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

diff --git a/poky/documentation/sdk-manual/intro.rst b/poky/documentation/sdk-manual/intro.rst
new file mode 100644
index 000000000..66b12cdff
--- /dev/null
+++ b/poky/documentation/sdk-manual/intro.rst
@@ -0,0 +1,220 @@
+.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
+
+************
+Introduction
+************
+
+eSDK Introduction
+=================
+
+Welcome to the Yocto Project Application Development and the Extensible
+Software Development Kit (eSDK) manual. This manual provides information
+that explains how to use both the Yocto Project extensible and standard
+SDKs to develop applications and images.
+
+.. note::
+
+   Prior to the 2.0 Release of the Yocto Project, application
+   development was primarily accomplished through the use of the
+   Application Development Toolkit (ADT) and the availability of
+   stand-alone cross-development toolchains and other tools. With the
+   2.1 Release of the Yocto Project, application development has
+   transitioned to within a tool-rich extensible SDK and the more
+   traditional standard SDK.
+
+All SDKs consist of the following:
+
+-  *Cross-Development Toolchain*: This toolchain contains a compiler,
+   debugger, and various miscellaneous tools.
+
+-  *Libraries, Headers, and Symbols*: The libraries, headers, and
+   symbols are specific to the image (i.e. they match the image).
+
+-  *Environment Setup Script*: This ``*.sh`` file, once run, sets up the
+   cross-development environment by defining variables and preparing for
+   SDK use.
+
+Additionally, an extensible SDK has tools that allow you to easily add
+new applications and libraries to an image, modify the source of an
+existing component, test changes on the target hardware, and easily
+integrate an application into the :term:`OpenEmbedded Build System`.
+
+You can use an SDK to independently develop and test code that is
+destined to run on some target machine. SDKs are completely
+self-contained. The binaries are linked against their own copy of
+``libc``, which results in no dependencies on the target system. To
+achieve this, the pointer to the dynamic loader is configured at install
+time since that path cannot be dynamically altered. This is the reason
+for a wrapper around the ``populate_sdk`` and ``populate_sdk_ext``
+archives.
+
+Another feature for the SDKs is that only one set of cross-compiler
+toolchain binaries are produced for any given architecture. This feature
+takes advantage of the fact that the target hardware can be passed to
+``gcc`` as a set of compiler options. Those options are set up by the
+environment script and contained in variables such as
+:term:`CC` and
+:term:`LD`. This reduces the space needed
+for the tools. Understand, however, that every target still needs a
+sysroot because those binaries are target-specific.
+
+The SDK development environment consists of the following:
+
+-  The self-contained SDK, which is an architecture-specific
+   cross-toolchain and matching sysroots (target and native) all built
+   by the OpenEmbedded build system (e.g. the SDK). The toolchain and
+   sysroots are based on a :term:`Metadata`
+   configuration and extensions, which allows you to cross-develop on
+   the host machine for the target hardware. Additionally, the
+   extensible SDK contains the ``devtool`` functionality.
+
+-  The Quick EMUlator (QEMU), which lets you simulate target hardware.
+   QEMU is not literally part of the SDK. You must build and include
+   this emulator separately. However, QEMU plays an important role in
+   the development process that revolves around use of the SDK.
+
+In summary, the extensible and standard SDK share many features.
+However, the extensible SDK has powerful development tools to help you
+more quickly develop applications. Following is a table that summarizes
+the primary differences between the standard and extensible SDK types
+when considering which to build:
+
++-----------------------+-----------------------+-----------------------+
+| *Feature*             | *Standard SDK*        | *Extensible SDK*      |
++=======================+=======================+=======================+
+| Toolchain             | Yes                   | Yes [1]_              |
++-----------------------+-----------------------+-----------------------+
+| Debugger              | Yes                   | Yes [1]_              |
++-----------------------+-----------------------+-----------------------+
+| Size                  | 100+ MBytes           | 1+ GBytes (or 300+    |
+|                       |                       | MBytes for minimal    |
+|                       |                       | w/toolchain)          |
++-----------------------+-----------------------+-----------------------+
+| ``devtool``           | No                    | Yes                   |
++-----------------------+-----------------------+-----------------------+
+| Build Images          | No                    | Yes                   |
++-----------------------+-----------------------+-----------------------+
+| Updateable            | No                    | Yes                   |
++-----------------------+-----------------------+-----------------------+
+| Managed Sysroot [2]_  | No                    | Yes                   |
++-----------------------+-----------------------+-----------------------+
+| Installed Packages    | No  [3]_              | Yes  [4]_             |
++-----------------------+-----------------------+-----------------------+
+| Construction          | Packages              | Shared State          |
++-----------------------+-----------------------+-----------------------+
+
+.. [1] Extensible SDK contains the toolchain and debugger if :term:`SDK_EXT_TYPE`
+       is "full" or :term:`SDK_INCLUDE_TOOLCHAIN` is "1", which is the default.
+.. [2] Sysroot is managed through the use of ``devtool``. Thus, it is less
+       likely that you will corrupt your SDK sysroot when you try to add
+       additional libraries.
+.. [3] You can add runtime package management to the standard SDK but it is not
+       supported by default.
+.. [4] You must build and make the shared state available to extensible SDK
+       users for "packages" you want to enable users to install.
+
+The Cross-Development Toolchain
+-------------------------------
+
+The :term:`Cross-Development Toolchain` consists
+of a cross-compiler, cross-linker, and cross-debugger that are used to
+develop user-space applications for targeted hardware. Additionally, for
+an extensible SDK, the toolchain also has built-in ``devtool``
+functionality. This toolchain is created by running a SDK installer
+script or through a :term:`Build Directory` that is based on
+your metadata configuration or extension for your targeted device. The
+cross-toolchain works with a matching target sysroot.
+
+Sysroots
+--------
+
+The native and target sysroots contain needed headers and libraries for
+generating binaries that run on the target architecture. The target
+sysroot is based on the target root filesystem image that is built by
+the OpenEmbedded build system and uses the same metadata configuration
+used to build the cross-toolchain.
+
+The QEMU Emulator
+-----------------
+
+The QEMU emulator allows you to simulate your hardware while running
+your application or image. QEMU is not part of the SDK but is made
+available a number of different ways:
+
+-  If you have cloned the ``poky`` Git repository to create a
+   :term:`Source Directory` and you have
+   sourced the environment setup script, QEMU is installed and
+   automatically available.
+
+-  If you have downloaded a Yocto Project release and unpacked it to
+   create a Source Directory and you have sourced the environment setup
+   script, QEMU is installed and automatically available.
+
+-  If you have installed the cross-toolchain tarball and you have
+   sourced the toolchain's setup environment script, QEMU is also
+   installed and automatically available.
+
+SDK Development Model
+=====================
+
+Fundamentally, the SDK fits into the development process as follows:
+
+.. image:: figures/sdk-environment.png
+   :align: center
+
+The SDK is installed on any machine and can be used to develop applications,
+images, and kernels. An SDK can even be used by a QA Engineer or Release
+Engineer. The fundamental concept is that the machine that has the SDK
+installed does not have to be associated with the machine that has the
+Yocto Project installed. A developer can independently compile and test
+an object on their machine and then, when the object is ready for
+integration into an image, they can simply make it available to the
+machine that has the Yocto Project. Once the object is available, the
+image can be rebuilt using the Yocto Project to produce the modified
+image.
+
+You just need to follow these general steps:
+
+1. *Install the SDK for your target hardware:* For information on how to
+   install the SDK, see the "`Installing the
+   SDK <#sdk-installing-the-sdk>`__" section.
+
+2. *Download or Build the Target Image:* The Yocto Project supports
+   several target architectures and has many pre-built kernel images and
+   root filesystem images.
+
+   If you are going to develop your application on hardware, go to the
+   :yocto_dl:`machines </releases/yocto/yocto-&DISTRO;/machines/>` download area and choose a
+   target machine area from which to download the kernel image and root
+   filesystem. This download area could have several files in it that
+   support development using actual hardware. For example, the area
+   might contain ``.hddimg`` files that combine the kernel image with
+   the filesystem, boot loaders, and so forth. Be sure to get the files
+   you need for your particular development process.
+
+   If you are going to develop your application and then run and test it
+   using the QEMU emulator, go to the
+   :yocto_dl:`machines/qemu </releases/yocto/yocto-&DISTRO;/machines/qemu>` download area. From this
+   area, go down into the directory for your target architecture (e.g.
+   ``qemux86_64`` for an Intel-based 64-bit architecture). Download the
+   kernel, root filesystem, and any other files you need for your
+   process.
+
+   .. note::
+
+      To use the root filesystem in QEMU, you need to extract it. See
+      the "
+      Extracting the Root Filesystem
+      " section for information on how to extract the root filesystem.
+
+3. *Develop and Test your Application:* At this point, you have the
+   tools to develop your application. If you need to separately install
+   and use the QEMU emulator, you can go to `QEMU Home
+   Page <http://wiki.qemu.org/Main_Page>`__ to download and learn about
+   the emulator. See the ":doc:`/dev-manual/qemu`" chapter in the
+   Yocto Project Development Tasks Manual for information on using QEMU
+   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
+how you can build, install, and modify an SDK.