build-appliance-image: Update to scarthgap head revision

Bump b-a SRCREV again to pull in docs changes.

(From OE-Core rev: 70dc15941dd33270a92d1001174efb3093e79bdf)

Signed-off-by: Paul Barker <paul@pbarker.dev>

bitbake/README

@@ -24,7 +24,7 @@ for full details on how to submit changes.
 As a quick guide, patches should be sent to bitbake-devel@lists.openembedded.org
 The git command to do that would be:
 
-    git send-email -M -1 --to bitbake-devel@lists.openembedded.org
+    git send-email -M -1 --to bitbake-devel@lists.openembedded.org --subject-prefix='2.8][PATCH'
 
 If you're sending a patch related to the BitBake manual, make sure you copy
 the Yocto Project documentation mailing list:

bitbake/lib/bb/data.py

@@ -377,7 +377,7 @@ def generate_dependencies(d, ignored_vars):
     mod_funcs = set(bb.codeparser.modulecode_deps.keys())
     keys = set(key for key in d if not key.startswith("__")) | mod_funcs
     shelldeps = set(key for key in d.getVar("__exportlist", False) if bb.utils.to_boolean(d.getVarFlag(key, "export")) and not bb.utils.to_boolean(d.getVarFlag(key, "unexport")))
-    varflagsexcl = d.getVar('BB_SIGNATURE_EXCLUDE_FLAGS')
+    varflagsexcl = (d.getVar('BB_SIGNATURE_EXCLUDE_FLAGS') or "").split()
 
     codeparserd = d.createCopy()
     for forced in (d.getVar('BB_HASH_CODEPARSER_VALS') or "").split():

bitbake/lib/bb/fetch2/__init__.py

@@ -23,6 +23,7 @@ import collections
 import subprocess
 import pickle
 import errno
+import shlex
 import bb.persist_data, bb.utils
 import bb.checksum
 import bb.process
@@ -1519,7 +1520,10 @@ class FetchMethod(object):
         if unpack:
             tar_cmd = 'tar --extract --no-same-owner'
             if 'striplevel' in urldata.parm:
-                tar_cmd += ' --strip-components=%s' %  urldata.parm['striplevel']
+                striplevel = urldata.parm['striplevel']
+                if not striplevel.isdigit():
+                    raise UnpackError("Invalid striplevel parameter: %s" % striplevel, urldata.url)
+                tar_cmd += ' --strip-components=%s' % striplevel
             if file.endswith('.tar'):
                 cmd = '%s -f %s' % (tar_cmd, file)
             elif file.endswith('.tgz') or file.endswith('.tar.gz') or file.endswith('.tar.Z'):
@@ -1559,24 +1563,27 @@ class FetchMethod(object):
             elif file.endswith('.rpm') or file.endswith('.srpm'):
                 if 'extract' in urldata.parm:
                     unpack_file = urldata.parm.get('extract')
-                    cmd = 'rpm2cpio.sh %s | cpio -id %s' % (file, unpack_file)
+                    cmd = 'rpm2cpio.sh %s | cpio --no-absolute-filenames -id %s' % (file, unpack_file)
                     iterate = True
                     iterate_file = unpack_file
                 else:
-                    cmd = 'rpm2cpio.sh %s | cpio -id' % (file)
+                    cmd = 'rpm2cpio.sh %s | cpio --no-absolute-filenames -id' % (file)
             elif file.endswith('.deb') or file.endswith('.ipk'):
                 output = subprocess.check_output(['ar', '-t', file], preexec_fn=subprocess_setup)
                 datafile = None
+                valid_datafiles = ('data.tar', 'data.tar.gz', 'data.tar.xz',
+                                   'data.tar.zst', 'data.tar.bz2', 'data.tar.lzma')
                 if output:
                     for line in output.decode().splitlines():
-                        if line.startswith('data.tar.'):
+                        if line in valid_datafiles:
                             datafile = line
                             break
                     else:
-                        raise UnpackError("Unable to unpack deb/ipk package - does not contain data.tar.* file", urldata.url)
+                        raise UnpackError("Unable to unpack deb/ipk package - does not contain supported data.tar* file", urldata.url)
                 else:
                     raise UnpackError("Unable to unpack deb/ipk package - could not list contents", urldata.url)
-                cmd = 'ar x %s %s && %s -p -f %s && rm %s' % (file, datafile, tar_cmd, datafile, datafile)
+                quoted_datafile = shlex.quote(datafile)
+                cmd = 'ar x %s %s && %s -p -f %s && rm %s' % (shlex.quote(file), quoted_datafile, tar_cmd, quoted_datafile, quoted_datafile)
 
         # If 'subdir' param exists, create a dir and use it as destination for unpack cmd
         if 'subdir' in urldata.parm:

bitbake/lib/bb/fetch2/crate.py

@@ -68,8 +68,11 @@ class Crate(Wget):
         # if using upstream just fix it up nicely
         if host == 'crates.io':
             host = 'crates.io/api/v1/crates'
+            cdn_host = 'static.crates.io/crates'
+        else:
+            cdn_host = host
 
-        ud.url = "https://%s/%s/%s/download" % (host, name, version)
+        ud.url = "https://%s/%s/%s/download" % (cdn_host, name, version)
         ud.parm['downloadfilename'] = "%s-%s.crate" % (name, version)
         if 'name' not in ud.parm:
             ud.parm['name'] = '%s-%s' % (name, version)

bitbake/lib/bb/fetch2/git.py

@@ -399,14 +399,14 @@ class Git(FetchMethod):
                 bb.utils.mkdirhier(ud.clonedir)
                 runfetchcmd("tar -xzf %s" % ud.fullmirror, d, workdir=ud.clonedir)
             else:
-                tmpdir = tempfile.mkdtemp(dir=d.getVar('DL_DIR'))
+                with tempfile.TemporaryDirectory(dir=d.getVar('DL_DIR')) as tmpdir:
-                runfetchcmd("tar -xzf %s" % ud.fullmirror, d, workdir=tmpdir)
+                    runfetchcmd("tar -xzf %s" % ud.fullmirror, d, workdir=tmpdir)
-                output = runfetchcmd("%s remote" % ud.basecmd, d, quiet=True, workdir=ud.clonedir)
+                    output = runfetchcmd("%s remote" % ud.basecmd, d, quiet=True, workdir=ud.clonedir)
-                if 'mirror' in output:
+                    if 'mirror' in output:
-                    runfetchcmd("%s remote rm mirror" % ud.basecmd, d, workdir=ud.clonedir)
+                        runfetchcmd("%s remote rm mirror" % ud.basecmd, d, workdir=ud.clonedir)
-                runfetchcmd("%s remote add --mirror=fetch mirror %s" % (ud.basecmd, tmpdir), d, workdir=ud.clonedir)
+                    runfetchcmd("%s remote add --mirror=fetch mirror %s" % (ud.basecmd, tmpdir), d, workdir=ud.clonedir)
-                fetch_cmd = "LANG=C %s fetch -f --update-head-ok  --progress mirror " % (ud.basecmd)
+                    fetch_cmd = "LANG=C %s fetch -f --update-head-ok  --progress mirror " % (ud.basecmd)
-                runfetchcmd(fetch_cmd, d, workdir=ud.clonedir)
+                    runfetchcmd(fetch_cmd, d, workdir=ud.clonedir)
         repourl = self._get_repo_url(ud)
 
         needs_clone = False
@@ -602,7 +602,7 @@ class Git(FetchMethod):
         shallow_cmd = [self.make_shallow_path, '-s']
         for b in shallow_branches:
             shallow_cmd.append('-r')
-            shallow_cmd.append(b)
+            shallow_cmd.append(shlex.quote(b))
         shallow_cmd.extend(shallow_revisions)
         runfetchcmd(subprocess.list2cmdline(shallow_cmd), d, workdir=dest)
 

bitbake/lib/bb/fetch2/wget.py

@@ -303,15 +303,70 @@ class Wget(FetchMethod):
             http_error_403 = http_error_405
 
 
+        def _url_origin(url):
+            parsed = urllib.parse.urlsplit(url)
+            scheme = parsed.scheme.lower()
+            host = parsed.hostname.lower() if parsed.hostname else ""
+            port = parsed.port
+            if port is None:
+                port = {"http": 80, "https": 443}.get(scheme)
+            return (scheme, host, port)
+
+        def _same_origin(url_a, url_b):
+            return _url_origin(url_a) == _url_origin(url_b)
+
         class FixedHTTPRedirectHandler(urllib.request.HTTPRedirectHandler):
             """
-            urllib2.HTTPRedirectHandler resets the method to GET on redirect,
+            urllib2.HTTPRedirectHandler before 3.13 has two flaws:
-            when we want to follow redirects using the original method.
+            
+            It resets the method to GET on redirect when we want to follow
+            redirects using the original method (typically HEAD). This was fixed
+            in 759e8e7.
+
+            It also doesn't handle 308 (Permanent Redirect). This was fixed in
+            c379bc5.
+
+            Until we depend on Python 3.13 onwards, copy the redirect_request
+            method to fix these issues.
+
+            Additionally, strip sensitive headers (Authorization, Cookie) when
+            redirecting to a different origin to avoid credential leaks.
             """
             def redirect_request(self, req, fp, code, msg, headers, newurl):
-                newreq = urllib.request.HTTPRedirectHandler.redirect_request(self, req, fp, code, msg, headers, newurl)
+                m = req.get_method()
-                newreq.get_method = req.get_method
+                if (not (code in (301, 302, 303, 307, 308) and m in ("GET", "HEAD")
-                return newreq
+                    or code in (301, 302, 303) and m == "POST")):
+                    raise urllib.HTTPError(req.full_url, code, msg, headers, fp)
+
+                # Strictly (according to RFC 2616), 301 or 302 in response to
+                # a POST MUST NOT cause a redirection without confirmation
+                # from the user (of urllib.request, in this case).  In practice,
+                # essentially all clients do redirect in this case, so we do
+                # the same.
+
+                # Be conciliant with URIs containing a space.  This is mainly
+                # redundant with the more complete encoding done in http_error_302(),
+                # but it is kept for compatibility with other callers.
+                newurl = newurl.replace(' ', '%20')
+
+                CONTENT_HEADERS = ("content-length", "content-type")
+                SENSITIVE_REDIRECT_HEADERS = ("authorization", "cookie")
+                same_origin = _same_origin(req.get_full_url(), newurl)
+                newheaders = {}
+                for k, v in req.headers.items():
+                    header = k.lower()
+                    if header in CONTENT_HEADERS:
+                        continue
+                    if not same_origin and header in SENSITIVE_REDIRECT_HEADERS:
+                        continue
+                    newheaders[k] = v
+                return urllib.request.Request(newurl,
+                            method="HEAD" if m == "HEAD" else "GET",
+                            headers=newheaders,
+                            origin_req_host=req.origin_req_host,
+                            unverifiable=True)
+
+            http_error_308 = urllib.request.HTTPRedirectHandler.http_error_302
 
         # We need to update the environment here as both the proxy and HTTPS
         # handlers need variables set. The proxy needs http_proxy and friends to

bitbake/lib/bb/runqueue.py

@@ -22,11 +22,12 @@ from bb import msg, event
 from bb import monitordisk
 import subprocess
 import pickle
-from multiprocessing import Process
 import shlex
 import pprint
 import time
 
+Process = bb.multiprocessing.Process
+
 bblogger = logging.getLogger("BitBake")
 logger = logging.getLogger("BitBake.RunQueue")
 hashequiv_logger = logging.getLogger("BitBake.RunQueue.HashEquiv")

bitbake/lib/bb/siggen.py

@@ -43,6 +43,10 @@ def check_siggen_version(siggen):
     if siggen.find_siginfo_version < siggen.find_siginfo_minversion:
         bb.fatal("Siggen from metadata (OE-Core?) is too old, please update it (%s vs %s)" % (siggen.find_siginfo_version, siggen.find_siginfo_minversion))
 
+def check_hashserv_unihash(unihash):
+    if not hashserv.is_valid_unihash(unihash):
+        bb.fatal("Hash Equivalence Server returned invalid unihash")
+
 class SetEncoder(json.JSONEncoder):
     def default(self, obj):
         if isinstance(obj, set) or isinstance(obj, frozenset):
@@ -753,6 +757,7 @@ class SignatureGeneratorUniHashMixIn(object):
             #    the unique hash.
             taskhash = self.taskhash[tid]
             if unihash:
+                check_hashserv_unihash(unihash)
                 # A unique hash equal to the taskhash is not very interesting,
                 # so it is reported it at debug level 2. If they differ, that
                 # is much more interesting, so it is reported at debug level 1
@@ -772,7 +777,7 @@ class SignatureGeneratorUniHashMixIn(object):
         import importlib
 
         taskhash = d.getVar('BB_TASKHASH')
-        unihash = d.getVar('BB_UNIHASH')
+        unihash = d.getVar('BB_UNIHASH', expand=False)
         report_taskdata = d.getVar('SSTATE_HASHEQUIV_REPORT_TASKDATA') == '1'
         tempdir = d.getVar('T')
         mcfn = d.getVar('BB_FILENAME')
@@ -834,6 +839,7 @@ class SignatureGeneratorUniHashMixIn(object):
                     data = client.report_unihash(taskhash, method, outhash, unihash, extra_data)
 
                 new_unihash = data['unihash']
+                check_hashserv_unihash(new_unihash)
 
                 if new_unihash != unihash:
                     hashequiv_logger.debug('Task %s unihash changed %s -> %s by server %s' % (taskhash, unihash, new_unihash, self.server))
@@ -873,6 +879,7 @@ class SignatureGeneratorUniHashMixIn(object):
                 return False
 
             finalunihash = data['unihash']
+            check_hashserv_unihash(finalunihash)
 
             if finalunihash == current_unihash:
                 hashequiv_logger.verbose('Task %s unihash %s unchanged by server' % (tid, finalunihash))

bitbake/lib/bb/tests/fetch.py

@@ -7,13 +7,17 @@
 #
 
 import contextlib
+import http.server
+import shutil
 import unittest
 import hashlib
 import tempfile
 import collections
 import os
 import signal
+import subprocess
 import tarfile
+import threading
 from bb.fetch2 import URI
 from bb.fetch2 import FetchMethod
 import bb
@@ -731,6 +735,34 @@ class FetcherLocalTest(FetcherTest):
         bb.process.run('tar cjf archive.tar.bz2 -C dir .', cwd=self.localsrcdir)
         self.d.setVar("FILESPATH", self.localsrcdir)
 
+    def make_ar_package(self, package_name, data_member="data.tar"):
+        if not shutil.which("ar"):
+            self.skipTest("ar not installed")
+
+        workdir = tempfile.mkdtemp(dir=self.tempdir)
+        payload = os.path.join(workdir, "payload")
+        with open(payload, "w") as f:
+            f.write("payload\n")
+
+        data_path = os.path.join(workdir, data_member)
+        mode = "w:gz" if data_member.endswith(".gz") else "w"
+        with tarfile.open(data_path, mode) as archive:
+            archive.add(payload, arcname="payload")
+
+        with open(os.path.join(workdir, "debian-binary"), "w") as f:
+            f.write("2.0\n")
+
+        control = os.path.join(workdir, "control")
+        with open(control, "w") as f:
+            f.write("Package: fetch-test\nVersion: 1\nArchitecture: all\n")
+        with tarfile.open(os.path.join(workdir, "control.tar"), "w") as archive:
+            archive.add(control, arcname="control")
+
+        package_path = os.path.join(self.localsrcdir, package_name)
+        subprocess.check_call(["ar", "r", package_path, "debian-binary", "control.tar", data_member],
+                              cwd=workdir, stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)
+        return package_name
+
     def fetchUnpack(self, uris):
         fetcher = bb.fetch.Fetch(uris, self.d)
         fetcher.download()
@@ -800,6 +832,40 @@ class FetcherLocalTest(FetcherTest):
         tree = self.fetchUnpack(['file://archive.tar.bz2;subdir=bar;striplevel=1'])
         self.assertEqual(tree, ['bar/c', 'bar/d', 'bar/subdir/e'])
 
+    def test_local_deb_quoted_filename(self):
+        package = self.make_ar_package("archive$(id).deb")
+        tree = self.fetchUnpack(['file://%s' % package])
+        self.assertEqual(tree, ['payload'])
+
+    def test_local_ipk_gz_data_member(self):
+        package = self.make_ar_package("archive.ipk", data_member="data.tar.gz")
+        tree = self.fetchUnpack(['file://%s' % package])
+        self.assertEqual(tree, ['payload'])
+
+    def test_local_deb_rejects_unknown_data_member_suffix(self):
+        package = self.make_ar_package("archive.deb", data_member="data.tar.foo")
+        with self.assertRaises(bb.fetch2.UnpackError) as context:
+            self.fetchUnpack(['file://%s' % package])
+
+        self.assertIn("does not contain supported data.tar* file", str(context.exception))
+
+    def test_local_deb_rejects_unsafe_data_member(self):
+        package = self.make_ar_package("archive.deb", data_member="data.tar.xz;id")
+        with self.assertRaises(bb.fetch2.UnpackError) as context:
+            self.fetchUnpack(['file://%s' % package])
+
+        self.assertIn("does not contain supported data.tar* file", str(context.exception))
+
+    def assertInvalidStriplevel(self, value):
+        with self.assertRaises(bb.fetch2.UnpackError) as context:
+            self.fetchUnpack(['file://archive.tar;subdir=bar;striplevel=%s' % value])
+        self.assertIn("Invalid striplevel parameter", str(context.exception))
+
+    def test_local_striplevel_rejects_invalid_values(self):
+        for value in ("abc", "", "-1", "1 2"):
+            with self.subTest(striplevel=repr(value)):
+                self.assertInvalidStriplevel(value)
+
     def dummyGitTest(self, suffix):
         # Create dummy local Git repo
         src_dir = tempfile.mkdtemp(dir=self.tempdir,
@@ -1107,7 +1173,7 @@ class FetcherNetworkTest(FetcherTest):
         # URL with ssh submodules
         url = "gitsm://git.yoctoproject.org/git-submodule-test;branch=ssh-gitsm-tests;rev=049da4a6cb198d7c0302e9e8b243a1443cb809a7;branch=master;protocol=https"
         # Original URL (comment this if you have ssh access to git.yoctoproject.org)
-        url = "gitsm://git.yoctoproject.org/git-submodule-test;branch=master;rev=a2885dd7d25380d23627e7544b7bbb55014b16ee;branch=master;protocol=https"
+        url = "gitsm://git.yoctoproject.org/git-submodule-test;branch=master;rev=38e61644af90dccd73c03ed3acaed98c8dda9294;branch=master;protocol=https"
         fetcher = bb.fetch.Fetch([url], self.d)
         fetcher.download()
         # Previous cwd has been deleted
@@ -1546,6 +1612,41 @@ class FetchCheckStatusTest(FetcherTest):
                       "https://github.com/kergoth/tslib/releases/download/1.1/tslib-1.1.tar.xz"
                       ]
 
+    def _start_checkstatus_server(self):
+        class CheckStatusHTTPRequestHandler(http.server.BaseHTTPRequestHandler):
+            def do_HEAD(self):
+                self.server.requests.append((self.path, dict(self.headers)))
+                if self.path == "/a" and self.server.redirect_url:
+                    self.send_response(302)
+                    self.send_header("Location", self.server.redirect_url)
+                    self.end_headers()
+                    return
+                self.send_response(200)
+                self.end_headers()
+
+            def log_message(self, format_str, *args):
+                pass
+
+        server = http.server.HTTPServer(("127.0.0.1", 0), CheckStatusHTTPRequestHandler)
+        server.redirect_url = None
+        server.requests = []
+        thread = threading.Thread(target=server.serve_forever, kwargs={"poll_interval": 0.05})
+        thread.daemon = True
+        thread.start()
+
+        def stop_server():
+            server.shutdown()
+            thread.join()
+            server.server_close()
+
+        self.addCleanup(stop_server)
+        return server
+
+    def _checkstatus(self, url):
+        fetch = bb.fetch2.Fetch([url], self.d)
+        ud = fetch.ud[url]
+        return ud.method.checkstatus(fetch, ud, self.d)
+
     @skipIfNoNetwork()
     def test_wget_checkstatus(self):
         fetch = bb.fetch2.Fetch(self.test_wget_uris, self.d)
@@ -1573,6 +1674,31 @@ class FetchCheckStatusTest(FetcherTest):
 
         connection_cache.close_connections()
 
+    def test_wget_checkstatus_same_origin_redirect_keeps_auth(self):
+        server = self._start_checkstatus_server()
+        server.redirect_url = "http://127.0.0.1:%s/b" % server.server_port
+
+        url = "http://127.0.0.1:%s/a;user=user;pswd=pass" % server.server_port
+        self.assertTrue(self._checkstatus(url))
+
+        self.assertEqual(len(server.requests), 2)
+        redirected_headers = {k.lower(): v for k, v in server.requests[1][1].items()}
+        self.assertIn("authorization", redirected_headers)
+
+    def test_wget_checkstatus_different_origin_redirect_drops_auth(self):
+        origin = self._start_checkstatus_server()
+        target = self._start_checkstatus_server()
+        # Same host but different port is a different origin.
+        origin.redirect_url = "http://127.0.0.1:%s/b" % target.server_port
+
+        url = "http://127.0.0.1:%s/a;user=user;pswd=pass" % origin.server_port
+        self.assertTrue(self._checkstatus(url))
+
+        self.assertEqual(len(origin.requests), 1)
+        self.assertEqual(len(target.requests), 1)
+        redirected_headers = {k.lower(): v for k, v in target.requests[0][1].items()}
+        self.assertNotIn("authorization", redirected_headers)
+
 
 class GitMakeShallowTest(FetcherTest):
     def setUp(self):
@@ -2142,6 +2268,36 @@ class GitShallowTest(FetcherTest):
         self.assertRefs(['master', 'origin/master', 'v1.0'])
         self.assertRevCount(1)
 
+    def test_shallow_extra_refs_wildcard_shell_quoted(self):
+        self.add_empty_file('a')
+        marker = os.path.join(self.tempdir, 'ref-command-marker')
+        ref = 'refs/tags/poc;touch${IFS}%s' % marker
+        self.git(['update-ref', ref, 'HEAD'], cwd=self.srcdir)
+
+        self.d.setVar('BB_GIT_SHALLOW_EXTRA_REFS', 'refs/tags/*')
+        self.fetch_shallow()
+
+        self.assertFalse(os.path.exists(marker))
+        self.assertRefs(['master', 'origin/master', ref])
+
+    def test_shallow_extra_refs_wildcard_fetch_options(self):
+        self.add_empty_file('a')
+        marker = os.path.join(self.tempdir, 'ref-option-marker')
+        helper = os.path.join(self.tempdir, 'upload-pack-helper')
+        with open(helper, 'w') as f:
+            f.write('#!/bin/sh\n')
+            f.write('touch "%s"\n' % marker)
+            f.write('exec git-upload-pack "$@"\n')
+        os.chmod(helper, 0o755)
+        ref = 'refs/tags/--upload-pack=%s' % helper
+        self.git(['update-ref', ref, 'HEAD'], cwd=self.srcdir)
+
+        self.d.setVar('BB_GIT_SHALLOW_EXTRA_REFS', 'refs/tags/*')
+        self.fetch_shallow()
+
+        self.assertFalse(os.path.exists(marker))
+        self.assertRefs(['master', 'origin/master', ref])
+
     def test_shallow_missing_extra_refs(self):
         self.add_empty_file('a')
         self.add_empty_file('b')
@@ -3267,6 +3423,7 @@ class FetchPremirroronlyNetworkTest(FetcherTest):
         self.reponame = "fstests"
         self.clonedir = os.path.join(self.tempdir, "git")
         self.gitdir = os.path.join(self.tempdir, "git", "{}.git".format(self.reponame))
+        self.giturl = "https://git.yoctoproject.org/fstests"
         self.recipe_url = "git://git.yoctoproject.org/fstests;protocol=https"
         self.d.setVar("BB_FETCH_PREMIRRORONLY", "1")
         self.d.setVar("BB_NO_NETWORK", "0")
@@ -3276,7 +3433,7 @@ class FetchPremirroronlyNetworkTest(FetcherTest):
         import shutil
         self.mirrorname = "git2_git.yoctoproject.org.fstests.tar.gz"
         os.makedirs(self.clonedir)
-        self.git("clone --bare --shallow-since=\"01.01.2013\" {}".format(self.recipe_url), self.clonedir)
+        self.git("clone --bare --shallow-since=\"01.01.2013\" {}".format(self.giturl), self.clonedir)
         bb.process.run('tar -czvf {} .'.format(os.path.join(self.mirrordir, self.mirrorname)), cwd =  self.gitdir)
         shutil.rmtree(self.clonedir)
 

bitbake/lib/bb/tests/siggen.py

@@ -9,7 +9,9 @@
 import unittest
 import logging
 import bb
+import bb.data
 import time
+from contextlib import contextmanager
 
 logger = logging.getLogger('BitBake.TestSiggen')
 
@@ -26,3 +28,49 @@ class SiggenTest(unittest.TestCase):
         for t in tests:
             self.assertEqual(bb.siggen.build_pnid(*t), tests[t])
 
+    def test_get_unihashes_rejects_invalid_hashserv_unihash(self):
+        class TestClient:
+            def get_unihash_batch(self, query):
+                list(query)
+                return ["${@os.system('true')}"]
+
+        class TestSiggen(bb.siggen.SignatureGeneratorUniHashMixIn):
+            def __init__(self):
+                self.server = "test-server"
+                self.method = "test-method"
+                self.extramethod = {}
+                self.taskhash = {"test.bb:do_compile": "a" * 64}
+                self.unihash = {}
+                self.unitaskhashes = {}
+                self.tidtopn = {}
+                self.setscenetasks = set()
+                self.max_parallel = 1
+
+            @contextmanager
+            def client(self):
+                yield TestClient()
+
+        siggen = TestSiggen()
+
+        with self.assertRaises(bb.BBHandledException):
+            siggen.get_unihashes(["test.bb:do_compile"])
+
+        self.assertEqual(siggen.unihash, {})
+        self.assertEqual(siggen.unitaskhashes, {})
+
+    def test_report_unihash_reads_bb_unihash_without_expansion(self):
+        class TestSiggen(bb.siggen.SignatureGeneratorUniHashMixIn):
+            def __init__(self):
+                self.setscenetasks = set()
+                self.taskhash = {"test.bb:do_compile": "b" * 64}
+
+        d = bb.data.init()
+        d.setVar("BB_TASKHASH", "a" * 64)
+        d.setVar("BB_UNIHASH", "${@d.setVar('EXPANDED_UNIHASH', '1') or 'bad'}")
+        d.setVar("SSTATE_HASHEQUIV_REPORT_TASKDATA", "0")
+        d.setVar("T", "/tmp")
+        d.setVar("BB_FILENAME", "test.bb")
+
+        TestSiggen().report_unihash(".", "compile", d)
+
+        self.assertIsNone(d.getVar("EXPANDED_UNIHASH"))

bitbake/lib/bb/utils.py

@@ -763,8 +763,20 @@ def mkdirhier(directory):
     try:
         os.makedirs(directory)
     except OSError as e:
-        if e.errno != errno.EEXIST or not os.path.isdir(directory):
+        if e.errno != errno.EEXIST:
             raise e
+        if os.path.isdir(directory):
+            return
+        # We can end up here if there is a race between two mkdirs on an NFS mount,
+        # which happens more often with sstate that you'd think. The server returns
+        # EEXIST but the local attribute cache is out of date. It can be refreshed with
+        # an opendir call, so try that (via listdir) and check the directory again
+        # before we really fail.
+        os.listdir(os.path.dirname(directory))
+        if os.path.isdir(directory):
+            return
+        bb.warn("mkdir: %s is not a directory?")
+        raise e
 
 def movefile(src, dest, newmtime = None, sstat = None):
     """Moves a file from src to dest, preserving all permissions and

bitbake/lib/hashserv/__init__.py

@@ -7,12 +7,19 @@ import asyncio
 from contextlib import closing
 import itertools
 import json
+import re
 from collections import namedtuple
 from urllib.parse import urlparse
 from bb.asyncrpc.client import parse_address, ADDR_TYPE_UNIX, ADDR_TYPE_WS
 
 User = namedtuple("User", ("username", "permissions"))
 
+UNIHASH_REGEX = re.compile(r"^[0-9a-f]{64}$")
+
+
+def is_valid_unihash(value):
+    return isinstance(value, str) and UNIHASH_REGEX.fullmatch(value) is not None
+
 def create_server(
     addr,
     dbname,

bitbake/lib/hashserv/server.py

@@ -12,6 +12,7 @@ import os
 import base64
 import hashlib
 from . import create_async_client
+from . import is_valid_unihash
 import bb.asyncrpc
 
 logger = logging.getLogger("hashserv.server")
@@ -172,6 +173,11 @@ def hash_token(algo, salt, token):
     return ":".join([algo, salt, h.hexdigest()])
 
 
+def validate_unihash(value):
+    if not is_valid_unihash(value):
+        raise bb.asyncrpc.InvokeError("Invalid unihash")
+
+
 def permissions(*permissions, allow_anon=True, allow_self_service=False):
     """
     Function decorator that can be used to decorate an RPC function call and
@@ -343,7 +349,7 @@ class ServerClient(bb.asyncrpc.AsyncServerConnection):
                 d = {k: row[k] for k in row.keys()}
             elif self.upstream_client is not None:
                 d = await self.upstream_client.get_taskhash(method, taskhash)
-                await self.db.insert_unihash(d["method"], d["taskhash"], d["unihash"])
+                await self.insert_unihash(d["method"], d["taskhash"], d["unihash"])
 
         return d
 
@@ -375,9 +381,13 @@ class ServerClient(bb.asyncrpc.AsyncServerConnection):
         if data is None:
             return
 
-        await self.db.insert_unihash(data["method"], data["taskhash"], data["unihash"])
+        await self.insert_unihash(data["method"], data["taskhash"], data["unihash"])
         await self.db.insert_outhash(data)
 
+    async def insert_unihash(self, method, taskhash, unihash):
+        validate_unihash(unihash)
+        return await self.db.insert_unihash(method, taskhash, unihash)
+
     async def _stream_handler(self, handler):
         await self.socket.send_message("ok")
 
@@ -465,6 +475,8 @@ class ServerClient(bb.asyncrpc.AsyncServerConnection):
     # report is made inside the function
     @permissions(READ_PERM)
     async def handle_report(self, data):
+        validate_unihash(data.get("unihash"))
+
         if self.server.read_only or not self.user_has_permissions(REPORT_PERM):
             return await self.report_readonly(data)
 
@@ -507,7 +519,7 @@ class ServerClient(bb.asyncrpc.AsyncServerConnection):
                     if upstream_data is not None:
                         unihash = upstream_data["unihash"]
 
-            await self.db.insert_unihash(data["method"], data["taskhash"], unihash)
+            await self.insert_unihash(data["method"], data["taskhash"], unihash)
 
         unihash_data = await self.get_unihash(data["method"], data["taskhash"])
         if unihash_data is not None:
@@ -523,7 +535,9 @@ class ServerClient(bb.asyncrpc.AsyncServerConnection):
 
     @permissions(READ_PERM, REPORT_PERM)
     async def handle_equivreport(self, data):
-        await self.db.insert_unihash(data["method"], data["taskhash"], data["unihash"])
+        validate_unihash(data.get("unihash"))
+
+        await self.insert_unihash(data["method"], data["taskhash"], data["unihash"])
 
         # Fetch the unihash that will be reported for the taskhash. If the
         # unihash matches, it means this row was inserted (or the mapping
@@ -859,7 +873,10 @@ class Server(bb.asyncrpc.AsyncServer):
                 method, taskhash = item
                 d = await client.get_taskhash(method, taskhash)
                 if d is not None:
-                    await db.insert_unihash(d["method"], d["taskhash"], d["unihash"])
+                    if is_valid_unihash(d.get("unihash")):
+                        await db.insert_unihash(d["method"], d["taskhash"], d["unihash"])
+                    else:
+                        self.logger.warning("Upstream server returned invalid unihash")
                 self.backfill_queue.task_done()
 
     def start(self):

bitbake/lib/hashserv/tests.py

@@ -128,7 +128,7 @@ class HashEquivalenceTestSetup(object):
         # Simple test that hashes can be created
         taskhash = '35788efcb8dfb0a02659d81cf2bfd695fb30faf9'
         outhash = '2765d4a5884be49b28601445c2760c5f21e7e5c0ee2b7e3fce98fd7e5970796f'
-        unihash = 'f46d3fbb439bd9b921095da657a4de906510d2cd'
+        unihash = 'a69ec97f5af2e21e1a1f9cc8896965515d5559425666f734e245a3d40cee33d9'
 
         self.assertClientGetHash(client, taskhash, None)
 
@@ -182,7 +182,7 @@ class HashEquivalenceCommonTests(object):
         # assigned the same unihash
         taskhash = '53b8dce672cb6d0c73170be43f540460bfc347b4'
         outhash = '5a9cb1649625f0bf41fc7791b635cd9c2d7118c7f021ba87dcd03f72b67ce7a8'
-        unihash = 'f37918cc02eb5a520b1aff86faacbc0a38124646'
+        unihash = '46edb5140d2613049332d0bf3745d9fafec9c559dac8cc61813739a28007fcdf'
 
         result = self.client.report_unihash(taskhash, self.METHOD, outhash, unihash)
         self.assertEqual(result['unihash'], unihash, 'Server returned bad unihash')
@@ -190,7 +190,7 @@ class HashEquivalenceCommonTests(object):
         # Report a different task with the same outhash. The returned unihash
         # should match the first task
         taskhash2 = '3bf6f1e89d26205aec90da04854fbdbf73afe6b4'
-        unihash2 = 'af36b199320e611fbb16f1f277d3ee1d619ca58b'
+        unihash2 = 'bf6e81926066f770e960f9f777cd088c62bea9addb7745f3e77deaa81a645747'
         result = self.client.report_unihash(taskhash2, self.METHOD, outhash, unihash2)
         self.assertEqual(result['unihash'], unihash, 'Server returned bad unihash')
 
@@ -200,19 +200,19 @@ class HashEquivalenceCommonTests(object):
         # taskhash
         taskhash = '8aa96fcffb5831b3c2c0cb75f0431e3f8b20554a'
         outhash = 'afe240a439959ce86f5e322f8c208e1fedefea9e813f2140c81af866cc9edf7e'
-        unihash = '218e57509998197d570e2c98512d0105985dffc9'
+        unihash = '5b521d8a12683086cc08bc2c6d94a7a2dcff17eba53b9911e145d51164689380'
         self.client.report_unihash(taskhash, self.METHOD, outhash, unihash)
 
         self.assertClientGetHash(self.client, taskhash, unihash)
 
         outhash2 = '0904a7fe3dc712d9fd8a74a616ddca2a825a8ee97adf0bd3fc86082c7639914d'
-        unihash2 = 'ae9a7d252735f0dafcdb10e2e02561ca3a47314c'
+        unihash2 = 'a37541b54fd22440e292f617eb30ba07455e88fb0b9f0952eca229b6356290e3'
         self.client.report_unihash(taskhash, self.METHOD, outhash2, unihash2)
 
         self.assertClientGetHash(self.client, taskhash, unihash)
 
         outhash3 = '77623a549b5b1a31e3732dfa8fe61d7ce5d44b3370f253c5360e136b852967b4'
-        unihash3 = '9217a7d6398518e5dc002ed58f2cbbbc78696603'
+        unihash3 = '6842f1f2daccd96ddef15c9154d4e41ac8a2300d781ac9a9db7f8afeb8a96808'
         self.client.report_unihash(taskhash, self.METHOD, outhash3, unihash3)
 
         self.assertClientGetHash(self.client, taskhash, unihash)
@@ -272,7 +272,7 @@ class HashEquivalenceCommonTests(object):
         # Simple test that hashes can be created
         taskhash = 'c665584ee6817aa99edfc77a44dd853828279370'
         outhash = '3c979c3db45c569f51ab7626a4651074be3a9d11a84b1db076f5b14f7d39db44'
-        unihash = '90e9bc1d1f094c51824adca7f8ea79a048d68824'
+        unihash = '06f89b8f329ba8124ff73c56d09ef921b42624747c421277bddaf5e23f136e57'
 
         self.assertClientGetHash(self.client, taskhash, None)
 
@@ -295,6 +295,36 @@ class HashEquivalenceCommonTests(object):
         self.assertEqual(result_outhash['outhash'], outhash)
         self.assertEqual(result_outhash['outhash_siginfo'], siginfo)
 
+    def test_report_rejects_invalid_unihash(self):
+        taskhash = '68a9206490b2321bb033fb3eab013a4ec62c41f9'
+        outhash = 'bf5f2efaf1ca351f3b4c3d079363540ab48f7c58db3d23cfbb069cf4ff1ea8f7'
+        invalid_unihashes = (
+            "${@os.system('true')}",
+            'a' * 63,
+            'a' * 65,
+            'A' * 64,
+            None,
+        )
+
+        for unihash in invalid_unihashes:
+            with self.subTest(unihash=unihash):
+                with self.start_client(self.server_address) as client:
+                    with self.assertRaises(InvokeError) as context:
+                        client.report_unihash(taskhash, self.METHOD, outhash, unihash)
+
+                self.assertEqual(str(context.exception), "Invalid unihash")
+
+        self.assertClientGetHash(self.client, taskhash, None)
+
+    def test_equivreport_rejects_invalid_unihash(self):
+        taskhash = 'ae6339531895ddf5b67e663e6a374ad8ec71d81c'
+
+        with self.assertRaises(InvokeError) as context:
+            self.client.report_unihash_equiv(taskhash, self.METHOD, "${@os.system('true')}")
+
+        self.assertEqual(str(context.exception), "Invalid unihash")
+        self.assertClientGetHash(self.start_client(self.server_address), taskhash, None)
+
     def test_stress(self):
         def query_server(failures):
             client = Client(self.server_address)
@@ -365,7 +395,7 @@ class HashEquivalenceCommonTests(object):
         # Basic report
         taskhash = '8aa96fcffb5831b3c2c0cb75f0431e3f8b20554a'
         outhash = 'afe240a439959ce86f5e322f8c208e1fedefea9e813f2140c81af866cc9edf7e'
-        unihash = '218e57509998197d570e2c98512d0105985dffc9'
+        unihash = '5b521d8a12683086cc08bc2c6d94a7a2dcff17eba53b9911e145d51164689380'
         self.client.report_unihash(taskhash, self.METHOD, outhash, unihash)
 
         check_hash(taskhash, unihash, None)
@@ -373,7 +403,7 @@ class HashEquivalenceCommonTests(object):
         # Duplicated taskhash with multiple output hashes and unihashes.
         # All servers should agree with the originally reported hash
         outhash2 = '0904a7fe3dc712d9fd8a74a616ddca2a825a8ee97adf0bd3fc86082c7639914d'
-        unihash2 = 'ae9a7d252735f0dafcdb10e2e02561ca3a47314c'
+        unihash2 = 'a37541b54fd22440e292f617eb30ba07455e88fb0b9f0952eca229b6356290e3'
         self.client.report_unihash(taskhash, self.METHOD, outhash2, unihash2)
 
         check_hash(taskhash, unihash, unihash)
@@ -381,7 +411,7 @@ class HashEquivalenceCommonTests(object):
         # Report an equivalent task. The sideload will originally report
         # no unihash until backfilled
         taskhash3 = "044c2ec8aaf480685a00ff6ff49e6162e6ad34e1"
-        unihash3 = "def64766090d28f627e816454ed46894bb3aab36"
+        unihash3 = "aca636d800aef40e6ddcea4b2262cc4ea0d1180a6783e5b4653a20c7dd73458d"
         self.client.report_unihash(taskhash3, self.METHOD, outhash, unihash3)
 
         check_hash(taskhash3, unihash, None)
@@ -390,7 +420,7 @@ class HashEquivalenceCommonTests(object):
         # propagating to the upstream server
         taskhash4 = "e3da00593d6a7fb435c7e2114976c59c5fd6d561"
         outhash4 = "1cf8713e645f491eb9c959d20b5cae1c47133a292626dda9b10709857cbe688a"
-        unihash4 = "3b5d3d83f07f259e9086fcb422c855286e18a57d"
+        unihash4 = "7aebef07d66a8c0f92d0c4f65ec8b1fbb850a3693c53827b8774b64fa9a8a9fe"
         down_client.report_unihash(taskhash4, self.METHOD, outhash4, unihash4)
         down_client.backfill_wait()
 
@@ -402,18 +432,18 @@ class HashEquivalenceCommonTests(object):
         # match which was previously reported to the upstream server
         taskhash5 = '35788efcb8dfb0a02659d81cf2bfd695fb30faf9'
         outhash5 = '2765d4a5884be49b28601445c2760c5f21e7e5c0ee2b7e3fce98fd7e5970796f'
-        unihash5 = 'f46d3fbb439bd9b921095da657a4de906510d2cd'
+        unihash5 = 'a69ec97f5af2e21e1a1f9cc8896965515d5559425666f734e245a3d40cee33d9'
         result = self.client.report_unihash(taskhash5, self.METHOD, outhash5, unihash5)
 
         taskhash6 = '35788efcb8dfb0a02659d81cf2bfd695fb30fafa'
-        unihash6 = 'f46d3fbb439bd9b921095da657a4de906510d2ce'
+        unihash6 = 'eabc7a98e0c12bbeb8394dbdf055eb81aac60e4a14cca5c1f069d36efc933b23'
         result = down_client.report_unihash(taskhash6, self.METHOD, outhash5, unihash6)
         self.assertEqual(result['unihash'], unihash5, 'Server failed to copy unihash from upstream')
 
         # Tests read through from server with
         taskhash7 = '9d81d76242cc7cfaf7bf74b94b9cd2e29324ed74'
         outhash7 = '8470d56547eea6236d7c81a644ce74670ca0bbda998e13c629ef6bb3f0d60b69'
-        unihash7 = '05d2a63c81e32f0a36542ca677e8ad852365c538'
+        unihash7 = '7521a98a0c645341bc51559b234ef37a097e8f3a01665e0303a317925ab7b4d5'
         self.client.report_unihash(taskhash7, self.METHOD, outhash7, unihash7)
 
         result = down_client.get_taskhash(self.METHOD, taskhash7, True)
@@ -424,7 +454,7 @@ class HashEquivalenceCommonTests(object):
 
         taskhash8 = '86978a4c8c71b9b487330b0152aade10c1ee58aa'
         outhash8 = 'ca8c128e9d9e4a28ef24d0508aa20b5cf880604eacd8f65c0e366f7e0cc5fbcf'
-        unihash8 = 'd8bcf25369d40590ad7d08c84d538982f2023e01'
+        unihash8 = '83386d9385b0bf3ba25693127ddcaaadeaa1c4bf8cb0baecfb5314b9a20072a1'
         self.client.report_unihash(taskhash8, self.METHOD, outhash8, unihash8)
 
         result = down_client.get_outhash(self.METHOD, outhash8, taskhash8)
@@ -435,7 +465,7 @@ class HashEquivalenceCommonTests(object):
 
         taskhash9 = 'ae6339531895ddf5b67e663e6a374ad8ec71d81c'
         outhash9 = 'afc78172c81880ae10a1fec994b5b4ee33d196a001a1b66212a15ebe573e00b5'
-        unihash9 = '6662e699d6e3d894b24408ff9a4031ef9b038ee8'
+        unihash9 = 'cc74784b2c0ad5b378a6b783c74c518d2c46b8b52fba29cb39a8430d742440d7'
         self.client.report_unihash(taskhash9, self.METHOD, outhash9, unihash9)
 
         result = down_client.get_taskhash(self.METHOD, taskhash9, False)
@@ -446,7 +476,7 @@ class HashEquivalenceCommonTests(object):
     def test_unihash_exsits(self):
         taskhash, outhash, unihash = self.create_test_hash(self.client)
         self.assertTrue(self.client.unihash_exists(unihash))
-        self.assertFalse(self.client.unihash_exists('6662e699d6e3d894b24408ff9a4031ef9b038ee8'))
+        self.assertFalse(self.client.unihash_exists('cc74784b2c0ad5b378a6b783c74c518d2c46b8b52fba29cb39a8430d742440d7'))
 
     def test_ro_server(self):
         rw_server = self.start_server()
@@ -458,7 +488,7 @@ class HashEquivalenceCommonTests(object):
         # Report a hash via the read-write server
         taskhash = '35788efcb8dfb0a02659d81cf2bfd695fb30faf9'
         outhash = '2765d4a5884be49b28601445c2760c5f21e7e5c0ee2b7e3fce98fd7e5970796f'
-        unihash = 'f46d3fbb439bd9b921095da657a4de906510d2cd'
+        unihash = 'a69ec97f5af2e21e1a1f9cc8896965515d5559425666f734e245a3d40cee33d9'
 
         result = rw_client.report_unihash(taskhash, self.METHOD, outhash, unihash)
         self.assertEqual(result['unihash'], unihash, 'Server returned bad unihash')
@@ -469,7 +499,7 @@ class HashEquivalenceCommonTests(object):
         # Ensure that reporting via the read-only server fails
         taskhash2 = 'c665584ee6817aa99edfc77a44dd853828279370'
         outhash2 = '3c979c3db45c569f51ab7626a4651074be3a9d11a84b1db076f5b14f7d39db44'
-        unihash2 = '90e9bc1d1f094c51824adca7f8ea79a048d68824'
+        unihash2 = '06f89b8f329ba8124ff73c56d09ef921b42624747c421277bddaf5e23f136e57'
 
         result = ro_client.report_unihash(taskhash2, self.METHOD, outhash2, unihash2)
         self.assertEqual(result['unihash'], unihash2)
@@ -559,15 +589,15 @@ class HashEquivalenceCommonTests(object):
     def test_client_pool_get_unihashes(self):
         TEST_INPUT = (
             # taskhash                                   outhash                                                            unihash
-            ('8aa96fcffb5831b3c2c0cb75f0431e3f8b20554a', 'afe240a439959ce86f5e322f8c208e1fedefea9e813f2140c81af866cc9edf7e','218e57509998197d570e2c98512d0105985dffc9'),
+            ('8aa96fcffb5831b3c2c0cb75f0431e3f8b20554a', 'afe240a439959ce86f5e322f8c208e1fedefea9e813f2140c81af866cc9edf7e','5b521d8a12683086cc08bc2c6d94a7a2dcff17eba53b9911e145d51164689380'),
             # Duplicated taskhash with multiple output hashes and unihashes.
-            ('8aa96fcffb5831b3c2c0cb75f0431e3f8b20554a', '0904a7fe3dc712d9fd8a74a616ddca2a825a8ee97adf0bd3fc86082c7639914d', 'ae9a7d252735f0dafcdb10e2e02561ca3a47314c'),
+            ('8aa96fcffb5831b3c2c0cb75f0431e3f8b20554a', '0904a7fe3dc712d9fd8a74a616ddca2a825a8ee97adf0bd3fc86082c7639914d', 'a37541b54fd22440e292f617eb30ba07455e88fb0b9f0952eca229b6356290e3'),
             # Equivalent hash
-            ("044c2ec8aaf480685a00ff6ff49e6162e6ad34e1", '0904a7fe3dc712d9fd8a74a616ddca2a825a8ee97adf0bd3fc86082c7639914d', "def64766090d28f627e816454ed46894bb3aab36"),
+            ("044c2ec8aaf480685a00ff6ff49e6162e6ad34e1", '0904a7fe3dc712d9fd8a74a616ddca2a825a8ee97adf0bd3fc86082c7639914d', "aca636d800aef40e6ddcea4b2262cc4ea0d1180a6783e5b4653a20c7dd73458d"),
-            ("e3da00593d6a7fb435c7e2114976c59c5fd6d561", "1cf8713e645f491eb9c959d20b5cae1c47133a292626dda9b10709857cbe688a", "3b5d3d83f07f259e9086fcb422c855286e18a57d"),
+            ("e3da00593d6a7fb435c7e2114976c59c5fd6d561", "1cf8713e645f491eb9c959d20b5cae1c47133a292626dda9b10709857cbe688a", "7aebef07d66a8c0f92d0c4f65ec8b1fbb850a3693c53827b8774b64fa9a8a9fe"),
-            ('35788efcb8dfb0a02659d81cf2bfd695fb30faf9', '2765d4a5884be49b28601445c2760c5f21e7e5c0ee2b7e3fce98fd7e5970796f', 'f46d3fbb439bd9b921095da657a4de906510d2cd'),
+            ('35788efcb8dfb0a02659d81cf2bfd695fb30faf9', '2765d4a5884be49b28601445c2760c5f21e7e5c0ee2b7e3fce98fd7e5970796f', 'a69ec97f5af2e21e1a1f9cc8896965515d5559425666f734e245a3d40cee33d9'),
-            ('35788efcb8dfb0a02659d81cf2bfd695fb30fafa', '2765d4a5884be49b28601445c2760c5f21e7e5c0ee2b7e3fce98fd7e5970796f', 'f46d3fbb439bd9b921095da657a4de906510d2ce'),
+            ('35788efcb8dfb0a02659d81cf2bfd695fb30fafa', '2765d4a5884be49b28601445c2760c5f21e7e5c0ee2b7e3fce98fd7e5970796f', 'eabc7a98e0c12bbeb8394dbdf055eb81aac60e4a14cca5c1f069d36efc933b23'),
-            ('9d81d76242cc7cfaf7bf74b94b9cd2e29324ed74', '8470d56547eea6236d7c81a644ce74670ca0bbda998e13c629ef6bb3f0d60b69', '05d2a63c81e32f0a36542ca677e8ad852365c538'),
+            ('9d81d76242cc7cfaf7bf74b94b9cd2e29324ed74', '8470d56547eea6236d7c81a644ce74670ca0bbda998e13c629ef6bb3f0d60b69', '7521a98a0c645341bc51559b234ef37a097e8f3a01665e0303a317925ab7b4d5'),
         )
         EXTRA_QUERIES = (
             "6b6be7a84ab179b4240c4302518dc3f6",
@@ -584,28 +614,56 @@ class HashEquivalenceCommonTests(object):
             result = client_pool.get_unihashes(query)
 
             self.assertDictEqual(result, {
-                0: "218e57509998197d570e2c98512d0105985dffc9",
+                0: "5b521d8a12683086cc08bc2c6d94a7a2dcff17eba53b9911e145d51164689380",
-                1: "218e57509998197d570e2c98512d0105985dffc9",
+                1: "5b521d8a12683086cc08bc2c6d94a7a2dcff17eba53b9911e145d51164689380",
-                2: "218e57509998197d570e2c98512d0105985dffc9",
+                2: "5b521d8a12683086cc08bc2c6d94a7a2dcff17eba53b9911e145d51164689380",
-                3: "3b5d3d83f07f259e9086fcb422c855286e18a57d",
+                3: "7aebef07d66a8c0f92d0c4f65ec8b1fbb850a3693c53827b8774b64fa9a8a9fe",
-                4: "f46d3fbb439bd9b921095da657a4de906510d2cd",
+                4: "a69ec97f5af2e21e1a1f9cc8896965515d5559425666f734e245a3d40cee33d9",
-                5: "f46d3fbb439bd9b921095da657a4de906510d2cd",
+                5: "a69ec97f5af2e21e1a1f9cc8896965515d5559425666f734e245a3d40cee33d9",
-                6: "05d2a63c81e32f0a36542ca677e8ad852365c538",
+                6: "7521a98a0c645341bc51559b234ef37a097e8f3a01665e0303a317925ab7b4d5",
                 7: None,
             })
 
     def test_get_unihash_batch(self):
         TEST_INPUT = (
             # taskhash                                   outhash                                                            unihash
-            ('8aa96fcffb5831b3c2c0cb75f0431e3f8b20554a', 'afe240a439959ce86f5e322f8c208e1fedefea9e813f2140c81af866cc9edf7e','218e57509998197d570e2c98512d0105985dffc9'),
+            (
+                '8aa96fcffb5831b3c2c0cb75f0431e3f8b20554a',
+                'afe240a439959ce86f5e322f8c208e1fedefea9e813f2140c81af866cc9edf7e',
+                '5b521d8a12683086cc08bc2c6d94a7a2dcff17eba53b9911e145d51164689380',
+            ),
             # Duplicated taskhash with multiple output hashes and unihashes.
-            ('8aa96fcffb5831b3c2c0cb75f0431e3f8b20554a', '0904a7fe3dc712d9fd8a74a616ddca2a825a8ee97adf0bd3fc86082c7639914d', 'ae9a7d252735f0dafcdb10e2e02561ca3a47314c'),
+            (
+                '8aa96fcffb5831b3c2c0cb75f0431e3f8b20554a',
+                '0904a7fe3dc712d9fd8a74a616ddca2a825a8ee97adf0bd3fc86082c7639914d',
+                'a37541b54fd22440e292f617eb30ba07455e88fb0b9f0952eca229b6356290e3',
+            ),
             # Equivalent hash
-            ("044c2ec8aaf480685a00ff6ff49e6162e6ad34e1", '0904a7fe3dc712d9fd8a74a616ddca2a825a8ee97adf0bd3fc86082c7639914d', "def64766090d28f627e816454ed46894bb3aab36"),
+            (
-            ("e3da00593d6a7fb435c7e2114976c59c5fd6d561", "1cf8713e645f491eb9c959d20b5cae1c47133a292626dda9b10709857cbe688a", "3b5d3d83f07f259e9086fcb422c855286e18a57d"),
+                "044c2ec8aaf480685a00ff6ff49e6162e6ad34e1",
-            ('35788efcb8dfb0a02659d81cf2bfd695fb30faf9', '2765d4a5884be49b28601445c2760c5f21e7e5c0ee2b7e3fce98fd7e5970796f', 'f46d3fbb439bd9b921095da657a4de906510d2cd'),
+                '0904a7fe3dc712d9fd8a74a616ddca2a825a8ee97adf0bd3fc86082c7639914d',
-            ('35788efcb8dfb0a02659d81cf2bfd695fb30fafa', '2765d4a5884be49b28601445c2760c5f21e7e5c0ee2b7e3fce98fd7e5970796f', 'f46d3fbb439bd9b921095da657a4de906510d2ce'),
+                "aca636d800aef40e6ddcea4b2262cc4ea0d1180a6783e5b4653a20c7dd73458d",
-            ('9d81d76242cc7cfaf7bf74b94b9cd2e29324ed74', '8470d56547eea6236d7c81a644ce74670ca0bbda998e13c629ef6bb3f0d60b69', '05d2a63c81e32f0a36542ca677e8ad852365c538'),
+            ),
+            (
+                "e3da00593d6a7fb435c7e2114976c59c5fd6d561",
+                "1cf8713e645f491eb9c959d20b5cae1c47133a292626dda9b10709857cbe688a",
+                "7aebef07d66a8c0f92d0c4f65ec8b1fbb850a3693c53827b8774b64fa9a8a9fe",
+            ),
+            (
+                '35788efcb8dfb0a02659d81cf2bfd695fb30faf9',
+                '2765d4a5884be49b28601445c2760c5f21e7e5c0ee2b7e3fce98fd7e5970796f',
+                'a69ec97f5af2e21e1a1f9cc8896965515d5559425666f734e245a3d40cee33d9',
+            ),
+            (
+                '35788efcb8dfb0a02659d81cf2bfd695fb30fafa',
+                '2765d4a5884be49b28601445c2760c5f21e7e5c0ee2b7e3fce98fd7e5970796f',
+                'eabc7a98e0c12bbeb8394dbdf055eb81aac60e4a14cca5c1f069d36efc933b23',
+            ),
+            (
+                '9d81d76242cc7cfaf7bf74b94b9cd2e29324ed74',
+                '8470d56547eea6236d7c81a644ce74670ca0bbda998e13c629ef6bb3f0d60b69',
+                '7521a98a0c645341bc51559b234ef37a097e8f3a01665e0303a317925ab7b4d5',
+            ),
         )
         EXTRA_QUERIES = (
             "6b6be7a84ab179b4240c4302518dc3f6",
@@ -621,28 +679,28 @@ class HashEquivalenceCommonTests(object):
         )
 
         self.assertListEqual(result, [
-            "218e57509998197d570e2c98512d0105985dffc9",
+            "5b521d8a12683086cc08bc2c6d94a7a2dcff17eba53b9911e145d51164689380",
-            "218e57509998197d570e2c98512d0105985dffc9",
+            "5b521d8a12683086cc08bc2c6d94a7a2dcff17eba53b9911e145d51164689380",
-            "218e57509998197d570e2c98512d0105985dffc9",
+            "5b521d8a12683086cc08bc2c6d94a7a2dcff17eba53b9911e145d51164689380",
-            "3b5d3d83f07f259e9086fcb422c855286e18a57d",
+            "7aebef07d66a8c0f92d0c4f65ec8b1fbb850a3693c53827b8774b64fa9a8a9fe",
-            "f46d3fbb439bd9b921095da657a4de906510d2cd",
+            "a69ec97f5af2e21e1a1f9cc8896965515d5559425666f734e245a3d40cee33d9",
-            "f46d3fbb439bd9b921095da657a4de906510d2cd",
+            "a69ec97f5af2e21e1a1f9cc8896965515d5559425666f734e245a3d40cee33d9",
-            "05d2a63c81e32f0a36542ca677e8ad852365c538",
+            "7521a98a0c645341bc51559b234ef37a097e8f3a01665e0303a317925ab7b4d5",
             None,
         ])
 
     def test_client_pool_unihash_exists(self):
         TEST_INPUT = (
             # taskhash                                   outhash                                                            unihash
-            ('8aa96fcffb5831b3c2c0cb75f0431e3f8b20554a', 'afe240a439959ce86f5e322f8c208e1fedefea9e813f2140c81af866cc9edf7e','218e57509998197d570e2c98512d0105985dffc9'),
+            ('8aa96fcffb5831b3c2c0cb75f0431e3f8b20554a', 'afe240a439959ce86f5e322f8c208e1fedefea9e813f2140c81af866cc9edf7e','5b521d8a12683086cc08bc2c6d94a7a2dcff17eba53b9911e145d51164689380'),
             # Duplicated taskhash with multiple output hashes and unihashes.
-            ('8aa96fcffb5831b3c2c0cb75f0431e3f8b20554a', '0904a7fe3dc712d9fd8a74a616ddca2a825a8ee97adf0bd3fc86082c7639914d', 'ae9a7d252735f0dafcdb10e2e02561ca3a47314c'),
+            ('8aa96fcffb5831b3c2c0cb75f0431e3f8b20554a', '0904a7fe3dc712d9fd8a74a616ddca2a825a8ee97adf0bd3fc86082c7639914d', 'a37541b54fd22440e292f617eb30ba07455e88fb0b9f0952eca229b6356290e3'),
             # Equivalent hash
-            ("044c2ec8aaf480685a00ff6ff49e6162e6ad34e1", '0904a7fe3dc712d9fd8a74a616ddca2a825a8ee97adf0bd3fc86082c7639914d', "def64766090d28f627e816454ed46894bb3aab36"),
+            ("044c2ec8aaf480685a00ff6ff49e6162e6ad34e1", '0904a7fe3dc712d9fd8a74a616ddca2a825a8ee97adf0bd3fc86082c7639914d', "aca636d800aef40e6ddcea4b2262cc4ea0d1180a6783e5b4653a20c7dd73458d"),
-            ("e3da00593d6a7fb435c7e2114976c59c5fd6d561", "1cf8713e645f491eb9c959d20b5cae1c47133a292626dda9b10709857cbe688a", "3b5d3d83f07f259e9086fcb422c855286e18a57d"),
+            ("e3da00593d6a7fb435c7e2114976c59c5fd6d561", "1cf8713e645f491eb9c959d20b5cae1c47133a292626dda9b10709857cbe688a", "7aebef07d66a8c0f92d0c4f65ec8b1fbb850a3693c53827b8774b64fa9a8a9fe"),
-            ('35788efcb8dfb0a02659d81cf2bfd695fb30faf9', '2765d4a5884be49b28601445c2760c5f21e7e5c0ee2b7e3fce98fd7e5970796f', 'f46d3fbb439bd9b921095da657a4de906510d2cd'),
+            ('35788efcb8dfb0a02659d81cf2bfd695fb30faf9', '2765d4a5884be49b28601445c2760c5f21e7e5c0ee2b7e3fce98fd7e5970796f', 'a69ec97f5af2e21e1a1f9cc8896965515d5559425666f734e245a3d40cee33d9'),
-            ('35788efcb8dfb0a02659d81cf2bfd695fb30fafa', '2765d4a5884be49b28601445c2760c5f21e7e5c0ee2b7e3fce98fd7e5970796f', 'f46d3fbb439bd9b921095da657a4de906510d2ce'),
+            ('35788efcb8dfb0a02659d81cf2bfd695fb30fafa', '2765d4a5884be49b28601445c2760c5f21e7e5c0ee2b7e3fce98fd7e5970796f', 'eabc7a98e0c12bbeb8394dbdf055eb81aac60e4a14cca5c1f069d36efc933b23'),
-            ('9d81d76242cc7cfaf7bf74b94b9cd2e29324ed74', '8470d56547eea6236d7c81a644ce74670ca0bbda998e13c629ef6bb3f0d60b69', '05d2a63c81e32f0a36542ca677e8ad852365c538'),
+            ('9d81d76242cc7cfaf7bf74b94b9cd2e29324ed74', '8470d56547eea6236d7c81a644ce74670ca0bbda998e13c629ef6bb3f0d60b69', '7521a98a0c645341bc51559b234ef37a097e8f3a01665e0303a317925ab7b4d5'),
         )
         EXTRA_QUERIES = (
             "6b6be7a84ab179b4240c4302518dc3f6",
@@ -676,15 +734,43 @@ class HashEquivalenceCommonTests(object):
     def test_unihash_exists_batch(self):
         TEST_INPUT = (
             # taskhash                                   outhash                                                            unihash
-            ('8aa96fcffb5831b3c2c0cb75f0431e3f8b20554a', 'afe240a439959ce86f5e322f8c208e1fedefea9e813f2140c81af866cc9edf7e','218e57509998197d570e2c98512d0105985dffc9'),
+            (
+                '8aa96fcffb5831b3c2c0cb75f0431e3f8b20554a',
+                'afe240a439959ce86f5e322f8c208e1fedefea9e813f2140c81af866cc9edf7e',
+                '5b521d8a12683086cc08bc2c6d94a7a2dcff17eba53b9911e145d51164689380',
+            ),
             # Duplicated taskhash with multiple output hashes and unihashes.
-            ('8aa96fcffb5831b3c2c0cb75f0431e3f8b20554a', '0904a7fe3dc712d9fd8a74a616ddca2a825a8ee97adf0bd3fc86082c7639914d', 'ae9a7d252735f0dafcdb10e2e02561ca3a47314c'),
+            (
+                '8aa96fcffb5831b3c2c0cb75f0431e3f8b20554a',
+                '0904a7fe3dc712d9fd8a74a616ddca2a825a8ee97adf0bd3fc86082c7639914d',
+                'a37541b54fd22440e292f617eb30ba07455e88fb0b9f0952eca229b6356290e3',
+            ),
             # Equivalent hash
-            ("044c2ec8aaf480685a00ff6ff49e6162e6ad34e1", '0904a7fe3dc712d9fd8a74a616ddca2a825a8ee97adf0bd3fc86082c7639914d', "def64766090d28f627e816454ed46894bb3aab36"),
+            (
-            ("e3da00593d6a7fb435c7e2114976c59c5fd6d561", "1cf8713e645f491eb9c959d20b5cae1c47133a292626dda9b10709857cbe688a", "3b5d3d83f07f259e9086fcb422c855286e18a57d"),
+                "044c2ec8aaf480685a00ff6ff49e6162e6ad34e1",
-            ('35788efcb8dfb0a02659d81cf2bfd695fb30faf9', '2765d4a5884be49b28601445c2760c5f21e7e5c0ee2b7e3fce98fd7e5970796f', 'f46d3fbb439bd9b921095da657a4de906510d2cd'),
+                '0904a7fe3dc712d9fd8a74a616ddca2a825a8ee97adf0bd3fc86082c7639914d',
-            ('35788efcb8dfb0a02659d81cf2bfd695fb30fafa', '2765d4a5884be49b28601445c2760c5f21e7e5c0ee2b7e3fce98fd7e5970796f', 'f46d3fbb439bd9b921095da657a4de906510d2ce'),
+                "aca636d800aef40e6ddcea4b2262cc4ea0d1180a6783e5b4653a20c7dd73458d",
-            ('9d81d76242cc7cfaf7bf74b94b9cd2e29324ed74', '8470d56547eea6236d7c81a644ce74670ca0bbda998e13c629ef6bb3f0d60b69', '05d2a63c81e32f0a36542ca677e8ad852365c538'),
+            ),
+            (
+                "e3da00593d6a7fb435c7e2114976c59c5fd6d561",
+                "1cf8713e645f491eb9c959d20b5cae1c47133a292626dda9b10709857cbe688a",
+                "7aebef07d66a8c0f92d0c4f65ec8b1fbb850a3693c53827b8774b64fa9a8a9fe",
+            ),
+            (
+                '35788efcb8dfb0a02659d81cf2bfd695fb30faf9',
+                '2765d4a5884be49b28601445c2760c5f21e7e5c0ee2b7e3fce98fd7e5970796f',
+                'a69ec97f5af2e21e1a1f9cc8896965515d5559425666f734e245a3d40cee33d9',
+            ),
+            (
+                '35788efcb8dfb0a02659d81cf2bfd695fb30fafa',
+                '2765d4a5884be49b28601445c2760c5f21e7e5c0ee2b7e3fce98fd7e5970796f',
+                'eabc7a98e0c12bbeb8394dbdf055eb81aac60e4a14cca5c1f069d36efc933b23',
+            ),
+            (
+                '9d81d76242cc7cfaf7bf74b94b9cd2e29324ed74',
+                '8470d56547eea6236d7c81a644ce74670ca0bbda998e13c629ef6bb3f0d60b69',
+                '7521a98a0c645341bc51559b234ef37a097e8f3a01665e0303a317925ab7b4d5',
+            ),
         )
         EXTRA_QUERIES = (
             "6b6be7a84ab179b4240c4302518dc3f6",
@@ -1024,14 +1110,14 @@ class HashEquivalenceCommonTests(object):
     def test_gc(self):
         taskhash = '53b8dce672cb6d0c73170be43f540460bfc347b4'
         outhash = '5a9cb1649625f0bf41fc7791b635cd9c2d7118c7f021ba87dcd03f72b67ce7a8'
-        unihash = 'f37918cc02eb5a520b1aff86faacbc0a38124646'
+        unihash = '46edb5140d2613049332d0bf3745d9fafec9c559dac8cc61813739a28007fcdf'
 
         result = self.client.report_unihash(taskhash, self.METHOD, outhash, unihash)
         self.assertEqual(result['unihash'], unihash, 'Server returned bad unihash')
 
         taskhash2 = '3bf6f1e89d26205aec90da04854fbdbf73afe6b4'
         outhash2 = '77623a549b5b1a31e3732dfa8fe61d7ce5d44b3370f253c5360e136b852967b4'
-        unihash2 = 'af36b199320e611fbb16f1f277d3ee1d619ca58b'
+        unihash2 = 'bf6e81926066f770e960f9f777cd088c62bea9addb7745f3e77deaa81a645747'
 
         result = self.client.report_unihash(taskhash2, self.METHOD, outhash2, unihash2)
         self.assertClientGetHash(self.client, taskhash2, unihash2)
@@ -1057,14 +1143,14 @@ class HashEquivalenceCommonTests(object):
     def test_gc_switch_mark(self):
         taskhash = '53b8dce672cb6d0c73170be43f540460bfc347b4'
         outhash = '5a9cb1649625f0bf41fc7791b635cd9c2d7118c7f021ba87dcd03f72b67ce7a8'
-        unihash = 'f37918cc02eb5a520b1aff86faacbc0a38124646'
+        unihash = '46edb5140d2613049332d0bf3745d9fafec9c559dac8cc61813739a28007fcdf'
 
         result = self.client.report_unihash(taskhash, self.METHOD, outhash, unihash)
         self.assertEqual(result['unihash'], unihash, 'Server returned bad unihash')
 
         taskhash2 = '3bf6f1e89d26205aec90da04854fbdbf73afe6b4'
         outhash2 = '77623a549b5b1a31e3732dfa8fe61d7ce5d44b3370f253c5360e136b852967b4'
-        unihash2 = 'af36b199320e611fbb16f1f277d3ee1d619ca58b'
+        unihash2 = 'bf6e81926066f770e960f9f777cd088c62bea9addb7745f3e77deaa81a645747'
 
         result = self.client.report_unihash(taskhash2, self.METHOD, outhash2, unihash2)
         self.assertClientGetHash(self.client, taskhash2, unihash2)
@@ -1102,14 +1188,14 @@ class HashEquivalenceCommonTests(object):
     def test_gc_switch_sweep_mark(self):
         taskhash = '53b8dce672cb6d0c73170be43f540460bfc347b4'
         outhash = '5a9cb1649625f0bf41fc7791b635cd9c2d7118c7f021ba87dcd03f72b67ce7a8'
-        unihash = 'f37918cc02eb5a520b1aff86faacbc0a38124646'
+        unihash = '46edb5140d2613049332d0bf3745d9fafec9c559dac8cc61813739a28007fcdf'
 
         result = self.client.report_unihash(taskhash, self.METHOD, outhash, unihash)
         self.assertEqual(result['unihash'], unihash, 'Server returned bad unihash')
 
         taskhash2 = '3bf6f1e89d26205aec90da04854fbdbf73afe6b4'
         outhash2 = '77623a549b5b1a31e3732dfa8fe61d7ce5d44b3370f253c5360e136b852967b4'
-        unihash2 = 'af36b199320e611fbb16f1f277d3ee1d619ca58b'
+        unihash2 = 'bf6e81926066f770e960f9f777cd088c62bea9addb7745f3e77deaa81a645747'
 
         result = self.client.report_unihash(taskhash2, self.METHOD, outhash2, unihash2)
         self.assertClientGetHash(self.client, taskhash2, unihash2)
@@ -1132,7 +1218,7 @@ class HashEquivalenceCommonTests(object):
     def test_gc_new_hashes(self):
         taskhash = '53b8dce672cb6d0c73170be43f540460bfc347b4'
         outhash = '5a9cb1649625f0bf41fc7791b635cd9c2d7118c7f021ba87dcd03f72b67ce7a8'
-        unihash = 'f37918cc02eb5a520b1aff86faacbc0a38124646'
+        unihash = '46edb5140d2613049332d0bf3745d9fafec9c559dac8cc61813739a28007fcdf'
 
         result = self.client.report_unihash(taskhash, self.METHOD, outhash, unihash)
         self.assertEqual(result['unihash'], unihash, 'Server returned bad unihash')
@@ -1149,7 +1235,7 @@ class HashEquivalenceCommonTests(object):
 
         taskhash2 = '3bf6f1e89d26205aec90da04854fbdbf73afe6b4'
         outhash2 = '77623a549b5b1a31e3732dfa8fe61d7ce5d44b3370f253c5360e136b852967b4'
-        unihash2 = 'af36b199320e611fbb16f1f277d3ee1d619ca58b'
+        unihash2 = 'bf6e81926066f770e960f9f777cd088c62bea9addb7745f3e77deaa81a645747'
 
         result = self.client.report_unihash(taskhash2, self.METHOD, outhash2, unihash2)
         self.assertClientGetHash(self.client, taskhash2, unihash2)
@@ -1205,7 +1291,7 @@ class TestHashEquivalenceClient(HashEquivalenceTestSetup, unittest.TestCase):
 
         p = self.run_hashclient([
             "--address", self.server_address,
-            "unihash-exists", '6662e699d6e3d894b24408ff9a4031ef9b038ee8',
+            "unihash-exists", 'cc74784b2c0ad5b378a6b783c74c518d2c46b8b52fba29cb39a8430d742440d7',
         ], check=True)
         self.assertEqual(p.stdout.strip(), "false")
 
@@ -1222,7 +1308,7 @@ class TestHashEquivalenceClient(HashEquivalenceTestSetup, unittest.TestCase):
 
         p = self.run_hashclient([
             "--address", self.server_address,
-            "unihash-exists", '6662e699d6e3d894b24408ff9a4031ef9b038ee8',
+            "unihash-exists", 'cc74784b2c0ad5b378a6b783c74c518d2c46b8b52fba29cb39a8430d742440d7',
             "--quiet",
         ])
         self.assertEqual(p.returncode, 1)
@@ -1448,14 +1534,14 @@ class TestHashEquivalenceClient(HashEquivalenceTestSetup, unittest.TestCase):
     def test_gc(self):
         taskhash = '53b8dce672cb6d0c73170be43f540460bfc347b4'
         outhash = '5a9cb1649625f0bf41fc7791b635cd9c2d7118c7f021ba87dcd03f72b67ce7a8'
-        unihash = 'f37918cc02eb5a520b1aff86faacbc0a38124646'
+        unihash = '46edb5140d2613049332d0bf3745d9fafec9c559dac8cc61813739a28007fcdf'
 
         result = self.client.report_unihash(taskhash, self.METHOD, outhash, unihash)
         self.assertEqual(result['unihash'], unihash, 'Server returned bad unihash')
 
         taskhash2 = '3bf6f1e89d26205aec90da04854fbdbf73afe6b4'
         outhash2 = '77623a549b5b1a31e3732dfa8fe61d7ce5d44b3370f253c5360e136b852967b4'
-        unihash2 = 'af36b199320e611fbb16f1f277d3ee1d619ca58b'
+        unihash2 = 'bf6e81926066f770e960f9f777cd088c62bea9addb7745f3e77deaa81a645747'
 
         result = self.client.report_unihash(taskhash2, self.METHOD, outhash2, unihash2)
         self.assertClientGetHash(self.client, taskhash2, unihash2)
@@ -1498,7 +1584,7 @@ class TestHashEquivalenceUnixServerLongPath(HashEquivalenceTestSetup, unittest.T
         # Simple test that hashes can be created
         taskhash = '35788efcb8dfb0a02659d81cf2bfd695fb30faf9'
         outhash = '2765d4a5884be49b28601445c2760c5f21e7e5c0ee2b7e3fce98fd7e5970796f'
-        unihash = 'f46d3fbb439bd9b921095da657a4de906510d2cd'
+        unihash = 'a69ec97f5af2e21e1a1f9cc8896965515d5559425666f734e245a3d40cee33d9'
 
         self.assertClientGetHash(self.client, taskhash, None)
 
@@ -1585,4 +1671,3 @@ class TestHashEquivalenceExternalServer(HashEquivalenceTestSetup, HashEquivalenc
 
     def test_auth_get_all_users(self):
         self.skipTest("Cannot test all users with external server")
-

documentation/Pipfile

@@ -4,6 +4,8 @@ url = "https://pypi.org/simple"
 verify_ssl = true
 
 [dev-packages]
+sphinx-lint = "*"
+vale = "*"
 
 [packages]
 sphinx = "*"

documentation/README

@@ -151,6 +151,13 @@ dependencies in a virtual environment:
  $ pipenv install
  $ pipenv run make html
 
+Note: if you decide to use Pipenv for installing the dependencies, don't forget
+to prefix all the make commands below with "pipenv run ". The make commands
+which already start with "pipenv run " don't need to be prefixed a second time
+but require you to use Pipenv for them to run and aren't available when
+following the instructions from
+https://docs.yoctoproject.org/dev/ref-manual/system-requirements.html#required-packages-for-the-build-host.
+
 Style checking the Yocto Project documentation
 ==============================================
 
@@ -159,19 +166,19 @@ to validate the text style.
 
 To install Vale:
 
- $ pip install vale
+ $ pipenv install --dev
 
 To run Vale:
 
- $ make stylecheck
+ $ pipenv run 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>
+  $ pipenv run make stylecheck VALEDOCS=<file>
-  $ make stylecheck VALEDOCS="<file1> <file2>"
+  $ pipenv run make stylecheck VALEDOCS="<file1> <file2>"
-  $ make stylecheck VALEDOCS=<dir>
+  $ pipenv run make stylecheck VALEDOCS=<dir>
 
 Lint checking the Yocto Project documentation
 =============================================
@@ -181,19 +188,19 @@ the project uses sphinx-lint (https://github.com/sphinx-contrib/sphinx-lint).
 
 To install sphinx-lint:
 
- $ pip install sphinx-lint
+ $ pipenv install --dev
 
 To run sphinx-lint:
 
- $ make sphinx-lint
+ $ pipenv run 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>
+  $ pipenv run make sphinx-lint SPHINXLINTDOCS=<file>
-  $ make sphinx-lint SPHINXLINTDOCS="<file1> <file2>"
+  $ pipenv run make sphinx-lint SPHINXLINTDOCS="<file1> <file2>"
-  $ make sphinx-lint SPHINXLINTDOCS=<dir>
+  $ pipenv run make sphinx-lint SPHINXLINTDOCS=<dir>
 
 Sphinx theme and CSS customization
 ==================================

documentation/bitbake.rst

@@ -1,8 +1,8 @@
 .. SPDX-License-Identifier: CC-BY-SA-2.0-UK
 
-=====================
+===================
-BitBake Documentation
+BitBake User Manual
-=====================
+===================
 
 |
 

documentation/brief-yoctoprojectqs/index.rst

@@ -19,11 +19,8 @@ build a reference embedded OS called Poky.
       you want to use Yocto Project on to build an image
       (:term:`Build Host`) is not
       a native Linux system, you can still perform these steps by using
-      CROss PlatformS (CROPS) and setting up a Poky container. See the
+      an :wikipedia:`OCI container <Open_Container_Initiative>` (using
-      :ref:`dev-manual/start:setting up to use cross platforms (crops)`
+      `Docker <https://www.docker.com/>`__ or `Podman <https://podman.io/>`__).
-      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.
@@ -61,8 +58,8 @@ following requirements:
 
    -  Git &MIN_GIT_VERSION; or greater
    -  tar &MIN_TAR_VERSION; or greater
-   -  Python &MIN_PYTHON_VERSION; or greater.
+   -  Python &MIN_PYTHON_VERSION; or greater
-   -  gcc &MIN_GCC_VERSION; or greater.
+   -  gcc &MIN_GCC_VERSION; or greater
    -  GNU make &MIN_MAKE_VERSION; or greater
 
 If your build host does not satisfy all of the above version

documentation/bsp-guide/bsp.rst

@@ -7,10 +7,10 @@ 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
 hardware platform. The BSP includes information about the hardware
-features present on the device and kernel configuration information
+features present on the device, any essential bootloader, kernel and
-along with any additional hardware drivers required. The BSP also lists
+device tree configuration, along with any additional hardware drivers required.
-any additional software components required in addition to a generic
+The BSP also lists any additional software components required in addition to
-Linux software stack for both essential and optional platform features.
+a generic Linux software stack for both essential and optional platform features.
 
 This guide presents information about BSP layers, defines a structure
 for components so that BSPs follow a commonly understood layout,
@@ -147,8 +147,7 @@ section.
 #. *Set Up the Build Environment:* Be sure you are set up to use BitBake
    in a shell. See the ":ref:`dev-manual/start:preparing the build host`"
    section in the Yocto Project Development Tasks Manual for information on how
-   to get a build host ready that is either a native Linux machine or a machine
+   to get a :term:`build host` ready.
-   that uses CROPS.
 
 #. *Clone the poky Repository:* You need to have a local copy of the
    Yocto Project :term:`Source Directory` (i.e. a local
@@ -1302,7 +1301,7 @@ to build, and U-Boot configurations.
 
 The following list provides some explanation for the statements found in
 the example reference machine configuration file for the BeagleBone
-development boards. Realize that much more can be defined as part of a
+development board. Realize that much more can be defined as part of a
 machine's configuration file. In general, you can learn about related
 variables that this example does not have by locating the variables in
 the ":ref:`ref-manual/variables:variables glossary`" in the Yocto
@@ -1376,7 +1375,7 @@ Project Reference Manual.
 
 -  :term:`PREFERRED_VERSION_linux-yocto <PREFERRED_VERSION>`:
    Defines the version of the recipe used to build the kernel, which is
-   "6.12" in this case.
+   "6.18%" in this case.
 
 -  :term:`KERNEL_IMAGETYPE`:
    The type of kernel to build for the device. In this case, the
@@ -1435,35 +1434,27 @@ The kernel recipe used to build the kernel image for the BeagleBone
 device was established in the machine configuration::
 
    PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
-   PREFERRED_VERSION_linux-yocto ?= "6.1%"
+   PREFERRED_VERSION_linux-yocto ?= "6.18%"
 
 The ``meta-yocto-bsp/recipes-kernel/linux`` directory in the layer contains
 metadata used to build the kernel. In this case, a kernel append file
-(i.e. ``linux-yocto_6.1.bbappend``) is used to override an established
+(i.e. ``linux-yocto_6.18.bbappend``) is used to override an established
-kernel recipe (i.e. ``linux-yocto_6.1.bb``), which is located in
+kernel recipe (i.e. ``linux-yocto_6.18.bb``), which is located in
-:yocto_git:`/poky/tree/meta/recipes-kernel/linux`.
+:oe_git:`/openembedded-core/tree/meta/recipes-kernel/linux`.
 
 The contents of the append file are::
 
-   KBRANCH:genericx86  = "v6.1/standard/base"
+   COMPATIBLE_MACHINE:genericarm64 = "genericarm64"
-   KBRANCH:genericx86-64  = "v6.1/standard/base"
+   COMPATIBLE_MACHINE:beaglebone-yocto = "beaglebone-yocto"
-   KBRANCH:beaglebone-yocto = "v6.1/standard/beaglebone"
-
-   KMACHINE:genericx86 ?= "common-pc"
-   KMACHINE:genericx86-64 ?= "common-pc-64"
-   KMACHINE:beaglebone-yocto ?= "beaglebone"
-
-   SRCREV_machine:genericx86 ?= "6ec439b4b456ce929c4c07fe457b5d6a4b468e86"
-   SRCREV_machine:genericx86-64 ?= "6ec439b4b456ce929c4c07fe457b5d6a4b468e86"
-   SRCREV_machine:beaglebone-yocto ?= "423e1996694b61fbfc8ec3bf062fc6461d64fde1"
-
    COMPATIBLE_MACHINE:genericx86 = "genericx86"
    COMPATIBLE_MACHINE:genericx86-64 = "genericx86-64"
-   COMPATIBLE_MACHINE:beaglebone-yocto = "beaglebone-yocto"
 
-   LINUX_VERSION:genericx86 = "6.1.30"
+   KMACHINE:beaglebone-yocto ?= "beaglebone"
-   LINUX_VERSION:genericx86-64 = "6.1.30"
+   KMACHINE:genericx86 ?= "common-pc"
-   LINUX_VERSION:beaglebone-yocto = "6.1.20"
+   KMACHINE:genericx86-64 ?= "common-pc-64"
+
+   KBRANCH:genericarm64 ?= "v6.18/standard/genericarm64"
+   SRCREV_machine:genericarm64 ?= "5cd75b0b5da06045acdd0c66e50656ab82cb880f"
 
 This particular append file works for all the machines that are
 part of the ``meta-yocto-bsp`` layer. The relevant statements are

documentation/conf.py

@@ -89,23 +89,38 @@ rst_prolog = """
 .. |author| replace:: %s
 """ % (project, copyright, author)
 
+# base url definitions
+oe_git_server = "https://git.openembedded.org"
+oecore_git = f"{oe_git_server}/openembedded-core"
+bitbake_git = f"{oe_git_server}/bitbake"
+yocto_git_server = "https://git.yoctoproject.org"
+meta_yocto_git = f"{yocto_git_server}/meta-yocto"
+bugzilla_server = "https://bugzilla.yoctoproject.org"
+
 # external links and substitutions
 extlinks = {
-    'bitbake_git': ('https://git.openembedded.org/bitbake%s', None),
+    'bitbake_git': (f'{bitbake_git}%s', None),
+    'bitbake_path': (f'{bitbake_git}/tree/%s', '%s'),
+    'bitbake_rev': (f'{bitbake_git}/commit/?id=%s', '%.7s'),
     '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),
     'yocto_lists': ('https://lists.yoctoproject.org%s', None),
-    'yocto_bugs': ('https://bugzilla.yoctoproject.org%s', None),
+    'yocto_bugs': (f'{bugzilla_server}%s', None),
+    'yocto_bug': (f'{bugzilla_server}/show_bug.cgi?id=%s', '%s'),
     'yocto_ab': ('https://autobuilder.yoctoproject.org%s', None),
     'yocto_docs': ('https://docs.yoctoproject.org%s', None),
-    'yocto_git': ('https://git.yoctoproject.org%s', None),
+    'yocto_git': (f'{yocto_git_server}%s', None),
+    'meta_yocto_path': (f'{meta_yocto_git}/tree/%s', '%s'),
+    'meta_yocto_rev': (f'{meta_yocto_git}/commit/?id=%s', '%.7s'),
     'yocto_sstate': ('http://sstate.yoctoproject.org%s', None),
     'oe_home': ('https://www.openembedded.org%s', None),
     'oe_lists': ('https://lists.openembedded.org%s', None),
-    'oe_git': ('https://git.openembedded.org%s', None),
+    'oe_git': (f'{oe_git_server}%s', None),
+    'oecore_path': (f'{oecore_git}/tree/%s', '%s'),
+    'oecore_rev': (f'{oecore_git}/commit/?id=%s', '%.7s'),
     'oe_wiki': ('https://www.openembedded.org/wiki%s', None),
     'oe_layerindex': ('https://layers.openembedded.org%s', None),
     'oe_layer': ('https://layers.openembedded.org/layerindex/branch/master/layer%s', None),

documentation/contributor-guide/identify-component.rst

@@ -1,7 +1,7 @@
 .. SPDX-License-Identifier: CC-BY-SA-2.0-UK
 
-Identify the component
+Identifying the component
-**********************
+*************************
 
 The Yocto Project and OpenEmbedded ecosystem is built of :term:`layers <Layer>`
 so the first step is to identify the component where the issue likely lies.

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

@@ -28,7 +28,7 @@ file name. It is recommended to use released versions of software as these are
 revisions that upstream are expecting people to use.
 
 Recipe versions should always compare and sort correctly so that upgrades work
-as expected. With conventional versions such as ``1.4`` upgrading ``to 1.5``
+as expected. With conventional versions such as ``1.4`` upgrading to ``1.5``
 this happens naturally, but some versions don't sort. For example,
 ``1.5 Release Candidate 2`` could be written as ``1.5rc2`` but this sorts after
 ``1.5``, so upgrades from feeds won't happen correctly.
@@ -82,7 +82,7 @@ Recipe formatting
 Variable Formatting
 -------------------
 
--  Variable assignment should a space around each side of the operator, e.g.
+-  Variable assignment should include a space around each side of the operator, e.g.
    ``FOO = "bar"``, not ``FOO="bar"``.
 
 -  Double quotes should be used on the right-hand side of the assignment,
@@ -268,14 +268,19 @@ 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:``
+due to upstream making modifications to the license files, you need to briefly
-tag.  Often it's quite trivial, such as::
+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.
 
+The ``License-Update:`` tag is not needed for commits which fix incorrect
+license data in our metadata (for an example see OE-Core commit
+:oecore_rev:`6c8b76d240d2457578a58787121bc5873d724ee2`).
+
 Tips and Guidelines for Writing Recipes
 ---------------------------------------
 
@@ -293,7 +298,7 @@ Tips and Guidelines for Writing Recipes
    - then, copy ``X.orig`` back to ``X``,
    - and, finally, modify ``X``.
 
-   This ensures if rerun the task always has the same end result and the
+   This ensures that rerunning the task always produces the same end result and the
    original file can be preserved to reuse. It also guards against an
    interrupted build corrupting the file.
 
@@ -315,7 +320,7 @@ following status strings:
    No determination has been made yet, or patch has not yet been submitted to
    upstream.
 
-   Keep in mind that every patch submitted upstream reduces the maintainance
+   Keep in mind that every patch submitted upstream reduces the maintenance
    burden in OpenEmbedded and Yocto Project in the long run, so this patch
    status should only be used in exceptional cases if there are genuine
    obstacles to submitting a patch upstream; the reason for that should be
@@ -346,7 +351,7 @@ following status strings:
    The patch is not appropriate for upstream, include a brief reason on the
    same line enclosed with ``[]``. In the past, there were several different
    reasons not to submit patches upstream, but we have to consider that every
-   non-upstreamed patch means a maintainance burden for recipe maintainers.
+   non-upstreamed patch means a maintenance burden for recipe maintainers.
    Currently, the only reasons to mark patches as inappropriate for upstream
    submission are:
 
@@ -403,7 +408,7 @@ CVE patches
 ===========
 
 In order to have a better control of vulnerabilities, patches that fix CVEs must
-contain a ``CVE:`` tag. This tag list all CVEs fixed by the patch. If more than
+contain a ``CVE:`` tag. This tag should list all CVEs fixed by the patch. If more than
 one CVE is fixed, separate them using spaces.
 
 CVE Examples

documentation/contributor-guide/submit-changes.rst

@@ -702,6 +702,12 @@ page.
 
 .. note::
 
+   Patches submitted for a stable branch need to be isolated changes that are
+   human readable and understandable. Fixes for CVEs or other issues which have
+   a high complexity, consist of a large number of commits and/or a large
+   numbers of changed lines are unlikely to be accepted due to the difficulty
+   they cause with maintainability and scalability.
+
    Changes will not typically be accepted for branches which are marked as
    End-Of-Life (EOL).
 
@@ -752,7 +758,7 @@ Taking Patch Review into Account
 You may get feedback on your submitted patches from other community members
 or from the automated patchtest service. If issues are identified in your
 patches then it is usually necessary to address these before the patches are
-accepted into the project. In this case you should your commits according
+accepted into the project. In this case you should revise your commits according
 to the feedback and submit an updated version to the relevant mailing list.
 
 In any case, never fix reported issues by fixing them in new commits

documentation/dev-manual/build-quality.rst

@@ -242,8 +242,8 @@ Here is an example of ``image-info.txt``:
    BAD_RECOMMENDATIONS =
    NO_RECOMMENDATIONS =
    PACKAGE_EXCLUDE =
-   ROOTFS_POSTPROCESS_COMMAND = write_package_manifest; license_create_manifest; cve_check_write_rootfs_manifest;   ssh_allow_empty_password;  ssh_allow_root_login;  postinst_enable_logging;  rootfs_update_timestamp;   write_image_test_data;   empty_var_volatile;   sort_passwd; rootfs_reproducible;
+   ROOTFS_POSTPROCESS_COMMAND = ssh_allow_empty_password  ssh_allow_root_login  postinst_enable_logging  rootfs_update_timestamp   write_image_test_data   empty_var_volatile   sort_passwd rootfs_reproducible
-   IMAGE_POSTPROCESS_COMMAND =  buildhistory_get_imageinfo ;
+   IMAGE_POSTPROCESS_COMMAND =  buildhistory_get_imageinfo
    IMAGESIZE = 9265
 
 Other than ``IMAGESIZE``,

documentation/dev-manual/building.rst

@@ -920,7 +920,7 @@ Replicating a Build Offline
 It can be useful to take a "snapshot" of upstream sources used in a
 build and then use that "snapshot" later to replicate the build offline.
 To do so, you need to first prepare and populate your downloads
-directory your "snapshot" of files. Once your downloads directory is
+directory with your "snapshot" of files. Once your downloads directory is
 ready, you can use it at any time and from any machine to replicate your
 build.
 
@@ -948,7 +948,7 @@ Follow these steps to populate your Downloads directory:
 #. *Populate Your Downloads Directory Without Building:* Use BitBake to
    fetch your sources but inhibit the build::
 
-      $ bitbake target --runonly=fetch
+      $ bitbake target --runall=fetch
 
    The downloads directory (i.e. ``${DL_DIR}``) now has
    a "snapshot" of the source files in the form of tarballs, which can

documentation/dev-manual/external-scm.rst

@@ -38,28 +38,29 @@ configuration file contains the line::
 
    require conf/distro/include/poky-floating-revisions.inc
 
-This line pulls in the
+This line pulls in the listed include file that defines the set of
-listed include file that contains numerous lines of exactly that form::
+AUTOREV-enabled recipes::
 
-   #SRCREV:pn-opkg-native ?= "${AUTOREV}"
+   INHERIT += "poky-bleeding"
-   #SRCREV:pn-opkg-sdk ?= "${AUTOREV}"
-   #SRCREV:pn-opkg ?= "${AUTOREV}"
-   #SRCREV:pn-opkg-utils-native ?= "${AUTOREV}"
-   #SRCREV:pn-opkg-utils ?= "${AUTOREV}"
-   SRCREV:pn-gconf-dbus ?= "${AUTOREV}"
-   SRCREV:pn-matchbox-common ?= "${AUTOREV}"
-   SRCREV:pn-matchbox-config-gtk ?= "${AUTOREV}"
-   SRCREV:pn-matchbox-desktop ?= "${AUTOREV}"
-   SRCREV:pn-matchbox-keyboard ?= "${AUTOREV}"
-   SRCREV:pn-matchbox-panel-2 ?= "${AUTOREV}"
-   SRCREV:pn-matchbox-themes-extra ?= "${AUTOREV}"
-   SRCREV:pn-matchbox-terminal ?= "${AUTOREV}"
-   SRCREV:pn-matchbox-wm ?= "${AUTOREV}"
-   SRCREV:pn-settings-daemon ?= "${AUTOREV}"
-   SRCREV:pn-screenshot ?= "${AUTOREV}"
-   . . .
 
-These lines allow you to
+   POKY_AUTOREV_RECIPES = "\
+       libmatchbox \
+       opkg-utils \
+       matchbox-config-gtk \
+       matchbox-desktop \
+       matchbox-keyboard \
+       matchbox-panel-2 \
+       matchbox-terminal \
+       matchbox-theme-sato \
+       matchbox-wm \
+       pseudo \
+       puzzles \
+       sato-icon-theme \
+       sato-screenshot \
+       settings-daemon \
+   "
+
+This allows you to
 experiment with building a distribution that tracks the latest
 development source for numerous packages.
 

documentation/dev-manual/init-manager.rst

@@ -5,7 +5,7 @@
 Selecting an Initialization Manager
 ***********************************
 
-By default, the Yocto Project uses :wikipedia:`SysVinit <Init#SysV-style>` as
+By default, the :term:`Poky` distro uses :wikipedia:`SysVinit <Init#SysV-style>` as
 the initialization manager. There is also support for BusyBox init, a simpler
 implementation, as well as support for :wikipedia:`systemd <Systemd>`, which
 is a full replacement for init with parallel starting of services, reduced

documentation/dev-manual/libraries.rst

@@ -232,7 +232,7 @@ Here are the implementation details for the IPK Package Management System:
 Installing Multiple Versions of the Same Library
 ================================================
 
-There are be situations where you need to install and use multiple versions
+There might be situations where you need to install and use multiple versions
 of the same library on the same system at the same time. This
 almost always happens when a library API changes and you have
 multiple pieces of software that depend on the separate versions of the

documentation/dev-manual/new-recipe.rst

@@ -825,7 +825,7 @@ different ways:
 -  *systemd:* System Management Daemon (systemd) was designed to replace
    SysVinit and to provide enhanced management of services. For more
    information on systemd, see the systemd homepage at
-   https://freedesktop.org/wiki/Software/systemd/.
+   https://systemd.io/.
 
    To enable a service using systemd, your recipe needs to inherit the
    :ref:`ref-classes-systemd` class. See the ``systemd.bbclass`` file
@@ -976,11 +976,10 @@ kernel recipe you want by using the :term:`PREFERRED_PROVIDER` variable. As
 an example, consider the :yocto_git:`x86-base.inc
 </poky/tree/meta/conf/machine/include/x86/x86-base.inc>` include file, which is a
 machine (i.e. :term:`MACHINE`) configuration file. This include file is the
-reason all x86-based machines use the ``linux-yocto`` kernel. Here are the
+reason all x86-based machines use the ``linux-yocto`` kernel. Here is the
-relevant lines from the include file::
+relevant line from that include file::
 
    PREFERRED_PROVIDER_virtual/kernel ??= "linux-yocto"
-   PREFERRED_VERSION_linux-yocto ??= "4.15%"
 
 When you use a virtual provider, you do not have to "hard code" a recipe
 name as a build dependency. You can use the

documentation/dev-manual/prebuilt-libraries.rst

@@ -153,8 +153,8 @@ default :term:`FILES` variables in ``bitbake.conf`` are::
 
    SOLIBS = ".so.*"
    SOLIBSDEV = ".so"
-   FILES:${PN} = "... ${libdir}/lib*${SOLIBS} ..."
+   FILES:${PN} = "... ${libdir}/lib*${SOLIBS} ... ${base_libdir}/*${SOLIBS} ..."
-   FILES_SOLIBSDEV ?= "... ${libdir}/lib*${SOLIBSDEV} ..."
+   FILES_SOLIBSDEV ?= "${base_libdir}/lib*${SOLIBSDEV} ${libdir}/lib*${SOLIBSDEV}"
    FILES:${PN}-dev = "... ${FILES_SOLIBSDEV} ..."
 
 :term:`SOLIBS` defines a pattern that matches real shared object libraries.

documentation/dev-manual/sbom.rst

@@ -31,9 +31,18 @@ If needed, it can be disabled from a :term:`configuration file`::
 
    INHERIT_DISTRO:remove = "create-spdx"
 
+SPDX version 3 support is available on Yocto &DISTRO_NAME;, but disabled by
+default. To enable it, add the following statements from a :term:`configuration
+file`::
+
+   INHERIT_DISTRO:remove = "create-spdx"
+   INHERIT_DISTRO:append = " create-spdx-3.0"
+
+The following documentation will make the assumption that SPDX3 is used.
+
 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
+``IMAGE-MACHINE.spdx.json`` file in ``tmp/deploy/images/MACHINE/`` inside
-recipes.
+the :term:`Build Directory`.
 
 The :ref:`ref-classes-create-spdx` class offers options to include
 more information in the output :term:`SPDX` data:
@@ -50,19 +59,7 @@ more information in the output :term:`SPDX` data:
 
 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`` too, such as:
+generated files are available in ``tmp/deploy/spdx`` too.
-
--  The individual :term:`SPDX` JSON files in the ``IMAGE-MACHINE.spdx.tar.zst``
-   archive.
-
--  Compressed archives of the files in the generated target packages,
-   in ``packages/packagename.tar.zst`` (when :term:`SPDX_ARCHIVE_PACKAGED`
-   is set).
-
--  Compressed archives of the source files used to build the host tools
-   and the target packages in ``recipes/recipe-packagename.tar.zst``
-   (when :term:`SPDX_ARCHIVE_SOURCES` is set). Those are needed to fulfill
-   "source code access" license requirements.
 
 See also the :term:`SPDX_CUSTOM_ANNOTATION_VARS` variable which allows
 to associate custom notes to a recipe.

documentation/dev-manual/start.rst

@@ -251,11 +251,10 @@ Preparing the Build Host
 This section provides procedures to set up a system to be used as your
 :term:`Build Host` for
 development using the Yocto Project. Your build host can be a native
-Linux machine (recommended), it can be a machine (Linux, Mac, or
+Linux machine (recommended), it can be an :wikipedia:`OCI container
-Windows) that uses `CROPS <https://github.com/crops/poky-container>`__,
+<Open_Container_Initiative>` (such as `Docker <https://www.docker.com/>`__ or
-which leverages `Docker Containers <https://www.docker.com/>`__ or it
+`Podman <https://podman.io/>`__), or it can be a Windows machine capable of
-can be a Windows machine capable of running version 2 of Windows Subsystem
+running version 2 of Windows Subsystem For Linux (WSL 2).
-For Linux (WSL 2).
 
 .. note::
 
@@ -339,101 +338,6 @@ the `Yocto Project BitBake
 <https://marketplace.visualstudio.com/items?itemName=yocto-project.yocto-bitbake>`__
 extension accordingly.
 
-Setting Up to Use CROss PlatformS (CROPS)
------------------------------------------
-
-With `CROPS <https://github.com/crops/poky-container>`__, which
-leverages `Docker Containers <https://www.docker.com/>`__, you can
-create a Yocto Project development environment that is operating system
-agnostic. You can set up a container in which you can develop using the
-Yocto Project on a Windows, Mac, or Linux machine.
-
-Follow these general steps to prepare a Windows, Mac, or Linux machine
-as your Yocto Project build host:
-
-#. *Determine What Your Build Host Needs:*
-   `Docker <https://www.docker.com/what-docker>`__ is a software
-   container platform that you need to install on the build host.
-   Depending on your build host, you might have to install different
-   software to support Docker containers. Go to the Docker installation
-   page and read about the platform requirements in "`Supported
-   Platforms <https://docs.docker.com/engine/install/#supported-platforms>`__"
-   your build host needs to run containers.
-
-#. *Choose What To Install:* Depending on whether or not your build host
-   meets system requirements, you need to install "Docker CE Stable" or
-   the "Docker Toolbox". Most situations call for Docker CE. However, if
-   you have a build host that does not meet requirements (e.g.
-   Pre-Windows 10 or Windows 10 "Home" version), you must install Docker
-   Toolbox instead.
-
-#. *Go to the Install Site for Your Platform:* Click the link for the
-   Docker edition associated with your build host's native software. For
-   example, if your build host is running Microsoft Windows Version 10
-   and you want the Docker CE Stable edition, click that link under
-   "Supported Platforms".
-
-#. *Install the Software:* Once you have understood all the
-   pre-requisites, you can download and install the appropriate
-   software. Follow the instructions for your specific machine and the
-   type of the software you need to install:
-
-   -  Install `Docker Desktop on
-      Windows <https://docs.docker.com/docker-for-windows/install/#install-docker-desktop-on-windows>`__
-      for Windows build hosts that meet requirements.
-
-   -  Install `Docker Desktop on
-      MacOs <https://docs.docker.com/docker-for-mac/install/#install-and-run-docker-desktop-on-mac>`__
-      for Mac build hosts that meet requirements.
-
-   -  Install `Docker Engine on
-      CentOS <https://docs.docker.com/engine/install/centos/>`__
-      for Linux build hosts running the CentOS distribution.
-
-   -  Install `Docker Engine on
-      Debian <https://docs.docker.com/engine/install/debian/>`__
-      for Linux build hosts running the Debian distribution.
-
-   -  Install `Docker Engine for
-      Fedora <https://docs.docker.com/engine/install/fedora/>`__
-      for Linux build hosts running the Fedora distribution.
-
-   -  Install `Docker Engine for
-      Ubuntu <https://docs.docker.com/engine/install/ubuntu/>`__
-      for Linux build hosts running the Ubuntu distribution.
-
-#. *Optionally Orient Yourself With Docker:* If you are unfamiliar with
-   Docker and the container concept, you can learn more here -
-   https://docs.docker.com/get-started/.
-
-#. *Launch Docker or Docker Toolbox:* You should be able to launch
-   Docker or the Docker Toolbox and have a terminal shell on your
-   development host.
-
-#. *Set Up the Containers to Use the Yocto Project:* Go to
-   https://github.com/crops/docker-win-mac-docs/wiki and follow
-   the directions for your particular build host (i.e. Linux, Mac, or
-   Windows).
-
-   Once you complete the setup instructions for your machine, you have
-   the Poky, Extensible SDK, and Toaster containers available. You can
-   click those links from the page and learn more about using each of
-   those containers.
-
-Once you have a container 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 Poky container, see the
-":ref:`dev-manual/start:cloning the \`\`poky\`\` repository`"
-section. 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. 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 (WSL 2)
 -----------------------------------------------------
 

documentation/dev-manual/x32-psabi.rst

@@ -3,8 +3,8 @@
 Using x32 psABI
 ***************
 
-x32 processor-specific Application Binary Interface (`x32
+x32 processor-specific Application Binary Interface (:wikipedia:`x32
-psABI <https://software.intel.com/en-us/node/628948>`__) is a native
+psABI <X32_ABI>`) is a native
 32-bit processor-specific ABI for Intel 64 (x86-64) architectures. An
 ABI defines the calling conventions between functions in a processing
 environment. The interface determines what registers are used and what

documentation/index.rst

@@ -5,10 +5,21 @@
    You can adapt this file completely to your liking, but it should at least
    contain the root `toctree` directive.
 
+==========================================
 Welcome to the Yocto Project Documentation
 ==========================================
 
-|
+.. only:: html
+
+   This is the top level of the Yocto Project documentation tree. The Yocto
+   Project documentation is always a work in progress, just like the Yocto
+   Project itself. Improvements to the documentation are always welcome; join
+   the :yocto_lists:`docs mailing list </g/docs>` if you want to help out.
+
+Introduction and Overview
+=========================
+
+Get started using the Yocto Project.
 
 .. toctree::
    :maxdepth: 1
@@ -17,15 +28,41 @@ Welcome to the Yocto Project Documentation
    Quick Build <brief-yoctoprojectqs/index>
    what-i-wish-id-known
    transitioning-to-a-custom-environment
-   Yocto Project Software Overview <https://www.yoctoproject.org/software-overview/>
+
-   Tips and Tricks Wiki <https://wiki.yoctoproject.org/wiki/TipsAndTricks>
+Get familiar with the development environment and concepts of the Yocto Project.
+
+.. toctree::
+   :maxdepth: 2
+
+   Overview and Concepts <overview-manual/index>
+
+Additional introductory resources.
+
+-  `Technical Overview (external website) <https://www.yoctoproject.org/development/technical-overview/>`__
+-  `Tips and Tricks Wiki (external website) <https://wiki.yoctoproject.org/wiki/TipsAndTricks>`__
+
+Contributing to the Yocto Project
+=================================
+
+Guides on how to contribute to the different parts of the Yocto Project.
+
+.. toctree::
+   :maxdepth: 2
+   :caption: Contributor Guide
+
+   Contributor Guide <contributor-guide/index>
+
+Manuals
+=======
+
+A collection of manuals covering many aspects of the Yocto Project, including
+reference definitions, tutorials, and details about the project's
+infrastructure.
 
 .. toctree::
    :maxdepth: 1
    :caption: Manuals
 
-   Overview and Concepts Manual <overview-manual/index>
-   Contributor Guide <contributor-guide/index>
    Reference Manual <ref-manual/index>
    Board Support Package (BSP) Developer's guide <bsp-guide/index>
    Development Tasks Manual <dev-manual/index>
@@ -34,20 +71,35 @@ Welcome to the Yocto Project Documentation
    Application Development and the Extensible SDK (eSDK) <sdk-manual/index>
    Toaster Manual <toaster-manual/index>
    Test Environment Manual <test-manual/index>
-   bitbake
+   BitBake User Manual <bitbake>
+
+Security Reference
+==================
+
+Security-related processes and contact information for vulnerability reporting.
 
 .. toctree::
    :maxdepth: 1
-   :caption: Security
+   :caption: Security Reference
 
    Yocto Project Security Reference <security-reference/index>
 
+Release Information
+===================
+
+Release notes and migration guides for the different Yocto Project releases.
+
+.. toctree::
+   :maxdepth: 2
+   :caption: Release Information
+
+   Release Notes and Migration Guides <migration-guides/index>
+
 .. toctree::
    :maxdepth: 1
    :caption: Release Manuals
    :hidden:
 
-   Release Information <migration-guides/index>
    releases
 
 .. toctree::

documentation/kernel-dev/common.rst

@@ -696,21 +696,6 @@ the ":ref:`kernel-dev/common:getting ready to develop using ``devtool```" Sectio
 
       $ devtool modify linux-yocto
 
-   .. note::
-
-      During the checkout operation, there is a bug that could cause
-      errors such as the following:
-
-      .. code-block:: none
-
-              ERROR: Taskhash mismatch 2c793438c2d9f8c3681fd5f7bc819efa versus
-                     be3a89ce7c47178880ba7bf6293d7404 for
-                     /path/to/esdk/layers/poky/meta/recipes-kernel/linux/linux-yocto_4.10.bb.do_unpack
-
-
-      You can safely ignore these messages. The source code is correctly
-      checked out.
-
 #. *Edit the Source Files* Follow these steps to make some simple
    changes to the source files:
 

documentation/kernel-dev/concepts-appx.rst

@@ -76,22 +76,6 @@ and included with Yocto Project releases:
 -  *linux-yocto-dev:* A development kernel based on the latest
    upstream release candidate available.
 
-.. note::
-
-   Long Term Support Initiative (LTSI) for Yocto Linux kernels is as
-   follows:
-
-   -  For Yocto Project releases 1.7, 1.8, and 2.0, the LTSI kernel is
-      ``linux-yocto-3.14``.
-
-   -  For Yocto Project releases 2.1, 2.2, and 2.3, the LTSI kernel is
-      ``linux-yocto-4.1``.
-
-   -  For Yocto Project release 2.4, the LTSI kernel is
-      ``linux-yocto-4.9``
-
-   -  ``linux-yocto-4.4`` is an LTS kernel.
-
 Once a Yocto Linux kernel is officially released, the Yocto Project team
 goes into their next development cycle, or upward revision (uprev)
 cycle, while still continuing maintenance on the released kernel. It is

documentation/kernel-dev/intro.rst

@@ -23,11 +23,7 @@ whose Git repositories you can view in the Yocto
 heading. New recipes for the release track the latest Linux kernel
 upstream developments from https://www.kernel.org and introduce
 newly-supported platforms. Previous recipes in the release are refreshed
-and supported for at least one additional Yocto Project release. As they
+and supported for at least one additional Yocto Project release.
-align, these previous releases are updated to include the latest from
-the Long Term Support Initiative (LTSI) project. You can learn more
-about Yocto Linux kernels and LTSI in the
-":ref:`kernel-dev/concepts-appx:yocto project kernel development and maintenance`" section.
 
 Also included is a Yocto Linux kernel development recipe
 (``linux-yocto-dev.bb``) should you want to work with the very latest in

documentation/migration-guides/release-4.0.rst

@@ -39,3 +39,6 @@ Release 4.0 (kirkstone)
    release-notes-4.0.30
    release-notes-4.0.31
    release-notes-4.0.32
+   release-notes-4.0.33
+   release-notes-4.0.34
+   release-notes-4.0.35

documentation/migration-guides/release-5.0.rst

@@ -23,3 +23,6 @@ Release 5.0 (scarthgap)
    release-notes-5.0.14
    release-notes-5.0.15
    release-notes-5.0.16
+   release-notes-5.0.17
+   release-notes-5.0.18
+   release-notes-5.0.19

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

@@ -200,7 +200,7 @@ openembedded-core
 
 meta-mingw
 
--  Repository Location: :yocto_git:`meta-mingw`
+-  Repository Location: :yocto_git:`/meta-mingw`
 -  Branch: :yocto_git:`honister </meta-mingw/log/?h=honister>`
 -  Tag: :yocto_git:`yocto-3.4.2 </meta-mingw/tag/?h=yocto-3.4.2>`
 -  Git Revision: :yocto_git:`f5d761cbd5c957e4405c5d40b0c236d263c916a8 </meta-mingw/commit/?id=f5d761cbd5c957e4405c5d40b0c236d263c916a8>`
@@ -239,4 +239,4 @@ yocto-docs
 -  Repository Location: :yocto_git:`/yocto-docs`
 -  Branch: :yocto_git:`honister </yocto-docs/log/?h=honister>`
 -  Tag: :yocto_git:`yocto-3.4.2 </yocto-docs/tag/?h=yocto-3.4.2>`
--  Git Revision: :yocto_git:`3061d3d62054a5c3b9e16bfce4bcd186fa7a23d2` </yocto-docs/commit/?3061d3d62054a5c3b9e16bfce4bcd186fa7a23d2>`
+-  Git Revision: :yocto_git:`3061d3d62054a5c3b9e16bfce4bcd186fa7a23d2 </yocto-docs/commit/?3061d3d62054a5c3b9e16bfce4bcd186fa7a23d2>`

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

@@ -0,0 +1,182 @@
+Release notes for Yocto-4.0.33 (Kirkstone)
+------------------------------------------
+
+Security Fixes in Yocto-4.0.33
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  binutils: Fix :cve_nist:`2025-1181`, :cve_nist:`2025-11494`, :cve_nist:`2025-11839` and
+   :cve_nist:`2025-11840`
+-  cups: Fix :cve_nist:`2025-58436` and :cve_nist:`2025-61915`
+-  curl: Fix :cve_nist:`2025-14017`, :cve_nist:`2025-15079` and :cve_nist:`2025-15224`
+-  dropbear: Fix :cve_nist:`2019-6111`
+-  glib-2.0: Fix :cve_nist:`2025-13601`, :cve_nist:`2025-14087` and :cve_nist:`2025-14512`
+-  gnupg: Fix :cve_nist:`2025-68973`
+-  go: Fix :cve_nist:`2023-39323`, :cve_nist:`2025-61727` and :cve_nist:`2025-61729`
+-  go: Fix :cve_nist:`2025-58187` (update patch)
+-  grub: Fix :cve_nist:`2025-61661`, :cve_nist:`2025-61662`, :cve_nist:`2025-61663` and
+   :cve_nist:`2025-61664`
+-  libarchive: Fix :cve_nist:`2025-60753` (update patch)
+-  libpcap: Fix :cve_nist:`2025-11961` and :cve_nist:`2025-11964`
+-  libsoup: fix :cve_nist:`2025-12105`
+-  libxslt: Fix :cve_nist:`2025-11731`
+-  python3: Fix :cve_nist:`2025-13836`
+-  python3-urllib3: Fix :cve_nist:`2025-66418`
+-  qemu: Fix :cve_nist:`2025-12464`
+-  qemu: Ignore :cve_nist:`2025-54566` and :cve_nist:`2025-54567`
+-  rsync: Fix :cve_nist:`2025-10158`
+-  util-linux: Fix :cve_nist:`2025-14104`
+
+
+Fixes in Yocto-4.0.33
+~~~~~~~~~~~~~~~~~~~~~
+
+-  build-appliance-image: Update to kirkstone head revision
+-  contributor-guide/recipe-style-guide.rst: explain difference between layer and recipe license(s)
+-  cross.bbclass: Propagate dependencies to outhash
+-  cups: allow unknown directives in conf files
+-  docs: Add a new "Security" section
+-  oeqa: Use 2.14 release of cpio instead of 2.13
+-  overview-manual/yp-intro.rst: change removed ECOSYSTEM to ABOUT
+-  overview-manual/yp-intro.rst: fix SDK type in bullet list
+-  overview-manual/yp-intro.rst: link to YP members and participants
+-  overview-manual: convert YP-flow-diagram.png to SVG
+-  poky.conf: Bump version for 4.0.33 release
+-  pseudo: Upgrade to 1.9.2+git125b020dd2
+-  ref-manual/classes.rst: document the image-container class
+-  ref-manual/release-process.rst: add a "Development Cycle" section
+-  ref-manual/svg/releases.svg: mark styhead and walnascar EOL
+-  ref-manual/svg/releases.svg: mark whinlatter as current release
+-  ref-manual/variables.rst: document the :term:`CCACHE_TOP_DIR` variable
+-  scripts/install-buildtools: Update to 4.0.31
+-  test-manual/ptest.rst: detail the exit code and output requirements
+
+
+Known Issues in Yocto-4.0.33
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+- N/A
+
+
+Contributors to Yocto-4.0.33
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  Aleksandar Nikolic
+-  Antonin Godard
+-  Changqing Li
+-  Deepesh Varatharajan
+-  Hitendra Prajapati
+-  Jiaying Song
+-  Kai Kang
+-  Khem Raj
+-  Libo Chen
+-  Liyin Zhang
+-  Martin Jansa
+-  Mingli Yu
+-  Paul Barker
+-  Peter Marko
+-  Richard Purdie
+-  Robert Yang
+-  Vijay Anusuri
+-  Yash Shinde
+
+Repositories / Downloads for Yocto-4.0.33
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+yocto-docs
+
+-  Repository Location: :yocto_git:`/yocto-docs`
+-  Branch: :yocto_git:`kirkstone </yocto-docs/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.33 </yocto-docs/log/?h=yocto-4.0.33>`
+-  Git Revision: :yocto_git:`6799b1be5d48f4bf5dcd0b16c2dbc2e297d4ecd9 </yocto-docs/commit/?id=6799b1be5d48f4bf5dcd0b16c2dbc2e297d4ecd9>`
+-  Release Artefact: yocto-docs-6799b1be5d48f4bf5dcd0b16c2dbc2e297d4ecd9
+-  sha: 42a0eb89c8f87a9a966aecb8265f463486d4383cb67d1e67382ddf9d4d7f88b5
+-  Download Locations:
+
+   https://downloads.yoctoproject.org/releases/yocto/yocto-4.0.33/yocto-docs-6799b1be5d48f4bf5dcd0b16c2dbc2e297d4ecd9.tar.bz2
+
+   https://mirrors.edge.kernel.org/yocto/yocto/yocto-4.0.33/yocto-docs-6799b1be5d48f4bf5dcd0b16c2dbc2e297d4ecd9.tar.bz2
+
+poky
+
+-  Repository Location: :yocto_git:`/poky`
+-  Branch: :yocto_git:`kirkstone </poky/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.33 </poky/log/?h=yocto-4.0.33>`
+-  Git Revision: :yocto_git:`ff118ede826a9ae45eb35025a5f7f612880fba01 </poky/commit/?id=ff118ede826a9ae45eb35025a5f7f612880fba01>`
+-  Release Artefact: poky-ff118ede826a9ae45eb35025a5f7f612880fba01
+-  sha: 2a8c24406fa96fc52728a96f25136a3fd7ee652eea6e12319a6b7c0457ccfdfd
+-  Download Locations:
+
+   https://downloads.yoctoproject.org/releases/yocto/yocto-4.0.33/poky-ff118ede826a9ae45eb35025a5f7f612880fba01.tar.bz2
+
+   https://mirrors.edge.kernel.org/yocto/yocto/yocto-4.0.33/poky-ff118ede826a9ae45eb35025a5f7f612880fba01.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.33 </openembedded-core/log/?h=yocto-4.0.33>`
+-  Git Revision: :oe_git:`036f76ea35c49a78d612093dcd8eb1fac7ded8d7 </openembedded-core/commit/?id=036f76ea35c49a78d612093dcd8eb1fac7ded8d7>`
+-  Release Artefact: oecore-036f76ea35c49a78d612093dcd8eb1fac7ded8d7
+-  sha: fc180ff224529fd73a7aec4a4cf5beb40fba17646ee694715cf603baba26610c
+-  Download Locations:
+
+   https://downloads.yoctoproject.org/releases/yocto/yocto-4.0.33/oecore-036f76ea35c49a78d612093dcd8eb1fac7ded8d7.tar.bz2
+
+   https://mirrors.edge.kernel.org/yocto/yocto/yocto-4.0.33/oecore-036f76ea35c49a78d612093dcd8eb1fac7ded8d7.tar.bz2
+
+meta-yocto
+
+-  Repository Location: :yocto_git:`/meta-yocto`
+-  Branch: :yocto_git:`kirkstone </meta-yocto/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.33 </meta-yocto/log/?h=yocto-4.0.33>`
+-  Git Revision: :yocto_git:`677379f21941363d50f9d946963542b4ccb7e27c </meta-yocto/commit/?id=677379f21941363d50f9d946963542b4ccb7e27c>`
+-  Release Artefact: meta-yocto-677379f21941363d50f9d946963542b4ccb7e27c
+-  sha: 90f52c406f4e69748b8d73eee07b8a1247d19cc29f4893174f110a034b10415f
+-  Download Locations:
+
+   https://downloads.yoctoproject.org/releases/yocto/yocto-4.0.33/meta-yocto-677379f21941363d50f9d946963542b4ccb7e27c.tar.bz2
+
+   https://mirrors.edge.kernel.org/yocto/yocto/yocto-4.0.33/meta-yocto-677379f21941363d50f9d946963542b4ccb7e27c.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.33 </meta-mingw/log/?h=yocto-4.0.33>`
+-  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.33/meta-mingw-87c22abb1f11be430caf4372e6b833dc7d77564e.tar.bz2
+
+   https://mirrors.edge.kernel.org/yocto/yocto/yocto-4.0.33/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.33 </meta-gplv2/log/?h=yocto-4.0.33>`
+-  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.33/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2
+
+   https://mirrors.edge.kernel.org/yocto/yocto/yocto-4.0.33/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.33 </bitbake/log/?h=yocto-4.0.33>`
+-  Git Revision: :oe_git:`8e2d1f8de055549b2101614d85454fcd1d0f94b2 </bitbake/commit/?id=8e2d1f8de055549b2101614d85454fcd1d0f94b2>`
+-  Release Artefact: bitbake-8e2d1f8de055549b2101614d85454fcd1d0f94b2
+-  sha: fad4e7699bae62082118e89785324b031b0af0743064caee87c91ba28549afb0
+-  Download Locations:
+
+   https://downloads.yoctoproject.org/releases/yocto/yocto-4.0.33/bitbake-8e2d1f8de055549b2101614d85454fcd1d0f94b2.tar.bz2
+
+   https://mirrors.edge.kernel.org/yocto/yocto/yocto-4.0.33/bitbake-8e2d1f8de055549b2101614d85454fcd1d0f94b2.tar.bz2
+

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

@@ -0,0 +1,191 @@
+Release notes for Yocto-4.0.34 (Kirkstone)
+------------------------------------------
+
+Security Fixes in Yocto-4.0.34
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  avahi: Fix :cve_nist:`2026-24401`, :cve_nist:`2025-68276`, :cve_nist:`2025-68468` and
+   :cve_nist:`2025-68471`
+-  bind: Fix :cve_nist:`2025-13878`
+-  expat: Fix :cve_nist:`2026-24515` and :cve_nist:`2026-25210`
+-  ffmpeg: Ignore :cve_nist:`2025-25468` and :cve_nist:`2025-25469`
+-  glib-2.0: Fix :cve_nist:`2026-0988`, :cve_nist:`2026-1484`, :cve_nist:`2026-1485` and
+   :cve_nist:`2026-1489`
+-  glibc: Fix :cve_nist:`2025-15281`, :cve_nist:`2026-0861` and :cve_nist:`2026-0915`
+-  harfbuzz: Ignore :cve_nist:`2026-22693`
+-  inetutils: Fix :cve_nist:`2026-24061`
+-  libpng: Fix :cve_nist:`2026-22695`, :cve_nist:`2026-22801` and :cve_nist:`2026-25646`
+-  libtasn1: Fix :cve_nist:`2025-13151`
+-  libxml2: Fix :cve_nist:`2026-0990` and :cve_nist:`2026-0992`
+-  linux-yocto/5.15: Fix :cve_nist:`2022-49465`, :cve_nist:`2023-54207`, :cve_nist:`2025-22058`,
+   :cve_nist:`2025-40040`, :cve_nist:`2025-40149`, :cve_nist:`2025-40164`, :cve_nist:`2025-68211`,
+   :cve_nist:`2025-68340`, :cve_nist:`2025-68365`, :cve_nist:`2025-68725`, :cve_nist:`2025-68817`,
+   :cve_nist:`2025-71147`, :cve_nist:`2025-71154`, :cve_nist:`2025-71162`, :cve_nist:`2025-71163`,
+   :cve_nist:`2026-22976`, :cve_nist:`2026-22977`, :cve_nist:`2026-22978`, :cve_nist:`2026-22980`,
+   :cve_nist:`2026-22982`, :cve_nist:`2026-22984`, :cve_nist:`2026-22990`, :cve_nist:`2026-22991`,
+   :cve_nist:`2026-22992`, :cve_nist:`2026-22997`, :cve_nist:`2026-22998`, :cve_nist:`2026-22999`,
+   :cve_nist:`2026-23060`, :cve_nist:`2026-23061`, :cve_nist:`2026-23063`, :cve_nist:`2026-23064`,
+   :cve_nist:`2026-23076`, :cve_nist:`2026-23078`, :cve_nist:`2026-23080`, :cve_nist:`2026-23083`,
+   :cve_nist:`2026-23084`, :cve_nist:`2026-23085`, :cve_nist:`2026-23087`, :cve_nist:`2026-23089`,
+   :cve_nist:`2026-23090`, :cve_nist:`2026-23091`, :cve_nist:`2026-23093`, :cve_nist:`2026-23095`,
+   :cve_nist:`2026-23096`, :cve_nist:`2026-23097`, :cve_nist:`2026-23119`, :cve_nist:`2026-23120`,
+   :cve_nist:`2026-23121`, :cve_nist:`2026-23124`, :cve_nist:`2026-23125`, :cve_nist:`2026-23133`,
+   :cve_nist:`2026-23146`, :cve_nist:`2026-23150`, :cve_nist:`2026-23164`, :cve_nist:`2026-23167`
+   and :cve_nist:`2026-23170`
+-  openssl: Fix :cve_nist:`2025-15467`, :cve_nist:`2026-22795`, :cve_nist:`2026-22796`,
+   :cve_nist:`2025-68160`, :cve_nist:`2025-69418`, :cve_nist:`2025-69419`, :cve_nist:`2025-69420`
+   and :cve_nist:`2025-69421`
+-  python3: Fix :cve_nist:`2025-12084` and :cve_nist:`2025-13837`
+-  vim: Ignore :cve_nist:`2025-66476`
+-  zlib: Ignore :cve_nist:`2026-22184`
+
+
+Fixes in Yocto-4.0.34
+~~~~~~~~~~~~~~~~~~~~~
+
+-  bind: Upgrade to 9.18.44
+-  build-appliance-image: Update to kirkstone head revision
+-  classes/buildhistory: Do not sign buildhistory commits
+-  dev-manual/packages.rst: fix example recipe version
+-  dev-manual/packages.rst: pr server: fix and explain why r0.X increments on :term:`SRCREV` change
+-  dev-manual/packages.rst: rename r0.0 to r0 when :term:`PR` server is not enabled
+-  glibc: stable 2.35 branch updates
+-  linux-yocto/5.15: update to v5.15.199
+-  migration-guides: add release notes for 4.0.32
+-  openssl: upgrade to 3.0.19
+-  poky.conf: Bump version for 4.0.34 release
+-  poky.conf: add fedora-41, debian-12, rocky-8&9 to :term:`SANITY_TESTED_DISTROS`
+-  pseudo: Update to 1.9.3+git43cbd8fb49
+-  ref-manual/classes.rst: fix broken links to U-Boot documentation
+-  ref-manual/system-requirements.rst: update untested distros
+-  scripts/install-buildtools: Update to 4.0.32
+-  u-boot: move CVE patch out of u-boot-common.inc
+-  what-i-wish-id-known.rst: replace figure by the new SVG
+
+
+Known Issues in Yocto-4.0.34
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+- N/A
+
+
+Contributors to Yocto-4.0.34
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  Aleksandar Nikolic
+-  Amaury Couderc
+-  Ankur Tyagi
+-  Antonin Godard
+-  Bruce Ashfield
+-  Fabio Berton
+-  Hugo SIMELIERE
+-  Lee Chee Yang
+-  Michael Opdenacker
+-  Paul Barker
+-  Peter Marko
+-  Richard Purdie
+-  Scott Murray
+-  Vijay Anusuri
+-  Yoann Congal
+
+Repositories / Downloads for Yocto-4.0.34
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+yocto-docs
+
+-  Repository Location: :yocto_git:`/yocto-docs`
+-  Branch: :yocto_git:`kirkstone </yocto-docs/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.34 </yocto-docs/log/?h=yocto-4.0.34>`
+-  Git Revision: :yocto_git:`7c348dd67cfd169b1a56bf969606b03dccb76c56 </yocto-docs/commit/?id=7c348dd67cfd169b1a56bf969606b03dccb76c56>`
+-  Release Artefact: yocto-docs-7c348dd67cfd169b1a56bf969606b03dccb76c56
+-  sha: 0677fc3aee3c936599f3bcffbe16792494058bd3506ca3ab1697ceac1822829b
+-  Download Locations:
+
+   https://downloads.yoctoproject.org/releases/yocto/yocto-4.0.34/yocto-docs-7c348dd67cfd169b1a56bf969606b03dccb76c56.tar.bz2
+
+   https://mirrors.edge.kernel.org/yocto/yocto/yocto-4.0.34/yocto-docs-7c348dd67cfd169b1a56bf969606b03dccb76c56.tar.bz2
+
+poky
+
+-  Repository Location: :yocto_git:`/poky`
+-  Branch: :yocto_git:`kirkstone </poky/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.34 </poky/log/?h=yocto-4.0.34>`
+-  Git Revision: :yocto_git:`8334e82e1d85e50557bd3da64054fc9e3eafc495 </poky/commit/?id=8334e82e1d85e50557bd3da64054fc9e3eafc495>`
+-  Release Artefact: poky-8334e82e1d85e50557bd3da64054fc9e3eafc495
+-  sha: 74fcc57d1dd3bb0c6ef77bfaaeca7504f393e705a55149cf52d4b61981c9c387
+-  Download Locations:
+
+   https://downloads.yoctoproject.org/releases/yocto/yocto-4.0.34/poky-8334e82e1d85e50557bd3da64054fc9e3eafc495.tar.bz2
+
+   https://mirrors.edge.kernel.org/yocto/yocto/yocto-4.0.34/poky-8334e82e1d85e50557bd3da64054fc9e3eafc495.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.34 </openembedded-core/log/?h=yocto-4.0.34>`
+-  Git Revision: :oe_git:`7b6c9faa301a6d058ca34e230586f6a81ffa3ffb </openembedded-core/commit/?id=7b6c9faa301a6d058ca34e230586f6a81ffa3ffb>`
+-  Release Artefact: oecore-7b6c9faa301a6d058ca34e230586f6a81ffa3ffb
+-  sha: 375a22e3e229064749e78c80c44cde95adcedd26df76045fccefa3a9d3fa14ad
+-  Download Locations:
+
+   https://downloads.yoctoproject.org/releases/yocto/yocto-4.0.34/oecore-7b6c9faa301a6d058ca34e230586f6a81ffa3ffb.tar.bz2
+
+   https://mirrors.edge.kernel.org/yocto/yocto/yocto-4.0.34/oecore-7b6c9faa301a6d058ca34e230586f6a81ffa3ffb.tar.bz2
+
+meta-yocto
+
+-  Repository Location: :yocto_git:`/meta-yocto`
+-  Branch: :yocto_git:`kirkstone </meta-yocto/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.34 </meta-yocto/log/?h=yocto-4.0.34>`
+-  Git Revision: :yocto_git:`1d3874a383023a5e2433e0fcfd87ac5d1e6d341d </meta-yocto/commit/?id=1d3874a383023a5e2433e0fcfd87ac5d1e6d341d>`
+-  Release Artefact: meta-yocto-1d3874a383023a5e2433e0fcfd87ac5d1e6d341d
+-  sha: baf48bbe1f29686d502c0c6f311c7723b0a18f08e7efbf89c150589102285dbe
+-  Download Locations:
+
+   https://downloads.yoctoproject.org/releases/yocto/yocto-4.0.34/meta-yocto-1d3874a383023a5e2433e0fcfd87ac5d1e6d341d.tar.bz2
+
+   https://mirrors.edge.kernel.org/yocto/yocto/yocto-4.0.34/meta-yocto-1d3874a383023a5e2433e0fcfd87ac5d1e6d341d.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.34 </meta-mingw/log/?h=yocto-4.0.34>`
+-  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.34/meta-mingw-87c22abb1f11be430caf4372e6b833dc7d77564e.tar.bz2
+
+   https://mirrors.edge.kernel.org/yocto/yocto/yocto-4.0.34/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.34 </meta-gplv2/log/?h=yocto-4.0.34>`
+-  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.34/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2
+
+   https://mirrors.edge.kernel.org/yocto/yocto/yocto-4.0.34/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.34 </bitbake/log/?h=yocto-4.0.34>`
+-  Git Revision: :oe_git:`8e2d1f8de055549b2101614d85454fcd1d0f94b2 </bitbake/commit/?id=8e2d1f8de055549b2101614d85454fcd1d0f94b2>`
+-  Release Artefact: bitbake-8e2d1f8de055549b2101614d85454fcd1d0f94b2
+-  sha: fad4e7699bae62082118e89785324b031b0af0743064caee87c91ba28549afb0
+-  Download Locations:
+
+   https://downloads.yoctoproject.org/releases/yocto/yocto-4.0.34/bitbake-8e2d1f8de055549b2101614d85454fcd1d0f94b2.tar.bz2
+
+   https://mirrors.edge.kernel.org/yocto/yocto/yocto-4.0.34/bitbake-8e2d1f8de055549b2101614d85454fcd1d0f94b2.tar.bz2
+

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

@@ -0,0 +1,198 @@
+.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
+
+Release notes for Yocto-4.0.35 (Kirkstone)
+------------------------------------------
+
+Security Fixes in Yocto-4.0.35
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  alsa-lib: Fix :cve_nist:`2026-25068`
+-  busybox: Fix :cve_nist:`2025-60876`
+-  curl: Fix :cve_nist:`2025-14524`, :cve_nist:`2026-1965`, :cve_nist:`2026-3783` and
+   :cve_nist:`2026-3784`
+-  ffmpeg: Fix :cve_nist:`2025-10256`
+-  gdk-pixbuf: Fix :cve_nist:`2025-6199`
+-  inetutils: Fix :cve_nist:`2026-28372`
+-  libarchive: Fix :cve_nist:`2026-4111`
+-  libpam: Fix :cve_nist:`2024-10963`
+-  linux-yocto/5.15: Fix :cve_nist:`2025-40082`, :cve_nist:`2025-68358`, :cve_nist:`2025-71089`,
+   :cve_nist:`2025-71220`, :cve_nist:`2025-71222`, :cve_nist:`2025-71232`, :cve_nist:`2025-71233`,
+   :cve_nist:`2025-71235`, :cve_nist:`2025-71236`, :cve_nist:`2025-71237`, :cve_nist:`2025-71238`,
+   :cve_nist:`2026-23111`, :cve_nist:`2026-23112`, :cve_nist:`2026-23169`, :cve_nist:`2026-23190`,
+   :cve_nist:`2026-23193`, :cve_nist:`2026-23198`, :cve_nist:`2026-23202`, :cve_nist:`2026-23206`,
+   :cve_nist:`2026-23209`, :cve_nist:`2026-23216`, :cve_nist:`2026-23221`, :cve_nist:`2026-23222`,
+   :cve_nist:`2026-23228`, :cve_nist:`2026-23229`, :cve_nist:`2026-23231`, :cve_nist:`2026-23234`,
+   :cve_nist:`2026-23235`, :cve_nist:`2026-23236`, :cve_nist:`2026-23237` and :cve_nist:`2026-23238`
+-  ncurses: Fix :cve_nist:`2025-69720`
+-  python3: Fix :cve_nist:`2024-6923`, :cve_nist:`2025-15282`, :cve_nist:`2025-59375`,
+   :cve_nist:`2026-0865`, :cve_nist:`2026-24515` and :cve_nist:`2026-25210`
+-  python3-pip: Fix :cve_nist:`2026-1703`
+-  python3-pyopenssl: Fix :cve_nist:`2026-27448` and :cve_nist:`2026-27459`
+-  sqlite3: Fix :cve_nist:`2025-70873`
+-  tiff: Fix :cve_nist:`2025-61143` and :cve_nist:`2025-61144`
+-  vim: Fix :cve_nist:`2026-25749`, :cve_nist:`2026-26269`, :cve_nist:`2026-28418`,
+   :cve_nist:`2026-28419` and :cve_nist:`2026-33412`
+
+
+Fixes in Yocto-4.0.35
+~~~~~~~~~~~~~~~~~~~~~
+
+-  bitbake: tests/fetch: Avoid using git protocol in tests
+-  build-appliance-image: Update to kirkstone head revision
+-  contributor-guide/submit-changes.rst: Added missing word
+-  create-pull-request: Keep commit hash to be pulled in cover email
+-  createrepo-c: Fix createrepo-c-native build on GCC14 hosts (e.g. Fedora 41)
+-  gtk+3: fix incompatible-pointer-types errors for native build on Fedora 41
+-  libcomps: Fix libcomps-native build on GCC14 hosts (e.g. Fedora 41)
+-  libpam: re-add missing libgen include
+-  libtheora: set :term:`CVE_PRODUCT`
+-  linux-yocto/5.15: update to v5.15.201
+-  lsb.py: strip ' from os-release file
+-  migration-guide: add release notes for 4.0.33 4.0.34
+-  oeqa/manual: Default to https git protocol for YP/OE repos
+-  oeqa/sdk: Default to https git protocol for YP/OE repos
+-  oeqa/selftest/git-submodule-test: Default to https git protocol for YP/OE repos
+-  overview-manual: escape wildcard in inline markup
+-  poky.conf: Bump version for 4.0.35 release
+-  python3: upgrade to 3.10.20
+-  README.OE-Core: update contributor links and add kirkstone prefix
+-  recipes: Default to https git protocol for YP/OE repos
+-  recipetool: Recognise https://git. as git urls
+-  ref-manual/system-requirements.rst: update end-of-life distros
+-  scripts/install-buildtools: Update to 4.0.34
+-  scripts: Default to https git protocol for YP/OE repos
+-  selftest/scripts: Update old git protocol references
+-  tcl: skip http11 tests
+-  tiff: set status of CVE-2025-61145 as fixed by patch for :cve_nist:`2025-8961`
+-  tzdata,tzcode-native: Upgrade to 2026a
+
+
+Known Issues in Yocto-4.0.35
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+- N/A
+
+
+Contributors to Yocto-4.0.35
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  Aleksandar Nikolic
+-  Antonin Godard
+-  Bruce Ashfield
+-  Fabien Thomas
+-  Hitendra Prajapati
+-  Jinfeng Wang
+-  Ken Kurematsu
+-  Kristiyan Chakarov
+-  Lee Chee Yang
+-  Martin Jansa
+-  Paul Barker
+-  Peter Marko
+-  Richard Purdie
+-  Ross Burton
+-  Shaik Moin
+-  Vijay Anusuri
+-  Yanis BINARD
+-  Yoann Congal
+
+Repositories / Downloads for Yocto-4.0.35
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+yocto-docs
+
+-  Repository Location: :yocto_git:`/yocto-docs`
+-  Branch: :yocto_git:`kirkstone </yocto-docs/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.35 </yocto-docs/log/?h=yocto-4.0.35>`
+-  Git Revision: :yocto_git:`ce6734c68649739c635675a133fa77edb9865028 </yocto-docs/commit/?id=ce6734c68649739c635675a133fa77edb9865028>`
+-  Release Artefact: yocto-docs-ce6734c68649739c635675a133fa77edb9865028
+-  sha: ddb6fac4d257f4f76836055cafad529729e99c293d3b8d3dabef926fad5e725f
+-  Download Locations:
+
+   https://downloads.yoctoproject.org/releases/yocto/yocto-4.0.35/yocto-docs-ce6734c68649739c635675a133fa77edb9865028.tar.bz2
+
+   https://mirrors.edge.kernel.org/yocto/yocto/yocto-4.0.35/yocto-docs-ce6734c68649739c635675a133fa77edb9865028.tar.bz2
+
+poky
+
+-  Repository Location: :yocto_git:`/poky`
+-  Branch: :yocto_git:`kirkstone </poky/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.35 </poky/log/?h=yocto-4.0.35>`
+-  Git Revision: :yocto_git:`93431249a6260da7bd29ee3ca32145d89e5b8259 </poky/commit/?id=93431249a6260da7bd29ee3ca32145d89e5b8259>`
+-  Release Artefact: poky-93431249a6260da7bd29ee3ca32145d89e5b8259
+-  sha: a8e95213248c5400276611754f2c98b8d8972e166bdf41433c45fcdd2bf668cb
+-  Download Locations:
+
+   https://downloads.yoctoproject.org/releases/yocto/yocto-4.0.35/poky-93431249a6260da7bd29ee3ca32145d89e5b8259.tar.bz2
+
+   https://mirrors.edge.kernel.org/yocto/yocto/yocto-4.0.35/poky-93431249a6260da7bd29ee3ca32145d89e5b8259.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.35 </openembedded-core/log/?h=yocto-4.0.35>`
+-  Git Revision: :oe_git:`51259c7e933a2ac8ebc01604d6e65607b76b7b56 </openembedded-core/commit/?id=51259c7e933a2ac8ebc01604d6e65607b76b7b56>`
+-  Release Artefact: oecore-51259c7e933a2ac8ebc01604d6e65607b76b7b56
+-  sha: 2cd531e2a107849e7a452e71e41f22b42160979066e10d0661e97acfab125b1f
+-  Download Locations:
+
+   https://downloads.yoctoproject.org/releases/yocto/yocto-4.0.35/oecore-51259c7e933a2ac8ebc01604d6e65607b76b7b56.tar.bz2
+
+   https://mirrors.edge.kernel.org/yocto/yocto/yocto-4.0.35/oecore-51259c7e933a2ac8ebc01604d6e65607b76b7b56.tar.bz2
+
+meta-yocto
+
+-  Repository Location: :yocto_git:`/meta-yocto`
+-  Branch: :yocto_git:`kirkstone </meta-yocto/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.35 </meta-yocto/log/?h=yocto-4.0.35>`
+-  Git Revision: :yocto_git:`34e3c9a19b8b955116109a2e9528966db3fced37 </meta-yocto/commit/?id=34e3c9a19b8b955116109a2e9528966db3fced37>`
+-  Release Artefact: meta-yocto-34e3c9a19b8b955116109a2e9528966db3fced37
+-  sha: 18da6dbb745d5e4e42a93527c36751778155e3762728b0b1020b890480402dde
+-  Download Locations:
+
+   https://downloads.yoctoproject.org/releases/yocto/yocto-4.0.35/meta-yocto-34e3c9a19b8b955116109a2e9528966db3fced37.tar.bz2
+
+   https://mirrors.edge.kernel.org/yocto/yocto/yocto-4.0.35/meta-yocto-34e3c9a19b8b955116109a2e9528966db3fced37.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.35 </meta-mingw/log/?h=yocto-4.0.35>`
+-  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.35/meta-mingw-87c22abb1f11be430caf4372e6b833dc7d77564e.tar.bz2
+
+   https://mirrors.edge.kernel.org/yocto/yocto/yocto-4.0.35/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.35 </meta-gplv2/log/?h=yocto-4.0.35>`
+-  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.35/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2
+
+   https://mirrors.edge.kernel.org/yocto/yocto/yocto-4.0.35/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.35 </bitbake/log/?h=yocto-4.0.35>`
+-  Git Revision: :oe_git:`7fd0197fd5fedd23cc885b5e7e816d86a392fdf9 </bitbake/commit/?id=7fd0197fd5fedd23cc885b5e7e816d86a392fdf9>`
+-  Release Artefact: bitbake-7fd0197fd5fedd23cc885b5e7e816d86a392fdf9
+-  sha: 6c01ff2b4b0060ef3d6d3f1fc11690094b22865af4989946544d08d74b473ec9
+-  Download Locations:
+
+   https://downloads.yoctoproject.org/releases/yocto/yocto-4.0.35/bitbake-7fd0197fd5fedd23cc885b5e7e816d86a392fdf9.tar.bz2
+
+   https://mirrors.edge.kernel.org/yocto/yocto/yocto-4.0.35/bitbake-7fd0197fd5fedd23cc885b5e7e816d86a392fdf9.tar.bz2
+

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

@@ -73,7 +73,7 @@ New Features / Enhancements in 4.3
      for the latest long-term release (6.1).
 
    - The list of fixed kernel CVEs is updated regularly using data from
-     `linuxkernelcves.com <https://linuxkernelcves.com>`__.
+     `linuxkernelcves.com <https://web.archive.org/web/20240420122324/https://www.linuxkernelcves.com/>`__.
 
    - A ``showconfig`` task was added to the :ref:`ref-classes-cml1` class, to
      easily examine the final generated ``.config`` file.

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

@@ -0,0 +1,263 @@
+Release notes for Yocto-5.0.17 (Scarthgap)
+------------------------------------------
+
+Openssl 3.2 has reached EOL. Some projects would like to use LTS version due to criticality and exposure of this component, so upgrade to 3.5 branch.
+
+Security Fixes in Yocto-5.0.17
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  alsa-lib: Fix :cve_nist:`2026-25068`
+-  avahi: Fix :cve_nist:`2025-68276`, :cve_nist:`2025-68468`, :cve_nist:`2025-68471` and
+   :cve_nist:`2026-24401`
+-  bind: Fix :cve_nist:`2025-13878`
+-  busybox: Fix :cve_nist:`2025-60876`
+-  ffmpeg: ignore :cve_nist:`2025-1594`, :cve_nist:`2025-10256`, :cve_nist:`2025-12343` and
+   :cve_nist:`2025-25468`
+-  freetype: Fix :cve_nist:`2026-23865`
+-  gdk-pixbuf: Fix :cve_nist:`2025-6199`
+-  glib-2.0: Fix :cve_nist:`2026-1484`, :cve_nist:`2026-1485` and :cve_nist:`2026-1489`
+-  gnupg: Fix :cve_nist:`2025-68973`
+-  gnutls: Fix :cve_nist:`2025-14831`
+-  go 1.22.12: Fix :cve_nist:`2025-61726`, :cve_nist:`2025-61728`, :cve_nist:`2025-61730`,
+   :cve_nist:`2025-61731`, :cve_nist:`2025-61732`, :cve_nist:`2025-68119` and :cve_nist:`2025-68121`
+-  harfbuzz: Fix :cve_nist:`2026-22693`
+-  inetutils: Fix :cve_nist:`2026-28372` and :cve_nist:`2026-32746`
+-  libpng: Fix :cve_nist:`2026-25646`
+-  libsndfile1: Fix :cve_nist:`2025-56226`
+-  libtheora: Ignore :cve_nist:`2024-56431`
+-  linux-yocto/6.6: Fix :cve_nist:`2025-38593`, :cve_nist:`2025-38643`, :cve_nist:`2025-38678`,
+   :cve_nist:`2025-40039`, :cve_nist:`2025-40040`, :cve_nist:`2025-40149`, :cve_nist:`2025-40164`,
+   :cve_nist:`2025-40251`, :cve_nist:`2025-68211`, :cve_nist:`2025-68214`, :cve_nist:`2025-68223`,
+   :cve_nist:`2025-68340`, :cve_nist:`2025-68365`, :cve_nist:`2025-68725`, :cve_nist:`2025-68817`,
+   :cve_nist:`2025-71068`, :cve_nist:`2025-71071`, :cve_nist:`2025-71075`, :cve_nist:`2025-71077`,
+   :cve_nist:`2025-71078`, :cve_nist:`2025-71079`, :cve_nist:`2025-71081`, :cve_nist:`2025-71082`,
+   :cve_nist:`2025-71083`, :cve_nist:`2025-71084`, :cve_nist:`2025-71085`, :cve_nist:`2025-71086`,
+   :cve_nist:`2025-71087`, :cve_nist:`2025-71088`, :cve_nist:`2025-71089`, :cve_nist:`2025-71091`,
+   :cve_nist:`2025-71093`, :cve_nist:`2025-71094`, :cve_nist:`2025-71095`, :cve_nist:`2025-71096`,
+   :cve_nist:`2025-71097`, :cve_nist:`2025-71098`, :cve_nist:`2025-71101`, :cve_nist:`2025-71102`,
+   :cve_nist:`2025-71104`, :cve_nist:`2025-71105`, :cve_nist:`2025-71107`, :cve_nist:`2025-71108`,
+   :cve_nist:`2025-71111`, :cve_nist:`2025-71112`, :cve_nist:`2025-71113`, :cve_nist:`2025-71114`,
+   :cve_nist:`2025-71116`, :cve_nist:`2025-71118`, :cve_nist:`2025-71119`, :cve_nist:`2025-71120`,
+   :cve_nist:`2025-71121`, :cve_nist:`2025-71122`, :cve_nist:`2025-71125`, :cve_nist:`2025-71126`,
+   :cve_nist:`2025-71127`, :cve_nist:`2025-71129`, :cve_nist:`2025-71130`, :cve_nist:`2025-71131`,
+   :cve_nist:`2025-71132`, :cve_nist:`2025-71133`, :cve_nist:`2025-71136`, :cve_nist:`2025-71137`,
+   :cve_nist:`2025-71138`, :cve_nist:`2025-71141`, :cve_nist:`2025-71143`, :cve_nist:`2025-71147`,
+   :cve_nist:`2025-71148`, :cve_nist:`2025-71149`, :cve_nist:`2025-71150`, :cve_nist:`2025-71151`,
+   :cve_nist:`2025-71153`, :cve_nist:`2025-71154`, :cve_nist:`2025-71160`, :cve_nist:`2025-71162`,
+   :cve_nist:`2025-71163`, :cve_nist:`2025-71180`, :cve_nist:`2025-71182`, :cve_nist:`2025-71183`,
+   :cve_nist:`2025-71185`, :cve_nist:`2025-71186`, :cve_nist:`2025-71188`, :cve_nist:`2025-71189`,
+   :cve_nist:`2025-71190`, :cve_nist:`2025-71191`, :cve_nist:`2025-71200`, :cve_nist:`2026-22976`,
+   :cve_nist:`2026-22977`, :cve_nist:`2026-22978`, :cve_nist:`2026-22979`, :cve_nist:`2026-22980`,
+   :cve_nist:`2026-22982`, :cve_nist:`2026-22984`, :cve_nist:`2026-22990`, :cve_nist:`2026-22991`,
+   :cve_nist:`2026-22992`, :cve_nist:`2026-22994`, :cve_nist:`2026-22997`, :cve_nist:`2026-22998`,
+   :cve_nist:`2026-22999`, :cve_nist:`2026-23001`, :cve_nist:`2026-23003`, :cve_nist:`2026-23005`,
+   :cve_nist:`2026-23006`, :cve_nist:`2026-23010`, :cve_nist:`2026-23011`, :cve_nist:`2026-23019`,
+   :cve_nist:`2026-23020`, :cve_nist:`2026-23021`, :cve_nist:`2026-23025`, :cve_nist:`2026-23026`,
+   :cve_nist:`2026-23060`, :cve_nist:`2026-23061`, :cve_nist:`2026-23062`, :cve_nist:`2026-23063`,
+   :cve_nist:`2026-23064`, :cve_nist:`2026-23068`, :cve_nist:`2026-23069`, :cve_nist:`2026-23071`,
+   :cve_nist:`2026-23073`, :cve_nist:`2026-23074`, :cve_nist:`2026-23075`, :cve_nist:`2026-23076`,
+   :cve_nist:`2026-23078`, :cve_nist:`2026-23080`, :cve_nist:`2026-23083`, :cve_nist:`2026-23084`,
+   :cve_nist:`2026-23085`, :cve_nist:`2026-23086`, :cve_nist:`2026-23087`, :cve_nist:`2026-23088`,
+   :cve_nist:`2026-23089`, :cve_nist:`2026-23090`, :cve_nist:`2026-23091`, :cve_nist:`2026-23093`,
+   :cve_nist:`2026-23094`, :cve_nist:`2026-23095`, :cve_nist:`2026-23096`, :cve_nist:`2026-23097`,
+   :cve_nist:`2026-23098`, :cve_nist:`2026-23099`, :cve_nist:`2026-23101`, :cve_nist:`2026-23102`,
+   :cve_nist:`2026-23103`, :cve_nist:`2026-23105`, :cve_nist:`2026-23107`, :cve_nist:`2026-23108`,
+   :cve_nist:`2026-23110`, :cve_nist:`2026-23113`, :cve_nist:`2026-23116`, :cve_nist:`2026-23119`,
+   :cve_nist:`2026-23120`, :cve_nist:`2026-23121`, :cve_nist:`2026-23123`, :cve_nist:`2026-23124`,
+   :cve_nist:`2026-23125`, :cve_nist:`2026-23126`, :cve_nist:`2026-23128`, :cve_nist:`2026-23131`,
+   :cve_nist:`2026-23133`, :cve_nist:`2026-23135`, :cve_nist:`2026-23136`, :cve_nist:`2026-23139`,
+   :cve_nist:`2026-23140`, :cve_nist:`2026-23141`, :cve_nist:`2026-23142`, :cve_nist:`2026-23144`,
+   :cve_nist:`2026-23146`, :cve_nist:`2026-23150`, :cve_nist:`2026-23156`, :cve_nist:`2026-23160`,
+   :cve_nist:`2026-23163`, :cve_nist:`2026-23164`, :cve_nist:`2026-23167`, :cve_nist:`2026-23168`,
+   :cve_nist:`2026-23170`, :cve_nist:`2026-23172`, :cve_nist:`2026-23173` and :cve_nist:`2026-23212`
+-  openssl: fix :cve_nist:`2025-15468` and :cve_nist:`2025-69419`
+-  python3-cryptography: Fix :cve_nist:`2026-26007`
+-  python3-pip: Fix :cve_nist:`2026-1703`
+-  python3-pyopenssl: Fix :cve_nist:`2026-27448` and :cve_nist:`2026-27459`
+-  tiff: ignore :cve_nist:`2025-61144` and :cve_nist:`2025-61145`
+-  vim: ignore :cve_nist:`2025-66476`
+-  zlib: Fix :cve_nist:`2026-27171`
+
+
+Fixes in Yocto-5.0.17
+~~~~~~~~~~~~~~~~~~~~~
+
+-  README: Add scarthgap subject-prefix to git-send-email suggestion
+-  bind: upgrade to 9.18.44
+-  bitbake: COW: Fix hardcoded magic numbers and work with python 3.13
+-  bitbake: fetch2: Fix LFS object checkout in submodules
+-  bitbake: fetch2: Fix incorrect lfs parametrization for submodules
+-  bitbake: fetch2: don't try to preserve all attributes when unpacking files
+-  bitbake: gitsm: Add clean function
+-  build-appliance-image: Update to scarthgap head revision
+-  classes/buildhistory: Do not sign buildhistory commits
+-  create-pull-request: Keep commit hash to be pulled in cover email
+-  dev-manual: delete references to "tar" package format
+-  docs: Makefile: pass -silent to latexmk
+-  go-vendor: Fix absolute paths issue
+-  improve_kernel_cve_report: add option to read debugsources.zstd
+-  improve_kernel_cve_report: do not override backported-patch
+-  improve_kernel_cve_report: do not use custom version
+-  linux-yocto/6.6: upgrade to v6.6.123
+-  lsb.py: strip ' from os-release file
+-  migration-guides: add release notes for 5.0.16
+-  mobile-broadband-provider-info: upgrade to 20251101
+-  oe-setup-build: Fix typo
+-  oeqa/selftest/wic: test recursive dir copy on ext partitions
+-  openssl: upgrade to 3.5.5
+-  overview-manual/concepts: list other possible class directories
+-  overview-manual: escape wildcard in inline markup
+-  poky.conf: Bump version for 5.0.17 release
+-  poky.conf: add Centos Stream 9, fedora-41, rocky-8 to :term:`SANITY_TESTED_DISTROS`
+-  pseudo: Update to include a fix for systems with kernel <5.6
+-  python3-pip: drop unused Windows distlib launcher templates
+-  python3-setuptools: drop Windows launcher executables on non-mingw builds
+-  ref-manual/classes.rst: fix broken links to U-Boot documentation
+-  ref-manual/system-requirements.rst: update supported, end-of-life and untested distros
+-  scripts/install-buildtools: Update to 5.0.15
+-  spdx30_tasks: Exclude 'doc' when exporting :term:`PACKAGECONFIG` to :term:`SPDX`
+-  spdx: add option to include only compiled sources
+-  systemd-systemctl: Fix instance name parsing with escapes or periods
+-  tzdata,tzcode-native: upgrade to 2025c
+-  u-boot: move CVE Fixes out of the common .inc file
+-  uboot-config: Fix devtool modify
+-  weston: fix a touch-calibrator issue
+-  what-i-wish-id-known.rst: replace figure by the new SVG
+-  wic/engine: error on old host debugfs for standalone directory copy
+-  wic/engine: fix copying directories into wic image with ext* partition
+-  wireless-regdb: upgrade to 2026.02.04
+
+
+Known Issues in Yocto-5.0.17
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+- N/A
+
+Contributors to Yocto-5.0.17
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  Aleksandar Nikolic
+-  Amaury Couderc
+-  Ankur Tyagi
+-  Antonin Godard
+-  Benjamin Robin (Schneider Electric)
+-  Bruce Ashfield
+-  Daniel Dragomir
+-  Daniel Turull
+-  Deepak Rathore
+-  Dragomir, Daniel
+-  Eduardo Ferreira
+-  Fabio Berton
+-  Hitendra Prajapati
+-  Hugo SIMELIERE
+-  João Marcos Costa (Schneider Electric)
+-  Kristiyan Chakarov
+-  Krupal Ka Patel
+-  Lee Chee Yang
+-  Livin Sunny
+-  Martin Jansa
+-  Michael Opdenacker
+-  Ming Liu
+-  Nguyen Dat Tho
+-  Paul Barker
+-  Peter Marko
+-  Philip Lorenz
+-  Quentin Schulz
+-  Richard Purdie
+-  Robert P. J. Day
+-  Robert Yang
+-  Ross Burton
+-  Ryan Eatmon
+-  Shaik Moin
+-  Tom Hochstein
+-  Trent Piepho
+-  Vijay Anusuri
+-  Yoann Congal
+
+Repositories / Downloads for Yocto-5.0.17
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+yocto-docs
+
+-  Repository Location: :yocto_git:`/yocto-docs`
+-  Branch: :yocto_git:`scarthgap </yocto-docs/log/?h=scarthgap>`
+-  Tag:  :yocto_git:`yocto-5.0.17 </yocto-docs/log/?h=yocto-5.0.17>`
+-  Git Revision: :yocto_git:`aa7226705451e6c1ef964d49963bbed29b267c27 </yocto-docs/commit/?id=aa7226705451e6c1ef964d49963bbed29b267c27>`
+-  Release Artefact: yocto-docs-aa7226705451e6c1ef964d49963bbed29b267c27
+-  sha: d429833609637657f213611317dfadbd70293fff2f9e22753d1f71ef8515a6c0
+-  Download Locations:
+
+   https://downloads.yoctoproject.org/releases/yocto/yocto-5.0.17/yocto-docs-aa7226705451e6c1ef964d49963bbed29b267c27.tar.bz2
+
+   https://mirrors.edge.kernel.org/yocto/yocto/yocto-5.0.17/yocto-docs-aa7226705451e6c1ef964d49963bbed29b267c27.tar.bz2
+
+poky
+
+-  Repository Location: :yocto_git:`/poky`
+-  Branch: :yocto_git:`scarthgap </poky/log/?h=scarthgap>`
+-  Tag:  :yocto_git:`yocto-5.0.17 </poky/log/?h=yocto-5.0.17>`
+-  Git Revision: :yocto_git:`1e8099846661571ede077f533eb1b6c86818ddce </poky/commit/?id=1e8099846661571ede077f533eb1b6c86818ddce>`
+-  Release Artefact: poky-1e8099846661571ede077f533eb1b6c86818ddce
+-  sha: b56890576f593cc881ea8e467562d842cfca248099ce653d28ca14d250f6219e
+-  Download Locations:
+
+   https://downloads.yoctoproject.org/releases/yocto/yocto-5.0.17/poky-1e8099846661571ede077f533eb1b6c86818ddce.tar.bz2
+
+   https://mirrors.edge.kernel.org/yocto/yocto/yocto-5.0.17/poky-1e8099846661571ede077f533eb1b6c86818ddce.tar.bz2
+
+openembedded-core
+
+-  Repository Location: :oe_git:`/openembedded-core`
+-  Branch: :oe_git:`scarthgap </openembedded-core/log/?h=scarthgap>`
+-  Tag:  :oe_git:`yocto-5.0.17 </openembedded-core/log/?h=yocto-5.0.17>`
+-  Git Revision: :oe_git:`52380df998b3a8fe6a091f8547434a3231320a8e </openembedded-core/commit/?id=52380df998b3a8fe6a091f8547434a3231320a8e>`
+-  Release Artefact: oecore-52380df998b3a8fe6a091f8547434a3231320a8e
+-  sha: a948d75acf76a392d170129ce6eb6f5fe45082d95b4fd28045aac58b8373cb26
+-  Download Locations:
+
+   https://downloads.yoctoproject.org/releases/yocto/yocto-5.0.17/oecore-52380df998b3a8fe6a091f8547434a3231320a8e.tar.bz
+
+   https://mirrors.edge.kernel.org/yocto/yocto/yocto-5.0.17/oecore-52380df998b3a8fe6a091f8547434a3231320a8e.tar.bz2
+
+meta-yocto
+
+-  Repository Location: :yocto_git:`/meta-yocto`
+-  Branch: :yocto_git:`scarthgap </meta-yocto/log/?h=scarthgap>`
+-  Tag:  :yocto_git:`yocto-5.0.17 </meta-yocto/log/?h=yocto-5.0.17>`
+-  Git Revision: :yocto_git:`c7c38663a1cafb1fa8593c0b246811e51d3bbe20 </meta-yocto/commit/?id=c7c38663a1cafb1fa8593c0b246811e51d3bbe20>`
+-  Release Artefact: meta-yocto-c7c38663a1cafb1fa8593c0b246811e51d3bbe20
+-  sha: 5a2a9360249e639694cc2a75985e3907085512b3eb236e8491cb07f1e0cb0f19
+-  Download Locations:
+
+   https://downloads.yoctoproject.org/releases/yocto/yocto-5.0.17/meta-yocto-c7c38663a1cafb1fa8593c0b246811e51d3bbe20.tar.bz2
+
+   https://mirrors.edge.kernel.org/yocto/yocto/yocto-5.0.17/meta-yocto-c7c38663a1cafb1fa8593c0b246811e51d3bbe20.tar.bz2
+
+meta-mingw
+
+-  Repository Location: :yocto_git:`/meta-mingw`
+-  Branch: :yocto_git:`scarthgap </meta-mingw/log/?h=scarthgap>`
+-  Tag:  :yocto_git:`yocto-5.0.17 </meta-mingw/log/?h=yocto-5.0.17>`
+-  Git Revision: :yocto_git:`bd9fef71ec005be3c3a6d7f8b99d8116daf70c4f </meta-mingw/commit/?id=bd9fef71ec005be3c3a6d7f8b99d8116daf70c4f>`
+-  Release Artefact: meta-mingw-bd9fef71ec005be3c3a6d7f8b99d8116daf70c4f
+-  sha: ab073def6487f237ac125d239b3739bf02415270959546b6b287778664f0ae65
+-  Download Locations:
+
+   https://downloads.yoctoproject.org/releases/yocto/yocto-5.0.17/meta-mingw-bd9fef71ec005be3c3a6d7f8b99d8116daf70c4f.tar.bz2
+
+   https://mirrors.edge.kernel.org/yocto/yocto/yocto-5.0.17/meta-mingw-bd9fef71ec005be3c3a6d7f8b99d8116daf70c4f.tar.bz2
+
+bitbake
+
+-  Repository Location: :oe_git:`/bitbake`
+-  Branch: :oe_git:`2.8 </bitbake/log/?h=2.8>`
+-  Tag:  :oe_git:`yocto-5.0.17 </bitbake/log/?h=yocto-5.0.17>`
+-  Git Revision: :oe_git:`d3b4c352dd33fca90cd31649eda054b884478739 </bitbake/commit/?id=d3b4c352dd33fca90cd31649eda054b884478739>`
+-  Release Artefact: bitbake-d3b4c352dd33fca90cd31649eda054b884478739
+-  sha: 1021fc412780e21b25ccb045b66368ebe3fc4e785a65066ac0cafb9bdd5492fa
+-  Download Locations:
+
+   https://downloads.yoctoproject.org/releases/yocto/yocto-5.0.17/bitbake-d3b4c352dd33fca90cd31649eda054b884478739.tar.bz2
+
+   https://mirrors.edge.kernel.org/yocto/yocto/yocto-5.0.17/bitbake-d3b4c352dd33fca90cd31649eda054b884478739.tar.bz2
+

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

@@ -0,0 +1,663 @@
+Release notes for Yocto-5.0.19 (Scarthgap)
+------------------------------------------
+
+gawk-native is now built from source instead of used from the host when
+building grub2 & glibc to avoid reproducibility issues on newer host
+distros.
+
+Security Fixes in Yocto-5.0.19
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  avahi: Remove a reference to the rejected :cve_nist:`2021-36217`
+-  binutils: Fix :cve_nist:`2025-69644`
+-  busybox: Fix :cve_nist:`2026-29004`
+-  dpkg: Fix :cve_nist:`2026-2219`
+-  go: Fix :cve_nist:`2025-58183`, :cve_mitre:`2026-25679`, :cve_nist:`2026-27140`,
+   :cve_nist:`2026-27142`, :cve_nist:`2026-27143`, :cve_nist:`2026-27144`, :cve_nist:`2026-27145`,
+   :cve_nist:`2026-32280`, :cve_nist:`2026-32283`, :cve_nist:`2026-32288`, :cve_nist:`2026-32289`,
+   :cve_nist:`2026-33811`, :cve_nist:`2026-39817`, :cve_nist:`2026-39819`, :cve_nist:`2026-39820`,
+   :cve_nist:`2026-39825`, :cve_nist:`2026-39826`, :cve_nist:`2026-42499`, :cve_nist:`2026-42501`,
+   :cve_nist:`2026-42504` and :cve_nist:`2026-42507`
+-  go: Ignore :cve_nist:`2026-39836`
+-  libarchive: Fix :cve_nist:`2026-4424`
+-  libexif: Fix :cve_nist:`2026-32775`, :cve_nist:`2026-40385` and :cve_nist:`2026-40386`
+-  libinput: Fix :cve_nist:`2026-50292`
+-  libpng: Fix :cve_nist:`2026-33416`
+-  libsolv: Fix :cve_nist:`2026-9150`
+-  libsoup: Fix :cve_nist:`2025-11021` and :cve_nist:`2026-2369`
+-  libssh2: Fix :cve_nist:`2026-7598`
+-  libusb1: Fix :cve_nist:`2026-23679` and :cve_nist:`2026-47104`
+-  libxml-parser-perl: Fix :cve_nist:`2006-10003`
+-  linux-yocto/6.6: Fix :cve_nist:`2023-52920`, :cve_nist:`2024-14027`, :cve_nist:`2024-27022`,
+   :cve_nist:`2024-56647`, :cve_nist:`2025-21739`, :cve_nist:`2025-22125`, :cve_nist:`2025-38531`,
+   :cve_nist:`2025-38584`, :cve_nist:`2025-38710`, :cve_nist:`2025-39981`, :cve_nist:`2025-40219`,
+   :cve_nist:`2025-68315`, :cve_nist:`2025-71184`, :cve_nist:`2025-71239`, :cve_nist:`2025-71265`,
+   :cve_nist:`2025-71266`, :cve_nist:`2025-71267`, :cve_nist:`2025-71269`, :cve_nist:`2025-71274`,
+   :cve_nist:`2025-71286`, :cve_nist:`2025-71287`, :cve_nist:`2025-71288`, :cve_nist:`2025-71291`,
+   :cve_nist:`2025-71292`, :cve_nist:`2025-71295`, :cve_nist:`2025-71297`, :cve_nist:`2025-71304`,
+   :cve_nist:`2025-71305`, :cve_nist:`2026-23004`, :cve_nist:`2026-23171`, :cve_nist:`2026-23231`,
+   :cve_nist:`2026-23242`, :cve_nist:`2026-23243`, :cve_nist:`2026-23244`, :cve_nist:`2026-23245`,
+   :cve_nist:`2026-23246`, :cve_nist:`2026-23253`, :cve_nist:`2026-23255`, :cve_nist:`2026-23268`,
+   :cve_nist:`2026-23269`, :cve_nist:`2026-23270`, :cve_nist:`2026-23271`, :cve_nist:`2026-23272`,
+   :cve_nist:`2026-23273`, :cve_nist:`2026-23274`, :cve_nist:`2026-23277`, :cve_nist:`2026-23279`,
+   :cve_nist:`2026-23281`, :cve_nist:`2026-23284`, :cve_nist:`2026-23285`, :cve_nist:`2026-23286`,
+   :cve_nist:`2026-23287`, :cve_nist:`2026-23289`, :cve_nist:`2026-23290`, :cve_nist:`2026-23291`,
+   :cve_nist:`2026-23292`, :cve_nist:`2026-23293`, :cve_nist:`2026-23296`, :cve_nist:`2026-23298`,
+   :cve_nist:`2026-23300`, :cve_nist:`2026-23302`, :cve_nist:`2026-23303`, :cve_nist:`2026-23304`,
+   :cve_nist:`2026-23306`, :cve_nist:`2026-23307`, :cve_nist:`2026-23308`, :cve_nist:`2026-23310`,
+   :cve_nist:`2026-23312`, :cve_nist:`2026-23313`, :cve_nist:`2026-23315`, :cve_nist:`2026-23317`,
+   :cve_nist:`2026-23318`, :cve_nist:`2026-23319`, :cve_nist:`2026-23321`, :cve_nist:`2026-23324`,
+   :cve_nist:`2026-23325`, :cve_nist:`2026-23330`, :cve_nist:`2026-23334`, :cve_nist:`2026-23335`,
+   :cve_nist:`2026-23336`, :cve_nist:`2026-23339`, :cve_nist:`2026-23340`, :cve_nist:`2026-23343`,
+   :cve_nist:`2026-23347`, :cve_nist:`2026-23351`, :cve_nist:`2026-23352`, :cve_nist:`2026-23356`,
+   :cve_nist:`2026-23357`, :cve_nist:`2026-23359`, :cve_nist:`2026-23360`, :cve_nist:`2026-23362`,
+   :cve_nist:`2026-23364`, :cve_nist:`2026-23365`, :cve_nist:`2026-23367`, :cve_nist:`2026-23368`,
+   :cve_nist:`2026-23370`, :cve_nist:`2026-23372`, :cve_nist:`2026-23374`, :cve_nist:`2026-23378`,
+   :cve_nist:`2026-23379`, :cve_nist:`2026-23381`, :cve_nist:`2026-23382`, :cve_nist:`2026-23386`,
+   :cve_nist:`2026-23387`, :cve_nist:`2026-23388`, :cve_nist:`2026-23389`, :cve_nist:`2026-23391`,
+   :cve_nist:`2026-23392`, :cve_nist:`2026-23395`, :cve_nist:`2026-23396`, :cve_nist:`2026-23397`,
+   :cve_nist:`2026-23398`, :cve_nist:`2026-23399`, :cve_nist:`2026-23401`, :cve_nist:`2026-23403`,
+   :cve_nist:`2026-23404`, :cve_nist:`2026-23405`, :cve_nist:`2026-23406`, :cve_nist:`2026-23407`,
+   :cve_nist:`2026-23408`, :cve_nist:`2026-23409`, :cve_nist:`2026-23410`, :cve_nist:`2026-23411`,
+   :cve_nist:`2026-23412`, :cve_nist:`2026-23413`, :cve_nist:`2026-23414`, :cve_nist:`2026-23419`,
+   :cve_nist:`2026-23420`, :cve_nist:`2026-23422`, :cve_nist:`2026-23426`, :cve_nist:`2026-23427`,
+   :cve_nist:`2026-23428`, :cve_nist:`2026-23434`, :cve_nist:`2026-23438`, :cve_nist:`2026-23439`,
+   :cve_nist:`2026-23440`, :cve_nist:`2026-23441`, :cve_nist:`2026-23442`, :cve_nist:`2026-23443`,
+   :cve_nist:`2026-23444`, :cve_nist:`2026-23446`, :cve_nist:`2026-23447`, :cve_nist:`2026-23448`,
+   :cve_nist:`2026-23449`, :cve_nist:`2026-23450`, :cve_nist:`2026-23452`, :cve_nist:`2026-23454`,
+   :cve_nist:`2026-23455`, :cve_nist:`2026-23456`, :cve_nist:`2026-23457`, :cve_nist:`2026-23458`,
+   :cve_nist:`2026-23460`, :cve_nist:`2026-23461`, :cve_nist:`2026-23462`, :cve_nist:`2026-23463`,
+   :cve_nist:`2026-23465`, :cve_nist:`2026-23468`, :cve_nist:`2026-23474`, :cve_nist:`2026-23475`,
+   :cve_nist:`2026-31389`, :cve_nist:`2026-31391`, :cve_nist:`2026-31392`, :cve_nist:`2026-31393`,
+   :cve_nist:`2026-31396`, :cve_nist:`2026-31399`, :cve_nist:`2026-31400`, :cve_nist:`2026-31402`,
+   :cve_nist:`2026-31403`, :cve_nist:`2026-31405`, :cve_nist:`2026-31407`, :cve_nist:`2026-31408`,
+   :cve_nist:`2026-31409`, :cve_nist:`2026-31411`, :cve_nist:`2026-31412`, :cve_nist:`2026-31414`,
+   :cve_nist:`2026-31415`, :cve_nist:`2026-31416`, :cve_nist:`2026-31417`, :cve_nist:`2026-31418`,
+   :cve_nist:`2026-31421`, :cve_nist:`2026-31422`, :cve_nist:`2026-31423`, :cve_nist:`2026-31424`,
+   :cve_nist:`2026-31425`, :cve_nist:`2026-31426`, :cve_nist:`2026-31427`, :cve_nist:`2026-31428`,
+   :cve_nist:`2026-31429`, :cve_nist:`2026-31430`, :cve_nist:`2026-31431`, :cve_nist:`2026-31433`,
+   :cve_nist:`2026-31434`, :cve_nist:`2026-31439`, :cve_nist:`2026-31440`, :cve_nist:`2026-31441`,
+   :cve_nist:`2026-31446`, :cve_nist:`2026-31447`, :cve_nist:`2026-31448`, :cve_nist:`2026-31449`,
+   :cve_nist:`2026-31450`, :cve_nist:`2026-31451`, :cve_nist:`2026-31452`, :cve_nist:`2026-31453`,
+   :cve_nist:`2026-31454`, :cve_nist:`2026-31455`, :cve_nist:`2026-31458`, :cve_nist:`2026-31464`,
+   :cve_nist:`2026-31466`, :cve_nist:`2026-31467`, :cve_nist:`2026-31469`, :cve_nist:`2026-31473`,
+   :cve_nist:`2026-31474`, :cve_nist:`2026-31476`, :cve_nist:`2026-31477`, :cve_nist:`2026-31478`,
+   :cve_nist:`2026-31480`, :cve_nist:`2026-31482`, :cve_nist:`2026-31483`, :cve_nist:`2026-31485`,
+   :cve_nist:`2026-31488`, :cve_nist:`2026-31489`, :cve_nist:`2026-31492`, :cve_nist:`2026-31494`,
+   :cve_nist:`2026-31495`, :cve_nist:`2026-31496`, :cve_nist:`2026-31497`, :cve_nist:`2026-31498`,
+   :cve_nist:`2026-31500`, :cve_nist:`2026-31503`, :cve_nist:`2026-31504`, :cve_nist:`2026-31507`,
+   :cve_nist:`2026-31508`, :cve_nist:`2026-31509`, :cve_nist:`2026-31510`, :cve_nist:`2026-31512`,
+   :cve_nist:`2026-31515`, :cve_nist:`2026-31518`, :cve_nist:`2026-31519`, :cve_nist:`2026-31520`,
+   :cve_nist:`2026-31521`, :cve_nist:`2026-31522`, :cve_nist:`2026-31523`, :cve_nist:`2026-31524`,
+   :cve_nist:`2026-31525`, :cve_nist:`2026-31528`, :cve_nist:`2026-31532`, :cve_nist:`2026-31533`,
+   :cve_nist:`2026-31540`, :cve_nist:`2026-31542`, :cve_nist:`2026-31545`, :cve_nist:`2026-31546`,
+   :cve_nist:`2026-31548`, :cve_nist:`2026-31549`, :cve_nist:`2026-31550`, :cve_nist:`2026-31551`,
+   :cve_nist:`2026-31552`, :cve_nist:`2026-31555`, :cve_nist:`2026-31563`, :cve_nist:`2026-31565`,
+   :cve_nist:`2026-31566`, :cve_nist:`2026-31570`, :cve_nist:`2026-31576`, :cve_nist:`2026-31577`,
+   :cve_nist:`2026-31578`, :cve_nist:`2026-31580`, :cve_nist:`2026-31581`, :cve_nist:`2026-31583`,
+   :cve_nist:`2026-31584`, :cve_nist:`2026-31585`, :cve_nist:`2026-31586`, :cve_nist:`2026-31587`,
+   :cve_nist:`2026-31588`, :cve_nist:`2026-31590`, :cve_nist:`2026-31594`, :cve_nist:`2026-31595`,
+   :cve_nist:`2026-31596`, :cve_nist:`2026-31597`, :cve_nist:`2026-31598`, :cve_nist:`2026-31599`,
+   :cve_nist:`2026-31602`, :cve_nist:`2026-31603`, :cve_nist:`2026-31604`, :cve_nist:`2026-31605`,
+   :cve_nist:`2026-31607`, :cve_nist:`2026-31610`, :cve_nist:`2026-31611`, :cve_nist:`2026-31612`,
+   :cve_nist:`2026-31613`, :cve_nist:`2026-31614`, :cve_nist:`2026-31615`, :cve_nist:`2026-31616`,
+   :cve_nist:`2026-31617`, :cve_nist:`2026-31618`, :cve_nist:`2026-31619`, :cve_nist:`2026-31622`,
+   :cve_nist:`2026-31623`, :cve_nist:`2026-31624`, :cve_nist:`2026-31625`, :cve_nist:`2026-31626`,
+   :cve_nist:`2026-31627`, :cve_nist:`2026-31628`, :cve_nist:`2026-31629`, :cve_nist:`2026-31634`,
+   :cve_nist:`2026-31637`, :cve_nist:`2026-31638`, :cve_nist:`2026-31639`, :cve_nist:`2026-31642`,
+   :cve_nist:`2026-31646`, :cve_nist:`2026-31648`, :cve_nist:`2026-31649`, :cve_nist:`2026-31651`,
+   :cve_nist:`2026-31655`, :cve_nist:`2026-31656`, :cve_nist:`2026-31657`, :cve_nist:`2026-31658`,
+   :cve_nist:`2026-31659`, :cve_nist:`2026-31660`, :cve_nist:`2026-31661`, :cve_nist:`2026-31662`,
+   :cve_nist:`2026-31664`, :cve_nist:`2026-31665`, :cve_nist:`2026-31667`, :cve_nist:`2026-31668`,
+   :cve_nist:`2026-31669`, :cve_nist:`2026-31670`, :cve_nist:`2026-31671`, :cve_nist:`2026-31672`,
+   :cve_nist:`2026-31673`, :cve_nist:`2026-31674`, :cve_nist:`2026-31675`, :cve_nist:`2026-31676`,
+   :cve_nist:`2026-31678`, :cve_nist:`2026-31679`, :cve_nist:`2026-31680`, :cve_nist:`2026-31681`,
+   :cve_nist:`2026-31682`, :cve_nist:`2026-31683`, :cve_nist:`2026-31684`, :cve_nist:`2026-31685`,
+   :cve_nist:`2026-31686`, :cve_nist:`2026-31689`, :cve_nist:`2026-31693`, :cve_nist:`2026-31694`,
+   :cve_nist:`2026-31695`, :cve_nist:`2026-31696`, :cve_nist:`2026-31697`, :cve_nist:`2026-31698`,
+   :cve_nist:`2026-31699`, :cve_nist:`2026-31700`, :cve_nist:`2026-31701`, :cve_nist:`2026-31702`,
+   :cve_nist:`2026-31704`, :cve_nist:`2026-31705`, :cve_nist:`2026-31707`, :cve_nist:`2026-31708`,
+   :cve_nist:`2026-31709`, :cve_nist:`2026-31711`, :cve_nist:`2026-31712`, :cve_nist:`2026-31714`,
+   :cve_nist:`2026-31715`, :cve_nist:`2026-31716`, :cve_nist:`2026-31718`, :cve_nist:`2026-31720`,
+   :cve_nist:`2026-31721`, :cve_nist:`2026-31726`, :cve_nist:`2026-31728`, :cve_nist:`2026-31730`,
+   :cve_nist:`2026-31737`, :cve_nist:`2026-31738`, :cve_nist:`2026-31740`, :cve_nist:`2026-31741`,
+   :cve_nist:`2026-31747`, :cve_nist:`2026-31748`, :cve_nist:`2026-31749`, :cve_nist:`2026-31751`,
+   :cve_nist:`2026-31752`, :cve_nist:`2026-31754`, :cve_nist:`2026-31755`, :cve_nist:`2026-31756`,
+   :cve_nist:`2026-31758`, :cve_nist:`2026-31759`, :cve_nist:`2026-31761`, :cve_nist:`2026-31762`,
+   :cve_nist:`2026-31763`, :cve_nist:`2026-31768`, :cve_nist:`2026-31770`, :cve_nist:`2026-31773`,
+   :cve_nist:`2026-31778`, :cve_nist:`2026-31779`, :cve_nist:`2026-31780`, :cve_nist:`2026-31781`,
+   :cve_nist:`2026-31786`, :cve_nist:`2026-31787`, :cve_nist:`2026-31788`, :cve_nist:`2026-43007`,
+   :cve_nist:`2026-43011`, :cve_nist:`2026-43013`, :cve_nist:`2026-43014`, :cve_nist:`2026-43015`,
+   :cve_nist:`2026-43016`, :cve_nist:`2026-43017`, :cve_nist:`2026-43018`, :cve_nist:`2026-43020`,
+   :cve_nist:`2026-43023`, :cve_nist:`2026-43024`, :cve_nist:`2026-43025`, :cve_nist:`2026-43026`,
+   :cve_nist:`2026-43027`, :cve_nist:`2026-43028`, :cve_nist:`2026-43030`, :cve_nist:`2026-43032`,
+   :cve_nist:`2026-43033`, :cve_nist:`2026-43035`, :cve_nist:`2026-43037`, :cve_nist:`2026-43038`,
+   :cve_nist:`2026-43040`, :cve_nist:`2026-43041`, :cve_nist:`2026-43043`, :cve_nist:`2026-43044`,
+   :cve_nist:`2026-43046`, :cve_nist:`2026-43047`, :cve_nist:`2026-43050`, :cve_nist:`2026-43051`,
+   :cve_nist:`2026-43054`, :cve_nist:`2026-43056`, :cve_nist:`2026-43057`, :cve_nist:`2026-43058`,
+   :cve_nist:`2026-43060`, :cve_nist:`2026-43061`, :cve_nist:`2026-43062`, :cve_nist:`2026-43064`,
+   :cve_nist:`2026-43065`, :cve_nist:`2026-43066`, :cve_nist:`2026-43067`, :cve_nist:`2026-43068`,
+   :cve_nist:`2026-43069`, :cve_nist:`2026-43071`, :cve_nist:`2026-43072`, :cve_nist:`2026-43074`,
+   :cve_nist:`2026-43075`, :cve_nist:`2026-43076`, :cve_nist:`2026-43077`, :cve_nist:`2026-43078`,
+   :cve_nist:`2026-43079`, :cve_nist:`2026-43080`, :cve_nist:`2026-43081`, :cve_nist:`2026-43082`,
+   :cve_nist:`2026-43085`, :cve_nist:`2026-43086`, :cve_nist:`2026-43089`, :cve_nist:`2026-43091`,
+   :cve_nist:`2026-43092`, :cve_nist:`2026-43093`, :cve_nist:`2026-43094`, :cve_nist:`2026-43098`,
+   :cve_nist:`2026-43099`, :cve_nist:`2026-43103`, :cve_nist:`2026-43104`, :cve_nist:`2026-43105`,
+   :cve_nist:`2026-43109`, :cve_nist:`2026-43110`, :cve_nist:`2026-43111`, :cve_nist:`2026-43112`,
+   :cve_nist:`2026-43113`, :cve_nist:`2026-43114`, :cve_nist:`2026-43117`, :cve_nist:`2026-43120`,
+   :cve_nist:`2026-43123`, :cve_nist:`2026-43124`, :cve_nist:`2026-43128`, :cve_nist:`2026-43130`,
+   :cve_nist:`2026-43132`, :cve_nist:`2026-43133`, :cve_nist:`2026-43134`, :cve_nist:`2026-43135`,
+   :cve_nist:`2026-43136`, :cve_nist:`2026-43137`, :cve_nist:`2026-43139`, :cve_nist:`2026-43140`,
+   :cve_nist:`2026-43141`, :cve_nist:`2026-43143`, :cve_nist:`2026-43145`, :cve_nist:`2026-43147`,
+   :cve_nist:`2026-43148`, :cve_nist:`2026-43149`, :cve_nist:`2026-43150`, :cve_nist:`2026-43152`,
+   :cve_nist:`2026-43156`, :cve_nist:`2026-43157`, :cve_nist:`2026-43158`, :cve_nist:`2026-43159`,
+   :cve_nist:`2026-43162`, :cve_nist:`2026-43163`, :cve_nist:`2026-43167`, :cve_nist:`2026-43168`,
+   :cve_nist:`2026-43170`, :cve_nist:`2026-43171`, :cve_nist:`2026-43173`, :cve_nist:`2026-43180`,
+   :cve_nist:`2026-43182`, :cve_nist:`2026-43183`, :cve_nist:`2026-43184`, :cve_nist:`2026-43186`,
+   :cve_nist:`2026-43187`, :cve_nist:`2026-43189`, :cve_nist:`2026-43190`, :cve_nist:`2026-43194`,
+   :cve_nist:`2026-43196`, :cve_nist:`2026-43200`, :cve_nist:`2026-43202`, :cve_nist:`2026-43203`,
+   :cve_nist:`2026-43205`, :cve_nist:`2026-43206`, :cve_nist:`2026-43207`, :cve_nist:`2026-43209`,
+   :cve_nist:`2026-43211`, :cve_nist:`2026-43212`, :cve_nist:`2026-43214`, :cve_nist:`2026-43215`,
+   :cve_nist:`2026-43218`, :cve_nist:`2026-43221`, :cve_nist:`2026-43222`, :cve_nist:`2026-43223`,
+   :cve_nist:`2026-43225`, :cve_nist:`2026-43226`, :cve_nist:`2026-43227`, :cve_nist:`2026-43230`,
+   :cve_nist:`2026-43231`, :cve_nist:`2026-43232`, :cve_nist:`2026-43233`, :cve_nist:`2026-43236`,
+   :cve_nist:`2026-43238`, :cve_nist:`2026-43239`, :cve_nist:`2026-43240`, :cve_nist:`2026-43241`,
+   :cve_nist:`2026-43242`, :cve_nist:`2026-43245`, :cve_nist:`2026-43246`, :cve_nist:`2026-43251`,
+   :cve_nist:`2026-43252`, :cve_nist:`2026-43253`, :cve_nist:`2026-43255`, :cve_nist:`2026-43256`,
+   :cve_nist:`2026-43257`, :cve_nist:`2026-43261`, :cve_nist:`2026-43262`, :cve_nist:`2026-43264`,
+   :cve_nist:`2026-43265`, :cve_nist:`2026-43266`, :cve_nist:`2026-43268`, :cve_nist:`2026-43269`,
+   :cve_nist:`2026-43270`, :cve_nist:`2026-43271`, :cve_nist:`2026-43273`, :cve_nist:`2026-43275`,
+   :cve_nist:`2026-43277`, :cve_nist:`2026-43278`, :cve_nist:`2026-43279`, :cve_nist:`2026-43281`,
+   :cve_nist:`2026-43283`, :cve_nist:`2026-43284`, :cve_nist:`2026-43287`, :cve_nist:`2026-43288`,
+   :cve_nist:`2026-43289`, :cve_nist:`2026-43291`, :cve_nist:`2026-43295`, :cve_nist:`2026-43296`,
+   :cve_nist:`2026-43302`, :cve_nist:`2026-43304`, :cve_nist:`2026-43312`, :cve_nist:`2026-43313`,
+   :cve_nist:`2026-43314`, :cve_nist:`2026-43315`, :cve_nist:`2026-43316`, :cve_nist:`2026-43324`,
+   :cve_nist:`2026-43327`, :cve_nist:`2026-43328`, :cve_nist:`2026-43329`, :cve_nist:`2026-43330`,
+   :cve_nist:`2026-43332`, :cve_nist:`2026-43333`, :cve_nist:`2026-43334`, :cve_nist:`2026-43336`,
+   :cve_nist:`2026-43339`, :cve_nist:`2026-43340`, :cve_nist:`2026-43341`, :cve_nist:`2026-43342`,
+   :cve_nist:`2026-43343`, :cve_nist:`2026-43345`, :cve_nist:`2026-43350`, :cve_nist:`2026-43355`,
+   :cve_nist:`2026-43357`, :cve_nist:`2026-43359`, :cve_nist:`2026-43360`, :cve_nist:`2026-43361`,
+   :cve_nist:`2026-43362`, :cve_nist:`2026-43363`, :cve_nist:`2026-43365`, :cve_nist:`2026-43366`,
+   :cve_nist:`2026-43368`, :cve_nist:`2026-43370`, :cve_nist:`2026-43371`, :cve_nist:`2026-43372`,
+   :cve_nist:`2026-43373`, :cve_nist:`2026-43376`, :cve_nist:`2026-43377`, :cve_nist:`2026-43378`,
+   :cve_nist:`2026-43379`, :cve_nist:`2026-43380`, :cve_nist:`2026-43381`, :cve_nist:`2026-43382`,
+   :cve_nist:`2026-43383`, :cve_nist:`2026-43386`, :cve_nist:`2026-43387`, :cve_nist:`2026-43397`,
+   :cve_nist:`2026-43405`, :cve_nist:`2026-43406`, :cve_nist:`2026-43407`, :cve_nist:`2026-43409`,
+   :cve_nist:`2026-43411`, :cve_nist:`2026-43412`, :cve_nist:`2026-43413`, :cve_nist:`2026-43415`,
+   :cve_nist:`2026-43419`, :cve_nist:`2026-43420`, :cve_nist:`2026-43424`, :cve_nist:`2026-43425`,
+   :cve_nist:`2026-43426`, :cve_nist:`2026-43427`, :cve_nist:`2026-43428`, :cve_nist:`2026-43429`,
+   :cve_nist:`2026-43430`, :cve_nist:`2026-43432`, :cve_nist:`2026-43436`, :cve_nist:`2026-43437`,
+   :cve_nist:`2026-43439`, :cve_nist:`2026-43441`, :cve_nist:`2026-43445`, :cve_nist:`2026-43448`,
+   :cve_nist:`2026-43449`, :cve_nist:`2026-43450`, :cve_nist:`2026-43451`, :cve_nist:`2026-43452`,
+   :cve_nist:`2026-43453`, :cve_nist:`2026-43455`, :cve_nist:`2026-43457`, :cve_nist:`2026-43458`,
+   :cve_nist:`2026-43459`, :cve_nist:`2026-43466`, :cve_nist:`2026-43468`, :cve_nist:`2026-43469`,
+   :cve_nist:`2026-43471`, :cve_nist:`2026-43472`, :cve_nist:`2026-43473`, :cve_nist:`2026-43475`,
+   :cve_nist:`2026-43476`, :cve_nist:`2026-43480`, :cve_nist:`2026-43483`, :cve_nist:`2026-43484`,
+   :cve_nist:`2026-43488`, :cve_nist:`2026-43490`, :cve_nist:`2026-43491`, :cve_nist:`2026-43492`,
+   :cve_nist:`2026-43493`, :cve_nist:`2026-43494`, :cve_nist:`2026-43495`, :cve_nist:`2026-43496`,
+   :cve_nist:`2026-43497`, :cve_nist:`2026-43499`, :cve_nist:`2026-43500`, :cve_nist:`2026-43501`,
+   :cve_nist:`2026-43502`, :cve_nist:`2026-43503`, :cve_nist:`2026-45834`, :cve_nist:`2026-45835`,
+   :cve_nist:`2026-45836`, :cve_nist:`2026-45838`, :cve_nist:`2026-45839`, :cve_nist:`2026-45840`,
+   :cve_nist:`2026-45841`, :cve_nist:`2026-45842`, :cve_nist:`2026-45843`, :cve_nist:`2026-45844`,
+   :cve_nist:`2026-45845`, :cve_nist:`2026-45846`, :cve_nist:`2026-45847`, :cve_nist:`2026-45848`,
+   :cve_nist:`2026-45849`, :cve_nist:`2026-45851`, :cve_nist:`2026-45852`, :cve_nist:`2026-45856`,
+   :cve_nist:`2026-45857`, :cve_nist:`2026-45858`, :cve_nist:`2026-45860`, :cve_nist:`2026-45862`,
+   :cve_nist:`2026-45864`, :cve_nist:`2026-45865`, :cve_nist:`2026-45866`, :cve_nist:`2026-45867`,
+   :cve_nist:`2026-45868`, :cve_nist:`2026-45869`, :cve_nist:`2026-45870`, :cve_nist:`2026-45871`,
+   :cve_nist:`2026-45872`, :cve_nist:`2026-45873`, :cve_nist:`2026-45875`, :cve_nist:`2026-45878`,
+   :cve_nist:`2026-45879`, :cve_nist:`2026-45880`, :cve_nist:`2026-45881`, :cve_nist:`2026-45883`,
+   :cve_nist:`2026-45885`, :cve_nist:`2026-45886`, :cve_nist:`2026-45890`, :cve_nist:`2026-45891`,
+   :cve_nist:`2026-45895`, :cve_nist:`2026-45899`, :cve_nist:`2026-45902`, :cve_nist:`2026-45904`,
+   :cve_nist:`2026-45905`, :cve_nist:`2026-45910`, :cve_nist:`2026-45911`, :cve_nist:`2026-45912`,
+   :cve_nist:`2026-45913`, :cve_nist:`2026-45914`, :cve_nist:`2026-45915`, :cve_nist:`2026-45916`,
+   :cve_nist:`2026-45919`, :cve_nist:`2026-45920`, :cve_nist:`2026-45921`, :cve_nist:`2026-45923`,
+   :cve_nist:`2026-45924`, :cve_nist:`2026-45935`, :cve_nist:`2026-45936`, :cve_nist:`2026-45941`,
+   :cve_nist:`2026-45942`, :cve_nist:`2026-45946`, :cve_nist:`2026-45947`, :cve_nist:`2026-45948`,
+   :cve_nist:`2026-45954`, :cve_nist:`2026-45956`, :cve_nist:`2026-45957`, :cve_nist:`2026-45958`,
+   :cve_nist:`2026-45960`, :cve_nist:`2026-45962`, :cve_nist:`2026-45964`, :cve_nist:`2026-45965`,
+   :cve_nist:`2026-45968`, :cve_nist:`2026-45969`, :cve_nist:`2026-45970`, :cve_nist:`2026-45972`,
+   :cve_nist:`2026-45974`, :cve_nist:`2026-45976`, :cve_nist:`2026-45978`, :cve_nist:`2026-45981`,
+   :cve_nist:`2026-45982`, :cve_nist:`2026-45983`, :cve_nist:`2026-45984`, :cve_nist:`2026-45985`,
+   :cve_nist:`2026-45986`, :cve_nist:`2026-45987`, :cve_nist:`2026-45988`, :cve_nist:`2026-45989`,
+   :cve_nist:`2026-45991`, :cve_nist:`2026-45993`, :cve_nist:`2026-45994`, :cve_nist:`2026-45996`,
+   :cve_nist:`2026-45997`, :cve_nist:`2026-45998`, :cve_nist:`2026-45999`, :cve_nist:`2026-46000`,
+   :cve_nist:`2026-46002`, :cve_nist:`2026-46003`, :cve_nist:`2026-46004`, :cve_nist:`2026-46005`,
+   :cve_nist:`2026-46006`, :cve_nist:`2026-46009`, :cve_nist:`2026-46011`, :cve_nist:`2026-46012`,
+   :cve_nist:`2026-46015`, :cve_nist:`2026-46016`, :cve_nist:`2026-46018`, :cve_nist:`2026-46019`,
+   :cve_nist:`2026-46021`, :cve_nist:`2026-46022`, :cve_nist:`2026-46023`, :cve_nist:`2026-46024`,
+   :cve_nist:`2026-46026`, :cve_nist:`2026-46027`, :cve_nist:`2026-46028`, :cve_nist:`2026-46031`,
+   :cve_nist:`2026-46033`, :cve_nist:`2026-46037`, :cve_nist:`2026-46038`, :cve_nist:`2026-46040`,
+   :cve_nist:`2026-46043`, :cve_nist:`2026-46046`, :cve_nist:`2026-46047`, :cve_nist:`2026-46049`,
+   :cve_nist:`2026-46050`, :cve_nist:`2026-46051`, :cve_nist:`2026-46052`, :cve_nist:`2026-46053`,
+   :cve_nist:`2026-46056`, :cve_nist:`2026-46058`, :cve_nist:`2026-46062`, :cve_nist:`2026-46063`,
+   :cve_nist:`2026-46064`, :cve_nist:`2026-46065`, :cve_nist:`2026-46068`, :cve_nist:`2026-46069`,
+   :cve_nist:`2026-46070`, :cve_nist:`2026-46072`, :cve_nist:`2026-46075`, :cve_nist:`2026-46077`,
+   :cve_nist:`2026-46078`, :cve_nist:`2026-46079`, :cve_nist:`2026-46080`, :cve_nist:`2026-46082`,
+   :cve_nist:`2026-46083`, :cve_nist:`2026-46084`, :cve_nist:`2026-46086`, :cve_nist:`2026-46088`,
+   :cve_nist:`2026-46089`, :cve_nist:`2026-46091`, :cve_nist:`2026-46094`, :cve_nist:`2026-46098`,
+   :cve_nist:`2026-46099`, :cve_nist:`2026-46101`, :cve_nist:`2026-46102`, :cve_nist:`2026-46103`,
+   :cve_nist:`2026-46106`, :cve_nist:`2026-46107`, :cve_nist:`2026-46108`, :cve_nist:`2026-46110`,
+   :cve_nist:`2026-46111`, :cve_nist:`2026-46112`, :cve_nist:`2026-46113`, :cve_nist:`2026-46114`,
+   :cve_nist:`2026-46115`, :cve_nist:`2026-46116`, :cve_nist:`2026-46119`, :cve_nist:`2026-46120`,
+   :cve_nist:`2026-46121`, :cve_nist:`2026-46122`, :cve_nist:`2026-46123`, :cve_nist:`2026-46124`,
+   :cve_nist:`2026-46125`, :cve_nist:`2026-46127`, :cve_nist:`2026-46128`, :cve_nist:`2026-46129`,
+   :cve_nist:`2026-46131`, :cve_nist:`2026-46132`, :cve_nist:`2026-46133`, :cve_nist:`2026-46136`,
+   :cve_nist:`2026-46137`, :cve_nist:`2026-46138`, :cve_nist:`2026-46142`, :cve_nist:`2026-46143`,
+   :cve_nist:`2026-46144`, :cve_nist:`2026-46145`, :cve_nist:`2026-46146`, :cve_nist:`2026-46149`,
+   :cve_nist:`2026-46150`, :cve_nist:`2026-46151`, :cve_nist:`2026-46152`, :cve_nist:`2026-46155`,
+   :cve_nist:`2026-46158`, :cve_nist:`2026-46159`, :cve_nist:`2026-46160`, :cve_nist:`2026-46161`,
+   :cve_nist:`2026-46163`, :cve_nist:`2026-46164`, :cve_nist:`2026-46167`, :cve_nist:`2026-46168`,
+   :cve_nist:`2026-46169`, :cve_nist:`2026-46170`, :cve_nist:`2026-46172`, :cve_nist:`2026-46173`,
+   :cve_nist:`2026-46174`, :cve_nist:`2026-46176`, :cve_nist:`2026-46177`, :cve_nist:`2026-46178`,
+   :cve_nist:`2026-46179`, :cve_nist:`2026-46180`, :cve_nist:`2026-46184`, :cve_nist:`2026-46185`,
+   :cve_nist:`2026-46186`, :cve_nist:`2026-46187`, :cve_nist:`2026-46189`, :cve_nist:`2026-46190`,
+   :cve_nist:`2026-46191`, :cve_nist:`2026-46193`, :cve_nist:`2026-46194`, :cve_nist:`2026-46195`,
+   :cve_nist:`2026-46196`, :cve_nist:`2026-46197`, :cve_nist:`2026-46198`, :cve_nist:`2026-46199`,
+   :cve_nist:`2026-46204`, :cve_nist:`2026-46205`, :cve_nist:`2026-46206`, :cve_nist:`2026-46208`,
+   :cve_nist:`2026-46209`, :cve_nist:`2026-46212`, :cve_nist:`2026-46214`, :cve_nist:`2026-46218`,
+   :cve_nist:`2026-46219`, :cve_nist:`2026-46220`, :cve_nist:`2026-46225`, :cve_nist:`2026-46226`,
+   :cve_nist:`2026-46227`, :cve_nist:`2026-46229`, :cve_nist:`2026-46230`, :cve_nist:`2026-46231`,
+   :cve_nist:`2026-46232`, :cve_nist:`2026-46233`, :cve_nist:`2026-46234`, :cve_nist:`2026-46235`,
+   :cve_nist:`2026-46236`, :cve_nist:`2026-46238`, :cve_nist:`2026-46243`, :cve_nist:`2026-46244`,
+   :cve_nist:`2026-46247`, :cve_nist:`2026-46249`, :cve_nist:`2026-46250`, :cve_nist:`2026-46251`,
+   :cve_nist:`2026-46253`, :cve_nist:`2026-46255`, :cve_nist:`2026-46259`, :cve_nist:`2026-46260`,
+   :cve_nist:`2026-46261`, :cve_nist:`2026-46262`, :cve_nist:`2026-46265`, :cve_nist:`2026-46266`,
+   :cve_nist:`2026-46267`, :cve_nist:`2026-46270`, :cve_nist:`2026-46273`, :cve_nist:`2026-46274`,
+   :cve_nist:`2026-46275`, :cve_nist:`2026-46276`, :cve_nist:`2026-46280`, :cve_nist:`2026-46285`,
+   :cve_nist:`2026-46286`, :cve_nist:`2026-46287`, :cve_nist:`2026-46289`, :cve_nist:`2026-46291`,
+   :cve_nist:`2026-46292`, :cve_nist:`2026-46293`, :cve_nist:`2026-46294`, :cve_nist:`2026-46296`,
+   :cve_nist:`2026-46299`, :cve_nist:`2026-46300`, :cve_nist:`2026-46301`, :cve_nist:`2026-46303`,
+   :cve_nist:`2026-46304`, :cve_nist:`2026-46306`, :cve_nist:`2026-46307`, :cve_nist:`2026-46312`,
+   :cve_nist:`2026-46319`, :cve_nist:`2026-46323`, :cve_nist:`2026-46328`, :cve_nist:`2026-46333`,
+   :cve_nist:`2026-52911`, :cve_nist:`2026-52912`, :cve_nist:`2026-52914`, :cve_nist:`2026-52915`,
+   :cve_nist:`2026-52916`, :cve_nist:`2026-52918`, :cve_nist:`2026-52919`, :cve_nist:`2026-52920`,
+   :cve_nist:`2026-52921`, :cve_nist:`2026-52922`, :cve_nist:`2026-52923`, :cve_nist:`2026-52925`,
+   :cve_nist:`2026-52926`, :cve_nist:`2026-52931`, :cve_nist:`2026-52933`, :cve_nist:`2026-52936`,
+   :cve_nist:`2026-52941`, :cve_nist:`2026-53128`, :cve_nist:`2026-53130`, :cve_nist:`2026-53279`,
+   :cve_nist:`2026-53287`, :cve_nist:`2026-53289`, :cve_nist:`2026-53291`, :cve_nist:`2026-53293`,
+   :cve_nist:`2026-53294`, :cve_nist:`2026-53295`, :cve_nist:`2026-53296`, :cve_nist:`2026-53303`,
+   :cve_nist:`2026-53304`, :cve_nist:`2026-53306`, :cve_nist:`2026-53309`, :cve_nist:`2026-53314`
+   and :cve_nist:`2026-53320`
+-  linux-yocto/6.6: Ignore :cve_nist:`2023-53012`, :cve_nist:`2023-53187`, :cve_nist:`2024-26949`,
+   :cve_nist:`2024-26997`, :cve_nist:`2024-35983`, :cve_nist:`2024-36002`, :cve_nist:`2024-36288`,
+   :cve_nist:`2024-38542`, :cve_nist:`2024-38595`, :cve_nist:`2024-40920`, :cve_nist:`2024-40921`,
+   :cve_nist:`2024-40986`, :cve_nist:`2024-42111`, :cve_nist:`2024-42112`, :cve_nist:`2024-42150`,
+   :cve_nist:`2024-43820`, :cve_nist:`2024-43838`, :cve_nist:`2024-47711`, :cve_nist:`2024-49854`,
+   :cve_nist:`2024-50042`, :cve_nist:`2024-50097`, :cve_nist:`2024-50203`, :cve_nist:`2024-50206`,
+   :cve_nist:`2024-50238`, :cve_nist:`2024-50241`, :cve_nist:`2024-50249`, :cve_nist:`2024-50281`,
+   :cve_nist:`2024-53073`, :cve_nist:`2024-53097`, :cve_nist:`2024-53115`, :cve_nist:`2024-53133`,
+   :cve_nist:`2024-53169`, :cve_nist:`2024-53201`, :cve_nist:`2024-54191`, :cve_nist:`2024-54460`,
+   :cve_nist:`2024-56542`, :cve_nist:`2024-56550`, :cve_nist:`2024-56561`, :cve_nist:`2024-56782`,
+   :cve_nist:`2024-57805`, :cve_nist:`2024-57852`, :cve_nist:`2024-57879`, :cve_nist:`2024-57935`,
+   :cve_nist:`2024-57952`, :cve_nist:`2024-57990`, :cve_nist:`2024-58008`, :cve_nist:`2024-58081`,
+   :cve_nist:`2025-21752`, :cve_nist:`2025-21809`, :cve_nist:`2025-21813`, :cve_nist:`2025-21902`,
+   :cve_nist:`2025-22026`, :cve_nist:`2025-22030`, :cve_nist:`2025-22032`, :cve_nist:`2025-22069`,
+   :cve_nist:`2025-22112`, :cve_nist:`2025-37760`, :cve_nist:`2025-37814`, :cve_nist:`2025-37827`,
+   :cve_nist:`2025-37845`, :cve_nist:`2025-37868`, :cve_nist:`2025-37871`, :cve_nist:`2025-37878`,
+   :cve_nist:`2025-37895`, :cve_nist:`2025-37929`, :cve_nist:`2025-37962`, :cve_nist:`2025-37974`,
+   :cve_nist:`2025-38055`, :cve_nist:`2025-38098`, :cve_nist:`2025-38099`, :cve_nist:`2025-38162`,
+   :cve_nist:`2025-38169`, :cve_nist:`2025-38201`, :cve_nist:`2025-38224`, :cve_nist:`2025-38234`,
+   :cve_nist:`2025-38289`, :cve_nist:`2025-38325`, :cve_nist:`2025-38372`, :cve_nist:`2025-38373`,
+   :cve_nist:`2025-38405`, :cve_nist:`2025-38421`, :cve_nist:`2025-38484`, :cve_nist:`2025-38551`,
+   :cve_nist:`2025-38567`, :cve_nist:`2025-38675`, :cve_nist:`2025-38733`, :cve_nist:`2025-38736`,
+   :cve_nist:`2025-39688`, :cve_nist:`2025-39725`, :cve_nist:`2025-39775`, :cve_nist:`2025-39807`,
+   :cve_nist:`2025-39872`, :cve_nist:`2025-39930`, :cve_nist:`2025-39948`, :cve_nist:`2025-39965`,
+   :cve_nist:`2025-39999`, :cve_nist:`2025-40005`, :cve_nist:`2025-40007`, :cve_nist:`2025-40082`,
+   :cve_nist:`2025-40101`, :cve_nist:`2025-40131`, :cve_nist:`2025-40199`, :cve_nist:`2025-40213`,
+   :cve_nist:`2025-40290`, :cve_nist:`2025-40327`, :cve_nist:`2025-40332`, :cve_nist:`2025-40344`,
+   :cve_nist:`2025-68195`, :cve_nist:`2025-68207`, :cve_nist:`2025-68213`, :cve_nist:`2025-68215`,
+   :cve_nist:`2025-68298`, :cve_nist:`2025-68351`, :cve_nist:`2025-68357`, :cve_nist:`2025-68358`,
+   :cve_nist:`2025-68823`, :cve_nist:`2025-71070`, :cve_nist:`2025-71076`, :cve_nist:`2025-71135`,
+   :cve_nist:`2025-71145`, :cve_nist:`2025-71146`, :cve_nist:`2025-71155`, :cve_nist:`2025-71204`,
+   :cve_nist:`2025-71220`, :cve_nist:`2025-71222`, :cve_nist:`2025-71223`, :cve_nist:`2025-71224`,
+   :cve_nist:`2025-71229`, :cve_nist:`2025-71232`, :cve_nist:`2025-71233`, :cve_nist:`2025-71235`,
+   :cve_nist:`2025-71236`, :cve_nist:`2025-71237`, :cve_nist:`2025-71238`, :cve_nist:`2025-71268`,
+   :cve_nist:`2025-71270`, :cve_nist:`2025-71271`, :cve_nist:`2025-71290`, :cve_nist:`2025-71293`,
+   :cve_nist:`2025-71294`, :cve_nist:`2025-71296`, :cve_nist:`2025-71298`, :cve_nist:`2025-71299`,
+   :cve_nist:`2025-71300`, :cve_nist:`2025-71301`, :cve_nist:`2025-71302`, :cve_nist:`2026-23014`,
+   :cve_nist:`2026-23018`, :cve_nist:`2026-23079`, :cve_nist:`2026-23100`, :cve_nist:`2026-23111`,
+   :cve_nist:`2026-23112`, :cve_nist:`2026-23143`, :cve_nist:`2026-23148`, :cve_nist:`2026-23151`,
+   :cve_nist:`2026-23166`, :cve_nist:`2026-23169`, :cve_nist:`2026-23176`, :cve_nist:`2026-23178`,
+   :cve_nist:`2026-23180`, :cve_nist:`2026-23182`, :cve_nist:`2026-23187`, :cve_nist:`2026-23189`,
+   :cve_nist:`2026-23190`, :cve_nist:`2026-23193`, :cve_nist:`2026-23198`, :cve_nist:`2026-23200`,
+   :cve_nist:`2026-23201`, :cve_nist:`2026-23202`, :cve_nist:`2026-23204`, :cve_nist:`2026-23205`,
+   :cve_nist:`2026-23206`, :cve_nist:`2026-23209`, :cve_nist:`2026-23216`, :cve_nist:`2026-23217`,
+   :cve_nist:`2026-23220`, :cve_nist:`2026-23221`, :cve_nist:`2026-23222`, :cve_nist:`2026-23228`,
+   :cve_nist:`2026-23229`, :cve_nist:`2026-23230`, :cve_nist:`2026-23233`, :cve_nist:`2026-23234`,
+   :cve_nist:`2026-23235`, :cve_nist:`2026-23236`, :cve_nist:`2026-23237`, :cve_nist:`2026-23238`,
+   :cve_nist:`2026-23254`, :cve_nist:`2026-23256`, :cve_nist:`2026-23257`, :cve_nist:`2026-23258`,
+   :cve_nist:`2026-23260`, :cve_nist:`2026-23261`, :cve_nist:`2026-23262`, :cve_nist:`2026-23264`,
+   :cve_nist:`2026-23266`, :cve_nist:`2026-23267`, :cve_nist:`2026-23288`, :cve_nist:`2026-23341`,
+   :cve_nist:`2026-23355`, :cve_nist:`2026-23376`, :cve_nist:`2026-23418`, :cve_nist:`2026-23421`,
+   :cve_nist:`2026-23423`, :cve_nist:`2026-23424`, :cve_nist:`2026-23425`, :cve_nist:`2026-23429`,
+   :cve_nist:`2026-23430`, :cve_nist:`2026-23431`, :cve_nist:`2026-23432`, :cve_nist:`2026-23433`,
+   :cve_nist:`2026-23435`, :cve_nist:`2026-23436`, :cve_nist:`2026-23437`, :cve_nist:`2026-23445`,
+   :cve_nist:`2026-23451`, :cve_nist:`2026-23453`, :cve_nist:`2026-23459`, :cve_nist:`2026-23464`,
+   :cve_nist:`2026-23466`, :cve_nist:`2026-23467`, :cve_nist:`2026-23469`, :cve_nist:`2026-23470`,
+   :cve_nist:`2026-31390`, :cve_nist:`2026-31394`, :cve_nist:`2026-31395`, :cve_nist:`2026-31397`,
+   :cve_nist:`2026-31398`, :cve_nist:`2026-31401`, :cve_nist:`2026-31404`, :cve_nist:`2026-31406`,
+   :cve_nist:`2026-31413`, :cve_nist:`2026-31435`, :cve_nist:`2026-31436`, :cve_nist:`2026-31437`,
+   :cve_nist:`2026-31438`, :cve_nist:`2026-31442`, :cve_nist:`2026-31443`, :cve_nist:`2026-31444`,
+   :cve_nist:`2026-31445`, :cve_nist:`2026-31456`, :cve_nist:`2026-31457`, :cve_nist:`2026-31459`,
+   :cve_nist:`2026-31460`, :cve_nist:`2026-31461`, :cve_nist:`2026-31463`, :cve_nist:`2026-31465`,
+   :cve_nist:`2026-31468`, :cve_nist:`2026-31470`, :cve_nist:`2026-31471`, :cve_nist:`2026-31472`,
+   :cve_nist:`2026-31475`, :cve_nist:`2026-31479`, :cve_nist:`2026-31481`, :cve_nist:`2026-31484`,
+   :cve_nist:`2026-31490`, :cve_nist:`2026-31491`, :cve_nist:`2026-31499`, :cve_nist:`2026-31501`,
+   :cve_nist:`2026-31511`, :cve_nist:`2026-31513`, :cve_nist:`2026-31514`, :cve_nist:`2026-31517`,
+   :cve_nist:`2026-31526`, :cve_nist:`2026-31529`, :cve_nist:`2026-31535`, :cve_nist:`2026-31538`,
+   :cve_nist:`2026-31539`, :cve_nist:`2026-31541`, :cve_nist:`2026-31543`, :cve_nist:`2026-31544`,
+   :cve_nist:`2026-31547`, :cve_nist:`2026-31553`, :cve_nist:`2026-31554`, :cve_nist:`2026-31556`,
+   :cve_nist:`2026-31558`, :cve_nist:`2026-31559`, :cve_nist:`2026-31561`, :cve_nist:`2026-31562`,
+   :cve_nist:`2026-31564`, :cve_nist:`2026-31567`, :cve_nist:`2026-31569`, :cve_nist:`2026-31571`,
+   :cve_nist:`2026-31572`, :cve_nist:`2026-31573`, :cve_nist:`2026-31574`, :cve_nist:`2026-31575`,
+   :cve_nist:`2026-31582`, :cve_nist:`2026-31589`, :cve_nist:`2026-31591`, :cve_nist:`2026-31593`,
+   :cve_nist:`2026-31600`, :cve_nist:`2026-31601`, :cve_nist:`2026-31608`, :cve_nist:`2026-31609`,
+   :cve_nist:`2026-31620`, :cve_nist:`2026-31621`, :cve_nist:`2026-31631`, :cve_nist:`2026-31632`,
+   :cve_nist:`2026-31633`, :cve_nist:`2026-31635`, :cve_nist:`2026-31636`, :cve_nist:`2026-31640`,
+   :cve_nist:`2026-31641`, :cve_nist:`2026-31643`, :cve_nist:`2026-31644`, :cve_nist:`2026-31647`,
+   :cve_nist:`2026-31650`, :cve_nist:`2026-31652`, :cve_nist:`2026-31653`, :cve_nist:`2026-31654`,
+   :cve_nist:`2026-31666`, :cve_nist:`2026-31687`, :cve_nist:`2026-31690`, :cve_nist:`2026-31691`,
+   :cve_nist:`2026-31703`, :cve_nist:`2026-31710`, :cve_nist:`2026-31713`, :cve_nist:`2026-31719`,
+   :cve_nist:`2026-31727`, :cve_nist:`2026-31731`, :cve_nist:`2026-31732`, :cve_nist:`2026-31733`,
+   :cve_nist:`2026-31734`, :cve_nist:`2026-31735`, :cve_nist:`2026-31736`, :cve_nist:`2026-31739`,
+   :cve_nist:`2026-31742`, :cve_nist:`2026-31743`, :cve_nist:`2026-31744`, :cve_nist:`2026-31745`,
+   :cve_nist:`2026-31746`, :cve_nist:`2026-31750`, :cve_nist:`2026-31753`, :cve_nist:`2026-31757`,
+   :cve_nist:`2026-31760`, :cve_nist:`2026-31764`, :cve_nist:`2026-31765`, :cve_nist:`2026-31766`,
+   :cve_nist:`2026-31769`, :cve_nist:`2026-31772`, :cve_nist:`2026-31774`, :cve_nist:`2026-31775`,
+   :cve_nist:`2026-31776`, :cve_nist:`2026-31782`, :cve_nist:`2026-31783`, :cve_nist:`2026-31784`,
+   :cve_nist:`2026-31785`, :cve_nist:`2026-43004`, :cve_nist:`2026-43005`, :cve_nist:`2026-43006`,
+   :cve_nist:`2026-43008`, :cve_nist:`2026-43012`, :cve_nist:`2026-43021`, :cve_nist:`2026-43031`,
+   :cve_nist:`2026-43034`, :cve_nist:`2026-43039`, :cve_nist:`2026-43045`, :cve_nist:`2026-43055`,
+   :cve_nist:`2026-43059`, :cve_nist:`2026-43063`, :cve_nist:`2026-43070`, :cve_nist:`2026-43084`,
+   :cve_nist:`2026-43087`, :cve_nist:`2026-43090`, :cve_nist:`2026-43095`, :cve_nist:`2026-43096`,
+   :cve_nist:`2026-43097`, :cve_nist:`2026-43100`, :cve_nist:`2026-43102`, :cve_nist:`2026-43106`,
+   :cve_nist:`2026-43108`, :cve_nist:`2026-43121`, :cve_nist:`2026-43122`, :cve_nist:`2026-43131`,
+   :cve_nist:`2026-43138`, :cve_nist:`2026-43142`, :cve_nist:`2026-43144`, :cve_nist:`2026-43146`,
+   :cve_nist:`2026-43151`, :cve_nist:`2026-43154`, :cve_nist:`2026-43155`, :cve_nist:`2026-43160`,
+   :cve_nist:`2026-43164`, :cve_nist:`2026-43165`, :cve_nist:`2026-43166`, :cve_nist:`2026-43169`,
+   :cve_nist:`2026-43174`, :cve_nist:`2026-43175`, :cve_nist:`2026-43176`, :cve_nist:`2026-43177`,
+   :cve_nist:`2026-43178`, :cve_nist:`2026-43179`, :cve_nist:`2026-43181`, :cve_nist:`2026-43188`,
+   :cve_nist:`2026-43191`, :cve_nist:`2026-43192`, :cve_nist:`2026-43193`, :cve_nist:`2026-43195`,
+   :cve_nist:`2026-43201`, :cve_nist:`2026-43208`, :cve_nist:`2026-43210`, :cve_nist:`2026-43217`,
+   :cve_nist:`2026-43220`, :cve_nist:`2026-43224`, :cve_nist:`2026-43228`, :cve_nist:`2026-43229`,
+   :cve_nist:`2026-43235`, :cve_nist:`2026-43237`, :cve_nist:`2026-43243`, :cve_nist:`2026-43247`,
+   :cve_nist:`2026-43254`, :cve_nist:`2026-43259`, :cve_nist:`2026-43260`, :cve_nist:`2026-43263`,
+   :cve_nist:`2026-43267`, :cve_nist:`2026-43272`, :cve_nist:`2026-43274`, :cve_nist:`2026-43276`,
+   :cve_nist:`2026-43280`, :cve_nist:`2026-43282`, :cve_nist:`2026-43285`, :cve_nist:`2026-43286`,
+   :cve_nist:`2026-43290`, :cve_nist:`2026-43292`, :cve_nist:`2026-43293`, :cve_nist:`2026-43297`,
+   :cve_nist:`2026-43300`, :cve_nist:`2026-43301`, :cve_nist:`2026-43305`, :cve_nist:`2026-43306`,
+   :cve_nist:`2026-43307`, :cve_nist:`2026-43320`, :cve_nist:`2026-43321`, :cve_nist:`2026-43322`,
+   :cve_nist:`2026-43323`, :cve_nist:`2026-43325`, :cve_nist:`2026-43326`, :cve_nist:`2026-43335`,
+   :cve_nist:`2026-43337`, :cve_nist:`2026-43346`, :cve_nist:`2026-43347`, :cve_nist:`2026-43348`,
+   :cve_nist:`2026-43349`, :cve_nist:`2026-43351`, :cve_nist:`2026-43354`, :cve_nist:`2026-43356`,
+   :cve_nist:`2026-43358`, :cve_nist:`2026-43364`, :cve_nist:`2026-43367`, :cve_nist:`2026-43369`,
+   :cve_nist:`2026-43374`, :cve_nist:`2026-43375`, :cve_nist:`2026-43384`, :cve_nist:`2026-43385`,
+   :cve_nist:`2026-43388`, :cve_nist:`2026-43389`, :cve_nist:`2026-43390`, :cve_nist:`2026-43391`,
+   :cve_nist:`2026-43392`, :cve_nist:`2026-43393`, :cve_nist:`2026-43394`, :cve_nist:`2026-43395`,
+   :cve_nist:`2026-43396`, :cve_nist:`2026-43398`, :cve_nist:`2026-43399`, :cve_nist:`2026-43400`,
+   :cve_nist:`2026-43401`, :cve_nist:`2026-43402`, :cve_nist:`2026-43403`, :cve_nist:`2026-43404`,
+   :cve_nist:`2026-43408`, :cve_nist:`2026-43410`, :cve_nist:`2026-43417`, :cve_nist:`2026-43418`,
+   :cve_nist:`2026-43422`, :cve_nist:`2026-43423`, :cve_nist:`2026-43431`, :cve_nist:`2026-43433`,
+   :cve_nist:`2026-43434`, :cve_nist:`2026-43435`, :cve_nist:`2026-43438`, :cve_nist:`2026-43440`,
+   :cve_nist:`2026-43442`, :cve_nist:`2026-43444`, :cve_nist:`2026-43446`, :cve_nist:`2026-43447`,
+   :cve_nist:`2026-43454`, :cve_nist:`2026-43460`, :cve_nist:`2026-43461`, :cve_nist:`2026-43462`,
+   :cve_nist:`2026-43463`, :cve_nist:`2026-43467`, :cve_nist:`2026-43470`, :cve_nist:`2026-43474`,
+   :cve_nist:`2026-43477`, :cve_nist:`2026-43478`, :cve_nist:`2026-43479`, :cve_nist:`2026-43481`,
+   :cve_nist:`2026-43482`, :cve_nist:`2026-43485`, :cve_nist:`2026-43486`, :cve_nist:`2026-43487`,
+   :cve_nist:`2026-43489` and :cve_nist:`2026-43498`
+-  lz4: Remove a reference to the rejected :cve_nist:`2025-62813`
+-  nfs-utils: Fix :cve_nist:`2025-12801`
+-  openssh: Fix :cve_nist:`2026-35386`, :cve_nist:`2026-35385`, :cve_nist:`2026-35387` and
+   :cve_nist:`2026-35388`
+-  python3-requests: Fix :cve_nist:`2026-25645`
+-  python3: Fix :cve_nist:`2025-13462`, :cve_nist:`2026-0672`, :cve_nist:`2026-1502`,
+   :cve_nist:`2026-3644`, :cve_nist:`2026-4224`, :cve_nist:`2026-4519`, :cve_nist:`2026-4786`,
+   :cve_nist:`2026-6019` and :cve_nist:`2026-6100`
+-  python3: Ignore :cve_nist:`2026-3087`
+-  qemu: Fix :cve_nist:`2024-6519`
+-  qemu: fix :cve_nist:`2025-11234`
+-  rust,libstd-rs: Ignore :cve_nist:`2024-3566`
+-  tiff: fix :cve_nist:`2026-4775`
+-  util-linux: Fix :cve_nist:`2026-27456`
+-  xserver-xorg: Fix :cve_nist:`2026-33999`, :cve_nist:`2026-34000`, :cve_nist:`2026-34001`,
+   :cve_nist:`2026-34002` and :cve_nist:`2026-34003`
+-  xwayland: Fix :cve_nist:`2026-33999`, :cve_nist:`2026-34000`, :cve_nist:`2026-34001`,
+   :cve_nist:`2026-34002` and :cve_nist:`2026-34003`
+-  xz: Fix :cve_nist:`2026-34743`
+
+Fixes in Yocto-5.0.19
+~~~~~~~~~~~~~~~~~~~~~
+
+-  apr-util: Add :term:`CVE_PRODUCT` to support product name
+-  apr: Add :term:`CVE_PRODUCT` to support product name
+-  bitbake: data: fix issue with varflag exclusion
+-  bitbake: fetch2/git: quote shallow extra ref arguments
+-  bitbake: fetch2/wget: handle HTTP 308 Permanent Redirect
+-  bitbake: fetch2/wget: limit auth on checkstatus redirects
+-  bitbake: fetch2: Unpack RPMs with --no-absolute-filenames
+-  bitbake: fetch2: validate deb/ipk data member names
+-  bitbake: fetch2: validate striplevel parameter
+-  bitbake: hashserv/tests: use valid 64-character unihashes
+-  bitbake: hashserv: validate unihash values
+-  bitbake: tests/fetch: cover checkstatus redirect auth handling
+-  bsp-guide: mention bootloader and device tree in BSP intro
+-  bsp-guide: update guide to reflect newer beaglebone
+-  build-appliance-image: Update to scarthgap head revisions
+-  build-manual: update :term:`ROOTFS_POSTPROCESS_COMMAND` example
+-  bzip2: set :term:`CVE_PRODUCT`
+-  cargo: set :term:`CVE_PRODUCT`
+-  classes/base: prefer gnu-prefixed :term:`HOSTTOOLS`
+-  classes/gtk-icon-cache: fix libdir passed to the postrm intercept
+-  conf/machine: fix typos in ARM and x86 README files
+-  contributor-guide: couple minor typo/grammar fixes
+-  contributor-guide: fix type "maintainance" to "maintenance"
+-  dev-manual: drop "PREFERRED_VERSION" from x86-base.inc snippet
+-  dev-manual: fix broken grammar in "Libraries" section
+-  dev-manual: fix grammatical error, missing word "with"
+-  dev-manual: fully define SOLIBS-related variables in bitbake.conf
+-  dev-manual: remove semicolons for rootfs commands
+-  dev-manual: SysVinit is the default init manager for Poky
+-  dev-manual: update :term:`AUTOREV` explanation to match current file
+-  devtool: prevent 'devtool modify -n' from corrupting kernel Git repos
+-  docs: conf.py: add a :yocto_bug: role
+-  docs: conf.py: define new \*_path roles
+-  docs: conf.py: define new {oecore,bitbake,meta_yocto}_rev roles
+-  docs: index.rst: update "Software Overview" to "Technical Overview"
+-  docs: "Transitioning ..." Various pedantic cleanups
+-  docs: What I Wish I'd Known: Various pedantic cleanups
+-  docs: YP Quick Build: delete extraneous periods in list
+-  gawk-native: fix gcc-15/C23 compilation issues
+-  gawk: trim native build configuration
+-  gawk: use native gawk when building glibc and grub
+-  gdb: backport a patch to fix static_assert in recent GCC
+-  gnupg: upgrade to 2.4.9
+-  go.bbclass: change GOTMPDIR to improve reproducibility
+-  go.bbclass: disable workspaces
+-  grub/glibc: Bump versions to resolve hashequiv/reproducibility issues
+-  kernel-dev: remove references to defunct LTSI project
+-  linux-yocto/6.6: address ltp hang
+-  linux-yocto/6.6: genericarm64 fix configuration audit warning
+-  linux-yocto/6.6: update to v6.6.142
+-  lttng-modules: Fix trace_hrtimer_start build failure
+-  meta/lib/oe/package.py: fix path to kernel sources in save_debugsources_info
+-  meta: fix generation of kernel CONFIGi\_ in SPDX3
+-  migration-guide: add release notes for 4.0.35 5.0.18
+-  oeqa/core/runner: stub addDuration in OETestResult
+-  oeqa/runtime/parselogs: update pci BAR ignore for kernel 6.10
+-  oeqa: Drop /git/ from our urls
+-  oeqa: runtime: go: Increase test_go_compile/test_go_module timeout
+-  openssl: upgrade to 3.5.7
+-  overview-manual: add ":term:" for OE Build System
+-  overview-manual: fix "checkout" versus "check out"
+-  overview-manual: fix typo, "semi-colon" -> "colon"
+-  overview-manual: hyphens not allowed in file version
+-  overview-manual: inform the reader early of "bitbake-getvar"
+-  overview-manual: mention that patch files can be compressed
+-  overview-manual: provide a more expansive definition of "layer"
+-  overview-manual: remind reader that meta-poky is a distro layer
+-  overview-manual: update deploy.bbclass snippet
+-  overview-manual: use correct spelling "counterpart"
+-  overview-manual: yp-intro.rst: add link to "buildbot"
+-  overview-manual: yp-intro.rst: delete really old references
+-  perl: link to the system zlib instead of a vendored copy
+-  poky.conf: Bump version for 5.0.19 release
+-  pseudo: Update to 1.9.8
+-  python_setuptools_build_meta: clean the build directory in configure
+-  recipe-style-guide.rst: two minor grammatical tweaks
+-  recipetool: Recognise https://git. as git urls
+-  ref-manual/variables.rst: link \*MIRRORS definitions to the BitBake manual
+-  ref-manual: add more explanation to glossary variable :term:`LICENSE`
+-  ref-manual: clarify that :term:`PACKAGE_EXCLUDE` supports DEB packaging
+-  ref-manual: clarify use of "PACKAGE_ARCH" in a packagegroup
+-  ref-manual: document :term:`RM_WORK_EXCLUDE_ITEMS` variable
+-  scripts/install-buildtools: Update to 5.0.18
+-  security-team.rst: update my email address and key
+-  security-team: Add section on multi-project embargoes
+-  security-team: Tidy and update section on security team operations
+-  security-team: Update membership list
+-  setuptools3: clean the build directory in configure
+-  setuptools3_legacy: ensure ${B} is clean
+-  systemd: update musl specific patch to apply
+-  tzdata/tzcode-native: upgrade to 2026b
+-  wic: filemap: use separate fd for SEEK_HOLE probes
+
+
+Known Issues in Yocto-5.0.19
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+- N/A
+
+Contributors to Yocto-5.0.19
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Thanks to the following people who contributed to this release:
+
+-  Adarsh Jagadish Kamini
+-  Alexander Kanavin
+-  Amaury Couderc
+-  Anders Heimer
+-  Anil Dongare
+-  Ankur Tyagi
+-  Antonin Godard
+-  Benjamin Robin (Schneider Electric)
+-  Bruce Ashfield
+-  Changqing Li
+-  Deepak Rathore
+-  Enrico Jörns
+-  Guðni Már Gilbert
+-  He Zhe
+-  Himanshu Jadon
+-  Hitendra Prajapati
+-  Hugo SIMELIERE (Schneider Electric)
+-  Jonas Munsin
+-  João Marcos Costa (Schneider Electric)
+-  Lee Chee Yang
+-  Marcio Henriques
+-  Mark Hatle
+-  Marta Rybczynska
+-  Martin Jansa
+-  Mathieu Dubois-Briand
+-  Naman Jain
+-  Paul Barker
+-  Peter Bergin
+-  Peter Marko
+-  Prabhudasu Vatala
+-  Richard Purdie
+-  Robert P. J. Day
+-  Ross Burton
+-  Shubham Pushpkar
+-  Sudhir Dumbhare
+-  Theo Gaige (Schneider Electric)
+-  Trevor Woerner
+-  Vijay Anusuri
+-  Yoann Congal
+-  Zahir Hussain
+
+
+Repositories / Downloads for Yocto-5.0.19
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+yocto-docs
+
+-  Repository Location: :yocto_git:`/yocto-docs`
+-  Branch: :yocto_git:`scarthgap </yocto-docs/log/?h=scarthgap>`
+-  Tag:  :yocto_git:`yocto-5.0.19 </yocto-docs/log/?h=yocto-5.0.19>`
+-  Git Revision: :yocto_git:`1b819d324780a699d9307a2d4e68c69b576ab748 </yocto-docs/commit/?id=1b819d324780a699d9307a2d4e68c69b576ab748>`
+-  Release Artefact: yocto-docs-1b819d324780a699d9307a2d4e68c69b576ab748
+-  sha: b2c484d8d13b05b133f6f23f44e7757e4b53d93c27c9ea76d1a2e5f759f51af0
+-  Download Locations:
+
+   https://downloads.yoctoproject.org/releases/yocto/yocto-5.0.19/yocto-docs-1b819d324780a699d9307a2d4e68c69b576ab748.tar.bz2
+
+   https://mirrors.edge.kernel.org/yocto/yocto/yocto-5.0.19/yocto-docs-1b819d324780a699d9307a2d4e68c69b576ab748.tar.bz2
+
+poky
+
+-  Repository Location: :yocto_git:`/poky`
+-  Branch: :yocto_git:`scarthgap </poky/log/?h=scarthgap>`
+-  Tag:  :yocto_git:`yocto-5.0.19 </poky/log/?h=yocto-5.0.19>`
+-  Git Revision: :yocto_git:`bb98354685781296e3b3737e7762412100f359c2 </poky/commit/?id=bb98354685781296e3b3737e7762412100f359c2>`
+-  Release Artefact: poky-bb98354685781296e3b3737e7762412100f359c2
+-  sha: 37fd9eeff8043e6d7d595421b8ac40d38357d2d4ce3a6d0f86a0f7d884c995c3
+-  Download Locations:
+
+   https://downloads.yoctoproject.org/releases/yocto/yocto-5.0.19/poky-bb98354685781296e3b3737e7762412100f359c2.tar.bz2
+
+   https://mirrors.edge.kernel.org/yocto/yocto/yocto-5.0.19/poky-bb98354685781296e3b3737e7762412100f359c2.tar.bz2
+
+openembedded-core
+
+-  Repository Location: :oe_git:`/openembedded-core`
+-  Branch: :oe_git:`scarthgap </openembedded-core/log/?h=scarthgap>`
+-  Tag:  :oe_git:`yocto-5.0.19 </openembedded-core/log/?h=yocto-5.0.19>`
+-  Git Revision: :oe_git:`2814f0962f56c8d1afa4de76d2895ba9b5cb767d </openembedded-core/commit/?id=2814f0962f56c8d1afa4de76d2895ba9b5cb767d>`
+-  Release Artefact: oecore-2814f0962f56c8d1afa4de76d2895ba9b5cb767d
+-  sha: 8556e454499fcda4026dc58fb8fc627861720f5c006bd72bf3b455dabd22a0e8
+-  Download Locations:
+
+   https://downloads.yoctoproject.org/releases/yocto/yocto-5.0.19/oecore-2814f0962f56c8d1afa4de76d2895ba9b5cb767d.tar.bz2
+
+   https://mirrors.edge.kernel.org/yocto/yocto/yocto-5.0.19/oecore-2814f0962f56c8d1afa4de76d2895ba9b5cb767d.tar.bz2
+
+meta-yocto
+
+-  Repository Location: :yocto_git:`/meta-yocto`
+-  Branch: :yocto_git:`scarthgap </meta-yocto/log/?h=scarthgap>`
+-  Tag:  :yocto_git:`yocto-5.0.19 </meta-yocto/log/?h=yocto-5.0.19>`
+-  Git Revision: :yocto_git:`2f749ae477c3b94dce71038f025180d7f612dab0 </meta-yocto/commit/?id=2f749ae477c3b94dce71038f025180d7f612dab0>`
+-  Release Artefact: meta-yocto-2f749ae477c3b94dce71038f025180d7f612dab0
+-  sha: 754237ee59a67d31da1f242555c77b75a96d9cdabdf0a4c9cfd98e378643d031
+-  Download Locations:
+
+   https://downloads.yoctoproject.org/releases/yocto/yocto-5.0.19/meta-yocto-2f749ae477c3b94dce71038f025180d7f612dab0.tar.bz2
+
+   https://mirrors.edge.kernel.org/yocto/yocto/yocto-5.0.19/meta-yocto-2f749ae477c3b94dce71038f025180d7f612dab0.tar.bz2
+
+meta-mingw
+
+-  Repository Location: :yocto_git:`/meta-mingw`
+-  Branch: :yocto_git:`scarthgap </meta-mingw/log/?h=scarthgap>`
+-  Tag:  :yocto_git:`yocto-5.0.19 </meta-mingw/log/?h=yocto-5.0.19>`
+-  Git Revision: :yocto_git:`bd9fef71ec005be3c3a6d7f8b99d8116daf70c4f </meta-mingw/commit/?id=bd9fef71ec005be3c3a6d7f8b99d8116daf70c4f>`
+-  Release Artefact: meta-mingw-bd9fef71ec005be3c3a6d7f8b99d8116daf70c4f
+-  sha: ab073def6487f237ac125d239b3739bf02415270959546b6b287778664f0ae65
+-  Download Locations:
+
+   https://downloads.yoctoproject.org/releases/yocto/yocto-5.0.19/meta-mingw-bd9fef71ec005be3c3a6d7f8b99d8116daf70c4f.tar.bz2
+
+   https://mirrors.edge.kernel.org/yocto/yocto/yocto-5.0.19/meta-mingw-bd9fef71ec005be3c3a6d7f8b99d8116daf70c4f.tar.bz2
+
+bitbake
+
+-  Repository Location: :oe_git:`/bitbake`
+-  Branch: :oe_git:`2.8 </bitbake/log/?h=2.8>`
+-  Tag:  :oe_git:`yocto-5.0.19 </bitbake/log/?h=yocto-5.0.19>`
+-  Git Revision: :oe_git:`0880963fea4d91a034e4a6e007d23f98658ab986 </bitbake/commit/?id=0880963fea4d91a034e4a6e007d23f98658ab986>`
+-  Release Artefact: bitbake-0880963fea4d91a034e4a6e007d23f98658ab986
+-  sha: 2bbf83d622fd4ad7ef0110378a9c88b683b2d82a911aba681b561446ec2f486b
+-  Download Locations:
+
+   https://downloads.yoctoproject.org/releases/yocto/yocto-5.0.19/bitbake-0880963fea4d91a034e4a6e007d23f98658ab986.tar.bz2
+
+   https://mirrors.edge.kernel.org/yocto/yocto/yocto-5.0.19/bitbake-0880963fea4d91a034e4a6e007d23f98658ab986.tar.bz2
+

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

@@ -166,7 +166,7 @@ New Features / Enhancements in 5.0
       ``meta/lib/patchtest/tests``) and make a number of improvements to enable
       it to validate patches submitted on the mailing list again. Additionally,
       make it work with the original upstream version of
-      `Patchwork <http://jk.ozlabs.org/projects/patchwork/>`__.
+      `Patchwork <https://web.archive.org/web/20250823174533/http://jk.ozlabs.org/projects/patchwork/>`__.
 
    -  Add an optional ``unimplemented-ptest`` QA warning to detect upstream
       packages with tests, that do not use ptest.
@@ -217,7 +217,7 @@ New Features / Enhancements in 5.0
       state directory (i.e., ``/run``).
 
    -  Allow to disable colored text output through the
-      `NO_COLOR <https://no-color.org/>`__ environment variable.
+      ``NO_COLOR`` environment variable.
 
    -  ``git-make-shallow`` script: add support for Git's ``safe.bareRepository=explicit``
       configuration setting.

documentation/overview-manual/concepts.rst

@@ -11,6 +11,14 @@ workflow,
 cross-development toolchains, shared state cache, and so forth are
 explained.
 
+.. note::
+
+   Throughout this section, many variables and their meanings are
+   introduced. If, in the context of a :term:`Build Directory`,
+   you want to examine the value of any of these variables, you can
+   use the ``bitbake-getvar`` command, explained in the
+   ":ref:`dev-manual/debugging:viewing variable values`" section.
+
 Yocto Project Components
 ========================
 
@@ -63,7 +71,7 @@ following commands::
 The most common usage for BitBake is ``bitbake recipename``, where
 ``recipename`` is the name of the recipe you want to build (referred
 to as the "target"). The target often equates to the first part of a
-recipe's filename (e.g. "foo" for a recipe named ``foo_1.3.0-r0.bb``).
+recipe's filename (e.g. "foo" for a recipe file named ``foo_1.3.0.bb``).
 So, to process the ``matchbox-desktop_1.2.3.bb`` recipe file, you might
 type the following::
 
@@ -427,7 +435,8 @@ configurations into their own layer. Settings you provide in
 in your ``conf/local.conf`` file in the :term:`Build Directory`.
 
 The following list provides some explanation and references for what you
-typically find in a distribution layer:
+typically find in a distribution layer (recall that
+:yocto_git:`meta-poky </meta-yocto/tree/meta-poky>` is such a layer):
 
 -  *classes*, *classes-global*, *classes-recipe:* Class files (``.bbclass``)
    hold common functionality that
@@ -770,7 +779,8 @@ and the :term:`FILESPATH` variable
 to locate applicable patch files.
 
 Default processing for patch files assumes the files have either
-``*.patch`` or ``*.diff`` file types. You can use :term:`SRC_URI` parameters
+``*.patch`` or ``*.diff`` file types (or a compressed form of those
+file types). You can use :term:`SRC_URI` parameters
 to change the way the build system recognizes patch files. See the
 :ref:`ref-tasks-patch` task for more
 information.
@@ -808,17 +818,20 @@ to a holding area (staged) in preparation for packaging:
 This step in the build process consists of the following tasks:
 
 -  :ref:`ref-tasks-prepare_recipe_sysroot`:
-   This task sets up the two sysroots in
+   This task sets up the two sysroots in the ``${``\ :term:`WORKDIR`\ ``}`` (i.e.
-   ``${``\ :term:`WORKDIR`\ ``}``
+   ``recipe-sysroot`` and ``recipe-sysroot-native``) so that the subsequent tasks
-   (i.e. ``recipe-sysroot`` and ``recipe-sysroot-native``) so that
+   of the recipe (notably :ref:`ref-tasks-configure` and :ref:`ref-tasks-compile`)
-   during the packaging phase the sysroots can contain the contents of
+   can access the libraries, headers, and similar files built by the recipes on
-   the
+   which it depends.
-   :ref:`ref-tasks-populate_sysroot`
-   tasks of the recipes on which the recipe containing the tasks
-   depends. A sysroot exists for both the target and for the native
-   binaries, which run on the host system.
 
--  *do_configure*: This task configures the source by enabling and
+   -  ``recipe-sysroot``: contains target libraries, and associated headers and
+      other data needed to cross-build software from its sources
+
+   -  ``recipe-sysroot-native``: contains host-native executables with their libraries
+      and other data, so that they can be run directly on the build host when
+      that is required by the build process
+
+-  :ref:`ref-tasks-configure`: This task configures the source by enabling and
    disabling any build-time and configuration options for the software
    being built. Configurations can come from the recipe itself as well
    as from an inherited class. Additionally, the software itself might
@@ -837,7 +850,7 @@ This step in the build process consists of the following tasks:
    class, see the :ref:`ref-classes-autotools` class
    :yocto_git:`here </poky/tree/meta/classes-recipe/autotools.bbclass>`.
 
--  *do_compile*: Once a configuration task has been satisfied,
+-  :ref:`ref-tasks-compile`: Once a configuration task has been satisfied,
    BitBake compiles the source using the
    :ref:`ref-tasks-compile` task.
    Compilation occurs in the directory pointed to by the
@@ -845,7 +858,7 @@ This step in the build process consists of the following tasks:
    :term:`B` directory is, by default, the same as the
    :term:`S` directory.
 
--  *do_install*: After compilation completes, BitBake executes the
+-  :ref:`ref-tasks-install`: After compilation completes, BitBake executes the
    :ref:`ref-tasks-install` task.
    This task copies files from the :term:`B` directory and places them in a
    holding area pointed to by the :term:`D`
@@ -936,7 +949,7 @@ root filesystem on the target, and must *not* make a reference to the variable
 .. note::
 
    The list of files for a package is defined using the override syntax by
-   separating :term:`FILES` and the package name by a semi-colon (``:``).
+   separating :term:`FILES` and the package name by a colon (``:``).
 
 A given file can only ever be in one package. By iterating from the leftmost to
 rightmost package in :term:`PACKAGES`, each file matching one of the patterns
@@ -1134,7 +1147,7 @@ host part is the part of the SDK that runs on the
 :term:`SDKMACHINE`.
 
 The :ref:`ref-tasks-populate_sdk_ext` task helps create the extensible SDK and
-handles host and target parts differently than its counter part does for
+handles host and target parts differently than its counterpart does for
 the standard SDK. For the extensible SDK, the task encapsulates the
 build system, which includes everything needed (host and target) for the
 SDK.
@@ -1815,7 +1828,8 @@ adding shared state wrapping to a task is as simple as this
        sstate_setscene(d)
    }
    addtask do_deploy_setscene
-   do_deploy[dirs] = "${DEPLOYDIR} ${B}"
+   do_deploy[dirs] = "${B}"
+   do_deploy[cleandirs] = "${DEPLOYDIR}"
    do_deploy[stamp-extra-info] = "${MACHINE_ARCH}"
 
 The following list explains the previous example:
@@ -1860,9 +1874,16 @@ The following list explains the previous example:
    information, see the ":ref:`bitbake-user-manual/bitbake-user-manual-execution:setscene`"
    section in the BitBake User Manual.
 
--  The ``do_deploy[dirs] = "${DEPLOYDIR} ${B}"`` line creates ``${DEPLOYDIR}``
+-  The ``do_deploy[dirs] = "${B}"`` line creates the directory ``${B}``
-   and ``${B}`` before the :ref:`ref-tasks-deploy` task runs, and also sets the
+   before the :ref:`ref-tasks-deploy` task runs, and also sets the
-   current working directory of :ref:`ref-tasks-deploy` to ``${B}``. For more
+   current working directory of :ref:`ref-tasks-deploy` to ``${B}``.
+   (If the directory already exists, it is left as is.) For more
+   information, see the ":ref:`bitbake-user-manual/bitbake-user-manual-metadata:variable flags`"
+   section in the BitBake User Manual.
+
+-  The ``do_deploy[cleandirs] = "${DEPLOYDIR}"`` line creates the *empty*
+   directory ``${DEPLOYDIR}`` before the :ref:`ref-tasks-deploy` task runs.
+   (If the directory already exists, it is deleted and recreated empty.) For more
    information, see the ":ref:`bitbake-user-manual/bitbake-user-manual-metadata:variable flags`"
    section in the BitBake User Manual.
 

documentation/overview-manual/development-environment.rst

@@ -58,16 +58,12 @@ Project. Most find that it is best to have a native Linux machine
 function as the development host. However, it is possible to use a
 system that does not run Linux as its operating system as your
 development host. When you have a Mac or Windows-based system, you can
-set it up as the development host by using
+set it up as the development host by using an :wikipedia:`OCI container
-`CROPS <https://github.com/crops/poky-container>`__, which leverages
+<Open_Container_Initiative>` (using `Docker <https://www.docker.com/>`__ or
-`Docker Containers <https://www.docker.com/>`__. Once you take the steps
+`Podman <https://podman.io/>`__). Once you take the steps
-to set up a CROPS machine, you effectively have access to a shell
+to set up container, you effectively have access to a shell
 environment that is similar to what you see when using a Linux-based
-development host. For the steps needed to set up a system using CROPS,
+development host.
-see the
-":ref:`dev-manual/start:setting up to use cross platforms (crops)`"
-section in
-the Yocto Project Development Tasks Manual.
 
 If your development host is going to be a system that runs a Linux
 distribution, you must still take steps to prepare the system
@@ -87,7 +83,7 @@ are several ways of working in the Yocto Project environment:
    which uses
    BitBake, in a command-line environment from a shell on your
    development host. You can accomplish this from a host that is a
-   native Linux machine or from a host that has been set up with CROPS.
+   native Linux machine or from a container.
    Either way, you create, modify, and build images and applications all
    within a shell-based environment using components and tools available
    through your Linux distribution and the Yocto Project.
@@ -172,7 +168,7 @@ these tarballs gives you a snapshot of the released files.
       BSP repository and the Source Directory (i.e. ``poky``)
       repository. For example, if you have checked out the "&DISTRO_NAME_NO_CAP;"
       branch of ``poky`` and you are going to use ``meta-intel``, be
-      sure to checkout the "&DISTRO_NAME_NO_CAP;" branch of ``meta-intel``.
+      sure to check out the "&DISTRO_NAME_NO_CAP;" branch of ``meta-intel``.
 
 In summary, here is where you can get the project files needed for
 development:
@@ -365,7 +361,7 @@ commands.
 .. note::
 
    -  For more information on Git, see
-      https://git-scm.com/documentation.
+      https://git-scm.com/docs.
 
    -  If you need to download Git, it is recommended that you add Git to
       your system through your distribution's "software store" (e.g. for
@@ -438,7 +434,7 @@ local branch named "&DISTRO_NAME_NO_CAP;", which tracks the upstream
 branch would ultimately affect the upstream "&DISTRO_NAME_NO_CAP;" branch
 of the ``poky`` repository.
 
-It is important to understand that when you create and checkout a local
+It is important to understand that when you create and check out a local
 working branch based on a branch name, your local environment matches
 the "tip" of that particular development branch at the time you created
 your local branch, which could be different from the files in the
@@ -461,10 +457,10 @@ releases.
 
 When you create a local copy of the Git repository, you also have access
 to all the tags in the upstream repository. Similar to branches, you can
-create and checkout a local working Git branch based on a tag name. When
+create and check out a local working Git branch based on a tag name. When
 you do this, you get a snapshot of the Git repository that reflects the
 state of the files when the change was made associated with that tag.
-The most common use is to checkout a working branch that matches a
+The most common use is to check out a working branch that matches a
 specific Yocto Project release. Here is an example::
 
    $ cd ~
@@ -483,7 +479,7 @@ whose "HEAD" matches the commit in the repository associated with the
 "rocko-18.0.0" tag. The files in your repository now exactly match that
 particular Yocto Project release as it is tagged in the upstream Git
 repository. It is important to understand that when you create and
-checkout a local working branch based on a tag, your environment matches
+check out a local working branch based on a tag, your environment matches
 a specific point in time and not the entire development branch (i.e.
 from the "tip" of the branch backwards).
 
@@ -496,7 +492,7 @@ you can manage with a small set of basic operations and workflows once
 you understand the basic philosophy behind Git. You do not have to be an
 expert in Git to be functional. A good place to look for instruction on
 a minimal set of Git commands is
-`here <https://git-scm.com/documentation>`__.
+`here <https://git-scm.com/docs>`__.
 
 The following list of Git commands briefly describes some basic Git
 operations as a way to get started. As with any set of commands, this

documentation/overview-manual/index.rst

@@ -4,15 +4,70 @@
 Yocto Project Overview and Concepts Manual
 ==========================================
 
-|
+Welcome to the Yocto Project Overview and Concepts Manual! This manual
+introduces the Yocto Project by providing concepts, software overviews,
+best-known-methods (BKMs), and any other high-level introductory
+information suitable for a new Yocto Project user.
+
+Here is what you can get from this manual:
+
+-  :ref:`overview-manual/yp-intro:introducing the yocto project`\ *:*
+   This chapter provides an introduction to the Yocto Project. You will learn
+   about features and challenges of the Yocto Project, the layer model,
+   components and tools, development methods, the
+   :term:`Poky` reference distribution, the
+   :term:`OpenEmbedded Build System` workflow, and some basic Yocto terms.
+
+-  :ref:`overview-manual/development-environment:the yocto project development environment`\ *:*
+   This chapter helps you get started understanding the Yocto Project
+   development environment. You will learn about open source, development hosts,
+   Yocto Project source repositories, workflows using Git and the Yocto
+   Project, a Git primer, and information about licensing.
+
+-  :doc:`/overview-manual/concepts` *:* This
+   chapter presents various concepts regarding the Yocto Project. You
+   can find conceptual information about components, development,
+   cross-toolchains, and so forth.
+
+This manual does not give you the following:
+
+-  *Step-by-step Instructions for Development Tasks:* Instructional
+   procedures reside in other manuals within the Yocto Project
+   documentation set. For example, the :doc:`/dev-manual/index`
+   provides examples on how to perform
+   various development tasks. As another example, the
+   :doc:`/sdk-manual/index` manual contains detailed
+   instructions on how to install an SDK, which is used to develop
+   applications for target hardware.
+
+-  *Reference Material:* This type of material resides in an appropriate
+   reference manual. For example, system variables are documented in the
+   :doc:`/ref-manual/index`. As another
+   example, the :doc:`/bsp-guide/index` contains reference information on
+   BSPs.
+
+-  *Detailed Public Information Not Specific to the Yocto Project:* For
+   example, exhaustive information on how to use the Source Control
+   Manager Git is better covered with Internet searches and official Git
+   Documentation than through the Yocto Project documentation.
 
 .. toctree::
    :caption: Table of Contents
    :numbered:
 
-   intro
    yp-intro
    development-environment
    concepts
 
+Because this manual presents information for many different topics,
+supplemental information is recommended for full comprehension. For
+additional introductory information on the Yocto Project, see the
+:yocto_home:`Yocto Project Website <>`. If you want to build an image
+with no knowledge of Yocto Project as a way of quickly testing it out,
+see the :doc:`/brief-yoctoprojectqs/index` document.
+For a comprehensive list of links and other documentation, see the
+":ref:`Links and Related
+Documentation <resources-links-and-related-documentation>`"
+section in the Yocto Project Reference Manual.
+
 .. include:: /boilerplate.rst

documentation/overview-manual/intro.rst

@@ -1,69 +0,0 @@
-.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
-
-**********************************************
-The Yocto Project Overview and Concepts Manual
-**********************************************
-
-Welcome
-=======
-
-Welcome to the Yocto Project Overview and Concepts Manual! This manual
-introduces the Yocto Project by providing concepts, software overviews,
-best-known-methods (BKMs), and any other high-level introductory
-information suitable for a new Yocto Project user.
-
-Here is what you can get from this manual:
-
--  :ref:`overview-manual/yp-intro:introducing the yocto project`\ *:*
-   This chapter provides an introduction to the Yocto Project. You will learn
-   about features and challenges of the Yocto Project, the layer model,
-   components and tools, development methods, the
-   :term:`Poky` reference distribution, the
-   OpenEmbedded build system workflow, and some basic Yocto terms.
-
--  :ref:`overview-manual/development-environment:the yocto project development environment`\ *:*
-   This chapter helps you get started understanding the Yocto Project
-   development environment. You will learn about open source, development hosts,
-   Yocto Project source repositories, workflows using Git and the Yocto
-   Project, a Git primer, and information about licensing.
-
--  :doc:`/overview-manual/concepts` *:* This
-   chapter presents various concepts regarding the Yocto Project. You
-   can find conceptual information about components, development,
-   cross-toolchains, and so forth.
-
-This manual does not give you the following:
-
--  *Step-by-step Instructions for Development Tasks:* Instructional
-   procedures reside in other manuals within the Yocto Project
-   documentation set. For example, the :doc:`/dev-manual/index`
-   provides examples on how to perform
-   various development tasks. As another example, the
-   :doc:`/sdk-manual/index` manual contains detailed
-   instructions on how to install an SDK, which is used to develop
-   applications for target hardware.
-
--  *Reference Material:* This type of material resides in an appropriate
-   reference manual. For example, system variables are documented in the
-   :doc:`/ref-manual/index`. As another
-   example, the :doc:`/bsp-guide/index` contains reference information on
-   BSPs.
-
--  *Detailed Public Information Not Specific to the Yocto Project:* For
-   example, exhaustive information on how to use the Source Control
-   Manager Git is better covered with Internet searches and official Git
-   Documentation than through the Yocto Project documentation.
-
-Other Information
-=================
-
-Because this manual presents information for many different topics,
-supplemental information is recommended for full comprehension. For
-additional introductory information on the Yocto Project, see the
-:yocto_home:`Yocto Project Website <>`. If you want to build an image
-with no knowledge of Yocto Project as a way of quickly testing it out,
-see the :doc:`/brief-yoctoprojectqs/index` document.
-For a comprehensive list of links and other documentation, see the
-":ref:`Links and Related
-Documentation <resources-links-and-related-documentation>`"
-section in the Yocto Project Reference Manual.

documentation/overview-manual/yp-intro.rst

@@ -26,12 +26,6 @@ platforms as well as software stacks that can be maintained and scaled.
 .. image:: svg/key-dev-elements.*
     :width: 100%
 
-For further introductory information on the Yocto Project, you might be
-interested in this
-`article <https://www.embedded.com/why-the-yocto-project-for-my-iot-project/>`__
-by Drew Moseley and in this short introductory
-`video <https://www.youtube.com/watch?v=utZpKM7i5Z4>`__.
-
 The remainder of this section overviews advantages and challenges tied
 to the Yocto Project.
 
@@ -291,13 +285,6 @@ Development Tools
 Here are tools that help you develop images and applications using
 the Yocto Project:
 
--  *CROPS:* `CROPS <https://github.com/crops/poky-container/>`__ is an
-   open source, cross-platform development framework that leverages
-   `Docker Containers <https://www.docker.com/>`__. CROPS provides an
-   easily managed, extensible environment that allows you to build
-   binaries for a variety of architectures on Windows, Linux and Mac OS
-   X hosts.
-
 -  *devtool:* This command-line tool is available as part of the
    extensible SDK (eSDK) and is its cornerstone. You can use ``devtool``
    to help build, test, and package software within the eSDK. You can
@@ -387,7 +374,7 @@ Yocto Project:
 
    .. note::
 
-      AutoBuilder is based on buildbot.
+      AutoBuilder is based on `buildbot <https://buildbot.net/>`__.
 
    A goal of the Yocto Project is to lead the open source industry with
    a project that automates testing and QA procedures. In doing so, the
@@ -540,9 +527,9 @@ Linux.
    Build Appliance was useful as a way to try out development in the
    Yocto Project environment.
 
-#. *CROPS:* The final and best solution available now for developing
+#. *CROPS:* Used to be a solution available for developing
-   using the Yocto Project on a system not native to Linux is with
+   using the Yocto Project on a system not native to Linux (see
-   :ref:`CROPS <overview-manual/yp-intro:development tools>`.
+   https://github.com/crops/poky-container).
 
 Development Methods
 ===================
@@ -576,25 +563,10 @@ Build Host runs, you have several choices.
    ":ref:`dev-manual/start:setting up a native linux host`"
    section in the Yocto Project Development Tasks Manual.
 
--  *CROss PlatformS (CROPS):* Typically, you use
+-  *OCI Containers:* Typically, you use an :wikipedia:`OCI container
-   `CROPS <https://github.com/crops/poky-container/>`__, which leverages
+   <Open_Container_Initiative>` (with `Docker <https://www.docker.com/>`__ or
-   `Docker Containers <https://www.docker.com/>`__, to set up a Build
+   `Podman <https://podman.io/>`__ for example), to set up a :term:`Build
-   Host that is not running Linux (e.g. Microsoft Windows or macOS).
+   Host` that is not running Linux (e.g. Microsoft Windows or macOS).
-
-   .. note::
-
-      You can, however, use CROPS on a Linux-based system.
-
-   CROPS is an open source, cross-platform development framework that
-   provides an easily managed, extensible environment for building
-   binaries targeted for a variety of architectures on Windows, macOS,
-   or Linux hosts. Once the Build Host is set up using CROPS, you can
-   prepare a shell environment to mimic that of a shell being used on a
-   system natively running Linux.
-
-   For information on how to set up a Build Host with CROPS, see the
-   ":ref:`dev-manual/start:setting up to use cross platforms (crops)`"
-   section in the Yocto Project Development Tasks Manual.
 
 -  *Windows Subsystem For Linux (WSL 2):* You may use Windows Subsystem
    For Linux version 2 to set up a Build Host using Windows 10 or later,
@@ -787,7 +759,9 @@ helpful for getting started:
    their code available to other application developers. For information
    on the eSDK, see the :doc:`/sdk-manual/index` manual.
 
--  *Layer:* A collection of related recipes. Layers allow you to
+-  *Layer:* A collection of related metadata, which could include any of
+   recipes, machine configuration files, distro configuration files
+   and/or class files. Layers allow you to
    consolidate related metadata to customize your build. Layers also
    isolate information used when building for multiple architectures.
    Layers are hierarchical in their ability to override previous

documentation/profile-manual/usage.rst

@@ -39,7 +39,7 @@ other tools when it seems useful to do so.
 The coverage below details some of the most common ways you'll likely
 want to apply the tool; full documentation can be found either within
 the tool itself or in the manual pages at
-`perf(1) <https://linux.die.net/man/1/perf>`__.
+:manpage:`perf(1)`.
 
 perf Setup
 ----------
@@ -869,8 +869,8 @@ goes a little way to support the idea mentioned previously that given
 the right kind of trace data, higher-level profiling-type summaries can
 be derived from it.
 
-Documentation on using the `'perf script' Python
+Documentation on using the :manpage:`'perf script' Python
-binding <https://linux.die.net/man/1/perf-script-python>`__.
+binding <perf-script-python(1)>`.
 
 System-Wide Tracing and Profiling
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -1150,23 +1150,19 @@ perf Documentation
 Online versions of the manual pages for the commands discussed in this
 section can be found here:
 
--  The `'perf stat' manual page <https://linux.die.net/man/1/perf-stat>`__.
+-  The :manpage:`'perf stat' manual page <perf-stat(1)>`.
 
--  The `'perf record'
+-  The :manpage:`'perf record' manual page <perf-record(1)>`.
-   manual page <https://linux.die.net/man/1/perf-record>`__.
 
--  The `'perf report'
+-  The :manpage:`'perf report' manual page <perf-report(1)>`.
-   manual page <https://linux.die.net/man/1/perf-report>`__.
 
--  The `'perf probe' manual page <https://linux.die.net/man/1/perf-probe>`__.
+-  The :manpage:`'perf probe' manual page <perf-probe(1)>`.
 
--  The `'perf script'
+-  The :manpage:`'perf script' manual page <perf-script(1)>`.
-   manual page <https://linux.die.net/man/1/perf-script>`__.
 
--  Documentation on using the `'perf script' Python
+-  Documentation on using the :manpage:`'perf script' Python binding <perf-script-python(1)>`.
-   binding <https://linux.die.net/man/1/perf-script-python>`__.
 
--  The top-level `perf(1) manual page <https://linux.die.net/man/1/perf>`__.
+-  The top-level :manpage:`perf(1) manual page <perf(1)>`.
 
 Normally, you should be able to open the manual pages via perf itself
 e.g. ``perf help`` or ``perf help record``.
@@ -1781,7 +1777,7 @@ gather / print / aggregate data extracted from the context they end up being
 called under.
 
 For example, this probe from the `SystemTap
-tutorial <https://sourceware.org/systemtap/tutorial/>`__ just prints a
+tutorial <https://sourceware.org/systemtap/tutorial.html>`__ just prints a
 line every time any process on the system runs ``open()`` on a file. For each line,
 it prints the executable name of the program that opened the file, along
 with its PID, and the name of the file it opened (or tried to open), which it
@@ -1957,7 +1953,7 @@ SystemTap Documentation
 -----------------------
 
 The SystemTap language reference can be found here: `SystemTap Language
-Reference <https://sourceware.org/systemtap/langref/>`__
+Reference <https://sourceware.org/systemtap/langref.html>`__
 
 Links to other SystemTap documents, tutorials, and examples can be found
 here: `SystemTap documentation
@@ -2388,7 +2384,7 @@ first part of the filenames::
 The report shows each event that was
 found in the blktrace data, along with a summary of the overall block
 I/O traffic during the run. You can look at the
-`blkparse <https://linux.die.net/man/1/blkparse>`__ manual page to learn the
+:manpage:`blkparse(1)` manual page to learn the
 meaning of each field displayed in the trace listing.
 
 Live Mode
@@ -2588,14 +2584,14 @@ blktrace Documentation
 Online versions of the manual pages for the commands discussed in this
 section can be found here:
 
--  https://linux.die.net/man/8/blktrace
+-  :manpage:`blktrace(8)`
 
--  https://linux.die.net/man/1/blkparse
+-  :manpage:`blkparse(1)`
 
--  https://linux.die.net/man/8/btrace
+-  :manpage:`btrace(8)`
 
 The above manual pages, along with manuals for the other blktrace utilities
 (``btt``, ``blkiomon``, etc) can be found in the ``/doc`` directory of the blktrace
 tools git repository::
 
-   $ git clone git://git.kernel.dk/blktrace.git
+   $ git clone https://git.kernel.org/pub/scm/linux/kernel/git/axboe/blktrace.git

documentation/ref-manual/classes.rst

@@ -515,7 +515,7 @@ by the :term:`SPDX_PRETTY`, :term:`SPDX_ARCHIVE_PACKAGED`,
 
 See the description of these variables and the
 ":ref:`dev-manual/sbom:creating a software bill of materials`"
-section in the Yocto Project Development Manual for more details.
+section in the Yocto Project Development Tasks Manual for more details.
 
 .. _ref-classes-cross:
 
@@ -2327,11 +2327,8 @@ consider some further things about using RPM:
    perform on-device upgrades.
 
 You can find additional information on the effects of the package class
-at these two Yocto Project mailing list links:
+at this Yocto Project mailing list link:
-
+:yocto_lists:`/g/poky/topic/61292484#msg6286`
--  :yocto_lists:`/pipermail/poky/2011-May/006362.html`
-
--  :yocto_lists:`/pipermail/poky/2011-May/006363.html`
 
 .. _ref-classes-package_deb:
 
@@ -2404,6 +2401,18 @@ section in the Yocto Project Development Tasks Manual.
 
 Previously, this class was called the ``task`` class.
 
+.. note::
+
+   If you're defining a packagegroup and need to set::
+
+      PACKAGE_ARCH = "${MACHINE_ARCH}"
+
+   for the packagegroup, you need to do that *before* the
+   ``inherit packagegroup`` line in the recipe file.
+   Setting it afterward can break BitBake parsing, result in
+   an "allarch" architecture mismatch error, or allow
+   architecture-independent defaults to override your intent.
+
 .. _ref-classes-patch:
 
 ``patch``
@@ -2677,7 +2686,7 @@ This class is intended to be inherited by individual recipes. However,
 the class' functionality is largely disabled unless "ptest" appears in
 :term:`DISTRO_FEATURES`. See the
 ":ref:`test-manual/ptest:testing packages with ptest`"
-section in the Yocto Project Development Tasks Manual for more information
+section in the Yocto Project Test Environment Manual for more information
 on ptest.
 
 .. _ref-classes-ptest-cargo:
@@ -2701,7 +2710,7 @@ have tests intended to be executed with ``gnome-desktop-testing``.
 
 For information on setting up and running ptests, see the
 ":ref:`test-manual/ptest:testing packages with ptest`"
-section in the Yocto Project Development Tasks Manual.
+section in the Yocto Project Test Environment Manual.
 
 .. _ref-classes-python3-dir:
 
@@ -2844,6 +2853,13 @@ which can also be set in your ``local.conf`` file. Here is an example::
 
    RM_WORK_EXCLUDE += "busybox glibc"
 
+Finally, if you are using this class for a recipe but want to prevent
+:term:`BitBake` from deleting specific folders or files in that recipe's
+:term:`WORKDIR` (other than ``temp``), you can preserve those folders or
+files with the :term:`RM_WORK_EXCLUDE_ITEMS` variable as follows::
+
+   RM_WORK_EXCLUDE_ITEMS += "items_to_keep"
+
 .. _ref-classes-rootfs*:
 
 ``rootfs*``
@@ -2981,7 +2997,7 @@ Python version 3.x extensions that use build systems based on ``setuptools``
 ``pyproject.toml`` format). Unlike :ref:`ref-classes-setuptools3`,
 this uses the traditional ``setup.py`` ``build`` and ``install`` commands and
 not wheels. This use of ``setuptools`` like this is
-`deprecated <https://github.com/pypa/setuptools/blob/main/CHANGES.rst#v5830>`__
+`deprecated <https://github.com/pypa/setuptools/blob/14cc4452199818e60cf01cd9cea96e90761abce7/NEWS.rst#v5830>`__
 but still relatively common.
 
 .. _ref-classes-setuptools3-base:
@@ -3246,7 +3262,7 @@ the :term:`SYSTEMD_BOOT_CFG`,
 :term:`SYSTEMD_BOOT_TIMEOUT` variables.
 
 You can also see the `Systemd-boot
-documentation <https://www.freedesktop.org/wiki/Software/systemd/systemd-boot/>`__
+documentation <https://systemd.io/BOOT/>`__
 for more information.
 
 .. _ref-classes-terminal:

documentation/ref-manual/faq.rst

@@ -105,7 +105,8 @@ attempt before any others by adding something like the following to the
        git://.*/.* &YOCTO_DL_URL;/mirror/sources/ \
        ftp://.*/.* &YOCTO_DL_URL;/mirror/sources/ \
        http://.*/.* &YOCTO_DL_URL;/mirror/sources/ \
-       https://.*/.* &YOCTO_DL_URL;/mirror/sources/"
+       https://.*/.* &YOCTO_DL_URL;/mirror/sources/ \
+   "
 
 These changes cause the build system to intercept Git, FTP, HTTP, and
 HTTPS requests and direct them to the ``http://`` sources mirror. You
@@ -144,7 +145,8 @@ file as long as the :term:`PREMIRRORS` server is current::
        git://.*/.* &YOCTO_DL_URL;/mirror/sources/ \
        ftp://.*/.* &YOCTO_DL_URL;/mirror/sources/ \
        http://.*/.* &YOCTO_DL_URL;/mirror/sources/ \
-       https://.*/.* &YOCTO_DL_URL;/mirror/sources/"
+       https://.*/.* &YOCTO_DL_URL;/mirror/sources/ \
+   "
    BB_FETCH_PREMIRRORONLY = "1"
 
 These changes would cause the build system to successfully fetch source

documentation/ref-manual/features.rst

@@ -208,7 +208,7 @@ metadata, as extra layers can define their own:
 -  *ptest:* Enables building the package tests where supported by
    individual recipes. For more information on package tests, see the
    ":ref:`test-manual/ptest:testing packages with ptest`" section
-   in the Yocto Project Development Tasks Manual.
+   in the Yocto Project Test Environment Manual.
 
 -  *pulseaudio:* Include support for
    `PulseAudio <https://www.freedesktop.org/wiki/Software/PulseAudio/>`__.
@@ -357,7 +357,7 @@ The image features available for all images are:
    different package name (or names) within the image recipe or at the
    distro configuration level.
 
--  *stateless-rootfs:*: specifies that the image should be created as
+-  *stateless-rootfs:* specifies that the image should be created as
    stateless - when using ``systemd``, ``systemctl-native`` will not
    be run on the image, leaving the image for population at runtime by
    systemd.

documentation/ref-manual/images.rst

@@ -37,10 +37,7 @@ Here is a list of supported recipes:
 -  ``build-appliance-image``: An example virtual machine that contains
    all the pieces required to run builds using the build system as well
    as the build system itself. You can boot and run the image using
-   either the `VMware
+   `VMware Workstation <https://www.vmware.com/products/desktop-hypervisor/workstation-and-fusion>`__.
-   Player <https://www.vmware.com/products/player/overview.html>`__ or
-   `VMware
-   Workstation <https://www.vmware.com/products/workstation/overview.html>`__.
    For more information on this image, see the :yocto_home:`Build
    Appliance </software-item/build-appliance>` page
    on the Yocto Project website.

documentation/ref-manual/release-process.rst

@@ -151,8 +151,8 @@ upgrade to the following :term:`LTS` release.
 
 The currently supported :term:`LTS` releases are:
 
+-  Version 6.0 ("Wrynose"), released in May 2026 and supported until April 2030.
 -  Version 5.0 ("Scarthgap"), released in April 2024 and supported until April 2028.
--  Version 4.0 ("Kirkstone"), released in May 2022 and supported until May 2026.
 
 See :yocto_wiki:`/Stable_Release_and_LTS` for details about the management
 of stable and :term:`LTS` releases.

documentation/ref-manual/tasks.rst

@@ -658,7 +658,7 @@ When invoked by the user, this task creates a file containing the
 differences between the original config as produced by
 :ref:`ref-tasks-kernel_configme` task and the
 changes made by the user with other methods (i.e. using
-(:ref:`ref-tasks-kernel_menuconfig`). Once the
+(:ref:`ref-tasks-menuconfig`). Once the
 file of differences is created, it can be used to create a config
 fragment that only contains the differences. You can invoke this task
 from the command line as follows::
@@ -686,7 +686,7 @@ kernel with the correct branches checked out.
 -------------------------
 
 Validates the configuration produced by the
-:ref:`ref-tasks-kernel_menuconfig` task. The
+:ref:`ref-tasks-menuconfig` task. The
 :ref:`ref-tasks-kernel_configcheck` task produces warnings when a requested
 configuration does not appear in the final ``.config`` file or when you
 override a policy configuration in a hardware configuration fragment.
@@ -711,26 +711,6 @@ passed to the kernel configuration phase proper. This is also the time
 during which user-specified defconfigs are applied if present, and where
 configuration modes such as ``--allnoconfig`` are applied.
 
-.. _ref-tasks-kernel_menuconfig:
-
-``do_kernel_menuconfig``
-------------------------
-
-Invoked by the user to manipulate the ``.config`` file used to build a
-linux-yocto recipe. This task starts the Linux kernel configuration
-tool, which you then use to modify the kernel configuration.
-
-.. note::
-
-   You can also invoke this tool from the command line as follows::
-
-           $ bitbake linux-yocto -c menuconfig
-
-
-See the ":ref:`kernel-dev/common:using ``menuconfig```"
-section in the Yocto Project Linux Kernel Development Manual for more
-information on this configuration tool.
-
 .. _ref-tasks-kernel_metadata:
 
 ``do_kernel_metadata``
@@ -749,10 +729,19 @@ which can then be applied by subsequent tasks such as
 ``do_menuconfig``
 -----------------
 
-Runs ``make menuconfig`` for the kernel. For information on
+Invoked by the user to manipulate the ``.config`` file used to build a
-``menuconfig``, see the
+linux-yocto recipe. This task starts the Linux kernel configuration
-":ref:`kernel-dev/common:using ``menuconfig```"
+tool, which you then use to modify the kernel configuration.
-section in the Yocto Project Linux Kernel Development Manual.
+
+You can invoke this tool from the command line as follows:
+
+.. code-block:: console
+
+   $ bitbake linux-yocto -c menuconfig
+
+See the ":ref:`kernel-dev/common:using ``menuconfig```"
+section in the Yocto Project Linux Kernel Development Manual for more
+information on this configuration tool.
 
 .. _ref-tasks-savedefconfig:
 
@@ -763,7 +752,7 @@ When invoked by the user, creates a defconfig file that can be used
 instead of the default defconfig. The saved defconfig contains the
 differences between the default defconfig and the changes made by the
 user using other methods (i.e. the
-:ref:`ref-tasks-kernel_menuconfig` task. You
+:ref:`ref-tasks-menuconfig` task. You
 can invoke the task using the following command::
 
    $ bitbake linux-yocto -c savedefconfig
@@ -785,22 +774,29 @@ can successfully build the kernel modules in the next step of the build.
 ``do_sizecheck``
 ----------------
 
-After the kernel has been built, this task checks the size of the
+If the variable :term:`KERNEL_IMAGE_MAXSIZE` is set, this task compares
-stripped kernel image against
+the size of all stripped kernel images listed in :term:`KERNEL_IMAGETYPES`
-:term:`KERNEL_IMAGE_MAXSIZE`. If that
+against that value. If more than one image type is listed there, warn on
-variable was set and the size of the stripped kernel exceeds that size,
+any that exceed that value, but fail only if none of them fit.
-the kernel build produces a warning to that effect.
 
 .. _ref-tasks-strip:
 
 ``do_strip``
 ------------
 
-If ``KERNEL_IMAGE_STRIP_EXTRA_SECTIONS`` is defined, this task strips
+If :term:`KERNEL_IMAGE_STRIP_EXTRA_SECTIONS` is defined, this task strips
 the sections named in that variable from ``vmlinux``. This stripping is
 typically used to remove nonessential sections such as ``.comment``
 sections from a size-sensitive configuration.
 
+Common sections to strip:
+
+-  ``.comment``: Holds compiler version strings and information
+
+-  ``.note.*``: Extra notes often left by the compiler
+
+-  ``.debug``: Debugging information
+
 .. _ref-tasks-validate_branches:
 
 ``do_validate_branches``

documentation/ref-manual/variables.rst

@@ -1463,6 +1463,11 @@ system and gives an overview of their function and contents.
       :term:`CCACHE_DISABLE` variable can be set to "1" in a recipe to disable
       `Ccache` support. This is useful when the recipe is known to not support it.
 
+   :term:`CCACHE_NATIVE_RECIPES_ALLOWED`
+      The :term:`CCACHE_NATIVE_RECIPES_ALLOWED` variable can be set in a
+      :term:`configuration file` to a list of native recipes that are allowed to
+      be optimized with the :ref:`ref-classes-ccache` class.
+
    :term:`CCACHE_TOP_DIR`
       When inheriting the :ref:`ref-classes-ccache` class, the
       :term:`CCACHE_TOP_DIR` variable can be set to the location of where
@@ -1638,7 +1643,7 @@ system and gives an overview of their function and contents.
          (set via :term:`RRECOMMENDS`) are always ignored.
 
    :term:`COMPONENTS_DIR`
-      Stores sysroot components for each recipe. The OpenEmbedded build
+      Stores sysroot components provided by each recipe. The OpenEmbedded build
       system uses :term:`COMPONENTS_DIR` when constructing recipe-specific
       sysroots for other recipes.
 
@@ -1727,15 +1732,52 @@ system and gives an overview of their function and contents.
       Where :term:`AUTOTOOLS_SCRIPT_PATH` is the location of the of the
       Autotools build system scripts, which defaults to :term:`S`.
 
+   :term:`CONFLICT_COMBINED_FEATURES`
+      When inheriting the :ref:`ref-classes-features_check`
+      class, this variable identifies combined features (see
+      :term:`COMBINED_FEATURES` for what this means) that would be in conflict
+      should the recipe be built. In other words, if the
+      :term:`CONFLICT_COMBINED_FEATURES` variable lists a feature that also
+      appears in :term:`COMBINED_FEATURES` within the current configuration,
+      then the recipe will be skipped, and if the build system attempts to build
+      the recipe then an error will be triggered.
+
    :term:`CONFLICT_DISTRO_FEATURES`
       When inheriting the :ref:`ref-classes-features_check`
-      class, this variable identifies distribution features that would be
+      class, this variable identifies distro features that would be
       in conflict should the recipe be built. In other words, if the
       :term:`CONFLICT_DISTRO_FEATURES` variable lists a feature that also
       appears in :term:`DISTRO_FEATURES` within the current configuration, then
       the recipe will be skipped, and if the build system attempts to build
       the recipe then an error will be triggered.
 
+   :term:`CONFLICT_IMAGE_FEATURES`
+      When inheriting the :ref:`ref-classes-features_check`
+      class, this variable identifies image features that would be
+      in conflict should the recipe be built. In other words, if the
+      :term:`CONFLICT_IMAGE_FEATURES` variable lists a feature that also
+      appears in :term:`IMAGE_FEATURES` within the current configuration, then
+      the recipe will be skipped, and if the build system attempts to build
+      the recipe then an error will be triggered.
+
+   :term:`CONFLICT_MACHINE_FEATURES`
+      When inheriting the :ref:`ref-classes-features_check`
+      class, this variable identifies machine features that would be
+      in conflict should the recipe be built. In other words, if the
+      :term:`CONFLICT_MACHINE_FEATURES` variable lists a feature that also
+      appears in :term:`MACHINE_FEATURES` within the current configuration, then
+      the recipe will be skipped, and if the build system attempts to build
+      the recipe then an error will be triggered.
+
+   :term:`CONFLICT_TUNE_FEATURES`
+      When inheriting the :ref:`ref-classes-features_check`
+      class, this variable identifies tune features that would be
+      in conflict should the recipe be built. In other words, if the
+      :term:`CONFLICT_TUNE_FEATURES` variable lists a feature that also
+      appears in :term:`TUNE_FEATURES` within the current configuration, then
+      the recipe will be skipped, and if the build system attempts to build
+      the recipe then an error will be triggered.
+
    :term:`CONVERSION_CMD`
       This variable is used for storing image conversion commands.
       Image conversion can convert an image into different objects like:
@@ -2144,7 +2186,7 @@ system and gives an overview of their function and contents.
 
       The practical effect of the previous assignment is that all files
       installed by bar will be available in the appropriate staging sysroot,
-      given by the :term:`STAGING_DIR* <STAGING_DIR>` variables, by the time
+      given by the :term:`STAGING_DIR* <STAGING_DIR_HOST>` variables, by the time
       the :ref:`ref-tasks-configure` task for ``foo`` runs. This mechanism is
       implemented by having :ref:`ref-tasks-configure` depend on the
       :ref:`ref-tasks-populate_sysroot` task of each recipe listed in
@@ -3522,7 +3564,7 @@ system and gives an overview of their function and contents.
          GROUPADD_PARAM:${PN} = "-g 880 group1; -g 890 group2"
 
       For information on the standard Linux shell command
-      ``groupadd``, see https://linux.die.net/man/8/groupadd.
+      ``groupadd``, see :manpage:`groupadd(8)`.
 
    :term:`GROUPMEMS_PARAM`
       When inheriting the :ref:`ref-classes-useradd` class,
@@ -3946,6 +3988,21 @@ system and gives an overview of their function and contents.
             or ``:prepend``. You must use the ``+=`` operator to add one or
             more options to the :term:`IMAGE_FSTYPES` variable.
 
+   :term:`IMAGE_FSTYPES_DEBUGFS`
+      The :term:`IMAGE_FSTYPES_DEBUGFS` holds a list of filesystem image types
+      to generate when the :term:`IMAGE_GEN_DEBUGFS` variable is set to "1". The
+      content of this variable is the same as what is supported by the
+      :term:`IMAGE_FSTYPES` variable.
+
+   :term:`IMAGE_GEN_DEBUGFS`
+      When set to "1" in an :ref:`ref-classes-image` recipe, the
+      :term:`OpenEmbedded Build System` will generate a companion image that
+      contains the debug symbols and source code for the packages installed on
+      the image. The :term:`OpenEmbedded Build System` does this by adding all
+      the available ``-dbg`` and ``-src`` packages available in the package
+      feed, which are automatically generated during
+      :ref:`overview-manual/concepts:Package Splitting`.
+
    :term:`IMAGE_INSTALL`
       Used by recipes to specify the packages to install into an image
       through the :ref:`ref-classes-image` class. Use the
@@ -5053,17 +5110,18 @@ system and gives an overview of their function and contents.
       information.
 
    :term:`KERNEL_IMAGE_MAXSIZE`
-      Specifies the maximum size of the kernel image file in kilobytes. If
+      Specifies the maximum allowable size of the kernel image file in kibibytes.
-      :term:`KERNEL_IMAGE_MAXSIZE` is set, the size of the kernel image file is
+      If this variable is set, the sizes of all of the kernel image files listed
-      checked against the set value during the
+      in :term:`KERNEL_IMAGETYPES` are checked against this value during the
-      :ref:`ref-tasks-sizecheck` task. The task fails if
+      :ref:`ref-tasks-sizecheck` task. That task will warn about any of the
-      the kernel image file is larger than the setting.
+      kernel images that exceed the maximum, and will fail only if all images
+      are too large.
 
       :term:`KERNEL_IMAGE_MAXSIZE` is useful for target devices that have a
       limited amount of space in which the kernel image must be stored.
 
       By default, this variable is not set, which means the size of the
-      kernel image is not checked.
+      kernel images are not checked.
 
    :term:`KERNEL_IMAGE_NAME`
       The base name of the kernel image. This variable is set in the
@@ -5073,6 +5131,13 @@ system and gives an overview of their function and contents.
 
       See :term:`KERNEL_ARTIFACT_NAME` for additional information.
 
+   :term:`KERNEL_IMAGE_STRIP_EXTRA_SECTIONS`
+      If this variable is set, it should contain the sections to be
+      stripped from the ``vmlinux`` image by the kernel-related
+      :ref:`ref-tasks-strip` task. As a simple example::
+
+         KERNEL_IMAGE_STRIP_EXTRA_SECTIONS = ".comment .note.* .debug"
+
    :term:`KERNEL_IMAGETYPE`
       The type of kernel to build for a device, usually set by the machine
       configuration files and defaults to "zImage". This variable is used
@@ -5349,7 +5414,8 @@ system and gives an overview of their function and contents.
       section in the Yocto Project Development Tasks Manual.
 
    :term:`LICENSE`
-      The list of source licenses for the recipe. Follow these rules:
+      This is a required field in an OpenEmbedded recipe file, and should
+      contain a list of source licenses for the recipe. Follow these rules:
 
       -  Do not use spaces within individual license names.
 
@@ -5389,6 +5455,12 @@ system and gives an overview of their function and contents.
          LICENSE:${PN} = "GPL-2.0.only"
          LICENSE:${PN}-doc = "GFDL-1.2"
 
+      .. note::
+
+         A recipe's :term:`LICENSE` value must be accompanied by an associated
+         :term:`LIC_FILES_CHKSUM` value, except in the special case where
+         the :term:`LICENSE` value is set to "CLOSED".
+
    :term:`LICENSE_CREATE_PACKAGE`
       Setting :term:`LICENSE_CREATE_PACKAGE` to "1" causes the OpenEmbedded
       build system to create an extra package (i.e.
@@ -5503,6 +5575,19 @@ system and gives an overview of their function and contents.
          $ uname -r
          3.7.0-rc8-custom
 
+   :term:`LOCALE_PATHS`
+      The :term:`LOCALE_PATHS` variable holds a whitespace separated list of
+      paths that are scanned to construct ``-locale`` packages during
+      :ref:`overview-manual/concepts:Package Splitting`. The list
+      contains ``${datadir}/locale`` by default.
+
+   :term:`LOCALE_UTF8_IS_DEFAULT`
+      If set, locale names are renamed such that those lacking an explicit
+      encoding (e.g. ``en_US``) will always be UTF-8, and non-UTF-8 encodings
+      are renamed to, e.g., ``en_US.ISO-8859-1``. Otherwise, the encoding is
+      specified by `Glibc`'s ``SUPPORTED`` file. This is not supported for
+      pre-compiled locales.
+
    :term:`LOG_DIR`
       Specifies the directory to which the OpenEmbedded build system writes
       overall log files. The default directory is ``${TMPDIR}/log``.
@@ -5774,6 +5859,9 @@ system and gives an overview of their function and contents.
       The default value for :term:`MIRRORS` is defined in the
       ``meta/classes-global/mirrors.bbclass`` file in the core metadata layer.
 
+      See the definition of this variable in the BitBake Manual for more
+      details: :term:`bitbake:MIRRORS`.
+
    :term:`MLPREFIX`
       Specifies a prefix has been added to :term:`PN` to create a
       special version of a recipe or package (i.e. a Multilib version). The
@@ -5818,7 +5906,7 @@ system and gives an overview of their function and contents.
       See the :term:`KERNEL_MODULE_AUTOLOAD` variable for more information.
 
    :term:`module_conf`
-      Specifies `modprobe.d <https://linux.die.net/man/5/modprobe.d>`__
+      Specifies :manpage:`modprobe.d(5)`
       syntax lines for inclusion in the ``/etc/modprobe.d/modname.conf``
       file.
 
@@ -6346,8 +6434,8 @@ system and gives an overview of their function and contents.
       an iterative development process to remove specific components from a
       system.
 
-      This variable is supported only when using the IPK and RPM
+      This variable is supported by all of the RPM, DEB and IPK
-      packaging backends. DEB is not supported.
+      packaging backends.
 
       See the :term:`NO_RECOMMENDATIONS` and the
       :term:`BAD_RECOMMENDATIONS` variables for
@@ -6491,6 +6579,53 @@ system and gives an overview of their function and contents.
       install, the build system does not generate an error. This variable
       is generally not user-defined.
 
+   :term:`PACKAGE_NO_LOCALE`
+      The :term:`PACKAGE_NO_LOCALE` variable can be set to "1" to prevent the
+      :term:`OpenEmbedded Build System` from splitting the locales found in the
+      :term:`PKGD` directory into split packages.
+
+      For example, the ``quilt`` recipe automatically produces split packages
+      after the :ref:`ref-tasks-package` task is run. Taking a look inside the
+      :term:`WORKDIR` directory of ``quilt``:
+
+      .. code-block:: console
+
+         $ ls -1 packages-split/
+         guards
+         guards-doc
+         quilt
+         quilt-dbg
+         quilt-dev
+         quilt-doc
+         quilt-locale-de
+         quilt-locale-fr
+         quilt-locale-ja
+         quilt-locale-ru
+         quilt-ptest
+         quilt-src
+         quilt-staticdev
+
+      We can see the ``quilt-locale-*`` packages were automatically generated.
+      Setting :term:`PACKAGE_NO_LOCALE` to "1" would produce the following
+      packages:
+
+      .. code-block:: console
+
+         $ ls -1 packages-split/
+         guards
+         guards-doc
+         quilt
+         quilt-dbg
+         quilt-dev
+         quilt-doc
+         quilt-locale
+         quilt-ptest
+         quilt-src
+         quilt-staticdev
+
+      The ``quilt-locale`` package contains the merged content of the previous
+      ``quilt-locale-*`` packages.
+
    :term:`PACKAGE_PREPROCESS_FUNCS`
       Specifies a list of functions run to pre-process the
       :term:`PKGD` directory prior to splitting the files out
@@ -6638,6 +6773,12 @@ system and gives an overview of their function and contents.
       :ref:`ref-tasks-configure` task, then you need to use
       :term:`PACKAGECONFIG_CONFARGS` appropriately.
 
+   :term:`PACKAGEFUNCS`
+      The :term:`PACKAGEFUNCS` variable holds a list of functions which are
+      executed to process metadata based on split packages found in the
+      :term:`PKGDEST` directory. These functions are executed in the
+      :ref:`ref-classes-package` class in the order found in the list.
+
    :term:`PACKAGEGROUP_DISABLE_COMPLEMENTARY`
       For recipes inheriting the :ref:`ref-classes-packagegroup` class, setting
       :term:`PACKAGEGROUP_DISABLE_COMPLEMENTARY` to "1" specifies that the
@@ -6841,19 +6982,17 @@ system and gives an overview of their function and contents.
       Points to a shared, global-state directory that holds data generated
       during the packaging process. During the packaging process, the
       :ref:`ref-tasks-packagedata` task packages data
-      for each recipe and installs it into this temporary, shared area.
+      for each recipe and installs it into this shared area.
       This directory defaults to the following, which you should not
       change::
 
-         ${STAGING_DIR_HOST}/pkgdata
+         ${TMPDIR}/pkgdata/${MACHINE}
 
       For examples of how this data is used, see the
       ":ref:`overview-manual/concepts:automatically added runtime dependencies`"
       section in the Yocto Project Overview and Concepts Manual and the
       ":ref:`dev-manual/debugging:viewing package information with ``oe-pkgdata-util```"
-      section in the Yocto Project Development Tasks Manual. For more
+      section in the Yocto Project Development Tasks Manual.
-      information on the shared, global-state directory, see
-      :term:`STAGING_DIR_HOST`.
 
    :term:`PKGDEST`
       Points to the parent directory for files to be packaged after they
@@ -7093,7 +7232,8 @@ system and gives an overview of their function and contents.
              git://.*/.* &YOCTO_DL_URL;/mirror/sources/ \
              ftp://.*/.* &YOCTO_DL_URL;/mirror/sources/ \
              http://.*/.* &YOCTO_DL_URL;/mirror/sources/ \
-             https://.*/.* &YOCTO_DL_URL;/mirror/sources/"
+             https://.*/.* &YOCTO_DL_URL;/mirror/sources/ \
+         "
 
       These changes cause the
       build system to intercept Git, FTP, HTTP, and HTTPS requests and
@@ -7101,6 +7241,9 @@ system and gives an overview of their function and contents.
       ``file://`` URLs to point to local directories or network shares as
       well.
 
+      See the definition of this variable in the BitBake Manual for more
+      details: :term:`bitbake:PREMIRRORS`.
+
    :term:`PRIORITY`
       Indicates the importance of a package.
 
@@ -7270,6 +7413,167 @@ system and gives an overview of their function and contents.
 
          QA_EMPTY_DIRS_RECOMMENDATION:/dev = "but all devices must be created at runtime"
 
+   :term:`QB_CMDLINE_IP_SLIRP`
+
+      If :term:`QB_NETWORK_DEVICE` adds more than one network interface to QEMU,
+      usually the ``ip=`` Linux kernel command line argument needs to be changed
+      accordingly. The :term:`QB_CMDLINE_IP_SLIRP` variable allows controlling
+      this value. See the Linux kernel documentation for more details:
+      https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt.
+
+   :term:`QB_CMDLINE_IP_TAP`
+
+      This variable is similar to the :term:`QB_CMDLINE_IP_SLIRP` variable.
+
+      Use as follows::
+
+         QB_CMDLINE_IP_TAP = "ip=192.168.7.@CLIENT@::192.168.7.@GATEWAY@:255.255.255.0::eth0"
+
+      Since the tap interface requires static IP configuration, ``runqemu``
+      replaces the ``@CLIENT@`` and ``@GATEWAY@`` place holders by the IP and
+      the gateway address of the QEMU guest.
+
+   :term:`QB_DEFAULT_BIOS`
+      The :term:`QB_DEFAULT_BIOS` variable can be used to provide a default
+      value for the path of a file located in :term:`DEPLOY_DIR_IMAGE` and
+      used by ``runqemu`` to specify the `-bios <https://www.qemu.org/docs/master/system/invocation.html#hxtool-8>`__
+      option of QEMU. For example, this variable can be set as follows to
+      emulate U-Boot for the :oecore_path:`qemuarm64 <meta/conf/machine/qemuarm64.conf>`
+      machine::
+
+         QB_DEFAULT_BIOS = "u-boot.bin"
+
+      The above example makes the assumption the U-Boot recipe was built
+      and that the ``u-boot.bin`` is deployed in the :term:`DEPLOY_DIR_IMAGE`
+      directory.
+
+      .. note::
+
+         When using ``runqemu``, the ``BIOS`` environment variable takes
+         precedence over this variable.
+
+   :term:`QB_DEFAULT_FSTYPE`
+
+      The :term:`QB_DEFAULT_FSTYPE` variable controls the default filesystem
+      type to boot. It is represented as the file extension of one of the root
+      filesystem image extension found in :term:`DEPLOY_DIR_IMAGE`. For example:
+      ``ext4.zst``.
+
+   :term:`QB_DEFAULT_KERNEL`
+
+      When using ``runqemu``, the :term:`QB_DEFAULT_KERNEL` variable controls
+      the default Linux kernel image to boot, found in :term:`DEPLOY_DIR_IMAGE`. For
+      example: ``bzImage``.
+
+   :term:`QB_DRIVE_TYPE`
+
+      When using ``runqemu``, the :term:`QB_DRIVE_TYPE` variable specifies the
+      type of drive to emulate when starting the emulated machine.
+      Valid values are:
+
+      -  ``/dev/hd``: emulates an IDE drive.
+      -  ``/dev/mmcblk``: emulates an SD Card.
+      -  ``/dev/sd``: emulates an SCSI drive.
+      -  ``/dev/vd``: emulates a VirtIO drive.
+      -  ``/dev/vdb``: emulates a block VirtIO drive.
+
+   :term:`QB_GRAPHICS`
+
+      When using ``runqemu``, the :term:`QB_GRAPHICS` variable controls the QEMU
+      video card type to emulate. For example: ``-vga std``.
+
+      This value is appended to the argument list when running ``qemu``.
+
+   :term:`QB_KERNEL_CMDLINE_APPEND`
+
+      The :term:`QB_KERNEL_CMDLINE_APPEND` variable controls the options passed
+      to the Linux kernel's ``-append`` QEMU options, which controls the Linux kernel
+      command-line.
+
+      For example::
+
+         QB_KERNEL_CMDLINE_APPEND = "console=ttyS0"
+
+   :term:`QB_MEM`
+
+      The :term:`QB_MEM` variable controls the amount of memory allocated to the
+      emulated machine. Specify as follows::
+
+         QB_MEM = "-m 512"
+
+   :term:`QB_NETWORK_DEVICE`
+
+      When using ``runqemu``, the :term:`QB_NETWORK_DEVICE` variable controls
+      the network device instantiated by QEMU. This value needs to be compatible
+      with the :term:`QB_TAP_OPT` variable.
+
+      Example::
+
+         QB_NETWORK_DEVICE = "-device virtio-net-pci,netdev=net0,mac=@MAC@"
+
+      ``runqemu`` replaces ``@MAC@`` with a predefined mac address.
+
+   :term:`QB_NFSROOTFS_EXTRA_OPT`
+
+      When using ``runqemu``, the :term:`QB_NFSROOTFS_EXTRA_OPT` variable
+      controls extra options to be appended to the NFS rootfs options in the
+      Linux kernel command-line.
+
+      For example::
+
+         QB_NFSROOTFS_EXTRA_OPT = "wsize=4096,rsize=4096"
+
+   :term:`QB_OPT_APPEND`
+
+      When using ``runqemu``, the :term:`QB_OPT_APPEND` variable controls
+      general options to append to QEMU when starting.
+
+   :term:`QB_RNG`
+
+      When using ``runqemu``, the :term:`QB_RNG` variable controls
+      pass-through for host random number generator, it can speedup boot
+      in system mode, where system is experiencing entropy starvation.
+
+      For example::
+
+         QB_RNG = "-object rng-random,filename=/dev/urandom,id=rng0 -device virtio-rng-pci,rng=rng0"
+
+   :term:`QB_ROOTFS_EXTRA_OPT`
+
+      When using ``runqemu``, the :term:`QB_ROOTFS_EXTRA_OPT` variable controls
+      extra options to be appended to the rootfs device options.
+
+   :term:`QB_SERIAL_OPT`
+
+      When using ``runqemu``, the :term:`QB_SERIAL_OPT` variable controls the
+      serial port option.
+
+      For example::
+
+         QB_SERIAL_OPT = "-serial mon:stdio"
+
+   :term:`QB_SMP`
+
+      When using ``runqemu``, the :term:`QB_SMP` variable controls
+      amount of CPU cores made availalble inside the QEMU guest, each mapped to
+      a thread on the host.
+
+      For example::
+
+         QB_SMP = "-smp 8".
+
+   :term:`QB_TAP_OPT`
+
+      When using ``runqemu``, the :term:`QB_TAP_OPT` variable controls
+      the network option for "tap" mode.
+
+      For example::
+
+         QB_TAP_OPT = "-netdev tap,id=net0,ifname=@TAP@,script=no,downscript=no"
+
+      Note that ``runqemu`` will replace ``@TAP@`` with the tap interface in
+      use, such as ``tap0``, ``tap1``, etc.
+
    :term:`RANLIB`
       The minimal command and arguments to run :manpage:`ranlib <ranlib(1)>`.
 
@@ -7435,13 +7739,13 @@ system and gives an overview of their function and contents.
       section.
 
    :term:`RECIPE_SYSROOT`
-      This variable points to the directory that holds all files populated from
+      This variable points to the directory populated with all files provided by
       recipes specified in :term:`DEPENDS`. As the name indicates,
-      think of this variable as a custom root (``/``) for the recipe that will be
+      think of this variable as a custom root (``/``) for the recipe, that will be
       used by the compiler in order to find headers and other files needed to complete
       its job.
 
-      This variable is related to :term:`STAGING_DIR_HOST` or :term:`STAGING_DIR_TARGET`
+      This variable is used to define :term:`STAGING_DIR_HOST` or :term:`STAGING_DIR_TARGET`
       according to the type of the recipe and the build target.
 
       To better understand this variable, consider the following examples:
@@ -7455,11 +7759,11 @@ system and gives an overview of their function and contents.
       Do not modify it.
 
    :term:`RECIPE_SYSROOT_NATIVE`
-      This is similar to :term:`RECIPE_SYSROOT` but the populated files are from
+      This is similar to :term:`RECIPE_SYSROOT` but files in it are provided by
-      ``-native`` recipes. This allows a recipe built for the target machine to
+      native recipes. This allows a recipe built for the target machine to
-      use ``native`` tools.
+      use native tools.
 
-      This variable is related to :term:`STAGING_DIR_NATIVE`.
+      This variable is used to define :term:`STAGING_DIR_NATIVE`.
 
       The default value is ``"${WORKDIR}/recipe-sysroot-native"``.
       Do not modify it.
@@ -7529,6 +7833,12 @@ system and gives an overview of their function and contents.
       specifies a list of recipes whose work directories should not be removed.
       See the ":ref:`ref-classes-rm-work`" section for more details.
 
+   :term:`RM_WORK_EXCLUDE_ITEMS`
+      With :ref:`ref-classes-rm-work` enabled, this variable specifies
+      a list of files or folders --- relative to the recipe's :term:`WORKDIR` ---
+      to be preserved.
+      See the ":ref:`ref-classes-rm-work`" section for more details.
+
    :term:`ROOT_HOME`
       Defines the root home directory. By default, this directory is set as
       follows in the BitBake configuration file::
@@ -7720,7 +8030,9 @@ system and gives an overview of their function and contents.
    :term:`RSUGGESTS`
       A list of additional packages that you can suggest for installation
       by the package manager at the time a package is installed. Not all
-      package managers support this functionality.
+      package managers support this functionality. This feature takes effect
+      only when the package manager is being used to install packages on
+      the target system from a package feed.
 
       As with all package-controlling variables, you must always use this
       variable in conjunction with a package name override. Here is an
@@ -7728,6 +8040,10 @@ system and gives an overview of their function and contents.
 
          RSUGGESTS:${PN} = "useful_package another_package"
 
+      For more information on package management, see the
+      :ref:`dev-manual/packages:Using Runtime Package Management` section
+      of the Yocto Project Development Tasks Manual.
+
    :term:`RUST_CHANNEL`
       Specifies which version of Rust to build - "stable", "beta" or "nightly".
       The default value is "stable". Set this at your own risk, as values other
@@ -8893,8 +9209,7 @@ system and gives an overview of their function and contents.
       directory for the build host.
 
    :term:`STAGING_DIR`
-      Helps construct the ``recipe-sysroot*`` directories, which are used
+      Used for constructing directory trees used during staging.
-      during packaging.
 
       For information on how staging for recipe-specific sysroots occurs,
       see the :ref:`ref-tasks-populate_sysroot`
@@ -8914,31 +9229,31 @@ system and gives an overview of their function and contents.
          those files into the sysroot.
 
    :term:`STAGING_DIR_HOST`
-      Specifies the path to the sysroot directory for the system on which
+      Specifies the path to the recipe's input sysroot directory, populated with files
-      the component is built to run (the system that hosts the component).
+      for the system on which the component is built to run
-      For most recipes, this sysroot is the one in which that recipe's
+      (the system that hosts the component).
-      :ref:`ref-tasks-populate_sysroot` task copies
+      For most recipes, this sysroot is populated by their
-      files. Exceptions include ``-native`` recipes, where the
+      :ref:`ref-tasks-populate_sysroot` task (when sharing files
-      :ref:`ref-tasks-populate_sysroot` task instead uses
+      between recipes). Exceptions include native recipes, for which the files from
-      :term:`STAGING_DIR_NATIVE`. Depending on
+      :ref:`ref-tasks-populate_sysroot` task are instead copied to
-      the type of recipe and the build target, :term:`STAGING_DIR_HOST` can
+      :term:`STAGING_DIR_NATIVE`. Depending on the type of recipe and the build target,
-      have the following values:
+      :term:`STAGING_DIR_HOST` can have the following values:
 
       -  For recipes building for the target machine, the value is
-         "${:term:`STAGING_DIR`}/${:term:`MACHINE`}".
+         ``"${RECIPE_SYSROOT}"``, check :term:`RECIPE_SYSROOT`.
 
-      -  For native recipes building for the build host, the value is empty
+      -  For native recipes (building for the :term:`build host`), the value is empty
-         given the assumption that when building for the build host, the
+         given the assumption that when building for the :term:`build host`, the
-         build host's own directories should be used.
+         :term:`build host`'s own directories should be used.
 
          .. note::
 
-            ``-native`` recipes are not installed into host paths like such
+            Native recipe files are not installed into host paths such
-            as ``/usr``. Rather, these recipes are installed into
+            as ``/usr``. Rather, such files are installed into
-            :term:`STAGING_DIR_NATIVE`. When compiling ``-native`` recipes,
+            :term:`STAGING_DIR_NATIVE`. When compiling native recipes,
             standard build environment variables such as
             :term:`CPPFLAGS` and
-            :term:`CFLAGS` are set up so that both host paths
+            :term:`CFLAGS` are set up so that both :term:`build host`'s paths
             and :term:`STAGING_DIR_NATIVE` are searched for libraries and
             headers using, for example, GCC's ``-isystem`` option.
 
@@ -8946,16 +9261,15 @@ system and gives an overview of their function and contents.
             should be viewed as input variables by tasks such as
             :ref:`ref-tasks-configure`,
             :ref:`ref-tasks-compile`, and
-            :ref:`ref-tasks-install`. Having the real system
+            :ref:`ref-tasks-install`. Having the real system root
-            root correspond to :term:`STAGING_DIR_HOST` makes conceptual sense
+            (the :term:`build host`'s root) play the role of :term:`STAGING_DIR_HOST`
-            for ``-native`` recipes, as they make use of host headers and
+            makes conceptual sense for native recipes, as they make use
-            libraries.
+            of the :term:`build host`'s headers and libraries.
-
-      Check :term:`RECIPE_SYSROOT` and :term:`RECIPE_SYSROOT_NATIVE`.
 
    :term:`STAGING_DIR_NATIVE`
-      Specifies the path to the sysroot directory used when building
+      Specifies the path to the recipe's input sysroot directory, populated with
-      components that run on the build host itself.
+      files provided by native recipes (recipes building components that
+      run on the :term:`build host` itself).
 
       The default value is ``"${RECIPE_SYSROOT_NATIVE}"``,
       check :term:`RECIPE_SYSROOT_NATIVE`.
@@ -9806,7 +10120,8 @@ system and gives an overview of their function and contents.
       For background information on cross-development toolchains in the
       Yocto Project development environment, see the
       ":ref:`sdk-manual/intro:the cross-development toolchain`"
-      section in the Yocto Project Overview and Concepts Manual. For
+      section in the Yocto Project Application Development and Software
+      Development Kits (SDK/eSDK) Manual. For
       information on setting up a cross-development environment, see the
       :doc:`/sdk-manual/index` manual.
 
@@ -9854,7 +10169,8 @@ system and gives an overview of their function and contents.
       For background information on cross-development toolchains in the
       Yocto Project development environment, see the
       ":ref:`sdk-manual/intro:the cross-development toolchain`"
-      section in the Yocto Project Overview and Concepts Manual. For
+      section in the Yocto Project Application Development and Software
+      Development Kits (SDK/eSDK) Manual. For
       information on setting up a cross-development environment, see the
       :doc:`/sdk-manual/index` manual.
 
@@ -10479,7 +10795,7 @@ system and gives an overview of their function and contents.
 
       For information on the
       standard Linux shell command ``useradd``, see
-      https://linux.die.net/man/8/useradd.
+      :manpage:`useradd(8)`.
 
    :term:`USERADD_UID_TABLES`
       Specifies a password file to use for obtaining static user

documentation/sdk-manual/appendix-obtain.rst

@@ -96,8 +96,7 @@ build the SDK installer. Follow these steps:
 #. *Set Up the Build Environment:* Be sure you are set up to use BitBake
    in a shell. See the ":ref:`dev-manual/start:preparing the build host`" section
    in the Yocto Project Development Tasks Manual for information on how
-   to get a build host ready that is either a native Linux machine or a
+   to get a :term:`build host` ready.
-   machine that uses CROPS.
 
 #. *Clone the ``poky`` Repository:* You need to have a local copy of the
    Yocto Project :term:`Source Directory`

documentation/security-reference/security-team.rst

@@ -56,31 +56,21 @@ 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
+for contacting an appropriate CVE Numbering Authority (CNA), such as `Mitre
-the CVE record published.
+<https://cveform.mitre.org/>`__, to get a CVE number assigned and the CVE
+record published.
+
+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.
 
 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
@@ -90,6 +80,28 @@ 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.
 
+Handling multi-project embargoes
+--------------------------------
+
+In rare cases, a severe security issue affects multiple projects. This might be
+numerous projects having a similar issue because of design, coding pattern, or
+reuse of the same code (an example of this situation is :cve_nist:`2023-44487`
+where multiple web servers share a design weakness). It might also be a
+high-profile issue in a commonly used library (like OpenSSL). In such cases,
+the project, learning first about the issue, might decide to notify other
+affected projects confidentially so that they come up with a synchronized fix.
+It might also be the affected project informing major distributions to roll out
+the update simultaneously.
+
+Such notifications happen over confidential, non-public means. Typically, the
+project initiating this "embargo" directly notifies a selected number of people
+from each project, including a subset of the security team. When Yocto Project
+is a part of such a notified group, developers prepare fixes on separate
+infrastructure and test it. They might also include additional developers and
+domain experts who can help with the fix and eventual regressions. When the
+embargo is lifted, they send a patch to the relevant public list, and the usual
+review process starts.
+
 Security Team Members
 =====================
 
@@ -105,6 +117,6 @@ information in the subject line.
 
 -  Richard Purdie: <richard.purdie [at] linuxfoundation [dot] 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>`__
+-  Marta Rybczynska: <marta DOT rybczynska [at] ygreky [dot] com> `Public key <https://keys.openpgp.org/search?q=marta.rybczynska@ygreky.com>`__
 
--  Steve Sakoman: <steve [at] sakoman [dot] com> `Public key <https://keys.openpgp.org/search?q=steve%40sakoman.com>`__
+-  Paul Barker <paul [at] pbarker [dot] dev> `Public key <https://keys.openpgp.org/search?q=paul@pbarker.dev>`__

documentation/sphinx-static/theme_overrides.css

@@ -99,14 +99,23 @@ em {
 [alt='Permalink'] { color: #eee; }
 [alt='Permalink']:hover { color: black; }
 
-@media screen {
+.literal-block {
-    /* content column
+    background: #f8f8f8;
-     *
+}
-     * RTD theme's default is 800px as max width for the content, but we have
-     * tables with tons of columns, which need the full width of the view-port.
-     */
 
-    .wy-nav-content{max-width: none; }
+section#welcome-to-the-yocto-project-documentation p.caption {
+   display: none;
+}
+
+@media screen {
+    .wy-nav-content {
+       max-width: 1000px;
+       background: #fcfcfc;
+    }
+
+    .wy-nav-content-wrap {
+       background: #efefef;
+    }
 
     /* inline literal: drop the borderbox, padding and red color */
     code, .rst-content tt, .rst-content code {

documentation/test-manual/intro.rst

@@ -141,7 +141,7 @@ the following types of tests:
    built by the OpenEmbedded build system on the target machine. See the
    :ref:`Testing Packages With
    ptest <test-manual/ptest:Testing Packages With ptest>` section
-   in the Yocto Project Development Tasks Manual and the
+   in the Yocto Project Test Environment Manual and the
    ":yocto_wiki:`Ptest </Ptest>`" Wiki page for more
    information on Ptest.
 

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

@@ -9,10 +9,10 @@ Transitioning to a custom environment for systems development
 .. note::
 
    So you've finished the :doc:`brief-yoctoprojectqs/index` and
-   glanced over the document :doc:`what-i-wish-id-known`, the latter contains
+   glanced over the document :doc:`what-i-wish-id-known`, the latter containing
    important information learned from other users. You're well prepared. But
    now, as you are starting your own project, it isn't exactly straightforward what
-   to do. And, the documentation is daunting. We've put together a few hints to
+   to do, and the documentation is daunting. We've put together a few hints to
    get you started.
 
 #. **Make a list of the processor, target board, technologies, and capabilities
@@ -23,7 +23,7 @@ Transitioning to a custom environment for systems development
 #. **Set up your board support**.
    Even if you're using custom hardware, it might be easier to start with an
    existing target board that uses the same processor or at least the same
-   architecture as your custom hardware. Knowing the board already has a
+   architecture as your custom hardware. Knowing that the board already has a
    functioning Board Support Package (BSP) within the project makes it easier
    for you to get comfortable with project concepts.
 
@@ -34,19 +34,19 @@ Transitioning to a custom environment for systems development
    target board. The Yocto Project layer index BSPs are regularly validated. The
    best place to get your first BSP is from your silicon manufacturer or board
    vendor – they can point you to their most qualified efforts. In general, for
-   Intel silicon use meta-intel, for Texas Instruments use meta-ti, and so
+   Intel silicon use ``meta-intel``, for Texas Instruments use ``meta-ti``, and so
    forth. Choose a BSP that has been tested with the same Yocto Project release
    that you've downloaded. Be aware that some BSPs may not be immediately
    supported on the very latest release, but they will be eventually.
 
    You might want to start with the build specification that Poky provides
-   (which is reference embedded distribution) and then add your newly chosen
+   (which is reference embedded distribution) and then add your newly-chosen
    layers to that. Here is the information :ref:`about adding layers
    <dev-manual/layers:Understanding and Creating Layers>`.
 
 #. **Based on the layers you've chosen, make needed changes in your
    configuration**.
-   For instance, you've chosen a machine type and added in the corresponding BSP
+   For instance, assume you've chosen a machine type and added in the corresponding BSP
    layer. You'll then need to change the value of the :term:`MACHINE` variable in your
    configuration file (build/local.conf) to point to that same machine
    type. There could be other layer-specific settings you need to change as
@@ -68,8 +68,8 @@ Transitioning to a custom environment for systems development
    bsp layer using the \`\`bitbake-layers\`\` script>`. For example, given a
    64-bit x86-based machine, copy the conf/intel-corei7-64 definition and give
    the machine a relevant name (think board name, not product name). Make sure
-   the layer configuration is dependent on the meta-intel layer (or at least,
+   the layer configuration is dependent on the ``meta-intel`` layer (or at least,
-   meta-intel remains in your bblayers.conf). Now you can put your custom BSP
+   ``meta-intel`` remains in your ``bblayers.conf`` file). Now you can put your custom BSP
    settings into your layer and you can re-use it for different applications.
 
 #. **Write your own recipe to build additional software support that isn't

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

@@ -9,7 +9,7 @@ What I wish I'd known about Yocto Project
 .. note::
 
    Before reading further, make sure you've taken a look at the
-   :yocto_home:`Software Overview</software-overview>` page which presents the
+   :yocto_home:`Technical Overview</development/technical-overview>` page which presents the
    definitions for many of the terms referenced here. Also, know that some of the
    information here won't make sense now, but as you start developing, it is the
    information you'll want to keep close at hand. These are best known methods for
@@ -22,8 +22,8 @@ known before embarking on their first build with Yocto Project. Feel free to
 contact us with other suggestions.
 
 #. **Use Git, not the tarball download:**
-   If you use git the software will be automatically updated with bug updates
+   If you use Git, the software will be automatically updated with bug updates
-   because of how git works. If you download the tarball instead, you will need
+   because of how Git works. If you download the tarball instead, you will need
    to be responsible for your own updates.
 
 #. **Get to know the layer index:**
@@ -165,19 +165,19 @@ contact us with other suggestions.
 
    * deal with corporate proxies
    * add a package to an image
-   * understand the difference between a recipe and package
+   * understand the difference between a recipe and a package
-   * build a package by itself and why that's useful
+   * build a package by itself and understand why that's useful
    * find out what packages are created by a recipe
    * find out what files are in a package
    * find out what files are in an image
-   * add an ssh server to an image (enable transferring of files to target)
+   * add an SSH server to an image (enable transferring of files to target)
    * know the anatomy of a recipe
    * know how to create and use layers
    * find recipes (with the :oe_layerindex:`OpenEmbedded Layer index <>`)
-   * understand difference between machine and distro settings
+   * understand the difference between MACHINE and DISTRO settings
    * find and use the right BSP (machine) for your hardware
-   * find examples of distro features and know where to set them
+   * find examples of DISTRO features and know where to set them
-   * understanding the task pipeline and executing individual tasks
+   * understand the task pipeline and how to execute individual tasks
    * understand devtool and how it simplifies your workflow
    * improve build speeds with shared downloads and shared state cache
    * generate and understand a dependency graph

meta-poky/conf/distro/poky.conf

@@ -1,6 +1,6 @@
 DISTRO = "poky"
 DISTRO_NAME = "Poky (Yocto Project Reference Distro)"
-DISTRO_VERSION = "5.0.17"
+DISTRO_VERSION = "5.0.20"
 DISTRO_CODENAME = "scarthgap"
 SDK_VENDOR = "-pokysdk"
 SDK_VERSION = "${@d.getVar('DISTRO_VERSION').replace('snapshot-${METADATA_REVISION}', 'snapshot')}"
@@ -43,8 +43,8 @@ SANITY_TESTED_DISTROS ?= " \
             fedora-39 \n \
             fedora-40 \n \
             fedora-41 \n \
-            centosstream-8 \n \
+            centos-8 \n \
-            centosstream-9 \n \
+            centos-9 \n \
             debian-11 \n \
             debian-12 \n \
             opensuseleap-15.4 \n \

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

@@ -11,7 +11,7 @@ SRCREV = "1a3e1343761b30750bed70e0fd688f6d3c7b3717"
 PV = "0.1+git"
 PR = "r2"
 
-SRC_URI = "git://git.yoctoproject.org/dbus-wait;branch=master"
+SRC_URI = "git://git.yoctoproject.org/dbus-wait;branch=master;protocol=https"
 UPSTREAM_CHECK_COMMITS = "1"
 RECIPE_NO_UPDATE_REASON = "This recipe is used to test devtool upgrade feature"
 

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

@@ -10,7 +10,7 @@ DEPENDS = "dbus"
 SRCREV = "6cc6077a36fe2648a5f993fe7c16c9632f946517"
 PV = "0.1+git"
 
-SRC_URI = "git://git.yoctoproject.org/dbus-wait;branch=master"
+SRC_URI = "git://git.yoctoproject.org/dbus-wait;branch=master;protocol=https"
 UPSTREAM_CHECK_COMMITS = "1"
 RECIPE_NO_UPDATE_REASON = "This recipe is used to test devtool upgrade feature"
 

meta-selftest/recipes-test/git-submodule-test/git-submodule-test.bb

@@ -7,8 +7,8 @@ INHIBIT_DEFAULT_DEPS = "1"
 
 UPSTREAM_VERSION_UNKNOWN = "1"
 
-SRC_URI = "gitsm://git.yoctoproject.org/git-submodule-test;branch=master"
+SRC_URI = "gitsm://git.yoctoproject.org/git-submodule-test;branch=master;protocol=https"
-SRCREV = "a2885dd7d25380d23627e7544b7bbb55014b16ee"
+SRCREV = "f280847494763cdcf71197557a81ba7d8a6bce42"
 
 S = "${WORKDIR}/git"
 

meta-selftest/recipes-test/gitrepotest/gitrepotest.bb

@@ -7,7 +7,7 @@ INHIBIT_DEFAULT_DEPS = "1"
 
 PATCHTOOL="git"
 
-SRC_URI = "git://git.yoctoproject.org/git/matchbox-panel-2;branch=master;protocol=https \
+SRC_URI = "git://git.yoctoproject.org/matchbox-panel-2;branch=master;protocol=https \
            file://0001-testpatch.patch \
           "
 

meta-selftest/recipes-test/gitunpackoffline/gitunpackoffline.inc

@@ -1,5 +1,5 @@
 SUMMARY = "Test recipe for fetching git submodules"
-HOMEPAGE = "https://git.yoctoproject.org/git/matchbox-panel-2"
+HOMEPAGE = "https://git.yoctoproject.org/matchbox-panel-2"
 LICENSE = "GPL-2.0-or-later"
 LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f"
 
@@ -8,7 +8,7 @@ INHIBIT_DEFAULT_DEPS = "1"
 TAGVALUE = "2.10"
 
 # Deliberately have a tag which has to be resolved but ensure do_unpack doesn't access the network again.
-SRC_URI = "git://git.yoctoproject.org/git/matchbox-panel-2;branch=master;protocol=https"
+SRC_URI = "git://git.yoctoproject.org/matchbox-panel-2;branch=master;protocol=https"
 SRC_URI:append:gitunpack-enable-recipe = ";tag=${TAGVALUE}"
 SRCREV = "f82ca3f42510fb3ef10f598b393eb373a2c34ca7"
 SRCREV:gitunpack-enable-recipe = ""

meta/classes-global/base.bbclass

@@ -111,7 +111,11 @@ def setup_hosttools_dir(dest, toolsvar, d, fatal=True):
             # clean up dead symlink
             if os.path.islink(desttool):
                 os.unlink(desttool)
-            srctool = bb.utils.which(path, tool, executable=True)
+
+            # Prefer gnu-prefixed binaries, if available
+            srctool = (bb.utils.which(path, "gnu" + tool, executable=True) or
+                       bb.utils.which(path, tool, executable=True))
+
             # gcc/g++ may link to ccache on some hosts, e.g.,
             # /usr/local/bin/ccache/gcc -> /usr/bin/ccache, then which(gcc)
             # would return /usr/local/bin/ccache/gcc, but what we need is

meta/classes-global/package.bbclass

@@ -468,8 +468,7 @@ PACKAGEFUNCS += " \
                 package_do_shlibs \
                 package_do_pkgconfig \
                 read_shlibdeps \
-                package_depchains \
+                package_depchains"
-                emit_pkgdata"
 
 python do_package () {
     # Change the following version to cause sstate to invalidate the package
@@ -561,9 +560,13 @@ python do_package () {
             for file in files:
                 pkgfiles[pkg].append(walkroot + os.sep + file)
 
+
+    # We want emit_pkgdata to run last, after everything
     for f in (d.getVar('PACKAGEFUNCS') or '').split():
         bb.build.exec_func(f, d)
 
+    bb.build.exec_func("emit_pkgdata", d)
+
     oe.qa.exit_if_errors(d)
 }
 

meta/classes-recipe/cargo-update-recipe-crates.bbclass

@@ -36,7 +36,8 @@ def get_crates(f):
     crates_candidates = list(filter(lambda c: 'crates.io' in c.get('source', ''), crates['package']))
 
     if not crates_candidates:
-        raise ValueError("Unable to find any candidate crates that use crates.io")
+        print("WARNING: Unable to find any candidate crates that use crates.io")
+        return None
 
     # Update crates uri and their checksum, to avoid name clashing on the checksum
     # we need to rename crates with name and version to have a unique key
@@ -63,14 +64,11 @@ for root, dirs, files in os.walk('${CARGO_LOCK_SRC_DIR}'):
         continue
     for file in files:
         if file == 'Cargo.lock':
-            try:
+            cargo_lock_path = os.path.join(root, file)
-                cargo_lock_path = os.path.join(root, file)
+            c = get_crates(cargo_lock_path)
-                crates += get_crates(os.path.join(root, file))
+            if c is not None:
-            except Exception as e:
+                crates += c
-                raise ValueError("Cannot parse '%s'" % cargo_lock_path) from e
+if crates is None:
-            else:
-                found = True
-if not found:
     raise ValueError("Unable to find any Cargo.lock in ${CARGO_LOCK_SRC_DIR}")
 open("${TARGET_FILE}", 'w').write(crates)
 EOF

meta/classes-recipe/create-spdx-image-3.0.bbclass

@@ -71,7 +71,7 @@ python do_create_image_sbom_spdx() {
 }
 addtask do_create_image_sbom_spdx after do_create_rootfs_spdx do_create_image_spdx before do_build
 SSTATETASKS += "do_create_image_sbom_spdx"
-SSTATE_SKIP_CREATION:task-create-image-sbom = "1"
+SSTATE_SKIP_CREATION:task-create-image-sbom-spdx = "1"
 do_create_image_sbom_spdx[sstate-inputdirs] = "${SPDXIMAGEDEPLOYDIR}"
 do_create_image_sbom_spdx[sstate-outputdirs] = "${DEPLOY_DIR_IMAGE}"
 do_create_image_sbom_spdx[stamp-extra-info] = "${MACHINE_ARCH}"

meta/classes-recipe/go.bbclass

@@ -22,6 +22,7 @@ export GOARCH = "${TARGET_GOARCH}"
 export GOOS = "${TARGET_GOOS}"
 export GOHOSTARCH="${BUILD_GOARCH}"
 export GOHOSTOS="${BUILD_GOOS}"
+export GOWORK = "off"
 
 GOARM[export] = "0"
 GOARM:arm:class-target = "${TARGET_GOARM}"
@@ -77,7 +78,7 @@ B = "${WORKDIR}/build"
 export GOPATH = "${B}"
 export GOENV = "off"
 export GOPROXY ??= "https://proxy.golang.org,direct"
-export GOTMPDIR ?= "${WORKDIR}/build-tmp"
+export GOTMPDIR ?= "${WORKDIR}/tmp-go-build"
 GOTMPDIR[vardepvalue] = ""
 
 python go_do_unpack() {

meta/classes-recipe/gtk-icon-cache.bbclass

@@ -46,7 +46,7 @@ gtk_icon_cache_postrm() {
 if [ "x$D" != "x" ]; then
 	$INTERCEPT_DIR/postinst_intercept update_gtk_icon_cache ${PKG} \
 		mlprefix=${MLPREFIX} \
-		libdir=${libdir}
+		libdir_native=${libdir_native}
 else
 	for icondir in /usr/share/icons/* ; do
 		if [ -d $icondir ] ; then

meta/classes-recipe/kernel.bbclass

@@ -870,14 +870,13 @@ addtask deploy after do_populate_sysroot do_packagedata
 
 EXPORT_FUNCTIONS do_deploy
 
-python __anonymous() {
+do_create_spdx:append() {
-    inherits = (d.getVar("INHERIT") or "")
+    def create_kernel_config_spdx(d):
-    if "create-spdx" in inherits:
+        if not bb.data.inherits_class("create-spdx-3.0", d):
-        bb.build.addtask('do_create_kernel_config_spdx', 'do_populate_lic do_deploy', 'do_create_spdx', d)
+            return
-}
+        if d.getVar("SPDX_INCLUDE_KERNEL_CONFIG", True) != "1":
+            return
 
-python do_create_kernel_config_spdx() {
-    if d.getVar("SPDX_INCLUDE_KERNEL_CONFIG", True) == "1":
         import oe.spdx30
         import oe.spdx30_tasks
         from pathlib import Path
@@ -909,9 +908,11 @@ python do_create_kernel_config_spdx() {
         except Exception as e:
             bb.error(f"Failed to parse kernel config file: {e}")
 
-        build, build_objset = oe.sbom30.find_root_obj_in_jsonld(
+        path = oe.sbom30.jsonld_arch_path(d, pkg_arch, "recipes", f"recipe-{pn}", deploydir=deploydir)
-            d, "recipes", f"recipe-{pn}", oe.spdx30.build_Build
+        build_objset = oe.sbom30.load_jsonld(d, path, required=True)
-        )
+        build = build_objset.find_root(oe.spdx30.build_Build)
+        if not build:
+            bb.fatal("No root %s found in %s" % (oe.spdx30.build_Build.__name__, path))
 
         kernel_build = build_objset.add_root(
             oe.spdx30.build_Build(
@@ -930,9 +931,11 @@ python do_create_kernel_config_spdx() {
             [kernel_build]
         )
 
-        oe.sbom30.write_jsonld_doc(d, build_objset, deploydir / pkg_arch / "recipes" / f"recipe-{pn}.spdx.json")
+        oe.sbom30.write_jsonld_doc(d, build_objset, path)
+
+    create_kernel_config_spdx(d)
 }
-do_create_kernel_config_spdx[depends] = "virtual/kernel:do_configure"
+do_create_spdx[depends] += "virtual/kernel:do_configure"
 
 # Add using Device Tree support
 inherit kernel-devicetree

meta/classes-recipe/license_image.bbclass

@@ -294,7 +294,7 @@ def get_deployed_files(man_file):
             dep_files.append(os.path.basename(f))
     return dep_files
 
-ROOTFS_POSTPROCESS_COMMAND:prepend = "write_package_manifest license_create_manifest "
+ROOTFS_POSTUNINSTALL_COMMAND:prepend = "write_package_manifest license_create_manifest "
 do_rootfs[recrdeptask] += "do_populate_lic"
 
 python do_populate_lic_deploy() {

meta/classes-recipe/nospdx.bbclass

@@ -10,4 +10,4 @@ deltask do_create_spdx_runtime
 deltask do_create_package_spdx
 deltask do_create_rootfs_spdx
 deltask do_create_image_spdx
-deltask do_create_image_sbom
+deltask do_create_image_sbom_spdx

meta/classes-recipe/python_setuptools_build_meta.bbclass

@@ -7,3 +7,7 @@
 inherit setuptools3-base python_pep517
 
 DEPENDS += "python3-setuptools-native python3-wheel-native"
+
+# This isn't nice, but is the best solutions to ensure clean builds for now.
+# https://github.com/pypa/setuptools/issues/4732
+do_configure[cleandirs] = "${PEP517_SOURCE_PATH}/build"

meta/classes-recipe/setuptools3.bbclass

@@ -15,6 +15,9 @@ SETUPTOOLS_SETUP_PATH ?= "${S}"
 setuptools3_do_configure() {
     :
 }
+# This isn't nice, but is the best solutions to ensure clean builds for now.
+# https://github.com/pypa/setuptools/issues/4732
+do_configure[cleandirs] = "${SETUPTOOLS_SETUP_PATH}/build"
 
 setuptools3_do_compile() {
         cd ${SETUPTOOLS_SETUP_PATH}

meta/classes-recipe/setuptools3_legacy.bbclass

@@ -17,6 +17,7 @@
 inherit setuptools3-base
 
 B = "${WORKDIR}/build"
+do_configure[cleandirs] = "${B}"
 
 SETUPTOOLS_BUILD_ARGS ?= ""
 SETUPTOOLS_INSTALL_ARGS ?= "--root=${D} \

meta/classes/archiver.bbclass

@@ -397,7 +397,7 @@ python do_ar_mirror() {
 
         # We now have an appropriate localpath
         bb.note('Copying source mirror')
-        cmd = 'cp -fpPRH %s %s' % (localpath, destdir)
+        cmd = 'cp --force --preserve=timestamps --no-dereference --recursive -H %s %s' % (localpath, destdir)
         subprocess.check_call(cmd, shell=True)
 }
 

meta/classes/create-spdx-2.2.bbclass

@@ -933,7 +933,7 @@ def spdx_get_src(d):
             share_src = d.getVar('WORKDIR')
             d.setVar('WORKDIR', spdx_workdir)
             d.setVar('STAGING_DIR_NATIVE', spdx_sysroot_native)
-            src_dir = spdx_workdir + "/" + d.getVar('PN')+ "-" + d.getVar('PV') + "-" + d.getVar('PR')
+            src_dir = spdx_workdir + "/" + d.getVar('BP')
             bb.utils.mkdirhier(src_dir)
             if bb.data.inherits_class('kernel',d):
                 share_src = d.getVar('STAGING_KERNEL_DIR')

meta/classes/vex.bbclass

@@ -229,7 +229,7 @@ python vex_write_rootfs_manifest () {
     bb.plain("Image VEX JSON report stored in: %s" % manifest_name)
 }
 
-ROOTFS_POSTPROCESS_COMMAND:prepend = "vex_write_rootfs_manifest; "
+ROOTFS_POSTUNINSTALL_COMMAND:prepend = "vex_write_rootfs_manifest "
 do_rootfs[recrdeptask] += "do_generate_vex "
 do_populate_sdk[recrdeptask] += "do_generate_vex "
 

meta/conf/distro/include/yocto-uninative.inc

@@ -6,10 +6,10 @@
 # to the distro running on the build machine.
 #
 
-UNINATIVE_MAXGLIBCVERSION = "2.42"
+UNINATIVE_MAXGLIBCVERSION = "2.43"
-UNINATIVE_VERSION = "4.9"
+UNINATIVE_VERSION = "5.1"
 
 UNINATIVE_URL ?= "http://downloads.yoctoproject.org/releases/uninative/${UNINATIVE_VERSION}/"
-UNINATIVE_CHECKSUM[aarch64] ?= "812045d826b7fda88944055e8526b95a5a9440bfef608d5b53fd52faab49bf85"
+UNINATIVE_CHECKSUM[aarch64] ?= "4166237a9dabd222dcb9627a9435dffd756764fabf76ed7ef2e93dc2964567ad"
-UNINATIVE_CHECKSUM[i686] ?= "5cc28efd0c15a75de4bcb147c6cce65f1c1c9d442173a220f08427f40a3ffa09"
+UNINATIVE_CHECKSUM[i686] ?= "761502cc9aef4d54d0c6fe9418beb9fdd2c6220da6f2b04128c89f47902ab9ae"
-UNINATIVE_CHECKSUM[x86_64] ?= "4c03d1ed2b7b4e823aca4a1a23d8f2e322f1770fc10e859adcede5777aff4f3a"
+UNINATIVE_CHECKSUM[x86_64] ?= "2b63a078c26535e0786e87f81ae69509df30f4dce40693004c527bd5e4ab2b85"

meta/conf/machine/include/arm/README

@@ -10,7 +10,7 @@ of the existence of the "bigendian" feature in a given tune.
 
 A small set of ARM specific variables have been defined to allow 
 TUNE_PKGARCH to be automatically defined.  Optimized tunings must NOT 
-change the definiton of TUNE_PKGARCH.  TUNE_PKGACH:tune-<tune> will be 
+change the definition of TUNE_PKGARCH.  TUNE_PKGARCH:tune-<tune> will be 
 ignored.  The format of the package arch is enforced by the TUNE_PKGARCH
 default.  The format must be of the form:
 <armversion>[t][e][hf][b][-vfp][-neon]
@@ -22,14 +22,14 @@ ARMPKGARCH - This is the core package arch component specified by each
 tuning.  This is the primary identifier of a tuning.  Usual values are:
 arm, armv4, armv5, armv6, armv7a, etc.
 
-ARMPKGSFX_THUMB - This is the thumb specific suffix.  Curently it is 
+ARMPKGSFX_THUMB - This is the thumb specific suffix.  Currently it is 
 defined in feature-arm-thumb.inc.
 
 ARMPKGSFX_DSP - This is the DSP specific suffix.  Currently this is set 
 to 'e' when on armv5 and the dsp feature is enabled.
 
 ARMPKGSFX_EABI - This is the eabi specific suffix.  There are currently 
-two defined ABIs specificed, standard EABI and Hard Float (VFP) EABI.  
+two defined ABIs specified, standard EABI and Hard Float (VFP) EABI.  
 When the callconvention-hard is enabled, "hf" is specified, otherwise it 
 is blank.
 

meta/conf/machine/include/x86/README

@@ -4,7 +4,7 @@
 Most of the items for the X86 architectures are defined in the single
 arch-x86 file.
 
-Three ABIs are define, m32, mx32 and m64.
+Three ABIs are defined, m32, mx32 and m64.
 
 The following is the list of X86 specific variables:
 
@@ -17,7 +17,7 @@ The TUNE_PKGARCH is defined as follows:
 TUNE_PKGARCH = ${TUNE_PKGARCH:tune-${DEFAULTTUNE}}
 
 The package architecture for 32-bit targets is historical and generally
-set to to match the core compatible processor type, i.e. i386.
+set to match the core compatible processor type, i.e. i386.
 
 For 64-bit architectures, the architecture is expected to end in '_64'.
 

meta/files/layers.example.json

@@ -20,7 +20,7 @@
                 "describe": "15.0-hardknott-3.3-310-g0a96edae",
                 "remotes": {
                     "origin": {
-                        "uri": "git://git.yoctoproject.org/meta-intel"
+                        "uri": "https://git.yoctoproject.org/meta-intel"
                     }
                 },
                 "rev": "0a96edae609a3f48befac36af82cf1eed6786b4a"
@@ -33,7 +33,7 @@
                 "describe": "4.1_M1-374-g9dda719b2a",
                 "remotes": {
                     "origin": {
-                        "uri": "git://git.yoctoproject.org/poky"
+                        "uri": "https://git.yoctoproject.org/poky"
                     },
                     "poky-contrib": {
                         "uri": "ssh://git@push.yoctoproject.org/poky-contrib"

meta/lib/oe/package.py

@@ -1055,13 +1055,13 @@ def save_debugsources_info(debugsrcdir, sources_raw, d):
         # we format the sources as expected by spdx by replacing /usr/src/kernel/
         # into BP/
         kernel_src = d.getVar('KERNEL_SRC_PATH')
-        pf = d.getVar('PF')
+        bp = d.getVar('BP')
         sources_dict = {}
         for file, src_files in sources_raw:
             file_clean = file.replace(f"{workdir}/package/","")
             sources_clean = [
                 src.replace(f"{debugsrcdir}/{pn}/", "")
-                if not kernel_src else src.replace(f"{kernel_src}/", f"{pf}/")
+                if not kernel_src else src.replace(f"{kernel_src}/", f"{bp}/")
                 for src in src_files
                 if not any(keyword in src for keyword in ("<internal>", "<built-in>")) and not src.endswith("/")
             ]

meta/lib/oe/spdx30_tasks.py

@@ -535,7 +535,7 @@ def create_spdx(d):
             # specified.
             if (
                 include_vex != "all"
-                and "detail" in ("fixed-version", "cpe-stable-backport")
+                and detail in ("fixed-version", "cpe-stable-backport")
             ):
                 bb.debug(1, "Skipping %s since it is already fixed upstream" % cve_id)
                 continue

meta/lib/oeqa/core/runner.py

@@ -78,6 +78,10 @@ class OETestResult(_TestResult):
                     self.shownmsg.append(test.id())
                     break
 
+    # Python 3.12 added this, stub it out for now
+    def addDuration(self, test, elapsed):
+         pass
+
     def logSummary(self, component, context_msg=''):
         elapsed_time = self.tc._run_end_time - self.tc._run_start_time
         self.tc.logger.info("SUMMARY:")

meta/lib/oeqa/manual/toaster-managed-mode.json

@@ -2176,7 +2176,7 @@
       ],
       "execution": {
         "1": {
-          "action": "Clone the poky environment     git clone http://git.yoctoproject.org/git/poky",
+          "action": "Clone the poky environment     git clone http://git.yoctoproject.org/poky",
           "expected_results": ""
         },
         "2": {
@@ -2458,7 +2458,7 @@
       ],
       "execution": {
         "1": {
-          "action": "Clone the poky environment     git clone http://git.yoctoproject.org/git/poky",
+          "action": "Clone the poky environment     git clone http://git.yoctoproject.org/poky",
           "expected_results": ""
         },
         "2": {
@@ -2496,7 +2496,7 @@
       ],
       "execution": {
         "1": {
-          "action": "Clone the poky environment     git clone http://git.yoctoproject.org/git/poky\n",
+          "action": "Clone the poky environment     git clone http://git.yoctoproject.org/poky\n",
           "expected_results": ""
         },
         "2": {

meta/lib/oeqa/runtime/cases/go.py

@@ -35,7 +35,7 @@ class GoCompileTest(OERuntimeTestCase):
             self.skipTest('go command not found, output: %s' % output)
 
         # Compile the simple Go program
-        status, output = self.target.run('go build -o /tmp/test /tmp/test.go')
+        status, output = self.target.run('go build -o /tmp/test /tmp/test.go', 600)
         msg = 'go compile failed, output: %s' % output
         self.assertEqual(status, 0, msg=msg)
 
@@ -65,7 +65,7 @@ class GoCompileTest(OERuntimeTestCase):
         self.assertEqual(status, 0, msg=msg)
 
         # Build the module
-        status, output = self.target.run('cd /tmp/hello-go && go build -o hello main.go')
+        status, output = self.target.run('cd /tmp/hello-go && go build -o hello main.go', 600)
         msg = 'go build failed, output: %s' % output
         self.assertEqual(status, 0, msg=msg)
 

meta/lib/oeqa/runtime/cases/parselogs-ignores-qemuall.txt

@@ -13,6 +13,14 @@ FBIOPUT_VSCREENINFO failed, double buffering disabled
 # pci 0000:00:00.0: [Firmware Bug]: reg 0x20: invalid BAR (can't size)
 # pci 0000:00:00.0: [Firmware Bug]: reg 0x24: invalid BAR (can't size)
 invalid BAR (can't size)
+# 6.10+ the invalid BAR warnings are of this format:
+# pci 0000:00:00.0: [Firmware Bug]: BAR 0: invalid; can't size
+# pci 0000:00:00.0: [Firmware Bug]: BAR 1: invalid; can't size
+# pci 0000:00:00.0: [Firmware Bug]: BAR 2: invalid; can't size
+# pci 0000:00:00.0: [Firmware Bug]: BAR 3: invalid; can't size
+# pci 0000:00:00.0: [Firmware Bug]: BAR 4: invalid; can't size
+# pci 0000:00:00.0: [Firmware Bug]: BAR 5: invalid; can't size
+invalid; can't size
 
 # These should be reviewed to see if they are still needed
 wrong ELF class

meta/lib/oeqa/sdk/buildtools-docs-cases/build.py

@@ -15,5 +15,5 @@ class BuildTests(OESDKTestCase):
     """
     def test_docs_build(self):
         with tempfile.TemporaryDirectory(prefix='docs-tarball-build-', dir=self.tc.sdk_dir) as testdir:
-            self._run('git clone git://git.yoctoproject.org/yocto-docs %s' % testdir)
+            self._run('git clone https://git.yoctoproject.org/yocto-docs %s' % testdir)
             self._run('cd %s/documentation && make html' % testdir)

meta/lib/oeqa/sdkext/cases/devtool.py

@@ -71,14 +71,14 @@ class DevtoolTest(OESDKExtTestCase):
     def test_extend_autotools_recipe_creation(self):
         recipe = "test-dbus-wait"
         self._run('devtool sdk-install dbus')
-        self._run('devtool add %s https://git.yoctoproject.org/git/dbus-wait' % (recipe) )
+        self._run('devtool add %s https://git.yoctoproject.org/dbus-wait' % (recipe) )
         try:
             self._run('devtool build %s' % recipe)
         finally:
             self._run('devtool reset %s' % recipe)
 
     def test_devtool_kernelmodule(self):
-        docfile = 'https://git.yoctoproject.org/git/kernel-module-hello-world'
+        docfile = 'https://git.yoctoproject.org/kernel-module-hello-world'
         recipe = 'kernel-module-hello-world'
         self._run('devtool add %s %s' % (recipe, docfile) )
         try: