build-appliance-image: Update to master head revision

(From OE-Core rev: fed2692c4e7b87fd2bf08a5abb4391b79bbfc982)

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.0"
+__version__ = "2.15.1"
 
 if __name__ == "__main__":
     if __version__ != bb.__version__:

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 = bool(int(sys.argv[8]))
+profile = sys.argv[8]
 xmlrpcinterface = (sys.argv[9], int(sys.argv[10]))
 if xmlrpcinterface[0] == "None":
     xmlrpcinterface = (None, xmlrpcinterface[1])

bitbake/bin/bitbake-worker

@@ -182,11 +182,8 @@ def fork_off_task(cfg, data, databuilder, workerdata, extraconfigdata, runtask):
     elif workerdata["umask"]:
         umask = workerdata["umask"]
     if umask:
-        # umask might come in as a number or text string..
-        try:
-             umask = int(umask, 8)
-        except TypeError:
-             pass
+        # Convert to a python numeric value as it could be a string
+        umask = bb.utils.to_filemode(umask)
 
     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('WORKDIR')
+   rootdir = l.getVar('UNPACKDIR')
    fetcher.unpack(rootdir)
 
-This code unpacks the downloaded files to the specified by ``WORKDIR``.
+This code unpacks the downloaded files to the specified by ``UNPACKDIR``.
 
 .. note::
 
@@ -51,7 +51,7 @@ This code unpacks the downloaded files to the specified by ``WORKDIR``.
    examine the OpenEmbedded class file ``base.bbclass``
    .
 
-The :term:`SRC_URI` and ``WORKDIR`` variables are not hardcoded into the
+The :term:`SRC_URI` and ``UNPACKDIR`` 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,13 +436,15 @@ 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. The default is
-   "master".
+-  *"rev":* The revision to use for the checkout. If :term:`SRCREV` is also set,
+   this parameter must match its value.
 
--  *"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.
+-  *"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.
 
 -  *"subpath":* Limits the checkout to a specific subpath of the tree.
    By default, the whole tree is checked out.
@@ -461,13 +463,6 @@ 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.
@@ -598,7 +593,7 @@ and port, username, and password, and fetches the Head Revision::
    SRC_URI = "p4://example-depot/main/source/..."
    SRCREV = "${AUTOREV}"
    PV = "p4-${SRCPV}"
-   S = "${WORKDIR}/p4"
+   S = "${UNPACKDIR}/p4"
 
 Here is an example that specifies the server URL and port, username, and
 password, and fetches a Revision based on a Label::
@@ -607,15 +602,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 = "${WORKDIR}/p4"
+   S = "${UNPACKDIR}/p4"
 
 .. note::
 
-   You should always set S to "${WORKDIR}/p4" in your recipe.
+   You should always set S to "${UNPACKDIR}/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 ``${WORKDIR}/p4``.  For situations where preserving parts of the remote depot
+in ``${UNPACKDIR}/p4``.  For situations where preserving parts of the remote depot
 paths locally is desirable, the fetcher supports two parameters:
 
 - *"module":*

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
+   addfragments conf/fragments OE_FRAGMENTS OE_FRAGMENTS_METADATA_VARS OE_BUILTIN_FRAGMENTS
 
-``addfragments`` takes three parameters:
+``addfragments`` takes four parameters:
 
 -  path prefix for fragment files inside the layer file tree that bitbake
    uses to construct full paths to the fragment files
@@ -1011,6 +1011,8 @@ 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::
 
@@ -1035,6 +1037,19 @@ 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
 =========
 

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

@@ -310,6 +310,11 @@ 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>`_.
@@ -533,11 +538,28 @@ 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).
+      1000000 (a pressure value unlikely to ever be reached). See
+      https://docs.kernel.org/accounting/psi.html for more information.
 
-      This threshold can be set in ``conf/local.conf`` as::
+      A default value to limit the CPU pressure to be set in ``conf/local.conf``
+      could be::
 
-         BB_PRESSURE_MAX_CPU = "500"
+         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.
 
    :term:`BB_PRESSURE_MAX_IO`
       Specifies a maximum I/O pressure threshold, above which BitBake's
@@ -549,14 +571,34 @@ 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).
+      1000000 (a pressure value unlikely to ever be reached). See
+      https://docs.kernel.org/accounting/psi.html for more information.
 
       At this point in time, experiments show that IO pressure tends to
       be short-lived and regulating just the CPU with
       :term:`BB_PRESSURE_MAX_CPU` can help to reduce it.
 
-   :term:`BB_PRESSURE_MAX_MEMORY`
+      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
@@ -566,7 +608,8 @@ 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).
+      1000000 (a pressure value unlikely to ever be reached). See
+      https://docs.kernel.org/accounting/psi.html for more information.
 
       Memory pressure is experienced when time is spent swapping,
       refaulting pages from the page cache or performing direct reclaim.
@@ -574,6 +617,26 @@ 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/lib/bb/__init__.py

@@ -9,7 +9,7 @@
 # SPDX-License-Identifier: GPL-2.0-only
 #
 
-__version__ = "2.15.0"
+__version__ = "2.15.1"
 
 import sys
 if sys.version_info < (3, 9, 0):
@@ -37,6 +37,34 @@ 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):

bitbake/lib/bb/asyncrpc/serv.py

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

bitbake/lib/bb/cooker.py

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

bitbake/lib/bb/event.py

@@ -236,9 +236,12 @@ def fire(event, d):
         # If messages have been queued up, clear the queue
         global _uiready, ui_queue
         if _uiready and ui_queue:
-            for queue_event in ui_queue:
+            with bb.utils.lock_timeout_nocheck(_thread_lock):
+                queue = ui_queue
+                ui_queue = []
+            for queue_event in queue:
                 fire_ui_handlers(queue_event, d)
-            ui_queue = []
+
         fire_ui_handlers(event, d)
 
 def fire_from_worker(event, d):

bitbake/lib/bb/fetch2/git.py

@@ -199,6 +199,8 @@ 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:
@@ -633,8 +635,6 @@ 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/')
@@ -660,7 +660,7 @@ class Git(FetchMethod):
         subdir = ud.parm.get("subdir")
         subpath = ud.parm.get("subpath")
         readpathspec = ""
-        def_destsuffix = "git/"
+        def_destsuffix = (d.getVar("BB_GIT_DEFAULT_DESTSUFFIX") or "git") + "/"
 
         if subpath:
             readpathspec = ":%s" % subpath

bitbake/lib/bb/main.py

@@ -208,8 +208,10 @@ 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="store_true",
-                        help="Profile the command and save reports.")
+    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("-S", "--dump-signatures", action="append",
                         default=[], metavar="SIGNATURE_HANDLER",

bitbake/lib/bb/parse/ast.py

@@ -343,11 +343,12 @@ class InheritDeferredNode(AstNode):
         bb.parse.BBHandler.inherit_defer(*self.inherit, data)
 
 class AddFragmentsNode(AstNode):
-    def __init__(self, filename, lineno, fragments_path_prefix, fragments_variable, flagged_variables_list_variable):
+    def __init__(self, filename, lineno, fragments_path_prefix, fragments_variable, flagged_variables_list_variable, builtin_fragments_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
@@ -360,13 +361,23 @@ 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)
@@ -430,7 +441,8 @@ def handleAddFragments(statements, filename, lineno, m):
     fragments_path_prefix = m.group(1)
     fragments_variable = m.group(2)
     flagged_variables_list_variable = m.group(3)
-    statements.append(AddFragmentsNode(filename, lineno, fragments_path_prefix, fragments_variable, flagged_variables_list_variable))
+    builtin_fragments_variable = m.group(4)
+    statements.append(AddFragmentsNode(filename, lineno, fragments_path_prefix, fragments_variable, flagged_variables_list_variable, builtin_fragments_variable))
 
 def runAnonFuncs(d):
     code = []

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

@@ -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+(.+)" )
+__addfragments_regexp__  = re.compile(r"addfragments\s+(.+)\s+(.+)\s+(.+)\s+(.+)" )
 
 def init(data):
     return

bitbake/lib/bb/server/process.py

@@ -13,7 +13,7 @@
 import bb
 import bb.event
 import logging
-import multiprocessing
+from bb import multiprocessing
 import threading
 import array
 import os
@@ -80,9 +80,6 @@ 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
@@ -140,23 +137,7 @@ class ProcessServer():
             serverlog("Error writing to lock file: %s" % str(e))
             pass
 
-        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
+        return bb.utils.profile_function("main" in self.cooker.configuration.profile, self.main, "profile-mainloop.log")
 
     def _idle_check(self):
         return len(self._idlefuns) == 0 and self.cooker.command.currentAsyncCommand is None
@@ -417,20 +398,7 @@ class ProcessServer():
                 serverlog("".join(msg))
 
     def idle_thread(self):
-        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()
+        bb.utils.profile_function("idle" in self.cooker.configuration.profile, self.idle_thread_internal, "profile-idleloop.log")
 
     def idle_thread_internal(self):
         def remove_idle_func(function):
@@ -632,7 +600,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(int(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(list(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) as e:
+            except (ConnectionError, FileNotFoundError, EOFError) 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) as e:
+            except (ConnectionError, FileNotFoundError, EOFError) 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) as e:
+        except (ConnectionError, FileNotFoundError, EOFError) as e:
             bb.warn('Error contacting Hash Equivalence Server %s: %s' % (self.server, str(e)))
 
         return False

bitbake/lib/bb/tests/fetch.py

@@ -1465,7 +1465,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://source.denx.de/u-boot/u-boot.git;branch=master;protocol=https", "62c175fbb8a0f9a926c88294ea9f7e88eb898f6c", "", "")
+        ("u-boot-mkimage", "git://git.yoctoproject.org/bbfetchtests-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", "", "")

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"
-oo_package_write_ipk[rdeptask] = "${DEBIANRDEP}"
+do_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
-import multiprocessing
+from bb 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,3 +692,14 @@ 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
+from functools import partial, wraps
 from contextlib import contextmanager
 
 import bb.cache
@@ -27,6 +27,135 @@ 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
@@ -700,6 +829,10 @@ 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/utils.py

@@ -12,7 +12,7 @@ import sys
 import errno
 import logging
 import locale
-import multiprocessing
+from bb import multiprocessing
 import importlib
 import importlib.machinery
 import importlib.util
@@ -1211,6 +1211,23 @@ def which(path, item, direction = 0, history = False, executable=False):
         return "", hist
     return ""
 
+def to_filemode(input):
+    """
+    Take a bitbake variable contents defining a file mode and return
+    the proper python representation of the number
+
+    Arguments:
+
+    -  ``input``: a string or number to convert, e.g. a bitbake variable
+       string, assumed to be an octal representation
+
+    Returns the python file mode as a number
+    """
+    # umask might come in as a number or text string..
+    if type(input) is int:
+        return input
+    return int(input, 8)
+
 @contextmanager
 def umask(new_mask):
     """
@@ -1401,42 +1418,66 @@ def cpu_count():
 def nonblockingfd(fd):
     fcntl.fcntl(fd, fcntl.F_SETFL, fcntl.fcntl(fd, fcntl.F_GETFL) | os.O_NONBLOCK)
 
-def process_profilelog(fn, pout = None):
-    # Either call with a list of filenames and set pout or a filename and optionally pout.
-    if not pout:
-        pout = fn + '.processed'
+def profile_function(profile, function, output_fn, process=True):
+    """Common function to profile a code block and optionally process the
+    output using or processing function.
 
-    with open(pout, 'w') as pout:
-        import pstats
+    Arguments:
+
+    -  ``profile``: a boolean saying whether to enable profiling or not
+    -  ``function``: the function call to profile/run
+    -  ``outputfn``: where to write the profiling data
+    -  ``process``: whether to process the profiling data and write a report
+
+    Returns the wrapped function return value
+    """
+    if profile:
+        try:
+            import cProfile as profile
+        except:
+             import profile
+        prof = profile.Profile()
+        ret = profile.Profile.runcall(prof, function)
+        prof.dump_stats(output_fn)
+        if process:
+            process_profilelog(output_fn)
+            serverlog("Raw profiling information saved to %s and processed statistics to %s.report*" % (output_fn, output_fn))
+        return ret
+    else:
+        return function()
+
+def process_profilelog(fn, fn_out = None):
+    # Either call with a list of filenames and set pout or a filename and optionally pout.
+    import pstats
+
+    if not fn_out:
+        fn_out = fn + '.report'
+
+    def pstatopen():
         if isinstance(fn, list):
-            p = pstats.Stats(*fn, stream=pout)
-        else:
-            p = pstats.Stats(fn, stream=pout)
+            return pstats.Stats(*fn, stream=pout)
+        return pstats.Stats(fn, stream=pout)
+
+    with open(fn_out + '.time', 'w') as pout:
+        p = pstatopen()
         p.sort_stats('time')
         p.print_stats()
+
+    with open(fn_out + '.time-callers', 'w') as pout:
+        p = pstatopen()
+        p.sort_stats('time')
         p.print_callers()
+
+    with open(fn_out + '.cumulative', 'w') as pout:
+        p = pstatopen()
         p.sort_stats('cumulative')
         p.print_stats()
 
-        pout.flush()
+    with open(fn_out + '.cumulative-callers', 'w') as pout:
+        p = pstatopen()
+        p.sort_stats('cumulative')
+        p.print_callers()
 
-#
-# Was present to work around multiprocessing pool bugs in python < 2.7.3
-#
-def multiprocessingpool(*args, **kwargs):
-
-    import multiprocessing.pool
-    #import multiprocessing.util
-    #multiprocessing.util.log_to_stderr(10)
-    # Deal with a multiprocessing bug where signals to the processes would be delayed until the work
-    # completes. Putting in a timeout means the signals (like SIGINT/SIGTERM) get processed.
-    def wrapper(func):
-        def wrap(self, timeout=None):
-            return func(self, timeout=timeout if timeout is not None else 1e100)
-        return wrap
-    multiprocessing.pool.IMapIterator.next = wrapper(multiprocessing.pool.IMapIterator.next)
-
-    return multiprocessing.Pool(*args, **kwargs)
 
 def exec_flat_python_func(func, *args, **kwargs):
     """Execute a flat python function (defined with ``def funcname(args): ...``)
@@ -2181,6 +2222,15 @@ def path_is_descendant(descendant, ancestor):
 
     return False
 
+# Recomputing the sets in signal.py is expensive (bitbake -pP idle)
+# so try and use _signal directly to avoid it
+valid_signals = signal.valid_signals()
+try:
+    import _signal
+    sigmask = _signal.pthread_sigmask
+except ImportError:
+    sigmask = signal.pthread_sigmask
+
 # If we don't have a timeout of some kind and a process/thread exits badly (for example
 # OOM killed) and held a lock, we'd just hang in the lock futex forever. It is better
 # we exit at some point than hang. 5 minutes with no progress means we're probably deadlocked.
@@ -2190,7 +2240,7 @@ def path_is_descendant(descendant, ancestor):
 @contextmanager
 def lock_timeout(lock):
     try:
-        s = signal.pthread_sigmask(signal.SIG_BLOCK, signal.valid_signals())
+        s = sigmask(signal.SIG_BLOCK, valid_signals)
         held = lock.acquire(timeout=5*60)
         if not held:
             bb.server.process.serverlog("Couldn't get the lock for 5 mins, timed out, exiting.\n%s" % traceback.format_stack())
@@ -2198,17 +2248,17 @@ def lock_timeout(lock):
         yield held
     finally:
         lock.release()
-        signal.pthread_sigmask(signal.SIG_SETMASK, s)
+        sigmask(signal.SIG_SETMASK, s)
 
 # A version of lock_timeout without the check that the lock was locked and a shorter timeout
 @contextmanager
 def lock_timeout_nocheck(lock):
     l = False
     try:
-        s = signal.pthread_sigmask(signal.SIG_BLOCK, signal.valid_signals())
+        s = sigmask(signal.SIG_BLOCK, valid_signals)
         l = lock.acquire(timeout=10)
         yield l
     finally:
         if l:
             lock.release()
-        signal.pthread_sigmask(signal.SIG_SETMASK, s)
+        sigmask(signal.SIG_SETMASK, s)

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
-import multiprocessing
+from bb import multiprocessing
 import os
 import sys
 import tempfile

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

@@ -108,6 +108,8 @@ 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/functional/test_project_page.py

@@ -685,17 +685,17 @@ class TestProjectPage(TestProjectPageBase):
             'active', str(self.find('#information').get_attribute('class'))
         )
         # Check second tab (recipes)
-        # Ensure page is scrolled to the top
-        self.driver.find_element(By.XPATH, '//body').send_keys(Keys.CONTROL + Keys.HOME)
         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})')
         tabs[1].click()
         self.assertIn(
             'active', str(self.find('#recipes').get_attribute('class'))
         )
         # Check third tab (machines)
-        # Ensure page is scrolled to the top
-        self.driver.find_element(By.XPATH, '//body').send_keys(Keys.CONTROL + Keys.HOME)
         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})')
         tabs[2].click()
         self.assertIn(
             'active', str(self.find('#machines').get_attribute('class'))

documentation/README

@@ -314,6 +314,16 @@ 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
 ==========
 

documentation/bsp-guide/bsp.rst

@@ -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>` file.
+   :yocto_git:`README </meta-intel/tree/README.md>` 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 -al`` command. See the
+         branch -a`` command. See the
          ":ref:`dev-manual/start:checking out by branch in poky`"
          section in the Yocto Project Development Tasks Manual for more
          information.
@@ -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_4.4.bb`` recipe to build the
+Suppose you are using the ``linux-yocto_6.12.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 ?= "4.4%"
+   PREFERRED_VERSION_linux-yocto ?= "6.12%"
 
 .. 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_4.4.bbappend`` file to append specific
+You would use the ``linux-yocto_6.12.bbappend`` file to append specific
 BSP settings to the kernel, thus configuring the kernel for your
 particular BSP.
 
@@ -698,14 +698,19 @@ 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 you see the following::
+``recipes-kernel/linux`` directory in that layer you see the following
+Raspberry Pi-specific recipes and associated files::
 
+   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_4.14.bb
-   linux-raspberrypi_4.9.bb
-
-The directory contains three kernel recipes and a common include file.
+   linux-raspberrypi-v7_6.12.bb
+   linux-raspberrypi-v7_6.1.bb
+   linux-raspberrypi-v7_6.6.bb
+   linux-raspberrypi-v7.inc
 
 Developing a Board Support Package (BSP)
 ========================================
@@ -876,7 +881,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
@@ -910,7 +915,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.
@@ -1177,7 +1182,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_4.12.bb``). The BSP
+   new custom kernel recipe file (e.g. ``linux-yocto_6.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
@@ -1242,7 +1247,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 kernel-devicetree"
+   MACHINE_EXTRA_RRECOMMENDS = "kernel-modules"
 
    EXTRA_IMAGEDEPENDS += "virtual/bootloader"
 
@@ -1258,23 +1263,21 @@ 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.1%"
+   PREFERRED_VERSION_linux-yocto ?= "6.12%"
 
    KERNEL_IMAGETYPE = "zImage"
-   KERNEL_DEVICETREE = "am335x-bone.dtb am335x-boneblack.dtb am335x-bonegreen.dtb"
-   KERNEL_EXTRA_ARGS += "LOADADDR=${UBOOT_ENTRYPOINT}"
+   DTB_FILES = "am335x-bone.dtb am335x-boneblack.dtb am335x-bonegreen.dtb"
+   KERNEL_DEVICETREE = '${@' '.join('ti/omap/%s' % d for d in '${DTB_FILES}'.split())}'
 
    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} ${KERNEL_DEVICETREE}"
+   IMAGE_BOOT_FILES ?= "u-boot.${UBOOT_SUFFIX} ${SPL_BINARY} ${KERNEL_IMAGETYPE} ${DTB_FILES}"
 
    # support runqemu
    EXTRA_IMAGEDEPENDS += "qemu-native qemu-helper-native"
@@ -1328,12 +1331,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 setings to implement
+   At the end of the file, we also use this setting to implement
    ``runqemu`` support on the host machine.
 
 -  :term:`DEFAULTTUNE`: Machines
    use tunings to optimize machine, CPU, and application performance.
-   These features, which are collectively known as "tuning features",
+   These features --- 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>`.
@@ -1363,8 +1366,7 @@ Project Reference Manual.
    to create the sysroot when building a Wic image.
 
 -  :term:`SERIAL_CONSOLES`:
-   Defines a serial console (TTY) to enable using getty. In this case,
-   the baud rate is "115200" and the device name is "ttyO0".
+   Defines one or more serial consoles (TTYs) to enable using getty.
 
 -  :term:`PREFERRED_PROVIDER_virtual/kernel <PREFERRED_PROVIDER>`:
    Specifies the recipe that provides "virtual/kernel" when more than
@@ -1374,7 +1376,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.1" in this case.
+   "6.12" in this case.
 
 -  :term:`KERNEL_IMAGETYPE`:
    The type of kernel to build for the device. In this case, the
@@ -1416,12 +1418,6 @@ 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

@@ -179,13 +179,13 @@ from sphinx.search import SearchEnglish
 from sphinx.search import languages
 class DashFriendlySearchEnglish(SearchEnglish):
 
-    # Accept words that can include hyphens
-    _word_re = re.compile(r'[\w\-]+')
+    # 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)
+        .split(/[^\p{Letter}\p{Number}_\p{Emoji_Presentation}\-\.]+/gu)
         .filter(term => term.length > 0);
 }
 """

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
@@ -872,7 +872,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:`recipe-style-guide`, and contributing the changes with
+including in the :doc:`/contributor-guide/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:`start`" section for options on how to get a
+   Yocto Project*: See the ":doc:`/dev-manual/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:`multiconfig` section of the Yocto Project Development Tasks
+See the :doc:`/dev-manual/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 use the
+   :ref:`ref-classes-own-mirrors` class, and add the
    :term:`BB_NO_NETWORK` variable to your ``local.conf``::
 
       SOURCE_MIRROR_URL ?= "file:///home/your-download-dir/"

documentation/dev-manual/debugging.rst

@@ -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/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.sh`` for more details about this script.
+Run ``sstate-cache-management.py`` 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 the source tarballs. For images,
+locating and downloading all of the source code. 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
-all of the source tarballs. Maybe you have been working with another
+source code. 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,6 +22,7 @@ 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.
 
-On the contrary, BusyBox init is the simplest and the lightest solution and
+By contrast, 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 = "dunfell"
+      LAYERSERIES_COMPAT_yoctobsp = "walnascar"
 
    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 it to use the character ``%`` in the ``.bbappend`` filename. For
+Another method is 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,10 +504,9 @@ 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 = "${WORKDIR}"
+   S = "${UNPACKDIR}"
 
    PACKAGE_ARCH = "${MACHINE_ARCH}"
    INHIBIT_DEFAULT_DEPS = "1"
@@ -582,11 +581,10 @@ 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 = "${WORKDIR}"
+   S = "${UNPACKDIR}"
 
    CONFFILES:${PN} = "${sysconfdir}/X11/xorg.conf"
 
@@ -594,9 +592,9 @@ Directory`.  Here is the main ``xserver-xf86-config`` recipe, which is named
    ALLOW_EMPTY:${PN} = "1"
 
    do_install () {
-        if test -s ${WORKDIR}/xorg.conf; then
+        if test -s ${UNPACKDIR}/xorg.conf; then
                 install -d ${D}/${sysconfdir}/X11
-                install -m 0644 ${WORKDIR}/xorg.conf ${D}/${sysconfdir}/X11/
+                install -m 0644 ${UNPACKDIR}/xorg.conf ${D}/${sysconfdir}/X11/
         fi
    }
 
@@ -614,8 +612,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 ${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/
+           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/
        fi
    }
 

documentation/dev-manual/libraries.rst

@@ -37,40 +37,10 @@ library files.
    Some previously released versions of the Yocto Project defined the
    static library files through ``${PN}-dev``.
 
-Here is the part of the BitBake configuration file, where you can see
+Here is a small 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://${WORKDIR}/license.html;md5=5c94767cedb5d6987c902ac850ded2c6"
+   LIC_FILES_CHKSUM = "file://${UNPACKDIR}/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:`WORKDIR`.
+:term:`UNPACKDIR`.
 
 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

@@ -0,0 +1,138 @@
+.. 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

@@ -188,13 +188,14 @@ 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:
+   examples (which includes the use of the string "git" as a special case of a
+   version identifier):
 
    .. code-block:: none
 
-      cups_1.7.0.bb
-      gawk_4.0.2.bb
-      irssi_0.8.16-rc1.bb
+      cups_2.4.12.bb
+      gawk_5.3.2.bb
+      psplash_git.bb
 
 Running a Build on the Recipe
 =============================
@@ -276,11 +277,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
-``meta/recipes-devtools/strace/strace_5.5.bb`` recipe where the source
-comes from a single tarball. Notice the use of 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
 :term:`PV` variable::
 
-   SRC_URI = "https://strace.io/files/${PV}/strace-${PV}.tar.xz \
+   SRC_URI = "${GITHUB_BASE_URI}/download/v${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
@@ -292,7 +293,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:`meta/recipes-sato/l3afpad/l3afpad_git.bb </openembedded-core/tree/meta/recipes-sato/l3afpad/l3afpad_git.bb>`::
+:oe_git:`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"
 
@@ -347,8 +348,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
-``meta/recipes-sato/rxvt-unicode/rxvt-unicode_9.20.bb`` recipe. The
-example's :term:`SRC_URI` statement identifies multiple files as the source
+: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
 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 \
@@ -706,7 +707,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:`WORKDIR`\ ``}``
+``${``\ :term:`UNPACKDIR`\ ``}``
 directories to the ``${``\ :term:`D`\ ``}``
 directory to create the structure as it should appear on the target
 system.
@@ -1145,7 +1146,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:`WORKDIR` in this
+directory containing the source code, which is set to :term:`UNPACKDIR` in this
 case --- the directory BitBake uses for the build::
 
    SUMMARY = "Simple helloworld application"
@@ -1155,7 +1156,7 @@ case --- the directory BitBake uses for the build::
 
    SRC_URI = "file://helloworld.c"
 
-   S = "${WORKDIR}"
+   S = "${UNPACKDIR}"
 
    do_compile() {
        ${CC} ${LDFLAGS} helloworld.c -o helloworld
@@ -1211,8 +1212,6 @@ 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"
@@ -1271,8 +1270,6 @@ 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
@@ -1397,11 +1394,31 @@ 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.
@@ -1428,7 +1445,7 @@ chapter of the BitBake User Manual.
    The following example shows some of the ways you can use variables in
    recipes::
 
-      S = "${WORKDIR}/postfix-${PV}"
+      S = "${UNPACKDIR}/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 = "${WORKDIR}/npm"
+   S = "${UNPACKDIR}/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 = "${WORKDIR}"
+   S = "${UNPACKDIR}"
 
    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 ${WORKDIR}/libfoo.so ${D}${libdir}
+           install -m 0755 ${UNPACKDIR}/libfoo.so ${D}${libdir}
    }
 

documentation/dev-manual/sbom.rst

@@ -60,6 +60,9 @@ 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 using ``opkg`` to
+       updates through a package update mechanism 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 QuickEMUlator (QEMU).
+       the Quick EMUlator (QEMU).
 
     -  Supports incremental build testing and from-scratch builds.
 
@@ -228,13 +228,24 @@ 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
@@ -310,7 +321,7 @@ Project Build Host:
 
    -  GNU make &MIN_MAKE_VERSION; or greater
 
-   If your build host does not meet any of these listed version
+   If your build host does not satisfy all 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`"
@@ -568,7 +579,7 @@ extension accordingly.
 Locating Yocto Project Source Files
 ===================================
 
-This section shows you how to locate, fetch and configure the source
+This section shows you how to locate, fetch, unpack, patch and configure the source
 files you'll need to work with the Yocto Project.
 
 .. note::
@@ -720,11 +731,11 @@ Follow these steps to create a local version of the upstream
       $ git branch
       * master
 
-   Your local repository of poky is identical to the
-   upstream poky repository at the time from which it was cloned. As you
+   Your local repository of poky is initially identical to the
+   upstream poky repository from which it was cloned. As you
    work with the local branch, you can periodically use the
-   ``git pull --rebase`` command to be sure you are up-to-date
-   with the upstream branch.
+   ``git pull`` command to be sure you stay up-to-date
+   with the upstream poky branch.
 
 Checking Out by Branch in Poky
 ------------------------------

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

@@ -18,11 +18,10 @@ 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 = "${WORKDIR}/${BP}"
+   S = "${UNPACKDIR}/${BP}"
 
 You should be aware that many recipes override the
-:term:`S` variable. For example, recipes that fetch their source from Git
-usually set :term:`S` to ``${WORKDIR}/git``.
+:term:`S` variable when the default isn't accurate.
 
 .. note::
 
@@ -31,8 +30,16 @@ usually set :term:`S` to ``${WORKDIR}/git``.
 
            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 work directory for the recipe
+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
 (:term:`WORKDIR`) is defined as
 follows::
 

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/migration-guides/migration-5.1.rst

@@ -20,8 +20,7 @@ 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 = "${WORKDIR}/sources"
-    UNPACKDIR = "${S}"
+    S = "${UNPACKDIR}"
 
 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`,
@@ -62,8 +61,7 @@ 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 = "${WORKDIR}/sources"
-    UNPACKDIR = "${S}"
+    S = "${UNPACKDIR}"
 
 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.3.rst

@@ -14,6 +14,56 @@ 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
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -59,6 +109,48 @@ 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
 ~~~~~~~~~~~~~~~~
 

documentation/migration-guides/release-4.0.rst

@@ -34,3 +34,4 @@ Release 4.0 (kirkstone)
    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

@@ -16,3 +16,4 @@ Release 5.0 (scarthgap)
    release-notes-5.0.7
    release-notes-5.0.8
    release-notes-5.0.9
+   release-notes-5.0.10

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

@@ -0,0 +1,224 @@
+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.

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

@@ -0,0 +1,208 @@
+.. 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.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 :ref:`ref-classes-kernel-fitimage`, the existence of
+   -  In ``kernel-fitimage``, the existence of
       :term:`EXTERNAL_KERNEL_DEVICETREE` is checked more thoroughly to avoid
       false positives.
 

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

@@ -29,7 +29,7 @@ New Features / Enhancements in |yocto-ver|
       ``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 :ref:`ref-classes-kernel-fitimage` for more information.
+      fit image. See the ``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
@@ -684,7 +684,7 @@ New Features / Enhancements in |yocto-ver|
       command-line tool was added to the different Yocto Project and OpenEmbedded
       repositories.
 
-   -  :ref:`ref-classes-kernel-fitimage`: handle :doc:`multiconfig
+   -  ``kernel-fitimage``: handle :doc:`multiconfig
       </dev-manual/multiconfig>` dependency when
       :term:`INITRAMFS_MULTICONFIG` is set.
 

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`` or ``.deb`` files), this document avoids
+build system (i.e. ``.ipk``, ``.deb`` or ``.rpm`` 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,6 +277,9 @@ 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.
 
@@ -352,7 +355,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 `general workflow
+the "User Configuration" box in the :ref:`general workflow
 figure <overview-manual/concepts:openembedded build system concepts>`:
 
 -  *Metadata (.bb + Patches):* Software layers containing
@@ -420,14 +423,14 @@ build.
 Distro Layer
 ~~~~~~~~~~~~
 
-The distribution layer provides policy configurations for your
+A 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 the distribution layer:
+typically find in a distribution layer:
 
 -  *classes:* Class files (``.bbclass``) hold common functionality that
    can be shared among recipes in the distribution. When your recipes
@@ -454,7 +457,7 @@ typically find in the distribution layer:
 BSP Layer
 ~~~~~~~~~
 
-The BSP Layer provides machine configurations that target specific
+A 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
@@ -465,7 +468,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.
 
-The BSP Layer's configuration directory contains configuration files for
+A BSP layer's configuration directory contains configuration files for
 the machine (``conf/machine/machine.conf``) and, of course, the layer
 (``conf/layer.conf``).
 
@@ -477,18 +480,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
 ~~~~~~~~~~~~~~
 
-The software layer provides the Metadata for additional software
+A 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
@@ -560,9 +563,8 @@ 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 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.
+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.
 
 Source Control Managers (Optional)
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -705,7 +707,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-unpack`` name. The
+recipe's unpacked source code, and has the default ``sources`` name. The
 preceding figure and the following list describe the :term:`Build Directory`'s
 hierarchy:
 
@@ -2369,8 +2371,6 @@ 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,11 +2395,9 @@ The contents of ``sayhello_0.1.bb`` are::
    DEPENDS += "libhello"
    RDEPENDS:${PN} += "libhello"
 
-   S = "${WORKDIR}/git"
-
    do_install(){
-      install -d ${D}/usr/bin
-      install -m 0700 sayhello ${D}/usr/bin
+      install -d ${D}${bindir}
+      install -m 0700 sayhello ${D}${bindir}
    }
 
 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-unpack &lt;─────────────────────── UNPACKDIR</tspan><tspan
+         id="tspan15">          sources &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-unpack &lt;─────────────────────── UNPACKDIR</tspan><tspan
+         id="tspan32">          sources &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-unpack &lt;───────────────────── UNPACKDIR</tspan><tspan
+         id="tspan21">          sources &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-unpack &lt;───────────────────── UNPACKDIR</tspan><tspan
+         id="tspan35">          sources &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-unpack &lt;──────────────────── UNPACKDIR</tspan><tspan
+         id="tspan21">          sources &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-unpack &lt;──────────────────── UNPACKDIR</tspan><tspan
+         id="tspan35">          sources &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-unpack &lt;─────────────────────── UNPACKDIR</tspan><tspan
+         id="tspan22">          sources &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-unpack &lt;─────────────────────── UNPACKDIR</tspan><tspan
+         id="tspan36">          sources &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

@@ -51,7 +51,7 @@ Here are features and advantages of the Yocto Project:
    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
+   :doc:`/ref-manual/yocto-project-supported-features` for details on the level
    of support for some of these architectures.
 
    Aside from broad architecture support, the Yocto Project fully

documentation/poky.yaml.in

@@ -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 : "8"
+MIN_RAM : "32"

documentation/ref-manual/classes.rst

@@ -1591,6 +1591,10 @@ 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
@@ -1732,77 +1736,158 @@ 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-fitimage:
+.. _ref-classes-kernel-fit-image:
 
-``kernel-fitimage``
-===================
+``kernel-fit-image``
+====================
 
-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
+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
 limited usecases: just one kernel image, an optional U-boot script,
-an optional :term:`Initramfs` bundle, an optional RAM disk, and any number of
-device trees.
+an optional :term:`Initramfs`, and any number of device trees.
 
-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 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.
 
-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.
+The simplest example for building a FIT image is to add::
 
-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.
+   KERNEL_CLASSES += "kernel-fit-extra-artifacts"
 
-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.
+to the machine :term:`configuration file` and to execute::
 
-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.
+   bitbake linux-yocto-fitimage
 
-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`.
+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 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.
+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::
 
-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".
+   KERNEL_CLASSES += "kernel-fit-extra-artifacts"
+   PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-rt"
 
+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:
 
@@ -2050,7 +2135,8 @@ a couple different ways:
       Not using this naming convention can lead to subtle problems
       caused by existing code that depends on that naming convention.
 
--  Create or modify a target recipe that contains the following::
+-  Or, create a :ref:`ref-classes-native` variant of any target recipe (e.g.
+   ``myrecipe.bb``) by adding the following to the recipe::
 
       BBCLASSEXTEND = "native"
 
@@ -2081,7 +2167,18 @@ couple different ways:
    inherit statement in the recipe after all other inherit statements so
    that the :ref:`ref-classes-nativesdk` class is inherited last.
 
--  Create a :ref:`ref-classes-nativesdk` variant of any recipe by adding the following::
+   .. 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::
 
        BBCLASSEXTEND = "nativesdk"
 
@@ -2090,16 +2187,6 @@ 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
@@ -3436,7 +3523,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-fitimage` class, which this class
+See also the description of :ref:`ref-classes-kernel-fit-image` class, which this class
 imitates.
 
 .. _ref-classes-uki:

documentation/ref-manual/resources.rst

@@ -23,7 +23,7 @@ The Yocto Project gladly accepts contributions. You can submit changes
 to the project either by creating and sending pull requests, or by
 submitting patches through email. For information on how to do both as
 well as information on how to identify the maintainer for each area of
-code, see the :doc:`../contributor-guide/index`.
+code, see the :doc:`/contributor-guide/index`.
 
 .. _resources-bugtracker:
 
@@ -45,7 +45,7 @@ your expectations).
 For a general procedure and guidelines on how to use Bugzilla to submit a bug
 against the Yocto Project, see the following:
 
--  The ":doc:`../contributor-guide/report-defect`"
+-  The ":doc:`/contributor-guide/report-defect`"
    section in the Yocto Project and OpenEmbedded Contributor Guide.
 
 -  The Yocto Project :yocto_wiki:`Bugzilla wiki page </Bugzilla_Configuration_and_Bug_Tracking>`

documentation/ref-manual/structure.rst

@@ -246,7 +246,8 @@ section in the Yocto Project Development Tasks Manual.
 ----------------
 
 This directory contains several internal files used by the OpenEmbedded
-build system.
+build system. The path to this directory is defined by the
+:term:`PERSISTENT_DIR` variable.
 
 It also contains ``sanity_info``, a text file keeping track of important
 build information such as the values of :term:`TMPDIR`, :term:`SSTATE_DIR`,
@@ -611,7 +612,7 @@ example, consider ``linux-yocto-kernel-3.0`` on the machine ``qemux86``
 built within the Yocto Project. For this package, a work directory of
 ``tmp/work/qemux86-poky-linux/linux-yocto/3.0+git1+<.....>``, referred
 to as the :term:`WORKDIR`, is created. Within this directory, the source is
-unpacked to ``linux-qemux86-standard-build`` and then patched by Quilt.
+unpacked to ``sources/linux-qemux86-standard-build`` and then patched by Quilt.
 (See the ":ref:`dev-manual/quilt:using quilt in your workflow`" section in
 the Yocto Project Development Tasks Manual for more information.) Within
 the ``linux-qemux86-standard-build`` directory, standard Quilt

documentation/ref-manual/system-requirements.rst

@@ -145,7 +145,7 @@ tested on former revisions of "&DISTRO_NAME;", but no longer are:
       interested in hearing about your experience. For information on
       how to submit a bug, see the Yocto Project
       :yocto_wiki:`Bugzilla wiki page </Bugzilla_Configuration_and_Bug_Tracking>`
-      and the ":doc:`../contributor-guide/report-defect`"
+      and the ":doc:`/contributor-guide/report-defect`"
       section in the Yocto Project and OpenEmbedded Contributor Guide.
 
 Required Packages for the Build Host

documentation/ref-manual/tasks.rst

@@ -412,8 +412,7 @@ them. You can learn more by looking at the
 -------------
 
 Unpacks the source code into a working directory pointed to by
-``${``\ :term:`UNPACKDIR`\ ``}``. A legacy way to specify
-this directory is through the :term:`S` and :term:`WORKDIR` variables.
+``${``\ :term:`UNPACKDIR`\ ``}``.
 For more information on how source files are unpacked, see the
 ":ref:`overview-manual/concepts:source fetching`"
 section in the Yocto Project Overview and Concepts Manual.

documentation/ref-manual/variables.rst

@@ -265,7 +265,7 @@ system and gives an overview of their function and contents.
       build process. By default, this directory is the same as the
       :term:`S` directory, which is defined as::
 
-         S = "${WORKDIR}/${BP}"
+         S = "${UNPACKDIR}/${BP}"
 
       You can separate the (:term:`S`) directory and the directory pointed to
       by the :term:`B` variable. Most Autotools-based recipes support
@@ -560,6 +560,13 @@ system and gives an overview of their function and contents.
    :term:`BB_GENERATE_SHALLOW_TARBALLS`
       See :term:`bitbake:BB_GENERATE_SHALLOW_TARBALLS` in the BitBake manual.
 
+   :term:`BB_GIT_DEFAULT_DESTSUFFIX`
+      See :term:`bitbake:BB_GIT_DEFAULT_DESTSUFFIX` in the BitBake manual.
+
+      In :term:`OpenEmbedded-Core (OE-Core)`, this variable is set to
+      :term:`BP` by default in :oe_git:`bitbake.conf
+      </openembedded-core/tree/meta/conf/bitbake.conf>`.
+
    :term:`BB_GIT_SHALLOW`
       See :term:`bitbake:BB_GIT_SHALLOW` in the BitBake manual.
 
@@ -582,8 +589,12 @@ system and gives an overview of their function and contents.
       See :term:`bitbake:BB_INVALIDCONF` in the BitBake manual.
 
    :term:`BB_LOADFACTOR_MAX`
-      The system load threshold above which BitBake will stop runnig extra
-      tasks.
+      The system load threshold above which :term:`BitBake` will stop running
+      extra tasks.
+
+      For more information on how to limit the resources used during builds, see
+      the :doc:`/dev-manual/limiting-resources` section of the Yocto Project
+      Development Tasks Manual.
 
    :term:`BB_LOGCONFIG`
       See :term:`bitbake:BB_LOGCONFIG` in the BitBake manual.
@@ -642,11 +653,9 @@ system and gives an overview of their function and contents.
       An alternative to using :term:`BB_NUMBER_THREADS` to keep the usage
       of build system resources under control is to use the smarter
       :term:`BB_PRESSURE_MAX_CPU`, :term:`BB_PRESSURE_MAX_IO` or
-      :term:`BB_PRESSURE_MAX_MEMORY` controls. They will prevent BitBake
-      from starting new tasks as long as thresholds are exceeded. Anyway,
-      as with :term:`BB_NUMBER_THREADS`, such controls won't prevent the
-      tasks already being run from using all CPU threads on the system
-      if :term:`PARALLEL_MAKE` is not set to a low value.
+      :term:`BB_PRESSURE_MAX_MEMORY` controls. See the
+      :doc:`/dev-manual/limiting-resources` section of the Yocto Project
+      Development Tasks Manual.
 
    :term:`BB_ORIGENV`
       See :term:`bitbake:BB_ORIGENV` in the BitBake manual.
@@ -657,12 +666,24 @@ system and gives an overview of their function and contents.
    :term:`BB_PRESSURE_MAX_CPU`
       See :term:`bitbake:BB_PRESSURE_MAX_CPU` in the BitBake manual.
 
+      For more information on how to limit the resources used during builds, see
+      the :doc:`/dev-manual/limiting-resources` section of the Yocto Project
+      Development Tasks Manual.
+
    :term:`BB_PRESSURE_MAX_IO`
       See :term:`bitbake:BB_PRESSURE_MAX_IO` in the BitBake manual.
 
+      For more information on how to limit the resources used during builds, see
+      the :doc:`/dev-manual/limiting-resources` section of the Yocto Project
+      Development Tasks Manual.
+
    :term:`BB_PRESSURE_MAX_MEMORY`
       See :term:`bitbake:BB_PRESSURE_MAX_MEMORY` in the BitBake manual.
 
+      For more information on how to limit the resources used during builds, see
+      the :doc:`/dev-manual/limiting-resources` section of the Yocto Project
+      Development Tasks Manual.
+
    :term:`BB_RUNFMT`
       See :term:`bitbake:BB_RUNFMT` in the BitBake manual.
 
@@ -2576,7 +2597,7 @@ system and gives an overview of their function and contents.
       You can safely share this directory between multiple builds on the
       same development machine. For additional information on how the build
       process gets source files when working behind a firewall or proxy
-      server, see this specific question in the ":doc:`faq`"
+      server, see this specific question in the ":doc:`/ref-manual/faq`"
       chapter. You can also refer to the
       ":yocto_wiki:`Working Behind a Network Proxy </Working_Behind_a_Network_Proxy>`"
       Wiki page.
@@ -2790,7 +2811,7 @@ system and gives an overview of their function and contents.
       ``meta/classes-recipe`` to see how the variable is used.
 
    :term:`EXTERNAL_KERNEL_DEVICETREE`
-      When inheriting :ref:`ref-classes-kernel-fitimage` and a
+      When inheriting :ref:`ref-classes-kernel-fit-image` and a
       :term:`PREFERRED_PROVIDER` for ``virtual/dtb`` set to ``devicetree``, the
       variable :term:`EXTERNAL_KERNEL_DEVICETREE` can be used to specify a
       directory containing one or more compiled device tree or device tree
@@ -3318,7 +3339,7 @@ system and gives an overview of their function and contents.
       Specifies the value of the ``#address-cells`` value for the
       description of the FIT image.
 
-      The default value is set to "1" by the :ref:`ref-classes-kernel-fitimage`
+      The default value is set to "1" by the :ref:`ref-classes-kernel-fit-image`
       class, which corresponds to 32 bit addresses.
 
       For platforms that need to set 64 bit addresses, for example in
@@ -3337,11 +3358,11 @@ system and gives an overview of their function and contents.
       Specifies the default device tree binary (dtb) file for a FIT image
       when multiple ones are provided.
 
-      This variable is used in the :ref:`ref-classes-kernel-fitimage` class.
+      This variable is used in the :ref:`ref-classes-kernel-fit-image` class.
 
    :term:`FIT_DESC`
       Specifies the description string encoded into a FIT image. The
-      default value is set by the :ref:`ref-classes-kernel-fitimage` class as
+      default value is set by the :ref:`ref-classes-kernel-fit-image` class as
       follows::
 
          FIT_DESC ?= "U-Boot fitImage for ${DISTRO_NAME}/${PV}/${MACHINE}"
@@ -3350,12 +3371,12 @@ system and gives an overview of their function and contents.
       Decides whether to generate the keys for signing the FIT image if
       they don't already exist. The keys are created in
       :term:`UBOOT_SIGN_KEYDIR`. The default value is set to "0"
-      by the :ref:`ref-classes-kernel-fitimage` class.
+      by the :ref:`ref-classes-kernel-fit-image` class.
 
    :term:`FIT_HASH_ALG`
       Specifies the hash algorithm used in creating the FIT Image.
       This variable is set by default to "sha256" by the
-      :ref:`ref-classes-kernel-fitimage` class.
+      :ref:`ref-classes-kernel-fit-image` class.
 
    :term:`FIT_KERNEL_COMP_ALG`
       The compression algorithm to use for the kernel image inside the FIT Image.
@@ -3374,31 +3395,31 @@ system and gives an overview of their function and contents.
    :term:`FIT_KEY_GENRSA_ARGS`
       Arguments to ``openssl genrsa`` for generating a RSA private key for
       signing the FIT image. The default value is set to "-F4" by the
-      :ref:`ref-classes-kernel-fitimage` class.
+      :ref:`ref-classes-kernel-fit-image` class.
 
    :term:`FIT_KEY_REQ_ARGS`
       Arguments to ``openssl req`` for generating a certificate for signing
       the FIT image. The default value is "-batch -new" by the
-      :ref:`ref-classes-kernel-fitimage` class, "batch" for
+      :ref:`ref-classes-kernel-fit-image` class, "batch" for
       non interactive mode and "new" for generating new keys.
 
    :term:`FIT_KEY_SIGN_PKCS`
       Format for the public key certificate used for signing the FIT image.
       The default value is set to "x509" by the
-      :ref:`ref-classes-kernel-fitimage` class.
+      :ref:`ref-classes-kernel-fit-image` class.
 
    :term:`FIT_SIGN_ALG`
       Specifies the signature algorithm used in creating the FIT Image.
       This variable is set by default to "rsa2048" by the
-      :ref:`ref-classes-kernel-fitimage` class.
+      :ref:`ref-classes-kernel-fit-image` class.
 
    :term:`FIT_PAD_ALG`
       Specifies the padding algorithm used in creating the FIT Image.
       The default value is set to "pkcs-1.5" by the
-      :ref:`ref-classes-kernel-fitimage` class.
+      :ref:`ref-classes-kernel-fit-image` class.
 
    :term:`FIT_SIGN_INDIVIDUAL`
-      If set to "1", the :ref:`ref-classes-kernel-fitimage` class signs each
+      If set to "1", the :ref:`ref-classes-kernel-fit-image` class signs each
       image node individually, including the kernel, DTB, RAM disk, and any
       other image types present in the FIT image, in addition to signing the
       configuration nodes.
@@ -3431,13 +3452,13 @@ system and gives an overview of their function and contents.
    :term:`FIT_SIGN_NUMBITS`
       Size of the private key used in the FIT image, in number of bits.
       The default value for this variable is set to "2048"
-      by the :ref:`ref-classes-kernel-fitimage` class.
+      by the :ref:`ref-classes-kernel-fit-image` class.
 
    :term:`FIT_UBOOT_ENV`
       This variable allows to add a U-Boot script as a text file to the
       FIT image. Such a script can be sourced from the U-Boot shell.
 
-      When inheriting the :ref:`ref-classes-kernel-fitimage` class a
+      When inheriting the :ref:`ref-classes-kernel-fit-image` class a
       script file should be included in the :term:`SRC_URI` of the Linux
       kernel recipe.
 
@@ -5075,9 +5096,7 @@ system and gives an overview of their function and contents.
    :term:`KERNEL_CLASSES`
       A list of classes defining kernel image types that the
       :ref:`ref-classes-kernel` class should inherit. You typically
-      append this variable to enable extended image types. An example is
-      ":ref:`ref-classes-kernel-fitimage`", which enables
-      FIT image support and resides in ``meta/classes-recipe/kernel-fitimage.bbclass``.
+      append this variable to enable extended image types.
       You can register custom kernel image types with the
       :ref:`ref-classes-kernel` class using this variable.
 
@@ -5352,6 +5371,27 @@ system and gives an overview of their function and contents.
       the :term:`KERNEL_PATH` variable. Both variables are common variables
       used by external Makefiles to point to the kernel source directory.
 
+   :term:`KERNEL_SPLIT_MODULES`
+      When inheriting the :ref:`ref-classes-kernel-module-split` class, this
+      variable controls whether kernel modules are split into separate packages
+      or bundled into a single package.
+
+      For some use cases, a monolithic kernel module package
+      :term:`KERNEL_PACKAGE_NAME` that contains all modules built from the
+      kernel sources may be preferred to speed up the installation.
+
+      By default, this variable is set to ``1``, resulting in one package per
+      module. Setting it to any other value will generate a single monolithic
+      package containing all kernel modules.
+
+      .. note::
+
+         If :term:`KERNEL_SPLIT_MODULES` is set to 0, it is still possible to
+         install all kernel modules at once by adding ``kernel-modules`` (assuming
+         :term:`KERNEL_PACKAGE_NAME` is ``kernel-modules``) to :term:`IMAGE_INSTALL`.
+         The way it works is that a placeholder "kernel-modules" package will be
+         created and will depend on every other individual kernel module packages.
+
    :term:`KERNEL_SRC`
       The location of the kernel sources. This variable is set to the value
       of the :term:`STAGING_KERNEL_DIR` within the :ref:`ref-classes-module`
@@ -6980,6 +7020,10 @@ system and gives an overview of their function and contents.
       ":ref:`dev-manual/speeding-up-build:speeding up a build`"
       section in the Yocto Project Development Tasks Manual.
 
+      For more information on how to limit the resources used during builds, see
+      the :doc:`/dev-manual/limiting-resources` section of the Yocto Project
+      Development Tasks Manual.
+
    :term:`PARALLEL_MAKEINST`
       Extra options passed to the build tool install command
       (``make install``, ``ninja install`` or more specific ones)
@@ -8041,7 +8085,7 @@ system and gives an overview of their function and contents.
    :term:`S`
       The location in the :term:`Build Directory` where
       unpacked recipe source code resides. By default, this directory is
-      ``${``\ :term:`WORKDIR`\ ``}/${``\ :term:`BPN`\ ``}-${``\ :term:`PV`\ ``}``,
+      ``${``\ :term:`UNPACKDIR`\ ``}/${``\ :term:`BPN`\ ``}-${``\ :term:`PV`\ ``}``,
       where ``${BPN}`` is the base recipe name and ``${PV}`` is the recipe
       version. If the source tarball extracts the code to a directory named
       anything other than ``${BPN}-${PV}``, or if the source code is
@@ -8054,19 +8098,10 @@ system and gives an overview of their function and contents.
       ``poky/build``. In this case, the work directory the build system
       uses to keep the unpacked recipe for ``db`` is the following::
 
-         poky/build/tmp/work/qemux86-poky-linux/db/5.1.19-r3/db-5.1.19
+         poky/build/tmp/work/qemux86-poky-linux/db/5.1.19-r3/sources/db-5.1.19
 
       The unpacked source code resides in the ``db-5.1.19`` folder.
 
-      This next example assumes a Git repository. By default, Git
-      repositories are cloned to ``${WORKDIR}/git`` during
-      :ref:`ref-tasks-fetch`. Since this path is different
-      from the default value of :term:`S`, you must set it specifically so the
-      source can be located::
-
-         SRC_URI = "git://path/to/repo.git;branch=main"
-         S = "${WORKDIR}/git"
-
    :term:`SANITY_REQUIRED_UTILITIES`
       Specifies a list of command-line utilities that should be checked for
       during the initial sanity checking process when running BitBake. If
@@ -8441,7 +8476,6 @@ system and gives an overview of their function and contents.
       sources are fetched from a Git repository and ``setup.py`` is in a
       ``python/pythonmodule`` subdirectory, you would have this::
 
-         S = "${WORKDIR}/git"
          SETUPTOOLS_SETUP_PATH = "${S}/python/pythonmodule"
 
    :term:`SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS`
@@ -8764,6 +8798,28 @@ system and gives an overview of their function and contents.
       image), compared to just using the :ref:`ref-classes-create-spdx` class
       with no option.
 
+   :term:`SPDX_INCLUDE_COMPILED_SOURCES`
+      This option allows the same as :term:`SPDX_INCLUDE_SOURCES` but including
+      only the sources used to compile the host tools and the target packages.
+      While :term:`SPDX_INCLUDE_SOURCES` includes all files in the source
+      directory as source file descriptions, :term:`SPDX_INCLUDE_COMPILED_SOURCES`
+      includes only the sources that are used to produce the binaries delivered
+      as packages. The source files that are not used during compilation are not
+      included in the SBOM. It uses debugsource information generated during
+      ``do_package`` to filter out source files.
+
+      This enables an external tool to use the SPDX information to disregard
+      vulnerabilities that are not compiled in the packages.
+
+      Enable this option as follows::
+
+         SPDX_INCLUDE_COMPILED_SOURCES = "1"
+
+      According to our tests, building ``core-image-minimal`` for the
+      ``qemux86-64`` machine, enabling this option compared with the
+      :term:`SPDX_INCLUDE_SOURCES` reduces the size of the  ``tmp/deploy/spdx``
+      directory from 2GB to 1.6GB.
+
    :term:`SPDX_NAMESPACE_PREFIX`
       This option could be used in order to change the prefix of ``spdxDocument``
       and the prefix of ``documentNamespace``. It is set by default to
@@ -10321,13 +10377,13 @@ system and gives an overview of their function and contents.
    :term:`UBOOT_DTB_LOADADDRESS`
       Specifies the load address for the dtb image used by U-Boot. During FIT
       image creation, the :term:`UBOOT_DTB_LOADADDRESS` variable is used in
-      :ref:`ref-classes-kernel-fitimage` class to specify the load address to be
+      :ref:`ref-classes-kernel-fit-image` class to specify the load address to be
       used in creating the dtb sections of Image Tree Source for the FIT image.
 
    :term:`UBOOT_DTBO_LOADADDRESS`
       Specifies the load address for the dtbo image used by U-Boot.  During FIT
       image creation, the :term:`UBOOT_DTBO_LOADADDRESS` variable is used in
-      :ref:`ref-classes-kernel-fitimage` class to specify the load address to be
+      :ref:`ref-classes-kernel-fit-image` class to specify the load address to be
       used in creating the dtbo sections of Image Tree Source for the FIT image.
 
    :term:`UBOOT_ENTRYPOINT`
@@ -10339,7 +10395,7 @@ system and gives an overview of their function and contents.
       -  The :term:`FIT_ADDRESS_CELLS` variable for FIT image creation.
       -  The :term:`UBOOT_FIT_ADDRESS_CELLS` variable for U-Boot FIT image creation.
 
-      This variable is used by the :ref:`ref-classes-kernel-fitimage`,
+      This variable is used by the :ref:`ref-classes-kernel-fit-image`,
       :ref:`ref-classes-kernel-uimage`, :ref:`ref-classes-kernel`,
       :ref:`ref-classes-uboot-config` and :ref:`ref-classes-uboot-sign`
       classes.
@@ -10616,7 +10672,7 @@ system and gives an overview of their function and contents.
       -  The :term:`FIT_ADDRESS_CELLS` variable for FIT image creation.
       -  The :term:`UBOOT_FIT_ADDRESS_CELLS` variable for U-Boot FIT image creation.
 
-      This variable is used by the :ref:`ref-classes-kernel-fitimage`,
+      This variable is used by the :ref:`ref-classes-kernel-fit-image`,
       :ref:`ref-classes-kernel-uimage`, :ref:`ref-classes-kernel`,
       :ref:`ref-classes-uboot-config` and :ref:`ref-classes-uboot-sign`
       classes.
@@ -10644,15 +10700,15 @@ system and gives an overview of their function and contents.
 
    :term:`UBOOT_MKIMAGE`
       Specifies the name of the mkimage command as used by the
-      :ref:`ref-classes-kernel-fitimage` class to assemble
+      :ref:`ref-classes-kernel-fit-image` class to assemble
       the FIT image. This can be used to substitute an alternative command, wrapper
       script or function if desired. The default is "uboot-mkimage".
 
    :term:`UBOOT_MKIMAGE_DTCOPTS`
       Options for the device tree compiler passed to ``mkimage -D`` feature
-      while creating a FIT image with the :ref:`ref-classes-kernel-fitimage`
+      while creating a FIT image with the :ref:`ref-classes-kernel-fit-image`
       class. If :term:`UBOOT_MKIMAGE_DTCOPTS` is not set then the
-      :ref:`ref-classes-kernel-fitimage` class will not pass the ``-D`` option
+      :ref:`ref-classes-kernel-fit-image` class will not pass the ``-D`` option
       to ``mkimage``.
 
       This variable is also used by the :ref:`ref-classes-uboot-sign` class.
@@ -10663,42 +10719,42 @@ system and gives an overview of their function and contents.
 
    :term:`UBOOT_MKIMAGE_SIGN`
       Specifies the name of the mkimage command as used by the
-      :ref:`ref-classes-kernel-fitimage` class to sign
+      :ref:`ref-classes-kernel-fit-image` class to sign
       the FIT image after it has been assembled (if enabled). This can be used
       to substitute an alternative command, wrapper script or function if
       desired. The default is "${:term:`UBOOT_MKIMAGE`}".
 
    :term:`UBOOT_MKIMAGE_SIGN_ARGS`
       Optionally specifies additional arguments for the
-      :ref:`ref-classes-kernel-fitimage` class to pass to the
+      :ref:`ref-classes-kernel-fit-image` class to pass to the
       mkimage command when signing the FIT image.
 
    :term:`UBOOT_RD_ENTRYPOINT`
       Specifies the entrypoint for the RAM disk image. During FIT image
       creation, the :term:`UBOOT_RD_ENTRYPOINT` variable is used in
-      :ref:`ref-classes-kernel-fitimage` class to specify the entrypoint to be
+      :ref:`ref-classes-kernel-fit-image` class to specify the entrypoint to be
       used in creating the Image Tree Source for the FIT image.
 
    :term:`UBOOT_RD_LOADADDRESS`
       Specifies the load address for the RAM disk image. During FIT image
       creation, the :term:`UBOOT_RD_LOADADDRESS` variable is used in
-      :ref:`ref-classes-kernel-fitimage` class to specify the load address to
+      :ref:`ref-classes-kernel-fit-image` class to specify the load address to
       be used in creating the Image Tree Source for the FIT image.
 
    :term:`UBOOT_SIGN_ENABLE`
       Enable signing of FIT image. The default value is "0".
 
-      This variable is used by the :ref:`ref-classes-kernel-fitimage`,
+      This variable is used by the :ref:`ref-classes-kernel-fit-image`,
       :ref:`ref-classes-uboot-config` and :ref:`ref-classes-uboot-sign`
       classes.
 
    :term:`UBOOT_SIGN_KEYDIR`
       Location of the directory containing the RSA key and certificate used for
-      signing FIT image, used by the :ref:`ref-classes-kernel-fitimage` and
+      signing FIT image, used by the :ref:`ref-classes-kernel-fit-image` and
       :ref:`ref-classes-uboot-sign` classes.
 
    :term:`UBOOT_SIGN_KEYNAME`
-      The name of keys used by the :ref:`ref-classes-kernel-fitimage` class
+      The name of keys used by the :ref:`ref-classes-kernel-fit-image` class
       for signing U-Boot FIT image stored in the :term:`UBOOT_SIGN_KEYDIR`
       directory. If we have for example a ``dev.key`` key and a ``dev.crt``
       certificate stored in the :term:`UBOOT_SIGN_KEYDIR` directory, you will

documentation/ref-manual/yocto-project-supported-features.rst

@@ -86,16 +86,16 @@ Below is a list of primary tested features, their maintainer(s) and builder(s):
      - meta-aws
    * - `meta-intel <https://git.yoctoproject.org/meta-intel>`__
      - meta-intel layer testing
-     - TBD
+     - meta-intel mailing list <meta-intel@lists.yoctoproject.org>
      - meta-intel
    * - `meta-exein <https://github.com/exein-io/meta-exein>`__
      - meta-exein layer testing
      - TBD
      - meta-exein
-   * - `meta-virtualization <https://git.yoctoproject.org/meta-virtualization/>`__
-     - meta-virtualization layer testing
+   * - `meta-webosose <https://github.com/webosose/meta-webosose>`__
+     - meta-webosose layer testing
      - TBD
-     - meta-virt
+     - meta-webosose
    * - :ref:`Multilib <dev-manual/libraries:Combining Multiple Versions of Library Files into One Image>`
      - Multilib feature testing
      - Collective effort
@@ -114,7 +114,7 @@ Below is a list of primary tested features, their maintainer(s) and builder(s):
      - pkgman-non-rpm (other builders use RPM by default)
    * - :ref:`Patchtest <contributor-guide/submit-changes:Validating Patches with Patchtest>`
      - Patchtest tool selftests
-     - TBD
+     - Collective effort
      - patchtest-selftest
    * - :wikipedia:`RISC-V (64-bit) <RISC-V>`
      - RISC-V architecture testing (64-bit)
@@ -209,25 +209,25 @@ builder(s):
      - Builder(s)
    * - :wikipedia:`PowerPC (32-bit) <PowerPC>`
      - PowerPC architecture testing (32-bit)
-     - TBD
+     - Peter Marko,
+       Adrian Freihofer
      - qemuppc,
-       qemuppc-alt,
        qemuppc-tc
    * - :oe_git:`meta-openembedded </meta-openembedded>`
      - meta-openembedded layer testing
-     - TBD
+     - Collective effort / openembedded-devel mailing list <openebedded-devel@lists.openembedded.org>
      - meta-oe
    * - `meta-mingw <https://git.yoctoproject.org/meta-mingw>`__
      - mingw based SDKs testing
      - TBD
      - meta-mingw
-   * - `meta-webosose <https://github.com/webosose/meta-webosose>`__
-     - meta-webosose layer testing
-     - TBD
-     - meta-webosose
+   * - `meta-virtualization <https://git.yoctoproject.org/meta-virtualization/>`__
+     - meta-virtualization layer testing
+     - meta-virtualization mailing list <meta-virtualization@lists.yoctoproject.org>
+     - meta-virt
    * - :wikipedia:`RISC-V (32-bit) <RISC-V>`
      - RISC-V architecture testing (32-bit)
-     - Collective effort
+     - TBD
      - qemuriscv32,
        qemuriscv32,
        qemuriscv32-tc
@@ -256,6 +256,10 @@ it is on a best effort only basis.
        qemumips-alt,
        qemumips-tc,
        qemumips64-tc
+   * - :wikipedia:`PowerPC (32-bit) <PowerPC>` Systemd
+     - PowerPC architecture testing (32-bit) with systemd
+     - No maintainers
+     - qemuppc-alt
    * - :wikipedia:`PowerPC (64-bit) <PowerPC>`
      - PowerPC architecture testing (64-bit)
      - No maintainers

documentation/standards.md

@@ -126,7 +126,16 @@ that most themes only style these two admonitions.
 
 ## ReStructured Text Syntax standards
 
-This section has not been filled yet
+### doc directive
+
+The [doc directive](https://www.sphinx-doc.org/en/master/usage/referencing.html#role-doc)
+allows to refer to another document within yocto-docs, like:
+
+    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.
 
 ## Adding screenshots
 

documentation/test-manual/ptest.rst

@@ -46,13 +46,19 @@ Running ptest
 =============
 
 The ``ptest-runner`` package installs a shell script that loops through
-all installed ptest test suites and runs them in sequence. Consequently,
-you might want to add this package to your image.
+all installed ptest test suites and runs them in sequence.
+
+During the execution ``ptest-runner`` keeps count of total and failed
+``ptests``. At end the execution summary is written to the console.
+If any of the ``run-ptest`` fails, ``ptest-runner`` returns '1'.
+
+Consequently, you might want to add ``ptest-runner`` to your image.
+
 
 Getting Your Package Ready
 ==========================
 
-In order to enable a recipe to run installed ptests on target hardware,
+In order to enable a recipe to run installed ``ptests`` on target hardware,
 you need to prepare the recipes that build the packages you want to
 test. Here is what you have to do for each recipe:
 
@@ -77,8 +83,9 @@ test. Here is what you have to do for each recipe:
 
 -  *Create run-ptest:* This script starts your test. Locate the
    script where you will refer to it using
-   :term:`SRC_URI`. Here is an
-   example that starts a test for ``dbus``::
+   :term:`SRC_URI`. Be sure ``run-ptest`` exits with 0 to mark it
+   as successfully executed otherwise will be marked as fail.
+   Here is an example that starts a test for ``dbus``::
 
       #!/bin/sh
       cd test

documentation/test-manual/understand-autobuilder.rst

@@ -184,6 +184,12 @@ directory to be shared between them. This means once a Worker has built
 an artifact, all the others can benefit from it. The usage of the directory
 within the build system is designed for sharing over NFS.
 
+Shared Hash Equivalence Server
+------------------------------
+
+The Workers all use the same Hash Equivalence server, through a common
+definition for :term:`BB_HASHSERVE`.
+
 Resulttool
 ----------
 

documentation/transitioning-to-a-custom-environment.rst

@@ -8,8 +8,8 @@ Transitioning to a custom environment for systems development
 
 .. note::
 
-   So you've finished the :doc:`brief-yoctoprojectqs/index` and
-   glanced over the document :doc:`what-i-wish-id-known`, the latter contains
+   So you've finished the :doc:`/brief-yoctoprojectqs/index` and
+   glanced over the document :doc:`/what-i-wish-id-known`, the latter contains
    important information learned from other users. You're well prepared. But
    now, as you are starting your own project, it isn't exactly straightforward what
    to do. And, the documentation is daunting. We've put together a few hints to

documentation/what-i-wish-id-known.rst

@@ -49,7 +49,7 @@ contact us with other suggestions.
    their silicon. These layers have names such as "meta-intel" or "meta-ti". Try
    not to build layers from scratch. If you do have custom silicon, use one of
    these layers as a guide or template and familiarize yourself with the
-   :doc:`bsp-guide/index`.
+   :doc:`/bsp-guide/index`.
 
 #. **Do not put everything into one layer:**
    Use different layers to logically separate information in your build. As an
@@ -127,7 +127,7 @@ contact us with other suggestions.
    You can build and run a specific task for a specific package (including
    devshell) or even a single recipe. When developers first start using the
    Yocto Project, the instructions found in the
-   :doc:`brief-yoctoprojectqs/index` show how to create an image
+   :doc:`/brief-yoctoprojectqs/index` show how to create an image
    and then run or flash that image.  However, you can actually build just a
    single recipe. Thus, if some dependency or recipe isn't working, you can just
    say "bitbake foo" where "foo" is the name for a specific recipe.  As you

meta-poky/conf/distro/poky.conf

@@ -1,7 +1,7 @@
 DISTRO = "poky"
 DISTRO_NAME = "Poky (Yocto Project Reference Distro)"
-DISTRO_VERSION = "5.2"
-DISTRO_CODENAME = "walnascar"
+DISTRO_VERSION = "5.2.99+snapshot-${METADATA_REVISION}"
+DISTRO_CODENAME = "whinlatter"
 SDK_VENDOR = "-pokysdk"
 SDK_VERSION = "${@d.getVar('DISTRO_VERSION').replace('snapshot-${METADATA_REVISION}', 'snapshot')}"
 SDK_VERSION[vardepvalue] = "${SDK_VERSION}"

meta-poky/conf/layer.conf

@@ -9,7 +9,7 @@ BBFILE_COLLECTIONS += "yocto"
 BBFILE_PATTERN_yocto = "^${LAYERDIR}/"
 BBFILE_PRIORITY_yocto = "5"
 
-LAYERSERIES_COMPAT_yocto = "walnascar"
+LAYERSERIES_COMPAT_yocto = "whinlatter"
 
 # This should only be incremented on significant changes that will
 # cause compatibility issues with other layers

meta-poky/conf/templates/default/local.conf.sample

@@ -21,9 +21,7 @@
 #
 #MACHINE ?= "qemuarm"
 #MACHINE ?= "qemuarm64"
-#MACHINE ?= "qemumips"
-#MACHINE ?= "qemumips64"
-#MACHINE ?= "qemuppc"
+#MACHINE ?= "qemuriscv64"
 #MACHINE ?= "qemux86"
 #MACHINE ?= "qemux86-64"
 #

meta-poky/recipes-core/tiny-init/tiny-init.bb

@@ -11,8 +11,7 @@ SRC_URI = "file://init \
 	   file://rc.local.sample \
 	  "
 
-S = "${WORKDIR}/sources"
-UNPACKDIR = "${S}"
+S = "${UNPACKDIR}"
 
 do_configure() {
 	:

meta-selftest/conf/layer.conf

@@ -11,4 +11,4 @@ BBFILE_PRIORITY_selftest = "5"
 
 addpylib ${LAYERDIR}/lib oeqa
 
-LAYERSERIES_COMPAT_selftest = "walnascar"
+LAYERSERIES_COMPAT_selftest = "whinlatter"

meta-selftest/recipes-devtools/mtd/mtd-utils-selftest_git.bb

@@ -18,8 +18,6 @@ SRC_URI = "git://git.infradead.org/mtd-utils.git;branch=master \
            file://0001-tests-Remove-unused-linux-fs.h-header-from-includes.patch \
            "
 
-S = "${WORKDIR}/git"
-
 # xattr support creates an additional compile-time dependency on acl because
 # the sys/acl.h header is needed. libacl is not needed and thus enabling xattr
 # regardless whether acl is enabled or disabled in the distro should be okay.

meta-selftest/recipes-devtools/python/python3-guessing-game_git.bb

@@ -12,8 +12,6 @@ SRC_URI = "git://git.yoctoproject.org/guessing-game.git;protocol=https;branch=ma
 PV = "0.1.0"
 SRCREV = "469c9e2230ca4fa9e391c94be6e697733e769500"
 
-S = "${WORKDIR}/git"
-
 inherit python_maturin cargo-update-recipe-crates
 
 require ${BPN}-crates.inc

meta-selftest/recipes-devtools/python/python3-guessing-game_git.bb.upgraded

@@ -12,8 +12,6 @@ SRC_URI = "git://git.yoctoproject.org/guessing-game.git;protocol=https;branch=ma
 PV = "0.2.0"
 SRCREV = "40cf004c2772ffa20ea803fa3be1528a75be3e98"
 
-S = "${WORKDIR}/git"
-
 inherit python_maturin cargo-update-recipe-crates
 
 require ${BPN}-crates.inc

meta-selftest/recipes-devtools/rust/rust-c-lib-example-bin_git.bb

@@ -8,7 +8,6 @@ SRC_URI = " \
 "
 
 SRCREV = "fc53c457f69aa5221ec1f8619a007e8150db5e60"
-S = "${WORKDIR}/git"
 
 DEPENDS = "rust-c-lib-example"
 

meta-selftest/recipes-devtools/rust/rust-c-lib-example_git.bb

@@ -8,7 +8,6 @@ SRC_URI = " \
 "
 
 SRCREV = "fc53c457f69aa5221ec1f8619a007e8150db5e60"
-S = "${WORKDIR}/git"
 
 inherit cargo_c
 

meta-selftest/recipes-extended/hello-rs/hello-rs_0.1.0.bb

@@ -12,7 +12,7 @@ SRCREV = "d3d096eda182644868f8e7458dcfa538ff637db3"
 SRCREV_FORMAT .= "_hello-lib"
 SRCREV_hello-lib = "59c84574e844617043cf337bc8fa537cf87ad8ae"
 
-S = "${WORKDIR}/rust"
+S = "${UNPACKDIR}/rust"
 
 inherit cargo cargo-update-recipe-crates ptest-cargo
 

meta-selftest/recipes-extended/sysdig/sysdig-selftest_0.28.0.bb

@@ -23,7 +23,7 @@ JIT:powerpc64 = ""
 RDEPENDS:${PN} = "bash"
 
 SRC_URI = "git://github.com/draios/sysdig.git;branch=dev;protocol=https;name=sysdig \
-           git://github.com/falcosecurity/libs;protocol=https;branch=master;name=falco;subdir=git/falcosecurity-libs \
+           git://github.com/falcosecurity/libs;protocol=https;branch=master;name=falco;subdir=${BB_GIT_DEFAULT_DESTSUFFIX}/falcosecurity-libs \
            file://0055-Add-cstdint-for-uintXX_t-types.patch;patchdir=./falcosecurity-libs \
            file://0099-cmake-Pass-PROBE_NAME-via-CFLAGS.patch \
            "
@@ -32,8 +32,6 @@ SRCREV_falco = "caa0e4d0044fdaaebab086592a97f0c7f32aeaa9"
 
 SRCREV_FORMAT = "sysdig_falco"
 
-S = "${WORKDIR}/git"
-
 EXTRA_OECMAKE = "\
                 -DBUILD_DRIVER=OFF \
                 -DMINIMAL_BUILD=ON \

meta-selftest/recipes-test/cpp/cpp-example.inc

@@ -19,7 +19,6 @@ SRC_URI = "\
     file://run-ptest \
 "
 
-S = "${WORKDIR}/sources"
-UNPACKDIR = "${S}"
+S = "${UNPACKDIR}"
 
 inherit ptest

meta-selftest/recipes-test/devtool/devtool-test-ignored.bb

@@ -4,6 +4,6 @@ INHIBIT_DEFAULT_DEPS = "1"
 SRC_URI = "file://${BPN}.tar.gz \
            file://${BPN}.patch"
 
-S = "${WORKDIR}/${BPN}"
+S = "${UNPACKDIR}/${BPN}"
 
 EXCLUDE_FROM_WORLD = "1"

meta-selftest/recipes-test/devtool/devtool-test-local_6.03.bb

@@ -12,7 +12,7 @@ SRC_URI:append:class-native = " file://file3"
 SRC_URI[md5sum] = "92a253df9211e9c20172796ecf388f13"
 SRC_URI[sha256sum] = "26d3986d2bea109d5dc0e4f8c4822a459276cf021125e8c9f23c3cca5d8c850e"
 
-S = "${WORKDIR}/syslinux-${PV}"
+S = "${UNPACKDIR}/syslinux-${PV}"
 
 EXCLUDE_FROM_WORLD = "1"
 BBCLASSEXTEND = "native"

meta-selftest/recipes-test/devtool/devtool-test-localonly.bb

@@ -6,8 +6,7 @@ SRC_URI = "file://file1 \
 
 SRC_URI:append:class-native = " file://file3"
 
-S = "${WORKDIR}/sources"
-UNPACKDIR = "${S}"
+S = "${UNPACKDIR}"
 
 EXCLUDE_FROM_WORLD = "1"
 BBCLASSEXTEND = "native"

meta-selftest/recipes-test/devtool/devtool-test-long-filename.bb

@@ -4,6 +4,6 @@ INHIBIT_DEFAULT_DEPS = "1"
 SRC_URI = "file://${BPN}.tar.gz \
            file://0001-I-ll-patch-you-only-if-devtool-lets-me-to-do-it-corr.patch"
 
-S = "${WORKDIR}/${BPN}"
+S = "${UNPACKDIR}/${BPN}"
 
 EXCLUDE_FROM_WORLD = "1"

meta-selftest/recipes-test/devtool/devtool-test-patch-gz.bb

@@ -8,7 +8,7 @@ SRC_URI = "http://downloads.yoctoproject.org/releases/xrestop/xrestop-0.4.tar.gz
            "
 UPSTREAM_VERSION_UNKNOWN = "1"
 
-S = "${WORKDIR}/xrestop-0.4"
+S = "${UNPACKDIR}/xrestop-0.4"
 
 SRC_URI[md5sum] = "d8a54596cbaf037e62b80c4585a3ca9b"
 SRC_URI[sha256sum] = "67c2fc94a7ecedbaae0d1837e82e93d1d98f4a6d759828860e552119af3ce257"

meta-selftest/recipes-test/devtool/devtool-test-reset-re++.bb

@@ -3,7 +3,6 @@ INHIBIT_DEFAULT_DEPS = "1"
 
 SRC_URI = "file://file1"
 
-S = "${WORKDIR}/sources"
-UNPACKDIR = "${S}"
+S = "${UNPACKDIR}"
 
 EXCLUDE_FROM_WORLD = "1"

meta-selftest/recipes-test/devtool/devtool-test-subdir.bb

@@ -4,6 +4,6 @@ INHIBIT_DEFAULT_DEPS = "1"
 SRC_URI = "file://devtool-test-subdir.tar.gz \
            file://testfile;subdir=${BPN}"
 
-S = "${WORKDIR}/${BPN}"
+S = "${UNPACKDIR}/${BPN}"
 
 EXCLUDE_FROM_WORLD = "1"

meta-selftest/recipes-test/devtool/devtool-upgrade-test1_1.5.3.bb

@@ -14,7 +14,7 @@ SRC_URI[sha256sum] = "681bcca9784bf3cb2207e68236d1f68e2aa7b80f999b5750dc77dcd756
 
 PR = "r5"
 
-S = "${WORKDIR}/pv-${PV}"
+S = "${UNPACKDIR}/pv-${PV}"
 
 EXCLUDE_FROM_WORLD = "1"
 

meta-selftest/recipes-test/devtool/devtool-upgrade-test1_1.5.3.bb.upgraded

@@ -11,7 +11,7 @@ RECIPE_NO_UPDATE_REASON = "This recipe is used to test devtool upgrade feature"
 
 SRC_URI[sha256sum] = "9dd45391806b0ed215abee4c5ac1597d018c386fe9c1f5afd2f6bc3b07fd82c3"
 
-S = "${WORKDIR}/pv-${PV}"
+S = "${UNPACKDIR}/pv-${PV}"
 
 EXCLUDE_FROM_WORLD = "1"
 

meta-selftest/recipes-test/devtool/devtool-upgrade-test2_git.bb

@@ -15,8 +15,6 @@ SRC_URI = "git://git.yoctoproject.org/dbus-wait;branch=master"
 UPSTREAM_CHECK_COMMITS = "1"
 RECIPE_NO_UPDATE_REASON = "This recipe is used to test devtool upgrade feature"
 
-S = "${WORKDIR}/git"
-
 EXCLUDE_FROM_WORLD = "1"
 
 inherit autotools pkgconfig