poky: subtree update:ad30a6d470..7231c10430

Akira Shibakawa (3):
      License-Update: attr: Add a missing file to LIC_FILES_CHKSUM.
      License-Update: kmod: Add a missing file to LIC_FILES_CHKSUM.
      License-Update: gdk-pixbuf: Fix LICENSE.

Alejandro Hernandez Samaniego (1):
      baremetal-helloworld: Fix install path since S doesnt have a trailing slash

Alexander Kanavin (4):
      ncurses: only include upstream releases in version check
      python3: fix upstream version check
      boost-build-native: fix upstream version check
      selftest/virgl: drop the custom 30 sec timeout

Alistair (1):
      weston-init: Allow setting idle time to 0

Changqing Li (1):
      toolchain-shar-extract.sh: don't print useless info

Charlie Davies (1):
      bitbake: bitbake: fetch/git: use shlex.quote() to support spaces in SRC_URI url

Chen Qi (2):
      watchdog: use /run instead of /var/run in systemd service file
      cups: use /run instead /var/run in systemd's unit file

David Reyna (1):
      bitbake: toaster: Enable Gatesgarth branch in place of Zeus

Douglas Royds (1):
      externalsrc: No single-task lock if S != B

Joshua Watt (2):
      ref-variables: Given example for naming sources
      ref-manual: Document wic --offset option

Khairul Rohaizzat Jamaluddin (1):
      imagefeatures: New test case, test_empty_image, added

Khem Raj (5):
      autotools.bbclass: Order CONFIG_SHELL before CACHED_CONFIGUREVARS
      boost: Fix build on 32-bit arches with 64bit time_t only
      mesa: Fix build on 32bit arches supporting 64bit time_t only
      packagegroup-core-tools-debug: Disable for rv32/glibc as well
      packagegroup-core-tools-profile: Remove lttng-tools and perf for rv32/glibc

Konrad Weihmann (1):
      lib/oe/rootfs: introduce IMAGE_LOG_CHECK_EXCLUDES

Lee Chee Yang (2):
      libproxy: fix CVE-2020-25219
      grub2: fix CVE-2020-10713

Martin Jansa (11):
      tune-cortexa76ae.inc: Correct TUNE_FEATURES
      arch-armv7a.inc: fix typo
      arch-mips.inc: remove duplicated mips64el-o32 from PACKAGE_EXTRA_ARCHS_tune-mips64el-o32
      arch-arm64.inc: don't append _be to ARMPKGARCH for tune-aarch64_be
      tune-mips64r6.inc: fix typo in mipsisa64r6-nf
      tune-ep9312.inc: add t suffix for thumb to PACKAGE_EXTRA_ARCHS_tune-ep9312
      tune-riscv.inc: use nf suffix also for TUNE_PKGARCH
      tune-supersparc.inc: remove
      tune-thunderx.inc: don't append _be to ARMPKGARCH for tune-thunderx_be
      siteinfo: Recognize 32bit PPC LE
      siteinfo: Recognize bigendian sh3be and sh4be

Max Krummenacher (2):
      linux-firmware: package marvel sdio 8997 firmware
      linux-firmware: package nvidia firmware

Mingli Yu (1):
      tcl: adapt to potential pseudo changes

Naoki Hayama (1):
      dev/test/ref-manual: Fix typos

Neil Armstrong (1):
      linux-firmware: add Amlogic VDEC firmware package

Nicolas Dechesne (4):
      sdk-manual: use built-in footnotes
      dev-manual/dev-manual-common-tasks: fix warning
      sphinx: add 3.1.3 and 3.0.4 release in the switcher
      dev-manual/dev-manual-common-tasks: fix typos and use extlinks

Paul Eggleton (2):
      classes/buildhistory: record SRC_URI
      classes/buildhistory: also save recipe info for native recipes

Quentin Schulz (17):
      docs: poky.yaml: use HTTPS for links
      docs: ref-manual: indentation, links and highlights fixes
      docs: remove OE_INIT_FILE variable
      docs: ref-manual: fix typos
      docs: ref-manual: migration-2.3: specify 2.3 version instead of DISTRO
      docs: ref-manual: ref-classes: remove dropped tinderclient class
      docs: ref-manual: ref-system-requirements: update requirements to build Sphinx docs
      docs: sphinx: yocto-vars: rebuild files when poky.yaml has changed
      docs: poky.yaml: fix identation in host packages variables
      docs: dev-manual-common-tasks: remove paragraph about race when missing DEPENDS
      docs: dev-manual-common-tasks: update python webserver example to python3
      docs: dev-manual: fix typos, highlights, indentation and links
      docs: ref-manual: ref-terms: add links to terms in glossary
      docs: bsp-guide: bsp: fix typos, highlights and links
      docs: kernel-dev: fix typos, highlights and links
      docs: kernel-dev-common: add .patch file extension to SRC_URI files
      docs: kernel-dev-faq: update outdated RDEPENDS_kernel-base

Reyna, David (1):
      bitbake: toaster: Update documentation links to new URLs

Richard Purdie (10):
      layer.conf: Switch to gatesgarth only in preparation for release
      bitbake: ui/toasterui: Fix startup faults from incorrect event sequencing
      bitbake: bitbake: Bump version to 1.48.0 ready for the new release
      oeqa: Add sync call to command execution
      poky.conf: Bump version for 3.2 gatesgarth release
      build-appliance-image: Update to master head revision
      bitbake: tests/fetch: Update upstream master->main branchname transition
      Revert "classes/buildhistory: also save recipe info for native recipes"
      valgrind: Fix build on musl after drd fixes
      build-appliance-image: Update to master head revision

Robert Yang (1):
      weston: Fix PACKAGECONFIG for remoting

Roland Hieber (1):
      devtool: make sure .git/info exists before writing to .git/info/excludes

Ross Burton (4):
      waf: don't assume the waf intepretter is good
      waf: add ${B} to do_configure[cleandirs]
      scripts/install-buildtools: Update to 3.2 M3 buildtools
      glib-2.0: fix parsing of slim encoded tzdata

Sourabh Banerjee (1):
      layer.conf: fix sanity error for PATH variable in extensible SDK workflow

Stacy Gaikovaia (2):
      valgrind: drd: fix pthread intercept test failures
      bitbake: main: Handle cooker daemon startup error

Tim Orling (1):
      bitbake: lib/bb/ui/knotty: fix typo in parseprogress

Victor Kamensky (3):
      Revert "qemumips: use 34Kf-64tlb CPU emulation"
      Revert "qemu: add 34Kf-64tlb fictitious cpu type"
      qemu: change TLBs number to 64 in 34Kf mips cpu model

Yi Zhao (1):
      dhcpcd: add PACKAGECONFIG for ntp/chrony/ypbind hooks

Zang Ruochen (1):
      harfbuzz: Refresh patch

akuster (2):
      busybox: add rev and pgrep
      kea: add init scripts

leimaohui (1):
      docs: Updated the status of spdx module.

zangrc (1):
      classes: Fixed the problem of undefined variables when compiling meta-toolchain.

Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
Change-Id: Ic45bc219b94960751896a0ae3d4923a9f5849e70
diff --git a/poky/documentation/bsp-guide/bsp.rst b/poky/documentation/bsp-guide/bsp.rst
index 61b2958..d0275ee 100644
--- a/poky/documentation/bsp-guide/bsp.rst
+++ b/poky/documentation/bsp-guide/bsp.rst
@@ -31,14 +31,14 @@
    meta-bsp_root_name
 
 The string "meta-" is prepended to the
-machine or platform name, which is bsp_root_name in the above form.
+machine or platform name, which is "bsp_root_name" in the above form.
 
 .. note::
 
    Because the BSP layer naming convention is well-established, it is
    advisable to follow it when creating layers. Technically speaking, a
-   BSP layer name does not need to start with
-   meta-. However, various scripts and tools in the Yocto Project development
+   BSP layer name does not need to start with ``meta-``.
+   However, various scripts and tools in the Yocto Project development
    environment assume this convention.
 
 To help understand the BSP layer concept, consider the BSPs that the
@@ -81,7 +81,7 @@
 ``conf/bblayers.conf`` file found in your
 :term:`Build Directory`, which is
 established after you run the OpenEmbedded build environment setup
-script (i.e. :ref:`ref-manual/ref-structure:\`\`oe-init-build-env\`\`` ).
+script (i.e. :ref:`ref-manual/ref-structure:\`\`oe-init-build-env\`\``).
 Adding the root directory allows the :term:`OpenEmbedded Build System`
 to recognize the BSP
 layer and from it build an image. Here is an example: ::
@@ -95,10 +95,11 @@
 
 .. note::
 
-   Ordering and ``BBFILE_PRIORITY`` for the layers listed in BBLAYERS matter. For
-   example, if multiple layers define a machine configuration, the OpenEmbedded
-   build system uses the last layer searched given similar layer priorities. The
-   build system works from the top-down through the layers listed in ``BBLAYERS``.
+   Ordering and :term:`BBFILE_PRIORITY` for the layers listed in ``BBLAYERS``
+   matter. For example, if multiple layers define a machine configuration, the
+   OpenEmbedded build system uses the last layer searched given similar layer
+   priorities. The build system works from the top-down through the layers
+   listed in ``BBLAYERS``.
 
 Some BSPs require or depend on additional layers beyond the BSP's root
 layer in order to be functional. In this case, you need to specify these
@@ -107,7 +108,7 @@
 them to the "Dependencies" section.
 
 Some layers function as a layer to hold other BSP layers. These layers
-are knows as ":term:`container layers <Container Layer>`". An example of
+are known as ":term:`container layers <Container Layer>`". An example of
 this type of layer is OpenEmbedded's
 `meta-openembedded <https://github.com/openembedded/meta-openembedded>`__
 layer. The ``meta-openembedded`` layer contains many ``meta-*`` layers.
@@ -141,8 +142,8 @@
 
 .. note::
 
-   For structural information on BSPs, see the Example Filesystem Layout
-   section.
+   For structural information on BSPs, see the
+   :ref:`bsp-guide/bsp:example filesystem layout` section.
 
 #. *Set Up the Build Environment:* Be sure you are set up to use BitBake
    in a shell. See the ":ref:`dev-manual/dev-manual-start:preparing the build host`"
@@ -150,10 +151,10 @@
    to get a build host ready that is either a native Linux machine or a machine
    that uses CROPS.
 
-#. *Clone the ``poky`` Repository:* You need to have a local copy of the
+#. *Clone the poky Repository:* You need to have a local copy of the
    Yocto Project :term:`Source Directory` (i.e. a local
    ``poky`` repository). See the
-   "ref:`dev-manual/dev-manual-start:cloning the ``poky`` repository`" and
+   ":ref:`dev-manual/dev-manual-start:cloning the \`\`poky\`\` repository`" and
    possibly the
    ":ref:`dev-manual/dev-manual-start:checking out by branch in poky`" or
    ":ref:`dev-manual/dev-manual-start:checking out by tag in poky`"
@@ -168,7 +169,7 @@
    BSP layers, you can look at the `index of
    machines <&YOCTO_RELEASE_DL_URL;/machines>`__ for the release.
 
-#. *Optionally Clone the ``meta-intel`` BSP Layer:* If your hardware is
+#. *Optionally Clone the meta-intel BSP Layer:* If your hardware is
    based on current Intel CPUs and devices, you can leverage this BSP
    layer. For details on the ``meta-intel`` BSP layer, see the layer's
    `README <http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/tree/README>`__
@@ -193,7 +194,7 @@
 
    #. *Check Out the Proper Branch:* The branch you check out for
       ``meta-intel`` must match the same branch you are using for the
-      Yocto Project release (e.g. &DISTRO_NAME_NO_CAP;): ::
+      Yocto Project release (e.g. ``&DISTRO_NAME_NO_CAP;``): ::
 
          $ cd meta-intel
          $ git checkout -b &DISTRO_NAME_NO_CAP; remotes/origin/&DISTRO_NAME_NO_CAP;
@@ -233,7 +234,7 @@
    setup script to define the OpenEmbedded build environment on your
    build host. ::
 
-      $ source &OE_INIT_FILE;
+      $ source oe-init-build-env
 
    Among other things, the script creates the :term:`Build Directory`, which is
    ``build`` in this case and is located in the :term:`Source Directory`.  After
@@ -291,7 +292,9 @@
    meta-bsp_root_name/recipes-kernel/linux/linux-yocto_kernel_rev.bbappend
 
 Below is an example of the Raspberry Pi BSP layer that is available from
-the :yocto_git:`Source Respositories <>`: ::
+the :yocto_git:`Source Respositories <>`:
+
+.. code-block:: none
 
    meta-raspberrypi/COPYING.MIT
    meta-raspberrypi/README.md
@@ -544,13 +547,13 @@
 identifies the contents of the layer, and contains information about how
 the build system should use it. Generally, a standard boilerplate file
 such as the following works. In the following example, you would replace
-bsp with the actual name of the BSP (i.e. bsp_root_name from the example
+"bsp" with the actual name of the BSP (i.e. "bsp_root_name" from the example
 template). ::
 
    # We have a conf and classes directory, add to BBPATH
    BBPATH .= ":${LAYERDIR}"
 
-   # We have a recipes directory, add to BBFILES
+   # We have a recipes directory containing .bb and .bbappend files, add to BBFILES
    BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
                ${LAYERDIR}/recipes-*/*/*.bbappend"
 
@@ -694,7 +697,7 @@
 
 Suppose you are using the ``linux-yocto_4.4.bb`` recipe to build the
 kernel. In other words, you have selected the kernel in your
-bsp_root_name\ ``.conf`` file by adding
+``"bsp_root_name".conf`` file by adding
 :term:`PREFERRED_PROVIDER` and :term:`PREFERRED_VERSION`
 statements as follows: ::
 
@@ -704,7 +707,7 @@
 .. note::
 
    When the preferred provider is assumed by default, the ``PREFERRED_PROVIDER``
-   statement does not appear in the ``bsp_root_name`` .conf file.
+   statement does not appear in the ``"bsp_root_name".conf`` file.
 
 You would use the ``linux-yocto_4.4.bbappend`` file to append specific
 BSP settings to the kernel, thus configuring the kernel for your
@@ -781,7 +784,7 @@
 
    .. note::
 
-      -  Five hardware reference BSPs exist that are part of the Yocto
+      -  Four hardware reference BSPs exist that are part of the Yocto
          Project release and are located in the ``poky/meta-yocto-bsp``
          BSP layer:
 
@@ -870,8 +873,8 @@
 -  The requirements in this section apply regardless of how you package
    a BSP. You should consult the packaging and distribution guidelines
    for your specific release process. For an example of packaging and
-   distribution requirements, see the "`Third Party BSP Release
-   Process <https://wiki.yoctoproject.org/wiki/Third_Party_BSP_Release_Process>`__"
+   distribution requirements, see the ":yocto_wiki:`Third Party BSP Release
+   Process </wiki/Third_Party_BSP_Release_Process>`"
    wiki page.
 
 -  The requirements for the BSP as it is made available to a developer
@@ -897,7 +900,7 @@
    your BSP layer as listed in the ``recipes.txt`` file, which is found
    in ``poky/meta`` directory of the :term:`Source Directory`
    or in the OpenEmbedded-Core Layer (``openembedded-core``) at
-   http://git.openembedded.org/openembedded-core/tree/meta.
+   https://git.openembedded.org/openembedded-core/tree/meta.
 
    You should place recipes (``*.bb`` files) and recipe modifications
    (``*.bbappend`` files) into ``recipes-*`` subdirectories by
@@ -1074,7 +1077,7 @@
 
    .. note::
 
-      If the meta-xyz layer did not support multiple machines, you would place
+      If the ``meta-xyz`` layer did not support multiple machines, you would place
       the interfaces configuration file in the layer here: ::
 
          meta-xyz/recipes-core/init-ifupdown/files/interfaces
@@ -1233,7 +1236,7 @@
    # We have a conf and classes directory, add to BBPATH
    BBPATH .= ":${LAYERDIR}"
 
-   # We have recipes-\* directories, add to BBFILES
+   # We have a recipes directory containing .bb and .bbappend files, add to BBFILES
    BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
                ${LAYERDIR}/recipes-*/*/*.bbappend"
 
@@ -1262,13 +1265,13 @@
 One or more machine configuration files exist in the
 ``bsp_layer/conf/machine/`` directory of the layer: ::
 
-   bsp_layer/conf/machine/machine1\.conf``
-   bsp_layer/conf/machine/machine2\.conf``
-   bsp_layer/conf/machine/machine3\.conf``
+   bsp_layer/conf/machine/machine1\.conf
+   bsp_layer/conf/machine/machine2\.conf
+   bsp_layer/conf/machine/machine3\.conf
    ... more ...
 
 For example, the machine configuration file for the `BeagleBone and
-BeagleBone Black development boards <http://beagleboard.org/bone>`__ is
+BeagleBone Black development boards <https://beagleboard.org/bone>`__ is
 located in the layer ``poky/meta-yocto-bsp/conf/machine`` and is named
 ``beaglebone-yocto.conf``: ::
 
@@ -1344,7 +1347,7 @@
 
    .. tip::
 
-      Many ``MACHINE\*`` variables exist that help you configure a particular piece
+      Many ``MACHINE*`` variables exist that help you configure a particular piece
       of hardware.
 
 -  :term:`EXTRA_IMAGEDEPENDS`:
@@ -1359,12 +1362,12 @@
    These features, which are collectively known as "tuning features",
    exist in the :term:`OpenEmbedded-Core (OE-Core)` layer (e.g.
    ``poky/meta/conf/machine/include``). In this example, the default
-   tunning file is "cortexa8hf-neon".
+   tuning file is "cortexa8hf-neon".
 
    .. note::
 
       The include statement that pulls in the
-      conf/machine/include/tune-cortexa8.inc file provides many tuning
+      ``conf/machine/include/tune-cortexa8.inc`` file provides many tuning
       possibilities.
 
 -  :term:`IMAGE_FSTYPES`: The
@@ -1389,7 +1392,7 @@
 
 -  ``do_image_wic[depends]``: A task that is constructed during the
    build. In this example, the task depends on specific tools in order
-   to create the sysroot when buiding a Wic image.
+   to create the sysroot when building a Wic image.
 
 -  :term:`SERIAL_CONSOLES`:
    Defines a serial console (TTY) to enable using getty. In this case,
@@ -1429,7 +1432,8 @@
 
    .. note::
 
-      For more information on how the SPL variables are used, see the u-boot.inc
+      For more information on how the SPL variables are used, see the
+      :yocto_git:`u-boot.inc </cgit/cgit.cgi/poky/tree/meta/recipes-bsp/u-boot/u-boot.inc>`
       include file.
 
 -  :term:`UBOOT_* <UBOOT_ENTRYPOINT>`: Defines
@@ -1473,7 +1477,7 @@
 metadata used to build the kernel. In this case, a kernel append file
 (i.e. ``linux-yocto_5.0.bbappend``) is used to override an established
 kernel recipe (i.e. ``linux-yocto_5.0.bb``), which is located in
-https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-kernel/linux.
+:yocto_git:`/cgit/cgit.cgi/poky/tree/meta/recipes-kernel/linux`.
 
 Following is the contents of the append file: ::