build-appliance-image: Update to master head revision

(From OE-Core rev: b4f1b78aef77198f26a8ef9e105fa690cc12e836)

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

MAINTAINERS.md

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

bitbake/bin/bitbake

@@ -28,7 +28,7 @@ from bb.main import bitbake_main, BitBakeConfigParameters, BBMainException
 if sys.getfilesystemencoding() != "utf-8":
     sys.exit("Please use a locale setting which supports UTF-8 (such as LANG=en_US.UTF-8).\nPython can't change the filesystem locale after loading so we need a UTF-8 when Python starts or things won't work.")
 
-__version__ = "2.0.0"
+__version__ = "2.0.1"
 
 if __name__ == "__main__":
     if __version__ != bb.__version__:

bitbake/bin/bitbake-diffsigs

@@ -11,6 +11,7 @@
 import os
 import sys
 import warnings
+
 warnings.simplefilter("default")
 import argparse
 import logging
@@ -27,6 +28,7 @@ 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',
@@ -52,6 +54,7 @@ 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 """
 
@@ -63,10 +66,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 not sig1 in sigfiles:
+        elif sig1 not in sigfiles:
             logger.error('No sigdata files found matching %s %s with signature %s' % (pn, taskname, sig1))
             sys.exit(1)
-        elif not sig2 in sigfiles:
+        elif sig2 not 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]]
@@ -88,9 +91,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 not hash1 in hashfiles:
+    elif hash1 not in hashfiles:
         recout.append("Unable to find matching sigdata for %s with hash %s" % (key, hash1))
-    elif not hash2 in hashfiles:
+    elif hash2 not 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)
@@ -110,36 +113,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:
@@ -157,7 +160,8 @@ 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])
 
@@ -166,7 +170,8 @@ 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/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;OptionA=xxx;OptionB=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;OptionA=xxx;OptionB=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/__init__.py

@@ -9,7 +9,7 @@
 # SPDX-License-Identifier: GPL-2.0-only
 #
 
-__version__ = "2.0.0"
+__version__ = "2.0.1"
 
 import sys
 if sys.version_info < (3, 6, 0):

bitbake/lib/bb/build.py

@@ -835,11 +835,7 @@ def stamp_cleanmask_internal(taskname, d, file_name):
 
     return [cleanmask, cleanmask.replace(taskflagname, taskflagname + "_setscene")]
 
-def make_stamp(task, d, file_name = None):
-    """
-    Creates/updates a stamp for a given task
-    (d can be a data dict or dataCache)
-    """
+def clean_stamp(task, d, file_name = None):
     cleanmask = stamp_cleanmask_internal(task, d, file_name)
     for mask in cleanmask:
         for name in glob.glob(mask):
@@ -850,6 +846,14 @@ def make_stamp(task, d, file_name = None):
             if name.endswith('.taint'):
                 continue
             os.unlink(name)
+    return
+
+def make_stamp(task, d, file_name = None):
+    """
+    Creates/updates a stamp for a given task
+    (d can be a data dict or dataCache)
+    """
+    clean_stamp(task, d, file_name)
 
     stamp = stamp_internal(task, d, file_name)
     # Remove the file and recreate to force timestamp

bitbake/lib/bb/cache.py

@@ -24,6 +24,7 @@ from collections.abc import Mapping
 import bb.utils
 from bb import PrefixLoggerAdapter
 import re
+import shutil
 
 logger = logging.getLogger("BitBake.Cache")
 
@@ -619,7 +620,7 @@ class Cache(NoCache):
                 for f in flist:
                     if not f:
                         continue
-                    f, exist = f.split(":")
+                    f, exist = f.rsplit(":", 1)
                     if (exist == "True" and not os.path.exists(f)) or (exist == "False" and os.path.exists(f)):
                         self.logger.debug2("%s's file checksum list file %s changed",
                                              fn, f)
@@ -998,3 +999,11 @@ class SimpleCache(object):
             p.dump([data, self.cacheversion])
 
         bb.utils.unlockfile(glf)
+
+    def copyfile(self, target):
+        if not self.cachefile:
+            return
+
+        glf = bb.utils.lockfile(self.cachefile + ".lock")
+        shutil.copy(self.cachefile, target)
+        bb.utils.unlockfile(glf)

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
@@ -744,19 +743,18 @@ class BBCooker:
                     taskdata[mc].add_unresolved(localdata[mc], self.recipecaches[mc])
                     mcdeps |= set(taskdata[mc].get_mcdepends())
                 new = False
-                for mc in self.multiconfigs:
-                    for k in mcdeps:
-                        if k in seen:
-                            continue
-                        l = k.split(':')
-                        depmc = l[2]
-                        if depmc not in self.multiconfigs:
-                            bb.fatal("Multiconfig dependency %s depends on nonexistent multiconfig configuration named configuration %s" % (k,depmc))
-                        else:
-                            logger.debug("Adding providers for multiconfig dependency %s" % l[3])
-                            taskdata[depmc].add_provider(localdata[depmc], self.recipecaches[depmc], l[3])
-                            seen.add(k)
-                            new = True
+                for k in mcdeps:
+                    if k in seen:
+                        continue
+                    l = k.split(':')
+                    depmc = l[2]
+                    if depmc not in self.multiconfigs:
+                        bb.fatal("Multiconfig dependency %s depends on nonexistent multiconfig configuration named configuration %s" % (k,depmc))
+                    else:
+                        logger.debug("Adding providers for multiconfig dependency %s" % l[3])
+                        taskdata[depmc].add_provider(localdata[depmc], self.recipecaches[depmc], l[3])
+                        seen.add(k)
+                        new = True
 
         for mc in self.multiconfigs:
             taskdata[mc].add_unresolved(localdata[mc], self.recipecaches[mc])
@@ -1908,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
@@ -1916,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('Variable %s from the shell environment has been renamed to %s' % (k, bb.data_smart.bitbake_renamed_vars[k]))
+                bb.error('Shell environment variable %s 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/data.py

@@ -277,6 +277,8 @@ def build_dependencies(key, keys, shelldeps, varflagsexcl, ignored_vars, d):
     try:
         if key[-1] == ']':
             vf = key[:-1].split('[')
+            if vf[1] == "vardepvalueexclude":
+                return deps, ""
             value, parser = d.getVarFlag(vf[0], vf[1], False, retparser=True)
             deps |= parser.references
             deps = deps | (keys & parser.execs)

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/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)
@@ -1220,23 +1222,21 @@ def get_checksum_file_list(d):
     SRC_URI as a space-separated string
     """
     fetch = Fetch([], d, cache = False, localonly = True)
-
-    dl_dir = d.getVar('DL_DIR')
     filelist = []
     for u in fetch.urls:
         ud = fetch.ud[u]
-
         if ud and isinstance(ud.method, local.Local):
+            found = False
             paths = ud.method.localpaths(ud, d)
             for f in paths:
                 pth = ud.decodedurl
-                if f.startswith(dl_dir):
-                    # The local fetcher's behaviour is to return a path under DL_DIR if it couldn't find the file anywhere else
-                    if os.path.exists(f):
-                        bb.warn("Getting checksum for %s SRC_URI entry %s: file not found except in DL_DIR" % (d.getVar('PN'), os.path.basename(f)))
-                    else:
-                        bb.warn("Unable to get checksum for %s SRC_URI entry %s: file could not be found" % (d.getVar('PN'), os.path.basename(f)))
+                if os.path.exists(f):
+                    found = True
                 filelist.append(f + ":" + str(os.path.exists(f)))
+            if not found:
+                bb.fatal(("Unable to get checksum for %s SRC_URI entry %s: file could not be found"
+                            "\nThe following paths were searched:"
+                            "\n%s") % (d.getVar('PN'), os.path.basename(f), '\n'.join(paths)))
 
     return " ".join(filelist)
 

bitbake/lib/bb/fetch2/crate.py

@@ -13,7 +13,6 @@ BitBake 'Fetch' implementation for crates.io
 import hashlib
 import json
 import os
-import shutil
 import subprocess
 import bb
 from   bb.fetch2 import logger, subprocess_setup, UnpackError

bitbake/lib/bb/fetch2/git.py

@@ -74,6 +74,9 @@ 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):
@@ -240,7 +243,7 @@ class Git(FetchMethod):
             for name in ud.names:
                 ud.unresolvedrev[name] = 'HEAD'
 
-        ud.basecmd = d.getVar("FETCHCMD_git") or "git -c core.fsyncobjectfiles=0 -c gc.autoDetach=false"
+        ud.basecmd = d.getVar("FETCHCMD_git") or "git -c core.fsyncobjectfiles=0 -c gc.autoDetach=false -c core.pager=cat"
 
         write_tarballs = d.getVar("BB_GENERATE_MIRROR_TARBALLS") or "0"
         ud.write_tarballs = write_tarballs != "0" or ud.rebaseable
@@ -249,8 +252,8 @@ class Git(FetchMethod):
         ud.setup_revisions(d)
 
         for name in ud.names:
-            # 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]]):
+            # Ensure any revision that doesn't look like a SHA-1 is translated into one
+            if not sha1_re.match(ud.revisions[name] or ''):
                 if ud.revisions[name]:
                     ud.unresolvedrev[name] = ud.revisions[name]
                 ud.revisions[name] = self.latest_revision(ud, d, name)
@@ -259,10 +262,10 @@ class Git(FetchMethod):
         if gitsrcname.startswith('.'):
             gitsrcname = gitsrcname[1:]
 
-        # for rebaseable git repo, it is necessary to keep mirror tar ball
-        # per revision, so that even the revision disappears from the
+        # 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
         # upstream repo in the future, the mirror will remain intact and still
-        # contains the revision
+        # contain the revision
         if ud.rebaseable:
             for name in ud.names:
                 gitsrcname = gitsrcname + '_' + ud.revisions[name]
@@ -350,10 +353,15 @@ class Git(FetchMethod):
         if ud.shallow and os.path.exists(ud.fullshallow) and self.need_update(ud, d):
             ud.localpath = ud.fullshallow
             return
-        elif os.path.exists(ud.fullmirror) and not os.path.exists(ud.clonedir):
-            bb.utils.mkdirhier(ud.clonedir)
-            runfetchcmd("tar -xzf %s" % ud.fullmirror, d, workdir=ud.clonedir)
-
+        elif os.path.exists(ud.fullmirror) and self.need_update(ud, d):
+            if not os.path.exists(ud.clonedir):
+                bb.utils.mkdirhier(ud.clonedir)
+                runfetchcmd("tar -xzf %s" % ud.fullmirror, d, workdir=ud.clonedir)
+            else:
+                tmpdir = tempfile.mkdtemp(dir=d.getVar('DL_DIR'))
+                runfetchcmd("tar -xzf %s" % ud.fullmirror, d, workdir=tmpdir)
+                fetch_cmd = "LANG=C %s fetch -f --progress %s " % (ud.basecmd, shlex.quote(tmpdir))
+                runfetchcmd(fetch_cmd, d, workdir=ud.clonedir)
         repourl = self._get_repo_url(ud)
 
         # If the repo still doesn't exist, fallback to cloning it
@@ -697,7 +705,6 @@ 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):
@@ -731,7 +738,7 @@ class Git(FetchMethod):
         Compute the HEAD revision for the url
         """
         if not d.getVar("__BBSEENSRCREV"):
-            raise bb.fetch2.FetchError("Recipe uses a floating tag/branch without a fixed SRCREV yet doesn't call bb.fetch2.get_srcrev() (use SRCPV in PV for OE).")
+            raise bb.fetch2.FetchError("Recipe uses a floating tag/branch '%s' for repo '%s' without a fixed SRCREV yet doesn't call bb.fetch2.get_srcrev() (use SRCPV in PV for OE)." % (ud.unresolvedrev[name], ud.host+ud.path))
 
         # Ensure we mark as not cached
         bb.fetch2.get_autorev(d)

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)

bitbake/lib/bb/fetch2/local.py

@@ -57,12 +57,6 @@ class Local(FetchMethod):
             logger.debug2("Searching for %s in paths:\n    %s" % (path, "\n    ".join(filespath.split(":"))))
             newpath, hist = bb.utils.which(filespath, path, history=True)
             searched.extend(hist)
-        if not os.path.exists(newpath):
-            dldirfile = os.path.join(d.getVar("DL_DIR"), path)
-            logger.debug2("Defaulting to %s for %s" % (dldirfile, path))
-            bb.utils.mkdirhier(os.path.dirname(dldirfile))
-            searched.append(dldirfile)
-            return searched
         return searched
 
     def need_update(self, ud, d):
@@ -78,8 +72,6 @@ class Local(FetchMethod):
             filespath = d.getVar('FILESPATH')
             if filespath:
                 locations = filespath.split(":")
-            locations.append(d.getVar("DL_DIR"))
-
             msg = "Unable to find file " + urldata.url + " anywhere. The paths that were searched were:\n    " + "\n    ".join(locations)
             raise FetchError(msg)
 

bitbake/lib/bb/fetch2/osc.py

@@ -9,6 +9,7 @@ Based on the svn "Fetch" implementation.
 
 import logging
 import os
+import re
 import  bb
 from    bb.fetch2 import FetchMethod
 from    bb.fetch2 import FetchError
@@ -36,6 +37,7 @@ class Osc(FetchMethod):
         # Create paths to osc checkouts
         oscdir = d.getVar("OSCDIR") or (d.getVar("DL_DIR") + "/osc")
         relpath = self._strip_leading_slashes(ud.path)
+        ud.oscdir = oscdir
         ud.pkgdir = os.path.join(oscdir, ud.host)
         ud.moddir = os.path.join(ud.pkgdir, relpath, ud.module)
 
@@ -43,13 +45,13 @@ class Osc(FetchMethod):
             ud.revision = ud.parm['rev']
         else:
             pv = d.getVar("PV", False)
-            rev = bb.fetch2.srcrev_internal_helper(ud, d)
+            rev = bb.fetch2.srcrev_internal_helper(ud, d, '')
             if rev:
                 ud.revision = rev
             else:
                 ud.revision = ""
 
-        ud.localfile = d.expand('%s_%s_%s.tar.gz' % (ud.module.replace('/', '.'), ud.path.replace('/', '.'), ud.revision))
+        ud.localfile = d.expand('%s_%s_%s.tar.gz' % (ud.module.replace('/', '.'), relpath.replace('/', '.'), ud.revision))
 
     def _buildosccommand(self, ud, d, command):
         """
@@ -59,26 +61,49 @@ class Osc(FetchMethod):
 
         basecmd = d.getVar("FETCHCMD_osc") or "/usr/bin/env osc"
 
-        proto = ud.parm.get('protocol', 'ocs')
+        proto = ud.parm.get('protocol', 'https')
 
         options = []
 
         config = "-c %s" % self.generate_config(ud, d)
 
-        if ud.revision:
+        if getattr(ud, 'revision', ''):
             options.append("-r %s" % ud.revision)
 
         coroot = self._strip_leading_slashes(ud.path)
 
         if command == "fetch":
-            osccmd = "%s %s co %s/%s %s" % (basecmd, config, coroot, ud.module, " ".join(options))
+            osccmd = "%s %s -A %s://%s co %s/%s %s" % (basecmd, config, proto, ud.host, coroot, ud.module, " ".join(options))
         elif command == "update":
-            osccmd = "%s %s up %s" % (basecmd, config, " ".join(options))
+            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)
         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
@@ -86,7 +111,7 @@ class Osc(FetchMethod):
 
         logger.debug2("Fetch: checking for module directory '" + ud.moddir + "'")
 
-        if os.access(os.path.join(d.getVar('OSCDIR'), ud.path, ud.module), os.R_OK):
+        if os.access(ud.moddir, os.R_OK):
             oscupdatecmd = self._buildosccommand(ud, d, "update")
             logger.info("Update "+ ud.url)
             # update sources there
@@ -114,20 +139,23 @@ class Osc(FetchMethod):
         Generate a .oscrc to be used for this run.
         """
 
-        config_path = os.path.join(d.getVar('OSCDIR'), "oscrc")
+        config_path = os.path.join(ud.oscdir, "oscrc")
+        if not os.path.exists(ud.oscdir):
+            bb.utils.mkdirhier(ud.oscdir)
+
         if (os.path.exists(config_path)):
             os.remove(config_path)
 
         f = open(config_path, 'w')
+        proto = ud.parm.get('protocol', 'https')
         f.write("[general]\n")
-        f.write("apisrv = %s\n" % ud.host)
-        f.write("scheme = http\n")
+        f.write("apiurl = %s://%s\n" % (proto, ud.host))
         f.write("su-wrapper = su -c\n")
         f.write("build-root = %s\n" % d.getVar('WORKDIR'))
         f.write("urllist = %s\n" % d.getVar("OSCURLLIST"))
         f.write("extra-pkgs = gzip\n")
         f.write("\n")
-        f.write("[%s]\n" % ud.host)
+        f.write("[%s://%s]\n" % (proto, ud.host))
         f.write("user = %s\n" % ud.parm["user"])
         f.write("pass = %s\n" % ud.parm["pswd"])
         f.close()

bitbake/lib/bb/fetch2/ssh.py

@@ -32,6 +32,7 @@ IETF secsh internet draft:
 
 import re, os
 from bb.fetch2 import check_network_access, FetchMethod, ParameterError, runfetchcmd
+import urllib
 
 
 __pattern__ = re.compile(r'''
@@ -70,6 +71,7 @@ class SSH(FetchMethod):
                 "git:// prefix with protocol=ssh", urldata.url)
         m = __pattern__.match(urldata.url)
         path = m.group('path')
+        path = urllib.parse.unquote(path)
         host = m.group('host')
         urldata.localpath = os.path.join(d.getVar('DL_DIR'),
                 os.path.basename(os.path.normpath(path)))
@@ -99,7 +101,7 @@ class SSH(FetchMethod):
 
         if path[0] != '~':
             path = '/%s' % path
-        path = path.replace("%3A", ":")
+        path = urllib.parse.unquote(path)
 
         fr += ':%s' % path
 
@@ -139,7 +141,7 @@ class SSH(FetchMethod):
 
         if path[0] != '~':
             path = '/%s' % path
-        path = path.replace("%3A", ":")
+        path = urllib.parse.unquote(path)
 
         cmd = 'ssh -o BatchMode=true %s %s [ -f %s ]' % (
             portarg,

bitbake/lib/bb/fetch2/wget.py

@@ -106,10 +106,9 @@ class Wget(FetchMethod):
 
         fetchcmd = self.basecmd
 
-        if 'downloadfilename' in ud.parm:
-            localpath = os.path.join(d.getVar("DL_DIR"), ud.localfile)
-            bb.utils.mkdirhier(os.path.dirname(localpath))
-            fetchcmd += " -O %s" % shlex.quote(localpath)
+        localpath = os.path.join(d.getVar("DL_DIR"), ud.localfile) + ".tmp"
+        bb.utils.mkdirhier(os.path.dirname(localpath))
+        fetchcmd += " -O %s" % shlex.quote(localpath)
 
         if ud.user and ud.pswd:
             fetchcmd += " --auth-no-challenge"
@@ -133,6 +132,10 @@ class Wget(FetchMethod):
 
         self._runwget(ud, d, fetchcmd, False)
 
+        # Remove the ".tmp" and move the file into position atomically
+        # Our lock prevents multiple writers but mirroring code may grab incomplete files
+        os.rename(localpath, localpath[:-4])
+
         # Sanity check since wget can pretend it succeed when it didn't
         # Also, this used to happen if sourceforge sent us to the mirror page
         if not os.path.exists(ud.localpath):

bitbake/lib/bb/msg.py

@@ -133,7 +133,6 @@ class LogFilterShowOnce(logging.Filter):
         self.seen_errors = set()
 
     def filter(self, record):
-        msg = record.msg
         if record.levelno == bb.msg.BBLogFormatter.WARNONCE:
             if record.msg in self.seen_warnings:
                 return False

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/persist_data.py

@@ -208,7 +208,7 @@ class SQLTable(collections.abc.MutableMapping):
 
     def __lt__(self, other):
         if not isinstance(other, Mapping):
-            raise NotImplemented
+            raise NotImplementedError()
 
         return len(self) < len(other)
 

bitbake/lib/bb/providers.py

@@ -396,8 +396,8 @@ def getRuntimeProviders(dataCache, rdepend):
         return rproviders
 
     # Only search dynamic packages if we can't find anything in other variables
-    for pattern in dataCache.packages_dynamic:
-        pattern = pattern.replace(r'+', r"\+")
+    for pat_key in dataCache.packages_dynamic:
+        pattern = pat_key.replace(r'+', r"\+")
         if pattern in regexp_cache:
             regexp = regexp_cache[pattern]
         else:
@@ -408,7 +408,7 @@ def getRuntimeProviders(dataCache, rdepend):
                 raise
             regexp_cache[pattern] = regexp
         if regexp.match(rdepend):
-            rproviders += dataCache.packages_dynamic[pattern]
+            rproviders += dataCache.packages_dynamic[pat_key]
             logger.debug("Assuming %s is a dynamic package, but it may not exist" % rdepend)
 
     return rproviders

bitbake/lib/bb/runqueue.py

@@ -1674,7 +1674,7 @@ class RunQueue:
             (mc, fn, taskname, taskfn) = split_tid_mcfn(tid)
             pn = self.rqdata.dataCaches[mc].pkg_fn[taskfn]
             h = self.rqdata.runtaskentries[tid].hash
-            matches = bb.siggen.find_siginfo(pn, taskname, [], self.cfgData)
+            matches = bb.siggen.find_siginfo(pn, taskname, [], self.cooker.databuilder.mcdata[mc])
             match = None
             for m in matches:
                 if h in m:
@@ -2299,6 +2299,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()
@@ -2664,7 +2667,6 @@ def build_scenequeue_data(sqdata, rqdata, rq, cooker, stampcache, sqrq):
             sq_revdeps_squash[point] = set()
             if point in rqdata.runq_setscene_tids:
                 sq_revdeps_squash[point] = tasks
-                tasks = set()
                 continue
             for dep in rqdata.runtaskentries[point].depends:
                 if point in sq_revdeps[dep]:

bitbake/lib/bb/server/process.py

@@ -20,7 +20,6 @@ import os
 import sys
 import time
 import select
-import signal
 import socket
 import subprocess
 import errno
@@ -438,6 +437,7 @@ class BitBakeProcessServerConnection(object):
         self.socket_connection = sock
 
     def terminate(self):
+        self.events.close()
         self.socket_connection.close()
         self.connection.connection.close()
         self.connection.recv.close()
@@ -663,23 +663,18 @@ class BBUIEventQueue:
         self.reader = ConnectionReader(readfd)
 
         self.t = threading.Thread()
-        self.t.daemon = True
         self.t.run = self.startCallbackHandler
         self.t.start()
 
     def getEvent(self):
-        self.eventQueueLock.acquire()
+        with self.eventQueueLock:
+            if len(self.eventQueue) == 0:
+                return None
 
-        if len(self.eventQueue) == 0:
-            self.eventQueueLock.release()
-            return None
+            item = self.eventQueue.pop(0)
+            if len(self.eventQueue) == 0:
+                self.eventQueueNotify.clear()
 
-        item = self.eventQueue.pop(0)
-
-        if len(self.eventQueue) == 0:
-            self.eventQueueNotify.clear()
-
-        self.eventQueueLock.release()
         return item
 
     def waitEvent(self, delay):
@@ -687,10 +682,9 @@ class BBUIEventQueue:
         return self.getEvent()
 
     def queue_event(self, event):
-        self.eventQueueLock.acquire()
-        self.eventQueue.append(event)
-        self.eventQueueNotify.set()
-        self.eventQueueLock.release()
+        with self.eventQueueLock:
+            self.eventQueue.append(event)
+            self.eventQueueNotify.set()
 
     def send_event(self, event):
         self.queue_event(pickle.loads(event))
@@ -699,13 +693,17 @@ class BBUIEventQueue:
         bb.utils.set_process_name("UIEventQueue")
         while True:
             try:
-                self.reader.wait()
-                event = self.reader.get()
-                self.queue_event(event)
-            except EOFError:
+                ready = self.reader.wait(0.25)
+                if ready:
+                    event = self.reader.get()
+                    self.queue_event(event)
+            except (EOFError, OSError, TypeError):
                 # Easiest way to exit is to close the file descriptor to cause an exit
                 break
+
+    def close(self):
         self.reader.close()
+        self.t.join()
 
 class ConnectionReader(object):
 
@@ -758,8 +756,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

@@ -40,7 +40,6 @@ def init(d):
     for sg in siggens:
         if desired == sg.name:
             return sg(d)
-            break
     else:
         logger.error("Invalid signature generator '%s', using default 'noop'\n"
                      "Available generators: %s", desired,
@@ -121,6 +120,9 @@ class SignatureGenerator(object):
     def save_unitaskhashes(self):
         return
 
+    def copy_unitaskhashes(self, targetdir):
+        return
+
     def set_setscene_tasks(self, setscene_tasks):
         return
 
@@ -359,6 +361,9 @@ class SignatureGeneratorBasic(SignatureGenerator):
     def save_unitaskhashes(self):
         self.unihash_cache.save(self.unitaskhashes)
 
+    def copy_unitaskhashes(self, targetdir):
+        self.unihash_cache.copyfile(targetdir)
+
     def dump_sigtask(self, fn, task, stampbase, runtime):
 
         tid = fn + ":" + task
@@ -1027,6 +1032,7 @@ 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/fetch.py

@@ -468,6 +468,7 @@ class MirrorUriTest(FetcherTest):
                 "http://.*/.* file:///someotherpath/downloads/"
 
     def test_urireplace(self):
+        self.d.setVar("FILESPATH", ".")
         for k, v in self.replaceuris.items():
             ud = bb.fetch.FetchData(k[0], self.d)
             ud.setup_localpath(self.d)
@@ -693,6 +694,11 @@ class FetcherLocalTest(FetcherTest):
         flst.sort()
         return flst
 
+    def test_local_checksum_fails_no_file(self):
+        self.d.setVar("SRC_URI", "file://404")
+        with self.assertRaises(bb.BBHandledException):
+            bb.fetch.get_checksum_file_list(self.d)
+
     def test_local(self):
         tree = self.fetchUnpack(['file://a', 'file://dir/c'])
         self.assertEqual(tree, ['a', 'dir/c'])
@@ -920,6 +926,7 @@ class FetcherNetworkTest(FetcherTest):
 
     @skipIfNoNetwork()
     def test_fetch_file_mirror_of_mirror(self):
+        self.d.setVar("FILESPATH", ".")
         self.d.setVar("MIRRORS", "http://.*/.* file:///some1where/ file:///some1where/.* file://some2where/ file://some2where/.* https://downloads.yoctoproject.org/releases/bitbake")
         fetcher = bb.fetch.Fetch(["http://invalid.yoctoproject.org/releases/bitbake/bitbake-1.0.tar.gz"], self.d)
         os.mkdir(self.dldir + "/some2where")
@@ -2802,3 +2809,121 @@ class GitSharedTest(FetcherTest):
         fetcher.unpack(self.unpackdir)
         alt = os.path.join(self.unpackdir, 'git/.git/objects/info/alternates')
         self.assertFalse(os.path.exists(alt))
+
+
+class FetchPremirroronlyLocalTest(FetcherTest):
+
+    def setUp(self):
+        super(FetchPremirroronlyLocalTest, self).setUp()
+        self.mirrordir = os.path.join(self.tempdir, "mirrors")
+        os.mkdir(self.mirrordir)
+        self.reponame = "bitbake"
+        self.gitdir = os.path.join(self.tempdir, "git", self.reponame)
+        self.recipe_url = "git://git.fake.repo/bitbake"
+        self.d.setVar("BB_FETCH_PREMIRRORONLY", "1")
+        self.d.setVar("BB_NO_NETWORK", "1")
+        self.d.setVar("PREMIRRORS", self.recipe_url + " " + "file://{}".format(self.mirrordir) + " \n")
+
+    def make_git_repo(self):
+        self.mirrorname = "git2_git.fake.repo.bitbake.tar.gz"
+        recipeurl = "git:/git.fake.repo/bitbake"
+        os.makedirs(self.gitdir)
+        self.git("init", self.gitdir)
+        for i in range(0):
+            self.git_new_commit()
+        bb.process.run('tar -czvf {} .'.format(os.path.join(self.mirrordir, self.mirrorname)), cwd =  self.gitdir)
+
+    def git_new_commit(self):
+        import random
+        testfilename = "bibake-fetch.test"
+        os.unlink(os.path.join(self.mirrordir, self.mirrorname))
+        with open(os.path.join(self.gitdir, testfilename), "w") as testfile:
+            testfile.write("Useless random data {}".format(random.random()))
+        self.git("add {}".format(testfilename), self.gitdir)
+        self.git("commit -a -m \"This random commit {}. I'm useless.\"".format(random.random()), self.gitdir)
+        bb.process.run('tar -czvf {} .'.format(os.path.join(self.mirrordir, self.mirrorname)), cwd =  self.gitdir)
+        return self.git("rev-parse HEAD", self.gitdir).strip()
+
+    def test_mirror_commit_nonexistent(self):
+        self.make_git_repo()
+        self.d.setVar("SRCREV", "0"*40)
+        fetcher = bb.fetch.Fetch([self.recipe_url], self.d)
+        with self.assertRaises(bb.fetch2.NetworkAccess):
+            fetcher.download()
+
+    def test_mirror_commit_exists(self):
+        self.make_git_repo()
+        self.d.setVar("SRCREV", self.git_new_commit())
+        fetcher = bb.fetch.Fetch([self.recipe_url], self.d)
+        fetcher.download()
+        fetcher.unpack(self.unpackdir)
+
+    def test_mirror_tarball_nonexistent(self):
+        self.d.setVar("SRCREV", "0"*40)
+        fetcher = bb.fetch.Fetch([self.recipe_url], self.d)
+        with self.assertRaises(bb.fetch2.NetworkAccess):
+            fetcher.download()
+
+class FetchPremirroronlyNetworkTest(FetcherTest):
+
+    def setUp(self):
+        super(FetchPremirroronlyNetworkTest, self).setUp()
+        self.mirrordir = os.path.join(self.tempdir, "mirrors")
+        os.mkdir(self.mirrordir)
+        self.reponame = "fstests"
+        self.clonedir = os.path.join(self.tempdir, "git")
+        self.gitdir = os.path.join(self.tempdir, "git", "{}.git".format(self.reponame))
+        self.recipe_url = "git://git.yoctoproject.org/fstests"
+        self.d.setVar("BB_FETCH_PREMIRRORONLY", "1")
+        self.d.setVar("BB_NO_NETWORK", "0")
+        self.d.setVar("PREMIRRORS", self.recipe_url + " " + "file://{}".format(self.mirrordir) + " \n")
+
+    def make_git_repo(self):
+        import shutil
+        self.mirrorname = "git2_git.yoctoproject.org.fstests.tar.gz"
+        os.makedirs(self.clonedir)
+        self.git("clone --bare --shallow-since=\"01.01.2013\" {}".format(self.recipe_url), self.clonedir)
+        bb.process.run('tar -czvf {} .'.format(os.path.join(self.mirrordir, self.mirrorname)), cwd =  self.gitdir)
+        shutil.rmtree(self.clonedir)
+
+    @skipIfNoNetwork()
+    def test_mirror_tarball_updated(self):
+        self.make_git_repo()
+        ## Upstream commit is in the mirror
+        self.d.setVar("SRCREV", "49d65d53c2bf558ae6e9185af0f3af7b79d255ec")
+        fetcher = bb.fetch.Fetch([self.recipe_url], self.d)
+        fetcher.download()
+
+    @skipIfNoNetwork()
+    def test_mirror_tarball_outdated(self):
+        self.make_git_repo()
+        ## Upstream commit not in the mirror
+        self.d.setVar("SRCREV", "15413486df1f5a5b5af699b6f3ba5f0984e52a9f")
+        fetcher = bb.fetch.Fetch([self.recipe_url], self.d)
+        with self.assertRaises(bb.fetch2.NetworkAccess):
+            fetcher.download()
+
+class FetchPremirroronlyBrokenTarball(FetcherTest):
+
+    def setUp(self):
+        super(FetchPremirroronlyBrokenTarball, self).setUp()
+        self.mirrordir = os.path.join(self.tempdir, "mirrors")
+        os.mkdir(self.mirrordir)
+        self.reponame = "bitbake"
+        self.gitdir = os.path.join(self.tempdir, "git", self.reponame)
+        self.recipe_url = "git://git.fake.repo/bitbake"
+        self.d.setVar("BB_FETCH_PREMIRRORONLY", "1")
+        self.d.setVar("BB_NO_NETWORK", "1")
+        self.d.setVar("PREMIRRORS", self.recipe_url + " " + "file://{}".format(self.mirrordir) + " \n")
+        self.mirrorname = "git2_git.fake.repo.bitbake.tar.gz"
+        with open(os.path.join(self.mirrordir, self.mirrorname), 'w') as targz:
+            targz.write("This is not tar.gz file!")
+
+    def test_mirror_broken_download(self):
+        import sys
+        self.d.setVar("SRCREV", "0"*40)
+        fetcher = bb.fetch.Fetch([self.recipe_url], self.d)
+        with self.assertRaises(bb.fetch2.FetchError):
+            fetcher.download()
+        stdout = sys.stdout.getvalue()
+        self.assertFalse(" not a git repository (or any parent up to mount point /)" in stdout)

bitbake/lib/bb/tests/parse.py

@@ -119,7 +119,7 @@ EXTRA_OECONF:class-target = "b"
 EXTRA_OECONF:append = " c"
 """
 
-    def test_parse_overrides(self):
+    def test_parse_overrides2(self):
         f = self.parsehelper(self.overridetest2)
         d = bb.parse.handle(f.name, self.d)['']
         d.appendVar("EXTRA_OECONF", " d")
@@ -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/ui/buildinfohelper.py

@@ -45,7 +45,7 @@ from pprint import pformat
 import logging
 from datetime import datetime, timedelta
 
-from django.db import transaction, connection
+from django.db import transaction
 
 
 # pylint: disable=invalid-name
@@ -496,7 +496,7 @@ class ORMWrapper(object):
             if not parent_path:
                 parent_path = "/"
             parent_obj = self._cached_get(Target_File, target = target_obj, path = parent_path, inodetype = Target_File.ITYPE_DIRECTORY)
-            tf_obj = Target_File.objects.create(
+            Target_File.objects.create(
                         target = target_obj,
                         path = path,
                         size = size,
@@ -561,7 +561,7 @@ class ORMWrapper(object):
 
             parent_obj = Target_File.objects.get(target = target_obj, path = parent_path, inodetype = Target_File.ITYPE_DIRECTORY)
 
-            tf_obj = Target_File.objects.create(
+            Target_File.objects.create(
                         target = target_obj,
                         path = path,
                         size = size,
@@ -1062,27 +1062,6 @@ class BuildInfoHelper(object):
 
         return recipe_info
 
-    def _get_path_information(self, task_object):
-        self._ensure_build()
-
-        assert isinstance(task_object, Task)
-        build_stats_format = "{tmpdir}/buildstats/{buildname}/{package}/"
-        build_stats_path = []
-
-        for t in self.internal_state['targets']:
-            buildname = self.internal_state['build'].build_name
-            pe, pv = task_object.recipe.version.split(":",1)
-            if pe:
-                package = task_object.recipe.name + "-" + pe + "_" + pv
-            else:
-                package = task_object.recipe.name + "-" + pv
-
-            build_stats_path.append(build_stats_format.format(tmpdir=self.tmp_dir,
-                                                     buildname=buildname,
-                                                     package=package))
-
-        return build_stats_path
-
 
     ################################
     ## external available methods to store information

bitbake/lib/bb/ui/knotty.py

@@ -877,7 +877,6 @@ def main(server, eventHandler, params, tf = TerminalFilter):
                     state_force_shutdown()
 
             main.shutdown = main.shutdown + 1
-            pass
         except Exception as e:
             import traceback
             sys.stderr.write(traceback.format_exc())

documentation/Makefile

@@ -47,9 +47,11 @@ 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,11 +64,12 @@ 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
 can still use the Yocto Project. See the
-:ref:`ref-manual/system-requirements:required git, tar, python and gcc versions`
+:ref:`ref-manual/system-requirements:required git, tar, python, make and gcc versions`
 section in the Yocto Project Reference Manual for information.
 
 Build Host Packages
@@ -256,12 +257,7 @@ 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"
+         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

@@ -1,8 +1,8 @@
 .. SPDX-License-Identifier: CC-BY-SA-2.0-UK
 
-************************************************
-Board Support Packages (BSP) - Developer's Guide
-************************************************
+**************************************************
+Board Support Packages (BSP) --- Developer's Guide
+**************************************************
 
 A Board Support Package (BSP) is a collection of information that
 defines how to support a particular hardware device, set of devices, or
@@ -725,6 +725,7 @@ 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"
@@ -53,7 +53,7 @@ author = 'The Linux Foundation'
 # -- General configuration ---------------------------------------------------
 
 # Prevent building with an outdated version of sphinx
-needs_sphinx = "3.1"
+needs_sphinx = "4.0"
 
 # to load local extension from the folder 'sphinx'
 sys.path.insert(0, os.path.abspath('sphinx'))
@@ -108,7 +108,7 @@ extlinks = {
     'oe_layer': ('https://layers.openembedded.org/layerindex/branch/master/layer%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 +129,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,6 +1125,7 @@ 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
 --------------------------------------------
@@ -2305,7 +2306,7 @@ under ``files``) requires a recipe that has the file listed in the
 :term:`SRC_URI` variable. Additionally, you need to manually write the
 ``do_compile`` and ``do_install`` tasks. The :term:`S` variable defines the
 directory containing the source code, which is set to
-:term:`WORKDIR` in this case - the
+:term:`WORKDIR` in this case --- the
 directory BitBake uses for the build.
 ::
 
@@ -2562,7 +2563,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
@@ -2620,7 +2621,7 @@ chapter of the BitBake User Manual.
 This next list summarizes the most important and most commonly used
 parts of the recipe syntax. For more information on these parts of the
 syntax, you can reference the
-:doc:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata` chapter
+":doc:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata`" chapter
 in the BitBake User Manual.
 
 -  *Line Continuation (\\):* Use the backward slash (``\``) character to
@@ -2779,7 +2780,7 @@ in the BitBake User Manual.
    functionality. The same considerations apply to various system
    utilities (e.g. ``sed``, ``grep``, ``awk``, and so forth) that you
    might wish to use. If in doubt, you should check with multiple
-   implementations - including those from BusyBox.
+   implementations --- including those from BusyBox.
 
 Adding a New Machine
 ====================
@@ -3347,9 +3348,9 @@ The actual directory depends on several things:
 
 -  :term:`PN`: The recipe name.
 
--  :term:`EXTENDPE`: The epoch - (if
+-  :term:`EXTENDPE`: The epoch --- if
    :term:`PE` is not specified, which is
-   usually the case for most recipes, then :term:`EXTENDPE` is blank).
+   usually the case for most recipes, then :term:`EXTENDPE` is blank.
 
 -  :term:`PV`: The recipe version.
 
@@ -3618,7 +3619,7 @@ Yocto Project Overview and Concepts Manual.
 The following figure and list overviews the build process:
 
 .. image:: figures/bitbake-build-flow.png
-   :align: center
+   :width: 100%
 
 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
@@ -3703,7 +3704,7 @@ Setting Up and Running a Multiple Configuration Build
 
 To accomplish a multiple configuration build, you must define each
 target's configuration separately using a parallel configuration file in
-the :term:`Build Directory`, and you
+the :term:`Build Directory` or configuration directory within a layer, and you
 must follow a required file hierarchy. Additionally, you must enable the
 multiple configuration builds in your ``local.conf`` file.
 
@@ -3711,16 +3712,19 @@ Follow these steps to set up and execute multiple configuration builds:
 
 -  *Create Separate Configuration Files*: You need to create a single
    configuration file for each build target (each multiconfig).
-   Minimally, each configuration file must define the machine and the
-   temporary directory BitBake uses for the build. Suggested practice
-   dictates that you do not overlap the temporary directories used
-   during the builds. However, it is possible that you can share the
-   temporary directory
-   (:term:`TMPDIR`). For example,
-   consider a scenario with two different multiconfigs for the same
+   The configuration definitions are implementation dependent but often
+   each configuration file will define the machine and the
+   temporary directory BitBake uses for the build. Whether the same
+   temporary directory (:term:`TMPDIR`) can be shared will depend on what is
+   similar and what is different between the configurations. Multiple MACHINE
+   targets can share the same (:term:`TMPDIR`) as long as the rest of the
+   configuration is the same, multiple DISTRO settings would need separate
+   (:term:`TMPDIR`) directories.
+
+   For example, consider a scenario with two different multiconfigs for the same
    :term:`MACHINE`: "qemux86" built
    for two distributions such as "poky" and "poky-lsb". In this case,
-   you might want to use the same :term:`TMPDIR`.
+   you would need to use the different :term:`TMPDIR`.
 
    Here is an example showing the minimal statements needed in a
    configuration file for a "qemux86" target whose temporary build
@@ -3731,17 +3735,16 @@ Follow these steps to set up and execute multiple configuration builds:
 
    The location for these multiconfig configuration files is specific.
    They must reside in the current build directory in a sub-directory of
-   ``conf`` named ``multiconfig``. Following is an example that defines
+   ``conf`` named ``multiconfig`` or within a layer's ``conf`` directory
+   under a directory named ``multiconfig``. Following is an example that defines
    two configuration files for the "x86" and "arm" multiconfigs:
 
    .. 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.
-   Consequently, using the configuration file as a pre-configuration
-   file is not possible unless it is located in the current working
-   directory.
+   The usual :term:`BBPATH` search path is used to locate multiconfig files in
+   a similar way to other conf files.
 
 -  *Add the BitBake Multi-configuration Variable to the Local
    Configuration File*: Use the
@@ -4826,7 +4829,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
@@ -5392,7 +5395,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
@@ -5464,7 +5467,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.
@@ -5479,7 +5482,9 @@ 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
+   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.
 
 Getting Help
 ------------
@@ -5546,7 +5551,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
@@ -5880,7 +5885,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 bmaptool copy mkefidisk-201804191017-sda.direct /dev/sdX
+   $ oe-run-native bmap-tools-native bmaptool copy mkefidisk-201804191017-sda.direct /dev/sdX
 
 or ::
 
@@ -6432,10 +6437,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
-``TEMPLATECONF`` to locate the directory from which it gathers
+:term:`TEMPLATECONF` to locate the directory from which it gathers
 configuration information that ultimately ends up in the
 :term:`Build Directory` ``conf`` directory.
-By default, ``TEMPLATECONF`` is set as follows in the ``poky``
+By default, :term:`TEMPLATECONF` is set as follows in the ``poky``
 repository::
 
    TEMPLATECONF=${TEMPLATECONF:-meta-poky/conf}
@@ -6450,7 +6455,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
-``TEMPLATECONF`` variable to your directory. The ``TEMPLATECONF``
+:term:`TEMPLATECONF` variable to your directory. The :term:`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
@@ -6490,7 +6495,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 ``TEMPLATECONF`` set to your directory.
+making sure you have :term:`TEMPLATECONF` set to your directory.
 
 Conserving Disk Space
 =====================
@@ -6597,7 +6602,7 @@ the following:
    installed into an image.
 
 -  Binary Package Version: The binary package version is composed of two
-   components - a version and a revision.
+   components --- a version and a revision.
 
    .. note::
 
@@ -6934,7 +6939,7 @@ optional arguments::
       Postinstall script to use for all packages
       (as a string)
    recursive
-      True to perform a recursive search - default
+      True to perform a recursive search --- default
       False
    hook
       A hook function to be called for every match.
@@ -6955,7 +6960,7 @@ optional arguments::
       Extra runtime dependencies (RDEPENDS) to be
       set for all packages. The default value of None
       causes a dependency on the main package
-      (${PN}) - if you do not want this, pass empty
+      (${PN}) --- if you do not want this, pass empty
       string '' for this parameter.
    aux_files_pattern
       Extra item(s) to be added to FILES for each
@@ -6981,7 +6986,7 @@ optional arguments::
       or a list of strings for multiple items. Must
       include %s.
    allow_links
-      True to allow symlinks to be matched - default
+      True to allow symlinks to be matched --- default
       False
    summary
       Summary to set for each package. Must include %s;
@@ -7426,7 +7431,7 @@ A Package Test (ptest) runs tests against packages built by the
 OpenEmbedded build system on the target machine. A ptest contains at
 least two items: the actual test, and a shell script (``run-ptest``)
 that starts the test. The shell script that starts the test must not
-contain the actual test - the script only starts the test. On the other
+contain the actual test --- the script only starts the test. On the other
 hand, the test can be anything from a simple shell script that runs a
 binary and checks the output to an elaborate system of test binaries and
 data files.
@@ -7609,6 +7614,11 @@ The
 fetch URI to download each dependency and capture license details where
 possible. The result is a generated recipe.
 
+After running for quite a long time, in particular building the
+``nodejs-native`` package, the command should end as follows::
+
+   INFO: Recipe /home/.../build/workspace/recipes/cute-files/cute-files_1.0.2.bb has been automatically created; further editing may be required to make it fully functional
+
 The recipe file is fairly simple and contains every license that
 ``recipetool`` finds and includes the licenses in the recipe's
 :term:`LIC_FILES_CHKSUM`
@@ -7619,7 +7629,7 @@ modules and manually add the information to the recipe.
 
 ``recipetool`` creates a "shrinkwrap" file for your recipe. Shrinkwrap
 files capture the version of all dependent modules. Many packages do not
-provide shrinkwrap files. ``recipetool`` create a shrinkwrap file as it
+provide shrinkwrap files but ``recipetool`` will create a shrinkwrap file as it
 runs.
 
 .. note::
@@ -7631,18 +7641,38 @@ runs.
 The ``devtool edit-recipe`` command lets you take a look at the recipe::
 
    $ devtool edit-recipe cute-files
+   # Recipe created by recipetool
+   # This is the basis of a recipe and may need further editing in order to be fully functional.
+   # (Feel free to remove these comments when editing.)
+
    SUMMARY = "Turn any folder on your computer into a cute file browser, available on the local network."
-   LICENSE = "MIT & ISC & Unknown"
+   # WARNING: the following LICENSE and LIC_FILES_CHKSUM values are best guesses - it is
+   # your responsibility to verify that the values are complete and correct.
+   #
+   # NOTE: multiple licenses have been detected; they have been separated with &
+   # in the LICENSE value for now since it is a reasonable assumption that all
+   # of the licenses apply. If instead there is a choice between the multiple
+   # licenses then you should change the value to separate the licenses with |
+   # instead of &. If there is any doubt, check the accompanying documentation
+   # to determine which situation is applicable.
+
+   SUMMARY = "Turn any folder on your computer into a cute file browser, available on the local network."
+   LICENSE = "BSD-3-Clause & ISC & MIT"
    LIC_FILES_CHKSUM = "file://LICENSE;md5=71d98c0a1db42956787b1909c74a86ca \
-       file://node_modules/toidentifier/LICENSE;md5=1a261071a044d02eb6f2bb47f51a3502 \
-       file://node_modules/debug/LICENSE;md5=ddd815a475e7338b0be7a14d8ee35a99 \
-       ...
+                       file://node_modules/accepts/LICENSE;md5=bf1f9ad1e2e1d507aef4883fff7103de \
+                       file://node_modules/array-flatten/LICENSE;md5=44088ba57cb871a58add36ce51b8de08 \
+   ...
+                       file://node_modules/cookie-signature/Readme.md;md5=57ae8b42de3dd0c1f22d5f4cf191e15a"
+
    SRC_URI = " \
        npm://registry.npmjs.org/;package=cute-files;version=${PV} \
        npmsw://${THISDIR}/${BPN}/npm-shrinkwrap.json \
        "
+
    S = "${WORKDIR}/npm"
+
    inherit npm
+
    LICENSE:${PN} = "MIT"
    LICENSE:${PN}-accepts = "MIT"
    LICENSE:${PN}-array-flatten = "MIT"
@@ -7675,23 +7705,16 @@ command to deploy your package::
    $ devtool deploy-target -s cute-files root@192.168.7.2
 
 Once the package is installed on the target, you can
-test the application:
-
-.. note::
-
-   Because of a known issue, you cannot simply run ``cute-files`` as you would
-   if you had run ``npm install``.
-
-::
+test the application to show the contents of any directory::
 
   $ cd /usr/lib/node_modules/cute-files
-  $ node cute-files.js
+  $ cute-files
 
 On a browser,
 go to ``http://192.168.7.2:3000`` and you see the following:
 
 .. image:: figures/cute-files-npm-example.png
-   :align: center
+   :width: 100%
 
 You can find the recipe in ``workspace/recipes/cute-files``. You can use
 the recipe in any layer you choose.
@@ -7713,12 +7736,11 @@ command::
 
    $ devtool add https://github.com/martinaglv/cute-files.git
 
-The
-recipe this command generates is very similar to the recipe created in
+The recipe this command generates is very similar to the recipe created in
 the previous section. However, the :term:`SRC_URI` looks like the following::
 
    SRC_URI = " \
-       git://github.com/martinaglv/cute-files.git;protocol=https \
+       git://github.com/martinaglv/cute-files.git;protocol=https;branch=master \
        npmsw://${THISDIR}/${BPN}/npm-shrinkwrap.json \
        "
 
@@ -8215,6 +8237,7 @@ 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
@@ -8555,7 +8578,7 @@ instruction in the ``README`` file
 Here is a sample screenshot of the interface:
 
 .. image:: figures/buildhistory-web.png
-   :align: center
+   :width: 100%
 
 Performing Automated Runtime Testing
 ====================================
@@ -9126,13 +9149,13 @@ The JSON file must include an object with the test name as keys of an
 object or an array. This object (or array of objects) uses the following
 data:
 
--  "pkg" - A mandatory string that is the name of the package to be
+-  "pkg" --- a mandatory string that is the name of the package to be
    installed.
 
--  "rm" - An optional boolean, which defaults to "false", that specifies
+-  "rm" --- an optional boolean, which defaults to "false", that specifies
    to remove the package after the test.
 
--  "extract" - An optional boolean, which defaults to "false", that
+-  "extract" --- an optional boolean, which defaults to "false", that
    specifies if the package must be extracted from the package format.
    When set to "true", the package is not automatically installed into
    the DUT.
@@ -9214,7 +9237,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.
 
@@ -9409,7 +9432,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.
@@ -9797,7 +9820,7 @@ Logging With Bash
 ~~~~~~~~~~~~~~~~~
 
 When creating recipes using Bash and inserting code that handles build
-logs, you have the same goals - informative with minimal console output.
+logs, you have the same goals --- informative with minimal console output.
 The syntax you use for recipes written in Bash is similar to that of
 recipes written in Python described in the previous section.
 
@@ -10070,7 +10093,7 @@ to use GDB directly on the remote target to debug applications. These
 constraints arise because GDB needs to load the debugging information
 and the binaries of the process being debugged. Additionally, GDB needs
 to perform many computations to locate information such as function
-names, variable names and values, stack traces and so forth - even
+names, variable names and values, stack traces and so forth --- even
 before starting the debugging process. These extra computations place
 more load on the target system and can alter the characteristics of the
 program being debugged.
@@ -10177,10 +10200,9 @@ debugger.
 
 2. *Configure the system to include gdbserver in the target filesystem:*
 
-   Make the following addition in either your ``local.conf`` file or in
-   an image recipe::
+   Make the following addition in your ``local.conf`` file::
 
-      IMAGE_INSTALL:append = " gdbserver"
+      EXTRA_IMAGE_FEATURES:append = " tools-debug"
 
    The change makes
    sure the ``gdbserver`` package is included.
@@ -10227,14 +10249,14 @@ debugger.
 
       $ mkdir debugfs
       $ cd debugfs
-      $ 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
+      $ 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
 
 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.
+   ``PATH`` environment variable and sets ``$GDB`` to the SDK's debugger.
 
    If you are using the build system, Gdb is located in
    `build-dir`\ ``/tmp/sysroots/``\ `host`\ ``/usr/bin/``\ `architecture`\ ``/``\ `architecture`\ ``-gdb``
@@ -10313,24 +10335,20 @@ 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 adding "gdb" to
-   :term:`IMAGE_INSTALL`::
+-  Ensure that GDB is on the target. You can do this by making
+   the following addition to your ``local.conf`` file::
 
-      IMAGE_INSTALL:append = " gdb"
+      EXTRA_IMAGE_FEATURES:append = " tools-debug"
 
-   Alternatively, you can add "tools-debug" to :term:`IMAGE_FEATURES`::
+-  Ensure that debug symbols are present. You can do so by adding the
+   corresponding ``-dbg`` package to :term:`IMAGE_INSTALL`::
 
-      IMAGE_FEATURES:append = " tools-debug"
+      IMAGE_INSTALL:append = " packagename-dbg"
 
--  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
+   Alternatively, you can add the following to ``local.conf`` to include
    all the debug symbols::
 
-      IMAGE_FEATURES:append = " dbg-pkgs"
+      EXTRA_IMAGE_FEATURES:append = " dbg-pkgs"
 
 .. note::
 
@@ -10565,7 +10583,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,
@@ -10652,7 +10670,7 @@ Preparing Changes for Submission
    -  If the change addresses a specific bug or issue that is associated
       with a bug-tracking ID, include a reference to that ID in your
       detailed description. For example, the Yocto Project uses a
-      specific convention for bug references - any commit that addresses
+      specific convention for bug references --- any commit that addresses
       a specific bug should use the following form for the detailed
       description. Be sure to use the actual bug-tracking ID from
       Bugzilla for bug-id::
@@ -10915,20 +10933,20 @@ follows:
    result in the most straightforward path into the stable branch for the
    fix.
 
-   a. *If the fix is present in the master branch - Submit a backport request
+   a. *If the fix is present in the master branch --- submit a backport request
       by email:* You should send an email to the relevant stable branch
       maintainer and the mailing list with details of the bug or CVE to be
       fixed, the commit hash on the master branch that fixes the issue and
       the stable branches which you would like this fix to be backported to.
 
-   b. *If the fix is not present in the master branch - Submit the fix to the
+   b. *If the fix is not present in the master branch --- submit the fix to the
       master branch first:* This will ensure that the fix passes through the
       project's usual patch review and test processes before being accepted.
       It will also ensure that bugs are not left unresolved in the master
       branch itself. Once the fix is accepted in the master branch a backport
       request can be submitted as above.
 
-   c. *If the fix is unsuitable for the master branch - Submit a patch
+   c. *If the fix is unsuitable for the master branch --- submit a patch
       directly for the stable branch:* This method should be considered as a
       last resort. It is typically necessary when the master branch is using
       a newer version of the software which includes an upstream fix for the
@@ -11259,7 +11277,7 @@ Providing the Source Code
 
 Compliance activities should begin before you generate the final image.
 The first thing you should look at is the requirement that tops the list
-for most compliance groups - providing the source. The Yocto Project has
+for most compliance groups --- providing the source. The Yocto Project has
 a few ways of meeting this requirement.
 
 One of the easiest ways to meet this requirement is to provide the
@@ -11442,7 +11460,7 @@ this function, you have to follow the following steps:
    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::
+   during BitBake using the fossology-python.bbclass::
 
       # Select fossology-python.bbclass.
       INHERIT += "fossology-python"
@@ -11507,8 +11525,15 @@ known security vulnerabilities, as tracked by the public
 `Common Vulnerabilities and Exposures (CVE) <https://en.wikipedia.org/wiki/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.
+
+To know which packages are vulnerable to known security vulnerabilities
+in the specific image you are building, add the following setting to your
+configuration::
 
    INHERIT += "cve-check"
 

documentation/dev-manual/start.rst

@@ -311,7 +311,7 @@ Project Build Host:
 
 3. *Meet Minimal Version Requirements:* The OpenEmbedded build system
    should be able to run on any modern distribution that has the
-   following versions for Git, tar, Python and gcc.
+   following versions for Git, tar, Python, gcc and make.
 
    -  Git &MIN_GIT_VERSION; or greater
 
@@ -321,10 +321,12 @@ Project Build Host:
 
    -  gcc &MIN_GCC_VERSION; or greater.
 
+   -  GNU make &MIN_MAKE_VERSION; or greater
+
    If your build host does not meet any of these listed version
    requirements, you can take steps to prepare the system so that you
    can still use the Yocto Project. See the
-   ":ref:`ref-manual/system-requirements:required git, tar, python and gcc versions`"
+   ":ref:`ref-manual/system-requirements:required git, tar, python, make and gcc versions`"
    section in the Yocto Project Reference Manual for information.
 
 4. *Install Development Host Packages:* Required development host
@@ -496,7 +498,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/advanced.rst

@@ -183,7 +183,7 @@ the structure:
    order to define a base kernel policy or major kernel type to be
    reused across multiple BSPs, place the file in ``ktypes`` directory.
 
-These distinctions can easily become blurred - especially as out-of-tree
+These distinctions can easily become blurred --- especially as out-of-tree
 features slowly merge upstream over time. Also, remember that how the
 description files are placed is a purely logical organization and has no
 impact on the functionality of the kernel Metadata. There is no impact

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

@@ -117,7 +117,7 @@ upstream Linux kernel development and are managed by the Yocto Project
 team's Yocto Linux kernel development strategy. It is the Yocto Project
 team's policy to not back-port minor features to the released Yocto
 Linux kernel. They only consider back-porting significant technological
-jumps - and, that is done after a complete gap analysis. The reason
+jumps --- and, that is done after a complete gap analysis. The reason
 for this policy is that back-porting any small to medium sized change
 from an evolving Linux kernel can easily create mismatches,
 incompatibilities and very subtle errors.
@@ -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
-   :align: center
+   :width: 100%
 
 In the illustration, the "Kernel.org Branch Point" marks the specific
 spot (or Linux kernel release) from which the Yocto Linux kernel is
@@ -318,12 +318,13 @@ 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
-   :align: center
+   :width: 100%
 
 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/index.rst

@@ -12,8 +12,8 @@ to move to one release of the Yocto Project from the previous one.
 .. toctree::
 
    migration-general
-   migration-4.0
-   migration-3.4
+   release-4.0
+   release-3.4
    migration-3.3
    migration-3.2
    migration-3.1

documentation/migration-guides/migration-1.5.rst

@@ -26,7 +26,7 @@ provide packages for these, you can install and use the Buildtools
 tarball, which provides an SDK-like environment containing them.
 
 For more information on this requirement, see the
-":ref:`ref-manual/system-requirements:required git, tar, python and gcc versions`"
+":ref:`ref-manual/system-requirements:required git, tar, python, make and gcc versions`"
 section.
 
 .. _migration-1.5-atom-pc-bsp:

documentation/migration-guides/migration-1.6.rst

@@ -341,39 +341,39 @@ Removed and Renamed Recipes
 
 The following recipes have been removed:
 
--  ``packagegroup-toolset-native`` - This recipe is largely unused.
+-  ``packagegroup-toolset-native`` --- this recipe is largely unused.
 
--  ``linux-yocto-3.8`` - Support for the Linux yocto 3.8 kernel has been
+-  ``linux-yocto-3.8`` --- support for the Linux yocto 3.8 kernel has been
    dropped. Support for the 3.10 and 3.14 kernels have been added with
    the ``linux-yocto-3.10`` and ``linux-yocto-3.14`` recipes.
 
--  ``ocf-linux`` - This recipe has been functionally replaced using
+-  ``ocf-linux`` --- this recipe has been functionally replaced using
    ``cryptodev-linux``.
 
--  ``genext2fs`` - ``genext2fs`` is no longer used by the build system
+-  ``genext2fs`` --- ``genext2fs`` is no longer used by the build system
    and is unmaintained upstream.
 
--  ``js`` - This provided an ancient version of Mozilla's javascript
+-  ``js`` --- this provided an ancient version of Mozilla's javascript
    engine that is no longer needed.
 
--  ``zaurusd`` - The recipe has been moved to the ``meta-handheld``
+-  ``zaurusd`` --- the recipe has been moved to the ``meta-handheld``
    layer.
 
--  ``eglibc 2.17`` - Replaced by the ``eglibc 2.19`` recipe.
+-  ``eglibc 2.17`` --- replaced by the ``eglibc 2.19`` recipe.
 
--  ``gcc 4.7.2`` - Replaced by the now stable ``gcc 4.8.2``.
+-  ``gcc 4.7.2`` --- replaced by the now stable ``gcc 4.8.2``.
 
--  ``external-sourcery-toolchain`` - this recipe is now maintained in
+-  ``external-sourcery-toolchain`` --- this recipe is now maintained in
    the ``meta-sourcery`` layer.
 
--  ``linux-libc-headers-yocto 3.4+git`` - Now using version 3.10 of the
+-  ``linux-libc-headers-yocto 3.4+git`` --- now using version 3.10 of the
    ``linux-libc-headers`` by default.
 
--  ``meta-toolchain-gmae`` - This recipe is obsolete.
+-  ``meta-toolchain-gmae`` --- this recipe is obsolete.
 
--  ``packagegroup-core-sdk-gmae`` - This recipe is obsolete.
+-  ``packagegroup-core-sdk-gmae`` --- this recipe is obsolete.
 
--  ``packagegroup-core-standalone-gmae-sdk-target`` - This recipe is
+-  ``packagegroup-core-standalone-gmae-sdk-target`` --- this recipe is
    obsolete.
 
 .. _migration-1.6-removed-classes:

documentation/migration-guides/migration-1.7.rst

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

documentation/migration-guides/migration-2.1.rst

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

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:
 
@@ -442,7 +442,7 @@ The following miscellaneous changes have occurred:
 -  :ref:`ref-classes-image`: Renamed COMPRESS(ION) to CONVERSION. This change
    means that ``COMPRESSIONTYPES``, ``COMPRESS_DEPENDS`` and
    ``COMPRESS_CMD`` are deprecated in favor of ``CONVERSIONTYPES``,
-   ``CONVERSION_DEPENDS`` and ``CONVERSION_CMD``. The ``COMPRESS*``
+   ``CONVERSION_DEPENDS`` and :term:`CONVERSION_CMD`. The ``COMPRESS*``
    variable names will still work in the 2.2 release but metadata that
    does not need to be backwards-compatible should be changed to use the
    new names as the ``COMPRESS*`` ones will be removed in a future

documentation/migration-guides/migration-2.4.rst

@@ -301,7 +301,7 @@ The following are additional changes:
    likely be removed in the next Yocto Project release.
 
 -  The ``vmdk``, ``vdi``, and ``qcow2`` image file types are now used in
-   conjunction with the "wic" image type through ``CONVERSION_CMD``.
+   conjunction with the "wic" image type through :term:`CONVERSION_CMD`.
    Consequently, the equivalent image types are now ``wic.vmdk``,
    ``wic.vdi``, and ``wic.qcow2``, respectively.
 

documentation/migration-guides/migration-2.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.
@@ -216,11 +216,11 @@ The following sanity check changes occurred.
 -  :term:`SRC_URI` is now checked for usage of two
    problematic items:
 
-   -  "${PN}" prefix/suffix use - Warnings always appear if ${PN} is
+   -  "${PN}" prefix/suffix use --- warnings always appear if ${PN} is
       used. You must fix the issue regardless of whether multiconfig or
       anything else that would cause prefixing/suffixing to happen.
 
-   -  Github archive tarballs - these are not guaranteed to be stable.
+   -  Github archive tarballs --- these are not guaranteed to be stable.
       Consequently, it is likely that the tarballs will be refreshed and
       thus the SRC_URI checksums will fail to apply. It is recommended
       that you fetch either an official release tarball or a specific

documentation/migration-guides/migration-3.1.rst

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

documentation/migration-guides/migration-3.2.rst

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

documentation/migration-guides/migration-3.3.rst

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

@@ -1,6 +1,3 @@
-Release 3.4 (honister)
-======================
-
 Migration notes for 3.4 (honister)
 ----------------------------------
 
@@ -149,7 +146,7 @@ Virtual runtime provides
 ~~~~~~~~~~~~~~~~~~~~~~~~
 
 Recipes shouldn't use the ``virtual/`` string in :term:`RPROVIDES` and
-:term:`RDEPENDS` - it is confusing because ``virtual/`` has no special
+:term:`RDEPENDS` --- it is confusing because ``virtual/`` has no special
 meaning in :term:`RPROVIDES` and :term:`RDEPENDS` (unlike in the
 corresponding build-time :term:`PROVIDES` and :term:`DEPENDS`).
 
@@ -174,7 +171,7 @@ Extensible SDK host extension
 For a normal SDK, some layers append to :term:`TOOLCHAIN_HOST_TASK`
 unconditionally which is fine, until the eSDK tries to override the
 variable to its own values. Instead of installing packages specified
-in this variable it uses native recipes instead - a very different
+in this variable it uses native recipes instead --- a very different
 approach. This has led to confusing errors when binaries are added
 to the SDK but not relocated.
 
@@ -236,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.
@@ -255,7 +252,7 @@ Miscellaneous
 
 - The previously deprecated ``COMPRESS_CMD`` and
   ``CVE_CHECK_CVE_WHITELIST`` variables have been removed. Use
-  ``CONVERSION_CMD`` and ``CVE_CHECK_WHITELIST`` (replaced by
+  :term:`CONVERSION_CMD` and ``CVE_CHECK_WHITELIST`` (replaced by
   :term:`CVE_CHECK_IGNORE` in version 3.5) respectively
   instead.
 
@@ -265,6 +262,12 @@ Miscellaneous
   built-in override support in the fetcher or overrides in general
   instead.
 
-.. include:: release-notes-3.4.rst
-.. include:: release-notes-3.4.1.rst
-.. include:: release-notes-3.4.2.rst
+- The ``-P`` (``--clear-password``) option can no longer be used with
+  ``useradd`` and ``usermod`` entries in :term:`EXTRA_USERS_PARAMS`.
+  It was being implemented using a custom patch to the ``shadow`` recipe
+  which clashed with a ``-P`` option that was added upstream in
+  ``shadow`` version 4.9, and in any case is fundamentally insecure.
+  Hardcoded passwords are still supported but they need to be hashed, see
+  examples in :term:`EXTRA_USERS_PARAMS`.
+
+

documentation/migration-guides/migration-4.0.rst

@@ -1,61 +1,74 @@
 Release 4.0 (kirkstone)
 =======================
 
+Migration notes for 4.0 (kirkstone)
+-----------------------------------
+
 This section provides migration information for moving to the Yocto
 Project 4.0 Release (codename "kirkstone") from the prior release.
 
-Recipe changes
---------------
+.. _migration-4.0-inclusive-language:
 
-- To use more `inclusive language <https://inclusivenaming.org/>`__
-  in the code and documentation, some variables have been renamed or even
-  deleted. BitBake will stop with an error when renamed or removed variables
-  still exist in your recipes or configuration.
+Inclusive language improvements
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-  Please note that the change applies also to environmental variables, so
-  make sure you use a fresh environment for your build.
+To use more `inclusive language <https://inclusivenaming.org/>`__
+in the code and documentation, some variables have been renamed, and
+some have been deleted where they are no longer needed. In many cases the
+new names are also easier to understand. BitBake will stop with an error when
+renamed or removed variables still exist in your recipes or configuration.
 
-  The following variables have changed their names:
+Please note that the change applies also to environmental variables, so
+make sure you use a fresh environment for your build.
 
-  - ``BB_ENV_WHITELIST`` became :term:`BB_ENV_PASSTHROUGH`
-  - ``BB_ENV_EXTRAWHITE`` became :term:`BB_ENV_PASSTHROUGH_ADDITIONS`
-  - ``BB_HASHBASE_WHITELIST`` became :term:`BB_BASEHASH_IGNORE_VARS`
-  - ``BB_HASHCONFIG_WHITELIST`` became :term:`BB_HASHCONFIG_IGNORE_VARS`
-  - ``BB_HASHTASK_WHITELIST`` became ``BB_TASKHASH_IGNORE_TASKS``
-  - ``BB_SETSCENE_ENFORCE_WHITELIST`` became ``BB_SETSCENE_ENFORCE_IGNORE_TASKS``
-  - ``CVE_CHECK_PN_WHITELIST`` became :term:`CVE_CHECK_SKIP_RECIPE`
-  - ``CVE_CHECK_WHITELIST`` became :term:`CVE_CHECK_IGNORE`
-  - ``ICECC_USER_CLASS_BL`` became :term:`ICECC_CLASS_DISABLE`
-  - ``ICECC_SYSTEM_CLASS_BL`` became :term:`ICECC_CLASS_DISABLE`
-  - ``ICECC_USER_PACKAGE_WL`` became :term:`ICECC_RECIPE_ENABLE`
-  - ``ICECC_USER_PACKAGE_BL`` became :term:`ICECC_RECIPE_DISABLE`
-  - ``ICECC_SYSTEM_PACKAGE_BL`` became :term:`ICECC_RECIPE_DISABLE`
-  - ``LICENSE_FLAGS_WHITELIST`` became :term:`LICENSE_FLAGS_ACCEPTED`
-  - ``MULTI_PROVIDER_WHITELIST`` became :term:`BB_MULTI_PROVIDER_ALLOWED`
-  - ``PNBLACKLIST`` became :term:`SKIP_RECIPE`
-  - ``SDK_LOCAL_CONF_BLACKLIST`` became :term:`ESDK_LOCALCONF_REMOVE`
-  - ``SDK_LOCAL_CONF_WHITELIST`` became :term:`ESDK_LOCALCONF_ALLOW`
-  - ``SDK_INHERIT_BLACKLIST`` became :term:`ESDK_CLASS_INHERIT_DISABLE`
-  - ``SSTATE_DUPWHITELIST`` became ``SSTATE_ALLOW_OVERLAP_FILES``
-  - ``SYSROOT_DIRS_BLACKLIST`` became :term:`SYSROOT_DIRS_IGNORE`
-  - ``UNKNOWN_CONFIGURE_WHITELIST`` became :term:`UNKNOWN_CONFIGURE_OPT_IGNORE`
+The following variables have changed their names:
 
-  In addition, ``BB_STAMP_WHITELIST``, ``BB_STAMP_POLICY``, ``INHERIT_BLACKLIST``
-  and ``TUNEABI_WHITELIST`` have been removed.
+- ``BB_ENV_WHITELIST`` became :term:`BB_ENV_PASSTHROUGH`
+- ``BB_ENV_EXTRAWHITE`` became :term:`BB_ENV_PASSTHROUGH_ADDITIONS`
+- ``BB_HASHBASE_WHITELIST`` became :term:`BB_BASEHASH_IGNORE_VARS`
+- ``BB_HASHCONFIG_WHITELIST`` became :term:`BB_HASHCONFIG_IGNORE_VARS`
+- ``BB_HASHTASK_WHITELIST`` became ``BB_TASKHASH_IGNORE_TASKS``
+- ``BB_SETSCENE_ENFORCE_WHITELIST`` became ``BB_SETSCENE_ENFORCE_IGNORE_TASKS``
+- ``CVE_CHECK_PN_WHITELIST`` became :term:`CVE_CHECK_SKIP_RECIPE`
+- ``CVE_CHECK_WHITELIST`` became :term:`CVE_CHECK_IGNORE`
+- ``ICECC_USER_CLASS_BL`` became :term:`ICECC_CLASS_DISABLE`
+- ``ICECC_SYSTEM_CLASS_BL`` became :term:`ICECC_CLASS_DISABLE`
+- ``ICECC_USER_PACKAGE_WL`` became :term:`ICECC_RECIPE_ENABLE`
+- ``ICECC_USER_PACKAGE_BL`` became :term:`ICECC_RECIPE_DISABLE`
+- ``ICECC_SYSTEM_PACKAGE_BL`` became :term:`ICECC_RECIPE_DISABLE`
+- ``LICENSE_FLAGS_WHITELIST`` became :term:`LICENSE_FLAGS_ACCEPTED`
+- ``MULTI_PROVIDER_WHITELIST`` became :term:`BB_MULTI_PROVIDER_ALLOWED`
+- ``PNBLACKLIST`` became :term:`SKIP_RECIPE`
+- ``SDK_LOCAL_CONF_BLACKLIST`` became :term:`ESDK_LOCALCONF_REMOVE`
+- ``SDK_LOCAL_CONF_WHITELIST`` became :term:`ESDK_LOCALCONF_ALLOW`
+- ``SDK_INHERIT_BLACKLIST`` became :term:`ESDK_CLASS_INHERIT_DISABLE`
+- ``SSTATE_DUPWHITELIST`` became ``SSTATE_ALLOW_OVERLAP_FILES``
+- ``SYSROOT_DIRS_BLACKLIST`` became :term:`SYSROOT_DIRS_IGNORE`
+- ``UNKNOWN_CONFIGURE_WHITELIST`` became :term:`UNKNOWN_CONFIGURE_OPT_IGNORE`
+- ``WHITELIST_<license>`` became :term:`INCOMPATIBLE_LICENSE_EXCEPTIONS`
 
-  Many internal variable names have been also renamed accordingly.
+In addition, ``BB_STAMP_WHITELIST``, ``BB_STAMP_POLICY``, ``INHERIT_BLACKLIST``,
+``TUNEABI``, ``TUNEABI_WHITELIST``, and ``TUNEABI_OVERRIDE`` have been removed.
 
-  In addition, in the ``cve-check`` output, the CVE issue status ``Whitelisted``
-  has been renamed to ``Ignored``.
+Many internal variable names have been also renamed accordingly.
 
-  A :oe_git:`convert-variable-renames.py
-  </openembedded-core/tree/scripts/contrib/convert-variable-renames.py>`
-  script is provided to convert your recipes and configuration,
-  and also warns you about the use of problematic words. The script performs
-  changes and you need to review them before committing. An example warning
-  looks like::
+In addition, in the ``cve-check`` output, the CVE issue status ``Whitelisted``
+has been renamed to ``Ignored``.
 
-     poky/scripts/lib/devtool/upgrade.py needs further work at line 275 since it contains abort
+The :term:`BB_DISKMON_DIRS` variable value now uses the term ``HALT``
+instead of ``ABORT``.
+
+A :oe_git:`convert-variable-renames.py
+</openembedded-core/tree/scripts/contrib/convert-variable-renames.py>`
+script is provided to convert your recipes and configuration,
+and also warns you about the use of problematic words. The script performs
+changes and you need to review them before committing. An example warning
+looks like::
+
+    poky/scripts/lib/devtool/upgrade.py needs further work at line 275 since it contains abort
+    
+Fetching changes
+~~~~~~~~~~~~~~~~
 
 - Because of the uncertainty in future default branch names in git repositories,
   it is now required to add a branch name to all URLs described
@@ -70,7 +83,8 @@ Recipe changes
 - Because of `GitHub dropping support for the git:
   protocol <https://github.blog/2021-09-01-improving-git-protocol-security-github/>`__,
   recipes now need to use ``;protocol=https`` at the end of GitHub
-  URLs. The same script as above can be used to convert the recipes.
+  URLs. The same ``convert-srcuri`` script mentioned above can be used to convert
+  your recipes.
 
 - Network access from tasks is now disabled by default on kernels which support
   this feature (on most recent distros such as CentOS 8 and Debian 11 onwards).
@@ -84,87 +98,170 @@ Recipe changes
   usually undermines fetcher source mirroring, image and licence manifests, software
   auditing and supply chain security.
 
-- The :term:`TOPDIR` variable and the current working directory are no longer modified
-  when parsing recipes. Any code depending on that behaviour will no longer work.
+License changes
+~~~~~~~~~~~~~~~
 
-- The ``append``, ``prepend`` and ``remove`` operators can now only be combined with
-  ``=`` and ``:=`` operators. To the exception of the ``append`` plus ``+=`` and
-  ``prepend`` plus ``=+`` combinations, all combinations could be factored up to the
-  ``append``, ``prepend`` or ``remove`` in the combination. This brought a lot of
-  confusion on how the override style syntax operators work and should be used.
-  Therefore, those combinations can simply be replaced by a single ``append``,
-  ``prepend`` or ``remove`` operator without any additional change.
-  For the ``append`` plus ``+=`` (and ``prepend`` plus ``=+``) combinations,
-  the content should be prefixed (respectively suffixed) by a space to maintain
-  the same behavior.  You can learn more about override style syntax operators
-  (``append``, ``prepend`` and ``remove``) in the BitBake documentation:
-  :ref:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata:appending and prepending (override style syntax)`
-  and :ref:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata:removal (override style syntax)`.
+- The ambiguous "BSD" license has been removed from the ``common-licenses`` directory.
+  Each recipe that fetches or builds BSD-licensed code should specify the proper
+  version of the BSD license in its :term:`LICENSE` value.
 
-- :ref:`allarch <ref-classes-allarch>` packagegroups can no longer depend on packages
-  which use :term:`PKG` renaming such as :ref:`ref-classes-debian`.
-
-- :term:`LICENSE` definitions now have to use `SPDX identifiers <https://spdx.org/licenses/>`__.
-  A :oe_git:`convert-spdx-licenses.py </openembedded-core/tree/scripts/contrib/convert-spdx-licenses.py>`
+- :term:`LICENSE` variable values should now use `SPDX identifiers <https://spdx.org/licenses/>`__.
+  If they do not, by default a warning will be shown. A
+  :oe_git:`convert-spdx-licenses.py </openembedded-core/tree/scripts/contrib/convert-spdx-licenses.py>`
   script can be used to update your recipes.
+  
+- :term:`INCOMPATIBLE_LICENSE` should now use `SPDX identifiers <https://spdx.org/licenses/>`__.
+  Additionally, wildcarding is now limited to specifically supported values -
+  see the :term:`INCOMPATIBLE_LICENSE` documentation for further information.
 
-- :term:`SRC_URI`: a new :ref:`bitbake:bitbake-user-manual/bitbake-user-manual-fetching:crate fetcher (\`\`crate://\`\`)`
-  is available for Rust packages.
+- The ``AVAILABLE_LICENSES`` variable has been removed. This variable was a performance
+  liability and is highly dependent on which layers are added to the configuration,
+  which can cause signature issues for users. In addition the ``available_licenses()``
+  function has been removed from the :ref:`license <ref-classes-license>` class as
+  it is no longer needed.
+  
+Removed recipes
+~~~~~~~~~~~~~~~
 
-Class changes
--------------
+The following recipes have been removed in this release:
 
-- The ``distutils*.bbclasses`` have been moved to ``meta-python``. The classes and
-  `DISTUTILS*` variables have been removed from the documentation.
+- ``dbus-test``: merged into main dbus recipe
+- ``libid3tag``: moved to meta-oe - no longer needed by anything in OE-Core
+- ``libportal``: moved to meta-gnome - no longer needed by anything in OE-Core
+- ``linux-yocto``: removed version 5.14 recipes (5.15 and 5.10 still provided)
+- ``python3-nose``: has not changed since 2016 upstream, and no longer needed by anything in OE-Core
+- ``rustfmt``: not especially useful as a standalone recipe
 
-- ``blacklist.bbclass`` is removed and the functionality moved to the
-  :ref:`base <ref-classes-base>` class with a more descriptive
-  ``varflag`` named :term:`SKIP_RECIPE` which will use the `SkipRecipe()`
-  function. The usage will remain the same::
-
-     SKIP_RECIPE[my-recipe] = "Reason for skipping recipe"
-
-- The Python package build process based on `wheels <https://pythonwheels.com/>`__.
+Python changes
+~~~~~~~~~~~~~~
+     
+- ``distutils`` has been deprecated upstream in Python 3.10 and thus the ``distutils*``
+  classes have been moved to ``meta-python``. Recipes that inherit the ``distutils*``
+  classes should be updated to inherit ``setuptools*`` equivalents instead.
+  
+- The Python package build process is now based on `wheels <https://pythonwheels.com/>`__.
   Here are the new Python packaging classes that should be used:
-  :ref:`python-flit_core <ref-classes-python_flit_core>`,
-  :ref:`setuptools_python-build_meta <ref-classes-python_setuptools_build_meta>`
-  and :ref:`python_poetry_core <ref-classes-python_poetry_core>`.
+  :ref:`python_flit_core <ref-classes-python_flit_core>`,
+  :ref:`python_setuptools_build_meta <ref-classes-python_setuptools_build_meta>`
+  and :ref:`python_poetry_core <ref-classes-python_poetry_core>`.  
 
-- ``image-prelink.bbclass`` class is removed.
+- The :ref:`setuptools3 <ref-classes-setuptools3>` class ``do_install()`` task now
+  installs the ``wheel`` binary archive. In current versions of ``setuptools`` the
+  legacy ``setup.py install`` method is deprecated. If the ``setup.py`` cannot be used
+  with wheels, for example it creates files outside of the Python module or standard
+  entry points, then :ref:`setuptools3_legacy <ref-classes-setuptools3_legacy>` should
+  be used instead.
 
-- New :ref:`overlayfs <ref-classes-overlayfs>` and
-  :ref:`overlayfs-etc <ref-classes-overlayfs-etc>` classes are available
-  to make it easier to overlay read-only filesystems (for example)
-  with `OverlayFS <https://en.wikipedia.org/wiki/OverlayFS>`__.
+Prelink removed
+~~~~~~~~~~~~~~~
 
-Configuration changes
----------------------
+Prelink has been dropped by ``glibc`` upstream in 2.36. It already caused issues with
+binary corruption, has a number of open bugs and is of questionable benefit
+without disabling load address randomization and PIE executables.
+    
+We disabled prelinking by default in the honister (3.4) release, but left it able
+to be enabled if desired. However, without glibc support it cannot be maintained
+any further, so all of the prelinking functionality has been removed in this release.
+If you were enabling the ``image-prelink`` class in :term:`INHERIT`, :term:`IMAGE_CLASSES`,
+:term:`USER_CLASSES` etc in your configuration, then you will need to remove the
+reference(s).
 
-- The Yocto Project now allows to reuse Shared State from its autobuilder.
-  If the network connection between our server and your machine is faster
-  than you would build recipes, you can try to speed up your builds
-  by using such Share State and Hash Equivalence by setting::
+Reproducible as standard
+~~~~~~~~~~~~~~~~~~~~~~~~
 
-     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"
+Reproducibility is now considered as standard functionality, thus the 
+``reproducible`` class has been removed and its previous contents merged into the
+:ref:`base <ref-classes-base>` class. If you have references in your configuration to
+``reproducible`` in :term:`INHERIT`, :term:`USER_CLASSES` etc. then they should be
+removed.
+
+Additionally, the ``BUILD_REPRODUCIBLE_BINARIES`` variable is no longer used.
+Specifically for the kernel, if you wish to enable build timestamping functionality
+that is normally disabled for reproducibility reasons, you can do so by setting
+a new :term:`KERNEL_DEBUG_TIMESTAMPS` variable to "1".
 
 Supported host distribution changes
------------------------------------
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-- New support for `AlmaLinux <https://en.wikipedia.org/wiki/AlmaLinux>`__
+- Support for `AlmaLinux <https://en.wikipedia.org/wiki/AlmaLinux>`__
   hosts replacing `CentOS <https://en.wikipedia.org/wiki/CentOS>`__.
   The following distribution versions were dropped: CentOS 8, Ubuntu 16.04 and Fedora 30, 31 and 32.
 
-Changes for release notes
--------------------------
+- ``gcc`` version 7.5 is now required at minimum on the build host. For older
+  host distributions where this is not available, you can use the
+  ``buildtools-extended-tarball`` (easily installable using
+  ``scripts/install-buildtools``).
 
-- Share State cache: now using `ZStandard (zstd) <https://en.wikipedia.org/wiki/Zstd>`__
-  instead of Gzip compression, for better performance.
+:append/:prepend in combination with other operators
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-- BitBake has an improved ``setscene`` task display.
+The ``append``, ``prepend`` and ``remove`` operators can now only be combined with
+``=`` and ``:=`` operators. To the exception of the ``append`` plus ``+=`` and
+``prepend`` plus ``=+`` combinations, all combinations could be factored up to the
+``append``, ``prepend`` or ``remove`` in the combination. This brought a lot of
+confusion on how the override style syntax operators work and should be used.
+Therefore, those combinations should be replaced by a single ``append``,
+``prepend`` or ``remove`` operator without any additional change.
+For the ``append`` plus ``+=`` (and ``prepend`` plus ``=+``) combinations,
+the content should be prefixed (respectively suffixed) by a space to maintain
+the same behavior.  You can learn more about override style syntax operators
+(``append``, ``prepend`` and ``remove``) in the BitBake documentation:
+:ref:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata:appending and prepending (override style syntax)`
+and :ref:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata:removal (override style syntax)`.
 
-- This release fixes the reproducibility issues with ``rust-llvm`` and ``golang``.
-  Recipes in OpenEmbedded-Core are now fully reproducible.
+Miscellaneous changes
+~~~~~~~~~~~~~~~~~~~~~
+  
+- ``blacklist.bbclass`` is removed and the functionality moved to the
+  :ref:`base <ref-classes-base>` class with a more descriptive
+  ``varflag`` variable named :term:`SKIP_RECIPE` which will use the `bb.parse.SkipRecipe()`
+  function. The usage remains the same, for example::
+
+     SKIP_RECIPE[my-recipe] = "Reason for skipping recipe"
+
+- :ref:`allarch <ref-classes-allarch>` packagegroups can no longer depend on packages
+  which use :term:`PKG` renaming such as :ref:`ref-classes-debian`. Such packagegroups
+  recipes should be changed to avoid inheriting :ref:`allarch <ref-classes-allarch>`.
+
+- The ``lnr`` script has been removed. ``lnr`` implemented the same behaviour as `ln --relative --symbolic`,
+  since at the time of creation `--relative` was only available in coreutils 8.16
+  onwards which was too new for the older supported distros. Current supported host
+  distros have a new enough version of coreutils, so it is no longer needed. If you have
+  any calls to ``lnr`` in your recipes or classes, they should be replaced with
+  `ln --relative --symbolic` or `ln -rs` if you prefer the short version.
+
+- The ``package_qa_handle_error()`` function formerly in the :ref:`insane <ref-classes-insane>`
+  class has been moved and renamed - if you have any references in your own custom
+  classes they should be changed to ``oe.qa.handle_error()``.
+
+- When building ``perl``, Berkeley db support is no longer enabled by default, since
+  Berkeley db is largely obsolete. If you wish to reenable it, you can append ``bdb``
+  to :term:`PACKAGECONFIG` in a ``perl`` bbappend or ``PACKAGECONFIG:pn-perl`` at
+  the configuration level.
+
+- For the ``xserver-xorg`` recipe, the ``xshmfence``, ``xmlto`` and ``systemd`` options
+  previously supported in :term:`PACKAGECONFIG` have been removed, as they are no
+  longer supported since the move from building it with autotools to meson in this release.
+
+- For the ``libsdl2`` recipe, various X11 features are now disabled by default (primarily
+  for reproducibility purposes in the native case) with options in :term:`EXTRA_OECMAKE`
+  within the recipe. These can be changed within a bbappend if desired. See the
+  ``libsdl2`` recipe for more details.
+
+- The ``cortexa72-crc`` and ``cortexa72-crc-crypto`` tunes have been removed since
+  the crc extension is now enabled by default for cortexa72. Replace any references to
+  these with ``cortexa72`` and ``cortexa72-crypto`` respectively.
+  
+- The Python development shell (previously known as ``devpyshell``) feature has been
+  renamed to ``pydevshell``. To start it you should now run::
+
+     bitbake <target> -c pydevshell
+
+- The ``packagegroups-core-full-cmdline-libs`` packagegroup is no longer produced, as
+  libraries should normally be brought in via dependencies. If you have any references
+  to this then remove them.
+  
+- The :term:`TOPDIR` variable and the current working directory are no longer modified
+  when parsing recipes. Any code depending on the previous behaviour will no longer
+  work - change any such code to explicitly use appropriate path variables instead.
 

documentation/migration-guides/release-3.4.rst

@@ -0,0 +1,12 @@
+Release 3.4 (honister)
+======================
+
+.. toctree::
+
+   migration-3.4
+   release-notes-3.4
+   release-notes-3.4.1
+   release-notes-3.4.2
+   release-notes-3.4.3
+   release-notes-3.4.4
+

documentation/migration-guides/release-4.0.rst

@@ -0,0 +1,8 @@
+Release 4.0 (kirkstone)
+=======================
+
+.. toctree::
+
+   migration-4.0
+   release-notes-4.0
+   release-notes-4.0.1

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-3.4.3.rst

@@ -0,0 +1,197 @@
+Release notes for 3.4.3 (honister)
+----------------------------------
+
+Security Fixes in 3.4.3
+~~~~~~~~~~~~~~~~~~~~~~~
+
+-  ghostscript: fix :cve:`2021-3781`
+-  ghostscript: fix :cve:`2021-45949`
+-  tiff: Add backports for two CVEs from upstream (:cve:`2022-0561` & :cve:`2022-0562`)
+-  gcc : Fix :cve:`2021-46195`
+-  virglrenderer: fix `CVE-2022-0135 <https://security-tracker.debian.org/tracker/CVE-2022-0135>`__ and `CVE-2022-0175 <https://security-tracker.debian.org/tracker/CVE-2022-0175>`__
+-  binutils: Add fix for :cve:`2021-45078`
+
+
+Fixes in 3.4.3
+~~~~~~~~~~~~~~
+
+-  Revert "cve-check: add lockfile to task"
+-  asciidoc: update git repository
+-  bitbake: build: Tweak exception handling for setscene tasks
+-  bitbake: contrib: Fix hash server Dockerfile dependencies
+-  bitbake: cooker: Improve parsing failure from handled exception usability
+-  bitbake: data_smart: Fix overrides file/line message additions
+-  bitbake: fetch2: ssh: username and password are optional
+-  bitbake: tests/fetch: Handle upstream master -> main branch change
+-  bitbake: utils: Ensure shell function failure in python logging is correct
+-  build-appliance-image: Update to honister head revision
+-  build-appliance-image: Update to honister head revision
+-  coreutils: remove obsolete ignored CVE list
+-  crate-fetch: fix setscene failures
+-  cups: Add --with-dbusdir to EXTRA_OECONF for deterministic build
+-  cve-check: create directory of CVE_CHECK_MANIFEST before copy
+-  cve-check: get_cve_info should open the database read-only
+-  default-distrovars.inc: Switch connectivity check to a yoctoproject.org page
+-  depmodwrapper-cross: add config directory option
+-  devtool: deploy-target: Remove stripped binaries in pseudo context
+-  devtool: explicitly set main or master branches in upgrades when available
+-  docs: fix hardcoded link warning messages
+-  documentation: conf.py: update for 3.4.2
+-  documentation: prepare for 3.4.3 release
+-  expat: Upgrade to 2.4.7
+-  gcc-target: fix glob to remove gcc-<version> binary
+-  gcsections: add nativesdk-cairo to exclude list
+-  go: update to 1.16.15
+-  gst-devtools: 1.18.5 -> 1.18.6
+-  gst-examples: 1.18.5 -> 1.18.6
+-  gstreamer1.0-libav: 1.18.5 -> 1.18.6
+-  gstreamer1.0-omx: 1.18.5 -> 1.18.6
+-  gstreamer1.0-plugins-bad: 1.18.5 -> 1.18.6
+-  gstreamer1.0-plugins-base: 1.18.5 -> 1.18.6
+-  gstreamer1.0-plugins-good: 1.18.5 -> 1.18.6
+-  gstreamer1.0-plugins-ugly: 1.18.5 -> 1.18.6
+-  gstreamer1.0-python: 1.18.5 -> 1.18.6
+-  gstreamer1.0-rtsp-server: 1.18.5 -> 1.18.6
+-  gstreamer1.0-vaapi: 1.18.5 -> 1.18.6
+-  gstreamer1.0: 1.18.5 -> 1.18.6
+-  harfbuzz: upgrade 2.9.0 -> 2.9.1
+-  initramfs-framework: unmount automounts before switch_root
+-  kernel-devsrc: do not copy Module.symvers file during install
+-  libarchive : update to 3.5.3
+-  libpcap: Disable DPDK explicitly
+-  libxml-parser-perl: Add missing RDEPENDS
+-  linux-firmware: upgrade 20211216 -> 20220209
+-  linux-yocto/5.10: Fix ramoops/ftrace
+-  linux-yocto/5.10: features/zram: remove CONFIG_ZRAM_DEF_COMP
+-  linux-yocto/5.10: fix dssall build error with binutils 2.3.8
+-  linux-yocto/5.10: ppc/riscv: fix build with binutils 2.3.8
+-  linux-yocto/5.10: update genericx86* machines to v5.10.99
+-  linux-yocto/5.10: update to v5.10.103
+-  mc: fix build if ncurses have been configured without wide characters
+-  oeqa/buildtools: Switch to our webserver instead of example.com
+-  patch.py: Prevent git repo reinitialization
+-  perl: Improve and update module RPDEPENDS
+-  poky.conf: bump version for 3.4.3 honister release
+-  qemuboot: Fix build error if UNINATIVE_LOADER is unset
+-  quilt: Disable external sendmail for deterministic build
+-  recipetool: Fix circular reference in SRC_URI
+-  releases: update to include 3.3.5
+-  releases: update to include 3.4.2
+-  rootfs-postcommands: amend systemd_create_users add user to group check
+-  ruby: update 3.0.2 -> 3.0.3
+-  scripts/runqemu-ifdown: Don't treat the last iptables command as special
+-  sdk: fix search for dynamic loader
+-  selftest: recipetool: Correct the URI for socat
+-  sstate: inside the threadedpool don't write to the shared localdata
+-  uninative: Upgrade to 3.5
+-  util-linux: upgrade to 2.37.4
+-  vim: Update to 8.2.4524 for further CVE fixes
+-  wic: Use custom kernel path if provided
+-  wireless-regdb: upgrade 2021.08.28 -> 2022.02.18
+-  zip: modify when match.S is built
+
+Contributors to 3.4.3
+~~~~~~~~~~~~~~~~~~~~~
+
+-  Alexander Kanavin
+-  Anuj Mittal
+-  Bill Pittman
+-  Bruce Ashfield
+-  Chee Yang Lee
+-  Christian Eggers
+-  Daniel Gomez
+-  Daniel Müller
+-  Daniel Wagenknecht
+-  Florian Amstutz
+-  Joe Slater
+-  Jose Quaresma
+-  Justin Bronder
+-  Lee Chee Yang
+-  Michael Halstead
+-  Michael Opdenacker
+-  Oleksandr Ocheretnyi
+-  Oleksandr Suvorov
+-  Pavel Zhukov
+-  Peter Kjellerstedt
+-  Richard Purdie
+-  Robert Yang
+-  Ross Burton
+-  Sakib Sajal
+-  Saul Wold
+-  Sean Anderson
+-  Stefan Herbrechtsmeier
+-  Tamizharasan Kumar
+-  Tean Cunningham
+-  Zoltán Böszörményi
+-  pgowda
+-  wangmy
+
+Repositories / Downloads for 3.4.3
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+poky
+
+-  Repository Location: https://git.yoctoproject.org/poky/
+-  Branch: :yocto_git:`honister </poky/log/?h=honister>`
+-  Tag: `yocto-3.4.3 <https://git.yoctoproject.org/poky/tag/?h=yocto-3.4.3>`__
+-  Git Revision: :yocto_git:`ee68ae307fd951b9de6b31dc6713ea29186b7749 </poky/commit/?id=ee68ae307fd951b9de6b31dc6713ea29186b7749>`
+-  Release Artefact: poky-ee68ae307fd951b9de6b31dc6713ea29186b7749
+-  sha: 92c3d73c3e74f0e1d5c2ab2836ce3a3accbe47772cea70df3755845e0db1379b
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-3.4.3/poky-ee68ae307fd951b9de6b31dc6713ea29186b7749.tar.bz2,
+   http://mirrors.kernel.org/yocto/yocto/yocto-3.4.3/poky-ee68ae307fd951b9de6b31dc6713ea29186b7749.tar.bz2
+
+openembedded-core
+
+-  Repository Location: :oe_git:`/openembedded-core`
+-  Branch: :oe_git:`honister </openembedded-core/log/?h=honister>`
+-  Tag: :oe_git:`yocto-3.4.3 </openembedded-core/tag/?h=yocto-3.4.3>`
+-  Git Revision: :oe_git:`ebca8f3ac9372b7ebb3d39e8f7f930b63b481448 </openembedded-core/commit/?id=ebca8f3ac9372b7ebb3d39e8f7f930b63b481448>`
+-  Release Artefact: oecore-ebca8f3ac9372b7ebb3d39e8f7f930b63b481448
+-  sha: f28e503f6f6c0bcd9192dbd528f8e3c7bcea504c089117e0094d9a4f315f4b9f
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-3.4.3/oecore-ebca8f3ac9372b7ebb3d39e8f7f930b63b481448.tar.bz2,
+   http://mirrors.kernel.org/yocto/yocto/yocto-3.4.3/oecore-ebca8f3ac9372b7ebb3d39e8f7f930b63b481448.tar.bz2
+
+meta-mingw
+
+-  Repository Location: https://git.yoctoproject.org/meta-mingw
+-  Branch: :yocto_git:`honister </meta-mingw/log/?h=honister>`
+-  Tag: :yocto_git:`yocto-3.4.3 </meta-mingw/tag/?h=yocto-3.4.3>`
+-  Git Revision: :yocto_git:`f5d761cbd5c957e4405c5d40b0c236d263c916a8 </meta-mingw/commit/?id=f5d761cbd5c957e4405c5d40b0c236d263c916a8>`
+-  Release Artefact: meta-mingw-f5d761cbd5c957e4405c5d40b0c236d263c916a8
+-  sha: d4305d638ef80948584526c8ca386a8cf77933dffb8a3b8da98d26a5c40fcc11
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-3.4.3/meta-mingw-f5d761cbd5c957e4405c5d40b0c236d263c916a8.tar.bz2,
+   http://mirrors.kernel.org/yocto/yocto/yocto-3.4.3/meta-mingw-f5d761cbd5c957e4405c5d40b0c236d263c916a8.tar.bz2
+
+meta-gplv2
+
+-  Repository Location: https://git.yoctoproject.org/meta-gplv2
+-  Branch: :yocto_git:`honister </meta-gplv2/log/?h=honister>`
+-  Tag: :yocto_git:`yocto-3.4.3 </meta-gplv2/tag/?h=yocto-3.4.3>`
+-  Git Revision: :yocto_git:`f04e4369bf9dd3385165281b9fa2ed1043b0e400 </meta-gplv2/commit/?id=f04e4369bf9dd3385165281b9fa2ed1043b0e400>`
+-  Release Artefact: meta-gplv2-f04e4369bf9dd3385165281b9fa2ed1043b0e400
+-  sha: ef8e2b1ec1fb43dbee4ff6990ac736315c7bc2d8c8e79249e1d337558657d3fe
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-3.4.3/meta-gplv2-f04e4369bf9dd3385165281b9fa2ed1043b0e400.tar.bz2,
+   http://mirrors.kernel.org/yocto/yocto/yocto-3.4.3/meta-gplv2-f04e4369bf9dd3385165281b9fa2ed1043b0e400.tar.bz2
+
+bitbake
+
+-  Repository Location: :oe_git:`/bitbake`
+-  Branch: :oe_git:`1.52 </bitbake/log/?h=1.52>`
+-  Tag: :oe_git:`yocto-3.4.3 </bitbake/tag/?h=yocto-3.4.3>`
+-  Git Revision: :oe_git:`43dcb2b2a2b95a5c959be57bca94fb7190ea6257 </bitbake/commit/?id=43dcb2b2a2b95a5c959be57bca94fb7190ea6257>`
+-  Release Artefact: bitbake-43dcb2b2a2b95a5c959be57bca94fb7190ea6257
+-  sha: 92497ff97fed81dcc6d3e202969fb63ca983a8f5d9d91cafc6aee88312f79cf9
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-3.4.3/bitbake-43dcb2b2a2b95a5c959be57bca94fb7190ea6257.tar.bz2,
+   http://mirrors.kernel.org/yocto/yocto/yocto-3.4.3/bitbake-43dcb2b2a2b95a5c959be57bca94fb7190ea6257.tar.bz2
+
+yocto-docs
+
+-  Repository Location: https://git.yoctoproject.org/yocto-docs
+-  Branch: :yocto_git:`honister </yocto-docs/log/?h=honister>`
+-  Tag: :yocto_git:`yocto-3.4.3 </yocto-docs/tag/?h=yocto-3.4.3>`
+-  Git Revision: :yocto_git:`15f46f97d9cad558c19fc1dc19cfbe3720271d04 </yocto-docs/commit/?15f46f97d9cad558c19fc1dc19cfbe3720271d04>`

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

@@ -0,0 +1,155 @@
+Release notes for 3.4.4 (honister)
+----------------------------------
+
+Security Fixes in 3.4.4
+~~~~~~~~~~~~~~~~~~~~~~~
+
+-  tiff: fix :cve:`2022-0865`, :cve:`2022-0891`, :cve:`2022-0907`, :cve:`2022-0908`, :cve:`2022-0909` and :cve:`2022-0924`
+-  xz: fix `CVE-2022-1271 <https://security-tracker.debian.org/tracker/CVE-2022-1271>`__
+-  unzip: fix `CVE-2021-4217 <https://security-tracker.debian.org/tracker/CVE-2021-4217>`__
+-  zlib: fix :cve:`2018-25032`
+-  grub: ignore :cve:`2021-46705`
+
+Fixes in 3.4.4
+~~~~~~~~~~~~~~
+
+-  alsa-tools: Ensure we install correctly
+-  bitbake.conf: mark all directories as safe for git to read
+-  bitbake: knotty: display active tasks when printing keepAlive() message
+-  bitbake: knotty: reduce keep-alive timeout from 5000s (83 minutes) to 10 minutes
+-  bitbake: server/process: Disable gc around critical section
+-  bitbake: server/xmlrpcserver: Add missing xmlrpcclient import
+-  bitbake: toaster: Fix IMAGE_INSTALL issues with _append vs :append
+-  bitbake: toaster: fixtures replace gatesgarth
+-  build-appliance-image: Update to honister head revision
+-  conf.py/poky.yaml: Move version information to poky.yaml and read in conf.py
+-  conf/machine: fix QEMU x86 sound options
+-  devupstream: fix handling of SRC_URI
+-  documentation: update for 3.4.4 release
+-  externalsrc/devtool: Fix to work with fixed export funcition flags handling
+-  gmp: add missing COPYINGv3
+-  gnu-config: update SRC_URI
+-  libxml2: fix CVE-2022-23308 regression
+-  libxml2: move to gitlab.gnome.org
+-  libxml2: update to 2.9.13
+-  libxshmfence: Correct LICENSE to HPND
+-  license_image.bbclass: close package.manifest file
+-  linux-firmware: correct license for ar3k firmware
+-  linux-firmware: upgrade 20220310 -> 20220411
+-  linux-yocto-rt/5.10: update to -rt61
+-  linux-yocto/5.10: cfg/debug: add configs for kcsan
+-  linux-yocto/5.10: split vtpm for more granular inclusion
+-  linux-yocto/5.10: update to v5.10.109
+-  linux-yocto: nohz_full boot arg fix
+-  oe-pkgdata-util: Adapt to the new variable override syntax
+-  oeqa/selftest/devtool: ensure Git username is set before upgrade tests
+-  poky.conf: bump version for 3.4.4 release
+-  pseudo: Add patch to workaround paths with crazy lengths
+-  pseudo: Fix handling of absolute links
+-  sanity: Add warning for local hasheqiv server with remote sstate mirrors
+-  scripts/runqemu: Fix memory limits for qemux86-64
+-  shadow-native: Simplify and fix syslog disable patch
+-  tiff: Add marker for CVE-2022-1056 being fixed
+-  toaster: Fix broken overrides usage
+-  u-boot: Inherit pkgconfig
+-  uninative: Upgrade to 3.6 with gcc 12 support
+-  vim: Upgrade 8.2.4524 -> 8.2.4681
+-  virglrenderer: update SRC_URI
+-  webkitgtk: update to 2.32.4
+-  wireless-regdb: upgrade 2022.02.18 -> 2022.04.08
+
+Known Issues
+~~~~~~~~~~~~
+
+There were a couple of known autobuilder intermittent bugs that occurred during release testing but these are not regressions in the release.
+
+Contributors to 3.4.4
+~~~~~~~~~~~~~~~~~~~~~
+
+-  Alexandre Belloni
+-  Anuj Mittal
+-  Bruce Ashfield
+-  Chee Yang Lee
+-  Dmitry Baryshkov
+-  Joe Slater
+-  Konrad Weihmann
+-  Martin Jansa
+-  Michael Opdenacker
+-  Minjae Kim
+-  Peter Kjellerstedt
+-  Ralph Siemsen
+-  Richard Purdie
+-  Ross Burton
+-  Tim Orling
+-  wangmy
+-  zhengruoqin
+
+Repositories / Downloads for 3.4.4
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+poky
+
+-  Repository Location: https://git.yoctoproject.org/poky/
+-  Branch: :yocto_git:`honister </poky/log/?h=honister>`
+-  Tag: `yocto-3.4.4 <https://git.yoctoproject.org/poky/tag/?h=yocto-3.4.4>`__
+-  Git Revision: :yocto_git:`780eeec8851950ee6ac07a2a398ba937206bd2e4 </poky/commit/?id=780eeec8851950ee6ac07a2a398ba937206bd2e4>`
+-  Release Artefact: poky-780eeec8851950ee6ac07a2a398ba937206bd2e4
+-  sha: 09558927064454ec2492da376156b716d9fd14aae57196435d742db7bfdb4b95
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-3.4.4/poky-780eeec8851950ee6ac07a2a398ba937206bd2e4.tar.bz2,
+   http://mirrors.kernel.org/yocto/yocto/yocto-3.4.4/poky-780eeec8851950ee6ac07a2a398ba937206bd2e4.tar.bz2
+
+openembedded-core
+
+-  Repository Location: :oe_git:`/openembedded-core`
+-  Branch: :oe_git:`honister </openembedded-core/log/?h=honister>`
+-  Tag: :oe_git:`yocto-3.4.4 </openembedded-core/tag/?h=yocto-3.4.4>`
+-  Git Revision: :oe_git:`1a6f5e27249afb6fb4d47c523b62b5dd2482a69d </openembedded-core/commit/?id=1a6f5e27249afb6fb4d47c523b62b5dd2482a69d>`
+-  Release Artefact: oecore-1a6f5e27249afb6fb4d47c523b62b5dd2482a69d
+-  sha: b8354ca457756384139a579b9e51f1ba854013c99add90c0c4c6ef68421fede5
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-3.4.4/oecore-1a6f5e27249afb6fb4d47c523b62b5dd2482a69d.tar.bz2,
+   http://mirrors.kernel.org/yocto/yocto/yocto-3.4.4/oecore-1a6f5e27249afb6fb4d47c523b62b5dd2482a69d.tar.bz2
+
+meta-mingw
+
+-  Repository Location: https://git.yoctoproject.org/meta-mingw
+-  Branch: :yocto_git:`honister </meta-mingw/log/?h=honister>`
+-  Tag: :yocto_git:`yocto-3.4.4 </meta-mingw/tag/?h=yocto-3.4.4>`
+-  Git Revision: :yocto_git:`f5d761cbd5c957e4405c5d40b0c236d263c916a8 </meta-mingw/commit/?id=f5d761cbd5c957e4405c5d40b0c236d263c916a8>`
+-  Release Artefact: meta-mingw-f5d761cbd5c957e4405c5d40b0c236d263c916a8
+-  sha: d4305d638ef80948584526c8ca386a8cf77933dffb8a3b8da98d26a5c40fcc11
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-3.4.4/meta-mingw-f5d761cbd5c957e4405c5d40b0c236d263c916a8.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-3.4.4/meta-mingw-f5d761cbd5c957e4405c5d40b0c236d263c916a8.tar.bz2
+
+meta-gplv2
+
+-  Repository Location: https://git.yoctoproject.org/meta-gplv2
+-  Branch: :yocto_git:`honister </meta-gplv2/log/?h=honister>`
+-  Tag: :yocto_git:`yocto-3.4.4 </meta-gplv2/tag/?h=yocto-3.4.4>`
+-  Git Revision: :yocto_git:`f04e4369bf9dd3385165281b9fa2ed1043b0e400 </meta-gplv2/commit/?id=f04e4369bf9dd3385165281b9fa2ed1043b0e400>`
+-  Release Artefact: meta-gplv2-f04e4369bf9dd3385165281b9fa2ed1043b0e400
+-  sha: ef8e2b1ec1fb43dbee4ff6990ac736315c7bc2d8c8e79249e1d337558657d3fe
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-3.4.4/meta-gplv2-f04e4369bf9dd3385165281b9fa2ed1043b0e400.tar.bz2,
+   http://mirrors.kernel.org/yocto/yocto/yocto-3.4.4/meta-gplv2-f04e4369bf9dd3385165281b9fa2ed1043b0e400.tar.bz2
+
+bitbake
+
+-  Repository Location: :oe_git:`/bitbake`
+-  Branch: :oe_git:`1.52 </bitbake/log/?h=1.52>`
+-  Tag: :oe_git:`yocto-3.4.4 </bitbake/tag/?h=yocto-3.4.3>`
+-  Git Revision: :oe_git:`c2d8f9b2137bd4a98eb0f51519493131773e7517 </bitbake/commit/?id=c2d8f9b2137bd4a98eb0f51519493131773e7517>`
+-  Release Artefact: bitbake-c2d8f9b2137bd4a98eb0f51519493131773e7517
+-  sha: a8b6217f2d63975bbf49f430e11046608023ee2827faa893b15d9a0d702cf833
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-3.4.4/bitbake-c2d8f9b2137bd4a98eb0f51519493131773e7517.tar.bz2,
+   http://mirrors.kernel.org/yocto/yocto/yocto-3.4.4/bitbake-c2d8f9b2137bd4a98eb0f51519493131773e7517.tar.bz2
+
+yocto-docs
+
+-  Repository Location: https://git.yoctoproject.org/yocto-docs
+-  Branch: :yocto_git:`honister </yocto-docs/log/?h=honister>`
+-  Tag: :yocto_git:`yocto-3.4.4 </yocto-docs/tag/?h=yocto-3.4.4>`
+-  Git Revision: :yocto_git:`5ead7d39aaf9044078dff27f462e29a8e31d89e4 </yocto-docs/commit/?5ead7d39aaf9044078dff27f462e29a8e31d89e4>`

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

@@ -5,7 +5,7 @@ New Features / Enhancements in 3.4
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 -  Linux kernel 5.14, glibc 2.34 and ~280 other recipe upgrades
--  Switched override character to ':' (replacing '_') for more robust parsing and improved performance - see the above migration guide for help
+-  Switched override character to ':' (replacing '_') for more robust parsing and improved performance --- see the above migration guide for help
 -  Rust integrated into core, providing rust support for cross-compilation and SDK
 -  New create-spdx class for creating SPDX SBoM documents
 -  New recipes: cargo, core-image-ptest-all, core-image-ptest-fast, core-image-weston-sdk, erofs-utils, gcompat, gi-docgen, libmicrohttpd, libseccomp, libstd-rs, perlcross, python3-markdown, python3-pyyaml, python3-smartypants, python3-typogrify, rust, rust-cross, rust-cross-canadian, rust-hello-world, rust-llvm, rust-tools-cross-canadian, rustfmt, xwayland

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

@@ -0,0 +1,248 @@
+Release notes for 4.0.1 (kirkstone)
+-----------------------------------
+
+Security Fixes in 4.0.1
+~~~~~~~~~~~~~~~~~~~~~~~
+
+-  linux-yocto/5.15: fix :cve:`2022-28796`
+-  python3: ignore :cve:`2015-20107`
+-  e2fsprogs: fix :cve:`2022-1304`
+-  lua: fix :cve:`2022-28805`
+-  busybox: fix :cve:`2022-28391`
+
+Fixes in 4.0.1
+~~~~~~~~~~~~~~
+
+-  abi_version/sstate: Bump hashequiv and sstate versions due to git changes
+-  apt: add apt selftest to test signed package feeds
+-  apt: upgrade 2.4.4 -> 2.4.5
+-  arch-armv8-2a.inc: fix a typo in TUNEVALID variable
+-  babeltrace: Disable warnings as errors
+-  base: Avoid circular references to our own scripts
+-  base: Drop git intercept
+-  build-appliance-image: Update to kirkstone head revision
+-  build-appliance: Switch to kirkstone branch
+-  buildtools-tarball: Only add cert envvars if certs are included
+-  busybox: Use base_bindir instead of hardcoding /bin path
+-  cases/buildepoxy.py: fix typo
+-  create-spdx: delete virtual/kernel dependency to fix FreeRTOS build
+-  create-spdx: fix error when symlink cannot be created
+-  cve-check: add JSON format to summary output
+-  cve-check: fix symlinks where link and output path are equal
+-  cve-check: no need to depend on the fetch task
+-  cve-update-db-native: let the user to drive the update interval
+-  cve-update-db-native: update the CVE database once a day only
+-  cve_check: skip remote patches that haven't been fetched when searching for CVE tags
+-  dev-manual: add command used to add the signed-off-by line.
+-  devshell.bbclass: Allow devshell & pydevshell to use the network
+-  docs: conf.py: fix cve extlinks caption for sphinx <4.0
+-  docs: migration-guides: migration-3.4: mention that hardcoded password are supported if hashed
+-  docs: migration-guides: release-notes-4.0: fix risc-v typo
+-  docs: migration-guides: release-notes-4.0: replace kernel placeholder with correct recipe name
+-  docs: ref-manual: variables: add hashed password example in EXTRA_USERS_PARAMS
+-  docs: set_versions.py: add information about obsolescence of a release
+-  docs: set_versions.py: fix latest release of a branch being shown twice in switchers.js
+-  docs: set_versions.py: fix latest version of an active release shown as obsolete
+-  docs: set_versions.py: mark as obsolete only branches and old tags from obsolete releases
+-  docs: sphinx-static: switchers.js.in: do not mark branches as outdated
+-  docs: sphinx-static: switchers.js.in: fix broken switcher for branches
+-  docs: sphinx-static: switchers.js.in: improve obsolete version detection
+-  docs: sphinx-static: switchers.js.in: remove duplicate for outdated versions
+-  docs: sphinx-static: switchers.js.in: rename all_versions to switcher_versions
+-  docs: update Bitbake objects.inv location for master branch
+-  documentation/brief-yoctoprojectqs: add directory for local.conf
+-  gcompat: Fix build when usrmerge distro feature is enabled
+-  git: correct license
+-  git: upgrade 2.35.2 -> 2.35.3
+-  glib: upgrade 2.72.0 -> 2.72.1
+-  glibc: ptest: Fix glibc-tests package issue
+-  gnupg: Disable FORTIFY_SOURCES on mips
+-  go.bbclass: disable the use of the default configuration file
+-  gstreamer1.0-plugins-bad: drop patch
+-  gstreamer1.0-plugins-good: Fix libsoup dependency
+-  gstreamer1.0: Minor documentation addition
+-  install/devshell: Introduce git intercept script due to fakeroot issues
+-  kernel-yocto.bbclass: Fixup do_kernel_configcheck usage of KMETA
+-  libc-glibc: Use libxcrypt to provide virtual/crypt
+-  libgit2: upgrade 1.4.2 -> 1.4.3
+-  libsoup: upgrade 3.0.5 -> 3.0.6
+-  libusb1: upgrade 1.0.25 -> 1.0.26
+-  linux-firmware: correct license for ar3k firmware
+-  linux-firmware: upgrade 20220310 -> 20220411
+-  linux-yocto/5.10: base: enable kernel crypto userspace API
+-  linux-yocto/5.10: update to v5.10.112
+-  linux-yocto/5.15: arm: poky-tiny cleanup and fixes
+-  linux-yocto/5.15: base: enable kernel crypto userspace API
+-  linux-yocto/5.15: fix -standard kernel build issue
+-  linux-yocto/5.15: fix ppc boot
+-  linux-yocto/5.15: fix qemuarm graphical boot
+-  linux-yocto/5.15: kasan: fix BUG: sleeping function called from invalid context
+-  linux-yocto/5.15: netfilter: conntrack: avoid useless indirection during conntrack destruction
+-  linux-yocto/5.15: update to v5.15.36
+-  linux-yocto: enable powerpc-debug fragment
+-  mdadm: Drop clang specific cflags
+-  migration-3.4: add missing entry on EXTRA_USERS_PARAMS
+-  migration-guides: add release notes for 4.0
+-  migration-guides: complete migration guide for 4.0
+-  migration-guides: release-notes-4.0: mention LTS release
+-  migration-guides: release-notes-4.0: update 'Repositories / Downloads' section
+-  migration-guides: stop including documents with ".. include"
+-  musl: Fix build when usrmerge distro feature is enabled
+-  ncurses: use COPYING file
+-  neard: Switch SRC_URI to git repo
+-  oeqa/selftest: add test for git working correctly inside pseudo
+-  openssl: minor security upgrade 3.0.2 -> 3.0.3
+-  package.bbclass: Prevent perform_packagecopy from removing /sysroot-only
+-  package: Ensure we track whether PRSERV was active or not
+-  package_manager: fix missing dependency on gnupg when signing deb package feeds
+-  poky-tiny: enable qemuarmv5/qemuarm64 and cleanups
+-  poky.conf: bump version for 4.0.1 release
+-  qemu.bbclass: Extend ppc/ppc64 extra options
+-  qemuarm64: use virtio pci interfaces
+-  qemuarmv5: use arm-versatile-926ejs KMACHINE
+-  ref-manual: Add XZ_THREADS and XZ_MEMLIMIT
+-  ref-manual: add KERNEL_DEBUG_TIMESTAMPS
+-  ref-manual: add ZSTD_THREADS
+-  ref-manual: add a note about hard-coded passwords
+-  ref-manual: add empty-dirs QA check and QA_EMPTY_DIRS*
+-  ref-manual: add mention of vendor filtering to CVE_PRODUCT
+-  ref-manual: mention wildcarding support in INCOMPATIBLE_LICENSE
+-  releases: update for yocto 4.0
+-  rootfs-postcommands: fix symlinks where link and output path are equal
+-  ruby: upgrade 3.1.1 -> 3.1.2
+-  sanity: skip make 4.2.1 warning for debian
+-  scripts/git: Ensure we don't have circular references
+-  scripts: Make git intercept global
+-  seatd: Disable overflow warning as error on ppc64/musl
+-  selftest/lic_checksum: Add test for filename containing space
+-  set_versions: update for 4.0 release
+-  staging: Ensure we filter out ourselves
+-  strace: fix ptest failure in landlock
+-  subversion: upgrade to 1.14.2
+-  systemd-boot: remove outdated EFI_LD comment
+-  systemtap: Fix build with gcc-12
+-  terminal.py: Restore error output from Terminal
+-  u-boot: Correct the SRC_URI
+-  u-boot: Inherit pkgconfig
+-  update_udev_hwdb: fix multilib issue with systemd
+-  util-linux: Create u-a symlink for findfs utility
+-  virgl: skip headless test on alma 8.6
+-  webkitgtk: adjust patch status
+-  wic: do not use PARTLABEL for msdos partition tables
+-  wireless-regdb: upgrade 2022.02.18 -> 2022.04.08
+-  xserver-xorg: Fix build with gcc12
+-  yocto-bsps: update to v5.15.36
+
+Contributors to 4.0.1
+~~~~~~~~~~~~~~~~~~~~~
+
+-  Abongwa Amahnui Bonalais
+-  Alexander Kanavin
+-  Bruce Ashfield
+-  Carlos Rafael Giani
+-  Chen Qi
+-  Davide Gardenal
+-  Dmitry Baryshkov
+-  Ferry Toth
+-  Henning Schild
+-  Jon Mason
+-  Justin Bronder
+-  Kai Kang
+-  Khem Raj
+-  Konrad Weihmann
+-  Lee Chee Yang
+-  Marta Rybczynska
+-  Martin Jansa
+-  Matt Madison
+-  Michael Halstead
+-  Michael Opdenacker
+-  Naveen Saini
+-  Nicolas Dechesne
+-  Paul Eggleton
+-  Paul Gortmaker
+-  Paulo Neves
+-  Peter Kjellerstedt
+-  Peter Marko
+-  Pgowda
+-  Portia
+-  Quentin Schulz
+-  Rahul Kumar
+-  Richard Purdie
+-  Robert Joslyn
+-  Robert Yang
+-  Roland Hieber
+-  Ross Burton
+-  Russ Dill
+-  Steve Sakoman
+-  wangmy
+-  zhengruoqin
+
+Repositories / Downloads for 4.0.1
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+poky
+
+-  Repository Location: https://git.yoctoproject.org/git/poky
+-  Branch: :yocto_git:`kirkstone </poky/log/?h=kirkstone>`
+-  Tag: :yocto_git:`yocto-4.0.1 </poky/tag/?h=yocto-4.0.1>`
+-  Git Revision: :yocto_git:`8c489602f218bcf21de0d3c9f8cf620ea5f06430 </poky/commit/?id=8c489602f218bcf21de0d3c9f8cf620ea5f06430>`
+-  Release Artefact: poky-8c489602f218bcf21de0d3c9f8cf620ea5f06430
+-  sha: 65c545a316bd8efb13ae1358eeccc8953543be908008103b51f7f90aed960d00
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.1/poky-8c489602f218bcf21de0d3c9f8cf620ea5f06430.tar.bz2,
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.1/poky-8c489602f218bcf21de0d3c9f8cf620ea5f06430.tar.bz2
+
+openembedded-core
+
+-  Repository Location: :oe_git:`/openembedded-core`
+-  Branch: :oe_git:`kirkstone </openembedded-core/log/?h=kirkstone>`
+-  Tag: :oe_git:`yocto-4.0.1 </openembedded-core/tag/?h=yocto-4.0>`
+-  Git Revision: :oe_git:`cb8647c08959abb1d6b7c2b3a34b4b415f66d7ee </openembedded-core/commit/?id=cb8647c08959abb1d6b7c2b3a34b4b415f66d7ee>`
+-  Release Artefact: oecore-cb8647c08959abb1d6b7c2b3a34b4b415f66d7ee
+-  sha: 43981b8fad82f601618a133dffbec839524f0d0a055efc3d8f808cbfd811ab17
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.1/oecore-cb8647c08959abb1d6b7c2b3a34b4b415f66d7ee.tar.bz2,
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.1/oecore-cb8647c08959abb1d6b7c2b3a34b4b415f66d7ee.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.1 </meta-mingw/tag/?h=yocto-4.0.1>`
+-  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.1/meta-mingw-a90614a6498c3345704e9611f2842eb933dc51c1.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.1/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.1 </meta-gplv2/tag/?h=yocto-4.0.1>`
+-  Git Revision: :yocto_git:`d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a </meta-mingw/commit/?id=d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a>`
+-  Release Artefact: meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a
+-  sha: c386f59f8a672747dc3d0be1d4234b6039273d0e57933eb87caa20f56b9cca6d
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.1/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.1/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2
+
+bitbake
+
+-  Repository Location: :oe_git:`/bitbake`
+-  Branch: :oe_git:`2.0 </bitbake/log/?h=2.0>`
+-  Tag: :oe_git:`yocto-4.0 </bitbake/tag/?h=yocto-4.0>`
+-  Git Revision: :oe_git:`59c16ae6c55c607c56efd2287537a1b97ba2bf52 </bitbake/commit/?id=59c16ae6c55c607c56efd2287537a1b97ba2bf52>`
+-  Release Artefact: bitbake-59c16ae6c55c607c56efd2287537a1b97ba2bf52
+-  sha: 3ae466c31f738fc45c3d7c6f665952d59f01697f2667ea42f0544d4298dd6ef0
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0.1/bitbake-59c16ae6c55c607c56efd2287537a1b97ba2bf52.tar.bz2,
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0.1/bitbake-59c16ae6c55c607c56efd2287537a1b97ba2bf52.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.1 </yocto-docs/tag/?h=yocto-4.0>`
+-  Git Revision: :yocto_git:`4ec9df3336a425719a9a35532504731ce56984ca </yocto-docs/commit/?id=4ec9df3336a425719a9a35532504731ce56984ca>`

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

@@ -0,0 +1,933 @@
+Release notes for 4.0 (kirkstone)
+---------------------------------
+
+This is a Long Term Support release, published in April 2022, and supported at least for two years (April 2024).
+
+New Features / Enhancements in 4.0
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+- Linux kernel 5.15, glibc 2.35 and ~300 other recipe upgrades
+
+- Reproducibility: this release fixes the reproducibility issues with ``rust-llvm`` and
+  ``golang``. Recipes in OpenEmbedded-Core are now fully reproducible. Functionality
+  previously in the optional "reproducible" class has been merged into the base class.
+
+- Network access is now disabled by default for tasks other than where it is expected to ensure build integrity (where host kernel supports it)
+
+- The Yocto Project now allows you to reuse the Shared State cache from
+  its autobuilder. If the network connection between our server and your
+  machine is faster than you would build recipes from source, you can
+  try to speed up your builds by using such Shared State and Hash
+  Equivalence by setting::
+
+     BB_SIGNATURE_HANDLER = "OEEquivHash"
+     BB_HASHSERVE = "auto"
+     BB_HASHSERVE_UPSTREAM = "typhoon.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.
+
+- New :ref:`overlayfs <ref-classes-overlayfs>` and
+  :ref:`overlayfs-etc <ref-classes-overlayfs-etc>` classes and
+  ``overlayroot`` support in the initramfs framework to make it easier to
+  overlay read-only filesystems (for example) with
+  `OverlayFS <https://en.wikipedia.org/wiki/OverlayFS>`__.
+
+- Inclusive language adjustments to some variable names - see the
+  :ref:`4.0 migration guide <migration-4.0-inclusive-language>` for details.
+  
+- New recipes:
+
+   - ``buildtools-docs-tarball``
+   - ``libptytty``
+   - ``libxcvt``
+   - ``lua``
+   - ``nghttp2``
+   - ``python3-alabaster``
+   - ``python3-asn1crypto``
+   - ``python3-babel``
+   - ``python3-bcrypt``
+   - ``python3-certifi``
+   - ``python3-cffi``
+   - ``python3-chardet``
+   - ``python3-cryptography``
+   - ``python3-cryptography-vectors``
+   - ``python3-dtschema``
+   - ``python3-flit-core``
+   - ``python3-idna``
+   - ``python3-imagesize``
+   - ``python3-installer``
+   - ``python3-iso8601``
+   - ``python3-jsonpointer``
+   - ``python3-jsonschema``
+   - ``python3-ndg-httpsclient``
+   - ``python3-ply``
+   - ``python3-poetry-core``
+   - ``python3-pretend``
+   - ``python3-psutil``
+   - ``python3-pyasn1``
+   - ``python3-pycparser``
+   - ``python3-pyopenssl``
+   - ``python3-pyrsistent``
+   - ``python3-pysocks``
+   - ``python3-pytest-runner``
+   - ``python3-pytest-subtests``
+   - ``python3-pytz``
+   - ``python3-requests``
+   - ``python3-rfc3339-validator``
+   - ``python3-rfc3986-validator``
+   - ``python3-rfc3987``
+   - ``python3-ruamel-yaml``
+   - ``python3-semantic-version``
+   - ``python3-setuptools-rust-native``
+   - ``python3-snowballstemmer``
+   - ``python3-sphinx``
+   - ``python3-sphinxcontrib-applehelp``
+   - ``python3-sphinxcontrib-devhelp``
+   - ``python3-sphinxcontrib-htmlhelp``
+   - ``python3-sphinxcontrib-jsmath``
+   - ``python3-sphinxcontrib-qthelp``
+   - ``python3-sphinxcontrib-serializinghtml``
+   - ``python3-sphinx-rtd-theme``
+   - ``python3-strict-rfc3339``
+   - ``python3-tomli``
+   - ``python3-typing-extensions``
+   - ``python3-urllib3``
+   - ``python3-vcversioner``
+   - ``python3-webcolors``
+   - ``python3-wheel``
+   - ``repo``
+   - ``seatd``
+
+- Extended recipes to ``native``: ``wayland``, ``wayland-protocols``
+
+- Shared state (sstate) improvements:
+
+   - Switched to `ZStandard (zstd) <https://en.wikipedia.org/wiki/Zstd>`__ instead
+     of Gzip, for better performance.
+   - Allow validation of sstate signatures against a list of keys
+   - Improved error messages and exception handling
+
+- BitBake enhancements:
+
+   - Fetcher enhancements:
+   
+      - New :ref:`bitbake:bitbake-user-manual/bitbake-user-manual-fetching:crate fetcher (\`\`crate://\`\`)` for Rust packages
+      - Added striplevel support to unpack
+      - git: Add a warning asking users to set a branch in git urls
+      - git: Allow git fetcher to support subdir param
+      - git: canonicalize ids in generated tarballs
+      - git: stop generated tarballs from leaking info
+      - npm: Put all downloaded files in the npm2 directory
+      - npmsw: Add support for duplicate dependencies without url
+      - npmsw: Add support for github prefix in npm shrinkwrap version
+      - ssh: now supports checkstatus, allows : in URLs (both required for use with sstate) and no longer requires username
+      - wget: add redirectauth parameter
+      - wget: add 30s timeout for checkstatus calls
+   
+   - Show warnings for append/prepend/remove operators combined with +=/.=
+   - Add bb.warnonce() and bb.erroronce() log methods
+   - Improved setscene task display
+   - Show elapsed time also for tasks with progress bars
+   - Improved cleanup on forced shutdown (either because of errors or Ctrl+C)
+   - contrib: Add Dockerfile for building PR service container
+   - Change file format of siginfo files to use zstd compressed json
+   - Display active tasks when printing keep-alive message to help debugging
+
+-  Architecture-specific enhancements:
+
+   - ARM:
+  
+      - tune-cortexa72: Enable the crc extension by default for cortexa72
+      - qemuarm64: Add tiny ktype to qemuarm64 bsp
+      - armv9a/tune: Add the support for the Neoverse N2 core
+      - arch-armv8-5a.inc: Add tune include for armv8.5a
+      - grub-efi: Add xen_boot support when 'xen' is in DISTRO_FEATURES for aarch64
+      - tune-cortexa73: Introduce cortexa73-crypto tune
+      - libacpi: Build libacpi also for 'aarch64' machines
+      - core-image-tiny-initramfs: Mark recipe as 32 bit ARM compatible
+
+   - PowerPC:
+
+      - weston-init: Use pixman rendering for qemuppc64
+      - rust: add support for big endian 64-bit PowerPC
+      - rust: Add snapshot checksums for powerpc64le
+
+   - RISC-V:
+
+      - libunwind: Enable for rv64
+      - systemtap: Enable for riscv64
+      - linux-yocto-dev: add qemuriscv32
+      - packagegroup-core-tools-profile: Enable systemtap for riscv64
+      - qemuriscv: Use virtio-tablet-pci for mouse
+  
+   - x86:
+
+      - kernel-yocto: conditionally enable stack protection checking on x86-64
+
+-  Kernel-related enhancements:
+
+   - Allow initramfs to be built from a separate multiconfig
+   - Make kernel-base recommend kernel-image, not depend (allowing images containing kernel modules without kernel image)
+   - linux-yocto: split vtpm for more granular inclusion
+   - linux-yocto: cfg/debug: add configs for kcsan
+   - linux-yocto: cfg: add kcov feature fragment
+   - linux-yocto: export pkgconfig variables to devshell
+   - linux-yocto-dev: use versioned branch as default
+   - New ``KERNEL_DEBUG_TIMESTAMPS`` variable (to replace removed ``BUILD_REPRODUCIBLE_BINARIES`` for the kernel)
+   - Introduce python3-dtschema-wrapper in preparation for mandatory schema checking on dtb files in 5.16
+   - Allow disabling kernel artifact symlink creation
+   - Allow changing default .bin kernel artifact extension
+
+- FIT image related enhancements:
+
+   - New ``FIT_SUPPORTED_INITRAMFS_FSTYPES`` variable to allow extending initramfs image types to look for
+   - New ``FIT_CONF_PREFIX`` variable to allow overriding FIT configuration prefix
+   - Use 'bbnote' for better logging
+
+- New :term:`PACKAGECONFIG` options in ``curl``, ``dtc``, ``epiphany``, ``git``, ``git``, ``gstreamer1.0-plugins-bad``, ``linux-yocto-dev``, ``kmod``, ``mesa``, ``piglit``, ``qemu``, ``rpm``, ``systemd``, ``webkitgtk``, ``weston-init``
+- ptest enhancements in ``findutils``, ``lttng-tools``, ``openssl``, ``gawk``, ``strace``, ``lttng-tools``, ``valgrind``, ``perl``, ``libxml-parser-perl``, ``openssh``, ``python3-cryptography``, ``popt``
+
+- Sysroot dependencies have been further optimised
+- Significant effort to upstream / rationalise patches across a variety of recipes
+- Allow the creation of block devices on top of UBI volumes
+- archiver: new ARCHIVER_MODE[compression] to set tarball compression, and switch default to xz
+- yocto-check-layer: add ability to perform tests from a global bbclass
+- yocto-check-layer: improved README checks
+- cve-check: add json output format
+- cve-check: add coverage statistics on recipes with/without CVEs
+- Added mirrors for kernel sources and uninative binaries on kernel.org 
+- glibc and binutils recipes now use shallow mirror tarballs for faster fetching
+- When patching fails, show more information on the fatal error
+
+-  wic Image Creator enhancements:
+
+  - Support rootdev identified by partition label
+  - rawcopy: Add support for packed images
+  - partition: Support valueless keys in sourceparams
+
+- QA check enhancements:
+
+   - Allow treating license issues as errors
+   - Added a check that Upstream-Status patch tag is present and correctly formed
+   - Added a check for directories that are expected to be empty
+   - Ensure addition of patch-fuzz retriggers do_qa_patch
+   - Added a sanity check for allarch packagegroups
+
+- create-spdx class improvements:
+
+   - Get SPDX-License-Identifier from source files
+   - Generate manifest also for SDKs
+   - New SPDX_ORG variable to allow changing the Organization field value
+   - Added packageSupplier field
+   - Added create_annotation function
+
+- devtool add / recipetool create enhancements:
+
+   - Extend curl detection when creating recipes
+   - Handle GitLab URLs like we do GitHub
+   - Recognize more standard license text variants
+   - Separate licenses with & operator
+   - Detect more known licenses in Python code
+   - Move license md5sums data into CSV files
+   - npm: Use README as license fallback
+   
+- SDK-related enhancements:
+
+   - Extended recipes to ``nativesdk``: ``cargo``, ``librsvg``, ``libstd-rs``, ``libva``, ``python3-docutil``, ``python3-packaging``
+   - Enabled nativesdk recipes to find a correct version of the rust cross compiler
+   - Support creating per-toolchain cmake file in SDK
+
+- Rust enhancements:
+   
+   - New python_setuptools3_rust class to enable building python extensions in Rust
+   - classes/meson: Add optional rust definitions
+
+- QEMU / runqemu enhancements:
+
+   - qemu: Add knob for enabling PMDK pmem support
+   - qemu: add tpm string section to qemu acpi table
+   - qemu: Build on musl targets
+   - runqemu: support rootfs mounted ro
+   - runqemu: add :term:`DEPLOY_DIR_IMAGE` replacement in QB_OPT_APPEND
+   - runqemu: Allow auto-detection of the correct graphics options
+
+- Capped ``cpu_count()`` (used to set parallelisation defaults) to 64 since any higher usually hurts parallelisation
+- Adjust some GL-using recipes so that they only require virtual/egl
+- package_rpm: use zstd instead of xz
+- npm: new ``EXTRA_OENPM`` variable (to set node-gyp variables for example)
+- npm: new ``NPM_NODEDIR`` variable
+- perl: Enable threading
+- u-boot: Convert ${UBOOT_ENV}.cmd into ${UBOOT_ENV}.scr
+- u-boot: Split do_configure logic into separate file
+- go.bbclass: Allow adding parameters to go ldflags
+- go: log build id computations
+- scons: support out-of-tree builds
+- scripts: Add a conversion script to use SPDX license names
+- scripts: Add convert-variable-renames script for inclusive language variable renaming
+- binutils-cross-canadian: enable gold for mingw
+- grub-efi: Add option to include all available modules
+- bitbake.conf: allow wayland distro feature through for native/SDK builds
+- weston-init: Pass --continue-without-input when launching weston
+- weston: wrapper for weston modules argument
+- weston: Add a knob to control simple clients
+- uninative: Add version to uninative tarball name
+- volatile-binds: SELinux and overlayfs extensions in mount-copybind
+- gtk-icon-cache: Allow using gtk4
+- kmod: Add an exclude directive to depmod
+- os-release: add os-release-initrd package for use in systemd-based initramfs images
+- gstreamer1.0-plugins-base: add support for graphene
+- gpg-sign: Add parameters to gpg signature function
+- package_manager: sign DEB package feeds
+- zstd: add libzstd package
+- libical: build gobject and vala introspection
+- dhcpcd: add option to set DBDIR location
+- rpcbind: install rpcbind.conf
+- mdadm: install mdcheck
+- boost: add json lib
+- libxkbcommon: allow building of API documentation
+- libxkbcommon: split libraries and xkbcli into separate packages
+- systemd: move systemd shared library into its own package
+- systemd: Minimize udev package size if DISTRO_FEATURES doen't contain sysvinit
+
+Known Issues in 4.0
+~~~~~~~~~~~~~~~~~~~
+
+- ``make`` version 4.2.1 is known to be buggy on non-Ubuntu systems. If this ``make``
+  version is detected on host distributions other than Ubuntu at build start time,
+  then a warning will be displayed.
+
+Recipe License changes in 4.0
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The following corrections have been made to the LICENSE values set by recipes:
+
+* cmake: add BSD-1-Clause & MIT & BSD-2-Clause to LICENSE due to additional vendored libraries in native/target context
+* gettext: extend LICENSE conditional upon PACKAGECONFIG (due to vendored libraries)
+* gstreamer1.0: update licenses of all modules to LGPL-2.1-or-later (with some exceptions that are GPL-2.0-or-later)
+* gstreamer1.0-plugins-bad/ugly: use the GPL-2.0-or-later only when it is in use
+* kern-tools-native: add missing MIT license due to Kconfiglib
+* libcap: add pam_cap license to LIC_FILES_CHKSUM if pam is enabled
+* libidn2: add Unicode-DFS-2016 license
+* libsdl2: add BSD-2-Clause to LICENSE due to default yuv2rgb and hidapi inclusion
+* libx11-compose-data: update LICENSE to "MIT & MIT-style & BSD-1-Clause & HPND & HPND-sell-variant" to better reflect reality
+* libx11: update LICENSE to "MIT & MIT-style & BSD-1-Clause & HPND & HPND-sell-variant" to better reflect reality
+* libxshmfence: correct LICENSE - MIT -> HPND
+* newlib: add BSD-3-Clause to LICENSE
+* python3-idna: correct LICENSE - Unicode -> Unicode-TOU
+* python3-pip: add "Apache-2.0 & MPL-2.0 & LGPL-2.1-only & BSD-3-Clause & PSF-2.0 & BSD-2-Clause" to LICENSE due to vendored libraries
+
+Other license-related notes:
+
+- The ambiguous "BSD" license has been removed from the ``common-licenses`` directory.
+  Each recipe that fetches or builds BSD-licensed code should specify the proper
+  version of the BSD license in its :term:`LICENSE` value.
+
+- :term:`LICENSE` definitions now have to use `SPDX identifiers <https://spdx.org/licenses/>`__.
+  A :oe_git:`convert-spdx-licenses.py </openembedded-core/tree/scripts/contrib/convert-spdx-licenses.py>`
+  script can be used to update your recipes.
+
+
+
+Security Fixes in 4.0
+~~~~~~~~~~~~~~~~~~~~~
+
+- binutils: :cve:`2021-42574`, :cve:`2021-45078`
+- curl: :cve:`2021-22945`, :cve:`2021-22946`, :cve:`2021-22947`
+- epiphany: :cve:`2021-45085`, :cve:`2021-45086`, :cve:`2021-45087`, :cve:`2021-45088`
+- expat: :cve:`2021-45960`, :cve:`2021-46143`, :cve:`2022-22822`, :cve:`2022-22823`, :cve:`2022-22824`, :cve:`2022-22825`, :cve:`2022-22826`, :cve:`2022-22827`, :cve:`2022-23852`, :cve:`2022-23990`, :cve:`2022-25235`, :cve:`2022-25236`, :cve:`2022-25313`, :cve:`2022-25314`, :cve:`2022-25315`
+- ffmpeg: :cve:`2021-38114`
+- gcc: :cve:`2021-35465`, :cve:`2021-42574`, :cve:`2021-46195`, :cve:`2022-24765`
+- glibc: :cve:`2021-3998`, :cve:`2021-3999`, :cve:`2021-43396`, :cve:`2022-23218`, :cve:`2022-23219`
+- gmp: :cve:`2021-43618`
+- go: :cve:`2021-41771` and :cve:`2021-41772`
+- grub2: :cve:`2021-3981`
+- gzip: :cve:`2022-1271`
+- libarchive : :cve:`2021-31566`, :cve:`2021-36976`
+- libxml2: :cve:`2022-23308`
+- libxslt: :cve:`2021-30560`
+- lighttpd: :cve:`2022-22707`
+- linux-yocto/5.10: amdgpu: :cve:`2021-42327`
+- lua: :cve:`2021-43396`
+- openssl: :cve:`2021-4044`, :cve:`2022-0778`
+- qemu: :cve:`2022-1050`, :cve:`2022-26353`, :cve:`2022-26354`
+- rpm: :cve:`2021-3521`
+- seatd: :cve:`2022-25643`
+- speex: :cve:`2020-23903`
+- squashfs-tools: :cve:`2021-41072`
+- systemd: :cve:`2021-4034`
+- tiff: :cve:`2022-0561`, :cve:`2022-0562`, :cve:`2022-0865`, :cve:`2022-0891`, :cve:`2022-0907`, :cve:`2022-0908`, :cve:`2022-0909`, :cve:`2022-0924`, :cve:`2022-1056`, :cve:`2022-22844`
+- unzip: :cve:`2021-4217`
+- vim: :cve:`2021-3796`, :cve:`2021-3872`, :cve:`2021-3875`, :cve:`2021-3927`, :cve:`2021-3928`, :cve:`2021-3968`, :cve:`2021-3973`, :cve:`2021-4187`, :cve:`2022-0128`, :cve:`2022-0156`, :cve:`2022-0158`, :cve:`2022-0261`, :cve:`2022-0318`, :cve:`2022-0319`, :cve:`2022-0554`, :cve:`2022-0696`, :cve:`2022-0714`, :cve:`2022-0729`, :cve:`2022-0943`
+- virglrenderer: :cve:`2022-0135`, :cve:`2022-0175`
+- webkitgtk: :cve:`2022-22589`, :cve:`2022-22590`, :cve:`2022-22592`
+- xz: :cve:`2022-1271`
+- zlib: :cve:`2018-25032`
+
+
+
+Recipe Upgrades in 4.0
+~~~~~~~~~~~~~~~~~~~~~~
+
+- acpica: upgrade 20210730 -> 20211217
+- acpid: upgrade 2.0.32 -> 2.0.33
+- adwaita-icon-theme: update 3.34/38 -> 41.0
+- alsa-ucm-conf: upgrade 1.2.6.2 -> 1.2.6.3
+- alsa: upgrade 1.2.5 -> 1.2.6
+- apt: upgrade 2.2.4 -> 2.4.3
+- asciidoc: upgrade 9.1.0 -> 10.0.0
+- atk: upgrade 2.36.0 -> 2.38.0
+- at-spi2-core: upgrade 2.40.3 -> 2.42.0
+- at: update 3.2.2 -> 3.2.5
+- autoconf-archive: upgrade 2021.02.19 -> 2022.02.11
+- automake: update 1.16.3 -> 1.16.5
+- bash: upgrade 5.1.8 -> 5.1.16
+- bind: upgrade 9.16.20 -> 9.18.1
+- binutils: Bump to latest 2.38 release branch
+- bison: upgrade 3.7.6 -> 3.8.2
+- bluez5: upgrade 5.61 -> 5.64
+- boost: update 1.77.0 -> 1.78.0
+- btrfs-tools: upgrade 5.13.1 -> 5.16.2
+- buildtools-installer: Update to use 3.4
+- busybox: 1.34.0 -> 1.35.0
+- ca-certificates: update 20210119 -> 20211016
+- cantarell-fonts: update 0.301 -> 0.303.1
+- ccache: upgrade 4.4 -> 4.6
+- cmake: update 3.21.1 -> 3.22.3
+- connman: update 1.40 -> 1.41
+- coreutils: update 8.32 -> 9.0
+- cracklib: update 2.9.5 -> 2.9.7
+- createrepo-c: upgrade 0.17.4 -> 0.19.0
+- cronie: upgrade 1.5.7 -> 1.6.0
+- cups: update 2.3.3op2 -> 2.4.1
+- curl: update 7.78.0 -> 7.82.0
+- dbus: upgrade 1.12.20 -> 1.14.0
+- debianutils: update 4.11.2 -> 5.7
+- dhcpcd: upgrade 9.4.0 -> 9.4.1
+- diffoscope: upgrade 181 -> 208
+- dnf: upgrade 4.8.0 -> 4.11.1
+- dpkg: update 1.20.9 ->  1.21.4
+- e2fsprogs: upgrade 1.46.4 -> 1.46.5
+- ed: upgrade 1.17 -> 1.18
+- efivar: update 37 -> 38
+- elfutils: update 0.185 -> 0.186
+- ell: upgrade 0.43 -> 0.49
+- enchant2: upgrade 2.3.1 -> 2.3.2
+- epiphany: update 40.3 -> 42.0
+- erofs-utils: update 1.3 -> 1.4
+- ethtool: update to 5.16
+- expat: upgrade 2.4.1 -> 2.4.7
+- ffmpeg: update 4.4 -> 5.0
+- file: upgrade 5.40 -> 5.41
+- findutils: upgrade 4.8.0 -> 4.9.0
+- flac: upgrade 1.3.3 -> 1.3.4
+- freetype: upgrade 2.11.0 -> 2.11.1
+- fribidi: upgrade 1.0.10 -> 1.0.11
+- gawk: update 5.1.0 -> 5.1.1
+- gcompat: Update to latest
+- gdbm: upgrade 1.19 -> 1.23
+- gdb: Upgrade to 11.2
+- ghostscript: update 9.54.0 -> 9.55.0
+- gi-docgen: upgrade 2021.7 -> 2022.1
+- git: update 2.33.0 -> 2.35.2
+- glib-2.0: update 2.68.4 -> 2.72.0
+- glibc: Upgrade to 2.35
+- glib-networking: update 2.68.2 -> 2.72.0
+- glslang: update 11.5.0 -> 11.8.0
+- gnu-config: update to latest revision
+- gnupg: update 2.3.1 -> 2.3.4
+- gnutls: update 3.7.2 -> 3.7.4
+- gobject-introspection: upgrade 1.68.0 -> 1.72.0
+- go-helloworld: update to latest revision
+- go: update 1.16.7 -> 1.17.8
+- gpgme: upgrade 1.16.0 -> 1.17.1
+- gsettings-desktop-schemas: upgrade 40.0 -> 42.0
+- gst-devtools: 1.18.4 -> 1.20.1
+- gst-examples: 1.18.4 -> 1.18.6
+- gstreamer1.0: 1.18.4 -> 1.20.1
+- gstreamer1.0-libav: 1.18.4 -> 1.20.1
+- gstreamer1.0-omx: 1.18.4 -> 1.20.1
+- gstreamer1.0-plugins-bad: 1.18.4  1.20.1
+- gstreamer1.0-plugins-base: 1.18.4 -> 1.20.1
+- gstreamer1.0-plugins-good: 1.18.4 -> 1.20.1
+- gstreamer1.0-plugins-ugly: 1.18.4 -> 1.20.1
+- gstreamer1.0-python: 1.18.4 -> 1.20.1
+- gstreamer1.0-rtsp-server: 1.18.4 -> 1.20.1
+- gstreamer1.0-vaapi: 1.18.4 -> 1.20.1
+- gtk+3: upgrade 3.24.30 -> 3.24.33
+- gzip: upgrade 1.10 -> 1.12
+- harfbuzz: upgrade 2.9.0 -> 4.0.1
+- hdparm: upgrade 9.62 -> 9.63
+- help2man: upgrade 1.48.4 -> 1.49.1
+- icu: update 69.1 -> 70.1
+- ifupdown: upgrade 0.8.36 -> 0.8.37
+- inetutils: update 2.1 -> 2.2
+- init-system-helpers: upgrade 1.60 -> 1.62
+- iproute2: update to 5.17.0
+- iputils: update 20210722 to 20211215
+- iso-codes: upgrade 4.6.0 -> 4.9.0
+- itstool: update 2.0.6 -> 2.0.7
+- iw: upgrade 5.9 -> 5.16
+- json-glib: upgrade 1.6.4 -> 1.6.6
+- kea: update 1.8.2 -> 2.0.2
+- kexec-tools: update 2.0.22 -> 2.0.23
+- less: upgrade 590 -> 600
+- libarchive: upgrade 3.5.1 -> 3.6.1
+- libatomic-ops: upgrade 7.6.10 -> 7.6.12
+- libbsd: upgrade 0.11.3 -> 0.11.5
+- libcap: update 2.51 -> 2.63
+- libcgroup: upgrade 2.0 -> 2.0.1
+- libcomps: upgrade 0.1.17 -> 0.1.18
+- libconvert-asn1-perl: upgrade 0.31 -> 0.33
+- libdazzle: upgrade 3.40.0 -> 3.44.0
+- libdnf: update 0.63.1 -> 0.66.0
+- libdrm: upgrade 2.4.107 -> 2.4.110
+- libedit: upgrade 20210714-3.1 -> 20210910-3.1
+- liberation-fonts: update 2.1.4 -> 2.1.5
+- libevdev: upgrade 1.11.0 -> 1.12.1
+- libexif: update 0.6.22 -> 0.6.24
+- libgit2: update 1.1.1 -> 1.4.2
+- libgpg-error: update 1.42 -> 1.44
+- libhandy: update 1.2.3 -> 1.5.0
+- libical: upgrade 3.0.10 -> 3.0.14
+- libinput: update to 1.19.3
+- libjitterentropy: update 3.1.0 -> 3.4.0
+- libjpeg-turbo: upgrade 2.1.1 -> 2.1.3
+- libmd: upgrade 1.0.3 -> 1.0.4
+- libmicrohttpd: upgrade 0.9.73 -> 0.9.75
+- libmodulemd: upgrade 2.13.0 -> 2.14.0
+- libpam: update 1.5.1 -> 1.5.2
+- libpcre2: upgrade 10.37 -> 10.39
+- libpipeline: upgrade 1.5.3 -> 1.5.5
+- librepo: upgrade 1.14.1 -> 1.14.2
+- librsvg: update 2.40.21 -> 2.52.7
+- libsamplerate0: update 0.1.9 -> 0.2.2
+- libsdl2: update 2.0.16 -> 2.0.20
+- libseccomp: update to 2.5.3
+- libsecret: upgrade 0.20.4 -> 0.20.5
+- libsndfile1: bump to version 1.0.31
+- libsolv: upgrade 0.7.19 -> 0.7.22
+- libsoup-2.4: upgrade 2.72.0 -> 2.74.2
+- libsoup: add a recipe for 3.0.5
+- libssh2: update 1.9.0 -> 1.10.0
+- libtasn1: upgrade 4.17.0 -> 4.18.0
+- libtool: Upgrade 2.4.6 -> 2.4.7
+- libucontext: Upgrade to 1.2 release
+- libunistring: update 0.9.10 -> 1.0
+- libunwind: upgrade 1.5.0 -> 1.6.2
+- liburcu: upgrade 0.13.0 -> 0.13.1
+- libusb1: upgrade 1.0.24 -> 1.0.25
+- libuv: update 1.42.0 -> 1.44.1
+- libva: update 2.12.0 -> 2.14.0
+- libva-utils: upgrade 2.13.0 -> 2.14.0
+- libwebp: 1.2.1 -> 1.2.2
+- libwpe: upgrade 1.10.1 -> 1.12.0
+- libx11: update to 1.7.3.1
+- libxcrypt: upgrade 4.4.26 -> 4.4.27
+- libxcrypt-compat: upgrade 4.4.26 -> 4.4.27
+- libxi: update to 1.8
+- libxkbcommon: update to 1.4.0
+- libxml2: update to 2.9.13
+- libxslt: update to v1.1.35
+- lighttpd: update 1.4.59 -> 1.4.64
+- linux-firmware: upgrade 20210818 -> 20220310
+- linux-libc-headers: update to v5.16
+- linux-yocto/5.10: update to v5.10.109
+- linux-yocto/5.15: introduce recipes (v5.15.32)
+- linux-yocto-dev: update to v5.18+
+- linux-yocto-rt/5.10: update to -rt61
+- linux-yocto-rt/5.15: update to -rt34
+- llvm: update 12.0.1 -> 13.0.1
+- logrotate: update 3.18.1 -> 3.19.0
+- lsof: update 4.91 -> 4.94.0
+- ltp: update 20210927 -> 20220121
+- ltp: Update to 20210927
+- lttng-modules: update devupstream to latest 2.13
+- lttng-modules: update to 2.13.3
+- lttng-tools: upgrade 2.13.0 -> 2.13.4
+- lttng-ust: upgrade 2.13.0 -> 2.13.2
+- lua: update 5.3.6 -> 5.4.4
+- lzip: upgrade 1.22 -> 1.23
+- man-db: upgrade 2.9.4 -> 2.10.2
+- man-pages: update to 5.13
+- mdadm: update 4.1 -> 4.2
+- mesa: upgrade 21.2.1 -> 22.0.0
+- meson: update 0.58.1 -> 0.61.3
+- minicom: Upgrade 2.7.1 -> 2.8
+- mmc-utils: upgrade to latest revision
+- mobile-broadband-provider-info: upgrade 20210805 -> 20220315
+- mpg123: upgrade 1.28.2 -> 1.29.3
+- msmtp: upgrade 1.8.15 -> 1.8.20
+- mtd-utils: upgrade 2.1.3 -> 2.1.4
+- mtools: upgrade 4.0.35 -> 4.0.38
+- musl: Update to latest master
+- ncurses: update 6.2 -> 6.3
+- newlib: Upgrade 4.1.0 -> 4.2.0
+- nfs-utils: upgrade 2.5.4 -> 2.6.1
+- nghttp2: upgrade 1.45.1 -> 1.47.0
+- ofono: upgrade 1.32 -> 1.34
+- opensbi: Upgrade to 1.0
+- openssh: upgrade 8.7p1 -> 8.9
+- openssl: update 1.1.1l -> 3.0.2
+- opkg: upgrade 0.4.5 -> 0.5.0
+- opkg-utils: upgrade 0.4.5 -> 0.5.0
+- ovmf: update 202105 -> 202202
+- p11-kit: update 0.24.0 -> 0.24.1
+- pango: upgrade 1.48.9 -> 1.50.4
+- patchelf: upgrade 0.13 -> 0.14.5
+- perl-cross: update 1.3.6 -> 1.3.7
+- perl: update 5.34.0 -> 5.34.1
+- piglit: upgrade to latest revision
+- pigz: upgrade 2.6 -> 2.7
+- pinentry: update 1.1.1 -> 1.2.0
+- pkgconfig: Update to latest
+- psplash: upgrade to latest revision
+- puzzles: upgrade to latest revision
+- python3-asn1crypto: upgrade 1.4.0 -> 1.5.1
+- python3-attrs: upgrade 21.2.0 -> 21.4.0
+- python3-cryptography: Upgrade to 36.0.2
+- python3-cryptography-vectors: upgrade to 36.0.2
+- python3-cython: upgrade 0.29.24 -> 0.29.28
+- python3-dbusmock: update to 0.27.3
+- python3-docutils: upgrade 0.17.1 0.18.1
+- python3-dtschema: upgrade 2021.10 -> 2022.1
+- python3-gitdb: upgrade 4.0.7 -> 4.0.9
+- python3-git: update to 3.1.27
+- python3-hypothesis: upgrade 6.15.0 -> 6.39.5
+- python3-imagesize: upgrade 1.2.0 -> 1.3.0
+- python3-importlib-metadata: upgrade 4.6.4 -> 4.11.3
+- python3-jinja2: upgrade 3.0.1 -> 3.1.1
+- python3-jsonschema: upgrade 3.2.0 -> 4.4.0
+- python3-libarchive-c: upgrade 3.1 -> 4.0
+- python3-magic: upgrade 0.4.24 -> 0.4.25
+- python3-mako: upgrade 1.1.5 -> 1.1.6
+- python3-markdown: upgrade 3.3.4 -> 3.3.6
+- python3-markupsafe: upgrade 2.0.1 -> 2.1.1
+- python3-more-itertools: upgrade 8.8.0 -> 8.12.0
+- python3-numpy: upgrade 1.21.2 -> 1.22.3
+- python3-packaging: upgrade 21.0 -> 21.3
+- python3-pathlib2: upgrade 2.3.6 -> 2.3.7
+- python3-pbr: upgrade 5.6.0 -> 5.8.1
+- python3-pip: update 21.2.4 -> 22.0.3
+- python3-pycairo: upgrade 1.20.1 -> 1.21.0
+- python3-pycryptodome: upgrade 3.10.1 -> 3.14.1
+- python3-pyelftools: upgrade 0.27 -> 0.28
+- python3-pygments: upgrade 2.10.0 -> 2.11.2
+- python3-pygobject: upgrade 3.40.1 -> 3.42.0
+- python3-pyparsing: update to 3.0.7
+- python3-pyrsistent: upgrade 0.18.0 -> 0.18.1
+- python3-pytest-runner: upgrade 5.3.1 -> 6.0.0
+- python3-pytest-subtests: upgrade 0.6.0 -> 0.7.0
+- python3-pytest: upgrade 6.2.4 -> 7.1.1
+- python3-pytz: upgrade 2021.3 -> 2022.1
+- python3-py: upgrade 1.10.0 -> 1.11.0
+- python3-pyyaml: upgrade 5.4.1 -> 6.0
+- python3-ruamel-yaml: upgrade 0.17.16 -> 0.17.21
+- python3-scons: upgrade 4.2.0 -> 4.3.0
+- python3-setuptools-scm: upgrade 6.0.1 -> 6.4.2
+- python3-setuptools: update to 59.5.0
+- python3-smmap: update to 5.0.0
+- python3-tomli: upgrade 1.2.1 -> 2.0.1
+- python3: update to 3.10.3
+- python3-urllib3: upgrade 1.26.8 -> 1.26.9
+- python3-zipp: upgrade 3.5.0 -> 3.7.0
+- qemu: update 6.0.0 -> 6.2.0
+- quilt: upgrade 0.66 -> 0.67
+- re2c: upgrade 2.2 -> 3.0
+- readline: upgrade 8.1 -> 8.1.2
+- repo: upgrade 2.17.3 -> 2.22
+- resolvconf: update 1.87 -> 1.91
+- rng-tools: upgrade 6.14 -> 6.15
+- rpcsvc-proto: upgrade 1.4.2 -> 1.4.3
+- rpm: update 4.16.1.3 -> 4.17.0
+- rt-tests: update 2.1 -> 2.3
+- ruby: update 3.0.2 -> 3.1.1
+- rust: update 1.54.0 -> 1.59.0
+- rxvt-unicode: upgrade 9.26 -> 9.30
+- screen: upgrade 4.8.0 -> 4.9.0
+- shaderc: update 2021.1 -> 2022.1
+- shadow: upgrade 4.9 -> 4.11.1
+- socat: upgrade 1.7.4.1 -> 1.7.4.3
+- spirv-headers: bump to b42ba6 revision
+- spirv-tools: update 2021.2 -> 2022.1
+- sqlite3: upgrade 3.36.0 -> 3.38.2
+- strace: update 5.14 -> 5.16
+- stress-ng: upgrade 0.13.00 -> 0.13.12
+- sudo: update 1.9.7p2 -> 1.9.10
+- sysklogd: upgrade 2.2.3 -> 2.3.0
+- sysstat: upgrade 12.4.3 -> 12.4.5
+- systemd: update 249.3 -> 250.4
+- systemtap: upgrade 4.5 -> 4.6
+- sysvinit: upgrade 2.99 -> 3.01
+- tzdata: update to 2022a
+- u-boot: upgrade 2021.07 -> 2022.01
+- uninative: Upgrade to 3.6 with gcc 12 support
+- util-linux: update 2.37.2 -> 2.37.4
+- vala: upgrade 0.52.5 -> 0.56.0
+- valgrind: update 3.17.0 -> 3.18.1
+- vim: upgrade to 8.2 patch 4681
+- vte: upgrade 0.64.2 -> 0.66.2
+- vulkan-headers: upgrade 1.2.182 -> 1.2.191
+- vulkan-loader: upgrade 1.2.182 -> 1.2.198.1
+- vulkan-samples: update to latest revision
+- vulkan-tools: upgrade 1.2.182 -> 1.2.191
+- vulkan: update 1.2.191.0 -> 1.3.204.1
+- waffle: update 1.6.1 -> 1.7.0
+- wayland-protocols: upgrade 1.21 -> 1.25
+- wayland: upgrade 1.19.0 -> 1.20.0
+- webkitgtk: upgrade 2.34.0 -> 2.36.0
+- weston: upgrade 9.0.0 -> 10.0.0
+- wget: update 1.21.1 -> 1.21.3
+- wireless-regdb: upgrade 2021.07.14 -> 2022.02.18
+- wpa-supplicant: update 2.9 -> 2.10
+- wpebackend-fdo: upgrade 1.10.0 -> 1.12.0
+- xauth: upgrade 1.1 -> 1.1.1
+- xf86-input-libinput: update to 1.2.1
+- xf86-video-intel: update to latest commit
+- xkeyboard-config: update to 2.35.1
+- xorgproto: update to 2021.5
+- xserver-xorg: update 1.20.13 -> 21.1.3
+- xwayland: update 21.1.2 -> 22.1.0
+- xxhash: upgrade 0.8.0 -> 0.8.1
+- zstd: update 1.5.0 -> 1.5.2
+
+
+
+Contributors to 4.0
+~~~~~~~~~~~~~~~~~~~
+
+Thanks to the following people who contributed to this release:
+
+- Abongwa Amahnui Bonalais
+- Adriaan Schmidt
+- Adrian Freihofer
+- Ahmad Fatoum
+- Ahmed Hossam
+- Ahsan Hussain
+- Alejandro Hernandez Samaniego
+- Alessio Igor Bogani
+- Alexander Kanavin
+- Alexandre Belloni
+- Alexandru Ardelean
+- Alexey Brodkin
+- Alex Stewart
+- Andreas Müller
+- Andrei Gherzan
+- Andrej Valek
+- Andres Beltran
+- Andrew Jeffery
+- Andrey Zhizhikin
+- Anton Mikanovich
+- Anuj Mittal
+- Bill Pittman
+- Bruce Ashfield
+- Caner Altinbasak
+- Carlos Rafael Giani
+- Chaitanya Vadrevu
+- Changhyeok Bae
+- Changqing Li
+- Chen Qi
+- Christian Eggers
+- Claudius Heine
+- Claus Stovgaard
+- Daiane Angolini
+- Daniel Ammann
+- Daniel Gomez
+- Daniel McGregor
+- Daniel Müller
+- Daniel Wagenknecht
+- David Joyner
+- David Reyna
+- Denys Dmytriyenko
+- Dhruva Gole
+- Diego Sueiro
+- Dmitry Baryshkov
+- Ferry Toth
+- Florian Amstutz
+- Henry Kleynhans
+- He Zhe
+- Hongxu Jia
+- Hsia-Jun(Randy) Li
+- Ian Ray
+- Jacob Kroon
+- Jagadeesh Krishnanjanappa
+- Jasper Orschulko
+- Jim Wilson
+- Joel Winarske
+- Joe Slater
+- Jon Mason
+- Jose Quaresma
+- Joshua Watt
+- Justin Bronder
+- Kai Kang
+- Kamil Dziezyk
+- Kevin Hao
+- Khairul Rohaizzat Jamaluddin
+- Khem Raj
+- Kiran Surendran
+- Konrad Weihmann
+- Kory Maincent
+- Lee Chee Yang
+- Leif Middelschulte
+- Lei Maohui
+- Li Wang
+- Liwei Song
+- Luca Boccassi
+- Lukasz Majewski
+- Luna Gräfje
+- Manuel Leonhardt
+- Marek Vasut
+- Mark Hatle
+- Markus Niebel
+- Markus Volk
+- Marta Rybczynska
+- Martin Beeger
+- Martin Jansa
+- Matthias Klein
+- Matt Madison
+- Maximilian Blenk
+- Max Krummenacher
+- Michael Halstead
+- Michael Olbrich
+- Michael Opdenacker
+- Mike Crowe
+- Ming Liu
+- Mingli Yu
+- Minjae Kim
+- Nicholas Sielicki
+- Olaf Mandel
+- Oleh Matiusha
+- Oleksandr Kravchuk
+- Oleksandr Ocheretnyi
+- Oleksandr Suvorov
+- Oleksiy Obitotskyy
+- Otavio Salvador
+- Pablo Saavedra
+- Paul Barker
+- Paul Eggleton
+- Pavel Zhukov
+- Peter Hoyes
+- Peter Kjellerstedt
+- Petr Vorel
+- Pgowda
+- Quentin Schulz
+- Ralph Siemsen
+- Randy Li
+- Randy MacLeod
+- Rasmus Villemoes
+- Ricardo Salveti
+- Richard Neill
+- Richard Purdie
+- Robert Joslyn
+- Robert P. J. Day
+- Robert Yang
+- Ross Burton
+- Rudolf J Streif
+- Sakib Sajal
+- Samuli Piippo
+- Saul Wold
+- Scott Murray
+- Sean Anderson
+- Simone Weiss
+- Simon Kuhnle
+- S. Lockwood-Childs
+- Stefan Herbrechtsmeier
+- Steve Sakoman
+- Sundeep KOKKONDA
+- Tamizharasan Kumar
+- Tean Cunningham
+- Teoh Jay Shen
+- Thomas Perrot
+- Tim Orling
+- Tobias Kaufmann
+- Tom Hochstein
+- Tony McDowell
+- Trevor Gamblin
+- Ulrich Ölmann
+- Valerii Chernous
+- Vivien Didelot
+- Vyacheslav Yurkov
+- Wang Mingyu
+- Xavier Berger
+- Yi Zhao
+- Yongxin Liu
+- Yureka
+- Zev Weiss
+- Zheng Ruoqin
+- Zoltán Böszörményi
+- Zygmunt Krynicki
+
+
+
+Repositories / Downloads for 4.0
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+
+poky
+
+-  Repository Location: https://git.yoctoproject.org/git/poky
+-  Branch: :yocto_git:`kirkstone </poky/log/?h=kirkstone>`
+-  Tag: :yocto_git:`yocto-4.0 </poky/tag/?h=yocto-4.0>`
+-  Git Revision: :yocto_git:`00cfdde791a0176c134f31e5a09eff725e75b905 </poky/commit/?id=00cfdde791a0176c134f31e5a09eff725e75b905>`
+-  Release Artefact: poky-00cfdde791a0176c134f31e5a09eff725e75b905
+-  sha: 4cedb491b7bf0d015768c61690f30d7d73f4266252d6fba907bba97eac83648c
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0/poky-00cfdde791a0176c134f31e5a09eff725e75b905.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0/poky-00cfdde791a0176c134f31e5a09eff725e75b905.tar.bz2
+
+openembedded-core
+
+-  Repository Location: :oe_git:`/openembedded-core`
+-  Branch: :oe_git:`kirkstone </openembedded-core/log/?h=kirkstone>`
+-  Tag: :oe_git:`yocto-4.0 </openembedded-core/tag/?h=yocto-4.0>`
+-  Git Revision: :oe_git:`92fcb6570bddd0c5717d8cfdf38ecf3e44942b0f </openembedded-core/commit/?id=92fcb6570bddd0c5717d8cfdf38ecf3e44942b0f>`
+-  Release Artefact: oecore-92fcb6570bddd0c5717d8cfdf38ecf3e44942b0f
+-  sha: c042629752543a10b0384b2076b1ee8742fa5e8112aef7b00b3621f8387a51c6
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0/oecore-92fcb6570bddd0c5717d8cfdf38ecf3e44942b0f.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0/oecore-92fcb6570bddd0c5717d8cfdf38ecf3e44942b0f.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 </meta-mingw/tag/?h=yocto-4.0>`
+-  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/meta-mingw-a90614a6498c3345704e9611f2842eb933dc51c1.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0/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 </meta-gplv2/tag/?h=yocto-4.0>`
+-  Git Revision: :yocto_git:`d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a </meta-mingw/commit/?id=d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a>`
+-  Release Artefact: meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a
+-  sha: c386f59f8a672747dc3d0be1d4234b6039273d0e57933eb87caa20f56b9cca6d
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0/meta-gplv2-d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a.tar.bz2
+
+bitbake
+
+-  Repository Location: :oe_git:`/bitbake`
+-  Branch: :oe_git:`2.0 </bitbake/log/?h=2.0>`
+-  Tag: :oe_git:`yocto-4.0 </bitbake/tag/?h=yocto-4.0>`
+-  Git Revision: :oe_git:`c212b0f3b542efa19f15782421196b7f4b64b0b9 </bitbake/commit/?id=c212b0f3b542efa19f15782421196b7f4b64b0b9>`
+-  Release Artefact: bitbake-c212b0f3b542efa19f15782421196b7f4b64b0b9
+-  sha: 6872095c7d7be5d791ef3e18b6bab2d1e0e237962f003d2b00dc7bd6fb6d2ef7
+-  Download Locations:
+   http://downloads.yoctoproject.org/releases/yocto/yocto-4.0/bitbake-c212b0f3b542efa19f15782421196b7f4b64b0b9.tar.bz2
+   http://mirrors.kernel.org/yocto/yocto/yocto-4.0/bitbake-c212b0f3b542efa19f15782421196b7f4b64b0b9.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 </yocto-docs/tag/?h=yocto-4.0>`
+-  Git Revision: :yocto_git:`a6f571ad5b087385cad8765ed455c4b4eaeebca6 </yocto-docs/commit/?id=a6f571ad5b087385cad8765ed455c4b4eaeebca6>`
+

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 Autotools uses.
-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 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.
 
 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 Curated Layer Index </software-overview/layers/>`
+:yocto_home:`Yocto Project Compatible 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
-   :align: center
+   :width: 100%
 
 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
-   :align: center
+   :width: 100%
 
 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 that yourself. The ``auto.conf`` file is typically
+you need to create it yourself. The ``auto.conf`` file is typically
 created by an autobuilder:
 
 -  *site.conf:* You can use the ``conf/site.conf`` configuration
@@ -321,17 +321,7 @@ 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.
-
-   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.
+   :term:`PACKAGE_CLASSES` variable.
 
 -  *auto.conf:* The file is usually created and written to by an
    autobuilder. The settings put into the file are typically the same as
@@ -401,6 +391,7 @@ 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,
@@ -551,6 +542,7 @@ area of the :ref:`general workflow figure <overview-manual/concepts:openembedded
 
 .. image:: figures/source-input.png
    :align: center
+   :width: 70%
 
 Upstream Project Releases
 ~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -565,7 +557,7 @@ Local Projects
 ~~~~~~~~~~~~~~
 
 Local projects are custom bits of software the user provides. These bits
-reside somewhere local to a project - perhaps a directory into which the
+reside somewhere local to a project --- perhaps a directory into which the
 user checks in items (e.g. a local directory containing a development
 source tree used by the group).
 
@@ -629,7 +621,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
-   :align: center
+   :width: 100%
 
 Package feeds are an intermediary step in the build process. The
 OpenEmbedded build system provides classes to generate different package
@@ -702,7 +694,7 @@ The first stages of building a recipe are to fetch and unpack the source
 code:
 
 .. image:: figures/source-fetching.png
-   :align: center
+   :width: 100%
 
 The :ref:`ref-tasks-fetch` and
 :ref:`ref-tasks-unpack` tasks fetch
@@ -790,7 +782,7 @@ Once source code is fetched and unpacked, BitBake locates patch files
 and applies them to the source files:
 
 .. image:: figures/patching.png
-   :align: center
+   :width: 100%
 
 The :ref:`ref-tasks-patch` task uses a
 recipe's :term:`SRC_URI` statements
@@ -831,7 +823,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
-   :align: center
+   :width: 100%
 
 This step in the build process consists of the following tasks:
 
@@ -889,7 +881,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
-   :align: center
+   :width: 100%
 
 The :ref:`ref-tasks-package` and
 :ref:`ref-tasks-packagedata`
@@ -968,7 +960,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
-   :align: center
+   :width: 100%
 
 The image generation process consists of several stages and depends on
 several tasks and variables. The
@@ -1086,7 +1078,7 @@ Development Kit (SDK) installer scripts for both the standard SDK and
 the extensible SDK (eSDK):
 
 .. image:: figures/sdk-generation.png
-   :align: center
+   :width: 100%
 
 .. note::
 
@@ -1262,6 +1254,7 @@ this output:
 
 .. image:: figures/images.png
    :align: center
+   :width: 75%
 
 .. note::
 
@@ -1321,7 +1314,7 @@ SDK (e.g. ``bitbake -c populate_sdk_ext`` imagename) or a standard SDK
 closer look at this output:
 
 .. image:: figures/sdk.png
-   :align: center
+   :width: 100%
 
 The specific form of this output is a set of files that includes a
 self-extracting SDK installer (``*.sh``), host and target manifest
@@ -1439,7 +1432,7 @@ The following figure shows a high-level build environment regarding
 toolchain construction and use.
 
 .. image:: figures/cross-development-toolchains.png
-   :align: center
+   :width: 100%
 
 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
@@ -1648,7 +1641,7 @@ you a good idea of when the task's data changes.
 
 To complicate the problem, there are things that should not be included
 in the checksum. First, there is the actual specific build path of a
-given task - the :term:`WORKDIR`. It
+given task --- the :term:`WORKDIR`. It
 does not matter if the work directory changes because it should not
 affect the output for target packages. Also, the build process has the
 objective of making native or cross packages relocatable.
@@ -1707,7 +1700,7 @@ need to fix this situation.
 Thus far, this section has limited discussion to the direct inputs into
 a task. Information based on direct inputs is referred to as the
 "basehash" in the code. However, the question of a task's indirect
-inputs still exits - items already built and present in the
+inputs still exits --- items already built and present in the
 :term:`Build Directory`. The checksum (or
 signature) for a particular task needs to add the hashes of all the
 tasks on which the particular task depends. Choosing which dependencies
@@ -2146,7 +2139,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

@@ -52,7 +52,7 @@ A development host or :term:`Build Host` is key to
 using the Yocto Project. Because the goal of the Yocto Project is to
 develop images or applications that run on embedded hardware,
 development of those images and applications generally takes place on a
-system not intended to run the software - the development host.
+system not intended to run the software --- the development host.
 
 You need to set up a development host in order to use it with the Yocto
 Project. Most find that it is best to have a native Linux machine
@@ -176,7 +176,7 @@ development:
    repositories for each of these areas.
 
    .. image:: figures/source-repos.png
-      :align: center
+      :width: 100%
 
    For steps on how to view and access these upstream Git repositories,
    see the ":ref:`dev-manual/start:accessing source repositories`"
@@ -191,6 +191,7 @@ 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`"
@@ -205,7 +206,7 @@ development:
    :yocto_dl:`Index of /releases: </releases>` area.
 
    .. image:: figures/yp-download.png
-      :align: center
+      :width: 100%
 
    For steps on how to use the "DOWNLOADS" page, see the
    ":ref:`dev-manual/start:using the downloads page`"
@@ -616,13 +617,9 @@ 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. MIT is also compatible with
-the GNU General Public License (GPL). Patches to the Yocto Project
+license is distributed with that software. Patches to the Yocto Project
 follow the upstream licensing scheme. You can find information on the
-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>`__.
+MIT license `here <https://en.wikipedia.org/wiki/MIT_License>`__.
 
 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
-    :align: center
+    :width: 100%
 
 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 curated layer index</software-overview/layers/>`
-      or the :oe_layerindex:`OpenEmbedded layer index <>`.
+      :yocto_home:`Yocto Project Compatible Layers </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
-    :align: center
+    :width: 100%
 
 -  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
-`layers <overview-manual/yp-intro:the yocto project layer model>` that extend
+these base image types by adding metadata :ref:`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
-    :align: center
+    :width: 100%
 
 Following is a brief summary of the "workflow":
 
@@ -842,7 +842,7 @@ helpful for getting started:
    distribution.
 
    Another point worth noting is that historically within the Yocto
-   Project, recipes were referred to as packages - thus, the existence
+   Project, recipes were referred to as packages --- thus, the existence
    of several BitBake variables that are seemingly mis-named, (e.g.
    :term:`PR`,
    :term:`PV`, and

documentation/poky.yaml.in

@@ -1,10 +1,10 @@
-DISTRO : "3.4.3"
-DISTRO_NAME_NO_CAP : "honister"
-DISTRO_NAME : "Honister"
-DISTRO_NAME_NO_CAP_MINUS_ONE : "hardknott"
+DISTRO : "4.0"
+DISTRO_NAME_NO_CAP : "kirkstone"
+DISTRO_NAME : "Kirkstone"
+DISTRO_NAME_NO_CAP_MINUS_ONE : "honister"
 DISTRO_NAME_NO_CAP_LTS : "dunfell"
-YOCTO_DOC_VERSION : "3.4.3"
-DISTRO_REL_TAG : "yocto-3.4.3"
+YOCTO_DOC_VERSION : "4.0"
+DISTRO_REL_TAG : "yocto-4.0"
 DOCCONF_VERSION : "dev"
 BITBAKE_SERIES : ""
 YOCTO_DL_URL : "https://downloads.yoctoproject.org"
@@ -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/intro.rst

@@ -7,7 +7,7 @@ Yocto Project Profiling and Tracing Manual
 Introduction
 ============
 
-Yocto bundles a number of tracing and profiling tools - this 'HOWTO'
+Yocto bundles a number of tracing and profiling tools --- this 'HOWTO'
 describes their basic usage and shows by example how to make use of them
 to examine application and system behavior.
 
@@ -26,7 +26,7 @@ please see the documentation and/or websites listed for each tool.
 
 The final section of this 'HOWTO' is a collection of real-world examples
 which we'll be continually adding to as we solve more problems using the
-tools - feel free to add your own examples to the list!
+tools --- feel free to add your own examples to the list!
 
 General Setup
 =============

documentation/profile-manual/usage.rst

@@ -17,7 +17,7 @@ The 'perf' tool is the profiling and tracing tool that comes bundled
 with the Linux kernel.
 
 Don't let the fact that it's part of the kernel fool you into thinking
-that it's only for tracing and profiling the kernel - you can indeed use
+that it's only for tracing and profiling the kernel --- you can indeed use
 it to trace and profile just the kernel, but you can also use it to
 profile specific applications separately (with or without kernel
 context), and you can also use it to trace and profile the kernel and
@@ -176,7 +176,7 @@ interactive text-based UI (or simply as text if we specify ``--stdio`` to
 
 As our first attempt at profiling this workload, we'll simply run 'perf
 record', handing it the workload we want to profile (everything after
-'perf record' and any perf options we hand it - here none - will be
+'perf record' and any perf options we hand it --- here none, will be
 executed in a new shell). perf collects samples until the process exits
 and records them in a file named 'perf.data' in the current working
 directory. ::
@@ -197,12 +197,13 @@ 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
 profiling run, ordered from the most popular to the least (perf has
 options to sort in various orders and keys as well as display entries
-only above a certain threshold and so on - see the perf documentation
+only above a certain threshold and so on --- see the perf documentation
 for details). Note that this includes both userspace functions (entries
 containing a [.]) and kernel functions accounted to the process (entries
 containing a [k]). (perf has command-line modifiers that can be used to
@@ -230,6 +231,7 @@ 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
@@ -266,6 +268,7 @@ 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
@@ -283,6 +286,7 @@ 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.
@@ -330,6 +334,7 @@ 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
@@ -337,6 +342,7 @@ 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
@@ -344,6 +350,7 @@ 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
@@ -354,6 +361,7 @@ 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.
@@ -362,6 +370,7 @@ 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
@@ -370,6 +379,7 @@ 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'.
@@ -593,11 +603,12 @@ 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
 paths to sched_wakeup (note that sched_wakeup is the name of the
-tracepoint - it's actually defined just inside ttwu_do_wakeup(), which
+tracepoint --- it's actually defined just inside ttwu_do_wakeup(), which
 accounts for the function name actually displayed in the profile:
 
 .. code-block:: c
@@ -740,7 +751,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:
 
@@ -859,14 +870,14 @@ 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
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 The examples so far have focused on tracing a particular program or
-workload - in other words, every profiling run has specified the program
+workload --- in other words, every profiling run has specified the program
 to profile in the command-line e.g. 'perf record wget ...'.
 
 It's also possible, and more interesting in many cases, to run a
@@ -894,6 +905,7 @@ 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
@@ -911,6 +923,7 @@ record a profile::
 
 .. image:: figures/perf-report-cycles-u.png
    :align: center
+   :width: 70%
 
 Notice in the screenshot above, we see only userspace entries ([.])
 
@@ -921,6 +934,7 @@ 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::
@@ -950,7 +964,7 @@ Filtering
 Notice that there are a lot of events that don't really have anything to
 do with what we're interested in, namely events that schedule 'perf'
 itself in and out or that wake perf up. We can get rid of those by using
-the '--filter' option - for each event we specify using -e, we can add a
+the '--filter' option --- for each event we specify using -e, we can add a
 --filter after that to filter out trace events that contain fields with
 specific values::
 
@@ -1116,11 +1130,12 @@ 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
 
    The trace events subsystem accommodate static and dynamic tracepoints
-   in exactly the same way - there's no difference as far as the
+   in exactly the same way --- there's no difference as far as the
    infrastructure is concerned. See the ftrace section for more details
    on the trace event subsystem.
 
@@ -1149,7 +1164,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>`__.
@@ -1186,7 +1201,7 @@ For this section, we'll assume you've already performed the basic setup
 outlined in the ":ref:`profile-manual/intro:General Setup`" section.
 
 ftrace, trace-cmd, and kernelshark run on the target system, and are
-ready to go out-of-the-box - no additional setup is necessary. For the
+ready to go out-of-the-box --- no additional setup is necessary. For the
 rest of this section we assume you've ssh'ed to the host and will be
 running ftrace on the target. kernelshark is a GUI application and if
 you use the '-X' option to ssh you can have the kernelshark GUI run on
@@ -1306,7 +1321,7 @@ great way to learn about how the kernel code works in a dynamic sense.
    ftrace:function tracepoint.
 
 It is a little more difficult to follow the call chains than it needs to
-be - luckily there's a variant of the function tracer that displays the
+be --- luckily there's a variant of the function tracer that displays the
 callchains explicitly, called the 'function_graph' tracer::
 
    root@sugarbay:/sys/kernel/debug/tracing# echo function_graph > current_tracer
@@ -1684,6 +1699,7 @@ 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
@@ -1699,6 +1715,7 @@ 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
@@ -1710,12 +1727,14 @@ 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
@@ -1974,6 +1993,7 @@ 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.
@@ -1988,6 +2008,7 @@ 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.
@@ -1999,6 +2020,7 @@ 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.
@@ -2116,7 +2138,7 @@ You can now view the trace in text form on the target::
    .
 
 You can now safely destroy the trace
-session (note that this doesn't delete the trace - it's still there in
+session (note that this doesn't delete the trace --- it's still there in
 ~/lttng-traces)::
 
    root@crownbay:~# lttng destroy
@@ -2200,7 +2222,7 @@ You can now view the trace in text form on the target::
    .
 
 You can now safely destroy the trace session (note that this doesn't delete the
-trace - it's still there in ~/lttng-traces)::
+trace --- it's still there in ~/lttng-traces)::
 
    root@crownbay:~# lttng destroy
    Session auto-20190303-021943 destroyed at /home/root
@@ -2535,7 +2557,7 @@ Execute the workload you're interested in::
    root@crownbay:/sys/kernel/debug/tracing# cat /media/sdc/testfile.txt
 
 And look at the output (note here that we're using 'trace_pipe' instead of
-trace to capture this trace - this allows us to wait around on the pipe
+trace to capture this trace --- this allows us to wait around on the pipe
 for data to appear)::
 
    root@crownbay:/sys/kernel/debug/tracing# cat trace_pipe

documentation/ref-manual/classes.rst

@@ -78,7 +78,8 @@ about the variable flags (varflags) that help control archive creation.
 ``autotools*.bbclass``
 ======================
 
-The ``autotools*`` classes support Autotooled packages.
+The ``autotools*`` classes support packages built with the
+`GNU Autotools <https://en.wikipedia.org/wiki/GNU_Autotools>`__.
 
 The ``autoconf``, ``automake``, and ``libtool`` packages bring
 standardization. This class defines a set of tasks (e.g. ``configure``,
@@ -107,18 +108,18 @@ support is either not present or is broken.
 It's useful to have some idea of how the tasks defined by the
 ``autotools*`` classes work and what they do behind the scenes.
 
--  :ref:`ref-tasks-configure` - Regenerates the
+-  :ref:`ref-tasks-configure` --- regenerates the
    configure script (using ``autoreconf``) and then launches it with a
    standard set of arguments used during cross-compilation. You can pass
    additional parameters to ``configure`` through the :term:`EXTRA_OECONF`
    or :term:`PACKAGECONFIG_CONFARGS`
    variables.
 
--  :ref:`ref-tasks-compile` - Runs ``make`` with
+-  :ref:`ref-tasks-compile` --- runs ``make`` with
    arguments that specify the compiler and linker. You can pass
    additional arguments through the :term:`EXTRA_OEMAKE` variable.
 
--  :ref:`ref-tasks-install` - Runs ``make install`` and
+-  :ref:`ref-tasks-install` --- runs ``make install`` and
    passes in ``${``\ :term:`D`\ ``}`` as ``DESTDIR``.
 
 .. _ref-classes-base:
@@ -576,6 +577,14 @@ Finally, here is an example that sets the root password::
        usermod -p '${PASSWD}' root; \
        "
 
+.. note::
+
+   From a security perspective, hardcoding a default password is not
+   generally a good idea or even legal in some jurisdictions. It is 
+   recommended that you do not do this if you are building a production 
+   image.
+
+
 .. _ref-classes-features_check:
 
 ``features_check.bbclass``
@@ -1032,6 +1041,11 @@ Here are the tests you can list with the :term:`WARN_QA` and
    cases, such as dynamically loaded modules, these symlinks
    are needed instead in the main package.
 
+-  ``empty-dirs:`` Checks that packages are not installing files to
+   directories that are normally expected to be empty (such as ``/tmp``)
+   The list of directories that are checked is specified by the
+   :term:`QA_EMPTY_DIRS` variable.
+
 -  ``file-rdeps:`` Checks that file-level dependencies identified by
    the OpenEmbedded build system at packaging time are satisfied. For
    example, a shell script might start with the line ``#!/bin/bash``.
@@ -1986,9 +2000,7 @@ The ``python_pep517`` class builds and installs a Python ``wheel`` binary
 archive (see `PEP-517 <https://peps.python.org/pep-0517/>`__).
 
 Recipes wouldn't inherit this directly, instead typically another class will
-inherit this, add the relevant native dependencies, and set
-:term:`PEP517_BUILD_API` to the Python class which implements the PEP-517 build
-API.
+inherit this and add the relevant native dependencies.
 
 Examples of classes which do this are :ref:`python_flit_core
 <ref-classes-python_flit_core>`, :ref:`python_setuptools_build_meta

documentation/ref-manual/devtool-reference.rst

@@ -126,8 +126,7 @@ common working area used across the tool.
 The following figure shows the workspace structure:
 
 .. image:: figures/build-workspace-directory.png
-   :align: center
-   :scale: 70%
+   :scale: 100%
 
 .. code-block:: none
 
@@ -165,7 +164,7 @@ Adding a New Recipe to the Workspace Layer
 ==========================================
 
 Use the ``devtool add`` command to add a new recipe to the workspace
-layer. The recipe you add should not exist - ``devtool`` creates it for
+layer. The recipe you add should not exist --- ``devtool`` creates it for
 you. The source files the recipe uses should exist in an external area.
 
 The following example creates and adds a new recipe named ``jackson`` to

documentation/ref-manual/faq.rst

@@ -22,7 +22,7 @@ Can I still use the Yocto Project?
 **A:** You can get the required tools on your host development system a
 couple different ways (i.e. building a tarball or downloading a
 tarball). See the
-":ref:`ref-manual/system-requirements:required git, tar, python and gcc versions`"
+":ref:`ref-manual/system-requirements:required git, tar, python, make and gcc versions`"
 section for steps on how to update your build tools.
 
 **Q:** How can you claim Poky / OpenEmbedded-Core is stable?
@@ -364,7 +364,7 @@ redirect requests through proxy servers.
 
 **Q:** Can I get rid of build output so I can start over?
 
-**A:** Yes - you can easily do this. When you use BitBake to build an
+**A:** Yes --- you can easily do this. When you use BitBake to build an
 image, all the build output goes into the directory created when you run
 the build environment setup script (i.e.
 :ref:`structure-core-script`). By default, this :term:`Build Directory`
@@ -428,7 +428,7 @@ relatively normal and the second is not:
       build/tmp/sysroots/x86_64-linux/usr/bin
 
 Even if the paths look unusual,
-they both are correct - the first for a target and the second for a
+they both are correct --- the first for a target and the second for a
 native recipe. These paths are a consequence of the ``DESTDIR``
 mechanism and while they appear strange, they are correct and in
 practice very effective.

documentation/ref-manual/features.rst

@@ -100,7 +100,9 @@ packages, and they can go beyond simply controlling the installation of
 a package or packages. In most cases, the presence or absence of a
 feature translates to the appropriate option supplied to the configure
 script during the :ref:`ref-tasks-configure` task for
-the recipes that optionally support the feature.
+the recipes that optionally support the feature. Appropriate options
+must be supplied, and enabling/disabling :term:`PACKAGECONFIG` for the
+concerned packages is one way of supplying such options.
 
 Some distro features are also machine features. These select features
 make sense to be controlled both at the machine and distribution
@@ -198,17 +200,19 @@ application problems or profile applications.
 
 Here are the image features available for all images:
 
--  *allow-empty-password:* Allows Dropbear and OpenSSH to accept root
-   logins and logins from accounts having an empty password string.
+-  *allow-empty-password:* Allows Dropbear and OpenSSH to accept
+   logins from accounts having an empty password string.
+
+-  *allow-root-login:* Allows Dropbear and OpenSSH to accept root logins.
 
 -  *dbg-pkgs:* Installs debug symbol packages for all packages installed
    in a given image.
 
 -  *debug-tweaks:* Makes an image suitable for development (e.g. allows
-   root logins without passwords and enables post-installation logging).
-   See the 'allow-empty-password', 'empty-root-password', and
-   'post-install-logging' features in this list for additional
-   information.
+   root logins, logins without passwords ---including root ones, and enables
+   post-installation logging). See the ``allow-empty-password``,
+   ``allow-root-login``, ``empty-root-password``, and ``post-install-logging``
+   features in this list for additional information.
 
 -  *dev-pkgs:* Installs development packages (headers and extra library
    links) for all packages installed in a given image.
@@ -216,8 +220,19 @@ Here are the image features available for all images:
 -  *doc-pkgs:* Installs documentation packages for all packages
    installed in a given image.
 
--  *empty-root-password:* Sets the root password to an empty string,
-   which allows logins with a blank password.
+-  *empty-root-password:* This feature or ``debug-tweaks`` is required if
+   you want to allow root login with an empty password. If these features
+   are not present in :term:`IMAGE_FEATURES`, a non-empty password is
+   forced in ``/etc/passwd`` and ``/etc/shadow`` if such files exist.
+
+   .. note::
+       ``empty-root-passwd`` doesn't set an empty root password by itself.
+       You get an initial empty root password thanks to the
+       :oe_git:`base-passwd </openembedded-core/tree/meta/recipes-core/base-passwd/>`
+       and :oe_git:`shadow </openembedded-core/tree/meta/recipes-extended/shadow/>`
+       recipes, and the presence of ``empty-root-passwd`` or ``debug-tweaks``
+       just disables the mechanism which forces an non-empty password for the
+       root user.
 
 -  *overlayfs-etc:* Configures the ``/etc`` directory to be in ``overlayfs``.
    This allows to store device specific information elsewhere, especially

documentation/ref-manual/qa-checks.rst

@@ -154,7 +154,16 @@ Errors and Warnings
    ``FILES:${PN}-dbg``. See :term:`FILES` for additional
    information on :term:`FILES`.
 
-    
+.. _qa-check-empty-dirs:
+
+-  ``<packagename> installs files in <path>, but it is expected to be empty [empty-dirs]``
+
+   The specified package is installing files into a directory that is
+   normally expected to be empty (such as ``/tmp``). These files may
+   be more appropriately installed to a different location, or
+   perhaps alternatively not installed at all, usually by updating the
+   ``do_install`` task/function.
+
 .. _qa-check-arch:
 
 -  ``Architecture did not match (<file_arch>, expected <machine_arch>) in <file> [arch]``
@@ -604,7 +613,7 @@ Errors and Warnings
     so using ${:term:`BPN`} rather than ${:term:`PN`} as the latter will change
     for different variants of the same recipe e.g. when :term:`BBCLASSEXTEND`
     or multilib are being used. This check will fail if a reference to ``${PN}``
-    is found within the :term:`SRC_URI` value - change it to ``${BPN}`` instead.
+    is found within the :term:`SRC_URI` value --- change it to ``${BPN}`` instead.
 
 
 .. _qa-check-unhandled-features-check:
@@ -718,7 +727,7 @@ Errors and Warnings
             devtool modify <recipe>
 
     This will apply all of the patches, and create new commits out of them in
-    the workspace - with the patch context updated.
+    the workspace --- with the patch context updated.
 
     Then, replace the patches in the recipe layer::
 

documentation/ref-manual/resources.rst

@@ -64,22 +64,22 @@ and announcements. To subscribe to one of the following mailing lists,
 click on the appropriate URL in the following list and follow the
 instructions:
 
--  :yocto_lists:`/g/yocto` - General Yocto Project
+-  :yocto_lists:`/g/yocto` --- general Yocto Project
    discussion mailing list.
 
--  :oe_lists:`/g/openembedded-core` - Discussion mailing
+-  :oe_lists:`/g/openembedded-core` --- discussion mailing
    list about OpenEmbedded-Core (the core metadata).
 
--  :oe_lists:`/g/openembedded-devel` - Discussion
+-  :oe_lists:`/g/openembedded-devel` --- discussion
    mailing list about OpenEmbedded.
 
--  :oe_lists:`/g/bitbake-devel` - Discussion mailing
+-  :oe_lists:`/g/bitbake-devel` --- discussion mailing
    list about the :term:`BitBake` build tool.
 
--  :yocto_lists:`/g/poky` - Discussion mailing list
+-  :yocto_lists:`/g/poky` --- discussion mailing list
    about :term:`Poky`.
 
--  :yocto_lists:`/g/yocto-announce` - Mailing list to
+-  :yocto_lists:`/g/yocto-announce` --- mailing list to
    receive official Yocto Project release and milestone announcements.
 
 For more Yocto Project-related mailing lists, see the

documentation/ref-manual/structure.rst

@@ -213,8 +213,8 @@ These files are standard top-level files.
 
 .. _structure-build:
 
-The Build Directory - ``build/``
-================================
+The Build Directory --- ``build/``
+==================================
 
 The OpenEmbedded build system creates the :term:`Build Directory`
 when you run the build environment setup
@@ -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
-``$TEMPLATECONF`` script variable, which defaults to ``meta-poky/conf/``
+:term:`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 ``TEMPLATECONF`` variable is used by looking at the
+   You can see how the :term:`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 ``$TEMPLATECONF`` script variable, which
+file used depends on the :term:`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 ``TEMPLATECONF`` variable ``scripts/oe-setup-builddir``
+   You can see how the :term:`TEMPLATECONF` variable is defined by the ``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.
@@ -589,7 +589,7 @@ install" places its output that is then split into sub-packages within
 ``build/tmp/work/tunearch/recipename/version/``
 -----------------------------------------------
 
-The recipe work directory - ``${WORKDIR}``.
+The recipe work directory --- ``${WORKDIR}``.
 
 As described earlier in the
 ":ref:`structure-build-tmp-sysroots`" section,
@@ -654,8 +654,8 @@ recipes. In practice, this is only used for ``gcc`` and its variants
 
 .. _structure-meta:
 
-The Metadata - ``meta/``
-========================
+The Metadata --- ``meta/``
+==========================
 
 As mentioned previously, :term:`Metadata` is the core of the
 Yocto Project. Metadata has several important subdivisions:

documentation/ref-manual/system-requirements.rst

@@ -234,8 +234,8 @@ supported CentOS-8 Linux distribution:
       $ sudo dnf install make python3-pip which
       &PIP3_HOST_PACKAGES_DOC;
 
-Required Git, tar, Python and gcc Versions
-==========================================
+Required Git, tar, Python, make and gcc Versions
+================================================
 
 In order to use the build system, your host development system must meet
 the following version requirements for Git, tar, and Python:
@@ -246,6 +246,8 @@ the following version requirements for Git, tar, and Python:
 
 -  Python &MIN_PYTHON_VERSION; or greater
 
+-  GNU make &MIN_MAKE_VERSION; or greater
+
 If your host development system does not meet all these requirements,
 you can resolve this by installing a ``buildtools`` tarball that
 contains these tools. You can get the tarball one of two ways: download

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

@@ -270,7 +270,7 @@ universal, the list includes them just in case:
       your Linux distribution.
 
       Another point worth noting is that historically within the Yocto
-      Project, recipes were referred to as packages - thus, the existence
+      Project, recipes were referred to as packages --- thus, the existence
       of several BitBake variables that are seemingly mis-named, (e.g.
       :term:`PR`, :term:`PV`, and
       :term:`PE`).
@@ -369,7 +369,7 @@ universal, the list includes them just in case:
      Directory created by unpacking a released tarball as compared to
      cloning ``git://git.yoctoproject.org/poky``. When you unpack a
      tarball, you have an exact copy of the files based on the time of
-     release - a fixed release point. Any changes you make to your local
+     release --- a fixed release point. Any changes you make to your local
      files in the Source Directory are on top of the release and will
      remain local only. On the other hand, when you clone the ``poky`` Git
      repository, you have an active development repository with access to
@@ -383,6 +383,31 @@ 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:`Sysroot`
+      When cross-compiling, the target file system may be differently laid
+      out and contain different things compared to the host system. The concept
+      of a *sysroot* is directory which looks like the target filesystem and
+      can be used to cross-compile against.
+
+      In the context of cross-compiling toolchains, a *sysroot*
+      typically contains C library and kernel headers, plus the
+      compiled binaries for the C library. A *multilib toolchain*
+      can contain multiple variants of the C library binaries,
+      each compiled for a target instruction set (such as ``armv5``,
+      ``armv7`` and ``armv8``), and possibly optimized for a specific CPU core.
+
+      In the more specific context of the OpenEmbedded build System and
+      of the Yocto Project, each recipe has two sysroots:
+
+      -  A *target sysroot* contains all the **target** libraries and headers
+         needed to build the recipe.
+
+      -  A *native sysroot* contains all the **host** files and executables
+         needed to build the recipe.
+
+      See the :term:`SYSROOT_* <SYSROOT_DESTDIR>` variables controlling
+      how sysroots are created and stored.
+
    :term:`Task`
       A per-recipe unit of execution for BitBake (e.g.
       :ref:`ref-tasks-compile`,

documentation/ref-manual/variables.rst

@@ -591,7 +591,7 @@ system and gives an overview of their function and contents.
       This variable is useful in situations where the same recipe appears
       in more than one layer. Setting this variable allows you to
       prioritize a layer against other layers that contain the same recipe
-      - effectively letting you control the precedence for the multiple
+      --- effectively letting you control the precedence for the multiple
       layers. The precedence established through this variable stands
       regardless of a recipe's version (:term:`PV` variable). For
       example, a layer that has a recipe with a higher :term:`PV` value but for
@@ -718,10 +718,11 @@ system and gives an overview of their function and contents.
 
          BBMULTICONFIG = "configA configB configC"
 
-      Each configuration file you
-      use must reside in the :term:`Build Directory`
-      ``conf/multiconfig`` directory (e.g.
-      ``build_directory/conf/multiconfig/configA.conf``).
+      Each configuration file you use must reside in a ``multiconfig``
+      subdirectory of a configuration directory within a layer, or
+      within the :term:`Build Directory` (e.g.
+      ``build_directory/conf/multiconfig/configA.conf`` or
+      ``mylayer/conf/multiconfig/configB.conf``).
 
       For information on how to use :term:`BBMULTICONFIG` in an environment
       that supports building targets with multiple configurations, see the
@@ -888,7 +889,7 @@ system and gives an overview of their function and contents.
    :term:`BUILD_OS`
       Specifies the operating system in use on the build host (e.g.
       "linux"). The OpenEmbedded build system sets the value of
-      :term:`BUILD_OS` from the OS reported by the ``uname`` command - the
+      :term:`BUILD_OS` from the OS reported by the ``uname`` command --- the
       first word, converted to lower-case characters.
 
    :term:`BUILD_PREFIX`
@@ -1296,6 +1297,19 @@ system and gives an overview of their function and contents.
       the recipe will be skipped, and if the build system attempts to build
       the recipe then an error will be triggered.
 
+   :term:`CONVERSION_CMD`
+      This variable is used for storing image conversion commands.
+      Image conversion can convert an image into different objects like:
+
+      -   Compressed version of the image
+
+      -   Checksums for the image
+
+      An example of :term:`CONVERSION_CMD` from :ref:`image-types
+      <ref-classes-image_types>` class is::
+
+         CONVERSION_CMD:lzo = "lzop -9 ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
+
    :term:`COPY_LIC_DIRS`
       If set to "1" along with the
       :term:`COPY_LIC_MANIFEST` variable, the
@@ -1485,6 +1499,13 @@ system and gives an overview of their function and contents.
 
          CVE_PRODUCT = "oracle_berkeley_db berkeley_db"
 
+      Sometimes the product name is not specific enough, for example
+      "tar" has been matching CVEs for the GNU ``tar`` package and also
+      the ``node-tar`` node.js extension. To avoid this problem, use the
+      vendor name as a prefix. The syntax for this is::
+
+         CVE_PRODUCT = "vendor:package"
+
    :term:`CVSDIR`
       The directory in which files checked out under the CVS system are
       stored.
@@ -1681,7 +1702,7 @@ system and gives an overview of their function and contents.
       ``${TMPDIR}/deploy``.
 
       For more information on the structure of the Build Directory, see
-      ":ref:`ref-manual/structure:the build directory - \`\`build/\`\``" section.
+      ":ref:`ref-manual/structure:the build directory --- \`\`build/\`\``" section.
       For more detail on the contents of the ``deploy`` directory, see the
       ":ref:`overview-manual/concepts:images`",
       ":ref:`overview-manual/concepts:package feeds`", and
@@ -1725,7 +1746,7 @@ system and gives an overview of their function and contents.
       <ref-classes-image>` class.
 
       For more information on the structure of the Build Directory, see
-      ":ref:`ref-manual/structure:the build directory - \`\`build/\`\``" section.
+      ":ref:`ref-manual/structure:the build directory --- \`\`build/\`\``" section.
       For more detail on the contents of the ``deploy`` directory, see the
       ":ref:`overview-manual/concepts:images`" and
       ":ref:`overview-manual/concepts:application development sdk`" sections both in
@@ -1865,7 +1886,10 @@ system and gives an overview of their function and contents.
       optionally support the feature. For example, specifying "x11" in
       :term:`DISTRO_FEATURES`, causes every piece of software built for the
       target that can optionally support X11 to have its X11 support
-      enabled.
+      enabled. Note: just enabling :term:`DISTRO_FEATURES` alone doesn't
+      enable feature support for packages, mechanisms such as making
+      :term:`PACKAGECONFIG` track :term:`DISTRO_FEATURES` are used
+      to enable/disable package features.
 
       Two more examples are Bluetooth and NFS support. For a more complete
       list of features that ships with the Yocto Project and that you can
@@ -2237,24 +2261,24 @@ system and gives an overview of their function and contents.
 
       Here are some examples of features you can add:
 
-        - "dbg-pkgs" - Adds -dbg packages for all installed packages including
+        - "dbg-pkgs" --- adds -dbg packages for all installed packages including
           symbol information for debugging and profiling.
 
-        - "debug-tweaks" - Makes an image suitable for debugging. For example, allows root logins without passwords and
+        - "debug-tweaks" --- makes an image suitable for debugging. For example, allows root logins without passwords and
           enables post-installation logging. See the 'allow-empty-password' and
           'post-install-logging' features in the ":ref:`ref-features-image`"
           section for more information.
-        - "dev-pkgs" - Adds -dev packages for all installed packages. This is
+        - "dev-pkgs" --- adds -dev packages for all installed packages. This is
           useful if you want to develop against the libraries in the image.
-        - "read-only-rootfs" - Creates an image whose root filesystem is
+        - "read-only-rootfs" --- creates an image whose root filesystem is
           read-only. See the
           ":ref:`dev-manual/common-tasks:creating a read-only root filesystem`"
           section in the Yocto Project Development Tasks Manual for more
           information
-        - "tools-debug" - Adds debugging tools such as gdb and strace.
-        - "tools-sdk" - Adds development tools such as gcc, make,
+        - "tools-debug" --- adds debugging tools such as gdb and strace.
+        - "tools-sdk" --- adds development tools such as gcc, make,
           pkgconfig and so forth.
-        - "tools-testapps" - Adds useful testing tools
+        - "tools-testapps" --- adds useful testing tools
           such as ts_print, aplay, arecord and so forth.
 
       For a complete list of image features that ships with the Yocto
@@ -2331,6 +2355,37 @@ system and gives an overview of their function and contents.
          # usermod -s /bin/sh tester; \
          # "
 
+      Hardcoded passwords are supported via the ``-p`` parameters for
+      ``useradd`` or ``usermod``, but only hashed.
+
+      Here is an example that adds two users named "tester-jim" and "tester-sue" and assigns
+      passwords. First on host, create the (escaped) password hash::
+
+         printf "%q" $(mkpasswd -m sha256crypt tester01)
+
+      The resulting hash is set to a variable and used in ``useradd`` command parameters::
+
+         inherit extrausers
+         PASSWD = "\$X\$ABC123\$A-Long-Hash"
+         EXTRA_USERS_PARAMS = "\
+             useradd -p '${PASSWD}' tester-jim; \
+             useradd -p '${PASSWD}' tester-sue; \
+             "
+
+      Finally, here is an example that sets the root password::
+
+         inherit extrausers
+         EXTRA_USERS_PARAMS = "\
+             usermod -p '${PASSWD}' root; \
+             "
+
+      .. note::
+
+         From a security perspective, hardcoding a default password is not
+         generally a good idea or even legal in some jurisdictions. It is 
+         recommended that you do not do this if you are building a production 
+         image.
+
       Additionally there is a special ``passwd-expire`` command that will
       cause the password for a user to be expired and thus force changing it
       on first login, for example::
@@ -3217,7 +3272,7 @@ system and gives an overview of their function and contents.
          IMAGE_NAME ?= "${IMAGE_BASENAME}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
 
    :term:`IMAGE_NAME_SUFFIX`
-      Suffix used for the image output filename - defaults to ``".rootfs"``
+      Suffix used for the image output filename --- defaults to ``".rootfs"``
       to distinguish the image file from other files created during image
       building; however if this suffix is redundant or not desired you can
       clear the value of this variable (set the value to ""). For example,
@@ -3485,6 +3540,14 @@ system and gives an overview of their function and contents.
       incompatible licenses are not built. Packages that are individually
       licensed with the specified incompatible licenses will be deleted.
 
+      There is some support for wildcards in this variable's value,
+      however it is restricted to specific licenses. Currently only
+      these wildcards are allowed and expand as follows:
+
+      - ``AGPL-3.0*"``: ``AGPL-3.0-only``, ``AGPL-3.0-or-later``
+      - ``GPL-3.0*``: ``GPL-3.0-only``, ``GPL-3.0-or-later``
+      - ``LGPL-3.0*``: ``LGPL-3.0-only``, ``LGPL-3.0-or-later``
+
       .. note::
 
          This functionality is only regularly tested using the following
@@ -3497,6 +3560,14 @@ system and gives an overview of their function and contents.
          remove dependencies on or provide alternatives to components that
          are required to produce a functional system image.
 
+   :term:`INCOMPATIBLE_LICENSE_EXCEPTIONS`
+      Specifies a space-separated list of package and license pairs that
+      are allowed to be used even if the license is specified in
+      :term:`INCOMPATIBLE_LICENSE`. The package and license pairs are
+      separated using a colon. Example::
+
+         INCOMPATIBLE_LICENSE_EXCEPTIONS = "gdbserver:GPL-3.0-only gdbserver:LGPL-3.0-only"
+
    :term:`INHERIT`
       Causes the named class or classes to be inherited globally. Anonymous
       functions in the class or classes are not executed for the base
@@ -3505,7 +3576,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
@@ -3938,6 +4009,11 @@ system and gives an overview of their function and contents.
       custom kernel image types with the :ref:`kernel <ref-classes-kernel>` class using this
       variable.
 
+   :term:`KERNEL_DEBUG_TIMESTAMPS`
+      If set to "1", enables timestamping functionality during building
+      the kernel. The default is "0" to disable this for reproducibility
+      reasons.
+
    :term:`KERNEL_DEVICETREE`
       Specifies the name of the generated Linux kernel device tree (i.e.
       the ``.dtb``) file.
@@ -4013,10 +4089,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
@@ -4204,7 +4280,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".
@@ -5606,11 +5682,6 @@ system and gives an overview of their function and contents.
 
       :term:`PE` is the default value of the :term:`PKGE` variable.
 
-   :term:`PEP517_BUILD_API`
-      When used by recipes that inherit the :ref:`python_pep517
-      <ref-classes-python_pep517>` class, specifies the entry point to the
-      PEP-517 compliant build API (such as ``flit_core.buildapi``).
-
    :term:`PEP517_WHEEL_PATH`
       When used by recipes that inherit the
       :ref:`python_pep517 <ref-classes-python_pep517>` class,
@@ -6064,6 +6135,28 @@ system and gives an overview of their function and contents.
       In the previous example,
       the version of the dependency is :term:`PYTHON_PN`.
 
+   :term:`QA_EMPTY_DIRS`
+      Specifies a list of directories that are expected to be empty when
+      packaging; if ``empty-dirs`` appears in :term:`ERROR_QA` or
+      :term:`WARN_QA` these will be checked and an error or warning
+      (respectively) will be produced.
+
+      The default :term:`QA_EMPTY_DIRS` value is set in
+      :ref:`insane.bbclass <ref-classes-insane>`.
+
+   :term:`QA_EMPTY_DIRS_RECOMMENDATION`
+      Specifies a recommendation for why a directory must be empty,
+      which will be included in the error message if a specific directory
+      is found to contain files. Must be overridden with the directory
+      path to match on.
+
+      If no recommendation is specified for a directory, then the default
+      "but it is expected to be empty" will be used.
+
+      An example message shows if files were present in '/dev'::
+
+         QA_EMPTY_DIRS_RECOMMENDATION:/dev = "but all devices must be created at runtime"
+
    :term:`RANLIB`
       The minimal command and arguments to run ``ranlib``.
 
@@ -6132,7 +6225,7 @@ system and gives an overview of their function and contents.
       ``baz``.
 
       The names of the packages you list within :term:`RDEPENDS` must be the
-      names of other packages - they cannot be recipe names. Although
+      names of other packages --- they cannot be recipe names. Although
       package names and recipe names usually match, the important point
       here is that you are providing package names within the :term:`RDEPENDS`
       variable. For an example of the default list of packages created from
@@ -7035,35 +7128,35 @@ system and gives an overview of their function and contents.
 
       There are standard and recipe-specific options. Here are standard ones:
 
-      -  ``apply`` - Whether to apply the patch or not. The default
+      -  ``apply`` --- whether to apply the patch or not. The default
          action is to apply the patch.
 
-      -  ``striplevel`` - Which striplevel to use when applying the
+      -  ``striplevel`` --- which striplevel to use when applying the
          patch. The default level is 1.
 
-      -  ``patchdir`` - Specifies the directory in which the patch should
+      -  ``patchdir`` --- specifies the directory in which the patch should
          be applied. The default is ``${``\ :term:`S`\ ``}``.
 
       Here are options specific to recipes building code from a revision
       control system:
 
-      -  ``mindate`` - Apply the patch only if
+      -  ``mindate`` --- apply the patch only if
          :term:`SRCDATE` is equal to or greater than
          ``mindate``.
 
-      -  ``maxdate`` - Apply the patch only if :term:`SRCDATE` is not later
+      -  ``maxdate`` --- apply the patch only if :term:`SRCDATE` is not later
          than ``maxdate``.
 
-      -  ``minrev`` - Apply the patch only if :term:`SRCREV` is equal to or
+      -  ``minrev`` --- apply the patch only if :term:`SRCREV` is equal to or
          greater than ``minrev``.
 
-      -  ``maxrev`` - Apply the patch only if :term:`SRCREV` is not later
+      -  ``maxrev`` --- apply the patch only if :term:`SRCREV` is not later
          than ``maxrev``.
 
-      -  ``rev`` - Apply the patch only if :term:`SRCREV` is equal to
+      -  ``rev`` --- apply the patch only if :term:`SRCREV` is equal to
          ``rev``.
 
-      -  ``notrev`` - Apply the patch only if :term:`SRCREV` is not equal to
+      -  ``notrev`` --- apply the patch only if :term:`SRCREV` is not equal to
          ``rev``.
 
       .. note::
@@ -7144,6 +7237,32 @@ system and gives an overview of their function and contents.
    :term:`SSTATE_DIR`
       The directory for the shared state cache.
 
+   :term:`SSTATE_EXCLUDEDEPS_SYSROOT`
+      This variable allows to specify indirect dependencies to exclude
+      from sysroots, for example to avoid the situations when a dependency on
+      any ``-native`` recipe will pull in all dependencies of that recipe
+      in the recipe sysroot. This behaviour might not always be wanted,
+      for example when that ``-native`` recipe depends on build tools
+      that are not relevant for the current recipe.
+
+      This way, irrelevant dependencies are ignored, which could have
+      prevented the reuse of prebuilt artifacts stored in the Shared
+      State Cache.
+
+      ``SSTATE_EXCLUDEDEPS_SYSROOT`` is evaluated as two regular
+      expressions of recipe and dependency to ignore. An example
+      is the rule in :oe_git:`meta/conf/layer.conf </meta/conf/layer.conf>`::
+
+         # Nothing needs to depend on libc-initial
+         # base-passwd/shadow-sysroot don't need their dependencies
+         SSTATE_EXCLUDEDEPS_SYSROOT += "\
+             .*->.*-initial.* \
+             .*(base-passwd|shadow-sysroot)->.* \
+         "
+
+      The ``->`` substring represents the dependency between
+      the two regular expressions.
+
    :term:`SSTATE_MIRROR_ALLOW_NETWORK`
       If set to "1", allows fetches from mirrors that are specified in
       :term:`SSTATE_MIRRORS` to work even when
@@ -7566,6 +7685,24 @@ system and gives an overview of their function and contents.
       For information on Systemd-boot, see the `Systemd-boot
       documentation <https://www.freedesktop.org/wiki/Software/systemd/systemd-boot/>`__.
 
+   :term:`SYSTEMD_DEFAULT_TARGET`
+
+      This variable allows to set the default unit that systemd starts at bootup.
+      Usually, this is either ``multi-user.target`` or ``graphical.target``.
+      This works by creating a ``default.target`` symbolic link to the chosen systemd
+      target file.
+
+      See `systemd's documentation
+      <https://www.freedesktop.org/software/systemd/man/systemd.special.html>`__
+      for details.
+
+      For example, this variable is used in the
+      `core-image-minimal-xfce.bb
+      <https://git.openembedded.org/meta-openembedded/tree/meta-xfce/recipes-core/images/core-image-minimal-xfce.bb>`__
+      recipe::
+
+          SYSTEMD_DEFAULT_TARGET = "graphical.target"
+
    :term:`SYSTEMD_PACKAGES`
       When inheriting the :ref:`systemd <ref-classes-systemd>` class,
       this variable locates the systemd unit files when they are not found
@@ -7583,12 +7720,18 @@ system and gives an overview of their function and contents.
       When inheriting the :ref:`systemd <ref-classes-systemd>` class,
       this variable specifies the systemd service name for a package.
 
+      Multiple services can be specified, each one separated by a space.
+
       When you specify this file in your recipe, use a package name
       override to indicate the package to which the value applies. Here is
       an example from the connman recipe::
 
          SYSTEMD_SERVICE:${PN} = "connman.service"
 
+      The package overrides that can be specified are directly related to the value of
+      term:`SYSTEMD_PACKAGES`. Overrides not included in term:`SYSTEMD_PACKAGES`
+      will be silently ignored.
+
    :term:`SYSVINIT_ENABLED_GETTYS`
       When using
       :ref:`SysVinit <dev-manual/common-tasks:enabling system services>`,
@@ -7826,6 +7969,21 @@ 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
@@ -8679,6 +8837,19 @@ 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
@@ -8694,8 +8865,8 @@ system and gives an overview of their function and contents.
       -  :term:`TMPDIR`: The top-level build output directory
       -  :term:`MULTIMACH_TARGET_SYS`: The target system identifier
       -  :term:`PN`: The recipe name
-      -  :term:`EXTENDPE`: The epoch - (if :term:`PE` is not specified, which
-         is usually the case for most recipes, then `EXTENDPE` is blank)
+      -  :term:`EXTENDPE`: The epoch --- if :term:`PE` is not specified, which
+         is usually the case for most recipes, then `EXTENDPE` is blank.
       -  :term:`PV`: The recipe version
       -  :term:`PR`: The recipe revision
 
@@ -8717,4 +8888,36 @@ system and gives an overview of their function and contents.
 
       The default value of :term:`XSERVER`, if not specified in the machine
       configuration, is "xserver-xorg xf86-video-fbdev xf86-input-evdev".
-   
+
+   :term:`XZ_THREADS`
+      Specifies the number of parallel threads that should be used when
+      using xz compression.
+
+      By default this scales with core count, but is never set less than 2
+      to ensure that multi-threaded mode is always used so that the output
+      file contents are deterministic. Builds will work with a value of 1
+      but the output will differ compared to the output from the compression
+      generated when more than one thread is used.
+
+      On systems where many tasks run in parallel, setting a limit to this
+      can be helpful in controlling system resource usage.
+
+    :term:`XZ_MEMLIMIT`
+      Specifies the maximum memory the xz compression should use as a percentage
+      of system memory. If unconstrained the xz compressor can use large amounts of
+      memory and become problematic with parallelism elsewhere in the build.
+      "50%" has been found to be a good value.
+
+   :term:`ZSTD_THREADS`
+      Specifies the number of parallel threads that should be used when
+      using ZStandard compression.
+
+      By default this scales with core count, but is never set less than 2
+      to ensure that multi-threaded mode is always used so that the output
+      file contents are deterministic. Builds will work with a value of 1
+      but the output will differ compared to the output from the compression
+      generated when more than one thread is used.
+
+      On systems where many tasks run in parallel, setting a limit to this
+      can be helpful in controlling system resource usage.
+

documentation/ref-manual/varlocality.rst

@@ -113,7 +113,7 @@ This section lists variables that are required for recipes.
 
 -  :term:`LIC_FILES_CHKSUM`
 
--  :term:`SRC_URI` - used in recipes that fetch local or remote files.
+-  :term:`SRC_URI` --- used in recipes that fetch local or remote files.
 
 .. _ref-varlocality-recipe-dependencies:
 

documentation/releases.rst

@@ -12,24 +12,12 @@
 ===========================
 
 ******************************
-Release Series 3.4 (honister)
+Release Series 4.0 (kirkstone)
 ******************************
 
-- :yocto_docs:`3.4 Documentation </3.4>`
-- :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>`
-
-******************************
-Release Series 3.3 (hardknott)
-******************************
-
-- :yocto_docs:`3.3 Documentation </3.3>`
-- :yocto_docs:`3.3.1 Documentation </3.3.1>`
-- :yocto_docs:`3.3.2 Documentation </3.3.2>`
-- :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:`4.0 Documentation </4.0>`
+- :yocto_docs:`4.0.1 Documentation </4.0.1>`
+- :yocto_docs:`4.0.2 Documentation </4.0.2>`
 
 ****************************
 Release Series 3.1 (dunfell)
@@ -51,11 +39,35 @@ 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>`
+- :yocto_docs:`3.1.17 Documentation </3.1.17>`
 
 ==========================
  Outdated Release Manuals
 ==========================
 
+******************************
+Release Series 3.4 (honister)
+******************************
+
+- :yocto_docs:`3.4 Documentation </3.4>`
+- :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)
+******************************
+
+- :yocto_docs:`3.3 Documentation </3.3>`
+- :yocto_docs:`3.3.1 Documentation </3.3.1>`
+- :yocto_docs:`3.3.2 Documentation </3.3.2>`
+- :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.2 (gatesgarth)
 *******************************

documentation/sdk-manual/appendix-obtain.rst

@@ -265,8 +265,7 @@ install the Standard SDK by running the ``*.sh`` SDK installation
 script:
 
 .. image:: figures/sdk-installed-standard-sdk-directory.png
-   :scale: 80%
-   :align: center
+   :scale: 100%
 
 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
-   :align: center
+   :width: 100%
 
 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
@@ -252,7 +252,7 @@ command:
    -  *Left*: The left scenario in the figure represents a common
       situation where the source code does not exist locally and needs
       to be extracted. In this situation, the source code is extracted
-      to the default workspace - you do not want the files in some
+      to the default workspace --- you do not want the files in some
       specific location outside of the workspace. Thus, everything you
       need will be located in the workspace::
 
@@ -267,7 +267,7 @@ command:
    -  *Middle*: The middle scenario in the figure also represents a
       situation where the source code does not exist locally. In this
       case, the code is again upstream and needs to be extracted to some
-      local area - this time outside of the default workspace.
+      local area --- this time outside of the default workspace.
 
       .. note::
 
@@ -302,7 +302,7 @@ command:
       recipe for the code and places the recipe into the workspace.
 
       Because the extracted source code already exists, ``devtool`` does
-      not try to relocate the source code into the workspace - only the
+      not try to relocate the source code into the workspace --- only the
       new recipe is placed in the workspace.
 
       Aside from a recipe folder, the command also creates an associated
@@ -401,7 +401,7 @@ diagram shows common development flows for the ``devtool modify``
 command:
 
 .. image:: figures/sdk-devtool-modify-flow.png
-   :align: center
+   :width: 100%
 
 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
-   :align: center
+   :width: 100%
 
 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
-   :align: center
+   :width: 100%
 
 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,6 +19,7 @@ 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:
@@ -168,23 +169,24 @@ 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:
 
--  *Case 1 - No Variables Set in the Makefile Map to Equivalent
+-  *Case 1 --- No Variables Set in the Makefile Map to Equivalent
    Environment Variables Set in the SDK Setup Script:* Because matching
    variables are not specifically set in the ``Makefile``, the variables
    retain their values based on the environment setup script.
 
--  *Case 2 - Variables Are Set in the Makefile that Map to Equivalent
+-  *Case 2 --- Variables Are Set in the Makefile that Map to Equivalent
    Environment Variables from the SDK Setup Script:* Specifically
    setting matching variables in the ``Makefile`` during the build
    results in the environment settings of the variables being
    overwritten. In this case, the variables you set in the ``Makefile``
    are used.
 
--  *Case 3 - Variables Are Set Using the Command Line that Map to
+-  *Case 3 --- Variables Are Set Using the Command Line that Map to
    Equivalent Environment Variables from the SDK Setup Script:*
    Executing the ``Makefile`` from the command line results in the
    environment variables being overwritten. In this case, the

documentation/set_versions.py

@@ -23,13 +23,17 @@ ourversion = None
 if len(sys.argv) == 2:
     ourversion = sys.argv[1]
 
-activereleases = ["honister", "hardknott", "dunfell"]
-#devbranch = "langdale"
-devbranch = "kirkstone"
+activereleases = ["kirkstone", "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["langdale"] = "4.1"
 release_series["kirkstone"] = "4.0"
 release_series["honister"] = "3.4"
 release_series["hardknott"] = "3.3"
@@ -57,8 +61,8 @@ release_series["bernard"] = "1.0"
 release_series["laverne"] = "0.9"
 
 
-#    "langdale" : "2.2",
 bitbake_mapping = {
+    "langdale" : "2.2",
     "kirkstone" : "2.0",
     "honister" : "1.52",
     "hardknott" : "1.50",
@@ -82,7 +86,7 @@ docconfver = None
 
 # Test tags exist and inform the user to fetch if not
 try:
-    subprocess.run(["git", "show", "yocto-3.4.2"], capture_output=True, check=True)
+    subprocess.run(["git", "show", "yocto-%s" % release_series[activereleases[0]]], capture_output=True, check=True)
 except subprocess.CalledProcessError:
     sys.exit("Please run 'git fetch --tags' before building the documentation")
 
@@ -128,7 +132,7 @@ else:
     if branch == "master":
         ourseries = devbranch
         docconfver = "dev"
-        bitbakeversion = ""
+        bitbakeversion = "dev"
     elif branch in release_series:
         ourseries = branch
         if branch in bitbake_mapping:
@@ -199,29 +203,29 @@ if os.path.exists("poky.yaml.in"):
 #  - current doc version
 # (with duplicates removed)
 
-if ourseries not in activereleases:
-    activereleases.append(ourseries)
-
 versions = []
 with open("sphinx-static/switchers.js.in", "r") as r, open("sphinx-static/switchers.js", "w") as w:
     lines = r.readlines()
     for line in lines:
+        if "ALL_RELEASES_PLACEHOLDER" in line:
+            w.write(str(list(release_series.keys())))
+            continue
         if "VERSIONS_PLACEHOLDER" in line:
-            w.write("    'dev': { 'title': 'dev (%s)', 'obsolete': false,},\n" % release_series[devbranch])
-            for branch in activereleases:
+            w.write("    'dev': { 'title': 'Unstable (dev)', 'obsolete': false,},\n")
+            for branch in activereleases + ([ourseries] if ourseries not in activereleases else []):
                 if branch == devbranch:
                     continue
-                versions = subprocess.run('git tag --list yocto-%s*' % (release_series[branch]), shell=True, capture_output=True, text=True).stdout.split()
-                versions = sorted([v.replace("yocto-" +  release_series[branch] + ".", "").replace("yocto-" +  release_series[branch], "0") for v in versions], key=int)
-                if not versions:
+                branch_versions = subprocess.run('git tag --list yocto-%s*' % (release_series[branch]), shell=True, capture_output=True, text=True).stdout.split()
+                branch_versions = sorted([v.replace("yocto-" +  release_series[branch] + ".", "").replace("yocto-" +  release_series[branch], "0") for v in branch_versions], key=int)
+                if not branch_versions:
                     continue
                 version = release_series[branch]
-                if versions[-1] != "0":
-                    version = version + "." + versions[-1]
+                if branch_versions[-1] != "0":
+                    version = version + "." + branch_versions[-1]
                 versions.append(version)
-                w.write("    '%s': {'title': '%s', 'obsolete': %s,},\n" % (version, version, str(branch == ourseries).lower()))
+                w.write("    '%s': {'title': '%s (%s)', 'obsolete': %s,},\n" % (version, branch.capitalize(), version, str(branch not in activereleases).lower()))
             if ourversion not in versions and ourseries != devbranch:
-                w.write("    '%s': {'title': '%s', 'obsolete': true,},\n" % (ourversion, ourversion))
+                w.write("    '%s': {'title': '%s (%s)', 'obsolete': %s,},\n" % (ourversion, ourseries.capitalize(), ourversion, str(ourseries not in activereleases).lower()))
         else:
             w.write(line)
 

documentation/sphinx-static/switchers.js.in

@@ -9,7 +9,11 @@ by https://git.yoctoproject.org/yocto-autobuilder-helper/tree/scripts/run-docs-b
 (function() {
   'use strict';
 
-  var all_versions = {
+  var all_releases =
+	ALL_RELEASES_PLACEHOLDER
+  ;
+
+  var switcher_versions = {
     VERSIONS_PLACEHOLDER
   };
 
@@ -65,7 +69,7 @@ by https://git.yoctoproject.org/yocto-autobuilder-helper/tree/scripts/run-docs-b
   function build_version_select(current_series, current_version) {
     var buf = ['<select>'];
 
-    $.each(all_versions, function(version, vers_data) {
+    $.each(switcher_versions, function(version, vers_data) {
       var series = version.substr(0, 3);
       if (series == current_series) {
         if (version == current_version)
@@ -149,14 +153,20 @@ by https://git.yoctoproject.org/yocto-autobuilder-helper/tree/scripts/run-docs-b
     var docroot = get_docroot_url()
 
     var new_versionpath = selected_version + '/';
-    if (selected_version == "dev")
-        new_versionpath = '';
 
-    // dev versions have no version prefix
-    if (current_version == "dev") {
+    // latest tag is also the default page (without version information)
+    if (docroot.endsWith(current_version + '/') == false) {
         var new_url = docroot + new_versionpath + url.replace(docroot, "");
         var fallback_url = docroot + new_versionpath;
     } else {
+	// check for named releases (e.g. dunfell) in the subpath
+        $.each(all_releases, function(idx, release) {
+		if (docroot.endsWith('/' + release + '/')) {
+			current_version = release;
+			return false;
+		}
+	});
+
         var new_url = url.replace('/' + current_version + '/', '/' + new_versionpath);
         var fallback_url = new_url.replace(url.replace(docroot, ""), "");
     }
@@ -220,10 +230,10 @@ by https://git.yoctoproject.org/yocto-autobuilder-helper/tree/scripts/run-docs-b
     $('.doctype_switcher_placeholder select').bind('change', on_doctype_switch);
 
     if (release != "dev") {
-      $.each(all_versions, function(version, vers_data) {
+      $.each(switcher_versions, function(version, vers_data) {
         var series = version.substr(0, 3);
         if (series == current_series) {
-          if (version != release) {
+          if (version != release && release.endsWith('.999') == false) {
             $('#outdated-warning').html('This document is for outdated version ' + release + ', you should select the latest release version in this series, ' + version + '.');
             $('#outdated-warning').css('padding', '.5em');
             return false;

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,7 +7,89 @@ It is currently a work in progress.
 
 ## Text standards
 
-This section has not been filled yet
+### Bulleted lists
+
+Though Sphinx supports both the ``*`` and ``-`` characters
+for introducing bulleted lists, we have chosen to use
+only ``-`` for this purpose.
+
+Though not strictly required by Sphinx, we have also chosen
+to use two space characters after ``-`` to introduce each
+list item:
+
+    -  Paragraph 1
+
+    -  Paragraph 2
+
+As shown in the above example, there should also be an empty
+line between each list item.
+
+An exception to this rule is when the list items are just made
+of a few words, instead of entire paragraphs:
+
+    -  Item 1
+    -  Item 2
+
+This is again a matter of style, not syntax.
+
+### Line wrapping
+
+Source code for the documentation shouldn't have lines
+wider than 80 characters. This makes patch lines more
+readable and code easier to quote in e-mail clients.
+
+If you have to include long commands or lines in configuration
+files, provided the syntax makes this possible, split them
+into multiple lines, using the ``\`` character.
+
+Here is an example:
+
+    $ scripts/install-buildtools \
+      --without-extended-buildtools \
+      --base-url https://downloads.yoctoproject.org/releases/yocto \
+      --release yocto-4.0.1 \
+      --installer-version 4.0.1
+
+Exceptions are granted for file contents whose lines
+cannot be split without infringing syntactic rules
+or reducing readability, as well as for command output
+which should be kept unmodified.
+
+### 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, tool and command names
+
+File, tool and command names should be double tick-quoted.
+For example, ``` ``conf/local.conf`` ``` is preferred over
+`"conf/local.conf"`.
+
+### Variables
+
+Every variable should be mentioned with:
+
+    :term:`VARIABLE`
+
+This assumes that `VARIABLE` is described either
+in the Yocto Project documentation variable index (`ref-manual/variables.rst`)
+or in the BitBake User Manual
+(`doc/bitbake-user-manual/bitbake-user-manual-ref-variables.rst`)
+
+If it is not described yet, the variable should be added to the
+glossary before or in the same patch it is used, so that `:term:` can be used.
 
 ## ReStructured Text Syntax standards
 
@@ -26,8 +108,14 @@ To include a screenshot in PNG format:
     .. image:: figures/user-configuration.png
        :align: center
 
-Depending on the size of the image, you may also shrink it
-to prevent it from filling the whole page width:
+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:
 
        :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,9 +83,10 @@ 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
-===============================================
+Yocto Project Tests --- Types of Testing Overview
+=================================================
 
 The Autobuilder tests different elements of the project by using
 the following types of tests:
@@ -174,20 +175,26 @@ 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
 
-   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
 
+   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
+
    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
@@ -335,12 +342,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.
 
@@ -468,7 +475,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,6 +92,7 @@ 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,
@@ -99,3 +100,4 @@ 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
-    ``TEMPLATECONF`` value reflects the contents of
+    :term:`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 curated layer index
+   Use the :yocto_home:`Yocto Project Compatible Layers
    </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
@@ -84,7 +84,7 @@ Transitioning to a custom environment for systems development
 
 #. **Now you're ready to create an image recipe**.
    There are a number of ways to do this. However, it is strongly recommended
-   that you have your own image recipe - don't try appending to existing image
+   that you have your own image recipe --- don't try appending to existing image
    recipes. Recipes for images are trivial to create and you usually want to
    fully customize their contents.
 

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

@@ -98,6 +98,7 @@ 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.
@@ -179,7 +180,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'
+You can also run generated qemu images with a command like 'runqemu qemux86-64'.
 
 Other commonly useful commands are:
  - 'devtool' and 'recipetool' handle common recipe tasks