build-appliance-image: Update to langdale head revision

(From OE-Core rev: 9237ffc4feee2dd6ff5bdd672072509ef9e82f6d)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

bitbake/doc/bitbake-user-manual/bitbake-user-manual-metadata.rst

@@ -330,7 +330,8 @@ Removal (Override Style Syntax)
 
 You can remove values from lists using the removal override style
 syntax. Specifying a value for removal causes all occurrences of that
-value to be removed from the variable.
+value to be removed from the variable. Unlike ":append" and ":prepend",
+there is no need to add a leading or trailing space to the value.
 
 When you use this syntax, BitBake expects one or more strings.
 Surrounding spaces and spacing are preserved. Here is an example::
@@ -421,6 +422,12 @@ documentation to a BitBake variable as follows::
 
    CACHE[doc] = "The directory holding the cache of the metadata."
 
+.. note::
+
+   Variable flag names starting with an underscore (``_``) character
+   are allowed but are ignored by ``d.getVarFlags("VAR")``
+   in Python code. Such flag names are used internally by BitBake.
+
 Inline Python Variable Expansion
 --------------------------------
 

bitbake/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.rst

@@ -484,29 +484,55 @@ overview of their function and contents.
          for it to work.
 
    :term:`BB_PRESSURE_MAX_CPU`
-      The threshold for maximum CPU pressure before BitBake prevents the
-      scheduling of new tasks. Once the :term:`BB_PRESSURE_MAX_CPU` threshold
-      is exceeded, new tasks are not started until the pressure subsides to
-      below the threshold. If :term:`BB_PRESSURE_MAX_CPU` is not set, CPU
-      pressure is not monitored. A threshold can be set in ``conf/local.conf``
-      as::
+      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 Linux kernels since
+      version 4.20 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).
+
+      This threshold can be set in ``conf/local.conf`` as::
 
          BB_PRESSURE_MAX_CPU = "500"
 
    :term:`BB_PRESSURE_MAX_IO`
-      The threshold for maximum IO pressure experienced before BitBake
-      prevents the scheduling of new tasks. The IO pressure is regulated in the
-      same way as :term:`BB_PRESSURE_MAX_CPU`. At this point in time,
-      experiments show that IO pressure tends to be short-lived and regulating
-      just the CPU can help to reduce it.
+      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 Linux kernels since
+      version 4.20 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).
+
+      At this point in time, experiments show that IO pressure tends to
+      be short-lived and regulating just the CPU with
+      :term:`BB_PRESSURE_MAX_CPU` can help to reduce it.
 
    :term:`BB_PRESSURE_MAX_MEMORY`
-      The threshold for maximum memory pressure experienced before BitBake
-      prevents the scheduling of new tasks. The memory pressure is regulated in
-      the same way as :term:`BB_PRESSURE_MAX_CPU`. Note that any memory
-      pressure indicates that a system is being pushed beyond its capacity. At
-      this point in time, experiments show that memory pressure tends to be
-      short-lived and regulating just the CPU can help to reduce it.
+
+      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 Linux kernels since
+      version 4.20 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_RUNFMT`
       Specifies the name of the executable script files (i.e. run files)

bitbake/lib/bb/asyncrpc/serv.py

@@ -42,7 +42,7 @@ class AsyncServerConnection(object):
 
             # Read protocol and version
             client_protocol = await self.reader.readline()
-            if client_protocol is None:
+            if not client_protocol:
                 return
 
             (client_proto_name, client_proto_version) = client_protocol.decode('utf-8').rstrip().split()
@@ -59,7 +59,7 @@ class AsyncServerConnection(object):
             # an empty line to signal the end of the headers
             while True:
                 line = await self.reader.readline()
-                if line is None:
+                if not line:
                     return
 
                 line = line.decode('utf-8').rstrip()

bitbake/lib/bb/fetch2/git.py

@@ -243,7 +243,7 @@ class Git(FetchMethod):
             for name in ud.names:
                 ud.unresolvedrev[name] = 'HEAD'
 
-        ud.basecmd = d.getVar("FETCHCMD_git") or "git -c core.fsyncobjectfiles=0 -c gc.autoDetach=false -c core.pager=cat"
+        ud.basecmd = d.getVar("FETCHCMD_git") or "git -c gc.autoDetach=false -c core.pager=cat"
 
         write_tarballs = d.getVar("BB_GENERATE_MIRROR_TARBALLS") or "0"
         ud.write_tarballs = write_tarballs != "0" or ud.rebaseable

bitbake/lib/bb/tests/fetch.py

@@ -1331,12 +1331,14 @@ class URLHandle(unittest.TestCase):
        "cvs://anoncvs:anonymous@cvs.handhelds.org/cvs;tag=V0-99-81;module=familiar/dist/ipkg" : ('cvs', 'cvs.handhelds.org', '/cvs', 'anoncvs', 'anonymous', collections.OrderedDict([('tag', 'V0-99-81'), ('module', 'familiar/dist/ipkg')])),
        "git://git.openembedded.org/bitbake;branch=@foo" : ('git', 'git.openembedded.org', '/bitbake', '', '', {'branch': '@foo'}),
        "file://somelocation;someparam=1": ('file', '', 'somelocation', '', '', {'someparam': '1'}),
+       r'git://s.o-me_ONE:!#$%^&*()-_={}[]\|:?,.<>~`@git.openembedded.org/bitbake;branch=main': ('git', 'git.openembedded.org', '/bitbake', 's.o-me_ONE', r'!#$%^&*()-_={}[]\|:?,.<>~`', {'branch': 'main'}),
     }
     # we require a pathname to encodeurl but users can still pass such urls to 
     # decodeurl and we need to handle them
     decodedata = datatable.copy()
     decodedata.update({
        "http://somesite.net;someparam=1": ('http', 'somesite.net', '/', '', '', {'someparam': '1'}),
+       "npmsw://some.registry.url;package=@pkg;version=latest": ('npmsw', 'some.registry.url', '/', '', '', {'package': '@pkg', 'version': 'latest'}),
     })
 
     def test_decodeurl(self):
@@ -1869,7 +1871,7 @@ class GitShallowTest(FetcherTest):
         self.add_empty_file('bsub', cwd=smdir)
 
         self.git('submodule init', cwd=self.srcdir)
-        self.git('submodule add file://%s' % smdir, cwd=self.srcdir)
+        self.git('-c protocol.file.allow=always submodule add file://%s' % smdir, cwd=self.srcdir)
         self.git('submodule update', cwd=self.srcdir)
         self.git('commit -m submodule -a', cwd=self.srcdir)
 
@@ -1899,7 +1901,7 @@ class GitShallowTest(FetcherTest):
         self.add_empty_file('bsub', cwd=smdir)
 
         self.git('submodule init', cwd=self.srcdir)
-        self.git('submodule add file://%s' % smdir, cwd=self.srcdir)
+        self.git('-c protocol.file.allow=always submodule add file://%s' % smdir, cwd=self.srcdir)
         self.git('submodule update', cwd=self.srcdir)
         self.git('commit -m submodule -a', cwd=self.srcdir)
 

bitbake/lib/bb/utils.py

@@ -547,7 +547,12 @@ def md5_file(filename):
     Return the hex string representation of the MD5 checksum of filename.
     """
     import hashlib
-    return _hasher(hashlib.new('MD5', usedforsecurity=False), filename)
+    try:
+        sig = hashlib.new('MD5', usedforsecurity=False)
+    except TypeError:
+        # Some configurations don't appear to support two arguments
+        sig = hashlib.new('MD5')
+    return _hasher(sig, filename)
 
 def sha256_file(filename):
     """

bitbake/lib/bblayers/layerindex.py

@@ -49,6 +49,31 @@ class LayerIndexPlugin(ActionPlugin):
             else:
                 logger.plain("Repository %s needs to be fetched" % url)
                 return subdir, layername, layerdir
+        elif os.path.exists(repodir) and branch:
+            """
+            If the repo is already cloned, ensure it is on the correct branch,
+            switching branches if necessary and possible.
+            """
+            base_cmd = ['git', '--git-dir=%s/.git' % repodir, '--work-tree=%s' % repodir]
+            cmd = base_cmd + ['branch']
+            completed_proc = subprocess.run(cmd, text=True, capture_output=True)
+            if completed_proc.returncode:
+                logger.error("Unable to validate repo %s (%s)" % (repodir, stderr))
+                return None, None, None
+            else:
+                if branch != completed_proc.stdout[2:-1]:
+                    cmd = base_cmd + ['status', '--short']
+                    completed_proc = subprocess.run(cmd, text=True, capture_output=True)
+                    if completed_proc.stdout.count('\n') != 0:
+                        logger.warning("There are uncommitted changes in repo %s" % repodir)
+                    cmd = base_cmd + ['checkout', branch]
+                    completed_proc = subprocess.run(cmd, text=True, capture_output=True)
+                    if completed_proc.returncode:
+                        # Could be due to original shallow clone on a different branch for example
+                        logger.error("Unable to automatically switch %s to desired branch '%s' (%s)"
+                                     % (repodir, branch, completed_proc.stderr))
+                        return None, None, None
+            return subdir, layername, layerdir
         elif os.path.exists(layerdir):
             return subdir, layername, layerdir
         else:

bitbake/lib/ply/yacc.py

@@ -2798,7 +2798,14 @@ class ParserReflect(object):
     def signature(self):
         try:
             import hashlib
+        except ImportError:
+            raise RuntimeError("Unable to import hashlib")
+        try:
             sig = hashlib.new('MD5', usedforsecurity=False)
+        except TypeError:
+            # Some configurations don't appear to support two arguments
+            sig = hashlib.new('MD5')
+        try:
             if self.start:
                 sig.update(self.start.encode('latin-1'))
             if self.prec:

documentation/brief-yoctoprojectqs/index.rst

@@ -25,18 +25,11 @@ build a reference embedded OS called Poky.
       in the Yocto Project Development Tasks Manual for more
       information.
 
-   -  You may use Windows Subsystem For Linux v2 to set up a build host
-      using Windows 10.
-
-      .. note::
-
-         The Yocto Project is not compatible with WSLv1, it is
-         compatible but not officially supported nor validated with
-         WSLv2, if you still decide to use WSL please upgrade to WSLv2.
-
-      See the :ref:`dev-manual/start:setting up to use windows
-      subsystem for linux (wslv2)` section in the Yocto Project Development
-      Tasks Manual for more information.
+   -  You may use version 2 of Windows Subsystem For Linux (WSL 2) to set
+      up a build host using Windows 10 or later, Windows Server 2019 or later.
+      See the :ref:`dev-manual/start:setting up to use windows subsystem for
+      linux (wsl 2)` section in the Yocto Project Development Tasks Manual
+      for more information.
 
 If you want more conceptual or background information on the Yocto
 Project, see the :doc:`/overview-manual/index`.

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
@@ -1731,7 +1731,7 @@ your software is built:
 
       If you need to install one or more custom CMake toolchain files
       that are supplied by the application you are building, install the
-      files to ``${D}${datadir}/cmake/Modules`` during ``do_install``.
+      files to ``${D}${datadir}/cmake/Modules`` during :ref:`ref-tasks-install`.
 
 -  *Other:* If your source files do not have a ``configure.ac`` or
    ``CMakeLists.txt`` file, then your software is built using some
@@ -1826,8 +1826,8 @@ out-of-tree modules. Your recipe will also need the following::
 Compilation
 -----------
 
-During a build, the ``do_compile`` task happens after source is fetched,
-unpacked, and configured. If the recipe passes through ``do_compile``
+During a build, the :ref:`ref-tasks-compile` task happens after source is fetched,
+unpacked, and configured. If the recipe passes through :ref:`ref-tasks-compile`
 successfully, nothing needs to be done.
 
 However, if the compile step fails, you need to diagnose the failure.
@@ -1888,7 +1888,7 @@ Here are some common issues that cause failures.
 Installing
 ----------
 
-During ``do_install``, the task copies the built files along with their
+During :ref:`ref-tasks-install`, the task copies the built files along with their
 hierarchy to locations that would mirror their locations on the target
 device. The installation process copies files from the
 ``${``\ :term:`S`\ ``}``,
@@ -1906,14 +1906,14 @@ the software being built:
 -  *Autotools and CMake:* If the software your recipe is building uses
    Autotools or CMake, the OpenEmbedded build system understands how to
    install the software. Consequently, you do not have to have a
-   ``do_install`` task as part of your recipe. You just need to make
+   :ref:`ref-tasks-install` task as part of your recipe. You just need to make
    sure the install portion of the build completes with no issues.
    However, if you wish to install additional files not already being
    installed by ``make install``, you should do this using a
    ``do_install:append`` function using the install command as described
    in the "Manual" bulleted item later in this list.
 
--  *Other (using* ``make install``\ *)*: You need to define a ``do_install``
+-  *Other (using* ``make install``\ *)*: You need to define a :ref:`ref-tasks-install`
    function in your recipe. The function should call
    ``oe_runmake install`` and will likely need to pass in the
    destination directory as well. How you pass that path is dependent on
@@ -1923,7 +1923,7 @@ the software being built:
    For an example recipe using ``make install``, see the
    ":ref:`dev-manual/common-tasks:makefile-based package`" section.
 
--  *Manual:* You need to define a ``do_install`` function in your
+-  *Manual:* You need to define a :ref:`ref-tasks-install` function in your
    recipe. The function must first use ``install -d`` to create the
    directories under
    ``${``\ :term:`D`\ ``}``. Once the
@@ -1946,10 +1946,10 @@ installed correctly.
       might need to replace hard-coded paths in an initscript with
       values of variables provided by the build system, such as
       replacing ``/usr/bin/`` with ``${bindir}``. If you do perform such
-      modifications during ``do_install``, be sure to modify the
+      modifications during :ref:`ref-tasks-install`, be sure to modify the
       destination file after copying rather than before copying.
       Modifying after copying ensures that the build system can
-      re-execute ``do_install`` if needed.
+      re-execute :ref:`ref-tasks-install` if needed.
 
    -  ``oe_runmake install``, which can be run directly or can be run
       indirectly by the
@@ -1958,7 +1958,7 @@ installed correctly.
       runs ``make install`` in parallel. Sometimes, a Makefile can have
       missing dependencies between targets that can result in race
       conditions. If you experience intermittent failures during
-      ``do_install``, you might be able to work around them by disabling
+      :ref:`ref-tasks-install`, you might be able to work around them by disabling
       parallel Makefile installs by adding the following to the recipe::
 
          PARALLEL_MAKEINST = ""
@@ -1980,7 +1980,7 @@ additional definitions in your recipe.
 If you are adding services and the service initialization script or the
 service file itself is not installed, you must provide for that
 installation in your recipe using a ``do_install:append`` function. If
-your recipe already has a ``do_install`` function, update the function
+your recipe already has a :ref:`ref-tasks-install` function, update the function
 near its end rather than adding an additional ``do_install:append``
 function.
 
@@ -2028,10 +2028,10 @@ Successful packaging is a combination of automated processes performed
 by the OpenEmbedded build system and some specific steps you need to
 take. The following list describes the process:
 
--  *Splitting Files*: The ``do_package`` task splits the files produced
+-  *Splitting Files*: The :ref:`ref-tasks-package` task splits the files produced
    by the recipe into logical components. Even software that produces a
    single binary might still have debug symbols, documentation, and
-   other logical components that should be split out. The ``do_package``
+   other logical components that should be split out. The :ref:`ref-tasks-package`
    task ensures that files are split up and packaged correctly.
 
 -  *Running QA Checks*: The
@@ -2124,7 +2124,7 @@ removed later when a recipe is either modified or removed. Thus, the
 sysroot is able to remain free from stale files.
 
 A subset of the files installed by the :ref:`ref-tasks-install` task are
-used by the :ref:`ref-tasks-populate_sysroot` task as defined by the the
+used by the :ref:`ref-tasks-populate_sysroot` task as defined by the
 :term:`SYSROOT_DIRS` variable to automatically populate the sysroot. It
 is possible to modify the list of directories that populate the sysroot.
 The following example shows how you could add the ``/opt`` directory to
@@ -2337,7 +2337,7 @@ Single .c File Package (Hello World!)
 Building an application from a single file that is stored locally (e.g.
 under ``files``) requires a recipe that has the file listed in the
 :term:`SRC_URI` variable. Additionally, you need to manually write the
-``do_compile`` and ``do_install`` tasks. The :term:`S` variable defines the
+:ref:`ref-tasks-compile` and :ref:`ref-tasks-install` tasks. The :term:`S` variable defines the
 directory containing the source code, which is set to
 :term:`WORKDIR` in this case --- the
 directory BitBake uses for the build.
@@ -2401,14 +2401,14 @@ Makefile-Based Package
 
 Applications that use GNU ``make`` also require a recipe that has the
 source archive listed in :term:`SRC_URI`. You do not need to add a
-``do_compile`` step since by default BitBake starts the ``make`` command
+:ref:`ref-tasks-compile` step since by default BitBake starts the ``make`` command
 to compile the application. If you need additional ``make`` options, you
 should store them in the
 :term:`EXTRA_OEMAKE` or
 :term:`PACKAGECONFIG_CONFARGS`
 variables. BitBake passes these options into the GNU ``make``
-invocation. Note that a ``do_install`` task is still required.
-Otherwise, BitBake runs an empty ``do_install`` task by default.
+invocation. Note that a :ref:`ref-tasks-install` task is still required.
+Otherwise, BitBake runs an empty :ref:`ref-tasks-install` task by default.
 
 Some applications might require extra parameters to be passed to the
 compiler. For example, the application might need an additional header
@@ -2551,7 +2551,7 @@ doing the following:
    ``${``\ :term:`S`\ ``}``.
 
    If ``${S}`` might contain a Makefile, or if you inherit some class
-   that replaces ``do_configure`` and ``do_compile`` with custom
+   that replaces :ref:`ref-tasks-configure` and :ref:`ref-tasks-compile` with custom
    versions, then you can use the
    ``[``\ :ref:`noexec <bitbake-user-manual/bitbake-user-manual-metadata:variable flags>`\ ``]``
    flag to turn the tasks into no-ops, as follows::
@@ -2567,7 +2567,7 @@ doing the following:
    :ref:`ref-tasks-patch` tasks to the
    :ref:`ref-tasks-install` task.
 
--  Make sure your ``do_install`` task installs the binaries
+-  Make sure your :ref:`ref-tasks-install` task installs the binaries
    appropriately.
 
 -  Ensure that you set up :term:`FILES`
@@ -2881,7 +2881,7 @@ you can use as references.
 If you are creating a new kernel recipe, normal recipe-writing rules
 apply for setting up a :term:`SRC_URI`. Thus, you need to specify any
 necessary patches and set :term:`S` to point at the source code. You need to
-create a ``do_configure`` task that configures the unpacked kernel with
+create a :ref:`ref-tasks-configure` task that configures the unpacked kernel with
 a ``defconfig`` file. You can do this by using a ``make defconfig``
 command or, more commonly, by copying in a suitable ``defconfig`` file
 and then running ``make oldconfig``. By making use of ``inherit kernel``
@@ -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::
 
@@ -3446,7 +3446,7 @@ Follow these general steps:
    you added to the patch.
 
 6. *Test Your Changes:* Once you have modified the source code, the
-   easiest way to test your changes is by calling the ``do_compile``
+   easiest way to test your changes is by calling the :ref:`ref-tasks-compile`
    task as shown in the following example::
 
       $ bitbake -c compile -f package
@@ -3458,7 +3458,7 @@ Follow these general steps:
    .. note::
 
       All the modifications you make to the temporary source code disappear
-      once you run the ``do_clean`` or ``do_cleanall`` tasks using BitBake
+      once you run the :ref:`ref-tasks-clean` or :ref:`ref-tasks-cleanall` tasks using BitBake
       (i.e. ``bitbake -c clean package`` and ``bitbake -c cleanall package``).
       Modifications will also disappear if you use the ``rm_work`` feature as
       described in the
@@ -3853,8 +3853,8 @@ to be added to the recipe that builds the ``core-image-sato`` image::
    do_image[mcdepends] = "mc:x86:arm:core-image-minimal:do_rootfs"
 
 In this example, the `from_multiconfig` is "x86". The `to_multiconfig` is "arm". The
-task on which the ``do_image`` task in the recipe depends is the
-``do_rootfs`` task from the ``core-image-minimal`` recipe associated
+task on which the :ref:`ref-tasks-image` task in the recipe depends is the
+:ref:`ref-tasks-rootfs` task from the ``core-image-minimal`` recipe associated
 with the "arm" multiconfig.
 
 Once you set up this dependency, you can build the "x86" multiconfig
@@ -3864,7 +3864,7 @@ using a BitBake command as follows::
 
 This command executes all the tasks needed to create the
 ``core-image-sato`` image for the "x86" multiconfig. Because of the
-dependency, BitBake also executes through the ``do_rootfs`` task for the
+dependency, BitBake also executes through the :ref:`ref-tasks-rootfs` task for the
 "arm" multiconfig build.
 
 Having a recipe depend on the root filesystem of another build might not
@@ -3882,99 +3882,59 @@ and have separate configuration files, BitBake places the artifacts for
 each build in the respective temporary build directories (i.e.
 :term:`TMPDIR`).
 
-Building an Initial RAM Filesystem (initramfs) Image
+Building an Initial RAM Filesystem (Initramfs) Image
 ----------------------------------------------------
 
-An initial RAM filesystem (initramfs) image provides a temporary root
-filesystem used for early system initialization (e.g. loading of modules
-needed to locate and mount the "real" root filesystem).
+An initial RAM filesystem (:term:`Initramfs`) image provides a temporary root
+filesystem used for early system initialization, typically providing tools and
+loading modules needed to locate and mount the final root filesystem.
 
-.. note::
+Follow these steps to create an :term:`Initramfs` image:
 
-   The initramfs image is the successor of initial RAM disk (initrd). It
-   is a "copy in and out" (cpio) archive of the initial filesystem that
-   gets loaded into memory during the Linux startup process. Because
-   Linux uses the contents of the archive during initialization, the
-   initramfs image needs to contain all of the device drivers and tools
-   needed to mount the final root filesystem.
-
-Follow these steps to create an initramfs image:
-
-1. *Create the initramfs Image Recipe:* You can reference the
+1. *Create the Initramfs Image Recipe:* You can reference the
    ``core-image-minimal-initramfs.bb`` recipe found in the
    ``meta/recipes-core`` directory of the :term:`Source Directory`
-   as an example
-   from which to work.
+   as an example from which to work.
 
-2. *Decide if You Need to Bundle the initramfs Image Into the Kernel
-   Image:* If you want the initramfs image that is built to be bundled
-   in with the kernel image, set the
-   :term:`INITRAMFS_IMAGE_BUNDLE`
-   variable to "1" in your ``local.conf`` configuration file and set the
-   :term:`INITRAMFS_IMAGE`
-   variable in the recipe that builds the kernel image.
+2. *Decide if You Need to Bundle the Initramfs Image Into the Kernel
+   Image:* If you want the :term:`Initramfs` image that is built to be bundled
+   in with the kernel image, set the :term:`INITRAMFS_IMAGE_BUNDLE`
+   variable to ``"1"`` in your ``local.conf`` configuration file and set the
+   :term:`INITRAMFS_IMAGE` variable in the recipe that builds the kernel image.
 
-   .. note::
-
-      It is recommended that you bundle the initramfs image with the
-      kernel image to avoid circular dependencies between the kernel
-      recipe and the initramfs recipe should the initramfs image include
-      kernel modules.
-
-   Setting the :term:`INITRAMFS_IMAGE_BUNDLE` flag causes the initramfs
+   Setting the :term:`INITRAMFS_IMAGE_BUNDLE` flag causes the :term:`Initramfs`
    image to be unpacked into the ``${B}/usr/`` directory. The unpacked
-   initramfs image is then passed to the kernel's ``Makefile`` using the
-   :term:`CONFIG_INITRAMFS_SOURCE`
-   variable, allowing the initramfs image to be built into the kernel
-   normally.
+   :term:`Initramfs` image is then passed to the kernel's ``Makefile`` using the
+   :term:`CONFIG_INITRAMFS_SOURCE` variable, allowing the :term:`Initramfs`
+   image to be built into the kernel normally.
 
-   .. note::
+3. *Optionally Add Items to the Initramfs Image Through the Initramfs
+   Image Recipe:* If you add items to the :term:`Initramfs` image by way of its
+   recipe, you should use :term:`PACKAGE_INSTALL` rather than
+   :term:`IMAGE_INSTALL`. :term:`PACKAGE_INSTALL` gives more direct control of
+   what is added to the image as compared to the defaults you might not
+   necessarily want that are set by the :ref:`image <ref-classes-image>`
+   or :ref:`core-image <ref-classes-core-image>` classes.
 
-      Bundling the initramfs with the kernel conflates the code in the initramfs
-      with the GPLv2 licensed Linux kernel binary. Thus only GPLv2 compatible
-      software may be part of a bundled initramfs.
-
-   .. note::
-
-      If you choose to not bundle the initramfs image with the kernel
-      image, you are essentially using an
-      `Initial RAM Disk (initrd) <https://en.wikipedia.org/wiki/Initrd>`__.
-      Creating an initrd is handled primarily through the :term:`INITRD_IMAGE`,
-      ``INITRD_LIVE``, and ``INITRD_IMAGE_LIVE`` variables. For more
-      information, see the :ref:`ref-classes-image-live` file.
-
-3. *Optionally Add Items to the initramfs Image Through the initramfs
-   Image Recipe:* If you add items to the initramfs image by way of its
-   recipe, you should use
-   :term:`PACKAGE_INSTALL`
-   rather than
-   :term:`IMAGE_INSTALL`.
-   :term:`PACKAGE_INSTALL` gives more direct control of what is added to the
-   image as compared to the defaults you might not necessarily want that
-   are set by the :ref:`image <ref-classes-image>`
-   or :ref:`core-image <ref-classes-core-image>`
-   classes.
-
-4. *Build the Kernel Image and the initramfs Image:* Build your kernel
-   image using BitBake. Because the initramfs image recipe is a
-   dependency of the kernel image, the initramfs image is built as well
+4. *Build the Kernel Image and the Initramfs Image:* Build your kernel
+   image using BitBake. Because the :term:`Initramfs` image recipe is a
+   dependency of the kernel image, the :term:`Initramfs` image is built as well
    and bundled with the kernel image if you used the
-   :term:`INITRAMFS_IMAGE_BUNDLE`
-   variable described earlier.
+   :term:`INITRAMFS_IMAGE_BUNDLE` variable described earlier.
 
 Bundling an Initramfs Image From a Separate Multiconfig
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-There may be a case where we want to build an initramfs image which does not
+There may be a case where we want to build an :term:`Initramfs` image which does not
 inherit the same distro policy as our main image, for example, we may want
-our main image to use ``TCLIBC="glibc"``, but to use ``TCLIBC="musl"`` in our initramfs
+our main image to use ``TCLIBC="glibc"``, but to use ``TCLIBC="musl"`` in our :term:`Initramfs`
 image to keep a smaller footprint. However, by performing the steps mentioned
-above the initramfs image will inherit ``TCLIBC="glibc"`` without allowing us
+above the :term:`Initramfs` image will inherit ``TCLIBC="glibc"`` without allowing us
 to override it.
 
 To achieve this, you need to perform some additional steps:
 
-1. *Create a multiconfig for your initramfs image:* You can perform the steps
+1. *Create a multiconfig for your Initramfs image:* You can perform the steps
    on ":ref:`dev-manual/common-tasks:building images for multiple targets using multiple configurations`" to create a separate multiconfig.
    For the sake of simplicity let's assume such multiconfig is called: ``initramfscfg.conf`` and
    contains the variables::
@@ -3982,7 +3942,7 @@ To achieve this, you need to perform some additional steps:
       TMPDIR="${TOPDIR}/tmp-initramfscfg"
       TCLIBC="musl"
 
-2. *Set additional initramfs variables on your main configuration:*
+2. *Set additional Initramfs variables on your main configuration:*
    Additionally, on your main configuration (``local.conf``) you need to set the
    variables::
 
@@ -3995,9 +3955,9 @@ To achieve this, you need to perform some additional steps:
    buildsystem know where the :term:`INITRAMFS_IMAGE` will be located.
 
    Building a system with such configuration will build the kernel using the
-   main configuration but the ``do_bundle_initramfs`` task will grab the
+   main configuration but the :ref:`ref-tasks-bundle_initramfs` task will grab the
    selected :term:`INITRAMFS_IMAGE` from :term:`INITRAMFS_DEPLOY_DIR_IMAGE`
-   instead, resulting in a musl based initramfs image bundled in the kernel
+   instead, resulting in a musl based :term:`Initramfs` image bundled in the kernel
    but a glibc based main image.
 
    The same is applicable to avoid inheriting :term:`DISTRO_FEATURES` on :term:`INITRAMFS_IMAGE`
@@ -4171,7 +4131,7 @@ file::
 Finally, you should consider exactly the type of root filesystem you
 need to meet your needs while also reducing its size. For example,
 consider ``cramfs``, ``squashfs``, ``ubifs``, ``ext2``, or an
-``initramfs`` using ``initramfs``. Be aware that ``ext3`` requires a 1
+:term:`Initramfs` using ``initramfs``. Be aware that ``ext3`` requires a 1
 Mbyte journal. If you are okay with running read-only, you do not need
 this journal.
 
@@ -4740,7 +4700,7 @@ the built library.
 The :term:`PACKAGES` and
 :term:`FILES:* <FILES>` variables in the
 ``meta/conf/bitbake.conf`` configuration file define how files installed
-by the ``do_install`` task are packaged. By default, the :term:`PACKAGES`
+by the :ref:`ref-tasks-install` task are packaged. By default, the :term:`PACKAGES`
 variable includes ``${PN}-staticdev``, which represents all static
 library files.
 
@@ -6902,7 +6862,7 @@ The previous example specifies a number of things in the call to
 ``do_split_packages``.
 
 -  A directory within the files installed by your recipe through
-   ``do_install`` in which to search.
+   :ref:`ref-tasks-install` in which to search.
 
 -  A regular expression used to match module files in that directory. In
    the example, note the parentheses () that mark the part of the
@@ -6929,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::
@@ -8481,7 +8441,7 @@ The following list shows the files produced for SDKs:
    information.
 
 -  ``sstate-task-sizes.txt:`` A text file containing name-value pairs
-   with information about task group sizes (e.g. ``do_populate_sysroot``
+   with information about task group sizes (e.g. :ref:`ref-tasks-populate_sysroot`
    tasks have a total size). The ``sstate-task-sizes.txt`` file exists
    only when an extensible SDK is created.
 
@@ -8802,7 +8762,7 @@ perform a one-time setup of your controller image by doing the following:
    -  Installs normal linux utilities not BusyBox ones (e.g. ``bash``,
       ``coreutils``, ``tar``, ``gzip``, and ``kmod``).
 
-   -  Uses a custom Initial RAM Disk (initramfs) image with a custom
+   -  Uses a custom :term:`Initramfs` image with a custom
       installer. A normal image that you can install usually creates a
       single root filesystem partition. This image uses another installer that
       creates a specific partition layout. Not all Board Support
@@ -8933,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"
@@ -9081,7 +9041,7 @@ Class methods are as follows:
 
 -  *hasPackage(pkg):* Returns "True" if ``pkg`` is in the installed
    package list of the image, which is based on the manifest file that
-   is generated during the ``do_rootfs`` task.
+   is generated during the :ref:`ref-tasks-rootfs` task.
 
 -  *hasFeature(feature):* Returns "True" if the feature is in
    :term:`IMAGE_FEATURES` or
@@ -9633,11 +9593,11 @@ Running Specific Tasks
 ----------------------
 
 Any given recipe consists of a set of tasks. The standard BitBake
-behavior in most cases is: ``do_fetch``, ``do_unpack``, ``do_patch``,
-``do_configure``, ``do_compile``, ``do_install``, ``do_package``,
-``do_package_write_*``, and ``do_build``. The default task is
-``do_build`` and any tasks on which it depends build first. Some tasks,
-such as ``do_devshell``, are not part of the default build chain. If you
+behavior in most cases is: :ref:`ref-tasks-fetch`, :ref:`ref-tasks-unpack`, :ref:`ref-tasks-patch`,
+:ref:`ref-tasks-configure`, :ref:`ref-tasks-compile`, :ref:`ref-tasks-install`, :ref:`ref-tasks-package`,
+:ref:`do_package_write_* <ref-tasks-package_write_deb>`, and :ref:`ref-tasks-build`. The default task is
+:ref:`ref-tasks-build` and any tasks on which it depends build first. Some tasks,
+such as :ref:`ref-tasks-devshell`, are not part of the default build chain. If you
 wish to run a task that is not part of the default build chain, you can
 use the ``-c`` option in BitBake. Here is an example::
 
@@ -9677,7 +9637,7 @@ The following example shows one way you can use the ``-f`` option::
 
 This sequence first builds and then recompiles ``matchbox-desktop``. The
 last command reruns all tasks (basically the packaging tasks) after the
-compile. BitBake recognizes that the ``do_compile`` task was rerun and
+compile. BitBake recognizes that the :ref:`ref-tasks-compile` task was rerun and
 therefore understands that the other tasks also need to be run again.
 
 Another, shorter way to rerun a task and all
@@ -9724,7 +9684,7 @@ task dependency mechanisms.
 
 
 You can view a list of tasks in a given package by running the
-``do_listtasks`` task as follows::
+:ref:`ref-tasks-listtasks` task as follows::
 
    $ bitbake matchbox-desktop -c listtasks
 

documentation/dev-manual/qemu.rst

@@ -123,9 +123,9 @@ available. Follow these general steps to run QEMU:
 
          $ runqemu qemux86-64 core-image-minimal ext4
 
-   -  This example specifies to boot an initial RAM disk image and to
-      enable audio in QEMU. For this case, ``runqemu`` set the internal
-      variable ``FSTYPE`` to "cpio.gz". Also, for audio to be enabled,
+   -  This example specifies to boot an :term:`Initramfs` image and to
+      enable audio in QEMU. For this case, ``runqemu`` sets the internal
+      variable ``FSTYPE`` to ``cpio.gz``. Also, for audio to be enabled,
       an appropriate driver must be installed (see the previous
       description for the ``audio`` option for more information).
       ::
@@ -394,7 +394,7 @@ command line:
    options are basically identical. If you do not provide a MACHINE
    option, ``runqemu`` tries to determine it based on other options.
 
--  ``ramfs``: Indicates you are booting an initial RAM disk (initramfs)
+-  ``ramfs``: Indicates you are booting an :term:`Initramfs`
    image, which means the ``FSTYPE`` is ``cpio.gz``.
 
 -  ``iso``: Indicates you are booting an ISO image, which means the

documentation/dev-manual/start.rst

@@ -267,16 +267,16 @@ development using the Yocto Project. Your build host can be a native
 Linux machine (recommended), it can be a machine (Linux, Mac, or
 Windows) that uses `CROPS <https://github.com/crops/poky-container>`__,
 which leverages `Docker Containers <https://www.docker.com/>`__ or it
-can be a Windows machine capable of running Windows Subsystem For Linux
-v2 (WSL).
+can be a Windows machine capable of running version 2 of Windows Subsystem
+For Linux (WSL 2).
 
 .. note::
 
-   The Yocto Project is not compatible with
-   `Windows Subsystem for Linux v1 <https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux>`__.
-   It is compatible but not officially supported nor validated with
-   WSLv2. If you still decide to use WSL please upgrade to
-   `WSLv2 <https://docs.microsoft.com/en-us/windows/wsl/install-win10>`__.
+   The Yocto Project is not compatible with version 1 of
+   `Windows Subsystem for Linux <https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux>`__.
+   It is compatible but neither officially supported nor validated with
+   WSL 2. If you still decide to use WSL please upgrade to
+   `WSL 2 <https://learn.microsoft.com/en-us/windows/wsl/install>`__.
 
 Once your build host is set up to use the Yocto Project, further steps
 are necessary depending on what you want to accomplish. See the
@@ -441,35 +441,36 @@ Kit (eSDK) manual. If you are going to use the Toaster container, see
 the ":doc:`/toaster-manual/setup-and-use`"
 section in the Toaster User Manual.
 
-Setting Up to Use Windows Subsystem For Linux (WSLv2)
+Setting Up to Use Windows Subsystem For Linux (WSL 2)
 -----------------------------------------------------
 
-With `Windows Subsystem for Linux
-(WSLv2) <https://docs.microsoft.com/en-us/windows/wsl/wsl2-about>`__,
+With `Windows Subsystem for Linux (WSL 2)
+<https://learn.microsoft.com/en-us/windows/wsl/>`__,
 you can create a Yocto Project development environment that allows you
 to build on Windows. You can set up a Linux distribution inside Windows
 in which you can develop using the Yocto Project.
 
-Follow these general steps to prepare a Windows machine using WSLv2 as
+Follow these general steps to prepare a Windows machine using WSL 2 as
 your Yocto Project build host:
 
-1. *Make sure your Windows 10 machine is capable of running WSLv2:*
-   WSLv2 is only available for Windows 10 builds > 18917. To check which
-   build version you are running, you may open a command prompt on
-   Windows and execute the command "ver".
-   ::
+1. *Make sure your Windows machine is capable of running WSL 2:*
+
+   While all Windows 11 and Windows Server 2022 builds support WSL 2,
+   the first versions of Windows 10 and Windows Server 2019 didn't.
+   Check the minimum build numbers for `Windows 10
+   <https://learn.microsoft.com/en-us/windows/wsl/install-manual#step-2---check-requirements-for-running-wsl-2>`__
+   and for `Windows Server 2019
+   <https://learn.microsoft.com/en-us/windows/wsl/install-on-server>`__.
+
+   To check which build version you are running, you may open a command
+   prompt on Windows and execute the command "ver"::
 
       C:\Users\myuser> ver
 
       Microsoft Windows [Version 10.0.19041.153]
 
-   If your build is capable of running
-   WSLv2 you may continue, for more information on this subject or
-   instructions on how to upgrade to WSLv2 visit `Windows 10
-   WSLv2 <https://docs.microsoft.com/en-us/windows/wsl/wsl2-install>`__
-
-2. *Install the Linux distribution of your choice inside Windows 10:*
-   Once you know your version of Windows 10 supports WSLv2, you can
+2. *Install the Linux distribution of your choice inside WSL 2:*
+   Once you know your version of Windows supports WSL 2, you can
    install the distribution of your choice from the Microsoft Store.
    Open the Microsoft Store and search for Linux. While there are
    several Linux distributions available, the assumption is that your
@@ -478,31 +479,28 @@ your Yocto Project build host:
    making your selection, simply click "Get" to download and install the
    distribution.
 
-3. *Check your Linux distribution is using WSLv2:* Open a Windows
+3. *Check which Linux distribution WSL 2 is using:* Open a Windows
    PowerShell and run::
 
       C:\WINDOWS\system32> wsl -l -v
       NAME    STATE   VERSION
       *Ubuntu Running 2
 
-   Note the version column which says the WSL version
-   being used by your distribution, on compatible systems, this can be
-   changed back at any point in time.
+   Note that WSL 2 supports running as many different Linux distributions
+   as you want to install.
 
-4. *Optionally Orient Yourself on WSL:* If you are unfamiliar with WSL,
-   you can learn more here -
+4. *Optionally Get Familiar with WSL:* You can learn more on
    https://docs.microsoft.com/en-us/windows/wsl/wsl2-about.
 
 5. *Launch your WSL Distibution:* From the Windows start menu simply
    launch your WSL distribution just like any other application.
 
-6. *Optimize your WSLv2 storage often:* Due to the way storage is
-   handled on WSLv2, the storage space used by the undelying Linux
-   distribution is not reflected immedately, and since BitBake heavily
+6. *Optimize your WSL 2 storage often:* Due to the way storage is
+   handled on WSL 2, the storage space used by the underlying Linux
+   distribution is not reflected immediately, and since BitBake heavily
    uses storage, after several builds, you may be unaware you are
-   running out of space. WSLv2 uses a VHDX file for storage, this issue
-   can be easily avoided by manually optimizing this file often, this
-   can be done in the following way:
+   running out of space. As WSL 2 uses a VHDX file for storage, this issue
+   can be easily avoided by regularly optimizing this file in a manual way:
 
    1. *Find the location of your VHDX file:*
 
@@ -556,14 +554,14 @@ your Yocto Project build host:
 
 .. note::
 
-   The current implementation of WSLv2 does not have out-of-the-box
+   The current implementation of WSL 2 does not have out-of-the-box
    access to external devices such as those connected through a USB
    port, but it automatically mounts your ``C:`` drive on ``/mnt/c/``
    (and others), which you can use to share deploy artifacts to be later
    flashed on hardware through Windows, but your build directory should
    not reside inside this mountpoint.
 
-Once you have WSLv2 set up, everything is in place to develop just as if
+Once you have WSL 2 set up, everything is in place to develop just as if
 you were running on a native Linux machine. If you are going to use the
 Extensible SDK container, see the ":doc:`/sdk-manual/extensible`" Chapter in the Yocto
 Project Application Development and the Extensible Software Development

documentation/kernel-dev/common.rst

@@ -1316,7 +1316,7 @@ In order to run this task, you must have an existing ``.config`` file.
 See the ":ref:`kernel-dev/common:using \`\`menuconfig\`\``" section for
 information on how to create a configuration file.
 
-Following is sample output from the ``do_kernel_configcheck`` task:
+Following is sample output from the :ref:`ref-tasks-kernel_configcheck` task:
 
 .. code-block:: none
 
@@ -1396,7 +1396,7 @@ possible by reading the output of the kernel configuration fragment
 audit, noting any issues, making changes to correct the issues, and then
 repeating.
 
-As part of the kernel build process, the ``do_kernel_configcheck`` task
+As part of the kernel build process, the :ref:`ref-tasks-kernel_configcheck` task
 runs. This task validates the kernel configuration by checking the final
 ``.config`` file against the input files. During the check, the task
 produces warning messages for the following issues:
@@ -1430,13 +1430,13 @@ To streamline the configuration, do the following:
    successfully. Use this configuration file as your baseline.
 
 2. *Run Configure and Check Tasks:* Separately run the
-   ``do_kernel_configme`` and ``do_kernel_configcheck`` tasks::
+   :ref:`ref-tasks-kernel_configme` and :ref:`ref-tasks-kernel_configcheck` tasks::
 
       $ bitbake linux-yocto -c kernel_configme -f
       $ bitbake linux-yocto -c kernel_configcheck -f
 
 3. *Process the Results:* Take the resulting list of files from the
-   ``do_kernel_configcheck`` task warnings and do the following:
+   :ref:`ref-tasks-kernel_configcheck` task warnings and do the following:
 
    -  Drop values that are redefined in the fragment but do not change
       the final ``.config`` file.
@@ -1450,7 +1450,7 @@ To streamline the configuration, do the following:
 
 4. *Re-Run Configure and Check Tasks:* After you have worked through the
    output of the kernel configuration audit, you can re-run the
-   ``do_kernel_configme`` and ``do_kernel_configcheck`` tasks to see the
+   :ref:`ref-tasks-kernel_configme` and :ref:`ref-tasks-kernel_configcheck` tasks to see the
    results of your changes. If you have more issues, you can deal with
    them as described in the previous step.
 

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

documentation/migration-guides/migration-1.3.rst

@@ -62,7 +62,7 @@ Previously, an inconsistent mix of spaces and tabs existed, which made
 extending these functions using ``_append`` or ``_prepend`` complicated
 given that Python treats whitespace as syntactically significant. If you
 are defining or extending any Python functions (e.g.
-``populate_packages``, ``do_unpack``, ``do_patch`` and so forth) in
+``populate_packages``, :ref:`ref-tasks-unpack`, :ref:`ref-tasks-patch` and so forth) in
 custom recipes or classes, you need to ensure you are using consistent
 four-space indentation.
 

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

documentation/migration-guides/migration-1.7.rst

@@ -165,7 +165,7 @@ The following changes have occurred to the QA check process:
    more parallel execution. This change is unlikely to be an issue
    except for highly customized recipes that disable packaging tasks
    themselves by marking them as ``noexec``. For those packages, you
-   will need to disable the ``do_package_qa`` task as well.
+   will need to disable the :ref:`ref-tasks-package_qa` task as well.
 
 -  Files being overwritten during the
    :ref:`ref-tasks-populate_sysroot` task now

documentation/migration-guides/migration-1.8.rst

@@ -84,7 +84,7 @@ where the ``linux.inc`` file in ``meta-oe`` was updated.
 
 Recipes that rely on the kernel source code and do not inherit the
 module classes might need to add explicit dependencies on the
-``do_shared_workdir`` kernel task, for example::
+:ref:`ref-tasks-shared_workdir` kernel task, for example::
 
    do_configure[depends] += "virtual/kernel:do_shared_workdir"
 
@@ -128,7 +128,7 @@ when the :ref:`ref-tasks-configure` task needs to be
 re-executed.
 
 One of the improvements is to attempt to run "make clean" during the
-``do_configure`` task if a ``Makefile`` exists. Some software packages
+:ref:`ref-tasks-configure` task if a ``Makefile`` exists. Some software packages
 do not provide a working clean target within their make files. If you
 have such recipes, you need to set
 :term:`CLEANBROKEN` to "1" within the recipe, for example::

documentation/migration-guides/migration-2.1.rst

@@ -108,12 +108,12 @@ this change should not be a problem. However, if you have a recipe that
 bypasses the standard :ref:`ref-tasks-configure` task
 from the :ref:`autotools <ref-classes-autotools>` class and the software the recipe is building
 uses a very old version of ``autoconf``, the recipe might be incapable
-of determining the correct size of ``off_t`` during ``do_configure``.
+of determining the correct size of ``off_t`` during :ref:`ref-tasks-configure`.
 
 The best course of action is to patch the software as necessary to allow
 the default implementation from the :ref:`autotools <ref-classes-autotools>` class to work such
 that ``autoreconf`` succeeds and produces a working configure script,
-and to remove the overridden ``do_configure`` task such that the default
+and to remove the overridden :ref:`ref-tasks-configure` task such that the default
 implementation does get used.
 
 .. _migration-2.1-image-generation-split-out-from-filesystem-generation:
@@ -128,12 +128,12 @@ separate :ref:`ref-tasks-image` tasks for clarity both in
 operation and in the code.
 
 For most cases, this change does not present any problems. However, if
-you have made customizations that directly modify the ``do_rootfs`` task
-or that mention ``do_rootfs``, you might need to update those changes.
-In particular, if you had added any tasks after ``do_rootfs``, you
+you have made customizations that directly modify the :ref:`ref-tasks-rootfs` task
+or that mention :ref:`ref-tasks-rootfs`, you might need to update those changes.
+In particular, if you had added any tasks after :ref:`ref-tasks-rootfs`, you
 should make edits so that those tasks are after the
 :ref:`ref-tasks-image-complete` task rather than
-after ``do_rootfs`` so that your added tasks run at the correct
+after :ref:`ref-tasks-rootfs` so that your added tasks run at the correct
 time.
 
 A minor part of this restructuring is that the post-processing

documentation/migration-guides/migration-2.4.rst

@@ -54,7 +54,7 @@ occurred:
       when "pam" is in :term:`DISTRO_FEATURES`.
 
    -  The ``switch_root`` program is now packaged in a separate
-      "util-linux-switch-root" package for small initramfs images that
+      "util-linux-switch-root" package for small :term:`Initramfs` images that
       do not need the whole ``util-linux`` package or the busybox
       binary, which are both much larger than ``switch_root``. The main
       ``util-linux`` package has a recommended runtime dependency (i.e.

documentation/migration-guides/migration-2.5.rst

@@ -261,7 +261,7 @@ The following are additional changes:
    ``pkg_postinst_ontarget()`` or call
    ``postinst_intercept delay_to_first_boot`` from ``pkg_postinst()``.
    Any failure of a ``pkg_postinst()`` script (including ``exit 1``)
-   will trigger a warning during ``do_rootfs``.
+   will trigger a warning during :ref:`ref-tasks-rootfs`.
 
    For more information, see the
    ":ref:`dev-manual/common-tasks:post-installation scripts`"

documentation/migration-guides/migration-2.6.rst

@@ -135,7 +135,7 @@ Fetching these types of dependencies that are not provided in the
 sysroot negatively affects the ability to reproduce builds. This type of
 fetching is now explicitly disabled. Consequently, any missing
 dependencies in Python recipes that use these classes now result in an
-error during the ``do_configure`` task.
+error during the :ref:`ref-tasks-configure` task.
 
 .. _migration-2.6-linux-yocto-configuration-audit-issues-now-correctly-reported:
 
@@ -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.
 

documentation/migration-guides/migration-3.1.rst

@@ -234,7 +234,7 @@ Packaging changes
 Additional warnings
 -------------------
 
-Warnings will now be shown at ``do_package_qa`` time in the following
+Warnings will now be shown at :ref:`ref-tasks-package_qa` time in the following
 circumstances:
 
 -  A recipe installs ``.desktop`` files containing ``MimeType`` keys but

documentation/migration-guides/migration-3.2.rst

@@ -60,7 +60,7 @@ pseudo as the interprocess round trip to the server is avoided.
 
 There is a possible complication where some existing recipe may break, for
 example, a recipe was found to be writing to ``${B}/install`` for
-``make install`` in ``do_install`` and since ``${B}`` is listed as not to be tracked,
+``make install`` in :ref:`ref-tasks-install` and since ``${B}`` is listed as not to be tracked,
 there were errors trying to ``chown root`` for files in this location. Another
 example was the ``tcl`` recipe where the source directory :term:`S` is set to a
 subdirectory of the source tree but files were written out to the directory
@@ -191,7 +191,7 @@ Globbing no longer supported in ``file://`` entries in ``SRC_URI``
 
 Globbing (``*`` and ``?`` wildcards) in ``file://`` URLs within :term:`SRC_URI`
 did not properly support file checksums, thus changes to the source files
-would not always change the do_fetch task checksum, and consequently would
+would not always change the :ref:`ref-tasks-fetch` task checksum, and consequently would
 not ensure that the changed files would be incorporated in subsequent builds.
 
 Unfortunately it is not practical to make globbing work generically here, so
@@ -207,9 +207,9 @@ files into a subdirectory and reference that instead.
 deploy class now cleans ``DEPLOYDIR`` before ``do_deploy``
 ----------------------------------------------------------
 
-``do_deploy`` as implemented in the :ref:`deploy <ref-classes-deploy>` class now cleans up ${:term:`DEPLOYDIR`} before running, just as ``do_install`` cleans up ${:term:`D`} before running. This reduces the risk of :term:`DEPLOYDIR` being accidentally contaminated by files from previous runs, possibly even with different config, in case of incremental builds.
+:ref:`ref-tasks-deploy` as implemented in the :ref:`deploy <ref-classes-deploy>` class now cleans up ${:term:`DEPLOYDIR`} before running, just as :ref:`ref-tasks-install` cleans up ${:term:`D`} before running. This reduces the risk of :term:`DEPLOYDIR` being accidentally contaminated by files from previous runs, possibly even with different config, in case of incremental builds.
 
-Most recipes and classes that inherit the :ref:`deploy <ref-classes-deploy>` class or interact with ``do_deploy`` are unlikely to be affected by this unless they add ``prefuncs`` to ``do_deploy`` *which also* put files into ``${DEPLOYDIR}`` --- these should be refactored to use ``do_deploy_prepend`` instead.
+Most recipes and classes that inherit the :ref:`deploy <ref-classes-deploy>` class or interact with :ref:`ref-tasks-deploy` are unlikely to be affected by this unless they add ``prefuncs`` to :ref:`ref-tasks-deploy` *which also* put files into ``${DEPLOYDIR}`` --- these should be refactored to use ``do_deploy_prepend`` instead.
 
 
 .. _migration-3.2-nativesdk-sdk-provides-dummy:
@@ -265,10 +265,10 @@ using the GL options.
 
 .. _migration-3.2-initramfs-suffix:
 
-initramfs images now use a blank suffix
+Initramfs images now use a blank suffix
 ---------------------------------------
 
-The reference initramfs images (``core-image-minimal-initramfs``,
+The reference :term:`Initramfs` images (``core-image-minimal-initramfs``,
 ``core-image-tiny-initramfs`` and ``core-image-testmaster-initramfs``) now
 set an empty string for :term:`IMAGE_NAME_SUFFIX`, which otherwise defaults
 to ``".rootfs"``. These images aren't root filesystems and thus the rootfs

documentation/migration-guides/migration-3.4.rst

@@ -22,7 +22,7 @@ syntax, so the following::
 
    SRC_URI_append = " file://somefile"
    SRC_URI_append_qemux86 = " file://somefile2"
-   SRC_URI_remove_qemux86-64 = " file://somefile3"
+   SRC_URI_remove_qemux86-64 = "file://somefile3"
    SRC_URI_prepend_qemuarm = "file://somefile4 "
    FILES_${PN}-ptest = "${bindir}/xyz"
    IMAGE_CMD_tar = "tar"
@@ -34,7 +34,7 @@ would now become::
 
    SRC_URI:append = " file://somefile"
    SRC_URI:append:qemux86 = " file://somefile2"
-   SRC_URI:remove:qemux86-64 = " file://somefile3"
+   SRC_URI:remove:qemux86-64 = "file://somefile3"
    SRC_URI:prepend:qemuarm = "file://somefile4 "
    FILES:${PN}-ptest = "${bindir}/xyz"
    IMAGE_CMD:tar = "tar"
@@ -206,7 +206,7 @@ Package/recipe splitting
 Image / SDK generation changes
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-- Recursive dependencies on the ``do_build`` task are now disabled when
+- Recursive dependencies on the :ref:`ref-tasks-build` task are now disabled when
   building SDKs. These are generally not needed; in the unlikely event
   that you do encounter problems then it will probably be as a result of
   missing explicit dependencies that need to be added.

documentation/migration-guides/migration-4.0.rst

@@ -93,8 +93,8 @@ Fetching changes
 
      do_mytask[network] = "1"
 
-  This is allowed by default from ``do_fetch`` but not from any of our other standard
-  tasks. Recipes shouldn't be accessing the network outside of ``do_fetch`` as it
+  This is allowed by default from :ref:`ref-tasks-fetch` but not from any of our other standard
+  tasks. Recipes shouldn't be accessing the network outside of :ref:`ref-tasks-fetch` as it
   usually undermines fetcher source mirroring, image and licence manifests, software
   auditing and supply chain security.
 
@@ -145,7 +145,7 @@ Python changes
   :ref:`python_setuptools_build_meta <ref-classes-python_setuptools_build_meta>`
   and :ref:`python_poetry_core <ref-classes-python_poetry_core>`.  
 
-- The :ref:`setuptools3 <ref-classes-setuptools3>` class ``do_install()`` task now
+- The :ref:`setuptools3 <ref-classes-setuptools3>` class :ref:`ref-tasks-install` task now
   installs the ``wheel`` binary archive. In current versions of ``setuptools`` the
   legacy ``setup.py install`` method is deprecated. If the ``setup.py`` cannot be used
   with wheels, for example it creates files outside of the Python module or standard

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)

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 on 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`.

documentation/migration-guides/release-4.0.rst

@@ -8,3 +8,4 @@ Release 4.0 (kirkstone)
    release-notes-4.0.1
    release-notes-4.0.2
    release-notes-4.0.3
+   release-notes-4.0.4

documentation/migration-guides/release-4.1.rst

@@ -0,0 +1,7 @@
+Release 4.1 (langdale)
+======================
+
+.. toctree::
+
+   migration-4.1
+   release-notes-4.1

documentation/migration-guides/release-notes-3.4.2.rst

@@ -167,7 +167,7 @@ Contributors to 3.4.2
 -  Vyacheslav Yurkov
 -  Yongxin Liu
 -  pgowda
--  wangmy
+-  Wang Mingyu
 
 Repositories / Downloads for 3.4.2
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

documentation/migration-guides/release-notes-3.4.3.rst

@@ -124,7 +124,7 @@ Contributors to 3.4.3
 -  Tean Cunningham
 -  Zoltán Böszörményi
 -  pgowda
--  wangmy
+-  Wang Mingyu
 
 Repositories / Downloads for 3.4.3
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

documentation/migration-guides/release-notes-3.4.4.rst

@@ -81,8 +81,8 @@ Contributors to 3.4.4
 -  Richard Purdie
 -  Ross Burton
 -  Tim Orling
--  wangmy
--  zhengruoqin
+-  Wang Mingyu
+-  Zheng Ruoqin
 
 Repositories / Downloads for 3.4.4
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

documentation/migration-guides/release-notes-3.4.rst

@@ -36,7 +36,7 @@ New Features / Enhancements in 3.4
 
 -  Kernel-related enhancements:
 
-   -  Support zstd-compressed modules and initramfs images
+   -  Support zstd-compressed modules and :term:`Initramfs` images
    -  Allow opt-out of split kernel modules
    -  linux-yocto-dev: base AUTOREV on specified version
    -  kernel-yocto: provide debug / summary information for metadata
@@ -67,7 +67,7 @@ New Features / Enhancements in 3.4
 
 -  SDK-related enhancements:
 
-   -  Enable do_populate_sdk with multilibs
+   -  Enable :ref:`ref-tasks-populate_sdk` with multilibs
    -  New ``SDKPATHINSTALL`` variable decouples default install path from built in path to avoid rebuilding nativesdk components on e.g. :term:`DISTRO_VERSION` changes
    -  eSDK: Error if trying to generate an eSDK from a multiconfig
    -  eSDK: introduce :term:`TOOLCHAIN_HOST_TASK_ESDK` to be used in place of :term:`TOOLCHAIN_HOST_TASK` to add components to the host part of the eSDK
@@ -211,7 +211,7 @@ The following corrections have been made to the LICENSE values set by recipes:
 Other license-related notes:
 
 -  When creating recipes for Python software, recipetool will now treat "BSD" as "BSD-3-Clause" for the purposes of setting LICENSE, as that is the most common understanding.
--  Please be aware that an initramfs bundled with the kernel using :term:`INITRAMFS_IMAGE_BUNDLE` should only contain GPLv2-compatible software; this is now mentioned in the documentation.
+-  Please be aware that an :term:`Initramfs` bundled with the kernel using :term:`INITRAMFS_IMAGE_BUNDLE` should only contain GPLv2-compatible software; this is now mentioned in the documentation.
 
 Security Fixes in 3.4
 ~~~~~~~~~~~~~~~~~~~~~

documentation/migration-guides/release-notes-4.0.1.rst

@@ -174,8 +174,8 @@ Contributors to 4.0.1
 -  Ross Burton
 -  Russ Dill
 -  Steve Sakoman
--  wangmy
--  zhengruoqin
+-  Wang Mingyu
+-  Zheng Ruoqin
 
 Repositories / Downloads for 4.0.1
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

documentation/migration-guides/release-notes-4.0.2.rst

@@ -223,7 +223,7 @@ Contributors to Yocto-4.0.2
 -  Xiaobing Luo
 -  Yi Zhao
 -  leimaohui
--  wangmy
+-  Wang Mingyu
 
 Repositories / Downloads for Yocto-4.0.2
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

documentation/migration-guides/release-notes-4.0.3.rst

@@ -239,7 +239,7 @@ Contributors to Yocto-4.0.3
 -  Yue Tao
 -  gr embeter
 -  leimaohui
--  wangmy
+-  Wang Mingyu
 
 
 Repositories / Downloads for Yocto-4.0.3

documentation/migration-guides/release-notes-4.0.4.rst

@@ -0,0 +1,299 @@
+Release notes for Yocto-4.0.4 (Kirkstone)
+-----------------------------------------
+
+Security Fixes in Yocto-4.0.4
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  binutils : fix :cve:`2022-38533`
+-  curl: fix :cve:`2022-35252`
+-  sqlite: fix :cve:`2022-35737`
+-  grub2: fix :cve:`2021-3695`, :cve:`2021-3696`, :cve:`2021-3697`, :cve:`2022-28733`, :cve:`2022-28734` and :cve:`2022-28735`
+-  u-boot: fix :cve:`2022-30552` and :cve:`2022-33967`
+-  libxml2: Ignore :cve:`2016-3709`
+-  libtiff: fix :cve:`2022-34526`
+-  zlib: fix :cve:`2022-37434`
+-  gnutls: fix :cve:`2022-2509`
+-  u-boot: fix :cve:`2022-33103`
+-  qemu: fix :cve:`2021-3507`, :cve:`2021-3929`, :cve:`2021-4158`, :cve:`2022-0216` and :cve:`2022-0358`
+
+
+Fixes in Yocto-4.0.4
+~~~~~~~~~~~~~~~~~~~~
+
+-  apr: Cache configure tests which use AC_TRY_RUN
+-  apr: Use correct strerror_r implementation based on libc type
+-  apt: fix nativesdk-apt build failure during the second time build
+-  archiver.bbclass: remove unsed do_deploy_archives[dirs]
+-  archiver.bbclass: some recipes that uses the kernelsrc bbclass uses the shared source
+-  autoconf: Fix strict prototype errors in generated tests
+-  autoconf: Update K & R stype functions
+-  bind: upgrade to 9.18.5
+-  bitbake.conf: set BB_DEFAULT_UMASK using ??=
+-  bitbake: ConfHandler/BBHandler: Improve comment error messages and add tests
+-  bitbake: ConfHandler: Remove lingering close
+-  bitbake: bb/utils: movefile: use the logger for printing
+-  bitbake: bb/utils: remove: check the path again the expand python glob
+-  bitbake: bitbake-user-manual: Correct description of the ??= operator
+-  bitbake: bitbake-user-manual: npm fetcher: improve description of SRC_URI format
+-  bitbake: bitbake: bitbake-user-manual: hashserv can be accessed on a dedicated domain
+-  bitbake: bitbake: runqueue: add cpu/io pressure regulation
+-  bitbake: bitbake: runqueue: add memory pressure regulation
+-  bitbake: cooker: Drop sre_constants usage
+-  bitbake: doc: bitbake-user-manual: add explicit target for crates fetcher
+-  bitbake: doc: bitbake-user-manual: document npm and npmsw fetchers
+-  bitbake: event.py: ignore exceptions from stdout and sterr operations in atexit
+-  bitbake: fetch2: Ensure directory exists before creating symlink
+-  bitbake: fetch2: gitsm: fix incorrect handling of git submodule relative urls
+-  bitbake: runqueue: Change pressure file warning to a note
+-  bitbake: runqueue: Fix unihash cache mismatch issues
+-  bitbake: toaster: fix kirkstone version
+-  bitbake: utils: Pass lock argument in fileslocked
+-  bluez5: upgrade to 5.65
+-  boost: fix install of fiber shared libraries
+-  cairo: Adapt the license information based on what is being built
+-  classes: cve-check: Get shared database lock
+-  cmake: remove CMAKE_ASM_FLAGS variable in toolchain file
+-  connman: Backports for security fixes
+-  core-image.bbclass: Exclude openssh complementary packages
+-  cracklib: Drop using register keyword
+-  cracklib: upgrade to 2.9.8
+-  create-spdx: Fix supplier field
+-  create-spdx: handle links to inaccessible locations
+-  create-spdx: ignore packing control files from ipk and deb
+-  cve-check: Don't use f-strings
+-  cve-check: close cursors as soon as possible
+-  devtool/upgrade: catch bb.fetch2.decodeurl errors
+-  devtool/upgrade: correctly clean up when recipe filename isn't yet known
+-  devtool: error out when workspace is using old override syntax
+-  ell: upgrade to 0.50
+-  epiphany: upgrade to 42.4
+-  externalsrc: Don't wipe out src dir when EXPORT_FUNCTIONS is used.
+-  gcc-multilib-config: Fix i686 toolchain relocation issues
+-  gcr: Define _GNU_SOURCE
+-  gdk-pixbuf: upgrade to 2.42.9
+-  glib-networking: upgrade to 2.72.2
+-  go: upgrade to v1.17.13
+-  insane.bbclass: Skip patches not in oe-core by full path
+-  iso-codes: upgrade to 4.11.0
+-  kernel-fitimage.bbclass: add padding algorithm property in config nodes
+-  kernel-fitimage.bbclass: only package unique DTBs
+-  kernel: Always set CC and LD for the kernel build
+-  kernel: Use consistent make flags for menuconfig
+-  lib:npm_registry: initial checkin
+-  libatomic-ops: upgrade to 7.6.14
+-  libcap: upgrade to 2.65
+-  libjpeg-turbo: upgrade to 2.1.4
+-  libpam: use /run instead of /var/run in systemd tmpfiles
+-  libtasn1: upgrade to 4.19.0
+-  liburcu: upgrade to 0.13.2
+-  libwebp: upgrade to 1.2.4
+-  libwpe: upgrade to 1.12.3
+-  libxml2: Port gentest.py to Python-3
+-  lighttpd: upgrade to 1.4.66
+-  linux-yocto/5.10: update genericx86* machines to v5.10.135
+-  linux-yocto/5.10: update to v5.10.137
+-  linux-yocto/5.15: update genericx86* machines to v5.15.59
+-  linux-yocto/5.15: update to v5.15.62
+-  linux-yocto: Fix COMPATIBLE_MACHINE regex match
+-  linux-yocto: prepend the value with a space when append to KERNEL_EXTRA_ARGS
+-  lttng-modules: fix 5.19+ build
+-  lttng-modules: fix build against mips and v5.19 kernel
+-  lttng-modules: fix build for kernel 5.10.137
+-  lttng-modules: replace mips compaction fix with upstream change
+-  lz4: upgrade to 1.9.4
+-  maintainers: update opkg maintainer
+-  meta: introduce UBOOT_MKIMAGE_KERNEL_TYPE
+-  migration guides: add missing release notes
+-  mobile-broadband-provider-info: upgrade to 20220725
+-  nativesdk: Clear TUNE_FEATURES
+-  npm: replace 'npm pack' call by 'tar czf'
+-  npm: return content of 'package.json' in 'npm_pack'
+-  npm: take 'version' directly from 'package.json'
+-  npm: use npm_registry to cache package
+-  oeqa/gotoolchain: put writable files in the Go module cache
+-  oeqa/gotoolchain: set CGO_ENABLED=1
+-  oeqa/parselogs: add qemuarmv5 arm-charlcd masking
+-  oeqa/qemurunner: add run_serial() comment
+-  oeqa/selftest: rename git.py to intercept.py
+-  oeqa: qemurunner: Report UNIX Epoch timestamp on login
+-  package_rpm: Do not replace square brackets in %files
+-  packagegroup-self-hosted: update for strace
+-  parselogs: Ignore xf86OpenConsole error
+-  perf: Fix reproducibility issues with 5.19 onwards
+-  pinentry: enable _XOPEN_SOURCE on musl for wchar usage in curses
+-  poky.conf: add ubuntu-22.04 to tested distros
+-  poky.conf: bump version for 4.0.4
+-  pseudo: Update to include recent upstream minor fixes
+-  python3-pip: Fix RDEPENDS after the update
+-  ref-manual: add numa to machine features
+-  relocate_sdk.py: ensure interpreter size error causes relocation to fail
+-  rootfs-postcommands.bbclass: avoid moving ssh host keys if etc is writable
+-  rootfs.py: dont try to list installed packages for baremetal images
+-  rootfspostcommands.py: Cleanup subid backup files generated by shadow-utils
+-  ruby: drop capstone support
+-  runqemu: Add missing space on default display option
+-  runqemu: display host uptime when starting
+-  sanity: add a comment to ensure CONNECTIVITY_CHECK_URIS is correct
+-  scripts/oe-setup-builddir: make it known where configurations come from
+-  scripts/runqemu.README: fix typos and trailing whitespaces
+-  selftest/wic: Tweak test case to not depend on kernel size
+-  shadow: Avoid nss warning/error with musl
+-  shadow: Enable subid support
+-  system-requirements.rst: Add Ubuntu 22.04 to list of supported distros
+-  systemd: Add 'no-dns-fallback' PACKAGECONFIG option
+-  systemd: Fix unwritable /var/lock when no sysvinit handling
+-  sysvinit-inittab/start_getty: Fix respawn too fast
+-  tcp-wrappers: Fix implicit-function-declaration warnings
+-  tzdata: upgrade to 2022b
+-  util-linux: Remove --enable-raw from EXTRA_OECONF
+-  vala: upgrade to 0.56.3
+-  vim: Upgrade to 9.0.0453
+-  watchdog: Include needed system header for function decls
+-  webkitgtk: upgrade to 2.36.5
+-  weston: upgrade to 10.0.2
+-  wic/bootimg-efi: use cross objcopy when building unified kernel image
+-  wic: add target tools to PATH when executing native commands
+-  wic: depend on cross-binutils
+-  wireless-regdb: upgrade to 2022.08.12
+-  wpebackend-fdo: upgrade to 1.12.1
+-  xinetd: Pass missing -D_GNU_SOURCE
+-  xz: update to 5.2.6
+
+
+Known Issues in Yocto-4.0.4
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+- N/A
+
+
+Contributors to Yocto-4.0.4
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  Alejandro Hernandez Samaniego
+-  Alex Stewart
+-  Alexander Kanavin
+-  Alexandre Belloni
+-  Andrei Gherzan
+-  Anuj Mittal
+-  Aryaman Gupta
+-  Awais Belal
+-  Beniamin Sandu
+-  Bertrand Marquis
+-  Bruce Ashfield
+-  Changqing Li
+-  Chee Yang Lee
+-  Daiane Angolini
+-  Enrico Scholz
+-  Ernst Sjöstrand
+-  Gennaro Iorio
+-  Hitendra Prajapati
+-  Jacob Kroon
+-  Jon Mason
+-  Jose Quaresma
+-  Joshua Watt
+-  Kai Kang
+-  Khem Raj
+-  Kristian Amlie
+-  LUIS ENRIQUEZ
+-  Mark Hatle
+-  Martin Beeger
+-  Martin Jansa
+-  Mateusz Marciniec
+-  Michael Opdenacker
+-  Mihai Lindner
+-  Mikko Rapeli
+-  Ming Liu
+-  Niko Mauno
+-  Ola x Nilsson
+-  Otavio Salvador
+-  Paul Eggleton
+-  Pavel Zhukov
+-  Peter Bergin
+-  Peter Kjellerstedt
+-  Peter Marko
+-  Rajesh Dangi
+-  Randy MacLeod
+-  Rasmus Villemoes
+-  Richard Purdie
+-  Robert Joslyn
+-  Roland Hieber
+-  Ross Burton
+-  Sakib Sajal
+-  Shubham Kulkarni
+-  Steve Sakoman
+-  Ulrich Ölmann
+-  Yang Xu
+-  Yongxin Liu
+-  ghassaneben
+-  pgowda
+-  Wang Mingyu
+
+Repositories / Downloads for Yocto-4.0.4
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+poky
+
+-  Repository Location: https://git.yoctoproject.org/git/poky
+-  Branch: :yocto_git:`kirkstone </poky/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.4 </poky/log/?h=yocto-4.0.4>`
+-  Git Revision: :yocto_git:`d64bef1c7d713b92a51228e5ade945835e5a94a4 </poky/commit/?id=d64bef1c7d713b92a51228e5ade945835e5a94a4>`
+-  Release Artefact: poky-d64bef1c7d713b92a51228e5ade945835e5a94a4
+-  sha: b5e92506b31f88445755bad2f45978b747ad1a5bea66ca897370542df5f1e7db
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.4/poky-d64bef1c7d713b92a51228e5ade945835e5a94a4.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.4/poky-d64bef1c7d713b92a51228e5ade945835e5a94a4.tar.bz2
+
+openembedded-core
+
+-  Repository Location: https://git.openembedded.org/openembedded-core
+-  Branch: :oe_git:`kirkstone </openembedded-core/log/?h=kirkstone>`
+-  Tag:  :oe_git:`yocto-4.0.4 </openembedded-core/log/?h=yocto-4.0.4>`
+-  Git Revision: :oe_git:`f7766da462905ec67bf549d46b8017be36cd5b2a </openembedded-core/commit/?id=f7766da462905ec67bf549d46b8017be36cd5b2a>`
+-  Release Artefact: oecore-f7766da462905ec67bf549d46b8017be36cd5b2a
+-  sha: ce0ac011474db5e5f0bb1be3fb97f890a02e46252a719dbcac5813268e48ff16
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.4/oecore-f7766da462905ec67bf549d46b8017be36cd5b2a.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.4/oecore-f7766da462905ec67bf549d46b8017be36cd5b2a.tar.bz2
+
+meta-mingw
+
+-  Repository Location: https://git.yoctoproject.org/git/meta-mingw
+-  Branch: :yocto_git:`kirkstone </meta-mingw/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.4 </meta-mingw/log/?h=yocto-4.0.4>`
+-  Git Revision: :yocto_git:`a90614a6498c3345704e9611f2842eb933dc51c1 </meta-mingw/commit/?id=a90614a6498c3345704e9611f2842eb933dc51c1>`
+-  Release Artefact: meta-mingw-a90614a6498c3345704e9611f2842eb933dc51c1
+-  sha: 49f9900bfbbc1c68136f8115b314e95d0b7f6be75edf36a75d9bcd1cca7c6302
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.4/meta-mingw-a90614a6498c3345704e9611f2842eb933dc51c1.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.4/meta-mingw-a90614a6498c3345704e9611f2842eb933dc51c1.tar.bz2
+
+meta-gplv2
+
+-  Repository Location: https://git.yoctoproject.org/git/meta-gplv2
+-  Branch: :yocto_git:`kirkstone </meta-gplv2/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.4 </meta-gplv2/log/?h=yocto-4.0.4>`
+-  Git Revision: :yocto_git:`d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a </meta-gplv2/commit/?id=d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a>`
+-  Release Artefact: meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a
+-  sha: c386f59f8a672747dc3d0be1d4234b6039273d0e57933eb87caa20f56b9cca6d
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.4/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.4/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2
+
+bitbake
+
+-  Repository Location: https://git.openembedded.org/bitbake
+-  Branch: :oe_git:`2.0 </bitbake/log/?h=2.0>`
+-  Tag:  :oe_git:`yocto-4.0.4 </bitbake/log/?h=yocto-4.0.4>`
+-  Git Revision: :oe_git:`ac576d6fad6bba0cfea931883f25264ea83747ca </bitbake/commit/?id=ac576d6fad6bba0cfea931883f25264ea83747ca>`
+-  Release Artefact: bitbake-ac576d6fad6bba0cfea931883f25264ea83747ca
+-  sha: 526c2768874eeda61ade8c9ddb3113c90d36ef44a026d6690f02de6f3dd0ea12
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.4/bitbake-ac576d6fad6bba0cfea931883f25264ea83747ca.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.4/bitbake-ac576d6fad6bba0cfea931883f25264ea83747ca.tar.bz2
+
+yocto-docs
+
+-  Repository Location: https://git.yoctoproject.org/git/yocto-docs
+-  Branch: :yocto_git:`kirkstone </yocto-docs/log/?h=kirkstone>`
+-  Tag: :yocto_git:`yocto-4.0.4 </yocto-docs/log/?h=yocto-4.0.4>`
+-  Git Revision: :yocto_git:`f632dad24c39778f948014029e74db3c871d9d21 </yocto-docs/commit/?id=f632dad24c39778f948014029e74db3c871d9d21>`

documentation/migration-guides/release-notes-4.0.rst

@@ -30,7 +30,7 @@ New Features / Enhancements in 4.0
 
 - New :ref:`overlayfs <ref-classes-overlayfs>` and
   :ref:`overlayfs-etc <ref-classes-overlayfs-etc>` classes and
-  ``overlayroot`` support in the initramfs framework to make it easier to
+  ``overlayroot`` support in the :term:`Initramfs` framework to make it easier to
   overlay read-only filesystems (for example) with
   `OverlayFS <https://en.wikipedia.org/wiki/OverlayFS>`__.
 
@@ -168,7 +168,7 @@ New Features / Enhancements in 4.0
 
 -  Kernel-related enhancements:
 
-   - Allow initramfs to be built from a separate multiconfig
+   - Allow :term:`Initramfs` to be built from a separate multiconfig
    - Make kernel-base recommend kernel-image, not depend (allowing images containing kernel modules without kernel image)
    - linux-yocto: split vtpm for more granular inclusion
    - linux-yocto: cfg/debug: add configs for kcsan
@@ -182,7 +182,7 @@ New Features / Enhancements in 4.0
 
 - FIT image related enhancements:
 
-   - New ``FIT_SUPPORTED_INITRAMFS_FSTYPES`` variable to allow extending initramfs image types to look for
+   - New ``FIT_SUPPORTED_INITRAMFS_FSTYPES`` variable to allow extending :term:`Initramfs` image types to look for
    - New ``FIT_CONF_PREFIX`` variable to allow overriding FIT configuration prefix
    - Use 'bbnote' for better logging
 
@@ -276,7 +276,7 @@ New Features / Enhancements in 4.0
 - volatile-binds: SELinux and overlayfs extensions in mount-copybind
 - gtk-icon-cache: Allow using gtk4
 - kmod: Add an exclude directive to depmod
-- os-release: add os-release-initrd package for use in systemd-based initramfs images
+- os-release: add os-release-initrd package for use in systemd-based :term:`Initramfs` images
 - gstreamer1.0-plugins-base: add support for graphene
 - gpg-sign: Add parameters to gpg signature function
 - package_manager: sign DEB package feeds

documentation/migration-guides/release-notes-4.1.rst

@@ -0,0 +1,758 @@
+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`` 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
+~~~~~~~~~~~~~~~~~~~
+
+- The change to :ref:`migration-4.1-complementary-deps` means that images
+  built with the ``ptest-pkgs`` :term:`IMAGE_FEATURES` don’t automatically
+  install ``ptest-runner``, as that package is a recommendation of the
+  individual ``-ptest`` packages.  This will be resolved in the next point
+  release, and can be worked around by explicitly installing ``ptest-runner``
+  into the image.  Filed as :yocto_bugs:`bug 14928 </show_bug.cgi?id=14928>`.
+
+- There is a known issue with eSDKs where sstate objects may be missing,
+  resulting in packages being unavailable to install in the sysroot. This is due
+  to image generation optimisations having unintended consequences in eSDK
+  generation. This will be resolved in the next point release.  Filed as
+  :yocto_bugs:`bug 14626 </show_bug.cgi?id=14626>`, which also details the fix.
+
+- The change to :ref:`migration-4.1-classes-split` inadvertently moved the
+  :ref:`externalsrc <ref-classes-externalsrc>` class to ``meta/classes-recipe``,
+  when it is not recipe-specific and can also be used in a global context.  The
+  class will be moved back to ``meta/classes`` in the next point release.  Filed
+  as :yocto_bugs:`bug 14940 </show_bug.cgi?id=14940>`.
+
+
+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
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+poky
+
+-  Repository Location: https://git.yoctoproject.org/git/poky
+-  Branch: :yocto_git:`langdale </poky/log/?h=langdale>`
+-  Tag:  :yocto_git:`yocto-4.1 </poky/log/?h=yocto-4.1>`
+-  Git Revision: :yocto_git:`5200799866b92259e855051112520006e1aaaac0 </poky/commit/?id=5200799866b92259e855051112520006e1aaaac0>`
+-  Release Artefact: poky-5200799866b92259e855051112520006e1aaaac0
+-  sha: 9d9a2f7ecf2502f89f43bf45d63e6b61cdcb95ed1d75c8281372f550d809c823
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.1/poky-5200799866b92259e855051112520006e1aaaac0.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.1/poky-5200799866b92259e855051112520006e1aaaac0.tar.bz2
+
+openembedded-core
+
+-  Repository Location: https://git.openembedded.org/openembedded-core
+-  Branch: :oe_git:`langdale </openembedded-core/log/?h=langdale>`
+-  Tag:  :oe_git:`yocto-4.1 </openembedded-core/log/?h=yocto-4.1>`
+-  Git Revision: :oe_git:`744a2277844ec9a384a9ca7dae2a634d5a0d3590 </openembedded-core/commit/?id=744a2277844ec9a384a9ca7dae2a634d5a0d3590>`
+-  Release Artefact: oecore-744a2277844ec9a384a9ca7dae2a634d5a0d3590
+-  sha: 34f1fd5bb83514bf0ec8ad7f8cce088a8e28677e1338db94c188283da704c663
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.1/oecore-744a2277844ec9a384a9ca7dae2a634d5a0d3590.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.1/oecore-744a2277844ec9a384a9ca7dae2a634d5a0d3590.tar.bz2
+
+meta-mingw
+
+-  Repository Location: https://git.yoctoproject.org/git/meta-mingw
+-  Branch: :yocto_git:`langdale </meta-mingw/log/?h=langdale>`
+-  Tag:  :yocto_git:`yocto-4.1 </meta-mingw/log/?h=yocto-4.1>`
+-  Git Revision: :yocto_git:`b0067202db8573df3d23d199f82987cebe1bee2c </meta-mingw/commit/?id=b0067202db8573df3d23d199f82987cebe1bee2c>`
+-  Release Artefact: meta-mingw-b0067202db8573df3d23d199f82987cebe1bee2c
+-  sha: 704f2940322b81ce774e9cbd27c3cfa843111d497dc7b1eeaa39cd694d9a2366
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.1/meta-mingw-b0067202db8573df3d23d199f82987cebe1bee2c.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.1/meta-mingw-b0067202db8573df3d23d199f82987cebe1bee2c.tar.bz2
+
+bitbake
+
+-  Repository Location: https://git.openembedded.org/bitbake
+-  Branch: :oe_git:`2.2 </bitbake/log/?h=2.2>`
+-  Tag:  :oe_git:`yocto-4.1 </bitbake/log/?h=yocto-4.1>`
+-  Git Revision: :oe_git:`074da4c469d1f4177a1c5be72b9f3ccdfd379d67 </bitbake/commit/?id=074da4c469d1f4177a1c5be72b9f3ccdfd379d67>`
+-  Release Artefact: bitbake-074da4c469d1f4177a1c5be72b9f3ccdfd379d67
+-  sha: e32c300e0c8522d8d49ef10aae473bd5f293202672eb9d38e90ed92594ed1fe8
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.1/bitbake-074da4c469d1f4177a1c5be72b9f3ccdfd379d67.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.1/bitbake-074da4c469d1f4177a1c5be72b9f3ccdfd379d67.tar.bz2
+
+yocto-docs
+
+-  Repository Location: https://git.yoctoproject.org/git/yocto-docs
+-  Branch: :yocto_git:`langdale </yocto-docs/log/?h=langdale>`
+-  Tag: :yocto_git:`yocto-4.1 </yocto-docs/log/?h=yocto-4.1>`
+-  Git Revision: :yocto_git:`42d3e26a0d04bc5951e640b471686f347dc9b74a </yocto-docs/commit/?id=42d3e26a0d04bc5951e640b471686f347dc9b74a>`

documentation/overview-manual/concepts.rst

@@ -703,16 +703,12 @@ the source files and unpack them into the
 
 .. note::
 
-   For every local file (e.g.
-   file://
-   ) that is part of a recipe's
-   SRC_URI
-   statement, the OpenEmbedded build system takes a checksum of the file
-   for the recipe and inserts the checksum into the signature for the
-   do_fetch
-   task. If any local file has been modified, the
-   do_fetch
-   task and all tasks that depend on it are re-executed.
+   For every local file (e.g. ``file://``) that is part of a recipe's
+   :term:`SRC_URI` statement, the OpenEmbedded build system takes a
+   checksum of the file for the recipe and inserts the checksum into
+   the signature for the :ref:`ref-tasks-fetch` task. If any local
+   file has been modified, the :ref:`ref-tasks-fetch` task and all
+   tasks that depend on it are re-executed.
 
 By default, everything is accomplished in the Build Directory, which has
 a defined structure. For additional general information on the Build
@@ -857,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
@@ -892,7 +888,7 @@ following as well as other items: splitting out debugging symbols,
 looking at shared library dependencies between packages, and looking at
 package relationships.
 
-The ``do_packagedata`` task creates package metadata based on the
+The :ref:`ref-tasks-packagedata` task creates package metadata based on the
 analysis such that the build system can generate the final packages. The
 :ref:`ref-tasks-populate_sysroot`
 task stages (copies) a subset of the files installed by the
@@ -905,7 +901,7 @@ the analysis and package splitting process use several areas:
    individual packages.
 
 -  :term:`PKGDESTWORK`: A
-   temporary work area (i.e. ``pkgdata``) used by the ``do_package``
+   temporary work area (i.e. ``pkgdata``) used by the :ref:`ref-tasks-package`
    task to save package metadata.
 
 -  :term:`PKGDEST`: The parent
@@ -935,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>`
@@ -1012,13 +1008,13 @@ all the post installation scripts must succeed on the build host during
 the package installation phase since the root filesystem on the target
 is read-only.
 
-The final stages of the ``do_rootfs`` task handle post processing. Post
+The final stages of the :ref:`ref-tasks-rootfs` task handle post processing. Post
 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.
@@ -1036,7 +1032,7 @@ the
 variable. This variable specifies a list of functions to call before the
 build system creates the final image output files.
 
-The build system dynamically creates ``do_image_*`` tasks as needed,
+The build system dynamically creates :ref:`do_image_* <ref-tasks-image>` tasks as needed,
 based on the image types specified in the
 :term:`IMAGE_FSTYPES` variable.
 The process turns everything into an image file or a set of image files
@@ -1085,7 +1081,7 @@ the extensible SDK (eSDK):
    For more information on the cross-development toolchain generation,
    see the ":ref:`overview-manual/concepts:cross-development toolchain generation`"
    section. For information on advantages gained when building a
-   cross-development toolchain using the do_populate_sdk task, see the
+   cross-development toolchain using the :ref:`ref-tasks-populate_sdk` task, see the
    ":ref:`sdk-manual/appendix-obtain:building an sdk installer`" section in
    the Yocto Project Application Development and the Extensible Software
    Development Kit (eSDK) manual.
@@ -1100,13 +1096,13 @@ actually install. For information on the variables listed in the figure,
 see the ":ref:`overview-manual/concepts:application development sdk`"
 section.
 
-The ``do_populate_sdk`` task helps create the standard SDK and handles
+The :ref:`ref-tasks-populate_sdk` task helps create the standard SDK and handles
 two parts: a target part and a host part. The target part is the part
 built for the target hardware and includes libraries and headers. The
 host part is the part of the SDK that runs on the
 :term:`SDKMACHINE`.
 
-The ``do_populate_sdk_ext`` task helps create the extensible SDK and
+The :ref:`ref-tasks-populate_sdk_ext` task helps create the extensible SDK and
 handles host and target parts differently than its counter part does for
 the standard SDK. For the extensible SDK, the task encapsulates the
 build system, which includes everything needed (host and target) for the
@@ -1198,7 +1194,7 @@ the work involved would be equal to or greater than the underlying task.
 
 In the build system, the common tasks that have setscene variants are
 :ref:`ref-tasks-package`,
-``do_package_write_*``,
+:ref:`do_package_write_* <ref-tasks-package_write_deb>`,
 :ref:`ref-tasks-deploy`,
 :ref:`ref-tasks-packagedata`, and
 :ref:`ref-tasks-populate_sysroot`.
@@ -1208,15 +1204,15 @@ end result.
 The build system has knowledge of the relationship between these tasks
 and other preceding tasks. For example, if BitBake runs
 ``do_populate_sysroot_setscene`` for something, it does not make sense
-to run any of the ``do_fetch``, ``do_unpack``, ``do_patch``,
-``do_configure``, ``do_compile``, and ``do_install`` tasks. However, if
-``do_package`` needs to be run, BitBake needs to run those other tasks.
+to run any of the :ref:`ref-tasks-fetch`, :ref:`ref-tasks-unpack`, :ref:`ref-tasks-patch`,
+:ref:`ref-tasks-configure`, :ref:`ref-tasks-compile`, and :ref:`ref-tasks-install` tasks. However, if
+:ref:`ref-tasks-package` needs to be run, BitBake needs to run those other tasks.
 
 It becomes more complicated if everything can come from an sstate cache
 because some objects are simply not required at all. For example, you do
 not need a compiler or native tools, such as quilt, if there isn't anything
-to compile or patch. If the ``do_package_write_*`` packages are available
-from sstate, BitBake does not need the ``do_package`` task data.
+to compile or patch. If the :ref:`do_package_write_* <ref-tasks-package_write_deb>` packages are available
+from sstate, BitBake does not need the :ref:`ref-tasks-package` task data.
 
 To handle all these complexities, BitBake runs in two phases. The first
 is the "setscene" stage. During this stage, BitBake first checks the
@@ -1435,7 +1431,7 @@ toolchain construction and use.
    :width: 100%
 
 Most of the work occurs on the Build Host. This is the machine used to
-build images and generally work within the the Yocto Project
+build images and generally work within the Yocto Project
 environment. When you run
 :term:`BitBake` to create an image, the
 OpenEmbedded build system uses the host ``gcc`` compiler to bootstrap a
@@ -1801,14 +1797,14 @@ from the :ref:`deploy <ref-classes-deploy>` class::
 
 The following list explains the previous example:
 
--  Adding "do_deploy" to ``SSTATETASKS`` adds some required
+-  Adding ``do_deploy`` to ``SSTATETASKS`` adds some required
    sstate-related processing, which is implemented in the
    :ref:`sstate <ref-classes-sstate>` class, to
    before and after the
    :ref:`ref-tasks-deploy` task.
 
 -  The ``do_deploy[sstate-inputdirs] = "${DEPLOYDIR}"`` declares that
-   ``do_deploy`` places its output in ``${DEPLOYDIR}`` when run normally
+   :ref:`ref-tasks-deploy` places its output in ``${DEPLOYDIR}`` when run normally
    (i.e. when not using the sstate cache). This output becomes the input
    to the shared state cache.
 
@@ -1818,15 +1814,15 @@ The following list explains the previous example:
 
    .. note::
 
-      If ``do_deploy`` is not already in the shared state cache or if its input
+      If :ref:`ref-tasks-deploy` is not already in the shared state cache or if its input
       checksum (signature) has changed from when the output was cached, the task
       runs to populate the shared state cache, after which the contents of the
       shared state cache is copied to ${:term:`DEPLOY_DIR_IMAGE`}. If
-      ``do_deploy`` is in the shared state cache and its signature indicates
+      :ref:`ref-tasks-deploy` is in the shared state cache and its signature indicates
       that the cached output is still valid (i.e. if no relevant task inputs
       have changed), then the contents of the shared state cache copies
       directly to ${:term:`DEPLOY_DIR_IMAGE`} by the ``do_deploy_setscene`` task
-      instead, skipping the ``do_deploy`` task.
+      instead, skipping the :ref:`ref-tasks-deploy` task.
 
 -  The following task definition is glue logic needed to make the
    previous settings effective::
@@ -1836,16 +1832,16 @@ The following list explains the previous example:
       }
       addtask do_deploy_setscene
 
-  ``sstate_setscene()`` takes the flags above as input and accelerates the ``do_deploy`` task
+  ``sstate_setscene()`` takes the flags above as input and accelerates the :ref:`ref-tasks-deploy` task
   through the shared state cache if possible. If the task was
   accelerated, ``sstate_setscene()`` returns True. Otherwise, it
-  returns False, and the normal ``do_deploy`` task runs. For more
+  returns False, and the normal :ref:`ref-tasks-deploy` task runs. For more
   information, see the ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-execution:setscene`"
   section in the BitBake User Manual.
 
 -  The ``do_deploy[dirs] = "${DEPLOYDIR} ${B}"`` line creates
-   ``${DEPLOYDIR}`` and ``${B}`` before the ``do_deploy`` task runs, and
-   also sets the current working directory of ``do_deploy`` to ``${B}``.
+   ``${DEPLOYDIR}`` and ``${B}`` before the :ref:`ref-tasks-deploy` task runs, and
+   also sets the current working directory of :ref:`ref-tasks-deploy` to ``${B}``.
    For more information, see the ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata:variable flags`"
    section in the BitBake
    User Manual.
@@ -1854,7 +1850,7 @@ The following list explains the previous example:
 
       In cases where ``sstate-inputdirs`` and ``sstate-outputdirs`` would be
       the same, you can use ``sstate-plaindirs``. For example, to preserve the
-      ${:term:`PKGD`} and ${:term:`PKGDEST`} output from the ``do_package``
+      ${:term:`PKGD`} and ${:term:`PKGDEST`} output from the :ref:`ref-tasks-package`
       task, use the following::
 
               do_package[sstate-plaindirs] = "${PKGD} ${PKGDEST}"
@@ -2101,12 +2097,12 @@ dependencies, you must manually declare the dependencies.
    :term:`PRIVATE_LIBS` inside
    the package's recipe.
 
--  ``pcdeps``: During the ``do_package`` task of each recipe, all
+-  ``pcdeps``: During the :ref:`ref-tasks-package` task of each recipe, all
    pkg-config modules (``*.pc`` files) installed by the recipe are
    located. For each module, the package that contains the module is
    registered as providing the module. The resulting module-to-package
    mapping is saved globally in :term:`PKGDATA_DIR` by the
-   ``do_packagedata`` task.
+   :ref:`ref-tasks-packagedata` task.
 
    Simultaneously, all pkg-config modules installed by the recipe are
    inspected to see what other pkg-config modules they depend on. A
@@ -2147,7 +2143,7 @@ dependencies, you must manually declare the dependencies.
    :term:`ALLOW_EMPTY` variable
    for more information.
 
-The ``do_package`` task depends on the ``do_packagedata`` task of each
+The :ref:`ref-tasks-package` task depends on the :ref:`ref-tasks-packagedata` task of each
 recipe in :term:`DEPENDS` through use
 of a ``[``\ :ref:`deptask <bitbake:bitbake-user-manual/bitbake-user-manual-metadata:variable flags>`\ ``]``
 declaration, which guarantees that the required
@@ -2162,8 +2158,8 @@ operations that are normally reserved for the root user (e.g.
 :ref:`ref-tasks-install`,
 :ref:`do_package_write* <ref-tasks-package_write_deb>`,
 :ref:`ref-tasks-rootfs`, and
-:ref:`do_image* <ref-tasks-image>`). For example,
-the ``do_install`` task benefits from being able to set the UID and GID
+:ref:`do_image_* <ref-tasks-image>`). For example,
+the :ref:`ref-tasks-install` task benefits from being able to set the UID and GID
 of installed files to arbitrary values.
 
 One approach to allowing tasks to perform root-only operations would be

documentation/overview-manual/yp-intro.rst

@@ -584,20 +584,15 @@ Build Host runs, you have several choices.
    ":ref:`dev-manual/start:setting up to use cross platforms (crops)`"
    section in the Yocto Project Development Tasks Manual.
 
--  *Windows Subsystem For Linux (WSLv2):* You may use Windows Subsystem
-   For Linux v2 to set up a Build Host using Windows 10.
+-  *Windows Subsystem For Linux (WSL 2):* You may use Windows Subsystem
+   For Linux version 2 to set up a Build Host using Windows 10 or later,
+   or Windows Server 2019 or later.
 
-   .. note::
-
-      The Yocto Project is not compatible with WSLv1, it is compatible
-      but not officially supported nor validated with WSLv2, if you
-      still decide to use WSL please upgrade to WSLv2.
-
-   The Windows Subsystem For Linux allows Windows 10 to run a real Linux
+   The Windows Subsystem For Linux allows Windows to run a real Linux
    kernel inside of a lightweight virtual machine (VM).
 
-   For information on how to set up a Build Host with WSLv2, see the
-   ":ref:`dev-manual/start:setting up to use windows subsystem for linux (wslv2)`"
+   For information on how to set up a Build Host with WSL 2, see the
+   ":ref:`dev-manual/start:setting up to use windows subsystem for linux (wsl 2)`"
    section in the Yocto Project Development Tasks Manual.
 
 -  *Toaster:* Regardless of what your Build Host is running, you can use

documentation/poky.yaml.in

@@ -1,10 +1,10 @@
-DISTRO : "4.0"
-DISTRO_NAME_NO_CAP : "kirkstone"
-DISTRO_NAME : "Kirkstone"
-DISTRO_NAME_NO_CAP_MINUS_ONE : "honister"
-DISTRO_NAME_NO_CAP_LTS : "dunfell"
-YOCTO_DOC_VERSION : "4.0"
-DISTRO_REL_TAG : "yocto-4.0"
+DISTRO : "4.1"
+DISTRO_NAME_NO_CAP : "langdale"
+DISTRO_NAME : "Langdale"
+DISTRO_NAME_NO_CAP_MINUS_ONE : "kirkstone"
+DISTRO_NAME_NO_CAP_LTS : "kirkstone"
+YOCTO_DOC_VERSION : "4.1"
+DISTRO_REL_TAG : "yocto-4.1"
 DOCCONF_VERSION : "dev"
 BITBAKE_SERIES : ""
 YOCTO_DL_URL : "https://downloads.yoctoproject.org"

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 @@ OpenEmbedded, with changes always being merged to OE-Core or BitBake
 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,253 +34,33 @@ section for steps on how to update your build tools.
 -  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`.
+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.
 
-Usually, if the board is not completely exotic, adding support in the
-Yocto Project is fairly straightforward.
+Building environment
+====================
 
-**Q:** Are there any products built using the OpenEmbedded build system?
+Missing dependencies on the development system?
+-----------------------------------------------
 
-**A:** The software running on the `Vernier
-LabQuest <https://vernier.com/labquest/>`__ is built using the
-OpenEmbedded build system. See the `Vernier
-LabQuest <https://www.vernier.com/products/interfaces/labq/>`__ website
-for more information. There are a number of pre-production devices using
-the OpenEmbedded build system and the Yocto Project team announces them
-as soon as they are released.
+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.
 
-**Q:** What does the OpenEmbedded build system produce as output?
+How does OpenEmbedded fetch source code? Will it work through a firewall or proxy server?
+-----------------------------------------------------------------------------------------
 
-**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.
-
-**Q:** How do I add my package to the Yocto Project?
-
-**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.
-
-**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.
 
@@ -325,16 +102,15 @@ Here is another technique::
 
    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.
 
@@ -353,9 +129,32 @@ These changes would cause the build system to successfully fetch source
 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::
 
@@ -363,23 +162,199 @@ redirect requests through proxy servers.
    ":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
@@ -411,15 +386,9 @@ native program (i.e. one that is intended to run on the build machine),
 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
@@ -428,32 +397,76 @@ relatively normal and the second is not:
       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 do_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

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.
@@ -152,29 +164,41 @@ 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.
 
+-  *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 @@ 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
@@ -273,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.
@@ -297,6 +331,18 @@ 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.)
+
+-  *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 @@ 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.
@@ -322,6 +373,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
@@ -339,6 +405,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.

documentation/ref-manual/images.rst

@@ -78,11 +78,11 @@ Following is a list of supported recipes:
    libraries you can use in a host development environment.
 
 -  ``core-image-minimal-initramfs``: A ``core-image-minimal`` image that
-   has the Minimal RAM-based Initial Root Filesystem (initramfs) as part
+   has the Minimal RAM-based Initial Root Filesystem (:term:`Initramfs`) as part
    of the kernel, which allows the system to find the first "init"
    program more efficiently. See the
    :term:`PACKAGE_INSTALL` variable for
-   additional information helpful when working with initramfs images.
+   additional information helpful when working with :term:`Initramfs` images.
 
 -  ``core-image-minimal-mtdutils``: A ``core-image-minimal`` image that
    has support for the Minimal MTD Utilities, which let the user
@@ -121,7 +121,7 @@ Following is a list of supported recipes:
    section in the Yocto Project Development Tasks Manual.
 
 -  ``core-image-testmaster-initramfs``: A RAM-based Initial Root
-   Filesystem (initramfs) image tailored for use with the
+   Filesystem (:term:`Initramfs`) image tailored for use with the
    ``core-image-testmaster`` image.
 
 -  ``core-image-weston``: A very basic Wayland image with a terminal.

documentation/ref-manual/qa-checks.rst

@@ -162,7 +162,7 @@ Errors and Warnings
    normally expected to be empty (such as ``/tmp``). These files may
    be more appropriately installed to a different location, or
    perhaps alternatively not installed at all, usually by updating the
-   ``do_install`` task/function.
+   :ref:`ref-tasks-install` task/function.
 
 .. _qa-check-arch:
 
@@ -536,7 +536,7 @@ Errors and Warnings
       in (e.g. ``FILES:${``\ :term:`PN`\ ``}`` for the main
       package).
 
-   -  Delete the files at the end of the ``do_install`` task if the
+   -  Delete the files at the end of the :ref:`ref-tasks-install` task if the
       files are not needed in any package.
 
     
@@ -582,7 +582,7 @@ Errors and Warnings
    ``${datadir}/mime/packages``) and yet does not inherit the mime
    class which will ensure that these get properly installed. Either
    add ``inherit mime`` to the recipe or remove the files at the
-   ``do_install`` step if they are not needed.
+   :ref:`ref-tasks-install` step if they are not needed.
 
 
 .. _qa-check-mime-xdg:
@@ -592,7 +592,7 @@ Errors and Warnings
     The specified package contains a .desktop file with a 'MimeType' key
     present, but does not inherit the mime-xdg class that is required in
     order for that to be activated. Either add ``inherit mime`` to the
-    recipe or remove the files at the ``do_install`` step if they are not
+    recipe or remove the files at the :ref:`ref-tasks-install` step if they are not
     needed.
 
 
@@ -667,8 +667,8 @@ Errors and Warnings
 
     If ``usrmerge`` is in :term:`DISTRO_FEATURES`, this check will ensure that no package
     installs files to root (``/bin``, ``/sbin``, ``/lib``, ``/lib64``) directories. If you are seeing this
-    message, it indicates that the ``do_install`` step (or perhaps the build process that
-    ``do_install`` is calling into, e.g. ``make install`` is using hardcoded paths instead
+    message, it indicates that the :ref:`ref-tasks-install` step (or perhaps the build process that
+    :ref:`ref-tasks-install` is calling into, e.g. ``make install`` is using hardcoded paths instead
     of the variables set up for this (``bindir``, ``sbindir``, etc.), and should be
     changed so that it does.
 
@@ -677,7 +677,7 @@ Errors and Warnings
 
 - ``Fuzz detected: <patch output> [patch-fuzz]``
 
-    This check looks for evidence of "fuzz" when applying patches within the ``do_patch``
+    This check looks for evidence of "fuzz" when applying patches within the :ref:`ref-tasks-patch`
     task. Patch fuzz is a situation when the ``patch`` tool ignores some of the context
     lines in order to apply the patch. Consider this example:
 
@@ -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
 ===================================

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

documentation/ref-manual/structure.rst

@@ -630,7 +630,7 @@ Here are key subdirectories within each recipe work directory:
    split into individual packages.
 
 -  ``${WORKDIR}/packages-split``: Contains the output of the
-   ``do_package`` task after the output has been split into individual
+   :ref:`ref-tasks-package` task after the output has been split into individual
    packages. There are subdirectories for each individual package created by
    the recipe.
 
@@ -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

documentation/ref-manual/system-requirements.rst

@@ -41,6 +41,8 @@ distributions:
 
 -  Ubuntu 20.04 (LTS)
 
+-  Ubuntu 22.04 (LTS)
+
 -  Fedora 34
 
 -  Fedora 35
@@ -72,12 +74,12 @@ distributions:
       the supported platforms listed below.
 
    -  You may use Windows Subsystem For Linux v2 to set up a build host
-      using Windows 10, but validation is not performed against build
-      hosts using WSLv2.
+      using Windows 10 or later, or Windows Server 2019 or later, but validation
+      is not performed against build hosts using WSL 2.
 
-   -  The Yocto Project is not compatible with WSLv1, it is
-      compatible but not officially supported nor validated with
-      WSLv2, if you still decide to use WSL please upgrade to WSLv2.
+      See the
+      :ref:`dev-manual/start:setting up to use windows subsystem for linux (wsl 2)`
+      section in the Yocto Project Development Tasks Manual for more information.
 
    -  If you encounter problems, please go to :yocto_bugs:`Yocto Project
       Bugzilla <>` and submit a bug. We are

documentation/ref-manual/tasks.rst

@@ -36,7 +36,7 @@ directory set to ``${``\ :term:`B`\ ``}``.
 
 The default behavior of this task is to run the ``oe_runmake`` function
 if a makefile (``Makefile``, ``makefile``, or ``GNUmakefile``) is found.
-If no such file is found, the ``do_compile`` task does nothing.
+If no such file is found, the :ref:`ref-tasks-compile` task does nothing.
 
 .. _ref-tasks-compile_ptest_base:
 
@@ -58,7 +58,7 @@ The default behavior of this task is to run ``oe_runmake clean`` if a
 makefile (``Makefile``, ``makefile``, or ``GNUmakefile``) is found and
 :term:`CLEANBROKEN` is not set to "1". If no such
 file is found or the :term:`CLEANBROKEN` variable is set to "1", the
-``do_configure`` task does nothing.
+:ref:`ref-tasks-configure` task does nothing.
 
 .. _ref-tasks-configure_ptest_base:
 
@@ -81,7 +81,7 @@ Recipes implementing this task should inherit the
 :ref:`deploy <ref-classes-deploy>` class and should write the output
 to ``${``\ :term:`DEPLOYDIR`\ ``}``, which is not to be
 confused with ``${DEPLOY_DIR}``. The :ref:`deploy <ref-classes-deploy>` class sets up
-``do_deploy`` as a shared state (sstate) task that can be accelerated
+:ref:`ref-tasks-deploy` as a shared state (sstate) task that can be accelerated
 through sstate use. The sstate mechanism takes care of copying the
 output from ``${DEPLOYDIR}`` to ``${DEPLOY_DIR_IMAGE}``.
 
@@ -90,14 +90,14 @@ output from ``${DEPLOYDIR}`` to ``${DEPLOY_DIR_IMAGE}``.
    Do not write the output directly to ``${DEPLOY_DIR_IMAGE}``, as this causes
    the sstate mechanism to malfunction.
 
-The ``do_deploy`` task is not added as a task by default and
+The :ref:`ref-tasks-deploy` task is not added as a task by default and
 consequently needs to be added manually. If you want the task to run
 after :ref:`ref-tasks-compile`, you can add it by doing
 the following::
 
       addtask deploy after do_compile
 
-Adding ``do_deploy`` after other tasks works the same way.
+Adding :ref:`ref-tasks-deploy` after other tasks works the same way.
 
 .. note::
 
@@ -110,7 +110,7 @@ Adding ``do_deploy`` after other tasks works the same way.
    See the ":ref:`bitbake-user-manual/bitbake-user-manual-execution:dependencies`"
    section in the BitBake User Manual for more information.
 
-If the ``do_deploy`` task re-executes, any previous output is removed
+If the :ref:`ref-tasks-deploy` task re-executes, any previous output is removed
 (i.e. "cleaned").
 
 .. _ref-tasks-fetch:
@@ -128,15 +128,15 @@ module.
 ``do_image``
 ------------
 
-Starts the image generation process. The ``do_image`` task runs after
+Starts the image generation process. The :ref:`ref-tasks-image` task runs after
 the OpenEmbedded build system has run the
 :ref:`ref-tasks-rootfs` task during which packages are
 identified for installation into the image and the root filesystem is
 created, complete with post-processing.
 
-The ``do_image`` task performs pre-processing on the image through the
+The :ref:`ref-tasks-image` task performs pre-processing on the image through the
 :term:`IMAGE_PREPROCESS_COMMAND` and
-dynamically generates supporting ``do_image_*`` tasks as needed.
+dynamically generates supporting :ref:`do_image_* <ref-tasks-image>` tasks as needed.
 
 For more information on image creation, see the ":ref:`overview-manual/concepts:image generation`"
 section in the Yocto Project Overview and Concepts Manual.
@@ -146,13 +146,13 @@ section in the Yocto Project Overview and Concepts Manual.
 ``do_image_complete``
 ---------------------
 
-Completes the image generation process. The ``do_image_complete`` task
+Completes the image generation process. The :ref:`do_image_complete <ref-tasks-image-complete>` task
 runs after the OpenEmbedded build system has run the
 :ref:`ref-tasks-image` task during which image
-pre-processing occurs and through dynamically generated ``do_image_*``
+pre-processing occurs and through dynamically generated :ref:`do_image_* <ref-tasks-image>`
 tasks the image is constructed.
 
-The ``do_image_complete`` task performs post-processing on the image
+The :ref:`do_image_complete <ref-tasks-image-complete>` task performs post-processing on the image
 through the
 :term:`IMAGE_POSTPROCESS_COMMAND`.
 
@@ -168,9 +168,9 @@ section in the Yocto Project Overview and Concepts Manual.
 Copies files that are to be packaged into the holding area
 ``${``\ :term:`D`\ ``}``. This task runs with the current
 working directory set to ``${``\ :term:`B`\ ``}``, which is the
-compilation directory. The ``do_install`` task, as well as other tasks
+compilation directory. The :ref:`ref-tasks-install` task, as well as other tasks
 that either directly or indirectly depend on the installed files (e.g.
-:ref:`ref-tasks-package`, ``do_package_write_*``, and
+:ref:`ref-tasks-package`, :ref:`do_package_write_* <ref-tasks-package_write_deb>`, and
 :ref:`ref-tasks-rootfs`), run under
 :ref:`fakeroot <overview-manual/concepts:fakeroot and pseudo>`.
 
@@ -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:
 
@@ -212,7 +212,7 @@ based on available packages and files. This task makes use of the
 :term:`PACKAGES` and :term:`FILES`
 variables.
 
-The ``do_package`` task, in conjunction with the
+The :ref:`ref-tasks-package` task, in conjunction with the
 :ref:`ref-tasks-packagedata` task, also saves some
 important package metadata. For additional information, see the
 :term:`PKGDESTWORK` variable and the
@@ -327,7 +327,7 @@ file as a patch file::
        "
 
 Conversely, if you have a file whose file type is ``.patch`` or ``.diff``
-and you want to exclude it so that the ``do_patch`` task does not apply
+and you want to exclude it so that the :ref:`ref-tasks-patch` task does not apply
 it during the patch phase, you can use the "apply=no" parameter with the
 :term:`SRC_URI` statement::
 
@@ -392,7 +392,7 @@ For information on what directories are copied by default, see the
 these variables inside your recipe if you need to make additional (or
 fewer) directories available to other recipes at build time.
 
-The ``do_populate_sysroot`` task is a shared state (sstate) task, which
+The :ref:`ref-tasks-populate_sysroot` task is a shared state (sstate) task, which
 means that the task can be accelerated through sstate use. Realize also
 that if the task is re-executed, any previous output is removed (i.e.
 "cleaned").
@@ -447,7 +447,7 @@ Validates the :term:`SRC_URI` value.
 ------------
 
 Removes all output files for a target from the
-:ref:`ref-tasks-unpack` task forward (i.e. ``do_unpack``,
+:ref:`ref-tasks-unpack` task forward (i.e. :ref:`ref-tasks-unpack`,
 :ref:`ref-tasks-configure`,
 :ref:`ref-tasks-compile`,
 :ref:`ref-tasks-install`, and
@@ -473,7 +473,7 @@ use the :ref:`ref-tasks-cleansstate` task instead
 Removes all output files, shared state
 (:ref:`sstate <overview-manual/concepts:shared state cache>`) cache, and
 downloaded source files for a target (i.e. the contents of
-:term:`DL_DIR`). Essentially, the ``do_cleanall`` task is
+:term:`DL_DIR`). Essentially, the :ref:`ref-tasks-cleanall` task is
 identical to the :ref:`ref-tasks-cleansstate` task
 with the added removal of downloaded source files.
 
@@ -481,7 +481,7 @@ You can run this task using BitBake as follows::
 
    $ bitbake -c cleanall recipe
 
-Typically, you would not normally use the ``cleanall`` task. Do so only
+Typically, you would not normally use the :ref:`ref-tasks-cleanall` task. Do so only
 if you want to start fresh with the :ref:`ref-tasks-fetch`
 task.
 
@@ -492,7 +492,7 @@ task.
 
 Removes all output files and shared state
 (:ref:`sstate <overview-manual/concepts:shared state cache>`) cache for a
-target. Essentially, the ``do_cleansstate`` task is identical to the
+target. Essentially, the :ref:`ref-tasks-cleansstate` task is identical to the
 :ref:`ref-tasks-clean` task with the added removal of
 shared state (:ref:`sstate <overview-manual/concepts:shared state cache>`)
 cache.
@@ -501,13 +501,13 @@ You can run this task using BitBake as follows::
 
    $ bitbake -c cleansstate recipe
 
-When you run the ``do_cleansstate`` task, the OpenEmbedded build system
+When you run the :ref:`ref-tasks-cleansstate` task, the OpenEmbedded build system
 no longer uses any sstate. Consequently, building the recipe from
 scratch is guaranteed.
 
 .. note::
 
-   The ``do_cleansstate`` task cannot remove sstate from a remote sstate
+   The :ref:`ref-tasks-cleansstate` task cannot remove sstate from a remote sstate
    mirror. If you need to build a target from scratch using remote mirrors, use
    the "-f" option as follows::
 
@@ -575,10 +575,8 @@ information on live image types.
 ``do_bundle_initramfs``
 -----------------------
 
-Combines an initial RAM disk (initramfs) image and kernel together to
-form a single image. The
-:term:`CONFIG_INITRAMFS_SOURCE` variable
-has some more information about these types of images.
+Combines an :term:`Initramfs` image and kernel together to
+form a single image.
 
 .. _ref-tasks-rootfs:
 
@@ -657,7 +655,7 @@ section in the Yocto Project Linux Kernel Development Manual.
 
 Converts the newly unpacked kernel source into a form with which the
 OpenEmbedded build system can work. Because the kernel source can be
-fetched in several different ways, the ``do_kernel_checkout`` task makes
+fetched in several different ways, the :ref:`ref-tasks-kernel_checkout` task makes
 sure that subsequent tasks are given a clean working tree copy of the
 kernel with the correct branches checked out.
 
@@ -668,7 +666,7 @@ kernel with the correct branches checked out.
 
 Validates the configuration produced by the
 :ref:`ref-tasks-kernel_menuconfig` task. The
-``do_kernel_configcheck`` task produces warnings when a requested
+:ref:`ref-tasks-kernel_configcheck` task produces warnings when a requested
 configuration does not appear in the final ``.config`` file or when you
 override a policy configuration in a hardware configuration fragment.
 You can run this task explicitly and view the output by using the
@@ -686,7 +684,7 @@ section in the Yocto Project Linux Kernel Development Manual.
 ----------------------
 
 After the kernel is patched by the :ref:`ref-tasks-patch`
-task, the ``do_kernel_configme`` task assembles and merges all the
+task, the :ref:`ref-tasks-kernel_configme` task assembles and merges all the
 kernel config fragments into a merged configuration that can then be
 passed to the kernel configuration phase proper. This is also the time
 during which user-specified defconfigs are applied if present, and where
@@ -719,7 +717,7 @@ information on this configuration tool.
 
 Collects all the features required for a given kernel build, whether the
 features come from :term:`SRC_URI` or from Git
-repositories. After collection, the ``do_kernel_metadata`` task
+repositories. After collection, the :ref:`ref-tasks-kernel_metadata` task
 processes the features into a series of config fragments and patches,
 which can then be applied by subsequent tasks such as
 :ref:`ref-tasks-patch` and
@@ -791,4 +789,4 @@ After the kernel is unpacked but before it is patched, this task makes
 sure that the machine and metadata branches as specified by the
 :term:`SRCREV` variables actually exist on the specified
 branches. Otherwise, if :term:`AUTOREV` is not being used, the
-``do_validate_branches`` task fails during the build.
+:ref:`ref-tasks-validate_branches` task fails during the build.

documentation/ref-manual/variables.rst

@@ -773,7 +773,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.
@@ -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>`
@@ -1171,12 +1171,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
@@ -1191,6 +1189,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
@@ -1242,24 +1245,24 @@ system and gives an overview of their function and contents.
          :term:`Source Directory`.
 
    :term:`CONFIG_INITRAMFS_SOURCE`
-      Identifies the initial RAM filesystem (initramfs) source files. The
+      Identifies the initial RAM filesystem (:term:`Initramfs`) source files. The
       OpenEmbedded build system receives and uses this kernel Kconfig
       variable as an environment variable. By default, the variable is set
       to null ("").
 
       The :term:`CONFIG_INITRAMFS_SOURCE` can be either a single cpio archive
       with a ``.cpio`` suffix or a space-separated list of directories and
-      files for building the initramfs image. A cpio archive should contain
-      a filesystem archive to be used as an initramfs image. Directories
-      should contain a filesystem layout to be included in the initramfs
+      files for building the :term:`Initramfs` image. A cpio archive should contain
+      a filesystem archive to be used as an :term:`Initramfs` image. Directories
+      should contain a filesystem layout to be included in the :term:`Initramfs`
       image. Files should contain entries according to the format described
       by the ``usr/gen_init_cpio`` program in the kernel tree.
 
-      If you specify multiple directories and files, the initramfs image
+      If you specify multiple directories and files, the :term:`Initramfs` image
       will be the aggregate of all of them.
 
-      For information on creating an initramfs, see the
-      ":ref:`dev-manual/common-tasks:building an initial ram filesystem (initramfs) image`" section
+      For information on creating an :term:`Initramfs`, see the
+      ":ref:`dev-manual/common-tasks:building an initial ram filesystem (Initramfs) image`" section
       in the Yocto Project Development Tasks Manual.
 
    :term:`CONFIG_SITE`
@@ -1466,15 +1469,31 @@ 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:`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.
 
@@ -1620,7 +1639,7 @@ system and gives an overview of their function and contents.
       the appropriate staging sysroot, given by the
       :term:`STAGING_DIR* <STAGING_DIR>` variables, by the time the
       :ref:`ref-tasks-configure` task for ``foo`` runs.
-      This mechanism is implemented by having ``do_configure`` depend on
+      This mechanism is implemented by having :ref:`ref-tasks-configure` depend on
       the :ref:`ref-tasks-populate_sysroot` task of
       each recipe listed in :term:`DEPENDS`, through a
       ``[``\ :ref:`deptask <bitbake:bitbake-user-manual/bitbake-user-manual-metadata:variable flags>`\ ``]``
@@ -1812,6 +1831,23 @@ 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.)
+      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 @@ 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
@@ -2197,7 +2233,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>`
@@ -2574,7 +2610,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}", \
@@ -2687,6 +2723,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
@@ -2756,6 +2796,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.
@@ -3041,17 +3088,23 @@ 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
-      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 @@ 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
@@ -3182,10 +3235,10 @@ system and gives an overview of their function and contents.
             image, do not use the :term:`IMAGE_INSTALL` variable to specify
             packages for installation. Instead, use the
             :term:`PACKAGE_INSTALL` variable, which
-            allows the initial RAM filesystem (initramfs) recipe to use a
+            allows the initial RAM filesystem (:term:`Initramfs`) recipe to use a
             fixed set of packages and not be affected by :term:`IMAGE_INSTALL`.
-            For information on creating an initramfs, see the
-            ":ref:`dev-manual/common-tasks:building an initial ram filesystem (initramfs) image`"
+            For information on creating an :term:`Initramfs`, see the
+            ":ref:`dev-manual/common-tasks:building an initial ram filesystem (Initramfs) image`"
             section in the Yocto Project Development Tasks Manual.
 
          -  Using :term:`IMAGE_INSTALL` with the
@@ -3265,7 +3318,7 @@ system and gives an overview of their function and contents.
       to distinguish the image file from other files created during image
       building; however if this suffix is redundant or not desired you can
       clear the value of this variable (set the value to ""). For example,
-      this is typically cleared in initramfs image recipes.
+      this is typically cleared in :term:`Initramfs` image recipes.
 
    :term:`IMAGE_OVERHEAD_FACTOR`
       Defines a multiplier that the build system applies to the initial
@@ -3463,7 +3516,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
@@ -3546,7 +3599,7 @@ system and gives an overview of their function and contents.
 
 
          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 @@ 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`"
@@ -3571,6 +3626,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::
 
@@ -3632,37 +3690,79 @@ system and gives an overview of their function and contents.
          even if the toolchain's binaries are strippable, there are other files
          needed for the build that are not strippable.
 
+   :term:`Initramfs`
+      An Initial RAM Filesystem (:term:`Initramfs`) is an optionally compressed
+      `cpio <https://en.wikipedia.org/wiki/Cpio>`__ archive which is extracted
+      by the Linux kernel into RAM in a special `tmpfs <https://en.wikipedia.org/wiki/Tmpfs>`__
+      instance, used as the initial root filesystem.
+
+      This is a replacement for the legacy init RAM disk ("initrd")
+      technique, booting on an emulated block device in RAM, but being less
+      efficient because of the overhead of going through a filesystem and
+      having to duplicate accessed file contents in the file cache in RAM,
+      as for any block device.
+
+      .. note:
+
+         As far as bootloaders are concerned, :term:`Initramfs` and "initrd"
+         images are still copied to RAM in the same way. That's why most
+	 most bootloaders refer to :term:`Initramfs` images as "initrd"
+	 or "init RAM disk".
+
+      This kind of mechanism is typically used for two reasons:
+
+      -  For booting the same kernel binary on multiple systems requiring
+         different device drivers. The Initramfs image is then customized
+	 for each type of system, to include the specific  kernel modules
+         necessary to access the final root filesystem. This technique
+	 is used on all GNU / Linux distributions for desktops and servers.
+
+      -  For booting faster. As the root filesystem is extracted into RAM,
+         accessing the first user-space applications is very fast, compared
+         to having to initialize a block device, to access multiple blocks
+         from it, and to go through a filesystem having its own overhead.
+         For example, this allows to display a splashscreen very early,
+	 and to later take care of mounting the final root filesystem and
+         loading less time-critical kernel drivers.
+
+      This cpio archive can either be loaded to RAM by the bootloader,
+      or be included in the kernel binary.
+
+      For information on creating and using an :term:`Initramfs`, see the
+      ":ref:`dev-manual/common-tasks:building an initial ram filesystem (Initramfs) image`"
+      section in the Yocto Project Development Tasks Manual.
+
    :term:`INITRAMFS_DEPLOY_DIR_IMAGE`
-      Indicates the deploy directory used by ``do_bundle_initramfs`` where the
+      Indicates the deploy directory used by :ref:`ref-tasks-bundle_initramfs` where the
       :term:`INITRAMFS_IMAGE` will be fetched from.
       This variable is set by default to ``${DEPLOY_DIR_IMAGE}`` in the
       :ref:`kernel <ref-classes-kernel>` class and it's only meant to be changed
-      when building an initramfs image from a separate multiconfig via :term:`INITRAMFS_MULTICONFIG`.
+      when building an :term:`Initramfs` image from a separate multiconfig via :term:`INITRAMFS_MULTICONFIG`.
 
    :term:`INITRAMFS_FSTYPES`
       Defines the format for the output image of an initial RAM filesystem
-      (initramfs), which is used during boot. Supported formats are the
+      (:term:`Initramfs`), which is used during boot. Supported formats are the
       same as those supported by the
       :term:`IMAGE_FSTYPES` variable.
 
       The default value of this variable, which is set in the
       ``meta/conf/bitbake.conf`` configuration file in the
       :term:`Source Directory`, is "cpio.gz". The Linux kernel's
-      initramfs mechanism, as opposed to the initial RAM filesystem
+      :term:`Initramfs` mechanism, as opposed to the initial RAM filesystem
       `initrd <https://en.wikipedia.org/wiki/Initrd>`__ mechanism, expects
       an optionally compressed cpio archive.
 
    :term:`INITRAMFS_IMAGE`
       Specifies the :term:`PROVIDES` name of an image
-      recipe that is used to build an initial RAM filesystem (initramfs)
+      recipe that is used to build an initial RAM filesystem (:term:`Initramfs`)
       image. In other words, the :term:`INITRAMFS_IMAGE` variable causes an
       additional recipe to be built as a dependency to whatever root
       filesystem recipe you might be using (e.g. ``core-image-sato``). The
-      initramfs image recipe you provide should set
+      :term:`Initramfs` image recipe you provide should set
       :term:`IMAGE_FSTYPES` to
       :term:`INITRAMFS_FSTYPES`.
 
-      An initramfs image provides a temporary root filesystem used for
+      An :term:`Initramfs` image provides a temporary root filesystem used for
       early system initialization (e.g. loading of modules needed to locate
       and mount the "real" root filesystem).
 
@@ -3670,8 +3770,8 @@ system and gives an overview of their function and contents.
 
          See the ``meta/recipes-core/images/core-image-minimal-initramfs.bb``
          recipe in the :term:`Source Directory`
-         for an example initramfs recipe. To select this sample recipe as
-         the one built to provide the initramfs image, set :term:`INITRAMFS_IMAGE`
+         for an example :term:`Initramfs` recipe. To select this sample recipe as
+         the one built to provide the :term:`Initramfs` image, set :term:`INITRAMFS_IMAGE`
          to "core-image-minimal-initramfs".
 
       You can also find more information by referencing the
@@ -3681,13 +3781,13 @@ system and gives an overview of their function and contents.
       class to see how to use the :term:`INITRAMFS_IMAGE` variable.
 
       If :term:`INITRAMFS_IMAGE` is empty, which is the default, then no
-      initramfs image is built.
+      :term:`Initramfs` image is built.
 
       For more information, you can also see the
       :term:`INITRAMFS_IMAGE_BUNDLE`
       variable, which allows the generated image to be bundled inside the
-      kernel image. Additionally, for information on creating an initramfs
-      image, see the ":ref:`dev-manual/common-tasks:building an initial ram filesystem (initramfs) image`" section
+      kernel image. Additionally, for information on creating an :term:`Initramfs`
+      image, see the ":ref:`dev-manual/common-tasks:building an initial ram filesystem (Initramfs) image`" section
       in the Yocto Project Development Tasks Manual.
 
    :term:`INITRAMFS_IMAGE_BUNDLE`
@@ -3696,32 +3796,32 @@ system and gives an overview of their function and contents.
       extra pass
       (:ref:`ref-tasks-bundle_initramfs`) during
       kernel compilation in order to build a single binary that contains
-      both the kernel image and the initial RAM filesystem (initramfs)
+      both the kernel image and the initial RAM filesystem (:term:`Initramfs`)
       image. This makes use of the
       :term:`CONFIG_INITRAMFS_SOURCE` kernel
       feature.
 
       .. note::
 
-         Bundling the initramfs with the kernel conflates the code in the
-         initramfs with the GPLv2 licensed Linux kernel binary. Thus only GPLv2
-         compatible software may be part of a bundled initramfs.
+         Bundling the :term:`Initramfs` with the kernel conflates the code in the
+         :term:`Initramfs` with the GPLv2 licensed Linux kernel binary. Thus only GPLv2
+         compatible software may be part of a bundled :term:`Initramfs`.
 
       .. note::
 
-         Using an extra compilation pass to bundle the initramfs avoids a
-         circular dependency between the kernel recipe and the initramfs
-         recipe should the initramfs include kernel modules. Should that be
-         the case, the initramfs recipe depends on the kernel for the
-         kernel modules, and the kernel depends on the initramfs recipe
-         since the initramfs is bundled inside the kernel image.
+         Using an extra compilation pass to bundle the :term:`Initramfs` avoids a
+         circular dependency between the kernel recipe and the :term:`Initramfs`
+         recipe should the :term:`Initramfs` include kernel modules. Should that be
+         the case, the :term:`Initramfs` recipe depends on the kernel for the
+         kernel modules, and the kernel depends on the :term:`Initramfs` recipe
+         since the :term:`Initramfs` is bundled inside the kernel image.
 
       The combined binary is deposited into the ``tmp/deploy`` directory,
       which is part of the :term:`Build Directory`.
 
       Setting the variable to "1" in a configuration file causes the
       OpenEmbedded build system to generate a kernel image with the
-      initramfs specified in :term:`INITRAMFS_IMAGE` bundled within::
+      :term:`Initramfs` specified in :term:`INITRAMFS_IMAGE` bundled within::
 
          INITRAMFS_IMAGE_BUNDLE = "1"
 
@@ -3739,12 +3839,12 @@ system and gives an overview of their function and contents.
       See the
       :yocto_git:`local.conf.sample.extended </poky/tree/meta-poky/conf/templates/default/local.conf.sample.extended>`
       file for additional information. Also, for information on creating an
-      initramfs, see the ":ref:`dev-manual/common-tasks:building an initial ram filesystem (initramfs) image`" section
+      :term:`Initramfs`, see the ":ref:`dev-manual/common-tasks:building an initial ram filesystem (Initramfs) image`" section
       in the Yocto Project Development Tasks Manual.
 
    :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}"
@@ -3764,13 +3864,13 @@ system and gives an overview of their function and contents.
       This allows the kernel to bundle an :term:`INITRAMFS_IMAGE` coming from
       a separate multiconfig, this is meant to be used in addition to :term:`INITRAMFS_DEPLOY_DIR_IMAGE`.
 
-      For more information on how to bundle an initramfs image from a separate
+      For more information on how to bundle an :term:`Initramfs` image from a separate
       multiconfig see the ":ref:`dev-manual/common-tasks:Bundling an Initramfs Image From a Separate Multiconfig`"
       section in the Yocto Project Development Tasks Manual.
 
    :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}"
@@ -3980,7 +4080,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}"
@@ -3993,7 +4093,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.
 
@@ -4002,6 +4102,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.
@@ -4017,7 +4123,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}"
@@ -4033,7 +4139,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}"
@@ -4084,7 +4190,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}"
@@ -4100,7 +4206,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}"
@@ -4112,7 +4218,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}"
 
@@ -4140,7 +4246,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}"
 
@@ -4240,7 +4346,7 @@ system and gives an overview of their function and contents.
       :term:`KERNELDEPMODDEPEND` does not control whether or not that data
       exists, but simply whether or not it is used. If you do not need to
       use the data, set the :term:`KERNELDEPMODDEPEND` variable in your
-      ``initramfs`` recipe. Setting the variable there when the data is not
+      :term:`Initramfs` recipe. Setting the variable there when the data is not
       needed avoids a potential dependency loop.
 
    :term:`KFEATURE_DESCRIPTION`
@@ -4875,7 +4981,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}"
 
@@ -4889,7 +4995,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}"
 
@@ -4898,6 +5004,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
@@ -5019,7 +5130,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.
 
@@ -5076,6 +5187,87 @@ 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_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
@@ -5395,9 +5587,9 @@ system and gives an overview of their function and contents.
       :term:`IMAGE_INSTALL` variable to specify
       packages for installation. The exception to this is when working with
       the :ref:`core-image-minimal-initramfs <ref-manual/images:images>`
-      image. When working with an initial RAM filesystem (initramfs) image,
+      image. When working with an initial RAM filesystem (:term:`Initramfs`) image,
       use the :term:`PACKAGE_INSTALL` variable. For information on creating an
-      initramfs, see the ":ref:`dev-manual/common-tasks:building an initial ram filesystem (initramfs) image`" section
+      :term:`Initramfs`, see the ":ref:`dev-manual/common-tasks:building an initial ram filesystem (Initramfs) image`" section
       in the Yocto Project Development Tasks Manual.
 
    :term:`PACKAGE_INSTALL_ATTEMPTONLY`
@@ -5521,7 +5713,7 @@ system and gives an overview of their function and contents.
       :ref:`cmake <ref-classes-cmake>` use :term:`PACKAGECONFIG_CONFARGS` to
       pass :term:`PACKAGECONFIG` options to ``configure`` and ``cmake``,
       respectively. If you are using :term:`PACKAGECONFIG` but not a class that
-      handles the ``do_configure`` task, then you need to use
+      handles the :ref:`ref-tasks-configure` task, then you need to use
       :term:`PACKAGECONFIG_CONFARGS` appropriately.
 
    :term:`PACKAGEGROUP_DISABLE_COMPLEMENTARY`
@@ -5603,7 +5795,7 @@ system and gives an overview of their function and contents.
       .. note::
 
          If the software being built experiences dependency issues during
-         the ``do_compile`` task that result in race conditions, you can clear
+         the :ref:`ref-tasks-compile` task that result in race conditions, you can clear
          the :term:`PARALLEL_MAKE` variable within the recipe as a workaround. For
          information on addressing race conditions, see the
          ":ref:`dev-manual/common-tasks:debugging parallel make races`"
@@ -5633,7 +5825,7 @@ system and gives an overview of their function and contents.
          way to ensure this is to use the ``oe_runmake`` function.
 
          If the software being built experiences dependency issues during
-         the ``do_install`` task that result in race conditions, you can
+         the :ref:`ref-tasks-install` task that result in race conditions, you can
          clear the :term:`PARALLEL_MAKEINST` variable within the recipe as a
          workaround. For information on addressing race conditions, see the
          ":ref:`dev-manual/common-tasks:debugging parallel make races`"
@@ -6100,6 +6292,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
@@ -6200,7 +6400,7 @@ system and gives an overview of their function and contents.
       The practical effect of the above :term:`RDEPENDS` assignment is that
       ``bar`` and ``baz`` will be declared as dependencies inside the
       package ``foo`` when it is written out by one of the
-      :ref:`do_package_write_\* <ref-tasks-package_write_deb>` tasks.
+      :ref:`do_package_write_* <ref-tasks-package_write_deb>` tasks.
       Exactly how this is done depends on which package format is used,
       which is determined by
       :term:`PACKAGE_CLASSES`. When the
@@ -6212,7 +6412,7 @@ system and gives an overview of their function and contents.
       added. This dependency is from the recipe's
       :ref:`ref-tasks-build` (not to be confused with
       :ref:`ref-tasks-compile`) task to the
-      ``do_package_write_*`` task of the recipes that build ``bar`` and
+      :ref:`do_package_write_* <ref-tasks-package_write_deb>` task of the recipes that build ``bar`` and
       ``baz``.
 
       The names of the packages you list within :term:`RDEPENDS` must be the
@@ -6573,6 +6773,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
@@ -6709,10 +6914,10 @@ system and gives an overview of their function and contents.
       A list of shared state tasks added to the extensible SDK. By default,
       the following tasks are added:
 
-      - do_populate_lic
-      - do_package_qa
-      - do_populate_sysroot
-      - do_deploy
+      - :ref:`ref-tasks-populate_lic`
+      - :ref:`ref-tasks-package_qa`
+      - :ref:`ref-tasks-populate_sysroot`
+      - :ref:`ref-tasks-deploy`
 
       Despite the default value of "" for the
       :term:`SDK_RECRDEP_TASKS` variable, the above four tasks are always added
@@ -6772,6 +6977,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
@@ -7382,7 +7591,7 @@ system and gives an overview of their function and contents.
       For most recipes, this sysroot is the one in which that recipe's
       :ref:`ref-tasks-populate_sysroot` task copies
       files. Exceptions include ``-native`` recipes, where the
-      ``do_populate_sysroot`` task instead uses
+      :ref:`ref-tasks-populate_sysroot` task instead uses
       :term:`STAGING_DIR_NATIVE`. Depending on
       the type of recipe and the build target, :term:`STAGING_DIR_HOST` can
       have the following values:
@@ -8175,7 +8384,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
@@ -8487,6 +8696,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
@@ -8654,6 +8867,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"
@@ -8802,6 +9018,15 @@ 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:`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

documentation/sdk-manual/extensible.rst

@@ -71,7 +71,7 @@ Setting up the Extensible SDK environment directly in a Yocto build
     $ bitbake meta-ide-support
     $ bitbake -c populate_sysroot gtk+3
     (or any other target or native item that the application developer would need)
-    $ bitbake populate-sysroots
+    $ bitbake build-sysroots
 
 
 Setting up the Extensible SDK from a standalone installer
@@ -1112,7 +1112,7 @@ links created within the source tree:
       ``${``\ :term:`D`\ ``}``.
 
    -  ``sysroot-destdir/``: Contains a subset of files installed within
-      ``do_install`` that have been put into the shared sysroot. For
+      :ref:`ref-tasks-install` that have been put into the shared sysroot. For
       more information, see the
       ":ref:`dev-manual/common-tasks:sharing files between recipes`" section.
 
@@ -1274,7 +1274,7 @@ is directly accessible to build additional items, and it
 can simply be executed directly:
 
    $ bitbake mesa
-   $ bitbake populate-sysroots
+   $ bitbake build-sysroots
 
 When using a standalone installer for the Extensible SDK
 --------------------------------------------------------

documentation/set_versions.py

@@ -26,8 +26,8 @@ ourversion = None
 if len(sys.argv) == 2:
     ourversion = sys.argv[1]
 
-activereleases = ["kirkstone", "dunfell"]
-devbranch = "langdale"
+activereleases = ["langdale", "kirkstone", "dunfell"]
+devbranch = "mickledore"
 ltsseries = ["kirkstone", "dunfell"]
 
 # used by run-docs-builds to get the default page
@@ -36,6 +36,7 @@ if ourversion == "getlatest":
     sys.exit(0)
 
 release_series = collections.OrderedDict()
+release_series["mickledore"] = "4.2"
 release_series["langdale"] = "4.1"
 release_series["kirkstone"] = "4.0"
 release_series["honister"] = "3.4"
@@ -65,6 +66,7 @@ release_series["laverne"] = "0.9"
 
 
 bitbake_mapping = {
+    "mickledore" : "2.4",
     "langdale" : "2.2",
     "kirkstone" : "2.0",
     "honister" : "1.52",

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

documentation/test-manual/understand-autobuilder.rst

@@ -56,7 +56,7 @@ the "templates" section, which looks like::
 
 Combining these two entries you can see that "qemux86-64" is a three step build where the
 ``bitbake BBTARGETS`` would be run, then ``bitbake SANITYTARGETS`` for each step; all for
-``MACHINE="qemx86-64"`` but with differing SDKMACHINE settings. In step
+``MACHINE="qemux86-64"`` but with differing SDKMACHINE settings. In step
 1 an extra variable is added to the ``auto.conf`` file to enable wic
 image generation.
 

meta-poky/conf/distro/poky.conf

@@ -1,7 +1,7 @@
 DISTRO = "poky"
 DISTRO_NAME = "Poky (Yocto Project Reference Distro)"
 #DISTRO_VERSION = "4.1+snapshot-${METADATA_REVISION}"
-DISTRO_VERSION = "4.1"
+DISTRO_VERSION = "4.1.1"
 DISTRO_CODENAME = "langdale"
 SDK_VENDOR = "-pokysdk"
 SDK_VERSION = "${@d.getVar('DISTRO_VERSION').replace('snapshot-${METADATA_REVISION}', 'snapshot')}"
@@ -38,7 +38,6 @@ SANITY_TESTED_DISTROS ?= " \
             poky-4.1 \n \
             ubuntu-18.04 \n \
             ubuntu-20.04 \n \
-            ubuntu-21.10 \n \
             ubuntu-22.04 \n \
             fedora-34 \n \
             fedora-35 \n \

meta/classes-global/insane.bbclass

@@ -555,7 +555,10 @@ python populate_lic_qa_checksum() {
                 import hashlib
                 lineno = 0
                 license = []
-                m = hashlib.new('MD5', usedforsecurity=False)
+                try:
+                    m = hashlib.new('MD5', usedforsecurity=False)
+                except TypeError:
+                    m = hashlib.new('MD5')
                 for line in f:
                     lineno += 1
                     if (lineno >= beginline):

meta/classes-global/mirrors.bbclass

@@ -90,6 +90,7 @@ BB_GIT_SHALLOW:pn-binutils-cross-${TARGET_ARCH} = "1"
 BB_GIT_SHALLOW:pn-binutils-cross-canadian-${TRANSLATED_TARGET_ARCH} = "1"
 BB_GIT_SHALLOW:pn-binutils-cross-testsuite = "1"
 BB_GIT_SHALLOW:pn-binutils-crosssdk-${SDK_SYS} = "1"
+BB_GIT_SHALLOW:pn-binutils-native = "1"
 BB_GIT_SHALLOW:pn-glibc = "1"
 PREMIRRORS += "git://sourceware.org/git/glibc.git https://downloads.yoctoproject.org/mirror/sources/ \
               git://sourceware.org/git/binutils-gdb.git https://downloads.yoctoproject.org/mirror/sources/"

meta/classes-global/sanity.bbclass

@@ -504,6 +504,14 @@ def check_tar_version(sanity_data):
     version = result.split()[3]
     if bb.utils.vercmp_string_op(version, "1.28", "<"):
         return "Your version of tar is older than 1.28 and does not have the support needed to enable reproducible builds. Please install a newer version of tar (you could use the project's buildtools-tarball from our last release or use scripts/install-buildtools).\n"
+
+    try:
+        result = subprocess.check_output(["tar", "--help"], stderr=subprocess.STDOUT).decode('utf-8')
+        if "--xattrs" not in result:
+            return "Your tar doesn't support --xattrs, please use GNU tar.\n"
+    except subprocess.CalledProcessError as e:
+        return "Unable to execute tar --help, exit code %d\n%s\n" % (e.returncode, e.output)
+
     return None
 
 # We use git parameters and functionality only found in 1.7.8 or later
@@ -865,7 +873,7 @@ def check_sanity_everybuild(status, d):
     mirror_vars = ['MIRRORS', 'PREMIRRORS', 'SSTATE_MIRRORS']
     protocols = ['http', 'ftp', 'file', 'https', \
                  'git', 'gitsm', 'hg', 'osc', 'p4', 'svn', \
-                 'bzr', 'cvs', 'npm', 'sftp', 'ssh', 's3', 'az', 'ftps']
+                 'bzr', 'cvs', 'npm', 'sftp', 'ssh', 's3', 'az', 'ftps', 'crate']
     for mirror_var in mirror_vars:
         mirrors = (d.getVar(mirror_var) or '').replace('\\n', ' ').split()
 

meta/classes-recipe/kernel-fitimage.bbclass

@@ -496,7 +496,7 @@ fitimage_assemble() {
 	ramdiskcount=$3
 	setupcount=""
 	bootscr_id=""
-	rm -f $1 arch/${ARCH}/boot/$2
+	rm -f $1 ${KERNEL_OUTPUT_DIR}/$2
 
 	if [ -n "${UBOOT_SIGN_IMG_KEYNAME}" -a "${UBOOT_SIGN_KEYNAME}" = "${UBOOT_SIGN_IMG_KEYNAME}" ]; then
 		bbfatal "Keys used to sign images and configuration nodes must be different."
@@ -529,9 +529,9 @@ fitimage_assemble() {
 				continue
 			fi
 
-			DTB_PATH="arch/${ARCH}/boot/dts/$DTB"
+			DTB_PATH="${KERNEL_OUTPUT_DIR}/dts/$DTB"
 			if [ ! -e "$DTB_PATH" ]; then
-				DTB_PATH="arch/${ARCH}/boot/$DTB"
+				DTB_PATH="${KERNEL_OUTPUT_DIR}/$DTB"
 			fi
 
 			DTB=$(echo "$DTB" | tr '/' '_')
@@ -574,9 +574,9 @@ fitimage_assemble() {
 	#
 	# Step 4: Prepare a setup section. (For x86)
 	#
-	if [ -e arch/${ARCH}/boot/setup.bin ]; then
+	if [ -e ${KERNEL_OUTPUT_DIR}/setup.bin ]; then
 		setupcount=1
-		fitimage_emit_section_setup $1 $setupcount arch/${ARCH}/boot/setup.bin
+		fitimage_emit_section_setup $1 $setupcount ${KERNEL_OUTPUT_DIR}/setup.bin
 	fi
 
 	#
@@ -650,7 +650,7 @@ fitimage_assemble() {
 	${UBOOT_MKIMAGE} \
 		${@'-D "${UBOOT_MKIMAGE_DTCOPTS}"' if len('${UBOOT_MKIMAGE_DTCOPTS}') else ''} \
 		-f $1 \
-		arch/${ARCH}/boot/$2
+		${KERNEL_OUTPUT_DIR}/$2
 
 	#
 	# Step 8: Sign the image and add public key to U-Boot dtb
@@ -667,7 +667,7 @@ fitimage_assemble() {
 			${@'-D "${UBOOT_MKIMAGE_DTCOPTS}"' if len('${UBOOT_MKIMAGE_DTCOPTS}') else ''} \
 			-F -k "${UBOOT_SIGN_KEYDIR}" \
 			$add_key_to_u_boot \
-			-r arch/${ARCH}/boot/$2 \
+			-r ${KERNEL_OUTPUT_DIR}/$2 \
 			${UBOOT_MKIMAGE_SIGN_ARGS}
 	fi
 }
@@ -770,7 +770,7 @@ kernel_do_deploy:append() {
 
 			if [ "${INITRAMFS_IMAGE_BUNDLE}" != "1" ]; then
 				bbnote "Copying fitImage-${INITRAMFS_IMAGE} file..."
-				install -m 0644 ${B}/arch/${ARCH}/boot/fitImage-${INITRAMFS_IMAGE} "$deployDir/fitImage-${INITRAMFS_IMAGE_NAME}-${KERNEL_FIT_NAME}${KERNEL_FIT_BIN_EXT}"
+				install -m 0644 ${B}/${KERNEL_OUTPUT_DIR}/fitImage-${INITRAMFS_IMAGE} "$deployDir/fitImage-${INITRAMFS_IMAGE_NAME}-${KERNEL_FIT_NAME}${KERNEL_FIT_BIN_EXT}"
 				if [ -n "${KERNEL_FIT_LINK_NAME}" ] ; then
 					ln -snf fitImage-${INITRAMFS_IMAGE_NAME}-${KERNEL_FIT_NAME}${KERNEL_FIT_BIN_EXT} "$deployDir/fitImage-${INITRAMFS_IMAGE_NAME}-${KERNEL_FIT_LINK_NAME}"
 				fi

meta/classes-recipe/kernel-yocto.bbclass

@@ -506,7 +506,7 @@ python do_config_analysis() {
                 try:
                     analysis = subprocess.check_output(['symbol_why.py', '--dotconfig',  '{}'.format( d.getVar('B') + '/.config' ), '--blame', c], cwd=s, env=env ).decode('utf-8')
                 except subprocess.CalledProcessError as e:
-                    bb.fatal( "config analysis failed: %s" % e.output.decode('utf-8'))
+                    bb.fatal( "config analysis failed when running '%s': %s" % (" ".join(e.cmd), e.output.decode('utf-8')))
 
                 outfile = d.getVar( 'CONFIG_ANALYSIS_FILE' )
 
@@ -514,7 +514,7 @@ python do_config_analysis() {
                 try:
                     analysis = subprocess.check_output(['symbol_why.py', '--dotconfig',  '{}'.format( d.getVar('B') + '/.config' ), '--summary', '--extended', '--sanity', c], cwd=s, env=env ).decode('utf-8')
                 except subprocess.CalledProcessError as e:
-                    bb.fatal( "config analysis failed: %s" % e.output.decode('utf-8'))
+                    bb.fatal( "config analysis failed when running '%s': %s" % (" ".join(e.cmd), e.output.decode('utf-8')))
 
                 outfile = d.getVar( 'CONFIG_AUDIT_FILE' )
 
@@ -575,7 +575,7 @@ python do_kernel_configcheck() {
     try:
         analysis = subprocess.check_output(['symbol_why.py', '--dotconfig',  '{}'.format( d.getVar('B') + '/.config' ), '--mismatches', extra_params], cwd=s, env=env ).decode('utf-8')
     except subprocess.CalledProcessError as e:
-        bb.fatal( "config analysis failed: %s" % e.output.decode('utf-8'))
+        bb.fatal( "config analysis failed when running '%s': %s" % (" ".join(e.cmd), e.output.decode('utf-8')))
 
     if analysis:
         outfile = "{}/{}/cfg/mismatch.txt".format( s, kmeta )
@@ -597,7 +597,7 @@ python do_kernel_configcheck() {
     try:
         analysis = subprocess.check_output(['symbol_why.py', '--dotconfig',  '{}'.format( d.getVar('B') + '/.config' ), '--invalid', extra_params], cwd=s, env=env ).decode('utf-8')
     except subprocess.CalledProcessError as e:
-        bb.fatal( "config analysis failed: %s" % e.output.decode('utf-8'))
+        bb.fatal( "config analysis failed when running '%s': %s" % (" ".join(e.cmd), e.output.decode('utf-8')))
 
     if analysis:
         outfile = "{}/{}/cfg/invalid.txt".format(s,kmeta)
@@ -616,7 +616,7 @@ python do_kernel_configcheck() {
     try:
         analysis = subprocess.check_output(['symbol_why.py', '--dotconfig',  '{}'.format( d.getVar('B') + '/.config' ), '--sanity'], cwd=s, env=env ).decode('utf-8')
     except subprocess.CalledProcessError as e:
-        bb.fatal( "config analysis failed: %s" % e.output.decode('utf-8'))
+        bb.fatal( "config analysis failed when running '%s': %s" % (" ".join(e.cmd), e.output.decode('utf-8')))
 
     if analysis:
         outfile = "{}/{}/cfg/redefinition.txt".format(s,kmeta)

meta/classes-recipe/kernel.bbclass

@@ -594,9 +594,7 @@ do_shared_workdir () {
 }
 
 # We don't need to stage anything, not the modules/firmware since those would clash with linux-firmware
-sysroot_stage_all () {
-	:
-}
+SYSROOT_DIRS = ""
 
 KERNEL_CONFIG_COMMAND ?= "oe_runmake_call -C ${S} O=${B} olddefconfig || oe_runmake -C ${S} O=${B} oldnoconfig"
 

meta/classes-recipe/overlayfs.bbclass

@@ -102,7 +102,11 @@ python do_create_overlayfs_units() {
     overlayMountPoints = d.getVarFlags("OVERLAYFS_MOUNT_POINT")
     for mountPoint in overlayMountPoints:
         bb.debug(1, "Process variable flag %s" % mountPoint)
-        for lower in d.getVarFlag('OVERLAYFS_WRITABLE_PATHS', mountPoint).split():
+        lowerList = d.getVarFlag('OVERLAYFS_WRITABLE_PATHS', mountPoint)
+        if not lowerList:
+            bb.note("No mount points defined for %s flag, skipping" % (mountPoint))
+            continue
+        for lower in lowerList.split():
             bb.debug(1, "Prepare mount unit for %s with data mount point %s" %
                      (lower, d.getVarFlag('OVERLAYFS_MOUNT_POINT', mountPoint)))
             prepareUnits(d.getVarFlag('OVERLAYFS_MOUNT_POINT', mountPoint), lower)

meta/classes-recipe/populate_sdk_base.bbclass

@@ -15,7 +15,7 @@ COMPLEMENTARY_GLOB[staticdev-pkgs] = '*-staticdev'
 COMPLEMENTARY_GLOB[doc-pkgs] = '*-doc'
 COMPLEMENTARY_GLOB[dbg-pkgs] = '*-dbg'
 COMPLEMENTARY_GLOB[src-pkgs] = '*-src'
-COMPLEMENTARY_GLOB[ptest-pkgs] = '*-ptest'
+COMPLEMENTARY_GLOB[ptest-pkgs] = '*-ptest ptest-runner'
 COMPLEMENTARY_GLOB[bash-completion-pkgs] = '*-bash-completion'
 
 def complementary_globs(featurevar, d):

meta/classes-recipe/rust-target-config.bbclass

@@ -231,19 +231,19 @@ TARGET_POINTER_WIDTH[powerpc64le] = "64"
 TARGET_C_INT_WIDTH[powerpc64le] = "64"
 MAX_ATOMIC_WIDTH[powerpc64le] = "64"
 
-## riscv32-unknown-linux-{gnu, musl}
-DATA_LAYOUT[riscv32] = "e-m:e-p:32:32-i64:64-n32-S128"
-TARGET_ENDIAN[riscv32] = "little"
-TARGET_POINTER_WIDTH[riscv32] = "32"
-TARGET_C_INT_WIDTH[riscv32] = "32"
-MAX_ATOMIC_WIDTH[riscv32] = "32"
+## riscv32gc-unknown-linux-{gnu, musl}
+DATA_LAYOUT[riscv32gc] = "e-m:e-p:32:32-i64:64-n32-S128"
+TARGET_ENDIAN[riscv32gc] = "little"
+TARGET_POINTER_WIDTH[riscv32gc] = "32"
+TARGET_C_INT_WIDTH[riscv32gc] = "32"
+MAX_ATOMIC_WIDTH[riscv32gc] = "32"
 
-## riscv64-unknown-linux-{gnu, musl}
-DATA_LAYOUT[riscv64] = "e-m:e-p:64:64-i64:64-i128:128-n64-S128"
-TARGET_ENDIAN[riscv64] = "little"
-TARGET_POINTER_WIDTH[riscv64] = "64"
-TARGET_C_INT_WIDTH[riscv64] = "64"
-MAX_ATOMIC_WIDTH[riscv64] = "64"
+## riscv64gc-unknown-linux-{gnu, musl}
+DATA_LAYOUT[riscv64gc] = "e-m:e-p:64:64-i64:64-i128:128-n64-S128"
+TARGET_ENDIAN[riscv64gc] = "little"
+TARGET_POINTER_WIDTH[riscv64gc] = "64"
+TARGET_C_INT_WIDTH[riscv64gc] = "64"
+MAX_ATOMIC_WIDTH[riscv64gc] = "64"
 
 # Convert a normal arch (HOST_ARCH, TARGET_ARCH, BUILD_ARCH, etc) to something
 # rust's internals won't choke on.
@@ -258,9 +258,21 @@ def arch_to_rust_target_arch(arch):
         return "arm"
     elif arch == "powerpc64le":
         return "powerpc64"
+    elif arch == "riscv32gc":
+        return "riscv32"
+    elif arch == "riscv64gc":
+        return "riscv64"
     else:
         return arch
 
+# Convert a rust target string to a llvm-compatible triplet
+def rust_sys_to_llvm_target(sys):
+    if sys.startswith('riscv32gc-'):
+        return sys.replace('riscv32gc-', 'riscv32-', 1)
+    if sys.startswith('riscv64gc-'):
+        return sys.replace('riscv64gc-', 'riscv64-', 1)
+    return sys
+
 # generates our target CPU value
 def llvm_cpu(d):
     cpu = d.getVar('PACKAGE_ARCH')
@@ -334,7 +346,7 @@ def rust_gen_target(d, thing, wd, arch):
 
     # build tspec
     tspec = {}
-    tspec['llvm-target'] = rustsys
+    tspec['llvm-target'] = rust_sys_to_llvm_target(rustsys)
     tspec['data-layout'] = d.getVarFlag('DATA_LAYOUT', arch_abi)
     if tspec['data-layout'] is None:
         bb.fatal("No rust target defined for %s" % arch_abi)

meta/classes-recipe/uboot-sign.bbclass

@@ -298,7 +298,7 @@ do_uboot_generate_rsa_keys() {
 				"${UBOOT_FIT_SIGN_NUMBITS}"
 
 			echo "Generating certificate for signing U-Boot fitImage"
-			openssl req ${FIT_KEY_REQ_ARGS} "${UBOOT_FIT_KEY_SIGN_PKCS}" \
+			openssl req ${UBOOT_FIT_KEY_REQ_ARGS} "${UBOOT_FIT_KEY_SIGN_PKCS}" \
 				-key "${SPL_SIGN_KEYDIR}/${SPL_SIGN_KEYNAME}".key \
 				-out "${SPL_SIGN_KEYDIR}/${SPL_SIGN_KEYNAME}".crt
 		fi

meta/classes/create-spdx.bbclass

@@ -21,7 +21,6 @@ SPDX_TOOL_VERSION ??= "1.0"
 SPDXRUNTIMEDEPLOY = "${SPDXDIR}/runtime-deploy"
 
 SPDX_INCLUDE_SOURCES ??= "0"
-SPDX_INCLUDE_PACKAGED ??= "0"
 SPDX_ARCHIVE_SOURCES ??= "0"
 SPDX_ARCHIVE_PACKAGED ??= "0"
 
@@ -431,7 +430,6 @@ python do_create_spdx() {
 
     deploy_dir_spdx = Path(d.getVar("DEPLOY_DIR_SPDX"))
     spdx_workdir = Path(d.getVar("SPDXWORK"))
-    include_packaged = d.getVar("SPDX_INCLUDE_PACKAGED") == "1"
     include_sources = d.getVar("SPDX_INCLUDE_SOURCES") == "1"
     archive_sources = d.getVar("SPDX_ARCHIVE_SOURCES") == "1"
     archive_packaged = d.getVar("SPDX_ARCHIVE_PACKAGED") == "1"
@@ -459,6 +457,7 @@ python do_create_spdx() {
 
     for s in d.getVar('SRC_URI').split():
         if not s.startswith("file://"):
+            s = s.split(';')[0]
             recipe.downloadLocation = s
             break
     else:

meta/classes/externalsrc.bbclass

@@ -61,7 +61,7 @@ python () {
         if externalsrcbuild:
             d.setVar('B', externalsrcbuild)
         else:
-            d.setVar('B', '${WORKDIR}/${BPN}-${PV}/')
+            d.setVar('B', '${WORKDIR}/${BPN}-${PV}')
 
         local_srcuri = []
         fetch = bb.fetch2.Fetch((d.getVar('SRC_URI') or '').split(), d)
@@ -212,8 +212,8 @@ def srctree_hash_files(d, srcdir=None):
     try:
         git_dir = os.path.join(s_dir,
             subprocess.check_output(['git', '-C', s_dir, 'rev-parse', '--git-dir'], stderr=subprocess.DEVNULL).decode("utf-8").rstrip())
-        top_git_dir = os.path.join(s_dir, subprocess.check_output(['git', '-C', d.getVar("TOPDIR"), 'rev-parse', '--git-dir'],
-            stderr=subprocess.DEVNULL).decode("utf-8").rstrip())
+        top_git_dir = os.path.join(d.getVar("TOPDIR"),
+            subprocess.check_output(['git', '-C', d.getVar("TOPDIR"), 'rev-parse', '--git-dir'], stderr=subprocess.DEVNULL).decode("utf-8").rstrip())
         if git_dir == top_git_dir:
             git_dir = None
     except subprocess.CalledProcessError:

meta/classes/own-mirrors.bbclass

@@ -17,4 +17,5 @@ https?://.*/.*  ${SOURCE_MIRROR_URL} \
 ftp://.*/.*     ${SOURCE_MIRROR_URL} \
 npm://.*/?.*    ${SOURCE_MIRROR_URL} \
 s3://.*/.*      ${SOURCE_MIRROR_URL} \
+crate://.*/.*   ${SOURCE_MIRROR_URL} \
 "

meta/lib/bblayers/buildconf.py

@@ -64,7 +64,7 @@ TEMPLATECONF={} . {}/oe-init-build-env build-try-{}"""
         oecore = None
 
         for l in layers:
-            if l[0] == os.path.abspath(args.layerpath):
+            if os.path.abspath(l[0]) == os.path.abspath(args.layerpath):
                 targetlayer = l[0]
             if l[1] == 'meta':
                 oecore = os.path.dirname(l[0])

meta/lib/oe/overlayfs.py

@@ -40,7 +40,11 @@ def unitFileList(d):
             bb.fatal("Missing required mount point for OVERLAYFS_MOUNT_POINT[%s] in your MACHINE configuration" % mountPoint)
 
     for mountPoint in overlayMountPoints:
-        for path in d.getVarFlag('OVERLAYFS_WRITABLE_PATHS', mountPoint).split():
+        mountPointList = d.getVarFlag('OVERLAYFS_WRITABLE_PATHS', mountPoint)
+        if not mountPointList:
+            bb.debug(1, "No mount points defined for %s flag, don't add to file list", mountPoint)
+            continue
+        for path in mountPointList.split():
             fileList.append(mountUnitName(path))
             fileList.append(helperUnitName(path))
 

meta/lib/oe/package_manager/rpm/__init__.py

@@ -98,11 +98,15 @@ class RpmPM(PackageManager):
         archs = ["sdk_provides_dummy_target"] + archs
         confdir = "%s/%s" %(self.target_rootfs, "etc/dnf/vars/")
         bb.utils.mkdirhier(confdir)
-        open(confdir + "arch", 'w').write(":".join(archs))
-        distro_codename = self.d.getVar('DISTRO_CODENAME')
-        open(confdir + "releasever", 'w').write(distro_codename if distro_codename is not None else '')
+        with open(confdir + "arch", 'w') as f:
+            f.write(":".join(archs))
 
-        open(oe.path.join(self.target_rootfs, "etc/dnf/dnf.conf"), 'w').write("")
+        distro_codename = self.d.getVar('DISTRO_CODENAME')
+        with open(confdir + "releasever", 'w') as f:
+            f.write(distro_codename if distro_codename is not None else '')
+
+        with open(oe.path.join(self.target_rootfs, "etc/dnf/dnf.conf"), 'w') as f:
+            f.write("")
 
 
     def _configure_rpm(self):
@@ -112,14 +116,17 @@ class RpmPM(PackageManager):
         platformconfdir = "%s/%s" %(self.target_rootfs, "etc/rpm/")
         rpmrcconfdir = "%s/%s" %(self.target_rootfs, "etc/")
         bb.utils.mkdirhier(platformconfdir)
-        open(platformconfdir + "platform", 'w').write("%s-pc-linux" % self.primary_arch)
+        with open(platformconfdir + "platform", 'w') as f:
+            f.write("%s-pc-linux" % self.primary_arch)
         with open(rpmrcconfdir + "rpmrc", 'w') as f:
             f.write("arch_compat: %s: %s\n" % (self.primary_arch, self.archs if len(self.archs) > 0 else self.primary_arch))
             f.write("buildarch_compat: %s: noarch\n" % self.primary_arch)
 
-        open(platformconfdir + "macros", 'w').write("%_transaction_color 7\n")
+        with open(platformconfdir + "macros", 'w') as f:
+            f.write("%_transaction_color 7\n")
         if self.d.getVar('RPM_PREFER_ELF_ARCH'):
-            open(platformconfdir + "macros", 'a').write("%%_prefer_color %s" % (self.d.getVar('RPM_PREFER_ELF_ARCH')))
+            with open(platformconfdir + "macros", 'a') as f:
+                f.write("%%_prefer_color %s" % (self.d.getVar('RPM_PREFER_ELF_ARCH')))
 
         if self.d.getVar('RPM_SIGN_PACKAGES') == '1':
             signer = get_signer(self.d, self.d.getVar('RPM_GPG_BACKEND'))
@@ -166,13 +173,13 @@ class RpmPM(PackageManager):
                     repo_uri = uri + "/" + arch
                     repo_id   = "oe-remote-repo"  + "-".join(urlparse(repo_uri).path.split("/"))
                     repo_name = "OE Remote Repo:" + " ".join(urlparse(repo_uri).path.split("/"))
-                    open(oe.path.join(self.target_rootfs, "etc", "yum.repos.d", repo_base + ".repo"), 'a').write(
-                             "[%s]\nname=%s\nbaseurl=%s\n%s\n" % (repo_id, repo_name, repo_uri, gpg_opts))
+                    with open(oe.path.join(self.target_rootfs, "etc", "yum.repos.d", repo_base + ".repo"), 'a') as f:
+                        f.write("[%s]\nname=%s\nbaseurl=%s\n%s\n" % (repo_id, repo_name, repo_uri, gpg_opts))
             else:
                 repo_name = "OE Remote Repo:" + " ".join(urlparse(uri).path.split("/"))
                 repo_uri = uri
-                open(oe.path.join(self.target_rootfs, "etc", "yum.repos.d", repo_base + ".repo"), 'w').write(
-                             "[%s]\nname=%s\nbaseurl=%s\n%s" % (repo_base, repo_name, repo_uri, gpg_opts))
+                with open(oe.path.join(self.target_rootfs, "etc", "yum.repos.d", repo_base + ".repo"), 'w') as f:
+                    f.write("[%s]\nname=%s\nbaseurl=%s\n%s" % (repo_base, repo_name, repo_uri, gpg_opts))
 
     def _prepare_pkg_transaction(self):
         os.environ['D'] = self.target_rootfs
@@ -331,7 +338,8 @@ class RpmPM(PackageManager):
             return e.output.decode("utf-8")
 
     def dump_install_solution(self, pkgs):
-        open(self.solution_manifest, 'w').write(" ".join(pkgs))
+        with open(self.solution_manifest, 'w') as f:
+            f.write(" ".join(pkgs))
         return pkgs
 
     def load_old_install_solution(self):
@@ -365,7 +373,8 @@ class RpmPM(PackageManager):
         bb.utils.mkdirhier(target_path)
         num = self._script_num_prefix(target_path)
         saved_script_name = oe.path.join(target_path, "%d-%s" % (num, pkg))
-        open(saved_script_name, 'w').write(output)
+        with open(saved_script_name, 'w') as f:
+            f.write(output)
         os.chmod(saved_script_name, 0o755)
 
     def _handle_intercept_failure(self, registered_pkgs):

meta/lib/oe/rust.py

@@ -8,4 +8,6 @@
 def arch_to_rust_arch(arch):
     if arch == "ppc64le":
         return "powerpc64le"
+    if arch in ('riscv32', 'riscv64'):
+        return arch + 'gc'
     return arch

meta/recipes-bsp/grub/grub2.inc

@@ -50,8 +50,8 @@ COMPATIBLE_HOST = "${GRUB_COMPATIBLE_HOST}"
 # Grub doesn't support hard float toolchain and won't be able to forcefully
 # disable it on some of the target CPUs. See 'configure.ac' for
 # supported/unsupported CPUs in hardfp.
-COMPATIBLE_HOST:armv7a = "${@'null' if d.getVar('TUNE_CCARGS_MFLOAT') == 'hardfp' else d.getVar('GRUB_COMPATIBLE_HOST')}"
-COMPATIBLE_HOST:armv7ve = "${@'null' if d.getVar('TUNE_CCARGS_MFLOAT') == 'hardfp' else d.getVar('GRUB_COMPATIBLE_HOST')}"
+COMPATIBLE_HOST:armv7a = "${@'null' if bb.utils.contains('TUNE_CCARGS_MFLOAT', 'hard', True, False, d) else d.getVar('GRUB_COMPATIBLE_HOST')}"
+COMPATIBLE_HOST:armv7ve = "${@'null' if bb.utils.contains('TUNE_CCARGS_MFLOAT', 'hard', True, False, d) else d.getVar('GRUB_COMPATIBLE_HOST')}"
 
 # configure.ac has code to set this automagically from the target tuple
 # but the OE freeform one (core2-foo-bar-linux) don't work with that.

meta/recipes-bsp/u-boot/u-boot.inc

@@ -5,7 +5,7 @@ PACKAGE_ARCH = "${MACHINE_ARCH}"
 
 DEPENDS += "${@bb.utils.contains('UBOOT_ENV_SUFFIX', 'scr', 'u-boot-mkimage-native', '', d)}"
 
-inherit uboot-config uboot-extlinux-config uboot-sign deploy cml1 python3native kernel-arch
+inherit uboot-config uboot-extlinux-config uboot-sign deploy python3native kernel-arch
 
 DEPENDS += "swig-native"
 
@@ -26,6 +26,13 @@ UBOOT_LOCALVERSION ?= ""
 
 require u-boot-configure.inc
 
+do_savedefconfig() {
+	bbplain "Saving defconfig to:\n${B}/defconfig"
+	oe_runmake -C ${B} savedefconfig
+}
+do_savedefconfig[nostamp] = "1"
+addtask savedefconfig after do_configure
+
 do_compile () {
     if [ "${@bb.utils.filter('DISTRO_FEATURES', 'ld-is-gold', d)}" ]; then
         sed -i 's/$(CROSS_COMPILE)ld$/$(CROSS_COMPILE)ld.bfd/g' ${S}/config.mk

meta/recipes-connectivity/bluez5/bluez5.inc

@@ -7,6 +7,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=12f884d2ae1ff87c09e5b7ccc2c4ca7e \
                     file://COPYING.LIB;md5=fb504b67c50331fc78734fed90fb0e09 \
                     file://src/main.c;beginline=1;endline=24;md5=0ad83ca0dc37ab08af448777c581e7ac"
 DEPENDS = "dbus glib-2.0"
+RDEPENDS:${PN} += "dbus"
 PROVIDES += "bluez-hcidump"
 RPROVIDES:${PN} += "bluez-hcidump"
 

meta/recipes-connectivity/openssl/files/environment.d-openssl.sh

@@ -1 +1,5 @@
 export OPENSSL_CONF="$OECORE_NATIVE_SYSROOT/usr/lib/ssl/openssl.cnf"
+export SSL_CERT_DIR="$OECORE_NATIVE_SYSROOT/usr/lib/ssl/certs"
+export SSL_CERT_FILE="$OECORE_NATIVE_SYSROOT/usr/lib/ssl/certs/ca-certificates.crt"
+export OPENSSL_MODULES="$OECORE_NATIVE_SYSROOT/usr/lib/ossl-modules/"
+export OPENSSL_ENGINES="$OECORE_NATIVE_SYSROOT/usr/lib/engines-3"

meta/recipes-connectivity/openssl/openssl_3.0.7.bb

@@ -18,7 +18,7 @@ SRC_URI:append:class-nativesdk = " \
            file://environment.d-openssl.sh \
            "
 
-SRC_URI[sha256sum] = "aa7d8d9bef71ad6525c55ba11e5f4397889ce49c2c9349dcea6d3e4f0b024a7a"
+SRC_URI[sha256sum] = "83049d042a260e696f62406ac5c08bf706fd84383f945cf21bd61e9ed95c396e"
 
 inherit lib_package multilib_header multilib_script ptest perlnative
 MULTILIB_SCRIPTS = "${PN}-bin:${bindir}/c_rehash"

meta/recipes-core/dropbear/dropbear_2022.82.bb

@@ -12,8 +12,6 @@ DEPENDS = "zlib virtual/crypt"
 RPROVIDES:${PN} = "ssh sshd"
 RCONFLICTS:${PN} = "openssh-sshd openssh"
 
-DEPENDS += "${@bb.utils.contains('DISTRO_FEATURES', 'pam', 'libpam', '', d)}"
-
 SRC_URI = "http://matt.ucc.asn.au/dropbear/releases/dropbear-${PV}.tar.bz2 \
            file://0001-urandom-xauth-changes-to-options.h.patch \
            file://init \
@@ -36,8 +34,6 @@ PAM_PLUGINS = "libpam-runtime \
 	pam-plugin-permit \
 	pam-plugin-unix \
 	"
-RDEPENDS:${PN} += "${@bb.utils.contains('DISTRO_FEATURES', 'pam', '${PAM_PLUGINS}', '', d)}"
-
 inherit autotools update-rc.d systemd
 
 CVE_PRODUCT = "dropbear_ssh"
@@ -51,14 +47,12 @@ SBINCOMMANDS = "dropbear dropbearkey dropbearconvert"
 BINCOMMANDS = "dbclient ssh scp"
 EXTRA_OEMAKE = 'MULTI=1 SCPPROGRESS=1 PROGRAMS="${SBINCOMMANDS} ${BINCOMMANDS}"'
 
-PACKAGECONFIG ?= "disable-weak-ciphers"
+PACKAGECONFIG ?= "disable-weak-ciphers ${@bb.utils.filter('DISTRO_FEATURES', 'pam', d)}"
+PACKAGECONFIG[pam] = "--enable-pam,--disable-pam,libpam,${PAM_PLUGINS}"
 PACKAGECONFIG[system-libtom] = "--disable-bundled-libtom,--enable-bundled-libtom,libtommath libtomcrypt"
 PACKAGECONFIG[disable-weak-ciphers] = ""
 PACKAGECONFIG[enable-x11-forwarding] = ""
 
-EXTRA_OECONF += "\
- ${@bb.utils.contains('DISTRO_FEATURES', 'pam', '--enable-pam', '--disable-pam', d)}"
-
 # This option appends to CFLAGS and LDFLAGS from OE
 # This is causing [textrel] QA warning
 EXTRA_OECONF += "--disable-harden"

meta/recipes-core/glib-2.0/glib-2.0/0001-gio-tests-g-file-info-don-t-assume-million-in-one-ev.patch

@@ -0,0 +1,51 @@
+Upstream-Status: Backport [https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2990]
+Signed-off-by: Ross Burton <ross.burton@arm.com>
+
+From 14838522a706ebdcc3cdab661d4c368099fe3a4e Mon Sep 17 00:00:00 2001
+From: Ross Burton <ross.burton@arm.com>
+Date: Tue, 6 Jul 2021 19:26:03 +0100
+Subject: [PATCH] gio/tests/g-file-info: don't assume million-in-one events
+ don't happen
+
+The access and creation time tests create a file, gets the time in
+seconds, then gets the time in microseconds and assumes that the
+difference between the two has to be above 0.
+
+As rare as this may be, it can happen:
+
+$ stat g-file-info-test-50A450 -c %y
+2021-07-06 18:24:56.000000767 +0100
+
+Change the test to simply assert that the difference not negative to
+handle this case.
+
+This is the same fix as 289f8b, but that was just modification time.
+---
+ gio/tests/g-file-info.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/gio/tests/g-file-info.c b/gio/tests/g-file-info.c
+index 59411c3a8..a213e4b92 100644
+--- a/gio/tests/g-file-info.c
++++ b/gio/tests/g-file-info.c
+@@ -239,7 +239,7 @@ test_g_file_info_access_time (void)
+   g_assert_nonnull (dt_usecs);
+ 
+   ts = g_date_time_difference (dt_usecs, dt);
+-  g_assert_cmpint (ts, >, 0);
++  g_assert_cmpint (ts, >=, 0);
+   g_assert_cmpint (ts, <, G_USEC_PER_SEC);
+ 
+   /* Try round-tripping the access time. */
+@@ -316,7 +316,7 @@ test_g_file_info_creation_time (void)
+   g_assert_nonnull (dt_usecs);
+ 
+   ts = g_date_time_difference (dt_usecs, dt);
+-  g_assert_cmpint (ts, >, 0);
++  g_assert_cmpint (ts, >=, 0);
+   g_assert_cmpint (ts, <, G_USEC_PER_SEC);
+ 
+   /* Try round-tripping the creation time. */
+-- 
+2.34.1
+

meta/recipes-core/glib-2.0/glib-2.0_2.72.3.bb

@@ -16,6 +16,7 @@ SRC_URI = "${GNOME_MIRROR}/glib/${SHRT_VER}/glib-${PV}.tar.xz \
            file://0001-Do-not-write-bindir-into-pkg-config-files.patch \
            file://0001-meson-Run-atomics-test-on-clang-as-well.patch \
            file://0001-gio-tests-resources.c-comment-out-a-build-host-only-.patch \
+           file://0001-gio-tests-g-file-info-don-t-assume-million-in-one-ev.patch \
            "
 SRC_URI:append:class-native = " file://relocate-modules.patch"
 

meta/recipes-core/ifupdown/ifupdown_0.8.39.bb

@@ -16,7 +16,7 @@ SRC_URI = "git://salsa.debian.org/debian/ifupdown.git;protocol=https;branch=mast
            file://0001-ifupdown-skip-wrong-test-case.patch \
            ${@bb.utils.contains('DISTRO_FEATURES', 'ptest', 'file://tweak-ptest-script.patch', '', d)} \
            "
-SRCREV = "2b4138f36ce3ba37186aa01b502273e0c39ab518"
+SRCREV = "be91dd267b4a8db502a6bbf5758563f7048b8078"
 
 S = "${WORKDIR}/git"
 

meta/recipes-core/images/build-appliance-image_15.0.0.bb

@@ -24,8 +24,8 @@ IMAGE_FSTYPES = "wic.vmdk wic.vhd wic.vhdx"
 
 inherit core-image setuptools3
 
-SRCREV ?= "4f942c272d4417b5b719df25b80a6a6b54669a73"
-SRC_URI = "git://git.yoctoproject.org/poky;branch=master \
+SRCREV ?= "80d22fc07f6284094f84d5001b8129b90c28df2c"
+SRC_URI = "git://git.yoctoproject.org/poky;branch=langdale \
            file://Yocto_Build_Appliance.vmx \
            file://Yocto_Build_Appliance.vmxf \
            file://README_VirtualBox_Guest_Additions.txt \

meta/recipes-core/meta/buildtools-tarball.bb

@@ -72,6 +72,8 @@ create_sdk_files:append () {
 	if [ -e "${SDK_OUTPUT}${SDKPATHNATIVE}${sysconfdir}/ssl/certs/ca-certificates.crt" ]; then
 		echo 'export GIT_SSL_CAINFO="${SDKPATHNATIVE}${sysconfdir}/ssl/certs/ca-certificates.crt"' >>$script
 		echo 'export SSL_CERT_FILE="${SDKPATHNATIVE}${sysconfdir}/ssl/certs/ca-certificates.crt"' >>$script
+		echo 'export REQUESTS_CA_BUNDLE="${SDKPATHNATIVE}${sysconfdir}/ssl/certs/ca-certificates.crt"' >>$script
+		echo 'export CURL_CA_BUNDLE="${SDKPATHNATIVE}${sysconfdir}/ssl/certs/ca-certificates.crt"' >>$script
 	fi
 
 	toolchain_create_sdk_version ${SDK_OUTPUT}/${SDKPATH}/version-${SDK_SYS}

meta/recipes-core/meta/cve-update-db-native.bb

@@ -18,6 +18,9 @@ NVDCVE_URL ?= "https://nvd.nist.gov/feeds/json/cve/1.1/nvdcve-1.1-"
 # Use a negative value to skip the update
 CVE_DB_UPDATE_INTERVAL ?= "86400"
 
+# Timeout for blocking socket operations, such as the connection attempt.
+CVE_SOCKET_TIMEOUT ?= "60"
+
 python () {
     if not bb.data.inherits_class("cve-check", d):
         raise bb.parse.SkipRecipe("Skip recipe when cve-check class is not loaded.")
@@ -39,6 +42,8 @@ python do_fetch() {
     db_file = d.getVar("CVE_CHECK_DB_FILE")
     db_dir = os.path.dirname(db_file)
 
+    cve_socket_timeout = int(d.getVar("CVE_SOCKET_TIMEOUT"))
+
     if os.path.exists("{0}-journal".format(db_file)):
         # If a journal is present the last update might have been interrupted. In that case,
         # just wipe any leftovers and force the DB to be recreated.
@@ -79,7 +84,7 @@ python do_fetch() {
 
             # Retrieve meta last modified date
             try:
-                response = urllib.request.urlopen(meta_url)
+                response = urllib.request.urlopen(meta_url, timeout=cve_socket_timeout)
             except urllib.error.URLError as e:
                 cve_f.write('Warning: CVE db update error, Unable to fetch CVE data.\n\n')
                 bb.warn("Failed to fetch CVE data (%s)" % e.reason)
@@ -107,7 +112,7 @@ python do_fetch() {
 
                 # Update db with current year json file
                 try:
-                    response = urllib.request.urlopen(json_url)
+                    response = urllib.request.urlopen(json_url, timeout=cve_socket_timeout)
                     if response:
                         update_db(conn, gzip.decompress(response.read()).decode('utf-8'))
                     conn.execute("insert or replace into META values (?, ?)", [year, last_modified]).close()

meta/recipes-core/psplash/psplash_git.bb

@@ -58,7 +58,7 @@ python __anonymous() {
         d.setVarFlag("ALTERNATIVE_TARGET_%s" % ep, 'psplash', '${bindir}/%s' % p)
         d.appendVar("RDEPENDS:%s" % ep, " %s" % pn)
         if p == "psplash-default":
-            d.appendVar("RRECOMMENDS:%s" % pn, " %s" % ep)
+            d.appendVar("RDEPENDS:%s" % pn, " %s" % ep)
 }
 
 S = "${WORKDIR}/git"

meta/recipes-core/systemd/systemd_251.4.bb

@@ -518,6 +518,8 @@ FILES:${PN}-extra-utils = "\
                         ${bindir}/systemd-path \
                         ${bindir}/systemd-run \
                         ${bindir}/systemd-cat \
+                        ${bindir}/systemd-creds \
+                        ${bindir}/systemd-cryptenroll \
                         ${bindir}/systemd-delta \
                         ${bindir}/systemd-cgls \
                         ${bindir}/systemd-cgtop \

meta/recipes-core/zlib/zlib/0001-Correct-incorrect-inputs-provided-to-the-CRC-functio.patch

@@ -1,54 +0,0 @@
-From ec3df00224d4b396e2ac6586ab5d25f673caa4c2 Mon Sep 17 00:00:00 2001
-From: Mark Adler <madler@alumni.caltech.edu>
-Date: Wed, 30 Mar 2022 11:14:53 -0700
-Subject: [PATCH] Correct incorrect inputs provided to the CRC functions.
-
-The previous releases of zlib were not sensitive to incorrect CRC
-inputs with bits set above the low 32. This commit restores that
-behavior, so that applications with such bugs will continue to
-operate as before.
-
-Upstream-Status: Backport [https://github.com/madler/zlib/commit/ec3df00224d4b396e2ac6586ab5d25f673caa4c2]
-Signed-off-by: Jacob Kroon <jacob.kroon@gmail.com>
----
- crc32.c | 8 ++++----
- 1 file changed, 4 insertions(+), 4 deletions(-)
-
-diff --git a/crc32.c b/crc32.c
-index a1bdce5..451887b 100644
---- a/crc32.c
-+++ b/crc32.c
-@@ -630,7 +630,7 @@ unsigned long ZEXPORT crc32_z(crc, buf, len)
- #endif /* DYNAMIC_CRC_TABLE */
- 
-     /* Pre-condition the CRC */
--    crc ^= 0xffffffff;
-+    crc = (~crc) & 0xffffffff;
- 
-     /* Compute the CRC up to a word boundary. */
-     while (len && ((z_size_t)buf & 7) != 0) {
-@@ -749,7 +749,7 @@ unsigned long ZEXPORT crc32_z(crc, buf, len)
- #endif /* DYNAMIC_CRC_TABLE */
- 
-     /* Pre-condition the CRC */
--    crc ^= 0xffffffff;
-+    crc = (~crc) & 0xffffffff;
- 
- #ifdef W
- 
-@@ -1077,7 +1077,7 @@ uLong ZEXPORT crc32_combine64(crc1, crc2, len2)
- #ifdef DYNAMIC_CRC_TABLE
-     once(&made, make_crc_table);
- #endif /* DYNAMIC_CRC_TABLE */
--    return multmodp(x2nmodp(len2, 3), crc1) ^ crc2;
-+    return multmodp(x2nmodp(len2, 3), crc1) ^ (crc2 & 0xffffffff);
- }
- 
- /* ========================================================================= */
-@@ -1112,5 +1112,5 @@ uLong crc32_combine_op(crc1, crc2, op)
-     uLong crc2;
-     uLong op;
- {
--    return multmodp(op, crc1) ^ crc2;
-+    return multmodp(op, crc1) ^ (crc2 & 0xffffffff);
- }

meta/recipes-core/zlib/zlib/0001-Fix-a-bug-when-getting-a-gzip-header-extra-field-wit.patch

@@ -1,38 +0,0 @@
-From eff308af425b67093bab25f80f1ae950166bece1 Mon Sep 17 00:00:00 2001
-From: Mark Adler <fork@madler.net>
-Date: Sat, 30 Jul 2022 15:51:11 -0700
-Subject: [PATCH] Fix a bug when getting a gzip header extra field with inflate().
-
-If the extra field was larger than the space the user provided with
-inflateGetHeader(), and if multiple calls of inflate() delivered
-the extra header data, then there could be a buffer overflow of the
-provided space. This commit assures that provided space is not
-exceeded.
-
-CVE: CVE-2022-37434
-Upstream-Status: Backport [https://github.com/madler/zlib/commit/eff308af425b67093bab25f80f1ae950166be]
-Signed-off-by: Khem Raj <raj.khem@gmail.com>
----
- inflate.c | 5 +++--
- 1 file changed, 3 insertions(+), 2 deletions(-)
-
-diff --git a/inflate.c b/inflate.c
-index 7be8c63..7a72897 100644
---- a/inflate.c
-+++ b/inflate.c
-@@ -763,9 +763,10 @@ int flush;
-                 copy = state->length;
-                 if (copy > have) copy = have;
-                 if (copy) {
-+                    len = state->head->extra_len - state->length;
-                     if (state->head != Z_NULL &&
--                        state->head->extra != Z_NULL) {
--                        len = state->head->extra_len - state->length;
-+                        state->head->extra != Z_NULL &&
-+                        len < state->head->extra_max) {
-                         zmemcpy(state->head->extra + len, next,
-                                 len + copy > state->head->extra_max ?
-                                 state->head->extra_max - len : copy);
--- 
-2.37.2
-

meta/recipes-core/zlib/zlib/0001-Fix-extra-field-processing-bug-that-dereferences-NUL.patch

@@ -1,36 +0,0 @@
-From 1eb7682f845ac9e9bf9ae35bbfb3bad5dacbd91d Mon Sep 17 00:00:00 2001
-From: Mark Adler <fork@madler.net>
-Date: Mon, 8 Aug 2022 10:50:09 -0700
-Subject: [PATCH] Fix extra field processing bug that dereferences NULL
- state->head.
-
-The recent commit to fix a gzip header extra field processing bug
-introduced the new bug fixed here.
-
-CVE: CVE-2022-37434
-Upstream-Status: Backport [https://github.com/madler/zlib/commit/1eb7682f845ac9e9bf9ae35bbfb3bad5dacbd91d]
-Signed-off-by: Khem Raj <raj.khem@gmail.com>
----
- inflate.c | 4 ++--
- 1 file changed, 2 insertions(+), 2 deletions(-)
-
-diff --git a/inflate.c b/inflate.c
-index 7a72897..2a3c4fe 100644
---- a/inflate.c
-+++ b/inflate.c
-@@ -763,10 +763,10 @@ int flush;
-                 copy = state->length;
-                 if (copy > have) copy = have;
-                 if (copy) {
--                    len = state->head->extra_len - state->length;
-                     if (state->head != Z_NULL &&
-                         state->head->extra != Z_NULL &&
--                        len < state->head->extra_max) {
-+                        (len = state->head->extra_len - state->length) <
-+                            state->head->extra_max) {
-                         zmemcpy(state->head->extra + len, next,
-                                 len + copy > state->head->extra_max ?
-                                 state->head->extra_max - len : copy);
--- 
-2.37.2
-

meta/recipes-core/zlib/zlib/cc.patch

@@ -1,27 +0,0 @@
-Upstream-Status: Backport
-Signed-off-by: Ross Burton <ross.burton@arm.com>
-
-From 05796d3d8d5546cf1b4dfe2cd72ab746afae505d Mon Sep 17 00:00:00 2001
-From: Mark Adler <madler@alumni.caltech.edu>
-Date: Mon, 28 Mar 2022 18:34:10 -0700
-Subject: [PATCH] Fix configure issue that discarded provided CC definition.
-
----
- configure | 3 +++
- 1 file changed, 3 insertions(+)
-
-diff --git a/configure b/configure
-index 52ff4a04e..3fa3e8618 100755
---- a/configure
-+++ b/configure
-@@ -174,7 +174,10 @@ if test -z "$CC"; then
-   else
-     cc=${CROSS_PREFIX}cc
-   fi
-+else
-+  cc=${CC}
- fi
-+
- cflags=${CFLAGS-"-O3"}
- # to force the asm version use: CFLAGS="-O3 -DASMV" ./configure
- case "$cc" in

meta/recipes-core/zlib/zlib/ldflags-tests.patch

@@ -1,45 +0,0 @@
-Obey LDFLAGS for tests
-
-Upstream-Status: Submitted [https://github.com/madler/zlib/pull/409]
-Signed-off-by: Ross Burton <ross.burton@intel.com>
-
---- zlib-1.2.8.orig/Makefile.in
-+++ zlib-1.2.8/Makefile.in
-@@ -26,7 +26,7 @@ CFLAGS=-O
-
- SFLAGS=-O
- LDFLAGS=
--TEST_LDFLAGS=-L. libz.a
-+TEST_LDFLAGS=-L. $(LDFLAGS)
- LDSHARED=$(CC)
- CPP=$(CC) -E
-
-@@ -176,22 +176,22 @@ placebo $(SHAREDLIBV): $(PIC_OBJS) libz.
-	-@rmdir objs
-
- example$(EXE): example.o $(STATICLIB)
--	$(CC) $(CFLAGS) -o $@ example.o $(TEST_LDFLAGS)
-+	$(CC) $(CFLAGS) -o $@ example.o $(TEST_LDFLAGS) $(STATICLIB)
-
- minigzip$(EXE): minigzip.o $(STATICLIB)
--	$(CC) $(CFLAGS) -o $@ minigzip.o $(TEST_LDFLAGS)
-+	$(CC) $(CFLAGS) -o $@ minigzip.o $(TEST_LDFLAGS) $(STATICLIB)
-
- examplesh$(EXE): example.o $(SHAREDLIBV)
--	$(CC) $(CFLAGS) -o $@ example.o -L. $(SHAREDLIBV)
-+	$(CC) $(CFLAGS) -o $@ example.o $(TEST_LDFLAGS) $(SHAREDLIBV)
-
- minigzipsh$(EXE): minigzip.o $(SHAREDLIBV)
--	$(CC) $(CFLAGS) -o $@ minigzip.o -L. $(SHAREDLIBV)
-+	$(CC) $(CFLAGS) -o $@ minigzip.o $(TEST_LDFLAGS) $(SHAREDLIBV)
-
- example64$(EXE): example64.o $(STATICLIB)
--	$(CC) $(CFLAGS) -o $@ example64.o $(TEST_LDFLAGS)
-+	$(CC) $(CFLAGS) -o $@ example64.o $(TEST_LDFLAGS) $(STATICLIB)
-
- minigzip64$(EXE): minigzip64.o $(STATICLIB)
--	$(CC) $(CFLAGS) -o $@ minigzip64.o $(TEST_LDFLAGS)
-+	$(CC) $(CFLAGS) -o $@ minigzip64.o $(TEST_LDFLAGS) $(STATICLIB)
-
- install-libs: $(LIBS)
-	-@if [ ! -d $(DESTDIR)$(exec_prefix)  ]; then mkdir -p $(DESTDIR)$(exec_prefix); fi

meta/recipes-core/zlib/zlib_1.2.13.bb

@@ -6,18 +6,18 @@ SECTION = "libs"
 LICENSE = "Zlib"
 LIC_FILES_CHKSUM = "file://zlib.h;beginline=6;endline=23;md5=5377232268e952e9ef63bc555f7aa6c0"
 
-SRC_URI = "https://zlib.net/${BP}.tar.xz \
-           file://cc.patch \
-           file://ldflags-tests.patch \
+# The source tarball needs to be .gz as only the .gz ends up in fossils/
+SRC_URI = "https://zlib.net/${BP}.tar.gz \
            file://0001-configure-Pass-LDFLAGS-to-link-tests.patch \
            file://run-ptest \
-           file://0001-Correct-incorrect-inputs-provided-to-the-CRC-functio.patch \
-           file://0001-Fix-a-bug-when-getting-a-gzip-header-extra-field-wit.patch \
-           file://0001-Fix-extra-field-processing-bug-that-dereferences-NUL.patch \
            "
 UPSTREAM_CHECK_URI = "http://zlib.net/"
 
-SRC_URI[sha256sum] = "7db46b8d7726232a621befaab4a1c870f00a90805511c0e0090441dac57def18"
+SRC_URI[sha256sum] = "b3a24de97a8fdbc835b9833169501030b8977031bcb54b3b3ac13740f846ab30"
+
+# When a new release is made the previous release is moved to fossils/, so add this
+# to PREMIRRORS so it is also searched automatically.
+PREMIRRORS:append = " https://zlib.net/ https://zlib.net/fossils/"
 
 CFLAGS += "-D_REENTRANT"
 
@@ -25,9 +25,12 @@ RDEPENDS:${PN}-ptest += "make"
 
 inherit ptest
 
+B = "${WORKDIR}/build"
+
 do_configure() {
-	LDCONFIG=true ./configure --prefix=${prefix} --shared --libdir=${libdir} --uname=GNU
+	LDCONFIG=true ${S}/configure --prefix=${prefix} --shared --libdir=${libdir} --uname=GNU
 }
+do_configure[cleandirs] += "${B}"
 
 do_compile() {
 	oe_runmake shared

meta/recipes-devtools/cmake/cmake-native_3.24.0.bb

@@ -32,6 +32,7 @@ CMAKE_EXTRACONF = "\
     -DCMAKE_USE_SYSTEM_LIBRARY_EXPAT=0 \
     -DENABLE_ACL=0 -DHAVE_ACL_LIBACL_H=0 \
     -DHAVE_SYS_ACL_H=0 \
+    -DCURL_LIBRARIES=-lcurl \
 "
 
 do_configure () {

meta/recipes-devtools/gcc/gcc/0002-gcc-poison-system-directories.patch

@@ -1,4 +1,4 @@
-From e1dbdcd0ea667bab4b551294354e04c6fe288ab6 Mon Sep 17 00:00:00 2001
+From 99f1e61b2957226254a116fde7fd73bf07034012 Mon Sep 17 00:00:00 2001
 From: Khem Raj <raj.khem@gmail.com>
 Date: Mon, 8 Mar 2021 16:04:20 -0800
 Subject: [PATCH] gcc: poison-system-directories
@@ -20,12 +20,12 @@ Signed-off-by: Khem Raj <raj.khem@gmail.com>
  gcc/configure       | 19 +++++++++++++++++++
  gcc/configure.ac    | 16 ++++++++++++++++
  gcc/doc/invoke.texi |  9 +++++++++
- gcc/gcc.cc          |  9 +++++++--
+ gcc/gcc.cc          | 15 ++++++++++++---
  gcc/incpath.cc      | 21 +++++++++++++++++++++
- 7 files changed, 86 insertions(+), 2 deletions(-)
+ 7 files changed, 91 insertions(+), 3 deletions(-)
 
 diff --git a/gcc/common.opt b/gcc/common.opt
-index 8a0dafc522d..0357868e22c 100644
+index 8a0dafc52..0357868e2 100644
 --- a/gcc/common.opt
 +++ b/gcc/common.opt
 @@ -710,6 +710,10 @@ Wreturn-local-addr
@@ -40,7 +40,7 @@ index 8a0dafc522d..0357868e22c 100644
  Common Var(warn_shadow) Warning
  Warn when one variable shadows another.  Same as -Wshadow=global.
 diff --git a/gcc/config.in b/gcc/config.in
-index 64c27c9cfac..a693cb8a886 100644
+index 64c27c9cf..a693cb8a8 100644
 --- a/gcc/config.in
 +++ b/gcc/config.in
 @@ -230,6 +230,16 @@
@@ -61,7 +61,7 @@ index 64c27c9cfac..a693cb8a886 100644
     optimizer and back end) to be checked for dynamic type safety at runtime.
     This is quite expensive. */
 diff --git a/gcc/configure b/gcc/configure
-index 5ce0557719a..dc2d59701ad 100755
+index 2b83acfb0..8bb97578c 100755
 --- a/gcc/configure
 +++ b/gcc/configure
 @@ -1023,6 +1023,7 @@ enable_maintainer_mode
@@ -81,7 +81,7 @@ index 5ce0557719a..dc2d59701ad 100755
    --enable-plugin         enable plugin support
    --enable-host-shared    build host code as shared libraries
    --disable-libquadmath-support
-@@ -31982,6 +31985,22 @@ if test "${enable_version_specific_runtime_libs+set}" = set; then :
+@@ -31996,6 +31999,22 @@ if test "${enable_version_specific_runtime_libs+set}" = set; then :
  fi
  
  
@@ -105,10 +105,10 @@ index 5ce0557719a..dc2d59701ad 100755
  
  
 diff --git a/gcc/configure.ac b/gcc/configure.ac
-index 23bee7010a3..36ce78924de 100644
+index daf2a708c..6155b83a7 100644
 --- a/gcc/configure.ac
 +++ b/gcc/configure.ac
-@@ -7421,6 +7421,22 @@ AC_ARG_ENABLE(version-specific-runtime-libs,
+@@ -7435,6 +7435,22 @@ AC_ARG_ENABLE(version-specific-runtime-libs,
                  [specify that runtime libraries should be
                   installed in a compiler-specific directory])])
  
@@ -132,7 +132,7 @@ index 23bee7010a3..36ce78924de 100644
  AC_SUBST(subdirs)
  AC_SUBST(srcdir)
 diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
-index 07b440190c3..b2de464798a 100644
+index ff6c338be..a8ebfa59a 100644
 --- a/gcc/doc/invoke.texi
 +++ b/gcc/doc/invoke.texi
 @@ -379,6 +379,7 @@ Objective-C and Objective-C++ Dialects}.
@@ -159,10 +159,10 @@ index 07b440190c3..b2de464798a 100644
  @opindex Wfloat-equal
  @opindex Wno-float-equal
 diff --git a/gcc/gcc.cc b/gcc/gcc.cc
-index bb07cc244e3..ce161d3c853 100644
+index beefde7f6..4e6557b3c 100644
 --- a/gcc/gcc.cc
 +++ b/gcc/gcc.cc
-@@ -1159,6 +1159,8 @@ proper position among the other output files.  */
+@@ -1162,6 +1162,8 @@ proper position among the other output files.  */
     "%{fuse-ld=*:-fuse-ld=%*} " LINK_COMPRESS_DEBUG_SPEC \
     "%X %{o*} %{e*} %{N} %{n} %{r}\
      %{s} %{t} %{u*} %{z} %{Z} %{!nostdlib:%{!r:%{!nostartfiles:%S}}} \
@@ -171,7 +171,7 @@ index bb07cc244e3..ce161d3c853 100644
      %{static|no-pie|static-pie:} %@{L*} %(mfwrap) %(link_libgcc) " \
      VTABLE_VERIFICATION_SPEC " " SANITIZER_EARLY_SPEC " %o "" \
      %{fopenacc|fopenmp|%:gt(%{ftree-parallelize-loops=*:%*} 1):\
-@@ -1254,8 +1256,11 @@ static const char *cpp_unique_options =
+@@ -1257,8 +1259,11 @@ static const char *cpp_unique_options =
  static const char *cpp_options =
  "%(cpp_unique_options) %1 %{m*} %{std*&ansi&trigraphs} %{W*&pedantic*} %{w}\
   %{f*} %{g*:%{%:debug-level-gt(0):%{g*}\
@@ -179,27 +179,27 @@ index bb07cc244e3..ce161d3c853 100644
 - %{undef} %{save-temps*:-fpch-preprocess}";
 + %{!fno-working-directory:-fworking-directory}}} %{O*}"
 +#ifdef POISON_BY_DEFAULT
-+ " -Werror=poison-system-directories"
++ " %{!Wno-error=poison-system-directories:-Werror=poison-system-directories}"
 +#endif
 + " %{undef} %{save-temps*:-fpch-preprocess}";
  
  /* Pass -d* flags, possibly modifying -dumpdir, -dumpbase et al.
  
-@@ -1265,7 +1270,11 @@ static const char *cc1_options =
+@@ -1287,7 +1292,11 @@ static const char *cc1_options =
   %{coverage:-fprofile-arcs -ftest-coverage}\
   %{fprofile-arcs|fprofile-generate*|coverage:\
     %{!fprofile-update=single:\
 -     %{pthread:-fprofile-update=prefer-atomic}}}";
 +     %{pthread:-fprofile-update=prefer-atomic}}}"
 +#ifdef POISON_BY_DEFAULT
-+ " -Werror=poison-system-directories"
++ " %{!Wno-error=poison-system-directories:-Werror=poison-system-directories}"
 +#endif
 +  ;
-
+ 
  static const char *asm_options =
  "%{-target-help:%:print-asm-header()} "
 diff --git a/gcc/incpath.cc b/gcc/incpath.cc
-index bd2a97938eb..c80f100f476 100644
+index 622204a38..5ac03c086 100644
 --- a/gcc/incpath.cc
 +++ b/gcc/incpath.cc
 @@ -26,6 +26,7 @@

meta/recipes-devtools/meson/meson/meson-wrapper

@@ -5,7 +5,7 @@ if [ -z "$OECORE_NATIVE_SYSROOT" ]; then
 fi
 
 if [ -z "$SSL_CERT_DIR" ]; then
-    export SSL_CERT_DIR="${OECORE_NATIVE_SYSROOT}/etc/ssl/certs/"
+    export SSL_CERT_DIR="$OECORE_NATIVE_SYSROOT/etc/ssl/certs/"
 fi
 
 # If these are set to a cross-compile path, meson will get confused and try to
@@ -13,7 +13,20 @@ fi
 # config is already in meson.cross.
 unset CC CXX CPP LD AR NM STRIP
 
+for arg in "$@"; do
+    case "$arg" in
+    -*) continue ;;
+    *) SUBCMD="$arg"; break ;;
+    esac
+done
+
+if [ "$SUBCMD" = "setup" ] || [ -d "$SUBCMD" ]; then
+    MESON_SUB_OPTS=" \
+        --cross-file="$OECORE_NATIVE_SYSROOT/usr/share/meson/${TARGET_PREFIX}meson.cross" \
+        --native-file="$OECORE_NATIVE_SYSROOT/usr/share/meson/meson.native" \
+        "
+fi
+
 exec "$OECORE_NATIVE_SYSROOT/usr/bin/meson.real" \
-     --cross-file "${OECORE_NATIVE_SYSROOT}/usr/share/meson/${TARGET_PREFIX}meson.cross" \
-     --native-file "${OECORE_NATIVE_SYSROOT}/usr/share/meson/meson.native" \
-     "$@"
+    "$@" \
+    $MESON_SUB_OPTS

meta/recipes-devtools/meson/meson_0.63.3.bb

@@ -18,7 +18,7 @@ SRC_URI = "${GITHUB_BASE_URI}/download/${PV}/meson-${PV}.tar.gz \
            file://0001-is_debianlike-always-return-False.patch \
            file://0001-Check-for-clang-before-guessing-gcc-or-lcc.patch \
            "
-SRC_URI[sha256sum] = "16222f17ef76be0542c91c07994f9676ae879f46fc21c0c786a21ef2cb518bbf"
+SRC_URI[sha256sum] = "519c0932e1a8b208741f0fdce90aa5c0b528dd297cf337009bf63539846ac056"
 
 inherit python_setuptools_build_meta github-releases
 

meta/recipes-devtools/mtools/mtools/disable-hardcoded-configs.patch

@@ -1,4 +1,4 @@
-From 3a05dc2c0acff1713dd44cef5e9f328f0706eb3e Mon Sep 17 00:00:00 2001
+From c496cad7b7a84e599f521f289648373df9fad80f Mon Sep 17 00:00:00 2001
 From: Ed Bartosh <ed.bartosh@linux.intel.com>
 Date: Tue, 13 Jun 2017 14:55:52 +0300
 Subject: [PATCH] Disabled reading host configs.
@@ -12,10 +12,10 @@ Signed-off-by: Ed Bartosh <ed.bartosh@linux.intel.com>
  1 file changed, 8 deletions(-)
 
 diff --git a/config.c b/config.c
-index 630f99d..07dbf53 100644
+index 8c5fa83..346048b 100644
 --- a/config.c
 +++ b/config.c
-@@ -834,14 +834,6 @@ void read_config(void)
+@@ -843,14 +843,6 @@ void read_config(void)
  	memcpy(devices, const_devices,
  	       nr_const_devices*sizeof(struct device));