build-appliance-image: Update to mickledore head revision

(From OE-Core rev: 23b5141400b2c676c806df3308f023f7c04e34e0)

Signed-off-by: Steve Sakoman <steve@sakoman.com>

README.OE-Core.md

@@ -16,9 +16,13 @@ which can be found at:
 Contributing
 ------------
 
-Please refer to
-https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded
-for guidelines on how to submit patches.
+Please refer to our contributor guide here: https://docs.yoctoproject.org/dev/contributor-guide/
+for full details on how to submit changes.
+
+As a quick guide, patches should be sent to openembedded-core@lists.openembedded.org
+The git command to do that would be:
+
+     git send-email -M -1 --to openembedded-core@lists.openembedded.org
 
 Mailing list:
 

SECURITY.md

@@ -0,0 +1,24 @@
+How to Report a Potential Vulnerability?
+========================================
+
+If you would like to report a public issue (for example, one with a released
+CVE number), please report it using the
+[https://bugzilla.yoctoproject.org/enter_bug.cgi?product=Security Security Bugzilla].
+If you have a patch ready, submit it following the same procedure as any other
+patch as described in README.md.
+
+If you are dealing with a not-yet released or urgent issue, please send a
+message to security AT yoctoproject DOT org, including as many details as
+possible: the layer or software module affected, the recipe and its version,
+and any example code, if available.
+
+Branches maintained with security fixes
+---------------------------------------
+
+See [https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS Stable release and LTS]
+for detailed info regarding the policies and maintenance of Stable branches.
+
+The [https://wiki.yoctoproject.org/wiki/Releases Release page] contains a list of all
+releases of the Yocto Project. Versions in grey are no longer actively maintained with
+security patches, but well-tested patches may still be accepted for them for
+significant issues.

bitbake/SECURITY.md

@@ -0,0 +1,24 @@
+How to Report a Potential Vulnerability?
+========================================
+
+If you would like to report a public issue (for example, one with a released
+CVE number), please report it using the
+[https://bugzilla.yoctoproject.org/enter_bug.cgi?product=Security Security Bugzilla].
+If you have a patch ready, submit it following the same procedure as any other
+patch as described in README.md.
+
+If you are dealing with a not-yet released or urgent issue, please send a
+message to security AT yoctoproject DOT org, including as many details as
+possible: the layer or software module affected, the recipe and its version,
+and any example code, if available.
+
+Branches maintained with security fixes
+---------------------------------------
+
+See [https://wiki.yoctoproject.org/wiki/Stable_Release_and_LTS Stable release and LTS]
+for detailed info regarding the policies and maintenance of Stable branches.
+
+The [https://wiki.yoctoproject.org/wiki/Releases Release page] contains a list of all
+releases of the Yocto Project. Versions in grey are no longer actively maintained with
+security patches, but well-tested patches may still be accepted for them for
+significant issues.

bitbake/bin/bitbake

@@ -27,7 +27,7 @@ from bb.main import bitbake_main, BitBakeConfigParameters, BBMainException
 
 bb.utils.check_system_locale()
 
-__version__ = "2.2.0"
+__version__ = "2.4.0"
 
 if __name__ == "__main__":
     if __version__ != bb.__version__:

bitbake/bin/bitbake-worker

@@ -269,7 +269,7 @@ def fork_off_task(cfg, data, databuilder, workerdata, extraconfigdata, runtask):
 
                 bb.utils.set_process_name("%s:%s" % (the_data.getVar("PN"), taskname.replace("do_", "")))
 
-                if not the_data.getVarFlag(taskname, 'network', False):
+                if not bb.utils.to_boolean(the_data.getVarFlag(taskname, 'network')):
                     if bb.utils.is_local_uid(uid):
                         logger.debug("Attempting to disable network for %s" % taskname)
                         bb.utils.disable_network(uid, gid)

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

@@ -656,7 +656,7 @@ builds are when execute, bitbake also supports user defined
 configuration of the `Python
 logging <https://docs.python.org/3/library/logging.html>`__ facilities
 through the :term:`BB_LOGCONFIG` variable. This
-variable defines a json or yaml `logging
+variable defines a JSON or YAML `logging
 configuration <https://docs.python.org/3/library/logging.config.html>`__
 that will be intelligently merged into the default configuration. The
 logging configuration is merged using the following rules:
@@ -690,9 +690,9 @@ logging configuration is merged using the following rules:
    adds a filter called ``BitBake.defaultFilter``, both filters will be
    applied to the logger
 
-As an example, consider the following user logging configuration file
-which logs all Hash Equivalence related messages of VERBOSE or higher to
-a file called ``hashequiv.log`` ::
+As a first example, you can create a ``hashequiv.json`` user logging
+configuration file to log all Hash Equivalence related messages of ``VERBOSE``
+or higher priority to a file called ``hashequiv.log``::
 
    {
        "version": 1,
@@ -721,3 +721,40 @@ a file called ``hashequiv.log`` ::
            }
        }
    }
+
+Then set the :term:`BB_LOGCONFIG` variable in ``conf/local.conf``::
+
+   BB_LOGCONFIG = "hashequiv.json"
+
+Another example is this ``warn.json`` file to log all ``WARNING`` and
+higher priority messages to a ``warn.log`` file::
+
+  {
+      "version": 1,
+      "formatters": {
+          "warnlogFormatter": {
+              "()": "bb.msg.BBLogFormatter",
+              "format": "%(levelname)s: %(message)s"
+          }
+      },
+
+      "handlers": {
+          "warnlog": {
+              "class": "logging.FileHandler",
+              "formatter": "warnlogFormatter",
+              "level": "WARNING",
+              "filename": "warn.log"
+          }
+      },
+
+      "loggers": {
+          "BitBake": {
+              "handlers": ["warnlog"]
+          }
+      },
+
+      "@disable_existing_loggers": false
+  }
+
+Note that BitBake's helper classes for structured logging are implemented in
+``lib/bb/msg.py``.

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

@@ -18,28 +18,32 @@ it.
 Obtaining BitBake
 =================
 
-See the :ref:`bitbake-user-manual/bitbake-user-manual-hello:obtaining bitbake` section for
+See the :ref:`bitbake-user-manual/bitbake-user-manual-intro:obtaining bitbake` section for
 information on how to obtain BitBake. Once you have the source code on
 your machine, the BitBake directory appears as follows::
 
    $ ls -al
-   total 100
-   drwxrwxr-x. 9 wmat wmat  4096 Jan 31 13:44 .
-   drwxrwxr-x. 3 wmat wmat  4096 Feb  4 10:45 ..
-   -rw-rw-r--. 1 wmat wmat   365 Nov 26 04:55 AUTHORS
-   drwxrwxr-x. 2 wmat wmat  4096 Nov 26 04:55 bin
-   drwxrwxr-x. 4 wmat wmat  4096 Jan 31 13:44 build
-   -rw-rw-r--. 1 wmat wmat 16501 Nov 26 04:55 ChangeLog
-   drwxrwxr-x. 2 wmat wmat  4096 Nov 26 04:55 classes
-   drwxrwxr-x. 2 wmat wmat  4096 Nov 26 04:55 conf
-   drwxrwxr-x. 3 wmat wmat  4096 Nov 26 04:55 contrib
-   -rw-rw-r--. 1 wmat wmat 17987 Nov 26 04:55 COPYING
-   drwxrwxr-x. 3 wmat wmat  4096 Nov 26 04:55 doc
-   -rw-rw-r--. 1 wmat wmat    69 Nov 26 04:55 .gitignore
-   -rw-rw-r--. 1 wmat wmat   849 Nov 26 04:55 HEADER
-   drwxrwxr-x. 5 wmat wmat  4096 Jan 31 13:44 lib
-   -rw-rw-r--. 1 wmat wmat   195 Nov 26 04:55 MANIFEST.in
-   -rw-rw-r--. 1 wmat wmat  2887 Nov 26 04:55 TODO
+   total 108
+   drwxr-xr-x  9 fawkh 10000  4096 feb 24 12:10 .
+   drwx------ 36 fawkh 10000  4096 mar  2 17:00 ..
+   -rw-r--r--  1 fawkh 10000   365 feb 24 12:10 AUTHORS
+   drwxr-xr-x  2 fawkh 10000  4096 feb 24 12:10 bin
+   -rw-r--r--  1 fawkh 10000 16501 feb 24 12:10 ChangeLog
+   drwxr-xr-x  2 fawkh 10000  4096 feb 24 12:10 classes
+   drwxr-xr-x  2 fawkh 10000  4096 feb 24 12:10 conf
+   drwxr-xr-x  5 fawkh 10000  4096 feb 24 12:10 contrib
+   drwxr-xr-x  6 fawkh 10000  4096 feb 24 12:10 doc
+   drwxr-xr-x  8 fawkh 10000  4096 mar  2 16:26 .git
+   -rw-r--r--  1 fawkh 10000    31 feb 24 12:10 .gitattributes
+   -rw-r--r--  1 fawkh 10000   392 feb 24 12:10 .gitignore
+   drwxr-xr-x 13 fawkh 10000  4096 feb 24 12:11 lib
+   -rw-r--r--  1 fawkh 10000  1224 feb 24 12:10 LICENSE
+   -rw-r--r--  1 fawkh 10000 15394 feb 24 12:10 LICENSE.GPL-2.0-only
+   -rw-r--r--  1 fawkh 10000  1286 feb 24 12:10 LICENSE.MIT
+   -rw-r--r--  1 fawkh 10000   229 feb 24 12:10 MANIFEST.in
+   -rw-r--r--  1 fawkh 10000  2413 feb 24 12:10 README
+   -rw-r--r--  1 fawkh 10000    43 feb 24 12:10 toaster-requirements.txt
+   -rw-r--r--  1 fawkh 10000  2887 feb 24 12:10 TODO
 
 At this point, you should have BitBake cloned to a directory that
 matches the previous listing except for dates and user names.
@@ -52,7 +56,7 @@ directory to where your local BitBake files are and run the following
 command::
 
   $ ./bin/bitbake --version
-  BitBake Build Tool Core version 1.23.0, bitbake version 1.23.0
+  BitBake Build Tool Core version 2.3.1
 
 The console output tells you what version
 you are running.
@@ -130,23 +134,8 @@ Following is the complete "Hello World" example.
     directory. Run the ``bitbake`` command and see what it does::
 
        $ bitbake
-       The BBPATH variable is not set and bitbake did not
-       find a conf/bblayers.conf file in the expected location.
+       ERROR: The BBPATH variable is not set and bitbake did not find a conf/bblayers.conf file in the expected location.
        Maybe you accidentally invoked bitbake from the wrong directory?
-       DEBUG: Removed the following variables from the environment:
-       GNOME_DESKTOP_SESSION_ID, XDG_CURRENT_DESKTOP,
-       GNOME_KEYRING_CONTROL, DISPLAY, SSH_AGENT_PID, LANG, no_proxy,
-       XDG_SESSION_PATH, XAUTHORITY, SESSION_MANAGER, SHLVL,
-       MANDATORY_PATH, COMPIZ_CONFIG_PROFILE, WINDOWID, EDITOR,
-       GPG_AGENT_INFO, SSH_AUTH_SOCK, GDMSESSION, GNOME_KEYRING_PID,
-       XDG_SEAT_PATH, XDG_CONFIG_DIRS, LESSOPEN, DBUS_SESSION_BUS_ADDRESS,
-       _, XDG_SESSION_COOKIE, DESKTOP_SESSION, LESSCLOSE, DEFAULTS_PATH,
-       UBUNTU_MENUPROXY, OLDPWD, XDG_DATA_DIRS, COLORTERM, LS_COLORS
-
-    The majority of this output is specific to environment variables that
-    are not directly relevant to BitBake. However, the very first
-    message regarding the :term:`BBPATH` variable and the
-    ``conf/bblayers.conf`` file is relevant.
 
     When you run BitBake, it begins looking for metadata files. The
     :term:`BBPATH` variable is what tells BitBake where
@@ -179,20 +168,14 @@ Following is the complete "Hello World" example.
     ``bitbake`` command again::
 
        $ bitbake
-       ERROR: Traceback (most recent call last):
-         File "/home/scott-lenovo/bitbake/lib/bb/cookerdata.py", line 163, in wrapped
-           return func(fn, *args)
-         File "/home/scott-lenovo/bitbake/lib/bb/cookerdata.py", line 173, in parse_config_file
-           return bb.parse.handle(fn, data, include)
-         File "/home/scott-lenovo/bitbake/lib/bb/parse/__init__.py", line 99, in handle
-           return h['handle'](fn, data, include)
-         File "/home/scott-lenovo/bitbake/lib/bb/parse/parse_py/ConfHandler.py", line 120, in handle
-           abs_fn = resolve_file(fn, data)
-         File "/home/scott-lenovo/bitbake/lib/bb/parse/__init__.py", line 117, in resolve_file
-           raise IOError("file %s not found in %s" % (fn, bbpath))
-       IOError: file conf/bitbake.conf not found in /home/scott-lenovo/hello
+       ERROR: Unable to parse /home/scott-lenovo/bitbake/lib/bb/parse/__init__.py
+       Traceback (most recent call last):
+       File "/home/scott-lenovo/bitbake/lib/bb/parse/__init__.py", line 127, in resolve_file(fn='conf/bitbake.conf', d=<bb.data_smart.DataSmart object at 0x7f22919a3df0>):
+             if not newfn:
+       >            raise IOError(errno.ENOENT, "file %s not found in %s" % (fn, bbpath))
+             fn = newfn
+       FileNotFoundError: [Errno 2] file conf/bitbake.conf not found in <projectdirectory>
 
-       ERROR: Unable to parse conf/bitbake.conf: file conf/bitbake.conf not found in /home/scott-lenovo/hello
 
     This sample output shows that BitBake could not find the
     ``conf/bitbake.conf`` file in the project directory. This file is
@@ -254,18 +237,14 @@ Following is the complete "Hello World" example.
     exists, you can run the ``bitbake`` command again::
 
        $ bitbake
-       ERROR: Traceback (most recent call last):
-         File "/home/scott-lenovo/bitbake/lib/bb/cookerdata.py", line 163, in wrapped
-           return func(fn, *args)
-         File "/home/scott-lenovo/bitbake/lib/bb/cookerdata.py", line 177, in _inherit
-           bb.parse.BBHandler.inherit(bbclass, "configuration INHERITs", 0, data)
-         File "/home/scott-lenovo/bitbake/lib/bb/parse/parse_py/BBHandler.py", line 92, in inherit
-           include(fn, file, lineno, d, "inherit")
-         File "/home/scott-lenovo/bitbake/lib/bb/parse/parse_py/ConfHandler.py", line 100, in include
-           raise ParseError("Could not %(error_out)s file %(fn)s" % vars(), oldfn, lineno)
-       ParseError: ParseError in configuration INHERITs: Could not inherit file classes/base.bbclass
+       ERROR: Unable to parse /home/scott-lenovo/bitbake/lib/bb/parse/parse_py/BBHandler.py
+       Traceback (most recent call last):
+       File "/home/scott-lenovo/bitbake/lib/bb/parse/parse_py/BBHandler.py", line 67, in inherit(files=['base'], fn='configuration INHERITs', lineno=0, d=<bb.data_smart.DataSmart object at 0x7fab6815edf0>):
+             if not os.path.exists(file):
+       >            raise ParseError("Could not inherit file %s" % (file), fn, lineno)
+
+       bb.parse.ParseError: ParseError in configuration INHERITs: Could not inherit file classes/base.bbclass
 
-       ERROR: Unable to parse base: ParseError in configuration INHERITs: Could not inherit file classes/base.bbclass
 
     In the sample output,
     BitBake could not find the ``classes/base.bbclass`` file. You need
@@ -284,7 +263,10 @@ Following is the complete "Hello World" example.
       $ mkdir classes
 
     Move to the ``classes`` directory and then create the
-    ``base.bbclass`` file by inserting this single line: addtask build
+    ``base.bbclass`` file by inserting this single line::
+
+      addtask build
+
     The minimal task that BitBake runs is the ``do_build`` task. This is
     all the example needs in order to build the project. Of course, the
     ``base.bbclass`` can have much more depending on which build
@@ -328,10 +310,19 @@ Following is the complete "Hello World" example.
       BBFILES += "${LAYERDIR}/*.bb"
       BBFILE_COLLECTIONS += "mylayer"
       BBFILE_PATTERN_mylayer := "^${LAYERDIR_RE}/"
+      LAYERSERIES_CORENAMES = "hello_world_example"
+      LAYERSERIES_COMPAT_mylayer = "hello_world_example"
 
     For information on these variables, click on :term:`BBFILES`,
-    :term:`LAYERDIR`, :term:`BBFILE_COLLECTIONS` or :term:`BBFILE_PATTERN_mylayer <BBFILE_PATTERN>`
-    to go to the definitions in the glossary.
+    :term:`LAYERDIR`, :term:`BBFILE_COLLECTIONS`, :term:`BBFILE_PATTERN_mylayer <BBFILE_PATTERN>`
+    or :term:`LAYERSERIES_COMPAT` to go to the definitions in the glossary.
+
+    .. note::
+
+       We are setting both LAYERSERIES_CORENAMES and LAYERSERIES_COMPAT in this particular case, because we
+       are using bitbake without OpenEmbedded.
+       You should usually just use LAYERSERIES_COMPAT to specify the OE-Core versions for which your layer
+       is compatible, and add the meta-openembedded layer to your project.
 
     You need to create the recipe file next. Inside your layer at the
     top-level, use an editor and create a recipe file named
@@ -389,12 +380,14 @@ Following is the complete "Hello World" example.
     target::
 
        $ bitbake printhello
+       Loading cache: 100% |
+       Loaded 0 entries from dependency cache.
        Parsing recipes: 100% |##################################################################################|
-       Time: 00:00:00
        Parsing of 1 .bb files complete (0 cached, 1 parsed). 1 targets, 0 skipped, 0 masked, 0 errors.
        NOTE: Resolving any missing task queue dependencies
-       NOTE: Preparing RunQueue
-       NOTE: Executing RunQueue Tasks
+       Initialising tasks: 100% |###############################################################################|
+       NOTE: No setscene tasks
+       NOTE: Executing Tasks
        ********************
        *                  *
        *  Hello, World!   *

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

@@ -1496,6 +1496,23 @@ functionality of the task:
    directory listed is used as the current working directory for the
    task.
 
+- ``[file-checksums]``: Controls the file dependencies for a task. The
+  baseline file list is the set of files associated with
+  :term:`SRC_URI`. May be used to set additional dependencies on
+  files not associated with :term:`SRC_URI`.
+
+  The value set to the list is a file-boolean pair where the first
+  value is the file name and the second is whether or not it
+  physically exists on the filesystem. ::
+
+    do_configure[file-checksums] += "${MY_DIRPATH}/my-file.txt:True"
+
+  It is important to record any paths which the task looked at and
+  which didn't exist. This means that if these do exist at a later
+  time, the task can be rerun with the new additional files. The
+  "exists" True or False value after the path allows this to be
+  handled.
+
 -  ``[lockfiles]``: Specifies one or more lockfiles to lock while the
    task executes. Only one task may hold a lockfile, and any task that
    attempts to lock an already locked file will block until the lock is
@@ -1955,6 +1972,24 @@ looking at the source code of the ``bb`` module, which is in
 the commonly used functions ``bb.utils.contains()`` and
 ``bb.utils.mkdirhier()``, which come with docstrings.
 
+Extending Python Library Code
+-----------------------------
+
+If you wish to add your own Python library code (e.g. to provide
+functions/classes you can use from Python functions in the metadata)
+you can do so from any layer using the ``addpylib`` directive.
+This directive is typically added to your layer configuration (
+``conf/layer.conf``) although it will be handled in any ``.conf`` file.
+
+Usage is of the form::
+
+   addpylib <directory> <namespace>
+
+Where <directory> specifies the directory to add to the library path.
+The specified <namespace> is imported automatically, and if the imported
+module specifies an attribute named ``BBIMPORTS``, that list of
+sub-modules is iterated and imported too.
+
 Testing and Debugging BitBake Python code
 -----------------------------------------
 

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

@@ -99,10 +99,26 @@ overview of their function and contents.
       the path of the build. BitBake's output should not (and usually does
       not) depend on the directory in which it was built.
 
+   :term:`BB_CACHEDIR`
+      Specifies the code parser cache directory (distinct from :term:`CACHE`
+      and :term:`PERSISTENT_DIR` although they can be set to the same value
+      if desired). The default value is "${TOPDIR}/cache".
+
    :term:`BB_CHECK_SSL_CERTS`
       Specifies if SSL certificates should be checked when fetching. The default
       value is ``1`` and certificates are not checked if the value is set to ``0``.
 
+   :term:`BB_HASH_CODEPARSER_VALS`
+      Specifies values for variables to use when populating the codeparser cache.
+      This can be used selectively to set dummy values for variables to avoid
+      the codeparser cache growing on every parse. Variables that would typically
+      be included are those where the value is not significant for where the
+      codeparser cache is used (i.e. when calculating variable dependencies for
+      code fragments.) The value is space-separated without quoting values, for
+      example::
+
+         BB_HASH_CODEPARSER_VALS = "T=/ WORKDIR=/ DATE=1234 TIME=1234"
+
    :term:`BB_CONSOLELOG`
       Specifies the path to a log file into which BitBake's user interface
       writes output during the build.
@@ -343,6 +359,14 @@ overview of their function and contents.
 
       For example usage, see :term:`BB_GIT_SHALLOW`.
 
+   :term:`BB_GLOBAL_PYMODULES`
+      Specifies the list of Python modules to place in the global namespace.
+      It is intended that only the core layer should set this and it is meant
+      to be a very small list, typically just ``os`` and ``sys``.
+      :term:`BB_GLOBAL_PYMODULES` is expected to be set before the first
+      ``addpylib`` directive.
+      See also ":ref:`bitbake-user-manual/bitbake-user-manual-metadata:extending python library code`".
+
    :term:`BB_HASHCHECK_FUNCTION`
       Specifies the name of the function to call during the "setscene" part
       of the task's execution in order to validate the list of task hashes.
@@ -990,7 +1014,7 @@ overview of their function and contents.
       ``bblayers.conf`` configuration file.
 
       To exclude a recipe from a world build using this variable, set the
-      variable to "1" in the recipe.
+      variable to "1" in the recipe. Set it to "0" to add it back to world build.
 
       .. note::
 
@@ -1096,6 +1120,29 @@ overview of their function and contents.
       variable is not available outside of ``layer.conf`` and references
       are expanded immediately when parsing of the file completes.
 
+   :term:`LAYERSERIES_COMPAT`
+      Lists the versions of the OpenEmbedded-Core (OE-Core) for which
+      a layer is compatible. Using the :term:`LAYERSERIES_COMPAT` variable
+      allows the layer maintainer to indicate which combinations of the
+      layer and OE-Core can be expected to work. The variable gives the
+      system a way to detect when a layer has not been tested with new
+      releases of OE-Core (e.g. the layer is not maintained).
+
+      To specify the OE-Core versions for which a layer is compatible, use
+      this variable in your layer's ``conf/layer.conf`` configuration file.
+      For the list, use the Yocto Project release name (e.g. "kirkstone",
+      "mickledore"). To specify multiple OE-Core versions for the layer, use
+      a space-separated list::
+
+         LAYERSERIES_COMPAT_layer_root_name = "kirkstone mickledore"
+
+      .. note::
+
+         Setting :term:`LAYERSERIES_COMPAT` is required by the Yocto Project
+         Compatible version 2 standard.
+         The OpenEmbedded build system produces a warning if the variable
+         is not set for any given layer.
+
    :term:`LAYERVERSION`
       Optionally specifies the version of a layer as a single number. You
       can use this variable within

bitbake/doc/releases.rst

@@ -1,61 +1,57 @@
 .. SPDX-License-Identifier: CC-BY-2.5
 
-===========================
- Supported Release Manuals
-===========================
+=================================
+BitBake Supported Release Manuals
+=================================
 
-******************************
-Release Series 3.4 (honister)
-******************************
+*****************************
+Release Series 4.1 (langdale)
+*****************************
 
-- :yocto_docs:`3.4 BitBake User Manual </3.4/bitbake-user-manual/bitbake-user-manual.html>`
-- :yocto_docs:`3.4.1 BitBake User Manual </3.4.1/bitbake-user-manual/bitbake-user-manual.html>`
-- :yocto_docs:`3.4.2 BitBake User Manual </3.4.2/bitbake-user-manual/bitbake-user-manual.html>`
+- :yocto_docs:`BitBake 2.2 User Manual </bitbake/2.2/>`
 
-******************************
-Release Series 3.3 (hardknott)
-******************************
+*****************************
+Release Series 4.0 (kirstone)
+*****************************
 
-- :yocto_docs:`3.3 BitBake User Manual </3.3/bitbake-user-manual/bitbake-user-manual.html>`
-- :yocto_docs:`3.3.1 BitBake User Manual </3.3.1/bitbake-user-manual/bitbake-user-manual.html>`
-- :yocto_docs:`3.3.2 BitBake User Manual </3.3.2/bitbake-user-manual/bitbake-user-manual.html>`
-- :yocto_docs:`3.3.3 BitBake User Manual </3.3.3/bitbake-user-manual/bitbake-user-manual.html>`
-- :yocto_docs:`3.3.4 BitBake User Manual </3.3.4/bitbake-user-manual/bitbake-user-manual.html>`
-- :yocto_docs:`3.3.5 BitBake User Manual </3.3.5/bitbake-user-manual/bitbake-user-manual.html>`
+- :yocto_docs:`BitBake 2.0 User Manual </bitbake/2.0/>`
 
 ****************************
 Release Series 3.1 (dunfell)
 ****************************
 
-- :yocto_docs:`3.1 BitBake User Manual </3.1/bitbake-user-manual/bitbake-user-manual.html>`
-- :yocto_docs:`3.1.1 BitBake User Manual </3.1.1/bitbake-user-manual/bitbake-user-manual.html>`
-- :yocto_docs:`3.1.2 BitBake User Manual </3.1.2/bitbake-user-manual/bitbake-user-manual.html>`
-- :yocto_docs:`3.1.3 BitBake User Manual </3.1.3/bitbake-user-manual/bitbake-user-manual.html>`
-- :yocto_docs:`3.1.4 BitBake User Manual </3.1.4/bitbake-user-manual/bitbake-user-manual.html>`
-- :yocto_docs:`3.1.5 BitBake User Manual </3.1.5/bitbake-user-manual/bitbake-user-manual.html>`
-- :yocto_docs:`3.1.6 BitBake User Manual </3.1.6/bitbake-user-manual/bitbake-user-manual.html>`
-- :yocto_docs:`3.1.7 BitBake User Manual </3.1.7/bitbake-user-manual/bitbake-user-manual.html>`
-- :yocto_docs:`3.1.8 BitBake User Manual </3.1.8/bitbake-user-manual/bitbake-user-manual.html>`
-- :yocto_docs:`3.1.9 BitBake User Manual </3.1.9/bitbake-user-manual/bitbake-user-manual.html>`
-- :yocto_docs:`3.1.10 BitBake User Manual </3.1.10/bitbake-user-manual/bitbake-user-manual.html>`
-- :yocto_docs:`3.1.11 BitBake User Manual </3.1.11/bitbake-user-manual/bitbake-user-manual.html>`
-- :yocto_docs:`3.1.12 BitBake User Manual </3.1.12/bitbake-user-manual/bitbake-user-manual.html>`
-- :yocto_docs:`3.1.13 BitBake User Manual </3.1.13/bitbake-user-manual/bitbake-user-manual.html>`
-- :yocto_docs:`3.1.14 BitBake User Manual </3.1.14/bitbake-user-manual/bitbake-user-manual.html>`
+- :yocto_docs:`BitBake 1.46 User Manual </bitbake/1.46/>`
 
-==========================
- Outdated Release Manuals
-==========================
+================================
+BitBake Outdated Release Manuals
+================================
+
+******************************
+Release Series 3.4 (honister)
+******************************
+
+- :yocto_docs:`BitBake 1.52 User Manual </bitbake/1.52/>`
+
+******************************
+Release Series 3.3 (hardknott)
+******************************
+
+- :yocto_docs:`BitBake 1.50 User Manual </bitbake/1.50/>`
 
 *******************************
 Release Series 3.2 (gatesgarth)
 *******************************
 
-- :yocto_docs:`3.2 BitBake User Manual </3.2/bitbake-user-manual/bitbake-user-manual.html>`
-- :yocto_docs:`3.2.1 BitBake User Manual </3.2.1/bitbake-user-manual/bitbake-user-manual.html>`
-- :yocto_docs:`3.2.2 BitBake User Manual </3.2.2/bitbake-user-manual/bitbake-user-manual.html>`
-- :yocto_docs:`3.2.3 BitBake User Manual </3.2.3/bitbake-user-manual/bitbake-user-manual.html>`
-- :yocto_docs:`3.2.4 BitBake User Manual </3.2.4/bitbake-user-manual/bitbake-user-manual.html>`
+- :yocto_docs:`BitBake 1.48 User Manual </bitbake/1.48/>`
+
+*******************************************
+Release Series 3.1 (dunfell first versions)
+*******************************************
+
+- :yocto_docs:`3.1 BitBake User Manual </3.1/bitbake-user-manual/bitbake-user-manual.html>`
+- :yocto_docs:`3.1.1 BitBake User Manual </3.1.1/bitbake-user-manual/bitbake-user-manual.html>`
+- :yocto_docs:`3.1.2 BitBake User Manual </3.1.2/bitbake-user-manual/bitbake-user-manual.html>`
+- :yocto_docs:`3.1.3 BitBake User Manual </3.1.3/bitbake-user-manual/bitbake-user-manual.html>`
 
 *************************
 Release Series 3.0 (zeus)

bitbake/lib/bb/__init__.py

@@ -9,7 +9,7 @@
 # SPDX-License-Identifier: GPL-2.0-only
 #
 
-__version__ = "2.2.0"
+__version__ = "2.4.0"
 
 import sys
 if sys.version_info < (3, 8, 0):

bitbake/lib/bb/build.py

@@ -25,6 +25,7 @@ import bb
 import bb.msg
 import bb.process
 import bb.progress
+from io import StringIO
 from bb import data, event, utils
 
 bblogger = logging.getLogger('BitBake')
@@ -177,7 +178,9 @@ class StdoutNoopContextManager:
 
     @property
     def name(self):
-        return sys.stdout.name
+        if "name" in dir(sys.stdout):
+            return sys.stdout.name
+        return "<mem>"
 
 
 def exec_func(func, d, dirs = None):
@@ -296,9 +299,21 @@ def exec_func_python(func, d, runfile, cwd=None):
         lineno = int(d.getVarFlag(func, "lineno", False))
         bb.methodpool.insert_method(func, text, fn, lineno - 1)
 
+        if verboseStdoutLogging:
+            sys.stdout.flush()
+            sys.stderr.flush()
+            currout = sys.stdout
+            currerr = sys.stderr
+            sys.stderr = sys.stdout = execio = StringIO()
         comp = utils.better_compile(code, func, "exec_func_python() autogenerated")
         utils.better_exec(comp, {"d": d}, code, "exec_func_python() autogenerated")
     finally:
+        if verboseStdoutLogging:
+            execio.flush()
+            logger.plain("%s" % execio.getvalue())
+            sys.stdout = currout
+            sys.stderr = currerr
+            execio.close()
         # We want any stdout/stderr to be printed before any other log messages to make debugging
         # more accurate. In some cases we seem to lose stdout/stderr entirely in logging tests without this.
         sys.stdout.flush()
@@ -441,7 +456,11 @@ exit $ret
         if fakerootcmd:
             cmd = [fakerootcmd, runfile]
 
-    if verboseStdoutLogging:
+    # We only want to output to logger via LogTee if stdout is sys.__stdout__ (which will either
+    # be real stdout or subprocess PIPE or similar). In other cases we are being run "recursively",
+    # ie. inside another function, in which case stdout is already being captured so we don't
+    # want to Tee here as output would be printed twice, and out of order.
+    if verboseStdoutLogging and sys.stdout == sys.__stdout__:
         logfile = LogTee(logger, StdoutNoopContextManager())
     else:
         logfile = StdoutNoopContextManager()

bitbake/lib/bb/cache.py

@@ -216,7 +216,7 @@ class CoreRecipeInfo(RecipeInfoCommon):
 
         # Collect files we may need for possible world-dep
         # calculations
-        if not self.not_world:
+        if not bb.utils.to_boolean(self.not_world):
             cachedata.possible_world.append(fn)
         #else:
         #    logger.debug2("EXCLUDE FROM WORLD: %s", fn)

bitbake/lib/bb/cooker.py

@@ -229,24 +229,26 @@ class BBCooker:
             self.handlePRServ()
 
     def setupConfigWatcher(self):
-        if self.configwatcher:
-            self.configwatcher.close()
-            self.confignotifier = None
-            self.configwatcher = None
-        self.configwatcher = pyinotify.WatchManager()
-        self.configwatcher.bbseen = set()
-        self.configwatcher.bbwatchedfiles = set()
-        self.confignotifier = pyinotify.Notifier(self.configwatcher, self.config_notifications)
+        with bb.utils.lock_timeout(self.inotify_threadlock):
+            if self.configwatcher:
+                self.configwatcher.close()
+                self.confignotifier = None
+                self.configwatcher = None
+            self.configwatcher = pyinotify.WatchManager()
+            self.configwatcher.bbseen = set()
+            self.configwatcher.bbwatchedfiles = set()
+            self.confignotifier = pyinotify.Notifier(self.configwatcher, self.config_notifications)
 
     def setupParserWatcher(self):
-        if self.watcher:
-            self.watcher.close()
-            self.notifier = None
-            self.watcher = None
-        self.watcher = pyinotify.WatchManager()
-        self.watcher.bbseen = set()
-        self.watcher.bbwatchedfiles = set()
-        self.notifier = pyinotify.Notifier(self.watcher, self.notifications)
+        with bb.utils.lock_timeout(self.inotify_threadlock):
+            if self.watcher:
+                self.watcher.close()
+                self.notifier = None
+                self.watcher = None
+            self.watcher = pyinotify.WatchManager()
+            self.watcher.bbseen = set()
+            self.watcher.bbwatchedfiles = set()
+            self.notifier = pyinotify.Notifier(self.watcher, self.notifications)
 
     def process_inotify_updates(self):
         with bb.utils.lock_timeout(self.inotify_threadlock):
@@ -337,12 +339,21 @@ class BBCooker:
                         providerlog.error("Root privilege is required to modify max_user_watches.")
                     raise
 
+    def handle_inotify_updates(self):
+        # reload files for which we got notifications
+        for p in self.inotify_modified_files:
+            bb.parse.update_cache(p)
+            if p in bb.parse.BBHandler.cached_statements:
+                del bb.parse.BBHandler.cached_statements[p]
+        self.inotify_modified_files = []
+
     def sigterm_exception(self, signum, stackframe):
         if signum == signal.SIGTERM:
             bb.warn("Cooker received SIGTERM, shutting down...")
         elif signum == signal.SIGHUP:
             bb.warn("Cooker received SIGHUP, shutting down...")
         self.state = state.forceshutdown
+        bb.event._should_exit.set()
 
     def setFeatures(self, features):
         # we only accept a new feature set if we're in state initial, so we can reset without problems
@@ -365,6 +376,7 @@ class BBCooker:
             if mod not in self.orig_sysmodules:
                 del sys.modules[mod]
 
+        self.handle_inotify_updates()
         self.setupConfigWatcher()
 
         # Need to preserve BB_CONSOLELOG over resets
@@ -1518,6 +1530,7 @@ class BBCooker:
             msg = None
             interrupted = 0
             if halt or self.state == state.forceshutdown:
+                bb.event._should_exit.set()
                 rq.finish_runqueue(True)
                 msg = "Forced shutdown"
                 interrupted = 2
@@ -1610,12 +1623,7 @@ class BBCooker:
         if self.state == state.running:
             return
 
-        # reload files for which we got notifications
-        for p in self.inotify_modified_files:
-            bb.parse.update_cache(p)
-            if p in bb.parse.BBHandler.cached_statements:
-                del bb.parse.BBHandler.cached_statements[p]
-        self.inotify_modified_files = []
+        self.handle_inotify_updates()
 
         if not self.baseconfig_valid:
             logger.debug("Reloading base configuration data")
@@ -1756,6 +1764,7 @@ class BBCooker:
     def shutdown(self, force=False):
         if force:
             self.state = state.forceshutdown
+            bb.event._should_exit.set()
         else:
             self.state = state.shutdown
 
@@ -1768,6 +1777,7 @@ class BBCooker:
             self.parser.shutdown(clean=False)
             self.parser.final_cleanup()
         self.state = state.initial
+        bb.event._should_exit.clear()
 
     def reset(self):
         if hasattr(bb.parse, "siggen"):
@@ -2213,7 +2223,7 @@ class CookerParser(object):
 
             self.results = itertools.chain(self.results, self.parse_generator())
 
-    def shutdown(self, clean=True):
+    def shutdown(self, clean=True, eventmsg="Parsing halted due to errors"):
         if not self.toparse:
             return
         if self.haveshutdown:
@@ -2228,6 +2238,7 @@ class CookerParser(object):
 
             bb.event.fire(event, self.cfgdata)
         else:
+            bb.event.fire(bb.event.ParseError(eventmsg), self.cfgdata)
             bb.error("Parsing halted due to errors, see error messages above")
 
         # Cleanup the queue before call process.join(), otherwise there might be
@@ -2345,7 +2356,7 @@ class CookerParser(object):
         except bb.parse.ParseError as exc:
             self.error += 1
             logger.error(str(exc))
-            self.shutdown(clean=False)
+            self.shutdown(clean=False, eventmsg=str(exc))
             return False
         except bb.data_smart.ExpansionError as exc:
             self.error += 1

bitbake/lib/bb/cookerdata.py

@@ -160,12 +160,7 @@ def catch_parse_error(func):
     def wrapped(fn, *args):
         try:
             return func(fn, *args)
-        except IOError as exc:
-            import traceback
-            parselog.critical(traceback.format_exc())
-            parselog.critical("Unable to parse %s: %s" % (fn, exc))
-            raise bb.BBHandledException()
-        except bb.data_smart.ExpansionError as exc:
+        except Exception as exc:
             import traceback
 
             bbdir = os.path.dirname(__file__) + os.sep
@@ -177,9 +172,6 @@ def catch_parse_error(func):
                     break
             parselog.critical("Unable to parse %s" % fn, exc_info=(exc_class, exc, tb))
             raise bb.BBHandledException()
-        except bb.parse.ParseError as exc:
-            parselog.critical(str(exc))
-            raise bb.BBHandledException()
     return wrapped
 
 @catch_parse_error
@@ -302,14 +294,9 @@ class CookerDataBuilder(object):
                 bb.event.fire(bb.event.MultiConfigParsed(mcdata), self.data)
 
             self.data_hash = data_hash.hexdigest()
-        except (SyntaxError, bb.BBHandledException):
-            raise bb.BBHandledException()
         except bb.data_smart.ExpansionError as e:
             logger.error(str(e))
             raise bb.BBHandledException()
-        except Exception:
-            logger.exception("Error parsing configuration files")
-            raise bb.BBHandledException()
 
         bb.codeparser.update_module_dependencies(self.data)
 
@@ -473,7 +460,7 @@ class CookerDataBuilder(object):
                 msg += (" and bitbake did not find a conf/bblayers.conf file in"
                         " the expected location.\nMaybe you accidentally"
                         " invoked bitbake from the wrong directory?")
-            raise SystemExit(msg)
+            bb.fatal(msg)
 
         if not data.getVar("TOPDIR"):
             data.setVar("TOPDIR", os.path.abspath(os.getcwd()))

bitbake/lib/bb/data.py

@@ -114,8 +114,8 @@ def emit_var(var, o=sys.__stdout__, d = init(), all=False):
     if d.getVarFlag(var, 'python', False) and func:
         return False
 
-    export = d.getVarFlag(var, "export", False)
-    unexport = d.getVarFlag(var, "unexport", False)
+    export = bb.utils.to_boolean(d.getVarFlag(var, "export"))
+    unexport = bb.utils.to_boolean(d.getVarFlag(var, "unexport"))
     if not all and not export and not unexport and not func:
         return False
 
@@ -188,8 +188,8 @@ def emit_env(o=sys.__stdout__, d = init(), all=False):
 
 def exported_keys(d):
     return (key for key in d.keys() if not key.startswith('__') and
-                                      d.getVarFlag(key, 'export', False) and
-                                      not d.getVarFlag(key, 'unexport', False))
+                                      bb.utils.to_boolean(d.getVarFlag(key, 'export')) and
+                                      not bb.utils.to_boolean(d.getVarFlag(key, 'unexport')))
 
 def exported_vars(d):
     k = list(exported_keys(d))
@@ -375,7 +375,7 @@ def generate_dependencies(d, ignored_vars):
 
     mod_funcs = set(bb.codeparser.modulecode_deps.keys())
     keys = set(key for key in d if not key.startswith("__")) | mod_funcs
-    shelldeps = set(key for key in d.getVar("__exportlist", False) if d.getVarFlag(key, "export", False) and not d.getVarFlag(key, "unexport", False))
+    shelldeps = set(key for key in d.getVar("__exportlist", False) if bb.utils.to_boolean(d.getVarFlag(key, "export")) and not bb.utils.to_boolean(d.getVarFlag(key, "unexport")))
     varflagsexcl = d.getVar('BB_SIGNATURE_EXCLUDE_FLAGS')
 
     codeparserd = d.createCopy()

bitbake/lib/bb/event.py

@@ -69,6 +69,7 @@ _eventfilter = None
 _uiready = False
 _thread_lock = threading.Lock()
 _heartbeat_enabled = False
+_should_exit = threading.Event()
 
 def enable_threadlock():
     # Always needed now
@@ -86,6 +87,16 @@ def disable_heartbeat():
     global _heartbeat_enabled
     _heartbeat_enabled = False
 
+#
+# In long running code, this function should be called periodically
+# to check if we should exit due to an interuption (.e.g Ctrl+C from the UI)
+#
+def check_for_interrupts(d):
+    global _should_exit
+    if _should_exit.is_set():
+        bb.warn("Exiting due to interrupt.")
+        raise bb.BBHandledException()
+
 def execute_handler(name, handler, event, d):
     event.data = d
     try:
@@ -845,3 +856,11 @@ class FindSigInfoResult(Event):
     def __init__(self, result):
         Event.__init__(self)
         self.result = result
+
+class ParseError(Event):
+    """
+    Event to indicate parse failed
+    """
+    def __init__(self, msg):
+        super().__init__()
+        self._msg = msg

bitbake/lib/bb/fetch2/__init__.py

@@ -560,7 +560,6 @@ def verify_checksum(ud, d, precomputed={}, localpath=None, fatal_nochecksum=True
     file against those in the recipe each time, rather than only after
     downloading. See https://bugzilla.yoctoproject.org/show_bug.cgi?id=5571.
     """
-
     if ud.ignore_checksums or not ud.method.supports_checksum(ud):
         return {}
 
@@ -605,11 +604,7 @@ def verify_checksum(ud, d, precomputed={}, localpath=None, fatal_nochecksum=True
 
         # If strict checking enabled and neither sum defined, raise error
         if strict == "1":
-            messages.append("No checksum specified for '%s', please add at " \
-                            "least one to the recipe:" % ud.localpath)
-            messages.extend(checksum_lines)
-            logger.error("\n".join(messages))
-            raise NoChecksumError("Missing SRC_URI checksum", ud.url)
+            raise NoChecksumError("\n".join(checksum_lines))
 
         bb.event.fire(MissingChecksumEvent(ud.url, **checksum_event), d)
 
@@ -749,10 +744,13 @@ def subprocess_setup():
     # SIGPIPE errors are known issues with gzip/bash
     signal.signal(signal.SIGPIPE, signal.SIG_DFL)
 
-def get_autorev(d):
-    #  only not cache src rev in autorev case
+def mark_recipe_nocache(d):
     if d.getVar('BB_SRCREV_POLICY') != "cache":
         d.setVar('BB_DONT_CACHE', '1')
+
+def get_autorev(d):
+    mark_recipe_nocache(d)
+    d.setVar("__BBAUTOREV_SEEN", True)
     return "AUTOINC"
 
 def get_srcrev(d, method_name='sortable_revision'):
@@ -769,7 +767,7 @@ def get_srcrev(d, method_name='sortable_revision'):
     that fetcher provides a method with the given name and the same signature as sortable_revision.
     """
 
-    d.setVar("__BBSEENSRCREV", "1")
+    d.setVar("__BBSRCREV_SEEN", "1")
     recursion = d.getVar("__BBINSRCREV")
     if recursion:
         raise FetchError("There are recursive references in fetcher variables, likely through SRC_URI")
@@ -851,10 +849,13 @@ FETCH_EXPORT_VARS = ['HOME', 'PATH',
                      'DBUS_SESSION_BUS_ADDRESS',
                      'P4CONFIG',
                      'SSL_CERT_FILE',
+                     'NODE_EXTRA_CA_CERTS',
                      'AWS_PROFILE',
                      'AWS_ACCESS_KEY_ID',
                      'AWS_SECRET_ACCESS_KEY',
-                     'AWS_DEFAULT_REGION']
+                     'AWS_DEFAULT_REGION',
+                     'GIT_CACHE_PATH',
+                     'SSL_CERT_DIR']
 
 def get_fetcher_environment(d):
     newenv = {}
@@ -1216,6 +1217,7 @@ def srcrev_internal_helper(ud, d, name):
     if srcrev == "INVALID" or not srcrev:
         raise FetchError("Please set a valid SRCREV for url %s (possible key names are %s, or use a ;rev=X URL parameter)" % (str(attempts), ud.url), ud.url)
     if srcrev == "AUTOINC":
+        d.setVar("__BBAUTOREV_ACTED_UPON", True)
         srcrev = ud.method.latest_revision(ud, d, name)
 
     return srcrev
@@ -1288,18 +1290,13 @@ class FetchData(object):
 
             if checksum_name in self.parm:
                 checksum_expected = self.parm[checksum_name]
-            elif self.type not in ["http", "https", "ftp", "ftps", "sftp", "s3", "az"]:
+            elif self.type not in ["http", "https", "ftp", "ftps", "sftp", "s3", "az", "crate"]:
                 checksum_expected = None
             else:
                 checksum_expected = d.getVarFlag("SRC_URI", checksum_name)
 
             setattr(self, "%s_expected" % checksum_id, checksum_expected)
 
-        for checksum_id in CHECKSUM_LIST:
-            configure_checksum(checksum_id)
-
-        self.ignore_checksums = False
-
         self.names = self.parm.get("name",'default').split(',')
 
         self.method = None
@@ -1321,6 +1318,11 @@ class FetchData(object):
         if hasattr(self.method, "urldata_init"):
             self.method.urldata_init(self, d)
 
+        for checksum_id in CHECKSUM_LIST:
+            configure_checksum(checksum_id)
+
+        self.ignore_checksums = False
+
         if "localpath" in self.parm:
             # if user sets localpath for file, use it instead.
             self.localpath = self.parm["localpath"]
@@ -1721,6 +1723,7 @@ class Fetch(object):
         network = self.d.getVar("BB_NO_NETWORK")
         premirroronly = bb.utils.to_boolean(self.d.getVar("BB_FETCH_PREMIRRORONLY"))
 
+        checksum_missing_messages = []
         for u in urls:
             ud = self.ud[u]
             ud.setup_localpath(self.d)
@@ -1732,7 +1735,6 @@ class Fetch(object):
 
             try:
                 self.d.setVar("BB_NO_NETWORK", network)
-
                 if m.verify_donestamp(ud, self.d) and not m.need_update(ud, self.d):
                     done = True
                 elif m.try_premirror(ud, self.d):
@@ -1804,13 +1806,20 @@ class Fetch(object):
                     raise ChecksumError("Stale Error Detected")
 
             except BBFetchException as e:
-                if isinstance(e, ChecksumError):
+                if isinstance(e, NoChecksumError):
+                    (message, _) = e.args
+                    checksum_missing_messages.append(message)
+                    continue
+                elif isinstance(e, ChecksumError):
                     logger.error("Checksum failure fetching %s" % u)
                 raise
 
             finally:
                 if ud.lockfile:
                     bb.utils.unlockfile(lf)
+        if checksum_missing_messages:
+            logger.error("Missing SRC_URI checksum, please add those to the recipe: \n%s", "\n".join(checksum_missing_messages))
+            raise BBFetchException("There was some missing checksums in the recipe")
 
     def checkstatus(self, urls=None):
         """

bitbake/lib/bb/fetch2/crate.py

@@ -33,7 +33,7 @@ class Crate(Wget):
         return ud.type in ['crate']
 
     def recommends_checksum(self, urldata):
-        return False
+        return True
 
     def urldata_init(self, ud, d):
         """
@@ -56,8 +56,10 @@ class Crate(Wget):
         if len(parts) < 5:
             raise bb.fetch2.ParameterError("Invalid URL: Must be crate://HOST/NAME/VERSION", ud.url)
 
-        # last field is version
-        version = parts[len(parts) - 1]
+        # version is expected to be the last token
+        # but ignore possible url parameters which will be used
+        # by the top fetcher class
+        version, _, _ = parts[len(parts) -1].partition(";")
         # second to last field is name
         name = parts[len(parts) - 2]
         # host (this is to allow custom crate registries to be specified
@@ -69,7 +71,8 @@ class Crate(Wget):
 
         ud.url = "https://%s/%s/%s/download" % (host, name, version)
         ud.parm['downloadfilename'] = "%s-%s.crate" % (name, version)
-        ud.parm['name'] = name
+        if 'name' not in ud.parm:
+            ud.parm['name'] = '%s-%s' % (name, version)
 
         logger.debug2("Fetching %s to %s" % (ud.url, ud.parm['downloadfilename']))
 

bitbake/lib/bb/fetch2/git.py

@@ -367,9 +367,13 @@ class Git(FetchMethod):
 
         # If the repo still doesn't exist, fallback to cloning it
         if not os.path.exists(ud.clonedir):
-            # We do this since git will use a "-l" option automatically for local urls where possible
+            # We do this since git will use a "-l" option automatically for local urls where possible,
+            # but it doesn't work when git/objects is a symlink, only works when it is a directory.
             if repourl.startswith("file://"):
-                repourl = repourl[7:]
+                repourl_path = repourl[7:]
+                objects = os.path.join(repourl_path, 'objects')
+                if os.path.isdir(objects) and not os.path.islink(objects):
+                    repourl = repourl_path
             clone_cmd = "LANG=C %s clone --bare --mirror %s %s --progress" % (ud.basecmd, shlex.quote(repourl), ud.clonedir)
             if ud.proto.lower() != 'file':
                 bb.fetch2.check_network_access(d, clone_cmd, ud.url)
@@ -417,8 +421,7 @@ class Git(FetchMethod):
             # It would be nice to just do this inline here by running 'git-lfs fetch'
             # on the bare clonedir, but that operation requires a working copy on some
             # releases of Git LFS.
-            tmpdir = tempfile.mkdtemp(dir=d.getVar('DL_DIR'))
-            try:
+            with tempfile.TemporaryDirectory(dir=d.getVar('DL_DIR')) as tmpdir:
                 # Do the checkout. This implicitly involves a Git LFS fetch.
                 Git.unpack(self, ud, tmpdir, d)
 
@@ -436,8 +439,6 @@ class Git(FetchMethod):
                 # downloaded.
                 if os.path.exists(os.path.join(tmpdir, "git", ".git", "lfs")):
                     runfetchcmd("tar -cf - lfs | tar -xf - -C %s" % ud.clonedir, d, workdir="%s/git/.git" % tmpdir)
-            finally:
-                bb.utils.remove(tmpdir, recurse=True)
 
     def build_mirror_data(self, ud, d):
 
@@ -660,11 +661,6 @@ class Git(FetchMethod):
         Check if the repository has 'lfs' (large file) content
         """
 
-        if not ud.nobranch:
-            branchname = ud.branches[ud.names[0]]
-        else:
-            branchname = "master"
-
         # The bare clonedir doesn't use the remote names; it has the branch immediately.
         if wd == ud.clonedir:
             refname = ud.branches[ud.names[0]]
@@ -741,11 +737,11 @@ class Git(FetchMethod):
         """
         Compute the HEAD revision for the url
         """
-        if not d.getVar("__BBSEENSRCREV"):
+        if not d.getVar("__BBSRCREV_SEEN"):
             raise bb.fetch2.FetchError("Recipe uses a floating tag/branch '%s' for repo '%s' without a fixed SRCREV yet doesn't call bb.fetch2.get_srcrev() (use SRCPV in PV for OE)." % (ud.unresolvedrev[name], ud.host+ud.path))
 
         # Ensure we mark as not cached
-        bb.fetch2.get_autorev(d)
+        bb.fetch2.mark_recipe_nocache(d)
 
         output = self._lsremote(ud, d, "")
         # Tags of the form ^{} may not work, need to fallback to other form

bitbake/lib/bb/fetch2/gitsm.py

@@ -90,7 +90,7 @@ class GitSM(Git):
                 # Convert relative to absolute uri based on parent uri
                 if  uris[m].startswith('..') or uris[m].startswith('./'):
                     newud = copy.copy(ud)
-                    newud.path = os.path.realpath(os.path.join(newud.path, uris[m]))
+                    newud.path = os.path.normpath(os.path.join(newud.path, uris[m]))
                     uris[m] = Git._get_repo_url(self, newud)
 
         for module in submodules:

bitbake/lib/bb/fetch2/local.py

@@ -72,7 +72,7 @@ class Local(FetchMethod):
             filespath = d.getVar('FILESPATH')
             if filespath:
                 locations = filespath.split(":")
-            msg = "Unable to find file " + urldata.url + " anywhere. The paths that were searched were:\n    " + "\n    ".join(locations)
+            msg = "Unable to find file " + urldata.url + " anywhere to download to " + urldata.localpath + ". The paths that were searched were:\n    " + "\n    ".join(locations)
             raise FetchError(msg)
 
         return True

bitbake/lib/bb/fetch2/npmsw.py

@@ -129,10 +129,28 @@ class NpmShrinkWrap(FetchMethod):
 
                 localpath = os.path.join(d.getVar("DL_DIR"), localfile)
 
+            # Handle local tarball and link sources
+            elif version.startswith("file"):
+                localpath = version[5:]
+                if not version.endswith(".tgz"):
+                    unpack = False
+
             # Handle git sources
-            elif version.startswith("git"):
+            elif version.startswith(("git", "bitbucket","gist")) or (
+                not version.endswith((".tgz", ".tar", ".tar.gz"))
+                and not version.startswith((".", "@", "/"))
+                and "/" in version
+            ):
                 if version.startswith("github:"):
                     version = "git+https://github.com/" + version[len("github:"):]
+                elif version.startswith("gist:"):
+                    version = "git+https://gist.github.com/" + version[len("gist:"):]
+                elif version.startswith("bitbucket:"):
+                    version = "git+https://bitbucket.org/" + version[len("bitbucket:"):]
+                elif version.startswith("gitlab:"):
+                    version = "git+https://gitlab.com/" + version[len("gitlab:"):]
+                elif not version.startswith(("git+","git:")):
+                    version = "git+https://github.com/" + version
                 regex = re.compile(r"""
                     ^
                     git\+
@@ -158,12 +176,6 @@ class NpmShrinkWrap(FetchMethod):
 
                 url = str(uri)
 
-            # Handle local tarball and link sources
-            elif version.startswith("file"):
-                localpath = version[5:]
-                if not version.endswith(".tgz"):
-                    unpack = False
-
             else:
                 raise ParameterError("Unsupported dependency: %s" % name, ud.url)
 
@@ -193,7 +205,9 @@ class NpmShrinkWrap(FetchMethod):
         # This fetcher resolves multiple URIs from a shrinkwrap file and then
         # forwards it to a proxy fetcher. The management of the donestamp file,
         # the lockfile and the checksums are forwarded to the proxy fetcher.
-        ud.proxy = Fetch([dep["url"] for dep in ud.deps if dep["url"]], data)
+        shrinkwrap_urls = [dep["url"] for dep in ud.deps if dep["url"]]
+        if shrinkwrap_urls:
+            ud.proxy = Fetch(shrinkwrap_urls, data)
         ud.needdonestamp = False
 
     @staticmethod

bitbake/lib/bb/fetch2/sftp.py

@@ -103,7 +103,7 @@ class SFTP(FetchMethod):
         if path[:3] == '/~/':
             path = path[3:]
 
-        remote = '%s%s:%s' % (user, urlo.hostname, path)
+        remote = '"%s%s:%s"' % (user, urlo.hostname, path)
 
         cmd = '%s %s %s %s' % (basecmd, port, remote, lpath)
 

bitbake/lib/bb/fetch2/wget.py

@@ -26,7 +26,6 @@ from   bb.fetch2 import FetchMethod
 from   bb.fetch2 import FetchError
 from   bb.fetch2 import logger
 from   bb.fetch2 import runfetchcmd
-from   bb.utils import export_proxies
 from   bs4 import BeautifulSoup
 from   bs4 import SoupStrainer
 
@@ -361,23 +360,16 @@ class Wget(FetchMethod):
 
                 try:
                     import netrc
-                    n = netrc.netrc()
-                    login, unused, password = n.authenticators(urllib.parse.urlparse(uri).hostname)
-                    add_basic_auth("%s:%s" % (login, password), r)
-                except (TypeError, ImportError, IOError, netrc.NetrcParseError):
+                    auth_data = netrc.netrc().authenticators(urllib.parse.urlparse(uri).hostname)
+                    if auth_data:
+                        login, _, password = auth_data
+                        add_basic_auth("%s:%s" % (login, password), r)
+                except (FileNotFoundError, netrc.NetrcParseError):
                     pass
 
                 with opener.open(r, timeout=30) as response:
                     pass
-            except urllib.error.URLError as e:
-                if try_again:
-                    logger.debug2("checkstatus: trying again")
-                    return self.checkstatus(fetch, ud, d, False)
-                else:
-                    # debug for now to avoid spamming the logs in e.g. remote sstate searches
-                    logger.debug2("checkstatus() urlopen failed: %s" % e)
-                    return False
-            except ConnectionResetError as e:
+            except (urllib.error.URLError, ConnectionResetError, TimeoutError) as e:
                 if try_again:
                     logger.debug2("checkstatus: trying again")
                     return self.checkstatus(fetch, ud, d, False)

bitbake/lib/bb/monitordisk.py

@@ -234,9 +234,10 @@ class diskMonitor:
                 freeInode = st.f_favail
 
                 if minInode and freeInode < minInode:
-                    # Some filesystems use dynamic inodes so can't run out
-                    # (e.g. btrfs). This is reported by the inode count being 0.
-                    if st.f_files == 0:
+                    # Some filesystems use dynamic inodes so can't run out.
+                    # This is reported by the inode count being 0 (btrfs) or the free
+                    # inode count being -1 (cephfs).
+                    if st.f_files == 0 or st.f_favail == -1:
                         self.devDict[k][2] = None
                         continue
                     # Always show warning, the self.checked would always be False if the action is WARN

bitbake/lib/bb/parse/ast.py

@@ -400,6 +400,9 @@ def finalize(fn, d, variant = None):
 
         d.setVar('BBINCLUDED', bb.parse.get_file_depends(d))
 
+        if d.getVar('__BBAUTOREV_SEEN') and d.getVar('__BBSRCREV_SEEN') and not d.getVar("__BBAUTOREV_ACTED_UPON"):
+            bb.fatal("AUTOREV/SRCPV set too late for the fetcher to work properly, please set the variables earlier in parsing. Erroring instead of later obtuse build failures.")
+
         bb.event.fire(bb.event.RecipeParsed(fn), d)
     finally:
         bb.event.set_handlers(saved_handlers)

bitbake/lib/bb/parse/parse_py/ConfHandler.py

@@ -21,7 +21,7 @@ __config_regexp__  = re.compile( r"""
     ^
     (?P<exp>export\s+)?
     (?P<var>[a-zA-Z0-9\-_+.${}/~:]+?)
-    (\[(?P<flag>[a-zA-Z0-9\-_+.]+)\])?
+    (\[(?P<flag>[a-zA-Z0-9\-_+.][a-zA-Z0-9\-_+.@]*)\])?
 
     \s* (
         (?P<colon>:=) |
@@ -45,7 +45,7 @@ __include_regexp__ = re.compile( r"include\s+(.+)" )
 __require_regexp__ = re.compile( r"require\s+(.+)" )
 __export_regexp__ = re.compile( r"export\s+([a-zA-Z0-9\-_+.${}/~]+)$" )
 __unset_regexp__ = re.compile( r"unset\s+([a-zA-Z0-9\-_+.${}/~]+)$" )
-__unset_flag_regexp__ = re.compile( r"unset\s+([a-zA-Z0-9\-_+.${}/~]+)\[([a-zA-Z0-9\-_+.]+)\]$" )
+__unset_flag_regexp__ = re.compile( r"unset\s+([a-zA-Z0-9\-_+.${}/~]+)\[([a-zA-Z0-9\-_+.][a-zA-Z0-9\-_+.@]+)\]$" )
 __addpylib_regexp__      = re.compile(r"addpylib\s+(.+)\s+(.+)" )
 
 def init(data):
@@ -103,7 +103,7 @@ def include_single_file(parentfn, fn, lineno, data, error_out):
 # We have an issue where a UI might want to enforce particular settings such as
 # an empty DISTRO variable. If configuration files do something like assigning
 # a weak default, it turns out to be very difficult to filter out these changes,
-# particularly when the weak default might appear half way though parsing a chain 
+# particularly when the weak default might appear half way though parsing a chain
 # of configuration files. We therefore let the UIs hook into configuration file
 # parsing. This turns out to be a hard problem to solve any other way.
 confFilters = []

bitbake/lib/bb/runqueue.py

@@ -198,15 +198,20 @@ class RunQueueScheduler(object):
                 curr_cpu_pressure = cpu_pressure_fds.readline().split()[4].split("=")[1]
                 curr_io_pressure = io_pressure_fds.readline().split()[4].split("=")[1]
                 curr_memory_pressure = memory_pressure_fds.readline().split()[4].split("=")[1]
-                exceeds_cpu_pressure =  self.rq.max_cpu_pressure and (float(curr_cpu_pressure) - float(self.prev_cpu_pressure)) > self.rq.max_cpu_pressure
-                exceeds_io_pressure =  self.rq.max_io_pressure and (float(curr_io_pressure) - float(self.prev_io_pressure)) > self.rq.max_io_pressure
-                exceeds_memory_pressure = self.rq.max_memory_pressure and (float(curr_memory_pressure) - float(self.prev_memory_pressure)) > self.rq.max_memory_pressure
                 now = time.time()
-                if now - self.prev_pressure_time > 1.0:
+                tdiff = now - self.prev_pressure_time
+                if tdiff > 1.0:
+                    exceeds_cpu_pressure =  self.rq.max_cpu_pressure and (float(curr_cpu_pressure) - float(self.prev_cpu_pressure)) / tdiff > self.rq.max_cpu_pressure
+                    exceeds_io_pressure =  self.rq.max_io_pressure and (float(curr_io_pressure) - float(self.prev_io_pressure)) / tdiff > self.rq.max_io_pressure
+                    exceeds_memory_pressure = self.rq.max_memory_pressure and (float(curr_memory_pressure) - float(self.prev_memory_pressure)) / tdiff > self.rq.max_memory_pressure
                     self.prev_cpu_pressure = curr_cpu_pressure
                     self.prev_io_pressure = curr_io_pressure
                     self.prev_memory_pressure = curr_memory_pressure
                     self.prev_pressure_time = now
+                else:
+                    exceeds_cpu_pressure =  self.rq.max_cpu_pressure and (float(curr_cpu_pressure) - float(self.prev_cpu_pressure)) > self.rq.max_cpu_pressure
+                    exceeds_io_pressure =  self.rq.max_io_pressure and (float(curr_io_pressure) - float(self.prev_io_pressure)) > self.rq.max_io_pressure
+                    exceeds_memory_pressure = self.rq.max_memory_pressure and (float(curr_memory_pressure) - float(self.prev_memory_pressure)) > self.rq.max_memory_pressure
             return (exceeds_cpu_pressure or exceeds_io_pressure or exceeds_memory_pressure)
         return False
 
@@ -655,6 +660,7 @@ class RunQueueData:
 
         self.init_progress_reporter.start()
         self.init_progress_reporter.next_stage()
+        bb.event.check_for_interrupts(self.cooker.data)
 
         # Step A - Work out a list of tasks to run
         #
@@ -803,6 +809,7 @@ class RunQueueData:
         #self.dump_data()
 
         self.init_progress_reporter.next_stage()
+        bb.event.check_for_interrupts(self.cooker.data)
 
         # Resolve recursive 'recrdeptask' dependencies (Part B)
         #
@@ -899,6 +906,7 @@ class RunQueueData:
             self.runtaskentries[tid].depends.difference_update(recursivetasksselfref)
 
         self.init_progress_reporter.next_stage()
+        bb.event.check_for_interrupts(self.cooker.data)
 
         #self.dump_data()
 
@@ -980,6 +988,7 @@ class RunQueueData:
                 mark_active(tid, 1)
 
         self.init_progress_reporter.next_stage()
+        bb.event.check_for_interrupts(self.cooker.data)
 
         # Step C - Prune all inactive tasks
         #
@@ -1019,6 +1028,7 @@ class RunQueueData:
                 bb.msg.fatal("RunQueue", "Could not find any tasks with the tasknames %s to run within the recipes of the taskgraphs of the targets %s" % (str(self.cooker.configuration.runall), str(self.targets)))
 
         self.init_progress_reporter.next_stage()
+        bb.event.check_for_interrupts(self.cooker.data)
 
         # Handle runonly
         if self.cooker.configuration.runonly:
@@ -1059,6 +1069,7 @@ class RunQueueData:
         logger.verbose("Assign Weightings")
 
         self.init_progress_reporter.next_stage()
+        bb.event.check_for_interrupts(self.cooker.data)
 
         # Generate a list of reverse dependencies to ease future calculations
         for tid in self.runtaskentries:
@@ -1066,6 +1077,7 @@ class RunQueueData:
                 self.runtaskentries[dep].revdeps.add(tid)
 
         self.init_progress_reporter.next_stage()
+        bb.event.check_for_interrupts(self.cooker.data)
 
         # Identify tasks at the end of dependency chains
         # Error on circular dependency loops (length two)
@@ -1082,12 +1094,14 @@ class RunQueueData:
         logger.verbose("Compute totals (have %s endpoint(s))", len(endpoints))
 
         self.init_progress_reporter.next_stage()
+        bb.event.check_for_interrupts(self.cooker.data)
 
         # Calculate task weights
         # Check of higher length circular dependencies
         self.runq_weight = self.calculate_task_weights(endpoints)
 
         self.init_progress_reporter.next_stage()
+        bb.event.check_for_interrupts(self.cooker.data)
 
         # Sanity Check - Check for multiple tasks building the same provider
         for mc in self.dataCaches:
@@ -1188,6 +1202,7 @@ class RunQueueData:
 
         self.init_progress_reporter.next_stage()
         self.init_progress_reporter.next_stage()
+        bb.event.check_for_interrupts(self.cooker.data)
 
         # Iterate over the task list looking for tasks with a 'setscene' function
         self.runq_setscene_tids = set()
@@ -1200,6 +1215,7 @@ class RunQueueData:
                 self.runq_setscene_tids.add(tid)
 
         self.init_progress_reporter.next_stage()
+        bb.event.check_for_interrupts(self.cooker.data)
 
         # Invalidate task if force mode active
         if self.cooker.configuration.force:
@@ -1216,6 +1232,7 @@ class RunQueueData:
                     invalidate_task(fn + ":" + st, True)
 
         self.init_progress_reporter.next_stage()
+        bb.event.check_for_interrupts(self.cooker.data)
 
         # Create and print to the logs a virtual/xxxx -> PN (fn) table
         for mc in taskData:
@@ -1228,6 +1245,7 @@ class RunQueueData:
                 bb.parse.siggen.tasks_resolved(virtmap, virtpnmap, self.dataCaches[mc])
 
         self.init_progress_reporter.next_stage()
+        bb.event.check_for_interrupts(self.cooker.data)
 
         bb.parse.siggen.set_setscene_tasks(self.runq_setscene_tids)
 
@@ -1240,6 +1258,7 @@ class RunQueueData:
                     dealtwith.add(tid)
                     todeal.remove(tid)
                     self.prepare_task_hash(tid)
+                bb.event.check_for_interrupts(self.cooker.data)
 
         bb.parse.siggen.writeout_file_checksum_cache()
 
@@ -1483,6 +1502,7 @@ class RunQueue:
         """
 
         retval = True
+        bb.event.check_for_interrupts(self.cooker.data)
 
         if self.state is runQueuePrepare:
             # NOTE: if you add, remove or significantly refactor the stages of this
@@ -1941,8 +1961,7 @@ class RunQueueExecute:
                 try:
                     module = __import__(modname, fromlist=(name,))
                 except ImportError as exc:
-                    logger.critical("Unable to import scheduler '%s' from '%s': %s" % (name, modname, exc))
-                    raise SystemExit(1)
+                    bb.fatal("Unable to import scheduler '%s' from '%s': %s" % (name, modname, exc))
                 else:
                     schedulers.add(getattr(module, name))
         return schedulers
@@ -1972,11 +1991,19 @@ class RunQueueExecute:
                 self.setbuildable(revdep)
                 logger.debug("Marking task %s as buildable", revdep)
 
-        for t in self.sq_deferred.copy():
+        found = None
+        for t in sorted(self.sq_deferred.copy()):
             if self.sq_deferred[t] == task:
-                logger.debug2("Deferred task %s now buildable" % t)
-                del self.sq_deferred[t]
-                update_scenequeue_data([t], self.sqdata, self.rqdata, self.rq, self.cooker, self.stampcache, self, summary=False)
+                # Allow the next deferred task to run. Any other deferred tasks should be deferred after that task.
+                # We shouldn't allow all to run at once as it is prone to races.
+                if not found:
+                    bb.note("Deferred task %s now buildable" % t)
+                    del self.sq_deferred[t]
+                    update_scenequeue_data([t], self.sqdata, self.rqdata, self.rq, self.cooker, self.stampcache, self, summary=False)
+                    found = t
+                else:
+                    bb.note("Deferring %s after %s" % (t, found))
+                    self.sq_deferred[t] = found
 
     def task_complete(self, task):
         self.stats.taskCompleted()

bitbake/lib/bb/server/process.py

@@ -405,7 +405,11 @@ class ProcessServer():
             nextsleep = 0.1
             fds = []
 
-            self.cooker.process_inotify_updates()
+            try:
+                self.cooker.process_inotify_updates()
+            except Exception as exc:
+                serverlog("Exception %s in inofify updates broke the idle_thread, exiting" % traceback.format_exc())
+                self.quit = True
 
             with bb.utils.lock_timeout(self._idlefuncsLock):
                 items = list(self._idlefuns.items())
@@ -473,6 +477,10 @@ class ProcessServer():
         if not self.idle:
             self.idle = threading.Thread(target=self.idle_thread)
             self.idle.start()
+        elif self.idle and not self.idle.is_alive():
+            serverlog("Idle thread terminated, main thread exiting too")
+            bb.error("Idle thread terminated, main thread exiting too")
+            self.quit = True
 
         if nextsleep is not None:
             if self.xmlrpc:

bitbake/lib/bb/server/xmlrpcserver.py

@@ -118,7 +118,7 @@ class BitBakeXMLRPCServerCommands():
         """
         Run a cooker command on the server
         """
-        return self.server.cooker.command.runCommand(command, self.server, self.server.readonly)
+        return self.server.cooker.command.runCommand(command, self.server.parent, self.server.readonly)
 
     def getEventHandle(self):
         return self.event_handle

bitbake/lib/bb/siggen.py

@@ -349,19 +349,19 @@ class SignatureGeneratorBasic(SignatureGenerator):
 
         data = self.basehash[tid]
         for dep in self.runtaskdeps[tid]:
-            data = data + self.get_unihash(dep)
+            data += self.get_unihash(dep)
 
         for (f, cs) in self.file_checksum_values[tid]:
             if cs:
                 if "/./" in f:
-                    data = data + "./" + f.split("/./")[1]
-                data = data + cs
+                    data += "./" + f.split("/./")[1]
+                data += cs
 
         if tid in self.taints:
             if self.taints[tid].startswith("nostamp:"):
-                data = data + self.taints[tid][8:]
+                data += self.taints[tid][8:]
             else:
-                data = data + self.taints[tid]
+                data += self.taints[tid]
 
         h = hashlib.sha256(data.encode("utf-8")).hexdigest()
         self.taskhash[tid] = h
@@ -598,7 +598,7 @@ class SignatureGeneratorUniHashMixIn(object):
                 # A unique hash equal to the taskhash is not very interesting,
                 # so it is reported it at debug level 2. If they differ, that
                 # is much more interesting, so it is reported at debug level 1
-                hashequiv_logger.debug((1, 2)[unihash == taskhash], 'Found unihash %s in place of %s for %s from %s' % (unihash, taskhash, tid, self.server))
+                hashequiv_logger.bbdebug((1, 2)[unihash == taskhash], 'Found unihash %s in place of %s for %s from %s' % (unihash, taskhash, tid, self.server))
             else:
                 hashequiv_logger.debug2('No reported unihash for %s:%s from %s' % (tid, taskhash, self.server))
         except ConnectionError as e:

bitbake/lib/bb/tests/fetch.py

@@ -785,7 +785,7 @@ class FetcherLocalTest(FetcherTest):
 
         # Fetch and check revision
         self.d.setVar("SRCREV", "AUTOINC")
-        self.d.setVar("__BBSEENSRCREV", "1")
+        self.d.setVar("__BBSRCREV_SEEN", "1")
         url = "git://" + self.gitdir + ";branch=master;protocol=file;" + suffix
         fetcher = bb.fetch.Fetch([url], self.d)
         fetcher.download()
@@ -1654,7 +1654,7 @@ class GitShallowTest(FetcherTest):
         self.d.setVar('BB_GIT_SHALLOW', '1')
         self.d.setVar('BB_GENERATE_MIRROR_TARBALLS', '0')
         self.d.setVar('BB_GENERATE_SHALLOW_TARBALLS', '1')
-        self.d.setVar("__BBSEENSRCREV", "1")
+        self.d.setVar("__BBSRCREV_SEEN", "1")
 
     def assertRefs(self, expected_refs, cwd=None):
         if cwd is None:
@@ -2199,6 +2199,12 @@ class GitShallowTest(FetcherTest):
         self.assertIn("fstests.doap", dir)
 
 class GitLfsTest(FetcherTest):
+    def skipIfNoGitLFS():
+        import shutil
+        if not shutil.which('git-lfs'):
+            return unittest.skip('git-lfs not installed')
+        return lambda f: f
+
     def setUp(self):
         FetcherTest.setUp(self)
 
@@ -2212,7 +2218,7 @@ class GitLfsTest(FetcherTest):
 
         self.d.setVar('SRCREV', '${AUTOREV}')
         self.d.setVar('AUTOREV', '${@bb.fetch2.get_autorev(d)}')
-        self.d.setVar("__BBSEENSRCREV", "1")
+        self.d.setVar("__BBSRCREV_SEEN", "1")
 
         bb.utils.mkdirhier(self.srcdir)
         self.git_init(cwd=self.srcdir)
@@ -2232,6 +2238,44 @@ class GitLfsTest(FetcherTest):
         ud = fetcher.ud[uri]
         return fetcher, ud
 
+    def get_real_git_lfs_file(self):
+        self.d.setVar('PATH', os.environ.get('PATH'))
+        fetcher, ud = self.fetch()
+        fetcher.unpack(self.d.getVar('WORKDIR'))
+        unpacked_lfs_file = os.path.join(self.d.getVar('WORKDIR'), 'git', "Cat_poster_1.jpg")
+        return unpacked_lfs_file
+
+    @skipIfNoGitLFS()
+    @skipIfNoNetwork()
+    def test_real_git_lfs_repo_succeeds_without_lfs_param(self):
+        self.d.setVar('SRC_URI', "git://gitlab.com/gitlab-examples/lfs.git;protocol=https;branch=master")
+        f = self.get_real_git_lfs_file()
+        self.assertTrue(os.path.exists(f))
+        self.assertEqual("c0baab607a97839c9a328b4310713307", bb.utils.md5_file(f))
+
+    @skipIfNoGitLFS()
+    @skipIfNoNetwork()
+    def test_real_git_lfs_repo_succeeds(self):
+        self.d.setVar('SRC_URI', "git://gitlab.com/gitlab-examples/lfs.git;protocol=https;branch=master;lfs=1")
+        f = self.get_real_git_lfs_file()
+        self.assertTrue(os.path.exists(f))
+        self.assertEqual("c0baab607a97839c9a328b4310713307", bb.utils.md5_file(f))
+
+    @skipIfNoGitLFS()
+    @skipIfNoNetwork()
+    def test_real_git_lfs_repo_succeeds(self):
+        self.d.setVar('SRC_URI', "git://gitlab.com/gitlab-examples/lfs.git;protocol=https;branch=master;lfs=0")
+        f = self.get_real_git_lfs_file()
+        # This is the actual non-smudged placeholder file on the repo if git-lfs does not run
+        lfs_file = (
+                   'version https://git-lfs.github.com/spec/v1\n'
+                   'oid sha256:34be66b1a39a1955b46a12588df9d5f6fc1da790e05cf01f3c7422f4bbbdc26b\n'
+                   'size 11423554\n'
+        )
+
+        with open(f) as fh:
+            self.assertEqual(lfs_file, fh.read())
+
     def test_lfs_enabled(self):
         import shutil
 
@@ -2250,12 +2294,16 @@ class GitLfsTest(FetcherTest):
             shutil.rmtree(self.gitdir, ignore_errors=True)
             fetcher.unpack(self.d.getVar('WORKDIR'))
 
-        # If git-lfs cannot be found, the unpack should throw an error
-        with self.assertRaises(bb.fetch2.FetchError):
-            fetcher.download()
-            ud.method._find_git_lfs = lambda d: False
-            shutil.rmtree(self.gitdir, ignore_errors=True)
-            fetcher.unpack(self.d.getVar('WORKDIR'))
+        old_find_git_lfs = ud.method._find_git_lfs
+        try:
+            # If git-lfs cannot be found, the unpack should throw an error
+            with self.assertRaises(bb.fetch2.FetchError):
+                fetcher.download()
+                ud.method._find_git_lfs = lambda d: False
+                shutil.rmtree(self.gitdir, ignore_errors=True)
+                fetcher.unpack(self.d.getVar('WORKDIR'))
+        finally:
+            ud.method._find_git_lfs = old_find_git_lfs
 
     def test_lfs_disabled(self):
         import shutil
@@ -2270,17 +2318,21 @@ class GitLfsTest(FetcherTest):
         fetcher, ud = self.fetch()
         self.assertIsNotNone(ud.method._find_git_lfs)
 
-        # If git-lfs can be found, the unpack should be successful. A
-        # live copy of git-lfs is not required for this case, so
-        # unconditionally forge its presence.
-        ud.method._find_git_lfs = lambda d: True
-        shutil.rmtree(self.gitdir, ignore_errors=True)
-        fetcher.unpack(self.d.getVar('WORKDIR'))
+        old_find_git_lfs = ud.method._find_git_lfs
+        try:
+            # If git-lfs can be found, the unpack should be successful. A
+            # live copy of git-lfs is not required for this case, so
+            # unconditionally forge its presence.
+            ud.method._find_git_lfs = lambda d: True
+            shutil.rmtree(self.gitdir, ignore_errors=True)
+            fetcher.unpack(self.d.getVar('WORKDIR'))
+            # If git-lfs cannot be found, the unpack should be successful
 
-        # If git-lfs cannot be found, the unpack should be successful
-        ud.method._find_git_lfs = lambda d: False
-        shutil.rmtree(self.gitdir, ignore_errors=True)
-        fetcher.unpack(self.d.getVar('WORKDIR'))
+            ud.method._find_git_lfs = lambda d: False
+            shutil.rmtree(self.gitdir, ignore_errors=True)
+            fetcher.unpack(self.d.getVar('WORKDIR'))
+        finally:
+            ud.method._find_git_lfs = old_find_git_lfs
 
 class GitURLWithSpacesTest(FetcherTest):
     test_git_urls = {
@@ -2325,6 +2377,13 @@ class CrateTest(FetcherTest):
         d = self.d
 
         fetcher = bb.fetch2.Fetch(uris, self.d)
+        ud = fetcher.ud[fetcher.urls[0]]
+
+        self.assertIn("name", ud.parm)
+        self.assertEqual(ud.parm["name"], "glob-0.2.11")
+        self.assertIn("downloadfilename", ud.parm)
+        self.assertEqual(ud.parm["downloadfilename"], "glob-0.2.11.crate")
+
         fetcher.download()
         fetcher.unpack(self.tempdir)
         self.assertEqual(sorted(os.listdir(self.tempdir)), ['cargo_home', 'download' , 'unpacked'])
@@ -2332,6 +2391,30 @@ class CrateTest(FetcherTest):
         self.assertTrue(os.path.exists(self.tempdir + "/cargo_home/bitbake/glob-0.2.11/.cargo-checksum.json"))
         self.assertTrue(os.path.exists(self.tempdir + "/cargo_home/bitbake/glob-0.2.11/src/lib.rs"))
 
+    @skipIfNoNetwork()
+    def test_crate_url_params(self):
+
+        uri = "crate://crates.io/aho-corasick/0.7.20;name=aho-corasick-renamed"
+        self.d.setVar('SRC_URI', uri)
+
+        uris = self.d.getVar('SRC_URI').split()
+        d = self.d
+
+        fetcher = bb.fetch2.Fetch(uris, self.d)
+        ud = fetcher.ud[fetcher.urls[0]]
+
+        self.assertIn("name", ud.parm)
+        self.assertEqual(ud.parm["name"], "aho-corasick-renamed")
+        self.assertIn("downloadfilename", ud.parm)
+        self.assertEqual(ud.parm["downloadfilename"], "aho-corasick-0.7.20.crate")
+
+        fetcher.download()
+        fetcher.unpack(self.tempdir)
+        self.assertEqual(sorted(os.listdir(self.tempdir)), ['cargo_home', 'download' , 'unpacked'])
+        self.assertEqual(sorted(os.listdir(self.tempdir + "/download")), ['aho-corasick-0.7.20.crate', 'aho-corasick-0.7.20.crate.done'])
+        self.assertTrue(os.path.exists(self.tempdir + "/cargo_home/bitbake/aho-corasick-0.7.20/.cargo-checksum.json"))
+        self.assertTrue(os.path.exists(self.tempdir + "/cargo_home/bitbake/aho-corasick-0.7.20/src/lib.rs"))
+
     @skipIfNoNetwork()
     def test_crate_url_multi(self):
 
@@ -2342,6 +2425,19 @@ class CrateTest(FetcherTest):
         d = self.d
 
         fetcher = bb.fetch2.Fetch(uris, self.d)
+        ud = fetcher.ud[fetcher.urls[0]]
+
+        self.assertIn("name", ud.parm)
+        self.assertEqual(ud.parm["name"], "glob-0.2.11")
+        self.assertIn("downloadfilename", ud.parm)
+        self.assertEqual(ud.parm["downloadfilename"], "glob-0.2.11.crate")
+
+        ud = fetcher.ud[fetcher.urls[1]]
+        self.assertIn("name", ud.parm)
+        self.assertEqual(ud.parm["name"], "time-0.1.35")
+        self.assertIn("downloadfilename", ud.parm)
+        self.assertEqual(ud.parm["downloadfilename"], "time-0.1.35.crate")
+
         fetcher.download()
         fetcher.unpack(self.tempdir)
         self.assertEqual(sorted(os.listdir(self.tempdir)), ['cargo_home', 'download' , 'unpacked'])
@@ -2351,6 +2447,18 @@ class CrateTest(FetcherTest):
         self.assertTrue(os.path.exists(self.tempdir + "/cargo_home/bitbake/time-0.1.35/.cargo-checksum.json"))
         self.assertTrue(os.path.exists(self.tempdir + "/cargo_home/bitbake/time-0.1.35/src/lib.rs"))
 
+    @skipIfNoNetwork()
+    def test_crate_incorrect_cksum(self):
+        uri = "crate://crates.io/aho-corasick/0.7.20"
+        self.d.setVar('SRC_URI', uri)
+        self.d.setVarFlag("SRC_URI", "aho-corasick-0.7.20.sha256sum", hashlib.sha256("Invalid".encode("utf-8")).hexdigest())
+
+        uris = self.d.getVar('SRC_URI').split()
+
+        fetcher = bb.fetch2.Fetch(uris, self.d)
+        with self.assertRaisesRegexp(bb.fetch2.FetchError, "Fetcher failure for URL"):
+            fetcher.download()
+
 class NPMTest(FetcherTest):
     def skipIfNoNpm():
         import shutil
@@ -2612,6 +2720,45 @@ class NPMTest(FetcherTest):
         self.assertTrue(os.path.exists(os.path.join(self.sdir, 'node_modules', 'array-flatten', 'node_modules', 'content-type', 'package.json')))
         self.assertTrue(os.path.exists(os.path.join(self.sdir, 'node_modules', 'array-flatten', 'node_modules', 'content-type', 'node_modules', 'cookie', 'package.json')))
 
+    @skipIfNoNpm()
+    @skipIfNoNetwork()
+    def test_npmsw_git(self):
+        swfile = self.create_shrinkwrap_file({
+            'dependencies': {
+                'cookie': {
+                    'version': 'github:jshttp/cookie.git#aec1177c7da67e3b3273df96cf476824dbc9ae09',
+                    'from': 'github:jshttp/cookie.git'
+                }
+            }
+        })
+        fetcher = bb.fetch.Fetch(['npmsw://' + swfile], self.d)
+        fetcher.download()
+        self.assertTrue(os.path.exists(os.path.join(self.dldir, 'git2', 'github.com.jshttp.cookie.git')))
+
+        swfile = self.create_shrinkwrap_file({
+            'dependencies': {
+                'cookie': {
+                    'version': 'jshttp/cookie.git#aec1177c7da67e3b3273df96cf476824dbc9ae09',
+                    'from': 'jshttp/cookie.git'
+                }
+            }
+        })
+        fetcher = bb.fetch.Fetch(['npmsw://' + swfile], self.d)
+        fetcher.download()
+        self.assertTrue(os.path.exists(os.path.join(self.dldir, 'git2', 'github.com.jshttp.cookie.git')))
+
+        swfile = self.create_shrinkwrap_file({
+            'dependencies': {
+                'nodejs': {
+                    'version': 'gitlab:gitlab-examples/nodejs.git#892a1f16725e56cc3a2cb0d677be42935c8fc262',
+                    'from': 'gitlab:gitlab-examples/nodejs'
+                }
+            }
+        })
+        fetcher = bb.fetch.Fetch(['npmsw://' + swfile], self.d)
+        fetcher.download()
+        self.assertTrue(os.path.exists(os.path.join(self.dldir, 'git2', 'gitlab.com.gitlab-examples.nodejs.git')))
+
     @skipIfNoNpm()
     @skipIfNoNetwork()
     def test_npmsw_dev(self):
@@ -2821,7 +2968,7 @@ class GitSharedTest(FetcherTest):
         super(GitSharedTest, self).setUp()
         self.recipe_url = "git://git.openembedded.org/bitbake;branch=master"
         self.d.setVar('SRCREV', '82ea737a0b42a8b53e11c9cde141e9e9c0bd8c40')
-        self.d.setVar("__BBSEENSRCREV", "1")
+        self.d.setVar("__BBSRCREV_SEEN", "1")
 
     @skipIfNoNetwork()
     def test_shared_unpack(self):

bitbake/lib/bb/tests/parse.py

@@ -218,3 +218,26 @@ VAR = " \\
         with self.assertRaises(bb.BBHandledException):
             d = bb.parse.handle(f.name, self.d)['']
 
+
+    at_sign_in_var_flag = """
+A[flag@.service] = "nonet"
+B[flag@.target] = "ntb"
+C[f] = "flag"
+
+unset A[flag@.service]
+"""
+    def test_parse_at_sign_in_var_flag(self):
+        f = self.parsehelper(self.at_sign_in_var_flag)
+        d = bb.parse.handle(f.name, self.d)['']
+        self.assertEqual(d.getVar("A"), None)
+        self.assertEqual(d.getVar("B"), None)
+        self.assertEqual(d.getVarFlag("A","flag@.service"), None)
+        self.assertEqual(d.getVarFlag("B","flag@.target"), "ntb")
+        self.assertEqual(d.getVarFlag("C","f"), "flag")
+
+    def test_parse_invalid_at_sign_in_var_flag(self):
+        invalid_at_sign = self.at_sign_in_var_flag.replace("B[f", "B[@f")
+        f = self.parsehelper(invalid_at_sign)
+        with self.assertRaises(bb.parse.ParseError):
+            d = bb.parse.handle(f.name, self.d)['']
+

bitbake/lib/bb/utils.py

@@ -1698,22 +1698,11 @@ def disable_network(uid=None, gid=None):
         f.write("%s %s 1" % (gid, gid))
 
 def export_proxies(d):
+    from bb.fetch2 import get_fetcher_environment
     """ export common proxies variables from datastore to environment """
-
-    variables = ['http_proxy', 'HTTP_PROXY', 'https_proxy', 'HTTPS_PROXY',
-                    'ftp_proxy', 'FTP_PROXY', 'no_proxy', 'NO_PROXY',
-                    'GIT_PROXY_COMMAND', 'SSL_CERT_FILE', 'SSL_CERT_DIR']
-
-    origenv = d.getVar("BB_ORIGENV")
-
-    for name in variables:
-        value = d.getVar(name)
-        if not value and origenv:
-            value = origenv.getVar(name)
-        if value:
-            os.environ[name] = value
-
-
+    newenv = get_fetcher_environment(d)
+    for v in newenv:
+        os.environ[v] = newenv[v]
 
 def load_plugins(logger, plugins, pluginpath):
     def load_plugin(name):

bitbake/lib/bblayers/action.py

@@ -11,6 +11,7 @@ import shutil
 import sys
 import tempfile
 
+from bb.cookerdata import findTopdir
 import bb.utils
 
 from bblayers.common import LayerPlugin
@@ -37,7 +38,7 @@ class ActionPlugin(LayerPlugin):
                 sys.stderr.write("Specified layer directory %s doesn't contain a conf/layer.conf file\n" % layerdir)
                 return 1
 
-        bblayers_conf = os.path.join('conf', 'bblayers.conf')
+        bblayers_conf = os.path.join(findTopdir(),'conf', 'bblayers.conf')
         if not os.path.exists(bblayers_conf):
             sys.stderr.write("Unable to find bblayers.conf\n")
             return 1
@@ -65,7 +66,7 @@ class ActionPlugin(LayerPlugin):
 
     def do_remove_layer(self, args):
         """Remove one or more layers from bblayers.conf."""
-        bblayers_conf = os.path.join('conf', 'bblayers.conf')
+        bblayers_conf = os.path.join(findTopdir() ,'conf', 'bblayers.conf')
         if not os.path.exists(bblayers_conf):
             sys.stderr.write("Unable to find bblayers.conf\n")
             return 1

bitbake/lib/bblayers/query.py

@@ -29,12 +29,12 @@ class QueryPlugin(LayerPlugin):
 
     def do_show_layers(self, args):
         """show current configured layers."""
-        logger.plain("%s  %s  %s" % ("layer".ljust(20), "path".ljust(40), "priority"))
-        logger.plain('=' * 74)
+        logger.plain("%s  %s  %s" % ("layer".ljust(20), "path".ljust(70), "priority"))
+        logger.plain('=' * 104)
         for layer, _, regex, pri in self.tinfoil.cooker.bbfile_config_priorities:
             layerdir = self.bbfile_collections.get(layer, None)
-            layername = self.get_layer_name(layerdir)
-            logger.plain("%s  %s  %d" % (layername.ljust(20), layerdir.ljust(40), pri))
+            layername = layer
+            logger.plain("%s  %s  %s" % (layername.ljust(20), layerdir.ljust(70), pri))
 
     def version_str(self, pe, pv, pr = None):
         verstr = "%s" % pv

bitbake/lib/toaster/orm/fixtures/gen_fixtures.py

@@ -35,18 +35,19 @@ verbose = False
 # [Codename, Yocto Project Version, Release Date, Current Version, Support Level, Poky Version, BitBake branch]
 current_releases = [
     # Release slot #1
-    ['Kirkstone','4.0','April 2022','4.0.6 (December 2022)','Stable - Long Term Support (until Apr. 2024)','','2.0'],
+    ['Kirkstone','4.0','April 2022','4.0.8 (March 2023)','Stable - Long Term Support (until Apr. 2024)','','2.0'],
     # Release slot #2 'local'
     ['HEAD','HEAD','','Local Yocto Project','HEAD','','HEAD'],
     # Release slot #3 'master'
     ['Master','master','','Yocto Project master','master','','master'],
     # Release slot #4
-    ['Langdale','4.1','October 2022','4.1.2 (January 2023)','Support for 7 months (until May 2023)','','2.2'],
+    ['Mickledore','4.2','April 2023','4.2.0 (April 2023)','Support for 7 months (until October 2023)','','2.4'],
+#   ['Langdale','4.1','October 2022','4.1.2 (January 2023)','Support for 7 months (until May 2023)','','2.2'],
 #   ['Honister','3.4','October 2021','3.4.2 (February 2022)','Support for 7 months (until May 2022)','26.0','1.52'],
 #   ['Hardknott','3.3','April 2021','3.3.5 (March 2022)','Stable - Support for 13 months (until Apr. 2022)','25.0','1.50'],
 #   ['Gatesgarth','3.2','Oct 2020','3.2.4 (May 2021)','EOL','24.0','1.48'],
     # Optional Release slot #5
-    ['Dunfell','3.1','April 2020','3.1.22 (January 2023)','Stable - Long Term Support (until Apr. 2024)','23.0','1.46'],
+    ['Dunfell','3.1','April 2020','3.1.23 (February 2023)','Stable - Long Term Support (until Apr. 2024)','23.0','1.46'],
 ]
 
 default_poky_layers = [

bitbake/lib/toaster/orm/fixtures/oe-core.xml

@@ -23,9 +23,9 @@
     <field type="CharField" name="branch">master</field>
   </object>
   <object model="orm.bitbakeversion" pk="4">
-    <field type="CharField" name="name">langdale</field>
+    <field type="CharField" name="name">mickledore</field>
     <field type="CharField" name="giturl">git://git.openembedded.org/bitbake</field>
-    <field type="CharField" name="branch">2.2</field>
+    <field type="CharField" name="branch">2.4</field>
   </object>
   <object model="orm.bitbakeversion" pk="5">
     <field type="CharField" name="name">dunfell</field>
@@ -56,11 +56,11 @@
     <field type="TextField" name="helptext">Toaster will run your builds using the tip of the &lt;a href=\"https://cgit.openembedded.org/openembedded-core/log/\"&gt;OpenEmbedded master&lt;/a&gt; branch.</field>
   </object>
   <object model="orm.release" pk="4">
-    <field type="CharField" name="name">langdale</field>
-    <field type="CharField" name="description">Openembedded Langdale</field>
+    <field type="CharField" name="name">mickledore</field>
+    <field type="CharField" name="description">Openembedded Mickledore</field>
     <field rel="ManyToOneRel" to="orm.bitbakeversion" name="bitbake_version">4</field>
-    <field type="CharField" name="branch_name">langdale</field>
-    <field type="TextField" name="helptext">Toaster will run your builds using the tip of the &lt;a href=\"https://cgit.openembedded.org/openembedded-core/log/?h=langdale\"&gt;OpenEmbedded Langdale&lt;/a&gt; branch.</field>
+    <field type="CharField" name="branch_name">mickledore</field>
+    <field type="TextField" name="helptext">Toaster will run your builds using the tip of the &lt;a href=\"https://cgit.openembedded.org/openembedded-core/log/?h=mickledore\"&gt;OpenEmbedded Mickledore&lt;/a&gt; branch.</field>
   </object>
   <object model="orm.release" pk="5">
     <field type="CharField" name="name">dunfell</field>

bitbake/lib/toaster/orm/fixtures/poky.xml

@@ -26,9 +26,9 @@
     <field type="CharField" name="dirpath">bitbake</field>
   </object>
   <object model="orm.bitbakeversion" pk="4">
-    <field type="CharField" name="name">langdale</field>
+    <field type="CharField" name="name">mickledore</field>
     <field type="CharField" name="giturl">git://git.yoctoproject.org/poky</field>
-    <field type="CharField" name="branch">langdale</field>
+    <field type="CharField" name="branch">mickledore</field>
     <field type="CharField" name="dirpath">bitbake</field>
   </object>
   <object model="orm.bitbakeversion" pk="5">
@@ -62,11 +62,11 @@
     <field type="TextField" name="helptext">Toaster will run your builds using the tip of the &lt;a href="https://git.yoctoproject.org/cgit/cgit.cgi/poky/log/"&gt;Yocto Project Master branch&lt;/a&gt;.</field>
   </object>
   <object model="orm.release" pk="4">
-    <field type="CharField" name="name">langdale</field>
-    <field type="CharField" name="description">Yocto Project 4.1 "Langdale"</field>
+    <field type="CharField" name="name">mickledore</field>
+    <field type="CharField" name="description">Yocto Project 4.2 "Mickledore"</field>
     <field rel="ManyToOneRel" to="orm.bitbakeversion" name="bitbake_version">4</field>
-    <field type="CharField" name="branch_name">langdale</field>
-    <field type="TextField" name="helptext">Toaster will run your builds using the tip of the &lt;a href="https://git.yoctoproject.org/cgit/cgit.cgi/poky/log/?h=langdale"&gt;Yocto Project Langdale branch&lt;/a&gt;.</field>
+    <field type="CharField" name="branch_name">mickledore</field>
+    <field type="TextField" name="helptext">Toaster will run your builds using the tip of the &lt;a href="https://git.yoctoproject.org/cgit/cgit.cgi/poky/log/?h=mickledore"&gt;Yocto Project Mickledore branch&lt;/a&gt;.</field>
   </object>
   <object model="orm.release" pk="5">
     <field type="CharField" name="name">dunfell</field>
@@ -177,7 +177,7 @@
     <field rel="ManyToOneRel" to="orm.layer" name="layer">1</field>
     <field type="IntegerField" name="layer_source">0</field>
     <field rel="ManyToOneRel" to="orm.release" name="release">4</field>
-    <field type="CharField" name="branch">langdale</field>
+    <field type="CharField" name="branch">mickledore</field>
     <field type="CharField" name="dirpath">meta</field>
   </object>
   <object model="orm.layer_version" pk="5">
@@ -222,7 +222,7 @@
     <field rel="ManyToOneRel" to="orm.layer" name="layer">2</field>
     <field type="IntegerField" name="layer_source">0</field>
     <field rel="ManyToOneRel" to="orm.release" name="release">4</field>
-    <field type="CharField" name="branch">langdale</field>
+    <field type="CharField" name="branch">mickledore</field>
     <field type="CharField" name="dirpath">meta-poky</field>
   </object>
   <object model="orm.layer_version" pk="10">
@@ -267,7 +267,7 @@
     <field rel="ManyToOneRel" to="orm.layer" name="layer">3</field>
     <field type="IntegerField" name="layer_source">0</field>
     <field rel="ManyToOneRel" to="orm.release" name="release">4</field>
-    <field type="CharField" name="branch">langdale</field>
+    <field type="CharField" name="branch">mickledore</field>
     <field type="CharField" name="dirpath">meta-yocto-bsp</field>
   </object>
   <object model="orm.layer_version" pk="15">

documentation/README

@@ -357,13 +357,16 @@ The sphinx.ext.intersphinx extension is enabled by default
 so that we can cross reference content from other Sphinx based
 documentation projects, such as the BitBake manual.
 
-References to the BitBake manual can be done:
+References to the BitBake manual can directly be done:
  - With a specific description instead of the section name:
-  :ref:`Azure Storage fetcher (az://) <bitbake:bitbake-user-manual/bitbake-user-manual-fetching:fetchers>`
+  :ref:`Azure Storage fetcher (az://) <bitbake-user-manual/bitbake-user-manual-fetching:fetchers>`
  - With the section name:
-  :ref:`bitbake:bitbake-user-manual/bitbake-user-manual-intro:usage and syntax` option
- - Linking to the entire BitBake manual:
-  :doc:`BitBake User Manual <bitbake:index>`
+  :ref:`bitbake-user-manual/bitbake-user-manual-intro:usage and syntax` option
+
+If you want to refer to an entire document (or chapter) in the BitBake manual,
+you have to use the ":doc:" macro with the "bitbake:" prefix:
+ - :doc:`BitBake User Manual <bitbake:index>`
+ - :doc:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata`" chapter
 
 Note that a reference to a variable (:term:`VARIABLE`) automatically points to
 the BitBake manual if the variable is not described in the Reference Manual's Variable Glossary.
@@ -372,6 +375,11 @@ BitBake manual as follows:
 
   :term:`bitbake:BB_NUMBER_PARSE_THREADS`
 
+This would be the same if we had identical document filenames in
+both the Yocto Project and BitBake manuals:
+
+  :ref:`bitbake:directory/file:section title`
+
 Submitting documentation changes
 ================================
 

documentation/brief-yoctoprojectqs/index.rst

@@ -40,7 +40,13 @@ Compatible Linux Distribution
 Make sure your :term:`Build Host` meets the
 following requirements:
 
--  50 Gbytes of free disk space
+-  At least &MIN_DISK_SPACE; Gbytes of free disk space, though
+   much more will help to run multiple builds and increase
+   performance by reusing build artifacts.
+
+-  At least &MIN_RAM; Gbytes of RAM, though a modern modern build host with as
+   much RAM and as many CPU cores as possible is strongly recommended to
+   maximize build performance.
 
 -  Runs a supported Linux distribution (i.e. recent releases of Fedora,
    openSUSE, CentOS, Debian, or Ubuntu). For a list of Linux
@@ -70,11 +76,9 @@ Build Host Packages
 
 You must install essential host packages on your build host. The
 following command installs the host packages based on an Ubuntu
-distribution:
+distribution::
 
-.. code-block:: shell
-
-  $ sudo apt install &UBUNTU_HOST_PACKAGES_ESSENTIAL;
+   $ sudo apt install &UBUNTU_HOST_PACKAGES_ESSENTIAL;
 
 .. note::
 
@@ -250,7 +254,7 @@ an entire Linux distribution, including the toolchain, from source.
          BB_SIGNATURE_HANDLER = "OEEquivHash"
          BB_HASHSERVE = "auto"
          BB_HASHSERVE_UPSTREAM = "hashserv.yocto.io:8687"
-         SSTATE_MIRRORS ?= "file://.* https://sstate.yoctoproject.org/all/PATH;downloadfilename=PATH"
+         SSTATE_MIRRORS ?= "file://.* http://cdn.jsdelivr.net/yocto/sstate/all/PATH;downloadfilename=PATH"
 
 #. **Start the Build:** Continue with the following command to build an OS
    image for the target, which is ``core-image-sato`` in this example:
@@ -262,7 +266,7 @@ an entire Linux distribution, including the toolchain, from source.
    For information on using the ``bitbake`` command, see the
    :ref:`overview-manual/concepts:bitbake` section in the Yocto Project Overview and
    Concepts Manual, or see
-   :ref:`bitbake:bitbake-user-manual/bitbake-user-manual-intro:the bitbake command`
+   :ref:`bitbake-user-manual/bitbake-user-manual-intro:the bitbake command`
    in the BitBake User Manual.
 
 #. **Simulate Your Image Using QEMU:** Once this particular image is

documentation/bsp-guide/bsp.rst

@@ -109,7 +109,7 @@ them to the "Dependencies" section.
 
 Some layers function as a layer to hold other BSP layers. These layers
 are known as ":term:`container layers <Container Layer>`". An example of
-this type of layer is OpenEmbedded's :oe_git:`meta-openbedded </meta-openembedded>`
+this type of layer is OpenEmbedded's :oe_git:`meta-openembedded </meta-openembedded>`
 layer. The ``meta-openembedded`` layer contains many ``meta-*`` layers.
 In cases like this, you need to include the names of the actual layers
 you want to work with, such as::
@@ -774,20 +774,6 @@ workflow.
 
          -  Two general IA platforms (``genericx86`` and ``genericx86-64``)
 
-      -  There are three core Intel BSPs in the Yocto Project
-         release, in the ``meta-intel`` layer:
-
-         -  ``intel-core2-32``, which is a BSP optimized for the Core2
-            family of CPUs as well as all CPUs prior to the Silvermont
-            core.
-
-         -  ``intel-corei7-64``, which is a BSP optimized for Nehalem
-            and later Core and Xeon CPUs as well as Silvermont and later
-            Atom CPUs, such as the Baytrail SoCs.
-
-         -  ``intel-quark``, which is a BSP optimized for the Intel
-            Galileo gen1 & gen2 development boards.
-
    When you set up a layer for a new BSP, you should follow a standard
    layout. This layout is described in the ":ref:`bsp-guide/bsp:example filesystem layout`"
    section. In the standard layout, notice
@@ -893,8 +879,8 @@ Yocto Project:
    ``recipes-*`` subdirectories specific to the recipe's function, or
    within a subdirectory containing a set of closely-related recipes.
    The recipes themselves should follow the general guidelines for
-   recipes used in the Yocto Project found in the ":oe_wiki:`OpenEmbedded
-   Style Guide </Styleguide>`".
+   recipes found in the ":doc:`../contributor-guide/recipe-style-guide`"
+   in the Yocto Project and OpenEmbedded Contributor Guide.
 
 -  *License File:* You must include a license file in the
    ``meta-bsp_root_name`` directory. This license covers the BSP
@@ -927,8 +913,8 @@ Yocto Project:
    -  The name and contact information for the BSP layer maintainer.
       This is the person to whom patches and questions should be sent.
       For information on how to find the right person, see the
-      ":ref:`dev-manual/changes:submitting a change to the yocto project`"
-      section in the Yocto Project Development Tasks Manual.
+      :doc:`../contributor-guide/submit-changes` section in the Yocto Project and
+      OpenEmbedded Contributor Guide.
 
    -  Instructions on how to build the BSP using the BSP layer.
 
@@ -1179,14 +1165,14 @@ Use these steps to create a BSP layer:
    :yocto_git:`Source Repositories <>`. To get examples of what you need
    in your configuration file, locate a layer (e.g. "meta-ti") and
    examine the
-   :yocto_git:`local.conf </meta-ti/tree/conf/layer.conf>`
+   :yocto_git:`local.conf </meta-ti/tree/meta-ti-bsp/conf/layer.conf>`
    file.
 
 -  *Create a Machine Configuration File:* Create a
    ``conf/machine/bsp_root_name.conf`` file. See
    :yocto_git:`meta-yocto-bsp/conf/machine </poky/tree/meta-yocto-bsp/conf/machine>`
    for sample ``bsp_root_name.conf`` files. There are other samples such as
-   :yocto_git:`meta-ti </meta-ti/tree/conf/machine>`
+   :yocto_git:`meta-ti </meta-ti/tree/meta-ti-bsp/conf/machine>`
    and
    :yocto_git:`meta-freescale </meta-freescale/tree/conf/machine>`
    from other vendors that have more specific machine and tuning
@@ -1194,7 +1180,7 @@ Use these steps to create a BSP layer:
 
 -  *Create a Kernel Recipe:* Create a kernel recipe in
    ``recipes-kernel/linux`` by either using a kernel append file or a
-   new custom kernel recipe file (e.g. ``yocto-linux_4.12.bb``). The BSP
+   new custom kernel recipe file (e.g. ``linux-yocto_4.12.bb``). The BSP
    layers mentioned in the previous step also contain different kernel
    examples. See the ":ref:`kernel-dev/common:modifying an existing recipe`"
    section in the Yocto Project Linux Kernel Development Manual for
@@ -1209,7 +1195,7 @@ BSP Layer Configuration Example
 -------------------------------
 
 The layer's ``conf`` directory contains the ``layer.conf`` configuration
-file. In this example, the ``conf/layer.conf`` is the following::
+file. In this example, the ``conf/layer.conf`` file is the following::
 
    # We have a conf and classes directory, add to BBPATH
    BBPATH .= ":${LAYERDIR}"

documentation/conf.py

@@ -91,6 +91,7 @@ rst_prolog = """
 # external links and substitutions
 extlinks = {
     'cve': ('https://nvd.nist.gov/vuln/detail/CVE-%s', 'CVE-%s'),
+    'cve_mitre': ('https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-%s', 'CVE-%s'),
     'yocto_home': ('https://www.yoctoproject.org%s', None),
     'yocto_wiki': ('https://wiki.yoctoproject.org/wiki%s', None),
     'yocto_dl': ('https://downloads.yoctoproject.org%s', None),

documentation/contributor-guide/identify-component.rst

@@ -0,0 +1,31 @@
+.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
+
+Identify the component
+**********************
+
+The Yocto Project and OpenEmbedded ecosystem is built of :term:`layers <Layer>`
+so the first step is to identify the component where the issue likely lies.
+For example, if you have a hardware issue, it is likely related to the BSP
+you are using and the best place to seek advice would be from the BSP provider
+or :term:`layer`. If the issue is a build/configuration one and a distro is in
+use, they would likely be the first place to ask questions. If the issue is a
+generic one and/or in the core classes or metadata, the core layer or BitBake
+might be the appropriate component.
+
+Each metadata layer being used should contain a ``README`` file and that should
+explain where to report issues, where to send changes and how to contact the
+maintainers.
+
+If the issue is in the core metadata layer (OpenEmbedded-Core) or in BitBake,
+issues can be reported in the :yocto_bugs:`Yocto Project Bugzilla <>`. The
+:yocto_lists:`yocto </g/yocto>` mailing list is a general “catch-all” location
+where questions can be sent if you can’t work out where something should go.
+
+:term:`Poky` is a commonly used “combination” repository where multiple
+components have been combined (:oe_git:`bitbake </bitbake>`,
+:oe_git:`openembedded-core </openembedded-core>`,
+:yocto_git:`meta-yocto </meta-yocto>` and
+:yocto_git:`yocto-docs </yocto-docs>`). Patches should be submitted against the
+appropriate individual component rather than :term:`Poky` itself as detailed in
+the appropriate ``README`` file.
+

documentation/contributor-guide/index.rst

@@ -0,0 +1,26 @@
+.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
+
+================================================
+Yocto Project and OpenEmbedded Contributor Guide
+================================================
+
+The Yocto Project and OpenEmbedded are open-source, community-based projects so
+contributions are very welcome, it is how the code evolves and everyone can
+effect change. Contributions take different forms, if you have a fix for an
+issue you’ve run into, a patch is the most appropriate way to contribute it.
+If you run into an issue but don’t have a solution, opening a defect in
+:yocto_bugs:`Bugzilla <>` or asking questions on the mailing lists might be
+more appropriate. This guide intends to point you in the right direction to
+this.
+
+
+.. toctree::
+   :caption: Table of Contents
+   :numbered:
+
+   identify-component
+   report-defect
+   recipe-style-guide
+   submit-changes
+
+.. include:: /boilerplate.rst

documentation/contributor-guide/recipe-style-guide.rst

@@ -0,0 +1,399 @@
+.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
+
+Recipe Style Guide
+******************
+
+Recipe Naming Conventions
+=========================
+
+In general, most recipes should follow the naming convention
+``recipes-category/recipename/recipename_version.bb``. Recipes for related
+projects may share the same recipe directory. ``recipename`` and ``category``
+may contain hyphens, but hyphens are not allowed in ``version``.
+
+If the recipe is tracking a Git revision that does not correspond to a released
+version of the software, ``version`` may be ``git`` (e.g. ``recipename_git.bb``)
+and the recipe would set :term:`PV`.
+
+Version Policy
+==============
+
+Our versions follow the form ``<epoch>:<version>-<revision>``
+or in BitBake variable terms ${:term:`PE`}:${:term:`PV`}-${:term:`PR`}. We
+generally follow the `Debian <https://www.debian.org/doc/debian-policy/ch-controlfields.html#version>`__
+version policy which defines these terms.
+
+In most cases the version :term:`PV` will be set automatically from the recipe
+file name. It is recommended to use released versions of software as these are
+revisions that upstream are expecting people to use.
+
+Recipe versions should always compare and sort correctly so that upgrades work
+as expected. With conventional versions such as ``1.4`` upgrading ``to 1.5``
+this happens naturally, but some versions don't sort. For example,
+``1.5 Release Candidate 2`` could be written as ``1.5rc2`` but this sorts after
+``1.5``, so upgrades from feeds won't happen correctly.
+
+Instead the tilde (``~``) operator can be used, which sorts before the empty
+string so ``1.5~rc2`` comes before ``1.5``. There is a historical syntax which
+may be found where :term:`PV` is set as a combination of the prior version
+``+`` the pre-release version, for example ``PV=1.4+1.5rc2``. This is a valid
+syntax but the tilde form is preferred.
+
+For version comparisons, the ``opkg-compare-versions`` program from
+``opkg-utils`` can be useful when attempting to determine how two version
+numbers compare to each other. Our definitive version comparison algorithm is
+the one within bitbake which aims to match those of the package managers and
+Debian policy closely.
+
+When a recipe references a git revision that does not correspond to a released
+version of software (e.g. is not a tagged version), the :term:`PV` variable
+should include the Git revision using the following to make the
+version clear::
+
+    PV = "<version>+git${SRCPV}"
+
+In this case, ``<version>`` should be the most recently released version of the
+software from the current source revision (``git describe`` can be useful for
+determining this). Whilst not recommended for published layers, this format is
+also useful when using :term:`AUTOREV` to set the recipe to increment source
+control revisions automatically, which can be useful during local development.
+
+Version Number Changes
+======================
+
+The :term:`PR` variable is used to indicate different revisions of a recipe
+that reference the same upstream source version. It can be used to force a
+new version of a recipe to be installed onto a device from a package feed.
+These once had to be set manually but in most cases these can now be set and
+incremented automatically by a PR Server connected with a package feed.
+
+When :term:`PV` increases, any existing :term:`PR` value can and should be
+removed.
+
+If :term:`PV` changes in such a way that it does not increase with respect to
+the previous value, you need to increase :term:`PE` to ensure package managers
+will upgrade it correctly. If unset you should set :term:`PE` to "1" since
+the default of empty is easily confused with "0" depending on the package
+manager. :term:`PE` can only have an integer value.
+
+Recipe formatting
+=================
+
+Variable Formatting
+-------------------
+
+-  Variable assignment should a space around each side of the operator, e.g.
+   ``FOO = "bar"``, not ``FOO="bar"``.
+
+-  Double quotes should be used on the right-hand side of the assignment,
+   e.g. ``FOO = "bar"`` not ``FOO = 'bar'``
+
+-  Spaces should be used for indenting variables, with 4 spaces per tab
+
+-  Long variables should be split over multiple lines when possible by using
+   the continuation character (``\``)
+
+-  When splitting a long variable over multiple lines, all continuation lines
+   should be indented (with spaces) to align with the start of the quote on the
+   first line::
+
+       FOO = "this line is \
+              long \
+              "
+
+   Instead of::
+
+       FOO = "this line is \
+       long \
+       "
+
+Python Function formatting
+--------------------------
+
+-  Spaces must be used for indenting Python code, with 4 spaces per tab
+
+Shell Function formatting
+-------------------------
+
+-  The formatting of shell functions should be consistent within layers.
+   Some use tabs, some use spaces.
+
+Recipe metadata
+===============
+
+Required Variables
+------------------
+
+The following variables should be included in all recipes:
+
+-  :term:`SUMMARY`: a one line description of the upstream project
+
+-  :term:`DESCRIPTION`: an extended description of the upstream project,
+   possibly with multiple lines. If no reasonable description can be written,
+   this may be omitted as it defaults to :term:`SUMMARY`.
+
+-  :term:`HOMEPAGE`: the URL to the upstream projects homepage.
+
+-  :term:`BUGTRACKER`: the URL upstream projects bug tracking website,
+   if applicable.
+
+Recipe Ordering
+---------------
+
+When a variable is defined in recipes and classes, variables should follow the
+general order when possible:
+
+-  :term:`SUMMARY`
+-  :term:`DESCRIPTION`
+-  :term:`HOMEPAGE`
+-  :term:`BUGTRACKER`
+-  :term:`SECTION`
+-  :term:`LICENSE`
+-  :term:`LIC_FILES_CHKSUM`
+-  :term:`DEPENDS`
+-  :term:`PROVIDES`
+-  :term:`PV`
+-  :term:`SRC_URI`
+-  :term:`SRCREV`
+-  :term:`S`
+-  ``inherit ...``
+-  :term:`PACKAGECONFIG`
+-  Build class specific variables such as ``EXTRA_QMAKEVARS_POST`` and :term:`EXTRA_OECONF`
+-  Tasks such as :ref:`ref-tasks-configure`
+-  :term:`PACKAGE_ARCH`
+-  :term:`PACKAGES`
+-  :term:`FILES`
+-  :term:`RDEPENDS`
+-  :term:`RRECOMMENDS`
+-  :term:`RSUGGESTS`
+-  :term:`RPROVIDES`
+-  :term:`RCONFLICTS`
+-  :term:`BBCLASSEXTEND`
+
+There are some cases where ordering is important and these cases would override
+this default order. Examples include:
+
+-  :term:`PACKAGE_ARCH` needing to be set before ``inherit packagegroup``
+
+Tasks should be ordered based on the order they generally execute. For commonly
+used tasks this would be:
+
+-  :ref:`ref-tasks-fetch`
+-  :ref:`ref-tasks-unpack`
+-  :ref:`ref-tasks-patch`
+-  :ref:`ref-tasks-prepare_recipe_sysroot`
+-  :ref:`ref-tasks-configure`
+-  :ref:`ref-tasks-compile`
+-  :ref:`ref-tasks-install`
+-  :ref:`ref-tasks-populate_sysroot`
+-  :ref:`ref-tasks-package`
+
+Custom tasks should be sorted similarly.
+
+Package specific variables are typically grouped together, e.g.::
+
+    RDEPENDS:${PN} = “foo”
+    RDEPENDS:${PN}-libs = “bar”
+
+    RRECOMMENDS:${PN} = “one”
+    RRECOMMENDS:${PN}-libs = “two”
+
+Recipe License Fields
+---------------------
+
+Recipes need to define both the :term:`LICENSE` and
+:term:`LIC_FILES_CHKSUM` variables:
+
+-  :term:`LICENSE`: This variable specifies the license for the software.
+   If you do not know the license under which the software you are
+   building is distributed, you should go to the source code and look
+   for that information. Typical files containing this information
+   include ``COPYING``, :term:`LICENSE`, and ``README`` files. You could
+   also find the information near the top of a source file. For example,
+   given a piece of software licensed under the GNU General Public
+   License version 2, you would set :term:`LICENSE` as follows::
+
+      LICENSE = "GPL-2.0-only"
+
+   The licenses you specify within :term:`LICENSE` can have any name as long
+   as you do not use spaces, since spaces are used as separators between
+   license names. For standard licenses, use the names of the files in
+   ``meta/files/common-licenses/`` or the :term:`SPDXLICENSEMAP` flag names
+   defined in ``meta/conf/licenses.conf``.
+
+-  :term:`LIC_FILES_CHKSUM`: The OpenEmbedded build system uses this
+   variable to make sure the license text has not changed. If it has,
+   the build produces an error and it affords you the chance to figure
+   it out and correct the problem.
+
+   You need to specify all applicable licensing files for the software.
+   At the end of the configuration step, the build process will compare
+   the checksums of the files to be sure the text has not changed. Any
+   differences result in an error with the message containing the
+   current checksum. For more explanation and examples of how to set the
+   :term:`LIC_FILES_CHKSUM` variable, see the
+   ":ref:`dev-manual/licenses:tracking license changes`" section.
+
+   To determine the correct checksum string, you can list the
+   appropriate files in the :term:`LIC_FILES_CHKSUM` variable with incorrect
+   md5 strings, attempt to build the software, and then note the
+   resulting error messages that will report the correct md5 strings.
+   See the ":ref:`dev-manual/new-recipe:fetching code`" section for
+   additional information.
+
+   Here is an example that assumes the software has a ``COPYING`` file::
+
+      LIC_FILES_CHKSUM = "file://COPYING;md5=xxx"
+
+   When you try to build the
+   software, the build system will produce an error and give you the
+   correct string that you can substitute into the recipe file for a
+   subsequent build.
+
+Tips and Guidelines for Writing Recipes
+---------------------------------------
+
+-  Use :term:`BBCLASSEXTEND` instead of creating separate recipes such as ``-native``
+   and ``-nativesdk`` ones, whenever possible. This avoids having to maintain multiple
+   recipe files at the same time.
+
+-  Recipes should have tasks which are idempotent, i.e. that executing a given task
+   multiple times shouldn't change the end result. The build environment is built upon
+   this assumption and breaking it can cause obscure build failures.
+
+-  For idempotence when modifying files in tasks, it is usually best to:
+
+   - copy a file ``X`` to ``X.orig`` (only if it doesn't exist already)
+   - then, copy ``X.orig`` back to ``X``,
+   - and, finally, modify ``X``.
+
+   This ensures if rerun the task always has the same end result and the
+   original file can be preserved to reuse. It also guards against an
+   interrupted build corrupting the file.
+
+Patch Upstream Status
+=====================
+
+In order to keep track of patches applied by recipes and ultimately reduce the
+number of patches that need maintaining, the OpenEmbedded build system
+requires information about the upstream status of each patch.
+
+In its description, each patch should provide detailed information about the
+bug that it addresses, such as the URL in a bug tracking system and links
+to relevant mailing list archives.
+
+Then, you should also add an ``Upstream-Status:`` tag containing one of the
+following status strings:
+
+``Pending``
+   No determination has been made yet, or patch has not yet been submitted to
+   upstream.
+
+   Keep in mind that every patch submitted upstream reduces the maintainance
+   burden in OpenEmbedded and Yocto Project in the long run, so this patch
+   status should only be used in exceptional cases if there are genuine
+   obstacles to submitting a patch upstream; the reason for that should be
+   included in the patch.
+
+``Submitted [where]``
+   Submitted to upstream, waiting for approval. Optionally include where
+   it was submitted, such as the author, mailing list, etc.
+
+``Backport [version]``
+   Accepted upstream and included in the next release, or backported from newer
+   upstream version, because we are at a fixed version.
+   Include upstream version info (e.g. commit ID or next expected version).
+
+``Denied``
+   Not accepted by upstream, include reason in patch.
+
+``Inactive-Upstream [lastcommit: when (and/or) lastrelease: when]``
+   The upstream is no longer available. This typically means a defunct project
+   where no activity has happened for a long time --- measured in years. To make
+   that judgement, it is recommended to look at not only when the last release
+   happened, but also when the last commit happened, and whether newly made bug
+   reports and merge requests since that time receive no reaction. It is also
+   recommended to add to the patch description any relevant links where the
+   inactivity can be clearly seen.
+
+``Inappropriate [reason]``
+   The patch is not appropriate for upstream, include a brief reason on the
+   same line enclosed with ``[]``. In the past, there were several different
+   reasons not to submit patches upstream, but we have to consider that every
+   non-upstreamed patch means a maintainance burden for recipe maintainers.
+   Currently, the only reasons to mark patches as inappropriate for upstream
+   submission are:
+
+   -  ``oe specific``: the issue is specific to how OpenEmbedded performs builds
+      or sets things up at runtime, and can be resolved only with a patch that
+      is not however relevant or appropriate for general upstream submission.
+   -  ``upstream ticket <link>``: the issue is not specific to Open-Embedded
+      and should be fixed upstream, but the patch in its current form is not
+      suitable for merging upstream, and the author lacks sufficient expertise
+      to develop a proper patch. Instead the issue is handled via a bug report
+      (include link).
+
+Of course, if another person later takes care of submitting this patch upstream,
+the status should be changed to ``Submitted [where]``, and an additional
+``Signed-off-by:`` line should be added to the patch by the person claiming
+responsibility for upstreaming.
+
+Examples
+--------
+
+Here's an example of a patch that has been submitted upstream::
+
+   rpm: Adjusted the foo setting in bar
+
+   [RPM Ticket #65] -- http://rpm5.org/cvs/tktview?tn=65,5
+
+   The foo setting in bar was decreased from X to X-50% in order to
+   ensure we don't exhaust all system memory with foobar threads.
+
+   Upstream-Status: Submitted [rpm5-devel@rpm5.org]
+
+   Signed-off-by: Joe Developer <joe.developer@example.com>
+
+A future update can change the value to ``Backport`` or ``Denied`` as
+appropriate.
+
+Another example of a patch that is specific to OpenEmbedded::
+
+   Do not treat warnings as errors
+
+   There are additional warnings found with musl which are
+   treated as errors and fails the build, we have more combinations
+   than upstream supports to handle.
+
+   Upstream-Status: Inappropriate [oe specific]
+
+Here's a patch that has been backported from an upstream commit::
+
+   include missing sys/file.h for LOCK_EX
+
+   Upstream-Status: Backport [https://github.com/systemd/systemd/commit/ac8db36cbc26694ee94beecc8dca208ec4b5fd45]
+
+CVE patches
+===========
+
+In order to have a better control of vulnerabilities, patches that fix CVEs must
+contain a ``CVE:`` tag. This tag list all CVEs fixed by the patch. If more than
+one CVE is fixed, separate them using spaces.
+
+CVE Examples
+------------
+
+This should be the header of patch that fixes :cve:`2015-8370` in GRUB2::
+
+   grub2: Fix CVE-2015-8370
+
+   [No upstream tracking] -- https://bugzilla.redhat.com/show_bug.cgi?id=1286966
+
+   Back to 28; Grub2 Authentication
+
+   Two functions suffer from integer underflow fault; the grub_username_get() and grub_password_get()located in
+   grub-core/normal/auth.c and lib/crypto.c respectively. This can be exploited to obtain a Grub rescue shell.
+
+   Upstream-Status: Backport [http://git.savannah.gnu.org/cgit/grub.git/commit/?id=451d80e52d851432e109771bb8febafca7a5f1f2]
+   CVE: CVE-2015-8370
+   Signed-off-by: Joe Developer <joe.developer@example.com>

documentation/contributor-guide/report-defect.rst

@@ -0,0 +1,67 @@
+.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
+
+Reporting a Defect Against the Yocto Project and OpenEmbedded
+**************************************************************
+
+You can use the Yocto Project instance of
+`Bugzilla <https://www.bugzilla.org/about/>`__ to submit a defect (bug)
+against BitBake, OpenEmbedded-Core, against any other Yocto Project component
+or for tool issues. For additional information on this implementation of
+Bugzilla see the ":ref:`Yocto Project Bugzilla <resources-bugtracker>`" section
+in the Yocto Project Reference Manual. For more detail on any of the following
+steps, see the Yocto Project
+:yocto_wiki:`Bugzilla wiki page </Bugzilla_Configuration_and_Bug_Tracking>`.
+
+Use the following general steps to submit a bug:
+
+#.  Open the Yocto Project implementation of :yocto_bugs:`Bugzilla <>`.
+
+#.  Click "File a Bug" to enter a new bug.
+
+#.  Choose the appropriate "Classification", "Product", and "Component"
+    for which the bug was found. Bugs for the Yocto Project fall into
+    one of several classifications, which in turn break down into
+    several products and components. For example, for a bug against the
+    ``meta-intel`` layer, you would choose "Build System, Metadata &
+    Runtime", "BSPs", and "bsps-meta-intel", respectively.
+
+#.  Choose the "Version" of the Yocto Project for which you found the
+    bug (e.g. &DISTRO;).
+
+#.  Determine and select the "Severity" of the bug. The severity
+    indicates how the bug impacted your work.
+
+#.  Choose the "Hardware" that the bug impacts.
+
+#.  Choose the "Architecture" that the bug impacts.
+
+#.  Choose a "Documentation change" item for the bug. Fixing a bug might
+    or might not affect the Yocto Project documentation. If you are
+    unsure of the impact to the documentation, select "Don't Know".
+
+#.  Provide a brief "Summary" of the bug. Try to limit your summary to
+    just a line or two and be sure to capture the essence of the bug.
+
+#.  Provide a detailed "Description" of the bug. You should provide as
+    much detail as you can about the context, behavior, output, and so
+    forth that surrounds the bug. You can even attach supporting files
+    for output from logs by using the "Add an attachment" button.
+
+#.  Click the "Submit Bug" button submit the bug. A new Bugzilla number
+    is assigned to the bug and the defect is logged in the bug tracking
+    system.
+
+Once you file a bug, the bug is processed by the Yocto Project Bug
+Triage Team and further details concerning the bug are assigned (e.g.
+priority and owner). You are the "Submitter" of the bug and any further
+categorization, progress, or comments on the bug result in Bugzilla
+sending you an automated email concerning the particular change or
+progress to the bug.
+
+There are no guarantees about if or when a bug might be worked on since an
+open-source project has no dedicated engineering resources. However, the
+project does have a good track record of resolving common issues over the
+medium and long term. We do encourage people to file bugs so issues are
+at least known about. It helps other users when they find somebody having
+the same issue as they do, and an issue that is unknown is much less likely
+to ever be fixed!

documentation/contributor-guide/submit-changes.rst

@@ -0,0 +1,754 @@
+.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
+
+Contributing Changes to a Component
+************************************
+
+Contributions to the Yocto Project and OpenEmbedded are very welcome.
+Because the system is extremely configurable and flexible, we recognize
+that developers will want to extend, configure or optimize it for their
+specific uses.
+
+.. _ref-why-mailing-lists:
+
+Contributing through mailing lists --- Why not using web-based workflows?
+=========================================================================
+
+Both Yocto Project and OpenEmbedded have many key components that are
+maintained by patches being submitted on mailing lists. We appreciate this
+approach does look a little old fashioned when other workflows are available
+through web technology such as GitHub, GitLab and others. Since we are often
+asked this question, we’ve decided to document the reasons for using mailing
+lists.
+
+One significant factor is that we value peer review. When a change is proposed
+to many of the core pieces of the project, it helps to have many eyes of review
+go over them. Whilst there is ultimately one maintainer who needs to make the
+final call on accepting or rejecting a patch, the review is made by many eyes
+and the exact people reviewing it are likely unknown to the maintainer. It is
+often the surprise reviewer that catches the most interesting issues!
+
+This is in contrast to the "GitHub" style workflow where either just a
+maintainer makes that review, or review is specifically requested from
+nominated people. We believe there is significant value added to the codebase
+by this peer review and that moving away from mailing lists would be to the
+detriment of our code.
+
+We also need to acknowledge that many of our developers are used to this
+mailing list workflow and have worked with it for years, with tools and
+processes built around it. Changing away from this would result in a loss
+of key people from the project, which would again be to its detriment.
+
+The projects are acutely aware that potential new contributors find the
+mailing list approach off-putting and would prefer a web-based GUI.
+Since we don’t believe that can work for us, the project is aiming to ensure
+`patchwork <https://patchwork.yoctoproject.org/>`__ is available to help track
+patch status and also looking at how tooling can provide more feedback to users
+about patch status. We are looking at improving tools such as ``patchtest`` to
+test user contributions before they hit the mailing lists and also at better
+documenting how to use such workflows since we recognise that whilst this was
+common knowledge a decade ago, it might not be as familiar now.
+
+Preparing Changes for Submission
+================================
+
+Set up Git
+----------
+
+The first thing to do is to install Git packages. Here is an example
+on Debian and Ubuntu::
+
+   sudo aptitude install git-core git-email
+
+Then, you need to set a name and e-mail address that Git will
+use to identify your commits::
+
+   git config --global user.name "Ada Lovelace"
+   git config --global user.email "ada.lovelace@gmail.com"
+
+Clone the Git repository for the component to modify
+----------------------------------------------------
+
+After identifying the component to modify as described in the
+":doc:`../contributor-guide/identify-component`" section, clone the
+corresponding Git repository. Here is an example for OpenEmbedded-Core::
+
+  git clone https://git.openembedded.org/openembedded-core
+  cd openembedded-core
+
+Create a new branch
+-------------------
+
+Then, create a new branch in your local Git repository
+for your changes, starting from the reference branch in the upstream
+repository (often called ``master``)::
+
+   $ git checkout <ref-branch>
+   $ git checkout -b my-changes
+
+If you have completely unrelated sets of changes to submit, you should even
+create one branch for each set.
+
+Implement and commit changes
+----------------------------
+
+In each branch, you should group your changes into small, controlled and
+isolated ones. Keeping changes small and isolated aids review, makes
+merging/rebasing easier and keeps the change history clean should anyone need
+to refer to it in future.
+
+To this purpose, you should create *one Git commit per change*,
+corresponding to each of the patches you will eventually submit.
+See `further guidance <https://www.kernel.org/doc/html/latest/process/submitting-patches.html#separate-your-changes>`__
+in the Linux kernel documentation if needed.
+
+For example, when you intend to add multiple new recipes, each recipe
+should be added in a separate commit. For upgrades to existing recipes,
+the previous version should usually be deleted as part of the same commit
+to add the upgraded version.
+
+#. *Stage Your Changes:* Stage your changes by using the ``git add``
+   command on each file you modified. If you want to stage all the
+   files you modified, you can even use the ``git add -A`` command.
+
+#. *Commit Your Changes:* This is when you can create separate commits. For
+   each commit to create, use the ``git commit -s`` command with the files
+   or directories you want to include in the commit::
+
+      $ git commit -s file1 file2 dir1 dir2 ...
+
+   To include **a**\ ll staged files::
+
+      $ git commit -sa
+
+   -  The ``-s`` option of ``git commit`` adds a "Signed-off-by:" line
+      to your commit message. There is the same requirement for contributing
+      to the Linux kernel. Adding such a line signifies that you, the
+      submitter, have agreed to the `Developer's Certificate of Origin 1.1
+      <https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin>`__
+      as follows:
+
+      .. code-block:: none
+
+         Developer's Certificate of Origin 1.1
+
+         By making a contribution to this project, I certify that:
+
+         (a) The contribution was created in whole or in part by me and I
+             have the right to submit it under the open source license
+             indicated in the file; or
+
+         (b) The contribution is based upon previous work that, to the best
+             of my knowledge, is covered under an appropriate open source
+             license and I have the right under that license to submit that
+             work with modifications, whether created in whole or in part
+             by me, under the same open source license (unless I am
+             permitted to submit under a different license), as indicated
+             in the file; or
+
+         (c) The contribution was provided directly to me by some other
+             person who certified (a), (b) or (c) and I have not modified
+             it.
+
+         (d) I understand and agree that this project and the contribution
+             are public and that a record of the contribution (including all
+             personal information I submit with it, including my sign-off) is
+             maintained indefinitely and may be redistributed consistent with
+             this project or the open source license(s) involved.
+
+   -  Provide a single-line summary of the change and, if more
+      explanation is needed, provide more detail in the body of the
+      commit. This summary is typically viewable in the "shortlist" of
+      changes. Thus, providing something short and descriptive that
+      gives the reader a summary of the change is useful when viewing a
+      list of many commits. You should prefix this short description
+      with the recipe name (if changing a recipe), or else with the
+      short form path to the file being changed.
+
+      .. note::
+
+         To find a suitable prefix for the commit summary, a good idea
+         is to look for prefixes used in previous commits touching the
+         same files or directories::
+
+            git log --oneline <paths>
+
+   -  For the body of the commit message, provide detailed information
+      that describes what you changed, why you made the change, and the
+      approach you used. It might also be helpful if you mention how you
+      tested the change. Provide as much detail as you can in the body
+      of the commit message.
+
+      .. note::
+
+         If the single line summary is enough to describe a simple
+         change, the body of the commit message can be left empty.
+
+   -  If the change addresses a specific bug or issue that is associated
+      with a bug-tracking ID, include a reference to that ID in your
+      detailed description. For example, the Yocto Project uses a
+      specific convention for bug references --- any commit that addresses
+      a specific bug should use the following form for the detailed
+      description. Be sure to use the actual bug-tracking ID from
+      Bugzilla for bug-id::
+
+         Fixes [YOCTO #bug-id]
+
+         detailed description of change
+
+#. *Crediting contributors:* By using the ``git commit --amend`` command,
+   you can add some tags to the commit description to credit other contributors
+   to the change:
+
+   -  ``Reported-by``: name and email of a person reporting a bug
+      that your commit is trying to fix. This is a good practice
+      to encourage people to go on reporting bugs and let them
+      know that their reports are taken into account.
+
+   -  ``Suggested-by``: name and email of a person to credit for the
+      idea of making the change.
+
+   -  ``Tested-by``, ``Reviewed-by``: name and email for people having
+      tested your changes or reviewed their code. These fields are
+      usually added by the maintainer accepting a patch, or by
+      yourself if you submitted your patches to early reviewers,
+      or are submitting an unmodified patch again as part of a
+      new iteration of your patch series.
+
+   -  ``CC:`` Name and email of people you want to send a copy
+      of your changes to. This field will be used by ``git send-email``.
+
+   See `more guidance about using such tags
+   <https://www.kernel.org/doc/html/latest/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes>`__
+   in the Linux kernel documentation.
+
+Creating Patches
+================
+
+Here is the general procedure on how to create patches to be sent through email:
+
+#. *Describe the Changes in your Branch:* If you have more than one commit
+   in your branch, it's recommended to provide a cover letter describing
+   the series of patches you are about to send.
+
+   For this purpose, a good solution is to store the cover letter contents
+   in the branch itself::
+
+      git branch --edit-description
+
+   This will open a text editor to fill in the description for your
+   changes. This description can be updated when necessary and will
+   be used by Git to create the cover letter together with the patches.
+
+   It is recommended to start this description with a title line which
+   will serve a the subject line for the cover letter.
+
+#. *Generate Patches for your Branch:* The ``git format-patch`` command will
+   generate patch files for each of the commits in your branch. You need
+   to pass the reference branch your branch starts from.
+
+   If you branch didn't need a description in the previous step::
+
+      $ git format-patch <ref-branch>
+
+   If you filled a description for your branch, you will want to generate
+   a cover letter too::
+
+      $ git format-patch --cover-letter --cover-from-description=auto <ref-branch>
+
+   After the command is run, the current directory contains numbered
+   ``.patch`` files for the commits in your branch. If you have a cover
+   letter, it will be in the ``0000-cover-letter.patch``.
+
+   .. note::
+
+      The ``--cover-from-description=auto`` option makes ``git format-patch``
+      use the first paragraph of the branch description as the cover
+      letter title. Another possibility, which is easier to remember, is to pass
+      only the ``--cover-letter`` option, but you will have to edit the
+      subject line manually every time you generate the patches.
+
+      See the `git format-patch manual page <https://git-scm.com/docs/git-format-patch>`__
+      for details.
+
+#. *Review each of the Patch Files:* This final review of the patches
+   before sending them often allows to view your changes from a different
+   perspective and discover defects such as typos, spacing issues or lines
+   or even files that you didn't intend to modify. This review should
+   include the cover letter patch too.
+
+   If necessary, rework your commits as described in
+   ":ref:`contributor-guide/submit-changes:taking patch review into account`".
+
+Sending the Patches via Email
+=============================
+
+Using Git to Send Patches
+-------------------------
+
+To submit patches through email, it is very important that you send them
+without any whitespace or HTML formatting that either you or your mailer
+introduces. The maintainer that receives your patches needs to be able
+to save and apply them directly from your emails, using the ``git am``
+command.
+
+Using the ``git send-email`` command is the only error-proof way of sending
+your patches using email since there is no risk of compromising whitespace
+in the body of the message, which can occur when you use your own mail
+client. It will also properly include your patches as *inline attachments*,
+which is not easy to do with standard e-mail clients without breaking lines.
+If you used your regular e-mail client and shared your patches as regular
+attachments, reviewers wouldn't be able to quote specific sections of your
+changes and make comments about them.
+
+Setting up Git to Send Email
+----------------------------
+
+The ``git send-email`` command can send email by using a local or remote
+Mail Transport Agent (MTA) such as ``msmtp``, ``sendmail``, or
+through a direct SMTP configuration in your Git ``~/.gitconfig`` file.
+
+Here are the settings for letting ``git send-email`` send e-mail through your
+regular STMP server, using a Google Mail account as an example::
+
+   git config --global sendemail.smtpserver smtp.gmail.com
+   git config --global sendemail.smtpserverport 587
+   git config --global sendemail.smtpencryption tls
+   git config --global sendemail.smtpuser ada.lovelace@gmail.com
+   git config --global sendemail.smtppass = XXXXXXXX
+
+These settings will appear in the ``.gitconfig`` file in your home directory.
+
+If you neither can use a local MTA nor SMTP,  make sure you use an email client
+that does not touch the message (turning spaces in tabs, wrapping lines, etc.).
+A good mail client to do so is Pine (or Alpine) or Mutt. For more
+information about suitable clients, see `Email clients info for Linux
+<https://www.kernel.org/doc/html/latest/process/email-clients.html>`__
+in the Linux kernel sources.
+
+If you use such clients, just include the patch in the body of your email.
+
+Finding a Suitable Mailing List
+-------------------------------
+
+You should send patches to the appropriate mailing list so that they can be
+reviewed by the right contributors and merged by the appropriate maintainer.
+The specific mailing list you need to use depends on the location of the code
+you are changing.
+
+If people have concerns with any of the patches, they will usually voice
+their concern over the mailing list. If patches do not receive any negative
+reviews, the maintainer of the affected layer typically takes them, tests them,
+and then based on successful testing, merges them.
+
+In general, each component (e.g. layer) should have a ``README`` file
+that indicates where to send the changes and which process to follow.
+
+The "poky" repository, which is the Yocto Project's reference build
+environment, is a hybrid repository that contains several individual
+pieces (e.g. BitBake, Metadata, documentation, and so forth) built using
+the combo-layer tool. The upstream location used for submitting changes
+varies by component:
+
+-  *Core Metadata:* Send your patches to the
+   :oe_lists:`openembedded-core </g/openembedded-core>`
+   mailing list. For example, a change to anything under the ``meta`` or
+   ``scripts`` directories should be sent to this mailing list.
+
+-  *BitBake:* For changes to BitBake (i.e. anything under the
+   ``bitbake`` directory), send your patches to the
+   :oe_lists:`bitbake-devel </g/bitbake-devel>`
+   mailing list.
+
+-  *"meta-\*" trees:* These trees contain Metadata. Use the
+   :yocto_lists:`poky </g/poky>` mailing list.
+
+-  *Documentation*: For changes to the Yocto Project documentation, use the
+   :yocto_lists:`docs </g/docs>` mailing list.
+
+For changes to other layers and tools hosted in the Yocto Project source
+repositories (i.e. :yocto_git:`git.yoctoproject.org <>`), use the
+:yocto_lists:`yocto </g/yocto/>` general mailing list.
+
+For changes to other layers hosted in the OpenEmbedded source
+repositories (i.e. :oe_git:`git.openembedded.org <>`), use
+the :oe_lists:`openembedded-devel </g/openembedded-devel>`
+mailing list, unless specified otherwise in the layer's ``README`` file.
+
+If you intend to submit a new recipe that neither fits into the core Metadata,
+nor into :oe_git:`meta-openembedded </meta-openembedded/>`, you should
+look for a suitable layer in https://layers.openembedded.org. If similar
+recipes can be expected, you may consider :ref:`dev-manual/layers:creating your own layer`.
+
+If in doubt, please ask on the :yocto_lists:`yocto </g/yocto/>` general mailing list
+or on the :oe_lists:`openembedded-devel </g/openembedded-devel>` mailing list.
+
+Subscribing to the Mailing List
+-------------------------------
+
+After identifying the right mailing list to use, you will have to subscribe to
+it if you haven't done it yet.
+
+If you attempt to send patches to a list you haven't subscribed to, your email
+will be returned as undelivered.
+
+However, if you don't want to be receive all the messages sent to a mailing list,
+you can set your subscription to "no email". You will still be a subscriber able
+to send messages, but you won't receive any e-mail. If people reply to your message,
+their e-mail clients will default to including your email address in the
+conversation anyway.
+
+Anyway, you'll also be able to access the new messages on mailing list archives,
+either through a web browser, or for the lists archived on https://lore.kernelorg,
+through an individual newsgroup feed or a git repository.
+
+Sending Patches via Email
+-------------------------
+
+At this stage, you are ready to send your patches via email. Here's the
+typical usage of ``git send-email``::
+
+   git send-email --to <mailing-list-address> *.patch
+
+Then, review each subject line and list of recipients carefully, and then
+and then allow the command to send each message.
+
+You will see that ``git send-email`` will automatically copy the people listed
+in any commit tags such as ``Signed-off-by`` or ``Reported-by``.
+
+In case you are sending patches for :oe_git:`meta-openembedded </meta-openembedded/>`
+or any layer other than :oe_git:`openembedded-core </openembedded-core/>`,
+please add the appropriate prefix so that it is clear which layer the patch is intended
+to be applied to::
+
+   git send-email --subject-prefix="meta-oe][PATCH" ...
+
+.. note::
+
+   It is actually possible to send patches without generating them
+   first. However, make sure you have reviewed your changes carefully
+   because ``git send-email`` will just show you the title lines of
+   each patch.
+
+   Here's a command you can use if you just have one patch in your
+   branch::
+
+      git send-email --to <mailing-list-address> -1
+
+   If you have multiple patches and a cover letter, you can send
+   patches for all the commits between the reference branch
+   and the tip of your branch::
+
+      git send-email --cover-letter --cover-from-description=auto --to <mailing-list-address> -M <ref-branch>
+
+See the `git send-email manual page <https://git-scm.com/docs/git-send-email>`__
+for details.
+
+Troubleshooting Email Issues
+----------------------------
+
+Fixing your From identity
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+We have a frequent issue with contributors whose patches are received through
+a ``From`` field which doesn't match the ``Signed-off-by`` information. Here is
+a typical example for people sending from a domain name with :wikipedia:`DMARC`::
+
+   From: "Linus Torvalds via lists.openembedded.org <linus.torvalds=kernel.org@lists.openembedded.org>"
+
+This ``From`` field is used by ``git am`` to recreate commits with the right
+author name. The following will ensure that your e-mails have an additional
+``From`` field at the beginning of the Email body, and therefore that
+maintainers accepting your patches don't have to fix commit author information
+manually::
+
+   git config --global sendemail.from "linus.torvalds@kernel.org"
+
+The ``sendemail.from`` should match your ``user.email`` setting,
+which appears in the ``Signed-off-by`` line of your commits.
+
+Streamlining git send-email usage
+---------------------------------
+
+If you want to save time and not be forced to remember the right options to use
+with ``git send-email``, you can use Git configuration settings.
+
+-  To set the right mailing list address for a given repository::
+
+      git config --local sendemail.to openembedded-devel@lists.openembedded.org
+
+-  If the mailing list requires a subject prefix for the layer
+   (this only works when the repository only contains one layer)::
+
+      git config --local format.subjectprefix "meta-something][PATCH"
+
+Using Scripts to Push a Change Upstream and Request a Pull
+==========================================================
+
+For larger patch series it is preferable to send a pull request which not
+only includes the patch but also a pointer to a branch that can be pulled
+from. This involves making a local branch for your changes, pushing this
+branch to an accessible repository and then using the ``create-pull-request``
+and ``send-pull-request`` scripts from openembedded-core to create and send a
+patch series with a link to the branch for review.
+
+Follow this procedure to push a change to an upstream "contrib" Git
+repository once the steps in
+":ref:`contributor-guide/submit-changes:preparing changes for submission`"
+have been followed:
+
+.. note::
+
+   You can find general Git information on how to push a change upstream
+   in the
+   `Git Community Book <https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows>`__.
+
+#. *Request Push Access to an "Upstream" Contrib Repository:* Send an email to
+   ``helpdesk@yoctoproject.org``:
+
+    -  Attach your SSH public key which usually named ``id_rsa.pub.``.
+       If you don't have one generate it by running ``ssh-keygen -t rsa -b 4096 -C "your_email@example.com"``.
+
+    -  List the repositories you're planning to contribute to.
+
+    -  Include your preferred branch prefix for ``-contrib`` repositories.
+
+#. *Push Your Commits to the "Contrib" Upstream:* Push your
+   changes to that repository::
+
+      $ git push upstream_remote_repo local_branch_name
+
+   For example, suppose you have permissions to push
+   into the upstream ``meta-intel-contrib`` repository and you are
+   working in a local branch named `your_name`\ ``/README``. The following
+   command pushes your local commits to the ``meta-intel-contrib``
+   upstream repository and puts the commit in a branch named
+   `your_name`\ ``/README``::
+
+      $ git push meta-intel-contrib your_name/README
+
+#. *Determine Who to Notify:* Determine the maintainer or the mailing
+   list that you need to notify for the change.
+
+   Before submitting any change, you need to be sure who the maintainer
+   is or what mailing list that you need to notify. Use either these
+   methods to find out:
+
+   -  *Maintenance File:* Examine the ``maintainers.inc`` file, which is
+      located in the :term:`Source Directory` at
+      ``meta/conf/distro/include``, to see who is responsible for code.
+
+   -  *Search by File:* Using :ref:`overview-manual/development-environment:git`, you can
+      enter the following command to bring up a short list of all
+      commits against a specific file::
+
+         git shortlog -- filename
+
+      Just provide the name of the file for which you are interested. The
+      information returned is not ordered by history but does include a
+      list of everyone who has committed grouped by name. From the list,
+      you can see who is responsible for the bulk of the changes against
+      the file.
+
+   -  *Find the Mailing List to Use:* See the
+      ":ref:`contributor-guide/submit-changes:finding a suitable mailing list`"
+      section above.
+
+#. *Make a Pull Request:* Notify the maintainer or the mailing list that
+   you have pushed a change by making a pull request.
+
+   The Yocto Project provides two scripts that conveniently let you
+   generate and send pull requests to the Yocto Project. These scripts
+   are ``create-pull-request`` and ``send-pull-request``. You can find
+   these scripts in the ``scripts`` directory within the
+   :term:`Source Directory` (e.g.
+   ``poky/scripts``).
+
+   Using these scripts correctly formats the requests without
+   introducing any whitespace or HTML formatting. The maintainer that
+   receives your patches either directly or through the mailing list
+   needs to be able to save and apply them directly from your emails.
+   Using these scripts is the preferred method for sending patches.
+
+   First, create the pull request. For example, the following command
+   runs the script, specifies the upstream repository in the contrib
+   directory into which you pushed the change, and provides a subject
+   line in the created patch files::
+
+      $ poky/scripts/create-pull-request -u meta-intel-contrib -s "Updated Manual Section Reference in README"
+
+   Running this script forms ``*.patch`` files in a folder named
+   ``pull-``\ `PID` in the current directory. One of the patch files is a
+   cover letter.
+
+   Before running the ``send-pull-request`` script, you must edit the
+   cover letter patch to insert information about your change. After
+   editing the cover letter, send the pull request. For example, the
+   following command runs the script and specifies the patch directory
+   and email address. In this example, the email address is a mailing
+   list::
+
+      $ poky/scripts/send-pull-request -p ~/meta-intel/pull-10565 -t meta-intel@lists.yoctoproject.org
+
+   You need to follow the prompts as the script is interactive.
+
+   .. note::
+
+      For help on using these scripts, simply provide the ``-h``
+      argument as follows::
+
+              $ poky/scripts/create-pull-request -h
+              $ poky/scripts/send-pull-request -h
+
+Submitting Changes to Stable Release Branches
+=============================================
+
+The process for proposing changes to a Yocto Project stable branch differs
+from the steps described above. Changes to a stable branch must address
+identified bugs or CVEs and should be made carefully in order to avoid the
+risk of introducing new bugs or breaking backwards compatibility. Typically
+bug fixes must already be accepted into the master branch before they can be
+backported to a stable branch unless the bug in question does not affect the
+master branch or the fix on the master branch is unsuitable for backporting.
+
+The list of stable branches along with the status and maintainer for each
+branch can be obtained from the
+:yocto_wiki:`Releases wiki page </Releases>`.
+
+.. note::
+
+   Changes will not typically be accepted for branches which are marked as
+   End-Of-Life (EOL).
+
+With this in mind, the steps to submit a change for a stable branch are as
+follows:
+
+#. *Identify the bug or CVE to be fixed:* This information should be
+   collected so that it can be included in your submission.
+
+   See :ref:`dev-manual/vulnerabilities:checking for vulnerabilities`
+   for details about CVE tracking.
+
+#. *Check if the fix is already present in the master branch:* This will
+   result in the most straightforward path into the stable branch for the
+   fix.
+
+   #. *If the fix is present in the master branch --- submit a backport request
+      by email:* You should send an email to the relevant stable branch
+      maintainer and the mailing list with details of the bug or CVE to be
+      fixed, the commit hash on the master branch that fixes the issue and
+      the stable branches which you would like this fix to be backported to.
+
+   #. *If the fix is not present in the master branch --- submit the fix to the
+      master branch first:* This will ensure that the fix passes through the
+      project's usual patch review and test processes before being accepted.
+      It will also ensure that bugs are not left unresolved in the master
+      branch itself. Once the fix is accepted in the master branch a backport
+      request can be submitted as above.
+
+   #. *If the fix is unsuitable for the master branch --- submit a patch
+      directly for the stable branch:* This method should be considered as a
+      last resort. It is typically necessary when the master branch is using
+      a newer version of the software which includes an upstream fix for the
+      issue or when the issue has been fixed on the master branch in a way
+      that introduces backwards incompatible changes. In this case follow the
+      steps in ":ref:`contributor-guide/submit-changes:preparing changes for submission`"
+      and in the following sections but modify the subject header of your patch
+      email to include the name of the stable branch which you are
+      targetting. This can be done using the ``--subject-prefix`` argument to
+      ``git format-patch``, for example to submit a patch to the
+      "&DISTRO_NAME_NO_CAP_MINUS_ONE;" branch use::
+
+         git format-patch --subject-prefix='&DISTRO_NAME_NO_CAP_MINUS_ONE;][PATCH' ...
+
+Taking Patch Review into Account
+================================
+
+You may get feedback on your submitted patches from other community members
+or from the automated patchtest service. If issues are identified in your
+patches then it is usually necessary to address these before the patches are
+accepted into the project. In this case you should your commits according
+to the feedback and submit an updated version to the relevant mailing list.
+
+In any case, never fix reported issues by fixing them in new commits
+on the tip of your branch. Always come up with a new series of commits
+without the reported issues.
+
+.. note::
+
+   It is a good idea to send a copy to the reviewers who provided feedback
+   to the previous version of the patch. You can make sure this happens
+   by adding a ``CC`` tag to the commit description::
+
+      CC: William Shakespeare <bill@yoctoproject.org>
+
+A single patch can be amended using ``git commit --amend``, and multiple
+patches can be easily reworked and reordered through an interactive Git rebase::
+
+   git rebase -i <ref-branch>
+
+See `this tutorial <https://hackernoon.com/beginners-guide-to-interactive-rebasing-346a3f9c3a6d>`__
+for practical guidance about using Git interactive rebasing.
+
+You should also modify the ``[PATCH]`` tag in the email subject line when
+sending the revised patch to mark the new iteration as ``[PATCH v2]``,
+``[PATCH v3]``, etc as appropriate. This can be done by passing the ``-v``
+argument to ``git format-patch`` with a version number::
+
+   git format-patch -v2 <ref-branch>
+
+Lastly please ensure that you also test your revised changes. In particular
+please don't just edit the patch file written out by ``git format-patch`` and
+resend it.
+
+Tracking the Status of Patches
+==============================
+
+The Yocto Project uses a `Patchwork instance <https://patchwork.yoctoproject.org/>`__
+to track the status of patches submitted to the various mailing lists and to
+support automated patch testing. Each submitted patch is checked for common
+mistakes and deviations from the expected patch format and submitters are
+notified by ``patchtest`` if such mistakes are found. This process helps to
+reduce the burden of patch review on maintainers.
+
+.. note::
+
+   This system is imperfect and changes can sometimes get lost in the flow.
+   Asking about the status of a patch or change is reasonable if the change
+   has been idle for a while with no feedback.
+
+If your patches have not had any feedback in a few days, they may have already
+been merged. You can run ``git pull``  branch to check this. Note that many if
+not most layer maintainers do not send out acknowledgement emails when they
+accept patches. Alternatively, if there is no response or merge after a few days
+the patch may have been missed or the appropriate reviewers may not currently be
+around. It is then perfectly fine to reply to it yourself with a reminder asking
+for feedback.
+
+.. note::
+
+      Patch reviews for feature and recipe upgrade patches are likely be delayed
+      during a feature freeze because these types of patches aren't merged during
+      at that time --- you may have to wait until after the freeze is lifted.
+
+Maintainers also commonly use ``-next`` branches to test submissions prior to
+merging patches. Thus, you can get an idea of the status of a patch based on
+whether the patch has been merged into one of these branches. The commonly
+used testing branches for OpenEmbedded-Core are as follows:
+
+-  *openembedded-core "master-next" branch:* This branch is part of the
+   :oe_git:`openembedded-core </openembedded-core/>` repository and contains
+   proposed changes to the core metadata.
+
+-  *poky "master-next" branch:* This branch is part of the
+   :yocto_git:`poky </poky/>` repository and combines proposed
+   changes to BitBake, the core metadata and the poky distro.
+
+Similarly, stable branches maintained by the project may have corresponding
+``-next`` branches which collect proposed changes. For example,
+``&DISTRO_NAME_NO_CAP;-next`` and ``&DISTRO_NAME_NO_CAP_MINUS_ONE;-next``
+branches in both the "openembdedded-core" and "poky" repositories.
+
+Other layers may have similar testing branches but there is no formal
+requirement or standard for these so please check the documentation for the
+layers you are contributing to.
+

documentation/dev-manual/building.rst

@@ -273,12 +273,12 @@ loading modules needed to locate and mount the final root filesystem.
 
 Follow these steps to create an :term:`Initramfs` image:
 
-#. *Create the :term:`Initramfs` Image Recipe:* You can reference the
+#. *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.
 
-#. *Decide if You Need to Bundle the :term:`Initramfs` Image Into the Kernel
+#. *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

documentation/dev-manual/changes.rst

@@ -1,525 +0,0 @@
-.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
-
-Making Changes to the Yocto Project
-***********************************
-
-Because the Yocto Project is an open-source, community-based project,
-you can effect changes to the project. This section presents procedures
-that show you how to submit a defect against the project and how to
-submit a change.
-
-Submitting a Defect Against the Yocto Project
-=============================================
-
-Use the Yocto Project implementation of
-`Bugzilla <https://www.bugzilla.org/about/>`__ to submit a defect (bug)
-against the Yocto Project. For additional information on this
-implementation of Bugzilla see the ":ref:`Yocto Project
-Bugzilla <resources-bugtracker>`" section in the
-Yocto Project Reference Manual. For more detail on any of the following
-steps, see the Yocto Project
-:yocto_wiki:`Bugzilla wiki page </Bugzilla_Configuration_and_Bug_Tracking>`.
-
-Use the following general steps to submit a bug:
-
-#.  Open the Yocto Project implementation of :yocto_bugs:`Bugzilla <>`.
-
-#.  Click "File a Bug" to enter a new bug.
-
-#.  Choose the appropriate "Classification", "Product", and "Component"
-    for which the bug was found. Bugs for the Yocto Project fall into
-    one of several classifications, which in turn break down into
-    several products and components. For example, for a bug against the
-    ``meta-intel`` layer, you would choose "Build System, Metadata &
-    Runtime", "BSPs", and "bsps-meta-intel", respectively.
-
-#.  Choose the "Version" of the Yocto Project for which you found the
-    bug (e.g. &DISTRO;).
-
-#.  Determine and select the "Severity" of the bug. The severity
-    indicates how the bug impacted your work.
-
-#.  Choose the "Hardware" that the bug impacts.
-
-#.  Choose the "Architecture" that the bug impacts.
-
-#.  Choose a "Documentation change" item for the bug. Fixing a bug might
-    or might not affect the Yocto Project documentation. If you are
-    unsure of the impact to the documentation, select "Don't Know".
-
-#.  Provide a brief "Summary" of the bug. Try to limit your summary to
-    just a line or two and be sure to capture the essence of the bug.
-
-#.  Provide a detailed "Description" of the bug. You should provide as
-    much detail as you can about the context, behavior, output, and so
-    forth that surrounds the bug. You can even attach supporting files
-    for output from logs by using the "Add an attachment" button.
-
-#.  Click the "Submit Bug" button submit the bug. A new Bugzilla number
-    is assigned to the bug and the defect is logged in the bug tracking
-    system.
-
-Once you file a bug, the bug is processed by the Yocto Project Bug
-Triage Team and further details concerning the bug are assigned (e.g.
-priority and owner). You are the "Submitter" of the bug and any further
-categorization, progress, or comments on the bug result in Bugzilla
-sending you an automated email concerning the particular change or
-progress to the bug.
-
-Submitting a Change to the Yocto Project
-========================================
-
-Contributions to the Yocto Project and OpenEmbedded are very welcome.
-Because the system is extremely configurable and flexible, we recognize
-that developers will want to extend, configure or optimize it for their
-specific uses.
-
-The Yocto Project uses a mailing list and a patch-based workflow that is
-similar to the Linux kernel but contains important differences. In
-general, there is a mailing list through which you can submit patches. You
-should send patches to the appropriate mailing list so that they can be
-reviewed and merged by the appropriate maintainer. The specific mailing
-list you need to use depends on the location of the code you are
-changing. Each component (e.g. layer) should have a ``README`` file that
-indicates where to send the changes and which process to follow.
-
-You can send the patch to the mailing list using whichever approach you
-feel comfortable with to generate the patch. Once sent, the patch is
-usually reviewed by the community at large. If somebody has concerns
-with the patch, they will usually voice their concern over the mailing
-list. If a patch does not receive any negative reviews, the maintainer
-of the affected layer typically takes the patch, tests it, and then
-based on successful testing, merges the patch.
-
-The "poky" repository, which is the Yocto Project's reference build
-environment, is a hybrid repository that contains several individual
-pieces (e.g. BitBake, Metadata, documentation, and so forth) built using
-the combo-layer tool. The upstream location used for submitting changes
-varies by component:
-
--  *Core Metadata:* Send your patch to the
-   :oe_lists:`openembedded-core </g/openembedded-core>`
-   mailing list. For example, a change to anything under the ``meta`` or
-   ``scripts`` directories should be sent to this mailing list.
-
--  *BitBake:* For changes to BitBake (i.e. anything under the
-   ``bitbake`` directory), send your patch to the
-   :oe_lists:`bitbake-devel </g/bitbake-devel>`
-   mailing list.
-
--  *"meta-\*" trees:* These trees contain Metadata. Use the
-   :yocto_lists:`poky </g/poky>` mailing list.
-
--  *Documentation*: For changes to the Yocto Project documentation, use the
-   :yocto_lists:`docs </g/docs>` mailing list.
-
-For changes to other layers hosted in the Yocto Project source
-repositories (i.e. ``yoctoproject.org``) and tools use the
-:yocto_lists:`Yocto Project </g/yocto/>` general mailing list.
-
-.. note::
-
-   Sometimes a layer's documentation specifies to use a particular
-   mailing list. If so, use that list.
-
-For additional recipes that do not fit into the core Metadata, you
-should determine which layer the recipe should go into and submit the
-change in the manner recommended by the documentation (e.g. the
-``README`` file) supplied with the layer. If in doubt, please ask on the
-Yocto general mailing list or on the openembedded-devel mailing list.
-
-You can also push a change upstream and request a maintainer to pull the
-change into the component's upstream repository. You do this by pushing
-to a contribution repository that is upstream. See the
-":ref:`overview-manual/development-environment:git workflows and the yocto project`"
-section in the Yocto Project Overview and Concepts Manual for additional
-concepts on working in the Yocto Project development environment.
-
-Maintainers commonly use ``-next`` branches to test submissions prior to
-merging patches. Thus, you can get an idea of the status of a patch based on
-whether the patch has been merged into one of these branches. The commonly
-used testing branches for OpenEmbedded-Core are as follows:
-
--  *openembedded-core "master-next" branch:* This branch is part of the
-   :oe_git:`openembedded-core </openembedded-core/>` repository and contains
-   proposed changes to the core metadata.
-
--  *poky "master-next" branch:* This branch is part of the
-   :yocto_git:`poky </poky/>` repository and combines proposed
-   changes to BitBake, the core metadata and the poky distro.
-
-Similarly, stable branches maintained by the project may have corresponding
-``-next`` branches which collect proposed changes. For example,
-``&DISTRO_NAME_NO_CAP;-next`` and ``&DISTRO_NAME_NO_CAP_MINUS_ONE;-next``
-branches in both the "openembdedded-core" and "poky" repositories.
-
-Other layers may have similar testing branches but there is no formal
-requirement or standard for these so please check the documentation for the
-layers you are contributing to.
-
-The following sections provide procedures for submitting a change.
-
-Preparing Changes for Submission
---------------------------------
-
-#. *Make Your Changes Locally:* Make your changes in your local Git
-   repository. You should make small, controlled, isolated changes.
-   Keeping changes small and isolated aids review, makes
-   merging/rebasing easier and keeps the change history clean should
-   anyone need to refer to it in future.
-
-#. *Stage Your Changes:* Stage your changes by using the ``git add``
-   command on each file you changed.
-
-#. *Commit Your Changes:* Commit the change by using the ``git commit``
-   command. Make sure your commit information follows standards by
-   following these accepted conventions:
-
-   -  Be sure to include a "Signed-off-by:" line in the same style as
-      required by the Linux kernel. This can be done by using the
-      ``git commit -s`` command. Adding this line signifies that you,
-      the submitter, have agreed to the Developer's Certificate of
-      Origin 1.1 as follows:
-
-      .. code-block:: none
-
-         Developer's Certificate of Origin 1.1
-
-         By making a contribution to this project, I certify that:
-
-         (a) The contribution was created in whole or in part by me and I
-             have the right to submit it under the open source license
-             indicated in the file; or
-
-         (b) The contribution is based upon previous work that, to the best
-             of my knowledge, is covered under an appropriate open source
-             license and I have the right under that license to submit that
-             work with modifications, whether created in whole or in part
-             by me, under the same open source license (unless I am
-             permitted to submit under a different license), as indicated
-             in the file; or
-
-         (c) The contribution was provided directly to me by some other
-             person who certified (a), (b) or (c) and I have not modified
-             it.
-
-         (d) I understand and agree that this project and the contribution
-             are public and that a record of the contribution (including all
-             personal information I submit with it, including my sign-off) is
-             maintained indefinitely and may be redistributed consistent with
-             this project or the open source license(s) involved.
-
-   -  Provide a single-line summary of the change and, if more
-      explanation is needed, provide more detail in the body of the
-      commit. This summary is typically viewable in the "shortlist" of
-      changes. Thus, providing something short and descriptive that
-      gives the reader a summary of the change is useful when viewing a
-      list of many commits. You should prefix this short description
-      with the recipe name (if changing a recipe), or else with the
-      short form path to the file being changed.
-
-   -  For the body of the commit message, provide detailed information
-      that describes what you changed, why you made the change, and the
-      approach you used. It might also be helpful if you mention how you
-      tested the change. Provide as much detail as you can in the body
-      of the commit message.
-
-      .. note::
-
-         You do not need to provide a more detailed explanation of a
-         change if the change is minor to the point of the single line
-         summary providing all the information.
-
-   -  If the change addresses a specific bug or issue that is associated
-      with a bug-tracking ID, include a reference to that ID in your
-      detailed description. For example, the Yocto Project uses a
-      specific convention for bug references --- any commit that addresses
-      a specific bug should use the following form for the detailed
-      description. Be sure to use the actual bug-tracking ID from
-      Bugzilla for bug-id::
-
-         Fixes [YOCTO #bug-id]
-
-         detailed description of change
-
-Using Email to Submit a Patch
------------------------------
-
-Depending on the components changed, you need to submit the email to a
-specific mailing list. For some guidance on which mailing list to use,
-see the
-:ref:`list <dev-manual/changes:submitting a change to the yocto project>`
-at the beginning of this section. For a description of all the available
-mailing lists, see the ":ref:`Mailing Lists <resources-mailinglist>`" section in the
-Yocto Project Reference Manual.
-
-Here is the general procedure on how to submit a patch through email
-without using the scripts once the steps in
-:ref:`dev-manual/changes:preparing changes for submission` have been followed:
-
-#. *Format the Commit:* Format the commit into an email message. To
-   format commits, use the ``git format-patch`` command. When you
-   provide the command, you must include a revision list or a number of
-   patches as part of the command. For example, either of these two
-   commands takes your most recent single commit and formats it as an
-   email message in the current directory::
-
-      $ git format-patch -1
-
-   or ::
-
-      $ git format-patch HEAD~
-
-   After the command is run, the current directory contains a numbered
-   ``.patch`` file for the commit.
-
-   If you provide several commits as part of the command, the
-   ``git format-patch`` command produces a series of numbered files in
-   the current directory – one for each commit. If you have more than
-   one patch, you should also use the ``--cover`` option with the
-   command, which generates a cover letter as the first "patch" in the
-   series. You can then edit the cover letter to provide a description
-   for the series of patches. For information on the
-   ``git format-patch`` command, see ``GIT_FORMAT_PATCH(1)`` displayed
-   using the ``man git-format-patch`` command.
-
-   .. note::
-
-      If you are or will be a frequent contributor to the Yocto Project
-      or to OpenEmbedded, you might consider requesting a contrib area
-      and the necessary associated rights.
-
-#. *Send the patches via email:* Send the patches to the recipients and
-   relevant mailing lists by using the ``git send-email`` command.
-
-   .. note::
-
-      In order to use ``git send-email``, you must have the proper Git packages
-      installed on your host.
-      For Ubuntu, Debian, and Fedora the package is ``git-email``.
-
-   The ``git send-email`` command sends email by using a local or remote
-   Mail Transport Agent (MTA) such as ``msmtp``, ``sendmail``, or
-   through a direct ``smtp`` configuration in your Git ``~/.gitconfig``
-   file. If you are submitting patches through email only, it is very
-   important that you submit them without any whitespace or HTML
-   formatting that either you or your mailer introduces. The maintainer
-   that receives your patches needs to be able to save and apply them
-   directly from your emails. A good way to verify that what you are
-   sending will be applicable by the maintainer is to do a dry run and
-   send them to yourself and then save and apply them as the maintainer
-   would.
-
-   The ``git send-email`` command is the preferred method for sending
-   your patches using email since there is no risk of compromising
-   whitespace in the body of the message, which can occur when you use
-   your own mail client. The command also has several options that let
-   you specify recipients and perform further editing of the email
-   message. For information on how to use the ``git send-email``
-   command, see ``GIT-SEND-EMAIL(1)`` displayed using the
-   ``man git-send-email`` command.
-
-The Yocto Project uses a `Patchwork instance <https://patchwork.openembedded.org/>`__
-to track the status of patches submitted to the various mailing lists and to
-support automated patch testing. Each submitted patch is checked for common
-mistakes and deviations from the expected patch format and submitters are
-notified by patchtest if such mistakes are found. This process helps to
-reduce the burden of patch review on maintainers.
-
-.. note::
-
-   This system is imperfect and changes can sometimes get lost in the flow.
-   Asking about the status of a patch or change is reasonable if the change
-   has been idle for a while with no feedback.
-
-Using Scripts to Push a Change Upstream and Request a Pull
-----------------------------------------------------------
-
-For larger patch series it is preferable to send a pull request which not
-only includes the patch but also a pointer to a branch that can be pulled
-from. This involves making a local branch for your changes, pushing this
-branch to an accessible repository and then using the ``create-pull-request``
-and ``send-pull-request`` scripts from openembedded-core to create and send a
-patch series with a link to the branch for review.
-
-Follow this procedure to push a change to an upstream "contrib" Git
-repository once the steps in :ref:`dev-manual/changes:preparing changes for submission` have
-been followed:
-
-.. note::
-
-   You can find general Git information on how to push a change upstream
-   in the
-   `Git Community Book <https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows>`__.
-
-#. *Push Your Commits to a "Contrib" Upstream:* If you have arranged for
-   permissions to push to an upstream contrib repository, push the
-   change to that repository::
-
-      $ git push upstream_remote_repo local_branch_name
-
-   For example, suppose you have permissions to push
-   into the upstream ``meta-intel-contrib`` repository and you are
-   working in a local branch named `your_name`\ ``/README``. The following
-   command pushes your local commits to the ``meta-intel-contrib``
-   upstream repository and puts the commit in a branch named
-   `your_name`\ ``/README``::
-
-      $ git push meta-intel-contrib your_name/README
-
-#. *Determine Who to Notify:* Determine the maintainer or the mailing
-   list that you need to notify for the change.
-
-   Before submitting any change, you need to be sure who the maintainer
-   is or what mailing list that you need to notify. Use either these
-   methods to find out:
-
-   -  *Maintenance File:* Examine the ``maintainers.inc`` file, which is
-      located in the :term:`Source Directory` at
-      ``meta/conf/distro/include``, to see who is responsible for code.
-
-   -  *Search by File:* Using :ref:`overview-manual/development-environment:git`, you can
-      enter the following command to bring up a short list of all
-      commits against a specific file::
-
-         git shortlog -- filename
-
-      Just provide the name of the file for which you are interested. The
-      information returned is not ordered by history but does include a
-      list of everyone who has committed grouped by name. From the list,
-      you can see who is responsible for the bulk of the changes against
-      the file.
-
-   -  *Examine the List of Mailing Lists:* For a list of the Yocto
-      Project and related mailing lists, see the ":ref:`Mailing
-      lists <resources-mailinglist>`" section in
-      the Yocto Project Reference Manual.
-
-#. *Make a Pull Request:* Notify the maintainer or the mailing list that
-   you have pushed a change by making a pull request.
-
-   The Yocto Project provides two scripts that conveniently let you
-   generate and send pull requests to the Yocto Project. These scripts
-   are ``create-pull-request`` and ``send-pull-request``. You can find
-   these scripts in the ``scripts`` directory within the
-   :term:`Source Directory` (e.g.
-   ``poky/scripts``).
-
-   Using these scripts correctly formats the requests without
-   introducing any whitespace or HTML formatting. The maintainer that
-   receives your patches either directly or through the mailing list
-   needs to be able to save and apply them directly from your emails.
-   Using these scripts is the preferred method for sending patches.
-
-   First, create the pull request. For example, the following command
-   runs the script, specifies the upstream repository in the contrib
-   directory into which you pushed the change, and provides a subject
-   line in the created patch files::
-
-      $ poky/scripts/create-pull-request -u meta-intel-contrib -s "Updated Manual Section Reference in README"
-
-   Running this script forms ``*.patch`` files in a folder named
-   ``pull-``\ `PID` in the current directory. One of the patch files is a
-   cover letter.
-
-   Before running the ``send-pull-request`` script, you must edit the
-   cover letter patch to insert information about your change. After
-   editing the cover letter, send the pull request. For example, the
-   following command runs the script and specifies the patch directory
-   and email address. In this example, the email address is a mailing
-   list::
-
-      $ poky/scripts/send-pull-request -p ~/meta-intel/pull-10565 -t meta-intel@lists.yoctoproject.org
-
-   You need to follow the prompts as the script is interactive.
-
-   .. note::
-
-      For help on using these scripts, simply provide the ``-h``
-      argument as follows::
-
-              $ poky/scripts/create-pull-request -h
-              $ poky/scripts/send-pull-request -h
-
-Responding to Patch Review
---------------------------
-
-You may get feedback on your submitted patches from other community members
-or from the automated patchtest service. If issues are identified in your
-patch then it is usually necessary to address these before the patch will be
-accepted into the project. In this case you should amend the patch according
-to the feedback and submit an updated version to the relevant mailing list,
-copying in the reviewers who provided feedback to the previous version of the
-patch.
-
-The patch should be amended using ``git commit --amend`` or perhaps ``git
-rebase`` for more expert git users. You should also modify the ``[PATCH]``
-tag in the email subject line when sending the revised patch to mark the new
-iteration as ``[PATCH v2]``, ``[PATCH v3]``, etc as appropriate. This can be
-done by passing the ``-v`` argument to ``git format-patch`` with a version
-number.
-
-Lastly please ensure that you also test your revised changes. In particular
-please don't just edit the patch file written out by ``git format-patch`` and
-resend it.
-
-Submitting Changes to Stable Release Branches
----------------------------------------------
-
-The process for proposing changes to a Yocto Project stable branch differs
-from the steps described above. Changes to a stable branch must address
-identified bugs or CVEs and should be made carefully in order to avoid the
-risk of introducing new bugs or breaking backwards compatibility. Typically
-bug fixes must already be accepted into the master branch before they can be
-backported to a stable branch unless the bug in question does not affect the
-master branch or the fix on the master branch is unsuitable for backporting.
-
-The list of stable branches along with the status and maintainer for each
-branch can be obtained from the
-:yocto_wiki:`Releases wiki page </Releases>`.
-
-.. note::
-
-   Changes will not typically be accepted for branches which are marked as
-   End-Of-Life (EOL).
-
-With this in mind, the steps to submit a change for a stable branch are as
-follows:
-
-#. *Identify the bug or CVE to be fixed:* This information should be
-   collected so that it can be included in your submission.
-
-   See :ref:`dev-manual/vulnerabilities:checking for vulnerabilities`
-   for details about CVE tracking.
-
-#. *Check if the fix is already present in the master branch:* This will
-   result in the most straightforward path into the stable branch for the
-   fix.
-
-   #. *If the fix is present in the master branch --- submit a backport request
-      by email:* You should send an email to the relevant stable branch
-      maintainer and the mailing list with details of the bug or CVE to be
-      fixed, the commit hash on the master branch that fixes the issue and
-      the stable branches which you would like this fix to be backported to.
-
-   #. *If the fix is not present in the master branch --- submit the fix to the
-      master branch first:* This will ensure that the fix passes through the
-      project's usual patch review and test processes before being accepted.
-      It will also ensure that bugs are not left unresolved in the master
-      branch itself. Once the fix is accepted in the master branch a backport
-      request can be submitted as above.
-
-   #. *If the fix is unsuitable for the master branch --- submit a patch
-      directly for the stable branch:* This method should be considered as a
-      last resort. It is typically necessary when the master branch is using
-      a newer version of the software which includes an upstream fix for the
-      issue or when the issue has been fixed on the master branch in a way
-      that introduces backwards incompatible changes. In this case follow the
-      steps in :ref:`dev-manual/changes:preparing changes for submission` and
-      :ref:`dev-manual/changes:using email to submit a patch` but modify the subject header of your patch
-      email to include the name of the stable branch which you are
-      targetting. This can be done using the ``--subject-prefix`` argument to
-      ``git format-patch``, for example to submit a patch to the dunfell
-      branch use
-      ``git format-patch --subject-prefix='&DISTRO_NAME_NO_CAP_MINUS_ONE;][PATCH' ...``.
-

documentation/dev-manual/debugging.rst

@@ -108,7 +108,7 @@ Viewing Variable Values
 Sometimes you need to know the value of a variable as a result of
 BitBake's parsing step. This could be because some unexpected behavior
 occurred in your project. Perhaps an attempt to :ref:`modify a variable
-<bitbake:bitbake-user-manual/bitbake-user-manual-metadata:modifying existing
+<bitbake-user-manual/bitbake-user-manual-metadata:modifying existing
 variables>` did not work out as expected.
 
 BitBake's ``-e`` option is used to display variable values after
@@ -282,15 +282,14 @@ Viewing Task Variable Dependencies
 ==================================
 
 As mentioned in the
-":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-execution:checksums (signatures)`" section of the BitBake
-User Manual, BitBake tries to automatically determine what variables a
-task depends on so that it can rerun the task if any values of the
-variables change. This determination is usually reliable. However, if
-you do things like construct variable names at runtime, then you might
-have to manually declare dependencies on those variables using
-``vardeps`` as described in the
-":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata:variable flags`" section of the BitBake
-User Manual.
+":ref:`bitbake-user-manual/bitbake-user-manual-execution:checksums (signatures)`"
+section of the BitBake User Manual, BitBake tries to automatically determine
+what variables a task depends on so that it can rerun the task if any values of
+the variables change. This determination is usually reliable. However, if you
+do things like construct variable names at runtime, then you might have to
+manually declare dependencies on those variables using ``vardeps`` as described
+in the ":ref:`bitbake-user-manual/bitbake-user-manual-metadata:variable flags`"
+section of the BitBake User Manual.
 
 If you are unsure whether a variable dependency is being picked up
 automatically for a given task, you can list the variable dependencies
@@ -457,7 +456,7 @@ out), then you can use the ``-f`` option.
 
    The reason ``-f`` is never required when running the
    :ref:`ref-tasks-devshell` task is because the
-   [\ :ref:`nostamp <bitbake:bitbake-user-manual/bitbake-user-manual-metadata:variable flags>`\ ]
+   [\ :ref:`nostamp <bitbake-user-manual/bitbake-user-manual-metadata:variable flags>`\ ]
    variable flag is already set for the task.
 
 The following example shows one way you can use the ``-f`` option::
@@ -572,10 +571,10 @@ log to ``${T}/log.do_``\ `task`, and can also log to standard output
 -  ``bb.note(msg)``: Writes "NOTE: msg" to the log. Also logs to
    stdout if BitBake is called with "-v".
 
--  ``bb.debug(level, msg)``: Writes "DEBUG: msg" to the
-   log. Also logs to stdout if the log level is greater than or equal to
-   level. See the ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-intro:usage and syntax`" option
-   in the BitBake User Manual for more information.
+-  ``bb.debug(level, msg)``: Writes "DEBUG: msg" to the log. Also logs to
+   stdout if the log level is greater than or equal to level. See the
+   ":ref:`bitbake-user-manual/bitbake-user-manual-intro:usage and syntax`"
+   option in the BitBake User Manual for more information.
 
 -  ``bb.warn(msg)``: Writes "WARNING: msg" to the log while also
    logging to stdout.
@@ -880,8 +879,7 @@ The build should work without issue.
 As with all solved problems, if they originated upstream, you need to
 submit the fix for the recipe in OE-Core and upstream so that the
 problem is taken care of at its source. See the
-":ref:`dev-manual/changes:submitting a change to the yocto project`"
-section for more information.
+":doc:`../contributor-guide/submit-changes`" section for more information.
 
 Debugging With the GNU Project Debugger (GDB) Remotely
 ======================================================
@@ -1237,9 +1235,7 @@ Here are some other tips that you might find useful:
    :yocto_bugs:`Bugzilla <>`. For information on
    how to submit a bug against the Yocto Project, see the Yocto Project
    Bugzilla :yocto_wiki:`wiki page </Bugzilla_Configuration_and_Bug_Tracking>`
-   and the
-   ":ref:`dev-manual/changes:submitting a defect against the yocto project`"
-   section.
+   and the ":doc:`../contributor-guide/report-defect`" section.
 
    .. note::
 

documentation/dev-manual/device-manager.rst

@@ -1,5 +1,7 @@
 .. SPDX-License-Identifier: CC-BY-SA-2.0-UK
 
+.. _device-manager:
+
 Selecting a Device Manager
 **************************
 

documentation/dev-manual/disk-space.rst

@@ -17,23 +17,45 @@ building a recipe once the recipe is built. For more information on
 "rm_work", see the :ref:`ref-classes-rm-work` class in the
 Yocto Project Reference Manual.
 
-Purging Duplicate Shared State Cache Files
-==========================================
+When you inherit this class and build a ``core-image-sato`` image for a
+``qemux86-64`` machine from an Ubuntu 22.04 x86-64 system, you end up with a
+final disk usage of 22 Gbytes instead of &MIN_DISK_SPACE; Gbytes. However,
+&MIN_DISK_SPACE_RM_WORK; Gbytes of initial free disk space are still needed to
+create temporary files before they can be deleted.
+
+Purging Obsolete Shared State Cache Files
+=========================================
 
 After multiple build iterations, the Shared State (sstate) cache can contain
-duplicate cache files for a given package, while only the most recent one
-is likely to be reusable. The following command purges all but the
-newest sstate cache file for each package::
+multiple cache files for a given package, consuming a substantial amount of
+disk space. However, only the most recent ones are likely to be reused.
+
+The following command is a quick way to purge all the cache files which
+haven't been used for a least a specified number of days::
+
+   find build/sstate-cache -type f -mtime +$DAYS -delete
+
+The above command relies on the fact that BitBake touches the sstate cache
+files as it accesses them, when it has write access to the cache.
+
+You could use ``-atime`` instead of ``-mtime`` if the partition isn't mounted
+with the ``noatime`` option for a read only cache.
+
+For more advanced needs, OpenEmbedded-Core also offers a more elaborate
+command. It has the ability to purge all but the newest cache files on each
+architecture, and also to remove files that it considers unreachable by
+exploring a set of build configurations. However, this command
+requires a full build environment to be available and doesn't work well
+covering multiple releases. It won't work either on limited environments
+such as BSD based NAS::
 
    sstate-cache-management.sh --remove-duplicated --cache-dir=build/sstate-cache
 
 This command will ask you to confirm the deletions it identifies.
+Run ``sstate-cache-management.sh`` for more details about this script.
 
 .. note::
 
-   The duplicated sstate cache files of one package must have the same
-   architecture, which means that sstate cache files with multiple
-   architectures are not considered as duplicate.
-
-Run ``sstate-cache-management.sh`` for more details about this script.
-
+   As this command is much more cautious and selective, removing only cache files,
+   it will execute much slower than the simple ``find`` command described above.
+   Therefore, it may not be your best option to trim huge cache directories.

documentation/dev-manual/index.rst

@@ -43,8 +43,8 @@ Yocto Project Development Tasks Manual
    build-quality
    runtime-testing
    debugging
-   changes
    licenses
+   security-subjects
    vulnerabilities
    sbom
    error-reporting-tool

documentation/dev-manual/init-manager.rst

@@ -1,83 +1,107 @@
 .. SPDX-License-Identifier: CC-BY-SA-2.0-UK
 
+.. _init-manager:
+
 Selecting an Initialization Manager
 ***********************************
 
-By default, the Yocto Project uses SysVinit as the initialization
-manager. However, there is also support for systemd, which is a full
-replacement for init with parallel starting of services, reduced shell
-overhead and other features that are used by many distributions.
+By default, the Yocto Project uses :wikipedia:`SysVinit <Init#SysV-style>` as
+the initialization manager. There is also support for BusyBox init, a simpler
+implementation, as well as support for :wikipedia:`systemd <Systemd>`, which
+is a full replacement for init with parallel starting of services, reduced
+shell overhead, increased security and resource limits for services, and other
+features that are used by many distributions.
 
-Within the system, SysVinit treats system components as services. These
-services are maintained as shell scripts stored in the ``/etc/init.d/``
-directory. Services organize into different run levels. This
-organization is maintained by putting links to the services in the
-``/etc/rcN.d/`` directories, where `N/` is one of the following options:
-"S", "0", "1", "2", "3", "4", "5", or "6".
+Within the system, SysVinit and BusyBox init treat system components as
+services. These services are maintained as shell scripts stored in the
+``/etc/init.d/`` directory.
+
+SysVinit is more elaborate than BusyBox init and organizes services in
+different run levels. This organization is maintained by putting links
+to the services in the ``/etc/rcN.d/`` directories, where `N/` is one
+of the following options: "S", "0", "1", "2", "3", "4", "5", or "6".
 
 .. note::
 
    Each runlevel has a dependency on the previous runlevel. This
    dependency allows the services to work properly.
 
+Both SysVinit and BusyBox init are configured through the ``/etc/inittab``
+file, with a very similar syntax, though of course BusyBox init features
+are more limited.
+
 In comparison, systemd treats components as units. Using units is a
 broader concept as compared to using a service. A unit includes several
-different types of entities. Service is one of the types of entities.
+different types of entities. ``Service`` is one of the types of entities.
 The runlevel concept in SysVinit corresponds to the concept of a target
 in systemd, where target is also a type of supported unit.
 
-In a SysVinit-based system, services load sequentially (i.e. one by one)
-during init and parallelization is not supported. With systemd, services
-start in parallel. Needless to say, the method can have an impact on
-system startup performance.
+In systems with SysVinit or BusyBox init, services load sequentially (i.e. one
+by one) during init and parallelization is not supported. With systemd, services
+start in parallel. This method can have an impact on the startup performance
+of a given service, though systemd will also provide more services by default,
+therefore increasing the total system boot time. systemd also substantially
+increases system size because of its multiple components and the extra
+dependencies it pulls.
 
-If you want to use SysVinit, you do not have to do anything. But, if you
-want to use systemd, you must take some steps as described in the
-following sections.
+On the contrary, BusyBox init is the simplest and the lightest solution and
+also comes with BusyBox mdev as device manager, a lighter replacement to
+:wikipedia:`udev <Udev>`, which SysVinit and systemd both use.
 
-Using systemd Exclusively
+The ":ref:`device-manager`" chapter has more details about device managers.
+
+Using SysVinit with udev
 =========================
 
-Set these variables in your distribution configuration file as follows::
+SysVinit with  the udev device manager corresponds to the
+default setting in Poky. This corresponds to setting::
 
-   DISTRO_FEATURES:append = " systemd"
-   VIRTUAL-RUNTIME_init_manager = "systemd"
+   INIT_MANAGER = "sysvinit"
 
-You can also prevent the SysVinit distribution feature from
-being automatically enabled as follows::
+Using BusyBox init with BusyBox mdev
+====================================
 
-   DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
+BusyBox init with BusyBox mdev is the simplest and lightest solution
+for small root filesystems. All you need is BusyBox, which most systems
+have anyway::
 
-Doing so removes any
-redundant SysVinit scripts.
+   INIT_MANAGER = "mdev-busybox"
 
-To remove initscripts from your image altogether, set this variable
-also::
+Using systemd
+=============
 
-   VIRTUAL-RUNTIME_initscripts = ""
+The last option is to use systemd together with the udev device
+manager. This is the most powerful and versatile solution, especially
+for more complex systems::
 
-For information on the backfill variable, see
-:term:`DISTRO_FEATURES_BACKFILL_CONSIDERED`.
+   INIT_MANAGER = "systemd"
 
-Using systemd for the Main Image and Using SysVinit for the Rescue Image
-========================================================================
+This will enable systemd and remove sysvinit components from the image.
+See :yocto_git:`meta/conf/distro/include/init-manager-systemd.inc
+</poky/tree/meta/conf/distro/include/init-manager-systemd.inc>` for exact
+details on what this does.
 
-Set these variables in your distribution configuration file as follows::
+Controling systemd from the target command line
+-----------------------------------------------
 
-   DISTRO_FEATURES:append = " systemd"
-   VIRTUAL-RUNTIME_init_manager = "systemd"
+Here is a quick reference for controling systemd from the command line on the
+target. Instead of opening and sometimes modifying files, most interaction
+happens through the ``systemctl`` and ``journalctl`` commands:
 
-Doing so causes your main image to use the
-``packagegroup-core-boot.bb`` recipe and systemd. The rescue/minimal
-image cannot use this package group. However, it can install SysVinit
-and the appropriate packages will have support for both systemd and
-SysVinit.
+-  ``systemctl status``: show the status of all services
+-  ``systemctl status <service>``: show the status of one service
+-  ``systemctl [start|stop] <service>``: start or stop a service
+-  ``systemctl [enable|disable] <service>``: enable or disable a service at boot time
+-  ``systemctl list-units``: list all available units
+-  ``journalctl -a``: show all logs for all services
+-  ``journalctl -f``: show only the last log entries, and keep printing updates as they arrive
+-  ``journalctl -u``: show only logs from a particular service
 
 Using systemd-journald without a traditional syslog daemon
-==========================================================
+----------------------------------------------------------
 
 Counter-intuitively, ``systemd-journald`` is not a syslog runtime or provider,
-and the proper way to use systemd-journald as your sole logging mechanism is to
+and the proper way to use ``systemd-journald`` as your sole logging mechanism is to
 effectively disable syslog entirely by setting these variables in your distribution
 configuration file::
 
@@ -85,5 +109,54 @@ configuration file::
    VIRTUAL-RUNTIME_base-utils-syslog = ""
 
 Doing so will prevent ``rsyslog`` / ``busybox-syslog`` from being pulled in by
-default, leaving only ``journald``.
+default, leaving only ``systemd-journald``.
 
+Summary
+-------
+
+The Yocto Project supports three different initialization managers, offering
+increasing levels of complexity and functionality:
+
+.. list-table::
+   :widths: 40 20 20 20
+   :header-rows: 1
+
+   * - 
+     - BusyBox init
+     - SysVinit
+     - systemd
+   * - Size
+     - Small
+     - Small
+     - Big [#footnote-systemd-size]_
+   * - Complexity
+     - Small
+     - Medium
+     - High
+   * - Support for boot profiles
+     - No
+     - Yes ("runlevels")
+     - Yes ("targets")
+   * - Services defined as
+     - Shell scripts
+     - Shell scripts
+     - Description files
+   * - Starting services in parallel
+     - No
+     - No
+     - Yes
+   * - Setting service resource limits
+     - No
+     - No
+     - Yes
+   * - Support service isolation
+     - No
+     - No
+     - Yes
+   * - Integrated logging
+     - No
+     - No
+     - Yes
+
+.. [#footnote-systemd-size] Using systemd increases the ``core-image-minimal``
+   image size by 160\% for ``qemux86-64`` on Mickledore (4.2), compared to SysVinit.

documentation/dev-manual/layers.rst

@@ -128,6 +128,20 @@ Follow these general steps to create your layer without using tools:
       variable is a good way to indicate if your particular layer is
       current.
 
+
+   .. note::
+
+      A layer does not have to contain only recipes ``.bb`` or append files
+      ``.bbappend``. Generally, developers create layers using
+      ``bitbake-layers create-layer``.
+      See ":ref:`dev-manual/layers:creating a general layer using the \`\`bitbake-layers\`\` script`",
+      explaining how the ``layer.conf`` file is created from a template located in
+      ``meta/lib/bblayers/templates/layer.conf``.
+      In fact, none of the variables set in ``layer.conf`` are mandatory,
+      except when :term:`BBFILE_COLLECTIONS` is present. In this case
+      :term:`LAYERSERIES_COMPAT` and :term:`BBFILE_PATTERN` have to be
+      defined too.
+
 #. *Add Content:* Depending on the type of layer, add the content. If
    the layer adds support for a machine, add the machine configuration
    in a ``conf/machine/`` file within the layer. If the layer adds

documentation/dev-manual/licenses.rst

@@ -242,10 +242,8 @@ defined in the
    COMMERCIAL_AUDIO_PLUGINS ?= ""
    COMMERCIAL_VIDEO_PLUGINS ?= ""
 
-If you
-want to enable these components, you can do so by making sure you have
-statements similar to the following in your ``local.conf`` configuration
-file::
+If you want to enable these components, you can do so by making sure you have
+statements similar to the following in your ``local.conf`` configuration file::
 
    COMMERCIAL_AUDIO_PLUGINS = "gst-plugins-ugly-mad \
        gst-plugins-ugly-mpegaudioparse"
@@ -253,20 +251,26 @@ file::
        gst-plugins-ugly-mpegstream gst-plugins-bad-mpegvideoparse"
    LICENSE_FLAGS_ACCEPTED = "commercial_gst-plugins-ugly commercial_gst-plugins-bad commercial_qmmp"
 
-
-Of course, you could also create a matching list for those
-components using the more general "commercial" in the
-:term:`LICENSE_FLAGS_ACCEPTED` variable, but that would also enable all
-the other packages with :term:`LICENSE_FLAGS`
+Of course, you could also create a matching list for those components using the
+more general "commercial" string in the :term:`LICENSE_FLAGS_ACCEPTED` variable,
+but that would also enable all the other packages with :term:`LICENSE_FLAGS`
 containing "commercial", which you may or may not want::
 
    LICENSE_FLAGS_ACCEPTED = "commercial"
 
 Specifying audio and video plugins as part of the
-``COMMERCIAL_AUDIO_PLUGINS`` and ``COMMERCIAL_VIDEO_PLUGINS`` statements
-(along with the enabling :term:`LICENSE_FLAGS_ACCEPTED`) includes the
-plugins or components into built images, thus adding support for media
-formats or components.
+:term:`COMMERCIAL_AUDIO_PLUGINS` and :term:`COMMERCIAL_VIDEO_PLUGINS` statements
+(along with :term:`LICENSE_FLAGS_ACCEPTED`) includes the plugins or
+components into built images, thus adding support for media formats or
+components.
+
+.. note::
+
+   GStreamer "ugly" and "bad" plugins are actually available through
+   open source licenses. However, the "ugly" ones can be subject to software
+   patents in some countries, making it necessary to pay licensing fees
+   to distribute them. The "bad" ones are just deemed unreliable by the
+   GStreamer community and should therefore be used with care.
 
 Maintaining Open Source License Compliance During Your Product's Lifecycle
 ==========================================================================
@@ -294,14 +298,28 @@ There are other requirements beyond the scope of these three and the
 methods described in this section (e.g. the mechanism through which
 source code is distributed).
 
-As different organizations have different methods of complying with open
-source licensing, this section is not meant to imply that there is only
-one single way to meet your compliance obligations, but rather to
-describe one method of achieving compliance. The remainder of this
-section describes methods supported to meet the previously mentioned
-three requirements. Once you take steps to meet these requirements, and
-prior to releasing images, sources, and the build system, you should
-audit all artifacts to ensure completeness.
+As different organizations have different ways of releasing software,
+there can be multiple ways of meeting license obligations. At
+least, we describe here two methods for achieving compliance:
+
+-  The first method is to use OpenEmbedded's ability to provide
+   the source code, provide a list of licenses, as well as
+   compilation scripts and source code modifications.
+
+   The remainder of this section describes supported methods to meet
+   the previously mentioned three requirements.
+
+-  The second method is to generate a *Software Bill of Materials*
+   (:term:`SBoM`), as described in the ":doc:`/dev-manual/sbom`" section.
+   Not only do you generate :term:`SPDX` output which can be used meet
+   license compliance requirements (except for sharing the build system
+   and layers sources for the time being), but this output also includes
+   component version and patch information which can be used
+   for vulnerability assessment.
+
+Whatever method you choose, prior to releasing images, sources,
+and the build system, you should audit all artifacts to ensure
+completeness.
 
 .. note::
 

documentation/dev-manual/new-recipe.rst

@@ -257,15 +257,14 @@ located. For a graphical representation of source locations, see the
 ":ref:`overview-manual/concepts:sources`" section in
 the Yocto Project Overview and Concepts Manual.
 
-The :ref:`ref-tasks-fetch` task uses
-the prefix of each entry in the :term:`SRC_URI` variable value to determine
-which :ref:`fetcher <bitbake:bitbake-user-manual/bitbake-user-manual-fetching:fetchers>` to use to get your
-source files. It is the :term:`SRC_URI` variable that triggers the fetcher.
-The :ref:`ref-tasks-patch` task uses
-the variable after source is fetched to apply patches. The OpenEmbedded
-build system uses
-:term:`FILESOVERRIDES` for
-scanning directory locations for local files in :term:`SRC_URI`.
+The :ref:`ref-tasks-fetch` task uses the prefix of each entry in the
+:term:`SRC_URI` variable value to determine which
+:ref:`fetcher <bitbake-user-manual/bitbake-user-manual-fetching:fetchers>`
+to use to get your source files. It is the :term:`SRC_URI` variable that triggers
+the fetcher. The :ref:`ref-tasks-patch` task uses the variable after source is
+fetched to apply patches. The OpenEmbedded build system uses
+:term:`FILESOVERRIDES` for scanning directory locations for local files in
+:term:`SRC_URI`.
 
 The :term:`SRC_URI` variable in your recipe must define each unique location
 for your source files. It is good practice to not hard-code version
@@ -288,7 +287,7 @@ extension (e.g. ``.tar``, ``.tar.gz``, ``.tar.bz2``, ``.zip``, and so
 forth), are automatically extracted during the
 :ref:`ref-tasks-unpack` task. For
 another example that specifies these types of files, see the
-":ref:`dev-manual/new-recipe:autotooled package`" section.
+":ref:`dev-manual/new-recipe:building an autotooled package`" section.
 
 Another way of specifying source is from an SCM. For Git repositories,
 you must specify :term:`SRCREV` and you should specify :term:`PV` to include
@@ -361,7 +360,7 @@ and searches specific directories in a certain order:
 ``files``. The directories are assumed to be subdirectories of the
 directory in which the recipe or append file resides. For another
 example that specifies these types of files, see the
-":ref:`dev-manual/new-recipe:single .c file package (hello world!)`" section.
+"`building a single .c file package`_" section.
 
 The previous example also specifies a patch file. Patch files are files
 whose names usually end in ``.patch`` or ``.diff`` but can end with
@@ -410,8 +409,8 @@ Patching Code
 
 Sometimes it is necessary to patch code after it has been fetched. Any
 files mentioned in :term:`SRC_URI` whose names end in ``.patch`` or
-``.diff`` or compressed versions of these suffixes (e.g. ``diff.gz`` are
-treated as patches. The
+``.diff`` or compressed versions of these suffixes (e.g. ``diff.gz``,
+``patch.bz2``, etc.) are treated as patches. The
 :ref:`ref-tasks-patch` task
 automatically applies these patches.
 
@@ -776,7 +775,7 @@ the software being built:
    ``PREFIX=${D}``, ``INSTALLROOT=${D}``, and so forth).
 
    For an example recipe using ``make install``, see the
-   ":ref:`dev-manual/new-recipe:makefile-based package`" section.
+   ":ref:`dev-manual/new-recipe:building a makefile-based package`" section.
 
 -  *Manual:* You need to define a :ref:`ref-tasks-install` function in your
    recipe. The function must first use ``install -d`` to create the
@@ -1083,13 +1082,14 @@ build system and package managers, so the resulting packages will not
 correctly trigger an upgrade.
 
 In order to ensure the versions compare properly, the recommended
-convention is to set :term:`PV` within the
-recipe to "previous_version+current_version". You can use an additional
-variable so that you can use the current version elsewhere. Here is an
-example::
+convention is to use a tilde (``~``) character as follows::
 
-   REALPV = "0.8.16-rc1"
-   PV = "0.8.15+${REALPV}"
+  PV = 0.8.16~rc1
+
+This way ``0.8.16~rc1`` sorts before ``0.8.16``. See the
+":ref:`contributor-guide/recipe-style-guide:version policy`" section in the
+Yocto Project and OpenEmbedded Contributor Guide for more details about
+versioning code corresponding to a pre-release or to a specific Git commit.
 
 Post-Installation Scripts
 =========================
@@ -1165,28 +1165,29 @@ Examples
 ========
 
 To help summarize how to write a recipe, this section provides some
-examples given various scenarios:
+recipe examples given various scenarios:
 
--  Recipes that use local files
+-  `Building a single .c file package`_
 
--  Using an Autotooled package
+-  `Building a Makefile-based package`_
 
--  Using a Makefile-based package
+-  `Building an Autotooled package`_
 
--  Splitting an application into multiple packages
+-  `Building a Meson package`_
 
--  Adding binaries to an image
+-  `Splitting an application into multiple packages`_
 
-Single .c File Package (Hello World!)
--------------------------------------
+-  `Packaging externally produced binaries`_
 
-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
-: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::
+Building a Single .c File Package
+---------------------------------
+
+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 :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::
 
    SUMMARY = "Simple helloworld application"
    SECTION = "examples"
@@ -1206,52 +1207,22 @@ directory BitBake uses for the build::
        install -m 0755 helloworld ${D}${bindir}
    }
 
-By default, the ``helloworld``, ``helloworld-dbg``, and
-``helloworld-dev`` packages are built. For information on how to
-customize the packaging process, see the
+By default, the ``helloworld``, ``helloworld-dbg``, and ``helloworld-dev`` packages
+are built. For information on how to customize the packaging process, see the
 ":ref:`dev-manual/new-recipe:splitting an application into multiple packages`"
 section.
 
-Autotooled Package
-------------------
+Building a Makefile-Based Package
+---------------------------------
 
-Applications that use Autotools such as ``autoconf`` and ``automake``
-require a recipe that has a source archive listed in :term:`SRC_URI` and
-also inherit the :ref:`ref-classes-autotools` class,
-which contains the definitions of all the steps needed to build an
-Autotool-based application. The result of the build is automatically
-packaged. And, if the application uses NLS for localization, packages
-with local information are generated (one package per language).
-Following is one example: (``hello_2.3.bb``)::
-
-   SUMMARY = "GNU Helloworld application"
-   SECTION = "examples"
-   LICENSE = "GPL-2.0-or-later"
-   LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe"
-
-   SRC_URI = "${GNU_MIRROR}/hello/hello-${PV}.tar.gz"
-
-   inherit autotools gettext
-
-The variable :term:`LIC_FILES_CHKSUM` is used to track source license
-changes as described in the
-":ref:`dev-manual/licenses:tracking license changes`" section in
-the Yocto Project Overview and Concepts Manual. You can quickly create
-Autotool-based recipes in a manner similar to the previous example.
-
-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
-: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 :ref:`ref-tasks-install` task is still required.
-Otherwise, BitBake runs an empty :ref:`ref-tasks-install` task by default.
+Applications built with GNU ``make`` require a recipe that has the source archive
+listed in :term:`SRC_URI`. You do not need to add a :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
+: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
@@ -1294,6 +1265,62 @@ In the following example, ``lz4`` is a makefile-based package::
 
    BBCLASSEXTEND = "native nativesdk"
 
+Building an Autotooled Package
+------------------------------
+
+Applications built with the Autotools such as ``autoconf`` and ``automake``
+require a recipe that has a source archive listed in :term:`SRC_URI` and also
+inherit the :ref:`ref-classes-autotools` class, which contains the definitions
+of all the steps needed to build an Autotool-based application. The result of
+the build is automatically packaged. And, if the application uses NLS for
+localization, packages with local information are generated (one package per
+language). Following is one example: (``hello_2.3.bb``)::
+
+   SUMMARY = "GNU Helloworld application"
+   SECTION = "examples"
+   LICENSE = "GPL-2.0-or-later"
+   LIC_FILES_CHKSUM = "file://COPYING;md5=751419260aa954499f7abaabaa882bbe"
+
+   SRC_URI = "${GNU_MIRROR}/hello/hello-${PV}.tar.gz"
+
+   inherit autotools gettext
+
+The variable :term:`LIC_FILES_CHKSUM` is used to track source license changes
+as described in the ":ref:`dev-manual/licenses:tracking license changes`"
+section in the Yocto Project Overview and Concepts Manual. You can quickly
+create Autotool-based recipes in a manner similar to the previous example.
+
+.. _ref-building-meson-package:
+
+Building a Meson Package
+------------------------
+
+Applications built with the `Meson build system <https://mesonbuild.com/>`__
+just need a recipe that has sources described in :term:`SRC_URI` and inherits
+the :ref:`ref-classes-meson` class.
+
+The :oe_git:`ipcalc recipe </meta-openembedded/tree/meta-networking/recipes-support/ipcalc>`
+is a simple example of an application without dependencies::
+
+   SUMMARY = "Tool to assist in network address calculations for IPv4 and IPv6."
+   HOMEPAGE = "https://gitlab.com/ipcalc/ipcalc"
+
+   SECTION = "net"
+
+   LICENSE = "GPL-2.0-only"
+   LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
+
+   SRC_URI = "git://gitlab.com/ipcalc/ipcalc.git;protocol=https;branch=master"
+   SRCREV = "4c4261a47f355946ee74013d4f5d0494487cc2d6"
+
+   S = "${WORKDIR}/git"
+
+   inherit meson
+
+Applications with dependencies are likely to inherit the
+:ref:`ref-classes-pkgconfig` class, as ``pkg-config`` is the default method
+used by Meson to find dependencies and compile applications against them.
+
 Splitting an Application into Multiple Packages
 -----------------------------------------------
 
@@ -1397,12 +1424,9 @@ doing the following:
       do_configure[noexec] = "1"
       do_compile[noexec] = "1"
 
-   Unlike
-   :ref:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata:deleting a task`,
-   using the flag preserves the dependency chain from the
-   :ref:`ref-tasks-fetch`,
-   :ref:`ref-tasks-unpack`, and
-   :ref:`ref-tasks-patch` tasks to the
+   Unlike :ref:`bitbake-user-manual/bitbake-user-manual-metadata:deleting a task`,
+   using the flag preserves the dependency chain from the :ref:`ref-tasks-fetch`,
+   :ref:`ref-tasks-unpack`, and :ref:`ref-tasks-patch` tasks to the
    :ref:`ref-tasks-install` task.
 
 -  Make sure your :ref:`ref-tasks-install` task installs the binaries
@@ -1418,9 +1442,9 @@ doing the following:
 Following Recipe Style Guidelines
 =================================
 
-When writing recipes, it is good to conform to existing style
-guidelines. The :oe_wiki:`OpenEmbedded Styleguide </Styleguide>` wiki page
-provides rough guidelines for preferred recipe style.
+When writing recipes, it is good to conform to existing style guidelines.
+See the ":doc:`../contributor-guide/recipe-style-guide`" in the Yocto Project
+and OpenEmbedded Contributor Guide for reference.
 
 It is common for existing recipes to deviate a bit from this style.
 However, aiming for at least a consistent style is a good idea. Some

documentation/dev-manual/packages.rst

@@ -227,18 +227,6 @@ default value is "r0", the practice of adding it to a new recipe makes
 it harder to forget to bump the variable when you make changes to the
 recipe in future.
 
-If you are sharing a common ``.inc`` file with multiple recipes, you can
-also use the :term:`INC_PR` variable to ensure that the recipes sharing the
-``.inc`` file are rebuilt when the ``.inc`` file itself is changed. The
-``.inc`` file must set :term:`INC_PR` (initially to "r0"), and all recipes
-referring to it should set :term:`PR` to "${INC_PR}.0" initially,
-incrementing the last number when the recipe is changed. If the ``.inc``
-file is changed then its :term:`INC_PR` should be incremented.
-
-When upgrading the version of a binary package, assuming the :term:`PV`
-changes, the :term:`PR` variable should be reset to "r0" (or "${INC_PR}.0"
-if you are using :term:`INC_PR`).
-
 Usually, version increases occur only to binary packages. However, if
 for some reason :term:`PV` changes but does not increase, you can increase
 the :term:`PE` variable (Package Epoch). The :term:`PE` variable defaults to
@@ -999,12 +987,12 @@ test. Here is what you have to do for each recipe:
 Creating Node Package Manager (NPM) Packages
 ============================================
 
-:wikipedia:`NPM <Npm_(software)>` is a package
-manager for the JavaScript programming language. The Yocto Project
-supports the NPM :ref:`fetcher <bitbake:bitbake-user-manual/bitbake-user-manual-fetching:fetchers>`. You can
-use this fetcher in combination with
-:doc:`devtool </ref-manual/devtool-reference>` to create
-recipes that produce NPM packages.
+:wikipedia:`NPM <Npm_(software)>` is a package manager for the JavaScript
+programming language. The Yocto Project supports the NPM
+:ref:`fetcher <bitbake-user-manual/bitbake-user-manual-fetching:fetchers>`.
+You can use this fetcher in combination with
+:doc:`devtool </ref-manual/devtool-reference>` to create recipes that produce
+NPM packages.
 
 There are two workflows that allow you to create NPM packages using
 ``devtool``: the NPM registry modules method and the NPM project code

documentation/dev-manual/prebuilt-libraries.rst

@@ -153,9 +153,9 @@ default :term:`FILES` variables in ``bitbake.conf``::
 
    SOLIBS = ".so.*"
    SOLIBSDEV = ".so"
-   FILES_${PN} = "... ${libdir}/lib*${SOLIBS} ..."
+   FILES:${PN} = "... ${libdir}/lib*${SOLIBS} ..."
    FILES_SOLIBSDEV ?= "... ${libdir}/lib*${SOLIBSDEV} ..."
-   FILES_${PN}-dev = "... ${FILES_SOLIBSDEV} ..."
+   FILES:${PN}-dev = "... ${FILES_SOLIBSDEV} ..."
 
 :term:`SOLIBS` defines a pattern that matches real shared object libraries.
 :term:`SOLIBSDEV` matches the development form (unversioned symlink). These two

documentation/dev-manual/python-development-shell.rst

@@ -27,7 +27,7 @@ functions::
    pydevshell> bb.build.exec_func("do_unpack", d)
    pydevshell>
 
-See the ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata:functions you can call from within python`"
+See the ":ref:`bitbake-user-manual/bitbake-user-manual-metadata:functions you can call from within python`"
 section in the BitBake User Manual for details about available functions.
 
 The commands execute just as if the OpenEmbedded build

documentation/dev-manual/runtime-testing.rst

@@ -229,7 +229,7 @@ The final thing you need to do when setting :term:`TEST_TARGET` to
    statements in your ``local.conf`` file::
 
       IMAGE_FSTYPES += "tar.gz"
-      INHERIT += "testimage"
+      IMAGE_CLASSES += "testimage"
       TEST_TARGET = "SystemdbootTarget"
       TEST_TARGET_IP = "192.168.2.3"
 
@@ -335,7 +335,7 @@ You can start the tests automatically or manually:
    inherit the :ref:`ref-classes-testimage` class by editing your
    ``local.conf`` file::
 
-      INHERIT += "testimage"
+      IMAGE_CLASSES += "testimage"
 
    Next, use BitBake to run the tests::
 

documentation/dev-manual/sbom.rst

@@ -63,7 +63,13 @@ generated files are available in ``tmp/deploy/spdx/MACHINE`` too, such as:
    (when :term:`SPDX_ARCHIVE_SOURCES` is set). Those are needed to fulfill
    "source code access" license requirements.
 
+See also the :term:`SPDX_CUSTOM_ANNOTATION_VARS` variable which allows
+to associate custom notes to a recipe.
+
 See the `tools page <https://spdx.dev/resources/tools/>`__ on the :term:`SPDX`
 project website for a list of tools to consume and transform the :term:`SPDX`
 data generated by the OpenEmbedded build system.
 
+See also Joshua Watt's
+`Automated SBoM generation with OpenEmbedded and the Yocto Project <https://youtu.be/Q5UQUM6zxVU>`__
+presentation at FOSDEM 2023.

documentation/dev-manual/securing-images.rst

@@ -68,7 +68,7 @@ more secure:
 
 -  Regularly update your version of Poky and OE-Core from their upstream
    developers, e.g. to apply updates and security fixes from stable
-   and LTS branches.
+   and :term:`LTS` branches.
 
 -  Ensure you remove or disable debugging functionality before producing
    the final image. For information on how to do this, see the

documentation/dev-manual/security-subjects.rst

@@ -0,0 +1,189 @@
+.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
+
+Dealing with Vulnerability Reports
+**********************************
+
+The Yocto Project and OpenEmbedded are open-source, community-based projects
+used in numerous products. They assemble multiple other open-source projects,
+and need to handle security issues and practices both internal (in the code
+maintained by both projects), and external (maintained by other projects and
+organizations).
+
+This manual assembles security-related information concerning the whole
+ecosystem. It includes information on reporting a potential security issue,
+the operation of the YP Security team and how to contribute in the
+related code. It is written to be useful for both security researchers and
+YP developers.
+
+How to report a potential security vulnerability?
+=================================================
+
+If you would like to report a public issue (for example, one with a released
+CVE number), please report it using the
+:yocto_bugs:`Security Bugzilla </enter_bug.cgi?product=Security>`.
+
+If you are dealing with a not-yet-released issue, or an urgent one, please send
+a message to security AT yoctoproject DOT org, including as many details as
+possible: the layer or software module affected, the recipe and its version,
+and any example code, if available. This mailing list is monitored by the
+Yocto Project Security team.
+
+For each layer, you might also look for specific instructions (if any) for
+reporting potential security issues in the specific ``SECURITY.md`` file at the
+root of the repository. Instructions on how and where submit a patch are
+usually available in ``README.md``. If this is your first patch to the
+Yocto Project/OpenEmbedded, you might want to have a look into the
+Contributor's Manual section
+":ref:`contributor-guide/submit-changes:preparing changes for submission`".
+
+Branches maintained with security fixes
+---------------------------------------
+
+See the
+:ref:`Release process <ref-manual/release-process:Stable Release Process>`
+documentation for details regarding the policies and maintenance of stable
+branches.
+
+The :yocto_wiki:`Releases page </Releases>` contains a list
+of all releases of the Yocto Project. Versions in gray are no longer actively
+maintained with security patches, but well-tested patches may still be accepted
+for them for significant issues.
+
+Security-related discussions at the Yocto Project
+-------------------------------------------------
+
+We have set up two security-related mailing lists:
+
+  -  Public List: yocto [dash] security [at] yoctoproject[dot] org
+
+    This is a public mailing list for anyone to subscribe to. This list is an
+    open list to discuss public security issues/patches and security-related
+    initiatives. For more information, including subscription information,
+    please see the  :yocto_lists:`yocto-security mailing list info page </g/yocto-security>`.
+
+  - Private List: security [at] yoctoproject [dot] org
+
+    This is a private mailing list for reporting non-published potential
+    vulnerabilities. The list is monitored by the Yocto Project Security team.
+
+
+What you should do if you find a security vulnerability
+-------------------------------------------------------
+
+If you find a security flaw: a crash, an information leakage, or anything that
+can have a security impact if exploited in any Open Source software built or
+used by the Yocto Project, please report this to the Yocto Project Security
+Team. If you prefer to contact the upstream project directly, please send a
+copy to the security team at the Yocto Project as well. If you believe this is
+highly sensitive information, please report the vulnerability in a secure way,
+i.e. encrypt the email and send it to the private list. This ensures that
+the exploit is not leaked and exploited before a response/fix has been generated.
+
+Security team
+=============
+
+The Yocto Project/OpenEmbedded security team coordinates the work on security
+subjects in the project. All general discussion takes place publicly. The
+Security Team only uses confidential communication tools to deal with private
+vulnerability reports before they are released.
+
+Security team appointment
+-------------------------
+
+The Yocto Project Security Team consists of at least three members. When new
+members are needed, the Yocto Project Technical Steering Committee (YP TSC)
+asks for nominations by public channels including a nomination deadline.
+Self-nominations are possible. When the limit time is
+reached, the YP TSC posts the list of candidates for the comments of project
+participants and developers. Comments may be sent publicly or privately to the
+YP and OE TSCs. The candidates are approved by both YP TSC and OpenEmbedded
+Technical Steering Committee (OE TSC) and the final list of the team members
+is announced publicly. The aim is to have people representing technical
+leadership, security knowledge and infrastructure present with enough people
+to provide backup/coverage but keep the notification list small enough to
+minimize information risk and maintain trust.
+
+YP Security Team members may resign at any time.
+
+Security Team Operations
+------------------------
+
+The work of the Security Team might require high confidentiality. Team members
+are individuals selected by merit and do not represent the companies they work
+for. They do not share information about confidential issues outside of the team
+and do not hint about ongoing embargoes.
+
+Team members can bring in domain experts as needed. Those people should be
+added to individual issues only and adhere to the same standards as the YP
+Security Team.
+
+The YP security team organizes its meetings and communication as needed.
+
+When the YP Security team receives a report about a potential security
+vulnerability, they quickly analyze and notify the reporter of the result.
+They might also request more information.
+
+If the issue is confirmed and affects the code maintained by the YP, they
+confidentially notify maintainers of that code and work with them to prepare
+a fix.
+
+If the issue is confirmed and affects an upstream project, the YP security team
+notifies the project. Usually, the upstream project analyzes the problem again.
+If they deem it a real security problem in their software, they develop and
+release a fix following their security policy. They may want to include the
+original reporter in the loop. There is also sometimes some coordination for
+handling patches, backporting patches etc, or just understanding the problem
+or what caused it.
+
+When the fix is publicly available, the YP security team member or the
+package maintainer sends patches against the YP code base, following usual
+procedures, including public code review.
+
+What Yocto Security Team does when it receives a security vulnerability
+-----------------------------------------------------------------------
+
+The YP Security Team team performs a quick analysis and would usually report
+the flaw to the upstream project. Normally the upstream project analyzes the
+problem. If they deem it a real security problem in their software, they
+develop and release a fix following their own security policy. They may want
+to include the original reporter in the loop. There is also sometimes some
+coordination for handling patches, backporting patches etc, or just
+understanding the problem or what caused it.
+
+The security policy of the upstream project might include a notification to
+Linux distributions or other important downstream projects in advance to
+discuss coordinated disclosure. These mailing lists are normally non-public.
+
+When the upstream project releases a version with the fix, they are responsible
+for contacting `Mitre <https://www.cve.org/>`__ to get a CVE number assigned and
+the CVE record published.
+
+If an upstream project does not respond quickly
+-----------------------------------------------
+
+If an upstream project does not fix the problem in a reasonable time,
+the Yocto's Security Team will contact other interested parties (usually
+other distributions) in the community and together try to solve the
+vulnerability as quickly as possible.
+
+The Yocto Project Security team adheres to the 90 days disclosure policy
+by default. An increase of the embargo time is possible when necessary.
+
+Current Security Team members
+-----------------------------
+
+For secure communications, please send your messages encrypted using the GPG
+keys. Remember, message headers are not encrypted so do not include sensitive
+information in the subject line.
+
+  -  Ross Burton: <ross@burtonini.com> `Public key <https://keys.openpgp.org/search?q=ross%40burtonini.com>`__
+
+  -  Michael Halstead: <mhalstead [at] linuxfoundation [dot] org>
+     `Public key <https://pgp.mit.edu/pks/lookup?op=vindex&search=0x3373170601861969>`__
+     or `Public key <https://keyserver.ubuntu.com/pks/lookup?op=get&search=0xd1f2407285e571ed12a407a73373170601861969>`__
+
+  -  Richard Purdie: <richard.purdie@linuxfoundation.org> `Public key <https://keys.openpgp.org/search?q=richard.purdie%40linuxfoundation.org>`__
+
+  -  Marta Rybczynska: <marta DOT rybczynska [at] syslinbit [dot] com> `Public key <https://keys.openpgp.org/search?q=marta.rybczynska@syslinbit.com>`__
+
+  -  Steve Sakoman: <steve [at] sakoman [dot] com> `Public key <https://keys.openpgp.org/search?q=steve%40sakoman.com>`__

documentation/dev-manual/start.rst

@@ -88,27 +88,15 @@ particular working environment and set of practices.
        For information about BitBake, see the
        :doc:`bitbake:index`.
 
-    It is relatively easy to set up Git services and create
-    infrastructure like :yocto_git:`/`, which is based on
-    server software called ``gitolite`` with ``cgit`` being used to
-    generate the web interface that lets you view the repositories. The
-    ``gitolite`` software identifies users using SSH keys and allows
+    It is relatively easy to set up Git services and create infrastructure like
+    :yocto_git:`/`, which is based on server software called
+    `Gitolite <https://gitolite.com>`__
+    with `cgit <https://git.zx2c4.com/cgit/about/>`__ being used to
+    generate the web interface that lets you view the repositories.
+    ``gitolite`` identifies users using SSH keys and allows
     branch-based access controls to repositories that you can control as
     little or as much as necessary.
 
-    .. note::
-
-       The setup of these services is beyond the scope of this manual.
-       However, here are sites describing how to perform setup:
-
-       -  `Gitolite <https://gitolite.com>`__: Information for
-          ``gitolite``.
-
-       -  `Interfaces, frontends, and
-          tools <https://git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools>`__:
-          Documentation on how to create interfaces and frontends for
-          Git.
-
 #.  *Set up the Application Development Machines:* As mentioned earlier,
     application developers are creating applications on top of existing
     software stacks. Following are some best practices for setting up
@@ -246,14 +234,13 @@ particular working environment and set of practices.
     -  The Yocto Project community encourages you to send patches to the
        project to fix bugs or add features. If you do submit patches,
        follow the project commit guidelines for writing good commit
-       messages. See the
-       ":ref:`dev-manual/changes:submitting a change to the yocto project`"
-       section.
+       messages. See the ":doc:`../contributor-guide/submit-changes`"
+       section in the Yocto Project and OpenEmbedded Contributor Guide.
 
     -  Send changes to the core sooner than later as others are likely
        to run into the same issues. For some guidance on mailing lists
-       to use, see the list in the
-       ":ref:`dev-manual/changes:submitting a change to the yocto project`"
+       to use, see the lists in the
+       ":ref:`contributor-guide/submit-changes:finding a suitable mailing list`"
        section. For a description
        of the available mailing lists, see the ":ref:`resources-mailinglist`" section in
        the Yocto Project Reference Manual.
@@ -302,7 +289,7 @@ Project Build Host:
    as these releases are frequently tested against the Yocto Project and
    officially supported. For a list of the distributions under
    validation and their status, see the ":ref:`Supported Linux
-   Distributions <detailed-supported-distros>`"
+   Distributions <system-requirements-supported-distros>`"
    section in the Yocto Project Reference Manual and the wiki page at
    :yocto_wiki:`Distribution Support </Distribution_Support>`.
 
@@ -613,44 +600,23 @@ Use the following procedure to locate the latest upstream copy of the
       For information on cloning a repository, see the
       ":ref:`dev-manual/start:cloning the \`\`poky\`\` repository`" section.
 
-Accessing Index of Releases
----------------------------
+Accessing Source Archives
+-------------------------
 
-Yocto Project maintains an Index of Releases area that contains related
-files that contribute to the Yocto Project. Rather than Git
-repositories, these files are tarballs that represent snapshots in time
-of a given component.
+The Yocto Project also provides source archives of its releases, which
+are available on :yocto_dl:`/releases/yocto/`. Then, choose the subdirectory
+containing the release you wish to use, for example
+:yocto_dl:`yocto-&DISTRO; </releases/yocto/yocto-&DISTRO;/>`.
+
+You will find there source archives of individual components (if you wish
+to use them individually), and of the corresponding Poky release bundling
+a selection of these components. 
 
 .. note::
 
    The recommended method for accessing Yocto Project components is to
    use Git to clone the upstream repository and work from within that
-   locally cloned repository. However, this section documents how to
-   use a tarball snapshot of any given component.
-
-Follow these steps to locate and download a particular tarball:
-
-#. *Access the Index of Releases:* Open a browser and go to
-   :yocto_dl:`Index of Releases </releases>`. The
-   list represents released components (e.g. ``bitbake``, ``sato``, and
-   so on).
-
-   .. note::
-
-      The ``yocto`` directory contains the full array of released Poky
-      tarballs. The ``poky`` directory in the Index of Releases was
-      historically used for very early releases and exists now only for
-      retroactive completeness.
-
-#. *Select a Component:* Click on any released component in which you
-   are interested (e.g. ``yocto``).
-
-#. *Find the Tarball:* Drill down to find the associated tarball. For
-   example, click on ``yocto-&DISTRO;`` to view files associated with the
-   Yocto Project &DISTRO; release.
-
-#. *Download the Tarball:* Click the tarball to download and save a
-   snapshot of the given component.
+   locally cloned repository.
 
 Using the Downloads Page
 ------------------------
@@ -659,7 +625,7 @@ The :yocto_home:`Yocto Project Website <>` uses a "DOWNLOADS" page
 from which you can locate and download tarballs of any Yocto Project
 release. Rather than Git repositories, these files represent snapshot
 tarballs similar to the tarballs located in the Index of Releases
-described in the ":ref:`dev-manual/start:accessing index of releases`" section.
+described in the ":ref:`dev-manual/start:accessing source archives`" section.
 
 #. *Go to the Yocto Project Website:* Open The
    :yocto_home:`Yocto Project Website <>` in your browser.

documentation/dev-manual/upgrading-recipes.rst

@@ -117,7 +117,7 @@ The following steps describe how to set up the AUH utility:
       class, which is optional, you need to have the following set in
       your ``conf/local.conf`` file::
 
-         INHERIT += "testimage"
+         IMAGE_CLASSES += "testimage"
 
       .. note::
 

documentation/dev-manual/vulnerabilities.rst

@@ -22,7 +22,7 @@ issues may be impacting Poky and OE-Core. It is up to the maintainers, users,
 contributors and anyone interested in the issues to investigate and possibly fix them by
 updating software components to newer versions or by applying patches to address them.
 It is recommended to work with Poky and OE-Core upstream maintainers and submit
-patches to fix them, see ":ref:`dev-manual/changes:submitting a change to the yocto project`" for details.
+patches to fix them, see ":doc:`../contributor-guide/submit-changes`" for details.
 
 Vulnerability check at build time
 =================================

documentation/dev-manual/wic.rst

@@ -72,7 +72,7 @@ In order to use the Wic utility with the OpenEmbedded Build system, your
 system needs to meet the following requirements:
 
 -  The Linux distribution on your development host must support the
-   Yocto Project. See the ":ref:`detailed-supported-distros`"
+   Yocto Project. See the ":ref:`system-requirements-supported-distros`"
    section in the Yocto Project Reference Manual for the list of
    distributions that support the Yocto Project.
 
@@ -92,7 +92,7 @@ system needs to meet the following requirements:
 -  You must build several native tools, which are built to run on the
    build system::
 
-      $ bitbake parted-native dosfstools-native mtools-native
+      $ bitbake wic-tools
 
 -  Include "wic" as part of the
    :term:`IMAGE_FSTYPES`

documentation/index.rst

@@ -26,6 +26,7 @@ Welcome to the Yocto Project Documentation
    :caption: Manuals
 
    Overview and Concepts Manual <overview-manual/index>
+   Contributor Guide <contributor-guide/index>
    Reference Manual <ref-manual/index>
    Board Support Package (BSP) Developer's guide <bsp-guide/index>
    Development Tasks Manual <dev-manual/index>

documentation/kernel-dev/advanced.rst

@@ -352,17 +352,15 @@ in the manual.
 Kernel Types
 ------------
 
-A kernel type defines a high-level kernel policy by aggregating
-non-hardware configuration fragments with patches you want to use when
-building a Linux kernel of a specific type (e.g. a real-time kernel).
-Syntactically, kernel types are no different than features as described
-in the ":ref:`kernel-dev/advanced:features`" section. The
-:term:`LINUX_KERNEL_TYPE`
-variable in the kernel recipe selects the kernel type. For example, in
-the ``linux-yocto_4.12.bb`` kernel recipe found in
-``poky/meta/recipes-kernel/linux``, a
-:ref:`require <bitbake:bitbake-user-manual/bitbake-user-manual-metadata:\`\`require\`\` directive>` directive
-includes the ``poky/meta/recipes-kernel/linux/linux-yocto.inc`` file,
+A kernel type defines a high-level kernel policy by aggregating non-hardware
+configuration fragments with patches you want to use when building a Linux
+kernel of a specific type (e.g. a real-time kernel). Syntactically, kernel
+types are no different than features as described in the
+":ref:`kernel-dev/advanced:features`" section. The :term:`LINUX_KERNEL_TYPE`
+variable in the kernel recipe selects the kernel type. For example, in the
+``linux-yocto_4.12.bb`` kernel recipe found in ``poky/meta/recipes-kernel/linux``, a
+:ref:`require <bitbake-user-manual/bitbake-user-manual-metadata:\`\`require\`\` directive>`
+directive includes the ``poky/meta/recipes-kernel/linux/linux-yocto.inc`` file,
 which has the following statement that defines the default kernel type::
 
    LINUX_KERNEL_TYPE ??= "standard"

documentation/kernel-dev/common.rst

@@ -649,12 +649,12 @@ append files, you can direct the OpenEmbedded build system to use a
 To specify an "in-tree" ``defconfig`` file, use the following statement
 form::
 
-   KBUILD_DEFCONFIG_KMACHINE ?= "defconfig_file"
+   KBUILD_DEFCONFIG:<machine> ?= "defconfig_file"
 
-Here is an example
-that assigns the :term:`KBUILD_DEFCONFIG` variable based on "raspberrypi2"
-and provides the path to the "in-tree" ``defconfig`` file to be used for
-a Raspberry Pi 2, which is based on the Broadcom 2708/2709 chipset::
+Here is an example that assigns the :term:`KBUILD_DEFCONFIG` variable utilizing
+an override for the "raspberrypi2" :term:`MACHINE` and provides the path to the
+"in-tree" ``defconfig`` file to be used for a Raspberry Pi 2, which is based on
+the Broadcom 2708/2709 chipset::
 
    KBUILD_DEFCONFIG:raspberrypi2 ?= "bcm2709_defconfig"
 
@@ -1005,7 +1005,7 @@ Section.
       the following sequence of commands::
 
               $ cd poky/build
-              $ bitbake -c cleanall yocto-linux
+              $ bitbake -c cleanall linux-yocto
               $ bitbake core-image-minimal -c cleanall
               $ bitbake core-image-minimal
               $ runqemu qemux86
@@ -1083,7 +1083,7 @@ Consider an example that configures the "CONFIG_SMP" setting for the
 .. note::
 
    The OpenEmbedded build system recognizes this kernel as ``linux-yocto``
-   through Metadata (e.g. :term:`PREFERRED_VERSION`\ ``_linux-yocto ?= "12.4%"``).
+   through Metadata (e.g. :term:`PREFERRED_VERSION`\ ``_linux-yocto ?= "4.12%"``).
 
 Once ``menuconfig`` launches, use the interface to navigate through the
 selections to find the configuration settings in which you are
@@ -1384,7 +1384,7 @@ 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:
 
--  Requested options that did not make the final ``.config`` file.
+-  Requested options that did not make it into the final ``.config`` file.
 
 -  Configuration items that appear twice in the same configuration
    fragment.

documentation/migration-guides/migration-2.2.rst

@@ -121,11 +121,10 @@ compared to uClibc.
 ``${B}`` No Longer Default Working Directory for Tasks
 ------------------------------------------------------
 
-``${``\ :term:`B`\ ``}`` is no longer the default working
-directory for tasks. Consequently, any custom tasks you define now need
-to either have the
-``[``\ :ref:`dirs <bitbake:bitbake-user-manual/bitbake-user-manual-metadata:variable flags>`\ ``]`` flag
-set, or the task needs to change into the appropriate working directory
+``${``\ :term:`B`\ ``}`` is no longer the default working directory for tasks.
+Consequently, any custom tasks you define now need to either have the
+``[``\ :ref:`dirs <bitbake-user-manual/bitbake-user-manual-metadata:variable flags>`\ ``]``
+flag set, or the task needs to change into the appropriate working directory
 manually (e.g using ``cd`` for a shell task).
 
 .. note::

documentation/migration-guides/migration-2.3.rst

@@ -198,9 +198,9 @@ The following changes took place for BitBake:
    fetcher passes the new parameter through the ``SVN_SSH`` environment
    variable during the :ref:`ref-tasks-fetch` task.
 
-   See the ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-fetching:subversion (svn) fetcher (\`\`svn://\`\`)`"
-   section in the BitBake
-   User Manual for additional information.
+   See the
+   ":ref:`bitbake-user-manual/bitbake-user-manual-fetching:subversion (svn) fetcher (\`\`svn://\`\`)`"
+   section in the BitBake User Manual for additional information.
 
 -  ``BB_SETSCENE_VERIFY_FUNCTION`` and ``BB_SETSCENE_VERIFY_FUNCTION2``
    Removed: Because the mechanism they were part of is no longer

documentation/migration-guides/migration-2.4.rst

@@ -286,7 +286,7 @@ The following are additional changes:
 
 -  BitBake fires multiple "BuildStarted" events when multiconfig is
    enabled (one per configuration). For more information, see the
-   ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata:events`"
+   ":ref:`bitbake-user-manual/bitbake-user-manual-metadata:events`"
    section in the BitBake User Manual.
 
 -  By default, the ``security_flags.inc`` file sets a

documentation/migration-guides/migration-2.6.rst

@@ -274,7 +274,7 @@ The following changes have occurred:
    specifying list items to remove, be aware that leading and trailing
    whitespace resulting from the removal is retained.
 
-   See the ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata:removal (override style syntax)`"
+   See the ":ref:`bitbake-user-manual/bitbake-user-manual-metadata:removal (override style syntax)`"
    section in the BitBake User Manual for a detailed example.
 
 .. _migration-2.6-systemd-configuration-now-split-out-to-system-conf:

documentation/migration-guides/migration-3.4.rst

@@ -45,7 +45,7 @@ would now become::
    BB_TASK_NICE_LEVEL:task-testimage = '0'
 
 This also applies to
-:ref:`variable queries to the datastore <bitbake:bitbake-user-manual/bitbake-user-manual-metadata:functions for accessing datastore variables>`,
+:ref:`variable queries to the datastore <bitbake-user-manual/bitbake-user-manual-metadata:functions for accessing datastore variables>`,
 for example using ``getVar`` and similar so ``d.getVar("RDEPENDS_${PN}")``
 becomes ``d.getVar("RDEPENDS:${PN}")``.
 

documentation/migration-guides/migration-4.0.rst

@@ -207,8 +207,8 @@ For the ``append`` plus ``+=`` (and ``prepend`` plus ``=+``) combinations,
 the content should be prefixed (respectively suffixed) by a space to maintain
 the same behavior.  You can learn more about override style syntax operators
 (``append``, ``prepend`` and ``remove``) in the BitBake documentation:
-:ref:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata:appending and prepending (override style syntax)`
-and :ref:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata:removal (override style syntax)`.
+:ref:`bitbake-user-manual/bitbake-user-manual-metadata:appending and prepending (override style syntax)`
+and :ref:`bitbake-user-manual/bitbake-user-manual-metadata:removal (override style syntax)`.
 
 Miscellaneous changes
 ~~~~~~~~~~~~~~~~~~~~~

documentation/migration-guides/migration-4.2.rst

@@ -9,27 +9,109 @@ Migration notes for 4.2 (mickledore)
 This section provides migration information for moving to the Yocto
 Project 4.2 Release (codename "mickledore") from the prior release.
 
+.. _migration-4.2-supported-distributions:
+
+Supported distributions
+~~~~~~~~~~~~~~~~~~~~~~~
+
+This release supports running BitBake on new GNU/Linux distributions:
+
+-  Fedora 36 and 37
+-  AlmaLinux 8.7 and 9.1
+-  OpenSuse 15.4
+
+On the other hand, some earlier distributions are no longer supported:
+
+-  Debian 10.x
+-  Fedora 34 and 35
+-  AlmaLinux 8.5
+
+See :ref:`all supported distributions <system-requirements-supported-distros>`.
+
 .. _migration-4.2-python-3.8:
 
 Python 3.8 is now the minimum required Python version version
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~------------
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-BitBake and OpenEmbedded-Core are now relying on Python 3.8,
+BitBake and OpenEmbedded-Core now require Python 3.8 or newer,
 making it a requirement to use a distribution providing at least this
-version, or to use :term:`buildtools`.
+version, or to install a :term:`buildtools` tarball.
 
-.. _migration-4.2-qa-checks:
+.. _migration-4.2-gcc-8.0:
 
-QA check changes
-~~~~~~~~~~~~~~~~
+gcc 8.0 is now the minimum required GNU C compiler version
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-.. _migration-4.2-misc-changes:
+This version, released in 2018, is a minimum requirement
+to build the ``mesa-native`` recipe and as the latter is in the
+default dependency chain when building QEMU this has now been
+made a requirement for all builds.
 
-Miscellaneous changes
-~~~~~~~~~~~~~~~~~~~~~
+In the event that your host distribution does not provide this
+or a newer version of gcc, you can install a
+:term:`buildtools-extended` tarball.
+
+.. _migration-4.2-new-nvd-api:
+
+Fetching the NVD vulnerability database through the 2.0 API
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This new version adds a new fetcher for the NVD database using the 2.0 API,
+as the 1.0 API will be retired in 2023.
+
+The implementation changes as little as possible, keeping the current
+database format (but using a different database file for the transition
+period), with a notable exception of not using the META table.
+
+Here are minor changes that you may notice:
+
+-  The database starts in 1999 instead of 2002
+-  The complete fetch is longer (30 minutes typically)
+
+.. _migration-4.2-rust-crate-checksums:
+
+Rust: mandatory checksums for crates
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This release now supports checksums for Rust crates and makes
+them mandatory for each crate in a recipe. See :yocto_git:`python3_bcrypt recipe changes
+</poky/commit/?h=mickledore&id=0dcb5ab3462fdaaf1646b05a00c7150eea711a9a>`
+for example.
+
+The ``cargo-update-recipe-crates`` utility
+:yocto_git:`has been extended </poky/commit/?h=mickledore&id=eef7fbea2c5bf59369390be4d5efa915591b7b22>`
+to include such checksums. So, in case you need to add the list of checksums
+to a recipe just inheriting the :ref:`ref-classes-cargo` class so far, you can
+follow these steps:
+
+#.  Make the recipe inherit :ref:`ref-classes-cargo-update-recipe-crates`
+#.  Remove all ``crate://`` lines from the recipe
+#.  Create an empty ``${BPN}-crates.inc`` file and make your recipe require it
+#.  Execute ``bitbake -c update_crates your_recipe``
+#.  Copy and paste the output of BitBake about the missing checksums into the
+    ``${BPN}-crates.inc`` file.
+
+
+.. _migration-4.2-addpylib:
+
+Python library code extensions
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+BitBake in this release now supports a new ``addpylib`` directive to enable
+Python libraries within layers.
+
+This directive should be added to your layer configuration
+as in the below example from ``meta/conf/layer.conf``::
+
+   addpylib ${LAYERDIR}/lib oe
+
+Layers currently adding a lib directory to extend Python library code should now
+use this directive as :term:`BBPATH` is not going to be added automatically by
+OE-Core in future. Note that the directives are immediate operations, so it does
+make modules available for use sooner than the current BBPATH-based approach.
+
+For more information, see :ref:`bitbake-user-manual/bitbake-user-manual-metadata:extending python library code`.
 
-- The ``OEBasic`` signature handler (see :term:`BB_SIGNATURE_HANDLER`) has been
-  removed.
 
 .. _migration-4.2-removed-variables:
 
@@ -37,7 +119,12 @@ Removed variables
 ~~~~~~~~~~~~~~~~~
 
 The following variables have been removed:
-- ``SERIAL_CONSOLE``, deprecated since version 2.6, replaced by :term:``SERIAL_CONSOLES``.
+
+-  ``SERIAL_CONSOLE``, deprecated since version 2.6, replaced by :term:`SERIAL_CONSOLES`.
+-  ``PACKAGEBUILDPKGD``, a mostly internal variable in the ref:`ref-classes-package`
+   class was rarely used to customise packaging. If you were using this in your custom
+   recipes or bbappends, you will need to switch to using :term:`PACKAGE_PREPROCESS_FUNCS`
+   or :term:`PACKAGESPLITFUNCS` instead.
 
 .. _migration-4.2-removed-recipes:
 
@@ -46,3 +133,144 @@ Removed recipes
 
 The following recipes have been removed in this release:
 
+-  ``python3-picobuild``: after switching to ``python3-build``
+-  ``python3-strict-rfc3339``: unmaintained and not needed by anything in
+   :oe_git:`openembedded-core </openembedded-core>`
+   or :oe_git:`meta-openembedded </meta-openembedded>`.
+-  ``linux-yocto``: removed version 5.19 recipes (6.1 and 5.15 still provided)
+
+
+.. _migration-4.2-removed-classes:
+
+Removed classes
+~~~~~~~~~~~~~~~
+
+The following classes have been removed in this release:
+
+-  ``rust-bin``: no longer used
+-  ``package_tar``: could not be used for actual packaging, and thus not particularly useful.
+
+
+LAYERSERIES_COMPAT for custom layers and devtool workspace
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Some layer maintainers have been setting :term:`LAYERSERIES_COMPAT` in their
+layer's ``conf/layer.conf`` to the value of ``LAYERSERIES_CORENAMES`` to
+effectively bypass the compatibility check - this is no longer permitted.
+Layer maintainers should set :term:`LAYERSERIES_COMPAT` appropriately to
+help users understand the compatibility status of the layer.
+
+Additionally, the :term:`LAYERSERIES_COMPAT` value for the devtool workspace
+layer is now set at the time of creation, thus if you upgrade with the
+workspace layer enabled and you wish to retain it, you will need to manually
+update the :term:`LAYERSERIES_COMPAT` value in ``workspace/conf/layer.conf``
+(or remove the path from :term:`BBLAYERS` in ``conf/bblayers.conf`` and
+delete/move the ``workspace`` directory out of the way if you no longer
+need it).
+
+
+.. _migration-4.2-runqemu-slirp:
+
+runqemu now limits slirp host port forwarding to localhost
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+With default slirp port forwarding configuration in runqemu, qemu
+previously listened on TCP ports 2222 and 2323 on all IP addresses
+available on the build host. Most use cases with runqemu only need
+it for localhost and it is not safe to run qemu images with root
+login without password enabled and listening on all available,
+possibly Internet reachable network interfaces. Thus, in this
+release we limit qemu port forwarding to localhost (127.0.0.1).
+
+However, if you need the qemu machine to be reachable from the
+network, then it can be enabled via ``conf/local.conf`` or machine
+config variable ``QB_SLIRP_OPT``::
+
+   QB_SLIRP_OPT = "-netdev user,id=net0,hostfwd=tcp::2222-:22"
+
+
+.. _migration-4.2-patch-qa:
+
+Patch QA checks
+~~~~~~~~~~~~~~~
+
+The QA checks for patch fuzz and Upstream-Status have been reworked
+slightly in this release. The Upstream-Status checking is now configurable
+from :term:`WARN_QA` / :term:`ERROR_QA` (``patch-status-core`` for the
+core layer, and ``patch-status-noncore`` for other layers).
+
+The ``patch-fuzz`` and ``patch-status-core`` checks are now in the default
+value of :term:`ERROR_QA` so that they will cause the build to fail
+if triggered. If you prefer to avoid this you will need to adjust the value
+of :term:`ERROR_QA` in your configuration as desired.
+
+
+.. _migration-4.2-mesa:
+
+Native/nativesdk mesa usage and graphics drivers
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This release includes mesa 23.0, and with that mesa release it is not longer
+possible to use drivers from the host system, as mesa upstream has added strict
+checks for matching builds between drivers and libraries that load them.
+
+This is particularly relevant when running QEMU built within the build
+system. A check has been added to runqemu so that there is a helpful error
+when there is no native/nativesdk opengl/virgl support available.
+
+To support this, a number of drivers have been enabled when building ``mesa-native``.
+The one major dependency pulled in by this change is ``llvm-native`` which will
+add a few minutes to the build on a modern machine. If this is undesirable, you
+can set the value of :term:`DISTRO_FEATURES_NATIVE` in your configuration such
+that ``opengl`` is excluded.
+
+
+.. _migration-4.2-misc-changes:
+
+Miscellaneous changes
+~~~~~~~~~~~~~~~~~~~~~
+
+-  The :term:`IMAGE_NAME` variable is now set based on :term:`IMAGE_LINK_NAME`. This
+   means that if you are setting :term:`IMAGE_LINK_NAME` to "" to disable unversioned
+   image symlink creation, you also now need to set :term:`IMAGE_NAME` to still have
+   a reasonable value e.g.::
+
+      IMAGE_LINK_NAME = ""
+      IMAGE_NAME = "${IMAGE_BASENAME}${IMAGE_MACHINE_SUFFIX}${IMAGE_VERSION_SUFFIX}"
+
+-  In ``/etc/os-release``, the ``VERSION_CODENAME`` field is now used instead of
+   ``DISTRO_CODENAME`` (though its value is still set from the :term:`DISTRO_CODENAME`
+   variable) for better conformance to standard os-release usage. If you have runtime
+   code reading this from ``/etc/os-release`` it may need to be updated.
+
+-  The kmod recipe now enables OpenSSL support by default in order to support module
+   signing. If you do not need this and wish to reclaim some space/avoid the dependency
+   you should set :term:`PACKAGECONFIG` in a kmod bbappend (or ``PACKAGECONFIG:pn-kmod``
+   at the configuration level) to exclude ``openssl``.
+
+-  The ``OEBasic`` signature handler (see :term:`BB_SIGNATURE_HANDLER`) has been
+   removed. It is unlikely that you would have selected to use this, but if you have
+   you will need to remove this setting.
+
+-  The :ref:`ref-classes-package` class now checks if package names conflict via
+   ``PKG:${PN}`` override during ``do_package``. If you receive the associated error
+   you will need to address the :term:`PKG` usage so that the conflict is resolved.
+
+-  openssh no longer uses :term:`RRECOMMENDS` to pull in ``rng-tools``, since rngd
+   is no longer needed as of Linux kernel 5.6. If you still need ``rng-tools``
+   installed for other reasons, you should add ``rng-tools`` explicitly to your
+   image. If you additionally need rngd to be started as a service you will also
+   need to add the ``rng-tools-service`` package as that has been split out.
+
+-  The cups recipe no longer builds with the web interface enabled, saving ~1.8M of
+   space in the final image. If you wish to enable it, you should set
+   :term:`PACKAGECONFIG` in a cups bbappend (or ``PACKAGECONFIG:pn-cups`` at the
+   configuration level) to include ``webif``.
+
+-  The :ref:`ref-classes-scons` class now passes a ``MAXLINELENGTH`` argument to
+   scons in order to fix an issue with scons and command line lengths when ccache is
+   enabled. However, some recipes may be using older scons versions which don't support
+   this argument. If that is the case you can set the following in the recipe in order
+   to disable this::
+
+      SCONS_MAXLINELENGTH = ""

documentation/migration-guides/release-4.0.rst

@@ -13,3 +13,10 @@ Release 4.0 (kirkstone)
    release-notes-4.0.4
    release-notes-4.0.5
    release-notes-4.0.6
+   release-notes-4.0.7
+   release-notes-4.0.8
+   release-notes-4.0.9
+   release-notes-4.0.10
+   release-notes-4.0.11
+   release-notes-4.0.12
+   release-notes-4.0.13

documentation/migration-guides/release-4.1.rst

@@ -9,3 +9,5 @@ Release 4.1 (langdale)
    release-notes-4.1
    release-notes-4.1.1
    release-notes-4.1.2
+   release-notes-4.1.3
+   release-notes-4.1.4

documentation/migration-guides/release-4.2.rst

@@ -7,3 +7,6 @@ Release 4.2 (mickledore)
 
    migration-4.2
    release-notes-4.2
+   release-notes-4.2.1
+   release-notes-4.2.2
+   release-notes-4.2.3

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

@@ -86,7 +86,7 @@ Fixes in 4.0.1
 -  migration-3.4: add missing entry on :term:`EXTRA_USERS_PARAMS`
 -  migration-guides: add release notes for 4.0
 -  migration-guides: complete migration guide for 4.0
--  migration-guides: release-notes-4.0: mention LTS release
+-  migration-guides: release-notes-4.0: mention :term:`LTS` release
 -  migration-guides: release-notes-4.0: update 'Repositories / Downloads' section
 -  migration-guides: stop including documents with ".. include"
 -  musl: Fix build when usrmerge distro feature is enabled

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

@@ -0,0 +1,180 @@
+.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
+
+Release notes for Yocto-4.0.10 (Kirkstone)
+------------------------------------------
+
+Security Fixes in Yocto-4.0.10
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  binutils: Fix :cve:`2023-1579`, :cve:`2023-1972`, :cve_mitre:`2023-25584`, :cve_mitre:`2023-25585` and :cve_mitre:`2023-25588`
+-  cargo : Ignore :cve:`2022-46176`
+-  connman: Fix :cve:`2023-28488`
+-  curl: Fix :cve:`2023-27533`, :cve:`2023-27534`, :cve:`2023-27535`, :cve:`2023-27536` and :cve:`2023-27538`
+-  ffmpeg: Fix :cve:`2022-48434`
+-  freetype: Fix :cve:`2023-2004`
+-  ghostscript: Fix :cve_mitre:`2023-29979`
+-  git: Fix :cve:`2023-25652` and :cve:`2023-29007`
+-  go: Fix :cve:`2022-41722`, :cve:`2022-41724`, :cve:`2022-41725`, :cve:`2023-24534`, :cve:`2023-24537` and :cve:`2023-24538`
+-  go: Ignore :cve:`2022-41716`
+-  libxml2: Fix :cve:`2023-28484` and :cve:`2023-29469`
+-  libxpm: Fix :cve:`2022-44617`, :cve:`2022-46285` and :cve:`2022-4883`
+-  linux-yocto: Ignore :cve:`2021-3759`, :cve:`2021-4135`, :cve:`2021-4155`, :cve:`2022-0168`, :cve:`2022-0171`, :cve:`2022-1016`, :cve:`2022-1184`, :cve:`2022-1198`, :cve:`2022-1199`, :cve:`2022-1462`, :cve:`2022-1734`, :cve:`2022-1852`, :cve:`2022-1882`, :cve:`2022-1998`, :cve:`2022-2078`, :cve:`2022-2196`, :cve:`2022-2318`, :cve:`2022-2380`, :cve:`2022-2503`, :cve:`2022-26365`, :cve:`2022-2663`, :cve:`2022-2873`, :cve:`2022-2905`, :cve:`2022-2959`, :cve:`2022-3028`, :cve:`2022-3078`, :cve:`2022-3104`, :cve:`2022-3105`, :cve:`2022-3106`, :cve:`2022-3107`, :cve:`2022-3111`, :cve:`2022-3112`, :cve:`2022-3113`, :cve:`2022-3115`, :cve:`2022-3202`, :cve:`2022-32250`, :cve:`2022-32296`, :cve:`2022-32981`, :cve:`2022-3303`, :cve:`2022-33740`, :cve:`2022-33741`, :cve:`2022-33742`, :cve:`2022-33743`, :cve:`2022-33744`, :cve:`2022-33981`, :cve:`2022-3424`, :cve:`2022-3435`, :cve:`2022-34918`, :cve:`2022-3521`, :cve:`2022-3545`, :cve:`2022-3564`, :cve:`2022-3586`, :cve:`2022-3594`, :cve:`2022-36123`, :cve:`2022-3621`, :cve:`2022-3623`, :cve:`2022-3629`, :cve:`2022-3633`, :cve:`2022-3635`, :cve:`2022-3646`, :cve:`2022-3649`, :cve:`2022-36879`, :cve:`2022-36946`, :cve:`2022-3707`, :cve:`2022-39188`, :cve:`2022-39190`, :cve:`2022-39842`, :cve:`2022-40307`, :cve:`2022-40768`, :cve:`2022-4095`, :cve:`2022-41218`, :cve:`2022-4139`, :cve:`2022-41849`, :cve:`2022-41850`, :cve:`2022-41858`, :cve:`2022-42328`, :cve:`2022-42329`, :cve:`2022-42703`, :cve:`2022-42721`, :cve:`2022-42722`, :cve:`2022-42895`, :cve:`2022-4382`, :cve:`2022-4662`, :cve:`2022-47518`, :cve:`2022-47519`, :cve:`2022-47520`, :cve:`2022-47929`, :cve:`2023-0179`, :cve:`2023-0394`, :cve:`2023-0461`, :cve:`2023-0590`, :cve:`2023-1073`, :cve:`2023-1074`, :cve:`2023-1077`, :cve:`2023-1078`, :cve:`2023-1079`, :cve:`2023-1095`, :cve:`2023-1118`, :cve:`2023-1249`, :cve:`2023-1252`, :cve:`2023-1281`, :cve:`2023-1382`, :cve:`2023-1513`, :cve:`2023-1829`, :cve:`2023-1838`, :cve:`2023-1998`, :cve:`2023-2006`, :cve:`2023-2008`, :cve:`2023-2162`, :cve:`2023-2166`, :cve:`2023-2177`, :cve:`2023-22999`, :cve:`2023-23002`, :cve:`2023-23004`, :cve:`2023-23454`, :cve:`2023-23455`, :cve:`2023-23559`, :cve:`2023-25012`, :cve:`2023-26545`, :cve:`2023-28327` and :cve:`2023-28328`
+-  nasm: Fix :cve:`2022-44370`
+-  python3-cryptography: Fix :cve:`2023-23931`
+-  qemu: Ignore :cve:`2023-0664`
+-  ruby: Fix :cve:`2023-28755` and :cve:`2023-28756`
+-  screen: Fix :cve:`2023-24626`
+-  shadow: Fix :cve:`2023-29383`
+-  tiff: Fix :cve:`2022-4645`
+-  webkitgtk: Fix :cve:`2022-32888` and :cve:`2022-32923`
+-  xserver-xorg: Fix :cve:`2023-1393`
+
+
+Fixes in Yocto-4.0.10
+~~~~~~~~~~~~~~~~~~~~~
+
+-  bitbake: bin/utils: Ensure locale en_US.UTF-8 is available on the system
+-  build-appliance-image: Update to kirkstone head revision
+-  cmake: add CMAKE_SYSROOT to generated toolchain file
+-  glibc: stable 2.35 branch updates.
+-  kernel-devsrc: depend on python3-core instead of python3
+-  kernel: improve initramfs bundle processing time
+-  libarchive: Enable acls, xattr for native as well as target
+-  libbsd: Add correct license for all packages
+-  libpam: Fix the xtests/tst-pam_motd[1|3] failures
+-  libxpm: upgrade to 3.5.15
+-  linux-firmware: upgrade to 20230404
+-  linux-yocto/5.15: upgrade to v5.15.108
+-  migration-guides: add release-notes for 4.0.9
+-  oeqa/utils/metadata.py: Fix running oe-selftest running with no distro set
+-  openssl: Move microblaze to linux-latomic config
+-  package.bbclass: correct check for /build in copydebugsources()
+-  poky.conf: bump version for 4.0.10
+-  populate_sdk_base: add zip options
+-  populate_sdk_ext.bbclass: set :term:`METADATA_REVISION` with an :term:`DISTRO` override
+-  run-postinsts: Set dependency for ldconfig to avoid boot issues
+-  update-alternatives.bbclass: fix old override syntax
+-  wic/bootimg-efi: if fixed-size is set then use that for mkdosfs
+-  wpebackend-fdo: upgrade to 1.14.2
+-  xorg-lib-common: Add variable to set tarball type
+-  xserver-xorg: upgrade to 21.1.8
+
+
+Known Issues in Yocto-4.0.10
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+- N/A
+
+
+Contributors to Yocto-4.0.10
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  Archana Polampalli
+-  Arturo Buzarra
+-  Bruce Ashfield
+-  Christoph Lauer
+-  Deepthi Hemraj
+-  Dmitry Baryshkov
+-  Frank de Brabander
+-  Hitendra Prajapati
+-  Joe Slater
+-  Kai Kang
+-  Kyle Russell
+-  Lee Chee Yang
+-  Mark Hatle
+-  Martin Jansa
+-  Mingli Yu
+-  Narpat Mali
+-  Pascal Bach
+-  Pawan Badganchi
+-  Peter Bergin
+-  Peter Marko
+-  Piotr Łobacz
+-  Randolph Sapp
+-  Ranjitsinh Rathod
+-  Ross Burton
+-  Shubham Kulkarni
+-  Siddharth Doshi
+-  Steve Sakoman
+-  Sundeep KOKKONDA
+-  Thomas Roos
+-  Virendra Thakur
+-  Vivek Kumbhar
+-  Wang Mingyu
+-  Xiangyu Chen
+-  Yash Shinde
+-  Yoann Congal
+-  Yogita Urade
+-  Zhixiong Chi
+
+
+Repositories / Downloads for Yocto-4.0.10
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+poky
+
+-  Repository Location: :yocto_git:`/poky`
+-  Branch: :yocto_git:`kirkstone </poky/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.10 </poky/log/?h=yocto-4.0.10>`
+-  Git Revision: :yocto_git:`f53ab3a2ff206a130cdc843839dd0ea5ec4ad02f </poky/commit/?id=f53ab3a2ff206a130cdc843839dd0ea5ec4ad02f>`
+-  Release Artefact: poky-f53ab3a2ff206a130cdc843839dd0ea5ec4ad02f
+-  sha: 8820aeac857ce6bbd1c7ef26cadbb86eca02be93deded253b4a5f07ddd69255d
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.10/poky-f53ab3a2ff206a130cdc843839dd0ea5ec4ad02f.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.10/poky-f53ab3a2ff206a130cdc843839dd0ea5ec4ad02f.tar.bz2
+
+openembedded-core
+
+-  Repository Location: :oe_git:`/openembedded-core`
+-  Branch: :oe_git:`kirkstone </openembedded-core/log/?h=kirkstone>`
+-  Tag:  :oe_git:`yocto-4.0.10 </openembedded-core/log/?h=yocto-4.0.10>`
+-  Git Revision: :oe_git:`d2713785f9cd2d58731df877bc8b7bcc71b6c8e6 </openembedded-core/commit/?id=d2713785f9cd2d58731df877bc8b7bcc71b6c8e6>`
+-  Release Artefact: oecore-d2713785f9cd2d58731df877bc8b7bcc71b6c8e6
+-  sha: 78e084a1aceaaa6ec022702f29f80eaffade3159e9c42b6b8985c1b7ddd2fbab
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.10/oecore-d2713785f9cd2d58731df877bc8b7bcc71b6c8e6.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.10/oecore-d2713785f9cd2d58731df877bc8b7bcc71b6c8e6.tar.bz2
+
+meta-mingw
+
+-  Repository Location: :yocto_git:`/meta-mingw`
+-  Branch: :yocto_git:`kirkstone </meta-mingw/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.10 </meta-mingw/log/?h=yocto-4.0.10>`
+-  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.10/meta-mingw-a90614a6498c3345704e9611f2842eb933dc51c1.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.10/meta-mingw-a90614a6498c3345704e9611f2842eb933dc51c1.tar.bz2
+
+meta-gplv2
+
+-  Repository Location: :yocto_git:`/meta-gplv2`
+-  Branch: :yocto_git:`kirkstone </meta-gplv2/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.10 </meta-gplv2/log/?h=yocto-4.0.10>`
+-  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.10/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.10/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2
+
+bitbake
+
+-  Repository Location: :oe_git:`/bitbake`
+-  Branch: :oe_git:`2.0 </bitbake/log/?h=2.0>`
+-  Tag:  :oe_git:`yocto-4.0.10 </bitbake/log/?h=yocto-4.0.10>`
+-  Git Revision: :oe_git:`0c6f86b60cfba67c20733516957c0a654eb2b44c </bitbake/commit/?id=0c6f86b60cfba67c20733516957c0a654eb2b44c>`
+-  Release Artefact: bitbake-0c6f86b60cfba67c20733516957c0a654eb2b44c
+-  sha: 4caa94ee4d644017b0cc51b702e330191677f7d179018cbcec8b1793949ebc74
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.10/bitbake-0c6f86b60cfba67c20733516957c0a654eb2b44c.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.10/bitbake-0c6f86b60cfba67c20733516957c0a654eb2b44c.tar.bz2
+
+yocto-docs
+
+-  Repository Location: :yocto_git:`/yocto-docs`
+-  Branch: :yocto_git:`kirkstone </yocto-docs/log/?h=kirkstone>`
+-  Tag: :yocto_git:`yocto-4.0.10 </yocto-docs/log/?h=yocto-4.0.10>`
+-  Git Revision: :yocto_git:`8388be749806bd0bf4fccf1005dae8f643aa4ef4 </yocto-docs/commit/?id=8388be749806bd0bf4fccf1005dae8f643aa4ef4>`
+

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

@@ -0,0 +1,214 @@
+.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
+
+Release notes for Yocto-4.0.11 (Kirkstone)
+------------------------------------------
+
+Security Fixes in Yocto-4.0.11
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  cups: Fix :cve:`2023-32324`
+-  curl: Fix :cve:`2023-28319`, :cve:`2023-28320`, :cve:`2023-28321` and :cve:`2023-28322`
+-  git: Ignore :cve:`2023-25815`
+-  go: Fix :cve:`2023-24539` and :cve:`2023-24540`
+-  nasm: Fix :cve:`2022-46457`
+-  openssh: Fix :cve:`2023-28531`
+-  openssl: Fix :cve:`2023-1255` and :cve:`2023-2650`
+-  perl: Fix :cve:`2023-31484`
+-  python3-requests: Fix for :cve:`2023-32681`
+-  sysstat: Fix :cve:`2023-33204`
+-  vim: Fix :cve:`2023-2426`
+-  webkitgtk: fix :cve:`2022-42867`, :cve:`2022-46691`, :cve:`2022-46699` and :cve:`2022-46700`
+
+
+Fixes in Yocto-4.0.11
+~~~~~~~~~~~~~~~~~~~~~
+
+-  Revert "docs: conf.py: fix cve extlinks caption for sphinx <4.0"
+-  Revert "ipk: Decode byte data to string in manifest handling"
+-  avahi: fix D-Bus introspection
+-  build-appliance-image: Update to kirkstone head revision
+-  conf.py: add macro for Mitre CVE links
+-  conf: add nice level to the hash config ignred variables
+-  cpio: Fix wrong CRC with ASCII CRC for large files
+-  cve-update-nvd2-native: added the missing http import
+-  cve-update-nvd2-native: new CVE database fetcher
+-  dhcpcd: use git instead of tarballs
+-  e2fsprogs: fix ptest bug for second running
+-  gcc-runtime: Use static dummy libstdc++
+-  glibc: stable 2.35 branch updates (cbceb903c4d7)
+-  go.bbclass: don't use test to check output from ls
+-  gstreamer1.0: Upgrade to 1.20.6
+-  iso-codes: Upgrade to 4.15.0
+-  kernel-devicetree: allow specification of dtb directory
+-  kernel-devicetree: make shell scripts posix compliant
+-  kernel-devicetree: recursively search for dtbs
+-  kernel: don't force PAHOLE=false
+-  kmscube: Correct :term:`DEPENDS` to avoid overwrite
+-  lib/terminal.py: Add urxvt terminal
+-  license.bbclass: Include :term:`LICENSE` in the output when it fails to parse
+-  linux-yocto/5.10: Upgrade to v5.10.180
+-  linux-yocto/5.15: Upgrade to v5.15.113
+-  llvm: backport a fix for build with gcc-13
+-  maintainers.inc: Fix email address typo
+-  maintainers.inc: Move repo to unassigned
+-  migration-guides: add release notes for 4.0.10
+-  migration-guides: use new cve_mitre macro
+-  nghttp2: Deleted the entries for -client and -server, and removed a dependency on them from the main package.
+-  oeqa/selftest/cases/devtool.py: skip all tests require folder a git repo
+-  openssh: Remove BSD-4-clause contents completely from codebase
+-  openssl: Upgrade to 3.0.9
+-  overview-manual: concepts.rst: Fix a typo
+-  p11-kit: add native to :term:`BBCLASSEXTEND`
+-  package: enable recursion on file globs
+-  package_manager/ipk: fix config path generation in _create_custom_config()
+-  piglit: Add :term:`PACKAGECONFIG` for glx and opencl
+-  piglit: Add missing glslang dependencies
+-  piglit: Fix build time dependency
+-  poky.conf: bump version for 4.0.11
+-  profile-manual: fix blktrace remote usage instructions
+-  quilt: Fix merge.test race condition
+-  ref-manual: add clarification for :term:`SRCREV`
+-  selftest/reproducible: Allow native/cross reuse in test
+-  staging.bbclass: do not add extend_recipe_sysroot to prefuncs of prepare_recipe_sysroot
+-  systemd-networkd: backport fix for rm unmanaged wifi
+-  systemd-systemctl: fix instance template WantedBy symlink construction
+-  systemd-systemctl: support instance expansion in WantedBy
+-  uninative: Upgrade to 3.10 to support gcc 13
+-  uninative: Upgrade to 4.0 to include latest gcc 13.1.1
+-  vim: Upgrade to 9.0.1527
+-  waffle: Upgrade to 1.7.2
+-  weston: add xwayland to :term:`DEPENDS` for :term:`PACKAGECONFIG` xwayland
+
+
+Known Issues in Yocto-4.0.11
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+- N/A
+
+
+Contributors to Yocto-4.0.11
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  Alexander Kanavin
+-  Andrew Jeffery
+-  Archana Polampalli
+-  Bhabu Bindu
+-  Bruce Ashfield
+-  C. Andy Martin
+-  Chen Qi
+-  Daniel Ammann
+-  Deepthi Hemraj
+-  Ed Beroset
+-  Eero Aaltonen
+-  Enrico Jörns
+-  Hannu Lounento
+-  Hitendra Prajapati
+-  Ian Ray
+-  Jan Luebbe
+-  Jan Vermaete
+-  Khem Raj
+-  Lee Chee Yang
+-  Lei Maohui
+-  Lorenzo Arena
+-  Marek Vasut
+-  Marta Rybczynska
+-  Martin Jansa
+-  Martin Siegumfeldt
+-  Michael Halstead
+-  Michael Opdenacker
+-  Ming Liu
+-  Narpat Mali
+-  Omkar Patil
+-  Pablo Saavedra
+-  Pavel Zhukov
+-  Peter Kjellerstedt
+-  Peter Marko
+-  Qiu Tingting
+-  Quentin Schulz
+-  Randolph Sapp
+-  Randy MacLeod
+-  Ranjitsinh Rathod
+-  Richard Purdie
+-  Riyaz Khan
+-  Sakib Sajal
+-  Sanjay Chitroda
+-  Soumya Sambu
+-  Steve Sakoman
+-  Thomas Roos
+-  Tom Hochstein
+-  Vivek Kumbhar
+-  Wang Mingyu
+-  Yogita Urade
+-  Zoltan Boszormenyi
+
+
+Repositories / Downloads for Yocto-4.0.11
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+poky
+
+-  Repository Location: :yocto_git:`/poky`
+-  Branch: :yocto_git:`kirkstone </poky/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.11 </poky/log/?h=yocto-4.0.11>`
+-  Git Revision: :yocto_git:`fc697fe87412b9b179ae3a68d266ace85bb1fcc6 </poky/commit/?id=fc697fe87412b9b179ae3a68d266ace85bb1fcc6>`
+-  Release Artefact: poky-fc697fe87412b9b179ae3a68d266ace85bb1fcc6
+-  sha: d42ab1b76b9d8ab164d86dc0882c908658f6b5be0742b13a71531068f6a5ee98
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.11/poky-fc697fe87412b9b179ae3a68d266ace85bb1fcc6.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.11/poky-fc697fe87412b9b179ae3a68d266ace85bb1fcc6.tar.bz2
+
+openembedded-core
+
+-  Repository Location: :oe_git:`/openembedded-core`
+-  Branch: :oe_git:`kirkstone </openembedded-core/log/?h=kirkstone>`
+-  Tag:  :oe_git:`yocto-4.0.11 </openembedded-core/log/?h=yocto-4.0.11>`
+-  Git Revision: :oe_git:`7949e786cf8e50f716ff1f1c4797136637205e0c </openembedded-core/commit/?id=7949e786cf8e50f716ff1f1c4797136637205e0c>`
+-  Release Artefact: oecore-7949e786cf8e50f716ff1f1c4797136637205e0c
+-  sha: 3bda3f7d15961bad5490faf3194709528591a97564b5eae3da7345b63be20334
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.11/oecore-7949e786cf8e50f716ff1f1c4797136637205e0c.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.11/oecore-7949e786cf8e50f716ff1f1c4797136637205e0c.tar.bz2
+
+meta-mingw
+
+-  Repository Location: :yocto_git:`/meta-mingw`
+-  Branch: :yocto_git:`kirkstone </meta-mingw/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.11 </meta-mingw/log/?h=yocto-4.0.11>`
+-  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.11/meta-mingw-a90614a6498c3345704e9611f2842eb933dc51c1.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.11/meta-mingw-a90614a6498c3345704e9611f2842eb933dc51c1.tar.bz2
+
+meta-gplv2
+
+-  Repository Location: :yocto_git:`/meta-gplv2`
+-  Branch: :yocto_git:`kirkstone </meta-gplv2/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.11 </meta-gplv2/log/?h=yocto-4.0.11>`
+-  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.11/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.11/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2
+
+bitbake
+
+-  Repository Location: :oe_git:`/bitbake`
+-  Branch: :oe_git:`2.0 </bitbake/log/?h=2.0>`
+-  Tag:  :oe_git:`yocto-4.0.11 </bitbake/log/?h=yocto-4.0.11>`
+-  Git Revision: :oe_git:`0c6f86b60cfba67c20733516957c0a654eb2b44c </bitbake/commit/?id=0c6f86b60cfba67c20733516957c0a654eb2b44c>`
+-  Release Artefact: bitbake-0c6f86b60cfba67c20733516957c0a654eb2b44c
+-  sha: 4caa94ee4d644017b0cc51b702e330191677f7d179018cbcec8b1793949ebc74
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.11/bitbake-0c6f86b60cfba67c20733516957c0a654eb2b44c.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.11/bitbake-0c6f86b60cfba67c20733516957c0a654eb2b44c.tar.bz2
+
+yocto-docs
+
+-  Repository Location: :yocto_git:`/yocto-docs`
+-  Branch: :yocto_git:`kirkstone </yocto-docs/log/?h=kirkstone>`
+-  Tag: :yocto_git:`yocto-4.0.11 </yocto-docs/log/?h=yocto-4.0.11>`
+-  Git Revision: :yocto_git:`6d16d2bde0aa32276a035ee49703e6eea7c7b29a </yocto-docs/commit/?id=6d16d2bde0aa32276a035ee49703e6eea7c7b29a>`
+

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

@@ -0,0 +1,277 @@
+.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
+
+Release notes for Yocto-4.0.12 (Kirkstone)
+------------------------------------------
+
+Security Fixes in Yocto-4.0.12
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  bind: Fix :cve:`2023-2828` and :cve:`2023-2911`
+-  cups: Fix :cve:`2023-34241`
+-  curl: Added :cve:`2023-28320` Follow-up patch
+-  dbus: Fix :cve:`2023-34969`
+-  dmidecode: fix :cve:`2023-30630`
+-  ghostscript: fix :cve:`2023-36664`
+-  go: fix :cve_mitre:`2023-24531`, :cve:`2023-24536`, :cve:`2023-29400`, :cve:`2023-29402`, :cve:`2023-29404`, :cve:`2023-29405` and :cve:`2023-29406`
+-  libarchive: Ignore :cve:`2023-30571`
+-  libcap: Fix :cve:`2023-2602` and :cve:`2023-2603`
+-  libjpeg-turbo: Fix :cve:`2023-2804`
+-  libpcre2: Fix :cve:`2022-41409`
+-  libtiff: fix :cve:`2023-26965`
+-  libwebp: Fix :cve:`2023-1999`
+-  libx11: Fix :cve:`2023-3138`
+-  libxpm: Fix :cve:`2022-44617`
+-  ninja: Ignore :cve:`2021-4336`
+-  openssh: Fix :cve:`2023-38408`
+-  openssl: Fix :cve:`2023-2975`, :cve:`2023-3446` and :cve:`2023-3817`
+-  perl: Fix :cve:`2023-31486`
+-  python3: Ignore :cve:`2023-36632`
+-  qemu: Fix :cve:`2023-0330`, :cve_mitre:`2023-2861`, :cve_mitre:`2023-3255` and :cve_mitre:`2023-3301`
+-  sqlite3: Fix :cve:`2023-36191`
+-  tiff: Fix :cve:`2023-0795`, :cve:`2023-0796`, :cve:`2023-0797`, :cve:`2023-0798`, :cve:`2023-0799`, :cve:`2023-25433`, :cve:`2023-25434` and :cve:`2023-25435`
+-  vim: :cve:`2023-2609` and :cve:`2023-2610`
+
+
+Fixes in Yocto-4.0.12
+~~~~~~~~~~~~~~~~~~~~~
+
+-  babeltrace2: Always use BFD linker when building tests with ld-is-lld distro feature
+-  babeltrace2: upgrade to 2.0.5
+-  bitbake.conf: add unzstd in :term:`HOSTTOOLS`
+-  bitbake: bitbake-layers: initialize tinfoil before registering command line arguments
+-  bitbake: runqueue: Fix deferred task/multiconfig race issue
+-  blktrace: ask for python3 specifically
+-  build-appliance-image: Update to kirkstone head revision
+-  cmake: Fix CMAKE_SYSTEM_PROCESSOR setting for SDK
+-  connman: fix warning by specifying runstatedir at configure time
+-  cpio: Replace fix wrong CRC with ASCII CRC for large files with upstream backport
+-  cve-update-nvd2-native: actually use API keys
+-  cve-update-nvd2-native: always pass str for json.loads()
+-  cve-update-nvd2-native: fix cvssV3 metrics
+-  cve-update-nvd2-native: handle all configuration nodes, not just first
+-  cve-update-nvd2-native: increase retry count
+-  cve-update-nvd2-native: log a little more
+-  cve-update-nvd2-native: retry all errors and sleep between retries
+-  cve-update-nvd2-native: use exact times, don't truncate
+-  dbus: upgrade to 1.14.8
+-  devtool: Fix the wrong variable in srcuri_entry
+-  diffutils: upgrade to 3.10
+-  docs: ref-manual: terms: fix typos in :term:`SPDX` term
+-  fribidi: upgrade to 1.0.13
+-  gcc: upgrade to v11.4
+-  gcc-testsuite: Fix ppc cpu specification
+-  gcc: don't pass --enable-standard-branch-protection
+-  gcc: fix runpath errors in cc1 binary
+-  grub: submit determinism.patch upstream
+-  image_types: Fix reproducible builds for initramfs and UKI img
+-  kernel: add missing path to search for debug files
+-  kmod: remove unused ptest.patch
+-  layer.conf: Add missing dependency exclusion
+-  libassuan: upgrade to 2.5.6
+-  libksba: upgrade to 1.6.4
+-  libpng: Add ptest for libpng
+-  libxcrypt: fix build with perl-5.38 and use master branch
+-  libxcrypt: fix hard-coded ".so" extension
+-  libxpm: upgrade to 3.5.16
+-  linux-firmware: upgrade to 20230515
+-  linux-yocto/5.10: cfg: fix DECNET configuration warning
+-  linux-yocto/5.10: update to v5.10.185
+-  linux-yocto/5.15: cfg: fix DECNET configuration warning
+-  linux-yocto/5.15: update to v5.15.120
+-  logrotate: Do not create logrotate.status file
+-  lttng-ust: upgrade to 2.13.6
+-  machine/arch-arm64: add -mbranch-protection=standard
+-  maintainers.inc: correct Carlos Rafael Giani's email address
+-  maintainers.inc: correct unassigned entries
+-  maintainers.inc: unassign Adrian Bunk from wireless-regdb
+-  maintainers.inc: unassign Alistair Francis from opensbi
+-  maintainers.inc: unassign Andreas Müller from itstool entry
+-  maintainers.inc: unassign Pascal Bach from cmake entry
+-  maintainers.inc: unassign Ricardo Neri from ovmf
+-  maintainers.inc: unassign Richard Weinberger from erofs-utils entry
+-  mdadm: fix 07revert-inplace ptest
+-  mdadm: fix segfaults when running ptests
+-  mdadm: fix util-linux ptest dependency
+-  mdadm: skip running known broken ptests
+-  meson.bbclass: Point to llvm-config from native sysroot
+-  meta: lib: oe: npm_registry: Add more safe caracters
+-  migration-guides: add release notes for 4.0.11
+-  minicom: remove unused patch files
+-  mobile-broadband-provider-info: upgrade to 20230416
+-  oe-depends-dot: Handle new format for task-depends.dot
+-  oeqa/runtime/cases/rpm: fix wait_for_no_process_for_user failure case
+-  oeqa/selftest/bbtests: add non-existent prefile/postfile tests
+-  oeqa/selftest/devtool: add unit test for "devtool add -b"
+-  openssl: Upgrade to 3.0.10
+-  openssl: add PERLEXTERNAL path to test its existence
+-  openssl: use a glob on the PERLEXTERNAL to track updates on the path
+-  package.bbclass: moving field data process before variable process in process_pkgconfig
+-  pm-utils: fix multilib conflictions
+-  poky.conf: bump version for 4.0.12
+-  psmisc: Set :term:`ALTERNATIVE` for pstree to resolve conflict with busybox
+-  pybootchartgui: show elapsed time for each task
+-  python3: fix missing comma in get_module_deps3.py
+-  python3: upgrade to 3.10.12
+-  recipetool: Fix inherit in created -native* recipes
+-  ref-manual: add LTS and Mixin terms
+-  ref-manual: document image-specific variant of :term:`INCOMPATIBLE_LICENSE`
+-  ref-manual: release-process: update for LTS releases
+-  rust-llvm: backport a fix for build with gcc-13
+-  scripts/runqemu: allocate unfsd ports in a way that doesn't race or clash with unrelated processes
+-  scripts/runqemu: split lock dir creation into a reusable function
+-  sdk.py: error out when moving file fails
+-  sdk.py: fix moving dnf contents
+-  selftest reproducible.py: support different build targets
+-  selftest/license: Exclude from world
+-  selftest/reproducible: Allow chose the package manager
+-  serf: upgrade to 1.3.10
+-  strace: Disable failing test
+-  strace: Merge two similar patches
+-  strace: Update patches/tests with upstream fixes
+-  sysfsutils: fetch a supported fork from github
+-  systemd-systemctl: fix errors in instance name expansion
+-  systemd: Backport nspawn: make sure host root can write to the uidmapped mounts we prepare for the container payload
+-  tzdata: upgrade to 2023c
+-  uboot-extlinux-config.bbclass: fix old override syntax in comment
+-  unzip: fix configure check for cross compilation
+-  useradd-staticids.bbclass: improve error message
+-  util-linux: add alternative links for ipcs,ipcrm
+-  v86d: Improve kernel dependency
+-  vim: upgrade to 9.0.1592
+-  wget: upgrade to 1.21.4
+-  wic: Add dependencies for erofs-utils
+-  wireless-regdb: upgrade to 2023.05.03
+-  xdpyinfo: upgrade to 1.3.4
+-  zip: fix configure check by using _Static_assert
+
+
+Known Issues in Yocto-4.0.12
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+- N/A
+
+
+Contributors to Yocto-4.0.12
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  Alberto Planas
+-  Alexander Kanavin
+-  Alexander Sverdlin
+-  Andrej Valek
+-  Archana Polampalli
+-  BELOUARGA Mohamed
+-  Benjamin Bouvier
+-  Bruce Ashfield
+-  Charlie Wu
+-  Chen Qi
+-  Etienne Cordonnier
+-  Fabien Mahot
+-  Frieder Paape
+-  Frieder Schrempf
+-  Heiko Thole
+-  Hitendra Prajapati
+-  Jermain Horsman
+-  Jose Quaresma
+-  Kai Kang
+-  Khem Raj
+-  Lee Chee Yang
+-  Marc Ferland
+-  Marek Vasut
+-  Martin Jansa
+-  Mauro Queiros
+-  Michael Opdenacker
+-  Mikko Rapeli
+-  Nikhil R
+-  Ovidiu Panait
+-  Peter Marko
+-  Poonam Jadhav
+-  Quentin Schulz
+-  Richard Purdie
+-  Ross Burton
+-  Rusty Howell
+-  Sakib Sajal
+-  Soumya Sambu
+-  Steve Sakoman
+-  Sundeep KOKKONDA
+-  Tim Orling
+-  Tom Hochstein
+-  Trevor Gamblin
+-  Vijay Anusuri
+-  Vivek Kumbhar
+-  Wang Mingyu
+-  Xiangyu Chen
+-  Yoann Congal
+-  Yogita Urade
+-  Yuta Hayama
+
+
+Repositories / Downloads for Yocto-4.0.12
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+poky
+
+-  Repository Location: :yocto_git:`/poky`
+-  Branch: :yocto_git:`kirkstone </poky/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.12 </poky/log/?h=yocto-4.0.12>`
+-  Git Revision: :yocto_git:`d6b8790370500b99ca11f0d8a05c39b661ab2ba6 </poky/commit/?id=d6b8790370500b99ca11f0d8a05c39b661ab2ba6>`
+-  Release Artefact: poky-d6b8790370500b99ca11f0d8a05c39b661ab2ba6
+-  sha: 35f0390e0c5a12f403ed471c0b1254c13cbb9d7c7b46e5a3538e63e36c1ac280
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.12/poky-d6b8790370500b99ca11f0d8a05c39b661ab2ba6.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.12/poky-d6b8790370500b99ca11f0d8a05c39b661ab2ba6.tar.bz2
+
+openembedded-core
+
+-  Repository Location: :oe_git:`/openembedded-core`
+-  Branch: :oe_git:`kirkstone </openembedded-core/log/?h=kirkstone>`
+-  Tag:  :oe_git:`yocto-4.0.12 </openembedded-core/log/?h=yocto-4.0.12>`
+-  Git Revision: :oe_git:`e1a604db8d2cf8782038b4016cc2e2052467333b </openembedded-core/commit/?id=e1a604db8d2cf8782038b4016cc2e2052467333b>`
+-  Release Artefact: oecore-e1a604db8d2cf8782038b4016cc2e2052467333b
+-  sha: 8b302eb3f3ffe5643f88bc6e4ae8f9a5cda63544d67e04637ecc4197e9750a1d
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.12/oecore-e1a604db8d2cf8782038b4016cc2e2052467333b.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.12/oecore-e1a604db8d2cf8782038b4016cc2e2052467333b.tar.bz2
+
+meta-mingw
+
+-  Repository Location: :yocto_git:`/meta-mingw`
+-  Branch: :yocto_git:`kirkstone </meta-mingw/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.12 </meta-mingw/log/?h=yocto-4.0.12>`
+-  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.12/meta-mingw-a90614a6498c3345704e9611f2842eb933dc51c1.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.12/meta-mingw-a90614a6498c3345704e9611f2842eb933dc51c1.tar.bz2
+
+meta-gplv2
+
+-  Repository Location: :yocto_git:`/meta-gplv2`
+-  Branch: :yocto_git:`kirkstone </meta-gplv2/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.12 </meta-gplv2/log/?h=yocto-4.0.12>`
+-  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.12/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.12/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2
+
+bitbake
+
+-  Repository Location: :oe_git:`/bitbake`
+-  Branch: :oe_git:`2.0 </bitbake/log/?h=2.0>`
+-  Tag:  :oe_git:`yocto-4.0.12 </bitbake/log/?h=yocto-4.0.12>`
+-  Git Revision: :oe_git:`41b6684489d0261753344956042be2cc4adb0159 </bitbake/commit/?id=41b6684489d0261753344956042be2cc4adb0159>`
+-  Release Artefact: bitbake-41b6684489d0261753344956042be2cc4adb0159
+-  sha: efa2b1c4d0be115ed3960750d1e4ed958771b2db6d7baee2d13ad386589376e8
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.12/bitbake-41b6684489d0261753344956042be2cc4adb0159.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.12/bitbake-41b6684489d0261753344956042be2cc4adb0159.tar.bz2
+
+yocto-docs
+
+-  Repository Location: :yocto_git:`/yocto-docs`
+-  Branch: :yocto_git:`kirkstone </yocto-docs/log/?h=kirkstone>`
+-  Tag: :yocto_git:`yocto-4.0.12 </yocto-docs/log/?h=yocto-4.0.12>`
+-  Git Revision: :yocto_git:`4dfef81ac6164764c6541e39a9fef81d49227096 </yocto-docs/commit/?id=4dfef81ac6164764c6541e39a9fef81d49227096>`
+

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

@@ -0,0 +1,242 @@
+.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
+
+Release notes for Yocto-4.0.7 (Kirkstone)
+-----------------------------------------
+
+Security Fixes in Yocto-4.0.7
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  binutils: Fix :cve:`2022-4285`
+-  curl: Fix :cve:`2022-43551` and `CVE-2022-43552 <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-43552>`__
+-  ffmpeg: Fix :cve:`2022-3109` and :cve:`2022-3341`
+-  go: Fix :cve:`2022-41715` and :cve:`2022-41717`
+-  libX11: Fix :cve:`2022-3554` and :cve:`2022-3555`
+-  libarchive: Fix :cve:`2022-36227`
+-  libksba: Fix :cve:`2022-47629`
+-  libpng: Fix :cve:`2019-6129`
+-  libxml2: Fix :cve:`2022-40303` and :cve:`2022-40304`
+-  openssl: Fix :cve:`2022-3996`
+-  python3: Fix :cve:`2022-45061`
+-  python3-git: Fix :cve:`2022-24439`
+-  python3-setuptools: Fix :cve:`2022-40897`
+-  python3-wheel: Fix :cve:`2022-40898`
+-  qemu: Fix :cve:`2022-4144`
+-  sqlite: Fix :cve:`2022-46908`
+-  systemd: Fix :cve:`2022-45873`
+-  vim: Fix :cve:`2023-0049`, :cve:`2023-0051`, :cve:`2023-0054` and :cve:`2023-0088`
+-  webkitgtk: Fix :cve:`2022-32886`, `CVE-2022-32891 <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-32891>`__ and :cve:`2022-32912`
+
+
+Fixes in Yocto-4.0.7
+~~~~~~~~~~~~~~~~~~~~
+
+-  Revert "gstreamer1.0: disable flaky gstbin:test_watch_for_state_change test"
+-  at: Change when files are copied
+-  baremetal-image: Avoid overriding qemu variables from IMAGE_CLASSES
+-  base.bbclass: Fix way to check ccache path
+-  bc: extend to nativesdk
+-  bind: upgrade to 9.18.10
+-  busybox: always start do_compile with orig config files
+-  busybox: rm temporary files if do_compile was interrupted
+-  cairo: fix CVE patches assigned wrong CVE number
+-  cairo: update patch for :cve:`2019-6461` with upstream solution
+-  classes/create-spdx: Add SPDX_PRETTY option
+-  classes: image: Set empty weak default IMAGE_LINGUAS
+-  combo-layer: add sync-revs command
+-  combo-layer: dont use bb.utils.rename
+-  combo-layer: remove unused import
+-  curl: Correct LICENSE from MIT-open-group to curl
+-  cve-check: write the cve manifest to IMGDEPLOYDIR
+-  cve-update-db-native: avoid incomplete updates
+-  cve-update-db-native: show IP on failure
+-  dbus: Add missing CVE product name
+-  devtool/upgrade: correctly handle recipes where S is a subdir of upstream tree
+-  devtool: process local files only for the main branch
+-  dhcpcd: backport two patches to fix runtime error
+-  docs: kernel-dev: faq: update tip on how to not include kernel in image
+-  docs: migration-4.0: specify variable name change for kernel inclusion in image recipe
+-  efibootmgr: update compilation with musl
+-  externalsrc: fix lookup for .gitmodules
+-  ffmpeg: refresh patches to apply cleanly
+-  freetype:update mirror site.
+-  gcc: Refactor linker patches and fix linker on arm with usrmerge
+-  glibc: stable 2.35 branch updates.
+-  go-crosssdk: avoid host contamination by GOCACHE
+-  gstreamer1.0: Fix race conditions in gstbin tests
+-  gstreamer1.0: upgrade to 1.20.5
+-  gtk-icon-cache: Fix GTKIC_CMD if-else condition
+-  harfbuzz: remove bindir only if it exists
+-  kernel-fitimage: Adjust order of dtb/dtbo files
+-  kernel-fitimage: Allow user to select dtb when multiple dtb exists
+-  kernel.bbclass: remove empty module directories to prevent QA issues
+-  lib/buildstats: fix parsing of trees with reduced_proc_pressure directories
+-  lib/oe/reproducible: Use git log without gpg signature
+-  libepoxy: remove upstreamed patch
+-  libnewt: update 0.52.21 -> 0.52.23
+-  libseccomp: fix typo in DESCRIPTION
+-  libxcrypt-compat: upgrade 4.4.30 -> 4.4.33
+-  libxml2: fix test data checksums
+-  linux-firmware: upgrade 20221109 -> 20221214
+-  linux-yocto/5.10: update to v5.10.152
+-  linux-yocto/5.10: update to v5.10.154
+-  linux-yocto/5.10: update to v5.10.160
+-  linux-yocto/5.15: fix perf build with clang
+-  linux-yocto/5.15: libbpf: Fix build warning on ref_ctr_off
+-  linux-yocto/5.15: ltp and squashfs fixes
+-  linux-yocto/5.15: powerpc: Fix reschedule bug in KUAP-unlocked user copy
+-  linux-yocto/5.15: update to v5.15.84
+-  lsof: add update-alternatives logic
+-  lttng-modules: update 2.13.7 -> 2.13.8
+-  manuals: add 4.0.5 and 4.0.6 release notes
+-  manuals: document SPDX_PRETTY variable
+-  mpfr: upgrade 4.1.0 -> 4.1.1
+-  oeqa/concurrencytest: Add number of failures to summary output
+-  oeqa/rpm.py: Increase timeout and add debug output
+-  oeqa/selftest/externalsrc: add test for srctree_hash_files
+-  openssh: remove RRECOMMENDS to rng-tools for sshd package
+-  poky.conf: bump version for 4.0.7
+-  qemuboot.bbclass: make sure runqemu boots bundled initramfs kernel image
+-  rm_work.bbclass: use HOSTTOOLS 'rm' binary exclusively
+-  rm_work: adjust dependency to make do_rm_work_all depend on do_rm_work
+-  ruby: merge .inc into .bb
+-  ruby: update 3.1.2 -> 3.1.3
+-  selftest/virgl: use pkg-config from the host
+-  tiff: Add packageconfig knob for webp
+-  toolchain-scripts: compatibility with unbound variable protection
+-  tzdata: update 2022d -> 2022g
+-  valgrind: skip the boost_thread test on arm
+-  xserver-xorg: upgrade 21.1.4 -> 21.1.6
+-  xwayland: libxshmfence is needed when dri3 is enabled
+-  xwayland: upgrade 22.1.5 -> 22.1.7
+-  yocto-check-layer: Allow OE-Core to be tested
+
+
+Known Issues in Yocto-4.0.7
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+- N/A
+
+
+Contributors to Yocto-4.0.7
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  Alejandro Hernandez Samaniego
+-  Alex Kiernan
+-  Alex Stewart
+-  Alexander Kanavin
+-  Antonin Godard
+-  Benoît Mauduit
+-  Bhabu Bindu
+-  Bruce Ashfield
+-  Carlos Alberto Lopez Perez
+-  Changqing Li
+-  Chen Qi
+-  Daniel Gomez
+-  Florin Diaconescu
+-  He Zhe
+-  Hitendra Prajapati
+-  Jagadeesh Krishnanjanappa
+-  Jan Kircher
+-  Jermain Horsman
+-  Jose Quaresma
+-  Joshua Watt
+-  KARN JYE LAU
+-  Kai Kang
+-  Khem Raj
+-  Luis
+-  Marta Rybczynska
+-  Martin Jansa
+-  Mathieu Dubois-Briand
+-  Michael Opdenacker
+-  Narpat Mali
+-  Ovidiu Panait
+-  Pavel Zhukov
+-  Peter Marko
+-  Petr Kubizňák
+-  Quentin Schulz
+-  Randy MacLeod
+-  Ranjitsinh Rathod
+-  Richard Purdie
+-  Robert Andersson
+-  Ross Burton
+-  Sandeep Gundlupet Raju
+-  Saul Wold
+-  Steve Sakoman
+-  Vivek Kumbhar
+-  Wang Mingyu
+-  Xiangyu Chen
+-  Yash Shinde
+-  Yogita Urade
+
+
+Repositories / Downloads for Yocto-4.0.7
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+poky
+
+-  Repository Location: :yocto_git:`/poky`
+-  Branch: :yocto_git:`kirkstone </poky/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.7 </poky/log/?h=yocto-4.0.7>`
+-  Git Revision: :yocto_git:`65dafea22018052fe7b2e17e6e4d7eb754224d38 </poky/commit/?id=65dafea22018052fe7b2e17e6e4d7eb754224d38>`
+-  Release Artefact: poky-65dafea22018052fe7b2e17e6e4d7eb754224d38
+-  sha: 6b1b67600b84503e2d5d29bcd6038547339f4f9413b830cd2408df825eda642d
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.7/poky-65dafea22018052fe7b2e17e6e4d7eb754224d38.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.7/poky-65dafea22018052fe7b2e17e6e4d7eb754224d38.tar.bz2
+
+openembedded-core
+
+-  Repository Location: :oe_git:`/openembedded-core`
+-  Branch: :oe_git:`kirkstone </openembedded-core/log/?h=kirkstone>`
+-  Tag:  :oe_git:`yocto-4.0.7 </openembedded-core/log/?h=yocto-4.0.7>`
+-  Git Revision: :oe_git:`a8c82902384f7430519a31732a4bb631f21693ac </openembedded-core/commit/?id=a8c82902384f7430519a31732a4bb631f21693ac>`
+-  Release Artefact: oecore-a8c82902384f7430519a31732a4bb631f21693ac
+-  sha: 6f2dbc4ea1e388620ef77ac3a7bbb2b5956bb8bf9349b0c16cd7610e9996f5ea
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.7/oecore-a8c82902384f7430519a31732a4bb631f21693ac.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.7/oecore-a8c82902384f7430519a31732a4bb631f21693ac.tar.bz2
+
+meta-mingw
+
+-  Repository Location: :yocto_git:`/meta-mingw`
+-  Branch: :yocto_git:`kirkstone </meta-mingw/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.7 </meta-mingw/log/?h=yocto-4.0.7>`
+-  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.7/meta-mingw-a90614a6498c3345704e9611f2842eb933dc51c1.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.7/meta-mingw-a90614a6498c3345704e9611f2842eb933dc51c1.tar.bz2
+
+meta-gplv2
+
+-  Repository Location: :yocto_git:`/meta-gplv2`
+-  Branch: :yocto_git:`kirkstone </meta-gplv2/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.7 </meta-gplv2/log/?h=yocto-4.0.7>`
+-  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.7/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.7/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2
+
+bitbake
+
+-  Repository Location: :oe_git:`/bitbake`
+-  Branch: :oe_git:`2.0 </bitbake/log/?h=2.0>`
+-  Tag:  :oe_git:`yocto-4.0.7 </bitbake/log/?h=yocto-4.0.7>`
+-  Git Revision: :oe_git:`7e268c107bb0240d583d2c34e24a71e373382509 </bitbake/commit/?id=7e268c107bb0240d583d2c34e24a71e373382509>`
+-  Release Artefact: bitbake-7e268c107bb0240d583d2c34e24a71e373382509
+-  sha: c3e2899012358c95962c7a5c85cf98dc30c58eae0861c374124e96d9556bb901
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.7/bitbake-7e268c107bb0240d583d2c34e24a71e373382509.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.7/bitbake-7e268c107bb0240d583d2c34e24a71e373382509.tar.bz2
+
+yocto-docs
+
+-  Repository Location: :yocto_git:`/yocto-docs`
+-  Branch: :yocto_git:`kirkstone </yocto-docs/log/?h=kirkstone>`
+-  Tag: :yocto_git:`yocto-4.0.7 </yocto-docs/log/?h=yocto-4.0.7>`
+-  Git Revision: :yocto_git:`5883e897c34f25401b358a597fb6e18d80f7f90b </yocto-docs/commit/?id=5883e897c34f25401b358a597fb6e18d80f7f90b>`
+
+

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

@@ -0,0 +1,217 @@
+.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
+
+Release notes for Yocto-4.0.8 (Kirkstone)
+-----------------------------------------
+
+Security Fixes in Yocto-4.0.8
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  apr-util: Fix :cve:`2022-25147`
+-  apr: Fix :cve:`2022-24963`, :cve:`2022-28331` and :cve:`2021-35940`
+-  bind: Fix :cve:`2022-3094`, :cve:`2022-3736` and :cve:`2022-3924`
+-  git: Ignore :cve:`2022-41953`
+-  git: Fix :cve:`2022-23521` and :cve:`2022-41903`
+-  libgit2: Fix :cve:`2023-22742`
+-  ppp: Fix :cve:`2022-4603`
+-  python3-certifi: Fix :cve:`2022-23491`
+-  sudo: Fix :cve:`2023-22809`
+-  tar: Fix :cve:`2022-48303`
+
+
+Fixes in Yocto-4.0.8
+~~~~~~~~~~~~~~~~~~~~
+
+-  core-image.bbclass: Fix missing leading whitespace with ':append'
+-  populate_sdk_ext.bbclass: Fix missing leading whitespace with ':append'
+-  ptest-packagelists.inc: Fix missing leading whitespace with ':append'
+-  apr-util: upgrade to 1.6.3
+-  apr: upgrade to 1.7.2
+-  apt: fix do_package_qa failure
+-  bind: upgrade to 9.18.11
+-  bitbake: bb/utils: include SSL certificate paths in export_proxies
+-  bitbake: bitbake-diffsigs: Make PEP8 compliant
+-  bitbake: bitbake-diffsigs: break on first dependent task difference
+-  bitbake: fetch2/git: Clarify the meaning of namespace
+-  bitbake: fetch2/git: Prevent git fetcher from fetching gitlab repository metadata
+-  bitbake: fetch2/git: show SRCREV and git repo in error message about fixed SRCREV
+-  bitbake: siggen: Fix inefficient string concatenation
+-  bitbake: utils/ply: Update md5 to better report errors with hashlib
+-  bootchart2: Fix usrmerge support
+-  bsp-guide: fix broken git URLs and missing word
+-  build-appliance-image: Update to kirkstone head revision
+-  buildtools-tarball: set pkg-config search path
+-  classes/fs-uuid: Fix command output decoding issue
+-  dev-manual: common-tasks.rst: add link to FOSDEM 2023 video
+-  dev-manual: fix old override syntax
+-  devshell: Do not add scripts/git-intercept to PATH
+-  devtool: fix devtool finish when gitmodules file is empty
+-  diffutils: upgrade to 3.9
+-  gdk-pixbuf: do not use tools from gdk-pixbuf-native when building tests
+-  git: upgrade to 2.35.7
+-  glslang: branch rename master -> main
+-  httpserver: add error handler that write to the logger
+-  image.bbclass: print all QA functions exceptions
+-  kernel/linux-kernel-base: Fix kernel build artefact determinism issues
+-  libc-locale: Fix on target locale generation
+-  libgit2: upgrade to 1.4.5
+-  libjpeg-turbo: upgrade to 2.1.5
+-  libtirpc: Check if file exists before operating on it
+-  libusb1: Link with latomic only if compiler has no atomic builtins
+-  libusb1: Strip trailing whitespaces
+-  linux-firmware: upgrade to 20230117
+-  linux-yocto/5.15: update to v5.15.91
+-  lsof: fix old override syntax
+-  lttng-modules: Fix for 5.10.163 kernel version
+-  lttng-tools: upgrade to 2.13.9
+-  make-mod-scripts: Ensure kernel build output is deterministic
+-  manuals: update patchwork instance URL
+-  meta: remove True option to getVar and getVarFlag calls (again)
+-  migration-guides: add release-notes for 4.0.7
+-  native: Drop special variable handling
+-  numactl: skip test case when target platform doesn't have 2 CPU node
+-  oeqa context.py: fix --target-ip comment to include ssh port number
+-  oeqa dump.py: add error counter and stop after 5 failures
+-  oeqa qemurunner.py: add timeout to QMP calls
+-  oeqa qemurunner.py: try to avoid reading one character at a time
+-  oeqa qemurunner: read more data at a time from serial
+-  oeqa ssh.py: add connection keep alive options to ssh client
+-  oeqa ssh.py: move output prints to new line
+-  oeqa/qemurunner: do not use Popen.poll() when terminating runqemu with a signal
+-  oeqa/selftest/bbtests: Update message lookup for test_git_unpack_nonetwork_fail
+-  oeqa/selftest/locales: Add selftest for locale generation/presence
+-  poky.conf: Update SANITY_TESTED_DISTROS to match autobuilder
+-  poky.conf: bump version for 4.0.8
+-  profile-manual: update WireShark hyperlinks
+-  python3-pytest: depend on python3-tomli instead of python3-toml
+-  qemu: fix compile error
+-  quilt: fix intermittent failure in faildiff.test
+-  quilt: use upstreamed faildiff.test fix
+-  recipe_sanity: fix old override syntax
+-  ref-manual: document SSTATE_EXCLUDEDEPS_SYSROOT
+-  scons.bbclass: Make MAXLINELENGTH overridable
+-  scons: Pass MAXLINELENGTH to scons invocation
+-  sdkext/cases/devtool: pass a logger to HTTPService
+-  spirv-headers: set correct branch name
+-  sudo: upgrade to 1.9.12p2
+-  system-requirements.rst: add Fedora 36 and AlmaLinux 8.7 to list of supported distros
+-  testimage: Fix error message to reflect new syntax
+-  update-alternatives: fix typos
+-  vulkan-samples: branch rename master -> main
+
+
+Known Issues in Yocto-4.0.8
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+- N/A
+
+
+Contributors to Yocto-4.0.8
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  Alejandro Hernandez Samaniego
+-  Alexander Kanavin
+-  Alexandre Belloni
+-  Armin Kuster
+-  Arnout Vandecappelle
+-  Bruce Ashfield
+-  Changqing Li
+-  Chee Yang Lee
+-  Etienne Cordonnier
+-  Harald Seiler
+-  Kai Kang
+-  Khem Raj
+-  Lee Chee Yang
+-  Louis Rannou
+-  Marek Vasut
+-  Marius Kriegerowski
+-  Mark Hatle
+-  Martin Jansa
+-  Mauro Queiros
+-  Michael Opdenacker
+-  Mikko Rapeli
+-  Mingli Yu
+-  Narpat Mali
+-  Niko Mauno
+-  Pawel Zalewski
+-  Peter Kjellerstedt
+-  Richard Purdie
+-  Rodolfo Quesada Zumbado
+-  Ross Burton
+-  Sakib Sajal
+-  Schmidt, Adriaan
+-  Steve Sakoman
+-  Thomas Roos
+-  Ulrich Ölmann
+-  Xiangyu Chen
+
+
+Repositories / Downloads for Yocto-4.0.8
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+poky
+
+-  Repository Location: :yocto_git:`/poky`
+-  Branch: :yocto_git:`kirkstone </poky/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.8 </poky/log/?h=yocto-4.0.8>`
+-  Git Revision: :yocto_git:`a361fb3df9c87cf12963a9d785a9f99faa839222 </poky/commit/?id=a361fb3df9c87cf12963a9d785a9f99faa839222>`
+-  Release Artefact: poky-a361fb3df9c87cf12963a9d785a9f99faa839222
+-  sha: af4e8d64be27d3a408357c49b7952ce04c6d8bb0b9d7b50c48848d9355de7fc2
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.8/poky-a361fb3df9c87cf12963a9d785a9f99faa839222.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.8/poky-a361fb3df9c87cf12963a9d785a9f99faa839222.tar.bz2
+
+openembedded-core
+
+-  Repository Location: :oe_git:`/openembedded-core`
+-  Branch: :oe_git:`kirkstone </openembedded-core/log/?h=kirkstone>`
+-  Tag:  :oe_git:`yocto-4.0.8 </openembedded-core/log/?h=yocto-4.0.8>`
+-  Git Revision: :oe_git:`b20e2134daec33fbb8ce358d984751d887752bd5 </openembedded-core/commit/?id=b20e2134daec33fbb8ce358d984751d887752bd5>`
+-  Release Artefact: oecore-b20e2134daec33fbb8ce358d984751d887752bd5
+-  sha: 63cce6f1caf8428eefc1471351ab024affc8a41d8d7777f525e3aa9ea454d2cd
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.8/oecore-b20e2134daec33fbb8ce358d984751d887752bd5.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.8/oecore-b20e2134daec33fbb8ce358d984751d887752bd5.tar.bz2
+
+meta-mingw
+
+-  Repository Location: :yocto_git:`/meta-mingw`
+-  Branch: :yocto_git:`kirkstone </meta-mingw/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.8 </meta-mingw/log/?h=yocto-4.0.8>`
+-  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.8/meta-mingw-a90614a6498c3345704e9611f2842eb933dc51c1.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.8/meta-mingw-a90614a6498c3345704e9611f2842eb933dc51c1.tar.bz2
+
+meta-gplv2
+
+-  Repository Location: :yocto_git:`/meta-gplv2`
+-  Branch: :yocto_git:`kirkstone </meta-gplv2/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.8 </meta-gplv2/log/?h=yocto-4.0.8>`
+-  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.8/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.8/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2
+
+bitbake
+
+-  Repository Location: :oe_git:`/bitbake`
+-  Branch: :oe_git:`2.0 </bitbake/log/?h=2.0>`
+-  Tag:  :oe_git:`yocto-4.0.8 </bitbake/log/?h=yocto-4.0.8>`
+-  Git Revision: :oe_git:`9bbdedc0ba7ca819b898e2a29a151d6a2014ca11 </bitbake/commit/?id=9bbdedc0ba7ca819b898e2a29a151d6a2014ca11>`
+-  Release Artefact: bitbake-9bbdedc0ba7ca819b898e2a29a151d6a2014ca11
+-  sha: 8e724411f4df00737e81b33eb568f1f97d2a00d5364342c0a212c46abb7b005b
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.8/bitbake-9bbdedc0ba7ca819b898e2a29a151d6a2014ca11.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.8/bitbake-9bbdedc0ba7ca819b898e2a29a151d6a2014ca11.tar.bz2
+
+yocto-docs
+
+-  Repository Location: :yocto_git:`/yocto-docs`
+-  Branch: :yocto_git:`kirkstone </yocto-docs/log/?h=kirkstone>`
+-  Tag: :yocto_git:`yocto-4.0.8 </yocto-docs/log/?h=yocto-4.0.8>`
+-  Git Revision: :yocto_git:`16ecbe028f2b9cc021267817a5413054e070b563 </yocto-docs/commit/?id=16ecbe028f2b9cc021267817a5413054e070b563>`
+

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

@@ -0,0 +1,249 @@
+.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
+
+Release notes for Yocto-4.0.9 (Kirkstone)
+-----------------------------------------
+
+Security Fixes in Yocto-4.0.9
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  binutils: Fix :cve:`2023-22608`
+-  curl: Fix :cve:`2023-23914`, :cve:`2023-23915` and :cve:`2023-23916`
+-  epiphany: Fix :cve:`2023-26081`
+-  git: Ignore :cve:`2023-22743`
+-  glibc: Fix  :cve:`2023-0687`
+-  gnutls: Fix :cve:`2023-0361`
+-  go: Fix :cve:`2022-2879`, :cve:`2022-41720` and :cve:`2022-41723`
+-  harfbuzz: Fix :cve:`2023-25193`
+-  less: Fix :cve:`2022-46663`
+-  libmicrohttpd: Fix :cve:`2023-27371`
+-  libsdl2: Fix :cve:`2022-4743`
+-  openssl: Fix :cve:`2022-3996`, :cve:`2023-0464`, :cve:`2023-0465` and :cve:`2023-0466`
+-  pkgconf: Fix :cve:`2023-24056`
+-  python3: Fix :cve:`2023-24329`
+-  shadow: Ignore :cve:`2016-15024`
+-  systemd: Fix :cve:`2022-4415`
+-  tiff: Fix :cve:`2023-0800`, :cve:`2023-0801`, :cve:`2023-0802`, :cve:`2023-0803` and :cve:`2023-0804`
+-  vim: Fix :cve:`2023-0433`, :cve:`2023-0512`, :cve:`2023-1127`, :cve:`2023-1170`, :cve:`2023-1175`, :cve:`2023-1264` and :cve:`2023-1355`
+-  xserver-xorg: Fix :cve:`2023-0494`
+-  xwayland: Fix :cve:`2023-0494`
+
+
+Fixes in Yocto-4.0.9
+~~~~~~~~~~~~~~~~~~~~
+
+-  base-files: Drop localhost.localdomain from hosts file
+-  binutils: Fix nativesdk ld.so search
+-  bitbake: cookerdata: Drop dubious exception handling code
+-  bitbake: cookerdata: Improve early exception handling
+-  bitbake: cookerdata: Remove incorrect SystemExit usage
+-  bitbake: fetch/git: Fix local clone url to make it work with repo
+-  bitbake: utils: Allow to_boolean to support int values
+-  bmap-tools: switch to main branch
+-  buildtools-tarball: Handle spaces within user $PATH
+-  busybox: Fix depmod patch
+-  cracklib: update github branch to 'main'
+-  cups: add/fix web interface packaging
+-  cups: check PACKAGECONFIG for pam feature
+-  cups: use BUILDROOT instead of DESTDIR
+-  curl: fix dependencies when building with ldap/ldaps
+-  cve-check: Fix false negative version issue
+-  dbus: upgrade to 1.14.6
+-  devtool/upgrade: do not delete the workspace/recipes directory
+-  dhcpcd: Fix install conflict when enable multilib.
+-  dhcpcd: fix dhcpcd start failure on qemuppc64
+-  gcc-shared-source: do not use ${S}/.. in deploy_source_date_epoch
+-  glibc: Add missing binutils dependency
+-  image_types: fix multiubi var init
+-  iso-codes: upgrade to  4.13.0
+-  json-c: Add ptest for json-c
+-  kernel-yocto: fix kernel-meta data detection
+-  lib/buildstats: handle tasks that never finished
+-  lib/resulttool: fix typo breaking resulttool log --ptest
+-  libjpeg-turbo: upgrade to 2.1.5.1
+-  libmicrohttpd: upgrade to 0.9.76
+-  libseccomp: fix for the ptest result format
+-  libssh2: Clean up ptest patch/coverage
+-  linux-firmware: add yamato fw files to qcom-adreno-a2xx package
+-  linux-firmware: properly set license for all Qualcomm firmware
+-  linux-firmware: upgrade to 20230210
+-  linux-yocto-rt/5.15: update to -rt59
+-  linux-yocto/5.10: upgrade to v5.10.175
+-  linux-yocto/5.15: upgrade to v5.15.103
+-  linux: inherit pkgconfig in kernel.bbclass
+-  lttng-modules: fix for kernel 6.2+
+-  lttng-modules: upgrade to v2.13.9
+-  lua: Fix install conflict when enable multilib.
+-  mdadm: Fix raid0, 06wrmostly and 02lineargrow tests
+-  meson: Fix wrapper handling of implicit setup command
+-  migration-guides: add 4.0.8 release notes
+-  nghttp2: never build python bindings
+-  oeqa rtc.py: skip if read-only-rootfs
+-  oeqa ssh.py: fix hangs in run()
+-  oeqa/sdk: Improve Meson test
+-  oeqa/selftest/prservice: Improve debug output for failure
+-  oeqa/selftest/resulttooltests: fix minor typo
+-  openssl: upgrade to 3.0.8
+-  package.bbclase: Add check for /build in copydebugsources()
+-  patchelf: replace a rejected patch with an equivalent uninative.bbclass tweak
+-  poky.conf: bump version for 4.0.9
+-  populate_sdk_ext: Handle spaces within user $PATH
+-  pybootchartui: Fix python syntax issue
+-  python3-git: fix indent error
+-  python3-setuptools-rust-native: Add direct dependency of native python3 modules
+-  qemu: Revert "fix :cve:`2021-3507`" as not applicable for qemu 6.2
+-  rsync: Add missing prototypes to function declarations
+-  rsync: Turn on -pedantic-errors at the end of 'configure'
+-  runqemu: kill qemu if it hangs
+-  scripts/lib/buildstats: handle top-level build_stats not being complete
+-  selftest/recipetool: Stop test corrupting tinfoil class
+-  selftest/runtime_test/virgl: Disable for all Rocky Linux
+-  selftest: devtool: set BB_HASHSERVE_UPSTREAM when setting SSTATE_MIRROR
+-  sstatesig: Improve output hash calculation
+-  staging/multilib: Fix manifest corruption
+-  staging: Separate out different multiconfig manifests
+-  sudo: update 1.9.12p2 -> 1.9.13p3
+-  systemd.bbclass: Add /usr/lib/systemd to searchpaths as well
+-  systemd: add group sgx to udev package
+-  systemd: fix wrong nobody-group assignment
+-  timezone: use 'tz' subdir instead of ${WORKDIR} directly
+-  toolchain-scripts: Handle spaces within user $PATH
+-  tzcode-native: fix build with gcc-13 on host
+-  tzdata: use separate B instead of WORKDIR for zic output
+-  uninative: upgrade to 3.9 to include libgcc and glibc 2.37
+-  vala: Fix install conflict when enable multilib.
+-  vim: add missing pkgconfig inherit
+-  vim: set modified-by to the recipe MAINTAINER
+-  vim: upgrade to 9.0.1429
+-  wic: Fix usage of fstype=none in wic
+-  wireless-regdb: upgrade to 2023.02.13
+-  xserver-xorg: upgrade to 21.1.7
+-  xwayland: upgrade to 22.1.8
+
+
+Known Issues in Yocto-4.0.9
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+- N/A
+
+
+Contributors to Yocto-4.0.9
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  Alexander Kanavin
+-  Alexis Lothoré
+-  Bruce Ashfield
+-  Changqing Li
+-  Chee Yang Lee
+-  Dmitry Baryshkov
+-  Federico Pellegrin
+-  Geoffrey GIRY
+-  Hitendra Prajapati
+-  Hongxu Jia
+-  Joe Slater
+-  Kai Kang
+-  Kenfe-Mickael Laventure
+-  Khem Raj
+-  Martin Jansa
+-  Mateusz Marciniec
+-  Michael Halstead
+-  Michael Opdenacker
+-  Mikko Rapeli
+-  Ming Liu
+-  Mingli Yu
+-  Narpat Mali
+-  Pavel Zhukov
+-  Pawan Badganchi
+-  Peter Marko
+-  Piotr Łobacz
+-  Poonam Jadhav
+-  Randy MacLeod
+-  Richard Purdie
+-  Robert Yang
+-  Romuald Jeanne
+-  Ross Burton
+-  Sakib Sajal
+-  Saul Wold
+-  Shubham Kulkarni
+-  Siddharth Doshi
+-  Simone Weiss
+-  Steve Sakoman
+-  Tim Orling
+-  Tom Hochstein
+-  Trevor Woerner
+-  Ulrich Ölmann
+-  Vivek Kumbhar
+-  Wang Mingyu
+-  Xiangyu Chen
+-  Yash Shinde
+
+
+Repositories / Downloads for Yocto-4.0.9
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+poky
+
+-  Repository Location: :yocto_git:`/poky`
+-  Branch: :yocto_git:`kirkstone </poky/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.9 </poky/log/?h=yocto-4.0.9>`
+-  Git Revision: :yocto_git:`09def309f91929f47c6cce386016ccb777bd2cfc </poky/commit/?id=09def309f91929f47c6cce386016ccb777bd2cfc>`
+-  Release Artefact: poky-09def309f91929f47c6cce386016ccb777bd2cfc
+-  sha: 5c7ce209c8a6b37ec2898e5ca21858234d91999c11fa862880ba98e8bde62f63
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.9/poky-09def309f91929f47c6cce386016ccb777bd2cfc.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.9/poky-09def309f91929f47c6cce386016ccb777bd2cfc.tar.bz2
+
+openembedded-core
+
+-  Repository Location: :oe_git:`/openembedded-core`
+-  Branch: :oe_git:`kirkstone </openembedded-core/log/?h=kirkstone>`
+-  Tag:  :oe_git:`yocto-4.0.9 </openembedded-core/log/?h=yocto-4.0.9>`
+-  Git Revision: :oe_git:`ff4b57ffff903a93b710284c7c7f916ddd74712f </openembedded-core/commit/?id=ff4b57ffff903a93b710284c7c7f916ddd74712f>`
+-  Release Artefact: oecore-ff4b57ffff903a93b710284c7c7f916ddd74712f
+-  sha: 726778ffc291136db1704316b196de979f68df9f96476b785e1791957fbb66b3
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.9/oecore-ff4b57ffff903a93b710284c7c7f916ddd74712f.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.9/oecore-ff4b57ffff903a93b710284c7c7f916ddd74712f.tar.bz2
+
+meta-mingw
+
+-  Repository Location: :yocto_git:`/meta-mingw`
+-  Branch: :yocto_git:`kirkstone </meta-mingw/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.9 </meta-mingw/log/?h=yocto-4.0.9>`
+-  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.9/meta-mingw-a90614a6498c3345704e9611f2842eb933dc51c1.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.9/meta-mingw-a90614a6498c3345704e9611f2842eb933dc51c1.tar.bz2
+
+meta-gplv2
+
+-  Repository Location: :yocto_git:`/meta-gplv2`
+-  Branch: :yocto_git:`kirkstone </meta-gplv2/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.9 </meta-gplv2/log/?h=yocto-4.0.9>`
+-  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.9/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.9/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2
+
+bitbake
+
+-  Repository Location: :oe_git:`/bitbake`
+-  Branch: :oe_git:`2.0 </bitbake/log/?h=2.0>`
+-  Tag:  :oe_git:`yocto-4.0.9 </bitbake/log/?h=yocto-4.0.9>`
+-  Git Revision: :oe_git:`2802adb572eb73a3eb2725a74a9bbdaafc543fa7 </bitbake/commit/?id=2802adb572eb73a3eb2725a74a9bbdaafc543fa7>`
+-  Release Artefact: bitbake-2802adb572eb73a3eb2725a74a9bbdaafc543fa7
+-  sha: 5c6e713b5e26b3835c0773095c7a1bc1f8affa28316b33597220ed86f1f1b643
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.9/bitbake-2802adb572eb73a3eb2725a74a9bbdaafc543fa7.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.9/bitbake-2802adb572eb73a3eb2725a74a9bbdaafc543fa7.tar.bz2
+
+yocto-docs
+
+-  Repository Location: :yocto_git:`/yocto-docs`
+-  Branch: :yocto_git:`kirkstone </yocto-docs/log/?h=kirkstone>`
+-  Tag: :yocto_git:`yocto-4.0.9 </yocto-docs/log/?h=yocto-4.0.9>`
+-  Git Revision: :yocto_git:`86d0b38a97941ad52b1af220c7b801a399d50e93 </yocto-docs/commit/?id=86d0b38a97941ad52b1af220c7b801a399d50e93>`
+

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

@@ -115,7 +115,7 @@ New Features / Enhancements in 4.0
 
    - Fetcher enhancements:
    
-      - New :ref:`bitbake:bitbake-user-manual/bitbake-user-manual-fetching:crate fetcher (\`\`crate://\`\`)` for Rust packages
+      - New :ref:`bitbake-user-manual/bitbake-user-manual-fetching:crate fetcher (\`\`crate://\`\`)` for Rust packages
       - Added striplevel support to unpack
       - git: Add a warning asking users to set a branch in git urls
       - git: Allow git fetcher to support subdir param

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

@@ -0,0 +1,317 @@
+.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
+
+Release notes for Yocto-4.1.3 (Langdale)
+----------------------------------------
+
+Security Fixes in Yocto-4.1.3
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  apr-util: Fix :cve:`2022-25147`
+-  apr: Fix :cve:`2022-24963` and :cve:`2022-28331`
+-  bind: Fix :cve:`2022-3094`, :cve:`2022-3736` and :cve:`2022-3924`
+-  curl: Fix :cve:`2022-43551` and :cve:`2022-43552`
+-  dbus: Fix :cve:`2022-42010`, :cve:`2022-42011` and :cve:`2022-42012`
+-  git: Fix  :cve:`2022-23521`, :cve:`2022-39253`, :cve:`2022-39260` and :cve:`2022-41903`
+-  git: Ignore :cve:`2022-41953`
+-  go: Fix :cve:`2022-41717` and :cve:`2022-41720`
+-  grub2: Fix :cve:`2022-2601` and :cve:`2022-3775`
+-  less: Fix :cve:`2022-46663`
+-  libarchive: Fix :cve:`2022-36227`
+-  libksba: Fix :cve:`2022-47629`
+-  openssl: Fix :cve:`2022-3996`
+-  pkgconf: Fix :cve:`2023-24056`
+-  ppp: Fix :cve:`2022-4603`
+-  sudo: Fix :cve:`2023-22809`
+-  tar: Fix :cve:`2022-48303`
+-  vim: Fix :cve:`2023-0049`, :cve:`2023-0051`, :cve:`2023-0054`, :cve:`2023-0288`, :cve:`2023-0433` and :cve:`2023-0512`
+-  xserver-xorg: Fix `CVE-2023-0494 <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-0494>`__
+-  xwayland: Fix `CVE-2023-0494 <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-0494>`__
+
+
+Fixes in Yocto-4.1.3
+~~~~~~~~~~~~~~~~~~~~
+
+-  apr-util: Upgrade to 1.6.3
+-  apr: Upgrade to 1.7.2
+-  apt: fix do_package_qa failure
+-  at: Change when files are copied
+-  base.bbclass: Fix way to check ccache path
+-  bblayers/makesetup: skip git repos that are submodules
+-  bblayers/setupwriters/oe-setup-layers: create dir if not exists
+-  bind: Upgrade to 9.18.11
+-  bitbake-layers: fix a typo
+-  bitbake: bb/utils: include SSL certificate paths in export_proxies
+-  bitbake: fetch2/git: Clarify the meaning of namespace
+-  bitbake: fetch2/git: Prevent git fetcher from fetching gitlab repository metadata
+-  bitbake: process: log odd unlink events with bitbake.sock
+-  bitbake: server/process: Add bitbake.sock race handling
+-  bitbake: siggen: Fix inefficient string concatenation
+-  bootchart2: Fix usrmerge support
+-  bsp-guide: fix broken git URLs and missing word
+-  build-appliance-image: Update to langdale head revision
+-  buildtools-tarball: set pkg-config search path
+-  busybox: Fix depmod patch
+-  busybox: always start do_compile with orig config files
+-  busybox: rm temporary files if do_compile was interrupted
+-  cairo: fix CVE patches assigned wrong CVE number
+-  classes/fs-uuid: Fix command output decoding issue
+-  classes/populate_sdk_base: Append cleandirs
+-  classes: image: Set empty weak default IMAGE_LINGUAS
+-  cml1: remove redundant addtask
+-  core-image.bbclass: Fix missing leading whitespace with ':append'
+-  createrepo-c: Include missing rpm/rpmstring.h
+-  curl: don't enable debug builds
+-  curl: fix dependencies when building with ldap/ldaps
+-  cve-check: write the cve manifest to IMGDEPLOYDIR
+-  cve-update-db-native: avoid incomplete updates
+-  cve-update-db-native: show IP on failure
+-  dbus: Upgrade to 1.14.6
+-  dev-manual: common-tasks.rst: add link to FOSDEM 2023 video
+-  dev-manual: fix old override syntax
+-  devshell: Do not add scripts/git-intercept to PATH
+-  devtool: fix devtool finish when gitmodules file is empty
+-  devtool: process local files only for the main branch
+-  dhcpcd: backport two patches to fix runtime error
+-  dhcpcd: fix dhcpcd start failure on qemuppc64
+-  diffutils: Upgrade to 3.9
+-  ffmpeg: fix configure failure on noexec /tmp host
+-  gdk-pixbuf: do not use tools from gdk-pixbuf-native when building tests
+-  git: Upgrade to 2.37.6
+-  glslang: branch rename master -> main
+-  go: Upgrade to 1.19.4
+-  gstreamer1.0 : Revert  "disable flaky gstbin:test_watch_for_state_change test" and Fix race conditions in gstbin tests with upstream solution
+-  harfbuzz: remove bindir only if it exists
+-  httpserver: add error handler that write to the logger
+-  image.bbclass: print all QA functions exceptions
+-  kernel-fitimage: Adjust order of dtb/dtbo files
+-  kernel-fitimage: Allow user to select dtb when multiple dtb exists
+-  kernel-yocto: fix kernel-meta data detection
+-  kernel/linux-kernel-base: Fix kernel build artefact determinism issues
+-  lib/buildstats: handle tasks that never finished
+-  lib/oe/reproducible: Use git log without gpg signature
+-  libarchive: Upgrade to 3.6.2
+-  libc-locale: Fix on target locale generation
+-  libgit2: Upgrade to 1.5.1
+-  libjpeg-turbo: Upgrade to 2.1.5.1
+-  libksba: Upgrade to 1.6.3
+-  libpng: Enable NEON for aarch64 to enensure consistency with arm32.
+-  librsvg: Only enable the Vala bindings if GObject Introspection is enabled
+-  librsvg: enable vapi build
+-  libseccomp: fix for the ptest result format
+-  libseccomp: fix typo in DESCRIPTION
+-  libssh2: Clean up ptest patch/coverage
+-  libtirpc: Check if file exists before operating on it
+-  libusb1: Link with latomic only if compiler has no atomic builtins
+-  libusb1: Strip trailing whitespaces
+-  linux-firmware: add yamato fw files to qcom-adreno-a2xx package
+-  linux-firmware: properly set license for all Qualcomm firmware
+-  linux-firmware: Upgrade to 20230210
+-  linux-yocto/5.15: fix perf build with clang
+-  linux-yocto/5.15: libbpf: Fix build warning on ref_ctr_off
+-  linux-yocto/5.15: ltp and squashfs fixes
+-  linux-yocto/5.15: powerpc: Fix reschedule bug in KUAP-unlocked user copy
+-  linux-yocto/5.15: Upgrade to v5.15.91
+-  linux-yocto/5.19: fix perf build with clang
+-  linux-yocto/5.19: powerpc: Fix reschedule bug in KUAP-unlocked user copy
+-  lsof: fix old override syntax
+-  lttng-modules: Fix for 5.10.163 kernel version
+-  lttng-modules: fix for kernel 6.2+
+-  lttng-modules: Upgrade to 2.13.8
+-  lttng-tools: Upgrade to 2.13.9
+-  make-mod-scripts: Ensure kernel build output is deterministic
+-  manuals: update patchwork instance URL
+-  mesa-gl: gallium is required when enabling x11
+-  meta: remove True option to getVar and getVarFlag calls (again)
+-  migration-guides: add release-notes for 4.0.7
+-  native: Drop special variable handling
+-  numactl: skip test case when target platform doesn't have 2 CPU node
+-  oeqa context.py: fix --target-ip comment to include ssh port number
+-  oeqa dump.py: add error counter and stop after 5 failures
+-  oeqa qemurunner.py: add timeout to QMP calls
+-  oeqa qemurunner.py: try to avoid reading one character at a time
+-  oeqa qemurunner: read more data at a time from serial
+-  oeqa ssh.py: add connection keep alive options to ssh client
+-  oeqa ssh.py: fix hangs in run()
+-  oeqa ssh.py: move output prints to new line
+-  oeqa/qemurunner: do not use Popen.poll() when terminating runqemu with a signal
+-  oeqa/rpm.py: Increase timeout and add debug output
+-  oeqa/selftest/debuginfod: improve testcase
+-  oeqa/selftest/locales: Add selftest for locale generation/presence
+-  oeqa/selftest/resulttooltests: fix minor typo
+-  openssl: Upgrade to 3.0.8
+-  opkg: ensure opkg uses private gpg.conf when applying keys.
+-  pango: Upgrade to 1.50.12
+-  perf: Enable debug/source packaging
+-  pkgconf: Upgrade to 1.9.4
+-  poky.conf: Update SANITY_TESTED_DISTROS to match autobuilder
+-  poky.conf: bump version for 4.1.3
+-  populate_sdk_ext.bbclass: Fix missing leading whitespace with ':append'
+-  profile-manual: update WireShark hyperlinks
+-  ptest-packagelists.inc: Fix missing leading whitespace with ':append'
+-  python3-pytest: depend on python3-tomli instead of python3-toml
+-  quilt: fix intermittent failure in faildiff.test
+-  quilt: use upstreamed faildiff.test fix
+-  recipe_sanity: fix old override syntax
+-  ref-manual: Fix invalid feature name
+-  ref-manual: update DEV_PKG_DEPENDENCY in variables
+-  ref-manual: variables.rst: fix broken hyperlink
+-  rm_work.bbclass: use HOSTTOOLS 'rm' binary exclusively
+-  runqemu: kill qemu if it hangs
+-  rust: Do not use default compiler flags defined in CC crate
+-  scons.bbclass: Make MAXLINELENGTH overridable
+-  scons: Pass MAXLINELENGTH to scons invocation
+-  sdkext/cases/devtool: pass a logger to HTTPService
+-  selftest/virgl: use pkg-config from the host
+-  spirv-headers/spirv-tools: set correct branch name
+-  sstate.bbclass: Fetch non-existing local .sig files if needed
+-  sstatesig: Improve output hash calculation
+-  sudo: Upgrade to 1.9.12p2
+-  system-requirements.rst: Add Fedora 36, AlmaLinux 8.7 & 9.1, and OpenSUSE 15.4 to list of supported distros
+-  testimage: Fix error message to reflect new syntax
+-  tiff: Add packageconfig knob for webp
+-  toolchain-scripts: compatibility with unbound variable protection
+-  uninative: Upgrade to 3.8.1 to include libgcc
+-  update-alternatives: fix typos
+-  vim: Upgrade to 9.0.1293
+-  vulkan-samples: branch rename master -> main
+-  wic: Fix usage of fstype=none in wic
+-  wireless-regdb: Upgrade to 2023.02.13
+-  xserver-xorg: Upgrade to 21.1.7
+-  xwayland: Upgrade to 22.1.8
+
+
+Known Issues in Yocto-4.1.3
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  N/A
+
+
+Contributors to Yocto-4.1.3
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  Adrian Freihofer
+-  Alejandro Hernandez Samaniego
+-  Alex Kiernan
+-  Alexander Kanavin
+-  Alexis Lothoré
+-  Anton Antonov
+-  Antonin Godard
+-  Armin Kuster
+-  Arnout Vandecappelle
+-  Benoît Mauduit
+-  Bruce Ashfield
+-  Carlos Alberto Lopez Perez
+-  Changqing Li
+-  Charlie Johnston
+-  Chee Yang Lee
+-  Chen Qi
+-  Dmitry Baryshkov
+-  Enguerrand de Ribaucourt
+-  Etienne Cordonnier
+-  Fawzi KHABER
+-  Federico Pellegrin
+-  Frank de Brabander
+-  Harald Seiler
+-  He Zhe
+-  Jan Kircher
+-  Jermain Horsman
+-  Jose Quaresma
+-  Joshua Watt
+-  Kai Kang
+-  Khem Raj
+-  Lei Maohui
+-  Louis Rannou
+-  Luis
+-  Marek Vasut
+-  Markus Volk
+-  Marta Rybczynska
+-  Martin Jansa
+-  Mateusz Marciniec
+-  Mauro Queiros
+-  Michael Halstead
+-  Michael Opdenacker
+-  Mikko Rapeli
+-  Mingli Yu
+-  Narpat Mali
+-  Niko Mauno
+-  Pavel Zhukov
+-  Pawel Zalewski
+-  Peter Kjellerstedt
+-  Petr Kubizňák
+-  Quentin Schulz
+-  Randy MacLeod
+-  Richard Purdie
+-  Robert Joslyn
+-  Rodolfo Quesada Zumbado
+-  Ross Burton
+-  Sakib Sajal
+-  Sandeep Gundlupet Raju
+-  Saul Wold
+-  Siddharth Doshi
+-  Steve Sakoman
+-  Thomas Roos
+-  Tobias Hagelborn
+-  Ulrich Ölmann
+-  Vivek Kumbhar
+-  Wang Mingyu
+-  Xiangyu Chen
+
+
+Repositories / Downloads for Yocto-4.1.3
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+poky
+
+-  Repository Location: :yocto_git:`/poky`
+-  Branch: :yocto_git:`langdale </poky/log/?h=langdale>`
+-  Tag:  :yocto_git:`yocto-4.1.3 </poky/log/?h=yocto-4.1.3>`
+-  Git Revision: :yocto_git:`91d0157d6daf4ea61d6b4e090c0b682d3f3ca60f </poky/commit/?id=91d0157d6daf4ea61d6b4e090c0b682d3f3ca60f>`
+-  Release Artefact: poky-91d0157d6daf4ea61d6b4e090c0b682d3f3ca60f
+-  sha: 94e4615eba651fe705436b29b854458be050cc39db936295f9d5eb7e85d3eff1
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.1.3/poky-91d0157d6daf4ea61d6b4e090c0b682d3f3ca60f.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.1.3/poky-91d0157d6daf4ea61d6b4e090c0b682d3f3ca60f.tar.bz2
+
+openembedded-core
+
+-  Repository Location: :oe_git:`/openembedded-core`
+-  Branch: :oe_git:`langdale </openembedded-core/log/?h=langdale>`
+-  Tag:  :oe_git:`yocto-4.1.3 </openembedded-core/log/?h=yocto-4.1.3>`
+-  Git Revision: :oe_git:`b995ea45773211bd7bdd60eabcc9bbffda6beb5c </openembedded-core/commit/?id=b995ea45773211bd7bdd60eabcc9bbffda6beb5c>`
+-  Release Artefact: oecore-b995ea45773211bd7bdd60eabcc9bbffda6beb5c
+-  sha: 952e19361f205ee91b74e5caaa835d58fa6dd0d92ddaed50d4cd3f3fa56fab63
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.1.3/oecore-b995ea45773211bd7bdd60eabcc9bbffda6beb5c.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.1.3/oecore-b995ea45773211bd7bdd60eabcc9bbffda6beb5c.tar.bz2
+
+meta-mingw
+
+-  Repository Location: :yocto_git:`/meta-mingw`
+-  Branch: :yocto_git:`langdale </meta-mingw/log/?h=langdale>`
+-  Tag:  :yocto_git:`yocto-4.1.3 </meta-mingw/log/?h=yocto-4.1.3>`
+-  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.3/meta-mingw-b0067202db8573df3d23d199f82987cebe1bee2c.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.1.3/meta-mingw-b0067202db8573df3d23d199f82987cebe1bee2c.tar.bz2
+
+bitbake
+
+-  Repository Location: :oe_git:`/bitbake`
+-  Branch: :oe_git:`2.2 </bitbake/log/?h=2.2>`
+-  Tag:  :oe_git:`yocto-4.1.3 </bitbake/log/?h=yocto-4.1.3>`
+-  Git Revision: :oe_git:`592ee222a1c6da42925fb56801f226884b6724ec </bitbake/commit/?id=592ee222a1c6da42925fb56801f226884b6724ec>`
+-  Release Artefact: bitbake-592ee222a1c6da42925fb56801f226884b6724ec
+-  sha: 79c32f2ca66596132e32a45654ce0e9dd42b6b39186eff3540a9d6b499fe952c
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.1.3/bitbake-592ee222a1c6da42925fb56801f226884b6724ec.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.1.3/bitbake-592ee222a1c6da42925fb56801f226884b6724ec.tar.bz2
+
+yocto-docs
+
+-  Repository Location: :yocto_git:`/yocto-docs`
+-  Branch: :yocto_git:`langdale </yocto-docs/log/?h=langdale>`
+-  Tag: :yocto_git:`yocto-4.1.3 </yocto-docs/log/?h=yocto-4.1.3>`
+-  Git Revision: :yocto_git:`3de2ad1f8ff87aeec30088779267880306a0f31a </yocto-docs/commit/?id=3de2ad1f8ff87aeec30088779267880306a0f31a>`
+

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

@@ -0,0 +1,254 @@
+.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
+
+Release notes for Yocto-4.1.4 (Langdale)
+----------------------------------------
+
+Security Fixes in Yocto-4.1.4
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  cve-extra-exclusions/linux-yocto: Ignore :cve:`2020-27784`, :cve:`2021-3669`, :cve:`2021-3759`, :cve:`2021-4218`, :cve:`2022-0480`, :cve:`2022-1184`, :cve:`2022-1462`, :cve:`2022-2308`, :cve:`2022-2327`, :cve:`2022-26365`, :cve:`2022-2663`, :cve:`2022-2785`, :cve:`2022-3176`, :cve:`2022-33740`, :cve:`2022-33741`, :cve:`2022-33742`, :cve:`2022-3526`, :cve:`2022-3563`, :cve:`2022-3621`, :cve:`2022-3623`, :cve:`2022-3624`, :cve:`2022-3625`, :cve:`2022-3629`, :cve:`2022-3630`, :cve:`2022-3633`, :cve:`2022-3635`, :cve:`2022-3636`, :cve:`2022-3637`, :cve:`2022-3646` and :cve:`2022-3649`
+-  cve-extra-exclusions/linux-yocto 5.15: Ignore :cve:`2022-3435`, :cve:`2022-3534`, :cve:`2022-3564`, :cve:`2022-3564`, :cve:`2022-3619`, :cve:`2022-3640`, :cve:`2022-42895`, :cve:`2022-42896`, :cve:`2022-4382`, :cve:`2023-0266` and :cve:`2023-0394`
+-  epiphany: Fix :cve:`2023-26081`
+-  git: Ignore :cve:`2023-22743`
+-  go: Fix :cve:`2022-41722`, :cve:`2022-41723`, :cve:`2022-41724`, :cve:`2022-41725` and :cve:`2023-24532`
+-  harfbuzz: Fix :cve:`2023-25193`
+-  libmicrohttpd: Fix :cve:`2023-27371`
+-  libxml2: Fix :cve:`2022-40303` and :cve:`2022-40304`
+-  openssl: Fix :cve:`2023-0464`, :cve:`2023-0465` and :cve:`2023-0466`
+-  python3-setuptools: Fix :cve:`2022-40897`
+-  qemu: Fix :cve:`2022-4144`
+-  screen: Fix :cve:`2023-24626`
+-  shadow: Ignore :cve:`2016-15024`
+-  tiff: Fix :cve:`2022-48281`, :cve:`2023-0795`, :cve:`2023-0796`, :cve:`2023-0797`, :cve:`2023-0798`, :cve:`2023-0799`, :cve:`2023-0800`, :cve:`2023-0801`, :cve:`2023-0802`, :cve:`2023-0803` and :cve:`2023-0804`
+-  vim: Fix :cve:`2023-1127`, :cve:`2023-1170`, :cve:`2023-1175`, :cve:`2023-1264` and :cve:`2023-1355`
+-  xdg-utils: Fix :cve:`2022-4055`
+-  xserver-xorg: Fix for :cve:`2023-1393`
+
+
+Fixes in Yocto-4.1.4
+~~~~~~~~~~~~~~~~~~~~
+
+-  apt: re-enable version check
+-  base-files: Drop localhost.localdomain from hosts file
+-  binutils: Fix nativesdk ld.so search
+-  bitbake: bin/utils: Ensure locale en_US.UTF-8 is available on the system
+-  bitbake: cookerdata: Drop dubious exception handling code
+-  bitbake: cookerdata: Improve early exception handling
+-  bitbake: cookerdata: Remove incorrect SystemExit usage
+-  bitbake: fetch/git: Fix local clone url to make it work with repo
+-  bitbake: toaster: Add refreshed oe-core and poky fixtures
+-  bitbake: toaster: fixtures/README: django 1.8 -> 3.2
+-  bitbake: toaster: fixtures/gen_fixtures.py: update branches
+-  bitbake: utils: Allow to_boolean to support int values
+-  bmap-tools: switch to main branch
+-  build-appliance-image: Update to langdale head revision
+-  buildtools-tarball: Handle spaces within user $PATH
+-  busybox: move hwclock init earlier in startup
+-  cargo.bbclass: use offline mode for building
+-  cpio: Fix wrong CRC with ASCII CRC for large files
+-  cracklib: update github branch to 'main'
+-  cups: add/fix web interface packaging
+-  cups: check :term:`PACKAGECONFIG` for pam feature
+-  cups: use BUILDROOT instead of DESTDIR
+-  cve-check: Fix false negative version issue
+-  devtool/upgrade: do not delete the workspace/recipes directory
+-  dhcpcd: Fix install conflict when enable multilib.
+-  ffmpeg: fix build failure when vulkan is enabled
+-  filemap.py: enforce maximum of 4kb block size
+-  gcc-shared-source: do not use ${S}/.. in deploy_source_date_epoch
+-  glibc: Add missing binutils dependency
+-  go: upgrade to 1.19.7
+-  image_types: fix multiubi var init
+-  image_types: fix vname var init in multiubi_mkfs() function
+-  iso-codes: upgrade to 4.13.0
+-  kernel-devsrc: fix mismatched compiler warning
+-  lib/oe/gpg_sign.py: Avoid race when creating .sig files in detach_sign
+-  lib/resulttool: fix typo breaking resulttool log --ptest
+-  libcomps: Fix callback function prototype for PyCOMPS_hash
+-  libdnf: upgrade to 0.70.0
+-  libgit2: update license information
+-  libmicrohttpd: upgrade to 0.9.76
+-  linux-yocto-rt/5.15: upgrade to -rt59
+-  linux-yocto/5.15: upgrade to v5.15.108
+-  linux: inherit pkgconfig in kernel.bbclass
+-  lttng-modules: upgrade to v2.13.9
+-  lua: Fix install conflict when enable multilib.
+-  mdadm: Fix raid0, 06wrmostly and 02lineargrow tests
+-  mesa-demos: packageconfig weston should have a dependency on wayland-protocols
+-  meson: Fix wrapper handling of implicit setup command
+-  meson: remove obsolete RPATH stripping patch
+-  migration-guides: update release notes
+-  oeqa ping.py: avoid busylooping failing ping command
+-  oeqa ping.py: fail test if target IP address has not been set
+-  oeqa rtc.py: skip if read-only-rootfs
+-  oeqa/runtime: clean up deprecated backslash expansion
+-  oeqa/sdk: Improve Meson test
+-  oeqa/selftest/cases/package.py: adding unittest for package rename conflicts
+-  oeqa/selftest/cases/runqemu: update imports
+-  oeqa/selftest/prservice: Improve debug output for failure
+-  oeqa/selftest/reproducible: Split different packages from missing packages output
+-  oeqa/selftest: OESelftestTestContext: convert relative to full path when newbuilddir is provided
+-  oeqa/targetcontrol: do not set dump_host_cmds redundantly
+-  oeqa/targetcontrol: fix misspelled RuntimeError
+-  oeqa/targetcontrol: remove unused imports
+-  oeqa/utils/commands: fix usage of undefined EPIPE
+-  oeqa/utils/commands: remove unused imports
+-  oeqa/utils/qemurunner: replace hard-coded user 'root' in debug output
+-  oeqs/selftest: OESelftestTestContext: replace the os.environ after subprocess.check_output
+-  package.bbclass: check packages name conflict in do_package
+-  pango: upgrade to 1.50.13
+-  piglit: Fix build time dependency
+-  poky.conf: bump version for 4.1.4
+-  populate_sdk_base: add zip options
+-  populate_sdk_ext: Handle spaces within user $PATH
+-  pybootchart: Fix extents handling to account for cpu/io/mem pressure changes
+-  pybootchartui: Fix python syntax issue
+-  report-error: catch Nothing :term:`PROVIDES` error
+-  rpm: Fix hdr_hash function prototype
+-  run-postinsts: Set dependency for ldconfig to avoid boot issues
+-  runqemu: respect :term:`IMAGE_LINK_NAME`
+-  runqemu: Revert "workaround for APIC hang on pre 4.15 kernels on qemux86q"
+-  scripts/lib/buildstats: handle top-level build_stats not being complete
+-  selftest/recipetool: Stop test corrupting tinfoil class
+-  selftest/runtime_test/virgl: Disable for all Rocky Linux
+-  selftest: devtool: set :term:`BB_HASHSERVE_UPSTREAM` when setting :term:`SSTATE_MIRRORS`
+-  selftest: runqemu: better check for ROOTFS: in the log
+-  selftest: runqemu: use better error message when asserts fail
+-  shadow: Fix can not print full login timeout message
+-  staging/multilib: Fix manifest corruption
+-  staging: Separate out different multiconfig manifests
+-  sudo: upgrade to 1.9.13p3
+-  systemd.bbclass: Add /usr/lib/systemd to searchpaths as well
+-  systemd: add group sgx to udev package
+-  systemd: fix wrong nobody-group assignment
+-  timezone: use 'tz' subdir instead of ${WORKDIR} directly
+-  toolchain-scripts: Handle spaces within user $PATH
+-  tzcode-native: fix build with gcc-13 on host
+-  tzdata: upgrade to 2023c
+-  tzdata: use separate :term:`B` instead of :term:`WORKDIR` for zic output
+-  u-boot: Map arm64 into map for u-boot dts installation
+-  uninative: Upgrade to 3.9 to include glibc 2.37
+-  vala: Fix install conflict when enable multilib.
+-  vim: add missing pkgconfig inherit
+-  vim: set modified-by to the recipe :term:`MAINTAINER`
+-  vim: upgrade to 9.0.1429
+-  xcb-proto: Fix install conflict when enable multilib.
+
+
+Known Issues in Yocto-4.1.4
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+- N/A
+
+
+Contributors to Yocto-4.1.4
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  Alexander Kanavin
+-  Andrew Geissler
+-  Arturo Buzarra
+-  Bhabu Bindu
+-  Bruce Ashfield
+-  Carlos Alberto Lopez Perez
+-  Chee Yang Lee
+-  Chris Elledge
+-  Christoph Lauer
+-  Dmitry Baryshkov
+-  Enrico Jörns
+-  Fawzi KHABER
+-  Frank de Brabander
+-  Frederic Martinsons
+-  Geoffrey GIRY
+-  Hitendra Prajapati
+-  Jose Quaresma
+-  Kenfe-Mickael Laventure
+-  Khem Raj
+-  Marek Vasut
+-  Martin Jansa
+-  Michael Halstead
+-  Michael Opdenacker
+-  Mikko Rapeli
+-  Ming Liu
+-  Mingli Yu
+-  Narpat Mali
+-  Pavel Zhukov
+-  Peter Marko
+-  Piotr Łobacz
+-  Randy MacLeod
+-  Richard Purdie
+-  Robert Yang
+-  Romuald JEANNE
+-  Romuald Jeanne
+-  Ross Burton
+-  Siddharth
+-  Siddharth Doshi
+-  Soumya
+-  Steve Sakoman
+-  Sudip Mukherjee
+-  Tim Orling
+-  Tobias Hagelborn
+-  Tom Hochstein
+-  Trevor Woerner
+-  Wang Mingyu
+-  Xiangyu Chen
+-  Zoltan Boszormenyi
+
+
+Repositories / Downloads for Yocto-4.1.4
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+poky
+
+-  Repository Location: :yocto_git:`/poky`
+-  Branch: :yocto_git:`langdale </poky/log/?h=langdale>`
+-  Tag:  :yocto_git:`yocto-4.1.4 </poky/log/?h=yocto-4.1.4>`
+-  Git Revision: :yocto_git:`3e95f268ce04b49ba6731fd4bbc53b1693c21963 </poky/commit/?id=3e95f268ce04b49ba6731fd4bbc53b1693c21963>`
+-  Release Artefact: poky-3e95f268ce04b49ba6731fd4bbc53b1693c21963
+-  sha: 54798c4b519f5e11f409e1fd074bea1bc0a1b80672aa60dddbac772c8e4d838b
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.1.4/poky-3e95f268ce04b49ba6731fd4bbc53b1693c21963.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.1.4/poky-3e95f268ce04b49ba6731fd4bbc53b1693c21963.tar.bz2
+
+openembedded-core
+
+-  Repository Location: :oe_git:`/openembedded-core`
+-  Branch: :oe_git:`langdale </openembedded-core/log/?h=langdale>`
+-  Tag:  :oe_git:`yocto-4.1.4 </openembedded-core/log/?h=yocto-4.1.4>`
+-  Git Revision: :oe_git:`78211cda40eb018a3aa535c75b61e87337236628 </openembedded-core/commit/?id=78211cda40eb018a3aa535c75b61e87337236628>`
+-  Release Artefact: oecore-78211cda40eb018a3aa535c75b61e87337236628
+-  sha: 1303d836bae54c438c64d6b9f068eb91c32be4cc1779e89d0f2d915a55d59b15
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.1.4/oecore-78211cda40eb018a3aa535c75b61e87337236628.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.1.4/oecore-78211cda40eb018a3aa535c75b61e87337236628.tar.bz2
+
+meta-mingw
+
+-  Repository Location: :yocto_git:`/meta-mingw`
+-  Branch: :yocto_git:`langdale </meta-mingw/log/?h=langdale>`
+-  Tag:  :yocto_git:`yocto-4.1.4 </meta-mingw/log/?h=yocto-4.1.4>`
+-  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.4/meta-mingw-b0067202db8573df3d23d199f82987cebe1bee2c.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.1.4/meta-mingw-b0067202db8573df3d23d199f82987cebe1bee2c.tar.bz2
+
+bitbake
+
+-  Repository Location: :oe_git:`/bitbake`
+-  Branch: :oe_git:`2.2 </bitbake/log/?h=2.2>`
+-  Tag:  :oe_git:`yocto-4.1.4 </bitbake/log/?h=yocto-4.1.4>`
+-  Git Revision: :oe_git:`5b105e76dd7de3b9a25b17b397f2c12c80048894 </bitbake/commit/?id=5b105e76dd7de3b9a25b17b397f2c12c80048894>`
+-  Release Artefact: bitbake-5b105e76dd7de3b9a25b17b397f2c12c80048894
+-  sha: 2cd6448138816f5a906f9927c6b6fdc5cf24981ef32b6402312f52ca490edb4f
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.1.4/bitbake-5b105e76dd7de3b9a25b17b397f2c12c80048894.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.1.4/bitbake-5b105e76dd7de3b9a25b17b397f2c12c80048894.tar.bz2
+
+yocto-docs
+
+-  Repository Location: :yocto_git:`/yocto-docs`
+-  Branch: :yocto_git:`langdale </yocto-docs/log/?h=langdale>`
+-  Tag: :yocto_git:`yocto-4.1.4 </yocto-docs/log/?h=yocto-4.1.4>`
+-  Git Revision: :yocto_git:`da685fc5e69d49728e3ffd6c4d623e7e1745059d </yocto-docs/commit/?id=da685fc5e69d49728e3ffd6c4d623e7e1745059d>`
+

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

@@ -238,20 +238,20 @@ Security Fixes in 4.1
 - 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)`
+- 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)`
+- 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`
+- 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`
+- 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`

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

@@ -0,0 +1,206 @@
+.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
+
+Release notes for Yocto-4.2.1 (Mickledore)
+------------------------------------------
+
+Security Fixes in Yocto-4.2.1
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  connman: Fix :cve:`2023-28488`
+-  linux-yocto: Ignore :cve:`2023-1652` and :cve:`2023-1829`
+-  ghostscript: Fix :cve:`2023-28879`
+-  qemu: Ignore :cve:`2023-0664`
+-  ruby: Fix :cve:`2022-28738` and :cve:`2022-28739`
+-  tiff: Fix :cve:`2022-4645`
+-  xwayland: Fix :cve:`2023-1393`
+
+
+Fixes in Yocto-4.2.1
+~~~~~~~~~~~~~~~~~~~~
+
+-  apr: upgrade to 1.7.3
+-  bind: upgrade to 9.18.13
+-  build-appliance-image: Update to mickledore head revision
+-  cargo: Fix build on musl/riscv
+-  cpio: fix appending to archives larger than 2GB
+-  cracklib: upgrade to 2.9.11
+-  cve-update-nvd2-native: added the missing http import
+-  dev-manual: init-manager.rst: add summary
+-  dhcpcd: use git instead of tarballs
+-  docs: add support for mickledore (4.2) release
+-  gawk: Add skipped.txt to emit test to ignore
+-  gawk: Disable known ptest fails on musl
+-  gawk: Remove redundant patch
+-  glib-networking: Add test retry to avoid failures
+-  glib-networking: Correct glib error handling in test patch
+-  gtk4: upgrade to 4.10.3
+-  kernel-devsrc: depend on python3-core instead of python3
+-  kernel-fitimage: Fix the default dtb config check
+-  kernel: improve initramfs bundle processing time
+-  libarchive: Enable acls, xattr for native as well as target
+-  libhandy: upgrade to 1.8.2
+-  libnotify: remove dependency dbus
+-  libpam: Fix the xtests/tst-pam_motd[1|3] failures
+-  libpcap: upgrade to 1.10.4
+-  libsdl2: upgrade to 2.26.5
+-  libxml2: Disable icu tests on musl
+-  license.bbclass: Include :term:`LICENSE` in the output when it fails to parse
+-  linux-firmware: upgrade to 20230404
+-  machine/qemuarm*: don't explicitly set vmalloc
+-  maintainers.inc: Fix email address typo
+-  maintainers.inc: Move repo to unassigned
+-  man-pages: upgrade to 6.04
+-  manuals: document :term:`SPDX_CUSTOM_ANNOTATION_VARS`
+-  manuals: expand init manager documentation
+-  mesa: upgrade to 23.0.3
+-  migration-guides: add release-notes for 4.1.4
+-  migration-guides: fixes and improvements to 4.2 release notes
+-  migration-guides: release-notes-4.0.9.rst: add missing :term:`SPDX` info
+-  migration-guides: release-notes-4.2: add doc improvement highlights
+-  mpg123: upgrade to 1.31.3
+-  mtools: upgrade to 4.0.43
+-  oeqa/utils/metadata.py: Fix running oe-selftest running with no distro set
+-  overview-manual: development-environment: update text and screenshots
+-  overview-manual: update section about source archives
+-  package_manager/ipk: fix config path generation in _create_custom_config()
+-  pango: upgrade to 1.50.14
+-  perl: patch out build paths from native binaries
+-  poky.conf: bump version for 4.2.1 release
+-  populate_sdk_ext.bbclass: redirect stderr to stdout so that both end in LOGFILE
+-  populate_sdk_ext.bbclass: set :term:`METADATA_REVISION` with an :term:`DISTRO` override
+-  python3targetconfig.bbclass: Extend PYTHONPATH instead of overwriting
+-  qemu: Add fix for powerpc instruction fallback issue
+-  qemu: Update ppc instruction fix to match revised upstream version
+-  quilt: Fix merge.test race condition
+-  recipes: Default to https git protocol where possible
+-  ref-manual: add "Mixin" term
+-  ref-manual: classes.rst: document devicetree.bbclass
+-  ref-manual: classes: kernel: document automatic defconfig usage
+-  ref-manual: classes: kernel: remove incorrect sentence opening
+-  ref-manual: remove unused and obsolete file
+-  ref-manual: system-requirements.rst: fix AlmaLinux variable name
+-  ref-manual: variables.rst: add wikipedia shortcut for "getty"
+-  ref-manual: variables.rst: document :term:`KERNEL_DANGLING_FEATURES_WARN_ONLY`
+-  ref-manual: variables.rst: don't mention the :term:`INIT_MANAGER` "none" option
+-  release-notes-4.2: remove/merge duplicates entries
+-  release-notes-4.2: update RC3 changes
+-  release-notes-4.2: update known issues and Repositories/Downloads
+-  releases.svg: fix and explain duration of Hardknott 3.3
+-  ruby: upgrade to 3.2.2
+-  rust: upgrade to 1.68.2
+-  selftest/distrodata: clean up exception lists in recipe maintainers test
+-  systemd-systemctl: fix instance template WantedBy symlink construction
+-  texinfo: upgrade to 7.0.3
+-  unfs3: fix symlink time setting issue
+-  update-alternatives.bbclass: fix old override syntax
+-  vala: upgrade to 0.56.6
+-  waffle: upgrade to 1.7.2
+-  weston: add xwayland to :term:`DEPENDS` for :term:`PACKAGECONFIG` xwayland
+-  wpebackend-fdo: upgrade to 1.14.2
+-  xserver-xorg: upgrade to 21.1.8
+-  xwayland: upgrade to 23.1.1
+
+
+Known Issues in Yocto-4.2.1
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+- N/A
+
+
+Contributors to Yocto-4.2.1
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  Alex Kiernan
+-  Alexander Kanavin
+-  Arslan Ahmad
+-  Bruce Ashfield
+-  Chen Qi
+-  Dmitry Baryshkov
+-  Enrico Jörns
+-  Jan Vermaete
+-  Joe Slater
+-  Johannes Schrimpf
+-  Kai Kang
+-  Khem Raj
+-  Kyle Russell
+-  Lee Chee Yang
+-  Luca Ceresoli
+-  Markus Volk
+-  Martin Jansa
+-  Martin Siegumfeldt
+-  Michael Halstead
+-  Michael Opdenacker
+-  Ming Liu
+-  Otavio Salvador
+-  Pawan Badganchi
+-  Peter Bergin
+-  Peter Kjellerstedt
+-  Piotr Łobacz
+-  Richard Purdie
+-  Ross Burton
+-  Steve Sakoman
+-  Thomas Roos
+-  Virendra Thakur
+-  Wang Mingyu
+-  Yoann Congal
+-  Zhixiong Chi
+
+
+Repositories / Downloads for Yocto-4.2.1
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+poky
+
+-  Repository Location: :yocto_git:`/poky`
+-  Branch: :yocto_git:`mickledore </poky/log/?h=mickledore>`
+-  Tag:  :yocto_git:`yocto-4.2.1 </poky/log/?h=yocto-4.2.1>`
+-  Git Revision: :yocto_git:`c5c69f78fc7ce4ba361363c14352e4264ce7813f </poky/commit/?id=c5c69f78fc7ce4ba361363c14352e4264ce7813f>`
+-  Release Artefact: poky-c5c69f78fc7ce4ba361363c14352e4264ce7813f
+-  sha: 057d7771dceebb949a79359d7d028a733a29ae7ecd98b60fefcff83fecb22eb7
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.2.1/poky-c5c69f78fc7ce4ba361363c14352e4264ce7813f.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.2.1/poky-c5c69f78fc7ce4ba361363c14352e4264ce7813f.tar.bz2
+
+openembedded-core
+
+-  Repository Location: :oe_git:`/openembedded-core`
+-  Branch: :oe_git:`mickledore </openembedded-core/log/?h=mickledore>`
+-  Tag:  :oe_git:`yocto-4.2.1 </openembedded-core/log/?h=yocto-4.2.1>`
+-  Git Revision: :oe_git:`20cd64812d286c920bd766145ab1cd968e72667e </openembedded-core/commit/?id=20cd64812d286c920bd766145ab1cd968e72667e>`
+-  Release Artefact: oecore-20cd64812d286c920bd766145ab1cd968e72667e
+-  sha: 877fb909af7aa51e1c962d33cfe91ba3e075c384716006aa1345b4bcb15a48ef
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.2.1/oecore-20cd64812d286c920bd766145ab1cd968e72667e.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.2.1/oecore-20cd64812d286c920bd766145ab1cd968e72667e.tar.bz2
+
+meta-mingw
+
+-  Repository Location: :yocto_git:`/meta-mingw`
+-  Branch: :yocto_git:`mickledore </meta-mingw/log/?h=mickledore>`
+-  Tag:  :yocto_git:`yocto-4.2.1 </meta-mingw/log/?h=yocto-4.2.1>`
+-  Git Revision: :yocto_git:`cc9fd0a988dc1041035a6a6cafb2d1237ef38d8e </meta-mingw/commit/?id=cc9fd0a988dc1041035a6a6cafb2d1237ef38d8e>`
+-  Release Artefact: meta-mingw-cc9fd0a988dc1041035a6a6cafb2d1237ef38d8e
+-  sha: 69ccc3ee503b5c35602889e85d28df64a5422ad0f1e55c96c94135b837bb4a1c
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.2.1/meta-mingw-cc9fd0a988dc1041035a6a6cafb2d1237ef38d8e.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.2.1/meta-mingw-cc9fd0a988dc1041035a6a6cafb2d1237ef38d8e.tar.bz2
+
+bitbake
+
+-  Repository Location: :oe_git:`/bitbake`
+-  Branch: :oe_git:`2.4 </bitbake/log/?h=2.4>`
+-  Tag:  :oe_git:`yocto-4.2.1 </bitbake/log/?h=yocto-4.2.1>`
+-  Git Revision: :oe_git:`d97d62e2cbe4bae17f0886f3b4759e8f9ba6d38c </bitbake/commit/?id=d97d62e2cbe4bae17f0886f3b4759e8f9ba6d38c>`
+-  Release Artefact: bitbake-d97d62e2cbe4bae17f0886f3b4759e8f9ba6d38c
+-  sha: 5edcb97cb545011226b778355bb840ebcc790552d4a885a0d83178153697ba7a
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.2.1/bitbake-d97d62e2cbe4bae17f0886f3b4759e8f9ba6d38c.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.2.1/bitbake-d97d62e2cbe4bae17f0886f3b4759e8f9ba6d38c.tar.bz2
+
+yocto-docs
+
+-  Repository Location: :yocto_git:`/yocto-docs`
+-  Branch: :yocto_git:`mickledore </yocto-docs/log/?h=mickledore>`
+-  Tag: :yocto_git:`yocto-4.2.1 </yocto-docs/log/?h=yocto-4.2.1>`
+-  Git Revision: :yocto_git:`6b04269bba72311e83139cc88b7a3539a5d832e8 </yocto-docs/commit/?id=6b04269bba72311e83139cc88b7a3539a5d832e8>`
+

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

@@ -0,0 +1,330 @@
+.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
+
+Release notes for Yocto-4.2.2 (Mickledore)
+------------------------------------------
+
+Security Fixes in Yocto-4.2.2
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  binutils: Fix :cve:`2023-1972`
+-  cups: Fix :cve:`2023-32324`
+-  curl: Fix :cve:`2023-28319`, :cve:`2023-28320`, :cve:`2023-28321` and :cve:`2023-28322`
+-  dbus: Fix :cve:`2023-34969`
+-  git: Fix :cve:`2023-25652` and :cve:`2023-29007`
+-  git: Ignore :cve:`2023-25815`
+-  libwebp: Fix :cve:`2023-1999`
+-  libxml2: Fix :cve:`2023-28484` and :cve:`2023-29469`
+-  libxpm: Fix :cve:`2022-44617`
+-  ninja: Ignore :cve:`2021-4336`
+-  openssl: Fix :cve:`2023-0464`, :cve:`2023-0465`, :cve:`2023-0466`, :cve:`2023-1255` and :cve:`2023-2650`
+-  perl: Fix :cve:`2023-31484` and :cve:`2023-31486`
+-  sysstat: Fix :cve:`2023-33204`
+-  tiff: Fix :cve_mitre:`2023-25434`, :cve:`2023-26965` and :cve:`2023-2731`
+-  vim: Fix :cve:`2023-2426`
+
+
+Fixes in Yocto-4.2.2
+~~~~~~~~~~~~~~~~~~~~
+
+-  apr: Upgrade to 1.7.4
+-  avahi: fix D-Bus introspection
+-  babeltrace2: Always use BFD linker when building tests with ld-is-lld distro feature
+-  babeltrace2: Upgrade to 2.0.5
+-  baremetal-helloworld: Update :term:`SRCREV` to fix entry addresses for ARM architectures
+-  bind: Upgrade to 9.18.15
+-  binutils: move packaging of gprofng static lib into common .inc
+-  binutils: package static libs from gprofng
+-  binutils: stable 2.40 branch updates (7343182dd1)
+-  bitbake.conf: add unzstd in :term:`HOSTTOOLS`
+-  bitbake: runqueue: Fix deferred task/multiconfig race issue
+-  bno_plot.py, btt_plot.py: Ask for python3 specifically
+-  build-appliance-image: Update to mickledore head revision
+-  busybox: Upgrade to 1.36.1
+-  cmake.bbclass: do not search host paths for find_program()
+-  conf: add nice level to the hash config ignred variables
+-  connman: fix warning by specifying runstatedir at configure time
+-  cpio: Run ptests under ptest user
+-  dbus: Upgrade to 1.14.8
+-  devtool: Fix the wrong variable in srcuri_entry
+-  dnf: only write the log lock to root for native dnf
+-  docs: bsp-guide: bsp: fix typo
+-  dpkg: Upgrade to v1.21.22
+-  e2fsprogs: Fix error SRCDIR when using usrmerge :term:`DISTRO_FEATURES`
+-  e2fsprogs: fix ptest bug for second running
+-  ell: Upgrade to 0.57
+-  expect: Add ptest support
+-  fribidi: Upgrade to 1.0.13
+-  gawk: Upgrade to 5.2.2
+-  gcc : upgrade to v12.3
+-  gdb: fix crashes when debugging threads with Arm Pointer Authentication enabled
+-  gdb: Upgrade to 13.2
+-  git: Upgrade to 2.39.3
+-  glib-networking: use correct error code in ptest
+-  glibc: Pass linker choice via compiler flags
+-  glibc: stable 2.37 branch updates.
+-  gnupg: Upgrade to 2.4.2
+-  go.bbclass: don't use test to check output from ls
+-  go: Upgrade to 1.20.5
+-  go: Use -no-pie to build target cgo
+-  gobject-introspection: remove obsolete :term:`DEPENDS`
+-  grub: submit determinism.patch upstream
+-  gstreamer1.0: Upgrade to 1.22.3
+-  gtk4: Upgrade to 4.10.4
+-  image-live.bbclass: respect :term:`IMAGE_MACHINE_SUFFIX`
+-  image_types: Fix reproducible builds for initramfs and UKI img
+-  inetutils: remove unused patch files
+-  ipk: Revert Decode byte data to string in manifest handling
+-  iso-codes: Upgrade to 4.15.0
+-  kernel: don't force PAHOLE=false
+-  kmod: remove unused ptest.patch
+-  kmscube: Correct :term:`DEPENDS` to avoid overwrite
+-  layer.conf: Add missing dependency exclusion
+-  lib/terminal.py: Add urxvt terminal
+-  libbsd: Add correct license for all packages
+-  libdnf: Upgrade to 0.70.1
+-  libgcrypt: Upgrade to 1.10.2
+-  libgloss: remove unused patch file
+-  libmicrohttpd: Upgrade to 0.9.77
+-  libmodule-build-perl: Upgrade to 0.4234
+-  libx11: remove unused patch and :term:`FILESEXTRAPATHS`
+-  libx11: Upgrade to 1.8.5
+-  libxfixes: Upgrade to v6.0.1
+-  libxft: Upgrade to 2.3.8
+-  libxi: Upgrade to v1.8.1
+-  libxml2: Do not use lld linker when building with tests on rv64
+-  libxml2: Upgrade to 2.10.4
+-  libxpm: Upgrade to 3.5.16
+-  linux-firmware: Upgrade to 20230515
+-  linux-yocto/5.15: cfg: fix DECNET configuration warning
+-  linux-yocto/5.15: Upgrade to v5.15.118
+-  linux-yocto/6.1: fix intermittent x86 boot hangs
+-  linux-yocto/6.1: Upgrade to v6.1.35
+-  linux-yocto: move build / debug dependencies to .inc
+-  logrotate: Do not create logrotate.status file
+-  maintainers.inc: correct Carlos Rafael Giani's email address
+-  maintainers.inc: correct unassigned entries
+-  maintainers.inc: unassign Adrian Bunk from wireless-regdb
+-  maintainers.inc: unassign Alistair Francis from opensbi
+-  maintainers.inc: unassign Andreas Müller from itstool entry
+-  maintainers.inc: unassign Chase Qi from libc-test
+-  maintainers.inc: unassign Oleksandr Kravchuk from python3 and all other items
+-  maintainers.inc: unassign Pascal Bach from cmake entry
+-  maintainers.inc: unassign Ricardo Neri from ovmf
+-  maintainers.inc: update version for gcc-source
+-  maintainers.inc: unassign Richard Weinberger from erofs-utils entry
+-  meta: depend on autoconf-archive-native, not autoconf-archive
+-  meta: lib: oe: npm_registry: Add more safe caracters
+-  migration-guides: add release notes for 4.2.1
+-  minicom: remove unused patch files
+-  mobile-broadband-provider-info: Upgrade to 20230416
+-  musl: Correct :term:`SRC_URI`
+-  oeqa/selftest/bbtests: add non-existent prefile/postfile tests
+-  oeqa/selftest/cases/devtool.py: skip all tests require folder a git repo
+-  oeqa: adding selftest-hello and use it to speed up tests
+-  openssh: Remove BSD-4-clause contents completely from codebase
+-  openssl: fix building on riscv32
+-  openssl: Upgrade to 3.1.1
+-  overview-manual: concepts.rst: Fix a typo
+-  parted: Add missing libuuid to linker cmdline for libparted-fs-resize.so
+-  perf: Make built-in libtraceevent plugins cohabit with external libtraceevent
+-  piglit: Add missing glslang dependencies
+-  piglit: Fix c++11-narrowing warnings in tests
+-  pkgconf: Upgrade to 1.9.5
+-  pm-utils: fix multilib conflictions
+-  poky.conf: bump version for 4.2.2 release
+-  populate_sdk_base.bbclass: respect :term:`MLPREFIX` for ptest-pkgs's ptest-runner
+-  profile-manual: fix blktrace remote usage instructions
+-  psmisc: Set :term:`ALTERNATIVE` for pstree to resolve conflict with busybox
+-  ptest-runner: Ensure data writes don't race
+-  ptest-runner: Pull in "runner: Remove threads and mutexes" fix
+-  ptest-runner: Pull in sync fix to improve log warnings
+-  python3-bcrypt: Use BFD linker when building tests
+-  python3-numpy: remove NPY_INLINE, use inline instead
+-  qemu: a pending patch was submitted and accepted upstream
+-  qemu: remove unused qemu-7.0.0-glibc-2.36.patch
+-  qemurunner.py: fix error message about qmp
+-  qemurunner: avoid leaking server_socket
+-  ref-manual: add clarification for :term:`SRCREV`
+-  ref-manual: classes.rst: fix typo
+-  rootfs-postcommands.bbclass: add post func remove_unused_dnf_log_lock
+-  rpcsvc-proto: Upgrade to 1.4.4
+-  rpm: drop unused 0001-Rip-out-partial-support-for-unused-MD2-and-RIPEMD160.patch
+-  rpm: Upgrade to 4.18.1
+-  rpm: write macros under libdir
+-  runqemu-gen-tapdevs: Refactoring
+-  runqemu-ifupdown/get-tapdevs: Add support for ip tuntap
+-  scripts/runqemu: allocate unfsd ports in a way that doesn't race or clash with unrelated processes
+-  scripts/runqemu: split lock dir creation into a reusable function
+-  scripts: fix buildstats diff/summary hard bound to host python3
+-  sdk.py: error out when moving file fails
+-  sdk.py: fix moving dnf contents
+-  selftest/license: Exclude from world
+-  selftest/reproducible: Allow native/cross reuse in test
+-  serf: Upgrade to 1.3.10
+-  staging.bbclass: do not add extend_recipe_sysroot to prefuncs of prepare_recipe_sysroot
+-  strace: Disable failing test
+-  strace: Merge two similar patches
+-  strace: Update patches/tests with upstream fixes
+-  sysfsutils: fetch a supported fork from github
+-  systemd-systemctl: support instance expansion in WantedBy
+-  systemd: Drop a backport
+-  tiff: Remove unused patch from tiff
+-  uninative: Upgrade to 3.10 to support gcc 13
+-  uninative: Upgrade to 4.0 to include latest gcc 13.1.1
+-  unzip: fix configure check for cross compilation
+-  unzip: remove hardcoded LARGE_FILE_SUPPORT
+-  useradd-example: package typo correction
+-  useradd-staticids.bbclass: improve error message
+-  v86d: Improve kernel dependency
+-  vim: Upgrade to 9.0.1527
+-  weston-init: add profile to point users to global socket
+-  weston-init: add the weston user to the wayland group
+-  weston-init: add weston user to the render group
+-  weston-init: fix the mixed indentation
+-  weston-init: guard against systemd configs
+-  weston-init: make sure the render group exists
+-  wget: Upgrade to 1.21.4
+-  wireless-regdb: Upgrade to 2023.05.03
+-  xdpyinfo: Upgrade to 1.3.4
+-  xf86-video-intel: Use the HTTPS protocol to fetch the Git repositories
+-  xinput: upgrade to v1.6.4
+-  xwininfo: upgrade to v1.1.6
+-  xz: Upgrade to 5.4.3
+-  yocto-bsps: update to v5.15.106
+-  zip: fix configure check by using _Static_assert
+-  zip: remove unnecessary LARGE_FILE_SUPPORT CLFAGS
+
+
+Known Issues in Yocto-4.2.2
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+- N/A
+
+
+Contributors to Yocto-4.2.2
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  Alberto Planas
+-  Alejandro Hernandez Samaniego
+-  Alexander Kanavin
+-  Andrej Valek
+-  Andrew Jeffery
+-  Anuj Mittal
+-  Archana Polampalli
+-  BELOUARGA Mohamed
+-  Bruce Ashfield
+-  Changqing Li
+-  Charlie Wu
+-  Chen Qi
+-  Chi Xu
+-  Daniel Ammann
+-  Deepthi Hemraj
+-  Denys Dmytriyenko
+-  Dmitry Baryshkov
+-  Ed Beroset
+-  Eero Aaltonen
+-  Fabien Mahot
+-  Frieder Paape
+-  Frieder Schrempf
+-  Hannu Lounento
+-  Ian Ray
+-  Jermain Horsman
+-  Jörg Sommer
+-  Kai Kang
+-  Khem Raj
+-  Lee Chee Yang
+-  Lorenzo Arena
+-  Marc Ferland
+-  Markus Volk
+-  Martin Jansa
+-  Michael Halstead
+-  Mikko Rapeli
+-  Mingli Yu
+-  Natasha Bailey
+-  Nikhil R
+-  Pablo Saavedra
+-  Paul Gortmaker
+-  Pavel Zhukov
+-  Peter Kjellerstedt
+-  Qiu Tingting
+-  Quentin Schulz
+-  Randolph Sapp
+-  Randy MacLeod
+-  Ranjitsinh Rathod
+-  Richard Purdie
+-  Riyaz Khan
+-  Ross Burton
+-  Sakib Sajal
+-  Sanjay Chitroda
+-  Siddharth Doshi
+-  Soumya Sambu
+-  Steve Sakoman
+-  Sudip Mukherjee
+-  Sundeep KOKKONDA
+-  Thomas Roos
+-  Tim Orling
+-  Tom Hochstein
+-  Trevor Gamblin
+-  Ulrich Ölmann
+-  Wang Mingyu
+-  Xiangyu Chen
+
+
+Repositories / Downloads for Yocto-4.2.2
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+poky
+
+-  Repository Location: :yocto_git:`/poky`
+-  Branch: :yocto_git:`mickledore </poky/log/?h=mickledore>`
+-  Tag:  :yocto_git:`yocto-4.2.2 </poky/log/?h=yocto-4.2.2>`
+-  Git Revision: :yocto_git:`6e17b3e644ca15b8b4afd071ccaa6f172a0e681a </poky/commit/?id=6e17b3e644ca15b8b4afd071ccaa6f172a0e681a>`
+-  Release Artefact: poky-6e17b3e644ca15b8b4afd071ccaa6f172a0e681a
+-  sha: c0b4dadcf00b97d866dd4cc2f162474da2c3e3289badaa42a978bff1d479af99
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.2.2/poky-6e17b3e644ca15b8b4afd071ccaa6f172a0e681a.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.2.2/poky-6e17b3e644ca15b8b4afd071ccaa6f172a0e681a.tar.bz2
+
+openembedded-core
+
+-  Repository Location: :oe_git:`/openembedded-core`
+-  Branch: :oe_git:`mickledore </openembedded-core/log/?h=mickledore>`
+-  Tag:  :oe_git:`yocto-4.2.2 </openembedded-core/log/?h=yocto-4.2.2>`
+-  Git Revision: :oe_git:`3ef283e02b0b91daf64c3a589e1f6bb68d4f5aa1 </openembedded-core/commit/?id=3ef283e02b0b91daf64c3a589e1f6bb68d4f5aa1>`
+-  Release Artefact: oecore-3ef283e02b0b91daf64c3a589e1f6bb68d4f5aa1
+-  sha: d2fd127f46e626fa4456c193af3dbd25d4b2565db59bc23be69a3b2dd4febed5
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.2.2/oecore-3ef283e02b0b91daf64c3a589e1f6bb68d4f5aa1.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.2.2/oecore-3ef283e02b0b91daf64c3a589e1f6bb68d4f5aa1.tar.bz2
+
+meta-mingw
+
+-  Repository Location: :yocto_git:`/meta-mingw`
+-  Branch: :yocto_git:`mickledore </meta-mingw/log/?h=mickledore>`
+-  Tag:  :yocto_git:`yocto-4.2.2 </meta-mingw/log/?h=yocto-4.2.2>`
+-  Git Revision: :yocto_git:`4608d0bb7e47c52b8f6e9be259bfb1716fda9fd6 </meta-mingw/commit/?id=4608d0bb7e47c52b8f6e9be259bfb1716fda9fd6>`
+-  Release Artefact: meta-mingw-4608d0bb7e47c52b8f6e9be259bfb1716fda9fd6
+-  sha: fcbae0dedb363477492b86b8f997e06f995793285535b24dc66038845483eeef
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.2.2/meta-mingw-4608d0bb7e47c52b8f6e9be259bfb1716fda9fd6.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.2.2/meta-mingw-4608d0bb7e47c52b8f6e9be259bfb1716fda9fd6.tar.bz2
+
+bitbake
+
+-  Repository Location: :oe_git:`/bitbake`
+-  Branch: :oe_git:`2.4 </bitbake/log/?h=2.4>`
+-  Tag:  :oe_git:`yocto-4.2.2 </bitbake/log/?h=yocto-4.2.2>`
+-  Git Revision: :oe_git:`08033b63ae442c774bd3fce62844eac23e6882d7 </bitbake/commit/?id=08033b63ae442c774bd3fce62844eac23e6882d7>`
+-  Release Artefact: bitbake-08033b63ae442c774bd3fce62844eac23e6882d7
+-  sha: 1d070c133bfb6502ac04befbf082cbfda7582c8b1c48296a788384352e5061fd
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.2.2/bitbake-08033b63ae442c774bd3fce62844eac23e6882d7.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.2.2/bitbake-08033b63ae442c774bd3fce62844eac23e6882d7.tar.bz2
+
+yocto-docs
+
+-  Repository Location: :yocto_git:`/yocto-docs`
+-  Branch: :yocto_git:`mickledore </yocto-docs/log/?h=mickledore>`
+-  Tag: :yocto_git:`yocto-4.2.2 </yocto-docs/log/?h=yocto-4.2.2>`
+-  Git Revision: :yocto_git:`54d849d259a332389beea159d789f8fa92871475 </yocto-docs/commit/?id=54d849d259a332389beea159d789f8fa92871475>`
+

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

@@ -0,0 +1,263 @@
+.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
+
+Release notes for Yocto-4.2.3 (Mickledore)
+------------------------------------------
+
+Security Fixes in Yocto-4.2.3
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  bind: Fix :cve:`2023-2828` and :cve:`2023-2911`
+-  cups: Fix :cve:`2023-34241`
+-  dmidecode: Fix :cve:`2023-30630`
+-  erofs-utils: Fix :cve:`2023-33551` and :cve:`2023-33552`
+-  ghostscript: Fix :cve:`2023-36664`
+-  go: Fix :cve_mitre:`2023-24531`
+-  libarchive: ignore :cve:`2023-30571`
+-  libjpeg-turbo: Fix :cve:`2023-2804`
+-  libx11: Fix :cve:`2023-3138`
+-  ncurses: Fix :cve:`2023-29491`
+-  openssh: Fix :cve:`2023-38408`
+-  python3-certifi: Fix :cve:`2023-37920`
+-  python3-requests: Fix :cve:`2023-32681`
+-  python3: Ignore :cve:`2023-36632`
+-  qemu: fix :cve:`2023-0330`, :cve_mitre:`2023-2861`, :cve_mitre:`2023-3255` and :cve_mitre:`2023-3301`
+-  ruby: Fix :cve:`2023-36617`
+-  vim: Fix :cve:`2023-2609` and :cve:`2023-2610`
+-  webkitgtk: Fix :cve:`2023-27932` and :cve:`2023-27954`
+
+
+Fixes in Yocto-4.2.3
+~~~~~~~~~~~~~~~~~~~~
+
+-  acpica: Update :term:`SRC_URI`
+-  automake: fix buildtest patch
+-  baremetal-helloworld: Fix race condition
+-  bind: upgrade to v9.18.17
+-  binutils: stable 2.40 branch updates
+-  build-appliance-image: Update to mickledore head revision
+-  cargo.bbclass: set up cargo environment in common do_compile
+-  conf.py: add macro for Mitre CVE links
+-  curl: ensure all ptest failures are caught
+-  cve-update-nvd2-native: actually use API keys
+-  cve-update-nvd2-native: fix cvssV3 metrics
+-  cve-update-nvd2-native: handle all configuration nodes, not just first
+-  cve-update-nvd2-native: increase retry count
+-  cve-update-nvd2-native: log a little more
+-  cve-update-nvd2-native: retry all errors and sleep between retries
+-  cve-update-nvd2-native: use exact times, don't truncate
+-  dev-manual: wic.rst: Update native tools build command
+-  devtool/upgrade: raise an error if extracting source produces more than one directory
+-  diffutils: upgrade to 3.10
+-  docs: ref-manual: terms: fix typos in :term:`SPDX` term
+-  file: fix the way path is written to environment-setup.d
+-  file: return wrapper to fix builds when file is in buildtools-tarball
+-  freetype: upgrade to 2.13.1
+-  gcc-testsuite: Fix ppc cpu specification
+-  gcc: don't pass --enable-standard-branch-protection
+-  glibc-locale: use stricter matching for metapackages' runtime dependencies
+-  glibc-testsuite: Fix network restrictions causing test failures
+-  glibc/check-test-wrapper: don't emit warnings from ssh
+-  go: upgrade to 1.20.6
+-  gstreamer1.0: upgrade to 1.22.4
+-  ifupdown: install missing directories
+-  kernel-module-split add systemd modulesloaddir and modprobedir config
+-  kernel-module-split: install config modules directories only when they are needed
+-  kernel-module-split: make autoload and probeconf distribution specific
+-  kernel-module-split: use context manager to open files
+-  kernel: Fix path comparison in kernel staging dir symlinking
+-  kernel: config modules directories are handled by kernel-module-split
+-  kernel: don't fail if Modules.symvers doesn't exist
+-  libassuan: upgrade to 2.5.6
+-  libksba: upgrade to 1.6.4
+-  libnss-nis: upgrade to 3.2
+-  libproxy: fetch from git
+-  libwebp: upgrade to 1.3.1
+-  libx11: upgrade to 1.8.6
+-  libxcrypt: fix hard-coded ".so" extension
+-  linux-firmware : Add firmware of RTL8822 serie
+-  linux-firmware: Fix mediatek mt7601u firmware path
+-  linux-firmware: package firmare for Dragonboard 410c
+-  linux-firmware: split platform-specific Adreno shaders to separate packages
+-  linux-firmware: upgrade to 20230625
+-  linux-yocto/5.15: update to v5.15.124
+-  linux-yocto/6.1: cfg: update ima.cfg to match current meta-integrity
+-  linux-yocto/6.1: upgrade to v6.1.38
+-  ltp: Add kernel loopback module dependency
+-  ltp: add :term:`RDEPENDS` on findutils
+-  lttng-ust: upgrade to 2.13.6
+-  machine/arch-arm64: add -mbranch-protection=standard
+-  maintainers.inc: Modify email address
+-  mdadm: add util-linux-blockdev ptest dependency
+-  mdadm: fix 07revert-inplace ptest
+-  mdadm: fix segfaults when running ptests
+-  mdadm: fix util-linux ptest dependency
+-  mdadm: re-add mdadm-ptest to PTESTS_SLOW
+-  mdadm: skip running known broken ptests
+-  meson.bbclass: Point to llvm-config from native sysroot
+-  migration-guides: add release notes for 4.0.10
+-  migration-guides: add release notes for 4.0.11
+-  migration-guides: add release notes for 4.2.2
+-  oeqa/runtime/cases/rpm: fix wait_for_no_process_for_user failure case
+-  oeqa/runtime/ltp: Increase ltp test output timeout
+-  oeqa/selftest/devtool: add unit test for "devtool add -b"
+-  oeqa/ssh: Further improve process exit handling
+-  oeqa/target/ssh: Ensure EAGAIN doesn't truncate output
+-  oeqa/utils/nfs: allow requesting non-udp ports
+-  openssh: upgrade to 9.3p2
+-  openssl: add PERLEXTERNAL path to test its existence
+-  openssl: use a glob on the PERLEXTERNAL to track updates on the path
+-  opkg-utils: upgrade to 0.6.2
+-  opkg: upgrade to 0.6.2
+-  pkgconf: update :term:`SRC_URI`
+-  poky.conf: bump version for 4.2.3 release
+-  poky.conf: update :term:`SANITY_TESTED_DISTROS` to match autobuilder
+-  ptest-runner: Pull in parallel test fixes and output handling
+-  python3-certifi: upgrade to 2023.7.22
+-  python3: fix missing comma in get_module_deps3.py
+-  recipetool: Fix inherit in created -native* recipes
+-  ref-manual: LTS releases now supported for 4 years
+-  ref-manual: document image-specific variant of :term:`INCOMPATIBLE_LICENSE`
+-  ref-manual: releases.svg: updates
+-  resulttool/resultutils: allow index generation despite corrupt json
+-  rootfs-postcommands.bbclass: Revert "add post func remove_unused_dnf_log_lock"
+-  rootfs: Add debugfs package db file copy and cleanup
+-  rootfs_rpm: don't depend on opkg-native for update-alternatives
+-  rpm: Pick debugfs package db files/dirs explicitly
+-  rust-common.bbclass: move musl-specific linking fix from rust-source.inc
+-  scripts/oe-setup-builddir: copy conf-notes.txt to build dir
+-  scripts/resulttool: add mention about new detected tests
+-  selftest/cases/glibc.py: fix the override syntax
+-  selftest/cases/glibc.py: increase the memory for testing
+-  selftest/cases/glibc.py: switch to using NFS over TCP
+-  shadow-sysroot: add license information
+-  systemd-systemctl: fix errors in instance name expansion
+-  taglib: upgrade to 1.13.1
+-  target/ssh: Ensure exit code set for commands
+-  tcf-agent: upgrade to 1.8.0
+-  testimage/oeqa: Drop testimage_dump_host functionality
+-  tiff: upgrade to 4.5.1
+-  uboot-extlinux-config.bbclass: fix old override syntax in comment
+-  util-linux: add alternative links for ipcs,ipcrm
+-  vim: upgrade to 9.0.1592
+-  webkitgtk: upgrade to 2.38.6
+-  weston: Cleanup and fix x11 and xwayland dependencies
+
+
+Known Issues in Yocto-4.2.3
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+- N/A
+
+
+Contributors to Yocto-4.2.3
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  Alejandro Hernandez Samaniego
+-  Alex Kiernan
+-  Alexander Kanavin
+-  Alexis Lothoré
+-  Andrej Valek
+-  Anuj Mittal
+-  Archana Polampalli
+-  BELOUARGA Mohamed
+-  Benjamin Bouvier
+-  Bruce Ashfield
+-  Changqing Li
+-  Chen Qi
+-  Daniel Semkowicz
+-  Dmitry Baryshkov
+-  Enrico Scholz
+-  Etienne Cordonnier
+-  Joe Slater
+-  Joel Stanley
+-  Jose Quaresma
+-  Julien Stephan
+-  Kai Kang
+-  Khem Raj
+-  Lee Chee Yang
+-  Marek Vasut
+-  Mark Hatle
+-  Michael Halstead
+-  Michael Opdenacker
+-  Mingli Yu
+-  Narpat Mali
+-  Oleksandr Hnatiuk
+-  Ovidiu Panait
+-  Peter Marko
+-  Quentin Schulz
+-  Richard Purdie
+-  Ross Burton
+-  Sanjana
+-  Sakib Sajal
+-  Staffan Rydén
+-  Steve Sakoman
+-  Stéphane Veyret
+-  Sudip Mukherjee
+-  Thomas Roos
+-  Tom Hochstein
+-  Trevor Gamblin
+-  Wang Mingyu
+-  Yi Zhao
+-  Yoann Congal
+-  Yogita Urade
+-  Yuta Hayama
+
+
+Repositories / Downloads for Yocto-4.2.3
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+poky
+
+-  Repository Location: :yocto_git:`/poky`
+-  Branch: :yocto_git:`mickledore </poky/log/?h=mickledore>`
+-  Tag:  :yocto_git:`yocto-4.2.3 </poky/log/?h=yocto-4.2.3>`
+-  Git Revision: :yocto_git:`aa63b25cbe25d89ab07ca11ee72c17cab68df8de </poky/commit/?id=aa63b25cbe25d89ab07ca11ee72c17cab68df8de>`
+-  Release Artefact: poky-aa63b25cbe25d89ab07ca11ee72c17cab68df8de
+-  sha: 9e2b40fc25f7984b3227126ec9b8aa68d3747c8821fb7bf8cb635fc143f894c3
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.2.3/poky-aa63b25cbe25d89ab07ca11ee72c17cab68df8de.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.2.3/poky-aa63b25cbe25d89ab07ca11ee72c17cab68df8de.tar.bz2
+
+openembedded-core
+
+-  Repository Location: :oe_git:`/openembedded-core`
+-  Branch: :oe_git:`mickledore </openembedded-core/log/?h=mickledore>`
+-  Tag:  :oe_git:`yocto-4.2.3 </openembedded-core/log/?h=yocto-4.2.3>`
+-  Git Revision: :oe_git:`7e3489c0c5970389c8a239dc7b367bcadf554eb5 </openembedded-core/commit/?id=7e3489c0c5970389c8a239dc7b367bcadf554eb5>`
+-  Release Artefact: oecore-7e3489c0c5970389c8a239dc7b367bcadf554eb5
+-  sha: 68620aca7c9db6b9a65d9853cacff4e60578f0df39e3e37114e062e1667ba724
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.2.3/oecore-7e3489c0c5970389c8a239dc7b367bcadf554eb5.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.2.3/oecore-7e3489c0c5970389c8a239dc7b367bcadf554eb5.tar.bz2
+
+meta-mingw
+
+-  Repository Location: :yocto_git:`/meta-mingw`
+-  Branch: :yocto_git:`mickledore </meta-mingw/log/?h=mickledore>`
+-  Tag:  :yocto_git:`yocto-4.2.3 </meta-mingw/log/?h=yocto-4.2.3>`
+-  Git Revision: :yocto_git:`92258028e1b5664a9f832541d5c4f6de0bd05e07 </meta-mingw/commit/?id=92258028e1b5664a9f832541d5c4f6de0bd05e07>`
+-  Release Artefact: meta-mingw-92258028e1b5664a9f832541d5c4f6de0bd05e07
+-  sha: ee081460b5dff4fb8dd4869ce5631718dbaaffbede9532b879b854c18f1b3f5d
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.2.3/meta-mingw-92258028e1b5664a9f832541d5c4f6de0bd05e07.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.2.3/meta-mingw-92258028e1b5664a9f832541d5c4f6de0bd05e07.tar.bz2
+
+bitbake
+
+-  Repository Location: :oe_git:`/bitbake`
+-  Branch: :oe_git:`2.4 </bitbake/log/?h=2.4>`
+-  Tag:  :oe_git:`yocto-4.2.3 </bitbake/log/?h=yocto-4.2.3>`
+-  Git Revision: :oe_git:`08033b63ae442c774bd3fce62844eac23e6882d7 </bitbake/commit/?id=08033b63ae442c774bd3fce62844eac23e6882d7>`
+-  Release Artefact: bitbake-08033b63ae442c774bd3fce62844eac23e6882d7
+-  sha: 1d070c133bfb6502ac04befbf082cbfda7582c8b1c48296a788384352e5061fd
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.2.3/bitbake-08033b63ae442c774bd3fce62844eac23e6882d7.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.2.3/bitbake-08033b63ae442c774bd3fce62844eac23e6882d7.tar.bz2
+
+yocto-docs
+
+-  Repository Location: :yocto_git:`/yocto-docs`
+-  Branch: :yocto_git:`mickledore </yocto-docs/log/?h=mickledore>`
+-  Tag: :yocto_git:`yocto-4.2.3 </yocto-docs/log/?h=yocto-4.2.3>`
+-  Git Revision: :yocto_git:`8e6752a9e55d16f3713e248b37f9d4d2745a2375 </yocto-docs/commit/?id=8e6752a9e55d16f3713e248b37f9d4d2745a2375>`
+

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

@@ -6,23 +6,979 @@ Release notes for 4.2 (mickledore)
 New Features / Enhancements in 4.2
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-- Python 3.8 is the minimum Python version required on the build host.
-  For host distributions that do not provide it, this is included as part of the
-  :term:`buildtools` tarball.
+-  Linux kernel 6.1, glibc 2.37 and ~350 other recipe upgrades
 
-- This release now supports a new ``addpylib`` directive to enable
-  Python libraries within layers.
+-  Python 3.8+ and GCC 8.0+ are now the minimum required versions on the build host.
+   For host distributions that do not provide it, this is included as part of the
+   :term:`buildtools` tarball.
 
-  This directive should be added to your layer configuration,
-  as in the below example from ``meta/conf/layer.conf``::
+-  BitBake in this release now supports a new ``addpylib`` directive to enable
+   Python libraries within layers. For more information,
+   see :ref:`bitbake-user-manual/bitbake-user-manual-metadata:extending python library code`.
 
-     addpylib ${LAYERDIR}/lib oe
+   This directive should be added to your layer configuration
+   as in the below example from ``meta/conf/layer.conf``::
+
+      addpylib ${LAYERDIR}/lib oe
+
+-  BitBake has seen multiple internal changes that may improve
+   memory and disk usage as well as parsing time, in particular:
+
+   -  BitBake's Cooker server is now multithreaded.
+
+   -  Ctrl+C can now be used to interrupt some long-running operations
+      that previously ignored it.
+
+   -  BitBake's cache has been extended to include more hash
+      debugging data, but has also been optimized to :yocto_git:`compress
+      cache data <https://git.yoctoproject.org/poky/commit/?h=mickledore&id=7d010055e2af3294e17db862f42664ca689a9356>`.
+
+   -  BitBake's UI will now ping the server regularly to ensure
+      it is still alive.
+ 
+-  New variables:
+
+   -  :term:`VOLATILE_TMP_DIR` allows to specify
+      whether ``/tmp`` should be on persistent storage
+      or in RAM.
+
+   -  :term:`SPDX_CUSTOM_ANNOTATION_VARS` allows to add
+      specific comments to the :term:`SPDX` description of a recipe.
+
+-  Rust improvements:
+
+   -  This release adds Cargo support on the target, and includes
+      automated QA tests for this functionality.
+
+   -  It also supports checksums for Rust crates and makes
+      them mandatory for each crate in a recipe.
+
+   -  New :ref:`ref-classes-cargo-update-recipe-crates` class to
+      enable updating :term:`SRC_URI` crate lists from ``Cargo.lock``
+
+   -  Enabled building Rust for baremetal targets
+
+   -  You can now also easily select to build beta or nightly
+      versions of Rust with a new :term:`RUST_CHANNEL` variable
+      (use at own risk)
+
+   -  Support for local GitHub repos in :term:`SRC_URI` as
+      replacements for Cargo dependencies
+
+   -  Use built-in Rust targets for ``-native`` builds to save several
+      minutes building the Rust toolchain
 
 -  Architecture-specific enhancements:
 
+   -  This release adds initial support for the
+      :wikipedia:`LoongArch <Loongson#LoongArch>`
+      (``loongarch64``) architecture, though there is no testing for it yet.
+
+   -  New ``x86-64-v3`` tunes (AVX, AVX2, BMI1, BMI2, F16C, FMA, LZCNT, MOVBE, XSAVE)
+
+   -  go: add support to build on ppc64le
+   -  rust: rustfmt now working and installed for riscv32
+   -  libpng: enable NEON for aarch64 to ensure consistency with arm32.
+   -  baremetal-helloworld: Enable x86 and x86-64 ports
+
 -  Kernel-related enhancements:
 
+   -  Added some support for building 6.2/6.3-rc kernels
+   -  linux-yocto-dev: mark as compatible with qemuarm64 and qemuarmv5
+   -  Add kernel specific OBJCOPY to help switching toolchains cleanly for kernel build between gcc and clang
+
+-  New core recipes:
+
+   - ``debugedit``
+   - ``gtk4`` (import from meta-gnome)
+   - ``gcr``: add recipe for gcr-4
+   - ``graphene`` (import from meta-oe)
+   - ``libc-test``
+   - ``libportal`` (import from meta-gnome)
+   - ``libslirp``
+   - ``libtest-fatal-perl``
+   - ``libtest-warnings-perl`` (import from meta-perl)
+   - ``libtry-tiny-perl``
+   - ``python3-build``
+   - ``python3-pyproject-hooks``
+   - ``python3-hatch-fancy-pypi-readme``
+   - ``python3-unittest-automake``
+
 -  QEMU/runqemu enhancements:
 
+   -  Set ``QB_SMP`` with ?= to make it easier to modify
+   -  Set ``QB_CPU`` with ?= to make it easier to modify (x86 configuration only)
+   -  New ``QB_NFSROOTFS_EXTRA_OPT`` to allow extra options to be appended to the NFS rootfs options in kernel boot args, e.g. ``"wsize=4096,rsize=4096"``
+   -  New ``QB_SETUP_CMD`` and ``QB_CLEANUP_CMD`` to enable running custom shell setup and cleanup commands before and after QEMU.
+   -  ``QB_DEFAULT_KERNEL`` now defaults to pick the bundled initramfs kernel image if the Linux kernel image is generated with :term:`INITRAMFS_IMAGE_BUNDLE` set to "1"
+   -  Split out the QEMU guest agent to its own ``qemu-guest-agent`` package
+   -  runqemu: new ``guestagent`` option to enable communication with the guest agent
+   -  runqemu: respect :term:`IMAGE_LINK_NAME` when searching for image
+
 -  Image-related enhancements:
 
+   -  Add 7-Zip support in image conversion types (``7zip``)
+   -  New :term:`IMAGE_MACHINE_SUFFIX` variable to allow easily removing machine name suffix from image file names
+
+-  wic Image Creator enhancements:
+
+   -  ``bootimg-efi.py``: add support for directly loading Linux kernel UEFI stub
+   -  ``bootimg-efi.py``: implement ``--include-path``
+   -  Allow usage of ``fstype=none`` to specify an unformatted partition
+   -  Implement repeatable disk identifiers based on :term:`SOURCE_DATE_EPOCH`
+
+-  FIT image related improvements:
+
+   -  FIT image signing support has been reworked to remove interdependencies and make it more easily extensible
+   -  Skip FDT section creation for applicable symlinks to avoid the same dtb being duplicated
+   -  New :term:`FIT_CONF_DEFAULT_DTB` variable to enable selecting default dtb when multiple dtbs exist
+
+-  SDK-related improvements:
+
+   -  Extended the following recipes to nativesdk:
+
+      - ``bc``
+      - ``gi-docgen``
+      - ``gperf``
+      - ``python3-iniconfig``
+      - ``python3-atomicwrites``
+      - ``python3-markdown``
+      - ``python3-smartypants``
+      - ``python3-typogrify``
+      - ``ruby``
+      - ``unifdef``
+
+   -  New :term:`SDK_ZIP_OPTIONS` variable to enable passing additional options to the zip command when preparing the SDK zip archive
+   -  New Rust SDK target packagegroup (``packagegroup-rust-sdk-target``)
+
+-  Testing:
+
+   -  The ptest images have changed structure in this release. The
+      underlying ``core-image-ptest`` recipe now uses :term:`BBCLASSEXTEND` to
+      create a variant for each ptest enabled recipe in OE-Core.
+
+      For example, this means that ``core-image-ptest-bzip2``,
+      ``core-image-ptest-lttng-tools`` and many more image targets now exist
+      and can be built/tested individually.
+
+      The ``core-image-ptest-all`` and ``core-image-ptest-fast`` targets are now
+      wrappers that target groups of individual images and means that the tests
+      can be executed in parallel during our automated testing. This also means
+      the dependencies are more accurately tested.
+
+   -  It is now possible to track regression changes between releases using
+      :oe_git:`yocto_testresults_query.py </openembedded-core/tree/scripts/yocto_testresults_query.py>`,
+      which is a thin wrapper over :oe_git:`resulttool
+      </openembedded-core/tree/scripts/resulttool>`. Here is an example
+      command, which allowed to spot and fix a regression in the
+      ``quilt`` ptest::
+
+         yocto_testresults_query.py regression-report 4.2_M1 4.2_M2
+
+      See this `blog post about regression detection
+      <https://bootlin.com/blog/continuous-integration-in-yocto-improving-the-regressions-detection/>`__.
+
+   -  This release adds support for parallel ptest execution with a ptest per image.
+      This takes ptest execution time from 3.5 hours to around 45 minutes on the autobuilder.
+
+   -  Basic Rust compile/run and cargo tests
+
+   -  New ``python3-unittest-automake`` recipe which provides modules for pytest
+      and unittest to adjust their output to automake-style for easier integration
+      with the ptest system.
+
+   -  ptest support added to ``bc``, ``cpio`` and ``gnutls``, and fixes made to
+      ptests in numerous other recipes.
+
+   -  ``ptest-runner`` now adds a non-root "ptest" user to run tests.
+
+   -  ``resulttool``: add a ``--list-ptest`` option to the log subcommand to list ptest names
+      in a results file
+
+   -  ``resulttool``: regression: add metadata filtering for oeselftest
+
+-  New :term:`PACKAGECONFIG` options in the following recipes:
+
+   - ``at-spi2-core``
+   - ``base-passwd``
+   - ``cronie``
+   - ``cups``
+   - ``curl``
+   - ``file``
+   - ``gstreamer1.0-plugins-good``
+   - ``gtk+3``
+   - ``iproute2``
+   - ``libsdl2``
+   - ``libtiff``
+   - ``llvm``
+   - ``mesa``
+   - ``psmisc``
+   - ``qemu``
+   - ``sudo``
+   - ``systemd``
+   - ``tiff``
+   - ``util-linux``
+
+-  Extended the following recipes to native:
+
+   - ``iso-codes``
+   - ``libxkbcommon``
+   - ``p11-kit``
+   - ``python3-atomicwrites``
+   - ``python3-dbusmock``
+   - ``python3-iniconfig``
+   - ``xkeyboard-config``
+
+-  Utility script changes:
+
+   -  ``devtool``: ignore patch-fuzz errors when extracting source in order to enable fixing fuzz issues
+   -  ``oe-setup-layers``: make efficiently idempotent
+   -  ``oe-setup-layers``: print a note about submodules if present
+   -  New ``buildstats-summary`` script to show a summary of the buildstats data
+   -  :ref:`ref-classes-report-error` class: catch ``Nothing PROVIDES`` error
+   -  ``combo-layer``: add ``sync-revs`` command
+   -  ``convert-overrides``: allow command-line customizations
+
+-  bitbake-layers improvements:
+
+   -  ``layerindex-fetch``: checkout layer(s) branch when clone exists
+   -  ``create``: add ``-a``/``--add-layer option`` to add layer to ``bblayers.conf`` after creating layer
+   -  ``show-layers``: improve output layout
+
+-  Other BitBake improvements:
+
+   -  Inline Python snippets can now include dictionary expressions
+   -  Evaluate the value of export/unexport/network flags so that they can be reset to "0"
+   -  Make :term:`EXCLUDE_FROM_WORLD` boolean so that it can be reset to "0"
+   -  Support int values in ``bb.utils.to_boolean()`` in addition to strings
+   -  ``bitbake-getvar``: Add a ``quiet`` command line argument
+   -  Allow the ``@`` character in variable flag names
+   -  Python library code will now be included when calculating task hashes
+   -  ``fetch2/npmsw``: add more short forms for git operations
+   -  Display a warning when ``SRCREV = "${AUTOREV}"`` is set too late to be effective
+   -  Display all missing :term:`SRC_URI` checksums at once
+   -  Improve error message for a missing multiconfig
+   -  Switch to a new :term:`BB_CACHEDIR` variable for codeparser cache location
+   -  Mechanism introduced to reduce the codeparser cache unnecessarily growing in size
+
+-  Packaging changes:
+
+   -  ``rng-tools`` is no longer recommended by ``openssh``, and the ``rng-tools``
+      service files have been split out to their own package
+   -  ``linux-firmware``: split ``rtl8761`` and ``amdgpu`` firmware
+   -  ``linux-firmware``: add new firmware file to ``${PN}-qcom-adreno-a530``
+   -  ``iproute2``: separate ``routel`` and add Python dependency
+   -  ``xinetd``: move ``xconv.pl`` script to separate package
+   -  ``perf``: enable debug/source packaging
+
+-  Prominent documentation updates:
+
+   -  Substantially expanded the ":doc:`/dev-manual/vulnerabilities`" section.
+   -  Added a new ":doc:`/dev-manual/sbom`" section about SPDX SBoM generation.
+   -  Expanded ":ref:`init-manager`" documentation.
+   -  New section about :ref:`ref-long-term-support-releases`.
+   -  System Requirements: details about :ref:`system-requirements-minimum-ram`.
+   -  Details about :ref:`ref-building-meson-package` and the
+      :ref:`ref-classes-meson` class.
+   -  Documentation about how to write recipes for Rust programs. See the
+      :ref:`ref-classes-cargo` class.
+   -  Documentation about how to write recipes for Go programs. See the
+      :ref:`ref-classes-go` class.
+   -  Variable index: added references to variables only documented in the
+      BitBake manual. All variables should be easy to access through the Yocto
+      Manual variable index.
+   -  Expanded the description of the :term:`BB_NUMBER_THREADS` variable.
+      
+-  Miscellaneous changes:
+
+   -  Supporting 64 bit dates on 32 bit platforms: several packages have been
+      updated to pass year 2038 tests, and a QA check for 32 bit time and file
+      offset functions has been added (default off)
+
+   -  Patch fuzz/Upstream-Status checking has been reworked:
+
+      -  Upstream-Status checking is now configurable from :term:`WARN_QA`/:term:`ERROR_QA` (``patch-status-core``)
+      -  Can now be enabled for non-core layers (``patch-status-noncore``)
+      -  ``patch-fuzz`` is now in :term:`ERROR_QA` by default, and actually stops the build
+
+   -  Many packages were updated to add large file support.
+
+   -  ``vulkan-loader``: allow headless targets to build the loader
+   -  ``dhcpcd``: fix to work with systemd
+   -  ``u-boot``: add /boot to :term:`SYSROOT_DIRS` to allow boot files to be used by other recipes
+   -  ``linux-firmware``: don't put the firmware into the sysroot
+   -  ``cups``: add :term:`PACKAGECONFIG` to control web interface and default to off
+   -  ``buildtools-tarball``: export certificates to python and curl
+   -  ``yocto-check-layer``: allow OE-Core to be tested
+   -  ``yocto-check-layer``: check for patch file upstream status
+   -  ``boost``: enable building ``Boost.URL`` library
+   -  ``native``: drop special variable handling
+   -  Poky: make it easier to set :term:`INIT_MANAGER` from local.conf
+   -  :ref:`ref-classes-create-spdx`: add support for custom annotations (:term:`SPDX_CUSTOM_ANNOTATION_VARS`)
+   -  :ref:`ref-classes-create-spdx`: report downloads as separate packages
+   -  :ref:`ref-classes-create-spdx`: remove the top-level image SPDX file and the JSON index file from :term:`DEPLOYDIR` to avoid confusion
+   -  ``os-release``: replace ``DISTRO_CODENAME`` with ``VERSION_CODENAME`` (still set from :term:`DISTRO_CODENAME`)
+   -  ``weston``: add kiosk shell
+   -  :ref:`ref-classes-overlayfs`: Allow unused mount points
+   -  ``sstatesig``: emit more helpful error message when not finding sstate manifest
+   -  :ref:`ref-classes-pypi`.bbclass: Set :term:`SRC_URI` downloadfilename with an optional prefix
+   -  ``poky-bleeding`` distro: update and rework
+   -  :ref:`package.bbclass <ref-classes-package>`: check if package names conflict via ``PKG:${PN}`` override in :ref:`do_package <ref-tasks-package>`
+   -  ``cve-update-nvd2-native``: new NVD CVE database fetcher using the 2.0 API
+   -  :ref:`ref-classes-mirrors` class: use shallow tarball for ``binutils-native``/``nativesdk-binutils``
+   -  ``meta/conf``: move default configuration templates into ``meta/conf/templates/default``
+   -  ``binutils``: enable ``--enable-new-dtags`` as per many Linux distributions
+   -  ``base-files``: drop ``localhost.localdomain`` from hosts file as per many Linux distributions
+   -  ``packagegroup-core-boot``: make ``init-ifupdown`` package a recommendation
+
+Known Issues in 4.2
+~~~~~~~~~~~~~~~~~~~
+
+- N/A
+
+Recipe License changes in 4.2
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The following corrections have been made to the :term:`LICENSE` values set by recipes:
+
+- ``curl``: set :term:`LICENSE` appropriately to ``curl`` as it is a special derivative of the MIT/X license, not exactly that license.
+- ``libgit2``: added ``Zlib``, ``ISC``, ``LGPL-2.1-or-later`` and ``CC0-1.0`` to :term:`LICENSE` covering portions of the included code.
+- ``linux-firmware``: set package :term:`LICENSE` appropriately for all qcom packages
+
+Security Fixes in 4.2
+~~~~~~~~~~~~~~~~~~~~~
+
+- binutils: :cve:`2022-4285`, `CVE-2023-25586 <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-25586>`__
+- curl: :cve:`2022-32221`, :cve:`2022-35260`, :cve:`2022-42915`, :cve:`2022-42916`
+- epiphany: :cve:`2023-26081`
+- expat: :cve:`2022-43680`
+- ffmpeg: :cve:`2022-3964`, :cve:`2022-3965`
+- git: :cve:`2022-39260`, :cve:`2022-41903`, :cve:`2022-23521`, :cve:`2022-41953` (ignored)
+- glibc: :cve:`2023-25139` (ignored)
+- go: :cve:`2023-24532`, :cve:`2023-24537`
+- grub2: :cve:`2022-2601`, :cve:`2022-3775`, `CVE-2022-28736 <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-28736>`__
+- inetutils: :cve:`2019-0053`
+- less: :cve:`2022-46663`
+- libarchive: :cve:`2022-36227`
+- libinput: :cve:`2022-1215`
+- libpam: :cve:`2022-28321`
+- libpng: :cve:`2019-6129`
+- libx11: :cve:`2022-3554`
+- openssh: :cve:`2023-28531`
+- openssl: :cve:`2022-3358`, :cve:`2022-3786`, :cve:`2022-3602`, :cve:`2022-3996`, :cve:`2023-0286`, :cve:`2022-4304`, :cve:`2022-4203`, :cve:`2023-0215`, :cve:`2022-4450`, :cve:`2023-0216`, :cve:`2023-0217`, :cve:`2023-0401`, :cve:`2023-0464`
+- ppp: :cve:`2022-4603`
+- python3-cryptography{-vectors}: :cve:`2022-3602`, :cve:`2022-3786`, :cve:`2023-23931`
+- python3: `CVE-2022-37460 <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-37460>`__
+- qemu: :cve:`2022-3165`
+- rust: :cve:`2022-46176`
+- rxvt-unicode: :cve:`2022-4170`
+- screen: :cve:`2023-24626`
+- shadow: :cve:`2023-29383`, :cve:`2016-15024` (ignored)
+- sudo: :cve:`2022-43995`
+- systemd: :cve:`2022-4415` (ignored)
+- tar: :cve:`2022-48303`
+- tiff: :cve:`2022-3599`, :cve:`2022-3597`, :cve:`2022-3626`, :cve:`2022-3627`, :cve:`2022-3570`, :cve:`2022-3598`, :cve:`2022-3970`, :cve:`2022-48281`
+- vim: :cve:`2022-3352`, :cve:`2022-4141`, :cve:`2023-0049`, :cve:`2023-0051`, :cve:`2023-0054`, :cve:`2023-0288`, :cve:`2023-1127`, :cve:`2023-1170`, :cve:`2023-1175`, :cve:`2023-1127`, :cve:`2023-1170`, :cve:`2023-1175`, :cve:`2023-1264`, :cve:`2023-1355`, :cve:`2023-0433`, :cve:`2022-47024`, :cve:`2022-3705`
+- xdg-utils: :cve:`2022-4055`
+- xserver-xorg: :cve:`2022-3550`, :cve:`2022-3551`, :cve:`2023-1393`, :cve:`2023-0494`, :cve:`2022-3553` (ignored)
+
+Recipe Upgrades in 4.2
+~~~~~~~~~~~~~~~~~~~~~~
+
+- acpid: upgrade 2.0.33 -> 2.0.34
+- adwaita-icon-theme: update 42.0 -> 43
+- alsa-lib: upgrade 1.2.7.2 -> 1.2.8
+- alsa-ucm-conf: upgrade 1.2.7.2 -> 1.2.8
+- alsa-utils: upgrade 1.2.7 -> 1.2.8
+- apr: update 1.7.0 -> 1.7.2
+- apr-util: update 1.6.1 -> 1.6.3
+- argp-standalone: replace with a maintained fork
+- at-spi2-core: upgrade 2.44.1 -> 2.46.0
+- autoconf-archive: upgrade 2022.09.03 -> 2023.02.20
+- babeltrace: upgrade 1.5.8 -> 1.5.11
+- base-passwd: Update to 3.6.1
+- bash: update 5.1.16 -> 5.2.15
+- bind: upgrade 9.18.7 -> 9.18.12
+- binutils: Upgrade to 2.40 release
+- bluez: update 5.65 -> 5.66
+- boost-build-native: update 1.80.0 -> 1.81.0
+- boost: upgrade 1.80.0 -> 1.81.0
+- btrfs-tools: upgrade 5.19.1 -> 6.1.3
+- busybox: 1.35.0 -> 1.36.0
+- ccache: upgrade 4.6.3 -> 4.7.4
+- cmake: update 3.24.0 -> 3.25.2
+- cracklib: upgrade to v2.9.10
+- curl: upgrade 7.86.0 -> 8.0.1
+- dbus: upgrade 1.14.0 -> 1.14.6
+- diffoscope: upgrade 221 -> 236
+- diffstat: upgrade 1.64 -> 1.65
+- diffutils: update 3.8 -> 3.9
+- dos2unix: upgrade 7.4.3 -> 7.4.4
+- dpkg: update 1.21.9 -> 1.21.21
+- dropbear: upgrade 2022.82 -> 2022.83
+- dtc: upgrade 1.6.1 -> 1.7.0
+- e2fsprogs: upgrade 1.46.5 -> 1.47.0
+- ed: upgrade 1.18 -> 1.19
+- elfutils: update 0.187 -> 0.188
+- ell: upgrade 0.53 -> 0.56
+- enchant2: upgrade 2.3.3 -> 2.3.4
+- encodings: update 1.0.6 -> 1.0.7
+- epiphany: update 42.4 -> 43.1
+- ethtool: upgrade 5.19 -> 6.2
+- expat: upgrade to 2.5.0
+- ffmpeg: upgrade 5.1.1 -> 5.1.2
+- file: upgrade 5.43 -> 5.44
+- flac: update 1.4.0 -> 1.4.2
+- font-alias: update 1.0.4 -> 1.0.5
+- fontconfig: upgrade 2.14.0 -> 2.14.2
+- font-util: upgrade 1.3.3 -> 1.4.0
+- freetype: update 2.12.1 -> 2.13.0
+- gawk: update 5.1.1 -> 5.2.1
+- gcr3: update 3.40.0 -> 3.41.1
+- gcr: rename gcr -> gcr3
+- gdb: Upgrade to 13.1
+- gdk-pixbuf: upgrade 2.42.9 -> 2.42.10
+- gettext: update 0.21 -> 0.21.1
+- ghostscript: update 9.56.1 -> 10.0.0
+- gi-docgen: upgrade 2022.1 -> 2023.1
+- git: upgrade 2.37.3 -> 2.39.2
+- glib-2.0: update 2.72.3 -> 2.74.6
+- glibc: upgrade to 2.37 release + stable updates
+- glib-networking: update 2.72.2 -> 2.74.0
+- glslang: upgrade 1.3.236.0 -> 1.3.239.0
+- gnu-config: upgrade to latest revision
+- gnupg: upgrade 2.3.7 -> 2.4.0
+- gnutls: upgrade 3.7.7 -> 3.8.0
+- gobject-introspection: upgrade 1.72.0 -> 1.74.0
+- go: update 1.19 -> 1.20.1
+- grep: update 3.7 -> 3.10
+- gsettings-desktop-schemas: upgrade 42.0 -> 43.0
+- gstreamer1.0: upgrade 1.20.3 -> 1.22.0
+- gtk+3: upgrade 3.24.34 -> 3.24.36
+- gtk4: update 4.8.2 -> 4.10.0
+- harfbuzz: upgrade 5.1.0 -> 7.1.0
+- hdparm: update 9.64 -> 9.65
+- help2man: upgrade 1.49.2 -> 1.49.3
+- icu: update 71.1 -> 72-1
+- ifupdown: upgrade 0.8.37 -> 0.8.41
+- igt-gpu-tools: upgrade 1.26 -> 1.27.1
+- inetutils: upgrade 2.3 -> 2.4
+- init-system-helpers: upgrade 1.64 -> 1.65.2
+- iproute2: upgrade 5.19.0 -> 6.2.0
+- iptables: update 1.8.8 -> 1.8.9
+- iputils: update to 20221126
+- iso-codes: upgrade 4.11.0 -> 4.13.0
+- jquery: upgrade 3.6.0 -> 3.6.3
+- kexec-tools: upgrade 2.0.25 -> 2.0.26
+- kmscube: upgrade to latest revision
+- libarchive: upgrade 3.6.1 -> 3.6.2
+- libbsd: upgrade 0.11.6 -> 0.11.7
+- libcap: upgrade 2.65 -> 2.67
+- libdnf: update 0.69.0 -> 0.70.0
+- libdrm: upgrade 2.4.113 -> 2.4.115
+- libedit: upgrade 20210910-3.1 -> 20221030-3.1
+- libepoxy: update 1.5.9 -> 1.5.10
+- libffi: upgrade 3.4.2 -> 3.4.4
+- libfontenc: upgrade 1.1.6 -> 1.1.7
+- libgit2: upgrade 1.5.0 -> 1.6.3
+- libgpg-error: update 1.45 -> 1.46
+- libhandy: update 1.6.3 -> 1.8.1
+- libical: upgrade 3.0.14 -> 3.0.16
+- libice: update 1.0.10 -> 1.1.1
+- libidn2: upgrade 2.3.3 -> 2.3.4
+- libinput: upgrade 1.19.4 -> 1.22.1
+- libjpeg-turbo: upgrade 2.1.4 -> 2.1.5.1
+- libksba: upgrade 1.6.0 -> 1.6.3
+- libmicrohttpd: upgrade 0.9.75 -> 0.9.76
+- libmodule-build-perl: update 0.4231 -> 0.4232
+- libmpc: upgrade 1.2.1 -> 1.3.1
+- libnewt: update 0.52.21 -> 0.52.23
+- libnotify: upgrade 0.8.1 -> 0.8.2
+- libpcap: upgrade 1.10.1 -> 1.10.3
+- libpciaccess: update 0.16 -> 0.17
+- libpcre2: upgrade 10.40 -> 10.42
+- libpipeline: upgrade 1.5.6 -> 1.5.7
+- libpng: upgrade 1.6.38 -> 1.6.39
+- libpsl: upgrade 0.21.1 -> 0.21.2
+- librepo: upgrade 1.14.5 -> 1.15.1
+- libsdl2: upgrade 2.24.1 -> 2.26.3
+- libsm: 1.2.3 > 1.2.4
+- libsndfile1: upgrade 1.1.0 -> 1.2.0
+- libsolv: upgrade 0.7.22 -> 0.7.23
+- libsoup-2.4: upgrade 2.74.2 -> 2.74.3
+- libsoup: upgrade 3.0.7 -> 3.2.2
+- libtest-fatal-perl: upgrade 0.016 -> 0.017
+- libtest-needs-perl: upgrade 0.002009 -> 0.002010
+- libunistring: upgrade 1.0 -> 1.1
+- liburcu: upgrade 0.13.2 -> 0.14.0
+- liburi-perl: upgrade 5.08 -> 5.17
+- libva: upgrade 2.15.0 -> 2.16.0
+- libva-utils: upgrade 2.15.0 -> 2.17.1
+- libwebp: upgrade 1.2.4 -> 1.3.0
+- libwpe: upgrade 1.12.3 -> 1.14.1
+- libx11: 1.8.1 -> 1.8.4
+- libx11-compose-data: 1.6.8 -> 1.8.4
+- libxau: upgrade 1.0.10 -> 1.0.11
+- libxcomposite: update 0.4.5 -> 0.4.6
+- libxcrypt-compat: upgrade 4.4.30 -> 4.4.33
+- libxcrypt: upgrade 4.4.28 -> 4.4.30
+- libxdamage: update 1.1.5 -> 1.1.6
+- libxdmcp: update 1.1.3 -> 1.1.4
+- libxext: update 1.3.4 -> 1.3.5
+- libxft: update 2.3.4 -> 2.3.6
+- libxft: upgrade 2.3.6 -> 2.3.7
+- libxinerama: update 1.1.4 -> 1.1.5
+- libxkbcommon: upgrade 1.4.1 -> 1.5.0
+- libxkbfile: update 1.1.0 -> 1.1.1
+- libxkbfile: upgrade 1.1.1 -> 1.1.2
+- libxml2: upgrade 2.9.14 -> 2.10.3
+- libxmu: update 1.1.3 -> 1.1.4
+- libxpm: update 3.5.13 -> 3.5.15
+- libxrandr: update 1.5.2 -> 1.5.3
+- libxrender: update 0.9.10 -> 0.9.11
+- libxres: update 1.2.1 -> 1.2.2
+- libxscrnsaver: update 1.2.3 -> 1.2.4
+- libxshmfence: update 1.3 -> 1.3.2
+- libxslt: upgrade 1.1.35 -> 1.1.37
+- libxtst: update 1.2.3 -> 1.2.4
+- libxv: update 1.0.11 -> 1.0.12
+- libxxf86vm: update 1.1.4 -> 1.1.5
+- lighttpd: upgrade 1.4.66 -> 1.4.69
+- linux-firmware: upgrade 20220913 -> 20230210
+- linux-libc-headers: bump to 6.1
+- linux-yocto/5.15: update genericx86* machines to v5.15.103
+- linux-yocto/5.15: update to v5.15.108
+- linux-yocto/6.1: update to v6.1.25
+- linux-yocto-dev: bump to v6.3
+- linux-yocto-rt/5.15: update to -rt59
+- linux-yocto-rt/6.1: update to -rt7
+- llvm: update 14.0.6 -> 15.0.7
+- log4cplus: upgrade 2.0.8 -> 2.1.0
+- logrotate: upgrade 3.20.1 -> 3.21.0
+- lsof: upgrade 4.95.0 -> 4.98.0
+- ltp: upgrade 20220527 -> 20230127
+- lttng-modules: upgrade 2.13.4 -> 2.13.9
+- lttng-tools: update 2.13.8 -> 2.13.9
+- lttng-ust: upgrade 2.13.4 -> 2.13.5
+- makedepend: upgrade 1.0.6 -> 1.0.8
+- make: update 4.3 -> 4.4.1
+- man-db: update 2.10.2 -> 2.11.2
+- man-pages: upgrade 5.13 -> 6.03
+- matchbox-config-gtk: Update to latest SRCREV
+- matchbox-desktop-2: Update 2.2 -> 2.3
+- matchbox-panel-2: Update 2.11 -> 2.12
+- matchbox-terminal: Update to latest SRCREV
+- matchbox-wm: Update 1.2.2 -> 1.2.3
+- mc: update 4.8.28 -> 4.8.29
+- mesa: update 22.2.0 -> 23.0.0
+- meson: upgrade 0.63.2 -> 1.0.1
+- mmc-utils: upgrade to latest revision
+- mobile-broadband-provider-info: upgrade 20220725 -> 20221107
+- mpfr: upgrade 4.1.0 -> 4.2.0
+- mpg123: upgrade 1.30.2 -> 1.31.2
+- msmtp: upgrade 1.8.22 -> 1.8.23
+- mtd-utils: upgrade 2.1.4 -> 2.1.5
+- mtools: upgrade 4.0.40 -> 4.0.42
+- musl-obstack: Update to 1.2.3
+- musl: Upgrade to latest master
+- nasm: update 2.15.05 -> 2.16.01
+- ncurses: upgrade 6.3+20220423 -> 6.4
+- netbase: upgrade 6.3 -> 6.4
+- newlib: Upgrade 4.2.0 -> 4.3.0
+- nghttp2: upgrade 1.49.0 -> 1.52.0
+- numactl: upgrade 2.0.15 -> 2.0.16
+- opensbi: Upgrade to 1.2 release
+- openssh: upgrade 9.0p1 -> 9.3p1
+- openssl: Upgrade 3.0.5 -> 3.1.0
+- opkg: upgrade to version 0.6.1
+- orc: upgrade 0.4.32 -> 0.4.33
+- ovmf: upgrade edk2-stable202205 -> edk2-stable202211
+- pango: upgrade 1.50.9 -> 1.50.13
+- patchelf: upgrade 0.15.0 -> 0.17.2
+- pciutils: upgrade 3.8.0 -> 3.9.0
+- piglit: upgrade to latest revision
+- pinentry: update 1.2.0 -> 1.2.1
+- pixman: upgrade 0.40.0 -> 0.42.2
+- pkgconf: upgrade 1.9.3 -> 1.9.4
+- popt: update 1.18 -> 1.19
+- powertop: upgrade 2.14 -> 2.15
+- procps: update 3.3.17 -> 4.0.3
+- psmisc: upgrade 23.5 -> 23.6
+- puzzles: upgrade to latest revision
+- python3-alabaster: upgrade 0.7.12 -> 0.7.13
+- python3-attrs: upgrade 22.1.0 -> 22.2.0
+- python3-babel: upgrade 2.10.3 -> 2.12.1
+- python3-bcrypt: upgrade 3.2.2 -> 4.0.1
+- python3-certifi: upgrade 2022.9.14 -> 2022.12.7
+- python3-chardet: upgrade 5.0.0 -> 5.1.0
+- python3-cryptography: upgrade 38.0.3 -> 39.0.4
+- python3-cryptography-vectors: upgrade 37.0.4 -> 39.0.2
+- python3-cython: upgrade 0.29.32 -> 0.29.33
+- python3-dbusmock: update 0.28.4 -> 0.28.7
+- python3-dbus: upgrade 1.2.18 -> 1.3.2
+- python3-dtschema: upgrade 2022.8.3 -> 2023.1
+- python3-flit-core: upgrade 3.7.1 -> 3.8.0
+- python3-gitdb: upgrade 4.0.9 -> 4.0.10
+- python3-git: upgrade 3.1.27 -> 3.1.31
+- python3-hatch-fancy-pypi-readme: upgrade 22.7.0 -> 22.8.0
+- python3-hatchling: upgrade 1.9.0 -> 1.13.0
+- python3-hatch-vcs: upgrade 0.2.0 -> 0.3.0
+- python3-hypothesis: upgrade 6.54.5 -> 6.68.2
+- python3-importlib-metadata: upgrade 4.12.0 -> 6.0.0
+- python3-iniconfig: upgrade 1.1.1 -> 2.0.0
+- python3-installer: update 0.5.1 -> 0.6.0
+- python3-iso8601: upgrade 1.0.2 -> 1.1.0
+- python3-jsonschema: upgrade 4.9.1 -> 4.17.3
+- python3-lxml: upgrade 4.9.1 -> 4.9.2
+- python3-mako: upgrade 1.2.2 -> 1.2.4
+- python3-markupsafe: upgrade 2.1.1 -> 2.1.2
+- python3-more-itertools: upgrade 8.14.0 -> 9.1.0
+- python3-numpy: upgrade 1.23.3 -> 1.24.2
+- python3-packaging: upgrade to 23.0
+- python3-pathspec: upgrade 0.10.1 -> 0.11.0
+- python3-pbr: upgrade 5.10.0 -> 5.11.1
+- python3-pip: upgrade 22.2.2 -> 23.0.1
+- python3-poetry-core: upgrade 1.0.8 -> 1.5.2
+- python3-psutil: upgrade 5.9.2 -> 5.9.4
+- python3-pycairo: upgrade 1.21.0 -> 1.23.0
+- python3-pycryptodome: upgrade 3.15.0 -> 3.17
+- python3-pycryptodomex: upgrade 3.15.0 -> 3.17
+- python3-pygments: upgrade 2.13.0 -> 2.14.0
+- python3-pyopenssl: upgrade 22.0.0 -> 23.0.0
+- python3-pyrsistent: upgrade 0.18.1 -> 0.19.3
+- python3-pytest-subtests: upgrade 0.8.0 -> 0.10.0
+- python3-pytest: upgrade 7.1.3 -> 7.2.2
+- python3-pytz: upgrade 2022.2.1 -> 2022.7.1
+- python3-requests: upgrade 2.28.1 -> 2.28.2
+- python3-scons: upgrade 4.4.0 -> 4.5.2
+- python3-setuptools-rust: upgrade 1.5.1 -> 1.5.2
+- python3-setuptools-scm: upgrade 7.0.5 -> 7.1.0
+- python3-setuptools: upgrade 65.0.2 -> 67.6.0
+- python3-sphinxcontrib-applehelp: update 1.0.2 -> 1.0.4
+- python3-sphinxcontrib-htmlhelp: 2.0.0 -> 2.0.1
+- python3-sphinx-rtd-theme: upgrade 1.0.0 -> 1.2.0
+- python3-sphinx: upgrade 5.1.1 -> 6.1.3
+- python3-subunit: upgrade 1.4.0 -> 1.4.2
+- python3-testtools: upgrade 2.5.0 -> 2.6.0
+- python3-typing-extensions: upgrade 4.3.0 -> 4.5.0
+- python3: update 3.10.6 -> 3.11.2
+- python3-urllib3: upgrade 1.26.12 -> 1.26.15
+- python3-wcwidth: upgrade 0.2.5 -> 0.2.6
+- python3-wheel: upgrade 0.37.1 -> 0.40.0
+- python3-zipp: upgrade 3.8.1 -> 3.15.0
+- qemu: update 7.1.0 -> 7.2.0
+- quota: update 4.06 -> 4.09
+- readline: update 8.1.2 -> 8.2
+- repo: upgrade 2.29.2 -> 2.32
+- rgb: update 1.0.6 -> 1.1.0
+- rng-tools: upgrade 6.15 -> 6.16
+- rsync: update 3.2.5 -> 3.2.7
+- rt-tests: update 2.4 -> 2.5
+- ruby: update 3.1.2 -> 3.2.1
+- rust: update 1.63.0 -> 1.68.1
+- rxvt-unicode: upgrade 9.30 -> 9.31
+- sed: update 4.8 -> 4.9
+- shaderc: upgrade 2022.2 -> 2023.2
+- shadow: update 4.12.1 -> 4.13
+- socat: upgrade 1.7.4.3 -> 1.7.4.4
+- spirv-headers: upgrade 1.3.236.0 -> 1.3.239.0
+- spirv-tools: upgrade 1.3.236.0 -> 1.3.239.0
+- sqlite3: upgrade 3.39.3 -> 3.41.0
+- strace: upgrade 5.19 -> 6.2
+- stress-ng: update 0.14.03 -> 0.15.06
+- sudo: upgrade 1.9.11p3 -> 1.9.13p3
+- swig: update 4.0.2 -> 4.1.1
+- sysstat: upgrade 12.6.0 -> 12.6.2
+- systemd: update 251.4 -> 253.1
+- systemtap: upgrade 4.7 -> 4.8
+- taglib: upgrade 1.12 -> 1.13
+- tcf-agent: Update to current version
+- tcl: update 8.6.11 -> 8.6.13
+- texinfo: update 6.8 -> 7.0.2
+- tiff: update 4.4.0 -> 4.5.0
+- tzdata: update 2022d -> 2023c
+- u-boot: upgrade 2022.07 -> 2023.01
+- unfs: update 0.9.22 -> 0.10.0
+- usbutils: upgrade 014 -> 015
+- util-macros: upgrade 1.19.3 -> 1.20.0
+- vala: upgrade 0.56.3 -> 0.56.4
+- valgrind: update to 3.20.0
+- vim: Upgrade 9.0.0598 -> 9.0.1429
+- virglrenderer: upgrade 0.10.3 -> 0.10.4
+- vte: update 0.68.0 -> 0.72.0
+- vulkan-headers: upgrade 1.3.236.0 -> 1.3.239.0
+- vulkan-loader: upgrade 1.3.236.0 -> 1.3.239.0
+- vulkan-samples: update to latest revision
+- vulkan-tools: upgrade 1.3.236.0 -> 1.3.239.0
+- vulkan: update 1.3.216.0 -> 1.3.236.0
+- wayland-protocols: upgrade 1.26 -> 1.31
+- wayland-utils: update 1.0.0 -> 1.1.0
+- webkitgtk: update 2.36.7 -> 2.38.5
+- weston: update 10.0.2 -> 11.0.1
+- wireless-regdb: upgrade 2022.08.12 -> 2023.02.13
+- wpebackend-fdo: upgrade 1.12.1 -> 1.14.0
+- xcb-util: update 0.4.0 -> 0.4.1
+- xcb-util-keysyms: 0.4.0 -> 0.4.1
+- xcb-util-renderutil: 0.3.9 -> 0.3.10
+- xcb-util-wm: 0.4.1 -> 0.4.2
+- xcb-util-image: 0.4.0 -> 0.4.1
+- xf86-input-mouse: update 1.9.3 -> 1.9.4
+- xf86-input-vmmouse: update 13.1.0 -> 13.2.0
+- xf86-video-vesa: update 2.5.0 -> 2.6.0
+- xf86-video-vmware: update 13.3.0 -> 13.4.0
+- xhost: update 1.0.8 -> 1.0.9
+- xinit: update 1.4.1 -> 1.4.2
+- xkbcomp: update 1.4.5 -> 1.4.6
+- xkeyboard-config: upgrade 2.36 -> 2.38
+- xprop: update 1.2.5 -> 1.2.6
+- xrandr: upgrade 1.5.1 -> 1.5.2
+- xserver-xorg: upgrade 21.1.4 -> 21.1.7
+- xset: update 1.2.4 -> 1.2.5
+- xvinfo: update 1.1.4 -> 1.1.5
+- xwayland: upgrade 22.1.3 -> 22.1.8
+- xz: upgrade 5.2.6 -> 5.4.2
+- zlib: upgrade 1.2.12 -> 1.2.13
+- zstd: upgrade 1.5.2 -> 1.5.4
+
+Contributors to 4.2
+~~~~~~~~~~~~~~~~~~~
+
+Thanks to the following people who contributed to this release:
+
+- Adrian Freihofer
+- Ahmad Fatoum
+- Alejandro Hernandez Samaniego
+- Alexander Kanavin
+- Alexandre Belloni
+- Alexey Smirnov
+- Alexis Lothoré
+- Alex Kiernan
+- Alex Stewart
+- Andrej Valek
+- Andrew Geissler
+- Anton Antonov
+- Antonin Godard
+- Archana Polampalli
+- Armin Kuster
+- Arnout Vandecappelle
+- Arturo Buzarra
+- Atanas Bunchev
+- Benjamin Szőke
+- Benoît Mauduit
+- Bernhard Rosenkränzer
+- Bruce Ashfield
+- Caner Altinbasak
+- Carlos Alberto Lopez Perez
+- Changhyeok Bae
+- Changqing Li
+- Charlie Johnston
+- Chase Qi
+- Chee Yang Lee
+- Chen Qi
+- Chris Elledge
+- Christian Eggers
+- Christoph Lauer
+- Chuck Wolber
+- Ciaran Courtney
+- Claus Stovgaard
+- Clément Péron
+- Daniel Ammann
+- David Bagonyi
+- Denys Dmytriyenko
+- Denys Zagorui
+- Diego Sueiro
+- Dmitry Baryshkov
+- Ed Tanous
+- Enguerrand de Ribaucourt
+- Enrico Jörns
+- Enrico Scholz
+- Etienne Cordonnier
+- Fabio Estevam
+- Fabre Sébastien
+- Fawzi KHABER
+- Federico Pellegrin
+- Frank de Brabander
+- Frederic Martinsons
+- Geoffrey GIRY
+- George Kelly
+- Harald Seiler
+- He Zhe
+- Hitendra Prajapati
+- Jagadeesh Krishnanjanappa
+- James Raphael Tiovalen
+- Jan Kircher
+- Jan Luebbe
+- Jan-Simon Moeller
+- Javier Tia
+- Jeremy Puhlman
+- Jermain Horsman
+- Jialing Zhang
+- Joel Stanley
+- Joe Slater
+- Johan Korsnes
+- Jon Mason
+- Jordan Crouse
+- Jose Quaresma
+- Joshua Watt
+- Justin Bronder
+- Kai Kang
+- Kasper Revsbech
+- Keiya Nobuta
+- Kenfe-Mickael Laventure
+- Kevin Hao
+- Khem Raj
+- Konrad Weihmann
+- Lei Maohui
+- Leon Anavi
+- Liam Beguin
+- Louis Rannou
+- Luca Boccassi
+- Luca Ceresoli
+- Luis Martins
+- Maanya Goenka
+- Marek Vasut
+- Mark Asselstine
+- Mark Hatle
+- Markus Volk
+- Marta Rybczynska
+- Martin Jansa
+- Martin Larsson
+- Mateusz Marciniec
+- Mathieu Dubois-Briand
+- Mauro Queiros
+- Maxim Uvarov
+- Michael Halstead
+- Michael Opdenacker
+- Mike Crowe
+- Mikko Rapeli
+- Ming Liu
+- Mingli Yu
+- Narpat Mali
+- Nathan Rossi
+- Niko Mauno
+- Ola x Nilsson
+- Oliver Lang
+- Ovidiu Panait
+- Pablo Saavedra
+- Patrick Williams
+- Paul Eggleton
+- Paulo Neves
+- Pavel Zhukov
+- Pawel Zalewski
+- Pedro Baptista
+- Peter Bergin
+- Peter Kjellerstedt
+- Peter Marko
+- Petr Kubizňák
+- Petr Vorel
+- pgowda
+- Piotr Łobacz
+- Quentin Schulz
+- Randy MacLeod
+- Ranjitsinh Rathod
+- Ravineet Singh
+- Ravula Adhitya Siddartha
+- Richard Elberger
+- Richard Leitner
+- Richard Purdie
+- Robert Andersson
+- Robert Joslyn
+- Robert Yang
+- Romuald JEANNE
+- Ross Burton
+- Ryan Eatmon
+- Sakib Sajal
+- Sandeep Gundlupet Raju
+- Saul Wold
+- Sean Anderson
+- Sergei Zhmylev
+- Siddharth Doshi
+- Soumya
+- Sudip Mukherjee
+- Sundeep KOKKONDA
+- Teoh Jay Shen
+- Thomas De Schampheleire
+- Thomas Perrot
+- Thomas Roos
+- Tim Orling
+- Tobias Hagelborn
+- Tom Hochstein
+- Trevor Woerner
+- Ulrich Ölmann
+- Vincent Davis Jr
+- Vivek Kumbhar
+- Vyacheslav Yurkov
+- Wang Mingyu
+- Wentao Zhang
+- Xiangyu Chen
+- Xiaotian Wu
+- Yan Xinkuan
+- Yash Shinde
+- Yi Zhao
+- Yoann Congal
+- Yureka Lilian
+- Zang Ruochen
+- Zheng Qiu
+- Zheng Ruoqin
+- Zoltan Boszormenyi
+- 张忠山
+
+
+Repositories / Downloads for Yocto-4.2
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+poky
+
+-  Repository Location: :yocto_git:`/poky`
+-  Branch: :yocto_git:`mickledore </poky/log/?h=mickledore>`
+-  Tag:  :yocto_git:`yocto-4.2 </poky/log/?h=yocto-4.2>`
+-  Git Revision: :yocto_git:`21790e71d55f417f27cd51fae9dd47549758d4a0 </poky/commit/?id=21790e71d55f417f27cd51fae9dd47549758d4a0>`
+-  Release Artefact: poky-21790e71d55f417f27cd51fae9dd47549758d4a0
+-  sha: 38606076765d912deec84e523403709ef1249122197e61454ae08818e60f83c2
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.2/poky-21790e71d55f417f27cd51fae9dd47549758d4a0.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.2/poky-21790e71d55f417f27cd51fae9dd47549758d4a0.tar.bz2
+
+openembedded-core
+
+-  Repository Location: :oe_git:`/openembedded-core`
+-  Branch: :oe_git:`mickledore </openembedded-core/log/?h=mickledore>`
+-  Tag:  :oe_git:`yocto-4.2 </openembedded-core/log/?h=yocto-4.2>`
+-  Git Revision: :oe_git:`c57d1a561db563ed2f521bbac5fc12d4ac8e11a7 </openembedded-core/commit/?id=c57d1a561db563ed2f521bbac5fc12d4ac8e11a7>`
+-  Release Artefact: oecore-c57d1a561db563ed2f521bbac5fc12d4ac8e11a7
+-  sha: e8cdd870492017be7e7b74b8c2fb73ae6771b2d2125b2aa1f0e65d0689f96af8
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.2/oecore-c57d1a561db563ed2f521bbac5fc12d4ac8e11a7.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.2/oecore-c57d1a561db563ed2f521bbac5fc12d4ac8e11a7.tar.bz2
+
+meta-mingw
+
+-  Repository Location: :yocto_git:`/meta-mingw`
+-  Branch: :yocto_git:`mickledore </meta-mingw/log/?h=mickledore>`
+-  Tag:  :yocto_git:`yocto-4.2 </meta-mingw/log/?h=yocto-4.2>`
+-  Git Revision: :yocto_git:`250617ffa524c082b848487359b9d045703d59c2 </meta-mingw/commit/?id=250617ffa524c082b848487359b9d045703d59c2>`
+-  Release Artefact: meta-mingw-250617ffa524c082b848487359b9d045703d59c2
+-  sha: 873a97dfd5ed6fb26e1f6a2ddc2c0c9d7a7b3c7f5018588e912294618775c323
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.2/meta-mingw-250617ffa524c082b848487359b9d045703d59c2.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.2/meta-mingw-250617ffa524c082b848487359b9d045703d59c2.tar.bz2
+
+bitbake
+
+-  Repository Location: :oe_git:`/bitbake`
+-  Branch: :oe_git:`2.4 </bitbake/log/?h=2.4>`
+-  Tag:  :oe_git:`yocto-4.2 </bitbake/log/?h=yocto-4.2>`
+-  Git Revision: :oe_git:`d97d62e2cbe4bae17f0886f3b4759e8f9ba6d38c </bitbake/commit/?id=d97d62e2cbe4bae17f0886f3b4759e8f9ba6d38c>`
+-  Release Artefact: bitbake-d97d62e2cbe4bae17f0886f3b4759e8f9ba6d38c
+-  sha: 5edcb97cb545011226b778355bb840ebcc790552d4a885a0d83178153697ba7a
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.2/bitbake-d97d62e2cbe4bae17f0886f3b4759e8f9ba6d38c.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.2/bitbake-d97d62e2cbe4bae17f0886f3b4759e8f9ba6d38c.tar.bz2
+
+yocto-docs
+
+-  Repository Location: :yocto_git:`/yocto-docs`
+-  Branch: :yocto_git:`mickledore </yocto-docs/log/?h=mickledore>`
+-  Tag: :yocto_git:`yocto-4.2 </yocto-docs/log/?h=yocto-4.2>`
+-  Git Revision: :yocto_git:`4d6807e34adf5d92d9b6e5852736443a867c78fa </yocto-docs/commit/?id=4d6807e34adf5d92d9b6e5852736443a867c78fa>`
+

documentation/overview-manual/concepts.rst

@@ -69,12 +69,10 @@ type the following::
 
    $ bitbake matchbox-desktop
 
-Several different
-versions of ``matchbox-desktop`` might exist. BitBake chooses the one
-selected by the distribution configuration. You can get more details
-about how BitBake chooses between different target versions and
-providers in the
-":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-execution:preferences`" section
+Several different versions of ``matchbox-desktop`` might exist. BitBake chooses
+the one selected by the distribution configuration. You can get more details
+about how BitBake chooses between different target versions and providers in the
+":ref:`bitbake-user-manual/bitbake-user-manual-execution:preferences`" section
 of the BitBake User Manual.
 
 BitBake also tries to execute any dependent tasks first. So for example,
@@ -570,13 +568,11 @@ Source Control Managers (Optional)
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Another place from which the build system can get source files is with
-:ref:`bitbake:bitbake-user-manual/bitbake-user-manual-fetching:fetchers` employing various Source
-Control Managers (SCMs) such as Git or Subversion. In such cases, a
-repository is cloned or checked out. The
-:ref:`ref-tasks-fetch` task inside
-BitBake uses the :term:`SRC_URI`
-variable and the argument's prefix to determine the correct fetcher
-module.
+:ref:`bitbake-user-manual/bitbake-user-manual-fetching:fetchers` employing
+various Source Control Managers (SCMs) such as Git or Subversion. In such
+cases, a repository is cloned or checked out. The :ref:`ref-tasks-fetch` task
+inside BitBake uses the :term:`SRC_URI` variable and the argument's prefix to
+determine the correct fetcher module.
 
 .. note::
 
@@ -642,9 +638,8 @@ package files are kept:
    type sub-folder. Given RPM, IPK, or DEB packaging and tarball
    creation, the
    :term:`DEPLOY_DIR_RPM`,
-   :term:`DEPLOY_DIR_IPK`,
-   :term:`DEPLOY_DIR_DEB`, or
-   :term:`DEPLOY_DIR_TAR`,
+   :term:`DEPLOY_DIR_IPK`, or
+   :term:`DEPLOY_DIR_DEB`
    variables are used, respectively.
 
 -  :term:`PACKAGE_ARCH`: Defines
@@ -657,9 +652,8 @@ tasks to generate packages and place them into the package holding area
 (e.g. ``do_package_write_ipk`` for IPK packages). See the
 ":ref:`ref-tasks-package_write_deb`",
 ":ref:`ref-tasks-package_write_ipk`",
-":ref:`ref-tasks-package_write_rpm`",
 and
-":ref:`ref-tasks-package_write_tar`"
+":ref:`ref-tasks-package_write_rpm`"
 sections in the Yocto Project Reference Manual for additional
 information. As an example, consider a scenario where an IPK packaging
 manager is being used and there is package architecture support for both
@@ -680,7 +674,7 @@ closer look at each of those areas.
 .. note::
 
    Documentation for the BitBake tool is available separately. See the
-   BitBake User Manual
+   :doc:`BitBake User Manual <bitbake:index>`
    for reference material on BitBake.
 
 Source Fetching
@@ -1145,7 +1139,7 @@ Since :term:`STAMPS_DIR` is usually a subdirectory of :term:`TMPDIR`, removing
 properly be rerun to repopulate :term:`TMPDIR`.
 
 If you want some task to always be considered "out of date", you can
-mark it with the :ref:`nostamp <bitbake:bitbake-user-manual/bitbake-user-manual-metadata:variable flags>`
+mark it with the :ref:`nostamp <bitbake-user-manual/bitbake-user-manual-metadata:variable flags>`
 varflag. If some other task depends on such a task, then that task will
 also always be considered out of date, which might not be what you want.
 
@@ -1811,19 +1805,18 @@ The following list explains the previous example:
       }
       addtask do_deploy_setscene
 
-  ``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 :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.
+   ``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 :ref:`ref-tasks-deploy` task runs. For more
+   information, see the ":ref:`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 :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.
+-  The ``do_deploy[dirs] = "${DEPLOYDIR} ${B}"`` line creates ``${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-user-manual/bitbake-user-manual-metadata:variable flags`"
+   section in the BitBake User Manual.
 
    .. note::
 
@@ -1835,12 +1828,10 @@ The following list explains the previous example:
               do_package[sstate-plaindirs] = "${PKGD} ${PKGDEST}"
 
 
--  The ``do_deploy[stamp-extra-info] = "${MACHINE_ARCH}"`` line appends
-   extra metadata to the :ref:`stamp
-   file <overview-manual/concepts:stamp files and the rerunning of tasks>`. In
-   this case, the metadata makes the task specific to a machine's architecture.
-   See
-   ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-execution:the task list`"
+-  The ``do_deploy[stamp-extra-info] = "${MACHINE_ARCH}"`` line appends extra
+   metadata to the :ref:`stamp file <overview-manual/concepts:stamp files and the rerunning of tasks>`.
+   In this case, the metadata makes the task specific to a machine's architecture.
+   See the ":ref:`bitbake-user-manual/bitbake-user-manual-execution:the task list`"
    section in the BitBake User Manual for more information on the
    ``stamp-extra-info`` flag.
 
@@ -1950,7 +1941,7 @@ Thanks to this, the depending tasks will keep a previously recorded
 task hash, and BitBake will be able to retrieve their output from
 the Shared State cache, instead of re-executing them. Similarly, the
 output of further downstream tasks can also be retrieved from Shared
-Shate.
+State.
 
 If the output hash is unknown, a new entry will be created on the Hash
 Equivalence server, matching the task hash to that output.
@@ -1972,6 +1963,15 @@ task output from the Shared State cache.
    the stability of the task's output hash. Therefore, the effectiveness
    of Hash Equivalence strongly depends on it.
 
+   Recipes that are not reproducible may have undesired behavior if hash
+   equivalence is enabled, since the non-reproducible diverging output maybe be
+   remapped to an older sstate object in the cache by the server. If a recipe
+   is non-reproducible in trivial ways, such as different timestamps, this is
+   likely not a problem. However recipes that have more dramatic changes (such
+   as completely different file names) will likely outright fail since the
+   downstream sstate objects are not actually equivalent to what was just
+   built.
+
 This applies to multiple scenarios:
 
 -  A "trivial" change to a recipe that doesn't impact its generated output,
@@ -2122,12 +2122,12 @@ dependencies, you must manually declare the dependencies.
    :term:`ALLOW_EMPTY` variable
    for more information.
 
-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
-shared-library/module-to-package mapping information will be available
-when needed as long as :term:`DEPENDS` has been correctly set.
+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-user-manual/bitbake-user-manual-metadata:variable flags>`\ ``]``
+declaration, which guarantees that the required shared-library /
+module-to-package mapping information will be available when needed as long as
+:term:`DEPENDS` has been correctly set.
 
 Fakeroot and Pseudo
 ===================