poky: subtree update:0ac99625bf..796be0593a

Alexander Kanavin (31):
      netbase: upgrade 6.1 -> 6.2
      meson: upgrade 0.55.1 -> 0.56.0
      vulkan-samples: update to latest revision
      libcap: update 2.44 -> 2.45
      bind: upgrade 9.16.7 -> 9.16.9
      quota: upgrade 4.05 -> 4.06
      pango: upgrade 1.46.2 -> 1.48.0
      elfutils: upgrade 0.181 -> 0.182
      ifupdown: upgrade 0.8.35 -> 0.8.36
      createrepo-c: upgrade 0.16.1 -> 0.16.2
      acpica: upgrade 20200925 -> 20201113
      grep: upgrade 3.5 -> 3.6
      man-pages: upgrade 5.08 -> 5.09
      stress-ng: upgrade 0.11.23 -> 0.11.24
      libhandy: upgrade 1.0.1 -> 1.0.2
      piglit: upgrade to latest revision
      xkbcomp: upgrade 1.4.3 -> 1.4.4
      lz4: upgrade 1.9.2 -> 1.9.3
      bison: upgrade 3.7.3 -> 3.7.4
      python3-setuptools-scm: fix upstream version check
      cantarell-fonts: update 0.0.25 -> 0.201
      meta/lib/oe/reproducible.py: gitsm:// works just as fine as git:// for timestamps
      llvm: fix reproducibility
      ruby: fix reproducibility
      webkitgtk: fix reproducibility
      ffmpeg: fix reproducibility
      piglit: fix reproducibility
      serf: do not install the static library
      llvm: sort the lists in generated source reproducibibly
      kea: fix reproducibility
      poky.conf: do not write current date into distro version, use git hash instead

Andrej Valek (1):
      kernel-dummy: fix executing unexpected tasks

Anuj Mittal (1):
      releases.rst: add gatesgarth to current releases

Brett Warren (1):
      libffi: add patch to revert clang VFP workaround

Chandana kalluri (1):
      populate_sdk_ext: use SDK_CUSTOM_TEPLATECONF variable to enable custom templateconf.cfg

Changqing Li (1):
      buildtools-tarball: add wic dependency into extended buildtools

Diego Sueiro (2):
      modutils-initscripts: Fix modules.dep creation when USE_DEPMOD="0"
      initscripts: Change execution order between checkroot and modutils

Dmitry Baryshkov (2):
      linux-firmware: upgrade 20201022 -> 20201118
      linux-firmware: package ath11k firmware

Fabio Berton (1):
      mesa: Update 20.2.1 -> 20.2.4

Gratian Crisan (1):
      kernel-module-split.bbclass: fix kernel modules getting marked as CONFFILES

Jack Mitchell (3):
      Revert "connman: set service to conflict with systemd-networkd"
      systemd-conf: add PACKAGECONFIG to enable/disable auto ethernet DHCP
      systemd-conf: match ethernet interfaces by type rather than globbing

Joshua Watt (2):
      bitbake: hashserv: client: Fix AF_UNIX path length limits
      bitbake: hashserv: Fix broken AF_UNIX path length limit

Kai Kang (2):
      systemd-systemctl-native: capable to call without argument
      systemd.bbclass: update command to check systemctl available

Kevin Hao (1):
      tune-octeontx2.inc: Add tune for Marvell OCTEON TX2 core

Li Wang (2):
      qemu: CVE-2020-29129 CVE-2020-29130
      qemu: CVE-2020-25624

Luca Boccassi (1):
      dbus: move messagebus user to dbus-common package

Michael Halstead (1):
      releases: conf: add link to 3.1.4, update to include 3.1.4

Nicolas Dechesne (19):
      sphinx: add .vscode in .gitignore
      {dev,kernel,sdk}-manual: replace hardcoded release version with &DISTRO;
      sphinx: replace bitbake labels with references to corresponding title
      brief-yoctoprojectqs: replace labels with references to section title
      dev-manual: replace labels with references to section title
      ref-manual: replace labels with references to section title
      sdk-manual: replace labels with references to section title
      overview-manual: remove unused labels
      dev-manual: remove unused labels
      sphinx: rename top level document in each manual
      sphinx: use absolute paths for :doc: references
      test-manual: remove 'test-manual' from filenames
      toaster-manual: remove 'toaster-manual' from filenames
      dev-manual: remove 'dev-manual' from filenames
      kernel-dev: remove 'kernel-dev' from filenames
      profile-manual: remove 'profile-manual' from filenames
      overview-manual: remove 'overview-manual' from filenames
      sdk-manual: remove 'sdk' from filenames
      ref-manual: remove 'ref' from filenames

Paul Barker (5):
      documentation: Simplify yocto_wiki links
      documentation: Simplify yocto_git links
      ref-manual: Simplify oe_git links
      poky.conf: Add opensuseleap-15.2 and fedora-33 to tested distros
      poky.conf: Drop fedora-30 from tested distros

Peter Kjellerstedt (2):
      pseudo: Simplify pseudo_client_ignore_path_chroot()
      bitbake.conf: Add all layers (from BBLAYERS) to PSEUDO_IGNORE_PATHS

Richard Purdie (8):
      lz4: Use the new branch naming from upstream
      Revert "bitbake.conf: Add all layers (from BBLAYERS) to PSEUDO_IGNORE_PATHS"
      build-appliance-image: Update to master head revision
      bitbake: Revert "fetch2: use relative symlinks for anything pulled from PREMIRRORS"
      build-appliance-image: Update to master head revision
      metadata_scm: Fix signature handling of METADATA_REVISION and METADATA_BRANCH
      poky: Set SDK_VERSION explicitly
      build-appliance-image: Update to master head revision

Ross Burton (9):
      oeqa/devtool: use Yocto mirror for pv-1.5.3 tarball
      image_types: remove obsolete tar comment
      image_types: sort tarball file listings
      package_manager/ipk: neaten OPKGLIBDIR logic
      ldconfig-native: don't write auxiliary cache
      package_manager/ipk: improve remove_packaging_data
      oeqa/selftest/containerimage: update for improved cleanup
      coreutils: add SUSE-specific issues to CVE whitelist
      bitbake: msg: use safe YAML loader

Sinan Kaya (1):
      poky-tiny: enable section removal

Tomasz Dziendzielski (1):
      pseudo: Update to print PSEUDO_LOGFILE in abort message on path mismatches

sangeeta jain (1):
      meta/lib/oeqa/manual/oe-core.json: Update test_bitbake_devshell

zangrc (3):
      libinput: upgrade 1.16.3 -> 1.16.4
      lighttpd: upgrade 1.4.55 -> 1.4.56
      sysstat: upgrade 12.4.0 -> 12.4.1

Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
Change-Id: I65f2f1c9d44433f3e62609240012c42256679b51

1 files changed, 442 insertions, 0 deletions

diff --git a/poky/documentation/ref-manual/system-requirements.rst b/poky/documentation/ref-manual/system-requirements.rst
new file mode 100644
index 000000000..66afb0810
--- /dev/null
+++ b/poky/documentation/ref-manual/system-requirements.rst
@@ -0,0 +1,442 @@
+.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
+
+*******************
+System Requirements
+*******************
+
+Welcome to the Yocto Project Reference Manual! This manual provides
+reference information for the current release of the Yocto Project, and
+is most effectively used after you have an understanding of the basics
+of the Yocto Project. The manual is neither meant to be read as a
+starting point to the Yocto Project, nor read from start to finish.
+Rather, use this manual to find variable definitions, class
+descriptions, and so forth as needed during the course of using the
+Yocto Project.
+
+For introductory information on the Yocto Project, see the
+:yocto_home:`Yocto Project Website <>` and the
+":ref:`overview-manual/development-environment:the yocto project development environment`"
+chapter in the Yocto Project Overview and Concepts Manual.
+
+If you want to use the Yocto Project to quickly build an image without
+having to understand concepts, work through the
+:doc:`/brief-yoctoprojectqs/index` document. You can find "how-to"
+information in the :doc:`/dev-manual/index`. You can find Yocto Project overview
+and conceptual information in the :doc:`/overview-manual/index`.
+
+.. note::
+
+   For more information about the Yocto Project Documentation set, see
+   the :ref:`ref-manual/resources:links and related documentation` section.
+
+.. _detailed-supported-distros:
+
+Supported Linux Distributions
+=============================
+
+Currently, the Yocto Project is supported on the following
+distributions:
+
+-  Ubuntu 16.04 (LTS)
+
+-  Ubuntu 18.04 (LTS)
+
+-  Ubuntu 20.04
+
+-  Fedora 30
+
+-  Fedora 31
+
+-  Fedora 32
+
+-  CentOS 7.x
+
+-  CentOS 8.x
+
+-  Debian GNU/Linux 8.x (Jessie)
+
+-  Debian GNU/Linux 9.x (Stretch)
+
+-  Debian GNU/Linux 10.x (Buster)
+
+-  OpenSUSE Leap 15.1
+
+
+.. note::
+
+   -  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.
+
+   -  Yocto Project releases are tested against the stable Linux
+      distributions in the above list. The Yocto Project should work
+      on other distributions but validation is not performed against
+      them.
+
+   -  In particular, the Yocto Project does not support and currently
+      has no plans to support rolling-releases or development
+      distributions due to their constantly changing nature. We welcome
+      patches and bug reports, but keep in mind that our priority is on
+      the supported platforms listed below.
+
+   -  You may use Windows Subsystem For Linux v2 to set up a build host
+      using Windows 10, but validation is not performed against build
+      hosts using WSLv2.
+
+   -  The Yocto Project is not compatible with WSLv1, it is
+      compatible but not officially supported nor validated with
+      WSLv2, if you still decide to use WSL please upgrade to WSLv2.
+
+   -  If you encounter problems, please go to :yocto_bugs:`Yocto Project
+      Bugzilla <>` and submit a bug. We are
+      interested in hearing about your experience. For information on
+      how to submit a bug, see the Yocto Project
+      :yocto_wiki:`Bugzilla wiki page </Bugzilla_Configuration_and_Bug_Tracking>`
+      and the ":ref:`dev-manual/common-tasks:submitting a defect against the yocto project`"
+      section in the Yocto Project Development Tasks Manual.
+
+
+Required Packages for the Build Host
+====================================
+
+The list of packages you need on the host development system can be
+large when covering all build scenarios using the Yocto Project. This
+section describes required packages according to Linux distribution and
+function.
+
+.. _ubuntu-packages:
+
+Ubuntu and Debian
+-----------------
+
+The following list shows the required packages by function given a
+supported Ubuntu or Debian Linux distribution:
+
+.. note::
+
+   -  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:
+      ::
+
+         $ sudo apt-get build-dep qemu
+         $ sudo apt-get remove oss4-dev
+
+   -  For Debian-8, ``python3-git`` and ``pylint3`` are no longer
+      available via ``apt-get``.
+      ::
+
+         $ sudo pip3 install GitPython pylint==1.9.5
+
+-  *Essentials:* Packages needed to build an image on a headless system:
+   ::
+
+      $ sudo apt-get install &UBUNTU_HOST_PACKAGES_ESSENTIAL;
+
+-  *Documentation:* Packages needed if you are going to build out the
+   Yocto Project documentation manuals:
+   ::
+
+      $ sudo apt-get install make python3-pip
+      &PIP3_HOST_PACKAGES_DOC;
+
+   .. note::
+
+      It is currently not possible to build out documentation from Debian 8
+      (Jessie) because of outdated ``pip3`` and ``python3``. ``python3-sphinx``
+      is too outdated.
+
+Fedora Packages
+---------------
+
+The following list shows the required packages by function given a
+supported Fedora Linux distribution:
+
+-  *Essentials:* Packages needed to build an image for a headless
+   system:
+   ::
+
+      $ sudo dnf install &FEDORA_HOST_PACKAGES_ESSENTIAL;
+
+-  *Documentation:* Packages needed if you are going to build out the
+   Yocto Project documentation manuals:
+   ::
+
+      $ sudo dnf install make python3-pip which
+      &PIP3_HOST_PACKAGES_DOC;
+
+openSUSE Packages
+-----------------
+
+The following list shows the required packages by function given a
+supported openSUSE Linux distribution:
+
+-  *Essentials:* Packages needed to build an image for a headless
+   system:
+   ::
+
+      $ sudo zypper install &OPENSUSE_HOST_PACKAGES_ESSENTIAL;
+
+-  *Documentation:* Packages needed if you are going to build out the
+   Yocto Project documentation manuals:
+   ::
+
+      $ sudo zypper install make python3-pip which
+      &PIP3_HOST_PACKAGES_DOC;
+
+
+CentOS-7 Packages
+-----------------
+
+The following list shows the required packages by function given a
+supported CentOS-7 Linux distribution:
+
+-  *Essentials:* Packages needed to build an image for a headless
+   system:
+   ::
+
+      $ sudo yum install &CENTOS7_HOST_PACKAGES_ESSENTIAL;
+
+   .. note::
+
+      -  Extra Packages for Enterprise Linux (i.e. ``epel-release``) is
+         a collection of packages from Fedora built on RHEL/CentOS for
+         easy installation of packages not included in enterprise Linux
+         by default. You need to install these packages separately.
+
+      -  The ``makecache`` command consumes additional Metadata from
+         ``epel-release``.
+
+-  *Documentation:* Packages needed if you are going to build out the
+   Yocto Project documentation manuals:
+   ::
+
+      $ sudo yum install make python3-pip which
+      &PIP3_HOST_PACKAGES_DOC;
+
+CentOS-8 Packages
+-----------------
+
+The following list shows the required packages by function given a
+supported CentOS-8 Linux distribution:
+
+-  *Essentials:* Packages needed to build an image for a headless
+   system:
+   ::
+
+      $ sudo dnf install &CENTOS8_HOST_PACKAGES_ESSENTIAL;
+
+   .. note::
+
+      -  Extra Packages for Enterprise Linux (i.e. ``epel-release``) is
+         a collection of packages from Fedora built on RHEL/CentOS for
+         easy installation of packages not included in enterprise Linux
+         by default. You need to install these packages separately.
+
+      -  The ``PowerTools`` repo provides additional packages such as
+         ``rpcgen`` and ``texinfo``.
+
+      -  The ``makecache`` command consumes additional Metadata from
+         ``epel-release``.
+
+-  *Documentation:* Packages needed if you are going to build out the
+   Yocto Project documentation manuals:
+   ::
+
+      $ sudo dnf install make python3-pip which
+      &PIP3_HOST_PACKAGES_DOC;
+
+Required Git, tar, Python and gcc Versions
+==========================================
+
+In order to use the build system, your host development system must meet
+the following version requirements for Git, tar, and Python:
+
+-  Git 1.8.3.1 or greater
+
+-  tar 1.28 or greater
+
+-  Python 3.5.0 or greater
+
+If your host development system does not meet all these requirements,
+you can resolve this by installing a ``buildtools`` tarball that
+contains these tools. You can get the tarball one of two ways: download
+a pre-built tarball or use BitBake to build the tarball.
+
+In addition, your host development system must meet the following
+version requirement for gcc:
+
+-  gcc 5.0 or greater
+
+If your host development system does not meet this requirement, you can
+resolve this by installing a ``buildtools-extended`` tarball that
+contains additional tools, the equivalent of ``buildtools-essential``.
+
+Installing a Pre-Built ``buildtools`` Tarball with ``install-buildtools`` script
+--------------------------------------------------------------------------------
+
+The ``install-buildtools`` script is the easiest of the three methods by
+which you can get these tools. It downloads a pre-built buildtools
+installer and automatically installs the tools for you:
+
+1. Execute the ``install-buildtools`` script. Here is an example:
+   ::
+
+      $ cd poky
+      $ scripts/install-buildtools --without-extended-buildtools \
+        --base-url &YOCTO_DL_URL;/releases/yocto \
+        --release yocto-&DISTRO; \
+        --installer-version &DISTRO;
+
+   During execution, the buildtools tarball will be downloaded, the
+   checksum of the download will be verified, the installer will be run
+   for you, and some basic checks will be run to to make sure the
+   installation is functional.
+
+   To avoid the need of ``sudo`` privileges, the ``install-buildtools``
+   script will by default tell the installer to install in:
+   ::
+
+      /path/to/poky/buildtools
+
+   If your host development system needs the additional tools provided
+   in the ``buildtools-extended`` tarball, you can instead execute the
+   ``install-buildtools`` script with the default parameters:
+   ::
+
+      $ cd poky
+      $ scripts/install-buildtools
+
+2. Source the tools environment setup script by using a command like the
+   following:
+   ::
+
+      $ source /path/to/poky/buildtools/environment-setup-x86_64-pokysdk-linux
+
+   Of course, you need to supply your installation directory and be sure to
+   use the right file (i.e. i586 or x86_64).
+
+   After you have sourced the setup script, the tools are added to
+   ``PATH`` and any other environment variables required to run the
+   tools are initialized. The results are working versions versions of
+   Git, tar, Python and ``chrpath``. And in the case of the
+   ``buildtools-extended`` tarball, additional working versions of tools
+   including ``gcc``, ``make`` and the other tools included in
+   ``packagegroup-core-buildessential``.
+
+Downloading a Pre-Built ``buildtools`` Tarball
+----------------------------------------------
+
+Downloading and running a pre-built buildtools installer is the easiest
+of the two methods by which you can get these tools:
+
+1. Locate and download the ``*.sh`` at &YOCTO_RELEASE_DL_URL;/buildtools/
+
+2. Execute the installation script. Here is an example for the
+   traditional installer:
+   ::
+
+      $ sh ~/Downloads/x86_64-buildtools-nativesdk-standalone-DISTRO.sh
+
+   Here is an example for the extended installer:
+   ::
+
+      $ sh ~/Downloads/x86_64-buildtools-extended-nativesdk-standalone-DISTRO.sh
+
+   During execution, a prompt appears that allows you to choose the
+   installation directory. For example, you could choose the following:
+   ``/home/your-username/buildtools``
+
+3. Source the tools environment setup script by using a command like the
+   following:
+   ::
+
+      $ source /home/your_username/buildtools/environment-setup-i586-poky-linux
+
+   Of
+   course, you need to supply your installation directory and be sure to
+   use the right file (i.e. i585 or x86-64).
+
+   After you have sourced the setup script, the tools are added to
+   ``PATH`` and any other environment variables required to run the
+   tools are initialized. The results are working versions versions of
+   Git, tar, Python and ``chrpath``. And in the case of the
+   ``buildtools-extended`` tarball, additional working versions of tools
+   including ``gcc``, ``make`` and the other tools included in
+   ``packagegroup-core-buildessential``.
+
+Building Your Own ``buildtools`` Tarball
+----------------------------------------
+
+Building and running your own buildtools installer applies only when you
+have a build host that can already run BitBake. In this case, you use
+that machine to build the ``.sh`` file and then take steps to transfer
+and run it on a machine that does not meet the minimal Git, tar, and
+Python (or gcc) requirements.
+
+Here are the steps to take to build and run your own buildtools
+installer:
+
+1. On the machine that is able to run BitBake, be sure you have set up
+   your build environment with the setup script
+   (:ref:`structure-core-script`).
+
+2. Run the BitBake command to build the tarball:
+   ::
+
+      $ bitbake buildtools-tarball
+
+   or run the BitBake command to build the extended tarball:
+   ::
+
+      $ bitbake buildtools-extended-tarball
+
+   .. note::
+
+      The :term:`SDKMACHINE` variable in your ``local.conf`` file determines
+      whether you build tools for a 32-bit or 64-bit system.
+
+   Once the build completes, you can find the ``.sh`` file that installs
+   the tools in the ``tmp/deploy/sdk`` subdirectory of the
+   :term:`Build Directory`. The installer file has the string
+   "buildtools" (or "buildtools-extended") in the name.
+
+3. Transfer the ``.sh`` file from the build host to the machine that
+   does not meet the Git, tar, or Python (or gcc) requirements.
+
+4. On the machine that does not meet the requirements, run the ``.sh``
+   file to install the tools. Here is an example for the traditional
+   installer:
+   ::
+
+      $ sh ~/Downloads/x86_64-buildtools-nativesdk-standalone-&DISTRO;.sh
+
+   Here is an example for the extended installer:
+   ::
+
+      $ sh ~/Downloads/x86_64-buildtools-extended-nativesdk-standalone-&DISTRO;.sh
+
+   During execution, a prompt appears that allows you to choose the
+   installation directory. For example, you could choose the following:
+   ``/home/your_username/buildtools``
+
+5. Source the tools environment setup script by using a command like the
+   following:
+   ::
+
+      $ source /home/your_username/buildtools/environment-setup-x86_64-poky-linux
+
+   Of course, you need to supply your installation directory and be sure to
+   use the right file (i.e. i586 or x86_64).
+
+   After you have sourced the setup script, the tools are added to
+   ``PATH`` and any other environment variables required to run the
+   tools are initialized. The results are working versions versions of
+   Git, tar, Python and ``chrpath``. And in the case of the
+   ``buildtools-extended`` tarball, additional working versions of tools
+   including ``gcc``, ``make`` and the other tools included in
+   ``packagegroup-core-buildessential``.