build-appliance-image: Update to gatesgarth head revision

(From OE-Core rev: d11ab9cb77bf91f939035417b757773a5d80242c)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

bitbake/doc/Makefile

@@ -0,0 +1,35 @@
+# Minimal makefile for Sphinx documentation
+#
+
+# You can set these variables from the command line, and also
+# from the environment for the first two.
+SPHINXOPTS    ?=
+SPHINXBUILD   ?= sphinx-build
+SOURCEDIR     = .
+BUILDDIR      = _build
+DESTDIR       = final
+
+ifeq ($(shell if which $(SPHINXBUILD) >/dev/null 2>&1; then echo 1; else echo 0; fi),0)
+$(error "The '$(SPHINXBUILD)' command was not found. Make sure you have Sphinx installed")
+endif
+
+# Put it first so that "make" without argument is like "make help".
+help:
+	@$(SPHINXBUILD) -M help "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
+
+.PHONY: help Makefile clean publish
+
+publish: Makefile html singlehtml
+	rm -rf $(BUILDDIR)/$(DESTDIR)/
+	mkdir -p $(BUILDDIR)/$(DESTDIR)/
+	cp -r $(BUILDDIR)/html/* $(BUILDDIR)/$(DESTDIR)/
+	cp $(BUILDDIR)/singlehtml/index.html $(BUILDDIR)/$(DESTDIR)/singleindex.html
+	sed -i -e 's@index.html#@singleindex.html#@g' $(BUILDDIR)/$(DESTDIR)/singleindex.html
+
+clean:
+	@rm -rf $(BUILDDIR)
+
+# Catch-all target: route all unknown targets to Sphinx using the new
+# "make mode" option.  $(O) is meant as a shortcut for $(SPHINXOPTS).
+%: Makefile
+	@$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)

documentation/README

@@ -34,15 +34,15 @@ Manual Organization
 
 Folders exist for individual manuals as follows:
 
-* sdk-manual       - The Yocto Project Software Development Kit (SDK) Developer's Guide.
-* bsp-guide        - The Yocto Project Board Support Package (BSP) Developer's Guide
-* dev-manual       - The Yocto Project Development Tasks Manual
-* kernel-dev       - The Yocto Project Linux Kernel Development Tasks Manual
-* ref-manual       - The Yocto Project Reference Manual
-* yocto-project-qs - The Yocto Project Quick Start
-* profile-manual   - The Yocto Project Profile and Tracing Manual
-* toaster-manual   - The Toaster Manual
-* test-manual      - The Test Environment Manual
+* sdk-manual           - The Yocto Project Software Development Kit (SDK) Developer's Guide.
+* bsp-guide            - The Yocto Project Board Support Package (BSP) Developer's Guide
+* dev-manual           - The Yocto Project Development Tasks Manual
+* kernel-dev           - The Yocto Project Linux Kernel Development Tasks Manual
+* ref-manual           - The Yocto Project Reference Manual
+* brief-yoctoprojectqs - The Yocto Project Quick Start
+* profile-manual       - The Yocto Project Profile and Tracing Manual
+* toaster-manual       - The Toaster Manual
+* test-manual          - The Test Environment Manual
 
 Each folder is self-contained regarding content and figures.
 

documentation/adt-manual/adt-command.rst

@@ -1,180 +0,0 @@
-.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
-
-**********************
-Using the Command Line
-**********************
-
-Recall that earlier the manual discussed how to use an existing
-toolchain tarball that had been installed into the default installation
-directory, ``/opt/poky/DISTRO``, which is outside of the :term:`Build Directory`
-(see the section
-"`Using a Cross-Toolchain
-Tarball) <#using-an-existing-toolchain-tarball>`__". And, that sourcing
-your architecture-specific environment setup script initializes a
-suitable cross-toolchain development environment.
-
-During this setup, locations for the compiler, QEMU scripts, QEMU
-binary, a special version of ``pkgconfig`` and other useful utilities
-are added to the ``PATH`` variable. Also, variables to assist
-``pkgconfig`` and ``autotools`` are also defined so that, for example,
-``configure.sh`` can find pre-generated test results for tests that need
-target hardware on which to run. You can see the "`Setting Up the
-Cross-Development
-Environment <#setting-up-the-cross-development-environment>`__" section
-for the list of cross-toolchain environment variables established by the
-script.
-
-Collectively, these conditions allow you to easily use the toolchain
-outside of the OpenEmbedded build environment on both Autotools-based
-projects and Makefile-based projects. This chapter provides information
-for both these types of projects.
-
-Autotools-Based Projects
-========================
-
-Once you have a suitable cross-toolchain installed, it is very easy to
-develop a project outside of the OpenEmbedded build system. This section
-presents a simple "Helloworld" example that shows how to set up,
-compile, and run the project.
-
-Creating and Running a Project Based on GNU Autotools
------------------------------------------------------
-
-Follow these steps to create a simple Autotools-based project:
-
-1.  *Create your directory:* Create a clean directory for your project
-    and then make that directory your working location: $ mkdir
-    $HOME/helloworld $ cd $HOME/helloworld
-
-2.  *Populate the directory:* Create ``hello.c``, ``Makefile.am``, and
-    ``configure.in`` files as follows:
-
-    -  For ``hello.c``, include these lines: #include <stdio.h> main() {
-       printf("Hello World!\n"); }
-
-    -  For ``Makefile.am``, include these lines: bin_PROGRAMS = hello
-       hello_SOURCES = hello.c
-
-    -  For ``configure.in``, include these lines: AC_INIT(hello.c)
-       AM_INIT_AUTOMAKE(hello,0.1) AC_PROG_CC AC_PROG_INSTALL
-       AC_OUTPUT(Makefile)
-
-3.  *Source the cross-toolchain environment setup file:* Installation of
-    the cross-toolchain creates a cross-toolchain environment setup
-    script in the directory that the ADT was installed. Before you can
-    use the tools to develop your project, you must source this setup
-    script. The script begins with the string "environment-setup" and
-    contains the machine architecture, which is followed by the string
-    "poky-linux". Here is an example that sources a script from the
-    default ADT installation directory that uses the 32-bit Intel x86
-    Architecture and the DISTRO_NAME Yocto Project release: $ source
-    /opt/poky/DISTRO/environment-setup-i586-poky-linux
-
-4.  *Generate the local aclocal.m4 files and create the configure
-    script:* The following GNU Autotools generate the local
-    ``aclocal.m4`` files and create the configure script: $ aclocal $
-    autoconf
-
-5.  *Generate files needed by GNU coding standards:* GNU coding
-    standards require certain files in order for the project to be
-    compliant. This command creates those files: $ touch NEWS README
-    AUTHORS ChangeLog
-
-6.  *Generate the configure file:* This command generates the
-    ``configure``: $ automake -a
-
-7.  *Cross-compile the project:* This command compiles the project using
-    the cross-compiler. The
-    :term:`CONFIGURE_FLAGS`
-    environment variable provides the minimal arguments for GNU
-    configure: $ ./configure ${CONFIGURE_FLAGS}
-
-8.  *Make and install the project:* These two commands generate and
-    install the project into the destination directory: $ make $ make
-    install DESTDIR=./tmp
-
-9.  *Verify the installation:* This command is a simple way to verify
-    the installation of your project. Running the command prints the
-    architecture on which the binary file can run. This architecture
-    should be the same architecture that the installed cross-toolchain
-    supports. $ file ./tmp/usr/local/bin/hello
-
-10. *Execute your project:* To execute the project in the shell, simply
-    enter the name. You could also copy the binary to the actual target
-    hardware and run the project there as well: $ ./hello As expected,
-    the project displays the "Hello World!" message.
-
-Passing Host Options
---------------------
-
-For an Autotools-based project, you can use the cross-toolchain by just
-passing the appropriate host option to ``configure.sh``. The host option
-you use is derived from the name of the environment setup script found
-in the directory in which you installed the cross-toolchain. For
-example, the host option for an ARM-based target that uses the GNU EABI
-is ``armv5te-poky-linux-gnueabi``. You will notice that the name of the
-script is ``environment-setup-armv5te-poky-linux-gnueabi``. Thus, the
-following command works to update your project and rebuild it using the
-appropriate cross-toolchain tools: $ ./configure
---host=armv5te-poky-linux-gnueabi \\ --with-libtool-sysroot=sysroot_dir
-
-.. note::
-
-   If the
-   configure
-   script results in problems recognizing the
-   --with-libtool-sysroot=
-   sysroot-dir
-   option, regenerate the script to enable the support by doing the
-   following and then run the script again:
-   ::
-
-           $ libtoolize --automake
-           $ aclocal -I ${OECORE_NATIVE_SYSROOT}/usr/share/aclocal \
-              [-I dir_containing_your_project-specific_m4_macros]
-           $ autoconf
-           $ autoheader
-           $ automake -a
-                      
-
-Makefile-Based Projects
-=======================
-
-For Makefile-based projects, the cross-toolchain environment variables
-established by running the cross-toolchain environment setup script are
-subject to general ``make`` rules.
-
-To illustrate this, consider the following four cross-toolchain
-environment variables:
-:term:`CC`\ =i586-poky-linux-gcc -m32
--march=i586 --sysroot=/opt/poky/1.8/sysroots/i586-poky-linux
-:term:`LD`\ =i586-poky-linux-ld
---sysroot=/opt/poky/1.8/sysroots/i586-poky-linux
-:term:`CFLAGS`\ =-O2 -pipe -g
--feliminate-unused-debug-types
-:term:`CXXFLAGS`\ =-O2 -pipe -g
--feliminate-unused-debug-types Now, consider the following three cases:
-
--  *Case 1 - No Variables Set in the ``Makefile``:* Because these
-   variables are not specifically set in the ``Makefile``, the variables
-   retain their values based on the environment.
-
--  *Case 2 - Variables Set in the ``Makefile``:* Specifically setting
-   variables in the ``Makefile`` during the build results in the
-   environment settings of the variables being overwritten.
-
--  *Case 3 - Variables Set when the ``Makefile`` is Executed from the
-   Command Line:* Executing the ``Makefile`` from the command line
-   results in the variables being overwritten with command-line content
-   regardless of what is being set in the ``Makefile``. In this case,
-   environment variables are not considered unless you use the "-e" flag
-   during the build: $ make -e file If you use this flag, then the
-   environment values of the variables override any variables
-   specifically set in the ``Makefile``.
-
-.. note::
-
-   For the list of variables set up by the cross-toolchain environment
-   setup script, see the "
-   Setting Up the Cross-Development Environment
-   " section.

documentation/adt-manual/adt-intro.rst

@@ -1,138 +0,0 @@
-.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
-
-*****************************************
-The Application Development Toolkit (ADT)
-*****************************************
-
-Part of the Yocto Project development solution is an Application
-Development Toolkit (ADT). The ADT provides you with a custom-built,
-cross-development platform suited for developing a user-targeted product
-application.
-
-Fundamentally, the ADT consists of the following:
-
--  An architecture-specific cross-toolchain and matching sysroot both
-   built by the :term:`OpenEmbedded Build System`.
-   The toolchain and
-   sysroot are based on a `Metadata <&YOCTO_DOCS_DEV_URL;#metadata>`__
-   configuration and extensions, which allows you to cross-develop on
-   the host machine for the target hardware.
-
--  The Eclipse IDE Yocto Plug-in.
-
--  The Quick EMUlator (QEMU), which lets you simulate target hardware.
-
--  Various user-space tools that greatly enhance your application
-   development experience.
-
-The Cross-Development Toolchain
-===============================
-
-The `Cross-Development
-Toolchain <&YOCTO_DOCS_DEV_URL;#cross-development-toolchain>`__ consists
-of a cross-compiler, cross-linker, and cross-debugger that are used to
-develop user-space applications for targeted hardware. This toolchain is
-created either by running the ADT Installer script, a toolchain
-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.
-
-Sysroot
-=======
-
-The matching target sysroot contains needed headers and libraries for
-generating binaries that run on the target architecture. The 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.
-
-.. _eclipse-overview:
-
-Eclipse Yocto Plug-in
-=====================
-
-The Eclipse IDE is a popular development environment and it fully
-supports development using the Yocto Project. When you install and
-configure the Eclipse Yocto Project Plug-in into the Eclipse IDE, you
-maximize your Yocto Project experience. Installing and configuring the
-Plug-in results in an environment that has extensions specifically
-designed to let you more easily develop software. These extensions allow
-for cross-compilation, deployment, and execution of your output into a
-QEMU emulation session. You can also perform cross-debugging and
-profiling. The environment also supports a suite of tools that allows
-you to perform remote profiling, tracing, collection of power data,
-collection of latency data, and collection of performance data.
-
-For information about the application development workflow that uses the
-Eclipse IDE and for a detailed example of how to install and configure
-the Eclipse Yocto Project Plug-in, see the "`Working Within
-Eclipse <&YOCTO_DOCS_DEV_URL;#adt-eclipse>`__" section of the Yocto
-Project Development Manual.
-
-The QEMU Emulator
-=================
-
-The QEMU emulator allows you to simulate your hardware while running
-your application or image. QEMU is made available a number of ways:
-
--  If you use the ADT Installer script to install ADT, you can specify
-   whether or not to install QEMU.
-
--  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 :term:`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.
-
-User-Space Tools
-================
-
-User-space tools are included as part of the Yocto Project. You will
-find these tools helpful during development. The tools include
-LatencyTOP, PowerTOP, OProfile, Perf, SystemTap, and Lttng-ust. These
-tools are common development tools for the Linux platform.
-
--  *LatencyTOP:* LatencyTOP focuses on latency that causes skips in
-   audio, stutters in your desktop experience, or situations that
-   overload your server even when you have plenty of CPU power left.
-
--  *PowerTOP:* Helps you determine what software is using the most
-   power. You can find out more about PowerTOP at
-   https://01.org/powertop/.
-
--  *OProfile:* A system-wide profiler for Linux systems that is capable
-   of profiling all running code at low overhead. You can find out more
-   about OProfile at http://oprofile.sourceforge.net/about/. For
-   examples on how to setup and use this tool, see the
-   "`OProfile <&YOCTO_DOCS_PROF_URL;#profile-manual-oprofile>`__"
-   section in the Yocto Project Profiling and Tracing Manual.
-
--  *Perf:* Performance counters for Linux used to keep track of certain
-   types of hardware and software events. For more information on these
-   types of counters see https://perf.wiki.kernel.org/. For
-   examples on how to setup and use this tool, see the
-   "`perf <&YOCTO_DOCS_PROF_URL;#profile-manual-perf>`__" section in the
-   Yocto Project Profiling and Tracing Manual.
-
--  *SystemTap:* A free software infrastructure that simplifies
-   information gathering about a running Linux system. This information
-   helps you diagnose performance or functional problems. SystemTap is
-   not available as a user-space tool through the Eclipse IDE Yocto
-   Plug-in. See http://sourceware.org/systemtap for more
-   information on SystemTap. For examples on how to setup and use this
-   tool, see the
-   "`SystemTap <&YOCTO_DOCS_PROF_URL;#profile-manual-systemtap>`__"
-   section in the Yocto Project Profiling and Tracing Manual.
-
--  *Lttng-ust:* A User-space Tracer designed to provide detailed
-   information on user-space activity. See http://lttng.org/ust
-   for more information on Lttng-ust.

documentation/adt-manual/adt-manual-intro.rst

@@ -1,24 +0,0 @@
-.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
-
-************
-Introduction
-************
-
-Welcome to the Yocto Project Application Developer's Guide. This manual
-provides information that lets you begin developing applications using
-the Yocto Project.
-
-The Yocto Project provides an application development environment based
-on an Application Development Toolkit (ADT) and the availability of
-stand-alone cross-development toolchains and other tools. This manual
-describes the ADT and how you can configure and install it, how to
-access and use the cross-development toolchains, how to customize the
-development packages installation, how to use command-line development
-for both Autotools-based and Makefile-based projects, and an
-introduction to the Eclipse IDE Yocto Plug-in.
-
-.. note::
-
-   The ADT is distribution-neutral and does not require the Yocto
-   Project reference distribution, which is called Poky. This manual,
-   however, uses examples that use the Poky distribution.

documentation/adt-manual/adt-manual.rst

@@ -1,17 +0,0 @@
-.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
-
-===========================================
-Yocto Project Application Developer's Guide
-===========================================
-
-|
-
-.. toctree::
-   :caption: Table of Contents
-   :numbered:
-
-   adt-manual-intro
-   adt-intro
-   adt-prepare
-   adt-package
-   adt-command

documentation/adt-manual/adt-package.rst

@@ -1,70 +0,0 @@
-.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
-
-************************************************************
-Optionally Customizing the Development Packages Installation
-************************************************************
-
-Because the Yocto Project is suited for embedded Linux development, it
-is likely that you will need to customize your development packages
-installation. For example, if you are developing a minimal image, then
-you might not need certain packages (e.g. graphics support packages).
-Thus, you would like to be able to remove those packages from your
-target sysroot.
-
-Package Management Systems
-==========================
-
-The OpenEmbedded build system supports the generation of sysroot files
-using three different Package Management Systems (PMS):
-
--  *OPKG:* A less well known PMS whose use originated in the
-   OpenEmbedded and OpenWrt embedded Linux projects. This PMS works with
-   files packaged in an ``.ipk`` format. See
-   http://en.wikipedia.org/wiki/Opkg for more information about
-   OPKG.
-
--  *RPM:* A more widely known PMS intended for GNU/Linux distributions.
-   This PMS works with files packaged in an ``.rpm`` format. The build
-   system currently installs through this PMS by default. See
-   http://en.wikipedia.org/wiki/RPM_Package_Manager for more
-   information about RPM.
-
--  *Debian:* The PMS for Debian-based systems is built on many PMS
-   tools. The lower-level PMS tool ``dpkg`` forms the base of the Debian
-   PMS. For information on dpkg see
-   http://en.wikipedia.org/wiki/Dpkg.
-
-Configuring the PMS
-===================
-
-Whichever PMS you are using, you need to be sure that the
-:term:`PACKAGE_CLASSES`
-variable in the ``conf/local.conf`` file is set to reflect that system.
-The first value you choose for the variable specifies the package file
-format for the root filesystem at sysroot. Additional values specify
-additional formats for convenience or testing. See the
-``conf/local.conf`` configuration file for details.
-
-.. note::
-
-   For build performance information related to the PMS, see the "
-   package.bbclass
-   " section in the Yocto Project Reference Manual.
-
-As an example, consider a scenario where you are using OPKG and you want
-to add the ``libglade`` package to the target sysroot.
-
-First, you should generate the IPK file for the ``libglade`` package and
-add it into a working ``opkg`` repository. Use these commands: $ bitbake
-libglade $ bitbake package-index
-
-Next, source the cross-toolchain environment setup script found in the
-:term:`Source Directory`. Follow
-that by setting up the installation destination to point to your sysroot
-as sysroot_dir. Finally, have an OPKG configuration file conf_file that
-corresponds to the ``opkg`` repository you have just created. The
-following command forms should now work: $ opkg-cl –f conf_file -o
-sysroot_dir update $ opkg-cl –f cconf_file -o sysroot_dir \\
---force-overwrite install libglade $ opkg-cl –f cconf_file -o
-sysroot_dir \\ --force-overwrite install libglade-dbg $ opkg-cl –f
-conf_file> -osysroot_dir> \\ --force-overwrite install libglade-dev

documentation/adt-manual/adt-prepare.rst

@@ -1,752 +0,0 @@
-.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
-
-*************************************
-Preparing for Application Development
-*************************************
-
-In order to develop applications, you need set up your host development
-system. Several ways exist that allow you to install cross-development
-tools, QEMU, the Eclipse Yocto Plug-in, and other tools. This chapter
-describes how to prepare for application development.
-
-.. _installing-the-adt:
-
-Installing the ADT and Toolchains
-=================================
-
-The following list describes installation methods that set up varying
-degrees of tool availability on your system. Regardless of the
-installation method you choose, you must ``source`` the cross-toolchain
-environment setup script, which establishes several key environment
-variables, before you use a toolchain. See the "`Setting Up the
-Cross-Development
-Environment <#setting-up-the-cross-development-environment>`__" section
-for more information.
-
-.. note::
-
-   Avoid mixing installation methods when installing toolchains for
-   different architectures. For example, avoid using the ADT Installer
-   to install some toolchains and then hand-installing cross-development
-   toolchains by running the toolchain installer for different
-   architectures. Mixing installation methods can result in situations
-   where the ADT Installer becomes unreliable and might not install the
-   toolchain.
-
-   If you must mix installation methods, you might avoid problems by
-   deleting ``/var/lib/opkg``, thus purging the ``opkg`` package
-   metadata.
-
--  *Use the ADT installer script:* This method is the recommended way to
-   install the ADT because it automates much of the process for you. For
-   example, you can configure the installation to install the QEMU
-   emulator and the user-space NFS, specify which root filesystem
-   profiles to download, and define the target sysroot location.
-
--  *Use an existing toolchain:* Using this method, you select and
-   download an architecture-specific toolchain installer and then run
-   the script to hand-install the toolchain. If you use this method, you
-   just get the cross-toolchain and QEMU - you do not get any of the
-   other mentioned benefits had you run the ADT Installer script.
-
--  *Use the toolchain from within the Build Directory:* If you already
-   have a :term:`Build Directory`,
-   you can build the cross-toolchain within the directory. However, like
-   the previous method mentioned, you only get the cross-toolchain and
-   QEMU - you do not get any of the other benefits without taking
-   separate steps.
-
-Using the ADT Installer
------------------------
-
-To run the ADT Installer, you need to get the ADT Installer tarball, be
-sure you have the necessary host development packages that support the
-ADT Installer, and then run the ADT Installer Script.
-
-For a list of the host packages needed to support ADT installation and
-use, see the "ADT Installer Extras" lists in the "`Required Packages for
-the Host Development
-System <&YOCTO_DOCS_REF_URL;#required-packages-for-the-host-development-system>`__"
-section of the Yocto Project Reference Manual.
-
-Getting the ADT Installer Tarball
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-The ADT Installer is contained in the ADT Installer tarball. You can get
-the tarball using either of these methods:
-
--  *Download the Tarball:* You can download the tarball from
-   ` <&YOCTO_ADTINSTALLER_DL_URL;>`__ into any directory.
-
--  *Build the Tarball:* You can use
-   :term:`BitBake` to generate the
-   tarball inside an existing :term:`Build Directory`.
-
-   If you use BitBake to generate the ADT Installer tarball, you must
-   ``source`` the environment setup script
-   (````` <&YOCTO_DOCS_REF_URL;#structure-core-script>`__ or
-   ```oe-init-build-env-memres`` <&YOCTO_DOCS_REF_URL;#structure-memres-core-script>`__)
-   located in the Source Directory before running the ``bitbake``
-   command that creates the tarball.
-
-   The following example commands establish the
-   :term:`Source Directory`, check out the
-   current release branch, set up the build environment while also
-   creating the default Build Directory, and run the ``bitbake`` command
-   that results in the tarball
-   ``poky/build/tmp/deploy/sdk/adt_installer.tar.bz2``:
-
-   .. note::
-
-      Before using BitBake to build the ADT tarball, be sure to make
-      sure your
-      local.conf
-      file is properly configured. See the "
-      User Configuration
-      " section in the Yocto Project Reference Manual for general
-      configuration information.
-
-   $ cd ~ $ git clone git://git.yoctoproject.org/poky $ cd poky $ git
-   checkout -b DISTRO_NAME origin/DISTRO_NAME $ source oe-init-build-env $
-   bitbake adt-installer
-
-Configuring and Running the ADT Installer Script
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Before running the ADT Installer script, you need to unpack the tarball.
-You can unpack the tarball in any directory you wish. For example, this
-command copies the ADT Installer tarball from where it was built into
-the home directory and then unpacks the tarball into a top-level
-directory named ``adt-installer``: $ cd ~ $ cp
-poky/build/tmp/deploy/sdk/adt_installer.tar.bz2 $HOME $ tar -xjf
-adt_installer.tar.bz2 Unpacking it creates the directory
-``adt-installer``, which contains the ADT Installer script
-(``adt_installer``) and its configuration file (``adt_installer.conf``).
-
-Before you run the script, however, you should examine the ADT Installer
-configuration file and be sure you are going to get what you want. Your
-configurations determine which kernel and filesystem image are
-downloaded.
-
-The following list describes the configurations you can define for the
-ADT Installer. For configuration values and restrictions, see the
-comments in the ``adt-installer.conf`` file:
-
--  ``YOCTOADT_REPO``: This area includes the IPKG-based packages and the
-   root filesystem upon which the installation is based. If you want to
-   set up your own IPKG repository pointed to by ``YOCTOADT_REPO``, you
-   need to be sure that the directory structure follows the same layout
-   as the reference directory set up at
-   http://adtrepo.yoctoproject.org. Also, your repository needs
-   to be accessible through HTTP.
-
--  ``YOCTOADT_TARGETS``: The machine target architectures for which you
-   want to set up cross-development environments.
-
--  ``YOCTOADT_QEMU``: Indicates whether or not to install the emulator
-   QEMU.
-
--  ``YOCTOADT_NFS_UTIL``: Indicates whether or not to install user-mode
-   NFS. If you plan to use the Eclipse IDE Yocto plug-in against QEMU,
-   you should install NFS.
-
-   .. note::
-
-      To boot QEMU images using our userspace NFS server, you need to be
-      running
-      portmap
-      or
-      rpcbind
-      . If you are running
-      rpcbind
-      , you will also need to add the
-      -i
-      option when
-      rpcbind
-      starts up. Please make sure you understand the security
-      implications of doing this. You might also have to modify your
-      firewall settings to allow NFS booting to work.
-
--  ``YOCTOADT_ROOTFS_``\ arch: The root filesystem images you want to
-   download from the ``YOCTOADT_IPKG_REPO`` repository.
-
--  ``YOCTOADT_TARGET_SYSROOT_IMAGE_``\ arch: The particular root
-   filesystem used to extract and create the target sysroot. The value
-   of this variable must have been specified with
-   ``YOCTOADT_ROOTFS_``\ arch. For example, if you downloaded both
-   ``minimal`` and ``sato-sdk`` images by setting
-   ``YOCTOADT_ROOTFS_``\ arch to "minimal sato-sdk", then
-   ``YOCTOADT_ROOTFS_``\ arch must be set to either "minimal" or
-   "sato-sdk".
-
--  ``YOCTOADT_TARGET_SYSROOT_LOC_``\ arch: The location on the
-   development host where the target sysroot is created.
-
-After you have configured the ``adt_installer.conf`` file, run the
-installer using the following command: $ cd adt-installer $
-./adt_installer Once the installer begins to run, you are asked to enter
-the location for cross-toolchain installation. The default location is
-``/opt/poky/``\ release. After either accepting the default location or
-selecting your own location, you are prompted to run the installation
-script interactively or in silent mode. If you want to closely monitor
-the installation, choose "I" for interactive mode rather than "S" for
-silent mode. Follow the prompts from the script to complete the
-installation.
-
-Once the installation completes, the ADT, which includes the
-cross-toolchain, is installed in the selected installation directory.
-You will notice environment setup files for the cross-toolchain in the
-installation directory, and image tarballs in the ``adt-installer``
-directory according to your installer configurations, and the target
-sysroot located according to the ``YOCTOADT_TARGET_SYSROOT_LOC_``\ arch
-variable also in your configuration file.
-
-.. _using-an-existing-toolchain-tarball:
-
-Using a Cross-Toolchain Tarball
--------------------------------
-
-If you want to simply install a cross-toolchain by hand, you can do so
-by running the toolchain installer. The installer includes the pre-built
-cross-toolchain, the ``runqemu`` script, and support files. If you use
-this method to install the cross-toolchain, you might still need to
-install the target sysroot by installing and extracting it separately.
-For information on how to install the sysroot, see the "`Extracting the
-Root Filesystem <#extracting-the-root-filesystem>`__" section.
-
-Follow these steps:
-
-1. *Get your toolchain installer using one of the following methods:*
-
-   -  Go to ` <&YOCTO_TOOLCHAIN_DL_URL;>`__ and find the folder that
-      matches your host development system (i.e. ``i686`` for 32-bit
-      machines or ``x86_64`` for 64-bit machines).
-
-      Go into that folder and download the toolchain installer whose
-      name includes the appropriate target architecture. The toolchains
-      provided by the Yocto Project are based off of the
-      ``core-image-sato`` image and contain libraries appropriate for
-      developing against that image. For example, if your host
-      development system is a 64-bit x86 system and you are going to use
-      your cross-toolchain for a 32-bit x86 target, go into the
-      ``x86_64`` folder and download the following installer:
-      poky-glibc-x86_64-core-image-sato-i586-toolchain-DISTRO.sh
-
-   -  Build your own toolchain installer. For cases where you cannot use
-      an installer from the download area, you can build your own as
-      described in the "`Optionally Building a Toolchain
-      Installer <#optionally-building-a-toolchain-installer>`__"
-      section.
-
-2. *Once you have the installer, run it to install the toolchain:*
-
-   .. note::
-
-      You must change the permissions on the toolchain installer script
-      so that it is executable.
-
-   The following command shows how to run the installer given a
-   toolchain tarball for a 64-bit x86 development host system and a
-   32-bit x86 target architecture. The example assumes the toolchain
-   installer is located in ``~/Downloads/``. $
-   ~/Downloads/poky-glibc-x86_64-core-image-sato-i586-toolchain-DISTRO.sh
-   The first thing the installer prompts you for is the directory into
-   which you want to install the toolchain. The default directory used
-   is ``/opt/poky/DISTRO``. If you do not have write permissions for the
-   directory into which you are installing the toolchain, the toolchain
-   installer notifies you and exits. Be sure you have write permissions
-   in the directory and run the installer again.
-
-   When the script finishes, the cross-toolchain is installed. You will
-   notice environment setup files for the cross-toolchain in the
-   installation directory.
-
-.. _using-the-toolchain-from-within-the-build-tree:
-
-Using BitBake and the Build Directory
--------------------------------------
-
-A final way of making the cross-toolchain available is to use BitBake to
-generate the toolchain within an existing :term:`Build Directory`.
-This method does
-not install the toolchain into the default ``/opt`` directory. As with
-the previous method, if you need to install the target sysroot, you must
-do that separately as well.
-
-Follow these steps to generate the toolchain into the Build Directory:
-
-1. *Set up the Build Environment:* Source the OpenEmbedded build
-   environment setup script (i.e.
-   ````` <&YOCTO_DOCS_REF_URL;#structure-core-script>`__ or
-   ```oe-init-build-env-memres`` <&YOCTO_DOCS_REF_URL;#structure-memres-core-script>`__)
-   located in the :term:`Source Directory`.
-
-2. *Check your Local Configuration File:* At this point, you should be
-   sure that the :term:`MACHINE`
-   variable in the ``local.conf`` file found in the ``conf`` directory
-   of the Build Directory is set for the target architecture. Comments
-   within the ``local.conf`` file list the values you can use for the
-   ``MACHINE`` variable. If you do not change the ``MACHINE`` variable,
-   the OpenEmbedded build system uses ``qemux86`` as the default target
-   machine when building the cross-toolchain.
-
-   .. note::
-
-      You can populate the Build Directory with the cross-toolchains for
-      more than a single architecture. You just need to edit the
-      MACHINE
-      variable in the
-      local.conf
-      file and re-run the
-      bitbake
-      command.
-
-3. *Make Sure Your Layers are Enabled:* Examine the
-   ``conf/bblayers.conf`` file and make sure that you have enabled all
-   the compatible layers for your target machine. The OpenEmbedded build
-   system needs to be aware of each layer you want included when
-   building images and cross-toolchains. For information on how to
-   enable a layer, see the "`Enabling Your
-   Layer <&YOCTO_DOCS_DEV_URL;#enabling-your-layer>`__" section in the
-   Yocto Project Development Manual.
-
-4. *Generate the Cross-Toolchain:* Run ``bitbake meta-ide-support`` to
-   complete the cross-toolchain generation. Once the ``bitbake`` command
-   finishes, the cross-toolchain is generated and populated within the
-   Build Directory. You will notice environment setup files for the
-   cross-toolchain that contain the string "``environment-setup``" in
-   the Build Directory's ``tmp`` folder.
-
-   Be aware that when you use this method to install the toolchain, you
-   still need to separately extract and install the sysroot filesystem.
-   For information on how to do this, see the "`Extracting the Root
-   Filesystem <#extracting-the-root-filesystem>`__" section.
-
-Setting Up the Cross-Development Environment
-============================================
-
-Before you can develop using the cross-toolchain, you need to set up the
-cross-development environment by sourcing the toolchain's environment
-setup script. If you used the ADT Installer or hand-installed
-cross-toolchain, then you can find this script in the directory you
-chose for installation. For this release, the default installation
-directory is ````. If you installed the toolchain in the
-:term:`Build Directory`, you can find the
-environment setup script for the toolchain in the Build Directory's
-``tmp`` directory.
-
-Be sure to run the environment setup script 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 architecture. For example, the toolchain environment
-setup script for a 64-bit IA-based architecture installed in the default
-installation directory would be the following:
-YOCTO_ADTPATH_DIR/environment-setup-x86_64-poky-linux When you run the
-setup script, many environment variables are defined:
-:term:`SDKTARGETSYSROOT` -
-The path to the sysroot used for cross-compilation
-:term:`PKG_CONFIG_PATH` - The
-path to the target pkg-config files
-:term:`CONFIG_SITE` - A GNU
-autoconf site file preconfigured for the target
-:term:`CC` - The minimal command and
-arguments to run the C compiler
-:term:`CXX` - The minimal command and
-arguments to run the C++ compiler
-:term:`CPP` - The minimal command and
-arguments to run the C preprocessor
-:term:`AS` - The minimal command and
-arguments to run the assembler :term:`LD`
-- The minimal command and arguments to run the linker
-:term:`GDB` - The minimal command and
-arguments to run the GNU Debugger
-:term:`STRIP` - The minimal command and
-arguments to run 'strip', which strips symbols
-:term:`RANLIB` - The minimal command
-and arguments to run 'ranlib'
-:term:`OBJCOPY` - The minimal command
-and arguments to run 'objcopy'
-:term:`OBJDUMP` - The minimal command
-and arguments to run 'objdump' :term:`AR`
-- The minimal command and arguments to run 'ar'
-:term:`NM` - The minimal command and
-arguments to run 'nm'
-:term:`TARGET_PREFIX` - The
-toolchain binary prefix for the target tools
-:term:`CROSS_COMPILE` - The
-toolchain binary prefix for the target tools
-:term:`CONFIGURE_FLAGS` - The
-minimal arguments for GNU configure
-:term:`CFLAGS` - Suggested C flags
-:term:`CXXFLAGS` - Suggested C++
-flags :term:`LDFLAGS` - Suggested
-linker flags when you use CC to link
-:term:`CPPFLAGS` - Suggested
-preprocessor flags
-
-Securing Kernel and Filesystem Images
-=====================================
-
-You will need to have a kernel and filesystem image to boot using your
-hardware or the QEMU emulator. Furthermore, if you plan on booting your
-image using NFS or you want to use the root filesystem as the target
-sysroot, you need to extract the root filesystem.
-
-Getting the Images
-------------------
-
-To get the kernel and filesystem images, you either have to build them
-or download pre-built versions. For an example of how to build these
-images, see the "`Buiding
-Images <&YOCTO_DOCS_QS_URL;#qs-buiding-images>`__" section of the Yocto
-Project Quick Start. For an example of downloading pre-build versions,
-see the "`Example Using Pre-Built Binaries and
-QEMU <#using-pre-built>`__" section.
-
-The Yocto Project ships basic kernel and filesystem images for several
-architectures (``x86``, ``x86-64``, ``mips``, ``powerpc``, and ``arm``)
-that you can use unaltered in the QEMU emulator. These kernel images
-reside in the release area - ` <&YOCTO_MACHINES_DL_URL;>`__ and are
-ideal for experimentation using Yocto Project. For information on the
-image types you can build using the OpenEmbedded build system, see the
-":ref:`ref-manual/ref-images:Images`" chapter in the Yocto
-Project Reference Manual.
-
-If you are planning on developing against your image and you are not
-building or using one of the Yocto Project development images (e.g.
-``core-image-*-dev``), you must be sure to include the development
-packages as part of your image recipe.
-
-If you plan on remotely deploying and debugging your application from
-within the Eclipse IDE, you must have an image that contains the Yocto
-Target Communication Framework (TCF) agent (``tcf-agent``). You can do
-this by including the ``eclipse-debug`` image feature.
-
-.. note::
-
-   See the "
-   Image Features
-   " section in the Yocto Project Reference Manual for information on
-   image features.
-
-To include the ``eclipse-debug`` image feature, modify your
-``local.conf`` file in the :term:`Build Directory`
-so that the
-:term:`EXTRA_IMAGE_FEATURES`
-variable includes the "eclipse-debug" feature. After modifying the
-configuration file, you can rebuild the image. Once the image is
-rebuilt, the ``tcf-agent`` will be included in the image and is launched
-automatically after the boot.
-
-Extracting the Root Filesystem
-------------------------------
-
-If you install your toolchain by hand or build it using BitBake and you
-need a root filesystem, you need to extract it separately. If you use
-the ADT Installer to install the ADT, the root filesystem is
-automatically extracted and installed.
-
-Here are some cases where you need to extract the root filesystem:
-
--  You want to boot the image using NFS.
-
--  You want to use the root filesystem as the target sysroot. For
-   example, the Eclipse IDE environment with the Eclipse Yocto Plug-in
-   installed allows you to use QEMU to boot under NFS.
-
--  You want to develop your target application using the root filesystem
-   as the target sysroot.
-
-To extract the root filesystem, first ``source`` the cross-development
-environment setup script to establish necessary environment variables.
-If you built the toolchain in the Build Directory, you will find the
-toolchain environment script in the ``tmp`` directory. If you installed
-the toolchain by hand, the environment setup script is located in
-``/opt/poky/DISTRO``.
-
-After sourcing the environment script, use the ``runqemu-extract-sdk``
-command and provide the filesystem image.
-
-Following is an example. The second command sets up the environment. In
-this case, the setup script is located in the ``/opt/poky/DISTRO``
-directory. The third command extracts the root filesystem from a
-previously built filesystem that is located in the ``~/Downloads``
-directory. Furthermore, this command extracts the root filesystem into
-the ``qemux86-sato`` directory: $ cd ~ $ source
-/opt/poky/DISTRO/environment-setup-i586-poky-linux $ runqemu-extract-sdk
-\\ ~/Downloads/core-image-sato-sdk-qemux86-2011091411831.rootfs.tar.bz2
-\\ $HOME/qemux86-sato You could now point to the target sysroot at
-``qemux86-sato``.
-
-Optionally Building a Toolchain Installer
-=========================================
-
-As an alternative to locating and downloading a toolchain installer, you
-can build the toolchain installer if you have a :term:`Build Directory`.
-
-.. note::
-
-   Although not the preferred method, it is also possible to use
-   bitbake meta-toolchain
-   to build the toolchain installer. If you do use this method, you must
-   separately install and extract the target sysroot. For information on
-   how to install the sysroot, see the "
-   Extracting the Root Filesystem
-   " section.
-
-To build the toolchain installer and populate the SDK image, use the
-following command: $ bitbake image -c populate_sdk The command results
-in a toolchain installer that contains the sysroot that matches your
-target root filesystem.
-
-Another powerful feature is that the toolchain is 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`` archive.
-
-Another feature is that only one set of cross-canadian toolchain
-binaries are produced per 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 a sysroot is still
-needed for every target since those binaries are target-specific.
-
-Remember, before using any BitBake command, you must source the build
-environment setup script (i.e.
-````` <&YOCTO_DOCS_REF_URL;#structure-core-script>`__ or
-```oe-init-build-env-memres`` <&YOCTO_DOCS_REF_URL;#structure-memres-core-script>`__)
-located in the Source Directory and you must make sure your
-``conf/local.conf`` variables are correct. In particular, you need to be
-sure the :term:`MACHINE` variable
-matches the architecture for which you are building and that the
-:term:`SDKMACHINE` variable 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 machine).
-
-When the ``bitbake`` command completes, the toolchain installer will be
-in ``tmp/deploy/sdk`` in the Build Directory.
-
-.. note::
-
-   By default, this toolchain does not build static binaries. If you
-   want to use the toolchain to build these types of libraries, you need
-   to be sure your image has the appropriate static development
-   libraries. Use the
-   IMAGE_INSTALL
-   variable inside your
-   local.conf
-   file to install the appropriate library packages. Following is an
-   example using
-   glibc
-   static development libraries:
-   ::
-
-           IMAGE_INSTALL_append = " glibc-staticdev"
-                  
-
-Optionally Using an External Toolchain
-======================================
-
-You might want to use an external toolchain as part of your development.
-If this is the case, the fundamental steps you need to accomplish are as
-follows:
-
--  Understand where the installed toolchain resides. For cases where you
-   need to build the external toolchain, you would need to take separate
-   steps to build and install the toolchain.
-
--  Make sure you add the layer that contains the toolchain to your
-   ``bblayers.conf`` file through the
-   :term:`BBLAYERS` variable.
-
--  Set the
-   :term:`EXTERNAL_TOOLCHAIN`
-   variable in your ``local.conf`` file to the location in which you
-   installed the toolchain.
-
-A good example of an external toolchain used with the Yocto Project is
-Mentor Graphics Sourcery G++ Toolchain. You can see information on how
-to use that particular layer in the ``README`` file at
-http://github.com/MentorEmbedded/meta-sourcery/. You can find
-further information by reading about the
-:term:`TCMODE` variable in the Yocto
-Project Reference Manual's variable glossary.
-
-.. _using-pre-built:
-
-Example Using Pre-Built Binaries and QEMU
-=========================================
-
-If hardware, libraries and services are stable, you can get started by
-using a pre-built binary of the filesystem image, kernel, and toolchain
-and run it using the QEMU emulator. This scenario is useful for
-developing application software.
-
-|Using a Pre-Built Image|
-
-For this scenario, you need to do several things:
-
--  Install the appropriate stand-alone toolchain tarball.
-
--  Download the pre-built image that will boot with QEMU. You need to be
-   sure to get the QEMU image that matches your target machine's
-   architecture (e.g. x86, ARM, etc.).
-
--  Download the filesystem image for your target machine's architecture.
-
--  Set up the environment to emulate the hardware and then start the
-   QEMU emulator.
-
-Installing the Toolchain
-------------------------
-
-You can download a tarball installer, which includes the pre-built
-toolchain, the ``runqemu`` script, and support files from the
-appropriate directory under ` <&YOCTO_TOOLCHAIN_DL_URL;>`__. Toolchains
-are available for 32-bit and 64-bit x86 development systems from the
-``i686`` and ``x86_64`` directories, respectively. The toolchains the
-Yocto Project provides are based off the ``core-image-sato`` image and
-contain libraries appropriate for developing against that image. Each
-type of development system supports five or more target architectures.
-
-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 a string representing the image you wish to
-                   develop a Software Development Toolkit (SDK) for use against.
-                   The Yocto Project builds toolchain installers using the
-                   following BitBake command:
-
-                       bitbake core-image-sato -c populate_sdk
-
-            arch is a string representing the tuned target architecture:
-
-                       i586, x86_64, powerpc, mips, armv7a or armv5te
-
-            release_version is a string representing the release number of the
-                   Yocto Project:
-
-                       DISTRO, DISTRO+snapshot
-               
-
-For example, the following toolchain installer is for a 64-bit
-development host system and a i586-tuned target architecture based off
-the SDK for ``core-image-sato``:
-poky-glibc-x86_64-core-image-sato-i586-toolchain-DISTRO.sh
-
-Toolchains are self-contained and by default are installed into
-``/opt/poky``. However, when you run the toolchain installer, you can
-choose an installation directory.
-
-The following command shows how to run the installer given a toolchain
-tarball for a 64-bit x86 development host system and a 32-bit x86 target
-architecture. You must change the permissions on the toolchain installer
-script so that it is executable.
-
-The example assumes the toolchain installer is located in
-``~/Downloads/``.
-
-.. note::
-
-   If you do not have write permissions for the directory into which you
-   are installing the toolchain, the toolchain installer notifies you
-   and exits. Be sure you have write permissions in the directory and
-   run the installer again.
-
-$ ~/Downloads/poky-glibc-x86_64-core-image-sato-i586-toolchain-DISTRO.sh
-
-For more information on how to install tarballs, see the "`Using a
-Cross-Toolchain
-Tarball <&YOCTO_DOCS_ADT_URL;#using-an-existing-toolchain-tarball>`__"
-and "`Using BitBake and the Build
-Directory <&YOCTO_DOCS_ADT_URL;#using-the-toolchain-from-within-the-build-tree>`__"
-sections in the Yocto Project Application Developer's Guide.
-
-Downloading the Pre-Built Linux Kernel
---------------------------------------
-
-You can download the pre-built Linux kernel suitable for running in the
-QEMU emulator from ` <&YOCTO_QEMU_DL_URL;>`__. Be sure to use the kernel
-that matches the architecture you want to simulate. Download areas exist
-for the five supported machine architectures: ``qemuarm``, ``qemumips``,
-``qemuppc``, ``qemux86``, and ``qemux86-64``.
-
-Most kernel files have one of the following forms: \*zImage-qemuarch.bin
-vmlinux-qemuarch.bin Where: arch is a string representing the target
-architecture: x86, x86-64, ppc, mips, or arm.
-
-You can learn more about downloading a Yocto Project kernel in the
-"`Yocto Project Kernel <&YOCTO_DOCS_DEV_URL;#local-kernel-files>`__"
-bulleted item in the Yocto Project Development Manual.
-
-Downloading the Filesystem
---------------------------
-
-You can also download the filesystem image suitable for your target
-architecture from ` <&YOCTO_QEMU_DL_URL;>`__. Again, be sure to use the
-filesystem that matches the architecture you want to simulate.
-
-The filesystem image has two tarball forms: ``ext3`` and ``tar``. You
-must use the ``ext3`` form when booting an image using the QEMU
-emulator. The ``tar`` form can be flattened out in your host development
-system and used for build purposes with the Yocto Project.
-core-image-profile-qemuarch.ext3 core-image-profile-qemuarch.tar.bz2
-Where: profile is the filesystem image's profile: lsb, lsb-dev, lsb-sdk,
-lsb-qt3, minimal, minimal-dev, sato, sato-dev, or sato-sdk. For
-information on these types of image profiles, see the
-":ref:`ref-manual/ref-images:Images`" chapter in the Yocto
-Project Reference Manual. arch is a string representing the target
-architecture: x86, x86-64, ppc, mips, or arm.
-
-Setting Up the Environment and Starting the QEMU Emulator
----------------------------------------------------------
-
-Before you start the QEMU emulator, you need to set up the emulation
-environment. The following command form sets up the emulation
-environment. $ source
-YOCTO_ADTPATH_DIR/environment-setup-arch-poky-linux-if Where: arch is a
-string representing the target architecture: i586, x86_64, ppc603e,
-mips, or armv5te. if is a string representing an embedded application
-binary interface. Not all setup scripts include this string.
-
-Finally, this command form invokes the QEMU emulator $ runqemu qemuarch
-kernel-image filesystem-image Where: qemuarch is a string representing
-the target architecture: qemux86, qemux86-64, qemuppc, qemumips, or
-qemuarm. kernel-image is the architecture-specific kernel image.
-filesystem-image is the .ext3 filesystem image.
-
-Continuing with the example, the following two commands setup the
-emulation environment and launch QEMU. This example assumes the root
-filesystem (``.ext3`` file) and the pre-built kernel image file both
-reside in your home directory. The kernel and filesystem are for a
-32-bit target architecture. $ cd $HOME $ source
-YOCTO_ADTPATH_DIR/environment-setup-i586-poky-linux $ runqemu qemux86
-bzImage-qemux86.bin \\ core-image-sato-qemux86.ext3
-
-The environment in which QEMU launches varies depending on the
-filesystem image and on the target architecture. For example, if you
-source the environment for the ARM target architecture and then boot the
-minimal QEMU image, the emulator comes up in a new shell in command-line
-mode. However, if you boot the SDK image, QEMU comes up with a GUI.
-
-.. note::
-
-   Booting the PPC image results in QEMU launching in the same shell in
-   command-line mode.
-
-.. |Using a Pre-Built Image| image:: figures/using-a-pre-built-image.png

documentation/conf.py

@@ -16,7 +16,7 @@ import os
 import sys
 import datetime
 
-current_version = "dev"
+current_version = "3.2.1"
 
 # String used in sidebar
 version = 'Version: ' + current_version
@@ -53,8 +53,7 @@ templates_path = ['_templates']
 # List of patterns, relative to source directory, that match files and
 # directories to ignore when looking for source files.
 # This pattern also affects html_static_path and html_extra_path.
-exclude_patterns = ['_build', 'Thumbs.db', '.DS_Store', 'boilerplate.rst',
-                    'adt-manual/*.rst']
+exclude_patterns = ['_build', 'Thumbs.db', '.DS_Store', 'boilerplate.rst']
 
 # master document name. The default changed from contents to index. so better
 # set it ourselves.
@@ -83,7 +82,7 @@ extlinks = {
 
 # Intersphinx config to use cross reference with Bitbake user manual
 intersphinx_mapping = {
-    'bitbake': ('https://docs.yoctoproject.org/bitbake/', None)
+    'bitbake': ('https://docs.yoctoproject.org/bitbake/1.48', None)
 }
 
 # -- Options for HTML output -------------------------------------------------

documentation/dev-manual/dev-manual-common-tasks.rst

@@ -2602,6 +2602,13 @@ doing the following:
    where you have installed them and whether those files are in
    different locations than the defaults.
 
+.. note::
+
+  If image prelinking is enabled (e.g. "image-prelink" is in :term:`USER_CLASSES`
+  which it is by default), prelink will change the binaries in the generated images
+  and this often catches people out. Remove that class to ensure binaries are
+  preserved exactly if that is necessary.
+
 Following Recipe Style Guidelines
 ---------------------------------
 
@@ -11493,7 +11500,7 @@ this function, you have to follow the following steps:
    Directory`. The following is an example showing how to generate spdx files
    during bitbake using the fossology-python.bbclass::
 
-      # Selet fossology-python.bbclass.
+      # Select fossology-python.bbclass.
       INHERIT += "fossology-python"
       # For fossology-python.bbclass, TOKEN is necessary, so, after setup a
       # Fossology server, you have to create a token.
@@ -11503,10 +11510,11 @@ this function, you have to follow the following steps:
       # If you want to upload the source code to a special folder:
       FOLDER_NAME = "xxxx" //Optional
       # If you don't want to put spdx files in tmp/deploy/spdx, you can enable:
-      SPDX_DEPLOY_DIR = "${DeployDir}" //Optional
+      SPDX_DEPLOY_DIR = "${DEPLOY_DIR}" //Optional
+
+For more usage information refer to :yocto_git:`the meta-spdxscanner repository
+</cgit/cgit.cgi/meta-spdxscanner/>`.
 
-For more usage information on meta-spdxscanner, refer to the repsoitory which you can find at:
-https://git.yoctoproject.org/cgit/cgit.cgi/meta-spdxscanner/.
 
 Copying Licenses that Do Not Exist
 ----------------------------------

documentation/kernel-dev/kernel-dev-advanced.rst

@@ -44,9 +44,7 @@ linux-yocto recipe.
 .. note::
 
    A Linux kernel recipe that contains kernel Metadata (e.g. inherits
-   from the
-   linux-yocto.inc
-   file) is said to be a "linux-yocto style" recipe.
+   from the ``linux-yocto.inc`` file) is said to be a "linux-yocto style" recipe.
 
 Every linux-yocto style recipe must define the
 :term:`KMACHINE` variable. This
@@ -70,12 +68,8 @@ to indicate the branch.
 
 .. note::
 
-   You can use the
-   KBRANCH
-   value to define an alternate branch typically with a machine override
-   as shown here from the
-   meta-yocto-bsp
-   layer:
+   You can use the ``KBRANCH`` value to define an alternate branch typically
+   with a machine override as shown here from the ``meta-yocto-bsp`` layer:
    ::
 
            KBRANCH_edgerouter = "standard/edgerouter"
@@ -101,7 +95,7 @@ section for more information on kernel types.
 During the build, the kern-tools search for the BSP description file
 that most closely matches the ``KMACHINE`` and ``LINUX_KERNEL_TYPE``
 variables passed in from the recipe. The tools use the first BSP
-description it finds that match both variables. If the tools cannot find
+description they find that matches both variables. If the tools cannot find
 a match, they issue a warning.
 
 The tools first search for the ``KMACHINE`` and then for the
@@ -251,8 +245,7 @@ two files: ``smp.scc`` and ``smp.cfg``. You can find these files in the
       CONFIG_X86_BIGSMP=y
 
 You can find general information on configuration
-fragment files in the "`Creating Configuration
-Fragments <#creating-config-fragments>`__" section.
+fragment files in the ":ref:`creating-config-fragments`" section.
 
 Within the ``smp.scc`` file, the
 :term:`KFEATURE_DESCRIPTION`
@@ -269,13 +262,12 @@ non-hardware fragment.
 
 .. note::
 
-   The description file can include multiple
-   kconf
-   statements, one per fragment.
+   The description file can include multiple ``kconf`` statements, one per
+   fragment.
 
-As described in the "`Validating
-Configuration <#validating-configuration>`__" section, you can use the
-following BitBake command to audit your configuration:
+As described in the
+":ref:`kernel-dev/kernel-dev-common:validating configuration`" section, you can
+use the following BitBake command to audit your configuration:
 ::
 
    $ bitbake linux-yocto -c kernel_configcheck -f
@@ -335,10 +327,8 @@ for the five patches in the directory.
 
 You can create a typical ``.patch`` file using ``diff -Nurp`` or
 ``git format-patch`` commands. For information on how to create patches,
-see the "`Using ``devtool`` to Patch the
-Kernel <#using-devtool-to-patch-the-kernel>`__" and "`Using Traditional
-Kernel Development to Patch the
-Kernel <#using-traditional-kernel-development-to-patch-the-kernel>`__"
+see the ":ref:`kernel-dev/kernel-dev-common:using \`\`devtool\`\` to patch the kernel`"
+and ":ref:`kernel-dev/kernel-dev-common:using traditional kernel development to patch the kernel`"
 sections.
 
 Features
@@ -397,15 +387,11 @@ type as follows:
 
 .. note::
 
-   You can find kernel recipes in the
-   meta/recipes-kernel/linux
-   directory of the
-   Source Directory
-   (e.g.
-   poky/meta/recipes-kernel/linux/linux-yocto_4.12.bb
-   ). See the "
-   Using Kernel Metadata in a Recipe
-   " section for more information.
+   You can find kernel recipes in the ``meta/recipes-kernel/linux`` directory
+   of the :ref:`overview-manual/overview-manual-development-environment:yocto project source repositories`
+   (e.g. ``poky/meta/recipes-kernel/linux/linux-yocto_4.12.bb``). See the
+   ":ref:`kernel-dev/kernel-dev-advanced:using kernel metadata in a recipe`"
+   section for more information.
 
 Three kernel types ("standard", "tiny", and "preempt-rt") are supported
 for Linux Yocto kernels:
@@ -466,16 +452,11 @@ and ``patch`` commands, respectively.
 
 .. note::
 
-   It is not strictly necessary to create a kernel type
-   .scc
+   It is not strictly necessary to create a kernel type ``.scc``
    file. The Board Support Package (BSP) file can implicitly define the
-   kernel type using a
-   define
-   KTYPE
-   myktype
-   line. See the "
-   BSP Descriptions
-   " section for more information.
+   kernel type using a ``define`` :term:`KTYPE` ``myktype`` line. See the
+   ":ref:`kernel-dev/kernel-dev-advanced:bsp descriptions`" section for more
+   information.
 
 BSP Descriptions
 ----------------
@@ -488,13 +469,9 @@ supported kernel type.
 .. note::
 
    For BSPs supported by the Yocto Project, the BSP description files
-   are located in the
-   bsp
-   directory of the
-   yocto-kernel-cache
+   are located in the ``bsp`` directory of the ``yocto-kernel-cache``
    repository organized under the "Yocto Linux Kernel" heading in the
-   Yocto Project Source Repositories
-   .
+   :yocto_git:`Yocto Project Source Repositories </>`.
 
 This section overviews the BSP description structure, the aggregation
 concepts, and presents a detailed example using a BSP supported by the
@@ -571,7 +548,7 @@ policy. See the "`Kernel Types <#kernel-types>`__" section for more
 information.
 
 To aggregate common configurations and features specific to the kernel
-for mybsp, use the following:
+for `mybsp`, use the following:
 ::
 
    include mybsp.scc
@@ -582,8 +559,7 @@ You can see that in the BeagleBone example with the following:
    include beaglebone.scc
 
 For information on how to break a complete ``.config`` file into the various
-configuration fragments, see the "`Creating Configuration
-Fragments <#creating-config-fragments>`__" section.
+configuration fragments, see the ":ref:`creating-config-fragments`" section.
 
 Finally, if you have any configurations specific to the hardware that
 are not in a ``*.scc`` file, you can include them as follows:
@@ -653,7 +629,7 @@ found on the machine. This ``minnow.scc`` description file is then
 included in each of the three "minnow" description files for the
 supported kernel types (i.e. "standard", "preempt-rt", and "tiny").
 Consider the "minnow" description for the "standard" kernel type (i.e.
-``minnow-standard.scc``:
+``minnow-standard.scc``):
 ::
 
    define KMACHINE minnow
@@ -725,8 +701,8 @@ others, the recipe-space method is recommended. This method is also a
 good approach if you are working with Linux kernel sources you do not
 control or if you just do not want to maintain a Linux kernel Git
 repository on your own. For partial information on how you can define
-kernel Metadata in the recipe-space, see the "`Modifying an Existing
-Recipe <#modifying-an-existing-recipe>`__" section.
+kernel Metadata in the recipe-space, see the
+":ref:`kernel-dev/kernel-dev-common:modifying an existing recipe`" section.
 
 Conversely, if you are actively developing a kernel and are already
 maintaining a Linux kernel Git repository of your own, you might find it
@@ -746,8 +722,8 @@ modifying
 ``oe-core/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb`` to
 a recipe in your layer, ``FILESEXTRAPATHS`` is typically set to
 ``${``\ :term:`THISDIR`\ ``}/${``\ :term:`PN`\ ``}``.
-See the "`Modifying an Existing
-Recipe <#modifying-an-existing-recipe>`__" section for more information.
+See the ":ref:`kernel-dev/kernel-dev-common:modifying an existing recipe`"
+section for more information.
 
 Here is an example that shows a trivial tree of kernel Metadata stored
 in recipe-space within a BSP layer:
@@ -849,7 +825,7 @@ best for your development model.
 Encapsulating Patches
 ---------------------
 
-if you are reusing patches from an external tree and are not working on
+If you are reusing patches from an external tree and are not working on
 the patches, you might find the encapsulated feature to be appropriate.
 Given this scenario, you do not need to create any branches in the
 source repository. Rather, you just take the static patches you need and
@@ -881,6 +857,7 @@ new branch as the ``KBRANCH`` to use for the board as follows:
 
 Another method is to use the ``branch`` command in the BSP
 description:
+::
 
    mybsp.scc:
       define KMACHINE mybsp
@@ -902,7 +879,7 @@ repositories use:
 If you had two kernel types, "standard" and "small" for instance, three
 machines, and common as ``mydir``, the branches in your Git repository
 might look like this:
-:
+::
 
    mydir/base
    mydir/standard/base
@@ -922,11 +899,8 @@ appropriate for the other branches.
 
    The "base" branches are an artifact of the way Git manages its data
    internally on the filesystem: Git will not allow you to use
-   mydir/standard
-   and
-   mydir/standard/machine_a
-   because it would have to create a file and a directory named
-   "standard".
+   ``mydir/standard`` and ``mydir/standard/machine_a`` because it would have to
+   create a file and a directory named "standard".
 
 Feature Branches
 ----------------

documentation/kernel-dev/kernel-dev-common.rst

@@ -33,12 +33,10 @@ Source Directory.
 
    Be sure you check out the appropriate development branch or you
    create your local branch by checking out a specific tag to get the
-   desired version of Yocto Project. See the "
-   Checking Out by Branch in Poky
-   " and "
-   Checking Out by Tag in Poky
-   " sections in the Yocto Project Development Tasks Manual for more
-   information.
+   desired version of Yocto Project. See the
+   ":ref:`dev-manual/dev-manual-start:checking out by branch in poky`" and
+   ":ref:`dev-manual/dev-manual-start:checking out by tag in poky`"
+   sections in the Yocto Project Development Tasks Manual for more information.
 
 Kernel development is best accomplished using
 :ref:`devtool <sdk-manual/sdk-extensible:using \`\`devtool\`\` in your sdk workflow>`
@@ -50,8 +48,8 @@ Getting Ready to Develop Using ``devtool``
 
 Follow these steps to prepare to update the kernel image using
 ``devtool``. Completing this procedure leaves you with a clean kernel
-image and ready to make modifications as described in the "
-:ref:`kernel-dev/kernel-dev-common:using \`\`devtool\`\` to patch the kernel`"
+image and ready to make modifications as described in the
+":ref:`kernel-dev/kernel-dev-common:using \`\`devtool\`\` to patch the kernel`"
 section:
 
 1. *Initialize the BitBake Environment:* Before building an extensible
@@ -65,10 +63,8 @@ section:
    .. note::
 
       The previous commands assume the
-      Source Repositories
-      (i.e.
-      poky
-      ) have been cloned using Git and the local repository is named
+      :ref:`overview-manual/overview-manual-development-environment:yocto project source repositories`
+      (i.e. ``poky``) have been cloned using Git and the local repository is named
       "poky".
 
 2. *Prepare Your local.conf File:* By default, the
@@ -107,18 +103,15 @@ section:
    .. note::
 
       For background information on working with common and BSP layers,
-      see the "
-      Understanding and Creating Layers
-      " section in the Yocto Project Development Tasks Manual and the "
-      BSP Layers
-      " section in the Yocto Project Board Support (BSP) Developer's
-      Guide, respectively. For information on how to use the
-      bitbake-layers create-layer
-      command to quickly set up a layer, see the "
-      Creating a General Layer Using the
-      bitbake-layers
-      Script
-      " section in the Yocto Project Development Tasks Manual.
+      see the
+      ":ref:`dev-manual/dev-manual-common-tasks:understanding and creating layers`"
+      section in the Yocto Project Development Tasks Manual and the
+      ":ref:`bsp-guide/bsp:bsp layers`" section in the Yocto Project Board
+      Support (BSP) Developer's Guide, respectively. For information on how to
+      use the ``bitbake-layers create-layer`` command to quickly set up a layer,
+      see the
+      ":ref:`dev-manual/dev-manual-common-tasks:creating a general layer using the \`\`bitbake-layers\`\` script`"
+      section in the Yocto Project Development Tasks Manual.
 
 4. *Inform the BitBake Build Environment About Your Layer:* As directed
    when you created your layer, you need to add the layer to the
@@ -141,9 +134,12 @@ section:
    Once
    the build finishes, you can find the SDK installer file (i.e.
    ``*.sh`` file) in the following directory:
-   ~/poky/build/tmp/deploy/sdk For this example, the installer file is
-   named
-   ``poky-glibc-x86_64-core-image-minimal-i586-toolchain-ext-DISTRO.sh``
+   ::
+
+      ~/poky/build/tmp/deploy/sdk
+
+   For this example, the installer file is named
+   ``poky-glibc-x86_64-core-image-minimal-i586-toolchain-ext-DISTRO.sh``.
 
 6. *Install the Extensible SDK:* Use the following command to install
    the SDK. For this example, install the SDK in the default
@@ -211,7 +207,7 @@ section:
    building for actual hardware and not for emulation, you could flash
    the image to a USB stick on ``/dev/sdd`` and boot your device. For an
    example that uses a Minnowboard, see the
-   `TipsAndTricks/KernelDevelopmentWithEsdk <https://wiki.yoctoproject.org/wiki/TipsAndTricks/KernelDevelopmentWithEsdk>`__
+   :yocto_wiki:`TipsAndTricks/KernelDevelopmentWithEsdk </wiki/TipsAndTricks/KernelDevelopmentWithEsdk>`
    Wiki page.
 
 At this point you have set up to start making modifications to the
@@ -247,16 +243,14 @@ section:
       $ cd ~/poky
       $ git branch
       master
-      * &DISTRO_NAME;
+      * &DISTRO_NAME_NO_CAP;
       $ source oe-init-build-env
 
    .. note::
 
       The previous commands assume the
-      Source Repositories
-      (i.e.
-      poky
-      ) have been cloned using Git and the local repository is named
+      :ref:`overview-manual/overview-manual-development-environment:yocto project source repositories`
+      (i.e. ``poky``) have been cloned using Git and the local repository is named
       "poky".
 
 2. *Prepare Your local.conf File:* By default, the
@@ -294,18 +288,15 @@ section:
    .. note::
 
       For background information on working with common and BSP layers,
-      see the "
-      Understanding and Creating Layers
-      " section in the Yocto Project Development Tasks Manual and the "
-      BSP Layers
-      " section in the Yocto Project Board Support (BSP) Developer's
-      Guide, respectively. For information on how to use the
-      bitbake-layers create-layer
-      command to quickly set up a layer, see the "
-      Creating a General Layer Using the
-      bitbake-layers
-      Script
-      " section in the Yocto Project Development Tasks Manual.
+      see the
+      ":ref:`dev-manual/dev-manual-common-tasks:understanding and creating layers`"
+      section in the Yocto Project Development Tasks Manual and the
+      ":ref:`bsp-guide/bsp:bsp layers`" section in the Yocto Project Board
+      Support (BSP) Developer's Guide, respectively. For information on how to
+      use the ``bitbake-layers create-layer`` command to quickly set up a layer,
+      see the
+      ":ref:`dev-manual/dev-manual-common-tasks:creating a general layer using the \`\`bitbake-layers\`\` script`"
+      section in the Yocto Project Development Tasks Manual.
 
 4. *Inform the BitBake Build Environment About Your Layer:* As directed
    when you created your layer, you need to add the layer to the
@@ -334,12 +325,10 @@ section:
 
    .. note::
 
-      The
-      linux-yocto-4.12
-      kernel can be used with the Yocto Project 2.4 release and forward.
-      You cannot use the
-      linux-yocto-4.12
-      kernel with releases prior to Yocto Project 2.4:
+      The ``linux-yocto-4.12`` kernel can be used with the Yocto Project 2.4
+      release and forward.
+      You cannot use the ``linux-yocto-4.12`` kernel with releases prior to
+      Yocto Project 2.4.
 
    ::
 
@@ -351,7 +340,7 @@ section:
       remote: Total 6097195 (delta 5152604), reused 6096847 (delta 5152256)
       Receiving objects: 100% (6097195/6097195), 1.24 GiB | 7.81 MiB/s, done.
       Resolving deltas: 100% (5152604/5152604), done. Checking connectivity... done.
-      Checking out   files: 100% (59846/59846), done.
+      Checking out files: 100% (59846/59846), done.
 
 6. *Create a Local Copy of the Kernel Cache Git Repository:* For
    simplicity, it is recommended that you create your copy of the kernel
@@ -395,13 +384,10 @@ section in the Yocto Project Development Tasks Manual.
 .. note::
 
    The Yocto Project comes with many tools that simplify tasks you need
-   to perform. One such tool is the
-   bitbake-layers create-layer
-   command, which simplifies creating a new layer. See the "
-   Creating a General Layer Using the
-   bitbake-layers
-   Script
-   " section in the Yocto Project Development Tasks Manual for
+   to perform. One such tool is the ``bitbake-layers create-layer``
+   command, which simplifies creating a new layer. See the
+   ":ref:`dev-manual/dev-manual-common-tasks:creating a general layer using the \`\`bitbake-layers\`\` script`"
+   section in the Yocto Project Development Tasks Manual for
    information on how to use this script to quick set up a new layer.
 
 To better understand the layer you create for kernel development, the
@@ -450,9 +436,9 @@ home directory:
 
       FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
 
-      SRC_URI_append = " file://patch-file-one"
-      SRC_URI_append = " file://patch-file-two"
-      SRC_URI_append = " file://patch-file-three"
+      SRC_URI_append = " file://patch-file-one.patch"
+      SRC_URI_append = " file://patch-file-two.patch"
+      SRC_URI_append = " file://patch-file-three.patch"
 
    The :term:`FILESEXTRAPATHS` and :term:`SRC_URI` statements
    enable the OpenEmbedded build system to find patch files. For more
@@ -471,11 +457,11 @@ the :term:`Source Directory` in
 
 Modifying an existing recipe can consist of the following:
 
--  Creating the append file
+- :ref:`kernel-dev/kernel-dev-common:creating the append file`
 
--  Applying patches
+- :ref:`kernel-dev/kernel-dev-common:applying patches`
 
--  Changing the configuration
+- :ref:`kernel-dev/kernel-dev-common:changing the configuration`
 
 Before modifying an existing recipe, be sure that you have created a
 minimal, custom layer from which you can work. See the "`Creating and
@@ -490,7 +476,8 @@ based on the linux-yocto recipe you are using. For example, if you are
 modifying the ``meta/recipes-kernel/linux/linux-yocto_4.12.bb`` recipe,
 the append file will typically be located as follows within your custom
 layer:
-::
+
+.. code-block:: none
 
    your-layer/recipes-kernel/linux/linux-yocto_4.12.bbappend
 
@@ -515,13 +502,12 @@ your layer in the following area:
 .. note::
 
    If you are working on a new machine Board Support Package (BSP), be
-   sure to refer to the
-   Yocto Project Board Support Package (BSP) Developer's Guide
-   .
+   sure to refer to the :doc:`../bsp-guide/bsp-guide`.
 
 As an example, consider the following append file used by the BSPs in
 ``meta-yocto-bsp``:
-::
+
+.. code-block:: none
 
    meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.12.bbappend
 
@@ -689,17 +675,13 @@ created to hold the configuration changes.
 
 .. note::
 
-   The build system applies the configurations from the
-   defconfig
+   The build system applies the configurations from the ``defconfig``
    file before applying any subsequent configuration fragments. The
    final kernel configuration is a combination of the configurations in
-   the
-   defconfig
-   file and any configuration fragments you provide. You need to realize
-   that if you have any configuration fragments, the build system
-   applies these on top of and after applying the existing
-   defconfig
-   file configurations.
+   the ``defconfig`` file and any configuration fragments you provide. You need
+   to realize that if you have any configuration fragments, the build system
+   applies these on top of and after applying the existing ``defconfig`` file
+   configurations.
 
 Generally speaking, the preferred approach is to determine the
 incremental change you want to make and add that as a configuration
@@ -755,7 +737,7 @@ To specify an "in-tree" ``defconfig`` file, use the following statement
 form:
 ::
 
-   KBUILD_DEFCONFIG_KMACHINE ?= defconfig_file
+   KBUILD_DEFCONFIG_KMACHINE ?= "defconfig_file"
 
 Here is an example
 that assigns the ``KBUILD_DEFCONFIG`` variable based on "raspberrypi2"
@@ -768,7 +750,7 @@ a Raspberry Pi 2, which is based on the Broadcom 2708/2709 chipset:
 Aside from modifying your kernel recipe and providing your own
 ``defconfig`` file, you need to be sure no files or statements set
 ``SRC_URI`` to use a ``defconfig`` other than your "in-tree" file (e.g.
-a kernel's ``linux-``\ machine\ ``.inc`` file). In other words, if the
+a kernel's ``linux-``\ `machine`\ ``.inc`` file). In other words, if the
 build system detects a statement that identifies an "out-of-tree"
 ``defconfig`` file, that statement will override your
 ``KBUILD_DEFCONFIG`` variable.
@@ -786,10 +768,9 @@ the extensible SDK and ``devtool``.
 .. note::
 
    Before attempting this procedure, be sure you have performed the
-   steps to get ready for updating the kernel as described in the "
-   Getting Ready to Develop Using
-   devtool
-   " section.
+   steps to get ready for updating the kernel as described in the
+   ":ref:`kernel-dev/kernel-dev-common:getting ready to develop using \`\`devtool\`\``"
+   section.
 
 Patching the kernel involves changing or adding configurations to an
 existing kernel, changing or adding recipes to the kernel that are
@@ -809,12 +790,9 @@ the ":ref:`kernel-dev/kernel-dev-common:getting ready to develop using \`\`devto
 
    .. note::
 
-      See this
-      step
-      in the "
-      Getting Ready to Develop Using
-      devtool
-      " section for more information.
+      See this step in the
+      ":ref:`kernel-dev/kernel-dev-common:getting ready to develop using \`\`devtool\`\``"
+      section for more information.
 
    Use the following ``devtool`` command to check out the code:
    ::
@@ -825,7 +803,8 @@ the ":ref:`kernel-dev/kernel-dev-common:getting ready to develop using \`\`devto
 
       During the checkout operation, a bug exists that could cause
       errors such as the following to appear:
-      ::
+
+      .. code-block:: none
 
               ERROR: Taskhash mismatch 2c793438c2d9f8c3681fd5f7bc819efa versus
                      be3a89ce7c47178880ba7bf6293d7404 for
@@ -883,7 +862,7 @@ the ":ref:`kernel-dev/kernel-dev-common:getting ready to develop using \`\`devto
       If the image you originally created resulted in a Wic file, you
       can use an alternate method to create the new image with the
       updated kernel. For an example, see the steps in the
-      TipsAndTricks/KernelDevelopmentWithEsdk
+      :yocto_wiki:`TipsAndTricks/KernelDevelopmentWithEsdk </wiki/TipsAndTricks/KernelDevelopmentWithEsdk>`
       Wiki Page.
 
    ::
@@ -903,7 +882,8 @@ the ":ref:`kernel-dev/kernel-dev-common:getting ready to develop using \`\`devto
    2. *Verify the changes*: Log into the machine using ``root`` with no
       password and then use the following shell command to scroll
       through the console's boot output.
-      ::
+
+      .. code-block:: none
 
          # dmesg | less
 
@@ -925,14 +905,15 @@ the ":ref:`kernel-dev/kernel-dev-common:getting ready to develop using \`\`devto
    commits as patches and create a ``.bbappend`` file, use the following
    command in the terminal used to work with the extensible SDK. This
    example uses the previously established layer named ``meta-mylayer``.
+   ::
+
+      $ devtool finish linux-yocto ~/meta-mylayer
 
    .. note::
 
-      See Step 3 of the "
-      Getting Ready to Develop Using devtool
-      " section for information on setting up this layer.
-
-   $ devtool finish linux-yocto ~/meta-mylayer
+      See Step 3 of the
+      ":ref:`kernel-dev/kernel-dev-common:getting ready to develop using \`\`devtool\`\``"
+      section for information on setting up this layer.
 
    Once the command
    finishes, the patches and the ``.bbappend`` file are located in the
@@ -960,9 +941,9 @@ section).
 .. note::
 
    Before attempting this procedure, be sure you have performed the
-   steps to get ready for updating the kernel as described in the "
-   Getting Ready for Traditional Kernel Development
-   " section.
+   steps to get ready for updating the kernel as described in the
+   ":ref:`kernel-dev/kernel-dev-common:getting ready for traditional kernel development`"
+   section.
 
 Patching the kernel involves changing or adding configurations to an
 existing kernel, changing or adding recipes to the kernel that are
@@ -986,7 +967,7 @@ Section.
    section, use the following commands to edit the ``calibrate.c`` file:
 
    1. *Change the working directory*: You need to locate the source
-      files in the local copy of the kernel Git repository: Change to
+      files in the local copy of the kernel Git repository. Change to
       where the kernel source code is before making your edits to the
       ``calibrate.c`` file:
       ::
@@ -1046,13 +1027,10 @@ Section.
 
    .. note::
 
-      Be sure to replace
-      path-to
+      Be sure to replace `path-to`
       with the pathname to your local Git repositories. Also, you must
       be sure to specify the correct branch and machine types. For this
-      example, the branch is
-      standard/base
-      and the machine is "qemux86".
+      example, the branch is ``standard/base`` and the machine is ``qemux86``.
 
 4. *Build the Image:* With the source modified, your changes staged and
    committed, and the ``local.conf`` file pointing to the kernel files,
@@ -1073,7 +1051,8 @@ Section.
 6. *Look for Your Changes:* As QEMU booted, you might have seen your
    changes rapidly scroll by. If not, use these commands to see your
    changes:
-   ::
+
+   .. code-block:: none
 
       # dmesg | less
 
@@ -1134,13 +1113,10 @@ Section.
 
    .. note::
 
-      To build
-      core-image-minimal
-      again and see the effects of your patch, you can essentially
-      eliminate the temporary source files saved in
-      poky/build/tmp/work/...
-      and residual effects of the build by entering the following
-      sequence of commands:
+      To build ``core-image-minimal`` again and see the effects of your patch,
+      you can essentially eliminate the temporary source files saved in
+      ``poky/build/tmp/work/...`` and residual effects of the build by entering
+      the following sequence of commands:
       ::
 
               $ cd ~/poky/build
@@ -1174,7 +1150,7 @@ Using  ``menuconfig``
 The easiest way to define kernel configurations is to set them through
 the ``menuconfig`` tool. This tool provides an interactive method with
 which to set kernel configurations. For general information on
-``menuconfig``, see http://en.wikipedia.org/wiki/Menuconfig.
+``menuconfig``, see https://en.wikipedia.org/wiki/Menuconfig.
 
 To use the ``menuconfig`` tool in the Yocto Project development
 environment, you must do the following:
@@ -1212,35 +1188,20 @@ the tool and save your changes to create an updated version of the
 
 .. note::
 
-   You can use the entire
-   .config
-   file as the
-   defconfig
-   file. For information on
-   defconfig
-   files, see the "
-   Changing the Configuration
-   ", "
-   Using an In-Tree
-   defconfig
-   File
-   , and "
-   Creating a
-   defconfig
-   File
-   " sections.
+   You can use the entire ``.config`` file as the ``defconfig`` file. For
+   information on ``defconfig`` files, see the
+   ":ref:`kernel-dev/kernel-dev-common:changing the configuration`",
+   ":ref:`kernel-dev/kernel-dev-common:using an "in-tree" \`\`defconfig\`\` file`",
+   and ":ref:`kernel-dev/kernel-dev-common:creating a \`\`defconfig\`\` file`"
+   sections.
 
 Consider an example that configures the "CONFIG_SMP" setting for the
 ``linux-yocto-4.12`` kernel.
 
 .. note::
 
-   The OpenEmbedded build system recognizes this kernel as
-   linux-yocto
-   through Metadata (e.g.
-   PREFERRED_VERSION
-   \_linux-yocto ?= "12.4%"
-   ).
+   The OpenEmbedded build system recognizes this kernel as ``linux-yocto``
+   through Metadata (e.g. :term:`PREFERRED_VERSION`\ ``_linux-yocto ?= "12.4%"``).
 
 Once ``menuconfig`` launches, use the interface to navigate through the
 selections to find the configuration settings in which you are
@@ -1259,7 +1220,8 @@ area where the specific kernel is built. For example, if you were
 building a Linux Yocto kernel based on the ``linux-yocto-4.12`` kernel
 and you were building a QEMU image targeted for ``x86`` architecture,
 the ``.config`` file would be:
-::
+
+.. code-block:: none
 
    poky/build/tmp/work/qemux86-poky-linux/linux-yocto/4.12.12+gitAUTOINC+eda4d18...
    ...967-r0/linux-qemux86-standard-build/.config
@@ -1289,11 +1251,8 @@ kernel layer.
 
 .. note::
 
-   Be sure to make a copy of the
-   .config
-   file and do not just rename it. The build system needs an existing
-   .config
-   file from which to work.
+   Be sure to make a copy of the ``.config`` file and do not just rename it.
+   The build system needs an existing ``.config`` file from which to work.
 
 Creating a  ``defconfig`` File
 ------------------------------
@@ -1307,13 +1266,9 @@ which the OpenEmbedded build system can draw to create the final
 
 .. note::
 
-   Out-of-the-box, the Yocto Project never ships a
-   defconfig
-   or
-   .config
-   file. The OpenEmbedded build system creates the final
-   .config
-   file used to configure the kernel.
+   Out-of-the-box, the Yocto Project never ships a ``defconfig`` or ``.config``
+   file. The OpenEmbedded build system creates the final ``.config`` file used
+   to configure the kernel.
 
 To create a ``defconfig``, start with a complete, working Linux kernel
 ``.config`` file. Copy that file to the appropriate
@@ -1335,16 +1290,13 @@ created to hold the configuration changes.
 
 .. note::
 
-   The build system applies the configurations from the
-   defconfig
+   The build system applies the configurations from the ``defconfig``
    file before applying any subsequent configuration fragments. The
    final kernel configuration is a combination of the configurations in
-   the
-   defconfig
-   file and any configuration fragments you provide. You need to realize
-   that if you have any configuration fragments, the build system
-   applies these on top of and after applying the existing defconfig
-   file configurations.
+   the ``defconfig`` file and any configuration fragments you provide. You need
+   to realize that if you have any configuration fragments, the build system
+   applies these on top of and after applying the existing ``defconfig`` file
+   configurations.
 
 For more information on configuring the kernel, see the "`Changing the
 Configuration <#changing-the-configuration>`__" section.
@@ -1368,9 +1320,8 @@ appear in the ``.config`` file, which is in the :term:`Build Directory`.
 
 .. note::
 
-   For more information about where the
-   .config
-   file is located, see the example in the
+   For more information about where the ``.config`` file is located, see the
+   example in the
    ":ref:`kernel-dev/kernel-dev-common:using \`\`menuconfig\`\``"
    section.
 
@@ -1384,10 +1335,9 @@ multi-processor support within the kernel:
 
 .. note::
 
-   All configuration fragment files must use the
-   .cfg
-   extension in order for the OpenEmbedded build system to recognize
-   them as a configuration fragment.
+   All configuration fragment files must use the ``.cfg`` extension in order
+   for the OpenEmbedded build system to recognize them as a configuration
+   fragment.
 
 Another method is to create a configuration fragment using the
 differences between two configuration files: one previously created and
@@ -1429,9 +1379,8 @@ information on how to use the output as a configuration fragment.
 .. note::
 
    You can also use this method to create configuration fragments for a
-   BSP. See the "
-   BSP Descriptions
-   " section for more information.
+   BSP. See the ":ref:`kernel-dev/kernel-dev-advanced:bsp descriptions`"
+   section for more information.
 
 Where do you put your configuration fragment files? You can place these
 files in an area pointed to by
@@ -1480,7 +1429,8 @@ See the ":ref:`kernel-dev/kernel-dev-common:using \`\`menuconfig\`\``" section f
 information on how to create a configuration file.
 
 Following is sample output from the ``do_kernel_configcheck`` task:
-::
+
+.. code-block:: none
 
    Loading cache: 100% |########################################################| Time: 0:00:00
    Loaded 1275 entries from dependency cache.
@@ -1577,10 +1527,8 @@ produces warning messages for the following issues:
 
 .. note::
 
-   The
-   do_kernel_configcheck
-   task can also optionally report if an option is overridden during
-   processing.
+   The :ref:`ref-tasks-kernel_configcheck` task can also optionally report if
+   an option is overridden during processing.
 
 For each output warning, a message points to the file that contains a
 list of the options and a pointer to the configuration fragment that
@@ -1627,7 +1575,7 @@ Expanding Variables
 ===================
 
 Sometimes it is helpful to determine what a variable expands to during a
-build. You can do examine the values of variables by examining the
+build. You can examine the values of variables by examining the
 output of the ``bitbake -e`` command. The output is long and is more
 easily managed in a text file, which allows for easy searches:
 ::
@@ -1767,7 +1715,10 @@ Here are some basic steps you can use to work with your own sources:
       as derived from the :term:`SRCPV`
       variable. The combined results are a string with the following
       form:
-      3.19.11+git1+68a635bf8dfb64b02263c1ac80c948647cc76d5f_1+218bd8d2022b9852c60d32f0d770931e3cf343e2
+      ::
+
+         3.19.11+git1+68a635bf8dfb64b02263c1ac80c948647cc76d5f_1+218bd8d2022b9852c60d32f0d770931e3cf343e2
+
       While lengthy, the extra verbosity in ``PV`` helps ensure you are
       using the exact sources from which you intend to build.
 
@@ -1778,7 +1729,10 @@ Here are some basic steps you can use to work with your own sources:
       triggers an explicit build failure. You must change it to match a
       list of the machines that your new recipe supports. For example,
       to support the ``qemux86`` and ``qemux86-64`` machines, use the
-      following form: COMPATIBLE_MACHINE = "qemux86|qemux86-64"
+      following form:
+      ::
+
+         COMPATIBLE_MACHINE = "qemux86|qemux86-64"
 
 5. *Customize Your Recipe as Needed:* Provide further customizations to
    your recipe as needed just as you would customize an existing
@@ -1813,7 +1767,8 @@ is running that image.
 Prior to attempting to build the out-of-tree modules, you need to be on
 the target as root and you need to change to the ``/usr/src/kernel``
 directory. Next, ``make`` the scripts:
-::
+
+.. code-block:: none
 
    # cd /usr/src/kernel
    # make scripts
@@ -1835,7 +1790,8 @@ create your own out-of-tree Linux kernel module recipe.
 
 This template recipe is located in the ``poky`` Git repository of the
 Yocto Project :yocto_git:`Source Repository <>` at:
-::
+
+.. code-block:: none
 
    poky/meta-skeleton/recipes-kernel/hello-mod/hello-mod_0.1.bb
 
@@ -1925,17 +1881,15 @@ changes.
 
 .. note::
 
-   In the following examples, unless you provide a commit range,
-   kernel.org
+   In the following examples, unless you provide a commit range, ``kernel.org``
    history is blended with Yocto Project kernel changes. You can form
    ranges by using branch names from the kernel tree as the upper and
    lower commit markers with the Git commands. You can see the branch
    names through the web interface to the Yocto Project source
-   repositories at
-   .
+   repositories at :yocto_git:`/`.
 
 To see a full range of the changes, use the ``git whatchanged`` command
-and specify a commit range for the branch (commit\ ``..``\ commit).
+and specify a commit range for the branch (`commit`\ ``..``\ `commit`).
 
 Here is an example that looks at what has changed in the ``emenlow``
 branch of the ``linux-yocto-3.19`` kernel. The lower commit range is the
@@ -1990,8 +1944,8 @@ Adding Recipe-Space Kernel Features
 ===================================
 
 You can add kernel features in the
-`recipe-space <#recipe-space-metadata>`__ by using the
-:term:`KERNEL_FEATURES`
+:ref:`recipe-space <kernel-dev/kernel-dev-advanced:recipe-space metadata>`
+by using the :term:`KERNEL_FEATURES`
 variable and by specifying the feature's ``.scc`` file path in the
 :term:`SRC_URI` statement. When you
 add features using this method, the OpenEmbedded build system checks to
@@ -2008,9 +1962,9 @@ You add a kernel feature by providing the feature as part of the
 OpenEmbedded build system searches all forms of kernel Metadata on the
 ``SRC_URI`` statement regardless of whether the Metadata is in the
 "kernel-cache", system kernel Metadata, or a recipe-space Metadata (i.e.
-part of the kernel recipe). See the "`Kernel Metadata
-Location <#kernel-metadata-location>`__" section for additional
-information.
+part of the kernel recipe). See the
+":ref:`kernel-dev/kernel-dev-advanced:kernel metadata location`" section for
+additional information.
 
 When you specify the feature's ``.scc`` file on the ``SRC_URI``
 statement, the OpenEmbedded build system adds the directory of that
@@ -2073,6 +2027,5 @@ build.
    .. note::
 
       If other features are contained below "test.scc", then their
-      directories are relative to the directory containing the
-      test.scc
+      directories are relative to the directory containing the ``test.scc``
       file.

documentation/kernel-dev/kernel-dev-concepts-appx.rst

@@ -11,7 +11,7 @@ Yocto Project Kernel Development and Maintenance
 
 Kernels available through the Yocto Project (Yocto Linux kernels), like
 other kernels, are based off the Linux kernel releases from
-http://www.kernel.org. At the beginning of a major Linux kernel
+https://www.kernel.org. At the beginning of a major Linux kernel
 development cycle, the Yocto Project team chooses a Linux kernel based
 on factors such as release timing, the anticipated release timing of
 final upstream ``kernel.org`` versions, and Yocto Project feature
@@ -119,7 +119,7 @@ upstream Linux kernel development and are managed by the Yocto Project
 team's Yocto Linux kernel development strategy. It is the Yocto Project
 team's policy to not back-port minor features to the released Yocto
 Linux kernel. They only consider back-porting significant technological
-jumps DASH and, that is done after a complete gap analysis. The reason
+jumps - and, that is done after a complete gap analysis. The reason
 for this policy is that back-porting any small to medium sized change
 from an evolving Linux kernel can easily create mismatches,
 incompatibilities and very subtle errors.
@@ -129,7 +129,7 @@ cutting edge Yocto Linux kernel that mixes forward ports of existing
 Linux kernel features and significant and critical new functionality.
 Forward porting Linux kernel functionality into the Yocto Linux kernels
 available through the Yocto Project can be thought of as a "micro
-uprev." The many "micro uprevs" produce a Yocto Linux kernel version
+uprev". The many "micro uprevs" produce a Yocto Linux kernel version
 with a mix of important new mainline, non-mainline, BSP developments and
 feature integrations. This Yocto Linux kernel gives insight into new
 features and allows focused amounts of testing to be done on the kernel,
@@ -160,9 +160,8 @@ implemented by the Yocto Project team using the Source Code Manager
       but, Git continues to grow in popularity and supports many
       different work flows, front-ends and management techniques.
 
-   -  You can find documentation on Git at
-      http://git-scm.com/documentation. You can also get an
-      introduction to Git as it applies to the Yocto Project in the
+   -  You can find documentation on Git at https://git-scm.com/doc. You can
+      also get an introduction to Git as it applies to the Yocto Project in the
       ":ref:`overview-manual/overview-manual-development-environment:git`" section in the Yocto Project
       Overview and Concepts Manual. The latter reference provides an
       overview of Git and presents a minimal set of Git commands that
@@ -260,8 +259,8 @@ Yocto Linux kernel needed for any given set of requirements.
    Keep in mind the figure does not take into account all the supported
    Yocto Linux kernels, but rather shows a single generic kernel just
    for conceptual purposes. Also keep in mind that this structure
-   represents the Yocto Project
-   Source Repositories
+   represents the
+   :ref:`overview-manual/overview-manual-development-environment:yocto project source repositories`
    that are either pulled from during the build or established on the
    host development system prior to the build by either cloning a
    particular kernel's Git repository or by downloading and unpacking a

documentation/kernel-dev/kernel-dev-faq.rst

@@ -38,7 +38,7 @@ How do I install/not-install the kernel image on the rootfs?
 The kernel image (e.g. ``vmlinuz``) is provided by the
 ``kernel-image`` package. Image recipes depend on ``kernel-base``. To
 specify whether or not the kernel image is installed in the generated
-root filesystem, override ``RDEPENDS_kernel-base`` to include or not
+root filesystem, override ``RDEPENDS_${KERNEL_PACKAGE_NAME}-base`` to include or not
 include "kernel-image". See the
 ":ref:`dev-manual/dev-manual-common-tasks:using .bbappend files in your layer`"
 section in the
@@ -50,13 +50,13 @@ How do I install a specific kernel module?
 
 Linux kernel modules are packaged individually. To ensure a
 specific kernel module is included in an image, include it in the
-appropriate machine
-:term:`RRECOMMENDS` variable.
+appropriate machine :term:`RRECOMMENDS` variable.
 These other variables are useful for installing specific modules:
-:term:`MACHINE_ESSENTIAL_EXTRA_RDEPENDS`
-:term:`MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS`
-:term:`MACHINE_EXTRA_RDEPENDS`
-:term:`MACHINE_EXTRA_RRECOMMENDS`
+- :term:`MACHINE_ESSENTIAL_EXTRA_RDEPENDS`
+- :term:`MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS`
+- :term:`MACHINE_EXTRA_RDEPENDS`
+- :term:`MACHINE_EXTRA_RRECOMMENDS`
+
 For example, set the following in the ``qemux86.conf`` file to include
 the ``ab123`` kernel modules with images built for the ``qemux86``
 machine:
@@ -64,9 +64,8 @@ machine:
 
    MACHINE_EXTRA_RRECOMMENDS += "kernel-module-ab123"
 
-For more
-information, see the "`Incorporating Out-of-Tree
-Modules <#incorporating-out-of-tree-modules>`__" section.
+For more information, see the
+":ref:`kernel-dev/kernel-dev-common:incorporating out-of-tree modules`" section.
 
 How do I change the Linux kernel command line?
 ----------------------------------------------

documentation/kernel-dev/kernel-dev-intro.rst

@@ -23,7 +23,7 @@ Each Yocto Project release has a set of Yocto Linux kernel recipes,
 whose Git repositories you can view in the Yocto
 :yocto_git:`Source Repositories <>` under the "Yocto Linux Kernel"
 heading. New recipes for the release track the latest Linux kernel
-upstream developments from http://www.kernel.org> and introduce
+upstream developments from https://www.kernel.org and introduce
 newly-supported platforms. Previous recipes in the release are refreshed
 and supported for at least one additional Yocto Project release. As they
 align, these previous releases are updated to include the latest from
@@ -37,8 +37,8 @@ upstream Yocto Linux kernel development and kernel Metadata development.
 
 .. note::
 
-   For more on Yocto Linux kernels, see the "
-   Yocto Project Kernel Development and Maintenance
+   For more on Yocto Linux kernels, see the
+   ":ref:`Yocto Project Kernel Development and Maintenance <kernel-big-picture>`"
    section.
 
 The Yocto Project also provides a powerful set of kernel tools for
@@ -75,7 +75,7 @@ tools with your own kernel sources.
 The remainder of this manual provides instructions for completing
 specific Linux kernel development tasks. These instructions assume you
 are comfortable working with
-`BitBake <http://openembedded.org/wiki/Bitbake>`__ recipes and basic
+`BitBake <https://openembedded.org/wiki/Bitbake>`__ recipes and basic
 open-source development tools. Understanding these concepts will
 facilitate the process of working with the kernel recipes. If you find
 you need some additional background, please be sure to review and
@@ -158,8 +158,7 @@ general information and references for further information.
 
    .. note::
 
-      Try to resist the temptation to directly edit an existing
-      .config
+      Try to resist the temptation to directly edit an existing ``.config``
       file, which is found in the Build Directory among the source code
       used for the build. Doing so, can produce unexpected results when
       the OpenEmbedded build system regenerates the configuration file.
@@ -167,9 +166,9 @@ general information and references for further information.
    Once you are satisfied with the configuration changes made using
    ``menuconfig`` and you have saved them, you can directly compare the
    resulting ``.config`` file against an existing original and gather
-   those changes into a `configuration fragment
-   file <#creating-config-fragments>`__ to be referenced from within the
-   kernel's ``.bbappend`` file.
+   those changes into a
+   :ref:`configuration fragment file <creating-config-fragments>` to be
+   referenced from within the kernel's ``.bbappend`` file.
 
    Additionally, if you are working in a BSP layer and need to modify
    the BSP's kernel's configuration, you can use ``menuconfig``.

documentation/kernel-dev/kernel-dev-maint-appx.rst

@@ -42,7 +42,11 @@ section.
 
 Once you have cloned the kernel Git repository and the cache of Metadata
 on your local machine, you can discover the branches that are available
-in the repository using the following Git command: $ git branch -a
+in the repository using the following Git command:
+::
+
+   $ git branch -a
+
 Checking out a branch allows you to work with a particular Yocto Linux
 kernel. For example, the following commands check out the
 "standard/beagleboard" branch of the Yocto Linux kernel repository and
@@ -56,10 +60,8 @@ the "yocto-4.12" branch of the ``yocto-kernel-cache`` repository:
 
 .. note::
 
-   Branches in the
-   yocto-kernel-cache
-   repository correspond to Yocto Linux kernel versions (e.g.
-   "yocto-4.12", "yocto-4.10", "yocto-4.9", and so forth).
+   Branches in the ``yocto-kernel-cache`` repository correspond to Yocto Linux
+   kernel versions (e.g. "yocto-4.12", "yocto-4.10", "yocto-4.9", and so forth).
 
 Once you have checked out and switched to appropriate branches, you can
 see a snapshot of all the kernel source files used to used to build that
@@ -105,7 +107,7 @@ patch, or BSP:
       repository organized under the "Yocto Linux Kernel" heading in the
       :yocto_git:`Yocto Project Source Repositories <>`.
 
-   -  Areas pointed to by ``SRC_URI`` statements found in kernel recipes
+   -  Areas pointed to by ``SRC_URI`` statements found in kernel recipes.
 
    For a typical build, the target of the search is a feature
    description in an ``.scc`` file whose name follows this format (e.g.
@@ -194,12 +196,10 @@ the build process before compilation starts:
    .. note::
 
       In the previous example, the "yocto-4.12" branch is checked out in
-      the
-      yocto-kernel-cache
-      repository.
+      the ``yocto-kernel-cache`` repository.
 
 The OpenEmbedded build system makes sure these conditions exist before
-attempting compilation. Other means, however, do exist, such as as
+attempting compilation. Other means, however, do exist, such as
 bootstrapping a BSP.
 
 Before building a kernel, the build process verifies the tree and

documentation/poky.yaml

@@ -1,63 +1,15 @@
-DISTRO : "3.1"
-DISTRO_COMPRESSED : "31"
-DISTRO_NAME_NO_CAP : "dunfell"
-DISTRO_NAME : "Dunfell"
-DISTRO_NAME_NO_CAP_MINUS_ONE : "zeus"
-DISTRO_NAME_MINUS_ONE : "Zeus"
-YOCTO_DOC_VERSION : "3.1"
-YOCTO_DOC_VERSION_MINUS_ONE : "3.0.2"
-DISTRO_REL_TAG : "yocto-3.1"
-METAINTELVERSION : "12.0"
-REL_MONTH_YEAR : "April 2020"
-META_INTEL_REL_TAG : "&METAINTELVERSION;-&DISTRO_NAME_NO_CAP;-&YOCTO_DOC_VERSION;"
-POKYVERSION : "23.0.0"
-POKYVERSION_COMPRESSED : "2300"
+DISTRO : "3.2.1"
+DISTRO_NAME_NO_CAP : "gatesgarth"
+DISTRO_NAME : "Gatesgarth"
+DISTRO_NAME_NO_CAP_MINUS_ONE : "dunfell"
+YOCTO_DOC_VERSION : "3.2.1"
+YOCTO_DOC_VERSION_MINUS_ONE : "3.1.3"
+DISTRO_REL_TAG : "yocto-3.2.1"
+POKYVERSION : "24.0.1"
 YOCTO_POKY : "poky-&DISTRO_NAME_NO_CAP;-&POKYVERSION;"
-COPYRIGHT_YEAR : "2010-2020"
-ORGNAME : "The Yocto Project"
-ORGEMAIL : "docs@lists.yoctoproject.org"
 YOCTO_DL_URL : "https://downloads.yoctoproject.org"
-YOCTO_HOME_URL : "https://www.yoctoproject.org"
-YOCTO_LISTS_URL : "https://lists.yoctoproject.org"
-YOCTO_BUGZILLA_URL : "https://bugzilla.yoctoproject.org"
-YOCTO_WIKI_URL : "https://wiki.yoctoproject.org"
 YOCTO_AB_URL : "https://autobuilder.yoctoproject.org"
-YOCTO_GIT_URL : "https://git.yoctoproject.org"
-YOCTO_ADTREPO_URL : "http://adtrepo.yoctoproject.org"
-OE_HOME_URL : "https://www.openembedded.org"
-OE_LISTS_URL : "https://lists.openembedded.org"
-OE_DOCS_URL : "https://docs.openembedded.org"
-OH_HOME_URL : "http://o-hand.com"
-BITBAKE_HOME_URL : "http://developer.berlios.de/projects/bitbake/"
-YOCTO_DOCS_URL : "&YOCTO_HOME_URL;/docs"
-YOCTO_SOURCES_URL : "&YOCTO_HOME_URL;/sources/"
-YOCTO_AB_PORT_URL : "https://autobuilder.yocto.io/"
-YOCTO_AB_NIGHTLY_URL : "&YOCTO_AB_PORT_URL;/pub/nightly/"
-YOCTO_POKY_URL : "&YOCTO_DL_URL;/releases/poky/"
 YOCTO_RELEASE_DL_URL : "&YOCTO_DL_URL;/releases/yocto/yocto-&DISTRO;"
-YOCTO_TOOLCHAIN_DL_URL : "&YOCTO_RELEASE_DL_URL;/toolchain/"
-YOCTO_ADTINSTALLER_DL_URL : "&YOCTO_RELEASE_DL_URL;/adt-installer"
-YOCTO_POKY_DL_URL : "&YOCTO_RELEASE_DL_URL;/&YOCTO_POKY;.tar.bz2"
-YOCTO_MACHINES_DL_URL : "&YOCTO_RELEASE_DL_URL;/machines"
-YOCTO_QEMU_DL_URL : "&YOCTO_MACHINES_DL_URL;/qemu"
-YOCTO_PYTHON-i686_DL_URL : "&YOCTO_DL_URL;/releases/miscsupport/python-nativesdk-standalone-i686.tar.bz2"
-YOCTO_PYTHON-x86_64_DL_URL : "&YOCTO_DL_URL;/releases/miscsupport/python-nativesdk-standalone-x86_64.tar.bz2"
-YOCTO_DOCS_QS_URL : "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/yocto-project-qs/yocto-project-qs.html"
-YOCTO_DOCS_ADT_URL : "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/adt-manual/adt-manual.html"
-YOCTO_DOCS_REF_URL : "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/ref-manual/ref-manual.html"
-YOCTO_DOCS_BSP_URL : "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/bsp-guide/bsp-guide.html"
-YOCTO_DOCS_DEV_URL : "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/dev-manual/dev-manual.html"
-YOCTO_DOCS_KERNEL_DEV_URL : "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/kernel-dev/kernel-dev.html"
-YOCTO_DOCS_PROF_URL : "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/profile-manual/profile-manual.html"
-YOCTO_DOCS_MM_URL : "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/mega-manual/mega-manual.html"
-YOCTO_DOCS_BB_URL : "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/bitbake-user-manual/bitbake-user-manual.html"
-YOCTO_DOCS_TOAST_URL : "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/toaster-manual/toaster-manual.html"
-YOCTO_DOCS_SDK_URL : "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/sdk-manual/sdk-manual.html"
-YOCTO_DOCS_OM_URL : "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/overview-manual/overview-manual.html"
-YOCTO_DOCS_BRIEF_URL : "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/brief-yoctoprojectqs/brief-yoctoprojectqs.html"
-YOCTO_ADTPATH_DIR : "/opt/poky/&DISTRO;"
-YOCTO_POKY_TARBALL : "&YOCTO_POKY;.tar.bz2"
-OE_INIT_PATH : "&YOCTO_POKY;/oe-init-build-env"
 UBUNTU_HOST_PACKAGES_ESSENTIAL : "gawk wget git-core diffstat unzip texinfo gcc-multilib \
      build-essential chrpath socat cpio python3 python3-pip python3-pexpect \
      xz-utils debianutils iputils-ping python3-git python3-jinja2 libegl1-mesa libsdl1.2-dev \

documentation/ref-manual/faq.rst

@@ -451,3 +451,14 @@ variant. For another example, permissions errors might be caused by a
 Makefile that ignores ``DESTDIR`` or uses a different name for that
 environment variable. Check the the build system to see if these kinds
 of issues exist.
+
+**Q:** I'm adding a binary in a recipe but it's different in the image, what is
+changing it?
+
+**A:** The first most obvious change is the system stripping debug symbols from
+it. Setting :term:`INHIBIT_PACKAGE_STRIP` to stop debug symbols being stripped and/or
+:term:`INHIBIT_PACKAGE_DEBUG_SPLIT` to stop debug symbols being split into a separate
+file will ensure the binary is unchanged. The other less obvious thing that can
+happen is prelinking of the image. This is set by default in local.conf via
+:term:`USER_CLASSES` which can contain 'image-prelink'. If you remove that, the
+image will not be prelinked meaning the binaries would be unchanged.

documentation/ref-manual/migration-3.2.rst

@@ -0,0 +1,313 @@
+Moving to the Yocto Project 3.2 Release
+=======================================
+
+This section provides migration information for moving to the Yocto
+Project 3.2 Release from the prior release.
+
+.. _migration-3.2-minimum-system-requirements:
+
+Minimum system requirements
+---------------------------
+
+``gcc`` version 6.0 is now required at minimum on the build host. For older
+host distributions where this is not available, you can use the
+``buildtools-extended-tarball`` (easily installable using
+``scripts/install-buildtools``).
+
+
+.. _migration-3.2-removed-recipes:
+
+Removed recipes
+---------------
+
+The following recipes have been removed:
+
+- ``bjam-native``: replaced by ``boost-build-native``
+- ``avahi-ui``: folded into the main ``avahi`` recipe - the GTK UI can be disabled using :term:`PACKAGECONFIG` for ``avahi``.
+- ``build-compare``: no longer needed with the removal of the ``packagefeed-stability`` class
+- ``dhcp``: obsolete, functionally replaced by ``dhcpcd`` and ``kea``
+- ``libmodulemd-v1``: replaced by ``libmodulemd``
+- ``packagegroup-core-device-devel``: obsolete
+
+
+.. _migration-3.2-removed-classes:
+
+Removed classes
+---------------
+
+The following classes (.bbclass files) have been removed:
+
+-  ``spdx``: obsolete - the Yocto Project is a strong supporter of SPDX, but this class was old code using a dated approach and had the potential to be misleading. The ``meta-sdpxscanner`` layer is a much more modern and active approach to handling this and is recommended as a replacement.
+
+- ``packagefeed-stability``: this class had become obsolete with the advent of hash equivalence and reproducible builds.
+
+
+pseudo path filtering and mismatch behaviour
+--------------------------------------------
+
+pseudo now operates on a filtered subset of files. This is a significant change
+to the way pseudo operates within OpenEmbedded - by default, pseudo monitors and
+logs (adds to its database) any file created or modified whilst in a ``fakeroot``
+environment. However, there are large numbers of files that we simply don't care
+about the permissions of whilst in that ``fakeroot`` context, for example ${:term:`S`}, ${:term:`B`}, ${:term:`T`},
+${:term:`SSTATE_DIR`}, the central sstate control directories, and others.
+
+As of this release, new functionality in pseudo is enabled to ignore these
+directory trees (controlled using a new :term:`PSEUDO_IGNORE_PATHS` variable)
+resulting in a cleaner database with less chance of "stray" mismatches if files
+are modified outside pseudo context. It also should reduce some overhead from
+pseudo as the interprocess round trip to the server is avoided.
+
+There is a possible complication where some existing recipe may break, for
+example, a recipe was found to be writing to ``${B}/install`` for
+``make install`` in ``do_install`` and since ``${B}`` is listed as not to be tracked,
+there were errors trying to ``chown root`` for files in this location. Another
+example was the ``tcl`` recipe where the source directory ``S`` is set to a
+subdirectory of the source tree but files were written out to the directory
+structure above that subdirectory. For these types of cases in your own recipes,
+extend ``PSEUDO_IGNORE_PATHS`` to cover additional paths that pseudo should not
+be monitoring.
+
+In addition, pseudo's behaviour on mismatches has now been changed - rather
+than doing what turns out to be a rather dangerous "fixup" if it sees a file
+with a different path but the same inode as another file it has previously seen,
+pseudo will throw an ``abort()`` and direct you to a :yocto_wiki:`wiki page </wiki/Pseudo_Abort>`
+that explains how to deal with this.
+
+
+.. _migration-3.2-multilib-mlprefix:
+
+``MLPREFIX`` now required for multilib when runtime dependencies conditionally added
+------------------------------------------------------------------------------------
+
+In order to solve some previously intractable problems with runtime
+dependencies and multilib, a change was made that now requires the :term:`MLPREFIX`
+value to be explicitly prepended to package names being added as
+dependencies (e.g. in :term:`RDEPENDS` and :term:`RRECOMMENDS` values)
+where the dependency is conditionally added.
+
+If you have anonymous python or in-line python conditionally adding
+dependencies in your custom recipes, and you intend for those recipes to
+work with multilib, then you will need to ensure that ``${MLPREFIX}``
+is prefixed on the package names in the dependencies, for example
+(from the ``glibc`` recipe): ::
+
+    RRECOMMENDS_${PN} = "${@bb.utils.contains('DISTRO_FEATURES', 'ldconfig', '${MLPREFIX}ldconfig', '', d)}"
+
+This also applies when conditionally adding packages to :term:`PACKAGES` where
+those packages have dependencies, for example (from the ``alsa-plugins`` recipe): ::
+
+    PACKAGES += "${@bb.utils.contains('PACKAGECONFIG', 'pulseaudio', 'alsa-plugins-pulseaudio-conf', '', d)}"
+    ...
+    RDEPENDS_${PN}-pulseaudio-conf += "\
+            ${MLPREFIX}libasound-module-conf-pulse \
+            ${MLPREFIX}libasound-module-ctl-pulse \
+            ${MLPREFIX}libasound-module-pcm-pulse \
+    "
+
+
+.. _migration-3.2-packagegroup-core-device-devel:
+
+packagegroup-core-device-devel no longer included in images built for qemu* machines
+------------------------------------------------------------------------------------
+
+``packagegroup-core-device-devel`` was previously added automatically to
+images built for ``qemu*`` machines, however the purpose of the group and what
+it should contain is no longer clear, and in general, adding userspace
+development items to images is best done at the image/class level; thus this
+packagegroup was removed.
+
+This packagegroup previously pulled in the following:
+
+- ``distcc-config``
+- ``nfs-export-root``
+- ``bash``
+- ``binutils-symlinks``
+
+If you still need any of these in your image built for a ``qemu*`` machine
+then you will add them explicitly to :term:`IMAGE_INSTALL` or another
+appropriate place in the dependency chain for your image (if you have not
+already done so).
+
+
+.. _migration-3.2-dhcp:
+
+DHCP server/client replaced
+---------------------------
+
+The ``dhcp`` software package has become unmaintained and thus has been
+functionally replaced by ``dhcpcd`` (client) and ``kea`` (server). You will
+need to replace references to the recipe/package names as appropriate - most
+commonly, at the package level ``dhcp-client`` should be replaced by
+``dhcpcd`` and ``dhcp-server`` should be replaced by ``kea``. If you have any
+custom configuration files for these they will need to be adapted - refer to
+the upstream documentation for ``dhcpcd`` and ``kea`` for further details.
+
+
+.. _migration-3.2-packaging-changes:
+
+Packaging changes
+-----------------
+
+- ``python3``: the ``urllib`` python package has now moved into the core package, as it is used more commonly than just netclient (e.g. email, xml, mimetypes, pydoc). In addition, the ``pathlib`` module is now also part of the core package.
+
+- ``iptables``: ``iptables-apply`` and ``ip6tables-apply`` have been split out to their own package to avoid a bash dependency in the main ``iptables`` package
+
+
+.. _migration-3.2-package-qa-checks:
+
+Package QA check changes
+------------------------
+
+Previously, the following package QA checks triggered warnings, however they can
+be indicators of genuine underlying problems and are therefore now treated as
+errors:
+
+- :ref:`already-stripped <qa-check-already-stripped>`
+- :ref:`compile-host-path <qa-check-compile-host-path>`
+- :ref:`installed-vs-shipped <qa-check-installed-vs-shipped>`
+- :ref:`ldflags <qa-check-ldflags>`
+- :ref:`pn-overrides <qa-check-pn-overrides>`
+- :ref:`rpaths <qa-check-rpaths>`
+- :ref:`staticdev <qa-check-staticdev>`
+- :ref:`unknown-configure-option <qa-check-unknown-configure-option>`
+- :ref:`useless-rpaths <qa-check-useless-rpaths>`
+
+In addition, the following new checks were added and default to triggering an error:
+
+- :ref:`shebang-size <qa-check-shebang-size>`: Check for shebang (#!) lines longer than 128 characters, which can give an error at runtime depending on the operating system.
+
+- :ref:`unhandled-features-check <qa-check-unhandled-features-check>`: Check if any of the variables supported by the :ref:`features_check <ref-classes-features_check>` class is set while not inheriting the class itself.
+
+- :ref:`missing-update-alternatives <qa-check-missing-update-alternatives>`: Check if the recipe sets the :term:`ALTERNATIVE` variable for any of its packages, and does not inherit the :ref:`update-alternatives <ref-classes-update-alternatives>` class.
+
+- A trailing slash or duplicated slashes in the value of :term:`S` or :term:`B` will now trigger a warning so that they can be removed and path comparisons can be more reliable - remove any instances of these in your recipes if the warning is displayed.
+
+
+.. _migration-3.2-src-uri-file-globbing:
+
+Globbing no longer supported in ``file://`` entries in ``SRC_URI``
+------------------------------------------------------------------
+
+Globbing (``*`` and ``?`` wildcards) in ``file://`` URLs within :term:`SRC_URI`
+did not properly support file checksums, thus changes to the source files
+would not always change the do_fetch task checksum, and consequently would
+not ensure that the changed files would be incorporated in subsequent builds.
+
+Unfortunately it is not practical to make globbing work generically here, so
+the decision was taken to remove support for globs in ``file://`` URLs.
+If you have any usage of these in your recipes, then you will now need to
+either add each of the files that you expect to match explicitly, or
+alternatively if you still need files to be pulled in dynamically, put the
+files into a subdirectory and reference that instead.
+
+
+.. _migration-3.2-deploydir-clean:
+
+deploy class now cleans ``DEPLOYDIR`` before ``do_deploy``
+----------------------------------------------------------
+
+``do_deploy`` as implemented in the :ref:`deploy <ref-classes-deploy>` class now cleans up ${:term:`DEPLOYDIR`} before running, just as ``do_install`` cleans up ${:term:`D`} before running. This reduces the risk of ``DEPLOYDIR`` being accidentally contaminated by files from previous runs, possibly even with different config, in case of incremental builds.
+
+Most recipes and classes that inherit the ``deploy`` class or interact with ``do_deploy`` are unlikely to be affected by this unless they add ``prefuncs`` to ``do_deploy`` *which also* put files into ``${DEPLOYDIR}`` - these should be refactored to use ``do_deploy_prepend`` instead.
+
+
+.. _migration-3.2-nativesdk-sdk-provides-dummy:
+
+Custom SDK / SDK-style recipes need to include ``nativesdk-sdk-provides-dummy``
+-------------------------------------------------------------------------------
+
+All ``nativesdk`` packages require ``/bin/sh`` due to their postinstall scriptlets, thus this package has to be dummy-provided within the SDK and ``nativesdk-sdk-provides-dummy`` now does this. If you have a custom SDK recipe (or your own SDK-style recipe similar to e.g. ``buildtools-tarball``), you will need to ensure ``nativesdk-sdk-provides-dummy`` or an equivalent is included in :term:`TOOLCHAIN_HOST_TASK`.
+
+
+``ld.so.conf`` now moved back to main ``glibc`` package
+-------------------------------------------------------
+
+There are cases where one doesn't want ``ldconfig`` on target (e.g. for
+read-only root filesystems, it's rather pointless), yet one still
+needs ``/etc/ld.so.conf`` to be present at image build time:
+
+When some recipe installs libraries to a non-standard location, and
+therefore installs in a file in ``/etc/ld.so.conf.d/foo.conf``, we
+need ``/etc/ld.so.conf`` containing: ::
+
+  include /etc/ld.so.conf.d/*.conf
+
+in order to get those other locations picked up.
+
+Thus ``/etc/ld.so.conf`` is now in the main ``glibc`` package so that
+there's always an ``ld.so.conf`` present when the build-time ``ldconfig``
+runs towards the end of image construction.
+
+The ``ld.so.conf`` and ``ld.so.conf.d/*.conf`` files do not take up
+significant space (at least not compared to the ~700kB ``ldconfig`` binary), and they
+might be needed in case ``ldconfig`` is installable, so they are left
+in place after the image is built. Technically it would be possible to
+remove them if desired, though it would not be trivial if you still
+wanted the build-time ldconfig to function (:term:`ROOTFS_POSTPROCESS_COMMAND`
+will not work as ``ldconfig`` is run after the functions referred to
+by that variable).
+
+
+.. _migration-3.2-virgl:
+
+Host DRI drivers now used for GL support within ``runqemu``
+-----------------------------------------------------------
+
+``runqemu`` now uses the mesa-native libraries everywhere virgl is used
+(i.e. when ``gl``, ``gl-es`` or ``egl-headless`` options are specified),
+but instructs them to load DRI drivers from the host. Unfortunately this
+may not work well with proprietary graphics drivers such as those from
+Nvidia; if you are using such drivers then you may need to switch to an
+alternative (such as Nouveau in the case of Nvidia hardware) or avoid
+using the GL options.
+
+
+.. _migration-3.2-initramfs-suffix:
+
+initramfs images now use a blank suffix
+---------------------------------------
+
+The reference initramfs images (``core-image-minimal-initramfs``,
+``core-image-tiny-initramfs`` and ``core-image-testmaster-initramfs``) now
+set an empty string for :term:`IMAGE_NAME_SUFFIX`, which otherwise defaults
+to ``".rootfs"``. These images aren't root filesystems and thus the rootfs
+label didn't make sense. If you are looking for the output files generated
+by these image recipes directly then you will need to adapt to the new
+naming without the ``.rootfs`` part.
+
+
+.. _migration-3.2-image-artifact-names:
+
+Image artifact name variables now centralised in image-artifact-names class
+---------------------------------------------------------------------------
+
+The defaults for the following image artifact name variables have been moved
+from bitbake.conf to a new ``image-artifact-names`` class:
+
+- :term:`IMAGE_BASENAME`
+- :term:`IMAGE_LINK_NAME`
+- :term:`IMAGE_NAME`
+- :term:`IMAGE_NAME_SUFFIX`
+- :term:`IMAGE_VERSION_SUFFIX`
+
+Image-related classes now inherit this class, and typically these variables
+are only referenced within image recipes so those will be unaffected by this
+change. However if you have references to these variables in either a recipe
+that is not an image or a class that is enabled globally, then those will
+now need to be changed to ``inherit image-artifact-names``.
+
+
+.. _migration-3.2-misc:
+
+Miscellaneous changes
+---------------------
+
+- Support for the long-deprecated ``PACKAGE_GROUP`` variable has now been removed - replace any remaining instances with :term:`FEATURE_PACKAGES`.
+- The ``FILESPATHPKG`` variable, having been previously deprecated, has now been removed. Replace any remaining references with appropriate use of :term:`FILESEXTRAPATHS`.
+- Erroneous use of ``inherit +=`` (instead of ``INHERIT +=``) in a configuration file now triggers an error instead of silently being ignored.
+- ptest support has been removed from the ``kbd`` recipe, as upstream has moved to autotest which is difficult to work with in a cross-compilation environment.
+- ``oe.utils.is_machine_specific()`` and ``oe.utils.machine_paths()`` have been removed as their utility was questionable. In the unlikely event that you have references to these in your own code, then the code will need to be reworked.
+- The ``i2ctransfer`` module is now disabled by default when building ``busybox`` in order to be consistent with disabling the other i2c tools there. If you do wish the i2ctransfer module to be built in busybox then add ``CONFIG_I2CTRANSFER=y`` to your custom busybox configuration.
+- In the ``Upstream-Status`` header convention for patches, ``Accepted`` has been replaced with ``Backport`` as these almost always mean the same thing i.e. the patch is already upstream and may need to be removed in a future recipe upgrade. If you are adding these headers to your own patches then use ``Backport`` to indicate that the patch has been sent upstream.
+- The ``tune-supersparc.inc`` tune file has been removed as it does not appear to be widely used and no longer works.

documentation/ref-manual/migration.rst

@@ -27,4 +27,5 @@ notes for a given release.
    migration-2.7
    migration-3.0
    migration-3.1
+   migration-3.2
 

documentation/ref-manual/ref-classes.rst

@@ -501,21 +501,6 @@ Support for other version control systems such as Subversion is limited
 due to BitBake's automatic fetch dependencies (e.g.
 ``subversion-native``).
 
-.. _ref-classes-distro_features_check:
-
-``distro_features_check.bbclass``
-=================================
-
-The ``distro_features_check`` class allows individual recipes to check
-for required and conflicting
-:term:`DISTRO_FEATURES`.
-
-This class provides support for the
-:term:`REQUIRED_DISTRO_FEATURES` and
-:term:`CONFLICT_DISTRO_FEATURES`
-variables. If any conditions specified in the recipe using the above
-variables are not met, the recipe will be skipped.
-
 .. _ref-classes-distutils:
 
 ``distutils*.bbclass``
@@ -656,6 +641,32 @@ Finally, here is an example that sets the root password to "1876*18":
        usermod -P 1876*18 root; \
        "
 
+.. _ref-classes-features_check:
+
+``features_check.bbclass``
+=================================
+
+The ``features_check`` class allows individual recipes to check
+for required and conflicting
+:term:`DISTRO_FEATURES`, :term:`MACHINE_FEATURES` or :term:`COMBINED_FEATURES`.
+
+This class provides support for the following variables:
+
+- :term:`REQUIRED_DISTRO_FEATURES`
+- :term:`CONFLICT_DISTRO_FEATURES`
+- :term:`ANY_OF_DISTRO_FEATURES`
+- ``REQUIRED_MACHINE_FEATURES``
+- ``CONFLICT_MACHINE_FEATURES``
+- ``ANY_OF_MACHINE_FEATURES``
+- ``REQUIRED_COMBINED_FEATURES``
+- ``CONFLICT_COMBINED_FEATURES``
+- ``ANY_OF_COMBINED_FEATURES``
+
+If any conditions specified in the recipe using the above
+variables are not met, the recipe will be skipped, and if the
+build system attempts to build the recipe then an error will be
+triggered.
+
 .. _ref-classes-fontcache:
 
 ``fontcache.bbclass``

documentation/ref-manual/ref-qa-checks.rst

@@ -43,6 +43,8 @@ error form along with an explanation.
 Errors and Warnings
 ===================
 
+.. _qa-check-libexec:
+
 -  ``<packagename>: <path> is using libexec please relocate to <libexecdir> [libexec]``
 
    The specified package contains files in ``/usr/libexec`` when the
@@ -51,6 +53,7 @@ Errors and Warnings
    default can be changed (e.g. ``${libdir}``).
 
     
+.. _qa-check-rpaths:
 
 -  ``package <packagename> contains bad RPATH <rpath> in file <file> [rpaths]``
 
@@ -65,6 +68,7 @@ Errors and Warnings
    software.
 
     
+.. _qa-check-useless-rpaths:
 
 -  ``<packagename>: <file> contains probably-redundant RPATH <rpath> [useless-rpaths]``
 
@@ -77,6 +81,7 @@ Errors and Warnings
    the build of the software.
 
     
+.. _qa-check-file-rdeps:
 
 -  ``<packagename> requires <files>, but no providers in its RDEPENDS [file-rdeps]``
 
@@ -88,6 +93,7 @@ Errors and Warnings
    built.
 
     
+.. _qa-check-build-deps:
 
 -  ``<packagename1> rdepends on <packagename2>, but it isn't a build dependency? [build-deps]``
 
@@ -101,6 +107,7 @@ Errors and Warnings
    to add an explicit ``RDEPENDS`` for the dependency.
 
     
+.. _qa-check-dev-so:
 
 -  ``non -dev/-dbg/nativesdk- package contains symlink .so: <packagename> path '<path>' [dev-so]``
 
@@ -112,6 +119,7 @@ Errors and Warnings
    file goes into an appropriate ``-dev`` package.
 
     
+.. _qa-check-staticdev:
 
 -  ``non -staticdev package contains static .a library: <packagename> path '<path>' [staticdev]``
 
@@ -121,6 +129,7 @@ Errors and Warnings
    goes into an appropriate ``-staticdev`` package.
 
     
+.. _qa-check-libdir:
 
 -  ``<packagename>: found library in wrong location [libdir]``
 
@@ -133,6 +142,7 @@ Errors and Warnings
    :term:`INSANE_SKIP` for the package.
 
     
+.. _qa-check-debug-files:
 
 -  ``non debug package contains .debug directory: <packagename> path <path> [debug-files]``
 
@@ -145,8 +155,9 @@ Errors and Warnings
    information on ``FILES``.
 
     
+.. _qa-check-arch:
 
--  ``Architecture did not match (<machine_arch> to <file_arch>) on <file> [arch]``
+-  ``Architecture did not match (<file_arch>, expected <machine_arch>) in <file> [arch]``
 
    By default, the OpenEmbedded build system checks the Executable and
    Linkable Format (ELF) type, bit size, and endianness of any binaries
@@ -164,7 +175,7 @@ Errors and Warnings
 
     
 
--  ``Bit size did not match (<machine_bits> to <file_bits>) <recipe> on <file> [arch]``
+-  ``Bit size did not match (<file_bits>, expected <machine_bits>) in <file> [arch]``
 
    By default, the OpenEmbedded build system checks the Executable and
    Linkable Format (ELF) type, bit size, and endianness of any binaries
@@ -182,7 +193,7 @@ Errors and Warnings
 
     
 
--  ``Endianness did not match (<machine_endianness> to <file_endianness>) on <file> [arch]``
+-  ``Endianness did not match (<file_endianness>, expected <machine_endianness>) in <file> [arch]``
 
    By default, the OpenEmbedded build system checks the Executable and
    Linkable Format (ELF) type, bit size, and endianness of any binaries
@@ -199,6 +210,7 @@ Errors and Warnings
    and verify that the compiler options being used are correct.
 
     
+.. _qa-check-textrel:
 
 -  ``ELF binary '<file>' has relocations in .text [textrel]``
 
@@ -218,8 +230,9 @@ Errors and Warnings
    http://www.akkadia.org/drepper/textrelocs.html.
 
     
+.. _qa-check-ldflags:
 
--  ``No GNU_HASH in the elf binary: '<file>' [ldflags]``
+-  ``File '<file>' in package '<package>' doesn't have GNU_HASH (didn't pass LDFLAGS?) [ldflags]``
 
    This indicates that binaries produced when building the recipe have
    not been linked with the :term:`LDFLAGS` options
@@ -233,6 +246,7 @@ Errors and Warnings
       TARGET_CC_ARCH += "${LDFLAGS}"
 
     
+.. _qa-check-xorg-driver-abi:
 
 -  ``Package <packagename> contains Xorg driver (<driver>) but no xorg-abi- dependencies [xorg-driver-abi]``
 
@@ -245,6 +259,7 @@ Errors and Warnings
    to explicitly add dependencies to binary driver recipes.
 
     
+.. _qa-check-infodir:
 
 -  ``The /usr/share/info/dir file is not meant to be shipped in a particular package. [infodir]``
 
@@ -256,6 +271,8 @@ Errors and Warnings
       rm ${D}${infodir}/dir
    
 
+.. _qa-check-symlink-to-sysroot:
+
 -  ``Symlink <path> in <packagename> points to TMPDIR [symlink-to-sysroot]``
 
    The specified symlink points into :term:`TMPDIR` on the
@@ -264,6 +281,7 @@ Errors and Warnings
    symlink to use a relative path or remove the symlink.
 
     
+.. _qa-check-la:
 
 -  ``<file> failed sanity test (workdir) in path <path> [la]``
 
@@ -273,6 +291,7 @@ Errors and Warnings
    automatically itself.
 
     
+.. _qa-check-pkgconfig:
 
 -  ``<file> failed sanity test (tmpdir) in path <path> [pkgconfig]``
 
@@ -283,6 +302,7 @@ Errors and Warnings
    are accessed.
 
     
+.. _qa-check-debug-deps:
 
 -  ``<packagename> rdepends on <debug_packagename> [debug-deps]``
 
@@ -305,6 +325,7 @@ Errors and Warnings
    manually (e.g. by adding to :term:`RDEPENDS`).
 
     
+.. _qa-check-dev-deps:
 
 -  ``<packagename> rdepends on <dev_packagename> [dev-deps]``
 
@@ -327,6 +348,7 @@ Errors and Warnings
    manually (e.g. by adding to :term:`RDEPENDS`).
 
     
+.. _qa-check-dep-cmp:
 
 -  ``<var>_<packagename> is invalid: <comparison> (<value>)   only comparisons <, =, >, <=, and >= are allowed [dep-cmp]``
 
@@ -341,6 +363,7 @@ Errors and Warnings
    adding to match those listed in the message.
 
     
+.. _qa-check-compile-host-path:
 
 -  ``<recipename>: The compile log indicates that host include and/or library paths were used. Please check the log '<logfile>' for more information. [compile-host-path]``
 
@@ -351,6 +374,7 @@ Errors and Warnings
    file.
 
     
+.. _qa-check-install-host-path:
 
 -  ``<recipename>: The install log indicates that host include and/or library paths were used. Please check the log '<logfile>' for more information. [install-host-path]``
 
@@ -361,8 +385,9 @@ Errors and Warnings
    file.
 
     
+.. _qa-check-configure-unsafe:
 
--  ``This autoconf log indicates errors, it looked at host include and/or library paths while determining system capabilities. Rerun configure task after fixing this. The path was '<path>'``
+-  ``This autoconf log indicates errors, it looked at host include and/or library paths while determining system capabilities. Rerun configure task after fixing this. [configure-unsafe]``
 
    The log for the :ref:`ref-tasks-configure` task
    indicates that paths on the host were searched for files, which is
@@ -371,6 +396,7 @@ Errors and Warnings
    file.
 
     
+.. _qa-check-pkgname:
 
 -  ``<packagename> doesn't match the [a-z0-9.+-]+ regex [pkgname]``
 
@@ -384,6 +410,7 @@ Errors and Warnings
    change the package name appropriately.
 
     
+.. _qa-check-unknown-configure-option:
 
 -  ``<recipe>: configure was passed unrecognized options: <options> [unknown-configure-option]``
 
@@ -401,6 +428,7 @@ Errors and Warnings
    accordingly.
 
     
+.. _qa-check-pn-overrides:
 
 -  ``Recipe <recipefile> has PN of "<recipename>" which is in OVERRIDES, this can result in unexpected behavior. [pn-overrides]``
 
@@ -416,6 +444,7 @@ Errors and Warnings
    :term:`FILES` for additional information.
 
     
+.. _qa-check-pkgvarcheck:
 
 -  ``<recipefile>: Variable <variable> is set as not being package specific, please fix this. [pkgvarcheck]``
 
@@ -432,7 +461,16 @@ Errors and Warnings
    ``RDEPENDS = "value"``). If you receive this error, correct any
    assignments to these variables within your recipe.
 
-    
+
+- ``recipe uses DEPENDS_${PN}, should use DEPENDS [pkgvarcheck]``
+
+   This check looks for instances of setting ``DEPENDS_${PN}``
+   which is erroneous (:term:`DEPENDS` is a recipe-wide variable and thus
+   it is not correct to specify it for a particular package, nor will such
+   an assignment actually work.) Set ``DEPENDS`` instead.
+
+
+.. _qa-check-already-stripped:
 
 -  ``File '<file>' from <recipename> was already stripped, this will prevent future debugging! [already-stripped]``
 
@@ -458,6 +496,7 @@ Errors and Warnings
       strip the symbols from the binaries.
 
     
+.. _qa-check-packages-list:
 
 -  ``<packagename> is listed in PACKAGES multiple times, this leads to packaging errors. [packages-list]``
 
@@ -467,6 +506,7 @@ Errors and Warnings
    already in the variable's value.
 
     
+.. _qa-check-files-invalid:
 
 -  ``FILES variable for package <packagename> contains '//' which is invalid. Attempting to fix this but you should correct the metadata. [files-invalid]``
 
@@ -475,6 +515,7 @@ Errors and Warnings
    that there is only a single "/".
 
     
+.. _qa-check-installed-vs-shipped:
 
 -  ``<recipename>: Files/directories were installed but not shipped in any package [installed-vs-shipped]``
 
@@ -505,6 +546,9 @@ Errors and Warnings
    :term:`PRIVATE_LIBS` in the recipe that provides
    the private version of the library.
 
+
+.. _qa-check-unlisted-pkg-lics:
+
 -  ``LICENSE_<packagename> includes licenses (<licenses>) that are not listed in LICENSE [unlisted-pkg-lics]``
 
    The :term:`LICENSE` of the recipe should be a superset
@@ -512,7 +556,192 @@ Errors and Warnings
    words, any license in ``LICENSE_*`` should also appear in
    :term:`LICENSE`.
 
-    
+
+.. _qa-check-configure-gettext:
+
+-  ``AM_GNU_GETTEXT used but no inherit gettext [configure-gettext]``
+
+    If a recipe is building something that uses automake and the automake
+    files contain an ``AM_GNU_GETTEXT`` directive then this check will fail
+    if there is no ``inherit gettext`` statement in the recipe to ensure
+    that gettext is available during the build. Add ``inherit gettext`` to
+    remove the warning.
+
+
+.. _qa-check-mime:
+
+- ``package contains mime types but does not inherit mime: <packagename> path '<file>' [mime]``
+
+   The specified package contains mime type files (``.xml`` files in
+   ``${datadir}/mime/packages``) and yet does not inherit the mime
+   class which will ensure that these get properly installed. Either
+   add ``inherit mime`` to the recipe or remove the files at the
+   ``do_install`` step if they are not needed.
+
+
+.. _qa-check-mime-xdg:
+
+- ``package contains desktop file with key 'MimeType' but does not inhert mime-xdg: <packagename> path '<file>' [mime-xdg]``
+
+    The specified package contains a .desktop file with a 'MimeType' key
+    present, but does not inherit the mime-xdg class that is required in
+    order for that to be activated. Either add ``inherit mime`` to the
+    recipe or remove the files at the ``do_install`` step if they are not
+    needed.
+
+
+.. _qa-check-src-uri-bad:
+
+- ``<recipename>: SRC_URI uses unstable GitHub archives [src-uri-bad]``
+
+    GitHub provides "archive" tarballs, however these can be re-generated
+    on the fly and thus the file's signature will not necessarily match that
+    in the SRC_URI checksums in future leading to build failures. It is
+    recommended that you use an official release tarball or switch to
+    pulling the corresponding revision in the actual git repository instead.
+
+
+- ``SRC_URI uses PN not BPN [src-uri-bad]``
+
+    If some part of :term:`SRC_URI` needs to reference the recipe name, it should do
+    so using ${:term:`BPN`} rather than ${:term:`PN`} as the latter will change
+    for different variants of the same recipe e.g. when :term:`BBCLASSEXTEND`
+    or multilib are being used. This check will fail if a reference to ``${PN}``
+    is found within the ``SRC_URI`` value - change it to ``${BPN}`` instead.
+
+
+.. _qa-check-unhandled-features-check:
+
+- ``<recipename>: recipe doesn't inherit features_check [unhandled-features-check]``
+
+    This check ensures that if one of the variables that the :ref:`features_check <ref-classes-features_check>`
+    class supports (e.g. :term:`REQUIRED_DISTRO_FEATURES`) is used, then the recipe
+    inherits ``features_check`` in order for the requirement to actually work. If
+    you are seeing this message, either add ``inherit features_check`` to your recipe
+    or remove the reference to the variable if it is not needed.
+
+
+.. _qa-check-missing-update-alternatives:
+
+- ``<recipename>: recipe defines ALTERNATIVE_<packagename> but doesn't inherit update-alternatives. This might fail during do_rootfs later! [missing-update-alternatives]``
+
+    This check ensures that if a recipe sets the :term:`ALTERNATIVE` variable that the
+    recipe also inherits :ref:`update-alternatives <ref-classes-update-alternatives>` such
+    that the alternative will be correctly set up. If you are seeing this message, either
+    add ``inherit update-alternatives`` to your recipe or remove the reference to the variable
+    if it is not needed.
+
+
+.. _qa-check-shebang-size:
+
+- ``<packagename>: <file> maximum shebang size exceeded, the maximum size is 128. [shebang-size]``
+
+    This check ensures that the shebang line (``#!`` in the first line) for a script
+    is not longer than 128 characters, which can cause an error at runtime depending
+    on the operating system. If you are seeing this message then the specified script
+    may need to be patched to have a shorter in order to avoid runtime problems.
+
+
+.. _qa-check-perllocalpod:
+
+- ``<packagename> contains perllocal.pod (<files>), should not be installed [perllocalpod]``
+
+    ``perllocal.pod`` is an index file of locally installed modules and so shouldn't be
+    installed by any distribution packages. The :ref:`cpan <ref-classes-cpan>` class
+    already sets ``NO_PERLLOCAL`` to stop this file being generated by most Perl recipes,
+    but if a recipe is using ``MakeMaker`` directly then they might not be doing this
+    correctly. This check ensures that perllocal.pod is not in any package in order to
+    avoid multiple packages shipping this file and thus their packages conflicting
+    if installed together.
+
+
+.. _qa-check-usrmerge:
+
+- ``<packagename> package is not obeying usrmerge distro feature. /<path> should be relocated to /usr. [usrmerge]``
+
+    If ``usrmerge`` is in :term:`DISTRO_FEATURES`, this check will ensure that no package
+    installs files to root (``/bin``, ``/sbin``, ``/lib``, ``/lib64``) directories. If you are seeing this
+    message, it indicates that the ``do_install`` step (or perhaps the build process that
+    ``do_install`` is calling into, e.g. ``make install`` is using hardcoded paths instead
+    of the variables set up for this (``bindir``, ``sbindir``, etc.), and should be
+    changed so that it does.
+
+
+.. _qa-check-patch-fuzz:
+
+- ``Fuzz detected: <patch output> [patch-fuzz]``
+
+    This check looks for evidence of "fuzz" when applying patches within the ``do_patch``
+    task. Patch fuzz is a situation when the ``patch`` tool ignores some of the context
+    lines in order to apply the patch. Consider this example:
+
+    Patch to be applied: ::
+
+        --- filename
+        +++ filename
+         context line 1
+         context line 2
+         context line 3
+        +newly added line
+         context line 4
+         context line 5
+         context line 6
+
+    Original source code: ::
+
+        different context line 1
+        different context line 2
+        context line 3
+        context line 4
+        different context line 5
+        different context line 6
+
+    Outcome (after applying patch with fuzz): ::
+
+        different context line 1
+        different context line 2
+        context line 3
+        newly added line
+        context line 4
+        different context line 5
+        different context line 6
+
+    Chances are, the newly added line was actually added in a completely
+    wrong location, or it was already in the original source and was added
+    for the second time. This is especially possible if the context line 3
+    and 4 are blank or have only generic things in them, such as ``#endif`` or ``}``.
+    Depending on the patched code, it is entirely possible for an incorrectly
+    patched file to still compile without errors.
+
+    *How to eliminate patch fuzz warnings*
+
+    Use the ``devtool`` command as explained by the warning. First, unpack the
+    source into devtool workspace: ::
+
+            devtool modify <recipe>
+
+    This will apply all of the patches, and create new commits out of them in
+    the workspace - with the patch context updated.
+
+    Then, replace the patches in the recipe layer: ::
+
+            devtool finish --force-patch-refresh <recipe> <layer_path>
+
+    The patch updates then need be reviewed (preferably with a side-by-side diff
+    tool) to ensure they are indeed doing the right thing i.e.:
+
+    #. they are applied in the correct location within the file;
+    #. they do not introduce duplicate lines, or otherwise do things that
+       are no longer necessary.
+
+    To confirm these things, you can also review the patched source code in
+    devtool's workspace, typically in ``<build_dir>/workspace/sources/<recipe>/``
+
+    Once the review is done, you can create and publish a layer commit with
+    the patch updates that modify the context. Devtool may also refresh
+    other things in the patches, those can be discarded.
+
+
 
 Configuring and Disabling QA Checks
 ===================================

documentation/ref-manual/ref-variables.rst

@@ -132,6 +132,18 @@ system and gives an overview of their function and contents.
       ":ref:`update-alternatives.bbclass <ref-classes-update-alternatives>`"
       section.
 
+   :term:`ANY_OF_DISTRO_FEATURES`
+      When inheriting the
+      :ref:`features_check <ref-classes-features_check>`
+      class, this variable identifies a list of distribution features where
+      at least one must be enabled in the current configuration in order
+      for the OpenEmbedded build system to build the recipe. In other words,
+      if none of the features listed in ``ANY_OF_DISTRO_FEATURES``
+      appear in ``DISTRO_FEATURES`` within the current configuration, then
+      the recipe will be skipped, and if the build system attempts to build
+      the recipe then an error will be triggered.
+      
+
    :term:`APPEND`
       An override list of append strings for each target specified with
       :term:`LABELS`.
@@ -1300,12 +1312,13 @@ system and gives an overview of their function and contents.
 
    :term:`CONFLICT_DISTRO_FEATURES`
       When inheriting the
-      :ref:`distro_features_check <ref-classes-distro_features_check>`
+      :ref:`features_check <ref-classes-features_check>`
       class, this variable identifies distribution features that would be
       in conflict should the recipe be built. In other words, if the
       ``CONFLICT_DISTRO_FEATURES`` variable lists a feature that also
-      appears in ``DISTRO_FEATURES`` within the current configuration, an
-      error occurs and the build stops.
+      appears in ``DISTRO_FEATURES`` within the current configuration, then
+      the recipe will be skipped, and if the build system attempts to build
+      the recipe then an error will be triggered.
 
    :term:`COPYLEFT_LICENSE_EXCLUDE`
       A space-separated list of licenses to exclude from the source
@@ -3085,6 +3098,17 @@ system and gives an overview of their function and contents.
       See the :term:`GLIBC_GENERATE_LOCALES`
       variable for information on generating GLIBC locales.
 
+
+   :term:`IMAGE_LINK_NAME`
+      The name of the output image symlink (which does not include
+      the version part as :term:`IMAGE_NAME` does). The default value
+      is derived using the :term:`IMAGE_BASENAME` and :term:`MACHINE`
+      variables:
+      ::
+
+         IMAGE_LINK_NAME ?= "${IMAGE_BASENAME}-${MACHINE}"
+
+
    :term:`IMAGE_MANIFEST`
       The manifest file for the image. This file lists all the installed
       packages that make up the image. The file contains package
@@ -3108,11 +3132,18 @@ system and gives an overview of their function and contents.
    :term:`IMAGE_NAME`
       The name of the output image files minus the extension. This variable
       is derived using the :term:`IMAGE_BASENAME`,
-      :term:`MACHINE`, and :term:`DATETIME`
+      :term:`MACHINE`, and :term:`IMAGE_VERSION_SUFFIX`
       variables:
       ::
 
-         IMAGE_NAME = "${IMAGE_BASENAME}-${MACHINE}-${DATETIME}"
+         IMAGE_NAME ?= "${IMAGE_BASENAME}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
+
+   :term:`IMAGE_NAME_SUFFIX`
+      Suffix used for the image output file name - defaults to ``".rootfs"``
+      to distinguish the image file from other files created during image
+      building; however if this suffix is redundant or not desired you can
+      clear the value of this variable (set the value to ""). For example,
+      this is typically cleared in initramfs image recipes.
 
    :term:`IMAGE_OVERHEAD_FACTOR`
       Defines a multiplier that the build system applies to the initial
@@ -3316,6 +3347,14 @@ system and gives an overview of their function and contents.
       For more information about these types of images, see
       ``meta/classes/image_types*.bbclass`` in the :term:`Source Directory`.
 
+   :term:`IMAGE_VERSION_SUFFIX`
+      Version suffix that is part of the default :term:`IMAGE_NAME` and
+      :term:`KERNEL_ARTIFACT_NAME` values.
+      Defaults to ``"-${DATETIME}"``, however you could set this to a
+      version string that comes from your external build environment if
+      desired, and this suffix would then be used consistently across
+      the build artifacts.
+
    :term:`INC_PR`
       Helps define the recipe revision for recipes that share a common
       ``include`` file. You can think of this variable as part of the
@@ -3774,12 +3813,8 @@ system and gives an overview of their function and contents.
 
          KERNEL_ARTIFACT_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}${IMAGE_VERSION_SUFFIX}"
 
-      See the :term:`PKGE`, :term:`PKGV`, :term:`PKGR`, and :term:`MACHINE`
-      variables for additional information.
-
-      .. note::
-
-         The ``IMAGE_VERSION_SUFFIX`` variable is set to :term:`DATETIME`.
+      See the :term:`PKGE`, :term:`PKGV`, :term:`PKGR`, :term:`MACHINE`
+      and :term:`IMAGE_VERSION_SUFFIX` variables for additional information.
 
    :term:`KERNEL_CLASSES`
       A list of classes defining kernel image types that the
@@ -5104,7 +5139,7 @@ system and gives an overview of their function and contents.
 
       .. note::
 
-         You can use the ``PACKAGE_FEEDS_ARCHS``
+         You can use the ``PACKAGE_FEED_ARCHS``
          variable to whitelist specific package architectures. If you do
          not need to whitelist specific architectures, which is a common
          case, you can omit this variable. Omitting the variable results in
@@ -5919,6 +5954,15 @@ system and gives an overview of their function and contents.
       service <dev-manual/dev-manual-common-tasks:working with a pr service>`. You can
       set ``PRSERV_HOST`` to other values to use a remote PR service.
 
+
+   :term:`PSEUDO_IGNORE_PATHS`
+      A comma-separated (without spaces) list of path prefixes that should be ignored
+      by pseudo when monitoring and recording file operations, in order to avoid
+      problems with files being written to outside of the pseudo context and
+      reduce pseudo's overhead. A path is ignored if it matches any prefix in the list
+      and can include partial directory (or file) names.
+
+
    :term:`PTEST_ENABLED`
       Specifies whether or not :ref:`Package
       Test <dev-manual/dev-manual-common-tasks:testing packages with ptest>` (ptest)
@@ -6122,13 +6166,14 @@ system and gives an overview of their function and contents.
 
    :term:`REQUIRED_DISTRO_FEATURES`
       When inheriting the
-      :ref:`distro_features_check <ref-classes-distro_features_check>`
+      :ref:`features_check <ref-classes-features_check>`
       class, this variable identifies distribution features that must exist
       in the current configuration in order for the OpenEmbedded build
       system to build the recipe. In other words, if the
       ``REQUIRED_DISTRO_FEATURES`` variable lists a feature that does not
-      appear in ``DISTRO_FEATURES`` within the current configuration, an
-      error occurs and the build stops.
+      appear in ``DISTRO_FEATURES`` within the current configuration, then
+      the recipe will be skipped, and if the build system attempts to build
+      the recipe then an error will be triggered.
 
    :term:`RM_WORK_EXCLUDE`
       With ``rm_work`` enabled, this variable specifies a list of recipes

documentation/releases.rst

@@ -4,6 +4,12 @@
  Current Release Manuals
 =========================
 
+*******************************
+3.2 'gatesgarth' Release Series
+*******************************
+
+- :yocto_docs:`3.2 Documentation </3.2>`
+
 ****************************
 3.1 'dunfell' Release Series
 ****************************
@@ -11,6 +17,7 @@
 - :yocto_docs:`3.1 Documentation </3.1>`
 - :yocto_docs:`3.1.1 Documentation </3.1.1>`
 - :yocto_docs:`3.1.2 Documentation </3.1.2>`
+- :yocto_docs:`3.1.3 Documentation </3.1.3>`
 
 ==========================
  Previous Release Manuals

documentation/sphinx-static/switchers.js

@@ -2,7 +2,8 @@
   'use strict';
 
   var all_versions = {
-    'dev': 'dev (3.2)',
+    'dev': 'dev (3.3)',
+    '3.2': '3.2',
     '3.1.3': '3.1.3',
     '3.0.4': '3.0.4',
     '2.7.4': '2.7.4',

meta-poky/conf/distro/poky.conf

@@ -1,6 +1,6 @@
 DISTRO = "poky"
 DISTRO_NAME = "Poky (Yocto Project Reference Distro)"
-DISTRO_VERSION = "3.2"
+DISTRO_VERSION = "3.2.1"
 DISTRO_CODENAME = "gatesgarth"
 SDK_VENDOR = "-pokysdk"
 SDK_VERSION = "${@d.getVar('DISTRO_VERSION').replace('snapshot-${DATE}', 'snapshot')}"

meta/classes/cve-check.bbclass

@@ -208,6 +208,9 @@ def check_cves(d, patched_cves):
     """
     from distutils.version import LooseVersion
 
+    pn = d.getVar("PN")
+    real_pv = d.getVar("PV")
+
     cves_unpatched = []
     # CVE_PRODUCT can contain more than one product (eg. curl/libcurl)
     products = d.getVar("CVE_PRODUCT").split()
@@ -217,7 +220,7 @@ def check_cves(d, patched_cves):
     pv = d.getVar("CVE_VERSION").split("+git")[0]
 
     # If the recipe has been whitlisted we return empty lists
-    if d.getVar("PN") in d.getVar("CVE_CHECK_PN_WHITELIST").split():
+    if pn in d.getVar("CVE_CHECK_PN_WHITELIST").split():
         bb.note("Recipe has been whitelisted, skipping check")
         return ([], [], [])
 
@@ -286,12 +289,12 @@ def check_cves(d, patched_cves):
                         vulnerable = vulnerable_start or vulnerable_end
 
                 if vulnerable:
-                    bb.note("%s-%s is vulnerable to %s" % (product, pv, cve))
+                    bb.note("%s-%s is vulnerable to %s" % (pn, real_pv, cve))
                     cves_unpatched.append(cve)
                     break
 
             if not vulnerable:
-                bb.note("%s-%s is not vulnerable to %s" % (product, pv, cve))
+                bb.note("%s-%s is not vulnerable to %s" % (pn, real_pv, cve))
                 # TODO: not patched but not vulnerable
                 patched_cves.add(cve)
 

meta/classes/distutils-common-base.bbclass

@@ -11,7 +11,7 @@ export LDCXXSHARED  = "${CXX} -shared"
 export CCSHARED  = "-fPIC -DPIC"
 # LINKFORSHARED are the flags passed to the $(CC) command that links
 # the python executable
-export LINKFORSHARED = "{SECURITY_CFLAGS} -Xlinker -export-dynamic"
+export LINKFORSHARED = "${SECURITY_CFLAGS} -Xlinker -export-dynamic"
 
 FILES_${PN} += "${libdir}/* ${libdir}/${PYTHON_DIR}/*"
 

meta/classes/kernel-module-split.bbclass

@@ -120,6 +120,7 @@ python split_kernel_module_packages () {
         files = d.getVar('FILES_%s' % pkg)
         files = "%s /etc/modules-load.d/%s.conf /etc/modprobe.d/%s.conf" % (files, basename, basename)
         d.setVar('FILES_%s' % pkg, files)
+        d.setVar('CONFFILES_%s' % pkg, files)
 
         if "description" in vals:
             old_desc = d.getVar('DESCRIPTION_' + pkg) or ""

meta/classes/kernel.bbclass

@@ -383,6 +383,10 @@ do_compile_kernelmodules() {
 		# other kernel modules and will look at this
 		# file to do symbol lookups
 		cp ${B}/Module.symvers ${STAGING_KERNEL_BUILDDIR}/
+		# 5.10+ kernels have module.lds that we need to copy for external module builds
+		if [ -e "${B}/scripts/module.lds" ]; then
+			install -Dm 0644 ${B}/scripts/module.lds ${STAGING_KERNEL_BUILDDIR}/scripts/module.lds
+		fi
 	else
 		bbnote "no modules to compile"
 	fi
@@ -586,7 +590,7 @@ addtask savedefconfig after do_configure
 
 inherit cml1
 
-KCONFIG_CONFIG_COMMAND_append = " HOSTLDFLAGS='${BUILD_LDFLAGS}'"
+KCONFIG_CONFIG_COMMAND_append = " LD='${KERNEL_LD}' HOSTLDFLAGS='${BUILD_LDFLAGS}'"
 
 EXPORT_FUNCTIONS do_compile do_install do_configure
 

meta/classes/license_image.bbclass

@@ -125,7 +125,6 @@ def write_license_files(d, license_manifest, pkg_dic, rootfs=True):
 
                 licenses = os.listdir(pkg_license_dir)
                 for lic in licenses:
-                    rootfs_license = os.path.join(rootfs_license_dir, lic)
                     pkg_license = os.path.join(pkg_license_dir, lic)
                     pkg_rootfs_license = os.path.join(pkg_rootfs_license_dir, lic)
 
@@ -144,6 +143,8 @@ def write_license_files(d, license_manifest, pkg_dic, rootfs=True):
                                 bad_licenses) == False:
                             continue
 
+                        # Make sure we use only canonical name for the license file
+                        rootfs_license = os.path.join(rootfs_license_dir, "generic_%s" % generic_lic)
                         if not os.path.exists(rootfs_license):
                             oe.path.copyhardlink(pkg_license, rootfs_license)
 

meta/classes/package.bbclass

@@ -2340,7 +2340,7 @@ python do_package () {
     # cache.  This is useful if an item this class depends on changes in a
     # way that the output of this class changes.  rpmdeps is a good example
     # as any change to rpmdeps requires this to be rerun.
-    # PACKAGE_BBCLASS_VERSION = "2"
+    # PACKAGE_BBCLASS_VERSION = "4"
 
     # Init cachedpath
     global cpath

meta/classes/qemuboot.bbclass

@@ -43,7 +43,7 @@
 #                          QB_NETWORK_DEVICE_prepend might be used, since Qemu enumerates the eth*
 #                          devices in reverse order to -device arguments.
 #
-# QB_TAP_OPT: netowrk option for 'tap' mode, e.g.,
+# QB_TAP_OPT: network option for 'tap' mode, e.g.,
 #             "-netdev tap,id=net0,ifname=@TAP@,script=no,downscript=no"
 #              Note, runqemu will replace "@TAP@" with the one which is used, such as tap0, tap1 ...
 #

meta/classes/rootfs_deb.bbclass

@@ -7,7 +7,7 @@ ROOTFS_PKGMANAGE = "dpkg apt"
 do_rootfs[depends] += "dpkg-native:do_populate_sysroot apt-native:do_populate_sysroot"
 do_populate_sdk[depends] += "dpkg-native:do_populate_sysroot apt-native:do_populate_sysroot bzip2-native:do_populate_sysroot"
 do_rootfs[recrdeptask] += "do_package_write_deb do_package_qa"
-do_rootfs[vardeps] += "PACKAGE_FEED_URIS"
+do_rootfs[vardeps] += "PACKAGE_FEED_URIS PACKAGE_FEED_BASE_PATHS PACKAGE_FEED_ARCHS"
 
 do_rootfs[lockfiles] += "${DEPLOY_DIR_DEB}/deb.lock"
 do_populate_sdk[lockfiles] += "${DEPLOY_DIR_DEB}/deb.lock"

meta/classes/rootfs_ipk.bbclass

@@ -11,7 +11,7 @@ ROOTFS_PKGMANAGE = "opkg ${EXTRAOPKGCONFIG}"
 do_rootfs[depends] += "opkg-native:do_populate_sysroot opkg-utils-native:do_populate_sysroot"
 do_populate_sdk[depends] += "opkg-native:do_populate_sysroot opkg-utils-native:do_populate_sysroot"
 do_rootfs[recrdeptask] += "do_package_write_ipk do_package_qa"
-do_rootfs[vardeps] += "PACKAGE_FEED_URIS"
+do_rootfs[vardeps] += "PACKAGE_FEED_URIS PACKAGE_FEED_BASE_PATHS PACKAGE_FEED_ARCHS"
 
 do_rootfs[lockfiles] += "${WORKDIR}/ipk.lock"
 do_populate_sdk[lockfiles] += "${WORKDIR}/ipk.lock"

meta/classes/rootfs_rpm.bbclass

@@ -24,7 +24,7 @@ do_rootfs[depends] += "${RPMROOTFSDEPENDS}"
 do_populate_sdk[depends] += "${RPMROOTFSDEPENDS}"
 
 do_rootfs[recrdeptask] += "do_package_write_rpm do_package_qa"
-do_rootfs[vardeps] += "PACKAGE_FEED_URIS"
+do_rootfs[vardeps] += "PACKAGE_FEED_URIS PACKAGE_FEED_BASE_PATHS PACKAGE_FEED_ARCHS"
 
 python () {
     if d.getVar('BUILD_IMAGES_FROM_FEEDS'):

meta/classes/testimage.bbclass

@@ -367,6 +367,7 @@ def testimage_main(d):
     package_extraction(d, tc.suites)
 
     results = None
+    complete = False
     orig_sigterm_handler = signal.signal(signal.SIGTERM, sigterm_exception)
     try:
         # We need to check if runqemu ends unexpectedly
@@ -378,6 +379,7 @@ def testimage_main(d):
         except ValueError:
             pass
         results = tc.runTests()
+        complete = True
     except (KeyboardInterrupt, BlockingIOError) as err:
         if isinstance(err, KeyboardInterrupt):
             bb.error('testimage interrupted, shutting down...')
@@ -385,20 +387,21 @@ def testimage_main(d):
             bb.error('runqemu failed, shutting down...')
         if results:
             results.stop()
-            results = None
+        results = tc.results
     finally:
         signal.signal(signal.SIGTERM, orig_sigterm_handler)
         tc.target.stop()
 
     # Show results (if we have them)
-    if not results:
+    if results:
+        configuration = get_testimage_configuration(d, 'runtime', machine)
+        results.logDetails(get_testimage_json_result_dir(d),
+                        configuration,
+                        get_testimage_result_id(configuration),
+                        dump_streams=d.getVar('TESTREPORT_FULLLOGS'))
+        results.logSummary(pn)
+    if not results or not complete:
         bb.fatal('%s - FAILED - tests were interrupted during execution' % pn, forcelog=True)
-    configuration = get_testimage_configuration(d, 'runtime', machine)
-    results.logDetails(get_testimage_json_result_dir(d),
-                       configuration,
-                       get_testimage_result_id(configuration),
-                       dump_streams=d.getVar('TESTREPORT_FULLLOGS'))
-    results.logSummary(pn)
     if not results.wasSuccessful():
         bb.fatal('%s - FAILED - check the task log and the ssh log' % pn, forcelog=True)
 

meta/conf/abi_version.conf

@@ -12,4 +12,4 @@ OELAYOUT_ABI = "14"
 # a reset of the equivalence, for example when reproducibility issues break the
 # existing match data. Distros can also append to this value for the same effect.
 #
-HASHEQUIV_HASH_VERSION  = "3"
+HASHEQUIV_HASH_VERSION  = "4"

meta/conf/bitbake.conf

@@ -685,7 +685,7 @@ SRC_URI = ""
 PSEUDO_LOCALSTATEDIR ?= "${WORKDIR}/pseudo/"
 PSEUDO_PASSWD ?= "${STAGING_DIR_TARGET}:${PSEUDO_SYSROOT}"
 PSEUDO_SYSROOT = "${COMPONENTS_DIR}/${BUILD_ARCH}/pseudo-native"
-PSEUDO_IGNORE_PATHS = "/usr/,/etc/,/lib,/dev/,${T},${WORKDIR}/recipe-sysroot,${SSTATE_DIR},${STAMPS_DIR},${WORKDIR}/pkgdata-sysroot,${TMPDIR}/sstate-control,${DEPLOY_DIR},${WORKDIR}/deploy-,${TMPDIR}/buildstats,${WORKDIR}/sstate-build-package_,${WORKDIR}/sstate-install-package_,${WORKDIR}/sstate-build-image_complete,${TMPDIR}/sysroots-components,${BUILDHISTORY_DIR},${TMPDIR}/pkgdata,${TOPDIR}/cache,${COREBASE}/scripts,${COREBASE}/meta"
+PSEUDO_IGNORE_PATHS = "/usr/,/etc/,/lib,/dev/,${T},${WORKDIR}/recipe-sysroot,${SSTATE_DIR},${STAMPS_DIR},${WORKDIR}/pkgdata-sysroot,${TMPDIR}/sstate-control,${DEPLOY_DIR},${WORKDIR}/deploy-,${TMPDIR}/buildstats,${WORKDIR}/sstate-build-package_,${WORKDIR}/sstate-install-package_,${WORKDIR}/sstate-build-image_complete,${TMPDIR}/sysroots-components,${BUILDHISTORY_DIR},${TMPDIR}/pkgdata,${TOPDIR}/cache,${COREBASE}/scripts,${COREBASE}/meta,${CCACHE_DIR}"
 
 export PSEUDO_DISABLED = "1"
 #export PSEUDO_PREFIX = "${STAGING_DIR_NATIVE}${prefix_native}"

meta/conf/conf-notes.txt

@@ -5,7 +5,9 @@ You can now run 'bitbake <target>'
 
 Common targets are:
     core-image-minimal
+    core-image-full-cmdline
     core-image-sato
+    core-image-weston
     meta-toolchain
     meta-ide-support
 

meta/conf/layer.conf

@@ -104,4 +104,4 @@ SSTATE_EXCLUDEDEPS_SYSROOT += ".*->autoconf-archive-native"
 # We need to keep bitbake tools in PATH
 # Avoid empty path entries
 BITBAKEPATH := "${@os.path.dirname(bb.utils.which(d.getVar('PATH'),'bitbake'))}"
-PATH := "${@'${BITBAKEPATH}:' if '${BITBAKEPATH}' is not '' else ''}${HOSTTOOLS_DIR}"
+PATH := "${@'${BITBAKEPATH}:' if '${BITBAKEPATH}' != '' else ''}${HOSTTOOLS_DIR}"

meta/files/common-licenses/bzip2-1.0.4

@@ -0,0 +1,43 @@
+
+--------------------------------------------------------------------------
+
+This program, "bzip2", the associated library "libbzip2", and all
+documentation, are copyright (C) 1996-2006 Julian R Seward.  All
+rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+
+1. Redistributions of source code must retain the above copyright
+   notice, this list of conditions and the following disclaimer.
+
+2. The origin of this software must not be misrepresented; you must 
+   not claim that you wrote the original software.  If you use this 
+   software in a product, an acknowledgment in the product 
+   documentation would be appreciated but is not required.
+
+3. Altered source versions must be plainly marked as such, and must
+   not be misrepresented as being the original software.
+
+4. The name of the author may not be used to endorse or promote 
+   products derived from this software without specific prior written 
+   permission.
+
+THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS
+OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
+DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
+GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
+WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
+NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+Julian Seward, Cambridge, UK.
+jseward@bzip.org
+bzip2/libbzip2 version 1.0.4 of 20 December 2006
+
+--------------------------------------------------------------------------

meta/files/fs-perms-persistent-log.txt

@@ -41,7 +41,7 @@ ${includedir}		0755	root	root	true	0644	root	root
 ${oldincludedir}	0755	root	root	true	0644	root	root
 
 # Cleanup debug src
-/usr/src/debug		0755	root	root	true	-	root	root
+/usr/src/debug		0755	root	root	true	0644	root	root
 
 # Items from base-files
 # Links

meta/files/fs-perms.txt

@@ -41,7 +41,7 @@ ${includedir}		0755	root	root	true	0644	root	root
 ${oldincludedir}	0755	root	root	true	0644	root	root
 
 # Cleanup debug src
-/usr/src/debug		0755	root	root	true	-	root	root
+/usr/src/debug		0755	root	root	true	0644	root	root
 
 # Items from base-files
 # Links

meta/lib/oe/buildhistory_analysis.py

@@ -373,8 +373,10 @@ def compare_file_lists(alines, blines, compare_ownership=True):
                                 removals.remove(removal2)
                     continue
             filechanges.append(FileChange(removal, FileChange.changetype_move, addition))
-            additions.remove(addition)
-            removals.remove(removal)
+            if addition in additions:
+                additions.remove(addition)
+            if removal in removals:
+                removals.remove(removal)
     for rename in renames:
         filechanges.append(FileChange(renames[rename], FileChange.changetype_move, rename))
 

meta/lib/oe/package_manager/deb/__init__.py

@@ -282,7 +282,7 @@ class DpkgPM(OpkgDpkgPM):
 
         os.environ['APT_CONFIG'] = self.apt_conf_file
 
-        cmd = "%s %s install --force-yes --allow-unauthenticated --no-remove %s" % \
+        cmd = "%s %s install --allow-downgrades --allow-remove-essential --allow-change-held-packages --allow-unauthenticated --no-remove %s" % \
               (self.apt_get_cmd, self.apt_args, ' '.join(pkgs))
 
         try:

meta/lib/oe/sstatesig.py

@@ -484,6 +484,9 @@ def OEOuthashBasic(path, sigfile, task, d):
     include_owners = os.environ.get('PSEUDO_DISABLED') == '0'
     if "package_write_" in task or task == "package_qa":
         include_owners = False
+    include_timestamps = False
+    if task == "package":
+        include_timestamps = d.getVar('BUILD_REPRODUCIBLE_BINARIES') == '1'
     extra_content = d.getVar('HASHEQUIV_HASH_VERSION')
 
     try:
@@ -558,6 +561,9 @@ def OEOuthashBasic(path, sigfile, task, d):
                         bb.warn("KeyError in %s" % path)
                         raise
 
+                if include_timestamps:
+                    update_hash(" %10d" % s.st_mtime)
+
                 update_hash(" ")
                 if stat.S_ISBLK(s.st_mode) or stat.S_ISCHR(s.st_mode):
                     update_hash("%9s" % ("%d.%d" % (os.major(s.st_rdev), os.minor(s.st_rdev))))

meta/lib/oeqa/core/context.py

@@ -31,6 +31,9 @@ class OETestContext(object):
         self._registry = {}
         self._registry['cases'] = collections.OrderedDict()
 
+        self.results = unittest.TestResult()
+        unittest.registerResult(self.results)
+
     def _read_modules_from_manifest(self, manifest):
         if not os.path.exists(manifest):
             raise OEQAMissingManifest("Manifest does not exist on %s" % manifest)
@@ -82,6 +85,7 @@ class OETestContext(object):
         self.skipTests(skips)
 
         self._run_start_time = time.time()
+        self._run_end_time = self._run_start_time
         if not processes:
             self.runner.buffer = True
         result = self.runner.run(self.prepareSuite(self.suites, processes))

meta/recipes-bsp/grub/files/CVE-2020-15706-script-Avoid-a-use-after-free-when-redefining-a-func.patch

@@ -0,0 +1,117 @@
+From c65fc7e75b7b7e880d90766057040011701e97f4 Mon Sep 17 00:00:00 2001
+From: Chris Coulson <chris.coulson@canonical.com>
+Date: Fri, 10 Jul 2020 14:41:45 +0100
+Subject: [PATCH 8/9] script: Avoid a use-after-free when redefining a function
+ during execution
+
+Defining a new function with the same name as a previously defined
+function causes the grub_script and associated resources for the
+previous function to be freed. If the previous function is currently
+executing when a function with the same name is defined, this results
+in use-after-frees when processing subsequent commands in the original
+function.
+
+Instead, reject a new function definition if it has the same name as
+a previously defined function, and that function is currently being
+executed. Although a behavioural change, this should be backwards
+compatible with existing configurations because they can't be
+dependent on the current behaviour without being broken.
+
+Fixes: CVE-2020-15706
+
+Signed-off-by: Chris Coulson <chris.coulson@canonical.com>
+Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
+
+Upstream-Status: Backport
+CVE: CVE-2020-15706
+
+Reference to upstream patch:
+https://git.savannah.gnu.org/cgit/grub.git/commit/?id=426f57383d647406ae9c628c472059c27cd6e040
+
+Signed-off-by: Yongxin Liu <yongxin.liu@windriver.com>
+---
+ grub-core/script/execute.c  |  2 ++
+ grub-core/script/function.c | 16 +++++++++++++---
+ grub-core/script/parser.y   |  3 ++-
+ include/grub/script_sh.h    |  2 ++
+ 4 files changed, 19 insertions(+), 4 deletions(-)
+
+diff --git a/grub-core/script/execute.c b/grub-core/script/execute.c
+index c8d6806..7e028e1 100644
+--- a/grub-core/script/execute.c
++++ b/grub-core/script/execute.c
+@@ -838,7 +838,9 @@ grub_script_function_call (grub_script_function_t func, int argc, char **args)
+   old_scope = scope;
+   scope = &new_scope;
+ 
++  func->executing++;
+   ret = grub_script_execute (func->func);
++  func->executing--;
+ 
+   function_return = 0;
+   active_loops = loops;
+diff --git a/grub-core/script/function.c b/grub-core/script/function.c
+index d36655e..3aad04b 100644
+--- a/grub-core/script/function.c
++++ b/grub-core/script/function.c
+@@ -34,6 +34,7 @@ grub_script_function_create (struct grub_script_arg *functionname_arg,
+   func = (grub_script_function_t) grub_malloc (sizeof (*func));
+   if (! func)
+     return 0;
++  func->executing = 0;
+ 
+   func->name = grub_strdup (functionname_arg->str);
+   if (! func->name)
+@@ -60,10 +61,19 @@ grub_script_function_create (struct grub_script_arg *functionname_arg,
+       grub_script_function_t q;
+ 
+       q = *p;
+-      grub_script_free (q->func);
+-      q->func = cmd;
+       grub_free (func);
+-      func = q;
++      if (q->executing > 0)
++        {
++          grub_error (GRUB_ERR_BAD_ARGUMENT,
++		      N_("attempt to redefine a function being executed"));
++          func = NULL;
++        }
++      else
++        {
++          grub_script_free (q->func);
++          q->func = cmd;
++          func = q;
++        }
+     }
+   else
+     {
+diff --git a/grub-core/script/parser.y b/grub-core/script/parser.y
+index 4f0ab83..f80b86b 100644
+--- a/grub-core/script/parser.y
++++ b/grub-core/script/parser.y
+@@ -289,7 +289,8 @@ function: "function" "name"
+ 	      grub_script_mem_free (state->func_mem);
+ 	    else {
+ 	      script->children = state->scripts;
+-	      grub_script_function_create ($2, script);
++	      if (!grub_script_function_create ($2, script))
++		grub_script_free (script);
+ 	    }
+ 
+ 	    state->scripts = $<scripts>3;
+diff --git a/include/grub/script_sh.h b/include/grub/script_sh.h
+index b382bcf..6c48e07 100644
+--- a/include/grub/script_sh.h
++++ b/include/grub/script_sh.h
+@@ -361,6 +361,8 @@ struct grub_script_function
+ 
+   /* The next element.  */
+   struct grub_script_function *next;
++
++  unsigned executing;
+ };
+ typedef struct grub_script_function *grub_script_function_t;
+ 
+-- 
+2.14.4
+

meta/recipes-bsp/grub/files/CVE-2020-15707-linux-Fix-integer-overflows-in-initrd-size-handling.patch

@@ -0,0 +1,177 @@
+From 68a09a74f6d726d79709847f3671c0a08e4fb5a0 Mon Sep 17 00:00:00 2001
+From: Colin Watson <cjwatson@debian.org>
+Date: Sat, 25 Jul 2020 12:15:37 +0100
+Subject: [PATCH 9/9] linux: Fix integer overflows in initrd size handling
+
+These could be triggered by a crafted filesystem with very large files.
+
+Fixes: CVE-2020-15707
+
+Signed-off-by: Colin Watson <cjwatson@debian.org>
+Reviewed-by: Jan Setje-Eilers <jan.setjeeilers@oracle.com>
+Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
+
+Upstream-Status: Backport
+CVE: CVE-2020-15707
+
+Reference to upstream patch:
+https://git.savannah.gnu.org/cgit/grub.git/commit/?id=e7b8856f8be3292afdb38d2e8c70ad8d62a61e10
+
+Signed-off-by: Yongxin Liu <yongxin.liu@windriver.com>
+---
+ grub-core/loader/linux.c | 74 +++++++++++++++++++++++++++++++++++-------------
+ 1 file changed, 54 insertions(+), 20 deletions(-)
+
+diff --git a/grub-core/loader/linux.c b/grub-core/loader/linux.c
+index 471b214..8c8565a 100644
+--- a/grub-core/loader/linux.c
++++ b/grub-core/loader/linux.c
+@@ -4,6 +4,7 @@
+ #include <grub/misc.h>
+ #include <grub/file.h>
+ #include <grub/mm.h>
++#include <grub/safemath.h>
+ 
+ struct newc_head
+ {
+@@ -98,13 +99,13 @@ free_dir (struct dir *root)
+   grub_free (root);
+ }
+ 
+-static grub_size_t
++static grub_err_t
+ insert_dir (const char *name, struct dir **root,
+-	    grub_uint8_t *ptr)
++	    grub_uint8_t *ptr, grub_size_t *size)
+ {
+   struct dir *cur, **head = root;
+   const char *cb, *ce = name;
+-  grub_size_t size = 0;
++  *size = 0;
+   while (1)
+     {
+       for (cb = ce; *cb == '/'; cb++);
+@@ -130,14 +131,22 @@ insert_dir (const char *name, struct dir **root,
+ 	      ptr = make_header (ptr, name, ce - name,
+ 				 040777, 0);
+ 	    }
+-	  size += ALIGN_UP ((ce - (char *) name)
+-			    + sizeof (struct newc_head), 4);
++	  if (grub_add (*size,
++		        ALIGN_UP ((ce - (char *) name)
++				  + sizeof (struct newc_head), 4),
++			size))
++	    {
++	      grub_error (GRUB_ERR_OUT_OF_RANGE, N_("overflow is detected"));
++	      grub_free (n->name);
++	      grub_free (n);
++	      return grub_errno;
++	    }
+ 	  *head = n;
+ 	  cur = n;
+ 	}
+       root = &cur->next;
+     }
+-  return size;
++  return GRUB_ERR_NONE;
+ }
+ 
+ grub_err_t
+@@ -173,26 +182,33 @@ grub_initrd_init (int argc, char *argv[],
+ 	  eptr = grub_strchr (ptr, ':');
+ 	  if (eptr)
+ 	    {
++	      grub_size_t dir_size, name_len;
++
+ 	      initrd_ctx->components[i].newc_name = grub_strndup (ptr, eptr - ptr);
+-	      if (!initrd_ctx->components[i].newc_name)
++	      if (!initrd_ctx->components[i].newc_name ||
++		  insert_dir (initrd_ctx->components[i].newc_name, &root, 0,
++			      &dir_size))
+ 		{
+ 		  grub_initrd_close (initrd_ctx);
+ 		  return grub_errno;
+ 		}
+-	      initrd_ctx->size
+-		+= ALIGN_UP (sizeof (struct newc_head)
+-			    + grub_strlen (initrd_ctx->components[i].newc_name),
+-			     4);
+-	      initrd_ctx->size += insert_dir (initrd_ctx->components[i].newc_name,
+-					      &root, 0);
++	      name_len = grub_strlen (initrd_ctx->components[i].newc_name);
++	      if (grub_add (initrd_ctx->size,
++			    ALIGN_UP (sizeof (struct newc_head) + name_len, 4),
++			    &initrd_ctx->size) ||
++		  grub_add (initrd_ctx->size, dir_size, &initrd_ctx->size))
++		goto overflow;
+ 	      newc = 1;
+ 	      fname = eptr + 1;
+ 	    }
+ 	}
+       else if (newc)
+ 	{
+-	  initrd_ctx->size += ALIGN_UP (sizeof (struct newc_head)
+-					+ sizeof ("TRAILER!!!") - 1, 4);
++	  if (grub_add (initrd_ctx->size,
++			ALIGN_UP (sizeof (struct newc_head)
++				  + sizeof ("TRAILER!!!") - 1, 4),
++			&initrd_ctx->size))
++	    goto overflow;
+ 	  free_dir (root);
+ 	  root = 0;
+ 	  newc = 0;
+@@ -208,19 +224,29 @@ grub_initrd_init (int argc, char *argv[],
+       initrd_ctx->nfiles++;
+       initrd_ctx->components[i].size
+ 	= grub_file_size (initrd_ctx->components[i].file);
+-      initrd_ctx->size += initrd_ctx->components[i].size;
++      if (grub_add (initrd_ctx->size, initrd_ctx->components[i].size,
++		    &initrd_ctx->size))
++	goto overflow;
+     }
+ 
+   if (newc)
+     {
+       initrd_ctx->size = ALIGN_UP (initrd_ctx->size, 4);
+-      initrd_ctx->size += ALIGN_UP (sizeof (struct newc_head)
+-				    + sizeof ("TRAILER!!!") - 1, 4);
++      if (grub_add (initrd_ctx->size,
++		    ALIGN_UP (sizeof (struct newc_head)
++			      + sizeof ("TRAILER!!!") - 1, 4),
++		    &initrd_ctx->size))
++	goto overflow;
+       free_dir (root);
+       root = 0;
+     }
+   
+   return GRUB_ERR_NONE;
++
++ overflow:
++  free_dir (root);
++  grub_initrd_close (initrd_ctx);
++  return grub_error (GRUB_ERR_OUT_OF_RANGE, N_("overflow is detected"));
+ }
+ 
+ grub_size_t
+@@ -261,8 +287,16 @@ grub_initrd_load (struct grub_linux_initrd_context *initrd_ctx,
+ 
+       if (initrd_ctx->components[i].newc_name)
+ 	{
+-	  ptr += insert_dir (initrd_ctx->components[i].newc_name,
+-			     &root, ptr);
++	  grub_size_t dir_size;
++
++	  if (insert_dir (initrd_ctx->components[i].newc_name, &root, ptr,
++			  &dir_size))
++	    {
++	      free_dir (root);
++	      grub_initrd_close (initrd_ctx);
++	      return grub_errno;
++	    }
++	  ptr += dir_size;
+ 	  ptr = make_header (ptr, initrd_ctx->components[i].newc_name,
+ 			     grub_strlen (initrd_ctx->components[i].newc_name),
+ 			     0100777,
+-- 
+2.14.4
+

meta/recipes-bsp/grub/files/calloc-Make-sure-we-always-have-an-overflow-checking.patch

@@ -0,0 +1,246 @@
+From c005f62f5c4b26a77b916c8f76a852324439ecb3 Mon Sep 17 00:00:00 2001
+From: Peter Jones <pjones@redhat.com>
+Date: Mon, 15 Jun 2020 12:15:29 -0400
+Subject: [PATCH 2/9] calloc: Make sure we always have an overflow-checking
+ calloc() available
+
+This tries to make sure that everywhere in this source tree, we always have
+an appropriate version of calloc() (i.e. grub_calloc(), xcalloc(), etc.)
+available, and that they all safely check for overflow and return NULL when
+it would occur.
+
+Upstream-Status: Backport [commit 64e26162ebfe68317c143ca5ec996c892019f8f8
+from https://git.savannah.gnu.org/git/grub.git]
+
+Signed-off-by: Peter Jones <pjones@redhat.com>
+Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
+Signed-off-by: Yongxin Liu <yongxin.liu@windriver.com>
+---
+ grub-core/kern/emu/misc.c          | 12 ++++++++++++
+ grub-core/kern/emu/mm.c            | 10 ++++++++++
+ grub-core/kern/mm.c                | 40 ++++++++++++++++++++++++++++++++++++++
+ grub-core/lib/libgcrypt_wrap/mem.c | 11 +++++++++--
+ grub-core/lib/posix_wrap/stdlib.h  |  8 +++++++-
+ include/grub/emu/misc.h            |  1 +
+ include/grub/mm.h                  |  6 ++++++
+ 7 files changed, 85 insertions(+), 3 deletions(-)
+
+diff --git a/grub-core/kern/emu/misc.c b/grub-core/kern/emu/misc.c
+index 65db79b..dfd8a8e 100644
+--- a/grub-core/kern/emu/misc.c
++++ b/grub-core/kern/emu/misc.c
+@@ -85,6 +85,18 @@ grub_util_error (const char *fmt, ...)
+   exit (1);
+ }
+ 
++void *
++xcalloc (grub_size_t nmemb, grub_size_t size)
++{
++  void *p;
++
++  p = calloc (nmemb, size);
++  if (!p)
++    grub_util_error ("%s", _("out of memory"));
++
++  return p;
++}
++
+ void *
+ xmalloc (grub_size_t size)
+ {
+diff --git a/grub-core/kern/emu/mm.c b/grub-core/kern/emu/mm.c
+index f262e95..145b01d 100644
+--- a/grub-core/kern/emu/mm.c
++++ b/grub-core/kern/emu/mm.c
+@@ -25,6 +25,16 @@
+ #include <string.h>
+ #include <grub/i18n.h>
+ 
++void *
++grub_calloc (grub_size_t nmemb, grub_size_t size)
++{
++  void *ret;
++  ret = calloc (nmemb, size);
++  if (!ret)
++    grub_error (GRUB_ERR_OUT_OF_MEMORY, N_("out of memory"));
++  return ret;
++}
++
+ void *
+ grub_malloc (grub_size_t size)
+ {
+diff --git a/grub-core/kern/mm.c b/grub-core/kern/mm.c
+index ee88ff6..f2822a8 100644
+--- a/grub-core/kern/mm.c
++++ b/grub-core/kern/mm.c
+@@ -67,8 +67,10 @@
+ #include <grub/dl.h>
+ #include <grub/i18n.h>
+ #include <grub/mm_private.h>
++#include <grub/safemath.h>
+ 
+ #ifdef MM_DEBUG
++# undef grub_calloc
+ # undef grub_malloc
+ # undef grub_zalloc
+ # undef grub_realloc
+@@ -375,6 +377,30 @@ grub_memalign (grub_size_t align, grub_size_t size)
+   return 0;
+ }
+ 
++/*
++ * Allocate NMEMB instances of SIZE bytes and return the pointer, or error on
++ * integer overflow.
++ */
++void *
++grub_calloc (grub_size_t nmemb, grub_size_t size)
++{
++  void *ret;
++  grub_size_t sz = 0;
++
++  if (grub_mul (nmemb, size, &sz))
++    {
++      grub_error (GRUB_ERR_OUT_OF_RANGE, N_("overflow is detected"));
++      return NULL;
++    }
++
++  ret = grub_memalign (0, sz);
++  if (!ret)
++    return NULL;
++
++  grub_memset (ret, 0, sz);
++  return ret;
++}
++
+ /* Allocate SIZE bytes and return the pointer.  */
+ void *
+ grub_malloc (grub_size_t size)
+@@ -561,6 +587,20 @@ grub_mm_dump (unsigned lineno)
+   grub_printf ("\n");
+ }
+ 
++void *
++grub_debug_calloc (const char *file, int line, grub_size_t nmemb, grub_size_t size)
++{
++  void *ptr;
++
++  if (grub_mm_debug)
++    grub_printf ("%s:%d: calloc (0x%" PRIxGRUB_SIZE ", 0x%" PRIxGRUB_SIZE ") = ",
++		 file, line, size);
++  ptr = grub_calloc (nmemb, size);
++  if (grub_mm_debug)
++    grub_printf ("%p\n", ptr);
++  return ptr;
++}
++
+ void *
+ grub_debug_malloc (const char *file, int line, grub_size_t size)
+ {
+diff --git a/grub-core/lib/libgcrypt_wrap/mem.c b/grub-core/lib/libgcrypt_wrap/mem.c
+index beeb661..74c6eaf 100644
+--- a/grub-core/lib/libgcrypt_wrap/mem.c
++++ b/grub-core/lib/libgcrypt_wrap/mem.c
+@@ -4,6 +4,7 @@
+ #include <grub/crypto.h>
+ #include <grub/dl.h>
+ #include <grub/env.h>
++#include <grub/safemath.h>
+ 
+ GRUB_MOD_LICENSE ("GPLv3+");
+ 
+@@ -36,7 +37,10 @@ void *
+ gcry_xcalloc (size_t n, size_t m)
+ {
+   void *ret;
+-  ret = grub_zalloc (n * m);
++  size_t sz;
++  if (grub_mul (n, m, &sz))
++    grub_fatal ("gcry_xcalloc would overflow");
++  ret = grub_zalloc (sz);
+   if (!ret)
+     grub_fatal ("gcry_xcalloc failed");
+   return ret;
+@@ -56,7 +60,10 @@ void *
+ gcry_xcalloc_secure (size_t n, size_t m)
+ {
+   void *ret;
+-  ret = grub_zalloc (n * m);
++  size_t sz;
++  if (grub_mul (n, m, &sz))
++    grub_fatal ("gcry_xcalloc would overflow");
++  ret = grub_zalloc (sz);
+   if (!ret)
+     grub_fatal ("gcry_xcalloc failed");
+   return ret;
+diff --git a/grub-core/lib/posix_wrap/stdlib.h b/grub-core/lib/posix_wrap/stdlib.h
+index 3b46f47..7a8d385 100644
+--- a/grub-core/lib/posix_wrap/stdlib.h
++++ b/grub-core/lib/posix_wrap/stdlib.h
+@@ -21,6 +21,7 @@
+ 
+ #include <grub/mm.h>
+ #include <grub/misc.h>
++#include <grub/safemath.h>
+ 
+ static inline void 
+ free (void *ptr)
+@@ -37,7 +38,12 @@ malloc (grub_size_t size)
+ static inline void *
+ calloc (grub_size_t size, grub_size_t nelem)
+ {
+-  return grub_zalloc (size * nelem);
++  grub_size_t sz;
++
++  if (grub_mul (size, nelem, &sz))
++    return NULL;
++
++  return grub_zalloc (sz);
+ }
+ 
+ static inline void *
+diff --git a/include/grub/emu/misc.h b/include/grub/emu/misc.h
+index ce464cf..ff9c48a 100644
+--- a/include/grub/emu/misc.h
++++ b/include/grub/emu/misc.h
+@@ -47,6 +47,7 @@ grub_util_device_is_mapped (const char *dev);
+ #define GRUB_HOST_PRIuLONG_LONG "llu"
+ #define GRUB_HOST_PRIxLONG_LONG "llx"
+ 
++void * EXPORT_FUNC(xcalloc) (grub_size_t nmemb, grub_size_t size) WARN_UNUSED_RESULT;
+ void * EXPORT_FUNC(xmalloc) (grub_size_t size) WARN_UNUSED_RESULT;
+ void * EXPORT_FUNC(xrealloc) (void *ptr, grub_size_t size) WARN_UNUSED_RESULT;
+ char * EXPORT_FUNC(xstrdup) (const char *str) WARN_UNUSED_RESULT;
+diff --git a/include/grub/mm.h b/include/grub/mm.h
+index 28e2e53..9c38dd3 100644
+--- a/include/grub/mm.h
++++ b/include/grub/mm.h
+@@ -29,6 +29,7 @@
+ #endif
+ 
+ void grub_mm_init_region (void *addr, grub_size_t size);
++void *EXPORT_FUNC(grub_calloc) (grub_size_t nmemb, grub_size_t size);
+ void *EXPORT_FUNC(grub_malloc) (grub_size_t size);
+ void *EXPORT_FUNC(grub_zalloc) (grub_size_t size);
+ void EXPORT_FUNC(grub_free) (void *ptr);
+@@ -48,6 +49,9 @@ extern int EXPORT_VAR(grub_mm_debug);
+ void grub_mm_dump_free (void);
+ void grub_mm_dump (unsigned lineno);
+ 
++#define grub_calloc(nmemb, size)	\
++  grub_debug_calloc (GRUB_FILE, __LINE__, nmemb, size)
++
+ #define grub_malloc(size)	\
+   grub_debug_malloc (GRUB_FILE, __LINE__, size)
+ 
+@@ -63,6 +67,8 @@ void grub_mm_dump (unsigned lineno);
+ #define grub_free(ptr)	\
+   grub_debug_free (GRUB_FILE, __LINE__, ptr)
+ 
++void *EXPORT_FUNC(grub_debug_calloc) (const char *file, int line,
++				      grub_size_t nmemb, grub_size_t size);
+ void *EXPORT_FUNC(grub_debug_malloc) (const char *file, int line,
+ 				      grub_size_t size);
+ void *EXPORT_FUNC(grub_debug_zalloc) (const char *file, int line,
+-- 
+2.14.4
+

meta/recipes-bsp/grub/files/lvm-Add-LVM-cache-logical-volume-handling.patch

@@ -0,0 +1,287 @@
+From 8eb02bcb5897b238b29ff762402bb0c3028f0eab Mon Sep 17 00:00:00 2001
+From: Michael Chang <mchang@suse.com>
+Date: Thu, 19 Mar 2020 13:56:13 +0800
+Subject: [PATCH 3/9] lvm: Add LVM cache logical volume handling
+
+The LVM cache logical volume is the logical volume consisting of the original
+and the cache pool logical volume. The original is usually on a larger and
+slower storage device while the cache pool is on a smaller and faster one. The
+performance of the original volume can be improved by storing the frequently
+used data on the cache pool to utilize the greater performance of faster
+device.
+
+The default cache mode "writethrough" ensures that any data written will be
+stored both in the cache and on the origin LV, therefore grub can be straight
+to read the original lv as no data loss is guarenteed.
+
+The second cache mode is "writeback", which delays writing from the cache pool
+back to the origin LV to have increased performance. The drawback is potential
+data loss if losing the associated cache device.
+
+During the boot time grub reads the LVM offline i.e. LVM volumes are not
+activated and mounted, hence it should be fine to read directly from original
+lv since all cached data should have been flushed back in the process of taking
+it offline.
+
+It is also not much helpful to the situation by adding fsync calls to the
+install code. The fsync did not force to write back dirty cache to the original
+device and rather it would update associated cache metadata to complete the
+write transaction with the cache device. IOW the writes to cached blocks still
+go only to the cache device.
+
+To write back dirty cache, as LVM cache did not support dirty cache flush per
+block range, there'no way to do it for file. On the other hand the "cleaner"
+policy is implemented and can be used to write back "all" dirty blocks in a
+cache, which effectively drain all dirty cache gradually to attain and last in
+the "clean" state, which can be useful for shrinking or decommissioning a
+cache. The result and effect is not what we are looking for here.
+
+In conclusion, as it seems no way to enforce file writes to the original
+device, grub may suffer from power failure as it cannot assemble the cache
+device and read the dirty data from it. However since the case is only
+applicable to writeback mode which is sensitive to data lost in nature, I'd
+still like to propose my (relatively simple) patch and treat reading dirty
+cache as improvement.
+
+Upstream-Status: Backport [commit 0454b0445393aafc5600e92ef0c39494e333b135
+from https://git.savannah.gnu.org/git/grub.git]
+
+Signed-off-by: Michael Chang <mchang@suse.com>
+Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
+Signed-off-by: Yongxin Liu <yongxin.liu@windriver.com>
+---
+ grub-core/disk/lvm.c | 190 +++++++++++++++++++++++++++++++++++++++++++++++++++
+ 1 file changed, 190 insertions(+)
+
+diff --git a/grub-core/disk/lvm.c b/grub-core/disk/lvm.c
+index 7b265c7..dc6b83b 100644
+--- a/grub-core/disk/lvm.c
++++ b/grub-core/disk/lvm.c
+@@ -33,6 +33,14 @@
+ 
+ GRUB_MOD_LICENSE ("GPLv3+");
+ 
++struct cache_lv
++{
++  struct grub_diskfilter_lv *lv;
++  char *cache_pool;
++  char *origin;
++  struct cache_lv *next;
++};
++
+ 
+ /* Go the string STR and return the number after STR.  *P will point
+    at the number.  In case STR is not found, *P will be NULL and the
+@@ -95,6 +103,34 @@ grub_lvm_check_flag (char *p, const char *str, const char *flag)
+     }
+ }
+ 
++static void
++grub_lvm_free_cache_lvs (struct cache_lv *cache_lvs)
++{
++  struct cache_lv *cache;
++
++  while ((cache = cache_lvs))
++    {
++      cache_lvs = cache_lvs->next;
++
++      if (cache->lv)
++	{
++	  unsigned int i;
++
++	  for (i = 0; i < cache->lv->segment_count; ++i)
++	    if (cache->lv->segments)
++	      grub_free (cache->lv->segments[i].nodes);
++	  grub_free (cache->lv->segments);
++	  grub_free (cache->lv->fullname);
++	  grub_free (cache->lv->idname);
++	  grub_free (cache->lv->name);
++	}
++      grub_free (cache->lv);
++      grub_free (cache->origin);
++      grub_free (cache->cache_pool);
++      grub_free (cache);
++    }
++}
++
+ static struct grub_diskfilter_vg * 
+ grub_lvm_detect (grub_disk_t disk,
+ 		 struct grub_diskfilter_pv_id *id,
+@@ -242,6 +278,8 @@ grub_lvm_detect (grub_disk_t disk,
+ 
+   if (! vg)
+     {
++      struct cache_lv *cache_lvs = NULL;
++
+       /* First time we see this volume group. We've to create the
+ 	 whole volume group structure. */
+       vg = grub_malloc (sizeof (*vg));
+@@ -671,6 +709,106 @@ grub_lvm_detect (grub_disk_t disk,
+ 			  seg->nodes[seg->node_count - 1].name = tmp;
+ 			}
+ 		    }
++		  else if (grub_memcmp (p, "cache\"",
++				   sizeof ("cache\"") - 1) == 0)
++		    {
++		      struct cache_lv *cache = NULL;
++
++		      char *p2, *p3;
++		      grub_size_t sz;
++
++		      cache = grub_zalloc (sizeof (*cache));
++		      if (!cache)
++			goto cache_lv_fail;
++		      cache->lv = grub_zalloc (sizeof (*cache->lv));
++		      if (!cache->lv)
++			goto cache_lv_fail;
++		      grub_memcpy (cache->lv, lv, sizeof (*cache->lv));
++
++		      if (lv->fullname)
++			{
++			  cache->lv->fullname = grub_strdup (lv->fullname);
++			  if (!cache->lv->fullname)
++			    goto cache_lv_fail;
++			}
++		      if (lv->idname)
++			{
++			  cache->lv->idname = grub_strdup (lv->idname);
++			  if (!cache->lv->idname)
++			    goto cache_lv_fail;
++			}
++		      if (lv->name)
++			{
++			  cache->lv->name = grub_strdup (lv->name);
++			  if (!cache->lv->name)
++			    goto cache_lv_fail;
++			}
++
++		      skip_lv = 1;
++
++		      p2 = grub_strstr (p, "cache_pool = \"");
++		      if (!p2)
++			goto cache_lv_fail;
++
++		      p2 = grub_strchr (p2, '"');
++		      if (!p2)
++			goto cache_lv_fail;
++
++		      p3 = ++p2;
++		      p3 = grub_strchr (p3, '"');
++		      if (!p3)
++			goto cache_lv_fail;
++
++		      sz = p3 - p2;
++
++		      cache->cache_pool = grub_malloc (sz + 1);
++		      if (!cache->cache_pool)
++			goto cache_lv_fail;
++		      grub_memcpy (cache->cache_pool, p2, sz);
++		      cache->cache_pool[sz] = '\0';
++
++		      p2 = grub_strstr (p, "origin = \"");
++		      if (!p2)
++			goto cache_lv_fail;
++
++		      p2 = grub_strchr (p2, '"');
++		      if (!p2)
++			goto cache_lv_fail;
++
++		      p3 = ++p2;
++		      p3 = grub_strchr (p3, '"');
++		      if (!p3)
++			goto cache_lv_fail;
++
++		      sz = p3 - p2;
++
++		      cache->origin = grub_malloc (sz + 1);
++		      if (!cache->origin)
++			goto cache_lv_fail;
++		      grub_memcpy (cache->origin, p2, sz);
++		      cache->origin[sz] = '\0';
++
++		      cache->next = cache_lvs;
++		      cache_lvs = cache;
++		      break;
++
++		    cache_lv_fail:
++		      if (cache)
++			{
++			  grub_free (cache->origin);
++			  grub_free (cache->cache_pool);
++			  if (cache->lv)
++			    {
++			      grub_free (cache->lv->fullname);
++			      grub_free (cache->lv->idname);
++			      grub_free (cache->lv->name);
++			    }
++			  grub_free (cache->lv);
++			  grub_free (cache);
++			}
++		      grub_lvm_free_cache_lvs (cache_lvs);
++		      goto fail4;
++		    }
+ 		  else
+ 		    {
+ #ifdef GRUB_UTIL
+@@ -747,6 +885,58 @@ grub_lvm_detect (grub_disk_t disk,
+ 	      }
+ 	
+       }
++
++      {
++	struct cache_lv *cache;
++
++	for (cache = cache_lvs; cache; cache = cache->next)
++	  {
++	    struct grub_diskfilter_lv *lv;
++
++	    for (lv = vg->lvs; lv; lv = lv->next)
++	      if (grub_strcmp (lv->name, cache->origin) == 0)
++		break;
++	    if (lv)
++	      {
++		cache->lv->segments = grub_malloc (lv->segment_count * sizeof (*lv->segments));
++		if (!cache->lv->segments)
++		  {
++		    grub_lvm_free_cache_lvs (cache_lvs);
++		    goto fail4;
++		  }
++		grub_memcpy (cache->lv->segments, lv->segments, lv->segment_count * sizeof (*lv->segments));
++
++		for (i = 0; i < lv->segment_count; ++i)
++		  {
++		    struct grub_diskfilter_node *nodes = lv->segments[i].nodes;
++		    grub_size_t node_count = lv->segments[i].node_count;
++
++		    cache->lv->segments[i].nodes = grub_malloc (node_count * sizeof (*nodes));
++		    if (!cache->lv->segments[i].nodes)
++		      {
++			for (j = 0; j < i; ++j)
++			  grub_free (cache->lv->segments[j].nodes);
++			grub_free (cache->lv->segments);
++			cache->lv->segments = NULL;
++			grub_lvm_free_cache_lvs (cache_lvs);
++			goto fail4;
++		      }
++		    grub_memcpy (cache->lv->segments[i].nodes, nodes, node_count * sizeof (*nodes));
++		  }
++
++		if (cache->lv->segments)
++		  {
++		    cache->lv->segment_count = lv->segment_count;
++		    cache->lv->vg = vg;
++		    cache->lv->next = vg->lvs;
++		    vg->lvs = cache->lv;
++		    cache->lv = NULL;
++		  }
++	      }
++	  }
++      }
++
++      grub_lvm_free_cache_lvs (cache_lvs);
+       if (grub_diskfilter_vg_register (vg))
+ 	goto fail4;
+     }
+-- 
+2.14.4
+

meta/recipes-bsp/grub/files/safemath-Add-some-arithmetic-primitives-that-check-f.patch

@@ -0,0 +1,94 @@
+From 06c361a71c4998635493610e5d76d0d223925251 Mon Sep 17 00:00:00 2001
+From: Peter Jones <pjones@redhat.com>
+Date: Mon, 15 Jun 2020 10:58:42 -0400
+Subject: [PATCH 5/9] safemath: Add some arithmetic primitives that check for
+ overflow
+
+This adds a new header, include/grub/safemath.h, that includes easy to
+use wrappers for __builtin_{add,sub,mul}_overflow() declared like:
+
+  bool OP(a, b, res)
+
+where OP is grub_add, grub_sub or grub_mul. OP() returns true in the
+case where the operation would overflow and res is not modified.
+Otherwise, false is returned and the operation is executed.
+
+These arithmetic primitives require newer compiler versions. So, bump
+these requirements in the INSTALL file too.
+
+Upstream-Status: Backport [commit 68708c4503018d61dbcce7ac11cbb511d6425f4d
+from https://git.savannah.gnu.org/git/grub.git]
+
+Signed-off-by: Peter Jones <pjones@redhat.com>
+Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
+[YL: omit the change to INSTALL from original patch]
+Signed-off-by: Yongxin Liu <yongxin.liu@windriver.com>
+---
+ include/grub/compiler.h |  8 ++++++++
+ include/grub/safemath.h | 37 +++++++++++++++++++++++++++++++++++++
+ 2 files changed, 45 insertions(+)
+ create mode 100644 include/grub/safemath.h
+
+diff --git a/include/grub/compiler.h b/include/grub/compiler.h
+index c9e1d7a..8f3be3a 100644
+--- a/include/grub/compiler.h
++++ b/include/grub/compiler.h
+@@ -48,4 +48,12 @@
+ #  define WARN_UNUSED_RESULT
+ #endif
+ 
++#if defined(__clang__) && defined(__clang_major__) && defined(__clang_minor__)
++#  define CLANG_PREREQ(maj,min) \
++          ((__clang_major__ > (maj)) || \
++	   (__clang_major__ == (maj) && __clang_minor__ >= (min)))
++#else
++#  define CLANG_PREREQ(maj,min) 0
++#endif
++
+ #endif /* ! GRUB_COMPILER_HEADER */
+diff --git a/include/grub/safemath.h b/include/grub/safemath.h
+new file mode 100644
+index 0000000..c17b89b
+--- /dev/null
++++ b/include/grub/safemath.h
+@@ -0,0 +1,37 @@
++/*
++ *  GRUB  --  GRand Unified Bootloader
++ *  Copyright (C) 2020  Free Software Foundation, Inc.
++ *
++ *  GRUB is free software: you can redistribute it and/or modify
++ *  it under the terms of the GNU General Public License as published by
++ *  the Free Software Foundation, either version 3 of the License, or
++ *  (at your option) any later version.
++ *
++ *  GRUB is distributed in the hope that it will be useful,
++ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
++ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
++ *  GNU General Public License for more details.
++ *
++ *  You should have received a copy of the GNU General Public License
++ *  along with GRUB.  If not, see <http://www.gnu.org/licenses/>.
++ *
++ *  Arithmetic operations that protect against overflow.
++ */
++
++#ifndef GRUB_SAFEMATH_H
++#define GRUB_SAFEMATH_H 1
++
++#include <grub/compiler.h>
++
++/* These appear in gcc 5.1 and clang 3.8. */
++#if GNUC_PREREQ(5, 1) || CLANG_PREREQ(3, 8)
++
++#define grub_add(a, b, res)	__builtin_add_overflow(a, b, res)
++#define grub_sub(a, b, res)	__builtin_sub_overflow(a, b, res)
++#define grub_mul(a, b, res)	__builtin_mul_overflow(a, b, res)
++
++#else
++#error gcc 5.1 or newer or clang 3.8 or newer is required
++#endif
++
++#endif /* GRUB_SAFEMATH_H */
+-- 
+2.14.4
+

meta/recipes-bsp/grub/files/script-Remove-unused-fields-from-grub_script_functio.patch

@@ -0,0 +1,37 @@
+From e219bad8cee67b2bb21712df8f055706f8da25d2 Mon Sep 17 00:00:00 2001
+From: Chris Coulson <chris.coulson@canonical.com>
+Date: Fri, 10 Jul 2020 11:21:14 +0100
+Subject: [PATCH 7/9] script: Remove unused fields from grub_script_function
+ struct
+
+Upstream-Status: Backport [commit 1a8d9c9b4ab6df7669b5aa36a56477f297825b96
+from https://git.savannah.gnu.org/git/grub.git]
+
+Signed-off-by: Chris Coulson <chris.coulson@canonical.com>
+Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>
+Signed-off-by: Yongxin Liu <yongxin.liu@windriver.com>
+---
+ include/grub/script_sh.h | 5 -----
+ 1 file changed, 5 deletions(-)
+
+diff --git a/include/grub/script_sh.h b/include/grub/script_sh.h
+index 360c2be..b382bcf 100644
+--- a/include/grub/script_sh.h
++++ b/include/grub/script_sh.h
+@@ -359,13 +359,8 @@ struct grub_script_function
+   /* The script function.  */
+   struct grub_script *func;
+ 
+-  /* The flags.  */
+-  unsigned flags;
+-
+   /* The next element.  */
+   struct grub_script_function *next;
+-
+-  int references;
+ };
+ typedef struct grub_script_function *grub_script_function_t;
+ 
+-- 
+2.14.4
+

meta/recipes-bsp/grub/grub2.inc

@@ -19,6 +19,14 @@ SRC_URI = "${GNU_MIRROR}/grub/grub-${PV}.tar.gz \
            file://grub-module-explicitly-keeps-symbole-.module_license.patch \
            file://0001-grub.d-10_linux.in-add-oe-s-kernel-name.patch \
            file://CVE-2020-10713.patch \
+           file://calloc-Make-sure-we-always-have-an-overflow-checking.patch \
+           file://lvm-Add-LVM-cache-logical-volume-handling.patch \
+           file://CVE-2020-14308-calloc-Use-calloc-at-most-places.patch \
+           file://safemath-Add-some-arithmetic-primitives-that-check-f.patch \
+           file://CVE-2020-14309-CVE-2020-14310-CVE-2020-14311-malloc-Use-overflow-checking-primitives-where-we-do-.patch \
+           file://script-Remove-unused-fields-from-grub_script_functio.patch \
+           file://CVE-2020-15706-script-Avoid-a-use-after-free-when-redefining-a-func.patch \
+           file://CVE-2020-15707-linux-Fix-integer-overflows-in-initrd-size-handling.patch \
 "
 SRC_URI[md5sum] = "5ce674ca6b2612d8939b9e6abed32934"
 SRC_URI[sha256sum] = "f10c85ae3e204dbaec39ae22fa3c5e99f0665417e91c2cb49b7e5031658ba6ea"

meta/recipes-bsp/lrzsz/lrzsz-0.12.20/0001-Fix-cross-compilation-using-autoconf-detected-AR.patch

@@ -0,0 +1,36 @@
+From ecdcf0df6c28c65ca6d1e5638726e13e373c76c5 Mon Sep 17 00:00:00 2001
+From: Khem Raj <raj.khem@gmail.com>
+Date: Wed, 11 Nov 2020 22:58:55 -0800
+Subject: [PATCH] Fix cross compilation using autoconf detected AR
+
+currently its using 'ar' program from build host, which is not expected,
+we need to respect AR passed in environment
+
+Upstream-Status: Pending
+
+Signed-off-by: Khem Raj <raj.khem@gmail.com>
+---
+ configure.in | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+diff --git a/configure.in b/configure.in
+index 4ddbe8b..b7c3c31 100644
+--- a/configure.in
++++ b/configure.in
+@@ -84,6 +84,13 @@ AC_ARG_ENABLE(syslog,
+ 	  ])
+ 
+ dnl Checks for programs.
++m4_ifndef([AC_PROG_AR],[dnl
++  AN_MAKEVAR([AR], [AC_PROG_AR])
++  AN_PROGRAM([ar], [AC_PROG_AR])
++  AC_DEFUN([AC_PROG_AR],
++  [AC_CHECK_TOOL(AR, ar, :)])
++])
++AC_PROG_AR
+ AC_PROG_CC
+ AC_PROG_GCC_TRADITIONAL
+ dnl AC_PROG_INSTALL  included in AM_INIT_AUTOMAKE
+-- 
+2.29.2
+

meta/recipes-bsp/lrzsz/lrzsz_0.12.20.bb

@@ -19,6 +19,7 @@ SRC_URI = "http://www.ohse.de/uwe/releases/lrzsz-${PV}.tar.gz \
            file://lrzsz-check-locale.h.patch \
            file://cve-2018-10195.patch \
            file://include.patch \
+           file://0001-Fix-cross-compilation-using-autoconf-detected-AR.patch \
            "
 
 SRC_URI[md5sum] = "b5ce6a74abc9b9eb2af94dffdfd372a4"

meta/recipes-connectivity/bluez5/bluez5_5.55.bb

@@ -1,7 +1,7 @@
 require bluez5.inc
 
-SRC_URI[md5sum] = "e637feb2dbb7582bbbff1708367a847c"
-SRC_URI[sha256sum] = "68cdab9e63e8832b130d5979dc8c96fdb087b31278f342874d992af3e56656dc"
+SRC_URI[md5sum] = "94972b8bc7ade60c72b0ffa6ccff2c0a"
+SRC_URI[sha256sum] = "8863717113c4897e2ad3271fc808ea245319e6fd95eed2e934fae8e0894e9b88"
 
 # noinst programs in Makefile.tools that are conditional on READLINE
 # support

meta/recipes-connectivity/openssh/openssh_8.3p1.bb

@@ -27,6 +27,10 @@ SRC_URI = "http://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-${PV}.tar
            "
 SRC_URI[sha256sum] = "f2befbe0472fe7eb75d23340eb17531cb6b3aac24075e2066b41f814e12387b2"
 
+# This CVE is specific to OpenSSH server, as used in Fedora and Red Hat Enterprise Linux 7
+# and when running in a Kerberos environment. As such it is not relevant to OpenEmbedded
+CVE_CHECK_WHITELIST += "CVE-2014-9278"
+
 PAM_SRC_URI = "file://sshd"
 
 inherit manpages useradd update-rc.d update-alternatives systemd

meta/recipes-core/busybox/busybox.inc

@@ -5,10 +5,11 @@ BUGTRACKER = "https://bugs.busybox.net/"
 
 DEPENDS += "kern-tools-native virtual/crypt"
 
-# bzip2 applet in busybox is based on lightly-modified bzip2 source
+# bzip2 applet in busybox is based on lightly-modified bzip2-1.0.4 source
 # the GPL is version 2 only
-LICENSE = "GPLv2 & bzip2-1.0.6"
-LIC_FILES_CHKSUM = "file://LICENSE;md5=de10de48642ab74318e893a61105afbb"
+LICENSE = "GPLv2 & bzip2-1.0.4"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=de10de48642ab74318e893a61105afbb \
+                    file://archival/libarchive/bz/LICENSE;md5=28e3301eae987e8cfe19988e98383dae"
 
 SECTION = "base"
 

meta/recipes-core/glib-2.0/glib.inc

@@ -170,7 +170,7 @@ RDEPENDS_${PN}-ptest += "\
             ${PN}-locale-th \
             python3-core \
             python3-modules \
-            python3-dbusmock \
+            ${@bb.utils.contains('GI_DATA_ENABLED', 'True', 'python3-dbusmock', '', d)} \
             ${PN}-codegen \
            "
 

meta/recipes-core/images/build-appliance-image_15.0.0.bb

@@ -24,8 +24,8 @@ IMAGE_FSTYPES = "wic.vmdk"
 
 inherit core-image module-base setuptools3
 
-SRCREV ?= "1dfd37d30953208fd998cef79483f371330a754e"
-SRC_URI = "git://git.yoctoproject.org/poky \
+SRCREV ?= "76dac9d657f3b2864dec3bfcd2ee392fafdcdfe6"
+SRC_URI = "git://git.yoctoproject.org/poky;branch=gatesgarth \
            file://Yocto_Build_Appliance.vmx \
            file://Yocto_Build_Appliance.vmxf \
            file://README_VirtualBox_Guest_Additions.txt \

meta/recipes-core/init-ifupdown/init-ifupdown-1.0/qemuarm64/interfaces

@@ -1,5 +0,0 @@
-# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)
- 
-# The loopback interface
-auto lo
-iface lo inet loopback

meta/recipes-core/init-ifupdown/init-ifupdown-1.0/qemuarmv6/interfaces

@@ -1,5 +0,0 @@
-# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)
- 
-# The loopback interface
-auto lo
-iface lo inet loopback

meta/recipes-core/init-ifupdown/init-ifupdown-1.0/qemuarmv7/interfaces

@@ -1,5 +0,0 @@
-# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)
- 
-# The loopback interface
-auto lo
-iface lo inet loopback

meta/recipes-core/init-ifupdown/init-ifupdown-1.0/qemumips/interfaces

@@ -1,8 +0,0 @@
-# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)
- 
-# The loopback interface
-auto lo
-iface lo inet loopback
-
-
-

meta/recipes-core/init-ifupdown/init-ifupdown-1.0/qemumips64/interfaces

@@ -1,8 +0,0 @@
-# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)
- 
-# The loopback interface
-auto lo
-iface lo inet loopback
-
-
-

meta/recipes-core/init-ifupdown/init-ifupdown-1.0/qemuppc/interfaces

@@ -1,8 +0,0 @@
-# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)
- 
-# The loopback interface
-auto lo
-iface lo inet loopback
-
-
-

meta/recipes-core/init-ifupdown/init-ifupdown-1.0/qemush4/interfaces

@@ -1,8 +0,0 @@
-# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)
- 
-# The loopback interface
-auto lo
-iface lo inet loopback
-
-
-

meta/recipes-core/init-ifupdown/init-ifupdown-1.0/qemux86-64/interfaces

@@ -1,8 +0,0 @@
-# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)
- 
-# The loopback interface
-auto lo
-iface lo inet loopback
-
-
-

meta/recipes-core/init-ifupdown/init-ifupdown-1.0/qemux86/interfaces

@@ -1,8 +0,0 @@
-# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)
- 
-# The loopback interface
-auto lo
-iface lo inet loopback
-
-
-

meta/recipes-core/netbase/netbase_6.1.bb

@@ -6,13 +6,15 @@ LICENSE = "GPLv2"
 LIC_FILES_CHKSUM = "file://debian/copyright;md5=3dd6192d306f582dee7687da3d8748ab"
 PE = "1"
 
-SRC_URI = "${DEBIAN_MIRROR}/main/n/${BPN}/${BPN}_${PV}.tar.xz"
+SRC_URI = "${DEBIAN_MIRROR}/main/n/${BPN}/${BPN}_${PV}~bpo10+1.tar.xz"
+S = "${WORKDIR}/${BPN}-${PV}~bpo10+1"
 
-SRC_URI[md5sum] = "e5871a3a5c8390557b8033cf19316a55"
-SRC_URI[sha256sum] = "084d743bd84d4d9380bac4c71c51e57406dce44f5a69289bb823c903e9b035d8"
+SRC_URI[md5sum] = "4fa7517285b4045ac0dc8dbf6730dd7a"
+SRC_URI[sha256sum] = "4e9c3082dff8896cb6b6bea9bb2200d82fb0d7c8d8c8fc9b18704fe553316237"
 
 UPSTREAM_CHECK_URI = "${DEBIAN_MIRROR}/main/n/netbase/"
 do_install () {
+
 	install -d ${D}/${mandir}/man8 ${D}${sysconfdir}
 	install -m 0644 ${S}/etc/rpc ${D}${sysconfdir}/rpc
 	install -m 0644 ${S}/etc/protocols ${D}${sysconfdir}/protocols

meta/recipes-core/sysvinit/sysvinit/rc

@@ -63,7 +63,7 @@ startup() {
   stty onlcr 0>&1
 
   # Limit stack size for startup scripts
-  [ "$STACK_SIZE" == "" ] || ulimit -S -s $STACK_SIZE
+  [ "$STACK_SIZE" = "" ] || ulimit -S -s $STACK_SIZE
 
   # Now find out what the current and what the previous runlevel are.
 

meta/recipes-core/udev/eudev/init

@@ -52,7 +52,7 @@ case "$1" in
     kill_udevd > "/dev/null" 2>&1
 
     # trigger the sorted events
-    [ -e /proc/sys/kernel/hotplug ] && echo -e '\000' >/proc/sys/kernel/hotplug
+    [ -e /proc/sys/kernel/hotplug ] && printf '\0\n' >/proc/sys/kernel/hotplug
     @UDEVD@ -d
 
     udevadm control --env=STARTUP=1

meta/recipes-devtools/apt/apt/0001-Do-not-configure-packages-on-installation.patch

@@ -1,4 +1,4 @@
-From 1ad21140787a6b8b0f774f75b50444d2c30a56f6 Mon Sep 17 00:00:00 2001
+From 96d23fc57d1ff9c851d563d6d6a6c4752dc4f1b6 Mon Sep 17 00:00:00 2001
 From: Alexander Kanavin <alex.kanavin@gmail.com>
 Date: Thu, 21 May 2020 20:28:12 +0000
 Subject: [PATCH] Do not configure packages on installation

meta/recipes-devtools/apt/apt/0001-Do-not-init-tables-from-dpkg-configuration.patch

@@ -1,4 +1,4 @@
-From b18d7aa7d71b53b86bac21cd1d8c3accabb28f2b Mon Sep 17 00:00:00 2001
+From bf45c314867e5fb12141803fba06f3e45679d628 Mon Sep 17 00:00:00 2001
 From: Alexander Kanavin <alex.kanavin@gmail.com>
 Date: Fri, 10 May 2019 16:47:38 +0200
 Subject: [PATCH] Do not init tables from dpkg configuration

meta/recipes-devtools/apt/apt/0001-Revert-always-run-dpkg-configure-a-at-the-end-of-our.patch

@@ -1,4 +1,4 @@
-From 742fbb243f99e940c3e6b31296f7f416f550a57a Mon Sep 17 00:00:00 2001
+From 34700bebc52659e7e3eecd252f65bd36e669eee8 Mon Sep 17 00:00:00 2001
 From: Alexander Kanavin <alex.kanavin@gmail.com>
 Date: Thu, 21 May 2020 20:13:25 +0000
 Subject: [PATCH] Revert "always run 'dpkg --configure -a' at the end of our

meta/recipes-devtools/apt/apt/0001-test-libapt-do-not-use-gtest-from-the-host.patch

@@ -0,0 +1,40 @@
+From 28e389a0d1275e7693df84a7d4a58b28364be1a9 Mon Sep 17 00:00:00 2001
+From: Alexander Kanavin <alex.kanavin@gmail.com>
+Date: Thu, 22 Oct 2020 17:33:38 +0200
+Subject: [PATCH] test/libapt: do not use gtest from the host
+
+This really does not work when cross-compiling.
+
+Upstream-Status: Inappropriate [oe-core specific]
+Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
+---
+ test/libapt/CMakeLists.txt | 16 ----------------
+ 1 file changed, 16 deletions(-)
+
+diff --git a/test/libapt/CMakeLists.txt b/test/libapt/CMakeLists.txt
+index 035ff07..280b83c 100644
+--- a/test/libapt/CMakeLists.txt
++++ b/test/libapt/CMakeLists.txt
+@@ -6,22 +6,6 @@ find_path(GTEST_ROOT src/gtest.cc
+ find_package(GTest)
+ set(GTEST_DEPENDENCIES)
+ 
+-if(NOT GTEST_FOUND AND EXISTS ${GTEST_ROOT})
+-   include(ExternalProject)
+-   ExternalProject_Add(gtest PREFIX ./gtest
+-                             SOURCE_DIR ${GTEST_ROOT}
+-                             INSTALL_COMMAND true)
+-
+-   link_directories(${CMAKE_CURRENT_BINARY_DIR}/gtest/src/gtest-build)
+-
+-   set(GTEST_LIBRARIES "-lgtest")
+-   set(GTEST_DEPENDENCIES "gtest")
+-   set(GTEST_FOUND TRUE)
+-   find_path(GTEST_INCLUDE_DIRS NAMES gtest/gtest.h PATHS ${GTEST_ROOT}/include)
+-
+-   message(STATUS "Found GTest at ${GTEST_ROOT}, headers at ${GTEST_INCLUDE_DIRS}")
+-endif()
+-
+ if(GTEST_FOUND)
+    # gtest produces some warnings with the set of warnings we activate,
+    # so disable the offending warnings while compiling tests for now

meta/recipes-devtools/apt/apt_1.8.2.1.bb

@@ -8,6 +8,7 @@ SRC_URI = "${DEBIAN_MIRROR}/main/a/apt/${BPN}_${PV}.tar.xz \
            file://0001-Disable-documentation-directory-altogether.patch \
            file://0001-Fix-musl-build.patch \
            file://0001-CMakeLists.txt-avoid-changing-install-paths-based-on.patch \
+           file://0001-test-libapt-do-not-use-gtest-from-the-host.patch \
            "
      
 SRC_URI_append_class-native = " \

meta/recipes-devtools/binutils/binutils-2.35.inc

@@ -41,5 +41,7 @@ SRC_URI = "\
      file://0014-Fix-rpath-in-libtool-when-sysroot-is-enabled.patch \
      file://0015-sync-with-OE-libtool-changes.patch \
      file://0016-Check-for-clang-before-checking-gcc-version.patch \
+     file://0017-gas-improve-reproducibility-for-stabs-debugging-data.patch \
+     file://0001-aarch64-Return-an-error-on-conditional-branch-to-an-.patch \
 "
 S  = "${WORKDIR}/git"

meta/recipes-devtools/binutils/binutils/0001-aarch64-Return-an-error-on-conditional-branch-to-an-.patch

@@ -0,0 +1,135 @@
+From c7cd291722779c9d4703ed0010388fe394c644c8 Mon Sep 17 00:00:00 2001
+From: Siddhesh Poyarekar <siddesh.poyarekar@arm.com>
+Date: Tue, 1 Sep 2020 14:25:52 +0530
+Subject: [PATCH] aarch64: Return an error on conditional branch to an undefined symbol
+
+The fix in 7e05773767820b441b23a16628b55c98cb1aef46 introduced a PLT
+for conditional jumps when the target symbol is undefined.  This is
+incorrect because conditional branch relocations are not allowed to
+clobber IP0/IP1 and hence, should not result in a dynamic relocation.
+
+Revert that change and in its place, issue an error when the target
+symbol is undefined.
+
+bfd/
+
+	2020-09-10  Siddhesh Poyarekar  <siddesh.poyarekar@arm.com>
+
+	* elfnn-aarch64.c (elfNN_aarch64_final_link_relocate): Revert
+	changes in 7e05773767820b441b23a16628b55c98cb1aef46.  Set
+	error for undefined symbol in BFD_RELOC_AARCH64_BRANCH19 and
+	BFD_RELOC_AARCH64_TSTBR14 relocations.
+
+ld/
+
+	2020-09-10  Siddhesh Poyarekar  <siddesh.poyarekar@arm.com>
+
+	* testsuite/ld-aarch64/emit-relocs-560.d: Expect error instead
+	of valid output.
+---
+Upstream-Status: Backport [https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=c7cd291722779c9d4703ed0010388fe394c644c8]
+Signed-off-by: Khem Raj <raj.khem@gmail.com>
+
+ bfd/ChangeLog                             |  7 +++++
+ bfd/elfnn-aarch64.c                       | 37 ++++++++++++-----------
+ ld/ChangeLog                              |  5 +++
+ ld/testsuite/ld-aarch64/emit-relocs-560.d |  7 +----
+ 4 files changed, 32 insertions(+), 24 deletions(-)
+
+diff --git a/bfd/elfnn-aarch64.c b/bfd/elfnn-aarch64.c
+index 5b4c189b593..a9924e7ec56 100644
+--- a/bfd/elfnn-aarch64.c
++++ b/bfd/elfnn-aarch64.c
+@@ -5447,7 +5447,6 @@ elfNN_aarch64_final_link_relocate (reloc_howto_type *howto,
+   bfd_vma orig_value = value;
+   bfd_boolean resolved_to_zero;
+   bfd_boolean abs_symbol_p;
+-  bfd_boolean via_plt_p;
+ 
+   globals = elf_aarch64_hash_table (info);
+ 
+@@ -5469,8 +5468,6 @@ elfNN_aarch64_final_link_relocate (reloc_howto_type *howto,
+ 		  : bfd_is_und_section (sym_sec));
+   abs_symbol_p = h != NULL && bfd_is_abs_symbol (&h->root);
+ 
+-  via_plt_p = (globals->root.splt != NULL && h != NULL
+-	       && h->plt.offset != (bfd_vma) - 1);
+ 
+   /* Since STT_GNU_IFUNC symbol must go through PLT, we handle
+      it here if it is defined in a non-shared object.  */
+@@ -5806,23 +5803,12 @@ elfNN_aarch64_final_link_relocate (reloc_howto_type *howto,
+ 	value += signed_addend;
+       break;
+ 
+-    case BFD_RELOC_AARCH64_BRANCH19:
+-    case BFD_RELOC_AARCH64_TSTBR14:
+-      /* A conditional branch to an undefined weak symbol is converted to a
+-	 branch to itself.  */
+-      if (weak_undef_p && !via_plt_p)
+-	{
+-	  value = _bfd_aarch64_elf_resolve_relocation (input_bfd, bfd_r_type,
+-						       place, value,
+-						       signed_addend,
+-						       weak_undef_p);
+-	  break;
+-	}
+-      /* Fall through.  */
+     case BFD_RELOC_AARCH64_CALL26:
+     case BFD_RELOC_AARCH64_JUMP26:
+       {
+ 	asection *splt = globals->root.splt;
++	bfd_boolean via_plt_p =
++	  splt != NULL && h != NULL && h->plt.offset != (bfd_vma) - 1;
+ 
+ 	/* A call to an undefined weak symbol is converted to a jump to
+ 	   the next instruction unless a PLT entry will be created.
+@@ -5903,6 +5889,23 @@ elfNN_aarch64_final_link_relocate (reloc_howto_type *howto,
+ 	  bfd_set_error (bfd_error_bad_value);
+ 	  return bfd_reloc_notsupported;
+ 	}
++      value = _bfd_aarch64_elf_resolve_relocation (input_bfd, bfd_r_type,
++						   place, value,
++						   signed_addend,
++						   weak_undef_p);
++      break;
++
++    case BFD_RELOC_AARCH64_BRANCH19:
++    case BFD_RELOC_AARCH64_TSTBR14:
++      if (h && h->root.type == bfd_link_hash_undefined)
++	{
++	  _bfd_error_handler
++	    /* xgettext:c-format */
++	    (_("%pB: conditional branch to undefined symbol `%s' "
++	       "not allowed"), input_bfd, h->root.root.string);
++	  bfd_set_error (bfd_error_bad_value);
++	  return bfd_reloc_notsupported;
++	}
+       /* Fall through.  */
+ 
+     case BFD_RELOC_AARCH64_16:
+@@ -7968,8 +7971,6 @@ elfNN_aarch64_check_relocs (bfd *abfd, struct bfd_link_info *info,
+ 	    break;
+ 	  }
+ 
+-	case BFD_RELOC_AARCH64_BRANCH19:
+-	case BFD_RELOC_AARCH64_TSTBR14:
+ 	case BFD_RELOC_AARCH64_CALL26:
+ 	case BFD_RELOC_AARCH64_JUMP26:
+ 	  /* If this is a local symbol then we resolve it
+diff --git a/ld/testsuite/ld-aarch64/emit-relocs-560.d b/ld/testsuite/ld-aarch64/emit-relocs-560.d
+index 153532457b4..8751b743bd4 100644
+--- a/ld/testsuite/ld-aarch64/emit-relocs-560.d
++++ b/ld/testsuite/ld-aarch64/emit-relocs-560.d
+@@ -1,8 +1,3 @@
+ #source: emit-relocs-560.s
+ #ld: -shared
+-#readelf: -r
+-
+-Relocation section '.rela.plt' at offset 0x[0-9a-f]+ contains 2 entries:
+-  Offset          Info           Type           Sym. Value    Sym. Name \+ Addend
+-[0-9a-f]+  000100000402 R_AARCH64_JUMP_SL 0000000000000000 baz \+ 0
+-[0-9a-f]+  000200000402 R_AARCH64_JUMP_SL 0000000000000000 bar \+ 0
++#error: .*: conditional branch to undefined symbol `bar' not allowed
+-- 
+2.29.2
+

meta/recipes-devtools/binutils/binutils/0017-gas-improve-reproducibility-for-stabs-debugging-data.patch

@@ -0,0 +1,35 @@
+From aa6586e80fc6fcd739aa959a71e4cf064cdef072 Mon Sep 17 00:00:00 2001
+From: Denys Zagorui <dzagorui@cisco.com>
+Date: Mon, 9 Nov 2020 15:39:10 +0000
+Subject: [PATCH] gas: improve reproducibility for stabs debugging data format
+
+	* config/obj-elf (obj_elf_init_stab_section): Improve
+	reproducibility for stabs debugging data format
+
+Upstream-Status: Backport [https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=0541201782c006c09d029d18a45c6e743cfea906]
+---
+ gas/config/obj-elf.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/gas/config/obj-elf.c b/gas/config/obj-elf.c
+index de22b5a1da..2025df8542 100644
+--- a/gas/config/obj-elf.c
++++ b/gas/config/obj-elf.c
+@@ -2374,12 +2374,13 @@ obj_elf_init_stab_section (segT seg)
+   p = frag_more (12);
+   /* Zero it out.  */
+   memset (p, 0, 12);
+-  file = as_where (NULL);
++  file = remap_debug_filename (as_where (NULL));
+   stabstr_name = concat (segment_name (seg), "str", (char *) NULL);
+   stroff = get_stab_string_offset (file, stabstr_name, TRUE);
+   know (stroff == 1 || (stroff == 0 && file[0] == '\0'));
+   md_number_to_chars (p, stroff, 4);
+   seg_info (seg)->stabu.p = p;
++  xfree ((char *) file);
+ }
+ 
+ #endif
+-- 
+2.20.1
+

meta/recipes-devtools/diffstat/diffstat_1.63.bb

@@ -27,3 +27,5 @@ LDFLAGS += "${TOOLCHAIN_OPTIONS}"
 do_install_ptest() {
 	cp -r ${S}/testing ${D}${PTEST_PATH}
 }
+
+BBCLASSEXTEND = "nativesdk"

meta/recipes-devtools/e2fsprogs/e2fsprogs_1.45.6.bb

@@ -125,6 +125,8 @@ do_compile_ptest() {
 }
 
 do_install_ptest() {
+	# This file's permissions depends on the host umask so be deterministic
+	chmod 0644 ${B}/tests/test_data.tmp
 	cp -R --no-dereference --preserve=mode,links -v ${B}/tests ${D}${PTEST_PATH}/test
 	cp -R --no-dereference --preserve=mode,links -v ${S}/tests/* ${D}${PTEST_PATH}/test
 	sed -e 's!../e2fsck/e2fsck!e2fsck!g' \

meta/recipes-devtools/libdnf/libdnf_0.48.0.bb

@@ -1,5 +1,5 @@
 SUMMARY = "Library providing simplified C and Python API to libsolv"
-LICENSE = "LGPLv2.1"
+LICENSE = "LGPLv2.1+"
 LIC_FILES_CHKSUM = "file://COPYING;md5=4fbd65380cdd255951079008b364516c"
 
 SRC_URI = "git://github.com/rpm-software-management/libdnf;branch=dnf-4-master \

meta/recipes-devtools/python/python3/CVE-2020-27619.patch

@@ -0,0 +1,71 @@
+From 6c6c256df3636ff6f6136820afaefa5a10a3ac33 Mon Sep 17 00:00:00 2001
+From: "Miss Skeleton (bot)" <31488909+miss-islington@users.noreply.github.com>
+Date: Tue, 6 Oct 2020 05:38:54 -0700
+Subject: [PATCH] bpo-41944: No longer call eval() on content received via HTTP
+ in the CJK codec tests (GH-22566) (GH-22577)
+
+(cherry picked from commit 2ef5caa58febc8968e670e39e3d37cf8eef3cab8)
+
+Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
+
+Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
+
+Upstream-Status: Backport [https://github.com/python/cpython/commit/6c6c256df3636ff6f6136820afaefa5a10a3ac33]
+CVE: CVE-2020-27619
+Signed-off-by: Chee Yang Lee <chee.yang.lee@intel.com>
+
+---
+ Lib/test/multibytecodec_support.py            | 22 +++++++------------
+ .../2020-10-05-17-43-46.bpo-41944.rf1dYb.rst  |  1 +
+ 2 files changed, 9 insertions(+), 14 deletions(-)
+ create mode 100644 Misc/NEWS.d/next/Tests/2020-10-05-17-43-46.bpo-41944.rf1dYb.rst
+
+diff --git a/Lib/test/multibytecodec_support.py b/Lib/test/multibytecodec_support.py
+index cca8af67d6d1d..f76c0153f5ecf 100644
+--- a/Lib/test/multibytecodec_support.py
++++ b/Lib/test/multibytecodec_support.py
+@@ -305,29 +305,23 @@ def test_mapping_file(self):
+             self._test_mapping_file_plain()
+ 
+     def _test_mapping_file_plain(self):
+-        unichrs = lambda s: ''.join(map(chr, map(eval, s.split('+'))))
++        def unichrs(s):
++            return ''.join(chr(int(x, 16)) for x in s.split('+'))
++
+         urt_wa = {}
+ 
+         with self.open_mapping_file() as f:
+             for line in f:
+                 if not line:
+                     break
+-                data = line.split('#')[0].strip().split()
++                data = line.split('#')[0].split()
+                 if len(data) != 2:
+                     continue
+ 
+-                csetval = eval(data[0])
+-                if csetval <= 0x7F:
+-                    csetch = bytes([csetval & 0xff])
+-                elif csetval >= 0x1000000:
+-                    csetch = bytes([(csetval >> 24), ((csetval >> 16) & 0xff),
+-                                    ((csetval >> 8) & 0xff), (csetval & 0xff)])
+-                elif csetval >= 0x10000:
+-                    csetch = bytes([(csetval >> 16), ((csetval >> 8) & 0xff),
+-                                    (csetval & 0xff)])
+-                elif csetval >= 0x100:
+-                    csetch = bytes([(csetval >> 8), (csetval & 0xff)])
+-                else:
++                if data[0][:2] != '0x':
++                    self.fail(f"Invalid line: {line!r}")
++                csetch = bytes.fromhex(data[0][2:])
++                if len(csetch) == 1 and 0x80 <= csetch[0]:
+                     continue
+ 
+                 unich = unichrs(data[1])
+diff --git a/Misc/NEWS.d/next/Tests/2020-10-05-17-43-46.bpo-41944.rf1dYb.rst b/Misc/NEWS.d/next/Tests/2020-10-05-17-43-46.bpo-41944.rf1dYb.rst
+new file mode 100644
+index 0000000000000..4f9782f1c85af
+--- /dev/null
++++ b/Misc/NEWS.d/next/Tests/2020-10-05-17-43-46.bpo-41944.rf1dYb.rst
+@@ -0,0 +1 @@
++Tests for CJK codecs no longer call ``eval()`` on content received via HTTP.

meta/recipes-devtools/python/python3_3.8.5.bb

@@ -32,6 +32,7 @@ SRC_URI = "http://www.python.org/ftp/python/${PV}/Python-${PV}.tar.xz \
            file://0001-configure.ac-fix-LIBPL.patch \
            file://0001-python3-Do-not-hardcode-lib-for-distutils.patch \
            file://0020-configure.ac-setup.py-do-not-add-a-curses-include-pa.patch \
+           file://CVE-2020-27619.patch \
            "
 
 SRC_URI_append_class-native = " \
@@ -49,6 +50,8 @@ UPSTREAM_CHECK_URI = "https://www.python.org/downloads/source/"
 
 CVE_PRODUCT = "python"
 
+# Upstream consider this expected behaviour
+CVE_CHECK_WHITELIST += "CVE-2007-4559"
 # This is not exploitable when glibc has CVE-2016-10739 fixed.
 CVE_CHECK_WHITELIST += "CVE-2019-18348"
 

meta/recipes-devtools/qemu/qemu.inc

@@ -32,6 +32,7 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \
            file://find_datadir.patch \
            file://usb-fix-setup_len-init.patch \
            file://0001-target-mips-Increase-number-of-TLB-entries-on-the-34.patch \
+           file://CVE-2020-24352.patch \
            "
 UPSTREAM_CHECK_REGEX = "qemu-(?P<pver>\d+(\.\d+)+)\.tar"
 

meta/recipes-devtools/qemu/qemu/CVE-2020-24352.patch

@@ -0,0 +1,52 @@
+From ca1f9cbfdce4d63b10d57de80fef89a89d92a540 Mon Sep 17 00:00:00 2001
+From: Prasad J Pandit <pjp@fedoraproject.org>
+Date: Wed, 21 Oct 2020 16:08:18 +0530
+Subject: [PATCH 1/1] ati: check x y display parameter values
+
+The source and destination x,y display parameters in ati_2d_blt()
+may run off the vga limits if either of s->regs.[src|dst]_[xy] is
+zero. Check the parameter values to avoid potential crash.
+
+Reported-by: Gaoning Pan <pgn@zju.edu.cn>
+Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org>
+Message-id: 20201021103818.1704030-1-ppandit@redhat.com
+Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
+
+Upstream-Status: Backport [ https://git.qemu.org/?p=qemu.git;a=commitdiff;h=ca1f9cbfdce4d63b10d57de80fef89a89d92a540;hp=2ddafce7f797082ad216657c830afd4546f16e37 ]
+CVE: CVE-2020-24352
+Signed-off-by: Chee Yang Lee <chee.yang.lee@intel.com>
+---
+ hw/display/ati_2d.c | 10 ++++++----
+ 1 file changed, 6 insertions(+), 4 deletions(-)
+
+diff --git a/hw/display/ati_2d.c b/hw/display/ati_2d.c
+index 23a8ae0..4dc10ea 100644
+--- a/hw/display/ati_2d.c
++++ b/hw/display/ati_2d.c
+@@ -75,8 +75,9 @@ void ati_2d_blt(ATIVGAState *s)
+         dst_stride *= bpp;
+     }
+     uint8_t *end = s->vga.vram_ptr + s->vga.vram_size;
+-    if (dst_bits >= end || dst_bits + dst_x + (dst_y + s->regs.dst_height) *
+-        dst_stride >= end) {
++    if (dst_x > 0x3fff || dst_y > 0x3fff || dst_bits >= end
++        || dst_bits + dst_x
++         + (dst_y + s->regs.dst_height) * dst_stride >= end) {
+         qemu_log_mask(LOG_UNIMP, "blt outside vram not implemented\n");
+         return;
+     }
+@@ -107,8 +108,9 @@ void ati_2d_blt(ATIVGAState *s)
+             src_bits += s->regs.crtc_offset & 0x07ffffff;
+             src_stride *= bpp;
+         }
+-        if (src_bits >= end || src_bits + src_x +
+-            (src_y + s->regs.dst_height) * src_stride >= end) {
++        if (src_x > 0x3fff || src_y > 0x3fff || src_bits >= end
++            || src_bits + src_x
++             + (src_y + s->regs.dst_height) * src_stride >= end) {
+             qemu_log_mask(LOG_UNIMP, "blt outside vram not implemented\n");
+             return;
+         }
+-- 
+1.8.3.1
+

meta/recipes-devtools/ruby/ruby/CVE-2020-25613.patch

@@ -0,0 +1,40 @@
+From 8946bb38b4d87549f0d99ed73c62c41933f97cc7 Mon Sep 17 00:00:00 2001
+From: Yusuke Endoh <mame@ruby-lang.org>
+Date: Tue, 29 Sep 2020 13:15:58 +0900
+Subject: [PATCH] Make it more strict to interpret some headers
+
+Some regexps were too tolerant.
+
+Upstream-Status: Backport
+[https://github.com/ruby/webrick/commit/8946bb38b4d87549f0d99ed73c62c41933f97cc7]
+CVE: CVE-2020-25613
+Signed-off-by: Chee Yang Lee <chee.yang.lee@intel.com>
+---
+ lib/webrick/httprequest.rb | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/lib/webrick/httprequest.rb b/lib/webrick/httprequest.rb
+index 294bd91..d34eac7 100644
+--- a/lib/webrick/httprequest.rb
++++ b/lib/webrick/httprequest.rb
+@@ -227,9 +227,9 @@ def parse(socket=nil)
+         raise HTTPStatus::BadRequest, "bad URI `#{@unparsed_uri}'."
+       end
+ 
+-      if /close/io =~ self["connection"]
++      if /\Aclose\z/io =~ self["connection"]
+         @keep_alive = false
+-      elsif /keep-alive/io =~ self["connection"]
++      elsif /\Akeep-alive\z/io =~ self["connection"]
+         @keep_alive = true
+       elsif @http_version < "1.1"
+         @keep_alive = false
+@@ -508,7 +508,7 @@ def read_body(socket, block)
+       return unless socket
+       if tc = self['transfer-encoding']
+         case tc
+-        when /chunked/io then read_chunked(socket, block)
++        when /\Achunked\z/io then read_chunked(socket, block)
+         else raise HTTPStatus::NotImplemented, "Transfer-Encoding: #{tc}."
+         end
+       elsif self['content-length'] || @remaining_size

meta/recipes-devtools/ruby/ruby_2.7.1.bb

@@ -6,6 +6,7 @@ SRC_URI += " \
            file://remove_has_include_macros.patch \
            file://run-ptest \
            file://0001-Modify-shebang-of-libexec-y2racc-and-libexec-racc2y.patch \
+           file://CVE-2020-25613.patch \
            "
 
 SRC_URI[md5sum] = "debb9c325bf65021214451660f46e909"

meta/recipes-devtools/valgrind/valgrind/0001-helgrind-Intercept-libc-functions.patch

@@ -0,0 +1,54 @@
+From cdec010444df5a4328e90d07a2024fdeefcc74b5 Mon Sep 17 00:00:00 2001
+From: Paul Floyd <paulf@free.fr>
+Date: Wed, 18 Nov 2020 12:49:20 -0400
+Subject: [PATCH] helgrind: Intercept libc functions
+
+PTH_FUNC definition needs to be modified in order to
+intercept posix thread functions in both libc and
+libpthread. In order to handle this in helgrind, weak alias
+the pthread functions in glibc.
+
+Upstream-Status: Submitted
+
+Signed-off-by: Paul Floyd <paulf@free.fr>
+Signed-off-by: Stacy Gaikovaia <stacy.gaikovaia@windriver.com>
+---
+ helgrind/hg_intercepts.c | 12 ++++++++++++
+ 1 file changed, 12 insertions(+)
+
+diff --git a/helgrind/hg_intercepts.c b/helgrind/hg_intercepts.c
+index a10c3a4a3..316140ca6 100644
+--- a/helgrind/hg_intercepts.c
++++ b/helgrind/hg_intercepts.c
+@@ -77,6 +77,11 @@
+ /*---                                                          ---*/
+ /*----------------------------------------------------------------*/
+ 
++#define hg_expand(tok) #tok
++#define hg_str(tok) hg_expand(tok)
++# define hg_weak_alias(name, aliasname) \
++  extern __typeof (name) aliasname __attribute__ ((weak, alias(hg_str(name))))
++
+ #if defined(VGO_solaris)
+ /* On Solaris, libpthread is just a filter library on top of libc.
+  * Threading and synchronization functions in runtime linker are not
+@@ -91,9 +96,16 @@
+ #define CREQ_PTHREAD_T Word
+ #define SEM_ERROR ret
+ #else
++#ifdef MUSL_LIBC
++#define PTH_FUNC(ret_ty, f, args...) \
++   ret_ty I_WRAP_SONAME_FNNAME_ZZ(VG_Z_LIBPTHREAD_SONAME,f)(args); \
++   ret_ty I_WRAP_SONAME_FNNAME_ZZ(VG_Z_LIBPTHREAD_SONAME,f)(args)
++#else
+ #define PTH_FUNC(ret_ty, f, args...) \
+    ret_ty I_WRAP_SONAME_FNNAME_ZZ(VG_Z_LIBPTHREAD_SONAME,f)(args); \
++   hg_weak_alias(I_WRAP_SONAME_FNNAME_ZZ(VG_Z_LIBPTHREAD_SONAME,f), I_WRAP_SONAME_FNNAME_ZZ(VG_Z_LIBC_SONAME,f)); \
+    ret_ty I_WRAP_SONAME_FNNAME_ZZ(VG_Z_LIBPTHREAD_SONAME,f)(args)
++#endif
+ #define CREQ_PTHREAD_T pthread_t
+ #define SEM_ERROR errno
+ #endif /* VGO_solaris */
+-- 
+2.17.1
+

meta/recipes-devtools/valgrind/valgrind_3.16.1.bb

@@ -42,6 +42,7 @@ SRC_URI = "https://sourceware.org/pub/valgrind/valgrind-${PV}.tar.bz2 \
            file://0001-memcheck-tests-Fix-timerfd-syscall-test.patch \
            file://0001-drd-Port-to-Fedora-33.patch \
            file://0001-drd-musl-fix.patch \
+           file://0001-helgrind-Intercept-libc-functions.patch \
            "
 SRC_URI[md5sum] = "d1b153f1ab17cf1f311705e7a83ef589"
 SRC_URI[sha256sum] = "c91f3a2f7b02db0f3bc99479861656154d241d2fdb265614ba918cc6720a33ca"

meta/recipes-extended/gawk/gawk/0001-Use-cross-AR-during-compile.patch

@@ -0,0 +1,35 @@
+From 207b94e37c84007b294e57878c913271aad544ef Mon Sep 17 00:00:00 2001
+From: Khem Raj <raj.khem@gmail.com>
+Date: Wed, 11 Nov 2020 23:13:23 -0800
+Subject: [PATCH] Use cross AR during compile
+
+If AR is specifcied then it should be used instead of defaulting to 'ar'
+from host
+
+Upstream-Status: Pending
+Signed-off-by: Khem Raj <raj.khem@gmail.com>
+---
+ configure.ac | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+diff --git a/configure.ac b/configure.ac
+index 31364ab..4804f7b 100644
+--- a/configure.ac
++++ b/configure.ac
+@@ -92,6 +92,13 @@ GAWK_CANONICAL_HOST
+ AC_USE_SYSTEM_EXTENSIONS
+ 
+ dnl checks for programs
++m4_ifndef([AC_PROG_AR],[dnl
++  AN_MAKEVAR([AR], [AC_PROG_AR])
++  AN_PROGRAM([ar], [AC_PROG_AR])
++  AC_DEFUN([AC_PROG_AR],
++  [AC_CHECK_TOOL(AR, ar, :)])
++])
++AC_PROG_AR
+ AC_PROG_EGREP
+ AC_PROG_YACC
+ AC_PROG_LN_S
+-- 
+2.29.2
+

meta/recipes-extended/gawk/gawk_5.1.0.bb

@@ -17,6 +17,7 @@ PACKAGECONFIG[mpfr] = "--with-mpfr,--without-mpfr, mpfr"
 
 SRC_URI = "${GNU_MIRROR}/gawk/gawk-${PV}.tar.gz \
            file://run-ptest \
+           file://0001-Use-cross-AR-during-compile.patch \
 "
 
 SRC_URI[md5sum] = "f719bc9966df28e67fc6ebc405e7ea03"