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, 110 deletions

diff --git a/poky/documentation/test-manual/test-manual-test-process.xml b/poky/documentation/test-manual/test-manual-test-process.xml
deleted file mode 100644
index 6e2157c62..000000000
--- a/poky/documentation/test-manual/test-manual-test-process.xml
+++ /dev/null
@@ -1,110 +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='test-manual-test-process'>
-
-<title>Project Testing and Release Process</title>
-    <section id='test-daily-devel'>
-        <title>Day to Day Development</title>
-
-        <para>This section details how the project tests changes, through automation on the
-            Autobuilder or with the assistance of QA teams, through to making releases.</para>
-
-        <para>The project aims to test changes against our test matrix before those changes are
-            merged into the master branch. As such, changes are queued up in batches either in the
-                <filename>master-next</filename> branch in the main trees, or in user trees such as
-                <filename>ross/mut</filename> in <filename>poky-contrib</filename> (Ross Burton
-            helps review and test patches and this is his testing tree).</para>
-        <para>We have two broad categories of test builds, including "full" and "quick". On the
-            Autobuilder, these can be seen as "a-quick" and "a-full", simply for ease of sorting in
-            the UI. Use our Autobuilder console view to see where me manage most test-related items,
-            available at: <link linkend=""
-                >https://autobuilder.yoctoproject.org/typhoon/#/console</link>.</para>
-        <para>Builds are triggered manually when the test branches are ready. The builds are
-            monitored by the SWAT team. For additional information, see <link linkend=""
-                >https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team</link>. If
-            successful, the changes would usually be merged to the <filename>master</filename>
-            branch. If not successful, someone would respond to the changes on the mailing list
-            explaining that there was a failure in testing. The choice of quick or full would depend
-            on the type of changes and the speed with which the result was required.</para>
-        <para>The Autobuilder does build the <filename>master</filename> branch once daily for
-            several reasons, in particular, to ensure the current <filename>master</filename> branch
-            does build, but also to keep <filename>yocto-testresults</filename> (<link linkend=""
-                >http://git.yoctoproject.org/cgit.cgi/yocto-testresults/</link>), buildhistory
-                (<link linkend="">http://git.yoctoproject.org/cgit.cgi/poky-buildhistory/</link>),
-            and our sstate up to date. On the weekend, there is a master-next build instead to
-            ensure the test results are updated for the less frequently run targets.</para>
-        <para>Performance builds (buildperf-* targets in the console) are triggered separately every
-            six hours and automatically push their results to the buildstats repository at: <link
-                linkend="">http://git.yoctoproject.org/cgit.cgi/yocto-buildstats/</link>. </para>
-        <para>The 'quick' targets have been selected to be the ones which catch the most failures or
-            give the most valuable data. We run 'fast' ptests in this case for example but not the
-            ones which take a long time. The quick target doesn't include *-lsb builds for all
-            architectures, some world builds and doesn't trigger performance tests or ltp testing.
-            The full build includes all these things and is slower but more comprehensive.</para>
-    </section>
-
-    <section id='test-yocto-project-autobuilder-overview'>
-        <title>Release Builds</title>
-
-        <para>The project typically has two major releases a year with a six month cadence in April
-            and October. Between these there would be a number of milestone releases (usually four)
-            with the final one being stablization only along with point releases of our stable
-            branches.</para>
-        <para>The build and release process for these project releases is similar to that in <link
-                linkend="test-daily-devel">Day to Day Development</link>, in that the a-full target
-            of the Autobuilder is used but in addition the form is configured to generate and
-            publish artefacts and the milestone number, version, release candidate number and other
-            information is entered. The box to "generate an email to QA"is also checked.</para>
-        <para>When the build completes, an email is sent out using the send-qa-email script in the
-                <filename>yocto-autobuilder-helper</filename> repository to the list of people
-            configured for that release. Release builds are placed into a directory in <link
-                linkend="">https://autobuilder.yocto.io/pub/releases</link> on the Autobuilder which
-            is included in the email. The process from here is more manual and control is
-            effectively passed to release engineering. The next steps include:<itemizedlist>
-                <listitem>
-                    <para>QA teams respond to the email saying which tests they plan to run and when
-                        the results will be available.</para>
-                </listitem>
-                <listitem>
-                    <para>QA teams run their tests and share their results in the yocto-
-                        testresults-contrib repository, along with a summary of their findings.
-                    </para>
-                </listitem>
-                <listitem>
-                    <para>Release engineering prepare the release as per their process. </para>
-                </listitem>
-                <listitem>
-                    <para>Test results from the QA teams are included into the release in separate
-                        directories and also uploaded to the yocto-testresults repository alongside
-                        the other test results for the given revision.</para>
-                </listitem>
-                <listitem>
-                    <para>The QA report in the final release is regenerated using resulttool to
-                        include the new test results and the test summaries from the teams (as
-                        headers to the generated report).</para>
-                </listitem>
-                <listitem>
-                    <para>The release is checked against the release checklist and release readiness
-                        criteria.</para>
-                </listitem>
-                <listitem>
-                    <para>A final decision on whether to release is made by the YP TSC who have
-                        final oversight on release readiness.</para>
-                </listitem>
-            </itemizedlist></para>
-    </section>
-
-
-
-
-
-
-
-
-</chapter>
-<!--
-vim: expandtab tw=80 ts=4
--->