build-applance-image: Fix to use the release branch for morty

(From OE-Core rev: 2a59d0fa7bda78927435603e3049ce373cf6a198)

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

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

@@ -3621,6 +3621,106 @@
         </section>
     </section>
 
+    <section id='platdev-building-targets-with-multiple-configurations'>
+        <title>Building Targets with Multiple Configurations</title>
+
+        <para>
+            Bitbake also has functionality that allows you to build
+            multiple targets at the same time, where each target uses
+            a different configuration.
+        </para>
+
+        <para>
+            In order to accomplish this, you setup each of the configurations
+            you need to use in parallel by placing the configuration files in
+            your current build directory alongside the usual
+            <filename>local.conf</filename> file.
+        </para>
+
+        <para>
+            Follow these guidelines to create an environment that supports
+            multiple configurations:
+            <itemizedlist>
+                <listitem><para>
+                    <emphasis>Create Configuration Files</emphasis>:
+                    You need to create a single configuration file for each
+                    configuration for which you want to add support.
+                    These files would contain lines such as the following:
+                    <literallayout class='monospaced'>
+     MACHINE = "A"
+                    </literallayout>
+                    The files would contain any other variables that can
+                    be set and built in the same directory.
+                    <note>
+                        You can change the
+                        <ulink url='&YOCTO_DOCS_REF_URL;#var-TMPDIR'><filename>TMPDIR</filename></ulink>
+                        to not conflict.
+                    </note></para>
+
+                    <para>
+                    Furthermore, the configuration file must be located in the
+                    current build directory in a directory named
+                    <filename>multiconfig</filename> under the build's
+                    <filename>conf</filename> directory where
+                    <filename>local.conf</filename> resides.
+                    The reason for this restriction is because the
+                    <filename>BBPATH</filename> variable is not constructed
+                    until the layers are parsed.
+                    Consequently, using the configuration file as a
+                    pre-configuration file is not possible unless it is
+                    located in the current working directory.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis>Add the BitBake Multi-Config Variable to you Local Configuration File</emphasis>:
+                    Use the
+                    <filename>BBMULTICONFIG</filename>
+                    variable in your <filename>conf/local.conf</filename>
+                    configuration file to specify each separate configuration.
+                    For example, the following line tells BitBake it should load
+                    <filename>conf/multiconfig/configA.conf</filename>,
+                    <filename>conf/multiconfig/configB.conf</filename>, and
+                    <filename>conf/multiconfig/configC.conf</filename>.
+                    <literallayout class='monospaced'>
+     BBMULTICONFIG = "configA configB configC"
+                    </literallayout>
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis>Launch BitBake</emphasis>:
+                    Use the following BitBake command form to launch the
+                    build:
+                    <literallayout class='monospaced'>
+     $ bitbake [multiconfig:<replaceable>multiconfigname</replaceable>:]<replaceable>target</replaceable> [[[multiconfig:<replaceable>multiconfigname</replaceable>:]<replaceable>target</replaceable>] ... ]
+                    </literallayout>
+                    Following is an example that supports building a minimal
+                    image for configuration A alongside a standard
+                    <filename>core-image-sato</filename>, which takes its
+                    configuration from <filename>local.conf</filename>:
+                    <literallayout class='monospaced'>
+     $ bitbake multiconfig:configA:core-image-minimal core-image-sato
+                    </literallayout>
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+
+        <para>
+            Support for multiple configurations in this current release of
+            the Yocto Project (&DISTRO_NAME; &DISTRO;) has some known issues:
+            <itemizedlist>
+                <listitem><para>
+                    No inter-multi-configuration dependencies exist.
+                    </para></listitem>
+                <listitem><para>
+                    Shared State (sstate) optimizations do not exist.
+                    Consequently, if the build uses the same object twice
+                    in, for example, two different
+                    <filename>TMPDIR</filename> directories, the build
+                    will either load from an existing sstate cache at the
+                    start or build the object twice.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
     <section id="platdev-working-with-libraries">
         <title>Working With Libraries</title>
 

documentation/ref-manual/introduction.xml

@@ -257,12 +257,6 @@
                         <literallayout class='monospaced'>
      $ sudo apt-get install make xsltproc docbook-utils fop dblatex xmlto
                         </literallayout></para></listitem>
-                    <listitem><para><emphasis>SDK Installer Extras:</emphasis>
-                        Packages needed if you are going to be using the
-                        the standard or extensible SDK:
-                        <literallayout class='monospaced'>
-     $ sudo apt-get install autoconf automake libtool libglib2.0-dev libarchive-dev
-                        </literallayout></para></listitem>
                     <listitem><para><emphasis>OpenEmbedded Self-Test (<filename>oe-selftest</filename>):</emphasis>
                         Packages needed if you are going to run
                         <filename>oe-selftest</filename>:
@@ -301,12 +295,6 @@
      $ sudo dnf install make docbook-style-dsssl docbook-style-xsl \
      docbook-dtds docbook-utils fop libxslt dblatex xmlto xsltproc
                         </literallayout></para></listitem>
-                    <listitem><para><emphasis>SDK Installer Extras:</emphasis>
-                        Packages needed if you are going to be using the
-                        standard or extensible SDK:
-                        <literallayout class='monospaced'>
-     $ sudo dnf install autoconf automake libtool glib2-devel libarchive-devel
-                        </literallayout></para></listitem>
                     <listitem><para><emphasis>OpenEmbedded Self-Test (<filename>oe-selftest</filename>):</emphasis>
                         Packages needed if you are going to run
                         <filename>oe-selftest</filename>:
@@ -344,12 +332,6 @@
                         <literallayout class='monospaced'>
      $ sudo zypper install make fop xsltproc dblatex xmlto
                         </literallayout></para></listitem>
-                    <listitem><para><emphasis>SDK Installer Extras:</emphasis>
-                        Packages needed if you are going to be using the
-                        standard or extensible SDK:
-                        <literallayout class='monospaced'>
-     $ sudo zypper install autoconf automake libtool glib2-devel libarchive-devel
-                        </literallayout></para></listitem>
                     <listitem><para><emphasis>OpenEmbedded Self-Test (<filename>oe-selftest</filename>):</emphasis>
                         Packages needed if you are going to run
                         <filename>oe-selftest</filename>:
@@ -399,12 +381,6 @@
      $ sudo yum install make docbook-style-dsssl docbook-style-xsl \
      docbook-dtds docbook-utils fop libxslt dblatex xmlto xsltproc
                         </literallayout></para></listitem>
-                    <listitem><para><emphasis>SDK Installer Extras:</emphasis>
-                        Packages needed if you are going to be using the
-                        standard or extensible SDK:
-                        <literallayout class='monospaced'>
-     $ sudo yum install autoconf automake libtool glib2-devel libarchive-devel
-                        </literallayout></para></listitem>
                     <listitem><para><emphasis>OpenEmbedded Self-Test (<filename>oe-selftest</filename>):</emphasis>
                         Packages needed if you are going to run
                         <filename>oe-selftest</filename>:

documentation/ref-manual/migration.xml

@@ -3392,10 +3392,6 @@
 
         <para>
             The following changes for Python occurred:
-            <note>
-                Python 2 and recipes that use it can still be built for the
-                target as with previous versions.
-            </note>
         </para>
 
         <section id='migration-2.2-bitbake-now-requires-python-3.4'>
@@ -3443,6 +3439,10 @@
                 Unfortunately, systems using RPM as a package manager and
                 providing online package-manager support through SMART still
                 require Python 2.
+                <note>
+                    Python 2 and recipes that use it can still be built for the
+                    target as with previous versions.
+                </note>
             </para>
         </section>
 
@@ -3489,23 +3489,26 @@
         <para>
             <filename>runqemu</filename> has been ported to Python and has
             changed behavior in some cases.
+            Previous usage patterns continued to be supported.
         </para>
 
         <para>
             The new <filename>runqemu</filename> is a Python script.
-            The script requires a configuration file in the following
-            form in order to boot the BSP:
+            Machine knowledge is no longer hardcoded into
+            <filename>runqemu</filename>.
+            You can choose to use the <filename>qemuboot</filename>
+            configuration file to define the BSP's own arguments and to make
+            it bootable with <filename>runqemu</filename>.
+            If you use a configuration file, use the following form:
             <literallayout class='monospaced'>
      <replaceable>image-name</replaceable>-<replaceable>machine</replaceable>.qemuboot.conf
             </literallayout>
-            Machine knowledge is no longer hardcoded into
-            <filename>runqemu</filename>.
-            You can use the <filename>qemuboot</filename> configuration file
-            to define the BSP's own arguments and to make it bootable
-            with <filename>runqemu</filename>.
-            <note>
-                Previous usage patterns are continued to be supported.
-            </note>
+            The configuration file enables fine-grained tuning of options
+            passed to QEMU without the <filename>runqemu</filename> script
+            hard-coding any knowledge about different machines.
+            Using a configuration file is particularly convenient when trying
+            to use QEMU with machines other than the
+            <filename>qemu*</filename> machines in OE-Core.
             The <filename>qemuboot.conf</filename> file is generated by the
             <filename>qemuboot</filename>
             class when the root filesystem is being build (i.e.
@@ -3515,6 +3518,34 @@
             <filename>qemuboot.conf</filename>.
         </para>
 
+
+        <para>
+            If you want to use <filename>runqemu</filename> without a
+            configuration file, use the following command form:
+            <literallayout class='monospaced'>
+     $ runqemu <replaceable>machine</replaceable> <replaceable>rootfs</replaceable> <replaceable>kernel</replaceable> [<replaceable>options</replaceable>]
+            </literallayout>
+            Supported <replaceable>machines</replaceable> are as follows:
+            <literallayout class='monospaced'>
+     qemuarm
+     qemuarm64
+     qemux86
+     qemux86-64
+     qemuppc
+     qemumips
+     qemumips64
+     qemumipsel
+     qemumips64el
+            </literallayout>
+            Consider the following example, which uses the
+            <filename>qemux86-64</filename> machine,
+            provides a root filesystem, provides an image, and uses
+            the <filename>nographic</filename> option:
+            <literallayout class='monospaced'>
+$ runqemu qemux86-64 tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.ext4 tmp/deploy/images/qemux86-64/bzImage nographic
+            </literallayout>
+        </para>
+
         <para>
             Following is a list of variables that can be set in configuration
             files such as <filename>bsp.conf</filename> to enable the BSP
@@ -3579,8 +3610,8 @@
             binary" QA issues when building such recipes.
             You need to fix these recipes so that they use the expected
             <filename>LDFLAGS</filename>.
-            Depending on how the software is built, the build system might
-            need to be patched.
+            Depending on how the software is built, the build system used by
+            the software (e.g. a Makefile) might need to be patched.
             However, sometimes making this fix is as simple as adding the
             following to the recipe:
             <literallayout class='monospaced'>

documentation/ref-manual/ref-variables.xml

@@ -1225,6 +1225,42 @@
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-BBMULTICONFIG'><glossterm>BBMULTICONFIG</glossterm>
+            <info>
+                BBMULTICONFIG[doc] = "Specifies each separate configuration when you are building targets with multiple configurations."
+            </info>
+            <glossdef>
+                <para role="glossdeffirst">
+<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+                    Specifies each separate configuration when you are
+                    building targets with multiple configurations.
+                    Use this variable in your
+                    <filename>conf/local.conf</filename> configuration file.
+                    Specify a <replaceable>multiconfigname</replaceable> for
+                    each configuration file you are using.
+                    For example, the following line specifies three
+                    configuration files:
+                    <literallayout class='monospaced'>
+     BBMULTIFONFIG = "configA configB configC"
+                    </literallayout>
+                    Each configuration file you use must reside in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory's</ulink>
+                    <filename>conf/multiconfig</filename> directory
+                    (e.g.
+                    <replaceable>build_directory</replaceable><filename>/conf/multiconfig/configA.conf</filename>).
+                </para>
+
+                <para>
+                    For information on how to use
+                    <filename>BBMULTICONFIG</filename> in an environment that
+                    supports building targets with multiple configurations,
+                    see the
+                    "<ulink url='&YOCTO_DOCS_DEV_URL;#platdev-building-targets-with-multiple-configurations'>Building Targets with Multiple Configurations</ulink>"
+                    section in the Yocto Project Development Manual.
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-BBPATH'><glossterm>BBPATH</glossterm>
             <info>
                 BBPATH[doc] = "Used by BitBake to locate .bbclass and configuration files. This variable is analogous to the PATH variable."

documentation/yocto-project-qs/yocto-project-qs.xml

@@ -390,8 +390,8 @@
         </para>
 
         <para>
-            You can try out the Yocto Project using the command-line interface
-            by finishing this quick start, which presents steps that let you
+            To use the Yocto Project through the command-line interface,
+            finish this quick start, which presents steps that let you
             do the following:
             <itemizedlist>
                 <listitem><para>
@@ -400,19 +400,24 @@
                     </para></listitem>
                 <listitem><para>
                     Easily change configurations so that you can quickly
-                    create a second image, which would be for MinnowBoard
+                    create a second image that you can load onto bootable
+                    media and actually boot target hardware.
+                    This example uses the MinnowBoard
                     MAX-compatible boards.
                     </para></listitem>
             </itemizedlist>
             <note>
-                The steps in this section do not provide detail, but rather
-                provide minimal, working commands and examples designed to
-                just get you started.
+                The steps in the following two sections do not provide detail,
+                but rather provide minimal, working commands and examples
+                designed to just get you started.
                 For more details, see the appropriate manuals in the
                 <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project manual set</ulink>.
             </note>
         </para>
 
+        <section id='building-an-image-for-emulation'>
+            <title>Building an Image for Emulation</title>
+
             <para>
                 Use the following commands to build your image.
                 The OpenEmbedded build system creates an entire Linux
@@ -596,6 +601,10 @@
                         </para></listitem>
                 </orderedlist>
             </para>
+        </section>
+
+        <section id='building-an-image-for-hardware'>
+            <title>Building an Image for Hardware</title>
 
             <para id='qs-minnowboard-example'>
                 The following steps show how easy it is to set up to build an
@@ -722,23 +731,18 @@
                         </literallayout>
                         </para></listitem>
                     <listitem><para><emphasis>Write the Image:</emphasis>
-                    You can write the image to a USB key, SATA drive, or SD
-                    card by using the <filename>mkefidisk.sh</filename> script,
-                    which is included in the <filename>poky</filename>
-                    repository at
-                    <filename>scripts/contrib/mkefidisk.sh</filename>:
+                        You can write the image just built to a bootable media
+                        (e.g. a USB key, SATA drive, SD card, etc.) using the
+                        <filename>dd</filename> utility:
                         <literallayout class='monospaced'>
-     $ sudo $HOME/source/poky/scripts/contrib/mkefidisk.sh <replaceable>HOST_DEVICE</replaceable> \
-        tmp/deploy/images/intel-corei7-64/core-image-base-intel-corei7-64.hddimg <replaceable>TARGET_DEVICE</replaceable>
+     $ sudo dd if=tmp/deploy/images/intel-corei7-64/core-image-minimal-intel-corei7-64.wic of=TARGET_DEVICE
                         </literallayout>
-                    In the previous command,
-                    <replaceable>HOST_DEVICE</replaceable> is the device node
-                    on the build host (e.g. <filename>/dev/sdc</filename> or
-                    <filename>/dev/mmcblk0</filename>).
-                    <replaceable>TARGET_DEVICE</replaceable> is the name of the
-                    device as the MinnowBoard MAX sees it (e.g.
-                    <filename>/dev/sda</filename> or
-                    <filename>/dev/mmcblk0</filename>).
+                        In the previous command, the
+                        <filename>TARGET_DEVICE</filename> is the device node in
+                        the host machine (e.g. <filename>/dev/sdc</filename>, which
+                        is most likely a USB stick, or
+                        <filename>/dev/mmcblk0</filename>, which is most likely an
+                        SD card.
                         </para></listitem>
                     <listitem><para><emphasis>Boot the Hardware:</emphasis>
                         With the boot device provisioned, you can insert the
@@ -765,6 +769,7 @@
                 </orderedlist>
             </para>
         </section>
+    </section>
 
     <section id='qs-next-steps'>
         <title>Next Steps</title>

meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.1.bbappend

@@ -7,11 +7,11 @@ KBRANCH_mpc8315e-rdb = "standard/fsl-mpc8315e-rdb"
 KMACHINE_genericx86 ?= "common-pc"
 KMACHINE_genericx86-64 ?= "common-pc-64"
 
-SRCREV_machine_genericx86    ?= "a38cb202738a2b055ac216b3699cc9377edea45a"
-SRCREV_machine_genericx86-64 ?= "a38cb202738a2b055ac216b3699cc9377edea45a"
-SRCREV_machine_edgerouter ?= "a38cb202738a2b055ac216b3699cc9377edea45a"
-SRCREV_machine_beaglebone ?= "3e064525c427e128d08ea599ea3247e2963b54a5"
-SRCREV_machine_mpc8315e-rdb ?= "a38cb202738a2b055ac216b3699cc9377edea45a"
+SRCREV_machine_genericx86    ?= "f4d0900b2851e829e990e0f64b09ed3b8e355fae"
+SRCREV_machine_genericx86-64 ?= "f4d0900b2851e829e990e0f64b09ed3b8e355fae"
+SRCREV_machine_edgerouter ?= "f4d0900b2851e829e990e0f64b09ed3b8e355fae"
+SRCREV_machine_beaglebone ?= "12532e753b50997690923e03edb3ac3368817a26"
+SRCREV_machine_mpc8315e-rdb ?= "f4d0900b2851e829e990e0f64b09ed3b8e355fae"
 
 COMPATIBLE_MACHINE_genericx86 = "genericx86"
 COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64"

meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.4.bbappend

@@ -7,11 +7,11 @@ KBRANCH_edgerouter = "standard/edgerouter"
 KBRANCH_beaglebone = "standard/beaglebone"
 KBRANCH_mpc8315e-rdb = "standard/fsl-mpc8315e-rdb"
 
-SRCREV_machine_genericx86    ?= "f4e52341c304e044dbe581a35aad6b930c9410d1"
-SRCREV_machine_genericx86-64 ?= "f4e52341c304e044dbe581a35aad6b930c9410d1"
-SRCREV_machine_edgerouter ?= "f4e52341c304e044dbe581a35aad6b930c9410d1"
-SRCREV_machine_beaglebone ?= "f4e52341c304e044dbe581a35aad6b930c9410d1"
-SRCREV_machine_mpc8315e-rdb ?= "50e000bc5fce1e04a1a3aea5ffc57c3d5fd71e72"
+SRCREV_machine_genericx86    ?= "ca6a08bd7f86ebef11f763d26f787f7d65270473"
+SRCREV_machine_genericx86-64 ?= "ca6a08bd7f86ebef11f763d26f787f7d65270473"
+SRCREV_machine_edgerouter ?= "ca6a08bd7f86ebef11f763d26f787f7d65270473"
+SRCREV_machine_beaglebone ?= "ca6a08bd7f86ebef11f763d26f787f7d65270473"
+SRCREV_machine_mpc8315e-rdb ?= "7fa42ad9a43ca4bb1e578e208ffeddae2d6150e2"
 
 COMPATIBLE_MACHINE_genericx86 = "genericx86"
 COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64"
@@ -19,8 +19,8 @@ COMPATIBLE_MACHINE_edgerouter = "edgerouter"
 COMPATIBLE_MACHINE_beaglebone = "beaglebone"
 COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb"
 
-LINUX_VERSION_genericx86 = "4.4.22"
-LINUX_VERSION_genericx86-64 = "4.4.22"
-LINUX_VERSION_edgerouter = "4.4.22"
-LINUX_VERSION_beaglebone = "4.4.22"
-LINUX_VERSION_mpc8315e-rdb = "4.4.22"
+LINUX_VERSION_genericx86 = "4.4.26"
+LINUX_VERSION_genericx86-64 = "4.4.26"
+LINUX_VERSION_edgerouter = "4.4.26"
+LINUX_VERSION_beaglebone = "4.4.26"
+LINUX_VERSION_mpc8315e-rdb = "4.4.26"

meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.8.bbappend

@@ -7,11 +7,11 @@ KBRANCH_edgerouter = "standard/edgerouter"
 KBRANCH_beaglebone = "standard/beaglebone"
 KBRANCH_mpc8315e-rdb = "standard/fsl-mpc8315e-rdb"
 
-SRCREV_machine_genericx86    ?= "67813e7efa3a4614e209c2f058d92ef9a636441a"
-SRCREV_machine_genericx86-64 ?= "67813e7efa3a4614e209c2f058d92ef9a636441a"
-SRCREV_machine_edgerouter ?= "67813e7efa3a4614e209c2f058d92ef9a636441a"
-SRCREV_machine_beaglebone ?= "67813e7efa3a4614e209c2f058d92ef9a636441a"
-SRCREV_machine_mpc8315e-rdb ?= "4c9e17100b1f8ce45a60ad8984c12b00febbc685"
+SRCREV_machine_genericx86    ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
+SRCREV_machine_genericx86-64 ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
+SRCREV_machine_edgerouter ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
+SRCREV_machine_beaglebone ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
+SRCREV_machine_mpc8315e-rdb ?= "4be88b03f6648004e74b68044fa2b05e81cf9a1b"
 
 COMPATIBLE_MACHINE_genericx86 = "genericx86"
 COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64"
@@ -19,8 +19,8 @@ COMPATIBLE_MACHINE_edgerouter = "edgerouter"
 COMPATIBLE_MACHINE_beaglebone = "beaglebone"
 COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb"
 
-LINUX_VERSION_genericx86 = "4.8"
-LINUX_VERSION_genericx86-64 = "4.8"
-LINUX_VERSION_edgerouter = "4.8"
-LINUX_VERSION_beaglebone = "4.8"
-LINUX_VERSION_mpc8315e-rdb = "4.8"
+LINUX_VERSION_genericx86 = "4.8.3"
+LINUX_VERSION_genericx86-64 = "4.8.3"
+LINUX_VERSION_edgerouter = "4.8.3"
+LINUX_VERSION_beaglebone = "4.8.3"
+LINUX_VERSION_mpc8315e-rdb = "4.8.3"

meta/classes/image_types.bbclass

@@ -184,7 +184,7 @@ IMAGE_CMD_ubi () {
 
 IMAGE_CMD_ubifs = "mkfs.ubifs -r ${IMAGE_ROOTFS} -o ${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.ubifs ${MKUBIFS_ARGS}"
 
-WKS_FILE ?= "${IMAGE_BASENAME}.${MACHINE}.wks"
+WKS_FILE ??= "${IMAGE_BASENAME}.${MACHINE}.wks"
 WKS_FILES ?= "${WKS_FILE} ${IMAGE_BASENAME}.wks"
 WKS_SEARCH_PATH ?= "${THISDIR}:${@':'.join('%s/scripts/lib/wic/canned-wks' % l for l in '${BBPATH}:${COREBASE}'.split(':'))}"
 WKS_FULL_PATH = "${@wks_search('${WKS_FILES}'.split(), '${WKS_SEARCH_PATH}') or ''}"

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

@@ -22,8 +22,8 @@ IMAGE_FSTYPES = "vmdk"
 
 inherit core-image module-base
 
-SRCREV ?= "4b94b498e21aeba945fe7e72a6b7c4bb0314fb83"
-SRC_URI = "git://git.yoctoproject.org/poky;branch=master \
+SRCREV ?= "746c681be4c744d0c6c2d3225b94550241546f65"
+SRC_URI = "git://git.yoctoproject.org/poky;branch=morty \
            file://Yocto_Build_Appliance.vmx \
            file://Yocto_Build_Appliance.vmxf \
            file://README_VirtualBox_Guest_Additions.txt \

meta/recipes-kernel/linux/linux-yocto-rt_4.8.bb

@@ -11,8 +11,8 @@ python () {
         raise bb.parse.SkipPackage("Set PREFERRED_PROVIDER_virtual/kernel to linux-yocto-rt to enable it")
 }
 
-SRCREV_machine ?= "320bceb35315d118c1e209effd441eb8a8dbad57"
-SRCREV_meta ?= "6d028d2818603cd82cfb707b3231b8a9038f13bb"
+SRCREV_machine ?= "4057556c041f6aac0d29aa3425587d414c9a0090"
+SRCREV_meta ?= "83110d94edeb856a3667b62903ed4ae91c24117d"
 
 SRC_URI = "git://git.yoctoproject.org/linux-yocto-4.8.git;branch=${KBRANCH};name=machine \
            git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.8;destsuffix=${KMETA}"

meta/recipes-kernel/linux/linux-yocto-tiny_4.8.bb

@@ -10,7 +10,7 @@ KMETA = "kernel-meta"
 KCONF_BSP_AUDIT_LEVEL = "2"
 
 SRCREV_machine ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
-SRCREV_meta ?= "6d028d2818603cd82cfb707b3231b8a9038f13bb"
+SRCREV_meta ?= "83110d94edeb856a3667b62903ed4ae91c24117d"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 

meta/recipes-kernel/linux/linux-yocto_4.8.bb

@@ -19,7 +19,7 @@ SRCREV_machine_qemux86 ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
 SRCREV_machine_qemux86-64 ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
 SRCREV_machine_qemumips64 ?= "64f96ba530e58456070f26b0f3fcce3f64988b72"
 SRCREV_machine ?= "1adf9d36338dc3c63cdbf6f98bcbdc7bba42a794"
-SRCREV_meta ?= "6d028d2818603cd82cfb707b3231b8a9038f13bb"
+SRCREV_meta ?= "83110d94edeb856a3667b62903ed4ae91c24117d"
 
 SRC_URI = "git://git.yoctoproject.org/linux-yocto-4.8.git;name=machine;branch=${KBRANCH}; \
            git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.8;destsuffix=${KMETA}"

scripts/lib/devtool/runqemu.py

@@ -48,7 +48,12 @@ def runqemu(args, config, basepath, workspace):
         raise DevtoolError('Unable to determine image name to run, please specify one')
 
     try:
-        exec_build_env_command(config.init_path, basepath, 'runqemu %s %s %s' % (machine, imagename, " ".join(args.args)), watch=True)
+        # FIXME runqemu assumes that if OECORE_NATIVE_SYSROOT is set then it shouldn't
+        # run bitbake to find out the values of various environment variables, which
+        # isn't the case for the extensible SDK. Work around it for now.
+        newenv = dict(os.environ)
+        newenv.pop('OECORE_NATIVE_SYSROOT', '')
+        exec_build_env_command(config.init_path, basepath, 'runqemu %s %s %s' % (machine, imagename, " ".join(args.args)), watch=True, env=newenv)
     except bb.process.ExecutionError as e:
         # We've already seen the output since watch=True, so just ensure we return something to the user
         return e.exitcode