build-appliance-image: Update to kirkstone head revision

(From OE-Core rev: 45a8b4101b14453aa3020d3f2b8a76b4dc0ae3f2)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

MAINTAINERS.md

@@ -53,6 +53,7 @@ Maintainers needed
 * wic
 * Patchwork
 * Patchtest
+* Prelink-cross
 * Matchbox
 * Sato
 * Autobuilder

bitbake/bin/bitbake-diffsigs

@@ -11,7 +11,6 @@
 import os
 import sys
 import warnings
-
 warnings.simplefilter("default")
 import argparse
 import logging
@@ -28,7 +27,6 @@ logger = bb.msg.logger_create(myname)
 
 is_dump = myname == 'bitbake-dumpsig'
 
-
 def find_siginfo(tinfoil, pn, taskname, sigs=None):
     result = None
     tinfoil.set_event_mask(['bb.event.FindSigInfoResult',
@@ -54,7 +52,6 @@ def find_siginfo(tinfoil, pn, taskname, sigs=None):
         sys.exit(2)
     return result
 
-
 def find_siginfo_task(bbhandler, pn, taskname, sig1=None, sig2=None):
     """ Find the most recent signature files for the specified PN/task """
 
@@ -66,10 +63,10 @@ def find_siginfo_task(bbhandler, pn, taskname, sig1=None, sig2=None):
         if not sigfiles:
             logger.error('No sigdata files found matching %s %s matching either %s or %s' % (pn, taskname, sig1, sig2))
             sys.exit(1)
-        elif sig1 not in sigfiles:
+        elif not sig1 in sigfiles:
             logger.error('No sigdata files found matching %s %s with signature %s' % (pn, taskname, sig1))
             sys.exit(1)
-        elif sig2 not in sigfiles:
+        elif not sig2 in sigfiles:
             logger.error('No sigdata files found matching %s %s with signature %s' % (pn, taskname, sig2))
             sys.exit(1)
         latestfiles = [sigfiles[sig1], sigfiles[sig2]]
@@ -91,9 +88,9 @@ def recursecb(key, hash1, hash2):
     recout = []
     if not hashfiles:
         recout.append("Unable to find matching sigdata for %s with hashes %s or %s" % (key, hash1, hash2))
-    elif hash1 not in hashfiles:
+    elif not hash1 in hashfiles:
         recout.append("Unable to find matching sigdata for %s with hash %s" % (key, hash1))
-    elif hash2 not in hashfiles:
+    elif not hash2 in hashfiles:
         recout.append("Unable to find matching sigdata for %s with hash %s" % (key, hash2))
     else:
         out2 = bb.siggen.compare_sigfiles(hashfiles[hash1], hashfiles[hash2], recursecb, color=color)
@@ -113,36 +110,36 @@ parser.add_argument('-D', '--debug',
 
 if is_dump:
     parser.add_argument("-t", "--task",
-                        help="find the signature data file for the last run of the specified task",
-                        action="store", dest="taskargs", nargs=2, metavar=('recipename', 'taskname'))
+            help="find the signature data file for the last run of the specified task",
+            action="store", dest="taskargs", nargs=2, metavar=('recipename', 'taskname'))
 
     parser.add_argument("sigdatafile1",
-                        help="Signature file to dump. Not used when using -t/--task.",
-                        action="store", nargs='?', metavar="sigdatafile")
+            help="Signature file to dump. Not used when using -t/--task.",
+            action="store", nargs='?', metavar="sigdatafile")
 else:
     parser.add_argument('-c', '--color',
-                        help='Colorize the output (where %(metavar)s is %(choices)s)',
-                        choices=['auto', 'always', 'never'], default='auto', metavar='color')
+            help='Colorize the output (where %(metavar)s is %(choices)s)',
+            choices=['auto', 'always', 'never'], default='auto', metavar='color')
 
     parser.add_argument('-d', '--dump',
-                        help='Dump the last signature data instead of comparing (equivalent to using bitbake-dumpsig)',
-                        action='store_true')
+            help='Dump the last signature data instead of comparing (equivalent to using bitbake-dumpsig)',
+            action='store_true')
 
     parser.add_argument("-t", "--task",
-                        help="find the signature data files for the last two runs of the specified task and compare them",
-                        action="store", dest="taskargs", nargs=2, metavar=('recipename', 'taskname'))
+            help="find the signature data files for the last two runs of the specified task and compare them",
+            action="store", dest="taskargs", nargs=2, metavar=('recipename', 'taskname'))
 
     parser.add_argument("-s", "--signature",
-                        help="With -t/--task, specify the signatures to look for instead of taking the last two",
-                        action="store", dest="sigargs", nargs=2, metavar=('fromsig', 'tosig'))
+            help="With -t/--task, specify the signatures to look for instead of taking the last two",
+            action="store", dest="sigargs", nargs=2, metavar=('fromsig', 'tosig'))
 
     parser.add_argument("sigdatafile1",
-                        help="First signature file to compare (or signature file to dump, if second not specified). Not used when using -t/--task.",
-                        action="store", nargs='?')
+            help="First signature file to compare (or signature file to dump, if second not specified). Not used when using -t/--task.",
+            action="store", nargs='?')
 
     parser.add_argument("sigdatafile2",
-                        help="Second signature file to compare",
-                        action="store", nargs='?')
+            help="Second signature file to compare",
+            action="store", nargs='?')
 
 options = parser.parse_args()
 if is_dump:
@@ -160,8 +157,7 @@ if options.taskargs:
     with bb.tinfoil.Tinfoil() as tinfoil:
         tinfoil.prepare(config_only=True)
         if not options.dump and options.sigargs:
-            files = find_siginfo_task(tinfoil, options.taskargs[0], options.taskargs[1], options.sigargs[0],
-                                      options.sigargs[1])
+            files = find_siginfo_task(tinfoil, options.taskargs[0], options.taskargs[1], options.sigargs[0], options.sigargs[1])
         else:
             files = find_siginfo_task(tinfoil, options.taskargs[0], options.taskargs[1])
 
@@ -170,8 +166,7 @@ if options.taskargs:
             output = bb.siggen.dump_sigfile(files[-1])
         else:
             if len(files) < 2:
-                logger.error('Only one matching sigdata file found for the specified task (%s %s)' % (
-                    options.taskargs[0], options.taskargs[1]))
+                logger.error('Only one matching sigdata file found for the specified task (%s %s)' % (options.taskargs[0], options.taskargs[1]))
                 sys.exit(1)
 
             # Recurse into signature comparison

bitbake/bin/bitbake-prserv

@@ -1,5 +1,7 @@
 #!/usr/bin/env python3
 #
+# Copyright BitBake Contributors
+#
 # SPDX-License-Identifier: GPL-2.0-only
 #
 

bitbake/bin/bitbake-worker

@@ -1,5 +1,7 @@
 #!/usr/bin/env python3
 #
+# Copyright BitBake Contributors
+#
 # SPDX-License-Identifier: GPL-2.0-only
 #
 

bitbake/bin/git-make-shallow

@@ -1,5 +1,7 @@
 #!/usr/bin/env python3
 #
+# Copyright BitBake Contributors
+#
 # SPDX-License-Identifier: GPL-2.0-only
 #
 

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

@@ -688,6 +688,8 @@ Here is an example URL::
 
 It can also be used when setting mirrors definitions using the :term:`PREMIRRORS` variable.
 
+.. _crate-fetcher:
+
 Crate Fetcher (``crate://``)
 ----------------------------
 
@@ -704,6 +706,80 @@ Here is an example URL::
 
    SRC_URI = "crate://crates.io/glob/0.2.11"
 
+.. _npm-fetcher:
+
+NPM Fetcher (``npm://``)
+------------------------
+
+This submodule fetches source code from an
+`NPM <https://en.wikipedia.org/wiki/Npm_(software)>`__
+Javascript package registry.
+
+The format for the :term:`SRC_URI` setting must be::
+
+   SRC_URI = "npm://some.registry.url;ParameterA=xxx;ParameterB=xxx;..."
+
+This fetcher supports the following parameters:
+
+-  *"package":* The NPM package name. This is a mandatory parameter.
+
+-  *"version":* The NPM package version. This is a mandatory parameter.
+
+-  *"downloadfilename":* Specifies the filename used when storing the downloaded file.
+
+-  *"destsuffix":* Specifies the directory to use to unpack the package (default: ``npm``).
+
+Note that NPM fetcher only fetches the package source itself. The dependencies
+can be fetched through the `npmsw-fetcher`_.
+
+Here is an example URL with both fetchers::
+
+   SRC_URI = " \
+       npm://registry.npmjs.org/;package=cute-files;version=${PV} \
+       npmsw://${THISDIR}/${BPN}/npm-shrinkwrap.json \
+       "
+
+See :yocto_docs:`Creating Node Package Manager (NPM) Packages
+</dev-manual/common-tasks.html#creating-node-package-manager-npm-packages>`
+in the Yocto Project manual for details about using
+:yocto_docs:`devtool <https://docs.yoctoproject.org/ref-manual/devtool-reference.html>`
+to automatically create a recipe from an NPM URL.
+
+.. _npmsw-fetcher:
+
+NPM shrinkwrap Fetcher (``npmsw://``)
+-------------------------------------
+
+This submodule fetches source code from an
+`NPM shrinkwrap <https://docs.npmjs.com/cli/v8/commands/npm-shrinkwrap>`__
+description file, which lists the dependencies
+of an NPM package while locking their versions.
+
+The format for the :term:`SRC_URI` setting must be::
+
+   SRC_URI = "npmsw://some.registry.url;ParameterA=xxx;ParameterB=xxx;..."
+
+This fetcher supports the following parameters:
+
+-  *"dev":* Set this parameter to ``1`` to install "devDependencies".
+
+-  *"destsuffix":* Specifies the directory to use to unpack the dependencies
+   (``${S}`` by default).
+
+Note that the shrinkwrap file can also be provided by the recipe for
+the package which has such dependencies, for example::
+
+   SRC_URI = " \
+       npm://registry.npmjs.org/;package=cute-files;version=${PV} \
+       npmsw://${THISDIR}/${BPN}/npm-shrinkwrap.json \
+       "
+
+Such a file can automatically be generated using
+:yocto_docs:`devtool <https://docs.yoctoproject.org/ref-manual/devtool-reference.html>`
+as described in the :yocto_docs:`Creating Node Package Manager (NPM) Packages
+</dev-manual/common-tasks.html#creating-node-package-manager-npm-packages>`
+section of the Yocto Project.
+
 Other Fetchers
 --------------
 
@@ -713,8 +789,6 @@ Fetch submodules also exist for the following:
 
 -  Mercurial (``hg://``)
 
--  npm (``npm://``)
-
 -  OSC (``osc://``)
 
 -  Secure FTP (``sftp://``)

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

@@ -195,22 +195,45 @@ value. However, if ``A`` is not set, the variable is set to "aval".
 Setting a weak default value (??=)
 ----------------------------------
 
-It is possible to use a "weaker" assignment than in the previous section
-by using the "??=" operator. This assignment behaves identical to "?="
-except that the assignment is made at the end of the parsing process
-rather than immediately. Consequently, when multiple "??=" assignments
-exist, the last one is used. Also, any "=" or "?=" assignment will
-override the value set with "??=". Here is an example::
+The weak default value of a variable is the value which that variable
+will expand to if no value has been assigned to it via any of the other
+assignment operators. The "??=" operator takes effect immediately, replacing
+any previously defined weak default value. Here is an example::
 
-   A ??= "somevalue"
-   A ??= "someothervalue"
+   W ??= "x"
+   A := "${W}" # Immediate variable expansion
+   W ??= "y"
+   B := "${W}" # Immediate variable expansion
+   W ??= "z"
+   C = "${W}"
+   W ?= "i"
 
-If ``A`` is set before the above statements are
-parsed, the variable retains its value. If ``A`` is not set, the
-variable is set to "someothervalue".
+After parsing we will have::
 
-Again, this assignment is a "lazy" or "weak" assignment because it does
-not occur until the end of the parsing process.
+   A = "x"
+   B = "y"
+   C = "i"
+   W = "i"
+
+Appending and prepending non-override style will not substitute the weak
+default value, which means that after parsing::
+
+   W ??= "x"
+   W += "y"
+
+we will have::
+
+   W = " y"
+
+On the other hand, override-style appends/prepends/removes are applied after
+any active weak default value has been substituted::
+
+   W ??= "x"
+   W:append = "y"
+
+After parsing we will have::
+
+   W = "xy"
 
 Immediate variable expansion (:=)
 ---------------------------------

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

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

bitbake/lib/bb/COW.py

@@ -3,6 +3,8 @@
 #
 # Copyright (C) 2006 Tim Ansell
 #
+# SPDX-License-Identifier: GPL-2.0-only
+#
 # Please Note:
 # Be careful when using mutable types (ie Dict and Lists) - operations involving these are SLOW.
 # Assign a file to __warn__ to get warnings about slow operations.

bitbake/lib/bb/asyncrpc/__init__.py

@@ -1,4 +1,6 @@
 #
+# Copyright BitBake Contributors
+#
 # SPDX-License-Identifier: GPL-2.0-only
 #
 

bitbake/lib/bb/asyncrpc/client.py

@@ -1,4 +1,6 @@
 #
+# Copyright BitBake Contributors
+#
 # SPDX-License-Identifier: GPL-2.0-only
 #
 
@@ -29,7 +31,17 @@ class AsyncClient(object):
 
     async def connect_unix(self, path):
         async def connect_sock():
-            return await asyncio.open_unix_connection(path)
+            # AF_UNIX has path length issues so chdir here to workaround
+            cwd = os.getcwd()
+            try:
+                os.chdir(os.path.dirname(path))
+                # The socket must be opened synchronously so that CWD doesn't get
+                # changed out from underneath us so we pass as a sock into asyncio
+                sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM, 0)
+                sock.connect(os.path.basename(path))
+            finally:
+               os.chdir(cwd)
+            return await asyncio.open_unix_connection(sock=sock)
 
         self._connect_sock = connect_sock
 
@@ -148,14 +160,8 @@ class Client(object):
             setattr(self, m, self._get_downcall_wrapper(downcall))
 
     def connect_unix(self, path):
-        # AF_UNIX has path length issues so chdir here to workaround
-        cwd = os.getcwd()
-        try:
-            os.chdir(os.path.dirname(path))
-            self.loop.run_until_complete(self.client.connect_unix(os.path.basename(path)))
-            self.loop.run_until_complete(self.client.connect())
-        finally:
-            os.chdir(cwd)
+        self.loop.run_until_complete(self.client.connect_unix(path))
+        self.loop.run_until_complete(self.client.connect())
 
     @property
     def max_chunk(self):

bitbake/lib/bb/asyncrpc/serv.py

@@ -1,4 +1,6 @@
 #
+# Copyright BitBake Contributors
+#
 # SPDX-License-Identifier: GPL-2.0-only
 #
 

bitbake/lib/bb/codeparser.py

@@ -1,4 +1,6 @@
 #
+# Copyright BitBake Contributors
+#
 # SPDX-License-Identifier: GPL-2.0-only
 #
 

bitbake/lib/bb/compress/_pipecompress.py

@@ -1,4 +1,6 @@
 #
+# Copyright BitBake Contributors
+#
 # SPDX-License-Identifier: GPL-2.0-only
 #
 # Helper library to implement streaming compression and decompression using an

bitbake/lib/bb/compress/lz4.py

@@ -1,4 +1,6 @@
 #
+# Copyright BitBake Contributors
+#
 # SPDX-License-Identifier: GPL-2.0-only
 #
 

bitbake/lib/bb/compress/zstd.py

@@ -1,4 +1,6 @@
 #
+# Copyright BitBake Contributors
+#
 # SPDX-License-Identifier: GPL-2.0-only
 #
 

bitbake/lib/bb/cooker.py

@@ -13,7 +13,6 @@ import sys, os, glob, os.path, re, time
 import itertools
 import logging
 import multiprocessing
-import sre_constants
 import threading
 from io import StringIO, UnsupportedOperation
 from contextlib import closing
@@ -1907,7 +1906,7 @@ class CookerCollectFiles(object):
                 try:
                     re.compile(mask)
                     bbmasks.append(mask)
-                except sre_constants.error:
+                except re.error:
                     collectlog.critical("BBMASK contains an invalid regular expression, ignoring: %s" % mask)
 
             # Then validate the combined regular expressions. This should never
@@ -1915,7 +1914,7 @@ class CookerCollectFiles(object):
             bbmask = "|".join(bbmasks)
             try:
                 bbmask_compiled = re.compile(bbmask)
-            except sre_constants.error:
+            except re.error:
                 collectlog.critical("BBMASK is not a valid regular expression, ignoring: %s" % bbmask)
                 bbmask = None
 

bitbake/lib/bb/cookerdata.py

@@ -248,7 +248,7 @@ class CookerDataBuilder(object):
         for k in cookercfg.env:
             self.savedenv.setVar(k, cookercfg.env[k])
             if k in bb.data_smart.bitbake_renamed_vars:
-                bb.error('Shell environment variable %s has been renamed to %s' % (k, bb.data_smart.bitbake_renamed_vars[k]))
+                bb.error('Variable %s from the shell environment has been renamed to %s' % (k, bb.data_smart.bitbake_renamed_vars[k]))
                 bb.fatal("Exiting to allow enviroment variables to be corrected")
 
         filtered_keys = bb.utils.approved_variables()

bitbake/lib/bb/daemonize.py

@@ -1,4 +1,6 @@
 #
+# Copyright BitBake Contributors
+#
 # SPDX-License-Identifier: GPL-2.0-only
 #
 

bitbake/lib/bb/event.py

@@ -132,8 +132,14 @@ def print_ui_queue():
     if not _uiready:
         from bb.msg import BBLogFormatter
         # Flush any existing buffered content
-        sys.stdout.flush()
-        sys.stderr.flush()
+        try:
+            sys.stdout.flush()
+        except:
+            pass
+        try:
+            sys.stderr.flush()
+        except:
+            pass
         stdout = logging.StreamHandler(sys.stdout)
         stderr = logging.StreamHandler(sys.stderr)
         formatter = BBLogFormatter("%(levelname)s: %(message)s")

bitbake/lib/bb/exceptions.py

@@ -1,4 +1,6 @@
 #
+# Copyright BitBake Contributors
+#
 # SPDX-License-Identifier: GPL-2.0-only
 #
 

bitbake/lib/bb/fetch2/__init__.py

@@ -1097,6 +1097,8 @@ def try_mirror_url(fetch, origud, ud, ld, check = False):
 
 def ensure_symlink(target, link_name):
     if not os.path.exists(link_name):
+        dirname = os.path.dirname(link_name)
+        bb.utils.mkdirhier(dirname)
         if os.path.islink(link_name):
             # Broken symbolic link
             os.unlink(link_name)

bitbake/lib/bb/fetch2/git.py

@@ -74,9 +74,6 @@ from   bb.fetch2 import runfetchcmd
 from   bb.fetch2 import logger
 
 
-sha1_re = re.compile(r'^[0-9a-f]{40}$')
-slash_re = re.compile(r"/+")
-
 class GitProgressHandler(bb.progress.LineFilterProgressHandler):
     """Extract progress information from git output"""
     def __init__(self, d):
@@ -252,8 +249,8 @@ class Git(FetchMethod):
         ud.setup_revisions(d)
 
         for name in ud.names:
-            # Ensure any revision that doesn't look like a SHA-1 is translated into one
-            if not sha1_re.match(ud.revisions[name] or ''):
+            # Ensure anything that doesn't look like a sha256 checksum/revision is translated into one
+            if not ud.revisions[name] or len(ud.revisions[name]) != 40  or (False in [c in "abcdef0123456789" for c in ud.revisions[name]]):
                 if ud.revisions[name]:
                     ud.unresolvedrev[name] = ud.revisions[name]
                 ud.revisions[name] = self.latest_revision(ud, d, name)
@@ -262,10 +259,10 @@ class Git(FetchMethod):
         if gitsrcname.startswith('.'):
             gitsrcname = gitsrcname[1:]
 
-        # For a rebaseable git repo, it is necessary to keep a mirror tar ball
-        # per revision, so that even if the revision disappears from the
+        # for rebaseable git repo, it is necessary to keep mirror tar ball
+        # per revision, so that even the revision disappears from the
         # upstream repo in the future, the mirror will remain intact and still
-        # contain the revision
+        # contains the revision
         if ud.rebaseable:
             for name in ud.names:
                 gitsrcname = gitsrcname + '_' + ud.revisions[name]
@@ -700,6 +697,7 @@ class Git(FetchMethod):
         Return a unique key for the url
         """
         # Collapse adjacent slashes
+        slash_re = re.compile(r"/+")
         return "git:" + ud.host + slash_re.sub(".", ud.path) + ud.unresolvedrev[name]
 
     def _lsremote(self, ud, d, search):

bitbake/lib/bb/fetch2/gitsm.py

@@ -88,7 +88,7 @@ class GitSM(Git):
                 subrevision[m] = module_hash.split()[2]
 
                 # Convert relative to absolute uri based on parent uri
-                if uris[m].startswith('..'):
+                if  uris[m].startswith('..') or uris[m].startswith('./'):
                     newud = copy.copy(ud)
                     newud.path = os.path.realpath(os.path.join(newud.path, uris[m]))
                     uris[m] = Git._get_repo_url(self, newud)
@@ -115,6 +115,9 @@ class GitSM(Git):
                     # This has to be a file reference
                     proto = "file"
                     url = "gitsm://" + uris[module]
+            if url.endswith("{}{}".format(ud.host, ud.path)):
+                raise bb.fetch2.FetchError("Submodule refers to the parent repository. This will cause deadlock situation in current version of Bitbake." \
+                                           "Consider using git fetcher instead.")
 
             url += ';protocol=%s' % proto
             url += ";name=%s" % module

bitbake/lib/bb/fetch2/npm.py

@@ -156,7 +156,7 @@ class Npm(FetchMethod):
             raise ParameterError("Invalid 'version' parameter", ud.url)
 
         # Extract the 'registry' part of the url
-        ud.registry = re.sub(r"^npm://", "http://", ud.url.split(";")[0])
+        ud.registry = re.sub(r"^npm://", "https://", ud.url.split(";")[0])
 
         # Using the 'downloadfilename' parameter as local filename
         # or the npm package name.

bitbake/lib/bb/fetch2/osc.py

@@ -1,4 +1,6 @@
 #
+# Copyright BitBake Contributors
+#
 # SPDX-License-Identifier: GPL-2.0-only
 #
 """
@@ -9,7 +11,6 @@ Based on the svn "Fetch" implementation.
 
 import logging
 import os
-import re
 import  bb
 from    bb.fetch2 import FetchMethod
 from    bb.fetch2 import FetchError
@@ -61,49 +62,26 @@ class Osc(FetchMethod):
 
         basecmd = d.getVar("FETCHCMD_osc") or "/usr/bin/env osc"
 
-        proto = ud.parm.get('protocol', 'https')
+        proto = ud.parm.get('protocol', 'ocs')
 
         options = []
 
         config = "-c %s" % self.generate_config(ud, d)
 
-        if getattr(ud, 'revision', ''):
+        if ud.revision:
             options.append("-r %s" % ud.revision)
 
         coroot = self._strip_leading_slashes(ud.path)
 
         if command == "fetch":
-            osccmd = "%s %s -A %s://%s co %s/%s %s" % (basecmd, config, proto, ud.host, coroot, ud.module, " ".join(options))
+            osccmd = "%s %s co %s/%s %s" % (basecmd, config, coroot, ud.module, " ".join(options))
         elif command == "update":
-            osccmd = "%s %s -A %s://%s up %s" % (basecmd, config, proto, ud.host, " ".join(options))
-        elif command == "api_source":
-            osccmd = "%s %s -A %s://%s api source/%s/%s" % (basecmd, config, proto, ud.host, coroot, ud.module)
+            osccmd = "%s %s up %s" % (basecmd, config, " ".join(options))
         else:
             raise FetchError("Invalid osc command %s" % command, ud.url)
 
         return osccmd
 
-    def _latest_revision(self, ud, d, name):
-        """
-        Fetch latest revision for the given package
-        """
-        api_source_cmd = self._buildosccommand(ud, d, "api_source")
-
-        output = runfetchcmd(api_source_cmd, d)
-        match = re.match(r'<directory ?.* rev="(\d+)".*>', output)
-        if match is None:
-            raise FetchError("Unable to parse osc response", ud.url)
-        return match.groups()[0]
-
-    def _revision_key(self, ud, d, name):
-        """
-        Return a unique key for the url
-        """
-        # Collapse adjacent slashes
-        slash_re = re.compile(r"/+")
-        rev = getattr(ud, 'revision', "latest")
-        return "osc:%s%s.%s.%s" % (ud.host, slash_re.sub(".", ud.path), name, rev)
-
     def download(self, ud, d):
         """
         Fetch url
@@ -147,7 +125,7 @@ class Osc(FetchMethod):
             os.remove(config_path)
 
         f = open(config_path, 'w')
-        proto = ud.parm.get('protocol', 'https')
+        proto = ud.parm.get('proto', 'https')
         f.write("[general]\n")
         f.write("apiurl = %s://%s\n" % (proto, ud.host))
         f.write("su-wrapper = su -c\n")

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

@@ -178,10 +178,10 @@ def feeder(lineno, s, fn, root, statements, eof=False):
 
     if s and s[0] == '#':
         if len(__residue__) != 0 and __residue__[0][0] != "#":
-            bb.fatal("There is a comment on line %s of file %s (%s) which is in the middle of a multiline expression.\nBitbake used to ignore these but no longer does so, please fix your metadata as errors are likely as a result of this change." % (lineno, fn, s))
+            bb.fatal("There is a comment on line %s of file %s:\n'''\n%s\n'''\nwhich is in the middle of a multiline expression. This syntax is invalid, please correct it." % (lineno, fn, s))
 
     if len(__residue__) != 0 and __residue__[0][0] == "#" and (not s or s[0] != "#"):
-        bb.fatal("There is a confusing multiline, partially commented expression on line %s of file %s (%s).\nPlease clarify whether this is all a comment or should be parsed." % (lineno, fn, s))
+        bb.fatal("There is a confusing multiline partially commented expression on line %s of file %s:\n%s\nPlease clarify whether this is all a comment or should be parsed." % (lineno - len(__residue__), fn, "\n".join(__residue__)))
 
     if s and s[-1] == '\\':
         __residue__.append(s[:-1])

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

@@ -125,16 +125,21 @@ def handle(fn, data, include):
             s = f.readline()
             if not s:
                 break
+            origlineno = lineno
+            origline = s
             w = s.strip()
             # skip empty lines
             if not w:
                 continue
             s = s.rstrip()
             while s[-1] == '\\':
-                s2 = f.readline().rstrip()
+                line = f.readline()
+                origline += line
+                s2 = line.rstrip()
                 lineno = lineno + 1
                 if (not s2 or s2 and s2[0] != "#") and s[0] == "#" :
-                    bb.fatal("There is a confusing multiline, partially commented expression on line %s of file %s (%s).\nPlease clarify whether this is all a comment or should be parsed." % (lineno, fn, s))
+                    bb.fatal("There is a confusing multiline, partially commented expression starting on line %s of file %s:\n%s\nPlease clarify whether this is all a comment or should be parsed." % (origlineno, fn, origline))
+
                 s = s[:-1] + s2
             # skip comments
             if s[0] == '#':
@@ -147,8 +152,6 @@ def handle(fn, data, include):
     if oldfile:
         data.setVar('FILE', oldfile)
 
-    f.close()
-
     for f in confFilters:
         f(fn, data)
 

bitbake/lib/bb/process.py

@@ -1,4 +1,6 @@
 #
+# Copyright BitBake Contributors
+#
 # SPDX-License-Identifier: GPL-2.0-only
 #
 

bitbake/lib/bb/runqueue.py

@@ -24,6 +24,7 @@ import pickle
 from multiprocessing import Process
 import shlex
 import pprint
+import time
 
 bblogger = logging.getLogger("BitBake")
 logger = logging.getLogger("BitBake.RunQueue")
@@ -159,6 +160,55 @@ class RunQueueScheduler(object):
                 self.buildable.append(tid)
 
         self.rev_prio_map = None
+        self.is_pressure_usable()
+
+    def is_pressure_usable(self):
+        """
+        If monitoring pressure, return True if pressure files can be open and read. For example
+        openSUSE /proc/pressure/* files have readable file permissions but when read the error EOPNOTSUPP (Operation not supported)
+        is returned.
+        """
+        if self.rq.max_cpu_pressure or self.rq.max_io_pressure or self.rq.max_memory_pressure:
+            try:
+                with open("/proc/pressure/cpu") as cpu_pressure_fds, \
+                    open("/proc/pressure/io") as io_pressure_fds, \
+                    open("/proc/pressure/memory") as memory_pressure_fds:
+
+                    self.prev_cpu_pressure = cpu_pressure_fds.readline().split()[4].split("=")[1]
+                    self.prev_io_pressure = io_pressure_fds.readline().split()[4].split("=")[1]
+                    self.prev_memory_pressure = memory_pressure_fds.readline().split()[4].split("=")[1]
+                    self.prev_pressure_time = time.time()
+                self.check_pressure = True
+            except:
+                bb.note("The /proc/pressure files can't be read. Continuing build without monitoring pressure")
+                self.check_pressure = False
+        else:
+            self.check_pressure = False
+
+    def exceeds_max_pressure(self):
+        """
+        Monitor the difference in total pressure at least once per second, if
+        BB_PRESSURE_MAX_{CPU|IO|MEMORY} are set, return True if above threshold.
+        """
+        if self.check_pressure:
+            with open("/proc/pressure/cpu") as cpu_pressure_fds, \
+                open("/proc/pressure/io") as io_pressure_fds, \
+                open("/proc/pressure/memory") as memory_pressure_fds:
+                # extract "total" from /proc/pressure/{cpu|io}
+                curr_cpu_pressure = cpu_pressure_fds.readline().split()[4].split("=")[1]
+                curr_io_pressure = io_pressure_fds.readline().split()[4].split("=")[1]
+                curr_memory_pressure = memory_pressure_fds.readline().split()[4].split("=")[1]
+                exceeds_cpu_pressure =  self.rq.max_cpu_pressure and (float(curr_cpu_pressure) - float(self.prev_cpu_pressure)) > self.rq.max_cpu_pressure
+                exceeds_io_pressure =  self.rq.max_io_pressure and (float(curr_io_pressure) - float(self.prev_io_pressure)) > self.rq.max_io_pressure
+                exceeds_memory_pressure = self.rq.max_memory_pressure and (float(curr_memory_pressure) - float(self.prev_memory_pressure)) > self.rq.max_memory_pressure
+                now = time.time()
+                if now - self.prev_pressure_time > 1.0:
+                    self.prev_cpu_pressure = curr_cpu_pressure
+                    self.prev_io_pressure = curr_io_pressure
+                    self.prev_memory_pressure = curr_memory_pressure
+                    self.prev_pressure_time = now
+            return (exceeds_cpu_pressure or exceeds_io_pressure or exceeds_memory_pressure)
+        return False
 
     def next_buildable_task(self):
         """
@@ -172,6 +222,12 @@ class RunQueueScheduler(object):
         if not buildable:
             return None
 
+        # Bitbake requires that at least one task be active. Only check for pressure if
+        # this is the case, otherwise the pressure limitation could result in no tasks
+        # being active and no new tasks started thereby, at times, breaking the scheduler.
+        if self.rq.stats.active and self.exceeds_max_pressure():
+            return None
+
         # Filter out tasks that have a max number of threads that have been exceeded
         skip_buildable = {}
         for running in self.rq.runq_running.difference(self.rq.runq_complete):
@@ -1699,6 +1755,9 @@ class RunQueueExecute:
 
         self.number_tasks = int(self.cfgData.getVar("BB_NUMBER_THREADS") or 1)
         self.scheduler = self.cfgData.getVar("BB_SCHEDULER") or "speed"
+        self.max_cpu_pressure = self.cfgData.getVar("BB_PRESSURE_MAX_CPU")
+        self.max_io_pressure = self.cfgData.getVar("BB_PRESSURE_MAX_IO")
+        self.max_memory_pressure = self.cfgData.getVar("BB_PRESSURE_MAX_MEMORY")
 
         self.sq_buildable = set()
         self.sq_running = set()
@@ -1733,6 +1792,29 @@ class RunQueueExecute:
         if self.number_tasks <= 0:
              bb.fatal("Invalid BB_NUMBER_THREADS %s" % self.number_tasks)
 
+        lower_limit = 1.0
+        upper_limit = 1000000.0
+        if self.max_cpu_pressure:
+            self.max_cpu_pressure = float(self.max_cpu_pressure)
+            if self.max_cpu_pressure < lower_limit:
+                bb.fatal("Invalid BB_PRESSURE_MAX_CPU %s, minimum value is %s." % (self.max_cpu_pressure, lower_limit))
+            if self.max_cpu_pressure > upper_limit:
+                bb.warn("Your build will be largely unregulated since BB_PRESSURE_MAX_CPU is set to %s. It is very unlikely that such high pressure will be experienced." % (self.max_cpu_pressure))
+
+        if self.max_io_pressure:
+            self.max_io_pressure = float(self.max_io_pressure)
+            if self.max_io_pressure < lower_limit:
+                bb.fatal("Invalid BB_PRESSURE_MAX_IO %s, minimum value is %s." % (self.max_io_pressure, lower_limit))
+            if self.max_io_pressure > upper_limit:
+                bb.warn("Your build will be largely unregulated since BB_PRESSURE_MAX_IO is set to %s. It is very unlikely that such high pressure will be experienced." % (self.max_io_pressure))
+
+        if self.max_memory_pressure:
+            self.max_memory_pressure = float(self.max_memory_pressure)
+            if self.max_memory_pressure < lower_limit:
+                bb.fatal("Invalid BB_PRESSURE_MAX_MEMORY %s, minimum value is %s." % (self.max_memory_pressure, lower_limit))
+            if self.max_memory_pressure > upper_limit:
+                bb.warn("Your build will be largely unregulated since BB_PRESSURE_MAX_MEMORY is set to %s. It is very unlikely that such high pressure will be experienced." % (self.max_io_pressure))
+            
         # List of setscene tasks which we've covered
         self.scenequeue_covered = set()
         # List of tasks which are covered (including setscene ones)
@@ -2172,10 +2254,9 @@ class RunQueueExecute:
 
         # No more tasks can be run. If we have deferred setscene tasks we should run them.
         if self.sq_deferred:
-            tid = self.sq_deferred.pop(list(self.sq_deferred.keys())[0])
-            logger.warning("Runqeueue deadlocked on deferred tasks, forcing task %s" % tid)
-            if tid not in self.runq_complete:
-                self.sq_task_failoutright(tid)
+            deferred_tid = list(self.sq_deferred.keys())[0]
+            blocking_tid = self.sq_deferred.pop(deferred_tid)
+            logger.warning("Runqeueue deadlocked on deferred tasks, forcing task %s blocked by %s" % (deferred_tid, blocking_tid))
             return True
 
         if self.failed_tids:
@@ -2299,6 +2380,9 @@ class RunQueueExecute:
                     self.rqdata.runtaskentries[hashtid].unihash = unihash
                     bb.parse.siggen.set_unihash(hashtid, unihash)
                     toprocess.add(hashtid)
+                if torehash:
+                    # Need to save after set_unihash above
+                    bb.parse.siggen.save_unitaskhashes()
 
         # Work out all tasks which depend upon these
         total = set()
@@ -2405,17 +2489,6 @@ class RunQueueExecute:
                 self.sq_buildable.remove(tid)
             if tid in self.sq_running:
                 self.sq_running.remove(tid)
-            harddepfail = False
-            for t in self.sqdata.sq_harddeps:
-                if tid in self.sqdata.sq_harddeps[t] and t in self.scenequeue_notcovered:
-                    harddepfail = True
-                    break
-            if not harddepfail and self.sqdata.sq_revdeps[tid].issubset(self.scenequeue_covered | self.scenequeue_notcovered):
-                if tid not in self.sq_buildable:
-                    self.sq_buildable.add(tid)
-            if not self.sqdata.sq_revdeps[tid]:
-                self.sq_buildable.add(tid)
-
             if tid in self.sqdata.outrightfail:
                 self.sqdata.outrightfail.remove(tid)
             if tid in self.scenequeue_notcovered:
@@ -2434,18 +2507,36 @@ class RunQueueExecute:
             if tid in self.build_stamps:
                 del self.build_stamps[tid]
 
-            update_tasks.append((tid, harddepfail, tid in self.sqdata.valid))
+            update_tasks.append(tid)
 
-        if update_tasks:
+        update_tasks2 = []
+        for tid in update_tasks:
+            harddepfail = False
+            for t in self.sqdata.sq_harddeps:
+                if tid in self.sqdata.sq_harddeps[t] and t in self.scenequeue_notcovered:
+                    harddepfail = True
+                    break
+            if not harddepfail and self.sqdata.sq_revdeps[tid].issubset(self.scenequeue_covered | self.scenequeue_notcovered):
+                if tid not in self.sq_buildable:
+                    self.sq_buildable.add(tid)
+            if not self.sqdata.sq_revdeps[tid]:
+                self.sq_buildable.add(tid)
+
+            update_tasks2.append((tid, harddepfail, tid in self.sqdata.valid))
+
+        if update_tasks2:
             self.sqdone = False
-            for tid in [t[0] for t in update_tasks]:
-                h = pending_hash_index(tid, self.rqdata)
-                if h in self.sqdata.hashes and tid != self.sqdata.hashes[h]:
-                    self.sq_deferred[tid] = self.sqdata.hashes[h]
-                    bb.note("Deferring %s after %s" % (tid, self.sqdata.hashes[h]))
-            update_scenequeue_data([t[0] for t in update_tasks], self.sqdata, self.rqdata, self.rq, self.cooker, self.stampcache, self, summary=False)
+            for mc in sorted(self.sqdata.multiconfigs):
+                for tid in sorted([t[0] for t in update_tasks2]):
+                    if mc_from_tid(tid) != mc:
+                        continue
+                    h = pending_hash_index(tid, self.rqdata)
+                    if h in self.sqdata.hashes and tid != self.sqdata.hashes[h]:
+                        self.sq_deferred[tid] = self.sqdata.hashes[h]
+                        bb.note("Deferring %s after %s" % (tid, self.sqdata.hashes[h]))
+            update_scenequeue_data([t[0] for t in update_tasks2], self.sqdata, self.rqdata, self.rq, self.cooker, self.stampcache, self, summary=False)
 
-        for (tid, harddepfail, origvalid) in update_tasks:
+        for (tid, harddepfail, origvalid) in update_tasks2:
             if tid in self.sqdata.valid and not origvalid:
                 hashequiv_logger.verbose("Setscene task %s became valid" % tid)
             if harddepfail:

bitbake/lib/bb/server/process.py

@@ -757,8 +757,11 @@ class ConnectionWriter(object):
                 process.queue_signals = True
                 self._send(obj)
                 process.queue_signals = False
-                for sig in process.signal_received.pop():
-                    process.handle_sig(sig, None)
+                try:
+                    for sig in process.signal_received.pop():
+                        process.handle_sig(sig, None)
+                except IndexError:
+                    pass
         else:
             self._send(obj)
 

bitbake/lib/bb/siggen.py

@@ -1,4 +1,6 @@
 #
+# Copyright BitBake Contributors
+#
 # SPDX-License-Identifier: GPL-2.0-only
 #
 
@@ -419,7 +421,7 @@ class SignatureGeneratorBasic(SignatureGenerator):
                 bb.error("Taskhash mismatch %s versus %s for %s" % (computed_taskhash, self.taskhash[tid], tid))
                 sigfile = sigfile.replace(self.taskhash[tid], computed_taskhash)
 
-        fd, tmpfile = tempfile.mkstemp(dir=os.path.dirname(sigfile), prefix="sigtask.")
+        fd, tmpfile = bb.utils.mkstemp(dir=os.path.dirname(sigfile), prefix="sigtask.")
         try:
             with bb.compress.zstd.open(fd, "wt", encoding="utf-8", num_threads=1) as f:
                 json.dump(data, f, sort_keys=True, separators=(",", ":"), cls=SetEncoder)
@@ -1026,7 +1028,6 @@ def compare_sigfiles(a, b, recursecb=None, color=False, collapsed=False):
                             # If a dependent hash changed, might as well print the line above and then defer to the changes in
                             # that hash since in all likelyhood, they're the same changes this task also saw.
                             output = [output[-1]] + recout
-                            break
 
     a_taint = a_data.get('taint', None)
     b_taint = b_data.get('taint', None)

bitbake/lib/bb/tests/compression.py

@@ -1,4 +1,6 @@
 #
+# Copyright BitBake Contributors
+#
 # SPDX-License-Identifier: GPL-2.0-only
 #
 

bitbake/lib/bb/tests/cooker.py

@@ -1,6 +1,8 @@
 #
 # BitBake Tests for cooker.py
 #
+# Copyright BitBake Contributors
+#
 # SPDX-License-Identifier: GPL-2.0-only
 #
 

bitbake/lib/bb/tests/fetch.py

@@ -1834,7 +1834,7 @@ class GitShallowTest(FetcherTest):
         self.add_empty_file('bsub', cwd=smdir)
 
         self.git('submodule init', cwd=self.srcdir)
-        self.git('submodule add file://%s' % smdir, cwd=self.srcdir)
+        self.git('-c protocol.file.allow=always submodule add file://%s' % smdir, cwd=self.srcdir)
         self.git('submodule update', cwd=self.srcdir)
         self.git('commit -m submodule -a', cwd=self.srcdir)
 
@@ -1864,7 +1864,7 @@ class GitShallowTest(FetcherTest):
         self.add_empty_file('bsub', cwd=smdir)
 
         self.git('submodule init', cwd=self.srcdir)
-        self.git('submodule add file://%s' % smdir, cwd=self.srcdir)
+        self.git('-c protocol.file.allow=always submodule add file://%s' % smdir, cwd=self.srcdir)
         self.git('submodule update', cwd=self.srcdir)
         self.git('commit -m submodule -a', cwd=self.srcdir)
 

bitbake/lib/bb/tests/parse.py

@@ -194,3 +194,26 @@ deltask ${EMPTYVAR}
         self.assertTrue('addtask ignored: " do_patch"' in stdout)
         #self.assertTrue('dependent task do_foo for do_patch does not exist' in stdout)
 
+    broken_multiline_comment = """
+# First line of comment \\
+# Second line of comment \\
+
+"""
+    def test_parse_broken_multiline_comment(self):
+        f = self.parsehelper(self.broken_multiline_comment)
+        with self.assertRaises(bb.BBHandledException):
+            d = bb.parse.handle(f.name, self.d)['']
+
+
+    comment_in_var = """
+VAR = " \\
+    SOMEVAL \\
+#   some comment \\
+    SOMEOTHERVAL \\
+"
+"""
+    def test_parse_comment_in_var(self):
+        f = self.parsehelper(self.comment_in_var)
+        with self.assertRaises(bb.BBHandledException):
+            d = bb.parse.handle(f.name, self.d)['']
+

bitbake/lib/bb/utils.py

@@ -28,6 +28,8 @@ import signal
 import collections
 import copy
 import ctypes
+import random
+import tempfile
 from subprocess import getstatusoutput
 from contextlib import contextmanager
 from ctypes import cdll
@@ -429,12 +431,14 @@ def better_eval(source, locals, extraglobals = None):
     return eval(source, ctx, locals)
 
 @contextmanager
-def fileslocked(files):
+def fileslocked(files, *args, **kwargs):
     """Context manager for locking and unlocking file locks."""
     locks = []
     if files:
         for lockfile in files:
-            locks.append(bb.utils.lockfile(lockfile))
+            l = bb.utils.lockfile(lockfile, *args, **kwargs)
+            if l is not None:
+                locks.append(l)
 
     try:
         yield
@@ -692,8 +696,8 @@ def remove(path, recurse=False, ionice=False):
         return
     if recurse:
         for name in glob.glob(path):
-            if _check_unsafe_delete_path(path):
-                raise Exception('bb.utils.remove: called with dangerous path "%s" and recurse=True, refusing to delete!' % path)
+            if _check_unsafe_delete_path(name):
+                raise Exception('bb.utils.remove: called with dangerous path "%s" and recurse=True, refusing to delete!' % name)
         # shutil.rmtree(name) would be ideal but its too slow
         cmd = []
         if ionice:
@@ -751,7 +755,7 @@ def movefile(src, dest, newmtime = None, sstat = None):
         if not sstat:
             sstat = os.lstat(src)
     except Exception as e:
-        print("movefile: Stating source file failed...", e)
+        logger.warning("movefile: Stating source file failed...", e)
         return None
 
     destexists = 1
@@ -779,7 +783,7 @@ def movefile(src, dest, newmtime = None, sstat = None):
             os.unlink(src)
             return os.lstat(dest)
         except Exception as e:
-            print("movefile: failed to properly create symlink:", dest, "->", target, e)
+            logger.warning("movefile: failed to properly create symlink:", dest, "->", target, e)
             return None
 
     renamefailed = 1
@@ -796,7 +800,7 @@ def movefile(src, dest, newmtime = None, sstat = None):
         except Exception as e:
             if e.errno != errno.EXDEV:
                 # Some random error.
-                print("movefile: Failed to move", src, "to", dest, e)
+                logger.warning("movefile: Failed to move", src, "to", dest, e)
                 return None
             # Invalid cross-device-link 'bind' mounted or actually Cross-Device
 
@@ -808,13 +812,13 @@ def movefile(src, dest, newmtime = None, sstat = None):
                 bb.utils.rename(destpath + "#new", destpath)
                 didcopy = 1
             except Exception as e:
-                print('movefile: copy', src, '->', dest, 'failed.', e)
+                logger.warning('movefile: copy', src, '->', dest, 'failed.', e)
                 return None
         else:
             #we don't yet handle special, so we need to fall back to /bin/mv
             a = getstatusoutput("/bin/mv -f " + "'" + src + "' '" + dest + "'")
             if a[0] != 0:
-                print("movefile: Failed to move special file:" + src + "' to '" + dest + "'", a)
+                logger.warning("movefile: Failed to move special file:" + src + "' to '" + dest + "'", a)
                 return None # failure
         try:
             if didcopy:
@@ -822,7 +826,7 @@ def movefile(src, dest, newmtime = None, sstat = None):
                 os.chmod(destpath, stat.S_IMODE(sstat[stat.ST_MODE])) # Sticky is reset on chown
                 os.unlink(src)
         except Exception as e:
-            print("movefile: Failed to chown/chmod/unlink", dest, e)
+            logger.warning("movefile: Failed to chown/chmod/unlink", dest, e)
             return None
 
     if newmtime:
@@ -1754,3 +1758,22 @@ def is_local_uid(uid=''):
             if str(uid) == line_split[2]:
                 return True
     return False
+
+def mkstemp(suffix=None, prefix=None, dir=None, text=False):
+    """
+    Generates a unique filename, independent of time.
+
+    mkstemp() in glibc (at least) generates unique file names based on the
+    current system time. When combined with highly parallel builds, and
+    operating over NFS (e.g. shared sstate/downloads) this can result in
+    conflicts and race conditions.
+
+    This function adds additional entropy to the file name so that a collision
+    is independent of time and thus extremely unlikely.
+    """
+    entropy = "".join(random.choices("abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890", k=20))
+    if prefix:
+        prefix = prefix + entropy
+    else:
+        prefix = tempfile.gettempprefix() + entropy
+    return tempfile.mkstemp(suffix=suffix, prefix=prefix, dir=dir, text=text)

bitbake/lib/bblayers/__init__.py

@@ -1,4 +1,6 @@
 #
+# Copyright BitBake Contributors
+#
 # SPDX-License-Identifier: GPL-2.0-only
 #
 

bitbake/lib/bblayers/action.py

@@ -1,4 +1,6 @@
 #
+# Copyright BitBake Contributors
+#
 # SPDX-License-Identifier: GPL-2.0-only
 #
 

bitbake/lib/bblayers/common.py

@@ -1,4 +1,6 @@
 #
+# Copyright BitBake Contributors
+#
 # SPDX-License-Identifier: GPL-2.0-only
 #
 

bitbake/lib/bblayers/layerindex.py

@@ -1,4 +1,6 @@
 #
+# Copyright BitBake Contributors
+#
 # SPDX-License-Identifier: GPL-2.0-only
 #
 

bitbake/lib/bblayers/query.py

@@ -1,4 +1,6 @@
 #
+# Copyright BitBake Contributors
+#
 # SPDX-License-Identifier: GPL-2.0-only
 #
 

bitbake/lib/prserv/__init__.py

@@ -1,4 +1,6 @@
 #
+# Copyright BitBake Contributors
+#
 # SPDX-License-Identifier: GPL-2.0-only
 #
 

bitbake/lib/prserv/client.py

@@ -1,4 +1,6 @@
 #
+# Copyright BitBake Contributors
+#
 # SPDX-License-Identifier: GPL-2.0-only
 #
 

bitbake/lib/prserv/db.py

@@ -1,4 +1,6 @@
 #
+# Copyright BitBake Contributors
+#
 # SPDX-License-Identifier: GPL-2.0-only
 #
 

bitbake/lib/prserv/serv.py

@@ -1,4 +1,6 @@
 #
+# Copyright BitBake Contributors
+#
 # SPDX-License-Identifier: GPL-2.0-only
 #
 

bitbake/lib/toaster/manage.py

@@ -1,5 +1,7 @@
 #!/usr/bin/env python3
 #
+# Copyright BitBake Contributors
+#
 # SPDX-License-Identifier: GPL-2.0-only
 #
 

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

@@ -42,7 +42,7 @@
   <!-- Releases available -->
   <object model="orm.release" pk="1">
     <field type="CharField" name="name">kirkstone</field>
-    <field type="CharField" name="description">Yocto Project 3.5 "Kirkstone"</field>
+    <field type="CharField" name="description">Yocto Project 4.0 "Kirkstone"</field>
     <field rel="ManyToOneRel" to="orm.bitbakeversion" name="bitbake_version">1</field>
     <field type="CharField" name="branch_name">kirkstone</field>
     <field type="TextField" name="helptext">Toaster will run your builds using the tip of the &lt;a href="https://git.yoctoproject.org/cgit/cgit.cgi/poky/log/?h=kirkstone"&gt;Yocto Project Kirkstone branch&lt;/a&gt;.</field>

documentation/Makefile

@@ -47,11 +47,9 @@ clean:
 	@rm -rf $(BUILDDIR) $(PNGs) $(PDFs) poky.yaml sphinx-static/switchers.js
 
 epub: $(PNGs)
-	$(SOURCEDIR)/set_versions.py
 	@$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
 
 latexpdf: $(PDFs)
-	$(SOURCEDIR)/set_versions.py
 	@$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
 
 all: html epub latexpdf

documentation/brief-yoctoprojectqs/index.rst

@@ -64,6 +64,7 @@ following requirements:
    -  tar &MIN_TAR_VERSION; or greater
    -  Python &MIN_PYTHON_VERSION; or greater.
    -  gcc &MIN_GCC_VERSION; or greater.
+   -  GNU make &MIN_MAKE_VERSION; or greater
 
 If your build host does not meet any of these three listed version
 requirements, you can take steps to prepare the system so that you
@@ -255,13 +256,8 @@ an entire Linux distribution, including the toolchain, from source.
 
          BB_SIGNATURE_HANDLER = "OEEquivHash"
          BB_HASHSERVE = "auto"
-         BB_HASHSERVE_UPSTREAM = "typhoon.yocto.io:8687"
-         SSTATE_MIRRORS ?= "file://.* https://sstate.yoctoproject.org/&YOCTO_DOC_VERSION;/PATH;downloadfilename=PATH"
-
-      The above settings assumed the use of Yocto Project &YOCTO_DOC_VERSION;.
-      If you are using the development version instead, set :term:`SSTATE_MIRRORS` as follows::
-
-         SSTATE_MIRRORS ?= "file://.* https://sstate.yoctoproject.org/dev/PATH;downloadfilename=PATH"
+         BB_HASHSERVE_UPSTREAM = "hashserv.yocto.io:8687"
+         SSTATE_MIRRORS ?= "file://.* https://sstate.yoctoproject.org/all/PATH;downloadfilename=PATH"
 
 #. **Start the Build:** Continue with the following command to build an OS
    image for the target, which is ``core-image-sato`` in this example:
@@ -424,9 +420,9 @@ information including the website, wiki pages, and user manuals:
    development documentation, and access to a rich Yocto Project
    Development Community into which you can tap.
 
--  **Video Seminar:** The `Introduction to the Yocto Project and BitBake, Part 1
+-  **Video Seminar:** The `Introduction to the Yocto Project and Bitbake, Part 1
    <https://youtu.be/yuE7my3KOpo>`__ and
-   `Introduction to the Yocto Project and BitBake, Part 2
+   `Introduction to the Yocto Project and Bitbake, Part 2
    <https://youtu.be/iZ05TTyzGHk>`__ videos offer a video seminar
    introducing you to the most important aspects of developing a
    custom embedded Linux distribution with the Yocto Project.

documentation/bsp-guide/bsp.rst

@@ -725,7 +725,6 @@ workflow.
 
 .. image:: figures/bsp-dev-flow.png
    :align: center
-   :width: 70%
 
 #. *Set up Your Host Development System to Support Development Using the
    Yocto Project*: See the ":ref:`dev-manual/start:preparing the build host`"

documentation/conf.py

@@ -19,7 +19,7 @@ try:
     import yaml
 except ImportError:
     sys.stderr.write("The Yocto Project Sphinx documentation requires PyYAML.\
-    \nPlease make sure to install pyyaml Python package.\n")
+    \nPlease make sure to install pyyaml python package.\n")
     sys.exit(1)
 
 # current_version = "dev"
@@ -106,9 +106,10 @@ extlinks = {
     '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),
+    'wikipedia': ('https://en.wikipedia.org/wiki/%s', None),
 }
 
-# Intersphinx config to use cross reference with BitBake user manual
+# Intersphinx config to use cross reference with Bitbake user manual
 intersphinx_mapping = {
     'bitbake': ('https://docs.yoctoproject.org/bitbake/' + bitbake_version, None)
 }
@@ -129,7 +130,7 @@ try:
     }
 except ImportError:
     sys.stderr.write("The Sphinx sphinx_rtd_theme HTML theme was not found.\
-    \nPlease make sure to install the sphinx_rtd_theme Python package.\n")
+    \nPlease make sure to install the sphinx_rtd_theme python package.\n")
     sys.exit(1)
 
 html_logo = 'sphinx-static/YoctoProject_Logo_RGB.jpg'

documentation/dev-manual/common-tasks.rst

@@ -1125,7 +1125,6 @@ The remainder of the section provides details for the steps.
 
 .. image:: figures/recipe-workflow.png
    :align: center
-   :width: 50%
 
 Locate or Automatically Create a Base Recipe
 --------------------------------------------
@@ -2563,7 +2562,7 @@ Recipe Syntax
 Understanding recipe file syntax is important for writing recipes. The
 following list overviews the basic items that make up a BitBake recipe
 file. For more complete BitBake syntax descriptions, see the
-":doc:`bitbake-user-manual/bitbake-user-manual-metadata`"
+":doc:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata`"
 chapter of the BitBake User Manual.
 
 -  *Variable Assignments and Manipulations:* Variable assignments allow
@@ -3619,7 +3618,7 @@ Yocto Project Overview and Concepts Manual.
 The following figure and list overviews the build process:
 
 .. image:: figures/bitbake-build-flow.png
-   :width: 100%
+   :align: center
 
 1. *Set up Your Host Development System to Support Development Using the
    Yocto Project*: See the ":doc:`start`" section for options on how to get a
@@ -3737,7 +3736,6 @@ Follow these steps to set up and execute multiple configuration builds:
 
    .. image:: figures/multiconfig_files.png
       :align: center
-      :width: 50%
 
    The reason for this required file hierarchy is because the :term:`BBPATH`
    variable is not constructed until the layers are parsed.
@@ -4828,7 +4826,7 @@ configuration would be as follows::
    require conf/multilib.conf
    MULTILIBS = "multilib:lib32"
    DEFAULTTUNE:virtclass-multilib-lib32 = "x86"
-   IMAGE_INSTALL:append = " lib32-glib-2.0"
+   IMAGE_INSTALL:append = "lib32-glib-2.0"
 
 This example enables an additional library named
 ``lib32`` alongside the normal target packages. When combining these
@@ -5394,7 +5392,7 @@ create the properly partitioned image.
 
 The ``wic`` command generates partitioned images from existing
 OpenEmbedded build artifacts. Image generation is driven by partitioning
-commands contained in an OpenEmbedded kickstart file (``.wks``)
+commands contained in an Openembedded kickstart file (``.wks``)
 specified either directly on the command line or as one of a selection
 of canned kickstart files as shown with the ``wic list images`` command
 in the
@@ -5466,7 +5464,7 @@ system needs to meet the following requirements:
 
 -  You need to have the build artifacts already available, which
    typically means that you must have already created an image using the
-   OpenEmbedded build system (e.g. ``core-image-minimal``). While it
+   Openembedded build system (e.g. ``core-image-minimal``). While it
    might seem redundant to generate an image in order to create an image
    using Wic, the current version of Wic requires the artifacts in the
    form generated by the OpenEmbedded build system.
@@ -5481,9 +5479,7 @@ system needs to meet the following requirements:
    variable.
 
 -  Include the name of the :ref:`wic kickstart file <openembedded-kickstart-wks-reference>`
-   as part of the :term:`WKS_FILE` variable. If multiple candidate files can
-   be provided by different layers, specify all the possible names through the
-   :term:`WKS_FILES` variable instead.
+   as part of the :term:`WKS_FILE` variable
 
 Getting Help
 ------------
@@ -5550,7 +5546,7 @@ Operational Modes
 -----------------
 
 You can use Wic in two different modes, depending on how much control
-you need for specifying the OpenEmbedded build artifacts that are used
+you need for specifying the Openembedded build artifacts that are used
 for creating the image: Raw and Cooked:
 
 -  *Raw Mode:* You explicitly specify build artifacts through Wic
@@ -5884,7 +5880,7 @@ Directory onto a USB stick, or whatever media for which you built your
 image, and boot from the media. You can write the image by using
 ``bmaptool`` or ``dd``::
 
-   $ oe-run-native bmap-tools-native bmaptool copy mkefidisk-201804191017-sda.direct /dev/sdX
+   $ oe-run-native bmaptool copy mkefidisk-201804191017-sda.direct /dev/sdX
 
 or ::
 
@@ -6436,10 +6432,10 @@ files (i.e. ``local.conf`` and ``bblayers.conf``) that are created in a
 new build directory.
 
 The OpenEmbedded build system uses the environment variable
-:term:`TEMPLATECONF` to locate the directory from which it gathers
+``TEMPLATECONF`` to locate the directory from which it gathers
 configuration information that ultimately ends up in the
 :term:`Build Directory` ``conf`` directory.
-By default, :term:`TEMPLATECONF` is set as follows in the ``poky``
+By default, ``TEMPLATECONF`` is set as follows in the ``poky``
 repository::
 
    TEMPLATECONF=${TEMPLATECONF:-meta-poky/conf}
@@ -6454,7 +6450,7 @@ list of BitBake targets when running the setup script.
 
 To override these default configuration files with configurations you
 want used within every new Build Directory, simply set the
-:term:`TEMPLATECONF` variable to your directory. The :term:`TEMPLATECONF`
+``TEMPLATECONF`` variable to your directory. The ``TEMPLATECONF``
 variable is set in the ``.templateconf`` file, which is in the top-level
 :term:`Source Directory` folder
 (e.g. ``poky``). Edit the ``.templateconf`` so that it can locate your
@@ -6494,7 +6490,7 @@ either of the setup scripts::
 
 Changing the listed common targets is as easy as editing your version of
 ``conf-notes.txt`` in your custom template configuration directory and
-making sure you have :term:`TEMPLATECONF` set to your directory.
+making sure you have ``TEMPLATECONF`` set to your directory.
 
 Conserving Disk Space
 =====================
@@ -7695,7 +7691,7 @@ On a browser,
 go to ``http://192.168.7.2:3000`` and you see the following:
 
 .. image:: figures/cute-files-npm-example.png
-   :width: 100%
+   :align: center
 
 You can find the recipe in ``workspace/recipes/cute-files``. You can use
 the recipe in any layer you choose.
@@ -8219,7 +8215,6 @@ variable. Here is an example abbreviated listing:
 
 .. image:: figures/buildhistory.png
    :align: center
-   :width: 50%
 
 At the top level, there is a ``metadata-revs`` file that lists the
 revisions of the repositories for the enabled layers when the build was
@@ -8560,7 +8555,7 @@ instruction in the ``README`` file
 Here is a sample screenshot of the interface:
 
 .. image:: figures/buildhistory-web.png
-   :width: 100%
+   :align: center
 
 Performing Automated Runtime Testing
 ====================================
@@ -8906,21 +8901,21 @@ You can start the tests automatically or manually:
 
       bitbake -c testimage image
 
-All test files reside in ``meta/lib/oeqa/runtime`` in the
+All test files reside in ``meta/lib/oeqa/runtime/cases`` in the
 :term:`Source Directory`. A test name maps
 directly to a Python module. Each test module may contain a number of
 individual tests. Tests are usually grouped together by the area tested
-(e.g tests for systemd reside in ``meta/lib/oeqa/runtime/systemd.py``).
+(e.g tests for systemd reside in ``meta/lib/oeqa/runtime/cases/systemd.py``).
 
 You can add tests to any layer provided you place them in the proper
 area and you extend :term:`BBPATH` in
 the ``local.conf`` file as normal. Be sure that tests reside in
-``layer/lib/oeqa/runtime``.
+``layer/lib/oeqa/runtime/cases``.
 
 .. note::
 
    Be sure that module names do not collide with module names used in
-   the default set of test modules in ``meta/lib/oeqa/runtime``.
+   the default set of test modules in ``meta/lib/oeqa/runtime/cases``.
 
 You can change the set of tests run by appending or overriding
 :term:`TEST_SUITES` variable in
@@ -9013,7 +9008,7 @@ Writing New Tests
 As mentioned previously, all new test files need to be in the proper
 place for the build system to find them. New tests for additional
 functionality outside of the core should be added to the layer that adds
-the functionality, in ``layer/lib/oeqa/runtime`` (as long as
+the functionality, in ``layer/lib/oeqa/runtime/cases`` (as long as
 :term:`BBPATH` is extended in the
 layer's ``layer.conf`` file as normal). Just remember the following:
 
@@ -9219,7 +9214,7 @@ section:
    to run specific tasks in the build chain. It can be useful to run
    tasks "out-of-order" when trying isolate build issues.
 
--  ":ref:`dev-manual/common-tasks:general BitBake problems`" describes how
+-  ":ref:`dev-manual/common-tasks:general bitbake problems`" describes how
    to use BitBake's ``-D`` debug output option to reveal more about what
    BitBake is doing during the build.
 
@@ -9414,7 +9409,7 @@ format and can be converted to images (e.g. using the ``dot`` tool from
 
    -  DOT files use a plain text format. The graphs generated using the
       ``bitbake -g`` command are often so large as to be difficult to
-      read without special pruning (e.g. with BitBake's ``-I`` option)
+      read without special pruning (e.g. with Bitbake's ``-I`` option)
       and processing. Despite the form and size of the graphs, the
       corresponding ``.dot`` files can still be possible to read and
       provide useful information.
@@ -10182,9 +10177,10 @@ debugger.
 
 2. *Configure the system to include gdbserver in the target filesystem:*
 
-   Make the following addition in your ``local.conf`` file::
+   Make the following addition in either your ``local.conf`` file or in
+   an image recipe::
 
-      EXTRA_IMAGE_FEATURES:append = " tools-debug"
+      IMAGE_INSTALL:append = " gdbserver"
 
    The change makes
    sure the ``gdbserver`` package is included.
@@ -10231,14 +10227,14 @@ debugger.
 
       $ mkdir debugfs
       $ cd debugfs
-      $ tar xvfj build-dir/tmp/deploy/images/machine/image.rootfs.tar.bz2
-      $ tar xvfj build-dir/tmp/deploy/images/machine/image-dbg.rootfs.tar.bz2
+      $ tar xvfj build-dir/tmp-glibc/deploy/images/machine/image.rootfs.tar.bz2
+      $ tar xvfj build-dir/tmp-glibc/deploy/images/machine/image-dbg.rootfs.tar.bz2
 
 5. *Set up GDB:*
 
    Install the SDK (if you built one) and then source the correct
    environment file. Sourcing the environment file puts the SDK in your
-   ``PATH`` environment variable and sets ``$GDB`` to the SDK's debugger.
+   ``PATH`` environment variable.
 
    If you are using the build system, Gdb is located in
    `build-dir`\ ``/tmp/sysroots/``\ `host`\ ``/usr/bin/``\ `architecture`\ ``/``\ `architecture`\ ``-gdb``
@@ -10317,20 +10313,24 @@ debug on the target hardware.
 
 To support this kind of debugging, you need do the following:
 
--  Ensure that GDB is on the target. You can do this by making
-   the following addition to your ``local.conf`` file::
+-  Ensure that GDB is on the target. You can do this by adding "gdb" to
+   :term:`IMAGE_INSTALL`::
 
-      EXTRA_IMAGE_FEATURES:append = " tools-debug"
+      IMAGE_INSTALL:append = " gdb"
 
--  Ensure that debug symbols are present. You can do so by adding the
-   corresponding ``-dbg`` package to :term:`IMAGE_INSTALL`::
+   Alternatively, you can add "tools-debug" to :term:`IMAGE_FEATURES`::
 
-      IMAGE_INSTALL:append = " packagename-dbg"
+      IMAGE_FEATURES:append = " tools-debug"
 
-   Alternatively, you can add the following to ``local.conf`` to include
+-  Ensure that debug symbols are present. You can make sure these
+   symbols are present by installing ``-dbg``::
+
+      IMAGE_INSTALL:append = "packagename-dbg"
+
+   Alternatively, you can do the following to include
    all the debug symbols::
 
-      EXTRA_IMAGE_FEATURES:append = " dbg-pkgs"
+      IMAGE_FEATURES:append = " dbg-pkgs"
 
 .. note::
 
@@ -10565,7 +10565,7 @@ used testing branches for OpenEmbedded-Core are as follows:
 
 -  *poky "master-next" branch:* This branch is part of the
    :yocto_git:`poky </poky/>` repository and combines proposed
-   changes to BitBake, the core metadata and the poky distro.
+   changes to bitbake, the core metadata and the poky distro.
 
 Similarly, stable branches maintained by the project may have corresponding
 ``-next`` branches which collect proposed changes. For example,
@@ -11426,39 +11426,6 @@ layers (recipes, configuration files, and so forth) enables you to meet
 your requirements to include the scripts to control compilation as well
 as any modifications to the original source.
 
-Providing spdx files
-~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The spdx module has been integrated to a layer named meta-spdxscanner.
-meta-spdxscanner provides several kinds of scanner. If you want to enable
-this function, you have to follow the following steps:
-
-1. Add meta-spdxscanner layer into ``bblayers.conf``. 
-
-2. Refer to the README in meta-spdxscanner to setup the environment (e.g, 
-   setup a fossology server) needed for the scanner.
-
-3. Meta-spdxscanner provides several methods within the bbclass to create spdx files.
-   Please choose one that you want to use and enable the spdx task. You have to
-   add some config options in ``local.conf`` file in your :term:`Build
-   Directory`. Here is an example showing how to generate spdx files
-   during BitBake using the fossology-python.bbclass::
-
-      # Select fossology-python.bbclass.
-      INHERIT += "fossology-python"
-      # For fossology-python.bbclass, TOKEN is necessary, so, after setup a
-      # Fossology server, you have to create a token.
-      TOKEN = "eyJ0eXAiO..."
-      # The fossology server is necessary for fossology-python.bbclass.
-      FOSSOLOGY_SERVER = "http://xx.xx.xx.xx:8081/repo"
-      # If you want to upload the source code to a special folder:
-      FOLDER_NAME = "xxxx" //Optional
-      # If you don't want to put spdx files in tmp/deploy/spdx, you can enable:
-      SPDX_DEPLOY_DIR = "${DEPLOY_DIR}" //Optional
-
-For more usage information refer to :yocto_git:`the meta-spdxscanner repository
-</meta-spdxscanner/>`.
-
 Compliance Limitations with Executables Built from Static Libraries
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -11499,21 +11466,92 @@ the license from the fetched source::
 Checking for Vulnerabilities
 ============================
 
-Vulnerabilities in images
--------------------------
+Vulnerabilities in Poky and OE-Core
+-----------------------------------
 
 The Yocto Project has an infrastructure to track and address unfixed
 known security vulnerabilities, as tracked by the public
-`Common Vulnerabilities and Exposures (CVE) <https://en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures>`__
+:wikipedia:`Common Vulnerabilities and Exposures (CVE) <Common_Vulnerabilities_and_Exposures>`
 database.
 
-To know which packages are vulnerable to known security vulnerabilities,
-add the following setting to your configuration::
+The Yocto Project maintains a `list of known vulnerabilities
+<https://autobuilder.yocto.io/pub/non-release/patchmetrics/>`__
+for packages in Poky and OE-Core, tracking the evolution of the number of
+unpatched CVEs and the status of patches. Such information is available for
+the current development version and for each supported release.
+
+Security is a process, not a product, and thus at any time, a number of security
+issues may be impacting Poky and OE-Core. It is up to the maintainers, users,
+contributors and anyone interested in the issues to investigate and possibly fix them by
+updating software components to newer versions or by applying patches to address them.
+It is recommended to work with Poky and OE-Core upstream maintainers and submit
+patches to fix them, see ":ref:`dev-manual/common-tasks:submitting a change to the yocto project`" for details.
+
+Vulnerability check at build time
+---------------------------------
+
+To enable a check for CVE security vulnerabilities using :ref:`cve-check <ref-classes-cve-check>` in the specific image
+or target you are building, add the following setting to your configuration::
 
    INHERIT += "cve-check"
 
-This way, at build time, BitBake will warn you about known CVEs
-as in the example below::
+The CVE database contains some old incomplete entries which have been
+deemed not to impact Poky or OE-Core. These CVE entries can be excluded from the
+check using build configuration::
+
+   include conf/distro/include/cve-extra-exclusions.inc
+
+With this CVE check enabled, BitBake build will try to map each compiled software component
+recipe name and version information to the CVE database and generate recipe and
+image specific reports. These reports will contain:
+
+-  metadata about the software component like names and versions
+
+-  metadata about the CVE issue such as description and NVD link
+
+-  for each software component, a list of CVEs which are possibly impacting this version
+
+-  status of each CVE: ``Patched``, ``Unpatched`` or ``Ignored``
+
+The status ``Patched`` means that a patch file to address the security issue has been
+applied. ``Unpatched`` status means that no patches to address the issue have been
+applied and that the issue needs to be investigated. ``Ignored`` means that after
+analysis, it has been deemed to ignore the issue as it for example affects
+the software component on a different operating system platform.
+
+After a build with CVE check enabled, reports for each compiled source recipe will be
+found in ``build/tmp/deploy/cve``.
+
+For example the CVE check report for the ``flex-native`` recipe looks like::
+
+   $ cat poky/build/tmp/deploy/cve/flex-native
+   LAYER: meta
+   PACKAGE NAME: flex-native
+   PACKAGE VERSION: 2.6.4
+   CVE: CVE-2016-6354
+   CVE STATUS: Patched
+   CVE SUMMARY: Heap-based buffer overflow in the yy_get_next_buffer function in Flex before 2.6.1 might allow context-dependent attackers to cause a denial of service or possibly execute arbitrary code via vectors involving num_to_read.
+   CVSS v2 BASE SCORE: 7.5
+   CVSS v3 BASE SCORE: 9.8
+   VECTOR: NETWORK
+   MORE INFORMATION: https://nvd.nist.gov/vuln/detail/CVE-2016-6354
+
+   LAYER: meta
+   PACKAGE NAME: flex-native
+   PACKAGE VERSION: 2.6.4
+   CVE: CVE-2019-6293
+   CVE STATUS: Ignored
+   CVE SUMMARY: An issue was discovered in the function mark_beginning_as_normal in nfa.c in flex 2.6.4. There is a stack exhaustion problem caused by the mark_beginning_as_normal function making recursive calls to itself in certain scenarios involving lots of '*' characters. Remote attackers could leverage this vulnerability to cause a denial-of-service.
+   CVSS v2 BASE SCORE: 4.3
+   CVSS v3 BASE SCORE: 5.5
+   VECTOR: NETWORK
+   MORE INFORMATION: https://nvd.nist.gov/vuln/detail/CVE-2019-6293
+
+For images, a summary of all recipes included in the image and their CVEs is also
+generated in textual and JSON formats. These ``.cve`` and ``.json`` reports can be found
+in the ``tmp/deploy/images`` directory for each compiled image.
+
+At build time CVE check will also throw warnings about ``Unpatched`` CVEs::
 
    WARNING: flex-2.6.4-r0 do_cve_check: Found unpatched CVE (CVE-2019-6293), for more information check /poky/build/tmp/work/core2-64-poky-linux/flex/2.6.4-r0/temp/cve.log
    WARNING: libarchive-3.5.1-r0 do_cve_check: Found unpatched CVE (CVE-2021-36976), for more information check /poky/build/tmp/work/core2-64-poky-linux/libarchive/3.5.1-r0/temp/cve.log
@@ -11522,21 +11560,46 @@ It is also possible to check the CVE status of individual packages as follows::
 
    bitbake -c cve_check flex libarchive
 
-Note that OpenEmbedded-Core keeps a list of known unfixed CVE issues which can
-be ignored. You can pass this list to the check as follows::
+Fixing CVE product name and version mappings
+--------------------------------------------
 
-   bitbake -c cve_check libarchive -R conf/distro/include/cve-extra-exclusions.inc
+By default, :ref:`cve-check <ref-classes-cve-check>` uses the recipe name :term:`BPN` as CVE
+product name when querying the CVE database. If this mapping contains false positives, e.g.
+some reported CVEs are not for the software component in question, or false negatives like
+some CVEs are not found to impact the recipe when they should, then the problems can be
+in the recipe name to CVE product mapping. These mapping issues can be fixed by setting
+the :term:`CVE_PRODUCT` variable inside the recipe. This defines the name of the software component in the
+upstream `NIST CVE database <https://nvd.nist.gov/>`__.
 
-Enabling vulnerabily tracking in recipes
-----------------------------------------
+The variable supports using vendor and product names like this::
 
-The :term:`CVE_PRODUCT` variable defines the name used to match the recipe name
-against the name in the upstream `NIST CVE database <https://nvd.nist.gov/>`__.
+   CVE_PRODUCT = "flex_project:flex"
 
-Editing recipes to fix vulnerabilities
---------------------------------------
+In this example the vendor name used in the CVE database is ``flex_project`` and the
+product is ``flex``. With this setting the ``flex`` recipe only maps to this specific
+product and not products from other vendors with same name ``flex``.
 
-To fix a given known vulnerability, you need to add a patch file to your recipe. Here's
+Similarly, when the recipe version :term:`PV` is not compatible with software versions used by
+the upstream software component releases and the CVE database, these can be fixed using
+the :term:`CVE_VERSION` variable.
+
+Note that if the CVE entries in the NVD database contain bugs or have missing or incomplete
+information, it is recommended to fix the information there directly instead of working
+around the issues possibly for a long time in Poky and OE-Core side recipes. Feedback to
+NVD about CVE entries can be provided through the `NVD contact form <https://nvd.nist.gov/info/contact-form>`__.
+
+Fixing vulnerabilities in recipes
+---------------------------------
+
+If a CVE security issue impacts a software component, it can be fixed by updating to a newer
+version of the software component or by applying a patch. For Poky and OE-Core master branches, updating
+to a newer software component release with fixes is the best option, but patches can be applied
+if releases are not yet available.
+
+For stable branches, it is preferred to apply patches for the issues. For some software
+components minor version updates can also be applied if they are backwards compatible.
+
+Here is an example of fixing CVE security issues with patch files,
 an example from the :oe_layerindex:`ffmpeg recipe</layerindex/recipe/47350>`::
 
    SRC_URI = "https://www.ffmpeg.org/releases/${BP}.tar.xz \
@@ -11548,31 +11611,21 @@ an example from the :oe_layerindex:`ffmpeg recipe</layerindex/recipe/47350>`::
               file://fix-CVE-2020-22033-CVE-2020-22019.patch \
               file://fix-CVE-2021-33815.patch \
 
-The :ref:`cve-check <ref-classes-cve-check>` class defines two ways of
-supplying a patch for a given CVE. The first
-way is to use a patch filename that matches the below pattern::
+A good practice is to include the CVE identifier in both the patch file name
+and inside the patch file commit message using the format::
 
-   cve_file_name_match = re.compile(".*([Cc][Vv][Ee]\-\d{4}\-\d+)")
+   CVE: CVE-2020-22033
 
-As shown in the example above, multiple CVE IDs can appear in a patch filename,
-but the :ref:`cve-check <ref-classes-cve-check>` class will only consider
-the last CVE ID in the filename as patched.
+CVE checker will then capture this information and change the CVE status to ``Patched``
+in the generated reports.
 
-The second way to recognize a patched CVE ID is when a line matching the
-below pattern is found in any patch file provided by the recipe::
+If analysis shows that the CVE issue does not impact the recipe due to configuration, platform,
+version or other reasons, the CVE can be marked as ``Ignored`` using the :term:`CVE_CHECK_IGNORE` variable.
+As mentioned previously, if data in the CVE database is wrong, it is recommend to fix those
+issues in the CVE database directly.
 
-  cve_match = re.compile("CVE:( CVE\-\d{4}\-\d+)+")
-
-This allows a single patch file to address multiple CVE IDs at the same time.
-
-Of course, another way to fix vulnerabilities is to upgrade to a version
-of the package which is not impacted, typically a more recent one.
-The NIST database knows which versions are vulnerable and which ones
-are not.
-
-Last but not least, you can choose to ignore vulnerabilities through
-the :term:`CVE_CHECK_SKIP_RECIPE` and :term:`CVE_CHECK_IGNORE`
-variables.
+Recipes can be completely skipped by CVE check by including the recipe name in
+the :term:`CVE_CHECK_SKIP_RECIPE` variable.
 
 Implementation details
 ----------------------
@@ -11589,24 +11642,104 @@ file. The found CVE IDs are also considered as patched.
 Then, the code looks up all the CVE IDs in the NIST database for all the
 products defined in :term:`CVE_PRODUCT`. Then, for each found CVE:
 
- - If the package name (:term:`PN`) is part of
-   :term:`CVE_CHECK_SKIP_RECIPE`, it is considered as patched.
+-  If the package name (:term:`PN`) is part of
+   :term:`CVE_CHECK_SKIP_RECIPE`, it is considered as ``Patched``.
 
- - If the CVE ID is part of :term:`CVE_CHECK_IGNORE`, it is
-   considered as patched too.
+-  If the CVE ID is part of :term:`CVE_CHECK_IGNORE`, it is
+   set as ``Ignored``.
 
- - If the CVE ID is part of the patched CVE for the recipe, it is
-   already considered as patched.
+-  If the CVE ID is part of the patched CVE for the recipe, it is
+   already considered as ``Patched``.
 
- - Otherwise, the code checks whether the recipe version (:term:`PV`)
+-  Otherwise, the code checks whether the recipe version (:term:`PV`)
    is within the range of versions impacted by the CVE. If so, the CVE
-   is considered as unpatched.
+   is considered as ``Unpatched``.
 
 The CVE database is stored in :term:`DL_DIR` and can be inspected using
 ``sqlite3`` command as follows::
 
    sqlite3 downloads/CVE_CHECK/nvdcve_1.1.db .dump | grep CVE-2021-37462
 
+When analyzing CVEs, it is recommended to:
+
+-  study the latest information in `CVE database <https://nvd.nist.gov/vuln/search>`__.
+
+-  check how upstream developers of the software component addressed the issue, e.g.
+   what patch was applied, which upstream release contains the fix.
+
+-  check what other Linux distributions like `Debian <https://security-tracker.debian.org/tracker/>`__
+   did to analyze and address the issue.
+
+-  follow security notices from other Linux distributions.
+
+-  follow public `open source security mailing lists <https://oss-security.openwall.org/wiki/mailing-lists>`__ for
+   discussions and advance notifications of CVE bugs and software releases with fixes.
+
+Creating a Software Bill of Materials
+=====================================
+
+Once you are able to build an image for your project, once the licenses for
+each software component are all identified (see
+":ref:`dev-manual/common-tasks:working with licenses`") and once vulnerability
+fixes are applied (see ":ref:`dev-manual/common-tasks:checking
+for vulnerabilities`"), the OpenEmbedded build system can generate
+a description of all the components you used, their licenses, their dependencies,
+the changes that were applied and the known vulnerabilities that were fixed.
+
+This description is generated in the form of a *Software Bill of Materials*
+(:term:`SBOM`), using the :term:`SPDX` standard.
+
+When you release software, this is the most standard way to provide information
+about the Software Supply Chain of your software image and SDK. The
+:term:`SBOM` tooling is often used to ensure open source license compliance by
+providing the license texts used in the product which legal departments and end
+users can read in standardized format.
+
+:term:`SBOM` information is also critical to performing vulnerability exposure
+assessments, as all the components used in the Software Supply Chain are listed.
+
+The OpenEmbedded build system doesn't generate such information by default.
+To make this happen, you must inherit the
+:ref:`create-spdx <ref-classes-create-spdx>` class from a configuration file::
+
+   INHERIT += "create-spdx"
+
+You then get :term:`SPDX` output in JSON format as an
+``IMAGE-MACHINE.spdx.json`` file in ``tmp/deploy/images/MACHINE/`` inside the
+:term:`Build Directory`.
+
+This is a toplevel file accompanied by an ``IMAGE-MACHINE.spdx.index.json``
+containing an index of JSON :term:`SPDX` files for individual recipes, together
+with an ``IMAGE-MACHINE.spdx.tar.zst`` compressed archive containing all such
+files.
+
+The :ref:`create-spdx <ref-classes-create-spdx>` class offers options to include
+more information in the output :term:`SPDX` data, such as adding compressed
+archives of the files in the generated target packages
+(:term:`SPDX_ARCHIVE_PACKAGED`), adding a description of the source files
+handled by the target recipes (:term:`SPDX_INCLUDE_SOURCES`) and adding archives
+of these source files themselves (:term:`SPDX_ARCHIVE_SOURCES`).
+
+Though the toplevel :term:`SPDX` output is available in
+``tmp/deploy/images/MACHINE/`` inside the :term:`Build Directory`, ancillary
+generated files are available in ``tmp/deploy/spdx/MACHINE`` too, such as:
+
+-  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 the `tools page <https://spdx.dev/resources/tools/>`__ on the :term:`SPDX`
+project website for a list of tools to consume and transform the :term:`SPDX`
+data generated by the OpenEmbedded build system.
+
 Using the Error Reporting Tool
 ==============================
 

documentation/dev-manual/start.rst

@@ -496,7 +496,7 @@ your Yocto Project build host:
 
 6. *Optimize your WSLv2 storage often:* Due to the way storage is
    handled on WSLv2, the storage space used by the undelying Linux
-   distribution is not reflected immedately, and since BitBake heavily
+   distribution is not reflected immedately, and since bitbake heavily
    uses storage, after several builds, you may be unaware you are
    running out of space. WSLv2 uses a VHDX file for storage, this issue
    can be easily avoided by manually optimizing this file often, this

documentation/kernel-dev/common.rst

@@ -1062,7 +1062,7 @@ Section.
    contents::
 
       FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:"
-      SRC_URI:append = " file://0001-calibrate.c-Added-some-printk-statements.patch"
+      SRC_URI:append = "file://0001-calibrate.c-Added-some-printk-statements.patch"
 
    The :term:`FILESEXTRAPATHS` and :term:`SRC_URI` statements
    enable the OpenEmbedded build system to find the patch file.
@@ -1560,7 +1560,7 @@ source directory. Follow these steps to clean up the version string:
    on building the kernel image when using ``devtool``, see the
    ":ref:`kernel-dev/common:using \`\`devtool\`\` to patch the kernel`"
    section. For
-   information on building the kernel image when using BitBake, see the
+   information on building the kernel image when using Bitbake, see the
    ":ref:`kernel-dev/common:using traditional kernel development to patch the kernel`"
    section.
 

documentation/kernel-dev/concepts-appx.rst

@@ -221,7 +221,7 @@ the line-by-line code ``diff`` level is now a trivial operation.
 The following illustration shows the conceptual Yocto Linux kernel.
 
 .. image:: figures/kernel-architecture-overview.png
-   :width: 100%
+   :align: center
 
 In the illustration, the "Kernel.org Branch Point" marks the specific
 spot (or Linux kernel release) from which the Yocto Linux kernel is
@@ -318,13 +318,12 @@ tree specific to your kernel from which to generate the new kernel
 image.
 
 The following figure shows the temporary file structure created on your
-host system when you build the kernel using BitBake. This
+host system when you build the kernel using Bitbake. This
 :term:`Build Directory` contains all the
 source files used during the build.
 
 .. image:: figures/kernel-overview-2-generic.png
    :align: center
-   :width: 70%
 
 Again, for additional information on the Yocto Project kernel's
 architecture and its branching strategy, see the

documentation/kernel-dev/intro.rst

@@ -106,7 +106,7 @@ modification workflow. The illustration and accompanying list provide
 general information and references for further information.
 
 .. image:: figures/kernel-dev-flow.png
-   :width: 100%
+   :align: center
 
 1. *Set up Your Host Development System to Support Development Using the
    Yocto Project*: See the ":doc:`/dev-manual/start`" section in

documentation/migration-guides/migration-2.2.rst

@@ -70,7 +70,7 @@ Metadata Must Now Use Python 3 Syntax
 
 The metadata is now required to use Python 3 syntax. For help preparing
 metadata, see any of the many Python 3 porting guides available.
-Alternatively, you can reference the conversion commits for BitBake and
+Alternatively, you can reference the conversion commits for Bitbake and
 you can use :term:`OpenEmbedded-Core (OE-Core)` as a guide for changes. Following are
 particular areas of interest:
 

documentation/migration-guides/migration-2.7.rst

@@ -15,7 +15,7 @@ The following changes have been made to BitBake:
    functions (e.g. ``def funcname:``) in the metadata for tab
    indentation. If found, BitBake produces a warning.
 
--  BitBake now checks
+-  Bitbake now checks
    :term:`BBFILE_COLLECTIONS` for duplicate
    entries and triggers an error if any are found.
 

documentation/migration-guides/migration-3.0.rst

@@ -152,7 +152,7 @@ by ``CVE_CHECK_WHITELIST`` (replaced by :term:`CVE_CHECK_IGNORE` in version 3.5)
 
 .. _migration-3.0-bitbake-changes:
 
-BitBake Changes
+Bitbake Changes
 ---------------
 
 The following BitBake changes have occurred.

documentation/migration-guides/migration-3.2.rst

@@ -86,7 +86,7 @@ value to be explicitly prepended to package names being added as
 dependencies (e.g. in :term:`RDEPENDS` and :term:`RRECOMMENDS` values)
 where the dependency is conditionally added.
 
-If you have anonymous Python or in-line Python conditionally adding
+If you have anonymous python or in-line python conditionally adding
 dependencies in your custom recipes, and you intend for those recipes to
 work with multilib, then you will need to ensure that ``${MLPREFIX}``
 is prefixed on the package names in the dependencies, for example
@@ -149,7 +149,7 @@ the upstream documentation for ``dhcpcd`` and ``kea`` for further details.
 Packaging changes
 -----------------
 
-- ``python3``: the ``urllib`` Python package has now moved into the core package, as it is used more commonly than just netclient (e.g. email, xml, mimetypes, pydoc). In addition, the ``pathlib`` module is now also part of the core package.
+- ``python3``: the ``urllib`` python package has now moved into the core package, as it is used more commonly than just netclient (e.g. email, xml, mimetypes, pydoc). In addition, the ``pathlib`` module is now also part of the core package.
 
 - ``iptables``: ``iptables-apply`` and ``ip6tables-apply`` have been split out to their own package to avoid a bash dependency in the main ``iptables`` package
 
@@ -283,7 +283,7 @@ Image artifact name variables now centralised in image-artifact-names class
 ---------------------------------------------------------------------------
 
 The defaults for the following image artifact name variables have been moved
-from ``bitbake.conf`` to a new ``image-artifact-names`` class:
+from bitbake.conf to a new ``image-artifact-names`` class:
 
 - :term:`IMAGE_BASENAME`
 - :term:`IMAGE_LINK_NAME`

documentation/migration-guides/migration-3.3.rst

@@ -76,7 +76,7 @@ Some example recipes where this change has been made: ``gpgme``, ``libcap-ng``,
 
 .. _migration-3.3-distutils-path:
 
-``setup.py`` path for Python modules
+``setup.py`` path for python modules
 ------------------------------------
 
 In a Python module, sometimes ``setup.py`` can be buried deep in the
@@ -133,7 +133,7 @@ unless you want to take advantage of the improved granularity:
 - ``procps``: split ``ps`` and ``sysctl`` into their own packages
 - ``rpm``: split build and extra functionality into separate packages
 - ``sudo``: split ``sudo`` binary into ``sudo-sudo`` and libs into ``sudo-lib``
-- ``systemtap``: examples, Python scripts and runtime material split out
+- ``systemtap``: examples, python scripts and runtime material split out
 - ``util-linux``: ``libuuid`` has been split out to its own
   ``util-linux-libuuid`` recipe (and corresponding packages) to avoid circular
   dependencies if ``libgcrypt`` support is enabled in ``util-linux``.

documentation/migration-guides/migration-3.4.rst

@@ -233,7 +233,7 @@ Image / SDK generation changes
 Miscellaneous
 ~~~~~~~~~~~~~
 
-- Certificates are now properly checked when BitBake fetches sources
+- Certificates are now properly checked when bitbake fetches sources
   over HTTPS. If you receive errors as a result for your custom recipes,
   you will need to use a mirror or address the issue with the operators
   of the server in question.

documentation/migration-guides/release-4.0.rst

@@ -6,3 +6,6 @@ Release 4.0 (kirkstone)
    migration-4.0
    release-notes-4.0
    release-notes-4.0.1
+   release-notes-4.0.2
+   release-notes-4.0.3
+   release-notes-4.0.4

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

@@ -46,7 +46,7 @@ Fixes in 3.4.1
 -  bitbake: tests/fetch: Update pcre.org address after github changes
 -  bitbake: tests/runqueue: Ensure hashserv exits before deleting files
 -  bitbake: utils: Handle lockfile filenames that are too long for filesystems
--  bootchart2: Don't compile Python modules
+-  bootchart2: Don't compile python modules
 -  build-appliance-image: Update to honister head revision
 -  buildhistory: Fix package output files for SDKs
 -  busybox: 1.34.0 -> 1.34.1

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

@@ -0,0 +1,296 @@
+Release notes for Yocto-4.0.2 (Kirkstone)
+-----------------------------------------
+
+Security Fixes in Yocto-4.0.2
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  libxslt: Mark :cve:`2022-29824` as not applying
+-  tiff: Add jbig PACKAGECONFIG and clarify IGNORE :cve:`2022-1210`
+-  tiff: mark :cve:`2022-1622` and :cve:`2022-1623` as invalid
+-  pcre2:fix :cve:`2022-1586` Out-of-bounds read
+-  curl: fix :cve:`2022-22576`, :cve:`2022-27775`, :cve:`2022-27776`, :cve:`2022-27774`, :cve:`2022-30115`, :cve:`2022-27780`, :cve:`2022-27781`, :cve:`2022-27779` and :cve:`2022-27782`
+-  qemu: fix :cve:`2021-4206` and :cve:`2021-4207`
+-  freetype: fix :cve:`2022-27404`, :cve:`2022-27405` and :cve:`2022-27406`
+
+Fixes in Yocto-4.0.2
+~~~~~~~~~~~~~~~~~~~~
+
+-  alsa-plugins: fix libavtp vs. avtp packageconfig
+-  archiver: don't use machine variables in shared recipes
+-  archiver: use bb.note instead of echo
+-  baremetal-image: fix broken symlink in do_rootfs
+-  base-passwd: Disable shell for default users
+-  bash: submit patch upstream
+-  bind: upgrade 9.18.1 -> 9.18.2
+-  binutils: Bump to latest 2.38 release branch
+-  bitbake.conf: Make TCLIBC and TCMODE lazy assigned
+-  bitbake: build: Add clean_stamp API function to allow removal of task stamps
+-  bitbake: data: Do not depend on vardepvalueexclude flag
+-  bitbake: fetch2/osc: Small fixes for osc fetcher
+-  bitbake: server/process: Fix logging issues where only the first message was displayed
+-  build-appliance-image: Update to kirkstone head revision
+-  buildhistory.bbclass: fix shell syntax when using dash
+-  cairo: Add missing GPLv3 license checksum entry
+-  classes: rootfs-postcommands: add skip option to overlayfs_qa_check
+-  cronie: upgrade 1.6.0 -> 1.6.1
+-  cups: upgrade 2.4.1 -> 2.4.2
+-  cve-check.bbclass: Added do_populate_sdk[recrdeptask].
+-  cve-check: Add helper for symlink handling
+-  cve-check: Allow warnings to be disabled
+-  cve-check: Fix report generation
+-  cve-check: Only include installed packages for rootfs manifest
+-  cve-check: add support for Ignored CVEs
+-  cve-check: fix return type in check_cves
+-  cve-check: move update_symlinks to a library
+-  cve-check: write empty fragment files in the text mode
+-  cve-extra-exclusions: Add kernel CVEs
+-  cve-update-db-native: make it possible to disable database updates
+-  devtool: Fix _copy_file() TypeError
+-  e2fsprogs: add alternatives handling of lsattr as well
+-  e2fsprogs: update upstream status
+-  efivar: add musl libc compatibility
+-  epiphany: upgrade 42.0 -> 42.2
+-  ffmpeg: upgrade 5.0 -> 5.0.1
+-  fribidi: upgrade 1.0.11 -> 1.0.12
+-  gcc-cross-canadian: Add nativesdk-zstd dependency
+-  gcc-source: Fix incorrect task dependencies from ${B}
+-  gcc: Upgrade to 11.3 release
+-  gcc: depend on zstd-native
+-  git: fix override syntax in RDEPENDS
+-  glib-2.0: upgrade 2.72.1 -> 2.72.2
+-  glibc: Drop make-native dependency
+-  go: upgrade 1.17.8 -> 1.17.10
+-  gst-devtools: upgrade 1.20.1 -> 1.20.2
+-  gstreamer1.0-libav: upgrade 1.20.1 -> 1.20.2
+-  gstreamer1.0-omx: upgrade 1.20.1 -> 1.20.2
+-  gstreamer1.0-plugins-bad: upgrade 1.20.1 -> 1.20.2
+-  gstreamer1.0-plugins-base: upgrade 1.20.1 -> 1.20.2
+-  gstreamer1.0-plugins-good: upgrade 1.20.1 -> 1.20.2
+-  gstreamer1.0-plugins-ugly: upgrade 1.20.1 -> 1.20.2
+-  gstreamer1.0-python: upgrade 1.20.1 -> 1.20.2
+-  gstreamer1.0-rtsp-server: upgrade 1.20.1 -> 1.20.2
+-  gstreamer1.0-vaapi: upgrade 1.20.1 -> 1.20.2
+-  gstreamer1.0: upgrade 1.20.1 -> 1.20.2
+-  gtk+3: upgrade 3.24.33 -> 3.24.34
+-  gtk-doc: Fix potential shebang overflow on gtkdoc-mkhtml2
+-  image.bbclass: allow overriding dependency on virtual/kernel:do_deploy
+-  insane.bbclass: make sure to close .patch files
+-  iso-codes: upgrade 4.9.0 -> 4.10.0
+-  kernel-yocto.bbclass: Reset to exiting on non-zero return code at end of task
+-  libcgroup: upgrade 2.0.1 -> 2.0.2
+-  liberror-perl: Update sstate/equiv versions to clean cache
+-  libinput: upgrade 1.19.3 -> 1.19.4
+-  libpcre2: upgrade 10.39 -> 10.40
+-  librepo: upgrade 1.14.2 -> 1.14.3
+-  libseccomp: Add missing files for ptests
+-  libseccomp: Correct LIC_FILES_CHKSUM
+-  libxkbcommon: upgrade 1.4.0 -> 1.4.1
+-  libxml2: Upgrade 2.9.13 -> 2.9.14
+-  license.bbclass: Bound beginline and endline in copy_license_files()
+-  license_image.bbclass: Make QA errors fail the build
+-  linux-firmware: add support for building snapshots
+-  linux-firmware: package new Qualcomm firmware
+-  linux-firmware: replace mkdir by install
+-  linux-firmware: split ath3k firmware
+-  linux-firmware: upgrade to 20220610
+-  linux-yocto/5.10: update to v5.10.119
+-  linux-yocto/5.15: Enable MDIO bus config
+-  linux-yocto/5.15: bpf: explicitly disable unpriv eBPF by default
+-  linux-yocto/5.15: cfg/xen: Move x86 configs to separate file
+-  linux-yocto/5.15: update to v5.15.44
+-  local.conf.sample: Update sstate url to new 'all' path
+-  logrotate: upgrade 3.19.0 -> 3.20.1
+-  lttng-modules: Fix build failure for 5.10.119+ and 5.15.44+ kernel
+-  lttng-modules: fix build against 5.18-rc7+
+-  lttng-modules: fix shell syntax
+-  lttng-ust: upgrade 2.13.2 -> 2.13.3
+-  lzo: Add further info to a patch and mark as Inactive-Upstream
+-  makedevs: Don't use COPYING.patch just to add license file into ${S}
+-  manuals: switch to the sstate mirror shared between all versions
+-  mesa.inc: package 00-radv-defaults.conf
+-  mesa: backport a patch to support compositors without zwp_linux_dmabuf_v1 again
+-  mesa: upgrade to 22.0.3
+-  meson.bbclass: add cython binary to cross/native toolchain config
+-  mmc-utils: upgrade to latest revision
+-  mobile-broadband-provider-info: upgrade 20220315 -> 20220511
+-  ncurses: update to patchlevel 20220423
+-  oeqa/selftest/cve_check: add tests for Ignored and partial reports
+-  oeqa/selftest/cve_check: add tests for recipe and image reports
+-  oescripts: change compare logic in OEListPackageconfigTests
+-  openssl: Backport fix for ptest cert expiry
+-  overlayfs: add docs about skipping QA check & service dependencies
+-  ovmf: Fix native build with gcc-12
+-  patch.py: make sure that patches/series file exists before quilt pop
+-  pciutils: avoid lspci conflict with busybox
+-  perl: Add dependency on make-native to avoid race issues
+-  perl: Fix build with gcc-12
+-  poky.conf: bump version for 4.0.2
+-  popt: fix override syntax in RDEPENDS
+-  pypi.bbclass: Set CVE_PRODUCT to PYPI_PACKAGE
+-  python3: Ensure stale empty python module directories don't break the build
+-  python3: Remove problematic paths from sysroot files
+-  python3: fix reproducibility issue with python3-core
+-  python3: use built-in distutils for ptest, rather than setuptools' 'fork'
+-  python: Avoid shebang overflow on python-config.py
+-  rootfs-postcommands.bbclass: correct comments
+-  rootfs.py: close kernel_abi_ver_file
+-  rootfs.py: find .ko.zst kernel modules
+-  rust-common: Drop LLVM_TARGET and simplify
+-  rust-common: Ensure sstate signatures have correct dependencues for do_rust_gen_targets
+-  rust-common: Fix for target definitions returning 'NoneType' for arm
+-  rust-common: Fix native signature dependency issues
+-  rust-common: Fix sstate signatures between arm hf and non-hf
+-  sanity: Don't warn about make 4.2.1 for mint
+-  sanity: Switch to make 4.0 as a minimum version
+-  sed: Specify shell for "nobody" user in run-ptest
+-  selftest/imagefeatures/overlayfs: Always append to DISTRO_FEATURES
+-  selftest/multiconfig: Test that multiconfigs in separate layers works
+-  sqlite3: upgrade to 3.38.5
+-  staging.bbclass: process direct dependencies in deterministic order
+-  staging: Fix rare sysroot corruption issue
+-  strace: Don't run ptest as "nobody"
+-  systemd: Correct 0001-pass-correct-parameters-to-getdents64.patch
+-  systemd: Correct path returned in sd_path_lookup()
+-  systemd: Document future actions needed for set of musl patches
+-  systemd: Drop 0001-test-parse-argument-Include-signal.h.patch
+-  systemd: Drop 0002-don-t-use-glibc-specific-qsort_r.patch
+-  systemd: Drop 0016-Hide-__start_BUS_ERROR_MAP-and-__stop_BUS_ERROR_MAP.patch
+-  systemd: Drop redundant musl patches
+-  systemd: Fix build regression with latest update
+-  systemd: Remove __compare_fn_t type in musl-specific patch
+-  systemd: Update patch status
+-  systemd: systemd-systemctl: Support instance conf files during enable
+-  systemd: update ``0008-add-missing-FTW_-macros-for-musl.patch``
+-  systemd: upgrade 250.4 -> 250.5
+-  uboot-sign: Fix potential index error issues
+-  valgrind: submit arm patches upstream
+-  vim: Upgrade to 8.2.5083
+-  webkitgtk: upgrade to 2.36.3
+-  wic/plugins/rootfs: Fix permissions when splitting rootfs folders across partitions
+-  xwayland: upgrade 22.1.0 -> 22.1.1
+-  xxhash: fix build with gcc 12
+-  zip/unzip: mark all submittable patches as Inactive-Upstream
+
+Known Issues in Yocto-4.0.2
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+- There were build failures at the autobuilder due to a known scp issue on Fedora-36 hosts.
+
+Contributors to Yocto-4.0.2
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  Alex Kiernan
+-  Alexander Kanavin
+-  Aryaman Gupta
+-  Bruce Ashfield
+-  Claudius Heine
+-  Davide Gardenal
+-  Dmitry Baryshkov
+-  Ernst Sjöstrand
+-  Felix Moessbauer
+-  Gunjan Gupta
+-  He Zhe
+-  Hitendra Prajapati
+-  Jack Mitchell
+-  Jeremy Puhlman
+-  Jiaqing Zhao
+-  Joerg Vehlow
+-  Jose Quaresma
+-  Kai Kang
+-  Khem Raj
+-  Konrad Weihmann
+-  Marcel Ziswiler
+-  Markus Volk
+-  Marta Rybczynska
+-  Martin Jansa
+-  Michael Opdenacker
+-  Mingli Yu
+-  Naveen Saini
+-  Nick Potenski
+-  Paulo Neves
+-  Pavel Zhukov
+-  Peter Kjellerstedt
+-  Rasmus Villemoes
+-  Richard Purdie
+-  Robert Joslyn
+-  Ross Burton
+-  Samuli Piippo
+-  Sean Anderson
+-  Stefan Wiehler
+-  Steve Sakoman
+-  Sundeep Kokkonda
+-  Tomasz Dziendzielski
+-  Xiaobing Luo
+-  Yi Zhao
+-  leimaohui
+-  wangmy
+
+Repositories / Downloads for Yocto-4.0.2
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+poky
+
+-  Repository Location: https://git.yoctoproject.org/git/poky
+-  Branch: :yocto_git:`kirkstone </poky/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.2 </poky/log/?h=yocto-4.0.2>`
+-  Git Revision: :yocto_git:`a5ea426b1da472fc8549459fff3c1b8c6e02f4b5 </poky/commit/?id=a5ea426b1da472fc8549459fff3c1b8c6e02f4b5>`
+-  Release Artefact: poky-a5ea426b1da472fc8549459fff3c1b8c6e02f4b5
+-  sha: 474ddfacfed6661be054c161597a1a5273188dfe021b31d6156955d93c6b7359
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.2/poky-a5ea426b1da472fc8549459fff3c1b8c6e02f4b5.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.2/poky-a5ea426b1da472fc8549459fff3c1b8c6e02f4b5.tar.bz2
+
+openembedded-core
+
+-  Repository Location: https://git.openembedded.org/openembedded-core
+-  Branch: :oe_git:`kirkstone </openembedded-core/log/?h=kirkstone>`
+-  Tag:  :oe_git:`yocto-4.0.2 </openembedded-core/log/?h=yocto-4.0.2>`
+-  Git Revision: :oe_git:`eea52e0c3d24c79464f4afdbc3c397e1cb982231 </openembedded-core/commit/?id=eea52e0c3d24c79464f4afdbc3c397e1cb982231>`
+-  Release Artefact: oecore-eea52e0c3d24c79464f4afdbc3c397e1cb982231
+-  sha: 252d5c2c2db7e14e7365fcc69d32075720b37d629894bae36305eba047a39907
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.2/oecore-eea52e0c3d24c79464f4afdbc3c397e1cb982231.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.2/oecore-eea52e0c3d24c79464f4afdbc3c397e1cb982231.tar.bz2
+
+meta-mingw
+
+-  Repository Location: https://git.yoctoproject.org/git/meta-mingw
+-  Branch: :yocto_git:`kirkstone </meta-mingw/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.2 </meta-mingw/log/?h=yocto-4.0.2>`
+-  Git Revision: :yocto_git:`a90614a6498c3345704e9611f2842eb933dc51c1 </meta-mingw/commit/?id=a90614a6498c3345704e9611f2842eb933dc51c1>`
+-  Release Artefact: meta-mingw-a90614a6498c3345704e9611f2842eb933dc51c1
+-  sha: 49f9900bfbbc1c68136f8115b314e95d0b7f6be75edf36a75d9bcd1cca7c6302
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.2/meta-mingw-a90614a6498c3345704e9611f2842eb933dc51c1.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.2/meta-mingw-a90614a6498c3345704e9611f2842eb933dc51c1.tar.bz2
+
+meta-gplv2
+
+-  Repository Location: https://git.yoctoproject.org/git/meta-gplv2
+-  Branch: :yocto_git:`kirkstone </meta-gplv2/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.2 </meta-gplv2/log/?h=yocto-4.0.2>`
+-  Git Revision: :yocto_git:`d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a </meta-gplv2/commit/?id=d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a>`
+-  Release Artefact: meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a
+-  sha: c386f59f8a672747dc3d0be1d4234b6039273d0e57933eb87caa20f56b9cca6d
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.2/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.2/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2
+
+bitbake
+
+-  Repository Location: https://git.openembedded.org/bitbake
+-  Branch: :oe_git:`2.0 </bitbake/log/?h=2.0>`
+-  Tag:  :oe_git:`yocto-4.0.2 </bitbake/log/?h=yocto-4.0.2>`
+-  Git Revision: :oe_git:`b8fd6f5d9959d27176ea016c249cf6d35ac8ba03 </bitbake/commit/?id=b8fd6f5d9959d27176ea016c249cf6d35ac8ba03>`
+-  Release Artefact: bitbake-b8fd6f5d9959d27176ea016c249cf6d35ac8ba03
+-  sha: 373818b1dee2c502264edf654d6d8f857b558865437f080e02d5ba6bb9e72cc3
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.2/bitbake-b8fd6f5d9959d27176ea016c249cf6d35ac8ba03.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.2/bitbake-b8fd6f5d9959d27176ea016c249cf6d35ac8ba03.tar.bz2
+
+yocto-docs
+
+-  Repository Location: https://git.yoctoproject.org/git/yocto-docs
+-  Branch: :yocto_git:`kirkstone </yocto-docs/log/?h=kirkstone>`
+-  Tag: :yocto_git:`yocto-4.0.2 </yocto-docs/log/?h=yocto-4.0.2>`
+-  Git Revision: :yocto_git:`662294dccd028828d5c7e9fd8f5c8e14df53df4b </yocto-docs/commit/?id=662294dccd028828d5c7e9fd8f5c8e14df53df4b>`

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

@@ -0,0 +1,314 @@
+Release notes for Yocto-4.0.3 (Kirkstone)
+-----------------------------------------
+
+Security Fixes in Yocto-4.0.3
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  binutils: fix :cve:`2019-1010204`
+-  busybox: fix :cve:`2022-30065`
+-  cups: ignore :cve:`2022-26691`
+-  curl: Fix :cve:`2022-32205`, :cve:`2022-32206`, :cve:`2022-32207` and :cve:`2022-32208`
+-  dpkg: fix :cve:`2022-1664`
+-  ghostscript: fix :cve:`2022-2085`
+-  harfbuzz: fix :cve:`2022-33068`
+-  libtirpc: fix :cve:`2021-46828`
+-  lua: fix :cve:`2022-33099`
+-  nasm: ignore :cve:`2020-18974`
+-  qemu: fix :cve:`2022-35414`
+-  qemu: ignore :cve:`2021-20255` and :cve:`2019-12067`
+-  tiff: fix :cve:`2022-1354`, :cve:`2022-1355`, :cve:`2022-2056`, :cve:`2022-2057` and :cve:`2022-2058`
+-  u-boot: fix :cve:`2022-34835`
+-  unzip: fix :cve:`2022-0529` and :cve:`2022-0530`
+
+
+Fixes in Yocto-4.0.3
+~~~~~~~~~~~~~~~~~~~~
+
+-  alsa-state: correct license
+-  at: take tarballs from debian
+-  base.bbclass: Correct the test for obsolete license exceptions
+-  base/reproducible: Change Source Date Epoch generation methods
+-  bin_package: install into base_prefix
+-  bind: Remove legacy python3 PACKAGECONFIG code
+-  bind: upgrade to 9.18.4
+-  binutils: stable 2.38 branch updates
+-  build-appliance-image: Update to kirkstone head revision
+-  cargo_common.bbclass: enable bitbake vendoring for externalsrc
+-  coreutils: Tweak packaging variable names for coreutils-dev
+-  curl: backport openssl fix CN check error code
+-  cve-check: hook cleanup to the BuildCompleted event, not CookerExit
+-  cve-extra-exclusions: Clean up and ignore three CVEs (2xqemu and nasm)
+-  devtool: finish: handle patching when S points to subdir of a git repo
+-  devtool: ignore pn- overrides when determining SRC_URI overrides
+-  docs: BB_HASHSERVE_UPSTREAM: update to new host
+-  dropbear: break dependency on base package for -dev package
+-  efivar: fix import functionality
+-  encodings: update to 1.0.6
+-  epiphany: upgrade to 42.3
+-  externalsrc.bbclass: support crate fetcher on externalsrc
+-  font-util: update 1.3.2 -> 1.3.3
+-  gcc-runtime: Fix build when using gold
+-  gcc-runtime: Fix missing MLPREFIX in debug mappings
+-  gcc-runtime: Pass -nostartfiles when building dummy libstdc++.so
+-  gcc: Backport a fix for gcc bug 105039
+-  git: upgrade to v2.35.4
+-  glib-2.0: upgrade to 2.72.3
+-  glib-networking: upgrade to 2.72.1
+-  glibc : stable 2.35 branch updates
+-  glibc-tests: Avoid reproducibility issues
+-  glibc-tests: not clear BBCLASSEXTEND
+-  glibc: revert one upstream change to work around broken DEBUG_BUILD build
+-  glibc: stable 2.35 branch updates
+-  gnupg: upgrade to 2.3.7
+-  go: upgrade to v1.17.12
+-  gobject-introspection-data: Disable cache for g-ir-scanner
+-  gperf: Add a patch to work around reproducibility issues
+-  gperf: Switch to upstream patch
+-  gst-devtools: upgrade to 1.20.3
+-  gstreamer1.0-libav: upgrade to 1.20.3
+-  gstreamer1.0-omx: upgrade to 1.20.3
+-  gstreamer1.0-plugins-bad: upgrade to 1.20.3
+-  gstreamer1.0-plugins-base: upgrade to 1.20.3
+-  gstreamer1.0-plugins-good: upgrade to 1.20.3
+-  gstreamer1.0-plugins-ugly: upgrade to 1.20.3
+-  gstreamer1.0-python: upgrade to 1.20.3
+-  gstreamer1.0-rtsp-server: upgrade to 1.20.3
+-  gstreamer1.0-vaapi: upgrade to 1.20.3
+-  gstreamer1.0: upgrade to 1.20.3
+-  gtk-doc: Remove hardcoded buildpath
+-  harfbuzz: Fix compilation with clang
+-  initramfs-framework: move storage mounts to actual rootfs
+-  initscripts: run umountnfs as a KILL script
+-  insane.bbclass: host-user-contaminated: Correct per package home path
+-  insane: Fix buildpaths test to work with special devices
+-  kernel-arch: Fix buildpaths leaking into external module compiles
+-  kernel-devsrc: fix reproducibility and buildpaths QA warning
+-  kernel-devsrc: ppc32: fix reproducibility
+-  kernel-uboot.bbclass: Use vmlinux.initramfs when INITRAMFS_IMAGE_BUNDLE set
+-  kernel.bbclass: pass LD also in savedefconfig
+-  libffi: fix native build being not portable
+-  libgcc: Fix standalone target builds with usrmerge distro feature
+-  libmodule-build-perl: Use env utility to find perl interpreter
+-  libsoup: upgrade to 3.0.7
+-  libuv: upgrade to 1.44.2
+-  linux-firmware: upgrade to 20220708
+-  linux-firwmare: restore WHENCE_CHKSUM variable
+-  linux-yocto-rt/5.15: update to -rt48 (and fix -stable merge)
+-  linux-yocto/5.10: fix build_OID_registry/conmakehash buildpaths warning
+-  linux-yocto/5.10: fix buildpaths issue with gen-mach-types
+-  linux-yocto/5.10: fix buildpaths issue with pnmtologo
+-  linux-yocto/5.10: update to v5.10.135
+-  linux-yocto/5.15: drop obselete GPIO sysfs ABI
+-  linux-yocto/5.15: fix build_OID_registry buildpaths warning
+-  linux-yocto/5.15: fix buildpaths issue with gen-mach-types
+-  linux-yocto/5.15: fix buildpaths issue with pnmtologo
+-  linux-yocto/5.15: fix qemuppc buildpaths warning
+-  linux-yocto/5.15: fix reproducibility issues
+-  linux-yocto/5.15: update to v5.15.59
+-  log4cplus: upgrade to 2.0.8
+-  lttng-modules: Fix build failure for kernel v5.15.58
+-  lttng-modules: upgrade to 2.13.4
+-  lua: Fix multilib buildpath reproducibility issues
+-  mkfontscale: upgrade to 1.2.2
+-  oe-selftest-image: Ensure the image has sftp as well as dropbear
+-  oe-selftest: devtool: test modify git recipe building from a subdir
+-  oeqa/runtime/scp: Disable scp test for dropbear
+-  oeqa/runtime: add test that the kernel has CONFIG_PREEMPT_RT enabled
+-  oeqa/sdk: drop the nativesdk-python 2.x test
+-  openssh: Add openssh-sftp-server to openssh RDEPENDS
+-  openssh: break dependency on base package for -dev package
+-  openssl: update to 3.0.5
+-  package.bbclass: Avoid stripping signed kernel modules in splitdebuginfo
+-  package.bbclass: Fix base directory for debugsource files when using externalsrc
+-  package.bbclass: Fix kernel source handling when not using externalsrc
+-  package_manager/ipk: do not pipe stderr to stdout
+-  packagegroup-core-ssh-dropbear: Add openssh-sftp-server recommendation
+-  patch: handle if S points to a subdirectory of a git repo
+-  perf: fix reproducibility in 5.19+
+-  perf: fix reproduciblity in older releases of Linux
+-  perf: sort-pmuevents: really keep array terminators
+-  perl: don't install Makefile.old into perl-ptest
+-  poky.conf: bump version for 4.0.3
+-  pulseaudio: add m4-native to DEPENDS
+-  python3: Backport patch to fix an issue in subinterpreters
+-  qemu: Add PACKAGECONFIG for brlapi
+-  qemu: Avoid accidental librdmacm linkage
+-  qemu: Avoid accidental libvdeplug linkage
+-  qemu: Fix slirp determinism issue
+-  qemu: add PACKAGECONFIG for capstone
+-  recipetool/devtool: Fix python egg whitespace issues in PACKAGECONFIG
+-  ref-manual: variables: remove sphinx directive from literal block
+-  rootfs-postcommands.bbclass: move host-user-contaminated.txt to ${S}
+-  ruby: add PACKAGECONFIG for capstone
+-  rust: fix issue building cross-canadian tools for aarch64 on x86_64
+-  sanity.bbclass: Add ftps to accepted URI protocols for mirrors sanity
+-  selftest/runtime_test/virgl: Disable for all almalinux
+-  sstatesig: Include all dependencies in SPDX task signatures
+-  strace: set COMPATIBLE_HOST for riscv32
+-  systemd: Added base_bindir into pkg_postinst:udev-hwdb.
+-  udev-extraconf/initrdscripts/parted: Rename mount.blacklist -> mount.ignorelist
+-  udev-extraconf/mount.sh: add LABELs to mountpoints
+-  udev-extraconf/mount.sh: ignore lvm in automount
+-  udev-extraconf/mount.sh: only mount devices on hotplug
+-  udev-extraconf/mount.sh: save mount name in our tmp filecache
+-  udev-extraconf: fix some systemd automount issues
+-  udev-extraconf: force systemd-udevd to use shared MountFlags
+-  udev-extraconf: let automount base directory configurable
+-  udev-extraconf:mount.sh: fix a umount issue
+-  udev-extraconf:mount.sh: fix path mismatching issues
+-  vala: Fix on target wrapper buildpaths issue
+-  vala: upgrade to 0.56.2
+-  vim: upgrade to 9.0.0063
+-  waffle: correctly request wayland-scanner executable
+-  webkitgtk: upgrade to 2.36.4
+-  weston: upgrade to 10.0.1
+-  wic/plugins/rootfs: Fix NameError for 'orig_path'
+-  wic: fix WicError message
+-  wireless-regdb: upgrade to 2022.06.06
+-  xdpyinfo: upgrade to 1.3.3
+-  xev: upgrade to 1.2.5
+-  xf86-input-synaptics: upgrade to 1.9.2
+-  xmodmap: upgrade to 1.0.11
+-  xorg-app: Tweak handling of compression changes in SRC_URI
+-  xserver-xorg: upgrade to 21.1.4
+-  xwayland: upgrade to 22.1.3
+-  yocto-bsps/5.10: fix buildpaths issue with gen-mach-types
+-  yocto-bsps/5.10: fix buildpaths issue with pnmtologo
+-  yocto-bsps/5.15: fix buildpaths issue with gen-mach-types
+-  yocto-bsps/5.15: fix buildpaths issue with pnmtologo
+-  yocto-bsps: buildpaths fixes
+-  yocto-bsps: update to v5.10.130
+-  yocto-bsps: buildpaths fixes
+-  yocto-bsps: update to v5.15.54
+
+
+Known Issues in Yocto-4.0.3
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+- N/A
+
+
+Contributors to Yocto-4.0.3
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  Ahmed Hossam
+-  Alejandro Hernandez Samaniego
+-  Alex Kiernan
+-  Alexander Kanavin
+-  Bruce Ashfield
+-  Chanho Park
+-  Christoph Lauer
+-  David Bagonyi
+-  Dmitry Baryshkov
+-  He Zhe
+-  Hitendra Prajapati
+-  Jose Quaresma
+-  Joshua Watt
+-  Kai Kang
+-  Khem Raj
+-  Lee Chee Yang
+-  Lucas Stach
+-  Markus Volk
+-  Martin Jansa
+-  Maxime Roussin-Bélanger
+-  Michael Opdenacker
+-  Mihai Lindner
+-  Ming Liu
+-  Mingli Yu
+-  Muhammad Hamza
+-  Naveen
+-  Pascal Bach
+-  Paul Eggleton
+-  Pavel Zhukov
+-  Peter Bergin
+-  Peter Kjellerstedt
+-  Peter Marko
+-  Pgowda
+-  Raju Kumar Pothuraju
+-  Richard Purdie
+-  Robert Joslyn
+-  Ross Burton
+-  Sakib Sajal
+-  Shruthi Ravichandran
+-  Steve Sakoman
+-  Sundeep Kokkonda
+-  Thomas Roos
+-  Tom Hochstein
+-  Wentao Zhang
+-  Yi Zhao
+-  Yue Tao
+-  gr embeter
+-  leimaohui
+-  wangmy
+
+
+Repositories / Downloads for Yocto-4.0.3
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+poky
+
+-  Repository Location: https://git.yoctoproject.org/git/poky
+-  Branch: :yocto_git:`kirkstone </poky/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.3 </poky/log/?h=yocto-4.0.3>`
+-  Git Revision: :yocto_git:`387ab5f18b17c3af3e9e30dc58584641a70f359f </poky/commit/?id=387ab5f18b17c3af3e9e30dc58584641a70f359f>`
+-  Release Artefact: poky-387ab5f18b17c3af3e9e30dc58584641a70f359f
+-  sha: fe674186bdb0684313746caa9472134fc19e6f1443c274fe02c06cb1e675b404
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.3/poky-387ab5f18b17c3af3e9e30dc58584641a70f359f.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.3/poky-387ab5f18b17c3af3e9e30dc58584641a70f359f.tar.bz2
+
+openembedded-core
+
+-  Repository Location: https://git.openembedded.org/openembedded-core
+-  Branch: :oe_git:`kirkstone </openembedded-core/log/?h=kirkstone>`
+-  Tag:  :oe_git:`yocto-4.0.3 </openembedded-core/log/?h=yocto-4.0.3>`
+-  Git Revision: :oe_git:`2cafa6ed5f0aa9df5a120b6353755d56c7c7800d </openembedded-core/commit/?id=2cafa6ed5f0aa9df5a120b6353755d56c7c7800d>`
+-  Release Artefact: oecore-2cafa6ed5f0aa9df5a120b6353755d56c7c7800d
+-  sha: 5181d3e8118c6112936637f01a07308b715e0e3d12c7eba338556747dfcabe92
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.3/oecore-2cafa6ed5f0aa9df5a120b6353755d56c7c7800d.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.3/oecore-2cafa6ed5f0aa9df5a120b6353755d56c7c7800d.tar.bz2
+
+meta-mingw
+
+-  Repository Location: https://git.yoctoproject.org/git/meta-mingw
+-  Branch: :yocto_git:`kirkstone </meta-mingw/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.3 </meta-mingw/log/?h=yocto-4.0.3>`
+-  Git Revision: :yocto_git:`a90614a6498c3345704e9611f2842eb933dc51c1 </meta-mingw/commit/?id=a90614a6498c3345704e9611f2842eb933dc51c1>`
+-  Release Artefact: meta-mingw-a90614a6498c3345704e9611f2842eb933dc51c1
+-  sha: 49f9900bfbbc1c68136f8115b314e95d0b7f6be75edf36a75d9bcd1cca7c6302
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.3/meta-mingw-a90614a6498c3345704e9611f2842eb933dc51c1.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.3/meta-mingw-a90614a6498c3345704e9611f2842eb933dc51c1.tar.bz2
+
+meta-gplv2
+
+-  Repository Location: https://git.yoctoproject.org/git/meta-gplv2
+-  Branch: :yocto_git:`kirkstone </meta-gplv2/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.3 </meta-gplv2/log/?h=yocto-4.0.3>`
+-  Git Revision: :yocto_git:`d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a </meta-gplv2/commit/?id=d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a>`
+-  Release Artefact: meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a
+-  sha: c386f59f8a672747dc3d0be1d4234b6039273d0e57933eb87caa20f56b9cca6d
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.3/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.3/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2
+
+bitbake
+
+-  Repository Location: https://git.openembedded.org/bitbake
+-  Branch: :oe_git:`2.0 </bitbake/log/?h=2.0>`
+-  Tag:  :oe_git:`yocto-4.0.3 </bitbake/log/?h=yocto-4.0.3>`
+-  Git Revision: :oe_git:`b8fd6f5d9959d27176ea016c249cf6d35ac8ba03 </bitbake/commit/?id=b8fd6f5d9959d27176ea016c249cf6d35ac8ba03>`
+-  Release Artefact: bitbake-b8fd6f5d9959d27176ea016c249cf6d35ac8ba03
+-  sha: 373818b1dee2c502264edf654d6d8f857b558865437f080e02d5ba6bb9e72cc3
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.3/bitbake-b8fd6f5d9959d27176ea016c249cf6d35ac8ba03.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.3/bitbake-b8fd6f5d9959d27176ea016c249cf6d35ac8ba03.tar.bz2
+
+yocto-docs
+
+-  Repository Location: https://git.yoctoproject.org/git/yocto-docs
+-  Branch: :yocto_git:`kirkstone </yocto-docs/log/?h=kirkstone>`
+-  Tag: :yocto_git:`yocto-4.0.3 </yocto-docs/log/?h=yocto-4.0.3>`
+-  Git Revision: :yocto_git:`d9b3dcf65ef25c06f552482aba460dd16862bf96 </yocto-docs/commit/?id=d9b3dcf65ef25c06f552482aba460dd16862bf96>`
+

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

@@ -0,0 +1,299 @@
+Release notes for Yocto-4.0.4 (Kirkstone)
+-----------------------------------------
+
+Security Fixes in Yocto-4.0.4
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  binutils : fix :cve:`2022-38533`
+-  curl: fix :cve:`2022-35252`
+-  sqlite: fix :cve:`2022-35737`
+-  grub2: fix :cve:`2021-3695`, :cve:`2021-3696`, :cve:`2021-3697`, :cve:`2022-28733`, :cve:`2022-28734` and :cve:`2022-28735`
+-  u-boot: fix :cve:`2022-30552` and :cve:`2022-33967`
+-  libxml2: Ignore :cve:`2016-3709`
+-  libtiff: fix :cve:`2022-34526`
+-  zlib: fix :cve:`2022-37434`
+-  gnutls: fix :cve:`2022-2509`
+-  u-boot: fix :cve:`2022-33103`
+-  qemu: fix :cve:`2021-3507`, :cve:`2021-3929`, :cve:`2021-4158`, :cve:`2022-0216` and :cve:`2022-0358`
+
+
+Fixes in Yocto-4.0.4
+~~~~~~~~~~~~~~~~~~~~
+
+-  apr: Cache configure tests which use AC_TRY_RUN
+-  apr: Use correct strerror_r implementation based on libc type
+-  apt: fix nativesdk-apt build failure during the second time build
+-  archiver.bbclass: remove unsed do_deploy_archives[dirs]
+-  archiver.bbclass: some recipes that uses the kernelsrc bbclass uses the shared source
+-  autoconf: Fix strict prototype errors in generated tests
+-  autoconf: Update K & R stype functions
+-  bind: upgrade to 9.18.5
+-  bitbake.conf: set BB_DEFAULT_UMASK using ??=
+-  bitbake: ConfHandler/BBHandler: Improve comment error messages and add tests
+-  bitbake: ConfHandler: Remove lingering close
+-  bitbake: bb/utils: movefile: use the logger for printing
+-  bitbake: bb/utils: remove: check the path again the expand python glob
+-  bitbake: bitbake-user-manual: Correct description of the ??= operator
+-  bitbake: bitbake-user-manual: npm fetcher: improve description of SRC_URI format
+-  bitbake: bitbake: bitbake-user-manual: hashserv can be accessed on a dedicated domain
+-  bitbake: bitbake: runqueue: add cpu/io pressure regulation
+-  bitbake: bitbake: runqueue: add memory pressure regulation
+-  bitbake: cooker: Drop sre_constants usage
+-  bitbake: doc: bitbake-user-manual: add explicit target for crates fetcher
+-  bitbake: doc: bitbake-user-manual: document npm and npmsw fetchers
+-  bitbake: event.py: ignore exceptions from stdout and sterr operations in atexit
+-  bitbake: fetch2: Ensure directory exists before creating symlink
+-  bitbake: fetch2: gitsm: fix incorrect handling of git submodule relative urls
+-  bitbake: runqueue: Change pressure file warning to a note
+-  bitbake: runqueue: Fix unihash cache mismatch issues
+-  bitbake: toaster: fix kirkstone version
+-  bitbake: utils: Pass lock argument in fileslocked
+-  bluez5: upgrade to 5.65
+-  boost: fix install of fiber shared libraries
+-  cairo: Adapt the license information based on what is being built
+-  classes: cve-check: Get shared database lock
+-  cmake: remove CMAKE_ASM_FLAGS variable in toolchain file
+-  connman: Backports for security fixes
+-  core-image.bbclass: Exclude openssh complementary packages
+-  cracklib: Drop using register keyword
+-  cracklib: upgrade to 2.9.8
+-  create-spdx: Fix supplier field
+-  create-spdx: handle links to inaccessible locations
+-  create-spdx: ignore packing control files from ipk and deb
+-  cve-check: Don't use f-strings
+-  cve-check: close cursors as soon as possible
+-  devtool/upgrade: catch bb.fetch2.decodeurl errors
+-  devtool/upgrade: correctly clean up when recipe filename isn't yet known
+-  devtool: error out when workspace is using old override syntax
+-  ell: upgrade to 0.50
+-  epiphany: upgrade to 42.4
+-  externalsrc: Don't wipe out src dir when EXPORT_FUNCTIONS is used.
+-  gcc-multilib-config: Fix i686 toolchain relocation issues
+-  gcr: Define _GNU_SOURCE
+-  gdk-pixbuf: upgrade to 2.42.9
+-  glib-networking: upgrade to 2.72.2
+-  go: upgrade to v1.17.13
+-  insane.bbclass: Skip patches not in oe-core by full path
+-  iso-codes: upgrade to 4.11.0
+-  kernel-fitimage.bbclass: add padding algorithm property in config nodes
+-  kernel-fitimage.bbclass: only package unique DTBs
+-  kernel: Always set CC and LD for the kernel build
+-  kernel: Use consistent make flags for menuconfig
+-  lib:npm_registry: initial checkin
+-  libatomic-ops: upgrade to 7.6.14
+-  libcap: upgrade to 2.65
+-  libjpeg-turbo: upgrade to 2.1.4
+-  libpam: use /run instead of /var/run in systemd tmpfiles
+-  libtasn1: upgrade to 4.19.0
+-  liburcu: upgrade to 0.13.2
+-  libwebp: upgrade to 1.2.4
+-  libwpe: upgrade to 1.12.3
+-  libxml2: Port gentest.py to Python-3
+-  lighttpd: upgrade to 1.4.66
+-  linux-yocto/5.10: update genericx86* machines to v5.10.135
+-  linux-yocto/5.10: update to v5.10.137
+-  linux-yocto/5.15: update genericx86* machines to v5.15.59
+-  linux-yocto/5.15: update to v5.15.62
+-  linux-yocto: Fix COMPATIBLE_MACHINE regex match
+-  linux-yocto: prepend the the value with a space when append to KERNEL_EXTRA_ARGS
+-  lttng-modules: fix 5.19+ build
+-  lttng-modules: fix build against mips and v5.19 kernel
+-  lttng-modules: fix build for kernel 5.10.137
+-  lttng-modules: replace mips compaction fix with upstream change
+-  lz4: upgrade to 1.9.4
+-  maintainers: update opkg maintainer
+-  meta: introduce UBOOT_MKIMAGE_KERNEL_TYPE
+-  migration guides: add missing release notes
+-  mobile-broadband-provider-info: upgrade to 20220725
+-  nativesdk: Clear TUNE_FEATURES
+-  npm: replace 'npm pack' call by 'tar czf'
+-  npm: return content of 'package.json' in 'npm_pack'
+-  npm: take 'version' directly from 'package.json'
+-  npm: use npm_registry to cache package
+-  oeqa/gotoolchain: put writable files in the Go module cache
+-  oeqa/gotoolchain: set CGO_ENABLED=1
+-  oeqa/parselogs: add qemuarmv5 arm-charlcd masking
+-  oeqa/qemurunner: add run_serial() comment
+-  oeqa/selftest: rename git.py to intercept.py
+-  oeqa: qemurunner: Report UNIX Epoch timestamp on login
+-  package_rpm: Do not replace square brackets in %files
+-  packagegroup-self-hosted: update for strace
+-  parselogs: Ignore xf86OpenConsole error
+-  perf: Fix reproducibility issues with 5.19 onwards
+-  pinentry: enable _XOPEN_SOURCE on musl for wchar usage in curses
+-  poky.conf: add ubuntu-22.04 to tested distros
+-  poky.conf: bump version for 4.0.4
+-  pseudo: Update to include recent upstream minor fixes
+-  python3-pip: Fix RDEPENDS after the update
+-  ref-manual: add numa to machine features
+-  relocate_sdk.py: ensure interpreter size error causes relocation to fail
+-  rootfs-postcommands.bbclass: avoid moving ssh host keys if etc is writable
+-  rootfs.py: dont try to list installed packages for baremetal images
+-  rootfspostcommands.py: Cleanup subid backup files generated by shadow-utils
+-  ruby: drop capstone support
+-  runqemu: Add missing space on default display option
+-  runqemu: display host uptime when starting
+-  sanity: add a comment to ensure CONNECTIVITY_CHECK_URIS is correct
+-  scripts/oe-setup-builddir: make it known where configurations come from
+-  scripts/runqemu.README: fix typos and trailing whitespaces
+-  selftest/wic: Tweak test case to not depend on kernel size
+-  shadow: Avoid nss warning/error with musl
+-  shadow: Enable subid support
+-  system-requirements.rst: Add Ubuntu 22.04 to list of supported distros
+-  systemd: Add 'no-dns-fallback' PACKAGECONFIG option
+-  systemd: Fix unwritable /var/lock when no sysvinit handling
+-  sysvinit-inittab/start_getty: Fix respawn too fast
+-  tcp-wrappers: Fix implicit-function-declaration warnings
+-  tzdata: upgrade to 2022b
+-  util-linux: Remove --enable-raw from EXTRA_OECONF
+-  vala: upgrade to 0.56.3
+-  vim: Upgrade to 9.0.0453
+-  watchdog: Include needed system header for function decls
+-  webkitgtk: upgrade to 2.36.5
+-  weston: upgrade to 10.0.2
+-  wic/bootimg-efi: use cross objcopy when building unified kernel image
+-  wic: add target tools to PATH when executing native commands
+-  wic: depend on cross-binutils
+-  wireless-regdb: upgrade to 2022.08.12
+-  wpebackend-fdo: upgrade to 1.12.1
+-  xinetd: Pass missing -D_GNU_SOURCE
+-  xz: update to 5.2.6
+
+
+Known Issues in Yocto-4.0.4
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+- N/A
+
+
+Contributors to Yocto-4.0.4
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+-  Alejandro Hernandez Samaniego
+-  Alex Stewart
+-  Alexander Kanavin
+-  Alexandre Belloni
+-  Andrei Gherzan
+-  Anuj Mittal
+-  Aryaman Gupta
+-  Awais Belal
+-  Beniamin Sandu
+-  Bertrand Marquis
+-  Bruce Ashfield
+-  Changqing Li
+-  Chee Yang Lee
+-  Daiane Angolini
+-  Enrico Scholz
+-  Ernst Sjöstrand
+-  Gennaro Iorio
+-  Hitendra Prajapati
+-  Jacob Kroon
+-  Jon Mason
+-  Jose Quaresma
+-  Joshua Watt
+-  Kai Kang
+-  Khem Raj
+-  Kristian Amlie
+-  LUIS ENRIQUEZ
+-  Mark Hatle
+-  Martin Beeger
+-  Martin Jansa
+-  Mateusz Marciniec
+-  Michael Opdenacker
+-  Mihai Lindner
+-  Mikko Rapeli
+-  Ming Liu
+-  Niko Mauno
+-  Ola x Nilsson
+-  Otavio Salvador
+-  Paul Eggleton
+-  Pavel Zhukov
+-  Peter Bergin
+-  Peter Kjellerstedt
+-  Peter Marko
+-  Rajesh Dangi
+-  Randy MacLeod
+-  Rasmus Villemoes
+-  Richard Purdie
+-  Robert Joslyn
+-  Roland Hieber
+-  Ross Burton
+-  Sakib Sajal
+-  Shubham Kulkarni
+-  Steve Sakoman
+-  Ulrich Ölmann
+-  Yang Xu
+-  Yongxin Liu
+-  ghassaneben
+-  pgowda
+-  wangmy
+
+Repositories / Downloads for Yocto-4.0.4
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+poky
+
+-  Repository Location: https://git.yoctoproject.org/git/poky
+-  Branch: :yocto_git:`kirkstone </poky/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.4 </poky/log/?h=yocto-4.0.4>`
+-  Git Revision: :yocto_git:`d64bef1c7d713b92a51228e5ade945835e5a94a4 </poky/commit/?id=d64bef1c7d713b92a51228e5ade945835e5a94a4>`
+-  Release Artefact: poky-d64bef1c7d713b92a51228e5ade945835e5a94a4
+-  sha: b5e92506b31f88445755bad2f45978b747ad1a5bea66ca897370542df5f1e7db
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.4/poky-d64bef1c7d713b92a51228e5ade945835e5a94a4.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.4/poky-d64bef1c7d713b92a51228e5ade945835e5a94a4.tar.bz2
+
+openembedded-core
+
+-  Repository Location: https://git.openembedded.org/openembedded-core
+-  Branch: :oe_git:`kirkstone </openembedded-core/log/?h=kirkstone>`
+-  Tag:  :oe_git:`yocto-4.0.4 </openembedded-core/log/?h=yocto-4.0.4>`
+-  Git Revision: :oe_git:`f7766da462905ec67bf549d46b8017be36cd5b2a </openembedded-core/commit/?id=f7766da462905ec67bf549d46b8017be36cd5b2a>`
+-  Release Artefact: oecore-f7766da462905ec67bf549d46b8017be36cd5b2a
+-  sha: ce0ac011474db5e5f0bb1be3fb97f890a02e46252a719dbcac5813268e48ff16
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.4/oecore-f7766da462905ec67bf549d46b8017be36cd5b2a.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.4/oecore-f7766da462905ec67bf549d46b8017be36cd5b2a.tar.bz2
+
+meta-mingw
+
+-  Repository Location: https://git.yoctoproject.org/git/meta-mingw
+-  Branch: :yocto_git:`kirkstone </meta-mingw/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.4 </meta-mingw/log/?h=yocto-4.0.4>`
+-  Git Revision: :yocto_git:`a90614a6498c3345704e9611f2842eb933dc51c1 </meta-mingw/commit/?id=a90614a6498c3345704e9611f2842eb933dc51c1>`
+-  Release Artefact: meta-mingw-a90614a6498c3345704e9611f2842eb933dc51c1
+-  sha: 49f9900bfbbc1c68136f8115b314e95d0b7f6be75edf36a75d9bcd1cca7c6302
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.4/meta-mingw-a90614a6498c3345704e9611f2842eb933dc51c1.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.4/meta-mingw-a90614a6498c3345704e9611f2842eb933dc51c1.tar.bz2
+
+meta-gplv2
+
+-  Repository Location: https://git.yoctoproject.org/git/meta-gplv2
+-  Branch: :yocto_git:`kirkstone </meta-gplv2/log/?h=kirkstone>`
+-  Tag:  :yocto_git:`yocto-4.0.4 </meta-gplv2/log/?h=yocto-4.0.4>`
+-  Git Revision: :yocto_git:`d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a </meta-gplv2/commit/?id=d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a>`
+-  Release Artefact: meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a
+-  sha: c386f59f8a672747dc3d0be1d4234b6039273d0e57933eb87caa20f56b9cca6d
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.4/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.4/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2
+
+bitbake
+
+-  Repository Location: https://git.openembedded.org/bitbake
+-  Branch: :oe_git:`2.0 </bitbake/log/?h=2.0>`
+-  Tag:  :oe_git:`yocto-4.0.4 </bitbake/log/?h=yocto-4.0.4>`
+-  Git Revision: :oe_git:`ac576d6fad6bba0cfea931883f25264ea83747ca </bitbake/commit/?id=ac576d6fad6bba0cfea931883f25264ea83747ca>`
+-  Release Artefact: bitbake-ac576d6fad6bba0cfea931883f25264ea83747ca
+-  sha: 526c2768874eeda61ade8c9ddb3113c90d36ef44a026d6690f02de6f3dd0ea12
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.4/bitbake-ac576d6fad6bba0cfea931883f25264ea83747ca.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.4/bitbake-ac576d6fad6bba0cfea931883f25264ea83747ca.tar.bz2
+
+yocto-docs
+
+-  Repository Location: https://git.yoctoproject.org/git/yocto-docs
+-  Branch: :yocto_git:`kirkstone </yocto-docs/log/?h=kirkstone>`
+-  Tag: :yocto_git:`yocto-4.0.4 </yocto-docs/log/?h=yocto-4.0.4>`
+-  Git Revision: :yocto_git:`f632dad24c39778f948014029e74db3c871d9d21 </yocto-docs/commit/?id=f632dad24c39778f948014029e74db3c871d9d21>`

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

@@ -22,8 +22,8 @@ New Features / Enhancements in 4.0
 
      BB_SIGNATURE_HANDLER = "OEEquivHash"
      BB_HASHSERVE = "auto"
-     BB_HASHSERVE_UPSTREAM = "typhoon.yocto.io:8687"
-     SSTATE_MIRRORS ?= "file://.* https://sstate.yoctoproject.org/&YOCTO_DOC_VERSION;/PATH;downloadfilename=PATH"
+     BB_HASHSERVE_UPSTREAM = "hashserv.yocto.io:8687"
+     SSTATE_MIRRORS ?= "file://.* https://sstate.yoctoproject.org/all/PATH;downloadfilename=PATH"
 
 - The Python package build process is now based on `wheels <https://pythonwheels.com/>`__
   in line with the upstream direction.

documentation/overview-manual/concepts.rst

@@ -109,10 +109,10 @@ Classes
 Class files (``.bbclass``) contain information that is useful to share
 between recipes files. An example is the
 :ref:`autotools <ref-classes-autotools>` class,
-which contains common settings for any application that is built with
-the `GNU Autotools <https://en.wikipedia.org/wiki/GNU_Autotools>`__.
-The ":ref:`ref-manual/classes:Classes`" chapter in the Yocto Project
-Reference Manual provides details about classes and how to use them.
+which contains common settings for any application that Autotools uses.
+The ":ref:`ref-manual/classes:Classes`" chapter in the
+Yocto Project Reference Manual provides details about classes and how to
+use them.
 
 Configurations
 --------------
@@ -140,7 +140,7 @@ using a different layer where that metadata might be common across
 several pieces of hardware.
 
 There are many layers working in the Yocto Project development environment. The
-:yocto_home:`Yocto Project Compatible Layer Index </software-overview/layers/>`
+:yocto_home:`Yocto Project Curated Layer Index </software-overview/layers/>`
 and :oe_layerindex:`OpenEmbedded Layer Index <>` both contain layers from
 which you can use or leverage.
 
@@ -166,7 +166,7 @@ remainder of this section expands on the fundamental input, output,
 process, and metadata logical blocks that make up the workflow.
 
 .. image:: figures/YP-flow-diagram.png
-   :width: 100%
+   :align: center
 
 In general, the build's workflow consists of several functional areas:
 
@@ -209,7 +209,7 @@ Configuration" box of the :ref:`general workflow
 figure <overview-manual/concepts:openembedded build system concepts>`:
 
 .. image:: figures/user-configuration.png
-   :width: 100%
+   :align: center
 
 BitBake needs some basic configuration files in order to complete a
 build. These files are ``*.conf`` files. The minimally necessary ones
@@ -313,7 +313,7 @@ section in the Yocto Project Development Tasks Manual.
 
 The files ``site.conf`` and ``auto.conf`` are not created by the
 environment initialization script. If you want the ``site.conf`` file,
-you need to create it yourself. The ``auto.conf`` file is typically
+you need to create that yourself. The ``auto.conf`` file is typically
 created by an autobuilder:
 
 -  *site.conf:* You can use the ``conf/site.conf`` configuration
@@ -321,7 +321,17 @@ created by an autobuilder:
    you had several build environments and they shared some common
    features. You can set these default build properties here. A good
    example is perhaps the packaging format to use through the
-   :term:`PACKAGE_CLASSES` variable.
+   :term:`PACKAGE_CLASSES`
+   variable.
+
+   One useful scenario for using the ``conf/site.conf`` file is to
+   extend your :term:`BBPATH` variable
+   to include the path to a ``conf/site.conf``. Then, when BitBake looks
+   for Metadata using :term:`BBPATH`, it finds the ``conf/site.conf`` file
+   and applies your common configurations found in the file. To override
+   configurations in a particular build directory, alter the similar
+   configurations within that build directory's ``conf/local.conf``
+   file.
 
 -  *auto.conf:* The file is usually created and written to by an
    autobuilder. The settings put into the file are typically the same as
@@ -391,7 +401,6 @@ layers from the :ref:`general workflow figure
 
 .. image:: figures/layer-input.png
    :align: center
-   :width: 70%
 
 In general, all layers have a similar structure. They all contain a
 licensing file (e.g. ``COPYING.MIT``) if the layer is to be distributed,
@@ -542,7 +551,6 @@ area of the :ref:`general workflow figure <overview-manual/concepts:openembedded
 
 .. image:: figures/source-input.png
    :align: center
-   :width: 70%
 
 Upstream Project Releases
 ~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -621,7 +629,7 @@ This section looks a little closer into the package feeds area used by
 the build system. Here is a more detailed look at the area:
 
 .. image:: figures/package-feeds.png
-   :width: 100%
+   :align: center
 
 Package feeds are an intermediary step in the build process. The
 OpenEmbedded build system provides classes to generate different package
@@ -694,7 +702,7 @@ The first stages of building a recipe are to fetch and unpack the source
 code:
 
 .. image:: figures/source-fetching.png
-   :width: 100%
+   :align: center
 
 The :ref:`ref-tasks-fetch` and
 :ref:`ref-tasks-unpack` tasks fetch
@@ -782,7 +790,7 @@ Once source code is fetched and unpacked, BitBake locates patch files
 and applies them to the source files:
 
 .. image:: figures/patching.png
-   :width: 100%
+   :align: center
 
 The :ref:`ref-tasks-patch` task uses a
 recipe's :term:`SRC_URI` statements
@@ -823,7 +831,7 @@ compile the source code. Once compilation occurs, the files are copied
 to a holding area (staged) in preparation for packaging:
 
 .. image:: figures/configuration-compile-autoreconf.png
-   :width: 100%
+   :align: center
 
 This step in the build process consists of the following tasks:
 
@@ -881,7 +889,7 @@ After source code is configured, compiled, and staged, the build system
 analyzes the results and splits the output into packages:
 
 .. image:: figures/analysis-for-package-splitting.png
-   :width: 100%
+   :align: center
 
 The :ref:`ref-tasks-package` and
 :ref:`ref-tasks-packagedata`
@@ -960,7 +968,7 @@ Once packages are split and stored in the Package Feeds area, the build
 system uses BitBake to generate the root filesystem image:
 
 .. image:: figures/image-generation.png
-   :width: 100%
+   :align: center
 
 The image generation process consists of several stages and depends on
 several tasks and variables. The
@@ -1078,7 +1086,7 @@ Development Kit (SDK) installer scripts for both the standard SDK and
 the extensible SDK (eSDK):
 
 .. image:: figures/sdk-generation.png
-   :width: 100%
+   :align: center
 
 .. note::
 
@@ -1254,7 +1262,6 @@ this output:
 
 .. image:: figures/images.png
    :align: center
-   :width: 75%
 
 .. note::
 
@@ -1314,7 +1321,7 @@ SDK (e.g. ``bitbake -c populate_sdk_ext`` imagename) or a standard SDK
 closer look at this output:
 
 .. image:: figures/sdk.png
-   :width: 100%
+   :align: center
 
 The specific form of this output is a set of files that includes a
 self-extracting SDK installer (``*.sh``), host and target manifest
@@ -1432,7 +1439,7 @@ The following figure shows a high-level build environment regarding
 toolchain construction and use.
 
 .. image:: figures/cross-development-toolchains.png
-   :width: 100%
+   :align: center
 
 Most of the work occurs on the Build Host. This is the machine used to
 build images and generally work within the the Yocto Project
@@ -2139,7 +2146,7 @@ dependencies, you must manually declare the dependencies.
 
       By default, ``foo-dev`` also has an :term:`RDEPENDS`-style dependency on
       ``foo``, because the default value of ``RDEPENDS:${PN}-dev`` (set in
-      ``bitbake.conf``) includes "${PN}".
+      bitbake.conf) includes "${PN}".
 
    To ensure that the dependency chain is never broken, ``-dev`` and
    ``-dbg`` packages are always generated by default, even if the

documentation/overview-manual/development-environment.rst

@@ -176,7 +176,7 @@ development:
    repositories for each of these areas.
 
    .. image:: figures/source-repos.png
-      :width: 100%
+      :align: center
 
    For steps on how to view and access these upstream Git repositories,
    see the ":ref:`dev-manual/start:accessing source repositories`"
@@ -191,7 +191,6 @@ development:
 
    .. image:: figures/index-downloads.png
       :align: center
-      :width: 50%
 
    For steps on how to view and access these files, see the
    ":ref:`dev-manual/start:accessing index of releases`"
@@ -206,7 +205,7 @@ development:
    :yocto_dl:`Index of /releases: </releases>` area.
 
    .. image:: figures/yp-download.png
-      :width: 100%
+      :align: center
 
    For steps on how to use the "DOWNLOADS" page, see the
    ":ref:`dev-manual/start:using the downloads page`"
@@ -617,9 +616,13 @@ this history, you can find basic information here:
 In general, the Yocto Project is broadly licensed under the
 Massachusetts Institute of Technology (MIT) License. MIT licensing
 permits the reuse of software within proprietary software as long as the
-license is distributed with that software. Patches to the Yocto Project
+license is distributed with that software. MIT is also compatible with
+the GNU General Public License (GPL). Patches to the Yocto Project
 follow the upstream licensing scheme. You can find information on the
-MIT license `here <https://en.wikipedia.org/wiki/MIT_License>`__.
+MIT license
+`here <https://www.opensource.org/licenses/mit-license.php>`__. You can
+find information on the GNU GPL
+`here <https://www.opensource.org/licenses/LGPL-3.0>`__.
 
 When you build an image using the Yocto Project, the build process uses
 a known list of licenses to ensure compliance. You can find this list in

documentation/overview-manual/yp-intro.rst

@@ -24,7 +24,7 @@ software customizations and build interchange for multiple hardware
 platforms as well as software stacks that can be maintained and scaled.
 
 .. image:: figures/key-dev-elements.png
-    :width: 100%
+    :align: center
 
 For further introductory information on the Yocto Project, you might be
 interested in this
@@ -218,8 +218,8 @@ your Metadata, the easier it is to cope with future changes.
       possible.
 
    -  Familiarize yourself with the
-      :yocto_home:`Yocto Project Compatible Layers </software-overview/layers/>`
-      or the :oe_layerindex:`OpenEmbedded Layer Index <>`.
+      :yocto_home:`Yocto Project curated layer index</software-overview/layers/>`
+      or the :oe_layerindex:`OpenEmbedded layer index <>`.
       The latter contains more layers but they are less universally
       validated.
 
@@ -638,7 +638,7 @@ these items that make up the Poky repository in the
 The following figure illustrates what generally comprises Poky:
 
 .. image:: figures/poky-reference-distribution.png
-    :width: 100%
+    :align: center
 
 -  BitBake is a task executor and scheduler that is the heart of the
    OpenEmbedded build system.
@@ -688,8 +688,8 @@ Sato.
 
 One of the most powerful properties of Poky is that every aspect of a
 build is controlled by the metadata. You can use metadata to augment
-these base image types by adding metadata :ref:`layers
-<overview-manual/yp-intro:the yocto project layer model>` that extend
+these base image types by adding metadata
+`layers <overview-manual/yp-intro:the yocto project layer model>` that extend
 functionality.
 These layers can provide, for example, an additional software stack for
 an image type, add a board support package (BSP) for additional
@@ -720,7 +720,7 @@ accomplish image and SDK generation. The following figure overviews that
 workflow:
 
 .. image:: figures/YP-flow-diagram.png
-    :width: 100%
+    :align: center
 
 Following is a brief summary of the "workflow":
 

documentation/poky.yaml.in

@@ -44,4 +44,5 @@ PIP3_HOST_PACKAGES_DOC : "$ sudo pip3 install sphinx sphinx_rtd_theme pyyaml"
 MIN_PYTHON_VERSION : "3.6.0"
 MIN_TAR_VERSION : "1.28"
 MIN_GIT_VERSION : "1.8.3.1"
-MIN_GCC_VERSION : "5.0"
+MIN_GCC_VERSION : "7.5"
+MIN_MAKE_VERSION : "4.0"

documentation/profile-manual/usage.rst

@@ -197,7 +197,6 @@ in an interactive UI::
 
 .. image:: figures/perf-wget-flat-stripped.png
    :align: center
-   :width: 70%
 
 The above screenshot displays a 'flat' profile, one entry for each
 'bucket' corresponding to the functions that were profiled during the
@@ -231,7 +230,6 @@ but the entire callchain to the sampled function as well::
 
 .. image:: figures/perf-wget-g-copy-to-user-expanded-stripped.png
    :align: center
-   :width: 70%
 
 Using the callgraph view, we can actually see not only which functions
 took the most time, but we can also see a summary of how those functions
@@ -268,7 +266,6 @@ busybox.
 
 .. image:: figures/perf-wget-g-copy-from-user-expanded-stripped.png
    :align: center
-   :width: 70%
 
 The above screenshot shows the other half of the journey for the data -
 from the wget program's userspace buffers to disk. To get the buffers to
@@ -286,7 +283,6 @@ let's expand the first entry containing BusyBox:
 
 .. image:: figures/perf-wget-busybox-expanded-stripped.png
    :align: center
-   :width: 70%
 
 Again, before we expanded we saw that the function was labeled with a
 hex value instead of a symbol as with most of the kernel entries.
@@ -334,7 +330,6 @@ their functions symbolically:
 
 .. image:: figures/perf-wget-busybox-debuginfo.png
    :align: center
-   :width: 70%
 
 If we expand one of the entries and press 'enter' on a leaf node, we're
 presented with a menu of actions we can take to get more information
@@ -342,7 +337,6 @@ related to that entry:
 
 .. image:: figures/perf-wget-busybox-dso-zoom-menu.png
    :align: center
-   :width: 70%
 
 One of these actions allows us to show a view that displays a
 busybox-centric view of the profiled functions (in this case we've also
@@ -350,7 +344,6 @@ expanded all the nodes using the 'E' key):
 
 .. image:: figures/perf-wget-busybox-dso-zoom.png
    :align: center
-   :width: 70%
 
 Finally, we can see that now that the BusyBox debuginfo is installed,
 the previously unresolved symbol in the ``sys_clock_gettime()`` entry
@@ -361,7 +354,6 @@ function:
 
 .. image:: figures/perf-wget-g-copy-to-user-expanded-debuginfo.png
    :align: center
-   :width: 70%
 
 At the lowest level of detail, we can dive down to the assembly level
 and see which instructions caused the most overhead in a function.
@@ -370,7 +362,6 @@ with a menu:
 
 .. image:: figures/perf-wget-busybox-annotate-menu.png
    :align: center
-   :width: 70%
 
 Selecting 'Annotate udhcpc_main', we get a detailed listing of
 percentages by instruction for the udhcpc_main function. From the
@@ -379,7 +370,6 @@ taken up by a couple tests and the move of a constant (1) to a register:
 
 .. image:: figures/perf-wget-busybox-annotate-udhcpc.png
    :align: center
-   :width: 70%
 
 As a segue into tracing, let's try another profile using a different
 counter, something other than the default 'cycles'.
@@ -603,7 +593,6 @@ and tell perf to do a profile using it as the sampling event::
 
 .. image:: figures/sched-wakeup-profile.png
    :align: center
-   :width: 70%
 
 The screenshot above shows the results of running a profile using
 sched:sched_switch tracepoint, which shows the relative costs of various
@@ -751,7 +740,7 @@ entry/exit events we recorded::
    root@crownbay:~# perf script -g python
    generated Python script: perf-script.py
 
-The skeleton script simply creates a Python function for each event type in the
+The skeleton script simply creates a python function for each event type in the
 perf.data file. The body of each function simply prints the event name along
 with its parameters. For example:
 
@@ -870,7 +859,7 @@ 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 `'perf script' python
 binding <https://linux.die.net/man/1/perf-script-python>`__.
 
 System-Wide Tracing and Profiling
@@ -905,7 +894,6 @@ other processes running on the system as well:
 
 .. image:: figures/perf-systemwide.png
    :align: center
-   :width: 70%
 
 In the snapshot above, we can see callchains that originate in libc, and
 a callchain from Xorg that demonstrates that we're using a proprietary X
@@ -923,7 +911,6 @@ record a profile::
 
 .. image:: figures/perf-report-cycles-u.png
    :align: center
-   :width: 70%
 
 Notice in the screenshot above, we see only userspace entries ([.])
 
@@ -934,7 +921,6 @@ the entries associated with the libc-xxx.so DSO.
 
 .. image:: figures/perf-systemwide-libc.png
    :align: center
-   :width: 70%
 
 We can also use the system-wide -a switch to do system-wide tracing.
 Here we'll trace a couple of scheduler events::
@@ -1130,7 +1116,6 @@ callgraphs from starting a few programs during those 30 seconds:
 
 .. image:: figures/perf-probe-do_fork-profile.png
    :align: center
-   :width: 70%
 
 .. admonition:: Tying it Together
 
@@ -1164,7 +1149,7 @@ section can be found here:
 -  The `'perf script'
    manpage <https://linux.die.net/man/1/perf-script>`__.
 
--  Documentation on using the `'perf script' Python
+-  Documentation on using the `'perf script' python
    binding <https://linux.die.net/man/1/perf-script-python>`__.
 
 -  The top-level `perf(1) manpage <https://linux.die.net/man/1/perf>`__.
@@ -1699,7 +1684,6 @@ events (or even one or more complete subsystems) to trace:
 
 .. image:: figures/kernelshark-choose-events.png
    :align: center
-   :width: 70%
 
 Note that these are exactly the same sets of events described in the
 previous trace events subsystem section, and in fact is where trace-cmd
@@ -1715,7 +1699,6 @@ will turn into the 'Stop' button after the trace has started):
 
 .. image:: figures/kernelshark-output-display.png
    :align: center
-   :width: 70%
 
 Notice that the right-hand pane shows the exact trace-cmd command-line
 that's used to run the trace, along with the results of the trace-cmd
@@ -1727,14 +1710,12 @@ detailed event listing below that:
 
 .. image:: figures/kernelshark-i915-display.png
    :align: center
-   :width: 70%
 
 Here's another example, this time a display resulting from tracing 'all
 events':
 
 .. image:: figures/kernelshark-all.png
    :align: center
-   :width: 70%
 
 The tool is pretty self-explanatory, but for more detailed information
 on navigating through the data, see the `kernelshark
@@ -1993,7 +1974,6 @@ with profiling data:
 
 .. image:: figures/sysprof-copy-to-user.png
    :align: center
-   :width: 70%
 
 The left pane shows a list of functions and processes. Selecting one of
 those expands that function in the right pane, showing all its callees.
@@ -2008,7 +1988,6 @@ in the perf display shown in the perf section of this page.
 
 .. image:: figures/sysprof-copy-from-user.png
    :align: center
-   :width: 70%
 
 Similarly, the above is a snapshot of the Sysprof display of a
 copy-from-user callchain.
@@ -2020,7 +1999,6 @@ left pane. In this case, the lower pane is showing all the callers of
 
 .. image:: figures/sysprof-callers.png
    :align: center
-   :width: 70%
 
 Double-clicking on one of those functions will in turn change the focus
 to the selected function, and so on.

documentation/ref-manual/classes.rst

@@ -78,8 +78,7 @@ about the variable flags (varflags) that help control archive creation.
 ``autotools*.bbclass``
 ======================
 
-The ``autotools*`` classes support packages built with the
-`GNU Autotools <https://en.wikipedia.org/wiki/GNU_Autotools>`__.
+The ``autotools*`` classes support Autotooled packages.
 
 The ``autoconf``, ``automake``, and ``libtool`` packages bring
 standardization. This class defines a set of tasks (e.g. ``configure``,
@@ -362,6 +361,32 @@ authors used.
 Both build methods inherit the ``cpan-base`` class for basic Perl
 support.
 
+.. _ref-classes-create-spdx:
+
+``create-spdx.bbclass``
+=======================
+
+The :ref:`create-spdx <ref-classes-create-spdx>` class provides support for
+automatically creating :term:`SPDX` :term:`SBOM` documents based upon image
+and SDK contents.
+
+This class is meant to be inherited globally from a configuration file::
+
+   INHERIT += "create-spdx"
+
+The toplevel :term:`SPDX` output file is generated in JSON format as a
+``IMAGE-MACHINE.spdx.json`` file in ``tmp/deploy/images/MACHINE/`` inside the
+:term:`Build Directory`. There are other related files in the same directory,
+as well as in ``tmp/deploy/spdx``.
+
+The exact behaviour of this class, and the amount of output can be controlled
+by the :term:`SPDX_ARCHIVE_PACKAGED`, :term:`SPDX_ARCHIVE_SOURCES` and
+:term:`SPDX_INCLUDE_SOURCES` variables.
+
+See the description of these variables and the
+":ref:`dev-manual/common-tasks:creating a software bill of materials`"
+section in the Yocto Project Development Manual for more details.
+
 .. _ref-classes-cross:
 
 ``cross.bbclass``
@@ -397,14 +422,62 @@ discussion on these cross-compilation tools.
 ``cve-check.bbclass``
 =====================
 
-The ``cve-check`` class looks for known CVEs (Common Vulnerabilities
-and Exposures) while building an image. This class is meant to be
+The :ref:`cve-check <ref-classes-cve-check>` class looks for known CVEs (Common Vulnerabilities
+and Exposures) while building with BitBake. This class is meant to be
 inherited globally from a configuration file::
 
    INHERIT += "cve-check"
 
+To filter out obsolete CVE database entries which are known not to impact software from Poky and OE-Core,
+add following line to the build configuration file::
+
+   include cve-extra-exclusions.inc
+
 You can also look for vulnerabilities in specific packages by passing
-``-c cve_check`` to BitBake. You will find details in the
+``-c cve_check`` to BitBake.
+
+After building the software with Bitbake, CVE check output reports are available in ``tmp/deploy/cve``
+and image specific summaries in ``tmp/deploy/images/*.cve`` or ``tmp/deploy/images/*.json`` files.
+
+When building, the CVE checker will emit build time warnings for any detected
+issues which are in the state ``Unpatched``, meaning that CVE issue seems to affect the software component
+and version being compiled and no patches to address the issue are applied. Other states
+for detected CVE issues are: ``Patched`` meaning that a patch to address the issue is already
+applied, and ``Ignored`` meaning that the issue can be ignored.
+
+The ``Patched`` state of a CVE issue is detected from patch files with the format
+``CVE-ID.patch``, e.g. ``CVE-2019-20633.patch``, in the :term:`SRC_URI` and using
+CVE metadata of format ``CVE: CVE-ID`` in the commit message of the patch file.
+
+If the recipe lists the ``CVE-ID`` in :term:`CVE_CHECK_IGNORE` variable, then the CVE state is reported
+as ``Ignored``. Multiple CVEs can be listed separated by spaces. Example::
+
+   CVE_CHECK_IGNORE += "CVE-2020-29509 CVE-2020-29511"
+
+If CVE check reports that a recipe contains false positives or false negatives, these may be
+fixed in recipes by adjusting the CVE product name using :term:`CVE_PRODUCT` and :term:`CVE_VERSION` variables.
+:term:`CVE_PRODUCT` defaults to the plain recipe name :term:`BPN` which can be adjusted to one or more CVE
+database vendor and product pairs using the syntax::
+
+   CVE_PRODUCT = "flex_project:flex"
+
+where ``flex_project`` is the CVE database vendor name and ``flex`` is the product name. Similarly
+if the default recipe version :term:`PV` does not match the version numbers of the software component
+in upstream releases or the CVE database, then the :term:`CVE_VERSION` variable can be used to set the
+CVE database compatible version number, for example::
+
+   CVE_VERSION = "2.39"
+
+Any bugs or missing or incomplete information in the CVE database entries should be fixed in the CVE database
+via the `NVD feedback form <https://nvd.nist.gov/info/contact-form>`__.
+
+Users should note that security is a process, not a product, and thus also CVE checking, analyzing results,
+patching and updating the software should be done as a regular process. The data and assumptions
+required for CVE checker to reliably detect issues are frequently broken in various ways.
+These can only be detected by reviewing the details of the issues and iterating over the generated reports,
+and following what happens in other Linux distributions and in the greater open source community.
+
+You will find some more details in the
 ":ref:`dev-manual/common-tasks:checking for vulnerabilities`"
 section in the Development Tasks Manual.
 
@@ -1976,6 +2049,22 @@ When inherited by a recipe, the ``perlnative`` class supports using the
 native version of Perl built by the build system rather than using the
 version provided by the build host.
 
+.. _ref-classes-pypi:
+
+``pypi.bbclass``
+================
+
+The :ref:`pypi <ref-classes-pypi>` class sets variables appropriately for recipes that build
+Python modules from `PyPI <https://pypi.org/>`__, the Python Package Index.
+By default it determines the PyPI package name based upon :term:`BPN`
+(stripping the "python-" or "python3-" prefix off if present), however in
+some cases you may need to set it manually in the recipe by setting
+:term:`PYPI_PACKAGE`.
+
+Variables set by the :ref:`pypi <ref-classes-pypi>` class include :term:`SRC_URI`, :term:`SECTION`,
+:term:`HOMEPAGE`, :term:`UPSTREAM_CHECK_URI`, :term:`UPSTREAM_CHECK_REGEX`
+and :term:`CVE_PRODUCT`.
+
 .. _ref-classes-python_flit_core:
 
 ``python_flit_core.bbclass``

documentation/ref-manual/devtool-reference.rst

@@ -126,7 +126,8 @@ common working area used across the tool.
 The following figure shows the workspace structure:
 
 .. image:: figures/build-workspace-directory.png
-   :scale: 100%
+   :align: center
+   :scale: 70%
 
 .. code-block:: none
 

documentation/ref-manual/features.rst

@@ -62,6 +62,8 @@ Project metadata:
 
 -  *keyboard:* Hardware has a keyboard
 
+-  *numa:* Hardware has non-uniform memory access
+
 -  *pcbios:* Support for booting through BIOS
 
 -  *pci:* Hardware has a PCI bus

documentation/ref-manual/structure.rst

@@ -261,7 +261,7 @@ OpenEmbedded build system creates it from ``local.conf.sample`` when you
 :ref:`structure-core-script`.
 
 The source ``local.conf.sample`` file used depends on the
-:term:`TEMPLATECONF` script variable, which defaults to ``meta-poky/conf/``
+``$TEMPLATECONF`` script variable, which defaults to ``meta-poky/conf/``
 when you are building from the Yocto Project development environment,
 and to ``meta/conf/`` when you are building from the OpenEmbedded-Core
 environment. Because the script variable points to the source of the
@@ -278,7 +278,7 @@ file, it uses ``sed`` to substitute final
 
 .. note::
 
-   You can see how the :term:`TEMPLATECONF` variable is used by looking at the
+   You can see how the ``TEMPLATECONF`` variable is used by looking at the
    ``scripts/oe-setup-builddir`` script in the :term:`Source Directory`.
    You can find the Yocto Project version of the ``local.conf.sample`` file in
    the ``meta-poky/conf`` directory.
@@ -300,7 +300,7 @@ you ``source`` the top-level build environment setup script (i.e.
 :ref:`structure-core-script`).
 
 As with the ``local.conf`` file, the source ``bblayers.conf.sample``
-file used depends on the :term:`TEMPLATECONF` script variable, which
+file used depends on the ``$TEMPLATECONF`` script variable, which
 defaults to ``meta-poky/conf/`` when you are building from the Yocto
 Project development environment, and to ``meta/conf/`` when you are
 building from the OpenEmbedded-Core environment. Because the script
@@ -315,7 +315,7 @@ Once the build process gets the sample file, it uses ``sed`` to substitute final
 
 .. note::
 
-   You can see how the :term:`TEMPLATECONF` variable is defined by the ``scripts/oe-setup-builddir``
+   You can see how the ``TEMPLATECONF`` variable ``scripts/oe-setup-builddir``
    script in the :term:`Source Directory`. You can find the Yocto Project
    version of the ``bblayers.conf.sample`` file in the ``meta-poky/conf/``
    directory.

documentation/ref-manual/system-requirements.rst

@@ -41,6 +41,8 @@ distributions:
 
 -  Ubuntu 20.04 (LTS)
 
+-  Ubuntu 22.04 (LTS)
+
 -  Fedora 34
 
 -  Fedora 35

documentation/ref-manual/tasks.rst

@@ -522,7 +522,7 @@ scratch is guaranteed.
 Starts a shell in which an interactive Python interpreter allows you to
 interact with the BitBake build environment. From within this shell, you
 can directly examine and set bits from the data store and execute
-functions as if within the BitBake environment. See the ":ref:`dev-manual/common-tasks:using a Python development shell`" section in
+functions as if within the BitBake environment. See the ":ref:`dev-manual/common-tasks:using a python development shell`" section in
 the Yocto Project Development Tasks Manual for more information about
 using ``pydevshell``.
 

documentation/ref-manual/terms.rst

@@ -323,6 +323,23 @@ universal, the list includes them just in case:
       :term:`build host<Build Host>` and other components, that can
       work on specific hardware.
 
+   :term:`SBOM`
+      This term means *Software Bill of Materials*. When you distribute
+      software, it offers a description of all the components you used,
+      their corresponding licenses, their dependencies, the changes that were
+      applied and the known vulnerabilities that were fixed.
+
+      This can be used by the recipients of the software to assess
+      their exposure to license compliance and security vulnerability issues.
+
+      See the :wikipedia:`Software Supply Chain <Software_supply_chain>`
+      article on Wikipedia for more details.
+
+      The OpenEmbedded Build System can generate such documentation for your
+      project, in :term:`SPDX` format, based on all the metadata it used to
+      build the software images. See the ":ref:`dev-manual/common-tasks:creating
+      a software bill of materials`" section of the Development Tasks manual.
+
    :term:`Source Directory`
      This term refers to the directory structure
      created as a result of creating a local copy of the ``poky`` Git
@@ -383,6 +400,17 @@ universal, the list includes them just in case:
      ":ref:`overview-manual/development-environment:repositories, tags, and branches`"
      section in the Yocto Project Overview and Concepts Manual.
 
+   :term:`SPDX`
+      This term means *Software Package Data Exchange*, and is used as a open
+      standard for providing a *Software Bill of Materials* (:term:`SBOM`).
+      This standard is developed through a `Linux Foundation project
+      <https://spdx.dev/>`__ and is used by the OpenEmbedded Build System to
+      provide an :term:`SBOM` associated to each a software image.
+
+      For details, see Wikipedia's :wikipedia:`SPDX page <Software_Package_Data_Exchange>`
+      and the ":ref:`dev-manual/common-tasks:creating a software bill of materials`"
+      section of the Development Tasks manual.
+
    :term:`Task`
       A per-recipe unit of execution for BitBake (e.g.
       :ref:`ref-tasks-compile`,

documentation/ref-manual/variables.rst

@@ -1469,15 +1469,31 @@ system and gives an overview of their function and contents.
          # This is windows only issue.
          CVE_CHECK_IGNORE += "CVE-2020-15523"
 
+   :term:`CVE_CHECK_SHOW_WARNINGS`
+      Specifies whether or not the :ref:`cve-check <ref-classes-cve-check>`
+      class should generate warning messages on the console when unpatched
+      CVEs are found. The default is "1", but you may wish to set it to "0" if
+      you are already examining/processing the logs after the build has
+      completed and thus do not need the warning messages.
+
    :term:`CVE_CHECK_SKIP_RECIPE`
       The list of package names (:term:`PN`) for which
       CVEs (Common Vulnerabilities and Exposures) are ignored.
 
+   :term:`CVE_DB_UPDATE_INTERVAL`
+      Specifies the CVE database update interval in seconds, as used by
+      ``cve-update-db-native``. The default value is "86400" i.e. once a day
+      (24*60*60). If the value is set to "0" then the update will be forced
+      every time. Alternatively, a negative value e.g. "-1" will disable
+      updates entirely.
+
    :term:`CVE_PRODUCT`
       In a recipe, defines the name used to match the recipe name
       against the name in the upstream `NIST CVE database <https://nvd.nist.gov/>`__.
 
-      The default is ${:term:`BPN`}. If it does not match the name in the NIST CVE
+      The default is ${:term:`BPN`} (except for recipes that inherit the
+      :ref:`pypi <ref-classes-pypi>` class where it is set based upon
+      :term:`PYPI_PACKAGE`). If it does not match the name in the NIST CVE
       database or matches with multiple entries in the database, the default
       value needs to be changed.
 
@@ -1492,6 +1508,18 @@ system and gives an overview of their function and contents.
 
          CVE_PRODUCT = "vendor:package"
 
+   :term:`CVE_VERSION`
+      In a recipe, defines the version used to match the recipe version
+      against the version in the `NIST CVE database <https://nvd.nist.gov/>`__
+      when usign :ref:`cve-check <ref-classes-cve-check>`.
+
+      The default is ${:term:`PV`} but if recipes use custom version numbers
+      which do not map to upstream software component release versions and the versions
+      used in the CVE database, then this variable can be used to set the
+      version number for :ref:`cve-check <ref-classes-cve-check>`. Example::
+
+          CVE_VERSION = "2.39"
+
    :term:`CVSDIR`
       The directory in which files checked out under the CVS system are
       stored.
@@ -3551,7 +3579,7 @@ system and gives an overview of their function and contents.
 
       For more information on :term:`INHERIT`, see the
       :ref:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata:\`\`inherit\`\` configuration directive`"
-      section in the BitBake User Manual.
+      section in the Bitbake User Manual.
 
    :term:`INHERIT_DISTRO`
       Lists classes that will be inherited at the distribution level. It is
@@ -4064,10 +4092,10 @@ system and gives an overview of their function and contents.
       statements add specific configurations to targeted machine types::
 
          KERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc features/taskstats/taskstats.scc"
-         KERNEL_FEATURES:append = " ${KERNEL_EXTRA_FEATURES}"
-         KERNEL_FEATURES:append:qemuall = " cfg/virtio.scc"
-         KERNEL_FEATURES:append:qemux86 = "  cfg/sound.scc cfg/paravirt_kvm.scc"
-         KERNEL_FEATURES:append:qemux86-64 = " cfg/sound.scc"
+         KERNEL_FEATURES:append = "${KERNEL_EXTRA_FEATURES}"
+         KERNEL_FEATURES:append:qemuall = "cfg/virtio.scc"
+         KERNEL_FEATURES:append:qemux86 = " cfg/sound.scc cfg/paravirt_kvm.scc"
+         KERNEL_FEATURES:append:qemux86-64 = "cfg/sound.scc"
 
    :term:`KERNEL_FIT_LINK_NAME`
       The link name of the kernel flattened image tree (FIT) image. This
@@ -4255,7 +4283,7 @@ system and gives an overview of their function and contents.
          SRCREV_machine:core2-32-intel-common = "43b9eced9ba8a57add36af07736344dcc383f711"
          KMACHINE:core2-32-intel-common = "intel-core2-32"
          KBRANCH:core2-32-intel-common = "standard/base"
-         KERNEL_FEATURES:append:core2-32-intel-common = " ${KERNEL_FEATURES_INTEL_COMMON}"
+         KERNEL_FEATURES:append:core2-32-intel-common = "${KERNEL_FEATURES_INTEL_COMMON}"
 
       The :term:`KMACHINE` statement says
       that the kernel understands the machine name as "intel-core2-32".
@@ -6089,6 +6117,14 @@ system and gives an overview of their function and contents.
 
       :term:`PV` is the default value of the :term:`PKGV` variable.
 
+   :term:`PYPI_PACKAGE`
+      When inheriting the :ref:`pypi <ref-classes-pypi>` class, specifies the
+      `PyPI <https://pypi.org/>`__ package name to be built. The default value
+      is set based upon :term:`BPN` (stripping any "python-" or "python3-"
+      prefix off if present), however for some packages it will need to be set
+      explicitly if that will not match the package name (e.g. where the
+      package name has a prefix, underscores, uppercase letters etc.)
+
    :term:`PYTHON_ABI`
       When used by recipes that inherit the
       :ref:`setuptools3 <ref-classes-setuptools3>` class, denotes the
@@ -7058,6 +7094,77 @@ system and gives an overview of their function and contents.
 
          You can specify only a single URL in :term:`SOURCE_MIRROR_URL`.
 
+   :term:`SPDX_ARCHIVE_PACKAGED`
+      This option allows to add to :term:`SPDX` output compressed archives
+      of the files in the generated target packages.
+
+      Such archives are available in
+      ``tmp/deploy/spdx/MACHINE/packages/packagename.tar.zst``
+      under the :term:`Build Directory`.
+
+      Enable this option as follows::
+
+         SPDX_ARCHIVE_PACKAGED = "1"
+
+      According to our tests on release 4.1 "langdale", building
+      ``core-image-minimal`` for the ``qemux86-64`` machine, enabling this
+      option multiplied the size of the ``tmp/deploy/spdx`` directory by a
+      factor of 13 (+1.6 GiB for this image), compared to just using the
+      :ref:`create-spdx <ref-classes-create-spdx>` class with no option.
+
+      Note that this option doesn't increase the size of :term:`SPDX`
+      files in ``tmp/deploy/images/MACHINE``.
+
+   :term:`SPDX_ARCHIVE_SOURCES`
+      This option allows to add to :term:`SPDX` output compressed archives
+      of the sources for packages installed on the target. It currently
+      only works when :term:`SPDX_INCLUDE_SOURCES` is set.
+
+      This is one way of fulfilling "source code access" license
+      requirements.
+
+      Such source archives are available in
+      ``tmp/deploy/spdx/MACHINE/recipes/recipe-packagename.tar.zst``
+      under the :term:`Build Directory`.
+
+      Enable this option as follows::
+
+         SPDX_INCLUDE_SOURCES = "1"
+         SPDX_ARCHIVE_SOURCES = "1"
+
+      According to our tests on release 4.1 "langdale", building
+      ``core-image-minimal`` for the ``qemux86-64`` machine, enabling
+      these options multiplied the size of the ``tmp/deploy/spdx``
+      directory by a factor of 11 (+1.4 GiB for this image),
+      compared to just using the :ref:`create-spdx <ref-classes-create-spdx>`
+      class with no option.
+
+      Note that using this option only marginally increases the size
+      of the :term:`SPDX` output in ``tmp/deploy/images/MACHINE/``
+      (+ 0.07\% with the tested image), compared to just enabling
+      :term:`SPDX_INCLUDE_SOURCES`.
+
+   :term:`SPDX_INCLUDE_SOURCES`
+      This option allows to add a description of the source files used to build
+      the host tools and the target packages, to the ``spdx.json`` files in
+      ``tmp/deploy/spdx/MACHINE/recipes/`` under the :term:`Build Directory`.
+      As a consequence, the ``spdx.json`` files under the ``by-namespace`` and
+      ``packages`` subdirectories in ``tmp/deploy/spdx/MACHINE`` are also
+      modified to include references to such source file descriptions.
+
+      Enable this option as follows::
+
+         SPDX_INCLUDE_SOURCES = "1"
+
+      According to our tests on release 4.1 "langdale", building
+      ``core-image-minimal`` for the ``qemux86-64`` machine, enabling
+      this option multiplied the total size of the ``tmp/deploy/spdx``
+      directory by a factor of 3  (+291 MiB for this image),
+      and the size of the ``IMAGE-MACHINE.spdx.tar.zst`` in
+      ``tmp/deploy/images/MACHINE`` by a factor of 130 (+15 MiB for this
+      image), compared to just using the
+      :ref:`create-spdx <ref-classes-create-spdx>` class with no option.
+
    :term:`SPDXLICENSEMAP`
       Maps commonly used license names to their SPDX counterparts found in
       ``meta/files/common-licenses/``. For the default :term:`SPDXLICENSEMAP`
@@ -7609,7 +7716,7 @@ system and gives an overview of their function and contents.
       :ref:`systemd-boot <ref-classes-systemd-boot>` class sets the
       :term:`SYSTEMD_BOOT_CFG` as follows::
 
-         SYSTEMD_BOOT_CFG ?= "${:term:`S`}/loader.conf"
+         SYSTEMD_BOOT_CFG ?= "${S}/loader.conf"
 
       For information on Systemd-boot, see the `Systemd-boot
       documentation <https://www.freedesktop.org/wiki/Software/systemd/systemd-boot/>`__.
@@ -7899,21 +8006,6 @@ system and gives an overview of their function and contents.
       toolchain. You can use ``meta-sourcery`` as a template for adding
       support for other external toolchains.
 
-   :term:`TEMPLATECONF`
-      Specifies the directory used by the build system to find templates
-      from which to build the ``bblayers.conf`` and ``local.conf`` files.
-      Use this variable if you wish to customize such files, and the default
-      BitBake targets shown when sourcing the ``oe-init-build-env`` script.
-
-      For details, see the
-      :ref:`dev-manual/common-tasks:creating a custom template configuration directory`
-      section in the Yocto Project Development Tasks manual.
-
-      .. note::
-
-         You must set this variable in the external environment in order
-         for it to work.
-
    :term:`TEST_EXPORT_DIR`
       The location the OpenEmbedded build system uses to export tests when
       the :term:`TEST_EXPORT_ONLY` variable is set
@@ -8767,19 +8859,6 @@ system and gives an overview of their function and contents.
       previous example, some-native-tool would be replaced with an actual
       native tool on which the build would depend.
 
-   :term:`WKS_FILES`
-      Specifies a list of candidate Wic kickstart files to be used by the
-      OpenEmbedded build system to create a partitioned image. Only the
-      first one that is found, from left to right, will be used.
-
-      This is only useful when there are multiple ``.wks`` files that can be
-      used to produce an image. A typical case is when multiple layers are
-      used for different hardware platforms, each supplying a different
-      ``.wks`` file. In this case, you specify all possible ones through
-      :term:`WKS_FILES`.
-
-      If only one ``.wks`` file is used, set :term:`WKS_FILE` instead.
-
    :term:`WORKDIR`
       The pathname of the work directory in which the OpenEmbedded build
       system builds a recipe. This directory is located within the

documentation/releases.rst

@@ -16,7 +16,6 @@ Release Series 4.0 (kirkstone)
 ******************************
 
 - :yocto_docs:`4.0 Documentation </4.0>`
-- :yocto_docs:`4.0.1 Documentation </4.0.1>`
 
 ******************************
 Release Series 3.4 (honister)
@@ -26,7 +25,6 @@ Release Series 3.4 (honister)
 - :yocto_docs:`3.4.1 Documentation </3.4.1>`
 - :yocto_docs:`3.4.2 Documentation </3.4.2>`
 - :yocto_docs:`3.4.3 Documentation </3.4.3>`
-- :yocto_docs:`3.4.4 Documentation </3.4.4>`
 
 ******************************
 Release Series 3.3 (hardknott)
@@ -38,7 +36,6 @@ Release Series 3.3 (hardknott)
 - :yocto_docs:`3.3.3 Documentation </3.3.3>`
 - :yocto_docs:`3.3.4 Documentation </3.3.4>`
 - :yocto_docs:`3.3.5 Documentation </3.3.5>`
-- :yocto_docs:`3.3.6 Documentation </3.3.6>`
 
 ****************************
 Release Series 3.1 (dunfell)
@@ -60,7 +57,6 @@ Release Series 3.1 (dunfell)
 - :yocto_docs:`3.1.13 Documentation </3.1.13>`
 - :yocto_docs:`3.1.14 Documentation </3.1.14>`
 - :yocto_docs:`3.1.15 Documentation </3.1.15>`
-- :yocto_docs:`3.1.16 Documentation </3.1.16>`
 
 ==========================
  Outdated Release Manuals

documentation/sdk-manual/appendix-obtain.rst

@@ -265,7 +265,8 @@ install the Standard SDK by running the ``*.sh`` SDK installation
 script:
 
 .. image:: figures/sdk-installed-standard-sdk-directory.png
-   :scale: 100%
+   :scale: 80%
+   :align: center
 
 The installed SDK consists of an environment setup script for the SDK, a
 configuration file for the target, a version file for the target, and

documentation/sdk-manual/extensible.rst

@@ -233,7 +233,7 @@ shows common development flows you would use with the ``devtool add``
 command:
 
 .. image:: figures/sdk-devtool-add-flow.png
-   :width: 100%
+   :align: center
 
 1. *Generating the New Recipe*: The top part of the flow shows three
    scenarios by which you could use ``devtool add`` to generate a recipe
@@ -401,7 +401,7 @@ diagram shows common development flows for the ``devtool modify``
 command:
 
 .. image:: figures/sdk-devtool-modify-flow.png
-   :width: 100%
+   :align: center
 
 1. *Preparing to Modify the Code*: The top part of the flow shows three
    scenarios by which you could use ``devtool modify`` to prepare to
@@ -620,7 +620,7 @@ The following diagram shows the common development flow used with the
 ``devtool upgrade`` command:
 
 .. image:: figures/sdk-devtool-upgrade-flow.png
-   :width: 100%
+   :align: center
 
 1. *Initiate the Upgrade*: The top part of the flow shows the typical
    scenario by which you use the ``devtool upgrade`` command. The

documentation/sdk-manual/intro.rst

@@ -149,7 +149,7 @@ SDK Development Model
 Fundamentally, the SDK fits into the development process as follows:
 
 .. image:: figures/sdk-environment.png
-   :width: 100%
+   :align: center
 
 The SDK is installed on any machine and can be used to develop applications,
 images, and kernels. An SDK can even be used by a QA Engineer or Release

documentation/sdk-manual/working-projects.rst

@@ -19,7 +19,6 @@ The following figure presents a simple Autotools workflow.
 
 .. image:: figures/sdk-autotools-flow.png
    :align: center
-   :width: 70%
 
 Follow these steps to create a simple Autotools-based "Hello World"
 project:
@@ -169,7 +168,6 @@ variables and Makefile variables during development.
 
 .. image:: figures/sdk-makefile-flow.png
    :align: center
-   :width: 70%
 
 The main point of this section is to explain the following three cases
 regarding variable behavior:

documentation/set_versions.py

@@ -23,15 +23,10 @@ ourversion = None
 if len(sys.argv) == 2:
     ourversion = sys.argv[1]
 
-activereleases = ["kirkstone", "honister", "dunfell"]
+activereleases = ["kirkstone", "honister", "hardknott", "dunfell"]
 devbranch = "langdale"
 ltsseries = ["kirkstone", "dunfell"]
 
-# used by run-docs-builds to get the default page
-if ourversion == "getlatest":
-    print(activereleases[0])
-    sys.exit(0)
-
 release_series = collections.OrderedDict()
 release_series["langdale"] = "4.1"
 release_series["kirkstone"] = "4.0"
@@ -211,7 +206,7 @@ with open("sphinx-static/switchers.js.in", "r") as r, open("sphinx-static/switch
             w.write(str(list(release_series.keys())))
             continue
         if "VERSIONS_PLACEHOLDER" in line:
-            w.write("    'dev': { 'title': 'Unstable (dev)', 'obsolete': false,},\n")
+            w.write("    'dev': { 'title': 'dev (%s)', 'obsolete': false,},\n" % release_series[devbranch])
             for branch in activereleases + ([ourseries] if ourseries not in activereleases else []):
                 if branch == devbranch:
                     continue
@@ -223,9 +218,9 @@ with open("sphinx-static/switchers.js.in", "r") as r, open("sphinx-static/switch
                 if branch_versions[-1] != "0":
                     version = version + "." + branch_versions[-1]
                 versions.append(version)
-                w.write("    '%s': {'title': '%s (%s)', 'obsolete': %s,},\n" % (version, branch.capitalize(), version, str(branch not in activereleases).lower()))
+                w.write("    '%s': {'title': '%s', 'obsolete': %s,},\n" % (version, version, str(branch not in activereleases).lower()))
             if ourversion not in versions and ourseries != devbranch:
-                w.write("    '%s': {'title': '%s (%s)', 'obsolete': %s,},\n" % (ourversion, ourseries.capitalize(), ourversion, str(ourseries not in activereleases).lower()))
+                w.write("    '%s': {'title': '%s', 'obsolete': %s,},\n" % (ourversion, ourversion, str(ourseries not in activereleases).lower()))
         else:
             w.write(line)
 

documentation/sphinx/yocto-vars.py

@@ -13,7 +13,7 @@ try:
     import yaml
 except ImportError:
     sys.stderr.write("The Yocto Project Sphinx documentation requires PyYAML.\
-    \nPlease make sure to install pyyaml Python package.\n")
+    \nPlease make sure to install pyyaml python package.\n")
     sys.exit(1)
 
 __version__  = '1.0'

documentation/standards.md

@@ -7,29 +7,7 @@ It is currently a work in progress.
 
 ## Text standards
 
-### Project names
-
-Project names should be capitalized in the same
-way they are on Wikipedia, in particular:
-
-* BitBake
-* OpenEmbedded
-
-There are exceptions in which such names can be used
-in lower case:
-
-* When referring to a package name
-* When referring to the corresponding command name
-* When used in a cross-reference title. Such
-  titles are usually in lower case.
-
-### File names
-
-File names should be quoted as in the below example:
-
-     ``conf/local.conf``
-
-Using "conf/local/conf" would be wrong.
+This section has not been filled yet
 
 ## ReStructured Text Syntax standards
 
@@ -48,14 +26,8 @@ To include a screenshot in PNG format:
     .. image:: figures/user-configuration.png
        :align: center
 
-A diagram with many details usually needs to use
-the whole page width to be readable on all media.
-In this case, the `:align:` directive is unnecessary:
-
-       :scale: 100%
-
-Conversely, you may also shrink some images to
-to prevent them from filling the whole page width:
+Depending on the size of the image, you may also shrink it
+to prevent it from filling the whole page width:
 
        :scale: 50%
 

documentation/test-manual/intro.rst

@@ -72,7 +72,7 @@ simple JSON files.
 .. note::
 
    The project uses Buildbot for historical reasons but also because
-   many of the project developers have knowledge of Python. It is
+   many of the project developers have knowledge of python. It is
    possible to use the outer layers from another Continuous Integration
    (CI) system such as
    `Jenkins <https://en.wikipedia.org/wiki/Jenkins_(software)>`__
@@ -83,7 +83,6 @@ topology that includes a controller and a cluster of workers:
 
 .. image:: figures/ab-test-cluster.png
    :align: center
-   :width: 70%
 
 Yocto Project Tests - Types of Testing Overview
 ===============================================
@@ -175,26 +174,20 @@ Tests map into the codebase as follows:
    which include the fetchers. The tests are located in
    ``bitbake/lib/*/tests``.
 
-   Some of these tests run the ``bitbake`` command, so ``bitbake/bin``
-   must be added to the ``PATH`` before running ``bitbake-selftest``.
    From within the BitBake repository, run the following::
 
-      $ export PATH=$PWD/bin:$PATH
-
-   After that, you can run the selftest script::
-
       $ bitbake-selftest
 
-   The default output is quiet and just prints a summary of what was
-   run. To see more information, there is a verbose option::
-
-      $ bitbake-selftest -v
-
    To skip tests that access the Internet, use the ``BB_SKIP_NETTESTS``
    variable when running "bitbake-selftest" as follows::
 
       $ BB_SKIP_NETTESTS=yes bitbake-selftest
 
+   The default output is quiet and just prints a summary of what was
+   run. To see more information, there is a verbose option::
+
+      $ bitbake-selftest -v
+
    Use this option when you wish to skip tests that access the network,
    which are mostly necessary to test the fetcher modules. To specify
    individual test modules to run, append the test module name to the
@@ -342,12 +335,12 @@ A simple test example from ``lib/bb/tests/data.py`` is::
             self.assertEqual(str(val), "value_of_foo")
 
 In this example, a ``DataExpansions`` class of tests is created,
-derived from standard Python unittest. The class has a common ``setUp``
+derived from standard python unittest. The class has a common ``setUp``
 function which is shared by all the tests in the class. A simple test is
 then added to test that when a variable is expanded, the correct value
 is found.
 
-BitBake selftests are straightforward Python unittest. Refer to the
+Bitbake selftests are straightforward python unittest. Refer to the
 Python unittest documentation for additional information on writing
 these tests at: https://docs.python.org/3/library/unittest.html.
 
@@ -475,7 +468,7 @@ following::
 
 In this example, if nativesdk-python3-core has been installed into the SDK, the code runs
 the python3 interpreter with a basic command to check it is working
-correctly. The test would only run if Python3 is installed in the SDK.
+correctly. The test would only run if python3 is installed in the SDK.
 
 ``oe-build-perf-test``
 ----------------------

documentation/toaster-manual/intro.rst

@@ -92,7 +92,6 @@ suited for a single user developing on a single build host.
 
 .. image:: figures/simple-configuration.png
    :align: center
-   :width: 70%
 
 Toaster as a hosted service is suited for multiple users developing
 across several build hosts. When Toaster is set up as a hosted service,
@@ -100,4 +99,3 @@ its components can be spread across several machines:
 
 .. image:: figures/hosted-service.png
    :align: center
-   :width: 50%

documentation/toaster-manual/setup-and-use.rst

@@ -311,7 +311,7 @@ Perform the following steps to install Toaster:
     migrations). The next line sets the Toaster root directory
     ``TOASTER_DIR`` and the location of the Toaster configuration file
     ``TOASTER_CONF``, which is relative to ``TOASTER_DIR``. The
-    :term:`TEMPLATECONF` value reflects the contents of
+    ``TEMPLATECONF`` value reflects the contents of
     ``poky/.templateconf``, and by default, should include the string
     "poky". For more information on the Toaster configuration file, see
     the ":ref:`toaster-manual/reference:Configuring Toaster`" section.

documentation/toaster-manual/start.rst

@@ -40,7 +40,7 @@ command::
    $ pip3 install --user -r bitbake/toaster-requirements.txt
 
 The previous command installs the necessary Toaster modules into a local
-Python 3 cache in your ``$HOME`` directory. The caches is actually
+python 3 cache in your ``$HOME`` directory. The caches is actually
 located in ``$HOME/.local``. To see what packages have been installed
 into your ``$HOME`` directory, do the following::
 

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

@@ -28,9 +28,9 @@ Transitioning to a custom environment for systems development
    for you to get comfortable with project concepts.
 
 #. **Find and acquire the best BSP for your target**.
-   Use the :yocto_home:`Yocto Project Compatible Layers
+   Use the :yocto_home:`Yocto Project curated layer index
    </software-overview/layers/>` or even the :oe_layerindex:`OpenEmbedded
-   Layer Index <>` to find and acquire the best BSP for your
+   layer index <>` to find and acquire the best BSP for your
    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

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

@@ -98,7 +98,6 @@ contact us with other suggestions.
    be going wrong.
 
    .. image:: figures/yp-how-it-works-new-diagram.png
-      :width: 100%
 
 #. **Know that you can generate a dependency graph and learn how to do it:**
    A dependency graph shows dependencies between recipes, tasks, and targets.
@@ -180,7 +179,7 @@ contact us with other suggestions.
    * understand devtool and how it simplifies your workflow
    * improve build speeds with shared downloads and shared state cache
    * generate and understand a dependency graph
-   * generate and understand BitBake environment
+   * generate and understand bitbake environment
    * build an Extensible SDK for applications development
 
 #. **Depending on what you primary interests are with the Yocto Project, you

meta-poky/conf/conf-notes.txt

@@ -11,7 +11,7 @@ Common targets are:
     meta-toolchain
     meta-ide-support
 
-You can also run generated qemu images with a command like 'runqemu qemux86-64'.
+You can also run generated qemu images with a command like 'runqemu qemux86'
 
 Other commonly useful commands are:
  - 'devtool' and 'recipetool' handle common recipe tasks

meta-poky/conf/distro/poky-altcfg.conf

@@ -8,8 +8,8 @@ DISTRO = "poky-altcfg"
 DISTROOVERRIDES = "poky:poky-altcfg"
 #DISTROOVERRIDES = "poky:linuxstdbase"
 
-INIT_MANAGER:poky-altcfg = "systemd"
+INIT_MANAGER ?= "systemd"
 # systemd isn't suitable with musl
-INIT_MANAGER:poky-altcfg:libc-musl = "sysvinit"
+INIT_MANAGER:libc-musl ?= "sysvinit"
 
 require conf/distro/include/poky-distro-alt-test-config.inc

meta-poky/conf/distro/poky-tiny.conf

@@ -32,7 +32,6 @@ require conf/distro/poky.conf
 require conf/distro/include/gcsections.inc
 
 DISTRO = "poky-tiny"
-DISTRO_NAME = "Poky Tiny"
 DISTROOVERRIDES = "poky:poky-tiny"
 TCLIBC = "musl"
 
@@ -63,8 +62,6 @@ ENABLE_WIDEC:class-native = "true"
 # Drop native language support. This removes the
 # eglibc->bash->gettext->libc-posix-clang-wchar dependency.
 USE_NLS="no"
-# As we don't have native language support, don't install locales into images
-IMAGE_LINGUAS = ""
 
 # Comment out any of the lines below to disable them in the build
 # DISTRO_FEATURES options:
@@ -89,7 +86,7 @@ DISTRO_FEATURES:class-native = "${DISTRO_FEATURES_DEFAULT} ${POKY_DEFAULT_DISTRO
 DISTRO_FEATURES:class-nativesdk = "${DISTRO_FEATURES_DEFAULT} ${POKY_DEFAULT_DISTRO_FEATURES}"
 
 # enable mdev/busybox for init
-INIT_MANAGER:poky-tiny = "mdev-busybox"
+INIT_MANAGER ?= "mdev-busybox"
 
 # FIXME: Consider adding "modules" to MACHINE_FEATURES and using that in
 # packagegroup-core-base to select modutils-initscripts or not.  Similar with "net" and

meta-poky/conf/distro/poky.conf

@@ -1,7 +1,8 @@
 DISTRO = "poky"
 DISTRO_NAME = "Poky (Yocto Project Reference Distro)"
-DISTRO_VERSION = "4.1+snapshot-${METADATA_REVISION}"
-DISTRO_CODENAME = "langdale"
+#DISTRO_VERSION = "3.4+snapshot-${METADATA_REVISION}"
+DISTRO_VERSION = "4.0.6"
+DISTRO_CODENAME = "kirkstone"
 SDK_VENDOR = "-pokysdk"
 SDK_VERSION = "${@d.getVar('DISTRO_VERSION').replace('snapshot-${METADATA_REVISION}', 'snapshot')}"
 SDK_VERSION[vardepvalue] = "${SDK_VERSION}"
@@ -30,8 +31,6 @@ DISTRO_EXTRA_RRECOMMENDS += "${POKY_DEFAULT_EXTRA_RRECOMMENDS}"
 
 TCLIBCAPPEND = ""
 
-PACKAGE_CLASSES ?= "package_rpm"
-
 SANITY_TESTED_DISTROS ?= " \
             poky-3.3 \n \
             poky-3.4 \n \
@@ -39,6 +38,7 @@ SANITY_TESTED_DISTROS ?= " \
             ubuntu-18.04 \n \
             ubuntu-20.04 \n \
             ubuntu-21.10 \n \
+            ubuntu-22.04 \n \
             fedora-34 \n \
             fedora-35 \n \
             centos-7 \n \
@@ -66,5 +66,3 @@ INHERIT += "uninative"
 
 BB_SIGNATURE_HANDLER ?= "OEEquivHash"
 BB_HASHSERVE ??= "auto"
-
-INIT_MANAGER = "sysvinit"