meta-openembedded and poky: subtree updates

Squash of the following due to dependencies among them
and OpenBMC changes:

meta-openembedded: subtree update:d0748372d2..9201611135
meta-openembedded: subtree update:9201611135..17fd382f34
poky: subtree update:9052e5b32a..2e11d97b6c
poky: subtree update:2e11d97b6c..a8544811d7

The change log was too large for the jenkins plugin
to handle therefore it has been removed. Here is
the first and last commit of each subtree:

meta-openembedded:d0748372d2
      cppzmq: bump to version 4.6.0
meta-openembedded:17fd382f34
      mpv: Remove X11 dependency
poky:9052e5b32a
      package_ipk: Remove pointless comment to trigger rebuild
poky:a8544811d7
      pbzip2: Fix license warning

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

4 files changed, 314 insertions, 154 deletions

diff --git a/poky/documentation/dev-manual/dev-manual-common-tasks.xml b/poky/documentation/dev-manual/dev-manual-common-tasks.xml
index 00741ee45..e9ce182a5 100644
--- a/poky/documentation/dev-manual/dev-manual-common-tasks.xml
+++ b/poky/documentation/dev-manual/dev-manual-common-tasks.xml
@@ -184,6 +184,10 @@
                                 variable.
                                 </para></listitem>
                             <listitem><para>
+                                <ulink url='&YOCTO_DOCS_REF_URL;#var-LAYERDEPENDS'><filename>LAYERDEPENDS</filename></ulink>:
+                                Lists all layers on which this layer depends (if any).
+                                </para></listitem>
+                            <listitem><para>
                                 <ulink url='&YOCTO_DOCS_REF_URL;#var-LAYERSERIES_COMPAT'><filename>LAYERSERIES_COMPAT</filename></ulink>:
                                 Lists the
                                 <ulink url='&YOCTO_WIKI_URL;/wiki/Releases'>Yocto Project</ulink>
@@ -315,12 +319,26 @@
      DEPENDS_append_one = " foo"
      DEPENDS_prepend_one = "foo "
                                 </literallayout>
-                                As an actual example, here's a line from the recipe
-                                for gnutls, which adds dependencies on
-                                "argp-standalone" when building with the musl C
-                                library:
+                                As an actual example, here's a snippet from the
+                                generic kernel include file
+                                <filename>linux-yocto.inc</filename>,
+                                wherein the kernel compile and link options are
+                                adjusted in the case of a subset of the supported
+                                architectures:
                                 <literallayout class='monospaced'>
-     DEPENDS_append_libc-musl = " argp-standalone"
+     DEPENDS_append_aarch64 = " libgcc"
+     KERNEL_CC_append_aarch64 = " ${TOOLCHAIN_OPTIONS}"
+     KERNEL_LD_append_aarch64 = " ${TOOLCHAIN_OPTIONS}"
+
+     DEPENDS_append_nios2 = " libgcc"
+     KERNEL_CC_append_nios2 = " ${TOOLCHAIN_OPTIONS}"
+     KERNEL_LD_append_nios2 = " ${TOOLCHAIN_OPTIONS}"
+
+     DEPENDS_append_arc = " libgcc"
+     KERNEL_CC_append_arc = " ${TOOLCHAIN_OPTIONS}"
+     KERNEL_LD_append_arc = " ${TOOLCHAIN_OPTIONS}"
+
+     KERNEL_FEATURES_append_qemuall=" features/debug/printk.scc"
                                 </literallayout>
                                 <note>
                                     Avoiding "+=" and "=+" and using
@@ -580,11 +598,19 @@
                             <filename>bitbake -e</filename>).
                             </para></listitem>
                         <listitem><para>
+                            <filename>common.test_world</filename>:
+                            Verifies that <filename>bitbake world</filename> works.
+                            </para></listitem>
+                        <listitem><para>
                             <filename>common.test_signatures</filename>:
                             Tests to be sure that BSP and DISTRO layers do not
                             come with recipes that change signatures.
                             </para></listitem>
                         <listitem><para>
+                            <filename>common.test_layerseries_compat</filename>:
+                            Verifies layer compatibility is set properly.
+                            </para></listitem>
+                        <listitem><para>
                             <filename>bsp.test_bsp_defines_machines</filename>:
                             Tests if a BSP layer has machine configurations.
                             </para></listitem>
@@ -594,11 +620,22 @@
                             machine when the layer is added.
                             </para></listitem>
                         <listitem><para>
+                            <filename>bsp.test_machine_world</filename>:
+                            Verifies that <filename>bitbake world</filename>
+                            works regardless of which machine is selected.
+                            </para></listitem>
+                        <listitem><para>
+                            <filename>bsp.test_machine_signatures</filename>:
+                            Verifies that building for a particular machine
+                            affects only the signature of tasks specific to that
+                            machine.
+                            </para></listitem>
+                        <listitem><para>
                             <filename>distro.test_distro_defines_distros</filename>:
                             Tests if a DISTRO layer has distro configurations.
                             </para></listitem>
                         <listitem><para>
-                            <filename>distro.test_distro_no_set_distro</filename>:
+                            <filename>distro.test_distro_no_set_distros</filename>:
                             Tests to ensure a DISTRO layer does not set the
                             distribution when the layer is added.
                             </para></listitem>
@@ -1397,7 +1434,7 @@
                 package specified in the <filename>PACKAGES</filename>
                 statement.
                 <note>
-                    The <filename>inherit packages</filename> should be
+                    The <filename>inherit packagegroup</filename> line should be
                     located near the top of the recipe, certainly before
                     the <filename>PACKAGES</filename> statement.
                 </note>
@@ -1417,28 +1454,32 @@
 
             <para>
                 Here is a short, fabricated example showing the same basic
-                pieces:
+                pieces for a hypothetical packagegroup defined in
+                <filename>packagegroup-custom.bb</filename>, where the
+                variable <filename>PN</filename> is the standard way to
+                abbreviate the reference to the full packagegroup name
+                <filename>packagegroup-custom</filename>:
                 <literallayout class='monospaced'>
      DESCRIPTION = "My Custom Package Groups"
 
      inherit packagegroup
 
      PACKAGES = "\
-         packagegroup-custom-apps \
-         packagegroup-custom-tools \
+         ${PN}-apps \
+         ${PN}-tools \
          "
 
-     RDEPENDS_packagegroup-custom-apps = "\
+     RDEPENDS_${PN}-apps = "\
          dropbear \
          portmap \
          psplash"
 
-     RDEPENDS_packagegroup-custom-tools = "\
+     RDEPENDS_${PN}-tools = "\
          oprofile \
          oprofileui-server \
          lttng-tools"
 
-     RRECOMMENDS_packagegroup-custom-tools = "\
+     RRECOMMENDS_${PN}-tools = "\
          kernel-module-oprofile"
                 </literallayout>
             </para>
@@ -1900,9 +1941,9 @@
             <para>
                 The <filename>SRC_URI</filename> variable in your recipe must
                 define each unique location for your source files.
-                It is good practice to not hard-code pathnames in an URL used
+                It is good practice to not hard-code version numbers in a URL used
                 in <filename>SRC_URI</filename>.
-                Rather than hard-code these paths, use
+                Rather than hard-code these values, use
                 <filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PV'><filename>PV</filename></ulink><filename>}</filename>,
                 which causes the fetch process to use the version specified in
                 the recipe filename.
@@ -1913,13 +1954,13 @@
 
             <para>
                 Here is a simple example from the
-                <filename>meta/recipes-devtools/cdrtools/cdrtools-native_3.01a20.bb</filename>
+                <filename>meta/recipes-devtools/strace/strace_5.5.bb</filename>
                 recipe where the source comes from a single tarball.
                 Notice the use of the
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-PV'><filename>PV</filename></ulink>
                 variable:
                 <literallayout class='monospaced'>
-     SRC_URI = "ftp://ftp.berlios.de/pub/cdrecord/alpha/cdrtools-${PV}.tar.bz2"
+     SRC_URI = "https://strace.io/files/${PV}/strace-${PV}.tar.xz \
                 </literallayout>
             </para>
 
@@ -1978,16 +2019,17 @@
                 For these cases, you provide a name for each URL as part of
                 the <filename>SRC_URI</filename> and then reference that name
                 in the subsequent checksum statements.
-                Here is an example:
+                Here is an example combining lines from the files
+                <filename>git.inc</filename> and
+                <filename>git_2.24.1.bb</filename>:
                 <literallayout class='monospaced'>
-     SRC_URI = "${DEBIAN_MIRROR}/main/a/apmd/apmd_3.2.2.orig.tar.gz;name=tarball \
-                ${DEBIAN_MIRROR}/main/a/apmd/apmd_${PV}.diff.gz;name=patch"
+     SRC_URI = "${KERNELORG_MIRROR}/software/scm/git/git-${PV}.tar.gz;name=tarball \
+                ${KERNELORG_MIRROR}/software/scm/git/git-manpages-${PV}.tar.gz;name=manpages"
 
-     SRC_URI[tarball.md5sum] = "b1e6309e8331e0f4e6efd311c2d97fa8"
-     SRC_URI[tarball.sha256sum] = "7f7d9f60b7766b852881d40b8ff91d8e39fccb0d1d913102a5c75a2dbb52332d"
-
-     SRC_URI[patch.md5sum] = "57e1b689264ea80f78353519eece0c92"
-     SRC_URI[patch.sha256sum] = "7905ff96be93d725544d0040e425c42f9c05580db3c272f11cff75b9aa89d430"
+     SRC_URI[tarball.md5sum] = "166bde96adbbc11c8843d4f8f4f9811b"
+     SRC_URI[tarball.sha256sum] = "ad5334956301c86841eb1e5b1bb20884a6bad89a10a6762c958220c7cf64da02"
+     SRC_URI[manpages.md5sum] = "31c2272a8979022497ba3d4202df145d"
+     SRC_URI[manpages.sha256sum] = "9a7ae3a093bea39770eb96ca3e5b40bff7af0b9f6123f089d7821d0e5b8e1230"
                 </literallayout>
             </para>
 
@@ -3242,8 +3284,6 @@
                 The script defined in the post-installation function is
                 called when the root filesystem is created.
                 If the script succeeds, the package is marked as installed.
-                If the script fails, the package is marked as unpacked and
-                the script is executed when the image boots again.
                 <note>
                     Any RPM post-installation script that runs on the target
                     should return a 0 exit code.
@@ -3262,7 +3302,7 @@
                 mark post installs to defer to the target.
                 You can use <filename>pkg_postinst_ontarget()</filename> or
                 call
-                <filename>postinst-intercepts defer_to_first_boot</filename>
+                <filename>postinst_intercept delay_to_first_boot</filename>
                 from <filename>pkg_postinst()</filename>.
                 Any failure of a <filename>pkg_postinst()</filename> script
                 (including exit 1) triggers an error during the
@@ -7609,7 +7649,6 @@
                 available Wic images as follows:
                 <literallayout class='monospaced'>
      $ wic list images
-       mpc8315e-rdb                  		Create SD card image for MPC8315E-RDB
        genericx86                    		Create an EFI disk image for genericx86*
        beaglebone-yocto              		Create SD card image for Beaglebone
        edgerouter                    		Create SD card image for Edgerouter
@@ -7797,7 +7836,6 @@
                 files:
                 <literallayout class='monospaced'>
      $ wic list images
-       mpc8315e-rdb                  		Create SD card image for MPC8315E-RDB
        genericx86                    		Create an EFI disk image for genericx86*
        beaglebone-yocto              		Create SD card image for Beaglebone
        edgerouter                    		Create SD card image for Edgerouter
@@ -10550,7 +10588,7 @@
                     <filename>devtool</filename> and the NPM fetcher to
                     create the recipe:
                     <literallayout class='monospaced'>
-     $ devtool add "npm://registry.npmjs.org;name=cute-files;version=1.0.2"
+     $ devtool add "npm://registry.npmjs.org;package=cute-files;version=1.0.2"
                     </literallayout>
                     The <filename>devtool add</filename> command runs
                     <filename>recipetool create</filename> and uses the
@@ -10575,25 +10613,13 @@
                 </para>
 
                 <para>
-                    <filename>recipetool</filename> creates "shrinkwrap" and
-                    "lockdown" files for your recipe.
+                    <filename>recipetool</filename> creates a "shrinkwrap" file
+                    for your recipe.
                     Shrinkwrap files capture the version of all dependent
                     modules.
                     Many packages do not provide shrinkwrap files.
                     <filename>recipetool</filename> create a shrinkwrap
                     file as it runs.
-                    You can replace the shrinkwrap file with your own file
-                    by setting the <filename>NPM_SHRINKWRAP</filename>
-                    variable.
-                </para>
-
-                <para>
-                    Lockdown files contain the checksum for each module
-                    to determine if your users download the same files when
-                    building with a recipe.
-                    Lockdown files ensure that dependencies have not been
-                    changed and that your NPM registry is still providing
-                    the same file.
                     <note>
                         A package is created for each sub-module.
                         This policy is the only practical way to have the
@@ -10608,23 +10634,26 @@
                     <literallayout class='monospaced'>
      $ devtool edit-recipe cute-files
      SUMMARY = "Turn any folder on your computer into a cute file browser, available on the local network."
-     LICENSE = "BSD-3-Clause &amp; Unknown &amp; MIT &amp; ISC"
+     LICENSE = "MIT &amp; ISC &amp; Unknown"
      LIC_FILES_CHKSUM = "file://LICENSE;md5=71d98c0a1db42956787b1909c74a86ca \
-                         file://node_modules/content-disposition/LICENSE;md5=c6e0ce1e688c5ff16db06b7259e9cd20 \
-                         file://node_modules/express/LICENSE;md5=5513c00a5c36cd361da863dd9aa8875d \
+                         file://node_modules/toidentifier/LICENSE;md5=1a261071a044d02eb6f2bb47f51a3502 \
+                         file://node_modules/debug/LICENSE;md5=ddd815a475e7338b0be7a14d8ee35a99 \
                          ...
 
-     SRC_URI = "npm://registry.npmjs.org;name=cute-files;version=${PV}"
-     NPM_SHRINKWRAP := "${THISDIR}/${PN}/npm-shrinkwrap.json"
-     NPM_LOCKDOWN := "${THISDIR}/${PN}/lockdown.json"
+     SRC_URI = " \
+         npm://registry.npmjs.org/;package=cute-files;version=${PV} \
+         npmsw://${THISDIR}/${BPN}/npm-shrinkwrap.json \
+     "
+
+     S = "${WORKDIR}/npm"
+
      inherit npm
-     # Must be set after inherit npm since that itself sets S
-     S = "${WORKDIR}/npmpkg"
 
-     LICENSE_${PN}-content-disposition = "MIT"
-     ...
-     LICENSE_${PN}-express = "MIT"
      LICENSE_${PN} = "MIT"
+     LICENSE_${PN}-accepts = "MIT"
+     LICENSE_${PN}-array-flatten = "MIT"
+     ...
+     LICENSE_${PN}-vary = "MIT"
                     </literallayout>
                     Three key points exist in the previous example:
                     <itemizedlist>
@@ -10717,11 +10746,10 @@
                     However, the <filename>SRC_URI</filename> looks like the
                     following:
                     <literallayout class='monospaced'>
-     SRC_URI = "git://github.com/martinaglv/cute-files.git;protocol=https \
-               npm://registry.npmjs.org;name=commander;version=2.9.0;subdir=node_modules/commander \
-               npm://registry.npmjs.org;name=express;version=4.14.0;subdir=node_modules/express \
-               npm://registry.npmjs.org;name=content-disposition;version=0.3.0;subdir=node_modules/content-disposition \
-               "
+     SRC_URI = " \
+         git://github.com/martinaglv/cute-files.git;protocol=https \
+         npmsw://${THISDIR}/${BPN}/npm-shrinkwrap.json \
+         "
                     </literallayout>
                     In this example, the main module is taken from the Git
                     repository and dependents are taken from the NPM registry.
@@ -10822,7 +10850,7 @@
                 Use the following BitBake command form to fetch all the
                 necessary sources without starting the build:
                 <literallayout class='monospaced'>
-     $ bitbake -c <replaceable>target</replaceable> runall="fetch"
+     $ bitbake <replaceable>target</replaceable> --runall=fetch
                 </literallayout>
                 This variation of the BitBake command guarantees that you
                 have all the sources for that BitBake target should you
@@ -10845,15 +10873,6 @@
         </para>
 
         <para>
-            By default, the Yocto Project uses SysVinit as the initialization
-            manager.
-            However, support also exists for systemd,
-            which is a full replacement for init with
-            parallel starting of services, reduced shell overhead and other
-            features that are used by many distributions.
-        </para>
-
-        <para>
             Within the system, SysVinit treats system components as services.
             These services are maintained as shell scripts stored in the
             <filename>/etc/init.d/</filename> directory.
@@ -11164,18 +11183,18 @@
 
             <para>
                 To create the read-only root filesystem, simply add the
-                "read-only-rootfs" feature to your image.
-                Using either of the following statements in your
-                image recipe or from within the
-                <filename>local.conf</filename> file found in the
-                <ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink>
-                causes the build system to create a read-only root filesystem:
+                "read-only-rootfs" feature to your image, normally in one of two ways.
+                The first way is to add the "read-only-rootfs" image feature
+                in the image's recipe file via the
+                <filename>IMAGE_FEATURES</filename> variable:
                 <literallayout class='monospaced'>
-     IMAGE_FEATURES = "read-only-rootfs"
+     IMAGE_FEATURES += "read-only-rootfs"
                 </literallayout>
-                or
+                As an alternative, you can add the same feature from within your
+                build directory's <filename>local.conf</filename> file with the
+                associated <filename>EXTRA_IMAGE_FEATURES</filename> variable, as in:
                 <literallayout class='monospaced'>
-     EXTRA_IMAGE_FEATURES += "read-only-rootfs"
+     EXTRA_IMAGE_FEATURES = "read-only-rootfs"
                 </literallayout>
             </para>
 
@@ -12038,15 +12057,15 @@
                     In order to run tests on hardware, you need to set
                     <filename>TEST_TARGET</filename> to an appropriate value.
                     For QEMU, you do not have to change anything, the default
-                    value is "QemuTarget".
+                    value is "qemu".
                     For running tests on hardware, the following options exist:
                     <itemizedlist>
-                        <listitem><para><emphasis>"SimpleRemoteTarget":</emphasis>
-                            Choose "SimpleRemoteTarget" if you are going to
+                        <listitem><para><emphasis>"simpleremote":</emphasis>
+                            Choose "simpleremote" if you are going to
                             run tests on a target system that is already
                             running the image to be tested and is available
                             on the network.
-                            You can use "SimpleRemoteTarget" in conjunction
+                            You can use "simpleremote" in conjunction
                             with either real hardware or an image running
                             within a separately started QEMU or any
                             other virtual machine manager.
@@ -12221,7 +12240,7 @@
                 <title>Power Control</title>
 
                 <para>
-                    For most hardware targets other than SimpleRemoteTarget,
+                    For most hardware targets other than "simpleremote",
                     you can control power:
                     <itemizedlist>
                         <listitem><para>
@@ -12618,7 +12637,7 @@
                                 <listitem><para><emphasis><filename>target</filename>:</emphasis>
                                     The target controller object used to deploy
                                     and start an image on a particular target
-                                    (e.g. QemuTarget, SimpleRemote, and
+                                    (e.g. Qemu, SimpleRemote, and
                                     SystemdbootTarget).
                                     Tests usually use the following:
                                     <itemizedlist>
diff --git a/poky/documentation/dev-manual/dev-manual-qemu.xml b/poky/documentation/dev-manual/dev-manual-qemu.xml
index f5a0d64af..5ccc0dfe8 100644
--- a/poky/documentation/dev-manual/dev-manual-qemu.xml
+++ b/poky/documentation/dev-manual/dev-manual-qemu.xml
@@ -151,13 +151,13 @@
                     <itemizedlist>
                         <listitem><para>
                             This example starts QEMU with
-                            <replaceable>MACHINE</replaceable> set to "qemux86".
+                            <replaceable>MACHINE</replaceable> set to "qemux86-64".
                             Assuming a standard
                             <ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink>,
                             <filename>runqemu</filename> automatically finds the
-                            <filename>bzImage-qemux86.bin</filename> image file and
+                            <filename>bzImage-qemux86-64.bin</filename> image file and
                             the
-                            <filename>core-image-minimal-qemux86-20140707074611.rootfs.ext3</filename>
+                            <filename>core-image-minimal-qemux86-64-20200218002850.rootfs.ext4</filename>
                             (assuming the current build created a
                             <filename>core-image-minimal</filename> image).
                             <note>
@@ -166,7 +166,7 @@
                             timestamp.
                             </note>
                             <literallayout class='monospaced'>
-     $ runqemu qemux86
+     $ runqemu qemux86-64
                             </literallayout>
                             </para></listitem>
                         <listitem><para>
@@ -175,7 +175,7 @@
                             This command, however, specifically provides the image
                             and root filesystem type.
                             <literallayout class='monospaced'>
-     $ runqemu qemux86 core-image-minimal ext3
+     $ runqemu qemux86-64 core-image-minimal ext4
                             </literallayout>
                             </para></listitem>
                         <listitem><para>
@@ -188,7 +188,7 @@
                             be installed (see the previous description for the
                             <filename>audio</filename> option for more information).
                             <literallayout class='monospaced'>
-     $ runqemu qemux86 ramfs audio
+     $ runqemu qemux86-64 ramfs audio
                             </literallayout>
                             </para></listitem>
                         <listitem><para>
@@ -200,7 +200,7 @@
                             <replaceable>KERNEL</replaceable>, or
                             <replaceable>VM</replaceable> option.
                             <literallayout class='monospaced'>
-     $ runqemu ext3
+     $ runqemu ext4
                             </literallayout>
                             </para></listitem>
                         <listitem><para>
@@ -209,9 +209,9 @@
                             From the <filename>.wic.vmdk</filename>,
                             <filename>runqemu</filename> determines the QEMU
                             architecture (<replaceable>MACHINE</replaceable>) to be
-                            "qemux86" and the root filesystem type to be "vmdk".
+                            "qemux86-64" and the root filesystem type to be "vmdk".
                             <literallayout class='monospaced'>
-     $ runqemu /home/scott-lenovo/vm/core-image-minimal-qemux86.wic.vmdk
+     $ runqemu /home/scott-lenovo/vm/core-image-minimal-qemux86-64.wic.vmdk
                             </literallayout>
                             </para></listitem>
                     </itemizedlist>
@@ -296,7 +296,7 @@
                     extracts it to a directory named
                     <filename>test-nfs</filename>:
                     <literallayout class='monospaced'>
-     runqemu-extract-sdk ./tmp/deploy/images/qemux86/core-image-sato-qemux86.tar.bz2 test-nfs
+     runqemu-extract-sdk ./tmp/deploy/images/qemux86-64/core-image-sato-qemux86-64.tar.bz2 test-nfs
                     </literallayout>
                     </para></listitem>
                 <listitem><para>
@@ -310,7 +310,7 @@
                     Here is an example using the <filename>qemux86</filename>
                     image:
                     <literallayout class='monospaced'>
-     runqemu qemux86 ./test-nfs
+     runqemu qemux86-64 ./test-nfs
                     </literallayout>
                     </para></listitem>
             </orderedlist>
diff --git a/poky/documentation/dev-manual/dev-manual-start.xml b/poky/documentation/dev-manual/dev-manual-start.xml
index 59ffa49bb..8cb5631f0 100644
--- a/poky/documentation/dev-manual/dev-manual-start.xml
+++ b/poky/documentation/dev-manual/dev-manual-start.xml
@@ -7,7 +7,7 @@
 <title>Setting Up to Use the Yocto Project</title>
 
 <para>
-    This chapter provides procedures related to getting set up to use the
+    This chapter provides guidance on how to prepare to use the
     Yocto Project.
     You can learn about creating a team environment that develops using the
     Yocto Project, how to set up a
@@ -24,9 +24,9 @@
         Project in a team development environment, or how to scale it for a
         large team of developers.
         You can adapt the Yocto Project to many different use cases and
-        scenarios.
-        However, this flexibility could cause difficulties if you are trying
-        to create a working setup that scales across a large team.
+        scenarios;
+        however, this flexibility could cause difficulties if you are trying
+        to create a working setup that scales effectively.
     </para>
 
     <para>
@@ -35,17 +35,17 @@
         that can help you get the results you want.
         The procedure is high-level and presents some of the project's most
         successful experiences, practices, solutions, and available
-        technologies that have proved to work well in the past.
-        Keep in mind, the procedure here is a starting point.
+        technologies that have proved to work well in the past;
+        however, keep in mind, the procedure here is simply a starting point.
         You can build off these steps and customize the procedure to fit any
         particular working environment and set of practices.
         <orderedlist>
             <listitem><para>
                 <emphasis>Determine Who is Going to be Developing:</emphasis>
-                You need to understand who is going to be doing anything
+                You first need to understand who is going to be doing anything
                 related to the Yocto Project and determine their roles.
                 Making this determination is essential to completing
-                steps two and three, which are to get your equipment together
+                subsequent steps, which are to get your equipment together
                 and set up your development environment's hardware topology.
                 </para>
 
@@ -64,8 +64,8 @@
                         <listitem><para>
                             <emphasis>Build Engineer:</emphasis>
                             This type of developer manages Autobuilders and
-                            releases.
-                            Not all environments need a Build Engineer.
+                            releases. Depending on the specifics of the environment,
+                            not all situations might need a Build Engineer.
                             </para></listitem>
                         <listitem><para>
                             <emphasis>Test Engineer:</emphasis>
@@ -88,6 +88,11 @@
                 You can help ensure efficiency by having any machines used
                 for testing or that run Autobuilders be as high performance
                 as possible.
+                <note>
+                    Given sufficient processing power, you might also consider
+                    building Yocto Project development containers to be run
+                    under Docker, which is described later.
+                </note>
                 </para></listitem>
             <listitem><para>
                 <emphasis>Understand the Hardware Topology of the Environment:</emphasis>
@@ -114,10 +119,10 @@
                 and any software you are developing under the control of an SCM
                 system that is compatible   with the OpenEmbedded build system
                 is advisable.
-                Of the SCMs BitBake supports, the Yocto Project team strongly
+                Of all of the SCMs supported by BitBake, the Yocto Project team strongly
                 recommends using
                 <ulink url='&YOCTO_DOCS_OM_URL;#git'>Git</ulink>.
-                Git is a distributed system that is easy to backup,
+                Git is a distributed system that is easy to back up,
                 allows you to work remotely, and then connects back to the
                 infrastructure.
                 <note>
@@ -302,7 +307,7 @@
                 <para>As with any development environment, it is important
                 to document the policy used as well as any main project
                 guidelines so they are understood by everyone.
-                It is also a good idea to have well structured
+                It is also a good idea to have well-structured
                 commit messages, which are usually a part of a project's
                 guidelines.
                 Good commit messages are essential when looking back in time and
@@ -394,16 +399,18 @@
         This section provides procedures to set up a system to be used as your
         <ulink url='&YOCTO_DOCS_REF_URL;#hardware-build-system-term'>build host</ulink>
         for development using the Yocto Project.
-        Your build host can be a native Linux machine (recommended) or it can
+        Your build host can be a native Linux machine (recommended), it can
         be a machine (Linux, Mac, or Windows) that uses
-        <ulink url='https://git.yoctoproject.org/cgit/cgit.cgi/crops/about/'>CROPS</ulink>,
+        <ulink url='https://github.com/crops/poky-container'>CROPS</ulink>,
         which leverages
-        <ulink url='https://www.docker.com/'>Docker Containers</ulink>.
+        <ulink url='https://www.docker.com/'>Docker Containers</ulink> or it can
+        be a Windows machine capable of running Windows Subsystem For Linux v2 (WSL).
         <note>
-            You cannot use a build host that is using the
-            <ulink url='https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux'>Windows Subsystem for Linux</ulink>
-            (WSL).
-            The Yocto Project is not compatible with WSL.
+          The Yocto Project is not compatible with
+          <ulink url='https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux'>Windows Subsystem for Linux v1</ulink>.
+          It is compatible but not officially supported nor validated with WSLv2.
+          If you still decide to use WSL please upgrade to
+          <ulink url='https://docs.microsoft.com/en-us/windows/wsl/wsl2-install'>WSLv2</ulink>.
         </note>
     </para>
 
@@ -442,7 +449,7 @@
                     You should have a reasonably current Linux-based host
                     system.
                     You will have the best results with a recent release of
-                    Fedora, openSUSE, Debian, Ubuntu, or CentOS as these
+                    Fedora, openSUSE, Debian, Ubuntu, RHEL or CentOS as these
                     releases are frequently tested against the Yocto Project
                     and officially supported.
                     For a list of the distributions under validation and their
@@ -460,23 +467,26 @@
                     <emphasis>Meet Minimal Version Requirements:</emphasis>
                     The OpenEmbedded build system should be able to run on any
                     modern distribution that has the following versions for
-                    Git, tar, and Python.
+                    Git, tar, Python and gcc.
                     <itemizedlist>
                         <listitem><para>
                             Git 1.8.3.1 or greater
                             </para></listitem>
                         <listitem><para>
-                            tar 1.27 or greater
+                            tar 1.28 or greater
                             </para></listitem>
                         <listitem><para>
-                            Python 3.4.0 or greater.
-                            </para></listitem>
+                            Python 3.5.0 or greater.
+                        </para></listitem>
+                        <listitem><para>
+                            gcc 5.0 or greater.
+                        </para></listitem>
                     </itemizedlist>
                     If your build host does not meet any of these three listed
                     version requirements, you can take steps to prepare the
                     system so that you can still use the Yocto Project.
                     See the
-                    "<ulink url='&YOCTO_DOCS_REF_URL;#required-git-tar-and-python-versions'>Required Git, tar, and Python Versions</ulink>"
+                    "<ulink url='&YOCTO_DOCS_REF_URL;#required-git-tar-python-and-gcc-versions'>Required Git, tar, Python and gcc Versions</ulink>"
                     section in the Yocto Project Reference Manual for
                     information.
                     </para></listitem>
@@ -517,7 +527,7 @@
 
         <para>
             With
-            <ulink url='https://github.com/crops/crops/blob/master/README.md'>CROPS</ulink>,
+            <ulink url='https://github.com/crops/poky-container'>CROPS</ulink>,
             which leverages
             <ulink url='https://www.docker.com/'>Docker Containers</ulink>,
             you can create a Yocto Project development environment that
@@ -654,15 +664,147 @@
             section in the Toaster User Manual.
         </para>
     </section>
+
+    <section id='setting-up-to-use-wsl'>
+        <title>Setting Up to Use Windows Subsystem For Linux (WSLv2)</title>
+
+        <para>
+            With <ulink url='https://docs.microsoft.com/en-us/windows/wsl/wsl2-about'>
+            Windows Subsystem for Linux (WSLv2)</ulink>, you can create a
+            Yocto Project development environment that allows you to build
+            on Windows. You can set up a Linux distribution inside Windows
+            in which you can develop using the Yocto Project.
+        </para>
+
+        <para>
+            Follow these general steps to prepare a Windows machine using WSLv2
+            as your Yocto Project build host:
+            <orderedlist>
+                <listitem><para>
+                    <emphasis>Make sure your Windows 10 machine is capable of running WSLv2:</emphasis>
+                  
+                    WSLv2 is only available for Windows 10 builds > 18917. To
+                    check which build version you are running, you may open a
+                    command prompt on Windows and execute the command "ver".
+                    <literallayout class='monospaced'>
+    C:\Users\myuser> ver
+
+    Microsoft Windows [Version 10.0.19041.153]
+                    </literallayout>
+                    If your build is capable of running WSLv2 you may continue,
+                    for more information on this subject or instructions on how
+                    to upgrade to WSLv2 visit <ulink url='https://docs.microsoft.com/en-us/windows/wsl/wsl2-install'>Windows 10 WSLv2</ulink>
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis>Install the Linux distribution of your choice inside Windows 10:</emphasis>
+                    Once you know your version of Windows 10 supports WSLv2,
+                    you can install the distribution of your choice from the
+                    Microsoft Store.
+                    Open the Microsoft Store and search for Linux. While there
+                    are several Linux distributions available, the assumption
+                    is that your pick will be one of the distributions supported
+                    by the Yocto Project as stated on the instructions for
+                    using a native Linux host.
+                    After making your selection, simply click "Get" to download
+                    and install the distribution.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis>Check your Linux distribution is using WSLv2:</emphasis>
+                    Open a Windows PowerShell and run:
+                    <literallayout class='monospaced'>
+    C:\WINDOWS\system32> wsl -l -v
+    NAME      STATE           VERSION
+    *Ubuntu    Running         2
+                    </literallayout>
+                    Note the version column which says the WSL version being used by
+                    your distribution, on compatible systems, this can be changed back
+                    at any point in time.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis>Optionally Orient Yourself on WSL:</emphasis>
+                    If you are unfamiliar with WSL, you can learn more here -
+                    <ulink url='https://docs.microsoft.com/en-us/windows/wsl/wsl2-about'></ulink>.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis>Launch your WSL Distibution:</emphasis>
+                    From the Windows start menu simply launch your WSL distribution
+                    just like any other application.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis>Optimize your WSLv2 storage often:</emphasis>
+                    Due to the way storage is handled on WSLv2, the storage
+                    space used by the undelying Linux distribution is not
+                    reflected immedately, and since bitbake heavily uses
+                    storage, after several builds, you may be unaware you
+                    are running out of space. WSLv2 uses a VHDX file for
+                    storage, this issue can be easily avoided by manually
+                    optimizing this file often, this can be done in the
+                    following way:
+                    <orderedlist>
+                        <listitem><para>
+                            <emphasis>Find the location of your VHDX file:</emphasis>
+                            First you need to find the distro app package directory,
+                            to achieve this open a Windows Powershell as Administrator
+                            and run:
+                            <literallayout class='monospaced'>
+    C:\WINDOWS\system32> Get-AppxPackage -Name "*Ubuntu*" | Select PackageFamilyName
+    PackageFamilyName
+    -----------------
+    CanonicalGroupLimited.UbuntuonWindows_79abcdefgh
+                            </literallayout>
+                            You should now replace the <replaceable>PackageFamilyName</replaceable>
+                            and your <replaceable>user</replaceable> on the following
+                            path to find your VHDX file: <filename>C:\Users\user\AppData\Local\Packages\PackageFamilyName\LocalState\</filename>
+                            For example:
+                            <literallayout class='monospaced'>
+    ls C:\Users\myuser\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79abcdefgh\LocalState\
+    Mode                 LastWriteTime         Length Name
+    -a----         3/14/2020   9:52 PM    57418973184 ext4.vhdx                      
+                            </literallayout>
+                            Your VHDX file path is: <filename>C:\Users\myuser\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79abcdefgh\LocalState\ext4.vhdx</filename>
+                            </para></listitem>
+                        <listitem><para><emphasis>Optimize your VHDX file:</emphasis>
+                            Open a Windows Powershell as Administrator to optimize
+                            your VHDX file, shutting down WSL first:
+                            <literallayout class='monospaced'>
+    C:\WINDOWS\system32> wsl --shutdown
+    C:\WINDOWS\system32> optimize-vhd -Path C:\Users\myuser\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79abcdefgh\LocalState\ext4.vhdx -Mode full
+                            </literallayout>
+                            A progress bar should be shown while optimizing the VHDX file,
+                            and storage should now be reflected correctly on the Windows
+                            Explorer.
+                            </para></listitem>
+                    </orderedlist>
+                </para></listitem>
+            </orderedlist>
+            <note>
+              The current implementation of WSLv2 does not have out-of-the-box
+              access to external devices such as those connected through a
+              USB port, but it automatically mounts your <filename>C:</filename>
+              drive on <filename>/mnt/c/</filename> (and others), which
+              you can use to share deploy artifacts to be later flashed on
+              hardware through Windows, but your build directory should not
+              reside inside this mountpoint.
+            </note>
+            Once you have WSLv2 set up, everything is in place to
+            develop just as if you were running on a native Linux machine.
+            If you are going to use the Extensible SDK container, see the
+            "<ulink url='&YOCTO_DOCS_SDK_URL;#sdk-extensible'>Using the Extensible SDK</ulink>"
+            Chapter in the Yocto Project Application Development and the
+            Extensible Software Development Kit (eSDK) manual.
+            If you are going to use the Toaster container, see the
+            "<ulink url='&YOCTO_DOCS_TOAST_URL;#toaster-manual-setup-and-use'>Setting Up and Using Toaster</ulink>"
+            section in the Toaster User Manual.
+        </para>
+    </section>
 </section>
 
 <section id='locating-yocto-project-source-files'>
     <title>Locating Yocto Project Source Files</title>
 
     <para>
-        This section shows you how to locate and access the
-        source files that ship with the Yocto Project.
-        You establish and use these local files to work on projects.
+        This section shows you how to locate, fetch and configure the source
+        files you'll need to work with the Yocto Project.
         <note><title>Notes</title>
             <itemizedlist>
                 <listitem><para>
@@ -1019,20 +1161,18 @@
            .
            .
            .
-       remotes/origin/pyro
-       remotes/origin/pyro-next
-       remotes/origin/rocko
-       remotes/origin/rocko-next
-       remotes/origin/sumo
-       remotes/origin/sumo-next
        remotes/origin/thud
        remotes/origin/thud-next
        remotes/origin/warrior
+       remotes/origin/warrior-next
+       remotes/origin/zeus
+       remotes/origin/zeus-next
+       ... and so on ...
                     </literallayout>
                     </para></listitem>
                 <listitem><para>
-                    <emphasis>Checkout the Branch:</emphasis>
-                    Checkout the development branch in which you want to work.
+                    <emphasis>Check out the Branch:</emphasis>
+                    Check out the development branch in which you want to work.
                     For example, to access the files for the Yocto Project
                     &DISTRO; Release (&DISTRO_NAME;), use the following command:
                     <literallayout class='monospaced'>
@@ -1118,7 +1258,7 @@
                     </literallayout>
                     </para></listitem>
                 <listitem><para>
-                    <emphasis>Checkout the Branch:</emphasis>
+                    <emphasis>Check out the Branch:</emphasis>
                     <literallayout class='monospaced'>
      $ git checkout tags/&DISTRO_REL_TAG; -b my_yocto_&DISTRO;
      Switched to a new branch 'my_yocto_&DISTRO;'
diff --git a/poky/documentation/dev-manual/dev-manual.xml b/poky/documentation/dev-manual/dev-manual.xml
index 04fa1e4f9..6f86454ed 100644..100755
--- a/poky/documentation/dev-manual/dev-manual.xml
+++ b/poky/documentation/dev-manual/dev-manual.xml
@@ -22,18 +22,17 @@
 
         <authorgroup>
             <author>
-                <firstname>Scott</firstname> <surname>Rifenbark</surname>
                 <affiliation>
-                    <orgname>Scotty's Documentation Services, INC</orgname>
+                    <orgname>&ORGNAME;</orgname>
                 </affiliation>
-                <email>srifenbark@gmail.com</email>
+                <email>&ORGEMAIL;</email>
             </author>
         </authorgroup>
 
         <revhistory>
             <revision>
                 <revnumber>1.1</revnumber>
-                <date>6 October 2011</date>
+                <date>October 2011</date>
                 <revremark>The initial document released with the Yocto Project 1.1 Release.</revremark>
             </revision>
             <revision>
@@ -57,11 +56,6 @@
                 <revremark>Released with the Yocto Project 1.5 Release.</revremark>
             </revision>
             <revision>
-                <revnumber>1.5.1</revnumber>
-                <date>January 2014</date>
-                <revremark>Released with the Yocto Project 1.5.1 Release.</revremark>
-            </revision>
-            <revision>
                 <revnumber>1.6</revnumber>
                 <date>April 2014</date>
                 <revremark>Released with the Yocto Project 1.6 Release.</revremark>
@@ -118,9 +112,14 @@
             </revision>
             <revision>
                 <revnumber>3.0</revnumber>
-                <date>&REL_MONTH_YEAR;</date>
+                <date>October 2019</date>
                 <revremark>Released with the Yocto Project 3.0 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>3.1</revnumber>
+                <date>&REL_MONTH_YEAR;</date>
+                <revremark>Released with the Yocto Project 3.1 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>
@@ -144,7 +143,7 @@
                        Yocto Project.
                        To be sure you have the latest version of the manual
                        for this release, go to the
-                       <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink>
+                       <ulink url='&YOCTO_DOCS_URL;'>Yocto Project documentation page</ulink>
                        and select the manual from that site.
                        Manuals from the site are more up-to-date than manuals
                        derived from the Yocto Project released TAR files.
@@ -161,18 +160,20 @@
                        page.
                        If you need a version of this manual for a different
                        Yocto Project release, visit the
-                       <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink>
+                       <ulink url='&YOCTO_DOCS_URL;'>Yocto Project documentation page</ulink>
                        and select the manual set by using the
                        "ACTIVE RELEASES DOCUMENTATION" or "DOCUMENTS ARCHIVE"
                        pull-down menus.
                        </para></listitem>
-                   <listitem><para>
+                   <listitem>
+                       <para>
                        To report any inaccuracies or problems with this
-                       manual, send an email to the Yocto Project
-                       discussion group at
-                       <filename>yocto@yoctoproject.com</filename> or log into
-                       the freenode <filename>#yocto</filename> channel.
-                       </para></listitem>
+                       (or any other Yocto Project) manual, send an email to
+                       the Yocto Project documentation mailing list at
+                       <filename>docs@lists.yoctoproject.org</filename> or
+                       log into the freenode <filename>#yocto</filename> channel.
+                       </para>
+                   </listitem>
                </itemizedlist>
            </note>
     </legalnotice>