linux/cve-exclusion: Execute the script after changing to the new data source

Execute new script generate-cve-exclusions.py
./generate-cve-exclusions.py ~/cvelistV5/ 6.12.19 > cve-exclusion_6.12.inc

After using the database from CVEproject, some old
CVEs did not have correct metadata, therefore moving missing ones
from old cve-exclusions_6.12.inc into cve-exclusion.inc

Comparing output from cve_check before and after, two CVEs are removed:
CVE-2023-52904 and CVE-2024-38381

(From OE-Core rev: 02a8d5d255397e85d32879b178dd6dd559a34a05)

Signed-off-by: Daniel Turull <daniel.turull@ericsson.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

bitbake/bin/bitbake

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

bitbake/bin/bitbake-getvar

@@ -10,7 +10,6 @@ import io
 import os
 import sys
 import warnings
-import logging
 warnings.simplefilter("default")
 
 bindir = os.path.dirname(__file__)
@@ -39,10 +38,6 @@ if __name__ == "__main__":
             sys.exit("--flag only makes sense with --value")
 
     quiet = args.quiet or args.value
-    if quiet:
-        logger = logging.getLogger("BitBake")
-        logger.setLevel(logging.WARNING)
-
     with bb.tinfoil.Tinfoil(tracking=True, setup_logging=not quiet) as tinfoil:
         if args.recipe:
             tinfoil.prepare(quiet=3 if quiet else 2)

bitbake/bin/bitbake-server

@@ -30,7 +30,7 @@ logfile = sys.argv[4]
 lockname = sys.argv[5]
 sockname = sys.argv[6]
 timeout = float(sys.argv[7])
-profile = sys.argv[8]
+profile = bool(int(sys.argv[8]))
 xmlrpcinterface = (sys.argv[9], int(sys.argv[10]))
 if xmlrpcinterface[0] == "None":
     xmlrpcinterface = (None, xmlrpcinterface[1])

bitbake/bin/bitbake-worker

@@ -182,8 +182,11 @@ def fork_off_task(cfg, data, databuilder, workerdata, extraconfigdata, runtask):
     elif workerdata["umask"]:
         umask = workerdata["umask"]
     if umask:
-        # Convert to a python numeric value as it could be a string
-        umask = bb.utils.to_filemode(umask)
+        # umask might come in as a number or text string..
+        try:
+             umask = int(umask, 8)
+        except TypeError:
+             pass
 
     dry_run = cfg.dry_run or runtask['dry_run']
 

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

@@ -39,10 +39,10 @@ variable and then calls the ``download`` method to download the files.
 
 The instantiation of the fetch class is usually followed by::
 
-   rootdir = l.getVar('UNPACKDIR')
+   rootdir = l.getVar('WORKDIR')
    fetcher.unpack(rootdir)
 
-This code unpacks the downloaded files to the specified by ``UNPACKDIR``.
+This code unpacks the downloaded files to the specified by ``WORKDIR``.
 
 .. note::
 
@@ -51,7 +51,7 @@ This code unpacks the downloaded files to the specified by ``UNPACKDIR``.
    examine the OpenEmbedded class file ``base.bbclass``
    .
 
-The :term:`SRC_URI` and ``UNPACKDIR`` variables are not hardcoded into the
+The :term:`SRC_URI` and ``WORKDIR`` variables are not hardcoded into the
 fetcher, since those fetcher methods can be (and are) called with
 different variable names. In OpenEmbedded for example, the shared state
 (sstate) code uses the fetch module to fetch the sstate files.
@@ -436,15 +436,13 @@ This fetcher supports the following parameters:
    "nobranch" is set to "1", this is a mandatory parameter. The number of
    branch parameters must match the number of name parameters.
 
--  *"rev":* The revision to use for the checkout. If :term:`SRCREV` is also set,
-   this parameter must match its value.
+-  *"rev":* The revision to use for the checkout. The default is
+   "master".
 
--  *"tag":* Specifies a tag to use when fetching. To correctly resolve
-   tags, BitBake must access the network. If a ``rev`` parameter or
-   :term:`SRCREV` is also specified, network access is not necessary to resolve
-   the tag and instead, it is verified that they both resolve to the same commit
-   SHA at unpack time.  The ``tag`` parameter is optional, but strongly
-   recommended if the checked out revision is a tag.
+-  *"tag":* Specifies a tag to use for the checkout. To correctly
+   resolve tags, BitBake must access the network. For that reason, tags
+   are often not used. As far as Git is concerned, the "tag" parameter
+   behaves effectively the same as the "rev" parameter.
 
 -  *"subpath":* Limits the checkout to a specific subpath of the tree.
    By default, the whole tree is checked out.
@@ -463,6 +461,13 @@ Here are some example URLs::
    SRC_URI = "git://github.com/asciidoc/asciidoc-py;protocol=https;branch=main"
    SRC_URI = "git://git@gitlab.freedesktop.org/mesa/mesa.git;branch=main;protocol=ssh;..."
 
+.. note::
+
+   When using ``git`` as the fetcher of the main source code of your software,
+   ``S`` should be set accordingly::
+
+       S = "${WORKDIR}/git"
+
 .. note::
 
    Specifying passwords directly in ``git://`` urls is not supported.
@@ -593,7 +598,7 @@ and port, username, and password, and fetches the Head Revision::
    SRC_URI = "p4://example-depot/main/source/..."
    SRCREV = "${AUTOREV}"
    PV = "p4-${SRCPV}"
-   S = "${UNPACKDIR}/p4"
+   S = "${WORKDIR}/p4"
 
 Here is an example that specifies the server URL and port, username, and
 password, and fetches a Revision based on a Label::
@@ -602,15 +607,15 @@ password, and fetches a Revision based on a Label::
    SRC_URI = "p4://user:passwd@example-depot/main/source/..."
    SRCREV = "release-1.0"
    PV = "p4-${SRCPV}"
-   S = "${UNPACKDIR}/p4"
+   S = "${WORKDIR}/p4"
 
 .. note::
 
-   You should always set S to "${UNPACKDIR}/p4" in your recipe.
+   You should always set S to "${WORKDIR}/p4" in your recipe.
 
 By default, the fetcher strips the depot location from the local file paths. In
 the above example, the content of ``example-depot/main/source/`` will be placed
-in ``${UNPACKDIR}/p4``.  For situations where preserving parts of the remote depot
+in ``${WORKDIR}/p4``.  For situations where preserving parts of the remote depot
 paths locally is desirable, the fetcher supports two parameters:
 
 - *"module":*
@@ -681,9 +686,9 @@ Such functionality is set by the variable:
    delegate access to resources, if this variable is set, the Az Fetcher will
    use it when fetching artifacts from the cloud.
 
-You can specify the AZ_SAS variable prefixed with a ? as shown below::
+You can specify the AZ_SAS variable as shown below::
 
-   AZ_SAS = "?se=2021-01-01&sp=r&sv=2018-11-09&sr=c&skoid=<skoid>&sig=<signature>"
+   AZ_SAS = "se=2021-01-01&sp=r&sv=2018-11-09&sr=c&skoid=<skoid>&sig=<signature>"
 
 Here is an example URL::
 

bitbake/doc/bitbake-user-manual/bitbake-user-manual-library-functions.rst

@@ -1,59 +0,0 @@
-.. SPDX-License-Identifier: CC-BY-2.5
-
-=================
-Library Functions
-=================
-
-|
-
-This chapter lists common library functions available under the ``lib/``
-directory in BitBake.
-
-These functions can be used in recipes or configuration files with
-:ref:`inline-Python <bitbake-user-manual/bitbake-user-manual-metadata:Inline
-Python Variable Expansion>` or :ref:`Python
-<bitbake-user-manual/bitbake-user-manual-metadata:BitBake-Style Python
-Functions>` functions.
-
-Logging utilities
-=================
-
-Different logging utilities can be used from Python code in recipes or
-configuration files.
-
-The strings passed below can be formatted with ``str.format()``, for example::
-
-   bb.warn("Houston, we have a %s", "bit of a problem")
-
-Formatted string can also be used directly::
-
-   bb.error("%s, we have a %s" % ("Houston", "big problem"))
-
-Python f-strings may also be used::
-
-   h = "Houston"
-   bb.fatal(f"{h}, we have a critical problem")
-
-.. automodule:: bb
-   :members:
-      debug,
-      error,
-      erroronce,
-      fatal,
-      note,
-      plain,
-      verbnote,
-      warn,
-      warnonce,
-
-``bb.utils``
-============
-
-.. automodule:: bb.utils
-   :members:
-   :exclude-members:
-      LogCatcher,
-      PrCtlError,
-      VersionStringException,
-      better_compile,
-      better_exec,

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

@@ -998,9 +998,9 @@ This directive allows fine-tuning local configurations with configuration
 snippets contained in layers in a structured, controlled way. Typically it would
 go into ``bitbake.conf``, for example::
 
-   addfragments conf/fragments OE_FRAGMENTS OE_FRAGMENTS_METADATA_VARS OE_BUILTIN_FRAGMENTS
+   addfragments conf/fragments OE_FRAGMENTS OE_FRAGMENTS_METADATA_VARS
 
-``addfragments`` takes four parameters:
+``addfragments`` takes three parameters:
 
 -  path prefix for fragment files inside the layer file tree that bitbake
    uses to construct full paths to the fragment files
@@ -1011,8 +1011,6 @@ go into ``bitbake.conf``, for example::
 -  name of variable that contains a list of variable names containing
    fragment-specific metadata (such as descriptions)
 
--  name of variable that contains definitions for built-in fragments
-
 This allows listing enabled configuration fragments in ``OE_FRAGMENTS``
 variable like this::
 
@@ -1037,19 +1035,6 @@ The implementation will add a flag containing the fragment name to each of those
 when parsing fragments, so that the variables are namespaced by fragment name, and do not override
 each other when several fragments are enabled.
 
-The variable containing a built-in fragment definitions could look like this::
-
-   OE_BUILTIN_FRAGMENTS = "someprefix:SOMEVARIABLE anotherprefix:ANOTHERVARIABLE"
-
-and then if 'someprefix/somevalue' is added to the variable that holds the list
-of enabled fragments:
-
-  OE_FRAGMENTS = "... someprefix/somevalue"
-
-bitbake will treat that as direct value assignment in its configuration::
-
-  SOMEVARIABLE = "somevalue"
-
 Functions
 =========
 
@@ -1420,8 +1405,8 @@ the task and other tasks. Here is an example that shows how to define a
 task and declare some dependencies::
 
    python do_printdate () {
-       import datetime
-       bb.plain('Date: %s' % (datetime.date.today()))
+       import time
+       print time.strftime('%Y%m%d', time.gmtime())
    }
    addtask printdate after do_fetch before do_build
 
@@ -2089,8 +2074,11 @@ access. Here is a list of available operations:
 Other Functions
 ---------------
 
-Other functions are documented in the
-:doc:`/bitbake-user-manual/bitbake-user-manual-library-functions` document.
+You can find many other functions that can be called from Python by
+looking at the source code of the ``bb`` module, which is in
+``bitbake/lib/bb``. For example, ``bitbake/lib/bb/utils.py`` includes
+the commonly used functions ``bb.utils.contains()`` and
+``bb.utils.mkdirhier()``, which come with docstrings.
 
 Extending Python Library Code
 -----------------------------

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

@@ -310,11 +310,6 @@ overview of their function and contents.
 
       For example usage, see :term:`BB_GIT_SHALLOW`.
 
-   :term:`BB_GIT_DEFAULT_DESTSUFFIX`
-      The default destination directory where the Git fetcher unpacks the
-      source code. If this variable is not set, the source code is unpacked in a
-      directory named "git".
-
    :term:`BB_GIT_SHALLOW`
       Setting this variable to "1" enables the support for fetching, using and
       generating mirror tarballs of `shallow git repositories <https://riptutorial.com/git/example/4584/shallow-clone>`_.
@@ -538,28 +533,11 @@ overview of their function and contents.
       version 4.20 expose under ``/proc/pressure``. The threshold represents
       the difference in "total" pressure from the previous second. The
       minimum value is 1.0 (extremely slow builds) and the maximum is
-      1000000 (a pressure value unlikely to ever be reached). See
-      https://docs.kernel.org/accounting/psi.html for more information.
+      1000000 (a pressure value unlikely to ever be reached).
 
-      A default value to limit the CPU pressure to be set in ``conf/local.conf``
-      could be::
+      This threshold can be set in ``conf/local.conf`` as::
 
-         BB_PRESSURE_MAX_CPU = "15000"
-
-      Multiple values should be tested on the build host to determine what suits
-      best, depending on the need for performances versus load average during
-      the build.
-
-      .. note::
-
-         You may see numerous messages printed by BitBake in the case the
-         :term:`BB_PRESSURE_MAX_CPU` is too low:
-
-            Pressure status changed to CPU: True, IO: False, Mem: False (CPU: 1105.9/2.0, IO: 0.0/2.0, Mem: 0.0/2.0) - using 1/64 bitbake threads
-
-         This means that the :term:`BB_PRESSURE_MAX_CPU` should be increased to
-         a reasonable value for limiting the CPU pressure on the system.
-         Monitor the varying value after ``IO:`` above to set a sensible value.
+         BB_PRESSURE_MAX_CPU = "500"
 
    :term:`BB_PRESSURE_MAX_IO`
       Specifies a maximum I/O pressure threshold, above which BitBake's
@@ -571,34 +549,14 @@ overview of their function and contents.
       version 4.20 expose under ``/proc/pressure``. The threshold represents
       the difference in "total" pressure from the previous second. The
       minimum value is 1.0 (extremely slow builds) and the maximum is
-      1000000 (a pressure value unlikely to ever be reached). See
-      https://docs.kernel.org/accounting/psi.html for more information.
+      1000000 (a pressure value unlikely to ever be reached).
 
       At this point in time, experiments show that IO pressure tends to
       be short-lived and regulating just the CPU with
       :term:`BB_PRESSURE_MAX_CPU` can help to reduce it.
 
-      A default value to limit the IO pressure to be set in ``conf/local.conf``
-      could be::
-
-         BB_PRESSURE_MAX_IO = "15000"
-
-      Multiple values should be tested on the build host to determine what suits
-      best, depending on the need for performances versus I/O usage during the
-      build.
-
-      .. note::
-
-         You may see numerous messages printed by BitBake in the case the
-         :term:`BB_PRESSURE_MAX_IO` is too low::
-
-            Pressure status changed to CPU: None, IO: True, Mem: False (CPU: 2236.0/None, IO: 153.6/2.0, Mem: 0.0/2.0) - using 19/64 bitbake threads
-
-         This means that the :term:`BB_PRESSURE_MAX_IO` should be increased to
-         a reasonable value for limiting the I/O pressure on the system.
-         Monitor the varying value after ``IO:`` above to set a sensible value.
-
    :term:`BB_PRESSURE_MAX_MEMORY`
+
       Specifies a maximum memory pressure threshold, above which BitBake's
       scheduler will not start new tasks (providing there is at least
       one active task). If no value is set, memory pressure is not
@@ -608,8 +566,7 @@ overview of their function and contents.
       version 4.20 expose under ``/proc/pressure``. The threshold represents
       the difference in "total" pressure from the previous second. The
       minimum value is 1.0 (extremely slow builds) and the maximum is
-      1000000 (a pressure value unlikely to ever be reached). See
-      https://docs.kernel.org/accounting/psi.html for more information.
+      1000000 (a pressure value unlikely to ever be reached).
 
       Memory pressure is experienced when time is spent swapping,
       refaulting pages from the page cache or performing direct reclaim.
@@ -617,26 +574,6 @@ overview of their function and contents.
       might be useful as a last resort to prevent OOM errors if they are
       occurring during builds.
 
-      A default value to limit the memory pressure to be set in
-      ``conf/local.conf`` could be::
-
-         BB_PRESSURE_MAX_MEMORY = "15000"
-
-      Multiple values should be tested on the build host to determine what suits
-      best, depending on the need for performances versus memory consumption
-      during the build.
-
-      .. note::
-
-         You may see numerous messages printed by BitBake in the case the
-         :term:`BB_PRESSURE_MAX_MEMORY` is too low::
-
-            Pressure status changed to CPU: None, IO: False, Mem: True (CPU: 29.5/None, IO: 0.0/2.0, Mem: 2553.3/2.0) - using 17/64 bitbake threads
-
-         This means that the :term:`BB_PRESSURE_MAX_MEMORY` should be increased to
-         a reasonable value for limiting the memory pressure on the system.
-         Monitor the varying value after ``Mem:`` above to set a sensible value.
-
    :term:`BB_RUNFMT`
       Specifies the name of the executable script files (i.e. run files)
       saved into ``${``\ :term:`T`\ ``}``. By default, the

bitbake/doc/conf.py

@@ -17,8 +17,6 @@
 import sys
 import datetime
 
-from pathlib import Path
-
 current_version = "dev"
 
 # String used in sidebar
@@ -49,7 +47,6 @@ extlinks = {
 extensions = [
     'sphinx.ext.autosectionlabel',
     'sphinx.ext.extlinks',
-    'sphinx.ext.autodoc',
 ]
 autosectionlabel_prefix_document = True
 
@@ -102,7 +99,3 @@ html_last_updated_fmt = '%b %d, %Y'
 
 # Remove the trailing 'dot' in section numbers
 html_secnumber_suffix = " "
-
-# autoconf needs the modules available to auto-generate documentation from the
-# code
-sys.path.insert(0, str(Path('..', 'lib').resolve()))

bitbake/doc/index.rst

@@ -16,7 +16,6 @@ BitBake User Manual
    bitbake-user-manual/bitbake-user-manual-ref-variables-context
    bitbake-user-manual/bitbake-user-manual-fetching
    bitbake-user-manual/bitbake-user-manual-ref-variables
-   bitbake-user-manual/bitbake-user-manual-library-functions
    bitbake-user-manual/bitbake-user-manual-hello
 
 .. toctree::

bitbake/doc/releases.rst

@@ -4,11 +4,11 @@
 BitBake Supported Release Manuals
 =================================
 
-******************************
-Release Series 5.2 (walnascar)
-******************************
+****************************
+Release Series 5.1 (styhead)
+****************************
 
-- :yocto_docs:`BitBake 2.12 User Manual </bitbake/2.12/>`
+- :yocto_docs:`BitBake 2.10 User Manual </bitbake/2.10/>`
 
 *******************************
 Release Series 5.0 (scarthgap)
@@ -26,12 +26,6 @@ Release Series 4.0 (kirkstone)
 BitBake Outdated Release Manuals
 ================================
 
-****************************
-Release Series 5.1 (styhead)
-****************************
-
-- :yocto_docs:`BitBake 2.10 User Manual </bitbake/2.10/>`
-
 *******************************
 Release Series 4.3 (nanbield)
 *******************************

bitbake/lib/bb/__init__.py

@@ -9,7 +9,7 @@
 # SPDX-License-Identifier: GPL-2.0-only
 #
 
-__version__ = "2.15.1"
+__version__ = "2.12.0"
 
 import sys
 if sys.version_info < (3, 9, 0):
@@ -37,34 +37,6 @@ class BBHandledException(Exception):
 import os
 import logging
 from collections import namedtuple
-import multiprocessing as mp
-
-# Python 3.14 changes the default multiprocessing context from "fork" to
-# "forkserver". However, bitbake heavily relies on "fork" behavior to
-# efficiently pass data to the child processes. Places that need this should do:
-#   from bb import multiprocessing
-# in place of
-#   import multiprocessing
-
-class MultiprocessingContext(object):
-    """
-    Multiprocessing proxy object that uses the "fork" context for a property if
-    available, otherwise goes to the main multiprocessing module. This allows
-    it to be a drop-in replacement for the multiprocessing module, but use the
-    fork context
-    """
-    def __init__(self):
-        super().__setattr__("_ctx", mp.get_context("fork"))
-
-    def __getattr__(self, name):
-        if hasattr(self._ctx, name):
-            return getattr(self._ctx, name)
-        return getattr(mp, name)
-
-    def __setattr__(self, name, value):
-        raise AttributeError(f"Unable to set attribute {name}")
-
-multiprocessing = MultiprocessingContext()
 
 
 class NullHandler(logging.Handler):
@@ -157,25 +129,9 @@ sys.modules['bb.fetch'] = sys.modules['bb.fetch2']
 
 # Messaging convenience functions
 def plain(*args):
-    """
-    Prints a message at "plain" level (higher level than a ``bb.note()``).
-
-    Arguments:
-
-    -  ``args``: one or more strings to print.
-    """
     mainlogger.plain(''.join(args))
 
 def debug(lvl, *args):
-    """
-    Prints a debug message.
-
-    Arguments:
-
-    -  ``lvl``: debug level. Higher value increases the debug level
-       (determined by ``bitbake -D``).
-    -  ``args``: one or more strings to print.
-    """
     if isinstance(lvl, str):
         mainlogger.warning("Passed invalid debug level '%s' to bb.debug", lvl)
         args = (lvl,) + args
@@ -183,81 +139,33 @@ def debug(lvl, *args):
     mainlogger.bbdebug(lvl, ''.join(args))
 
 def note(*args):
-    """
-    Prints a message at "note" level.
-
-    Arguments:
-
-    -  ``args``: one or more strings to print.
-    """
     mainlogger.info(''.join(args))
 
+#
+# A higher prioity note which will show on the console but isn't a warning
+#
+# Something is happening the user should be aware of but they probably did
+# something to make it happen
+#
 def verbnote(*args):
-    """
-    A higher priority note which will show on the console but isn't a warning.
-
-    Use in contexts when something is happening the user should be aware of but
-    they probably did something to make it happen.
-
-    Arguments:
-
-    -  ``args``: one or more strings to print.
-    """
     mainlogger.verbnote(''.join(args))
 
 #
 # Warnings - things the user likely needs to pay attention to and fix
 #
 def warn(*args):
-    """
-    Prints a warning message.
-
-    Arguments:
-
-    -  ``args``: one or more strings to print.
-    """
     mainlogger.warning(''.join(args))
 
 def warnonce(*args):
-    """
-    Prints a warning message like ``bb.warn()``, but only prints the message
-    once.
-
-    Arguments:
-
-    -  ``args``: one or more strings to print.
-    """
     mainlogger.warnonce(''.join(args))
 
 def error(*args, **kwargs):
-    """
-    Prints an error message.
-
-    Arguments:
-
-    -  ``args``: one or more strings to print.
-    """
     mainlogger.error(''.join(args), extra=kwargs)
 
 def erroronce(*args):
-    """
-    Prints an error message like ``bb.error()``, but only prints the message
-    once.
-
-    Arguments:
-
-    -  ``args``: one or more strings to print.
-    """
     mainlogger.erroronce(''.join(args))
 
 def fatal(*args, **kwargs):
-    """
-    Prints an error message and stops the BitBake execution.
-
-    Arguments:
-
-    -  ``args``: one or more strings to print.
-    """
     mainlogger.critical(''.join(args), extra=kwargs)
     raise BBHandledException()
 

bitbake/lib/bb/asyncrpc/serv.py

@@ -11,7 +11,7 @@ import os
 import signal
 import socket
 import sys
-from bb import multiprocessing
+import multiprocessing
 import logging
 from .connection import StreamConnection, WebsocketConnection
 from .exceptions import ClientError, ServerError, ConnectionClosedError, InvokeError
@@ -211,10 +211,7 @@ class UnixStreamServer(StreamServer):
         self.server.close()
 
     def cleanup(self):
-        try:
-            os.unlink(self.path)
-        except FileNotFoundError:
-            pass
+        os.unlink(self.path)
 
 
 class WebsocketsServer(object):

bitbake/lib/bb/codeparser.py

@@ -69,7 +69,7 @@ def add_module_functions(fn, functions, namespace):
         name = "%s.%s" % (namespace, f)
         parser = PythonParser(name, logger)
         try:
-            parser.parse_python(None, filename=fn, lineno=1, fixedhash=fixedhash+f, func=functions[f])
+            parser.parse_python(None, filename=fn, lineno=1, fixedhash=fixedhash+f)
             #bb.warn("Cached %s" % f)
         except KeyError:
             try:
@@ -87,7 +87,7 @@ def add_module_functions(fn, functions, namespace):
                 # Builtin
                 continue
             src = "".join(lines)
-            parser.parse_python(src, filename=fn, lineno=lineno, fixedhash=fixedhash+f, func=functions[f])
+            parser.parse_python(src, filename=fn, lineno=lineno, fixedhash=fixedhash+f)
             #bb.warn("Not cached %s" % f)
         execs = parser.execs.copy()
         # Expand internal module exec references
@@ -348,7 +348,7 @@ class PythonParser():
     # For the python module code it is expensive to have the function text so it is
     # uses a different fixedhash to cache against. We can take the hit on obtaining the
     # text if it isn't in the cache.
-    def parse_python(self, node, lineno=0, filename="<string>", fixedhash=None, func=None):
+    def parse_python(self, node, lineno=0, filename="<string>", fixedhash=None):
         if not fixedhash and (not node or not node.strip()):
             return
 
@@ -390,10 +390,6 @@ class PythonParser():
             if n.__class__.__name__ == "Call":
                 self.visit_Call(n)
 
-        if func is not None:
-            self.references |= getattr(func, "bb_vardeps", set())
-            self.references -= getattr(func, "bb_vardepsexclude", set())
-
         self.execs.update(self.var_execs)
         self.extra = None
         if fixedhash:

bitbake/lib/bb/cooker.py

@@ -12,7 +12,7 @@ import enum
 import sys, os, glob, os.path, re, time
 import itertools
 import logging
-from bb import multiprocessing
+import multiprocessing
 import threading
 from io import StringIO, UnsupportedOperation
 from contextlib import closing
@@ -26,7 +26,6 @@ import json
 import pickle
 import codecs
 import hashserv
-import ctypes
 
 logger      = logging.getLogger("BitBake")
 collectlog  = logging.getLogger("BitBake.Collection")
@@ -1999,9 +1998,8 @@ class ParsingFailure(Exception):
         Exception.__init__(self, realexception, recipe)
 
 class Parser(multiprocessing.Process):
-    def __init__(self, jobs, next_job_id, results, quit, profile):
+    def __init__(self, jobs, results, quit, profile):
         self.jobs = jobs
-        self.next_job_id = next_job_id
         self.results = results
         self.quit = quit
         multiprocessing.Process.__init__(self)
@@ -2011,7 +2009,6 @@ class Parser(multiprocessing.Process):
         self.queue_signals = False
         self.signal_received = []
         self.signal_threadlock = threading.Lock()
-        self.exit = False
 
     def catch_sig(self, signum, frame):
         if self.queue_signals:
@@ -2024,10 +2021,24 @@ class Parser(multiprocessing.Process):
             signal.signal(signal.SIGTERM, signal.SIG_DFL)
             os.kill(os.getpid(), signal.SIGTERM)
         elif signum == signal.SIGINT:
-            self.exit = True
+            signal.default_int_handler(signum, frame)
 
     def run(self):
-        bb.utils.profile_function("parsing" in self.profile, self.realrun, "profile-parse-%s.log" % multiprocessing.current_process().name, process=False)
+
+        if not self.profile:
+            self.realrun()
+            return
+
+        try:
+            import cProfile as profile
+        except:
+            import profile
+        prof = profile.Profile()
+        try:
+            profile.Profile.runcall(prof, self.realrun)
+        finally:
+            logfile = "profile-parse-%s.log" % multiprocessing.current_process().name
+            prof.dump_stats(logfile)
 
     def realrun(self):
         # Signal handling here is hard. We must not terminate any process or thread holding the write
@@ -2048,19 +2059,15 @@ class Parser(multiprocessing.Process):
         pending = []
         havejobs = True
         try:
-            while (havejobs or pending) and not self.exit:
+            while havejobs or pending:
                 if self.quit.is_set():
                     break
 
                 job = None
-                if havejobs:
-                    with self.next_job_id.get_lock():
-                        if self.next_job_id.value < len(self.jobs):
-                            job = self.jobs[self.next_job_id.value]
-                            self.next_job_id.value += 1
-                        else:
-                            havejobs = False
-
+                try:
+                    job = self.jobs.pop()
+                except IndexError:
+                    havejobs = False
                 if job:
                     result = self.parse(*job)
                     # Clear the siggen cache after parsing to control memory usage, its huge
@@ -2126,13 +2133,13 @@ class CookerParser(object):
 
         self.bb_caches = bb.cache.MulticonfigCache(self.cfgbuilder, self.cfghash, cooker.caches_array)
         self.fromcache = set()
-        self.willparse = []
+        self.willparse = set()
         for mc in self.cooker.multiconfigs:
             for filename in self.mcfilelist[mc]:
                 appends = self.cooker.collections[mc].get_file_appends(filename)
                 layername = self.cooker.collections[mc].calc_bbfile_priority(filename)[2]
                 if not self.bb_caches[mc].cacheValid(filename, appends):
-                    self.willparse.append((mc, self.bb_caches[mc], filename, appends, layername))
+                    self.willparse.add((mc, self.bb_caches[mc], filename, appends, layername))
                 else:
                     self.fromcache.add((mc, self.bb_caches[mc], filename, appends, layername))
 
@@ -2151,18 +2158,18 @@ class CookerParser(object):
     def start(self):
         self.results = self.load_cached()
         self.processes = []
-
         if self.toparse:
             bb.event.fire(bb.event.ParseStarted(self.toparse), self.cfgdata)
 
-            next_job_id = multiprocessing.Value(ctypes.c_int, 0)
             self.parser_quit = multiprocessing.Event()
             self.result_queue = multiprocessing.Queue()
 
-            # Have to pass in willparse at fork time so all parsing processes have the unpickleable data
-            # then access it by index from the parse queue.
+            def chunkify(lst,n):
+                return [lst[i::n] for i in range(n)]
+            self.jobs = chunkify(list(self.willparse), self.num_processes)
+
             for i in range(0, self.num_processes):
-                parser = Parser(self.willparse, next_job_id, self.result_queue, self.parser_quit, self.cooker.configuration.profile)
+                parser = Parser(self.jobs[i], self.result_queue, self.parser_quit, self.cooker.configuration.profile)
                 parser.start()
                 self.process_names.append(parser.name)
                 self.processes.append(parser)
@@ -2189,12 +2196,11 @@ class CookerParser(object):
 
         # Cleanup the queue before call process.join(), otherwise there might be
         # deadlocks.
-        def read_results():
-            while True:
-                try:
-                   self.result_queue.get(timeout=0.25)
-                except queue.Empty:
-                    break
+        while True:
+            try:
+               self.result_queue.get(timeout=0.25)
+            except queue.Empty:
+                break
 
         def sync_caches():
             for c in self.bb_caches.values():
@@ -2206,19 +2212,15 @@ class CookerParser(object):
 
         self.parser_quit.set()
 
-        read_results()
-
         for process in self.processes:
-            process.join(2)
+            process.join(0.5)
 
         for process in self.processes:
             if process.exitcode is None:
                 os.kill(process.pid, signal.SIGINT)
 
-        read_results()
-
         for process in self.processes:
-            process.join(2)
+            process.join(0.5)
 
         for process in self.processes:
             if process.exitcode is None:
@@ -2241,9 +2243,9 @@ class CookerParser(object):
                     profiles.append(logfile)
 
             if profiles:
-                fn_out = "profile-parse.log.report"
-                bb.utils.process_profilelog(profiles, fn_out=fn_out)
-                print("Processed parsing statistics saved to %s" % (fn_out))
+                pout = "profile-parse.log.processed"
+                bb.utils.process_profilelog(profiles, pout = pout)
+                print("Processed parsing statistics saved to %s" % (pout))
 
     def final_cleanup(self):
         if self.syncthread:
@@ -2275,7 +2277,7 @@ class CookerParser(object):
                 yield result
 
         if not (self.parsed >= self.toparse):
-            raise bb.parse.ParseError("Not all recipes parsed, parser thread killed/died? (%s %s of %s) Exiting." % (len(self.processes), self.parsed, self.toparse), None)
+            raise bb.parse.ParseError("Not all recipes parsed, parser thread killed/died? Exiting.", None)
 
 
     def parse_next(self):

bitbake/lib/bb/event.py

@@ -236,12 +236,9 @@ def fire(event, d):
         # If messages have been queued up, clear the queue
         global _uiready, ui_queue
         if _uiready and ui_queue:
-            with bb.utils.lock_timeout_nocheck(_thread_lock):
-                queue = ui_queue
-                ui_queue = []
-            for queue_event in queue:
+            for queue_event in ui_queue:
                 fire_ui_handlers(queue_event, d)
-
+            ui_queue = []
         fire_ui_handlers(event, d)
 
 def fire_from_worker(event, d):
@@ -434,16 +431,6 @@ class RecipeEvent(Event):
         self.fn = fn
         Event.__init__(self)
 
-class RecipePreDeferredInherits(RecipeEvent):
-    """
-    Called before deferred inherits are processed so code can snoop on class extensions for example
-    Limitations: It won't see inherits of inherited classes and the data is unexpanded
-    """
-    def __init__(self, fn, inherits):
-        self.fn = fn
-        self.inherits = inherits
-        Event.__init__(self)
-
 class RecipePreFinalise(RecipeEvent):
     """ Recipe Parsing Complete but not yet finalised"""
 

bitbake/lib/bb/fetch2/__init__.py

@@ -1092,10 +1092,6 @@ def try_mirror_url(fetch, origud, ud, ld, check = False):
         # If that tarball is a local file:// we need to provide a symlink to it
         dldir = ld.getVar("DL_DIR")
 
-        if bb.utils.to_boolean(ld.getVar("BB_FETCH_PREMIRRORONLY")):
-            ld = ld.createCopy()
-            ld.setVar("BB_NO_NETWORK", "1")
-
         if origud.mirrortarballs and os.path.basename(ud.localpath) in origud.mirrortarballs and os.path.basename(ud.localpath) != os.path.basename(origud.localpath):
             # Create donestamp in old format to avoid triggering a re-download
             if ud.donestamp:
@@ -1117,10 +1113,7 @@ def try_mirror_url(fetch, origud, ud, ld, check = False):
                     origud.method.build_mirror_data(origud, ld)
             return origud.localpath
         # Otherwise the result is a local file:// and we symlink to it
-        # This may also be a link to a shallow archive
-        # When using shallow mode, add a symlink to the original fullshallow
-        # path to ensure a valid symlink even in the `PREMIRRORS` case
-        origud.method.update_mirror_links(ud, origud)
+        ensure_symlink(ud.localpath, origud.localpath)
         update_stamp(origud, ld)
         return ud.localpath
 
@@ -1154,6 +1147,25 @@ def try_mirror_url(fetch, origud, ud, ld, check = False):
         if ud.lockfile and ud.lockfile != origud.lockfile:
             bb.utils.unlockfile(lf)
 
+
+def ensure_symlink(target, link_name):
+    if not os.path.exists(link_name):
+        dirname = os.path.dirname(link_name)
+        bb.utils.mkdirhier(dirname)
+        if os.path.islink(link_name):
+            # Broken symbolic link
+            os.unlink(link_name)
+
+        # In case this is executing without any file locks held (as is
+        # the case for file:// URLs), two tasks may end up here at the
+        # same time, in which case we do not want the second task to
+        # fail when the link has already been created by the first task.
+        try:
+            os.symlink(target, link_name)
+        except FileExistsError:
+            pass
+
+
 def try_mirrors(fetch, d, origud, mirrors, check = False):
     """
     Try to use a mirrored version of the sources.
@@ -1573,11 +1585,11 @@ class FetchMethod(object):
                 datafile = None
                 if output:
                     for line in output.decode().splitlines():
-                        if line.startswith('data.tar.') or line == 'data.tar':
+                        if line.startswith('data.tar.'):
                             datafile = line
                             break
                     else:
-                        raise UnpackError("Unable to unpack deb/ipk package - does not contain data.tar* file", urldata.url)
+                        raise UnpackError("Unable to unpack deb/ipk package - does not contain data.tar.* file", urldata.url)
                 else:
                     raise UnpackError("Unable to unpack deb/ipk package - could not list contents", urldata.url)
                 cmd = 'ar x %s %s && %s -p -f %s && rm %s' % (file, datafile, tar_cmd, datafile, datafile)
@@ -1639,28 +1651,6 @@ class FetchMethod(object):
         """
         bb.utils.remove(urldata.localpath)
 
-    def ensure_symlink(self, target, link_name):
-        if not os.path.exists(link_name):
-            dirname = os.path.dirname(link_name)
-            bb.utils.mkdirhier(dirname)
-            if os.path.islink(link_name):
-                # Broken symbolic link
-                os.unlink(link_name)
-
-            # In case this is executing without any file locks held (as is
-            # the case for file:// URLs), two tasks may end up here at the
-            # same time, in which case we do not want the second task to
-            # fail when the link has already been created by the first task.
-            try:
-                os.symlink(target, link_name)
-            except FileExistsError:
-                pass
-
-    def update_mirror_links(self, ud, origud):
-        # For local file:// results, create a symlink to them
-        # This may also be a link to a shallow archive
-        self.ensure_symlink(ud.localpath, origud.localpath)
-
     def try_premirror(self, urldata, d):
         """
         Should premirrors be used?

bitbake/lib/bb/fetch2/az.py

@@ -36,8 +36,6 @@ class Az(Wget):
 
         az_sas = d.getVar('AZ_SAS')
         if az_sas and az_sas not in ud.url:
-            if not az_sas.startswith('?'):
-                raise FetchError("When using AZ_SAS, it must start with a '?' character to mark the start of the query-parameters.")
             ud.url += az_sas
 
         return Wget.checkstatus(self, fetch, ud, d, try_again)
@@ -64,8 +62,6 @@ class Az(Wget):
         az_sas = d.getVar('AZ_SAS')
 
         if az_sas:
-            if not az_sas.startswith('?'):
-                raise FetchError("When using AZ_SAS, it must start with a '?' character to mark the start of the query-parameters.")
             azuri = '%s%s%s%s' % ('https://', ud.host, ud.path, az_sas)
         else:
             azuri = '%s%s%s' % ('https://', ud.host, ud.path)

bitbake/lib/bb/fetch2/git.py

@@ -182,7 +182,7 @@ class Git(FetchMethod):
         ud.bareclone = ud.parm.get("bareclone","0") == "1"
         if ud.bareclone:
             ud.nocheckout = 1
-
+  
         ud.unresolvedrev = ""
         ud.branch = ud.parm.get("branch", "")
         if not ud.branch and not ud.nobranch:
@@ -199,8 +199,6 @@ class Git(FetchMethod):
         ud.shallow_skip_fast = False
         ud.shallow = d.getVar("BB_GIT_SHALLOW") == "1"
         ud.shallow_extra_refs = (d.getVar("BB_GIT_SHALLOW_EXTRA_REFS") or "").split()
-        if 'tag' in ud.parm:
-            ud.shallow_extra_refs.append("refs/tags/" + ud.parm['tag'])
 
         depth_default = d.getVar("BB_GIT_SHALLOW_DEPTH")
         if depth_default is not None:
@@ -326,13 +324,10 @@ class Git(FetchMethod):
         return False
 
     def lfs_need_update(self, ud, d):
-        if not self._need_lfs(ud):
-            return False
-
         if self.clonedir_need_update(ud, d):
             return True
 
-        if not self._lfs_objects_downloaded(ud, d, ud.clonedir):
+        if not self._lfs_objects_downloaded(ud, d, ud.name, ud.clonedir):
             return True
         return False
 
@@ -350,13 +345,6 @@ class Git(FetchMethod):
     def tarball_need_update(self, ud):
         return ud.write_tarballs and not os.path.exists(ud.fullmirror)
 
-    def update_mirror_links(self, ud, origud):
-        super().update_mirror_links(ud, origud)
-        # When using shallow mode, add a symlink to the original fullshallow
-        # path to ensure a valid symlink even in the `PREMIRRORS` case
-        if ud.shallow and not os.path.exists(origud.fullshallow):
-            self.ensure_symlink(ud.localpath, origud.fullshallow)
-
     def try_premirror(self, ud, d):
         # If we don't do this, updating an existing checkout with only premirrors
         # is not possible
@@ -491,14 +479,35 @@ class Git(FetchMethod):
                 raise bb.fetch2.FetchError("Unable to find revision %s even from upstream" % missing_rev)
 
         if self.lfs_need_update(ud, d):
-            self.lfs_fetch(ud, d, ud.clonedir, ud.revision)
+            # Unpack temporary working copy, use it to run 'git checkout' to force pre-fetching
+            # of all LFS blobs needed at the srcrev.
+            #
+            # 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.
+            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)
+
+                # Scoop up a copy of any stuff that Git LFS downloaded. Merge them into
+                # the bare clonedir.
+                #
+                # As this procedure is invoked repeatedly on incremental fetches as
+                # a recipe's SRCREV is bumped throughout its lifetime, this will
+                # result in a gradual accumulation of LFS blobs in <ud.clonedir>/lfs
+                # corresponding to all the blobs reachable from the different revs
+                # fetched across time.
+                #
+                # Only do this if the unpack resulted in a .git/lfs directory being
+                # created; this only happens if at least one blob needed to be
+                # downloaded.
+                if os.path.exists(os.path.join(ud.destdir, ".git", "lfs")):
+                    runfetchcmd("tar -cf - lfs | tar -xf - -C %s" % ud.clonedir, d, workdir="%s/.git" % ud.destdir)
 
     def lfs_fetch(self, ud, d, clonedir, revision, fetchall=False, progresshandler=None):
         """Helper method for fetching Git LFS data"""
         try:
-            if self._need_lfs(ud) and self._contains_lfs(ud, d, clonedir) and len(revision):
-                self._ensure_git_lfs(d, ud)
-
+            if self._need_lfs(ud) and self._contains_lfs(ud, d, clonedir) and self._find_git_lfs(d) and len(revision):
                 # Using worktree with the revision because .lfsconfig may exists
                 worktree_add_cmd = "%s worktree add wt %s" % (ud.basecmd, revision)
                 runfetchcmd(worktree_add_cmd, d, log=progresshandler, workdir=clonedir)
@@ -548,7 +557,7 @@ class Git(FetchMethod):
             try:
                 self.clone_shallow_local(ud, shallowclone, d)
             except:
-                logger.warning("Fast shallow clone failed, try to skip fast mode now.")
+                logger.warning("Fash shallow clone failed, try to skip fast mode now.")
                 bb.utils.remove(tempdir, recurse=True)
                 os.mkdir(tempdir)
                 ud.shallow_skip_fast = True
@@ -625,8 +634,9 @@ class Git(FetchMethod):
 
         runfetchcmd(fetch_cmd, d, workdir=dest)
         runfetchcmd("%s update-ref %s %s" % (ud.basecmd, ref, revision), d, workdir=dest)
-        # Fetch Git LFS data
-        self.lfs_fetch(ud, d, dest, ud.revision)
+        # Fetch Git LFS data for fast shallow clones
+        if not ud.shallow_skip_fast:
+            self.lfs_fetch(ud, d, dest, ud.revision)
 
         # Apply extra ref wildcards
         all_refs_remote = runfetchcmd("%s ls-remote origin 'refs/*'" % ud.basecmd, \
@@ -635,6 +645,8 @@ class Git(FetchMethod):
         for line in all_refs_remote:
             all_refs.append(line.split()[-1])
         extra_refs = []
+        if 'tag' in ud.parm:
+            extra_refs.append(ud.parm['tag'])
         for r in ud.shallow_extra_refs:
             if not ud.bareclone:
                 r = r.replace('refs/heads/', 'refs/remotes/origin/')
@@ -646,7 +658,7 @@ class Git(FetchMethod):
                 extra_refs.append(r)
 
         for ref in extra_refs:
-            ref_fetch = ref.replace('refs/heads/', '').replace('refs/remotes/origin/', '').replace('refs/tags/', '')
+            ref_fetch = os.path.basename(ref)
             runfetchcmd("%s fetch origin --depth 1 %s" % (ud.basecmd, ref_fetch), d, workdir=dest)
             revision = runfetchcmd("%s rev-parse FETCH_HEAD" % ud.basecmd, d, workdir=dest)
             runfetchcmd("%s update-ref %s %s" % (ud.basecmd, ref, revision), d, workdir=dest)
@@ -660,7 +672,7 @@ class Git(FetchMethod):
         subdir = ud.parm.get("subdir")
         subpath = ud.parm.get("subpath")
         readpathspec = ""
-        def_destsuffix = (d.getVar("BB_GIT_DEFAULT_DESTSUFFIX") or "git") + "/"
+        def_destsuffix = "git/"
 
         if subpath:
             readpathspec = ":%s" % subpath
@@ -718,22 +730,17 @@ class Git(FetchMethod):
             output = runfetchcmd("%s rev-list -n 1 %s" % (ud.basecmd, ud.parm['tag']), d, workdir=destdir)
             output = output.strip()
             if output != ud.revision:
-                # It is possible ud.revision is the revision on an annotated tag which won't match the output of rev-list
-                # If it resolves to the same thing there isn't a problem.
-                output2 = runfetchcmd("%s rev-list -n 1 %s" % (ud.basecmd, ud.revision), d, workdir=destdir)
-                output2 = output2.strip()
-                if output != output2:
-                    raise bb.fetch2.FetchError("The revision the git tag '%s' resolved to didn't match the SRCREV in use (%s vs %s)" % (ud.parm['tag'], output, ud.revision), ud.url)
+                raise bb.fetch2.FetchError("The revision the git tag '%s' resolved to didn't match the SRCREV in use (%s vs %s)" % (ud.parm['tag'], output, ud.revision), ud.url)
 
         repourl = self._get_repo_url(ud)
         runfetchcmd("%s remote set-url origin %s" % (ud.basecmd, shlex.quote(repourl)), d, workdir=destdir)
 
         if self._contains_lfs(ud, d, destdir):
-            if not need_lfs:
+            if need_lfs and not self._find_git_lfs(d):
+                raise bb.fetch2.FetchError("Repository %s has LFS content, install git-lfs on host to download (or set lfs=0 to ignore it)" % (repourl))
+            elif not need_lfs:
                 bb.note("Repository %s has LFS content but it is not being fetched" % (repourl))
             else:
-                self._ensure_git_lfs(d, ud)
-
                 runfetchcmd("%s lfs install --local" % ud.basecmd, d, workdir=destdir)
 
         if not ud.nocheckout:
@@ -791,16 +798,14 @@ class Git(FetchMethod):
             raise bb.fetch2.FetchError("The command '%s' gave output with more then 1 line unexpectedly, output: '%s'" % (cmd, output))
         return output.split()[0] != "0"
 
-    def _lfs_objects_downloaded(self, ud, d, wd):
+    def _lfs_objects_downloaded(self, ud, d, name, wd):
         """
         Verifies whether the LFS objects for requested revisions have already been downloaded
         """
         # Bail out early if this repository doesn't use LFS
-        if not self._contains_lfs(ud, d, wd):
+        if not self._need_lfs(ud) or not self._contains_lfs(ud, d, wd):
             return True
 
-        self._ensure_git_lfs(d, ud)
-
         # The Git LFS specification specifies ([1]) the LFS folder layout so it should be safe to check for file
         # existence.
         # [1] https://github.com/git-lfs/git-lfs/blob/main/docs/spec.md#intercepting-git
@@ -829,8 +834,18 @@ class Git(FetchMethod):
         """
         Check if the repository has 'lfs' (large file) content
         """
+
+        if ud.nobranch:
+            # If no branch is specified, use the current git commit
+            refname = self._build_revision(ud, d, ud.name)
+        elif wd == ud.clonedir:
+            # The bare clonedir doesn't use the remote names; it has the branch immediately.
+            refname = ud.branch
+        else:
+            refname = "origin/%s" % ud.branch
+
         cmd = "%s grep lfs %s:.gitattributes | wc -l" % (
-            ud.basecmd, ud.revision)
+            ud.basecmd, refname)
 
         try:
             output = runfetchcmd(cmd, d, quiet=True, workdir=wd)
@@ -840,14 +855,11 @@ class Git(FetchMethod):
             pass
         return False
 
-    def _ensure_git_lfs(self, d, ud):
+    def _find_git_lfs(self, d):
         """
-        Ensures that git-lfs is available, raising a FetchError if it isn't.
+        Return True if git-lfs can be found, False otherwise.
         """
-        if shutil.which("git-lfs", path=d.getVar('PATH')) is None:
-            raise bb.fetch2.FetchError(
-                "Repository %s has LFS content, install git-lfs on host to download (or set lfs=0 "
-                "to ignore it)" % self._get_repo_url(ud))
+        return shutil.which("git-lfs", path=d.getVar('PATH')) is not None
 
     def _get_repo_url(self, ud):
         """
@@ -855,7 +867,7 @@ class Git(FetchMethod):
         """
         # Note that we do not support passwords directly in the git urls. There are several
         # reasons. SRC_URI can be written out to things like buildhistory and people don't
-        # want to leak passwords like that. Its also all too easy to share metadata without
+        # want to leak passwords like that. Its also all too easy to share metadata without 
         # removing the password. ssh keys, ~/.netrc and ~/.ssh/config files can be used as
         # alternatives so we will not take patches adding password support here.
         if ud.user:
@@ -979,7 +991,7 @@ class Git(FetchMethod):
         Return a sortable revision number by counting commits in the history
         Based on gitpkgv.bblass in meta-openembedded
         """
-        rev = ud.revision
+        rev = self._build_revision(ud, d, name)
         localpath = ud.localpath
         rev_file = os.path.join(localpath, "oe-gitpkgv_" + rev)
         if not os.path.exists(localpath):

bitbake/lib/bb/fetch2/gitsm.py

@@ -122,7 +122,7 @@ class GitSM(Git):
             url += ";name=%s" % module
             url += ";subpath=%s" % module
             url += ";nobranch=1"
-            url += ";lfs=%s" % ("1" if self._need_lfs(ud) else "0")
+            url += ";lfs=%s" % self._need_lfs(ud)
             # Note that adding "user=" here to give credentials to the
             # submodule is not supported. Since using SRC_URI to give git://
             # URL a password is not supported, one have to use one of the
@@ -245,11 +245,12 @@ class GitSM(Git):
         ret = self.process_submodules(ud, ud.destdir, unpack_submodules, d)
 
         if not ud.bareclone and ret:
-            cmdprefix = ""
-            # Avoid LFS smudging (replacing the LFS pointers with the actual content) when LFS shouldn't be used but git-lfs is installed.
-            if not self._need_lfs(ud):
-                cmdprefix = "GIT_LFS_SKIP_SMUDGE=1 "
-            runfetchcmd("%s%s submodule update --recursive --no-fetch" % (cmdprefix, ud.basecmd), d, quiet=True, workdir=ud.destdir)
+            # All submodules should already be downloaded and configured in the tree.  This simply
+            # sets up the configuration and checks out the files.  The main project config should
+            # remain unmodified, and no download from the internet should occur. As such, lfs smudge
+            # should also be skipped as these files were already smudged in the fetch stage if lfs
+            # was enabled.
+            runfetchcmd("GIT_LFS_SKIP_SMUDGE=1 %s submodule update --recursive --no-fetch" % (ud.basecmd), d, quiet=True, workdir=ud.destdir)
     def clean(self, ud, d):
         def clean_submodule(ud, url, module, modpath, workdir, d):
             url += ";bareclone=1;nobranch=1"

bitbake/lib/bb/main.py

@@ -208,10 +208,8 @@ def create_bitbake_parser():
                              "failed and anything depending on it cannot be built, as much as "
                              "possible will be built before stopping.")
 
-    exec_group.add_argument("-P", "--profile", action="append",
-                        default=[],
-                        help="Profile the command and save reports. Specify 'main', 'idle' or 'parsing' "
-                             "to indicate which bitbake code to profile.")
+    exec_group.add_argument("-P", "--profile", action="store_true",
+                        help="Profile the command and save reports.")
 
     exec_group.add_argument("-S", "--dump-signatures", action="append",
                         default=[], metavar="SIGNATURE_HANDLER",

bitbake/lib/bb/parse/__init__.py

@@ -176,41 +176,4 @@ def get_file_depends(d):
         dep_files.append(os.path.abspath(fn))
     return " ".join(dep_files)
 
-def vardeps(*varnames):
-    """
-    Function decorator that can be used to instruct the bitbake dependency
-    parsing to add a dependency on the specified variables names
-
-    Example:
-
-        @bb.parse.vardeps("FOO", "BAR")
-        def my_function():
-            ...
-
-    """
-    def inner(f):
-        if not hasattr(f, "bb_vardeps"):
-            f.bb_vardeps = set()
-        f.bb_vardeps |= set(varnames)
-        return f
-    return inner
-
-def vardepsexclude(*varnames):
-    """
-    Function decorator that can be used to instruct the bitbake dependency
-    parsing to ignore dependencies on the specified variable names in the code
-
-    Example:
-
-        @bb.parse.vardepsexclude("FOO", "BAR")
-        def my_function():
-            ...
-    """
-    def inner(f):
-        if not hasattr(f, "bb_vardepsexclude"):
-            f.bb_vardepsexclude = set()
-        f.bb_vardepsexclude |= set(varnames)
-        return f
-    return inner
-
 from bb.parse.parse_py import __version__, ConfHandler, BBHandler

bitbake/lib/bb/parse/ast.py

@@ -340,15 +340,16 @@ class InheritDeferredNode(AstNode):
         self.inherit = (classes, filename, lineno)
 
     def eval(self, data):
-        bb.parse.BBHandler.inherit_defer(*self.inherit, data)
+        inherits = data.getVar('__BBDEFINHERITS', False) or []
+        inherits.append(self.inherit)
+        data.setVar('__BBDEFINHERITS', inherits)
 
 class AddFragmentsNode(AstNode):
-    def __init__(self, filename, lineno, fragments_path_prefix, fragments_variable, flagged_variables_list_variable, builtin_fragments_variable):
+    def __init__(self, filename, lineno, fragments_path_prefix, fragments_variable, flagged_variables_list_variable):
         AstNode.__init__(self, filename, lineno)
         self.fragments_path_prefix = fragments_path_prefix
         self.fragments_variable = fragments_variable
         self.flagged_variables_list_variable = flagged_variables_list_variable
-        self.builtin_fragments_variable = builtin_fragments_variable
 
     def eval(self, data):
         # No need to use mark_dependency since we would only match a fragment
@@ -361,23 +362,13 @@ class AddFragmentsNode(AstNode):
                    return candidate_fragment_path
            return None
 
-        def check_and_set_builtin_fragment(fragment, data, builtin_fragments):
-            prefix, value = fragment.split('/', 1)
-            if prefix in builtin_fragments.keys():
-                data.setVar(builtin_fragments[prefix], value)
-                return True
-            return False
-
         fragments = data.getVar(self.fragments_variable)
         layers = data.getVar('BBLAYERS')
         flagged_variables = data.getVar(self.flagged_variables_list_variable).split()
-        builtin_fragments = {f[0]:f[1] for f in [f.split(':') for f in data.getVar(self.builtin_fragments_variable).split()] }
 
         if not fragments:
             return
         for f in fragments.split():
-            if check_and_set_builtin_fragment(f, data, builtin_fragments):
-                continue
             layerid, fragment_name = f.split('/', 1)
             full_fragment_name = data.expand("{}/{}.conf".format(self.fragments_path_prefix, fragment_name))
             fragment_path = find_fragment(layers, layerid, full_fragment_name)
@@ -441,8 +432,7 @@ def handleAddFragments(statements, filename, lineno, m):
     fragments_path_prefix = m.group(1)
     fragments_variable = m.group(2)
     flagged_variables_list_variable = m.group(3)
-    builtin_fragments_variable = m.group(4)
-    statements.append(AddFragmentsNode(filename, lineno, fragments_path_prefix, fragments_variable, flagged_variables_list_variable, builtin_fragments_variable))
+    statements.append(AddFragmentsNode(filename, lineno, fragments_path_prefix, fragments_variable, flagged_variables_list_variable))
 
 def runAnonFuncs(d):
     code = []
@@ -481,17 +471,6 @@ def finalize(fn, d, variant = None):
         if d.getVar("_FAILPARSINGERRORHANDLED", False) == True:
             raise bb.BBHandledException()
 
-        inherits = [x[0] for x in (d.getVar('__BBDEFINHERITS', False) or [('',)])]
-        bb.event.fire(bb.event.RecipePreDeferredInherits(fn, inherits), d)
-
-        while True:
-            inherits = d.getVar('__BBDEFINHERITS', False) or []
-            if not inherits:
-                break
-            inherit, filename, lineno = inherits.pop(0)
-            d.setVar('__BBDEFINHERITS', inherits)
-            bb.parse.BBHandler.inherit(inherit, filename, lineno, d, deferred=True)
-
         for var in d.getVar('__BBHANDLERS', False) or []:
             # try to add the handler
             handlerfn = d.getVarFlag(var, "filename", False)
@@ -546,6 +525,14 @@ def multi_finalize(fn, d):
         logger.debug("Appending .bbappend file %s to %s", append, fn)
         bb.parse.BBHandler.handle(append, d, True)
 
+    while True:
+        inherits = d.getVar('__BBDEFINHERITS', False) or []
+        if not inherits:
+            break
+        inherit, filename, lineno = inherits.pop(0)
+        d.setVar('__BBDEFINHERITS', inherits)
+        bb.parse.BBHandler.inherit(inherit, filename, lineno, d, deferred=True)
+
     onlyfinalise = d.getVar("__ONLYFINALISE", False)
 
     safe_d = d
@@ -581,7 +568,7 @@ def multi_finalize(fn, d):
                 d.setVar("BBEXTENDVARIANT", variantmap[name])
             else:
                 d.setVar("PN", "%s-%s" % (pn, name))
-            bb.parse.BBHandler.inherit_defer(extendedmap[name], fn, 0, d)
+            bb.parse.BBHandler.inherit(extendedmap[name], fn, 0, d)
 
         safe_d.setVar("BBCLASSEXTEND", extended)
         _create_variants(datastores, extendedmap.keys(), extendfunc, onlyfinalise)

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

@@ -42,22 +42,12 @@ def supports(fn, d):
     """Return True if fn has a supported extension"""
     return os.path.splitext(fn)[-1] in [".bb", ".bbclass", ".inc"]
 
-def inherit_defer(expression, fn, lineno, d):
-    inherit = (expression, fn, lineno)
-    inherits = d.getVar('__BBDEFINHERITS', False) or []
-    inherits.append(inherit)
-    d.setVar('__BBDEFINHERITS', inherits)
-
 def inherit(files, fn, lineno, d, deferred=False):
     __inherit_cache = d.getVar('__inherit_cache', False) or []
     #if "${" in files and not deferred:
     #    bb.warn("%s:%s has non deferred conditional inherit" % (fn, lineno))
     files = d.expand(files).split()
     for file in files:
-        defer = (d.getVar("BB_DEFER_BBCLASSES") or "").split()
-        if not deferred and file in defer:
-            inherit_defer(file, fn, lineno, d)
-            continue
         classtype = d.getVar("__bbclasstype", False)
         origfile = file
         for t in ["classes-" + classtype, "classes"]:

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

@@ -23,7 +23,7 @@ __config_regexp__  = re.compile( r"""
     (?P<var>[a-zA-Z0-9\-_+.${}/~:]*?)
     (\[(?P<flag>[a-zA-Z0-9\-_+.][a-zA-Z0-9\-_+.@/]*)\])?
 
-    (?P<whitespace>\s*) (
+    \s* (
         (?P<colon>:=) |
         (?P<lazyques>\?\?=) |
         (?P<ques>\?=) |
@@ -32,7 +32,7 @@ __config_regexp__  = re.compile( r"""
         (?P<predot>=\.) |
         (?P<postdot>\.=) |
         =
-    ) (?P<whitespace2>\s*)
+    ) \s*
 
     (?!'[^']*'[^']*'$)
     (?!\"[^\"]*\"[^\"]*\"$)
@@ -48,7 +48,7 @@ __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\-_+.][a-zA-Z0-9\-_+.@]+)\]$" )
 __addpylib_regexp__      = re.compile(r"addpylib\s+(.+)\s+(.+)" )
-__addfragments_regexp__  = re.compile(r"addfragments\s+(.+)\s+(.+)\s+(.+)\s+(.+)" )
+__addfragments_regexp__  = re.compile(r"addfragments\s+(.+)\s+(.+)\s+(.+)" )
 
 def init(data):
     return
@@ -168,8 +168,6 @@ def feeder(lineno, s, fn, statements, baseconfig=False, conffile=True):
         groupd = m.groupdict()
         if groupd['var'] == "":
             raise ParseError("Empty variable name in assignment: '%s'" % s, fn, lineno);
-        if not groupd['whitespace'] or not groupd['whitespace2']:
-            logger.warning("%s:%s has a lack of whitespace around the assignment: '%s'" % (fn, lineno, s))
         ast.handleData(statements, fn, lineno, groupd)
         return
 

bitbake/lib/bb/runqueue.py

@@ -3034,13 +3034,14 @@ def build_scenequeue_data(sqdata, rqdata, sqrq):
     rqdata.init_progress_reporter.next_stage(len(rqdata.runtaskentries))
 
     # Sanity check all dependencies could be changed to setscene task references
-    for tid in rqdata.runtaskentries:
+    for taskcounter, tid in enumerate(rqdata.runtaskentries):
         if tid in rqdata.runq_setscene_tids:
             pass
         elif sq_revdeps_squash[tid]:
             bb.msg.fatal("RunQueue", "Something went badly wrong during scenequeue generation, halting. Please report this problem.")
         else:
             del sq_revdeps_squash[tid]
+        rqdata.init_progress_reporter.update(taskcounter)
 
     rqdata.init_progress_reporter.next_stage()
 

bitbake/lib/bb/server/process.py

@@ -13,7 +13,7 @@
 import bb
 import bb.event
 import logging
-from bb import multiprocessing
+import multiprocessing
 import threading
 import array
 import os
@@ -80,6 +80,9 @@ class idleFinish():
          self.msg = msg
 
 class ProcessServer():
+    profile_filename = "profile.log"
+    profile_processed_filename = "profile.log.processed"
+
     def __init__(self, lock, lockname, sock, sockname, server_timeout, xmlrpcinterface):
         self.command_channel = False
         self.command_channel_reply = False
@@ -137,7 +140,23 @@ class ProcessServer():
             serverlog("Error writing to lock file: %s" % str(e))
             pass
 
-        return bb.utils.profile_function("main" in self.cooker.configuration.profile, self.main, "profile-mainloop.log")
+        if self.cooker.configuration.profile:
+            try:
+                import cProfile as profile
+            except:
+                import profile
+            prof = profile.Profile()
+
+            ret = profile.Profile.runcall(prof, self.main)
+
+            prof.dump_stats("profile.log")
+            bb.utils.process_profilelog("profile.log")
+            serverlog("Raw profiling information saved to profile.log and processed statistics to profile.log.processed")
+
+        else:
+            ret = self.main()
+
+        return ret
 
     def _idle_check(self):
         return len(self._idlefuns) == 0 and self.cooker.command.currentAsyncCommand is None
@@ -398,7 +417,20 @@ class ProcessServer():
                 serverlog("".join(msg))
 
     def idle_thread(self):
-        bb.utils.profile_function("idle" in self.cooker.configuration.profile, self.idle_thread_internal, "profile-idleloop.log")
+        if self.cooker.configuration.profile:
+            try:
+                import cProfile as profile
+            except:
+                import profile
+            prof = profile.Profile()
+
+            ret = profile.Profile.runcall(prof, self.idle_thread_internal)
+
+            prof.dump_stats("profile-mainloop.log")
+            bb.utils.process_profilelog("profile-mainloop.log")
+            serverlog("Raw profiling information saved to profile-mainloop.log and processed statistics to profile-mainloop.log.processed")
+        else:
+            self.idle_thread_internal()
 
     def idle_thread_internal(self):
         def remove_idle_func(function):
@@ -600,7 +632,7 @@ class BitBakeServer(object):
         os.set_inheritable(self.bitbake_lock.fileno(), True)
         os.set_inheritable(self.readypipein, True)
         serverscript = os.path.realpath(os.path.dirname(__file__) + "/../../../bin/bitbake-server")
-        os.execl(sys.executable, sys.executable, serverscript, "decafbad", str(self.bitbake_lock.fileno()), str(self.readypipein), self.logfile, self.bitbake_lock.name, self.sockname,  str(self.server_timeout or 0), str(list(self.profile)), str(self.xmlrpcinterface[0]), str(self.xmlrpcinterface[1]))
+        os.execl(sys.executable, sys.executable, serverscript, "decafbad", str(self.bitbake_lock.fileno()), str(self.readypipein), self.logfile, self.bitbake_lock.name, self.sockname,  str(self.server_timeout or 0), str(int(self.profile)), str(self.xmlrpcinterface[0]), str(self.xmlrpcinterface[1]))
 
 def execServer(lockfd, readypipeinfd, lockname, sockname, server_timeout, xmlrpcinterface, profile):
 

bitbake/lib/bb/siggen.py

@@ -708,7 +708,7 @@ class SignatureGeneratorUniHashMixIn(object):
             try:
                 with self.client() as client:
                     unihashes = client.get_unihash_batch((self._get_method(tid), self.taskhash[tid]) for tid in query_tids)
-            except (ConnectionError, FileNotFoundError, EOFError) as e:
+            except (ConnectionError, FileNotFoundError) as e:
                 bb.warn('Error contacting Hash Equivalence Server %s: %s' % (self.server, str(e)))
 
         for idx, tid in enumerate(query_tids):
@@ -817,7 +817,7 @@ class SignatureGeneratorUniHashMixIn(object):
                     d.setVar('BB_UNIHASH', new_unihash)
                 else:
                     hashequiv_logger.debug('Reported task %s as unihash %s to %s' % (taskhash, unihash, self.server))
-            except (ConnectionError, FileNotFoundError, EOFError) as e:
+            except (ConnectionError, FileNotFoundError) as e:
                 bb.warn('Error contacting Hash Equivalence Server %s: %s' % (self.server, str(e)))
         finally:
             if sigfile:
@@ -859,7 +859,7 @@ class SignatureGeneratorUniHashMixIn(object):
                 # TODO: What to do here?
                 hashequiv_logger.verbose('Task %s unihash reported as unwanted hash %s' % (tid, finalunihash))
 
-        except (ConnectionError, FileNotFoundError, EOFError) as e:
+        except (ConnectionError, FileNotFoundError) as e:
             bb.warn('Error contacting Hash Equivalence Server %s: %s' % (self.server, str(e)))
 
         return False

bitbake/lib/bb/tests/fetch.py

@@ -7,10 +7,7 @@
 #
 
 import contextlib
-import shutil
 import unittest
-import unittest.mock
-import urllib.parse
 import hashlib
 import tempfile
 import collections
@@ -20,7 +17,6 @@ import tarfile
 from bb.fetch2 import URI
 from bb.fetch2 import FetchMethod
 import bb
-import bb.utils
 from bb.tests.support.httpserver import HTTPService
 
 def skipIfNoNetwork():
@@ -28,18 +24,6 @@ def skipIfNoNetwork():
         return unittest.skip("network test")
     return lambda f: f
 
-
-@contextlib.contextmanager
-def hide_directory(directory):
-    """Hide the given directory and restore it after the context is left"""
-    temp_name = directory + ".bak"
-    os.rename(directory, temp_name)
-    try:
-        yield
-    finally:
-        os.rename(temp_name, directory)
-
-
 class TestTimeout(Exception):
     # Indicate to pytest that this is not a test suite
     __test__ = False
@@ -1291,6 +1275,7 @@ class FetcherNetworkTest(FetcherTest):
 
 class SVNTest(FetcherTest):
     def skipIfNoSvn():
+        import shutil
         if not shutil.which("svn"):
             return unittest.skip("svn not installed,  tests being skipped")
 
@@ -1413,6 +1398,8 @@ class TrustedNetworksTest(FetcherTest):
         self.assertFalse(bb.fetch.trusted_network(self.d, url))
 
 class URLHandle(unittest.TestCase):
+    import urllib.parse
+
     # Quote password as per RFC3986
     password = urllib.parse.quote(r"!#$%^&*()-_={}[]\|:?,.<>~`", r"!$&'/()*+,;=")
     datatable = {
@@ -1439,6 +1426,7 @@ class URLHandle(unittest.TestCase):
             self.assertEqual(result, v)
 
     def test_encodeurl(self):
+        import urllib.parse
         for k, v in self.datatable.items():
             result = bb.fetch.encodeurl(v)
             if result.startswith("file:"):
@@ -1465,7 +1453,7 @@ class FetchLatestVersionTest(FetcherTest):
         # combination version pattern
         ("sysprof", "git://git.yoctoproject.org/sysprof.git;protocol=https;branch=master", "cd44ee6644c3641507fb53b8a2a69137f2971219", "", "")
             : "1.2.0",
-        ("u-boot-mkimage", "git://git.yoctoproject.org/bbfetchtests-u-boot.git;branch=master;protocol=https", "62c175fbb8a0f9a926c88294ea9f7e88eb898f6c", "", "")
+        ("u-boot-mkimage", "git://source.denx.de/u-boot/u-boot.git;branch=master;protocol=https", "62c175fbb8a0f9a926c88294ea9f7e88eb898f6c", "", "")
             : "2014.01",
         # version pattern "yyyymmdd"
         ("mobile-broadband-provider-info", "git://git.yoctoproject.org/mobile-broadband-provider-info.git;protocol=https;branch=master", "4ed19e11c2975105b71b956440acdb25d46a347d", "", "")
@@ -2237,33 +2225,6 @@ class GitShallowTest(FetcherTest):
             self.fetch_shallow()
         self.assertIn("Unable to find revision v0.0 even from upstream", cm.output[0])
 
-    @skipIfNoNetwork()
-    def test_git_shallow_fetch_premirrors(self):
-        url = "git://git.openembedded.org/bitbake;branch=master;protocol=https"
-
-        # Create a separate premirror directory within tempdir
-        premirror = os.path.join(self.tempdir, "premirror")
-        os.mkdir(premirror)
-
-        # Fetch a non-shallow clone into the premirror subdir
-        self.d.setVar('BB_GIT_SHALLOW', '0')
-        self.d.setVar("DL_DIR", premirror)
-        fetcher, ud = self.fetch(url)
-
-        # Fetch a shallow clone from the premirror subdir with unpacking
-        # using the original recipe URL and the premirror mapping
-        self.d.setVar('BB_GIT_SHALLOW', '1')
-        self.d.setVar("DL_DIR", self.dldir)
-        self.d.setVar('BB_FETCH_PREMIRRORONLY', '1')
-        self.d.setVar('BB_NO_NETWORK', '1')
-        self.d.setVar('BB_GENERATE_MIRROR_TARBALLS', '0')
-        self.d.setVar("PREMIRRORS", "git://.*/.* git://{0};protocol=file".format(premirror + "/git2/" + ud.host + ud.path.replace("/", ".")))
-        fetcher = self.fetch_and_unpack(url)
-
-        # Verify that the unpacked sources are shallow clones
-        self.assertRevCount(1)
-        assert os.path.exists(os.path.join(self.gitdir, '.git', 'shallow'))
-
     @skipIfNoNetwork()
     def test_bitbake(self):
         self.git('remote add --mirror=fetch origin https://github.com/openembedded/bitbake', cwd=self.srcdir)
@@ -2308,21 +2269,9 @@ class GitShallowTest(FetcherTest):
         self.assertRevCount(1)
         assert os.path.exists(os.path.join(self.gitdir, '.git', 'shallow'))
 
-    def test_shallow_succeeds_with_tag_containing_slash(self):
-        self.add_empty_file('a')
-        self.add_empty_file('b')
-        self.git('tag t1/t2/t3', cwd=self.srcdir)
-        self.assertRevCount(2, cwd=self.srcdir)
-
-        srcrev = self.git('rev-parse HEAD', cwd=self.srcdir).strip()
-        self.d.setVar('SRCREV', srcrev)
-        uri = self.d.getVar('SRC_URI').split()[0]
-        uri = '%s;tag=t1/t2/t3' % uri
-        self.fetch_shallow(uri)
-        self.assertRevCount(1)
-
 class GitLfsTest(FetcherTest):
     def skipIfNoGitLFS():
+        import shutil
         if not shutil.which('git-lfs'):
             return unittest.skip('git-lfs not installed')
         return lambda f: f
@@ -2346,18 +2295,12 @@ class GitLfsTest(FetcherTest):
         self.git_init(cwd=self.srcdir)
         self.commit_file('.gitattributes', '*.mp3 filter=lfs -text')
 
-    def commit(self, *, cwd=None):
-        cwd = cwd or self.srcdir
-        self.git(["commit", "-m", "Change"], cwd=cwd)
-        return self.git(["rev-parse", "HEAD"], cwd=cwd).strip()
-
-    def commit_file(self, filename, content, *, cwd=None):
-        cwd = cwd or self.srcdir
-
-        with open(os.path.join(cwd, filename), "w") as f:
+    def commit_file(self, filename, content):
+        with open(os.path.join(self.srcdir, filename), "w") as f:
             f.write(content)
-        self.git(["add", filename], cwd=cwd)
-        return self.commit(cwd=cwd)
+        self.git(["add", filename], cwd=self.srcdir)
+        self.git(["commit", "-m", "Change"], cwd=self.srcdir)
+        return self.git(["rev-parse", "HEAD"], cwd=self.srcdir).strip()
 
     def fetch(self, uri=None, download=True):
         uris = self.d.getVar('SRC_URI').split()
@@ -2377,113 +2320,26 @@ class GitLfsTest(FetcherTest):
         unpacked_lfs_file = os.path.join(self.d.getVar('WORKDIR'), 'git', "Cat_poster_1.jpg")
         return unpacked_lfs_file
 
-    @skipIfNoGitLFS()
-    def test_gitsm_lfs(self):
-        """Test that the gitsm fetcher caches objects stored via LFS"""
-        self.git(["lfs", "install", "--local"], cwd=self.srcdir)
-
-        def fetch_and_verify(revision, filename, content):
-            self.d.setVar('SRCREV', revision)
-            fetcher, ud = self.fetch()
-
-            with hide_directory(submoduledir), hide_directory(self.srcdir):
-                workdir = self.d.getVar('WORKDIR')
-                fetcher.unpack(workdir)
-
-                with open(os.path.join(workdir, "git", filename)) as f:
-                    self.assertEqual(f.read(), content)
-
-        # Create the git repository that will later be used as a submodule
-        submoduledir = self.tempdir + "/submodule"
-        bb.utils.mkdirhier(submoduledir)
-        self.git_init(submoduledir)
-        self.git(["lfs", "install", "--local"], cwd=submoduledir)
-        self.commit_file('.gitattributes', '*.mp3 filter=lfs -text', cwd=submoduledir)
-
-        submodule_commit_1 = self.commit_file("a.mp3", "submodule version 1", cwd=submoduledir)
-        _ = self.commit_file("a.mp3", "submodule version 2", cwd=submoduledir)
-
-        # Add the submodule to the repository at its current HEAD revision
-        self.git(["-c", "protocol.file.allow=always", "submodule", "add", submoduledir, "submodule"],
-                 cwd=self.srcdir)
-        base_commit_1 = self.commit()
-
-        # Let the submodule point at a different revision
-        self.git(["checkout", submodule_commit_1], self.srcdir + "/submodule")
-        self.git(["add", "submodule"], cwd=self.srcdir)
-        base_commit_2 = self.commit()
-
-        # Add a LFS file to the repository
-        base_commit_3 = self.commit_file("a.mp3", "version 1")
-        # Update the added LFS file
-        base_commit_4 = self.commit_file("a.mp3", "version 2")
-
-        self.d.setVar('SRC_URI', "gitsm://%s;protocol=file;lfs=1;branch=master" % self.srcdir)
-
-        # Verify that LFS objects referenced from submodules are fetched and checked out
-        fetch_and_verify(base_commit_1, "submodule/a.mp3", "submodule version 2")
-        # Verify that the repository inside the download cache of a submodile is extended with any
-        # additional LFS objects needed when checking out a different revision.
-        fetch_and_verify(base_commit_2, "submodule/a.mp3", "submodule version 1")
-        # Verify that LFS objects referenced from the base repository are fetched and checked out
-        fetch_and_verify(base_commit_3, "a.mp3", "version 1")
-        # Verify that the cached repository is extended with any additional LFS objects required
-        # when checking out a different revision.
-        fetch_and_verify(base_commit_4, "a.mp3", "version 2")
-
-    @skipIfNoGitLFS()
-    def test_gitsm_lfs_disabled(self):
-        """Test that the gitsm fetcher does not use LFS when explicitly disabled"""
-        self.git(["lfs", "install", "--local"], cwd=self.srcdir)
-
-        def fetch_and_verify(revision, filename, content):
-            self.d.setVar('SRCREV', revision)
-            fetcher, ud = self.fetch()
-
-            with hide_directory(submoduledir), hide_directory(self.srcdir):
-                workdir = self.d.getVar('WORKDIR')
-                fetcher.unpack(workdir)
-
-                with open(os.path.join(workdir, "git", filename)) as f:
-                    # Assume that LFS did not perform smudging when the expected content is
-                    # missing.
-                    self.assertNotEqual(f.read(), content)
-
-        # Create the git repository that will later be used as a submodule
-        submoduledir = self.tempdir + "/submodule"
-        bb.utils.mkdirhier(submoduledir)
-        self.git_init(submoduledir)
-        self.git(["lfs", "install", "--local"], cwd=submoduledir)
-        self.commit_file('.gitattributes', '*.mp3 filter=lfs -text', cwd=submoduledir)
-
-        submodule_commit_1 = self.commit_file("a.mp3", "submodule version 1", cwd=submoduledir)
-
-        # Add the submodule to the repository at its current HEAD revision
-        self.git(["-c", "protocol.file.allow=always", "submodule", "add", submoduledir, "submodule"],
-                 cwd=self.srcdir)
-        base_commit_1 = self.commit()
-
-        # Add a LFS file to the repository
-        base_commit_2 = self.commit_file("a.mp3", "version 1")
-
-        self.d.setVar('SRC_URI', "gitsm://%s;protocol=file;lfs=1;branch=master;lfs=0" % self.srcdir)
-
-        # Verify that LFS objects referenced from submodules are not fetched nor checked out
-        fetch_and_verify(base_commit_1, "submodule/a.mp3", "submodule version 1")
-        # Verify that the LFS objects referenced from the base repository are not fetched nor
-        # checked out
-        fetch_and_verify(base_commit_2, "a.mp3", "version 1")
-
     @skipIfNoGitLFS()
     def test_fetch_lfs_on_srcrev_change(self):
         """Test if fetch downloads missing LFS objects when a different revision within an existing repository is requested"""
         self.git(["lfs", "install", "--local"], cwd=self.srcdir)
 
+        @contextlib.contextmanager
+        def hide_upstream_repository():
+            """Hide the upstream repository to make sure that git lfs cannot pull from it"""
+            temp_name = self.srcdir + ".bak"
+            os.rename(self.srcdir, temp_name)
+            try:
+                yield
+            finally:
+                os.rename(temp_name, self.srcdir)
+
         def fetch_and_verify(revision, filename, content):
             self.d.setVar('SRCREV', revision)
             fetcher, ud = self.fetch()
 
-            with hide_directory(self.srcdir):
+            with hide_upstream_repository():
                 workdir = self.d.getVar('WORKDIR')
                 fetcher.unpack(workdir)
 
@@ -2535,6 +2391,8 @@ class GitLfsTest(FetcherTest):
 
     @skipIfNoGitLFS()
     def test_lfs_enabled(self):
+        import shutil
+
         uri = 'git://%s;protocol=file;lfs=1;branch=master' % self.srcdir
         self.d.setVar('SRC_URI', uri)
 
@@ -2545,6 +2403,8 @@ class GitLfsTest(FetcherTest):
 
     @skipIfNoGitLFS()
     def test_lfs_disabled(self):
+        import shutil
+
         uri = 'git://%s;protocol=file;lfs=0;branch=master' % self.srcdir
         self.d.setVar('SRC_URI', uri)
 
@@ -2553,64 +2413,48 @@ class GitLfsTest(FetcherTest):
         fetcher, ud = self.fetch()
         fetcher.unpack(self.d.getVar('WORKDIR'))
 
-    @skipIfNoGitLFS()
-    def test_lfs_enabled_not_installed_during_unpack(self):
-        uri = 'git://%s;protocol=file;lfs=1;branch=master' % self.srcdir
-        self.d.setVar('SRC_URI', uri)
-
-        # Careful: suppress initial attempt at downloading
-        fetcher, ud = self.fetch(uri=None, download=False)
-
-        fetcher.download()
-        # If git-lfs cannot be found, the unpack should throw an error
-        with self.assertRaises(bb.fetch2.FetchError):
-            with unittest.mock.patch("shutil.which", return_value=None):
-                shutil.rmtree(self.gitdir, ignore_errors=True)
-                fetcher.unpack(self.d.getVar('WORKDIR'))
-
     def test_lfs_enabled_not_installed(self):
+        import shutil
+
         uri = 'git://%s;protocol=file;lfs=1;branch=master' % self.srcdir
         self.d.setVar('SRC_URI', uri)
 
         # Careful: suppress initial attempt at downloading
         fetcher, ud = self.fetch(uri=None, download=False)
 
-        # If git-lfs cannot be found, the download should throw an error
-        with unittest.mock.patch("shutil.which", return_value=None):
+        # Artificially assert that git-lfs is not installed, so
+        # we can verify a failure to unpack in it's absence.
+        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_not_installed(self):
+        import shutil
+
         uri = 'git://%s;protocol=file;lfs=0;branch=master' % self.srcdir
         self.d.setVar('SRC_URI', uri)
 
         # Careful: suppress initial attempt at downloading
         fetcher, ud = self.fetch(uri=None, download=False)
 
-        # Even if git-lfs cannot be found, the download / unpack should be successful
-        with unittest.mock.patch("shutil.which", return_value=None):
-            fetcher.download()
-            shutil.rmtree(self.gitdir, ignore_errors=True)
-            fetcher.unpack(self.d.getVar('WORKDIR'))
-
-    def test_lfs_enabled_not_installed_but_not_needed(self):
-        srcdir = os.path.join(self.tempdir, "emptygit")
-        bb.utils.mkdirhier(srcdir)
-        self.git_init(srcdir)
-        self.commit_file("test", "test content", cwd=srcdir)
-
-        uri = 'git://%s;protocol=file;lfs=1;branch=master' % srcdir
-        self.d.setVar('SRC_URI', uri)
-
-        # Careful: suppress initial attempt at downloading
-        fetcher, ud = self.fetch(uri=None, download=False)
-
-        # It shouldnt't matter that git-lfs cannot be found as the repository configuration does not
-        # specify any LFS filters.
-        with unittest.mock.patch("shutil.which", return_value=None):
+        # Artificially assert that git-lfs is not installed, so
+        # we can verify a failure to unpack in it's absence.
+        old_find_git_lfs = ud.method._find_git_lfs
+        try:
+            # Even if git-lfs cannot be found, the unpack should be successful
             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
 
 class GitURLWithSpacesTest(FetcherTest):
     test_git_urls = {
@@ -2767,6 +2611,7 @@ class CrateTest(FetcherTest):
 
 class NPMTest(FetcherTest):
     def skipIfNoNpm():
+        import shutil
         if not shutil.which('npm'):
             return unittest.skip('npm not installed')
         return lambda f: f
@@ -3294,13 +3139,6 @@ class GitTagVerificationTests(FetcherTest):
         fetcher.download()
         fetcher.unpack(self.unpackdir)
 
-    def test_annotated_tag_rev_match(self):
-        # Test a url with rev= and tag= set works
-        # rev is the annotated tag revision in this case
-        fetcher = bb.fetch.Fetch(["git://git.openembedded.org/bitbake;branch=2.8;protocol=https;rev=6d363159e4b7dc566fc40d069b2615e61774a7d8;tag=2.8.7"], self.d)
-        fetcher.download()
-        fetcher.unpack(self.unpackdir)
-
     @skipIfNoNetwork()
     def test_tag_rev_match2(self):
         # Test a url with SRCREV and tag= set works
@@ -3449,10 +3287,10 @@ class FetchPremirroronlyNetworkTest(FetcherTest):
         self.d.setVar("PREMIRRORS", self.recipe_url + " " + "file://{}".format(self.mirrordir) + " \n")
 
     def make_git_repo(self):
+        import shutil
         self.mirrorname = "git2_git.yoctoproject.org.fstests.tar.gz"
         os.makedirs(self.clonedir)
-        self.git("clone --bare {}".format(self.recipe_url), self.clonedir)
-        self.git("update-ref HEAD 15413486df1f5a5b5af699b6f3ba5f0984e52a9f", self.gitdir)
+        self.git("clone --bare --shallow-since=\"01.01.2013\" {}".format(self.recipe_url), self.clonedir)
         bb.process.run('tar -czvf {} .'.format(os.path.join(self.mirrordir, self.mirrorname)), cwd =  self.gitdir)
         shutil.rmtree(self.clonedir)
 
@@ -3460,7 +3298,7 @@ class FetchPremirroronlyNetworkTest(FetcherTest):
     def test_mirror_tarball_updated(self):
         self.make_git_repo()
         ## Upstream commit is in the mirror
-        self.d.setVar("SRCREV", "15413486df1f5a5b5af699b6f3ba5f0984e52a9f")
+        self.d.setVar("SRCREV", "49d65d53c2bf558ae6e9185af0f3af7b79d255ec")
         fetcher = bb.fetch.Fetch([self.recipe_url], self.d)
         fetcher.download()
 
@@ -3468,7 +3306,7 @@ class FetchPremirroronlyNetworkTest(FetcherTest):
     def test_mirror_tarball_outdated(self):
         self.make_git_repo()
         ## Upstream commit not in the mirror
-        self.d.setVar("SRCREV", "49d65d53c2bf558ae6e9185af0f3af7b79d255ec")
+        self.d.setVar("SRCREV", "15413486df1f5a5b5af699b6f3ba5f0984e52a9f")
         fetcher = bb.fetch.Fetch([self.recipe_url], self.d)
         with self.assertRaises(bb.fetch2.NetworkAccess):
             fetcher.download()
@@ -3478,6 +3316,7 @@ class FetchPremirroronlyMercurialTest(FetcherTest):
         the test covers also basic hg:// clone (see fetch_and_create_tarball
     """
     def skipIfNoHg():
+        import shutil
         if not shutil.which('hg'):
             return unittest.skip('Mercurial not installed')
         return lambda f: f
@@ -3533,6 +3372,7 @@ class FetchPremirroronlyBrokenTarball(FetcherTest):
             targz.write("This is not tar.gz file!")
 
     def test_mirror_broken_download(self):
+        import sys
         self.d.setVar("SRCREV", "0"*40)
         fetcher = bb.fetch.Fetch([self.recipe_url], self.d)
         with self.assertRaises(bb.fetch2.FetchError), self.assertLogs() as logs:

bitbake/lib/bb/tests/runqueue-tests/classes/base.bbclass

@@ -98,7 +98,7 @@ do_package_qa[rdeptask] = "do_packagedata"
 do_populate_lic_deploy[recrdeptask] += "do_populate_lic do_deploy"
 
 DEBIANRDEP = "do_packagedata"
-do_package_write_ipk[rdeptask] = "${DEBIANRDEP}"
+oo_package_write_ipk[rdeptask] = "${DEBIANRDEP}"
 do_package_write_rpm[rdeptask] = "${DEBIANRDEP}"
 
 addtask fetch

bitbake/lib/bb/tests/support/httpserver.py

@@ -3,7 +3,7 @@
 #
 
 import http.server
-from bb import multiprocessing
+import multiprocessing
 import os
 import traceback
 import signal
@@ -43,7 +43,7 @@ class HTTPService(object):
         self.process = multiprocessing.Process(target=self.server.server_start, args=[self.root_dir, self.logger])
 
         # The signal handler from testimage.bbclass can cause deadlocks here
-        # if the HTTPServer is terminated before it can restore the standard
+        # if the HTTPServer is terminated before it can restore the standard 
         #signal behaviour
         orig = signal.getsignal(signal.SIGTERM)
         signal.signal(signal.SIGTERM, signal.SIG_DFL)

bitbake/lib/bb/tests/utils.py

@@ -692,14 +692,3 @@ class EnvironmentTests(unittest.TestCase):
         self.assertIn("A", os.environ)
         self.assertEqual(os.environ["A"], "this is A")
         self.assertNotIn("B", os.environ)
-
-class FilemodeTests(unittest.TestCase):
-    def test_filemode_convert(self):
-        self.assertEqual(0o775, bb.utils.to_filemode("0o775"))
-        self.assertEqual(0o775, bb.utils.to_filemode(0o775))
-        self.assertEqual(0o775, bb.utils.to_filemode("775"))
-        with self.assertRaises(ValueError):
-            bb.utils.to_filemode("xyz")
-        with self.assertRaises(ValueError):
-            bb.utils.to_filemode("999")
-

bitbake/lib/bb/tinfoil.py

@@ -14,7 +14,7 @@ import time
 import atexit
 import re
 from collections import OrderedDict, defaultdict
-from functools import partial, wraps
+from functools import partial
 from contextlib import contextmanager
 
 import bb.cache
@@ -27,135 +27,6 @@ import bb.remotedata
 from bb.main import setup_bitbake, BitBakeConfigParameters
 import bb.fetch2
 
-def wait_for(f):
-    """
-    Wrap a function that makes an asynchronous tinfoil call using
-    self.run_command() and wait for events to say that the call has been
-    successful, or an error has occurred.
-    """
-    @wraps(f)
-    def wrapper(self, *args, handle_events=True, extra_events=None, event_callback=None, **kwargs):
-        if handle_events:
-            # A reasonable set of default events matching up with those we handle below
-            eventmask = [
-                        'bb.event.BuildStarted',
-                        'bb.event.BuildCompleted',
-                        'logging.LogRecord',
-                        'bb.event.NoProvider',
-                        'bb.command.CommandCompleted',
-                        'bb.command.CommandFailed',
-                        'bb.build.TaskStarted',
-                        'bb.build.TaskFailed',
-                        'bb.build.TaskSucceeded',
-                        'bb.build.TaskFailedSilent',
-                        'bb.build.TaskProgress',
-                        'bb.runqueue.runQueueTaskStarted',
-                        'bb.runqueue.sceneQueueTaskStarted',
-                        'bb.event.ProcessStarted',
-                        'bb.event.ProcessProgress',
-                        'bb.event.ProcessFinished',
-                        ]
-            if extra_events:
-                eventmask.extend(extra_events)
-            ret = self.set_event_mask(eventmask)
-
-        includelogs = self.config_data.getVar('BBINCLUDELOGS')
-        loglines = self.config_data.getVar('BBINCLUDELOGS_LINES')
-
-        # Call actual function
-        ret = f(self, *args, **kwargs)
-
-        if handle_events:
-            lastevent = time.time()
-            result = False
-            # Borrowed from knotty, instead somewhat hackily we use the helper
-            # as the object to store "shutdown" on
-            helper = bb.ui.uihelper.BBUIHelper()
-            helper.shutdown = 0
-            parseprogress = None
-            termfilter = bb.ui.knotty.TerminalFilter(helper, helper, self.logger.handlers, quiet=self.quiet)
-            try:
-                while True:
-                    try:
-                        event = self.wait_event(0.25)
-                        if event:
-                            lastevent = time.time()
-                            if event_callback and event_callback(event):
-                                continue
-                            if helper.eventHandler(event):
-                                if isinstance(event, bb.build.TaskFailedSilent):
-                                    self.logger.warning("Logfile for failed setscene task is %s" % event.logfile)
-                                elif isinstance(event, bb.build.TaskFailed):
-                                    bb.ui.knotty.print_event_log(event, includelogs, loglines, termfilter)
-                                continue
-                            if isinstance(event, bb.event.ProcessStarted):
-                                if self.quiet > 1:
-                                    continue
-                                parseprogress = bb.ui.knotty.new_progress(event.processname, event.total)
-                                parseprogress.start(False)
-                                continue
-                            if isinstance(event, bb.event.ProcessProgress):
-                                if self.quiet > 1:
-                                    continue
-                                if parseprogress:
-                                    parseprogress.update(event.progress)
-                                else:
-                                    bb.warn("Got ProcessProgress event for something that never started?")
-                                continue
-                            if isinstance(event, bb.event.ProcessFinished):
-                                if self.quiet > 1:
-                                    continue
-                                if parseprogress:
-                                    parseprogress.finish()
-                                parseprogress = None
-                                continue
-                            if isinstance(event, bb.command.CommandCompleted):
-                                result = True
-                                break
-                            if isinstance(event, (bb.command.CommandFailed, bb.command.CommandExit)):
-                                self.logger.error(str(event))
-                                result = False
-                                break
-                            if isinstance(event, logging.LogRecord):
-                                if event.taskpid == 0 or event.levelno > logging.INFO:
-                                    self.logger.handle(event)
-                                continue
-                            if isinstance(event, bb.event.NoProvider):
-                                self.logger.error(str(event))
-                                result = False
-                                break
-                        elif helper.shutdown > 1:
-                            break
-                        termfilter.updateFooter()
-                        if time.time() > (lastevent + (3*60)):
-                            if not self.run_command('ping', handle_events=False):
-                                print("\nUnable to ping server and no events, closing down...\n")
-                                return False
-                    except KeyboardInterrupt:
-                        termfilter.clearFooter()
-                        if helper.shutdown == 1:
-                            print("\nSecond Keyboard Interrupt, stopping...\n")
-                            ret = self.run_command("stateForceShutdown")
-                            if ret and ret[2]:
-                                self.logger.error("Unable to cleanly stop: %s" % ret[2])
-                        elif helper.shutdown == 0:
-                            print("\nKeyboard Interrupt, closing down...\n")
-                            interrupted = True
-                            ret = self.run_command("stateShutdown")
-                            if ret and ret[2]:
-                                self.logger.error("Unable to cleanly shutdown: %s" % ret[2])
-                        helper.shutdown = helper.shutdown + 1
-                termfilter.clearFooter()
-            finally:
-                termfilter.finish()
-            if helper.failed_tasks:
-                result = False
-            return result
-        else:
-            return ret
-
-    return wrapper
-
 
 # We need this in order to shut down the connection to the bitbake server,
 # otherwise the process will never properly exit
@@ -829,10 +700,6 @@ class Tinfoil:
         """
         return self.run_command('buildFile', buildfile, task, internal)
 
-    @wait_for
-    def build_file_sync(self, *args):
-        self.build_file(*args)
-
     def build_targets(self, targets, task=None, handle_events=True, extra_events=None, event_callback=None):
         """
         Builds the specified targets. This is equivalent to a normal invocation

bitbake/lib/bb/ui/knotty.py

@@ -353,7 +353,7 @@ def print_event_log(event, includelogs, loglines, termfilter):
         termfilter.clearFooter()
         bb.error("Logfile of failure stored in: %s" % logfile)
         if includelogs and not event.errprinted:
-            bb.plain("Log data follows:")
+            print("Log data follows:")
             f = open(logfile, "r")
             lines = []
             while True:
@@ -366,11 +366,11 @@ def print_event_log(event, includelogs, loglines, termfilter):
                     if len(lines) > int(loglines):
                         lines.pop(0)
                 else:
-                    bb.plain('| %s' % l)
+                    print('| %s' % l)
             f.close()
             if lines:
                 for line in lines:
-                    bb.plain(line)
+                    print(line)
 
 def _log_settings_from_server(server, observe_only):
     # Get values of variables which control our output

bitbake/lib/hashserv/sqlite.py

@@ -4,7 +4,6 @@
 #
 # SPDX-License-Identifier: GPL-2.0-only
 #
-from datetime import datetime, timezone
 import sqlite3
 import logging
 from contextlib import closing
@@ -54,22 +53,6 @@ CONFIG_TABLE_DEFINITION = (
 CONFIG_TABLE_COLUMNS = tuple(name for name, _, _ in CONFIG_TABLE_DEFINITION)
 
 
-def adapt_datetime_iso(val):
-    """Adapt datetime.datetime to UTC ISO 8601 date."""
-    return val.astimezone(timezone.utc).isoformat()
-
-
-sqlite3.register_adapter(datetime, adapt_datetime_iso)
-
-
-def convert_datetime(val):
-    """Convert ISO 8601 datetime to datetime.datetime object."""
-    return datetime.fromisoformat(val.decode())
-
-
-sqlite3.register_converter("DATETIME", convert_datetime)
-
-
 def _make_table(cursor, name, definition):
     cursor.execute(
         """

bitbake/lib/hashserv/tests.py

@@ -10,7 +10,7 @@ from .server import DEFAULT_ANON_PERMS, ALL_PERMISSIONS
 from bb.asyncrpc import InvokeError
 import hashlib
 import logging
-from bb import multiprocessing
+import multiprocessing
 import os
 import sys
 import tempfile

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

@@ -41,9 +41,8 @@ current_releases = [
     # Release slot #3 'master'
     ['Master','master','','Yocto Project master','master','','master'],
     # Release slot #4
-    ['Whinlatter','5.3','October 2025','5.3.0 (October 2024)','Support for 7 months (until May 2026)','','2.14'],
-    ['Walnascar','5.2','April 2025','5.2.0 (April 2025)','Support for 7 months (until October 2025)','','2.12'],
-    #['Styhead','5.1','November 2024','5.1.0 (November 2024)','Support for 7 months (until May 2025)','','2.10'],
+    ['Walnascar','5.2','April 2025','5.2.0 (April 2024)','Support for 7 months (until October 2025)','','2.12'],
+    ['Styhead','5.1','November 2024','5.1.0 (November 2024)','Support for 7 months (until May 2025)','','2.10'],
     #['Nanbield','4.3','November 2023','4.3.0 (November 2023)','Support for 7 months (until May 2024)','','2.6'],
     #['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'],

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

@@ -23,21 +23,16 @@
     <field type="CharField" name="branch">master</field>
   </object>
   <object model="orm.bitbakeversion" pk="4">
-    <field type="CharField" name="name">whinlatter</field>
-    <field type="CharField" name="giturl">git://git.openembedded.org/bitbake</field>
-    <field type="CharField" name="branch">2.14</field>
-  </object>
-  <object model="orm.bitbakeversion" pk="5">
     <field type="CharField" name="name">walnascar</field>
     <field type="CharField" name="giturl">git://git.openembedded.org/bitbake</field>
     <field type="CharField" name="branch">2.12</field>
   </object>
-  <object model="orm.bitbakeversion" pk="6">
+  <object model="orm.bitbakeversion" pk="5">
     <field type="CharField" name="name">styhead</field>
     <field type="CharField" name="giturl">git://git.openembedded.org/bitbake</field>
     <field type="CharField" name="branch">2.10</field>
   </object>
-  <object model="orm.bitbakeversion" pk="7">
+  <object model="orm.bitbakeversion" pk="6">
     <field type="CharField" name="name">kirkstone</field>
     <field type="CharField" name="giturl">git://git.openembedded.org/bitbake</field>
     <field type="CharField" name="branch">2.0</field>
@@ -66,30 +61,23 @@
     <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">whinlatter</field>
-    <field type="CharField" name="description">Openembedded Whinlatter</field>
-    <field rel="ManyToOneRel" to="orm.bitbakeversion" name="bitbake_version">4</field>
-    <field type="CharField" name="branch_name">whinlatter</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=whinlatter\"&gt;OpenEmbedded Whinlatter&lt;/a&gt; branch.</field>
-  </object>
-  <object model="orm.release" pk="5">
     <field type="CharField" name="name">walnascar</field>
     <field type="CharField" name="description">Openembedded Walnascar</field>
-    <field rel="ManyToOneRel" to="orm.bitbakeversion" name="bitbake_version">5</field>
+    <field rel="ManyToOneRel" to="orm.bitbakeversion" name="bitbake_version">4</field>
     <field type="CharField" name="branch_name">walnascar</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=walnascar\"&gt;OpenEmbedded Walnascar&lt;/a&gt; branch.</field>
   </object>
-  <object model="orm.release" pk="6">
+  <object model="orm.release" pk="5">
     <field type="CharField" name="name">styhead</field>
     <field type="CharField" name="description">Openembedded Styhead</field>
-    <field rel="ManyToOneRel" to="orm.bitbakeversion" name="bitbake_version">6</field>
+    <field rel="ManyToOneRel" to="orm.bitbakeversion" name="bitbake_version">5</field>
     <field type="CharField" name="branch_name">styhead</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=styhead\"&gt;OpenEmbedded Styhead&lt;/a&gt; branch.</field>
   </object>
-  <object model="orm.release" pk="7">
+  <object model="orm.release" pk="6">
     <field type="CharField" name="name">kirkstone</field>
     <field type="CharField" name="description">Openembedded Kirkstone</field>
-    <field rel="ManyToOneRel" to="orm.bitbakeversion" name="bitbake_version">7</field>
+    <field rel="ManyToOneRel" to="orm.bitbakeversion" name="bitbake_version">6</field>
     <field type="CharField" name="branch_name">kirkstone</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=kirkstone\"&gt;OpenEmbedded Kirkstone&lt;/a&gt; branch.</field>
   </object>
@@ -119,10 +107,6 @@
     <field rel="ManyToOneRel" to="orm.release" name="release">6</field>
     <field type="CharField" name="layer_name">openembedded-core</field>
   </object>
-  <object model="orm.releasedefaultlayer" pk="7">
-    <field rel="ManyToOneRel" to="orm.release" name="release">7</field>
-    <field type="CharField" name="layer_name">openembedded-core</field>
-  </object>
 
 
   <!-- Layer for the Local release -->

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

@@ -26,24 +26,18 @@
     <field type="CharField" name="dirpath">bitbake</field>
   </object>
   <object model="orm.bitbakeversion" pk="4">
-    <field type="CharField" name="name">whinlatter</field>
-    <field type="CharField" name="giturl">git://git.yoctoproject.org/poky</field>
-    <field type="CharField" name="branch">whinlatter</field>
-    <field type="CharField" name="dirpath">bitbake</field>
-  </object>
-  <object model="orm.bitbakeversion" pk="5">
     <field type="CharField" name="name">walnascar</field>
     <field type="CharField" name="giturl">git://git.yoctoproject.org/poky</field>
     <field type="CharField" name="branch">walnascar</field>
     <field type="CharField" name="dirpath">bitbake</field>
   </object>
-  <object model="orm.bitbakeversion" pk="6">
+  <object model="orm.bitbakeversion" pk="5">
     <field type="CharField" name="name">styhead</field>
     <field type="CharField" name="giturl">git://git.yoctoproject.org/poky</field>
     <field type="CharField" name="branch">styhead</field>
     <field type="CharField" name="dirpath">bitbake</field>
   </object>
-  <object model="orm.bitbakeversion" pk="7">
+  <object model="orm.bitbakeversion" pk="6">
     <field type="CharField" name="name">kirkstone</field>
     <field type="CharField" name="giturl">git://git.yoctoproject.org/poky</field>
     <field type="CharField" name="branch">kirkstone</field>
@@ -74,30 +68,23 @@
     <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">whinlatter</field>
-    <field type="CharField" name="description">Yocto Project 5.3 "Whinlatter"</field>
-    <field rel="ManyToOneRel" to="orm.bitbakeversion" name="bitbake_version">4</field>
-    <field type="CharField" name="branch_name">whinlatter</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=whinlatter"&gt;Yocto Project Whinlatter branch&lt;/a&gt;.</field>
-  </object>
-  <object model="orm.release" pk="5">
     <field type="CharField" name="name">walnascar</field>
     <field type="CharField" name="description">Yocto Project 5.2 "Walnascar"</field>
-    <field rel="ManyToOneRel" to="orm.bitbakeversion" name="bitbake_version">5</field>
+    <field rel="ManyToOneRel" to="orm.bitbakeversion" name="bitbake_version">4</field>
     <field type="CharField" name="branch_name">walnascar</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=walnascar"&gt;Yocto Project Walnascar branch&lt;/a&gt;.</field>
   </object>
-  <object model="orm.release" pk="6">
+  <object model="orm.release" pk="5">
     <field type="CharField" name="name">styhead</field>
     <field type="CharField" name="description">Yocto Project 5.1 "Styhead"</field>
-    <field rel="ManyToOneRel" to="orm.bitbakeversion" name="bitbake_version">6</field>
+    <field rel="ManyToOneRel" to="orm.bitbakeversion" name="bitbake_version">5</field>
     <field type="CharField" name="branch_name">styhead</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=styhead"&gt;Yocto Project Styhead branch&lt;/a&gt;.</field>
   </object>
-  <object model="orm.release" pk="7">
+  <object model="orm.release" pk="6">
     <field type="CharField" name="name">kirkstone</field>
     <field type="CharField" name="description">Yocto Project 4.0 "Kirkstone"</field>
-    <field rel="ManyToOneRel" to="orm.bitbakeversion" name="bitbake_version">7</field>
+    <field rel="ManyToOneRel" to="orm.bitbakeversion" name="bitbake_version">6</field>
     <field type="CharField" name="branch_name">kirkstone</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=kirkstone"&gt;Yocto Project Kirkstone branch&lt;/a&gt;.</field>
   </object>
@@ -175,18 +162,6 @@
     <field rel="ManyToOneRel" to="orm.release" name="release">6</field>
     <field type="CharField" name="layer_name">meta-yocto-bsp</field>
   </object>
-  <object model="orm.releasedefaultlayer" pk="19">
-    <field rel="ManyToOneRel" to="orm.release" name="release">7</field>
-    <field type="CharField" name="layer_name">openembedded-core</field>
-  </object>
-  <object model="orm.releasedefaultlayer" pk="20">
-    <field rel="ManyToOneRel" to="orm.release" name="release">7</field>
-    <field type="CharField" name="layer_name">meta-poky</field>
-  </object>
-  <object model="orm.releasedefaultlayer" pk="21">
-    <field rel="ManyToOneRel" to="orm.release" name="release">7</field>
-    <field type="CharField" name="layer_name">meta-yocto-bsp</field>
-  </object>
 
   <!-- Default layers provided by poky
        openembedded-core
@@ -227,27 +202,20 @@
     <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">whinlatter</field>
+    <field type="CharField" name="branch">walnascar</field>
     <field type="CharField" name="dirpath">meta</field>
   </object>
   <object model="orm.layer_version" pk="5">
     <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">5</field>
-    <field type="CharField" name="branch">walnascar</field>
+    <field type="CharField" name="branch">styhead</field>
     <field type="CharField" name="dirpath">meta</field>
   </object>
   <object model="orm.layer_version" pk="6">
     <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">6</field>
-    <field type="CharField" name="branch">styhead</field>
-    <field type="CharField" name="dirpath">meta</field>
-  </object>
-  <object model="orm.layer_version" pk="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">7</field>
     <field type="CharField" name="branch">kirkstone</field>
     <field type="CharField" name="dirpath">meta</field>
   </object>
@@ -260,14 +228,14 @@
     <field type="CharField" name="vcs_web_tree_base_url">https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/%path%?h=%branch%</field>
     <field type="CharField" name="vcs_web_file_base_url">https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/%path%?h=%branch%</field>
   </object>
-  <object model="orm.layer_version" pk="8">
+  <object model="orm.layer_version" pk="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">1</field>
     <field type="CharField" name="branch">scarthgap</field>
     <field type="CharField" name="dirpath">meta-poky</field>
   </object>
-  <object model="orm.layer_version" pk="9">
+  <object model="orm.layer_version" pk="8">
     <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">2</field>
@@ -275,38 +243,31 @@
     <field type="CharField" name="commit">HEAD</field>
     <field type="CharField" name="dirpath">meta-poky</field>
   </object>
-  <object model="orm.layer_version" pk="10">
+  <object model="orm.layer_version" pk="9">
     <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">3</field>
     <field type="CharField" name="branch">master</field>
     <field type="CharField" name="dirpath">meta-poky</field>
   </object>
-  <object model="orm.layer_version" pk="11">
+  <object model="orm.layer_version" pk="10">
     <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">whinlatter</field>
+    <field type="CharField" name="branch">walnascar</field>
+    <field type="CharField" name="dirpath">meta-poky</field>
+  </object>
+  <object model="orm.layer_version" pk="11">
+    <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">5</field>
+    <field type="CharField" name="branch">styhead</field>
     <field type="CharField" name="dirpath">meta-poky</field>
   </object>
   <object model="orm.layer_version" pk="12">
-    <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">5</field>
-    <field type="CharField" name="branch">walnascar</field>
-    <field type="CharField" name="dirpath">meta-poky</field>
-  </object>
-  <object model="orm.layer_version" pk="13">
     <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">6</field>
-    <field type="CharField" name="branch">styhead</field>
-    <field type="CharField" name="dirpath">meta-poky</field>
-  </object>
-  <object model="orm.layer_version" pk="14">
-    <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">7</field>
     <field type="CharField" name="branch">kirkstone</field>
     <field type="CharField" name="dirpath">meta-poky</field>
   </object>
@@ -319,14 +280,14 @@
     <field type="CharField" name="vcs_web_tree_base_url">https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/%path%?h=%branch%</field>
     <field type="CharField" name="vcs_web_file_base_url">https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/%path%?h=%branch%</field>
   </object>
-  <object model="orm.layer_version" pk="15">
+  <object model="orm.layer_version" pk="13">
     <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">1</field>
     <field type="CharField" name="branch">scarthgap</field>
     <field type="CharField" name="dirpath">meta-yocto-bsp</field>
   </object>
-  <object model="orm.layer_version" pk="16">
+  <object model="orm.layer_version" pk="14">
     <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">2</field>
@@ -334,38 +295,31 @@
     <field type="CharField" name="commit">HEAD</field>
     <field type="CharField" name="dirpath">meta-yocto-bsp</field>
   </object>
-  <object model="orm.layer_version" pk="17">
+  <object model="orm.layer_version" pk="15">
     <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">3</field>
     <field type="CharField" name="branch">master</field>
     <field type="CharField" name="dirpath">meta-yocto-bsp</field>
   </object>
-  <object model="orm.layer_version" pk="18">
+  <object model="orm.layer_version" pk="16">
     <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">whinlatter</field>
-    <field type="CharField" name="dirpath">meta-yocto-bsp</field>
-  </object>
-  <object model="orm.layer_version" pk="19">
-    <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">5</field>
     <field type="CharField" name="branch">walnascar</field>
     <field type="CharField" name="dirpath">meta-yocto-bsp</field>
   </object>
-  <object model="orm.layer_version" pk="20">
+  <object model="orm.layer_version" pk="17">
     <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">6</field>
+    <field rel="ManyToOneRel" to="orm.release" name="release">5</field>
     <field type="CharField" name="branch">styhead</field>
     <field type="CharField" name="dirpath">meta-yocto-bsp</field>
   </object>
-  <object model="orm.layer_version" pk="21">
+  <object model="orm.layer_version" pk="18">
     <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">7</field>
+    <field rel="ManyToOneRel" to="orm.release" name="release">6</field>
     <field type="CharField" name="branch">kirkstone</field>
     <field type="CharField" name="dirpath">meta-yocto-bsp</field>
   </object>

bitbake/lib/toaster/tests/browser/test_layerdetails_page.py

@@ -108,8 +108,6 @@ class TestLayerDetailsPage(SeleniumTestCase):
             save_btn.click()
 
         self.wait_until_visible("#save-changes-for-switch")
-        # Ensure scrolled into view
-        self.driver.execute_script('window.scrollTo({behavior: "instant", top: 0, left: 0})')
         btn_save_chg_for_switch = self.wait_until_clickable(
             "#save-changes-for-switch")
         btn_save_chg_for_switch.click()

bitbake/lib/toaster/tests/builds/buildtest.py

@@ -128,7 +128,7 @@ class BuildTest(unittest.TestCase):
         if os.environ.get("TOASTER_TEST_USE_SSTATE_MIRROR"):
             ProjectVariable.objects.get_or_create(
                 name="SSTATE_MIRRORS",
-                value="file://.* http://sstate.yoctoproject.org/all/PATH;downloadfilename=PATH",
+                value="file://.* http://cdn.jsdelivr.net/yocto/sstate/all/PATH;downloadfilename=PATH",
                 project=project)
 
         ProjectTarget.objects.create(project=project,

bitbake/lib/toaster/tests/functional/test_create_new_project.py

@@ -53,7 +53,7 @@ class TestCreateNewProject(SeleniumFunctionalTestCase):
           - Release: Yocto Project 4.0 "Kirkstone" (option value: 6)
           - Merge Toaster settings: True
         """
-        release = '7'
+        release = '6'
         release_title = 'Yocto Project 4.0 "Kirkstone"'
         project_name = 'projectkirkstone'
         self.create_new_project(

bitbake/lib/toaster/tests/functional/test_project_page.py

@@ -685,17 +685,17 @@ class TestProjectPage(TestProjectPageBase):
             'active', str(self.find('#information').get_attribute('class'))
         )
         # Check second tab (recipes)
-        self.wait_until_visible('.nav-tabs')
         # Ensure page is scrolled to the top
-        self.driver.execute_script('window.scrollTo({behavior: "instant", top: 0, left: 0})')
+        self.driver.find_element(By.XPATH, '//body').send_keys(Keys.CONTROL + Keys.HOME)
+        self.wait_until_visible('.nav-tabs')
         tabs[1].click()
         self.assertIn(
             'active', str(self.find('#recipes').get_attribute('class'))
         )
         # Check third tab (machines)
-        self.wait_until_visible('.nav-tabs')
         # Ensure page is scrolled to the top
-        self.driver.execute_script('window.scrollTo({behavior: "instant", top: 0, left: 0})')
+        self.driver.find_element(By.XPATH, '//body').send_keys(Keys.CONTROL + Keys.HOME)
+        self.wait_until_visible('.nav-tabs')
         tabs[2].click()
         self.assertIn(
             'active', str(self.find('#machines').get_attribute('class'))

documentation/README

@@ -314,16 +314,6 @@ See https://stackoverflow.com/questions/27420317/restructured-text-rst-http-link
 Anchor (<#link>) links are forbidden as they are not checked by Sphinx during
 the build and may be broken without knowing about it.
 
-It is also possible to refer to another document within yocto-docs with the
-:doc: directive (c.f.
-https://www.sphinx-doc.org/en/master/usage/referencing.html#role-doc), e.g.:
-
-  For more information, read :doc:`/bsp-guide/index`.
-
-Note that only "absolute" paths (starting with a '/') are allowed. The root
-directory of that path is documentation/, that is, :doc:`/bsp-guide/index`
-points at documentation/bsp-guide/index.rst.
-
 References
 ==========
 
@@ -416,22 +406,5 @@ both the Yocto Project and BitBake manuals:
 Submitting documentation changes
 ================================
 
-Please refer to our contributor guide here: https://docs.yoctoproject.org/contributor-guide/
-for full details on how to submit changes.
-
-As a quick guide, patches should be sent to docs@lists.yoctoproject.org
-The git command to do that would be:
-
-     git send-email -M -1 --to docs@lists.yoctoproject.org
-
-The 'To' header can be set as default for this repository:
-
-     git config sendemail.to docs@lists.yoctoproject.org
-
-Now you can just do 'git send-email origin/master..' to send all local patches.
-
-Read the other sections in this document and documentation/standards.md for
-rules to follow when contributing to the documentation.
-
-Git repository: https://git.yoctoproject.org/yocto-docs
-Mailing list: docs@lists.yoctoproject.org
+Please see the top level README file in this repository for details of where
+to send patches.

documentation/brief-yoctoprojectqs/index.rst

@@ -57,7 +57,7 @@ following requirements:
    :ref:`dev-manual/start:preparing the build host`
    section in the Yocto Project Development Tasks Manual.
 
--  Ensure that the following utilities have these minimum version numbers:
+-
 
    -  Git &MIN_GIT_VERSION; or greater
    -  tar &MIN_TAR_VERSION; or greater
@@ -65,7 +65,7 @@ following requirements:
    -  gcc &MIN_GCC_VERSION; or greater.
    -  GNU make &MIN_MAKE_VERSION; or greater
 
-If your build host does not satisfy all of the above version
+If your build host does not meet any of these three listed version
 requirements, you can take steps to prepare the system so that you
 can still use the Yocto Project. See the
 :ref:`ref-manual/system-requirements:required git, tar, python, make and gcc versions`
@@ -76,10 +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::
 
-.. literalinclude:: ../tools/host_packages_scripts/ubuntu_essential.sh
-   :language: shell
+   $ sudo apt install &UBUNTU_DEBIAN_HOST_PACKAGES_ESSENTIAL;
 
 .. note::
 
@@ -183,7 +182,7 @@ an entire Linux distribution, including the toolchain, from source.
       page of the Yocto Project Wiki.
 
 #. **Initialize the Build Environment:** From within the ``poky``
-   directory, run the :ref:`ref-manual/structure:``oe-init-build-env```
+   directory, run the :ref:`ref-manual/structure:\`\`oe-init-build-env\`\``
    environment
    setup script to define Yocto Project's build environment on your
    build host.
@@ -253,7 +252,7 @@ an entire Linux distribution, including the toolchain, from source.
       file in the :term:`Build Directory`::
 
          BB_HASHSERVE_UPSTREAM = "wss://hashserv.yoctoproject.org/ws"
-         SSTATE_MIRRORS ?= "file://.* http://sstate.yoctoproject.org/all/PATH;downloadfilename=PATH"
+         SSTATE_MIRRORS ?= "file://.* http://cdn.jsdelivr.net/yocto/sstate/all/PATH;downloadfilename=PATH"
          BB_HASHSERVE = "auto"
          BB_SIGNATURE_HANDLER = "OEEquivHash"
 

documentation/bsp-guide/bsp.rst

@@ -81,7 +81,7 @@ directory of that Layer. This directory is what you add to the
 ``conf/bblayers.conf`` file found in your
 :term:`Build Directory`, which is
 established after you run the OpenEmbedded build environment setup
-script (i.e. :ref:`ref-manual/structure:``oe-init-build-env```).
+script (i.e. :ref:`ref-manual/structure:\`\`oe-init-build-env\`\``).
 Adding the root directory allows the :term:`OpenEmbedded Build System`
 to recognize the BSP
 layer and from it build an image. Here is an example::
@@ -172,7 +172,7 @@ section.
 #. *Optionally Clone the meta-intel BSP Layer:* If your hardware is
    based on current Intel CPUs and devices, you can leverage this BSP
    layer. For details on the ``meta-intel`` BSP layer, see the layer's
-   :yocto_git:`README </meta-intel/tree/README.md>` file.
+   :yocto_git:`README </meta-intel/tree/README>` file.
 
    #. *Navigate to Your Source Directory:* Typically, you set up the
       ``meta-intel`` Git repository inside the :term:`Source Directory` (e.g.
@@ -204,7 +204,7 @@ section.
       .. note::
 
          To see the available branch names in a cloned repository, use the ``git
-         branch -a`` command. See the
+         branch -al`` command. See the
          ":ref:`dev-manual/start:checking out by branch in poky`"
          section in the Yocto Project Development Tasks Manual for more
          information.
@@ -229,7 +229,7 @@ section.
 
 #. *Initialize the Build Environment:* While in the root directory of
    the Source Directory (i.e. ``poky``), run the
-   :ref:`ref-manual/structure:``oe-init-build-env``` environment
+   :ref:`ref-manual/structure:\`\`oe-init-build-env\`\`` environment
    setup script to define the OpenEmbedded build environment on your
    build host. ::
 
@@ -674,21 +674,21 @@ to the kernel recipe by using a similarly named append file, which is
 located in the BSP Layer for your target device (e.g. the
 ``meta-bsp_root_name/recipes-kernel/linux`` directory).
 
-Suppose you are using the ``linux-yocto_6.12.bb`` recipe to build the
+Suppose you are using the ``linux-yocto_4.4.bb`` recipe to build the
 kernel. In other words, you have selected the kernel in your
 ``"bsp_root_name".conf`` file by adding
 :term:`PREFERRED_PROVIDER` and :term:`PREFERRED_VERSION`
 statements as follows::
 
    PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
-   PREFERRED_VERSION_linux-yocto ?= "6.12%"
+   PREFERRED_VERSION_linux-yocto ?= "4.4%"
 
 .. note::
 
    When the preferred provider is assumed by default, the :term:`PREFERRED_PROVIDER`
    statement does not appear in the ``"bsp_root_name".conf`` file.
 
-You would use the ``linux-yocto_6.12.bbappend`` file to append specific
+You would use the ``linux-yocto_4.4.bbappend`` file to append specific
 BSP settings to the kernel, thus configuring the kernel for your
 particular BSP.
 
@@ -698,19 +698,14 @@ in the Yocto Project Linux Kernel Development Manual.
 
 An alternate scenario is when you create your own kernel recipe for the
 BSP. A good example of this is the Raspberry Pi BSP. If you examine the
-``recipes-kernel/linux`` directory in that layer you see the following
-Raspberry Pi-specific recipes and associated files::
+``recipes-kernel/linux`` directory you see the following::
 
-   files/
-   linux-raspberrypi_6.12.bb
-   linux-raspberrypi_6.1.bb
-   linux-raspberrypi_6.6.bb
    linux-raspberrypi-dev.bb
    linux-raspberrypi.inc
-   linux-raspberrypi-v7_6.12.bb
-   linux-raspberrypi-v7_6.1.bb
-   linux-raspberrypi-v7_6.6.bb
-   linux-raspberrypi-v7.inc
+   linux-raspberrypi_4.14.bb
+   linux-raspberrypi_4.9.bb
+
+The directory contains three kernel recipes and a common include file.
 
 Developing a Board Support Package (BSP)
 ========================================
@@ -881,7 +876,7 @@ The requirements for a released BSP that conform to the Yocto Project are:
    ``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 found in the ":doc:`/contributor-guide/recipe-style-guide`"
+   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
@@ -915,7 +910,7 @@ The requirements for a released BSP that conform to the Yocto Project are:
    -  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
-      :doc:`/contributor-guide/submit-changes` section in the Yocto Project and
+      :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.
@@ -1182,7 +1177,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. ``linux-yocto_6.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
@@ -1247,7 +1242,7 @@ located in :yocto_git:`poky/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
 
    PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xorg"
 
-   MACHINE_EXTRA_RRECOMMENDS = "kernel-modules"
+   MACHINE_EXTRA_RRECOMMENDS = "kernel-modules kernel-devicetree"
 
    EXTRA_IMAGEDEPENDS += "virtual/bootloader"
 
@@ -1263,21 +1258,23 @@ located in :yocto_git:`poky/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
    SERIAL_CONSOLES ?= "115200;ttyS0 115200;ttyO0 115200;ttyAMA0"
 
    PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
-   PREFERRED_VERSION_linux-yocto ?= "6.12%"
+   PREFERRED_VERSION_linux-yocto ?= "6.1%"
 
    KERNEL_IMAGETYPE = "zImage"
-   DTB_FILES = "am335x-bone.dtb am335x-boneblack.dtb am335x-bonegreen.dtb"
-   KERNEL_DEVICETREE = '${@' '.join('ti/omap/%s' % d for d in '${DTB_FILES}'.split())}'
+   KERNEL_DEVICETREE = "am335x-bone.dtb am335x-boneblack.dtb am335x-bonegreen.dtb"
+   KERNEL_EXTRA_ARGS += "LOADADDR=${UBOOT_ENTRYPOINT}"
 
    PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot"
 
    SPL_BINARY = "MLO"
    UBOOT_SUFFIX = "img"
    UBOOT_MACHINE = "am335x_evm_defconfig"
+   UBOOT_ENTRYPOINT = "0x80008000"
+   UBOOT_LOADADDRESS = "0x80008000"
 
    MACHINE_FEATURES = "usbgadget usbhost vfat alsa"
 
-   IMAGE_BOOT_FILES ?= "u-boot.${UBOOT_SUFFIX} ${SPL_BINARY} ${KERNEL_IMAGETYPE} ${DTB_FILES}"
+   IMAGE_BOOT_FILES ?= "u-boot.${UBOOT_SUFFIX} ${SPL_BINARY} ${KERNEL_IMAGETYPE} ${KERNEL_DEVICETREE}"
 
    # support runqemu
    EXTRA_IMAGEDEPENDS += "qemu-native qemu-helper-native"
@@ -1331,12 +1328,12 @@ Project Reference Manual.
    needed in the root filesystem. In this case, the U-Boot recipe must
    be built for the image.
 
-   At the end of the file, we also use this setting to implement
+   At the end of the file, we also use this setings to implement
    ``runqemu`` support on the host machine.
 
 -  :term:`DEFAULTTUNE`: Machines
    use tunings to optimize machine, CPU, and application performance.
-   These features --- collectively known as "tuning features" ---
+   These features, which are collectively known as "tuning features",
    are set in the :term:`OpenEmbedded-Core (OE-Core)` layer. In this
    example, the default tuning file is :oe_git:`tune-cortexa8
    </openembedded-core/tree/meta/conf/machine/include/arm/armv7a/tune-cortexa8.inc>`.
@@ -1366,7 +1363,8 @@ Project Reference Manual.
    to create the sysroot when building a Wic image.
 
 -  :term:`SERIAL_CONSOLES`:
-   Defines one or more serial consoles (TTYs) to enable using getty.
+   Defines a serial console (TTY) to enable using getty. In this case,
+   the baud rate is "115200" and the device name is "ttyO0".
 
 -  :term:`PREFERRED_PROVIDER_virtual/kernel <PREFERRED_PROVIDER>`:
    Specifies the recipe that provides "virtual/kernel" when more than
@@ -1376,7 +1374,7 @@ Project Reference Manual.
 
 -  :term:`PREFERRED_VERSION_linux-yocto <PREFERRED_VERSION>`:
    Defines the version of the recipe used to build the kernel, which is
-   "6.12" in this case.
+   "6.1" in this case.
 
 -  :term:`KERNEL_IMAGETYPE`:
    The type of kernel to build for the device. In this case, the
@@ -1418,6 +1416,12 @@ Project Reference Manual.
       Specifies the value passed on the make command line when building
       a U-Boot image.
 
+   -  :term:`UBOOT_ENTRYPOINT`:
+      Specifies the entry point for the U-Boot image.
+
+   -  :term:`UBOOT_LOADADDRESS`:
+      Specifies the load address for the U-Boot image.
+
 -  :term:`MACHINE_FEATURES`:
    Specifies the list of hardware features the BeagleBone device is
    capable of supporting. In this case, the device supports "usbgadget

documentation/conf.py

@@ -13,7 +13,6 @@
 # documentation root, use os.path.abspath to make it absolute, like shown here.
 #
 import os
-import re
 import sys
 import datetime
 try:
@@ -174,24 +173,6 @@ latex_elements = {
     'preamble': '\\usepackage[UTF8]{ctex}\n\\setcounter{tocdepth}{2}',
 }
 
-
-from sphinx.search import SearchEnglish
-from sphinx.search import languages
-class DashFriendlySearchEnglish(SearchEnglish):
-
-    # Accept words that can include 'inner' hyphens or dots
-    _word_re = re.compile(r'[\w]+(?:[\.\-][\w]+)*')
-
-    js_splitter_code = r"""
-function splitQuery(query) {
-    return query
-        .split(/[^\p{Letter}\p{Number}_\p{Emoji_Presentation}\-\.]+/gu)
-        .filter(term => term.length > 0);
-}
-"""
-
-languages['en'] = DashFriendlySearchEnglish
-
 # Make the EPUB builder prefer PNG to SVG because of issues rendering Inkscape SVG
 from sphinx.builders.epub3 import Epub3Builder
 Epub3Builder.supported_image_types = ['image/png', 'image/gif', 'image/jpeg']

documentation/contributor-guide/submit-changes.rst

@@ -76,7 +76,7 @@ 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
+":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
@@ -776,38 +776,6 @@ argument to ``git format-patch`` with a version number::
 
    git format-patch -v2 <ref-branch>
 
-
-After generating updated patches (v2, v3, and so on) via ``git
-format-patch``, ideally developers will add a patch version changelog
-to each patch that describes what has changed between each revision of
-the patch. Add patch version changelogs after the ``---`` marker in the
-patch, indicating that this information is part of this patch, but is not
-suitable for inclusion in the commit message (i.e. the git history) itself.
-Providing a patch version changelog makes it easier for maintainers and
-reviewers to succinctly understand what changed in all versions of the
-patch, without having to consult alternate sources of information, such as
-searching through messages on a mailing list. For example::
-
-   <patch title>
-
-   <commit message>
-
-   <Signed-off-by/other trailers>
-   ---
-   changes in v4:
-   - provide a clearer commit message
-   - fix spelling mistakes
-
-   changes in v3:
-   - replace func() to use other_func() instead
-
-   changes in v2:
-   - this patch was added in v2
-   ---
-   <diffstat output>
-
-   <unified diff>
-
 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.
@@ -872,7 +840,7 @@ in regards to the use of generative AI tools. See:
 https://www.linuxfoundation.org/legal/generative-ai.
 
 All of the existing guidelines in this document are expected to be followed,
-including in the :doc:`/contributor-guide/recipe-style-guide`, and contributing the changes with
+including in the :doc:`recipe-style-guide`, and contributing the changes with
 additional requirements to the items in section
 :ref:`contributor-guide/submit-changes:Implement and commit changes`.
 

documentation/dev-manual/building.rst

@@ -48,7 +48,7 @@ The following figure and list overviews the build process:
    :width: 100%
 
 #. *Set up Your Host Development System to Support Development Using the
-   Yocto Project*: See the ":doc:`/dev-manual/start`" section for options on how to get a
+   Yocto Project*: See the ":doc:`start`" section for options on how to get a
    build host ready to use the Yocto Project.
 
 #. *Initialize the Build Environment:* Initialize the build environment
@@ -113,7 +113,7 @@ The following figure and list overviews the build process:
 Building Images for Multiple Targets Using Multiple Configurations
 ==================================================================
 
-See the :doc:`/dev-manual/multiconfig` section of the Yocto Project Development Tasks
+See the :doc:`multiconfig` section of the Yocto Project Development Tasks
 Manual.
 
 Building an Initial RAM Filesystem (Initramfs) Image
@@ -591,7 +591,7 @@ If build speed and package feed maintenance are considerations, you
 should consider the points in this section that can help you optimize
 your tunings to best consider build times and package feed maintenance.
 
--  *Share the* :term:`Build Directory` *:* If at all possible, share the
+-  *Share the :term:`Build Directory`:* If at all possible, share the
    :term:`TMPDIR` across builds. The Yocto Project supports switching between
    different :term:`MACHINE` values in the same :term:`TMPDIR`. This practice
    is well supported and regularly used by developers when building for
@@ -813,7 +813,7 @@ directory:
 
 #. *Using Local Files Only:* Inside your ``local.conf`` file, add the
    :term:`SOURCE_MIRROR_URL` variable, inherit the
-   :ref:`ref-classes-own-mirrors` class, and add the
+   :ref:`ref-classes-own-mirrors` class, and use the
    :term:`BB_NO_NETWORK` variable to your ``local.conf``::
 
       SOURCE_MIRROR_URL ?= "file:///home/your-download-dir/"

documentation/dev-manual/debugging.rst

@@ -36,7 +36,7 @@ section:
    use the BitBake ``-e`` option to examine variable values after a
    recipe has been parsed.
 
--  ":ref:`dev-manual/debugging:viewing package information with ``oe-pkgdata-util```"
+-  ":ref:`dev-manual/debugging:viewing package information with \`\`oe-pkgdata-util\`\``"
    describes how to use the ``oe-pkgdata-util`` utility to query
    :term:`PKGDATA_DIR` and
    display package-related information for built packages.
@@ -890,7 +890,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
-":doc:`/contributor-guide/submit-changes`" section for more information.
+":doc:`../contributor-guide/submit-changes`" section for more information.
 
 Debugging With the GNU Project Debugger (GDB) Remotely
 ======================================================
@@ -1261,7 +1261,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 ":doc:`/contributor-guide/report-defect`" section.
+   and the ":doc:`../contributor-guide/report-defect`" section.
 
    .. note::
 

documentation/dev-manual/devtool.rst

@@ -552,7 +552,7 @@ the two modes:
 
       This instance of VSCode uses plugins that are useful for the development
       of the application. ``devtool ide-sdk`` generates the necessary
-      ``extensions.json``, ``settings.json``, ``tasks.json`` and ``launch.json``
+      ``extensions.json``, ``settings.json``, ``tasks.json``and ``launch.json``
       configuration files for all the involved plugins.
 
       When the source code folder present in the workspace folder is opened in

documentation/dev-manual/disk-space.rst

@@ -52,7 +52,7 @@ such as BSD based NAS::
    sstate-cache-management.py --remove-duplicated --cache-dir=sstate-cache
 
 This command will ask you to confirm the deletions it identifies.
-Run ``sstate-cache-management.py`` for more details about this script.
+Run ``sstate-cache-management.sh`` for more details about this script.
 
 .. note::
 

documentation/dev-manual/efficiently-fetching-sources.rst

@@ -6,7 +6,7 @@ Efficiently Fetching Source Files During a Build
 The OpenEmbedded build system works with source files located through
 the :term:`SRC_URI` variable. When
 you build something using BitBake, a big part of the operation is
-locating and downloading all of the source code. For images,
+locating and downloading all the source tarballs. For images,
 downloading all the source for various packages can take a significant
 amount of time.
 
@@ -18,7 +18,7 @@ Setting up Effective Mirrors
 ============================
 
 A good deal that goes into a Yocto Project build is simply downloading
-source code. Maybe you have been working with another
+all of the source tarballs. Maybe you have been working with another
 build system for which you have built up a
 sizable directory of source tarballs. Or, perhaps someone else has such
 a directory for which you have read access. If so, you can save time by

documentation/dev-manual/index.rst

@@ -22,7 +22,6 @@ Yocto Project Development Tasks Manual
    building
    multiconfig
    speeding-up-build
-   limiting-resources
    libraries
    prebuilt-libraries
    devtool

documentation/dev-manual/init-manager.rst

@@ -44,7 +44,7 @@ therefore increasing the total system boot time. systemd also substantially
 increases system size because of its multiple components and the extra
 dependencies it pulls.
 
-By contrast, BusyBox init is the simplest and the lightest solution and
+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.
 

documentation/dev-manual/layers.rst

@@ -80,7 +80,7 @@ Follow these general steps to create your layer without using tools:
       BBFILE_PATTERN_yoctobsp = "^${LAYERDIR}/"
       BBFILE_PRIORITY_yoctobsp = "5"
       LAYERVERSION_yoctobsp = "4"
-      LAYERSERIES_COMPAT_yoctobsp = "walnascar"
+      LAYERSERIES_COMPAT_yoctobsp = "dunfell"
 
    Here is an explanation of the layer configuration file:
 
@@ -306,7 +306,7 @@ The Yocto Project Compatibility Program consists of a layer application
 process that requests permission to use the Yocto Project Compatibility
 Logo for your layer and application. The process consists of two parts:
 
-#. Successfully passing a script (``yocto-check-layer``) that, when run
+#. Successfully passing a script (``yocto-check-layer``) that when run
    against your layer, tests it against constraints based on experiences
    of how layers have worked in the real world and where pitfalls have
    been found. Getting a "PASS" result from the script is required for
@@ -478,7 +478,7 @@ name. To handle these errors, the best practice is to rename the ``.bbappend``
 to match the original recipe version. This also gives you the opportunity to see
 if the ``.bbappend`` is still relevant for the new version of the recipe.
 
-Another method is to use the character ``%`` in the ``.bbappend`` filename. For
+Another method it to use the character ``%`` in the ``.bbappend`` filename. For
 example, to append information to every ``6.*`` minor versions of the recipe
 ``someapp``, the ``someapp_6.%.bbappend`` file can be created. This way, an
 error will only be triggered if the ``someapp`` recipe has a major version
@@ -504,9 +504,10 @@ the "meta" layer at ``meta/recipes-bsp/formfactor``::
    SECTION = "base"
    LICENSE = "MIT"
    LIC_FILES_CHKSUM = "file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
+   PR = "r45"
 
    SRC_URI = "file://config file://machconfig"
-   S = "${UNPACKDIR}"
+   S = "${WORKDIR}"
 
    PACKAGE_ARCH = "${MACHINE_ARCH}"
    INHIBIT_DEFAULT_DEPS = "1"
@@ -581,10 +582,11 @@ Directory`.  Here is the main ``xserver-xf86-config`` recipe, which is named
    SECTION = "x11/base"
    LICENSE = "MIT"
    LIC_FILES_CHKSUM = "file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
+   PR = "r33"
 
    SRC_URI = "file://xorg.conf"
 
-   S = "${UNPACKDIR}"
+   S = "${WORKDIR}"
 
    CONFFILES:${PN} = "${sysconfdir}/X11/xorg.conf"
 
@@ -592,9 +594,9 @@ Directory`.  Here is the main ``xserver-xf86-config`` recipe, which is named
    ALLOW_EMPTY:${PN} = "1"
 
    do_install () {
-        if test -s ${UNPACKDIR}/xorg.conf; then
+        if test -s ${WORKDIR}/xorg.conf; then
                 install -d ${D}/${sysconfdir}/X11
-                install -m 0644 ${UNPACKDIR}/xorg.conf ${D}/${sysconfdir}/X11/
+                install -m 0644 ${WORKDIR}/xorg.conf ${D}/${sysconfdir}/X11/
         fi
    }
 
@@ -612,8 +614,8 @@ file is in the layer at ``recipes-graphics/xorg-xserver``::
        PITFT="${@bb.utils.contains("MACHINE_FEATURES", "pitft", "1", "0", d)}"
        if [ "${PITFT}" = "1" ]; then
            install -d ${D}/${sysconfdir}/X11/xorg.conf.d/
-           install -m 0644 ${UNPACKDIR}/xorg.conf.d/98-pitft.conf ${D}/${sysconfdir}/X11/xorg.conf.d/
-           install -m 0644 ${UNPACKDIR}/xorg.conf.d/99-calibration.conf ${D}/${sysconfdir}/X11/xorg.conf.d/
+           install -m 0644 ${WORKDIR}/xorg.conf.d/98-pitft.conf ${D}/${sysconfdir}/X11/xorg.conf.d/
+           install -m 0644 ${WORKDIR}/xorg.conf.d/99-calibration.conf ${D}/${sysconfdir}/X11/xorg.conf.d/
        fi
    }
 

documentation/dev-manual/libraries.rst

@@ -37,10 +37,40 @@ library files.
    Some previously released versions of the Yocto Project defined the
    static library files through ``${PN}-dev``.
 
-Here is a small part of the BitBake configuration file, where you can see
+Here is the part of the BitBake configuration file, where you can see
 how the static library files are defined::
 
+   PACKAGE_BEFORE_PN ?= ""
    PACKAGES = "${PN}-src ${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale ${PACKAGE_BEFORE_PN} ${PN}"
+   PACKAGES_DYNAMIC = "^${PN}-locale-.*"
+   FILES = ""
+
+   FILES:${PN} = "${bindir}/* ${sbindir}/* ${libexecdir}/* ${libdir}/lib*${SOLIBS} \
+               ${sysconfdir} ${sharedstatedir} ${localstatedir} \
+               ${base_bindir}/* ${base_sbindir}/* \
+               ${base_libdir}/*${SOLIBS} \
+               ${base_prefix}/lib/udev ${prefix}/lib/udev \
+               ${base_libdir}/udev ${libdir}/udev \
+               ${datadir}/${BPN} ${libdir}/${BPN}/* \
+               ${datadir}/pixmaps ${datadir}/applications \
+               ${datadir}/idl ${datadir}/omf ${datadir}/sounds \
+               ${libdir}/bonobo/servers"
+
+   FILES:${PN}-bin = "${bindir}/* ${sbindir}/*"
+
+   FILES:${PN}-doc = "${docdir} ${mandir} ${infodir} ${datadir}/gtk-doc \
+               ${datadir}/gnome/help"
+   SECTION:${PN}-doc = "doc"
+
+   FILES_SOLIBSDEV ?= "${base_libdir}/lib*${SOLIBSDEV} ${libdir}/lib*${SOLIBSDEV}"
+   FILES:${PN}-dev = "${includedir} ${FILES_SOLIBSDEV} ${libdir}/*.la \
+                   ${libdir}/*.o ${libdir}/pkgconfig ${datadir}/pkgconfig \
+                   ${datadir}/aclocal ${base_libdir}/*.o \
+                   ${libdir}/${BPN}/*.la ${base_libdir}/*.la \
+                   ${libdir}/cmake ${datadir}/cmake"
+   SECTION:${PN}-dev = "devel"
+   ALLOW_EMPTY:${PN}-dev = "1"
+   RDEPENDS:${PN}-dev = "${PN} (= ${EXTENDPKGV})"
 
    FILES:${PN}-staticdev = "${libdir}/*.a ${base_libdir}/*.a ${libdir}/${BPN}/*.a"
    SECTION:${PN}-staticdev = "devel"

documentation/dev-manual/licenses.rst

@@ -55,11 +55,11 @@ Consider this next example::
 
    LIC_FILES_CHKSUM = "file://src/ls.c;beginline=5;endline=16;\
                                        md5=bb14ed3c4cda583abc85401304b5cd4e"
-   LIC_FILES_CHKSUM = "file://${UNPACKDIR}/license.html;md5=5c94767cedb5d6987c902ac850ded2c6"
+   LIC_FILES_CHKSUM = "file://${WORKDIR}/license.html;md5=5c94767cedb5d6987c902ac850ded2c6"
 
 The first line locates a file in ``${S}/src/ls.c`` and isolates lines
 five through 16 as license text. The second line refers to a file in
-:term:`UNPACKDIR`.
+:term:`WORKDIR`.
 
 Note that :term:`LIC_FILES_CHKSUM` variable is mandatory for all recipes,
 unless the :term:`LICENSE` variable is set to "CLOSED".

documentation/dev-manual/limiting-resources.rst

@@ -1,138 +0,0 @@
-.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
-
-Limiting the Host Resources Usage
-*********************************
-
-While you sometimes need to :doc:`speed up a build
-</dev-manual/speeding-up-build>`, you may also need to limit the resources used
-by the :term:`OpenEmbedded Build System`, especially on shared infrastructures
-where multiple users start heavy-load builds, or when building on low-power
-machines.
-
-This document aims at giving the different configuration variables available to
-limit the resources used by the build system. These variables should be set from
-a :term:`configuration file` and thus take effect over the entire build environment.
-For each variable, also see the variable description in the glossary for more
-details.
-
--  :term:`BB_NUMBER_THREADS`:
-
-   This sets a hard limit on the number of threads :term:`BitBake` can run at the
-   same time. Lowering this value will set a limit to the number of
-   :term:`BitBake` threads, but will not prevent a single task from starting more
-   compilation threads (see :term:`PARALLEL_MAKE`).
-
--  :term:`BB_NUMBER_PARSE_THREADS`:
-
-   Like :term:`BB_NUMBER_THREADS`, but this variable sets a limit on the number
-   of threads during the parsing of the environment (before executing tasks).
-
--  :term:`PARALLEL_MAKE`:
-
-   This variable should be set in the form of ``-jN``, where ``N`` is a positive
-   integer. This integer controls the number of threads used when starting
-   ``make``. Note that this variable is not limited to the usage of ``make``,
-   but extends to the compilation (:ref:`ref-tasks-compile` task) commands
-   defined by the :ref:`ref-classes-meson`, :ref:`ref-classes-cmake` and such
-   classes.
-
-   If you want to have a different limit from the rest of the build for a
-   recipe, it is also possible to achieve with the following line added to your
-   ``local.conf`` :term:`configuration file`::
-
-      PARALLEL_MAKE:pn-linux-yocto = "-j4"
-
-   The above example will limit the number of threads used by ``make`` for the
-   ``linux-yocto`` recipe to 4.
-
--  :term:`PARALLEL_MAKEINST`:
-
-   Like :term:`PARALLEL_MAKE`, but this variable controls the number of threads
-   used during the :ref:`ref-tasks-install` task.
-
-   The default value of :term:`PARALLEL_MAKEINST` is the value of
-   :term:`PARALLEL_MAKE`.
-
-.. note::
-
-   While most of the variables in this document help to limit the CPU load, it
-   is also possible that the host system runs out of physical RAM when running
-   builds. This can trigger the out-of-memory killer and stop the related
-   processes abruptly. This can create strange looking failures in the output
-   log of the tasks in question. The out-of-memory killer only logs in the
-   kernel dmesg logs, so it is advised to monitor it closely with the ``dmesg``
-   command when encountering unexpected failures during builds.
-
-   In these situations, lowering the value of :term:`PARALLEL_MAKE` and
-   :term:`BB_NUMBER_THREADS` is recommended.
-
--  :term:`BB_PRESSURE_MAX_CPU`, :term:`BB_PRESSURE_MAX_IO` and
-   :term:`BB_PRESSURE_MAX_MEMORY`:
-
-   These variables control the limit of pressure (PSI as defined by
-   https://docs.kernel.org/accounting/psi.html) on the system, and will
-   limit the number of :term:`BitBake` threads dynamically depending on the
-   current pressure of the system. This also means that your host must support
-   the PSI kernel feature (otherwise see :term:`BB_LOADFACTOR_MAX` below).
-
-   These variables take a positive integer between 1 (extremely low limit) and
-   1000000 (value unlikely ever reached). Setting an extremely low value, such
-   as 2, is not desirable as it will result in :term:`BitBake` limiting the
-   number of threads to 1 most of the time.
-
-   To determine a reasonable value to set for your host, follow the steps below:
-
-   #. In a Bash shell, start the following script, which will provide an
-      estimate of the current pressure on your host:
-
-      .. code-block:: bash
-
-         pressure="0"
-         while true; do
-            prev_pressure="$pressure"
-            pressure=$(head -1 /proc/pressure/cpu  | cut -d' ' -f5 | cut -d'=' -f2)
-            echo $(( $pressure - $prev_pressure ))
-            sleep 1
-         done
-
-      .. note::
-
-         Change ``/proc/pressure/cpu`` to ``/proc/pressure/io`` or
-         ``/proc/pressure/memory`` to change the pressure type to monitor.
-
-      This script can be stopped by pressing Control + C.
-
-   #.  Then, start a heavy-load build, for example::
-
-          bitbake virtual/kernel -c compile -f
-
-       You can stop the build at anytime with Control + C.
-
-   #.  Monitor the values printed on the console. These should indicate how the
-       pressure evolves during the build. You can take a value below the maximum
-       printed value as a starting point.
-
-   After setting initial values, :term:`BitBake` will print messages on the
-   console in the following format each time the current pressure exceeds of the
-   limit set by the above variables::
-
-      Pressure status changed to CPU: True, IO: False, Mem: False (CPU: 1105.9/2.0, IO: 0.0/2.0, Mem: 0.0/2.0) - using 1/64 bitbake threads
-
-   Take a look at the value between parenthesis: ``CPU: 1105.9/2.0, IO: 0.0/2.0,
-   Mem: 0.0/2.0``. They correspond to the current pressure value for the CPU, IO
-   and memory respectively. If :term:`BitBake` prints these messages a lot, it
-   is likely that your pressure limit is too low, and thus can be raised to a
-   higher value.
-
--  :term:`BB_LOADFACTOR_MAX`:
-
-   This variable will limit the number of threads :term:`BitBake` will start
-   by monitoring the current CPU load of the host system. :term:`BitBake` will
-   print the following when the limit set by :term:`BB_LOADFACTOR_MAX` is
-   reached::
-
-      Load average limiting set to True as load average: 0.7188262939453125 - using 37/64 bitbake threads
-
-   This variable has no effect when any of :term:`BB_PRESSURE_MAX_CPU`,
-   :term:`BB_PRESSURE_MAX_IO` or :term:`BB_PRESSURE_MAX_MEMORY` is set, as it
-   was designed for systems that do not have pressure information available.

documentation/dev-manual/new-recipe.rst

@@ -56,7 +56,7 @@ necessary when adding a recipe to build a new piece of software to be
 included in a build.
 
 You can find a complete description of the ``devtool add`` command in
-the ":ref:`dev-manual/devtool:a closer look at ``devtool add```" section
+the ":ref:`dev-manual/devtool:a closer look at \`\`devtool add\`\``" section
 in the Yocto Project Application Development and the Extensible Software
 Development Kit (eSDK) manual.
 
@@ -188,14 +188,13 @@ the recipe.
    Use lower-cased characters and do not include the reserved suffixes
    ``-native``, ``-cross``, ``-initial``, or ``-dev`` casually (i.e. do not use
    them as part of your recipe name unless the string applies). Here are some
-   examples (which includes the use of the string "git" as a special case of a
-   version identifier):
+   examples:
 
    .. code-block:: none
 
-      cups_2.4.12.bb
-      gawk_5.3.2.bb
-      psplash_git.bb
+      cups_1.7.0.bb
+      gawk_4.0.2.bb
+      irssi_0.8.16-rc1.bb
 
 Running a Build on the Recipe
 =============================
@@ -277,11 +276,11 @@ upgrading the recipe to a future version is as simple as renaming the
 recipe to match the new version.
 
 Here is a simple example from the
-:oe_git:`strace recipe </openembedded-core/tree/meta/recipes-devtools/strace>`
-where the source comes from a single tarball. Notice the use of the
+``meta/recipes-devtools/strace/strace_5.5.bb`` recipe where the source
+comes from a single tarball. Notice the use of the
 :term:`PV` variable::
 
-   SRC_URI = "${GITHUB_BASE_URI}/download/v${PV}/strace-${PV}.tar.xz \
+   SRC_URI = "https://strace.io/files/${PV}/strace-${PV}.tar.xz \
 
 Files mentioned in :term:`SRC_URI` whose names end in a typical archive
 extension (e.g. ``.tar``, ``.tar.gz``, ``.tar.bz2``, ``.zip``, and so
@@ -293,7 +292,7 @@ another example that specifies these types of files, see the
 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
 a ``+`` sign in its definition. Here is an example from the recipe
-:oe_git:`l3afpad_git.bb </openembedded-core/tree/meta/recipes-sato/l3afpad/l3afpad_git.bb>`::
+:oe_git:`meta/recipes-sato/l3afpad/l3afpad_git.bb </openembedded-core/tree/meta/recipes-sato/l3afpad/l3afpad_git.bb>`::
 
    SRC_URI = "git://github.com/stevenhoneyman/l3afpad.git;branch=master;protocol=https"
 
@@ -348,8 +347,8 @@ paste them into your recipe and then run the build again to continue.
    continuing with the build.
 
 This final example is a bit more complicated and is from the
-:oe_git:`rxvt-unicode </openembedded-core/tree/meta/recipes-sato/rxvt-unicode>`
-recipe. The example's :term:`SRC_URI` statement identifies multiple files as the source
+``meta/recipes-sato/rxvt-unicode/rxvt-unicode_9.20.bb`` recipe. The
+example's :term:`SRC_URI` statement identifies multiple files as the source
 files for the recipe: a tarball, a patch file, a desktop file, and an icon::
 
    SRC_URI = "http://dist.schmorp.de/rxvt-unicode/Attic/rxvt-unicode-${PV}.tar.bz2 \
@@ -707,7 +706,7 @@ hierarchy to locations that would mirror their locations on the target
 device. The installation process copies files from the
 ``${``\ :term:`S`\ ``}``,
 ``${``\ :term:`B`\ ``}``, and
-``${``\ :term:`UNPACKDIR`\ ``}``
+``${``\ :term:`WORKDIR`\ ``}``
 directories to the ``${``\ :term:`D`\ ``}``
 directory to create the structure as it should appear on the target
 system.
@@ -1146,7 +1145,7 @@ 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:`UNPACKDIR` in this
+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"
@@ -1156,7 +1155,7 @@ case --- the directory BitBake uses for the build::
 
    SRC_URI = "file://helloworld.c"
 
-   S = "${UNPACKDIR}"
+   S = "${WORKDIR}"
 
    do_compile() {
        ${CC} ${LDFLAGS} helloworld.c -o helloworld
@@ -1212,6 +1211,8 @@ In the following example, ``lz4`` is a makefile-based package::
               "
    UPSTREAM_CHECK_GITTAGREGEX = "v(?P<pver>.*)"
 
+   S = "${WORKDIR}/git"
+
    CVE_STATUS[CVE-2014-4715] = "fixed-version: Fixed in r118, which is larger than the current version"
 
    EXTRA_OEMAKE = "PREFIX=${prefix} CC='${CC}' CFLAGS='${CFLAGS}' DESTDIR=${D} LIBDIR=${libdir} INCLUDEDIR=${includedir} BUILD_STATIC=no"
@@ -1270,6 +1271,8 @@ is a simple example of an application without dependencies::
    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
@@ -1394,31 +1397,11 @@ doing the following:
    where you have installed them and whether those files are in
    different locations than the defaults.
 
-As a basic example of a :ref:`ref-classes-bin-package`-style recipe, consider
-this snippet from the
-:oe_git:`wireless-regdb </openembedded-core/tree/meta/recipes-kernel/wireless-regdb>`
-recipe file, which fetches a single tarball of binary content and manually
-installs with no need for any configuration or compilation::
-
-   SRC_URI = "https://www.kernel.org/pub/software/network/${BPN}/${BP}.tar.xz"
-   SRC_URI[sha256sum] = "57f8e7721cf5a880c13ae0c202edbb21092a060d45f9e9c59bcd2a8272bfa456"
-
-   inherit bin_package allarch
-
-   do_install() {
-       install -d -m0755 ${D}${nonarch_libdir}/crda
-       install -d -m0755 ${D}${sysconfdir}/wireless-regdb/pubkeys
-       install -m 0644 regulatory.bin ${D}${nonarch_libdir}/crda/regulatory.bin
-       install -m 0644 wens.key.pub.pem ${D}${sysconfdir}/wireless-regdb/pubkeys/wens.key.pub.pem
-       install -m 0644 -D regulatory.db ${D}${nonarch_base_libdir}/firmware/regulatory.db
-       install -m 0644 regulatory.db.p7s ${D}${nonarch_base_libdir}/firmware/regulatory.db.p7s
-   }
-
 Following Recipe Style Guidelines
 =================================
 
 When writing recipes, it is good to conform to existing style guidelines.
-See the ":doc:`/contributor-guide/recipe-style-guide`" in the Yocto Project
+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.
@@ -1445,7 +1428,7 @@ chapter of the BitBake User Manual.
    The following example shows some of the ways you can use variables in
    recipes::
 
-      S = "${UNPACKDIR}/postfix-${PV}"
+      S = "${WORKDIR}/postfix-${PV}"
       CFLAGS += "-DNO_ASM"
       CFLAGS:append = " --enable-important-feature"
 

documentation/dev-manual/packages.rst

@@ -1024,7 +1024,7 @@ The ``devtool edit-recipe`` command lets you take a look at the recipe::
        npmsw://${THISDIR}/${BPN}/npm-shrinkwrap.json \
        "
 
-   S = "${UNPACKDIR}/npm"
+   S = "${WORKDIR}/npm"
 
    inherit npm
 

documentation/dev-manual/prebuilt-libraries.rst

@@ -97,7 +97,7 @@ The complete recipe would look like this::
    # we use a local link.
    SRC_URI = "file://libft4222-linux-${PV}.tgz"
 
-   S = "${UNPACKDIR}"
+   S = "${WORKDIR}"
 
    ARCH_DIR:x86-64 = "build-x86_64"
    ARCH_DIR:i586 = "build-i386"
@@ -170,7 +170,7 @@ as follows::
 The modifications cause the ``.so`` file to be the real library
 and unset :term:`FILES_SOLIBSDEV` so that no libraries get packaged into
 ``${PN}-dev``. The changes are required because unless :term:`PACKAGES` is changed,
-``${PN}-dev`` collects files before ``${PN}``. ``${PN}-dev`` must not collect any of
+``${PN}-dev`` collects files before `${PN}`. ``${PN}-dev`` must not collect any of
 the files you want in ``${PN}``.
 
 Finally, loadable modules, essentially unversioned libraries that are linked
@@ -204,6 +204,6 @@ versioned library example. The "magic" is setting the :term:`SOLIBS` and
 
    do_install () {
            install -d ${D}${libdir}
-           install -m 0755 ${UNPACKDIR}/libfoo.so ${D}${libdir}
+           install -m 0755 ${WORKDIR}/libfoo.so ${D}${libdir}
    }
 

documentation/dev-manual/sbom.rst

@@ -24,20 +24,12 @@ users can read in standardized format.
 :term:`SBOM` information is also critical to performing vulnerability exposure
 assessments, as all the components used in the Software Supply Chain are listed.
 
-The OpenEmbedded build system doesn't generate such information by default,
-though the :term:`Poky` reference distribution has it enabled out of the box.
-
-To enable it, inherit the :ref:`ref-classes-create-spdx` class from a
-configuration file::
+The OpenEmbedded build system doesn't generate such information by default.
+To make this happen, you must inherit the
+:ref:`ref-classes-create-spdx` class from a configuration file::
 
    INHERIT += "create-spdx"
 
-In the :term:`Poky` reference distribution, :term:`SPDX` generation does
-consume some build time resources and thus if needed it can be disabled from a
-:term:`configuration file`::
-
-   INHERIT:remove = "create-spdx"
-
 Upon building an image, you will then get:
 
 -  :term:`SPDX` output in JSON format as an ``IMAGE-MACHINE.spdx.json`` file in
@@ -60,9 +52,6 @@ more information in the output :term:`SPDX` data:
 -  Add a description of the source files used to generate host tools and target
    packages (:term:`SPDX_INCLUDE_SOURCES`)
 
--  Add a description of the **compiled** source files used to generate host tools
-   and target packages (:term:`SPDX_INCLUDE_COMPILED_SOURCES`)
-
 -  Add archives of these source files themselves (:term:`SPDX_ARCHIVE_SOURCES`).
 
 Though the toplevel :term:`SPDX` output is available in

documentation/dev-manual/start.rst

@@ -109,7 +109,7 @@ particular working environment and set of practices.
 
     -  Keep your cross-development toolchains updated. You can do this
        through provisioning either as new toolchain downloads or as
-       updates through a package update mechanism to
+       updates through a package update mechanism using ``opkg`` to
        provide updates to an existing toolchain. The exact mechanics of
        how and when to do this depend on local policy.
 
@@ -159,7 +159,7 @@ particular working environment and set of practices.
        are made.
 
     -  Allows triggering of automated image booting and testing under
-       the Quick EMUlator (QEMU).
+       the QuickEMUlator (QEMU).
 
     -  Supports incremental build testing and from-scratch builds.
 
@@ -228,24 +228,13 @@ particular working environment and set of practices.
        used by developers in the same organization and share the same
        source directories on their machines.
 
-    -  Set up a local :ref:`overview-manual/concepts:Hash Equivalence` server
-       with :term:`BB_HASHSERVE` and :term:`BB_SIGNATURE_HANDLER`. A basic setup
-       would be::
-
-          BB_HASHSERVE = "auto"
-          BB_SIGNATURE_HANDLER = "OEEquivHash"
-
-       See the :ref:`overview-manual/concepts:Hash Equivalence` section of the
-       Yocto Project Overview and Concepts Manual for more details on the hash
-       equivalence feature.
-
     -  Set up an Autobuilder and have it populate the sstate cache and
        source directories.
 
     -  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 ":doc:`/contributor-guide/submit-changes`"
+       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
@@ -321,7 +310,7 @@ Project Build Host:
 
    -  GNU make &MIN_MAKE_VERSION; or greater
 
-   If your build host does not satisfy all of these listed version
+   If your build host does not meet any of these listed version
    requirements, you can take steps to prepare the system so that you
    can still use the Yocto Project. See the
    ":ref:`ref-manual/system-requirements:required git, tar, python, make and gcc versions`"
@@ -579,7 +568,7 @@ extension accordingly.
 Locating Yocto Project Source Files
 ===================================
 
-This section shows you how to locate, fetch, unpack, patch and configure the source
+This section shows you how to locate, fetch and configure the source
 files you'll need to work with the Yocto Project.
 
 .. note::
@@ -731,11 +720,11 @@ Follow these steps to create a local version of the upstream
       $ git branch
       * master
 
-   Your local repository of poky is initially identical to the
-   upstream poky repository from which it was cloned. As you
+   Your local repository of poky is identical to the
+   upstream poky repository at the time from which it was cloned. As you
    work with the local branch, you can periodically use the
-   ``git pull`` command to be sure you stay up-to-date
-   with the upstream poky branch.
+   ``git pull --rebase`` command to be sure you are up-to-date
+   with the upstream branch.
 
 Checking Out by Branch in Poky
 ------------------------------
@@ -869,9 +858,9 @@ Initializing the Build Environment
 ==================================
 
 Before you can use Yocto you need to setup the build environment.
-From within the ``poky`` directory, source the :ref:`ref-manual/structure:``oe-init-build-env``` environment
+From within the ``poky`` directory, source the :ref:`ref-manual/structure:\`\`oe-init-build-env\`\`` environment
 setup script to define Yocto Project's build environment on your build host::
-
-   $ source oe-init-build-env
+    
+    $ source oe-init-build-env 
 
 Note, that this step will have to be repeated every time you open a new shell.

documentation/dev-manual/temporary-source-code.rst

@@ -18,10 +18,11 @@ build packages is available in the :term:`Build Directory` as defined by the
 defined in the ``meta/conf/bitbake.conf`` configuration file in the
 :term:`Source Directory`::
 
-   S = "${UNPACKDIR}/${BP}"
+   S = "${WORKDIR}/${BP}"
 
 You should be aware that many recipes override the
-:term:`S` variable when the default isn't accurate.
+:term:`S` variable. For example, recipes that fetch their source from Git
+usually set :term:`S` to ``${WORKDIR}/git``.
 
 .. note::
 
@@ -30,16 +31,8 @@ You should be aware that many recipes override the
 
            BP = "${BPN}-${PV}"
 
-   This matches the location that the git fetcher unpacks to, and usually
-   matches unpacked content of release tarballs (e.g. they contain a single
-   directory which matches value of ${BP} exactly).
 
-The path to the unpack directory for the recipe
-(:term:`UNPACKDIR`) is defined as follows::
-
-   ${WORKDIR}/sources
-
-In turn, the path to the work directory for the recipe
+The path to the work directory for the recipe
 (:term:`WORKDIR`) is defined as
 follows::
 

documentation/dev-manual/upgrading-recipes.rst

@@ -333,7 +333,7 @@ Manually Upgrading a Recipe
 
 If for some reason you choose not to upgrade recipes using
 :ref:`dev-manual/upgrading-recipes:Using the Auto Upgrade Helper (AUH)` or
-by :ref:`dev-manual/upgrading-recipes:Using ``devtool upgrade```,
+by :ref:`dev-manual/upgrading-recipes:Using \`\`devtool upgrade\`\``,
 you can manually edit the recipe files to upgrade the versions.
 
 .. 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 ":doc:`/contributor-guide/submit-changes`" for details.
+patches to fix them, see ":doc:`../contributor-guide/submit-changes`" for details.
 
 Vulnerability check at build time
 =================================

documentation/kernel-dev/common.rst

@@ -672,7 +672,7 @@ The steps in this procedure show you how you can patch the kernel using
 
    Before attempting this procedure, be sure you have performed the
    steps to get ready for updating the kernel as described in the
-   ":ref:`kernel-dev/common:getting ready to develop using ``devtool```"
+   ":ref:`kernel-dev/common:getting ready to develop using \`\`devtool\`\``"
    section.
 
 Patching the kernel involves changing or adding configurations to an
@@ -685,7 +685,7 @@ output at boot time through ``printk`` statements in the kernel's
 ``calibrate.c`` source code file. Applying the patch and booting the
 modified image causes the added messages to appear on the emulator's
 console. The example is a continuation of the setup procedure found in
-the ":ref:`kernel-dev/common:getting ready to develop using ``devtool```" Section.
+the ":ref:`kernel-dev/common:getting ready to develop using \`\`devtool\`\``" Section.
 
 #. *Check Out the Kernel Source Files:* First you must use ``devtool``
    to checkout the kernel source code in its workspace.
@@ -693,7 +693,7 @@ the ":ref:`kernel-dev/common:getting ready to develop using ``devtool```" Sectio
    .. note::
 
       See this step in the
-      ":ref:`kernel-dev/common:getting ready to develop using ``devtool```"
+      ":ref:`kernel-dev/common:getting ready to develop using \`\`devtool\`\``"
       section for more information.
 
    Use the following ``devtool`` command to check out the code::
@@ -804,7 +804,7 @@ the ":ref:`kernel-dev/common:getting ready to develop using ``devtool```" Sectio
    .. note::
 
       See Step 3 of the
-      ":ref:`kernel-dev/common:getting ready to develop using ``devtool```"
+      ":ref:`kernel-dev/common:getting ready to develop using \`\`devtool\`\``"
       section for information on setting up this layer.
 
    Once the command
@@ -1190,7 +1190,7 @@ appear in the ``.config`` file, which is in the :term:`Build Directory`.
 
    For more information about where the ``.config`` file is located, see the
    example in the
-   ":ref:`kernel-dev/common:using ``menuconfig```"
+   ":ref:`kernel-dev/common:using \`\`menuconfig\`\``"
    section.
 
 It is simple to create a configuration fragment. One method is to use
@@ -1286,7 +1286,7 @@ when you override a policy configuration in a hardware configuration
 fragment.
 
 In order to run this task, you must have an existing ``.config`` file.
-See the ":ref:`kernel-dev/common:using ``menuconfig```" section for
+See the ":ref:`kernel-dev/common:using \`\`menuconfig\`\``" section for
 information on how to create a configuration file.
 
 Here is sample output from the :ref:`ref-tasks-kernel_configcheck` task:
@@ -1359,7 +1359,7 @@ and
 tasks until they produce no warnings.
 
 For more information on how to use the ``menuconfig`` tool, see the
-:ref:`kernel-dev/common:using ``menuconfig``` section.
+:ref:`kernel-dev/common:using \`\`menuconfig\`\`` section.
 
 Fine-Tuning the Kernel Configuration File
 -----------------------------------------

documentation/kernel-dev/intro.rst

@@ -122,7 +122,7 @@ general information and references for further information.
    Using ``devtool`` requires that you have a clean build
    of the image. For
    more information, see the
-   ":ref:`kernel-dev/common:getting ready to develop using ``devtool```"
+   ":ref:`kernel-dev/common:getting ready to develop using \`\`devtool\`\``"
    section.
 
    Using traditional kernel development requires that you have the

documentation/migration-guides/index.rst

@@ -12,7 +12,6 @@ to move to one release of the Yocto Project from the previous one.
 .. toctree::
 
    migration-general
-   release-5.3
    release-5.2
    release-5.1
    release-5.0

documentation/migration-guides/migration-5.1.rst

@@ -20,7 +20,8 @@ S = ${WORKDIR} no longer supported
 If a recipe has :term:`S` set to be :term:`WORKDIR`, this is no longer
 supported, and an error will be issued. The recipe should be changed to::
 
-    S = "${UNPACKDIR}"
+    S = "${WORKDIR}/sources"
+    UNPACKDIR = "${S}"
 
 Any :term:`WORKDIR` references where files from :term:`SRC_URI` are referenced
 should be changed to :term:`S`. These are commonly in :ref:`ref-tasks-compile`,
@@ -61,7 +62,8 @@ require to add an :term:`S` definition to a recipe that only uses
 ``file://`` :term:`SRC_URI` entries. To be consistent, the following pattern is
 recommended::
 
-    S = "${UNPACKDIR}"
+    S = "${WORKDIR}/sources"
+    UNPACKDIR = "${S}"
 
 Building C files from :term:`UNPACKDIR` without setting :term:`S` to point at
 it does not work as the debug prefix mapping doesn't handle that.

documentation/migration-guides/migration-5.2.rst

@@ -83,7 +83,7 @@ systemd changes
    files by starting them via
    `Also <https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html#Also=>`__,
    the other service files were automatically added to the :term:`FILES` variable of
-   the same package. Example:
+   the same package. Example: 
 
    a.service contains::
 

documentation/migration-guides/migration-5.3.rst

@@ -1,160 +0,0 @@
-.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
-
-.. |yocto-codename| replace:: whinlatter
-.. |yocto-ver| replace:: 5.3
-.. Note: anchors id below cannot contain substitutions so replace them with the
-   value of |yocto-ver| above.
-
-Release |yocto-ver| (|yocto-codename|)
-======================================
-
-Migration notes for |yocto-ver| (|yocto-codename|)
---------------------------------------------------
-
-This section provides migration information for moving to the Yocto
-Project |yocto-ver| Release (codename "|yocto-codename|") from the prior release.
-
-:term:`WORKDIR` changes
-~~~~~~~~~~~~~~~~~~~~~~~
-
-``S = ${WORKDIR}/something`` no longer supported
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-If a recipe has :term:`S` set to be ``${``\ :term:`WORKDIR`\ ``}/something``,
-this is no longer supported, and an error will be issued. The recipe should be
-changed to::
-
-   S = "${UNPACKDIR}/something"
-
-``S = ${WORKDIR}/git`` and ``S = ${UNPACKDIR}/git`` should be removed
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The Git fetcher now unpacks into the :term:`BB_GIT_DEFAULT_DESTSUFFIX` directory
-rather than the ``git/`` directory under :term:`UNPACKDIR`.
-:term:`BB_GIT_DEFAULT_DESTSUFFIX` is set in :term:`OpenEmbedded-Core
-(OE-Core)`'s :oe_git:`bitbake.conf
-</openembedded-core/tree/meta/conf/bitbake.conf>` to :term:`BP`.
-
-This location matches the default value of :term:`S` set by bitbake.conf, so :term:`S`
-setting in recipes can and should be removed.
-
-Note that when :term:`S` is set to a subdirectory of the git checkout, then it
-should be instead adjusted according to the previous point::
-
-   S = "${UNPACKDIR}/${BP}/something"
-
-Note that "git" as the source checkout location can be hardcoded
-in other places in recipes; when it's in :term:`SRC_URI`, replace with
-:term:`BB_GIT_DEFAULT_DESTSUFFIX`, otherwise replace with :term:`BP`.
-
-How to make those adjustments without tedious manual editing
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-The following sed command can be used to remove S = "${WORKDIR}/git
-across a whole layer::
-
-   sed -i "/^S = \"\${WORKDIR}\/git\"/d" `find . -name *.bb -o -name *.inc -o -name *.bbclass`
-
-Then, the following command can tweak the remaining :term:`S` assignments to
-refer to :term:`UNPACKDIR` instead of :term:`WORKDIR`::
-
-   sed -i "s/^S = \"\${WORKDIR}\//S = \"\${UNPACKDIR}\//g" `find . -name *.bb -o -name *.inc -o -name *.bbclass`
-
-The first change can introduce a lot of consecutive empty lines, so those can be removed with::
-
-   sed -i -z -E 's/([ \t\f\v\r]*\n){3,}/\n\n/g' `find . -name *.bb -o -name *.inc`
-
-Supported kernel versions
-~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The :term:`OLDEST_KERNEL` setting is XXX in this release, meaning that
-out the box, older kernels are not supported. See :ref:`4.3 migration notes
-<migration-4.3-supported-kernel-versions>` for details.
-
-Supported distributions
-~~~~~~~~~~~~~~~~~~~~~~~
-
-Compared to the previous releases, running BitBake is supported on new
-GNU/Linux distributions:
-
--  XXX
-
-On the other hand, some earlier distributions are no longer supported:
-
--  XXX
-
-See :ref:`all supported distributions <system-requirements-supported-distros>`.
-
-Rust language changes
-~~~~~~~~~~~~~~~~~~~~~
-
-systemd changes
-~~~~~~~~~~~~~~~
-
-Recipe changes
-~~~~~~~~~~~~~~
-
-Removed variables
-~~~~~~~~~~~~~~~~~
-
-The following variables have been removed:
-
-Removed recipes
-~~~~~~~~~~~~~~~
-
-The following recipes have been removed in this release:
-
-Removed classes
-~~~~~~~~~~~~~~~
-
-The following classes have been removed in this release:
-
--  ``kernel-fitimage.bbclass``: the class has been replaced by the
-   :ref:`ref-classes-kernel-fit-image` class. The new implementation resolves
-   the long-standing :yocto_bugs:`bug 12912</show_bug.cgi?id=12912>`.
-
-   If you are using the kernel FIT image support, you will need to:
-
-   #. Make sure to include ``kernel-fit-extra-artifacts`` in your :term:`KERNEL_CLASSES`
-      variable to ensure the required files are exposed to the :term:`DEPLOY_DIR_IMAGE`
-      directory::
-
-         KERNEL_CLASSES += "kernel-fit-extra-artifacts"
-
-   #. Use the specific FIT image recipe rather than the base kernel recipe.
-      For example, instead of::
-
-         bitbake linux-yocto
-
-      the FIT image is now build by::
-
-         bitbake linux-yocto-fitimage
-
-      For custom kernel recipes, creating a corresponding custom FIT image recipe
-      is usually a good approach.
-
-   #. If a FIT image is used as a replacement for the kernel image in the root
-      filesystem, add the following configuration to your machine configuration
-      file::
-
-         # Create and deploy the vmlinux artifact which gets included into the FIT image
-         KERNEL_CLASSES += "kernel-fit-extra-artifacts"
-
-         # Do not install the kernel image package
-         RRECOMMENDS:${KERNEL_PACKAGE_NAME}-base = ""
-         # Install the FIT image package
-         MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "linux-yocto-fitimage"
-
-         # Configure the image.bbclass to depend on the FIT image instead of only
-         # the kernel to ensure the FIT image is built and deployed with the image
-         KERNEL_DEPLOY_DEPEND = "linux-yocto-fitimage:do_deploy"
-
-   See the :ref:`ref-classes-kernel-fit-image` section for more information.
-
-Removed features
-~~~~~~~~~~~~~~~~
-
-The following features have been removed in this release:
-
-Miscellaneous changes
-~~~~~~~~~~~~~~~~~~~~~

documentation/migration-guides/release-4.0.rst

@@ -32,6 +32,3 @@ Release 4.0 (kirkstone)
    release-notes-4.0.23
    release-notes-4.0.24
    release-notes-4.0.25
-   release-notes-4.0.26
-   release-notes-4.0.27
-   release-notes-4.0.28

documentation/migration-guides/release-5.0.rst

@@ -15,5 +15,3 @@ Release 5.0 (scarthgap)
    release-notes-5.0.6
    release-notes-5.0.7
    release-notes-5.0.8
-   release-notes-5.0.9
-   release-notes-5.0.10

documentation/migration-guides/release-5.2.rst

@@ -7,4 +7,3 @@ Release 5.2 (walnascar)
 
    migration-5.2
    release-notes-5.2
-   release-notes-5.2.1

documentation/migration-guides/release-5.3.rst

@@ -1,9 +0,0 @@
-.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
-
-Release 5.3 (whinlatter)
-========================
-
-.. toctree::
-
-   migration-5.3
-   release-notes-5.3

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

@@ -1,263 +0,0 @@
-Release notes for Yocto-4.0.26 (Kirkstone)
-------------------------------------------
-
-Security Fixes in Yocto-4.0.26
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-
--  bind: Fix :cve_nist:`2024-11187` and :cve_nist:`2024-12705`
--  binutils: Fix :cve_nist:`2025-0840`
--  elfutils: Fix :cve_nist:`2025-1352` and :cve_nist:`2025-1372`
--  ffmpeg: Fix CVE-2024-28661, :cve_nist:`2024-35369`, :cve_nist:`2024-36613`, :cve_nist:`2024-36616`,
-   :cve_nist:`2024-36617`, :cve_nist:`2024-36618`, :cve_nist:`2025-0518` and :cve_nist:`2025-25473`
--  ffmpeg: Ignore :cve_nist:`2023-46407`, :cve_nist:`2023-47470`, :cve_nist:`2024-7272`,
-   :cve_nist:`2024-22860`, :cve_nist:`2024-22861` and :cve_nist:`2024-22862`
--  freetype: Fix :cve_nist:`2025-27363`
--  gnutls: Fix :cve_nist:`2024-12243`
--  grub: Fix :cve_nist:`2024-45774`, :cve_nist:`2024-45775`, :cve_nist:`2024-45776`,
-   :cve_nist:`2024-45777`, :cve_nist:`2024-45778`, :cve_nist:`2024-45779`, :cve_nist:`2024-45780`,
-   :cve_nist:`2024-45781`, :cve_nist:`2024-45782`, :cve_nist:`2024-45783`, :cve_nist:`2024-56737`,
-   :cve_nist:`2025-0622`, :cve_nist:`2025-0624`, :cve_nist:`2025-0677`, :cve_nist:`2025-0684`,
-   :cve_nist:`2025-0685`, :cve_nist:`2025-0686`, :cve_nist:`2025-0689`, :cve_nist:`2025-0678`,
-   :cve_nist:`2025-0690`, :cve_nist:`2025-1118` and :cve_nist:`2025-1125`
--  gstreamer1.0-rtsp-server: fix :cve_nist:`2024-44331`
--  libarchive: Fix :cve_nist:`2025-25724`
--  libarchive: Ignore :cve_nist:`2025-1632`
--  libcap: Fix :cve_nist:`2025-1390`
--  linux-yocto/5.10: Fix :cve_nist:`2024-36476`, :cve_nist:`2024-43098`, :cve_nist:`2024-47143`,
-   :cve_nist:`2024-48881`, :cve_nist:`2024-50051`, :cve_nist:`2024-50074`, :cve_nist:`2024-50082`,
-   :cve_nist:`2024-50083`, :cve_nist:`2024-50099`, :cve_nist:`2024-50115`, :cve_nist:`2024-50116`,
-   :cve_nist:`2024-50117`, :cve_nist:`2024-50142`, :cve_nist:`2024-50148`, :cve_nist:`2024-50150`,
-   :cve_nist:`2024-50151`, :cve_nist:`2024-50167`, :cve_nist:`2024-50168`, :cve_nist:`2024-50171`,
-   :cve_nist:`2024-50185`, :cve_nist:`2024-50192`, :cve_nist:`2024-50193`, :cve_nist:`2024-50194`,
-   :cve_nist:`2024-50195`, :cve_nist:`2024-50198`, :cve_nist:`2024-50201`, :cve_nist:`2024-50202`,
-   :cve_nist:`2024-50205`, :cve_nist:`2024-50208`, :cve_nist:`2024-50209`, :cve_nist:`2024-50229`,
-   :cve_nist:`2024-50230`, :cve_nist:`2024-50233`, :cve_nist:`2024-50234`, :cve_nist:`2024-50236`,
-   :cve_nist:`2024-50237`, :cve_nist:`2024-50251`, :cve_nist:`2024-50262`, :cve_nist:`2024-50264`,
-   :cve_nist:`2024-50265`, :cve_nist:`2024-50267`, :cve_nist:`2024-50268`, :cve_nist:`2024-50269`,
-   :cve_nist:`2024-50273`, :cve_nist:`2024-50278`, :cve_nist:`2024-50279`, :cve_nist:`2024-50282`,
-   :cve_nist:`2024-50287`, :cve_nist:`2024-50292`, :cve_nist:`2024-50296`, :cve_nist:`2024-50299`,
-   :cve_nist:`2024-50301`, :cve_nist:`2024-50302`, :cve_nist:`2024-53042`, :cve_nist:`2024-53052`,
-   :cve_nist:`2024-53057`, :cve_nist:`2024-53059`, :cve_nist:`2024-53060`, :cve_nist:`2024-53061`,
-   :cve_nist:`2024-53063`, :cve_nist:`2024-53066`, :cve_nist:`2024-53096`, :cve_nist:`2024-53097`,
-   :cve_nist:`2024-53101`, :cve_nist:`2024-53103`, :cve_nist:`2024-53104`, :cve_nist:`2024-53145`,
-   :cve_nist:`2024-53146`, :cve_nist:`2024-53150`, :cve_nist:`2024-53155`, :cve_nist:`2024-53156`,
-   :cve_nist:`2024-53157`, :cve_nist:`2024-53161`, :cve_nist:`2024-53165`, :cve_nist:`2024-53171`,
-   :cve_nist:`2024-53173`, :cve_nist:`2024-53174`, :cve_nist:`2024-53194`, :cve_nist:`2024-53197`,
-   :cve_nist:`2024-53217`, :cve_nist:`2024-53226`, :cve_nist:`2024-53227`, :cve_nist:`2024-53237`,
-   :cve_nist:`2024-53239`, :cve_nist:`2024-55916`, :cve_nist:`2024-56548`, :cve_nist:`2024-56558`,
-   :cve_nist:`2024-56567`, :cve_nist:`2024-56568`, :cve_nist:`2024-56569`, :cve_nist:`2024-56572`,
-   :cve_nist:`2024-56574`, :cve_nist:`2024-56581`, :cve_nist:`2024-56587`, :cve_nist:`2024-56593`,
-   :cve_nist:`2024-56595`, :cve_nist:`2024-56596`, :cve_nist:`2024-56598`, :cve_nist:`2024-56600`,
-   :cve_nist:`2024-56601`, :cve_nist:`2024-56602`, :cve_nist:`2024-56603`, :cve_nist:`2024-56605`,
-   :cve_nist:`2024-56606`, :cve_nist:`2024-56615`, :cve_nist:`2024-56619`, :cve_nist:`2024-56623`,
-   :cve_nist:`2024-56629`, :cve_nist:`2024-56634`, :cve_nist:`2024-56642`, :cve_nist:`2024-56643`,
-   :cve_nist:`2024-56648`, :cve_nist:`2024-56650`, :cve_nist:`2024-56659`, :cve_nist:`2024-56662`,
-   :cve_nist:`2024-56670`, :cve_nist:`2024-56688`, :cve_nist:`2024-56698`, :cve_nist:`2024-56704`,
-   :cve_nist:`2024-56716`, :cve_nist:`2024-56720`, :cve_nist:`2024-56723`, :cve_nist:`2024-56724`,
-   :cve_nist:`2024-56728`, :cve_nist:`2024-56739`, :cve_nist:`2024-56746`, :cve_nist:`2024-56747`,
-   :cve_nist:`2024-56748`, :cve_nist:`2024-56754`, :cve_nist:`2024-56756`, :cve_nist:`2024-56770`,
-   :cve_nist:`2024-56779`, :cve_nist:`2024-56780`, :cve_nist:`2024-56781`, :cve_nist:`2024-56785`,
-   :cve_nist:`2024-57802`, :cve_nist:`2024-57807`, :cve_nist:`2024-57850`, :cve_nist:`2024-57874`,
-   :cve_nist:`2024-57890`, :cve_nist:`2024-57896`, :cve_nist:`2024-57900`, :cve_nist:`2024-57901`,
-   :cve_nist:`2024-57902`, :cve_nist:`2024-57910`, :cve_nist:`2024-57911`, :cve_nist:`2024-57913`,
-   :cve_nist:`2024-57922`, :cve_nist:`2024-57938`, :cve_nist:`2024-57939`, :cve_nist:`2024-57946`,
-   :cve_nist:`2024-57951`, :cve_nist:`2025-21638`, :cve_nist:`2025-21687`, :cve_nist:`2025-21689`,
-   :cve_nist:`2025-21692`, :cve_nist:`2025-21694`, :cve_nist:`2025-21697` and :cve_nist:`2025-21699`
--  linux-yocto/5.15: Fix :cve_nist:`2024-57979`, :cve_nist:`2024-58034`, :cve_nist:`2024-58052`,
-   :cve_nist:`2024-58055`, :cve_nist:`2024-58058`, :cve_nist:`2024-58063`, :cve_nist:`2024-58069`,
-   :cve_nist:`2024-58071`, :cve_nist:`2024-58076`, :cve_nist:`2024-58083`, :cve_nist:`2025-21700`,
-   :cve_nist:`2025-21703`, :cve_nist:`2025-21715`, :cve_nist:`2025-21722`, :cve_nist:`2025-21727`,
-   :cve_nist:`2025-21731`, :cve_nist:`2025-21753`, :cve_nist:`2025-21756`, :cve_nist:`2025-21760`,
-   :cve_nist:`2025-21761`, :cve_nist:`2025-21762`, :cve_nist:`2025-21763`, :cve_nist:`2025-21764`,
-   :cve_nist:`2025-21796`, :cve_nist:`2025-21811`, :cve_nist:`2025-21887`, :cve_nist:`2025-21898`,
-   :cve_nist:`2025-21904`, :cve_nist:`2025-21905`, :cve_nist:`2025-21912`, :cve_nist:`2025-21917`,
-   :cve_nist:`2025-21919`, :cve_nist:`2025-21920`, :cve_nist:`2025-21922`, :cve_nist:`2025-21934`,
-   :cve_nist:`2025-21943`, :cve_nist:`2025-21948` and :cve_nist:`2025-21951`
--  libpcre2: Ignore :cve_nist:`2022-1586`
--  libtasn1: Fix :cve_nist:`2024-12133`
--  libxml2: Fix :cve_nist:`2022-49043`, :cve_nist:`2024-56171`, :cve_nist:`2025-24928` and
-   :cve_nist:`2025-27113`
--  libxslt: Fix :cve_nist:`2024-55549` and :cve_nist:`2025-24855`
--  llvm: Fix :cve_nist:`2024-0151`
--  mpg123: Fix :cve_nist:`2024-10573`
--  openssh: Fix :cve_nist:`2025-26465`
--  ovmf: Revert Fix for CVE-2023-45236 :cve_nist:`2023-45237`
--  perl: Ignore :cve_nist:`2023-47038`
--  puzzles: Ignore :cve_nist:`2024-13769`, :cve_nist:`2024-13770` and :cve_nist:`2025-0837`
--  python3: Fix :cve_nist:`2025-0938`
--  ruby: Fix :cve_nist:`2024-41946`, :cve_nist:`2025-27219` and :cve_nist:`2025-27220`
--  subversion: Ignore :cve_nist:`2024-45720`
--  systemd: Fix :cve_nist:`2022-3821`, :cve_nist:`2022-4415`, :cve_nist:`2022-45873` and
-   :cve_nist:`2023-7008`
--  tiff: mark :cve_nist:`2023-30774` as patched with existing patch
--  u-boot: Fix :cve_nist:`2022-2347`, :cve_nist:`2022-30767`, :cve_nist:`2022-30790`,
-   :cve_nist:`2024-57254`, :cve_nist:`2024-57255`, :cve_nist:`2024-57256`, :cve_nist:`2024-57257`,
-   :cve_nist:`2024-57258` and :cve_nist:`2024-57259`
--  vim: Fix :cve_nist:`2025-1215`, :cve_nist:`2025-22134`, :cve_nist:`2025-24014`,
-   :cve_nist:`2025-26603`, :cve_nist:`2025-27423` and :cve_nist:`2025-29768`
--  xserver-xorg: Fix :cve_nist:`2022-49737`, :cve_nist:`2025-26594`, :cve_nist:`2025-26595`,
-   :cve_nist:`2025-26596`, :cve_nist:`2025-26597`, :cve_nist:`2025-26598`, :cve_nist:`2025-26599`,
-   :cve_nist:`2025-26600` and :cve_nist:`2025-26601`
--  xwayland: Fix :cve_nist:`2022-49737`, :cve_nist:`2024-9632`, :cve_nist:`2024-21885`,
-   :cve_nist:`2024-21886`, :cve_nist:`2024-31080`, :cve_nist:`2024-31081`, :cve_nist:`2024-31083`,
-   :cve_nist:`2025-26594`, :cve_nist:`2025-26595`, :cve_nist:`2025-26596`, :cve_nist:`2025-26597`,
-   :cve_nist:`2025-26598`, :cve_nist:`2025-26599`, :cve_nist:`2025-26600` and :cve_nist:`2025-26601`
--  zlib: Fix :cve_nist:`2014-9485`
-
-
-
-Fixes in Yocto-4.0.26
-~~~~~~~~~~~~~~~~~~~~~
-
--  bind: Upgrade to 9.18.33
--  bitbake: cache: bump cache version
--  bitbake: siggen.py: Improve taskhash reproducibility
--  boost: fix do_fetch error
--  build-appliance-image: Update to kirkstone head revision
--  contributor-guide/submit-changes: add policy on AI generated code
--  cve-update-nvd2-native: handle missing vulnStatus
--  docs: Add favicon for the documentation html
--  docs: Remove all mention of core-image-lsb
--  libtasn1: upgrade to 4.20.0
--  libxcrypt-compat: Remove libcrypt.so to fix conflict with libcrypt
--  libxml2: fix compilation of explicit child axis in pattern
--  linux-yocto/5.10: update to v5.10.234
--  linux-yocto/5.15: update to v5.15.179
--  mesa: Fix missing GLES3 headers in SDK sysroot
--  mesa: Update :term:`SRC_URI`
--  meta: Enable '-o pipefail' for the SDK installer
--  migration-guides: add release notes for 4.0.25
--  poky.conf: add ubuntu2404 to :term:`SANITY_TESTED_DISTROS`
--  poky.conf: bump version for 4.0.26
--  procps: replaced one use of fputs(3) with a write(2) call
--  ref-manual: don't refer to poky-lsb
--  scripts/install-buildtools: Update to 4.0.24
--  scritps/runqemu: Ensure we only have two serial ports
--  systemd: upgrade to 250.14
--  tzcode-native: Fix compiler setting from 2023d version
--  tzcode: Update :term:`SRC_URI`
--  tzdata/tzcode-native: upgrade 2025a
--  vim: Upgrade to 9.1.1198
--  virglrenderer: fix do_fetch error
--  vulnerabilities/classes: remove references to cve-check text format
--  xz: Update :term:`SRC_URI`
--  yocto-uninative: Update to 4.7 for glibc 2.41
-
-
-Known Issues in Yocto-4.0.26
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-- N/A
-
-
-Contributors to Yocto-4.0.26
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Thanks to the following people who contributed to this release:
-
--  Aleksandar Nikolic
--  Alessio Cascone
--  Antonin Godard
--  Archana Polampalli
--  Ashish Sharma
--  Bruce Ashfield
--  Carlos Dominguez
--  Deepesh Varatharajan
--  Divya Chellam
--  Guocai He
--  Hitendra Prajapati
--  Hongxu Jia
--  Jiaying Song
--  Johannes Kauffmann
--  Kai Kang
--  Lee Chee Yang
--  Libo Chen
--  Marta Rybczynska
--  Michael Halstead
--  Mingli Yu
--  Moritz Haase
--  Narpat Mali
--  Paulo Neves
--  Peter Marko
--  Priyal Doshi
--  Richard Purdie
--  Robert Yang
--  Ross Burton
--  Sakib Sajal
--  Steve Sakoman
--  Vijay Anusuri
--  Yogita Urade
--  Zhang Peng
-
-
-Repositories / Downloads for Yocto-4.0.26
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-poky
-
--  Repository Location: :yocto_git:`/poky`
--  Branch: :yocto_git:`kirkstone </poky/log/?h=kirkstone>`
--  Tag:  :yocto_git:`yocto-4.0.26 </poky/log/?h=yocto-4.0.26>`
--  Git Revision: :yocto_git:`d70d287a77d5026b698ac237ab865b2dafd36bb8 </poky/commit/?id=d70d287a77d5026b698ac237ab865b2dafd36bb8>`
--  Release Artefact: poky-d70d287a77d5026b698ac237ab865b2dafd36bb8
--  sha: 3ebfadb8bff4c1ca12b3cf3e4ef6e3ac2ce52b73570266daa98436c9959249f2
--  Download Locations:
-   https://downloads.yoctoproject.org/releases/yocto/yocto-4.0.26/poky-d70d287a77d5026b698ac237ab865b2dafd36bb8.tar.bz2
-   https://mirrors.kernel.org/yocto/yocto/yocto-4.0.26/poky-d70d287a77d5026b698ac237ab865b2dafd36bb8.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.26 </openembedded-core/log/?h=yocto-4.0.26>`
--  Git Revision: :oe_git:`1efbe1004bc82e7c14c1e8bd4ce644f5015c3346 </openembedded-core/commit/?id=1efbe1004bc82e7c14c1e8bd4ce644f5015c3346>`
--  Release Artefact: oecore-1efbe1004bc82e7c14c1e8bd4ce644f5015c3346
--  sha: d3805e034dabd0865dbf55488b2c16d4ea0351d37aa826f0054a6bfdde5a8be9
--  Download Locations:
-   https://downloads.yoctoproject.org/releases/yocto/yocto-4.0.26/oecore-1efbe1004bc82e7c14c1e8bd4ce644f5015c3346.tar.bz2
-   https://mirrors.kernel.org/yocto/yocto/yocto-4.0.26/oecore-1efbe1004bc82e7c14c1e8bd4ce644f5015c3346.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.26 </meta-mingw/log/?h=yocto-4.0.26>`
--  Git Revision: :yocto_git:`87c22abb1f11be430caf4372e6b833dc7d77564e </meta-mingw/commit/?id=87c22abb1f11be430caf4372e6b833dc7d77564e>`
--  Release Artefact: meta-mingw-87c22abb1f11be430caf4372e6b833dc7d77564e
--  sha: f0bc4873e2e0319fb9d6d6ab9b98eb3f89664d4339a167d2db6a787dd12bc1a8
--  Download Locations:
-   https://downloads.yoctoproject.org/releases/yocto/yocto-4.0.26/meta-mingw-87c22abb1f11be430caf4372e6b833dc7d77564e.tar.bz2
-   https://mirrors.kernel.org/yocto/yocto/yocto-4.0.26/meta-mingw-87c22abb1f11be430caf4372e6b833dc7d77564e.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.26 </meta-gplv2/log/?h=yocto-4.0.26>`
--  Git Revision: :yocto_git:`d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a </meta-gplv2/commit/?id=d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a>`
--  Release Artefact: meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a
--  sha: c386f59f8a672747dc3d0be1d4234b6039273d0e57933eb87caa20f56b9cca6d
--  Download Locations:
-   https://downloads.yoctoproject.org/releases/yocto/yocto-4.0.26/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2
-   https://mirrors.kernel.org/yocto/yocto/yocto-4.0.26/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.26 </bitbake/log/?h=yocto-4.0.26>`
--  Git Revision: :oe_git:`046871d9fd76efdca7b72718b328d8f545523f7e </bitbake/commit/?id=046871d9fd76efdca7b72718b328d8f545523f7e>`
--  Release Artefact: bitbake-046871d9fd76efdca7b72718b328d8f545523f7e
--  sha: e9df0a9f5921b583b539188d66b23f120e1751000e7822e76c3391d5c76ee21a
--  Download Locations:
-   https://downloads.yoctoproject.org/releases/yocto/yocto-4.0.26/bitbake-046871d9fd76efdca7b72718b328d8f545523f7e.tar.bz2
-   https://mirrors.kernel.org/yocto/yocto/yocto-4.0.26/bitbake-046871d9fd76efdca7b72718b328d8f545523f7e.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.26 </yocto-docs/log/?h=yocto-4.0.26>`
--  Git Revision: :yocto_git:`9b4c36f7b02dd4bedfec90206744a1e90e37733c </yocto-docs/commit/?id=9b4c36f7b02dd4bedfec90206744a1e90e37733c>`
-

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

@@ -1,153 +0,0 @@
-Release notes for Yocto-4.0.27 (Kirkstone)
-------------------------------------------
-
-Security Fixes in Yocto-4.0.27
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
--  binutils: Fix :cve_nist:`2025-1178`
--  busybox: fix :cve_nist:`2023-39810`
--  connman :fix :cve_nist:`2025-32743`
--  curl: Ignore :cve_nist:`2025-0725`
--  ghostscript: Fix :cve_nist:`2025-27830`, :cve_nist:`2025-27831`, :cve_nist:`2025-27832`,
-   :cve_nist:`2025-27834`, :cve_nist:`2025-27835` and :cve_nist:`2025-27836`
--  ghostscript: Ignore :cve_nist:`2024-29507`, :cve_nist:`2025-27833` and :cve_nist:`2025-27837`
--  glib-2.0: Fix :cve_nist:`2025-3360`
--  go: Fix :cve_nist:`2025-22871`
--  libarchive: Ignore :cve_nist:`2024-48615`
--  libpam: Fix :cve_nist:`2024-10041`
--  libsoup-2.4: Fix :cve_nist:`2024-52532`, :cve_nist:`2025-32906` and :cve_nist:`2025-32909`
--  libsoup: Fix :cve_nist:`2024-52532`, :cve_nist:`2025-32906`, :cve_nist:`2025-32909`,
-   :cve_nist:`2025-32910`, :cve_nist:`2025-32911`, :cve_nist:`2025-32912`, :cve_nist:`2025-32913`
-   and :cve_nist:`2025-32914`
--  libxml2: Fix :cve_nist:`2025-32414` and :cve_nist:`2025-32415`
--  ofono: Fix :cve_nist:`2024-7537`
--  perl: Fix :cve_nist:`2024-56406`
--  ppp: Fix :cve_nist:`2024-58250`
--  python3-setuptools: Fix :cve_nist:`2024-6345`
--  qemu: Ignore :cve_nist:`2023-1386`
--  ruby: Fix :cve_nist:`2024-43398`
--  sqlite3: Fix :cve_nist:`2025-29088`
--  systemd: Ignore :cve_nist:`2022-3821`, :cve_nist:`2022-4415` and :cve_nist:`2022-45873`
-
-
-Fixes in Yocto-4.0.27
-~~~~~~~~~~~~~~~~~~~~~
-
--  Revert "cve-update-nvd2-native: Tweak to work better with NFS DL_DIR"
--  build-appliance-image: Update to kirkstone head revision
--  cve-update-nvd2-native: add workaround for json5 style list
--  docs: Fix dead links that use the :term:`DISTRO` macro
--  docs: manuals: remove repeated word
--  docs: poky.yaml: introduce DISTRO_LATEST_TAG
--  glibc: Add single-threaded fast path to rand()
--  glibc: stable 2.35 branch updates
--  module.bbclass: add KBUILD_EXTRA_SYMBOLS to install
--  perl: enable _GNU_SOURCE define via d_gnulibc
--  poky.conf: bump version for 4.0.27
--  ref-manual/variables.rst: document autotools class related variables
--  scripts/install-buildtools: Update to 4.0.26
--  systemd: backport patch to fix journal issue
--  systemd: systemd-journald fails to setup LogNamespace
--  tzdata/tzcode-native: upgrade to 2025b
-
-
-Known Issues in Yocto-4.0.27
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-- N/A
-
-
-Contributors to Yocto-4.0.27
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
--  Aleksandar Nikolic
--  Alexander Kanavin
--  Alon Bar-Lev
--  Andrew Kreimer
--  Antonin Godard
--  Chen Qi
--  Deepesh Varatharajan
--  Divya Chellam
--  Haitao Liu
--  Haixiao Yan
--  Hitendra Prajapati
--  Peter Marko
--  Praveen Kumar
--  Priyal Doshi
--  Shubham Kulkarni
--  Soumya Sambu
--  Steve Sakoman
--  Vijay Anusuri
--  Yogita Urade
-
-
-Repositories / Downloads for Yocto-4.0.27
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-poky
-
--  Repository Location: :yocto_git:`/poky`
--  Branch: :yocto_git:`kirkstone </poky/log/?h=kirkstone>`
--  Tag:  :yocto_git:`yocto-4.0.27 </poky/log/?h=yocto-4.0.27>`
--  Git Revision: :yocto_git:`ab9a994a8cd8e06b519a693db444030999d273b7 </poky/commit/?id=ab9a994a8cd8e06b519a693db444030999d273b7>`
--  Release Artefact: poky-ab9a994a8cd8e06b519a693db444030999d273b7
--  sha: 77a366c17cf29eef15c6ff3f44e73f81c07288c723fd4a6dbd8c7ee9b79933f3
--  Download Locations:
-   https://downloads.yoctoproject.org/releases/yocto/yocto-4.0.27/poky-ab9a994a8cd8e06b519a693db444030999d273b7.tar.bz2
-   https://mirrors.kernel.org/yocto/yocto/yocto-4.0.27/poky-ab9a994a8cd8e06b519a693db444030999d273b7.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.27 </openembedded-core/log/?h=yocto-4.0.27>`
--  Git Revision: :oe_git:`e8be08a624b2d024715a5c8b0c37f2345a02336b </openembedded-core/commit/?id=e8be08a624b2d024715a5c8b0c37f2345a02336b>`
--  Release Artefact: oecore-e8be08a624b2d024715a5c8b0c37f2345a02336b
--  sha: cc5b0fadab021c6dc61f37fc4ff01a1cf657e7c219488ce264bede42f7f6212f
--  Download Locations:
-   https://downloads.yoctoproject.org/releases/yocto/yocto-4.0.27/oecore-e8be08a624b2d024715a5c8b0c37f2345a02336b.tar.bz2
-   https://mirrors.kernel.org/yocto/yocto/yocto-4.0.27/oecore-e8be08a624b2d024715a5c8b0c37f2345a02336b.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.27 </meta-mingw/log/?h=yocto-4.0.27>`
--  Git Revision: :yocto_git:`87c22abb1f11be430caf4372e6b833dc7d77564e </meta-mingw/commit/?id=87c22abb1f11be430caf4372e6b833dc7d77564e>`
--  Release Artefact: meta-mingw-87c22abb1f11be430caf4372e6b833dc7d77564e
--  sha: f0bc4873e2e0319fb9d6d6ab9b98eb3f89664d4339a167d2db6a787dd12bc1a8
--  Download Locations:
-   https://downloads.yoctoproject.org/releases/yocto/yocto-4.0.27/meta-mingw-87c22abb1f11be430caf4372e6b833dc7d77564e.tar.bz2
-   https://mirrors.kernel.org/yocto/yocto/yocto-4.0.27/meta-mingw-87c22abb1f11be430caf4372e6b833dc7d77564e.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.27 </meta-gplv2/log/?h=yocto-4.0.27>`
--  Git Revision: :yocto_git:`d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a </meta-gplv2/commit/?id=d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a>`
--  Release Artefact: meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a
--  sha: c386f59f8a672747dc3d0be1d4234b6039273d0e57933eb87caa20f56b9cca6d
--  Download Locations:
-   https://downloads.yoctoproject.org/releases/yocto/yocto-4.0.27/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2
-   https://mirrors.kernel.org/yocto/yocto/yocto-4.0.27/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.27 </bitbake/log/?h=yocto-4.0.27>`
--  Git Revision: :oe_git:`046871d9fd76efdca7b72718b328d8f545523f7e </bitbake/commit/?id=046871d9fd76efdca7b72718b328d8f545523f7e>`
--  Release Artefact: bitbake-046871d9fd76efdca7b72718b328d8f545523f7e
--  sha: e9df0a9f5921b583b539188d66b23f120e1751000e7822e76c3391d5c76ee21a
--  Download Locations:
-   https://downloads.yoctoproject.org/releases/yocto/yocto-4.0.27/bitbake-046871d9fd76efdca7b72718b328d8f545523f7e.tar.bz2
-   https://mirrors.kernel.org/yocto/yocto/yocto-4.0.27/bitbake-046871d9fd76efdca7b72718b328d8f545523f7e.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.27 </yocto-docs/log/?h=yocto-4.0.27>`
--  Git Revision: :yocto_git:`0d51e553d5f83eea6634e03ddc9c7740bf72fcea </yocto-docs/commit/?id=0d51e553d5f83eea6634e03ddc9c7740bf72fcea>`
-

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

@@ -1,224 +0,0 @@
-Release notes for Yocto-4.0.28 (Kirkstone)
-------------------------------------------
-
-Security Fixes in Yocto-4.0.28
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
--  binutils: Fix :cve_nist:`2025-1180`, :cve_nist:`2025-1182`, :cve_nist:`2025-5244` and
-   :cve_nist:`2025-5245`
--  connman: Fix :cve_nist:`2025-32366`
--  ffmpeg: Fix :cve_nist:`2025-1373`, :cve_nist:`2025-22919` and :cve_nist:`2025-22921`
--  ffmpeg: Ignore :cve_nist:`2022-48434`
--  ghostscript: Fix :cve_nist:`2025-48708`
--  git: Fix :cve_nist:`2024-50349` and :cve_nist:`2024-52006`
--  glib-2.0: Fix :cve_nist:`2025-4373`
--  glibc: Fix for :cve_nist:`2025-4802`
--  go: Fix :cve_nist:`2025-4673`
--  go: ignore :cve_nist:`2024-3566`
--  icu: Fix :cve_nist:`2025-5222`
--  iputils: Fix :cve_nist:`2025-47268`
--  libsoup-2.4: Fix :cve_nist:`2025-2784`, :cve_nist:`2025-4476`, :cve_nist:`2025-4948`,
-   :cve_nist:`2025-4969`, :cve_nist:`2025-32050`, :cve_nist:`2025-32052`, :cve_nist:`2025-32053`,
-   :cve_nist:`2025-32907`, :cve_nist:`2025-32910`, :cve_nist:`2025-32911`, :cve_nist:`2025-32912`,
-   :cve_nist:`2025-32913`, :cve_nist:`2025-32914`, :cve_nist:`2025-46420` and :cve_nist:`2025-46421`
--  libsoup: Fix :cve_nist:`2025-2784`, :cve_nist:`2025-4476`, :cve_nist:`2025-4948`,
-   :cve_nist:`2025-4969`, :cve_nist:`2025-32050`, :cve_nist:`2025-32051`, :cve_nist:`2025-32052`,
-   :cve_nist:`2025-32053`, :cve_nist:`2025-32907`, :cve_nist:`2025-46420` and :cve_nist:`2025-46421`
--  linux-yocto/5.15: Fix :cve_nist:`2024-26952`, :cve_nist:`2025-21941`, :cve_nist:`2025-21957`,
-   :cve_nist:`2025-21959`, :cve_nist:`2025-21962`, :cve_nist:`2025-21963`, :cve_nist:`2025-21964`,
-   :cve_nist:`2025-21968`, :cve_nist:`2025-21996`, :cve_nist:`2025-22018`, :cve_nist:`2025-22020`,
-   :cve_nist:`2025-22035`, :cve_nist:`2025-22054`, :cve_nist:`2025-22056`, :cve_nist:`2025-22063`,
-   :cve_nist:`2025-22066`, :cve_nist:`2025-22081`, :cve_nist:`2025-22097`, :cve_nist:`2025-23136`,
-   :cve_nist:`2025-37785`, :cve_nist:`2025-37803`, :cve_nist:`2025-37805`, :cve_nist:`2025-38152`,
-   :cve_nist:`2025-39728` and :cve_nist:`2025-39735`
--  net-tools: Fix :cve_nist:`2025-46836`
--  openssh: Fix :cve_nist:`2025-32728`
--  python3: Fix :cve_nist:`2024-12718`, :cve_nist:`2025-0938`, :cve_nist:`2025-4138`,
-   :cve_nist:`2025-4330`, :cve_nist:`2025-4435`, :cve_nist:`2025-4516` and :cve_nist:`2025-4517`
--  python3-requests: Fix :cve_nist:`2024-47081`
--  python3-setuptools: Fix :cve_nist:`2025-47273`
--  ruby: Fix :cve_nist:`2025-27221`
--  screen: Fix :cve_nist:`2025-46802`, :cve_nist:`2025-46804` and :cve_nist:`2025-46805`
--  taglib: Fix :cve_nist:`2023-47466`
-
-
-Fixes in Yocto-4.0.28
-~~~~~~~~~~~~~~~~~~~~~
-
--  babeltrace/libatomic-ops: correct the :term:`SRC_URI`
--  brief-yoctoprojectqs/ref-manual: Switch to new CDN
--  bsp guide: update kernel version example to 6.12
--  bsp-guide: update lonely "4.12" kernel reference to "6.12"
--  build-appliance-image: Update to kirkstone head revision
--  cmake: Correctly handle cost data of tests with arbitrary chars in name
--  conf.py: tweak SearchEnglish to be hyphen-friendly
--  contributor-guide/submit-changes: encourage patch version changelogs
--  dev-manual/sbom.rst: fix wrong build outputs
--  docs: Clean up explanation of minimum required version numbers
--  docs: README: specify how to contribute instead of pointing at another file
--  docs: conf.py: silence SyntaxWarning on js_splitter_code
--  e2fsprogs: removed 'sed -u' option
--  ffmpeg: Add "libswresample libavcodec" to :term:`CVE_PRODUCT`
--  ffmpeg: upgrade to 5.0.3
--  gcc: AArch64 - Fix strict-align cpymem/setmem
--  glibc: nptl Fix indentation
--  glibc: nptl Remove unnecessary catch-all-wake in condvar group switch
--  glibc: nptl Remove unnecessary quadruple check in pthread_cond_wait
--  glibc: nptl Update comments and indentation for new condvar implementation
--  glibc: nptl Use a single loop in pthread_cond_wait instaed of a nested loop
--  glibc: nptl Use all of g1_start and g_signals
--  glibc: nptl rename __condvar_quiesce_and_switch_g1
--  glibc: pthreads NPTL lost wakeup fix 2
--  kernel.bbclass: add original package name to :term:`RPROVIDES` for -image and -base
--  libpng: Improve ptest
--  linux-yocto/5.15: update to v5.15.184
--  migration-guides: add release notes for 4.0.26 and 4.0.27
--  nfs-utils: don't use signals to shut down nfs server.
--  poky.conf: bump version for 4.0.28
--  python3: upgrade to 3.10.18
--  ref-manual/release-process: update releases.svg
--  ref-manual/variables.rst: document :term:`INHIBIT_DEFAULT_RUST_DEPS`
-   :term:`INHIBIT_UPDATERCD_BBCLASS` :term:`SSTATE_SKIP_CREATION` :term:`WIC_CREATE_EXTRA_ARGS`
-   :term:`IMAGE_ROOTFS_MAXSIZE` :term:`INITRAMFS_MAXSIZE`
--  ref-manual: clarify :term:`KCONFIG_MODE` default behaviour
--  ref-manual: classes: nativesdk: move note to appropriate section
--  ref-manual: classes: reword to clarify that native/nativesdk options are exclusive
--  ref-manual: kernel-fitimage.bbclass does not use :term:`SPL_SIGN_KEYNAME`
--  scripts/install-buildtools: Update to 4.0.27
--  sphinx-lint: role missing opening tag colon
--  sphinx-lint: trailing whitespace
--  sphinx-lint: unbalanced inline literal markup
--  sysstat: correct the :term:`SRC_URI`
--  systemtap: add sysroot Python paths to configure flags
--  test-manual/intro: remove Buildbot version used
--  util-linux: Add fix to isolate test fstab entries using CUSTOM_FSTAB
--  xz: Update :term:`LICENSE` variable for xz packages
-
-
-Known Issues in Yocto-4.0.28
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-- N/A
-
-
-Contributors to Yocto-4.0.28
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
--  Aditya Tayade
--  Adrian Freihofer
--  Aleksandar Nikolic
--  Alper Ak
--  Antonin Godard
--  Archana Polampalli
--  Ashish Sharma
--  Bruce Ashfield
--  Carlos Sánchez de La Lama
--  Changqing Li
--  Christos Gavros
--  Colin Pinnell McAllister
--  Deepesh Varatharajan
--  Divya Chellam
--  Enrico Jörns
--  Etienne Cordonnier
--  Guocai He
--  Harish Sadineni
--  Hitendra Prajapati
--  Jiaying Song
--  Lee Chee Yang
--  Martin Jansa
--  Moritz Haase
--  NeilBrown
--  Peter Marko
--  Poonam Jadhav
--  Praveen Kumar
--  Quentin Schulz
--  Richard Purdie
--  Robert P. J. Day
--  Soumya Sambu
--  Steve Sakoman
--  Sundeep KOKKONDA
--  Sunil Dora
--  Trevor Woerner
--  Vijay Anusuri
--  Virendra Thakur
--  Yi Zhao
--  aszh07
-
-
-Repositories / Downloads for Yocto-4.0.28
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-poky
-
--  Repository Location: :yocto_git:`/poky`
--  Branch: :yocto_git:`kirkstone </poky/log/?h=kirkstone>`
--  Tag:  :yocto_git:`yocto-4.0.28 </poky/log/?h=yocto-4.0.28>`
--  Git Revision: :yocto_git:`78c9cb3eaf071932567835742608404d5ce23cc4 </poky/commit/?id=78c9cb3eaf071932567835742608404d5ce23cc4>`
--  Release Artefact: poky-78c9cb3eaf071932567835742608404d5ce23cc4
--  sha: 9c73c6f89e70c2041a52851e5cc582e5a2f05ad2fdc110d2c518f2c4994e8de3
--  Download Locations:
-   https://downloads.yoctoproject.org/releases/yocto/yocto-4.0.28/poky-78c9cb3eaf071932567835742608404d5ce23cc4.tar.bz2
-   https://mirrors.kernel.org/yocto/yocto/yocto-4.0.28/poky-78c9cb3eaf071932567835742608404d5ce23cc4.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.28 </openembedded-core/log/?h=yocto-4.0.28>`
--  Git Revision: :oe_git:`75e54301c5076eb0454aee33c870adf078f563fd </openembedded-core/commit/?id=75e54301c5076eb0454aee33c870adf078f563fd>`
--  Release Artefact: oecore-75e54301c5076eb0454aee33c870adf078f563fd
--  sha: c5ffceab90881c4041ec4304da8b7b32d9c1f89a4c63ee7b8cbd53c796b0187b
--  Download Locations:
-   https://downloads.yoctoproject.org/releases/yocto/yocto-4.0.28/oecore-75e54301c5076eb0454aee33c870adf078f563fd.tar.bz2
-   https://mirrors.kernel.org/yocto/yocto/yocto-4.0.28/oecore-75e54301c5076eb0454aee33c870adf078f563fd.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.28 </meta-mingw/log/?h=yocto-4.0.28>`
--  Git Revision: :yocto_git:`87c22abb1f11be430caf4372e6b833dc7d77564e </meta-mingw/commit/?id=87c22abb1f11be430caf4372e6b833dc7d77564e>`
--  Release Artefact: meta-mingw-87c22abb1f11be430caf4372e6b833dc7d77564e
--  sha: f0bc4873e2e0319fb9d6d6ab9b98eb3f89664d4339a167d2db6a787dd12bc1a8
--  Download Locations:
-   https://downloads.yoctoproject.org/releases/yocto/yocto-4.0.28/meta-mingw-87c22abb1f11be430caf4372e6b833dc7d77564e.tar.bz2
-   https://mirrors.kernel.org/yocto/yocto/yocto-4.0.28/meta-mingw-87c22abb1f11be430caf4372e6b833dc7d77564e.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.28 </meta-gplv2/log/?h=yocto-4.0.28>`
--  Git Revision: :yocto_git:`d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a </meta-gplv2/commit/?id=d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a>`
--  Release Artefact: meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a
--  sha: c386f59f8a672747dc3d0be1d4234b6039273d0e57933eb87caa20f56b9cca6d
--  Download Locations:
-   https://downloads.yoctoproject.org/releases/yocto/yocto-4.0.28/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2
-   https://mirrors.kernel.org/yocto/yocto/yocto-4.0.28/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.28 </bitbake/log/?h=yocto-4.0.28>`
--  Git Revision: :oe_git:`046871d9fd76efdca7b72718b328d8f545523f7e </bitbake/commit/?id=046871d9fd76efdca7b72718b328d8f545523f7e>`
--  Release Artefact: bitbake-046871d9fd76efdca7b72718b328d8f545523f7e
--  sha: e9df0a9f5921b583b539188d66b23f120e1751000e7822e76c3391d5c76ee21a
--  Download Locations:
-   https://downloads.yoctoproject.org/releases/yocto/yocto-4.0.28/bitbake-046871d9fd76efdca7b72718b328d8f545523f7e.tar.bz2
-   https://mirrors.kernel.org/yocto/yocto/yocto-4.0.28/bitbake-046871d9fd76efdca7b72718b328d8f545523f7e.tar.bz2
-
-meta-yocto
-
--  Repository Location: :yocto_git:`/meta-yocto`
--  Branch: :yocto_git:`kirkstone </meta-yocto/log/?h=kirkstone>`
--  Tag: :yocto_git:`yocto-4.0.28 </meta-yocto/log/?h=yocto-4.0.28>`
--  Git Revision: :yocto_git:`0bf3dcef1caa80fb047bf9c3514314ab658e30ea </meta-yocto/commit/?id=0bf3dcef1caa80fb047bf9c3514314ab658e30ea>`
-
-yocto-docs
-
--  Repository Location: :yocto_git:`/yocto-docs`
--  Branch: :yocto_git:`kirkstone </yocto-docs/log/?h=kirkstone>`
--  Tag: :yocto_git:`yocto-4.0.28 </yocto-docs/log/?h=yocto-4.0.28>`
--  Git Revision: :yocto_git:`97cd3ee7f3bf1de8454708d1852ea9cdbd45c39b </yocto-docs/commit/?id=97cd3ee7f3bf1de8454708d1852ea9cdbd45c39b>`
-

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

@@ -272,9 +272,9 @@ New Features / Enhancements in 4.3
 
 -  Prominent documentation updates:
 
-   -  New :doc:`/contributor-guide/index` document.
+   -  New :doc:`../contributor-guide/index` document.
 
-   -  New :doc:`/dev-manual/security-subjects` chapter in the Development
+   -  New :doc:`../dev-manual/security-subjects` chapter in the Development
       Tasks Manual.
 
    -  Long overdue documentation for the :ref:`ref-classes-devicetree` class.
@@ -295,7 +295,7 @@ New Features / Enhancements in 4.3
    -  Generation of :term:`SPDX` manifests is now enabled by default.
 
    -  Git based recipes in OE-Core which used the ``git``  protocol have been
-      changed to use ``https`` where possible, as it is typically faster and
+      changed to use `https`` where possible, as it is typically faster and
       more reliable.
 
    -  The ``os-release`` recipe added a ``CPE_NAME`` to the fields provided, with the

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

@@ -1,208 +0,0 @@
-.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
-
-Release notes for Yocto-5.0.10 (Scarthgap)
-------------------------------------------
-
-Security Fixes in Yocto-5.0.10
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
--  binutils: Fix :cve_nist:`2025-1153`, :cve_nist:`2025-1179`, :cve_nist:`2025-1180` and
-   :cve_nist:`2025-1182`
--  connman: Fix :cve_nist:`2025-32366` and :cve_nist:`2025-32743`
--  curl: Fix :cve_nist:`2024-11053` and :cve_nist:`2025-0167`
--  elfutils: Fix :cve_nist:`2025-1371`
--  ffmpeg: Fix :cve_nist:`2024-7055`, :cve_nist:`2024-32230`, :cve_nist:`2024-35366`,
-   :cve_nist:`2024-36613`, :cve_nist:`2024-36616`, :cve_nist:`2024-36617` and :cve_nist:`2024-36619`
--  git: Fix :cve_nist:`2024-50349` and :cve_nist:`2024-52006`
--  glib-2.0: fix :cve_nist:`2025-3360` and :cve_nist:`2025-4373`
--  iputils: Fix :cve_nist:`2025-47268`
--  libpam: Fix :cve_nist:`2024-10041`
--  libsoup-2.4: Fix :cve_nist:`2024-52530`, :cve_nist:`2024-52531`, :cve_nist:`2024-52532`,
-   :cve_nist:`2025-32906`, :cve_nist:`2025-32909`, :cve_nist:`2025-32910`, :cve_nist:`2025-32911`,
-   :cve_nist:`2025-32912`, :cve_nist:`2025-32913`, :cve_nist:`2025-32914` and :cve_nist:`2025-46420`
--  libsoup: Fix :cve_nist:`2025-4476`, :cve_nist:`2025-32906`, :cve_nist:`2025-32909`,
-   :cve_nist:`2025-32910`, :cve_nist:`2025-32911`, :cve_nist:`2025-32912`, :cve_nist:`2025-32913`,
-   :cve_nist:`2025-32914` and :cve_nist:`2025-46420`
--  libxml2: Fix :cve_nist:`2025-32414` and :cve_nist:`2025-32415`
--  openssh: Fix :cve_nist:`2025-32728`
--  perl: Fix :cve_nist:`2024-56406`
--  ppp: Fix :cve_nist:`2024-58250`
--  python3-jinja2: Fix :cve_nist:`2024-56201`, :cve_nist:`2024-56326` and :cve_nist:`2025-27516`
--  ruby: Fix :cve_nist:`2025-27221`
--  sqlite3: Fix :cve_nist:`2025-3277`, :cve_nist:`2025-29087` and :cve_nist:`2025-29088`
-
-
-Fixes in Yocto-5.0.10
-~~~~~~~~~~~~~~~~~~~~~
-
--  binutils: stable 2.42 branch updates
--  bluez5: add missing tools to noinst-tools package
--  bluez5: backport a patch to fix btmgmt -i
--  bluez5: make media control a :term:`PACKAGECONFIG` option
--  build-appliance-image: Update to scarthgap head revision
--  buildtools-tarball: Make buildtools respects host CA certificates
--  buildtools-tarball: add envvars into :term:`BB_ENV_PASSTHROUGH_ADDITIONS`
--  buildtools-tarball: move setting of envvars to respective envfile
--  contributor-guide/submit-changes: encourage patch version changelogs
--  cve-check.bbclass: Fix symlink handling also for text files
--  cve-update-nvd2-native: Revert "cve-update-nvd2-native: Tweak to work better with NFS DL_DIR"
--  dev-manual/sbom.rst: fix wrong build outputs
--  docs: Fix dead links that use the :term:`DISTRO` macro
--  docs: conf.py: tweak SearchEnglish to be hyphen-friendly
--  docs:conf.py: define a manpage url
--  ffmpeg: upgrade to 6.1.2
--  git: upgrade to 2.44.3
--  glibc-y2038-tests: remove glibc-y2038-tests_2.39.bb recipe
--  glibc: Add single-threaded fast path to rand()
--  glibc: stable 2.39 branch updates
--  initscripts: add function log_success_msg/log_failure_msg/log_warning_msg
--  libatomic-ops: Update :term:`GITHUB_BASE_URI`
--  manuals: remove repeated word
--  migration-guides: add release notes for 4.0.26, 5.0.8, 5.0.9
--  module.bbclass: add KBUILD_EXTRA_SYMBOLS to install
--  perl: upgrade to 5.38.4
--  perlcross: upgrade to 1.6.2
--  poky.conf: bump version for 5.0.10
--  poky.yaml: introduce DISTRO_LATEST_TAG
--  python3-jinja2: upgrade to 3.1.6
--  ref-manual/release-process: update releases.svg
--  ref-manual/variables.rst: HOST_CC_ARCH: fix wrong SDK reference
--  ref-manual/variables.rst: WATCHDOG_TIMEOUT: fix recipe name
--  ref-manual/variables.rst: add manpage links for toolchain variables
--  ref-manual/variables.rst: add missing documentation for BUILD_* variables
--  ref-manual/variables.rst: document HOST_*_ARCH variables
--  ref-manual/variables.rst: document :term:`INHIBIT_DEFAULT_RUST_DEPS`
--  ref-manual/variables.rst: document :term:`INHIBIT_UPDATERCD_BBCLASS`
--  ref-manual/variables.rst: document :term:`SSTATE_SKIP_CREATION`
--  ref-manual/variables.rst: document :term:`WIC_CREATE_EXTRA_ARGS`
--  ref-manual/variables.rst: document autotools class related variables
--  ref-manual/variables.rst: document missing SDK_*_ARCH variables
--  ref-manual/variables.rst: document the :term:`IMAGE_ROOTFS_MAXSIZE` variable
--  ref-manual/variables.rst: document the :term:`INITRAMFS_MAXSIZE` variable
--  ref-manual/variables.rst: improve the :term:`PKGV` documentation
--  ref-manual/variables.rst: update :term:`ROOT_HOME` documentation
--  ref-manual: kernel-fitimage.bbclass does not use :term:`SPL_SIGN_KEYNAME`
--  scripts/install-buildtools: Update to 5.0.9
--  sphinx-lint: missing space after literal
--  sphinx-lint: trailing whitespace
--  sphinx-lint: unbalanced inline literal markup
--  systemd: Password agents shouldn't be optional
--  systemd: upgrade to 255.18
--  test-manual/intro: remove Buildbot version used
--  tzdata/tzcode-native: upgrade 2025a -> 2025b
--  u-boot: ensure keys are generated before assembling U-Boot FIT image
--  util-linux: Add fix to isolate test fstab entries using CUSTOM_FSTAB
--  wic: bootimg-efi: Support + symbol in filenames
-
-
-Known Issues in Yocto-5.0.10
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
--  There is an issue where the target libsoup-2.4 build may fail if apachectl is present on the build
-   host. The issue only affects test binaries which aren't actually used. The issue can be fixed by
-   disabling the tests or updating to more recent changes on the scarthgap branch which fix this.
-
-
-Contributors to Yocto-5.0.10
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Thanks to the following people who contributed to this release:
-
--  Adrian Freihofer
--  Aleksandar Nikolic
--  Alexander Kanavin
--  Alon Bar-Lev
--  Alper Ak
--  Andrew Kreimer
--  Antonin Godard
--  Archana Polampalli
--  Ashish Sharma
--  Changqing Li
--  Christos Gavros
--  Deepesh Varatharajan
--  Divya Chellam
--  Divyanshu Rathore
--  Enrico Jörns
--  Etienne Cordonnier
--  Guðni Már Gilbert
--  Haixiao Yan
--  Harish Sadineni
--  Igor Opaniuk
--  Jeroen Hofstee
--  Lee Chee Yang
--  Nguyen Dat Tho
--  Niko Mauno
--  Peter Marko
--  Praveen Kumar
--  Priyal Doshi
--  Rogerio Guerra Borin
--  Shubham Kulkarni
--  Soumya Sambu
--  Steve Sakoman
--  Sunil Dora
--  Trevor Woerner
--  Vijay Anusuri
--  Virendra Thakur
--  Vyacheslav Yurkov
--  Yi Zhao
--  Yogita Urade
--  rajmohan r
-
-Repositories / Downloads for Yocto-5.0.10
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-poky
-
--  Repository Location: :yocto_git:`/poky`
--  Branch: :yocto_git:`scarthgap </poky/log/?h=scarthgap>`
--  Tag:  :yocto_git:`yocto-5.0.10 </poky/log/?h=yocto-5.0.10>`
--  Git Revision: :yocto_git:`ac257900c33754957b2696529682029d997a8f28 </poky/commit/?id=ac257900c33754957b2696529682029d997a8f28>`
--  Release Artefact: poky-ac257900c33754957b2696529682029d997a8f28
--  sha: ddca7e54b331e78214bea65b346320d4fbcddf4b51103bfbbd9fc3960f32cdc7
--  Download Locations:
-   https://downloads.yoctoproject.org/releases/yocto/yocto-5.0.10/poky-ac257900c33754957b2696529682029d997a8f28.tar.bz2
-   https://mirrors.kernel.org/yocto/yocto/yocto-5.0.10/poky-ac257900c33754957b2696529682029d997a8f28.tar.bz2
-
-openembedded-core
-
--  Repository Location: :oe_git:`/openembedded-core`
--  Branch: :oe_git:`scarthgap </openembedded-core/log/?h=scarthgap>`
--  Tag:  :oe_git:`yocto-5.0.10 </openembedded-core/log/?h=yocto-5.0.10>`
--  Git Revision: :oe_git:`d5342ffc570d47a723b18297d75bd2f63c2088db </openembedded-core/commit/?id=d5342ffc570d47a723b18297d75bd2f63c2088db>`
--  Release Artefact: oecore-d5342ffc570d47a723b18297d75bd2f63c2088db
--  sha: daa62094f2327f4b3fbcc485e8964d1b86a4722f58fb37e0d8e8e9885094a262
--  Download Locations:
-   https://downloads.yoctoproject.org/releases/yocto/yocto-5.0.10/oecore-d5342ffc570d47a723b18297d75bd2f63c2088db.tar.bz2
-   https://mirrors.kernel.org/yocto/yocto/yocto-5.0.10/oecore-d5342ffc570d47a723b18297d75bd2f63c2088db.tar.bz2
-
-meta-mingw
-
--  Repository Location: :yocto_git:`/meta-mingw`
--  Branch: :yocto_git:`scarthgap </meta-mingw/log/?h=scarthgap>`
--  Tag:  :yocto_git:`yocto-5.0.10 </meta-mingw/log/?h=yocto-5.0.10>`
--  Git Revision: :yocto_git:`bd9fef71ec005be3c3a6d7f8b99d8116daf70c4f </meta-mingw/commit/?id=bd9fef71ec005be3c3a6d7f8b99d8116daf70c4f>`
--  Release Artefact: meta-mingw-bd9fef71ec005be3c3a6d7f8b99d8116daf70c4f
--  sha: ab073def6487f237ac125d239b3739bf02415270959546b6b287778664f0ae65
--  Download Locations:
-   https://downloads.yoctoproject.org/releases/yocto/yocto-5.0.10/meta-mingw-bd9fef71ec005be3c3a6d7f8b99d8116daf70c4f.tar.bz2
-   https://mirrors.kernel.org/yocto/yocto/yocto-5.0.10/meta-mingw-bd9fef71ec005be3c3a6d7f8b99d8116daf70c4f.tar.bz2
-
-bitbake
-
--  Repository Location: :oe_git:`/bitbake`
--  Branch: :oe_git:`2.8 </bitbake/log/?h=2.8>`
--  Tag:  :oe_git:`yocto-5.0.10 </bitbake/log/?h=yocto-5.0.10>`
--  Git Revision: :oe_git:`696c2c1ef095f8b11c7d2eff36fae50f58c62e5e </bitbake/commit/?id=696c2c1ef095f8b11c7d2eff36fae50f58c62e5e>`
--  Release Artefact: bitbake-696c2c1ef095f8b11c7d2eff36fae50f58c62e5e
--  sha: fc83f879cd6dd14b9b7eba0161fec23ecc191fed0fb00556ba729dceef6c145f
--  Download Locations:
-   https://downloads.yoctoproject.org/releases/yocto/yocto-5.0.10/bitbake-696c2c1ef095f8b11c7d2eff36fae50f58c62e5e.tar.bz2
-   https://mirrors.kernel.org/yocto/yocto/yocto-5.0.10/bitbake-696c2c1ef095f8b11c7d2eff36fae50f58c62e5e.tar.bz2
-
-yocto-docs
-
--  Repository Location: :yocto_git:`/yocto-docs`
--  Branch: :yocto_git:`scarthgap </yocto-docs/log/?h=scarthgap>`
--  Tag: :yocto_git:`yocto-5.0.10 </yocto-docs/log/?h=yocto-5.0.10>`
--  Git Revision: :yocto_git:`3996388e337377bedc113d072a51fe9d68dd40c6 </yocto-docs/commit/?id=3996388e337377bedc113d072a51fe9d68dd40c6>`
-

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

@@ -1,206 +0,0 @@
-.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
-
-Release notes for Yocto-5.0.9 (Scarthgap)
------------------------------------------
-
-Security Fixes in Yocto-5.0.9
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
--  binutils: Fix :cve_nist:`2024-57360`, :cve_nist:`2025-1176`, :cve_nist:`2025-1178` and
-   :cve_nist:`2025-1181`
--  expat: Fix :cve_nist:`2024-8176`
--  freetype: Fix :cve_nist:`2025-27363`
--  ghostscript: Fix :cve_nist:`2025-27830`, :cve_nist:`2025-27831`, :cve_nist:`2025-27832`,
-   :cve_nist:`2025-27833`, :cve_nist:`2025-27833`, :cve_nist:`2025-27834`, :cve_nist:`2025-27835`
-   and :cve_nist:`2025-27836`
--  go: fix :cve_nist:`2025-22870` and :cve_nist:`2025-22871`
--  grub: Fix :cve_nist:`2024-45781`, :cve_nist:`2024-45774`, :cve_nist:`2024-45775`,
-   :cve_nist:`2024-45776`, :cve_nist:`2024-45777`, :cve_nist:`2024-45778`, :cve_nist:`2024-45779`,
-   :cve_nist:`2024-45780`, :cve_nist:`2024-45782`, :cve_nist:`2024-45783`, :cve_nist:`2024-56737`,
-   :cve_nist:`2025-0622`, :cve_nist:`2025-0624`, :cve_nist:`2025-0677`, :cve_nist:`2025-0678`,
-   :cve_nist:`2025-0684`, :cve_nist:`2025-0685`, :cve_nist:`2025-0686`, :cve_nist:`2025-0689`,
-   :cve_nist:`2025-0690`, :cve_nist:`2025-1118` and :cve_nist:`2025-1125`
--  libarchive: Fix :cve_nist:`2024-20696`, :cve_nist:`2024-48957`, :cve_nist:`2024-48958`,
-   :cve_nist:`2025-1632` and :cve_nist:`2025-25724`
--  libxslt: Fix :cve_nist:`2024-24855` and :cve_nist:`2024-55549`
--  linux-yocto/6.6: Fix :cve_nist:`2024-54458`, :cve_nist:`2024-57834`, :cve_nist:`2024-57973`,
-   :cve_nist:`2024-57978`, :cve_nist:`2024-57979`, :cve_nist:`2024-57980`, :cve_nist:`2024-57981`,
-   :cve_nist:`2024-57984`, :cve_nist:`2024-57996`, :cve_nist:`2024-57997`, :cve_nist:`2024-58002`,
-   :cve_nist:`2024-58005`, :cve_nist:`2024-58007`, :cve_nist:`2024-58010`, :cve_nist:`2024-58011`,
-   :cve_nist:`2024-58013`, :cve_nist:`2024-58017`, :cve_nist:`2024-58020`, :cve_nist:`2024-58034`,
-   :cve_nist:`2024-58052`, :cve_nist:`2024-58055`, :cve_nist:`2024-58058`, :cve_nist:`2024-58063`,
-   :cve_nist:`2024-58068`, :cve_nist:`2024-58069`, :cve_nist:`2024-58070`, :cve_nist:`2024-58071`,
-   :cve_nist:`2024-58076`, :cve_nist:`2024-58080`, :cve_nist:`2024-58083`, :cve_nist:`2024-58088`,
-   :cve_nist:`2025-21700`, :cve_nist:`2025-21703`, :cve_nist:`2025-21707`, :cve_nist:`2025-21711`,
-   :cve_nist:`2025-21715`, :cve_nist:`2025-21716`, :cve_nist:`2025-21718`, :cve_nist:`2025-21726`,
-   :cve_nist:`2025-21727`, :cve_nist:`2025-21731`, :cve_nist:`2025-21735`, :cve_nist:`2025-21736`,
-   :cve_nist:`2025-21741`, :cve_nist:`2025-21742`, :cve_nist:`2025-21743`, :cve_nist:`2025-21744`,
-   :cve_nist:`2025-21745`, :cve_nist:`2025-21748`, :cve_nist:`2025-21749`, :cve_nist:`2025-21753`,
-   :cve_nist:`2025-21756`, :cve_nist:`2025-21759`, :cve_nist:`2025-21760`, :cve_nist:`2025-21761`,
-   :cve_nist:`2025-21762`, :cve_nist:`2025-21763`, :cve_nist:`2025-21764`, :cve_nist:`2025-21773`,
-   :cve_nist:`2025-21775`, :cve_nist:`2025-21776`, :cve_nist:`2025-21779`, :cve_nist:`2025-21780`,
-   :cve_nist:`2025-21782`, :cve_nist:`2025-21783`, :cve_nist:`2025-21785`, :cve_nist:`2025-21787`,
-   :cve_nist:`2025-21789`, :cve_nist:`2025-21790`, :cve_nist:`2025-21791`, :cve_nist:`2025-21792`,
-   :cve_nist:`2025-21793`, :cve_nist:`2025-21796`, :cve_nist:`2025-21811`, :cve_nist:`2025-21812`,
-   :cve_nist:`2025-21814`, :cve_nist:`2025-21820`, :cve_nist:`2025-21844`, :cve_nist:`2025-21846`,
-   :cve_nist:`2025-21847`, :cve_nist:`2025-21848`, :cve_nist:`2025-21853`, :cve_nist:`2025-21854`,
-   :cve_nist:`2025-21855`, :cve_nist:`2025-21856`, :cve_nist:`2025-21857`, :cve_nist:`2025-21858`,
-   :cve_nist:`2025-21859`, :cve_nist:`2025-21862`, :cve_nist:`2025-21863`, :cve_nist:`2025-21864`,
-   :cve_nist:`2025-21865`, :cve_nist:`2025-21866`, :cve_nist:`2025-21867`, :cve_nist:`2025-21887`,
-   :cve_nist:`2025-21891`, :cve_nist:`2025-21898`, :cve_nist:`2025-21904`, :cve_nist:`2025-21905`,
-   :cve_nist:`2025-21908`, :cve_nist:`2025-21912`, :cve_nist:`2025-21915`, :cve_nist:`2025-21917`,
-   :cve_nist:`2025-21918`, :cve_nist:`2025-21919`, :cve_nist:`2025-21920`, :cve_nist:`2025-21922`,
-   :cve_nist:`2025-21928`, :cve_nist:`2025-21934`, :cve_nist:`2025-21936`, :cve_nist:`2025-21937`,
-   :cve_nist:`2025-21941`, :cve_nist:`2025-21943`, :cve_nist:`2025-21945`, :cve_nist:`2025-21947`,
-   :cve_nist:`2025-21948`, :cve_nist:`2025-21951`, :cve_nist:`2025-21957`, :cve_nist:`2025-21959`,
-   :cve_nist:`2025-21962`, :cve_nist:`2025-21963`, :cve_nist:`2025-21964`, :cve_nist:`2025-21966`,
-   :cve_nist:`2025-21967`, :cve_nist:`2025-21968`, :cve_nist:`2025-21969`, :cve_nist:`2025-21979`,
-   :cve_nist:`2025-21980`, :cve_nist:`2025-21981`, :cve_nist:`2025-21991` and :cve_nist:`2025-21993`
--  mpg123: Fix :cve_nist:`2024-10573`
--  ofono: Fix :cve_nist:`2024-7537`
--  openssh: Fix :cve_nist:`2025-26465`
--  puzzles: Ignore :cve_nist:`2024-13769`, :cve_nist:`2024-13770` and :cve_nist:`2025-0837`
--  qemu: Ignore :cve_nist:`2023-1386`
--  ruby: Fix :cve_nist:`2025-27219` and :cve_nist:`2025-27220`
--  rust-cross-canadian: Ignore :cve_nist:`2024-43402`
--  vim: Fix :cve_nist:`2025-1215`, :cve_nist:`2025-26603`, :cve_nist:`2025-27423` and
-   :cve_nist:`2025-29768`
--  xserver-xorg: Fix :cve_nist:`2025-26594`, :cve_nist:`2025-26595`, :cve_nist:`2025-26596`,
-   :cve_nist:`2025-26597`, :cve_nist:`2025-26598`, :cve_nist:`2025-26599`, :cve_nist:`2025-26600`
-   and :cve_nist:`2025-26601`
--  xz: Fix :cve_nist:`2025-31115`
-
-
-Fixes in Yocto-5.0.9
-~~~~~~~~~~~~~~~~~~~~
-
--  babeltrace2: extend to nativesdk
--  babeltrace: extend to nativesdk
--  bitbake: event/utils: Avoid deadlock from lock_timeout() and recursive events
--  bitbake: utils: Add signal blocking for lock_timeout
--  bitbake: utils: Print information about lock issue before exiting
--  bitbake: utils: Tweak lock_timeout logic
--  build-appliance-image: Update to scarthgap head revision
--  cve-check.bbclass: Mitigate symlink related error
--  cve-update-nvd2-native: add workaround for json5 style list
--  cve-update-nvd2-native: handle missing vulnStatus
--  gcc: remove paths to sysroot from configargs.h and checksum-options for gcc-cross-canadian
--  gcc: unify cleanup of include-fixed, apply to cross-canadian
--  ghostscript: upgrade to 10.05.0
--  grub: backport strlcpy function
--  grub: drop obsolete CVE statuses
--  icu: Adjust ICU_DATA_DIR path on big endian targets
--  kernel-arch: add macro-prefix-map in KERNEL_CC
--  libarchive: upgrade to 3.7.9
--  libxslt: upgrade to 1.1.43
--  linux-yocto/6.6: update to v6.6.84
--  mc: set ac_cv_path_ZIP to avoid buildpaths QA issues
--  mpg123: upgrade to 1.32.10
--  nativesdk-libtool: sanitize the script, remove buildpaths
--  openssl: rewrite ptest installation
--  overview-manual/concepts: remove :term:`PR` from the build dir list
--  patch.py: set commituser and commitemail for addNote
--  poky.conf: bump version for 5.0.9
--  vim: Upgrade to 9.1.1198
--  xserver-xf86-config: add a configuration fragment to disable screen blanking
--  xserver-xf86-config: remove obsolete configuration files
--  xserver-xorg: upgrade to 21.1.16
--  xz: upgrade to 5.4.7
--  yocto-uninative: Update to 4.7 for glibc 2.41
-
-
-Known Issues in Yocto-5.0.9
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-- N/A
-
-Contributors to Yocto-5.0.9
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Thanks to the following people who contributed to this release:
-
--  Antonin Godard
--  Archana Polampalli
--  Ashish Sharma
--  Bruce Ashfield
--  Changqing Li
--  Denys Dmytriyenko
--  Divya Chellam
--  Hitendra Prajapati
--  Madhu Marri
--  Makarios Christakis
--  Martin Jansa
--  Michael Halstead
--  Niko Mauno
--  Oleksandr Hnatiuk
--  Peter Marko
--  Richard Purdie
--  Ross Burton
--  Sana Kazi
--  Stefan Mueller-Klieser
--  Steve Sakoman
--  Vijay Anusuri
--  Virendra Thakur
--  Vishwas Udupa
--  Wang Mingyu
--  Zhang Peng
-
-
-Repositories / Downloads for Yocto-5.0.9
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-poky
-
--  Repository Location: :yocto_git:`/poky`
--  Branch: :yocto_git:`scarthgap </poky/log/?h=scarthgap>`
--  Tag:  :yocto_git:`yocto-5.0.9 </poky/log/?h=yocto-5.0.9>`
--  Git Revision: :yocto_git:`bab0f9f62af9af580744948dd3240f648a99879a </poky/commit/?id=bab0f9f62af9af580744948dd3240f648a99879a>`
--  Release Artefact: poky-bab0f9f62af9af580744948dd3240f648a99879a
--  sha: ee6811d9fb6c4913e19d6e3569f1edc8ccd793779b237520596506446a6b4531
--  Download Locations:
-   https://downloads.yoctoproject.org/releases/yocto/yocto-5.0.9/poky-bab0f9f62af9af580744948dd3240f648a99879a.tar.bz2
-   https://mirrors.kernel.org/yocto/yocto/yocto-5.0.9/poky-bab0f9f62af9af580744948dd3240f648a99879a.tar.bz2
-
-openembedded-core
-
--  Repository Location: :oe_git:`/openembedded-core`
--  Branch: :oe_git:`scarthgap </openembedded-core/log/?h=scarthgap>`
--  Tag:  :oe_git:`yocto-5.0.9 </openembedded-core/log/?h=yocto-5.0.9>`
--  Git Revision: :oe_git:`04038ecd1edd6592b826665a2b787387bb7074fa </openembedded-core/commit/?id=04038ecd1edd6592b826665a2b787387bb7074fa>`
--  Release Artefact: oecore-04038ecd1edd6592b826665a2b787387bb7074fa
--  sha: 6e201a4b486dfbdfcb7e96d83b962a205ec4764db6ad0e34bd623db18910eddb
--  Download Locations:
-   https://downloads.yoctoproject.org/releases/yocto/yocto-5.0.9/oecore-04038ecd1edd6592b826665a2b787387bb7074fa.tar.bz2
-   https://mirrors.kernel.org/yocto/yocto/yocto-5.0.9/oecore-04038ecd1edd6592b826665a2b787387bb7074fa.tar.bz2
-
-meta-mingw
-
--  Repository Location: :yocto_git:`/meta-mingw`
--  Branch: :yocto_git:`scarthgap </meta-mingw/log/?h=scarthgap>`
--  Tag:  :yocto_git:`yocto-5.0.9 </meta-mingw/log/?h=yocto-5.0.9>`
--  Git Revision: :yocto_git:`bd9fef71ec005be3c3a6d7f8b99d8116daf70c4f </meta-mingw/commit/?id=bd9fef71ec005be3c3a6d7f8b99d8116daf70c4f>`
--  Release Artefact: meta-mingw-bd9fef71ec005be3c3a6d7f8b99d8116daf70c4f
--  sha: ab073def6487f237ac125d239b3739bf02415270959546b6b287778664f0ae65
--  Download Locations:
-   https://downloads.yoctoproject.org/releases/yocto/yocto-5.0.9/meta-mingw-bd9fef71ec005be3c3a6d7f8b99d8116daf70c4f.tar.bz2
-   https://mirrors.kernel.org/yocto/yocto/yocto-5.0.9/meta-mingw-bd9fef71ec005be3c3a6d7f8b99d8116daf70c4f.tar.bz2
-
-bitbake
-
--  Repository Location: :oe_git:`/bitbake`
--  Branch: :oe_git:`2.8 </bitbake/log/?h=2.8>`
--  Tag:  :oe_git:`yocto-5.0.9 </bitbake/log/?h=yocto-5.0.9>`
--  Git Revision: :oe_git:`696c2c1ef095f8b11c7d2eff36fae50f58c62e5e </bitbake/commit/?id=696c2c1ef095f8b11c7d2eff36fae50f58c62e5e>`
--  Release Artefact: bitbake-696c2c1ef095f8b11c7d2eff36fae50f58c62e5e
--  sha: fc83f879cd6dd14b9b7eba0161fec23ecc191fed0fb00556ba729dceef6c145f
--  Download Locations:
-   https://downloads.yoctoproject.org/releases/yocto/yocto-5.0.9/bitbake-696c2c1ef095f8b11c7d2eff36fae50f58c62e5e.tar.bz2
-   https://mirrors.kernel.org/yocto/yocto/yocto-5.0.9/bitbake-696c2c1ef095f8b11c7d2eff36fae50f58c62e5e.tar.bz2
-
-yocto-docs
-
--  Repository Location: :yocto_git:`/yocto-docs`
--  Branch: :yocto_git:`scarthgap </yocto-docs/log/?h=scarthgap>`
--  Tag: :yocto_git:`yocto-5.0.9 </yocto-docs/log/?h=yocto-5.0.9>`
--  Git Revision: :yocto_git:`56db4fd81f6235428bef9e46a61c11ca0ba89733 </yocto-docs/commit/?id=56db4fd81f6235428bef9e46a61c11ca0ba89733>`
-

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

@@ -377,7 +377,7 @@ New Features / Enhancements in 5.1
       :term:`SIGGEN_EXCLUDERECIPES_ABISAFE` and does not trigger a rebuild on a
       change for dependent tasks.
 
-   -  In ``kernel-fitimage``, the existence of
+   -  In :ref:`ref-classes-kernel-fitimage`, the existence of
       :term:`EXTERNAL_KERNEL_DEVICETREE` is checked more thoroughly to avoid
       false positives.
 

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

@@ -1,161 +0,0 @@
-Release notes for Yocto-5.2.1 (Walnascar)
------------------------------------------
-
-Security Fixes in Yocto-5.2.1
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
--  connman :Fix :cve_nist:`2025-32366` and :cve_nist:`2025-32743`
--  ffmpeg: Fix :cve_nist:`2025-22921`
--  go: Fix :cve_nist:`2025-22871` and CVE-2025-22873
--  iputils: Fix :cve_nist:`2025-47268`
--  libsoup-2.4: Fix :cve_nist:`2024-52532` and :cve_nist:`2025-32911`
--  libxml2: Fix :cve_nist:`2025-32414` and :cve_nist:`2025-32415`
--  openssh: Fix :cve_nist:`2025-32728`
--  perl: Fix :cve_nist:`2024-56406`
--  qemu: Ignore :cve_nist:`2023-1386`
--  ruby: Fix :cve_nist:`2025-27219`, :cve_nist:`2025-27220` and :cve_nist:`2025-27221`
--  webkitgtk: Fix :cve_nist:`2024-54551`, :cve_nist:`2025-24208`, :cve_nist:`2025-24209`,
-   :cve_nist:`2025-24213`, :cve_nist:`2025-24216`, :cve_nist:`2025-24264` and :cve_nist:`2025-30427`
-
-
-Fixes in Yocto-5.2.1
-~~~~~~~~~~~~~~~~~~~~
-
--  binutils: stable 2.44 branch updates
--  bluez5: add missing tools to noinst-tools package
--  build-appliance-image: Update to walnascar head revision
--  buildtools-tarball: Make buildtools respects host CA certificates
--  buildtools-tarball: add envvars into :term:`BB_ENV_PASSTHROUGH_ADDITIONS`
--  buildtools-tarball: move setting of envvars to respective envfile
--  cdrtools-native: fix booting EFI ISO live failed
--  contributor-guide/submit-changes: encourage patch version changelogs
--  gcc: Fix LDRD register overlap in register-indexed mode
--  glibc-y2038-tests: remove glibc-y2038-tests_2.41.bb recipe
--  glibc: Add single-threaded fast path to rand()
--  glibc: stable 2.41 branch update
--  go: upgrade to 1.24.3
--  gobject-introspection: Fix wrong :term:`PN` used in MULTILIB_SCRIPTS
--  icu: set ac_cv_path_install to ensure install tool reproducibility
--  initscripts: add function log_success_msg/log_failure_msg/log_warning_msg
--  insane.bbclass: Move test for invalid PACKAGECONFIGs to do_recipe_qa
--  insane.bbclass: Report all invalid PACKAGECONFIGs for a recipe at once
--  libxml2: upgrade to 2.13.8
--  makedumpfile: upgrade to 1.7.7
--  migration-guides: add release notes for 4.0.26 and 5.0.9
--  module.bbclass: add KBUILD_EXTRA_SYMBOLS to install
--  patch.py: set commituser and commitemail for addNote
--  perl: upgrade to 5.40.2
--  perlcross: upgrade to 1.6.2
--  poky.conf: bump version for 5.2.1
--  ref-manual/release-process: update releases.svg
--  ref-manual/variables.rst: document :term:`WIC_CREATE_EXTRA_ARGS`
--  ref-manual/variables.rst: update :term:`ROOT_HOME` documentation
--  ref-manual: classes: uki: Fix git links
--  ref-manual: kernel-fitimage.bbclass does not use :term:`SPL_SIGN_KEYNAME`
--  ruby: upgrade to 3.4.3
--  sbom.rst: how to disable :term:`SPDX` generation
--  scripts/install-buildtools: Update to 5.2
--  sphinx-lint: various fixes
--  syslinux: improve isohybrid to process extra sector count for ISO 9660 image
--  test-manual/intro: remove Buildbot version used
--  tzdata/tzcode-native: upgrade to 2025b
--  webkitgtk: Use WTF_CPU_UNKNOWN when building for riscv64
--  webkitgtk: upgrade to 2.48.1
-
-
-Known Issues in Yocto-5.2.1
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-- N/A
-
-
-Contributors to Yocto-5.2.1
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
--  Adrian Freihofer
--  Aleksandar Nikolic
--  Alon Bar-Lev
--  Antonin Godard
--  Archana Polampalli
--  Changqing Li
--  Deepesh Varatharajan
--  Divya Chellam
--  Enrico Jörns
--  Guðni Már Gilbert
--  Haixiao Yan
--  Hongxu Jia
--  Jiaying Song
--  Khem Raj
--  Lee Chee Yang
--  Leonard Anderweit
--  Madhu Marri
--  Mikko Rapeli
--  Peter Kjellerstedt
--  Peter Marko
--  Praveen Kumar
--  Priyal Doshi
--  Steve Sakoman
--  Trevor Woerner
--  Yi Zhao
--  Yogita Urade
--  rajmohan r
-
-
-Repositories / Downloads for Yocto-5.2.1
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-poky
-
--  Repository Location: :yocto_git:`/poky`
--  Branch: :yocto_git:`walnascar </poky/log/?h=walnascar>`
--  Tag:  :yocto_git:`yocto-5.2.1 </poky/log/?h=yocto-5.2.1>`
--  Git Revision: :yocto_git:`fd9b605507a20d850a9991316cd190c1d20dc4a6 </poky/commit/?id=fd9b605507a20d850a9991316cd190c1d20dc4a6>`
--  Release Artefact: poky-fd9b605507a20d850a9991316cd190c1d20dc4a6
--  sha: 0234a96fc28e60e0acaae2a03118ecde76810c47e8bb259f4950492bd75fc050
--  Download Locations:
-   https://downloads.yoctoproject.org/releases/yocto/yocto-5.2.1/poky-fd9b605507a20d850a9991316cd190c1d20dc4a6.tar.bz2
-   https://mirrors.kernel.org/yocto/yocto/yocto-5.2.1/poky-fd9b605507a20d850a9991316cd190c1d20dc4a6.tar.bz2
-
-openembedded-core
-
--  Repository Location: :oe_git:`/openembedded-core`
--  Branch: :oe_git:`walnascar </openembedded-core/log/?h=walnascar>`
--  Tag:  :oe_git:`yocto-5.2.1 </openembedded-core/log/?h=yocto-5.2.1>`
--  Git Revision: :oe_git:`17affdaa600896282e07fb4d64cb23195673baa1 </openembedded-core/commit/?id=17affdaa600896282e07fb4d64cb23195673baa1>`
--  Release Artefact: oecore-17affdaa600896282e07fb4d64cb23195673baa1
--  sha: b6c3c15004fcd1efbaa26c9695202806402730dde8e41552a70140cff67c97c9
--  Download Locations:
-   https://downloads.yoctoproject.org/releases/yocto/yocto-5.2.1/oecore-17affdaa600896282e07fb4d64cb23195673baa1.tar.bz2
-   https://mirrors.kernel.org/yocto/yocto/yocto-5.2.1/oecore-17affdaa600896282e07fb4d64cb23195673baa1.tar.bz2
-
-meta-mingw
-
--  Repository Location: :yocto_git:`/meta-mingw`
--  Branch: :yocto_git:`walnascar </meta-mingw/log/?h=walnascar>`
--  Tag:  :yocto_git:`yocto-5.2.1 </meta-mingw/log/?h=yocto-5.2.1>`
--  Git Revision: :yocto_git:`edce693e1b8fabd84651aa6c0888aafbcf238577 </meta-mingw/commit/?id=edce693e1b8fabd84651aa6c0888aafbcf238577>`
--  Release Artefact: meta-mingw-edce693e1b8fabd84651aa6c0888aafbcf238577
--  sha: 6cfed41b54f83da91a6cf201ec1c2cd4ac284f642b1268c8fa89d2335ea2bce1
--  Download Locations:
-   https://downloads.yoctoproject.org/releases/yocto/yocto-5.2.1/meta-mingw-edce693e1b8fabd84651aa6c0888aafbcf238577.tar.bz2
-   https://mirrors.kernel.org/yocto/yocto/yocto-5.2.1/meta-mingw-edce693e1b8fabd84651aa6c0888aafbcf238577.tar.bz2
-
-bitbake
-
--  Repository Location: :oe_git:`/bitbake`
--  Branch: :oe_git:`2.12 </bitbake/log/?h=2.12>`
--  Tag:  :oe_git:`yocto-5.2.1 </bitbake/log/?h=yocto-5.2.1>`
--  Git Revision: :oe_git:`5b4e20377eea8d428edf1aeb2187c18f82ca6757 </bitbake/commit/?id=5b4e20377eea8d428edf1aeb2187c18f82ca6757>`
--  Release Artefact: bitbake-5b4e20377eea8d428edf1aeb2187c18f82ca6757
--  sha: 48cff22c1e61f47adce474b636ca865e7e0b62293fc5c8829d09e7f1ac5252af
--  Download Locations:
-   https://downloads.yoctoproject.org/releases/yocto/yocto-5.2.1/bitbake-5b4e20377eea8d428edf1aeb2187c18f82ca6757.tar.bz2
-   https://mirrors.kernel.org/yocto/yocto/yocto-5.2.1/bitbake-5b4e20377eea8d428edf1aeb2187c18f82ca6757.tar.bz2
-
-yocto-docs
-
--  Repository Location: :yocto_git:`/yocto-docs`
--  Branch: :yocto_git:`walnascar </yocto-docs/log/?h=walnascar>`
--  Tag: :yocto_git:`yocto-5.2.1 </yocto-docs/log/?h=yocto-5.2.1>`
--  Git Revision: :yocto_git:`6b7019c13054bf11fb16657a3fac85831352cea9 </yocto-docs/commit/?id=6b7019c13054bf11fb16657a3fac85831352cea9>`
-

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

@@ -25,11 +25,11 @@ New Features / Enhancements in |yocto-ver|
       :ref:`Shared State <overview-manual/concepts:Shared State>` for the
       dependencies. See :doc:`/test-manual/reproducible-builds`.
 
-   -  ``systemd``: Add :term:`WATCHDOG_RUNTIME_SEC`: for controlling the
+   -  ``systemd``: Add term:`WATCHDOG_RUNTIME_SEC`: for controlling the
       ``RuntimeWatchdogSec`` option in ``/etc/systemd/system.conf``.
 
    -  :term:`FIT_UBOOT_ENV` to allow including a u-boot script as a text in a
-      fit image. See the ``kernel-fitimage`` for more information.
+      fit image. See the :ref:`ref-classes-kernel-fitimage` for more information.
 
    -  :ref:`ref-classes-meson`: :term:`MESON_INSTALL_TAGS` to allow passing
       install tags (``--tags``) to the ``meson install`` command during the
@@ -354,7 +354,7 @@ New Features / Enhancements in |yocto-ver|
          HTTPS tokens may not be required.
 
    -  ``compress``: use ``lz4`` instead of ``lz4c``, as ``lz4c`` as been
-      considered deprecated since 2018.
+      considered deprecrated since 2018.
 
    -  ``server/process``: decrease idle/main loop frequency, as it is idle and
       main loops have socket select calls to know when to execute.
@@ -373,7 +373,7 @@ New Features / Enhancements in |yocto-ver|
    -  ``bb/build``: add a function ``bb.build.listtasks()`` to list the tasks in
       a datastore.
 
-   -  Remove custom exception backtrace formatting, and replace occurrences of
+   -  Remove custom exception backtrace formatting, and replace occurences of
       ``bb.exception.format_exception()`` by ``traceback.format_exception()``.
 
    -  ``runqueue``: various performance optimizations including:
@@ -598,7 +598,7 @@ New Features / Enhancements in |yocto-ver|
       code in :oe_git:`meta/lib/oe/license.py </openembedded-core/tree/meta/lib/oe/license.py>`.
 
    -  The recipe ``cairo`` now disables the features ``symbol-lookup``,
-      ``spectre``, and ``tests`` by default.
+      ``spectre`, and ``tests`` by default.
 
    -  The recipe ``glib-2.0`` now disables the feature ``sysprof`` by default.
 
@@ -671,7 +671,7 @@ New Features / Enhancements in |yocto-ver|
    -  New ``bbverbnote`` log utility which can be used to print on the console
       (equivalent to the ``bb.verbnote`` Python implementation).
 
-   -  :ref:`ref-classes-grub-efi`: Add :term:`GRUB_TITLE` variable to set
+   -  :ref:``ref-classes-grub-efi``: Add :term:`GRUB_TITLE` variable to set
       custom GRUB titles.
 
    -  ``gawk``: Enable high precision arithmetic support by default (``mpfr``
@@ -684,7 +684,7 @@ New Features / Enhancements in |yocto-ver|
       command-line tool was added to the different Yocto Project and OpenEmbedded
       repositories.
 
-   -  ``kernel-fitimage``: handle :doc:`multiconfig
+   -  :ref:`ref-classes-kernel-fitimage`: handle :doc:`multiconfig
       </dev-manual/multiconfig>` dependency when
       :term:`INITRAMFS_MULTICONFIG` is set.
 
@@ -2241,60 +2241,3 @@ Thanks to the following people who contributed to this release:
 
 Repositories / Downloads for Yocto-|yocto-ver|
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-
-poky
-
--  Repository Location: :yocto_git:`/poky`
--  Branch: :yocto_git:`walnascar </poky/log/?h=walnascar>`
--  Tag:  :yocto_git:`yocto-5.2 </poky/log/?h=yocto-5.2>`
--  Git Revision: :yocto_git:`9b96fdbb0cab02f4a6180e812b02bc9d4c41b1a5 </poky/commit/?id=9b96fdbb0cab02f4a6180e812b02bc9d4c41b1a5>`
--  Release Artefact: poky-9b96fdbb0cab02f4a6180e812b02bc9d4c41b1a5
--  sha: 2d3c0e216c7fa71a364986be6754549e2059d37581aad0a53f0f95c33fb1eefe
--  Download Locations:
-   https://downloads.yoctoproject.org/releases/yocto/yocto-5.2/poky-9b96fdbb0cab02f4a6180e812b02bc9d4c41b1a5.tar.bz2
-   https://mirrors.kernel.org/yocto/yocto/yocto-5.2/poky-9b96fdbb0cab02f4a6180e812b02bc9d4c41b1a5.tar.bz2
-
-openembedded-core
-
--  Repository Location: :oe_git:`/openembedded-core`
--  Branch: :oe_git:`walnascar </openembedded-core/log/?h=walnascar>`
--  Tag:  :oe_git:`yocto-5.2 </openembedded-core/log/?h=yocto-5.2>`
--  Git Revision: :oe_git:`6ec2c52b938302b894f119f701ffcf0a847eee85 </openembedded-core/commit/?id=6ec2c52b938302b894f119f701ffcf0a847eee85>`
--  Release Artefact: oecore-6ec2c52b938302b894f119f701ffcf0a847eee85
--  sha: 00453354efdd9c977d559f7c0047691bb974170ce313ac9a1e6cb94108d6c648
--  Download Locations:
-   https://downloads.yoctoproject.org/releases/yocto/yocto-5.2/oecore-6ec2c52b938302b894f119f701ffcf0a847eee85.tar.bz2
-   https://mirrors.kernel.org/yocto/yocto/yocto-5.2/oecore-6ec2c52b938302b894f119f701ffcf0a847eee85.tar.bz2
-
-meta-mingw
-
--  Repository Location: :yocto_git:`/meta-mingw`
--  Branch: :yocto_git:`walnascar </meta-mingw/log/?h=walnascar>`
--  Tag:  :yocto_git:`yocto-5.2 </meta-mingw/log/?h=yocto-5.2>`
--  Git Revision: :yocto_git:`edce693e1b8fabd84651aa6c0888aafbcf238577 </meta-mingw/commit/?id=edce693e1b8fabd84651aa6c0888aafbcf238577>`
--  Release Artefact: meta-mingw-edce693e1b8fabd84651aa6c0888aafbcf238577
--  sha: 6cfed41b54f83da91a6cf201ec1c2cd4ac284f642b1268c8fa89d2335ea2bce1
--  Download Locations:
-   https://downloads.yoctoproject.org/releases/yocto/yocto-5.2/meta-mingw-edce693e1b8fabd84651aa6c0888aafbcf238577.tar.bz2
-   https://mirrors.kernel.org/yocto/yocto/yocto-5.2/meta-mingw-edce693e1b8fabd84651aa6c0888aafbcf238577.tar.bz2
-
-bitbake
-
--  Repository Location: :oe_git:`/bitbake`
--  Branch: :oe_git:`2.12 </bitbake/log/?h=2.12>`
--  Tag:  :oe_git:`yocto-5.2 </bitbake/log/?h=yocto-5.2>`
--  Git Revision: :oe_git:`5b4e20377eea8d428edf1aeb2187c18f82ca6757 </bitbake/commit/?id=5b4e20377eea8d428edf1aeb2187c18f82ca6757>`
--  Release Artefact: bitbake-5b4e20377eea8d428edf1aeb2187c18f82ca6757
--  sha: 48cff22c1e61f47adce474b636ca865e7e0b62293fc5c8829d09e7f1ac5252af
--  Download Locations:
-   https://downloads.yoctoproject.org/releases/yocto/yocto-5.2/bitbake-5b4e20377eea8d428edf1aeb2187c18f82ca6757.tar.bz2
-   https://mirrors.kernel.org/yocto/yocto/yocto-5.2/bitbake-5b4e20377eea8d428edf1aeb2187c18f82ca6757.tar.bz2
-
-yocto-docs
-
--  Repository Location: :yocto_git:`/yocto-docs`
--  Branch: :yocto_git:`walnascar </yocto-docs/log/?h=walnascar>`
--  Tag: :yocto_git:`yocto-5.2 </yocto-docs/log/?h=yocto-5.2>`
--  Git Revision: :yocto_git:`b8d9cf79d299b2e553e6bc962527d835206022ec </yocto-docs/commit/?id=b8d9cf79d299b2e553e6bc962527d835206022ec>`
-

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

@@ -1,126 +0,0 @@
-.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
-
-.. |yocto-codename| replace:: whinlatter
-.. |yocto-ver| replace:: 5.3
-.. Note: anchors id below cannot contain substitutions so replace them with the
-   value of |yocto-ver| above.
-
-Release notes for |yocto-ver| (|yocto-codename|)
-------------------------------------------------
-
-New Features / Enhancements in |yocto-ver|
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
--  Linux kernel XXX, gcc XXX, glibc XXX, LLVM XXX, and over XXX other
-   recipe upgrades.
-
--  Minimum Python version required on the host: XXX.
-
--  New variables:
-
--  Kernel-related changes:
-
--  New core recipes:
-
--  New core classes:
-
--  Architecture-specific changes:
-
--  QEMU / ``runqemu`` changes:
-
--  Documentation changes:
-
--  Go changes:
-
--  Rust changes:
-
--  Wic Image Creator changes:
-
--  SDK-related changes:
-
--  Testing-related changes:
-
--  Utility script changes:
-
--  BitBake changes:
-
--  Packaging changes:
-
--  LLVM related changes:
-
--  SPDX-related changes:
-
--  ``devtool`` changes:
-
--  Patchtest-related changes:
-
--  :ref:`ref-classes-insane` class related changes:
-
--  Security changes:
-
--  :ref:`ref-classes-cve-check` changes:
-
--  New :term:`PACKAGECONFIG` options for individual recipes:
-
--  Systemd related changes:
-
--  :ref:`ref-classes-sanity` class changes:
-
--  Miscellaneous changes:
-
-Known Issues in |yocto-ver|
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Recipe License changes in |yocto-ver|
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The following changes have been made to the :term:`LICENSE` values set by recipes:
-
-.. list-table::
-   :widths: 20 40 40
-   :header-rows: 1
-
-   * - Recipe
-     - Previous value
-     - New value
-   * - ``recipe name``
-     - Previous value
-     - New value
-
-Security Fixes in |yocto-ver|
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The following CVEs have been fixed:
-
-.. list-table::
-   :widths: 30 70
-   :header-rows: 1
-
-   * - Recipe
-     - CVE IDs
-   * - ``recipe name``
-     - :cve_nist:`xxx-xxxx`, ...
-
-Recipe Upgrades in |yocto-ver|
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The following recipes have been upgraded:
-
-.. list-table::
-   :widths: 20 40 40
-   :header-rows: 1
-
-   * - Recipe
-     - Previous version
-     - New version
-   * - ``recipe name``
-     - Previous version
-     - New version
-
-Contributors to |yocto-ver|
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Thanks to the following people who contributed to this release:
-
-Repositories / Downloads for Yocto-|yocto-ver|
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

documentation/overview-manual/concepts.rst

@@ -98,7 +98,7 @@ files, and how to package the compiled output.
 
 The term "package" is sometimes used to refer to recipes. However, since
 the word "package" is used for the packaged output from the OpenEmbedded
-build system (i.e. ``.ipk``, ``.deb`` or ``.rpm`` files), this document avoids
+build system (i.e. ``.ipk`` or ``.deb`` files), this document avoids
 using the term "package" when referring to recipes.
 
 Classes
@@ -256,7 +256,7 @@ development environment.
 .. note::
 
    The
-   ``scripts/oe-setup-builddir``
+   scripts/oe-setup-builddir
    script uses the
    ``$TEMPLATECONF``
    variable to determine which sample configuration files to locate.
@@ -277,9 +277,6 @@ in the ``meta-poky`` layer:
 -  *Shared State Directory:* Controlled by the
    :term:`SSTATE_DIR` variable.
 
--  *Persistent Data Directory:* Controlled by the
-   :term:`PERSISTENT_DIR` variable.
-
 -  *Build Output:* Controlled by the
    :term:`TMPDIR` variable.
 
@@ -355,7 +352,7 @@ layers the build system uses to further control the build. These layers
 provide Metadata for the software, machine, and policies.
 
 In general, there are three types of layer input. You can see them below
-the "User Configuration" box in the :ref:`general workflow
+the "User Configuration" box in the `general workflow
 figure <overview-manual/concepts:openembedded build system concepts>`:
 
 -  *Metadata (.bb + Patches):* Software layers containing
@@ -423,14 +420,14 @@ build.
 Distro Layer
 ~~~~~~~~~~~~
 
-A distribution layer provides policy configurations for your
+The distribution layer provides policy configurations for your
 distribution. Best practices dictate that you isolate these types of
 configurations into their own layer. Settings you provide in
 ``conf/distro/distro.conf`` override similar settings that BitBake finds
 in your ``conf/local.conf`` file in the :term:`Build Directory`.
 
 The following list provides some explanation and references for what you
-typically find in a distribution layer:
+typically find in the distribution layer:
 
 -  *classes:* Class files (``.bbclass``) hold common functionality that
    can be shared among recipes in the distribution. When your recipes
@@ -457,7 +454,7 @@ typically find in a distribution layer:
 BSP Layer
 ~~~~~~~~~
 
-A BSP layer provides machine configurations that target specific
+The BSP Layer provides machine configurations that target specific
 hardware. Everything in this layer is specific to the machine for which
 you are building the image or the SDK. A common structure or form is
 defined for BSP layers. You can learn more about this structure in the
@@ -468,7 +465,7 @@ defined for BSP layers. You can learn more about this structure in the
    In order for a BSP layer to be considered compliant with the Yocto
    Project, it must meet some structural requirements.
 
-A BSP layer's configuration directory contains configuration files for
+The BSP Layer's configuration directory contains configuration files for
 the machine (``conf/machine/machine.conf``) and, of course, the layer
 (``conf/layer.conf``).
 
@@ -480,18 +477,18 @@ formfactors, graphics support systems, and so forth.
 .. note::
 
    While the figure shows several
-   ``recipes-*``
+   recipes-\*
    directories, not all these directories appear in all BSP layers.
 
 Software Layer
 ~~~~~~~~~~~~~~
 
-A software layer provides the Metadata for additional software
+The software layer provides the Metadata for additional software
 packages used during the build. This layer does not include Metadata
 that is specific to the distribution or the machine, which are found in
 their respective layers.
 
-This layer contains any recipes, append files, and patches that your
+This layer contains any recipes, append files, and patches, that your
 project needs.
 
 Sources
@@ -563,8 +560,9 @@ source tree used by the group).
 
 The canonical method through which to include a local project is to use the
 :ref:`ref-classes-externalsrc` class to include that local project. You use
-either ``local.conf`` or a recipe's append file to override or set the
-recipe to point to the local directory from which to fetch the source.
+either the ``local.conf`` or a recipe's append file to override or set the
+recipe to point to the local directory on your disk to pull in the whole
+source tree.
 
 Source Control Managers (Optional)
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -707,7 +705,7 @@ the Yocto Project Reference Manual.
 
 Each recipe has an area in the :term:`Build Directory` where the unpacked
 source code resides. The :term:`UNPACKDIR` variable points to this area for a
-recipe's unpacked source code, and has the default ``sources`` name. The
+recipe's unpacked source code, and has the default ``sources-unpack`` name. The
 preceding figure and the following list describe the :term:`Build Directory`'s
 hierarchy:
 
@@ -958,7 +956,7 @@ package.
 
   For more information on the ``oe-pkgdata-util`` utility, see the section
   :ref:`dev-manual/debugging:Viewing Package Information with
-  ``oe-pkgdata-util``` of the Yocto Project Development Tasks Manual.
+  \`\`oe-pkgdata-util\`\`` of the Yocto Project Development Tasks Manual.
 
 To add a custom package variant of the ``${PN}`` recipe named
 ``${PN}-extra`` (name is arbitrary), one can add it to the
@@ -2371,6 +2369,8 @@ The contents of ``libhello_0.1.bb`` are::
    # Change <username> accordingly
    SRC_URI = "git://github.com/<username>/libhello;branch=main;protocol=https"
 
+   S = "${WORKDIR}/git"
+
    do_install(){
       install -d ${D}${includedir}
       install -d ${D}${libdir}
@@ -2395,9 +2395,11 @@ The contents of ``sayhello_0.1.bb`` are::
    DEPENDS += "libhello"
    RDEPENDS:${PN} += "libhello"
 
+   S = "${WORKDIR}/git"
+
    do_install(){
-      install -d ${D}${bindir}
-      install -m 0700 sayhello ${D}${bindir}
+      install -d ${D}/usr/bin
+      install -m 0700 sayhello ${D}/usr/bin
    }
 
 After placing the recipes in a custom layer we can run ``bitbake sayhello``

documentation/overview-manual/development-environment.rst

@@ -240,7 +240,7 @@ and so forth.
 
    For information on finding out who is responsible for (maintains) a
    particular area of code in the Yocto Project, see the
-   ":doc:`/contributor-guide/identify-component`"
+   ":doc:`../contributor-guide/identify-component`"
    section of the Yocto Project and OpenEmbedded Contributor Guide.
 
 The Yocto Project ``poky`` Git repository also has an upstream
@@ -272,7 +272,7 @@ push them into the "contrib" area and subsequently request that the
 maintainer include them into an upstream branch. This process is called
 "submitting a patch" or "submitting a change." For information on
 submitting patches and changes, see the
-":doc:`/contributor-guide/submit-changes`" section in the Yocto Project
+":doc:`../contributor-guide/submit-changes`" section in the Yocto Project
 and OpenEmbedded Contributor Guide.
 
 In summary, there is a single point of entry for changes into the
@@ -347,7 +347,7 @@ Book <https://book.git-scm.com>`__.
    this type of change, you format the patch and then send the email
    using the Git commands ``git format-patch`` and ``git send-email``.
    For information on how to use these scripts, see the
-   ":doc:`/contributor-guide/submit-changes`" section in the Yocto Project
+   ":doc:`../contributor-guide/submit-changes`" section in the Yocto Project
    and OpenEmbedded Contributor Guide.
 
 Git

documentation/overview-manual/svg/analysis-for-package-splitting.svg

@@ -1483,12 +1483,12 @@
          x="291.66635"
          y="381.29614"
          style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:10.6667px;font-family:'Nimbus Mono PS';-inkscape-font-specification:'Nimbus Mono PS, Normal';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-variant-east-asian:normal;text-align:start;text-anchor:start;stroke:none;stroke-width:1.42682px"
-         id="tspan15">          sources &lt;────────────────────────────── UNPACKDIR</tspan><tspan
+         id="tspan15">          sources-unpack &lt;─────────────────────── UNPACKDIR</tspan><tspan
          sodipodi:role="line"
          x="291.66635"
          y="394.62952"
          style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:10.6667px;font-family:'Nimbus Mono PS';-inkscape-font-specification:'Nimbus Mono PS, Normal';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-variant-east-asian:normal;text-align:start;text-anchor:start;stroke:none;stroke-width:1.42682px"
-         id="tspan29">            ${BP} &lt;────────────────────────────── S / B</tspan><tspan
+         id="tspan29">          ${BP} &lt;──────────────────────────────── S / B</tspan><tspan
          sodipodi:role="line"
          x="291.66635"
          y="407.96289"
@@ -1543,12 +1543,12 @@
          x="291.66635"
          y="541.29663"
          style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:10.6667px;font-family:'Nimbus Mono PS';-inkscape-font-specification:'Nimbus Mono PS, Normal';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-variant-east-asian:normal;text-align:start;text-anchor:start;stroke:none;stroke-width:1.42682px"
-         id="tspan32">          sources &lt;────────────────────────────── UNPACKDIR</tspan><tspan
+         id="tspan32">          sources-unpack &lt;─────────────────────── UNPACKDIR</tspan><tspan
          sodipodi:role="line"
          x="291.66635"
          y="554.63"
          style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:10.6667px;font-family:'Nimbus Mono PS';-inkscape-font-specification:'Nimbus Mono PS, Normal';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-variant-east-asian:normal;text-align:start;text-anchor:start;stroke:none;stroke-width:1.42682px"
-         id="tspan33">            ${BP} &lt;────────────────────────────── S / B</tspan><tspan
+         id="tspan33">          ${BP} &lt;──────────────────────────────── S / B</tspan><tspan
          sodipodi:role="line"
          x="291.66635"
          y="567.96338"

documentation/overview-manual/svg/configuration-compile-autoreconf.svg

@@ -1277,12 +1277,12 @@
          x="287.2186"
          y="300.76147"
          style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:10.6667px;font-family:'Nimbus Mono PS';-inkscape-font-specification:'Nimbus Mono PS, Normal';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-variant-east-asian:normal;text-align:start;text-anchor:start;stroke:none;stroke-width:1.42682px"
-         id="tspan21">          sources &lt;──────────────────────────── UNPACKDIR</tspan><tspan
+         id="tspan21">          sources-unpack &lt;───────────────────── UNPACKDIR</tspan><tspan
          sodipodi:role="line"
          x="287.2186"
          y="314.09485"
          style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:10.6667px;font-family:'Nimbus Mono PS';-inkscape-font-specification:'Nimbus Mono PS, Normal';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-variant-east-asian:normal;text-align:start;text-anchor:start;stroke:none;stroke-width:1.42682px"
-         id="tspan22">            ${BP} &lt;──────────────────────────── S / B</tspan><tspan
+         id="tspan22">          ${BP} &lt;────────────────────────────── S / B</tspan><tspan
          sodipodi:role="line"
          x="287.2186"
          y="327.42822"
@@ -1322,12 +1322,12 @@
          x="287.2186"
          y="420.76184"
          style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:10.6667px;font-family:'Nimbus Mono PS';-inkscape-font-specification:'Nimbus Mono PS, Normal';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-variant-east-asian:normal;text-align:start;text-anchor:start;stroke:none;stroke-width:1.42682px"
-         id="tspan35">          sources &lt;──────────────────────────── UNPACKDIR</tspan><tspan
+         id="tspan35">          sources-unpack &lt;───────────────────── UNPACKDIR</tspan><tspan
          sodipodi:role="line"
          x="287.2186"
          y="434.09521"
          style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:10.6667px;font-family:'Nimbus Mono PS';-inkscape-font-specification:'Nimbus Mono PS, Normal';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-variant-east-asian:normal;text-align:start;text-anchor:start;stroke:none;stroke-width:1.42682px"
-         id="tspan36">            ${BP} &lt;──────────────────────────── S / B</tspan><tspan
+         id="tspan36">          ${BP} &lt;────────────────────────────── S / B</tspan><tspan
          sodipodi:role="line"
          x="287.2186"
          y="447.42859"

documentation/overview-manual/svg/patching.svg

@@ -1074,12 +1074,12 @@
          x="283.34647"
          y="318.12881"
          style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:10.6667px;font-family:'Nimbus Mono PS';-inkscape-font-specification:'Nimbus Mono PS, Normal';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-variant-east-asian:normal;text-align:start;text-anchor:start;stroke:none;stroke-width:1.42682px"
-         id="tspan21">          sources &lt;─────────────────────────── UNPACKDIR</tspan><tspan
+         id="tspan21">          sources-unpack &lt;──────────────────── UNPACKDIR</tspan><tspan
          sodipodi:role="line"
          x="283.34647"
          y="331.46219"
          style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:10.6667px;font-family:'Nimbus Mono PS';-inkscape-font-specification:'Nimbus Mono PS, Normal';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-variant-east-asian:normal;text-align:start;text-anchor:start;stroke:none;stroke-width:1.42682px"
-         id="tspan31">            ${BP} &lt;─────────────────────────── S</tspan><tspan
+         id="tspan31">          ${BP} &lt;───────────────────────────── S</tspan><tspan
          sodipodi:role="line"
          x="283.34647"
          y="344.79556"
@@ -1099,12 +1099,12 @@
          x="283.34647"
          y="384.79568"
          style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:10.6667px;font-family:'Nimbus Mono PS';-inkscape-font-specification:'Nimbus Mono PS, Normal';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-variant-east-asian:normal;text-align:start;text-anchor:start;stroke:none;stroke-width:1.42682px"
-         id="tspan35">          sources &lt;─────────────────────────── UNPACKDIR</tspan><tspan
+         id="tspan35">          sources-unpack &lt;──────────────────── UNPACKDIR</tspan><tspan
          sodipodi:role="line"
          x="283.34647"
          y="398.12906"
          style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:10.6667px;font-family:'Nimbus Mono PS';-inkscape-font-specification:'Nimbus Mono PS, Normal';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-variant-east-asian:normal;text-align:start;text-anchor:start;stroke:none;stroke-width:1.42682px"
-         id="tspan47">            ${BP} &lt;─────────────────────────── S</tspan></text>
+         id="tspan47">          ${BP} &lt;───────────────────────────── S</tspan></text>
     <text
        xml:space="preserve"
        style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:8.8889px;line-height:125%;font-family:'Nimbus Mono PS';-inkscape-font-specification:'Nimbus Mono PS, Normal';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-variant-east-asian:normal;text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:#000000;stroke-width:1.42682px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"

documentation/overview-manual/svg/source-fetching.svg

@@ -1017,12 +1017,12 @@
          x="281.13275"
          y="317.37775"
          style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:10.6667px;font-family:'Nimbus Mono PS';-inkscape-font-specification:'Nimbus Mono PS, Normal';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-variant-east-asian:normal;text-align:start;text-anchor:start;stroke:none;stroke-width:1.42682px"
-         id="tspan22">          sources &lt;────────────────────────────── UNPACKDIR</tspan><tspan
+         id="tspan22">          sources-unpack &lt;─────────────────────── UNPACKDIR</tspan><tspan
          sodipodi:role="line"
          x="281.13275"
          y="330.71112"
          style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:10.6667px;font-family:'Nimbus Mono PS';-inkscape-font-specification:'Nimbus Mono PS, Normal';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-variant-east-asian:normal;text-align:start;text-anchor:start;stroke:none;stroke-width:1.42682px"
-         id="tspan32">            ${BP} &lt;────────────────────────────── S</tspan><tspan
+         id="tspan32">          ${BP} &lt;──────────────────────────────── S</tspan><tspan
          sodipodi:role="line"
          x="281.13275"
          y="344.04449"
@@ -1042,12 +1042,12 @@
          x="281.13275"
          y="384.04462"
          style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:10.6667px;font-family:'Nimbus Mono PS';-inkscape-font-specification:'Nimbus Mono PS, Normal';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-variant-east-asian:normal;text-align:start;text-anchor:start;stroke:none;stroke-width:1.42682px"
-         id="tspan36">          sources &lt;────────────────────────────── UNPACKDIR</tspan><tspan
+         id="tspan36">          sources-unpack &lt;─────────────────────── UNPACKDIR</tspan><tspan
          sodipodi:role="line"
          x="281.13275"
          y="397.37799"
          style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:10.6667px;font-family:'Nimbus Mono PS';-inkscape-font-specification:'Nimbus Mono PS, Normal';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-variant-east-asian:normal;text-align:start;text-anchor:start;stroke:none;stroke-width:1.42682px"
-         id="tspan44">            ${BP} &lt;────────────────────────────── S</tspan></text>
+         id="tspan44">          ${BP} &lt;──────────────────────────────── S</tspan></text>
     <text
        xml:space="preserve"
        style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:11.5555px;line-height:125%;font-family:'Nimbus Sans L';-inkscape-font-specification:'Nimbus Sans L, Normal';font-variant-ligatures:normal;font-variant-caps:normal;font-variant-numeric:normal;font-variant-east-asian:normal;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;fill:#000000;fill-opacity:1;stroke:#000000;stroke-width:1.42682px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"

documentation/overview-manual/yp-intro.rst

@@ -47,12 +47,10 @@ Here are features and advantages of the Yocto Project:
    see the "COMMUNITY" and "ECOSYSTEM" tabs on the
    :yocto_home:`Yocto Project <>` home page.
 
--  *Architecture Agnostic:* Yocto Project supports Intel, ARM, MIPS, AMD, PPC,
-   RISC-V and other architectures. Most ODMs, OSVs, and chip vendors create and
-   supply BSPs that support their hardware. If you have custom silicon, you can
-   create a BSP that supports that architecture. See
-   :doc:`/ref-manual/yocto-project-supported-features` for details on the level
-   of support for some of these architectures.
+-  *Architecture Agnostic:* Yocto Project supports Intel, ARM, MIPS,
+   AMD, PPC and other architectures. Most ODMs, OSVs, and chip vendors
+   create and supply BSPs that support their hardware. If you have
+   custom silicon, you can create a BSP that supports that architecture.
 
    Aside from broad architecture support, the Yocto Project fully
    supports a wide range of devices emulated by the Quick EMUlator

documentation/poky.yaml.in

@@ -4,18 +4,18 @@
 
 # The DISTRO variable represents the current docs version. It should be used
 # when referring to the current docs version. See also DISTRO_LATEST_TAG.
-DISTRO : "5.2"
+DISTRO : "5.1"
 # The DISTRO_LATEST_TAG represents the latest tag on the current branch. It
 # should be used in HTTP link referring to the current docs version. In these
 # cases, the DISTRO may point to A.B.999 which does not exist (just used to
 # represent the latest HEAD revision on the branch). DISTRO_LATEST_TAG should
 # always point to an existing tag.
-DISTRO_LATEST_TAG : "5.2"
-DISTRO_NAME_NO_CAP : "walnascar"
-DISTRO_NAME : "Walnascar"
-DISTRO_NAME_NO_CAP_MINUS_ONE : "styhead"
+DISTRO_LATEST_TAG : "5.1"
+DISTRO_NAME_NO_CAP : "styhead"
+DISTRO_NAME : "Styhead"
+DISTRO_NAME_NO_CAP_MINUS_ONE : "scarthgap"
 DISTRO_NAME_NO_CAP_LTS : "scarthgap"
-YOCTO_DOC_VERSION : "5.2"
+YOCTO_DOC_VERSION : "5.1"
 DISTRO_REL_TAG : "yocto-$DISTRO;"
 DISTRO_REL_LATEST_TAG : "yocto-&DISTRO_LATEST_TAG;"
 DOCCONF_VERSION : "dev"
@@ -32,4 +32,4 @@ MIN_DISK_SPACE : "90"
 # Disk space (Gbytes) needed to generate qemux86-64 core-image-sato on Ubuntu 22.04 (x86-64) with "rm_work", rounded up from 38
 MIN_DISK_SPACE_RM_WORK : "40"
 # RAM (Gbytes) needed to generate qemux86-64 core-image-sato on Ubuntu 22.04 (x86-64) on a 4 core system
-MIN_RAM : "32"
+MIN_RAM : "8"

documentation/ref-manual/classes.rst

@@ -1591,10 +1591,6 @@ The tests you can list with the :term:`WARN_QA` and
    For example, assignments such as ``FILES:${PN} = "xyz"`` effectively
    turn into ``FILES = "xyz"``.
 
--  ``recipe-naming:`` Checks that the recipe name and recipe class match, so
-   that ``*-native`` recipes inherit :ref:`ref-classes-native` and
-   ``nativesdk-*`` recipes inherit :ref:`ref-classes-nativesdk`.
-
 -  ``rpaths:`` Checks for rpaths in the binaries that contain build
    system paths such as :term:`TMPDIR`. If this test fails, bad ``-rpath``
    options are being passed to the linker commands and your binaries
@@ -1736,158 +1732,77 @@ Its behavior is mainly controlled by the following variables:
 -  :term:`KERNEL_DTC_FLAGS`: flags for ``dtc``, the Device Tree Compiler
 -  :term:`KERNEL_PACKAGE_NAME`: base name of the kernel packages
 
-.. _ref-classes-kernel-fit-image:
+.. _ref-classes-kernel-fitimage:
 
-``kernel-fit-image``
-====================
+``kernel-fitimage``
+===================
 
-The :ref:`ref-classes-kernel-fit-image` class provides support to pack a kernel image,
-device trees, a U-boot script, and an :term:`Initramfs` into a single FIT image.
-In theory, a FIT image can support any number of kernels, U-boot scripts,
-:term:`Initramfs`, and device trees.
-However, :ref:`ref-classes-kernel-fit-image` currently only supports
+The :ref:`ref-classes-kernel-fitimage` class provides support to pack a kernel image,
+device trees, a U-boot script, an :term:`Initramfs` bundle and a RAM disk
+into a single FIT image. In theory, a FIT image can support any number
+of kernels, U-boot scripts, :term:`Initramfs` bundles, RAM disks and device-trees.
+However, :ref:`ref-classes-kernel-fitimage` currently only supports
 limited usecases: just one kernel image, an optional U-boot script,
-an optional :term:`Initramfs`, and any number of device trees.
+an optional :term:`Initramfs` bundle, an optional RAM disk, and any number of
+device trees.
 
-The FIT image is created by a recipe which inherits the
-:ref:`ref-classes-kernel-fit-image` class.
-One such example is the ``linux-yocto-fitimage`` recipe which creates a FIT
-image for the Linux Yocto kernel.
-Additionally, it is required that :term:`KERNEL_CLASSES` is set to include
-:ref:`ref-classes-kernel-fit-extra-artifacts`.
-The :ref:`ref-classes-kernel-fit-extra-artifacts` class exposes the required kernel
-artifacts to the :term:`DEPLOY_DIR_IMAGE` which are used by the
-:ref:`ref-classes-kernel-fit-image` class to create the FIT image.
+To create a FIT image, it is required that :term:`KERNEL_CLASSES`
+is set to include ":ref:`ref-classes-kernel-fitimage`" and one of :term:`KERNEL_IMAGETYPE`,
+:term:`KERNEL_ALT_IMAGETYPE` or :term:`KERNEL_IMAGETYPES` to include "fitImage".
 
-The simplest example for building a FIT image is to add::
+The options for the device tree compiler passed to ``mkimage -D``
+when creating the FIT image are specified using the
+:term:`UBOOT_MKIMAGE_DTCOPTS` variable.
 
-   KERNEL_CLASSES += "kernel-fit-extra-artifacts"
+Only a single kernel can be added to the FIT image created by
+:ref:`ref-classes-kernel-fitimage` and the kernel image in FIT is mandatory. The
+address where the kernel image is to be loaded by U-Boot is
+specified by :term:`UBOOT_LOADADDRESS` and the entrypoint by
+:term:`UBOOT_ENTRYPOINT`. Setting :term:`FIT_ADDRESS_CELLS` to "2"
+is necessary if such addresses are 64 bit ones.
 
-to the machine :term:`configuration file` and to execute::
+Multiple device trees can be added to the FIT image created by
+:ref:`ref-classes-kernel-fitimage` and the device tree is optional.
+The address where the device tree is to be loaded by U-Boot is
+specified by :term:`UBOOT_DTBO_LOADADDRESS` for device tree overlays
+and by :term:`UBOOT_DTB_LOADADDRESS` for device tree binaries.
 
-   bitbake linux-yocto-fitimage
+Only a single RAM disk can be added to the FIT image created by
+:ref:`ref-classes-kernel-fitimage` and the RAM disk in FIT is optional.
+The address where the RAM disk image is to be loaded by U-Boot
+is specified by :term:`UBOOT_RD_LOADADDRESS` and the entrypoint by
+:term:`UBOOT_RD_ENTRYPOINT`. The ramdisk is added to the FIT image when
+:term:`INITRAMFS_IMAGE` is specified and requires that :term:`INITRAMFS_IMAGE_BUNDLE`
+is not set to 1.
 
-This results in a ``fitImage`` file deployed to the :term:`DEPLOY_DIR_IMAGE`
-directory and a ``linux-yocto-fitimage`` package which can be installed.
+Only a single :term:`Initramfs` bundle can be added to the FIT image created by
+:ref:`ref-classes-kernel-fitimage` and the :term:`Initramfs` bundle in FIT is optional.
+In case of :term:`Initramfs`, the kernel is configured to be bundled with the root filesystem
+in the same binary (example: zImage-initramfs-:term:`MACHINE`.bin).
+When the kernel is copied to RAM and executed, it unpacks the :term:`Initramfs` root filesystem.
+The :term:`Initramfs` bundle can be enabled when :term:`INITRAMFS_IMAGE`
+is specified and requires that :term:`INITRAMFS_IMAGE_BUNDLE` is set to 1.
+The address where the :term:`Initramfs` bundle is to be loaded by U-boot is specified
+by :term:`UBOOT_LOADADDRESS` and the entrypoint by :term:`UBOOT_ENTRYPOINT`.
 
-The same approach works for all variants of the ``linux-yocto`` kernel.
-For example, if the ``linux-yocto-rt`` kernel should be used, add the following
-lines to the machine configuration file::
+Only a single U-boot boot script can be added to the FIT image created by
+:ref:`ref-classes-kernel-fitimage` and the boot script is optional.
+The boot script is specified in the ITS file as a text file containing
+U-boot commands. When using a boot script the user should configure the
+U-boot :ref:`ref-tasks-install` task to copy the script to sysroot.
+So the script can be included in the FIT image by the :ref:`ref-classes-kernel-fitimage`
+class. At run-time, U-boot CONFIG_BOOTCOMMAND define can be configured to
+load the boot script from the FIT image and execute it.
 
-   KERNEL_CLASSES += "kernel-fit-extra-artifacts"
-   PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-rt"
+The FIT image generated by the :ref:`ref-classes-kernel-fitimage` class is signed when the
+variables :term:`UBOOT_SIGN_ENABLE`, :term:`UBOOT_MKIMAGE_DTCOPTS`,
+:term:`UBOOT_SIGN_KEYDIR` and :term:`UBOOT_SIGN_KEYNAME` are set
+appropriately. The default values used for :term:`FIT_HASH_ALG` and
+:term:`FIT_SIGN_ALG` in :ref:`ref-classes-kernel-fitimage` are "sha256" and
+"rsa2048" respectively. The keys for signing the FIT image can be generated using
+the :ref:`ref-classes-kernel-fitimage` class when both :term:`FIT_GENERATE_KEYS` and
+:term:`UBOOT_SIGN_ENABLE` are set to "1".
 
-The FIT image, this time including the RT kernel, is built again by calling::
-
-   bitbake linux-yocto-fitimage
-
-For other kernels provided by other layers, the same approach would work.
-However, it is usually more intuitive to add a custom FIT image recipe next to
-the custom kernel recipe.
-For example, if a layer provides a ``linux-vanilla`` recipe, a
-``linux-vanilla-fitimage`` recipe may be added as well.
-The ``linux-vanilla-fitimage`` recipe can be created as a customized copy of
-the ``linux-yocto-fitimage`` recipe.
-
-Usually the kernel is built as a dependency of an image.
-If the FIT image should be used as a replacement for the kernel image which
-is installed in the root filesystem, then the following variables can be set
-e.g. in the machine configuration file::
-
-   # Create and deploy the vmlinux artifact which gets included into the FIT image
-   KERNEL_CLASSES += "kernel-fit-extra-artifacts"
-
-   # Do not install the kernel image package
-   RRECOMMENDS:${KERNEL_PACKAGE_NAME}-base = ""
-   # Install the FIT image package
-   MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "linux-yocto-fitimage"
-
-   # Configure the image.bbclass to depend on the FIT image instead of only
-   # the kernel to ensure the FIT image is built and deployed with the image
-   KERNEL_DEPLOY_DEPEND = "linux-yocto-fitimage:do_deploy"
-
-The :ref:`ref-classes-kernel-fit-image` class processes several variables that
-allow configuration:
-
--  The options for the device tree compiler passed to ``mkimage -D``
-   when creating the FIT image are specified using the
-   :term:`UBOOT_MKIMAGE_DTCOPTS` variable.
-
--  Only a single kernel can be added to the FIT image created by
-   :ref:`ref-classes-kernel-fit-image` and it is a mandatory component of the
-   FIT image.
-   The address where the kernel image is to be loaded by U-Boot is
-   specified by :term:`UBOOT_LOADADDRESS` and the entrypoint by
-   :term:`UBOOT_ENTRYPOINT`. Setting :term:`FIT_ADDRESS_CELLS` to "2"
-   is necessary if such addresses are 64 bit ones.
-
--  Multiple device trees can be added to the FIT image created by
-   :ref:`ref-classes-kernel-fit-image` and the device tree is optional.
-   The address where the device tree is to be loaded by U-Boot is
-   specified by :term:`UBOOT_DTBO_LOADADDRESS` for device tree overlays
-   and by :term:`UBOOT_DTB_LOADADDRESS` for device tree binaries.
-
--  Only a single :term:`Initramfs` can be added to the FIT image created by
-   :ref:`ref-classes-kernel-fit-image`. The :term:`Initramfs` in FIT is optional.
-   The address where the RAM disk image is to be loaded by U-Boot
-   is specified by :term:`UBOOT_RD_LOADADDRESS` and the entrypoint by
-   :term:`UBOOT_RD_ENTRYPOINT`. The :term:`Initramfs` is added to the FIT image
-   when :term:`INITRAMFS_IMAGE` is specified.
-
--  It's recommended to add the :term:`Initramfs` and the kernel image as
-   independent image nodes to the FIT image.
-   Bundling a RAM disk image with the kernel image and including the bundle
-   (:term:`INITRAMFS_IMAGE_BUNDLE` set to "1") in the FIT image is possible.
-   However, this approach has the disadvantage that any change to the RAM
-   disk image necessitates rebuilding the kernel image.
-   This process requires the full kernel build directory, which is kind of
-   incompatible with the :term:`SSTATE_DIR` and, consequently, with SDKs.
-
--  Only a single U-Boot boot script can be added to the FIT image created by
-   :ref:`ref-classes-kernel-fit-image`. The boot script is optional.
-   The boot script is specified in the ITS file as a text file containing
-   U-Boot commands. When using a boot script the recipe which inherits the
-   :ref:`ref-classes-kernel-fit-image` class should add the script to
-   :term:`SRC_URI` and set the :term:`FIT_UBOOT_ENV` variable to the name of the
-   file like the following::
-
-      FIT_UBOOT_ENV = "boot.txt"
-      SRC_URI += "file://${FIT_UBOOT_ENV}"
-
-   At run-time, U-boot's boot command can be configured to load the boot script
-   from the FIT image and source it.
-
--  The FIT image generated by the :ref:`ref-classes-kernel-fit-image` class is signed when the
-   variables :term:`UBOOT_SIGN_ENABLE`, :term:`UBOOT_MKIMAGE_DTCOPTS`,
-   :term:`UBOOT_SIGN_KEYDIR` and :term:`UBOOT_SIGN_KEYNAME` are set
-   appropriately. The default values used for :term:`FIT_HASH_ALG` and
-   :term:`FIT_SIGN_ALG` in :ref:`ref-classes-kernel-fit-image` are "sha256" and
-   "rsa2048" respectively. The keys for signing the FIT image can be generated using
-   the :ref:`ref-classes-kernel-fit-image` class when both :term:`FIT_GENERATE_KEYS` and
-   :term:`UBOOT_SIGN_ENABLE` are set to "1".
-
-.. _ref-classes-kernel-fit-extra-artifacts:
-
-``kernel-fit-extra-artifacts``
-==============================
-
-The :ref:`ref-classes-kernel-fit-extra-artifacts` class exposes the required
-kernel artifacts to the :term:`DEPLOY_DIR_IMAGE` directory.
-These artifacts are used by the :ref:`ref-classes-kernel-fit-image` class to
-create a FIT image that can include the kernel, device trees, an optional
-U-Boot script, and an optional Initramfs.
-
-This class is typically included by adding it to the :term:`KERNEL_CLASSES`
-variable in your kernel recipe or machine configuration when building FIT images.
-It ensures that all necessary files are available for packaging into the FIT image,
-such as the kernel binary, device tree blobs (DTBs), and other related files.
-
-For example, to enable this class, set::
-
-   KERNEL_CLASSES += "kernel-fit-extra-artifacts"
-
-This is required when using the :ref:`ref-classes-kernel-fit-image` class to
-generate FIT images for your kernel.
 
 .. _ref-classes-kernel-grub:
 
@@ -2135,8 +2050,7 @@ a couple different ways:
       Not using this naming convention can lead to subtle problems
       caused by existing code that depends on that naming convention.
 
--  Or, create a :ref:`ref-classes-native` variant of any target recipe (e.g.
-   ``myrecipe.bb``) by adding the following to the recipe::
+-  Create or modify a target recipe that contains the following::
 
       BBCLASSEXTEND = "native"
 
@@ -2167,18 +2081,7 @@ couple different ways:
    inherit statement in the recipe after all other inherit statements so
    that the :ref:`ref-classes-nativesdk` class is inherited last.
 
-   .. note::
-
-      When creating a recipe, you must follow this naming convention::
-
-              nativesdk-myrecipe.bb
-
-
-      Not doing so can lead to subtle problems because there is code that
-      depends on the naming convention.
-
--  Or, create a :ref:`ref-classes-nativesdk` variant of any target recipe (e.g.
-   ``myrecipe.bb``) by adding the following to the recipe::
+-  Create a :ref:`ref-classes-nativesdk` variant of any recipe by adding the following::
 
        BBCLASSEXTEND = "nativesdk"
 
@@ -2187,6 +2090,16 @@ couple different ways:
    specify any functionality specific to the respective SDK machine or
    target case.
 
+.. note::
+
+   When creating a recipe, you must follow this naming convention::
+
+           nativesdk-myrecipe.bb
+
+
+   Not doing so can lead to subtle problems because there is code that
+   depends on the naming convention.
+
 Although applied differently, the :ref:`ref-classes-nativesdk` class is used with both
 methods. The advantage of the second method is that you do not need to
 have two separate recipes (assuming you need both) for the SDK machine
@@ -3513,8 +3426,6 @@ The variables used by this class are:
 -  :term:`UBOOT_FIT_USER_SETTINGS`: adds a user-specific snippet to the U-Boot
    Image Tree Source (ITS). Users can include their custom U-Boot Image Tree
    Source (ITS) snippet in this variable.
--  :term:`UBOOT_FIT_CONF_FIRMWARE`: adds one image to the ``firmware`` property
-   of the configuration node.
 -  :term:`UBOOT_FIT_CONF_USER_LOADABLES`: adds one or more user-defined images
    to the ``loadables`` property of the configuration node.
 
@@ -3523,7 +3434,7 @@ See U-Boot's documentation for details about `verified boot
 and the `signature process
 <https://source.denx.de/u-boot/u-boot/-/blob/master/doc/uImage.FIT/signature.txt>`__.
 
-See also the description of :ref:`ref-classes-kernel-fit-image` class, which this class
+See also the description of :ref:`ref-classes-kernel-fitimage` class, which this class
 imitates.
 
 .. _ref-classes-uki:
@@ -3541,7 +3452,7 @@ on target hardware. Using ``systemd`` as init is recommended. Image builds
 should create an ESP partition for UEFI firmware and copy ``systemd-boot`` and
 UKI files there. Sample configuration for Wic images is provided in
 :oe_git:`scripts/lib/wic/canned-wks/efi-uki-bootdisk.wks.in
-</openembedded-core/tree/scripts/lib/wic/canned-wks/efi-uki-bootdisk.wks.in>`.
+<openembedded-core/tree/scripts/lib/wic/canned-wks/efi-uki-bootdisk.wks.in>`.
 UKIs are generated using ``systemd`` reference implementation `ukify
 <https://www.freedesktop.org/software/systemd/man/latest/ukify.html>`__.
 This class uses a number of variables but tries to find sensible defaults for
@@ -3551,7 +3462,7 @@ The variables used by this class are:
 
 -  :term:`EFI_ARCH`: architecture name within EFI standard, set in
    :oe_git:`meta/conf/image-uefi.conf
-   </openembedded-core/tree/meta/conf/image-uefi.conf>`
+   <openembedded-core/tree/meta/conf/image-uefi.conf>`
 -  :term:`IMAGE_EFI_BOOT_FILES`: files to install to EFI boot partition
    created by the ``bootimg-efi`` Wic plugin
 -  :term:`INITRAMFS_IMAGE`: initramfs recipe name
@@ -3570,9 +3481,9 @@ The variables used by this class are:
 
 For examples on how to use this class see oeqa selftest
 :oe_git:`meta/lib/oeqa/selftest/cases/uki.py
-</openembedded-core/tree/meta/lib/oeqa/selftest/cases/uki.py>`.
+<openembedded-core/tree/meta/lib/oeqa/selftest/cases/uki.py>`.
 Also an oeqa runtime test :oe_git:`meta/lib/oeqa/runtime/cases/uki.py
-</openembedded-core/tree/meta/lib/oeqa/runtime/cases/uki.py>` is provided which
+<openembedded-core/tree/meta/lib/oeqa/runtime/cases/uki.py>` is provided which
 verifies that the target system booted the same UKI binary as was set at
 buildtime via :term:`UKI_FILENAME`.
 

documentation/ref-manual/devtool-reference.rst

@@ -435,7 +435,7 @@ You can read more on the ``devtool upgrade`` workflow in the
 ":ref:`dev-manual/devtool:use \`\`devtool upgrade\`\` to create a version of the recipe that supports a newer version of the software`"
 section in the Yocto Project Application Development and the Extensible
 Software Development Kit (eSDK) manual. You can also see an example of
-how to use ``devtool upgrade`` in the ":ref:`dev-manual/upgrading-recipes:using ``devtool upgrade```"
+how to use ``devtool upgrade`` in the ":ref:`dev-manual/upgrading-recipes:using \`\`devtool upgrade\`\``"
 section in the Yocto Project Development Tasks Manual.
 
 .. _devtool-resetting-a-recipe:

documentation/ref-manual/index.rst

@@ -11,7 +11,6 @@ Yocto Project Reference Manual
    :numbered:
 
    system-requirements
-   yocto-project-supported-features
    terms
    release-process
    structure