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, 0 insertions, 319 deletions

diff --git a/poky/documentation/sdk-manual/sdk-appendix-obtain.rst b/poky/documentation/sdk-manual/sdk-appendix-obtain.rst
deleted file mode 100644
index eef425bdf..000000000
--- a/poky/documentation/sdk-manual/sdk-appendix-obtain.rst
+++ /dev/null
@@ -1,319 +0,0 @@
-.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
-
-*****************
-Obtaining the SDK
-*****************
-
-Locating Pre-Built SDK Installers
-=================================
-
-You can use existing, pre-built toolchains by locating and running an
-SDK installer script that ships with the Yocto Project. Using this
-method, you select and download an architecture-specific SDK installer
-and then run the script to hand-install the toolchain.
-
-Follow these steps to locate and hand-install the toolchain:
-
-1. *Go to the Installers Directory:* Go to
-   :yocto_dl:`/releases/yocto/yocto-3.1.2/toolchain/`
-
-2. *Open the Folder for Your Build Host:* Open the folder that matches
-   your :term:`Build Host` (i.e.
-   ``i686`` for 32-bit machines or ``x86_64`` for 64-bit machines).
-
-3. *Locate and Download the SDK Installer:* You need to find and
-   download the installer appropriate for your build host, target
-   hardware, and image type.
-
-   The installer files (``*.sh``) follow this naming convention:
-   ::
-
-      poky-glibc-host_system-core-image-type-arch-toolchain[-ext]-release.sh
-
-      Where:
-          host_system is a string representing your development system:
-                 "i686" or "x86_64"
-
-          type is a string representing the image:
-                "sato" or "minimal"
-
-          arch is a string representing the target architecture:
-                 "aarch64", "armv5e", "core2-64", "coretexa8hf-neon", "i586", "mips32r2",
-                 "mips64", or "ppc7400"
-
-          release is the version of Yocto Project.
-
-          NOTE:
-             The standard SDK installer does not have the "-ext" string as
-             part of the filename.
-
-
-   The toolchains provided by the Yocto
-   Project are based off of the ``core-image-sato`` and
-   ``core-image-minimal`` images and contain libraries appropriate for
-   developing against those images.
-
-   For example, if your build host is a 64-bit x86 system and you need
-   an extended SDK for a 64-bit core2 target, go into the ``x86_64``
-   folder and download the following installer:
-   ::
-
-      poky-glibc-x86_64-core-image-sato-core2-64-toolchain-ext-DISTRO.sh
-
-4. *Run the Installer:* Be sure you have execution privileges and run
-   the installer. Following is an example from the ``Downloads``
-   directory:
-   ::
-
-      $ ~/Downloads/poky-glibc-x86_64-core-image-sato-core2-64-toolchain-ext-DISTRO.sh
-
-   During execution of the script, you choose the root location for the
-   toolchain. See the "`Installed Standard SDK Directory
-   Structure <#sdk-installed-standard-sdk-directory-structure>`__"
-   section and the "`Installed Extensible SDK Directory
-   Structure <#sdk-installed-extensible-sdk-directory-structure>`__"
-   section for more information.
-
-Building an SDK Installer
-=========================
-
-As an alternative to locating and downloading an SDK installer, you can
-build the SDK installer. Follow these steps:
-
-1. *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`" section
-   in the Yocto Project Development Tasks Manual for information on how
-   to get a build host ready that is either a native Linux machine or a
-   machine that uses CROPS.
-
-2. *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
-   possibly the ":ref:`dev-manual/dev-manual-start:checking out by branch in poky`" and
-   ":ref:`checkout-out-by-tag-in-poky`" sections
-   all in the Yocto Project Development Tasks Manual for information on
-   how to clone the ``poky`` repository and check out the appropriate
-   branch for your work.
-
-3. *Initialize the Build Environment:* While in the root directory of
-   the Source Directory (i.e. ``poky``), run the
-   :ref:`structure-core-script` environment
-   setup script to define the OpenEmbedded build environment on your
-   build host.
-   ::
-
-      $ 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 Source Directory. After
-   the script runs, your current working directory is set to the
-   ``build`` directory.
-
-4. *Make Sure You Are Building an Installer for the Correct Machine:*
-   Check to be sure that your
-   :term:`MACHINE` variable in the
-   ``local.conf`` file in your Build Directory matches the architecture
-   for which you are building.
-
-5. *Make Sure Your SDK Machine is Correctly Set:* If you are building a
-   toolchain designed to run on an architecture that differs from your
-   current development host machine (i.e. the build host), be sure that
-   the :term:`SDKMACHINE` variable
-   in the ``local.conf`` file in your Build Directory is correctly set.
-
-   .. note::
-
-      If you are building an SDK installer for the Extensible SDK, the
-      SDKMACHINE
-      value must be set for the architecture of the machine you are
-      using to build the installer. If
-      SDKMACHINE
-      is not set appropriately, the build fails and provides an error
-      message similar to the following:
-      ::
-
-              The extensible SDK can currently only be built for the same architecture as the machine being built on - SDK_ARCH is
-              set to i686 (likely via setting SDKMACHINE) which is different from the architecture of the build machine (x86_64).
-              Unable to continue.
-
-
-6. *Build the SDK Installer:* To build the SDK installer for a standard
-   SDK and populate the SDK image, use the following command form. Be
-   sure to replace image with an image (e.g. "core-image-sato"): $
-   bitbake image -c populate_sdk You can do the same for the extensible
-   SDK using this command form:
-   ::
-
-      $ bitbake image -c populate_sdk_ext
-
-   These commands produce an SDK installer that contains the sysroot
-   that matches your target root filesystem.
-
-   When the ``bitbake`` command completes, the SDK installer will be in
-   ``tmp/deploy/sdk`` in the Build Directory.
-
-   .. note::
-
-      -  By default, the previous BitBake command does not build static
-         binaries. If you want to use the toolchain to build these types
-         of libraries, you need to be sure your SDK has the appropriate
-         static development libraries. Use the
-         :term:`TOOLCHAIN_TARGET_TASK`
-         variable inside your ``local.conf`` file before building the
-         SDK installer. Doing so ensures that the eventual SDK
-         installation process installs the appropriate library packages
-         as part of the SDK. Following is an example using ``libc``
-         static development libraries: TOOLCHAIN_TARGET_TASK_append = "
-         libc-staticdev"
-
-7. *Run the Installer:* You can now run the SDK installer from
-   ``tmp/deploy/sdk`` in the Build Directory. Following is an example:
-   ::
-
-      $ cd ~/poky/build/tmp/deploy/sdk
-      $ ./poky-glibc-x86_64-core-image-sato-core2-64-toolchain-ext-DISTRO.sh
-
-   During execution of the script, you choose the root location for the
-   toolchain. See the "`Installed Standard SDK Directory
-   Structure <#sdk-installed-standard-sdk-directory-structure>`__"
-   section and the "`Installed Extensible SDK Directory
-   Structure <#sdk-installed-extensible-sdk-directory-structure>`__"
-   section for more information.
-
-Extracting the Root Filesystem
-==============================
-
-After installing the toolchain, for some use cases you might need to
-separately extract a root filesystem:
-
--  You want to boot the image using NFS.
-
--  You want to use the root filesystem as the target sysroot.
-
--  You want to develop your target application using the root filesystem
-   as the target sysroot.
-
-Follow these steps to extract the root filesystem:
-
-1. *Locate and Download the Tarball for the Pre-Built Root Filesystem
-   Image File:* You need to find and download the root filesystem image
-   file that is appropriate for your target system. These files are kept
-   in machine-specific folders in the
-   :yocto_dl:`Index of Releases </releases/yocto/yocto-3.1.2/machines/>`
-   in the "machines" directory.
-
-   The machine-specific folders of the "machines" directory contain
-   tarballs (``*.tar.bz2``) for supported machines. These directories
-   also contain flattened root filesystem image files (``*.ext4``),
-   which you can use with QEMU directly.
-
-   The pre-built root filesystem image files follow these naming
-   conventions:
-   ::
-
-      core-image-profile-arch.tar.bz2
-
-      Where:
-          profile is the filesystem image's profile:
-                    lsb, lsb-dev, lsb-sdk, minimal, minimal-dev, minimal-initramfs,
-                    sato, sato-dev, sato-sdk, sato-sdk-ptest. For information on
-                    these types of image profiles, see the "Images" chapter in
-                    the Yocto Project Reference Manual.
-
-          arch is a string representing the target architecture:
-                    beaglebone-yocto, beaglebone-yocto-lsb, edgerouter, edgerouter-lsb,
-                    genericx86, genericx86-64, genericx86-64-lsb, genericx86-lsb and qemu*.
-
-   The root filesystems
-   provided by the Yocto Project are based off of the
-   ``core-image-sato`` and ``core-image-minimal`` images.
-
-   For example, if you plan on using a BeagleBone device as your target
-   hardware and your image is a ``core-image-sato-sdk`` image, you can
-   download the following file:
-   ::
-
-      core-image-sato-sdk-beaglebone-yocto.tar.bz2
-
-2. *Initialize the Cross-Development Environment:* You must ``source``
-   the cross-development environment setup script to establish necessary
-   environment variables.
-
-   This script is located in the top-level directory in which you
-   installed the toolchain (e.g. ``poky_sdk``).
-
-   Following is an example based on the toolchain installed in the
-   ":ref:`sdk-manual/sdk-appendix-obtain:locating pre-built sdk installers`" section:
-   ::
-
-      $ source ~/poky_sdk/environment-setup-core2-64-poky-linux
-
-3. *Extract the Root Filesystem:* Use the ``runqemu-extract-sdk``
-   command and provide the root filesystem image.
-
-   Following is an example command that extracts the root filesystem
-   from a previously built root filesystem image that was downloaded
-   from the :yocto_dl:`Index of Releases </releases/yocto/yocto-3.1.2/machines/>`.
-   This command extracts the root filesystem into the ``core2-64-sato``
-   directory:
-   ::
-
-      $ runqemu-extract-sdk ~/Downloads/core-image-sato-sdk-beaglebone-yocto.tar.bz2 ~/beaglebone-sato
-
-   You could now point to the target sysroot at ``beablebone-sato``.
-
-Installed Standard SDK Directory Structure
-==========================================
-
-The following figure shows the resulting directory structure after you
-install the Standard SDK by running the ``*.sh`` SDK installation
-script:
-
-.. image:: figures/sdk-installed-standard-sdk-directory.png
-   :scale: 80%
-   :align: center
-
-The installed SDK consists of an environment setup script for the SDK, a
-configuration file for the target, a version file for the target, and
-the root filesystem (``sysroots``) needed to develop objects for the
-target system.
-
-Within the figure, italicized text is used to indicate replaceable
-portions of the file or directory name. For example, install_dir/version
-is the directory where the SDK is installed. By default, this directory
-is ``/opt/poky/``. And, version represents the specific snapshot of the
-SDK (e.g. 3.1.2). Furthermore, target represents the target architecture
-(e.g. ``i586``) and host represents the development system's
-architecture (e.g. ``x86_64``). Thus, the complete names of the two
-directories within the ``sysroots`` could be ``i586-poky-linux`` and
-``x86_64-pokysdk-linux`` for the target and host, respectively.
-
-Installed Extensible SDK Directory Structure
-============================================
-
-The following figure shows the resulting directory structure after you
-install the Extensible SDK by running the ``*.sh`` SDK installation
-script:
-
-.. image:: figures/sdk-installed-extensible-sdk-directory.png
-   :scale: 80%
-   :align: center
-
-The installed directory structure for the extensible SDK is quite
-different than the installed structure for the standard SDK. The
-extensible SDK does not separate host and target parts in the same
-manner as does the standard SDK. The extensible SDK uses an embedded
-copy of the OpenEmbedded build system, which has its own sysroots.
-
-Of note in the directory structure are an environment setup script for
-the SDK, a configuration file for the target, a version file for the
-target, and log files for the OpenEmbedded build system preparation
-script run by the installer and BitBake.
-
-Within the figure, italicized text is used to indicate replaceable
-portions of the file or directory name. For example, install_dir is the
-directory where the SDK is installed, which is ``poky_sdk`` by default,
-and target represents the target architecture (e.g. ``i586``).