diff --git a/poky/documentation/ref-manual/classes.rst b/poky/documentation/ref-manual/classes.rst
index 5e49613..cd5a516 100644
--- a/poky/documentation/ref-manual/classes.rst
+++ b/poky/documentation/ref-manual/classes.rst
@@ -13,8 +13,14 @@
 
 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 @@
 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.
 
@@ -362,6 +368,14 @@
 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``
@@ -659,6 +673,20 @@
 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``
@@ -881,8 +909,22 @@
 ``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:
 
@@ -980,8 +1022,8 @@
    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
@@ -1293,7 +1335,7 @@
 into a single FIT image. In theory, a FIT image can support any number
 of kernels, U-boot scripts, Initramfs bundles, RAM disks and device-trees.
 However, ``kernel-fitimage`` currently only supports
-limited usescases: just one kernel image, an optional U-boot script,
+limited usecases: just one kernel image, an optional U-boot script,
 an optional Initramfs bundle, an optional RAM disk, and any number of
 device tree.
 
@@ -1977,6 +2019,22 @@
 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 :term:`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`, :term:`UPSTREAM_CHECK_REGEX`
+and :term:`CVE_PRODUCT`.
+
 .. _ref-classes-python_flit_core:
 
 ``python_flit_core.bbclass``
@@ -2724,33 +2782,32 @@
 :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.
 
-.. 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.
 
-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`"
@@ -2892,7 +2949,7 @@
 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/poky/documentation/ref-manual/faq.rst b/poky/documentation/ref-manual/faq.rst
index af49d57..a570c40 100644
--- a/poky/documentation/ref-manual/faq.rst
+++ b/poky/documentation/ref-manual/faq.rst
@@ -4,9 +4,15 @@
 FAQ
 ***
 
-**Q:** How does Poky differ from :oe_home:`OpenEmbedded <>`?
+.. contents::
 
-**A:** The term ``Poky`` refers to the specific reference build
+General questions
+=================
+
+How does Poky differ from OpenEmbedded?
+---------------------------------------
+
+The term ``Poky`` refers to the specific reference build
 system that the Yocto Project provides. Poky is based on
 :term:`OpenEmbedded-Core (OE-Core)` and :term:`BitBake`. Thus, the
 generic term used here for the build system is the "OpenEmbedded build
@@ -15,19 +21,10 @@
 first before being pulled back into Poky. This practice benefits both
 projects immediately.
 
-**Q:** My development system does not meet the required Git, tar, and
-Python versions. In particular, I do not have Python &MIN_PYTHON_VERSION; or greater.
-Can I still use the Yocto Project?
+How can you claim Poky / OpenEmbedded-Core is stable?
+-----------------------------------------------------
 
-**A:** You can get the required tools on your host development system a
-couple different ways (i.e. building a tarball or downloading a
-tarball). See the
-":ref:`ref-manual/system-requirements:required git, tar, python, make and gcc versions`"
-section for steps on how to update your build tools.
-
-**Q:** How can you claim Poky / OpenEmbedded-Core is stable?
-
-**A:** There are three areas that help with stability;
+There are three areas that help with stability;
 
 -  The Yocto Project team keeps :term:`OpenEmbedded-Core (OE-Core)` small and
    focused, containing around 830 recipes as opposed to the thousands
@@ -37,250 +34,33 @@
 -  The Yocto Project team runs manual and automated tests using a small,
    fixed set of reference hardware as well as emulated targets.
 
--  The Yocto Project uses an autobuilder, which provides continuous
-   build and integration tests.
+-  The Yocto Project uses an :yocto_ab:`autobuilder <>`, which provides
+   continuous build and integration tests.
 
-**Q:** How do I get support for my board added to the Yocto Project?
+Are there any products built using the OpenEmbedded build system?
+-----------------------------------------------------------------
 
-**A:** Support for an additional board is added by creating a Board
-Support Package (BSP) layer for it. For more information on how to
-create a BSP layer, see the
-":ref:`dev-manual/common-tasks:understanding and creating layers`"
-section in the Yocto Project Development Tasks Manual and the
-:doc:`/bsp-guide/index`.
-
-Usually, if the board is not completely exotic, adding support in the
-Yocto Project is fairly straightforward.
-
-**Q:** Are there any products built using the OpenEmbedded build system?
-
-**A:** See :yocto_wiki:`Products that use the Yocto Project
+See :yocto_wiki:`Products that use the Yocto Project
 </Project_Users#Products_that_use_the_Yocto_Project>` in the Yocto Project
 Wiki. Don't hesitate to contribute to this page if you know other such
 products.
 
-**Q:** What does the OpenEmbedded build system produce as output?
+Building environment
+====================
 
-**A:** Because you can use the same set of recipes to create output of
-various formats, the output of an OpenEmbedded build depends on how you
-start it. Usually, the output is a flashable image ready for the target
-device.
+Missing dependencies on the development system?
+-----------------------------------------------
 
-**Q:** How do I add my package to the Yocto Project?
+If your development system does not meet the required Git, tar, and
+Python versions, you can get the required tools on your host development
+system in different ways (i.e. building a tarball or downloading a
+tarball). See the ":ref:`ref-manual/system-requirements:required git, tar, python, make and gcc versions`"
+section for steps on how to update your build tools.
 
-**A:** To add a package, you need to create a BitBake recipe. For
-information on how to create a BitBake recipe, see the
-":ref:`dev-manual/common-tasks:writing a new recipe`"
-section in the Yocto Project Development Tasks Manual.
+How does OpenEmbedded fetch source code? Will it work through a firewall or proxy server?
+-----------------------------------------------------------------------------------------
 
-**Q:** Do I have to reflash my entire board with a new Yocto Project
-image when recompiling a package?
-
-**A:** The OpenEmbedded build system can build packages in various
-formats such as IPK for OPKG, Debian package (``.deb``), or RPM. You can
-then upgrade the packages using the package tools on the device, much
-like on a desktop distribution such as Ubuntu or Fedora. However,
-package management on the target is entirely optional.
-
-**Q:** I see the error
-'``chmod: XXXXX new permissions are r-xrwxrwx, not r-xr-xr-x``'. What is
-wrong?
-
-**A:** You are probably running the build on an NTFS filesystem. Use
-``ext2``, ``ext3``, or ``ext4`` instead.
-
-**Q:** I see lots of 404 responses for files when the OpenEmbedded build
-system is trying to download sources. Is something wrong?
-
-**A:** Nothing is wrong. The OpenEmbedded build system checks any
-configured source mirrors before downloading from the upstream sources.
-The build system does this searching for both source archives and
-pre-checked out versions of SCM-managed software. These checks help in
-large installations because it can reduce load on the SCM servers
-themselves. The address above is one of the default mirrors configured
-into the build system. Consequently, if an upstream source disappears,
-the team can place sources there so builds continue to work.
-
-**Q:** I have machine-specific data in a package for one machine only
-but the package is being marked as machine-specific in all cases, how do
-I prevent this?
-
-**A:** Set :term:`SRC_URI_OVERRIDES_PACKAGE_ARCH` = "0" in the ``.bb`` file
-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.
-
-**Q:** I'm behind a firewall and need to use a proxy server. How do I do
-that?
-
-**A:** Most source fetching by the OpenEmbedded build system is done by
-``wget`` and you therefore need to specify the proxy settings in a
-``.wgetrc`` file, which can be in your home directory if you are a
-single user or can be in ``/usr/local/etc/wgetrc`` as a global user
-file.
-
-Following is the applicable code for setting various proxy types in the
-``.wgetrc`` file. By default, these settings are disabled with comments.
-To use them, remove the comments::
-
-   # You can set the default proxies for Wget to use for http, https, and ftp.
-   # They will override the value in the environment.
-   #https_proxy = http://proxy.yoyodyne.com:18023/
-   #http_proxy = http://proxy.yoyodyne.com:18023/
-   #ftp_proxy = http://proxy.yoyodyne.com:18023/
-
-   # If you do not want to use proxy at all, set this to off.
-   #use_proxy = on
-
-The Yocto Project also includes a
-``meta-poky/conf/templates/default/site.conf.sample`` file that shows
-how to configure CVS and Git proxy servers if needed. For more
-information on setting up various proxy types and configuring proxy
-servers, see the
-":yocto_wiki:`Working Behind a Network Proxy </Working_Behind_a_Network_Proxy>`"
-Wiki page.
-
-**Q:** What's the difference between ``target`` and ``target-native``?
-
-**A:** The ``*-native`` targets are designed to run on the system being
-used for the build. These are usually tools that are needed to assist
-the build in some way such as ``quilt-native``, which is used to apply
-patches. The non-native version is the one that runs on the target
-device.
-
-**Q:** I'm seeing random build failures. Help?!
-
-**A:** If the same build is failing in totally different and random
-ways, the most likely explanation is:
-
--  The hardware you are running the build on has some problem.
-
--  You are running the build under virtualization, in which case the
-   virtualization probably has bugs.
-
-The OpenEmbedded build system processes a massive amount of data that
-causes lots of network, disk and CPU activity and is sensitive to even
-single-bit failures in any of these areas. True random failures have
-always been traced back to hardware or virtualization issues.
-
-**Q:** When I try to build a native recipe, the build fails with
-``iconv.h`` problems.
-
-**A:** If you get an error message that indicates GNU ``libiconv`` is
-not in use but ``iconv.h`` has been included from ``libiconv``, you need
-to check to see if you have a previously installed version of the header
-file in ``/usr/local/include``.
-::
-
-   #error GNU libiconv not in use but included iconv.h is from libiconv
-
-If you find a previously installed
-file, you should either uninstall it or temporarily rename it and try
-the build again.
-
-This issue is just a single manifestation of "system leakage" issues
-caused when the OpenEmbedded build system finds and uses previously
-installed files during a native build. This type of issue might not be
-limited to ``iconv.h``. Be sure that leakage cannot occur from
-``/usr/local/include`` and ``/opt`` locations.
-
-**Q:** What do we need to ship for license compliance?
-
-**A:** This is a difficult question and you need to consult your lawyer
-for the answer for your specific case. It is worth bearing in mind that
-for GPL compliance, there needs to be enough information shipped to
-allow someone else to rebuild and produce the same end result you are
-shipping. This means sharing the source code, any patches applied to it,
-and also any configuration information about how that package was
-configured and built.
-
-You can find more information on licensing in the
-":ref:`overview-manual/development-environment:licensing`"
-section in the Yocto
-Project Overview and Concepts Manual and also in the
-":ref:`dev-manual/common-tasks:maintaining open source license compliance during your product's lifecycle`"
-section in the Yocto Project Development Tasks Manual.
-
-**Q:** How do I disable the cursor on my touchscreen device?
-
-**A:** You need to create a form factor file as described in the
-":ref:`bsp-guide/bsp:miscellaneous bsp-specific recipe files`" section in
-the Yocto Project Board Support Packages (BSP) Developer's Guide. Set
-the ``HAVE_TOUCHSCREEN`` variable equal to one as follows::
-
-   HAVE_TOUCHSCREEN=1
-
-**Q:** How do I make sure connected network interfaces are brought up by
-default?
-
-**A:** The default interfaces file provided by the netbase recipe does
-not automatically bring up network interfaces. Therefore, you will need
-to add a BSP-specific netbase that includes an interfaces file. See the
-":ref:`bsp-guide/bsp:miscellaneous bsp-specific recipe files`" section in
-the Yocto Project Board Support Packages (BSP) Developer's Guide for
-information on creating these types of miscellaneous recipe files.
-
-For example, add the following files to your layer::
-
-   meta-MACHINE/recipes-bsp/netbase/netbase/MACHINE/interfaces
-   meta-MACHINE/recipes-bsp/netbase/netbase_5.0.bbappend
-
-**Q:** How do I create images with more free space?
-
-**A:** By default, the OpenEmbedded build system creates images that are
-1.3 times the size of the populated root filesystem. To affect the image
-size, you need to set various configurations:
-
--  *Image Size:* The OpenEmbedded build system uses the
-   :term:`IMAGE_ROOTFS_SIZE` variable to define
-   the size of the image in Kbytes. The build system determines the size
-   by taking into account the initial root filesystem size before any
-   modifications such as requested size for the image and any requested
-   additional free disk space to be added to the image.
-
--  *Overhead:* Use the
-   :term:`IMAGE_OVERHEAD_FACTOR` variable
-   to define the multiplier that the build system applies to the initial
-   image size, which is 1.3 by default.
-
--  *Additional Free Space:* Use the
-   :term:`IMAGE_ROOTFS_EXTRA_SPACE`
-   variable to add additional free space to the image. The build system
-   adds this space to the image after it determines its
-   :term:`IMAGE_ROOTFS_SIZE`.
-
-**Q:** Why don't you support directories with spaces in the pathnames?
-
-**A:** The Yocto Project team has tried to do this before but too many
-of the tools the OpenEmbedded build system depends on, such as
-``autoconf``, break when they find spaces in pathnames. Until that
-situation changes, the team will not support spaces in pathnames.
-
-**Q:** How do I use an external toolchain?
-
-**A:** The toolchain configuration is very flexible and customizable. It
-is primarily controlled with the :term:`TCMODE` variable. This variable
-controls which ``tcmode-*.inc`` file to include from the
-``meta/conf/distro/include`` directory within the :term:`Source Directory`.
-
-The default value of :term:`TCMODE` is "default", which tells the
-OpenEmbedded build system to use its internally built toolchain (i.e.
-``tcmode-default.inc``). However, other patterns are accepted. In
-particular, "external-\*" refers to external toolchains. One example is
-the Sourcery G++ Toolchain. The support for this toolchain resides in
-the separate ``meta-sourcery`` layer at
-https://github.com/MentorEmbedded/meta-sourcery/.
-
-In addition to the toolchain configuration, you also need a
-corresponding toolchain recipe file. This recipe file needs to package
-up any pre-built objects in the toolchain such as ``libgcc``,
-``libstdcc++``, any locales, and ``libc``.
-
-**Q:** How does the OpenEmbedded build system obtain source code and
-will it work behind my firewall or proxy server?
-
-**A:** The way the build system obtains source code is highly
+The way the build system obtains source code is highly
 configurable. You can setup the build system to get source code in most
 environments if HTTP transport is available.
 
@@ -322,16 +102,15 @@
 
    BB_FETCH_PREMIRRORONLY = "1"
 
-This statement
-limits the build system to pulling source from the :term:`PREMIRRORS` only.
-Again, this technique is useful for reproducing builds.
+This statement limits the build system to pulling source from the
+:term:`PREMIRRORS` only.  Again, this technique is useful for reproducing
+builds.
 
 Here is another technique::
 
    BB_GENERATE_MIRROR_TARBALLS = "1"
 
-This
-statement tells the build system to generate mirror tarballs. This
+This statement tells the build system to generate mirror tarballs. This
 technique is useful if you want to create a mirror server. If not,
 however, the technique can simply waste time during the build.
 
@@ -350,9 +129,32 @@
 over HTTP and any network accesses to anything other than the
 :term:`PREMIRRORS` would fail.
 
-The build system also honors the standard shell environment variables
-``http_proxy``, ``ftp_proxy``, ``https_proxy``, and ``all_proxy`` to
-redirect requests through proxy servers.
+Most source fetching by the OpenEmbedded build system is done by
+``wget`` and you therefore need to specify the proxy settings in a
+``.wgetrc`` file, which can be in your home directory if you are a
+single user or can be in ``/usr/local/etc/wgetrc`` as a global user
+file.
+
+Following is the applicable code for setting various proxy types in the
+``.wgetrc`` file. By default, these settings are disabled with comments.
+To use them, remove the comments::
+
+   # You can set the default proxies for Wget to use for http, https, and ftp.
+   # They will override the value in the environment.
+   #https_proxy = http://proxy.yoyodyne.com:18023/
+   #http_proxy = http://proxy.yoyodyne.com:18023/
+   #ftp_proxy = http://proxy.yoyodyne.com:18023/
+
+   # If you do not want to use proxy at all, set this to off.
+   #use_proxy = on
+
+The build system also accepts ``http_proxy``, ``ftp_proxy``, ``https_proxy``,
+and ``all_proxy`` set as to standard shell environment variables to redirect
+requests through proxy servers.
+
+The Yocto Project also includes a
+``meta-poky/conf/templates/default/site.conf.sample`` file that shows
+how to configure CVS and Git proxy servers if needed.
 
 .. note::
 
@@ -360,23 +162,199 @@
    ":yocto_wiki:`Working Behind a Network Proxy </Working_Behind_a_Network_Proxy>`"
    Wiki page.
 
-**Q:** Can I get rid of build output so I can start over?
+Using the OpenEmbedded Build system
+===================================
 
-**A:** Yes --- you can easily do this. When you use BitBake to build an
+How do I use an external toolchain?
+-----------------------------------
+
+The toolchain configuration is very flexible and customizable. It
+is primarily controlled with the :term:`TCMODE` variable. This variable
+controls which ``tcmode-*.inc`` file to include from the
+``meta/conf/distro/include`` directory within the :term:`Source Directory`.
+
+The default value of :term:`TCMODE` is "default", which tells the
+OpenEmbedded build system to use its internally built toolchain (i.e.
+``tcmode-default.inc``). However, other patterns are accepted. In
+particular, "external-\*" refers to external toolchains. One example is
+the Sourcery G++ Toolchain. The support for this toolchain resides in
+the separate ``meta-sourcery`` layer at
+https://github.com/MentorEmbedded/meta-sourcery/.
+
+In addition to the toolchain configuration, you also need a
+corresponding toolchain recipe file. This recipe file needs to package
+up any pre-built objects in the toolchain such as ``libgcc``,
+``libstdcc++``, any locales, and ``libc``.
+
+Why do I get chmod permission issues?
+-------------------------------------
+
+If you see the error
+``chmod: XXXXX new permissions are r-xrwxrwx, not r-xr-xr-x``,
+you are probably running the build on an NTFS filesystem. Instead,
+run the build system on a partition with a modern Linux filesystem such as
+``ext4``, ``btrfs`` or ``xfs``.
+
+I see many 404 errors trying to download sources. Is anything wrong?
+--------------------------------------------------------------------
+
+Nothing is wrong. The OpenEmbedded build system checks any
+configured source mirrors before downloading from the upstream sources.
+The build system does this searching for both source archives and
+pre-checked out versions of SCM-managed software. These checks help in
+large installations because it can reduce load on the SCM servers
+themselves. This can also allow builds to continue to work if an
+upstream source disappears.
+
+Why do I get random build failures?
+-----------------------------------
+
+If the same build is failing in totally different and random
+ways, the most likely explanation is:
+
+-  The hardware you are running the build on has some problem.
+
+-  You are running the build under virtualization, in which case the
+   virtualization probably has bugs.
+
+The OpenEmbedded build system processes a massive amount of data that
+causes lots of network, disk and CPU activity and is sensitive to even
+single-bit failures in any of these areas. True random failures have
+always been traced back to hardware or virtualization issues.
+
+Why does the build fail with ``iconv.h`` problems?
+--------------------------------------------------
+
+When you try to build a native recipe, you may get an error message that
+indicates that GNU ``libiconv`` is not in use but ``iconv.h`` has been
+included from ``libiconv``::
+
+   #error GNU libiconv not in use but included iconv.h is from libiconv
+
+When this happens, you need to check whether you have a previously
+installed version of the header file in ``/usr/local/include/``.
+If that's the case, you should either uninstall it or temporarily rename
+it and try the build again.
+
+This issue is just a single manifestation of "system leakage" issues
+caused when the OpenEmbedded build system finds and uses previously
+installed files during a native build. This type of issue might not be
+limited to ``iconv.h``. Make sure that leakage cannot occur from
+``/usr/local/include`` and ``/opt`` locations.
+
+Why don't other recipes find the files provided by my ``*-native`` recipe?
+--------------------------------------------------------------------------
+
+Files provided by your native recipe could be missing from the native
+sysroot, your recipe could also be installing to the wrong place, or you
+could be getting permission errors during the :ref:`ref-tasks-install`
+task in your recipe.
+
+This situation happens when the build system used by a package does not
+recognize the environment variables supplied to it by :term:`BitBake`. The
+incident that prompted this FAQ entry involved a Makefile that used an
+environment variable named ``BINDIR`` instead of the more standard
+variable ``bindir``. The makefile's hardcoded default value of
+"/usr/bin" worked most of the time, but not for the recipe's ``-native``
+variant. For another example, permission errors might be caused by a
+Makefile that ignores ``DESTDIR`` or uses a different name for that
+environment variable. Check the build system of the package to see if
+these kinds of issues exist.
+
+Can I get rid of build output so I can start over?
+--------------------------------------------------
+
+Yes --- you can easily do this. When you use BitBake to build an
 image, all the build output goes into the directory created when you run
-the build environment setup script (i.e.
-:ref:`structure-core-script`). By default, this :term:`Build Directory`
-is named ``build`` but can be named
+the build environment setup script (i.e.  :ref:`structure-core-script`).
+By default, this :term:`Build Directory` is named ``build`` but can be named
 anything you want.
 
 Within the Build Directory, is the ``tmp`` directory. To remove all the
 build output yet preserve any source code or downloaded files from
 previous builds, simply remove the ``tmp`` directory.
 
-**Q:** Why do ``${bindir}`` and ``${libdir}`` have strange values for
-``-native`` recipes?
+Customizing generated images
+============================
 
-**A:** Executables and libraries might need to be used from a directory
+What does the OpenEmbedded build system produce as output?
+----------------------------------------------------------
+
+Because you can use the same set of recipes to create output of
+various formats, the output of an OpenEmbedded build depends on how you
+start it. Usually, the output is a flashable image ready for the target
+device.
+
+How do I make the Yocto Project support my board?
+-------------------------------------------------
+
+Support for an additional board is added by creating a Board
+Support Package (BSP) layer for it. For more information on how to
+create a BSP layer, see the
+":ref:`dev-manual/common-tasks:understanding and creating layers`"
+section in the Yocto Project Development Tasks Manual and the
+:doc:`/bsp-guide/index`.
+
+Usually, if the board is not completely exotic, adding support in the
+Yocto Project is fairly straightforward.
+
+How do I make the Yocto Project support my package?
+---------------------------------------------------
+
+To add a package, you need to create a BitBake recipe. For
+information on how to create a BitBake recipe, see the
+":ref:`dev-manual/common-tasks:writing a new recipe`"
+section in the Yocto Project Development Tasks Manual.
+
+What do I need to ship for license compliance?
+----------------------------------------------
+
+This is a difficult question and you need to consult your lawyer
+for the answer for your specific case. It is worth bearing in mind that
+for GPL compliance, there needs to be enough information shipped to
+allow someone else to rebuild and produce the same end result you are
+shipping. This means sharing the source code, any patches applied to it,
+and also any configuration information about how that package was
+configured and built.
+
+You can find more information on licensing in the
+":ref:`overview-manual/development-environment:licensing`"
+section in the Yocto Project Overview and Concepts Manual and also in the
+":ref:`dev-manual/common-tasks:maintaining open source license compliance during your product's lifecycle`"
+section in the Yocto Project Development Tasks Manual.
+
+Do I have to make a full reflash after recompiling one package?
+---------------------------------------------------------------
+
+The OpenEmbedded build system can build packages in various
+formats such as IPK for OPKG, Debian package (``.deb``), or RPM. You can
+then upgrade only the modified packages using the package tools on the device,
+much like on a desktop distribution such as Ubuntu or Fedora. However,
+package management on the target is entirely optional.
+
+How to prevent my package from being marked as machine specific?
+----------------------------------------------------------------
+
+If you have machine-specific data in a package for one machine only
+but the package is being marked as machine-specific in all cases,
+you can set :term:`SRC_URI_OVERRIDES_PACKAGE_ARCH` = "0" in the ``.bb`` file.
+However, 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-global/base.bbclass`` file.
+
+What's the difference between ``target`` and ``target-native``?
+---------------------------------------------------------------
+
+The ``*-native`` targets are designed to run on the system being
+used for the build. These are usually tools that are needed to assist
+the build in some way such as ``quilt-native``, which is used to apply
+patches. The non-native version is the one that runs on the target
+device.
+
+Why do ``${bindir}`` and ``${libdir}`` have strange values for ``-native`` recipes?
+-----------------------------------------------------------------------------------
+
+Executables and libraries might need to be used from a directory
 other than the directory into which they were initially installed.
 Complicating this situation is the fact that sometimes these executables
 and libraries are compiled with the expectation of being run from that
@@ -408,15 +386,9 @@
 that program is never installed directly to the build machine's root
 file system. Consequently, the build system uses paths within the Build
 Directory for ``DESTDIR``, ``bindir`` and related variables. To better
-understand this, consider the following two paths where the first is
-relatively normal and the second is not:
-
-.. note::
-
-   Due to these lengthy examples, the paths are artificially broken
-   across lines for readability.
-
-::
+understand this, consider the following two paths (artificially broken
+across lines for readability) where the first is relatively normal and
+the second is not::
 
    /home/maxtothemax/poky-bootchart2/build/tmp/work/i586-poky-linux/zlib/
       1.2.8-r0/sysroot-destdir/usr/bin
@@ -425,32 +397,76 @@
       zlib-native/1.2.8-r0/sysroot-destdir/home/maxtothemax/poky-bootchart2/
       build/tmp/sysroots/x86_64-linux/usr/bin
 
-Even if the paths look unusual,
-they both are correct --- the first for a target and the second for a
-native recipe. These paths are a consequence of the ``DESTDIR``
-mechanism and while they appear strange, they are correct and in
-practice very effective.
+Even if the paths look unusual, they both are correct --- the first for
+a target and the second for a native recipe. These paths are a consequence
+of the ``DESTDIR`` mechanism and while they appear strange, they are correct
+and in practice very effective.
 
-**Q:** The files provided by my ``*-native`` recipe do not appear to be
-available to other recipes. Files are missing from the native sysroot,
-my recipe is installing to the wrong place, or I am getting permissions
-errors during the :ref:`ref-tasks-install` task in my recipe! What is wrong?
+How do I create images with more free space?
+--------------------------------------------
 
-**A:** This situation results when a build system does not recognize the
-environment variables supplied to it by :term:`BitBake`. The
-incident that prompted this FAQ entry involved a Makefile that used an
-environment variable named ``BINDIR`` instead of the more standard
-variable ``bindir``. The makefile's hardcoded default value of
-"/usr/bin" worked most of the time, but not for the recipe's ``-native``
-variant. For another example, permissions errors might be caused by a
-Makefile that ignores ``DESTDIR`` or uses a different name for that
-environment variable. Check the build system to see if these kinds
-of issues exist.
+By default, the OpenEmbedded build system creates images that are
+1.3 times the size of the populated root filesystem. To affect the image
+size, you need to set various configurations:
 
-**Q:** I'm adding a binary in a recipe but it's different in the image, what is
-changing it?
+-  *Image Size:* The OpenEmbedded build system uses the
+   :term:`IMAGE_ROOTFS_SIZE` variable to define
+   the size of the image in Kbytes. The build system determines the size
+   by taking into account the initial root filesystem size before any
+   modifications such as requested size for the image and any requested
+   additional free disk space to be added to the image.
 
-**A:** The first most obvious change is the system stripping debug symbols from
-it. Setting :term:`INHIBIT_PACKAGE_STRIP` to stop debug symbols being stripped and/or
-:term:`INHIBIT_PACKAGE_DEBUG_SPLIT` to stop debug symbols being split into a separate
-file will ensure the binary is unchanged.
+-  *Overhead:* Use the
+   :term:`IMAGE_OVERHEAD_FACTOR` variable
+   to define the multiplier that the build system applies to the initial
+   image size, which is 1.3 by default.
+
+-  *Additional Free Space:* Use the
+   :term:`IMAGE_ROOTFS_EXTRA_SPACE`
+   variable to add additional free space to the image. The build system
+   adds this space to the image after it determines its
+   :term:`IMAGE_ROOTFS_SIZE`.
+
+Why aren't spaces in path names supported?
+------------------------------------------
+
+The Yocto Project team has tried to do this before but too many
+of the tools the OpenEmbedded build system depends on, such as
+``autoconf``, break when they find spaces in pathnames. Until that
+situation changes, the team will not support spaces in pathnames.
+
+I'm adding a binary in a recipe. Why is it different in the image?
+------------------------------------------------------------------
+
+The first most obvious change is the system stripping debug symbols from
+it. Setting :term:`INHIBIT_PACKAGE_STRIP` to stop debug symbols being
+stripped and/or :term:`INHIBIT_PACKAGE_DEBUG_SPLIT` to stop debug symbols
+being split into a separate file will ensure the binary is unchanged.
+
+Issues on the running system
+============================
+
+How do I disable the cursor on my touchscreen device?
+-----------------------------------------------------
+
+You need to create a form factor file as described in the
+":ref:`bsp-guide/bsp:miscellaneous bsp-specific recipe files`" section in
+the Yocto Project Board Support Packages (BSP) Developer's Guide. Set
+the ``HAVE_TOUCHSCREEN`` variable equal to one as follows::
+
+   HAVE_TOUCHSCREEN=1
+
+How to always bring up connected network interfaces?
+----------------------------------------------------
+
+The default interfaces file provided by the netbase recipe does
+not automatically bring up network interfaces. Therefore, you will need
+to add a BSP-specific netbase that includes an interfaces file. See the
+":ref:`bsp-guide/bsp:miscellaneous bsp-specific recipe files`" section in
+the Yocto Project Board Support Packages (BSP) Developer's Guide for
+information on creating these types of miscellaneous recipe files.
+
+For example, add the following files to your layer::
+
+   meta-MACHINE/recipes-bsp/netbase/netbase/MACHINE/interfaces
+   meta-MACHINE/recipes-bsp/netbase/netbase_5.0.bbappend
diff --git a/poky/documentation/ref-manual/features.rst b/poky/documentation/ref-manual/features.rst
index 5e853ca..a5b01e8 100644
--- a/poky/documentation/ref-manual/features.rst
+++ b/poky/documentation/ref-manual/features.rst
@@ -72,6 +72,8 @@
 
 -  *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 @@
 :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 @@
 -  *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.
@@ -152,29 +164,41 @@
 -  *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.
 
+-  *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
@@ -182,6 +206,13 @@
    ":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
@@ -273,6 +304,9 @@
        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.
@@ -297,6 +331,18 @@
    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.)
+
+-  *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
@@ -304,6 +350,11 @@
    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.
@@ -322,6 +373,21 @@
 
 -  *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
@@ -339,6 +405,8 @@
 -  *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.
diff --git a/poky/documentation/ref-manual/qa-checks.rst b/poky/documentation/ref-manual/qa-checks.rst
index 9455bec..fb31dc1 100644
--- a/poky/documentation/ref-manual/qa-checks.rst
+++ b/poky/documentation/ref-manual/qa-checks.rst
@@ -748,6 +748,22 @@
     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
 ===================================
diff --git a/poky/documentation/ref-manual/release-process.rst b/poky/documentation/ref-manual/release-process.rst
index 8acb4b8..c36fa55 100644
--- a/poky/documentation/ref-manual/release-process.rst
+++ b/poky/documentation/ref-manual/release-process.rst
@@ -127,7 +127,7 @@
    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/poky/documentation/ref-manual/structure.rst b/poky/documentation/ref-manual/structure.rst
index 533745b..fe27d17 100644
--- a/poky/documentation/ref-manual/structure.rst
+++ b/poky/documentation/ref-manual/structure.rst
@@ -669,10 +669,10 @@
 
 .. _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/poky/documentation/ref-manual/tasks.rst b/poky/documentation/ref-manual/tasks.rst
index d4408d1..b17c09c 100644
--- a/poky/documentation/ref-manual/tasks.rst
+++ b/poky/documentation/ref-manual/tasks.rst
@@ -190,8 +190,8 @@
    -  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/poky/documentation/ref-manual/variables.rst b/poky/documentation/ref-manual/variables.rst
index 1685a26..71e8c27 100644
--- a/poky/documentation/ref-manual/variables.rst
+++ b/poky/documentation/ref-manual/variables.rst
@@ -773,7 +773,7 @@
          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.
@@ -920,10 +920,10 @@
       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>`
@@ -1171,12 +1171,10 @@
       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
@@ -1191,6 +1189,11 @@
 
          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
@@ -1466,15 +1469,31 @@
          # This is windows only issue.
          CVE_CHECK_IGNORE += "CVE-2020-15523"
 
+   :term:`CVE_CHECK_SHOW_WARNINGS`
+      Specifies whether or not the :ref:`cve-check <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.
 
+   :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/>`__.
 
-      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.
 
@@ -1812,6 +1831,23 @@
       :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.)
+      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`
@@ -2029,7 +2065,7 @@
       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
@@ -2197,7 +2233,7 @@
       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>`
@@ -2574,7 +2610,7 @@
       :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}", \
@@ -2687,6 +2723,10 @@
       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
@@ -2756,6 +2796,13 @@
       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.
@@ -3041,17 +3088,23 @@
       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
-      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
@@ -3067,7 +3120,7 @@
       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
@@ -3463,7 +3516,7 @@
       - 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
@@ -3546,7 +3599,7 @@
 
 
          Although you can use other settings, you might be required to
-         remove dependencies on or provide alternatives to components that
+         remove dependencies on (or provide alternatives to) components that
          are required to produce a functional system image.
 
    :term:`INCOMPATIBLE_LICENSE_EXCEPTIONS`
@@ -3562,6 +3615,8 @@
       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`"
@@ -3571,6 +3626,9 @@
       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::
 
@@ -3786,7 +3844,7 @@
 
    :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}"
@@ -3812,7 +3870,7 @@
 
    :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}"
@@ -4022,7 +4080,7 @@
       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}"
@@ -4035,7 +4093,7 @@
       :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.
 
@@ -4044,6 +4102,12 @@
       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.
@@ -4059,7 +4123,7 @@
 
    :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}"
@@ -4075,7 +4139,7 @@
 
    :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}"
@@ -4126,7 +4190,7 @@
 
    :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}"
@@ -4142,7 +4206,7 @@
 
    :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}"
@@ -4154,7 +4218,7 @@
 
    :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}"
 
@@ -4182,7 +4246,7 @@
 
    :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}"
 
@@ -4917,7 +4981,7 @@
 
    :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}"
 
@@ -4931,7 +4995,7 @@
 
    :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}"
 
@@ -4940,6 +5004,11 @@
 
          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
@@ -5061,7 +5130,7 @@
       ``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.
 
@@ -5118,6 +5187,87 @@
       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_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
+      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:`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_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
+      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
@@ -6142,6 +6292,14 @@
 
       :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
@@ -6615,6 +6773,11 @@
       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
@@ -6814,6 +6977,10 @@
       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
@@ -8217,7 +8384,7 @@
       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
@@ -8529,6 +8696,10 @@
       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
@@ -8696,6 +8867,9 @@
       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"
@@ -8844,6 +9018,15 @@
       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:`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