build-appliance-image: Update to master head revision

(From OE-Core rev: 3b2903ccc791d5dedd84c75227f38ae4c8d29251)

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

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

@@ -648,13 +648,6 @@ compiled binary. To handle this, BitBake calls the
 each successful setscene task to know whether or not it needs to obtain
 the dependencies of that task.
 
-Finally, after all the setscene tasks have executed, BitBake calls the
-function listed in
-:term:`BB_SETSCENE_VERIFY_FUNCTION2`
-with the list of tasks BitBake thinks has been "covered". The metadata
-can then ensure that this list is correct and can inform BitBake that it
-wants specific tasks to be run regardless of the setscene result.
-
 You can find more information on setscene metadata in the
 :ref:`bitbake-user-manual/bitbake-user-manual-metadata:task checksums and setscene`
 section.

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

@@ -1650,10 +1650,15 @@ user interfaces:
 Variants - Class Extension Mechanism
 ====================================
 
-BitBake supports two features that facilitate creating from a single
-recipe file multiple incarnations of that recipe file where all
-incarnations are buildable. These features are enabled through the
-:term:`BBCLASSEXTEND` and :term:`BBVERSIONS` variables.
+BitBake supports multiple incarnations of a recipe file via the
+:term:`BBCLASSEXTEND` variable.
+
+The :term:`BBCLASSEXTEND` variable is a space separated list of classes used
+to "extend" the recipe for each variant. Here is an example that results in a
+second incarnation of the current recipe being available. This second
+incarnation will have the "native" class inherited. ::
+
+      BBCLASSEXTEND = "native"
 
 .. note::
 
@@ -1663,34 +1668,6 @@ incarnations are buildable. These features are enabled through the
    class. For specific examples, see the OE-Core native , nativesdk , and
    multilib classes.
 
--  ``BBCLASSEXTEND``: This variable is a space separated list of
-   classes used to "extend" the recipe for each variant. Here is an
-   example that results in a second incarnation of the current recipe
-   being available. This second incarnation will have the "native" class
-   inherited. ::
-
-      BBCLASSEXTEND = "native"
-
--  ``BBVERSIONS``: This variable allows a single recipe to build
-   multiple versions of a project from a single recipe file. You can
-   also specify conditional metadata (using the
-   :term:`OVERRIDES` mechanism) for a single
-   version, or an optionally named range of versions. Here is an
-   example::
-
-      BBVERSIONS = "1.0 2.0 git"
-      SRC_URI_git = "git://someurl/somepath.git"
-
-      BBVERSIONS = "1.0.[0-6]:1.0.0+ 1.0.[7-9]:1.0.7+"
-      SRC_URI_append_1.0.7+ = "file://some_patch_which_the_new_versions_need.patch;patch=1"
-
-   The name of the range defaults to the original version of the recipe. For
-   example, in OpenEmbedded, the recipe file ``foo_1.0.0+.bb`` creates a default
-   name range of ``1.0.0+``. This is useful because the range name is not only
-   placed into overrides, but it is also made available for the metadata to use
-   in the variable that defines the base recipe versions for use in ``file://``
-   search paths (:term:`FILESPATH`).
-
 Dependencies
 ============
 
@@ -1943,10 +1920,6 @@ The following list describes related variables:
    Specifies a function BitBake calls that determines whether BitBake
    requires a setscene dependency to be met.
 
--  :term:`BB_SETSCENE_VERIFY_FUNCTION2`:
-   Specifies a function to call that verifies the list of planned task
-   execution before the main task execution happens.
-
 -  :term:`BB_STAMP_POLICY`: Defines the mode
    for comparing timestamps of stamp files.
 

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

@@ -23,10 +23,6 @@ overview of their function and contents.
       systems extend the functionality of the variable as it is
       described here in this glossary.
 
-   -  Finally, there are variables mentioned in this glossary that do
-      not appear in the BitBake glossary. These other variables are
-      variables used in systems that use BitBake.
-
 .. glossary::
 
    :term:`ASSUME_PROVIDED`
@@ -313,6 +309,16 @@ overview of their function and contents.
       However, the more accurate the data returned, the more efficient the
       build will be.
 
+   :term:`BB_HASHSERVE`
+      Specifies the Hash Equivalence server to use.
+
+      If set to ``auto``, BitBake automatically starts its own server
+      over a UNIX domain socket.
+
+      If set to ``host:port``, BitBake will use a remote server on the
+      specified host. This allows multiple clients to share the same
+      hash equivalence data.
+
    :term:`BB_INVALIDCONF`
       Used in combination with the ``ConfigParsed`` event to trigger
       re-parsing the base metadata (i.e. all the recipes). The
@@ -426,17 +432,6 @@ overview of their function and contents.
       The function specified by this variable returns a "True" or "False"
       depending on whether the dependency needs to be met.
 
-   :term:`BB_SETSCENE_VERIFY_FUNCTION2`
-      Specifies a function to call that verifies the list of planned task
-      execution before the main task execution happens. The function is
-      called once BitBake has a list of setscene tasks that have run and
-      either succeeded or failed.
-
-      The function allows for a task list check to see if they make sense.
-      Even if BitBake was planning to skip a task, the returned value of
-      the function can force BitBake to run the task, which is necessary
-      under certain metadata defined circumstances.
-
    :term:`BB_SIGNATURE_EXCLUDE_FLAGS`
       Lists variable flags (varflags) that can be safely excluded from
       checksum and dependency data for keys in the datastore. When
@@ -797,16 +792,6 @@ overview of their function and contents.
       Allows you to use a configuration file to add to the list of
       command-line target recipes you want to build.
 
-   :term:`BBVERSIONS`
-      Allows a single recipe to build multiple versions of a project from a
-      single recipe file. You also able to specify conditional metadata
-      using the :term:`OVERRIDES` mechanism for a
-      single version or for an optionally named range of versions.
-
-      For more information on ``BBVERSIONS``, see the
-      ":ref:`bitbake-user-manual/bitbake-user-manual-metadata:variants - class extension mechanism`"
-      section.
-
    :term:`BITBAKE_UI`
       Used to specify the UI module to use when running BitBake. Using this
       variable is equivalent to using the ``-u`` command-line option.

bitbake/lib/bb/asyncrpc/client.py

@@ -103,13 +103,18 @@ class AsyncClient(object):
 
         return await self._send_wrapper(proc)
 
+    async def ping(self):
+        return await self.send_message(
+            {'ping': {}}
+        )
+
 
 class Client(object):
     def __init__(self):
         self.client = self._get_async_client()
         self.loop = asyncio.new_event_loop()
 
-        self._add_methods('connect_tcp', 'close')
+        self._add_methods('connect_tcp', 'close', 'ping')
 
     @abc.abstractmethod
     def _get_async_client(self):

bitbake/lib/bb/asyncrpc/serv.py

@@ -28,6 +28,7 @@ class AsyncServerConnection(object):
         self.max_chunk = DEFAULT_MAX_CHUNK
         self.handlers = {
             'chunk-stream': self.handle_chunk,
+            'ping': self.handle_ping,
         }
         self.logger = logger
 
@@ -123,6 +124,10 @@ class AsyncServerConnection(object):
 
         await self.dispatch_message(msg)
 
+    async def handle_ping(self, request):
+        response = {'alive': True}
+        self.write_message(response)
+
 
 class AsyncServer(object):
     def __init__(self, logger, loop=None):
@@ -142,7 +147,7 @@ class AsyncServer(object):
         )
 
         for s in self.server.sockets:
-            self.logger.info('Listening on %r' % (s.getsockname(),))
+            self.logger.debug('Listening on %r' % (s.getsockname(),))
             # Newer python does this automatically. Do it manually here for
             # maximum compatibility
             s.setsockopt(socket.SOL_TCP, socket.TCP_NODELAY, 1)
@@ -168,7 +173,7 @@ class AsyncServer(object):
         finally:
             os.chdir(cwd)
 
-        self.logger.info('Listening on %r' % path)
+        self.logger.debug('Listening on %r' % path)
 
         self._cleanup_socket = cleanup
         self.address = "unix://%s" % os.path.abspath(path)
@@ -187,7 +192,7 @@ class AsyncServer(object):
             self.logger.error('Error from client: %s' % str(e), exc_info=True)
             traceback.print_exc()
             writer.close()
-        self.logger.info('Client disconnected')
+        self.logger.debug('Client disconnected')
 
     def run_loop_forever(self):
         try:
@@ -207,7 +212,7 @@ class AsyncServer(object):
             self.server.close()
 
             self.loop.run_until_complete(self.server.wait_closed())
-            self.logger.info('Server shutting down')
+            self.logger.debug('Server shutting down')
         finally:
             if self.close_loop:
                 if sys.version_info >= (3, 6):

bitbake/lib/bb/build.py

@@ -927,6 +927,11 @@ def add_tasks(tasklist, d):
                 task_deps[name] = {}
             if name in flags:
                 deptask = d.expand(flags[name])
+                if name in ['noexec', 'fakeroot', 'nostamp']:
+                    if deptask != '1':
+                        bb.warn("In a future version of BitBake, setting the '{}' flag to something other than '1' "
+                                "will result in the flag not being set. See YP bug #13808.".format(name))
+
                 task_deps[name][task] = deptask
         getTask('mcdepends')
         getTask('depends')

bitbake/lib/bb/fetch2/__init__.py

@@ -562,6 +562,9 @@ def verify_checksum(ud, d, precomputed={}):
 
         checksum_expected = getattr(ud, "%s_expected" % checksum_id)
 
+        if checksum_expected == '':
+            checksum_expected = None
+
         return {
             "id": checksum_id,
             "name": checksum_name,
@@ -612,7 +615,7 @@ def verify_checksum(ud, d, precomputed={}):
 
     for ci in checksum_infos:
         if ci["expected"] and ci["expected"] != ci["data"]:
-            messages.append("File: '%s' has %s checksum %s when %s was " \
+            messages.append("File: '%s' has %s checksum '%s' when '%s' was " \
                             "expected" % (ud.localpath, ci["id"], ci["data"], ci["expected"]))
             bad_checksum = ci["data"]
 

documentation/README

@@ -32,7 +32,7 @@ these instances.
 Manual Organization
 ===================
 
-Folders exist for individual manuals as follows:
+Here the folders corresponding to individual manuals:
 
 * sdk-manual           - The Yocto Project Software Development Kit (SDK) Developer's Guide.
 * bsp-guide            - The Yocto Project Board Support Package (BSP) Developer's Guide

documentation/brief-yoctoprojectqs/index.rst

@@ -297,7 +297,7 @@ modular development and makes it easier to reuse the layer metadata.
 
 Follow these steps to add a hardware layer:
 
-#. **Find a Layer:** Lots of hardware layers exist. The Yocto Project
+#. **Find a Layer:** Many hardware layers are available. The Yocto Project
    :yocto_git:`Source Repositories <>` has many hardware layers.
    This example adds the
    `meta-altera <https://github.com/kraj/meta-altera>`__ hardware layer.
@@ -318,8 +318,8 @@ Follow these steps to add a hardware layer:
       Resolving deltas: 100% (13385/13385), done.
       Checking connectivity... done.
 
-   The hardware layer now exists
-   with other layers inside the Poky reference repository on your build
+   The hardware layer is now available
+   next to other layers inside the Poky reference repository on your build
    host as ``meta-altera`` and contains all the metadata needed to
    support hardware from Altera, which is owned by Intel.
 
@@ -431,8 +431,8 @@ information including the website, wiki pages, and user manuals:
    information.
 
 -  **Yocto Project Mailing Lists:** Related mailing lists provide a forum
-   for discussion, patch submission and announcements. Several mailing
-   lists exist and are grouped according to areas of concern. See the
+   for discussion, patch submission and announcements. There are several
+   mailing lists grouped by topic. See the
    :ref:`ref-manual/resources:mailing lists`
    section in the Yocto Project Reference Manual for a complete list of
    Yocto Project mailing lists.

documentation/bsp-guide/bsp.rst

@@ -267,7 +267,7 @@ maintain the distinction that the BSP layer, a build system, and tools
 are separate components that could be combined in certain end products.
 
 Before looking at the recommended form for the directory structure
-inside a BSP layer, you should be aware that some requirements do exist
+inside a BSP layer, you should be aware that there are some requirements
 in order for a BSP layer to be considered compliant with the Yocto
 Project. For that list of requirements, see the
 ":ref:`bsp-guide/bsp:released bsp requirements`" section.
@@ -763,8 +763,8 @@ workflow.
 
    .. note::
 
-      -  Four hardware reference BSPs exist that are part of the Yocto
-         Project release and are located in the ``poky/meta-yocto-bsp``
+      -  There are four hardware reference BSPs in the Yocto
+         Project release, located in the ``poky/meta-yocto-bsp``
          BSP layer:
 
          -  Texas Instruments Beaglebone (``beaglebone-yocto``)
@@ -773,8 +773,8 @@ workflow.
 
          -  Two general IA platforms (``genericx86`` and ``genericx86-64``)
 
-      -  Three core Intel BSPs exist as part of the Yocto Project
-         release in the ``meta-intel`` layer:
+      -  There are three core Intel BSPs in the Yocto Project
+         release, in the ``meta-intel`` layer:
 
          -  ``intel-core2-32``, which is a BSP optimized for the Core2
             family of CPUs as well as all CPUs prior to the Silvermont
@@ -832,10 +832,8 @@ workflow.
 Requirements and Recommendations for Released BSPs
 ==================================================
 
-Certain requirements exist for a released BSP to be considered compliant
-with the Yocto Project. Additionally, recommendations also exist. This
-section describes the requirements and recommendations for released
-BSPs.
+This section describes requirements and recommendations for a released
+BSP to be considered compliant with the Yocto Project.
 
 Released BSP Requirements
 -------------------------
@@ -864,7 +862,7 @@ Before looking at BSP requirements, you should consider the following:
 
 -  It is not required that specific packages or package modifications
    exist in the BSP layer, beyond the requirements for general
-   compliance with the Yocto Project. For example, no requirement exists
+   compliance with the Yocto Project. For example, there is no requirement
    dictating that a specific kernel or kernel version be used in a given
    BSP.
 
@@ -900,7 +898,7 @@ Yocto Project:
 -  *License File:* You must include a license file in the
    ``meta-bsp_root_name`` directory. This license covers the BSP
    Metadata as a whole. You must specify which license to use since no
-   default license exists when one is not specified. See the
+   default license exists. See the
    :yocto_git:`COPYING.MIT </meta-raspberrypi/tree/COPYING.MIT>`
    file for the Raspberry Pi BSP in the ``meta-raspberrypi`` BSP layer
    as an example.
@@ -1107,7 +1105,7 @@ system requirements.
    unsuitable functionality or quality, you can use an encumbered
    version.
 
-A couple different methods exist within the OpenEmbedded build system to
+There are two different methods within the OpenEmbedded build system to
 satisfy the licensing requirements for an encumbered BSP. The following
 list describes them in order of preference:
 
@@ -1186,11 +1184,11 @@ Use these steps to create a BSP layer:
 -  *Create a Machine Configuration File:* Create a
    ``conf/machine/bsp_root_name.conf`` file. See
    :yocto_git:`meta-yocto-bsp/conf/machine </poky/tree/meta-yocto-bsp/conf/machine>`
-   for sample ``bsp_root_name.conf`` files. Other samples such as
+   for sample ``bsp_root_name.conf`` files. There are other samples such as
    :yocto_git:`meta-ti </meta-ti/tree/conf/machine>`
    and
    :yocto_git:`meta-freescale </meta-freescale/tree/conf/machine>`
-   exist from other vendors that have more specific machine and tuning
+   from other vendors that have more specific machine and tuning
    examples.
 
 -  *Create a Kernel Recipe:* Create a kernel recipe in
@@ -1241,7 +1239,7 @@ As mentioned earlier in this section, the existence of a machine
 configuration file is what makes a layer a BSP layer as compared to a
 general or kernel layer.
 
-One or more machine configuration files exist in the
+There are one or more machine configuration files in the
 ``bsp_layer/conf/machine/`` directory of the layer::
 
    bsp_layer/conf/machine/machine1\.conf
@@ -1311,7 +1309,7 @@ Project Reference Manual.
 -  :term:`PREFERRED_PROVIDER_virtual/xserver <PREFERRED_PROVIDER>`:
    The recipe that provides "virtual/xserver" when more than one
    provider is found. In this case, the recipe that provides
-   "virtual/xserver" is "xserver-xorg", which exists in
+   "virtual/xserver" is "xserver-xorg", available in
    ``poky/meta/recipes-graphics/xorg-xserver``.
 
 -  :term:`XSERVER`: The packages that
@@ -1326,7 +1324,7 @@ Project Reference Manual.
 
    .. tip::
 
-      Many ``MACHINE*`` variables exist that help you configure a particular piece
+      There are many ``MACHINE*`` variables that help you configure a particular piece
       of hardware.
 
 -  :term:`EXTRA_IMAGEDEPENDS`:
@@ -1339,9 +1337,9 @@ Project Reference Manual.
 -  :term:`DEFAULTTUNE`: Machines
    use tunings to optimize machine, CPU, and application performance.
    These features, which are collectively known as "tuning features",
-   exist in the :term:`OpenEmbedded-Core (OE-Core)` layer (e.g.
+   are set in the :term:`OpenEmbedded-Core (OE-Core)` layer (e.g.
    ``poky/meta/conf/machine/include``). In this example, the default
-   tuning file is "cortexa8hf-neon".
+   tuning file is ``cortexa8hf-neon``.
 
    .. note::
 

documentation/dev-manual/common-tasks.rst

@@ -346,7 +346,7 @@ The application consists of the following sections:
    of the Yocto Project for which your layer is compatible.
 
 -  *Acceptance Criteria:* Provide "Yes" or "No" answers for each of the
-   items in the checklist. Space exists at the bottom of the form for
+   items in the checklist. There is space at the bottom of the form for
    any explanations for items for which you answered "No".
 
 -  *Recommendations:* Provide answers for the questions regarding Linux
@@ -542,7 +542,7 @@ important as it ensures that items in the list remain colon-separated.
    paths in the final list.
 
    Also, not all append files add extra files. Many append files simply
-   exist to add build options (e.g. ``systemd``). For these cases, your
+   allow to add build options (e.g. ``systemd``). For these cases, your
    append file would not even use the ``FILESEXTRAPATHS`` statement.
 
 Prioritizing Your Layer
@@ -1060,8 +1060,8 @@ The remainder of the section provides details for the steps.
 Locate or Automatically Create a Base Recipe
 --------------------------------------------
 
-You can always write a recipe from scratch. However, three choices exist
-that can help you quickly get a start on a new recipe:
+You can always write a recipe from scratch. However, there are three choices
+that can help you quickly get started with a new recipe:
 
 -  ``devtool add``: A command that assists in creating a recipe and an
    environment conducive to development.
@@ -1521,8 +1521,8 @@ software is built; and runtime dependencies, which are required to be
 installed on the target in order for the software to run.
 
 Within a recipe, you specify build-time dependencies using the
-:term:`DEPENDS` variable. Although
-nuances exist, items specified in ``DEPENDS`` should be names of other
+:term:`DEPENDS` variable. Although there are nuances,
+items specified in ``DEPENDS`` should be names of other
 recipes. It is important that you specify all build-time dependencies
 explicitly.
 
@@ -2183,8 +2183,8 @@ script to first boot is undesirable and for read-only rootfs impossible.
 
 .. note::
 
-   Equivalent support for pre-install, pre-uninstall, and post-uninstall
-   scripts exist by way of ``pkg_preinst``, ``pkg_prerm``, and ``pkg_postrm``,
+   There is equivalent support for pre-install, pre-uninstall, and post-uninstall
+   scripts by way of ``pkg_preinst``, ``pkg_prerm``, and ``pkg_postrm``,
    respectively. These scrips work in exactly the same way as does
    ``pkg_postinst`` with the exception that they run at different times. Also,
    because of when they run, they are not applicable to being run at image
@@ -2376,7 +2376,7 @@ Packaging Externally Produced Binaries
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Sometimes, you need to add pre-compiled binaries to an image. For
-example, suppose that binaries for proprietary code exist, which are
+example, suppose that there are binaries for proprietary code,
 created by a particular division of a company. Your part of the company
 needs to use those binaries as part of an image that you are building
 using the OpenEmbedded build system. Since you only have the binaries
@@ -2832,7 +2832,7 @@ Over time, upstream developers publish new versions for software built
 by layer recipes. It is recommended to keep recipes up-to-date with
 upstream version releases.
 
-While several methods exist that allow you upgrade a recipe, you might
+While there are several methods to upgrade a recipe, you might
 consider checking on the upgrade status of a recipe first. You can do so
 using the ``devtool check-upgrade-status`` command. See the
 ":ref:`devtool-checking-on-the-upgrade-status-of-a-recipe`"
@@ -2861,8 +2861,8 @@ commit messages in the layer's tree for the changes made to recipes.
 
 .. note::
 
-   Conditions do exist when you should not use AUH to upgrade recipes
-   and you should instead use either ``devtool upgrade`` or upgrade your
+   In some conditions, you should not use AUH to upgrade recipes
+   and should instead use either ``devtool upgrade`` or upgrade your
    recipes manually:
 
    -  When AUH cannot complete the upgrade sequence. This situation
@@ -2922,7 +2922,7 @@ The following steps describe how to set up the AUH utility:
    undesirably.
 
 5. *Make Configurations in Your Local Configuration File:* Several
-   settings need to exist in the ``local.conf`` file in the build
+   settings are needed in the ``local.conf`` file in the build
    directory you just created for AUH. Make these following
    configurations:
 
@@ -3131,8 +3131,8 @@ newly upgraded recipe::
    NOTE: nano: compiling from external source tree /home/scottrif/poky/build/workspace/sources/nano
    NOTE: Tasks Summary: Attempted 520 tasks of which 304 didn't need to be rerun and all succeeded.
 
-Within the ``devtool upgrade`` workflow, opportunity
-exists to deploy and test your rebuilt software. For this example,
+Within the ``devtool upgrade`` workflow, you can
+deploy and test your rebuilt software. For this example,
 however, running ``devtool finish`` cleans up the workspace once the
 source in your workspace is clean. This usually means using Git to stage
 and submit commits for the changes generated by the upgrade process.
@@ -3214,7 +3214,7 @@ To manually upgrade recipe versions, follow these general steps:
    if the recipe is to be released publicly.
 
 5. *Check the Upstream Change Log or Release Notes:* Checking both these
-   reveals if new features exist that could break
+   reveals if there are new features that could break
    backwards-compatibility. If so, you need to take steps to mitigate or
    eliminate that situation.
 
@@ -3517,7 +3517,7 @@ Building a Simple Image
 
 In the development environment, you need to build an image whenever you
 change hardware support, add or change system libraries, or add or
-change services that have dependencies. Several methods exist that allow
+change services that have dependencies. There are several methods that allow
 you to build an image within the Yocto Project. This section presents
 the basic steps you need to build a simple image using BitBake from a
 build host running Linux.
@@ -4215,7 +4215,7 @@ your tunings to best consider build times and package feed maintenance.
    sysroot for each machine is generated, the software is not recompiled
    and only one package feed exists.
 
--  *Manage Granular Level Packaging:* Sometimes cases exist where
+-  *Manage Granular Level Packaging:* Sometimes there are cases where
    injecting another level of package architecture beyond the three
    higher levels noted earlier can be useful. For example, consider how
    NXP (formerly Freescale) allows for the easy reuse of binary packages
@@ -4281,7 +4281,7 @@ By default, the OpenEmbedded build system uses the
 code. The build process involves fetching the source files, unpacking
 them, and then patching them if necessary before the build takes place.
 
-Situations exist where you might want to build software from source
+There are situations where you might want to build software from source
 files that are external to and thus outside of the OpenEmbedded build
 system. For example, suppose you have a project that includes a new BSP
 with a heavily customized kernel. And, you want to minimize exposing the
@@ -4648,7 +4648,7 @@ libraries and other binaries to use a different set of libraries. The
 libraries could differ in architecture, compiler options, or other
 optimizations.
 
-Several examples exist in the ``meta-skeleton`` layer found in the
+There are several examples in the ``meta-skeleton`` layer found in the
 :term:`Source Directory`:
 
 -  ``conf/multilib-example.conf`` configuration file
@@ -4661,7 +4661,7 @@ Preparing to Use Multilib
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 
 User-specific requirements drive the Multilib feature. Consequently,
-there is no one "out-of-the-box" configuration that likely exists to
+there is no one "out-of-the-box" configuration that would
 meet your needs.
 
 In order to enable Multilib, you first need to ensure your recipe is
@@ -4724,8 +4724,8 @@ specifically with a command like this::
 Additional Implementation Details
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Generic implementation details as well as details that are specific to
-package management systems exist. Following are implementation details
+There are generic implementation details as well as details that are specific to
+package management systems. Following are implementation details
 that exist regardless of the package management system:
 
 -  The typical convention used for the class extension code as used by
@@ -4742,8 +4742,7 @@ that exist regardless of the package management system:
    vendor string presently break Autoconf's ``config.sub``, and other
    separators are problematic for different reasons.
 
-For the RPM Package Management System, the following implementation
-details exist:
+Here are the implementation details for the RPM Package Management System:
 
 -  A unique architecture is defined for the Multilib packages, along
    with creating a unique deploy folder under ``tmp/deploy/rpm`` in the
@@ -4764,8 +4763,7 @@ details exist:
 -  The build system relies on RPM to resolve the identical files in the
    two (or more) Multilib packages.
 
-For the IPK Package Management System, the following implementation
-details exist:
+Here are the implementation details for the IPK Package Management System:
 
 -  The ``${MLPREFIX}`` is not stripped from ``${PN}`` during IPK
    packaging. The naming for a normal RPM package and a Multilib IPK
@@ -4783,9 +4781,9 @@ details exist:
 Installing Multiple Versions of the Same Library
 ------------------------------------------------
 
-Situations can exist where you need to install and use multiple versions
-of the same library on the same system at the same time. These
-situations almost always exist when a library API changes and you have
+There are be situations where you need to install and use multiple versions
+of the same library on the same system at the same time. This
+almost always happens when a library API changes and you have
 multiple pieces of software that depend on the separate versions of the
 library. To accommodate these situations, you can install multiple
 versions of the same library in parallel on the same system.
@@ -4850,9 +4848,9 @@ follows:
 -  You can create and boot ``core-image-minimal`` and
    ``core-image-sato`` images.
 
--  RPM Package Manager (RPM) support exists for x32 binaries.
+-  There is RPM Package Manager (RPM) support for x32 binaries.
 
--  Support for large images exists.
+-  There is support for large images.
 
 To use the x32 psABI, you need to edit your ``conf/local.conf``
 configuration file as follows::
@@ -4918,7 +4916,7 @@ library package involves the following:
    :term:`DISTRO_FEATURES_BACKFILL_CONSIDERED`
    and that "qemu-usermode" is not in
    :term:`MACHINE_FEATURES_BACKFILL_CONSIDERED`.
-   If either of these conditions exist, nothing will happen.
+   In either of these conditions, nothing will happen.
 
 3. Try to build the recipe. If you encounter build errors that look like
    something is unable to find ``.so`` libraries, check where these
@@ -5005,7 +5003,7 @@ working in an image:
 Known Issues
 ------------
 
-The following know issues exist for GObject Introspection Support:
+Here are know issues in GObject Introspection Support:
 
 -  ``qemu-ppc64`` immediately crashes. Consequently, you cannot build
    introspection data on that architecture.
@@ -5184,7 +5182,7 @@ For example, the following returns overview help for Wic::
 
    $ wic help overview
 
-One additional level of help exists for Wic. You can get help on
+There is one additional level of help for Wic. You can get help on
 individual images through the ``list`` command. You can use the ``list``
 command to return the available Wic images as follows::
 
@@ -5872,8 +5870,8 @@ your image more secure.
 General Considerations
 ----------------------
 
-General considerations exist that help you create more secure images.
-You should consider the following suggestions to help make your device
+There are general considerations that help you create more secure images.
+You should consider the following suggestions to make your device
 more secure:
 
 -  Scan additional code you are adding to the system (e.g. application
@@ -6210,8 +6208,8 @@ or to not install a package at all.
 
 The following list introduces variables you can use to prevent packages
 from being installed into your image. Each of these variables only works
-with IPK and RPM package types. Support for Debian packages does not
-exist. Also, you can use these variables from your ``local.conf`` file
+with IPK and RPM package types, not for Debian packages.
+Also, you can use these variables from your ``local.conf`` file
 or attach them to a specific image recipe by using a recipe name
 override. For more detail on the variables, see the descriptions in the
 Yocto Project Reference Manual's glossary chapter.
@@ -6285,7 +6283,7 @@ maintain a package feed that is compatible with existing package manager
 applications such as RPM, APT, and OPKG, using an automated system is
 much preferred over a manual system. In either system, the main
 requirement is that binary package version numbering increases in a
-linear fashion and that a number of version components exist that
+linear fashion and that there is a number of version components that
 support that linear progression. For information on how to ensure
 package revisioning remains linear, see the
 ":ref:`dev-manual/common-tasks:automatically incrementing a package version number`"
@@ -6342,7 +6340,7 @@ generated are just "self consistent". The build system adds and removes
 packages and there are no guarantees about upgrade paths but images will
 be consistent and correct with the latest changes.
 
-The simplest form for a PR Service is for it to exist for a single host
+The simplest form for a PR Service is for a single host
 development system that builds the package feed (building system). For
 this scenario, you can enable a local PR Service by setting
 :term:`PRSERV_HOST` in your
@@ -6545,7 +6543,7 @@ The previous example specifies a number of things in the call to
    "Lighttpd module for alias".
 
 Often, packaging modules is as simple as the previous example. However,
-more advanced options exist that you can use within
+there are more advanced options that you can use within
 ``do_split_packages`` to modify its behavior. And, if you need to, you
 can add more logic by specifying a hook function that is called for each
 package. It is also perfectly acceptable to call ``do_split_packages``
@@ -7024,7 +7022,7 @@ file::
    `passphrase`.
 
 Aside from the ``RPM_GPG_NAME`` and ``RPM_GPG_PASSPHRASE`` variables in
-the previous example, two optional variables related to signing exist:
+the previous example, two optional variables related to signing are available:
 
 -  *GPG_BIN:* Specifies a ``gpg`` binary/wrapper that is executed
    when the package is signed.
@@ -7046,14 +7044,14 @@ your ``local.config`` or ``distro.config`` file::
    PACKAGE_FEED_GPG_NAME = "key_name"
    PACKAGE_FEED_GPG_PASSPHRASE_FILE = "path_to_file_containing_passphrase"
 
-For signed package feeds, the passphrase must exist in a separate file,
+For signed package feeds, the passphrase must be specified in a separate file,
 which is pointed to by the ``PACKAGE_FEED_GPG_PASSPHRASE_FILE``
 variable. Regarding security, keeping a plain text passphrase out of the
 configuration is more secure.
 
 Aside from the ``PACKAGE_FEED_GPG_NAME`` and
 ``PACKAGE_FEED_GPG_PASSPHRASE_FILE`` variables, three optional variables
-related to signed package feeds exist:
+related to signed package feeds are available:
 
 -  *GPG_BIN* Specifies a ``gpg`` binary/wrapper that is executed
    when the package is signed.
@@ -7192,7 +7190,7 @@ use this fetcher in combination with
 :doc:`devtool </ref-manual/devtool-reference>` to create
 recipes that produce NPM packages.
 
-Two workflows exist that allow you to create NPM packages using
+There are two workflows that allow you to create NPM packages using
 ``devtool``: the NPM registry modules method and the NPM project code
 method.
 
@@ -7296,7 +7294,7 @@ The ``devtool edit-recipe`` command lets you take a look at the recipe::
    ...
    LICENSE_${PN}-vary = "MIT"
 
-Three key points exist in the previous example:
+Here are three key points in the previous example:
 
 -  :term:`SRC_URI` uses the NPM
    scheme so that the NPM fetcher is used.
@@ -7488,7 +7486,7 @@ Selecting an Initialization Manager
 ===================================
 
 By default, the Yocto Project uses SysVinit as the initialization
-manager. However, support also exists for systemd, which is a full
+manager. However, there is also support for systemd, which is a full
 replacement for init with parallel starting of services, reduced shell
 overhead and other features that are used by many distributions.
 
@@ -7794,7 +7792,7 @@ link to the built library and that library will be pulled into your
 image along with the new software even if you did not want the library.
 
 The :ref:`buildhistory <ref-classes-buildhistory>`
-class exists to help you maintain the quality of your build output. You
+class helps you maintain the quality of your build output. You
 can use the class to highlight unexpected and possibly unwanted changes
 in the build output. When you enable build history, it records
 information about the contents of each package and image and then
@@ -7849,7 +7847,7 @@ variable. Here is an example abbreviated listing:
 .. image:: figures/buildhistory.png
    :align: center
 
-At the top level, a ``metadata-revs`` file exists that lists the
+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
 produced. The rest of the data splits into separate ``packages``,
 ``images`` and ``sdk`` directories, the contents of which are described
@@ -7885,7 +7883,7 @@ The exceptions are ``FILELIST``, which is the actual list of files in
 the package, and ``PKGSIZE``, which is the total size of files in the
 package in bytes.
 
-A file also exists that corresponds to the recipe from which the package
+There is also a file that corresponds to the recipe from which the package
 came (e.g. ``buildhistory/packages/i586-poky-linux/busybox/latest``):
 
 .. code-block:: none
@@ -7900,8 +7898,8 @@ came (e.g. ``buildhistory/packages/i586-poky-linux/busybox/latest``):
       busybox-staticdev busybox-dev busybox-doc busybox-locale busybox
 
 Finally, for those recipes fetched from a version control system (e.g.,
-Git), a file exists that lists source revisions that are specified in
-the recipe and lists the actual revisions used during the build. Listed
+Git), there is a file that lists source revisions that are specified in
+the recipe and the actual revisions used during the build. Listed
 and actual revisions might differ when
 :term:`SRCREV` is set to
 ${:term:`AUTOREV`}. Here is an
@@ -8141,7 +8139,7 @@ You need to realize,
 however, that this method does show changes that are not significant
 (e.g. a package's size changing by a few bytes).
 
-A command-line tool called ``buildhistory-diff`` does exist, though,
+There is a command-line tool called ``buildhistory-diff``, though,
 that queries the Git repository and prints just the differences that
 might be significant in human-readable form. Here is an example::
 
@@ -8315,7 +8313,7 @@ the MAC address of the device.
 In order to run tests on hardware, you need to set ``TEST_TARGET`` to an
 appropriate value. For QEMU, you do not have to change anything, the
 default value is "qemu". For running tests on hardware, the following
-options exist:
+options are available:
 
 -  *"simpleremote":* Choose "simpleremote" if you are going to run tests
    on a target system that is already running the image to be tested and
@@ -8639,7 +8637,7 @@ layer's ``layer.conf`` file as normal). Just remember the following:
 
 -  Do not use module names that collide with existing core tests.
 
--  Minimally, an empty ``__init__.py`` file must exist in the runtime
+-  Minimally, an empty ``__init__.py`` file must be present in the runtime
    directory.
 
 To create a new test, start by copying an existing module (e.g.
@@ -8719,7 +8717,7 @@ Class attributes are as follows:
 Instance Attributes
 ~~~~~~~~~~~~~~~~~~~
 
-A single instance attribute exists, which is ``target``. The ``target``
+There is a single instance attribute, which is ``target``. The ``target``
 instance attribute is identical to the class attribute of the same name,
 which is described in the previous section. This attribute exists as
 both an instance and class attribute so tests can use
@@ -9348,7 +9346,7 @@ Recipe Logging Mechanisms
 
 The Yocto Project provides several logging functions for producing
 debugging output and reporting errors and warnings. For Python
-functions, the following logging functions exist. All of these functions
+functions, the following logging functions are available. All of these functions
 log to ``${T}/log.do_``\ `task`, and can also log to standard output
 (stdout) with the right settings:
 
@@ -9454,8 +9452,8 @@ A parallel ``make`` race occurs when the build consists of several parts
 that are run simultaneously and a situation occurs when the output or
 result of one part is not ready for use with a different part of the
 build that depends on that output. Parallel make races are annoying and
-can sometimes be difficult to reproduce and fix. However, some simple
-tips and tricks exist that can help you debug and fix them. This section
+can sometimes be difficult to reproduce and fix. However, there are some simple
+tips and tricks that can help you debug and fix them. This section
 presents a real-world example of an error encountered on the Yocto
 Project autobuilder and the process used to fix it.
 
@@ -9578,7 +9576,7 @@ In the ``devshell``, do the following::
    $ make tools/snep-send.o
 
 The ``devshell`` commands cause the failure to clearly
-be visible. In this case, a missing dependency exists for the "neard"
+be visible. In this case, there is a missing dependency for the ``neard``
 Makefile target. Here is some abbreviated, sample output with the
 missing dependency clearly visible at the end::
 
@@ -9623,9 +9621,8 @@ patch::
    $ quilt refresh
    Refreshed patch patches/parallelmake.patch
 
-Once
-the patch file exists, you need to add it back to the originating recipe
-folder. Here is an example assuming a top-level
+Once the patch file is created, you need to add it back to the originating
+recipe folder. Here is an example assuming a top-level
 :term:`Source Directory` named ``poky``::
 
    $ cp patches/parallelmake.patch poky/meta/recipes-connectivity/neard/neard
@@ -10119,7 +10116,7 @@ specific uses.
 
 The Yocto Project uses a mailing list and a patch-based workflow that is
 similar to the Linux kernel but contains important differences. In
-general, a mailing list exists through which you can submit patches. You
+general, there is a mailing list through which you can submit patches. You
 should send patches to the appropriate mailing list so that they can be
 reviewed and merged by the appropriate maintainer. The specific mailing
 list you need to use depends on the location of the code you are
@@ -10796,8 +10793,8 @@ Here are some other scenarios:
 Other Variables Related to Commercial Licenses
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Other helpful variables related to commercial license handling exist and
-are defined in the
+There are other helpful variables related to commercial license handling,
+defined in the
 ``poky/meta/conf/distro/include/default-distrovars.inc`` file::
 
    COMMERCIAL_AUDIO_PLUGINS ?= ""
@@ -10841,7 +10838,7 @@ requirements during a software release.
 With hundreds of different open source licenses that the Yocto Project
 tracks, it is difficult to know the requirements of each and every
 license. However, the requirements of the major FLOSS licenses can begin
-to be covered by assuming that three main areas of concern exist:
+to be covered by assuming that there are three main areas of concern:
 
 -  Source code must be provided.
 
@@ -11105,9 +11102,9 @@ portion is integrated with the installed Yocto Project
 The server receives the information collected and saves it in a
 database.
 
-A live instance of the error reporting server exists at
-https://errors.yoctoproject.org. This server exists so that when
-you want to get help with build failures, you can submit all of the
+There is a live instance of the error reporting server at
+https://errors.yoctoproject.org.
+When you want to get help with build failures, you can submit all of the
 information on the failure easily and then point to the URL in your bug
 report or send an email to the mailing list.
 

documentation/dev-manual/qemu.rst

@@ -275,7 +275,7 @@ present, the toolchain is also automatically used.
 
 .. note::
 
-   Several mechanisms exist that let you connect to the system running
+   There are several mechanisms to connect to the system running
    on the QEMU emulator:
 
    -  QEMU provides a framebuffer interface that makes standard consoles
@@ -286,7 +286,7 @@ present, the toolchain is also automatically used.
       that port to run a console. The connection uses standard IP
       networking.
 
-   -  SSH servers exist in some QEMU images. The ``core-image-sato``
+   -  SSH servers are available in some QEMU images. The ``core-image-sato``
       QEMU image has a Dropbear secure shell (SSH) server that runs with
       the root password disabled. The ``core-image-full-cmdline`` and
       ``core-image-lsb`` QEMU images have OpenSSH instead of Dropbear.

documentation/dev-manual/start.rst

@@ -36,7 +36,7 @@ particular working environment and set of practices.
     equipment together and set up your development environment's
     hardware topology.
 
-    The following roles exist:
+    Here are possible roles:
 
     -  *Application Developer:* This type of developer does application
        level work on top of an existing software stack.
@@ -99,8 +99,7 @@ particular working environment and set of practices.
     .. note::
 
        The setup of these services is beyond the scope of this manual.
-       However, sites such as the following exist that describe how to
-       perform setup:
+       However, here are sites describing how to perform setup:
 
        -  `Gitolite <https://gitolite.com>`__: Information for
           ``gitolite``.
@@ -190,7 +189,7 @@ particular working environment and set of practices.
     develop locally using their primary development system.
 
 9.  *Document Policies and Change Flow:* The Yocto Project uses a
-    hierarchical structure and a pull model. Scripts exist to create and
+    hierarchical structure and a pull model. There are scripts to create and
     send pull requests (i.e. ``create-pull-request`` and
     ``send-pull-request``). This model is in line with other open source
     projects where maintainers are responsible for specific areas of the
@@ -215,8 +214,8 @@ particular working environment and set of practices.
     someone else in the community needs them also.
 
 10. *Development Environment Summary:* Aside from the previous steps,
-    some best practices exist within the Yocto Project development
-    environment. Consider the following:
+    here are best practices within the Yocto Project development
+    environment:
 
     -  Use :ref:`overview-manual/development-environment:git` as the source control
        system.
@@ -607,8 +606,8 @@ of a given component.
 
    The recommended method for accessing Yocto Project components is to
    use Git to clone the upstream repository and work from within that
-   locally cloned repository. The procedure in this section exists
-   should you desire a tarball snapshot of any given component.
+   locally cloned repository. However, this section documents how to
+   use a tarball snapshot of any given component.
 
 Follow these steps to locate and download a particular tarball:
 
@@ -645,13 +644,6 @@ release. Rather than Git repositories, these files represent snapshot
 tarballs similar to the tarballs located in the Index of Releases
 described in the ":ref:`dev-manual/start:accessing index of releases`" section.
 
-.. note::
-
-   The recommended method for accessing Yocto Project components is to
-   use Git to clone a repository and work from within that local
-   repository. The procedure in this section exists should you desire a
-   tarball snapshot of any given component.
-
 1. *Go to the Yocto Project Website:* Open The
    :yocto_home:`Yocto Project Website <>` in your browser.
 
@@ -750,8 +742,8 @@ Follow these steps to create a local version of the upstream
    ":ref:`dev-manual/start:checking out by tag in poky`" sections, respectively.
 
    Once the local repository is created, you can change to that
-   directory and check its status. Here, the single "master" branch
-   exists on your system and by default, it is checked out::
+   directory and check its status. The ``master`` branch is checked out
+   by default::
 
       $ cd poky
       $ git status

documentation/index.rst

@@ -38,16 +38,14 @@ Welcome to the Yocto Project Documentation
 
 .. toctree::
    :maxdepth: 1
-   :caption: 'Mega' Manual
+   :caption: Releases manual
+   :hidden:
 
-   All-in-one 'Mega' Manual <https://docs.yoctoproject.org/singleindex.html>
+   releases
 
 .. toctree::
    :maxdepth: 1
-   :caption: Manuals/Variable Index
+   :caption: Documentation Index
+   :hidden:
 
    genindex
-   Current/Previous Version Specific Manuals <releases>
-
-
-

documentation/kernel-dev/advanced.rst

@@ -21,7 +21,7 @@ is the ``yocto-kernel-cache`` Git repository. You can find this repository
 grouped under the "Yocto Linux Kernel" heading in the
 :yocto_git:`Yocto Project Source Repositories <>`.
 
-Kernel development tools ("kern-tools") exist also in the Yocto Project
+Kernel development tools ("kern-tools") are also available in the Yocto Project
 Source Repositories under the "Yocto Linux Kernel" heading in the
 ``yocto-kernel-tools`` Git repository. The recipe that builds these
 tools is ``meta/recipes-kernel/kern-tools/kern-tools-native_git.bb`` in
@@ -313,7 +313,7 @@ The following listings show the ``build.scc`` file and part of the
 
 The description file can
 include multiple patch statements where each statement handles a single
-patch. In the example ``build.scc`` file, five patch statements exist
+patch. In the example ``build.scc`` file, there are five patch statements
 for the five patches in the directory.
 
 You can create a typical ``.patch`` file using ``diff -Nurp`` or
@@ -509,8 +509,8 @@ description as meeting the criteria set by the recipe being built. This
 example supports the "beaglebone" machine for the "standard" kernel and
 the "arm" architecture.
 
-Be aware that a hard link between the ``KTYPE`` variable and a kernel
-type description file does not exist. Thus, if you do not have the
+Be aware that there is no hard link between the ``KTYPE`` variable and a kernel
+type description file. Thus, if you do not have the
 kernel type defined in your kernel Metadata as it is here, you only need
 to ensure that the
 :term:`LINUX_KERNEL_TYPE`
@@ -776,8 +776,8 @@ patches in every kernel you build (i.e. have the patches as part of the
 lone "master" branch). It is situations like these that give rise to
 multiple branches used within a Linux kernel sources Git repository.
 
-Repository organization strategies exist that maximize source reuse,
-remove redundancy, and logically order your changes. This section
+Here are repository organization strategies maximizing source reuse,
+removing redundancy, and logically ordering your changes. This section
 presents strategies for the following cases:
 
 -  Encapsulating patches in a feature description and only including the

documentation/kernel-dev/common.rst

@@ -578,7 +578,7 @@ recipe is processed.
 
 .. note::
 
-   Other methods exist to accomplish grouping and defining configuration
+   There are other ways of grouping and defining configuration
    options. For example, if you are working with a local clone of the
    kernel repository, you could checkout the kernel's ``meta`` branch,
    make your changes, and then push the changes to the local bare clone
@@ -781,8 +781,8 @@ the ":ref:`kernel-dev/common:getting ready to develop using \`\`devtool\`\``" Se
 
    .. note::
 
-      During the checkout operation, a bug exists that could cause
-      errors such as the following to appear:
+      During the checkout operation, there is a bug that could cause
+      errors such as the following:
 
       .. code-block:: none
 
@@ -1306,7 +1306,7 @@ steps:
       $ bitbake linux-yocto -c kernel_configme -f
 
    This step ensures that you create a
-   ``.config`` file from a known state. Because situations exist where
+   ``.config`` file from a known state. Because there are situations where
    your build state might become unknown, it is best to run this task
    prior to starting ``menuconfig``.
 
@@ -1536,7 +1536,7 @@ Working with a "Dirty" Kernel Version String
 ============================================
 
 If you build a kernel image and the version string has a "+" or a
-"-dirty" at the end, uncommitted modifications exist in the kernel's
+"-dirty" at the end, it means there are uncommitted modifications in the kernel's
 source directory. Follow these steps to clean up the version string:
 
 1. *Discover the Uncommitted Changes:* Go to the kernel's locally cloned
@@ -1615,7 +1615,7 @@ Here are some basic steps you can use to work with your own sources:
 
    Running the ``make defconfig`` command results in the default
    configuration for your architecture as defined by your kernel.
-   However, no guarantee exists that this configuration is valid for
+   However, there is no guarantee that this configuration is valid for
    your use case, or that your board will even boot. This is
    particularly true for non-x86 architectures.
 

documentation/kernel-dev/concepts-appx.rst

@@ -213,7 +213,7 @@ BSP-specific commits. In other words, the divisions of the kernel are
 transparent and are not relevant to the developer on a day-to-day basis.
 From the developer's perspective, this path is the "master" branch in
 Git terms. The developer does not need to be aware of the existence of
-any other branches at all. Of course, value exists in the having these
+any other branches at all. Of course, it can make sense to have these
 branches in the tree, should a person decide to explore them. For
 example, a comparison between two BSPs at either the commit level or at
 the line-by-line code ``diff`` level is now a trivial operation.

documentation/kernel-dev/intro.rst

@@ -66,9 +66,9 @@ from the continual kernel integration and testing performed during
 development of the Yocto Project.
 
 If, instead, you have a very specific Linux kernel source tree and are
-unable to align with one of the official Yocto Linux kernel recipes, an
-alternative exists by which you can use the Yocto Project Linux kernel
-tools with your own kernel sources.
+unable to align with one of the official Yocto Linux kernel recipes,
+you have a way to use the Yocto Project Linux kernel tools with your
+own kernel sources.
 
 The remainder of this manual provides instructions for completing
 specific Linux kernel development tasks. These instructions assume you

documentation/kernel-dev/maint-appx.rst

@@ -175,7 +175,7 @@ Build Strategy
 Once you have cloned a Yocto Linux kernel repository and the cache
 repository (``yocto-kernel-cache``) onto your development system, you
 can consider the compilation phase of kernel development, which is
-building a kernel image. Some prerequisites exist that are validated by
+building a kernel image. Some prerequisites are validated by
 the build process before compilation starts:
 
 -  The :term:`SRC_URI` points to the
@@ -194,7 +194,7 @@ the build process before compilation starts:
       In the previous example, the "yocto-4.12" branch is checked out in
       the ``yocto-kernel-cache`` repository.
 
-The OpenEmbedded build system makes sure these conditions exist before
+The OpenEmbedded build system makes sure these conditions are satisfied before
 attempting compilation. Other means, however, do exist, such as
 bootstrapping a BSP.
 

documentation/overview-manual/concepts.rst

@@ -139,7 +139,7 @@ hardware-specific configurations allows you to share other metadata by
 using a different layer where that metadata might be common across
 several pieces of hardware.
 
-Many layers exist that work in the Yocto Project development environment. The
+There are many layers working in the Yocto Project development environment. The
 :yocto_home:`Yocto Project Curated Layer Index </software-overview/layers/>`
 and :oe_layerindex:`OpenEmbedded Layer Index <>` both contain layers from
 which you can use or leverage.
@@ -370,7 +370,7 @@ BitBake's global behavior. This section takes a closer look at the
 layers the build system uses to further control the build. These layers
 provide Metadata for the software, machine, and policies.
 
-In general, three types of layer input exists. You can see them below
+In general, there are three types of layer input. You can see them below
 the "User Configuration" box in the `general workflow
 figure <overview-manual/concepts:openembedded build system concepts>`:
 
@@ -427,8 +427,8 @@ Repositories <>` also shows layers categorized under "Yocto Metadata Layers."
 
 .. note::
 
-   Layers exist in the Yocto Project Source Repositories that cannot be
-   found in the OpenEmbedded Layer Index. These layers are either
+   There are layers in the Yocto Project Source Repositories that cannot be
+   found in the OpenEmbedded Layer Index. Such layers are either
    deprecated or experimental in nature.
 
 BitBake uses the ``conf/bblayers.conf`` file, which is part of the user
@@ -489,7 +489,7 @@ the machine (``conf/machine/machine.conf``) and, of course, the layer
 
 The remainder of the layer is dedicated to specific recipes by function:
 ``recipes-bsp``, ``recipes-core``, ``recipes-graphics``,
-``recipes-kernel``, and so forth. Metadata can exist for multiple
+``recipes-kernel``, and so forth. There can be metadata for multiple
 formfactors, graphics support systems, and so forth.
 
 .. note::
@@ -528,9 +528,7 @@ project that is more dynamic or experimental in nature, a project might
 keep source files in a repository controlled by a Source Control Manager
 (SCM) such as Git. Pulling source from a repository allows you to
 control the point in the repository (the revision) from which you want
-to build software. Finally, a combination of the two might exist, which
-would give the consumer a choice when deciding where to get source
-files.
+to build software. A combination of the two is also possible.
 
 BitBake uses the :term:`SRC_URI`
 variable to point to source files regardless of their location. Each
@@ -609,7 +607,7 @@ the specific revision from which to build.
 Source Mirror(s)
 ~~~~~~~~~~~~~~~~
 
-Two kinds of mirrors exist: pre-mirrors and regular mirrors. The
+There are two kinds of mirrors: pre-mirrors and regular mirrors. The
 :term:`PREMIRRORS` and
 :term:`MIRRORS` variables point to
 these, respectively. BitBake checks pre-mirrors before looking upstream
@@ -667,8 +665,8 @@ package files are kept:
    variables are used, respectively.
 
 -  :term:`PACKAGE_ARCH`: Defines
-   architecture-specific sub-folders. For example, packages could exist
-   for the i586 or qemux86 architectures.
+   architecture-specific sub-folders. For example, packages could be
+   available for the i586 or qemux86 architectures.
 
 BitBake uses the
 :ref:`do_package_write_* <ref-tasks-package_write_deb>`
@@ -681,8 +679,8 @@ and
 ":ref:`ref-tasks-package_write_tar`"
 sections in the Yocto Project Reference Manual for additional
 information. As an example, consider a scenario where an IPK packaging
-manager is being used and package architecture support for both i586 and
-qemux86 exist. Packages for the i586 architecture are placed in
+manager is being used and there is package architecture support for both
+i586 and qemux86. Packages for the i586 architecture are placed in
 ``build/tmp/deploy/ipk/i586``, while packages for the qemux86
 architecture are placed in ``build/tmp/deploy/ipk/qemux86``.
 
@@ -698,7 +696,7 @@ closer look at each of those areas.
 
 .. note::
 
-   Separate documentation exists for the BitBake tool. See the
+   Documentation for the BitBake tool is available separately. See the
    BitBake User Manual
    for reference material on BitBake.
 
@@ -783,12 +781,10 @@ Build Directory's hierarchy:
 
 .. note::
 
-   In the previous figure, notice that two sample hierarchies exist: one
-   based on package architecture (i.e.
-   PACKAGE_ARCH
-   ) and one based on a machine (i.e.
-   MACHINE
-   ). The underlying structures are identical. The differentiator being
+   In the previous figure, notice that there are two sample hierarchies:
+   one based on package architecture (i.e. :term:`PACKAGE_ARCH`)
+   and one based on a machine (i.e. :term:`MACHINE`).
+   The underlying structures are identical. The differentiator being
    what the OpenEmbedded build system is using as a build target (e.g.
    general architecture, a build host, an SDK, or a specific machine).
 
@@ -963,8 +959,7 @@ that part of the build process.
 
 .. note::
 
-   Support for creating feeds directly from the
-   deploy/\*
+   Support for creating feeds directly from the ``deploy/*``
    directories does not exist. Creating such feeds usually requires some
    kind of feed maintenance mechanism that would upload the new packages
    into an official package feed (e.g. the Ångström distribution). This
@@ -1156,9 +1151,9 @@ checksum <overview-manual/concepts:checksums (signatures)>`.
    OpenEmbedded.
 
 To determine if a task needs to be rerun, BitBake checks if a stamp file
-with a matching input checksum exists for the task. If such a stamp file
-exists, the task's output is assumed to exist and still be valid. If the
-file does not exist, the task is rerun.
+with a matching input checksum exists for the task. In this case,
+the task's output is assumed to exist and still be valid. Otherwise,
+the task is rerun.
 
 .. note::
 
@@ -1234,14 +1229,14 @@ to run any of the ``do_fetch``, ``do_unpack``, ``do_patch``,
 
 It becomes more complicated if everything can come from an sstate cache
 because some objects are simply not required at all. For example, you do
-not need a compiler or native tools, such as quilt, if nothing exists to
-compile or patch. If the ``do_package_write_*`` packages are available
+not need a compiler or native tools, such as quilt, if there isn't anything
+to compile or patch. If the ``do_package_write_*`` packages are available
 from sstate, BitBake does not need the ``do_package`` task data.
 
 To handle all these complexities, BitBake runs in two phases. The first
 is the "setscene" stage. During this stage, BitBake first checks the
 sstate cache for any targets it is planning to build. BitBake does a
-fast check to see if the object exists rather than a complete download.
+fast check to see if the object exists rather than doing a complete download.
 If nothing exists, the second phase, which is the setscene stage,
 completes and the main build proceeds.
 
@@ -1366,9 +1361,9 @@ can initialize the environment before using the tools.
 
 All the output files for an SDK are written to the ``deploy/sdk`` folder
 inside the :term:`Build Directory` as
-shown in the previous figure. Depending on the type of SDK, several
-variables exist that help configure these files. The following list
-shows the variables associated with an extensible SDK:
+shown in the previous figure. Depending on the type of SDK, there are
+several variables to configure these files. Here are the variables
+associated with an extensible SDK:
 
 -  :term:`DEPLOY_DIR`: Points to
    the ``deploy`` directory.
@@ -1577,8 +1572,8 @@ Shared State Cache
 By design, the OpenEmbedded build system builds everything from scratch
 unless :term:`BitBake` can determine
 that parts do not need to be rebuilt. Fundamentally, building from
-scratch is attractive as it means all parts are built fresh and no
-possibility of stale data exists that can cause problems. When
+scratch is attractive as it means all parts are built fresh and there is
+no possibility of stale data that can cause problems. When
 developers hit problems, they typically default back to building from
 scratch so they have a know state from the start.
 
@@ -1617,7 +1612,7 @@ them if they are deemed to be valid.
 
    -  The build system does not maintain
       :term:`PR` information as part of
-      the shared state packages. Consequently, considerations exist that
+      the shared state packages. Consequently, there are considerations that
       affect maintaining shared state feeds. For information on how the
       build system works with packages and can track incrementing ``PR``
       information, see the ":ref:`dev-manual/common-tasks:automatically incrementing a package version number`"
@@ -1687,7 +1682,7 @@ used to prune the "run" scripts down to the minimum set, thereby
 alleviating this problem and making the "run" scripts much more readable
 as a bonus.
 
-So far, solutions for shell scripts exist. What about Python tasks? The
+So far, there are solutions for shell scripts. What about Python tasks? The
 same approach applies even though these tasks are more difficult. The
 process needs to figure out what variables a Python function accesses
 and what functions it calls. Again, the incremental build solution
@@ -1695,7 +1690,7 @@ contains code that first figures out the variable and function
 dependencies, and then creates a checksum for the data used as the input
 to the task.
 
-Like the ``WORKDIR`` case, situations exist where dependencies should be
+Like the ``WORKDIR`` case, there can be situations where dependencies should be
 ignored. For these situations, you can instruct the build process to
 ignore a dependency by using a line like the following::
 
@@ -1732,7 +1727,7 @@ to add is a policy decision. However, the effect is to generate a master
 checksum that combines the basehash and the hashes of the task's
 dependencies.
 
-At the code level, a variety of ways exist by which both the basehash
+At the code level, there are multiple ways by which both the basehash
 and the dependent task hashes can be influenced. Within the BitBake
 configuration file, you can give BitBake some extra information to help
 it construct the basehash. The following statement effectively results
@@ -1961,8 +1956,8 @@ Automatically Added Runtime Dependencies
 The OpenEmbedded build system automatically adds common types of runtime
 dependencies between packages, which means that you do not need to
 explicitly declare the packages using
-:term:`RDEPENDS`. Three automatic
-mechanisms exist (``shlibdeps``, ``pcdeps``, and ``depchains``) that
+:term:`RDEPENDS`. There are three automatic
+mechanisms (``shlibdeps``, ``pcdeps``, and ``depchains``) that
 handle shared libraries, package configuration (pkg-config) modules, and
 ``-dev`` and ``-dbg`` packages, respectively. For other types of runtime
 dependencies, you must manually declare the dependencies.

documentation/overview-manual/development-environment.rst

@@ -71,7 +71,7 @@ section in
 the Yocto Project Development Tasks Manual.
 
 If your development host is going to be a system that runs a Linux
-distribution, steps still exist that you must take to prepare the system
+distribution, you must still take steps to prepare the system
 for use with the Yocto Project. You need to be sure that the Linux
 distribution on the system is one that supports the Yocto Project. You
 also need to be sure that the correct set of host packages are installed
@@ -80,8 +80,8 @@ set up a development host that runs Linux, see the
 ":ref:`dev-manual/start:setting up a native linux host`"
 section in the Yocto Project Development Tasks Manual.
 
-Once your development host is set up to use the Yocto Project, several
-methods exist for you to do work in the Yocto Project environment:
+Once your development host is set up to use the Yocto Project, there
+are several ways of working in the Yocto Project environment:
 
 -  *Command Lines, BitBake, and Shells:* Traditional development in the
    Yocto Project involves using the :term:`OpenEmbedded Build System`,
@@ -271,7 +271,7 @@ files that are being worked on simultaneously by more than one person.
 All this work is done locally on the development host before anything is
 pushed to a "contrib" area and examined at the maintainer's level.
 
-A somewhat formal method exists by which developers commit changes and
+There is a somewhat formal method by which developers commit changes and
 push them into the "contrib" area and subsequently request that the
 maintainer include them into an upstream branch. This process is called
 "submitting a patch" or "submitting a change." For information on
@@ -279,9 +279,9 @@ submitting patches and changes, see the
 ":ref:`dev-manual/common-tasks:submitting a change to the yocto project`"
 section in the Yocto Project Development Tasks Manual.
 
-In summary, a single point of entry exists for changes into a "master"
+In summary, there is a single point of entry for changes into a "master"
 or development branch of the Git repository, which is controlled by the
-project's maintainer. And, a set of developers exist who independently
+project's maintainer. A set of developers independently
 develop, test, and submit changes to "contrib" areas for the maintainer
 to examine. The maintainer then chooses which changes are going to
 become a permanent part of the project.

documentation/overview-manual/yp-intro.rst

@@ -140,8 +140,7 @@ Here are challenges you might encounter when developing using the Yocto Project:
 
 -  *Steep Learning Curve:* The Yocto Project has a steep learning curve
    and has many different ways to accomplish similar tasks. It can be
-   difficult to choose how to proceed when varying methods exist by
-   which to accomplish a given task.
+   difficult to choose between such ways.
 
 -  *Understanding What Changes You Need to Make For Your Design Requires
    Some Research:* Beyond the simple tutorial stage, understanding what
@@ -156,7 +155,7 @@ Here are challenges you might encounter when developing using the Yocto Project:
    workflow <overview-manual/development-environment:the yocto project development environment>`
    could be confusing if you are used to traditional desktop and server
    software development.
-   In a desktop development environment, mechanisms exist to easily pull
+   In a desktop development environment, there are mechanisms to easily pull
    and install new packages, which are typically pre-compiled binaries
    from servers accessible over the Internet. Using the Yocto Project,
    you must modify your configuration and rebuild to add additional
@@ -430,8 +429,8 @@ Yocto Project:
    require system administrator privileges. For example, file ownership
    or permissions might need to be defined. Pseudo is a tool that you
    can either use directly or through the environment variable
-   ``LD_PRELOAD``. Either method allows these operations to succeed as
-   if system administrator privileges exist even when they do not.
+   ``LD_PRELOAD``. Either method allows these operations to succeed
+   even without system administrator privileges.
 
    Thanks to Pseudo, the Yocto Project never needs root privileges to
    build images for your target system.
@@ -579,8 +578,7 @@ software.
 This section provides an introduction to the choices or development
 methods you have when setting up your Build Host. Depending on your
 particular workflow preference and the type of operating system your
-Build Host runs, several choices exist that allow you to use the Yocto
-Project.
+Build Host runs, you have several choices.
 
 .. note::
 
@@ -790,7 +788,7 @@ Some Basic Terms
 ================
 
 It helps to understand some basic fundamental terms when learning the
-Yocto Project. Although a list of terms exists in the ":doc:`Yocto Project
+Yocto Project. Although there is a list of terms in the ":doc:`Yocto Project
 Terms </ref-manual/terms>`" section of the Yocto Project
 Reference Manual, this section provides the definitions of some terms
 helpful for getting started:

documentation/poky.yaml

@@ -1,12 +1,12 @@
-DISTRO : "3.3"
+DISTRO : "3.3.1"
 DISTRO_NAME_NO_CAP : "hardknott"
 DISTRO_NAME : "Hardknott"
 DISTRO_NAME_NO_CAP_MINUS_ONE : "gatesgarth"
 DISTRO_NAME_NO_CAP_LTS : "dunfell"
-YOCTO_DOC_VERSION : "3.3"
+YOCTO_DOC_VERSION : "3.3.1"
 YOCTO_DOC_VERSION_MINUS_ONE : "3.2.4"
-DISTRO_REL_TAG : "yocto-3.3"
-POKYVERSION : "25.0.0"
+DISTRO_REL_TAG : "yocto-3.3.1"
+POKYVERSION : "25.0.1"
 YOCTO_POKY : "poky-&DISTRO_NAME_NO_CAP;-&POKYVERSION;"
 YOCTO_DL_URL : "https://downloads.yoctoproject.org"
 YOCTO_AB_URL : "https://autobuilder.yoctoproject.org"
@@ -19,7 +19,8 @@ FEDORA_HOST_PACKAGES_ESSENTIAL : "gawk make wget tar bzip2 gzip python3 unzip pe
      diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath \
      ccache perl-Data-Dumper perl-Text-ParseWords perl-Thread-Queue perl-bignum socat \
      python3-pexpect findutils which file cpio python python3-pip xz python3-GitPython \
-     python3-jinja2 SDL-devel xterm rpcgen mesa-libGL-devel"
+     python3-jinja2 SDL-devel xterm rpcgen mesa-libGL-devel perl-FindBin perl-File-Compare \
+     perl-File-Copy perl-locale"
 OPENSUSE_HOST_PACKAGES_ESSENTIAL : "python gcc gcc-c++ git chrpath make wget python-xml \
      diffstat makeinfo python-curses patch socat python3 python3-curses tar python3-pip \
      python3-pexpect xz which python3-Jinja2 Mesa-libEGL1 libSDL-devel xterm rpcgen Mesa-dri-devel

documentation/ref-manual/classes.rst

@@ -289,21 +289,6 @@ is used during the build process for ``nativesdk``, ``cross``, and
 ``cross-canadian`` recipes to change ``RPATH`` records within binaries
 in order to make them relocatable.
 
-.. _ref-classes-clutter:
-
-``clutter.bbclass``
-===================
-
-The ``clutter`` class consolidates the major and minor version naming
-and other common items used by Clutter and related recipes.
-
-.. note::
-
-   Unlike some other classes related to specific libraries, recipes
-   building other software that uses Clutter do not need to inherit this
-   class unless they use the same recipe versioning scheme that the
-   Clutter and related recipes do.
-
 .. _ref-classes-cmake:
 
 ``cmake.bbclass``
@@ -1006,7 +991,7 @@ package name override, in this example ``${PN}``, must be used::
    INSANE_SKIP_${PN} += "dev-so"
 
 Please keep in mind that the QA checks
-exist in order to detect real or potential problems in the packaged
+are meant to detect real or potential problems in the packaged
 output. So exercise caution when disabling these checks.
 
 Here are the tests you can list with the ``WARN_QA`` and
@@ -1085,8 +1070,8 @@ Here are the tests you can list with the ``WARN_QA`` and
 -  ``dev-so:`` Checks that the ``.so`` symbolic links are in the
    ``-dev`` package and not in any of the other packages. In general,
    these symlinks are only useful for development purposes. Thus, the
-   ``-dev`` package is the correct location for them. Some very rare
-   cases do exist for dynamically loaded modules where these symlinks
+   ``-dev`` package is the correct location for them. In very rare
+   cases, such as dynamically loaded modules, these symlinks
    are needed instead in the main package.
 
 -  ``file-rdeps:`` Checks that file-level dependencies identified by
@@ -1676,7 +1661,7 @@ couple different ways:
            nativesdk-myrecipe.bb
 
 
-   Not doing so can lead to subtle problems because code exists that
+   Not doing so can lead to subtle problems because there is code that
    depends on the naming convention.
 
 Although applied differently, the ``nativesdk`` class is used with both
@@ -1714,10 +1699,10 @@ section in the Yocto Project Development Tasks Manual.
 ``oelint.bbclass``
 ==================
 
-The ``oelint`` class is an obsolete lint checking tool that exists in
+The ``oelint`` class is an obsolete lint checking tool available in
 ``meta/classes`` in the :term:`Source Directory`.
 
-A number of classes exist that could be generally useful in OE-Core but
+There are some classes that could be generally useful in OE-Core but
 are never actually used within OE-Core itself. The ``oelint`` class is
 one such example. However, being aware of this class can reduce the
 proliferation of different versions of similar classes across multiple

documentation/ref-manual/devtool-reference.rst

@@ -403,8 +403,8 @@ Upgrading a Recipe
 
 As software matures, upstream recipes are upgraded to newer versions. As
 a developer, you need to keep your local recipes up-to-date with the
-upstream version releases. Several methods exist by which you can
-upgrade recipes. You can read about them in the ":ref:`dev-manual/common-tasks:upgrading recipes`"
+upstream version releases. There are several ways of upgrading recipes.
+You can read about them in the ":ref:`dev-manual/common-tasks:upgrading recipes`"
 section of the Yocto Project Development Tasks Manual. This section
 overviews the ``devtool upgrade`` command.
 
@@ -516,8 +516,8 @@ you do, the package manager is bypassed.
    should never use it to update an image that will be used in
    production.
 
-Some conditions exist that could prevent a deployed application from
-behaving as expected. When both of the following conditions exist, your
+Some conditions could prevent a deployed application from
+behaving as expected. When both of the following conditions are met, your
 application has the potential to not behave correctly when run on the
 target:
 
@@ -528,7 +528,7 @@ target:
 -  The target does not physically have the packages on which the
    application depends installed.
 
-If both of these conditions exist, your application will not behave as
+If both of these conditions are met, your application will not behave as
 expected. The reason for this misbehavior is because the
 ``devtool deploy-target`` command does not deploy the packages (e.g.
 libraries) on which your new application depends. The assumption is that

documentation/ref-manual/faq.rst

@@ -312,7 +312,7 @@ HTTPS requests and direct them to the ``http://`` sources mirror. You
 can use ``file://`` URLs to point to local directories or network shares
 as well.
 
-Aside from the previous technique, these options also exist::
+Here are other options::
 
    BB_NO_NETWORK = "1"
 

documentation/ref-manual/images.rst

@@ -46,10 +46,6 @@ Following is a list of supported recipes:
 -  ``core-image-base``: A console-only image that fully supports the
    target device hardware.
 
--  ``core-image-clutter``: An image with support for the Open GL-based
-   toolkit Clutter, which enables development of rich and animated
-   graphical user interfaces.
-
 -  ``core-image-full-cmdline``: A console-only image with more
    full-featured Linux system functionality installed.
 

documentation/ref-manual/kickstart.rst

@@ -106,13 +106,15 @@ the ``part`` and ``partition`` commands:
 -  ``--fstype``: Sets the file system type for the partition. Valid
    values are:
 
-   -  ``ext4``
+   -  ``btrfs``
 
-   -  ``ext3``
+   -  ``erofs``
 
    -  ``ext2``
 
-   -  ``btrfs``
+   -  ``ext3``
+
+   -  ``ext4``
 
    -  ``squashfs``
 
@@ -210,5 +212,5 @@ supports the following options:
 
 -  ``--configfile``: Specifies a user-defined configuration file for
    the bootloader. You can provide a full pathname for the file or a
-   file that exists in the ``canned-wks`` folder. This option overrides
+   file located in the ``canned-wks`` folder. This option overrides
    all other bootloader options.

documentation/ref-manual/migration-3.0.rst

@@ -184,10 +184,9 @@ The following BitBake changes have occurred.
    exceptions. Remove this argument in any calls to
    ``bb.build.exec_func()`` in custom classes or scripts.
 
--  The
-   :term:`bitbake:BB_SETSCENE_VERIFY_FUNCTION2`
-   is no longer used. In the unlikely event that you have any references
-   to it, they should be removed.
+-  The ``BB_SETSCENE_VERIFY_FUNCTION2`` variable is no longer used. In
+   the unlikely event that you have any references to it, they should be
+   removed.
 
 -  The ``RunQueueExecuteScenequeue`` and ``RunQueueExecuteTasks`` events
    have been removed since setscene tasks are now executed as part of

documentation/ref-manual/qa-checks.rst

@@ -97,7 +97,7 @@ Errors and Warnings
 
 -  ``<packagename1> rdepends on <packagename2>, but it isn't a build dependency? [build-deps]``
 
-   A runtime dependency exists between the two specified packages, but
+   There is a runtime dependency between the two specified packages, but
    there is nothing explicit within the recipe to enable the
    OpenEmbedded build system to ensure that dependency is satisfied.
    This condition is usually triggered by an
@@ -303,7 +303,7 @@ Errors and Warnings
 
 -  ``<packagename> rdepends on <debug_packagename> [debug-deps]``
 
-   A dependency exists between the specified non-dbg package (i.e. a
+   There is a dependency between the specified non-dbg package (i.e. a
    package whose name does not end in ``-dbg``) and a package that is a
    ``dbg`` package. The ``dbg`` packages contain debug symbols and are
    brought in using several different methods:
@@ -326,7 +326,7 @@ Errors and Warnings
 
 -  ``<packagename> rdepends on <dev_packagename> [dev-deps]``
 
-   A dependency exists between the specified non-dev package (a package
+   There is a dependency between the specified non-dev package (a package
    whose name does not end in ``-dev``) and a package that is a ``dev``
    package. The ``dev`` packages contain development headers and are
    usually brought in using several different methods:
@@ -753,6 +753,6 @@ how to work with the QA checks, see the
 
 .. note::
 
-   Please keep in mind that the QA checks exist in order to detect real
+   Please keep in mind that the QA checks are meant to detect real
    or potential problems in the packaged output. So exercise caution
    when disabling these checks.

documentation/ref-manual/release-process.rst

@@ -82,14 +82,14 @@ stable release.
    bug fixes and security fixes only. Policy dictates that features are
    not backported to a stable release. This policy means generic recipe
    version upgrades are unlikely to be accepted for backporting. The
-   exception to this policy occurs when a strong reason exists such as
+   exception to this policy occurs when there is a strong reason such as
    the fix happens to also be the preferred upstream approach.
 
 Stable release branches have strong maintenance for about a year after
 their initial release. Should significant issues be found for any
 release regardless of its age, fixes could be backported to older
 releases. For issues that are not backported given an older release,
-Community LTS trees and branches exist where community members share
+Community LTS trees and branches allow community members to share
 patches for older releases. However, these types of patches do not go
 through the same release process as do point releases. You can find more
 information about stable branch maintenance at

documentation/ref-manual/resources.rst

@@ -10,7 +10,7 @@ Introduction
 ============
 
 The Yocto Project team is happy for people to experiment with the Yocto
-Project. A number of places exist to find help if you run into
+Project. There is a number of places where you can find help if you run into
 difficulties or find bugs. This presents information about contributing
 and participating in the Yocto Project.
 
@@ -43,8 +43,7 @@ the Yocto Project itself (e.g. when discovering an issue with some
 component of the build system that acts contrary to the documentation or
 your expectations).
 
-A general procedure and guidelines exist for when you use Bugzilla to
-submit a bug. For information on how to use Bugzilla to submit a bug
+For a general procedure and guidelines on how to use Bugzilla to submit a bug
 against the Yocto Project, see the following:
 
 -  The ":ref:`dev-manual/common-tasks:submitting a defect against the yocto project`"
@@ -59,7 +58,7 @@ For information on Bugzilla in general, see https://www.bugzilla.org/about/.
 Mailing lists
 =============
 
-A number of mailing lists maintained by the Yocto Project exist as well
+There are multiple mailing lists maintained by the Yocto Project as well
 as related OpenEmbedded mailing lists for discussion, patch submission
 and announcements. To subscribe to one of the following mailing lists,
 click on the appropriate URL in the following list and follow the
@@ -156,9 +155,8 @@ Here is a list of resources you might find helpful:
 
 -  :yocto_docs:`Yocto Project Mega-Manual </singleindex.html>`\ *:* This manual
    is simply a single HTML file comprised of the bulk of the Yocto
-   Project manuals. The Mega-Manual primarily exists as a vehicle by
-   which you can easily search for phrases and terms used in the Yocto
-   Project documentation set.
+   Project manuals. It makes it easy to search for phrases and terms used
+   in the Yocto Project documentation set.
 
 -  :doc:`/profile-manual/index` *:* This manual presents a set of
    common and generally useful tracing and profiling schemes along with

documentation/ref-manual/structure.rst

@@ -510,8 +510,8 @@ should be automatic, and recipes should not directly reference
 -----------------------
 
 Previous versions of the OpenEmbedded build system used to create a
-global shared sysroot per machine along with a native sysroot. Beginning
-with the 2.3 version of the Yocto Project, sysroots exist in
+global shared sysroot per machine along with a native sysroot. Since
+the 2.3 version of the Yocto Project, there are sysroots in
 recipe-specific :term:`WORKDIR` directories. Thus, the
 ``build/tmp/sysroots/`` directory is unused.
 
@@ -601,7 +601,7 @@ constructed using the architecture of the given build (e.g.
 name, and the version of the recipe (i.e.
 :term:`PE`\ ``:``\ :term:`PV`\ ``-``\ :term:`PR`).
 
-A number of key subdirectories exist within each recipe work directory:
+Here are key subdirectories within each recipe work directory:
 
 -  ``${WORKDIR}/temp``: Contains the log files of each task executed for
    this recipe, the "run" files for each executed task, which contain
@@ -624,7 +624,7 @@ A number of key subdirectories exist within each recipe work directory:
 
 -  ``${WORKDIR}/packages-split``: Contains the output of the
    ``do_package`` task after the output has been split into individual
-   packages. Subdirectories exist for each individual package created by
+   packages. There are subdirectories for each individual package created by
    the recipe.
 
 -  ``${WORKDIR}/recipe-sysroot``: A directory populated with the target

documentation/ref-manual/system-requirements.rst

@@ -41,7 +41,7 @@ distributions:
 
 -  Ubuntu 18.04 (LTS)
 
--  Ubuntu 20.04
+-  Ubuntu 20.04 (LTS)
 
 -  Fedora 30
 
@@ -66,9 +66,8 @@ distributions:
 
    -  While the Yocto Project Team attempts to ensure all Yocto Project
       releases are one hundred percent compatible with each officially
-      supported Linux distribution, instances might exist where you
-      encounter a problem while using the Yocto Project on a specific
-      distribution.
+      supported Linux distribution, you may still encounter problems
+      that happen only with a specific distribution.
 
    -  Yocto Project releases are tested against the stable Linux
       distributions in the above list. The Yocto Project should work
@@ -119,8 +118,7 @@ supported Ubuntu or Debian Linux distribution:
    -  If your build system has the ``oss4-dev`` package installed, you
       might experience QEMU build failures due to the package installing
       its own custom ``/usr/include/linux/soundcard.h`` on the Debian
-      system. If you run into this situation, either of the following
-      solutions exist::
+      system. If you run into this situation, try either of these solutions::
 
          $ sudo apt-get build-dep qemu
          $ sudo apt-get remove oss4-dev

documentation/ref-manual/tasks.rst

@@ -823,6 +823,5 @@ sections from a size-sensitive configuration.
 After the kernel is unpacked but before it is patched, this task makes
 sure that the machine and metadata branches as specified by the
 :term:`SRCREV` variables actually exist on the specified
-branches. If these branches do not exist and
-:term:`AUTOREV` is not being used, the
+branches. Otherwise, if :term:`AUTOREV` is not being used, the
 ``do_validate_branches`` task fails during the build.

documentation/ref-manual/variables.rst

@@ -49,10 +49,9 @@ system and gives an overview of their function and contents.
       alternatives system to create a different binary naming scheme so the
       commands can co-exist.
 
-      To use the variable, list out the package's commands that also exist
-      as part of another package. For example, if the ``busybox`` package
-      has four commands that also exist as part of another package, you
-      identify them as follows::
+      To use the variable, list out the package's commands that are also
+      provided by another package. For example, if the ``busybox`` package
+      has four such commands, you identify them as follows::
 
          ALTERNATIVE_busybox = "sh sed test bracket"
 
@@ -306,8 +305,8 @@ system and gives an overview of their function and contents.
       variable), the OpenEmbedded build system ignores your request and
       will install the packages to avoid dependency errors.
 
-      Support for this variable exists only when using the IPK and RPM
-      packaging backend. Support does not exist for DEB.
+      This variable is supported only when using the IPK and RPM
+      packaging backends. DEB is not supported.
 
       See the :term:`NO_RECOMMENDATIONS` and the
       :term:`PACKAGE_EXCLUDE` variables for related
@@ -336,8 +335,8 @@ system and gives an overview of their function and contents.
       -  This host list is only used if ``BB_NO_NETWORK`` is either not set
          or set to "0".
 
-      -  Limited support for wildcard matching against the beginning of
-         host names exists. For example, the following setting matches
+      -  There is limited support for wildcard matching against the beginning of
+         host names. For example, the following setting matches
          ``git.gnu.org``, ``ftp.gnu.org``, and ``foo.git.gnu.org``.
          ::
 
@@ -558,7 +557,7 @@ system and gives an overview of their function and contents.
 
    :term:`BBCLASSEXTEND`
       Allows you to extend a recipe so that it builds variants of the
-      software. Common variants for recipes exist such as "natives" like
+      software. There are common variants for recipes as "natives" like
       ``quilt-native``, which is a copy of Quilt built to run on the build
       system; "crosses" such as ``gcc-cross``, which is a compiler built to
       run on the build machine but produces binaries that run on the target
@@ -1237,7 +1236,7 @@ system and gives an overview of their function and contents.
          CONFFILES_${PN} += "${sysconfdir}/file1 \
              ${sysconfdir}/file2 ${sysconfdir}/file3"
 
-      A relationship exists between the ``CONFFILES`` and ``FILES``
+      There is a relationship between the ``CONFFILES`` and ``FILES``
       variables. The files listed within ``CONFFILES`` must be a subset of
       the files listed within ``FILES``. Because the configuration files
       you provide with ``CONFFILES`` are simply being identified so that
@@ -1417,8 +1416,8 @@ system and gives an overview of their function and contents.
    :term:`COREBASE_FILES`
       Lists files from the :term:`COREBASE` directory that
       should be copied other than the layers listed in the
-      ``bblayers.conf`` file. The ``COREBASE_FILES`` variable exists for
-      the purpose of copying metadata from the OpenEmbedded build system
+      ``bblayers.conf`` file. The ``COREBASE_FILES`` variable allows
+      to copy metadata from the OpenEmbedded build system
       into the extensible SDK.
 
       Explicitly listing files in ``COREBASE`` is needed because it
@@ -1525,10 +1524,10 @@ system and gives an overview of their function and contents.
 
    :term:`DEBUG_BUILD`
       Specifies to build packages with debugging information. This
-      influences the value of the ``SELECTED_OPTIMIZATION`` variable.
+      influences the value of the :term:`SELECTED_OPTIMIZATION` variable.
 
    :term:`DEBUG_OPTIMIZATION`
-      The options to pass in ``TARGET_CFLAGS`` and ``CFLAGS`` when
+      The options to pass in :term:`TARGET_CFLAGS` and :term:`CFLAGS` when
       compiling a system for debugging. This variable defaults to "-O
       -fno-omit-frame-pointer ${DEBUG_FLAGS} -pipe".
 
@@ -1538,7 +1537,7 @@ system and gives an overview of their function and contents.
       The most common usage of this is variable is to set it to "-1" within
       a recipe for a development version of a piece of software. Using the
       variable in this way causes the stable version of the recipe to build
-      by default in the absence of ``PREFERRED_VERSION`` being used to
+      by default in the absence of :term:`PREFERRED_VERSION` being used to
       build the development version.
 
       .. note::
@@ -2460,8 +2459,8 @@ system and gives an overview of their function and contents.
             ``FILESEXTRAPATHS`` variable.
 
       You can take advantage of this searching behavior in useful ways. For
-      example, consider a case where the following directory structure
-      exists for general and machine-specific configurations::
+      example, consider a case where there is the following directory structure
+      for general and machine-specific configurations::
 
          files/defconfig
          files/MACHINEA/defconfig
@@ -2579,7 +2578,7 @@ system and gives an overview of their function and contents.
       Set the variable to "1" to force the removal of these packages.
 
    :term:`FULL_OPTIMIZATION`
-      The options to pass in ``TARGET_CFLAGS`` and ``CFLAGS`` when
+      The options to pass in :term:`TARGET_CFLAGS` and :term:`CFLAGS` when
       compiling an optimized system. This variable defaults to "-O2 -pipe
       ${DEBUG_FLAGS}".
 
@@ -3013,8 +3012,8 @@ system and gives an overview of their function and contents.
 
       Image recipes set ``IMAGE_INSTALL`` to specify the packages to
       install into an image through ``image.bbclass``. Additionally,
-      "helper" classes such as the
-      :ref:`core-image <ref-classes-core-image>` class exist that can
+      there are "helper" classes such as the
+      :ref:`core-image <ref-classes-core-image>` class which can
       take lists used with ``IMAGE_FEATURES`` and turn them into
       auto-generated entries in ``IMAGE_INSTALL`` in addition to its
       default contents.
@@ -3280,6 +3279,9 @@ system and gives an overview of their function and contents.
       - cpio.lzma
       - cpio.xz
       - cramfs
+      - erofs
+      - erofs-lz4
+      - erofs-lz4hc
       - ext2
       - ext2.bz2
       - ext2.gz
@@ -3465,8 +3467,8 @@ system and gives an overview of their function and contents.
          Use of the ``INHIBIT_SYSROOT_STRIP`` variable occurs in rare and
          special circumstances. For example, suppose you are building
          bare-metal firmware by using an external GCC toolchain. Furthermore,
-         even if the toolchain's binaries are strippable, other files exist
-         that are needed for the build that are not strippable.
+         even if the toolchain's binaries are strippable, there are other files
+         needed for the build that are not strippable.
 
    :term:`INITRAMFS_FSTYPES`
       Defines the format for the output image of an initial RAM filesystem
@@ -3817,7 +3819,7 @@ system and gives an overview of their function and contents.
 
       .. note::
 
-         Legacy support exists for specifying the full path to the device
+         There is legacy support for specifying the full path to the device
          tree. However, providing just the ``.dtb`` file is preferred.
 
       In order to use this variable, the
@@ -4042,7 +4044,7 @@ system and gives an overview of their function and contents.
 
    :term:`KERNELDEPMODDEPEND`
       Specifies whether the data referenced through
-      :term:`PKGDATA_DIR` is needed or not. The
+      :term:`PKGDATA_DIR` is needed or not.
       ``KERNELDEPMODDEPEND`` does not control whether or not that data
       exists, but simply whether or not it is used. If you do not need to
       use the data, set the ``KERNELDEPMODDEPEND`` variable in your
@@ -4227,8 +4229,8 @@ system and gives an overview of their function and contents.
       -  Separate license names using \| (pipe) when there is a choice
          between licenses.
 
-      -  Separate license names using & (ampersand) when multiple licenses
-         exist that cover different parts of the source.
+      -  Separate license names using & (ampersand) when there are
+         multiple licenses for different parts of the source.
 
       -  You can use spaces between license names.
 
@@ -4376,8 +4378,8 @@ system and gives an overview of their function and contents.
 
       The variable corresponds to a machine configuration file of the same
       name, through which machine-specific configurations are set. Thus,
-      when ``MACHINE`` is set to "qemux86" there exists the corresponding
-      ``qemux86.conf`` machine configuration file, which can be found in
+      when ``MACHINE`` is set to "qemux86", the corresponding
+      ``qemux86.conf`` machine configuration file can be found in
       the :term:`Source Directory` in
       ``meta/conf/machine``.
 
@@ -4630,7 +4632,7 @@ system and gives an overview of their function and contents.
 
          do_foo[depends] += "${MLPREFIX}recipe:do_foo"
 
-   module_autoload
+   :term:`module_autoload`
       This variable has been replaced by the ``KERNEL_MODULE_AUTOLOAD``
       variable. You should replace all occurrences of ``module_autoload``
       with additions to ``KERNEL_MODULE_AUTOLOAD``, for example::
@@ -4643,7 +4645,7 @@ system and gives an overview of their function and contents.
 
       See the :term:`KERNEL_MODULE_AUTOLOAD` variable for more information.
 
-   module_conf
+   :term:`module_conf`
       Specifies `modprobe.d <https://linux.die.net/man/5/modprobe.d>`_
       syntax lines for inclusion in the ``/etc/modprobe.d/modname.conf``
       file.
@@ -4742,7 +4744,7 @@ system and gives an overview of their function and contents.
 
    :term:`NO_GENERIC_LICENSE`
       Avoids QA errors when you use a non-common, non-CLOSED license in a
-      recipe. Packages exist, such as the linux-firmware package, with many
+      recipe. There are packages, such as the linux-firmware package, with many
       licenses that are not in any way common. Also, new licenses are added
       occasionally to avoid introducing a lot of common license files,
       which are only applicable to a specific package.
@@ -4786,8 +4788,8 @@ system and gives an overview of their function and contents.
          functionality, such as kernel modules. It is up to you to add
          packages with the :term:`IMAGE_INSTALL` variable.
 
-      Support for this variable exists only when using the IPK and RPM
-      packaging backend. Support does not exist for DEB.
+      This variable is only supported when using the IPK and RPM
+      packaging backends. DEB is not supported.
 
       See the :term:`BAD_RECOMMENDATIONS` and
       the :term:`PACKAGE_EXCLUDE` variables for
@@ -4804,6 +4806,13 @@ system and gives an overview of their function and contents.
          FILES_${PN}-dbg = "/usr/src/debug/"
          FILES_${QT_BASE_NAME}-demos-doc = "${docdir}/${QT_DIR_NAME}/qch/qt.qch"
 
+   :term:`NON_MULTILIB_RECIPES`
+      A list of recipes that should not be built for multilib. OE-Core's
+      ``multilib.conf`` file defines a reasonable starting point for this
+      list with::
+
+         NON_MULTILIB_RECIPES = "grub grub-efi make-mod-scripts ovmf u-boot"
+
    :term:`OBJCOPY`
       The minimal command and arguments to run ``objcopy``.
 
@@ -5064,8 +5073,8 @@ system and gives an overview of their function and contents.
       an iterative development process to remove specific components from a
       system.
 
-      Support for this variable exists only when using the IPK and RPM
-      packaging backend. Support does not exist for DEB.
+      This variable is supported only when using the IPK and RPM
+      packaging backends. DEB is not supported.
 
       See the :term:`NO_RECOMMENDATIONS` and the
       :term:`BAD_RECOMMENDATIONS` variables for
@@ -6211,7 +6220,7 @@ system and gives an overview of their function and contents.
       :term:`PACKAGE_EXCLUDE` variables.
 
       Packages specified in ``RRECOMMENDS`` need not actually be produced.
-      However, a recipe must exist that provides each package, either
+      However, there must be a recipe providing each package, either
       through the :term:`PACKAGES` or
       :term:`PACKAGES_DYNAMIC` variables or the
       :term:`RPROVIDES` variable, or an error will occur
@@ -6691,8 +6700,8 @@ system and gives an overview of their function and contents.
       value of the :term:`TARGET_CFLAGS` variable.
 
       The ``SELECTED_OPTIMIZATION`` variable takes the value of
-      ``FULL_OPTIMIZATION`` unless ``DEBUG_BUILD`` = "1". If that is the
-      case, the value of ``DEBUG_OPTIMIZATION`` is used.
+      :term:`FULL_OPTIMIZATION` unless :term:`DEBUG_BUILD` = "1", in which
+      case the value of :term:`DEBUG_OPTIMIZATION` is used.
 
    :term:`SERIAL_CONSOLE`
       Defines a serial console (TTY) to enable using
@@ -6979,8 +6988,8 @@ system and gives an overview of their function and contents.
 
       -  ``az://`` - Fetches files from an Azure Storage account.
 
-      Standard and recipe-specific options for ``SRC_URI`` exist. Here are
-      standard options:
+      There are standard and recipe-specific options for ``SRC_URI``. Here are
+      standard ones:
 
       -  ``apply`` - Whether to apply the patch or not. The default
          action is to apply the patch.
@@ -7093,6 +7102,30 @@ system and gives an overview of their function and contents.
          ":ref:`dev-manual/common-tasks:automatically incrementing a package version number`"
          section, which is in the Yocto Project Development Tasks Manual.
 
+   :term:`SRCTREECOVEREDTASKS`
+      A list of tasks that are typically not relevant (and therefore skipped)
+      when building using the :ref:`externalsrc <ref-classes-externalsrc>`
+      class. The default value as set in that class file is the set of tasks
+      that are rarely needed when using external source::
+
+         SRCTREECOVEREDTASKS ?= "do_patch do_unpack do_fetch"
+
+      The notable exception is when processing external kernel source as
+      defined in the :ref:`kernel-yocto <ref-classes-kernel-yocto>`
+      class file (formatted for aesthetics)::
+
+         SRCTREECOVEREDTASKS += "\
+           do_validate_branches \
+           do_kernel_configcheck \
+           do_kernel_checkout \
+           do_fetch \
+           do_unpack \
+           do_patch \
+         "
+
+      See the associated :term:`EXTERNALSRC` and :term:`EXTERNALSRC_BUILD`
+      variables for more information.
+
    :term:`SSTATE_DIR`
       The directory for the shared state cache.
 
@@ -7667,8 +7700,8 @@ system and gives an overview of their function and contents.
    :term:`TARGET_OS`
       Specifies the target's operating system. The variable can be set to
       "linux" for glibc-based systems (GNU C Library) and to "linux-musl"
-      for musl libc. For ARM/EABI targets, "linux-gnueabi" and
-      "linux-musleabi" possible values exist.
+      for musl libc. For ARM/EABI targets, the possible values are
+      "linux-gnueabi" and "linux-musleabi".
 
    :term:`TARGET_PREFIX`
       Specifies the prefix used for the toolchain binary target tools.
@@ -8369,11 +8402,10 @@ system and gives an overview of their function and contents.
       configure options are simply not passed to the configure script (e.g.
       should be removed from :term:`EXTRA_OECONF` or
       :term:`PACKAGECONFIG_CONFARGS`).
-      However, common options, for example, exist that are passed to all
-      configure scripts at a class level that might not be valid for some
-      configure scripts. It follows that no benefit exists in seeing a
-      warning about these options. For these cases, the options are added
-      to ``UNKNOWN_CONFIGURE_WHITELIST``.
+      However, there are common options that are passed to all
+      configure scripts at a class level, but might not be valid for some
+      configure scripts. Therefore warnings about these options are useless.
+      For these cases, the options are added to ``UNKNOWN_CONFIGURE_WHITELIST``.
 
       The configure arguments check that uses
       ``UNKNOWN_CONFIGURE_WHITELIST`` is part of the

documentation/releases.rst

@@ -9,6 +9,7 @@
 *******************************
 
 - :yocto_docs:`3.3 Documentation </3.3>`
+- :yocto_docs:`3.3.1 Documentation </3.3.1>`
 
 *******************************
 3.2 'gatesgarth' Release Series
@@ -32,6 +33,7 @@
 - :yocto_docs:`3.1.5 Documentation </3.1.5>`
 - :yocto_docs:`3.1.6 Documentation </3.1.6>`
 - :yocto_docs:`3.1.7 Documentation </3.1.7>`
+- :yocto_docs:`3.1.8 Documentation </3.1.8>`
 
 ==========================
  Previous Release Manuals

documentation/sdk-manual/appendix-customizing.rst

@@ -57,8 +57,7 @@ Adjusting the Extensible SDK to Suit Your Build Host's Setup
 ============================================================
 
 In most cases, the extensible SDK defaults should work with your :term:`Build
-Host`'s setup.
-However, some cases exist for which you might consider making
+Host`'s setup. However, there are cases when you might consider making
 adjustments:
 
 -  If your SDK configuration inherits additional classes using the
@@ -153,7 +152,7 @@ follows::
 
    SDK_TITLE ??= "${@d.getVar('DISTRO_NAME') or d.getVar('DISTRO')} SDK"
 
-While several ways exist to change this variable, an efficient method is
+While there are several ways of changing this variable, an efficient method is
 to set the variable in your distribution's configuration file. Doing so
 creates an SDK installer title that applies across your distribution. As
 an example, assume you have your own layer for your distribution named
@@ -223,7 +222,7 @@ You can
 change this default installation directory by specifically setting the
 ``SDKEXTPATH`` variable.
 
-While a number of ways exist through which you can set this variable,
+While there are several ways of setting this variable,
 the method that makes the most sense is to set the variable in your
 distribution's configuration file. Doing so creates an SDK installer
 default directory that applies across your distribution. As an example,

documentation/sdk-manual/extensible.rst

@@ -194,7 +194,7 @@ all the commands.
    devtool
    quick reference.
 
-Three ``devtool`` subcommands exist that provide entry-points into
+Three ``devtool`` subcommands provide entry-points into
 development:
 
 -  *devtool add*: Assists in adding new software to be built.
@@ -276,7 +276,7 @@ command:
          devtool
          always creates a Git repository locally during the extraction.
 
-      Furthermore, the first positional argument srctree in this case
+      Furthermore, the first positional argument ``srctree`` in this case
       identifies where the ``devtool add`` command will locate the
       extracted code outside of the workspace. You need to specify an
       empty directory::
@@ -285,13 +285,13 @@ command:
 
       In summary,
       the source code is pulled from fetchuri and extracted into the
-      location defined by srctree as a local Git repository.
+      location defined by ``srctree`` as a local Git repository.
 
       Within workspace, ``devtool`` creates a recipe named recipe along
       with an associated append file.
 
    -  *Right*: The right scenario in the figure represents a situation
-      where the srctree has been previously prepared outside of the
+      where the ``srctree`` has been previously prepared outside of the
       ``devtool`` workspace.
 
       The following command provides a new recipe name and identifies
@@ -437,7 +437,7 @@ command:
       locate the source code and any local patch files from other
       developers.
 
-      With this scenario, no srctree argument exists. Consequently, the
+      With this scenario, there is no ``srctree`` argument. Consequently, the
       default behavior of the ``devtool modify`` command is to extract
       the source files pointed to by the ``SRC_URI`` statements into a
       local Git structure. Furthermore, the location for the extracted
@@ -483,21 +483,21 @@ command:
       under the newly created source tree.
 
       Once the files are located, the command by default extracts them
-      into srctree.
+      into ``srctree``.
 
       Within workspace, ``devtool`` creates an append file for the
       recipe. The recipe remains in its original location but the source
-      files are extracted to the location you provide with srctree.
+      files are extracted to the location you provide with ``srctree``.
 
    -  *Right*: The right scenario in the figure represents a situation
-      where the source tree (srctree) already exists locally as a
+      where the source tree (``srctree``) already exists locally as a
       previously extracted Git structure outside of the ``devtool``
       workspace. In this example, the recipe also exists elsewhere
       locally in its own layer.
 
       The following command tells ``devtool`` the recipe with which to
       work, uses the "-n" option to indicate source does not need to be
-      extracted, and uses srctree to point to the previously extracted
+      extracted, and uses ``srctree`` to point to the previously extracted
       source files::
 
          $ devtool modify -n recipe srctree
@@ -646,8 +646,9 @@ The following diagram shows the common development flow used with the
    code into the ``sources`` directory in the
    :ref:`devtool-the-workspace-layer-structure`.
    If you want the code extracted to any other location, you need to
-   provide the srctree positional argument with the command as follows:
-   $ devtool upgrade -V version recipe srctree
+   provide the ``srctree`` positional argument with the command as follows::
+
+      $ devtool upgrade -V version recipe srctree
 
    .. note::
 
@@ -674,8 +675,8 @@ The following diagram shows the common development flow used with the
    are incorporated into the build the next time you build the software
    just as are other changes you might have made to the source.
 
-2. *Resolve any Conflicts created by the Upgrade*: Conflicts could exist
-   due to the software being upgraded to a new version. Conflicts occur
+2. *Resolve any Conflicts created by the Upgrade*: Conflicts could happen
+   after upgrading the software to a new version. Conflicts occur
    if your recipe specifies some patch files in ``SRC_URI`` that
    conflict with changes made in the new version of the software. For
    such cases, you need to resolve the conflicts by editing the source
@@ -908,8 +909,8 @@ mind:
    similar manner to the environment set up by the SDK's environment
    setup script. One easy way to see these variables is to run the
    ``devtool build`` command on the recipe and then look in
-   ``oe-logs/run.do_compile``. Towards the top of this file, a list of
-   environment variables exists that are being set. You can take
+   ``oe-logs/run.do_compile``. Towards the top of this file, there is
+   a list of environment variables that are set. You can take
    advantage of these variables within the Makefile.
 
 -  If the Makefile sets a default for a variable using "=", that default
@@ -1037,8 +1038,8 @@ If you look at the contents of a recipe, you will see that the recipe
 does not include complete instructions for building the software.
 Instead, common functionality is encapsulated in classes inherited with
 the ``inherit`` directive. This technique leaves the recipe to describe
-just the things that are specific to the software being built. A
-:ref:`base <ref-classes-base>` class exists that
+just the things that are specific to the software being built. There is
+a :ref:`base <ref-classes-base>` class that
 is implicitly inherited by all recipes and provides the functionality
 that most recipes typically need.
 
@@ -1110,9 +1111,9 @@ Recipes often need to use files provided by other recipes on the
 :term:`Build Host`. For example,
 an application linking to a common library needs access to the library
 itself and its associated headers. The way this access is accomplished
-within the extensible SDK is through the sysroot. One sysroot exists per
+within the extensible SDK is through the sysroot. There is one sysroot per
 "machine" for which the SDK is being built. In practical terms, this
-means a sysroot exists for the target machine, and a sysroot exists for
+means there is a sysroot for the target machine, and a sysroot for
 the build host.
 
 Recipes should never write files directly into the sysroot. Instead,
@@ -1159,8 +1160,8 @@ example, ``FILES_${PN}`` specifies the files to go into the main package
 ``${``\ :term:`PN`\ ``}`` evaluates to the
 recipe name). The order of the ``PACKAGES`` value is significant. For
 each installed file, the first package whose ``FILES`` value matches the
-file is the package into which the file goes. Defaults exist for both
-the ``PACKAGES`` and ``FILES`` variables. Consequently, you might find
+file is the package into which the file goes. Both the ``PACKAGES`` and
+``FILES`` variables have default values. Consequently, you might find
 you do not even need to set these variables in your recipe unless the
 software the recipe is building installs files into non-standard
 locations.
@@ -1230,7 +1231,7 @@ source, you can add the "-s" option as follows::
 
 It is important to remember that building the item from source
 takes significantly longer than installing the pre-built artifact. Also,
-if no recipe exists for the item you want to add to the SDK, you must
+if there is no recipe for the item you want to add to the SDK, you must
 instead add the item using the ``devtool add`` command.
 
 Applying Updates to an Installed Extensible SDK

documentation/sdk-manual/intro.rst

@@ -214,5 +214,5 @@ You just need to follow these general steps:
    within the Yocto Project.
 
 The remainder of this manual describes how to use the extensible and
-standard SDKs. Information also exists in appendix form that describes
+standard SDKs. There is also information in appendix form describing
 how you can build, install, and modify an SDK.

documentation/sphinx-static/switchers.js

@@ -3,9 +3,9 @@
 
   var all_versions = {
     'dev': 'dev (3.4)',
-    '3.3': '3.3',
+    '3.3.1': '3.3.1',
     '3.2.4': '3.2.4',
-    '3.1.7': '3.1.7',
+    '3.1.8': '3.1.8',
     '3.0.4': '3.0.4',
     '2.7.4': '2.7.4',
   };

documentation/toaster-manual/reference.rst

@@ -9,8 +9,8 @@ concepts and have some basic command reference material available. This
 final chapter provides conceptual information on layer sources,
 releases, and JSON configuration files. Also provided is a quick look at
 some useful ``manage.py`` commands that are Toaster-specific.
-Information on ``manage.py`` commands does exist across the Web and the
-information in this manual by no means attempts to provide a command
+Information on ``manage.py`` commands is available across the Web and
+this manual by no means attempts to provide a command
 comprehensive reference.
 
 Layer Source
@@ -508,7 +508,7 @@ Useful Commands
 ===============
 
 In addition to the web user interface and the scripts that start and
-stop Toaster, command-line commands exist through the ``manage.py``
+stop Toaster, command-line commands are available through the ``manage.py``
 management script. You can find general documentation on ``manage.py``
 at the
 `Django <https://docs.djangoproject.com/en/2.2/topics/settings/>`__

meta-poky/conf/distro/include/poky-floating-revisions.inc

@@ -26,8 +26,6 @@ SRCREV_pn-sato-icon-theme ?= "${AUTOREV}"
 SRCREV_pn-matchbox-desktop-sato ?= "${AUTOREV}"
 SRCREV_pn-oh-puzzles ?= "${AUTOREV}"
 SRCREV_pn-libowl ?= "${AUTOREV}"
-SRCREV_pn-clutter ?= "${AUTOREV}"
-SRCREV_pn-clutter-gst ?= "${AUTOREV}"
 SRCREV_pn-libmatchbox ?= "${AUTOREV}"
 SRCREV_pn-ofono ?= "${AUTOREV}"
 

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

@@ -115,7 +115,6 @@ RDEPENDS_${PN}-mtrace_pn-eglibc = ""
 
 PNBLACKLIST[build-appliance-image] = "not buildable with poky-tiny"
 PNBLACKLIST[core-image-base] = "not buildable with poky-tiny"
-PNBLACKLIST[core-image-clutter] = "not buildable with poky-tiny"
 PNBLACKLIST[core-image-full-cmdline] = "not buildable with poky-tiny"
 PNBLACKLIST[core-image-rt] = "not buildable with poky-tiny"
 PNBLACKLIST[core-image-rt-sdk] = "not buildable with poky-tiny"

meta/classes/baremetal-image.bbclass

@@ -50,6 +50,10 @@ python do_rootfs(){
         if os.path.lexists(manifest_link):
             os.remove(manifest_link)
         os.symlink(os.path.basename(manifest_name), manifest_link)
+    # A lot of postprocess commands assume the existence of rootfs/etc
+    sysconfdir = d.getVar("IMAGE_ROOTFS") + d.getVar('sysconfdir')
+    bb.utils.mkdirhier(sysconfdir)
+
     execute_pre_post_process(d, d.getVar('ROOTFS_POSTPROCESS_COMMAND'))
 }
 

meta/classes/buildhistory.bbclass

@@ -43,6 +43,7 @@ BUILDHISTORY_COMMIT ?= "1"
 BUILDHISTORY_COMMIT_AUTHOR ?= "buildhistory <buildhistory@${DISTRO}>"
 BUILDHISTORY_PUSH_REPO ?= ""
 BUILDHISTORY_TAG ?= "build"
+BUILDHISTORY_PATH_PREFIX_STRIP ?= ""
 
 SSTATEPOSTINSTFUNCS_append = " buildhistory_emit_pkghistory"
 # We want to avoid influencing the signatures of sstate tasks - first the function itself:
@@ -697,7 +698,7 @@ python buildhistory_write_sigs() {
     if hasattr(bb.parse.siggen, 'dump_siglist'):
         taskoutdir = os.path.join(d.getVar('BUILDHISTORY_DIR'), 'task')
         bb.utils.mkdirhier(taskoutdir)
-        bb.parse.siggen.dump_siglist(os.path.join(taskoutdir, 'tasksigs.txt'))
+        bb.parse.siggen.dump_siglist(os.path.join(taskoutdir, 'tasksigs.txt'), d.getVar("BUILDHISTORY_PATH_PREFIX_STRIP"))
 }
 
 def buildhistory_get_build_id(d):

meta/classes/clutter.bbclass

@@ -1,18 +0,0 @@
-def get_minor_dir(v):
-    import re
-    m = re.match(r"^([0-9]+)\.([0-9]+)", v)
-    return "%s.%s" % (m.group(1), m.group(2))
-
-def get_real_name(n):
-    import re
-    m = re.match(r"^([a-z]+(-[a-z]+)?)(-[0-9]+\.[0-9]+)?", n)
-    return "%s" % (m.group(1))
-
-VERMINOR = "${@get_minor_dir("${PV}")}"
-REALNAME = "${@get_real_name("${BPN}")}"
-
-SRC_URI = "${GNOME_MIRROR}/${REALNAME}/${VERMINOR}/${REALNAME}-${PV}.tar.xz;name=archive"
-S = "${WORKDIR}/${REALNAME}-${PV}"
-
-CLUTTERBASEBUILDCLASS ??= "autotools"
-inherit ${CLUTTERBASEBUILDCLASS} pkgconfig gtk-doc gettext

meta/classes/gnomebase.bbclass

@@ -1,5 +1,6 @@
 def gnome_verdir(v):
-    return oe.utils.trim_version(v, 2)
+    return ".".join(v.split(".")[:-1])
+
 
 GNOME_COMPRESS_TYPE ?= "xz"
 SECTION ?= "x11/gnome"

meta/classes/icecc.bbclass

@@ -138,10 +138,6 @@ def use_icecc(bb,d):
     if icecc_is_cross_canadian(bb, d):
         return "no"
 
-    if d.getVar('INHIBIT_DEFAULT_DEPS', False):
-        # We don't have a compiler, so no icecc
-        return "no"
-
     pn = d.getVar('PN')
     bpn = d.getVar('BPN')
 
@@ -362,7 +358,7 @@ set_icecc_env() {
     ICECC_WHICH_AS="${@bb.utils.which(os.getenv('PATH'), 'as')}"
     if [ ! -x "${ICECC_CC}" -o ! -x "${ICECC_CXX}" ]
     then
-        bbwarn "Cannot use icecc: could not get ICECC_CC or ICECC_CXX"
+        bbnote "Cannot use icecc: could not get ICECC_CC or ICECC_CXX"
         return
     fi
 

meta/classes/image-live.bbclass

@@ -261,4 +261,4 @@ python do_bootimg() {
 do_bootimg[subimages] = "hddimg iso"
 do_bootimg[imgsuffix] = "."
 
-addtask bootimg before do_image_complete
+addtask bootimg before do_image_complete after do_rootfs

meta/classes/image_types.bbclass

@@ -108,6 +108,11 @@ IMAGE_CMD_squashfs-xz = "mksquashfs ${IMAGE_ROOTFS} ${IMGDEPLOYDIR}/${IMAGE_NAME
 IMAGE_CMD_squashfs-lzo = "mksquashfs ${IMAGE_ROOTFS} ${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.squashfs-lzo ${EXTRA_IMAGECMD} -noappend -comp lzo"
 IMAGE_CMD_squashfs-lz4 = "mksquashfs ${IMAGE_ROOTFS} ${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.squashfs-lz4 ${EXTRA_IMAGECMD} -noappend -comp lz4"
 
+IMAGE_CMD_erofs = "mkfs.erofs ${EXTRA_IMAGECMD} ${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.erofs ${IMAGE_ROOTFS}"
+IMAGE_CMD_erofs-lz4 = "mkfs.erofs -zlz4 ${EXTRA_IMAGECMD} ${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.erofs-lz4 ${IMAGE_ROOTFS}"
+IMAGE_CMD_erofs-lz4hc = "mkfs.erofs -zlz4hc ${EXTRA_IMAGECMD} ${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.erofs-lz4hc ${IMAGE_ROOTFS}"
+
+
 IMAGE_CMD_TAR ?= "tar"
 # ignore return code 1 "file changed as we read it" as other tasks(e.g. do_image_wic) may be hardlinking rootfs
 IMAGE_CMD_tar = "${IMAGE_CMD_TAR} --sort=name --format=posix --numeric-owner -cf ${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.tar -C ${IMAGE_ROOTFS} . || [ $? -eq 1 ]"
@@ -243,6 +248,9 @@ do_image_ubi[depends] += "mtd-utils-native:do_populate_sysroot"
 do_image_ubifs[depends] += "mtd-utils-native:do_populate_sysroot"
 do_image_multiubi[depends] += "mtd-utils-native:do_populate_sysroot"
 do_image_f2fs[depends] += "f2fs-tools-native:do_populate_sysroot"
+do_image_erofs[depends] += "erofs-utils-native:do_populate_sysroot"
+do_image_erofs_lz4[depends] += "erofs-utils-native:do_populate_sysroot"
+do_image_erofs_lz4hc[depends] += "erofs-utils-native:do_populate_sysroot"
 
 # This variable is available to request which values are suitable for IMAGE_FSTYPES
 IMAGE_TYPES = " \
@@ -261,6 +269,7 @@ IMAGE_TYPES = " \
     wic wic.gz wic.bz2 wic.lzma wic.zst \
     container \
     f2fs \
+    erofs erofs-lz4 erofs-lz4hc \
 "
 
 # Compression is a special case of conversion. The old variable
@@ -269,7 +278,7 @@ IMAGE_TYPES = " \
 # CONVERSION_CMD/DEPENDS.
 COMPRESSIONTYPES ?= ""
 
-CONVERSIONTYPES = "gz bz2 lzma xz lz4 lzo zip zst sum md5sum sha1sum sha224sum sha256sum sha384sum sha512sum bmap u-boot vmdk vhd vhdx vdi qcow2 base64 ${COMPRESSIONTYPES}"
+CONVERSIONTYPES = "gz bz2 lzma xz lz4 lzo zip zst sum md5sum sha1sum sha224sum sha256sum sha384sum sha512sum bmap u-boot vmdk vhd vhdx vdi qcow2 base64 gzsync zsync ${COMPRESSIONTYPES}"
 CONVERSION_CMD_lzma = "lzma -k -f -7 ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
 CONVERSION_CMD_gz = "gzip -f -9 -n -c --rsyncable ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} > ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.gz"
 CONVERSION_CMD_bz2 = "pbzip2 -f -k ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
@@ -293,6 +302,8 @@ CONVERSION_CMD_vhd = "qemu-img convert -O vpc -o subformat=fixed ${IMAGE_NAME}${
 CONVERSION_CMD_vdi = "qemu-img convert -O vdi ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.vdi"
 CONVERSION_CMD_qcow2 = "qemu-img convert -O qcow2 ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.qcow2"
 CONVERSION_CMD_base64 = "base64 ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type} > ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}.base64"
+CONVERSION_CMD_zsync = "zsyncmake_curl ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
+CONVERSION_CMD_gzsync = "zsyncmake_curl -z ${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.${type}"
 CONVERSION_DEPENDS_lzma = "xz-native"
 CONVERSION_DEPENDS_gz = "pigz-native"
 CONVERSION_DEPENDS_bz2 = "pbzip2-native"
@@ -310,6 +321,8 @@ CONVERSION_DEPENDS_qcow2 = "qemu-system-native"
 CONVERSION_DEPENDS_base64 = "coreutils-native"
 CONVERSION_DEPENDS_vhdx = "qemu-system-native"
 CONVERSION_DEPENDS_vhd = "qemu-system-native"
+CONVERSION_DEPENDS_zsync = "zsync-curl-native"
+CONVERSION_DEPENDS_gzsync = "zsync-curl-native"
 
 RUNNABLE_IMAGE_TYPES ?= "ext2 ext3 ext4"
 RUNNABLE_MACHINE_PATTERNS ?= "qemu"

meta/classes/kernel-fitimage.bbclass

@@ -217,13 +217,13 @@ fitimage_emit_section_boot_script() {
 	bootscr_sign_keyname="${UBOOT_SIGN_KEYNAME}"
 
         cat << EOF >> ${1}
-                bootscr@${2} {
+                bootscr-${2} {
                         description = "U-boot script";
                         data = /incbin/("${3}");
                         type = "script";
                         arch = "${UBOOT_ARCH}";
                         compression = "none";
-                        hash@1 {
+                        hash-1 {
                                 algo = "${bootscr_csum}";
                         };
                 };
@@ -232,7 +232,7 @@ EOF
 	if [ "${UBOOT_SIGN_ENABLE}" = "1" -a "${FIT_SIGN_INDIVIDUAL}" = "1" -a -n "${bootscr_sign_keyname}" ] ; then
 		sed -i '$ d' ${1}
 		cat << EOF >> ${1}
-                        signature@1 {
+                        signature-1 {
                                 algo = "${bootscr_csum},${bootscr_sign_algo}";
                                 key-name-hint = "${bootscr_sign_keyname}";
                         };
@@ -331,7 +331,7 @@ fitimage_emit_section_config() {
 
 	conf_csum="${FIT_HASH_ALG}"
 	conf_sign_algo="${FIT_SIGN_ALG}"
-	if [ -n "${UBOOT_SIGN_ENABLE}" ] ; then
+	if [ "${UBOOT_SIGN_ENABLE}" = "1" ] ; then
 		conf_sign_keyname="${UBOOT_SIGN_KEYNAME}"
 	fi
 
@@ -383,7 +383,7 @@ fitimage_emit_section_config() {
 	if [ -n "${bootscr_id}" ]; then
 		conf_desc="${conf_desc}${sep}u-boot script"
 		sep=", "
-		bootscr_line="bootscr = \"bootscr@${bootscr_id}\";"
+		bootscr_line="bootscr = \"bootscr-${bootscr_id}\";"
 	fi
 
 	if [ -n "${config_id}" ]; then
@@ -667,7 +667,34 @@ do_assemble_fitimage_initramfs() {
 
 addtask assemble_fitimage_initramfs before do_deploy after do_bundle_initramfs
 
-addtask generate_rsa_keys before do_assemble_fitimage after do_compile
+do_kernel_generate_rsa_keys() {
+	if [ "${UBOOT_SIGN_ENABLE}" = "0" ] && [ "${FIT_GENERATE_KEYS}" = "1" ]; then
+		bbwarn "FIT_GENERATE_KEYS is set to 1 even though UBOOT_SIGN_ENABLE is set to 0. The keys will not be generated as they won't be used."
+	fi
+
+	if [ "${UBOOT_SIGN_ENABLE}" = "1" ] && [ "${FIT_GENERATE_KEYS}" = "1" ]; then
+
+		# Generate keys only if they don't already exist
+		if [ ! -f "${UBOOT_SIGN_KEYDIR}/${UBOOT_SIGN_KEYNAME}".key ] || \
+			[ ! -f "${UBOOT_SIGN_KEYDIR}/${UBOOT_SIGN_KEYNAME}".crt ]; then
+
+			# make directory if it does not already exist
+			mkdir -p "${UBOOT_SIGN_KEYDIR}"
+
+			echo "Generating RSA private key for signing fitImage"
+			openssl genrsa ${FIT_KEY_GENRSA_ARGS} -out \
+				"${UBOOT_SIGN_KEYDIR}/${UBOOT_SIGN_KEYNAME}".key \
+			"${FIT_SIGN_NUMBITS}"
+
+			echo "Generating certificate for signing fitImage"
+			openssl req ${FIT_KEY_REQ_ARGS} "${FIT_KEY_SIGN_PKCS}" \
+				-key "${UBOOT_SIGN_KEYDIR}/${UBOOT_SIGN_KEYNAME}".key \
+				-out "${UBOOT_SIGN_KEYDIR}/${UBOOT_SIGN_KEYNAME}".crt
+		fi
+	fi
+}
+
+addtask kernel_generate_rsa_keys before do_assemble_fitimage after do_compile
 
 kernel_do_deploy[vardepsexclude] = "DATETIME"
 kernel_do_deploy_append() {
@@ -718,13 +745,13 @@ kernel_do_deploy_append() {
 # - Removes do_assemble_fitimage. FIT generation is done through
 #   do_assemble_fitimage_initramfs. do_assemble_fitimage is not needed
 #   and should not be part of the tasks to be executed.
-# - Since do_generate_rsa_keys is inserted by default
+# - Since do_kernel_generate_rsa_keys is inserted by default
 #   between do_compile and do_assemble_fitimage, this is
-#   not suitable in case of initramfs bundles.  do_generate_rsa_keys
+#   not suitable in case of initramfs bundles.  do_kernel_generate_rsa_keys
 #   should be between do_bundle_initramfs and do_assemble_fitimage_initramfs.
 python () {
     if d.getVar('INITRAMFS_IMAGE_BUNDLE') == "1":
         bb.build.deltask('do_assemble_fitimage', d)
-        bb.build.deltask('generate_rsa_keys', d)
-        bb.build.addtask('generate_rsa_keys', 'do_assemble_fitimage_initramfs', 'do_bundle_initramfs', d)
+        bb.build.deltask('kernel_generate_rsa_keys', d)
+        bb.build.addtask('kernel_generate_rsa_keys', 'do_assemble_fitimage_initramfs', 'do_bundle_initramfs', d)
 }

meta/classes/native.bbclass

@@ -119,6 +119,7 @@ python native_virtclass_handler () {
     pn = e.data.getVar("PN")
     if not pn.endswith("-native"):
         return
+    bpn = e.data.getVar("BPN")
 
     # Set features here to prevent appends and distro features backfill
     # from modifying native distro features
@@ -146,7 +147,10 @@ python native_virtclass_handler () {
             elif "-cross-" in dep:
                 newdeps.append(dep.replace("-cross", "-native"))
             elif not dep.endswith("-native"):
-                newdeps.append(dep.replace("-native", "") + "-native")
+                # Replace ${PN} with ${BPN} in the dependency to make sure
+                # dependencies on, e.g., ${PN}-foo become ${BPN}-foo-native
+                # rather than ${BPN}-native-foo-native.
+                newdeps.append(dep.replace(pn, bpn) + "-native")
             else:
                 newdeps.append(dep)
         d.setVar(varname, " ".join(newdeps), parsing=True)
@@ -166,7 +170,7 @@ python native_virtclass_handler () {
         if prov.find(pn) != -1:
             nprovides.append(prov)
         elif not prov.endswith("-native"):
-            nprovides.append(prov.replace(prov, prov + "-native"))
+            nprovides.append(prov + "-native")
         else:
             nprovides.append(prov)
     e.data.setVar("PROVIDES", ' '.join(nprovides))

meta/classes/package_rpm.bbclass

@@ -684,8 +684,8 @@ python do_package_rpm () {
     cmd = cmd + " --define '_use_internal_dependency_generator 0'"
     cmd = cmd + " --define '_binaries_in_noarch_packages_terminate_build 0'"
     cmd = cmd + " --define '_build_id_links none'"
-    cmd = cmd + " --define '_binary_payload w6T.xzdio'"
-    cmd = cmd + " --define '_source_payload w6T.xzdio'"
+    cmd = cmd + " --define '_binary_payload w6T%d.xzdio'" % int(d.getVar("XZ_THREADS"))
+    cmd = cmd + " --define '_source_payload w6T%d.xzdio'" % int(d.getVar("XZ_THREADS"))
     cmd = cmd + " --define 'clamp_mtime_to_source_date_epoch 1'"
     cmd = cmd + " --define 'use_source_date_epoch_as_buildtime 1'"
     cmd = cmd + " --define '_buildhost reproducible'"

meta/classes/reproducible_build.bbclass

@@ -80,17 +80,16 @@ python create_source_date_epoch_stamp() {
     import oe.reproducible
 
     epochfile = d.getVar('SDE_FILE')
-    # If it exists we need to regenerate as the sources may have changed
-    if os.path.isfile(epochfile):
-        bb.debug(1, "Deleting existing SOURCE_DATE_EPOCH from: %s" % epochfile)
-        os.remove(epochfile)
+    tmp_file = "%s.new" % epochfile
 
     source_date_epoch = oe.reproducible.get_source_date_epoch(d, d.getVar('S'))
 
     bb.debug(1, "SOURCE_DATE_EPOCH: %d" % source_date_epoch)
     bb.utils.mkdirhier(d.getVar('SDE_DIR'))
-    with open(epochfile, 'w') as f:
+    with open(tmp_file, 'w') as f:
         f.write(str(source_date_epoch))
+
+    os.rename(tmp_file, epochfile)
 }
 
 def get_source_date_epoch_value(d):
@@ -100,7 +99,7 @@ def get_source_date_epoch_value(d):
 
     epochfile = d.getVar('SDE_FILE')
     source_date_epoch = int(d.getVar('SOURCE_DATE_EPOCH_FALLBACK'))
-    if os.path.isfile(epochfile):
+    try:
         with open(epochfile, 'r') as f:
             s = f.read()
             try:
@@ -113,7 +112,7 @@ def get_source_date_epoch_value(d):
                 bb.warn("SOURCE_DATE_EPOCH value '%s' is invalid. Reverting to SOURCE_DATE_EPOCH_FALLBACK" % s)
                 source_date_epoch = int(d.getVar('SOURCE_DATE_EPOCH_FALLBACK'))
         bb.debug(1, "SOURCE_DATE_EPOCH: %d" % source_date_epoch)
-    else:
+    except FileNotFoundError:
         bb.debug(1, "Cannot find %s. SOURCE_DATE_EPOCH will default to %d" % (epochfile, source_date_epoch))
 
     d.setVar('__CACHED_SOURCE_DATE_EPOCH', str(source_date_epoch))

meta/classes/sstate.bbclass

@@ -706,6 +706,8 @@ def sstate_package(ss, d):
 
     return
 
+sstate_package[vardepsexclude] += "SSTATE_SIG_KEY"
+
 def pstaging_fetch(sstatefetch, d):
     import bb.fetch2
 

meta/classes/uboot-config.bbclass

@@ -71,6 +71,10 @@ UBOOT_MKIMAGE_SIGN ?= "${UBOOT_MKIMAGE}"
 UBOOT_MKIMAGE_SIGN_ARGS ?= ""
 SPL_MKIMAGE_SIGN_ARGS ?= ""
 
+# Options to deploy the u-boot device tree
+UBOOT_DTB ?= ""
+UBOOT_DTB_BINARY ??= ""
+
 python () {
     ubootmachine = d.getVar("UBOOT_MACHINE")
     ubootconfigflags = d.getVarFlags('UBOOT_CONFIG')

meta/classes/uboot-sign.bbclass

@@ -255,32 +255,7 @@ do_install_append() {
 	fi
 }
 
-do_generate_rsa_keys() {
-	if [ "${UBOOT_SIGN_ENABLE}" = "0" ] && [ "${FIT_GENERATE_KEYS}" = "1" ]; then
-		bbwarn "FIT_GENERATE_KEYS is set to 1 even though UBOOT_SIGN_ENABLE is set to 0. The keys will not be generated as they won't be used."
-	fi
-
-	if [ "${UBOOT_SIGN_ENABLE}" = "1" ] && [ "${FIT_GENERATE_KEYS}" = "1" ]; then
-
-		# Generate keys only if they don't already exist
-		if [ ! -f "${UBOOT_SIGN_KEYDIR}/${UBOOT_SIGN_KEYNAME}".key ] || \
-			[ ! -f "${UBOOT_SIGN_KEYDIR}/${UBOOT_SIGN_KEYNAME}".crt ]; then
-
-			# make directory if it does not already exist
-			mkdir -p "${UBOOT_SIGN_KEYDIR}"
-
-			echo "Generating RSA private key for signing fitImage"
-			openssl genrsa ${FIT_KEY_GENRSA_ARGS} -out \
-				"${UBOOT_SIGN_KEYDIR}/${UBOOT_SIGN_KEYNAME}".key \
-				"${FIT_SIGN_NUMBITS}"
-
-			echo "Generating certificate for signing fitImage"
-			openssl req ${FIT_KEY_REQ_ARGS} "${FIT_KEY_SIGN_PKCS}" \
-				-key "${UBOOT_SIGN_KEYDIR}/${UBOOT_SIGN_KEYNAME}".key \
-				-out "${UBOOT_SIGN_KEYDIR}/${UBOOT_SIGN_KEYNAME}".crt
-		fi
-	fi
-
+do_uboot_generate_rsa_keys() {
 	if [ "${SPL_SIGN_ENABLE}" = "0" ] && [ "${UBOOT_FIT_GENERATE_KEYS}" = "1" ]; then
 		bbwarn "UBOOT_FIT_GENERATE_KEYS is set to 1 eventhough SPL_SIGN_ENABLE is set to 0. The keys will not be generated as they won't be used."
 	fi
@@ -308,7 +283,7 @@ do_generate_rsa_keys() {
 
 }
 
-addtask generate_rsa_keys before do_uboot_assemble_fitimage after do_compile
+addtask uboot_generate_rsa_keys before do_uboot_assemble_fitimage after do_compile
 
 # Create a ITS file for the U-boot FIT, for use when
 # we want to sign it so that the SPL can verify it

meta/conf/distro/include/cve-extra-exclusions.inc

@@ -0,0 +1,73 @@
+# This file contains a list of CVE's where resolution has proven to be impractical
+# or there is no reasonable action the Yocto Project can take to resolve the issue.
+# It contains all the information we are aware of about an issue and analysis about
+# why we believe it can't be fixed/handled. Additional information is welcome through
+# patches to the file.
+#
+# Include this file in your local.conf or distro.conf to exclude these CVE's
+# from the cve-check results or add to the bitbake command with:
+#     -R conf/distro/include/cve-extra-exclusions.inc
+#
+# The file is not included by default since users should review this data to ensure
+# it matches their expectations and usage of the project.
+#
+# We may also include "in-flight" information about current/ongoing CVE work with
+# the aim of sharing that work and ensuring we don't duplicate it.
+#
+
+
+# strace https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2000-0006
+# CVE is more than 20 years old with no resolution evident
+# broken links in CVE database references make resolution impractical
+CVE_CHECK_WHITELIST += "CVE-2000-0006"
+
+# epiphany https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2005-0238
+# The issue here is spoofing of domain names using characters from other character sets.
+# There has been much discussion amongst the epiphany and webkit developers and
+# whilst there are improvements about how domains are handled and displayed to the user
+# there is unlikely ever to be a single fix to webkit or epiphany which addresses this
+# problem. Whitelisted as there isn't any mitigation or fix or way to progress this further
+# we can seem to take.
+CVE_CHECK_WHITELIST += "CVE-2005-0238"
+
+# glibc https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-4756
+# Issue is memory exhaustion via glob() calls, e.g. from within an ftp server
+# Best discussion in https://bugzilla.redhat.com/show_bug.cgi?id=681681
+# Upstream don't see it as a security issue, ftp servers shouldn't be passing
+# this to libc glob. Exclude as upstream have no plans to add BSD's GLOB_LIMIT or similar
+CVE_CHECK_WHITELIST += "CVE-2010-4756"
+
+# go https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-29509
+# go https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-29511
+# The encoding/xml package in go can potentially be used for security exploits if not used correctly
+# CVE applies to a netapp product as well as flagging a general issue. We don't ship anything
+# exposing this interface in an exploitable way
+CVE_CHECK_WHITELIST += "CVE-2020-29509 CVE-2020-29511"
+
+
+
+#### CPE update pending ####
+
+# groff:groff-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2000-0803
+# Appears it was fixed in https://git.savannah.gnu.org/cgit/groff.git/commit/?id=07f95f1674217275ed4612f1dcaa95a88435c6a7
+# so from 1.17 onwards. Reported to the database for update by RP 2021/5/9. Update accepted 2021/5/10.
+#CVE_CHECK_WHITELIST += "CVE-2000-0803"
+
+
+
+#### Upstream still working on ####
+
+# qemu:qemu-native:qemu-system-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-20255
+# There was a proposed patch https://lists.gnu.org/archive/html/qemu-devel/2021-02/msg06098.html
+# however qemu maintainers are sure the patch is incorrect and should not be applied.
+
+# flex:flex-native https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-6293
+# Upstream bug, still open: https://github.com/westes/flex/issues/414
+# Causes memory exhaustion so potential DoS but no buffer overflow, low priority
+
+# wget https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2021-31879
+# https://mail.gnu.org/archive/html/bug-wget/2021-02/msg00002.html
+# No response upstream as of 2021/5/12
+
+
+

meta/conf/distro/include/distro_alias.inc

@@ -26,21 +26,11 @@ DISTRO_PN_ALIAS_pn-builder = "OE-Core"
 DISTRO_PN_ALIAS_pn-buildtools-tarball = "OE-Core"
 DISTRO_PN_ALIAS_pn-cdrtools = "OpenSUSE=cdrtools OSPDT"
 DISTRO_PN_ALIAS_pn-chkconfig-alternatives = "Mandriva=chkconfig Debian=chkconfig"
-DISTRO_PN_ALIAS_pn-clutter = "Fedora=clutter OpenSuse=clutter Ubuntu=clutter-1.0 Mandriva=clutter Debian=clutter"
-DISTRO_PN_ALIAS_pn-clutter-1.8 = "Fedora=clutter OpenSuse=clutter Ubuntu=clutter-1.0 Mandriva=clutter Debian=clutter"
-DISTRO_PN_ALIAS_pn-clutter-gst-1.0 = "Debian=clutter-gst Ubuntu=clutter-gst Fedora=clutter-gst"
-DISTRO_PN_ALIAS_pn-clutter-gst-1.8 = "Fedora=clutter-gst Debian=libclutter-gst"
-DISTRO_PN_ALIAS_pn-clutter-gst-3.0 = "Ubuntu=libclutter-gst Debian=libclutter-gst"
-DISTRO_PN_ALIAS_pn-clutter-gtk-1.0 = "Debian=clutter-gtk Ubuntu=clutter-gtk Fedora=clutter-gtk"
-DISTRO_PN_ALIAS_pn-clutter-gtk-1.8 = "Fedora=clutter-gtk OpenSuSE=clutter-gtk Ubuntu=clutter-gtk-0.10 Mandriva=clutter-gtk Debian=clutter-gtk"
-DISTRO_PN_ALIAS_pn-cogl-1.0 = "Debian=cogl Ubuntu=cogl Fedora=cogl"
-DISTRO_PN_ALIAS_pn-cogl = "Fedora=cogl OpenSuse=cogl Ubuntu=cogl Mandriva=cogl Debian=cogl"
 DISTRO_PN_ALIAS_pn-connman = "Meego=connman"
 DISTRO_PN_ALIAS_pn-connman-conf = "OE-Core"
 DISTRO_PN_ALIAS_pn-connman-gnome = "Intel"
 DISTRO_PN_ALIAS_pn-console-tools = "Debian=console-tools Ubuntu=console-tools"
 DISTRO_PN_ALIAS_pn-core-image-base = "OE-Core"
-DISTRO_PN_ALIAS_pn-core-image-clutter = "OE-Core"
 DISTRO_PN_ALIAS_pn-core-image-full-cmdline = "OE-Core"
 DISTRO_PN_ALIAS_pn-core-image-kernel-dev = "OE-Core"
 DISTRO_PN_ALIAS_pn-core-image-minimal = "OE-Core"
@@ -248,7 +238,6 @@ DISTRO_PN_ALIAS_pn-packagegroup-base = "OE-Core"
 DISTRO_PN_ALIAS_pn-packagegroup-core = "OE-Core"
 DISTRO_PN_ALIAS_pn-packagegroup-core-boot = "OE-Core"
 DISTRO_PN_ALIAS_pn-packagegroup-core-buildessential = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-core-clutter = "OE-Core"
 DISTRO_PN_ALIAS_pn-packagegroup-core-device-devel = "OE-Core"
 DISTRO_PN_ALIAS_pn-packagegroup-core-eclipse-debug = "OE-Core"
 DISTRO_PN_ALIAS_pn-packagegroup-core-full-cmdline = "OE-Core"

meta/conf/distro/include/maintainers.inc

@@ -48,9 +48,9 @@ RECIPE_MAINTAINER_pn-asciidoc = "Yi Zhao <yi.zhao@windriver.com>"
 RECIPE_MAINTAINER_pn-aspell = "Anuj Mittal <anuj.mittal@intel.com>"
 RECIPE_MAINTAINER_pn-assimp = "Anuj Mittal <anuj.mittal@intel.com>"
 RECIPE_MAINTAINER_pn-at = "Chen Qi <Qi.Chen@windriver.com>"
-RECIPE_MAINTAINER_pn-at-spi2-atk = "Tim Orling <timothy.t.orling@linux.intel.com>"
-RECIPE_MAINTAINER_pn-at-spi2-core = "Tim Orling <timothy.t.orling@linux.intel.com>"
-RECIPE_MAINTAINER_pn-atk = "Tim Orling <timothy.t.orling@linux.intel.com>"
+RECIPE_MAINTAINER_pn-at-spi2-atk = "Tim Orling <timothy.t.orling@intel.com>"
+RECIPE_MAINTAINER_pn-at-spi2-core = "Tim Orling <timothy.t.orling@intel.com>"
+RECIPE_MAINTAINER_pn-atk = "Tim Orling <timothy.t.orling@intel.com>"
 RECIPE_MAINTAINER_pn-attr = "Chen Qi <Qi.Chen@windriver.com>"
 RECIPE_MAINTAINER_pn-autoconf = "Robert Yang <liezhi.yang@windriver.com>"
 RECIPE_MAINTAINER_pn-autoconf-archive = "Robert Yang <liezhi.yang@windriver.com>"
@@ -93,12 +93,8 @@ RECIPE_MAINTAINER_pn-cantarell-fonts = "Alexander Kanavin <alex.kanavin@gmail.co
 RECIPE_MAINTAINER_pn-ccache = "Robert Yang <liezhi.yang@windriver.com>"
 RECIPE_MAINTAINER_pn-cdrtools-native = "Yi Zhao <yi.zhao@windriver.com>"
 RECIPE_MAINTAINER_pn-chrpath = "Yi Zhao <yi.zhao@windriver.com>"
-RECIPE_MAINTAINER_pn-clutter-1.0 = "Ross Burton <ross.burton@arm.com>"
-RECIPE_MAINTAINER_pn-clutter-gst-3.0 = "Ross Burton <ross.burton@arm.com>"
-RECIPE_MAINTAINER_pn-clutter-gtk-1.0 = "Ross Burton <ross.burton@arm.com>"
 RECIPE_MAINTAINER_pn-cmake = "Pascal Bach <pascal.bach@siemens.com>"
 RECIPE_MAINTAINER_pn-cmake-native = "Pascal Bach <pascal.bach@siemens.com>"
-RECIPE_MAINTAINER_pn-cogl-1.0 = "Ross Burton <ross.burton@arm.com>"
 RECIPE_MAINTAINER_pn-connman = "Changhyeok Bae <changhyeok.bae@gmail.com>"
 RECIPE_MAINTAINER_pn-connman-conf = "Ross Burton <ross.burton@arm.com>"
 RECIPE_MAINTAINER_pn-connman-gnome = "Ross Burton <ross.burton@arm.com>"
@@ -111,19 +107,16 @@ RECIPE_MAINTAINER_pn-core-image-minimal-mtdutils = "Richard Purdie <richard.purd
 RECIPE_MAINTAINER_pn-core-image-tiny-initramfs = "Richard Purdie <richard.purdie@linuxfoundation.org>"
 RECIPE_MAINTAINER_pn-core-image-full-cmdline = "Richard Purdie <richard.purdie@linuxfoundation.org>"
 RECIPE_MAINTAINER_pn-core-image-kernel-dev = "Richard Purdie <richard.purdie@linuxfoundation.org>"
+RECIPE_MAINTAINER_pn-core-image-ptest-all = "Richard Purdie <richard.purdie@linuxfoundation.org>"
+RECIPE_MAINTAINER_pn-core-image-ptest-fast = "Richard Purdie <richard.purdie@linuxfoundation.org>"
 RECIPE_MAINTAINER_pn-core-image-sato = "Richard Purdie <richard.purdie@linuxfoundation.org>"
 RECIPE_MAINTAINER_pn-core-image-sato-sdk = "Richard Purdie <richard.purdie@linuxfoundation.org>"
 RECIPE_MAINTAINER_pn-core-image-testmaster-initramfs = "Richard Purdie <richard.purdie@linuxfoundation.org>"
 RECIPE_MAINTAINER_pn-core-image-testmaster = "Richard Purdie <richard.purdie@linuxfoundation.org>"
-RECIPE_MAINTAINER_pn-core-image-clutter = "Richard Purdie <richard.purdie@linuxfoundation.org>"
 RECIPE_MAINTAINER_pn-core-image-weston = "Richard Purdie <richard.purdie@linuxfoundation.org>"
-RECIPE_MAINTAINER_pn-core-image-weston-ptest-all = "Richard Purdie <richard.purdie@linuxfoundation.org>"
-RECIPE_MAINTAINER_pn-core-image-weston-ptest-fast = "Richard Purdie <richard.purdie@linuxfoundation.org>"
 RECIPE_MAINTAINER_pn-core-image-weston-sdk = "Richard Purdie <richard.purdie@linuxfoundation.org>"
 RECIPE_MAINTAINER_pn-core-image-x11 = "Richard Purdie <richard.purdie@linuxfoundation.org>"
 RECIPE_MAINTAINER_pn-core-image-sato-dev = "Richard Purdie <richard.purdie@linuxfoundation.org>"
-RECIPE_MAINTAINER_pn-core-image-sato-ptest-fast = "Richard Purdie <richard.purdie@linuxfoundation.org>"
-RECIPE_MAINTAINER_pn-core-image-sato-sdk-ptest = "Richard Purdie <richard.purdie@linuxfoundation.org>"
 RECIPE_MAINTAINER_pn-coreutils = "Chen Qi <Qi.Chen@windriver.com>"
 RECIPE_MAINTAINER_pn-cpio = "Denys Dmytriyenko <denis@denix.org>"
 RECIPE_MAINTAINER_pn-cracklib = "Armin Kuster <akuster808@gmail.com>"
@@ -171,6 +164,7 @@ RECIPE_MAINTAINER_pn-ell = "Zang Ruochen <zangrc.fnst@fujitsu.com>"
 RECIPE_MAINTAINER_pn-enchant2 = "Anuj Mittal <anuj.mittal@intel.com>"
 RECIPE_MAINTAINER_pn-encodings = "Armin Kuster <akuster808@gmail.com>"
 RECIPE_MAINTAINER_pn-epiphany = "Alexander Kanavin <alex.kanavin@gmail.com>"
+RECIPE_MAINTAINER_pn-erofs-utils = "Richard Weinberger <richard@nod.at>"
 RECIPE_MAINTAINER_pn-ethtool = "Changhyeok Bae <changhyeok.bae@gmail.com>"
 RECIPE_MAINTAINER_pn-eudev = "Anuj Mittal <anuj.mittal@intel.com>"
 RECIPE_MAINTAINER_pn-expat = "Yi Zhao <yi.zhao@windriver.com>"
@@ -316,7 +310,7 @@ RECIPE_MAINTAINER_pn-libcap-ng-python = "Yi Zhao <yi.zhao@windriver.com>"
 RECIPE_MAINTAINER_pn-libcgroup = "Alexander Kanavin <alex.kanavin@gmail.com>"
 RECIPE_MAINTAINER_pn-libcheck = "Yi Zhao <yi.zhao@windriver.com>"
 RECIPE_MAINTAINER_pn-libcomps = "Alexander Kanavin <alex.kanavin@gmail.com>"
-RECIPE_MAINTAINER_pn-libconvert-asn1-perl = "Tim Orling <timothy.t.orling@linux.intel.com>"
+RECIPE_MAINTAINER_pn-libconvert-asn1-perl = "Tim Orling <timothy.t.orling@intel.com>"
 RECIPE_MAINTAINER_pn-libcroco = "Anuj Mittal <anuj.mittal@intel.com>"
 RECIPE_MAINTAINER_pn-libdaemon = "Alexander Kanavin <alex.kanavin@gmail.com>"
 RECIPE_MAINTAINER_pn-libdazzle = "Alexander Kanavin <alex.kanavin@gmail.com>"
@@ -326,7 +320,7 @@ RECIPE_MAINTAINER_pn-libdrm = "Otavio Salvador <otavio.salvador@ossystems.com.br
 RECIPE_MAINTAINER_pn-libedit = "Khem Raj <raj.khem@gmail.com>"
 RECIPE_MAINTAINER_pn-libepoxy = "Anuj Mittal <anuj.mittal@intel.com>"
 RECIPE_MAINTAINER_pn-liberation-fonts = "Alexander Kanavin <alex.kanavin@gmail.com>"
-RECIPE_MAINTAINER_pn-liberror-perl = "Tim Orling <timothy.t.orling@linux.intel.com>"
+RECIPE_MAINTAINER_pn-liberror-perl = "Tim Orling <timothy.t.orling@intel.com>"
 RECIPE_MAINTAINER_pn-libevdev = "Anuj Mittal <anuj.mittal@intel.com>"
 RECIPE_MAINTAINER_pn-libevent = "Anuj Mittal <anuj.mittal@intel.com>"
 RECIPE_MAINTAINER_pn-libexif = "Alexander Kanavin <alex.kanavin@gmail.com>"
@@ -357,7 +351,7 @@ RECIPE_MAINTAINER_pn-libmd = "Alexander Kanavin <alex.kanavin@gmail.com>"
 RECIPE_MAINTAINER_pn-libmicrohttpd = "Alexander Kanavin <alex.kanavin@gmail.com>"
 RECIPE_MAINTAINER_pn-libmnl = "Khem Raj <raj.khem@gmail.com>"
 RECIPE_MAINTAINER_pn-libmpc = "Khem Raj <raj.khem@gmail.com>"
-RECIPE_MAINTAINER_pn-libmodule-build-perl = "Tim Orling <timothy.t.orling@linux.intel.com>"
+RECIPE_MAINTAINER_pn-libmodule-build-perl = "Tim Orling <timothy.t.orling@intel.com>"
 RECIPE_MAINTAINER_pn-libmodulemd = "Alexander Kanavin <alex.kanavin@gmail.com>"
 RECIPE_MAINTAINER_pn-libnewt = "Hongxu Jia <hongxu.jia@windriver.com>"
 RECIPE_MAINTAINER_pn-libnl = "Alexander Kanavin <alex.kanavin@gmail.com>"
@@ -391,9 +385,9 @@ RECIPE_MAINTAINER_pn-libsoup-2.4 = "Anuj Mittal <anuj.mittal@intel.com>"
 RECIPE_MAINTAINER_pn-libssh2 = "Unassigned <unassigned@yoctoproject.org>"
 RECIPE_MAINTAINER_pn-libssp-nonshared = "Khem Raj <raj.khem@gmail.com>"
 RECIPE_MAINTAINER_pn-libtasn1 = "Anuj Mittal <anuj.mittal@intel.com>"
-RECIPE_MAINTAINER_pn-libtest-needs-perl = "Tim Orling <timothy.t.orling@linux.intel.com>"
+RECIPE_MAINTAINER_pn-libtest-needs-perl = "Tim Orling <timothy.t.orling@intel.com>"
 RECIPE_MAINTAINER_pn-libtheora = "Alexander Kanavin <alex.kanavin@gmail.com>"
-RECIPE_MAINTAINER_pn-libtimedate-perl = "Tim Orling <timothy.t.orling@linux.intel.com>"
+RECIPE_MAINTAINER_pn-libtimedate-perl = "Tim Orling <timothy.t.orling@intel.com>"
 RECIPE_MAINTAINER_pn-libtirpc = "Anuj Mittal <anuj.mittal@intel.com>"
 RECIPE_MAINTAINER_pn-libtool = "Robert Yang <liezhi.yang@windriver.com>"
 RECIPE_MAINTAINER_pn-libtool-cross = "Robert Yang <liezhi.yang@windriver.com>"
@@ -402,7 +396,7 @@ RECIPE_MAINTAINER_pn-libucontext = "Khem Raj <raj.khem@gmail.com>"
 RECIPE_MAINTAINER_pn-libunistring = "Anuj Mittal <anuj.mittal@intel.com>"
 RECIPE_MAINTAINER_pn-libunwind = "Bruce Ashfield <bruce.ashfield@gmail.com>"
 RECIPE_MAINTAINER_pn-liburcu = "Wang Mingyu <wangmy@fujitsu.com>"
-RECIPE_MAINTAINER_pn-liburi-perl = "Tim Orling <timothy.t.orling@linux.intel.com>"
+RECIPE_MAINTAINER_pn-liburi-perl = "Tim Orling <timothy.t.orling@intel.com>"
 RECIPE_MAINTAINER_pn-libusb1 = "Anuj Mittal <anuj.mittal@intel.com>"
 RECIPE_MAINTAINER_pn-libubootenv = "Stefano Babic <sbabic@denx.de>"
 RECIPE_MAINTAINER_pn-libuv = "Armin Kuster <akuster@mvista.com>"
@@ -430,12 +424,12 @@ RECIPE_MAINTAINER_pn-libxi = "Armin Kuster <akuster808@gmail.com>"
 RECIPE_MAINTAINER_pn-libxinerama = "Armin Kuster <akuster808@gmail.com>"
 RECIPE_MAINTAINER_pn-libxkbcommon = "Armin Kuster <akuster808@gmail.com>"
 RECIPE_MAINTAINER_pn-libxkbfile = "Armin Kuster <akuster808@gmail.com>"
-RECIPE_MAINTAINER_pn-libxml-namespacesupport-perl = "Tim Orling <timothy.t.orling@linux.intel.com>"
-RECIPE_MAINTAINER_pn-libxml-parser-perl = "Tim Orling <timothy.t.orling@linux.intel.com>"
-RECIPE_MAINTAINER_pn-libxml-perl = "Tim Orling <timothy.t.orling@linux.intel.com>"
-RECIPE_MAINTAINER_pn-libxml-sax-base-perl = "Tim Orling <timothy.t.orling@linux.intel.com>"
-RECIPE_MAINTAINER_pn-libxml-sax-perl = "Tim Orling <timothy.t.orling@linux.intel.com>"
-RECIPE_MAINTAINER_pn-libxml-simple-perl = "Tim Orling <timothy.t.orling@linux.intel.com>"
+RECIPE_MAINTAINER_pn-libxml-namespacesupport-perl = "Tim Orling <timothy.t.orling@intel.com>"
+RECIPE_MAINTAINER_pn-libxml-parser-perl = "Tim Orling <timothy.t.orling@intel.com>"
+RECIPE_MAINTAINER_pn-libxml-perl = "Tim Orling <timothy.t.orling@intel.com>"
+RECIPE_MAINTAINER_pn-libxml-sax-base-perl = "Tim Orling <timothy.t.orling@intel.com>"
+RECIPE_MAINTAINER_pn-libxml-sax-perl = "Tim Orling <timothy.t.orling@intel.com>"
+RECIPE_MAINTAINER_pn-libxml-simple-perl = "Tim Orling <timothy.t.orling@intel.com>"
 RECIPE_MAINTAINER_pn-libxml2 = "Hongxu Jia <hongxu.jia@windriver.com>"
 RECIPE_MAINTAINER_pn-libxmu = "Armin Kuster <akuster808@gmail.com>"
 RECIPE_MAINTAINER_pn-libxpm = "Armin Kuster <akuster808@gmail.com>"
@@ -521,7 +515,6 @@ RECIPE_MAINTAINER_pn-mtools = "Anuj Mittal <anuj.mittal@intel.com>"
 RECIPE_MAINTAINER_pn-musl = "Khem Raj <raj.khem@gmail.com>"
 RECIPE_MAINTAINER_pn-musl-obstack = "Khem Raj <raj.khem@gmail.com>"
 RECIPE_MAINTAINER_pn-musl-utils = "Khem Raj <raj.khem@gmail.com>"
-RECIPE_MAINTAINER_pn-mx-1.0 = "Anuj Mittal <anuj.mittal@intel.com>"
 RECIPE_MAINTAINER_pn-nasm = "Richard Purdie <richard.purdie@linuxfoundation.org>"
 RECIPE_MAINTAINER_pn-nativesdk-buildtools-perl-dummy = "Richard Purdie <richard.purdie@linuxfoundation.org>"
 RECIPE_MAINTAINER_pn-nativesdk-icecc-toolchain = "Joshua Watt <JPEWhacker@gmail.com>"
@@ -565,6 +558,7 @@ RECIPE_MAINTAINER_pn-pciutils = "Chen Qi <Qi.Chen@windriver.com>"
 RECIPE_MAINTAINER_pn-pcmanfm = "Alexander Kanavin <alex.kanavin@gmail.com>"
 RECIPE_MAINTAINER_pn-perf = "Bruce Ashfield <bruce.ashfield@gmail.com>"
 RECIPE_MAINTAINER_pn-perl = "Alexander Kanavin <alex.kanavin@gmail.com>"
+RECIPE_MAINTAINER_pn-perlcross = "Alexander Kanavin <alex.kanavin@gmail.com>"
 RECIPE_MAINTAINER_pn-piglit = "Ross Burton <ross.burton@arm.com>"
 RECIPE_MAINTAINER_pn-pigz = "Hongxu Jia <hongxu.jia@windriver.com>"
 RECIPE_MAINTAINER_pn-pinentry = "Armin Kuster <akuster808@gmail.com>"
@@ -589,8 +583,8 @@ RECIPE_MAINTAINER_pn-pulseaudio-client-conf-sato = "Unassigned <unassigned@yocto
 RECIPE_MAINTAINER_pn-puzzles = "Anuj Mittal <anuj.mittal@intel.com>"
 RECIPE_MAINTAINER_pn-python3 = "Oleksandr Kravchuk <open.source@oleksandr-kravchuk.com>"
 RECIPE_MAINTAINER_pn-python3-async = "Oleksandr Kravchuk <open.source@oleksandr-kravchuk.com>"
-RECIPE_MAINTAINER_pn-python3-atomicwrites = "Tim Orling <timothy.t.orling@linux.intel.com>"
-RECIPE_MAINTAINER_pn-python3-attrs = "Tim Orling <timothy.t.orling@linux.intel.com>"
+RECIPE_MAINTAINER_pn-python3-atomicwrites = "Tim Orling <timothy.t.orling@intel.com>"
+RECIPE_MAINTAINER_pn-python3-attrs = "Tim Orling <timothy.t.orling@intel.com>"
 RECIPE_MAINTAINER_pn-python3-cython = "Oleksandr Kravchuk <open.source@oleksandr-kravchuk.com>"
 RECIPE_MAINTAINER_pn-python3-dbus = "Zang Ruochen <zangrc.fnst@fujitsu.com>"
 RECIPE_MAINTAINER_pn-python3-dbusmock = "Oleksandr Kravchuk <open.source@oleksandr-kravchuk.com>"
@@ -600,9 +594,9 @@ RECIPE_MAINTAINER_pn-python3-pycryptodomex = "Joshua Watt <JPEWhacker@gmail.com>
 RECIPE_MAINTAINER_pn-python3-extras = "Oleksandr Kravchuk <open.source@oleksandr-kravchuk.com>"
 RECIPE_MAINTAINER_pn-python3-git = "Oleksandr Kravchuk <open.source@oleksandr-kravchuk.com>"
 RECIPE_MAINTAINER_pn-python3-gitdb = "Oleksandr Kravchuk <open.source@oleksandr-kravchuk.com>"
-RECIPE_MAINTAINER_pn-python3-hypothesis = "Tim Orling <timothy.t.orling@linux.intel.com>"
-RECIPE_MAINTAINER_pn-python3-importlib-metadata = "Tim Orling <timothy.t.orling@linux.intel.com>"
-RECIPE_MAINTAINER_pn-python3-iniconfig = "Tim Orling <timothy.t.orling@linux.intel.com>"
+RECIPE_MAINTAINER_pn-python3-hypothesis = "Tim Orling <timothy.t.orling@intel.com>"
+RECIPE_MAINTAINER_pn-python3-importlib-metadata = "Tim Orling <timothy.t.orling@intel.com>"
+RECIPE_MAINTAINER_pn-python3-iniconfig = "Tim Orling <timothy.t.orling@intel.com>"
 RECIPE_MAINTAINER_pn-python3-iniparse = "Oleksandr Kravchuk <open.source@oleksandr-kravchuk.com>"
 RECIPE_MAINTAINER_pn-python3-jinja2 = "Richard Purdie <richard.purdie@linuxfoundation.org>"
 RECIPE_MAINTAINER_pn-python3-libarchive-c = "Joshua Watt <JPEWhacker@gmail.com>"
@@ -610,36 +604,36 @@ RECIPE_MAINTAINER_pn-python3-magic = "Joshua Watt <JPEWhacker@gmail.com>"
 RECIPE_MAINTAINER_pn-python3-mako = "Oleksandr Kravchuk <open.source@oleksandr-kravchuk.com>"
 RECIPE_MAINTAINER_pn-python3-markdown = "Alexander Kanavin <alex.kanavin@gmail.com>"
 RECIPE_MAINTAINER_pn-python3-markupsafe = "Richard Purdie <richard.purdie@linuxfoundation.org>"
-RECIPE_MAINTAINER_pn-python3-more-itertools = "Tim Orling <timothy.t.orling@linux.intel.com>"
+RECIPE_MAINTAINER_pn-python3-more-itertools = "Tim Orling <timothy.t.orling@intel.com>"
 RECIPE_MAINTAINER_pn-python3-nose = "Oleksandr Kravchuk <open.source@oleksandr-kravchuk.com>"
 RECIPE_MAINTAINER_pn-python3-numpy = "Oleksandr Kravchuk <open.source@oleksandr-kravchuk.com>"
-RECIPE_MAINTAINER_pn-python3-packaging = "Tim Orling <timothy.t.orling@linux.intel.com>"
-RECIPE_MAINTAINER_pn-python3-pathlib2 = "Tim Orling <timothy.t.orling@linux.intel.com>"
+RECIPE_MAINTAINER_pn-python3-packaging = "Tim Orling <timothy.t.orling@intel.com>"
+RECIPE_MAINTAINER_pn-python3-pathlib2 = "Tim Orling <timothy.t.orling@intel.com>"
 RECIPE_MAINTAINER_pn-python3-pbr = "Zang Ruochen <zangrc.fnst@fujitsu.com>"
 RECIPE_MAINTAINER_pn-python3-pip = "Zang Ruochen <zangrc.fnst@fujitsu.com>"
-RECIPE_MAINTAINER_pn-python3-pluggy = "Tim Orling <timothy.t.orling@linux.intel.com>"
-RECIPE_MAINTAINER_pn-python3-py = "Tim Orling <timothy.t.orling@linux.intel.com>"
-RECIPE_MAINTAINER_pn-python3-pyyaml = "Tim Orling <timothy.t.orling@linux.intel.com>"
+RECIPE_MAINTAINER_pn-python3-pluggy = "Tim Orling <timothy.t.orling@intel.com>"
+RECIPE_MAINTAINER_pn-python3-py = "Tim Orling <timothy.t.orling@intel.com>"
+RECIPE_MAINTAINER_pn-python3-pyyaml = "Tim Orling <timothy.t.orling@intel.com>"
 RECIPE_MAINTAINER_pn-python3-pycairo = "Zang Ruochen <zangrc.fnst@fujitsu.com>"
 RECIPE_MAINTAINER_pn-python3-pyelftools = "Joshua Watt <JPEWhacker@gmail.com>"
 RECIPE_MAINTAINER_pn-python3-pygments = "Oleksandr Kravchuk <open.source@oleksandr-kravchuk.com>"
 RECIPE_MAINTAINER_pn-python3-pygobject = "Zang Ruochen <zangrc.fnst@fujitsu.com>"
 RECIPE_MAINTAINER_pn-python3-pyparsing = "Oleksandr Kravchuk <open.source@oleksandr-kravchuk.com>"
-RECIPE_MAINTAINER_pn-python3-pytest = "Tim Orling <timothy.t.orling@linux.intel.com>"
-RECIPE_MAINTAINER_pn-python3-scons = "Tim Orling <timothy.t.orling@linux.intel.com>"
-RECIPE_MAINTAINER_pn-python3-scons-native = "Tim Orling <timothy.t.orling@linux.intel.com>"
+RECIPE_MAINTAINER_pn-python3-pytest = "Tim Orling <timothy.t.orling@intel.com>"
+RECIPE_MAINTAINER_pn-python3-scons = "Tim Orling <timothy.t.orling@intel.com>"
+RECIPE_MAINTAINER_pn-python3-scons-native = "Tim Orling <timothy.t.orling@intel.com>"
 RECIPE_MAINTAINER_pn-python3-setuptools = "Oleksandr Kravchuk <open.source@oleksandr-kravchuk.com>"
-RECIPE_MAINTAINER_pn-python3-setuptools-scm = "Tim Orling <timothy.t.orling@linux.intel.com>"
+RECIPE_MAINTAINER_pn-python3-setuptools-scm = "Tim Orling <timothy.t.orling@intel.com>"
 RECIPE_MAINTAINER_pn-python3-six = "Zang Ruochen <zangrc.fnst@fujitsu.com>"
 RECIPE_MAINTAINER_pn-python3-smartypants = "Alexander Kanavin <alex.kanavin@gmail.com>"
 RECIPE_MAINTAINER_pn-python3-smmap = "Oleksandr Kravchuk <open.source@oleksandr-kravchuk.com>"
-RECIPE_MAINTAINER_pn-python3-sortedcontainers = "Tim Orling <timothy.t.orling@linux.intel.com>"
+RECIPE_MAINTAINER_pn-python3-sortedcontainers = "Tim Orling <timothy.t.orling@intel.com>"
 RECIPE_MAINTAINER_pn-python3-subunit = "Oleksandr Kravchuk <open.source@oleksandr-kravchuk.com>"
 RECIPE_MAINTAINER_pn-python3-testtools = "Oleksandr Kravchuk <open.source@oleksandr-kravchuk.com>"
-RECIPE_MAINTAINER_pn-python3-toml = "Tim Orling <timothy.t.orling@linux.intel.com>"
+RECIPE_MAINTAINER_pn-python3-toml = "Tim Orling <timothy.t.orling@intel.com>"
 RECIPE_MAINTAINER_pn-python3-typogrify = "Alexander Kanavin <alex.kanavin@gmail.com>"
-RECIPE_MAINTAINER_pn-python3-wcwidth = "Tim Orling <timothy.t.orling@linux.intel.com>"
-RECIPE_MAINTAINER_pn-python3-zipp = "Tim Orling <timothy.t.orling@linux.intel.com>"
+RECIPE_MAINTAINER_pn-python3-wcwidth = "Tim Orling <timothy.t.orling@intel.com>"
+RECIPE_MAINTAINER_pn-python3-zipp = "Tim Orling <timothy.t.orling@intel.com>"
 RECIPE_MAINTAINER_pn-qemu = "Richard Purdie <richard.purdie@linuxfoundation.org>"
 RECIPE_MAINTAINER_pn-qemu-helper-native = "Richard Purdie <richard.purdie@linuxfoundation.org>"
 RECIPE_MAINTAINER_pn-qemu-native = "Richard Purdie <richard.purdie@linuxfoundation.org>"

meta/conf/distro/include/ptest-packagelists.inc

@@ -88,7 +88,6 @@ PTESTS_SLOW_remove_riscv64 = "valgrind-ptest"
 PTESTS_PROBLEMS_append_riscv64 = "valgrind-ptest"
 
 #    ruby-ptest \ # Timeout
-#    clutter-1.0-ptest \ # Doesn't build due to depends on cogl-1.0
 #    lz4-ptest \ # Needs a rewrite
 #    rt-tests-ptest \ # Needs to be checked whether it runs at all
 #    bash-ptest \ # Test outcomes are non-deterministic by design
@@ -102,7 +101,6 @@ PTESTS_PROBLEMS_append_riscv64 = "valgrind-ptest"
 
 PTESTS_PROBLEMS = "\
     ruby-ptest \
-    clutter-1.0-ptest \
     lz4-ptest \
     rt-tests-ptest \
     bash-ptest \

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

@@ -8,7 +8,7 @@
 
 UNINATIVE_MAXGLIBCVERSION = "2.33"
 
-UNINATIVE_URL ?= "http://downloads.yoctoproject.org/releases/uninative/3.1/"
-UNINATIVE_CHECKSUM[aarch64] ?= "7fa12b9fe7a95934cc09beb0e8a25ff97179ef3105116015d32548eadd27b024"
-UNINATIVE_CHECKSUM[i686] ?= "bbfcdd48336800b5af97e294918c6586a0a8fa903f127f813b0bd5110de8c55c"
-UNINATIVE_CHECKSUM[x86_64] ?= "5d0611df544edff6428cef7d871257a91aa6ba1bd92f5365a2df8deb54b6b31e"
+UNINATIVE_URL ?= "http://downloads.yoctoproject.org/releases/uninative/3.2/"
+UNINATIVE_CHECKSUM[aarch64] ?= "4f0872cdca2775b637a8a99815ca5c8dd42146abe903a24a50ee0448358c764b"
+UNINATIVE_CHECKSUM[i686] ?= "e2eeab92e67263db37d9bb6d4c58579abd1f47ff4cded3171bde572fece124b2"
+UNINATIVE_CHECKSUM[x86_64] ?= "3ee8c7d55e2d4c7ae3887cddb97219f97b94efddfeee2e24923c0cb0e8ce84c6"

meta/conf/machine-sdk/ppc64.conf

@@ -0,0 +1,2 @@
+SDK_ARCH = "ppc64"
+ABIEXTENSION_class-nativesdk = ""

meta/conf/machine/include/arm/arch-armv4.inc

@@ -2,7 +2,7 @@ DEFAULTTUNE ?= "armv4"
 
 TUNEVALID[arm] = "Enable ARM instruction set"
 TUNEVALID[armv4] = "Enable instructions for ARMv4"
-TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv4', ' -march=armv4t', '', d)}"
+TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv4', ' -march=armv4${ARMPKGSFX_THUMB}', '', d)}"
 # enable --fix-v4bx when we have armv4 in TUNE_FEATURES, but then disable it when we have also armv5 or thumb
 # maybe we should extend bb.utils.contains to support check for any checkvalues in value, now it does 
 # checkvalues.issubset(val) which cannot be used for negative test of foo neither bar in value

meta/lib/oe/gpg_sign.py

@@ -111,7 +111,7 @@ class LocalSigner(object):
 
     def verify(self, sig_file):
         """Verify signature"""
-        cmd = self.gpg_cmd + [" --verify", "--no-permission-warning"]
+        cmd = self.gpg_cmd + ["--verify", "--no-permission-warning"]
         if self.gpg_path:
             cmd += ["--homedir", self.gpg_path]
 

meta/lib/oe/package_manager/rpm/__init__.py

@@ -199,6 +199,9 @@ class RpmPM(PackageManager):
 
         failed_scriptlets_pkgnames = collections.OrderedDict()
         for line in output.splitlines():
+            if line.startswith("Error: Systemctl"):
+                bb.error(line)
+
             if line.startswith("Error in POSTIN scriptlet in rpm package"):
                 failed_scriptlets_pkgnames[line.split()[-1]] = True
 

meta/lib/oe/sstatesig.py

@@ -248,13 +248,24 @@ class SignatureGeneratorOEBasicHashMixIn(object):
                 f.write('    "\n')
             f.write('SIGGEN_LOCKEDSIGS_TYPES_%s = "%s"' % (self.machine, " ".join(l)))
 
-    def dump_siglist(self, sigfile):
+    def dump_siglist(self, sigfile, path_prefix_strip=None):
+        def strip_fn(fn):
+            nonlocal path_prefix_strip
+            if not path_prefix_strip:
+                return fn
+
+            fn_exp = fn.split(":")
+            if fn_exp[-1].startswith(path_prefix_strip):
+                fn_exp[-1] = fn_exp[-1][len(path_prefix_strip):]
+
+            return ":".join(fn_exp)
+
         with open(sigfile, "w") as f:
             tasks = []
             for taskitem in self.taskhash:
                 (fn, task) = taskitem.rsplit(":", 1)
                 pn = self.lockedpnmap[fn]
-                tasks.append((pn, task, fn, self.taskhash[taskitem]))
+                tasks.append((pn, task, strip_fn(fn), self.taskhash[taskitem]))
             for (pn, task, fn, taskhash) in sorted(tasks):
                 f.write('%s:%s %s %s\n' % (pn, task, fn, taskhash))
 
@@ -453,7 +464,7 @@ def find_sstate_manifest(taskdata, taskdata2, taskname, d, multilibcache):
         manifest = d2.expand("${SSTATE_MANIFESTS}/manifest-%s-%s.%s" % (pkgarch, taskdata, taskname))
         if os.path.exists(manifest):
             return manifest, d2
-    bb.error("Manifest %s not found in %s (variant '%s')?" % (manifest, d2.expand(" ".join(pkgarchs)), variant))
+    bb.fatal("Manifest %s not found in %s (variant '%s')?" % (manifest, d2.expand(" ".join(pkgarchs)), variant))
     return None, d2
 
 def OEOuthashBasic(path, sigfile, task, d):

meta/lib/oeqa/core/target/qemu.py

@@ -8,6 +8,8 @@ import os
 import sys
 import signal
 import time
+import glob
+import subprocess
 from collections import defaultdict
 
 from .ssh import OESSHTarget
@@ -36,6 +38,8 @@ class OEQemuTarget(OESSHTarget):
         self.ovmf = ovmf
         self.use_slirp = slirp
         self.boot_patterns = boot_patterns
+        self.dump_dir = dump_dir
+        self.bootlog = bootlog
 
         self.runner = QemuRunner(machine=machine, rootfs=rootfs, tmpdir=tmpdir,
                                  deploy_dir_image=dir_image, display=display,
@@ -74,7 +78,28 @@ class OEQemuTarget(OESSHTarget):
                 self.server_ip = self.runner.server_ip
         else:
             self.stop()
-            raise RuntimeError("FAILED to start qemu - check the task log and the boot log")
+            # Display the first 20 lines of top and
+            # last 20 lines of the bootlog when the
+            # target is not being booted up.
+            topfile = glob.glob(self.dump_dir + "/*_qemu/host_*_top")
+            msg = "\n\n===== start: snippet =====\n\n"
+            for f in topfile:
+                msg += "file: %s\n\n" % f
+                with open(f) as tf:
+                    for x in range(20):
+                        msg += next(tf)
+            msg += "\n\n===== end: snippet =====\n\n"
+            blcmd = ["tail", "-20", self.bootlog]
+            msg += "===== start: snippet =====\n\n"
+            try:
+                out = subprocess.check_output(blcmd, stderr=subprocess.STDOUT, timeout=1).decode('utf-8')
+                msg += "file: %s\n\n" % self.bootlog
+                msg += out
+            except (subprocess.CalledProcessError, subprocess.TimeoutExpired, FileNotFoundError) as err:
+                msg += "Error running command: %s\n%s\n" % (blcmd, err)
+            msg += "\n\n===== end: snippet =====\n"
+
+            raise RuntimeError("FAILED to start qemu - check the task log and the boot log %s" % (msg))
 
     def stop(self):
         self.runner.stop()

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

@@ -2348,7 +2348,7 @@
           "expected_results": ""
         },
         "3": {
-          "action": "Build 6 recipes example (core-image-sato, core-image-minimal, core-image-base, core-image-clutter) to name a few. ",
+          "action": "Build 6 recipes example (core-image-sato, core-image-minimal, core-image-base) to name a few. ",
           "expected_results": " All recipes are built correctly \n\n"
         },
         "4": {
@@ -2382,7 +2382,7 @@
           "expected_results": ""
         },
         "3": {
-          "action": "Build 6 recipes example (core-image-sato, core-image-minimal, core-image-base, core-image-clutter) to name a few. \n\n",
+          "action": "Build 6 recipes example (core-image-sato, core-image-minimal, core-image-base) to name a few. \n\n",
           "expected_results": "All recipes are built correctly \n\n"
         },
         "4": {
@@ -2420,7 +2420,7 @@
           "expected_results": ""
         },
         "3": {
-          "action": "Build 4 recipes example (core-image-sato, core-image-minimal, core-image-base, core-image-clutter) to name a few. \n\n",
+          "action": "Build 4 recipes example (core-image-sato, core-image-minimal, core-image-base) to name a few. \n\n",
           "expected_results": " All recipes are built correctly \n\n"
         },
         "4": {

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

@@ -141,13 +141,4 @@ class RpmInstallRemoveTest(OERuntimeTestCase):
 
         self.tc.target.run('rm -f %s' % self.dst)
 
-        # if using systemd this should ensure all entries are flushed to /var
-        status, output = self.target.run("journalctl --sync")
-        # Get the amount of entries in the log file
-        status, output = self.target.run(check_log_cmd)
-        msg = 'Failed to get the final size of the log file.'
-        self.assertEqual(0, status, msg=msg)
 
-        # Check that there's enough of them
-        self.assertGreaterEqual(int(output), 80,
-                                   'Cound not find sufficient amount of rpm entries in /var/log/messages, found {} entries'.format(output))

meta/lib/oeqa/selftest/cases/imagefeatures.py

@@ -68,18 +68,6 @@ class ImageFeatures(OESelftestTestCase):
                     self.assertEqual(status, 0, 'ssh to user tester failed with %s' % output)
 
 
-    def test_clutter_image_can_be_built(self):
-        """
-        Summary:     Check if clutter image can be built
-        Expected:    1. core-image-clutter can be built
-        Product:     oe-core
-        Author:      Ionut Chisanovici <ionutx.chisanovici@intel.com>
-        AutomatedBy: Daniel Istrate <daniel.alexandrux.istrate@intel.com>
-        """
-
-        # Build a core-image-clutter
-        bitbake('core-image-clutter')
-
     def test_wayland_support_in_image(self):
         """
         Summary:     Check Wayland support in image

meta/lib/oeqa/utils/qemurunner.py

@@ -65,7 +65,7 @@ class QemuRunner:
         self.boot_patterns = boot_patterns
         self.tmpfsdir = tmpfsdir
 
-        self.runqemutime = 120
+        self.runqemutime = 300
         if not workdir:
             workdir = os.getcwd()
         self.qemu_pidfile = workdir + '/pidfile_' + str(os.getpid())
@@ -277,14 +277,33 @@ class QemuRunner:
 
         if self.runqemu_exited:
             self.logger.warning("runqemu after timeout")
-            return False
 
         if self.runqemu.returncode:
             self.logger.warning('runqemu exited with code %d' % self.runqemu.returncode)
-            return False
 
         if not self.is_alive():
-            self.logger.warning('is_alive() failed later')
+            self.logger.error("Qemu pid didn't appear in %s seconds (%s)" %
+                              (self.runqemutime, time.strftime("%D %H:%M:%S")))
+
+            qemu_pid = None
+            if os.path.isfile(self.qemu_pidfile):
+                with open(self.qemu_pidfile, 'r') as f:
+                    qemu_pid = f.read().strip()
+
+            self.logger.error("Status information, poll status: %s, pidfile exists: %s, pidfile contents %s, proc pid exists %s"
+                % (self.runqemu.poll(), os.path.isfile(self.qemu_pidfile), str(qemu_pid), os.path.exists("/proc/" + str(qemu_pid))))
+
+            # Dump all processes to help us to figure out what is going on...
+            ps = subprocess.Popen(['ps', 'axww', '-o', 'pid,ppid,pri,ni,command '], stdout=subprocess.PIPE).communicate()[0]
+            processes = ps.decode("utf-8")
+            self.logger.debug("Running processes:\n%s" % processes)
+            self._dump_host()
+            op = self.getOutput(output)
+            self.stop()
+            if op:
+                self.logger.error("Output from runqemu:\n%s" % op)
+            else:
+                self.logger.error("No output from runqemu.\n")
             return False
 
         # Create the client socket for the QEMU Monitor Control Socket
@@ -323,34 +342,26 @@ class QemuRunner:
         finally:
             os.chdir(origpath)
 
-        # Release the qemu porcess to continue running
+        # We worry that mmap'd libraries may cause page faults which hang the qemu VM for periods
+        # causing failures. Before we "start" qemu, read through it's mapped files to try and 
+        # ensure we don't hit page faults later
+        mapdir = "/proc/" + str(self.qemupid) + "/map_files/"
+        try:
+            for f in os.listdir(mapdir):
+                linktarget = os.readlink(os.path.join(mapdir, f))
+                if not linktarget.startswith("/") or linktarget.startswith("/dev") or "deleted" in linktarget:
+                    continue
+                with open(linktarget, "rb") as readf:
+                    data = True
+                    while data:
+                        data = readf.read(4096)
+        # Centos7 doesn't allow us to read /map_files/
+        except PermissionError:
+            pass
+
+        # Release the qemu process to continue running
         self.run_monitor('cont')
 
-        if not self.is_alive():
-            self.logger.error("Qemu pid didn't appear in %s seconds (%s)" %
-                              (self.runqemutime, time.strftime("%D %H:%M:%S")))
-
-            qemu_pid = None
-            if os.path.isfile(self.qemu_pidfile):
-                with open(self.qemu_pidfile, 'r') as f:
-                    qemu_pid = f.read().strip()
-
-            self.logger.error("Status information, poll status: %s, pidfile exists: %s, pidfile contents %s, proc pid exists %s"
-                % (self.runqemu.poll(), os.path.isfile(self.qemu_pidfile), str(qemu_pid), os.path.exists("/proc/" + str(qemu_pid))))
-
-            # Dump all processes to help us to figure out what is going on...
-            ps = subprocess.Popen(['ps', 'axww', '-o', 'pid,ppid,pri,ni,command '], stdout=subprocess.PIPE).communicate()[0]
-            processes = ps.decode("utf-8")
-            self.logger.debug("Running processes:\n%s" % processes)
-            self._dump_host()
-            op = self.getOutput(output)
-            self.stop()
-            if op:
-                self.logger.error("Output from runqemu:\n%s" % op)
-            else:
-                self.logger.error("No output from runqemu.\n")
-            return False
-
         # We are alive: qemu is running
         out = self.getOutput(output)
         netconf = False # network configuration is not required by default

meta/recipes-bsp/grub/grub2.inc

@@ -34,6 +34,9 @@ CVE_CHECK_WHITELIST += "\
     CVE-2020-25632 CVE-2020-25647 CVE-2020-27749 CVE-2020-27779 \
     CVE-2021-3418 CVE-2021-20225 CVE-2021-20233"
 
+# Applies only to RHEL
+CVE_CHECK_WHITELIST += "CVE-2019-14865"
+
 S = "${WORKDIR}/grub-${REALPV}"
 
 UPSTREAM_CHECK_URI = "${GNU_MIRROR}/grub"

meta/recipes-bsp/opensbi/opensbi-payloads.inc

@@ -7,12 +7,25 @@ def riscv_get_extra_oemake_image(d):
 
     return "FW_PAYLOAD_PATH=" + deploy_dir + "/" + sbi_payload
 
+def riscv_get_extra_oemake_fdt(d):
+    sbi_fdt = d.getVar('RISCV_SBI_FDT')
+    deploy_dir = d.getVar('DEPLOY_DIR_IMAGE')
+
+    if sbi_fdt is None:
+        return ""
+
+    return "FW_FDT_PATH=" + deploy_dir + "/" + sbi_fdt
+
 def riscv_get_do_compile_depends(d):
     sbi_payload = d.getVar('RISCV_SBI_PAYLOAD')
+    sbi_fdt = d.getVar('RISCV_SBI_FDT')
 
-    if sbi_payload is None:
+    if sbi_payload is None and sbi_fdt is None:
         return ""
 
+    if sbi_fdt is not None and 'u-boot.bin' in sbi_payload:
+        return "virtual/kernel:do_deploy virtual/bootloader:do_deploy"
+
     if 'linux' in sbi_payload or 'Image' in sbi_payload:
         return "virtual/kernel:do_deploy"
     if 'u-boot.bin' in sbi_payload:

meta/recipes-bsp/opensbi/opensbi_0.9.bb

@@ -15,9 +15,10 @@ SRC_URI = "git://github.com/riscv/opensbi.git;branch=master \
 
 S = "${WORKDIR}/git"
 
-EXTRA_OEMAKE += "PLATFORM=${RISCV_SBI_PLAT} I=${D}"
+EXTRA_OEMAKE += "PLATFORM=${RISCV_SBI_PLAT} I=${D} FW_PIC=n"
 # If RISCV_SBI_PAYLOAD is set then include it as a payload
 EXTRA_OEMAKE_append = " ${@riscv_get_extra_oemake_image(d)}"
+EXTRA_OEMAKE_append = " ${@riscv_get_extra_oemake_fdt(d)}"
 
 # Required if specifying a custom payload
 do_compile[depends] += "${@riscv_get_do_compile_depends(d)}"

meta/recipes-bsp/u-boot/files/0001-add-valid-fdt-check.patch

@@ -1,36 +0,0 @@
-From ea1a9ec5f430359720d9a0621ed1acfbba6a142a Mon Sep 17 00:00:00 2001
-From: Heinrich Schuchardt <xypron.glpk@gmx.de>
-Date: Wed, 13 Jan 2021 02:09:12 +0100
-Subject: [PATCH] image-fit: fit_check_format check for valid FDT
-
-fit_check_format() must check that the buffer contains a flattened device
-tree before calling any device tree library functions.
-
-Failure to do may cause segmentation faults.
-
-Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
-
-Upstream-Status: Backport[https://github.com/u-boot/u-boot/commit/ea1a9ec5f430359720d9a0621ed1acfbba6a142a]
-Signed-off-by: Scott Murray <scott.murray@konsulko.com>
-
----
- common/image-fit.c | 6 ++++++
- 1 file changed, 6 insertions(+)
-
-diff --git a/common/image-fit.c b/common/image-fit.c
-index 6a8787ca0a..21c44bdf69 100644
---- a/common/image-fit.c
-+++ b/common/image-fit.c
-@@ -1553,6 +1553,12 @@ int fit_image_check_comp(const void *fit, int noffset, uint8_t comp)
-  */
- int fit_check_format(const void *fit)
- {
-+	/* A FIT image must be a valid FDT */
-+	if (fdt_check_header(fit)) {
-+		debug("Wrong FIT format: not a flattened device tree\n");
-+		return 0;
-+	}
-+
- 	/* mandatory / node 'description' property */
- 	if (fdt_getprop(fit, 0, FIT_DESC_PROP, NULL) == NULL) {
- 		debug("Wrong FIT format: no description\n");

meta/recipes-bsp/u-boot/files/CVE-2021-27097-1.patch

@@ -1,71 +0,0 @@
-From 8a7d4cf9820ea16fabd25a6379351b4dc291204b Mon Sep 17 00:00:00 2001
-From: Simon Glass <sjg@chromium.org>
-Date: Mon, 15 Feb 2021 17:08:05 -0700
-Subject: [PATCH] fdt_region: Check for a single root node of the correct name
-
-At present fdt_find_regions() assumes that the FIT is a valid devicetree.
-If the FIT has two root nodes this is currently not detected in this
-function, nor does libfdt's fdt_check_full() notice. Also it is possible
-for the root node to have a name even though it should not.
-
-Add checks for these and return -FDT_ERR_BADSTRUCTURE if a problem is
-detected.
-
-CVE-2021-27097
-
-Signed-off-by: Simon Glass <sjg@chromium.org>
-Reported-by: Bruce Monroe <bruce.monroe@intel.com>
-Reported-by: Arie Haenel <arie.haenel@intel.com>
-Reported-by: Julien Lenoir <julien.lenoir@intel.com>
-
-CVE: CVE-2021-27097
-Upstream-Status: Backport[https://github.com/u-boot/u-boot/commit/8a7d4cf9820ea16fabd25a6379351b4dc291204b]
-Signed-off-by: Scott Murray <scott.murray@konsulko.com>
-
----
- common/fdt_region.c | 11 +++++++++++
- 1 file changed, 11 insertions(+)
-
-diff --git a/common/fdt_region.c b/common/fdt_region.c
-index ff12c518e9..e4ef0ca770 100644
---- a/common/fdt_region.c
-+++ b/common/fdt_region.c
-@@ -43,6 +43,7 @@ int fdt_find_regions(const void *fdt, char * const inc[], int inc_count,
- 	int depth = -1;
- 	int want = 0;
- 	int base = fdt_off_dt_struct(fdt);
-+	bool expect_end = false;
- 
- 	end = path;
- 	*end = '\0';
-@@ -59,6 +60,10 @@ int fdt_find_regions(const void *fdt, char * const inc[], int inc_count,
- 		tag = fdt_next_tag(fdt, offset, &nextoffset);
- 		stop_at = nextoffset;
- 
-+		/* If we see two root nodes, something is wrong */
-+		if (expect_end && tag != FDT_END)
-+			return -FDT_ERR_BADLAYOUT;
-+
- 		switch (tag) {
- 		case FDT_PROP:
- 			include = want >= 2;
-@@ -81,6 +86,10 @@ int fdt_find_regions(const void *fdt, char * const inc[], int inc_count,
- 			if (depth == FDT_MAX_DEPTH)
- 				return -FDT_ERR_BADSTRUCTURE;
- 			name = fdt_get_name(fdt, offset, &len);
-+
-+			/* The root node must have an empty name */
-+			if (!depth && *name)
-+				return -FDT_ERR_BADLAYOUT;
- 			if (end - path + 2 + len >= path_len)
- 				return -FDT_ERR_NOSPACE;
- 			if (end != path + 1)
-@@ -108,6 +117,8 @@ int fdt_find_regions(const void *fdt, char * const inc[], int inc_count,
- 			while (end > path && *--end != '/')
- 				;
- 			*end = '\0';
-+			if (depth == -1)
-+				expect_end = true;
- 			break;
- 
- 		case FDT_END:

meta/recipes-bsp/u-boot/files/CVE-2021-27097-2.patch

@@ -1,419 +0,0 @@
-From c5819701a3de61e2ba2ef7ad0b616565b32305e5 Mon Sep 17 00:00:00 2001
-From: Simon Glass <sjg@chromium.org>
-Date: Mon, 15 Feb 2021 17:08:09 -0700
-Subject: [PATCH] image: Adjust the workings of fit_check_format()
-
-At present this function does not accept a size for the FIT. This means
-that it must be read from the FIT itself, introducing potential security
-risk. Update the function to include a size parameter, which can be
-invalid, in which case fit_check_format() calculates it.
-
-For now no callers pass the size, but this can be updated later.
-
-Also adjust the return value to an error code so that all the different
-types of problems can be distinguished by the user.
-
-Signed-off-by: Simon Glass <sjg@chromium.org>
-Reported-by: Bruce Monroe <bruce.monroe@intel.com>
-Reported-by: Arie Haenel <arie.haenel@intel.com>
-Reported-by: Julien Lenoir <julien.lenoir@intel.com>
-
-CVE: CVE-2021-27097 CVE-2021-27138
-Upstream-Status: Backport[https://github.com/u-boot/u-boot/commit/c5819701a3de61e2ba2ef7ad0b616565b32305e5]
-Signed-off-by: Scott Murray <scott.murray@konsulko.com>
-
----
- arch/arm/cpu/armv8/sec_firmware.c  |  2 +-
- cmd/bootm.c                        |  6 ++---
- cmd/disk.c                         |  2 +-
- cmd/fpga.c                         |  2 +-
- cmd/nand.c                         |  2 +-
- cmd/source.c                       |  2 +-
- cmd/ximg.c                         |  2 +-
- common/image-fdt.c                 |  2 +-
- common/image-fit.c                 | 46 +++++++++++++++++---------------------
- common/splash_source.c             |  6 ++---
- common/update.c                    |  4 ++--
- drivers/fpga/socfpga_arria10.c     |  6 ++---
- drivers/net/fsl-mc/mc.c            |  2 +-
- drivers/net/pfe_eth/pfe_firmware.c |  2 +-
- include/image.h                    | 21 ++++++++++++++++-
- tools/fit_common.c                 |  3 ++-
- tools/fit_image.c                  |  2 +-
- tools/mkimage.h                    |  2 ++
- 18 files changed, 65 insertions(+), 49 deletions(-)
-
-diff --git a/arch/arm/cpu/armv8/sec_firmware.c b/arch/arm/cpu/armv8/sec_firmware.c
-index bfc0fac3ef..0561f5efd1 100644
---- a/arch/arm/cpu/armv8/sec_firmware.c
-+++ b/arch/arm/cpu/armv8/sec_firmware.c
-@@ -316,7 +316,7 @@ __weak bool sec_firmware_is_valid(const void *sec_firmware_img)
- 		return false;
- 	}
- 
--	if (!fit_check_format(sec_firmware_img)) {
-+	if (fit_check_format(sec_firmware_img, IMAGE_SIZE_INVAL)) {
- 		printf("SEC Firmware: Bad firmware image (bad FIT header)\n");
- 		return false;
- 	}
-diff --git a/cmd/bootm.c b/cmd/bootm.c
-index e6b0e04413..a0f823f968 100644
---- a/cmd/bootm.c
-+++ b/cmd/bootm.c
-@@ -291,7 +291,7 @@ static int image_info(ulong addr)
- 	case IMAGE_FORMAT_FIT:
- 		puts("   FIT image found\n");
- 
--		if (!fit_check_format(hdr)) {
-+		if (fit_check_format(hdr, IMAGE_SIZE_INVAL)) {
- 			puts("Bad FIT image format!\n");
- 			unmap_sysmem(hdr);
- 			return 1;
-@@ -368,7 +368,7 @@ static int do_imls_nor(void)
- #endif
- #if defined(CONFIG_FIT)
- 			case IMAGE_FORMAT_FIT:
--				if (!fit_check_format(hdr))
-+				if (fit_check_format(hdr, IMAGE_SIZE_INVAL))
- 					goto next_sector;
- 
- 				printf("FIT Image at %08lX:\n", (ulong)hdr);
-@@ -448,7 +448,7 @@ static int nand_imls_fitimage(struct mtd_info *mtd, int nand_dev, loff_t off,
- 		return ret;
- 	}
- 
--	if (!fit_check_format(imgdata)) {
-+	if (fit_check_format(imgdata, IMAGE_SIZE_INVAL)) {
- 		free(imgdata);
- 		return 0;
- 	}
-diff --git a/cmd/disk.c b/cmd/disk.c
-index 8060e753eb..3195db9127 100644
---- a/cmd/disk.c
-+++ b/cmd/disk.c
-@@ -114,7 +114,7 @@ int common_diskboot(struct cmd_tbl *cmdtp, const char *intf, int argc,
- 	/* This cannot be done earlier,
- 	 * we need complete FIT image in RAM first */
- 	if (genimg_get_format((void *) addr) == IMAGE_FORMAT_FIT) {
--		if (!fit_check_format(fit_hdr)) {
-+		if (fit_check_format(fit_hdr, IMAGE_SIZE_INVAL)) {
- 			bootstage_error(BOOTSTAGE_ID_IDE_FIT_READ);
- 			puts("** Bad FIT image format\n");
- 			return 1;
-diff --git a/cmd/fpga.c b/cmd/fpga.c
-index 8ae1c936fb..51410a8e42 100644
---- a/cmd/fpga.c
-+++ b/cmd/fpga.c
-@@ -330,7 +330,7 @@ static int do_fpga_loadmk(struct cmd_tbl *cmdtp, int flag, int argc,
- 			return CMD_RET_FAILURE;
- 		}
- 
--		if (!fit_check_format(fit_hdr)) {
-+		if (fit_check_format(fit_hdr, IMAGE_SIZE_INVAL)) {
- 			puts("Bad FIT image format\n");
- 			return CMD_RET_FAILURE;
- 		}
-diff --git a/cmd/nand.c b/cmd/nand.c
-index 92d039af8f..97e117a979 100644
---- a/cmd/nand.c
-+++ b/cmd/nand.c
-@@ -917,7 +917,7 @@ static int nand_load_image(struct cmd_tbl *cmdtp, struct mtd_info *mtd,
- #if defined(CONFIG_FIT)
- 	/* This cannot be done earlier, we need complete FIT image in RAM first */
- 	if (genimg_get_format ((void *)addr) == IMAGE_FORMAT_FIT) {
--		if (!fit_check_format (fit_hdr)) {
-+		if (fit_check_format(fit_hdr, IMAGE_SIZE_INVAL)) {
- 			bootstage_error(BOOTSTAGE_ID_NAND_FIT_READ);
- 			puts ("** Bad FIT image format\n");
- 			return 1;
-diff --git a/cmd/source.c b/cmd/source.c
-index b6c709a3d2..71f71528ad 100644
---- a/cmd/source.c
-+++ b/cmd/source.c
-@@ -107,7 +107,7 @@ int image_source_script(ulong addr, const char *fit_uname)
- #if defined(CONFIG_FIT)
- 	case IMAGE_FORMAT_FIT:
- 		fit_hdr = buf;
--		if (!fit_check_format (fit_hdr)) {
-+		if (fit_check_format(fit_hdr, IMAGE_SIZE_INVAL)) {
- 			puts ("Bad FIT image format\n");
- 			return 1;
- 		}
-diff --git a/cmd/ximg.c b/cmd/ximg.c
-index 159ba51648..ef738ebfa2 100644
---- a/cmd/ximg.c
-+++ b/cmd/ximg.c
-@@ -136,7 +136,7 @@ do_imgextract(struct cmd_tbl *cmdtp, int flag, int argc, char *const argv[])
- 			"at %08lx ...\n", uname, addr);
- 
- 		fit_hdr = (const void *)addr;
--		if (!fit_check_format(fit_hdr)) {
-+		if (fit_check_format(fit_hdr, IMAGE_SIZE_INVAL)) {
- 			puts("Bad FIT image format\n");
- 			return 1;
- 		}
-diff --git a/common/image-fdt.c b/common/image-fdt.c
-index 327a8c4c39..4105259212 100644
---- a/common/image-fdt.c
-+++ b/common/image-fdt.c
-@@ -399,7 +399,7 @@ int boot_get_fdt(int flag, int argc, char *const argv[], uint8_t arch,
- 			 */
- #if CONFIG_IS_ENABLED(FIT)
- 			/* check FDT blob vs FIT blob */
--			if (fit_check_format(buf)) {
-+			if (!fit_check_format(buf, IMAGE_SIZE_INVAL)) {
- 				ulong load, len;
- 
- 				fdt_noffset = boot_get_fdt_fit(images,
-diff --git a/common/image-fit.c b/common/image-fit.c
-index 9637d747fb..402f08fc9d 100644
---- a/common/image-fit.c
-+++ b/common/image-fit.c
-@@ -8,6 +8,8 @@
-  * Wolfgang Denk, DENX Software Engineering, wd@denx.de.
-  */
- 
-+#define LOG_CATEGORY LOGC_BOOT
-+
- #ifdef USE_HOSTCC
- #include "mkimage.h"
- #include <time.h>
-@@ -1550,49 +1552,41 @@ int fit_image_check_comp(const void *fit, int noffset, uint8_t comp)
- 	return (comp == image_comp);
- }
- 
--/**
-- * fit_check_format - sanity check FIT image format
-- * @fit: pointer to the FIT format image header
-- *
-- * fit_check_format() runs a basic sanity FIT image verification.
-- * Routine checks for mandatory properties, nodes, etc.
-- *
-- * returns:
-- *     1, on success
-- *     0, on failure
-- */
--int fit_check_format(const void *fit)
-+int fit_check_format(const void *fit, ulong size)
- {
-+	int ret;
-+
- 	/* A FIT image must be a valid FDT */
--	if (fdt_check_header(fit)) {
--		debug("Wrong FIT format: not a flattened device tree\n");
--		return 0;
-+	ret = fdt_check_header(fit);
-+	if (ret) {
-+		log_debug("Wrong FIT format: not a flattened device tree (err=%d)\n",
-+			  ret);
-+		return -ENOEXEC;
- 	}
- 
- 	/* mandatory / node 'description' property */
--	if (fdt_getprop(fit, 0, FIT_DESC_PROP, NULL) == NULL) {
--		debug("Wrong FIT format: no description\n");
--		return 0;
-+	if (!fdt_getprop(fit, 0, FIT_DESC_PROP, NULL)) {
-+		log_debug("Wrong FIT format: no description\n");
-+		return -ENOMSG;
- 	}
- 
- 	if (IMAGE_ENABLE_TIMESTAMP) {
- 		/* mandatory / node 'timestamp' property */
--		if (fdt_getprop(fit, 0, FIT_TIMESTAMP_PROP, NULL) == NULL) {
--			debug("Wrong FIT format: no timestamp\n");
--			return 0;
-+		if (!fdt_getprop(fit, 0, FIT_TIMESTAMP_PROP, NULL)) {
-+			log_debug("Wrong FIT format: no timestamp\n");
-+			return -ENODATA;
- 		}
- 	}
- 
- 	/* mandatory subimages parent '/images' node */
- 	if (fdt_path_offset(fit, FIT_IMAGES_PATH) < 0) {
--		debug("Wrong FIT format: no images parent node\n");
--		return 0;
-+		log_debug("Wrong FIT format: no images parent node\n");
-+		return -ENOENT;
- 	}
- 
--	return 1;
-+	return 0;
- }
- 
--
- /**
-  * fit_conf_find_compat
-  * @fit: pointer to the FIT format image header
-@@ -1929,7 +1923,7 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
- 	printf("## Loading %s from FIT Image at %08lx ...\n", prop_name, addr);
- 
- 	bootstage_mark(bootstage_id + BOOTSTAGE_SUB_FORMAT);
--	if (!fit_check_format(fit)) {
-+	if (fit_check_format(fit, IMAGE_SIZE_INVAL)) {
- 		printf("Bad FIT %s image format!\n", prop_name);
- 		bootstage_error(bootstage_id + BOOTSTAGE_SUB_FORMAT);
- 		return -ENOEXEC;
-diff --git a/common/splash_source.c b/common/splash_source.c
-index f51ca5ddf3..bad9a7790a 100644
---- a/common/splash_source.c
-+++ b/common/splash_source.c
-@@ -336,10 +336,10 @@ static int splash_load_fit(struct splash_location *location, u32 bmp_load_addr)
- 	if (res < 0)
- 		return res;
- 
--	res = fit_check_format(fit_header);
--	if (!res) {
-+	res = fit_check_format(fit_header, IMAGE_SIZE_INVAL);
-+	if (res) {
- 		debug("Could not find valid FIT image\n");
--		return -EINVAL;
-+		return res;
- 	}
- 
- 	/* Get the splash image node */
-diff --git a/common/update.c b/common/update.c
-index a5879cb52c..f0848954e5 100644
---- a/common/update.c
-+++ b/common/update.c
-@@ -286,7 +286,7 @@ int update_tftp(ulong addr, char *interface, char *devstring)
- got_update_file:
- 	fit = map_sysmem(addr, 0);
- 
--	if (!fit_check_format((void *)fit)) {
-+	if (fit_check_format((void *)fit, IMAGE_SIZE_INVAL)) {
- 		printf("Bad FIT format of the update file, aborting "
- 							"auto-update\n");
- 		return 1;
-@@ -363,7 +363,7 @@ int fit_update(const void *fit)
- 	if (!fit)
- 		return -EINVAL;
- 
--	if (!fit_check_format((void *)fit)) {
-+	if (fit_check_format((void *)fit, IMAGE_SIZE_INVAL)) {
- 		printf("Bad FIT format of the update file, aborting auto-update\n");
- 		return -EINVAL;
- 	}
-diff --git a/drivers/fpga/socfpga_arria10.c b/drivers/fpga/socfpga_arria10.c
-index 44e1ac54c3..18f99676d2 100644
---- a/drivers/fpga/socfpga_arria10.c
-+++ b/drivers/fpga/socfpga_arria10.c
-@@ -565,10 +565,10 @@ static int first_loading_rbf_to_buffer(struct udevice *dev,
- 	if (ret < 0)
- 		return ret;
- 
--	ret = fit_check_format(buffer_p);
--	if (!ret) {
-+	ret = fit_check_format(buffer_p, IMAGE_SIZE_INVAL);
-+	if (ret) {
- 		debug("FPGA: No valid FIT image was found.\n");
--		return -EBADF;
-+		return ret;
- 	}
- 
- 	confs_noffset = fdt_path_offset(buffer_p, FIT_CONFS_PATH);
-diff --git a/drivers/net/fsl-mc/mc.c b/drivers/net/fsl-mc/mc.c
-index 84db6be624..81265ee356 100644
---- a/drivers/net/fsl-mc/mc.c
-+++ b/drivers/net/fsl-mc/mc.c
-@@ -141,7 +141,7 @@ int parse_mc_firmware_fit_image(u64 mc_fw_addr,
- 		return -EINVAL;
- 	}
- 
--	if (!fit_check_format(fit_hdr)) {
-+	if (fit_check_format(fit_hdr, IMAGE_SIZE_INVAL)) {
- 		printf("fsl-mc: ERR: Bad firmware image (bad FIT header)\n");
- 		return -EINVAL;
- 	}
-diff --git a/drivers/net/pfe_eth/pfe_firmware.c b/drivers/net/pfe_eth/pfe_firmware.c
-index 41999e176d..eee70a2e73 100644
---- a/drivers/net/pfe_eth/pfe_firmware.c
-+++ b/drivers/net/pfe_eth/pfe_firmware.c
-@@ -160,7 +160,7 @@ static int pfe_fit_check(void)
- 		return ret;
- 	}
- 
--	if (!fit_check_format(pfe_fit_addr)) {
-+	if (fit_check_format(pfe_fit_addr, IMAGE_SIZE_INVAL)) {
- 		printf("PFE Firmware: Bad firmware image (bad FIT header)\n");
- 		ret = -1;
- 		return ret;
-diff --git a/include/image.h b/include/image.h
-index 41473dbb9c..8c152c5c5f 100644
---- a/include/image.h
-+++ b/include/image.h
-@@ -134,6 +134,9 @@ extern ulong image_load_addr;		/* Default Load Address */
- extern ulong image_save_addr;		/* Default Save Address */
- extern ulong image_save_size;		/* Default Save Size */
- 
-+/* An invalid size, meaning that the image size is not known */
-+#define IMAGE_SIZE_INVAL	(-1UL)
-+
- enum ih_category {
- 	IH_ARCH,
- 	IH_COMP,
-@@ -1141,7 +1144,23 @@ int fit_image_check_os(const void *fit, int noffset, uint8_t os);
- int fit_image_check_arch(const void *fit, int noffset, uint8_t arch);
- int fit_image_check_type(const void *fit, int noffset, uint8_t type);
- int fit_image_check_comp(const void *fit, int noffset, uint8_t comp);
--int fit_check_format(const void *fit);
-+
-+/**
-+ * fit_check_format() - Check that the FIT is valid
-+ *
-+ * This performs various checks on the FIT to make sure it is suitable for
-+ * use, looking for mandatory properties, nodes, etc.
-+ *
-+ * If FIT_FULL_CHECK is enabled, it also runs it through libfdt to make
-+ * sure that there are no strange tags or broken nodes in the FIT.
-+ *
-+ * @fit: pointer to the FIT format image header
-+ * @return 0 if OK, -ENOEXEC if not an FDT file, -EINVAL if the full FDT check
-+ *	failed (e.g. due to bad structure), -ENOMSG if the description is
-+ *	missing, -ENODATA if the timestamp is missing, -ENOENT if the /images
-+ *	path is missing
-+ */
-+int fit_check_format(const void *fit, ulong size);
- 
- int fit_conf_find_compat(const void *fit, const void *fdt);
- 
-diff --git a/tools/fit_common.c b/tools/fit_common.c
-index cdf987d3c1..52b63296f8 100644
---- a/tools/fit_common.c
-+++ b/tools/fit_common.c
-@@ -26,7 +26,8 @@
- int fit_verify_header(unsigned char *ptr, int image_size,
- 			struct image_tool_params *params)
- {
--	if (fdt_check_header(ptr) != EXIT_SUCCESS || !fit_check_format(ptr))
-+	if (fdt_check_header(ptr) != EXIT_SUCCESS ||
-+	    fit_check_format(ptr, IMAGE_SIZE_INVAL))
- 		return EXIT_FAILURE;
- 
- 	return EXIT_SUCCESS;
-diff --git a/tools/fit_image.c b/tools/fit_image.c
-index 06faeda7c2..d440d143c6 100644
---- a/tools/fit_image.c
-+++ b/tools/fit_image.c
-@@ -883,7 +883,7 @@ static int fit_extract_contents(void *ptr, struct image_tool_params *params)
- 	/* Indent string is defined in header image.h */
- 	p = IMAGE_INDENT_STRING;
- 
--	if (!fit_check_format(fit)) {
-+	if (fit_check_format(fit, IMAGE_SIZE_INVAL)) {
- 		printf("Bad FIT image format\n");
- 		return -1;
- 	}
-diff --git a/tools/mkimage.h b/tools/mkimage.h
-index 5b096a545b..0d3148444c 100644
---- a/tools/mkimage.h
-+++ b/tools/mkimage.h
-@@ -29,6 +29,8 @@
- #define debug(fmt,args...)
- #endif /* MKIMAGE_DEBUG */
- 
-+#define log_debug(fmt, args...)	debug(fmt, ##args)
-+
- static inline void *map_sysmem(ulong paddr, unsigned long len)
- {
- 	return (void *)(uintptr_t)paddr;

meta/recipes-bsp/u-boot/files/CVE-2021-27097-3.patch

@@ -1,105 +0,0 @@
-From 6f3c2d8aa5e6cbd80b5e869bbbddecb66c329d01 Mon Sep 17 00:00:00 2001
-From: Simon Glass <sjg@chromium.org>
-Date: Mon, 15 Feb 2021 17:08:10 -0700
-Subject: [PATCH] image: Add an option to do a full check of the FIT
-
-Some strange modifications of the FIT can introduce security risks. Add an
-option to check it thoroughly, using libfdt's fdt_check_full() function.
-
-Enable this by default if signature verification is enabled.
-
-CVE-2021-27097
-
-Signed-off-by: Simon Glass <sjg@chromium.org>
-Reported-by: Bruce Monroe <bruce.monroe@intel.com>
-Reported-by: Arie Haenel <arie.haenel@intel.com>
-Reported-by: Julien Lenoir <julien.lenoir@intel.com>
-
-CVE: CVE-2021-27097
-Upstream-Status: Backport[https://github.com/u-boot/u-boot/commit/6f3c2d8aa5e6cbd80b5e869bbbddecb66c329d01]
-Signed-off-by: Scott Murray <scott.murray@konsulko.com>
-
----
- common/Kconfig.boot | 20 ++++++++++++++++++++
- common/image-fit.c  | 16 ++++++++++++++++
- 2 files changed, 36 insertions(+)
-
-diff --git a/common/Kconfig.boot b/common/Kconfig.boot
-index 5eaabdfc27..7532e55edb 100644
---- a/common/Kconfig.boot
-+++ b/common/Kconfig.boot
-@@ -63,6 +63,15 @@ config FIT_ENABLE_SHA512_SUPPORT
- 	  SHA512 checksum is a 512-bit (64-byte) hash value used to check that
- 	  the image contents have not been corrupted.
- 
-+config FIT_FULL_CHECK
-+	bool "Do a full check of the FIT before using it"
-+	default y
-+	help
-+	  Enable this do a full check of the FIT to make sure it is valid. This
-+	  helps to protect against carefully crafted FITs which take advantage
-+	  of bugs or omissions in the code. This includes a bad structure,
-+	  multiple root nodes and the like.
-+
- config FIT_SIGNATURE
- 	bool "Enable signature verification of FIT uImages"
- 	depends on DM
-@@ -70,6 +79,7 @@ config FIT_SIGNATURE
- 	select RSA
- 	select RSA_VERIFY
- 	select IMAGE_SIGN_INFO
-+	select FIT_FULL_CHECK
- 	help
- 	  This option enables signature verification of FIT uImages,
- 	  using a hash signed and verified using RSA. If
-@@ -159,6 +169,15 @@ config SPL_FIT_PRINT
- 	help
- 	  Support printing the content of the fitImage in a verbose manner in SPL.
- 
-+config SPL_FIT_FULL_CHECK
-+	bool "Do a full check of the FIT before using it"
-+	help
-+	  Enable this do a full check of the FIT to make sure it is valid. This
-+	  helps to protect against carefully crafted FITs which take advantage
-+	  of bugs or omissions in the code. This includes a bad structure,
-+	  multiple root nodes and the like.
-+
-+
- config SPL_FIT_SIGNATURE
- 	bool "Enable signature verification of FIT firmware within SPL"
- 	depends on SPL_DM
-@@ -168,6 +187,7 @@ config SPL_FIT_SIGNATURE
- 	select SPL_RSA
- 	select SPL_RSA_VERIFY
- 	select SPL_IMAGE_SIGN_INFO
-+	select SPL_FIT_FULL_CHECK
- 
- config SPL_LOAD_FIT
- 	bool "Enable SPL loading U-Boot as a FIT (basic fitImage features)"
-diff --git a/common/image-fit.c b/common/image-fit.c
-index f6c0428a96..bcf395f6a1 100644
---- a/common/image-fit.c
-+++ b/common/image-fit.c
-@@ -1580,6 +1580,22 @@ int fit_check_format(const void *fit, ulong size)
- 		return -ENOEXEC;
- 	}
- 
-+	if (CONFIG_IS_ENABLED(FIT_FULL_CHECK)) {
-+		/*
-+		 * If we are not given the size, make do wtih calculating it.
-+		 * This is not as secure, so we should consider a flag to
-+		 * control this.
-+		 */
-+		if (size == IMAGE_SIZE_INVAL)
-+			size = fdt_totalsize(fit);
-+		ret = fdt_check_full(fit, size);
-+
-+		if (ret) {
-+			log_debug("FIT check error %d\n", ret);
-+			return -EINVAL;
-+		}
-+	}
-+
- 	/* mandatory / node 'description' property */
- 	if (!fdt_getprop(fit, 0, FIT_DESC_PROP, NULL)) {
- 		log_debug("Wrong FIT format: no description\n");

meta/recipes-bsp/u-boot/files/CVE-2021-27097-4.patch

@@ -1,73 +0,0 @@
-From 124c255731c76a2b09587378b2bcce561bcd3f2d Mon Sep 17 00:00:00 2001
-From: Simon Glass <sjg@chromium.org>
-Date: Mon, 15 Feb 2021 17:08:11 -0700
-Subject: [PATCH] libfdt: Check for multiple/invalid root nodes
-
-It is possible to construct a devicetree blob with multiple root nodes.
-Update fdt_check_full() to check for this, along with a root node with an
-invalid name.
-
-CVE-2021-27097
-
-Signed-off-by: Simon Glass <sjg@chromium.org>
-Reported-by: Bruce Monroe <bruce.monroe@intel.com>
-Reported-by: Arie Haenel <arie.haenel@intel.com>
-Reported-by: Julien Lenoir <julien.lenoir@intel.com>
-
-CVE: CVE-2021-27097
-Upstream-Status: Backport[https://github.com/u-boot/u-boot/commit/124c255731c76a2b09587378b2bcce561bcd3f2d]
-Signed-off-by: Scott Murray <scott.murray@konsulko.com>
-
----
- scripts/dtc/libfdt/fdt_ro.c | 17 +++++++++++++++++
- test/py/tests/test_vboot.py |  3 ++-
- 2 files changed, 19 insertions(+), 1 deletion(-)
-
-diff --git a/scripts/dtc/libfdt/fdt_ro.c b/scripts/dtc/libfdt/fdt_ro.c
-index d984bab036..efe7efe921 100644
---- a/scripts/dtc/libfdt/fdt_ro.c
-+++ b/scripts/dtc/libfdt/fdt_ro.c
-@@ -867,6 +867,7 @@ int fdt_check_full(const void *fdt, size_t bufsize)
- 	unsigned depth = 0;
- 	const void *prop;
- 	const char *propname;
-+	bool expect_end = false;
- 
- 	if (bufsize < FDT_V1_SIZE)
- 		return -FDT_ERR_TRUNCATED;
-@@ -887,6 +888,10 @@ int fdt_check_full(const void *fdt, size_t bufsize)
- 		if (nextoffset < 0)
- 			return nextoffset;
- 
-+		/* If we see two root nodes, something is wrong */
-+		if (expect_end && tag != FDT_END)
-+			return -FDT_ERR_BADLAYOUT;
-+
- 		switch (tag) {
- 		case FDT_NOP:
- 			break;
-@@ -900,12 +905,24 @@ int fdt_check_full(const void *fdt, size_t bufsize)
- 			depth++;
- 			if (depth > INT_MAX)
- 				return -FDT_ERR_BADSTRUCTURE;
-+
-+			/* The root node must have an empty name */
-+			if (depth == 1) {
-+				const char *name;
-+				int len;
-+
-+				name = fdt_get_name(fdt, offset, &len);
-+				if (*name || len)
-+					return -FDT_ERR_BADLAYOUT;
-+			}
- 			break;
- 
- 		case FDT_END_NODE:
- 			if (depth == 0)
- 				return -FDT_ERR_BADSTRUCTURE;
- 			depth--;
-+			if (depth == 0)
-+				expect_end = true;
- 			break;
- 
- 		case FDT_PROP:

meta/recipes-bsp/u-boot/files/CVE-2021-27138-1.patch

@@ -1,245 +0,0 @@
-From 79af75f7776fc20b0d7eb6afe1e27c00fdb4b9b4 Mon Sep 17 00:00:00 2001
-From: Simon Glass <sjg@chromium.org>
-Date: Mon, 15 Feb 2021 17:08:06 -0700
-Subject: [PATCH] fit: Don't allow verification of images with @ nodes
-
-When searching for a node called 'fred', any unit address appended to the
-name is ignored by libfdt, meaning that 'fred' can match 'fred@1'. This
-means that we cannot be sure that the node originally intended is the one
-that is used.
-
-Disallow use of nodes with unit addresses.
-
-Update the forge test also, since it uses @ addresses.
-
-CVE-2021-27138
-
-Signed-off-by: Simon Glass <sjg@chromium.org>
-Reported-by: Bruce Monroe <bruce.monroe@intel.com>
-Reported-by: Arie Haenel <arie.haenel@intel.com>
-Reported-by: Julien Lenoir <julien.lenoir@intel.com>
-
-CVE: CVE-2021-27138
-Upstream-Status: Backport[https://github.com/u-boot/u-boot/commit/79af75f7776fc20b0d7eb6afe1e27c00fdb4b9b4]
-Signed-off-by: Scott Murray <scott.murray@konsulko.com>
-
----
- common/image-fit-sig.c       | 22 ++++++++++++++++++++--
- common/image-fit.c           | 20 +++++++++++++++-----
- test/py/tests/test_fit.py    | 24 ++++++++++++------------
- test/py/tests/vboot_forge.py | 12 ++++++------
- 4 files changed, 53 insertions(+), 25 deletions(-)
-
-diff --git a/common/image-fit-sig.c b/common/image-fit-sig.c
-index 897e04c7a3..34ebb8edfe 100644
---- a/common/image-fit-sig.c
-+++ b/common/image-fit-sig.c
-@@ -149,6 +149,14 @@ static int fit_image_verify_sig(const void *fit, int image_noffset,
- 	fdt_for_each_subnode(noffset, fit, image_noffset) {
- 		const char *name = fit_get_name(fit, noffset, NULL);
- 
-+		/*
-+		 * We don't support this since libfdt considers names with the
-+		 * name root but different @ suffix to be equal
-+		 */
-+		if (strchr(name, '@')) {
-+			err_msg = "Node name contains @";
-+			goto error;
-+		}
- 		if (!strncmp(name, FIT_SIG_NODENAME,
- 			     strlen(FIT_SIG_NODENAME))) {
- 			ret = fit_image_check_sig(fit, noffset, data,
-@@ -398,9 +406,10 @@ error:
- 	return -EPERM;
- }
- 
--int fit_config_verify_required_sigs(const void *fit, int conf_noffset,
--				    const void *sig_blob)
-+static int fit_config_verify_required_sigs(const void *fit, int conf_noffset,
-+					   const void *sig_blob)
- {
-+	const char *name = fit_get_name(fit, conf_noffset, NULL);
- 	int noffset;
- 	int sig_node;
- 	int verified = 0;
-@@ -408,6 +417,15 @@ int fit_config_verify_required_sigs(const void *fit, int conf_noffset,
- 	bool reqd_policy_all = true;
- 	const char *reqd_mode;
- 
-+	/*
-+	 * We don't support this since libfdt considers names with the
-+	 * name root but different @ suffix to be equal
-+	 */
-+	if (strchr(name, '@')) {
-+		printf("Configuration node '%s' contains '@'\n", name);
-+		return -EPERM;
-+	}
-+
- 	/* Work out what we need to verify */
- 	sig_node = fdt_subnode_offset(sig_blob, 0, FIT_SIG_NODENAME);
- 	if (sig_node < 0) {
-diff --git a/common/image-fit.c b/common/image-fit.c
-index adc3e551de..c3dc814115 100644
---- a/common/image-fit.c
-+++ b/common/image-fit.c
-@@ -1369,21 +1369,31 @@ error:
-  */
- int fit_image_verify(const void *fit, int image_noffset)
- {
-+	const char *name = fit_get_name(fit, image_noffset, NULL);
- 	const void	*data;
- 	size_t		size;
--	int		noffset = 0;
- 	char		*err_msg = "";
- 
-+	if (strchr(name, '@')) {
-+		/*
-+		 * We don't support this since libfdt considers names with the
-+		 * name root but different @ suffix to be equal
-+		 */
-+		err_msg = "Node name contains @";
-+		goto err;
-+	}
- 	/* Get image data and data length */
- 	if (fit_image_get_data_and_size(fit, image_noffset, &data, &size)) {
- 		err_msg = "Can't get image data/size";
--		printf("error!\n%s for '%s' hash node in '%s' image node\n",
--		       err_msg, fit_get_name(fit, noffset, NULL),
--		       fit_get_name(fit, image_noffset, NULL));
--		return 0;
-+		goto err;
- 	}
- 
- 	return fit_image_verify_with_data(fit, image_noffset, data, size);
-+
-+err:
-+	printf("error!\n%s in '%s' image node\n", err_msg,
-+	       fit_get_name(fit, image_noffset, NULL));
-+	return 0;
- }
- 
- /**
-diff --git a/test/py/tests/test_fit.py b/test/py/tests/test_fit.py
-index 84b3f95850..6d5b43c3ba 100755
---- a/test/py/tests/test_fit.py
-+++ b/test/py/tests/test_fit.py
-@@ -17,7 +17,7 @@ base_its = '''
-         #address-cells = <1>;
- 
-         images {
--                kernel@1 {
-+                kernel-1 {
-                         data = /incbin/("%(kernel)s");
-                         type = "kernel";
-                         arch = "sandbox";
-@@ -26,7 +26,7 @@ base_its = '''
-                         load = <0x40000>;
-                         entry = <0x8>;
-                 };
--                kernel@2 {
-+                kernel-2 {
-                         data = /incbin/("%(loadables1)s");
-                         type = "kernel";
-                         arch = "sandbox";
-@@ -35,19 +35,19 @@ base_its = '''
-                         %(loadables1_load)s
-                         entry = <0x0>;
-                 };
--                fdt@1 {
-+                fdt-1 {
-                         description = "snow";
-                         data = /incbin/("%(fdt)s");
-                         type = "flat_dt";
-                         arch = "sandbox";
-                         %(fdt_load)s
-                         compression = "%(compression)s";
--                        signature@1 {
-+                        signature-1 {
-                                 algo = "sha1,rsa2048";
-                                 key-name-hint = "dev";
-                         };
-                 };
--                ramdisk@1 {
-+                ramdisk-1 {
-                         description = "snow";
-                         data = /incbin/("%(ramdisk)s");
-                         type = "ramdisk";
-@@ -56,7 +56,7 @@ base_its = '''
-                         %(ramdisk_load)s
-                         compression = "%(compression)s";
-                 };
--                ramdisk@2 {
-+                ramdisk-2 {
-                         description = "snow";
-                         data = /incbin/("%(loadables2)s");
-                         type = "ramdisk";
-@@ -67,10 +67,10 @@ base_its = '''
-                 };
-         };
-         configurations {
--                default = "conf@1";
--                conf@1 {
--                        kernel = "kernel@1";
--                        fdt = "fdt@1";
-+                default = "conf-1";
-+                conf-1 {
-+                        kernel = "kernel-1";
-+                        fdt = "fdt-1";
-                         %(ramdisk_config)s
-                         %(loadables_config)s
-                 };
-@@ -410,7 +410,7 @@ def test_fit(u_boot_console):
- 
-         # Try a ramdisk
-         with cons.log.section('Kernel + FDT + Ramdisk load'):
--            params['ramdisk_config'] = 'ramdisk = "ramdisk@1";'
-+            params['ramdisk_config'] = 'ramdisk = "ramdisk-1";'
-             params['ramdisk_load'] = 'load = <%#x>;' % params['ramdisk_addr']
-             fit = make_fit(mkimage, params)
-             cons.restart_uboot()
-@@ -419,7 +419,7 @@ def test_fit(u_boot_console):
- 
-         # Configuration with some Loadables
-         with cons.log.section('Kernel + FDT + Ramdisk load + Loadables'):
--            params['loadables_config'] = 'loadables = "kernel@2", "ramdisk@2";'
-+            params['loadables_config'] = 'loadables = "kernel-2", "ramdisk-2";'
-             params['loadables1_load'] = ('load = <%#x>;' %
-                                          params['loadables1_addr'])
-             params['loadables2_load'] = ('load = <%#x>;' %
-diff --git a/test/py/tests/vboot_forge.py b/test/py/tests/vboot_forge.py
-index 0fb7ef4024..b41105bd0e 100644
---- a/test/py/tests/vboot_forge.py
-+++ b/test/py/tests/vboot_forge.py
-@@ -376,12 +376,12 @@ def manipulate(root, strblock):
-     """
-     Maliciously manipulates the structure to create a crafted FIT file
-     """
--    # locate /images/kernel@1 (frankly, it just expects it to be the first one)
-+    # locate /images/kernel-1 (frankly, it just expects it to be the first one)
-     kernel_node = root[0][0]
-     # clone it to save time filling all the properties
-     fake_kernel = kernel_node.clone()
-     # rename the node
--    fake_kernel.name = b'kernel@2'
-+    fake_kernel.name = b'kernel-2'
-     # get rid of signatures/hashes
-     fake_kernel.children = []
-     # NOTE: this simply replaces the first prop... either description or data
-@@ -391,13 +391,13 @@ def manipulate(root, strblock):
-     root[0].children.append(fake_kernel)
- 
-     # modify the default configuration
--    root[1].props[0].value = b'conf@2\x00'
-+    root[1].props[0].value = b'conf-2\x00'
-     # clone the first (only?) configuration
-     fake_conf = root[1][0].clone()
-     # rename and change kernel and fdt properties to select the crafted kernel
--    fake_conf.name = b'conf@2'
--    fake_conf.props[0].value = b'kernel@2\x00'
--    fake_conf.props[1].value = b'fdt@1\x00'
-+    fake_conf.name = b'conf-2'
-+    fake_conf.props[0].value = b'kernel-2\x00'
-+    fake_conf.props[1].value = b'fdt-1\x00'
-     # insert the new configuration under /configurations
-     root[1].children.append(fake_conf)
- 

meta/recipes-bsp/u-boot/files/CVE-2021-27138-2.patch

@@ -1,109 +0,0 @@
-From 3f04db891a353f4b127ed57279279f851c6b4917 Mon Sep 17 00:00:00 2001
-From: Simon Glass <sjg@chromium.org>
-Date: Mon, 15 Feb 2021 17:08:12 -0700
-Subject: [PATCH] image: Check for unit addresses in FITs
-
-Using unit addresses in a FIT is a security risk. Add a check for this
-and disallow it.
-
-CVE-2021-27138
-
-Signed-off-by: Simon Glass <sjg@chromium.org>
-Reported-by: Bruce Monroe <bruce.monroe@intel.com>
-Reported-by: Arie Haenel <arie.haenel@intel.com>
-Reported-by: Julien Lenoir <julien.lenoir@intel.com>
-
-CVE: CVE-2021-27138
-Upstream-Status: Backport[https://github.com/u-boot/u-boot/commit/3f04db891a353f4b127ed57279279f851c6b4917]
-Signed-off-by: Scott Murray <scott.murray@konsulko.com>
-
----
- common/image-fit.c          | 56 +++++++++++++++++++++++++++++++++++++++++----
- test/py/tests/test_vboot.py |  9 ++++----
- 2 files changed, 57 insertions(+), 8 deletions(-)
-
-diff --git a/common/image-fit.c b/common/image-fit.c
-index bcf395f6a1..28b3d2b191 100644
---- a/common/image-fit.c
-+++ b/common/image-fit.c
-@@ -1568,6 +1568,34 @@ int fit_image_check_comp(const void *fit, int noffset, uint8_t comp)
- 	return (comp == image_comp);
- }
- 
-+/**
-+ * fdt_check_no_at() - Check for nodes whose names contain '@'
-+ *
-+ * This checks the parent node and all subnodes recursively
-+ *
-+ * @fit: FIT to check
-+ * @parent: Parent node to check
-+ * @return 0 if OK, -EADDRNOTAVAIL is a node has a name containing '@'
-+ */
-+static int fdt_check_no_at(const void *fit, int parent)
-+{
-+	const char *name;
-+	int node;
-+	int ret;
-+
-+	name = fdt_get_name(fit, parent, NULL);
-+	if (!name || strchr(name, '@'))
-+		return -EADDRNOTAVAIL;
-+
-+	fdt_for_each_subnode(node, fit, parent) {
-+		ret = fdt_check_no_at(fit, node);
-+		if (ret)
-+			return ret;
-+	}
-+
-+	return 0;
-+}
-+
- int fit_check_format(const void *fit, ulong size)
- {
- 	int ret;
-@@ -1589,10 +1617,27 @@ int fit_check_format(const void *fit, ulong size)
- 		if (size == IMAGE_SIZE_INVAL)
- 			size = fdt_totalsize(fit);
- 		ret = fdt_check_full(fit, size);
-+		if (ret)
-+			ret = -EINVAL;
-+
-+		/*
-+		 * U-Boot stopped using unit addressed in 2017. Since libfdt
-+		 * can match nodes ignoring any unit address, signature
-+		 * verification can see the wrong node if one is inserted with
-+		 * the same name as a valid node but with a unit address
-+		 * attached. Protect against this by disallowing unit addresses.
-+		 */
-+		if (!ret && CONFIG_IS_ENABLED(FIT_SIGNATURE)) {
-+			ret = fdt_check_no_at(fit, 0);
- 
-+			if (ret) {
-+				log_debug("FIT check error %d\n", ret);
-+				return ret;
-+			}
-+		}
- 		if (ret) {
- 			log_debug("FIT check error %d\n", ret);
--			return -EINVAL;
-+			return ret;
- 		}
- 	}
- 
-@@ -1955,10 +2000,13 @@ int fit_image_load(bootm_headers_t *images, ulong addr,
- 	printf("## Loading %s from FIT Image at %08lx ...\n", prop_name, addr);
- 
- 	bootstage_mark(bootstage_id + BOOTSTAGE_SUB_FORMAT);
--	if (fit_check_format(fit, IMAGE_SIZE_INVAL)) {
--		printf("Bad FIT %s image format!\n", prop_name);
-+	ret = fit_check_format(fit, IMAGE_SIZE_INVAL);
-+	if (ret) {
-+		printf("Bad FIT %s image format! (err=%d)\n", prop_name, ret);
-+		if (CONFIG_IS_ENABLED(FIT_SIGNATURE) && ret == -EADDRNOTAVAIL)
-+			printf("Signature checking prevents use of unit addresses (@) in nodes\n");
- 		bootstage_error(bootstage_id + BOOTSTAGE_SUB_FORMAT);
--		return -ENOEXEC;
-+		return ret;
- 	}
- 	bootstage_mark(bootstage_id + BOOTSTAGE_SUB_FORMAT_OK);
- 	if (fit_uname) {

meta/recipes-bsp/u-boot/u-boot-common.inc

@@ -12,16 +12,9 @@ PE = "1"
 
 # We use the revision in order to avoid having to fetch it from the
 # repo during parse
-SRCREV = "c4fddedc48f336eabc4ce3f74940e6aa372de18c"
+SRCREV = "b46dd116ce03e235f2a7d4843c6278e1da44b5e1"
 
 SRC_URI = "git://git.denx.de/u-boot.git \
-           file://0001-add-valid-fdt-check.patch \
-           file://CVE-2021-27097-1.patch \
-           file://CVE-2021-27097-2.patch \
-           file://CVE-2021-27097-3.patch \
-           file://CVE-2021-27097-4.patch \
-           file://CVE-2021-27138-1.patch \
-           file://CVE-2021-27138-2.patch \
           "
 
 S = "${WORKDIR}/git"

meta/recipes-bsp/u-boot/u-boot.inc

@@ -5,7 +5,7 @@ PACKAGE_ARCH = "${MACHINE_ARCH}"
 
 DEPENDS += "kern-tools-native"
 
-inherit uboot-config uboot-extlinux-config uboot-sign deploy cml1 python3native
+inherit uboot-config uboot-extlinux-config uboot-sign deploy cml1 python3native kernel-arch
 
 DEPENDS += "swig-native"
 
@@ -346,6 +346,11 @@ do_deploy () {
         ln -sf ${UBOOT_EXTLINUX_SYMLINK} ${DEPLOYDIR}/${UBOOT_EXTLINUX_CONF_NAME}-${MACHINE}
         ln -sf ${UBOOT_EXTLINUX_SYMLINK} ${DEPLOYDIR}/${UBOOT_EXTLINUX_CONF_NAME}
     fi
+
+    if [ -n "${UBOOT_DTB}" ]
+    then
+        install -m 644 ${B}/arch/${UBOOT_ARCH}/dts/${UBOOT_DTB_BINARY} ${DEPLOYDIR}/
+    fi
 }
 
 addtask deploy before do_build after do_compile

meta/recipes-connectivity/bind/bind_9.16.16.bb

@@ -20,7 +20,7 @@ SRC_URI = "https://ftp.isc.org/isc/bind9/${PV}/${BPN}-${PV}.tar.xz \
            file://0001-avoid-start-failure-with-bind-user.patch \
            "
 
-SRC_URI[sha256sum] = "98b6f432d878a7bf8f57eb7b3c28be27278cf6b9989154bfe6c81104b38e7839"
+SRC_URI[sha256sum] = "6c913902adf878e7dc5e229cea94faefc9d40f44775a30213edd08860f761d7b"
 
 UPSTREAM_CHECK_URI = "https://ftp.isc.org/isc/bind9/"
 # stay at 9.16 follow the ESV versions divisible by 4

meta/recipes-connectivity/iproute2/iproute2_5.12.0.bb

@@ -4,7 +4,7 @@ SRC_URI = "${KERNELORG_MIRROR}/linux/utils/net/${BPN}/${BP}.tar.xz \
            file://0001-libc-compat.h-add-musl-workaround.patch \
            "
 
-SRC_URI[sha256sum] = "c5e2ea108212b3445051b35953ec267f9f3469e1d5c67ac034ab559849505c54"
+SRC_URI[sha256sum] = "9d268db98a36ee2a0e3ff3b92b2efff66fc1138a51e409bdef6ab3cfe15f326f"
 
 # CFLAGS are computed in Makefile and reference CCOPTS
 #

meta/recipes-core/expat/expat_2.4.1.bb

@@ -11,7 +11,7 @@ SRC_URI = "${SOURCEFORGE_MIRROR}/expat/expat-${PV}.tar.bz2 \
            file://run-ptest \
            "
 
-SRC_URI[sha256sum] = "f122a20eada303f904d5e0513326c5b821248f2d4d2afbf5c6f1339e511c0586"
+SRC_URI[sha256sum] = "2f9b6a580b94577b150a7d5617ad4643a4301a6616ff459307df3e225bcfbf40"
 
 EXTRA_OECMAKE_class-native += "-DEXPAT_BUILD_DOCS=OFF"
 
@@ -24,3 +24,5 @@ do_install_ptest_class-target() {
 }
 
 BBCLASSEXTEND += "native nativesdk"
+
+CVE_PRODUCT = "expat libexpat"

meta/recipes-core/gettext/gettext_0.21.bb

@@ -174,7 +174,7 @@ do_install_ptest() {
     fi
 }
 
-RDEPENDS_${PN}-ptest += "make"
+RDEPENDS_${PN}-ptest += "make xz"
 RDEPENDS_${PN}-ptest_append_libc-glibc = "\
     glibc-gconv-big5 \
     glibc-charmap-big5 \