poky: subtree update:b23aa6b753..ad30a6d470

Armin Kuster (1):
      timezone: update to 2020b

Bruce Ashfield (7):
      linux-yocto/5.4: fix kprobes build warning
      linux-yocto/5.4: update to v5.4.67
      linux-yocto/5.8: update to v5.8.11
      linux-yocto/5.4: update to v5.4.68
      linux-yocto/5.8: update to v5.8.12
      linux-yocto/5.4: update to v5.4.69
      linux-yocto/5.8: update to v5.8.13

Fabio Berton (1):
      weston-init: Add environment file support for systemd unit file

Jon Mason (5):
      armv8/tunes: Move TUNECONFLICTS
      armv8/tunes: reference parent's TUNE_FEATURES
      armv8/tunes: Add tunes for supported ARMv8a cores
      armv8/tunes: Add tunes for supported ARMv8.2a cores
      tune-cortexa32: fix cortexa32 tune

Joshua Watt (2):
      classes/sanity: Bump minimum python version to 3.5
      classes/waf: Add build and install arguments

Khem Raj (3):
      systemd: Use ROOTPREFIX without suffixed slash in systemd.pc.in
      musl: Update to master
      strace: Fix value of IPPROTO_MAX

Martin Jansa (3):
      base.bbclass: use os.path.normpath instead of just comparing WORKDIR and S as strings
      mtd-utils: don't use trailing slash in S
      base.bbclass: warn when there is trailing slash in S or B variables

Michael Thalmeier (1):
      IMAGE_LOCALES_ARCHIVE: add option to prevent locale archive creation

Naoki Hayama (3):
      uninative: Fix typo in error message
      local.conf.sample: Fix comment typo
      local.conf.sample.extended: Fix comment typo

Naveen Saini (2):
      linux-yocto: update genericx86* SRCREV for 5.4
      linux-yocto: update genericx86* SRCREV for 5.8

Nicolas Dechesne (8):
      bitbake: docs: ref-variables: add links to terms in glossary
      bitbake: docs: sphinx: replace special quotes with double quotes
      bitbake: docs: update README file after migrationg to Sphinx
      bitbake: docs: sphinx: report errors when dependencies are not met
      bitbake: sphinx: remove DocBook files
      bitbake: sphinx: rename Makefile.sphinx
      sphinx: remove DocBook files
      sphinx: rename Makefile.sphinx

Peter Kjellerstedt (1):
      tune-cortexa65.inc: Correct TUNE_FEATURES_tune-cortexa65

Quentin Schulz (4):
      docs: ref-manual: ref-variables: fix one-letter pointer links in glossary
      docs: ref-manual: ref-variables: fix alphabetical order in glossary
      docs: ref-manual: ref-variables: add links to terms in glossary
      bitbake: docs: static: theme_overrides.css: fix responsive design on <640px screens

Richard Purdie (25):
      glibc: do_stash_locale must not delete files from ${D}
      libtools-cross/shadow-sysroot: Use nopackages inherit
      pseudo: Ignore mismatched inodes from the db
      pseudo: Add support for ignoring paths from the pseudo DB
      pseudo: Abort on mismatch patch
      psuedo: Add tracking of linked files for fds
      pseudo: Fix xattr segfault
      pseudo: Add may unlink patch
      pseudo: Add pathfix patch
      base/bitbake.conf: Enable pseudo path filtering
      wic: Handle new PSEUDO_IGNORE_PATHS variable
      pseudo: Fix statx function usage
      bitbake.conf: Extend PSEUDO_IGNORE_PATHS to ${COREBASE}/meta
      docs: Fix license CC-BY-2.0-UK -> CC-BY-SA-2.0-UK
      abi_version,sanity: Tell users TMPDIR must be clean after pseudo changes
      pseudo: Update to account for patches merged on branch
      pseudo: Upgrade to include mkostemp64 wrapper
      poky.conf: Drop OELAYOUT_ABI poking
      bitbake: command: Ensure exceptions inheriting from BBHandledException are visible
      bitbake: tinfoil: When sending commands we need to process events
      scripts/oe-build-perf-report: Allow operation with no buildstats
      oe-build-perf-report: Ensure correct data is shown for multiple branch options
      skeleton/baremetal-helloworld: Fix trailing slash
      oeqa/selftest/runtime_test: Exclude gpg directory from pseudo database
      bitbake: process: Show command exceptions in the server log as well

Ross Burton (10):
      bjam-native: don't do debug builds
      coreutils: improve coreutils-ptest RDEPENDS
      parted: improve ptest
      devtool: remove unused variable
      selftest: skip npm tests if nodejs-native isn't available
      selftest: add test for recipes with patches in overrides
      devtool: fix modify with patches in override directories
      boost: build a standalone boost.build
      boost: don't specify gcc version
      boost: consolidate and update library list

Usama Arif (1):
      kernel-fitimage: generate openssl RSA keys for signing fitimage

Victor Kamensky (2):
      qemu: add 34Kf-64tlb fictitious cpu type
      qemumips: use 34Kf-64tlb CPU emulation

Yann Dirson (1):
      rngd: fix --debug to also filter syslog() calls

Yoann Congal (1):
      bitbake-bblayers/create: Make the example recipe print its message

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

1 files changed, 0 insertions, 201 deletions

diff --git a/poky/documentation/sdk-manual/sdk-using.xml b/poky/documentation/sdk-manual/sdk-using.xml
deleted file mode 100644
index 28ee50d0b..000000000
--- a/poky/documentation/sdk-manual/sdk-using.xml
+++ /dev/null
@@ -1,201 +0,0 @@
-<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
-[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
-<!--SPDX-License-Identifier: CC-BY-2.0-UK-->
-
-<chapter id='sdk-using-the-standard-sdk'>
-    <title>Using the Standard SDK</title>
-
-    <para>
-        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
-            "<link linkend='sdk-manual-intro'>Introduction</link>"
-            section.
-        </note>
-    </para>
-
-    <para>
-        You can use a standard SDK to work on Makefile and Autotools-based
-        projects.
-        See the
-        "<link linkend='sdk-working-projects'>Using the SDK Toolchain Directly</link>"
-        chapter for more information.
-    </para>
-
-    <section id='sdk-standard-sdk-intro'>
-        <title>Why use the Standard SDK and What is in It?</title>
-
-        <para>
-            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
-            <filename>devtool</filename> functionality.
-        </para>
-
-        <para>
-            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
-            "<link linkend='sdk-installed-standard-sdk-directory-structure'>Installed Standard SDK Directory Structure</link>"
-            section.
-        </para>
-    </section>
-
-    <section id='sdk-installing-the-sdk'>
-        <title>Installing the SDK</title>
-
-        <para>
-            The first thing you need to do is install the SDK on your
-            <ulink url='&YOCTO_DOCS_REF_URL;#hardware-build-system-term'>Build Host</ulink>
-            by running the <filename>*.sh</filename> installation script.
-        </para>
-
-        <para>
-            You can download a tarball installer, which includes the
-            pre-built toolchain, the <filename>runqemu</filename>
-            script, and support files from the appropriate
-            <ulink url='&YOCTO_TOOLCHAIN_DL_URL;'>toolchain</ulink>
-            directory within the Index of Releases.
-            Toolchains are available for several 32-bit and 64-bit
-            architectures with the <filename>x86_64</filename> directories,
-            respectively.
-            The toolchains the Yocto Project provides are based off the
-            <filename>core-image-sato</filename> and
-            <filename>core-image-minimal</filename> images and contain
-            libraries appropriate for developing against that image.
-        </para>
-
-        <para>
-            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.
-            <literallayout class='monospaced'>
-     poky-glibc-<replaceable>host_system</replaceable>-<replaceable>image_type</replaceable>-<replaceable>arch</replaceable>-toolchain-<replaceable>release_version</replaceable>.sh
-
-     Where:
-         <replaceable>host_system</replaceable> is a string representing your development system:
-
-                    i686 or x86_64.
-
-         <replaceable>image_type</replaceable> is the image for which the SDK was built:
-
-                    core-image-minimal or core-image-sato.
-
-         <replaceable>arch</replaceable> is a string representing the tuned target architecture:
-
-                    aarch64, armv5e, core2-64, i586, mips32r2, mips64, ppc7400, or cortexa8hf-neon.
-
-         <replaceable>release_version</replaceable> is a string representing the release number of the Yocto Project:
-
-                    &DISTRO;, &DISTRO;+snapshot
-            </literallayout>
-            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 <filename>core-image-sato</filename> and
-            using the current &DISTRO; snapshot:
-            <literallayout class='monospaced'>
-     poky-glibc-x86_64-core-image-sato-i586-toolchain-&DISTRO;.sh
-            </literallayout>
-            <note>
-                As an alternative to downloading an SDK, you can build the
-                SDK installer.
-                For information on building the installer, see the
-                "<link linkend='sdk-building-an-sdk-installer'>Building an SDK Installer</link>"
-                section.
-            </note>
-        </para>
-
-        <para>
-            The SDK and toolchains are self-contained and by default are
-            installed into the <filename>poky_sdk</filename> 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.
-        </para>
-
-        <para>
-            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
-            <filename>~/Downloads/</filename> 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.
-            </note>
-            <literallayout class='monospaced'>
-     $ ./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
-            </literallayout>
-        </para>
-
-        <para>
-            Again, reference the
-            "<link linkend='sdk-installed-standard-sdk-directory-structure'>Installed Standard SDK Directory Structure</link>"
-            section for more details on the resulting directory structure of
-            the installed SDK.
-        </para>
-    </section>
-
-    <section id='sdk-running-the-sdk-environment-setup-script'>
-        <title>Running the SDK Environment Setup Script</title>
-
-        <para>
-            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
-            <filename>/opt/poky/&DISTRO;</filename> directory or the directory
-            you chose during installation.
-        </para>
-
-        <para>
-            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
-            "<filename>environment-setup</filename>" 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:
-            <literallayout class='monospaced'>
-     $ source /opt/poky/&DISTRO;/environment-setup-i586-poky-linux
-            </literallayout>
-            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
-            "<link linkend='sdk-running-the-extensible-sdk-environment-setup-script'>Running the Extensible SDK Environment Setup Script</link>"
-            section for more information.
-        </para>
-    </section>
-</chapter>
-<!--
-vim: expandtab tw=80 ts=4
--->