systemd-boot: upgrade to 239

Upgrade systemd-boot to 239.

The following patch is removed due to recent fix about meson's cpu family
mapping and validation.

  0001-Also-check-i386-i586-and-i686-for-ia32.patch

(From OE-Core rev: ff0b682b807959521c85716296de7a1d26d7d18f)

Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

bitbake/doc/bitbake-user-manual/bitbake-user-manual-metadata.xml

@@ -1929,6 +1929,38 @@
                         not careful.
                     </note>
                     </para></listitem>
+                <listitem><para><emphasis><filename>[number_threads]</filename>:</emphasis>
+                    Limits tasks to a specific number of simultaneous threads
+                    during execution.
+                    This varflag is useful when your build host has a large number
+                    of cores but certain tasks need to be rate-limited due to various
+                    kinds of resource constraints (e.g. to avoid network throttling).
+                    <filename>number_threads</filename> works similarly to the
+                    <link linkend='var-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename></link>
+                    variable but is task-specific.</para>
+
+                    <para>Set the value globally.
+                    For example, the following makes sure the
+                    <filename>do_fetch</filename> task uses no more than two
+                    simultaneous execution threads:
+                    <literallayout class='monospaced'>
+     do_fetch[number_threads] = "2"
+                    </literallayout>
+                    <note><title>Warnings</title>
+                        <itemizedlist>
+                            <listitem><para>
+                                Setting the varflag in individual recipes rather
+                                than globally can result in unpredictable behavior.
+                                </para></listitem>
+                            <listitem><para>
+                                Setting the varflag to a value greater than the
+                                value used in the <filename>BB_NUMBER_THREADS</filename>
+                                variable causes <filename>number_threads</filename>
+                                to have no effect.
+                                </para></listitem>
+                        </itemizedlist>
+                    </note>
+                    </para></listitem>
                 <listitem><para><emphasis><filename>[postfuncs]</filename>:</emphasis>
                     List of functions to call after the completion of the task.
                     </para></listitem>

bitbake/lib/bb/fetch2/__init__.py

@@ -452,8 +452,8 @@ def uri_replace(ud, uri_find, uri_replace, replacements, d, mirrortarball=None):
             # Handle URL parameters
             if i:
                 # Any specified URL parameters must match
-                for k in uri_replace_decoded[loc]:
-                    if uri_decoded[loc][k] != uri_replace_decoded[loc][k]:
+                for k in uri_find_decoded[loc]:
+                    if uri_decoded[loc][k] != uri_find_decoded[loc][k]:
                         return None
             # Overwrite any specified replacement parameters
             for k in uri_replace_decoded[loc]:

bitbake/lib/bb/fetch2/bzr.py

@@ -41,8 +41,9 @@ class Bzr(FetchMethod):
         init bzr specific variable within url data
         """
         # Create paths to bzr checkouts
+        bzrdir = d.getVar("BZRDIR") or (d.getVar("DL_DIR") + "/bzr")
         relpath = self._strip_leading_slashes(ud.path)
-        ud.pkgdir = os.path.join(d.expand('${BZRDIR}'), ud.host, relpath)
+        ud.pkgdir = os.path.join(bzrdir, ud.host, relpath)
 
         ud.setup_revisions(d)
 
@@ -57,7 +58,7 @@ class Bzr(FetchMethod):
         command is "fetch", "update", "revno"
         """
 
-        basecmd = d.expand('${FETCHCMD_bzr}')
+        basecmd = d.getVar("FETCHCMD_bzr") or "/usr/bin/env bzr"
 
         proto =  ud.parm.get('protocol', 'http')
 

bitbake/lib/bb/fetch2/cvs.py

@@ -110,7 +110,7 @@ class Cvs(FetchMethod):
         if ud.tag:
             options.append("-r %s" % ud.tag)
 
-        cvsbasecmd = d.getVar("FETCHCMD_cvs")
+        cvsbasecmd = d.getVar("FETCHCMD_cvs") or "/usr/bin/env cvs"
         cvscmd = cvsbasecmd + " '-d" + cvsroot + "' co " + " ".join(options) + " " + ud.module
         cvsupdatecmd = cvsbasecmd + " '-d" + cvsroot + "' update -d -P " + " ".join(options)
 
@@ -121,7 +121,8 @@ class Cvs(FetchMethod):
         # create module directory
         logger.debug(2, "Fetch: checking for module directory")
         pkg = d.getVar('PN')
-        pkgdir = os.path.join(d.getVar('CVSDIR'), pkg)
+        cvsdir = d.getVar("CVSDIR") or (d.getVar("DL_DIR") + "/cvs")
+        pkgdir = os.path.join(cvsdir, pkg)
         moddir = os.path.join(pkgdir, localdir)
         workdir = None
         if os.access(os.path.join(moddir, 'CVS'), os.R_OK):

bitbake/lib/bb/fetch2/git.py

@@ -261,7 +261,7 @@ class Git(FetchMethod):
                 gitsrcname = gitsrcname + '_' + ud.revisions[name]
 
         dl_dir = d.getVar("DL_DIR")
-        gitdir = d.getVar("GITDIR") or (dl_dir + "/git2/")
+        gitdir = d.getVar("GITDIR") or (dl_dir + "/git2")
         ud.clonedir = os.path.join(gitdir, gitsrcname)
         ud.localfile = ud.clonedir
 

bitbake/lib/bb/fetch2/hg.py

@@ -80,7 +80,7 @@ class Hg(FetchMethod):
         ud.fullmirror = os.path.join(d.getVar("DL_DIR"), mirrortarball)
         ud.mirrortarballs = [mirrortarball]
 
-        hgdir = d.getVar("HGDIR") or (d.getVar("DL_DIR") + "/hg/")
+        hgdir = d.getVar("HGDIR") or (d.getVar("DL_DIR") + "/hg")
         ud.pkgdir = os.path.join(hgdir, hgsrcname)
         ud.moddir = os.path.join(ud.pkgdir, ud.module)
         ud.localfile = ud.moddir

bitbake/lib/bb/fetch2/osc.py

@@ -32,8 +32,9 @@ class Osc(FetchMethod):
         ud.module = ud.parm["module"]
 
         # Create paths to osc checkouts
+        oscdir = d.getVar("OSCDIR") or (d.getVar("DL_DIR") + "/osc")
         relpath = self._strip_leading_slashes(ud.path)
-        ud.pkgdir = os.path.join(d.getVar('OSCDIR'), ud.host)
+        ud.pkgdir = os.path.join(oscdir, ud.host)
         ud.moddir = os.path.join(ud.pkgdir, relpath, ud.module)
 
         if 'rev' in ud.parm:
@@ -54,7 +55,7 @@ class Osc(FetchMethod):
         command is "fetch", "update", "info"
         """
 
-        basecmd = d.expand('${FETCHCMD_osc}')
+        basecmd = d.getVar("FETCHCMD_osc") or "/usr/bin/env osc"
 
         proto = ud.parm.get('protocol', 'ocs')
 

bitbake/lib/bb/fetch2/perforce.py

@@ -43,13 +43,9 @@ class Perforce(FetchMethod):
         provided by the env, use it.  If P4PORT is specified by the recipe, use
         its values, which may override the settings in P4CONFIG.
         """
-        ud.basecmd = d.getVar('FETCHCMD_p4')
-        if not ud.basecmd:
-            ud.basecmd = "/usr/bin/env p4"
+        ud.basecmd = d.getVar("FETCHCMD_p4") or "/usr/bin/env p4"
 
-        ud.dldir = d.getVar('P4DIR')
-        if not ud.dldir:
-            ud.dldir = '%s/%s' % (d.getVar('DL_DIR'), 'p4')
+        ud.dldir = d.getVar("P4DIR") or (d.getVar("DL_DIR") + "/p4")
 
         path = ud.url.split('://')[1]
         path = path.split(';')[0]

bitbake/lib/bb/fetch2/repo.py

@@ -45,6 +45,8 @@ class Repo(FetchMethod):
         "master".
         """
 
+        ud.basecmd = d.getVar("FETCHCMD_repo") or "/usr/bin/env repo"
+
         ud.proto = ud.parm.get('protocol', 'git')
         ud.branch = ud.parm.get('branch', 'master')
         ud.manifest = ud.parm.get('manifest', 'default.xml')
@@ -60,8 +62,8 @@ class Repo(FetchMethod):
             logger.debug(1, "%s already exists (or was stashed). Skipping repo init / sync.", ud.localpath)
             return
 
+        repodir = d.getVar("REPODIR") or (d.getVar("DL_DIR") + "/repo")
         gitsrcname = "%s%s" % (ud.host, ud.path.replace("/", "."))
-        repodir = d.getVar("REPODIR") or os.path.join(d.getVar("DL_DIR"), "repo")
         codir = os.path.join(repodir, gitsrcname, ud.manifest)
 
         if ud.user:
@@ -72,11 +74,11 @@ class Repo(FetchMethod):
         repodir = os.path.join(codir, "repo")
         bb.utils.mkdirhier(repodir)
         if not os.path.exists(os.path.join(repodir, ".repo")):
-            bb.fetch2.check_network_access(d, "repo init -m %s -b %s -u %s://%s%s%s" % (ud.manifest, ud.branch, ud.proto, username, ud.host, ud.path), ud.url)
-            runfetchcmd("repo init -m %s -b %s -u %s://%s%s%s" % (ud.manifest, ud.branch, ud.proto, username, ud.host, ud.path), d, workdir=repodir)
+            bb.fetch2.check_network_access(d, "%s init -m %s -b %s -u %s://%s%s%s" % (ud.basecmd, ud.manifest, ud.branch, ud.proto, username, ud.host, ud.path), ud.url)
+            runfetchcmd("%s init -m %s -b %s -u %s://%s%s%s" % (ud.basecmd, ud.manifest, ud.branch, ud.proto, username, ud.host, ud.path), d, workdir=repodir)
 
-        bb.fetch2.check_network_access(d, "repo sync %s" % ud.url, ud.url)
-        runfetchcmd("repo sync", d, workdir=repodir)
+        bb.fetch2.check_network_access(d, "%s sync %s" % (ud.basecmd, ud.url), ud.url)
+        runfetchcmd("%s sync" % ud.basecmd, d, workdir=repodir)
 
         scmdata = ud.parm.get("scmdata", "")
         if scmdata == "keep":

bitbake/lib/bb/fetch2/svn.py

@@ -49,7 +49,7 @@ class Svn(FetchMethod):
         if not "module" in ud.parm:
             raise MissingParameterError('module', ud.url)
 
-        ud.basecmd = d.getVar('FETCHCMD_svn')
+        ud.basecmd = d.getVar("FETCHCMD_svn") or "/usr/bin/env svn --non-interactive --trust-server-cert"
 
         ud.module = ud.parm["module"]
 
@@ -59,8 +59,9 @@ class Svn(FetchMethod):
             ud.path_spec = ud.parm["path_spec"]
 
         # Create paths to svn checkouts
+        svndir = d.getVar("SVNDIR") or (d.getVar("DL_DIR") + "/svn")
         relpath = self._strip_leading_slashes(ud.path)
-        ud.pkgdir = os.path.join(d.expand('${SVNDIR}'), ud.host, relpath)
+        ud.pkgdir = os.path.join(svndir, ud.host, relpath)
         ud.moddir = os.path.join(ud.pkgdir, ud.module)
 
         ud.setup_revisions(d)

bitbake/lib/bb/runqueue.py

@@ -94,13 +94,13 @@ class RunQueueStats:
         self.active = self.active - 1
         self.failed = self.failed + 1
 
-    def taskCompleted(self, number = 1):
-        self.active = self.active - number
-        self.completed = self.completed + number
+    def taskCompleted(self):
+        self.active = self.active - 1
+        self.completed = self.completed + 1
 
-    def taskSkipped(self, number = 1):
-        self.active = self.active + number
-        self.skipped = self.skipped + number
+    def taskSkipped(self):
+        self.active = self.active + 1
+        self.skipped = self.skipped + 1
 
     def taskActive(self):
         self.active = self.active + 1
@@ -134,6 +134,7 @@ class RunQueueScheduler(object):
         self.prio_map = [self.rqdata.runtaskentries.keys()]
 
         self.buildable = []
+        self.skip_maxthread = {}
         self.stamps = {}
         for tid in self.rqdata.runtaskentries:
             (mc, fn, taskname, taskfn) = split_tid_mcfn(tid)
@@ -150,8 +151,25 @@ class RunQueueScheduler(object):
         self.buildable = [x for x in self.buildable if x not in self.rq.runq_running]
         if not self.buildable:
             return None
+
+        # Filter out tasks that have a max number of threads that have been exceeded
+        skip_buildable = {}
+        for running in self.rq.runq_running.difference(self.rq.runq_complete):
+            rtaskname = taskname_from_tid(running)
+            if rtaskname not in self.skip_maxthread:
+                self.skip_maxthread[rtaskname] = self.rq.cfgData.getVarFlag(rtaskname, "number_threads")
+            if not self.skip_maxthread[rtaskname]:
+                continue
+            if rtaskname in skip_buildable:
+                skip_buildable[rtaskname] += 1
+            else:
+                skip_buildable[rtaskname] = 1
+
         if len(self.buildable) == 1:
             tid = self.buildable[0]
+            taskname = taskname_from_tid(tid)
+            if taskname in skip_buildable and skip_buildable[taskname] >= int(self.skip_maxthread[taskname]):
+                return None
             stamp = self.stamps[tid]
             if stamp not in self.rq.build_stamps.values():
                 return tid
@@ -164,6 +182,9 @@ class RunQueueScheduler(object):
         best = None
         bestprio = None
         for tid in self.buildable:
+            taskname = taskname_from_tid(tid)
+            if taskname in skip_buildable and skip_buildable[taskname] >= int(self.skip_maxthread[taskname]):
+                continue
             prio = self.rev_prio_map[tid]
             if bestprio is None or bestprio > prio:
                 stamp = self.stamps[tid]
@@ -1040,7 +1061,7 @@ class RunQueueData:
 
         # Create a whitelist usable by the stamp checks
         self.stampfnwhitelist = {}
-        for mc in self.taskData: 
+        for mc in self.taskData:
             self.stampfnwhitelist[mc] = []
             for entry in self.stampwhitelist.split():
                 if entry not in self.taskData[mc].build_targets:
@@ -1072,7 +1093,7 @@ class RunQueueData:
                     bb.debug(1, "Task %s is marked nostamp, cannot invalidate this task" % taskname)
             else:
                 logger.verbose("Invalidate task %s, %s", taskname, fn)
-                bb.parse.siggen.invalidate_task(taskname, self.dataCaches[mc], fn)
+                bb.parse.siggen.invalidate_task(taskname, self.dataCaches[mc], taskfn)
 
         self.init_progress_reporter.next_stage()
 
@@ -1865,14 +1886,13 @@ class RunQueueExecuteTasks(RunQueueExecute):
                 continue
             if revdep in self.runq_buildable:
                 continue
-            alldeps = 1
+            alldeps = True
             for dep in self.rqdata.runtaskentries[revdep].depends:
                 if dep not in self.runq_complete:
-                    alldeps = 0
-            if alldeps == 1:
+                    alldeps = False
+                    break
+            if alldeps:
                 self.setbuildable(revdep)
-                fn = fn_from_tid(revdep)
-                taskname = taskname_from_tid(revdep)
                 logger.debug(1, "Marking task %s as buildable", revdep)
 
     def task_complete(self, task):
@@ -1896,8 +1916,8 @@ class RunQueueExecuteTasks(RunQueueExecute):
         self.setbuildable(task)
         bb.event.fire(runQueueTaskSkipped(task, self.stats, self.rq, reason), self.cfgData)
         self.task_completeoutright(task)
-        self.stats.taskCompleted()
         self.stats.taskSkipped()
+        self.stats.taskCompleted()
 
     def execute(self):
         """
@@ -2342,8 +2362,8 @@ class RunQueueExecuteScenequeue(RunQueueExecute):
     def task_failoutright(self, task):
         self.runq_running.add(task)
         self.runq_buildable.add(task)
-        self.stats.taskCompleted()
         self.stats.taskSkipped()
+        self.stats.taskCompleted()
         self.scenequeue_notcovered.add(task)
         self.scenequeue_updatecounters(task, True)
 
@@ -2351,8 +2371,8 @@ class RunQueueExecuteScenequeue(RunQueueExecute):
         self.runq_running.add(task)
         self.runq_buildable.add(task)
         self.task_completeoutright(task)
-        self.stats.taskCompleted()
         self.stats.taskSkipped()
+        self.stats.taskCompleted()
 
     def execute(self):
         """

bitbake/lib/bb/siggen.py

@@ -347,7 +347,7 @@ class SignatureGeneratorBasicHash(SignatureGeneratorBasic):
 
     def stampcleanmask(self, stampbase, fn, taskname, extrainfo):
         return self.stampfile(stampbase, fn, taskname, extrainfo, clean=True)
-        
+
     def invalidate_task(self, task, d, fn):
         bb.note("Tainting hash to force rebuild of task %s, %s" % (fn, task))
         bb.build.write_taint(task, d, fn)
@@ -636,7 +636,7 @@ def compare_sigfiles(a, b, recursecb=None, color=False, collapsed=False):
                         if collapsed:
                             output.extend(recout)
                         else:
-                            # If a dependent hash changed, might as well print the line above and then defer to the changes in 
+                            # If a dependent hash changed, might as well print the line above and then defer to the changes in
                             # that hash since in all likelyhood, they're the same changes this task also saw.
                             output = [output[-1]] + recout
 

bitbake/lib/bb/tests/fetch.py

@@ -406,6 +406,8 @@ class MirrorUriTest(FetcherTest):
             : "http://somewhere2.org/somefile_1.2.3.tar.gz",
         ("http://somewhere.org/somedir1/somedir2/somefile_1.2.3.tar.gz", "http://.*/.*", "http://somewhere2.org/")
             : "http://somewhere2.org/somefile_1.2.3.tar.gz",
+        ("git://someserver.org/bitbake;tag=1234567890123456789012345678901234567890;branch=master", "git://someserver.org/bitbake;branch=master", "git://git.openembedded.org/bitbake;protocol=http")
+            : "git://git.openembedded.org/bitbake;tag=1234567890123456789012345678901234567890;branch=master;protocol=http",
 
         #Renaming files doesn't work
         #("http://somewhere.org/somedir1/somefile_1.2.3.tar.gz", "http://somewhere.org/somedir1/somefile_1.2.3.tar.gz", "http://somewhere2.org/somedir3/somefile_2.3.4.tar.gz") : "http://somewhere2.org/somedir3/somefile_2.3.4.tar.gz"

documentation/Makefile

@@ -268,7 +268,7 @@ TARFILES = mega-manual.html mega-style.css \
 	figures/sdk-devtool-add-flow.png figures/sdk-installed-extensible-sdk-directory.png \
 	figures/sdk-devtool-modify-flow.png figures/sdk-eclipse-dev-flow.png \
 	figures/sdk-devtool-upgrade-flow.png figures/bitbake-build-flow.png figures/bypqs-title.png \
-	figures/overview-manual-title.png
+	figures/overview-manual-title.png figures/sdk-autotools-flow.png figures/sdk-makefile-flow.png
 	endif
 
 MANUALS = $(DOC)/$(DOC).html
@@ -295,7 +295,7 @@ TARFILES = sdk-manual.html sdk-style.css figures/sdk-title.png \
            figures/sdk-environment.png figures/sdk-installed-standard-sdk-directory.png \
 	   figures/sdk-installed-extensible-sdk-directory.png figures/sdk-devtool-add-flow.png \
 	   figures/sdk-devtool-modify-flow.png figures/sdk-eclipse-dev-flow.png \
-	   figures/sdk-devtool-upgrade-flow.png \
+	   figures/sdk-devtool-upgrade-flow.png figures/sdk-autotools-flow.png figures/sdk-makefile-flow.png \
            eclipse
 MANUALS = $(DOC)/$(DOC).html $(DOC)/eclipse
 FIGURES = figures

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

@@ -15072,6 +15072,31 @@
                 </para>
             </section>
         </section>
+
+        <section id='copying-licenses-that-do-not-exist'>
+            <title>Copying Licenses that Do Not Exist</title>
+
+            <para>
+                Some packages, such as the linux-firmware package, have many
+                licenses that are not in any way common.
+                You can avoid adding a lot of these types of common license
+                files, which are only applicable to a specific package, by using
+                the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-NO_GENERIC_LICENSE'><filename>NO_GENERIC_LICENSE</filename></ulink>
+                variable.
+                Using this variable also avoids QA errors when you use a
+                non-common, non-CLOSED license in a recipe.
+            </para>
+
+            <para>
+                The following is an example that uses the
+                <filename>LICENSE.Abilis.txt</filename>
+                file as the license from the fetched source:
+                <literallayout class='monospaced'>
+     NO_GENERIC_LICENSE[Firmware-Abilis] = "LICENSE.Abilis.txt"
+                </literallayout>
+            </para>
+        </section>
     </section>
 
     <section id='using-the-error-reporting-tool'>

documentation/ref-manual/ref-tasks.xml

@@ -596,15 +596,6 @@
         </para>
     </section>
 
-    <section id='ref-tasks-rm_work_all'>
-        <title><filename>do_rm_work_all</filename></title>
-
-        <para>
-            Top-level task for removing work files after the build system has
-            finished with them.
-        </para>
-    </section>
-
     <section id='ref-tasks-unpack'>
         <title><filename>do_unpack</filename></title>
 

documentation/ref-manual/ref-variables.xml

@@ -9011,6 +9011,40 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-NO_GENERIC_LICENSE'><glossterm>NO_GENERIC_LICENSE</glossterm>
+            <info>
+                NO_GENERIC_LICENSE[doc] = "Used to allow copying a license that does not exist in common licenses."
+            </info>
+            <glossdef>
+                <para role="glossdeffirst">
+<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+                    Avoids QA errors when you use a non-common, non-CLOSED
+                    license in a recipe.
+                    Packages exist, such as the linux-firmware package, with
+                    many licenses that are not in any way common.
+                    Also, new licenses are added occasionally to avoid
+                    introducing a lot of common license files, which are only
+                    applicable to a specific package.
+                    <filename>NO_GENERIC_LICENSE</filename> is used to allow
+                    copying a license that does not exist in common licenses.
+                </para>
+
+                <para>
+                    The following example shows how to add
+                    <filename>NO_GENERIC_LICENSE</filename> to a recipe:
+                    <literallayout class='monospaced'>
+     NO_GENERIC_LICENSE[<replaceable>license_name</replaceable>] = "<replaceable>license_file_in_fetched_source</replaceable>"
+                    </literallayout>
+                    The following is an example that uses the
+                    <filename>LICENSE.Abilis.txt</filename> file as the license
+                    from the fetched source:
+                    <literallayout class='monospaced'>
+     NO_GENERIC_LICENSE[Firmware-Abilis] = "LICENSE.Abilis.txt"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-NO_RECOMMENDATIONS'><glossterm>NO_RECOMMENDATIONS</glossterm>
             <info>
                 NO_RECOMMENDATIONS[doc] = "When set to '1', no recommended packages will be installed. Some recommended packages might be required for certain system functionality, such as kernel-modules. It is up to the user to add packages to IMAGE_INSTALL as needed."

documentation/sdk-manual/sdk-appendix-neon.xml

@@ -14,8 +14,8 @@
         from start to finish.
         For general information on using the Eclipse IDE and the Yocto
         Project Eclipse Plug-In, see the
-        "<link linkend='sdk-eclipse-project'>Developing Applications Using <trademark class='trade'>Eclipse</trademark></link>"
-        Chapter.
+        "<link linkend='application-development-workflow-using-eclipse'>Application Development Workflow Using <trademark class='trade'>Eclipse</trademark></link>"
+        section.
     </para>
 
     <section id='neon-setting-up-the-eclipse-ide'>
@@ -53,13 +53,18 @@
                         <ulink url='http://www.eclipse.org/neon/'>http://www.eclipse.org/neon/</ulink>.
                         </para></listitem>
                     <listitem><para><emphasis>Download the Tarball:</emphasis>
-                        Click the "Download" button and then use the "Eclipse
-                        IDE for C/C++ Developers"
-                        appropriate for your development system.
+                        Click the "Download" button and look for the
+                        "Eclipse IDE for C/C++ Developers" Neon 3 Package.
+                        Select the correct platform download link listed at
+                        the right.
+                        For example, click on "64-bit" next to Linux if your
+                        build host is running a 64-bit Linux distribution.
+                        Click through the process to save the file.
                         </para></listitem>
                     <listitem><para><emphasis>Unpack the Tarball:</emphasis>
-                        Move to a clean directory and unpack the tarball.
-                        Here is an example:
+                        Move to a directory and unpack the tarball.
+                        The following commands unpack the tarball into the
+                        home directory:
                         <literallayout class='monospaced'>
      $ cd ~
      $ tar -xzvf ~/Downloads/eclipse-cpp-neon-3-linux-gtk-x86_64.tar.gz
@@ -84,11 +89,22 @@
 
             <para>
                 Follow these steps to configure the Neon Eclipse IDE.
-                <note>
-                    Depending on how you installed Eclipse and what you have
-                    already done, some of the options will not appear.
-                    If you cannot find an option as directed by the manual,
-                    it has already been installed.
+                <note><title>Notes</title>
+                    <itemizedlist>
+                        <listitem><para>
+                            Depending on how you installed Eclipse and what
+                            you have already done, some of the options do
+                            not appear.
+                            If you cannot find an option as directed by the
+                            manual, it has already been installed.
+                            </para></listitem>
+                        <listitem><para>
+                            If you want to see all options regardless of
+                            whether they are installed or not, deselect the
+                            "Hide items that are already installed"
+                            check box.
+                            </para></listitem>
+                    </itemizedlist>
                 </note>
                 <orderedlist>
                     <listitem><para>Be sure Eclipse is running and
@@ -164,11 +180,11 @@
                             in the URL field and provide a meaningful name
                             in the "Name" field.
                             </para></listitem>
-                        <listitem><para>Click "OK" to have the entry added
-                            to the "Work with:" drop-down list.
-                            </para></listitem>
-                        <listitem><para>Select the entry for the plug-in
-                            from the "Work with:" drop-down list.
+                        <listitem><para>
+                            Click "OK" to have the entry automatically
+                            populate the "Work with:" field and to have
+                            the items for installation appear in the window
+                            below.
                             </para></listitem>
                         <listitem><para>Check the boxes next to the following:
                             <literallayout class='monospaced'>
@@ -196,8 +212,14 @@
                     To install the Neon Eclipse Yocto Plug-in from the latest
                     source code, follow these steps:
                     <orderedlist>
-                        <listitem><para>Be sure your development system
-                            has JDK 1.8+
+                        <listitem><para>
+                            Be sure your build host has JDK version 1.8
+                            or greater.
+                            On a Linux build host you can determine the
+                            version using the following command:
+                            <literallayout class='monospaced'>
+     $ java -version
+                            </literallayout>
                             </para></listitem>
                         <listitem><para>install X11-related packages:
                             <literallayout class='monospaced'>
@@ -211,18 +233,19 @@
      $ git clone git://git.yoctoproject.org/eclipse-yocto
                             </literallayout>
                             </para></listitem>
-                        <listitem><para>Use Git to checkout the correct
-                            tag:
+                        <listitem><para>
+                            Use Git to create the correct tag:
                             <literallayout class='monospaced'>
      $ cd ~/eclipse-yocto
-     $ git checkout neon/yocto-&DISTRO;
+     $ git checkout -b neon/&DISTRO_NAME_NO_CAP; remotes/origin/neon/&DISTRO_NAME_NO_CAP;
                             </literallayout>
                             This creates a local tag named
-                            <filename>neon/yocto-&DISTRO;</filename> based on
-                            the branch <filename>origin/neon-master</filename>.
-                            This puts you in a detached HEAD state, which
-                            is fine since you are only going to be building
-                            and not developing.
+                            <filename>neon/&DISTRO_NAME_NO_CAP;</filename>
+                            based on the branch
+                            <filename>origin/neon/&DISTRO_NAME_NO_CAP;</filename>.
+                            You are put into a detached HEAD state,
+                            which is fine since you are only going to
+                            be building and not developing.
                             </para></listitem>
                         <listitem><para>Change to the
                             <filename>scripts</filename>
@@ -243,20 +266,22 @@
                             directory of the Git repository created
                             earlier.
                             </para></listitem>
-                        <listitem><para>Run the <filename>build.sh</filename>
+                        <listitem><para>
+                            Run the <filename>build.sh</filename>
                             script as directed.
-                            Be sure to provide the tag name, documentation
-                            branch, and a release name.</para>
-                            <para>
-                            Following is an example:
+                            Be sure to provide the tag name,
+                            documentation branch, and a release name.</para>
+
+                            <para>Following is an example:
                             <literallayout class='monospaced'>
-     $ ECLIPSE_HOME=/home/scottrif/eclipse-yocto/scripts/eclipse ./build.sh -l neon/yocto-&DISTRO; master yocto-&DISTRO; 2>&amp;1 | tee build.log
+     $ ECLIPSE_HOME=/home/scottrif/eclipse-yocto/scripts/eclipse ./build.sh -l neon/&DISTRO_NAME_NO_CAP; master yocto-&DISTRO; 2>&amp;1 | tee build.log
                             </literallayout>
-                            The previous example command adds the tag you
-                            need for <filename>neon/yocto-&DISTRO;</filename>
-                            to <filename>HEAD</filename>, then tells the
-                            build script to use the local (-l) Git checkout
-                            for the build.
+                            The previous example command adds the tag
+                            you need for
+                            <filename>neon/&DISTRO_NAME_NO_CAP;</filename>
+                            to <filename>HEAD</filename>, then tells
+                            the build script to use the local (-l) Git
+                            checkout for the build.
                             After running the script, the file
                             <filename>org.yocto.sdk-</filename><replaceable>release</replaceable><filename>-</filename><replaceable>date</replaceable><filename>-archive.zip</filename>
                             is in the current directory.
@@ -310,7 +335,7 @@
         </section>
 
         <section id='neon-configuring-the-eclipse-yocto-plug-in'>
-            <title>Configuring the Neon Eclipse Yocto Plug-in</title>
+            <title>Configuring the Neon Eclipse Yocto Plug-In</title>
 
             <para>
                 Configuring the Neon Eclipse Yocto Plug-in involves setting the
@@ -324,14 +349,16 @@
             <para>
                 To start, you need to do the following from within the
                 Eclipse IDE:
-                <itemizedlist>
-                    <listitem><para>Choose "Preferences" from the
+                <orderedlist>
+                    <listitem><para>
+                        Choose "Preferences" from the
                         "Window" menu to display the Preferences Dialog.
                         </para></listitem>
-                    <listitem><para>Click "Yocto Project SDK" to display
+                    <listitem><para>
+                        Click "Yocto Project SDK" to display
                         the configuration screen.
                         </para></listitem>
-                </itemizedlist>
+                </orderedlist>
                 The following sub-sections describe how to configure the
                 the plug-in.
                 <note>
@@ -354,15 +381,15 @@
                     the sysroot location, and select the target
                     architecture.
                     <itemizedlist>
-                        <listitem><para><emphasis>Selecting the Toolchain Type:</emphasis>
-                            Choose between
-                            <filename>Standalone pre-built toolchain</filename>
+                        <listitem><para>
+                            <emphasis>Selecting the Toolchain Type:</emphasis>
+                            Choose between "Standalone pre-built toolchain"
                             and
-                            <filename>Build system derived toolchain</filename>
-                            for Cross Compiler Options.
+                            "Build system derived toolchain" for Cross Compiler
+                            Options.
                                 <itemizedlist>
-                                    <listitem><para><emphasis>
-                                        <filename>Standalone Pre-built Toolchain:</filename></emphasis>
+                                    <listitem><para>
+                                        <emphasis>Standalone Pre-built Toolchain:</emphasis>
                                         Select this type when you are using
                                         a stand-alone cross-toolchain.
                                         For example, suppose you are an
@@ -376,24 +403,25 @@
                                         and installed a pre-built toolchain
                                         for an existing image.
                                         </para></listitem>
-                                   <listitem><para><emphasis>
-                                        <filename>Build System Derived Toolchain:</filename></emphasis>
+                                   <listitem><para>
+                                        <emphasis>Build System Derived Toolchain:</emphasis>
                                         Select this type if you built the
                                         toolchain as part of the
                                         <ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink>.
-                                        When you select
-                                        <filename>Build system derived toolchain</filename>,
-                                        you are using the toolchain built and
-                                        bundled inside the Build Directory.
+                                        When you select "Build system derived
+                                        toolchain", you are using the toolchain
+                                        built and bundled inside the Build
+                                        Directory.
                                         For example, suppose you created a
                                         suitable image using the steps in the
                                         <ulink url='https://wiki.yoctoproject.org/wiki/TipsAndTricks/RunningEclipseAgainstBuiltImage'>wiki</ulink>.
-                                        In this situation, you would select the
-                                        <filename>Build system derived toolchain</filename>.
+                                        In this situation, you would select
+                                        "Build system derived toolchain".
                                         </para></listitem>
                                 </itemizedlist>
                             </para></listitem>
-                        <listitem><para><emphasis>Specify the Toolchain Root Location:</emphasis>
+                        <listitem><para>
+                            <emphasis>Specify the Toolchain Root Location:</emphasis>
                             If you are using a stand-alone pre-built
                             toolchain, you should be pointing to where it is
                             installed (e.g.
@@ -402,10 +430,10 @@
                             "<link linkend='sdk-installing-the-sdk'>Installing the SDK</link>"
                             section for information about how the SDK is
                             installed.</para>
+
                             <para>If you are using a build system derived
                             toolchain, the path you provide for the
-                            <filename>Toolchain Root Location</filename>
-                            field is the
+                            "Toolchain Root Location" field is the
                             <ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink>
                             from which you run the
                             <filename>bitbake</filename> command (e.g
@@ -414,10 +442,12 @@
                             "<link linkend='sdk-building-an-sdk-installer'>Building an SDK Installer</link>"
                             section.
                             </para></listitem>
-                        <listitem><para><emphasis>Specify Sysroot Location:</emphasis>
+                        <listitem><para>
+                            <emphasis>Specify Sysroot Location:</emphasis>
                             This location is where the root filesystem for
                             the target hardware resides.
                             </para>
+
                             <para>This location depends on where you
                             separately extracted and installed the
                             target filesystem when you either built
@@ -438,17 +468,18 @@
                             and you would browse to and select that directory
                             (e.g. <filename>/home/scottrif/build/MY_QEMU_ROOTFS</filename>).
                             </para>
+
                             <para>For more information on how to install the
                             toolchain and on how to extract and install the
                             sysroot filesystem, see the
                             "<link linkend='sdk-building-an-sdk-installer'>Building an SDK Installer</link>"
                             section.
                             </para></listitem>
-                        <listitem><para><emphasis>Select the Target Architecture:</emphasis>
+                        <listitem><para>
+                            <emphasis>Select the Target Architecture:</emphasis>
                             The target architecture is the type of hardware
                             you are going to use or emulate.
-                            Use the pull-down
-                            <filename>Target Architecture</filename> menu
+                            Use the pull-down "Target Architecture" menu
                             to make your selection.
                             The pull-down menu should have the supported
                             architectures.
@@ -473,16 +504,17 @@
                     emulator, or you can choose to run your image on actual
                     hardware.
                     <itemizedlist>
-                        <listitem><para><emphasis>QEMU:</emphasis>
+                        <listitem><para>
+                            <emphasis>QEMU:</emphasis>
                             Select this option if you will be using the
                             QEMU emulator.
                             If you are using the emulator, you also need to
                             locate the kernel and specify any custom
                             options.</para>
-                            <para>If you selected the
-                            <filename>Build system derived toolchain</filename>,
-                            the target kernel you built will be located in
-                            the
+
+                            <para>If you selected the Build system derived
+                            toolchain, the target kernel you built will be
+                            located in the
                             <ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink>
                             in
                             <filename>tmp/deploy/images/<replaceable>machine</replaceable></filename>
@@ -494,10 +526,12 @@
                             followed by the image (e.g.
                             <filename>/home/scottrif/poky/build/tmp/deploy/images/qemux86/bzImage-qemux86.bin</filename>).
                             </para>
+
                             <para>If you selected the standalone pre-built
                             toolchain, the pre-built image you downloaded is
                             located in the directory you specified when you
                             downloaded the image.</para>
+
                             <para>Most custom options are for advanced QEMU
                             users to further customize their QEMU instance.
                             These options are specified between paired
@@ -514,16 +548,16 @@
                             The following is an example:
                            <literallayout class='monospaced'>
     serial ‘&lt;-m 256 -full-screen&gt;’
-                            </literallayout></para>
-                            <para>
+                            </literallayout>
                             Regardless of the mode, Sysroot is already
                             defined as part of the Cross-Compiler Options
-                            configuration in the
-                            <filename>Sysroot Location:</filename> field.
+                            configuration in the "Sysroot Location:" field.
                             </para></listitem>
-                        <listitem><para><emphasis>External HW:</emphasis>
+                        <listitem><para>
+                            <emphasis>External HW:</emphasis>
                             Select this option if you will be using actual
-                            hardware.</para></listitem>
+                            hardware.
+                            </para></listitem>
                     </itemizedlist>
                 </para>
 
@@ -558,31 +592,37 @@
             To create a project based on a Yocto template and then display
             the source code, follow these steps:
             <orderedlist>
-                <listitem><para>Select "C Project" from the "File -> New" menu.
+                <listitem><para>
+                    Select "C Project" from the "File -> New" menu.
                     </para></listitem>
-                <listitem><para>Expand <filename>Yocto Project SDK Autotools Project</filename>.
+                <listitem><para>
+                    Expand "Yocto Project SDK Autotools Project".
                     </para></listitem>
-                <listitem><para>Select <filename>Hello World ANSI C Autotools Projects</filename>.
+                <listitem><para>
+                    Select "Hello World ANSI C Autotools Projects".
                     This is an Autotools-based project based on a Yocto
                     template.
                     </para></listitem>
-                <listitem><para>Put a name in the <filename>Project name:</filename>
-                    field.
+                <listitem><para>
+                    Put a name in the "Project name:" field.
                     Do not use hyphens as part of the name
-                    (e.g. <filename>hello</filename>).
+                    (e.g. "hello").
                     </para></listitem>
-                <listitem><para>Click "Next".
+                <listitem><para>
+                    Click "Next".
                     </para></listitem>
-                <listitem><para>Add appropriate information in the various
-                    fields.
+                <listitem><para>
+                    Add appropriate information in the various fields.
                     </para></listitem>
-                <listitem><para>Click "Finish".
+                <listitem><para>
+                    Click "Finish".
                     </para></listitem>
-                <listitem><para>If the "open perspective" prompt appears,
+                <listitem><para>
+                    If the "open perspective" prompt appears,
                     click "Yes" so that you are in the C/C++ perspective.
                     </para></listitem>
-                <listitem><para>The left-hand navigation pane shows your
-                    project.
+                <listitem><para>
+                    The left-hand navigation pane shows your project.
                     You can display your source by double clicking the
                     project's source file.
                     </para></listitem>
@@ -600,7 +640,8 @@
             You can override these settings for a given project by following
             these steps:
             <orderedlist>
-                <listitem><para>Select "Yocto Project Settings" from
+                <listitem><para>
+                    Select "Yocto Project Settings" from
                     the "Project -> Properties" menu.
                     This selection brings up the Yocto Project Settings
                     Dialog and allows you to make changes specific to an
@@ -613,22 +654,19 @@
                     The Yocto Project Settings Dialog allows you to override
                     those default settings for a given project.
                     </para></listitem>
-                <listitem><para>Make or verify your configurations for the
-                    project and click "OK".
+                <listitem><para>
+                    Make or verify your configurations for the project and
+                    click "OK".
                     </para></listitem>
-                <listitem><para>Right-click in the navigation pane and
-                    select "Reconfigure Project" from the pop-up menu.
+                <listitem><para>
+                    Right-click in the navigation pane and select
+                    "Reconfigure Project" from the pop-up menu.
                     This selection reconfigures the project by running
-                    <filename>autogen.sh</filename> in the workspace for
-                    your project.
-                    The script also runs <filename>libtoolize</filename>,
-                    <filename>aclocal</filename>,
-                    <filename>autoconf</filename>,
-                    <filename>autoheader</filename>,
-                    <filename>automake --a</filename>, and
-                    <filename>./configure</filename>.
-                    Click on the "Console" tab beneath your source code to
-                    see the results of reconfiguring your project.
+                    <ulink url='https://en.wikipedia.org/wiki/GNU_Build_System'>Autotools GNU utility programs</ulink>
+                    such as Autoconf, Automake, and so forth in the
+                    workspace for your project.
+                    Click on the "Console" tab beneath your source code
+                    to see the results of reconfiguring your project.
                     </para></listitem>
             </orderedlist>
         </para>
@@ -656,8 +694,7 @@
                         Select the project.
                         </para></listitem>
                     <listitem><para>
-                        Select "Folder" from the
-                        <filename>File > New</filename> menu.
+                        Select "Folder" from the "File > New" menu.
                         </para></listitem>
                     <listitem><para>
                         In the "New Folder" Dialog, select "Link to alternate
@@ -782,54 +819,66 @@
                 exit out of or close that shell).
             </note>
             <orderedlist>
-                <listitem><para>Select "Debug Configurations..." from the
+                <listitem><para>
+                    Select "Debug Configurations..." from the
                     "Run" menu.</para></listitem>
-                <listitem><para>In the left area, expand
-                    <filename>C/C++Remote Application</filename>.
+                <listitem><para>
+                    In the left area, expand
+                    "C/C++Remote Application".
                     </para></listitem>
-                <listitem><para>Locate your project and select it to bring
+                <listitem><para>
+                    Locate your project and select it to bring
                     up a new tabbed view in the Debug Configurations Dialog.
                     </para></listitem>
-                <listitem><para>Click on the "Debugger" tab to see the
+                <listitem><para>
+                    Click on the "Debugger" tab to see the
                     cross-tool debugger you are using.
                     Be sure to change to the debugger perspective in Eclipse.
                     </para></listitem>
-                <listitem><para>Click on the "Main" tab.
+                <listitem><para>
+                    Click on the "Main" tab.
                     </para></listitem>
                 <listitem><para>Create a new connection to the QEMU instance
                     by clicking on "new".</para></listitem>
-                <listitem><para>Select <filename>SSH</filename>, which means
+                <listitem><para>
+                    Select "SSH", which means
                     Secure Socket Shell.
                     Optionally, you can select a TCF connection instead.
                     </para></listitem>
-                <listitem><para>Click "Next".
+                <listitem><para>
+                    Click "Next".
                     </para></listitem>
-                <listitem><para>Clear out the "Connection name" field and
+                <listitem><para>
+                    Clear out the "Connection name" field and
                     enter any name you want for the connection.
                     </para></listitem>
-                <listitem><para>Put the IP address for the connection in
+                <listitem><para>
+                    Put the IP address for the connection in
                     the "Host" field.
-                    For QEMU, the default is <filename>192.168.7.2</filename>.
+                    For QEMU, the default is "192.168.7.2".
                     However, if a previous QEMU session did not exit
                     cleanly, the IP address increments (e.g.
-                    <filename>192.168.7.3</filename>).
+                    "192.168.7.3").
                     <note>
                         You can find the IP address for the current QEMU
                         session by looking in the xterm that opens when
                         you launch QEMU.
                     </note>
                     </para></listitem>
-                <listitem><para>Enter <filename>root</filename>, which
+                <listitem><para>
+                    Enter "root", which
                     is the default for QEMU, for the "User" field.
                     Be sure to leave the password field empty.
                     </para></listitem>
                 <listitem><para>Click "Finish" to close the
                     New Connections Dialog.
                     </para></listitem>
-                <listitem><para>If necessary, use the drop-down menu now in the
+                <listitem><para>
+                    If necessary, use the drop-down menu now in the
                     "Connection" field and pick the IP Address you entered.
                      </para></listitem>
-                <listitem><para>Assuming you are connecting as the root user,
+                <listitem><para>
+                    Assuming you are connecting as the root user,
                     which is the default for QEMU x86-64 SDK images provided by
                     the Yocto Project, in the "Remote Absolute File Path for
                     C/C++ Application" field, browse to
@@ -874,9 +923,11 @@
                 <listitem><para>
                     Be sure you change to the "Debug" perspective in Eclipse.
                     </para></listitem>
-                <listitem><para>Click "Debug"
+                <listitem><para>
+                    Click "Debug"
                     </para></listitem>
-                <listitem><para>Accept the debug perspective.
+                <listitem><para>
+                    Accept the debug perspective.
                     </para></listitem>
             </orderedlist>
         </para>

documentation/sdk-manual/sdk-appendix-obtain.xml

@@ -25,32 +25,33 @@
                 Go to <ulink url='&YOCTO_TOOLCHAIN_DL_URL;'></ulink>
                 </para></listitem>
             <listitem><para>
-                <emphasis>Open the Folder for Your Development System:</emphasis>
-                Open the folder that matches your host development system
+                <emphasis>Open the Folder for Your Build Host:</emphasis>
+                Open the folder that matches your
+                <ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>build host</ulink>
                 (i.e. <filename>i686</filename> for 32-bit machines or
                 <filename>x86_64</filename> for 64-bit machines).
                 </para></listitem>
             <listitem><para>
                 <emphasis>Locate and Download the SDK Installer:</emphasis>
                 You need to find and download the installer appropriate for
-                your development system, target hardware, and image type.
+                your build host, target hardware, and image type.
                 </para>
 
                 <para>The installer files (<filename>*.sh</filename>) follow
                 this naming convention:
                 <literallayout class='monospaced'>
-     poky-eglibc-<replaceable>host_system</replaceable>-core-image-<replaceable>type</replaceable>-<replaceable>arch</replaceable>-toolchain-ext-<replaceable>release</replaceable>.sh
+     poky-glibc-<replaceable>host_system</replaceable>-core-image-<replaceable>type</replaceable>-<replaceable>arch</replaceable>-toolchain[-ext]-<replaceable>release</replaceable>.sh
 
      Where:
          <replaceable>host_system</replaceable> is a string representing your development system:
-                i686 or x86_64.
+                "i686" or "x86_64"
 
-         <replaceable>type</replaceable> is a string representing either a "sato" or "minimal"
-                image.
+         <replaceable>type</replaceable> is a string representing the image:
+                "sato" or "minimal"
 
          <replaceable>arch</replaceable> is a string representing the target architecture:
-                aarch64, armv5e, core2-64, coretexa8hf-neon, i586, mips3242,
-                mips64, or ppc7400.
+                "aarch64", "armv5e", "core2-64", "coretexa8hf-neon", "i586", "mips32r2",
+                "mips64", or "ppc7400"
 
          <replaceable>release</replaceable> is the version of Yocto Project.
 
@@ -65,10 +66,10 @@
                 libraries appropriate for developing against those images.
                 </para>
 
-                <para>For example, if your host development system is a
-                64-bit x86 system and you are need an extended SDK for a
-                64-bit core2 target, go into the <filename>x86_64</filename>
-                folder and download the following installer:
+                <para>For example, if your build host is a 64-bit x86 system
+                and you need an extended SDK for a 64-bit core2 target, go
+                into the <filename>x86_64</filename> folder and download the
+                following installer:
                 <literallayout class='monospaced'>
      poky-glibc-x86_64-core-image-sato-core2-64-toolchain-ext-&DISTRO;.sh
                 </literallayout>
@@ -97,7 +98,7 @@
     <title>Building an SDK Installer</title>
 
     <para>
-        As an alternative to locating and downloading a SDK installer,
+        As an alternative to locating and downloading an SDK installer,
         you can build the SDK installer.
         Follow these steps:
         <orderedlist>
@@ -138,8 +139,7 @@
                 Among other things, the script creates the
                 <ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink>,
                 which is <filename>build</filename> in this case
-                and is located in the
-                <ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink>.
+                and is located in the Source Directory.
                 After the script runs, your current working directory
                 is set to the <filename>build</filename> directory.
                 </para></listitem>
@@ -148,14 +148,14 @@
                 Check to be sure that your
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink>
                 variable in the <filename>local.conf</filename> file in your
-                <ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink>
-                matches the architecture for which you are building.
+                Build Directory matches the architecture for which you are
+                building.
                 </para></listitem>
             <listitem><para>
                 <emphasis>Make Sure Your SDK Machine is Correctly Set:</emphasis>
                 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), be sure that the
+                machine (i.e. the build host), be sure that the
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-SDKMACHINE'><filename>SDKMACHINE</filename></ulink>
                 variable in the <filename>local.conf</filename> file in your
                 Build Directory is correctly set.
@@ -174,7 +174,7 @@
                 <literallayout class='monospaced'>
      $ bitbake <replaceable>image</replaceable> -c populate_sdk_ext
                 </literallayout>
-                These commands result in a SDK installer that contains the
+                These commands produce an SDK installer that contains the
                 sysroot that matches your target root filesystem.</para>
 
                 <para>When the <filename>bitbake</filename> command completes,
@@ -183,16 +183,18 @@
                 <note><title>Notes</title>
                     <itemizedlist>
                         <listitem><para>
-                            By default, this toolchain does not build static
-                            binaries.
+                            By default, the previous BitBake command does not
+                            build static binaries.
                             If you want to use the toolchain to build these
                             types of libraries, you need to be sure your SDK
                             has the appropriate static development libraries.
                             Use the
                             <ulink url='&YOCTO_DOCS_REF_URL;#var-TOOLCHAIN_TARGET_TASK'><filename>TOOLCHAIN_TARGET_TASK</filename></ulink>
                             variable inside your <filename>local.conf</filename>
-                            file to install the appropriate library packages
-                            in the SDK.
+                            file before building the SDK installer.
+                            Doing so ensures that the eventual SDK installation
+                            process installs the appropriate library packages
+                            as part of the SDK.
                             Following is an example using
                             <filename>libc</filename> static development
                             libraries:
@@ -275,6 +277,9 @@
                 <para>The pre-built root filesystem image files
                 follow these naming conventions:
                 <literallayout class='monospaced'>
+<!--
+     core-image-<replaceable>profile</replaceable>-<replaceable>arch</replaceable>-<replaceable>date_time</replaceable>.rootfs.tar.bz2
+-->
      core-image-<replaceable>profile</replaceable>-<replaceable>arch</replaceable>.tar.bz2
 
      Where:
@@ -285,9 +290,12 @@
                    "Images" chapter in the Yocto Project Reference Manual.
 
          <replaceable>arch</replaceable> is a string representing the target architecture:
-                beaglebone, edgerouter, genericx86, genericx86-64, mpc8315e-rdb,
-                qemuarm, qemuarm64, qemumips, qemumips64, qemuppc, qemux86, or
-                qemux86-64.
+                   beaglebone, edgerouter, genericx86, genericx86-64, mpc8315e-rdb,
+                   and several versions for qemu*.
+
+<!-->
+         <replaceable>date_time</replaceable> is a date and time stamp.
+-->
 
                 </literallayout>
                 The root filesystems provided by the Yocto Project are based
@@ -300,7 +308,7 @@
                 <filename>core-image-minimal</filename> image, you need
                 to download the following root filesystem image file:
                 <literallayout class='monospaced'>
-     core-image-minimal-beaglebone.tar.bz2
+     core-image-minimal-beaglebone-yocto.tar.bz2
                 </literallayout>
                 </para></listitem>
             <listitem><para>
@@ -313,8 +321,8 @@
                 which you installed the toolchain (e.g.
                 <filename>poky_sdk</filename>).</para>
 
-                <para>Following is an example for the Core2 64-bit
-                architecture:
+                <para>Following is an example for the BeagleBone Board
+                previously shown:
                 <literallayout class='monospaced'>
      $ source ~/poky_sdk/environment-setup-core2-64-poky-linux
                 </literallayout>

documentation/sdk-manual/sdk-eclipse-project.xml

@@ -12,15 +12,34 @@
         application all from within Eclipse.
         This chapter describes general workflow using the SDK and Eclipse
         and how to configure and set up Eclipse.
+        <note><title>Notes</title>
+            <itemizedlist>
+                <listitem><para>
+                    This chapter assumes development of applications on top of
+                    an image prepared using the Yocto Project.
+                    As such, inclusion of a pre-built image or the building of
+                    an image is included in the workflow.
+                    </para></listitem>
+                <listitem><para>
+                    The chapter also assumes development on a build host that
+                    is set up to use the Yocto Project.
+                    Realize that you can easily use Eclipse and the Yocto
+                    Project plug-in to develop an application for any number
+                    of images developed and tested on different machines.
+                    </para></listitem>
+            </itemizedlist>
+        </note>
     </para>
 
-    <section id='workflow-using-eclipse'>
-        <title>Workflow Using <trademark class='trade'>Eclipse</trademark></title>
+    <section id='application-development-workflow-using-eclipse'>
+        <title>Application Development Workflow Using <trademark class='trade'>Eclipse</trademark></title>
 
         <para>
-            The following figure and supporting list summarize the
-            application development general workflow that employs both the
-            SDK Eclipse.
+            The following figure and supporting list summarize a
+            general workflow for application development that uses the
+            SDK within the Eclipse IDE.
+            The application developed runs on top of an image created using
+            the Yocto Project.
         </para>
 
         <para>
@@ -32,22 +51,29 @@
             <orderedlist>
                 <listitem><para>
                     <emphasis>Prepare the Host System for the Yocto Project</emphasis>:
+                    Because this example workflow assumes development on a
+                    system set up to use the Yocto Project, you need to be
+                    sure your
+                    <ulink url='&YOCTO_DOCS_REF_URL;#hardware-build-system-term'>build host</ulink>
+                    can use the Yocto Project.
                     See the
-                    "<ulink url='&YOCTO_DOCS_REF_URL;#detailed-supported-distros'>Supported Linux Distributions</ulink>"
-                    and
-                    "<ulink url='&YOCTO_DOCS_REF_URL;#required-packages-for-the-host-development-system'>Required Packages for the Host Development System</ulink>"
-                    sections both in the Yocto Project Reference Manual for
-                    requirements.
-                    In particular, be sure your host system has the
-                    <filename>xterm</filename> package installed.
+                    "<ulink url='&YOCTO_DOCS_DEV_URL;#setting-up-the-development-host-to-use-the-yocto-project'>Preparing a Build Host</ulink>"
+                    section in the Yocto Project Development Tasks Manual for
+                    information on how to set up your build host.
+                    <note>
+                        Be sure you install the "xterm" package, which is a
+                        <ulink url='&YOCTO_DOCS_REF_URL;#required-packages-for-the-host-development-system'>graphical and Eclipse plug-in extra</ulink>
+                        needed by Eclipse.
+                    </note>
                     </para></listitem>
                 <listitem><para>
-                    <emphasis>Secure the Yocto Project Kernel Target
-                    Image</emphasis>:
-                    You must have a target kernel image that has been built
-                    using the OpenEmbedded build system.</para>
-                    <para>Depending on whether the Yocto Project has a
-                    pre-built image that matches your target architecture
+                    <emphasis>Secure the Yocto Project Kernel Target Image</emphasis>:
+                    This example workflow assumes application development on
+                    top of an image built using the Yocto Project.
+                    Depending on whether you are using a pre-built image
+                    that matches your target architecture or you are using an
+                    image you build using the
+                    <ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>OpenEmbedded Build System</ulink>
                     and where you are going to run the image while you
                     develop your application (QEMU or real hardware), the
                     area from which you get the image differs.
@@ -78,6 +104,10 @@
                             "<ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;#using-devtool-to-patch-the-kernel'>Using <filename>devtool</filename> to Patch the Kernel</ulink>"
                             section in the Yocto Project Linux Kernel
                             Development Manual for an example.
+                            You can also see the
+                            "<ulink url='https://wiki.yoctoproject.org/wiki/TipsAndTricks/RunningEclipseAgainstBuiltImage#Making_a_Suitable_Qemux86_Image'>Making a Suitable Qemux86 Image</ulink>"
+                            wiki for steps needed to build an image suitable
+                            for QEMU and for debugging within the Eclipse IDE.
                             </para></listitem>
                     </itemizedlist>
                     </para></listitem>
@@ -91,10 +121,10 @@
                     section.
                     </para></listitem>
                 <listitem><para>
-                    <emphasis>Secure the Target Root Filesystem
-                    and the Cross-Development Toolchain</emphasis>:
+                    <emphasis>Secure the Target Root Filesystem and the Cross-Development Toolchain</emphasis>:
                     You need to find and download the appropriate root
                     filesystem and the cross-development toolchain.</para>
+
                     <para>You can find the tarballs for the root filesystem
                     in the same area used for the kernel image.
                     Depending on the type of image you are running, the
@@ -102,6 +132,7 @@
                     For example, if you are developing an application that
                     runs on an image that supports Sato, you need to get a
                     root filesystem that supports Sato.</para>
+
                     <para>You can find the cross-development toolchains at
                     <ulink url='&YOCTO_TOOLCHAIN_DL_URL;'><filename>toolchains</filename></ulink>.
                     Be sure to get the correct toolchain for your
@@ -118,14 +149,13 @@
                         section.
                         Another helpful resource for building an installer
                         is the
-                        <ulink url='https://wiki.yoctoproject.org/wiki/TipsAndTricks/RunningEclipseAgainstBuiltImage'>Cookbook guide to Making an Eclipse Debug Capable Image</ulink>
+                        "<ulink url='https://wiki.yoctoproject.org/wiki/TipsAndTricks/RunningEclipseAgainstBuiltImage'>Cookbook guide to Making an Eclipse Debug Capable Image</ulink>"
                         wiki page.
                     </note>
                     </para></listitem>
                 <listitem><para>
                     <emphasis>Create and Build Your Application</emphasis>:
-                    At this point, you need to have source files for your
-                    application.
+                    You need to have source files for your application.
                     Once you have the files, you can use the Eclipse IDE
                     to import them and build the project.
                     </para></listitem>
@@ -259,15 +289,28 @@
                             </para></listitem>
                         <listitem><para>
                             <emphasis>Install the Software:</emphasis>
-                            Accept the default "cpp-oxygen" directory and
-                            click "Install".
-                            Accept any license agreements and approve any
-                            certificates.
+                            Click "Install" to begin the installation.
+                            Accept all the certificates and any license
+                            agreements.
+                            Click "Install" again to finish the installation.
                             </para></listitem>
                         <listitem><para>
                             <emphasis>Launch Oxygen:</emphasis>
-                            Click the "Launch" button and accept the
-                            default "workspace".
+                            Accept the default "workspace" and click the
+                            "Launch" button.
+                            You should see the Eclipse welcome page from which
+                            can click "workbench" to enter your workspace.
+                            <note>
+                                The executable for Eclipse is located in the
+                                <filename>eclipse/cpp-oxygen/eclipse</filename>
+                                folder.
+                                To launch Eclipse outside of the installation
+                                process, simply execute that binary.
+                                Here is an example:
+                                <literallayout class='monospaced'>
+     $ ~/eclipse/cpp-oxygen/eclipse/eclipse
+                                </literallayout>
+                            </note>
                             </para></listitem>
                     </orderedlist>
                 </para>
@@ -278,17 +321,29 @@
 
                 <para>
                     Follow these steps to configure the Oxygen Eclipse IDE.
-                    <note>
-                        Depending on how you installed Eclipse and what
-                        you have already done, some of the options will
-                        not appear.
-                        If you cannot find an option as directed by the
-                        manual, it has already been installed.
+                    <note><title>Notes</title>
+                        <itemizedlist>
+                            <listitem><para>
+                                Depending on how you installed Eclipse and what
+                                you have already done, some of the options do
+                                not appear.
+                                If you cannot find an option as directed by the
+                                manual, it has already been installed.
+                                </para></listitem>
+                            <listitem><para>
+                                If you want to see all options regardless of
+                                whether they are installed or not, deselect the
+                                "Hide items that are already installed"
+                                check box.
+                                </para></listitem>
+                        </itemizedlist>
                     </note>
                     <orderedlist>
                         <listitem><para>
                             Be sure Eclipse is running and you are in your
                             workbench.
+                            Just click "workbench" if you are not in your
+                            default workspace.
                             </para></listitem>
                         <listitem><para>
                             Select "Install New Software" from the "Help"
@@ -341,7 +396,7 @@
                 <para>
                     You can install the Eclipse Yocto Plug-in into the
                     Eclipse IDE one of two ways:  use the Yocto Project's
-                    Eclipse Update site to install the pre-built plug-in
+                    Eclipse Update site to install the pre-built plug-in,
                     or build and install the plug-in from the latest
                     source code.
                 </para>
@@ -370,12 +425,10 @@
                                 name in the "Name" field.
                                 </para></listitem>
                             <listitem><para>
-                                Click "OK" to have the entry added
-                                to the "Work with:" drop-down list.
-                                </para></listitem>
-                            <listitem><para>
-                                Select the entry for the plug-in
-                                from the "Work with:" drop-down list.
+                                Click "OK" to have the entry automatically
+                                populate the "Work with:" field and to have
+                                the items for installation appear in the window
+                                below.
                                 </para></listitem>
                             <listitem><para>
                                 Check the boxes next to the following:
@@ -407,8 +460,13 @@
                         latest source code, follow these steps:
                         <orderedlist>
                             <listitem><para>
-                                Be sure your development system
-                                has JDK 1.8+
+                                Be sure your build host has JDK version 1.8
+                                or greater.
+                                On a Linux build host you can determine the
+                                version using the following command:
+                                <literallayout class='monospaced'>
+     $ java -version
+                                </literallayout>
                                 </para></listitem>
                             <listitem><para>
                                 Install X11-related packages:
@@ -428,12 +486,12 @@
                                 Use Git to create the correct tag:
                                 <literallayout class='monospaced'>
      $ cd ~/eclipse-yocto
-     $ git checkout -b oxygen/yocto-&DISTRO; remotes/origin/oxygen-master
+     $ git checkout -b oxygen/&DISTRO_NAME_NO_CAP; remotes/origin/oxygen/&DISTRO_NAME_NO_CAP;
                                 </literallayout>
                                 This creates a local tag named
-                                <filename>oxygen/yocto-&DISTRO;</filename>
+                                <filename>oxygen/&DISTRO_NAME_NO_CAP;</filename>
                                 based on the branch
-                                <filename>origin/oxygen-master</filename>.
+                                <filename>origin/oxygen/&DISTRO_NAME_NO_CAP;</filename>.
                                 You are put into a detached HEAD state,
                                 which is fine since you are only going to
                                 be building and not developing.
@@ -467,11 +525,11 @@
                                 <para>
                                 Following is an example:
                                 <literallayout class='monospaced'>
-     $ ECLIPSE_HOME=/home/scottrif/eclipse-yocto/scripts/eclipse ./build.sh -l oxygen/yocto-&DISTRO; master yocto-&DISTRO; 2>&amp;1 | tee build.log
+     $ ECLIPSE_HOME=/home/scottrif/eclipse-yocto/scripts/eclipse ./build.sh -l oxygen/&DISTRO_NAME_NO_CAP; master yocto-&DISTRO; 2>&amp;1 | tee build.log
                                 </literallayout>
                                 The previous example command adds the tag
                                 you need for
-                                <filename>oxygen/yocto-&DISTRO;</filename>
+                                <filename>oxygen/&DISTRO_NAME_NO_CAP;</filename>
                                 to <filename>HEAD</filename>, then tells
                                 the build script to use the local (-l) Git
                                 checkout for the build.
@@ -538,7 +596,7 @@
             </section>
 
             <section id='oxygen-configuring-the-eclipse-yocto-plug-in'>
-                <title>Configuring the Oxygen Eclipse Yocto Plug-in</title>
+                <title>Configuring the Oxygen Eclipse Yocto Plug-In</title>
 
                 <para>
                     Configuring the Oxygen Eclipse Yocto Plug-in involves
@@ -553,7 +611,7 @@
                 <para>
                     To start, you need to do the following from within the
                     Eclipse IDE:
-                    <itemizedlist>
+                    <orderedlist>
                         <listitem><para>
                             Choose "Preferences" from the "Window" menu to
                             display the Preferences Dialog.
@@ -562,7 +620,7 @@
                             Click "Yocto Project SDK" to display
                             the configuration screen.
                             </para></listitem>
-                    </itemizedlist>
+                    </orderedlist>
                     The following sub-sections describe how to configure
                     the plug-in.
                     <note>
@@ -570,7 +628,7 @@
                         example for preparing a QEMU image for use with
                         Eclipse is referenced as the "wiki" and is linked
                         to the example on the
-                        <ulink url='https://wiki.yoctoproject.org/wiki/TipsAndTricks/RunningEclipseAgainstBuiltImage'> Cookbook guide to Making an Eclipse Debug Capable Image</ulink>
+                        "<ulink url='https://wiki.yoctoproject.org/wiki/TipsAndTricks/RunningEclipseAgainstBuiltImage'> Cookbook guide to Making an Eclipse Debug Capable Image</ulink>"
                         wiki page.
                     </note>
                 </para>
@@ -587,18 +645,13 @@
                         architecture.
                         <itemizedlist>
                             <listitem><para>
-                                <emphasis>Selecting the Toolchain
-                                Type:</emphasis>
-                                Choose between
-                                <filename>Standalone pre-built toolchain</filename>
-                                and
-                                <filename>Build system derived toolchain</filename>
-                                for Cross Compiler Options.
+                                <emphasis>Selecting the Toolchain Type:</emphasis>
+                                Choose between "Standalone pre-built toolchain"
+                                and "Build system derived toolchain" for
+                                Cross Compiler Options.
                                 <itemizedlist>
                                     <listitem><para>
-                                        <emphasis>
-                                        <filename>Standalone Pre-built Toolchain:</filename>
-                                        </emphasis>
+                                        <emphasis>Standalone Pre-built Toolchain:</emphasis>
                                         Select this type when you are using
                                         a stand-alone cross-toolchain.
                                         For example, suppose you are an
@@ -613,29 +666,24 @@
                                         for an existing image.
                                         </para></listitem>
                                     <listitem><para>
-                                        <emphasis>
-                                        <filename>Build System Derived Toolchain:</filename>
-                                        </emphasis>
+                                        <emphasis>Build System Derived Toolchain:</emphasis>
                                         Select this type if you built the
                                         toolchain as part of the
                                         <ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink>.
-                                        When you select
-                                        <filename>Build system derived toolchain</filename>,
-                                        you are using the toolchain built
-                                        and bundled inside the Build
+                                        When you select "Build system derived
+                                        toolchain", you are using the toolchain
+                                        built and bundled inside the Build
                                         Directory.
                                         For example, suppose you created a
                                         suitable image using the steps in the
                                         <ulink url='https://wiki.yoctoproject.org/wiki/TipsAndTricks/RunningEclipseAgainstBuiltImage'>wiki</ulink>.
                                         In this situation, you would select
-                                        the
-                                        <filename>Build system derived toolchain</filename>.
+                                        "Build system derived toolchain".
                                         </para></listitem>
                                 </itemizedlist>
                                 </para></listitem>
                             <listitem><para>
-                                <emphasis>Specify the Toolchain Root
-                                Location:</emphasis>
+                                <emphasis>Specify the Toolchain Root Location:</emphasis>
                                 If you are using a stand-alone pre-built
                                 toolchain, you should be pointing to where
                                 it is installed (e.g.
@@ -644,11 +692,10 @@
                                 "<link linkend='sdk-installing-the-sdk'>Installing the SDK</link>"
                                 section for information about how the SDK is
                                 installed.</para>
+
                                 <para>If you are using a build system
                                 derived toolchain, the path you provide for
-                                the
-                                <filename>Toolchain Root Location</filename>
-                                field is the
+                                the "Toolchain Root Location" field is the
                                 <ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink>
                                 from which you run the
                                 <filename>bitbake</filename> command (e.g
@@ -659,11 +706,11 @@
                                 section.
                                 </para></listitem>
                             <listitem><para>
-                                <emphasis>Specify Sysroot Location:
-                                </emphasis>
+                                <emphasis>Specify Sysroot Location:</emphasis>
                                 This location is where the root filesystem
                                 for the target hardware resides.
                                 </para>
+
                                 <para>This location depends on where you
                                 separately extracted and installed the
                                 target filesystem when you either built
@@ -685,6 +732,7 @@
                                 directory (e.g.
                                 <filename>/home/scottrif/poky/build/MY_QEMU_ROOTFS</filename>).
                                 </para>
+
                                 <para>For more information on how to
                                 install the toolchain and on how to extract
                                 and install the sysroot filesystem, see the
@@ -692,12 +740,10 @@
                                 section.
                                 </para></listitem>
                             <listitem><para>
-                                <emphasis>Select the Target Architecture:
-                                </emphasis>
+                                <emphasis>Select the Target Architecture:</emphasis>
                                 The target architecture is the type of
                                 hardware you are going to use or emulate.
-                                Use the pull-down
-                                <filename>Target Architecture</filename>
+                                Use the pull-down "Target Architecture"
                                 menu to make your selection.
                                 The pull-down menu should have the
                                 supported architectures.
@@ -730,10 +776,10 @@
                                 If you are using the emulator, you also
                                 need to locate the kernel and specify any
                                 custom options.</para>
-                                <para>If you selected the
-                                <filename>Build system derived toolchain</filename>,
-                                the target kernel you built will be located
-                                in the
+
+                                <para>If you selected the Build system derived
+                                toolchain, the target kernel you built will be
+                                located in the
                                 <ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink>
                                 in
                                 <filename>tmp/deploy/images/<replaceable>machine</replaceable></filename>
@@ -745,11 +791,13 @@
                                 Directory path followed by the image (e.g.
                                 <filename>/home/scottrif/poky/build/tmp/deploy/images/qemux86/bzImage-qemux86.bin</filename>).
                                 </para>
+
                                 <para>If you selected the standalone
                                 pre-built toolchain, the pre-built image
                                 you downloaded is located in the directory
                                 you specified when you downloaded the
                                 image.</para>
+
                                 <para>Most custom options are for advanced
                                 QEMU users to further customize their QEMU
                                 instance.
@@ -768,23 +816,22 @@
                                 The following is an example:
                                <literallayout class='monospaced'>
     serial ‘&lt;-m 256 -full-screen&gt;’
-                                </literallayout></para>
-                                <para>
+                                </literallayout>
                                 Regardless of the mode, Sysroot is already
                                 defined as part of the Cross-Compiler
-                                Options configuration in the
-                                <filename>Sysroot Location:</filename>
-                                field.
+                                Options configuration in the "Sysroot
+                                Location:" field.
                                 </para></listitem>
                             <listitem><para>
                                 <emphasis>External HW:</emphasis>
                                 Select this option if you will be using
-                                actual hardware.</para></listitem>
+                                actual hardware.
+                                </para></listitem>
                         </itemizedlist>
                     </para>
 
                     <para>
-                        Click the "Apply" and "OK" to save your plug-in
+                        Click "Apply and Close" to save your plug-in
                         configurations.
                     </para>
                 </section>
@@ -822,19 +869,17 @@
                         click "Next".
                         </para></listitem>
                     <listitem><para>
-                        Expand
-                        <filename>Yocto Project SDK Autotools Project</filename>.
+                        Expand "Yocto Project SDK Autotools Project".
                         </para></listitem>
                     <listitem><para>
-                        Select <filename>Hello World ANSI C Autotools Projects</filename>.
+                        Select "Hello World ANSI C Autotools Projects".
                         This is an Autotools-based project based on a Yocto
                         template.
                         </para></listitem>
                     <listitem><para>
-                        Put a name in the
-                        <filename>Project name:</filename> field.
+                        Put a name in the "Project name:" field.
                         Do not use hyphens as part of the name
-                        (e.g. <filename>hello</filename>).
+                        (e.g. "hello").
                         </para></listitem>
                     <listitem><para>
                         Click "Next".
@@ -886,21 +931,15 @@
                         </para></listitem>
                     <listitem><para>
                         Make or verify your configurations for the
-                        project and click "OK".
+                        project and click "Apply and Close".
                         </para></listitem>
                     <listitem><para>
-                        Right-click in the navigation pane and
-                        select "Reconfigure Project" from the pop-up menu.
+                        Right-click in the navigation pane and select
+                        "Reconfigure Project" from the pop-up menu.
                         This selection reconfigures the project by running
-                        <filename>autogen.sh</filename> in the workspace
-                        for your project.
-                        The script also runs
-                        <filename>libtoolize</filename>,
-                        <filename>aclocal</filename>,
-                        <filename>autoconf</filename>,
-                        <filename>autoheader</filename>,
-                        <filename>automake --a</filename>, and
-                        <filename>./configure</filename>.
+                        <ulink url='https://en.wikipedia.org/wiki/GNU_Build_System'>Autotools GNU utility programs</ulink>
+                        such as Autoconf, Automake, and so forth in the
+                        workspace for your project.
                         Click on the "Console" tab beneath your source code
                         to see the results of reconfiguring your project.
                         </para></listitem>
@@ -914,7 +953,8 @@
                 To build the project select "Build All" from the
                 "Project" menu.
                 The console should update and you can note the
-                cross-compiler you are using.
+                cross-compiler you are using (i.e.
+                <filename>i586-poky-linux-gcc</filename> in this example).
                 <note>
                     When building "Yocto Project SDK Autotools" projects,
                     the Eclipse IDE might display error messages for
@@ -930,12 +970,12 @@
                             Select the project.
                             </para></listitem>
                         <listitem><para>
-                            Select "Folder" from the
-                            <filename>File > New</filename> menu.
+                            Select "Folder" from the "File -> New" menu.
                             </para></listitem>
                         <listitem><para>
-                            In the "New Folder" Dialog, select "Link to
-                            alternate location (linked folder)".
+                            In the "New Folder" Dialog, click the "Advanced"
+                            button and then activate "Link to
+                            alternate location (linked folder)" button.
                             </para></listitem>
                         <listitem><para>
                             Click "Browse" to navigate to the include
@@ -943,9 +983,6 @@
                             selected in the Yocto Project
                             configuration preferences.
                             </para></listitem>
-                        <listitem><para>
-                            Click "OK".
-                            </para></listitem>
                         <listitem><para>
                             Click "Finish" to save the linked folder.
                             </para></listitem>
@@ -988,8 +1025,8 @@
                             <filename>rpcbind</filename>, follow the
                             suggestions to get the service running.
                             As an example, on a new Ubuntu 16.04 LTS
-                            installation, you must do the following in
-                            order to get QEMU to launch:
+                            installation, you must do the following in a new
+                            shell in order to get QEMU to launch:
                             <literallayout class='monospaced'>
      $ sudo apt-get install rpcbind
                             </literallayout>
@@ -1073,7 +1110,7 @@
                         </para></listitem>
                     <listitem><para>
                         In the left area, expand
-                        <filename>C/C++Remote Application</filename>.
+                        "C/C++Remote Application".
                         </para></listitem>
                     <listitem><para>
                         Locate your project and select it to bring
@@ -1092,7 +1129,7 @@
                     <listitem><para>
                         Create a new connection to the QEMU instance
                         by clicking on "new".</para></listitem>
-                    <listitem><para>Select <filename>SSH</filename>, which
+                    <listitem><para>Select "SSH", which
                         means Secure Socket Shell and then click "OK".
                         Optionally, you can select a TCF connection
                         instead.
@@ -1104,11 +1141,10 @@
                     <listitem><para>
                         Put the IP address for the connection in
                         the "Host" field.
-                        For QEMU, the default is
-                        <filename>192.168.7.2</filename>.
+                        For QEMU, the default is "192.168.7.2".
                         However, if a previous QEMU session did not exit
                         cleanly, the IP address increments (e.g.
-                        <filename>192.168.7.3</filename>).
+                        "192.168.7.3").
                         <note>
                             You can find the IP address for the current
                             QEMU session by looking in the xterm that
@@ -1116,7 +1152,7 @@
                         </note>
                         </para></listitem>
                     <listitem><para>
-                        Enter <filename>root</filename>, which
+                        Enter "root", which
                         is the default for QEMU, for the "User" field.
                         Be sure to leave the password field empty.
                         </para></listitem>

documentation/sdk-manual/sdk-extensible.xml

@@ -359,7 +359,7 @@
                                 corresponding append file in the workspace.
                                 If you do not provide
                                 <replaceable>recipe</replaceable>, the command
-                                attempts to figure out the recipe name.
+                                makes an attempt to determine the recipe name.
                                 </para></listitem>
                             <listitem><para>
                                 <emphasis>Middle</emphasis>:
@@ -420,7 +420,7 @@
                                 <para>Because the extracted source code already
                                 exists, <filename>devtool</filename> does not
                                 try to relocate the source code into the
-                                workspace - only the new the recipe is placed
+                                workspace - only the new recipe is placed
                                 in the workspace.</para>
 
                                 <para>Aside from a recipe folder, the command
@@ -708,9 +708,25 @@
                         your source code modifications.
                         </para></listitem>
                     <listitem><para>
-                        <emphasis>Build the Recipe</emphasis>:
-                        Once you have updated the source files, you can build
-                        the recipe.
+                        <emphasis>Build the Recipe or Rebuild the Image</emphasis>:
+                        The next step you take depends on what you are going
+                        to do with the new code.</para>
+
+                        <para>If you need to eventually move the build output
+                        to the target hardware, use the following
+                        <filename>devtool</filename> command:
+                        <literallayout class='monospaced'>
+     $ devtool build <replaceable>recipe</replaceable>
+                        </literallayout></para>
+
+                        <para>On the other hand, if you want an image to
+                        contain the recipe's packages from the workspace
+                        for immediate deployment onto a device (e.g. for
+                        testing purposes), you can use
+                        the <filename>devtool build-image</filename> command:
+                        <literallayout class='monospaced'>
+     $ devtool build-image <replaceable>image</replaceable>
+                        </literallayout>
                         </para></listitem>
                     <listitem><para>
                         <emphasis>Deploy the Build Output</emphasis>:
@@ -800,7 +816,7 @@
                 workflow to make sure your recipes you are using for builds
                 are up-to-date with their upstream counterparts.
                 <note>
-                    Several methods exist by which you can upgrade recipes.
+                    Several methods exist by which you can upgrade recipes -
                     <filename>devtool upgrade</filename> happens to be one.
                     You can read about all the methods by which you can
                     upgrade recipes in the
@@ -819,12 +835,8 @@
             </para>
 
             <para>
-                Depending on your particular scenario, the arguments and
-                options you use with <filename>devtool upgrade</filename> form
-                different combinations.
-                The following diagram shows a common development flow
-                you would use with the <filename>devtool upgrade</filename>
-                command:
+                The following diagram shows the common development flow
+                used with the <filename>devtool upgrade</filename> command:
             </para>
 
             <para>
@@ -835,19 +847,18 @@
                 <orderedlist>
                     <listitem><para>
                         <emphasis>Initiate the Upgrade</emphasis>:
-                        The top part of the flow shows a typical scenario by
-                        which you could use
-                        <filename>devtool upgrade</filename>.
+                        The top part of the flow shows the typical scenario by
+                        which you use the <filename>devtool upgrade</filename>
+                        command.
                         The following conditions exist:
                         <itemizedlist>
                             <listitem><para>
-                                The recipe exists in some layer external
+                                The recipe exists in a local layer external
                                 to the <filename>devtool</filename> workspace.
                                 </para></listitem>
                             <listitem><para>
                                 The source files for the new release
-                                exist adjacent to the same location pointed to
-                                by
+                                exist in the same location pointed to by
                                 <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
                                 in the recipe (e.g. a tarball with the new
                                 version number in the name, or as a different
@@ -888,19 +899,19 @@
                         <para>Once <filename>devtool</filename> locates the
                         recipe, it uses the <filename>SRC_URI</filename>
                         variable to locate the source code and any local patch
-                        files from other developers are located.
+                        files from other developers.
                         The result is that the command sets up the source
                         code, the new version of the recipe, and an append file
                         all within the workspace.
                         </para></listitem>
-                    <listitem><para><emphasis>
-                        Resolve any Conflicts created by the Upgrade</emphasis>:
-                        At this point, conflicts could exist due to the
-                        software being upgraded to a new version.
+                    <listitem><para>
+                        <emphasis>Resolve any Conflicts created by the Upgrade</emphasis>:
+                        Conflicts could exist due to the software being
+                        upgraded to a new version.
                         Conflicts occur if your recipe specifies some patch
                         files in <filename>SRC_URI</filename> that conflict
                         with changes made in the new version of the software.
-                        If this is the case, you need to resolve the conflicts
+                        For such cases, you need to resolve the conflicts
                         by editing the source and following the normal
                         <filename>git rebase</filename> conflict resolution
                         process.</para>
@@ -910,13 +921,25 @@
                         newer or different version of the software.
                         </para></listitem>
                     <listitem><para>
-                        <emphasis>Build the Recipe</emphasis>:
-                        Once you have your recipe in order, you can build it.
-                        You can either use <filename>devtool build</filename>
-                        or <filename>bitbake</filename>.
-                        Either method produces build output that is stored
-                        in
-                        <ulink url='&YOCTO_DOCS_REF_URL;#var-TMPDIR'><filename>TMPDIR</filename></ulink>.
+                        <emphasis>Build the Recipe or Rebuild the Image</emphasis>:
+                        The next step you take depends on what you are going
+                        to do with the new code.</para>
+
+                        <para>If you need to eventually move the build output
+                        to the target hardware, use the following
+                        <filename>devtool</filename> command:
+                        <literallayout class='monospaced'>
+     $ devtool build <replaceable>recipe</replaceable>
+                        </literallayout></para>
+
+                        <para>On the other hand, if you want an image to
+                        contain the recipe's packages from the workspace
+                        for immediate deployment onto a device (e.g. for
+                        testing purposes), you can use
+                        the <filename>devtool build-image</filename> command:
+                        <literallayout class='monospaced'>
+     $ devtool build-image <replaceable>image</replaceable>
+                        </literallayout>
                         </para></listitem>
                     <listitem><para>
                         <emphasis>Deploy the Build Output</emphasis>:
@@ -992,8 +1015,8 @@
         <title>A Closer Look at <filename>devtool add</filename></title>
 
         <para>
-            The <filename>devtool add</filename> command automatically creates a
-            recipe based on the source tree with which you provide it.
+            The <filename>devtool add</filename> command automatically creates
+            a recipe based on the source tree you provide with the command.
             Currently, the command has support for the following:
             <itemizedlist>
                 <listitem><para>
@@ -1039,8 +1062,8 @@
                 In most cases, you need to edit the automatically generated
                 recipe in order to make it build properly.
                 Typically, you would go through several edit and build cycles
-                until you can build the recipe.
-                Once the recipe can be built, you could use possible further
+                until the recipe successfully builds.
+                Once the recipe builds, you could use possible further
                 iterations to test the recipe on the target device.
             </note>
         </para>
@@ -1055,15 +1078,19 @@
 
             <para>
                 If you do not specify a name and version on the command
-                line, <filename>devtool add</filename> attempts to determine
-                the name and version of the software being built from
-                various metadata within the source tree.
-                Furthermore, the command sets the name of the created recipe
-                file accordingly.
-                If the name or version cannot be determined, the
-                <filename>devtool add</filename> command prints an error and
-                you must re-run the command with both the name and version
-                or just the name or version specified.
+                line, <filename>devtool add</filename> uses various metadata
+                within the source tree in an attempt to determine
+                the name and version of the software being built.
+                Based on what the tool determines, <filename>devtool</filename>
+                sets the name of the created recipe file accordingly.
+            </para>
+
+            <para>
+                If <filename>devtool</filename> cannot determine the name and
+                version, the command prints an error.
+                For such cases, you must re-run the command and provide
+                the name and version, just the name, or just the version as
+                part of the command line.
             </para>
 
             <para>
@@ -1087,26 +1114,27 @@
                 detect build-time dependencies and map them to other recipes
                 in the system.
                 During this mapping, the command fills in the names of those
-                recipes in the
+                recipes as part of the
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-DEPENDS'><filename>DEPENDS</filename></ulink>
-                value within the recipe.
-                If a dependency cannot be mapped, then a comment is placed in
-                the recipe indicating such.
-                The inability to map a dependency might be caused because the
-                naming is not recognized or because the dependency simply is
-                not available.
+                variable within the recipe.
+                If a dependency cannot be mapped, <filename>devtool</filename>
+                places a comment in the recipe indicating such.
+                The inability to map a dependency can result from naming not
+                being recognized or because the dependency simply is not
+                available.
                 For cases where the dependency is not available, you must use
                 the <filename>devtool add</filename> command to add an
-                additional recipe to satisfy the dependency and then come
-                back to the first recipe and add its name to
-                <filename>DEPENDS</filename>.
+                additional recipe that satisfies the dependency.
+                Once you add that recipe, you need to update the
+                <filename>DEPENDS</filename> variable in the original recipe
+                to include the new recipe.
             </para>
 
             <para>
                 If you need to add runtime dependencies, you can do so by
                 adding the following to your recipe:
                 <literallayout class='monospaced'>
-     RDEPENDS_${PN} += "dependency1 dependency2 ..."
+     RDEPENDS_${PN} += "<replaceable>dependency1 dependency2 ...</replaceable>"
                 </literallayout>
                 <note>
                     The <filename>devtool add</filename> command often cannot
@@ -1117,7 +1145,7 @@
                     script for the software the recipe is building for further
                     details.
                     In some cases, you might find you can substitute the
-                    dependency for an option to disable the associated
+                    dependency with an option that disables the associated
                     functionality passed to the configure script.
                 </note>
             </para>
@@ -1129,20 +1157,24 @@
             <para>
                 The <filename>devtool add</filename> command attempts to
                 determine if the software you are adding is able to be
-                distributed under a common open-source license and sets the
+                distributed under a common, open-source license.
+                If so, the command sets the
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-LICENSE'><filename>LICENSE</filename></ulink>
                 value accordingly.
-                You should double-check this value against the documentation
-                or source files for the software you are building and update
-                that <filename>LICENSE</filename> value if necessary.
+                You should double-check the value added by the command against
+                the documentation or source files for the software you are
+                building and, if necessary, update that
+                <filename>LICENSE</filename> value.
             </para>
 
             <para>
                 The <filename>devtool add</filename> command also sets the
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-LIC_FILES_CHKSUM'><filename>LIC_FILES_CHKSUM</filename></ulink>
                 value to point to all files that appear to be license-related.
-                However, license statements often appear in comments at the top
-                of source files or within documentation.
+                Realize that license statements often appear in comments at
+                the top of source files or within the documentation.
+                In such cases, the command does not recognize those license
+                statements.
                 Consequently, you might need to amend the
                 <filename>LIC_FILES_CHKSUM</filename> variable to point to one
                 or more of those comments if present.
@@ -1156,14 +1188,13 @@
 
             <para>
                 If the <filename>devtool add</filename> command cannot
-                determine licensing information, the
-                <filename>LICENSE</filename> value is set to "CLOSED" and the
-                <filename>LIC_FILES_CHKSUM</filename> value remains unset.
-                This behavior allows you to continue with development but is
-                unlikely to be correct in all cases.
-                Consequently, you should check the documentation or source
-                files for the software you are building to determine the actual
-                license.
+                determine licensing information, <filename>devtool</filename>
+                sets the <filename>LICENSE</filename> value to "CLOSED" and
+                leaves the <filename>LIC_FILES_CHKSUM</filename> value unset.
+                This behavior allows you to continue with development even
+                though the settings are unlikely to be correct in all cases.
+                You should check the documentation or source files for the
+                software you are building to determine the actual license.
             </para>
         </section>
 
@@ -1171,8 +1202,8 @@
             <title>Adding Makefile-Only Software</title>
 
             <para>
-                The use of <filename>make</filename> by itself is very common
-                in both proprietary and open source software.
+                The use of Make by itself is very common in both proprietary
+                and open-source software.
                 Unfortunately, Makefiles are often not written with
                 cross-compilation in mind.
                 Thus, <filename>devtool add</filename> often cannot do very
@@ -1185,7 +1216,7 @@
                 <filename>gcc</filename> is the compiler for the build host
                 and the cross-compiler is named something similar to
                 <filename>arm-poky-linux-gnueabi-gcc</filename> and might
-                require some arguments (e.g. to point to the associated sysroot
+                require arguments (e.g. to point to the associated sysroot
                 for the target machine).
             </para>
 
@@ -1200,18 +1231,17 @@
                         <filename>g++</filename>.
                         </para></listitem>
                     <listitem><para>
-                        The environment in which <filename>make</filename> runs
-                        is set up with various standard variables for
-                        compilation (e.g. <filename>CC</filename>,
-                        <filename>CXX</filename>, and so forth) in a similar
-                        manner to the environment set up by the SDK's
-                        environment setup script.
+                        The environment in which Make runs is set up with
+                        various standard variables for compilation (e.g.
+                        <filename>CC</filename>, <filename>CXX</filename>, and
+                        so forth) in a similar manner to the environment set
+                        up by the SDK's environment setup script.
                         One easy way to see these variables is to run the
                         <filename>devtool build</filename> command on the
                         recipe and then look in
                         <filename>oe-logs/run.do_compile</filename>.
-                        Towards the top of this file you will see a list of
-                        environment variables that are being set.
+                        Towards the top of this file, a list of environment
+                        variables exists that are being set.
                         You can take advantage of these variables within the
                         Makefile.
                         </para></listitem>
@@ -1219,7 +1249,7 @@
                         If the Makefile sets a default for a variable using "=",
                         that default overrides the value set in the environment,
                         which is usually not desirable.
-                        In this situation, you can either patch the Makefile
+                        For this case, you can either patch the Makefile
                         so it sets the default using the "?=" operator, or
                         you can alternatively force the value on the
                         <filename>make</filename> command line.
@@ -1244,16 +1274,17 @@
                         This is particularly true because those hardcoded paths
                         often point to locations on the build host and thus
                         will either be read-only or will introduce
-                        contamination into the cross-compilation by virtue of
-                        being specific to the build host rather than the target.
+                        contamination into the cross-compilation because they
+                        are specific to the build host rather than the target.
                         Patching the Makefile to use prefix variables or other
-                        path variables is usually the way to handle this.
+                        path variables is usually the way to handle this
+                        situation.
                         </para></listitem>
                     <listitem><para>
                         Sometimes a Makefile runs target-specific commands such
                         as <filename>ldconfig</filename>.
-                        For such cases, you might be able to simply apply
-                        patches that remove these commands from the Makefile.
+                        For such cases, you might be able to apply patches that
+                        remove these commands from the Makefile.
                         </para></listitem>
                 </itemizedlist>
             </para>
@@ -1264,9 +1295,11 @@
 
             <para>
                 Often, you need to build additional tools that run on the
-                build host system as opposed to the target.
-                You should indicate this using one of the following methods
-                when you run <filename>devtool add</filename>:
+                <ulink url='&YOCTO_DOCS_REF_URL;#hardware-build-system-term'>build host</ulink>
+                as opposed to the target.
+                You should indicate this requirement by using one of the
+                following methods when you run
+                <filename>devtool add</filename>:
                 <itemizedlist>
                     <listitem><para>
                         Specify the name of the recipe such that it ends
@@ -1288,8 +1321,8 @@
                     typically accomplish this by building the native and target
                     parts separately rather than within the same compilation
                     process.
-                    Realize though that with the "&dash;&dash;also-native" option, you
-                    can add the tool using just one recipe file.
+                    Realize though that with the "&dash;&dash;also-native"
+                    option, you can add the tool using just one recipe file.
                 </note>
             </para>
         </section>
@@ -1330,11 +1363,9 @@
                             found" errors.
                             </para></listitem>
                         <listitem><para>
-                            In order to support adding
-                            Node.js modules, a
-                            <filename>nodejs</filename> recipe must be part of your
-                            SDK in order to provide Node.js
-                            itself.
+                            In order to support adding Node.js modules, a
+                            <filename>nodejs</filename> recipe must be part
+                            of your SDK.
                             </para></listitem>
                     </itemizedlist>
                 </note>
@@ -1343,14 +1374,15 @@
             <para>
                 As mentioned earlier, you can also add Node.js modules
                 directly from a repository or local source tree.
-                To add modules this way, use <filename>devtool add</filename> in
-                the following form:
+                To add modules this way, use <filename>devtool add</filename>
+                in the following form:
                 <literallayout class='monospaced'>
      $ devtool add https://github.com/diversario/node-ssdp
                 </literallayout>
-                In this example, <filename>devtool</filename> fetches the specified
-                Git repository, detects that the code is Node.js code, fetches
-                dependencies using <filename>npm</filename>, and sets
+                In this example, <filename>devtool</filename> fetches the
+                specified Git repository, detects the code as Node.js
+                code, fetches dependencies using <filename>npm</filename>, and
+                sets
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
                 accordingly.
             </para>
@@ -1361,8 +1393,9 @@
         <title>Working With Recipes</title>
 
         <para>
-            When building a recipe with <filename>devtool build</filename>, the
-            typical build progression is as follows:
+            When building a recipe using the
+            <filename>devtool build</filename> command, the typical build
+            progresses as follows:
             <orderedlist>
                 <listitem><para>
                     Fetch the source
@@ -1374,7 +1407,7 @@
                     Configure the source
                     </para></listitem>
                 <listitem><para>
-                    Compiling the source
+                    Compile the source
                     </para></listitem>
                 <listitem><para>
                     Install the build output
@@ -1385,10 +1418,13 @@
             </orderedlist>
             For recipes in the workspace, fetching and unpacking is disabled
             as the source tree has already been prepared and is persistent.
-            Each of these build steps is defined as a function, usually with a
-            "do_" prefix.
-            These functions are typically shell scripts but can instead be written
-            in Python.
+            Each of these build steps is defined as a function (task), usually
+            with a "do_" prefix (e.g.
+            <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-fetch'><filename>do_fetch</filename></ulink>,
+            <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-unpack'><filename>do_unpack</filename></ulink>,
+            and so forth).
+            These functions are typically shell scripts but can instead be
+            written in Python.
         </para>
 
         <para>
@@ -1396,12 +1432,13 @@
             recipe does not include complete instructions for building the
             software.
             Instead, common functionality is encapsulated in classes inherited
-            with the <filename>inherit</filename> directive, leaving the recipe
-            to describe just the things that are specific to the software to be
-            built.
-            A <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-base'><filename>base</filename></ulink>
-            class exists that is implicitly inherited by all recipes and provides
-            the functionality that most typical recipes need.
+            with the <filename>inherit</filename> directive.
+            This technique leaves the recipe to describe just the things that
+            are specific to the software being built.
+            A
+            <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-base'><filename>base</filename></ulink>
+            class exists that is implicitly inherited by all recipes and
+            provides the functionality that most recipes typically need.
         </para>
 
         <para>
@@ -1413,46 +1450,57 @@
             <title>Finding Logs and Work Files</title>
 
             <para>
-                When you are debugging a recipe that you previously created using
-                <filename>devtool add</filename> or whose source you are modifying
-                by using the <filename>devtool modify</filename> command, after
-                the first run of <filename>devtool build</filename>, you will
-                find some symbolic links created within the source tree:
-                <filename>oe-logs</filename>, which points to the directory in
-                which log files and run scripts for each build step are created
-                and <filename>oe-workdir</filename>, which points to the temporary
-                work area for the recipe.
-                You can use these links to get more information on what is
-                happening at each build step.
-            </para>
-
-            <para>
-                These locations under <filename>oe-workdir</filename> are
-                particularly useful:
+                After the first run of the <filename>devtool build</filename>
+                command, recipes that were previously created using the
+                <filename>devtool add</filename> command or whose sources were
+                modified using the <filename>devtool modify</filename>
+                command contain symbolic links created within the source tree:
                 <itemizedlist>
-                    <listitem><para><filename>image/</filename>:
-                        Contains all of the files installed at the
-                        <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-install'><filename>do_install</filename></ulink>
-                        stage.
-                        Within a recipe, this directory is referred to by the
-                        expression
-                        <filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-D'><filename>D</filename></ulink><filename>}</filename>.
+                    <listitem><para>
+                        <filename>oe-logs</filename>:
+                        This link points to the directory in which log files
+                        and run scripts for each build step are created.
                         </para></listitem>
-                    <listitem><para><filename>sysroot-destdir/</filename>:
-                        Contains a subset of files installed within
-                        <filename>do_install</filename> that have been put into the
-                        shared sysroot.
-                        For more information, see the
-                        "<link linkend='sdk-sharing-files-between-recipes'>Sharing Files Between Recipes</link>"
-                        section.
-                        </para></listitem>
-                    <listitem><para><filename>packages-split/</filename>:
-                        Contains subdirectories for each package produced by the
+                    <listitem><para>
+                        <filename>oe-workdir</filename>:
+                        This link points to the temporary work area for the
                         recipe.
-                        For more information, see the
-                        "<link linkend='sdk-packaging'>Packaging</link>" section.
+                        The following locations under
+                        <filename>oe-workdir</filename> are particularly
+                        useful:
+                            <itemizedlist>
+                                <listitem><para>
+                                    <filename>image/</filename>:
+                                    Contains all of the files installed during
+                                    the
+                                    <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-install'><filename>do_install</filename></ulink>
+                                    stage.
+                                    Within a recipe, this directory is referred
+                                    to by the expression
+                                    <filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-D'><filename>D</filename></ulink><filename>}</filename>.
+                                    </para></listitem>
+                                <listitem><para>
+                                    <filename>sysroot-destdir/</filename>:
+                                    Contains a subset of files installed within
+                                    <filename>do_install</filename> that have
+                                    been put into the shared sysroot.
+                                    For more information, see the
+                                    "<link linkend='sdk-sharing-files-between-recipes'>Sharing Files Between Recipes</link>"
+                                    section.
+                                    </para></listitem>
+                                <listitem><para>
+                                    <filename>packages-split/</filename>:
+                                    Contains subdirectories for each package
+                                    produced by the recipe.
+                                    For more information, see the
+                                    "<link linkend='sdk-packaging'>Packaging</link>"
+                                    section.
+                                    </para></listitem>
+                            </itemizedlist>
                         </para></listitem>
                 </itemizedlist>
+                You can use these links to get more information on what is
+                happening at each build step.
             </para>
         </section>
 
@@ -1499,12 +1547,14 @@
 
             <para>
                 Recipes often need to use files provided by other recipes on
-                the build host.
+                the
+                <ulink url='&YOCTO_DOCS_REF_URL;#hardware-build-system-term'>build host</ulink>.
                 For example, an application linking to a common library needs
                 access to the library itself and its associated headers.
                 The way this access is accomplished within the extensible SDK is
                 through the sysroot.
-                One sysroot exists per "machine" for which the SDK is being built.
+                One sysroot exists per "machine" for which the SDK is being
+                built.
                 In practical terms, this means a sysroot exists for the target
                 machine, and a sysroot exists for the build host.
             </para>
@@ -1517,7 +1567,7 @@
                 task within the
                 <filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-D'><filename>D</filename></ulink><filename>}</filename>
                 directory.
-                A subset of these files automatically go into the sysroot.
+                A subset of these files automatically goes into the sysroot.
                 The reason for this limitation is that almost all files that go
                 into the sysroot are cataloged in manifests in order to ensure
                 they can be removed later when a recipe is modified or removed.
@@ -1542,20 +1592,20 @@
                 <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-package'><filename>do_package</filename></ulink>
                 task, files installed during the
                 <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-install'><filename>do_install</filename></ulink>
-                task are split into one main package, which is almost always named
-                the same as the recipe, and several other packages.
-                This separation is done because not all of those installed files
-                are always useful in every image.
+                task are split into one main package, which is almost always
+                named the same as the recipe, and into several other packages.
+                This separation exists because not all of those installed files
+                are useful in every image.
                 For example, you probably do not need any of the documentation
                 installed in a production image.
-                Consequently, for each recipe the documentation files are separated
-                into a <filename>-doc</filename> package.
-                Recipes that package software that has optional modules or
-                plugins might do additional package splitting as well.
+                Consequently, for each recipe the documentation files are
+                separated into a <filename>-doc</filename> package.
+                Recipes that package software containing optional modules or
+                plugins might undergo additional package splitting as well.
             </para>
 
             <para>
-                After building a recipe you can see where files have gone by
+                After building a recipe, you can see where files have gone by
                 looking in the <filename>oe-workdir/packages-split</filename>
                 directory, which contains a subdirectory for each package.
                 Apart from some advanced cases, the
@@ -1565,17 +1615,18 @@
                 variables controls splitting.
                 The <filename>PACKAGES</filename> variable lists all of the
                 packages to be produced, while the <filename>FILES</filename>
-                variable specifies which files to include in each package,
+                variable specifies which files to include in each package by
                 using an override to specify the package.
-                For example, <filename>FILES_${PN}</filename> specifies the files
-                to go into the main package (i.e. the main package is named the
-                same as the recipe and
+                For example, <filename>FILES_${PN}</filename> specifies the
+                files to go into the main package (i.e. the main package has
+                the same name as the recipe and
                 <filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PN'><filename>PN</filename></ulink><filename>}</filename>
                 evaluates to the recipe name).
-                The order of the <filename>PACKAGES</filename> value is significant.
+                The order of the <filename>PACKAGES</filename> value is
+                significant.
                 For each installed file, the first package whose
-                <filename>FILES</filename> value matches the file is the package
-                into which the file goes.
+                <filename>FILES</filename> value matches the file is the
+                package into which the file goes.
                 Defaults exist for both the <filename>PACKAGES</filename> and
                 <filename>FILES</filename> variables.
                 Consequently, you might find you do not even need to set these
@@ -1597,29 +1648,29 @@
             <filename>devtool deploy-target</filename> command.
             Because the <filename>devtool deploy-target</filename> command
             backs up any files it overwrites, you can use the
-            <filename>devtool undeploy-target</filename> to restore those files
-            and remove any other files the recipe deployed.
+            <filename>devtool undeploy-target</filename> command to restore
+            those files and remove any other files the recipe deployed.
             Consider the following example:
             <literallayout class='monospaced'>
      $ devtool undeploy-target lighttpd root@192.168.7.2
             </literallayout>
             If you have deployed multiple applications, you can remove them
-            all at once thus restoring the target device back to its
+            all using the "-a" option thus restoring the target device to its
             original state:
             <literallayout class='monospaced'>
      $ devtool undeploy-target -a root@192.168.7.2
             </literallayout>
             Information about files deployed to the target as well as any
             backed up files are stored on the target itself.
-            This storage of course requires some additional space
+            This storage, of course, requires some additional space
             on the target machine.
             <note>
                 The <filename>devtool deploy-target</filename> and
-                <filename>devtool undeploy-target</filename> command do not
+                <filename>devtool undeploy-target</filename> commands do not
                 currently interact with any package management system on the
                 target device (e.g. RPM or OPKG).
-                Consequently, you should not intermingle operations
-                <filename>devtool deploy-target</filename> and the package
+                Consequently, you should not intermingle
+                <filename>devtool deploy-target</filename> and package
                 manager operations on the target device.
                 Doing so could result in a conflicting set of files.
             </note>
@@ -1630,16 +1681,14 @@
         <title>Installing Additional Items Into the Extensible SDK</title>
 
         <para>
-            The extensible SDK typically only comes with a small number of tools
-            and libraries out of the box.
-            If you have a minimal SDK, then it starts mostly empty and is
-            populated on-demand.
-            However, sometimes you will need to explicitly install extra items
-            into the SDK.
+            Out of the box the extensible SDK typically only comes with a small
+            number of tools and libraries.
+            A minimal SDK starts mostly empty and is populated on-demand.
+            Sometimes you must explicitly install extra items into the SDK.
             If you need these extra items, you can first search for the items
             using the <filename>devtool search</filename> command.
             For example, suppose you need to link to libGL but you are not sure
-            which recipe provides it.
+            which recipe provides libGL.
             You can use the following command to find out:
             <literallayout class='monospaced'>
      $ devtool search libGL
@@ -1650,17 +1699,19 @@
             <literallayout class='monospaced'>
      $ devtool sdk-install mesa
             </literallayout>
-            By default, the <filename>devtool sdk-install</filename> assumes the
-            item is available in pre-built form from your SDK provider.
+            By default, the <filename>devtool sdk-install</filename> command
+            assumes the item is available in pre-built form from your SDK
+            provider.
             If the item is not available and it is acceptable to build the item
             from source, you can add the "-s" option as follows:
             <literallayout class='monospaced'>
      $ devtool sdk-install -s mesa
             </literallayout>
-            It is important to remember that building the item from source takes
-            significantly longer than installing the pre-built artifact.
-            Also, if no recipe exists for the item you want to add to the SDK, you
-            must instead add it using the <filename>devtool add</filename> command.
+            It is important to remember that building the item from source
+            takes significantly longer than installing the pre-built artifact.
+            Also, if no recipe exists for the item you want to add to the SDK,
+            you must instead add the item using the
+            <filename>devtool add</filename> command.
         </para>
     </section>
 
@@ -1698,31 +1749,34 @@
 
         <para>
             You might need to produce an SDK that contains your own custom
-            libraries for sending to a third party (e.g., if you are a vendor with
-            customers needing to build their own software for the target platform).
-            If that is the case, then you can produce a derivative SDK based on
-            the currently installed SDK fairly easily.
-            Use these steps:
+            libraries.
+            A good example would be if you were a vendor with customers that
+            use your SDK to build their own platform-specific software and
+            those customers need an SDK that has custom libraries.
+            In such a case, you can produce a derivative SDK based on the
+            currently installed SDK fairly easily by following these steps:
             <orderedlist>
-                <listitem><para>If necessary, install an extensible SDK that
+                <listitem><para>
+                    If necessary, install an extensible SDK that
                     you want to use as a base for your derivative SDK.
                     </para></listitem>
-                <listitem><para>Source the environment script for the SDK.
+                <listitem><para>
+                    Source the environment script for the SDK.
                     </para></listitem>
-                <listitem><para>Add the extra libraries or other components
-                    you want by using the <filename>devtool add</filename>
-                    command.
+                <listitem><para>
+                    Add the extra libraries or other components you want by
+                    using the <filename>devtool add</filename> command.
                     </para></listitem>
-                <listitem><para>Run the <filename>devtool build-sdk</filename>
-                    command.
+                <listitem><para>
+                    Run the <filename>devtool build-sdk</filename> command.
                     </para></listitem>
             </orderedlist>
-            The above procedure takes the recipes added to the workspace and
-            constructs a new SDK installer containing those recipes and the
+            The previous steps take the recipes added to the workspace and
+            construct a new SDK installer that contains those recipes and the
             resulting binary artifacts.
             The recipes go into their own separate layer in the constructed
-            derivative SDK, leaving the workspace clean and ready for users
-            to add their own recipes.
+            derivative SDK, which leaves the workspace clean and ready for
+            users to add their own recipes.
         </para>
     </section>
 </chapter>

documentation/sdk-manual/sdk-using.xml

@@ -53,24 +53,24 @@
         <title>Installing the SDK</title>
 
         <para>
-            The first thing you need to do is install the SDK on your host
-            development machine by running the <filename>*.sh</filename>
-            installation script.
+            The first thing you need to do is install the SDK on your
+            <ulink url='&YOCTO_DOCS_REF_URL;#hardware-build-system-term'>Build Host</ulink>
+            by running the <filename>*.sh</filename> installation script.
         </para>
 
         <para>
             You can download a tarball installer, which includes the
             pre-built toolchain, the <filename>runqemu</filename>
-            script, and support files from the appropriate directory under
-            <ulink url='&YOCTO_TOOLCHAIN_DL_URL;'></ulink>.
-            Toolchains are available for 32-bit and 64-bit x86 development
-            systems from the <filename>i686</filename> and
-            <filename>x86_64</filename> directories, respectively.
+            script, and support files from the appropriate
+            <ulink url='&YOCTO_TOOLCHAIN_DL_URL;'>toolchain</ulink>
+            directory within the Index of Releases.
+            Toolchains are available for several 32-bit and 64-bit
+            architectures with the <filename>x86_64</filename> directories,
+            respectively.
             The toolchains the Yocto Project provides are based off the
-            <filename>core-image-sato</filename> image and contain
+            <filename>core-image-sato</filename> and
+            <filename>core-image-minimal</filename> images and contain
             libraries appropriate for developing against that image.
-            Each type of development system supports five or more target
-            architectures.
         </para>
 
         <para>
@@ -92,7 +92,7 @@
 
          <replaceable>arch</replaceable> is a string representing the tuned target architecture:
 
-                    aarch64, armv5e, core2-64, coretexah8f-neon, i586, mips32r2, mips64, or ppc7400.
+                    aarch64, armv5e, core2-64, i586, mips32r2, mips64, ppc7400, or cortexa8hf-neon.
 
          <replaceable>release_version</replaceable> is a string representing the release number of the Yocto Project:
 
@@ -121,38 +121,36 @@
 
         <para>
             The SDK and toolchains are self-contained and by default are
-            installed into <filename>/opt/poky</filename>.
-            However, when you run the SDK installer, you can choose an
-            installation directory.
-            <note>
-                You must change the permissions on the SDK
-                installer script so that it is executable:
-                <literallayout class='monospaced'>
-     $ chmod +x poky-glibc-x86_64-core-image-sato-i586-toolchain-&DISTRO;.sh
-                </literallayout>
-            </note>
+            installed into the <filename>poky_sdk</filename> folder in your
+            home directory.
+            You can choose to install the extensible SDK in any location when
+            you run the installer.
+            However, because files need to be written under that directory
+            during the normal course of operation, the location you choose
+            for installation must be writable for whichever
+            users need to use the SDK.
         </para>
 
         <para>
             The following command shows how to run the installer given a
             toolchain tarball for a 64-bit x86 development host system and
-            a 32-bit x86 target architecture.
+            a 64-bit x86 target architecture.
             The example assumes the SDK installer is located in
-            <filename>~/Downloads/</filename>.
+            <filename>~/Downloads/</filename> and has execution rights.
             <note>
                 If you do not have write permissions for the directory
                 into which you are installing the SDK, the installer
                 notifies you and exits.
-                Be sure you have write permissions in the directory and
-                run the installer again.
+                For that case, set up the proper permissions in the directory
+                and run the installer again.
             </note>
             <literallayout class='monospaced'>
-     $ ./poky-glibc-x86_64-core-image-sato-i586-toolchain-&DISTRO;.sh
+     $ ./Downloads/poky-glibc-x86_64-core-image-sato-i586-toolchain-&DISTRO;.sh
      Poky (Yocto Project Reference Distro) SDK installer version &DISTRO;
      ===============================================================
      Enter target directory for SDK (default: /opt/poky/&DISTRO;):
      You are about to install the SDK to "/opt/poky/&DISTRO;". Proceed[Y/n]? Y
-     Extracting SDK.......................................................................done
+     Extracting SDK........................................ ..............................done
      Setting it up...done
      SDK has been successfully set up and is ready to be used.
      Each time you wish to use the SDK in a new shell session, you need to source the environment setup script e.g.
@@ -173,12 +171,11 @@
 
         <para>
             Once you have the SDK installed, you must run the SDK environment
-            setup script before you can actually use it.
+            setup script before you can actually use the SDK.
             This setup script resides in the directory you chose when you
-            installed the SDK.
-            For information on where this setup script can reside, see the
-            "<link linkend='sdk-appendix-obtain'>Obtaining the SDK</link>"
-            Appendix.
+            installed the SDK, which is either the default
+            <filename>/opt/poky/&DISTRO;</filename> directory or the directory
+            you chose during installation.
         </para>
 
         <para>
@@ -187,9 +184,11 @@
             Environment setup scripts begin with the string
             "<filename>environment-setup</filename>" and include as part of
             their name the tuned target architecture.
-            For example, the command to source a setup script for an IA-based
-            target machine using i586 tuning and located in the default SDK
-            installation directory is as follows:
+            As an example, the following commands set the working directory
+            to where the SDK was installed and then source the environment
+            setup script.
+            In this example, the setup script is for an IA-based
+            target machine using i586 tuning:
             <literallayout class='monospaced'>
      $ source /opt/poky/&DISTRO;/environment-setup-i586-poky-linux
             </literallayout>

documentation/sdk-manual/sdk-working-projects.xml

@@ -19,263 +19,494 @@
         <title>Autotools-Based Projects</title>
 
         <para>
-            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.
+            Once you have a suitable
+            <ulink url='&YOCTO_DOCS_REF_URL;#cross-development-toolchain'>cross-development toolchain</ulink>
+            installed, it is very easy to develop a project using the
+            <ulink url='https://en.wikipedia.org/wiki/GNU_Build_System'>GNU Autotools-based</ulink>
+            workflow, which is outside of the
+            <ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>OpenEmbedded build system</ulink>.
         </para>
 
-        <section id='creating-and-running-a-project-based-on-gnu-autotools'>
-            <title>Creating and Running a Project Based on GNU Autotools</title>
+        <para>
+            The following figure presents a simple Autotools workflow.
+            <imagedata fileref="figures/sdk-autotools-flow.png" width="7in" height="8in" align="center" />
+        </para>
 
-            <para>
-                Follow these steps to create a simple Autotools-based project:
-                <orderedlist>
-                    <listitem><para>
-                        <emphasis>Create Your Directory:</emphasis>
-                        Create a clean directory for your project and then make
-                        that directory your working location:
-                        <literallayout class='monospaced'>
+        <para>
+            Follow these steps to create a simple Autotools-based
+            "Hello World" project:
+            <note>
+                For more information on the GNU Autotools workflow,
+                see the same example on the
+                <ulink url='https://developer.gnome.org/anjuta-build-tutorial/stable/create-autotools.html.en'>GNOME Developer</ulink>
+                site.
+            </note>
+            <orderedlist>
+                <listitem><para>
+                    <emphasis>Create a Working Directory and Populate It:</emphasis>
+                    Create a clean directory for your project and then make
+                    that directory your working location.
+                    <literallayout class='monospaced'>
      $ mkdir $HOME/helloworld
      $ cd $HOME/helloworld
-                        </literallayout>
-                        </para></listitem>
-                    <listitem><para>
-                        <emphasis>Populate the Directory:</emphasis>
-                        Create <filename>hello.c</filename>,
-                        <filename>Makefile.am</filename>,
-                        and <filename>configure.ac</filename> files as follows:
-                        <itemizedlist>
-                            <listitem><para>
-                                For <filename>hello.c</filename>, include
-                                these lines:
-                                <literallayout class='monospaced'>
+                    </literallayout>
+                    After setting up the directory, populate it with files
+                    needed for the flow.
+                    You need a project source file, a file to help with
+                    configuration, and a file to help create the Makefile,
+                    and a README file:
+                    <filename>hello.c</filename>,
+                    <filename>configure.ac</filename>,
+                    <filename>Makefile.am</filename>, and
+                    <filename>README</filename>, respectively.</para>
+
+                    <para> Use the following command to create an empty README
+                    file, which is required by GNU Coding Standards:
+                    <literallayout class='monospaced'>
+     $ touch README
+                    </literallayout>
+                    Create the remaining three files as follows:
+                    <itemizedlist>
+                        <listitem><para>
+                            <emphasis><filename>hello.c</filename>:</emphasis>
+                            <literallayout class='monospaced'>
      #include &lt;stdio.h&gt;
 
      main()
         {
            printf("Hello World!\n");
         }
-                                </literallayout>
-                                </para></listitem>
-                            <listitem><para>
-                                For <filename>Makefile.am</filename>,
-                                include these lines:
-                                <literallayout class='monospaced'>
-     bin_PROGRAMS = hello
-     hello_SOURCES = hello.c
-                                </literallayout>
-                                </para></listitem>
-                            <listitem><para>
-                                For <filename>configure.in</filename>,
-                                include these lines:
-                                <literallayout class='monospaced'>
+                            </literallayout>
+                            </para></listitem>
+                        <listitem><para>
+                            <emphasis><filename>configure.ac</filename>:</emphasis>
+                            <literallayout class='monospaced'>
      AC_INIT(hello,0.1)
      AM_INIT_AUTOMAKE([foreign])
      AC_PROG_CC
-     AC_PROG_INSTALL
-     AC_OUTPUT(Makefile)
-                                </literallayout>
-                                </para></listitem>
-                        </itemizedlist>
-                        </para></listitem>
-                    <listitem><para>
-                        <emphasis>Source the Cross-Toolchain
-                        Environment Setup File:</emphasis>
-                        As described earlier in the manual, installing the
-                        cross-toolchain creates a cross-toolchain
-                        environment setup script in the directory that the SDK
-                        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 SDK installation directory that uses the
-                        32-bit Intel x86 Architecture and the
-                        &DISTRO_NAME; Yocto Project release:
-                        <literallayout class='monospaced'>
+     AC_CONFIG_FILES(Makefile)
+     AC_OUTPUT
+                            </literallayout>
+                            </para></listitem>
+                        <listitem><para>
+                            <emphasis><filename>Makefile.am</filename>:</emphasis>
+                            <literallayout class='monospaced'>
+     bin_PROGRAMS = hello
+     hello_SOURCES = hello.c
+                            </literallayout>
+                            </para></listitem>
+                    </itemizedlist>
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis>Source the Cross-Toolchain
+                    Environment Setup File:</emphasis>
+                    As described earlier in the manual, installing the
+                    cross-toolchain creates a cross-toolchain
+                    environment setup script in the directory that the SDK
+                    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".
+                    For this example, the command sources a script from the
+                    default SDK installation directory that uses the
+                    32-bit Intel x86 Architecture and the
+                    &DISTRO_NAME; Yocto Project release:
+                    <literallayout class='monospaced'>
      $ source /opt/poky/&DISTRO;/environment-setup-i586-poky-linux
-                        </literallayout>
-                        </para></listitem>
-                    <listitem><para>
-                        <emphasis>Generate the Local <filename>aclocal.m4</filename>
-                        Files and Create the Configure Script:</emphasis>
-                        The following GNU Autotools generate the local
-                        <filename>aclocal.m4</filename> files and create the
-                        configure script:
-                        <literallayout class='monospaced'>
-     $ aclocal
-     $ autoconf
-                        </literallayout>
-                        </para></listitem>
-                    <listitem><para>
-                        <emphasis>Generate Files Needed by GNU Coding
-                        Standards:</emphasis>
-                        GNU coding standards require certain files in order
-                        for the project to be compliant.
-                        This command creates those files:
-                        <literallayout class='monospaced'>
-     $ touch NEWS README AUTHORS ChangeLog
-                        </literallayout>
-                        </para></listitem>
-                    <listitem><para>
-                        <emphasis>Generate the Configure File:</emphasis>
-                        This command generates the
-                        <filename>configure</filename>:
-                        <literallayout class='monospaced'>
-     $ automake -a
-                        </literallayout>
-                        </para></listitem>
-                    <listitem><para>
-                        <emphasis>Cross-Compile the Project:</emphasis>
-                        This command compiles the project using the
-                        cross-compiler.
-                        The
-                        <ulink url='&YOCTO_DOCS_REF_URL;#var-CONFIGURE_FLAGS'><filename>CONFIGURE_FLAGS</filename></ulink>
-                        environment variable provides the minimal arguments for
-                        GNU configure:
-                        <literallayout class='monospaced'>
+                    </literallayout>
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis>Create the <filename>configure</filename> Script:</emphasis>
+                    Use the <filename>autoreconf</filename> command to
+                    generate the <filename>configure</filename> script.
+                    <literallayout class='monospaced'>
+     $ autoreconf
+                    </literallayout>
+                    The <filename>autoreconf</filename> tool takes care
+                    of running the other Autotools such as
+                    <filename>aclocal</filename>,
+                    <filename>autoconf</filename>, and
+                    <filename>automake</filename>.
+                    <note>
+                        If you get errors from
+                        <filename>configure.ac</filename>, which
+                        <filename>autoreconf</filename> runs, that indicate
+                        missing files, you can use the "-i" option, which
+                        ensures missing auxiliary files are copied to the build
+                        host.
+                    </note>
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis>Cross-Compile the Project:</emphasis>
+                    This command compiles the project using the
+                    cross-compiler.
+                    The
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-CONFIGURE_FLAGS'><filename>CONFIGURE_FLAGS</filename></ulink>
+                    environment variable provides the minimal arguments for
+                    GNU configure:
+                    <literallayout class='monospaced'>
      $ ./configure ${CONFIGURE_FLAGS}
-                        </literallayout>
-                        </para></listitem>
-                    <listitem><para>
-                        <emphasis>Make and Install the Project:</emphasis>
-                        These two commands generate and install the project
-                        into the destination directory:
-                        <literallayout class='monospaced'>
+                    </literallayout>
+                    For an Autotools-based project, you can use the
+                    cross-toolchain by just passing the appropriate host
+                    option to <filename>configure.sh</filename>.
+                    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
+                    <filename>armv5te-poky-linux-gnueabi</filename>.
+                    You will notice that the name of the script is
+                    <filename>environment-setup-armv5te-poky-linux-gnueabi</filename>.
+                    Thus, the following command works to update your project
+                    and rebuild it using the appropriate cross-toolchain tools:
+                    <literallayout class='monospaced'>
+     $ ./configure --host=armv5te-poky-linux-gnueabi --with-libtool-sysroot=<replaceable>sysroot_dir</replaceable>
+                    </literallayout>
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis>Make and Install the Project:</emphasis>
+                    These two commands generate and install the project
+                    into the destination directory:
+                    <literallayout class='monospaced'>
      $ make
      $ make install DESTDIR=./tmp
-                        </literallayout>
-                        </para></listitem>
-                    <listitem><para>
-                        <emphasis>Verify the Installation:</emphasis>
-                        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.
-                        <literallayout class='monospaced'>
-     $ file ./tmp/usr/local/bin/hello
-                        </literallayout>
-                        </para></listitem>
-                    <listitem><para>
-                        <emphasis>Execute Your Project:</emphasis>
-                        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:
-                        <literallayout class='monospaced'>
-     $ ./hello
-                        </literallayout>
-                        As expected, the project displays the "Hello World!"
-                        message.
-                        </para></listitem>
-                </orderedlist>
-            </para>
-        </section>
-
-        <section id='passing-host-options'>
-            <title>Passing Host Options</title>
-
-            <para>
-                For an Autotools-based project, you can use the cross-toolchain
-                by just passing the appropriate host option to
-                <filename>configure.sh</filename>.
-                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 <filename>armv5te-poky-linux-gnueabi</filename>.
-                You will notice that the name of the script is
-                <filename>environment-setup-armv5te-poky-linux-gnueabi</filename>.
-                Thus, the following command works to update your project and
-                rebuild it using the appropriate cross-toolchain tools:
-                <literallayout class='monospaced'>
-     $ ./configure --host=armv5te-poky-linux-gnueabi \
-        --with-libtool-sysroot=<replaceable>sysroot_dir</replaceable>
-                </literallayout>
-                <note>
-                    If the <filename>configure</filename> script results in
-                    problems recognizing the
-                    <filename>--with-libtool-sysroot=</filename><replaceable>sysroot-dir</replaceable>
-                    option, regenerate the script to enable the support by
-                    doing the following and then run the script again:
-                    <literallayout class='monospaced'>
-     $ libtoolize --automake
-     $ aclocal -I ${OECORE_TARGET_SYSROOT}/usr/share/aclocal [-I <replaceable>dir_containing_your_project-specific_m4_macros</replaceable>]
-     $ autoconf
-     $ autoheader
-     $ automake -a
                     </literallayout>
-                </note>
-            </para>
-        </section>
+                    <note>
+                        To learn about environment variables established
+                        when you run the cross-toolchain environment setup
+                        script and how they are used or overridden when
+                        the Makefile, see the
+                        "<link linkend='makefile-based-projects'>Makefile-Based Projects</link>"
+                        section.
+                    </note>
+                    This next 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.
+                    <literallayout class='monospaced'>
+     $ file ./tmp/usr/local/bin/hello
+                    </literallayout>
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis>Execute Your Project:</emphasis>
+                    To execute the project, you would need to run it on your
+                    target hardware.
+                    If your target hardware happens to be your build host,
+                    you could run the project as follows:
+                    <literallayout class='monospaced'>
+     $ ./tmp/usr/local/bin/hello
+                    </literallayout>
+                    As expected, the project displays the "Hello World!"
+                    message.
+                    </para></listitem>
+            </orderedlist>
+        </para>
     </section>
 
     <section id='makefile-based-projects'>
         <title>Makefile-Based Projects</title>
 
         <para>
-            For Makefile-based projects, the cross-toolchain environment
-            variables established by running the cross-toolchain environment
-            setup script are subject to general <filename>make</filename>
-            rules.
+            Simple Makefile-based projects use and interact with the
+            cross-toolchain environment variables established when you run
+            the cross-toolchain environment setup script.
+            The environment variables are subject to general
+            <filename>make</filename> rules.
         </para>
 
         <para>
-            To illustrate this, consider the following four cross-toolchain
-            environment variables:
-            <literallayout class='monospaced'>
-     <ulink url='&YOCTO_DOCS_REF_URL;#var-CC'>CC</ulink>=i586-poky-linux-gcc -m32 -march=i586 --sysroot=/opt/poky/&DISTRO;/sysroots/i586-poky-linux
-     <ulink url='&YOCTO_DOCS_REF_URL;#var-LD'>LD</ulink>=i586-poky-linux-ld --sysroot=/opt/poky/&DISTRO;/sysroots/i586-poky-linux
-     <ulink url='&YOCTO_DOCS_REF_URL;#var-CFLAGS'>CFLAGS</ulink>=-O2 -pipe -g -feliminate-unused-debug-types
-     <ulink url='&YOCTO_DOCS_REF_URL;#var-CXXFLAGS'>CXXFLAGS</ulink>=-O2 -pipe -g -feliminate-unused-debug-types
-            </literallayout>
-            Now, consider the following three cases:
+            This section presents a simple Makefile development flow and
+            provides an example that lets you see how you can use
+            cross-toolchain environment variables and Makefile variables
+            during development.
+            <imagedata fileref="figures/sdk-makefile-flow.png" width="6in" height="7in" align="center" />
+        </para>
+
+        <para>
+            The main point of this section is to explain the following three
+            cases regarding variable behavior:
             <itemizedlist>
                 <listitem><para>
                     <emphasis>Case 1 - No Variables Set in the
-                    <filename>Makefile</filename>:</emphasis>
-                    Because these variables are not specifically set in the
+                    <filename>Makefile</filename> Map to Equivalent
+                    Environment Variables Set in the SDK Setup Script:</emphasis>
+                    Because matching variables are not specifically set in the
                     <filename>Makefile</filename>, the variables retain their
-                    values based on the environment.
+                    values based on the environment setup script.
                     </para></listitem>
                 <listitem><para>
-                    <emphasis>Case 2 - Variables Set in the
-                    <filename>Makefile</filename>:</emphasis>
-                    Specifically setting variables in the
+                    <emphasis>Case 2 - Variables Are Set in the Makefile that
+                    Map to Equivalent Environment Variables from the SDK
+                    Setup Script:</emphasis>
+                    Specifically setting matching variables in the
                     <filename>Makefile</filename> during the build results in
                     the environment settings of the variables being
                     overwritten.
+                    In this case, the variables you set in the
+                    <filename>Makefile</filename> are used.
                     </para></listitem>
                 <listitem><para>
-                    <emphasis>Case 3 - Variables Set when the
-                    <filename>Makefile</filename> is Executed from the
-                    Command Line:</emphasis>
+                    <emphasis>Case 3 - Variables Are Set Using the Command Line
+                    that Map to Equivalent Environment Variables from the
+                    SDK Setup Script:</emphasis>
                     Executing the <filename>Makefile</filename> from the
-                    command-line results in the variables being overwritten
-                    with command-line content regardless of what is being set
-                    in the <filename>Makefile</filename>.
-                    In this case, environment variables are not considered
-                    unless you use the "-e" flag during the build:
-                    <literallayout class='monospaced'>
-     $ make -e <replaceable>file</replaceable>
-                    </literallayout>
-                    If you use this flag, then the environment values of the
-                    variables override any variables specifically set in the
-                    <filename>Makefile</filename>.
+                    command line results in the environment variables being
+                    overwritten.
+                    In this case, the command-line content is used.
                     </para></listitem>
             </itemizedlist>
             <note>
-                For the list of variables set up by the cross-toolchain
-                environment setup script, see the
-                "<link linkend='sdk-running-the-sdk-environment-setup-script'>Running the SDK Environment Setup Script</link>"
-                section.
+                Regardless of how you set your variables, if you use
+                the "-e" option with <filename>make</filename>, the
+                variables from the SDK setup script take precedence:
+                <literallayout class='monospaced'>
+     $ make -e <replaceable>target</replaceable>
+                </literallayout>
             </note>
         </para>
+
+        <para>
+            The remainder of this section presents a simple Makefile example
+            that demonstrates these variable behaviors.
+        </para>
+
+        <para>
+            In a new shell environment variables are not established for the
+            SDK until you run the setup script.
+            For example, the following commands show a null value for the
+            compiler variable (i.e.
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-CC'><filename>CC</filename></ulink>).
+            <literallayout class='monospaced'>
+     $ echo ${CC}
+
+     $
+            </literallayout>
+            Running the SDK setup script for a 64-bit build host and an
+            i586-tuned target architecture for a
+            <filename>core-image-sato</filename> image using the current
+            &DISTRO; Yocto Project release and then echoing that variable
+            shows the value established through the script:
+            <literallayout class='monospaced'>
+     $ source /opt/poky/&DISTRO;/environment-setup-i586-poky-linux
+     $ echo ${CC}
+     i586-poky-linux-gcc -m32 -march=i586 --sysroot=/opt/poky/2.5/sysroots/i586-poky-linux
+            </literallayout>
+        </para>
+
+        <para>
+            To illustrate variable use, work through this simple "Hello World!"
+            example:
+            <orderedlist>
+                <listitem><para>
+                    <emphasis>Create a Working Directory and Populate It:</emphasis>
+                    Create a clean directory for your project and then make
+                    that directory your working location.
+                    <literallayout class='monospaced'>
+     $ mkdir $HOME/helloworld
+     $ cd $HOME/helloworld
+                    </literallayout>
+                    After setting up the directory, populate it with files
+                    needed for the flow.
+                    You need a <filename>main.c</filename> file from which you
+                    call your function, a <filename>module.h</filename> file
+                    to contain headers, and a <filename>module.c</filename>
+                    that defines your function.
+                    </para>
+
+                    <para>Create the three files as follows:
+                        <itemizedlist>
+                            <listitem><para>
+                                <emphasis><filename>main.c</filename>:</emphasis>
+                                <literallayout class='monospaced'>
+     #include "module.h"
+     void sample_func();
+     int main()
+     {
+     	sample_func();
+     	return 0;
+     }
+                                </literallayout>
+                                </para></listitem>
+                            <listitem><para>
+                                <emphasis><filename>module.h</filename>:</emphasis>
+                                <literallayout class='monospaced'>
+     #include &lt;stdio.h&gt;
+     void sample_func();
+                                </literallayout>
+                                </para></listitem>
+                            <listitem><para>
+                                <emphasis><filename>module.c</filename>:</emphasis>
+                                <literallayout class='monospaced'>
+     #include "module.h"
+     void sample_func()
+     {
+	     printf("Hello World!");
+	     printf("\n");
+     }
+                                </literallayout>
+                                </para></listitem>
+                        </itemizedlist>
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis>Source the Cross-Toolchain Environment Setup File:</emphasis>
+                    As described earlier in the manual, installing the
+                    cross-toolchain creates a cross-toolchain environment setup
+                    script in the directory that the SDK 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".
+                    For this example, the command sources a script from the
+                    default SDK installation directory that uses the
+                    32-bit Intel x86 Architecture and the
+                    &DISTRO_NAME; Yocto Project release:
+                    <literallayout class='monospaced'>
+     $ source /opt/poky/&DISTRO;/environment-setup-i586-poky-linux
+                    </literallayout>
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis>Create the <filename>Makefile</filename>:</emphasis>
+                    For this example, the Makefile contains two lines that
+                    can be used to set the <filename>CC</filename> variable.
+                    One line is identical to the value that is set when you
+                    run the SDK environment setup script, and the other line
+                    sets <filename>CC</filename> to "gcc", the default GNU
+                    compiler on the build host:
+                    <literallayout class='monospaced'>
+     # CC=i586-poky-linux-gcc  -m32 -march=i586 --sysroot=/opt/poky/2.5/sysroots/i586-poky-linux
+     # CC="gcc"
+     all: main.o module.o
+     	 ${CC} main.o module.o -o target_bin
+     main.o: main.c module.h
+	     ${CC} -I . -c main.c
+     module.o: module.c module.h
+	     ${CC} -I . -c module.c
+     clean:
+	     rm -rf *.o
+	     rm target_bin
+                    </literallayout>
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis>Make the Project:</emphasis>
+                    Use the <filename>make</filename> command to create the
+                    binary output file.
+                    Because variables are commented out in the Makefile,
+                    the value used for <filename>CC</filename> is the value
+                    set when the SDK environment setup file was run:
+                    <literallayout class='monospaced'>
+     $ make
+     i586-poky-linux-gcc  -m32 -march=i586 --sysroot=/opt/poky/2.5/sysroots/i586-poky-linux -I . -c main.c
+     i586-poky-linux-gcc  -m32 -march=i586 --sysroot=/opt/poky/2.5/sysroots/i586-poky-linux -I . -c module.c
+     i586-poky-linux-gcc  -m32 -march=i586 --sysroot=/opt/poky/2.5/sysroots/i586-poky-linux main.o module.o -o target_bin
+                    </literallayout>
+                    From the results of the previous command, you can see that
+                    the compiler used was the compiler established through
+                    the <filename>CC</filename> variable defined in the
+                    setup script.</para>
+
+                    <para>You can override the <filename>CC</filename>
+                    environment variable with the same variable as set from
+                    the Makefile by uncommenting the line in the Makefile
+                    and running <filename>make</filename> again.
+                    <literallayout class='monospaced'>
+     $ make clean
+     rm -rf *.o
+     rm target_bin
+     #
+     # Edit the Makefile by uncommenting the line that sets CC to "gcc"
+     #
+     $ make
+     gcc -I . -c main.c
+     gcc -I . -c module.c
+     gcc main.o module.o -o target_bin
+                    </literallayout>
+                    As shown in the previous example, the cross-toolchain
+                    compiler is not used.
+                    Rather, the default compiler is used.</para>
+
+                    <para>This next case shows how to override a variable
+                    by providing the variable as part of the command line.
+                    Go into the Makefile and re-insert the comment character
+                    so that running <filename>make</filename> uses
+                    the established SDK compiler.
+                    However, when you run <filename>make</filename>, use a
+                    command-line argument to set <filename>CC</filename>
+                    to "gcc":
+                    <literallayout class='monospaced'>
+     $ make clean
+     rm -rf *.o
+     rm target_bin
+     #
+     # Edit the Makefile to comment out the line setting CC to "gcc"
+     #
+     $ make
+     i586-poky-linux-gcc  -m32 -march=i586 --sysroot=/opt/poky/2.5/sysroots/i586-poky-linux -I . -c main.c
+     i586-poky-linux-gcc  -m32 -march=i586 --sysroot=/opt/poky/2.5/sysroots/i586-poky-linux -I . -c module.c
+     i586-poky-linux-gcc  -m32 -march=i586 --sysroot=/opt/poky/2.5/sysroots/i586-poky-linux main.o module.o -o target_bin
+     $ make clean
+     rm -rf *.o
+     rm target_bin
+     $ make CC="gcc"
+     gcc -I . -c main.c
+     gcc -I . -c module.c
+     gcc main.o module.o -o target_bin
+                    </literallayout>
+                    In the previous case, the command-line argument overrides
+                    the SDK environment variable.</para>
+
+                    <para>In this last case, edit Makefile again to use the
+                    "gcc" compiler but then use the "-e" option on the
+                    <filename>make</filename> command line:
+                    <literallayout class='monospaced'>
+     $ make clean
+     rm -rf *.o
+     rm target_bin
+     #
+     # Edit the Makefile to use "gcc"
+     #
+     $ make
+     gcc -I . -c main.c
+     gcc -I . -c module.c
+     gcc main.o module.o -o target_bin
+     $ make clean
+     rm -rf *.o
+     rm target_bin
+     $ make -e
+     i586-poky-linux-gcc  -m32 -march=i586 --sysroot=/opt/poky/2.5/sysroots/i586-poky-linux -I . -c main.c
+     i586-poky-linux-gcc  -m32 -march=i586 --sysroot=/opt/poky/2.5/sysroots/i586-poky-linux -I . -c module.c
+     i586-poky-linux-gcc  -m32 -march=i586 --sysroot=/opt/poky/2.5/sysroots/i586-poky-linux main.o module.o -o target_bin
+                    </literallayout>
+                    In the previous case, the "-e" option forces
+                    <filename>make</filename> to use the SDK environment
+                    variables regardless of the values in the Makefile.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis>Execute Your Project:</emphasis>
+                    To execute the project (i.e.
+                    <filename>target_bin</filename>), use the following
+                    command:
+                    <literallayout class='monospaced'>
+     $ ./target_bin
+     Hello World!
+                    </literallayout>
+                    <note>
+                        If you used the cross-toolchain compiler to build
+                        <filename>target_bin</filename> and your build host
+                        differs in architecture from that of the target
+                        machine, you need to run your project on the target
+                        device.
+                    </note>
+                    As expected, the project displays the "Hello World!"
+                    message.
+                    </para></listitem>
+            </orderedlist>
+        </para>
     </section>
 </chapter>
 <!--

meta-poky/conf/site.conf.sample

@@ -24,7 +24,9 @@ SCONF_VERSION = "1"
 #or
 #ALL_PROXY ?= "https://proxy.example.com:8080"
 # If you wish to use certain hosts without the proxy, specify them in NO_PROXY.
-# See the script for details on syntax.
+# See the script for details on syntax. The script oe-git-proxy uses some tools
+# that may not be included on HOSTTOOLS, thus  add them manually through
+# HOSTTOOLS += "getent seq"
 
 # Uncomment this to use a shared download directory
 #DL_DIR = "/some/shared/download/directory/"

meta-selftest/recipes-test/aspell/aspell_0.0.0.1.bb

@@ -28,5 +28,8 @@ FILES_${PN} = "${bindir}/aspell"
 FILES_libpspell = "${libdir}/libpspell.so.*"
 FILES_libpspell-dev = "${libdir}/libpspell* ${bindir}/pspell-config ${includedir}/pspell"
 
-ARM_INSTRUCTION_SET = "arm"
+ARM_INSTRUCTION_SET_armv4 = "arm"
+ARM_INSTRUCTION_SET_armv5 = "arm"
+ARM_INSTRUCTION_SET_armv6 = "arm"
+
 inherit autotools gettext

meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf

@@ -15,7 +15,7 @@ SERIAL_CONSOLE = "115200 ttyS0"
 MACHINE_FEATURES = "keyboard pci ext2 ext3 serial"
 
 PREFERRED_VERSION_linux-yocto ?= "4.15%"
-PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
+PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
 
 PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xorg"
 XSERVER ?= "xserver-xorg \
@@ -32,4 +32,4 @@ JFFS2_ERASEBLOCK = "0x4000"
 
 IMAGE_FSTYPES += "wic wic.bmap"
 WKS_FILE ?= 'mpc8315e-rdb.wks'
-IMAGE_BOOT_FILES ?= "u-boot.bin uImage uImage-mpc8315erdb.dtb;dtb"
+IMAGE_BOOT_FILES ?= "u-boot.bin uImage mpc8315erdb.dtb;dtb"

meta-yocto-bsp/lib/oeqa/selftest/cases/systemd_boot.py

@@ -44,7 +44,7 @@ class Systemdboot(OESelftestTestCase):
 
         # Ensure we're actually testing that this gets built and not that
         # it was around from an earlier build
-        bitbake('-c cleansstate systemd-boot')
+        bitbake('-c clean systemd-boot')
         runCmd('rm -f %s' % systemdbootfile)
 
         self._common_build()

meta-yocto-bsp/recipes-kernel/linux/linux-yocto-dev.bbappend

@@ -0,0 +1,15 @@
+KBRANCH_genericx86  = "standard/base"
+KBRANCH_genericx86-64  = "standard/base"
+KBRANCH_edgerouter = "standard/edgerouter"
+KBRANCH_beaglebone-yocto = "standard/beaglebone"
+KBRANCH_mpc8315e-rdb = "standard/fsl-mpc8315e-rdb"
+
+KMACHINE_genericx86 ?= "common-pc"
+KMACHINE_genericx86-64 ?= "common-pc-64"
+KMACHINE_beaglebone-yocto ?= "beaglebone"
+
+COMPATIBLE_MACHINE_genericx86 = "genericx86"
+COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64"
+COMPATIBLE_MACHINE_edgerouter = "edgerouter"
+COMPATIBLE_MACHINE_beaglebone-yocto = "beaglebone-yocto"
+COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb"

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

@@ -10,7 +10,7 @@ KMACHINE_beaglebone-yocto ?= "beaglebone"
 
 SRCREV_machine_genericx86    ?= "2bf00ed1aee9c26b48c26b10c731c2f8970d50c2"
 SRCREV_machine_genericx86-64 ?= "2bf00ed1aee9c26b48c26b10c731c2f8970d50c2"
-SRCREV_machine_edgerouter ?= "65d1c849534179bbfa494f77947f8be615e9871a"
+SRCREV_machine_edgerouter ?= "04043b48eb792c8baa310840307d480a28a43053"
 SRCREV_machine_beaglebone-yocto ?= "d62ddfa26a59c83f6128790b7aa2baadc04d2960"
 SRCREV_machine_mpc8315e-rdb ?= "80a106ecf737b69864e07b955eccb62f809cf120"
 

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

@@ -10,7 +10,7 @@ KMACHINE_beaglebone-yocto ?= "beaglebone"
 
 SRCREV_machine_genericx86    ?= "51273ff79f4ad930f4a788257f58e1266cb236e3"
 SRCREV_machine_genericx86-64 ?= "51273ff79f4ad930f4a788257f58e1266cb236e3"
-SRCREV_machine_edgerouter ?= "e25dbfe95302eeaa1a03a828d05c09479574488a"
+SRCREV_machine_edgerouter ?= "3373c0cf71f2812eeb9694839456df6f67fd32ac"
 SRCREV_machine_beaglebone-yocto ?= "e25dbfe95302eeaa1a03a828d05c09479574488a"
 SRCREV_machine_mpc8315e-rdb ?= "0b32edc46dfe7c40bf5451e9b7533c823bb2c6c4"
 

meta/classes/buildhistory.bbclass

@@ -77,6 +77,7 @@ python buildhistory_emit_pkghistory() {
 
     import re
     import json
+    import shlex
     import errno
 
     pkghistdir = d.getVar('BUILDHISTORY_DIR_PACKAGE')
@@ -244,7 +245,7 @@ python buildhistory_emit_pkghistory() {
                 key = item[0]
                 if key.endswith('_' + pkg):
                     key = key[:-len(pkg)-1]
-                pkgdata[key] = item[1]
+                pkgdata[key] = item[1].encode('latin-1').decode('unicode_escape')
 
         pkge = pkgdata.get('PKGE', '0')
         pkgv = pkgdata['PKGV']
@@ -287,7 +288,7 @@ python buildhistory_emit_pkghistory() {
         dictval = json.loads(val)
         filelist = list(dictval.keys())
         filelist.sort()
-        pkginfo.filelist = " ".join(filelist)
+        pkginfo.filelist = " ".join([shlex.quote(x) for x in filelist])
 
         pkginfo.size = int(pkgdata['PKGSIZE'])
 

meta/classes/cmake.bbclass

@@ -54,8 +54,6 @@ EXTRA_OECMAKE_BUILD_prepend_task-install = "${PARALLEL_MAKEINST} "
 OECMAKE_TARGET_COMPILE ?= "all"
 OECMAKE_TARGET_INSTALL ?= "install"
 
-FILES_${PN}-dev += "${libdir}/cmake ${datadir}/cmake"
-
 # CMake expects target architectures in the format of uname(2),
 # which do not always match TARGET_ARCH, so all the necessary
 # conversions should happen here.

meta/classes/cpan_build.bbclass

@@ -30,7 +30,7 @@ cpan_build_do_configure () {
 }
 
 cpan_build_do_compile () {
-        perl Build verbose=1
+        perl Build --perl "${bindir}/perl" verbose=1
 }
 
 cpan_build_do_install () {

meta/classes/cross-canadian.bbclass

@@ -30,7 +30,7 @@ python () {
     if d.getVar("MODIFYTOS") != "1":
         return
 
-    if d.getVar("TCLIBC") == "baremetal":
+    if d.getVar("TCLIBC") in [ 'baremetal', 'newlib' ]:
         return
 
     tos = d.getVar("TARGET_OS")

meta/classes/distutils3.bbclass

@@ -8,6 +8,12 @@ DISTUTILS_STAGE_ALL_ARGS ?= "--prefix=${STAGING_DIR_HOST}${prefix} \
 DISTUTILS_INSTALL_ARGS ?= "--prefix=${D}/${prefix} \
     --install-data=${D}/${datadir}"
 
+distutils3_do_configure() {
+	if [ "${CLEANBROKEN}" != "1" ] ; then
+		${STAGING_BINDIR_NATIVE}/${PYTHON_PN}-native/${PYTHON_PN} setup.py clean ${DISTUTILS_BUILD_ARGS}
+	fi
+}
+
 distutils3_do_compile() {
         STAGING_INCDIR=${STAGING_INCDIR} \
         STAGING_LIBDIR=${STAGING_LIBDIR} \
@@ -71,6 +77,6 @@ distutils3_do_install() {
 }
 distutils3_do_install[vardepsexclude] = "MACHINE"
 
-EXPORT_FUNCTIONS do_compile do_install
+EXPORT_FUNCTIONS do_configure do_compile do_install
 
 export LDSHARED="${CCLD} -shared"

meta/classes/fontcache.bbclass

@@ -17,7 +17,7 @@ FONTCONFIG_CACHE_PARAMS ?= "-v"
 FONTCONFIG_CACHE_ENV ?= "FC_DEBUG=1"
 fontcache_common() {
 if [ -n "$D" ] ; then
-	$INTERCEPT_DIR/postinst_intercept update_font_cache ${PKG} mlprefix=${MLPREFIX} \
+	$INTERCEPT_DIR/postinst_intercept update_font_cache ${PKG} mlprefix=${MLPREFIX} binprefix=${MLPREFIX} \
 		'bindir="${bindir}"' \
 		'libdir="${libdir}"' \
 		'base_libdir="${base_libdir}"' \

meta/classes/goarch.bbclass

@@ -33,9 +33,13 @@ COMPATIBLE_HOST_linux-muslx32 = "null"
 COMPATIBLE_HOST_powerpc = "null"
 COMPATIBLE_HOST_powerpc64 = "null"
 COMPATIBLE_HOST_mipsarchn32 = "null"
-ARM_INSTRUCTION_SET = "arm"
+
+ARM_INSTRUCTION_SET_armv4 = "arm"
+ARM_INSTRUCTION_SET_armv5 = "arm"
+ARM_INSTRUCTION_SET_armv6 = "arm"
+
 TUNE_CCARGS_remove = "-march=mips32r2"
-SECURITY_CFLAGS_mips = "${SECURITY_NOPIE_CFLAGS}"
+SECURITY_CFLAGS_mipsarch = "${SECURITY_NOPIE_CFLAGS}"
 SECURITY_NOPIE_CFLAGS ??= ""
 
 def go_map_arch(a, d):

meta/classes/gtk-immodules-cache.bbclass

@@ -10,53 +10,39 @@ GTKIMMODULES_PACKAGES ?= "${PN}"
 
 gtk_immodule_cache_postinst() {
 if [ "x$D" != "x" ]; then
-        if [ -x $D${bindir}/gtk-query-immodules-2.0 ]; then
-            IMFILES=$(ls $D${libdir}/gtk-2.0/*/immodules/*.so)
-            ${@qemu_run_binary(d, '$D', '${bindir}/gtk-query-immodules-2.0')} \
-                $IMFILES > $D${libdir}/gtk-2.0/2.10.0/immodules.cache 2>/dev/null &&
-                sed -i -e "s:$D::" $D${libdir}/gtk-2.0/2.10.0/immodules.cache
-        fi
-        if [ -x $D${bindir}/gtk-query-immodules-3.0 ]; then
-            IMFILES=$(ls $D${libdir}/gtk-3.0/*/immodules/*.so)
-            ${@qemu_run_binary(d, '$D', '${bindir}/gtk-query-immodules-3.0')} \
-                $IMFILES > $D${libdir}/gtk-3.0/3.0.0/immodules.cache 2>/dev/null &&
-                sed -i -e "s:$D::" $D${libdir}/gtk-3.0/3.0.0/immodules.cache
-        fi
-
-    [ $? -ne 0 ] && exit 1
-    exit 0
-fi
-if [ ! -z `which gtk-query-immodules-2.0` ]; then
-    gtk-query-immodules-2.0 > ${libdir}/gtk-2.0/2.10.0/immodules.cache
-fi
-if [ ! -z `which gtk-query-immodules-3.0` ]; then
-    gtk-query-immodules-3.0 > ${libdir}/gtk-3.0/3.0.0/immodules.cache
+    $INTERCEPT_DIR/postinst_intercept update_gtk_immodules_cache ${PKG} \
+            mlprefix=${MLPREFIX} \
+            binprefix=${MLPREFIX} \
+            libdir=${libdir} \
+            libexecdir=${libexecdir} \
+            base_libdir=${base_libdir} \
+            bindir=${bindir}
+else
+    if [ ! -z `which gtk-query-immodules-2.0` ]; then
+        gtk-query-immodules-2.0 > ${libdir}/gtk-2.0/2.10.0/immodules.cache
+    fi
+    if [ ! -z `which gtk-query-immodules-3.0` ]; then
+        gtk-query-immodules-3.0 > ${libdir}/gtk-3.0/3.0.0/immodules.cache
+    fi
 fi
 }
 
 gtk_immodule_cache_postrm() {
 if [ "x$D" != "x" ]; then
-        if [ -x $D${bindir}/gtk-query-immodules-2.0 ]; then
-            IMFILES=$(ls $D${libdir}/gtk-2.0/*/immodules/*.so)
-            ${@qemu_run_binary(d, '$D', '${bindir}/gtk-query-immodules-2.0')} \
-                $IMFILES > $D${libdir}/gtk-2.0/2.10.0/immodules.cache 2>/dev/null &&
-                sed -i -e "s:$D::" $D${libdir}/gtk-2.0/2.10.0/immodules.cache
-        fi
-        if [ -x $D${bindir}/gtk-query-immodules-3.0 ]; then
-            IMFILES=$(ls $D${libdir}/gtk-3.0/*/immodules/*.so)
-            ${@qemu_run_binary(d, '$D', '${bindir}/gtk-query-immodules-3.0')} \
-                $IMFILES > $D${libdir}/gtk-3.0/3.0.0/immodules.cache 2>/dev/null &&
-                sed -i -e "s:$D::" $D${libdir}/gtk-3.0/3.0.0/immodules.cache
-        fi
-
-    [ $? -ne 0 ] && exit 1
-    exit 0
-fi
-if [ ! -z `which gtk-query-immodules-2.0` ]; then
-    gtk-query-immodules-2.0 > ${libdir}/gtk-2.0/2.10.0/immodules.cache
-fi
-if [ ! -z `which gtk-query-immodules-3.0` ]; then
-    gtk-query-immodules-3.0 > ${libdir}/gtk-3.0/3.0.0/immodules.cache
+    $INTERCEPT_DIR/postinst_intercept update_gtk_immodules_cache ${PKG} \
+            mlprefix=${MLPREFIX} \
+            binprefix=${MLPREFIX} \
+            libdir=${libdir} \
+            libexecdir=${libexecdir} \
+            base_libdir=${base_libdir} \
+            bindir=${bindir}
+else
+    if [ ! -z `which gtk-query-immodules-2.0` ]; then
+        gtk-query-immodules-2.0 > ${libdir}/gtk-2.0/2.10.0/immodules.cache
+    fi
+    if [ ! -z `which gtk-query-immodules-3.0` ]; then
+        gtk-query-immodules-3.0 > ${libdir}/gtk-3.0/3.0.0/immodules.cache
+    fi
 fi
 }
 

meta/classes/image-live.bbclass

@@ -19,8 +19,6 @@
 
 # External variables (also used by syslinux.bbclass)
 # ${INITRD} - indicates a list of filesystem images to concatenate and use as an initrd (optional)
-# ${NOISO}  - skip building the ISO image if set to 1
-# ${NOHDD}  - skip building the HDD image if set to 1
 # ${HDDIMG_ID} - FAT image volume-id
 # ${ROOTFS} - indicates a filesystem image to include as the root filesystem (optional)
 
@@ -80,8 +78,8 @@ populate_live() {
 }
 
 build_iso() {
-	# Only create an ISO if we have an INITRD and NOISO was not set
-	if [ -z "${INITRD}" ] || [ "${NOISO}" = "1" ]; then
+	# Only create an ISO if we have an INITRD and the live or iso image type was selected
+	if [ -z "${INITRD}" ] || [ "${@bb.utils.contains_any('IMAGE_FSTYPES', 'live iso', '1', '0', d)}" != "1" ]; then
 		bbnote "ISO image will not be created."
 		return
 	fi
@@ -217,7 +215,7 @@ build_fat_img() {
 
 build_hddimg() {
 	# Create an HDD image
-	if [ "${NOHDD}" != "1" ] ; then
+	if [ "${@bb.utils.contains_any('IMAGE_FSTYPES', 'live hddimg', '1', '0', d)}" = "1" ] ; then
 		populate_live ${HDDDIR}
 
 		if [ "${PCBIOS}" = "1" ]; then
@@ -232,11 +230,11 @@ build_hddimg() {
 		if [ -f ${HDDDIR}/rootfs.img ]; then
 			rootfs_img_size=`stat -c '%s' ${HDDDIR}/rootfs.img`
 			max_size=`expr 4 \* 1024 \* 1024 \* 1024`
-			if [ $rootfs_img_size -gt $max_size ]; then
-				bberror "${HDDDIR}/rootfs.img execeeds 4GB,"
-				bberror "this doesn't work on FAT filesystem, you can try either of:"
-				bberror "1) Reduce the size of rootfs.img"
-				bbfatal "2) Use iso, vmdk or vdi to instead of hddimg\n"
+			if [ $rootfs_img_size -ge $max_size ]; then
+				bberror "${HDDDIR}/rootfs.img rootfs size is greather than or equal to 4GB,"
+				bberror "and this doesn't work on a FAT filesystem. You can either:"
+				bberror "1) Reduce the size of rootfs.img, or,"
+				bbfatal "2) Use wic, vmdk or vdi instead of hddimg\n"
 			fi
 		fi
 

meta/classes/image.bbclass

@@ -1,9 +1,20 @@
-inherit rootfs_${IMAGE_PKGTYPE}
 
+IMAGE_CLASSES ??= ""
+
+# rootfs bootstrap install
+# warning -  image-container resets this
+ROOTFS_BOOTSTRAP_INSTALL = "run-postinsts"
+
+# Handle inherits of any of the image classes we need
+IMGCLASSES = "rootfs_${IMAGE_PKGTYPE} image_types ${IMAGE_CLASSES}"
 # Only Linux SDKs support populate_sdk_ext, fall back to populate_sdk_base
 # in the non-Linux SDK_OS case, such as mingw32
-SDKEXTCLASS ?= "${@['populate_sdk_base', 'populate_sdk_ext']['linux' in d.getVar("SDK_OS")]}"
-inherit ${SDKEXTCLASS}
+IMGCLASSES += "${@['populate_sdk_base', 'populate_sdk_ext']['linux' in d.getVar("SDK_OS")]}"
+IMGCLASSES += "${@bb.utils.contains_any('IMAGE_FSTYPES', 'live iso hddimg', 'image-live', '', d)}"
+IMGCLASSES += "${@bb.utils.contains('IMAGE_FSTYPES', 'container', 'image-container', '', d)}"
+IMGCLASSES += "image_types_wic"
+IMGCLASSES += "rootfs-postcommands"
+inherit ${IMGCLASSES}
 
 TOOLCHAIN_TARGET_TASK += "${PACKAGE_INSTALL}"
 TOOLCHAIN_TARGET_TASK_ATTEMPTONLY += "${PACKAGE_INSTALL_ATTEMPTONLY}"
@@ -11,25 +22,21 @@ POPULATE_SDK_POST_TARGET_COMMAND += "rootfs_sysroot_relativelinks; "
 
 LICENSE ?= "MIT"
 PACKAGES = ""
-DEPENDS += "${MLPREFIX}qemuwrapper-cross depmodwrapper-cross"
+DEPENDS += "${@' '.join(["%s-qemuwrapper-cross" % m for m in d.getVar("MULTILIB_VARIANTS").split()])} qemuwrapper-cross depmodwrapper-cross"
 RDEPENDS += "${PACKAGE_INSTALL} ${LINGUAS_INSTALL}"
 RRECOMMENDS += "${PACKAGE_INSTALL_ATTEMPTONLY}"
+PATH_prepend = "${@":".join(all_multilib_tune_values(d, 'STAGING_BINDIR_CROSS').split())}:"
 
 INHIBIT_DEFAULT_DEPS = "1"
 
-TESTIMAGECLASS = "${@oe.utils.conditional('TEST_IMAGE', '1', 'testimage-auto', '', d)}"
-inherit ${TESTIMAGECLASS}
-
 # IMAGE_FEATURES may contain any available package group
 IMAGE_FEATURES ?= ""
 IMAGE_FEATURES[type] = "list"
-IMAGE_FEATURES[validitems] += "debug-tweaks read-only-rootfs empty-root-password allow-empty-password post-install-logging"
+IMAGE_FEATURES[validitems] += "debug-tweaks read-only-rootfs empty-root-password allow-empty-password allow-root-login post-install-logging"
 
 # Generate companion debugfs?
 IMAGE_GEN_DEBUGFS ?= "0"
 
-# rootfs bootstrap install
-ROOTFS_BOOTSTRAP_INSTALL = "run-postinsts"
 
 # These packages will be removed from a read-only rootfs after all other
 # packages have been installed
@@ -126,23 +133,6 @@ do_rootfs[vardeps] += "${@rootfs_variables(d)}"
 
 do_build[depends] += "virtual/kernel:do_deploy"
 
-def build_live(d):
-    if bb.utils.contains("IMAGE_FSTYPES", "live", "live", "0", d) == "0": # live is not set but hob might set iso or hddimg
-        d.setVar('NOISO', bb.utils.contains('IMAGE_FSTYPES', "iso", "0", "1", d))
-        d.setVar('NOHDD', bb.utils.contains('IMAGE_FSTYPES', "hddimg", "0", "1", d))
-        if d.getVar('NOISO') == "0" or d.getVar('NOHDD') == "0":
-            return "image-live"
-        return ""
-    return "image-live"
-
-IMAGE_TYPE_live = "${@build_live(d)}"
-inherit ${IMAGE_TYPE_live}
-
-IMAGE_TYPE_container = '${@bb.utils.contains("IMAGE_FSTYPES", "container", "image-container", "", d)}'
-inherit ${IMAGE_TYPE_container}
-
-IMAGE_TYPE_wic = "image_types_wic"
-inherit ${IMAGE_TYPE_wic}
 
 python () {
     def extraimage_getdepends(task):
@@ -177,9 +167,6 @@ python () {
     check_image_features(d)
 }
 
-IMAGE_CLASSES += "image_types"
-inherit ${IMAGE_CLASSES}
-
 IMAGE_POSTPROCESS_COMMAND ?= ""
 
 # some default locales
@@ -191,8 +178,6 @@ LINGUAS_INSTALL ?= "${@" ".join(map(lambda s: "locale-base-%s" % s, d.getVar('IM
 # aren't yet available.
 PSEUDO_PASSWD = "${IMAGE_ROOTFS}:${STAGING_DIR_NATIVE}"
 
-inherit rootfs-postcommands
-
 PACKAGE_EXCLUDE ??= ""
 PACKAGE_EXCLUDE[type] = "list"
 
@@ -666,7 +651,7 @@ POPULATE_SDK_PRE_TARGET_COMMAND += "${@bb.utils.contains('DISTRO_FEATURES', 'usr
 reproducible_final_image_task () {
     if [ "${BUILD_REPRODUCIBLE_BINARIES}" = "1" ]; then
         if [ "$REPRODUCIBLE_TIMESTAMP_ROOTFS" = "" ]; then
-            REPRODUCIBLE_TIMESTAMP_ROOTFS=`git log -1 --pretty=%ct`
+            REPRODUCIBLE_TIMESTAMP_ROOTFS=`git -C "${COREBASE}" log -1 --pretty=%ct`
         fi
         # Set mtime of all files to a reproducible value
         bbnote "reproducible_final_image_task: mtime set to $REPRODUCIBLE_TIMESTAMP_ROOTFS"

meta/classes/insane.bbclass

@@ -71,6 +71,7 @@ def package_qa_get_machine_dict(d):
                         "microblaze":  (189,   0,    0,          False,         32),
                         "microblazeeb":(189,   0,    0,          False,         32),
                         "microblazeel":(189,   0,    0,          True,          32),
+                        "powerpc":    (20,     0,    0,          False,         32),
                         "riscv32":    (243,    0,    0,          True,          32),
                         "riscv64":    (243,    0,    0,          True,          64),
                       },
@@ -534,9 +535,9 @@ def package_qa_check_buildpaths(path, name, d, elf, messages):
     if path.find(name + "/CONTROL/") != -1 or path.find(name + "/DEBIAN/") != -1:
         return
 
-    tmpdir = d.getVar('TMPDIR')
+    tmpdir = bytes(d.getVar('TMPDIR'), encoding="utf-8")
     with open(path, 'rb') as f:
-        file_content = f.read().decode('utf-8', errors='ignore')
+        file_content = f.read()
         if tmpdir in file_content:
             package_qa_add_message(messages, "buildpaths", "File %s in package contained reference to tmpdir" % package_qa_clean_path(path,d))
 
@@ -599,7 +600,7 @@ python populate_lic_qa_checksum() {
         return
 
     if not lic_files and d.getVar('SRC_URI'):
-        sane = package_qa_handle_error("license-checksum", pn + ": Recipe file fetches files and does not have license file information (LIC_FILES_CHKSUM)", d)
+        sane &= package_qa_handle_error("license-checksum", pn + ": Recipe file fetches files and does not have license file information (LIC_FILES_CHKSUM)", d)
 
     srcdir = d.getVar('S')
     corebase_licensefile = d.getVar('COREBASE') + "/LICENSE"
@@ -607,11 +608,11 @@ python populate_lic_qa_checksum() {
         try:
             (type, host, path, user, pswd, parm) = bb.fetch.decodeurl(url)
         except bb.fetch.MalformedUrl:
-            sane = package_qa_handle_error("license-checksum", pn + ": LIC_FILES_CHKSUM contains an invalid URL: " + url, d)
+            sane &= package_qa_handle_error("license-checksum", pn + ": LIC_FILES_CHKSUM contains an invalid URL: " + url, d)
             continue
         srclicfile = os.path.join(srcdir, path)
         if not os.path.isfile(srclicfile):
-            package_qa_handle_error("license-checksum", pn + ": LIC_FILES_CHKSUM points to an invalid file: " + srclicfile, d)
+            sane &= package_qa_handle_error("license-checksum", pn + ": LIC_FILES_CHKSUM points to an invalid file: " + srclicfile, d)
             continue
 
         if (srclicfile == corebase_licensefile):
@@ -695,7 +696,7 @@ python populate_lic_qa_checksum() {
             else:
                 msg = pn + ": LIC_FILES_CHKSUM is not specified for " +  url
                 msg = msg + "\n" + pn + ": The md5 checksum is " + md5chksum
-            sane = package_qa_handle_error("license-checksum", msg, d)
+            sane &= package_qa_handle_error("license-checksum", msg, d)
 
     if not sane:
         bb.fatal("Fatal QA errors found, failing task.")
@@ -732,14 +733,14 @@ def package_qa_check_staged(path,d):
                     file_content = file_content.replace(recipesysroot, "")
                     if workdir in file_content:
                         error_msg = "%s failed sanity test (workdir) in path %s" % (file,root)
-                        sane = package_qa_handle_error("la", error_msg, d)
+                        sane &= package_qa_handle_error("la", error_msg, d)
             elif file.endswith(".pc"):
                 with open(path) as f:
                     file_content = f.read()
                     file_content = file_content.replace(recipesysroot, "")
                     if pkgconfigcheck in file_content:
                         error_msg = "%s failed sanity test (tmpdir) in path %s" % (file,root)
-                        sane = package_qa_handle_error("pkgconfig", error_msg, d)
+                        sane &= package_qa_handle_error("pkgconfig", error_msg, d)
 
     return sane
 

meta/classes/kernel-artifact-names.bbclass

@@ -0,0 +1,19 @@
+KERNEL_IMAGE_BASE_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}-${DATETIME}"
+# Don't include the DATETIME variable in the sstate package signatures
+KERNEL_IMAGE_BASE_NAME[vardepsexclude] = "DATETIME"
+KERNEL_IMAGE_SYMLINK_NAME ?= "${MACHINE}"
+
+KERNEL_DTB_BASE_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}-${DATETIME}"
+KERNEL_DTB_BASE_NAME[vardepsexclude] = "DATETIME"
+KERNEL_DTB_SYMLINK_NAME ?= "${MACHINE}"
+
+MODULE_IMAGE_BASE_NAME ?= "modules-${PKGE}-${PKGV}-${PKGR}-${MACHINE}-${DATETIME}"
+MODULE_IMAGE_BASE_NAME[vardepsexclude] = "DATETIME"
+
+MODULE_TARBALL_BASE_NAME ?= "${MODULE_IMAGE_BASE_NAME}.tgz"
+MODULE_TARBALL_SYMLINK_NAME ?= "modules-${MACHINE}.tgz"
+MODULE_TARBALL_DEPLOY ?= "1"
+
+INITRAMFS_BASE_NAME ?= "initramfs-${PKGE}-${PKGV}-${PKGR}-${MACHINE}-${DATETIME}"
+INITRAMFS_BASE_NAME[vardepsexclude] = "DATETIME"
+INITRAMFS_SYMLINK_NAME ?= "initramfs-${MACHINE}"

meta/classes/kernel-devicetree.bbclass

@@ -10,21 +10,21 @@ FILES_${KERNEL_PACKAGE_NAME}-image-zimage-bundle = "/${KERNEL_IMAGEDEST}/zImage-
 KERNEL_DEVICETREE_BUNDLE ?= "0"
 
 normalize_dtb () {
-	DTB="$1"
-	if echo ${DTB} | grep -q '/dts/'; then
-		bbwarn "${DTB} contains the full path to the the dts file, but only the dtb name should be used."
-		DTB=`basename ${DTB} | sed 's,\.dts$,.dtb,g'`
+	dtb="$1"
+	if echo $dtb | grep -q '/dts/'; then
+		bbwarn "$dtb contains the full path to the the dts file, but only the dtb name should be used."
+		dtb=`basename $dtb | sed 's,\.dts$,.dtb,g'`
 	fi
-	echo "${DTB}"
+	echo "$dtb"
 }
 
 get_real_dtb_path_in_kernel () {
-	DTB="$1"
-	DTB_PATH="${B}/arch/${ARCH}/boot/dts/${DTB}"
-	if [ ! -e "${DTB_PATH}" ]; then
-		DTB_PATH="${B}/arch/${ARCH}/boot/${DTB}"
+	dtb="$1"
+	dtb_path="${B}/arch/${ARCH}/boot/dts/$dtb"
+	if [ ! -e "$dtb_path" ]; then
+		dtb_path="${B}/arch/${ARCH}/boot/$dtb"
 	fi
-	echo "${DTB_PATH}"
+	echo "$dtb_path"
 }
 
 do_configure_append() {
@@ -50,61 +50,44 @@ do_configure_append() {
 }
 
 do_compile_append() {
-	for DTB in ${KERNEL_DEVICETREE}; do
-		DTB=`normalize_dtb "${DTB}"`
-		oe_runmake ${DTB}
+	for dtbf in ${KERNEL_DEVICETREE}; do
+		dtb=`normalize_dtb "$dtbf"`
+		oe_runmake $dtb
 	done
 }
 
 do_install_append() {
-	for DTB in ${KERNEL_DEVICETREE}; do
-		DTB=`normalize_dtb "${DTB}"`
-		DTB_EXT=${DTB##*.}
-		DTB_PATH=`get_real_dtb_path_in_kernel "${DTB}"`
-		DTB_BASE_NAME=`basename ${DTB} ."${DTB_EXT}"`
-		install -m 0644 ${DTB_PATH} ${D}/${KERNEL_IMAGEDEST}/${DTB_BASE_NAME}.${DTB_EXT}
-		for type in ${KERNEL_IMAGETYPE_FOR_MAKE}; do
-			symlink_name=${type}"-"${KERNEL_IMAGE_SYMLINK_NAME}
-			DTB_SYMLINK_NAME=`echo ${symlink_name} | sed "s/${MACHINE}/${DTB_BASE_NAME}/g"`
-			ln -sf ${DTB_BASE_NAME}.${DTB_EXT} ${D}/${KERNEL_IMAGEDEST}/devicetree-${DTB_SYMLINK_NAME}.${DTB_EXT}
-
-			if [ "$type" = "zImage" ] && [ "${KERNEL_DEVICETREE_BUNDLE}" = "1" ]; then
-				cat ${D}/${KERNEL_IMAGEDEST}/$type \
-					${D}/${KERNEL_IMAGEDEST}/${DTB_BASE_NAME}.${DTB_EXT} \
-					> ${D}/${KERNEL_IMAGEDEST}/$type-${DTB_BASE_NAME}.${DTB_EXT}.bin
-			fi
-		done
+	for dtbf in ${KERNEL_DEVICETREE}; do
+		dtb=`normalize_dtb "$dtbf"`
+		dtb_ext=${dtb##*.}
+		dtb_base_name=`basename $dtb .$dtb_ext`
+		dtb_path=`get_real_dtb_path_in_kernel "$dtb"`
+		install -m 0644 $dtb_path ${D}/${KERNEL_IMAGEDEST}/$dtb_base_name.$dtb_ext
 	done
 }
 
 do_deploy_append() {
-	for DTB in ${KERNEL_DEVICETREE}; do
-		DTB=`normalize_dtb "${DTB}"`
-		DTB_EXT=${DTB##*.}
-		DTB_BASE_NAME=`basename ${DTB} ."${DTB_EXT}"`
+	for dtbf in ${KERNEL_DEVICETREE}; do
+		dtb=`normalize_dtb "$dtbf"`
+		dtb_ext=${dtb##*.}
+		dtb_base_name=`basename $dtb .$dtb_ext`
+		install -d ${DEPLOYDIR}
+		install -m 0644 ${D}/${KERNEL_IMAGEDEST}/$dtb_base_name.$dtb_ext ${DEPLOYDIR}/$dtb_base_name-${KERNEL_DTB_BASE_NAME}.$dtb_ext
+		ln -sf $dtb_base_name-${KERNEL_DTB_BASE_NAME}.$dtb_ext ${DEPLOYDIR}/$dtb_base_name.$dtb_ext
+		ln -sf $dtb_base_name-${KERNEL_DTB_BASE_NAME}.$dtb_ext ${DEPLOYDIR}/$dtb_base_name-${KERNEL_DTB_SYMLINK_NAME}.$dtb_ext
 		for type in ${KERNEL_IMAGETYPE_FOR_MAKE}; do
-			base_name=${type}"-"${KERNEL_IMAGE_BASE_NAME}
-			symlink_name=${type}"-"${KERNEL_IMAGE_SYMLINK_NAME}
-			DTB_NAME=`echo ${base_name} | sed "s/${MACHINE}/${DTB_BASE_NAME}/g"`
-			DTB_SYMLINK_NAME=`echo ${symlink_name} | sed "s/${MACHINE}/${DTB_BASE_NAME}/g"`
-			DTB_PATH=`get_real_dtb_path_in_kernel "${DTB}"`
-			install -d ${DEPLOYDIR}
-			install -m 0644 ${DTB_PATH} ${DEPLOYDIR}/${DTB_NAME}.${DTB_EXT}
-			ln -sf ${DTB_NAME}.${DTB_EXT} ${DEPLOYDIR}/${DTB_SYMLINK_NAME}.${DTB_EXT}
-			ln -sf ${DTB_NAME}.${DTB_EXT} ${DEPLOYDIR}/${DTB_BASE_NAME}.${DTB_EXT}
-
 			if [ "$type" = "zImage" ] && [ "${KERNEL_DEVICETREE_BUNDLE}" = "1" ]; then
-				cat ${DEPLOYDIR}/$type \
-					${DEPLOYDIR}/${DTB_NAME}.${DTB_EXT} \
-					> ${DEPLOYDIR}/${DTB_NAME}.${DTB_EXT}.bin
-				ln -sf ${DTB_NAME}.${DTB_EXT}.bin ${DEPLOYDIR}/$type-${DTB_BASE_NAME}.${DTB_EXT}.bin
-
+				cat ${D}/${KERNEL_IMAGEDEST}/$type \
+					${DEPLOYDIR}/$dtb_base_name-${KERNEL_DTB_BASE_NAME}.$dtb_ext \
+					> ${DEPLOYDIR}/$type-$dtb_base_name-${KERNEL_DTB_BASE_NAME}.$dtb_ext.bin
+				ln -sf $type-$dtb_base_name-${KERNEL_DTB_BASE_NAME}.$dtb_ext.bin \
+					${DEPLOYDIR}/$type-$dtb_base_name-${KERNEL_DTB_SYMLINK_NAME}.$dtb_ext.bin
 				if [ -e "${KERNEL_OUTPUT_DIR}/${type}.initramfs" ]; then
 					cat ${KERNEL_OUTPUT_DIR}/${type}.initramfs \
-						${DEPLOYDIR}/${DTB_NAME}.${DTB_EXT} \
-						> ${DEPLOYDIR}/${type}-${INITRAMFS_BASE_NAME}-${DTB_BASE_NAME}.${DTB_EXT}.bin
-					ln -sf ${type}-${INITRAMFS_BASE_NAME}-${DTB_BASE_NAME}.${DTB_EXT}.bin \
-					       ${DEPLOYDIR}/${type}-initramfs-${DTB_BASE_NAME}.${DTB_EXT}-${MACHINE}.bin
+						${DEPLOYDIR}/$dtb_base_name-${KERNEL_DTB_BASE_NAME}.$dtb_ext
+						>  ${DEPLOYDIR}/${type}-${INITRAMFS_BASE_NAME}-$dtb_base_name-${KERNEL_DTB_BASE_NAME}.$dtb_ext.bin
+					ln -sf ${type}-${INITRAMFS_BASE_NAME}-$dtb_base_name-${KERNEL_DTB_BASE_NAME}.$dtb_ext.bin \
+						${DEPLOYDIR}/${type}-${INITRAMFS_BASE_NAME}-$dtb_base_name-${KERNEL_DTB_SYMLINK_NAME}.$dtb_ext.bin
 				fi
 			fi
 		done

meta/classes/kernel-fitimage.bbclass

@@ -135,6 +135,15 @@ fitimage_emit_section_dtb() {
 
 	dtb_csum="sha1"
 
+	dtb_loadline=""
+	dtb_ext=${DTB##*.}
+	if [ "${dtb_ext}" = "dtbo" ]; then
+		if [ -n "${UBOOT_DTBO_LOADADDRESS}" ]; then
+			dtb_loadline="load = <${UBOOT_DTBO_LOADADDRESS}>;"
+		fi
+	elif [ -n "${UBOOT_DTB_LOADADDRESS}" ]; then
+		dtb_loadline="load = <${UBOOT_DTB_LOADADDRESS}>;"
+	fi
 	cat << EOF >> ${1}
                 fdt@${2} {
                         description = "Flattened Device Tree blob";
@@ -142,6 +151,7 @@ fitimage_emit_section_dtb() {
                         type = "flat_dt";
                         arch = "${UBOOT_ARCH}";
                         compression = "none";
+                        ${dtb_loadline}
                         hash@1 {
                                 algo = "${dtb_csum}";
                         };
@@ -248,25 +258,34 @@ fitimage_emit_section_config() {
 	fi
 
 	# Test if we have any DTBs at all
-	conf_desc="Linux kernel"
-	kernel_line="kernel = \"kernel@${2}\";"
+	sep=""
+	conf_desc=""
+	kernel_line=""
 	fdt_line=""
 	ramdisk_line=""
 	setup_line=""
 	default_line=""
 
+	if [ -n "${2}" ]; then
+		conf_desc="Linux kernel"
+		sep=", "
+		kernel_line="kernel = \"kernel@${2}\";"
+	fi
+
 	if [ -n "${3}" ]; then
-		conf_desc="${conf_desc}, FDT blob"
+		conf_desc="${conf_desc}${sep}FDT blob"
+		sep=", "
 		fdt_line="fdt = \"fdt@${3}\";"
 	fi
 
 	if [ -n "${4}" ]; then
-		conf_desc="${conf_desc}, ramdisk"
+		conf_desc="${conf_desc}${sep}ramdisk"
+		sep=", "
 		ramdisk_line="ramdisk = \"ramdisk@${4}\";"
 	fi
 
 	if [ -n "${5}" ]; then
-		conf_desc="${conf_desc}, setup"
+		conf_desc="${conf_desc}${sep}setup"
 		setup_line="setup = \"setup@${5}\";"
 	fi
 
@@ -289,18 +308,26 @@ EOF
 
 	if [ ! -z "${conf_sign_keyname}" ] ; then
 
-		sign_line="sign-images = \"kernel\""
+		sign_line="sign-images = "
+		sep=""
+
+		if [ -n "${2}" ]; then
+			sign_line="${sign_line}${sep}\"kernel\""
+			sep=", "
+		fi
 
 		if [ -n "${3}" ]; then
-			sign_line="${sign_line}, \"fdt\""
+			sign_line="${sign_line}${sep}\"fdt\""
+			sep=", "
 		fi
 
 		if [ -n "${4}" ]; then
-			sign_line="${sign_line}, \"ramdisk\""
+			sign_line="${sign_line}${sep}\"ramdisk\""
+			sep=", "
 		fi
 
 		if [ -n "${5}" ]; then
-			sign_line="${sign_line}, \"setup\""
+			sign_line="${sign_line}${sep}\"setup\""
 		fi
 
 		sign_line="${sign_line};"
@@ -377,7 +404,7 @@ fitimage_assemble() {
 	#
 	if [ "x${ramdiskcount}" = "x1" ] ; then
 		# Find and use the first initramfs image archive type we find
-		for img in cpio.lz4 cpio.lzo cpio.lzma cpio.xz cpio.gz cpio; do
+		for img in cpio.lz4 cpio.lzo cpio.lzma cpio.xz cpio.gz ext2.gz cpio; do
 			initramfs_path="${DEPLOY_DIR_IMAGE}/${INITRAMFS_IMAGE_NAME}.${img}"
 			echo "Using $initramfs_path"
 			if [ -e "${initramfs_path}" ]; then
@@ -403,7 +430,12 @@ fitimage_assemble() {
 	if [ -n "${DTBS}" ]; then
 		i=1
 		for DTB in ${DTBS}; do
-			fitimage_emit_section_config ${1} "${kernelcount}" "${DTB}" "${ramdiskcount}" "${setupcount}" "`expr ${i} = ${dtbcount}`"
+			dtb_ext=${DTB##*.}
+			if [ "${dtb_ext}" = "dtbo" ]; then
+				fitimage_emit_section_config ${1} "" "${DTB}" "" "" "`expr ${i} = ${dtbcount}`"
+			else
+				fitimage_emit_section_config ${1} "${kernelcount}" "${DTB}" "${ramdiskcount}" "${setupcount}" "`expr ${i} = ${dtbcount}`"
+			fi
 			i=`expr ${i} + 1`
 		done
 	fi
@@ -427,7 +459,7 @@ fitimage_assemble() {
 		uboot-mkimage \
 			${@'-D "${UBOOT_MKIMAGE_DTCOPTS}"' if len('${UBOOT_MKIMAGE_DTCOPTS}') else ''} \
 			-F -k "${UBOOT_SIGN_KEYDIR}" \
-			-K "${DEPLOY_DIR_IMAGE}/${UBOOT_DTB_BINARY}" \
+			${@'-K "${DEPLOY_DIR_IMAGE}/${UBOOT_DTB_BINARY}"' if len('${UBOOT_DTB_BINARY}') else ''} \
 			-r arch/${ARCH}/boot/${2}
 	fi
 }

meta/classes/kernel.bbclass

@@ -229,8 +229,6 @@ copy_initramfs() {
 	echo "Finished copy of initramfs into ./usr"
 }
 
-INITRAMFS_BASE_NAME ?= "initramfs-${PV}-${PR}-${MACHINE}-${DATETIME}"
-INITRAMFS_BASE_NAME[vardepsexclude] = "DATETIME"
 do_bundle_initramfs () {
 	if [ ! -z "${INITRAMFS_IMAGE}" -a x"${INITRAMFS_IMAGE_BUNDLE}" = x1 ]; then
 		echo "Creating a kernel image with a bundled initramfs..."
@@ -288,7 +286,7 @@ kernel_do_compile() {
 	if [ "${BUILD_REPRODUCIBLE_BINARIES}" = "1" ]; then
 		# kernel sources do not use do_unpack, so SOURCE_DATE_EPOCH may not
 		# be set....
-		if [ "$SOURCE_DATE_EPOCH" = "0" ]; then
+		if [ "${SOURCE_DATE_EPOCH}" = "" -o "${SOURCE_DATE_EPOCH}" = "0" ]; then
 			olddir=`pwd`
 			cd ${S}
 			SOURCE_DATE_EPOCH=`git log  -1 --pretty=%ct`
@@ -659,16 +657,7 @@ do_sizecheck[dirs] = "${B}"
 
 addtask sizecheck before do_install after do_strip
 
-KERNEL_IMAGE_BASE_NAME ?= "${PKGE}-${PKGV}-${PKGR}-${MACHINE}-${DATETIME}"
-# Don't include the DATETIME variable in the sstate package signatures
-KERNEL_IMAGE_BASE_NAME[vardepsexclude] = "DATETIME"
-KERNEL_IMAGE_SYMLINK_NAME ?= "${MACHINE}"
-MODULE_IMAGE_BASE_NAME ?= "modules-${PKGE}-${PKGV}-${PKGR}-${MACHINE}-${DATETIME}"
-MODULE_IMAGE_BASE_NAME[vardepsexclude] = "DATETIME"
-MODULE_TARBALL_BASE_NAME ?= "${MODULE_IMAGE_BASE_NAME}.tgz"
-# Don't include the DATETIME variable in the sstate package signatures
-MODULE_TARBALL_SYMLINK_NAME ?= "modules-${MACHINE}.tgz"
-MODULE_TARBALL_DEPLOY ?= "1"
+inherit kernel-artifact-names
 
 kernel_do_deploy() {
 	deployDir="${DEPLOYDIR}"
@@ -694,17 +683,14 @@ kernel_do_deploy() {
 		ln -sf ${base_name}.bin $deployDir/${type}
 	done
 
-	cd ${B}
-	# Update deploy directory
-	for type in ${KERNEL_IMAGETYPES} ; do
-		if [ -e "${KERNEL_OUTPUT_DIR}/${type}.initramfs" ]; then
-			echo "Copying deploy ${type} kernel-initramfs image and setting up links..."
+	if [ ! -z "${INITRAMFS_IMAGE}" -a x"${INITRAMFS_IMAGE_BUNDLE}" = x1 ]; then
+		for type in ${KERNEL_IMAGETYPES} ; do
 			initramfs_base_name=${type}-${INITRAMFS_BASE_NAME}
-			initramfs_symlink_name=${type}-initramfs-${MACHINE}
+			initramfs_symlink_name=${type}-${INITRAMFS_SYMLINK_NAME}
 			install -m 0644 ${KERNEL_OUTPUT_DIR}/${type}.initramfs $deployDir/${initramfs_base_name}.bin
 			ln -sf ${initramfs_base_name}.bin $deployDir/${initramfs_symlink_name}.bin
-		fi
-	done
+		done
+	fi
 }
 do_deploy[cleandirs] = "${DEPLOYDIR}"
 do_deploy[dirs] = "${DEPLOYDIR} ${B}"

meta/classes/license.bbclass

@@ -340,6 +340,9 @@ def add_package_and_files(d):
         # first in PACKAGES to be sure that nothing else gets LICENSE_FILES_DIRECTORY
         d.setVar('PACKAGES', "%s %s" % (pn_lic, packages))
         d.setVar('FILES_' + pn_lic, files)
+    for pn in packages.split():
+        if pn == pn_lic:
+            continue
         rrecommends_pn = d.getVar('RRECOMMENDS_' + pn)
         if rrecommends_pn:
             d.setVar('RRECOMMENDS_' + pn, "%s %s" % (pn_lic, rrecommends_pn))

meta/classes/manpages.bbclass

@@ -3,3 +3,35 @@
 # tends to pull in the entire XML stack and other tools, so it's not enabled
 # by default.
 PACKAGECONFIG_append_class-target = " ${@bb.utils.contains('DISTRO_FEATURES', 'api-documentation', 'manpages', '', d)}"
+
+inherit qemu
+
+# usually manual files are packaged to ${PN}-doc except man-pages
+MAN_PKG ?= "${PN}-doc"
+
+# only add man-db to RDEPENDS when manual files are built and installed
+RDEPENDS_${MAN_PKG} += "${@bb.utils.contains('PACKAGECONFIG', 'manpages', 'man-db', '', d)}"
+
+pkg_postinst_append_${MAN_PKG} () {
+	# only update manual page index caches when manual files are built and installed
+	if ${@bb.utils.contains('PACKAGECONFIG', 'manpages', 'true', 'false', d)}; then
+		if test -n "$D"; then
+			if ${@bb.utils.contains('MACHINE_FEATURES', 'qemu-usermode', 'true','false', d)}; then
+				sed "s:\(\s\)/:\1$D/:g" $D${sysconfdir}/man_db.conf | ${@qemu_run_binary(d, '$D', '${bindir}/mandb')} -C - -u -q $D${mandir}
+				mkdir -p $D${localstatedir}/cache/man
+				mv $D${mandir}/index.db $D${localstatedir}/cache/man
+			else
+				$INTERCEPT_DIR/postinst_intercept delay_to_first_boot ${PKG} mlprefix=${MLPREFIX}
+			fi
+		else
+			mandb -q
+		fi
+	fi
+}
+
+pkg_postrm_append_${MAN_PKG} () {
+	# only update manual page index caches when manual files are built and installed
+	if ${@bb.utils.contains('PACKAGECONFIG', 'manpages', 'true', 'false', d)}; then
+		mandb -q
+	fi
+}

meta/classes/meson.bbclass

@@ -35,14 +35,29 @@ MESON_LINK_ARGS = "${MESON_TOOLCHAIN_ARGS} ${LDFLAGS}"
 MESON_HOST_ENDIAN = "bogus-endian"
 MESON_TARGET_ENDIAN = "bogus-endian"
 
-EXTRA_OEMESON += "${PACKAGECONFIG_CONFARGS}"
+EXTRA_OEMESON_append = " ${PACKAGECONFIG_CONFARGS}"
 
 MESON_CROSS_FILE = ""
 MESON_CROSS_FILE_class-target = "--cross-file ${WORKDIR}/meson.cross"
 MESON_CROSS_FILE_class-nativesdk = "--cross-file ${WORKDIR}/meson.cross"
 
 def meson_array(var, d):
-    return "', '".join(d.getVar(var).split()).join(("'", "'"))
+    items = d.getVar(var).split()
+    return repr(items[0] if len(items) == 1 else items)
+
+# Map our ARCH values to what Meson expects:
+# http://mesonbuild.com/Reference-tables.html#cpu-families
+def meson_cpu_family(var, d):
+    import re
+    arch = d.getVar(var)
+    if arch == 'powerpc':
+        return 'ppc'
+    elif arch == 'mipsel':
+        return 'mips'
+    elif re.match(r"i[3-6]86", arch):
+        return "x86"
+    else:
+        return arch
 
 addtask write_config before do_configure
 do_write_config[vardeps] += "MESON_C_ARGS MESON_CPP_ARGS MESON_LINK_ARGS CC CXX LD AR NM STRIP READELF"
@@ -50,32 +65,32 @@ do_write_config() {
     # This needs to be Py to split the args into single-element lists
     cat >${WORKDIR}/meson.cross <<EOF
 [binaries]
-c = [${@meson_array('CC', d)}]
-cpp = [${@meson_array('CXX', d)}]
-ar = [${@meson_array('AR', d)}]
-nm = [${@meson_array('NM', d)}]
-ld = [${@meson_array('LD', d)}]
-strip = [${@meson_array('STRIP', d)}]
-readelf = [${@meson_array('READELF', d)}]
+c = ${@meson_array('CC', d)}
+cpp = ${@meson_array('CXX', d)}
+ar = ${@meson_array('AR', d)}
+nm = ${@meson_array('NM', d)}
+ld = ${@meson_array('LD', d)}
+strip = ${@meson_array('STRIP', d)}
+readelf = ${@meson_array('READELF', d)}
 pkgconfig = 'pkg-config'
 
 [properties]
 needs_exe_wrapper = true
-c_args = [${@meson_array('MESON_C_ARGS', d)}]
-c_link_args = [${@meson_array('MESON_LINK_ARGS', d)}]
-cpp_args = [${@meson_array('MESON_CPP_ARGS', d)}]
-cpp_link_args = [${@meson_array('MESON_LINK_ARGS', d)}]
+c_args = ${@meson_array('MESON_C_ARGS', d)}
+c_link_args = ${@meson_array('MESON_LINK_ARGS', d)}
+cpp_args = ${@meson_array('MESON_CPP_ARGS', d)}
+cpp_link_args = ${@meson_array('MESON_LINK_ARGS', d)}
 gtkdoc_exe_wrapper = '${B}/gtkdoc-qemuwrapper'
 
 [host_machine]
 system = '${HOST_OS}'
-cpu_family = '${HOST_ARCH}'
+cpu_family = '${@meson_cpu_family('HOST_ARCH', d)}'
 cpu = '${HOST_ARCH}'
 endian = '${MESON_HOST_ENDIAN}'
 
 [target_machine]
 system = '${TARGET_OS}'
-cpu_family = '${TARGET_ARCH}'
+cpu_family = '${@meson_cpu_family('TARGET_ARCH', d)}'
 cpu = '${TARGET_ARCH}'
 endian = '${MESON_TARGET_ENDIAN}'
 EOF
@@ -84,6 +99,7 @@ EOF
 CONFIGURE_FILES = "meson.build"
 
 meson_do_configure() {
+    bbnote Executing meson ${EXTRA_OEMESON}...
     if ! meson ${MESONOPTS} "${MESON_SOURCEPATH}" "${B}" ${MESON_CROSS_FILE} ${EXTRA_OEMESON}; then
         cat ${B}/meson-logs/meson-log.txt
         bbfatal_log meson failed
@@ -117,11 +133,11 @@ meson_do_configure_prepend_class-native() {
 
 do_compile[progress] = "outof:^\[(\d+)/(\d+)\]\s+"
 meson_do_compile() {
-    ninja ${PARALLEL_MAKE}
+    ninja -v ${PARALLEL_MAKE}
 }
 
 meson_do_install() {
-    DESTDIR='${D}' ninja ${PARALLEL_MAKEINST} install
+    DESTDIR='${D}' ninja -v ${PARALLEL_MAKEINST} install
 }
 
 EXPORT_FUNCTIONS do_configure do_compile do_install

meta/classes/mirrors.bbclass

@@ -1,4 +1,5 @@
 MIRRORS += "\
+${DEBIAN_MIRROR}	http://snapshot.debian.org/archive/debian/20180310T215105Z/pool \n \
 ${DEBIAN_MIRROR}	http://snapshot.debian.org/archive/debian-archive/20120328T092752Z/debian/pool \n \
 ${DEBIAN_MIRROR}	http://snapshot.debian.org/archive/debian-archive/20110127T084257Z/debian/pool \n \
 ${DEBIAN_MIRROR}	http://snapshot.debian.org/archive/debian-archive/20090802T004153Z/debian/pool \n \

meta/classes/multilib.bbclass

@@ -35,6 +35,10 @@ python multilib_virtclass_handler () {
         return
 
     if bb.data.inherits_class('cross-canadian', e.data):
+        # Multilib cross-candian should use the same nativesdk sysroot without MLPREFIX
+        e.data.setVar("RECIPE_SYSROOT", "${WORKDIR}/recipe-sysroot")
+        e.data.setVar("STAGING_DIR_TARGET", "${WORKDIR}/recipe-sysroot")
+        e.data.setVar("STAGING_DIR_HOST", "${WORKDIR}/recipe-sysroot")
         e.data.setVar("MLPREFIX", variant + "-")
         override = ":virtclass-multilib-" + variant
         e.data.setVar("OVERRIDES", e.data.getVar("OVERRIDES", False) + override)
@@ -115,6 +119,7 @@ python __anonymous () {
     clsextend.map_variable("INITSCRIPT_PACKAGES")
     clsextend.map_variable("USERADD_PACKAGES")
     clsextend.map_variable("SYSTEMD_PACKAGES")
+    clsextend.map_variable("UPDATERCPN")
 }
 
 PACKAGEFUNCS_append = " do_package_qa_multilib"

meta/classes/patch.bbclass

@@ -33,7 +33,7 @@ python patch_task_patch_prefunc() {
     if (testsrcdir + os.sep).startswith(workdir + os.sep):
         # Double-check that either workdir or S or some directory in-between is a git repository
         found = False
-        while testsrcdir != '/':
+        while testsrcdir != workdir:
             if os.path.exists(os.path.join(testsrcdir, '.git')):
                 found = True
                 break

meta/classes/pixbufcache.bbclass

@@ -12,7 +12,7 @@ PACKAGE_WRITE_DEPS += "qemu-native gdk-pixbuf-native"
 
 pixbufcache_common() {
 if [ "x$D" != "x" ]; then
-	$INTERCEPT_DIR/postinst_intercept update_pixbuf_cache ${PKG} mlprefix=${MLPREFIX} libdir=${libdir} \
+	$INTERCEPT_DIR/postinst_intercept update_pixbuf_cache ${PKG} mlprefix=${MLPREFIX} binprefix=${MLPREFIX} libdir=${libdir} \
 		bindir=${bindir} base_libdir=${base_libdir}
 else
 

meta/classes/populate_sdk_base.bbclass

@@ -46,7 +46,8 @@ TOOLCHAIN_TARGET_TASK_ATTEMPTONLY ?= ""
 TOOLCHAIN_OUTPUTNAME ?= "${SDK_NAME}-toolchain-${SDK_VERSION}"
 
 SDK_RDEPENDS = "${TOOLCHAIN_TARGET_TASK} ${TOOLCHAIN_HOST_TASK}"
-SDK_DEPENDS = "virtual/fakeroot-native xz-native cross-localedef-native ${MLPREFIX}qemuwrapper-cross"
+SDK_DEPENDS = "virtual/fakeroot-native xz-native cross-localedef-native nativesdk-qemuwrapper-cross ${@' '.join(["%s-qemuwrapper-cross" % m for m in d.getVar("MULTILIB_VARIANTS").split()])} qemuwrapper-cross"
+PATH_prepend = "${STAGING_DIR_HOST}${SDKPATHNATIVE}${bindir}/crossscripts:${@":".join(all_multilib_tune_values(d, 'STAGING_BINDIR_CROSS').split())}:"
 SDK_DEPENDS_append_libc-glibc = " nativesdk-glibc-locale"
 
 # We want the MULTIARCH_TARGET_SYS to point to the TUNE_PKGARCH, not PACKAGE_ARCH as it
@@ -62,8 +63,8 @@ SDK_PRE_INSTALL_COMMAND ?= ""
 SDK_POST_INSTALL_COMMAND ?= ""
 SDK_RELOCATE_AFTER_INSTALL ?= "1"
 
-SDKEXTPATH ?= "~/${@d.getVar('DISTRO')}_sdk"
-SDK_TITLE ?= "${@d.getVar('DISTRO_NAME') or d.getVar('DISTRO')} SDK"
+SDKEXTPATH ??= "~/${@d.getVar('DISTRO')}_sdk"
+SDK_TITLE ??= "${@d.getVar('DISTRO_NAME') or d.getVar('DISTRO')} SDK"
 
 SDK_TARGET_MANIFEST = "${SDKDEPLOYDIR}/${TOOLCHAIN_OUTPUTNAME}.target.manifest"
 SDK_HOST_MANIFEST = "${SDKDEPLOYDIR}/${TOOLCHAIN_OUTPUTNAME}.host.manifest"

meta/classes/populate_sdk_ext.bbclass

@@ -200,15 +200,9 @@ python copy_buildsystem () {
         workspace_name = 'orig-workspace'
     else:
         workspace_name = None
-    layers_copied = buildsystem.copy_bitbake_and_layers(baseoutpath + '/layers', workspace_name)
 
-    sdkbblayers = []
-    corebase = os.path.basename(d.getVar('COREBASE'))
-    for layer in layers_copied:
-        if corebase == os.path.basename(layer):
-            conf_bbpath = os.path.join('layers', layer, 'bitbake')
-        else:
-            sdkbblayers.append(layer)
+    corebase, sdkbblayers = buildsystem.copy_bitbake_and_layers(baseoutpath + '/layers', workspace_name)
+    conf_bbpath = os.path.join('layers', corebase, 'bitbake')
 
     for path in os.listdir(baseoutpath + '/layers'):
         relpath = os.path.join('layers', path, oe_init_env_script)
@@ -325,8 +319,9 @@ python copy_buildsystem () {
             f.write('TCLIBCAPPEND = ""\n')
             f.write('DL_DIR = "${TOPDIR}/downloads"\n')
 
-            f.write('INHERIT += "%s"\n' % 'uninative')
-            f.write('UNINATIVE_CHECKSUM[%s] = "%s"\n\n' % (d.getVar('BUILD_ARCH'), uninative_checksum))
+            if bb.data.inherits_class('uninative', d):
+               f.write('INHERIT += "%s"\n' % 'uninative')
+               f.write('UNINATIVE_CHECKSUM[%s] = "%s"\n\n' % (d.getVar('BUILD_ARCH'), uninative_checksum))
             f.write('CONF_VERSION = "%s"\n\n' % d.getVar('CONF_VERSION', False))
 
             # Some classes are not suitable for SDK, remove them from INHERIT

meta/classes/rm_work.bbclass

@@ -47,59 +47,60 @@ do_rm_work () {
     cd `dirname ${STAMP}`
     for i in `basename ${STAMP}`*
     do
-        for j in ${SSTATETASKS} do_shared_workdir
-        do
-            case $i in
-            *do_setscene*)
-                break
-                ;;
-            *_setscene*)
-                i=dummy
-                break
-                ;;
-            *sigdata*|*sigbasedata*)
-                i=dummy
-                break
-                ;;
-            *do_package_write*)
-                i=dummy
-                break
-                ;;
-            *do_image_complete*)
-                mv $i `echo $i | sed -e "s#do_image_complete#do_image_complete_setscene#"`
-                i=dummy
-                break
-                ;;
-            *do_rootfs*|*do_image*|*do_bootimg*|*do_write_qemuboot_conf*)
-                i=dummy
-                break
-                ;;
-            *do_build*)
-                i=dummy
-                break
-                ;;
-            *do_addto_recipe_sysroot*)
-                # Preserve recipe-sysroot-native if do_addto_recipe_sysroot has been used
-                excludes="$excludes recipe-sysroot-native"
-                i=dummy
-                break
-                ;;
+        # By default we'll delete the stamp, unless $i is changed by the inner loop
+        # (i=dummy does this)
+
+        case $i in
+        *sigdata*|*sigbasedata*)
+            # Save/skip anything that looks like a signature data file.
+            i=dummy
+            ;;
+        *do_image_complete_setscene*)
+            # Ensure we don't 'stack' setscene extensions to this stamp with the section below
+            i=dummy
+            ;;
+        *do_image_complete*)
+            # Promote do_image_complete stamps to setscene versions (ahead of *do_image* below)
+            mv $i `echo $i | sed -e "s#do_image_complete#do_image_complete_setscene#"`
+            i=dummy
+            ;;
+        *do_package_write*|*do_rootfs*|*do_image*|*do_bootimg*|*do_write_qemuboot_conf*|*do_build*)
+            i=dummy
+            ;;
+        *do_addto_recipe_sysroot*)
+            # Preserve recipe-sysroot-native if do_addto_recipe_sysroot has been used
+            excludes="$excludes recipe-sysroot-native"
+            i=dummy
+            ;;
+        *do_package|*do_package.*|*do_package_setscene.*)
             # We remove do_package entirely, including any
             # sstate version since otherwise we'd need to leave 'plaindirs' around
             # such as 'packages' and 'packages-split' and these can be large. No end
             # of chain tasks depend directly on do_package anymore.
-            *do_package|*do_package.*|*do_package_setscene.*)
-                rm -f $i;
-                i=dummy
+            rm -f $i;
+            i=dummy
+            ;;
+        *_setscene*)
+            # Skip stamps which are already setscene versions
+            i=dummy
+            ;;
+        esac
+
+        for j in ${SSTATETASKS} do_shared_workdir
+        do
+            case $i in
+            dummy)
                 break
                 ;;
             *$j|*$j.*)
+                # Promote the stamp to a setscene version
                 mv $i `echo $i | sed -e "s#${j}#${j}_setscene#"`
                 i=dummy
                 break
-            ;;
+                ;;
             esac
         done
+
         rm -f $i
     done
 

meta/classes/rootfs-postcommands.bbclass

@@ -2,9 +2,12 @@
 # Zap the root password if debug-tweaks feature is not enabled
 ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains_any("IMAGE_FEATURES", [ 'debug-tweaks', 'empty-root-password' ], "", "zap_empty_root_password ; ",d)}'
 
-# Allow dropbear/openssh to accept logins from accounts with an empty password string if debug-tweaks is enabled
+# Allow dropbear/openssh to accept logins from accounts with an empty password string if debug-tweaks or allow-empty-password is enabled
 ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains_any("IMAGE_FEATURES", [ 'debug-tweaks', 'allow-empty-password' ], "ssh_allow_empty_password; ", "",d)}'
 
+# Allow dropbear/openssh to accept root logins if debug-tweaks or allow-root-login is enabled
+ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains_any("IMAGE_FEATURES", [ 'debug-tweaks', 'allow-root-login' ], "ssh_allow_root_login; ", "",d)}'
+
 # Enable postinst logging if debug-tweaks is enabled
 ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains_any("IMAGE_FEATURES", [ 'debug-tweaks', 'post-install-logging' ], "postinst_enable_logging; ", "",d)}'
 
@@ -36,11 +39,6 @@ ROOTFS_POSTPROCESS_COMMAND += '${@bb.utils.contains("DISTRO_FEATURES", "systemd"
 
 ROOTFS_POSTPROCESS_COMMAND += 'empty_var_volatile;'
 
-# Disable DNS lookups, the SSH_DISABLE_DNS_LOOKUP can be overridden to allow
-# distros to choose not to take this change
-SSH_DISABLE_DNS_LOOKUP ?= " ssh_disable_dns_lookup ; "
-ROOTFS_POSTPROCESS_COMMAND_append_qemuall = "${SSH_DISABLE_DNS_LOOKUP}"
-
 # Sort the user and group entries in /etc by ID in order to make the content
 # deterministic. Package installs are not deterministic, causing the ordering
 # of entries to change between builds. In case that this isn't desired,
@@ -143,12 +141,11 @@ zap_empty_root_password () {
 }
 
 #
-# allow dropbear/openssh to accept root logins and logins from accounts with an empty password string
+# allow dropbear/openssh to accept logins from accounts with an empty password string
 #
 ssh_allow_empty_password () {
 	for config in sshd_config sshd_config_readonly; do
 		if [ -e ${IMAGE_ROOTFS}${sysconfdir}/ssh/$config ]; then
-			sed -i 's/^[#[:space:]]*PermitRootLogin.*/PermitRootLogin yes/' ${IMAGE_ROOTFS}${sysconfdir}/ssh/$config
 			sed -i 's/^[#[:space:]]*PermitEmptyPasswords.*/PermitEmptyPasswords yes/' ${IMAGE_ROOTFS}${sysconfdir}/ssh/$config
 		fi
 	done
@@ -171,9 +168,20 @@ ssh_allow_empty_password () {
 	fi
 }
 
-ssh_disable_dns_lookup () {
-	if [ -e ${IMAGE_ROOTFS}${sysconfdir}/ssh/sshd_config ]; then
-		sed -i -e 's:#UseDNS yes:UseDNS no:' ${IMAGE_ROOTFS}${sysconfdir}/ssh/sshd_config
+#
+# allow dropbear/openssh to accept root logins
+#
+ssh_allow_root_login () {
+	for config in sshd_config sshd_config_readonly; do
+		if [ -e ${IMAGE_ROOTFS}${sysconfdir}/ssh/$config ]; then
+			sed -i 's/^[#[:space:]]*PermitRootLogin.*/PermitRootLogin yes/' ${IMAGE_ROOTFS}${sysconfdir}/ssh/$config
+		fi
+	done
+
+	if [ -e ${IMAGE_ROOTFS}${sbindir}/dropbear ] ; then
+		if grep -q DROPBEAR_EXTRA_ARGS ${IMAGE_ROOTFS}${sysconfdir}/default/dropbear 2>/dev/null ; then
+			sed -i '/^DROPBEAR_EXTRA_ARGS=/ s/-w//' ${IMAGE_ROOTFS}${sysconfdir}/default/dropbear
+		fi
 	fi
 }
 

meta/classes/setuptools.bbclass

@@ -1,6 +1,6 @@
 inherit distutils
 
-DEPENDS += "python-distribute-native"
+DEPENDS += "python-setuptools-native"
 
 DISTUTILS_INSTALL_ARGS = "--root=${D} \
     --prefix=${prefix} \

meta/classes/spdx.bbclass

@@ -202,18 +202,13 @@ def list_files(dir):
     return
 
 def hash_file(file_name):
-    try:
-        with open(file_name, 'rb') as f:
-            data_string = f.read()
-            sha1 = hash_string(data_string)
-            return sha1
-    except:
-        return None
+    from bb.utils import sha1_file
+    return sha1_file(file_name)
 
 def hash_string(data):
     import hashlib
     sha1 = hashlib.sha1()
-    sha1.update(data)
+    sha1.update(data.encode('utf-8'))
     return sha1.hexdigest()
 
 def run_fossology(foss_command, full_spdx):
@@ -226,7 +221,7 @@ def run_fossology(foss_command, full_spdx):
     except subprocess.CalledProcessError as e:
         return None
 
-    foss_output = string.replace(foss_output, '\r', '')
+    foss_output = foss_output.replace('\r', '')
 
     # Package info
     package_info = {}
@@ -289,7 +284,8 @@ def create_spdx_doc(file_info, scanned_files):
 def get_ver_code(dirname):
     chksums = []
     for f_dir, f in list_files(dirname):
-        hash = hash_file(os.path.join(dirname, f_dir, f))
+        path = os.path.join(dirname, f_dir, f)
+        hash = hash_file(path)
         if not hash is None:
             chksums.append(hash)
         else:

meta/classes/sstate.bbclass

@@ -300,7 +300,7 @@ def sstate_installpkg(ss, d):
     sstatepkg = d.getVar('SSTATE_PKG') + '_' + ss['task'] + ".tgz"
 
     if not os.path.exists(sstatepkg):
-        pstaging_fetch(sstatefetch, sstatepkg, d)
+        pstaging_fetch(sstatefetch, d)
 
     if not os.path.isfile(sstatepkg):
         bb.note("Staging package %s does not exist" % sstatepkg)
@@ -407,7 +407,7 @@ python sstate_hardcode_path_unpack () {
         bb.note("Replacing fixme paths in sstate package: %s" % (sstate_hardcode_cmd))
         subprocess.check_call(sstate_hardcode_cmd, shell=True)
 
-        # Need to remove this or we'd copy it into the target directory and may 
+        # Need to remove this or we'd copy it into the target directory and may
         # conflict with another writer
         os.remove(fixmefn)
 }
@@ -635,7 +635,7 @@ def sstate_package(ss, d):
 
     return
 
-def pstaging_fetch(sstatefetch, sstatepkg, d):
+def pstaging_fetch(sstatefetch, d):
     import bb.fetch2
 
     # Only try and fetch if the user has configured a mirror

meta/classes/staging.bbclass

@@ -383,8 +383,6 @@ python extend_recipe_sysroot() {
     lock = bb.utils.lockfile(recipesysroot + "/sysroot.lock")
 
     fixme = {}
-    fixme[''] = []
-    fixme['native'] = []
     seendirs = set()
     postinsts = []
     multilibs = {}
@@ -471,7 +469,14 @@ python extend_recipe_sysroot() {
         os.symlink(c + "." + taskhash, depdir + "/" + c)
 
         manifest, d2 = oe.sstatesig.find_sstate_manifest(c, setscenedeps[dep][2], "populate_sysroot", d, multilibs)
+        if d2 is not d:
+            # If we don't do this, the recipe sysroot will be placed in the wrong WORKDIR for multilibs
+            # We need a consistent WORKDIR for the image
+            d2.setVar("WORKDIR", d.getVar("WORKDIR"))
         destsysroot = d2.getVar("RECIPE_SYSROOT")
+        # We put allarch recipes into the default sysroot
+        if manifest and "allarch" in manifest:
+            destsysroot = d.getVar("RECIPE_SYSROOT")
 
         native = False
         if c.endswith("-native") or "-cross-" in c or "-crosssdk" in c:
@@ -479,12 +484,13 @@ python extend_recipe_sysroot() {
 
         if manifest:
             newmanifest = collections.OrderedDict()
+            targetdir = destsysroot
             if native:
-                fm = fixme['native']
                 targetdir = recipesysrootnative
-            else:
-                fm = fixme['']
-                targetdir = destsysroot
+            if targetdir not in fixme:
+                fixme[targetdir] = []
+            fm = fixme[targetdir]
+
             with open(manifest, "r") as f:
                 manifests[dep] = manifest
                 for l in f:
@@ -542,12 +548,7 @@ python extend_recipe_sysroot() {
     bb.note("Skipping as already exists in sysroot: %s" % str(msg_exists))
 
     for f in fixme:
-        if f == '':
-            staging_processfixme(fixme[f], recipesysroot, recipesysroot, recipesysrootnative, d)
-        elif f == 'native':
-            staging_processfixme(fixme[f], recipesysrootnative, recipesysroot, recipesysrootnative, d)
-        else:
-            staging_processfixme(fixme[f], multilibs[f].getVar("RECIPE_SYSROOT"), recipesysroot, recipesysrootnative, d)
+        staging_processfixme(fixme[f], f, recipesysroot, recipesysrootnative, d)
 
     for p in postinsts:
         subprocess.check_output(p, shell=True, stderr=subprocess.STDOUT)

meta/classes/systemd.bbclass

@@ -34,10 +34,10 @@ if type systemctl >/dev/null 2>/dev/null; then
 		systemctl daemon-reload
 	fi
 
-	systemctl $OPTS ${SYSTEMD_AUTO_ENABLE} ${SYSTEMD_SERVICE}
+	systemctl $OPTS ${SYSTEMD_AUTO_ENABLE} ${SYSTEMD_SERVICE_ESCAPED}
 
 	if [ -z "$D" -a "${SYSTEMD_AUTO_ENABLE}" = "enable" ]; then
-		systemctl --no-block restart ${SYSTEMD_SERVICE}
+		systemctl --no-block restart ${SYSTEMD_SERVICE_ESCAPED}
 	fi
 fi
 }
@@ -51,10 +51,10 @@ fi
 
 if type systemctl >/dev/null 2>/dev/null; then
 	if [ -z "$D" ]; then
-		systemctl stop ${SYSTEMD_SERVICE}
+		systemctl stop ${SYSTEMD_SERVICE_ESCAPED}
 	fi
 
-	systemctl $OPTS disable ${SYSTEMD_SERVICE}
+	systemctl $OPTS disable ${SYSTEMD_SERVICE_ESCAPED}
 fi
 }
 
@@ -65,6 +65,7 @@ systemd_populate_packages[vardepsexclude] += "OVERRIDES"
 
 python systemd_populate_packages() {
     import re
+    import shlex
 
     if not bb.utils.contains('DISTRO_FEATURES', 'systemd', True, False, d):
         return
@@ -85,6 +86,9 @@ python systemd_populate_packages() {
     def systemd_generate_package_scripts(pkg):
         bb.debug(1, 'adding systemd calls to postinst/postrm for %s' % pkg)
 
+        paths_escaped = ' '.join(shlex.quote(s) for s in d.getVar('SYSTEMD_SERVICE_' + pkg, True).split())
+        d.setVar('SYSTEMD_SERVICE_ESCAPED_' + pkg, paths_escaped)
+
         # Add pkg to the overrides so that it finds the SYSTEMD_SERVICE_pkg
         # variable.
         localdata = d.createCopy()
@@ -130,7 +134,7 @@ python systemd_populate_packages() {
                 systemd_add_files_and_parse(pkg_systemd, path, service_base + '@.service', keys)
             for key in keys.split():
                 # recurse all dependencies found in keys ('Also';'Conflicts';..) and add to files
-                cmd = "grep %s %s | sed 's,%s=,,g' | tr ',' '\\n'" % (key, fullpath, key)
+                cmd = "grep %s %s | sed 's,%s=,,g' | tr ',' '\\n'" % (key, shlex.quote(fullpath), key)
                 pipe = os.popen(cmd, 'r')
                 line = pipe.readline()
                 while line:

meta/classes/testimage-auto.bbclass

@@ -1,23 +0,0 @@
-# Copyright (C) 2013 Intel Corporation
-#
-# Released under the MIT license (see COPYING.MIT)
-
-
-# Run tests automatically on an image after the image is constructed
-# (as opposed to testimage.bbclass alone where tests must be called
-# manually using bitbake -c testimage <image>).
-#
-# NOTE: to use this class, simply set TEST_IMAGE = "1" - no need to
-# inherit it since that will be done in image.bbclass when this variable
-# has been set.
-#
-# See testimage.bbclass for the test implementation.
-
-inherit testimage
-
-python do_testimage_auto() {
-    testimage_main(d)
-}
-addtask testimage_auto before do_build after do_image_complete
-do_testimage_auto[depends] += "${TESTIMAGEDEPENDS}"
-do_testimage_auto[lockfiles] += "${TESTIMAGELOCK}"

meta/classes/testimage.bbclass

@@ -10,6 +10,11 @@
 # - first add IMAGE_CLASSES += "testimage" in local.conf
 # - build a qemu core-image-sato
 # - then bitbake core-image-sato -c testimage. That will run a standard suite of tests.
+#
+# The tests can be run automatically each time an image is built if you set
+# TESTIMAGE_AUTO = "1"
+
+TESTIMAGE_AUTO ??= "0"
 
 # You can set (or append to) TEST_SUITES in local.conf to select the tests
 # which you want to run for your target.
@@ -382,4 +387,9 @@ def package_extraction(d, test_suites):
 
 testimage_main[vardepsexclude] += "BB_ORIGENV DATETIME"
 
+python () {
+    if oe.types.boolean(d.getVar("TESTIMAGE_AUTO") or "False"):
+        bb.build.addtask("testimage", "do_build", "do_image_complete", d)
+}
+
 inherit testsdk

meta/classes/testsdk.bbclass

@@ -24,8 +24,6 @@ def testsdk_main(d):
     from oeqa.sdk.context import OESDKTestContext, OESDKTestContextExecutor
     from oeqa.utils import make_logger_bitbake_compatible
 
-    bb.event.enable_threadlock()
-
     pn = d.getVar("PN")
     logger = make_logger_bitbake_compatible(logging.getLogger("BitBake"))
 
@@ -44,6 +42,8 @@ def testsdk_main(d):
     host_pkg_manifest = OESDKTestContextExecutor._load_manifest(
         d.expand("${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.host.manifest"))
 
+    processes = d.getVar("TESTIMAGE_NUMBER_THREADS") or d.getVar("BB_NUMBER_THREADS")
+
     sdk_dir = d.expand("${WORKDIR}/testimage-sdk/")
     bb.utils.remove(sdk_dir, True)
     bb.utils.mkdirhier(sdk_dir)
@@ -67,7 +67,10 @@ def testsdk_main(d):
             import traceback
             bb.fatal("Loading tests failed:\n%s" % traceback.format_exc())
 
-        result = tc.runTests()
+        if processes:
+            result = tc.runTests(processes=int(processes))
+        else:
+            result = tc.runTests()
 
         component = "%s %s" % (pn, OESDKTestContextExecutor.name)
         context_msg = "%s:%s" % (os.path.basename(tcname), os.path.basename(sdk_env))
@@ -99,8 +102,6 @@ def testsdkext_main(d):
     from oeqa.utils import avoid_paths_in_environ, make_logger_bitbake_compatible, subprocesstweak
     from oeqa.sdkext.context import OESDKExtTestContext, OESDKExtTestContextExecutor
 
-    bb.event.enable_threadlock()
-
     pn = d.getVar("PN")
     logger = make_logger_bitbake_compatible(logging.getLogger("BitBake"))
 
@@ -157,6 +158,7 @@ def testsdkext_main(d):
             f.write('SSTATE_MIRRORS += " \\n file://.* file://%s/PATH"\n' % test_data.get('SSTATE_DIR'))
             f.write('SOURCE_MIRROR_URL = "file://%s"\n' % test_data.get('DL_DIR'))
             f.write('INHERIT += "own-mirrors"\n')
+            f.write('PREMIRRORS_prepend = " git://git.yoctoproject.org/.* git://%s/git2/git.yoctoproject.org.BASENAME \\n "\n' % test_data.get('DL_DIR'))
 
         # We need to do this in case we have a minimal SDK
         subprocess.check_output(". %s > /dev/null; devtool sdk-install meta-extsdk-toolchain" % \
@@ -194,3 +196,8 @@ python do_testsdkext() {
 addtask testsdkext
 do_testsdkext[nostamp] = "1"
 
+python () {
+    if oe.types.boolean(d.getVar("TESTIMAGE_AUTO") or "False"):
+        bb.build.addtask("testsdk", None, "do_populate_sdk", d)
+        bb.build.addtask("testsdkext", None, "do_populate_sdk_ext", d)
+}

meta/classes/uboot-extlinux-config.bbclass

@@ -58,7 +58,7 @@
 #
 # The kernel has an internal default console, which you can override with
 # a console=...some_tty...
-UBOOT_EXTLINUX_CONSOLE ??= "console=${console}"
+UBOOT_EXTLINUX_CONSOLE ??= "console=${console},${baudrate}"
 UBOOT_EXTLINUX_LABELS ??= "linux"
 UBOOT_EXTLINUX_FDT ??= ""
 UBOOT_EXTLINUX_FDTDIR ??= "../"

meta/classes/utils.bbclass

@@ -328,16 +328,11 @@ def get_multilib_datastore(variant, d):
 def all_multilib_tune_values(d, var, unique = True, need_split = True, delim = ' '):
     """Return a string of all ${var} in all multilib tune configuration"""
     values = []
-    value = d.getVar(var) or ""
-    if value != "":
-        if need_split:
-            for item in value.split(delim):
-                values.append(item)
-        else:
-            values.append(value)
-    variants = d.getVar("MULTILIB_VARIANTS") or ""
-    for item in variants.split():
+    variants = (d.getVar("MULTILIB_VARIANTS") or "").split() + ['']
+    for item in variants:
         localdata = get_multilib_datastore(item, d)
+        # We need WORKDIR to be consistent with the original datastore
+        localdata.setVar("WORKDIR", d.getVar("WORKDIR"))
         value = localdata.getVar(var) or ""
         if value != "":
             if need_split:

meta/conf/bitbake.conf

@@ -308,7 +308,8 @@ FILES_SOLIBSDEV ?= "${base_libdir}/lib*${SOLIBSDEV} ${libdir}/lib*${SOLIBSDEV}"
 FILES_${PN}-dev = "${includedir} ${FILES_SOLIBSDEV} ${libdir}/*.la \
                 ${libdir}/*.o ${libdir}/pkgconfig ${datadir}/pkgconfig \
                 ${datadir}/aclocal ${base_libdir}/*.o \
-                ${libdir}/${BPN}/*.la ${base_libdir}/*.la"
+                ${libdir}/${BPN}/*.la ${base_libdir}/*.la \
+                ${libdir}/cmake ${datadir}/cmake"
 SECTION_${PN}-dev = "devel"
 ALLOW_EMPTY_${PN}-dev = "1"
 RDEPENDS_${PN}-dev = "${PN} (= ${EXTENDPKGV})"
@@ -318,7 +319,6 @@ SECTION_${PN}-staticdev = "devel"
 RDEPENDS_${PN}-staticdev = "${PN}-dev (= ${EXTENDPKGV})"
 
 FILES_${PN}-dbg = "/usr/lib/debug /usr/src/debug"
-
 SECTION_${PN}-dbg = "devel"
 ALLOW_EMPTY_${PN}-dbg = "1"
 
@@ -487,7 +487,7 @@ HOSTTOOLS += " \
 "
 
 # Tools needed to run testimage runtime image testing
-HOSTTOOLS += "${@'ip ping ps scp ssh stty' if (bb.data.inherits_class('testimage', d) or d.getVar('TEST_IMAGE') == '1') else ''}"
+HOSTTOOLS += "${@'ip ping ps scp ssh stty' if (bb.utils.contains_any('IMAGE_CLASSES', 'testimage testsdk', True, False, d) or any(x in (d.getVar("BBINCLUDED") or "") for x in ["testimage.bbclass", "testsdk.bbclass"])) else ''}"
 
 # Link to these if present
 HOSTTOOLS_NONFATAL += "aws ccache gcc-ar gpg ld.bfd ld.gold nc sftp socat ssh sudo"

meta/conf/distro/include/default-versions.inc

@@ -2,6 +2,6 @@
 # Default preferred versions
 #
 
-PREFERRED_VERSION_openssl = "1.0.%"
-PREFERRED_VERSION_openssl-native = "1.0.%"
-PREFERRED_VERSION_nativesdk-openssl = "1.0.%"
+PREFERRED_VERSION_openssl ?= "1.0.%"
+PREFERRED_VERSION_openssl-native ?= "1.0.%"
+PREFERRED_VERSION_nativesdk-openssl ?= "1.0.%"

meta/conf/distro/include/distro_alias.inc

@@ -87,7 +87,6 @@ DISTRO_PN_ALIAS_pn-encodings = "Ubuntu=xfonts-encodings Mandriva=x11-font-encodi
 DISTRO_PN_ALIAS_pn-font-alias = "Fedora=xorg-x11-fonts-base Mandriva=x11-font-alias Meego=xorg-x11-fonts"
 DISTRO_PN_ALIAS_pn-font-util = "Meego=xorg-x11-font-utils Fedora=xorg-x11-font-utils Ubuntu=xfonts-utils Mandriva=x11-font-util Debian=xfonts-utils"
 DISTRO_PN_ALIAS_pn-formfactor = "OE-Core"
-DISTRO_PN_ALIAS_pn-fstests = "OpenedHand"
 DISTRO_PN_ALIAS_pn-gcc-cross-initial = "OE-Core"
 DISTRO_PN_ALIAS_pn-gcc-cross-initial-i586 = "OE-Core"
 DISTRO_PN_ALIAS_pn-gcc-crosssdk-initial = "OE-Core"
@@ -141,7 +140,6 @@ DISTRO_PN_ALIAS_pn-initscripts = "Fedora=initscripts Mandravia=initscripts"
 DISTRO_PN_ALIAS_pn-iproute2 = "OSPDT"
 DISTRO_PN_ALIAS_pn-jpeg = "OpenSuSE=libjpeg Ubuntu=libjpeg62"
 DISTRO_PN_ALIAS_pn-kernel-devsrc = "Debian=linux-base Ubuntu=linux"
-DISTRO_PN_ALIAS_pn-kernelshark = "Mandriva=kernelshark Ubuntu=kernelshark"
 DISTRO_PN_ALIAS_pn-kern-tools-native = "Windriver"
 DISTRO_PN_ALIAS_pn-keymaps = "OE-Core"
 DISTRO_PN_ALIAS_pn-kf = "OSPDT"
@@ -244,7 +242,6 @@ DISTRO_PN_ALIAS_pn-mini-x-session = "OSPDT"
 DISTRO_PN_ALIAS_pn-mkelfimage = "Ubuntu=mkelfimage Fedora=mkelfimage"
 DISTRO_PN_ALIAS_pn-mkfontdir = "Mandriva=mkfontdir Ubuntu=xfonts-utils Fedora=xorg-x11-font-utils"
 DISTRO_PN_ALIAS_pn-mkfontscale = "Mandriva=mkfontscale Ubuntu=xfonts-utils Fedora=xorg-x11-font-utils"
-DISTRO_PN_ALIAS_pn-mktemp = "Mandriva=mktemp Fedora=mktemp"
 DISTRO_PN_ALIAS_pn-mmc-utils = "OE-Core"
 DISTRO_PN_ALIAS_pn-modutils-initscripts = "OE-Core"
 DISTRO_PN_ALIAS_pn-mtd-utils = "Debian=mtd-utils Ubuntu=mtd-utils"
@@ -308,14 +305,12 @@ DISTRO_PN_ALIAS_pn-ptest-runner = "OE-Core"
 DISTRO_PN_ALIAS_pn-pulseaudio-client-conf-sato = "OE-Core"
 DISTRO_PN_ALIAS_pn-puzzles = "Debian=sgt-puzzles Fedora=puzzles"
 DISTRO_PN_ALIAS_pn-python3 = "Fedora=python3 Debian=python3.2"
-DISTRO_PN_ALIAS_pn-python3-distribute = "Debian=python3-setuptools Fedora=python3-setuptools"
 DISTRO_PN_ALIAS_pn-python3-iniparse = "Fedora=python-iniparse Debian=python-iniparse"
 DISTRO_PN_ALIAS_pn-python3-pip = "OpenSuSE=python3-pip Debian=python3-pip"
 DISTRO_PN_ALIAS_pn-python3-pycurl = "Fedora=python-pycurl Debian=pycurl"
 DISTRO_PN_ALIAS_pn-python3-pygpgme = "Fedora=python-pygpgme Debian=pygpgme"
 DISTRO_PN_ALIAS_pn-python3-setuptools = "OpenSuSE=python3-setuptools Debian=python3-setuptools"
 DISTRO_PN_ALIAS_pn-python-dbus = "Ubuntu=python-dbus Debian=python-dbus Mandriva=python-dbus"
-DISTRO_PN_ALIAS_pn-python-distribute = "Opensuse=python-setuptools Fedora=python-setuptools"
 DISTRO_PN_ALIAS_pn-python-git = "Debian=python-git Fedora=GitPython"
 DISTRO_PN_ALIAS_pn-python-mako = "Fedora=python-mako Opensuse=python-Mako"
 DISTRO_PN_ALIAS_pn-python-pycairo = "Meego=pycairo Fedora=pycairo Ubuntu=pycairo Debian=pycairo"
@@ -357,7 +352,6 @@ DISTRO_PN_ALIAS_pn-tar-replacement = "Fedora=tar Ubuntu=tar"
 DISTRO_PN_ALIAS_pn-tcf-agent = "Windriver upstream=http://www.eclipse.org/dsdp/tm/"
 DISTRO_PN_ALIAS_pn-texinfo-dummy-native = "OE-Core"
 DISTRO_PN_ALIAS_pn-tiny-init = "OSPDT"
-DISTRO_PN_ALIAS_pn-trace-cmd = "Mandriva=trace-cmd Ubuntu=trace-cmd"
 DISTRO_PN_ALIAS_pn-tremor = "OSPDT upstream=http://www.xiph.org/vorbis/"
 DISTRO_PN_ALIAS_pn-ttf-bitstream-vera = "Debian=ttf-bitstream-vera Ubuntu=ttf-bitstream-vera"
 DISTRO_PN_ALIAS_pn-tzcode = "OSPDT"

meta/conf/distro/include/maintainers.inc

@@ -30,7 +30,6 @@
 RECIPE_MAINTAINER_pn-acl = "Chen Qi <Qi.Chen@windriver.com>"
 RECIPE_MAINTAINER_pn-acpica = "Fathi Boudra <fathi.boudra@linaro.org>"
 RECIPE_MAINTAINER_pn-acpid = "Maxin B. John <maxin.john@intel.com>"
-RECIPE_MAINTAINER_pn-acpitests = "Fathi Boudra <fathi.boudra@linaro.org>"
 RECIPE_MAINTAINER_pn-adwaita-icon-theme = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-alsa-lib = "Tanu Kaskinen <tanuk@iki.fi>"
 RECIPE_MAINTAINER_pn-alsa-plugins = "Tanu Kaskinen <tanuk@iki.fi>"
@@ -45,7 +44,7 @@ RECIPE_MAINTAINER_pn-apt = "Aníbal Limón <limon.anibal@gmail.com>"
 RECIPE_MAINTAINER_pn-apt-native = "Aníbal Limón <limon.anibal@gmail.com>"
 RECIPE_MAINTAINER_pn-argp-standalone = "Khem Raj <raj.khem@gmail.com>"
 RECIPE_MAINTAINER_pn-asciidoc = "Yi Zhao <yi.zhao@windriver.com>"
-RECIPE_MAINTAINER_pn-aspell = "Jose Lamego <jose.a.lamego@linux.intel.com>"
+RECIPE_MAINTAINER_pn-aspell = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-assimp = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-at = "Chen Qi <Qi.Chen@windriver.com>"
 RECIPE_MAINTAINER_pn-at-spi2-atk = "Maxin B. John <maxin.john@intel.com>"
@@ -54,17 +53,15 @@ RECIPE_MAINTAINER_pn-atk = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-attr = "Chen Qi <Qi.Chen@windriver.com>"
 RECIPE_MAINTAINER_pn-autoconf = "Robert Yang <liezhi.yang@windriver.com>"
 RECIPE_MAINTAINER_pn-autoconf-archive = "Robert Yang <liezhi.yang@windriver.com>"
-RECIPE_MAINTAINER_pn-autogen-native = "Robert Yang <liezhi.yang@windriver.com>"
 RECIPE_MAINTAINER_pn-automake = "Robert Yang <liezhi.yang@windriver.com>"
 RECIPE_MAINTAINER_pn-avahi = "Yi Zhao <yi.zhao@windriver.com>"
 RECIPE_MAINTAINER_pn-avahi-ui = "Yi Zhao <yi.zhao@windriver.com>"
 RECIPE_MAINTAINER_pn-babeltrace = "Alexander Kanavin <alex.kanavin@gmail.com>"
-RECIPE_MAINTAINER_pn-base-files = "Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>"
-RECIPE_MAINTAINER_pn-base-passwd = "Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>"
+RECIPE_MAINTAINER_pn-base-files = "Ross Burton <ross.burton@intel.com>"
+RECIPE_MAINTAINER_pn-base-passwd = "Ross Burton <ross.burton@intel.com>"
 RECIPE_MAINTAINER_pn-bash = "Hongxu Jia <hongxu.jia@windriver.com>"
 RECIPE_MAINTAINER_pn-bash-completion = "Alexander Kanavin <alex.kanavin@gmail.com>"
-RECIPE_MAINTAINER_pn-bc = "Jose Lamego <jose.a.lamego@linux.intel.com>"
-RECIPE_MAINTAINER_pn-bdwgc = "Alexander Kanavin <alex.kanavin@gmail.com>"
+RECIPE_MAINTAINER_pn-bc = "Ross Burton <ross.burton@intel.com>"
 RECIPE_MAINTAINER_pn-bind = "Armin Kuster <akuster808@gmail.com>"
 RECIPE_MAINTAINER_pn-binutils = "Khem Raj <raj.khem@gmail.com>"
 RECIPE_MAINTAINER_pn-binutils-cross = "Khem Raj <raj.khem@gmail.com>"
@@ -75,17 +72,17 @@ RECIPE_MAINTAINER_pn-bjam-native = "Alexander Kanavin <alex.kanavin@gmail.com>"
 RECIPE_MAINTAINER_pn-blktool = "Yi Zhao <yi.zhao@windriver.com>"
 RECIPE_MAINTAINER_pn-blktrace = "Alexander Kanavin <alex.kanavin@gmail.com>"
 RECIPE_MAINTAINER_pn-bluez5 = "Maxin B. John <maxin.john@intel.com>"
-RECIPE_MAINTAINER_pn-bmap-tools = "Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>"
+RECIPE_MAINTAINER_pn-bmap-tools = "Ross Burton <ross.burton@intel.com>"
 RECIPE_MAINTAINER_pn-boost = "Alexander Kanavin <alex.kanavin@gmail.com>"
 RECIPE_MAINTAINER_pn-bootchart2 = "Alexander Kanavin <alex.kanavin@gmail.com>"
 RECIPE_MAINTAINER_pn-bsd-headers = "Khem Raj <raj.khem@gmail.com>"
 RECIPE_MAINTAINER_pn-btrfs-tools = "Alexander Kanavin <alex.kanavin@gmail.com>"
 RECIPE_MAINTAINER_pn-build-appliance-image = "Richard Purdie <richard.purdie@linuxfoundation.org>"
-RECIPE_MAINTAINER_pn-build-compare = "Randy Witt <randy.e.witt@linux.intel.com>"
+RECIPE_MAINTAINER_pn-build-compare = "Paul Eggleton <paul.eggleton@linux.intel.com>"
 RECIPE_MAINTAINER_pn-build-sysroots = "Richard Purdie <richard.purdie@linuxfoundation.org>"
 RECIPE_MAINTAINER_pn-builder = "Richard Purdie <richard.purdie@linuxfoundation.org>"
 RECIPE_MAINTAINER_pn-buildtools-tarball = "Richard Purdie <richard.purdie@linuxfoundation.org>"
-RECIPE_MAINTAINER_pn-busybox = "Armin Kuster <akuster808@gmail.com>"
+RECIPE_MAINTAINER_pn-busybox = "Andrej Valek <andrej.valek@siemens.com>"
 RECIPE_MAINTAINER_pn-busybox-inittab = "Denys Dmytriyenko <denys@ti.com>"
 RECIPE_MAINTAINER_pn-bzip2 = "Denys Dmytriyenko <denys@ti.com>"
 RECIPE_MAINTAINER_pn-ca-certificates = "Alexander Kanavin <alex.kanavin@gmail.com>"
@@ -131,8 +128,6 @@ RECIPE_MAINTAINER_pn-desktop-file-utils-native = "Alexander Kanavin <alex.kanavi
 RECIPE_MAINTAINER_pn-dhcp = "Hongxu Jia <hongxu.jia@windriver.com>"
 RECIPE_MAINTAINER_pn-diffstat = "Chen Qi <Qi.Chen@windriver.com>"
 RECIPE_MAINTAINER_pn-diffutils = "Chen Qi <Qi.Chen@windriver.com>"
-RECIPE_MAINTAINER_pn-directfb = "Hongxu Jia <hongxu.jia@windriver.com>"
-RECIPE_MAINTAINER_pn-directfb-examples = "Hongxu Jia <hongxu.jia@windriver.com>"
 RECIPE_MAINTAINER_pn-distcc = "Hongxu Jia <hongxu.jia@windriver.com>"
 RECIPE_MAINTAINER_pn-distcc-config = "Yi Zhao <yi.zhao@windriver.com>"
 RECIPE_MAINTAINER_pn-dmidecode = "Alexander Kanavin <alex.kanavin@gmail.com>"
@@ -147,16 +142,14 @@ RECIPE_MAINTAINER_pn-dwarfsrcfiles = "Alexander Kanavin <alex.kanavin@gmail.com>
 RECIPE_MAINTAINER_pn-e2fsprogs = "Robert Yang <liezhi.yang@windriver.com>"
 RECIPE_MAINTAINER_pn-ed = "Alexander Kanavin <alex.kanavin@gmail.com>"
 RECIPE_MAINTAINER_pn-eee-acpi-scripts = "Alexander Kanavin <alex.kanavin@gmail.com>"
-RECIPE_MAINTAINER_pn-efilinux = "Alexander Kanavin <alex.kanavin@gmail.com>"
 RECIPE_MAINTAINER_pn-eglinfo-fb = "Alexander Kanavin <alex.kanavin@gmail.com>"
 RECIPE_MAINTAINER_pn-eglinfo-x11 = "Alexander Kanavin <alex.kanavin@gmail.com>"
-RECIPE_MAINTAINER_pn-efilinux = "Alexander Kanavin <alex.kanavin@gmail.com>"
 RECIPE_MAINTAINER_pn-elfutils = "Hongxu Jia <hongxu.jia@windriver.com>"
 RECIPE_MAINTAINER_pn-enchant = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-encodings = "Armin Kuster <akuster808@gmail.com>"
 RECIPE_MAINTAINER_pn-epiphany = "Alexander Kanavin <alex.kanavin@gmail.com>"
 RECIPE_MAINTAINER_pn-ethtool = "Changhyeok Bae <changhyeok.bae@lge.com>"
-RECIPE_MAINTAINER_pn-eudev = "Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>"
+RECIPE_MAINTAINER_pn-eudev = "Ross Burton <ross.burton@intel.com>"
 RECIPE_MAINTAINER_pn-expat = "Yi Zhao <yi.zhao@windriver.com>"
 RECIPE_MAINTAINER_pn-expect = "Alexander Kanavin <alex.kanavin@gmail.com>"
 RECIPE_MAINTAINER_pn-ffmpeg = "Alexander Kanavin <alex.kanavin@gmail.com>"
@@ -170,7 +163,6 @@ RECIPE_MAINTAINER_pn-fontconfig = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-foomatic-filters = "Chen Qi <Qi.Chen@windriver.com>"
 RECIPE_MAINTAINER_pn-formfactor = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-freetype = "Maxin B. John <maxin.john@intel.com>"
-RECIPE_MAINTAINER_pn-fstests = "Alexander Kanavin <alex.kanavin@gmail.com>"
 RECIPE_MAINTAINER_pn-fts = "Khem Raj <raj.khem@gmail.com>"
 RECIPE_MAINTAINER_pn-gawk = "Chen Qi <Qi.Chen@windriver.com>"
 RECIPE_MAINTAINER_pn-gcc = "Khem Raj <raj.khem@gmail.com>"
@@ -204,9 +196,7 @@ RECIPE_MAINTAINER_pn-glibc-mtrace = "Khem Raj <raj.khem@gmail.com>"
 RECIPE_MAINTAINER_pn-glibc-scripts = "Khem Raj <raj.khem@gmail.com>"
 RECIPE_MAINTAINER_pn-glide = "Otavio Salvador <otavio.salvador@ossystems.com.br>"
 RECIPE_MAINTAINER_pn-gmp = "Khem Raj <raj.khem@gmail.com>"
-RECIPE_MAINTAINER_pn-gnome-common = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-gnome-desktop-testing = "Maxin B. John <maxin.john@intel.com>"
-RECIPE_MAINTAINER_pn-gnome-doc-utils = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-gnome-themes-standard = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-gnu-config = "Robert Yang <liezhi.yang@windriver.com>"
 RECIPE_MAINTAINER_pn-gnu-efi = "Yi Zhao <yi.zhao@windriver.com>"
@@ -243,11 +233,7 @@ RECIPE_MAINTAINER_pn-gstreamer1.0-vaapi = "Anuj Mittal <anuj.mittal@intel.com>"
 RECIPE_MAINTAINER_pn-gtk+ = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-gtk+3 = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-gtk-doc = "Alexander Kanavin <alex.kanavin@gmail.com>"
-RECIPE_MAINTAINER_pn-gtk-engines = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-gtk-icon-utils-native = "Maxin B. John <maxin.john@intel.com>"
-RECIPE_MAINTAINER_pn-gtk-sato-engine = "Maxin B. John <maxin.john@intel.com>"
-RECIPE_MAINTAINER_pn-guilt-native = "Bruce Ashfield <bruce.ashfield@windriver.com>"
-RECIPE_MAINTAINER_pn-gummiboot = "Alexander Kanavin <alex.kanavin@gmail.com>"
 RECIPE_MAINTAINER_pn-gzip = "Denys Dmytriyenko <denys@ti.com>"
 RECIPE_MAINTAINER_pn-harfbuzz = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-hdparm = "Denys Dmytriyenko <denys@ti.com>"
@@ -262,13 +248,13 @@ RECIPE_MAINTAINER_pn-ifupdown = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-init-ifupdown = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-initramfs-boot = "Otavio Salvador <otavio.salvador@ossystems.com.br>"
 RECIPE_MAINTAINER_pn-initramfs-framework = "Otavio Salvador <otavio.salvador@ossystems.com.br>"
-RECIPE_MAINTAINER_pn-initramfs-live-boot = "Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>"
-RECIPE_MAINTAINER_pn-initramfs-live-boot-tiny = "Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>"
-RECIPE_MAINTAINER_pn-initramfs-live-install = "Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>"
-RECIPE_MAINTAINER_pn-initramfs-live-install-efi = "Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>"
-RECIPE_MAINTAINER_pn-initramfs-live-install-efi-testfs = "Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>"
-RECIPE_MAINTAINER_pn-initramfs-live-install-testfs = "Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>"
-RECIPE_MAINTAINER_pn-initscripts = "Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>"
+RECIPE_MAINTAINER_pn-initramfs-live-boot = "Ross Burton <ross.burton@intel.com>"
+RECIPE_MAINTAINER_pn-initramfs-live-boot-tiny = "Ross Burton <ross.burton@intel.com>"
+RECIPE_MAINTAINER_pn-initramfs-live-install = "Ross Burton <ross.burton@intel.com>"
+RECIPE_MAINTAINER_pn-initramfs-live-install-efi = "Ross Burton <ross.burton@intel.com>"
+RECIPE_MAINTAINER_pn-initramfs-live-install-efi-testfs = "Ross Burton <ross.burton@intel.com>"
+RECIPE_MAINTAINER_pn-initramfs-live-install-testfs = "Ross Burton <ross.burton@intel.com>"
+RECIPE_MAINTAINER_pn-initscripts = "Ross Burton <ross.burton@intel.com>"
 RECIPE_MAINTAINER_pn-intltool = "Alexander Kanavin <alex.kanavin@gmail.com>"
 RECIPE_MAINTAINER_pn-iproute2 = "Changhyeok Bae <changhyeok.bae@lge.com>"
 RECIPE_MAINTAINER_pn-iptables = "Changhyeok Bae <changhyeok.bae@lge.com>"
@@ -280,9 +266,7 @@ RECIPE_MAINTAINER_pn-libjpeg-turbo = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-json-c = "Yi Zhao <yi.zhao@windriver.com>"
 RECIPE_MAINTAINER_pn-json-glib = "Yi Zhao <yi.zhao@windriver.com>"
 RECIPE_MAINTAINER_pn-kbd = "Alexander Kanavin <alex.kanavin@gmail.com>"
-RECIPE_MAINTAINER_pn-kconfig-frontends = "Alexander Kanavin <alex.kanavin@gmail.com>"
 RECIPE_MAINTAINER_pn-kern-tools-native = "Bruce Ashfield <bruce.ashfield@windriver.com>"
-RECIPE_MAINTAINER_pn-kernelshark = "Alexander Kanavin <alex.kanavin@gmail.com>"
 RECIPE_MAINTAINER_pn-kernel-devsrc = "Bruce Ashfield <bruce.ashfield@windriver.com>"
 RECIPE_MAINTAINER_pn-kexec-tools = "Armin Kuster <akuster808@gmail.com>"
 RECIPE_MAINTAINER_pn-keymaps = "Alexander Kanavin <alex.kanavin@gmail.com>"
@@ -306,7 +290,7 @@ RECIPE_MAINTAINER_pn-libcap-ng = "Yi Zhao <yi.zhao@windriver.com>"
 RECIPE_MAINTAINER_pn-libcgroup = "Alexander Kanavin <alex.kanavin@gmail.com>"
 RECIPE_MAINTAINER_pn-libcheck = "Yi Zhao <yi.zhao@windriver.com>"
 RECIPE_MAINTAINER_pn-libcomps = "Alexander Kanavin <alex.kanavin@gmail.com>"
-RECIPE_MAINTAINER_pn-libconvert-asn1-perl = "Tim Orling <timothy.t.orling@intel.com>"
+RECIPE_MAINTAINER_pn-libconvert-asn1-perl = "Tim Orling <timothy.t.orling@linux.intel.com>"
 RECIPE_MAINTAINER_pn-libcroco = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-libdaemon = "Alexander Kanavin <alex.kanavin@gmail.com>"
 RECIPE_MAINTAINER_pn-libdmx = "Armin Kuster <akuster808@gmail.com>"
@@ -327,23 +311,21 @@ RECIPE_MAINTAINER_pn-libgcc = "Khem Raj <raj.khem@gmail.com>"
 RECIPE_MAINTAINER_pn-libgcc-initial = "Khem Raj <raj.khem@gmail.com>"
 RECIPE_MAINTAINER_pn-libgcrypt = "Hongxu Jia <hongxu.jia@windriver.com>"
 RECIPE_MAINTAINER_pn-libgfortran = "Khem Raj <raj.khem@gmail.com>"
+RECIPE_MAINTAINER_pn-libgloss = "Alejandro Hernandez <aehs29@gmail.com>"
 RECIPE_MAINTAINER_pn-libglu = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-libgpg-error = "Hongxu Jia <hongxu.jia@windriver.com>"
 RECIPE_MAINTAINER_pn-libgudev = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-libical = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-libice = "Armin Kuster <akuster808@gmail.com>"
-RECIPE_MAINTAINER_pn-libiconv = "Alexander Kanavin <alex.kanavin@gmail.com>"
 RECIPE_MAINTAINER_pn-libid3tag = "Tanu Kaskinen <tanuk@iki.fi>"
 RECIPE_MAINTAINER_pn-libidn = "Alexander Kanavin <alex.kanavin@gmail.com>"
 RECIPE_MAINTAINER_pn-libinput = "Maxin B. John <maxin.john@intel.com>"
-RECIPE_MAINTAINER_pn-libjson = "Alexander Kanavin <alex.kanavin@gmail.com>"
 RECIPE_MAINTAINER_pn-libksba = "Alexander Kanavin <alex.kanavin@gmail.com>"
 RECIPE_MAINTAINER_pn-libmatchbox = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-libmnl = "Khem Raj <raj.khem@gmail.com>"
 RECIPE_MAINTAINER_pn-libmpc = "Khem Raj <raj.khem@gmail.com>"
 RECIPE_MAINTAINER_pn-libnewt = "Hongxu Jia <hongxu.jia@windriver.com>"
 RECIPE_MAINTAINER_pn-libnewt-python = "Hongxu Jia <hongxu.jia@windriver.com>"
-RECIPE_MAINTAINER_pn-libnfsidmap = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-libnl = "Alexander Kanavin <alex.kanavin@gmail.com>"
 RECIPE_MAINTAINER_pn-libnotify = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-libnsl2 = "Khem Raj <raj.khem@gmail.com>"
@@ -351,16 +333,13 @@ RECIPE_MAINTAINER_pn-libnss-mdns = "Alexander Kanavin <alex.kanavin@gmail.com>"
 RECIPE_MAINTAINER_pn-libnss-nis = "Khem Raj <raj.khem@gmail.com>"
 RECIPE_MAINTAINER_pn-libogg = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-libomxil = "Maxin B. John <maxin.john@intel.com>"
-RECIPE_MAINTAINER_pn-libowl = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-libpam = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-libpcap = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-libpciaccess = "Alexander Kanavin <alex.kanavin@gmail.com>"
 RECIPE_MAINTAINER_pn-libpcre = "Yi Zhao <yi.zhao@windriver.com>"
 RECIPE_MAINTAINER_pn-libpcre2 = "Armin Kuster <akuster808@gmail.com>"
-RECIPE_MAINTAINER_pn-libpfm4 = "Matthew McClintock <msm@freescale.com>"
 RECIPE_MAINTAINER_pn-libpipeline = "Alexander Kanavin <alex.kanavin@gmail.com>"
 RECIPE_MAINTAINER_pn-libpng = "Maxin B. John <maxin.john@intel.com>"
-RECIPE_MAINTAINER_pn-libpng12 = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-libproxy = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-libpthread-stubs = "Alexander Kanavin <alex.kanavin@gmail.com>"
 RECIPE_MAINTAINER_pn-librepo = "Alexander Kanavin <alex.kanavin@gmail.com>"
@@ -394,7 +373,6 @@ RECIPE_MAINTAINER_pn-libwebp = "Alexander Kanavin <alex.kanavin@gmail.com>"
 RECIPE_MAINTAINER_pn-libx11 = "Armin Kuster <akuster808@gmail.com>"
 RECIPE_MAINTAINER_pn-libx11-diet = "Armin Kuster <akuster808@gmail.com>"
 RECIPE_MAINTAINER_pn-libxau = "Armin Kuster <akuster808@gmail.com>"
-RECIPE_MAINTAINER_pn-libxcalibrate = "Armin Kuster <akuster808@gmail.com>"
 RECIPE_MAINTAINER_pn-libxcb = "Armin Kuster <akuster808@gmail.com>"
 RECIPE_MAINTAINER_pn-libxcomposite = "Armin Kuster <akuster808@gmail.com>"
 RECIPE_MAINTAINER_pn-libxcursor = "Armin Kuster <akuster808@gmail.com>"
@@ -422,7 +400,6 @@ RECIPE_MAINTAINER_pn-libxrandr = "Armin Kuster <akuster808@gmail.com>"
 RECIPE_MAINTAINER_pn-libxrender = "Armin Kuster <akuster808@gmail.com>"
 RECIPE_MAINTAINER_pn-libxres = "Armin Kuster <akuster808@gmail.com>"
 RECIPE_MAINTAINER_pn-libxscrnsaver = "Armin Kuster <akuster808@gmail.com>"
-RECIPE_MAINTAINER_pn-libxsettings-client = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-libxshmfence = "Armin Kuster <akuster808@gmail.com>"
 RECIPE_MAINTAINER_pn-libxslt = "Alexander Kanavin <alex.kanavin@gmail.com>"
 RECIPE_MAINTAINER_pn-libxt = "Armin Kuster <akuster808@gmail.com>"
@@ -445,7 +422,7 @@ RECIPE_MAINTAINER_pn-llvm = "Khem Raj <raj.khem@gmail.com>"
 RECIPE_MAINTAINER_pn-logrotate = "Yi Zhao <yi.zhao@windriver.com>"
 RECIPE_MAINTAINER_pn-lrzsz = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-lsb = "Hongxu Jia <hongxu.jia@windriver.com>"
-RECIPE_MAINTAINER_pn-lsbinitscripts = "Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>"
+RECIPE_MAINTAINER_pn-lsbinitscripts = "Ross Burton <ross.burton@intel.com>"
 RECIPE_MAINTAINER_pn-lsbtest = "Yi Zhao <yi.zhao@windriver.com>"
 RECIPE_MAINTAINER_pn-lsof = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-ltp = "Yi Zhao <yi.zhao@windriver.com>"
@@ -466,7 +443,6 @@ RECIPE_MAINTAINER_pn-man-db = "Hongxu Jia <hongxu.jia@windriver.com>"
 RECIPE_MAINTAINER_pn-man-pages = "Hongxu Jia <hongxu.jia@windriver.com>"
 RECIPE_MAINTAINER_pn-matchbox-config-gtk = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-matchbox-desktop = "Maxin B. John <maxin.john@intel.com>"
-RECIPE_MAINTAINER_pn-matchbox-desktop-sato = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-matchbox-keyboard = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-matchbox-panel-2 = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-matchbox-session = "Maxin B. John <maxin.john@intel.com>"
@@ -490,11 +466,9 @@ RECIPE_MAINTAINER_pn-meta-world-pkgdata = "Richard Purdie <richard.purdie@linuxf
 RECIPE_MAINTAINER_pn-mingetty = "Yi Zhao <yi.zhao@windriver.com>"
 RECIPE_MAINTAINER_pn-mini-x-session = "Armin Kuster <akuster808@gmail.com>"
 RECIPE_MAINTAINER_pn-minicom = "Maxin B. John <maxin.john@intel.com>"
-RECIPE_MAINTAINER_pn-mkelfimage = "Alexander Kanavin <alex.kanavin@gmail.com>"
 RECIPE_MAINTAINER_pn-mkfontdir = "Armin Kuster <akuster808@gmail.com>"
 RECIPE_MAINTAINER_pn-mkfontscale = "Armin Kuster <akuster808@gmail.com>"
 RECIPE_MAINTAINER_pn-mklibs-native = "Robert Yang <liezhi.yang@windriver.com>"
-RECIPE_MAINTAINER_pn-mktemp = "Robert Yang <liezhi.yang@windriver.com>"
 RECIPE_MAINTAINER_pn-mmc-utils = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-mobile-broadband-provider-info = "Alexander Kanavin <alex.kanavin@gmail.com>"
 RECIPE_MAINTAINER_pn-modutils-initscripts = "Yi Zhao <yi.zhao@windriver.com>"
@@ -513,9 +487,9 @@ RECIPE_MAINTAINER_pn-nativesdk-buildtools-perl-dummy = "Richard Purdie <richard.
 RECIPE_MAINTAINER_pn-nativesdk-libtool = "Richard Purdie <richard.purdie@linuxfoundation.org>"
 RECIPE_MAINTAINER_pn-nativesdk-packagegroup-sdk-host = "Ross Burton <ross.burton@intel.com>"
 RECIPE_MAINTAINER_pn-nativesdk-qemu-helper = "Richard Purdie <richard.purdie@linuxfoundation.org>"
+RECIPE_MAINTAINER_pn-newlib = "Alejandro Hernandez <aehs29@gmail.com>"
 RECIPE_MAINTAINER_pn-ncurses = "Hongxu Jia <hongxu.jia@windriver.com>"
 RECIPE_MAINTAINER_pn-neard = "Maxin B. John <maxin.john@intel.com>"
-RECIPE_MAINTAINER_pn-neon = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-net-tools = "Armin Kuster <akuster808@gmail.com>"
 RECIPE_MAINTAINER_pn-netbase = "Armin Kuster <akuster808@gmail.com>"
 RECIPE_MAINTAINER_pn-nettle = "Armin Kuster <akuster808@gmail.com>"
@@ -527,14 +501,12 @@ RECIPE_MAINTAINER_pn-nspr = "Armin Kuster <akuster808@gmail.com>"
 RECIPE_MAINTAINER_pn-nss = "Armin Kuster <akuster808@gmail.com>"
 RECIPE_MAINTAINER_pn-nss-myhostname = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-ofono = "Maxin B. John <maxin.john@intel.com>"
-RECIPE_MAINTAINER_pn-oh-puzzles = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-openssh = "Armin Kuster <akuster808@gmail.com>"
 RECIPE_MAINTAINER_pn-openssl = "Alexander Kanavin <alex.kanavin@gmail.com>"
 RECIPE_MAINTAINER_pn-opkg = "Alejandro del Castillo <alejandro.delcastillo@ni.com>"
 RECIPE_MAINTAINER_pn-opkg-arch-config = "Alejandro del Castillo <alejandro.delcastillo@ni.com>"
 RECIPE_MAINTAINER_pn-opkg-keyrings = "Alejandro del Castillo <alejandro.delcastillo@ni.com>"
 RECIPE_MAINTAINER_pn-opkg-utils = "Alejandro del Castillo <alejandro.delcastillo@ni.com>"
-RECIPE_MAINTAINER_pn-oprofile = "Alexander Kanavin <alex.kanavin@gmail.com>"
 RECIPE_MAINTAINER_pn-orc = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-os-release = "Ross Burton <ross.burton@intel.com>"
 RECIPE_MAINTAINER_pn-ossp-uuid = "Alexander Kanavin <alex.kanavin@gmail.com>"
@@ -608,14 +580,12 @@ RECIPE_MAINTAINER_pn-quilt-native = "Robert Yang <liezhi.yang@windriver.com>"
 RECIPE_MAINTAINER_pn-quota = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-re2c = "Khem Raj <raj.khem@gmail.com>"
 RECIPE_MAINTAINER_pn-readline = "Hongxu Jia <hongxu.jia@windriver.com>"
-RECIPE_MAINTAINER_pn-remake = "Robert Yang <liezhi.yang@windriver.com>"
 RECIPE_MAINTAINER_pn-resolvconf = "Chen Qi <Qi.Chen@windriver.com>"
 RECIPE_MAINTAINER_pn-rgb = "Armin Kuster <akuster808@gmail.com>"
 RECIPE_MAINTAINER_pn-rpcbind = "Hongxu Jia <hongxu.jia@windriver.com>"
 RECIPE_MAINTAINER_pn-rng-tools = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-rpcsvc-proto = "Khem Raj <raj.khem@gmail.com>"
 RECIPE_MAINTAINER_pn-rpm = "Mark Hatle <mark.hatle@windriver.com>"
-RECIPE_MAINTAINER_pn-rpmresolve = "Mark Hatle <mark.hatle@windriver.com>"
 RECIPE_MAINTAINER_pn-rsync = "Yi Zhao <yi.zhao@windriver.com>"
 RECIPE_MAINTAINER_pn-rt-tests = "Alexander Kanavin <alex.kanavin@gmail.com>"
 RECIPE_MAINTAINER_pn-ruby = "Maxin B. John <maxin.john@intel.com>"
@@ -646,7 +616,6 @@ RECIPE_MAINTAINER_pn-strace = "Robert Yang <liezhi.yang@windriver.com>"
 RECIPE_MAINTAINER_pn-stress = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-subversion = "Richard Purdie <richard.purdie@linuxfoundation.org>"
 RECIPE_MAINTAINER_pn-sudo = "Chen Qi <Qi.Chen@windriver.com>"
-RECIPE_MAINTAINER_pn-swabber-native = "Alexander Kanavin <alex.kanavin@gmail.com>"
 RECIPE_MAINTAINER_pn-swig = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-sysfsutils = "Chen Qi <Qi.Chen@windriver.com>"
 RECIPE_MAINTAINER_pn-sysklogd = "Chen Qi <Qi.Chen@windriver.com>"
@@ -660,13 +629,13 @@ RECIPE_MAINTAINER_pn-systemd-bootconf = "Chen Qi <Qi.Chen@windriver.com>"
 RECIPE_MAINTAINER_pn-systemd-compat-units = "Chen Qi <Qi.Chen@windriver.com>"
 RECIPE_MAINTAINER_pn-systemd-serialgetty = "Chen Qi <Qi.Chen@windriver.com>"
 RECIPE_MAINTAINER_pn-systemd-systemctl-native = "Chen Qi <Qi.Chen@windriver.com>"
-RECIPE_MAINTAINER_pn-systemtap = "Alexander Kanavin <alex.kanavin@gmail.com>"
-RECIPE_MAINTAINER_pn-systemtap-uprobes = "Alexander Kanavin <alex.kanavin@gmail.com>"
-RECIPE_MAINTAINER_pn-sysvinit = "Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>"
-RECIPE_MAINTAINER_pn-sysvinit-inittab = "Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>"
+RECIPE_MAINTAINER_pn-systemtap = "Victor Kamensky <kamensky@cisco.com>"
+RECIPE_MAINTAINER_pn-systemtap-uprobes = "Victor Kamensky <kamensky@cisco.com>"
+RECIPE_MAINTAINER_pn-sysvinit = "Ross Burton <ross.burton@intel.com>"
+RECIPE_MAINTAINER_pn-sysvinit-inittab = "Ross Burton <ross.burton@intel.com>"
 RECIPE_MAINTAINER_pn-taglib = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-tar = "Chen Qi <Qi.Chen@windriver.com>"
-RECIPE_MAINTAINER_pn-tcf-agent = "Randy Witt <randy.e.witt@linux.intel.com>"
+RECIPE_MAINTAINER_pn-tcf-agent = "Ross Burton <ross.burton@intel.com>"
 RECIPE_MAINTAINER_pn-tcl = "Yi Zhao <yi.zhao@windriver.com>"
 RECIPE_MAINTAINER_pn-tcp-wrappers = "Robert Yang <liezhi.yang@windriver.com>"
 RECIPE_MAINTAINER_pn-testexport-tarball = "Richard Purdie <richard.purdie@linuxfoundation.org>"
@@ -675,21 +644,18 @@ RECIPE_MAINTAINER_pn-texinfo = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-texinfo-dummy-native = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-tiff = "Alexander Kanavin <alex.kanavin@gmail.com>"
 RECIPE_MAINTAINER_pn-time = "Robert Yang <liezhi.yang@windriver.com>"
-RECIPE_MAINTAINER_pn-tiny-init = "Alexander Kanavin <alex.kanavin@gmail.com>"
-RECIPE_MAINTAINER_pn-trace-cmd = "Alexander Kanavin <alex.kanavin@gmail.com>"
 RECIPE_MAINTAINER_pn-ttf-bitstream-vera = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-tzcode-native = "Armin Kuster <akuster808@gmail.com>"
 RECIPE_MAINTAINER_pn-tzdata = "Armin Kuster <akuster808@gmail.com>"
 RECIPE_MAINTAINER_pn-u-boot = "Marek Vasut <marek.vasut@gmail.com>"
 RECIPE_MAINTAINER_pn-u-boot-fw-utils = "Marek Vasut <marek.vasut@gmail.com>"
 RECIPE_MAINTAINER_pn-u-boot-mkimage = "Marek Vasut <marek.vasut@gmail.com>"
-RECIPE_MAINTAINER_pn-ubootchart = "Ross Burton <ross.burton@intel.com>"
 RECIPE_MAINTAINER_pn-udev-extraconf = "Maxin B. John <maxin.john@intel.com>"
-RECIPE_MAINTAINER_pn-unfs3 = "Randy Witt <randy.e.witt@linux.intel.com>"
+RECIPE_MAINTAINER_pn-unfs3 = "Ross Burton <ross.burton@intel.com>"
 RECIPE_MAINTAINER_pn-unifdef = "Ross Burton <ross.burton@intel.com>"
 RECIPE_MAINTAINER_pn-uninative-tarball = "Richard Purdie <richard.purdie@linuxfoundation.org>"
 RECIPE_MAINTAINER_pn-unzip = "Denys Dmytriyenko <denys@ti.com>"
-RECIPE_MAINTAINER_pn-update-rc.d = "Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>"
+RECIPE_MAINTAINER_pn-update-rc.d = "Ross Burton <ross.burton@intel.com>"
 RECIPE_MAINTAINER_pn-usbinit = "Alexander Kanavin <alex.kanavin@gmail.com>"
 RECIPE_MAINTAINER_pn-usbutils = "Alexander Kanavin <alex.kanavin@gmail.com>"
 RECIPE_MAINTAINER_pn-util-linux = "Chen Qi <Qi.Chen@windriver.com>"
@@ -711,9 +677,8 @@ RECIPE_MAINTAINER_pn-weston = "Denys Dmytriyenko <denys@ti.com>"
 RECIPE_MAINTAINER_pn-weston-init = "Denys Dmytriyenko <denys@ti.com>"
 RECIPE_MAINTAINER_pn-wget = "Yi Zhao <yi.zhao@windriver.com>"
 RECIPE_MAINTAINER_pn-which = "Maxin B. John <maxin.john@intel.com>"
-RECIPE_MAINTAINER_pn-wic-tools = "Chang Rebecca Swee Fun <rebecca.swee.fun.chang@intel.com>"
+RECIPE_MAINTAINER_pn-wic-tools = "Ross Burton <ross.burton@intel.com>"
 RECIPE_MAINTAINER_pn-wpa-supplicant = "Changhyeok Bae <changhyeok.bae@lge.com>"
-RECIPE_MAINTAINER_pn-x11-common = "Armin Kuster <akuster808@gmail.com>"
 RECIPE_MAINTAINER_pn-x11perf = "Armin Kuster <akuster808@gmail.com>"
 RECIPE_MAINTAINER_pn-x264 = "Anuj Mittal <anuj.mittal@intel.com>"
 RECIPE_MAINTAINER_pn-xauth = "Armin Kuster <akuster808@gmail.com>"
@@ -737,8 +702,6 @@ RECIPE_MAINTAINER_pn-xf86-input-vmmouse = "Armin Kuster <akuster808@gmail.com>"
 RECIPE_MAINTAINER_pn-xf86-video-cirrus = "Armin Kuster <akuster808@gmail.com>"
 RECIPE_MAINTAINER_pn-xf86-video-fbdev = "Armin Kuster <akuster808@gmail.com>"
 RECIPE_MAINTAINER_pn-xf86-video-intel = "Armin Kuster <akuster808@gmail.com>"
-RECIPE_MAINTAINER_pn-xf86-video-omap = "Armin Kuster <akuster808@gmail.com>"
-RECIPE_MAINTAINER_pn-xf86-video-omapfb = "Armin Kuster <akuster808@gmail.com>"
 RECIPE_MAINTAINER_pn-xf86-video-vesa = "Armin Kuster <akuster808@gmail.com>"
 RECIPE_MAINTAINER_pn-xf86-video-vmware = "Armin Kuster <akuster808@gmail.com>"
 RECIPE_MAINTAINER_pn-xhost = "Armin Kuster <akuster808@gmail.com>"

meta/conf/distro/include/tclibc-newlib.inc

@@ -0,0 +1,44 @@
+#
+# Newlib configuration
+#
+
+LIBCEXTENSION = "-newlib"
+LIBCOVERRIDE = ":libc-newlib"
+
+PREFERRED_PROVIDER_virtual/libc ?= "newlib"
+PREFERRED_PROVIDER_virtual/libiconv ?= "newlib"
+PREFERRED_PROVIDER_virtual/libintl ?= "newlib"
+PREFERRED_PROVIDER_virtual/nativesdk-libintl ?= "nativesdk-glibc"
+PREFERRED_PROVIDER_virtual/nativesdk-libiconv ?= "nativesdk-glibc"
+
+DISTRO_FEATURES_BACKFILL_CONSIDERED += "ldconfig"
+
+#USE_NLS ?= "no"
+
+IMAGE_LINGUAS = ""
+
+LIBC_DEPENDENCIES = "\
+    newlib-dbg \
+    newlib-dev \
+    libgloss \
+    libgloss-dev \
+    libgloss-dbg \
+    libgcc-dev \
+    libgcc-dbg \
+    "
+
+# compilerlibs defaults to gcc-runtime, but we get runtime from libgloss
+# we set ASSUME_PROVIDED because we cant set PREFERRED_PROVIDER
+# for compilerlibs since its overridden by tcmode-default
+ASSUME_PROVIDED += "virtual/${TARGET_PREFIX}compilerlibs virtual/crypt"
+
+# Its useful to be able to extend newlib, but we dont provide a native variant of libgloss
+NEWLIB_EXTENDED ?=  "libgloss libgcc"
+BASE_DEFAULT_DEPS_append_class-target = " ${NEWLIB_EXTENDED}"
+
+TARGET_OS = "elf"
+TARGET_OS_arm = "eabi"
+
+TOOLCHAIN_HOST_TASK ?= "packagegroup-cross-canadian-${MACHINE}"
+TOOLCHAIN_TARGET_TASK ?= "${LIBC_DEPENDENCIES}"
+TOOLCHAIN_NEED_CONFIGSITE_CACHE_remove = "zlib ncurses"

meta/conf/distro/include/yocto-uninative.inc

@@ -8,6 +8,6 @@
 
 UNINATIVE_MAXGLIBCVERSION = "2.27"
 
-UNINATIVE_URL ?= "http://downloads.yoctoproject.org/releases/uninative/1.9/"
-UNINATIVE_CHECKSUM[i686] ?= "83a4f927da81d9889ef0cbe5c12cb782e21c6cc11e6155600b94ff0c99576dce"
-UNINATIVE_CHECKSUM[x86_64] ?= "c26622a1f27dbf5b25de986b11584b5c5b2f322d9eb367f705a744f58a5561ec"
+UNINATIVE_URL ?= "http://downloads.yoctoproject.org/releases/uninative/2.1/"
+UNINATIVE_CHECKSUM[i686] ?= "a90db17d8845ece764aaac19348cd78504c0e554cb998da39ebad03aeef76185"
+UNINATIVE_CHECKSUM[x86_64] ?= "d43555df8d5a056ef5b20c7d8e0287207974e09df1e969a3e19302c8b4ea6b4b"

meta/conf/documentation.conf

@@ -288,8 +288,6 @@ MULTIMACH_TARGET_SYS[doc] = "Separates files for different machines such that yo
 
 NATIVELSBSTRING[doc] = "A string identifying the host distribution."
 NO_RECOMMENDATIONS[doc] = "When set to '1', no recommended packages will be installed. Realize that some recommended packages might be required for certain system functionality, such as kernel-modules. It is up to the user to add packages to IMAGE_INSTALL as needed."
-NOHDD[doc] = "Causes the OpenEmbedded build system to skip building the .hddimg image."
-NOISO[doc] = "Causes the OpenEmbedded build system to skip building the ISO image."
 
 #O
 
@@ -417,7 +415,7 @@ TARGET_PREFIX[doc] = "The prefix for the cross-compile toolchain (e.g. arm-linux
 TARGET_SYS[doc] = "The target system is comprised of TARGET_ARCH,TARGET_VENDOR and TARGET_OS."
 TCLIBC[doc] = "Specifies C library (libc) variant to use during the build process. You can select 'baremetal', 'glibc' or 'musl'."
 TCMODE[doc] = "Enables an external toolchain (where provided by an additional layer) if set to a value other than 'default'."
-TEST_IMAGE[doc] = "Enables test booting of virtual machine images under the QEMU emulator after any root filesystems are created and runs tests against those images."
+TESTIMAGE_AUTO[doc] = "Enables test booting of virtual machine images under the QEMU emulator after any root filesystems are created and runs tests against those images each time an image is built."
 TEST_QEMUBOOT_TIMEOUT[doc] = "The time in seconds allowed for an image to boot before automated runtime tests begin to run against an image."
 TEST_SUITES[doc] = "An ordered list of tests (modules) to run against an image when performing automated runtime testing."
 TEST_POWERCONTROL_CMD[doc] = "For automated hardware testing, specifies the command to use to control the power of the target machine under test"

meta/conf/licenses.conf

@@ -16,7 +16,7 @@ SRC_DISTRIBUTE_LICENSES += "CC-BY-SA-1.0 CC-BY-SA-2.0 CC-BY-SA-2.5 CC-BY-SA-3.0"
 SRC_DISTRIBUTE_LICENSES += "CDDL-1.0 CECILL-1.0 CECILL-2.0 CECILL-B CECILL-C"
 SRC_DISTRIBUTE_LICENSES += "ClArtistic CPAL-1.0 CPL-1.0 CUA-OPL-1.0 DSSSL"
 SRC_DISTRIBUTE_LICENSES += "ECL-1.0 ECL-2.0 eCos-2.0 EDL-1.0 EFL-1.0 EFL-2.0"
-SRC_DISTRIBUTE_LICENSES += "Elfutils-Exception Entessa EPL-1.0 ErlPL-1.1"
+SRC_DISTRIBUTE_LICENSES += "Elfutils-Exception Entessa EPL-1.0 EPL-2.0 ErlPL-1.1"
 SRC_DISTRIBUTE_LICENSES += "EUDatagrid EUPL-1.0 EUPL-1.1 Fair Frameworx-1.0"
 SRC_DISTRIBUTE_LICENSES += "FreeType GFDL-1.1 GFDL-1.2 GFDL-1.3 GPL-1.0"
 SRC_DISTRIBUTE_LICENSES += "GPL-2.0 GPL-2.0-with-autoconf-exception"

meta/conf/machine/include/arm/arch-armv7a.inc

@@ -1,4 +1,5 @@
 DEFAULTTUNE ?= "armv7athf"
+ARM_INSTRUCTION_SET ?= "thumb"
 
 TUNEVALID[armv7a] = "Enable instructions for ARMv7-a"
 TUNECONFLICTS[armv7a] = "armv4 armv5 armv6 armv7"

meta/conf/machine/include/x86-base.inc

@@ -10,8 +10,7 @@ MACHINE_FEATURES += "screen keyboard pci usbhost ext2 ext3 x86 \
 
 MACHINE_EXTRA_RRECOMMENDS += "kernel-modules"
 
-IMAGE_FSTYPES ?= "live"
-NOISO ?= "1"
+IMAGE_FSTYPES ?= "hddimg"
 
 KERNEL_IMAGETYPE ?= "bzImage"
 

meta/conf/machine/qemux86-64.conf

@@ -12,6 +12,8 @@ DEFAULTTUNE ?= "core2-64"
 require conf/machine/include/tune-core2.inc
 require conf/machine/include/qemuboot-x86.inc
 
+UBOOT_MACHINE ?= "qemu-x86_64_defconfig"
+
 KERNEL_IMAGETYPE = "bzImage"
 
 SERIAL_CONSOLES ?= "115200;ttyS0 115200;ttyS1"

meta/conf/machine/qemux86.conf

@@ -11,6 +11,8 @@ require conf/machine/include/qemu.inc
 require conf/machine/include/tune-i586.inc
 require conf/machine/include/qemuboot-x86.inc
 
+UBOOT_MACHINE ?= "qemu-x86_defconfig"
+
 KERNEL_IMAGETYPE = "bzImage"
 
 SERIAL_CONSOLES ?= "115200;ttyS0 115200;ttyS1"

meta/files/common-licenses/EPL-2.0

@@ -0,0 +1,277 @@
+Eclipse Public License - v 2.0
+
+    THE ACCOMPANYING PROGRAM IS PROVIDED UNDER THE TERMS OF THIS ECLIPSE
+    PUBLIC LICENSE ("AGREEMENT"). ANY USE, REPRODUCTION OR DISTRIBUTION
+    OF THE PROGRAM CONSTITUTES RECIPIENT'S ACCEPTANCE OF THIS AGREEMENT.
+
+1. DEFINITIONS
+
+"Contribution" means:
+
+  a) in the case of the initial Contributor, the initial content
+     Distributed under this Agreement, and
+
+  b) in the case of each subsequent Contributor:
+     i) changes to the Program, and
+     ii) additions to the Program;
+  where such changes and/or additions to the Program originate from
+  and are Distributed by that particular Contributor. A Contribution
+  "originates" from a Contributor if it was added to the Program by
+  such Contributor itself or anyone acting on such Contributor's behalf.
+  Contributions do not include changes or additions to the Program that
+  are not Modified Works.
+
+"Contributor" means any person or entity that Distributes the Program.
+
+"Licensed Patents" mean patent claims licensable by a Contributor which
+are necessarily infringed by the use or sale of its Contribution alone
+or when combined with the Program.
+
+"Program" means the Contributions Distributed in accordance with this
+Agreement.
+
+"Recipient" means anyone who receives the Program under this Agreement
+or any Secondary License (as applicable), including Contributors.
+
+"Derivative Works" shall mean any work, whether in Source Code or other
+form, that is based on (or derived from) the Program and for which the
+editorial revisions, annotations, elaborations, or other modifications
+represent, as a whole, an original work of authorship.
+
+"Modified Works" shall mean any work in Source Code or other form that
+results from an addition to, deletion from, or modification of the
+contents of the Program, including, for purposes of clarity any new file
+in Source Code form that contains any contents of the Program. Modified
+Works shall not include works that contain only declarations,
+interfaces, types, classes, structures, or files of the Program solely
+in each case in order to link to, bind by name, or subclass the Program
+or Modified Works thereof.
+
+"Distribute" means the acts of a) distributing or b) making available
+in any manner that enables the transfer of a copy.
+
+"Source Code" means the form of a Program preferred for making
+modifications, including but not limited to software source code,
+documentation source, and configuration files.
+
+"Secondary License" means either the GNU General Public License,
+Version 2.0, or any later versions of that license, including any
+exceptions or additional permissions as identified by the initial
+Contributor.
+
+2. GRANT OF RIGHTS
+
+  a) Subject to the terms of this Agreement, each Contributor hereby
+  grants Recipient a non-exclusive, worldwide, royalty-free copyright
+  license to reproduce, prepare Derivative Works of, publicly display,
+  publicly perform, Distribute and sublicense the Contribution of such
+  Contributor, if any, and such Derivative Works.
+
+  b) Subject to the terms of this Agreement, each Contributor hereby
+  grants Recipient a non-exclusive, worldwide, royalty-free patent
+  license under Licensed Patents to make, use, sell, offer to sell,
+  import and otherwise transfer the Contribution of such Contributor,
+  if any, in Source Code or other form. This patent license shall
+  apply to the combination of the Contribution and the Program if, at
+  the time the Contribution is added by the Contributor, such addition
+  of the Contribution causes such combination to be covered by the
+  Licensed Patents. The patent license shall not apply to any other
+  combinations which include the Contribution. No hardware per se is
+  licensed hereunder.
+
+  c) Recipient understands that although each Contributor grants the
+  licenses to its Contributions set forth herein, no assurances are
+  provided by any Contributor that the Program does not infringe the
+  patent or other intellectual property rights of any other entity.
+  Each Contributor disclaims any liability to Recipient for claims
+  brought by any other entity based on infringement of intellectual
+  property rights or otherwise. As a condition to exercising the
+  rights and licenses granted hereunder, each Recipient hereby
+  assumes sole responsibility to secure any other intellectual
+  property rights needed, if any. For example, if a third party
+  patent license is required to allow Recipient to Distribute the
+  Program, it is Recipient's responsibility to acquire that license
+  before distributing the Program.
+
+  d) Each Contributor represents that to its knowledge it has
+  sufficient copyright rights in its Contribution, if any, to grant
+  the copyright license set forth in this Agreement.
+
+  e) Notwithstanding the terms of any Secondary License, no
+  Contributor makes additional grants to any Recipient (other than
+  those set forth in this Agreement) as a result of such Recipient's
+  receipt of the Program under the terms of a Secondary License
+  (if permitted under the terms of Section 3).
+
+3. REQUIREMENTS
+
+3.1 If a Contributor Distributes the Program in any form, then:
+
+  a) the Program must also be made available as Source Code, in
+  accordance with section 3.2, and the Contributor must accompany
+  the Program with a statement that the Source Code for the Program
+  is available under this Agreement, and informs Recipients how to
+  obtain it in a reasonable manner on or through a medium customarily
+  used for software exchange; and
+
+  b) the Contributor may Distribute the Program under a license
+  different than this Agreement, provided that such license:
+     i) effectively disclaims on behalf of all other Contributors all
+     warranties and conditions, express and implied, including
+     warranties or conditions of title and non-infringement, and
+     implied warranties or conditions of merchantability and fitness
+     for a particular purpose;
+
+     ii) effectively excludes on behalf of all other Contributors all
+     liability for damages, including direct, indirect, special,
+     incidental and consequential damages, such as lost profits;
+
+     iii) does not attempt to limit or alter the recipients' rights
+     in the Source Code under section 3.2; and
+
+     iv) requires any subsequent distribution of the Program by any
+     party to be under a license that satisfies the requirements
+     of this section 3.
+
+3.2 When the Program is Distributed as Source Code:
+
+  a) it must be made available under this Agreement, or if the
+  Program (i) is combined with other material in a separate file or
+  files made available under a Secondary License, and (ii) the initial
+  Contributor attached to the Source Code the notice described in
+  Exhibit A of this Agreement, then the Program may be made available
+  under the terms of such Secondary Licenses, and
+
+  b) a copy of this Agreement must be included with each copy of
+  the Program.
+
+3.3 Contributors may not remove or alter any copyright, patent,
+trademark, attribution notices, disclaimers of warranty, or limitations
+of liability ("notices") contained within the Program from any copy of
+the Program which they Distribute, provided that Contributors may add
+their own appropriate notices.
+
+4. COMMERCIAL DISTRIBUTION
+
+Commercial distributors of software may accept certain responsibilities
+with respect to end users, business partners and the like. While this
+license is intended to facilitate the commercial use of the Program,
+the Contributor who includes the Program in a commercial product
+offering should do so in a manner which does not create potential
+liability for other Contributors. Therefore, if a Contributor includes
+the Program in a commercial product offering, such Contributor
+("Commercial Contributor") hereby agrees to defend and indemnify every
+other Contributor ("Indemnified Contributor") against any losses,
+damages and costs (collectively "Losses") arising from claims, lawsuits
+and other legal actions brought by a third party against the Indemnified
+Contributor to the extent caused by the acts or omissions of such
+Commercial Contributor in connection with its distribution of the Program
+in a commercial product offering. The obligations in this section do not
+apply to any claims or Losses relating to any actual or alleged
+intellectual property infringement. In order to qualify, an Indemnified
+Contributor must: a) promptly notify the Commercial Contributor in
+writing of such claim, and b) allow the Commercial Contributor to control,
+and cooperate with the Commercial Contributor in, the defense and any
+related settlement negotiations. The Indemnified Contributor may
+participate in any such claim at its own expense.
+
+For example, a Contributor might include the Program in a commercial
+product offering, Product X. That Contributor is then a Commercial
+Contributor. If that Commercial Contributor then makes performance
+claims, or offers warranties related to Product X, those performance
+claims and warranties are such Commercial Contributor's responsibility
+alone. Under this section, the Commercial Contributor would have to
+defend claims against the other Contributors related to those performance
+claims and warranties, and if a court requires any other Contributor to
+pay any damages as a result, the Commercial Contributor must pay
+those damages.
+
+5. NO WARRANTY
+
+EXCEPT AS EXPRESSLY SET FORTH IN THIS AGREEMENT, AND TO THE EXTENT
+PERMITTED BY APPLICABLE LAW, THE PROGRAM IS PROVIDED ON AN "AS IS"
+BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, EITHER EXPRESS OR
+IMPLIED INCLUDING, WITHOUT LIMITATION, ANY WARRANTIES OR CONDITIONS OF
+TITLE, NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR
+PURPOSE. Each Recipient is solely responsible for determining the
+appropriateness of using and distributing the Program and assumes all
+risks associated with its exercise of rights under this Agreement,
+including but not limited to the risks and costs of program errors,
+compliance with applicable laws, damage to or loss of data, programs
+or equipment, and unavailability or interruption of operations.
+
+6. DISCLAIMER OF LIABILITY
+
+EXCEPT AS EXPRESSLY SET FORTH IN THIS AGREEMENT, AND TO THE EXTENT
+PERMITTED BY APPLICABLE LAW, NEITHER RECIPIENT NOR ANY CONTRIBUTORS
+SHALL HAVE ANY LIABILITY FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
+EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING WITHOUT LIMITATION LOST
+PROFITS), 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 OR DISTRIBUTION OF THE PROGRAM OR THE
+EXERCISE OF ANY RIGHTS GRANTED HEREUNDER, EVEN IF ADVISED OF THE
+POSSIBILITY OF SUCH DAMAGES.
+
+7. GENERAL
+
+If any provision of this Agreement is invalid or unenforceable under
+applicable law, it shall not affect the validity or enforceability of
+the remainder of the terms of this Agreement, and without further
+action by the parties hereto, such provision shall be reformed to the
+minimum extent necessary to make such provision valid and enforceable.
+
+If Recipient institutes patent litigation against any entity
+(including a cross-claim or counterclaim in a lawsuit) alleging that the
+Program itself (excluding combinations of the Program with other software
+or hardware) infringes such Recipient's patent(s), then such Recipient's
+rights granted under Section 2(b) shall terminate as of the date such
+litigation is filed.
+
+All Recipient's rights under this Agreement shall terminate if it
+fails to comply with any of the material terms or conditions of this
+Agreement and does not cure such failure in a reasonable period of
+time after becoming aware of such noncompliance. If all Recipient's
+rights under this Agreement terminate, Recipient agrees to cease use
+and distribution of the Program as soon as reasonably practicable.
+However, Recipient's obligations under this Agreement and any licenses
+granted by Recipient relating to the Program shall continue and survive.
+
+Everyone is permitted to copy and distribute copies of this Agreement,
+but in order to avoid inconsistency the Agreement is copyrighted and
+may only be modified in the following manner. The Agreement Steward
+reserves the right to publish new versions (including revisions) of
+this Agreement from time to time. No one other than the Agreement
+Steward has the right to modify this Agreement. The Eclipse Foundation
+is the initial Agreement Steward. The Eclipse Foundation may assign the
+responsibility to serve as the Agreement Steward to a suitable separate
+entity. Each new version of the Agreement will be given a distinguishing
+version number. The Program (including Contributions) may always be
+Distributed subject to the version of the Agreement under which it was
+received. In addition, after a new version of the Agreement is published,
+Contributor may elect to Distribute the Program (including its
+Contributions) under the new version.
+
+Except as expressly stated in Sections 2(a) and 2(b) above, Recipient
+receives no rights or licenses to the intellectual property of any
+Contributor under this Agreement, whether expressly, by implication,
+estoppel or otherwise. All rights in the Program not expressly granted
+under this Agreement are reserved. Nothing in this Agreement is intended
+to be enforceable by any entity that is not a Contributor or Recipient.
+No third-party beneficiary rights are created under this Agreement.
+
+Exhibit A - Form of Secondary Licenses Notice
+
+"This Source Code may also be made available under the following
+Secondary Licenses when the conditions for such availability set forth
+in the Eclipse Public License, v. 2.0 are satisfied: {name license(s),
+version(s), and exceptions or additional permissions here}."
+
+  Simply including a copy of this Agreement, including this Exhibit A
+  is not sufficient to license the Source Code under Secondary Licenses.
+
+  If it is not possible or desirable to put the notice in a particular
+  file, then You may include the notice in a location (such as a LICENSE
+  file in a relevant directory) where a recipient would be likely to
+  look for such a notice.
+
+  You may add additional accurate notices of copyright ownership.

meta/lib/bblayers/create.py

@@ -30,8 +30,10 @@ class CreatePlugin(LayerPlugin):
         conf = os.path.join(layerdir, 'conf')
         bb.utils.mkdirhier(conf)
 
+        layername = os.path.basename(os.path.normpath(args.layerdir))
+
         # Create the README from templates/README
-        readme_template =  read_template('README') % (args.layerdir, args.layerdir, args.layerdir, args.layerdir, args.layerdir, args.layerdir)
+        readme_template =  read_template('README').format(layername=layername)
         readme = os.path.join(layerdir, 'README')
         with open(readme, 'w') as fd:
             fd.write(readme_template)
@@ -43,8 +45,12 @@ class CreatePlugin(LayerPlugin):
         license_dst = os.path.join(layerdir, copying)
         shutil.copy(license_src, license_dst)
 
+        # Get the compat value for core layer.
+        compat = self.tinfoil.config_data.getVar('LAYERSERIES_COMPAT_core') or ""
+
         # Create the layer.conf from templates/layer.conf
-        layerconf_template = read_template('layer.conf') % (args.layerdir, args.layerdir, args.layerdir, args.priority)
+        layerconf_template = read_template('layer.conf').format(
+                layername=layername, priority=args.priority, compat=compat)
         layerconf = os.path.join(conf, 'layer.conf')
         with open(layerconf, 'w') as fd:
             fd.write(layerconf_template)
@@ -53,7 +59,7 @@ class CreatePlugin(LayerPlugin):
         example_template = read_template('example.bb')
         example = os.path.join(layerdir, 'recipes-' + args.examplerecipe, args.examplerecipe)
         bb.utils.mkdirhier(example)
-        with open(os.path.join(example, args.examplerecipe + '.bb'), 'w') as fd:
+        with open(os.path.join(example, args.examplerecipe + '_%s.bb') % args.version, 'w') as fd:
             fd.write(example_template)
 
         logger.plain('Add your new layer with \'bitbake-layers add-layer %s\'' % args.layerdir)
@@ -63,4 +69,5 @@ class CreatePlugin(LayerPlugin):
         parser_create_layer.add_argument('layerdir', help='Layer directory to create')
         parser_create_layer.add_argument('--priority', '-p', default=6, help='Layer directory to create')
         parser_create_layer.add_argument('--example-recipe-name', '-e', dest='examplerecipe', default='example', help='Filename of the example recipe')
+        parser_create_layer.add_argument('--example-recipe-version', '-v', dest='version', default='0.1', help='Version number for the example recipe')
 

meta/lib/bblayers/templates/README

@@ -1,4 +1,4 @@
-This README file contains information on the contents of the %s layer.
+This README file contains information on the contents of the {layername} layer.
 
 Please see the corresponding sections below for details.
 
@@ -18,7 +18,7 @@ Dependencies
 Patches
 =======
 
-Please submit any patches against the %s layer to the xxxx mailing list (xxxx@zzzz.org)
+Please submit any patches against the {layername} layer to the xxxx mailing list (xxxx@zzzz.org)
 and cc: the maintainer:
 
 Maintainer: XXX YYYYYY <xxx.yyyyyy@zzzzz.com>
@@ -26,16 +26,16 @@ Maintainer: XXX YYYYYY <xxx.yyyyyy@zzzzz.com>
 Table of Contents
 =================
 
-  I. Adding the %s layer to your build
+  I. Adding the {layername} layer to your build
  II. Misc
 
 
-I. Adding the %s layer to your build
+I. Adding the {layername} layer to your build
 =================================================
 
-Run 'bitbake-layers add-layer %s'
+Run 'bitbake-layers add-layer {layername}'
 
 II. Misc
 ========
 
---- replace with specific information about the %s layer ---
+--- replace with specific information about the {layername} layer ---

meta/lib/bblayers/templates/layer.conf

@@ -1,10 +1,13 @@
 # We have a conf and classes directory, add to BBPATH
-BBPATH .= ":${LAYERDIR}"
+BBPATH .= ":${{LAYERDIR}}"
 
 # We have recipes-* directories, add to BBFILES
-BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
-            ${LAYERDIR}/recipes-*/*/*.bbappend"
+BBFILES += "${{LAYERDIR}}/recipes-*/*/*.bb \
+            ${{LAYERDIR}}/recipes-*/*/*.bbappend"
 
-BBFILE_COLLECTIONS += "%s"
-BBFILE_PATTERN_%s = "^${LAYERDIR}/"
-BBFILE_PRIORITY_%s = "%s"
+BBFILE_COLLECTIONS += "{layername}"
+BBFILE_PATTERN_{layername} = "^${{LAYERDIR}}/"
+BBFILE_PRIORITY_{layername} = "{priority}"
+
+LAYERDEPENDS_{layername} = "core"
+LAYERSERIES_COMPAT_{layername} = "{compat}"

meta/lib/oe/buildhistory_analysis.py

@@ -13,6 +13,7 @@ import os.path
 import difflib
 import git
 import re
+import shlex
 import hashlib
 import collections
 import bb.utils
@@ -31,13 +32,6 @@ ver_monitor_fields = ['PKGE', 'PKGV', 'PKGR']
 monitor_numeric_threshold = 10
 # Image files to monitor (note that image-info.txt is handled separately)
 img_monitor_files = ['installed-package-names.txt', 'files-in-image.txt']
-# Related context fields for reporting (note: PE, PV & PR are always reported for monitored package fields)
-related_fields = {}
-related_fields['RDEPENDS'] = ['DEPENDS']
-related_fields['RRECOMMENDS'] = ['DEPENDS']
-related_fields['FILELIST'] = ['FILES']
-related_fields['files-in-image.txt'] = ['installed-package-names.txt', 'USER_CLASSES', 'IMAGE_CLASSES', 'ROOTFS_POSTPROCESS_COMMAND', 'IMAGE_POSTPROCESS_COMMAND']
-related_fields['installed-package-names.txt'] = ['IMAGE_FEATURES', 'IMAGE_LINGUAS', 'IMAGE_INSTALL', 'BAD_RECOMMENDATIONS', 'NO_RECOMMENDATIONS', 'PACKAGE_EXCLUDE']
 
 colours = {
     'colour_default': '',
@@ -67,7 +61,6 @@ class ChangeRecord:
         self.oldvalue = oldvalue
         self.newvalue = newvalue
         self.monitored = monitored
-        self.related = []
         self.filechanges = None
 
     def __str__(self):
@@ -123,10 +116,13 @@ class ChangeRecord:
                 aitems = pkglist_combine(depvera)
                 bitems = pkglist_combine(depverb)
             else:
-                aitems = self.oldvalue.split()
-                bitems = self.newvalue.split()
                 if self.fieldname == 'FILELIST':
+                    aitems = shlex.split(self.oldvalue)
+                    bitems = shlex.split(self.newvalue)
                     renamed_dirs, aitems, bitems = detect_renamed_dirs(aitems, bitems)
+                else:
+                    aitems = self.oldvalue.split()
+                    bitems = self.newvalue.split()
 
             removed = list(set(aitems) - set(bitems))
             added = list(set(bitems) - set(aitems))
@@ -206,13 +202,6 @@ class ChangeRecord:
         else:
             out = '{} changed from "{colour_remove}{}{colour_default}" to "{colour_add}{}{colour_default}"'.format(self.fieldname, self.oldvalue, self.newvalue, **colours)
 
-        if self.related:
-            for chg in self.related:
-                if not outer and chg.fieldname in ['PE', 'PV', 'PR']:
-                    continue
-                for line in chg._str_internal(False).splitlines():
-                    out += '\n  * %s' % line
-
         return '%s%s' % (prefix, out) if out else ''
 
 class FileChange:
@@ -424,9 +413,13 @@ def compare_dict_blobs(path, ablob, bblob, report_all, report_ver):
                     (depvera, depverb) = compare_pkg_lists(astr, bstr)
                     if depvera == depverb:
                         continue
-                alist = astr.split()
+                if key == 'FILELIST':
+                    alist = shlex.split(astr)
+                    blist = shlex.split(bstr)
+                else:
+                    alist = astr.split()
+                    blist = bstr.split()
                 alist.sort()
-                blist = bstr.split()
                 blist.sort()
                 # We don't care about the removal of self-dependencies
                 if pkgname in alist and not pkgname in blist:
@@ -635,17 +628,6 @@ def process_changes(repopath, revision1, revision2='HEAD', report_all=False, rep
                 chg = ChangeRecord(path, filename[7:], d.a_blob.data_stream.read().decode('utf-8'), '', True)
                 changes.append(chg)
 
-    # Link related changes
-    for chg in changes:
-        if chg.monitored:
-            for chg2 in changes:
-                # (Check dirname in the case of fields from recipe info files)
-                if chg.path == chg2.path or os.path.dirname(chg.path) == chg2.path:
-                    if chg2.fieldname in related_fields.get(chg.fieldname, []):
-                        chg.related.append(chg2)
-                    elif chg.path == chg2.path and chg.path.startswith('packages/') and chg2.fieldname in ['PE', 'PV', 'PR']:
-                        chg.related.append(chg2)
-
     # filter out unwanted paths
     if exclude_path:
         for chg in changes:

meta/lib/oe/copy_buildsystem.py

@@ -1,5 +1,12 @@
 # This class should provide easy access to the different aspects of the
 # buildsystem such as layers, bitbake location, etc.
+#
+# SDK_LAYERS_EXCLUDE: Layers which will be excluded from SDK layers.
+# SDK_LAYERS_EXCLUDE_PATTERN: The simiar to SDK_LAYERS_EXCLUDE, this supports
+#                             python regular expression, use space as separator,
+#                              e.g.: ".*-downloads closed-.*"
+#
+
 import stat
 import shutil
 
@@ -23,9 +30,12 @@ class BuildSystem(object):
         self.context = context
         self.layerdirs = [os.path.abspath(pth) for pth in d.getVar('BBLAYERS').split()]
         self.layers_exclude = (d.getVar('SDK_LAYERS_EXCLUDE') or "").split()
+        self.layers_exclude_pattern = d.getVar('SDK_LAYERS_EXCLUDE_PATTERN')
 
     def copy_bitbake_and_layers(self, destdir, workspace_name=None):
+        import re
         # Copy in all metadata layers + bitbake (as repositories)
+        copied_corebase = None
         layers_copied = []
         bb.utils.mkdirhier(destdir)
         layers = list(self.layerdirs)
@@ -40,8 +50,17 @@ class BuildSystem(object):
         # Exclude layers
         for layer_exclude in self.layers_exclude:
             if layer_exclude in layers:
+                bb.note('Excluded %s from sdk layers since it is in SDK_LAYERS_EXCLUDE' % layer_exclude)
                 layers.remove(layer_exclude)
 
+        if self.layers_exclude_pattern:
+            layers_cp = layers[:]
+            for pattern in self.layers_exclude_pattern.split():
+                for layer in layers_cp:
+                    if re.match(pattern, layer):
+                        bb.note('Excluded %s from sdk layers since matched SDK_LAYERS_EXCLUDE_PATTERN' % layer)
+                        layers.remove(layer)
+
         workspace_newname = workspace_name
         if workspace_newname:
             layernames = [os.path.basename(layer) for layer in layers]
@@ -84,17 +103,18 @@ class BuildSystem(object):
 
             layer_relative = os.path.relpath(layerdestpath,
                                              destdir)
-            layers_copied.append(layer_relative)
-
             # Treat corebase as special since it typically will contain
             # build directories or other custom items.
             if corebase == layer:
+                copied_corebase = layer_relative
                 bb.utils.mkdirhier(layerdestpath)
                 for f in corebase_files:
                     f_basename = os.path.basename(f)
                     destname = os.path.join(layerdestpath, f_basename)
                     _smart_copy(f, destname)
             else:
+                layers_copied.append(layer_relative)
+
                 if os.path.exists(os.path.join(layerdestpath, 'conf/layer.conf')):
                     bb.note("Skipping layer %s, already handled" % layer)
                 else:
@@ -140,7 +160,7 @@ class BuildSystem(object):
                 layers_copied.remove(layer)
                 break
 
-        return layers_copied
+        return copied_corebase, layers_copied
 
 def generate_locked_sigs(sigfile, d):
     bb.utils.mkdirhier(os.path.dirname(sigfile))

meta/lib/oe/package_manager.py

@@ -370,7 +370,7 @@ class PackageManager(object, metaclass=ABCMeta):
                 self._handle_intercept_failure(registered_pkgs)
 
 
-    def run_intercepts(self):
+    def run_intercepts(self, populate_sdk=None):
         intercepts_dir = self.intercepts_dir
 
         bb.note("Running intercept scripts:")
@@ -382,7 +382,8 @@ class PackageManager(object, metaclass=ABCMeta):
             if script == "postinst_intercept" or not os.access(script_full, os.X_OK):
                 continue
 
-            if script == "delay_to_first_boot":
+            # we do not want to run any multilib variant of this
+            if script.startswith("delay_to_first_boot"):
                 self._postpone_to_first_boot(script_full)
                 continue
 
@@ -392,9 +393,22 @@ class PackageManager(object, metaclass=ABCMeta):
                 output = subprocess.check_output(script_full, stderr=subprocess.STDOUT)
                 if output: bb.note(output.decode("utf-8"))
             except subprocess.CalledProcessError as e:
-                bb.warn("The postinstall intercept hook '%s' failed, details in %s/log.do_%s" % (script, self.d.getVar('T'), self.d.getVar('BB_CURRENTTASK')))
                 bb.note("Exit code %d. Output:\n%s" % (e.returncode, e.output.decode("utf-8")))
-                self._postpone_to_first_boot(script_full)
+                if populate_sdk == 'host':
+                    bb.warn("The postinstall intercept hook '%s' failed, details in %s/log.do_%s" % (script, self.d.getVar('T'), self.d.getVar('BB_CURRENTTASK')))
+                elif populate_sdk == 'target':
+                    if "qemuwrapper: qemu usermode is not supported" in e.output.decode("utf-8"):
+                        bb.warn("The postinstall intercept hook '%s' could not be executed due to missing qemu usermode support, details in %s/log.do_%s"
+                                % (script, self.d.getVar('T'), self.d.getVar('BB_CURRENTTASK')))
+                    else:
+                        bb.fatal("The postinstall intercept hook '%s' failed, details in %s/log.do_%s" % (script, self.d.getVar('T'), self.d.getVar('BB_CURRENTTASK')))
+                else:
+                    if "qemuwrapper: qemu usermode is not supported" in e.output.decode("utf-8"):
+                        bb.note("The postinstall intercept hook '%s' could not be executed due to missing qemu usermode support, details in %s/log.do_%s"
+                                % (script, self.d.getVar('T'), self.d.getVar('BB_CURRENTTASK')))
+                        self._postpone_to_first_boot(script_full)
+                    else:
+                        bb.fatal("The postinstall intercept hook '%s' failed, details in %s/log.do_%s" % (script, self.d.getVar('T'), self.d.getVar('BB_CURRENTTASK')))
 
     @abstractmethod
     def update(self):

meta/lib/oe/path.py

@@ -259,3 +259,37 @@ def is_path_parent(possible_parent, *paths):
         if not path_abs.startswith(possible_parent_abs):
             return False
     return True
+
+def which_wild(pathname, path=None, mode=os.F_OK, *, reverse=False, candidates=False):
+    """Search a search path for pathname, supporting wildcards.
+
+    Return all paths in the specific search path matching the wildcard pattern
+    in pathname, returning only the first encountered for each file. If
+    candidates is True, information on all potential candidate paths are
+    included.
+    """
+    paths = (path or os.environ.get('PATH', os.defpath)).split(':')
+    if reverse:
+        paths.reverse()
+
+    seen, files = set(), []
+    for index, element in enumerate(paths):
+        if not os.path.isabs(element):
+            element = os.path.abspath(element)
+
+        candidate = os.path.join(element, pathname)
+        globbed = glob.glob(candidate)
+        if globbed:
+            for found_path in sorted(globbed):
+                if not os.access(found_path, mode):
+                    continue
+                rel = os.path.relpath(found_path, element)
+                if rel not in seen:
+                    seen.add(rel)
+                    if candidates:
+                        files.append((found_path, [os.path.join(p, rel) for p in paths[:index+1]]))
+                    else:
+                        files.append(found_path)
+
+    return files
+

meta/lib/oe/rootfs.py

@@ -561,6 +561,9 @@ class DpkgOpkgRootfs(Rootfs):
         return pkg_list
 
     def _save_postinsts_common(self, dst_postinst_dir, src_postinst_dir):
+        if bb.utils.contains("IMAGE_FEATURES", "package-management",
+                         True, False, self.d):
+            return
         num = 0
         for p in self._get_delayed_postinsts():
             bb.utils.mkdirhier(dst_postinst_dir)

meta/lib/oe/sdk.py

@@ -209,7 +209,7 @@ class RpmSdk(Sdk):
 
         self.target_pm.install_complementary(self.d.getVar('SDKIMAGE_INSTALL_COMPLEMENTARY'))
 
-        self.target_pm.run_intercepts()
+        self.target_pm.run_intercepts(populate_sdk='target')
 
         execute_pre_post_process(self.d, self.d.getVar("POPULATE_SDK_POST_TARGET_COMMAND"))
 
@@ -220,7 +220,7 @@ class RpmSdk(Sdk):
         self._populate_sysroot(self.host_pm, self.host_manifest)
         self.install_locales(self.host_pm)
 
-        self.host_pm.run_intercepts()
+        self.host_pm.run_intercepts(populate_sdk='host')
 
         execute_pre_post_process(self.d, self.d.getVar("POPULATE_SDK_POST_HOST_COMMAND"))
 
@@ -297,7 +297,7 @@ class OpkgSdk(Sdk):
 
         self.target_pm.install_complementary(self.d.getVar('SDKIMAGE_INSTALL_COMPLEMENTARY'))
 
-        self.target_pm.run_intercepts()
+        self.target_pm.run_intercepts(populate_sdk='target')
 
         execute_pre_post_process(self.d, self.d.getVar("POPULATE_SDK_POST_TARGET_COMMAND"))
 
@@ -308,7 +308,7 @@ class OpkgSdk(Sdk):
         self._populate_sysroot(self.host_pm, self.host_manifest)
         self.install_locales(self.host_pm)
 
-        self.host_pm.run_intercepts()
+        self.host_pm.run_intercepts(populate_sdk='host')
 
         execute_pre_post_process(self.d, self.d.getVar("POPULATE_SDK_POST_HOST_COMMAND"))
 
@@ -386,7 +386,7 @@ class DpkgSdk(Sdk):
 
         self.target_pm.install_complementary(self.d.getVar('SDKIMAGE_INSTALL_COMPLEMENTARY'))
 
-        self.target_pm.run_intercepts()
+        self.target_pm.run_intercepts(populate_sdk='target')
 
         execute_pre_post_process(self.d, self.d.getVar("POPULATE_SDK_POST_TARGET_COMMAND"))
 
@@ -399,7 +399,7 @@ class DpkgSdk(Sdk):
         self._populate_sysroot(self.host_pm, self.host_manifest)
         self.install_locales(self.host_pm)
 
-        self.host_pm.run_intercepts()
+        self.host_pm.run_intercepts(populate_sdk='host')
 
         execute_pre_post_process(self.d, self.d.getVar("POPULATE_SDK_POST_HOST_COMMAND"))
 

meta/lib/oe/sstatesig.py

@@ -45,7 +45,7 @@ def sstate_rundepfilter(siggen, fn, recipename, task, dep, depname, dataCache):
 
     # allarch packagegroups are assumed to have well behaved names which don't change between architecures/tunes
     if isPackageGroup(fn) and isAllArch(fn) and not isNative(depname):
-        return False  
+        return False
 
     # Exclude well defined machine specific configurations which don't change ABI
     if depname in siggen.abisaferecipes and not isImage(fn):
@@ -372,8 +372,14 @@ def sstate_get_manifest_filename(task, d):
 def find_sstate_manifest(taskdata, taskdata2, taskname, d, multilibcache):
     d2 = d
     variant = ''
+    curr_variant = ''
+    if d.getVar("BBEXTENDCURR") == "multilib":
+        curr_variant = d.getVar("BBEXTENDVARIANT")
+        if "virtclass-multilib" not in d.getVar("OVERRIDES"):
+            curr_variant = "invalid"
     if taskdata2.startswith("virtual:multilib"):
         variant = taskdata2.split(":")[2]
+    if curr_variant != variant:
         if variant not in multilibcache:
             multilibcache[variant] = oe.utils.get_multilib_datastore(variant, d)
         d2 = multilibcache[variant]

meta/lib/oe/types.py

@@ -103,8 +103,13 @@ def boolean(value):
     """OpenEmbedded 'boolean' type
 
     Valid values for true: 'yes', 'y', 'true', 't', '1'
-    Valid values for false: 'no', 'n', 'false', 'f', '0'
+    Valid values for false: 'no', 'n', 'false', 'f', '0', None
     """
+    if value is None:
+        return False
+
+    if isinstance(value, bool):
+        return value
 
     if not isinstance(value, str):
         raise TypeError("boolean accepts a string, not '%s'" % type(value))

meta/lib/oe/utils.py

@@ -327,9 +327,15 @@ def host_gcc_version(d):
 
 def get_multilib_datastore(variant, d):
     localdata = bb.data.createCopy(d)
-    overrides = localdata.getVar("OVERRIDES", False) + ":virtclass-multilib-" + variant
-    localdata.setVar("OVERRIDES", overrides)
-    localdata.setVar("MLPREFIX", variant + "-")
+    if variant:
+        overrides = localdata.getVar("OVERRIDES", False) + ":virtclass-multilib-" + variant
+        localdata.setVar("OVERRIDES", overrides)
+        localdata.setVar("MLPREFIX", variant + "-")
+    else:
+        overrides = localdata.getVar("OVERRIDES", False).split(":")
+        overrides = ":".join([x for x in overrides if not x.startswith("virtclass-multilib-")])
+        localdata.setVar("OVERRIDES", overrides)
+        localdata.setVar("MLPREFIX", "")
     return localdata
 
 #

meta/lib/oeqa/core/context.py

@@ -27,7 +27,6 @@ class OETestContext(object):
         self.logger = logger
         self._registry = {}
         self._registry['cases'] = collections.OrderedDict()
-        self._results = {}
 
     def _read_modules_from_manifest(self, manifest):
         if not os.path.exists(manifest):
@@ -58,14 +57,20 @@ class OETestContext(object):
                 modules_required, filters)
         self.suites = self.loader.discover()
 
-    def runTests(self, skips=[]):
-        self.runner = self.runnerClass(self, descriptions=False, verbosity=2)
+    def runTests(self, processes=None, skips=[]):
+        self.runner = self.runnerClass(self, descriptions=False, verbosity=2, buffer=True)
 
         # Dinamically skip those tests specified though arguments
         self.skipTests(skips)
 
         self._run_start_time = time.time()
-        result = self.runner.run(self.suites)
+        if processes:
+            from oeqa.core.utils.concurrencytest import ConcurrentTestSuite
+
+            concurrent_suite = ConcurrentTestSuite(self.suites, processes)
+            result = self.runner.run(concurrent_suite)
+        else:
+            result = self.runner.run(self.suites)
         self._run_end_time = time.time()
 
         return result