migration-guides: add release notes for 4.0.32

(From yocto-docs rev: 398a2a080361eb22b9c447dbde31fca58bf4e0bb)

Signed-off-by: Lee Chee Yang <chee.yang.lee@intel.com>
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
(cherry picked from commit 095981c08b9d63905472df5d1d60c07af96f0250)
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

bitbake/bin/bitbake-getvar

@@ -36,9 +36,10 @@ if __name__ == "__main__":
         print("--flag only makes sense with --value")
         sys.exit(1)
 
-    with bb.tinfoil.Tinfoil(tracking=True, setup_logging=not args.quiet) as tinfoil:
+    quiet = args.quiet
+    with bb.tinfoil.Tinfoil(tracking=True, setup_logging=not quiet) as tinfoil:
         if args.recipe:
-            tinfoil.prepare(quiet=2)
+            tinfoil.prepare(quiet=3 if quiet else 2)
             d = tinfoil.parse_recipe(args.recipe)
         else:
             tinfoil.prepare(quiet=2, config_only=True)

bitbake/bin/bitbake-hashclient

@@ -56,25 +56,24 @@ def main():
             nonlocal missed_hashes
             nonlocal max_time
 
-            client = hashserv.create_client(args.address)
+            with hashserv.create_client(args.address) as client:
+                for i in range(args.requests):
+                    taskhash = hashlib.sha256()
+                    taskhash.update(args.taskhash_seed.encode('utf-8'))
+                    taskhash.update(str(i).encode('utf-8'))
 
-            for i in range(args.requests):
-                taskhash = hashlib.sha256()
-                taskhash.update(args.taskhash_seed.encode('utf-8'))
-                taskhash.update(str(i).encode('utf-8'))
+                    start_time = time.perf_counter()
+                    l = client.get_unihash(METHOD, taskhash.hexdigest())
+                    elapsed = time.perf_counter() - start_time
 
-                start_time = time.perf_counter()
-                l = client.get_unihash(METHOD, taskhash.hexdigest())
-                elapsed = time.perf_counter() - start_time
+                    with lock:
+                        if l:
+                            found_hashes += 1
+                        else:
+                            missed_hashes += 1
 
-                with lock:
-                    if l:
-                        found_hashes += 1
-                    else:
-                        missed_hashes += 1
-
-                    max_time = max(elapsed, max_time)
-                    pbar.update()
+                        max_time = max(elapsed, max_time)
+                        pbar.update()
 
         max_time = 0
         found_hashes = 0
@@ -152,9 +151,8 @@ def main():
 
     func = getattr(args, 'func', None)
     if func:
-        client = hashserv.create_client(args.address)
-
-        return func(args, client)
+        with hashserv.create_client(args.address) as client:
+            return func(args, client)
 
     return 0
 

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

@@ -401,7 +401,7 @@ overview of their function and contents.
 
       Example usage::
 
-         BB_HASHSERVE_UPSTREAM = "hashserv.yocto.io:8687"
+         BB_HASHSERVE_UPSTREAM = "hashserv.yoctoproject.org:8686"
 
    :term:`BB_INVALIDCONF`
       Used in combination with the ``ConfigParsed`` event to trigger

bitbake/lib/bb/__init__.py

@@ -15,6 +15,13 @@ import sys
 if sys.version_info < (3, 6, 0):
     raise RuntimeError("Sorry, python 3.6.0 or later is required for this version of bitbake")
 
+if sys.version_info < (3, 10, 0):
+    # With python 3.8 and 3.9, we see errors of "libgcc_s.so.1 must be installed for pthread_cancel to work"
+    # https://stackoverflow.com/questions/64797838/libgcc-s-so-1-must-be-installed-for-pthread-cancel-to-work
+    # https://bugs.ams1.psf.io/issue42888
+    # so ensure libgcc_s is loaded early on
+    import ctypes
+    libgcc_s = ctypes.CDLL('libgcc_s.so.1')
 
 class BBHandledException(Exception):
     """

bitbake/lib/bb/asyncrpc/client.py

@@ -126,6 +126,12 @@ class AsyncClient(object):
             {'ping': {}}
         )
 
+    async def __aenter__(self):
+        return self
+
+    async def __aexit__(self, exc_type, exc_value, traceback):
+        await self.close()
+
 
 class Client(object):
     def __init__(self):
@@ -176,3 +182,10 @@ class Client(object):
         if sys.version_info >= (3, 6):
             self.loop.run_until_complete(self.loop.shutdown_asyncgens())
         self.loop.close()
+
+    def __enter__(self):
+        return self
+
+    def __exit__(self, exc_type, exc_value, traceback):
+        self.close()
+        return False

bitbake/lib/bb/cache.py

@@ -27,7 +27,7 @@ import re
 
 logger = logging.getLogger("BitBake.Cache")
 
-__cache_version__ = "154"
+__cache_version__ = "155"
 
 def getCacheFile(path, filename, mc, data_hash):
     mcspec = ''

bitbake/lib/bb/codeparser.py

@@ -201,6 +201,22 @@ class DummyLogger():
     def flush(self):
         return
 
+
+# Starting with Python 3.8, the ast module exposes all string nodes as a
+# Constant. While earlier versions of the module also have the Constant type
+# those use the Str type to encapsulate strings.
+if sys.version_info < (3, 8):
+    def node_str_value(node):
+        if isinstance(node, ast.Str):
+            return node.s
+        return None
+else:
+    def node_str_value(node):
+        if isinstance(node, ast.Constant) and isinstance(node.value, str):
+            return node.value
+        return None
+
+
 class PythonParser():
     getvars = (".getVar", ".appendVar", ".prependVar", "oe.utils.conditional")
     getvarflags = (".getVarFlag", ".appendVarFlag", ".prependVarFlag")
@@ -225,19 +241,22 @@ class PythonParser():
     def visit_Call(self, node):
         name = self.called_node_name(node.func)
         if name and (name.endswith(self.getvars) or name.endswith(self.getvarflags) or name in self.containsfuncs or name in self.containsanyfuncs):
-            if isinstance(node.args[0], ast.Str):
-                varname = node.args[0].s
-                if name in self.containsfuncs and isinstance(node.args[1], ast.Str):
+            varname = node_str_value(node.args[0])
+            if varname is not None:
+                arg_str_value = None
+                if len(node.args) >= 2:
+                    arg_str_value = node_str_value(node.args[1])
+                if name in self.containsfuncs and arg_str_value is not None:
                     if varname not in self.contains:
                         self.contains[varname] = set()
-                    self.contains[varname].add(node.args[1].s)
-                elif name in self.containsanyfuncs and isinstance(node.args[1], ast.Str):
+                    self.contains[varname].add(arg_str_value)
+                elif name in self.containsanyfuncs and arg_str_value is not None:
                     if varname not in self.contains:
                         self.contains[varname] = set()
-                    self.contains[varname].update(node.args[1].s.split())
+                    self.contains[varname].update(arg_str_value.split())
                 elif name.endswith(self.getvarflags):
-                    if isinstance(node.args[1], ast.Str):
-                        self.references.add('%s[%s]' % (varname, node.args[1].s))
+                    if arg_str_value is not None:
+                        self.references.add('%s[%s]' % (varname, arg_str_value))
                     else:
                         self.warn(node.func, node.args[1])
                 else:
@@ -245,10 +264,10 @@ class PythonParser():
             else:
                 self.warn(node.func, node.args[0])
         elif name and name.endswith(".expand"):
-            if isinstance(node.args[0], ast.Str):
-                value = node.args[0].s
+            arg_str_value = node_str_value(node.args[0])
+            if arg_str_value is not None:
                 d = bb.data.init()
-                parser = d.expandWithRefs(value, self.name)
+                parser = d.expandWithRefs(arg_str_value, self.name)
                 self.references |= parser.references
                 self.execs |= parser.execs
                 for varname in parser.contains:
@@ -256,8 +275,9 @@ class PythonParser():
                         self.contains[varname] = set()
                     self.contains[varname] |= parser.contains[varname]
         elif name in self.execfuncs:
-            if isinstance(node.args[0], ast.Str):
-                self.var_execs.add(node.args[0].s)
+            arg_str_value = node_str_value(node.args[0])
+            if arg_str_value is not None:
+                self.var_execs.add(arg_str_value)
             else:
                 self.warn(node.func, node.args[0])
         elif name and isinstance(node.func, (ast.Name, ast.Attribute)):

bitbake/lib/bb/data.py

@@ -310,6 +310,7 @@ def build_dependencies(key, keys, shelldeps, varflagsexcl, ignored_vars, d):
                 value += "\n_remove of %s" % r
                 deps |= r2.references
                 deps = deps | (keys & r2.execs)
+                value = handle_contains(value, r2.contains, exclusions, d)
             return value
 
         if "vardepvalue" in varflags:

bitbake/lib/bb/data_smart.py

@@ -261,12 +261,9 @@ class VariableHistory(object):
             return
         if 'op' not in loginfo or not loginfo['op']:
             loginfo['op'] = 'set'
-        if 'detail' in loginfo:
-            loginfo['detail'] = str(loginfo['detail'])
         if 'variable' not in loginfo or 'file' not in loginfo:
             raise ValueError("record() missing variable or file.")
         var = loginfo['variable']
-
         if var not in self.variables:
             self.variables[var] = []
         if not isinstance(self.variables[var], list):
@@ -325,7 +322,8 @@ class VariableHistory(object):
                     flag = '[%s] ' % (event['flag'])
                 else:
                     flag = ''
-                o.write("#   %s %s:%s%s\n#     %s\"%s\"\n" % (event['op'], event['file'], event['line'], display_func, flag, re.sub('\n', '\n#     ', event['detail'])))
+                o.write("#   %s %s:%s%s\n#     %s\"%s\"\n" % \
+                    (event['op'], event['file'], event['line'], display_func, flag, re.sub('\n', '\n#     ', str(event['detail']))))
             if len(history) > 1:
                 o.write("# pre-expansion value:\n")
                 o.write('#   "%s"\n' % (commentVal))
@@ -379,7 +377,7 @@ class VariableHistory(object):
             if isset and event['op'] == 'set?':
                 continue
             isset = True
-            items = d.expand(event['detail']).split()
+            items = d.expand(str(event['detail'])).split()
             for item in items:
                 # This is a little crude but is belt-and-braces to avoid us
                 # having to handle every possible operation type specifically

bitbake/lib/bb/fetch2/__init__.py

@@ -498,30 +498,30 @@ def fetcher_init(d):
     Calls before this must not hit the cache.
     """
 
-    revs = bb.persist_data.persist('BB_URI_HEADREVS', d)
-    try:
-        # fetcher_init is called multiple times, so make sure we only save the
-        # revs the first time it is called.
-        if not bb.fetch2.saved_headrevs:
-            bb.fetch2.saved_headrevs = dict(revs)
-    except:
-        pass
+    with bb.persist_data.persist('BB_URI_HEADREVS', d) as revs:
+        try:
+            # fetcher_init is called multiple times, so make sure we only save the
+            # revs the first time it is called.
+            if not bb.fetch2.saved_headrevs:
+                bb.fetch2.saved_headrevs = dict(revs)
+        except:
+            pass
 
-    # When to drop SCM head revisions controlled by user policy
-    srcrev_policy = d.getVar('BB_SRCREV_POLICY') or "clear"
-    if srcrev_policy == "cache":
-        logger.debug("Keeping SRCREV cache due to cache policy of: %s", srcrev_policy)
-    elif srcrev_policy == "clear":
-        logger.debug("Clearing SRCREV cache due to cache policy of: %s", srcrev_policy)
-        revs.clear()
-    else:
-        raise FetchError("Invalid SRCREV cache policy of: %s" % srcrev_policy)
+        # When to drop SCM head revisions controlled by user policy
+        srcrev_policy = d.getVar('BB_SRCREV_POLICY') or "clear"
+        if srcrev_policy == "cache":
+            logger.debug("Keeping SRCREV cache due to cache policy of: %s", srcrev_policy)
+        elif srcrev_policy == "clear":
+            logger.debug("Clearing SRCREV cache due to cache policy of: %s", srcrev_policy)
+            revs.clear()
+        else:
+            raise FetchError("Invalid SRCREV cache policy of: %s" % srcrev_policy)
 
-    _checksum_cache.init_cache(d)
+        _checksum_cache.init_cache(d)
 
-    for m in methods:
-        if hasattr(m, "init"):
-            m.init(d)
+        for m in methods:
+            if hasattr(m, "init"):
+                m.init(d)
 
 def fetcher_parse_save():
     _checksum_cache.save_extras()
@@ -535,8 +535,8 @@ def fetcher_compare_revisions(d):
     when bitbake was started and return true if they have changed.
     """
 
-    headrevs = dict(bb.persist_data.persist('BB_URI_HEADREVS', d))
-    return headrevs != bb.fetch2.saved_headrevs
+    with dict(bb.persist_data.persist('BB_URI_HEADREVS', d)) as headrevs:
+        return headrevs != bb.fetch2.saved_headrevs
 
 def mirror_from_string(data):
     mirrors = (data or "").replace('\\n',' ').split()
@@ -1618,13 +1618,13 @@ class FetchMethod(object):
         if not hasattr(self, "_latest_revision"):
             raise ParameterError("The fetcher for this URL does not support _latest_revision", ud.url)
 
-        revs = bb.persist_data.persist('BB_URI_HEADREVS', d)
-        key = self.generate_revision_key(ud, d, name)
-        try:
-            return revs[key]
-        except KeyError:
-            revs[key] = rev = self._latest_revision(ud, d, name)
-            return rev
+        with bb.persist_data.persist('BB_URI_HEADREVS', d) as revs:
+            key = self.generate_revision_key(ud, d, name)
+            try:
+                return revs[key]
+            except KeyError:
+                revs[key] = rev = self._latest_revision(ud, d, name)
+                return rev
 
     def sortable_revision(self, ud, d, name):
         latest_rev = self._build_revision(ud, d, name)

bitbake/lib/bb/fetch2/git.py

@@ -307,7 +307,10 @@ class Git(FetchMethod):
         return ud.clonedir
 
     def need_update(self, ud, d):
-        return self.clonedir_need_update(ud, d) or self.shallow_tarball_need_update(ud) or self.tarball_need_update(ud)
+        return self.clonedir_need_update(ud, d) \
+                or self.shallow_tarball_need_update(ud) \
+                or self.tarball_need_update(ud) \
+                or self.lfs_need_update(ud, d)
 
     def clonedir_need_update(self, ud, d):
         if not os.path.exists(ud.clonedir):
@@ -319,6 +322,15 @@ class Git(FetchMethod):
                 return True
         return False
 
+    def lfs_need_update(self, ud, d):
+        if self.clonedir_need_update(ud, d):
+            return True
+
+        for name in ud.names:
+            if not self._lfs_objects_downloaded(ud, d, name, ud.clonedir):
+                return True
+        return False
+
     def clonedir_need_shallow_revs(self, ud, d):
         for rev in ud.shallow_revs:
             try:
@@ -406,7 +418,7 @@ class Git(FetchMethod):
             if missing_rev:
                 raise bb.fetch2.FetchError("Unable to find revision %s even from upstream" % missing_rev)
 
-        if self._contains_lfs(ud, d, ud.clonedir) and self._need_lfs(ud):
+        if self.lfs_need_update(ud, d):
             # Unpack temporary working copy, use it to run 'git checkout' to force pre-fetching
             # of all LFS blobs needed at the srcrev.
             #
@@ -649,6 +661,35 @@ class Git(FetchMethod):
             raise bb.fetch2.FetchError("The command '%s' gave output with more then 1 line unexpectedly, output: '%s'" % (cmd, output))
         return output.split()[0] != "0"
 
+    def _lfs_objects_downloaded(self, ud, d, name, wd):
+        """
+        Verifies whether the LFS objects for requested revisions have already been downloaded
+        """
+        # Bail out early if this repository doesn't use LFS
+        if not self._need_lfs(ud) or not self._contains_lfs(ud, d, wd):
+            return True
+
+        # The Git LFS specification specifies ([1]) the LFS folder layout so it should be safe to check for file
+        # existence.
+        # [1] https://github.com/git-lfs/git-lfs/blob/main/docs/spec.md#intercepting-git
+        cmd = "%s lfs ls-files -l %s" \
+                % (ud.basecmd, ud.revisions[name])
+        output = runfetchcmd(cmd, d, quiet=True, workdir=wd).rstrip()
+        # Do not do any further matching if no objects are managed by LFS
+        if not output:
+            return True
+
+        # Match all lines beginning with the hexadecimal OID
+        oid_regex = re.compile("^(([a-fA-F0-9]{2})([a-fA-F0-9]{2})[A-Fa-f0-9]+)")
+        for line in output.split("\n"):
+            oid = re.search(oid_regex, line)
+            if not oid:
+                bb.warn("git lfs ls-files output '%s' did not match expected format." % line)
+            if not os.path.exists(os.path.join(wd, "lfs", "objects", oid.group(2), oid.group(3), oid.group(1))):
+                return False
+
+        return True
+
     def _need_lfs(self, ud):
         return ud.parm.get("lfs", "1") == "1"
 
@@ -820,9 +861,8 @@ class Git(FetchMethod):
             commits = None
         else:
             if not os.path.exists(rev_file) or not os.path.getsize(rev_file):
-                from pipes import quote
                 commits = bb.fetch2.runfetchcmd(
-                        "git rev-list %s -- | wc -l" % quote(rev),
+                        "git rev-list %s -- | wc -l" % shlex.quote(rev),
                         d, quiet=True).strip().lstrip('0')
                 if commits:
                     open(rev_file, "w").write("%d\n" % int(commits))

bitbake/lib/bb/fetch2/gitsm.py

@@ -139,6 +139,19 @@ class GitSM(Git):
 
         return submodules != []
 
+    def call_process_submodules(self, ud, d, extra_check, subfunc):
+        # If we're using a shallow mirror tarball it needs to be
+        # unpacked temporarily so that we can examine the .gitmodules file
+        if ud.shallow and os.path.exists(ud.fullshallow) and extra_check:
+            tmpdir = tempfile.mkdtemp(dir=d.getVar("DL_DIR"))
+            try:
+                runfetchcmd("tar -xzf %s" % ud.fullshallow, d, workdir=tmpdir)
+                self.process_submodules(ud, tmpdir, subfunc, d)
+            finally:
+                shutil.rmtree(tmpdir)
+        else:
+            self.process_submodules(ud, ud.clonedir, subfunc, d)
+
     def need_update(self, ud, d):
         if Git.need_update(self, ud, d):
             return True
@@ -156,15 +169,7 @@ class GitSM(Git):
                 logger.error('gitsm: submodule update check failed: %s %s' % (type(e).__name__, str(e)))
                 need_update_result = True
 
-        # If we're using a shallow mirror tarball it needs to be unpacked
-        # temporarily so that we can examine the .gitmodules file
-        if ud.shallow and os.path.exists(ud.fullshallow) and not os.path.exists(ud.clonedir):
-            tmpdir = tempfile.mkdtemp(dir=d.getVar("DL_DIR"))
-            runfetchcmd("tar -xzf %s" % ud.fullshallow, d, workdir=tmpdir)
-            self.process_submodules(ud, tmpdir, need_update_submodule, d)
-            shutil.rmtree(tmpdir)
-        else:
-            self.process_submodules(ud, ud.clonedir, need_update_submodule, d)
+        self.call_process_submodules(ud, d, not os.path.exists(ud.clonedir), need_update_submodule)
 
         if need_update_list:
             logger.debug('gitsm: Submodules requiring update: %s' % (' '.join(need_update_list)))
@@ -187,16 +192,7 @@ class GitSM(Git):
                 raise
 
         Git.download(self, ud, d)
-
-        # If we're using a shallow mirror tarball it needs to be unpacked
-        # temporarily so that we can examine the .gitmodules file
-        if ud.shallow and os.path.exists(ud.fullshallow) and self.need_update(ud, d):
-            tmpdir = tempfile.mkdtemp(dir=d.getVar("DL_DIR"))
-            runfetchcmd("tar -xzf %s" % ud.fullshallow, d, workdir=tmpdir)
-            self.process_submodules(ud, tmpdir, download_submodule, d)
-            shutil.rmtree(tmpdir)
-        else:
-            self.process_submodules(ud, ud.clonedir, download_submodule, d)
+        self.call_process_submodules(ud, d, self.need_update(ud, d), download_submodule)
 
     def unpack(self, ud, destdir, d):
         def unpack_submodules(ud, url, module, modpath, workdir, d):
@@ -249,14 +245,6 @@ class GitSM(Git):
             newfetch = Fetch([url], d, cache=False)
             urldata.extend(newfetch.expanded_urldata())
 
-        # If we're using a shallow mirror tarball it needs to be unpacked
-        # temporarily so that we can examine the .gitmodules file
-        if ud.shallow and os.path.exists(ud.fullshallow) and ud.method.need_update(ud, d):
-            tmpdir = tempfile.mkdtemp(dir=d.getVar("DL_DIR"))
-            subprocess.check_call("tar -xzf %s" % ud.fullshallow, cwd=tmpdir, shell=True)
-            self.process_submodules(ud, tmpdir, add_submodule, d)
-            shutil.rmtree(tmpdir)
-        else:
-            self.process_submodules(ud, ud.clonedir, add_submodule, d)
+        self.call_process_submodules(ud, d, ud.method.need_update(ud, d), add_submodule)
 
         return urldata

bitbake/lib/bb/fetch2/wget.py

@@ -88,7 +88,10 @@ class Wget(FetchMethod):
         if not ud.localfile:
             ud.localfile = d.expand(urllib.parse.unquote(ud.host + ud.path).replace("/", "."))
 
-        self.basecmd = d.getVar("FETCHCMD_wget") or "/usr/bin/env wget -t 2 -T 30 --passive-ftp"
+        self.basecmd = d.getVar("FETCHCMD_wget") or "/usr/bin/env wget -t 2 -T 100"
+
+        if ud.type == 'ftp' or ud.type == 'ftps':
+            self.basecmd += " --passive-ftp"
 
         if not self.check_certs(d):
             self.basecmd += " --no-check-certificate"
@@ -106,10 +109,10 @@ class Wget(FetchMethod):
 
         fetchcmd = self.basecmd
 
-        if 'downloadfilename' in ud.parm:
-            localpath = os.path.join(d.getVar("DL_DIR"), ud.localfile)
-            bb.utils.mkdirhier(os.path.dirname(localpath))
-            fetchcmd += " -O %s" % shlex.quote(localpath)
+        dldir = os.path.realpath(d.getVar("DL_DIR"))
+        localpath = os.path.join(dldir, ud.localfile) + ".tmp"
+        bb.utils.mkdirhier(os.path.dirname(localpath))
+        fetchcmd += " -O %s" % shlex.quote(localpath)
 
         if ud.user and ud.pswd:
             fetchcmd += " --auth-no-challenge"
@@ -127,12 +130,16 @@ class Wget(FetchMethod):
         uri = ud.url.split(";")[0]
         if os.path.exists(ud.localpath):
             # file exists, but we didnt complete it.. trying again..
-            fetchcmd += d.expand(" -c -P ${DL_DIR} '%s'" % uri)
+            fetchcmd += " -c -P " + dldir + " '" + uri + "'"
         else:
-            fetchcmd += d.expand(" -P ${DL_DIR} '%s'" % uri)
+            fetchcmd += " -P " + dldir + " '" + uri + "'"
 
         self._runwget(ud, d, fetchcmd, False)
 
+        # Remove the ".tmp" and move the file into position atomically
+        # Our lock prevents multiple writers but mirroring code may grab incomplete files
+        os.rename(localpath, localpath[:-4])
+
         # Sanity check since wget can pretend it succeed when it didn't
         # Also, this used to happen if sourceforge sent us to the mirror page
         if not os.path.exists(ud.localpath):
@@ -358,7 +365,7 @@ class Wget(FetchMethod):
                 except (TypeError, ImportError, IOError, netrc.NetrcParseError):
                     pass
 
-                with opener.open(r, timeout=30) as response:
+                with opener.open(r, timeout=100) as response:
                     pass
             except urllib.error.URLError as e:
                 if try_again:

bitbake/lib/bb/monitordisk.py

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

bitbake/lib/bb/parse/__init__.py

@@ -49,20 +49,23 @@ class SkipPackage(SkipRecipe):
 __mtime_cache = {}
 def cached_mtime(f):
     if f not in __mtime_cache:
-        __mtime_cache[f] = os.stat(f)[stat.ST_MTIME]
+        res = os.stat(f)
+        __mtime_cache[f] = (res.st_mtime_ns, res.st_size, res.st_ino)
     return __mtime_cache[f]
 
 def cached_mtime_noerror(f):
     if f not in __mtime_cache:
         try:
-            __mtime_cache[f] = os.stat(f)[stat.ST_MTIME]
+            res = os.stat(f)
+            __mtime_cache[f] = (res.st_mtime_ns, res.st_size, res.st_ino)
         except OSError:
             return 0
     return __mtime_cache[f]
 
 def update_mtime(f):
     try:
-        __mtime_cache[f] = os.stat(f)[stat.ST_MTIME]
+        res = os.stat(f)
+        __mtime_cache[f] = (res.st_mtime_ns, res.st_size, res.st_ino)
     except OSError:
         if f in __mtime_cache:
             del __mtime_cache[f]

bitbake/lib/bb/persist_data.py

@@ -154,6 +154,7 @@ class SQLTable(collections.abc.MutableMapping):
 
     def __exit__(self, *excinfo):
         self.connection.__exit__(*excinfo)
+        self.connection.close()
 
     @_Decorators.retry()
     @_Decorators.transaction

bitbake/lib/bb/runqueue.py

@@ -198,15 +198,27 @@ class RunQueueScheduler(object):
                 curr_cpu_pressure = cpu_pressure_fds.readline().split()[4].split("=")[1]
                 curr_io_pressure = io_pressure_fds.readline().split()[4].split("=")[1]
                 curr_memory_pressure = memory_pressure_fds.readline().split()[4].split("=")[1]
-                exceeds_cpu_pressure =  self.rq.max_cpu_pressure and (float(curr_cpu_pressure) - float(self.prev_cpu_pressure)) > self.rq.max_cpu_pressure
-                exceeds_io_pressure =  self.rq.max_io_pressure and (float(curr_io_pressure) - float(self.prev_io_pressure)) > self.rq.max_io_pressure
-                exceeds_memory_pressure = self.rq.max_memory_pressure and (float(curr_memory_pressure) - float(self.prev_memory_pressure)) > self.rq.max_memory_pressure
                 now = time.time()
-                if now - self.prev_pressure_time > 1.0:
+                tdiff = now - self.prev_pressure_time
+                psi_accumulation_interval = 1.0
+                cpu_pressure = (float(curr_cpu_pressure) - float(self.prev_cpu_pressure)) / tdiff
+                io_pressure = (float(curr_io_pressure) - float(self.prev_io_pressure)) / tdiff
+                memory_pressure = (float(curr_memory_pressure) - float(self.prev_memory_pressure)) / tdiff
+                exceeds_cpu_pressure =  self.rq.max_cpu_pressure and cpu_pressure > self.rq.max_cpu_pressure
+                exceeds_io_pressure =  self.rq.max_io_pressure and io_pressure > self.rq.max_io_pressure
+                exceeds_memory_pressure =  self.rq.max_memory_pressure and memory_pressure > self.rq.max_memory_pressure
+
+                if tdiff > psi_accumulation_interval:
                     self.prev_cpu_pressure = curr_cpu_pressure
                     self.prev_io_pressure = curr_io_pressure
                     self.prev_memory_pressure = curr_memory_pressure
                     self.prev_pressure_time = now
+
+            pressure_state = (exceeds_cpu_pressure, exceeds_io_pressure, exceeds_memory_pressure)
+            pressure_values = (round(cpu_pressure,1), self.rq.max_cpu_pressure, round(io_pressure,1), self.rq.max_io_pressure, round(memory_pressure,1), self.rq.max_memory_pressure)
+            if hasattr(self, "pressure_state") and pressure_state != self.pressure_state:
+                bb.note("Pressure status changed to CPU: %s, IO: %s, Mem: %s (CPU: %s/%s, IO: %s/%s, Mem: %s/%s) - using %s/%s bitbake threads" % (pressure_state + pressure_values + (len(self.rq.runq_running.difference(self.rq.runq_complete)), self.rq.number_tasks)))
+            self.pressure_state = pressure_state
             return (exceeds_cpu_pressure or exceeds_io_pressure or exceeds_memory_pressure)
         return False
 
@@ -1980,12 +1992,12 @@ class RunQueueExecute:
                 # Allow the next deferred task to run. Any other deferred tasks should be deferred after that task.
                 # We shouldn't allow all to run at once as it is prone to races.
                 if not found:
-                    bb.note("Deferred task %s now buildable" % t)
+                    bb.debug(1, "Deferred task %s now buildable" % t)
                     del self.sq_deferred[t]
                     update_scenequeue_data([t], self.sqdata, self.rqdata, self.rq, self.cooker, self.stampcache, self, summary=False)
                     found = t
                 else:
-                    bb.note("Deferring %s after %s" % (t, found))
+                    bb.debug(1, "Deferring %s after %s" % (t, found))
                     self.sq_deferred[t] = found
 
     def task_complete(self, task):
@@ -2892,7 +2904,7 @@ def build_scenequeue_data(sqdata, rqdata, rq, cooker, stampcache, sqrq):
                 sqdata.hashes[h] = tid
             else:
                 sqrq.sq_deferred[tid] = sqdata.hashes[h]
-                bb.note("Deferring %s after %s" % (tid, sqdata.hashes[h]))
+                bb.debug(1, "Deferring %s after %s" % (tid, sqdata.hashes[h]))
 
     update_scenequeue_data(sqdata.sq_revdeps, sqdata, rqdata, rq, cooker, stampcache, sqrq, summary=True)
 

bitbake/lib/bb/siggen.py

@@ -331,7 +331,7 @@ class SignatureGeneratorBasic(SignatureGenerator):
         for dep in self.runtaskdeps[tid]:
             data += self.get_unihash(dep)
 
-        for (f, cs) in self.file_checksum_values[tid]:
+        for (f, cs) in sorted(self.file_checksum_values[tid], key=clean_checksum_file_path):
             if cs:
                 if "/./" in f:
                     data += "./" + f.split("/./")[1]
@@ -393,7 +393,7 @@ class SignatureGeneratorBasic(SignatureGenerator):
         if runtime and tid in self.taskhash:
             data['runtaskdeps'] = self.runtaskdeps[tid]
             data['file_checksum_values'] = []
-            for f,cs in self.file_checksum_values[tid]:
+            for f,cs in sorted(self.file_checksum_values[tid], key=clean_checksum_file_path):
                 if "/./" in f:
                     data['file_checksum_values'].append(("./" + f.split("/./")[1], cs))
                 else:
@@ -720,6 +720,12 @@ class SignatureGeneratorTestMulticonfigDepends(SignatureGeneratorBasicHash):
     name = "TestMulticonfigDepends"
     supports_multiconfig_datacaches = True
 
+def clean_checksum_file_path(file_checksum_tuple):
+    f, cs = file_checksum_tuple
+    if "/./" in f:
+        return "./" + f.split("/./")[1]
+    return f
+
 def dump_this_task(outfile, d):
     import bb.parse
     fn = d.getVar("BB_FILENAME")

bitbake/lib/bb/tests/codeparser.py

@@ -430,6 +430,32 @@ esac
         self.assertEqual(deps, set(["TESTVAR2"]))
         self.assertEqual(self.d.getVar('ANOTHERVAR').split(), ['testval3', 'anothervalue'])
 
+    def test_contains_vardeps_override_operators(self):
+        # Check override operators handle dependencies correctly with the contains functionality
+        expr_plain = 'testval'
+        expr_prepend = '${@bb.utils.filter("TESTVAR1", "testval1", d)} '
+        expr_append = ' ${@bb.utils.filter("TESTVAR2", "testval2", d)}'
+        expr_remove = '${@bb.utils.contains("TESTVAR3", "no-testval", "testval", "", d)}'
+        # Check dependencies
+        self.d.setVar('ANOTHERVAR', expr_plain)
+        self.d.prependVar('ANOTHERVAR', expr_prepend)
+        self.d.appendVar('ANOTHERVAR', expr_append)
+        self.d.setVar('ANOTHERVAR:remove', expr_remove)
+        self.d.setVar('TESTVAR1', 'blah')
+        self.d.setVar('TESTVAR2', 'testval2')
+        self.d.setVar('TESTVAR3', 'no-testval')
+        deps, values = bb.data.build_dependencies("ANOTHERVAR", set(self.d.keys()), set(), set(), set(), self.d)
+        self.assertEqual(sorted(values.splitlines()),
+                         sorted([
+                          expr_prepend + expr_plain + expr_append,
+                          '_remove of ' + expr_remove,
+                          'TESTVAR1{testval1} = Unset',
+                          'TESTVAR2{testval2} = Set',
+                          'TESTVAR3{no-testval} = Set',
+                          ]))
+        # Check final value
+        self.assertEqual(self.d.getVar('ANOTHERVAR').split(), ['testval2'])
+
     #Currently no wildcard support
     #def test_vardeps_wildcards(self):
     #    self.d.setVar("oe_libinstall", "echo test")

bitbake/lib/bb/tests/fetch.py

@@ -6,6 +6,7 @@
 # SPDX-License-Identifier: GPL-2.0-only
 #
 
+import contextlib
 import unittest
 import hashlib
 import tempfile
@@ -1332,12 +1333,12 @@ class FetchLatestVersionTest(FetcherTest):
         ("dtc", "git://git.yoctoproject.org/bbfetchtests-dtc.git;branch=master", "65cc4d2748a2c2e6f27f1cf39e07a5dbabd80ebf", "")
             : "1.4.0",
         # combination version pattern
-        ("sysprof", "git://gitlab.gnome.org/GNOME/sysprof.git;protocol=https;branch=master", "cd44ee6644c3641507fb53b8a2a69137f2971219", "")
+        ("sysprof", "git://git.yoctoproject.org/sysprof.git;protocol=https;branch=master", "cd44ee6644c3641507fb53b8a2a69137f2971219", "")
             : "1.2.0",
-        ("u-boot-mkimage", "git://git.denx.de/u-boot.git;branch=master;protocol=git", "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://gitlab.gnome.org/GNOME/mobile-broadband-provider-info.git;protocol=https;branch=master", "4ed19e11c2975105b71b956440acdb25d46a347d", "")
+        ("mobile-broadband-provider-info", "git://git.yoctoproject.org/mobile-broadband-provider-info.git;protocol=https;branch=master", "4ed19e11c2975105b71b956440acdb25d46a347d", "")
             : "20120614",
         # packages with a valid UPSTREAM_CHECK_GITTAGREGEX
                 # mirror of git://anongit.freedesktop.org/xorg/driver/xf86-video-omap since network issues interfered with testing
@@ -1416,7 +1417,7 @@ class FetchLatestVersionTest(FetcherTest):
 
     def test_wget_latest_versionstring(self):
         testdata = os.path.dirname(os.path.abspath(__file__)) + "/fetch-testdata"
-        server = HTTPService(testdata)
+        server = HTTPService(testdata, host="127.0.0.1")
         server.start()
         port = server.port
         try:
@@ -1424,10 +1425,10 @@ class FetchLatestVersionTest(FetcherTest):
                 self.d.setVar("PN", k[0])
                 checkuri = ""
                 if k[2]:
-                    checkuri = "http://localhost:%s/" % port + k[2]
+                    checkuri = "http://127.0.0.1:%s/" % port + k[2]
                 self.d.setVar("UPSTREAM_CHECK_URI", checkuri)
                 self.d.setVar("UPSTREAM_CHECK_REGEX", k[3])
-                url = "http://localhost:%s/" % port + k[1]
+                url = "http://127.0.0.1:%s/" % port + k[1]
                 ud = bb.fetch2.FetchData(url, self.d)
                 pupver = ud.method.latest_versionstring(ud, self.d)
                 verstring = pupver[0]
@@ -1620,6 +1621,8 @@ class GitShallowTest(FetcherTest):
         if cwd is None:
             cwd = self.gitdir
         actual_refs = self.git(['for-each-ref', '--format=%(refname)'], cwd=cwd).splitlines()
+        # Resolve references into the same format as the comparision (needed by git 2.48 onwards)
+        actual_refs = self.git(['rev-parse', '--symbolic-full-name'] + actual_refs, cwd=cwd).splitlines()
         full_expected = self.git(['rev-parse', '--symbolic-full-name'] + expected_refs, cwd=cwd).splitlines()
         self.assertEqual(sorted(set(full_expected)), sorted(set(actual_refs)))
 
@@ -2159,6 +2162,12 @@ class GitShallowTest(FetcherTest):
         self.assertIn("fstests.doap", dir)
 
 class GitLfsTest(FetcherTest):
+    def skipIfNoGitLFS():
+        import shutil
+        if not shutil.which('git-lfs'):
+            return unittest.skip('git-lfs not installed')
+        return lambda f: f
+
     def setUp(self):
         FetcherTest.setUp(self)
 
@@ -2176,10 +2185,14 @@ class GitLfsTest(FetcherTest):
 
         bb.utils.mkdirhier(self.srcdir)
         self.git_init(cwd=self.srcdir)
-        with open(os.path.join(self.srcdir, '.gitattributes'), 'wt') as attrs:
-            attrs.write('*.mp3 filter=lfs -text')
-        self.git(['add', '.gitattributes'], cwd=self.srcdir)
-        self.git(['commit', '-m', "attributes", '.gitattributes'], cwd=self.srcdir)
+        self.commit_file('.gitattributes', '*.mp3 filter=lfs -text')
+
+    def commit_file(self, filename, content):
+        with open(os.path.join(self.srcdir, filename), "w") as f:
+            f.write(content)
+        self.git(["add", filename], cwd=self.srcdir)
+        self.git(["commit", "-m", "Change"], cwd=self.srcdir)
+        return self.git(["rev-parse", "HEAD"], cwd=self.srcdir).strip()
 
     def fetch(self, uri=None, download=True):
         uris = self.d.getVar('SRC_URI').split()
@@ -2192,6 +2205,82 @@ class GitLfsTest(FetcherTest):
         ud = fetcher.ud[uri]
         return fetcher, ud
 
+    def get_real_git_lfs_file(self):
+        self.d.setVar('PATH', os.environ.get('PATH'))
+        fetcher, ud = self.fetch()
+        fetcher.unpack(self.d.getVar('WORKDIR'))
+        unpacked_lfs_file = os.path.join(self.d.getVar('WORKDIR'), 'git', "Cat_poster_1.jpg")
+        return unpacked_lfs_file
+
+    @skipIfNoGitLFS()
+    def test_fetch_lfs_on_srcrev_change(self):
+        """Test if fetch downloads missing LFS objects when a different revision within an existing repository is requested"""
+        self.git(["lfs", "install", "--local"], cwd=self.srcdir)
+
+        @contextlib.contextmanager
+        def hide_upstream_repository():
+            """Hide the upstream repository to make sure that git lfs cannot pull from it"""
+            temp_name = self.srcdir + ".bak"
+            os.rename(self.srcdir, temp_name)
+            try:
+                yield
+            finally:
+                os.rename(temp_name, self.srcdir)
+
+        def fetch_and_verify(revision, filename, content):
+            self.d.setVar('SRCREV', revision)
+            fetcher, ud = self.fetch()
+
+            with hide_upstream_repository():
+                workdir = self.d.getVar('WORKDIR')
+                fetcher.unpack(workdir)
+
+                with open(os.path.join(workdir, "git", filename)) as f:
+                    self.assertEqual(f.read(), content)
+
+        commit_1 = self.commit_file("a.mp3", "version 1")
+        commit_2 = self.commit_file("a.mp3", "version 2")
+
+        self.d.setVar('SRC_URI', "git://%s;protocol=file;lfs=1;branch=master" % self.srcdir)
+
+        # Seed the local download folder by fetching the latest commit and verifying that the LFS contents are
+        # available even when the upstream repository disappears.
+        fetch_and_verify(commit_2, "a.mp3", "version 2")
+        # Verify that even when an older revision is fetched, the needed LFS objects are fetched into the download
+        # folder.
+        fetch_and_verify(commit_1, "a.mp3", "version 1")
+
+    @skipIfNoGitLFS()
+    @skipIfNoNetwork()
+    def test_real_git_lfs_repo_succeeds_without_lfs_param(self):
+        self.d.setVar('SRC_URI', "git://gitlab.com/gitlab-examples/lfs.git;protocol=https;branch=master")
+        f = self.get_real_git_lfs_file()
+        self.assertTrue(os.path.exists(f))
+        self.assertEqual("c0baab607a97839c9a328b4310713307", bb.utils.md5_file(f))
+
+    @skipIfNoGitLFS()
+    @skipIfNoNetwork()
+    def test_real_git_lfs_repo_succeeds(self):
+        self.d.setVar('SRC_URI', "git://gitlab.com/gitlab-examples/lfs.git;protocol=https;branch=master;lfs=1")
+        f = self.get_real_git_lfs_file()
+        self.assertTrue(os.path.exists(f))
+        self.assertEqual("c0baab607a97839c9a328b4310713307", bb.utils.md5_file(f))
+
+    @skipIfNoGitLFS()
+    @skipIfNoNetwork()
+    def test_real_git_lfs_repo_succeeds(self):
+        self.d.setVar('SRC_URI', "git://gitlab.com/gitlab-examples/lfs.git;protocol=https;branch=master;lfs=0")
+        f = self.get_real_git_lfs_file()
+        # This is the actual non-smudged placeholder file on the repo if git-lfs does not run
+        lfs_file = (
+                   'version https://git-lfs.github.com/spec/v1\n'
+                   'oid sha256:34be66b1a39a1955b46a12588df9d5f6fc1da790e05cf01f3c7422f4bbbdc26b\n'
+                   'size 11423554\n'
+        )
+
+        with open(f) as fh:
+            self.assertEqual(lfs_file, fh.read())
+
     def test_lfs_enabled(self):
         import shutil
 
@@ -2210,12 +2299,16 @@ class GitLfsTest(FetcherTest):
             shutil.rmtree(self.gitdir, ignore_errors=True)
             fetcher.unpack(self.d.getVar('WORKDIR'))
 
-        # If git-lfs cannot be found, the unpack should throw an error
-        with self.assertRaises(bb.fetch2.FetchError):
-            fetcher.download()
-            ud.method._find_git_lfs = lambda d: False
-            shutil.rmtree(self.gitdir, ignore_errors=True)
-            fetcher.unpack(self.d.getVar('WORKDIR'))
+        old_find_git_lfs = ud.method._find_git_lfs
+        try:
+            # If git-lfs cannot be found, the unpack should throw an error
+            with self.assertRaises(bb.fetch2.FetchError):
+                fetcher.download()
+                ud.method._find_git_lfs = lambda d: False
+                shutil.rmtree(self.gitdir, ignore_errors=True)
+                fetcher.unpack(self.d.getVar('WORKDIR'))
+        finally:
+            ud.method._find_git_lfs = old_find_git_lfs
 
     def test_lfs_disabled(self):
         import shutil
@@ -2230,17 +2323,21 @@ class GitLfsTest(FetcherTest):
         fetcher, ud = self.fetch()
         self.assertIsNotNone(ud.method._find_git_lfs)
 
-        # If git-lfs can be found, the unpack should be successful. A
-        # live copy of git-lfs is not required for this case, so
-        # unconditionally forge its presence.
-        ud.method._find_git_lfs = lambda d: True
-        shutil.rmtree(self.gitdir, ignore_errors=True)
-        fetcher.unpack(self.d.getVar('WORKDIR'))
+        old_find_git_lfs = ud.method._find_git_lfs
+        try:
+            # If git-lfs can be found, the unpack should be successful. A
+            # live copy of git-lfs is not required for this case, so
+            # unconditionally forge its presence.
+            ud.method._find_git_lfs = lambda d: True
+            shutil.rmtree(self.gitdir, ignore_errors=True)
+            fetcher.unpack(self.d.getVar('WORKDIR'))
+            # If git-lfs cannot be found, the unpack should be successful
 
-        # If git-lfs cannot be found, the unpack should be successful
-        ud.method._find_git_lfs = lambda d: False
-        shutil.rmtree(self.gitdir, ignore_errors=True)
-        fetcher.unpack(self.d.getVar('WORKDIR'))
+            ud.method._find_git_lfs = lambda d: False
+            shutil.rmtree(self.gitdir, ignore_errors=True)
+            fetcher.unpack(self.d.getVar('WORKDIR'))
+        finally:
+            ud.method._find_git_lfs = old_find_git_lfs
 
 class GitURLWithSpacesTest(FetcherTest):
     test_git_urls = {

bitbake/lib/bb/tinfoil.py

@@ -324,11 +324,11 @@ class Tinfoil:
         self.recipes_parsed = False
         self.quiet = 0
         self.oldhandlers = self.logger.handlers[:]
+        self.localhandlers = []
         if setup_logging:
             # This is the *client-side* logger, nothing to do with
             # logging messages from the server
             bb.msg.logger_create('BitBake', output)
-            self.localhandlers = []
             for handler in self.logger.handlers:
                 if handler not in self.oldhandlers:
                     self.localhandlers.append(handler)

bitbake/lib/bs4/tests/test_tree.py

@@ -585,7 +585,7 @@ class SiblingTest(TreeTest):
                     </html>'''
         # All that whitespace looks good but makes the tests more
         # difficult. Get rid of it.
-        markup = re.compile("\n\s*").sub("", markup)
+        markup = re.compile(r"\n\s*").sub("", markup)
         self.tree = self.soup(markup)
 
 

bitbake/lib/hashserv/tests.py

@@ -30,7 +30,7 @@ class HashEquivalenceTestSetup(object):
 
     server_index = 0
 
-    def start_server(self, dbpath=None, upstream=None, read_only=False, prefunc=server_prefunc):
+    def start_server(self, dbpath=None, upstream=None, read_only=False, prefunc=server_prefunc, need_client=True):
         self.server_index += 1
         if dbpath is None:
             dbpath = os.path.join(self.temp_dir.name, "db%d.sqlite" % self.server_index)
@@ -54,8 +54,11 @@ class HashEquivalenceTestSetup(object):
         def cleanup_client(client):
             client.close()
 
-        client = create_client(server.address)
-        self.addCleanup(cleanup_client, client)
+        if need_client:
+            client = create_client(server.address)
+            self.addCleanup(cleanup_client, client)
+        else:
+            client = None
 
         return (client, server)
 
@@ -341,7 +344,7 @@ class HashEquivalenceCommonTests(object):
         old_signal = signal.signal(signal.SIGTERM, do_nothing)
         self.addCleanup(signal.signal, signal.SIGTERM, old_signal)
 
-        _, server = self.start_server(prefunc=prefunc)
+        _, server = self.start_server(prefunc=prefunc, need_client=False)
         server.process.terminate()
         time.sleep(30)
         event.set()

bitbake/lib/prserv/serv.py

@@ -344,9 +344,9 @@ def auto_shutdown():
 def ping(host, port):
     from . import client
 
-    conn = client.PRClient()
-    conn.connect_tcp(host, port)
-    return conn.ping()
+    with client.PRClient() as conn:
+        conn.connect_tcp(host, port)
+        return conn.ping()
 
 def connect(host, port):
     from . import client

bitbake/lib/toaster/toastergui/api.py

@@ -11,7 +11,7 @@ import os
 import re
 import logging
 import json
-import subprocess
+import glob
 from collections import Counter
 
 from orm.models import Project, ProjectTarget, Build, Layer_Version
@@ -227,20 +227,18 @@ class XhrSetDefaultImageUrl(View):
 #    same logical name
 #  * Each project that uses a layer will have its own
 #    LayerVersion and Project Layer for it
-#  * During the Paroject delete process, when the last
+#  * During the Project delete process, when the last
 #    LayerVersion for a 'local_source_dir' layer is deleted
 #    then the Layer record is deleted to remove orphans
 #
 
 def scan_layer_content(layer,layer_version):
     # if this is a local layer directory, we can immediately scan its content
-    if layer.local_source_dir:
+    if os.path.isdir(layer.local_source_dir):
         try:
             # recipes-*/*/*.bb
-            cmd = '%s %s' % ('ls', os.path.join(layer.local_source_dir,'recipes-*/*/*.bb'))
-            recipes_list = subprocess.Popen(cmd, shell=True, stdout=subprocess.PIPE,stderr=subprocess.STDOUT).stdout.read()
-            recipes_list = recipes_list.decode("utf-8").strip()
-            if recipes_list and 'No such' not in recipes_list:
+            recipes_list = glob.glob(os.path.join(layer.local_source_dir, 'recipes-*/*/*.bb'))
+            for recipe in recipes_list:
                 for recipe in recipes_list.split('\n'):
                     recipe_path = recipe[recipe.rfind('recipes-'):]
                     recipe_name = recipe[recipe.rfind('/')+1:].replace('.bb','')
@@ -260,6 +258,9 @@ def scan_layer_content(layer,layer_version):
 
         except Exception as e:
             logger.warning("ERROR:scan_layer_content: %s" % e)
+    else:
+        logger.warning("ERROR: wrong path given")
+        raise KeyError("local_source_dir")
 
 class XhrLayer(View):
     """ Delete, Get, Add and Update Layer information
@@ -456,15 +457,18 @@ class XhrLayer(View):
                              'layerdetailurl':
                              layer_dep.get_detailspage_url(project.pk)})
 
-            # Scan the layer's content and update components
-            scan_layer_content(layer,layer_version)
+            # Only scan_layer_content if layer is local
+            if layer_data.get('local_source_dir', None):
+                # Scan the layer's content and update components
+                scan_layer_content(layer,layer_version)
 
         except Layer_Version.DoesNotExist:
             return error_response("layer-dep-not-found")
         except Project.DoesNotExist:
             return error_response("project-not-found")
-        except KeyError:
-            return error_response("incorrect-parameters")
+        except KeyError as e:
+            _log("KeyError: %s" % e)
+            return error_response(f"incorrect-parameters")
 
         return JsonResponse({'error': "ok",
                              'imported_layer': {

documentation/.gitignore

@@ -5,3 +5,5 @@ sphinx-static/switchers.js
 .vscode/
 */svg/*.png
 */svg/*.pdf
+styles/*
+!styles/config

documentation/.vale.ini

@@ -0,0 +1,7 @@
+StylesPath = styles
+MinAlertLevel = suggestion
+Packages = RedHat, proselint, write-good, alex, Readability, Joblint
+Vocab = Yocto, OpenSource
+[*.rst]
+BasedOnStyles = Vale, RedHat, proselint, write-good, alex, Readability, Joblint
+

documentation/Makefile

@@ -3,14 +3,18 @@
 
 # You can set these variables from the command line, and also
 # from the environment for the first two.
-SPHINXOPTS    ?= -W --keep-going -j auto
-SPHINXBUILD   ?= sphinx-build
-SOURCEDIR     = .
-IMAGEDIRS     = */svg
-BUILDDIR      = _build
-DESTDIR       = final
-SVG2PNG       = inkscape
-SVG2PDF       = inkscape
+SPHINXOPTS     ?= -W --keep-going -j auto
+SPHINXBUILD    ?= sphinx-build
+# Release notes are excluded because they contain contributor names and commit messages which can't be modified
+VALEOPTS       ?= --no-wrap --glob '!migration-guides/release-notes-*.rst'
+SOURCEDIR      = .
+VALEDOCS       ?= $(SOURCEDIR)
+SPHINXLINTDOCS ?= $(SOURCEDIR)
+IMAGEDIRS      = */svg
+BUILDDIR       = _build
+DESTDIR        = final
+SVG2PNG        = inkscape
+SVG2PDF        = inkscape
 
 ifeq ($(shell if which $(SPHINXBUILD) >/dev/null 2>&1; then echo 1; else echo 0; fi),0)
 $(error "The '$(SPHINXBUILD)' command was not found. Make sure you have Sphinx installed")
@@ -20,7 +24,7 @@ endif
 help:
 	@$(SPHINXBUILD) -M help "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
 
-.PHONY: all help Makefile clean publish epub latexpdf
+.PHONY: all help Makefile clean stylecheck publish epub latexpdf
 
 publish: Makefile html singlehtml
 	rm -rf $(BUILDDIR)/$(DESTDIR)/
@@ -46,10 +50,19 @@ PNGs := $(foreach dir, $(IMAGEDIRS), $(patsubst %.svg,%.png,$(wildcard $(SOURCED
 clean:
 	@rm -rf $(BUILDDIR) $(PNGs) $(PDFs) poky.yaml sphinx-static/switchers.js
 
+stylecheck:
+	vale sync
+	vale $(VALEOPTS) $(VALEDOCS)
+
+sphinx-lint:
+	sphinx-lint $(SPHINXLINTDOCS)
+
 epub: $(PNGs)
+	$(SOURCEDIR)/set_versions.py
 	@$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
 
 latexpdf: $(PDFs)
+	$(SOURCEDIR)/set_versions.py
 	@$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
 
 all: html epub latexpdf

documentation/README

@@ -151,6 +151,50 @@ dependencies in a virtual environment:
  $ pipenv install
  $ pipenv run make html
 
+Style checking the Yocto Project documentation
+==============================================
+
+The project is starting to use Vale (https://vale.sh/)
+to validate the text style.
+
+To install Vale:
+
+ $ pip install vale
+
+To run Vale:
+
+ $ make stylecheck
+
+Style checking the whole documentation might take some time and generate a
+lot of warnings/errors, thus one can run Vale on a subset of files or
+directories:
+
+  $ make stylecheck VALEDOCS=<file>
+  $ make stylecheck VALEDOCS="<file1> <file2>"
+  $ make stylecheck VALEDOCS=<dir>
+
+Lint checking the Yocto Project documentation
+=============================================
+
+To fix errors which are not reported by Sphinx itself,
+the project uses sphinx-lint (https://github.com/sphinx-contrib/sphinx-lint).
+
+To install sphinx-lint:
+
+ $ pip install sphinx-lint
+
+To run sphinx-lint:
+
+ $ make sphinx-lint
+
+Lint checking the whole documentation might take some time and generate a
+lot of warnings/errors, thus one can run sphinx-lint on a subset of files
+or directories:
+
+  $ make sphinx-lint SPHINXLINTDOCS=<file>
+  $ make sphinx-lint SPHINXLINTDOCS="<file1> <file2>"
+  $ make sphinx-lint SPHINXLINTDOCS=<dir>
+
 Sphinx theme and CSS customization
 ==================================
 
@@ -385,5 +429,22 @@ both the Yocto Project and BitBake manuals:
 Submitting documentation changes
 ================================
 
-Please see the top level README file in this repository for details of where
-to send patches.
+Please refer to our contributor guide here: https://docs.yoctoproject.org/contributor-guide/
+for full details on how to submit changes.
+
+As a quick guide, patches should be sent to docs@lists.yoctoproject.org
+The git command to do that would be:
+
+     git send-email -M -1 --to docs@lists.yoctoproject.org
+
+The 'To' header can be set as default for this repository:
+
+     git config sendemail.to docs@lists.yoctoproject.org
+
+Now you can just do 'git send-email origin/master..' to send all local patches.
+
+Read the other sections in this document and documentation/standards.md for
+rules to follow when contributing to the documentation.
+
+Git repository: https://git.yoctoproject.org/yocto-docs
+Mailing list: docs@lists.yoctoproject.org

documentation/brief-yoctoprojectqs/index.rst

@@ -25,18 +25,11 @@ build a reference embedded OS called Poky.
       in the Yocto Project Development Tasks Manual for more
       information.
 
-   -  You may use Windows Subsystem For Linux v2 to set up a build host
-      using Windows 10.
-
-      .. note::
-
-         The Yocto Project is not compatible with WSLv1, it is
-         compatible but not officially supported nor validated with
-         WSLv2, if you still decide to use WSL please upgrade to WSLv2.
-
-      See the :ref:`dev-manual/start:setting up to use windows
-      subsystem for linux (wslv2)` section in the Yocto Project Development
-      Tasks Manual for more information.
+   -  You may use version 2 of Windows Subsystem For Linux (WSL 2) to set
+      up a build host using Windows 10 or later, Windows Server 2019 or later.
+      See the :ref:`dev-manual/start:setting up to use windows subsystem for
+      linux (wsl 2)` section in the Yocto Project Development Tasks Manual
+      for more information.
 
 If you want more conceptual or background information on the Yocto
 Project, see the :doc:`/overview-manual/index`.
@@ -47,7 +40,13 @@ Compatible Linux Distribution
 Make sure your :term:`Build Host` meets the
 following requirements:
 
--  50 Gbytes of free disk space
+-  At least &MIN_DISK_SPACE; Gbytes of free disk space, though
+   much more will help to run multiple builds and increase
+   performance by reusing build artifacts.
+
+-  At least &MIN_RAM; Gbytes of RAM, though a modern build host with as
+   much RAM and as many CPU cores as possible is strongly recommended to
+   maximize build performance.
 
 -  Runs a supported Linux distribution (i.e. recent releases of Fedora,
    openSUSE, CentOS, Debian, or Ubuntu). For a list of Linux
@@ -58,7 +57,7 @@ following requirements:
    :ref:`dev-manual/start:preparing the build host`
    section in the Yocto Project Development Tasks Manual.
 
--
+-  Ensure that the following utilities have these minimum version numbers:
 
    -  Git &MIN_GIT_VERSION; or greater
    -  tar &MIN_TAR_VERSION; or greater
@@ -66,10 +65,10 @@ following requirements:
    -  gcc &MIN_GCC_VERSION; or greater.
    -  GNU make &MIN_MAKE_VERSION; or greater
 
-If your build host does not meet any of these three listed version
+If your build host does not satisfy all of the above 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 and gcc versions`
+:ref:`ref-manual/system-requirements:required git, tar, python, make and gcc versions`
 section in the Yocto Project Reference Manual for information.
 
 Build Host Packages
@@ -77,11 +76,9 @@ Build Host Packages
 
 You must install essential host packages on your build host. The
 following command installs the host packages based on an Ubuntu
-distribution:
+distribution::
 
-.. code-block:: shell
-
-  $ sudo apt install &UBUNTU_HOST_PACKAGES_ESSENTIAL;
+   $ sudo apt install &UBUNTU_DEBIAN_HOST_PACKAGES_ESSENTIAL;
 
 .. note::
 
@@ -185,7 +182,7 @@ an entire Linux distribution, including the toolchain, from source.
       page of the Yocto Project Wiki.
 
 #. **Initialize the Build Environment:** From within the ``poky``
-   directory, run the :ref:`ref-manual/structure:\`\`oe-init-build-env\`\``
+   directory, run the :ref:`ref-manual/structure:``oe-init-build-env```
    environment
    setup script to define Yocto Project's build environment on your
    build host.
@@ -254,10 +251,10 @@ an entire Linux distribution, including the toolchain, from source.
       To use such mirrors, uncomment the below lines in your ``conf/local.conf``
       file in the :term:`Build Directory`::
 
-         BB_SIGNATURE_HANDLER = "OEEquivHash"
+         BB_HASHSERVE_UPSTREAM = "hashserv.yoctoproject.org:8686"
+         SSTATE_MIRRORS ?= "file://.* http://sstate.yoctoproject.org/all/PATH;downloadfilename=PATH"
          BB_HASHSERVE = "auto"
-         BB_HASHSERVE_UPSTREAM = "hashserv.yocto.io:8687"
-         SSTATE_MIRRORS ?= "file://.* http://cdn.jsdelivr.net/yocto/sstate/all/PATH;downloadfilename=PATH"
+         BB_SIGNATURE_HANDLER = "OEEquivHash"
 
 #. **Start the Build:** Continue with the following command to build an OS
    image for the target, which is ``core-image-sato`` in this example:

documentation/bsp-guide/bsp.rst

@@ -1,8 +1,8 @@
 .. SPDX-License-Identifier: CC-BY-SA-2.0-UK
 
-************************************************
-Board Support Packages (BSP) - Developer's Guide
-************************************************
+**************************************************
+Board Support Packages (BSP) --- Developer's Guide
+**************************************************
 
 A Board Support Package (BSP) is a collection of information that
 defines how to support a particular hardware device, set of devices, or
@@ -81,7 +81,7 @@ directory of that Layer. This directory is what you add to the
 ``conf/bblayers.conf`` file found in your
 :term:`Build Directory`, which is
 established after you run the OpenEmbedded build environment setup
-script (i.e. :ref:`ref-manual/structure:\`\`oe-init-build-env\`\``).
+script (i.e. :ref:`ref-manual/structure:``oe-init-build-env```).
 Adding the root directory allows the :term:`OpenEmbedded Build System`
 to recognize the BSP
 layer and from it build an image. Here is an example::
@@ -167,7 +167,7 @@ section.
    BSPs, which are maintained in their own layers or in layers designed
    to contain several BSPs. To get an idea of machine support through
    BSP layers, you can look at the
-   :yocto_dl:`index of machines </releases/yocto/yocto-&DISTRO;/machines>`
+   :yocto_dl:`index of machines </releases/yocto/&DISTRO_REL_LATEST_TAG;/machines>`
    for the release.
 
 #. *Optionally Clone the meta-intel BSP Layer:* If your hardware is
@@ -230,7 +230,7 @@ section.
 
 #. *Initialize the Build Environment:* While in the root directory of
    the Source Directory (i.e. ``poky``), run the
-   :ref:`ref-manual/structure:\`\`oe-init-build-env\`\`` environment
+   :ref:`ref-manual/structure:``oe-init-build-env``` environment
    setup script to define the OpenEmbedded build environment on your
    build host. ::
 
@@ -675,21 +675,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.
 
@@ -699,14 +699,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)
 ========================================
@@ -853,8 +858,7 @@ Before looking at BSP requirements, you should consider the following:
    dictating that a specific kernel or kernel version be used in a given
    BSP.
 
-Following are the requirements for a released BSP that conform to the
-Yocto Project:
+The requirements for a released BSP that conform to the Yocto Project are:
 
 -  *Layer Name:* The BSP must have a layer name that follows the Yocto
    Project standards. For information on BSP layer names, see the
@@ -958,7 +962,7 @@ Yocto Project:
 Released BSP Recommendations
 ----------------------------
 
-Following are recommendations for released BSPs that conform to the
+Here are recommendations for released BSPs that conform to the
 Yocto Project:
 
 -  *Bootable Images:* Released BSPs can contain one or more bootable
@@ -1020,7 +1024,7 @@ the following:
    that additional hierarchy and the files would obviously not be able
    to reside in a machine-specific directory.
 
-Following is a specific example to help you better understand the
+Here is a specific example to help you better understand the
 process. This example customizes a recipe by adding a
 BSP-specific configuration file named ``interfaces`` to the
 ``init-ifupdown_1.0.bb`` recipe for machine "xyz" where the BSP layer
@@ -1180,7 +1184,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
@@ -1443,7 +1447,7 @@ metadata used to build the kernel. In this case, a kernel append file
 kernel recipe (i.e. ``linux-yocto_5.15.bb``), which is located in
 :yocto_git:`/poky/tree/meta-yocto-bsp/recipes-kernel/linux`.
 
-Following is the contents of the append file::
+The contents of the append file are::
 
    KBRANCH:genericx86  = "v5.15/standard/base"
    KBRANCH:genericx86-64  = "v5.15/standard/base"

documentation/conf.py

@@ -13,6 +13,7 @@
 # documentation root, use os.path.abspath to make it absolute, like shown here.
 #
 import os
+import re
 import sys
 import datetime
 try:
@@ -90,8 +91,9 @@ rst_prolog = """
 
 # external links and substitutions
 extlinks = {
-    'cve': ('https://nvd.nist.gov/vuln/detail/CVE-%s', 'CVE-%s'),
+    'bitbake_git': ('https://git.openembedded.org/bitbake%s', None),
     'cve_mitre': ('https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-%s', 'CVE-%s'),
+    'cve_nist': ('https://nvd.nist.gov/vuln/detail/CVE-%s', 'CVE-%s'),
     'yocto_home': ('https://www.yoctoproject.org%s', None),
     'yocto_wiki': ('https://wiki.yoctoproject.org/wiki%s', None),
     'yocto_dl': ('https://downloads.yoctoproject.org%s', None),
@@ -135,6 +137,7 @@ except ImportError:
     sys.exit(1)
 
 html_logo = 'sphinx-static/YoctoProject_Logo_RGB.jpg'
+html_favicon = 'sphinx-static/favicon.ico'
 
 # Add any paths that contain custom static files (such as style sheets) here,
 # relative to this directory. They are copied after the builtin static files,
@@ -159,10 +162,28 @@ html_last_updated_fmt = '%b %d, %Y'
 html_secnumber_suffix = " "
 
 latex_elements = {
-    'passoptionstopackages': '\PassOptionsToPackage{bookmarksdepth=5}{hyperref}',
-    'preamble': '\setcounter{tocdepth}{2}',
+    'passoptionstopackages': '\\PassOptionsToPackage{bookmarksdepth=5}{hyperref}',
+    'preamble': '\\setcounter{tocdepth}{2}',
 }
 
+
+from sphinx.search import SearchEnglish
+from sphinx.search import languages
+class DashFriendlySearchEnglish(SearchEnglish):
+
+    # Accept words that can include 'inner' hyphens or dots
+    _word_re = re.compile(r'[\w]+(?:[\.\-][\w]+)*')
+
+    js_splitter_code = r"""
+function splitQuery(query) {
+    return query
+        .split(/[^\p{Letter}\p{Number}_\p{Emoji_Presentation}\-\.]+/gu)
+        .filter(term => term.length > 0);
+}
+"""
+
+languages['en'] = DashFriendlySearchEnglish
+
 # Make the EPUB builder prefer PNG to SVG because of issues rendering Inkscape SVG
 from sphinx.builders.epub3 import Epub3Builder
 Epub3Builder.supported_image_types = ['image/png', 'image/gif', 'image/jpeg']

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

@@ -221,6 +221,20 @@ Recipes need to define both the :term:`LICENSE` and
    ``meta/files/common-licenses/`` or the :term:`SPDXLICENSEMAP` flag names
    defined in ``meta/conf/licenses.conf``.
 
+   .. note::
+
+      Setting a :term:`LICENSE` in a recipe applies to the software to be built
+      by this recipe, not to the recipe file itself. The license of recipes,
+      configuration files and scripts should also be clearly specified, for
+      example via comments or via a license found in the :term:`layer` that
+      holds these files. These license files are usually found at the root of
+      the layer. Exceptions should be clearly stated in the layer README or
+      LICENSE file.
+
+      For example, the :term:`OpenEmbedded-Core (OE-Core)` layer provides both
+      the GPL-2.0-only and MIT license files, and a "LICENSE" file to explain
+      how these two licenses are attributed to files found in the layer.
+
 -  :term:`LIC_FILES_CHKSUM`: The OpenEmbedded build system uses this
    variable to make sure the license text has not changed. If it has,
    the build produces an error and it affords you the chance to figure
@@ -250,6 +264,18 @@ Recipes need to define both the :term:`LICENSE` and
    correct string that you can substitute into the recipe file for a
    subsequent build.
 
+License Updates
+~~~~~~~~~~~~~~~
+
+When you change the :term:`LICENSE` or :term:`LIC_FILES_CHKSUM` in the recipe
+you need to briefly explain the reason for the change via a ``License-Update:``
+tag.  Often it's quite trivial, such as::
+
+    License-Update: copyright years refreshed
+
+Less often, the actual licensing terms themselves will have changed.  If so, do
+try to link to upstream making/justifying that decision.
+
 Tips and Guidelines for Writing Recipes
 ---------------------------------------
 
@@ -383,7 +409,7 @@ one CVE is fixed, separate them using spaces.
 CVE Examples
 ------------
 
-This should be the header of patch that fixes :cve:`2015-8370` in GRUB2::
+This should be the header of patch that fixes :cve_nist:`2015-8370` in GRUB2::
 
    grub2: Fix CVE-2015-8370
 

documentation/contributor-guide/submit-changes.rst

@@ -57,7 +57,7 @@ Set up Git
 The first thing to do is to install Git packages. Here is an example
 on Debian and Ubuntu::
 
-   sudo aptitude install git-core git-email
+   sudo apt install git-core git-email
 
 Then, you need to set a name and e-mail address that Git will
 use to identify your commits::
@@ -65,6 +65,13 @@ use to identify your commits::
    git config --global user.name "Ada Lovelace"
    git config --global user.email "ada.lovelace@gmail.com"
 
+By default, Git adds a signature line at the end of patches containing the Git
+version. We suggest to remove it as it doesn't add useful information.
+
+Remove it with the following command::
+
+   git config --global format.signature ""
+
 Clone the Git repository for the component to modify
 ----------------------------------------------------
 
@@ -116,110 +123,148 @@ to add the upgraded version.
 
       $ git commit -s file1 file2 dir1 dir2 ...
 
-   To include **a**\ ll staged files::
+   To include all staged files::
 
       $ git commit -sa
 
-   -  The ``-s`` option of ``git commit`` adds a "Signed-off-by:" line
-      to your commit message. There is the same requirement for contributing
-      to the Linux kernel. Adding such a line signifies that you, the
-      submitter, have agreed to the `Developer's Certificate of Origin 1.1
-      <https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin>`__
-      as follows:
+   #.  The ``-s`` option of ``git commit`` adds a "Signed-off-by:" line
+       to your commit message. There is the same requirement for contributing
+       to the Linux kernel. Adding such a line signifies that you, the
+       submitter, have agreed to the `Developer's Certificate of Origin 1.1
+       <https://www.kernel.org/doc/html/latest/process/submitting-patches.html#sign-your-work-the-developer-s-certificate-of-origin>`__
+       as follows:
 
-      .. code-block:: none
+       .. code-block:: none
 
-         Developer's Certificate of Origin 1.1
+          Developer's Certificate of Origin 1.1
 
-         By making a contribution to this project, I certify that:
+          By making a contribution to this project, I certify that:
 
-         (a) The contribution was created in whole or in part by me and I
-             have the right to submit it under the open source license
-             indicated in the file; or
+          (a) The contribution was created in whole or in part by me and I
+              have the right to submit it under the open source license
+              indicated in the file; or
 
-         (b) The contribution is based upon previous work that, to the best
-             of my knowledge, is covered under an appropriate open source
-             license and I have the right under that license to submit that
-             work with modifications, whether created in whole or in part
-             by me, under the same open source license (unless I am
-             permitted to submit under a different license), as indicated
-             in the file; or
+          (b) The contribution is based upon previous work that, to the best
+              of my knowledge, is covered under an appropriate open source
+              license and I have the right under that license to submit that
+              work with modifications, whether created in whole or in part
+              by me, under the same open source license (unless I am
+              permitted to submit under a different license), as indicated
+              in the file; or
 
-         (c) The contribution was provided directly to me by some other
-             person who certified (a), (b) or (c) and I have not modified
-             it.
+          (c) The contribution was provided directly to me by some other
+              person who certified (a), (b) or (c) and I have not modified
+              it.
 
-         (d) I understand and agree that this project and the contribution
-             are public and that a record of the contribution (including all
-             personal information I submit with it, including my sign-off) is
-             maintained indefinitely and may be redistributed consistent with
-             this project or the open source license(s) involved.
+          (d) I understand and agree that this project and the contribution
+              are public and that a record of the contribution (including all
+              personal information I submit with it, including my sign-off) is
+              maintained indefinitely and may be redistributed consistent with
+              this project or the open source license(s) involved.
 
-   -  Provide a single-line summary of the change and, if more
-      explanation is needed, provide more detail in the body of the
-      commit. This summary is typically viewable in the "shortlist" of
-      changes. Thus, providing something short and descriptive that
-      gives the reader a summary of the change is useful when viewing a
-      list of many commits. You should prefix this short description
-      with the recipe name (if changing a recipe), or else with the
-      short form path to the file being changed.
+   #.  Provide a single-line summary of the change and, if more
+       explanation is needed, provide more detail in the description of the
+       commit. This summary is typically viewable in the "shortlist" of
+       changes. Thus, providing something short and descriptive that
+       gives the reader a summary of the change is useful when viewing a
+       list of many commits. You should prefix this short description
+       with the recipe name (if changing a recipe), or else with the
+       short form path to the file being changed.
+
+       .. note::
+
+          To find a suitable prefix for the commit summary, a good idea
+          is to look for prefixes used in previous commits touching the
+          same files or directories::
+
+             git log --oneline <paths>
+
+   #.  For the commit description, provide detailed information
+       that describes what you changed, why you made the change, and the
+       approach you used. It might also be helpful if you mention how you
+       tested the change. Provide as much detail as you can in the commit
+       description.
+
+       .. note::
+
+          If the single line summary is enough to describe a simple
+          change, the commit description can be left empty.
+
+   #.  If the change addresses a specific bug or issue that is associated
+       with a bug-tracking ID, include a reference to that ID in the body of the
+       commit message. For example, the Yocto Project uses a
+       specific convention for bug references --- any commit that addresses
+       a specific bug should use the following form for the body of the commit
+       message. Be sure to use the actual bug-tracking ID from
+       Bugzilla for bug-id::
+
+          single-line summary of change
+
+          Fixes [YOCTO #bug-id]
+
+          detailed description of change
+
+   #. If other people participated in this patch, add some tags to the commit
+      description to credit other contributors to the change:
+
+      -  ``Reported-by``: name and email of a person reporting a bug
+         that your commit is trying to fix. This is a good practice
+         to encourage people to go on reporting bugs and let them
+         know that their reports are taken into account.
+
+      -  ``Suggested-by``: name and email of a person to credit for the
+         idea of making the change.
+
+      -  ``Tested-by``, ``Reviewed-by``: name and email for people having
+         tested your changes or reviewed their code. These fields are
+         usually added by the maintainer accepting a patch, or by
+         yourself if you submitted your patches to early reviewers,
+         or are submitting an unmodified patch again as part of a
+         new iteration of your patch series.
+
+      -  ``Cc``: name and email of people you want to send a copy
+         of your changes to. This field will be used by ``git send-email``.
+
+      See `more guidance about using such tags
+      <https://www.kernel.org/doc/html/latest/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes>`__
+      in the Linux kernel documentation.
 
       .. note::
 
-         To find a suitable prefix for the commit summary, a good idea
-         is to look for prefixes used in previous commits touching the
-         same files or directories::
+         One can amend an existing git commit message to add missing tags for
+         contributors with the ``git commit --amend`` command.
 
-            git log --oneline <paths>
+Test your changes
+-----------------
 
-   -  For the body of the commit message, provide detailed information
-      that describes what you changed, why you made the change, and the
-      approach you used. It might also be helpful if you mention how you
-      tested the change. Provide as much detail as you can in the body
-      of the commit message.
+For each contributions you make, you should test your changes as well.
+For this the Yocto Project offers several types of tests. Those tests cover
+different areas and it depends on your changes which are feasible. For example run:
 
-      .. note::
+   -  For changes that affect the build environment:
 
-         If the single line summary is enough to describe a simple
-         change, the body of the commit message can be left empty.
+      -  ``bitbake-selftest``: for changes within BitBake
 
-   -  If the change addresses a specific bug or issue that is associated
-      with a bug-tracking ID, include a reference to that ID in your
-      detailed description. For example, the Yocto Project uses a
-      specific convention for bug references --- any commit that addresses
-      a specific bug should use the following form for the detailed
-      description. Be sure to use the actual bug-tracking ID from
-      Bugzilla for bug-id::
+      -  ``oe-selftest``: to test combinations of BitBake runs
 
-         Fixes [YOCTO #bug-id]
+      -  ``oe-build-perf-test``: to test the performance of common build scenarios
 
-         detailed description of change
+   -  For changes in a recipe:
 
-#. *Crediting contributors:* By using the ``git commit --amend`` command,
-   you can add some tags to the commit description to credit other contributors
-   to the change:
+      - ``ptest``: run package specific tests, if they exist
 
-   -  ``Reported-by``: name and email of a person reporting a bug
-      that your commit is trying to fix. This is a good practice
-      to encourage people to go on reporting bugs and let them
-      know that their reports are taken into account.
+      - ``testimage``: build an image, boot it and run testcases on it
 
-   -  ``Suggested-by``: name and email of a person to credit for the
-      idea of making the change.
+      - If applicable, ensure also the ``native`` and ``nativesdk`` variants builds
 
-   -  ``Tested-by``, ``Reviewed-by``: name and email for people having
-      tested your changes or reviewed their code. These fields are
-      usually added by the maintainer accepting a patch, or by
-      yourself if you submitted your patches to early reviewers,
-      or are submitting an unmodified patch again as part of a
-      new iteration of your patch series.
+   -  For changes relating to the SDK:
 
-   -  ``CC:`` Name and email of people you want to send a copy
-      of your changes to. This field will be used by ``git send-email``.
+      - ``testsdk``: to build, install and run tests against a SDK
 
-   See `more guidance about using such tags
-   <https://www.kernel.org/doc/html/latest/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes>`__
-   in the Linux kernel documentation.
+      - ``testsdk_ext``: to build, install and run tests against an extended SDK
+
+Note that this list just gives suggestions and is not exhaustive. More details can
+be found here: :ref:`test-manual/intro:Yocto Project Tests --- Types of Testing Overview`.
 
 Creating Patches
 ================
@@ -359,7 +404,7 @@ varies by component:
    :oe_lists:`bitbake-devel </g/bitbake-devel>`
    mailing list.
 
--  *"meta-\*" trees:* These trees contain Metadata. Use the
+-  *meta-poky* and *meta-yocto-bsp* trees: These trees contain Metadata. Use the
    :yocto_lists:`poky </g/poky>` mailing list.
 
 -  *Documentation*: For changes to the Yocto Project documentation, use the
@@ -367,7 +412,7 @@ varies by component:
 
 For changes to other layers and tools hosted in the Yocto Project source
 repositories (i.e. :yocto_git:`git.yoctoproject.org <>`), use the
-:yocto_lists:`yocto </g/yocto/>` general mailing list.
+:yocto_lists:`yocto-patches </g/yocto-patches/>` general mailing list.
 
 For changes to other layers hosted in the OpenEmbedded source
 repositories (i.e. :oe_git:`git.openembedded.org <>`), use
@@ -398,7 +443,7 @@ their e-mail clients will default to including your email address in the
 conversation anyway.
 
 Anyway, you'll also be able to access the new messages on mailing list archives,
-either through a web browser, or for the lists archived on https://lore.kernelorg,
+either through a web browser, or for the lists archived on https://lore.kernel.org,
 through an individual newsgroup feed or a git repository.
 
 Sending Patches via Email
@@ -410,7 +455,7 @@ typical usage of ``git send-email``::
    git send-email --to <mailing-list-address> *.patch
 
 Then, review each subject line and list of recipients carefully, and then
-and then allow the command to send each message.
+allow the command to send each message.
 
 You will see that ``git send-email`` will automatically copy the people listed
 in any commit tags such as ``Signed-off-by`` or ``Reported-by``.
@@ -420,7 +465,7 @@ or any layer other than :oe_git:`openembedded-core </openembedded-core/>`,
 please add the appropriate prefix so that it is clear which layer the patch is intended
 to be applied to::
 
-   git send-email --subject-prefix="meta-oe][PATCH" ...
+   git format-patch --subject-prefix="meta-oe][PATCH" ...
 
 .. note::
 
@@ -611,8 +656,8 @@ backported to a stable branch unless the bug in question does not affect the
 master branch or the fix on the master branch is unsuitable for backporting.
 
 The list of stable branches along with the status and maintainer for each
-branch can be obtained from the
-:yocto_wiki:`Releases wiki page </Releases>`.
+branch can be obtained from the :yocto_home:`Releases </development/releases/>`
+page.
 
 .. note::
 
@@ -696,6 +741,38 @@ argument to ``git format-patch`` with a version number::
 
    git format-patch -v2 <ref-branch>
 
+
+After generating updated patches (v2, v3, and so on) via ``git
+format-patch``, ideally developers will add a patch version changelog
+to each patch that describes what has changed between each revision of
+the patch. Add patch version changelogs after the ``---`` marker in the
+patch, indicating that this information is part of this patch, but is not
+suitable for inclusion in the commit message (i.e. the git history) itself.
+Providing a patch version changelog makes it easier for maintainers and
+reviewers to succinctly understand what changed in all versions of the
+patch, without having to consult alternate sources of information, such as
+searching through messages on a mailing list. For example::
+
+   <patch title>
+
+   <commit message>
+
+   <Signed-off-by/other trailers>
+   ---
+   changes in v4:
+   - provide a clearer commit message
+   - fix spelling mistakes
+
+   changes in v3:
+   - replace func() to use other_func() instead
+
+   changes in v2:
+   - this patch was added in v2
+   ---
+   <diffstat output>
+
+   <unified diff>
+
 Lastly please ensure that you also test your revised changes. In particular
 please don't just edit the patch file written out by ``git format-patch`` and
 resend it.
@@ -752,3 +829,52 @@ Other layers may have similar testing branches but there is no formal
 requirement or standard for these so please check the documentation for the
 layers you are contributing to.
 
+Acceptance of AI Generated Code
+===============================
+
+The Yocto Project and OpenEmbedded follow the guidance of the Linux Foundation
+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
+additional requirements to the items in section
+:ref:`contributor-guide/submit-changes:Implement and commit changes`.
+
+All AI Generated Code must be labeled as such in the commit message,
+prior to your ``Signed-off-by`` line. It is also strongly recommended,
+that any patches or code within the commit also have a comment or other
+indication that this code was AI generated.
+
+For example, here is a properly formatted commit message::
+
+   component: Add the ability to ...
+
+   AI-Generated: Uses GitHub Copilot
+
+   Signed-off-by: Your Name <your.name@domain>
+
+The ``Signed-off-by`` line must be written by you, and not the AI helper.
+As a reminder, when contributing a change, your ``Signed-off-by`` line is
+required and the stipulations in the `Developer's Statement of Origin
+1.1 <https://developercertificate.org/>`__ still apply.
+
+Additionally, you must stipulate AI contributions conform to the Linux
+Foundation policy, specifically:
+
+#. Contributors should ensure that the terms and conditions of the generative AI
+   tool do not place any contractual restrictions on how the tool's output can
+   be used that are inconsistent with the project's open source software
+   license, the project's intellectual property policies, or the Open Source
+   Definition.
+
+#. If any pre-existing copyrighted materials (including pre-existing open
+   source code) authored or owned by third parties are included in the AI tool's
+   output, prior to contributing such output to the project, the Contributor
+   should confirm that they have permission from the third party
+   owners -- such as the form of an open source license or public domain
+   declaration that complies with the project's licensing policies -- to use and
+   modify such pre-existing materials and contribute them to the project.
+   Additionally, the contributor should provide notice and attribution of such
+   third party rights, along with information about the applicable license
+   terms, with their contribution.

documentation/dev-manual/building.rst

@@ -32,6 +32,10 @@ build host running Linux.
       OpenEmbedded build system, see the
       :doc:`/brief-yoctoprojectqs/index` document.
 
+   -  You can also use the `Yocto Project BitBake
+      <https://marketplace.visualstudio.com/items?itemName=yocto-project.yocto-bitbake>`__
+      extension for Visual Studio Code to build images.
+
 The build process creates an entire Linux distribution from source and
 places it in your :term:`Build Directory` under ``tmp/deploy/images``. For
 detailed information on the build process using BitBake, see the
@@ -156,7 +160,7 @@ Follow these steps to set up and execute multiple configuration builds:
    The location for these multiconfig configuration files is specific.
    They must reside in the current :term:`Build Directory` in a sub-directory of
    ``conf`` named ``multiconfig`` or within a layer's ``conf`` directory
-   under a directory named ``multiconfig``. Following is an example that defines
+   under a directory named ``multiconfig``. Here is an example that defines
    two configuration files for the "x86" and "arm" multiconfigs:
 
    .. image:: figures/multiconfig_files.png
@@ -276,7 +280,9 @@ Follow these steps to create an :term:`Initramfs` image:
 #. *Create the Initramfs Image Recipe:* You can reference the
    ``core-image-minimal-initramfs.bb`` recipe found in the
    ``meta/recipes-core`` directory of the :term:`Source Directory`
-   as an example from which to work.
+   as an example from which to work. The ``core-image-minimal-initramfs`` recipe
+   is based on the :ref:`initramfs-framework <dev-manual/building:Customizing an
+   Initramfs using \`\`initramfs-framework\`\`>` recipe described below.
 
 #. *Decide if You Need to Bundle the Initramfs Image Into the Kernel
    Image:* If you want the :term:`Initramfs` image that is built to be bundled
@@ -304,6 +310,86 @@ Follow these steps to create an :term:`Initramfs` image:
    and bundled with the kernel image if you used the
    :term:`INITRAMFS_IMAGE_BUNDLE` variable described earlier.
 
+Customizing an Initramfs using ``initramfs-framework``
+------------------------------------------------------
+
+The ``core-image-minimal-initramfs.bb`` recipe found in
+:oe_git:`meta/recipes-core/images
+</openembedded-core/tree/meta/recipes-core/images>` uses the
+:oe_git:`initramfs-framework_1.0.bb
+</openembedded-core/tree/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb>`
+recipe as its base component. The goal of the ``initramfs-framework`` recipe is
+to provide the building blocks to build a customized :term:`Initramfs`.
+
+The ``initramfs-framework`` recipe relies on shell initialization scripts
+defined in :oe_git:`meta/recipes-core/initrdscripts/initramfs-framework
+</openembedded-core/tree/meta/recipes-core/initrdscripts/initramfs-framework>`. Since some of
+these scripts do not apply for all use cases, the ``initramfs-framework`` recipe
+defines different packages:
+
+-  ``initramfs-framework-base``: this package installs the basic components of
+   an :term:`Initramfs`, such as the ``init`` script or the ``/dev/console``
+   character special file. As this package is a runtime dependency of all
+   modules listed below, it is automatically pulled in when one of the modules
+   is installed in the image.
+-  ``initramfs-module-exec``: support for execution of applications.
+-  ``initramfs-module-mdev``: support for `mdev
+   <https://wiki.gentoo.org/wiki/Mdev>`__.
+-  ``initramfs-module-udev``: support for :wikipedia:`Udev <Udev>`.
+-  ``initramfs-module-e2fs``: support for :wikipedia:`ext4/ext3/ext2
+   <Extended_file_system>` filesystems.
+-  ``initramfs-module-nfsrootfs``: support for locating and mounting the root
+   partition via :wikipedia:`NFS <Network_File_System>`.
+-  ``initramfs-module-rootfs``: support for locating and mounting the root
+   partition.
+-  ``initramfs-module-debug``: dynamic debug support.
+-  ``initramfs-module-lvm``: :wikipedia:`LVM <Logical_volume_management>` rootfs support.
+-  ``initramfs-module-overlayroot``: support for mounting a read-write overlay
+   on top of a read-only root filesystem.
+
+In addition to the packages defined by the ``initramfs-framework`` recipe
+itself, the following packages are defined by the recipes present in
+:oe_git:`meta/recipes-core/initrdscripts </openembedded-core/tree/meta/recipes-core/initrdscripts>`:
+
+-  ``initramfs-module-install``: module to create and install a partition layout
+   on a selected block device.
+-  ``initramfs-module-install-efi``: module to create and install an EFI
+   partition layout on a selected block device.
+-  ``initramfs-module-setup-live``: module to start a shell in the
+   :term:`Initramfs` if ``root=/dev/ram0`` in passed in the `Kernel command-line
+   <https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html>`__
+   or the ``root=`` parameter was not passed.
+
+To customize the :term:`Initramfs`, you can add or remove packages listed
+earlier from the :term:`PACKAGE_INSTALL` variable with a :ref:`bbappend
+<dev-manual/layers:Appending Other Layers Metadata With Your Layer>` on the
+``core-image-minimal-initramfs`` recipe, or create a custom recipe for the
+:term:`Initramfs` taking ``core-image-minimal-initramfs`` as example.
+
+Custom scripts can be added to the :term:`Initramfs` by writing your own
+recipes. The recipes are conventionally named ``initramfs-module-<module name>``
+where ``<module name>`` is the name of the module. The recipe should set its
+:term:`RDEPENDS` package-specific variables to include
+``initramfs-framework-base`` and the other packages on which the module depends
+at runtime.
+
+The recipe must install shell initialization scripts in :term:`${D} <D>`\
+``/init.d`` and must follow the ``<number>-<script name>`` naming scheme where:
+
+-  ``<number>`` is a *two-digit* number that affects the execution order of the
+   script compared to others. For example, the script ``80-setup-live`` would be
+   executed after ``01-udev`` because 80 is greater than 01.
+
+   This number being two-digits is important here as the scripts are executed
+   alphabetically. For example, the script ``10-script`` would be executed
+   before the script ``8-script``, because ``1`` is inferior to ``8``.
+   Therefore, the script should be named ``08-script``.
+
+-  ``<script name>`` is the script name which you can choose freely.
+
+   If two script use the same ``<number>``, they are sorted alphabetically based
+   on ``<script name>``.
+
 Bundling an Initramfs Image From a Separate Multiconfig
 -------------------------------------------------------
 
@@ -771,10 +857,9 @@ your tunings to best consider build times and package feed maintenance.
       in the script for information on how to use the tool.
 
    -  *BitBake's "-S printdiff" Option:* Using this option causes
-      BitBake to try to establish the closest signature match it can
-      (e.g. in the shared state cache) and then run ``bitbake-diffsigs``
-      over the matches to determine the stamps and delta where these two
-      stamp trees diverge.
+      BitBake to try to establish the most recent signature match
+      (e.g. in the shared state cache) and then compare matched signatures
+      to determine the stamps and delta where these two stamp trees diverge.
 
 Building Software from an External Source
 =========================================
@@ -824,6 +909,11 @@ to point to that directory::
 
    EXTERNALSRC_BUILD:pn-myrecipe = "path-to-your-source-tree"
 
+.. note::
+
+   The values of :term:`EXTERNALSRC` and :term:`EXTERNALSRC_BUILD`
+   must be absolute paths.
+
 Replicating a Build Offline
 ===========================
 

documentation/dev-manual/custom-distribution.rst

@@ -4,10 +4,16 @@ Creating Your Own Distribution
 ******************************
 
 When you build an image using the Yocto Project and do not alter any
-distribution :term:`Metadata`, you are
-creating a Poky distribution. If you wish to gain more control over
-package alternative selections, compile-time options, and other
-low-level configurations, you can create your own distribution.
+distribution :term:`Metadata`, you are using the Poky distribution.
+Poky is explicitly a *reference* distribution for testing and
+development purposes. It enables most hardware and software features
+so that they can be tested, but this also means that from a security
+point of view the attack surface is very large. Additionally, at some
+point it is likely that you will want to gain more control over package
+alternative selections, compile-time options, and other low-level
+configurations. For both of these reasons, if you are using the Yocto
+Project for production use then you are strongly encouraged to create
+your own distribution.
 
 To create your own distribution, the basic steps consist of creating
 your own distribution layer, creating your own distribution
@@ -107,3 +113,23 @@ layer. The following steps provide some more detail:
    For information on append files, see the
    ":ref:`dev-manual/layers:appending other layers metadata with your layer`"
    section.
+
+Copying and modifying the Poky distribution
+===========================================
+
+Instead of creating a custom distribution from scratch as per above, you may
+wish to start your custom distribution configuration by copying the Poky
+distribution provided within the ``meta-poky`` layer and then modifying it.
+This is fine, however if you do this you should keep the following in mind:
+
+-  Every reference to Poky needs to be updated in your copy so that it
+   will still apply. This includes override usage within files (e.g. ``:poky``)
+   and in directory names. This is a good opportunity to evaluate each one of
+   these customizations to see if they are needed for your use case.
+
+-  Unless you also intend to use them, the ``poky-tiny``, ``poky-altcfg`` and
+   ``poky-bleeding`` variants and any references to them can be removed.
+
+-  More generally, the Poky distribution configuration enables a lot more
+   than you likely need for your production use case. You should evaluate *every*
+   configuration choice made in your copy to determine if it is needed.

documentation/dev-manual/customizing-images.rst

@@ -80,15 +80,14 @@ recipe that are enabled with :term:`IMAGE_FEATURES`. The value of
 :term:`EXTRA_IMAGE_FEATURES` is added to :term:`IMAGE_FEATURES` within
 ``meta/conf/bitbake.conf``.
 
-To illustrate how you can use these variables to modify your image,
-consider an example that selects the SSH server. The Yocto Project ships
-with two SSH servers you can use with your images: Dropbear and OpenSSH.
-Dropbear is a minimal SSH server appropriate for resource-constrained
-environments, while OpenSSH is a well-known standard SSH server
-implementation. By default, the ``core-image-sato`` image is configured
-to use Dropbear. The ``core-image-full-cmdline`` and ``core-image-lsb``
-images both include OpenSSH. The ``core-image-minimal`` image does not
-contain an SSH server.
+To illustrate how you can use these variables to modify your image, consider an
+example that selects the SSH server. The Yocto Project ships with two SSH
+servers you can use with your images: Dropbear and OpenSSH. Dropbear is a
+minimal SSH server appropriate for resource-constrained environments, while
+OpenSSH is a well-known standard SSH server implementation. By default, the
+``core-image-sato`` image is configured to use Dropbear. The
+``core-image-full-cmdline`` image includes OpenSSH. The ``core-image-minimal``
+image does not contain an SSH server.
 
 You can customize your image and change these defaults. Edit the
 :term:`IMAGE_FEATURES` variable in your recipe or use the

documentation/dev-manual/debugging.rst

@@ -36,7 +36,7 @@ section:
    use the BitBake ``-e`` option to examine variable values after a
    recipe has been parsed.
 
--  ":ref:`dev-manual/debugging:viewing package information with \`\`oe-pkgdata-util\`\``"
+-  ":ref:`dev-manual/debugging:viewing package information with ``oe-pkgdata-util```"
    describes how to use the ``oe-pkgdata-util`` utility to query
    :term:`PKGDATA_DIR` and
    display package-related information for built packages.
@@ -111,17 +111,17 @@ occurred in your project. Perhaps an attempt to :ref:`modify a variable
 <bitbake-user-manual/bitbake-user-manual-metadata:modifying existing
 variables>` did not work out as expected.
 
-BitBake's ``-e`` option is used to display variable values after
-parsing. The following command displays the variable values after the
-configuration files (i.e. ``local.conf``, ``bblayers.conf``,
+BitBake's ``bitbake-getvar`` command is used to display variable values after
+parsing. The following command displays the variable value for :term:`OVERRIDES`
+after the configuration files (i.e. ``local.conf``, ``bblayers.conf``,
 ``bitbake.conf`` and so forth) have been parsed::
 
-   $ bitbake -e
+   $ bitbake-getvar OVERRIDES
 
-The following command displays variable values after a specific recipe has
-been parsed. The variables include those from the configuration as well::
+The following command displays the value of :term:`PV` after a specific recipe
+has been parsed::
 
-   $ bitbake -e recipename
+   $ bitbake-getvar -r recipename PV
 
 .. note::
 
@@ -135,19 +135,25 @@ been parsed. The variables include those from the configuration as well::
    the recipe datastore, which means that variables set within one task
    will not be visible to other tasks.
 
-In the output of ``bitbake -e``, each variable is preceded by a
-description of how the variable got its value, including temporary
-values that were later overridden. This description also includes
-variable flags (varflags) set on the variable. The output can be very
+In the output of ``bitbake-getvar``, the line containing the value of the
+variable is preceded by a description of how the variable got its value,
+including temporary values that were later overridden. This description also
+includes variable flags (varflags) set on the variable. The output can be very
 helpful during debugging.
 
 Variables that are exported to the environment are preceded by
-``export`` in the output of ``bitbake -e``. See the following example::
+``export`` in the output of ``bitbake-getvar``. See the following example::
 
    export CC="i586-poky-linux-gcc -m32 -march=i586 --sysroot=/home/ulf/poky/build/tmp/sysroots/qemux86"
 
-In addition to variable values, the output of the ``bitbake -e`` and
-``bitbake -e`` recipe commands includes the following information:
+Shell functions and tasks can also be inspected with the same mechanism::
+
+   $ bitbake-getvar -r recipename do_install
+
+For Python functions and tasks, ``bitbake -e recipename`` can be used instead.
+
+Moreover, the output of the ``bitbake -e`` and ``bitbake -e`` recipe commands
+includes the following information:
 
 -  The output starts with a tree listing all configuration files and
    classes included globally, recursively listing the files they include
@@ -170,7 +176,7 @@ You can use the ``oe-pkgdata-util`` command-line utility to query
 various package-related information. When you use the utility, you must
 use it to view information on packages that have already been built.
 
-Following are a few of the available ``oe-pkgdata-util`` subcommands.
+Here are a few of the available ``oe-pkgdata-util`` subcommands.
 
 .. note::
 
@@ -327,7 +333,7 @@ BitBake has determined by doing the following:
    the task. This list also includes indirect dependencies from
    variables depending on other variables, recursively::
 
-      Task dependencies: ['PV', 'SRCREV', 'SRC_URI', 'SRC_URI[md5sum]', 'SRC_URI[sha256sum]', 'base_do_fetch']
+      Task dependencies: ['PV', 'SRCREV', 'SRC_URI', 'SRC_URI[sha256sum]', 'base_do_fetch']
 
    .. note::
 
@@ -339,7 +345,10 @@ BitBake has determined by doing the following:
    :term:`BB_BASEHASH_IGNORE_VARS`
    information.
 
-There is also a ``bitbake-diffsigs`` command for comparing two
+Debugging signature construction and unexpected task executions
+===============================================================
+
+There is a ``bitbake-diffsigs`` command for comparing two
 ``siginfo`` or ``sigdata`` files. This command can be helpful when
 trying to figure out what changed between two versions of a task. If you
 call ``bitbake-diffsigs`` with just one file, the command behaves like
@@ -356,8 +365,12 @@ BitBake command-line options::
 .. note::
 
    Two common values for `SIGNATURE_HANDLER` are "none" and "printdiff", which
-   dump only the signature or compare the dumped signature with the cached one,
-   respectively.
+   dump only the signature or compare the dumped signature with the most recent one,
+   respectively. "printdiff" will try to establish the most recent
+   signature match (e.g. in the sstate cache) and then
+   compare the matched signatures to determine the stamps and delta
+   where these two stamp trees diverge. This can be used to determine why
+   tasks need to be re-run in situations where that is not expected.
 
 Using BitBake with either of these options causes BitBake to dump out
 ``sigdata`` files in the ``stamps`` directory for every task it would
@@ -608,7 +621,7 @@ logs, keep in mind the goal is to have informative logs while keeping
 the console as "silent" as possible. Also, if you want status messages
 in the log, use the "debug" loglevel.
 
-Following is an example written in Python. The code handles logging for
+Here is an example written in Python. The code handles logging for
 a function that determines the number of tasks needed to be run. See the
 ":ref:`ref-tasks-listtasks`"
 section for additional information::
@@ -636,7 +649,7 @@ logs, you have the same goals --- informative with minimal console output.
 The syntax you use for recipes written in Bash is similar to that of
 recipes written in Python described in the previous section.
 
-Following is an example written in Bash. The code logs the progress of
+Here is an example written in Bash. The code logs the progress of
 the ``do_my_function`` function::
 
    do_my_function() {
@@ -1221,7 +1234,7 @@ Here are some other tips that you might find useful:
                "$@"
       }
 
-   Following are some usage examples::
+   Here are some usage examples::
 
       $ g FOO # Search recursively for "FOO"
       $ g -i foo # Search recursively for "foo", ignoring case

documentation/dev-manual/development-shell.rst

@@ -16,7 +16,7 @@ OpenEmbedded build system were executing them. Consequently, working
 this way can be helpful when debugging a build or preparing software to
 be used with the OpenEmbedded build system.
 
-Following is an example that uses ``devshell`` on a target named
+Here is an example that uses ``devshell`` on a target named
 ``matchbox-desktop``::
 
   $ bitbake matchbox-desktop -c devshell

documentation/dev-manual/device-manager.rst

@@ -60,10 +60,10 @@ kernel.
 All devices created by ``devtmpfs`` will be owned by ``root`` and have
 permissions ``0600``.
 
-To have more control over the device nodes, you can use a device manager
-like ``udev`` or ``busybox-mdev``. You choose the device manager by
-defining the ``VIRTUAL-RUNTIME_dev_manager`` variable in your machine or
-distro configuration file. Alternatively, you can set this variable in
+To have more control over the device nodes, you can use a device manager like
+``udev`` or ``busybox-mdev``. You choose the device manager by defining the
+:term:`VIRTUAL-RUNTIME_dev_manager <VIRTUAL-RUNTIME>` variable in your machine
+or distro configuration file. Alternatively, you can set this variable in
 your ``local.conf`` configuration file::
 
    VIRTUAL-RUNTIME_dev_manager = "udev"

documentation/dev-manual/index.rst

@@ -39,10 +39,8 @@ Yocto Project Development Tasks Manual
    external-scm
    read-only-rootfs
    build-quality
-   runtime-testing
    debugging
    licenses
-   security-subjects
    vulnerabilities
    sbom
    error-reporting-tool

documentation/dev-manual/init-manager.rst

@@ -121,7 +121,7 @@ increasing levels of complexity and functionality:
    :widths: 40 20 20 20
    :header-rows: 1
 
-   * - 
+   * -
      - BusyBox init
      - SysVinit
      - systemd

documentation/dev-manual/layers.rst

@@ -82,7 +82,7 @@ Follow these general steps to create your layer without using tools:
       LAYERVERSION_yoctobsp = "4"
       LAYERSERIES_COMPAT_yoctobsp = "dunfell"
 
-   Following is an explanation of the layer configuration file:
+   Here is an explanation of the layer configuration file:
 
    -  :term:`BBPATH`: Adds the layer's
       root directory to BitBake's search path. Through the use of the
@@ -123,10 +123,9 @@ Follow these general steps to create your layer without using tools:
       Lists all layers on which this layer depends (if any).
 
    -  :term:`LAYERSERIES_COMPAT`:
-      Lists the :yocto_wiki:`Yocto Project </Releases>`
-      releases for which the current version is compatible. This
-      variable is a good way to indicate if your particular layer is
-      current.
+      Lists the :yocto_home:`Yocto Project releases </development/releases/>`
+      for which the current version is compatible. This variable is a good
+      way to indicate if your particular layer is current.
 
 
    .. note::
@@ -191,7 +190,7 @@ following list:
 -  *Structure Your Layers:* Proper use of overrides within append files
    and placement of machine-specific files within your layer can ensure
    that a build is not using the wrong Metadata and negatively impacting
-   a build for a different machine. Following are some examples:
+   a build for a different machine. Here are some examples:
 
    -  *Modify Variables to Support a Different Machine:* Suppose you
       have a layer named ``meta-one`` that adds support for building
@@ -313,7 +312,7 @@ Logo for your layer and application. The process consists of two parts:
    successful compatibility registration.
 
 #. Completion of an application acceptance form, which you can find at
-   :yocto_home:`/webform/yocto-project-compatible-registration`.
+   :yocto_home:`/compatible-registration/`.
 
 To be granted permission to use the logo, you need to satisfy the
 following:
@@ -337,7 +336,7 @@ application, you can use the Yocto Project Compatibility Logo with your
 layer and the application that uses your layer.
 
 To access the form, use this link:
-:yocto_home:`/webform/yocto-project-compatible-registration`.
+:yocto_home:`/compatible-registration`.
 Follow the instructions on the form to complete your application.
 
 The application consists of the following sections:
@@ -501,19 +500,19 @@ the "meta" layer at ``meta/recipes-bsp/formfactor``::
    INHIBIT_DEFAULT_DEPS = "1"
 
    do_install() {
-	   # Install file only if it has contents
+           # Install file only if it has contents
            install -d ${D}${sysconfdir}/formfactor/
            install -m 0644 ${S}/config ${D}${sysconfdir}/formfactor/
-	   if [ -s "${S}/machconfig" ]; then
-	           install -m 0644 ${S}/machconfig ${D}${sysconfdir}/formfactor/
-	   fi
+           if [ -s "${S}/machconfig" ]; then
+                   install -m 0644 ${S}/machconfig ${D}${sysconfdir}/formfactor/
+           fi
    }
 
 In the main recipe, note the :term:`SRC_URI`
 variable, which tells the OpenEmbedded build system where to find files
 during the build.
 
-Following is the append file, which is named ``formfactor_0.0.bbappend``
+Here is the append file, which is named ``formfactor_0.0.bbappend``
 and is from the Raspberry Pi BSP Layer named ``meta-raspberrypi``. The
 file is in the layer at ``recipes-bsp/formfactor``::
 
@@ -582,13 +581,13 @@ 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
-		install -d ${D}/${sysconfdir}/X11
-		install -m 0644 ${WORKDIR}/xorg.conf ${D}/${sysconfdir}/X11/
-	fi
+        if test -s ${WORKDIR}/xorg.conf; then
+                install -d ${D}/${sysconfdir}/X11
+                install -m 0644 ${WORKDIR}/xorg.conf ${D}/${sysconfdir}/X11/
+        fi
    }
 
-Following is the append file, which is named ``xserver-xf86-config_%.bbappend``
+Here is the append file, which is named ``xserver-xf86-config_%.bbappend``
 and is from the Raspberry Pi BSP Layer named ``meta-raspberrypi``. The
 file is in the layer at ``recipes-graphics/xorg-xserver``::
 
@@ -644,6 +643,96 @@ variable and append the layer's root name::
    order of ``.conf`` or ``.bbclass`` files. Future versions of BitBake
    might address this.
 
+Providing Global-level Configurations With Your Layer
+-----------------------------------------------------
+
+When creating a layer, you may need to define configurations that should take
+effect globally in your build environment when the layer is part of the build.
+The ``layer.conf`` file is a :term:`configuration file` that affects the build
+system globally, so it is a candidate for this use-case.
+
+.. warning::
+
+   Providing unconditional global level configuration from the ``layer.conf``
+   file is *not* a good practice, and should be avoided. For this reason, the
+   section :ref:`ref-conditional-layer-confs` below shows how the ``layer.conf``
+   file can be used to provide configurations only if a certain condition is
+   met.
+
+For example, if your layer provides a Linux kernel recipe named
+``linux-custom``, you may want to make :term:`PREFERRED_PROVIDER_virtual/kernel
+<PREFERRED_PROVIDER>` point to ``linux-custom``::
+
+   PREFERRED_PROVIDER_virtual/kernel = "linux-custom"
+
+This can be defined in the ``layer.conf`` file. If your layer is at the last
+position in the :term:`BBLAYERS` list, it will take precedence over previous
+``PREFERRED_PROVIDER_virtual/kernel`` assignments (unless one is set from a
+:term:`configuration file` that is parsed later, such as machine or distro
+configuration files).
+
+.. _ref-conditional-layer-confs:
+
+Conditionally Provide Global-level Configurations With Your Layer
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+In some cases, your layer may provide global configurations only if some
+features it provides are enabled. Since the ``layer.conf`` file is parsed at an
+earlier stage in the parsing process, the :term:`DISTRO_FEATURES` and
+:term:`MACHINE_FEATURES` variables are not yet available to ``layer.conf``, and
+declaring conditional assignments based on these variables is not possible. The
+following technique shows a way to bypass this limitation by using the
+:term:`USER_CLASSES` variable and a conditional ``require`` command.
+
+In the following steps, let's assume our layer is named ``meta-mylayer`` and
+that this layer defines a custom :ref:`distro feature <ref-features-distro>`
+named ``mylayer-kernel``. We will set the :term:`PREFERRED_PROVIDER` variable
+for the kernel only if our feature ``mylayer-kernel`` is part of the
+:term:`DISTRO_FEATURES`:
+
+#. Create an include file in the directory
+   ``meta-mylayer/conf/distro/include/``, for example a file named
+   ``mylayer-kernel-provider.inc`` that sets the kernel provider to
+   ``linux-custom``::
+
+      PREFERRED_PROVIDER_virtual/kernel = "linux-custom"
+
+#. Provide a path to this include file in your ``layer.conf``::
+
+      META_MYLAYER_KERNEL_PROVIDER_PATH = "${LAYERDIR}/conf/distro/include/mylayer-kernel-provider.inc"
+
+#. Create a new class in ``meta-mylayer/classes-global/``, for example a class
+   ``meta-mylayer-cfg.bbclass``. Make it conditionally require the file
+   ``mylayer-kernel-provider.inc`` defined above, using the variable
+   ``META_MYLAYER_KERNEL_PROVIDER_PATH`` defined in ``layer.conf``::
+
+      require ${@bb.utils.contains('DISTRO_FEATURES', 'mylayer-kernel', '${META_MYLAYER_KERNEL_PROVIDER_PATH}', '', d)}
+
+   For details on the ``bb.utils.contains`` function, see its definition in
+   :bitbake_git:`lib/bb/utils.py </tree/lib/bb/utils.py>`.
+
+   .. note::
+
+      The ``require`` command is designed to not fail if the function
+      ``bb.utils.contains`` returns an empty string.
+
+#. Back to your ``layer.conf`` file, add the class ``meta-mylayer-cfg`` class to
+   the :term:`USER_CLASSES` variable::
+
+      USER_CLASSES:append = " meta-mylayer-cfg"
+
+   This will add the class ``meta-mylayer-cfg`` to the list of classes to
+   globally inherit. Since the ``require`` command is conditional in
+   ``meta-mylayer-cfg.bbclass``, even though inherited the class will have no
+   effect unless the feature ``mylayer-kernel`` is enabled through
+   :term:`DISTRO_FEATURES`.
+
+This technique can also be used for :ref:`Machine features
+<ref-features-machine>` by following the same steps. Though not mandatory, it is
+recommended to put include files for :term:`DISTRO_FEATURES` in your layer's
+``conf/distro/include`` and the ones for :term:`MACHINE_FEATURES` in your
+layer's ``conf/machine/include``.
+
 Managing Layers
 ===============
 
@@ -732,6 +821,8 @@ The following list describes the available commands:
 
 -  ``create-layer``: Creates a basic layer.
 
+-  ``show-machines``: Lists the machines available in the currently configured layers.
+
 Creating a General Layer Using the ``bitbake-layers`` Script
 ============================================================
 

documentation/dev-manual/libraries.rst

@@ -37,7 +37,7 @@ library files.
    Some previously released versions of the Yocto Project defined the
    static library files through ``${PN}-dev``.
 
-Following is part of the BitBake configuration file, where you can see
+Here is the part of the BitBake configuration file, where you can see
 how the static library files are defined::
 
    PACKAGE_BEFORE_PN ?= ""
@@ -177,7 +177,7 @@ Additional Implementation Details
 ---------------------------------
 
 There are generic implementation details as well as details that are specific to
-package management systems. Following are implementation details
+package management systems. Here are implementation details
 that exist regardless of the package management system:
 
 -  The typical convention used for the class extension code as used by

documentation/dev-manual/licenses.rst

@@ -27,7 +27,7 @@ Specifying the ``LIC_FILES_CHKSUM`` Variable
 --------------------------------------------
 
 The :term:`LIC_FILES_CHKSUM` variable contains checksums of the license text
-in the source code for the recipe. Following is an example of how to
+in the source code for the recipe. Here is an example of how to
 specify :term:`LIC_FILES_CHKSUM`::
 
    LIC_FILES_CHKSUM = "file://COPYING;md5=xxxx \

documentation/dev-manual/new-machine.rst

@@ -104,7 +104,7 @@ contains directories for specific machines such as ``qemuarm`` and
 defaults, see the ``meta/recipes-bsp/formfactor/files/config`` file
 found in the same area.
 
-Following is an example for "qemuarm" machine::
+Here is an example for "qemuarm" machine::
 
    HAVE_TOUCHSCREEN=1
    HAVE_KEYBOARD=1

documentation/dev-manual/new-recipe.rst

@@ -56,7 +56,7 @@ necessary when adding a recipe to build a new piece of software to be
 included in a build.
 
 You can find a complete description of the ``devtool add`` command in
-the ":ref:`sdk-manual/extensible:a closer look at \`\`devtool add\`\``" section
+the ":ref:`sdk-manual/extensible:a closer look at ``devtool add```" section
 in the Yocto Project Application Development and the Extensible Software
 Development Kit (eSDK) manual.
 
@@ -83,24 +83,25 @@ command::
    OpenEmbedded recipe tool
 
    options:
-     -d, --debug     Enable debug output
-     -q, --quiet     Print only errors
-     --color COLOR   Colorize output (where COLOR is auto, always, never)
-     -h, --help      show this help message and exit
+     -d, --debug       Enable debug output
+     -q, --quiet       Print only errors
+     --color COLOR     Colorize output (where COLOR is auto, always, never)
+     -h, --help        show this help message and exit
 
    subcommands:
-     create          Create a new recipe
-     newappend       Create a bbappend for the specified target in the specified
-                       layer
-     setvar          Set a variable within a recipe
-     appendfile      Create/update a bbappend to replace a target file
-     appendsrcfiles  Create/update a bbappend to add or replace source files
-     appendsrcfile   Create/update a bbappend to add or replace a source file
+     newappend         Create a bbappend for the specified target in the specified layer
+     create            Create a new recipe
+     setvar            Set a variable within a recipe
+     appendfile        Create/update a bbappend to replace a target file
+     appendsrcfiles    Create/update a bbappend to add or replace source files
+     appendsrcfile     Create/update a bbappend to add or replace a source file
+     edit              Edit the recipe and appends for the specified target. This obeys $VISUAL if set,
+                       otherwise $EDITOR, otherwise vi.
    Use recipetool <subcommand> --help to get help on a specific command
 
 Running ``recipetool create -o OUTFILE`` creates the base recipe and
 locates it properly in the layer that contains your source files.
-Following are some syntax examples:
+Here are some syntax examples:
 
  - Use this syntax to generate a recipe based on source. Once generated,
    the recipe resides in the existing source code layer::
@@ -218,9 +219,9 @@ compilation and packaging files, and so forth.
 
 The path to the per-recipe temporary work directory depends on the
 context in which it is being built. The quickest way to find this path
-is to have BitBake return it by running the following::
+is to use the ``bitbake-getvar`` utility::
 
-   $ bitbake -e basename | grep ^WORKDIR=
+   $ bitbake-getvar -r basename WORKDIR
 
 As an example, assume a Source Directory
 top-level folder named ``poky``, a default :term:`Build Directory` at
@@ -303,28 +304,33 @@ If your :term:`SRC_URI` statement includes URLs pointing to individual files
 fetched from a remote server other than a version control system,
 BitBake attempts to verify the files against checksums defined in your
 recipe to ensure they have not been tampered with or otherwise modified
-since the recipe was written. Two checksums are used:
-``SRC_URI[md5sum]`` and ``SRC_URI[sha256sum]``.
+since the recipe was written. Multiple checksums are supported:
+``SRC_URI[md5sum]``, ``SRC_URI[sha1sum]``, ``SRC_URI[sha256sum]``.
+``SRC_URI[sha384sum]`` and ``SRC_URI[sha512sum]``, but only
+``SRC_URI[sha256sum]`` is commonly used.
+
+.. note::
+
+   ``SRC_URI[md5sum]`` used to also be commonly used, but it is deprecated
+   and should be replaced by ``SRC_URI[sha256sum]`` when updating existing
+   recipes.
 
 If your :term:`SRC_URI` variable points to more than a single URL (excluding
-SCM URLs), you need to provide the ``md5`` and ``sha256`` checksums for
-each URL. For these cases, you provide a name for each URL as part of
-the :term:`SRC_URI` and then reference that name in the subsequent checksum
-statements. Here is an example combining lines from the files
-``git.inc`` and ``git_2.24.1.bb``::
+SCM URLs), you need to provide the ``sha256`` checksum for each URL. For these
+cases, you provide a name for each URL as part of the :term:`SRC_URI` and then
+reference that name in the subsequent checksum statements. Here is an example
+combining lines from the files ``git.inc`` and ``git_2.24.1.bb``::
 
    SRC_URI = "${KERNELORG_MIRROR}/software/scm/git/git-${PV}.tar.gz;name=tarball \
               ${KERNELORG_MIRROR}/software/scm/git/git-manpages-${PV}.tar.gz;name=manpages"
 
-   SRC_URI[tarball.md5sum] = "166bde96adbbc11c8843d4f8f4f9811b"
    SRC_URI[tarball.sha256sum] = "ad5334956301c86841eb1e5b1bb20884a6bad89a10a6762c958220c7cf64da02"
-   SRC_URI[manpages.md5sum] = "31c2272a8979022497ba3d4202df145d"
    SRC_URI[manpages.sha256sum] = "9a7ae3a093bea39770eb96ca3e5b40bff7af0b9f6123f089d7821d0e5b8e1230"
 
-Proper values for ``md5`` and ``sha256`` checksums might be available
+The proper value for the ``sha256`` checksum might be available together
 with other signatures on the download page for the upstream source (e.g.
 ``md5``, ``sha1``, ``sha256``, ``GPG``, and so forth). Because the
-OpenEmbedded build system only deals with ``sha256sum`` and ``md5sum``,
+OpenEmbedded build system typically only deals with ``sha256sum``,
 you should verify all the signatures you find by hand.
 
 If no :term:`SRC_URI` checksums are specified when you attempt to build the
@@ -433,7 +439,7 @@ Licensing
 =========
 
 Your recipe needs to define variables related to the license
-under whith the software is distributed. See the
+under which the software is distributed. See the
 :ref:`contributor-guide/recipe-style-guide:recipe license fields`
 section in the Contributor Guide for details.
 
@@ -1228,7 +1234,7 @@ inherit the :ref:`ref-classes-autotools` class, which contains the definitions
 of all the steps needed to build an Autotool-based application. The result of
 the build is automatically packaged. And, if the application uses NLS for
 localization, packages with local information are generated (one package per
-language). Following is one example: (``hello_2.3.bb``)::
+language). Here is one example: (``hello_2.3.bb``)::
 
    SUMMARY = "GNU Helloworld application"
    SECTION = "examples"
@@ -1281,7 +1287,7 @@ Splitting an Application into Multiple Packages
 You can use the variables :term:`PACKAGES` and :term:`FILES` to split an
 application into multiple packages.
 
-Following is an example that uses the ``libxpm`` recipe. By default,
+Here is an example that uses the ``libxpm`` recipe. By default,
 this recipe generates a single package that contains the library along
 with a few binaries. You can modify the recipe to split the binaries
 into separate packages::
@@ -1506,7 +1512,7 @@ in the BitBake User Manual.
       when you make the assignment, but this is not generally needed.
 
 -  *Quote All Assignments ("value"):* Use double quotes around values in
-   all variable assignments (e.g. ``"value"``). Following is an example::
+   all variable assignments (e.g. ``"value"``). Here is an example::
 
       VAR1 = "${OTHERVAR}"
       VAR2 = "The version is ${PV}"

documentation/dev-manual/packages.rst

@@ -16,7 +16,7 @@ This section describes a few tasks that involve packages:
 -  :ref:`dev-manual/packages:generating and using signed packages`
 
 -  :ref:`Setting up and running package test
-   (ptest) <dev-manual/packages:testing packages with ptest>`
+   (ptest) <test-manual/ptest:testing packages with ptest>`
 
 -  :ref:`dev-manual/packages:creating node package manager (npm) packages`
 
@@ -205,9 +205,14 @@ history, see the
    The OpenEmbedded build system does not maintain :term:`PR` information as
    part of the shared state (sstate) packages. If you maintain an sstate
    feed, it's expected that either all your building systems that
-   contribute to the sstate feed use a shared PR Service, or you do not
-   run a PR Service on any of your building systems. Having some systems
-   use a PR Service while others do not leads to obvious problems.
+   contribute to the sstate feed use a shared PR service, or you do not
+   run a PR service on any of your building systems.
+
+   That's because if you had multiple machines sharing a PR service but
+   not their sstate feed, you could end up with "diverging" hashes for
+   the same output artefacts. When presented to the share PR service,
+   each would be considered as new and would increase the revision
+   number, causing many unnecessary package upgrades.
 
    For more information on shared state, see the
    ":ref:`overview-manual/concepts:shared state cache`"
@@ -274,8 +279,23 @@ with a number. The number used depends on the state of the PR Service:
 
    .. code-block:: none
 
-      hello-world-git_0.0+git0+b6558dd387-r0.0_armv7a-neon.ipk
-      hello-world-git_0.0+git1+dd2f5c3565-r0.0_armv7a-neon.ipk
+      hello-world-git_1.0+git0+b6558dd387-r0.0_armv7a-neon.ipk
+      hello-world-git_1.0+git1+dd2f5c3565-r0.1_armv7a-neon.ipk
+
+   Two numbers got incremented here:
+
+   -  ``gitX`` changed from ``git0`` to ``git1``. This is because there was a
+      change in the source code (``SRCREV``).
+
+   -  ``r0.X`` changed from ``r0.0`` to ``r0.1``. This is because the hash of
+      the :ref:`ref-tasks-package` task changed.
+
+      The reason for this change can be many. To understand why the hash of the
+      :ref:`ref-tasks-package` task changed, you can run the following command:
+
+      .. code-block:: console
+
+         $ bitbake-diffsigs -t hello-world package
 
 -  If PR Service is not enabled, the build system replaces the
    ``AUTOINC`` placeholder with zero (i.e. "0"). This results in
@@ -285,8 +305,8 @@ with a number. The number used depends on the state of the PR Service:
 
    .. code-block:: none
 
-      hello-world-git_0.0+git0+b6558dd387-r0.0_armv7a-neon.ipk
-      hello-world-git_0.0+git0+dd2f5c3565-r0.0_armv7a-neon.ipk
+      hello-world-git_1.0+git0+b6558dd387-r0_armv7a-neon.ipk
+      hello-world-git_1.0+git0+dd2f5c3565-r0_armv7a-neon.ipk
 
 In summary, the OpenEmbedded build system does not track the history of
 binary package versions for this purpose. ``AUTOINC``, in this case, is
@@ -365,7 +385,7 @@ For more examples that show how to use ``do_split_packages``, see the
 directory of the ``poky`` :ref:`source repository <overview-manual/development-environment:yocto project source repositories>`. You can
 also find examples in ``meta/classes-recipe/kernel.bbclass``.
 
-Following is a reference that shows ``do_split_packages`` mandatory and
+Here is a reference that shows ``do_split_packages`` mandatory and
 optional arguments::
 
    Mandatory arguments
@@ -607,6 +627,13 @@ subsequent sections are necessary to configure the target. You should
 set these variables before building the image in order to produce a
 correctly configured image.
 
+.. note::
+
+   Your image will need enough free storage space to run package upgrades,
+   especially if many of them need to be downloaded at the same time.
+   You should make sure images are created with enough free space
+   by setting the :term:`IMAGE_ROOTFS_EXTRA_SPACE` variable.
+
 When your build is complete, your packages reside in the
 ``${TMPDIR}/deploy/packageformat`` directory. For example, if
 ``${``\ :term:`TMPDIR`\ ``}`` is
@@ -875,114 +902,8 @@ related to signed package feeds are available:
 Testing Packages With ptest
 ===========================
 
-A Package Test (ptest) runs tests against packages built by the
-OpenEmbedded build system on the target machine. A ptest contains at
-least two items: the actual test, and a shell script (``run-ptest``)
-that starts the test. The shell script that starts the test must not
-contain the actual test --- the script only starts the test. On the other
-hand, the test can be anything from a simple shell script that runs a
-binary and checks the output to an elaborate system of test binaries and
-data files.
-
-The test generates output in the format used by Automake::
-
-   result: testname
-
-where the result can be ``PASS``, ``FAIL``, or ``SKIP``, and
-the testname can be any identifying string.
-
-For a list of Yocto Project recipes that are already enabled with ptest,
-see the :yocto_wiki:`Ptest </Ptest>` wiki page.
-
-.. note::
-
-   A recipe is "ptest-enabled" if it inherits the :ref:`ref-classes-ptest`
-   class.
-
-Adding ptest to Your Build
---------------------------
-
-To add package testing to your build, add the :term:`DISTRO_FEATURES` and
-:term:`EXTRA_IMAGE_FEATURES` variables to your ``local.conf`` file, which
-is found in the :term:`Build Directory`::
-
-   DISTRO_FEATURES:append = " ptest"
-   EXTRA_IMAGE_FEATURES += "ptest-pkgs"
-
-Once your build is complete, the ptest files are installed into the
-``/usr/lib/package/ptest`` directory within the image, where ``package``
-is the name of the package.
-
-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.
-
-Getting Your Package Ready
---------------------------
-
-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:
-
--  *Be sure the recipe inherits the* :ref:`ref-classes-ptest` *class:*
-   Include the following line in each recipe::
-
-      inherit ptest
-
--  *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``::
-
-      #!/bin/sh
-      cd test
-      make -k runtest-TESTS
-
--  *Ensure dependencies are met:* If the test adds build or runtime
-   dependencies that normally do not exist for the package (such as
-   requiring "make" to run the test suite), use the
-   :term:`DEPENDS` and
-   :term:`RDEPENDS` variables in
-   your recipe in order for the package to meet the dependencies. Here
-   is an example where the package has a runtime dependency on "make"::
-
-      RDEPENDS:${PN}-ptest += "make"
-
--  *Add a function to build the test suite:* Not many packages support
-   cross-compilation of their test suites. Consequently, you usually
-   need to add a cross-compilation function to the package.
-
-   Many packages based on Automake compile and run the test suite by
-   using a single command such as ``make check``. However, the host
-   ``make check`` builds and runs on the same computer, while
-   cross-compiling requires that the package is built on the host but
-   executed for the target architecture (though often, as in the case
-   for ptest, the execution occurs on the host). The built version of
-   Automake that ships with the Yocto Project includes a patch that
-   separates building and execution. Consequently, packages that use the
-   unaltered, patched version of ``make check`` automatically
-   cross-compiles.
-
-   Regardless, you still must add a ``do_compile_ptest`` function to
-   build the test suite. Add a function similar to the following to your
-   recipe::
-
-      do_compile_ptest() {
-          oe_runmake buildtest-TESTS
-      }
-
--  *Ensure special configurations are set:* If the package requires
-   special configurations prior to compiling the test code, you must
-   insert a ``do_configure_ptest`` function into the recipe.
-
--  *Install the test suite:* The :ref:`ref-classes-ptest` class
-   automatically copies the file ``run-ptest`` to the target and then runs make
-   ``install-ptest`` to run the tests. If this is not enough, you need
-   to create a ``do_install_ptest`` function and make sure it gets
-   called after the "make install-ptest" completes.
+See the :ref:`test-manual/ptest:Testing Packages With ptest` section of the
+Yocto Project Test Environment Manual.
 
 Creating Node Package Manager (NPM) Packages
 ============================================
@@ -1123,7 +1044,7 @@ The ``devtool edit-recipe`` command lets you take a look at the recipe::
    ...
    LICENSE:${PN}-vary = "MIT"
 
-Here are three key points in the previous example:
+Three key points in the previous example are:
 
 -  :term:`SRC_URI` uses the NPM
    scheme so that the NPM fetcher is used.

documentation/dev-manual/prebuilt-libraries.rst

@@ -148,8 +148,8 @@ recipe. By default, ``libfoo.so`` gets packaged into ``${PN}-dev``, which
 triggers a QA warning that a non-symlink library is in a ``-dev`` package,
 and binaries in the same recipe link to the library in ``${PN}-dev``,
 which triggers more QA warnings. To solve this problem, you need to package the
-unversioned library into ``${PN}`` where it belongs. The following are the abridged
-default :term:`FILES` variables in ``bitbake.conf``::
+unversioned library into ``${PN}`` where it belongs. The abridged
+default :term:`FILES` variables in ``bitbake.conf`` are::
 
    SOLIBS = ".so.*"
    SOLIBSDEV = ".so"

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

@@ -35,7 +35,7 @@ system were executing them. Consequently, working this way can be
 helpful when debugging a build or preparing software to be used with the
 OpenEmbedded build system.
 
-Following is an example that uses ``pydevshell`` on a target named
+Here is an example that uses ``pydevshell`` on a target named
 ``matchbox-desktop``::
 
    $ bitbake matchbox-desktop -c pydevshell

documentation/dev-manual/qemu.rst

@@ -75,7 +75,7 @@ available. Follow these general steps to run QEMU:
       your :term:`Build Directory`.
 
    -  If you have not built an image, you can go to the
-      :yocto_dl:`machines/qemu </releases/yocto/yocto-&DISTRO;/machines/qemu/>` area and download a
+      :yocto_dl:`machines/qemu </releases/yocto/&DISTRO_REL_LATEST_TAG;/machines/qemu/>` area and download a
       pre-built image that matches your architecture and can be run on
       QEMU.
 
@@ -287,12 +287,11 @@ present, the toolchain is also automatically used.
       networking.
 
    -  SSH servers are available in some QEMU images. The ``core-image-sato``
-      QEMU image has a Dropbear secure shell (SSH) server that runs with
-      the root password disabled. The ``core-image-full-cmdline`` and
-      ``core-image-lsb`` QEMU images have OpenSSH instead of Dropbear.
-      Including these SSH servers allow you to use standard ``ssh`` and
-      ``scp`` commands. The ``core-image-minimal`` QEMU image, however,
-      contains no SSH server.
+      QEMU image has a Dropbear secure shell (SSH) server that runs with the
+      root password disabled. The ``core-image-full-cmdline`` QEMU image has
+      OpenSSH instead of Dropbear. Including these SSH servers allow you to use
+      standard ``ssh`` and ``scp`` commands. The ``core-image-minimal`` QEMU
+      image, however, contains no SSH server.
 
    -  You can use a provided, user-space NFS server to boot the QEMU
       session using a local copy of the root filesystem on the host. In
@@ -318,7 +317,7 @@ timestamp when it needs to look for an image. Minimally, through the use
 of options, you must provide either a machine name, a virtual machine
 image (``*wic.vmdk``), or a kernel image (``*.bin``).
 
-Following is the command-line help output for the ``runqemu`` command::
+Here is the command-line help output for the ``runqemu`` command::
 
    $ runqemu --help
 
@@ -360,7 +359,7 @@ Following is the command-line help output for the ``runqemu`` command::
 ``runqemu`` Command-Line Options
 ================================
 
-Following is a description of ``runqemu`` options you can provide on the
+Here is a description of ``runqemu`` options you can provide on the
 command line:
 
 .. note::

documentation/dev-manual/sbom.rst

@@ -30,26 +30,26 @@ To make this happen, you must inherit the
 
    INHERIT += "create-spdx"
 
-You then get :term:`SPDX` output in JSON format as an
-``IMAGE-MACHINE.spdx.json`` file in ``tmp/deploy/images/MACHINE/`` inside the
-:term:`Build Directory`.
-
-This is a toplevel file accompanied by an ``IMAGE-MACHINE.spdx.index.json``
-containing an index of JSON :term:`SPDX` files for individual recipes, together
-with an ``IMAGE-MACHINE.spdx.tar.zst`` compressed archive containing all such
-files.
+Upon building an image, you will then get the compressed archive
+``IMAGE-MACHINE.spdx.tar.zst`` contains the index and the files for the single
+recipes.
 
 The :ref:`ref-classes-create-spdx` class offers options to include
-more information in the output :term:`SPDX` data, such as making the generated
-files more human readable (:term:`SPDX_PRETTY`), adding compressed archives of
-the files in the generated target packages (:term:`SPDX_ARCHIVE_PACKAGED`),
-adding a description of the source files used to generate host tools and target
-packages (:term:`SPDX_INCLUDE_SOURCES`) and adding archives of these source
-files themselves (:term:`SPDX_ARCHIVE_SOURCES`).
+more information in the output :term:`SPDX` data:
+
+-  Make the json files more human readable by setting (:term:`SPDX_PRETTY`).
+
+-  Add compressed archives of the files in the generated target packages by
+   setting (:term:`SPDX_ARCHIVE_PACKAGED`).
+
+-  Add a description of the source files used to generate host tools and target
+   packages (:term:`SPDX_INCLUDE_SOURCES`)
+
+-  Add archives of these source files themselves (:term:`SPDX_ARCHIVE_SOURCES`).
 
 Though the toplevel :term:`SPDX` output is available in
 ``tmp/deploy/images/MACHINE/`` inside the :term:`Build Directory`, ancillary
-generated files are available in ``tmp/deploy/spdx/MACHINE`` too, such as:
+generated files are available in ``tmp/deploy/spdx`` too, such as:
 
 -  The individual :term:`SPDX` JSON files in the ``IMAGE-MACHINE.spdx.tar.zst``
    archive.
@@ -67,6 +67,8 @@ See the `tools page <https://spdx.dev/resources/tools/>`__ on the :term:`SPDX`
 project website for a list of tools to consume and transform the :term:`SPDX`
 data generated by the OpenEmbedded build system.
 
-See also Joshua Watt's
+See also Joshua Watt's presentations
 `Automated SBoM generation with OpenEmbedded and the Yocto Project <https://youtu.be/Q5UQUM6zxVU>`__
-presentation at FOSDEM 2023.
+at FOSDEM 2023 and
+`SPDX in the Yocto Project <https://fosdem.org/2024/schedule/event/fosdem-2024-3318-spdx-in-the-yocto-project/>`__
+at FOSDEM 2024.

documentation/dev-manual/security-subjects.rst

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

documentation/dev-manual/speeding-up-build.rst

@@ -33,7 +33,7 @@ auto-scaling ensures that the build system fundamentally takes advantage
 of potential parallel operations during the build based on the build
 machine's capabilities.
 
-Following are additional factors that can affect build speed:
+Additional factors that can affect build speed are:
 
 -  File system type: The file system type that the build is being
    performed on can also influence performance. Using ``ext4`` is
@@ -88,7 +88,7 @@ that can help you speed up the build:
    variable to "1".
 
 -  Disable static library generation for recipes derived from
-   ``autoconf`` or ``libtool``: Following is an example showing how to
+   ``autoconf`` or ``libtool``: Here is an example showing how to
    disable static libraries and still provide an override to handle
    exceptions::
 

documentation/dev-manual/start.rst

@@ -36,7 +36,7 @@ particular working environment and set of practices.
     equipment together and set up your development environment's
     hardware topology.
 
-    Here are possible roles:
+    Possible roles are:
 
     -  *Application Developer:* This type of developer does application
        level work on top of an existing software stack.
@@ -99,7 +99,7 @@ particular working environment and set of practices.
 
 5.  *Set up the Application Development Machines:* As mentioned earlier,
     application developers are creating applications on top of existing
-    software stacks. Following are some best practices for setting up
+    software stacks. Here are some best practices for setting up
     machines used for application development:
 
     -  Use a pre-built toolchain that contains the software stack
@@ -118,7 +118,7 @@ particular working environment and set of practices.
 
 6.  *Set up the Core Development Machines:* As mentioned earlier, core
     developers work on the contents of the operating system itself.
-    Following are some best practices for setting up machines used for
+    Here are some best practices for setting up machines used for
     developing images:
 
     -  Have the :term:`OpenEmbedded Build System` available on
@@ -254,16 +254,16 @@ development using the Yocto Project. Your build host can be a native
 Linux machine (recommended), it can be a machine (Linux, Mac, or
 Windows) that uses `CROPS <https://github.com/crops/poky-container>`__,
 which leverages `Docker Containers <https://www.docker.com/>`__ or it
-can be a Windows machine capable of running Windows Subsystem For Linux
-v2 (WSL).
+can be a Windows machine capable of running version 2 of Windows Subsystem
+For Linux (WSL 2).
 
 .. note::
 
-   The Yocto Project is not compatible with
-   `Windows Subsystem for Linux v1 <https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux>`__.
-   It is compatible but not officially supported nor validated with
-   WSLv2. If you still decide to use WSL please upgrade to
-   `WSLv2 <https://docs.microsoft.com/en-us/windows/wsl/install-win10>`__.
+   The Yocto Project is not compatible with version 1 of
+   `Windows Subsystem for Linux <https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux>`__.
+   It is compatible but neither officially supported nor validated with
+   WSL 2. If you still decide to use WSL please upgrade to
+   `WSL 2 <https://learn.microsoft.com/en-us/windows/wsl/install>`__.
 
 Once your build host is set up to use the Yocto Project, further steps
 are necessary depending on what you want to accomplish. See the
@@ -289,7 +289,7 @@ Project Build Host:
    as these releases are frequently tested against the Yocto Project and
    officially supported. For a list of the distributions under
    validation and their status, see the ":ref:`Supported Linux
-   Distributions <detailed-supported-distros>`"
+   Distributions <system-requirements-supported-distros>`"
    section in the Yocto Project Reference Manual and the wiki page at
    :yocto_wiki:`Distribution Support </Distribution_Support>`.
 
@@ -308,10 +308,12 @@ Project Build Host:
 
    -  gcc &MIN_GCC_VERSION; or greater.
 
+   -  GNU make &MIN_MAKE_VERSION; or greater
+
    If your build host does not meet any of these listed version
    requirements, you can take steps to prepare the system so that you
    can still use the Yocto Project. See the
-   ":ref:`ref-manual/system-requirements:required git, tar, python and gcc versions`"
+   ":ref:`ref-manual/system-requirements:required git, tar, python, make and gcc versions`"
    section in the Yocto Project Reference Manual for information.
 
 4. *Install Development Host Packages:* Required development host
@@ -332,7 +334,10 @@ to use the Extensible SDK, see the ":doc:`/sdk-manual/extensible`" Chapter in th
 Project Application Development and the Extensible Software Development
 Kit (eSDK) manual. If you want to work on the kernel, see the :doc:`/kernel-dev/index`. If you are going to use
 Toaster, see the ":doc:`/toaster-manual/setup-and-use`"
-section in the Toaster User Manual.
+section in the Toaster User Manual. If you are a VSCode user, you can configure
+the `Yocto Project BitBake
+<https://marketplace.visualstudio.com/items?itemName=yocto-project.yocto-bitbake>`__
+extension accordingly.
 
 Setting Up to Use CROss PlatformS (CROPS)
 -----------------------------------------
@@ -424,37 +429,41 @@ section. If you are going to use the Extensible SDK container, see the
 Project Application Development and the Extensible Software Development
 Kit (eSDK) manual. If you are going to use the Toaster container, see
 the ":doc:`/toaster-manual/setup-and-use`"
-section in the Toaster User Manual.
+section in the Toaster User Manual. If you are a VSCode user, you can configure
+the `Yocto Project BitBake
+<https://marketplace.visualstudio.com/items?itemName=yocto-project.yocto-bitbake>`__
+extension accordingly.
 
-Setting Up to Use Windows Subsystem For Linux (WSLv2)
+Setting Up to Use Windows Subsystem For Linux (WSL 2)
 -----------------------------------------------------
 
-With `Windows Subsystem for Linux
-(WSLv2) <https://docs.microsoft.com/en-us/windows/wsl/wsl2-about>`__,
+With `Windows Subsystem for Linux (WSL 2)
+<https://learn.microsoft.com/en-us/windows/wsl/>`__,
 you can create a Yocto Project development environment that allows you
 to build on Windows. You can set up a Linux distribution inside Windows
 in which you can develop using the Yocto Project.
 
-Follow these general steps to prepare a Windows machine using WSLv2 as
+Follow these general steps to prepare a Windows machine using WSL 2 as
 your Yocto Project build host:
 
-1. *Make sure your Windows 10 machine is capable of running WSLv2:*
-   WSLv2 is only available for Windows 10 builds > 18917. To check which
-   build version you are running, you may open a command prompt on
-   Windows and execute the command "ver".
-   ::
+1. *Make sure your Windows machine is capable of running WSL 2:*
+
+   While all Windows 11 and Windows Server 2022 builds support WSL 2,
+   the first versions of Windows 10 and Windows Server 2019 didn't.
+   Check the minimum build numbers for `Windows 10
+   <https://learn.microsoft.com/en-us/windows/wsl/install-manual#step-2---check-requirements-for-running-wsl-2>`__
+   and for `Windows Server 2019
+   <https://learn.microsoft.com/en-us/windows/wsl/install-on-server>`__.
+
+   To check which build version you are running, you may open a command
+   prompt on Windows and execute the command "ver"::
 
       C:\Users\myuser> ver
 
       Microsoft Windows [Version 10.0.19041.153]
 
-   If your build is capable of running
-   WSLv2 you may continue, for more information on this subject or
-   instructions on how to upgrade to WSLv2 visit `Windows 10
-   WSLv2 <https://docs.microsoft.com/en-us/windows/wsl/wsl2-install>`__
-
-2. *Install the Linux distribution of your choice inside Windows 10:*
-   Once you know your version of Windows 10 supports WSLv2, you can
+2. *Install the Linux distribution of your choice inside WSL 2:*
+   Once you know your version of Windows supports WSL 2, you can
    install the distribution of your choice from the Microsoft Store.
    Open the Microsoft Store and search for Linux. While there are
    several Linux distributions available, the assumption is that your
@@ -463,31 +472,28 @@ your Yocto Project build host:
    making your selection, simply click "Get" to download and install the
    distribution.
 
-3. *Check your Linux distribution is using WSLv2:* Open a Windows
+3. *Check which Linux distribution WSL 2 is using:* Open a Windows
    PowerShell and run::
 
       C:\WINDOWS\system32> wsl -l -v
       NAME    STATE   VERSION
       *Ubuntu Running 2
 
-   Note the version column which says the WSL version
-   being used by your distribution, on compatible systems, this can be
-   changed back at any point in time.
+   Note that WSL 2 supports running as many different Linux distributions
+   as you want to install.
 
-4. *Optionally Orient Yourself on WSL:* If you are unfamiliar with WSL,
-   you can learn more here -
+4. *Optionally Get Familiar with WSL:* You can learn more on
    https://docs.microsoft.com/en-us/windows/wsl/wsl2-about.
 
 5. *Launch your WSL Distibution:* From the Windows start menu simply
    launch your WSL distribution just like any other application.
 
-6. *Optimize your WSLv2 storage often:* Due to the way storage is
-   handled on WSLv2, the storage space used by the undelying Linux
-   distribution is not reflected immedately, and since bitbake heavily
+6. *Optimize your WSL 2 storage often:* Due to the way storage is
+   handled on WSL 2, the storage space used by the underlying Linux
+   distribution is not reflected immediately, and since BitBake heavily
    uses storage, after several builds, you may be unaware you are
-   running out of space. WSLv2 uses a VHDX file for storage, this issue
-   can be easily avoided by manually optimizing this file often, this
-   can be done in the following way:
+   running out of space. As WSL 2 uses a VHDX file for storage, this issue
+   can be easily avoided by regularly optimizing this file in a manual way:
 
    1. *Find the location of your VHDX file:*
 
@@ -537,24 +543,28 @@ your Yocto Project build host:
          DISKPART> select vdisk file="<path_to_VHDX_file>"
          DISKPART> attach vdisk readonly
          DISKPART> compact vdisk
+         DISKPART> detach
          DISKPART> exit
 
 .. note::
 
-   The current implementation of WSLv2 does not have out-of-the-box
+   The current implementation of WSL 2 does not have out-of-the-box
    access to external devices such as those connected through a USB
    port, but it automatically mounts your ``C:`` drive on ``/mnt/c/``
    (and others), which you can use to share deploy artifacts to be later
    flashed on hardware through Windows, but your build directory should
    not reside inside this mountpoint.
 
-Once you have WSLv2 set up, everything is in place to develop just as if
+Once you have WSL 2 set up, everything is in place to develop just as if
 you were running on a native Linux machine. If you are going to use the
 Extensible SDK container, see the ":doc:`/sdk-manual/extensible`" Chapter in the Yocto
 Project Application Development and the Extensible Software Development
 Kit (eSDK) manual. If you are going to use the Toaster container, see
 the ":doc:`/toaster-manual/setup-and-use`"
-section in the Toaster User Manual.
+section in the Toaster User Manual. If you are a VSCode user, you can configure
+the `Yocto Project BitBake
+<https://marketplace.visualstudio.com/items?itemName=yocto-project.yocto-bitbake>`__
+extension accordingly.
 
 Locating Yocto Project Source Files
 ===================================
@@ -603,10 +613,14 @@ Use the following procedure to locate the latest upstream copy of the
 Accessing Index of Releases
 ---------------------------
 
-Yocto Project maintains an Index of Releases area that contains related
-files that contribute to the Yocto Project. Rather than Git
-repositories, these files are tarballs that represent snapshots in time
-of a given component.
+The Yocto Project also provides source archives of its releases, which
+are available on :yocto_dl:`/releases/yocto/`. Then, choose the subdirectory
+containing the release you wish to use, for example
+:yocto_dl:`&DISTRO_REL_LATEST_TAG; </releases/yocto/&DISTRO_REL_LATEST_TAG;/>`.
+
+You will find there source archives of individual components (if you wish
+to use them individually), and of the corresponding Poky release bundling
+a selection of these components.
 
 .. note::
 
@@ -642,7 +656,7 @@ Follow these steps to locate and download a particular tarball:
 Using the Downloads Page
 ------------------------
 
-The :yocto_home:`Yocto Project Website <>` uses a "DOWNLOADS" page
+The :yocto_home:`Yocto Project Website <>` uses a "RELEASES" page
 from which you can locate and download tarballs of any Yocto Project
 release. Rather than Git repositories, these files represent snapshot
 tarballs similar to the tarballs located in the Index of Releases
@@ -651,24 +665,25 @@ described in the ":ref:`dev-manual/start:accessing index of releases`" section.
 1. *Go to the Yocto Project Website:* Open The
    :yocto_home:`Yocto Project Website <>` in your browser.
 
-2. *Get to the Downloads Area:* Select the "DOWNLOADS" item from the
-   pull-down "SOFTWARE" tab menu near the top of the page.
+#. *Get to the Downloads Area:* Select the "RELEASES" item from the
+   pull-down "DEVELOPMENT" tab menu near the top of the page.
 
-3. *Select a Yocto Project Release:* Use the menu next to "RELEASE" to
-   display and choose a recent or past supported Yocto Project release
-   (e.g. &DISTRO_NAME_NO_CAP;, &DISTRO_NAME_NO_CAP_MINUS_ONE;, and so forth).
+#. *Select a Yocto Project Release:* On the top of the "RELEASE" page currently
+   supported releases are displayed, further down past supported Yocto Project
+   releases are visible. The "Download" links in the rows of the table there
+   will lead to the download tarballs for the release.
 
    .. note::
 
       For a "map" of Yocto Project releases to version numbers, see the
-      :yocto_wiki:`Releases </Releases>` wiki page.
+      :yocto_home:`Releases </development/releases/>` page.
 
    You can use the "RELEASE ARCHIVE" link to reveal a menu of all Yocto
    Project releases.
 
-4. *Download Tools or Board Support Packages (BSPs):* From the
-   "DOWNLOADS" page, you can download tools or BSPs as well. Just scroll
-   down the page and look for what you need.
+#. *Download Tools or Board Support Packages (BSPs):* Next to the tarballs you
+   will find download tools or BSPs as well. Just select a Yocto Project
+   release and look for what you need.
 
 Cloning and Checking Out Branches
 =================================

documentation/dev-manual/upgrading-recipes.rst

@@ -113,7 +113,7 @@ The following steps describe how to set up the AUH utility:
       ``upgrade-helper/work/recipe/buildhistory-diff.txt`` file found in
       your :term:`Build Directory`.
 
-   -  If you want to enable testing through the :ref:`ref-classes-testimage*`
+   -  If you want to enable testing through the :ref:`ref-classes-testimage`
       class, which is optional, you need to have the following set in
       your ``conf/local.conf`` file::
 
@@ -333,7 +333,7 @@ Manually Upgrading a Recipe
 
 If for some reason you choose not to upgrade recipes using
 :ref:`dev-manual/upgrading-recipes:Using the Auto Upgrade Helper (AUH)` or
-by :ref:`dev-manual/upgrading-recipes:Using \`\`devtool upgrade\`\``,
+by :ref:`dev-manual/upgrading-recipes:Using ``devtool upgrade```,
 you can manually edit the recipe files to upgrade the versions.
 
 .. note::

documentation/dev-manual/vulnerabilities.rst

@@ -12,7 +12,7 @@ known security vulnerabilities, as tracked by the public
 database.
 
 The Yocto Project maintains a `list of known vulnerabilities
-<https://autobuilder.yocto.io/pub/non-release/patchmetrics/>`__
+<https://valkyrie.yocto.io/pub/non-release/patchmetrics/>`__
 for packages in Poky and OE-Core, tracking the evolution of the number of
 unpatched CVEs and the status of patches. Such information is available for
 the current development version and for each supported release.
@@ -62,37 +62,77 @@ found in ``build/tmp/deploy/cve``.
 
 For example the CVE check report for the ``flex-native`` recipe looks like::
 
-   $ cat poky/build/tmp/deploy/cve/flex-native
-   LAYER: meta
-   PACKAGE NAME: flex-native
-   PACKAGE VERSION: 2.6.4
-   CVE: CVE-2016-6354
-   CVE STATUS: Patched
-   CVE SUMMARY: Heap-based buffer overflow in the yy_get_next_buffer function in Flex before 2.6.1 might allow context-dependent attackers to cause a denial of service or possibly execute arbitrary code via vectors involving num_to_read.
-   CVSS v2 BASE SCORE: 7.5
-   CVSS v3 BASE SCORE: 9.8
-   VECTOR: NETWORK
-   MORE INFORMATION: https://nvd.nist.gov/vuln/detail/CVE-2016-6354
-
-   LAYER: meta
-   PACKAGE NAME: flex-native
-   PACKAGE VERSION: 2.6.4
-   CVE: CVE-2019-6293
-   CVE STATUS: Ignored
-   CVE SUMMARY: An issue was discovered in the function mark_beginning_as_normal in nfa.c in flex 2.6.4. There is a stack exhaustion problem caused by the mark_beginning_as_normal function making recursive calls to itself in certain scenarios involving lots of '*' characters. Remote attackers could leverage this vulnerability to cause a denial-of-service.
-   CVSS v2 BASE SCORE: 4.3
-   CVSS v3 BASE SCORE: 5.5
-   VECTOR: NETWORK
-   MORE INFORMATION: https://nvd.nist.gov/vuln/detail/CVE-2019-6293
+   $ cat ./tmp/deploy/cve/flex-native_cve.json
+   {
+     "version": "1",
+     "package": [
+       {
+         "name": "flex-native",
+         "layer": "meta",
+         "version": "2.6.4",
+         "products": [
+           {
+             "product": "flex",
+             "cvesInRecord": "No"
+           },
+           {
+             "product": "flex",
+             "cvesInRecord": "Yes"
+           }
+         ],
+         "issue": [
+           {
+             "id": "CVE-2006-0459",
+             "status": "Patched",
+             "link": "https://nvd.nist.gov/vuln/detail/CVE-2006-0459",
+             "summary": "flex.skl in Will Estes and John Millaway Fast Lexical Analyzer Generator (flex) before 2.5.33 does not allocate enough memory for grammars containing (1) REJECT statements or (2) trailing context rules, which causes flex to generate code that contains a buffer overflow that might allow context-dependent attackers to execute arbitrary code.",
+             "scorev2": "7.5",
+             "scorev3": "0.0",
+             "scorev4": "0.0",
+             "modified": "2024-11-21T00:06Z",
+             "vector": "NETWORK",
+             "vectorString": "AV:N/AC:L/Au:N/C:P/I:P/A:P",
+             "detail": "version-not-in-range"
+           },
+           {
+             "id": "CVE-2016-6354",
+             "status": "Patched",
+             "link": "https://nvd.nist.gov/vuln/detail/CVE-2016-6354",
+             "summary": "Heap-based buffer overflow in the yy_get_next_buffer function in Flex before 2.6.1 might allow context-dependent attackers to cause a denial of service or possibly execute arbitrary code via vectors involving num_to_read.",
+             "scorev2": "7.5",
+             "scorev3": "9.8",
+             "scorev4": "0.0",
+             "modified": "2024-11-21T02:55Z",
+             "vector": "NETWORK",
+             "vectorString": "AV:N/AC:L/Au:N/C:P/I:P/A:P",
+             "detail": "version-not-in-range"
+           },
+           {
+             "id": "CVE-2019-6293",
+             "status": "Ignored",
+             "link": "https://nvd.nist.gov/vuln/detail/CVE-2019-6293",
+             "summary": "An issue was discovered in the function mark_beginning_as_normal in nfa.c in flex 2.6.4. There is a stack exhaustion problem caused by the mark_beginning_as_normal function making recursive calls to itself in certain scenarios involving lots of '*' characters. Remote attackers could leverage this vulnerability to cause a denial-of-service.",
+             "scorev2": "4.3",
+             "scorev3": "5.5",
+             "scorev4": "0.0",
+             "modified": "2024-11-21T04:46Z",
+             "vector": "NETWORK",
+             "vectorString": "AV:N/AC:M/Au:N/C:N/I:N/A:P",
+             "detail": "upstream-wontfix",
+             "description": "there is stack exhaustion but no bug and it is building the parser, not running it, effectively similar to a compiler ICE. Upstream no plans to address this."
+           }
+         ]
+       }
+     ]
+   }
 
 For images, a summary of all recipes included in the image and their CVEs is also
-generated in textual and JSON formats. These ``.cve`` and ``.json`` reports can be found
+generated in the JSON format. These ``.json`` reports can be found
 in the ``tmp/deploy/images`` directory for each compiled image.
 
 At build time CVE check will also throw warnings about ``Unpatched`` CVEs::
 
-   WARNING: flex-2.6.4-r0 do_cve_check: Found unpatched CVE (CVE-2019-6293), for more information check /poky/build/tmp/work/core2-64-poky-linux/flex/2.6.4-r0/temp/cve.log
-   WARNING: libarchive-3.5.1-r0 do_cve_check: Found unpatched CVE (CVE-2021-36976), for more information check /poky/build/tmp/work/core2-64-poky-linux/libarchive/3.5.1-r0/temp/cve.log
+   WARNING: qemu-native-9.2.0-r0 do_cve_check: Found unpatched CVE (CVE-2023-1386)
 
 It is also possible to check the CVE status of individual packages as follows::
 
@@ -111,10 +151,10 @@ upstream `NIST CVE database <https://nvd.nist.gov/>`__.
 
 The variable supports using vendor and product names like this::
 
-   CVE_PRODUCT = "flex_project:flex"
+   CVE_PRODUCT = "flex_project:flex westes:flex"
 
-In this example the vendor name used in the CVE database is ``flex_project`` and the
-product is ``flex``. With this setting the ``flex`` recipe only maps to this specific
+In this example we have two possible vendors names,  ``flex_project`` and ``westes``,
+with the product name ``flex``. With this setting the ``flex`` recipe only maps to this specific
 product and not products from other vendors with same name ``flex``.
 
 Similarly, when the recipe version :term:`PV` is not compatible with software versions used by
@@ -195,7 +235,7 @@ products defined in :term:`CVE_PRODUCT`. Then, for each found CVE:
 The CVE database is stored in :term:`DL_DIR` and can be inspected using
 ``sqlite3`` command as follows::
 
-   sqlite3 downloads/CVE_CHECK/nvdcve_1.1.db .dump | grep CVE-2021-37462
+   sqlite3 downloads/CVE_CHECK/nvd*.db .dump | grep CVE-2021-37462
 
 When analyzing CVEs, it is recommended to:
 

documentation/dev-manual/wic.rst

@@ -72,7 +72,7 @@ In order to use the Wic utility with the OpenEmbedded Build system, your
 system needs to meet the following requirements:
 
 -  The Linux distribution on your development host must support the
-   Yocto Project. See the ":ref:`detailed-supported-distros`"
+   Yocto Project. See the ":ref:`system-requirements-supported-distros`"
    section in the Yocto Project Reference Manual for the list of
    distributions that support the Yocto Project.
 
@@ -139,20 +139,20 @@ individual images through the ``list`` command. You can use the ``list``
 command to return the available Wic images as follows::
 
    $ wic list images
-     genericx86                    		Create an EFI disk image for genericx86*
-     edgerouter                    		Create SD card image for Edgerouter
-     beaglebone-yocto              		Create SD card image for Beaglebone
-     qemuriscv                     		Create qcow2 image for RISC-V QEMU machines
-     mkefidisk                     		Create an EFI disk image
-     directdisk-multi-rootfs       		Create multi rootfs image using rootfs plugin
-     directdisk                    		Create a 'pcbios' direct disk image
-     efi-bootdisk                  		
-     mkhybridiso                   		Create a hybrid ISO image
-     directdisk-gpt                		Create a 'pcbios' direct disk image
-     systemd-bootdisk              		Create an EFI disk image with systemd-boot
-     sdimage-bootpart              		Create SD card image with a boot partition
-     qemux86-directdisk            		Create a qemu machine 'pcbios' direct disk image
-     directdisk-bootloader-config  		Create a 'pcbios' direct disk image with custom bootloader config
+     genericx86                                 Create an EFI disk image for genericx86*
+     edgerouter                                 Create SD card image for Edgerouter
+     beaglebone-yocto                           Create SD card image for Beaglebone
+     qemuriscv                                  Create qcow2 image for RISC-V QEMU machines
+     mkefidisk                                  Create an EFI disk image
+     directdisk-multi-rootfs                    Create multi rootfs image using rootfs plugin
+     directdisk                                 Create a 'pcbios' direct disk image
+     efi-bootdisk
+     mkhybridiso                                Create a hybrid ISO image
+     directdisk-gpt                             Create a 'pcbios' direct disk image
+     systemd-bootdisk                           Create an EFI disk image with systemd-boot
+     sdimage-bootpart                           Create SD card image with a boot partition
+     qemux86-directdisk                         Create a qemu machine 'pcbios' direct disk image
+     directdisk-bootloader-config               Create a 'pcbios' direct disk image with custom bootloader config
 
 
 Once you know the list of available
@@ -283,20 +283,20 @@ following two locations::
 Use the following command to list the available kickstart files::
 
    $ wic list images
-     genericx86                    		Create an EFI disk image for genericx86*
-     edgerouter                    		Create SD card image for Edgerouter
-     beaglebone-yocto              		Create SD card image for Beaglebone
-     qemuriscv                     		Create qcow2 image for RISC-V QEMU machines
-     mkefidisk                     		Create an EFI disk image
-     directdisk-multi-rootfs       		Create multi rootfs image using rootfs plugin
-     directdisk                    		Create a 'pcbios' direct disk image
-     efi-bootdisk                  		
-     mkhybridiso                   		Create a hybrid ISO image
-     directdisk-gpt                		Create a 'pcbios' direct disk image
-     systemd-bootdisk              		Create an EFI disk image with systemd-boot
-     sdimage-bootpart              		Create SD card image with a boot partition
-     qemux86-directdisk            		Create a qemu machine 'pcbios' direct disk image
-     directdisk-bootloader-config  		Create a 'pcbios' direct disk image with custom bootloader config
+     genericx86                                 Create an EFI disk image for genericx86*
+     edgerouter                                 Create SD card image for Edgerouter
+     beaglebone-yocto                           Create SD card image for Beaglebone
+     qemuriscv                                  Create qcow2 image for RISC-V QEMU machines
+     mkefidisk                                  Create an EFI disk image
+     directdisk-multi-rootfs                    Create multi rootfs image using rootfs plugin
+     directdisk                                 Create a 'pcbios' direct disk image
+     efi-bootdisk
+     mkhybridiso                                Create a hybrid ISO image
+     directdisk-gpt                             Create a 'pcbios' direct disk image
+     systemd-bootdisk                           Create an EFI disk image with systemd-boot
+     sdimage-bootpart                           Create SD card image with a boot partition
+     qemux86-directdisk                         Create a qemu machine 'pcbios' direct disk image
+     directdisk-bootloader-config               Create a 'pcbios' direct disk image with custom bootloader config
 
 When you use an existing file, you
 do not have to use the ``.wks`` extension. Here is an example in Raw
@@ -514,7 +514,7 @@ or ::
 
    For more information on how to use the ``bmaptool``
    to flash a device with an image, see the
-   ":ref:`dev-manual/bmaptool:flashing images using \`\`bmaptool\`\``"
+   ":ref:`dev-manual/bmaptool:flashing images using ``bmaptool```"
    section.
 
 Using a Modified Kickstart File

documentation/index.rst

@@ -20,7 +20,6 @@ Welcome to the Yocto Project Documentation
    Yocto Project Software Overview <https://www.yoctoproject.org/software-overview/>
    Tips and Tricks Wiki <https://wiki.yoctoproject.org/wiki/TipsAndTricks>
 
-
 .. toctree::
    :maxdepth: 1
    :caption: Manuals
@@ -37,6 +36,12 @@ Welcome to the Yocto Project Documentation
    Test Environment Manual <test-manual/index>
    bitbake
 
+.. toctree::
+   :maxdepth: 1
+   :caption: Security
+
+   Yocto Project Security Reference <security-reference/index>
+
 .. toctree::
    :maxdepth: 1
    :caption: Release Manuals

documentation/kernel-dev/advanced.rst

@@ -182,7 +182,7 @@ the structure:
    order to define a base kernel policy or major kernel type to be
    reused across multiple BSPs, place the file in ``ktypes`` directory.
 
-These distinctions can easily become blurred - especially as out-of-tree
+These distinctions can easily become blurred --- especially as out-of-tree
 features slowly merge upstream over time. Also, remember that how the
 description files are placed is a purely logical organization and has no
 impact on the functionality of the kernel Metadata. There is no impact
@@ -303,8 +303,8 @@ The following listings show the ``build.scc`` file and part of the
                         .
                         .
                         .
- 	        char *dump_write = NULL, *files_source = NULL;
- 	        int opt;
+                char *dump_write = NULL, *files_source = NULL;
+                int opt;
       --
       2.10.1
 

documentation/kernel-dev/common.rst

@@ -383,11 +383,7 @@ home directory:
 
 1. *Create Structure*: Create the layer's structure::
 
-      $ mkdir meta-mylayer
-      $ mkdir meta-mylayer/conf
-      $ mkdir meta-mylayer/recipes-kernel
-      $ mkdir meta-mylayer/recipes-kernel/linux
-      $ mkdir meta-mylayer/recipes-kernel/linux/linux-yocto
+      $ mkdir -p meta-mylayer/conf meta-mylayer/recipes-kernel/linux/linux-yocto
 
    The ``conf`` directory holds your configuration files, while the
    ``recipes-kernel`` directory holds your append file and eventual
@@ -728,13 +724,9 @@ a Raspberry Pi 2, which is based on the Broadcom 2708/2709 chipset::
 
    KBUILD_DEFCONFIG:raspberrypi2 ?= "bcm2709_defconfig"
 
-Aside from modifying your kernel recipe and providing your own
-``defconfig`` file, you need to be sure no files or statements set
-:term:`SRC_URI` to use a ``defconfig`` other than your "in-tree" file (e.g.
-a kernel's ``linux-``\ `machine`\ ``.inc`` file). In other words, if the
-build system detects a statement that identifies an "out-of-tree"
-``defconfig`` file, that statement will override your
-:term:`KBUILD_DEFCONFIG` variable.
+If the build system detects a statement that identifies an "out-of-tree"
+``defconfig`` file, your :term:`KBUILD_DEFCONFIG` variable will take precedence
+over it.
 
 See the
 :term:`KBUILD_DEFCONFIG`
@@ -750,7 +742,7 @@ the extensible SDK and ``devtool``.
 
    Before attempting this procedure, be sure you have performed the
    steps to get ready for updating the kernel as described in the
-   ":ref:`kernel-dev/common:getting ready to develop using \`\`devtool\`\``"
+   ":ref:`kernel-dev/common:getting ready to develop using ``devtool```"
    section.
 
 Patching the kernel involves changing or adding configurations to an
@@ -763,7 +755,7 @@ output at boot time through ``printk`` statements in the kernel's
 ``calibrate.c`` source code file. Applying the patch and booting the
 modified image causes the added messages to appear on the emulator's
 console. The example is a continuation of the setup procedure found in
-the ":ref:`kernel-dev/common:getting ready to develop using \`\`devtool\`\``" Section.
+the ":ref:`kernel-dev/common:getting ready to develop using ``devtool```" Section.
 
 1. *Check Out the Kernel Source Files:* First you must use ``devtool``
    to checkout the kernel source code in its workspace. Be sure you are
@@ -772,7 +764,7 @@ the ":ref:`kernel-dev/common:getting ready to develop using \`\`devtool\`\``" Se
    .. note::
 
       See this step in the
-      ":ref:`kernel-dev/common:getting ready to develop using \`\`devtool\`\``"
+      ":ref:`kernel-dev/common:getting ready to develop using ``devtool```"
       section for more information.
 
    Use the following ``devtool`` command to check out the code::
@@ -887,7 +879,7 @@ the ":ref:`kernel-dev/common:getting ready to develop using \`\`devtool\`\``" Se
    .. note::
 
       See Step 3 of the
-      ":ref:`kernel-dev/common:getting ready to develop using \`\`devtool\`\``"
+      ":ref:`kernel-dev/common:getting ready to develop using ``devtool```"
       section for information on setting up this layer.
 
    Once the command
@@ -1044,9 +1036,7 @@ Section.
    additional structure to your layer using the following commands::
 
       $ cd ~/meta-mylayer
-      $ mkdir recipes-kernel
-      $ mkdir recipes-kernel/linux
-      $ mkdir recipes-kernel/linux/linux-yocto
+      $ mkdir -p recipes-kernel recipes-kernel/linux/linux-yocto
 
    Once you have created this
    hierarchy in your layer, you can move the patch file using the
@@ -1277,15 +1267,17 @@ appear in the ``.config`` file, which is in the :term:`Build Directory`.
 
    For more information about where the ``.config`` file is located, see the
    example in the
-   ":ref:`kernel-dev/common:using \`\`menuconfig\`\``"
+   ":ref:`kernel-dev/common:using ``menuconfig```"
    section.
 
 It is simple to create a configuration fragment. One method is to use
 shell commands. For example, issuing the following from the shell
-creates a configuration fragment file named ``my_smp.cfg`` that enables
-multi-processor support within the kernel::
+creates a configuration fragment file named ``my_changes.cfg`` that enables
+multi-processor support within the kernel and disables the FPGA
+Configuration Framework::
 
-   $ echo "CONFIG_SMP=y" >> my_smp.cfg
+   $ echo "CONFIG_SMP=y" >> my_changes.cfg
+   $ echo "# CONFIG_FPGA is not set" >> my_changes.cfg
 
 .. note::
 
@@ -1373,10 +1365,10 @@ when you override a policy configuration in a hardware configuration
 fragment.
 
 In order to run this task, you must have an existing ``.config`` file.
-See the ":ref:`kernel-dev/common:using \`\`menuconfig\`\``" section for
+See the ":ref:`kernel-dev/common:using ``menuconfig```" section for
 information on how to create a configuration file.
 
-Following is sample output from the ``do_kernel_configcheck`` task:
+Here is sample output from the ``do_kernel_configcheck`` task:
 
 .. code-block:: none
 
@@ -1446,7 +1438,7 @@ and
 tasks until they produce no warnings.
 
 For more information on how to use the ``menuconfig`` tool, see the
-:ref:`kernel-dev/common:using \`\`menuconfig\`\`` section.
+:ref:`kernel-dev/common:using ``menuconfig``` section.
 
 Fine-Tuning the Kernel Configuration File
 -----------------------------------------
@@ -1522,15 +1514,13 @@ Expanding Variables
 ===================
 
 Sometimes it is helpful to determine what a variable expands to during a
-build. You can examine the values of variables by examining the
-output of the ``bitbake -e`` command. The output is long and is more
-easily managed in a text file, which allows for easy searches::
+build. You can examine the value of a variable by running the ``bitbake-getvar``
+command::
 
-   $ bitbake -e virtual/kernel > some_text_file
+   $ bitbake-getvar -r virtual/kernel VARIABLE
 
-Within the text file, you can see
-exactly how each variable is expanded and used by the OpenEmbedded build
-system.
+The output of the command explains exactly how the variable is expanded and used
+by the :term:`OpenEmbedded Build System`.
 
 Working with a "Dirty" Kernel Version String
 ============================================
@@ -1755,10 +1745,10 @@ looks much like the one provided with the ``hello-mod`` template::
    SRC := $(shell pwd)
 
    all:
-   	$(MAKE) -C $(KERNEL_SRC) M=$(SRC)
+        $(MAKE) -C $(KERNEL_SRC) M=$(SRC)
 
    modules_install:
-   	$(MAKE) -C $(KERNEL_SRC) M=$(SRC) modules_install
+        $(MAKE) -C $(KERNEL_SRC) M=$(SRC) modules_install
    ...
 
 The important point to note here is the :term:`KERNEL_SRC` variable. The
@@ -1809,7 +1799,7 @@ tree. Using Git is an efficient way to see what has changed in the tree.
 What Changed in a Kernel?
 -------------------------
 
-Following are a few examples that show how to use Git commands to
+Here are a few examples that show how to use Git commands to
 examine changes. These examples are by no means the only way to see
 changes.
 

documentation/kernel-dev/concepts-appx.rst

@@ -117,7 +117,7 @@ upstream Linux kernel development and are managed by the Yocto Project
 team's Yocto Linux kernel development strategy. It is the Yocto Project
 team's policy to not back-port minor features to the released Yocto
 Linux kernel. They only consider back-porting significant technological
-jumps - and, that is done after a complete gap analysis. The reason
+jumps --- and, that is done after a complete gap analysis. The reason
 for this policy is that back-porting any small to medium sized change
 from an evolving Linux kernel can easily create mismatches,
 incompatibilities and very subtle errors.

documentation/kernel-dev/intro.rst

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

documentation/migration-guides/migration-1.5.rst

@@ -26,8 +26,7 @@ provide packages for these, you can install and use the Buildtools
 tarball, which provides an SDK-like environment containing them.
 
 For more information on this requirement, see the
-":ref:`ref-manual/system-requirements:required git, tar, python and gcc versions`"
-section.
+":ref:`system-requirements-buildtools`" section.
 
 .. _migration-1.5-atom-pc-bsp:
 
@@ -240,19 +239,19 @@ Automated Image Testing
 -----------------------
 
 A new automated image testing framework has been added through the
-:ref:`ref-classes-testimage*` classes. This
+:ref:`ref-classes-testimage` classes. This
 framework replaces the older ``imagetest-qemu`` framework.
 
 You can learn more about performing automated image tests in the
-":ref:`dev-manual/runtime-testing:performing automated runtime testing`"
-section in the Yocto Project Development Tasks Manual.
+":ref:`test-manual/runtime-testing:performing automated runtime testing`"
+section in the Yocto Project Test Environment Manual.
 
 .. _migration-1.5-build-history:
 
 Build History
 -------------
 
-Following are changes to Build History:
+The changes to Build History are:
 
 -  Installed package sizes: ``installed-package-sizes.txt`` for an image
    now records the size of the files installed by each package instead
@@ -275,7 +274,7 @@ section in the Yocto Project Development Tasks Manual.
 ``udev``
 --------
 
-Following are changes to ``udev``:
+The changes to ``udev`` are:
 
 -  ``udev`` no longer brings in ``udev-extraconf`` automatically through
    :term:`RRECOMMENDS`, since this was originally
@@ -319,7 +318,7 @@ Removed and Renamed Recipes
 Other Changes
 -------------
 
-Following is a list of short entries describing other changes:
+Here is a list of short entries describing other changes:
 
 -  ``run-postinsts``: Make this generic.
 

documentation/migration-guides/migration-1.6.rst

@@ -220,7 +220,7 @@ Package Test (ptest)
 
 Package Tests (ptest) are built but not installed by default. For
 information on using Package Tests, see the
-":ref:`dev-manual/packages:testing packages with ptest`"
+":ref:`test-manual/ptest:testing packages with ptest`"
 section in the Yocto Project Development Tasks Manual. For information on the
 ``ptest`` class, see the ":ref:`ref-classes-ptest`" section.
 
@@ -341,39 +341,39 @@ Removed and Renamed Recipes
 
 The following recipes have been removed:
 
--  ``packagegroup-toolset-native`` - This recipe is largely unused.
+-  ``packagegroup-toolset-native`` --- this recipe is largely unused.
 
--  ``linux-yocto-3.8`` - Support for the Linux yocto 3.8 kernel has been
+-  ``linux-yocto-3.8`` --- support for the Linux yocto 3.8 kernel has been
    dropped. Support for the 3.10 and 3.14 kernels have been added with
    the ``linux-yocto-3.10`` and ``linux-yocto-3.14`` recipes.
 
--  ``ocf-linux`` - This recipe has been functionally replaced using
+-  ``ocf-linux`` --- this recipe has been functionally replaced using
    ``cryptodev-linux``.
 
--  ``genext2fs`` - ``genext2fs`` is no longer used by the build system
+-  ``genext2fs`` --- ``genext2fs`` is no longer used by the build system
    and is unmaintained upstream.
 
--  ``js`` - This provided an ancient version of Mozilla's javascript
+-  ``js`` --- this provided an ancient version of Mozilla's javascript
    engine that is no longer needed.
 
--  ``zaurusd`` - The recipe has been moved to the ``meta-handheld``
+-  ``zaurusd`` --- the recipe has been moved to the ``meta-handheld``
    layer.
 
--  ``eglibc 2.17`` - Replaced by the ``eglibc 2.19`` recipe.
+-  ``eglibc 2.17`` --- replaced by the ``eglibc 2.19`` recipe.
 
--  ``gcc 4.7.2`` - Replaced by the now stable ``gcc 4.8.2``.
+-  ``gcc 4.7.2`` --- replaced by the now stable ``gcc 4.8.2``.
 
--  ``external-sourcery-toolchain`` - this recipe is now maintained in
+-  ``external-sourcery-toolchain`` --- this recipe is now maintained in
    the ``meta-sourcery`` layer.
 
--  ``linux-libc-headers-yocto 3.4+git`` - Now using version 3.10 of the
+-  ``linux-libc-headers-yocto 3.4+git`` --- now using version 3.10 of the
    ``linux-libc-headers`` by default.
 
--  ``meta-toolchain-gmae`` - This recipe is obsolete.
+-  ``meta-toolchain-gmae`` --- this recipe is obsolete.
 
--  ``packagegroup-core-sdk-gmae`` - This recipe is obsolete.
+-  ``packagegroup-core-sdk-gmae`` --- this recipe is obsolete.
 
--  ``packagegroup-core-standalone-gmae-sdk-target`` - This recipe is
+-  ``packagegroup-core-standalone-gmae-sdk-target`` --- this recipe is
    obsolete.
 
 .. _migration-1.6-removed-classes:

documentation/migration-guides/migration-1.7.rst

@@ -30,8 +30,8 @@ version required on the
 build host is now 1.7.8 because the ``--list`` option is now required by
 BitBake's Git fetcher. As always, if your host distribution does not
 provide a version of Git that meets this requirement, you can use the
-``buildtools-tarball`` that does. See the
-":ref:`ref-manual/system-requirements:required git, tar, python and gcc versions`"
+:term:`buildtools` tarball that does. See the
+":ref:`ref-manual/system-requirements:required git, tar, python, make and gcc versions`"
 section for more information.
 
 .. _migration-1.7-autotools-class-changes:

documentation/migration-guides/migration-2.1.rst

@@ -356,9 +356,9 @@ These additional changes exist:
 
 -  The minimum Git version has been increased to 1.8.3.1. If your host
    distribution does not provide a sufficiently recent version, you can
-   install the buildtools, which will provide it. See the
-   :ref:`ref-manual/system-requirements:required git, tar, python and gcc versions`
-   section for more information on the buildtools tarball.
+   install the :term:`buildtools`, which will provide it. See the
+   :ref:`ref-manual/system-requirements:required git, tar, python, make and gcc versions`
+   section for more information on the :term:`buildtools` tarball.
 
 -  The buggy and incomplete support for the RPM version 4 package
    manager has been removed. The well-tested and maintained support for

documentation/migration-guides/migration-2.2.rst

@@ -27,7 +27,7 @@ Staging Directories in Sysroot Has Been Simplified
 The way directories are staged in sysroot has been simplified and
 introduces the new :term:`SYSROOT_DIRS`,
 :term:`SYSROOT_DIRS_NATIVE`, and ``SYSROOT_DIRS_BLACKLIST``
-(replaced by :term:`SYSROOT_DIRS_IGNORE` in version 3.5). See the
+(replaced by :term:`SYSROOT_DIRS_IGNORE` in version 4.0). See the
 :oe_lists:`v2 patch series on the OE-Core Mailing List
 </pipermail/openembedded-core/2016-May/121365.html>`
 for additional information.
@@ -70,9 +70,9 @@ Metadata Must Now Use Python 3 Syntax
 
 The metadata is now required to use Python 3 syntax. For help preparing
 metadata, see any of the many Python 3 porting guides available.
-Alternatively, you can reference the conversion commits for Bitbake and
-you can use :term:`OpenEmbedded-Core (OE-Core)` as a guide for changes. Following are
-particular areas of interest:
+Alternatively, you can reference the conversion commits for BitBake and
+you can use :term:`OpenEmbedded-Core (OE-Core)` as a guide for changes.
+Particular areas of interest are:
 
   - subprocess command-line pipes needing locale decoding
 
@@ -103,7 +103,7 @@ online package-manager support through SMART still require Python 2.
 ``buildtools-tarball`` Includes Python 3
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-``buildtools-tarball`` now includes Python 3.
+The :term:`buildtools` tarball now includes Python 3.
 
 .. _migration-2.2-uclibc-replaced-by-musl:
 
@@ -181,14 +181,8 @@ root filesystem, provides an image, and uses the ``nographic`` option::
 
    $ runqemu qemux86-64 tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.ext4 tmp/deploy/images/qemux86-64/bzImage nographic
 
-Following is a list of variables that can be set in configuration files
-such as ``bsp.conf`` to enable the BSP to be booted by ``runqemu``:
-
-.. note::
-
-   "QB" means "QEMU Boot".
-
-::
+Here is a list of variables that can be set in configuration files
+such as ``bsp.conf`` to enable the BSP to be booted by ``runqemu``::
 
    QB_SYSTEM_NAME: QEMU name (e.g. "qemu-system-i386")
    QB_OPT_APPEND: Options to append to QEMU (e.g. "-show-cursor")
@@ -442,7 +436,7 @@ The following miscellaneous changes have occurred:
 -  :ref:`ref-classes-image`: Renamed COMPRESS(ION) to CONVERSION. This change
    means that ``COMPRESSIONTYPES``, ``COMPRESS_DEPENDS`` and
    ``COMPRESS_CMD`` are deprecated in favor of ``CONVERSIONTYPES``,
-   ``CONVERSION_DEPENDS`` and ``CONVERSION_CMD``. The ``COMPRESS*``
+   ``CONVERSION_DEPENDS`` and :term:`CONVERSION_CMD`. The ``COMPRESS*``
    variable names will still work in the 2.2 release but metadata that
    does not need to be backwards-compatible should be changed to use the
    new names as the ``COMPRESS*`` ones will be removed in a future

documentation/migration-guides/migration-2.4.rst

@@ -89,8 +89,6 @@ occurred:
 Removed Recipes
 ---------------
 
-The following recipes have been removed:
-
 -  ``acpitests``: This recipe is not maintained.
 
 -  ``autogen-native``: No longer required by Grub, oe-core, or
@@ -213,8 +211,6 @@ recipes you might have. This will avoid breakage in post 2.4 releases.
 Package QA Changes
 ------------------
 
-The following package QA changes took place:
-
 -  The "unsafe-references-in-scripts" QA check has been removed.
 
 -  If you refer to ``${COREBASE}/LICENSE`` within
@@ -229,8 +225,6 @@ The following package QA changes took place:
 ``README`` File Changes
 -----------------------
 
-The following are changes to ``README`` files:
-
 -  The main Poky ``README`` file has been moved to the ``meta-poky``
    layer and has been renamed ``README.poky``. A symlink has been
    created so that references to the old location work.
@@ -246,8 +240,6 @@ The following are changes to ``README`` files:
 Miscellaneous Changes
 ---------------------
 
-The following are additional changes:
-
 -  The ``ROOTFS_PKGMANAGE_BOOTSTRAP`` variable and any references to it
    have been removed. You should remove this variable from any custom
    recipes.
@@ -301,7 +293,7 @@ The following are additional changes:
    likely be removed in the next Yocto Project release.
 
 -  The ``vmdk``, ``vdi``, and ``qcow2`` image file types are now used in
-   conjunction with the "wic" image type through ``CONVERSION_CMD``.
+   conjunction with the "wic" image type through :term:`CONVERSION_CMD`.
    Consequently, the equivalent image types are now ``wic.vmdk``,
    ``wic.vdi``, and ``wic.qcow2``, respectively.
 

documentation/migration-guides/migration-2.5.rst

@@ -85,8 +85,6 @@ The following recipes have been removed:
 Scripts and Tools Changes
 -------------------------
 
-The following are changes to scripts and tools:
-
 -  ``yocto-bsp``, ``yocto-kernel``, and ``yocto-layer``: The
    ``yocto-bsp``, ``yocto-kernel``, and ``yocto-layer`` scripts
    previously shipped with poky but not in OpenEmbedded-Core have been
@@ -117,8 +115,6 @@ The following are changes to scripts and tools:
 BitBake Changes
 ---------------
 
-The following are BitBake changes:
-
 -  The ``--runall`` option has changed. There are two different
    behaviors people might want:
 
@@ -151,7 +147,7 @@ The following are BitBake changes:
 Python and Python 3 Changes
 ---------------------------
 
-The following are auto-packaging changes to Python and Python 3:
+Here are auto-packaging changes to Python and Python 3:
 
 The script-managed ``python-*-manifest.inc`` files that were previously
 used to generate Python and Python 3 packages have been replaced with a
@@ -185,8 +181,6 @@ change please see :yocto_git:`this commit
 Miscellaneous Changes
 ---------------------
 
-The following are additional changes:
-
 -  The :ref:`kernel <ref-classes-kernel>` class supports building packages for multiple kernels.
    If your kernel recipe or ``.bbappend`` file mentions packaging at
    all, you should replace references to the kernel in package names

documentation/migration-guides/migration-2.6.rst

@@ -319,7 +319,7 @@ This section provides information about automatic testing changes:
    practices now dictate that you use the
    :term:`IMAGE_CLASSES` variable rather than the
    :term:`INHERIT` variable when you inherit the
-   :ref:`testimage <ref-classes-testimage*>` and
+   :ref:`testimage <ref-classes-testimage>` and
    :ref:`testsdk <ref-classes-testsdk>` classes used for automatic
    testing.
 

documentation/migration-guides/migration-3.0.rst

@@ -148,7 +148,7 @@ XML feeds that ``cve-check-tool`` was using, supports CVSSv3 scoring,
 and makes other improvements.
 
 Additionally, the ``CVE_CHECK_CVE_WHITELIST`` variable has been replaced
-by ``CVE_CHECK_WHITELIST`` (replaced by :term:`CVE_CHECK_IGNORE` in version 3.5).
+by ``CVE_CHECK_WHITELIST`` (replaced by :term:`CVE_CHECK_IGNORE` in version 4.0).
 
 .. _migration-3.0-bitbake-changes:
 
@@ -216,11 +216,11 @@ The following sanity check changes occurred.
 -  :term:`SRC_URI` is now checked for usage of two
    problematic items:
 
-   -  "${PN}" prefix/suffix use - Warnings always appear if ${PN} is
+   -  "${PN}" prefix/suffix use --- warnings always appear if ${PN} is
       used. You must fix the issue regardless of whether multiconfig or
       anything else that would cause prefixing/suffixing to happen.
 
-   -  Github archive tarballs - these are not guaranteed to be stable.
+   -  Github archive tarballs --- these are not guaranteed to be stable.
       Consequently, it is likely that the tarballs will be refreshed and
       thus the SRC_URI checksums will fail to apply. It is recommended
       that you fetch either an official release tarball or a specific

documentation/migration-guides/migration-3.1.rst

@@ -200,7 +200,7 @@ Packaging changes
 -----------------
 
 -  ``intltool`` has been removed from ``packagegroup-core-sdk`` as it is
-   rarely needed to build modern software - gettext can do most of the
+   rarely needed to build modern software --- gettext can do most of the
    things it used to be needed for. ``intltool`` has also been removed
    from ``packagegroup-core-self-hosted`` as it is not needed to for
    standard builds.

documentation/migration-guides/migration-3.2.rst

@@ -11,7 +11,7 @@ Minimum system requirements
 
 ``gcc`` version 6.0 is now required at minimum on the build host. For older
 host distributions where this is not available, you can use the
-``buildtools-extended-tarball`` (easily installable using
+:term:`buildtools-extended` tarball (easily installable using
 ``scripts/install-buildtools``).
 
 
@@ -23,7 +23,7 @@ Removed recipes
 The following recipes have been removed:
 
 - ``bjam-native``: replaced by ``boost-build-native``
-- ``avahi-ui``: folded into the main ``avahi`` recipe - the GTK UI can be disabled using :term:`PACKAGECONFIG` for ``avahi``.
+- ``avahi-ui``: folded into the main ``avahi`` recipe --- the GTK UI can be disabled using :term:`PACKAGECONFIG` for ``avahi``.
 - ``build-compare``: no longer needed with the removal of the ``packagefeed-stability`` class
 - ``dhcp``: obsolete, functionally replaced by ``dhcpcd`` and ``kea``
 - ``libmodulemd-v1``: replaced by ``libmodulemd``
@@ -37,7 +37,7 @@ Removed classes
 
 The following classes (.bbclass files) have been removed:
 
--  ``spdx``: obsolete - the Yocto Project is a strong supporter of SPDX, but this class was old code using a dated approach and had the potential to be misleading. The ``meta-sdpxscanner`` layer is a much more modern and active approach to handling this and is recommended as a replacement.
+-  ``spdx``: obsolete --- the Yocto Project is a strong supporter of SPDX, but this class was old code using a dated approach and had the potential to be misleading. The ``meta-sdpxscanner`` layer is a much more modern and active approach to handling this and is recommended as a replacement.
 
 - ``packagefeed-stability``: this class had become obsolete with the advent of hash equivalence and reproducible builds.
 
@@ -46,7 +46,7 @@ pseudo path filtering and mismatch behaviour
 --------------------------------------------
 
 pseudo now operates on a filtered subset of files. This is a significant change
-to the way pseudo operates within OpenEmbedded - by default, pseudo monitors and
+to the way pseudo operates within OpenEmbedded --- by default, pseudo monitors and
 logs (adds to its database) any file created or modified whilst in a ``fakeroot``
 environment. However, there are large numbers of files that we simply don't care
 about the permissions of whilst in that ``fakeroot`` context, for example ${:term:`S`}, ${:term:`B`}, ${:term:`T`},
@@ -68,7 +68,7 @@ structure above that subdirectory. For these types of cases in your own recipes,
 extend :term:`PSEUDO_IGNORE_PATHS` to cover additional paths that pseudo should not
 be monitoring.
 
-In addition, pseudo's behaviour on mismatches has now been changed - rather
+In addition, pseudo's behaviour on mismatches has now been changed --- rather
 than doing what turns out to be a rather dangerous "fixup" if it sees a file
 with a different path but the same inode as another file it has previously seen,
 pseudo will throw an ``abort()`` and direct you to a :yocto_wiki:`wiki page </Pseudo_Abort>`
@@ -137,10 +137,10 @@ DHCP server/client replaced
 
 The ``dhcp`` software package has become unmaintained and thus has been
 functionally replaced by ``dhcpcd`` (client) and ``kea`` (server). You will
-need to replace references to the recipe/package names as appropriate - most
+need to replace references to the recipe/package names as appropriate --- most
 commonly, at the package level ``dhcp-client`` should be replaced by
 ``dhcpcd`` and ``dhcp-server`` should be replaced by ``kea``. If you have any
-custom configuration files for these they will need to be adapted - refer to
+custom configuration files for these they will need to be adapted --- refer to
 the upstream documentation for ``dhcpcd`` and ``kea`` for further details.
 
 
@@ -181,7 +181,7 @@ In addition, the following new checks were added and default to triggering an er
 
 - :ref:`missing-update-alternatives <qa-check-missing-update-alternatives>`: Check if the recipe sets the :term:`ALTERNATIVE` variable for any of its packages, and does not inherit the :ref:`update-alternatives <ref-classes-update-alternatives>` class.
 
-- A trailing slash or duplicated slashes in the value of :term:`S` or :term:`B` will now trigger a warning so that they can be removed and path comparisons can be more reliable - remove any instances of these in your recipes if the warning is displayed.
+- A trailing slash or duplicated slashes in the value of :term:`S` or :term:`B` will now trigger a warning so that they can be removed and path comparisons can be more reliable --- remove any instances of these in your recipes if the warning is displayed.
 
 
 .. _migration-3.2-src-uri-file-globbing:
@@ -209,7 +209,7 @@ deploy class now cleans ``DEPLOYDIR`` before ``do_deploy``
 
 ``do_deploy`` as implemented in the :ref:`deploy <ref-classes-deploy>` class now cleans up ${:term:`DEPLOYDIR`} before running, just as ``do_install`` cleans up ${:term:`D`} before running. This reduces the risk of :term:`DEPLOYDIR` being accidentally contaminated by files from previous runs, possibly even with different config, in case of incremental builds.
 
-Most recipes and classes that inherit the :ref:`deploy <ref-classes-deploy>` class or interact with ``do_deploy`` are unlikely to be affected by this unless they add ``prefuncs`` to ``do_deploy`` *which also* put files into ``${DEPLOYDIR}`` - these should be refactored to use ``do_deploy_prepend`` instead.
+Most recipes and classes that inherit the :ref:`deploy <ref-classes-deploy>` class or interact with ``do_deploy`` are unlikely to be affected by this unless they add ``prefuncs`` to ``do_deploy`` *which also* put files into ``${DEPLOYDIR}`` --- these should be refactored to use ``do_deploy_prepend`` instead.
 
 
 .. _migration-3.2-nativesdk-sdk-provides-dummy:
@@ -303,7 +303,7 @@ now need to be changed to ``inherit image-artifact-names``.
 Miscellaneous changes
 ---------------------
 
-- Support for the long-deprecated ``PACKAGE_GROUP`` variable has now been removed - replace any remaining instances with :term:`FEATURE_PACKAGES`.
+- Support for the long-deprecated ``PACKAGE_GROUP`` variable has now been removed --- replace any remaining instances with :term:`FEATURE_PACKAGES`.
 - The ``FILESPATHPKG`` variable, having been previously deprecated, has now been removed. Replace any remaining references with appropriate use of :term:`FILESEXTRAPATHS`.
 - Erroneous use of ``inherit +=`` (instead of ``INHERIT +=``) in a configuration file now triggers an error instead of silently being ignored.
 - ptest support has been removed from the ``kbd`` recipe, as upstream has moved to autotest which is difficult to work with in a cross-compilation environment.

documentation/migration-guides/migration-3.3.rst

@@ -12,12 +12,11 @@ Minimum system requirements
 
 You will now need at least Python 3.6 installed on your build host. Most recent
 distributions provide this, but should you be building on a distribution that
-does not have it, you can use the ``buildtools-tarball`` (easily installable
-using ``scripts/install-buildtools``) - see
-:ref:`ref-manual/system-requirements:required git, tar, python and gcc versions`
+does not have it, you can use the :term:`buildtools` tarball (easily installable
+using ``scripts/install-buildtools``) --- see
+:ref:`ref-manual/system-requirements:required git, tar, python, make and gcc versions`
 for details.
 
-
 .. _migration-3.3-removed-recipes:
 
 Removed recipes

documentation/migration-guides/migration-3.4.rst

@@ -93,7 +93,7 @@ The ``lz4c``, ``pzstd`` and ``zstd`` commands are now required to be
 installed on the build host to support LZ4 and Zstandard compression
 functionality. These are typically provided by ``lz4`` and ``zstd``
 packages in most Linux distributions. Alternatively they are available
-as part of ``buildtools-tarball`` if your distribution does not provide
+as part of :term:`buildtools` tarball if your distribution does not provide
 them. For more information see
 :ref:`ref-manual/system-requirements:required packages for the build host`.
 
@@ -146,7 +146,7 @@ Virtual runtime provides
 ~~~~~~~~~~~~~~~~~~~~~~~~
 
 Recipes shouldn't use the ``virtual/`` string in :term:`RPROVIDES` and
-:term:`RDEPENDS` - it is confusing because ``virtual/`` has no special
+:term:`RDEPENDS` --- it is confusing because ``virtual/`` has no special
 meaning in :term:`RPROVIDES` and :term:`RDEPENDS` (unlike in the
 corresponding build-time :term:`PROVIDES` and :term:`DEPENDS`).
 
@@ -171,7 +171,7 @@ Extensible SDK host extension
 For a normal SDK, some layers append to :term:`TOOLCHAIN_HOST_TASK`
 unconditionally which is fine, until the eSDK tries to override the
 variable to its own values. Instead of installing packages specified
-in this variable it uses native recipes instead - a very different
+in this variable it uses native recipes instead --- a very different
 approach. This has led to confusing errors when binaries are added
 to the SDK but not relocated.
 
@@ -252,8 +252,8 @@ Miscellaneous
 
 - The previously deprecated ``COMPRESS_CMD`` and
   ``CVE_CHECK_CVE_WHITELIST`` variables have been removed. Use
-  ``CONVERSION_CMD`` and ``CVE_CHECK_WHITELIST`` (replaced by
-  :term:`CVE_CHECK_IGNORE` in version 3.5) respectively
+  :term:`CONVERSION_CMD` and ``CVE_CHECK_WHITELIST`` (replaced by
+  :term:`CVE_CHECK_IGNORE` in version 4.0) respectively
   instead.
 
 - The obsolete ``oe_machinstall`` function previously provided in the

documentation/migration-guides/migration-4.0.rst

@@ -66,7 +66,7 @@ changes and you need to review them before committing. An example warning
 looks like::
 
     poky/scripts/lib/devtool/upgrade.py needs further work at line 275 since it contains abort
-    
+
 Fetching changes
 ~~~~~~~~~~~~~~~~
 
@@ -109,7 +109,7 @@ License changes
   If they do not, by default a warning will be shown. A
   :oe_git:`convert-spdx-licenses.py </openembedded-core/tree/scripts/contrib/convert-spdx-licenses.py>`
   script can be used to update your recipes.
-  
+
 - :term:`INCOMPATIBLE_LICENSE` should now use `SPDX identifiers <https://spdx.org/licenses/>`__.
   Additionally, wildcarding is now limited to specifically supported values -
   see the :term:`INCOMPATIBLE_LICENSE` documentation for further information.
@@ -119,7 +119,7 @@ License changes
   which can cause signature issues for users. In addition the ``available_licenses()``
   function has been removed from the :ref:`license <ref-classes-license>` class as
   it is no longer needed.
-  
+
 Removed recipes
 ~~~~~~~~~~~~~~~
 
@@ -134,16 +134,16 @@ The following recipes have been removed in this release:
 
 Python changes
 ~~~~~~~~~~~~~~
-     
+
 - ``distutils`` has been deprecated upstream in Python 3.10 and thus the ``distutils*``
   classes have been moved to ``meta-python``. Recipes that inherit the ``distutils*``
   classes should be updated to inherit ``setuptools*`` equivalents instead.
-  
+
 - The Python package build process is now based on `wheels <https://pythonwheels.com/>`__.
-  Here are the new Python packaging classes that should be used:
+  The new Python packaging classes that should be used are
   :ref:`python_flit_core <ref-classes-python_flit_core>`,
   :ref:`python_setuptools_build_meta <ref-classes-python_setuptools_build_meta>`
-  and :ref:`python_poetry_core <ref-classes-python_poetry_core>`.  
+  and :ref:`python_poetry_core <ref-classes-python_poetry_core>`.
 
 - The :ref:`setuptools3 <ref-classes-setuptools3>` class ``do_install()`` task now
   installs the ``wheel`` binary archive. In current versions of ``setuptools`` the
@@ -158,7 +158,7 @@ Prelink removed
 Prelink has been dropped by ``glibc`` upstream in 2.36. It already caused issues with
 binary corruption, has a number of open bugs and is of questionable benefit
 without disabling load address randomization and PIE executables.
-    
+
 We disabled prelinking by default in the honister (3.4) release, but left it able
 to be enabled if desired. However, without glibc support it cannot be maintained
 any further, so all of the prelinking functionality has been removed in this release.
@@ -169,7 +169,7 @@ reference(s).
 Reproducible as standard
 ~~~~~~~~~~~~~~~~~~~~~~~~
 
-Reproducibility is now considered as standard functionality, thus the 
+Reproducibility is now considered as standard functionality, thus the
 ``reproducible`` class has been removed and its previous contents merged into the
 :ref:`base <ref-classes-base>` class. If you have references in your configuration to
 ``reproducible`` in :term:`INHERIT`, :term:`USER_CLASSES` etc. then they should be
@@ -189,7 +189,7 @@ Supported host distribution changes
 
 - ``gcc`` version 7.5 is now required at minimum on the build host. For older
   host distributions where this is not available, you can use the
-  ``buildtools-extended-tarball`` (easily installable using
+  :term:`buildtools-extended` tarball (easily installable using
   ``scripts/install-buildtools``).
 
 :append/:prepend in combination with other operators
@@ -211,7 +211,7 @@ and :ref:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata:removal (over
 
 Miscellaneous changes
 ~~~~~~~~~~~~~~~~~~~~~
-  
+
 - ``blacklist.bbclass`` is removed and the functionality moved to the
   :ref:`base <ref-classes-base>` class with a more descriptive
   ``varflag`` variable named :term:`SKIP_RECIPE` which will use the `bb.parse.SkipRecipe()`
@@ -251,7 +251,7 @@ Miscellaneous changes
 - The ``cortexa72-crc`` and ``cortexa72-crc-crypto`` tunes have been removed since
   the crc extension is now enabled by default for cortexa72. Replace any references to
   these with ``cortexa72`` and ``cortexa72-crypto`` respectively.
-  
+
 - The Python development shell (previously known as ``devpyshell``) feature has been
   renamed to ``pydevshell``. To start it you should now run::
 
@@ -260,7 +260,7 @@ Miscellaneous changes
 - The ``packagegroups-core-full-cmdline-libs`` packagegroup is no longer produced, as
   libraries should normally be brought in via dependencies. If you have any references
   to this then remove them.
-  
+
 - The :term:`TOPDIR` variable and the current working directory are no longer modified
   when parsing recipes. Any code depending on the previous behaviour will no longer
   work - change any such code to explicitly use appropriate path variables instead.

documentation/migration-guides/release-4.0.rst

@@ -20,3 +20,22 @@ Release 4.0 (kirkstone)
    release-notes-4.0.11
    release-notes-4.0.12
    release-notes-4.0.13
+   release-notes-4.0.14
+   release-notes-4.0.15
+   release-notes-4.0.16
+   release-notes-4.0.17
+   release-notes-4.0.18
+   release-notes-4.0.19
+   release-notes-4.0.20
+   release-notes-4.0.21
+   release-notes-4.0.22
+   release-notes-4.0.23
+   release-notes-4.0.24
+   release-notes-4.0.25
+   release-notes-4.0.26
+   release-notes-4.0.27
+   release-notes-4.0.28
+   release-notes-4.0.29
+   release-notes-4.0.30
+   release-notes-4.0.31
+   release-notes-4.0.32

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

@@ -9,14 +9,14 @@ Known Issues in 3.4.1
 Security Fixes in 3.4.1
 ~~~~~~~~~~~~~~~~~~~~~~~
 
--  glibc: Backport fix for :cve:`2021-43396`
--  vim: add patch number to :cve:`2021-3778` patch
--  vim: fix :cve:`2021-3796`, :cve:`2021-3872`, and :cve:`2021-3875`
--  squashfs-tools: follow-up fix for :cve:`2021-41072`
+-  glibc: Backport fix for :cve_nist:`2021-43396`
+-  vim: add patch number to :cve_nist:`2021-3778` patch
+-  vim: fix :cve_nist:`2021-3796`, :cve_nist:`2021-3872`, and :cve_nist:`2021-3875`
+-  squashfs-tools: follow-up fix for :cve_nist:`2021-41072`
 -  avahi: update CVE id fixed by local-ping.patch
--  squashfs-tools: fix :cve:`2021-41072`
--  ffmpeg: fix :cve:`2021-38114`
--  curl: fix :cve:`2021-22945`, :cve:`2021-22946` and :cve:`2021-22947`
+-  squashfs-tools: fix :cve_nist:`2021-41072`
+-  ffmpeg: fix :cve_nist:`2021-38114`
+-  curl: fix :cve_nist:`2021-22945`, :cve_nist:`2021-22946` and :cve_nist:`2021-22947`
 
 Fixes in 3.4.1
 ~~~~~~~~~~~~~~

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

@@ -4,29 +4,29 @@ Release notes for 3.4.2 (honister)
 Security Fixes in 3.4.2
 ~~~~~~~~~~~~~~~~~~~~~~~
 
--  tiff: backport fix for :cve:`2022-22844`
--  glibc : Fix :cve:`2021-3999`
--  glibc : Fix :cve:`2021-3998`
--  glibc : Fix :cve:`2022-23219`
--  glibc : Fix :cve:`2022-23218`
--  lighttpd: backport a fix for :cve:`2022-22707`
--  speex: fix :cve:`2020-23903`
--  linux-yocto/5.10: amdgpu: updates for :cve:`2021-42327`
--  libsndfile1: fix :cve:`2021-4156`
+-  tiff: backport fix for :cve_nist:`2022-22844`
+-  glibc : Fix :cve_nist:`2021-3999`
+-  glibc : Fix :cve_nist:`2021-3998`
+-  glibc : Fix :cve_nist:`2022-23219`
+-  glibc : Fix :cve_nist:`2022-23218`
+-  lighttpd: backport a fix for :cve_nist:`2022-22707`
+-  speex: fix :cve_nist:`2020-23903`
+-  linux-yocto/5.10: amdgpu: updates for :cve_nist:`2021-42327`
+-  libsndfile1: fix :cve_nist:`2021-4156`
 -  xserver-xorg: whitelist two CVEs
--  grub2: fix :cve:`2021-3981`
--  xserver-xorg: update CVE_PRODUCT
--  binutils: :cve:`2021-42574`
--  gcc: Fix :cve:`2021-42574`
--  gcc: Fix :cve:`2021-35465`
+-  grub2: fix :cve_nist:`2021-3981`
+-  xserver-xorg: update :term:`CVE_PRODUCT`
+-  binutils: :cve_nist:`2021-42574`
+-  gcc: Fix :cve_nist:`2021-42574`
+-  gcc: Fix :cve_nist:`2021-35465`
 -  cve-extra-exclusions: add db CVEs to exclusion list
--  gcc: Add :cve:`2021-37322` to the list of CVEs to ignore
--  bind: fix :cve:`2021-25219`
--  openssh: fix :cve:`2021-41617`
--  ncurses: fix :cve:`2021-39537`
--  vim: fix :cve:`2021-3968` and :cve:`2021-3973`
--  vim: fix :cve:`2021-3927` and :cve:`2021-3928`
--  gmp: fix :cve:`2021-43618`
+-  gcc: Add :cve_nist:`2021-37322` to the list of CVEs to ignore
+-  bind: fix :cve_nist:`2021-25219`
+-  openssh: fix :cve_nist:`2021-41617`
+-  ncurses: fix :cve_nist:`2021-39537`
+-  vim: fix :cve_nist:`2021-3968` and :cve_nist:`2021-3973`
+-  vim: fix :cve_nist:`2021-3927` and :cve_nist:`2021-3928`
+-  gmp: fix :cve_nist:`2021-43618`
 
 Fixes in 3.4.2
 ~~~~~~~~~~~~~~

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

@@ -4,12 +4,12 @@ Release notes for 3.4.3 (honister)
 Security Fixes in 3.4.3
 ~~~~~~~~~~~~~~~~~~~~~~~
 
--  ghostscript: fix :cve:`2021-3781`
--  ghostscript: fix :cve:`2021-45949`
--  tiff: Add backports for two CVEs from upstream (:cve:`2022-0561` & :cve:`2022-0562`)
--  gcc : Fix :cve:`2021-46195`
+-  ghostscript: fix :cve_nist:`2021-3781`
+-  ghostscript: fix :cve_nist:`2021-45949`
+-  tiff: Add backports for two CVEs from upstream (:cve_nist:`2022-0561` & :cve_nist:`2022-0562`)
+-  gcc : Fix :cve_nist:`2021-46195`
 -  virglrenderer: fix `CVE-2022-0135 <https://security-tracker.debian.org/tracker/CVE-2022-0135>`__ and `CVE-2022-0175 <https://security-tracker.debian.org/tracker/CVE-2022-0175>`__
--  binutils: Add fix for :cve:`2021-45078`
+-  binutils: Add fix for :cve_nist:`2021-45078`
 
 
 Fixes in 3.4.3

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

@@ -4,11 +4,11 @@ Release notes for 3.4.4 (honister)
 Security Fixes in 3.4.4
 ~~~~~~~~~~~~~~~~~~~~~~~
 
--  tiff: fix :cve:`2022-0865`, :cve:`2022-0891`, :cve:`2022-0907`, :cve:`2022-0908`, :cve:`2022-0909` and :cve:`2022-0924`
+-  tiff: fix :cve_nist:`2022-0865`, :cve_nist:`2022-0891`, :cve_nist:`2022-0907`, :cve_nist:`2022-0908`, :cve_nist:`2022-0909` and :cve_nist:`2022-0924`
 -  xz: fix `CVE-2022-1271 <https://security-tracker.debian.org/tracker/CVE-2022-1271>`__
 -  unzip: fix `CVE-2021-4217 <https://security-tracker.debian.org/tracker/CVE-2021-4217>`__
--  zlib: fix :cve:`2018-25032`
--  grub: ignore :cve:`2021-46705`
+-  zlib: fix :cve_nist:`2018-25032`
+-  grub: ignore :cve_nist:`2021-46705`
 
 Fixes in 3.4.4
 ~~~~~~~~~~~~~~

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

@@ -5,7 +5,7 @@ New Features / Enhancements in 3.4
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 -  Linux kernel 5.14, glibc 2.34 and ~280 other recipe upgrades
--  Switched override character to ':' (replacing '_') for more robust parsing and improved performance - see the above migration guide for help
+-  Switched override character to ':' (replacing '_') for more robust parsing and improved performance --- see the above migration guide for help
 -  Rust integrated into core, providing rust support for cross-compilation and SDK
 -  New create-spdx class for creating SPDX SBoM documents
 -  New recipes: cargo, core-image-ptest-all, core-image-ptest-fast, core-image-weston-sdk, erofs-utils, gcompat, gi-docgen, libmicrohttpd, libseccomp, libstd-rs, perlcross, python3-markdown, python3-pyyaml, python3-smartypants, python3-typogrify, rust, rust-cross, rust-cross-canadian, rust-hello-world, rust-llvm, rust-tools-cross-canadian, rustfmt, xwayland
@@ -216,34 +216,34 @@ Other license-related notes:
 Security Fixes in 3.4
 ~~~~~~~~~~~~~~~~~~~~~
 
--  apr: :cve:`2021-35940`
--  aspell: :cve:`2019-25051`
--  avahi: :cve:`2021-3468`, :cve:`2021-36217`
--  binutils: :cve:`2021-20197`
--  bluez: :cve:`2021-3658`
--  busybox: :cve:`2021-28831`
--  cairo: :cve:`2020-35492`
--  cpio: :cve:`2021-38185`
--  expat: :cve:`2013-0340`
--  ffmpeg: :cve:`2020-20446`, :cve:`2020-22015`, :cve:`2020-22021`, :cve:`2020-22033`, :cve:`2020-22019`, :cve:`2021-33815`, :cve:`2021-38171`, :cve:`2020-20453`
--  glibc: :cve:`2021-33574`, :cve:`2021-38604`
--  inetutils: :cve:`2021-40491`
--  libgcrypt: :cve:`2021-40528`
--  linux-yocto/5.10, 5.14: :cve:`2021-3653`, :cve:`2021-3656`
--  lz4: :cve:`2021-3520`
--  nettle: :cve:`2021-20305`
--  openssl: :cve:`2021-3711`, :cve:`2021-3712`
--  perl: :cve:`2021-36770`
--  python3: :cve:`2021-29921`
--  python3-pip: :cve:`2021-3572`
--  qemu: :cve:`2020-27821`, :cve:`2020-29443`, :cve:`2020-35517`, :cve:`2021-3392`, :cve:`2021-3409`, :cve:`2021-3416`, :cve:`2021-3527`, :cve:`2021-3544`, :cve:`2021-3545`, :cve:`2021-3546`, :cve:`2021-3682`, :cve:`2021-20181`, :cve:`2021-20221`, :cve:`2021-20257`, :cve:`2021-20263`
--  rpm: :cve:`2021-3421`, :cve:`2021-20271`
--  rsync: :cve:`2020-14387`
--  util-linux: :cve:`2021-37600`
--  vim: :cve:`2021-3770`, :cve:`2021-3778`
--  wpa-supplicant: :cve:`2021-30004`
--  xdg-utils: :cve:`2020-27748`
--  xserver-xorg: :cve:`2021-3472`
+-  apr: :cve_nist:`2021-35940`
+-  aspell: :cve_nist:`2019-25051`
+-  avahi: :cve_nist:`2021-3468`, :cve_nist:`2021-36217`
+-  binutils: :cve_nist:`2021-20197`
+-  bluez: :cve_nist:`2021-3658`
+-  busybox: :cve_nist:`2021-28831`
+-  cairo: :cve_nist:`2020-35492`
+-  cpio: :cve_nist:`2021-38185`
+-  expat: :cve_nist:`2013-0340`
+-  ffmpeg: :cve_nist:`2020-20446`, :cve_nist:`2020-22015`, :cve_nist:`2020-22021`, :cve_nist:`2020-22033`, :cve_nist:`2020-22019`, :cve_nist:`2021-33815`, :cve_nist:`2021-38171`, :cve_nist:`2020-20453`
+-  glibc: :cve_nist:`2021-33574`, :cve_nist:`2021-38604`
+-  inetutils: :cve_nist:`2021-40491`
+-  libgcrypt: :cve_nist:`2021-40528`
+-  linux-yocto/5.10, 5.14: :cve_nist:`2021-3653`, :cve_nist:`2021-3656`
+-  lz4: :cve_nist:`2021-3520`
+-  nettle: :cve_nist:`2021-20305`
+-  openssl: :cve_nist:`2021-3711`, :cve_nist:`2021-3712`
+-  perl: :cve_nist:`2021-36770`
+-  python3: :cve_nist:`2021-29921`
+-  python3-pip: :cve_nist:`2021-3572`
+-  qemu: :cve_nist:`2020-27821`, :cve_nist:`2020-29443`, :cve_nist:`2020-35517`, :cve_nist:`2021-3392`, :cve_nist:`2021-3409`, :cve_nist:`2021-3416`, :cve_nist:`2021-3527`, :cve_nist:`2021-3544`, :cve_nist:`2021-3545`, :cve_nist:`2021-3546`, :cve_nist:`2021-3682`, :cve_nist:`2021-20181`, :cve_nist:`2021-20221`, :cve_nist:`2021-20257`, :cve_nist:`2021-20263`
+-  rpm: :cve_nist:`2021-3421`, :cve_nist:`2021-20271`
+-  rsync: :cve_nist:`2020-14387`
+-  util-linux: :cve_nist:`2021-37600`
+-  vim: :cve_nist:`2021-3770`, :cve_nist:`2021-3778`
+-  wpa-supplicant: :cve_nist:`2021-30004`
+-  xdg-utils: :cve_nist:`2020-27748`
+-  xserver-xorg: :cve_nist:`2021-3472`
 
 Recipe Upgrades in 3.4
 ~~~~~~~~~~~~~~~~~~~~~~

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

@@ -4,11 +4,11 @@ Release notes for 4.0.1 (kirkstone)
 Security Fixes in 4.0.1
 ~~~~~~~~~~~~~~~~~~~~~~~
 
--  linux-yocto/5.15: fix :cve:`2022-28796`
--  python3: ignore :cve:`2015-20107`
--  e2fsprogs: fix :cve:`2022-1304`
--  lua: fix :cve:`2022-28805`
--  busybox: fix :cve:`2022-28391`
+-  linux-yocto/5.15: fix :cve_nist:`2022-28796`
+-  python3: ignore :cve_nist:`2015-20107`
+-  e2fsprogs: fix :cve_nist:`2022-1304`
+-  lua: fix :cve_nist:`2022-28805`
+-  busybox: fix :cve_nist:`2022-28391`
 
 Fixes in 4.0.1
 ~~~~~~~~~~~~~~

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

@@ -6,28 +6,28 @@ Release notes for Yocto-4.0.10 (Kirkstone)
 Security Fixes in Yocto-4.0.10
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
--  binutils: Fix :cve:`2023-1579`, :cve:`2023-1972`, :cve_mitre:`2023-25584`, :cve_mitre:`2023-25585` and :cve_mitre:`2023-25588`
--  cargo : Ignore :cve:`2022-46176`
--  connman: Fix :cve:`2023-28488`
--  curl: Fix :cve:`2023-27533`, :cve:`2023-27534`, :cve:`2023-27535`, :cve:`2023-27536` and :cve:`2023-27538`
--  ffmpeg: Fix :cve:`2022-48434`
--  freetype: Fix :cve:`2023-2004`
+-  binutils: Fix :cve_nist:`2023-1579`, :cve_nist:`2023-1972`, :cve_mitre:`2023-25584`, :cve_mitre:`2023-25585` and :cve_mitre:`2023-25588`
+-  cargo : Ignore :cve_nist:`2022-46176`
+-  connman: Fix :cve_nist:`2023-28488`
+-  curl: Fix :cve_nist:`2023-27533`, :cve_nist:`2023-27534`, :cve_nist:`2023-27535`, :cve_nist:`2023-27536` and :cve_nist:`2023-27538`
+-  ffmpeg: Fix :cve_nist:`2022-48434`
+-  freetype: Fix :cve_nist:`2023-2004`
 -  ghostscript: Fix :cve_mitre:`2023-29979`
--  git: Fix :cve:`2023-25652` and :cve:`2023-29007`
--  go: Fix :cve:`2022-41722`, :cve:`2022-41724`, :cve:`2022-41725`, :cve:`2023-24534`, :cve:`2023-24537` and :cve:`2023-24538`
--  go: Ignore :cve:`2022-41716`
--  libxml2: Fix :cve:`2023-28484` and :cve:`2023-29469`
--  libxpm: Fix :cve:`2022-44617`, :cve:`2022-46285` and :cve:`2022-4883`
--  linux-yocto: Ignore :cve:`2021-3759`, :cve:`2021-4135`, :cve:`2021-4155`, :cve:`2022-0168`, :cve:`2022-0171`, :cve:`2022-1016`, :cve:`2022-1184`, :cve:`2022-1198`, :cve:`2022-1199`, :cve:`2022-1462`, :cve:`2022-1734`, :cve:`2022-1852`, :cve:`2022-1882`, :cve:`2022-1998`, :cve:`2022-2078`, :cve:`2022-2196`, :cve:`2022-2318`, :cve:`2022-2380`, :cve:`2022-2503`, :cve:`2022-26365`, :cve:`2022-2663`, :cve:`2022-2873`, :cve:`2022-2905`, :cve:`2022-2959`, :cve:`2022-3028`, :cve:`2022-3078`, :cve:`2022-3104`, :cve:`2022-3105`, :cve:`2022-3106`, :cve:`2022-3107`, :cve:`2022-3111`, :cve:`2022-3112`, :cve:`2022-3113`, :cve:`2022-3115`, :cve:`2022-3202`, :cve:`2022-32250`, :cve:`2022-32296`, :cve:`2022-32981`, :cve:`2022-3303`, :cve:`2022-33740`, :cve:`2022-33741`, :cve:`2022-33742`, :cve:`2022-33743`, :cve:`2022-33744`, :cve:`2022-33981`, :cve:`2022-3424`, :cve:`2022-3435`, :cve:`2022-34918`, :cve:`2022-3521`, :cve:`2022-3545`, :cve:`2022-3564`, :cve:`2022-3586`, :cve:`2022-3594`, :cve:`2022-36123`, :cve:`2022-3621`, :cve:`2022-3623`, :cve:`2022-3629`, :cve:`2022-3633`, :cve:`2022-3635`, :cve:`2022-3646`, :cve:`2022-3649`, :cve:`2022-36879`, :cve:`2022-36946`, :cve:`2022-3707`, :cve:`2022-39188`, :cve:`2022-39190`, :cve:`2022-39842`, :cve:`2022-40307`, :cve:`2022-40768`, :cve:`2022-4095`, :cve:`2022-41218`, :cve:`2022-4139`, :cve:`2022-41849`, :cve:`2022-41850`, :cve:`2022-41858`, :cve:`2022-42328`, :cve:`2022-42329`, :cve:`2022-42703`, :cve:`2022-42721`, :cve:`2022-42722`, :cve:`2022-42895`, :cve:`2022-4382`, :cve:`2022-4662`, :cve:`2022-47518`, :cve:`2022-47519`, :cve:`2022-47520`, :cve:`2022-47929`, :cve:`2023-0179`, :cve:`2023-0394`, :cve:`2023-0461`, :cve:`2023-0590`, :cve:`2023-1073`, :cve:`2023-1074`, :cve:`2023-1077`, :cve:`2023-1078`, :cve:`2023-1079`, :cve:`2023-1095`, :cve:`2023-1118`, :cve:`2023-1249`, :cve:`2023-1252`, :cve:`2023-1281`, :cve:`2023-1382`, :cve:`2023-1513`, :cve:`2023-1829`, :cve:`2023-1838`, :cve:`2023-1998`, :cve:`2023-2006`, :cve:`2023-2008`, :cve:`2023-2162`, :cve:`2023-2166`, :cve:`2023-2177`, :cve:`2023-22999`, :cve:`2023-23002`, :cve:`2023-23004`, :cve:`2023-23454`, :cve:`2023-23455`, :cve:`2023-23559`, :cve:`2023-25012`, :cve:`2023-26545`, :cve:`2023-28327` and :cve:`2023-28328`
--  nasm: Fix :cve:`2022-44370`
--  python3-cryptography: Fix :cve:`2023-23931`
--  qemu: Ignore :cve:`2023-0664`
--  ruby: Fix :cve:`2023-28755` and :cve:`2023-28756`
--  screen: Fix :cve:`2023-24626`
--  shadow: Fix :cve:`2023-29383`
--  tiff: Fix :cve:`2022-4645`
--  webkitgtk: Fix :cve:`2022-32888` and :cve:`2022-32923`
--  xserver-xorg: Fix :cve:`2023-1393`
+-  git: Fix :cve_nist:`2023-25652` and :cve_nist:`2023-29007`
+-  go: Fix :cve_nist:`2022-41722`, :cve_nist:`2022-41724`, :cve_nist:`2022-41725`, :cve_nist:`2023-24534`, :cve_nist:`2023-24537` and :cve_nist:`2023-24538`
+-  go: Ignore :cve_nist:`2022-41716`
+-  libxml2: Fix :cve_nist:`2023-28484` and :cve_nist:`2023-29469`
+-  libxpm: Fix :cve_nist:`2022-44617`, :cve_nist:`2022-46285` and :cve_nist:`2022-4883`
+-  linux-yocto: Ignore :cve_nist:`2021-3759`, :cve_nist:`2021-4135`, :cve_nist:`2021-4155`, :cve_nist:`2022-0168`, :cve_nist:`2022-0171`, :cve_nist:`2022-1016`, :cve_nist:`2022-1184`, :cve_nist:`2022-1198`, :cve_nist:`2022-1199`, :cve_nist:`2022-1462`, :cve_nist:`2022-1734`, :cve_nist:`2022-1852`, :cve_nist:`2022-1882`, :cve_nist:`2022-1998`, :cve_nist:`2022-2078`, :cve_nist:`2022-2196`, :cve_nist:`2022-2318`, :cve_nist:`2022-2380`, :cve_nist:`2022-2503`, :cve_nist:`2022-26365`, :cve_nist:`2022-2663`, :cve_nist:`2022-2873`, :cve_nist:`2022-2905`, :cve_nist:`2022-2959`, :cve_nist:`2022-3028`, :cve_nist:`2022-3078`, :cve_nist:`2022-3104`, :cve_nist:`2022-3105`, :cve_nist:`2022-3106`, :cve_nist:`2022-3107`, :cve_nist:`2022-3111`, :cve_nist:`2022-3112`, :cve_nist:`2022-3113`, :cve_nist:`2022-3115`, :cve_nist:`2022-3202`, :cve_nist:`2022-32250`, :cve_nist:`2022-32296`, :cve_nist:`2022-32981`, :cve_nist:`2022-3303`, :cve_nist:`2022-33740`, :cve_nist:`2022-33741`, :cve_nist:`2022-33742`, :cve_nist:`2022-33743`, :cve_nist:`2022-33744`, :cve_nist:`2022-33981`, :cve_nist:`2022-3424`, :cve_nist:`2022-3435`, :cve_nist:`2022-34918`, :cve_nist:`2022-3521`, :cve_nist:`2022-3545`, :cve_nist:`2022-3564`, :cve_nist:`2022-3586`, :cve_nist:`2022-3594`, :cve_nist:`2022-36123`, :cve_nist:`2022-3621`, :cve_nist:`2022-3623`, :cve_nist:`2022-3629`, :cve_nist:`2022-3633`, :cve_nist:`2022-3635`, :cve_nist:`2022-3646`, :cve_nist:`2022-3649`, :cve_nist:`2022-36879`, :cve_nist:`2022-36946`, :cve_nist:`2022-3707`, :cve_nist:`2022-39188`, :cve_nist:`2022-39190`, :cve_nist:`2022-39842`, :cve_nist:`2022-40307`, :cve_nist:`2022-40768`, :cve_nist:`2022-4095`, :cve_nist:`2022-41218`, :cve_nist:`2022-4139`, :cve_nist:`2022-41849`, :cve_nist:`2022-41850`, :cve_nist:`2022-41858`, :cve_nist:`2022-42328`, :cve_nist:`2022-42329`, :cve_nist:`2022-42703`, :cve_nist:`2022-42721`, :cve_nist:`2022-42722`, :cve_nist:`2022-42895`, :cve_nist:`2022-4382`, :cve_nist:`2022-4662`, :cve_nist:`2022-47518`, :cve_nist:`2022-47519`, :cve_nist:`2022-47520`, :cve_nist:`2022-47929`, :cve_nist:`2023-0179`, :cve_nist:`2023-0394`, :cve_nist:`2023-0461`, :cve_nist:`2023-0590`, :cve_nist:`2023-1073`, :cve_nist:`2023-1074`, :cve_nist:`2023-1077`, :cve_nist:`2023-1078`, :cve_nist:`2023-1079`, :cve_nist:`2023-1095`, :cve_nist:`2023-1118`, :cve_nist:`2023-1249`, :cve_nist:`2023-1252`, :cve_nist:`2023-1281`, :cve_nist:`2023-1382`, :cve_nist:`2023-1513`, :cve_nist:`2023-1829`, :cve_nist:`2023-1838`, :cve_nist:`2023-1998`, :cve_nist:`2023-2006`, :cve_nist:`2023-2008`, :cve_nist:`2023-2162`, :cve_nist:`2023-2166`, :cve_nist:`2023-2177`, :cve_nist:`2023-22999`, :cve_nist:`2023-23002`, :cve_nist:`2023-23004`, :cve_nist:`2023-23454`, :cve_nist:`2023-23455`, :cve_nist:`2023-23559`, :cve_nist:`2023-25012`, :cve_nist:`2023-26545`, :cve_nist:`2023-28327` and :cve_nist:`2023-28328`
+-  nasm: Fix :cve_nist:`2022-44370`
+-  python3-cryptography: Fix :cve_nist:`2023-23931`
+-  qemu: Ignore :cve_nist:`2023-0664`
+-  ruby: Fix :cve_nist:`2023-28755` and :cve_nist:`2023-28756`
+-  screen: Fix :cve_nist:`2023-24626`
+-  shadow: Fix :cve_nist:`2023-29383`
+-  tiff: Fix :cve_nist:`2022-4645`
+-  webkitgtk: Fix :cve_nist:`2022-32888` and :cve_nist:`2022-32923`
+-  xserver-xorg: Fix :cve_nist:`2023-1393`
 
 
 Fixes in Yocto-4.0.10

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

@@ -6,18 +6,18 @@ Release notes for Yocto-4.0.11 (Kirkstone)
 Security Fixes in Yocto-4.0.11
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
--  cups: Fix :cve:`2023-32324`
--  curl: Fix :cve:`2023-28319`, :cve:`2023-28320`, :cve:`2023-28321` and :cve:`2023-28322`
--  git: Ignore :cve:`2023-25815`
--  go: Fix :cve:`2023-24539` and :cve:`2023-24540`
--  nasm: Fix :cve:`2022-46457`
--  openssh: Fix :cve:`2023-28531`
--  openssl: Fix :cve:`2023-1255` and :cve:`2023-2650`
--  perl: Fix :cve:`2023-31484`
--  python3-requests: Fix for :cve:`2023-32681`
--  sysstat: Fix :cve:`2023-33204`
--  vim: Fix :cve:`2023-2426`
--  webkitgtk: fix :cve:`2022-42867`, :cve:`2022-46691`, :cve:`2022-46699` and :cve:`2022-46700`
+-  cups: Fix :cve_nist:`2023-32324`
+-  curl: Fix :cve_nist:`2023-28319`, :cve_nist:`2023-28320`, :cve_nist:`2023-28321` and :cve_nist:`2023-28322`
+-  git: Ignore :cve_nist:`2023-25815`
+-  go: Fix :cve_nist:`2023-24539` and :cve_nist:`2023-24540`
+-  nasm: Fix :cve_nist:`2022-46457`
+-  openssh: Fix :cve_nist:`2023-28531`
+-  openssl: Fix :cve_nist:`2023-1255` and :cve_nist:`2023-2650`
+-  perl: Fix :cve_nist:`2023-31484`
+-  python3-requests: Fix for :cve_nist:`2023-32681`
+-  sysstat: Fix :cve_nist:`2023-33204`
+-  vim: Fix :cve_nist:`2023-2426`
+-  webkitgtk: fix :cve_nist:`2022-42867`, :cve_nist:`2022-46691`, :cve_nist:`2022-46699` and :cve_nist:`2022-46700`
 
 
 Fixes in Yocto-4.0.11

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

@@ -6,30 +6,30 @@ Release notes for Yocto-4.0.12 (Kirkstone)
 Security Fixes in Yocto-4.0.12
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
--  bind: Fix :cve:`2023-2828` and :cve:`2023-2911`
--  cups: Fix :cve:`2023-34241`
--  curl: Added :cve:`2023-28320` Follow-up patch
--  dbus: Fix :cve:`2023-34969`
--  dmidecode: fix :cve:`2023-30630`
--  ghostscript: fix :cve:`2023-36664`
--  go: fix :cve_mitre:`2023-24531`, :cve:`2023-24536`, :cve:`2023-29400`, :cve:`2023-29402`, :cve:`2023-29404`, :cve:`2023-29405` and :cve:`2023-29406`
--  libarchive: Ignore :cve:`2023-30571`
--  libcap: Fix :cve:`2023-2602` and :cve:`2023-2603`
--  libjpeg-turbo: Fix :cve:`2023-2804`
--  libpcre2: Fix :cve:`2022-41409`
--  libtiff: fix :cve:`2023-26965`
--  libwebp: Fix :cve:`2023-1999`
--  libx11: Fix :cve:`2023-3138`
--  libxpm: Fix :cve:`2022-44617`
--  ninja: Ignore :cve:`2021-4336`
--  openssh: Fix :cve:`2023-38408`
--  openssl: Fix :cve:`2023-2975`, :cve:`2023-3446` and :cve:`2023-3817`
--  perl: Fix :cve:`2023-31486`
--  python3: Ignore :cve:`2023-36632`
--  qemu: Fix :cve:`2023-0330`, :cve_mitre:`2023-2861`, :cve_mitre:`2023-3255` and :cve_mitre:`2023-3301`
--  sqlite3: Fix :cve:`2023-36191`
--  tiff: Fix :cve:`2023-0795`, :cve:`2023-0796`, :cve:`2023-0797`, :cve:`2023-0798`, :cve:`2023-0799`, :cve:`2023-25433`, :cve:`2023-25434` and :cve:`2023-25435`
--  vim: :cve:`2023-2609` and :cve:`2023-2610`
+-  bind: Fix :cve_nist:`2023-2828` and :cve_nist:`2023-2911`
+-  cups: Fix :cve_nist:`2023-34241`
+-  curl: Added :cve_nist:`2023-28320` Follow-up patch
+-  dbus: Fix :cve_nist:`2023-34969`
+-  dmidecode: fix :cve_nist:`2023-30630`
+-  ghostscript: fix :cve_nist:`2023-36664`
+-  go: fix :cve_mitre:`2023-24531`, :cve_nist:`2023-24536`, :cve_nist:`2023-29400`, :cve_nist:`2023-29402`, :cve_nist:`2023-29404`, :cve_nist:`2023-29405` and :cve_nist:`2023-29406`
+-  libarchive: Ignore :cve_nist:`2023-30571`
+-  libcap: Fix :cve_nist:`2023-2602` and :cve_nist:`2023-2603`
+-  libjpeg-turbo: Fix :cve_nist:`2023-2804`
+-  libpcre2: Fix :cve_nist:`2022-41409`
+-  libtiff: fix :cve_nist:`2023-26965`
+-  libwebp: Fix :cve_nist:`2023-1999`
+-  libx11: Fix :cve_nist:`2023-3138`
+-  libxpm: Fix :cve_nist:`2022-44617`
+-  ninja: Ignore :cve_nist:`2021-4336`
+-  openssh: Fix :cve_nist:`2023-38408`
+-  openssl: Fix :cve_nist:`2023-2975`, :cve_nist:`2023-3446` and :cve_nist:`2023-3817`
+-  perl: Fix :cve_nist:`2023-31486`
+-  python3: Ignore :cve_nist:`2023-36632`
+-  qemu: Fix :cve_nist:`2023-0330`, :cve_mitre:`2023-2861`, :cve_mitre:`2023-3255` and :cve_mitre:`2023-3301`
+-  sqlite3: Fix :cve_nist:`2023-36191`
+-  tiff: Fix :cve_nist:`2023-0795`, :cve_nist:`2023-0796`, :cve_nist:`2023-0797`, :cve_nist:`2023-0798`, :cve_nist:`2023-0799`, :cve_nist:`2023-25433`, :cve_nist:`2023-25434` and :cve_nist:`2023-25435`
+-  vim: :cve_nist:`2023-2609` and :cve_nist:`2023-2610`
 
 
 Fixes in Yocto-4.0.12

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

@@ -0,0 +1,189 @@
+.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
+
+Release notes for Yocto-4.0.15 (Kirkstone)
+------------------------------------------
+
+Security Fixes in Yocto-4.0.15
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  avahi: Fix :cve_nist:`2023-1981`, :cve_nist:`2023-38469`, :cve_nist:`2023-38470`, :cve_nist:`2023-38471`, :cve_nist:`2023-38472` and :cve_nist:`2023-38473`
+-  binutils: Fix :cve_nist:`2022-47007`, :cve_nist:`2022-47010` and :cve_nist:`2022-48064`
+-  bluez5: Fix :cve_nist:`2023-45866`
+-  ghostscript: Ignore GhostPCL :cve_nist:`2023-38560`
+-  gnutls: Fix :cve_nist:`2023-5981`
+-  go: Ignore :cve_nist:`2023-45283` and :cve_nist:`2023-45284`
+-  grub: Fix :cve_nist:`2023-4692` and :cve_nist:`2023-4693`
+-  gstreamer1.0-plugins-bad: Fix :cve_mitre:`2023-44429`
+-  libsndfile: Fix :cve_nist:`2022-33065`
+-  libwebp: Fix :cve_nist:`2023-4863`
+-  openssl: Fix :cve_nist:`2023-5678`
+-  python3-cryptography: Fix :cve_nist:`2023-49083`
+-  qemu: Fix :cve_nist:`2023-1544`
+-  sudo: :cve_nist:`2023-42456` and :cve_mitre:`2023-42465`
+-  tiff: Fix :cve_nist:`2023-41175`
+-  vim: Fix :cve_nist:`2023-46246`, :cve_nist:`2023-48231`, :cve_nist:`2023-48232`, :cve_nist:`2023-48233`, :cve_nist:`2023-48234`, :cve_nist:`2023-48235`, :cve_nist:`2023-48236`, :cve_nist:`2023-48237` and :cve_nist:`2023-48706`
+-  xserver-xorg: Fix :cve_nist:`2023-5367` and :cve_nist:`2023-5380`
+-  xwayland: Fix :cve_nist:`2023-5367`
+
+
+Fixes in Yocto-4.0.15
+~~~~~~~~~~~~~~~~~~~~~
+
+-  bash: changes to SIGINT handler while waiting for a child
+-  bitbake: Fix disk space monitoring on cephfs
+-  bitbake: bitbake-getvar: Make --quiet work with --recipe
+-  bitbake: runqueue.py: fix PSI check logic
+-  bitbake: runqueue: Add pressure change logging
+-  bitbake: runqueue: convert deferral messages from bb.note to bb.debug
+-  bitbake: runqueue: fix PSI check calculation
+-  bitbake: runqueue: show more pressure data
+-  bitbake: runqueue: show number of currently running bitbake threads when pressure changes
+-  bitbake: tinfoil: Do not fail when logging is disabled and full config is used
+-  build-appliance-image: Update to kirkstone head revision
+-  cve-check: don't warn if a patch is remote
+-  cve-check: slightly more verbose warning when adding the same package twice
+-  cve-check: sort the package list in the JSON report
+-  cve-exclusion_5.10.inc: update for 5.10.202
+-  go: Fix issue in DNS resolver
+-  goarch: Move Go architecture mapping to a library
+-  gstreamer1.0-plugins-base: enable glx/opengl support
+-  linux-yocto/5.10: update to v5.10.202
+-  manuals: update class references
+-  migration-guide: add release notes for 4.0.14
+-  native: Clear TUNE_FEATURES/ABIEXTENSION
+-  openssh: drop sudo from ptest dependencies
+-  overview-manual: concepts: Add Bitbake Tasks Map
+-  poky.conf: bump version for 4.0.15
+-  python3-jinja2: Fixed ptest result output as per the standard
+-  ref-manual: classes: explain cml1 class name
+-  ref-manual: update :term:`SDK_NAME` variable documentation
+-  ref-manual: variables: add :term:`RECIPE_MAINTAINER`
+-  ref-manual: variables: document OEQA_REPRODUCIBLE_* variables
+-  ref-manual: variables: mention new CDN for :term:`SSTATE_MIRRORS`
+-  rust-common: Set llvm-target correctly for cross SDK targets
+-  rust-cross-canadian: Fix ordering of target json config generation
+-  rust-cross/rust-common: Merge arm target handling code to fix cross-canadian
+-  rust-cross: Simplfy the rust_gen_target calls
+-  rust-llvm: Allow overriding LLVM target archs
+-  sdk-manual: extensible.rst: remove instructions for using SDK functionality directly in a yocto build
+-  sudo: upgrade to 1.9.15p2
+-  systemtap_git: fix used uninitialized error
+-  vim: Improve locale handling
+-  vim: Upgrade to 9.0.2130
+-  vim: use upstream generated .po files
+
+
+Known Issues in Yocto-4.0.15
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+- N/A
+
+
+Contributors to Yocto-4.0.15
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  Alexander Kanavin
+-  Archana Polampalli
+-  BELHADJ SALEM Talel
+-  Bruce Ashfield
+-  Chaitanya Vadrevu
+-  Chen Qi
+-  Deepthi Hemraj
+-  Denys Dmytriyenko
+-  Hitendra Prajapati
+-  Lee Chee Yang
+-  Li Wang
+-  Martin Jansa
+-  Meenali Gupta
+-  Michael Opdenacker
+-  Mikko Rapeli
+-  Narpat Mali
+-  Niko Mauno
+-  Ninad Palsule
+-  Niranjan Pradhan
+-  Paul Eggleton
+-  Peter Kjellerstedt
+-  Peter Marko
+-  Richard Purdie
+-  Ross Burton
+-  Samantha Jalabert
+-  Sanjana
+-  Soumya Sambu
+-  Steve Sakoman
+-  Tim Orling
+-  Vijay Anusuri
+-  Vivek Kumbhar
+-  Wenlin Kang
+-  Yogita Urade
+
+
+Repositories / Downloads for Yocto-4.0.15
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+poky
+
+-  Repository Location: :yocto_git:`/poky`
+-  Branch: :yocto_git:`kirkstone </poky/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.15 </poky/log/?h=yocto-4.0.15>`
+-  Git Revision: :yocto_git:`755632c2fcab43aa05cdcfa529727064b045073c </poky/commit/?id=755632c2fcab43aa05cdcfa529727064b045073c>`
+-  Release Artefact: poky-755632c2fcab43aa05cdcfa529727064b045073c
+-  sha: b40b43bd270d21a420c399981f9cfe0eb999f15e051fc2c89d124f249cdc0bd5
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.15/poky-755632c2fcab43aa05cdcfa529727064b045073c.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.15/poky-755632c2fcab43aa05cdcfa529727064b045073c.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.15 </openembedded-core/log/?h=yocto-4.0.15>`
+-  Git Revision: :oe_git:`eea685e1caafd8e8121006d3f8b5d0b8a4f2a933 </openembedded-core/commit/?id=eea685e1caafd8e8121006d3f8b5d0b8a4f2a933>`
+-  Release Artefact: oecore-eea685e1caafd8e8121006d3f8b5d0b8a4f2a933
+-  sha: ddc3d4a2c8a097f2aa7132ae716affacc44b119c616a1eeffb7db56caa7fc79e
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.15/oecore-eea685e1caafd8e8121006d3f8b5d0b8a4f2a933.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.15/oecore-eea685e1caafd8e8121006d3f8b5d0b8a4f2a933.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.15 </meta-mingw/log/?h=yocto-4.0.15>`
+-  Git Revision: :yocto_git:`f6b38ce3c90e1600d41c2ebb41e152936a0357d7 </meta-mingw/commit/?id=f6b38ce3c90e1600d41c2ebb41e152936a0357d7>`
+-  Release Artefact: meta-mingw-f6b38ce3c90e1600d41c2ebb41e152936a0357d7
+-  sha: 7d57167c19077f4ab95623d55a24c2267a3a3fb5ed83688659b4c03586373b25
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.15/meta-mingw-f6b38ce3c90e1600d41c2ebb41e152936a0357d7.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.15/meta-mingw-f6b38ce3c90e1600d41c2ebb41e152936a0357d7.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.15 </meta-gplv2/log/?h=yocto-4.0.15>`
+-  Git Revision: :yocto_git:`d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a </meta-gplv2/commit/?id=d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a>`
+-  Release Artefact: meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a
+-  sha: c386f59f8a672747dc3d0be1d4234b6039273d0e57933eb87caa20f56b9cca6d
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.15/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.15/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.15 </bitbake/log/?h=yocto-4.0.15>`
+-  Git Revision: :oe_git:`42a1c9fe698a03feb34c5bba223c6e6e0350925b </bitbake/commit/?id=42a1c9fe698a03feb34c5bba223c6e6e0350925b>`
+-  Release Artefact: bitbake-42a1c9fe698a03feb34c5bba223c6e6e0350925b
+-  sha: 64c684ccd661fa13e25c859dfc68d66bec79281da0f4f81b0d6a9995acb659b5
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.15/bitbake-42a1c9fe698a03feb34c5bba223c6e6e0350925b.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.15/bitbake-42a1c9fe698a03feb34c5bba223c6e6e0350925b.tar.bz2
+
+yocto-docs
+
+-  Repository Location: :yocto_git:`/yocto-docs`
+-  Branch: :yocto_git:`kirkstone </yocto-docs/log/?h=kirkstone>`
+-  Tag: :yocto_git:`yocto-4.0.15 </yocto-docs/log/?h=yocto-4.0.15>`
+-  Git Revision: :yocto_git:`08fda7a5601393617b1ecfe89229459e14a90b1d </yocto-docs/commit/?id=08fda7a5601393617b1ecfe89229459e14a90b1d>`
+

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

@@ -0,0 +1,191 @@
+.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
+
+Release notes for Yocto-4.0.16 (Kirkstone)
+------------------------------------------
+
+Security Fixes in Yocto-4.0.16
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  cpio: Fix :cve_mitre:`2023-7207`
+-  curl: Revert "curl: Backport fix CVE-2023-32001"
+-  curl: Fix :cve_nist:`2023-46218`
+-  dropbear:Fix :cve_nist:`2023-48795`
+-  ffmpeg: Fix :cve_nist:`2022-3964` and :cve_nist:`2022-3965`
+-  ghostscript: Fix :cve_nist:`2023-46751`
+-  gnutls: Fix :cve_nist:`2024-0553` and :cve_nist:`2024-0567`
+-  go: Fix :cve_nist:`2023-39326`
+-  openssh: Fix :cve_nist:`2023-48795`, :cve_nist:`2023-51384` and :cve_nist:`2023-51385`
+-  openssl: Fix :cve_nist:`2023-6129` and :cve_mitre:`2023-6237`
+-  pam: Fix :cve_mitre:`2024-22365`
+-  perl: Fix :cve_nist:`2023-47038`
+-  qemu: Fix :cve_nist:`2023-5088`
+-  sqlite3: Fix :cve_nist:`2023-7104`
+-  systemd: Fix :cve_nist:`2023-7008`
+-  tiff: Fix :cve_nist:`2023-6228`
+-  xserver-xorg: Fix :cve_nist:`2023-6377`, :cve_nist:`2023-6478`, :cve_nist:`2023-6816`, :cve_mitre:`2024-0229`, :cve_nist:`2024-0408`, :cve_nist:`2024-0409`, :cve_mitre:`2024-21885` and :cve_mitre:`2024-21886`
+-  zlib: Ignore :cve_nist:`2023-6992`
+
+
+Fixes in Yocto-4.0.16
+~~~~~~~~~~~~~~~~~~~~~
+
+-  bitbake: asyncrpc: Add context manager API
+-  bitbake: data: Add missing dependency handling of remove operator
+-  bitbake: lib/bb: Add workaround for libgcc issues with python 3.8 and 3.9
+-  bitbake: toastergui: verify that an existing layer path is given
+-  build-appliance-image: Update to kirkstone head revision
+-  contributor-guide: add License-Update tag
+-  contributor-guide: fix command option
+-  contributor-guide: use "apt" instead of "aptitude"
+-  cpio: upgrade to 2.14
+-  cve-update-nvd2-native: faster requests with API keys
+-  cve-update-nvd2-native: increase the delay between subsequent request failures
+-  cve-update-nvd2-native: make number of fetch attemtps configurable
+-  cve-update-nvd2-native: remove unused variable CVE_SOCKET_TIMEOUT
+-  dev-manual: Discourage the use of SRC_URI[md5sum]
+-  dev-manual: layers: update link to YP Compatible form
+-  dev-manual: runtime-testing: fix test module name
+-  dev-manual: start.rst: update use of Download page
+-  docs:what-i-wish-id-known.rst: fix URL
+-  docs: document VSCode extension
+-  docs:brief-yoctoprojectqs:index.rst: align variable order with default local.conf
+-  docs:migration-guides: add release notes for 4.0.15
+-  docs:migration-guides: release 3.5 is actually 4.0
+-  elfutils: Disable stringop-overflow warning for build host
+-  externalsrc: Ensure :term:`SRCREV` is processed before accessing :term:`SRC_URI`
+-  linux-firmware: upgrade to 20231030
+-  manuals: Add :term:`CONVERSION_CMD` definition
+-  manuals: Add :term:`UBOOT_BINARY`, extend :term:`UBOOT_CONFIG`
+-  perl: upgrade to 5.34.3
+-  poky.conf: bump version for 4.0.16
+-  pybootchartgui: fix 2 SyntaxWarnings
+-  python3-ptest: skip test_storlines
+-  ref-manual: Fix reference to MIRRORS/PREMIRRORS defaults
+-  ref-manual: classes: remove insserv bbclass
+-  ref-manual: releases.svg: update nanbield release status
+-  ref-manual: resources: sync with master branch
+-  ref-manual: update tested and supported distros
+-  test-manual: add links to python unittest
+-  test-manual: add or improve hyperlinks
+-  test-manual: explicit or fix file paths
+-  test-manual: resource updates
+-  test-manual: text and formatting fixes
+-  test-manual: use working example
+-  testimage: Exclude wtmp from target-dumper commands
+-  testimage: drop target_dumper, host_dumper, and monitor_dumper
+-  tzdata: Upgrade to 2023d
+
+
+Known Issues in Yocto-4.0.16
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+- N/A
+
+
+Contributors to Yocto-4.0.16
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  Aatir Manzur
+-  Archana Polampalli
+-  Dhairya Nagodra
+-  Dmitry Baryshkov
+-  Enguerrand de Ribaucourt
+-  Hitendra Prajapati
+-  Insu Park
+-  Joshua Watt
+-  Justin Bronder
+-  Jörg Sommer
+-  Khem Raj
+-  Lee Chee Yang
+-  mark.yang
+-  Marta Rybczynska
+-  Martin Jansa
+-  Maxin B. John
+-  Michael Opdenacker
+-  Paul Barker
+-  Peter Kjellerstedt
+-  Peter Marko
+-  Poonam Jadhav
+-  Richard Purdie
+-  Shubham Kulkarni
+-  Simone Weiß
+-  Soumya Sambu
+-  Sourav Pramanik
+-  Steve Sakoman
+-  Trevor Gamblin
+-  Vijay Anusuri
+-  Vivek Kumbhar
+-  Yoann Congal
+-  Yogita Urade
+
+
+Repositories / Downloads for Yocto-4.0.16
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+poky
+
+-  Repository Location: :yocto_git:`/poky`
+-  Branch: :yocto_git:`kirkstone </poky/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.16 </poky/log/?h=yocto-4.0.16>`
+-  Git Revision: :yocto_git:`54af8c5e80ebf63707ef4e51cc9d374f716da603 </poky/commit/?id=54af8c5e80ebf63707ef4e51cc9d374f716da603>`
+-  Release Artefact: poky-54af8c5e80ebf63707ef4e51cc9d374f716da603
+-  sha: a53ec3a661cf56ca40c0fbf1500288c2c20abe94896d66a572bc5ccf5d92e9d6
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.16/poky-54af8c5e80ebf63707ef4e51cc9d374f716da603.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.16/poky-54af8c5e80ebf63707ef4e51cc9d374f716da603.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.16 </openembedded-core/log/?h=yocto-4.0.16>`
+-  Git Revision: :oe_git:`a744a897f0ea7d34c31c024c13031221f9a85f24 </openembedded-core/commit/?id=a744a897f0ea7d34c31c024c13031221f9a85f24>`
+-  Release Artefact: oecore-a744a897f0ea7d34c31c024c13031221f9a85f24
+-  sha: 8c2bc9487597b0caa9f5a1d72b18cfcd1ddc7e6d91f0f051313563d6af95aeec
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.16/oecore-a744a897f0ea7d34c31c024c13031221f9a85f24.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.16/oecore-a744a897f0ea7d34c31c024c13031221f9a85f24.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.16 </meta-mingw/log/?h=yocto-4.0.16>`
+-  Git Revision: :yocto_git:`f6b38ce3c90e1600d41c2ebb41e152936a0357d7 </meta-mingw/commit/?id=f6b38ce3c90e1600d41c2ebb41e152936a0357d7>`
+-  Release Artefact: meta-mingw-f6b38ce3c90e1600d41c2ebb41e152936a0357d7
+-  sha: 7d57167c19077f4ab95623d55a24c2267a3a3fb5ed83688659b4c03586373b25
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.16/meta-mingw-f6b38ce3c90e1600d41c2ebb41e152936a0357d7.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.16/meta-mingw-f6b38ce3c90e1600d41c2ebb41e152936a0357d7.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.16 </meta-gplv2/log/?h=yocto-4.0.16>`
+-  Git Revision: :yocto_git:`d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a </meta-gplv2/commit/?id=d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a>`
+-  Release Artefact: meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a
+-  sha: c386f59f8a672747dc3d0be1d4234b6039273d0e57933eb87caa20f56b9cca6d
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.16/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.16/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.16 </bitbake/log/?h=yocto-4.0.16>`
+-  Git Revision: :oe_git:`ee090484cc25d760b8c20f18add17b5eff485b40 </bitbake/commit/?id=ee090484cc25d760b8c20f18add17b5eff485b40>`
+-  Release Artefact: bitbake-ee090484cc25d760b8c20f18add17b5eff485b40
+-  sha: 479e3a57ae9fbc2aa95292a7554caeef113bbfb28c226ed19547b8dde1c95314
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.16/bitbake-ee090484cc25d760b8c20f18add17b5eff485b40.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.16/bitbake-ee090484cc25d760b8c20f18add17b5eff485b40.tar.bz2
+
+yocto-docs
+
+-  Repository Location: :yocto_git:`/yocto-docs`
+-  Branch: :yocto_git:`kirkstone </yocto-docs/log/?h=kirkstone>`
+-  Tag: :yocto_git:`yocto-4.0.16 </yocto-docs/log/?h=yocto-4.0.16>`
+-  Git Revision: :yocto_git:`aba67b58711019a6ba439b2b77337f813ed799ac </yocto-docs/commit/?id=aba67b58711019a6ba439b2b77337f813ed799ac>`
+

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

@@ -0,0 +1,238 @@
+.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
+
+Release notes for Yocto-4.0.17 (Kirkstone)
+------------------------------------------
+
+Security Fixes in Yocto-4.0.17
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  bind: Fix :cve_nist:`2023-4408`, :cve_nist:`2023-5517`, :cve_nist:`2023-5679`, :cve_nist:`2023-50868` and :cve_nist:`2023-50387`
+-  binutils: Fix :cve_nist:`2023-39129` and :cve_nist:`2023-39130`
+-  curl: Fix :cve_nist:`2023-46219`
+-  curl: Ignore :cve_nist:`2023-42915`
+-  gcc: Ignore :cve_nist:`2023-4039`
+-  gdb: Fix :cve_nist:`2023-39129` and :cve_nist:`2023-39130`
+-  glibc: Ignore :cve_nist:`2023-0687`
+-  go: Fix :cve_nist:`2023-29406`, :cve_nist:`2023-45285`, :cve_nist:`2023-45287`, :cve_nist:`2023-45289`, :cve_nist:`2023-45290`, :cve_nist:`2024-24784` and :cve_nist:`2024-24785`
+-  less: Fix :cve_nist:`2022-48624`
+-  libgit2: Fix :cve_nist:`2024-24575` and :cve_nist:`2024-24577`
+-  libuv: fix :cve_nist:`2024-24806`
+-  libxml2: Fix for :cve_nist:`2024-25062`
+-  linux-yocto/5.15: Fix :cve_nist:`2022-36402`, :cve_nist:`2022-40982`, :cve_nist:`2022-47940`, :cve_nist:`2023-1193`, :cve_nist:`2023-1194`, :cve_nist:`2023-3772`, :cve_mitre:`2023-3867`, :cve_nist:`2023-4128`, :cve_nist:`2023-4206`, :cve_nist:`2023-4207`, :cve_nist:`2023-4208`, :cve_nist:`2023-4244`, :cve_nist:`2023-4273`, :cve_nist:`2023-4563`, :cve_nist:`2023-4569`, :cve_nist:`2023-4623`, :cve_nist:`2023-4881`, :cve_nist:`2023-4921`, :cve_nist:`2023-5158`, :cve_nist:`2023-5717`, :cve_nist:`2023-6040`, :cve_nist:`2023-6121`, :cve_nist:`2023-6176`, :cve_nist:`2023-6546`, :cve_nist:`2023-6606`, :cve_nist:`2023-6622`, :cve_nist:`2023-6817`, :cve_nist:`2023-6915`, :cve_nist:`2023-6931`, :cve_nist:`2023-6932`, :cve_nist:`2023-20569`, :cve_nist:`2023-20588`, :cve_nist:`2023-25775`, :cve_nist:`2023-31085`, :cve_nist:`2023-32247`, :cve_nist:`2023-32250`, :cve_nist:`2023-32252`, :cve_nist:`2023-32254`, :cve_nist:`2023-32257`, :cve_nist:`2023-32258`, :cve_nist:`2023-34324`, :cve_nist:`2023-35827`, :cve_nist:`2023-38427`, :cve_nist:`2023-38430`, :cve_nist:`2023-38431`, :cve_nist:`2023-39189`, :cve_nist:`2023-39192`, :cve_nist:`2023-39193`, :cve_nist:`2023-39194`, :cve_nist:`2023-39198`, :cve_nist:`2023-40283`, :cve_nist:`2023-42752`, :cve_nist:`2023-42753`, :cve_nist:`2023-42754`, :cve_nist:`2023-42755`, :cve_nist:`2023-45871`, :cve_nist:`2023-46343`, :cve_nist:`2023-46813`, :cve_nist:`2023-46838`, :cve_nist:`2023-46862`, :cve_nist:`2023-51042`, :cve_nist:`2023-51779`, :cve_mitre:`2023-52340`, :cve_nist:`2023-52429`, :cve_nist:`2023-52435`, :cve_nist:`2023-52436`, :cve_nist:`2023-52438`, :cve_nist:`2023-52439`, :cve_nist:`2023-52441`, :cve_nist:`2023-52442`, :cve_nist:`2023-52443`, :cve_nist:`2023-52444`, :cve_nist:`2023-52445`, :cve_nist:`2023-52448`, :cve_nist:`2023-52449`, :cve_nist:`2023-52451`, :cve_nist:`2023-52454`, :cve_nist:`2023-52456`, :cve_nist:`2023-52457`, :cve_nist:`2023-52458`, :cve_nist:`2023-52463`, :cve_nist:`2023-52464`, :cve_nist:`2024-0340`, :cve_nist:`2024-0584`, :cve_nist:`2024-0607`, :cve_nist:`2024-0641`, :cve_nist:`2024-0646`, :cve_nist:`2024-1085`, :cve_nist:`2024-1086`, :cve_nist:`2024-1151`, :cve_nist:`2024-22705`, :cve_nist:`2024-23849`, :cve_nist:`2024-23850`, :cve_nist:`2024-23851`, :cve_nist:`2024-24860`, :cve_nist:`2024-26586`, :cve_nist:`2024-26589`, :cve_nist:`2024-26591`, :cve_nist:`2024-26592`, :cve_nist:`2024-26593`, :cve_nist:`2024-26594`, :cve_nist:`2024-26597` and :cve_nist:`2024-26598`
+-  linux-yocto/5.15: Ignore :cve_nist:`2020-27418`, :cve_nist:`2020-36766`, :cve_nist:`2021-33630`, :cve_nist:`2021-33631`, :cve_nist:`2022-48619`, :cve_nist:`2023-2430`, :cve_nist:`2023-4610`, :cve_nist:`2023-4732`, :cve_nist:`2023-5090`, :cve_nist:`2023-5178`, :cve_nist:`2023-5197`, :cve_nist:`2023-5345`, :cve_nist:`2023-5633`, :cve_nist:`2023-5972`, :cve_nist:`2023-6111`, :cve_nist:`2023-6200`, :cve_nist:`2023-6531`, :cve_nist:`2023-6679`, :cve_nist:`2023-7192`, :cve_nist:`2023-40791`, :cve_nist:`2023-42756`, :cve_nist:`2023-44466`, :cve_nist:`2023-45862`, :cve_nist:`2023-45863`, :cve_nist:`2023-45898`, :cve_nist:`2023-51043`, :cve_nist:`2023-51780`, :cve_nist:`2023-51781`, :cve_nist:`2023-51782`, :cve_nist:`2023-52433`, :cve_nist:`2023-52440`, :cve_nist:`2023-52446`, :cve_nist:`2023-52450`, :cve_nist:`2023-52453`, :cve_nist:`2023-52455`, :cve_nist:`2023-52459`, :cve_nist:`2023-52460`, :cve_nist:`2023-52461`, :cve_nist:`2023-52462`, :cve_nist:`2024-0193`, :cve_nist:`2024-0443`, :cve_nist:`2024-0562`, :cve_nist:`2024-0582`, :cve_nist:`2024-0639`, :cve_nist:`2024-0775`, :cve_nist:`2024-26581`, :cve_nist:`2024-26582`, :cve_nist:`2024-26590`, :cve_nist:`2024-26596` and :cve_nist:`2024-26599`
+-  linux-yocto/5.10: Fix :cve_nist:`2023-6040`, :cve_nist:`2023-6121`, :cve_nist:`2023-6606`, :cve_nist:`2023-6817`, :cve_nist:`2023-6915`, :cve_nist:`2023-6931`, :cve_nist:`2023-6932`, :cve_nist:`2023-39198`, :cve_nist:`2023-46838`, :cve_nist:`2023-51779`, :cve_nist:`2023-51780`, :cve_nist:`2023-51781`, :cve_nist:`2023-51782`, :cve_mitre:`2023-52340`, :cve_nist:`2024-0584` and :cve_nist:`2024-0646`
+-  linux-yocto/5.10: Ignore :cve_nist:`2021-33630`, :cve_nist:`2021-33631`, :cve_nist:`2022-1508`, :cve_nist:`2022-36402`, :cve_nist:`2022-48619`, :cve_nist:`2023-2430`, :cve_nist:`2023-4610`, :cve_nist:`2023-5972`, :cve_nist:`2023-6039`, :cve_nist:`2023-6200`, :cve_nist:`2023-6531`, :cve_nist:`2023-6546`, :cve_nist:`2023-6622`, :cve_nist:`2023-6679`, :cve_nist:`2023-7192`, :cve_nist:`2023-46343`, :cve_nist:`2023-51042`, :cve_nist:`2023-51043`, :cve_nist:`2024-0193`, :cve_nist:`2024-0443`, :cve_nist:`2024-0562`, :cve_nist:`2024-0582`, :cve_nist:`2024-0639`, :cve_nist:`2024-0641`, :cve_nist:`2024-0775`, :cve_nist:`2024-1085` and :cve_nist:`2024-22705`
+-  openssl: Fix :cve_nist:`2024-0727`
+-  python3-pycryptodome: Fix :cve_nist:`2023-52323`
+-  qemu: Fix :cve_nist:`2023-6693`, :cve_nist:`2023-42467` and :cve_nist:`2024-24474`
+-  vim: Fix :cve_nist:`2024-22667`
+-  xwayland: Fix :cve_nist:`2023-6377` and :cve_nist:`2023-6478`
+
+
+Fixes in Yocto-4.0.17
+~~~~~~~~~~~~~~~~~~~~~
+
+-  bind: Upgrade to 9.18.24
+-  bitbake: bitbake/codeparser.py: address ast module deprecations in py 3.12
+-  bitbake: bitbake/lib/bs4/tests/test_tree.py: python 3.12 regex
+-  bitbake: codeparser: replace deprecated ast.Str and 's'
+-  bitbake: fetch2: Ensure that git LFS objects are available
+-  bitbake: tests/fetch: Add real git lfs tests and decorator
+-  bitbake: tests/fetch: git-lfs restore _find_git_lfs
+-  bitbake: toaster/toastergui: Bug-fix verify given layer path only if import/add local layer
+-  build-appliance-image: Update to kirkstone head revision
+-  cmake: Unset CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES
+-  contributor-guide: fix lore URL
+-  curl: don't enable debug builds
+-  cve_check: cleanup logging
+-  dbus: Add missing :term:`CVE_PRODUCT`
+-  dev-manual: sbom: Rephrase spdx creation
+-  dev-manual: runtime-testing: gen-tapdevs need iptables installed
+-  dev-manual: packages: clarify shared :term:`PR` service constraint
+-  dev-manual: packages: need enough free space
+-  dev-manual: start: remove idle line
+-  feature-microblaze-versions.inc: python 3.12 regex
+-  ghostscript: correct :term:`LICENSE` with AGPLv3
+-  image-live.bbclass: LIVE_ROOTFS_TYPE support compression
+-  kernel.bbclass: Set pkg-config variables for building modules
+-  kernel.bbclass: introduce KERNEL_LOCALVERSION
+-  kernel: fix localversion in v6.3+
+-  kernel: make LOCALVERSION consistent between recipes
+-  ldconfig-native: Fix to point correctly on the DT_NEEDED entries in an ELF file
+-  librsvg: Fix do_package_qa error for librsvg
+-  linux-firmware: upgrade to 20231211
+-  linux-yocto/5.10: update to v5.10.210
+-  linux-yocto/5.15: update to v5.15.150
+-  manuals: add minimum RAM requirements
+-  manuals: suppress excess use of "following" word
+-  manuals: update disk space requirements
+-  manuals: update references to buildtools
+-  manuals: updates for building on Windows (WSL 2)
+-  meta/lib/oeqa: python 3.12 regex
+-  meta/recipes: python 3.12 regex
+-  migration-guide: add release notes for 4.0.16
+-  oeqa/selftest/oelib/buildhistory: git default branch
+-  oeqa/selftest/recipetool: downgrade meson version to not use pyproject.toml
+-  oeqa/selftest/recipetool: expect meson.bb
+-  oeqa/selftest/recipetool: fix for python 3.12
+-  oeqa/selftest/runtime_test: only run the virgl tests on qemux86-64
+-  oeqa: replace deprecated assertEquals
+-  openssl: Upgrade to 3.0.13
+-  poky.conf: bump version for 4.0.17
+-  populate_sdk_ext: use ConfigParser instead of SafeConfigParser
+-  python3-jinja2: upgrade to 3.1.3
+-  recipetool/create_buildsys_python: use importlib instead of imp
+-  ref-manual: system-requirements: recommend buildtools for not supported distros
+-  ref-manual: system-requirements: add info on buildtools-make-tarball
+-  ref-manual: release-process: grammar fix
+-  ref-manual: system-requirements: fix AlmaLinux variable name
+-  ref-manual: system-requirements: modify anchor
+-  ref-manual: system-requirements: remove outdated note
+-  ref-manual: system-requirements: simplify supported distro requirements
+-  ref-manual: system-requirements: update packages to build docs
+-  scripts/runqemu: add qmp socket support
+-  scripts/runqemu: direct mesa to use its own drivers, rather than ones provided by host distro
+-  scripts/runqemu: fix regex escape sequences
+-  scripts: python 3.12 regex
+-  selftest: skip virgl gtk/sdl test on ubuntu 18.04
+-  systemd: Only add myhostname to nsswitch.conf if in :term:`PACKAGECONFIG`
+-  tzdata : Upgrade to 2024a
+-  u-boot: Move UBOOT_INITIAL_ENV back to u-boot.inc
+-  useradd-example: do not use unsupported clear text password
+-  vim: upgrade to v9.0.2190
+-  yocto-bsp: update to v5.15.150
+
+
+Known Issues in Yocto-4.0.17
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+- N/A
+
+
+Contributors to Yocto-4.0.17
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  Adrian Freihofer
+-  Alassane Yattara
+-  Alexander Kanavin
+-  Alexander Sverdlin
+-  Archana Polampalli
+-  Baruch Siach
+-  Bruce Ashfield
+-  Chen Qi
+-  Chris Laplante
+-  Deepthi Hemraj
+-  Dhairya Nagodra
+-  Fabien Mahot
+-  Fabio Estevam
+-  Hitendra Prajapati
+-  Hugo SIMELIERE
+-  Jermain Horsman
+-  Kai Kang
+-  Lee Chee Yang
+-  Ludovic Jozeau
+-  Michael Opdenacker
+-  Ming Liu
+-  Munehisa Kamata
+-  Narpat Mali
+-  Nikhil R
+-  Paul Eggleton
+-  Paulo Neves
+-  Peter Marko
+-  Philip Lorenz
+-  Poonam Jadhav
+-  Priyal Doshi
+-  Ross Burton
+-  Simone Weiß
+-  Soumya Sambu
+-  Steve Sakoman
+-  Tim Orling
+-  Trevor Gamblin
+-  Vijay Anusuri
+-  Vivek Kumbhar
+-  Wang Mingyu
+-  Zahir Hussain
+
+
+Repositories / Downloads for Yocto-4.0.17
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+poky
+
+-  Repository Location: :yocto_git:`/poky`
+-  Branch: :yocto_git:`kirkstone </poky/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.17 </poky/log/?h=yocto-4.0.17>`
+-  Git Revision: :yocto_git:`6d1a878bbf24c66f7186b270f823fcdf82e35383 </poky/commit/?id=6d1a878bbf24c66f7186b270f823fcdf82e35383>`
+-  Release Artefact: poky-6d1a878bbf24c66f7186b270f823fcdf82e35383
+-  sha: 3bc3010340b674f7b0dd0a7997f0167b2240b794fbd4aa28c0c4217bddd15e30
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.17/poky-6d1a878bbf24c66f7186b270f823fcdf82e35383.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.17/poky-6d1a878bbf24c66f7186b270f823fcdf82e35383.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.17 </openembedded-core/log/?h=yocto-4.0.17>`
+-  Git Revision: :oe_git:`2501534c9581c6c3439f525d630be11554a57d24 </openembedded-core/commit/?id=2501534c9581c6c3439f525d630be11554a57d24>`
+-  Release Artefact: oecore-2501534c9581c6c3439f525d630be11554a57d24
+-  sha: 52cc6cce9e920bdce078584b89136e81cc01e0c55616fab5fca6c3e04264c88e
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.17/oecore-2501534c9581c6c3439f525d630be11554a57d24.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.17/oecore-2501534c9581c6c3439f525d630be11554a57d24.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.17 </meta-mingw/log/?h=yocto-4.0.17>`
+-  Git Revision: :yocto_git:`f6b38ce3c90e1600d41c2ebb41e152936a0357d7 </meta-mingw/commit/?id=f6b38ce3c90e1600d41c2ebb41e152936a0357d7>`
+-  Release Artefact: meta-mingw-f6b38ce3c90e1600d41c2ebb41e152936a0357d7
+-  sha: 7d57167c19077f4ab95623d55a24c2267a3a3fb5ed83688659b4c03586373b25
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.17/meta-mingw-f6b38ce3c90e1600d41c2ebb41e152936a0357d7.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.17/meta-mingw-f6b38ce3c90e1600d41c2ebb41e152936a0357d7.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.17 </meta-gplv2/log/?h=yocto-4.0.17>`
+-  Git Revision: :yocto_git:`d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a </meta-gplv2/commit/?id=d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a>`
+-  Release Artefact: meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a
+-  sha: c386f59f8a672747dc3d0be1d4234b6039273d0e57933eb87caa20f56b9cca6d
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.17/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.17/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2
+
+meta-clang
+
+-  Repository Location: :yocto_git:`/meta-clang`
+-  Branch: :yocto_git:`kirkstone </meta-clang/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.17 </meta-clang/log/?h=yocto-4.0.17>`
+-  Git Revision: :yocto_git:`eebe4ff2e539f3ffb01c5060cc4ca8b226ea8b52 </meta-clang/commit/?id=eebe4ff2e539f3ffb01c5060cc4ca8b226ea8b52>`
+-  Release Artefact: meta-clang-eebe4ff2e539f3ffb01c5060cc4ca8b226ea8b52
+-  sha: 3299e96e069a22c0971e903fbc191f2427efffc83d910ac51bf0237caad01d17
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.17/meta-clang-eebe4ff2e539f3ffb01c5060cc4ca8b226ea8b52.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.17/meta-clang-eebe4ff2e539f3ffb01c5060cc4ca8b226ea8b52.tar.bz2
+
+bitbake
+
+-  Repository Location: :oe_git:`/bitbake`
+-  Branch: :oe_git:`2.0 </bitbake/log/?h=2.0>`
+-  Tag:  :oe_git:`yocto-4.0.17 </bitbake/log/?h=yocto-4.0.17>`
+-  Git Revision: :oe_git:`40fd5f4eef7460ca67f32cfce8e229e67e1ff607 </bitbake/commit/?id=40fd5f4eef7460ca67f32cfce8e229e67e1ff607>`
+-  Release Artefact: bitbake-40fd5f4eef7460ca67f32cfce8e229e67e1ff607
+-  sha: 5d20a0e4c5d0fce44bd84778168714a261a30a4b83f67c88df3b8a7e7115e444
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.17/bitbake-40fd5f4eef7460ca67f32cfce8e229e67e1ff607.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.17/bitbake-40fd5f4eef7460ca67f32cfce8e229e67e1ff607.tar.bz2
+
+yocto-docs
+
+-  Repository Location: :yocto_git:`/yocto-docs`
+-  Branch: :yocto_git:`kirkstone </yocto-docs/log/?h=kirkstone>`
+-  Tag: :yocto_git:`yocto-4.0.17 </yocto-docs/log/?h=yocto-4.0.17>`
+-  Git Revision: :yocto_git:`08ce7db2aa3a38deb8f5aa59bafc78542986babb </yocto-docs/commit/?id=08ce7db2aa3a38deb8f5aa59bafc78542986babb>`
+

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

@@ -0,0 +1,191 @@
+.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
+
+Release notes for Yocto-4.0.18 (Kirkstone)
+------------------------------------------
+
+Security Fixes in Yocto-4.0.18
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  curl: Fix :cve_nist:`2024-2398`
+-  expat: fix :cve_nist:`2023-52426` and :cve_nist:`2024-28757`
+-  libssh2: fix :cve_nist:`2023-48795`
+-  ncurses: Fix :cve_nist:`2023-50495`
+-  nghttp2: Fix :cve_nist:`2024-28182` and :cve_nist:`2023-44487`
+-  openssh: Ignore :cve_nist:`2023-51767`
+-  openssl: Fix :cve_nist:`2024-2511`
+-  perl: Ignore :cve_nist:`2023-47100`
+-  python3-cryptography: Fix :cve_nist:`2024-26130`
+-  python3-urllib3: Fix :cve_nist:`2023-45803`
+-  qemu: Fix :cve_nist:`2023-6683`
+-  ruby: fix :cve_mitre:`2024-27281`
+-  rust: Ignore :cve_nist:`2024-24576`
+-  tiff: Fix :cve_nist:`2023-52356` and :cve_nist:`2023-6277`
+-  xserver-xorg: Fix :cve_nist:`2024-31080` and :cve_nist:`2024-31081`
+-  xwayland: Fix :cve_nist:`2023-6816`, :cve_nist:`2024-0408` and :cve_nist:`2024-0409`
+
+
+Fixes in Yocto-4.0.18
+~~~~~~~~~~~~~~~~~~~~~
+
+-  build-appliance-image: Update to kirkstone head revision
+-  common-licenses: Backport missing license
+-  contributor-guide: add notes for tests
+-  contributor-guide: be more specific about meta-* trees
+-  cups: fix typo in :cve_nist:`2023-32360` backport patch
+-  cve-update-nvd2-native: Add an age threshold for incremental update
+-  cve-update-nvd2-native: Fix CVE configuration update
+-  cve-update-nvd2-native: Fix typo in comment
+-  cve-update-nvd2-native: Remove duplicated CVE_CHECK_DB_FILE definition
+-  cve-update-nvd2-native: Remove rejected CVE from database
+-  cve-update-nvd2-native: nvd_request_next: Improve comment
+-  dev-manual: improve descriptions of 'bitbake -S printdiff'
+-  dev-manual: packages: fix capitalization
+-  docs: conf.py: properly escape backslashes for latex_elements
+-  gcc: Backport sanitizer fix for 32-bit ALSR
+-  glibc: Fix subscript typos for get_nscd_addresses
+-  kernel-dev: join mkdir commands with -p
+-  linux-firmware: Upgrade to 20240220
+-  manuals: add initial sphinx-lint support
+-  manuals: add initial stylechecks with Vale
+-  manuals: document VIRTUAL-RUNTIME variables
+-  manuals: fix duplicate "stylecheck" target
+-  manuals: fix incorrect double backticks
+-  manuals: fix trailing spaces
+-  manuals: refer to new yocto-patches mailing list wherever appropriate
+-  manuals: remove tab characters
+-  manuals: replace hyphens with em dashes
+-  manuals: use "manual page(s)"
+-  migration-guides: add release notes for 4.0.17
+-  poky.conf: bump version for 4.0.18
+-  profile-manual: usage.rst: fix reference to bug report
+-  profile-manual: usage.rst: formatting fixes
+-  profile-manual: usage.rst: further style improvements
+-  python3-urllib3: Upgrade to v1.26.18
+-  ref-manual: add documentation of the variable :term:`SPDX_NAMESPACE_PREFIX`
+-  ref-manual: tasks: do_cleanall: recommend using '-f' instead
+-  ref-manual: tasks: do_cleansstate: recommend using '-f' instead for a shared sstate
+-  ref-manual: variables: adding multiple groups in :term:`GROUPADD_PARAM`
+-  ref-manual: variables: correct sdk installation default path
+-  stress-ng: avoid calling sync during do_compile
+-  systemd: Fix vlan qos mapping
+-  tcl: Add a way to skip ptests
+-  tcl: skip async and event tests in run-ptest
+-  tcl: skip timing-dependent tests in run-ptest
+-  valgrind: skip intermittently failing ptest
+-  wireless-regdb: Upgrade to 2024.01.23
+-  yocto-uninative: Update to 4.4 for glibc 2.39
+
+
+Known Issues in Yocto-4.0.18
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+- N/A
+
+
+Contributors to Yocto-4.0.18
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  Alex Kiernan
+-  Alex Stewart
+-  Alexander Kanavin
+-  BELOUARGA Mohamed
+-  Claus Stovgaard
+-  Colin McAllister
+-  Geoff Parker
+-  Haitao Liu
+-  Harish Sadineni
+-  Johan Bezem
+-  Jonathan GUILLOT
+-  Jörg Sommer
+-  Khem Raj
+-  Lee Chee Yang
+-  Luca Ceresoli
+-  Martin Jansa
+-  Meenali Gupta
+-  Michael Halstead
+-  Michael Opdenacker
+-  Peter Marko
+-  Quentin Schulz
+-  Ross Burton
+-  Sana Kazi
+-  Simone Weiß
+-  Soumya Sambu
+-  Steve Sakoman
+-  Tan Wen Yan
+-  Vijay Anusuri
+-  Wang Mingyu
+-  Yoann Congal
+-  Yogita Urade
+-  Zahir Hussain
+
+
+Repositories / Downloads for Yocto-4.0.18
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+poky
+
+-  Repository Location: :yocto_git:`/poky`
+-  Branch: :yocto_git:`kirkstone </poky/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.18 </poky/log/?h=yocto-4.0.18>`
+-  Git Revision: :yocto_git:`31751bba1c789f15f574773a659b8017d7bcf440 </poky/commit/?id=31751bba1c789f15f574773a659b8017d7bcf440>`
+-  Release Artefact: poky-31751bba1c789f15f574773a659b8017d7bcf440
+-  sha: 72d5aa65c3c37766ebc24b212740272c1d52342468548f9c070241d3522ad2ca
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.18/poky-31751bba1c789f15f574773a659b8017d7bcf440.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.18/poky-31751bba1c789f15f574773a659b8017d7bcf440.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.18 </openembedded-core/log/?h=yocto-4.0.18>`
+-  Git Revision: :oe_git:`b7182571242dc4e23e5250a449d90348e62a6abc </openembedded-core/commit/?id=b7182571242dc4e23e5250a449d90348e62a6abc>`
+-  Release Artefact: oecore-b7182571242dc4e23e5250a449d90348e62a6abc
+-  sha: 6f257e50c10ebae673dcf61a833b3270db6d22781f02f6794a370aac839f1020
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.18/oecore-b7182571242dc4e23e5250a449d90348e62a6abc.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.18/oecore-b7182571242dc4e23e5250a449d90348e62a6abc.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.18 </meta-mingw/log/?h=yocto-4.0.18>`
+-  Git Revision: :yocto_git:`f6b38ce3c90e1600d41c2ebb41e152936a0357d7 </meta-mingw/commit/?id=f6b38ce3c90e1600d41c2ebb41e152936a0357d7>`
+-  Release Artefact: meta-mingw-f6b38ce3c90e1600d41c2ebb41e152936a0357d7
+-  sha: 7d57167c19077f4ab95623d55a24c2267a3a3fb5ed83688659b4c03586373b25
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.18/meta-mingw-f6b38ce3c90e1600d41c2ebb41e152936a0357d7.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.18/meta-mingw-f6b38ce3c90e1600d41c2ebb41e152936a0357d7.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.18 </meta-gplv2/log/?h=yocto-4.0.18>`
+-  Git Revision: :yocto_git:`d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a </meta-gplv2/commit/?id=d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a>`
+-  Release Artefact: meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a
+-  sha: c386f59f8a672747dc3d0be1d4234b6039273d0e57933eb87caa20f56b9cca6d
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.18/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.18/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.18 </bitbake/log/?h=yocto-4.0.18>`
+-  Git Revision: :oe_git:`40fd5f4eef7460ca67f32cfce8e229e67e1ff607 </bitbake/commit/?id=40fd5f4eef7460ca67f32cfce8e229e67e1ff607>`
+-  Release Artefact: bitbake-40fd5f4eef7460ca67f32cfce8e229e67e1ff607
+-  sha: 5d20a0e4c5d0fce44bd84778168714a261a30a4b83f67c88df3b8a7e7115e444
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.18/bitbake-40fd5f4eef7460ca67f32cfce8e229e67e1ff607.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.18/bitbake-40fd5f4eef7460ca67f32cfce8e229e67e1ff607.tar.bz2
+
+yocto-docs
+
+-  Repository Location: :yocto_git:`/yocto-docs`
+-  Branch: :yocto_git:`kirkstone </yocto-docs/log/?h=kirkstone>`
+-  Tag: :yocto_git:`yocto-4.0.18 </yocto-docs/log/?h=yocto-4.0.18>`
+-  Git Revision: :yocto_git:`fd1423141e7458ba557db465c171b0b4e9063987 </yocto-docs/commit/?id=fd1423141e7458ba557db465c171b0b4e9063987>`
+

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

@@ -4,13 +4,13 @@ Release notes for Yocto-4.0.2 (Kirkstone)
 Security Fixes in Yocto-4.0.2
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
--  libxslt: Mark :cve:`2022-29824` as not applying
--  tiff: Add jbig PACKAGECONFIG and clarify IGNORE :cve:`2022-1210`
--  tiff: mark :cve:`2022-1622` and :cve:`2022-1623` as invalid
--  pcre2:fix :cve:`2022-1586` Out-of-bounds read
--  curl: fix :cve:`2022-22576`, :cve:`2022-27775`, :cve:`2022-27776`, :cve:`2022-27774`, :cve:`2022-30115`, :cve:`2022-27780`, :cve:`2022-27781`, :cve:`2022-27779` and :cve:`2022-27782`
--  qemu: fix :cve:`2021-4206` and :cve:`2021-4207`
--  freetype: fix :cve:`2022-27404`, :cve:`2022-27405` and :cve:`2022-27406`
+-  libxslt: Mark :cve_nist:`2022-29824` as not applying
+-  tiff: Add jbig :term:`PACKAGECONFIG` and clarify IGNORE :cve_nist:`2022-1210`
+-  tiff: mark :cve_nist:`2022-1622` and :cve_nist:`2022-1623` as invalid
+-  pcre2:fix :cve_nist:`2022-1586` Out-of-bounds read
+-  curl: fix :cve_nist:`2022-22576`, :cve_nist:`2022-27775`, :cve_nist:`2022-27776`, :cve_nist:`2022-27774`, :cve_nist:`2022-30115`, :cve_nist:`2022-27780`, :cve_nist:`2022-27781`, :cve_nist:`2022-27779` and :cve_nist:`2022-27782`
+-  qemu: fix :cve_nist:`2021-4206` and :cve_nist:`2021-4207`
+-  freetype: fix :cve_nist:`2022-27404`, :cve_nist:`2022-27405` and :cve_nist:`2022-27406`
 
 Fixes in Yocto-4.0.2
 ~~~~~~~~~~~~~~~~~~~~

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

@@ -0,0 +1,130 @@
+.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
+
+Release notes for Yocto-4.0.20 (Kirkstone)
+------------------------------------------
+
+Security Fixes in Yocto-4.0.20
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  acpica: Fix :cve_nist:`2024-24856`
+-  glib-2.0: Fix :cve_nist:`2024-34397`
+-  gstreamer1.0-plugins-base: Fix :cve_nist:`2024-4453`
+-  libxml2: Fix :cve_nist:`2024-34459`
+-  openssh: fix :cve_nist:`2024-6387`
+-  openssl: Fix :cve_mitre:`2024-4741` and :cve_nist:`2024-5535`
+-  ruby: fix :cve_nist:`2024-27280`
+-  wget: Fix for :cve_nist:`2024-38428`
+
+
+Fixes in Yocto-4.0.20
+~~~~~~~~~~~~~~~~~~~~~
+
+-  bitbake: tests/fetch: Tweak test to match upstream repo url change Upstream changed their urls, update our test to match.
+-  build-appliance-image: Update to kirkstone head revision
+-  glibc-tests: Add missing bash ptest dependency
+-  glibc-tests: correctly pull in the actual tests when installing -ptest package
+-  glibc: stable 2.35 branch updates
+-  gobject-introspection: Do not hardcode objdump name
+-  linuxloader: add -armhf on arm only for :term:`TARGET_FPU` 'hard'
+-  man-pages: add an alternative link name for crypt_r.3
+-  man-pages: remove conflict pages
+-  migration-guides: add release notes for 4.0.19
+-  openssl: Upgrade 3.0.13 -> 3.0.14
+-  poky.conf: bump version for 4.0.20
+
+
+Known Issues in Yocto-4.0.20
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+- N/A
+
+
+Contributors to Yocto-4.0.20
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  Archana Polampalli
+-  Changqing Li
+-  Deepthi Hemraj
+-  Jonas Gorski
+-  Jose Quaresma
+-  Khem Raj
+-  Lee Chee Yang
+-  Peter Marko
+-  Poonam Jadhav
+-  Siddharth Doshi
+-  Steve Sakoman
+-  Thomas Perrot
+-  Vijay Anusuri
+-  Yogita Urade
+
+
+Repositories / Downloads for Yocto-4.0.20
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+poky
+
+-  Repository Location: :yocto_git:`/poky`
+-  Branch: :yocto_git:`kirkstone </poky/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.20 </poky/log/?h=yocto-4.0.20>`
+-  Git Revision: :yocto_git:`6bd3969d32730538608e680653e032e66958fe84 </poky/commit/?id=6bd3969d32730538608e680653e032e66958fe84>`
+-  Release Artefact: poky-6bd3969d32730538608e680653e032e66958fe84
+-  sha: b7ef1bd5ba1af257c4eb07a59b51d69e147723aea010eb2da99ea30dcbbbe2d9
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.20/poky-6bd3969d32730538608e680653e032e66958fe84.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.20/poky-6bd3969d32730538608e680653e032e66958fe84.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.20 </openembedded-core/log/?h=yocto-4.0.20>`
+-  Git Revision: :oe_git:`5d97b0576e98a2cf402abab1a1edcab223545d87 </openembedded-core/commit/?id=5d97b0576e98a2cf402abab1a1edcab223545d87>`
+-  Release Artefact: oecore-5d97b0576e98a2cf402abab1a1edcab223545d87
+-  sha: 4064a32b8ff1ad8a98aa15e75b27585d2b27236c8cdfa4a28af6d6fef99b93c0
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.20/oecore-5d97b0576e98a2cf402abab1a1edcab223545d87.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.20/oecore-5d97b0576e98a2cf402abab1a1edcab223545d87.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.20 </meta-mingw/log/?h=yocto-4.0.20>`
+-  Git Revision: :yocto_git:`f6b38ce3c90e1600d41c2ebb41e152936a0357d7 </meta-mingw/commit/?id=f6b38ce3c90e1600d41c2ebb41e152936a0357d7>`
+-  Release Artefact: meta-mingw-f6b38ce3c90e1600d41c2ebb41e152936a0357d7
+-  sha: 7d57167c19077f4ab95623d55a24c2267a3a3fb5ed83688659b4c03586373b25
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.20/meta-mingw-f6b38ce3c90e1600d41c2ebb41e152936a0357d7.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.20/meta-mingw-f6b38ce3c90e1600d41c2ebb41e152936a0357d7.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.20 </meta-gplv2/log/?h=yocto-4.0.20>`
+-  Git Revision: :yocto_git:`d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a </meta-gplv2/commit/?id=d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a>`
+-  Release Artefact: meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a
+-  sha: c386f59f8a672747dc3d0be1d4234b6039273d0e57933eb87caa20f56b9cca6d
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.20/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.20/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.20 </bitbake/log/?h=yocto-4.0.20>`
+-  Git Revision: :oe_git:`734b0ea3dfe45eb16ee60f0c2c388e22af4040e0 </bitbake/commit/?id=734b0ea3dfe45eb16ee60f0c2c388e22af4040e0>`
+-  Release Artefact: bitbake-734b0ea3dfe45eb16ee60f0c2c388e22af4040e0
+-  sha: 99f4c6786fec790fd6c4577b5dea3c97c580cc4815bd409ce554a68ee99b0180
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.20/bitbake-734b0ea3dfe45eb16ee60f0c2c388e22af4040e0.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.20/bitbake-734b0ea3dfe45eb16ee60f0c2c388e22af4040e0.tar.bz2
+
+yocto-docs
+
+-  Repository Location: :yocto_git:`/yocto-docs`
+-  Branch: :yocto_git:`kirkstone </yocto-docs/log/?h=kirkstone>`
+-  Tag: :yocto_git:`yocto-4.0.20 </yocto-docs/log/?h=yocto-4.0.20>`
+-  Git Revision: :yocto_git:`b15b1d369edf33cd91232fefa0278e7e89653a01 </yocto-docs/commit/?id=b15b1d369edf33cd91232fefa0278e7e89653a01>`
+

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

@@ -0,0 +1,166 @@
+.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
+
+Release notes for Yocto-4.0.21 (Kirkstone)
+------------------------------------------
+
+Security Fixes in Yocto-4.0.21
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  bind: Fix :cve_nist:`2024-4076`, :cve_nist:`2024-1737`, :cve_nist:`2024-0760` and :cve_nist:`2024-1975`
+-  apr: Fix :cve_nist:`2023-49582`
+-  busybox: Fix :cve_nist:`2023-42363`, :cve_nist:`2023-42364`, :cve_nist:`2023-42365`, :cve_nist:`2023-42366` and :cve_nist:`2021-42380`
+-  curl: Ignore :cve_nist:`2024-32928`
+-  curl: Fix :cve_nist:`2024-7264`
+-  ghostscript: Fix :cve_nist:`2024-29506`, :cve_nist:`2024-29509` and :cve_nist:`2024-29511`
+-  go: Fix :cve_nist:`2024-24789` and :cve_nist:`2024-24791`
+-  gtk+3: Fix :cve_nist:`2024-6655`
+-  libarchive: Ignore :cve_nist:`2024-37407`
+-  libyaml: Ignore :cve_nist:`2024-35325`, :cve_nist:`2024-35326` and :cve_nist:`2024-35328`
+-  linux-yocto/5.15: Fix :cve_nist:`2022-48772`, :cve_nist:`2024-35972`, :cve_nist:`2024-35984`, :cve_nist:`2024-35990`, :cve_nist:`2024-35997`, :cve_nist:`2024-36008`, :cve_nist:`2024-36270`, :cve_nist:`2024-36489`, :cve_nist:`2024-36897`, :cve_nist:`2024-36938`, :cve_nist:`2024-36965`, :cve_nist:`2024-36967`, :cve_nist:`2024-36969`, :cve_nist:`2024-36971`, :cve_nist:`2024-36978`, :cve_nist:`2024-38546`, :cve_nist:`2024-38547`, :cve_nist:`2024-38549`, :cve_nist:`2024-38552`, :cve_nist:`2024-38555`, :cve_nist:`2024-38571`, :cve_nist:`2024-38583`, :cve_nist:`2024-38591`, :cve_nist:`2024-38597`, :cve_nist:`2024-38598`, :cve_nist:`2024-38600`, :cve_nist:`2024-38627`, :cve_nist:`2024-38633`, :cve_nist:`2024-38661`, :cve_nist:`2024-38662`, :cve_nist:`2024-38780`, :cve_nist:`2024-39277`, :cve_nist:`2024-39292`, :cve_nist:`2024-39301`, :cve_nist:`2024-39466`, :cve_nist:`2024-39468`, :cve_nist:`2024-39471`, :cve_nist:`2024-39475`, :cve_nist:`2024-39476`, :cve_nist:`2024-39480`, :cve_nist:`2024-39482`, :cve_nist:`2024-39484`, :cve_nist:`2024-39487`, :cve_nist:`2024-39489`, :cve_nist:`2024-39493`, :cve_nist:`2024-39495`, :cve_nist:`2024-39506`, :cve_nist:`2024-40902`, :cve_nist:`2024-40911`, :cve_nist:`2024-40912`, :cve_nist:`2024-40932`, :cve_nist:`2024-40934`, :cve_nist:`2024-40954`, :cve_nist:`2024-40956`, :cve_nist:`2024-40957`, :cve_nist:`2024-40958`, :cve_nist:`2024-40959`, :cve_nist:`2024-40960`, :cve_nist:`2024-40961`, :cve_nist:`2024-40967`, :cve_nist:`2024-40970`, :cve_nist:`2024-40980`, :cve_nist:`2024-40981`, :cve_nist:`2024-40994`, :cve_nist:`2024-40995`, :cve_nist:`2024-41000`, :cve_nist:`2024-41002`, :cve_nist:`2024-41006`, :cve_nist:`2024-41007`, :cve_nist:`2024-41046`, :cve_nist:`2024-41049`, :cve_nist:`2024-41055`, :cve_nist:`2024-41064`, :cve_nist:`2024-41070`, :cve_nist:`2024-41073`, :cve_nist:`2024-41087`, :cve_nist:`2024-41089`, :cve_nist:`2024-41092`, :cve_nist:`2024-41093`, :cve_nist:`2024-41095`, :cve_nist:`2024-41097`, :cve_nist:`2024-42068`, :cve_nist:`2024-42070`, :cve_nist:`2024-42076`, :cve_nist:`2024-42077`, :cve_nist:`2024-42080`, :cve_nist:`2024-42082`, :cve_nist:`2024-42085`, :cve_nist:`2024-42090`, :cve_nist:`2024-42093`, :cve_nist:`2024-42094`, :cve_nist:`2024-42101`, :cve_nist:`2024-42102`, :cve_nist:`2024-42104`, :cve_nist:`2024-42109`, :cve_nist:`2024-42140`, :cve_nist:`2024-42148`, :cve_nist:`2024-42152`, :cve_nist:`2024-42153`, :cve_nist:`2024-42154`, :cve_nist:`2024-42157`, :cve_nist:`2024-42161`, :cve_nist:`2024-42223`, :cve_nist:`2024-42224`, :cve_nist:`2024-42225`, :cve_nist:`2024-42229`, :cve_nist:`2024-42232`, :cve_nist:`2024-42236`, :cve_nist:`2024-42244` and :cve_nist:`2024-42247`
+-  llvm: Fix :cve_nist:`2023-46049` and :cve_nist:`2024-31852`
+-  ofono: fix :cve_nist:`2023-2794`
+-  orc: Fix :cve_nist:`2024-40897`
+-  python3-certifi: Fix :cve_nist:`2024-39689`
+-  python3-jinja2: Fix :cve_nist:`2024-34064`
+-  python3: Fix :cve_nist:`2024-8088`
+-  qemu: Fix :cve_nist:`2024-7409`
+-  ruby: Fix for :cve_nist:`2024-27282`
+-  tiff: Fix :cve_nist:`2024-7006`
+-  vim: Fix :cve_nist:`2024-22667`, :cve_nist:`2024-41957`, :cve_nist:`2024-41965` and :cve_nist:`2024-43374`
+-  wpa-supplicant: Fix :cve_nist:`2023-52160`
+
+
+Fixes in Yocto-4.0.21
+~~~~~~~~~~~~~~~~~~~~~
+
+-  apr: upgrade to 1.7.5
+-  bind: Upgrade to 9.18.28
+-  bitbake: data_smart: Improve performance for VariableHistory
+-  build-appliance-image: Update to kirkstone head revision
+-  cryptodev-module: Fix build for linux 5.10.220
+-  gcc-runtime: remove bashism
+-  grub: fs/fat: Don't error when mtime is 0
+-  image_types.bbclass: Use --force also with lz4,lzop
+-  libsoup: fix compile error on centos7
+-  linux-yocto/5.15: upgrade to v5.15.164
+-  lttng-modules: Upgrade to 2.13.14
+-  migration-guide: add release notes for 4.0.20
+-  orc: upgrade to 0.4.39
+-  poky.conf: bump version for 4.0.21
+-  python3-jinja2: upgrade to 3.1.4
+-  python3-pycryptodome(x): use python_setuptools_build_meta build class
+-  python3: add PACKAGECONFIG[editline]
+-  ref-manual: fix typo and move :term:`SYSROOT_DIRS` example
+-  sqlite3: CVE_ID correction for :cve_nist:`2023-7104` as patched
+-  sqlite3: Rename patch for :cve_nist:`2022-35737`
+-  uboot-sign: Fix index error in concat_dtb_helper() with multiple configs
+-  vim: upgrade to 9.1.0682
+-  wireless-regdb: upgrade to 2024.07.04
+
+
+Known Issues in Yocto-4.0.21
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+- N/A
+
+
+Contributors to Yocto-4.0.21
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  Archana Polampalli
+-  Ashish Sharma
+-  Bruce Ashfield
+-  Deepthi Hemraj
+-  Divya Chellam
+-  Florian Amstutz
+-  Guocai He
+-  Hitendra Prajapati
+-  Hugo SIMELIERE
+-  Lee Chee Yang
+-  Leon Anavi
+-  Matthias Pritschet
+-  Ming Liu
+-  Niko Mauno
+-  Peter Marko
+-  Robert Yang
+-  Rohini Sangam
+-  Ross Burton
+-  Siddharth Doshi
+-  Soumya Sambu
+-  Steve Sakoman
+-  Vijay Anusuri
+-  Vrushti Dabhi
+-  Wang Mingyu
+-  Yogita Urade
+
+
+Repositories / Downloads for Yocto-4.0.21
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+poky
+
+-  Repository Location: :yocto_git:`/poky`
+-  Branch: :yocto_git:`kirkstone </poky/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.21 </poky/log/?h=yocto-4.0.21>`
+-  Git Revision: :yocto_git:`4cdc553814640851cce85f84ee9c0b58646cd33b </poky/commit/?id=4cdc553814640851cce85f84ee9c0b58646cd33b>`
+-  Release Artefact: poky-4cdc553814640851cce85f84ee9c0b58646cd33b
+-  sha: 460e3a4ede491a9b66c5d262cd9498d5bcca1f2d880885342b08dc32b967f33d
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.21/poky-4cdc553814640851cce85f84ee9c0b58646cd33b.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.21/poky-4cdc553814640851cce85f84ee9c0b58646cd33b.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.21 </openembedded-core/log/?h=yocto-4.0.21>`
+-  Git Revision: :oe_git:`c40a3fec49942ac6d25ba33e57e801a550e252c9 </openembedded-core/commit/?id=c40a3fec49942ac6d25ba33e57e801a550e252c9>`
+-  Release Artefact: oecore-c40a3fec49942ac6d25ba33e57e801a550e252c9
+-  sha: afc2aaf312f9fb2590ae006615557ec605c98eff42bc380a1b2d6e39cfdf8930
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.21/oecore-c40a3fec49942ac6d25ba33e57e801a550e252c9.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.21/oecore-c40a3fec49942ac6d25ba33e57e801a550e252c9.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.21 </meta-mingw/log/?h=yocto-4.0.21>`
+-  Git Revision: :yocto_git:`f6b38ce3c90e1600d41c2ebb41e152936a0357d7 </meta-mingw/commit/?id=f6b38ce3c90e1600d41c2ebb41e152936a0357d7>`
+-  Release Artefact: meta-mingw-f6b38ce3c90e1600d41c2ebb41e152936a0357d7
+-  sha: 7d57167c19077f4ab95623d55a24c2267a3a3fb5ed83688659b4c03586373b25
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.21/meta-mingw-f6b38ce3c90e1600d41c2ebb41e152936a0357d7.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.21/meta-mingw-f6b38ce3c90e1600d41c2ebb41e152936a0357d7.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.21 </meta-gplv2/log/?h=yocto-4.0.21>`
+-  Git Revision: :yocto_git:`d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a </meta-gplv2/commit/?id=d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a>`
+-  Release Artefact: meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a
+-  sha: c386f59f8a672747dc3d0be1d4234b6039273d0e57933eb87caa20f56b9cca6d
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.21/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.21/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.21 </bitbake/log/?h=yocto-4.0.21>`
+-  Git Revision: :oe_git:`ec2a99a077da9aa0e99e8b05e0c65dcbd45864b1 </bitbake/commit/?id=ec2a99a077da9aa0e99e8b05e0c65dcbd45864b1>`
+-  Release Artefact: bitbake-ec2a99a077da9aa0e99e8b05e0c65dcbd45864b1
+-  sha: 1cb102f4c8dbd067f0262072e4e629ec7cb423103111ccdde75a09fcb8f55e5f
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.21/bitbake-ec2a99a077da9aa0e99e8b05e0c65dcbd45864b1.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.21/bitbake-ec2a99a077da9aa0e99e8b05e0c65dcbd45864b1.tar.bz2
+
+yocto-docs
+
+-  Repository Location: :yocto_git:`/yocto-docs`
+-  Branch: :yocto_git:`kirkstone </yocto-docs/log/?h=kirkstone>`
+-  Tag: :yocto_git:`yocto-4.0.21 </yocto-docs/log/?h=yocto-4.0.21>`
+-  Git Revision: :yocto_git:`512025edd9b3b6b8d0938b35bb6188c9f3b7f17d </yocto-docs/commit/?id=512025edd9b3b6b8d0938b35bb6188c9f3b7f17d>`
+

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

@@ -0,0 +1,196 @@
+.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
+
+Release notes for Yocto-4.0.22 (Kirkstone)
+------------------------------------------
+
+Security Fixes in Yocto-4.0.22
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  cups: Fix :cve_nist:`2024-35235` and :cve_nist:`2024-47175`
+-  curl: Fix :cve_nist:`2024-8096`
+-  expat: Fix :cve_nist:`2024-45490`, :cve_nist:`2024-45491` and :cve_nist:`2024-45492`
+-  gnupg: Ignore :cve_nist:`2022-3219`
+-  libpcap: Fix :cve_nist:`2023-7256` and :cve_nist:`2024-8006`
+-  linux-yocto/5.10: Fix :cve_nist:`2022-48772`, :cve_nist:`2023-52434`, :cve_nist:`2023-52447`, :cve_nist:`2023-52458`, :cve_nist:`2024-0841`, :cve_nist:`2024-26601`, :cve_nist:`2024-26882`, :cve_nist:`2024-26883`, :cve_nist:`2024-26884`, :cve_nist:`2024-26885`, :cve_nist:`2024-26898`, :cve_nist:`2024-26901`, :cve_nist:`2024-26903`, :cve_nist:`2024-26907`, :cve_nist:`2024-26934`, :cve_nist:`2024-26978`, :cve_nist:`2024-27013`, :cve_nist:`2024-27020`, :cve_nist:`2024-35972`, :cve_nist:`2024-35978`, :cve_nist:`2024-35982`, :cve_nist:`2024-35984`, :cve_nist:`2024-35990`, :cve_nist:`2024-35997`, :cve_nist:`2024-36008`, :cve_nist:`2024-36270`, :cve_nist:`2024-36489`, :cve_nist:`2024-36902`, :cve_nist:`2024-36971`, :cve_nist:`2024-36978`, :cve_nist:`2024-38546`, :cve_nist:`2024-38547`, :cve_nist:`2024-38549`, :cve_nist:`2024-38552`, :cve_nist:`2024-38555`, :cve_nist:`2024-38583`, :cve_nist:`2024-38590`, :cve_nist:`2024-38597`, :cve_nist:`2024-38598`, :cve_nist:`2024-38627`, :cve_nist:`2024-38633`, :cve_nist:`2024-38661`, :cve_nist:`2024-38662`, :cve_nist:`2024-38780`, :cve_nist:`2024-39292`, :cve_nist:`2024-39301`, :cve_nist:`2024-39468`, :cve_nist:`2024-39471`, :cve_nist:`2024-39475`, :cve_nist:`2024-39476`, :cve_nist:`2024-39480`, :cve_nist:`2024-39482`, :cve_nist:`2024-39484`, :cve_nist:`2024-39487`, :cve_nist:`2024-39489`, :cve_nist:`2024-39495`, :cve_nist:`2024-39506`, :cve_nist:`2024-40902`, :cve_nist:`2024-40904`, :cve_nist:`2024-40905`, :cve_nist:`2024-40912`, :cve_nist:`2024-40932`, :cve_nist:`2024-40934`, :cve_nist:`2024-40958`, :cve_nist:`2024-40959`, :cve_nist:`2024-40960`, :cve_nist:`2024-40961`, :cve_nist:`2024-40980`, :cve_nist:`2024-40981`, :cve_nist:`2024-40995`, :cve_nist:`2024-41000`, :cve_nist:`2024-41006`, :cve_nist:`2024-41007`, :cve_nist:`2024-41012`, :cve_nist:`2024-41040`, :cve_nist:`2024-41046`, :cve_nist:`2024-41049`, :cve_nist:`2024-41059`, :cve_nist:`2024-41063`, :cve_nist:`2024-41064`, :cve_nist:`2024-41070`, :cve_nist:`2024-41087`, :cve_nist:`2024-41089`, :cve_nist:`2024-41092`, :cve_nist:`2024-41095`, :cve_nist:`2024-41097`, :cve_nist:`2024-42070`, :cve_nist:`2024-42076`, :cve_nist:`2024-42077`, :cve_nist:`2024-42082`, :cve_nist:`2024-42090`, :cve_nist:`2024-42093`, :cve_nist:`2024-42094`, :cve_nist:`2024-42101`, :cve_nist:`2024-42102`, :cve_nist:`2024-42104`, :cve_nist:`2024-42131`, :cve_nist:`2024-42137`, :cve_nist:`2024-42148`, :cve_nist:`2024-42152`, :cve_nist:`2024-42153`, :cve_nist:`2024-42154`, :cve_nist:`2024-42157`, :cve_nist:`2024-42161`, :cve_nist:`2024-42223`, :cve_nist:`2024-42224`, :cve_nist:`2024-42229`, :cve_nist:`2024-42232`, :cve_nist:`2024-42236`, :cve_nist:`2024-42244` and :cve_nist:`2024-42247`
+-  linux-yocto/5.15: Fix :cve_nist:`2023-52889`, :cve_nist:`2024-41011`, :cve_nist:`2024-42114`, :cve_nist:`2024-42259`, :cve_nist:`2024-42271`, :cve_nist:`2024-42272`, :cve_nist:`2024-42277`, :cve_nist:`2024-42280`, :cve_nist:`2024-42283`, :cve_nist:`2024-42284`, :cve_nist:`2024-42285`, :cve_nist:`2024-42286`, :cve_nist:`2024-42287`, :cve_nist:`2024-42288`, :cve_nist:`2024-42289`, :cve_nist:`2024-42301`, :cve_nist:`2024-42302`, :cve_nist:`2024-42309`, :cve_nist:`2024-42310`, :cve_nist:`2024-42311`, :cve_nist:`2024-42313`, :cve_nist:`2024-43817`, :cve_nist:`2024-43828`, :cve_nist:`2024-43854`, :cve_nist:`2024-43856`, :cve_nist:`2024-43858`, :cve_nist:`2024-43860`, :cve_nist:`2024-43861`, :cve_nist:`2024-43863`, :cve_nist:`2024-43871`, :cve_nist:`2024-43873`, :cve_nist:`2024-43882`, :cve_nist:`2024-43889`, :cve_nist:`2024-43890`, :cve_nist:`2024-43893`, :cve_nist:`2024-43894`, :cve_nist:`2024-43902`, :cve_nist:`2024-43907`, :cve_nist:`2024-43908`, :cve_nist:`2024-43909`, :cve_nist:`2024-43914`, :cve_nist:`2024-44934`, :cve_nist:`2024-44935`, :cve_nist:`2024-44944`, :cve_nist:`2024-44947`, :cve_nist:`2024-44952`, :cve_nist:`2024-44954`, :cve_nist:`2024-44958`, :cve_nist:`2024-44960`, :cve_nist:`2024-44965`, :cve_nist:`2024-44966`, :cve_nist:`2024-44969`, :cve_nist:`2024-44971`, :cve_nist:`2024-44982`, :cve_nist:`2024-44983`, :cve_nist:`2024-44985`, :cve_nist:`2024-44986`, :cve_nist:`2024-44987`, :cve_nist:`2024-44988`, :cve_nist:`2024-44989`, :cve_nist:`2024-44990`, :cve_nist:`2024-44995`, :cve_nist:`2024-44998`, :cve_nist:`2024-44999`, :cve_nist:`2024-45003`, :cve_nist:`2024-45006`, :cve_nist:`2024-45011`, :cve_nist:`2024-45016`, :cve_nist:`2024-45018`, :cve_nist:`2024-45021`, :cve_nist:`2024-45025`, :cve_nist:`2024-45026`, :cve_nist:`2024-45028`, :cve_nist:`2024-46673`, :cve_nist:`2024-46674`, :cve_nist:`2024-46675`, :cve_nist:`2024-46676`, :cve_nist:`2024-46677`, :cve_nist:`2024-46679`, :cve_nist:`2024-46685`, :cve_nist:`2024-46689`, :cve_nist:`2024-46702` and :cve_nist:`2024-46707`
+-  openssl: Fix :cve_nist:`2024-6119`
+-  procps: Fix :cve_nist:`2023-4016`
+-  python3: Fix :cve_nist:`2023-27043`, :cve_nist:`2024-4030`, :cve_nist:`2024-4032`, :cve_nist:`2024-6923`, :cve_nist:`2024-6232`, :cve_nist:`2024-7592` and :cve_nist:`2024-8088`
+-  qemu: Fix :cve_nist:`2024-4467`
+-  rust: Ignore :cve_nist:`2024-43402`
+-  webkitgtk: Fix :cve_nist:`2024-40779`
+-  wpa-supplicant: Ignore :cve_nist:`2024-5290`
+-  wpa-supplicant: Fix :cve_nist:`2024-3596`
+
+
+Fixes in Yocto-4.0.22
+~~~~~~~~~~~~~~~~~~~~~
+
+-  bintuils: stable 2.38 branch update
+-  bitbake: fetch2/wget: Canonicalize :term:`DL_DIR` paths for wget2 compatibility
+-  bitbake: fetch/wget: Move files into place atomically
+-  bitbake: hashserv: tests: Omit client in slow server start test
+-  bitbake: tests/fetch: Tweak to work on Fedora40
+-  bitbake: wget: Make wget --passive-ftp option conditional on ftp/ftps
+-  build-appliance-image: Update to kirkstone head revision
+-  buildhistory: Fix intermittent package file list creation
+-  buildhistory: Restoring files from preserve list
+-  buildhistory: Simplify intercept call sites and drop SSTATEPOSTINSTFUNC usage
+-  busybox: Fix cut with "-s" flag
+-  cdrtools-native: fix build with gcc-14
+-  curl: free old conn better on reuse
+-  cve-exclusion: Drop the version comparision/warning
+-  dejagnu: Fix :term:`LICENSE` (change to GPL-3.0-only)
+-  doc/features: remove duplicate word in distribution feature ext2
+-  gcc: upgrade to v11.5
+-  gcr: Fix :term:`LICENSE` (change to LGPL-2.0-only)
+-  glibc: stable 2.35 branch updates
+-  install-buildtools: fix "test installation" step
+-  install-buildtools: remove md5 checksum validation
+-  install-buildtools: support buildtools-make-tarball and update to 4.1
+-  iw: Fix :term:`LICENSE` (change to ISC)
+-  kmscube: Add patch to fix -int-conversion build error
+-  lib/oeqa: rename assertRaisesRegexp to assertRaisesRegex
+-  libedit: Make docs generation deterministic
+-  linux-yocto/5.10: fix NFSV3 config warning
+-  linux-yocto/5.10: remove obsolete options
+-  linux-yocto/5.10: update to v5.10.223
+-  linux-yocto/5.15: update to v5.15.166
+-  meta-world-pkgdata: Inherit nopackages
+-  migration-guide: add release notes for 4.0.21
+-  openssl: Upgrade to 3.0.15
+-  poky.conf: bump version for 4.0.22
+-  populate_sdk_base: inherit nopackages
+-  python3: Upgrade to 3.10.15
+-  ruby: Make docs generation deterministic
+-  runqemu: keep generating tap devices
+-  scripts/install-buildtools: Update to 4.0.21
+-  selftest/runtime_test/virgl: Disable for all fedora
+-  testexport: fallback for empty :term:`IMAGE_LINK_NAME`
+-  testimage: fallback for empty :term:`IMAGE_LINK_NAME`
+-  tiff: Fix :term:`LICENSE` (change to libtiff)
+-  udev-extraconf: Add collect flag to mount
+-  unzip: Fix :term:`LICENSE` (change to Info-ZIP)
+-  valgrind: disable avx_estimate_insn.vgtest
+-  wpa-supplicant: Patch security advisory 2024-2
+-  yocto-uninative: Update to 4.5 for gcc 14
+-  yocto-uninative: Update to 4.6 for glibc 2.40
+-  zip: Fix :term:`LICENSE` (change to Info-ZIP)
+-  zstd: fix :term:`LICENSE` statement (change to "BSD-3-Clause | GPL-2.0-only")
+
+
+Known Issues in Yocto-4.0.22
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  ``oeqa/runtime``: the ``beaglebone-yocto`` target fails the ``parselogs``
+   runtime test due to unexpected kernel error messages in the log (see
+   :yocto_bugs:`bug 15624 </show_bug.cgi?id=15624>` on Bugzilla).
+
+
+Contributors to Yocto-4.0.22
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  Aleksandar Nikolic
+-  Alexandre Belloni
+-  Archana Polampalli
+-  Bruce Ashfield
+-  Colin McAllister
+-  Deepthi Hemraj
+-  Divya Chellam
+-  Hitendra Prajapati
+-  Hugo SIMELIERE
+-  Jinfeng Wang
+-  Joshua Watt
+-  Jörg Sommer
+-  Konrad Weihmann
+-  Lee Chee Yang
+-  Martin Jansa
+-  Massimiliano Minella
+-  Michael Halstead
+-  Mingli Yu
+-  Niko Mauno
+-  Paul Eggleton
+-  Pedro Ferreira
+-  Peter Marko
+-  Purushottam Choudhary
+-  Richard Purdie
+-  Rob Woolley
+-  Rohini Sangam
+-  Ross Burton
+-  Rudolf J Streif
+-  Siddharth Doshi
+-  Steve Sakoman
+-  Vijay Anusuri
+-  Vivek Kumbhar
+
+
+Repositories / Downloads for Yocto-4.0.22
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+poky
+
+-  Repository Location: :yocto_git:`/poky`
+-  Branch: :yocto_git:`kirkstone </poky/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.22 </poky/log/?h=yocto-4.0.22>`
+-  Git Revision: :yocto_git:`7e87dc422d972e0dc98372318fcdc63a76347d16 </poky/commit/?id=7e87dc422d972e0dc98372318fcdc63a76347d16>`
+-  Release Artefact: poky-7e87dc422d972e0dc98372318fcdc63a76347d16
+-  sha: 5058e7b2474f8cb73c19e776ef58d9784321ef42109d5982747c8c432531239f
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.22/poky-7e87dc422d972e0dc98372318fcdc63a76347d16.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.22/poky-7e87dc422d972e0dc98372318fcdc63a76347d16.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.22 </openembedded-core/log/?h=yocto-4.0.22>`
+-  Git Revision: :oe_git:`f09fca692f96c9c428e89c5ef53fbcb92ac0c9bf </openembedded-core/commit/?id=f09fca692f96c9c428e89c5ef53fbcb92ac0c9bf>`
+-  Release Artefact: oecore-f09fca692f96c9c428e89c5ef53fbcb92ac0c9bf
+-  sha: 378bcc840ba9fbf06a15fea1b5dacdd446f3ad4d85115d708e7bbb20629cdeb4
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.22/oecore-f09fca692f96c9c428e89c5ef53fbcb92ac0c9bf.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.22/oecore-f09fca692f96c9c428e89c5ef53fbcb92ac0c9bf.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.22 </meta-mingw/log/?h=yocto-4.0.22>`
+-  Git Revision: :yocto_git:`f6b38ce3c90e1600d41c2ebb41e152936a0357d7 </meta-mingw/commit/?id=f6b38ce3c90e1600d41c2ebb41e152936a0357d7>`
+-  Release Artefact: meta-mingw-f6b38ce3c90e1600d41c2ebb41e152936a0357d7
+-  sha: 7d57167c19077f4ab95623d55a24c2267a3a3fb5ed83688659b4c03586373b25
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.22/meta-mingw-f6b38ce3c90e1600d41c2ebb41e152936a0357d7.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.22/meta-mingw-f6b38ce3c90e1600d41c2ebb41e152936a0357d7.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.22 </meta-gplv2/log/?h=yocto-4.0.22>`
+-  Git Revision: :yocto_git:`d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a </meta-gplv2/commit/?id=d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a>`
+-  Release Artefact: meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a
+-  sha: c386f59f8a672747dc3d0be1d4234b6039273d0e57933eb87caa20f56b9cca6d
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.22/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.22/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.22 </bitbake/log/?h=yocto-4.0.22>`
+-  Git Revision: :oe_git:`eb5c1ce6b1b8f33535ff7b9263ec7648044163ea </bitbake/commit/?id=eb5c1ce6b1b8f33535ff7b9263ec7648044163ea>`
+-  Release Artefact: bitbake-eb5c1ce6b1b8f33535ff7b9263ec7648044163ea
+-  sha: 473d3e9539160633f3de9d88cce69123f6c623e4c8ab35beb7875868564593cf
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.22/bitbake-eb5c1ce6b1b8f33535ff7b9263ec7648044163ea.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.22/bitbake-eb5c1ce6b1b8f33535ff7b9263ec7648044163ea.tar.bz2
+
+yocto-docs
+
+-  Repository Location: :yocto_git:`/yocto-docs`
+-  Branch: :yocto_git:`kirkstone </yocto-docs/log/?h=kirkstone>`
+-  Tag: :yocto_git:`yocto-4.0.22 </yocto-docs/log/?h=yocto-4.0.22>`
+-  Git Revision: :yocto_git:`2169a52a24ebd1906039c42632bae6c4285a3aca </yocto-docs/commit/?id=2169a52a24ebd1906039c42632bae6c4285a3aca>`
+

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

@@ -0,0 +1,209 @@
+.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
+
+Release notes for Yocto-4.0.23 (Kirkstone)
+------------------------------------------
+
+Security Fixes in Yocto-4.0.23
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  ``curl``: Fix :cve_nist:`2024-9681`
+-  ``expat``: Fix :cve_nist:`2024-50602`
+-  ``gcc``: Ignore :cve_nist:`2023-4039`
+-  ``ghostscript``: Fix :cve_nist:`2023-46361` and :cve_nist:`2024-29508`
+-  ``gstreamer1.0``: Ignore :cve_nist:`2024-0444`
+-  ``libarchive``: Fix :cve_nist:`2024-48957` and :cve_nist:`2024-48958`
+-  ``openssl``: Fix :cve_nist:`2024-9143`
+-  ``orc``: Fix :cve_nist:`2024-40897`
+-  ``python3``: Ignore :cve_nist:`2023-27043`, :cve_nist:`2024-6232` and :cve_nist:`2024-7592`
+-  ``qemu``: Fix :cve_nist:`2023-3019`
+-  ``vim``: Fix :cve_nist:`2024-43790`, :cve_nist:`2024-43802`, :cve_nist:`2024-45306` and :cve_nist:`2024-47814`
+-  ``zstd``: Fix :cve_nist:`2022-4899`
+
+
+Fixes in Yocto-4.0.23
+~~~~~~~~~~~~~~~~~~~~~
+
+-  at-spi2-core: backport a patch to fix build with gcc-14 on host
+-  bitbake: bitbake: doc/user-manual: Update the BB_HASHSERVE_UPSTREAM
+-  bitbake: codeparser: Fix handling of string AST nodes with older Python versions
+-  bitbake: fetch2/git: Use quote from shlex, not pipes
+-  bitbake: gitsm: Add call_process_submodules() to remove duplicated code
+-  bitbake: gitsm: Remove downloads/tmpdir when failed
+-  bitbake: tests/fetch: Use our own mirror of mobile-broadband-provider to decouple from gnome gitlab
+-  bitbake: tests/fetch: Use our own mirror of sysprof to decouple from gnome gitlab
+-  bmap-tools: update :term:`HOMEPAGE` and :term:`SRC_URI`
+-  build-appliance-image: Update to kirkstone head revision
+-  cmake: Fix sporadic issues when determining compiler internals
+-  cracklib: Modify patch to compile with GCC 14
+-  cve-check: add CVSS vector string to CVE database and reports
+-  cve-check: add support for cvss v4.0
+-  cve_check: Use a local copy of the database during builds
+-  dev-manual: document how to provide confs from layer.conf
+-  documentation: Makefile: add SPHINXLINTDOCS to specify subset to sphinx-lint
+-  documentation: Makefile: fix epub and latexpdf targets
+-  documentation: README: add instruction to run Vale on a subset
+-  documentation: brief-yoctoprojectqs: update BB_HASHSERVE_UPSTREAM for new infrastructure
+-  documentation: conf.py: add a bitbake_git extlink
+-  documentation: rename :cve: role to :cve_nist:
+-  documentation: styles: vocabularies: Yocto: add sstate
+-  documnetation: contributor-guide: Remove duplicated words
+-  gcc: restore a patch for Neoverse N2 core
+-  glib-2.0: patch regression of :cve_nist:`2023-32665`
+-  kmscube: create_framebuffer: backport modifier fix
+-  libffi: backport a fix to build libffi-native with gcc-14
+-  linux-firmware: Upgrade to 20240909
+-  local.conf.sample: update BB_HASHSERVE_UPSTREAM for new infrastructure
+-  migration-guide: add release notes for 4.0.22
+-  migration-guide: release-notes-4.0: update BB_HASHSERVE_UPSTREAM for new infrastructure
+-  nativesdk-intercept: Fix bad intercept chgrp/chown logic
+-  orc: Upgrade to  0.4.40
+-  overlayfs-etc: add option to skip creation of mount dirs
+-  overview-manual: concepts: add details on package splitting
+-  package: Switch debug source handling to use prefix map
+-  patch.py: Use shlex instead of deprecated pipe
+-  poky.conf: bump version for 4.0.23
+-  pseudo: Disable LFS on 32bit arches
+-  pseudo: Fix envp bug and add posix_spawn wrapper
+-  pseudo: Fix to work with glibc 2.40
+-  pseudo: Switch back to the master branch
+-  pseudo: Update to include logic fix
+-  pseudo: Update to include open symlink handling bugfix
+-  pseudo: Update to pull in fchmodat fix
+-  pseudo: Update to pull in fd leak fix
+-  pseudo: Update to pull in gcc14 fix and missing statvfs64 intercept
+-  pseudo: Update to pull in linux-libc-headers race fix
+-  pseudo: Update to pull in python 3.12+ fix
+-  pseudo: Update to pull in syncfs probe fix
+-  ref-manual: add description for the "sysroot" term
+-  ref-manual: add missing CVE_CHECK manifest variables
+-  ref-manual: add missing :term:`EXTERNAL_KERNEL_DEVICETREE` variable
+-  ref-manual: add missing :term:`OPKGBUILDCMD` variable
+-  ref-manual: devtool-reference: document missing commands
+-  ref-manual: devtool-reference: refresh example outputs
+-  ref-manual: introduce :term:`CVE_CHECK_REPORT_PATCHED` variable
+-  ref-manual: release-process: add a reference to the doc's release
+-  ref-manual: release-process: refresh the current LTS releases
+-  ref-manual: release-process: update releases.svg
+-  ref-manual: release-process: update releases.svg with month after "Current"
+-  ref-manual: structure.rst: document missing tmp/ dirs
+-  ref-manual: variables: add SIGGEN_LOCKEDSIGS* variables
+-  syslinux: Disable error on implicit-function-declaration
+-  util-linux: Define pidfd_* function signatures
+-  vala: add -Wno-error=incompatible-pointer-types work around
+-  vim: Upgrade to 9.1.0764
+-  xmlto: backport a patch to fix build with gcc-14 on host
+-  zip: Fix build with gcc-14
+-  zip: Make configure checks to be more robust
+
+
+Known Issues in Yocto-4.0.23
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-N/A
+
+
+Contributors to Yocto-4.0.23
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  Aleksandar Nikolic
+-  Alexandre Belloni
+-  Antoine Lubineau
+-  Antonin Godard
+-  Archana Polampalli
+-  Ashish Sharma
+-  Baruch Siach
+-  Eilís 'pidge' Ní Fhlannagáin
+-  Jose Quaresma
+-  Julien Stephan
+-  Khem Raj
+-  Lee Chee Yang
+-  Macpaul Lin
+-  Martin Jansa
+-  Michael Opdenacker
+-  Ola x Nilsson
+-  Peter Marko
+-  Philip Lorenz
+-  Randolph Sapp
+-  Richard Purdie
+-  Robert Yang
+-  Rohini Sangam
+-  Ruiqiang Hao
+-  Siddharth Doshi
+-  Steve Sakoman
+-  Talel BELHAJSALEM
+-  Wang Mingyu
+-  Yogita Urade
+-  Zoltan Boszormenyi
+
+
+Repositories / Downloads for Yocto-4.0.23
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+poky
+
+-  Repository Location: :yocto_git:`/poky`
+-  Branch: :yocto_git:`kirkstone </poky/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.23 </poky/log/?h=yocto-4.0.23>`
+-  Git Revision: :yocto_git:`8e092852b63e998d990b8f8e1aa91297dec4430f </poky/commit/?id=8e092852b63e998d990b8f8e1aa91297dec4430f>`
+-  Release Artefact: poky-8e092852b63e998d990b8f8e1aa91297dec4430f
+-  sha: 339d34d8432070dac948449e732ebf06a888eeb27ff548958b2395c9446b029d
+-  Download Locations:
+   https://downloads.yoctoproject.org/releases/yocto/yocto-4.0.23/poky-8e092852b63e998d990b8f8e1aa91297dec4430f.tar.bz2
+   https://mirrors.kernel.org/yocto/yocto/yocto-4.0.23/poky-8e092852b63e998d990b8f8e1aa91297dec4430f.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.23 </openembedded-core/log/?h=yocto-4.0.23>`
+-  Git Revision: :oe_git:`fb45c5cf8c2b663af293acb069d446610f77ff1a </openembedded-core/commit/?id=fb45c5cf8c2b663af293acb069d446610f77ff1a>`
+-  Release Artefact: oecore-fb45c5cf8c2b663af293acb069d446610f77ff1a
+-  sha: 1d394370ea7d43fb885ab8a952d6d1e43f1a850745a5152d5ead5565a283a0f5
+-  Download Locations:
+   https://downloads.yoctoproject.org/releases/yocto/yocto-4.0.23/oecore-fb45c5cf8c2b663af293acb069d446610f77ff1a.tar.bz2
+   https://mirrors.kernel.org/yocto/yocto/yocto-4.0.23/oecore-fb45c5cf8c2b663af293acb069d446610f77ff1a.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.23 </meta-mingw/log/?h=yocto-4.0.23>`
+-  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.23/meta-mingw-87c22abb1f11be430caf4372e6b833dc7d77564e.tar.bz2
+   https://mirrors.kernel.org/yocto/yocto/yocto-4.0.23/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.23 </meta-gplv2/log/?h=yocto-4.0.23>`
+-  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.23/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2
+   https://mirrors.kernel.org/yocto/yocto/yocto-4.0.23/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.23 </bitbake/log/?h=yocto-4.0.23>`
+-  Git Revision: :oe_git:`fb73c495c45d1d4107cfd60b67a5b4f11a99647b </bitbake/commit/?id=fb73c495c45d1d4107cfd60b67a5b4f11a99647b>`
+-  Release Artefact: bitbake-fb73c495c45d1d4107cfd60b67a5b4f11a99647b
+-  sha: 5cd271299951f25912a2e8d4de6d8769a4c0bb3bbcfc90815be41f23fd299a0b
+-  Download Locations:
+   https://downloads.yoctoproject.org/releases/yocto/yocto-4.0.23/bitbake-fb73c495c45d1d4107cfd60b67a5b4f11a99647b.tar.bz2
+   https://mirrors.kernel.org/yocto/yocto/yocto-4.0.23/bitbake-fb73c495c45d1d4107cfd60b67a5b4f11a99647b.tar.bz2
+
+yocto-docs
+
+-  Repository Location: :yocto_git:`/yocto-docs`
+-  Branch: :yocto_git:`kirkstone </yocto-docs/log/?h=kirkstone>`
+-  Tag: :yocto_git:`yocto-4.0.23 </yocto-docs/log/?h=yocto-4.0.23>`
+-  Git Revision: :yocto_git:`TBD </yocto-docs/commit/?id=TBD>`
+
+

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

@@ -0,0 +1,383 @@
+Release notes for Yocto-4.0.24 (Kirkstone)
+------------------------------------------
+
+Security Fixes in Yocto-4.0.24
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  coreutils: Fix :cve_nist:`2024-0684`
+-  cpio: Ignore :cve_nist:`2023-7216`
+-  diffoscope: Fix :cve_nist:`2024-25711`
+-  ffmpeg: fix :cve_mitre:`2023-47342`, :cve_nist:`2023-50007`, :cve_nist:`2023-50008`,
+   :cve_nist:`2023-51793`, :cve_nist:`2023-51794`, :cve_nist:`2023-51796`, :cve_nist:`2023-51798`,
+   :cve_nist:`2024-7055`, :cve_nist:`2024-31578`, :cve_nist:`2024-31582`, :cve_nist:`2024-32230`,
+   :cve_nist:`2024-35366`, :cve_nist:`2024-35367` and :cve_nist:`2024-35368`
+-  ghostscript: Fix :cve_nist:`2024-46951`, :cve_nist:`2024-46952`, :cve_nist:`2024-46953`,
+   :cve_nist:`2024-46955` and :cve_nist:`2024-46956`
+-  ghostscript: Ignore :cve_nist:`2024-46954`
+-  glib-2.0: Fix :cve_nist:`2024-52533`
+-  gnupg: Ignore :cve_nist:`2022-3515`
+-  grub: Ignore :cve_nist:`2024-1048` and :cve_nist:`2023-4001`
+-  gstreame1.0: Ignore :cve_nist:`2023-40474`, :cve_nist:`2023-40475`, :cve_nist:`2023-40476`,
+   :cve_nist:`2023-44429`, :cve_nist:`2023-44446`, :cve_nist:`2023-50186` and :cve_nist:`2024-0444`
+-  gstreamer1.0-plugins-base: Fix :cve_nist:`2024-47538`, :cve_nist:`2024-47541`,
+   :cve_nist:`2024-47542`, :cve_nist:`2024-47600`, :cve_nist:`2024-47607`, :cve_nist:`2024-47615`
+   and :cve_nist:`2024-47835`
+-  gstreamer1.0-plugins-good: Fix :cve_nist:`2024-47537`, :cve_nist:`2024-47539`,
+   :cve_nist:`2024-47540`, :cve_nist:`2024-47543`, :cve_nist:`2024-47544`, :cve_nist:`2024-47545`,
+   :cve_nist:`2024-47546`, :cve_nist:`2024-47596`, :cve_nist:`2024-47597`, :cve_nist:`2024-47598`,
+   :cve_nist:`2024-47599`, :cve_nist:`2024-47601`, :cve_nist:`2024-47602`, :cve_nist:`2024-47603`,
+   :cve_nist:`2024-47606`, :cve_nist:`2024-47613`, :cve_nist:`2024-47774`, :cve_nist:`2024-47775`,
+   :cve_nist:`2024-47776`, :cve_nist:`2024-47777`, :cve_nist:`2024-47778` and :cve_nist:`2024-47834`
+-  gstreamer1.0: Fix :cve_nist:`2024-47606`
+-  libarchive: Fix :cve_nist:`2024-20696`
+-  libpam: Fix :cve_nist:`2024-10041`
+-  libsdl2: Ignore :cve_nist:`2020-14409` and :cve_nist:`2020-14410`
+-  libsndfile1: Fix :cve_nist:`2022-33065` and :cve_nist:`2024-50612`
+-  libsoup-2.4: Fix :cve_nist:`2024-52530`, :cve_nist:`2024-52531` and :cve_nist:`2024-52532`
+-  libsoup: Fix :cve_nist:`2024-52530`, :cve_nist:`2024-52531` and :cve_nist:`2024-52532`
+-  linux-yocto/5.10: Fix :cve_nist:`2023-52889`, :cve_nist:`2023-52917`, :cve_nist:`2023-52918`,
+   :cve_nist:`2024-41011`, :cve_nist:`2024-42259`, :cve_nist:`2024-42271`, :cve_nist:`2024-42272`,
+   :cve_nist:`2024-42280`, :cve_nist:`2024-42283`, :cve_nist:`2024-42284`, :cve_nist:`2024-42285`,
+   :cve_nist:`2024-42286`, :cve_nist:`2024-42287`, :cve_nist:`2024-42288`, :cve_nist:`2024-42289`,
+   :cve_nist:`2024-42301`, :cve_nist:`2024-42302`, :cve_nist:`2024-42309`, :cve_nist:`2024-42310`,
+   :cve_nist:`2024-42311`, :cve_nist:`2024-42313`, :cve_nist:`2024-43828`, :cve_nist:`2024-43856`,
+   :cve_nist:`2024-43858`, :cve_nist:`2024-43860`, :cve_nist:`2024-43861`, :cve_nist:`2024-43871`,
+   :cve_nist:`2024-43882`, :cve_nist:`2024-43889`, :cve_nist:`2024-43890`, :cve_nist:`2024-43893`,
+   :cve_nist:`2024-43894`, :cve_nist:`2024-43907`, :cve_nist:`2024-43908`, :cve_nist:`2024-43914`,
+   :cve_nist:`2024-44935`, :cve_nist:`2024-44944`, :cve_nist:`2024-44947`, :cve_nist:`2024-44954`,
+   :cve_nist:`2024-44960`, :cve_nist:`2024-44965`, :cve_nist:`2024-44969`, :cve_nist:`2024-44971`,
+   :cve_nist:`2024-44987`, :cve_nist:`2024-44988`, :cve_nist:`2024-44989`, :cve_nist:`2024-44990`,
+   :cve_nist:`2024-44995`, :cve_nist:`2024-44998`, :cve_nist:`2024-44999`, :cve_nist:`2024-45003`,
+   :cve_nist:`2024-45006`, :cve_nist:`2024-45016`, :cve_nist:`2024-45018`, :cve_nist:`2024-45021`,
+   :cve_nist:`2024-45025`, :cve_nist:`2024-45026`, :cve_nist:`2024-45028`, :cve_nist:`2024-46673`,
+   :cve_nist:`2024-46674`, :cve_nist:`2024-46675`, :cve_nist:`2024-46676`, :cve_nist:`2024-46677`,
+   :cve_nist:`2024-46679`, :cve_nist:`2024-46685`, :cve_nist:`2024-46689`, :cve_nist:`2024-46702`,
+   :cve_nist:`2024-46707`, :cve_nist:`2024-46714`, :cve_nist:`2024-46719`, :cve_nist:`2024-46721`,
+   :cve_nist:`2024-46722`, :cve_nist:`2024-46723`, :cve_nist:`2024-46724`, :cve_nist:`2024-46725`,
+   :cve_nist:`2024-46731`, :cve_nist:`2024-46737`, :cve_nist:`2024-46738`, :cve_nist:`2024-46739`,
+   :cve_nist:`2024-46740`, :cve_nist:`2024-46743`, :cve_nist:`2024-46744`, :cve_nist:`2024-46747`,
+   :cve_nist:`2024-46750`, :cve_nist:`2024-46755`, :cve_nist:`2024-46759`, :cve_nist:`2024-46761`,
+   :cve_nist:`2024-46763`, :cve_nist:`2024-46771`, :cve_nist:`2024-46777`, :cve_nist:`2024-46780`,
+   :cve_nist:`2024-46781`, :cve_nist:`2024-46782`, :cve_nist:`2024-46783`, :cve_nist:`2024-46791`,
+   :cve_nist:`2024-46798`, :cve_nist:`2024-46800`, :cve_nist:`2024-46804`, :cve_nist:`2024-46814`,
+   :cve_nist:`2024-46815`, :cve_nist:`2024-46817`, :cve_nist:`2024-46818`, :cve_nist:`2024-46819`,
+   :cve_nist:`2024-46822`, :cve_nist:`2024-46828`, :cve_nist:`2024-46829`, :cve_nist:`2024-46832`,
+   :cve_nist:`2024-46840`, :cve_nist:`2024-46844`, :cve_nist:`2024-47659`, :cve_nist:`2024-47660`,
+   :cve_nist:`2024-47663`, :cve_nist:`2024-47667`, :cve_nist:`2024-47668`, :cve_nist:`2024-47669`,
+   :cve_nist:`2024-47679`, :cve_nist:`2024-47684`, :cve_nist:`2024-47685`, :cve_nist:`2024-47692`,
+   :cve_nist:`2024-47697`, :cve_nist:`2024-47698`, :cve_nist:`2024-47699`, :cve_nist:`2024-47701`,
+   :cve_nist:`2024-47705`, :cve_nist:`2024-47706`, :cve_nist:`2024-47710`, :cve_nist:`2024-47712`,
+   :cve_nist:`2024-47713`, :cve_nist:`2024-47718`, :cve_nist:`2024-47723`, :cve_nist:`2024-47735`,
+   :cve_nist:`2024-47737`, :cve_nist:`2024-47739`, :cve_nist:`2024-47742`, :cve_nist:`2024-47747`,
+   :cve_nist:`2024-47748`, :cve_nist:`2024-47749`, :cve_nist:`2024-47757`, :cve_nist:`2024-49851`,
+   :cve_nist:`2024-49858`, :cve_nist:`2024-49860`, :cve_nist:`2024-49863`, :cve_nist:`2024-49867`,
+   :cve_nist:`2024-49868`, :cve_nist:`2024-49875`, :cve_nist:`2024-49877`, :cve_nist:`2024-49878`,
+   :cve_nist:`2024-49879`, :cve_nist:`2024-49881`, :cve_nist:`2024-49882`, :cve_nist:`2024-49883`,
+   :cve_nist:`2024-49884`, :cve_nist:`2024-49889`, :cve_nist:`2024-49890`, :cve_nist:`2024-49892`,
+   :cve_nist:`2024-49894`, :cve_nist:`2024-49895`, :cve_nist:`2024-49896`, :cve_nist:`2024-49900`,
+   :cve_nist:`2024-49902`, :cve_nist:`2024-49903`, :cve_nist:`2024-49907`, :cve_nist:`2024-49913`,
+   :cve_nist:`2024-49924`, :cve_nist:`2024-49930`, :cve_nist:`2024-49933`, :cve_nist:`2024-49936`,
+   :cve_nist:`2024-49938`, :cve_nist:`2024-49944`, :cve_nist:`2024-49948`, :cve_nist:`2024-49949`,
+   :cve_nist:`2024-49952`, :cve_nist:`2024-49955`, :cve_nist:`2024-49957`, :cve_nist:`2024-49958`,
+   :cve_nist:`2024-49959`, :cve_nist:`2024-49962`, :cve_nist:`2024-49963`, :cve_nist:`2024-49965`,
+   :cve_nist:`2024-49966`, :cve_nist:`2024-49969`, :cve_nist:`2024-49973`, :cve_nist:`2024-49975`,
+   :cve_nist:`2024-49977`, :cve_nist:`2024-49981`, :cve_nist:`2024-49982`, :cve_nist:`2024-49983`,
+   :cve_nist:`2024-49985`, :cve_nist:`2024-49995`, :cve_nist:`2024-49997`, :cve_nist:`2024-50001`,
+   :cve_nist:`2024-50006`, :cve_nist:`2024-50007`, :cve_nist:`2024-50008`, :cve_nist:`2024-50013`,
+   :cve_nist:`2024-50015`, :cve_nist:`2024-50024`, :cve_nist:`2024-50033`, :cve_nist:`2024-50035`,
+   :cve_nist:`2024-50039`, :cve_nist:`2024-50040`, :cve_nist:`2024-50044`, :cve_nist:`2024-50045`,
+   :cve_nist:`2024-50046`, :cve_nist:`2024-50049`, :cve_nist:`2024-50059`, :cve_nist:`2024-50095`,
+   :cve_nist:`2024-50096`, :cve_nist:`2024-50179`, :cve_nist:`2024-50180`, :cve_nist:`2024-50181`,
+   :cve_nist:`2024-50184` and :cve_nist:`2024-50188`
+-  linux-yocto/5.15: Fix :cve_nist:`2022-48695`, :cve_nist:`2023-52530`, :cve_nist:`2023-52917`,
+   :cve_nist:`2024-45009`, :cve_nist:`2024-46714`, :cve_nist:`2024-46719`, :cve_nist:`2024-46721`,
+   :cve_nist:`2024-46722`, :cve_nist:`2024-46723`, :cve_nist:`2024-46724`, :cve_nist:`2024-46725`,
+   :cve_nist:`2024-46731`, :cve_nist:`2024-46732`, :cve_nist:`2024-46737`, :cve_nist:`2024-46738`,
+   :cve_nist:`2024-46739`, :cve_nist:`2024-46740`, :cve_nist:`2024-46743`, :cve_nist:`2024-46744`,
+   :cve_nist:`2024-46746`, :cve_nist:`2024-46747`, :cve_nist:`2024-46750`, :cve_nist:`2024-46755`,
+   :cve_nist:`2024-46759`, :cve_nist:`2024-46761`, :cve_nist:`2024-46763`, :cve_nist:`2024-46771`,
+   :cve_nist:`2024-46777`, :cve_nist:`2024-46780`, :cve_nist:`2024-46781`, :cve_nist:`2024-46782`,
+   :cve_nist:`2024-46783`, :cve_nist:`2024-46791`, :cve_nist:`2024-46795`, :cve_nist:`2024-46798`,
+   :cve_nist:`2024-46800`, :cve_nist:`2024-46804`, :cve_nist:`2024-46805`, :cve_nist:`2024-46807`,
+   :cve_nist:`2024-46810`, :cve_nist:`2024-46814`, :cve_nist:`2024-46815`, :cve_nist:`2024-46817`,
+   :cve_nist:`2024-46818`, :cve_nist:`2024-46819`, :cve_nist:`2024-46822`, :cve_nist:`2024-46828`,
+   :cve_nist:`2024-46829`, :cve_nist:`2024-46832`, :cve_nist:`2024-46840`, :cve_nist:`2024-46844`,
+   :cve_nist:`2024-47659`, :cve_nist:`2024-47660`, :cve_nist:`2024-47663`, :cve_nist:`2024-47665`,
+   :cve_nist:`2024-47667`, :cve_nist:`2024-47668`, :cve_nist:`2024-47669`, :cve_nist:`2024-47674`,
+   :cve_nist:`2024-47679`, :cve_nist:`2024-47684`, :cve_nist:`2024-47685`, :cve_nist:`2024-47690`,
+   :cve_nist:`2024-47692`, :cve_nist:`2024-47693`, :cve_nist:`2024-47695`, :cve_nist:`2024-47696`,
+   :cve_nist:`2024-47697`, :cve_nist:`2024-47698`, :cve_nist:`2024-47699`, :cve_nist:`2024-47701`,
+   :cve_nist:`2024-47705`, :cve_nist:`2024-47706`, :cve_nist:`2024-47710`, :cve_nist:`2024-47712`,
+   :cve_nist:`2024-47713`, :cve_nist:`2024-47718`, :cve_nist:`2024-47720`, :cve_nist:`2024-47723`,
+   :cve_nist:`2024-47734`, :cve_nist:`2024-47735`, :cve_nist:`2024-47737`, :cve_nist:`2024-47739`,
+   :cve_nist:`2024-47742`, :cve_nist:`2024-47747`, :cve_nist:`2024-47748`, :cve_nist:`2024-47749`,
+   :cve_nist:`2024-47757`, :cve_nist:`2024-49851`, :cve_nist:`2024-49852`, :cve_nist:`2024-49854`,
+   :cve_nist:`2024-49856`, :cve_nist:`2024-49858`, :cve_nist:`2024-49860`, :cve_nist:`2024-49863`,
+   :cve_nist:`2024-49866`, :cve_nist:`2024-49867`, :cve_nist:`2024-49868`, :cve_nist:`2024-49871`,
+   :cve_nist:`2024-49875`, :cve_nist:`2024-49877`, :cve_nist:`2024-49878`, :cve_nist:`2024-49879`,
+   :cve_nist:`2024-49881`, :cve_nist:`2024-49882`, :cve_nist:`2024-49883`, :cve_nist:`2024-49884`,
+   :cve_nist:`2024-49886`, :cve_nist:`2024-49889`, :cve_nist:`2024-49890`, :cve_nist:`2024-49892`,
+   :cve_nist:`2024-49894`, :cve_nist:`2024-49895`, :cve_nist:`2024-49896`, :cve_nist:`2024-49900`,
+   :cve_nist:`2024-49902`, :cve_nist:`2024-49903`, :cve_nist:`2024-49907`, :cve_nist:`2024-49913`,
+   :cve_nist:`2024-49924`, :cve_nist:`2024-49927`, :cve_nist:`2024-49930`, :cve_nist:`2024-49933`,
+   :cve_nist:`2024-49935`, :cve_nist:`2024-49936`, :cve_nist:`2024-49938`, :cve_nist:`2024-49944`,
+   :cve_nist:`2024-49946`, :cve_nist:`2024-49948`, :cve_nist:`2024-49949`, :cve_nist:`2024-49952`,
+   :cve_nist:`2024-49954`, :cve_nist:`2024-49955`, :cve_nist:`2024-49957`, :cve_nist:`2024-49958`,
+   :cve_nist:`2024-49959`, :cve_nist:`2024-49962`, :cve_nist:`2024-49963`, :cve_nist:`2024-49965`,
+   :cve_nist:`2024-49966`, :cve_nist:`2024-49969`, :cve_nist:`2024-49973`, :cve_nist:`2024-49975`,
+   :cve_nist:`2024-49977`, :cve_nist:`2024-49981`, :cve_nist:`2024-49982`, :cve_nist:`2024-49983`,
+   :cve_nist:`2024-49985`, :cve_nist:`2024-49995`, :cve_nist:`2024-49997`, :cve_nist:`2024-50000`,
+   :cve_nist:`2024-50001`, :cve_nist:`2024-50002`, :cve_nist:`2024-50003`, :cve_nist:`2024-50006`,
+   :cve_nist:`2024-50007`, :cve_nist:`2024-50008`, :cve_nist:`2024-50013`, :cve_nist:`2024-50015`,
+   :cve_nist:`2024-50019`, :cve_nist:`2024-50024`, :cve_nist:`2024-50031`, :cve_nist:`2024-50033`,
+   :cve_nist:`2024-50035`, :cve_nist:`2024-50038`, :cve_nist:`2024-50039`, :cve_nist:`2024-50040`,
+   :cve_nist:`2024-50041`, :cve_nist:`2024-50044`, :cve_nist:`2024-50045`, :cve_nist:`2024-50046`,
+   :cve_nist:`2024-50049`, :cve_nist:`2024-50059`, :cve_nist:`2024-50062`, :cve_nist:`2024-50074`,
+   :cve_nist:`2024-50082`, :cve_nist:`2024-50083`, :cve_nist:`2024-50093`, :cve_nist:`2024-50095`,
+   :cve_nist:`2024-50096`, :cve_nist:`2024-50099`, :cve_nist:`2024-50101`, :cve_nist:`2024-50103`,
+   :cve_nist:`2024-50110`, :cve_nist:`2024-50115`, :cve_nist:`2024-50116`, :cve_nist:`2024-50117`,
+   :cve_nist:`2024-50127`, :cve_nist:`2024-50128`, :cve_nist:`2024-50131`, :cve_nist:`2024-50134`,
+   :cve_nist:`2024-50141`, :cve_nist:`2024-50142`, :cve_nist:`2024-50143`, :cve_nist:`2024-50148`,
+   :cve_nist:`2024-50150`, :cve_nist:`2024-50151`, :cve_nist:`2024-50153`, :cve_nist:`2024-50154`,
+   :cve_nist:`2024-50156`, :cve_nist:`2024-50160`, :cve_nist:`2024-50162`, :cve_nist:`2024-50163`,
+   :cve_nist:`2024-50167`, :cve_nist:`2024-50168`, :cve_nist:`2024-50171`, :cve_nist:`2024-50179`,
+   :cve_nist:`2024-50180`, :cve_nist:`2024-50181`, :cve_nist:`2024-50182`, :cve_nist:`2024-50184`,
+   :cve_nist:`2024-50185`, :cve_nist:`2024-50186`, :cve_nist:`2024-50188`, :cve_nist:`2024-50189`,
+   :cve_nist:`2024-50191`, :cve_nist:`2024-50192`, :cve_nist:`2024-50193`, :cve_nist:`2024-50194`,
+   :cve_nist:`2024-50195`, :cve_nist:`2024-50196`, :cve_nist:`2024-50198`, :cve_nist:`2024-50201`,
+   :cve_nist:`2024-50202`, :cve_nist:`2024-50205`, :cve_nist:`2024-50208`, :cve_nist:`2024-50209`,
+   :cve_nist:`2024-50229`, :cve_nist:`2024-50230`, :cve_nist:`2024-50232`, :cve_nist:`2024-50233`,
+   :cve_nist:`2024-50234`, :cve_nist:`2024-50236`, :cve_nist:`2024-50237`, :cve_nist:`2024-50244`,
+   :cve_nist:`2024-50245`, :cve_nist:`2024-50247`, :cve_nist:`2024-50251`, :cve_nist:`2024-50257`,
+   :cve_nist:`2024-50259`, :cve_nist:`2024-50262`, :cve_nist:`2024-50264`, :cve_nist:`2024-50265`,
+   :cve_nist:`2024-50267`, :cve_nist:`2024-50268`, :cve_nist:`2024-50269`, :cve_nist:`2024-50273`,
+   :cve_nist:`2024-50278`, :cve_nist:`2024-50279`, :cve_nist:`2024-50282`, :cve_nist:`2024-50287`,
+   :cve_nist:`2024-50292`, :cve_nist:`2024-50296`, :cve_nist:`2024-50299`, :cve_nist:`2024-50301`,
+   :cve_nist:`2024-50302`, :cve_nist:`2024-53052`, :cve_nist:`2024-53055`, :cve_nist:`2024-53057`,
+   :cve_nist:`2024-53058`, :cve_nist:`2024-53059`, :cve_nist:`2024-53060`, :cve_nist:`2024-53061`,
+   :cve_nist:`2024-53063`, :cve_nist:`2024-53066`, :cve_nist:`2024-53088`, :cve_nist:`2024-53096`,
+   :cve_nist:`2024-53101`, :cve_nist:`2024-53103`, :cve_nist:`2024-53145`, :cve_nist:`2024-53146`,
+   :cve_nist:`2024-53150`, :cve_nist:`2024-53151`, :cve_nist:`2024-53155`, :cve_nist:`2024-53156`,
+   :cve_nist:`2024-53157`, :cve_nist:`2024-53165`, :cve_nist:`2024-53171`, :cve_nist:`2024-53173`,
+   :cve_nist:`2024-53226`, :cve_nist:`2024-53227`, :cve_nist:`2024-53237`, :cve_nist:`2024-56567`,
+   :cve_nist:`2024-56572`, :cve_nist:`2024-56574`, :cve_nist:`2024-56578`, :cve_nist:`2024-56581`,
+   :cve_nist:`2024-56593`, :cve_nist:`2024-56600`, :cve_nist:`2024-56601`, :cve_nist:`2024-56602`,
+   :cve_nist:`2024-56603`, :cve_nist:`2024-56605`, :cve_nist:`2024-56606`, :cve_nist:`2024-56614`,
+   :cve_nist:`2024-56622`, :cve_nist:`2024-56623`, :cve_nist:`2024-56629`, :cve_nist:`2024-56634`,
+   :cve_nist:`2024-56640`, :cve_nist:`2024-56642`, :cve_nist:`2024-56643`, :cve_nist:`2024-56648`,
+   :cve_nist:`2024-56650`, :cve_nist:`2024-56659`, :cve_nist:`2024-56662`, :cve_nist:`2024-56670`,
+   :cve_nist:`2024-56688`, :cve_nist:`2024-56694`, :cve_nist:`2024-56704`, :cve_nist:`2024-56708`,
+   :cve_nist:`2024-56720`, :cve_nist:`2024-56723`, :cve_nist:`2024-56724`, :cve_nist:`2024-56726`,
+   :cve_nist:`2024-56728`, :cve_nist:`2024-56739`, :cve_nist:`2024-56741`, :cve_nist:`2024-56745`,
+   :cve_nist:`2024-56746`, :cve_nist:`2024-56747`, :cve_nist:`2024-56748`, :cve_nist:`2024-56754`,
+   :cve_nist:`2024-56756`, :cve_nist:`2024-56770`, :cve_nist:`2024-56774`, :cve_nist:`2024-56776`,
+   :cve_nist:`2024-56777`, :cve_nist:`2024-56778`, :cve_nist:`2024-56779`, :cve_nist:`2024-56780`,
+   :cve_nist:`2024-56781`, :cve_nist:`2024-56785` and :cve_nist:`2024-56787`
+-  ovmf: Fix :cve_nist:`2022-36763`, :cve_nist:`2022-36764`, :cve_nist:`2022-36765`,
+   :cve_nist:`2023-45229`, :cve_nist:`2023-45230`, :cve_nist:`2023-45231`, :cve_nist:`2023-45232`,
+   :cve_nist:`2023-45233`, :cve_nist:`2023-45234`, :cve_nist:`2023-45235`, :cve_nist:`2023-45236`,
+   :cve_nist:`2023-45237`, :cve_nist:`2024-1298` and :cve_nist:`2024-38796`
+-  pixman: Ignore :cve_nist:`2023-37769`
+-  python3: Fix :cve_nist:`2024-9287`, :cve_nist:`2024-11168` and :cve_nist:`2024-50602`
+-  python3-pip: Fix :cve_nist:`2023-5752`
+-  python3-requests: Fix :cve_nist:`2024-35195`
+-  python3-zipp: Fix :cve_nist:`2024-5569`
+-  qemu: Fix :cve_nist:`2024-3446`, :cve_nist:`2024-3447` and :cve_nist:`2024-6505`
+-  qemu: Ignore :cve_nist:`2022-36648`
+-  subversion: Fix :cve_nist:`2024-46901`
+-  tiff: Fix :cve_nist:`2023-3164`
+-  tiff: Ignore :cve_nist:`2023-2731`
+-  webkitgtk: Fix :cve_nist:`2024-40776` and :cve_nist:`2024-40780`
+-  xserver-xorg: Fix :cve_nist:`2024-9632`
+-  xwayland: Fix :cve_nist:`2023-5380` and :cve_nist:`2024-0229`
+
+
+Fixes in Yocto-4.0.24
+~~~~~~~~~~~~~~~~~~~~~
+
+-  base-passwd: Add the sgx group
+-  base-passwd: Regenerate the patches
+-  base-passwd: Update the status for two patches
+-  base-passwd: Update to 3.5.52
+-  base-passwd: add the wheel group
+-  base-passwd: fix patchreview warning
+-  bitbake: fetch2: use persist_data context managers
+-  bitbake: fetch/wget: Increase timeout to 100s from 30s
+-  bitbake: persist_data: close connection in SQLTable __exit__
+-  build-appliance-image: Update to kirkstone head revision
+-  builder: set :term:`CVE_PRODUCT`
+-  contributor-guide: submit-changes.rst: suggest to remove the git signature
+-  cve-update-nvd2-native: Tweak to work better with NFS :term:`DL_DIR`
+-  dbus: disable assertions and enable only modular tests
+-  do_package/sstate/sstatesig: Change timestamp clamping to hash output only
+-  docs: Gather dependencies in poky.yaml.in
+-  docs: standards.md: add a section on admonitions
+-  gstreamer1.0: improve test reliability
+-  linux-yocto/5.10: update to v5.10.227
+-  linux-yocto/5.15: update to v5.15.175
+-  llvm: reduce size of -dbg package
+-  lttng-modules: fix build error after kernel update to 5.15.171
+-  migration-guides: add release notes for 4.0.23
+-  ninja: fix build with python 3.13
+-  oeqa/utils/gitarchive: Return tag name and improve exclude handling
+-  ovmf-native: remove .pyc files from install
+-  package.bbclass: Use shlex instead of deprecated pipes
+-  package_rpm: restrict rpm to 4 threads
+-  package_rpm: use zstd's default compression level
+-  poky.conf: add new tested distros
+-  poky.conf: bump version for 4.0.24
+-  poky.yaml.in: add missing locales dependency
+-  python3: upgrade to 3.10.16
+-  ref-manual: SSTATE_MIRRORS/SOURCE_MIRROR_URL: add instructions for mirror authentication
+-  ref-manual: classes: fix bin_package description
+-  ref-manual: devtool-reference: add warning note on deploy-target and shared objects
+-  ref-manual: move runtime-testing section to the test-manual
+-  ref-manual: packages: move ptest section to the test-manual
+-  ref-manual: system-requirements: update list of supported distros
+-  ref-manual: use standardized method accross both ubuntu and debian for locale install
+-  resulttool: Add --logfile-archive option to store mode
+-  resulttool: Allow store to filter to specific revisions
+-  resulttool: Clean up repoducible build logs
+-  resulttool: Fix passthrough of --all files in store mode
+-  resulttool: Handle ltp rawlogs as well as ptest
+-  resulttool: Improve repo layout for oeselftest results
+-  resulttool: Trim the precision of duration information
+-  resulttool: Use single space indentation in json output
+-  rootfs-postcommands.bbclass: make opkg status reproducible
+-  rxvt-unicode.inc: disable the terminfo installation by setting TIC to :
+-  sanity: check for working user namespaces
+-  scripts/install-buildtools: Update to 4.0.22
+-  selftest/reproducible: Clean up pathnames
+-  selftest/reproducible: Drop rawlogs
+-  test-manual: reproducible-builds.rst: document :term:`OEQA_REPRODUCIBLE_TEST_TARGET` and
+   :term:`OEQA_REPRODUCIBLE_TEST_SSTATE_TARGETS`
+-  test-manual: reproducible-builds.rst: show how to build a single package
+-  toolchain-shar-extract.sh: exit when post-relocate-setup.sh fails
+-  tzdata & tzcode-native: upgrade 2024b
+-  udev-extraconf: fix network.sh script did not configure hotplugged interfaces
+-  unzip: Fix configure tests to use modern C
+-  webkitgtk: Fix build on 32bit arm
+-  webkitgtk: fix perl-native dependency
+-  webkitgtk: reduce size of -dbg package
+-  wireless-regdb: upgrade to 2024.10.07
+
+
+Known Issues in Yocto-4.0.24
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+- N/A
+
+Contributors to Yocto-4.0.24
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Thanks to the following people who contributed to this release:
+
+-  Aleksandar Nikolic
+-  Alex Kiernan
+-  Alexander Kanavin
+-  Alexandre Belloni
+-  Antonin Godard
+-  Archana Polampalli
+-  Bruce Ashfield
+-  Changqing Li
+-  Chen Qi
+-  Chris Laplante
+-  Divya Chellam
+-  Ernst Persson
+-  Guénaël Muller
+-  Hitendra Prajapati
+-  Hongxu Jia
+-  Jiaying Song
+-  Jinfeng Wang
+-  Khem Raj
+-  Lee Chee Yang
+-  Liyin Zhang
+-  Louis Rannou
+-  Markus Volk
+-  Mikko Rapeli
+-  Ovidiu Panait
+-  Peter Kjellerstedt
+-  Peter Marko
+-  Regis Dargent
+-  Richard Purdie
+-  Rohini Sangam
+-  Ross Burton
+-  Soumya Sambu
+-  Steve Sakoman
+-  Trevor Gamblin
+-  Vijay Anusuri
+-  Wang Mingyu
+-  Yogita Urade
+-  Zahir Hussain
+
+
+Repositories / Downloads for Yocto-4.0.24
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+poky
+
+-  Repository Location: :yocto_git:`/poky`
+-  Branch: :yocto_git:`kirkstone </poky/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.24 </poky/log/?h=yocto-4.0.24>`
+-  Git Revision: :yocto_git:`f50532593651dff82bc952288d786c55038c2c86 </poky/commit/?id=f50532593651dff82bc952288d786c55038c2c86>`
+-  Release Artefact: poky-f50532593651dff82bc952288d786c55038c2c86
+-  sha: 0aa062d19510394748db9a2d6ded2d764f435383296d9c94fb6b25755280556e
+-  Download Locations:
+   https://downloads.yoctoproject.org/releases/yocto/yocto-4.0.24/poky-f50532593651dff82bc952288d786c55038c2c86.tar.bz2
+   https://mirrors.kernel.org/yocto/yocto/yocto-4.0.24/poky-f50532593651dff82bc952288d786c55038c2c86.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.24 </openembedded-core/log/?h=yocto-4.0.24>`
+-  Git Revision: :oe_git:`a270d4c957259761bcc7382fcc54642a02f9fc7d </openembedded-core/commit/?id=a270d4c957259761bcc7382fcc54642a02f9fc7d>`
+-  Release Artefact: oecore-a270d4c957259761bcc7382fcc54642a02f9fc7d
+-  sha: b08b9b16c8ffa587d521ad28e24e38c79d757a6f0839d18165ebac3081a34b68
+-  Download Locations:
+   https://downloads.yoctoproject.org/releases/yocto/yocto-4.0.24/oecore-a270d4c957259761bcc7382fcc54642a02f9fc7d.tar.bz2
+   https://mirrors.kernel.org/yocto/yocto/yocto-4.0.24/oecore-a270d4c957259761bcc7382fcc54642a02f9fc7d.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.24 </meta-mingw/log/?h=yocto-4.0.24>`
+-  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.24/meta-mingw-87c22abb1f11be430caf4372e6b833dc7d77564e.tar.bz2
+   https://mirrors.kernel.org/yocto/yocto/yocto-4.0.24/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.24 </meta-gplv2/log/?h=yocto-4.0.24>`
+-  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.24/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2
+   https://mirrors.kernel.org/yocto/yocto/yocto-4.0.24/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.24 </bitbake/log/?h=yocto-4.0.24>`
+-  Git Revision: :oe_git:`3f88b005244a0afb5d5c7260e54a94a453ec9b3e </bitbake/commit/?id=3f88b005244a0afb5d5c7260e54a94a453ec9b3e>`
+-  Release Artefact: bitbake-3f88b005244a0afb5d5c7260e54a94a453ec9b3e
+-  sha: 31f442b72ec7d81ca75509b1a7179c3fe3942528b1e31c823b21a413244bd15b
+-  Download Locations:
+   https://downloads.yoctoproject.org/releases/yocto/yocto-4.0.24/bitbake-3f88b005244a0afb5d5c7260e54a94a453ec9b3e.tar.bz2
+   https://mirrors.kernel.org/yocto/yocto/yocto-4.0.24/bitbake-3f88b005244a0afb5d5c7260e54a94a453ec9b3e.tar.bz2
+
+yocto-docs
+
+-  Repository Location: :yocto_git:`/yocto-docs`
+-  Branch: :yocto_git:`kirkstone </yocto-docs/log/?h=kirkstone>`
+-  Tag: :yocto_git:`yocto-4.0.24 </yocto-docs/log/?h=yocto-4.0.24>`
+-  Git Revision: :yocto_git:`3128bf149f40928e6c2a3e264590a0c6c9778c6a </yocto-docs/commit/?id=3128bf149f40928e6c2a3e264590a0c6c9778c6a>`
+