[PATCH 00/34] 4.1 release notes and related changes

[PATCH 00/34] 4.1 release notes and related changes

[Paul Eggleton]

Here are the release notes and migration guide for 4.1 (langdale) as well
as a whole heap of additions of missing documentation. I may have got a
little carried away, but almost all of it was necessary to be able to
have links from the release notes / migration guide for more information.

Some things that we still need to sort out before release:
 * Known issues (if any)
 * Download info
 * externalsrc class has been moved to classes-recipe/ but documentation
   and comments in the class suggest using it globally (presumably to make
   it easier to support a subset of recipes without having to bbappend all
   of them.) We need to do one of the following:
   A) move the class back to classes/ (easiest),
   B) update the documentation and comments to remove the global usage,
      and note in the migration guide, or
   C) add it as a known issue and fix with A/B later.
 * New direct ESDK feature refers to "bitbake populate-sysroots" instead
   of "bitbake build-sysroots" - Alex will be sending a patch soon.

A few gaps that are still present (probably post-release at this point):
 * Rust support (classes, variables)
 * New layer setup functionality

Let me know if I missed anything / messed anything up.


The following changes since commit 42d3e26a0d04bc5951e640b471686f347dc9b74a:

  ref-manual/faq.rst: update references to products built with OE / Yocto Project (2022-10-06 10:22:27 +0200)

are available in the git repository at:

  https://git.yoctoproject.org/poky-contrib paule/4.1-release
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=paule/4.1-release

Paul Eggleton (34):
  migration-general: add section on using buildhistory
  ref-manual: add DISABLE_STATIC
  ref-manual: expand documentation on image-buildinfo class
  ref-manual: add WATCHDOG_TIMEOUT to variable glossary
  ref-manual: correct default for BUILDHISTORY_COMMIT
  ref-manual: document new github-releases class
  ref-manual: add a note to ssh-server-dropbear feature
  ref-manual: sync supported distro list with code
  ref-manual: update buildpaths QA check documentation
  ref-manual: add UBOOT_MKIMAGE_SIGN
  ref-manual: add DEV_PKG_DEPENDENCY
  ref-manual: add SDK_TOOLCHAIN_LANGS
  ref-manual: add pressure limit variable documentation
  ref-manual: add pypi class
  ref-manual: update pypi documentation for CVE_PRODUCT default in 4.1
  ref-manual: add CVE_CHECK_SHOW_WARNINGS
  ref-manual: add info on buildtools-make-tarball
  ref-manual: add FIT_PAD_ALG
  ref-manual: add CVE_DB_UPDATE_INTERVAL
  ref-manual: add KERNEL_DEPLOY_DEPEND
  ref-manual: add MOUNT_BASE variable
  ref-manual: remove reference to testimage-auto class
  Update documentation for classes split
  ref-manual: complementary package installation recommends
  ref-manual: remove reference to largefile in DISTRO_FEATURES
  ref-manual: add missing features
  ref-manual: add serial-autologin-root to IMAGE_FEATURES documentation
  ref-manual: add previous overlayfs-etc variables
  ref-manual: add OVERLAYFS_ETC_EXPOSE_LOWER
  ref-manual: add WIRELESS_DAEMON
  ref-manual: add section for create-spdx class
  ref-manual: add overlayfs class variables
  ref-manual: add OVERLAYFS_QA_SKIP
  Add 4.1 migration guide & release notes

 documentation/dev-manual/common-tasks.rst          |   8 +-
 documentation/migration-guides/index.rst           |   1 +
 documentation/migration-guides/migration-1.5.rst   |   2 +-
 documentation/migration-guides/migration-2.6.rst   |   2 +-
 documentation/migration-guides/migration-4.1.rst   | 214 +++++++
 .../migration-guides/migration-general.rst         |  33 +
 documentation/migration-guides/release-4.1.rst     |   7 +
 .../migration-guides/release-notes-4.1.rst         | 687 +++++++++++++++++++++
 documentation/overview-manual/concepts.rst         |   6 +-
 documentation/ref-manual/classes.rst               |  96 ++-
 documentation/ref-manual/faq.rst                   |   2 +-
 documentation/ref-manual/features.rst              |  74 ++-
 documentation/ref-manual/qa-checks.rst             |  16 +
 documentation/ref-manual/release-process.rst       |   2 +-
 documentation/ref-manual/structure.rst             |   6 +-
 documentation/ref-manual/system-requirements.rst   |  28 +-
 documentation/ref-manual/tasks.rst                 |   4 +-
 documentation/ref-manual/variables.rst             | 303 +++++++--
 documentation/test-manual/intro.rst                |   4 +-
 19 files changed, 1414 insertions(+), 81 deletions(-)
 create mode 100644 documentation/migration-guides/migration-4.1.rst
 create mode 100644 documentation/migration-guides/release-4.1.rst
 create mode 100644 documentation/migration-guides/release-notes-4.1.rst

-- 
1.8.3.1

[PATCH 01/34] migration-general: add section on using buildhistory

[Paul Eggleton]

From: Paul Eggleton <paul.eggleton@microsoft.com>

Add a short section recommending the use of buildhistory to compare
the build output before and after migration.

Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
---
 .../migration-guides/migration-general.rst         | 33 ++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/documentation/migration-guides/migration-general.rst b/documentation/migration-guides/migration-general.rst
index 9eecf69..8b22508 100644
--- a/documentation/migration-guides/migration-general.rst
+++ b/documentation/migration-guides/migration-general.rst
@@ -70,3 +70,36 @@ any new Yocto Project release.
      bitbake-layers show-appends
 
 
+.. _migration-general-buildhistory:
+
+- *Checking Image / SDK Changes*:
+
+   The :ref:`buildhistory <ref-classes-buildhistory>` class can be used
+   if you wish to check the impact of changes to images / SDKs across
+   the migration (e.g. added/removed packages, added/removed files, size
+   changes etc.). To do this, follow these steps:
+
+   1. Enable buildhistory before the migration
+
+   2. Run a pre-migration build
+
+   3. Capture the buildhistory output (as specified by :term:`BUILDHISTORY_DIR`)
+      and ensure it is preserved for subsequent builds. How you would do this
+      depends how you are running your builds - if you are doing this all on
+      one workstation in the same build directory you may not need to do
+      anything other than not deleting the buildhistory output directory. For
+      builds in a pipeline it may be more complicated.
+
+   4. Set a tag in the buildhistory output (which is a git repository) before
+      migration, to make the commit from the pre-migration build easy to find
+      as you may end up running multiple builds during the migration.
+
+   5. Perform the migration
+
+   6. Run a build
+
+   7. Check the output changes between the previously set tag and HEAD in the
+      buildhistory output using ``git diff`` or ``buildhistory-diff``.
+
+   For more information on using buildhistory, see
+   :ref:`dev-manual/common-tasks:maintaining build output quality`.
-- 
1.8.3.1

[PATCH 02/34] ref-manual: add DISABLE_STATIC

[Paul Eggleton]

From: Paul Eggleton <paul.eggleton@microsoft.com>

This was added all the way back in krogoth.

Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
---
 documentation/ref-manual/variables.rst | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst
index 1685a26..8ea9834 100644
--- a/documentation/ref-manual/variables.rst
+++ b/documentation/ref-manual/variables.rst
@@ -1812,6 +1812,18 @@ system and gives an overview of their function and contents.
       :term:`DESCRIPTION` takes the value of the :term:`SUMMARY`
       variable.
 
+   :term:`DISABLE_STATIC`
+      Used in order to disable static linking by default (in order to save
+      space, since static libraries are often unused in embedded systems.)
+      The default value is " --disable-static", however it can be set to ""
+      in order to enable static linking if desired. Certain recipes do this
+      individually, and also there is a
+      ``meta/conf/distro/include/no-static-libs.inc`` include file that
+      disables static linking for a number of recipes. Some software
+      packages or build tools (such as CMake) have explicit support for
+      enabling / disabling static linking, and in those cases
+      :term:`DISABLE_STATIC` is not used.
+
    :term:`DISTRO`
       The short name of the distribution. For information on the long name
       of the distribution, see the :term:`DISTRO_NAME`
-- 
1.8.3.1

[PATCH 03/34] ref-manual: expand documentation on image-buildinfo class

[Paul Eggleton]

From: Paul Eggleton <paul.eggleton@microsoft.com>

Expand the documentation on the image-buildinfo class, and add variable
glossary entries for IMAGE_BUILDINFO_FILE, IMAGE_BUILDINFO_VARS and
SDK_BUILDINFO_FILE (latter is new in 4.1).

Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
---
 documentation/ref-manual/classes.rst   | 18 ++++++++++++++++--
 documentation/ref-manual/variables.rst | 16 ++++++++++++++++
 2 files changed, 32 insertions(+), 2 deletions(-)

diff --git a/documentation/ref-manual/classes.rst b/documentation/ref-manual/classes.rst
index 5e49613..cc0d212 100644
--- a/documentation/ref-manual/classes.rst
+++ b/documentation/ref-manual/classes.rst
@@ -881,8 +881,22 @@ Yocto Project Overview and Concepts Manual.
 ``image-buildinfo.bbclass``
 ===========================
 
-The ``image-buildinfo`` class writes information to the target
-filesystem on ``/etc/build``.
+The ``image-buildinfo`` class writes a plain text file containing
+build information to the target filesystem at ``${sysconfdir}/buildinfo``
+by default (as specified by :term:`IMAGE_BUILDINFO_FILE`.
+This can be useful for manually determining the origin of any given
+image. It writes out two sections:
+
+1. `Build Configuration`: a list of variables and their values (specified
+   by :term:`IMAGE_BUILDINFO_VARS`, which defaults to :term:`DISTRO` and
+   :term:`DISTRO_VERSION`)
+
+2. `Layer Revisions`: the revisions of all of the layers used in the
+   build.
+
+Additionally, when building an SDK it will write the same contents
+to ``/buildinfo`` by default (as specified by
+:term:`SDK_BUILDINFO_FILE`).
 
 .. _ref-classes-image_types:
 
diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst
index 8ea9834..8b0331c 100644
--- a/documentation/ref-manual/variables.rst
+++ b/documentation/ref-manual/variables.rst
@@ -3053,6 +3053,17 @@ system and gives an overview of their function and contents.
       material for Wic is located in the
       ":doc:`/ref-manual/kickstart`" chapter.
 
+   :term:`IMAGE_BUILDINFO_FILE`
+      When using the :ref:`image-buildinfo <ref-classes-image-buildinfo>` class,
+      specifies the file in the image to write the build information into. The
+      default value is "``${sysconfdir}/buildinfo``".
+
+   :term:`IMAGE_BUILDINFO_VARS`
+      When using the :ref:`image-buildinfo <ref-classes-image-buildinfo>` class,
+      specifies the list of variables to include in the `Build Configuration`
+      section of the output file (as a space-separated list). Defaults to
+      ":term:`DISTRO` :term:`DISTRO_VERSION`".
+
    :term:`IMAGE_CLASSES`
       A list of classes that all images should inherit. You typically use
       this variable to specify the list of classes that register the
@@ -6627,6 +6638,11 @@ system and gives an overview of their function and contents.
       The target architecture for the SDK. Typically, you do not directly
       set this variable. Instead, use :term:`SDKMACHINE`.
 
+   :term:`SDK_BUILDINFO_FILE`
+      When using the :ref:`image-buildinfo <ref-classes-image-buildinfo>` class,
+      specifies the file in the SDK to write the build information into. The
+      default value is "``/buildinfo``".
+
    :term:`SDK_CUSTOM_TEMPLATECONF`
       When building the extensible SDK, if :term:`SDK_CUSTOM_TEMPLATECONF` is set to
       "1" and a ``conf/templateconf.cfg`` file exists in the build directory
-- 
1.8.3.1

[PATCH 04/34] ref-manual: add WATCHDOG_TIMEOUT to variable glossary

[Paul Eggleton]

From: Paul Eggleton <paul.eggleton@microsoft.com>

In 4.1 the WATCHDOG_TIMEOUT variable is now used in two places, so let's
actually document it.

Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
---
 documentation/ref-manual/variables.rst | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst
index 8b0331c..9eb453c 100644
--- a/documentation/ref-manual/variables.rst
+++ b/documentation/ref-manual/variables.rst
@@ -8872,6 +8872,10 @@ system and gives an overview of their function and contents.
       can control with this variable, see the
       ":ref:`ref-classes-insane`" section.
 
+   :term:`WATCHDOG_TIMEOUT`
+      Specifies the timeout in seconds used by the ``watchdog`` recipe and
+      also by ``systemd`` during reboot. The default is 60 seconds.
+
    :term:`WKS_FILE`
       Specifies the location of the Wic kickstart file that is used by the
       OpenEmbedded build system to create a partitioned image
-- 
1.8.3.1

[PATCH 05/34] ref-manual: correct default for BUILDHISTORY_COMMIT

[Paul Eggleton]

From: Paul Eggleton <paul.eggleton@microsoft.com>

The default changed to "1" back in 2017 (OE-Core revision
8018a2349b7ad5ab27731c93a49603adf5f72fc2). It seems I missed updating
the documentation to match.

Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
---
 documentation/ref-manual/variables.rst | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst
index 9eb453c..81a4ab1 100644
--- a/documentation/ref-manual/variables.rst
+++ b/documentation/ref-manual/variables.rst
@@ -920,10 +920,10 @@ system and gives an overview of their function and contents.
       and sdk). If you want to track changes to build history over time,
       you should set this value to "1".
 
-      By default, the :ref:`buildhistory <ref-classes-buildhistory>` class does not commit the build
-      history output in a local Git repository::
+      By default, the :ref:`buildhistory <ref-classes-buildhistory>` class
+      enables committing the buildhistory output in a local Git repository::
 
-         BUILDHISTORY_COMMIT ?= "0"
+         BUILDHISTORY_COMMIT ?= "1"
 
    :term:`BUILDHISTORY_COMMIT_AUTHOR`
       When inheriting the :ref:`buildhistory <ref-classes-buildhistory>`
-- 
1.8.3.1

[PATCH 06/34] ref-manual: document new github-releases class

[Paul Eggleton]

From: Paul Eggleton <paul.eggleton@microsoft.com>

Newly added class in 4.1.

Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
---
 documentation/ref-manual/classes.rst   | 14 ++++++++++++++
 documentation/ref-manual/variables.rst |  7 +++++++
 2 files changed, 21 insertions(+)

diff --git a/documentation/ref-manual/classes.rst b/documentation/ref-manual/classes.rst
index cc0d212..6c60d41 100644
--- a/documentation/ref-manual/classes.rst
+++ b/documentation/ref-manual/classes.rst
@@ -659,6 +659,20 @@ the GNU ``gettext`` internationalization and localization system. All
 recipes building software that use ``gettext`` should inherit this
 class.
 
+.. _ref-classes-github-releases:
+
+``github-releases``
+===================
+
+For recipes that fetch release tarballs from github, the ``github-releases``
+class sets up a standard way for checking available upstream versions
+(to support ``devtool upgrade`` and the Automated Upgrade Helper (AUH)).
+
+To use it, add ``github-releases`` to the inherit line in the recipe,
+and if the default value of :term:`GITHUB_BASE_URI` is not suitable,
+then set your own value in the recipe. You should then use ``${GITHUB_BASE_URI}``
+in the value you set for :term:`SRC_URI` within the recipe.
+
 .. _ref-classes-gnomebase:
 
 ``gnomebase.bbclass``
diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst
index 81a4ab1..bdc8e3b 100644
--- a/documentation/ref-manual/variables.rst
+++ b/documentation/ref-manual/variables.rst
@@ -2768,6 +2768,13 @@ system and gives an overview of their function and contents.
       The directory in which a local copy of a Git repository is stored
       when it is cloned.
 
+   :term:`GITHUB_BASE_URI`
+      When inheriting the :ref:`github-releases <ref-classes-github-releases>`
+      class, specifies the base URL for fetching releases for the github
+      project you wish to fetch sources from. The default value is as follows::
+
+         GITHUB_BASE_URI ?= "https://github.com/${BPN}/${BPN}/releases/"
+
    :term:`GLIBC_GENERATE_LOCALES`
       Specifies the list of GLIBC locales to generate should you not wish
       to generate all LIBC locals, which can be time consuming.
-- 
1.8.3.1

[PATCH 07/34] ref-manual: add a note to ssh-server-dropbear feature

[Paul Eggleton]

From: Paul Eggleton <paul.eggleton@microsoft.com>

Add a note regarding the 4.1 change to add openssh-sftp-server as a
recommends from ssh-server-dropbear.

Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
---
 documentation/ref-manual/features.rst | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/documentation/ref-manual/features.rst b/documentation/ref-manual/features.rst
index 5e853ca..9dc73db 100644
--- a/documentation/ref-manual/features.rst
+++ b/documentation/ref-manual/features.rst
@@ -322,6 +322,21 @@ these valid features is as follows:
 
 -  *ssh-server-dropbear:* Installs the Dropbear minimal SSH server.
 
+   .. note::
+
+      As of the 4.1 release, the ``ssh-server-dropbear`` feature also
+      recommends the ``openssh-sftp-server`` package, which by default
+      will be pulled into the image. This is because recent versions of
+      the OpenSSH ``scp`` client now use the SFTP protocol, and thus
+      require an SFTP server to be present to connect to. However, if
+      you wish to use the Dropbear ssh server `without` the SFTP server
+      installed, you can either remove ``ssh-server-dropbear`` from
+      ``IMAGE_FEATURES`` and add ``dropbear`` to :term:`IMAGE_INSTALL`
+      instead, or alternatively still use the feature but set
+      :term:`BAD_RECOMMENDATIONS` as follows::
+
+         BAD_RECOMMENDATIONS += "openssh-sftp-server"
+
 -  *ssh-server-openssh:* Installs the OpenSSH SSH server, which is more
    full-featured than Dropbear. Note that if both the OpenSSH SSH server
    and the Dropbear minimal SSH server are present in
-- 
1.8.3.1

[PATCH 08/34] ref-manual: sync supported distro list with code

[Paul Eggleton]

From: Paul Eggleton <paul.eggleton@microsoft.com>

We were missing Ubuntu 21.10.

Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
---
 documentation/ref-manual/system-requirements.rst | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/documentation/ref-manual/system-requirements.rst b/documentation/ref-manual/system-requirements.rst
index acc97c9..014c9a5 100644
--- a/documentation/ref-manual/system-requirements.rst
+++ b/documentation/ref-manual/system-requirements.rst
@@ -41,6 +41,8 @@ distributions:
 
 -  Ubuntu 20.04 (LTS)
 
+-  Ubuntu 21.10
+
 -  Ubuntu 22.04 (LTS)
 
 -  Fedora 34
-- 
1.8.3.1

[PATCH 09/34] ref-manual: update buildpaths QA check documentation

[Paul Eggleton]

From: Paul Eggleton <paul.eggleton@microsoft.com>

The buildpaths QA check is now practically usable and enabled by
default, so update the comment and add a section with the warning
message since users may start seeing it in their builds.

Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
---
 documentation/ref-manual/classes.rst   |  4 ++--
 documentation/ref-manual/qa-checks.rst | 16 ++++++++++++++++
 2 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/documentation/ref-manual/classes.rst b/documentation/ref-manual/classes.rst
index 6c60d41..d94db03 100644
--- a/documentation/ref-manual/classes.rst
+++ b/documentation/ref-manual/classes.rst
@@ -1008,8 +1008,8 @@ Here are the tests you can list with the :term:`WARN_QA` and
    software, like bootloaders, might need to bypass this check.
 
 -  ``buildpaths:`` Checks for paths to locations on the build host
-   inside the output files. Currently, this test triggers too many false
-   positives and thus is not normally enabled.
+   inside the output files. Not only can these leak information about
+   the build environment, they also hinder binary reproducibility.
 
 -  ``build-deps:`` Determines if a build-time dependency that is
    specified through :term:`DEPENDS`, explicit
diff --git a/documentation/ref-manual/qa-checks.rst b/documentation/ref-manual/qa-checks.rst
index 9455bec..fb31dc1 100644
--- a/documentation/ref-manual/qa-checks.rst
+++ b/documentation/ref-manual/qa-checks.rst
@@ -748,6 +748,22 @@ Errors and Warnings
     other things in the patches, those can be discarded.
 
 
+.. _qa-check-buildpaths:
+
+- ``File <filename> in package <packagename> contains reference to TMPDIR [buildpaths]``
+
+    This check ensures that build system paths (including :term:`TMPDIR`) do not
+    appear in output files, which not only leaks build system configuration into
+    the target, but also hinders binary reproducibility as the output will change
+    if the build system configuration changes.
+
+    Typically these paths will enter the output through some mechanism in the
+    configuration or compilation of the software being built by the recipe. To
+    resolve this issue you will need to determine how the detected path is
+    entering the output. Sometimes it may require adjusting scripts or code to
+    use a relative path rather than an absolute one, or to pick up the path from
+    runtime configuration or environment variables.
+
 
 Configuring and Disabling QA Checks
 ===================================
-- 
1.8.3.1

[PATCH 10/34] ref-manual: add UBOOT_MKIMAGE_SIGN

[Paul Eggleton]

From: Paul Eggleton <paul.eggleton@microsoft.com>

New variable in 4.1.

Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
---
 documentation/ref-manual/variables.rst | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst
index bdc8e3b..7707f5a 100644
--- a/documentation/ref-manual/variables.rst
+++ b/documentation/ref-manual/variables.rst
@@ -8564,6 +8564,10 @@ system and gives an overview of their function and contents.
       If :term:`UBOOT_MKIMAGE_DTCOPTS` is not set then kernel-fitimage will not
       pass the ``-D`` option to mkimage.
 
+   :term:`UBOOT_MKIMAGE_KERNEL_TYPE`
+      Specifies the type argument for the kernel as passed to ``uboot-mkimage``.
+      The default value is "kernel".
+
    :term:`UBOOT_MKIMAGE_SIGN`
       Specifies the name of the mkimage command as used by the
       :ref:`kernel-fitimage <ref-classes-kernel-fitimage>` class to sign
-- 
1.8.3.1

[PATCH 11/34] ref-manual: add DEV_PKG_DEPENDENCY

[Paul Eggleton]

From: Paul Eggleton <paul.eggleton@microsoft.com>

New variable in 4.1.

Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
---
 documentation/ref-manual/variables.rst | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst
index 7707f5a..ab39fa8 100644
--- a/documentation/ref-manual/variables.rst
+++ b/documentation/ref-manual/variables.rst
@@ -1812,6 +1812,11 @@ system and gives an overview of their function and contents.
       :term:`DESCRIPTION` takes the value of the :term:`SUMMARY`
       variable.
 
+   :term:`DEV_PKG_DEPENDENCY`
+      Provides an easy way for recipes to disable or adjust the runtime
+      dependency (:term:`RDEPENDS`) of the ``${PN}-dev`` package on the main
+      (``${PN}``) package, particularly where the main package may be empty.
+
    :term:`DISABLE_STATIC`
       Used in order to disable static linking by default (in order to save
       space, since static libraries are often unused in embedded systems.)
-- 
1.8.3.1

[PATCH 12/34] ref-manual: add SDK_TOOLCHAIN_LANGS

[Paul Eggleton]

From: Paul Eggleton <paul.eggleton@microsoft.com>

New variable in 4.1.

Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
---
 documentation/ref-manual/variables.rst | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst
index ab39fa8..0c6bd80 100644
--- a/documentation/ref-manual/variables.rst
+++ b/documentation/ref-manual/variables.rst
@@ -6854,6 +6854,10 @@ system and gives an overview of their function and contents.
       section in the Yocto Project Application Development and the
       Extensible Software Development Kit (eSDK) manual.
 
+   :term:`SDK_TOOLCHAIN_LANGS`
+      Specifies programming languages to support in the SDK, as a
+      space-separated list. Currently supported items are ``rust`` and ``go``.
+
    :term:`SDK_UPDATE_URL`
       An optional URL for an update server for the extensible SDK. If set,
       the value is used as the default update server when running
-- 
1.8.3.1

[PATCH 13/34] ref-manual: add pressure limit variable documentation

[Paul Eggleton]

From: Paul Eggleton <paul.eggleton@microsoft.com>

Add BB_PRESSURE_MAX_CPU, BB_PRESSURE_MAX_IO and BB_PRESSURE_MAX_MEMORY
variables (new in 4.1), based upon the supremely detailed commit
messages from Aryaman Gupta <aryaman.gupta@windriver.com> who
implemented the functionality. There is probably enough material for a
proper BitBake manual section (particularly if we can have some good
guidance on how users should determine the values for best performance)
but I did not have time to write such a section, and the BitBake manual
probably needs some additional preamble on tasks / scheduling
beforehand.

Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
---
 documentation/ref-manual/variables.rst | 42 ++++++++++++++++++++++++++++++++++
 1 file changed, 42 insertions(+)

diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst
index 0c6bd80..e4304d1 100644
--- a/documentation/ref-manual/variables.rst
+++ b/documentation/ref-manual/variables.rst
@@ -530,6 +530,48 @@ system and gives an overview of their function and contents.
       ":ref:`dev-manual/common-tasks:speeding up a build`"
       section in the Yocto Project Development Tasks Manual.
 
+   :term:`BB_PRESSURE_MAX_CPU`
+      Specifies a maximum CPU pressure threshold, above which BitBake's
+      scheduler will not start new tasks (providing there is at least
+      one active task). If no value is set, CPU pressure is not
+      monitored when starting tasks.
+
+      The pressure data is calculated based upon what (recent) Linux
+      kernels expose under ``/proc/pressure``. The threshold represents
+      the difference in "total" pressure from the previous second. The
+      minimum value is 1.0 (extremely slow builds) and the maximum is
+      1000000 (a pressure value unlikely to ever be reached).
+
+   :term:`BB_PRESSURE_MAX_IO`
+      Specifies a maximum I/O pressure threshold, above which BitBake's
+      scheduler will not start new tasks (providing there is at least
+      one active task). If no value is set, I/O pressure is not
+      monitored when starting tasks.
+
+      The pressure data is calculated based upon what (recent) Linux
+      kernels expose under ``/proc/pressure``. The threshold represents
+      the difference in "total" pressure from the previous second. The
+      minimum value is 1.0 (extremely slow builds) and the maximum is
+      1000000 (a pressure value unlikely to ever be reached).
+
+   :term:`BB_PRESSURE_MAX_MEMORY`
+      Specifies a maximum memory pressure threshold, above which BitBake's
+      scheduler will not start new tasks (providing there is at least
+      one active task). If no value is set, memory pressure is not
+      monitored when starting tasks.
+
+      The pressure data is calculated based upon what (recent) Linux
+      kernels expose under ``/proc/pressure``. The threshold represents
+      the difference in "total" pressure from the previous second. The
+      minimum value is 1.0 (extremely slow builds) and the maximum is
+      1000000 (a pressure value unlikely to ever be reached).
+
+      Memory pressure is experienced when time is spent swapping,
+      refaulting pages from the page cache or performing direct reclaim.
+      This is why memory pressure is rarely seen, but setting this variable
+      might be useful as a last resort to prevent OOM errors if they are
+      occurring during builds.
+
    :term:`BB_SERVER_TIMEOUT`
       Specifies the time (in seconds) after which to unload the BitBake
       server due to inactivity. Set :term:`BB_SERVER_TIMEOUT` to determine how
-- 
1.8.3.1

[PATCH 14/34] ref-manual: add pypi class

[Paul Eggleton]

From: Paul Eggleton <paul.eggleton@microsoft.com>

Add missing documentation for the pypi class.

Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
---
 documentation/ref-manual/classes.rst   | 14 ++++++++++++++
 documentation/ref-manual/variables.rst |  8 ++++++++
 2 files changed, 22 insertions(+)

diff --git a/documentation/ref-manual/classes.rst b/documentation/ref-manual/classes.rst
index d94db03..f6bbee5 100644
--- a/documentation/ref-manual/classes.rst
+++ b/documentation/ref-manual/classes.rst
@@ -2005,6 +2005,20 @@ When inherited by a recipe, the ``perlnative`` class supports using the
 native version of Perl built by the build system rather than using the
 version provided by the build host.
 
+.. _ref-classes-pypi:
+
+``pypi.bbclass``
+================
+
+The ``pypi`` class sets variables appropriately for recipes that build
+Python modules from `PyPI <https://pypi.org/>`__, the Python Package Index.
+By default it determines the PyPI package name based upon BPN (stripping the
+"python-" or "python3-" prefix off if present), however in some cases you may
+need to set it manually in the recipe by setting :term:`PYPI_PACKAGE`.
+
+Variables set by the ``pypi`` class include :term:`SRC_URI`, :term:`SECTION`,
+:term:`HOMEPAGE`, :term:`UPSTREAM_CHECK_URI`, and :term:`UPSTREAM_CHECK_REGEX`.
+
 .. _ref-classes-python_flit_core:
 
 ``python_flit_core.bbclass``
diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst
index e4304d1..ceb6b0e 100644
--- a/documentation/ref-manual/variables.rst
+++ b/documentation/ref-manual/variables.rst
@@ -6219,6 +6219,14 @@ system and gives an overview of their function and contents.
 
       :term:`PV` is the default value of the :term:`PKGV` variable.
 
+   :term:`PYPI_PACKAGE`
+      When inheriting the :ref:`pypi <ref-classes-pypi>` class, specifies the
+      `PyPI <https://pypi.org/>`__ package name to be built. The default value
+      is set based upon :term:`BPN` (stripping any "python-" or "python3-"
+      prefix off if present), however for some packages it will need to be set
+      explicitly if that will not match the package name (e.g. where the
+      package name has a prefix, underscores, uppercase letters etc.)
+
    :term:`PYTHON_ABI`
       When used by recipes that inherit the
       :ref:`setuptools3 <ref-classes-setuptools3>` class, denotes the
-- 
1.8.3.1

[PATCH 15/34] ref-manual: update pypi documentation for CVE_PRODUCT default in 4.1

[Paul Eggleton]

From: Paul Eggleton <paul.eggleton@microsoft.com>

In 4.1 the pypi class has been updated to set a default CVE_PRODUCT
value.

Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
---
 documentation/ref-manual/classes.rst   | 3 ++-
 documentation/ref-manual/variables.rst | 4 +++-
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/documentation/ref-manual/classes.rst b/documentation/ref-manual/classes.rst
index f6bbee5..3b5b4f2 100644
--- a/documentation/ref-manual/classes.rst
+++ b/documentation/ref-manual/classes.rst
@@ -2017,7 +2017,8 @@ By default it determines the PyPI package name based upon BPN (stripping the
 need to set it manually in the recipe by setting :term:`PYPI_PACKAGE`.
 
 Variables set by the ``pypi`` class include :term:`SRC_URI`, :term:`SECTION`,
-:term:`HOMEPAGE`, :term:`UPSTREAM_CHECK_URI`, and :term:`UPSTREAM_CHECK_REGEX`.
+:term:`HOMEPAGE`, :term:`UPSTREAM_CHECK_URI`, :term:`UPSTREAM_CHECK_REGEX`
+and :term:`CVE_PRODUCT`.
 
 .. _ref-classes-python_flit_core:
 
diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst
index ceb6b0e..885641a 100644
--- a/documentation/ref-manual/variables.rst
+++ b/documentation/ref-manual/variables.rst
@@ -1516,7 +1516,9 @@ system and gives an overview of their function and contents.
       In a recipe, defines the name used to match the recipe name
       against the name in the upstream `NIST CVE database <https://nvd.nist.gov/>`__.
 
-      The default is ${:term:`BPN`}. If it does not match the name in the NIST CVE
+      The default is ${:term:`BPN`} (except for recipes that inherit the
+      :ref:`pypi <ref-classes-pypi>` class where it is set based upon
+      :term:`PYPI_PACKAGE`). If it does not match the name in the NIST CVE
       database or matches with multiple entries in the database, the default
       value needs to be changed.
 
-- 
1.8.3.1

[PATCH 16/34] ref-manual: add CVE_CHECK_SHOW_WARNINGS

[Paul Eggleton]

From: Paul Eggleton <paul.eggleton@microsoft.com>

New variable in 4.1.

Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
---
 documentation/ref-manual/variables.rst | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst
index 885641a..c226b92 100644
--- a/documentation/ref-manual/variables.rst
+++ b/documentation/ref-manual/variables.rst
@@ -1508,6 +1508,13 @@ system and gives an overview of their function and contents.
          # This is windows only issue.
          CVE_CHECK_IGNORE += "CVE-2020-15523"
 
+   :term:`CVE_CHECK_SHOW_WARNINGS`
+      Specifies whether or not the :ref:`pypi <ref-classes-cve-check>` class
+      should generate warning messages on the console when unpatched CVEs
+      are found. The default is "1", but you may wish to set it to "0" if you
+      are already examining/processing the logs after the build has completed
+      and thus do not need the warning messages.
+
    :term:`CVE_CHECK_SKIP_RECIPE`
       The list of package names (:term:`PN`) for which
       CVEs (Common Vulnerabilities and Exposures) are ignored.
-- 
1.8.3.1

[PATCH 17/34] ref-manual: add info on buildtools-make-tarball

[Paul Eggleton]

From: Paul Eggleton <paul.eggleton@microsoft.com>

This is not perfect, but at least covers the use case and the new
tarball that we are providing. Note that the --make-only option to
install-buildtools is a currently pending patch.

Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
---
 documentation/ref-manual/system-requirements.rst | 26 +++++++++++++++++++++++-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/documentation/ref-manual/system-requirements.rst b/documentation/ref-manual/system-requirements.rst
index 014c9a5..d6545d6 100644
--- a/documentation/ref-manual/system-requirements.rst
+++ b/documentation/ref-manual/system-requirements.rst
@@ -222,8 +222,13 @@ resolve this by installing a ``buildtools-extended`` tarball that
 contains additional tools, the equivalent of the Debian/Ubuntu ``build-essential``
 package.
 
+For systems with a broken make version (e.g. make 4.2.1 without patches) but
+where the rest of the host tools are usable, you can use the ``buildtools-make``
+tarball instead.
+
 In the sections that follow, three different methods will be described for
-installing the ``buildtools`` or ``buildtools-extended`` toolset.
+installing the ``buildtools``, ``buildtools-extended`` or ``buildtools-make``
+toolset.
 
 Installing a Pre-Built ``buildtools`` Tarball with ``install-buildtools`` script
 --------------------------------------------------------------------------------
@@ -258,6 +263,13 @@ installer and automatically installs the tools for you:
       $ cd poky
       $ scripts/install-buildtools
 
+   Alternatively if your host development system has a broken ``make``
+   version such that you only need a known good version of ``make``,
+   you can use the ``--make-only`` option:
+
+      $ cd poky
+      $ scripts/install-buildtools --make-only
+
 2. Source the tools environment setup script by using a command like the
    following::
 
@@ -292,6 +304,10 @@ steps:
 
       $ sh ~/Downloads/x86_64-buildtools-extended-nativesdk-standalone-&DISTRO;.sh
 
+   An example for the make-only installer::
+
+      $ sh ~/Downloads/x86_64-buildtools-make-nativesdk-standalone-&DISTRO;.sh
+
    During execution, a prompt appears that allows you to choose the
    installation directory. For example, you could choose the following:
    ``/home/your-username/buildtools``
@@ -337,6 +353,10 @@ installer:
 
       $ bitbake buildtools-extended-tarball
 
+   or to build the make-only tarball::
+
+      $ bitbake buildtools-make-tarball
+
    .. note::
 
       The :term:`SDKMACHINE` variable in your ``local.conf`` file determines
@@ -360,6 +380,10 @@ installer:
 
       $ sh ~/Downloads/x86_64-buildtools-extended-nativesdk-standalone-&DISTRO;.sh
 
+   or for the make-only installer::
+
+      $ sh ~/Downloads/x86_64-buildtools-make-nativesdk-standalone-&DISTRO;.sh
+
    During execution, a prompt appears that allows you to choose the
    installation directory. For example, you could choose the following:
    ``/home/your_username/buildtools``
-- 
1.8.3.1

[PATCH 18/34] ref-manual: add FIT_PAD_ALG

[Paul Eggleton]

From: Paul Eggleton <paul.eggleton@microsoft.com>

New variable in 4.1.

Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
---
 documentation/ref-manual/variables.rst | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst
index c226b92..3848d86 100644
--- a/documentation/ref-manual/variables.rst
+++ b/documentation/ref-manual/variables.rst
@@ -2755,6 +2755,10 @@ system and gives an overview of their function and contents.
       Specifies the signature algorithm used in creating the FIT Image.
       For e.g. rsa2048.
 
+   :term:`FIT_PAD_ALG`
+      Specifies the padding algorithm used in creating the FIT Image.
+      The default value is "pkcs-1.5".
+
    :term:`FIT_SIGN_INDIVIDUAL`
       If set to "1", then the :ref:`kernel-fitimage <ref-classes-kernel-fitimage>`
       class will sign the kernel, dtb and ramdisk images individually in addition
-- 
1.8.3.1

[PATCH 19/34] ref-manual: add CVE_DB_UPDATE_INTERVAL

[Paul Eggleton]

From: Paul Eggleton <paul.eggleton@microsoft.com>

New variable in 4.1.

Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
---
 documentation/ref-manual/variables.rst | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst
index 3848d86..124eb59 100644
--- a/documentation/ref-manual/variables.rst
+++ b/documentation/ref-manual/variables.rst
@@ -1519,6 +1519,13 @@ system and gives an overview of their function and contents.
       The list of package names (:term:`PN`) for which
       CVEs (Common Vulnerabilities and Exposures) are ignored.
 
+   :term:`CVE_DB_UPDATE_INTERVAL`
+      Specifies the CVE database update interval in seconds, as used by
+      ``cve-update-db-native``. The default value is "86400" i.e. once a day
+      (24*60*60). If the value is set to "0" then the update will be forced
+      every time. Alternatively, a negative value e.g. "-1" will disable
+      updates entirely.
+
    :term:`CVE_PRODUCT`
       In a recipe, defines the name used to match the recipe name
       against the name in the upstream `NIST CVE database <https://nvd.nist.gov/>`__.
-- 
1.8.3.1

[PATCH 20/34] ref-manual: add KERNEL_DEPLOY_DEPEND

[Paul Eggleton]

From: Paul Eggleton <paul.eggleton@microsoft.com>

New variable in 4.1.

Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
---
 documentation/ref-manual/variables.rst | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst
index 124eb59..d5038e5 100644
--- a/documentation/ref-manual/variables.rst
+++ b/documentation/ref-manual/variables.rst
@@ -4141,6 +4141,12 @@ system and gives an overview of their function and contents.
       the kernel. The default is "0" to disable this for reproducibility
       reasons.
 
+   :term:`KERNEL_DEPLOY_DEPEND`
+      Provides a means of controlling the dependency of an image recipe
+      on the kernel. The default value is "virtual/kernel:do_deploy",
+      however for a small initramfs image or other images that do not
+      need the kernel, this can be set to "" in the image recipe.
+
    :term:`KERNEL_DEVICETREE`
       Specifies the name of the generated Linux kernel device tree (i.e.
       the ``.dtb``) file.
-- 
1.8.3.1

[PATCH 21/34] ref-manual: add MOUNT_BASE variable

[Paul Eggleton]

From: Paul Eggleton <paul.eggleton@microsoft.com>

New variable for 4.1.

Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
---
 documentation/ref-manual/variables.rst | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst
index d5038e5..7c4a3dc 100644
--- a/documentation/ref-manual/variables.rst
+++ b/documentation/ref-manual/variables.rst
@@ -5043,6 +5043,11 @@ system and gives an overview of their function and contents.
 
          KERNEL_ARTIFACT_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
 
+   :term:`MOUNT_BASE`
+      On non-systemd systems (where ``udev-extraconf`` is being used),
+      specifies the base directory for auto-mounting filesystems. The
+      default value is "/run/media".
+
    :term:`MULTIMACH_TARGET_SYS`
       Uniquely identifies the type of the target system for which packages
       are being built. This variable allows output for different types of
-- 
1.8.3.1

[PATCH 22/34] ref-manual: remove reference to testimage-auto class

[Paul Eggleton]

From: Paul Eggleton <paul.eggleton@microsoft.com>

testimage-auto was removed in the thud release.

Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
---
 documentation/dev-manual/common-tasks.rst        |  4 ++--
 documentation/migration-guides/migration-1.5.rst |  2 +-
 documentation/migration-guides/migration-2.6.rst |  2 +-
 documentation/overview-manual/concepts.rst       |  2 +-
 documentation/ref-manual/classes.rst             | 17 +++++++++--------
 documentation/ref-manual/release-process.rst     |  2 +-
 documentation/ref-manual/variables.rst           |  2 +-
 documentation/test-manual/intro.rst              |  4 ++--
 8 files changed, 18 insertions(+), 17 deletions(-)

diff --git a/documentation/dev-manual/common-tasks.rst b/documentation/dev-manual/common-tasks.rst
index a4741c5..68ce2b8 100644
--- a/documentation/dev-manual/common-tasks.rst
+++ b/documentation/dev-manual/common-tasks.rst
@@ -3048,7 +3048,7 @@ The following steps describe how to set up the AUH utility:
       your build directory.
 
    -  If you want to enable testing through the
-      :ref:`testimage <ref-classes-testimage*>`
+      :ref:`testimage <ref-classes-testimage>`
       class, which is optional, you need to have the following set in
       your ``conf/local.conf`` file::
 
@@ -8893,7 +8893,7 @@ You can start the tests automatically or manually:
 
 -  *Manually running tests:* To manually run the tests, first globally
    inherit the
-   :ref:`testimage <ref-classes-testimage*>` class
+   :ref:`testimage <ref-classes-testimage>` class
    by editing your ``local.conf`` file::
 
       INHERIT += "testimage"
diff --git a/documentation/migration-guides/migration-1.5.rst b/documentation/migration-guides/migration-1.5.rst
index 366fb00..1b78e99 100644
--- a/documentation/migration-guides/migration-1.5.rst
+++ b/documentation/migration-guides/migration-1.5.rst
@@ -240,7 +240,7 @@ Automated Image Testing
 -----------------------
 
 A new automated image testing framework has been added through the
-:ref:`ref-classes-testimage*` classes. This
+:ref:`ref-classes-testimage` classes. This
 framework replaces the older ``imagetest-qemu`` framework.
 
 You can learn more about performing automated image tests in the
diff --git a/documentation/migration-guides/migration-2.6.rst b/documentation/migration-guides/migration-2.6.rst
index 32bb48b..b36eb19 100644
--- a/documentation/migration-guides/migration-2.6.rst
+++ b/documentation/migration-guides/migration-2.6.rst
@@ -319,7 +319,7 @@ This section provides information about automatic testing changes:
    practices now dictate that you use the
    :term:`IMAGE_CLASSES` variable rather than the
    :term:`INHERIT` variable when you inherit the
-   :ref:`testimage <ref-classes-testimage*>` and
+   :ref:`testimage <ref-classes-testimage>` and
    :ref:`testsdk <ref-classes-testsdk>` classes used for automatic
    testing.
 
diff --git a/documentation/overview-manual/concepts.rst b/documentation/overview-manual/concepts.rst
index 39b8713..35d6feb 100644
--- a/documentation/overview-manual/concepts.rst
+++ b/documentation/overview-manual/concepts.rst
@@ -1014,7 +1014,7 @@ processing includes creation of a manifest file and optimizations.
 The manifest file (``.manifest``) resides in the same directory as the
 root filesystem image. This file lists out, line-by-line, the installed
 packages. The manifest file is useful for the
-:ref:`testimage <ref-classes-testimage*>` class,
+:ref:`testimage <ref-classes-testimage>` class,
 for example, to determine whether or not to run specific tests. See the
 :term:`IMAGE_MANIFEST`
 variable for additional information.
diff --git a/documentation/ref-manual/classes.rst b/documentation/ref-manual/classes.rst
index 3b5b4f2..0a83d04 100644
--- a/documentation/ref-manual/classes.rst
+++ b/documentation/ref-manual/classes.rst
@@ -2767,12 +2767,12 @@ session needs to be started. For example, the
 :ref:`devshell <ref-classes-devshell>` class all use the ``terminal``
 class.
 
-.. _ref-classes-testimage*:
+.. _ref-classes-testimage:
 
-``testimage*.bbclass``
-======================
+``testimage.bbclass``
+=====================
 
-The ``testimage*`` classes support running automated tests against
+The ``testimage`` class supports running automated tests against
 images using QEMU and on actual hardware. The classes handle loading the
 tests and starting the image. To use the classes, you need to perform
 steps to set up the environment.
@@ -2786,14 +2786,15 @@ steps to set up the environment.
 The tests are commands that run on the target system over ``ssh``. Each
 test is written in Python and makes use of the ``unittest`` module.
 
-The ``testimage.bbclass`` runs tests on an image when called using the
+The ``testimage`` class runs tests on an image when called using the
 following::
 
    $ bitbake -c testimage image
 
-The ``testimage-auto`` class
-runs tests on an image after the image is constructed (i.e.
-:term:`TESTIMAGE_AUTO` must be set to "1").
+Alternatively, if you wish to have tests automatically run for each image
+after it is built, you can set :term:`TESTIMAGE_AUTO`::
+
+   TESTIMAGE_AUTO = "1"
 
 For information on how to enable, run, and create new tests, see the
 ":ref:`dev-manual/common-tasks:performing automated runtime testing`"
diff --git a/documentation/ref-manual/release-process.rst b/documentation/ref-manual/release-process.rst
index 8acb4b8..c36fa55 100644
--- a/documentation/ref-manual/release-process.rst
+++ b/documentation/ref-manual/release-process.rst
@@ -127,7 +127,7 @@ consists of the following pieces:
    an ARM target, did the build produce ARM binaries. If, for example,
    the build produced PPC binaries then there is a problem.
 
--  :ref:`ref-classes-testimage*`: This class
+-  :ref:`ref-classes-testimage`: This class
    performs runtime testing of images after they are built. The tests
    are usually used with :doc:`QEMU </dev-manual/qemu>`
    to boot the images and check the combined runtime result boot
diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst
index 7c4a3dc..ec2e326 100644
--- a/documentation/ref-manual/variables.rst
+++ b/documentation/ref-manual/variables.rst
@@ -8342,7 +8342,7 @@ system and gives an overview of their function and contents.
       on enabling, running, and writing these tests, see the
       ":ref:`dev-manual/common-tasks:performing automated runtime testing`"
       section in the Yocto Project Development Tasks Manual and the
-      ":ref:`ref-classes-testimage*`" section.
+      ":ref:`ref-classes-testimage`" section.
 
    :term:`THISDIR`
       The directory in which the file BitBake is currently parsing is
diff --git a/documentation/test-manual/intro.rst b/documentation/test-manual/intro.rst
index 6421dd5..36958d0 100644
--- a/documentation/test-manual/intro.rst
+++ b/documentation/test-manual/intro.rst
@@ -132,8 +132,8 @@ the following types of tests:
 
       $ bitbake image -c testimage
 
-   The tests utilize the :ref:`testimage* <ref-classes-testimage*>`
-   classes and the :ref:`ref-tasks-testimage` task.
+   The tests utilize the :ref:`testimage <ref-classes-testimage>`
+   class 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
-- 
1.8.3.1

[PATCH 23/34] Update documentation for classes split

[Paul Eggleton]

From: Paul Eggleton <paul.eggleton@microsoft.com>

* Make reference to meta/classes* instead of just meta/classes
* Update each reference to the path where the class has moved
* Add a brief explanation to the classes reference explaining the split
* Add a note to INHERIT, INHERIT_DISTRO, IMAGE_CLASSES and USER_CLASSES
  variable glossary entries mentioning where the specified classes must
  be located. I contemplated adding the same note to PACKAGE_CLASSES
  but decided against it, as it has a very specific usage and such a
  note might distract from the narrative of that entry.
* Also trim the IMAGE_CLASSES entry which was quite outdated.
* INHERIT += no longer works with testimage so drop the note about that

Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
---
 documentation/dev-manual/common-tasks.rst  |  4 +-
 documentation/overview-manual/concepts.rst |  4 +-
 documentation/ref-manual/classes.rst       | 20 ++++++----
 documentation/ref-manual/faq.rst           |  2 +-
 documentation/ref-manual/structure.rst     |  6 +--
 documentation/ref-manual/tasks.rst         |  4 +-
 documentation/ref-manual/variables.rst     | 59 ++++++++++++++++--------------
 7 files changed, 53 insertions(+), 46 deletions(-)

diff --git a/documentation/dev-manual/common-tasks.rst b/documentation/dev-manual/common-tasks.rst
index 68ce2b8..0d4e814 100644
--- a/documentation/dev-manual/common-tasks.rst
+++ b/documentation/dev-manual/common-tasks.rst
@@ -973,7 +973,7 @@ a recipe and using :term:`EXTRA_IMAGE_FEATURES` from within your
 :term:`Build Directory`.
 
 To understand how these features work, the best reference is
-:ref:`meta/classes/image.bbclass <ref-classes-image>`.
+:ref:`meta/classes-recipe/image.bbclass <ref-classes-image>`.
 This class lists out the available
 :term:`IMAGE_FEATURES` of which most map to package groups while some, such
 as ``debug-tweaks`` and ``read-only-rootfs``, resolve as general
@@ -6889,7 +6889,7 @@ multiple times if you have more than one set of modules to package.
 For more examples that show how to use ``do_split_packages``, see the
 ``connman.inc`` file in the ``meta/recipes-connectivity/connman/``
 directory of the ``poky`` :ref:`source repository <overview-manual/development-environment:yocto project source repositories>`. You can
-also find examples in ``meta/classes/kernel.bbclass``.
+also find examples in ``meta/classes-recipe/kernel.bbclass``.
 
 Following is a reference that shows ``do_split_packages`` mandatory and
 optional arguments::
diff --git a/documentation/overview-manual/concepts.rst b/documentation/overview-manual/concepts.rst
index 35d6feb..a978e2c 100644
--- a/documentation/overview-manual/concepts.rst
+++ b/documentation/overview-manual/concepts.rst
@@ -853,7 +853,7 @@ This step in the build process consists of the following tasks:
    variables. For information on how this variable works within that
    class, see the
    :ref:`autotools <ref-classes-autotools>` class
-   :yocto_git:`here </poky/tree/meta/classes/autotools.bbclass>`.
+   :yocto_git:`here </poky/tree/meta/classes-recipe/autotools.bbclass>`.
 
 -  *do_compile*: Once a configuration task has been satisfied,
    BitBake compiles the source using the
@@ -931,7 +931,7 @@ The :term:`FILES` variable defines the
 files that go into each package in
 :term:`PACKAGES`. If you want
 details on how this is accomplished, you can look at
-:yocto_git:`package.bbclass </poky/tree/meta/classes/package.bbclass>`.
+:yocto_git:`package.bbclass </poky/tree/meta/classes-global/package.bbclass>`.
 
 Depending on the type of packages being created (RPM, DEB, or IPK), the
 :ref:`do_package_write_* <ref-tasks-package_write_deb>`
diff --git a/documentation/ref-manual/classes.rst b/documentation/ref-manual/classes.rst
index 0a83d04..652c2f3 100644
--- a/documentation/ref-manual/classes.rst
+++ b/documentation/ref-manual/classes.rst
@@ -13,8 +13,14 @@ some default behavior.
 
 Any :term:`Metadata` usually found in a recipe can also be
 placed in a class file. Class files are identified by the extension
-``.bbclass`` and are usually placed in a ``classes/`` directory beneath
-the ``meta*/`` directory found in the :term:`Source Directory`.
+``.bbclass`` and are usually placed in one of a set of subdirectories
+beneath the ``meta*/`` directory found in the :term:`Source Directory`:
+
+  - ``classes-recipe/`` - classes intended to be inherited by recipes
+    individually
+  - ``classes-global/`` - classes intended to be inherited globally
+  - ``classes/`` - classes whose usage context is not clearly defined
+
 Class files can also be pointed to by
 :term:`BUILDDIR` (e.g. ``build/``) in the same way as
 ``.conf`` files in the ``conf`` directory. Class files are searched for
@@ -22,7 +28,7 @@ in :term:`BBPATH` using the same method by which ``.conf``
 files are searched.
 
 This chapter discusses only the most useful and important classes. Other
-classes do exist within the ``meta/classes`` directory in the Source
+classes do exist within the ``meta/classes*`` directories in the Source
 Directory. You can reference the ``.bbclass`` files directly for more
 information.
 
@@ -2777,11 +2783,9 @@ images using QEMU and on actual hardware. The classes handle loading the
 tests and starting the image. To use the classes, you need to perform
 steps to set up the environment.
 
-.. note::
+To enable this class, add the following to your configuration::
 
-   Best practices include using :term:`IMAGE_CLASSES` rather than
-   :term:`INHERIT` to inherit the ``testimage`` class for automated image
-   testing.
+   IMAGE_CLASSES += "testimage"
 
 The tests are commands that run on the target system over ``ssh``. Each
 test is written in Python and makes use of the ``unittest`` module.
@@ -2936,7 +2940,7 @@ To use this class, you need to define a number of variables:
 These variables list alternative commands needed by a package, provide
 pathnames for links, default links for targets, and so forth. For
 details on how to use this class, see the comments in the
-:yocto_git:`update-alternatives.bbclass </poky/tree/meta/classes/update-alternatives.bbclass>`
+:yocto_git:`update-alternatives.bbclass </poky/tree/meta/classes-recipe/update-alternatives.bbclass>`
 file.
 
 .. note::
diff --git a/documentation/ref-manual/faq.rst b/documentation/ref-manual/faq.rst
index af49d57..84affdd 100644
--- a/documentation/ref-manual/faq.rst
+++ b/documentation/ref-manual/faq.rst
@@ -109,7 +109,7 @@ I prevent this?
 but make sure the package is manually marked as machine-specific for the
 case that needs it. The code that handles
 :term:`SRC_URI_OVERRIDES_PACKAGE_ARCH` is in the
-``meta/classes/base.bbclass`` file.
+``meta/classes-global/base.bbclass`` file.
 
 **Q:** I'm behind a firewall and need to use a proxy server. How do I do
 that?
diff --git a/documentation/ref-manual/structure.rst b/documentation/ref-manual/structure.rst
index 533745b..fe27d17 100644
--- a/documentation/ref-manual/structure.rst
+++ b/documentation/ref-manual/structure.rst
@@ -669,10 +669,10 @@ Yocto Project. Metadata has several important subdivisions:
 
 .. _structure-meta-classes:
 
-``meta/classes/``
------------------
+``meta/classes*/``
+------------------
 
-This directory contains the ``*.bbclass`` files. Class files are used to
+These directories contain the ``*.bbclass`` files. Class files are used to
 abstract common code so it can be reused by multiple packages. Every
 package inherits the :ref:`ref-classes-base` file. Examples of other important
 classes are :ref:`ref-classes-autotools`, which in theory allows any
diff --git a/documentation/ref-manual/tasks.rst b/documentation/ref-manual/tasks.rst
index d4408d1..b17c09c 100644
--- a/documentation/ref-manual/tasks.rst
+++ b/documentation/ref-manual/tasks.rst
@@ -190,8 +190,8 @@ that either directly or indirectly depend on the installed files (e.g.
    -  The ``cp`` command with the ``--no-preserve=ownership`` option.
 
    -  The ``tar`` command with the ``--no-same-owner`` option. See the
-      ``bin_package.bbclass`` file in the ``meta/classes`` directory of
-      the :term:`Source Directory` for an example.
+      ``bin_package.bbclass`` file in the ``meta/classes-recipe``
+      subdirectory of the :term:`Source Directory` for an example.
 
 .. _ref-tasks-install_ptest_base:
 
diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst
index ec2e326..c2e75d0 100644
--- a/documentation/ref-manual/variables.rst
+++ b/documentation/ref-manual/variables.rst
@@ -815,7 +815,7 @@ system and gives an overview of their function and contents.
          and `glob <https://docs.python.org/3/library/glob.html>`__.
 
       For more information on how this variable works, see
-      ``meta/classes/binconfig.bbclass`` in the :term:`Source Directory`.
+      ``meta/classes-recipe/binconfig.bbclass`` in the :term:`Source Directory`.
       You can also find general
       information on the class in the
       ":ref:`ref-classes-binconfig`" section.
@@ -2104,7 +2104,7 @@ system and gives an overview of their function and contents.
       available are xz and bz2.
 
       For information on policies and on how to use this variable, see the
-      comments in the ``meta/classes/compress_doc.bbclass`` file.
+      comments in the ``meta/classes-recipe/compress_doc.bbclass`` file.
 
    :term:`EFI_PROVIDER`
       When building bootable images (i.e. where ``hddimg``, ``iso``, or
@@ -2272,7 +2272,7 @@ system and gives an overview of their function and contents.
       variable tells the OpenEmbedded build system to prefer the installed
       external tools. See the
       :ref:`kernel-yocto <ref-classes-kernel-yocto>` class in
-      ``meta/classes`` to see how the variable is used.
+      ``meta/classes-recipe`` to see how the variable is used.
 
    :term:`EXTERNALSRC`
       When inheriting the :ref:`externalsrc <ref-classes-externalsrc>`
@@ -2649,7 +2649,7 @@ system and gives an overview of their function and contents.
       :term:`SRC_URI` statements.
 
       The default value for the :term:`FILESPATH` variable is defined in the
-      :ref:`ref-classes-base` class found in ``meta/classes`` in the
+      :ref:`ref-classes-base` class found in ``meta/classes-global`` in the
       :term:`Source Directory`::
 
          FILESPATH = "${@base_set_filespath(["${FILE_DIRNAME}/${BP}", \
@@ -3139,16 +3139,11 @@ system and gives an overview of their function and contents.
       ":term:`DISTRO` :term:`DISTRO_VERSION`".
 
    :term:`IMAGE_CLASSES`
-      A list of classes that all images should inherit. You typically use
-      this variable to specify the list of classes that register the
-      different types of images the OpenEmbedded build system creates.
+      A list of classes that all images should inherit. This is typically used
+      to enable functionality across all image recipes.
 
-      The default value for :term:`IMAGE_CLASSES` is ``image_types``. You can
-      set this variable in your ``local.conf`` or in a distribution
-      configuration file.
-
-      For more information, see ``meta/classes/image_types.bbclass`` in the
-      :term:`Source Directory`.
+      Classes specified in :term:`IMAGE_CLASSES` must be located in the
+      ``classes-recipe/`` or ``classes/`` subdirectories.
 
    :term:`IMAGE_CMD`
       Specifies the command to create the image file for a specific image
@@ -3164,7 +3159,7 @@ system and gives an overview of their function and contents.
       You typically do not need to set this variable unless you are adding
       support for a new image type. For more examples on how to set this
       variable, see the :ref:`image_types <ref-classes-image_types>`
-      class file, which is ``meta/classes/image_types.bbclass``.
+      class file, which is ``meta/classes-recipe/image_types.bbclass``.
 
    :term:`IMAGE_DEVICE_TABLES`
       Specifies one or more files that contain custom device tables that
@@ -3560,7 +3555,7 @@ system and gives an overview of their function and contents.
       - wic.lzma
 
       For more information about these types of images, see
-      ``meta/classes/image_types*.bbclass`` in the :term:`Source Directory`.
+      ``meta/classes-recipe/image_types*.bbclass`` in the :term:`Source Directory`.
 
    :term:`IMAGE_VERSION_SUFFIX`
       Version suffix that is part of the default :term:`IMAGE_NAME` and
@@ -3659,6 +3654,8 @@ system and gives an overview of their function and contents.
       functions in the class or classes are not executed for the base
       configuration and in each individual recipe. The OpenEmbedded build
       system ignores changes to :term:`INHERIT` in individual recipes.
+      Classes inherited using :term:`INHERIT` must be located in the
+      ``classes-global/`` or ``classes/`` subdirectories.
 
       For more information on :term:`INHERIT`, see the
       :ref:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata:\`\`inherit\`\` configuration directive`"
@@ -3668,6 +3665,9 @@ system and gives an overview of their function and contents.
       Lists classes that will be inherited at the distribution level. It is
       unlikely that you want to edit this variable.
 
+      Classes specified in :term:`INHERIT_DISTRO` must be located in the
+      ``classes-global/`` or ``classes/`` subdirectories.
+
       The default value of the variable is set as follows in the
       ``meta/conf/distro/defaultsetup.conf`` file::
 
@@ -3883,7 +3883,7 @@ system and gives an overview of their function and contents.
 
    :term:`INITRAMFS_LINK_NAME`
       The link name of the initial RAM filesystem image. This variable is
-      set in the ``meta/classes/kernel-artifact-names.bbclass`` file as
+      set in the ``meta/classes-recipe/kernel-artifact-names.bbclass`` file as
       follows::
 
          INITRAMFS_LINK_NAME ?= "initramfs-${KERNEL_ARTIFACT_LINK_NAME}"
@@ -3909,7 +3909,7 @@ system and gives an overview of their function and contents.
 
    :term:`INITRAMFS_NAME`
       The base name of the initial RAM filesystem image. This variable is
-      set in the ``meta/classes/kernel-artifact-names.bbclass`` file as
+      set in the ``meta/classes-recipe/kernel-artifact-names.bbclass`` file as
       follows::
 
          INITRAMFS_NAME ?= "initramfs-${KERNEL_ARTIFACT_NAME}"
@@ -4119,7 +4119,7 @@ system and gives an overview of their function and contents.
       variable.
 
       The value of :term:`KERNEL_ARTIFACT_NAME`, which is set in the
-      ``meta/classes/kernel-artifact-names.bbclass`` file, has the
+      ``meta/classes-recipe/kernel-artifact-names.bbclass`` file, has the
       following default value::
 
          KERNEL_ARTIFACT_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
@@ -4132,7 +4132,7 @@ system and gives an overview of their function and contents.
       :ref:`kernel <ref-classes-kernel>` class should inherit. You
       typically append this variable to enable extended image types. An
       example is the "kernel-fitimage", which enables fitImage support and
-      resides in ``meta/classes/kernel-fitimage.bbclass``. You can register
+      resides in ``meta/classes-recipe/kernel-fitimage.bbclass``. You can register
       custom kernel image types with the :ref:`kernel <ref-classes-kernel>` class using this
       variable.
 
@@ -4162,7 +4162,7 @@ system and gives an overview of their function and contents.
 
    :term:`KERNEL_DTB_LINK_NAME`
       The link name of the kernel device tree binary (DTB). This variable
-      is set in the ``meta/classes/kernel-artifact-names.bbclass`` file as
+      is set in the ``meta/classes-recipe/kernel-artifact-names.bbclass`` file as
       follows::
 
          KERNEL_DTB_LINK_NAME ?= "${KERNEL_ARTIFACT_LINK_NAME}"
@@ -4178,7 +4178,7 @@ system and gives an overview of their function and contents.
 
    :term:`KERNEL_DTB_NAME`
       The base name of the kernel device tree binary (DTB). This variable
-      is set in the ``meta/classes/kernel-artifact-names.bbclass`` file as
+      is set in the ``meta/classes-recipe/kernel-artifact-names.bbclass`` file as
       follows::
 
          KERNEL_DTB_NAME ?= "${KERNEL_ARTIFACT_NAME}"
@@ -4229,7 +4229,7 @@ system and gives an overview of their function and contents.
 
    :term:`KERNEL_FIT_LINK_NAME`
       The link name of the kernel flattened image tree (FIT) image. This
-      variable is set in the ``meta/classes/kernel-artifact-names.bbclass``
+      variable is set in the ``meta/classes-recipe/kernel-artifact-names.bbclass``
       file as follows::
 
          KERNEL_FIT_LINK_NAME ?= "${KERNEL_ARTIFACT_LINK_NAME}"
@@ -4245,7 +4245,7 @@ system and gives an overview of their function and contents.
 
    :term:`KERNEL_FIT_NAME`
       The base name of the kernel flattened image tree (FIT) image. This
-      variable is set in the ``meta/classes/kernel-artifact-names.bbclass``
+      variable is set in the ``meta/classes-recipe/kernel-artifact-names.bbclass``
       file as follows::
 
          KERNEL_FIT_NAME ?= "${KERNEL_ARTIFACT_NAME}"
@@ -4257,7 +4257,7 @@ system and gives an overview of their function and contents.
 
    :term:`KERNEL_IMAGE_LINK_NAME`
       The link name for the kernel image. This variable is set in the
-      ``meta/classes/kernel-artifact-names.bbclass`` file as follows::
+      ``meta/classes-recipe/kernel-artifact-names.bbclass`` file as follows::
 
          KERNEL_IMAGE_LINK_NAME ?= "${KERNEL_ARTIFACT_LINK_NAME}"
 
@@ -4285,7 +4285,7 @@ system and gives an overview of their function and contents.
 
    :term:`KERNEL_IMAGE_NAME`
       The base name of the kernel image. This variable is set in the
-      ``meta/classes/kernel-artifact-names.bbclass`` file as follows::
+      ``meta/classes-recipe/kernel-artifact-names.bbclass`` file as follows::
 
          KERNEL_IMAGE_NAME ?= "${KERNEL_ARTIFACT_NAME}"
 
@@ -5020,7 +5020,7 @@ system and gives an overview of their function and contents.
 
    :term:`MODULE_TARBALL_LINK_NAME`
       The link name of the kernel module tarball. This variable is set in
-      the ``meta/classes/kernel-artifact-names.bbclass`` file as follows::
+      the ``meta/classes-recipe/kernel-artifact-names.bbclass`` file as follows::
 
          MODULE_TARBALL_LINK_NAME ?= "${KERNEL_ARTIFACT_LINK_NAME}"
 
@@ -5034,7 +5034,7 @@ system and gives an overview of their function and contents.
 
    :term:`MODULE_TARBALL_NAME`
       The base name of the kernel module tarball. This variable is set in
-      the ``meta/classes/kernel-artifact-names.bbclass`` file as follows::
+      the ``meta/classes-recipe/kernel-artifact-names.bbclass`` file as follows::
 
          MODULE_TARBALL_NAME ?= "${KERNEL_ARTIFACT_NAME}"
 
@@ -5169,7 +5169,7 @@ system and gives an overview of their function and contents.
       ``sysroots/`` directory so that all builds that use the script will
       use the correct directories for the cross compiling layout.
 
-      See the ``meta/classes/binconfig.bbclass`` in the
+      See the ``meta/classes-recipe/binconfig.bbclass`` in the
       :term:`Source Directory` for details on how this class
       applies these additional sed command arguments.
 
@@ -8825,6 +8825,9 @@ system and gives an overview of their function and contents.
       A list of classes to globally inherit. These classes are used by the
       OpenEmbedded build system to enable extra features.
 
+      Classes inherited using :term:`USER_CLASSES` must be located in the
+      ``classes-global/`` or ``classes/`` subdirectories.
+
       The default list is set in your ``local.conf`` file::
 
          USER_CLASSES ?= "buildstats"
-- 
1.8.3.1

[PATCH 24/34] ref-manual: complementary package installation recommends

[Paul Eggleton]

From: Paul Eggleton <paul.eggleton@microsoft.com>

Add a note to the COMPLEMENTARY_GLOB variable glossary entry mentioning
that recommends aren't installed (since this seems to be the only place
that complementary package installation is really discussed). Also turn
the paragraph about globbing into a regular paragraph as I don't think
it should be called out in a note block.

Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
---
 documentation/ref-manual/variables.rst | 15 +++++++++------
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst
index c2e75d0..ade7c03 100644
--- a/documentation/ref-manual/variables.rst
+++ b/documentation/ref-manual/variables.rst
@@ -1213,12 +1213,10 @@ system and gives an overview of their function and contents.
       packages for all the packages explicitly (or implicitly) installed in
       an image.
 
-      .. note::
-
-         The :term:`COMPLEMENTARY_GLOB` variable uses Unix filename pattern matching
-         (`fnmatch <https://docs.python.org/3/library/fnmatch.html#module-fnmatch>`__),
-         which is similar to the Unix style pathname pattern expansion
-         (`glob <https://docs.python.org/3/library/glob.html>`__).
+      The :term:`COMPLEMENTARY_GLOB` variable uses Unix filename pattern matching
+      (`fnmatch <https://docs.python.org/3/library/fnmatch.html#module-fnmatch>`__),
+      which is similar to the Unix style pathname pattern expansion
+      (`glob <https://docs.python.org/3/library/glob.html>`__).
 
       The resulting list of complementary packages is associated with an
       item that can be added to
@@ -1233,6 +1231,11 @@ system and gives an overview of their function and contents.
 
          COMPLEMENTARY_GLOB[dev-pkgs] = '*-dev'
 
+      .. note::
+
+         When installing complementary packages, recommends relationships
+         (set via :term:`RRECOMMENDS`) are always ignored.
+
    :term:`COMPONENTS_DIR`
       Stores sysroot components for each recipe. The OpenEmbedded build
       system uses :term:`COMPONENTS_DIR` when constructing recipe-specific
-- 
1.8.3.1

[PATCH 25/34] ref-manual: remove reference to largefile in DISTRO_FEATURES

[Paul Eggleton]

From: Paul Eggleton <paul.eggleton@microsoft.com>

This no longer does anything in 4.1.

Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
---
 documentation/ref-manual/features.rst | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/documentation/ref-manual/features.rst b/documentation/ref-manual/features.rst
index 9dc73db..dad871d 100644
--- a/documentation/ref-manual/features.rst
+++ b/documentation/ref-manual/features.rst
@@ -152,9 +152,6 @@ metadata, as extra layers can define their own:
 -  *keyboard:* Include keyboard support (e.g. keymaps will be loaded
    during boot).
 
--  *largefile:* Enable building applications with
-   `argefile support <https://en.wikipedia.org/wiki/Large-file_support>`__.
-
 -  *multiarch:* Enable building applications with multiple architecture
    support.
 
-- 
1.8.3.1

[PATCH 26/34] ref-manual: add missing features

[Paul Eggleton]

From: Paul Eggleton <paul.eggleton@microsoft.com>

Add missing IMAGE_FEATURES, DISTRO_FEATURES and MACHINE_FEATURES items.
Additionally, add a note that DISTRO_FEATURES doesn't have any impact on
the kernel configuration so that users are aware they have to take care
of that as well. (I thought the same was true of MACHINE_FEATURES, but
it seems we have a couple of isolated cases where that will adjust the
kernel configuration - few enough that I suspect they might have slipped
in and thus probably shouldn't be documented yet.)

Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
---
 documentation/ref-manual/features.rst | 50 +++++++++++++++++++++++++++++++++++
 1 file changed, 50 insertions(+)

diff --git a/documentation/ref-manual/features.rst b/documentation/ref-manual/features.rst
index dad871d..ea4d257 100644
--- a/documentation/ref-manual/features.rst
+++ b/documentation/ref-manual/features.rst
@@ -72,6 +72,8 @@ Project metadata:
 
 -  *phone:* Mobile phone (voice) support
 
+-  *qemu-usermode:* QEMU can support user-mode emulation for this machine
+
 -  *qvga:* Machine has a QVGA (320x240) display
 
 -  *rtc:* Machine has a Real-Time Clock
@@ -112,6 +114,13 @@ configuration level. See the
 :term:`COMBINED_FEATURES` variable for more
 information.
 
+.. note::
+
+   :term:`DISTRO_FEATURES` is normally independent of kernel configuration,
+   so if a feature specified in :term:`DISTRO_FEATURES` also relies on
+   support in the kernel, you will also need to ensure that support is
+   enabled in the kernel configuration.
+
 This list only represents features as shipped with the Yocto Project
 metadata, as extra layers can define their own:
 
@@ -143,6 +152,9 @@ metadata, as extra layers can define their own:
 -  *ext2:* Include tools for supporting for devices with internal
    HDD/Microdrive for storing files (instead of Flash only devices).
 
+-  *gobject-introspection-data:* Include data to support
+   `GObject Introspection <https://gi.readthedocs.io/en/latest/>`__.
+
 -  *ipsec:* Include IPSec support.
 
 -  *ipv4:* Include IPv4 support.
@@ -155,23 +167,38 @@ metadata, as extra layers can define their own:
 -  *multiarch:* Enable building applications with multiple architecture
    support.
 
+-  *ld-is-gold:* Use the `gold <https://en.wikipedia.org/wiki/Gold_(linker)>`__
+   linker instead of the standard GCC linker (bfd).
+
 -  *ldconfig:* Include support for ldconfig and ``ld.so.conf`` on the
    target.
 
+-  *lto:* Enable `Link-Time Optimisation <https://gcc.gnu.org/wiki/LinkTimeOptimization>`__.
+
 -  *nfc:* Include support for
    `Near Field Communication <https://en.wikipedia.org/wiki/Near-field_communication>`__.
 
 -  *nfs:* Include NFS client support (for mounting NFS exports on
    device).
 
+-  *nls:* Include National Language Support (NLS).
+
 -  *opengl:* Include the Open Graphics Library, which is a
    cross-language, multi-platform application programming interface used
    for rendering two and three-dimensional graphics.
 
+-  *overlayfs:* Include `OverlayFS <https://docs.kernel.org/filesystems/overlayfs.html>`__
+   support.
+
+-  *pam:* Include `Pluggable Authentication Module (PAM) <https://en.wikipedia.org/wiki/Pluggable_authentication_module>`__
+   support.
+
 -  *pci:* Include PCI bus support.
 
 -  *pcmcia:* Include PCMCIA/CompactFlash support.
 
+-  *polkit:* Include `Polkit <https://en.wikipedia.org/wiki/Polkit>`__ support.
+
 -  *ppp:* Include PPP dialup support.
 
 -  *ptest:* Enables building the package tests where supported by
@@ -179,6 +206,13 @@ metadata, as extra layers can define their own:
    ":ref:`dev-manual/common-tasks:testing packages with ptest`" section
    in the Yocto Project Development Tasks Manual.
 
+-  *pulseaudio:* Include support for
+   `PulseAudio <https://www.freedesktop.org/wiki/Software/PulseAudio/>`__.
+
+-  *selinux:* Include support for
+   `Security-Enhanced Linux (SELinux) <https://en.wikipedia.org/wiki/Security-Enhanced_Linux>`__
+   (requires `meta-selinux <https://layers.openembedded.org/layerindex/layer/meta-selinux/>`__).
+
 -  *seccomp:* Enables building applications with
    `seccomp <https://en.wikipedia.org/wiki/Seccomp>`__ support, to
    allow them to strictly restrict the system calls that they are allowed
@@ -270,6 +304,9 @@ Here are the image features available for all images:
        just disables the mechanism which forces an non-empty password for the
        root user.
 
+-  *lic-pkgs:* Installs license packages for all packages installed in a
+   given image.
+
 -  *overlayfs-etc:* Configures the ``/etc`` directory to be in ``overlayfs``.
    This allows to store device specific information elsewhere, especially
    if the root filesystem is configured to be read-only.
@@ -294,6 +331,12 @@ Here are the image features available for all images:
    section in the Yocto Project Development Tasks Manual for more
    information.
 
+-  *read-only-rootfs-delayed-postinsts:* when specified in conjunction
+   with ``read-only-rootfs``, specifies that post-install scripts are
+   still permitted (this assumes that the root filesystem will be made
+   writeable for the first boot; this feature does not do anything to
+   ensure that - it just disables the check for post-install scripts.)
+
 -  *splash:* Enables showing a splash screen during boot. By default,
    this screen is provided by ``psplash``, which does allow
    customization. If you prefer to use an alternative splash screen
@@ -301,6 +344,11 @@ Here are the image features available for all images:
    different package name (or names) within the image recipe or at the
    distro configuration level.
 
+-  *stateless-rootfs:*: specifies that the image should be created as
+   stateless - when using ``systemd``, ``systemctl-native`` will not
+   be run on the image, leaving the image for population at runtime by
+   systemd.
+
 -  *staticdev-pkgs:* Installs static development packages, which are
    static libraries (i.e. ``*.a`` files), for all packages installed in
    a given image.
@@ -351,6 +399,8 @@ these valid features is as follows:
 -  *tools-testapps:* Installs device testing tools (e.g. touchscreen
    debugging).
 
+-  *weston:* Installs Weston (reference Wayland environment).
+
 -  *x11:* Installs the X server.
 
 -  *x11-base:* Installs the X server with a minimal environment.
-- 
1.8.3.1

[PATCH 27/34] ref-manual: add serial-autologin-root to IMAGE_FEATURES documentation

[Paul Eggleton]

From: Paul Eggleton <paul.eggleton@microsoft.com>

New IMAGE_FEATURES item in 4.1.

Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
---
 documentation/ref-manual/features.rst | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/documentation/ref-manual/features.rst b/documentation/ref-manual/features.rst
index ea4d257..a5b01e8 100644
--- a/documentation/ref-manual/features.rst
+++ b/documentation/ref-manual/features.rst
@@ -337,6 +337,12 @@ Here are the image features available for all images:
    writeable for the first boot; this feature does not do anything to
    ensure that - it just disables the check for post-install scripts.)
 
+-  *serial-autologin-root:* when specified in conjunction with
+   ``empty-root-password`` will automatically login as root on the
+   serial console. This of course opens up a security hole if the
+   serial console is potentially accessible to an attacker, so use
+   with caution.
+
 -  *splash:* Enables showing a splash screen during boot. By default,
    this screen is provided by ``psplash``, which does allow
    customization. If you prefer to use an alternative splash screen
-- 
1.8.3.1

[PATCH 28/34] ref-manual: add previous overlayfs-etc variables

[Paul Eggleton]

From: Paul Eggleton <paul.eggleton@microsoft.com>

These were supported in releases prior to 4.1.

Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
---
 documentation/ref-manual/variables.rst | 38 ++++++++++++++++++++++++++++++++++
 1 file changed, 38 insertions(+)

diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst
index ade7c03..9c510b8 100644
--- a/documentation/ref-manual/variables.rst
+++ b/documentation/ref-manual/variables.rst
@@ -5229,6 +5229,44 @@ system and gives an overview of their function and contents.
       default by setting the variable in a custom distribution
       configuration file.
 
+   :term:`OVERLAYFS_ETC_DEVICE`
+      When the :ref:`overlayfs-etc <ref-classes-overlayfs-etc>` class is
+      inherited, specifies the device to be mounted for the read/write
+      layer of ``/etc``. There is no default, so you must set this if you
+      wish to enable :ref:`overlayfs-etc <ref-classes-overlayfs-etc>`, for
+      example, assuming ``/dev/mmcblk0p2`` was the desired device::
+
+         OVERLAYFS_ETC_DEVICE = "/dev/mmcblk0p2"
+
+   :term:`OVERLAYFS_ETC_FSTYPE`
+      When the :ref:`overlayfs-etc <ref-classes-overlayfs-etc>` class is
+      inherited, specifies the file system type for the read/write
+      layer of ``/etc``. There is no default, so you must set this if you
+      wish to enable :ref:`overlayfs-etc <ref-classes-overlayfs-etc>`,
+      for example, assuming the file system is ext4::
+
+         OVERLAYFS_ETC_FSTYPE = "ext4"
+
+   :term:`OVERLAYFS_ETC_MOUNT_OPTIONS`
+      When the :ref:`overlayfs-etc <ref-classes-overlayfs-etc>` class is
+      inherited, specifies the mount options for the read-write layer.
+      The default value is "defaults".
+
+   :term:`OVERLAYFS_ETC_MOUNT_POINT`
+      When the :ref:`overlayfs-etc <ref-classes-overlayfs-etc>` class is
+      inherited, specifies the parent mount path for the filesystem layers.
+      There is no default, so you must set this if you wish to enable
+      :ref:`overlayfs-etc <ref-classes-overlayfs-etc>`, for example if
+      the desired path is "/data"::
+
+         OVERLAYFS_ETC_MOUNT_POINT = "/data"
+
+   :term:`OVERLAYFS_ETC_USE_ORIG_INIT_NAME`
+      When the :ref:`overlayfs-etc <ref-classes-overlayfs-etc>` class is
+      inherited, controls how the generated init will be named. For more
+      information, see the :ref:`overlayfs-etc <ref-classes-overlayfs-etc>`
+      class documentation. The default value is "1".
+
    :term:`OVERRIDES`
       A colon-separated list of overrides that currently apply. Overrides
       are a BitBake mechanism that allows variables to be selectively
-- 
1.8.3.1

[PATCH 29/34] ref-manual: add OVERLAYFS_ETC_EXPOSE_LOWER

[Paul Eggleton]

From: Paul Eggleton <paul.eggleton@microsoft.com>

New variable in 4.1.

Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
---
 documentation/ref-manual/variables.rst | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst
index 9c510b8..503926b 100644
--- a/documentation/ref-manual/variables.rst
+++ b/documentation/ref-manual/variables.rst
@@ -5238,6 +5238,12 @@ system and gives an overview of their function and contents.
 
          OVERLAYFS_ETC_DEVICE = "/dev/mmcblk0p2"
 
+   :term:`OVERLAYFS_ETC_EXPOSE_LOWER`
+      When the :ref:`overlayfs-etc <ref-classes-overlayfs-etc>` class is
+      inherited, if set to "1" then a read-only access to the original
+      ``/etc`` content will be provided as a ``lower/`` subdirectory of
+      :term:`OVERLAYFS_ETC_MOUNT_POINT`. The default value is "0".
+
    :term:`OVERLAYFS_ETC_FSTYPE`
       When the :ref:`overlayfs-etc <ref-classes-overlayfs-etc>` class is
       inherited, specifies the file system type for the read/write
-- 
1.8.3.1

[PATCH 30/34] ref-manual: add WIRELESS_DAEMON

[Paul Eggleton]

From: Paul Eggleton <paul.eggleton@microsoft.com>

Not new in 4.1, but the syntax and usage in packagegroup-base is.

Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
---
 documentation/ref-manual/variables.rst | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst
index 503926b..a14288e 100644
--- a/documentation/ref-manual/variables.rst
+++ b/documentation/ref-manual/variables.rst
@@ -9027,6 +9027,11 @@ system and gives an overview of their function and contents.
       Specifies the timeout in seconds used by the ``watchdog`` recipe and
       also by ``systemd`` during reboot. The default is 60 seconds.
 
+   :term:`WIRELESS_DAEMON`
+      For ``connman`` and ``packagegroup-base``, specifies the wireless
+      daemon to use. The default is "wpa-supplicant" (note that the value
+      uses a dash and not an underscore).
+
    :term:`WKS_FILE`
       Specifies the location of the Wic kickstart file that is used by the
       OpenEmbedded build system to create a partitioned image
-- 
1.8.3.1

[PATCH 31/34] ref-manual: add section for create-spdx class

[Paul Eggleton]

From: Paul Eggleton <paul.eggleton@microsoft.com>

create-spdx was added in the honister release. This is a stub since I
unfortunately don't have time to fully document this class and related
variables, hopefully someone else can expand it in future.

Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
---
 documentation/ref-manual/classes.rst | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/documentation/ref-manual/classes.rst b/documentation/ref-manual/classes.rst
index 652c2f3..dad78ef 100644
--- a/documentation/ref-manual/classes.rst
+++ b/documentation/ref-manual/classes.rst
@@ -368,6 +368,14 @@ authors used.
 Both build methods inherit the ``cpan-base`` class for basic Perl
 support.
 
+.. _ref-classes-create-spdx:
+
+``create-spdx.bbclass``
+=======================
+
+The ``create-spdx`` class provides support for automatically creating
+SPDX SBoM documents based upon image and SDK contents.
+
 .. _ref-classes-cross:
 
 ``cross.bbclass``
-- 
1.8.3.1

[PATCH 32/34] ref-manual: add overlayfs class variables

[Paul Eggleton]

From: Paul Eggleton <paul.eggleton@microsoft.com>

The overlayfs class was added in the honister release.

Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
---
 documentation/ref-manual/variables.rst | 24 ++++++++++++++++++++++++
 1 file changed, 24 insertions(+)

diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst
index a14288e..00d51e5 100644
--- a/documentation/ref-manual/variables.rst
+++ b/documentation/ref-manual/variables.rst
@@ -5273,6 +5273,30 @@ system and gives an overview of their function and contents.
       information, see the :ref:`overlayfs-etc <ref-classes-overlayfs-etc>`
       class documentation. The default value is "1".
 
+   :term:`OVERLAYFS_MOUNT_POINT`
+      When inheriting the :ref:`overlayfs <ref-classes-overlayfs>` class,
+      specifies mount point(s) to be used. For example::
+
+         OVERLAYFS_MOUNT_POINT[data] = "/data"
+
+      The assumes you have a ``data.mount`` systemd unit defined elsewhere
+      in your BSP (e.g. in ``systemd-machine-units`` recipe) and it is
+      installed into the image. For more information see
+      :ref:`overlayfs <ref-classes-overlayfs>`.
+
+      .. note::
+
+         Although the :ref:`overlayfs <ref-classes-overlayfs>` class is
+         inherited by individual recipes, :term:`OVERLAYFS_MOUNT_POINT`
+         should be set in your machine configuration.
+
+   :term:`OVERLAYFS_WRITABLE_PATHS`
+      When inheriting the :ref:`overlayfs <ref-classes-overlayfs>` class,
+      specifies writable paths used at runtime for the recipe. For
+      example::
+
+         OVERLAYFS_WRITABLE_PATHS[data] = "/usr/share/my-custom-application"
+
    :term:`OVERRIDES`
       A colon-separated list of overrides that currently apply. Overrides
       are a BitBake mechanism that allows variables to be selectively
-- 
1.8.3.1

[PATCH 33/34] ref-manual: add OVERLAYFS_QA_SKIP

[Paul Eggleton]

From: Paul Eggleton <paul.eggleton@microsoft.com>

New variable in 4.1.

Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
---
 documentation/ref-manual/variables.rst | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst
index 00d51e5..c5ab0ff 100644
--- a/documentation/ref-manual/variables.rst
+++ b/documentation/ref-manual/variables.rst
@@ -5290,6 +5290,19 @@ system and gives an overview of their function and contents.
          inherited by individual recipes, :term:`OVERLAYFS_MOUNT_POINT`
          should be set in your machine configuration.
 
+   :term:`OVERLAYFS_QA_SKIP`
+      When inheriting the :ref:`overlayfs <ref-classes-overlayfs>` class,
+      provides the ability to disable QA checks for particular overlayfs
+      mounts. For example::
+
+         OVERLAYFS_QA_SKIP[data] = "mount-configured"
+
+      .. note::
+
+         Although the :ref:`overlayfs <ref-classes-overlayfs>` class is
+         inherited by individual recipes, :term:`OVERLAYFS_QA_SKIP`
+         should be set in your machine configuration.
+
    :term:`OVERLAYFS_WRITABLE_PATHS`
       When inheriting the :ref:`overlayfs <ref-classes-overlayfs>` class,
       specifies writable paths used at runtime for the recipe. For
-- 
1.8.3.1

[PATCH 34/34] Add 4.1 migration guide & release notes

[Paul Eggleton]

From: Paul Eggleton <paul.eggleton@microsoft.com>

This currently does not include known issues or download information.

Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
---
 documentation/migration-guides/index.rst           |   1 +
 documentation/migration-guides/migration-4.1.rst   | 214 +++++++
 documentation/migration-guides/release-4.1.rst     |   7 +
 .../migration-guides/release-notes-4.1.rst         | 687 +++++++++++++++++++++
 4 files changed, 909 insertions(+)
 create mode 100644 documentation/migration-guides/migration-4.1.rst
 create mode 100644 documentation/migration-guides/release-4.1.rst
 create mode 100644 documentation/migration-guides/release-notes-4.1.rst

diff --git a/documentation/migration-guides/index.rst b/documentation/migration-guides/index.rst
index 4597506..ce0ca8c 100644
--- a/documentation/migration-guides/index.rst
+++ b/documentation/migration-guides/index.rst
@@ -12,6 +12,7 @@ to move to one release of the Yocto Project from the previous one.
 .. toctree::
 
    migration-general
+   release-4.1
    release-4.0
    release-3.4
    migration-3.3
diff --git a/documentation/migration-guides/migration-4.1.rst b/documentation/migration-guides/migration-4.1.rst
new file mode 100644
index 0000000..bb8c6dd
--- /dev/null
+++ b/documentation/migration-guides/migration-4.1.rst
@@ -0,0 +1,214 @@
+Release 4.1 (langdale)
+======================
+
+Migration notes for 4.1 (langdale)
+-----------------------------------
+
+This section provides migration information for moving to the Yocto
+Project 4.1 Release (codename "langdale") from the prior release.
+
+
+.. _migration-4.1-make-4.0:
+
+make 4.0 is now the minimum required make version
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+glibc now requires ``make`` 4.0 to build, thus it is now the version required to
+be installed on the build host. A new ``buildtools-make-tarball`` has been
+introduced to provide just make 4.0 for host distros without a current/working
+make 4.x version; if you also need other tools you can use the updated
+``buildtools-tarball``. For more information see
+:ref:`ref-manual/system-requirements:required packages for the build host`.
+
+
+.. _migration-4.1-complementary-deps:
+
+Complementary package installation ignores recommends
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+When installing complementary packages (e.g. ``-dev`` and ``-dbg`` packages when
+building an SDK, or if you have added ``dev-deps`` to :term:`IMAGE_FEATURES`),
+recommends (as defined by :term:`RRECOMMENDS`) are no longer installed.
+
+If you wish to double-check the contents of your images after this change, see
+:ref:`Checking Image / SDK Changes <migration-general-buildhistory>`. If needed
+you can explicitly install items by adding them to :term:`IMAGE_INSTALL` in
+image recipes or :term:`TOOLCHAIN_TARGET_TASK` for the SDK.
+
+
+.. _migration-4.1-dev-recommends:
+
+dev dependencies are now recommends
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The default for ``${PN}-dev`` package is now to use :term:`RRECOMMENDS` instead
+of :term:`RDEPENDS` to pull in the main package. This takes advantage of a
+change to complimentary package installation to not follow :term:`RRECOMMENDS`
+(as mentioned above) and for example means an SDK for an image with both openssh
+and dropbear components will now build successfully.
+
+
+.. _migration-4.1-dropbear-sftp:
+
+dropbear now recommends openssh-sftp-server
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+openssh has switched the scp client to use the sftp protocol instead of scp to
+move files. This means scp from Fedora 36 and other current distributions will
+no longer be able to move files to/from a system running dropbear with no sftp
+server installed.
+
+The sftp server from openssh is small (200kb uncompressed) and standalone, so
+adding it to the packagegroup seems to be the best way to preserve the
+functionality for user sanity. However, if you wish to avoid this dependency,
+you can either:
+
+ A. Use ``dropbear`` in :term:`IMAGE_INSTALL` instead of
+    ``packagegroup-core-ssh-dropbear`` (or ``ssh-server-dropbear`` in
+    :term:`IMAGE_FEATURES`), or
+ B. Add ``openssh-sftp-server`` to :term:`BAD_RECOMMENDATIONS`.
+
+
+.. _migration-4.1-classes-split:
+
+Classes now split by usage context
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+A split directory structure has now been set up for ``.bbclass`` files - classes
+that are intended to be inherited only by recipes (e.g. ``inherit`` in a recipe
+file, :term:`IMAGE_CLASSES` or :term:`KERNEL_CLASSES`) should be in a
+``classes-recipe`` subdirectory and classes that are intended to be inherited
+globally (e.g. via ``INHERIT +=``, :term:`PACKAGE_CLASSES`, :term:`USER_CLASSES`
+or :term:`INHERIT_DISTRO`) should be in ``classes-global``. Classes in the
+existing ``classes`` subdirectory will continue to work in any context as before.
+
+Other than knowing where to look when manually browsing the class files, this is
+not likely to require any changes to your configuration. However, if in your
+configuration you were using some classes in the incorrect context, you will now
+receive an error during parsing. For example, the following in ``local.conf`` will
+now cause an error::
+
+   INHERIT += "testimage"
+
+Since :ref:`testimage <ref-classes-testimage>` is a class intended solely to
+affect image recipes, this would be correctly specified as::
+
+   IMAGE_CLASSES += "testimage"
+
+
+.. _migration-4.1-local-file-error:
+
+Missing local files in SRC_URI now triggers an error
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+If a file referenced in :term:`SRC_URI` does not exist, in 4.1 this will trigger
+an error at parse time where previously this only triggered a warning. In the past
+you could ignore these warnings for example if you have multiple build
+configurations (e.g. for several different target machines) and there were recipes
+that you were not building in one of the configurations. If you have this scenario
+you will now need to conditionally add entries to :term:`SRC_URI` where they are
+valid, or use :term:`COMPATIBLE_MACHINE` / :term:`COMPATIBLE_HOST` to prevent the
+recipe from being available (and therefore avoid it being parsed) in configurations
+where the files aren't available.
+
+
+.. _migration-4.1-qa-checks:
+
+QA check changes
+~~~~~~~~~~~~~~~~
+
+- The :ref:`buildpaths <qa-check-buildpaths>` QA check is now enabled by default
+  in :term:`WARN_QA`, and thus any build system paths found in output files will
+  trigger a warning. If you see these warnings for your own recipes, for full
+  binary reproducibility you should make the necessary changes to the recipe build
+  to remove these paths. If you wish to disable the warning for a particular
+  recipe you can use :term:`INSANE_SKIP`, or for the entire build you can adjust
+  :term:`WARN_QA`. For more information, see the :ref:`buildpaths QA check
+  <qa-check-buildpaths>` section.
+
+- ``do_qa_staging`` now checks shebang length in all directories specified by
+  :term:`SYSROOT_DIRS`, since there is a maximum length defined in the kernel. For
+  native recipes which write scripts to the sysroot, if the shebang line in one of
+  these scripts is too long you will get an error. This can be skipped using
+  :term:`INSANE_SKIP` if necessary, but the best course of action is of course to
+  fix the script. There is now also a ``create_cmdline_shebang_wrapper`` function
+  that you can call e.g. from ``do_install`` (or ``do_install:append``) within a
+  recipe to create a wrapper to fix such scripts - see the ``libcheck`` recipe
+  for an example usage.
+
+
+
+Miscellaneous changes
+~~~~~~~~~~~~~~~~~~~~~
+
+- ``mount.blacklist`` has been renamed to ``mount.ignorelist`` in
+  ``udev-extraconf``. If you are customising this file via ``udev-extraconf`` then
+  you will need to update your ``udev-extraconf`` ``.bbappend`` as appropriate.
+- ``help2man-native`` has been removed from implicit sysroot dependencies. If a
+  recipe needs ``help2man-native`` it should now be explicitly added to
+  :term:`DEPENDS` within the recipe.
+- For images using systemd, the reboot watchdog timeout has been set to 60
+  seconds (from the upstream default of 10 minutes). If you wish to override this
+  you can set :term:`WATCHDOG_TIMEOUT` to the desired timeout in seconds. Note
+  that the same :term:`WATCHDOG_TIMEOUT` variable also specifies the timeout used
+  for the ``watchdog`` tool (if that is being built).
+- The :ref:`image-buildinfo <ref-classes-image-buildinfo>` class now writes to
+  ``${sysconfdir}/buildinfo`` instead of ``${sysconfdir}/build`` by default (i.e.
+  the default value of :term:`IMAGE_BUILDINFO_FILE` has been changed). If you have
+  code that reads this from images at build or runtime you will need to update it
+  or specify your own value for :term:`IMAGE_BUILDINFO_FILE`.
+- In the :ref:`archiver <ref-classes-archiver>` class, the default
+  ``ARCHIVER_OUTDIR`` value no longer includes the :term:`MACHINE` value in order
+  to avoid the archive task running multiple times in a multiconfig setup. If you
+  have custom code that does something with the files archived by the
+  :ref:`archiver <ref-classes-archiver>` class then you may need to adjust it to
+  the new structure.
+- If you are not using `systemd` then udev is now configured to use labels
+  (``LABEL`` or ``PARTLABEL``) to set the mount point for the device. For example::
+
+    /run/media/rootfs-sda2
+
+  instead of::
+
+    /run/media/sda2
+
+- ``icu`` no longer provides the ``icu-config`` configuration tool - upstream
+  have indicated ``icu-config`` is deprecated and should no longer be used. Code
+  with references to it will need to be updated, for example to use ``pkg-config``
+  instead.
+- The ``rng-tools`` systemd service name has changed from ``rngd`` to ``rng-tools``
+- The ``largefile`` :term:`DISTRO_FEATURES` item has been removed, large file
+  support is now always enabled where it was previously optional.
+- The Python ``zoneinfo`` module is now split out to its own ``python3-zoneinfo``
+  package.
+- The :term:`PACKAGECONFIG` option to enable wpa_supplicant in the ``connman``
+  recipe has been renamed to "wpa-supplicant". If you have set PACKAGECONFIG for
+  the ``connman`` recipe to include this option you will need to update
+  your configuration. Related to this, the :term:`WIRELESS_DAEMON` variable
+  now expects the new ``wpa-supplicant`` naming and affects ``packagegroup-base``
+  as well as ``connman``.
+- The ``wpa-supplicant`` recipe no longer uses a static (and stale) ``defconfig``
+  file, instead it uses the upstream version with appropriate edits for the
+  :term:`PACKAGECONFIG`. If you are customising this file you will need to
+  update your customisations.
+- With the introduction of picobuild in
+  :ref:`python_pep517 <ref-classes-python_pep517>`, The ``PEP517_BUILD_API``
+  variable is no longer supported. If you have any references to this variable
+  you should remove them.
+
+
+.. _migration-4.1-removed-recipes:
+
+Removed recipes
+~~~~~~~~~~~~~~~
+
+The following recipes have been removed in this release:
+
+- ``alsa-utils-scripts``: merged into alsa-utils
+- ``cargo-cross-canadian``: optimised out
+- ``lzop``: obsolete, unmaintained upstream
+- ``linux-yocto (5.10)``: 5.15 and 5.19 are currently provided
+- ``rust-cross``: optimised out
+- ``rust-crosssdk``: optimised out
+- ``rust-tools-cross-canadian``: optimised out
+- ``xf86-input-keyboard``: obsolete (replaced by libinput/evdev)
diff --git a/documentation/migration-guides/release-4.1.rst b/documentation/migration-guides/release-4.1.rst
new file mode 100644
index 0000000..8ebf4a4
--- /dev/null
+++ b/documentation/migration-guides/release-4.1.rst
@@ -0,0 +1,7 @@
+Release 4.1 (langdale)
+======================
+
+.. toctree::
+
+   migration-4.1
+   release-notes-4.1
diff --git a/documentation/migration-guides/release-notes-4.1.rst b/documentation/migration-guides/release-notes-4.1.rst
new file mode 100644
index 0000000..4639d04
--- /dev/null
+++ b/documentation/migration-guides/release-notes-4.1.rst
@@ -0,0 +1,687 @@
+Release notes for 4.1 (langdale)
+---------------------------------
+
+
+New Features / Enhancements in 4.1
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+- Linux kernel 5.19, glibc 2.36 and ~260 other recipe upgrades
+
+- ``make`` 4.0 is now the minimum make version required on the build host.
+  For host distros that do not provide it, this is included as part of the
+  ``buildtools-tarball``, and additionally a new ``buildtools-make-tarball``
+  has been introduced to provide this in particular for host distros with
+  a broken make 4.x version. For more details see
+  :ref:`ref-manual/system-requirements:required git, tar, python, make and gcc versions`.
+
+- New layer setup tooling:
+
+  - New ``scripts/oe-setup-layers`` standalone script to restore the layer
+    configuration from a json file
+  - New ``bitbake-layers create-layers-setup destdir`` command to save the
+    layer configuration to a json file
+  - New ``bitbake-layers save-build-conf`` command to save the active build
+    configuration as a template into a layer
+
+- Rust-related enhancements:
+
+  - Support for building rust for the target
+  - Significant SDK toolchain build optimisation
+  - Support for building native components in the SDK
+  - Support ``crate://`` fetcher with :ref:`externalsrc <ref-classes-externalsrc>`
+
+- New core recipes:
+
+  - ``buildtools-make-tarball``
+  - ``icon-naming-utils`` (previously removed)
+  - ``musl-locales``
+  - ``python3-editables`` (originally in meta-python)
+  - ``python3-hatch-vcs``
+  - ``python3-hatchling`` (originally in meta-oe)
+  - ``python3-lxml`` (originally in meta-python)
+  - ``python3-pathspec`` (originally in meta-python)
+  - ``python3-picobuild``
+  - ``sato-icon-theme`` (previously removed)
+
+- CVE checking enhancements:
+
+  - New :term:`CVE_DB_UPDATE_INTERVAL` variable to allow specifying the CVE database minimum update interval (and default to once per day)
+  - Added JSON format to summary output
+  - Added support for Ignored CVEs
+  - Enable recursive CVE checking also for ``do_populate_sdk``
+  - New :term:`CVE_CHECK_SHOW_WARNINGS` variable to disable unpatched CVE warning messages
+  - The :ref:`pypi <ref-classes-pypi>` class now defaults :term:`CVE_PRODUCT` from :term:`PYPI_PACKAGE`
+  - Added current kernel CVEs to ignore list since we stay as close to the kernel stable releases as we can
+  - Optimisations to avoid dependencies on fetching
+
+- Complementary package installation (as used in SDKs and images) no longer installs recommended packages, in order to avoid conflicts
+- Dependency of -dev package on main package is now an :term:`RRECOMMENDS` and can be easily set via new :term:`DEV_PKG_DEPENDENCY` variable
+
+- Support for CPU, I/O and memory pressure regulation in BitBake
+- Pressure data gathering in ``buildstats`` and rendering in ``pybootchartgui``
+
+- New Picobuild system for lightweight Python PEP-517 build support in the :ref:`python_pep517 <ref-classes-python_pep517>` class
+
+- Many classes are now split into global and recipe contexts for better
+  validation. For more information, see
+  :ref:`Classes now split by usage context <migration-4.1-classes-split>`.
+
+-  Architecture-specific enhancements:
+
+   - arch-armv8-4a.inc: add tune include for armv8.4a
+   - tune-neoversen2: support tune-neoversen2 base on armv9a
+   - riscv: Add tunes for rv64 without compressed instructions
+   - gnu-efi: enable for riscv64
+   - shadow-securetty: allow ttyS4 for amd-snowyowl-64
+
+-  Kernel-related enhancements:
+
+   - linux-yocto/5.15: cfg/xen: Move x86 configs to separate file
+   - linux-yocto/5.15: Enabled MDIO bus config
+   - linux-yocto: Enable mdio for qemu
+   - linux-yocto/5.15: base: enable kernel crypto userspace API
+   - kern-tools: allow 'y' or 'm' to avoid config audit warnings
+   - kernel-yocto.bbclass: say what SRC_URI entry is being dropped
+   - kernel.bbclass: Do not overwrite recipe's custom postinst
+   - kmod: Enable xz support by default
+   - Run depmod(wrapper) against each compiled kernel when multiple kernels are enabled
+   - linux-yocto-tiny: enable qemuarmv5/qemuarm64
+
+-  wic Image Creator enhancements:
+
+   - Added dependencies to support erofs
+   - Added ``fspassno`` parameter to partition to allow specifying the value of the last column (``fs_passno``) in ``/etc/fstab``.
+   - bootimg-efi: added support for loading devicetree files
+   - Added ``none`` fstype for custom image (for use in conjunction with ``rawcopy``)
+
+-  SDK-related enhancements:
+
+   - :ref:`Support for using the regular build system as an SDK <sdk-manual/extensible:Setting up the Extensible SDK environment directly in a Yocto build>`
+   - :ref:`image-buildinfo <ref-classes-image-buildinfo>` class now also writes build information to SDKs
+   - New :term:`SDK_TOOLCHAIN_LANGS` variable to control support of rust / go in SDK
+   - rust-llvm: enabled nativesdk variant
+   - python3-pluggy: enabled for native/nativesdk
+
+-  QEMU/runqemu enhancements:
+
+   - qemux86-64: Allow higher tunes
+   - runqemu: display host uptime when starting
+   - runqemu: add ``QB_KERNEL_CMDLINE`` that can be set to "none" to avoid overriding kernel command line specified in dtb
+
+-  Image-related enhancements:
+
+   - New variable :term:`UBOOT_MKIMAGE_KERNEL_TYPE`
+   - New variable :term:`FIT_PAD_ALG` to control FIT image padding algorithm
+   - New :term:`KERNEL_DEPLOY_DEPEND` variable to allow disabling image dependency on deploying the kernel
+   - image_types: isolate the write of UBI configuration to a ``write_ubi_config`` function that can be easily overridden
+
+- openssh: add support for config snippet includes to ssh and sshd
+- :ref:`create-spdx <ref-classes-create-spdx>`: Add ``SPDX_PRETTY`` option
+- wpa-supplicant: build static library if not disabled via :term:`DISABLE_STATIC`
+- wpa-supplicant: package dynamic modules
+- openssl: extract legacy provider module to a separate package
+- linux-firmware: split out ath3k firmware
+- linux-firmware: add support for building snapshots
+- eudev: create static-nodes in init script
+- udev-extraconf: new :term:`MOUNT_BASE` variable allows configuring automount base directory
+- udev-extraconf/mount.sh: use partition labels in mountpoint paths
+- systemd: Set RebootWatchdogSec to 60s by default
+- systemd: systemd-systemctl: Support instance conf files during enable
+- weston.init: enable ``xwayland`` in weston.ini if ``x11`` is in :term:`DISTRO_FEATURES`
+- New ``npm_registry`` Python module to enable caching with nodejs 16+
+- :ref:`npm <ref-classes-npm>`: replaced ``npm pack`` call with ``tar czf`` for nodejs 16+ compatibility and improved ``do_configure`` performance
+- Enabled :ref:`bin_package <ref-classes-bin-package>` class to work properly in the native case
+- Enabled :ref:`buildpaths <qa-check-buildpaths>` QA check as a warning by default
+- New :term:`OVERLAYFS_ETC_EXPOSE_LOWER` to provide read-only access to the original ``/etc`` content with :ref:`overlayfs-etc <ref-classes-overlayfs-etc>`
+- New :term:`OVERLAYFS_QA_SKIP` variable to allow skipping check on :ref:`overlayfs <ref-classes-overlayfs>` mounts
+- New :term:`PACKAGECONFIG` options for individual recipes:
+
+   - apr: xsi-strerror
+   - btrfs-tools: lzo
+   - connman: iwd
+   - coreutils: openssl
+   - dropbear: enable-x11-forwarding
+   - eudev: blkid, kmod, rule-generator
+   - eudev: manpages, selinux
+   - flac: avx, ogg
+   - gnutls: fips
+   - gstreamer1.0-plugins-bad: avtp
+   - libsdl2: libusb
+   - llvm: optviewer
+   - mesa: vulkan, vulkan-beta, zink
+   - perf: bfd
+   - piglit: glx, opencl
+   - python3: editline
+   - qemu: bpf, brlapi, capstone, rdma, slirp, uring, vde
+   - rpm: readline
+   - ruby: capstone
+   - systemd: no-dns-fallback, sysext
+   - tiff: jbig
+
+- ptest enhancements in ``curl``, ``json-c``, ``libgcrypt``, ``libgpg-error``, ``libxml2``
+- ptest compile/install functions now use :term:`PARALLEL_MAKE` and :term:`PARALLEL_MAKEINST` in ptest for significant speedup
+- New :term:`TC_CXX_RUNTIME` variable to enable other layers to more easily control C++ runtime
+- Set :term:`BB_DEFAULT_UMASK` using ??= to make it easier to override
+- Set :term:`TCLIBC` and :term:`TCMODE` using ??= to make them easier to override
+- squashfs-tools: build with lzo support by default
+- insane.bbclass: make ``do_qa_staging`` check shebang length for native scripts in all :term:`SYSROOT_DIRS`
+- utils: Add ``create_cmdline_shebang_wrapper`` function to allow recipes to easily create a wrapper to fix long shebang lines
+- meson: provide relocation script and native/cross wrappers also for meson-native
+- meson.bbclass: add cython binary to cross/native toolchain config
+- New ``musl-locales`` recipe to provide a limited set of locale data for musl based systems
+- gobject-introspection: use ``OBJDUMP`` environment variable so that objdump tool can be picked up from the environment
+- The Python ``zoneinfo`` module is now split out to its own ``python3-zoneinfo`` package.
+- busybox: added devmem 128-bit support
+- vim: split xxd out into its own package
+- New :ref:`github-releases <ref-classes-github-releases>` class to consolidate version checks for github-based packages
+- ``devtool reset`` now preserves ``workspace/sources`` source trees in ``workspace/attic/sources/`` instead of leaving them in-place
+- scripts/patchreview: Add commit to stored json data
+- scripts/patchreview: Make json output human parsable
+- ``wpa-supplicant`` recipe now uses the upstream ``defconfig`` modified based upon :term:`PACKAGECONFIG` instead of a stale ``defconfig`` file
+- bitbake: build: prefix the tasks with a timestamp in the log.task_order
+- bitbake: fetch2/osc: Add support to query latest revision
+- bitbake: utils: Pass lock argument in fileslocked
+- bitbake: utils: Add enable_loopback_networking()
+
+
+Known Issues in 4.1
+~~~~~~~~~~~~~~~~~~~
+
+
+
+Recipe License changes in 4.1
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The following corrections have been made to the LICENSE values set by recipes:
+
+- alsa-state: add GPL-2.0-or-later because of alsa-state-init file
+- git: add GPL-2.0-or-later & BSD-3-Clause & MIT & BSL-1.0 & LGPL-2.1-or-later due to embedded code
+- libgcrypt: dropped GPLv3 license after upstream changes
+- linux-firmware: correct license for ar3k firmware (specific "ar3k" license)
+
+
+
+Security Fixes in 4.1
+~~~~~~~~~~~~~~~~~~~~~
+
+- bind: :cve:`2022-1183`, :cve:`2022-2795`, :cve:`2022-2881`, :cve:`2022-2906`, :cve:`2022-3080`, :cve:`2022-38178`
+- binutils: :cve:`2019-1010204`, :cve:`2022-38126`, :cve:`2022-38127`, :cve:`2022-38128`, :cve:`2022-38533`
+- busybox: :cve:`2022-30065`
+- connman: :cve:`2022-32292`, :cve:`2022-32293`
+- cups: :cve:`2022-26691`
+- e2fsprogs: :cve:`2022-1304`
+- expat: :cve:`2022-40674`
+- freetype: :cve:`2022-27404`
+- glibc: :cve:`2022-39046`
+- gnupg: :cve:`2022-34903`
+- grub2: :cve:`2021-3695`, :cve:`2021-3696`, :cve:`2021-3697`, :cve:`2022-28733`, :cve:`2022-28734`, :cve:`2022-28735`
+- inetutils: :cve:`2022-39028`
+- libtirpc: :cve:`2021-46828`
+- libxml2: :cve:`2016-3709 (ignored)`
+- libxslt: :cve:`2022-29824 (not applicable)`
+- linux-yocto/5.15: :cve:`2022-28796`
+- logrotate: :cve:`2022-1348`
+- lua: :cve:`2022-33099`
+- nasm: :cve:`2020-18974 (ignored)`
+- ncurses: :cve:`2022-29458`
+- openssl: :cve:`2022-1292`, :cve:`2022-1343`, :cve:`2022-1434`, :cve:`2022-1473`, :cve:`2022-2068`, :cve:`2022-2274`, :cve:`2022-2097`
+- python3: :cve:`2015-20107 (ignored)`
+- qemu: :cve:`2021-20255 (ignored)`, :cve:`2019-12067 (ignored)`, :cve:`2021-3507`, :cve:`2022-0216`, :cve:`2022-2962`, :cve:`2022-35414`
+- rpm: :cve:`2021-35937`, :cve:`2021-35938`, :cve:`2021-35939`
+- rsync: :cve:`2022-29154`
+- subversion: :cve:`2021-28544`, :cve:`2022-24070`
+- tiff: :cve:`2022-1210 (not applicable)`, :cve:`2022-1622`, :cve:`2022-1623 (invalid)`, :cve:`2022-2056`, :cve:`2022-2057`, :cve:`2022-2058`, :cve:`2022-2953`, :cve:`2022-34526`
+- unzip: :cve:`2022-0529`, :cve:`2022-0530`
+- vim: :cve:`2022-1381`, :cve:`2022-1420`, :cve:`2022-1621`, :cve:`2022-1629`, :cve:`2022-1674`, :cve:`2022-1733`, :cve:`2022-1735`, :cve:`2022-1769`, :cve:`2022-1771`, :cve:`2022-1785`, :cve:`2022-1796`, :cve:`2022-1927`, :cve:`2022-1942`, :cve:`2022-2257`, :cve:`2022-2264`, :cve:`2022-2284`, :cve:`2022-2285`, :cve:`2022-2286`, :cve:`2022-2287`, :cve:`2022-2816`, :cve:`2022-2817`, :cve:`2022-2819`, :cve:`2022-2845`, :cve:`2022-2849`, :cve:`2022-2862`, :cve:`2022-2874`, :cve:`2022-2889`, :cve:`2022-2980`, :cve:`2022-2946`, :cve:`2022-2982`, :cve:`2022-3099`, :cve:`2022-3134`, :cve:`2022-3234`, :cve:`2022-3278`
+- zlib: :cve:`2022-37434`
+
+
+
+
+
+Recipe Upgrades in 4.1
+~~~~~~~~~~~~~~~~~~~~~~
+
+- acpica 20211217 -> 20220331
+- adwaita-icon-theme 41.0 -> 42.0
+- alsa-lib 1.2.6.1 -> 1.2.7.2
+- alsa-plugins 1.2.6 -> 1.2.7.1
+- alsa-ucm-conf 1.2.6.3 -> 1.2.7.2
+- alsa-utils 1.2.6 -> 1.2.7
+- asciidoc 10.1.4 -> 10.2.0
+- at-spi2-core 2.42.0 -> 2.44.1
+- autoconf-archive 2022.02.11 -> 2022.09.03
+- base-passwd 3.5.29 -> 3.5.52
+- bind 9.18.5 -> 9.18.7
+- binutils 2.38 -> 2.39
+- boost 1.78.0 -> 1.80.0
+- boost-build-native 4.4.1 -> 1.80.0
+- btrfs-tools 5.16.2 -> 5.19.1
+- cargo 1.59.0 -> 1.63.0
+- ccache 4.6 -> 4.6.3
+- cmake 3.22.3 -> 3.24.0
+- cmake-native 3.22.3 -> 3.24.0
+- coreutils 9.0 -> 9.1
+- createrepo-c 0.19.0 -> 0.20.1
+- cross-localedef-native 2.35 -> 2.36
+- curl 7.82.0 -> 7.85.0
+- diffoscope 208 -> 221
+- dmidecode 3.3 -> 3.4
+- dnf 4.11.1 -> 4.14.0
+- dos2unix 7.4.2 -> 7.4.3
+- dpkg 1.21.4 -> 1.21.9
+- dropbear 2020.81 -> 2022.82
+- efibootmgr 17 -> 18
+- elfutils 0.186 -> 0.187
+- ell 0.50 -> 0.53
+- enchant2 2.3.2 -> 2.3.3
+- erofs-utils 1.4 -> 1.5
+- ethtool 5.16 -> 5.19
+- eudev 3.2.10 -> 3.2.11
+- ffmpeg 5.0.1 -> 5.1.1
+- file 5.41 -> 5.43
+- flac 1.3.4 -> 1.4.0
+- fontconfig 2.13.1 -> 2.14.0
+- freetype 2.11.1 -> 2.12.1
+- gcc 11.3.0 -> 12.2.0
+- gcompat 1.0.0+1.1+gitX (4d6a5156a6eb…) -> 1.0.0+1.1+gitX (c6921a1aa454…)
+- gdb 11.2 -> 12.1
+- ghostscript 9.55.0 -> 9.56.1
+- git 2.35.4 -> 2.37.3
+- glibc 2.35 -> 2.36
+- glslang 1.3.204.1 -> 1.3.216.0
+- gnu-config 20211108+gitX -> 20220525+gitX
+- gnu-efi 3.0.14 -> 3.0.15
+- gnutls 3.7.4 -> 3.7.7
+- go 1.17.13 -> 1.19
+- go-helloworld 0.1 (787a929d5a0d…) -> 0.1 (2e68773dfca0…)
+- gpgme 1.17.1 -> 1.18.0
+- gptfdisk 1.0.8 -> 1.0.9
+- harfbuzz 4.0.1 -> 5.1.0
+- hdparm 9.63 -> 9.64
+- help2man 1.49.1 -> 1.49.2
+- hwlatdetect 2.3 -> 2.4
+- icu 70.1 -> 71.1
+- inetutils 2.2 -> 2.3
+- init-system-helpers 1.62 -> 1.64
+- iproute2 5.17.0 -> 5.19.0
+- iptables 1.8.7 -> 1.8.8
+- iw 5.16 -> 5.19
+- json-c 0.15 -> 0.16
+- kbd 2.4.0 -> 2.5.1
+- kea 2.0.2 -> 2.2.0
+- kexec-tools 2.0.23 -> 2.0.25
+- kmod 29 -> 30
+- kmscube git (9f63f359fab1…) -> git (3bf6ee1a0233…)
+- less 600 -> 608
+- libaio 0.3.112 -> 0.3.113
+- libbsd 0.11.5 -> 0.11.6
+- libcap-ng 0.8.2 -> 0.8.3
+- libcap-ng-python 0.8.2 -> 0.8.3
+- libcgroup 2.0.2 -> 3.0.0
+- libcomps 0.1.18 -> 0.1.19
+- libdnf 0.66.0 -> 0.69.0
+- libdrm 2.4.110 -> 2.4.113
+- libevdev 1.12.1 -> 1.13.0
+- libfontenc 1.1.4 -> 1.1.6
+- libgcc 11.3.0 -> 12.2.0
+- libgcc-initial 11.3.0 -> 12.2.0
+- libgcrypt 1.9.4 -> 1.10.1
+- libgfortran 11.3.0 -> 12.2.0
+- libgit2 1.4.3 -> 1.5.0
+- libgpg-error 1.44 -> 1.45
+- libhandy 1.5.0 -> 1.6.3
+- libidn2 2.3.2 -> 2.3.3
+- libjitterentropy 3.4.0 -> 3.4.1
+- libmnl 1.0.4 -> 1.0.5
+- libnl 3.5.0 -> 3.7.0
+- libnotify 0.7.9 -> 0.8.1
+- libpipeline 1.5.5 -> 1.5.6
+- libproxy 0.4.17 -> 0.4.18
+- librepo 1.14.3 -> 1.14.5
+- librsvg 2.52.7 -> 2.54.5
+- libsdl2 2.0.20 -> 2.24.0
+- libseccomp 2.5.3 -> 2.5.4
+- libsndfile1 1.0.31 -> 1.1.0
+- libstd-rs 1.59.0 -> 1.63.0
+- libtirpc 1.3.2 -> 1.3.3
+- libubootenv 0.3.2 -> 0.3.3
+- libva 2.14.0 -> 2.15.0
+- libva-utils 2.14.0 -> 2.15.0
+- libx11 1.7.3.1 -> 1.8.1
+- libxau 1.0.9 -> 1.0.10
+- libxcb 1.14 -> 1.15
+- libxcursor 1.2.0 -> 1.2.1
+- libxcvt 0.1.1 -> 0.1.2
+- libxfont2 2.0.5 -> 2.0.6
+- libxvmc 1.0.12 -> 1.0.13
+- linux-libc-headers 5.16 -> 5.19
+- linux-yocto 5.10.143+gitX, 5.15.68+gitX -> 5.15.68+gitX, 5.19.9+gitX
+- linux-yocto-dev 5.18++gitX -> 5.19++gitX
+- linux-yocto-rt 5.10.143+gitX, 5.15.68+gitX -> 5.15.68+gitX, 5.19.9+gitX
+- linux-yocto-tiny 5.10.143+gitX, 5.15.68+gitX -> 5.15.68+gitX, 5.19.9+gitX
+- llvm 13.0.1 -> 14.0.6
+- lsof 4.94.0 -> 4.95.0
+- ltp 20220121 -> 20220527
+- lttng-tools 2.13.4 -> 2.13.8
+- lttng-ust 2.13.3 -> 2.13.4
+- mc 4.8.27 -> 4.8.28
+- mesa 22.0.3 -> 22.2.0
+- mesa-demos 8.4.0 -> 8.5.0
+- mesa-gl 22.0.3 -> 22.2.0
+- meson 0.61.3 -> 0.63.2
+- mmc-utils 0.1+gitX (b7e4d5a6ae99…) -> 0.1+gitX (d7b343fd2628…)
+- mpg123 1.29.3 -> 1.30.2
+- msmtp 1.8.20 -> 1.8.22
+- mtools 4.0.38 -> 4.0.40
+- musl 1.2.3+gitX (7a43f6fea908…) -> 1.2.3+gitX (37e18b7bf307…)
+- musl-obstack 1.1 -> 1.2
+- ncurses 6.3+20220423 (a0bc708bc695…) -> 6.3+20220423 (20db1fb41ec9…)
+- neard 0.16 -> 0.18
+- nettle 3.7.3 -> 3.8.1
+- nfs-utils 2.6.1 -> 2.6.2
+- nghttp2 1.47.0 -> 1.49.0
+- ninja 1.10.2 -> 1.11.1
+- numactl 2.0.14 -> 2.0.15
+- ofono 1.34 -> 2.0
+- opensbi 1.0 -> 1.1
+- openssh 8.9p1 -> 9.0p1
+- opkg 0.5.0 -> 0.6.0
+- ovmf edk2-stable202202 -> edk2-stable202205
+- pango 1.50.4 -> 1.50.9
+- parted 3.4 -> 3.5
+- patchelf 0.14.5 -> 0.15.0
+- pciutils 3.7.0 -> 3.8.0
+- perl 5.34.1 -> 5.36.0
+- perlcross 1.3.7 -> 1.4
+- piglit 1.0+gitrX (2f80c7cc9c02…) -> 1.0+gitrX (265896c86f90…)
+- pkgconf 1.8.0 -> 1.9.3
+- psmisc 23.4 -> 23.5
+- pulseaudio 15.0 -> 16.1
+- puzzles 0.0+gitX (c43a34fbfe43…) -> 0.0+gitX (8399cff6a3b9…)
+- python3 3.10.4 -> 3.10.6
+- python3-atomicwrites 1.4.0 -> 1.4.1
+- python3-attrs 21.4.0 -> 22.1.0
+- python3-babel 2.9.1 -> 2.10.3
+- python3-bcrypt 3.2.0 -> 3.2.2
+- python3-certifi 2021.10.8 -> 2022.9.14
+- python3-cffi 1.15.0 -> 1.15.1
+- python3-chardet 4.0.0 -> 5.0.0
+- python3-cryptography 36.0.2 -> 37.0.4
+- python3-cryptography-vectors 36.0.2 -> 37.0.4
+- python3-cython 0.29.28 -> 0.29.32
+- python3-dbusmock 0.27.3 -> 0.28.4
+- python3-docutils 0.18.1 -> 0.19
+- python3-dtschema 2022.1 -> 2022.8.3
+- python3-hypothesis 6.39.5 -> 6.54.5
+- python3-idna 3.3 -> 3.4
+- python3-imagesize 1.3.0 -> 1.4.1
+- python3-importlib-metadata 4.11.3 -> 4.12.0
+- python3-jinja2 3.1.1 -> 3.1.2
+- python3-jsonpointer 2.2 -> 2.3
+- python3-jsonschema 4.4.0 -> 4.9.1
+- python3-magic 0.4.25 -> 0.4.27
+- python3-mako 1.1.6 -> 1.2.2
+- python3-markdown 3.3.6 -> 3.4.1
+- python3-more-itertools 8.12.0 -> 8.14.0
+- python3-numpy 1.22.3 -> 1.23.3
+- python3-pbr 5.8.1 -> 5.10.0
+- python3-pip 22.0.3 -> 22.2.2
+- python3-psutil 5.9.0 -> 5.9.2
+- python3-pycryptodome 3.14.1 -> 3.15.0
+- python3-pycryptodomex 3.14.1 -> 3.15.0
+- python3-pyelftools 0.28 -> 0.29
+- python3-pygments 2.11.2 -> 2.13.0
+- python3-pygobject 3.42.0 -> 3.42.2
+- python3-pyparsing 3.0.7 -> 3.0.9
+- python3-pytest 7.1.1 -> 7.1.3
+- python3-pytest-subtests 0.7.0 -> 0.8.0
+- python3-pytz 2022.1 -> 2022.2.1
+- python3-requests 2.27.1 -> 2.28.1
+- python3-scons 4.3.0 -> 4.4.0
+- python3-semantic-version 2.9.0 -> 2.10.0
+- python3-setuptools 59.5.0 -> 65.0.2
+- python3-setuptools-scm 6.4.2 -> 7.0.5
+- python3-sphinx 4.4.0 -> 5.1.1
+- python3-sphinx-rtd-theme 0.5.0 -> 1.0.0
+- python3-typing-extensions 3.10.0.0 -> 4.3.0
+- python3-urllib3 1.26.9 -> 1.26.12
+- python3-webcolors 1.11.1 -> 1.12
+- python3-zipp 3.7.0 -> 3.8.1
+- qemu 6.2.0 -> 7.1.0
+- repo 2.22 -> 2.29.2
+- rpm 4.17.0 -> 4.18.0
+- rsync 3.2.3 -> 3.2.5
+- rt-tests 2.3 -> 2.4
+- rust 1.59.0 -> 1.63.0
+- rust-llvm 1.59.0 -> 1.63.0
+- sbc 1.5 -> 2.0
+- seatd 0.6.4 -> 0.7.0
+- shaderc 2022.1 -> 2022.2
+- shadow 4.11.1 -> 4.12.1
+- shared-mime-info 2.1 -> 2.2
+- slang 2.3.2 -> 2.3.3
+- speex 1.2.0 -> 1.2.1
+- speexdsp 1.2.0 -> 1.2.1
+- spirv-headers 1.3.204.1 -> 1.3.216.0
+- spirv-tools 1.3.204.1 -> 1.3.216.0
+- sqlite3 3.38.5 -> 3.39.3
+- squashfs-tools 4.5 -> 4.5.1
+- strace 5.16 -> 5.19
+- stress-ng 0.13.12 -> 0.14.03
+- sudo 1.9.10 -> 1.9.11p3
+- sysklogd 2.3.0 -> 2.4.4
+- sysstat 12.4.5 -> 12.6.0
+- systemd 250.5 -> 251.4
+- systemd-boot 250.5 -> 251.4
+- systemtap 4.6 -> 4.7
+- systemtap-native 4.6 -> 4.7
+- systemtap-uprobes 4.6 -> 4.7
+- sysvinit 3.01 -> 3.04
+- tiff 4.3.0 -> 4.4.0
+- tzcode-native 2022c -> 2022d
+- tzdata 2022c -> 2022d
+- u-boot 2022.01 -> 2022.07
+- u-boot-tools 2022.01 -> 2022.07
+- util-linux 2.37.4 -> 2.38.1
+- util-linux-libuuid 2.37.4 -> 2.38.1
+- valgrind 3.18.1 -> 3.19.0
+- vim 9.0.0541 -> 9.0.0598
+- vim-tiny 9.0.0541 -> 9.0.0598
+- virglrenderer 0.9.1 -> 0.10.3
+- vte 0.66.2 -> 0.68.0
+- vulkan-headers 1.3.204.1 -> 1.3.216.0
+- vulkan-loader 1.3.204.1 -> 1.3.216.0
+- vulkan-samples git (28ca2dad83ce…) -> git (74d45aace02d…)
+- vulkan-tools 1.3.204.1 -> 1.3.216.0
+- wayland 1.20.0 -> 1.21.0
+- wayland-protocols 1.25 -> 1.26
+- webkitgtk 2.36.5 -> 2.36.7
+- x264 r3039+gitX (5db6aa6cab1b…) -> r3039+gitX (baee400fa9ce…)
+- xauth 1.1.1 -> 1.1.2
+- xcb-proto 1.14.1 -> 1.15.2
+- xf86-video-cirrus 1.5.3 -> 1.6.0
+- xkeyboard-config 2.35.1 -> 2.36
+- xmlto 0.0.28 -> 0.0.28+0.0.29+gitX
+- xorgproto 2021.5 -> 2022.2
+- zlib 1.2.11 -> 1.2.12
+
+
+
+Contributors to 4.1
+~~~~~~~~~~~~~~~~~~~
+
+Thanks to the following people who contributed to this release:
+
+- Aatir Manzur
+- Ahmed Hossam
+- Alejandro Hernandez Samaniego
+- Alexander Kanavin
+- Alexandre Belloni
+- Alex Kiernan
+- Alex Stewart
+- Andrei Gherzan
+- Andrej Valek
+- Andrey Konovalov
+- Aníbal Limón
+- Anuj Mittal
+- Arkadiusz Drabczyk
+- Armin Kuster
+- Aryaman Gupta
+- Awais Belal
+- Beniamin Sandu
+- Bertrand Marquis
+- Bob Henz
+- Bruce Ashfield
+- Carlos Rafael Giani
+- Changhyeok Bae
+- Changqing Li
+- Chanho Park
+- Chen Qi
+- Christoph Lauer
+- Claudius Heine
+- Daiane Angolini
+- Daniel Gomez
+- Daniel McGregor
+- David Bagonyi
+- Davide Gardenal
+- Denys Dmytriyenko
+- Dmitry Baryshkov
+- Drew Moseley
+- Enrico Scholz
+- Ernst Sjöstrand
+- Etienne Cordonnier
+- Fabio Estevam
+- Federico Pellegrin
+- Felix Moessbauer
+- Ferry Toth
+- Florin Diaconescu
+- Gennaro Iorio
+- Grygorii Tertychnyi
+- Gunjan Gupta
+- Henning Schild
+- He Zhe
+- Hitendra Prajapati
+- Jack Mitchell
+- Jacob Kroon
+- Jan Kiszka
+- Jan Luebbe
+- Jan Vermaete
+- Jasper Orschulko
+- JeongBong Seo
+- Jeremy Puhlman
+- Jiaqing Zhao
+- Joerg Vehlow
+- Johan Korsnes
+- Johannes Schneider
+- John Edward Broadbent
+- Jon Mason
+- Jose Quaresma
+- Joshua Watt
+- Justin Bronder
+- Kai Kang
+- Kevin Hao
+- Khem Raj
+- Konrad Weihmann
+- Kory Maincent
+- Kristian Amlie
+- Lee Chee Yang
+- Lei Maohui
+- Leon Anavi
+- Luca Ceresoli
+- Lucas Stach
+- LUIS ENRIQUEZ
+- Marcel Ziswiler
+- Marius Kriegerowski
+- Mark Hatle
+- Markus Volk
+- Marta Rybczynska
+- Martin Beeger
+- Martin Jansa
+- Mateusz Marciniec
+- Mattias Jernberg
+- Matt Madison
+- Maxime Roussin-Bélanger
+- Michael Halstead
+- Michael Opdenacker
+- Mihai Lindner
+- Mikko Rapeli
+- Ming Liu
+- Mingli Yu
+- Muhammad Hamza
+- Naveen Saini
+- Neil Horman
+- Nick Potenski
+- Nicolas Dechesne
+- Niko Mauno
+- Ola x Nilsson
+- Otavio Salvador
+- Pascal Bach
+- Paul Eggleton
+- Paul Gortmaker
+- Paulo Neves
+- Pavel Zhukov
+- Peter Bergin
+- Peter Kjellerstedt
+- Peter Marko
+- Petr Vorel
+- Pgowda
+- Portia Stephens
+- Quentin Schulz
+- Rahul Kumar
+- Raju Kumar Pothuraju
+- Randy MacLeod
+- Raphael Teller
+- Rasmus Villemoes
+- Ricardo Salveti
+- Richard Purdie
+- Robert Joslyn
+- Robert Yang
+- Roland Hieber
+- Ross Burton
+- Rouven Czerwinski
+- Ruiqiang Hao
+- Russ Dill
+- Rusty Howell
+- Sakib Sajal
+- Samuli Piippo
+- Schmidt, Adriaan
+- Sean Anderson
+- Shruthi Ravichandran
+- Shubham Kulkarni
+- Simone Weiss
+- Sebastian Suesens
+- Stefan Herbrechtsmeier
+- Stefano Babic
+- Stefan Wiehler
+- Steve Sakoman
+- Sundeep KOKKONDA
+- Teoh Jay Shen
+- Thomas Epperson
+- Thomas Perrot
+- Thomas Roos
+- Tobias Schmidl
+- Tomasz Dziendzielski
+- Tom Hochstein
+- Tom Rini
+- Trevor Woerner
+- Ulrich Ölmann
+- Vyacheslav Yurkov
+- Wang Mingyu
+- William A. Kennington III
+- Xiaobing Luo
+- Xu Huan
+- Yang Xu
+- Yi Zhao
+- Yogesh Tyagi
+- Yongxin Liu
+- Yue Tao
+- Yulong (Kevin) Liu
+- Zach Welch
+- Zheng Ruoqin
+- Zoltán Böszörményi
+
+
+
+Repositories / Downloads for 4.1
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- 
1.8.3.1

RE: [docs] [PATCH 16/34] ref-manual: add CVE_CHECK_SHOW_WARNINGS

[Peter Kjellerstedt]

> -----Original Message-----
> From: docs@lists.yoctoproject.org <docs@lists.yoctoproject.org> On Behalf
> Of Paul Eggleton
> Sent: den 10 oktober 2022 11:24
> To: docs@lists.yoctoproject.org
> Subject: [docs] [PATCH 16/34] ref-manual: add CVE_CHECK_SHOW_WARNINGS
> 
> From: Paul Eggleton <paul.eggleton@microsoft.com>
> 
> New variable in 4.1.
> 
> Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
> ---
>  documentation/ref-manual/variables.rst | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst
> index 885641a..c226b92 100644
> --- a/documentation/ref-manual/variables.rst
> +++ b/documentation/ref-manual/variables.rst
> @@ -1508,6 +1508,13 @@ system and gives an overview of their function and
> contents.
>           # This is windows only issue.
>           CVE_CHECK_IGNORE += "CVE-2020-15523"
> 
> +   :term:`CVE_CHECK_SHOW_WARNINGS`
> +      Specifies whether or not the :ref:`pypi <ref-classes-cve-check>` class

Change "pypi" to "cve-check".

> +      should generate warning messages on the console when unpatched CVEs
> +      are found. The default is "1", but you may wish to set it to "0" if you
> +      are already examining/processing the logs after the build has completed
> +      and thus do not need the warning messages.
> +
>     :term:`CVE_CHECK_SKIP_RECIPE`
>        The list of package names (:term:`PN`) for which
>        CVEs (Common Vulnerabilities and Exposures) are ignored.
> --
> 1.8.3.1

//Peter

Re: [docs] [PATCH 16/34] ref-manual: add CVE_CHECK_SHOW_WARNINGS

[Paul Eggleton]

On Tuesday, 11 October 2022 02:55:17 NZDT Peter Kjellerstedt wrote:
> > --- a/documentation/ref-manual/variables.rst
> > +++ b/documentation/ref-manual/variables.rst
> > @@ -1508,6 +1508,13 @@ system and gives an overview of their function and
> > contents.
> > 
> >           # This is windows only issue.
> >           CVE_CHECK_IGNORE += "CVE-2020-15523"
> > 
> > +   :term:`CVE_CHECK_SHOW_WARNINGS`
> > +      Specifies whether or not the :ref:`pypi <ref-classes-cve-check>`
> > class
>
> Change "pypi" to "cve-check".

Oops - fixed on the branch.

Thanks
Paul

Re: [docs] [PATCH 14/34] ref-manual: add pypi class

[Paul Eggleton]

On Monday, 10 October 2022 23:23:03 NZDT Joshua Lock wrote:
> > +``pypi.bbclass``
> > +================
> > +
> > +The ``pypi`` class sets variables appropriately for recipes that build
> > +Python modules from `PyPI < https://pypi.org/ >`__, the Python Package
> > Index.
> > +By default it determines the PyPI package name based upon BPN (stripping
> > the
> 
> Nit: it would be nice to change BPN here to :term:`BPN`

Ah yes, well spotted. Fixed on the branch.

Thanks
Paul

Re: [docs] [PATCH 10/34] ref-manual: add UBOOT_MKIMAGE_SIGN

[Paul Eggleton]

On Monday, 10 October 2022 23:24:07 NZDT Joshua Lock wrote:
> Nit: commit title mentions UBOOT_MKIMAGE_SIGN , but the patch documents
> UBOOT_MKIMAGE_KERNEL_TYPE

Oops. Fixed on the branch.

Thanks
Paul

Re: [docs] [PATCH 01/34] migration-general: add section on using buildhistory

[Michael Opdenacker]

Hi Paul

Many thanks for all these patches!

On 10/10/22 11:23, Paul Eggleton wrote:
> From: Paul Eggleton <paul.eggleton@microsoft.com>
>
> Add a short section recommending the use of buildhistory to compare
> the build output before and after migration.
>
> Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
> ---
>   .../migration-guides/migration-general.rst         | 33 ++++++++++++++++++++++
>   1 file changed, 33 insertions(+)
>
> diff --git a/documentation/migration-guides/migration-general.rst b/documentation/migration-guides/migration-general.rst
> index 9eecf69..8b22508 100644
> --- a/documentation/migration-guides/migration-general.rst
> +++ b/documentation/migration-guides/migration-general.rst
> @@ -70,3 +70,36 @@ any new Yocto Project release.
>        bitbake-layers show-appends
>   
>   
> +.. _migration-general-buildhistory:
> +
> +- *Checking Image / SDK Changes*:
> +
> +   The :ref:`buildhistory <ref-classes-buildhistory>` class can be used
> +   if you wish to check the impact of changes to images / SDKs across
> +   the migration (e.g. added/removed packages, added/removed files, size
> +   changes etc.). To do this, follow these steps:
> +
> +   1. Enable buildhistory before the migration
> +
> +   2. Run a pre-migration build
> +
> +   3. Capture the buildhistory output (as specified by :term:`BUILDHISTORY_DIR`)
> +      and ensure it is preserved for subsequent builds. How you would do this
> +      depends how you are running your builds - if you are doing this all on


s/depends how/depends on how/?
The rest looks good.
Thanks again

Michael.

-- 
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [docs] [PATCH 08/34] ref-manual: sync supported distro list with code

[Michael Opdenacker]

Hi Paul,

On 10/10/22 11:23, Paul Eggleton wrote:
> From: Paul Eggleton <paul.eggleton@microsoft.com>
>
> We were missing Ubuntu 21.10.
>
> Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
> ---
>   documentation/ref-manual/system-requirements.rst | 2 ++
>   1 file changed, 2 insertions(+)
>
> diff --git a/documentation/ref-manual/system-requirements.rst b/documentation/ref-manual/system-requirements.rst
> index acc97c9..014c9a5 100644
> --- a/documentation/ref-manual/system-requirements.rst
> +++ b/documentation/ref-manual/system-requirements.rst
> @@ -41,6 +41,8 @@ distributions:
>   
>   -  Ubuntu 20.04 (LTS)
>   
> +-  Ubuntu 21.10
> +
>   -  Ubuntu 22.04 (LTS)


Is the code right though? 21.10 is no longer updated by Canonical and 
22.04 is more recent. What about stopping testing it instead?
That's why I didn't add it to the documentation.
Cheers
Michael.

-- 
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [docs] [PATCH 13/34] ref-manual: add pressure limit variable documentation

[Michael Opdenacker]

Hi Paul,

On 10/10/22 11:23, Paul Eggleton wrote:
> From: Paul Eggleton <paul.eggleton@microsoft.com>
>
> Add BB_PRESSURE_MAX_CPU, BB_PRESSURE_MAX_IO and BB_PRESSURE_MAX_MEMORY
> variables (new in 4.1), based upon the supremely detailed commit
> messages from Aryaman Gupta <aryaman.gupta@windriver.com> who
> implemented the functionality. There is probably enough material for a
> proper BitBake manual section (particularly if we can have some good
> guidance on how users should determine the values for best performance)
> but I did not have time to write such a section, and the BitBake manual
> probably needs some additional preamble on tasks / scheduling
> beforehand.
>
> Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
> ---
>   documentation/ref-manual/variables.rst | 42 ++++++++++++++++++++++++++++++++++
>   1 file changed, 42 insertions(+)
>
> diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst
> index 0c6bd80..e4304d1 100644
> --- a/documentation/ref-manual/variables.rst
> +++ b/documentation/ref-manual/variables.rst
> @@ -530,6 +530,48 @@ system and gives an overview of their function and contents.
>         ":ref:`dev-manual/common-tasks:speeding up a build`"
>         section in the Yocto Project Development Tasks Manual.
>   
> +   :term:`BB_PRESSURE_MAX_CPU`
> +      Specifies a maximum CPU pressure threshold, above which BitBake's
> +      scheduler will not start new tasks (providing there is at least
> +      one active task). If no value is set, CPU pressure is not
> +      monitored when starting tasks.
> +
> +      The pressure data is calculated based upon what (recent) Linux
> +      kernels expose under ``/proc/pressure``. The threshold represents
> +      the difference in "total" pressure from the previous second. The
> +      minimum value is 1.0 (extremely slow builds) and the maximum is
> +      1000000 (a pressure value unlikely to ever be reached).
> +
> +   :term:`BB_PRESSURE_MAX_IO`
> +      Specifies a maximum I/O pressure threshold, above which BitBake's
> +      scheduler will not start new tasks (providing there is at least
> +      one active task). If no value is set, I/O pressure is not
> +      monitored when starting tasks.
> +
> +      The pressure data is calculated based upon what (recent) Linux
> +      kernels expose under ``/proc/pressure``. The threshold represents
> +      the difference in "total" pressure from the previous second. The
> +      minimum value is 1.0 (extremely slow builds) and the maximum is
> +      1000000 (a pressure value unlikely to ever be reached).
> +
> +   :term:`BB_PRESSURE_MAX_MEMORY`
> +      Specifies a maximum memory pressure threshold, above which BitBake's
> +      scheduler will not start new tasks (providing there is at least
> +      one active task). If no value is set, memory pressure is not
> +      monitored when starting tasks.
> +
> +      The pressure data is calculated based upon what (recent) Linux
> +      kernels expose under ``/proc/pressure``. The threshold represents
> +      the difference in "total" pressure from the previous second. The
> +      minimum value is 1.0 (extremely slow builds) and the maximum is
> +      1000000 (a pressure value unlikely to ever be reached).
> +
> +      Memory pressure is experienced when time is spent swapping,
> +      refaulting pages from the page cache or performing direct reclaim.
> +      This is why memory pressure is rarely seen, but setting this variable
> +      might be useful as a last resort to prevent OOM errors if they are
> +      occurring during builds.
> +
>      :term:`BB_SERVER_TIMEOUT`
>         Specifies the time (in seconds) after which to unload the BitBake
>         server due to inactivity. Set :term:`BB_SERVER_TIMEOUT` to determine how


Actually, these have recently been accepted in the BitBake manual (the 
patches from Aryaman got accepted after he left WindRiver), though 
apparently with fewer details:
https://git.openembedded.org/bitbake/commit/?id=c014281f72f4f54ec8e681ef2b8e1080de9ab5cf

Shall we submit your updates to the Bitbake manual instead? This way, we 
don't have these variables documented in two different places.

Cheers
Michael.

-- 
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [docs] [PATCH 34/34] Add 4.1 migration guide & release notes

[Michael Opdenacker]

Hi Paul

On 10/10/22 11:24, Paul Eggleton wrote:
> From: Paul Eggleton <paul.eggleton@microsoft.com>
>
> This currently does not include known issues or download information.
>
> Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
> ---
>   documentation/migration-guides/index.rst           |   1 +
>   documentation/migration-guides/migration-4.1.rst   | 214 +++++++
>   documentation/migration-guides/release-4.1.rst     |   7 +
>   .../migration-guides/release-notes-4.1.rst         | 687 +++++++++++++++++++++
>   4 files changed, 909 insertions(+)
>   create mode 100644 documentation/migration-guides/migration-4.1.rst
>   create mode 100644 documentation/migration-guides/release-4.1.rst
>   create mode 100644 documentation/migration-guides/release-notes-4.1.rst


This all looks great, including these last two documents. I'd really 
like to include these changes in the "master-next" branch, so that we 
can base our new work on them.
Would you be able to share an update of your branch taking into account 
the few comments that we had?

Many thanks again!
Cheers
Michael.

-- 
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [docs] [PATCH 34/34] Add 4.1 migration guide & release notes

[Michael Opdenacker]

Hi Paul,

On 10/11/22 21:31, Michael Opdenacker via lists.yoctoproject.org wrote:
> Hi Paul
>
> On 10/10/22 11:24, Paul Eggleton wrote:
>> From: Paul Eggleton <paul.eggleton@microsoft.com>
>>
>> This currently does not include known issues or download information.
>>
>> Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
>> ---
>>   documentation/migration-guides/index.rst           |   1 +
>>   documentation/migration-guides/migration-4.1.rst   | 214 +++++++
>>   documentation/migration-guides/release-4.1.rst     |   7 +
>>   .../migration-guides/release-notes-4.1.rst         | 687 
>> +++++++++++++++++++++
>>   4 files changed, 909 insertions(+)
>>   create mode 100644 documentation/migration-guides/migration-4.1.rst
>>   create mode 100644 documentation/migration-guides/release-4.1.rst
>>   create mode 100644 
>> documentation/migration-guides/release-notes-4.1.rst
>
>
> This all looks great, including these last two documents. I'd really 
> like to include these changes in the "master-next" branch, so that we 
> can base our new work on them.
> Would you be able to share an update of your branch taking into 
> account the few comments that we had?


As you already updated your branch for most of the items, I'll take care 
of merging your changes into master-next right away.
This way, I won't make further changes which will conflict with yours.

Thanks again
Michael.


-- 
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [docs] [PATCH 34/34] Add 4.1 migration guide & release notes

[Michael Opdenacker]

On 10/12/22 10:33, Michael Opdenacker via lists.yoctoproject.org wrote:
>
> As you already updated your branch for most of the items, I'll take 
> care of merging your changes into master-next right away.
> This way, I won't make further changes which will conflict with yours.


Done: https://git.yoctoproject.org/yocto-docs/log/?h=master-next
I just didn't pick the change that was adding Ubuntu 21.10 to the 
supported distros (we could discuss this further) and the documentation 
of the pressure variables, which I intend to submit for the BitBake User 
Manual.

To contributors on this list: given the number of patches in yocto-docs' 
master-next, it's best if your patches are based on this branch. This 
always makes my life easier, though conflicts are rare.

Thanks again
Cheers
Michael.

-- 
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [docs] [PATCH 17/34] ref-manual: add info on buildtools-make-tarball

[Michael Opdenacker]

On 10/10/22 11:24, Paul Eggleton wrote:
> From: Paul Eggleton <paul.eggleton@microsoft.com>
>
> This is not perfect, but at least covers the use case and the new
> tarball that we are providing. Note that the --make-only option to
> install-buildtools is a currently pending patch.
>
> Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>


I'm also holding this patch, and will update the commit message when 
your patch to OE-core has been accepted.

Thanks!
Michael.

-- 
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [docs] [PATCH 08/34] ref-manual: sync supported distro list with code

[Paul Eggleton]

On Tuesday, 11 October 2022 21:20:37 NZDT Michael Opdenacker via 
lists.yoctoproject.org wrote:
> Hi Paul,
> 
> On 10/10/22 11:23, Paul Eggleton wrote:
> > From: Paul Eggleton <paul.eggleton@microsoft.com>
> > 
> > We were missing Ubuntu 21.10.
> > 
> > Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
> > ---
> > 
> >   documentation/ref-manual/system-requirements.rst | 2 ++
> >   1 file changed, 2 insertions(+)
> > 
> > diff --git a/documentation/ref-manual/system-requirements.rst
> > b/documentation/ref-manual/system-requirements.rst index acc97c9..014c9a5
> > 100644
> > --- a/documentation/ref-manual/system-requirements.rst
> > +++ b/documentation/ref-manual/system-requirements.rst
> > 
> > @@ -41,6 +41,8 @@ distributions:
> >   -  Ubuntu 20.04 (LTS)
> > 
> > +-  Ubuntu 21.10
> > +
> > 
> >   -  Ubuntu 22.04 (LTS)
> 
> Is the code right though? 21.10 is no longer updated by Canonical and
> 22.04 is more recent. What about stopping testing it instead?

Fine by me, I just figured the documentation should match what is in 
SANITY_TESTED_DISTROS; in this case perhaps the latter needs updating.

Cheers
Paul

Re: [docs] [PATCH 13/34] ref-manual: add pressure limit variable documentation

[Paul Eggleton]

On Tuesday, 11 October 2022 23:30:50 NZDT Michael Opdenacker via 
lists.yoctoproject.org wrote:
> Actually, these have recently been accepted in the BitBake manual (the
> patches from Aryaman got accepted after he left WindRiver), though
> apparently with fewer details:
> https://git.openembedded.org/bitbake/commit/?id=c014281f72f4f54ec8e681ef2b8e
> 1080de9ab5cf
> 
> Shall we submit your updates to the Bitbake manual instead? This way, we
> don't have these variables documented in two different places.

Ah, oops - I missed that. I'm OK with that for now; however, and I may have 
also missed if this has been discussed recently, but it's my opinion that all 
variables documented in the BitBake manual should also be in the Yocto 
reference manual, since they are two different contexts - the catch being that 
for some variables there is information you can't reasonably include in the 
bitbake manual since it relies on some definitions unique to OE so the entries 
can't always be copied exactly. If on the other hand some variables only 
appear in the BitBake manual, there will be people who just won't find them. 

To avoid things getting out of sync, we could potentially have a script that 
would check for and report on variables present in the  BitBake manual that 
aren't in the Yocto reference manual. I'd be happy to write such a script.

Cheers
Paul

Re: [docs] [PATCH 13/34] ref-manual: add pressure limit variable documentation

[Michael Opdenacker]

Hi Paul,

On 10/16/22 22:38, Paul Eggleton wrote:
> On Tuesday, 11 October 2022 23:30:50 NZDT Michael Opdenacker via
> lists.yoctoproject.org wrote:
>> Actually, these have recently been accepted in the BitBake manual (the
>> patches from Aryaman got accepted after he left WindRiver), though
>> apparently with fewer details:
>> https://git.openembedded.org/bitbake/commit/?id=c014281f72f4f54ec8e681ef2b8e
>> 1080de9ab5cf
>>
>> Shall we submit your updates to the Bitbake manual instead? This way, we
>> don't have these variables documented in two different places.
> Ah, oops - I missed that. I'm OK with that for now; however, and I may have
> also missed if this has been discussed recently, but it's my opinion that all
> variables documented in the BitBake manual should also be in the Yocto
> reference manual, since they are two different contexts - the catch being that
> for some variables there is information you can't reasonably include in the
> bitbake manual since it relies on some definitions unique to OE so the entries
> can't always be copied exactly. If on the other hand some variables only
> appear in the BitBake manual, there will be people who just won't find them.


I agree that BitBake variables should all appear in the Yocto variable 
index.

There are already some variables which are initially documented in the 
BitBake manual and then the description is expanded in the Yocto manual 
according to the OE additions. SRC_URI is one of them:

  * https://docs.yoctoproject.org/bitbake/2.0/bitbake-user-manual/bitbake-user-manual-ref-variables.html#term-SRC_URI
  * https://docs.yoctoproject.org/ref-manual/variables.html#term-SRC_URI

>
> To avoid things getting out of sync, we could potentially have a script that
> would check for and report on variables present in the  BitBake manual that
> aren't in the Yocto reference manual. I'd be happy to write such a script.


This would be useful, but if I recall correctly, Quentin was rather 
thinking about having Sphinx include these from the BitBake manual, at 
least for the ones which are only defined in the BitBake manual.

Wouldn't it be better than duplicating content, which always causes trouble.

Any further thoughts?

Cheers
Michael.

-- 
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [docs] [PATCH 13/34] ref-manual: add pressure limit variable documentation

[Quentin Schulz]

Hi all,

On 10/17/22 10:15, Michael Opdenacker via lists.yoctoproject.org wrote:
> Hi Paul,
> 
> On 10/16/22 22:38, Paul Eggleton wrote:
>> On Tuesday, 11 October 2022 23:30:50 NZDT Michael Opdenacker via
>> lists.yoctoproject.org wrote:
>>> Actually, these have recently been accepted in the BitBake manual (the
>>> patches from Aryaman got accepted after he left WindRiver), though
>>> apparently with fewer details:
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.openembedded.org_bitbake_commit_-3Fid-3Dc014281f72f4f54ec8e681ef2b8e&d=DwICaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=x6GN6XCgxQmI7f-H7T3WT3-Fm0BA5lJwsTI4AYj7vqNo4vO7FONFXbwhZxNDjOg5&s=w3C2EZQkLelO9mCiJE4ey-FVbNc3zA7PBHZ2nnBc4wE&e= 1080de9ab5cf
>>>
>>> Shall we submit your updates to the Bitbake manual instead? This way, we
>>> don't have these variables documented in two different places.
>> Ah, oops - I missed that. I'm OK with that for now; however, and I may 
>> have
>> also missed if this has been discussed recently, but it's my opinion 
>> that all
>> variables documented in the BitBake manual should also be in the Yocto
>> reference manual, since they are two different contexts - the catch 
>> being that
>> for some variables there is information you can't reasonably include 
>> in the
>> bitbake manual since it relies on some definitions unique to OE so the 
>> entries
>> can't always be copied exactly. If on the other hand some variables only
>> appear in the BitBake manual, there will be people who just won't find 
>> them.
> 
> 
> I agree that BitBake variables should all appear in the Yocto variable 
> index.
> 
> There are already some variables which are initially documented in the 
> BitBake manual and then the description is expanded in the Yocto manual 
> according to the OE additions. SRC_URI is one of them:
> 
>   * 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.yoctoproject.org_bitbake_2.0_bitbake-2Duser-2Dmanual_bitbake-2Duser-2Dmanual-2Dref-2Dvariables.html-23term-2DSRC-5FURI&d=DwICaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=x6GN6XCgxQmI7f-H7T3WT3-Fm0BA5lJwsTI4AYj7vqNo4vO7FONFXbwhZxNDjOg5&s=MUG2hR2Xp_pBuwrtNxNwKRKxCuWXh8fgIcmZm7k0cTw&e=  * https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.yoctoproject.org_ref-2Dmanual_variables.html-23term-2DSRC-5FURI&d=DwICaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=x6GN6XCgxQmI7f-H7T3WT3-Fm0BA5lJwsTI4AYj7vqNo4vO7FONFXbwhZxNDjOg5&s=jTk77XY6-zxpJ_a9dWSexbLvlpev2lr2-QfhnWYv74E&e=
>>
>> To avoid things getting out of sync, we could potentially have a 
>> script that
>> would check for and report on variables present in the  BitBake manual 
>> that
>> aren't in the Yocto reference manual. I'd be happy to write such a 
>> script.
> 

This would be a good start, though...

> 
> This would be useful, but if I recall correctly, Quentin was rather 
> thinking about having Sphinx include these from the BitBake manual, at 
> least for the ones which are only defined in the BitBake manual.
> 

I'd prefer having a Sphinx plugin that does this automatically (I 
haven't checked if this is actually possible).

But we can start with this script and manually adding those to the YP 
glossary. Someone may eventually find the time and motivation to look 
into a Sphinx plugin but I for sure don't have this time at the moment. 
sorry.

How do you think of implementing this? I had in mind to just add a 
variable in the glossary whose description would be:

See :term:`BitBake documentation <bitbake:FOOVAR>`

so we don't need to take care of keeping their description in sync,

Cheers,
Quentin

Re: [docs] [PATCH 13/34] ref-manual: add pressure limit variable documentation

[Michael Opdenacker]

Hi Quentin

On 10/17/22 10:26, Quentin Schulz wrote:
> Hi all,
>
> On 10/17/22 10:15, Michael Opdenacker via lists.yoctoproject.org wrote:
>> Hi Paul,
>>
>> On 10/16/22 22:38, Paul Eggleton wrote:
>>> On Tuesday, 11 October 2022 23:30:50 NZDT Michael Opdenacker via
>>> lists.yoctoproject.org wrote:
>>>> Actually, these have recently been accepted in the BitBake manual (the
>>>> patches from Aryaman got accepted after he left WindRiver), though
>>>> apparently with fewer details:
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__git.openembedded.org_bitbake_commit_-3Fid-3Dc014281f72f4f54ec8e681ef2b8e&d=DwICaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=x6GN6XCgxQmI7f-H7T3WT3-Fm0BA5lJwsTI4AYj7vqNo4vO7FONFXbwhZxNDjOg5&s=w3C2EZQkLelO9mCiJE4ey-FVbNc3zA7PBHZ2nnBc4wE&e= 
>>>> 1080de9ab5cf
>>>>
>>>> Shall we submit your updates to the Bitbake manual instead? This 
>>>> way, we
>>>> don't have these variables documented in two different places.
>>> Ah, oops - I missed that. I'm OK with that for now; however, and I 
>>> may have
>>> also missed if this has been discussed recently, but it's my opinion 
>>> that all
>>> variables documented in the BitBake manual should also be in the Yocto
>>> reference manual, since they are two different contexts - the catch 
>>> being that
>>> for some variables there is information you can't reasonably include 
>>> in the
>>> bitbake manual since it relies on some definitions unique to OE so 
>>> the entries
>>> can't always be copied exactly. If on the other hand some variables 
>>> only
>>> appear in the BitBake manual, there will be people who just won't 
>>> find them.
>>
>>
>> I agree that BitBake variables should all appear in the Yocto 
>> variable index.
>>
>> There are already some variables which are initially documented in 
>> the BitBake manual and then the description is expanded in the Yocto 
>> manual according to the OE additions. SRC_URI is one of them:
>>
>>   * 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.yoctoproject.org_bitbake_2.0_bitbake-2Duser-2Dmanual_bitbake-2Duser-2Dmanual-2Dref-2Dvariables.html-23term-2DSRC-5FURI&d=DwICaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=x6GN6XCgxQmI7f-H7T3WT3-Fm0BA5lJwsTI4AYj7vqNo4vO7FONFXbwhZxNDjOg5&s=MUG2hR2Xp_pBuwrtNxNwKRKxCuWXh8fgIcmZm7k0cTw&e= 
>>  * 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.yoctoproject.org_ref-2Dmanual_variables.html-23term-2DSRC-5FURI&d=DwICaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=x6GN6XCgxQmI7f-H7T3WT3-Fm0BA5lJwsTI4AYj7vqNo4vO7FONFXbwhZxNDjOg5&s=jTk77XY6-zxpJ_a9dWSexbLvlpev2lr2-QfhnWYv74E&e=
>>>
>>> To avoid things getting out of sync, we could potentially have a 
>>> script that
>>> would check for and report on variables present in the BitBake 
>>> manual that
>>> aren't in the Yocto reference manual. I'd be happy to write such a 
>>> script.
>>
>
> This would be a good start, though...
>
>>
>> This would be useful, but if I recall correctly, Quentin was rather 
>> thinking about having Sphinx include these from the BitBake manual, 
>> at least for the ones which are only defined in the BitBake manual.
>>
>
> I'd prefer having a Sphinx plugin that does this automatically (I 
> haven't checked if this is actually possible).
>
> But we can start with this script and manually adding those to the YP 
> glossary. Someone may eventually find the time and motivation to look 
> into a Sphinx plugin but I for sure don't have this time at the 
> moment. sorry.
>
> How do you think of implementing this? I had in mind to just add a 
> variable in the glossary whose description would be:
>
> See :term:`BitBake documentation <bitbake:FOOVAR>`
>
> so we don't need to take care of keeping their description in sync,


Yes, this would be perfectly acceptable as a first solution IMHO, if 
nobody objects this redirection. Then Paul's script would definitely 
help (thanks in advance!).
Cheers
Michael.

-- 
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [docs] [PATCH 08/34] ref-manual: sync supported distro list with code

[Michael Opdenacker]

On 10/16/22 21:16, Paul Eggleton wrote:
> On Tuesday, 11 October 2022 21:20:37 NZDT Michael Opdenacker via
> lists.yoctoproject.org wrote:
>> Hi Paul,
>>
>> On 10/10/22 11:23, Paul Eggleton wrote:
>>> From: Paul Eggleton <paul.eggleton@microsoft.com>
>>>
>>> We were missing Ubuntu 21.10.
>>>
>>> Signed-off-by: Paul Eggleton <paul.eggleton@microsoft.com>
>>> ---
>>>
>>>    documentation/ref-manual/system-requirements.rst | 2 ++
>>>    1 file changed, 2 insertions(+)
>>>
>>> diff --git a/documentation/ref-manual/system-requirements.rst
>>> b/documentation/ref-manual/system-requirements.rst index acc97c9..014c9a5
>>> 100644
>>> --- a/documentation/ref-manual/system-requirements.rst
>>> +++ b/documentation/ref-manual/system-requirements.rst
>>>
>>> @@ -41,6 +41,8 @@ distributions:
>>>    -  Ubuntu 20.04 (LTS)
>>>
>>> +-  Ubuntu 21.10
>>> +
>>>
>>>    -  Ubuntu 22.04 (LTS)
>> Is the code right though? 21.10 is no longer updated by Canonical and
>> 22.04 is more recent. What about stopping testing it instead?
> Fine by me, I just figured the documentation should match what is in
> SANITY_TESTED_DISTROS; in this case perhaps the latter needs updating.


Done (at least proposed): 
https://lists.yoctoproject.org/g/poky/message/12908
Thanks
Michael

-- 
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com