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

diff --git a/poky/documentation/sdk-manual/using.rst b/poky/documentation/sdk-manual/using.rst
new file mode 100644
index 0000000000..29fb50465f
--- /dev/null
+++ b/poky/documentation/sdk-manual/using.rst
@@ -0,0 +1,153 @@
+.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
+
+**********************
+Using the Standard SDK
+**********************
+
+This chapter describes the standard SDK and how to install it.
+Information includes unique installation and setup aspects for the
+standard SDK.
+
+.. note::
+
+   For a side-by-side comparison of main features supported for a
+   standard SDK as compared to an extensible SDK, see the "
+   Introduction
+   " section.
+
+You can use a standard SDK to work on Makefile and Autotools-based
+projects. See the "`Using the SDK Toolchain
+Directly <#sdk-working-projects>`__" chapter for more information.
+
+Why use the Standard SDK and What is in It?
+===========================================
+
+The Standard SDK provides a cross-development toolchain and libraries
+tailored to the contents of a specific image. You would use the Standard
+SDK if you want a more traditional toolchain experience as compared to
+the extensible SDK, which provides an internal build system and the
+``devtool`` functionality.
+
+The installed Standard SDK consists of several files and directories.
+Basically, it contains an SDK environment setup script, some
+configuration files, and host and target root filesystems to support
+usage. You can see the directory structure in the "`Installed Standard
+SDK Directory
+Structure <#sdk-installed-standard-sdk-directory-structure>`__" section.
+
+Installing the SDK
+==================
+
+The first thing you need to do is install the SDK on your :term:`Build
+Host` by running the ``*.sh`` installation script.
+
+You can download a tarball installer, which includes the pre-built
+toolchain, the ``runqemu`` script, and support files from the
+appropriate :yocto_dl:`toolchain </releases/yocto/yocto-&DISTRO;/toolchain/>` directory within
+the Index of Releases. Toolchains are available for several 32-bit and
+64-bit architectures with the ``x86_64`` directories, respectively. The
+toolchains the Yocto Project provides are based off the
+``core-image-sato`` and ``core-image-minimal`` images and contain
+libraries appropriate for developing against that image.
+
+The names of the tarball installer scripts are such that a string
+representing the host system appears first in the filename and then is
+immediately followed by a string representing the target architecture.
+::
+
+   poky-glibc-host_system-image_type-arch-toolchain-release_version.sh
+
+   Where:
+       host_system is a string representing your development system:
+
+                  i686 or x86_64.
+
+       image_type is the image for which the SDK was built:
+
+                  core-image-minimal or core-image-sato.
+
+       arch is a string representing the tuned target architecture:
+
+                  aarch64, armv5e, core2-64, i586, mips32r2, mips64, ppc7400, or cortexa8hf-neon.
+
+       release_version is a string representing the release number of the Yocto Project:
+
+                  &DISTRO;, &DISTRO;+snapshot
+
+For example, the following SDK installer is for a 64-bit
+development host system and a i586-tuned target architecture based off
+the SDK for ``core-image-sato`` and using the current DISTRO snapshot:
+::
+
+   poky-glibc-x86_64-core-image-sato-i586-toolchain-DISTRO.sh
+
+.. note::
+
+   As an alternative to downloading an SDK, you can build the SDK
+   installer. For information on building the installer, see the "
+   Building an SDK Installer
+   " section.
+
+The SDK and toolchains are self-contained and by default are installed
+into the ``poky_sdk`` folder in your home directory. You can choose to
+install the extensible SDK in any location when you run the installer.
+However, because files need to be written under that directory during
+the normal course of operation, the location you choose for installation
+must be writable for whichever users need to use the SDK.
+
+The following command shows how to run the installer given a toolchain
+tarball for a 64-bit x86 development host system and a 64-bit x86 target
+architecture. The example assumes the SDK installer is located in
+``~/Downloads/`` and has execution rights.
+
+.. note::
+
+   If you do not have write permissions for the directory into which you
+   are installing the SDK, the installer notifies you and exits. For
+   that case, set up the proper permissions in the directory and run the
+   installer again.
+
+::
+
+   $ ./Downloads/poky-glibc-x86_64-core-image-sato-i586-toolchain-&DISTRO;.sh
+   Poky (Yocto Project Reference Distro) SDK installer version &DISTRO;
+   ===============================================================
+   Enter target directory for SDK (default: /opt/poky/&DISTRO;):
+   You are about to install the SDK to "/opt/poky/&DISTRO;". Proceed [Y/n]? Y
+   Extracting SDK........................................ ..............................done
+   Setting it up...done
+   SDK has been successfully set up and is ready to be used.
+   Each time you wish to use the SDK in a new shell session, you need to source the environment setup script e.g.
+    $ . /opt/poky/&DISTRO;/environment-setup-i586-poky-linux
+
+Again, reference the "`Installed Standard SDK Directory
+Structure <#sdk-installed-standard-sdk-directory-structure>`__" section
+for more details on the resulting directory structure of the installed
+SDK.
+
+Running the SDK Environment Setup Script
+========================================
+
+Once you have the SDK installed, you must run the SDK environment setup
+script before you can actually use the SDK. This setup script resides in
+the directory you chose when you installed the SDK, which is either the
+default ``/opt/poky/&DISTRO;`` directory or the directory you chose during
+installation.
+
+Before running the script, be sure it is the one that matches the
+architecture for which you are developing. Environment setup scripts
+begin with the string "``environment-setup``" and include as part of
+their name the tuned target architecture. As an example, the following
+commands set the working directory to where the SDK was installed and
+then source the environment setup script. In this example, the setup
+script is for an IA-based target machine using i586 tuning:
+::
+
+   $ source /opt/poky/&DISTRO;/environment-setup-i586-poky-linux
+
+When you run the
+setup script, the same environment variables are defined as are when you
+run the setup script for an extensible SDK. See the "`Running the
+Extensible SDK Environment Setup
+Script <#sdk-running-the-extensible-sdk-environment-setup-script>`__"
+section for more information.