meta-yocto-bsp: bump to the latest linux stable kernel for edgerouter/beaglebone

Bump to the latest stable kernel for 4.14 and 4.15 for edgerouter/beaglebone
to fix gcc8 build issues.

(From meta-yocto rev: c5e07b460cf9477181d2dcde8ea93daeeacc9a2e)

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

bitbake/bin/bitbake

@@ -38,7 +38,7 @@ from bb.main import bitbake_main, BitBakeConfigParameters, BBMainException
 if sys.getfilesystemencoding() != "utf-8":
     sys.exit("Please use a locale setting which supports UTF-8 (such as LANG=en_US.UTF-8).\nPython can't change the filesystem locale after loading so we need a UTF-8 when Python starts or things won't work.")
 
-__version__ = "1.38.0"
+__version__ = "1.39.0"
 
 if __name__ == "__main__":
     if __version__ != bb.__version__:

bitbake/bin/bitbake-diffsigs

@@ -1,7 +1,7 @@
 #!/usr/bin/env python3
 
-# bitbake-diffsigs / bitbake-dumpsig
-# BitBake task signature data dump and comparison utility
+# bitbake-diffsigs
+# BitBake task signature data comparison utility
 #
 # Copyright (C) 2012-2013, 2017 Intel Corporation
 #
@@ -21,6 +21,7 @@
 import os
 import sys
 import warnings
+import fnmatch
 import argparse
 import logging
 import pickle
@@ -31,10 +32,7 @@ import bb.tinfoil
 import bb.siggen
 import bb.msg
 
-myname = os.path.basename(sys.argv[0])
-logger = bb.msg.logger_create(myname)
-
-is_dump = myname == 'bitbake-dumpsig'
+logger = bb.msg.logger_create('bitbake-diffsigs')
 
 def find_siginfo(tinfoil, pn, taskname, sigs=None):
     result = None
@@ -61,8 +59,8 @@ def find_siginfo(tinfoil, pn, taskname, sigs=None):
         sys.exit(2)
     return result
 
-def find_siginfo_task(bbhandler, pn, taskname, sig1=None, sig2=None):
-    """ Find the most recent signature files for the specified PN/task """
+def find_compare_task(bbhandler, pn, taskname, sig1=None, sig2=None, color=False):
+    """ Find the most recent signature files for the specified PN/task and compare them """
 
     if not taskname.startswith('do_'):
         taskname = 'do_%s' % taskname
@@ -81,81 +79,73 @@ def find_siginfo_task(bbhandler, pn, taskname, sig1=None, sig2=None):
         latestfiles = [sigfiles[sig1], sigfiles[sig2]]
     else:
         filedates = find_siginfo(bbhandler, pn, taskname)
-        latestfiles = sorted(filedates.keys(), key=lambda f: filedates[f])[-2:]
+        latestfiles = sorted(filedates.keys(), key=lambda f: filedates[f])[-3:]
         if not latestfiles:
             logger.error('No sigdata files found matching %s %s' % (pn, taskname))
             sys.exit(1)
+        elif len(latestfiles) < 2:
+            logger.error('Only one matching sigdata file found for the specified task (%s %s)' % (pn, taskname))
+            sys.exit(1)
 
-    return latestfiles
+    # Define recursion callback
+    def recursecb(key, hash1, hash2):
+        hashes = [hash1, hash2]
+        hashfiles = find_siginfo(bbhandler, key, None, hashes)
 
+        recout = []
+        if len(hashfiles) == 0:
+            recout.append("Unable to find matching sigdata for %s with hashes %s or %s" % (key, hash1, hash2))
+        elif not hash1 in hashfiles:
+            recout.append("Unable to find matching sigdata for %s with hash %s" % (key, hash1))
+        elif not hash2 in hashfiles:
+            recout.append("Unable to find matching sigdata for %s with hash %s" % (key, hash2))
+        else:
+            out2 = bb.siggen.compare_sigfiles(hashfiles[hash1], hashfiles[hash2], recursecb, color=color)
+            for change in out2:
+                for line in change.splitlines():
+                    recout.append('  ' + line)
 
-# Define recursion callback
-def recursecb(key, hash1, hash2):
-    hashes = [hash1, hash2]
-    hashfiles = find_siginfo(tinfoil, key, None, hashes)
+        return recout
 
-    recout = []
-    if len(hashfiles) == 0:
-        recout.append("Unable to find matching sigdata for %s with hashes %s or %s" % (key, hash1, hash2))
-    elif not hash1 in hashfiles:
-        recout.append("Unable to find matching sigdata for %s with hash %s" % (key, hash1))
-    elif not hash2 in hashfiles:
-        recout.append("Unable to find matching sigdata for %s with hash %s" % (key, hash2))
-    else:
-        out2 = bb.siggen.compare_sigfiles(hashfiles[hash1], hashfiles[hash2], recursecb, color=color)
-        for change in out2:
-            for line in change.splitlines():
-                recout.append('  ' + line)
+    # Recurse into signature comparison
+    logger.debug("Signature file (previous): %s" % latestfiles[-2])
+    logger.debug("Signature file (latest): %s" % latestfiles[-1])
+    output = bb.siggen.compare_sigfiles(latestfiles[-2], latestfiles[-1], recursecb, color=color)
+    if output:
+        print('\n'.join(output))
+    sys.exit(0)
 
-    return recout
 
 
 parser = argparse.ArgumentParser(
-    description=("Dumps" if is_dump else "Compares") + " siginfo/sigdata files written out by BitBake")
+    description="Compares siginfo/sigdata files written out by BitBake")
 
-parser.add_argument('-D', '--debug',
+parser.add_argument('-d', '--debug',
                     help='Enable debug output',
                     action='store_true')
 
-if is_dump:
-    parser.add_argument("-t", "--task",
-            help="find the signature data file for the last run of the specified task",
-            action="store", dest="taskargs", nargs=2, metavar=('recipename', 'taskname'))
+parser.add_argument('--color',
+        help='Colorize output (where %(metavar)s is %(choices)s)',
+        choices=['auto', 'always', 'never'], default='auto', metavar='color')
 
-    parser.add_argument("sigdatafile1",
-            help="Signature file to dump. Not used when using -t/--task.",
-            action="store", nargs='?', metavar="sigdatafile")
-else:
-    parser.add_argument('-c', '--color',
-            help='Colorize the output (where %(metavar)s is %(choices)s)',
-            choices=['auto', 'always', 'never'], default='auto', metavar='color')
+parser.add_argument("-t", "--task",
+        help="find the signature data files for last two runs of the specified task and compare them",
+        action="store", dest="taskargs", nargs=2, metavar=('recipename', 'taskname'))
 
-    parser.add_argument('-d', '--dump',
-            help='Dump the last signature data instead of comparing (equivalent to using bitbake-dumpsig)',
-            action='store_true')
+parser.add_argument("-s", "--signature",
+        help="With -t/--task, specify the signatures to look for instead of taking the last two",
+        action="store", dest="sigargs", nargs=2, metavar=('fromsig', 'tosig'))
 
-    parser.add_argument("-t", "--task",
-            help="find the signature data files for the last two runs of the specified task and compare them",
-            action="store", dest="taskargs", nargs=2, metavar=('recipename', 'taskname'))
+parser.add_argument("sigdatafile1",
+        help="First signature file to compare (or signature file to dump, if second not specified). Not used when using -t/--task.",
+        action="store", nargs='?')
 
-    parser.add_argument("-s", "--signature",
-            help="With -t/--task, specify the signatures to look for instead of taking the last two",
-            action="store", dest="sigargs", nargs=2, metavar=('fromsig', 'tosig'))
+parser.add_argument("sigdatafile2",
+        help="Second signature file to compare",
+        action="store", nargs='?')
 
-    parser.add_argument("sigdatafile1",
-            help="First signature file to compare (or signature file to dump, if second not specified). Not used when using -t/--task.",
-            action="store", nargs='?')
-
-    parser.add_argument("sigdatafile2",
-            help="Second signature file to compare",
-            action="store", nargs='?')
 
 options = parser.parse_args()
-if is_dump:
-    options.color = 'never'
-    options.dump = True
-    options.sigdatafile2 = None
-    options.sigargs = None
 
 if options.debug:
     logger.setLevel(logging.DEBUG)
@@ -165,32 +155,17 @@ color = (options.color == 'always' or (options.color == 'auto' and sys.stdout.is
 if options.taskargs:
     with bb.tinfoil.Tinfoil() as tinfoil:
         tinfoil.prepare(config_only=True)
-        if not options.dump and options.sigargs:
-            files = find_siginfo_task(tinfoil, options.taskargs[0], options.taskargs[1], options.sigargs[0], options.sigargs[1])
+        if options.sigargs:
+            find_compare_task(tinfoil, options.taskargs[0], options.taskargs[1], options.sigargs[0], options.sigargs[1], color=color)
         else:
-            files = find_siginfo_task(tinfoil, options.taskargs[0], options.taskargs[1])
-
-        if options.dump:
-            logger.debug("Signature file: %s" % files[-1])
-            output = bb.siggen.dump_sigfile(files[-1])
-        else:
-            if len(files) < 2:
-                logger.error('Only one matching sigdata file found for the specified task (%s %s)' % (options.taskargs[0], options.taskargs[1]))
-                sys.exit(1)
-
-            # Recurse into signature comparison
-            logger.debug("Signature file (previous): %s" % files[-2])
-            logger.debug("Signature file (latest): %s" % files[-1])
-            output = bb.siggen.compare_sigfiles(files[-2], files[-1], recursecb, color=color)
+            find_compare_task(tinfoil, options.taskargs[0], options.taskargs[1], color=color)
 else:
     if options.sigargs:
         logger.error('-s/--signature can only be used together with -t/--task')
         sys.exit(1)
     try:
-        if not options.dump and options.sigdatafile1 and options.sigdatafile2:
-            with bb.tinfoil.Tinfoil() as tinfoil:
-                tinfoil.prepare(config_only=True)
-                output = bb.siggen.compare_sigfiles(options.sigdatafile1, options.sigdatafile2, recursecb, color=color)
+        if options.sigdatafile1 and options.sigdatafile2:
+            output = bb.siggen.compare_sigfiles(options.sigdatafile1, options.sigdatafile2, color=color)
         elif options.sigdatafile1:
             output = bb.siggen.dump_sigfile(options.sigdatafile1)
         else:
@@ -204,5 +179,5 @@ else:
         logger.error('Invalid signature data - ensure you are specifying sigdata/siginfo files')
         sys.exit(1)
 
-if output:
-    print('\n'.join(output))
+    if output:
+        print('\n'.join(output))

bitbake/bin/bitbake-dumpsig

@@ -1 +0,0 @@
-bitbake-diffsigs

bitbake/bin/bitbake-dumpsig

@@ -0,0 +1,94 @@
+#!/usr/bin/env python3
+
+# bitbake-dumpsig
+# BitBake task signature dump utility
+#
+# Copyright (C) 2013 Intel Corporation
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License version 2 as
+# published by the Free Software Foundation.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License along
+# with this program; if not, write to the Free Software Foundation, Inc.,
+# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+
+import os
+import sys
+import warnings
+import optparse
+import logging
+import pickle
+
+sys.path.insert(0, os.path.join(os.path.dirname(os.path.dirname(sys.argv[0])), 'lib'))
+
+import bb.tinfoil
+import bb.siggen
+import bb.msg
+
+logger = bb.msg.logger_create('bitbake-dumpsig')
+
+def find_siginfo_task(bbhandler, pn, taskname):
+    """ Find the most recent signature file for the specified PN/task """
+
+    if not hasattr(bb.siggen, 'find_siginfo'):
+        logger.error('Metadata does not support finding signature data files')
+        sys.exit(1)
+
+    if not taskname.startswith('do_'):
+        taskname = 'do_%s' % taskname
+
+    filedates = bb.siggen.find_siginfo(pn, taskname, None, bbhandler.config_data)
+    latestfiles = sorted(filedates.keys(), key=lambda f: filedates[f])[-1:]
+    if not latestfiles:
+        logger.error('No sigdata files found matching %s %s' % (pn, taskname))
+        sys.exit(1)
+
+    return latestfiles[0]
+
+parser = optparse.OptionParser(
+    description = "Dumps siginfo/sigdata files written out by BitBake",
+    usage = """
+  %prog -t recipename taskname
+  %prog sigdatafile""")
+
+parser.add_option("-D", "--debug",
+        help = "enable debug",
+        action = "store_true", dest="debug", default = False)
+
+parser.add_option("-t", "--task",
+        help = "find the signature data file for the specified task",
+        action="store", dest="taskargs", nargs=2, metavar='recipename taskname')
+
+options, args = parser.parse_args(sys.argv)
+
+if options.debug:
+    logger.setLevel(logging.DEBUG)
+
+if options.taskargs:
+    tinfoil = bb.tinfoil.Tinfoil()
+    tinfoil.prepare(config_only = True)
+    file = find_siginfo_task(tinfoil, options.taskargs[0], options.taskargs[1])
+    logger.debug("Signature file: %s" % file)
+elif len(args) == 1:
+    parser.print_help()
+    sys.exit(0)
+else:
+    file = args[1]
+
+try:
+    output = bb.siggen.dump_sigfile(file)
+except IOError as e:
+    logger.error(str(e))
+    sys.exit(1)
+except (pickle.UnpicklingError, EOFError):
+    logger.error('Invalid signature data - ensure you are specifying a sigdata/siginfo file')
+    sys.exit(1)
+
+if output:
+    print('\n'.join(output))

bitbake/bin/bitbake-worker

@@ -192,6 +192,9 @@ def fork_off_task(cfg, data, databuilder, workerdata, fn, task, taskname, append
             global worker_pipe_lock
             pipein.close()
 
+            signal.signal(signal.SIGTERM, sigterm_handler)
+            # Let SIGHUP exit as SIGTERM
+            signal.signal(signal.SIGHUP, sigterm_handler)
             bb.utils.signal_on_parent_exit("SIGTERM")
 
             # Save out the PID so that the event can include it the
@@ -206,11 +209,6 @@ def fork_off_task(cfg, data, databuilder, workerdata, fn, task, taskname, append
             # This ensures signals sent to the controlling terminal like Ctrl+C
             # don't stop the child processes.
             os.setsid()
-
-            signal.signal(signal.SIGTERM, sigterm_handler)
-            # Let SIGHUP exit as SIGTERM
-            signal.signal(signal.SIGHUP, sigterm_handler)
-
             # No stdin
             newsi = os.open(os.devnull, os.O_RDWR)
             os.dup2(newsi, sys.stdin.fileno())

bitbake/bin/toaster

@@ -18,12 +18,11 @@
 # along with this program. If not, see http://www.gnu.org/licenses/.
 
 HELP="
-Usage: source toaster start|stop [webport=<address:port>] [noweb] [nobuild] [toasterdir]
+Usage: source toaster start|stop [webport=<address:port>] [noweb] [nobuild]
     Optional arguments:
         [nobuild] Setup the environment for capturing builds with toaster but disable managed builds
         [noweb] Setup the environment for capturing builds with toaster but don't start the web server
         [webport] Set the development server (default: localhost:8000)
-        [toasterdir] Set absolute path to be used as TOASTER_DIR (default: BUILDDIR/../)
 "
 
 custom_extention()
@@ -161,9 +160,7 @@ fi
 
 export BBBASEDIR=`dirname $TOASTER`/..
 MANAGE="python3 $BBBASEDIR/lib/toaster/manage.py"
-if [ -z "$OE_ROOT" ]; then
-    OE_ROOT=`dirname $TOASTER`/../..
-fi
+OE_ROOT=`dirname $TOASTER`/../..
 
 # this is the configuraton file we are using for toaster
 # we are using the same logic that oe-setup-builddir uses
@@ -189,7 +186,6 @@ unset OE_ROOT
 WEBSERVER=1
 export TOASTER_BUILDSERVER=1
 ADDR_PORT="localhost:8000"
-TOASTERDIR=`dirname $BUILDDIR`
 unset CMD
 for param in $*; do
     case $param in
@@ -215,9 +211,6 @@ for param in $*; do
                 ADDR_PORT="localhost:$PORT"
             fi
     ;;
-    toasterdir=*)
-            TOASTERDIR="${param#*=}"
-    ;;
     --help)
             echo "$HELP"
             return 0
@@ -248,7 +241,7 @@ fi
 # 2) the build dir (in build)
 # 3) the sqlite db if that is being used.
 # 4) pid's we need to clean up on exit/shutdown
-export TOASTER_DIR=$TOASTERDIR
+export TOASTER_DIR=`dirname $BUILDDIR`
 export BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE TOASTER_DIR"
 
 # Determine the action. If specified by arguments, fine, if not, toggle it

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

@@ -588,14 +588,6 @@
                         The name of the path in which to place the checkout.
                         By default, the path is <filename>git/</filename>.
                         </para></listitem>
-                    <listitem><para><emphasis>"usehead":</emphasis>
-                        Enables local <filename>git://</filename> URLs to use the
-                        current branch HEAD as the revision for use with
-                        <filename>AUTOREV</filename>.
-                        The "usehead" parameter implies no branch and only works
-                        when the transfer protocol is
-                        <filename>file://</filename>.
-                        </para></listitem>
                 </itemizedlist>
                 Here are some example URLs:
                 <literallayout class='monospaced'>

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

@@ -502,7 +502,7 @@
         </section>
 
         <section id='unsetting-variables'>
-            <title>Unsetting variables</title>
+            <title>Unseting variables</title>
 
             <para>
                 It is possible to completely remove a variable or a variable flag

bitbake/lib/bb/COW.py

@@ -150,7 +150,7 @@ class COWDictMeta(COWMeta):
                 yield value
             if type == "items":
                 yield (key, value)
-        return
+        raise StopIteration()
 
     def iterkeys(cls):
         return cls.iter("keys")

bitbake/lib/bb/__init__.py

@@ -21,7 +21,7 @@
 # with this program; if not, write to the Free Software Foundation, Inc.,
 # 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
 
-__version__ = "1.38.0"
+__version__ = "1.39.0"
 
 import sys
 if sys.version_info < (3, 4, 0):

bitbake/lib/bb/checksum.py

@@ -97,8 +97,6 @@ class FileChecksumCache(MultiProcessCache):
 
         def checksum_dir(pth):
             # Handle directories recursively
-            if pth == "/":
-                bb.fatal("Refusing to checksum /")
             dirchecksums = []
             for root, dirs, files in os.walk(pth):
                 for name in files:

bitbake/lib/bb/cooker.py

@@ -175,31 +175,18 @@ class BBCooker:
 
         self.configuration = configuration
 
-        bb.debug(1, "BBCooker starting %s" % time.time())
-        sys.stdout.flush()
-
         self.configwatcher = pyinotify.WatchManager()
-        bb.debug(1, "BBCooker pyinotify1 %s" % time.time())
-        sys.stdout.flush()
-
         self.configwatcher.bbseen = []
         self.configwatcher.bbwatchedfiles = []
         self.confignotifier = pyinotify.Notifier(self.configwatcher, self.config_notifications)
-        bb.debug(1, "BBCooker pyinotify2 %s" % time.time())
-        sys.stdout.flush()
         self.watchmask = pyinotify.IN_CLOSE_WRITE | pyinotify.IN_CREATE | pyinotify.IN_DELETE | \
                          pyinotify.IN_DELETE_SELF | pyinotify.IN_MODIFY | pyinotify.IN_MOVE_SELF | \
                          pyinotify.IN_MOVED_FROM | pyinotify.IN_MOVED_TO
         self.watcher = pyinotify.WatchManager()
-        bb.debug(1, "BBCooker pyinotify3 %s" % time.time())
-        sys.stdout.flush()
         self.watcher.bbseen = []
         self.watcher.bbwatchedfiles = []
         self.notifier = pyinotify.Notifier(self.watcher, self.notifications)
 
-        bb.debug(1, "BBCooker pyinotify complete %s" % time.time())
-        sys.stdout.flush()
-
         # If being called by something like tinfoil, we need to clean cached data
         # which may now be invalid
         bb.parse.clear_cache()
@@ -209,9 +196,6 @@ class BBCooker:
 
         self.initConfigurationData()
 
-        bb.debug(1, "BBCooker parsed base configuration %s" % time.time())
-        sys.stdout.flush()
-
         # we log all events to a file if so directed
         if self.configuration.writeeventlog:
             # register the log file writer as UI Handler
@@ -249,9 +233,6 @@ class BBCooker:
         # Let SIGHUP exit as SIGTERM
         signal.signal(signal.SIGHUP, self.sigterm_exception)
 
-        bb.debug(1, "BBCooker startup complete %s" % time.time())
-        sys.stdout.flush()
-
     def process_inotify_updates(self):
         for n in [self.confignotifier, self.notifier]:
             if n.check_events(timeout=0):

bitbake/lib/bb/fetch2/__init__.py

@@ -383,7 +383,7 @@ def decodeurl(url):
         path = location
     else:
         host = location
-        path = ""
+        path = "/"
     if user:
         m = re.compile('(?P<user>[^:]+)(:?(?P<pswd>.*))').match(user)
         if m:
@@ -1457,7 +1457,7 @@ class FetchMethod(object):
                 else:
                     cmd = 'rpm2cpio.sh %s | cpio -id' % (file)
             elif file.endswith('.deb') or file.endswith('.ipk'):
-                output = subprocess.check_output(['ar', '-t', file], preexec_fn=subprocess_setup)
+                output = subprocess.check_output('ar -t %s' % file, preexec_fn=subprocess_setup, shell=True)
                 datafile = None
                 if output:
                     for line in output.decode().splitlines():

bitbake/lib/bb/fetch2/git.py

@@ -322,16 +322,13 @@ class Git(FetchMethod):
     def download(self, ud, d):
         """Fetch url"""
 
-        no_clone = not os.path.exists(ud.clonedir)
-        need_update = no_clone or self.need_update(ud, d)
-
         # A current clone is preferred to either tarball, a shallow tarball is
         # preferred to an out of date clone, and a missing clone will use
         # either tarball.
-        if ud.shallow and os.path.exists(ud.fullshallow) and need_update:
+        if ud.shallow and os.path.exists(ud.fullshallow) and self.need_update(ud, d):
             ud.localpath = ud.fullshallow
             return
-        elif os.path.exists(ud.fullmirror) and no_clone:
+        elif os.path.exists(ud.fullmirror) and not os.path.exists(ud.clonedir):
             bb.utils.mkdirhier(ud.clonedir)
             runfetchcmd("tar -xzf %s" % ud.fullmirror, d, workdir=ud.clonedir)
 
@@ -353,13 +350,16 @@ class Git(FetchMethod):
         for name in ud.names:
             if not self._contains_ref(ud, d, name, ud.clonedir):
                 needupdate = True
+                break
+
         if needupdate:
-            output = runfetchcmd("%s remote" % ud.basecmd, d, quiet=True, workdir=ud.clonedir)
-            if "origin" in output:
-              runfetchcmd("%s remote rm origin" % ud.basecmd, d, workdir=ud.clonedir)
+            try: 
+                runfetchcmd("%s remote rm origin" % ud.basecmd, d, workdir=ud.clonedir)
+            except bb.fetch2.FetchError:
+                logger.debug(1, "No Origin")
 
             runfetchcmd("%s remote add --mirror=fetch origin %s" % (ud.basecmd, repourl), d, workdir=ud.clonedir)
-            fetch_cmd = "LANG=C %s fetch -f --progress %s refs/*:refs/*" % (ud.basecmd, repourl)
+            fetch_cmd = "LANG=C %s fetch -f --prune --progress %s refs/*:refs/*" % (ud.basecmd, repourl)
             if ud.proto.lower() != 'file':
                 bb.fetch2.check_network_access(d, fetch_cmd, ud.url)
             progresshandler = GitProgressHandler(d)
@@ -372,6 +372,7 @@ class Git(FetchMethod):
             except OSError as exc:
                 if exc.errno != errno.ENOENT:
                     raise
+
         for name in ud.names:
             if not self._contains_ref(ud, d, name, ud.clonedir):
                 raise bb.fetch2.FetchError("Unable to find revision %s in branch %s even from upstream" % (ud.revisions[name], ud.branches[name]))
@@ -471,7 +472,7 @@ class Git(FetchMethod):
         if os.path.exists(destdir):
             bb.utils.prunedir(destdir)
 
-        if ud.shallow and (not os.path.exists(ud.clonedir) or self.need_update(ud, d)):
+        if ud.shallow and self.need_update(ud, d):
             bb.utils.mkdirhier(destdir)
             runfetchcmd("tar -xzf %s" % ud.fullshallow, d, workdir=destdir)
         else:

bitbake/lib/bb/fetch2/gitsm.py

@@ -98,7 +98,7 @@ class GitSM(Git):
                         for line in lines:
                             f.write(line)
 
-    def update_submodules(self, ud, d):
+    def update_submodules(self, ud, d, allow_network):
         # We have to convert bare -> full repo, do the submodule bit, then convert back
         tmpclonedir = ud.clonedir + ".tmp"
         gitdir = tmpclonedir + os.sep + ".git"
@@ -108,11 +108,46 @@ class GitSM(Git):
         runfetchcmd("sed " + gitdir + "/config -i -e 's/bare.*=.*true/bare = false/'", d)
         runfetchcmd(ud.basecmd + " reset --hard", d, workdir=tmpclonedir)
         runfetchcmd(ud.basecmd + " checkout -f " + ud.revisions[ud.names[0]], d, workdir=tmpclonedir)
-        runfetchcmd(ud.basecmd + " submodule update --init --recursive", d, workdir=tmpclonedir)
-        self._set_relative_paths(tmpclonedir)
-        runfetchcmd("sed " + gitdir + "/config -i -e 's/bare.*=.*false/bare = true/'", d, workdir=tmpclonedir)
-        os.rename(gitdir, ud.clonedir,)
-        bb.utils.remove(tmpclonedir, True)
+
+        try:
+            if allow_network:
+                fetch_flags = ""
+            else:
+                fetch_flags = "--no-fetch"
+
+            # The 'git submodule sync' sandwiched between two successive 'git submodule update' commands is
+            # intentional. See the notes on the similar construction in download() for an explanation.
+            runfetchcmd("%(basecmd)s submodule update --init --recursive %(fetch_flags)s || (%(basecmd)s submodule sync --recursive && %(basecmd)s submodule update --init --recursive %(fetch_flags)s)" % {'basecmd': ud.basecmd, 'fetch_flags' : fetch_flags}, d, workdir=tmpclonedir)
+        except bb.fetch.FetchError:
+            if allow_network:
+                raise
+            else:
+                # This method was called as a probe to see whether the submodule history
+                # is complete enough to allow the current working copy to have its
+                # modules filled in. It's not, so swallow up the exception and report
+                # the negative result.
+                return False
+        finally:
+            self._set_relative_paths(tmpclonedir)
+            runfetchcmd("sed " + gitdir + "/config -i -e 's/bare.*=.*false/bare = true/'", d, workdir=tmpclonedir)
+            os.rename(gitdir, ud.clonedir,)
+            bb.utils.remove(tmpclonedir, True)
+
+        return True
+
+    def need_update(self, ud, d):
+        main_repo_needs_update = Git.need_update(self, ud, d)
+
+        # First check that the main repository has enough history fetched. If it doesn't, then we don't
+        # even have the .gitmodules and gitlinks for the submodules to attempt asking whether the
+        # submodules' histories are recent enough.
+        if main_repo_needs_update:
+            return True
+
+        # Now check that the submodule histories are new enough. The git-submodule command doesn't have
+        # any clean interface for doing this aside from just attempting the checkout (with network
+        # fetched disabled).
+        return not self.update_submodules(ud, d, allow_network=False)
 
     def download(self, ud, d):
         Git.download(self, ud, d)
@@ -120,7 +155,7 @@ class GitSM(Git):
         if not ud.shallow or ud.localpath != ud.fullshallow:
             submodules = self.uses_submodules(ud, d, ud.clonedir)
             if submodules:
-                self.update_submodules(ud, d)
+                self.update_submodules(ud, d, allow_network=True)
 
     def clone_shallow_local(self, ud, dest, d):
         super(GitSM, self).clone_shallow_local(ud, dest, d)
@@ -132,4 +167,36 @@ class GitSM(Git):
 
         if self.uses_submodules(ud, d, ud.destdir):
             runfetchcmd(ud.basecmd + " checkout " + ud.revisions[ud.names[0]], d, workdir=ud.destdir)
-            runfetchcmd(ud.basecmd + " submodule update --init --recursive", d, workdir=ud.destdir)
+
+            # Copy over the submodules' fetched histories too.
+            if ud.bareclone:
+                repo_conf = ud.destdir
+            else:
+                repo_conf = os.path.join(ud.destdir, '.git')
+
+            if os.path.exists(ud.clonedir):
+                # This is not a copy unpacked from a shallow mirror clone. So
+                # the manual intervention to populate the .git/modules done
+                # in clone_shallow_local() won't have been done yet.
+                runfetchcmd("cp -fpPRH %s %s" % (os.path.join(ud.clonedir, 'modules'), repo_conf), d)
+                fetch_flags = "--no-fetch"
+            elif os.path.exists(os.path.join(repo_conf, 'modules')):
+                # Unpacked from a shallow mirror clone. Manual population of
+                # .git/modules is already done.
+                fetch_flags = "--no-fetch"
+            else:
+                # This isn't fatal; git-submodule will just fetch it
+                # during do_unpack().
+                fetch_flags = ""
+                bb.error("submodule history not retrieved during do_fetch()")
+
+            # Careful not to hit the network during unpacking; all history should already
+            # be fetched.
+            #
+            # The repeated attempts to do the submodule initialization sandwiched around a sync to
+            # install the correct remote URLs into the submodules' .git/config metadata are deliberate.
+            # Bad remote URLs are leftover in the modules' .git/config files from the unpack of bare
+            # clone tarballs and an initial 'git submodule update' is necessary to prod them back to
+            # enough life so that the 'git submodule sync' realizes the existing module .git/config
+            # files exist to be updated.
+            runfetchcmd("%(basecmd)s submodule update --init --recursive %(fetch_flags)s || (%(basecmd)s submodule sync --recursive && %(basecmd)s submodule update --init --recursive %(fetch_flags)s)" % {'basecmd': ud.basecmd, 'fetch_flags': fetch_flags}, d, workdir=ud.destdir)

bitbake/lib/bb/main.py

@@ -405,6 +405,9 @@ def setup_bitbake(configParams, configuration, extrafeatures=None):
         # In status only mode there are no logs and no UI
         logger.addHandler(handler)
 
+    # Clear away any spurious environment variables while we stoke up the cooker
+    cleanedvars = bb.utils.clean_environment()
+
     if configParams.server_only:
         featureset = []
         ui_module = None
@@ -420,10 +423,6 @@ def setup_bitbake(configParams, configuration, extrafeatures=None):
 
     server_connection = None
 
-    # Clear away any spurious environment variables while we stoke up the cooker
-    # (done after import_extension_module() above since for example import gi triggers env var usage)
-    cleanedvars = bb.utils.clean_environment()
-
     if configParams.remote_server:
         # Connect to a remote XMLRPC server
         server_connection = bb.server.xmlrpcclient.connectXMLRPC(configParams.remote_server, featureset,
@@ -448,7 +447,7 @@ def setup_bitbake(configParams, configuration, extrafeatures=None):
                 else:
                     logger.info("Reconnecting to bitbake server...")
                     if not os.path.exists(sockname):
-                        logger.info("Previous bitbake instance shutting down?, waiting to retry...")
+                        print("Previous bitbake instance shutting down?, waiting to retry...")
                         i = 0
                         lock = None
                         # Wait for 5s or until we can get the lock

bitbake/lib/bb/runqueue.py

@@ -1371,12 +1371,6 @@ class RunQueue:
                 bb.event.fire(bb.event.DepTreeGenerated(depgraph), self.cooker.data)
 
         if self.state is runQueueSceneInit:
-            if not self.dm_event_handler_registered:
-                 res = bb.event.register(self.dm_event_handler_name,
-                                         lambda x: self.dm.check(self) if self.state in [runQueueSceneRun, runQueueRunning, runQueueCleanUp] else False,
-                                         ('bb.event.HeartbeatEvent',))
-                 self.dm_event_handler_registered = True
-
             dump = self.cooker.configuration.dump_signatures
             if dump:
                 self.rqdata.init_progress_reporter.finish()
@@ -1393,6 +1387,11 @@ class RunQueue:
                 self.rqexe = RunQueueExecuteScenequeue(self)
 
         if self.state is runQueueSceneRun:
+            if not self.dm_event_handler_registered:
+                 res = bb.event.register(self.dm_event_handler_name,
+                                         lambda x: self.dm.check(self) if self.state in [runQueueSceneRun, runQueueRunning, runQueueCleanUp] else False,
+                                         ('bb.event.HeartbeatEvent',))
+                 self.dm_event_handler_registered = True
             retval = self.rqexe.execute()
 
         if self.state is runQueueRunInit:

bitbake/lib/bb/server/process.py

@@ -130,7 +130,6 @@ class ProcessServer(multiprocessing.Process):
         bb.utils.set_process_name("Cooker")
 
         ready = []
-        newconnections = []
 
         self.controllersock = False
         fds = [self.sock]
@@ -139,48 +138,37 @@ class ProcessServer(multiprocessing.Process):
         print("Entering server connection loop")
 
         def disconnect_client(self, fds):
+            if not self.haveui:
+                return
             print("Disconnecting Client")
-            if self.controllersock:
-                fds.remove(self.controllersock)
-                self.controllersock.close()
-                self.controllersock = False
-            if self.haveui:
-                fds.remove(self.command_channel)
-                bb.event.unregister_UIHhandler(self.event_handle, True)
-                self.command_channel_reply.writer.close()
-                self.event_writer.writer.close()
-                self.command_channel.close()
-                self.command_channel = False
-                del self.event_writer
-                self.lastui = time.time()
-                self.cooker.clientComplete()
-                self.haveui = False
-            ready = select.select(fds,[],[],0)[0]
-            if newconnections:
-                print("Starting new client")
-                conn = newconnections.pop(-1)
-                fds.append(conn)
-                self.controllersock = conn
-            elif self.timeout is None and not ready:
+            fds.remove(self.controllersock)
+            fds.remove(self.command_channel)
+            bb.event.unregister_UIHhandler(self.event_handle, True)
+            self.command_channel_reply.writer.close()
+            self.event_writer.writer.close()
+            del self.event_writer
+            self.controllersock.close()
+            self.controllersock = False
+            self.haveui = False
+            self.lastui = time.time()
+            self.cooker.clientComplete()
+            if self.timeout is None:
                 print("No timeout, exiting.")
                 self.quit = True
 
         while not self.quit:
             if self.sock in ready:
-                while select.select([self.sock],[],[],0)[0]:
-                    controllersock, address = self.sock.accept()
-                    if self.controllersock:
-                        print("Queuing %s (%s)" % (str(ready), str(newconnections)))
-                        newconnections.append(controllersock)
-                    else:
-                        print("Accepting %s (%s)" % (str(ready), str(newconnections)))
-                        self.controllersock = controllersock
-                        fds.append(controllersock)
+                self.controllersock, address = self.sock.accept()
+                if self.haveui:
+                    print("Dropping connection attempt as we have a UI %s" % (str(ready)))
+                    self.controllersock.close()
+                else:
+                    print("Accepting %s" % (str(ready)))
+                    fds.append(self.controllersock)
             if self.controllersock in ready:
                 try:
-                    print("Processing Client")
-                    ui_fds = recvfds(self.controllersock, 3)
                     print("Connecting Client")
+                    ui_fds = recvfds(self.controllersock, 3)
 
                     # Where to write events to
                     writer = ConnectionWriter(ui_fds[0])
@@ -251,12 +239,6 @@ class ProcessServer(multiprocessing.Process):
         while not lock:
             with bb.utils.timeout(3):
                 lock = bb.utils.lockfile(lockfile, shared=False, retry=False, block=True)
-                if lock:
-                    # We hold the lock so we can remove the file (hide stale pid data)
-                    bb.utils.remove(lockfile)
-                    bb.utils.unlockfile(lock)
-                    return
-
                 if not lock:
                     # Some systems may not have lsof available
                     procs = None
@@ -277,6 +259,10 @@ class ProcessServer(multiprocessing.Process):
                     if procs:
                         msg += ":\n%s" % str(procs)
                     print(msg)
+                    return
+        # We hold the lock so we can remove the file (hide stale pid data)
+        bb.utils.remove(lockfile)
+        bb.utils.unlockfile(lock)
 
     def idle_commands(self, delay, fds=None):
         nextsleep = delay
@@ -410,10 +396,7 @@ class BitBakeServer(object):
         self.bitbake_lock.close()
 
         ready = ConnectionReader(self.readypipe)
-        r = ready.poll(5)
-        if not r:
-            bb.note("Bitbake server didn't start within 5 seconds, waiting for 90")
-            r = ready.poll(90)
+        r = ready.poll(30)
         if r:
             r = ready.get()
         if not r or r != "ready":
@@ -423,40 +406,28 @@ class BitBakeServer(object):
                 logstart_re = re.compile(self.start_log_format % ('([0-9]+)', '([0-9-]+ [0-9:.]+)'))
                 started = False
                 lines = []
-                lastlines = []
                 with open(logfile, "r") as f:
                     for line in f:
                         if started:
                             lines.append(line)
                         else:
-                            lastlines.append(line)
                             res = logstart_re.match(line.rstrip())
                             if res:
                                 ldatetime = datetime.datetime.strptime(res.group(2), self.start_log_datetime_format)
                                 if ldatetime >= startdatetime:
                                     started = True
                                     lines.append(line)
-                        if len(lastlines) > 60:
-                            lastlines = lastlines[-60:]
                 if lines:
-                    if len(lines) > 60:
-                        bb.error("Last 60 lines of server log for this session (%s):\n%s" % (logfile, "".join(lines[-60:])))
+                    if len(lines) > 10:
+                        bb.error("Last 10 lines of server log for this session (%s):\n%s" % (logfile, "".join(lines[-10:])))
                     else:
                         bb.error("Server log for this session (%s):\n%s" % (logfile, "".join(lines)))
-                elif lastlines:
-                        bb.error("Server didn't start, last 60 loglines (%s):\n%s" % (logfile, "".join(lastlines)))
-            else:
-                bb.error("%s doesn't exist" % logfile)
-
             raise SystemExit(1)
-
         ready.close()
         os.close(self.readypipein)
 
     def _startServer(self):
         print(self.start_log_format % (os.getpid(), datetime.datetime.now().strftime(self.start_log_datetime_format)))
-        sys.stdout.flush()
-
         server = ProcessServer(self.bitbake_lock, self.sock, self.sockname)
         self.configuration.setServerRegIdleCallback(server.register_idle_function)
         writer = ConnectionWriter(self.readypipein)
@@ -472,8 +443,6 @@ class BitBakeServer(object):
         server.server_timeout = self.configuration.server_timeout
         server.xmlrpcinterface = self.configuration.xmlrpcinterface
         print("Started bitbake server pid %d" % os.getpid())
-        sys.stdout.flush()
-
         server.start()
 
 def connectProcessServer(sockname, featureset):
@@ -482,24 +451,16 @@ def connectProcessServer(sockname, featureset):
     # AF_UNIX has path length issues so chdir here to workaround
     cwd = os.getcwd()
 
+    try:
+        os.chdir(os.path.dirname(sockname))
+        sock.connect(os.path.basename(sockname))
+    finally:
+        os.chdir(cwd)
+
     readfd = writefd = readfd1 = writefd1 = readfd2 = writefd2 = None
     eq = command_chan_recv = command_chan = None
 
-    sock.settimeout(10)
-
     try:
-        try:
-            os.chdir(os.path.dirname(sockname))
-            finished = False
-            while not finished:
-                try:
-                    sock.connect(os.path.basename(sockname))
-                    finished = True
-                except IOError as e:
-                    if e.errno == errno.EWOULDBLOCK:
-                        pass
-        finally:
-            os.chdir(cwd)
 
         # Send an fd for the remote to write events to
         readfd, writefd = os.pipe()
@@ -528,8 +489,7 @@ def connectProcessServer(sockname, featureset):
             command_chan.close()
         for i in [writefd, readfd1, writefd2]:
             try:
-                if i:
-                    os.close(i)
+                os.close(i)
             except OSError:
                 pass
         sock.close()

bitbake/lib/bb/tests/fetch.py

@@ -402,6 +402,10 @@ class MirrorUriTest(FetcherTest):
             : "git://somewhere.org/somedir/mtd-utils.git;tag=1234567890123456789012345678901234567890;protocol=http", 
         ("git://git.invalid.infradead.org/foo/mtd-utils.git;tag=1234567890123456789012345678901234567890", "git://.*/.*", "git://somewhere.org/somedir/MIRRORNAME;protocol=http") 
             : "git://somewhere.org/somedir/git.invalid.infradead.org.foo.mtd-utils.git;tag=1234567890123456789012345678901234567890;protocol=http", 
+        ("http://somewhere.org/somedir1/somedir2/somefile_1.2.3.tar.gz", "http://.*/.*", "http://somewhere2.org")
+            : "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",
 
         #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"
@@ -832,7 +836,7 @@ class URLHandle(unittest.TestCase):
     # decodeurl and we need to handle them
     decodedata = datatable.copy()
     decodedata.update({
-       "http://somesite.net;someparam=1": ('http', 'somesite.net', '', '', '', {'someparam': '1'}),
+       "http://somesite.net;someparam=1": ('http', 'somesite.net', '/', '', '', {'someparam': '1'}),
     })
 
     def test_decodeurl(self):
@@ -861,12 +865,12 @@ class FetchLatestVersionTest(FetcherTest):
         ("dtc", "git://git.qemu.org/dtc.git", "65cc4d2748a2c2e6f27f1cf39e07a5dbabd80ebf", "")
             : "1.4.0",
         # combination version pattern
-        ("sysprof", "git://gitlab.gnome.org/GNOME/sysprof;protocol=https", "cd44ee6644c3641507fb53b8a2a69137f2971219", "")
+        ("sysprof", "git://git.gnome.org/sysprof", "cd44ee6644c3641507fb53b8a2a69137f2971219", "")
             : "1.2.0",
         ("u-boot-mkimage", "git://git.denx.de/u-boot.git;branch=master;protocol=git", "62c175fbb8a0f9a926c88294ea9f7e88eb898f6c", "")
             : "2014.01",
         # version pattern "yyyymmdd"
-        ("mobile-broadband-provider-info", "git://gitlab.gnome.org/GNOME/mobile-broadband-provider-info;protocol=https", "4ed19e11c2975105b71b956440acdb25d46a347d", "")
+        ("mobile-broadband-provider-info", "git://git.gnome.org/mobile-broadband-provider-info", "4ed19e11c2975105b71b956440acdb25d46a347d", "")
             : "20120614",
         # packages with a valid UPSTREAM_CHECK_GITTAGREGEX
         ("xf86-video-omap", "git://anongit.freedesktop.org/xorg/driver/xf86-video-omap", "ae0394e687f1a77e966cf72f895da91840dffb8f", "(?P<pver>(\d+\.(\d\.?)*))")
@@ -900,8 +904,8 @@ class FetchLatestVersionTest(FetcherTest):
         # packages with valid UPSTREAM_CHECK_URI and UPSTREAM_CHECK_REGEX
         ("cups", "http://www.cups.org/software/1.7.2/cups-1.7.2-source.tar.bz2", "https://github.com/apple/cups/releases", "(?P<name>cups\-)(?P<pver>((\d+[\.\-_]*)+))\-source\.tar\.gz")
             : "2.0.0",
-        ("db", "http://download.oracle.com/berkeley-db/db-5.3.21.tar.gz", "http://ftp.debian.org/debian/pool/main/d/db5.3/", "(?P<name>db5\.3_)(?P<pver>\d+(\.\d+)+).+\.orig\.tar\.xz")
-            : "5.3.10",
+        ("db", "http://download.oracle.com/berkeley-db/db-5.3.21.tar.gz", "http://www.oracle.com/technetwork/products/berkeleydb/downloads/index-082944.html", "http://download.oracle.com/otn/berkeley-db/(?P<name>db-)(?P<pver>((\d+[\.\-_]*)+))\.tar\.gz")
+            : "6.1.19",
     }
 
     @skipIfNoNetwork()

bitbake/lib/bb/utils.py

@@ -524,17 +524,12 @@ def md5_file(filename):
     """
     Return the hex string representation of the MD5 checksum of filename.
     """
-    import hashlib, mmap
+    import hashlib
+    m = hashlib.md5()
 
     with open(filename, "rb") as f:
-        m = hashlib.md5()
-        try:
-            with mmap.mmap(f.fileno(), 0, access=mmap.ACCESS_READ) as mm:
-                for chunk in iter(lambda: mm.read(8192), b''):
-                    m.update(chunk)
-        except ValueError:
-            # You can't mmap() an empty file so silence this exception
-            pass
+        for line in f:
+            m.update(line)
     return m.hexdigest()
 
 def sha256_file(filename):
@@ -1290,7 +1285,7 @@ def edit_metadata_file(meta_file, variables, varfunc):
     return updated
 
 
-def edit_bblayers_conf(bblayers_conf, add, remove, edit_cb=None):
+def edit_bblayers_conf(bblayers_conf, add, remove):
     """Edit bblayers.conf, adding and/or removing layers
     Parameters:
         bblayers_conf: path to bblayers.conf file to edit
@@ -1298,8 +1293,6 @@ def edit_bblayers_conf(bblayers_conf, add, remove, edit_cb=None):
             list to add nothing
         remove: layer path (or list of layer paths) to remove; None or
             empty list to remove nothing
-        edit_cb: optional callback function that will be called after
-            processing adds/removes once per existing entry.
     Returns a tuple:
         notadded: list of layers specified to be added but weren't
             (because they were already in the list)
@@ -1363,17 +1356,6 @@ def edit_bblayers_conf(bblayers_conf, add, remove, edit_cb=None):
                     bblayers.append(addlayer)
             del addlayers[:]
 
-        if edit_cb:
-            newlist = []
-            for layer in bblayers:
-                res = edit_cb(layer, canonicalise_path(layer))
-                if res != layer:
-                    newlist.append(res)
-                    updated = True
-                else:
-                    newlist.append(layer)
-            bblayers = newlist
-
         if updated:
             if op == '+=' and not bblayers:
                 bblayers = None

bitbake/lib/bblayers/layerindex.py

@@ -133,7 +133,7 @@ class LayerIndexPlugin(ActionPlugin):
         layerdir = os.path.join(repodir, subdir)
         if not os.path.exists(repodir):
             if fetch_layer:
-                result = subprocess.call(['git', 'clone', url, repodir])
+                result = subprocess.call('git clone %s %s' % (url, repodir), shell = True)
                 if result:
                     logger.error("Failed to download %s" % url)
                     return None, None

bitbake/lib/toaster/bldcontrol/localhostbecontroller.py

@@ -217,21 +217,9 @@ class LocalhostBEController(BuildEnvironmentController):
         self.setCloneStatus(bitbake,'complete',clone_total,clone_count)
         logger.debug("localhostbecontroller: current layer list %s " % pformat(layerlist))
 
-        # Resolve self.pokydirname if not resolved yet, consider the scenario
-        # where all layers are local, that's the else clause
-        if self.pokydirname is None:
-            if os.path.exists(os.path.join(self.be.sourcedir, "oe-init-build-env")):
-                logger.debug("localhostbecontroller: selected poky dir name %s" % self.be.sourcedir)
-                self.pokydirname = self.be.sourcedir
-            else:
-                # Alternatively, scan local layers for relative "oe-init-build-env" location
-                for layer in layers:
-                    if os.path.exists(os.path.join(layer.layer_version.layer.local_source_dir,"..","oe-init-build-env")):
-                        logger.debug("localhostbecontroller, setting pokydirname to %s" % (layer.layer_version.layer.local_source_dir))
-                        self.pokydirname = os.path.join(layer.layer_version.layer.local_source_dir,"..")
-                        break
-                else:
-                    logger.error("pokydirname is not set, you will run into trouble!")
+        if self.pokydirname is None and os.path.exists(os.path.join(self.be.sourcedir, "oe-init-build-env")):
+            logger.debug("localhostbecontroller: selected poky dir name %s" % self.be.sourcedir)
+            self.pokydirname = self.be.sourcedir
 
         # 5. create custom layer and add custom recipes to it
         for target in targets:
@@ -351,21 +339,8 @@ class LocalhostBEController(BuildEnvironmentController):
         # clean the Toaster to build environment
         env_clean = 'unset BBPATH;' # clean BBPATH for <= YP-2.4.0
 
-        # run bitbake server from the clone if available
-        # otherwise pick it from the PATH
-        bitbake = os.path.join(self.pokydirname, 'bitbake', 'bin', 'bitbake')
-        if not os.path.exists(bitbake):
-            logger.info("Bitbake not available under %s, will try to use it from PATH" %
-                        self.pokydirname)
-            for path in os.environ["PATH"].split(os.pathsep):
-                if os.path.exists(os.path.join(path, 'bitbake')):
-                    bitbake = os.path.join(path, 'bitbake')
-                    logger.info("Found Bitbake at: %s" % path)
-                    break
-            else:
-                logger.error("Looks like Bitbake is not available, please fix your environment")
-
         # run bitbake server from the clone
+        bitbake = os.path.join(self.pokydirname, 'bitbake', 'bin', 'bitbake')
         toasterlayers = os.path.join(builddir,"conf/toaster-bblayers.conf")
         self._shellcmd('%s bash -c \"source %s %s; BITBAKE_UI="knotty" %s --read %s --read %s '
                        '--server-only -B 0.0.0.0:0\"' % (env_clean, oe_init,

bitbake/lib/toaster/bldcontrol/management/commands/checksettings.py

@@ -74,9 +74,8 @@ class Command(BaseCommand):
                         print("Loading default settings")
                         call_command("loaddata", "settings")
                         template_conf = os.environ.get("TEMPLATECONF", "")
-                        custom_xml_only = os.environ.get("CUSTOM_XML_ONLY")
 
-                        if ToasterSetting.objects.filter(name='CUSTOM_XML_ONLY').count() > 0 or (not custom_xml_only == None):
+                        if ToasterSetting.objects.filter(name='CUSTOM_XML_ONLY').count() > 0:
                             # only use the custom settings
                             pass
                         elif "poky" in template_conf:

bitbake/lib/toaster/orm/models.py

@@ -1663,9 +1663,6 @@ class CustomImageRecipe(Recipe):
 
         path_schema_two = self.base_recipe.file_path
 
-        path_schema_three = "%s/%s" % (self.base_recipe.layer_version.layer.local_source_dir,
-                                     self.base_recipe.file_path)
-
         if os.path.exists(path_schema_one):
             return path_schema_one
 
@@ -1673,10 +1670,6 @@ class CustomImageRecipe(Recipe):
         if os.path.exists(path_schema_two):
             return path_schema_two
 
-        # Or a local path if all layers are local
-        if os.path.exists(path_schema_three):
-            return path_schema_three
-
         return None
 
     def generate_recipe_file_contents(self):

bitbake/lib/toaster/toastergui/static/js/layerdetails.js

@@ -359,8 +359,7 @@ function layerDetailsPageInit (ctx) {
     if ($(this).is("dt")) {
       var dd = $(this).next("dd");
       if (!dd.children("form:visible")|| !dd.find(".current-value").html()){
-        if (ctx.layerVersion.layer_source == ctx.layerSourceTypes.TYPE_IMPORTED ||
-            ctx.layerVersion.layer_source == ctx.layerSourceTypes.TYPE_LOCAL) {
+        if (ctx.layerVersion.layer_source == ctx.layerSourceTypes.TYPE_IMPORTED){
         /* There's no current value and the layer is editable
          * so show the "Not set" and hide the delete icon
          */

bitbake/lib/toaster/toastergui/templates/newproject.html

@@ -54,12 +54,12 @@
                     <span class="help-block">{{release.helptext|safe}}</span>
                   </div>
                 {% endfor %}
-                </div>
-              </div>
             {% else %}
               <input type="hidden" name="projectversion" value="{{releases.0.id}}"/>
             {% endif %}
                 </div>
+              </div>
+            </fieldset>
         {% endif %}
             <div class="top-air">
               <input type="submit" id="create-project-button" class="btn btn-primary btn-lg" value="Create project"/>

bitbake/lib/toaster/toastergui/templates/recipe.html

@@ -176,7 +176,7 @@
                     <td>{{task.get_executed_display}}</td>
 
                     <td>{{task.get_outcome_display}} 
-                        {% if task.outcome == task.OUTCOME_FAILED %}
+                        {% if task.outcome = task.OUTCOME_FAILED %}
                             <a href="{% url 'build_artifact' build.pk "tasklogfile" task.pk %}">
                                 <span class="glyphicon glyphicon-download-alt
                                     get-help" title="Download task log

bitbake/lib/toaster/toastergui/widgets.py

@@ -511,18 +511,13 @@ class MostRecentBuildsView(View):
                 buildrequest_id = build_obj.buildrequest.pk
             build['buildrequest_id'] = buildrequest_id
 
-            if build_obj.recipes_to_parse > 0:
-                build['recipes_parsed_percentage'] = \
-                    int((build_obj.recipes_parsed /
-                         build_obj.recipes_to_parse) * 100)
-            else:
-                build['recipes_parsed_percentage'] = 0
-            if build_obj.repos_to_clone > 0:
-                build['repos_cloned_percentage'] = \
-                    int((build_obj.repos_cloned /
-                         build_obj.repos_to_clone) * 100)
-            else:
-                build['repos_cloned_percentage'] = 0
+            build['recipes_parsed_percentage'] = \
+                int((build_obj.recipes_parsed /
+                     build_obj.recipes_to_parse) * 100)
+
+            build['repos_cloned_percentage'] = \
+                int((build_obj.repos_cloned /
+                     build_obj.repos_to_clone) * 100)
 
             tasks_complete_percentage = 0
             if build_obj.outcome in (Build.SUCCEEDED, Build.FAILED):

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/sdk-autotools-flow.png figures/sdk-makefile-flow.png
+	figures/overview-manual-title.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-autotools-flow.png figures/sdk-makefile-flow.png \
+	   figures/sdk-devtool-upgrade-flow.png \
            eclipse
 MANUALS = $(DOC)/$(DOC).html $(DOC)/eclipse
 FIGURES = figures

documentation/brief-yoctoprojectqs/brief-yoctoprojectqs.xml

@@ -131,43 +131,19 @@
             <literallayout class='monospaced'>
      $ git clone git://git.yoctoproject.org/poky
      Cloning into 'poky'...
-     remote: Counting objects: 431956, done.
-     remote: Compressing objects: 100% (101918/101918), done.
-     remote: Total 431956 (delta 322982), reused 431910 (delta 322936)
-     Receiving objects: 100% (431956/431956), 153.76 MiB | 6.86 MiB/s, done.
-     Resolving deltas: 100% (322982/322982), done.
+     remote: Counting objects: 361782, done.
+     remote: Compressing objects: 100% (87100/87100), done.
+     remote: Total 361782 (delta 268619), reused 361439 (delta 268277)
+     Receiving objects: 100% (361782/361782), 131.94 MiB | 6.88 MiB/s, done.
+     Resolving deltas: 100% (268619/268619), done.
      Checking connectivity... done.
+     $ git checkout tags/yocto-2.5 -b my-yocto-2.5
             </literallayout>
-            Move to the poky directory and take a look at the tags:
-            <literallayout class='monospaced'>
-     $ cd poky
-     $ git fetch --tags
-     $ git tag
-     1.1_M1.final
-     1.1_M1.rc1
-     1.1_M1.rc2
-     1.1_M2.final
-     1.1_M2.rc1
-        .
-        .
-        .
-     yocto-2.5.2
-     yocto-2.5.3
-     yocto-2.6
-     yocto-2.6.1
-     yocto_1.5_M5.rc8
-            </literallayout>
-            For this example, check out the branch based on the
-            yocto-&DISTRO; release:
-            <literallayout class='monospaced'>
-     $ git checkout tags/yocto-&DISTRO; -b my-yocto-&DISTRO;
-     Switched to a new branch 'my-yocto-&DISTRO;'
-            </literallayout>
-            The previous Git checkout command creates a local branch named
-            my-yocto-&DISTRO;.
-            The files available to you in that branch exactly match the
-            repository's files in the "&DISTRO_NAME_NO_CAP;" development
-            branch at the time of the Yocto Project yocto-&DISTRO; release.
+            The previous Git checkout command creates a local branch
+            named my-&DISTRO_REL_TAG;. The files available to you in that
+            branch exactly match the repository's files in the
+            "&DISTRO_NAME_NO_CAP;" development branch at the time of the
+            Yocto Project &DISTRO; release.
         </para>
 
         <para>

documentation/bsp-guide/bsp-guide.xml

@@ -122,19 +122,9 @@
                 <revremark>Released with the Yocto Project 2.5 Release.</revremark>
             </revision>
             <revision>
-                <revnumber>2.5.1</revnumber>
-                <date>September 2018</date>
-                <revremark>The initial document released with the Yocto Project 2.5.1 Release.</revremark>
-            </revision>
-            <revision>
-                <revnumber>2.5.2</revnumber>
-                <date>January 2019</date>
-                <revremark>The initial document released with the Yocto Project 2.5.2 Release.</revremark>
-            </revision>
-            <revision>
-                <revnumber>2.5.3</revnumber>
+                <revnumber>2.6</revnumber>
                 <date>&REL_MONTH_YEAR;</date>
-                <revremark>The initial document released with the Yocto Project 2.5.3 Release.</revremark>
+                <revremark>Released with the Yocto Project 2.6 Release.</revremark>
             </revision>
         </revhistory>
 

documentation/dev-manual/dev-manual-start.xml

@@ -881,11 +881,11 @@
                     <literallayout class='monospaced'>
      $ git clone git://git.yoctoproject.org/poky
      Cloning into 'poky'...
-     remote: Counting objects: 431956, done.
-     remote: Compressing objects: 100% (101918/101918), done.
-     remote: Total 431956 (delta 322982), reused 431910 (delta 322936)
-     Receiving objects: 100% (431956/431956), 153.76 MiB | 6.86 MiB/s, done.
-     Resolving deltas: 100% (322982/322982), done.
+     remote: Counting objects: 367178, done.
+     remote: Compressing objects: 100% (88161/88161), done.
+     remote: Total 367178 (delta 272761), reused 366942 (delta 272525)
+     Receiving objects: 100% (367178/367178), 133.26 MiB | 6.40 MiB/s, done.
+     Resolving deltas: 100% (272761/272761), done.
      Checking connectivity... done.
                     </literallayout>
                     Unless you specify a specific development branch or
@@ -963,12 +963,13 @@
            .
            .
            .
+       remotes/origin/master-next
+       remotes/origin/master-next2
+       remotes/origin/morty
+       remotes/origin/pinky
+       remotes/origin/purple
+       remotes/origin/pyro
        remotes/origin/rocko
-       remotes/origin/rocko-next
-       remotes/origin/sumo
-       remotes/origin/sumo-next
-       remotes/origin/thud
-       remotes/origin/thud-next
                     </literallayout>
                     </para></listitem>
                 <listitem><para>
@@ -1047,10 +1048,11 @@
         .
         .
         .
-     yocto-2.5.2
-     yocto-2.5.3
-     yocto-2.6
-     yocto-2.6.1
+     yocto-2.2
+     yocto-2.2.1
+     yocto-2.3
+     yocto-2.3.1
+     yocto-2.4
      yocto_1.5_M5.rc8
                     </literallayout>
                     </para></listitem>

documentation/dev-manual/dev-manual.xml

@@ -107,19 +107,9 @@
                 <revremark>Released with the Yocto Project 2.5 Release.</revremark>
             </revision>
             <revision>
-                <revnumber>2.5.1</revnumber>
-                <date>September 2018</date>
-                <revremark>The initial document released with the Yocto Project 2.5.1 Release.</revremark>
-            </revision>
-            <revision>
-                <revnumber>2.5.2</revnumber>
-                <date>January 2019</date>
-                <revremark>The initial document released with the Yocto Project 2.5.2 Release.</revremark>
-            </revision>
-            <revision>
-                <revnumber>2.5.3</revnumber>
+                <revnumber>2.6</revnumber>
                 <date>&REL_MONTH_YEAR;</date>
-                <revremark>The initial document released with the Yocto Project 2.5.3 Release.</revremark>
+                <revremark>Released with the Yocto Project 2.6 Release.</revremark>
             </revision>
         </revhistory>
 

documentation/kernel-dev/kernel-dev-common.xml

@@ -1603,11 +1603,8 @@
             <title>Creating a&nbsp;&nbsp;<filename>defconfig</filename> File</title>
 
             <para>
-                A <filename>defconfig</filename> file in the context of
-                the Yocto Project is often a <filename>.config</filename>
-                file that is copied from a build or a
-                <filename>defconfig</filename> taken from the kernel tree
-                and moved into recipe space.
+                A <filename>defconfig</filename> file is simply a
+                <filename>.config</filename> renamed to "defconfig".
                 You can use a <filename>defconfig</filename> file
                 to retain a known set of kernel configurations from which the
                 OpenEmbedded build system can draw to create the final

documentation/kernel-dev/kernel-dev.xml

@@ -92,19 +92,9 @@
                 <revremark>Released with the Yocto Project 2.5 Release.</revremark>
             </revision>
             <revision>
-                <revnumber>2.5.1</revnumber>
-                <date>September 2018</date>
-                <revremark>The initial document released with the Yocto Project 2.5.1 Release.</revremark>
-            </revision>
-            <revision>
-                <revnumber>2.5.2</revnumber>
-                <date>January 2019</date>
-                <revremark>The initial document released with the Yocto Project 2.5.2 Release.</revremark>
-            </revision>
-            <revision>
-                <revnumber>2.5.3</revnumber>
+                <revnumber>2.6</revnumber>
                 <date>&REL_MONTH_YEAR;</date>
-                <revremark>The initial document released with the Yocto Project 2.5.3 Release.</revremark>
+                <revremark>Released with the Yocto Project 2.6 Release.</revremark>
             </revision>
         </revhistory>
 

documentation/mega-manual/mega-manual.xml

@@ -76,19 +76,9 @@
                 <revremark>Released with the Yocto Project 2.5 Release.</revremark>
             </revision>
             <revision>
-                <revnumber>2.5.1</revnumber>
-                <date>September 2018</date>
-                <revremark>The initial document released with the Yocto Project 2.5.1 Release.</revremark>
-            </revision>
-            <revision>
-                <revnumber>2.5.2</revnumber>
-                <date>January 2019</date>
-                <revremark>The initial document released with the Yocto Project 2.5.2 Release.</revremark>
-            </revision>
-            <revision>
-                <revnumber>2.5.3</revnumber>
+                <revnumber>2.6</revnumber>
                 <date>&REL_MONTH_YEAR;</date>
-                <revremark>The initial document released with the Yocto Project 2.5.3 Release.</revremark>
+                <revremark>Released with the Yocto Project 2.6 Release.</revremark>
             </revision>
        </revhistory>
 

documentation/overview-manual/overview-manual.xml

@@ -37,19 +37,9 @@
                 <revremark>The initial document released with the Yocto Project 2.5 Release.</revremark>
             </revision>
             <revision>
-                <revnumber>2.5.1</revnumber>
-                <date>September 2018</date>
-                <revremark>The initial document released with the Yocto Project 2.5.1 Release.</revremark>
-            </revision>
-            <revision>
-                <revnumber>2.5.2</revnumber>
-                <date>January 2019</date>
-                <revremark>The initial document released with the Yocto Project 2.5.2 Release.</revremark>
-            </revision>
-            <revision>
-                <revnumber>2.5.3</revnumber>
+                <revnumber>2.6</revnumber>
                 <date>&REL_MONTH_YEAR;</date>
-                <revremark>The initial document released with the Yocto Project 2.5.3 Release.</revremark>
+                <revremark>Released with the Yocto Project 2.6 Release.</revremark>
             </revision>
         </revhistory>
 

documentation/poky.ent

@@ -1,19 +1,19 @@
-<!ENTITY DISTRO "2.5.3">
-<!ENTITY DISTRO_COMPRESSED "253">
-<!ENTITY DISTRO_NAME_NO_CAP "sumo">
-<!ENTITY DISTRO_NAME "Sumo">
-<!ENTITY DISTRO_NAME_NO_CAP_MINUS_ONE "rocko">
-<!ENTITY DISTRO_NAME_MINUS_ONE "Rocko">
-<!ENTITY YOCTO_DOC_VERSION "2.5.3">
-<!ENTITY YOCTO_DOC_VERSION_MINUS_ONE "2.4.4">
-<!ENTITY DISTRO_REL_TAG "yocto-2.5.3">
-<!ENTITY METAINTELVERSION "9.2">
-<!ENTITY REL_MONTH_YEAR "March 2019">
+<!ENTITY DISTRO "2.6">
+<!ENTITY DISTRO_COMPRESSED "26">
+<!ENTITY DISTRO_NAME_NO_CAP "thud">
+<!ENTITY DISTRO_NAME "Thud">
+<!ENTITY DISTRO_NAME_NO_CAP_MINUS_ONE "sumo">
+<!ENTITY DISTRO_NAME_MINUS_ONE "Sumo">
+<!ENTITY YOCTO_DOC_VERSION "2.6">
+<!ENTITY YOCTO_DOC_VERSION_MINUS_ONE "2.5">
+<!ENTITY DISTRO_REL_TAG "yocto-2.6">
+<!ENTITY METAINTELVERSION "9.0">
+<!ENTITY REL_MONTH_YEAR "TBD">
 <!ENTITY META_INTEL_REL_TAG "&METAINTELVERSION;-&DISTRO_NAME_NO_CAP;-&YOCTO_DOC_VERSION;">
-<!ENTITY POKYVERSION "20.0.3">
-<!ENTITY POKYVERSION_COMPRESSED "2003">
+<!ENTITY POKYVERSION "21.0.0">
+<!ENTITY POKYVERSION_COMPRESSED "2100">
 <!ENTITY YOCTO_POKY "poky-&DISTRO_NAME_NO_CAP;-&POKYVERSION;">
-<!ENTITY COPYRIGHT_YEAR "2010-2019">
+<!ENTITY COPYRIGHT_YEAR "2010-2018">
 <!ENTITY YOCTO_DL_URL "http://downloads.yoctoproject.org">
 <!ENTITY YOCTO_HOME_URL "http://www.yoctoproject.org">
 <!ENTITY YOCTO_LISTS_URL "http://lists.yoctoproject.org">

documentation/profile-manual/profile-manual.xml

@@ -92,19 +92,9 @@
                 <revremark>Released with the Yocto Project 2.5 Release.</revremark>
             </revision>
             <revision>
-                <revnumber>2.5.1</revnumber>
-                <date>September 2018</date>
-                <revremark>The initial document released with the Yocto Project 2.5.1 Release.</revremark>
-            </revision>
-            <revision>
-                <revnumber>2.5.2</revnumber>
-                <date>January 2019</date>
-                <revremark>The initial document released with the Yocto Project 2.5.2 Release.</revremark>
-            </revision>
-            <revision>
-                <revnumber>2.5.3</revnumber>
+                <revnumber>2.6</revnumber>
                 <date>&REL_MONTH_YEAR;</date>
-                <revremark>The initial document released with the Yocto Project 2.5.3 Release.</revremark>
+                <revremark>Released with the Yocto Project 2.6 Release.</revremark>
             </revision>
         </revhistory>
 

documentation/ref-manual/ref-manual.xml

@@ -123,19 +123,9 @@
                 <revremark>Released with the Yocto Project 2.5 Release.</revremark>
             </revision>
             <revision>
-                <revnumber>2.5.1</revnumber>
-                <date>September 2018</date>
-                <revremark>The initial document released with the Yocto Project 2.5.1 Release.</revremark>
-            </revision>
-            <revision>
-                <revnumber>2.5.2</revnumber>
-                <date>January 2019</date>
-                <revremark>The initial document released with the Yocto Project 2.5.2 Release.</revremark>
-            </revision>
-            <revision>
-                <revnumber>2.5.3</revnumber>
+                <revnumber>2.6</revnumber>
                 <date>&REL_MONTH_YEAR;</date>
-                <revremark>The initial document released with the Yocto Project 2.5.3 Release.</revremark>
+                <revremark>Released with the Yocto Project 2.6 Release.</revremark>
             </revision>
         </revhistory>
 

documentation/ref-manual/ref-variables.xml

@@ -3636,17 +3636,10 @@
                 <para role="glossdeffirst">
 <!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
                     The short name of the distribution.
-                    For information on the long name of the distribution, see
-                    the
-                    <link linkend='var-DISTRO_NAME'><filename>DISTRO_NAME</filename></link>
-                    variable.
-                </para>
-
-                <para>
-                    The <filename>DISTRO</filename> variable corresponds to a
-                    distribution configuration file whose root name is the
-                    same as the variable's argument and whose filename
-                    extension is <filename>.conf</filename>.
+                    This variable corresponds to a distribution
+                    configuration file whose root name is the same as the
+                    variable's argument and whose filename extension is
+                    <filename>.conf</filename>.
                     For example, the distribution configuration file for the
                     Poky distribution is named <filename>poky.conf</filename>
                     and resides in the
@@ -3671,9 +3664,9 @@
                     The value for <filename>DISTRO</filename> must not contain
                     spaces, and is typically all lower-case.
                     <note>
-                        If the <filename>DISTRO</filename> variable is blank,
-                        a set of default configurations are used, which are
-                        specified within
+                        If the <filename>DISTRO</filename> variable is blank, a set
+                        of default configurations are used, which are specified
+                        within
                         <filename>meta/conf/distro/defaultsetup.conf</filename>
                         also in the Source Directory.
                     </note>
@@ -3938,46 +3931,6 @@
                 <para role="glossdeffirst">
 <!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
                     The long name of the distribution.
-                    For information on the short name of the distribution, see
-                    the
-                    <link linkend='var-DISTRO'><filename>DISTRO</filename></link>
-                    variable.
-                </para>
-
-                <para>
-                    The <filename>DISTRO_NAME</filename> variable corresponds
-                    to a distribution configuration file whose root name is the
-                    same as the variable's argument and whose filename
-                    extension is <filename>.conf</filename>.
-                    For example, the distribution configuration file for the
-                    Poky distribution is named <filename>poky.conf</filename>
-                    and resides in the
-                    <filename>meta-poky/conf/distro</filename> directory of
-                    the
-                    <link linkend='source-directory'>Source Directory</link>.
-                </para>
-
-                <para>
-                    Within that <filename>poky.conf</filename> file, the
-                    <filename>DISTRO_NAME</filename> variable is set as
-                    follows:
-                    <literallayout class='monospaced'>
-     DISTRO_NAME = "Poky (Yocto Project Reference Distro)"
-                    </literallayout>
-                </para>
-
-                <para>
-                    Distribution configuration files are located in a
-                    <filename>conf/distro</filename> directory within the
-                    <link linkend='metadata'>Metadata</link>
-                    that contains the distribution configuration.
-                    <note>
-                        If the <filename>DISTRO_NAME</filename> variable is
-                        blank, a set of default configurations are used, which
-                        are specified within
-                        <filename>meta/conf/distro/defaultsetup.conf</filename>
-                        also in the Source Directory.
-                    </note>
                 </para>
             </glossdef>
         </glossentry>
@@ -9964,7 +9917,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     execute at rootfs creation time rather than on the
                     target but depends on a native tool in order to execute,
                     you need to list the tools in
-                    <filename>PACKAGE_WRITE_DEPS</filename>.
+                    <filename>PACKAGE_WRITE_DEPENDS</filename>.
                 </para>
 
                 <para>
@@ -12222,26 +12175,13 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     A list of classes to remove from the
                     <link linkend='var-INHERIT'><filename>INHERIT</filename></link>
                     value globally within the extensible SDK configuration.
-                    The
-                    <link linkend='ref-classes-populate-sdk-*'><filename>populate-sdk-ext</filename></link>
-                    class sets the default value:
-                    <literallayout class='monospaced'>
-     SDK_INHERIT_BLACKLIST ?= "buildhistory icecc"
-                    </literallayout>
+                    The default value is "buildhistory icecc".
                 </para>
 
                 <para>
                     Some classes are not generally applicable within
-                    the extensible SDK context.
-                    You can use this variable to disable those classes.
-                </para>
-
-                <para>
-                    For additional information on how to customize the
-                    extensible SDK's configuration, see the
-                    "<ulink url='&YOCTO_DOCS_SDK_URL;#sdk-configuring-the-extensible-sdk'>Configuring the Extensible SDK</ulink>"
-                    section in the Yocto Project Application Development and
-                    the Extensible Software Development Kit (eSDK) manual.
+                    the extensible SDK context and you can use this variable
+                    to disable them.
                 </para>
             </glossdef>
         </glossentry>
@@ -12253,40 +12193,12 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
             <glossdef>
                 <para role="glossdeffirst">
 <!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
-                    A list of variables not allowed through from the
-                    OpenEmbedded build system configuration into the extensible
-                    SDK configuration.
+                    A list of variables not allowed through from the build
+                    system configuration into the extensible SDK configuration.
                     Usually, these are variables that are specific to the
                     machine on which the build system is running and thus
                     would be potentially problematic within the extensible SDK.
-                    </para>
-
-                    <para>By default,
-                    <filename>SDK_LOCAL_CONF_BLACKLIST</filename> is set in the
-                    <link linkend='ref-classes-populate-sdk-*'><filename>populate-sdk-ext</filename></link>
-                    class and excludes the following variables:
-                    <literallayout class='monospaced'>
-     <link linkend='var-CONF_VERSION'>CONF_VERSION</link>
-     <link linkend='var-BB_NUMBER_THREADS'>BB_NUMBER_THREADS</link>
-     <ulink url='&YOCTO_DOCS_BB_URL;#var-BB_NUMBER_PARSE_THREADS'>BB_NUMBER_PARSE_THREADS</ulink>
-     <link linkend='var-PARALLEL_MAKE'>PARALLEL_MAKE</link>
-     <link linkend='var-PRSERV_HOST'>PRSERV_HOST</link>
-     <link linkend='var-SSTATE_MIRRORS'>SSTATE_MIRRORS</link>
-     <link linkend='var-DL_DIR'>DL_DIR</link>
-     <link linkend='var-SSTATE_DIR'>SSTATE_DIR</link>
-     <link linkend='var-TMPDIR'>TMPDIR</link>
-     <link linkend='var-BB_SERVER_TIMEOUT'>BB_SERVER_TIMEOUT</link>
-                    </literallayout>
                 </para>
-
-                <para>
-                    For additional information on how to customize the
-                    extensible SDK's configuration, see the
-                    "<ulink url='&YOCTO_DOCS_SDK_URL;#sdk-configuring-the-extensible-sdk'>Configuring the Extensible SDK</ulink>"
-                    section in the Yocto Project Application Development and
-                    the Extensible Software Development Kit (eSDK) manual.
-                </para>
-
             </glossdef>
         </glossentry>
 
@@ -12297,16 +12209,8 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
             <glossdef>
                 <para role="glossdeffirst">
 <!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
-                    A list of variables allowed through from the OpenEmbedded
-                    build system configuration into the extensible SDK
-                    configuration.
-                    By default, the list of variables is empty and is set in
-                    the
-                    <link linkend='ref-classes-populate-sdk-*'><filename>populate-sdk-ext</filename></link>
-                    class.
-                </para>
-
-                <para>
+                    A list of variables allowed through from the build system
+                    configuration into the extensible SDK configuration.
                     This list overrides the variables specified using the
                     <link linkend='var-SDK_LOCAL_CONF_BLACKLIST'><filename>SDK_LOCAL_CONF_BLACKLIST</filename></link>
                     variable as well as any variables identified by automatic
@@ -12315,14 +12219,6 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     path and thus might not be valid on the system where the
                     SDK is installed.
                 </para>
-
-                <para>
-                    For additional information on how to customize the
-                    extensible SDK's configuration, see the
-                    "<ulink url='&YOCTO_DOCS_SDK_URL;#sdk-configuring-the-extensible-sdk'>Configuring the Extensible SDK</ulink>"
-                    section in the Yocto Project Application Development and
-                    the Extensible Software Development Kit (eSDK) manual.
-                </para>
             </glossdef>
         </glossentry>
 
@@ -13301,7 +13197,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                             </para></listitem>
                         <listitem><para><emphasis><filename>maxdate</filename> -</emphasis>
                             Apply the patch only if <filename>SRCDATE</filename>
-                            is not later than <filename>maxdate</filename>.
+                            is not later than <filename>mindate</filename>.
                             </para></listitem>
                         <listitem><para><emphasis><filename>minrev</filename> -</emphasis>
                             Apply the patch only if <filename>SRCREV</filename>
@@ -16412,7 +16308,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
      USERADD_PACKAGES = "${PN}"
                     </literallayout>
                     <note>
-                        It follows that if you are going to use the
+                        If follows that if you are going to use the
                         <filename>USERADD_PACKAGES</filename> variable,
                         you need to set one or more of the
                         <link linkend='var-USERADD_PARAM'><filename>USERADD_PARAM</filename></link>,

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

@@ -17,31 +17,26 @@
         The extensible SDK primarily consists of a pre-configured copy of
         the OpenEmbedded build system from which it was produced.
         Thus, the SDK's configuration is derived using that build system and
-        the filters shown in the following list.
-        When these filters are present, the OpenEmbedded build system applies
-        them against <filename>local.conf</filename> and
-        <filename>auto.conf</filename>:
+        the following filters, which the OpenEmbedded build system applies
+        against <filename>local.conf</filename> and
+        <filename>auto.conf</filename> if they are present:
         <itemizedlist>
             <listitem><para>
                 Variables whose values start with "/" are excluded since the
                 assumption is that those values are paths that are likely to
-                be specific to the
-                <ulink url='&YOCTO_DOCS_REF_URL;#hardware-build-system-term'>build host</ulink>.
+                be specific to the build host.
                 </para></listitem>
             <listitem><para>
                 Variables listed in
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-SDK_LOCAL_CONF_BLACKLIST'><filename>SDK_LOCAL_CONF_BLACKLIST</filename></ulink>
                 are excluded.
-                These variables are not allowed through from the OpenEmbedded
-                build system configuration into the extensible SDK
-                configuration.
-                Typically, these variables are specific to the machine on
-                which the build system is running and could be problematic
-                as part of the extensible SDK configuration.</para>
-
-                <para>For a list of the variables excluded by default, see the
-                <ulink url='&YOCTO_DOCS_REF_URL;#var-SDK_LOCAL_CONF_BLACKLIST'><filename>SDK_LOCAL_CONF_BLACKLIST</filename></ulink>
-                in the glossary of the Yocto Project Reference Manual.
+                The default value blacklists
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-CONF_VERSION'><filename>CONF_VERSION</filename></ulink>,
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename></ulink>,
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-PARALLEL_MAKE'><filename>PARALLEL_MAKE</filename></ulink>,
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-PRSERV_HOST'><filename>PRSERV_HOST</filename></ulink>,
+                and
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-SSTATE_MIRRORS'><filename>SSTATE_MIRRORS</filename></ulink>.
                 </para></listitem>
             <listitem><para>
                 Variables listed in
@@ -49,7 +44,7 @@
                 are included.
                 Including a variable in the value of
                 <filename>SDK_LOCAL_CONF_WHITELIST</filename> overrides either
-                of the previous two filters.
+                of the above two conditions.
                 The default value is blank.
                 </para></listitem>
             <listitem><para>
@@ -59,7 +54,7 @@
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-SDK_INHERIT_BLACKLIST'><filename>SDK_INHERIT_BLACKLIST</filename></ulink>
                 are disabled.
                 Using <filename>SDK_INHERIT_BLACKLIST</filename> to disable
-                these classes is the typical method to disable classes that
+                these classes is is the typical method to disable classes that
                 are problematic or unnecessary in the SDK context.
                 The default value blacklists the
                 <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-buildhistory'><filename>buildhistory</filename></ulink>
@@ -78,13 +73,11 @@
     </para>
 </section>
 
-<section id='adjusting-the-extensible-sdk-to-suit-your-build-hosts-setup'>
-    <title>Adjusting the Extensible SDK to Suit Your Build Host's Setup</title>
+<section id='adjusting-the-extensible-sdk-to-suit-your-build-system-setup'>
+    <title>Adjusting the Extensible SDK to Suit Your Build System Setup</title>
 
     <para>
-        In most cases, the extensible SDK defaults should work with your
-        <ulink url='&YOCTO_DOCS_REF_URL;#hardware-build-system-term'>build host's</ulink>
-        setup.
+        In most cases, the extensible SDK defaults should work.
         However, some cases exist for which you might consider making
         adjustments:
         <itemizedlist>
@@ -95,43 +88,33 @@
                 variable and you do not need or want those classes enabled in
                 the SDK, you can blacklist them by adding them to the
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-SDK_INHERIT_BLACKLIST'><filename>SDK_INHERIT_BLACKLIST</filename></ulink>
-                variable as described in the fourth bullet of the previous
-                section.
-                <note>
-                    The default value of
-                    <filename>SDK_INHERIT_BLACKLIST</filename> is set using
-                    the "?=" operator.
-                    Consequently, you will need to either define the entire
-                    list by using the "=" operator, or you will need to append
-                    a value using either "_append" or the "+=" operator.
-                    You can learn more about these operators in the
-                    "<ulink url='&YOCTO_DOCS_BB_URL;#basic-syntax'>Basic Syntax</ulink>"
-                    section of the BitBake User Manual.
-                </note>.
+                variable.
+                The default value of <filename>SDK_INHERIT_BLACKLIST</filename>
+                is set using the "?=" operator.
+                Consequently, you will need to either set the complete value
+                using "=" or append the value using "_append".
                 </para></listitem>
             <listitem><para>
                 If you have classes or recipes that add additional tasks to
-                the standard build flow (i.e. the tasks execute as the recipe
-                builds as opposed to being called explicitly), then you need
-                to do one of the following:
+                the standard build flow (i.e. that execute as part of building
+                the recipe as opposed to needing to be called explicitly), then
+                you need to do one of the following:
                 <itemizedlist>
                     <listitem><para>
-                        After ensuring the tasks are
-                        <ulink url='&YOCTO_DOCS_OM_URL;#shared-state-cache'>shared state</ulink>
-                        tasks (i.e. the output of the task is saved to and
-                        can be restored from the shared state cache) or
-                        ensuring the tasks are able to be produced quickly from
-                        a task that is a shared state task, add the task name
-                        to the value of
+                        Ensure the tasks are shared state tasks (i.e. their
+                        output is saved to and can be restored from the shared
+                        state cache), or that the tasks are able to be
+                        produced quickly from a task that is a shared state
+                        task and add the task name to the value of
                         <ulink url='&YOCTO_DOCS_REF_URL;#var-SDK_RECRDEP_TASKS'><filename>SDK_RECRDEP_TASKS</filename></ulink>.
                         </para></listitem>
                     <listitem><para>
                         Disable the tasks if they are added by a class and
                         you do not need the functionality the class provides
                         in the extensible SDK.
-                        To disable the tasks, add the class to the
-                        <filename>SDK_INHERIT_BLACKLIST</filename> variable
-                        as described in the previous section.
+                        To disable the tasks, add the class to
+                        <filename>SDK_INHERIT_BLACKLIST</filename> as previously
+                        described.
                         </para></listitem>
                 </itemizedlist>
                 </para></listitem>
@@ -149,7 +132,7 @@
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-SDK_UPDATE_URL'><filename>SDK_UPDATE_URL</filename></ulink>
                 variable.
                 For more information, see the
-                "<link linkend='sdk-providing-updates-to-the-extensible-sdk-after-installation'>Providing Updates to the Extensible SDK After Installation</link>"
+                "<link linkend='sdk-providing-updates-after-installing-the-extensible-sdk'>Providing Updates After Installing the Extensible SDK</link>"
                 section.
                 </para></listitem>
             <listitem><para>
@@ -179,12 +162,11 @@
     </para>
 </section>
 
-<section id='sdk-changing-the-sdk-installer-title'>
-    <title>Changing the Extensible SDK Installer Title</title>
+<section id='sdk-changing-the-appearance-of-the-extensible-sdk'>
+    <title>Changing the Appearance of the Extensible SDK</title>
 
     <para>
-        You can change the displayed title for the SDK installer by setting
-        the
+        You can change the title shown by the SDK installer by setting the
         <ulink url='&YOCTO_DOCS_REF_URL;#var-SDK_TITLE'><filename>SDK_TITLE</filename></ulink>
         variable.
         By default, this title is derived from
@@ -195,37 +177,21 @@
         <ulink url='&YOCTO_DOCS_REF_URL;#var-DISTRO'><filename>DISTRO</filename></ulink>
         variable.
     </para>
-
-    <para>
-        The
-        <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-populate-sdk-*'><filename>populate_sdk_ext</filename></ulink>
-        class defines the default value of the <filename>SDK_TITLE</filename>
-        variable as follows:
-        <literallayout class='monospaced'>
-     SDK_TITLE_task-populate-sdk-ext = "${@d.getVar('DISTRO_NAME') or d.getVar('DISTRO')} Extensible SDK"
-        </literallayout>
-    </para>
 </section>
 
-<section id='sdk-providing-updates-to-the-extensible-sdk-after-installation'>
-    <title>Providing Updates to the Extensible SDK After Installation</title>
+<section id='sdk-providing-updates-after-installing-the-extensible-sdk'>
+    <title>Providing Updates After Installing the Extensible SDK</title>
 
     <para>
         When you make changes to your configuration or to the metadata and
         if you want those changes to be reflected in installed SDKs, you need
-        to perform additional steps.
-        These steps make it possible for anyone using the installed SDKs to
-        update the installed SDKs by using the
+        to perform additional steps to make it possible for those that use
+        the SDK to update their installations with the
         <filename>devtool sdk-update</filename> command:
         <orderedlist>
             <listitem><para>
-                Create a directory that can be shared over HTTP or HTTPS.
-                You can do this by setting up a web server such as an
-                <ulink url='https://en.wikipedia.org/wiki/Apache_HTTP_Server'>Apache HTTP Server</ulink>
-                or
-                <ulink url='https://en.wikipedia.org/wiki/Nginx'>Nginx</ulink>
-                server in the cloud to host the directory.
-                This directory must contain the published SDK.
+                Arrange to be created a directory that can be shared over
+                HTTP or HTTPS.
                 </para></listitem>
             <listitem><para>
                 Set the
@@ -233,10 +199,7 @@
                 variable to point to the corresponding HTTP or HTTPS URL.
                 Setting this variable causes any SDK built to default to that
                 URL and thus, the user does not have to pass the URL to the
-                <filename>devtool sdk-update</filename> command as described
-                in the
-                "<link linkend='sdk-applying-updates-to-an-installed-extensible-sdk'>Applying Updates to an Installed Extensible SDK</link>"
-                section.
+                <filename>devtool sdk-update</filename> command.
                 </para></listitem>
             <listitem><para>
                 Build the extensible SDK normally (i.e., use the
@@ -246,7 +209,7 @@
             <listitem><para>
                 Publish the SDK using the following command:
                 <literallayout class='monospaced'>
-     $ oe-publish-sdk <replaceable>some_path</replaceable>/sdk-installer.sh <replaceable>path_to_shared_http_directory</replaceable>
+     $ oe-publish-sdk <replaceable>some_path</replaceable>/sdk-installer.sh <replaceable>path_to_shared/http_directory</replaceable>
                 </literallayout>
                 You must repeat this step each time you rebuild the SDK
                 with changes that you want to make available through the
@@ -256,11 +219,11 @@
     </para>
 
     <para>
-        Completing the above steps allows users of the existing installed
-        SDKs to simply run <filename>devtool sdk-update</filename> to
-        retrieve and apply the latest updates.
+        Completing the above steps allows users of the existing SDKs to
+        simply run <filename>devtool sdk-update</filename> to retrieve the
+        latest updates.
         See the
-        "<link linkend='sdk-applying-updates-to-an-installed-extensible-sdk'>Applying Updates to an Installed Extensible SDK</link>"
+        "<link linkend='sdk-updating-the-extensible-sdk'>Updating the Extensible SDK</link>"
         section for further information.
     </para>
 </section>
@@ -269,38 +232,27 @@
     <title>Providing Additional Installable Extensible SDK Content</title>
 
     <para>
-        If you want the users of an extensible SDK you build to be
-        able to add items to the SDK without requiring the users to build
-        the items from source, you need to do a number of things:
+        If you want the users of the extensible SDK you are building to be
+        able to add items to the SDK without needing to build the
+        items from source, you need to do a number of things:
         <orderedlist>
             <listitem><para>
                 Ensure the additional items you want the user to be able to
-                install are already built:
-                <itemizedlist>
-                    <listitem><para>
-                        Build the items explicitly.
-                        You could use one or more "meta" recipes that depend
-                        on lists of other recipes.
-                        </para></listitem>
-                    <listitem><para>
-                        Build the "world" target and set
-                        <filename>EXCLUDE_FROM_WORLD_pn-</filename><replaceable>recipename</replaceable>
-                        for the recipes you do not want built.
-                        See the
-                        <ulink url='&YOCTO_DOCS_REF_URL;#var-EXCLUDE_FROM_WORLD'><filename>EXCLUDE_FROM_WORLD</filename></ulink>
-                        variable for additional information.
-                        </para></listitem>
-                </itemizedlist>
+                install are actually built.
+                You can ensure these items are built a number of different
+                ways: 1) Build them explicitly, perhaps using one or more
+                "meta" recipes that depend on lists of other recipes to keep
+                things tidy, or 2) Build the "world" target and set
+                <filename>EXCLUDE_FROM_WORLD_pn-</filename><replaceable>recipename</replaceable>
+                for the recipes you do not want built.
+                See the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-EXCLUDE_FROM_WORLD'><filename>EXCLUDE_FROM_WORLD</filename></ulink>
+                variable for additional information.
                 </para></listitem>
             <listitem><para>
                 Expose the <filename>sstate-cache</filename> directory
                 produced by the build.
-                Typically, you expose this directory by making it available
-                through an
-                <ulink url='https://en.wikipedia.org/wiki/Apache_HTTP_Server'>Apache HTTP Server</ulink>
-                or
-                <ulink url='https://en.wikipedia.org/wiki/Nginx'>Nginx</ulink>
-                server.
+                Typically, you expose this directory over HTTP or HTTPS.
                 </para></listitem>
             <listitem><para>
                 Set the appropriate configuration so that the produced SDK
@@ -333,7 +285,7 @@
                         Alternatively, if you just want to set the
                         <filename>SSTATE_MIRRORS</filename> variable's value
                         for the SDK alone, create a
-                        <filename>conf/sdk-extra.conf</filename> file either in
+                        <filename>conf/sdk-extra.conf</filename> either in
                         your
                         <ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink>
                         or within any layer and put your
@@ -372,24 +324,24 @@
         size, which downloads and installs quickly.
         You need to realize, though, that the minimal installer does not
         install any libraries or tools out of the box.
-        These libraries and tools must be installed either "on the fly" or
-        through actions you perform using <filename>devtool</filename> or
-        explicitly with the <filename>devtool sdk-install</filename> command.
+        These must be installed either "on the fly" or through actions you
+        perform using <filename>devtool</filename> or explicitly with the
+        <filename>devtool sdk-install</filename> command.
     </para>
 
     <para>
-        In most cases, when building a minimal SDK you need to also enable
+        In most cases, when building a minimal SDK you will need to also enable
         bringing in the information on a wider range of packages produced by
         the system.
-        Requiring this wider range of information is particularly true
-        so that <filename>devtool add</filename> is able to effectively map
-        dependencies it discovers in a source tree to the appropriate recipes.
-        Additionally, the information enables the
-        <filename>devtool search</filename> command to return useful results.
+        This is particularly true so that <filename>devtool add</filename>
+        is able to effectively map dependencies it discovers in a source tree
+        to the appropriate recipes.
+        Also so that the <filename>devtool search</filename> command
+        is able to return useful results.
     </para>
 
     <para>
-        To facilitate this wider range of information, you would need to
+        To facilitate this wider range of information, you would additionally
         set the following:
         <literallayout class='monospaced'>
      SDK_INCLUDE_PKGDATA = "1"
@@ -432,8 +384,8 @@
         <ulink url='&YOCTO_DOCS_REF_URL;#var-SDK_INCLUDE_TOOLCHAIN'><filename>SDK_INCLUDE_TOOLCHAIN</filename></ulink>
         variable to "1".
         In particular, it is useful to include the toolchain when you
-        have set <filename>SDK_EXT_TYPE</filename> to "minimal", which by
-        default, excludes the toolchain.
+        have set <filename>SDK_EXT_TYPE</filename> to
+        "minimal", which by default, excludes the toolchain.
         Also, it is helpful if you are building a small SDK for use with
         an IDE, such as <trademark class='trade'>Eclipse</trademark>, or some
         other tool where you do not want to take extra steps to install a

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='application-development-workflow-using-eclipse'>Application Development Workflow Using <trademark class='trade'>Eclipse</trademark></link>"
-        section.
+        "<link linkend='sdk-eclipse-project'>Developing Applications Using <trademark class='trade'>Eclipse</trademark></link>"
+        Chapter.
     </para>
 
     <section id='neon-setting-up-the-eclipse-ide'>
@@ -53,18 +53,13 @@
                         <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 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.
+                        Click the "Download" button and then use the "Eclipse
+                        IDE for C/C++ Developers"
+                        appropriate for your development system.
                         </para></listitem>
                     <listitem><para><emphasis>Unpack the Tarball:</emphasis>
-                        Move to a directory and unpack the tarball.
-                        The following commands unpack the tarball into the
-                        home directory:
+                        Move to a clean directory and unpack the tarball.
+                        Here is an example:
                         <literallayout class='monospaced'>
      $ cd ~
      $ tar -xzvf ~/Downloads/eclipse-cpp-neon-3-linux-gtk-x86_64.tar.gz
@@ -89,22 +84,11 @@
 
             <para>
                 Follow these steps to configure the Neon Eclipse IDE.
-                <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>
+                    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>
                 <orderedlist>
                     <listitem><para>Be sure Eclipse is running and
@@ -180,11 +164,11 @@
                             in the URL field and provide a meaningful name
                             in the "Name" field.
                             </para></listitem>
-                        <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.
+                        <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.
                             </para></listitem>
                         <listitem><para>Check the boxes next to the following:
                             <literallayout class='monospaced'>
@@ -212,14 +196,8 @@
                     To install the Neon Eclipse Yocto Plug-in from the latest
                     source code, follow these steps:
                     <orderedlist>
-                        <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>
+                        <listitem><para>Be sure your development system
+                            has JDK 1.8+
                             </para></listitem>
                         <listitem><para>install X11-related packages:
                             <literallayout class='monospaced'>
@@ -233,19 +211,18 @@
      $ git clone git://git.yoctoproject.org/eclipse-yocto
                             </literallayout>
                             </para></listitem>
-                        <listitem><para>
-                            Use Git to create the correct tag:
+                        <listitem><para>Use Git to checkout the correct
+                            tag:
                             <literallayout class='monospaced'>
      $ cd ~/eclipse-yocto
-     $ git checkout -b neon/&DISTRO_NAME_NO_CAP; remotes/origin/neon/&DISTRO_NAME_NO_CAP;
+     $ git checkout neon/yocto-&DISTRO;
                             </literallayout>
                             This creates a local tag named
-                            <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.
+                            <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.
                             </para></listitem>
                         <listitem><para>Change to the
                             <filename>scripts</filename>
@@ -266,22 +243,20 @@
                             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/&DISTRO_NAME_NO_CAP; master yocto-&DISTRO; 2>&amp;1 | tee build.log
+     $ ECLIPSE_HOME=/home/scottrif/eclipse-yocto/scripts/eclipse ./build.sh -l neon/yocto-&DISTRO; master yocto-&DISTRO; 2>&amp;1 | tee build.log
                             </literallayout>
-                            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.
+                            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.
                             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.
@@ -335,7 +310,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
@@ -349,16 +324,14 @@
             <para>
                 To start, you need to do the following from within the
                 Eclipse IDE:
-                <orderedlist>
-                    <listitem><para>
-                        Choose "Preferences" from the
+                <itemizedlist>
+                    <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>
-                </orderedlist>
+                </itemizedlist>
                 The following sub-sections describe how to configure the
                 the plug-in.
                 <note>
@@ -381,15 +354,15 @@
                     the sysroot location, and select the target
                     architecture.
                     <itemizedlist>
-                        <listitem><para>
-                            <emphasis>Selecting the Toolchain Type:</emphasis>
-                            Choose between "Standalone pre-built toolchain"
+                        <listitem><para><emphasis>Selecting the Toolchain Type:</emphasis>
+                            Choose between
+                            <filename>Standalone pre-built toolchain</filename>
                             and
-                            "Build system derived toolchain" for Cross Compiler
-                            Options.
+                            <filename>Build system derived toolchain</filename>
+                            for Cross Compiler Options.
                                 <itemizedlist>
-                                    <listitem><para>
-                                        <emphasis>Standalone Pre-built Toolchain:</emphasis>
+                                    <listitem><para><emphasis>
+                                        <filename>Standalone Pre-built Toolchain:</filename></emphasis>
                                         Select this type when you are using
                                         a stand-alone cross-toolchain.
                                         For example, suppose you are an
@@ -403,25 +376,24 @@
                                         and installed a pre-built toolchain
                                         for an existing image.
                                         </para></listitem>
-                                   <listitem><para>
-                                        <emphasis>Build System Derived Toolchain:</emphasis>
+                                   <listitem><para><emphasis>
+                                        <filename>Build System Derived Toolchain:</filename></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 "Build system derived
-                                        toolchain", you are using the toolchain
-                                        built and bundled inside the Build
-                                        Directory.
+                                        When you select
+                                        <filename>Build system derived toolchain</filename>,
+                                        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
-                                        "Build system derived toolchain".
+                                        In this situation, you would select the
+                                        <filename>Build system derived toolchain</filename>.
                                         </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.
@@ -430,10 +402,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
-                            "Toolchain Root Location" field is the
+                            <filename>Toolchain Root Location</filename>
+                            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
@@ -442,12 +414,10 @@
                             "<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
@@ -468,18 +438,17 @@
                             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 "Target Architecture" menu
+                            Use the pull-down
+                            <filename>Target Architecture</filename> menu
                             to make your selection.
                             The pull-down menu should have the supported
                             architectures.
@@ -504,17 +473,16 @@
                     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 Build system derived
-                            toolchain, the target kernel you built will be
-                            located in the
+                            <para>If you selected the
+                            <filename>Build system derived toolchain</filename>,
+                            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>
@@ -526,12 +494,10 @@
                             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
@@ -548,16 +514,16 @@
                             The following is an example:
                            <literallayout class='monospaced'>
     serial ‘&lt;-m 256 -full-screen&gt;’
-                            </literallayout>
+                            </literallayout></para>
+                            <para>
                             Regardless of the mode, Sysroot is already
                             defined as part of the Cross-Compiler Options
-                            configuration in the "Sysroot Location:" field.
+                            configuration in the
+                            <filename>Sysroot Location:</filename> 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>
 
@@ -592,37 +558,31 @@
             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 "Yocto Project SDK Autotools Project".
+                <listitem><para>Expand <filename>Yocto Project SDK Autotools Project</filename>.
                     </para></listitem>
-                <listitem><para>
-                    Select "Hello World ANSI C Autotools Projects".
+                <listitem><para>Select <filename>Hello World ANSI C Autotools Projects</filename>.
                     This is an Autotools-based project based on a Yocto
                     template.
                     </para></listitem>
-                <listitem><para>
-                    Put a name in the "Project name:" field.
+                <listitem><para>Put a name in the <filename>Project name:</filename>
+                    field.
                     Do not use hyphens as part of the name
-                    (e.g. "hello").
+                    (e.g. <filename>hello</filename>).
                     </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>
@@ -640,8 +600,7 @@
             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
@@ -654,19 +613,22 @@
                     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
-                    <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.
+                    <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.
                     </para></listitem>
             </orderedlist>
         </para>
@@ -694,7 +656,8 @@
                         Select the project.
                         </para></listitem>
                     <listitem><para>
-                        Select "Folder" from the "File > New" menu.
+                        Select "Folder" from the
+                        <filename>File > New</filename> menu.
                         </para></listitem>
                     <listitem><para>
                         In the "New Folder" Dialog, select "Link to alternate
@@ -819,66 +782,54 @@
                 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
-                    "C/C++Remote Application".
+                <listitem><para>In the left area, expand
+                    <filename>C/C++Remote Application</filename>.
                     </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 "SSH", which means
+                <listitem><para>Select <filename>SSH</filename>, 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 "192.168.7.2".
+                    For QEMU, the default is <filename>192.168.7.2</filename>.
                     However, if a previous QEMU session did not exit
                     cleanly, the IP address increments (e.g.
-                    "192.168.7.3").
+                    <filename>192.168.7.3</filename>).
                     <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 "root", which
+                <listitem><para>Enter <filename>root</filename>, 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
@@ -923,11 +874,9 @@
                 <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,33 +25,32 @@
                 Go to <ulink url='&YOCTO_TOOLCHAIN_DL_URL;'></ulink>
                 </para></listitem>
             <listitem><para>
-                <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>
+                <emphasis>Open the Folder for Your Development System:</emphasis>
+                Open the folder that matches your host development system
                 (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 build host, target hardware, and image type.
+                your development system, target hardware, and image type.
                 </para>
 
                 <para>The installer files (<filename>*.sh</filename>) follow
                 this naming convention:
                 <literallayout class='monospaced'>
-     poky-glibc-<replaceable>host_system</replaceable>-core-image-<replaceable>type</replaceable>-<replaceable>arch</replaceable>-toolchain[-ext]-<replaceable>release</replaceable>.sh
+     poky-eglibc-<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 the image:
-                "sato" or "minimal"
+         <replaceable>type</replaceable> is a string representing either a "sato" or "minimal"
+                image.
 
          <replaceable>arch</replaceable> is a string representing the target architecture:
-                "aarch64", "armv5e", "core2-64", "coretexa8hf-neon", "i586", "mips32r2",
-                "mips64", or "ppc7400"
+                aarch64, armv5e, core2-64, coretexa8hf-neon, i586, mips3242,
+                mips64, or ppc7400.
 
          <replaceable>release</replaceable> is the version of Yocto Project.
 
@@ -66,10 +65,10 @@
                 libraries appropriate for developing against those images.
                 </para>
 
-                <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:
+                <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:
                 <literallayout class='monospaced'>
      poky-glibc-x86_64-core-image-sato-core2-64-toolchain-ext-&DISTRO;.sh
                 </literallayout>
@@ -98,7 +97,7 @@
     <title>Building an SDK Installer</title>
 
     <para>
-        As an alternative to locating and downloading an SDK installer,
+        As an alternative to locating and downloading a SDK installer,
         you can build the SDK installer.
         Follow these steps:
         <orderedlist>
@@ -139,7 +138,8 @@
                 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 Source Directory.
+                and is located in the
+                <ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink>.
                 After the script runs, your current working directory
                 is set to the <filename>build</filename> directory.
                 </para></listitem>
@@ -148,31 +148,17 @@
                 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
-                Build Directory matches the architecture for which you are
-                building.
+                <ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink>
+                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 host), be sure that the
+                machine (i.e. the build machine), 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.
-                <note>
-                    If you are building an SDK installer for the Extensible
-                    SDK, the <filename>SDKMACHINE</filename> value must be
-                    set for the architecture of the machine you are using to
-                    build the installer.
-                    If <filename>SDKMACHINE</filename> is not set appropriately,
-                    the build fails and provides an error message similar to
-                    the following:
-                    <literallayout class='monospaced'>
-     The extensible SDK can currently only be built for the same architecture as the machine being built on - SDK_ARCH is
-     set to i686 (likely via setting SDKMACHINE) which is different from the architecture of the build machine (x86_64).
-     Unable to continue.
-                    </literallayout>
-                </note>
                 </para></listitem>
             <listitem><para>
                 <emphasis>Build the SDK Installer:</emphasis>
@@ -188,7 +174,7 @@
                 <literallayout class='monospaced'>
      $ bitbake <replaceable>image</replaceable> -c populate_sdk_ext
                 </literallayout>
-                These commands produce an SDK installer that contains the
+                These commands result in a SDK installer that contains the
                 sysroot that matches your target root filesystem.</para>
 
                 <para>When the <filename>bitbake</filename> command completes,
@@ -197,18 +183,16 @@
                 <note><title>Notes</title>
                     <itemizedlist>
                         <listitem><para>
-                            By default, the previous BitBake command does not
-                            build static binaries.
+                            By default, this toolchain does not build static
+                            binaries.
                             If you want to use the toolchain to build these
                             types of libraries, you need to be sure your 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 before building the SDK installer.
-                            Doing so ensures that the eventual SDK installation
-                            process installs the appropriate library packages
-                            as part of the SDK.
+                            file to install the appropriate library packages
+                            in the SDK.
                             Following is an example using
                             <filename>libc</filename> static development
                             libraries:
@@ -278,40 +262,32 @@
                 Root Filesystem Image File:</emphasis>
                 You need to find and download the root filesystem image
                 file that is appropriate for your target system.
-                These files are kept in machine-specific folders in the
+                These files are kept in the
                 <ulink url='&YOCTO_DL_URL;/releases/yocto/yocto-&DISTRO;/machines/'>Index of Releases</ulink>
                 in the "machines" directory.</para>
 
-                <para>The machine-specific folders of the "machines" directory
-                contain tarballs (<filename>*.tar.bz2</filename>) for supported
-                machines.
-                These directories also contain flattened root filesystem
+                <para>The "machines" directory contains tarballs
+                (<filename>*.tar.bz2</filename>) for supported machines.
+                The directory also contains flattened root filesystem
                 image files (<filename>*.ext4</filename>), which you can use
                 with QEMU directly.</para>
 
                 <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:
          <replaceable>profile</replaceable> is the filesystem image's profile:
-                   lsb, lsb-dev, lsb-sdk, minimal, minimal-dev, minimal-initramfs,
-                   sato, sato-dev, sato-sdk, sato-sdk-ptest. For information on
-                   these types of image profiles, see the "<ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Images</ulink>" chapter in
-                   the Yocto Project Reference Manual.
+                   lsb, lsb-dev, lsb-sdk, lsb-qt3, minimal, minimal-dev, sato,
+                   sato-dev, sato-sdk, minimal-initramfs, or sdk-ptest. For
+                   information on these types of image profiles, see the
+                   "Images" chapter in the Yocto Project Reference Manual.
 
          <replaceable>arch</replaceable> is a string representing the target architecture:
-                   beaglebone-yocto, beaglebone-yocto-lsb, edgerouter, edgerouter-lsb,
-                   genericx86, genericx86-64, genericx86-64-lsb, genericx86-lsb,
-                   mpc8315e-rdb, mpc8315e-rdb-lsb, and qemu*.
-
-<!-->
-         <replaceable>date_time</replaceable> is a date and time stamp.
--->
+                beaglebone, edgerouter, genericx86, genericx86-64, mpc8315e-rdb,
+                qemuarm, qemuarm64, qemumips, qemumips64, qemuppc, qemux86, or
+                qemux86-64.
 
                 </literallayout>
                 The root filesystems provided by the Yocto Project are based
@@ -319,28 +295,26 @@
                 <filename>core-image-minimal</filename> images.
                 </para>
 
-                <para>For example, if you plan on using a BeagleBone device
-                as your target hardware and your image is a
-                <filename>core-image-sato-sdk</filename>
-                image, you can download the following file:
+                <para>For example, if your target hardware system is a
+                BeagleBone board and your image is a
+                <filename>core-image-minimal</filename> image, you need
+                to download the following root filesystem image file:
                 <literallayout class='monospaced'>
-     core-image-sato-sdk-beaglebone-yocto.tar.bz2
+     core-image-minimal-beaglebone.tar.bz2
                 </literallayout>
                 </para></listitem>
             <listitem><para>
                 <emphasis>Initialize the Cross-Development Environment:</emphasis>
-                You must <filename>source</filename> the cross-development
-                environment setup script to establish necessary environment
-                variables.</para>
+                You must <filename>source</filename>
+                the cross-development environment setup script to establish
+                necessary environment variables.</para>
 
                 <para>This script is located in the top-level directory in
                 which you installed the toolchain (e.g.
                 <filename>poky_sdk</filename>).</para>
 
-                <para>Following is an example based on the toolchain installed
-                in the
-                "<link linkend='sdk-locating-pre-built-sdk-installers'>Locating Pre-Built SDK Installers</link>"
-                section:
+                <para>Following is an example for the Core2 64-bit
+                architecture:
                 <literallayout class='monospaced'>
      $ source ~/poky_sdk/environment-setup-core2-64-poky-linux
                 </literallayout>
@@ -357,10 +331,10 @@
                 This command extracts the root filesystem into the
                 <filename>core2-64-sato</filename> directory:
                 <literallayout class='monospaced'>
-     $ runqemu-extract-sdk ~/Downloads/core-image-sato-sdk-beaglebone-yocto.tar.bz2 ~/beaglebone-sato
+     $ runqemu-extract-sdk ~/Downloads/core-image-sato-core2-64.tar.bz2 ~/core2-64-sato
                 </literallayout>
                 You could now point to the target sysroot at
-                <filename>beablebone-sato</filename>.
+                <filename>core2-64-sato</filename>.
                 </para></listitem>
         </orderedlist>
     </para>
@@ -376,7 +350,7 @@
     </para>
 
     <para>
-        <imagedata fileref="figures/sdk-installed-standard-sdk-directory.png" scale="80" align="center" />
+        <imagedata fileref="figures/sdk-installed-standard-sdk-directory.png" scale="60" align="center" />
     </para>
 
     <para>
@@ -417,7 +391,7 @@
     </para>
 
     <para>
-        <imagedata fileref="figures/sdk-installed-extensible-sdk-directory.png" scale="80" align="center" />
+        <imagedata fileref="figures/sdk-installed-extensible-sdk-directory.png" scale="60" align="center" />
     </para>
 
     <para>
@@ -432,8 +406,8 @@
     <para>
         Of note in the directory structure are an environment setup script
         for the SDK, a configuration file for the target, a version file for
-        the target, and log files for the OpenEmbedded build system
-        preparation script run by the installer and BitBake.
+        the target, and a log file for the OpenEmbedded build system
+        preparation script run by the installer.
     </para>
 
     <para>
@@ -441,9 +415,11 @@
         portions of the file or directory name.
         For example,
         <replaceable>install_dir</replaceable> is the directory where the SDK
-        is installed, which is <filename>poky_sdk</filename> by default, and
+        is installed, which is <filename>poky_sdk</filename> by default.
         <replaceable>target</replaceable> represents the target
-        architecture (e.g. <filename>i586</filename>).
+        architecture (e.g. <filename>i586</filename>) and
+        <replaceable>host</replaceable> represents the development system's
+        architecture (e.g. <filename>x86_64</filename>).
     </para>
 </section>
 

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

@@ -12,34 +12,15 @@
         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='application-development-workflow-using-eclipse'>
-        <title>Application Development Workflow Using <trademark class='trade'>Eclipse</trademark></title>
+    <section id='workflow-using-eclipse'>
+        <title>Workflow Using <trademark class='trade'>Eclipse</trademark></title>
 
         <para>
-            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.
+            The following figure and supporting list summarize the
+            application development general workflow that employs both the
+            SDK Eclipse.
         </para>
 
         <para>
@@ -51,29 +32,22 @@
             <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_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>
+                    "<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.
                     </para></listitem>
                 <listitem><para>
-                    <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>
+                    <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
                     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.
@@ -104,10 +78,6 @@
                             "<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>
@@ -121,10 +91,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
@@ -132,7 +102,6 @@
                     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
@@ -149,13 +118,14 @@
                         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>:
-                    You need to have source files for your application.
+                    At this point, 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>
@@ -289,28 +259,15 @@
                             </para></listitem>
                         <listitem><para>
                             <emphasis>Install the Software:</emphasis>
-                            Click "Install" to begin the installation.
-                            Accept all the certificates and any license
-                            agreements.
-                            Click "Install" again to finish the installation.
+                            Accept the default "cpp-oxygen" directory and
+                            click "Install".
+                            Accept any license agreements and approve any
+                            certificates.
                             </para></listitem>
                         <listitem><para>
                             <emphasis>Launch Oxygen:</emphasis>
-                            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>
+                            Click the "Launch" button and accept the
+                            default "workspace".
                             </para></listitem>
                     </orderedlist>
                 </para>
@@ -321,29 +278,17 @@
 
                 <para>
                     Follow these steps to configure the Oxygen Eclipse IDE.
-                    <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>
+                        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>
                     <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"
@@ -396,7 +341,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>
@@ -425,10 +370,12 @@
                                 name in the "Name" field.
                                 </para></listitem>
                             <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.
+                                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.
                                 </para></listitem>
                             <listitem><para>
                                 Check the boxes next to the following:
@@ -460,13 +407,8 @@
                         latest source code, follow these steps:
                         <orderedlist>
                             <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>
+                                Be sure your development system
+                                has JDK 1.8+
                                 </para></listitem>
                             <listitem><para>
                                 Install X11-related packages:
@@ -486,12 +428,12 @@
                                 Use Git to create the correct tag:
                                 <literallayout class='monospaced'>
      $ cd ~/eclipse-yocto
-     $ git checkout -b oxygen/&DISTRO_NAME_NO_CAP; remotes/origin/oxygen/&DISTRO_NAME_NO_CAP;
+     $ git checkout -b oxygen/yocto-&DISTRO; remotes/origin/oxygen-master
                                 </literallayout>
                                 This creates a local tag named
-                                <filename>oxygen/&DISTRO_NAME_NO_CAP;</filename>
+                                <filename>oxygen/yocto-&DISTRO;</filename>
                                 based on the branch
-                                <filename>origin/oxygen/&DISTRO_NAME_NO_CAP;</filename>.
+                                <filename>origin/oxygen-master</filename>.
                                 You are put into a detached HEAD state,
                                 which is fine since you are only going to
                                 be building and not developing.
@@ -525,11 +467,11 @@
                                 <para>
                                 Following is an example:
                                 <literallayout class='monospaced'>
-     $ 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
+     $ ECLIPSE_HOME=/home/scottrif/eclipse-yocto/scripts/eclipse ./build.sh -l oxygen/yocto-&DISTRO; master yocto-&DISTRO; 2>&amp;1 | tee build.log
                                 </literallayout>
                                 The previous example command adds the tag
                                 you need for
-                                <filename>oxygen/&DISTRO_NAME_NO_CAP;</filename>
+                                <filename>oxygen/yocto-&DISTRO;</filename>
                                 to <filename>HEAD</filename>, then tells
                                 the build script to use the local (-l) Git
                                 checkout for the build.
@@ -596,7 +538,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
@@ -611,7 +553,7 @@
                 <para>
                     To start, you need to do the following from within the
                     Eclipse IDE:
-                    <orderedlist>
+                    <itemizedlist>
                         <listitem><para>
                             Choose "Preferences" from the "Window" menu to
                             display the Preferences Dialog.
@@ -620,7 +562,7 @@
                             Click "Yocto Project SDK" to display
                             the configuration screen.
                             </para></listitem>
-                    </orderedlist>
+                    </itemizedlist>
                     The following sub-sections describe how to configure
                     the plug-in.
                     <note>
@@ -628,7 +570,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>
@@ -645,13 +587,18 @@
                         architecture.
                         <itemizedlist>
                             <listitem><para>
-                                <emphasis>Selecting the Toolchain Type:</emphasis>
-                                Choose between "Standalone pre-built toolchain"
-                                and "Build system derived toolchain" for
-                                Cross Compiler Options.
+                                <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.
                                 <itemizedlist>
                                     <listitem><para>
-                                        <emphasis>Standalone Pre-built Toolchain:</emphasis>
+                                        <emphasis>
+                                        <filename>Standalone Pre-built Toolchain:</filename>
+                                        </emphasis>
                                         Select this type when you are using
                                         a stand-alone cross-toolchain.
                                         For example, suppose you are an
@@ -666,24 +613,29 @@
                                         for an existing image.
                                         </para></listitem>
                                     <listitem><para>
-                                        <emphasis>Build System Derived Toolchain:</emphasis>
+                                        <emphasis>
+                                        <filename>Build System Derived Toolchain:</filename>
+                                        </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 "Build system derived
-                                        toolchain", you are using the toolchain
-                                        built and bundled inside the Build
+                                        When you select
+                                        <filename>Build system derived toolchain</filename>,
+                                        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
-                                        "Build system derived toolchain".
+                                        the
+                                        <filename>Build system derived toolchain</filename>.
                                         </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.
@@ -692,10 +644,11 @@
                                 "<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 "Toolchain Root Location" field is the
+                                the
+                                <filename>Toolchain Root Location</filename>
+                                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
@@ -706,11 +659,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
@@ -732,7 +685,6 @@
                                 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
@@ -740,10 +692,12 @@
                                 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 "Target Architecture"
+                                Use the pull-down
+                                <filename>Target Architecture</filename>
                                 menu to make your selection.
                                 The pull-down menu should have the
                                 supported architectures.
@@ -776,10 +730,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 Build system derived
-                                toolchain, the target kernel you built will be
-                                located in the
+                                <para>If you selected the
+                                <filename>Build system derived toolchain</filename>,
+                                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>
@@ -791,13 +745,11 @@
                                 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.
@@ -816,22 +768,23 @@
                                 The following is an example:
                                <literallayout class='monospaced'>
     serial ‘&lt;-m 256 -full-screen&gt;’
-                                </literallayout>
+                                </literallayout></para>
+                                <para>
                                 Regardless of the mode, Sysroot is already
                                 defined as part of the Cross-Compiler
-                                Options configuration in the "Sysroot
-                                Location:" field.
+                                Options configuration in the
+                                <filename>Sysroot Location:</filename>
+                                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 "Apply and Close" to save your plug-in
+                        Click the "Apply" and "OK" to save your plug-in
                         configurations.
                     </para>
                 </section>
@@ -869,17 +822,19 @@
                         click "Next".
                         </para></listitem>
                     <listitem><para>
-                        Expand "Yocto Project SDK Autotools Project".
+                        Expand
+                        <filename>Yocto Project SDK Autotools Project</filename>.
                         </para></listitem>
                     <listitem><para>
-                        Select "Hello World ANSI C Autotools Projects".
+                        Select <filename>Hello World ANSI C Autotools Projects</filename>.
                         This is an Autotools-based project based on a Yocto
                         template.
                         </para></listitem>
                     <listitem><para>
-                        Put a name in the "Project name:" field.
+                        Put a name in the
+                        <filename>Project name:</filename> field.
                         Do not use hyphens as part of the name
-                        (e.g. "hello").
+                        (e.g. <filename>hello</filename>).
                         </para></listitem>
                     <listitem><para>
                         Click "Next".
@@ -931,15 +886,21 @@
                         </para></listitem>
                     <listitem><para>
                         Make or verify your configurations for the
-                        project and click "Apply and Close".
+                        project and click "OK".
                         </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
-                        <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.
+                        <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.
                         </para></listitem>
@@ -953,8 +914,7 @@
                 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 (i.e.
-                <filename>i586-poky-linux-gcc</filename> in this example).
+                cross-compiler you are using.
                 <note>
                     When building "Yocto Project SDK Autotools" projects,
                     the Eclipse IDE might display error messages for
@@ -970,12 +930,12 @@
                             Select the project.
                             </para></listitem>
                         <listitem><para>
-                            Select "Folder" from the "File -> New" menu.
+                            Select "Folder" from the
+                            <filename>File > New</filename> menu.
                             </para></listitem>
                         <listitem><para>
-                            In the "New Folder" Dialog, click the "Advanced"
-                            button and then activate "Link to
-                            alternate location (linked folder)" button.
+                            In the "New Folder" Dialog, select "Link to
+                            alternate location (linked folder)".
                             </para></listitem>
                         <listitem><para>
                             Click "Browse" to navigate to the include
@@ -983,6 +943,9 @@
                             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>
@@ -1025,8 +988,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 a new
-                            shell in order to get QEMU to launch:
+                            installation, you must do the following in
+                            order to get QEMU to launch:
                             <literallayout class='monospaced'>
      $ sudo apt-get install rpcbind
                             </literallayout>
@@ -1110,7 +1073,7 @@
                         </para></listitem>
                     <listitem><para>
                         In the left area, expand
-                        "C/C++Remote Application".
+                        <filename>C/C++Remote Application</filename>.
                         </para></listitem>
                     <listitem><para>
                         Locate your project and select it to bring
@@ -1129,7 +1092,7 @@
                     <listitem><para>
                         Create a new connection to the QEMU instance
                         by clicking on "new".</para></listitem>
-                    <listitem><para>Select "SSH", which
+                    <listitem><para>Select <filename>SSH</filename>, which
                         means Secure Socket Shell and then click "OK".
                         Optionally, you can select a TCF connection
                         instead.
@@ -1141,10 +1104,11 @@
                     <listitem><para>
                         Put the IP address for the connection in
                         the "Host" field.
-                        For QEMU, the default is "192.168.7.2".
+                        For QEMU, the default is
+                        <filename>192.168.7.2</filename>.
                         However, if a previous QEMU session did not exit
                         cleanly, the IP address increments (e.g.
-                        "192.168.7.3").
+                        <filename>192.168.7.3</filename>).
                         <note>
                             You can find the IP address for the current
                             QEMU session by looking in the xterm that
@@ -1152,7 +1116,7 @@
                         </note>
                         </para></listitem>
                     <listitem><para>
-                        Enter "root", which
+                        Enter <filename>root</filename>, 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
-                                makes an attempt to determine the recipe name.
+                                attempts to figure out 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 recipe is placed
+                                workspace - only the new the recipe is placed
                                 in the workspace.</para>
 
                                 <para>Aside from a recipe folder, the command
@@ -708,25 +708,9 @@
                         your source code modifications.
                         </para></listitem>
                     <listitem><para>
-                        <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>
+                        <emphasis>Build the Recipe</emphasis>:
+                        Once you have updated the source files, you can build
+                        the recipe.
                         </para></listitem>
                     <listitem><para>
                         <emphasis>Deploy the Build Output</emphasis>:
@@ -816,7 +800,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
@@ -835,8 +819,12 @@
             </para>
 
             <para>
-                The following diagram shows the common development flow
-                used with the <filename>devtool upgrade</filename> command:
+                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:
             </para>
 
             <para>
@@ -847,18 +835,19 @@
                 <orderedlist>
                     <listitem><para>
                         <emphasis>Initiate the Upgrade</emphasis>:
-                        The top part of the flow shows the typical scenario by
-                        which you use the <filename>devtool upgrade</filename>
-                        command.
+                        The top part of the flow shows a typical scenario by
+                        which you could use
+                        <filename>devtool upgrade</filename>.
                         The following conditions exist:
                         <itemizedlist>
                             <listitem><para>
-                                The recipe exists in a local layer external
+                                The recipe exists in some layer external
                                 to the <filename>devtool</filename> workspace.
                                 </para></listitem>
                             <listitem><para>
                                 The source files for the new release
-                                exist in the same location pointed to by
+                                exist adjacent to 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
@@ -899,19 +888,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.
+                        files from other developers are located.
                         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>:
-                        Conflicts could exist due to the software being
-                        upgraded to a new version.
+                    <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.
                         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.
-                        For such cases, you need to resolve the conflicts
+                        If this is the case, you need to resolve the conflicts
                         by editing the source and following the normal
                         <filename>git rebase</filename> conflict resolution
                         process.</para>
@@ -921,25 +910,13 @@
                         newer or different version of the software.
                         </para></listitem>
                     <listitem><para>
-                        <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>
+                        <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>.
                         </para></listitem>
                     <listitem><para>
                         <emphasis>Deploy the Build Output</emphasis>:
@@ -1015,8 +992,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 you provide with the command.
+            The <filename>devtool add</filename> command automatically creates a
+            recipe based on the source tree with which you provide it.
             Currently, the command has support for the following:
             <itemizedlist>
                 <listitem><para>
@@ -1062,8 +1039,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 the recipe successfully builds.
-                Once the recipe builds, you could use possible further
+                until you can build the recipe.
+                Once the recipe can be built, you could use possible further
                 iterations to test the recipe on the target device.
             </note>
         </para>
@@ -1078,19 +1055,15 @@
 
             <para>
                 If you do not specify a name and version on the command
-                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.
+                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.
             </para>
 
             <para>
@@ -1114,27 +1087,26 @@
                 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 as part of the
+                recipes in the
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-DEPENDS'><filename>DEPENDS</filename></ulink>
-                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.
+                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.
                 For cases where the dependency is not available, you must use
                 the <filename>devtool add</filename> command to add an
-                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.
+                additional recipe to satisfy the dependency and then come
+                back to the first recipe and add its name to
+                <filename>DEPENDS</filename>.
             </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} += "<replaceable>dependency1 dependency2 ...</replaceable>"
+     RDEPENDS_${PN} += "dependency1 dependency2 ..."
                 </literallayout>
                 <note>
                     The <filename>devtool add</filename> command often cannot
@@ -1145,7 +1117,7 @@
                     script for the software the recipe is building for further
                     details.
                     In some cases, you might find you can substitute the
-                    dependency with an option that disables the associated
+                    dependency for an option to disable the associated
                     functionality passed to the configure script.
                 </note>
             </para>
@@ -1157,24 +1129,20 @@
             <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.
-                If so, the command sets the
+                distributed under a common open-source license and sets the
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-LICENSE'><filename>LICENSE</filename></ulink>
                 value accordingly.
-                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.
+                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.
             </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.
-                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.
+                However, license statements often appear in comments at the top
+                of source files or within documentation.
                 Consequently, you might need to amend the
                 <filename>LIC_FILES_CHKSUM</filename> variable to point to one
                 or more of those comments if present.
@@ -1188,13 +1156,14 @@
 
             <para>
                 If the <filename>devtool add</filename> command cannot
-                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.
+                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.
             </para>
         </section>
 
@@ -1202,8 +1171,8 @@
             <title>Adding Makefile-Only Software</title>
 
             <para>
-                The use of Make by itself is very common in both proprietary
-                and open-source software.
+                The use of <filename>make</filename> 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
@@ -1216,7 +1185,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 arguments (e.g. to point to the associated sysroot
+                require some arguments (e.g. to point to the associated sysroot
                 for the target machine).
             </para>
 
@@ -1231,17 +1200,18 @@
                         <filename>g++</filename>.
                         </para></listitem>
                     <listitem><para>
-                        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.
+                        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.
                         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, a list of environment
-                        variables exists that are being set.
+                        Towards the top of this file you will see a list of
+                        environment variables that are being set.
                         You can take advantage of these variables within the
                         Makefile.
                         </para></listitem>
@@ -1249,7 +1219,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.
-                        For this case, you can either patch the Makefile
+                        In this situation, 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.
@@ -1274,17 +1244,16 @@
                         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 because they
-                        are specific to the build host rather than the target.
+                        contamination into the cross-compilation by virtue of
+                        being 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
-                        situation.
+                        path variables is usually the way to handle this.
                         </para></listitem>
                     <listitem><para>
                         Sometimes a Makefile runs target-specific commands such
                         as <filename>ldconfig</filename>.
-                        For such cases, you might be able to apply patches that
-                        remove these commands from the Makefile.
+                        For such cases, you might be able to simply apply
+                        patches that remove these commands from the Makefile.
                         </para></listitem>
                 </itemizedlist>
             </para>
@@ -1295,11 +1264,9 @@
 
             <para>
                 Often, you need to build additional tools that run on the
-                <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>:
+                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>:
                 <itemizedlist>
                     <listitem><para>
                         Specify the name of the recipe such that it ends
@@ -1321,8 +1288,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>
@@ -1363,9 +1330,11 @@
                             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 support adding
+                            Node.js modules, a
+                            <filename>nodejs</filename> recipe must be part of your
+                            SDK in order to provide Node.js
+                            itself.
                             </para></listitem>
                     </itemizedlist>
                 </note>
@@ -1374,15 +1343,14 @@
             <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 the code as Node.js
-                code, fetches dependencies using <filename>npm</filename>, and
-                sets
+                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
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
                 accordingly.
             </para>
@@ -1393,9 +1361,8 @@
         <title>Working With Recipes</title>
 
         <para>
-            When building a recipe using the
-            <filename>devtool build</filename> command, the typical build
-            progresses as follows:
+            When building a recipe with <filename>devtool build</filename>, the
+            typical build progression is as follows:
             <orderedlist>
                 <listitem><para>
                     Fetch the source
@@ -1407,7 +1374,7 @@
                     Configure the source
                     </para></listitem>
                 <listitem><para>
-                    Compile the source
+                    Compiling the source
                     </para></listitem>
                 <listitem><para>
                     Install the build output
@@ -1418,13 +1385,10 @@
             </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 (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.
+            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.
         </para>
 
         <para>
@@ -1432,13 +1396,12 @@
             recipe does not include complete instructions for building the
             software.
             Instead, common functionality is encapsulated in classes inherited
-            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.
+            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.
         </para>
 
         <para>
@@ -1450,58 +1413,47 @@
             <title>Finding Logs and Work Files</title>
 
             <para>
-                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>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>oe-workdir</filename>:
-                        This link points to the temporary work area for the
-                        recipe.
-                        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>
+                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:
+                <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>.
+                        </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>
         </section>
 
         <section id='sdk-setting-configure-arguments'>
@@ -1547,14 +1499,12 @@
 
             <para>
                 Recipes often need to use files provided by other recipes on
-                the
-                <ulink url='&YOCTO_DOCS_REF_URL;#hardware-build-system-term'>build host</ulink>.
+                the build host.
                 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>
@@ -1567,7 +1517,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 goes into the sysroot.
+                A subset of these files automatically go 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.
@@ -1592,20 +1542,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 into several other packages.
-                This separation exists because not all of those installed files
-                are useful in every image.
+                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.
                 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 containing optional modules or
-                plugins might undergo additional package splitting as well.
+                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.
             </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
@@ -1615,18 +1565,17 @@
                 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 by
+                variable specifies which files to include in each package,
                 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 has
-                the same name as the recipe and
+                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
                 <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
@@ -1648,29 +1597,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> command to restore
-            those files and remove any other files the recipe deployed.
+            <filename>devtool undeploy-target</filename> 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 using the "-a" option thus restoring the target device to its
+            all at once thus restoring the target device back 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> commands do not
+                <filename>devtool undeploy-target</filename> command do not
                 currently interact with any package management system on the
                 target device (e.g. RPM or OPKG).
-                Consequently, you should not intermingle
-                <filename>devtool deploy-target</filename> and package
+                Consequently, you should not intermingle operations
+                <filename>devtool deploy-target</filename> and the package
                 manager operations on the target device.
                 Doing so could result in a conflicting set of files.
             </note>
@@ -1681,14 +1630,16 @@
         <title>Installing Additional Items Into the Extensible SDK</title>
 
         <para>
-            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.
+            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.
             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 libGL.
+            which recipe provides it.
             You can use the following command to find out:
             <literallayout class='monospaced'>
      $ devtool search libGL
@@ -1699,51 +1650,45 @@
             <literallayout class='monospaced'>
      $ devtool sdk-install mesa
             </literallayout>
-            By default, the <filename>devtool sdk-install</filename> command
-            assumes the item is available in pre-built form from your SDK
-            provider.
+            By default, the <filename>devtool sdk-install</filename> 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 the item 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 it using the <filename>devtool add</filename> command.
         </para>
     </section>
 
-    <section id='sdk-applying-updates-to-an-installed-extensible-sdk'>
-        <title>Applying Updates to an Installed Extensible SDK</title>
+    <section id='sdk-updating-the-extensible-sdk'>
+        <title>Updating the Extensible SDK</title>
 
         <para>
-            If you are working with an installed extensible SDK that gets
-            occasionally updated (e.g. a third-party SDK), then you will need
-            to manually "pull down" the updates into the installed SDK.
+            If you are working with an extensible SDK that gets occasionally
+            updated (e.g. typically when that SDK has been provided to you by
+            another party), then you will need to manually pull down those
+            updates to your installed SDK.
         </para>
 
         <para>
-            To update your installed SDK, use <filename>devtool</filename> as
-            follows:
+            To update your installed SDK, run the following:
             <literallayout class='monospaced'>
      $ devtool sdk-update
             </literallayout>
             The previous command assumes your SDK provider has set the default
-            update URL for you through the
-            <ulink url='&YOCTO_DOCS_REF_URL;#var-SDK_UPDATE_URL'><filename>SDK_UPDATE_URL</filename></ulink>
-            variable as described in the
-            "<link linkend='sdk-providing-updates-to-the-extensible-sdk-after-installation'>Providing Updates to the Extensible SDK After Installation</link>"
-            section.
-            If the SDK provider has not set that default URL, you need to
-            specify it yourself in the command as follows:
+            update URL for you.
+            If that URL has not been set, you need to specify it yourself as
+            follows:
             <literallayout class='monospaced'>
      $ devtool sdk-update <replaceable>path_to_update_directory</replaceable>
             </literallayout>
             <note>
-                The URL needs to point specifically to a published SDK and
-                not to an SDK installer that you would download and install.
+                The URL needs to point specifically to a published SDK and not an
+                SDK installer that you would download and install.
             </note>
         </para>
     </section>
@@ -1753,34 +1698,31 @@
 
         <para>
             You might need to produce an SDK that contains your own custom
-            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:
+            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:
             <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 previous steps take the recipes added to the workspace and
-            construct a new SDK installer that contains those recipes and the
+            The above procedure takes the recipes added to the workspace and
+            constructs a new SDK installer containing those recipes and the
             resulting binary artifacts.
             The recipes go into their own separate layer in the constructed
-            derivative SDK, which leaves the workspace clean and ready for
-            users to add their own recipes.
+            derivative SDK, leaving the workspace clean and ready for users
+            to add their own recipes.
         </para>
     </section>
 </chapter>

documentation/sdk-manual/sdk-manual.xml

@@ -57,19 +57,9 @@
                 <revremark>Released with the Yocto Project 2.5 Release.</revremark>
             </revision>
             <revision>
-                <revnumber>2.5.1</revnumber>
-                <date>September 2018</date>
-                <revremark>The initial document released with the Yocto Project 2.5.1 Release.</revremark>
-            </revision>
-            <revision>
-                <revnumber>2.5.2</revnumber>
-                <date>January 2019</date>
-                <revremark>The initial document released with the Yocto Project 2.5.2 Release.</revremark>
-            </revision>
-            <revision>
-                <revnumber>2.5.3</revnumber>
+                <revnumber>2.6</revnumber>
                 <date>&REL_MONTH_YEAR;</date>
-                <revremark>The initial document released with the Yocto Project 2.5.3 Release.</revremark>
+                <revremark>Released with the Yocto Project 2.6 Release.</revremark>
             </revision>
        </revhistory>
 

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
-            <ulink url='&YOCTO_DOCS_REF_URL;#hardware-build-system-term'>Build Host</ulink>
-            by running the <filename>*.sh</filename> installation script.
+            The first thing you need to do is install the SDK on your host
+            development machine 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
-            <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.
+            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.
             The toolchains the Yocto Project provides are based off the
-            <filename>core-image-sato</filename> and
-            <filename>core-image-minimal</filename> images and contain
+            <filename>core-image-sato</filename> image 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, i586, mips32r2, mips64, ppc7400, or cortexa8hf-neon.
+                    aarch64, armv5e, core2-64, coretexah8f-neon, i586, mips32r2, mips64, or ppc7400.
 
          <replaceable>release_version</replaceable> is a string representing the release number of the Yocto Project:
 
@@ -121,36 +121,38 @@
 
         <para>
             The SDK and toolchains are self-contained and by default are
-            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.
+            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>
         </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 64-bit x86 target architecture.
+            a 32-bit x86 target architecture.
             The example assumes the SDK installer is located in
-            <filename>~/Downloads/</filename> and has execution rights.
+            <filename>~/Downloads/</filename>.
             <note>
                 If you do not have write permissions for the directory
                 into which you are installing the SDK, the installer
                 notifies you and exits.
-                For that case, set up the proper permissions in the directory
-                and run the installer again.
+                Be sure you have write permissions in the directory and
+                run the installer again.
             </note>
             <literallayout class='monospaced'>
-     $ ./Downloads/poky-glibc-x86_64-core-image-sato-i586-toolchain-&DISTRO;.sh
+     $ ./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.
@@ -171,11 +173,12 @@
 
         <para>
             Once you have the SDK installed, you must run the SDK environment
-            setup script before you can actually use the SDK.
+            setup script before you can actually use it.
             This setup script resides in the directory you chose when you
-            installed the SDK, which is either the default
-            <filename>/opt/poky/&DISTRO;</filename> directory or the directory
-            you chose during installation.
+            installed the SDK.
+            For information on where this setup script can reside, see the
+            "<link linkend='sdk-appendix-obtain'>Obtaining the SDK</link>"
+            Appendix.
         </para>
 
         <para>
@@ -184,11 +187,9 @@
             Environment setup scripts begin with the string
             "<filename>environment-setup</filename>" and include as part of
             their name the tuned target architecture.
-            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:
+            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:
             <literallayout class='monospaced'>
      $ source /opt/poky/&DISTRO;/environment-setup-i586-poky-linux
             </literallayout>

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

@@ -19,494 +19,263 @@
         <title>Autotools-Based Projects</title>
 
         <para>
-            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>.
+            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.
         </para>
 
-        <para>
-            The following figure presents a simple Autotools workflow.
-            <imagedata fileref="figures/sdk-autotools-flow.png" width="7in" height="8in" align="center" />
-        </para>
+        <section id='creating-and-running-a-project-based-on-gnu-autotools'>
+            <title>Creating and Running a Project Based on GNU Autotools</title>
 
-        <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'>
+            <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'>
      $ mkdir $HOME/helloworld
      $ cd $HOME/helloworld
-                    </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'>
+                        </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'>
      #include &lt;stdio.h&gt;
 
      main()
         {
            printf("Hello World!\n");
         }
-                            </literallayout>
-                            </para></listitem>
-                        <listitem><para>
-                            <emphasis><filename>configure.ac</filename>:</emphasis>
-                            <literallayout class='monospaced'>
+                                </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'>
      AC_INIT(hello,0.1)
      AM_INIT_AUTOMAKE([foreign])
      AC_PROG_CC
-     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'>
+     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'>
      $ source /opt/poky/&DISTRO;/environment-setup-i586-poky-linux
-                    </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'>
+                        </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'>
      $ ./configure ${CONFIGURE_FLAGS}
-                    </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'>
+                        </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>
-                    <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'>
+                        </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, 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>
+                        </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'>
-     $ ./tmp/usr/local/bin/hello
+     $ 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>
-                    As expected, the project displays the "Hello World!"
-                    message.
-                    </para></listitem>
-            </orderedlist>
-        </para>
+                </note>
+            </para>
+        </section>
     </section>
 
     <section id='makefile-based-projects'>
         <title>Makefile-Based Projects</title>
 
         <para>
-            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.
+            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.
         </para>
 
         <para>
-            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:
+            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:
             <itemizedlist>
                 <listitem><para>
                     <emphasis>Case 1 - No Variables 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>:</emphasis>
+                    Because these variables are not specifically set in the
                     <filename>Makefile</filename>, the variables retain their
-                    values based on the environment setup script.
+                    values based on the environment.
                     </para></listitem>
                 <listitem><para>
-                    <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
+                    <emphasis>Case 2 - Variables Set in the
+                    <filename>Makefile</filename>:</emphasis>
+                    Specifically setting 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 Are Set Using the Command Line
-                    that Map to Equivalent Environment Variables from the
-                    SDK Setup Script:</emphasis>
+                    <emphasis>Case 3 - Variables Set when the
+                    <filename>Makefile</filename> is Executed from the
+                    Command Line:</emphasis>
                     Executing the <filename>Makefile</filename> from the
-                    command line results in the environment variables being
-                    overwritten.
-                    In this case, the command-line content is used.
+                    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>.
                     </para></listitem>
             </itemizedlist>
             <note>
-                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>
+                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.
             </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>
 <!--

documentation/toaster-manual/toaster-manual.xml

@@ -67,19 +67,9 @@
                 <revremark>Released with the Yocto Project 2.5 Release.</revremark>
             </revision>
             <revision>
-                <revnumber>2.5.1</revnumber>
-                <date>September 2018</date>
-                <revremark>The initial document released with the Yocto Project 2.5.1 Release.</revremark>
-            </revision>
-            <revision>
-                <revnumber>2.5.2</revnumber>
-                <date>January 2019</date>
-                <revremark>The initial document released with the Yocto Project 2.5.2 Release.</revremark>
-            </revision>
-            <revision>
-                <revnumber>2.5.3</revnumber>
+                <revnumber>2.6</revnumber>
                 <date>&REL_MONTH_YEAR;</date>
-                <revremark>The initial document released with the Yocto Project 2.5.3 Release.</revremark>
+                <revremark>Released with the Yocto Project 2.6 Release.</revremark>
             </revision>
        </revhistory>
 

documentation/tools/mega-manual.sed

@@ -2,39 +2,39 @@
 # This style is for manual folders like "yocto-project-qs" and "poky-ref-manual".
 # This is the old way that did it.  Can't do that now that we have "bitbake-user-manual" strings
 # in the mega-manual.
-# s@"ulink" href="http://www.yoctoproject.org/docs/2.5.2/[a-z]*-[a-z]*-[a-z]*/[a-z]*-[a-z]*-[a-z]*.html#@"link" href="#@g
-s@"ulink" href="http://www.yoctoproject.org/docs/2.5.2/yocto-project-qs/yocto-project-qs.html#@"link" href="#@g
-s@"ulink" href="http://www.yoctoproject.org/docs/2.5.2/poky-ref-manual/poky-ref-manual.html#@"link" href="#@g
+# s@"ulink" href="http://www.yoctoproject.org/docs/2.6/[a-z]*-[a-z]*-[a-z]*/[a-z]*-[a-z]*-[a-z]*.html#@"link" href="#@g
+s@"ulink" href="http://www.yoctoproject.org/docs/2.6/yocto-project-qs/yocto-project-qs.html#@"link" href="#@g
+s@"ulink" href="http://www.yoctoproject.org/docs/2.6/poky-ref-manual/poky-ref-manual.html#@"link" href="#@g
 
 # Processes all other manuals (<word>-<word> style) except for the BitBake User Manual because
 # it is not included in the mega-manual.
 # This style is for manual folders that use two word, which is the standard now (e.g. "ref-manual").
 # This was the one-liner that worked before we introduced the BitBake User Manual, which is
 # not in the mega-manual.
-# s@"ulink" href="http://www.yoctoproject.org/docs/2.5.2/[a-z]*-[a-z]*/[a-z]*-[a-z]*.html#@"link" href="#@g
+# s@"ulink" href="http://www.yoctoproject.org/docs/2.6/[a-z]*-[a-z]*/[a-z]*-[a-z]*.html#@"link" href="#@g
 
-s@"ulink" href="http://www.yoctoproject.org/docs/2.5.2/sdk-manual/sdk-manual.html#@"link" href="#@g
-s@"ulink" href="http://www.yoctoproject.org/docs/2.5.2/bsp-guide/bsp-guide.html#@"link" href="#@g
-s@"ulink" href="http://www.yoctoproject.org/docs/2.5.2/dev-manual/dev-manual.html#@"link" href="#@g
-s@"ulink" href="http://www.yoctoproject.org/docs/2.5.2/overview-manual/overview-manual.html#@"link" href="#@g
-s@"ulink" href="http://www.yoctoproject.org/docs/2.5.2/brief-yoctoprojectqs/brief-yoctoprojectqs.html#@"link" href="#@g
-s@"ulink" href="http://www.yoctoproject.org/docs/2.5.2/kernel-dev/kernel-dev.html#@"link" href="#@g
-s@"ulink" href="http://www.yoctoproject.org/docs/2.5.2/profile-manual/profile-manual.html#@"link" href="#@g
-s@"ulink" href="http://www.yoctoproject.org/docs/2.5.2/ref-manual/ref-manual.html#@"link" href="#@g
-s@"ulink" href="http://www.yoctoproject.org/docs/2.5.2/toaster-manual/toaster-manual.html#@"link" href="#@g
+s@"ulink" href="http://www.yoctoproject.org/docs/2.6/sdk-manual/sdk-manual.html#@"link" href="#@g
+s@"ulink" href="http://www.yoctoproject.org/docs/2.6/bsp-guide/bsp-guide.html#@"link" href="#@g
+s@"ulink" href="http://www.yoctoproject.org/docs/2.6/dev-manual/dev-manual.html#@"link" href="#@g
+s@"ulink" href="http://www.yoctoproject.org/docs/2.6/overview-manual/overview-manual.html#@"link" href="#@g
+s@"ulink" href="http://www.yoctoproject.org/docs/2.6/brief-yoctoprojectqs/brief-yoctoprojectqs.html#@"link" href="#@g
+s@"ulink" href="http://www.yoctoproject.org/docs/2.6/kernel-dev/kernel-dev.html#@"link" href="#@g
+s@"ulink" href="http://www.yoctoproject.org/docs/2.6/profile-manual/profile-manual.html#@"link" href="#@g
+s@"ulink" href="http://www.yoctoproject.org/docs/2.6/ref-manual/ref-manual.html#@"link" href="#@g
+s@"ulink" href="http://www.yoctoproject.org/docs/2.6/toaster-manual/toaster-manual.html#@"link" href="#@g
 
 # Process cases where just an external manual is referenced without an id anchor
-s@<a class="ulink" href="http://www.yoctoproject.org/docs/2.5.2/brief-yoctoprojectqs/brief-yoctoprojectqs.html" target="_top">Yocto Project Quick Build</a>@Yocto Project Quick Build@g
-s@<a class="ulink" href="http://www.yoctoproject.org/docs/2.5.2/yocto-project-qs/yocto-project-qs.html" target="_top">Yocto Project Quick Start</a>@Yocto Project Quick Start@g
-s@<a class="ulink" href="http://www.yoctoproject.org/docs/2.5.2/dev-manual/dev-manual.html" target="_top">Yocto Project Development Tasks Manual</a>@Yocto Project Development Tasks Manual@g
-s@<a class="ulink" href="http://www.yoctoproject.org/docs/2.5.2/overview-manual/overview-manual.html" target="_top">Yocto Project Overview and Concepts Manual</a>@Yocto project Overview and Concepts Manual@g
-s@<a class="ulink" href="http://www.yoctoproject.org/docs/2.5.2/sdk-manual/sdk-manual.html" target="_top">Yocto Project Application Development and the Extensible Software Development Kit (eSDK)</a>@Yocto Project Application Development and the Extensible Software Development Kit (eSDK)@g
-s@<a class="ulink" href="http://www.yoctoproject.org/docs/2.5.2/bsp-guide/bsp-guide.html" target="_top">Yocto Project Board Support Package (BSP) Developer's Guide</a>@Yocto Project Board Support Package (BSP) Developer's Guide@g
-s@<a class="ulink" href="http://www.yoctoproject.org/docs/2.5.2/profile-manual/profile-manual.html" target="_top">Yocto Project Profiling and Tracing Manual</a>@Yocto Project Profiling and Tracing Manual@g
-s@<a class="ulink" href="http://www.yoctoproject.org/docs/2.5.2/kernel-dev/kernel-dev.html" target="_top">Yocto Project Linux Kernel Development Manual</a>@Yocto Project Linux Kernel Development Manual@g
-s@<a class="ulink" href="http://www.yoctoproject.org/docs/2.5.2/ref-manual/ref-manual.html" target="_top">Yocto Project Reference Manual</a>@Yocto Project Reference Manual@g
-s@<a class="ulink" href="http://www.yoctoproject.org/docs/2.5.2/toaster-manual/toaster-manual.html" target="_top">Toaster User Manual</a>@Toaster User Manual@g
+s@<a class="ulink" href="http://www.yoctoproject.org/docs/2.6/brief-yoctoprojectqs/brief-yoctoprojectqs.html" target="_top">Yocto Project Quick Build</a>@Yocto Project Quick Build@g
+s@<a class="ulink" href="http://www.yoctoproject.org/docs/2.6/yocto-project-qs/yocto-project-qs.html" target="_top">Yocto Project Quick Start</a>@Yocto Project Quick Start@g
+s@<a class="ulink" href="http://www.yoctoproject.org/docs/2.6/dev-manual/dev-manual.html" target="_top">Yocto Project Development Tasks Manual</a>@Yocto Project Development Tasks Manual@g
+s@<a class="ulink" href="http://www.yoctoproject.org/docs/2.6/overview-manual/overview-manual.html" target="_top">Yocto Project Overview and Concepts Manual</a>@Yocto project Overview and Concepts Manual@g
+s@<a class="ulink" href="http://www.yoctoproject.org/docs/2.6/sdk-manual/sdk-manual.html" target="_top">Yocto Project Application Development and the Extensible Software Development Kit (eSDK)</a>@Yocto Project Application Development and the Extensible Software Development Kit (eSDK)@g
+s@<a class="ulink" href="http://www.yoctoproject.org/docs/2.6/bsp-guide/bsp-guide.html" target="_top">Yocto Project Board Support Package (BSP) Developer's Guide</a>@Yocto Project Board Support Package (BSP) Developer's Guide@g
+s@<a class="ulink" href="http://www.yoctoproject.org/docs/2.6/profile-manual/profile-manual.html" target="_top">Yocto Project Profiling and Tracing Manual</a>@Yocto Project Profiling and Tracing Manual@g
+s@<a class="ulink" href="http://www.yoctoproject.org/docs/2.6/kernel-dev/kernel-dev.html" target="_top">Yocto Project Linux Kernel Development Manual</a>@Yocto Project Linux Kernel Development Manual@g
+s@<a class="ulink" href="http://www.yoctoproject.org/docs/2.6/ref-manual/ref-manual.html" target="_top">Yocto Project Reference Manual</a>@Yocto Project Reference Manual@g
+s@<a class="ulink" href="http://www.yoctoproject.org/docs/2.6/toaster-manual/toaster-manual.html" target="_top">Toaster User Manual</a>@Toaster User Manual@g
 
 # Process a single, rouge occurrence of a linked reference to the Mega-Manual.
-s@<a class="ulink" href="http://www.yoctoproject.org/docs/2.5.2/mega-manual/mega-manual.html" target="_top">Yocto Project Mega-Manual</a>@Yocto Project Mega-Manual@g
+s@<a class="ulink" href="http://www.yoctoproject.org/docs/2.6/mega-manual/mega-manual.html" target="_top">Yocto Project Mega-Manual</a>@Yocto Project Mega-Manual@g
 

meta-poky/conf/distro/poky.conf

@@ -1,7 +1,7 @@
 DISTRO = "poky"
 DISTRO_NAME = "Poky (Yocto Project Reference Distro)"
-DISTRO_VERSION = "2.5.3"
-DISTRO_CODENAME = "sumo"
+DISTRO_VERSION = "2.5+snapshot-${DATE}"
+DISTRO_CODENAME = "master"
 SDK_VENDOR = "-pokysdk"
 SDK_VERSION := "${@'${DISTRO_VERSION}'.replace('snapshot-${DATE}','snapshot')}"
 
@@ -68,12 +68,14 @@ SANITY_TESTED_DISTROS ?= " \
             poky-2.5 \n \
             ubuntu-15.04 \n \
             ubuntu-16.04 \n \
-            ubuntu-18.04 \n \
-            fedora-28 \n \
+            ubuntu-16.10 \n \
+            ubuntu-17.04 \n \
+            fedora-26 \n \
             centos-7 \n \
             debian-8 \n \
             debian-9 \n \
-            opensuse-42.3 \n \
+            opensuse-42.1 \n \
+            opensuse-42.2 \n \
             "
 #
 # OELAYOUT_ABI allows us to notify users when the format of TMPDIR changes in

meta-poky/conf/local.conf.sample

@@ -234,12 +234,12 @@ BB_DISKMON_DIRS ??= "\
 # Qemu configuration
 #
 # By default qemu will build with a builtin VNC server where graphical output can be
-# seen. The two lines below enable the SDL backend too. By default libsdl-native will
+# seen. The two lines below enable the SDL backend too. By default libsdl2-native will
 # be built, if you want to use your host's libSDL instead of the minimal libsdl built
-# by libsdl-native then uncomment the ASSUME_PROVIDED line below.
+# by libsdl2-native then uncomment the ASSUME_PROVIDED line below.
 PACKAGECONFIG_append_pn-qemu-native = " sdl"
 PACKAGECONFIG_append_pn-nativesdk-qemu = " sdl"
-#ASSUME_PROVIDED += "libsdl-native"
+#ASSUME_PROVIDED += "libsdl2-native"
 
 # CONF_VERSION is increased each time build/conf/ changes incompatibly and is used to
 # track the version of this file when it was generated. This can safely be ignored if

meta-poky/conf/local.conf.sample.extended

@@ -32,7 +32,7 @@
 #DISTRO_FEATURES_LIBC = "ipv6 libc-backtrace libc-big-macros libc-bsd libc-cxx-tests libc-catgets libc-charsets libc-crypt \
 #               libc-crypt-ufc libc-db-aliases libc-envz libc-fcvt libc-fmtmsg libc-fstab libc-ftraverse \
 #               libc-getlogin libc-idn libc-inet libc-inet-anl libc-libm libc-locales libc-locale-code \
-#               libc-memusage libc-nis libc-nsswitch libc-rcmd libc-rtld-debug libc-spawn libc-streams libc-sunrpc \
+#               libc-memusage libc-nsswitch libc-rcmd libc-rtld-debug libc-spawn libc-streams \
 #               libc-utmp libc-utmpx libc-wordexp libc-posix-clang-wchar libc-posix-regexp libc-posix-regexp-glibc \
 #               libc-posix-wchar-io"
 

meta-selftest/recipes-test/delay/delay.bb

@@ -1,12 +0,0 @@
-SUMMARY = "Recipe with a fixed delay task"
-DESCRIPTION = "Contains a delay task to be used to for testing."
-LICENSE = "MIT"
-
-INHIBIT_DEFAULT_DEPS = "1"
-EXCLUDE_FROM_WORLD = "1"
-
-do_delay() {
-	sleep 5
-}
-do_delay[nostamp] = "1"
-addtask delay

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 clean systemd-boot')
+        bitbake('-c cleansstate systemd-boot')
         runCmd('rm -f %s' % systemdbootfile)
 
         self._common_build()

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

@@ -8,8 +8,8 @@ KMACHINE_genericx86 ?= "common-pc"
 KMACHINE_genericx86-64 ?= "common-pc-64"
 KMACHINE_beaglebone-yocto ?= "beaglebone"
 
-SRCREV_machine_genericx86    ?= "084af9624d268ddf4fd65b2f9e8e50ca2f22e62b"
-SRCREV_machine_genericx86-64 ?= "084af9624d268ddf4fd65b2f9e8e50ca2f22e62b"
+SRCREV_machine_genericx86    ?= "2bf00ed1aee9c26b48c26b10c731c2f8970d50c2"
+SRCREV_machine_genericx86-64 ?= "2bf00ed1aee9c26b48c26b10c731c2f8970d50c2"
 SRCREV_machine_edgerouter ?= "65d1c849534179bbfa494f77947f8be615e9871a"
 SRCREV_machine_beaglebone-yocto ?= "d62ddfa26a59c83f6128790b7aa2baadc04d2960"
 SRCREV_machine_mpc8315e-rdb ?= "80a106ecf737b69864e07b955eccb62f809cf120"
@@ -20,8 +20,8 @@ COMPATIBLE_MACHINE_edgerouter = "edgerouter"
 COMPATIBLE_MACHINE_beaglebone-yocto = "beaglebone-yocto"
 COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb"
 
-LINUX_VERSION_genericx86 = "4.14.67"
-LINUX_VERSION_genericx86-64 = "4.14.67"
+LINUX_VERSION_genericx86 = "4.14.48"
+LINUX_VERSION_genericx86-64 = "4.14.48"
 LINUX_VERSION_edgerouter = "4.14.48"
 LINUX_VERSION_beaglebone-yocto = "4.14.48"
 LINUX_VERSION_mpc8315e-rdb = "4.14.48"

meta/classes/allarch.bbclass

@@ -45,6 +45,7 @@ python () {
         # These multilib values shouldn't change allarch packages so exclude them
         d.appendVarFlag("emit_pkgdata", "vardepsexclude", " MULTILIB_VARIANTS")
         d.appendVarFlag("write_specfile", "vardepsexclude", " MULTILIBS")
+        d.appendVarFlag("do_package", "vardepsexclude", " package_do_shlibs")
     elif bb.data.inherits_class('packagegroup', d) and not bb.data.inherits_class('nativesdk', d):
         bb.error("Please ensure recipe %s sets PACKAGE_ARCH before inherit packagegroup" % d.getVar("FILE"))
 }

meta/classes/archiver.bbclass

@@ -40,11 +40,8 @@ ARCHIVER_MODE[recipe] ?= "0"
 DEPLOY_DIR_SRC ?= "${DEPLOY_DIR}/sources"
 ARCHIVER_TOPDIR ?= "${WORKDIR}/deploy-sources"
 ARCHIVER_OUTDIR = "${ARCHIVER_TOPDIR}/${TARGET_SYS}/${PF}/"
-ARCHIVER_RPMTOPDIR ?= "${WORKDIR}/deploy-sources-rpm"
-ARCHIVER_RPMOUTDIR = "${ARCHIVER_RPMTOPDIR}/${TARGET_SYS}/${PF}/"
 ARCHIVER_WORKDIR = "${WORKDIR}/archiver-work/"
 
-
 do_dumpdata[dirs] = "${ARCHIVER_OUTDIR}"
 do_ar_recipe[dirs] = "${ARCHIVER_OUTDIR}"
 do_ar_original[dirs] = "${ARCHIVER_OUTDIR} ${ARCHIVER_WORKDIR}"
@@ -120,9 +117,6 @@ python () {
     if d.getVarFlag('ARCHIVER_MODE', 'srpm') == "1" and d.getVar('PACKAGES'):
         if "package_rpm" in d.getVar('PACKAGE_CLASSES'):
             d.appendVarFlag('do_deploy_archives', 'depends', ' %s:do_package_write_rpm' % pn)
-            d.appendVarFlag('do_package_write_rpm', 'dirs', ' ${ARCHIVER_RPMTOPDIR}')
-            d.appendVarFlag('do_package_write_rpm', 'sstate-inputdirs', ' ${ARCHIVER_RPMTOPDIR}')
-            d.appendVarFlag('do_package_write_rpm', 'sstate-outputdirs', ' ${DEPLOY_DIR_SRC}')
             if ar_dumpdata == "1":
                 d.appendVarFlag('do_package_write_rpm', 'depends', ' %s:do_dumpdata' % pn)
             if ar_recipe == "1":
@@ -273,14 +267,6 @@ python do_ar_configured() {
         create_tarball(d, srcdir, 'configured', ar_outdir)
 }
 
-def exclude_useless_paths(tarinfo):
-    if tarinfo.isdir():
-        if tarinfo.name.endswith('/temp') or tarinfo.name.endswith('/patches') or tarinfo.name.endswith('/.pc'):
-            return None
-        elif tarinfo.name == 'temp' or tarinfo.name == 'patches' or tarinfo.name == '.pc':
-            return None
-    return tarinfo
-
 def create_tarball(d, srcdir, suffix, ar_outdir):
     """
     create the tarball from srcdir
@@ -305,7 +291,7 @@ def create_tarball(d, srcdir, suffix, ar_outdir):
 
     bb.note('Creating %s' % tarname)
     tar = tarfile.open(tarname, 'w:gz')
-    tar.add(srcdir, arcname=os.path.basename(srcdir), filter=exclude_useless_paths)
+    tar.add(srcdir, arcname=os.path.basename(srcdir))
     tar.close()
 
 # creating .diff.gz between source.orig and source

meta/classes/base.bbclass

@@ -100,8 +100,8 @@ def get_lic_checksum_file_list(d):
         # We only care about items that are absolute paths since
         # any others should be covered by SRC_URI.
         try:
-            (method, host, path, user, pswd, parm) = bb.fetch.decodeurl(url)
-            if method != "file" or not path:
+            path = bb.fetch.decodeurl(url)[2]
+            if not path:
                 raise bb.fetch.MalformedUrl(url)
 
             if path[0] == '/':
@@ -152,7 +152,7 @@ python base_do_fetch() {
 addtask unpack after do_fetch
 do_unpack[dirs] = "${WORKDIR}"
 
-do_unpack[cleandirs] = "${@d.getVar('S') if d.getVar('S') != d.getVar('WORKDIR') else os.path.join('${S}', 'patches')}"
+do_unpack[cleandirs] = "${@d.getVar('S') if os.path.normpath(d.getVar('S')) != os.path.normpath(d.getVar('WORKDIR')) else os.path.join('${S}', 'patches')}"
 
 python base_do_unpack() {
     src_uri = (d.getVar('SRC_URI') or "").split()
@@ -303,9 +303,7 @@ base_do_configure() {
 			if [ "${CLEANBROKEN}" != "1" -a \( -e Makefile -o -e makefile -o -e GNUmakefile \) ]; then
 				oe_runmake clean
 			fi
-			# -ignore_readdir_race does not work correctly with -delete;
-			# use xargs to avoid spurious build failures
-			find ${B} -ignore_readdir_race -name \*.la -type f -print0 | xargs -0 rm -f
+			find ${B} -ignore_readdir_race -name \*.la -delete
 		fi
 	fi
 	if [ -n "${CONFIGURESTAMPFILE}" ]; then
@@ -522,19 +520,18 @@ python () {
             incompatwl = []
             for lic in bad_licenses:
                 spdx_license = return_spdx(d, lic)
-                for w in ["LGPLv2_WHITELIST_", "WHITELIST_"]:
-                    whitelist.extend((d.getVar(w + lic) or "").split())
-                    if spdx_license:
-                        whitelist.extend((d.getVar(w + spdx_license) or "").split())
-                    '''
-                    We need to track what we are whitelisting and why. If pn is
-                    incompatible we need to be able to note that the image that
-                    is created may infact contain incompatible licenses despite
-                    INCOMPATIBLE_LICENSE being set.
-                    '''
-                    incompatwl.extend((d.getVar(w + lic) or "").split())
-                    if spdx_license:
-                        incompatwl.extend((d.getVar(w + spdx_license) or "").split())
+                whitelist.extend((d.getVar("WHITELIST_" + lic) or "").split())
+                if spdx_license:
+                    whitelist.extend((d.getVar("WHITELIST_" + spdx_license) or "").split())
+                '''
+                We need to track what we are whitelisting and why. If pn is
+                incompatible we need to be able to note that the image that
+                is created may infact contain incompatible licenses despite
+                INCOMPATIBLE_LICENSE being set.
+                '''
+                incompatwl.extend((d.getVar("WHITELIST_" + lic) or "").split())
+                if spdx_license:
+                    incompatwl.extend((d.getVar("WHITELIST_" + spdx_license) or "").split())
 
             if not pn in whitelist:
                 pkgs = d.getVar('PACKAGES').split()
@@ -624,7 +621,7 @@ python () {
         elif path.endswith('.zip') or path.endswith('.jar'):
             d.appendVarFlag('do_unpack', 'depends', ' unzip-native:do_populate_sysroot')
 
-        # file is needed by rpm2cpio.sh
+        # Some rpm files may be compressed internally using xz (for example, rpms from Fedora)
         elif path.endswith('.rpm'):
             d.appendVarFlag('do_unpack', 'depends', ' xz-native:do_populate_sysroot')
 

meta/classes/clutter.bbclass

@@ -14,7 +14,7 @@ REALNAME = "${@get_real_name("${BPN}")}"
 
 CLUTTER_SRC_FTP = "${GNOME_MIRROR}/${REALNAME}/${VERMINOR}/${REALNAME}-${PV}.tar.xz;name=archive"
 
-CLUTTER_SRC_GIT = "git://gitlab.gnome.org/GNOME/${REALNAME};protocol=https"
+CLUTTER_SRC_GIT = "git://git.gnome.org/${REALNAME}"
 
 SRC_URI = "${CLUTTER_SRC_FTP}"
 S = "${WORKDIR}/${REALNAME}-${PV}"

meta/classes/cross.bbclass

@@ -37,7 +37,6 @@ CPPFLAGS = "${BUILD_CPPFLAGS}"
 CFLAGS = "${BUILD_CFLAGS}"
 CXXFLAGS = "${BUILD_CFLAGS}"
 LDFLAGS = "${BUILD_LDFLAGS}"
-LDFLAGS_build-darwin = "-L${STAGING_LIBDIR_NATIVE}"
 
 TOOLCHAIN_OPTIONS = ""
 

meta/classes/crosssdk.bbclass

@@ -21,10 +21,10 @@ TARGET_PREFIX = "${SDK_PREFIX}"
 TARGET_CC_ARCH = "${SDK_CC_ARCH}"
 TARGET_LD_ARCH = "${SDK_LD_ARCH}"
 TARGET_AS_ARCH = "${SDK_AS_ARCH}"
-TARGET_CPPFLAGS = ""
-TARGET_CFLAGS = ""
-TARGET_CXXFLAGS = ""
-TARGET_LDFLAGS = ""
+TARGET_CPPFLAGS = "${BUILD_CPPFLAGS}"
+TARGET_CFLAGS = "${BUILD_CFLAGS}"
+TARGET_CXXFLAGS = "${BUILD_CXXFLAGS}"
+TARGET_LDFLAGS = "${BUILD_LDFLAGS}"
 TARGET_FPU = ""
 
 

meta/classes/cve-check.bbclass

@@ -179,7 +179,7 @@ def check_cves(d, patched_cves):
     cve_db_dir = d.getVar("CVE_CHECK_DB_DIR")
     cve_whitelist = ast.literal_eval(d.getVar("CVE_CHECK_CVE_WHITELIST"))
     cve_cmd = "cve-check-tool"
-    cmd = [cve_cmd, "--no-html", "--skip-update", "--csv", "--not-affected", "-t", "faux", "-d", cve_db_dir]
+    cmd = [cve_cmd, "--no-html", "--csv", "--not-affected", "-t", "faux", "-d", cve_db_dir]
 
     # If the recipe has been whitlisted we return empty lists
     if d.getVar("PN") in d.getVar("CVE_CHECK_PN_WHITELIST").split():
@@ -190,8 +190,7 @@ def check_cves(d, patched_cves):
         # Write the faux CSV file to be used with cve-check-tool
         fd, faux = tempfile.mkstemp(prefix="cve-faux-")
         with os.fdopen(fd, "w") as f:
-            for pn in bpn.split():
-                f.write("%s,%s,%s,\n" % (pn, pv, cves))
+            f.write("%s,%s,%s," % (bpn, pv, cves))
         cmd.append(faux)
 
         output = subprocess.check_output(cmd).decode("utf-8")

meta/classes/externalsrc.bbclass

@@ -41,8 +41,8 @@ python () {
     # re-parsed so that the file-checksums function for do_compile is run every
     # time.
     bpn = d.getVar('BPN')
-    classextend = (d.getVar('BBCLASSEXTEND') or '').split()
-    if bpn == d.getVar('PN') or not classextend:
+    if bpn == d.getVar('PN'):
+        classextend = (d.getVar('BBCLASSEXTEND') or '').split()
         if (externalsrc or
                 ('native' in classextend and
                  d.getVar('EXTERNALSRC_pn-%s-native' % bpn)) or
@@ -77,6 +77,9 @@ python () {
             # Dummy value because the default function can't be called with blank SRC_URI
             d.setVar('SRCPV', '999')
 
+        if d.getVar('CONFIGUREOPT_DEPTRACK') == '--disable-dependency-tracking':
+            d.setVar('CONFIGUREOPT_DEPTRACK', '')
+
         tasks = filter(lambda k: d.getVarFlag(k, "task"), d.keys())
 
         for task in tasks:

meta/classes/gio-module-cache.bbclass

@@ -2,7 +2,6 @@ PACKAGE_WRITE_DEPS += "qemu-native"
 inherit qemu
 
 GIO_MODULE_PACKAGES ??= "${PN}"
-GIO_MODULE_PACKAGES_class-nativesdk = ""
 
 gio_module_cache_common() {
 if [ "x$D" != "x" ]; then

meta/classes/image-buildinfo.bbclass

@@ -64,8 +64,6 @@ def buildinfo_target(d):
 
 # Write build information to target filesystem
 python buildinfo () {
-    if not d.getVar('IMAGE_BUILDINFO_FILE'):
-        return
     with open(d.expand('${IMAGE_ROOTFS}${IMAGE_BUILDINFO_FILE}'), 'w') as build:
         build.writelines((
             '''-----------------------

meta/classes/image_types.bbclass

@@ -239,7 +239,6 @@ EXTRA_IMAGECMD_ext4 ?= "-i 4096"
 EXTRA_IMAGECMD_btrfs ?= "-n 4096"
 EXTRA_IMAGECMD_f2fs ?= ""
 
-do_image_cpio[depends] += "cpio-native:do_populate_sysroot"
 do_image_jffs2[depends] += "mtd-utils-native:do_populate_sysroot"
 do_image_cramfs[depends] += "util-linux-native:do_populate_sysroot"
 do_image_ext2[depends] += "e2fsprogs-native:do_populate_sysroot"

meta/classes/insane.bbclass

@@ -534,9 +534,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 = bytes(d.getVar('TMPDIR'), encoding="utf-8")
+    tmpdir = d.getVar('TMPDIR')
     with open(path, 'rb') as f:
-        file_content = f.read()
+        file_content = f.read().decode('utf-8', errors='ignore')
         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))
 

meta/classes/kernel.bbclass

@@ -62,31 +62,36 @@ python __anonymous () {
     type = d.getVar('KERNEL_IMAGETYPE') or ""
     alttype = d.getVar('KERNEL_ALT_IMAGETYPE') or ""
     types = d.getVar('KERNEL_IMAGETYPES') or ""
-    kname = d.getVar('KERNEL_PACKAGE_NAME') or "kernel"
     if type not in types.split():
         types = (type + ' ' + types).strip()
     if alttype not in types.split():
         types = (alttype + ' ' + types).strip()
     d.setVar('KERNEL_IMAGETYPES', types)
 
-    # some commonly used kernel images aren't generated by the kernel build system, such as vmlinux.gz
-    # typeformake lists only valid kernel make targets, and post processing can be done after the kernel
-    # is built (such as using gzip to compress vmlinux)
-    typeformake = types.replace('vmlinux.gz', 'vmlinux')
-    d.setVar('KERNEL_IMAGETYPE_FOR_MAKE', typeformake)
+    # KERNEL_IMAGETYPES may contain a mixture of image types supported directly
+    # by the kernel build system and types which are created by post-processing
+    # the output of the kernel build system (e.g. compressing vmlinux ->
+    # vmlinux.gz in kernel_do_compile()).
+    # KERNEL_IMAGETYPE_FOR_MAKE should contain only image types supported
+    # directly by the kernel build system.
+    if not d.getVar('KERNEL_IMAGETYPE_FOR_MAKE'):
+        typeformake = set()
+        for type in types.split():
+            if type == 'vmlinux.gz':
+                type = 'vmlinux'
+            typeformake.add(type)
+
+        d.setVar('KERNEL_IMAGETYPE_FOR_MAKE', ' '.join(sorted(typeformake)))
+
+    kname = d.getVar('KERNEL_PACKAGE_NAME') or "kernel"
+    imagedest = d.getVar('KERNEL_IMAGEDEST')
 
     for type in types.split():
         typelower = type.lower()
-        imagedest = d.getVar('KERNEL_IMAGEDEST')
-
         d.appendVar('PACKAGES', ' %s-image-%s' % (kname, typelower))
-
         d.setVar('FILES_' + kname + '-image-' + typelower, '/' + imagedest + '/' + type + '-${KERNEL_VERSION_NAME}' + ' /' + imagedest + '/' + type)
-
         d.appendVar('RDEPENDS_%s-image' % kname, ' %s-image-%s' % (kname, typelower))
-
         d.setVar('PKG_%s-image-%s' % (kname,typelower), '%s-image-%s-${KERNEL_VERSION_PKG_NAME}' % (kname, typelower))
-
         d.setVar('ALLOW_EMPTY_%s-image-%s' % (kname, typelower), '1')
 
     image = d.getVar('INITRAMFS_IMAGE')
@@ -152,8 +157,8 @@ PACKAGES_DYNAMIC += "^${KERNEL_PACKAGE_NAME}-firmware-.*"
 export OS = "${TARGET_OS}"
 export CROSS_COMPILE = "${TARGET_PREFIX}"
 export KBUILD_BUILD_VERSION = "1"
-export KBUILD_BUILD_USER ?= "oe-user"
-export KBUILD_BUILD_HOST ?= "oe-host"
+export KBUILD_BUILD_USER = "oe-user"
+export KBUILD_BUILD_HOST = "oe-host"
 
 KERNEL_RELEASE ?= "${KERNEL_VERSION}"
 

meta/classes/libc-common.bbclass

@@ -1,9 +1,5 @@
 do_install() {
 	oe_runmake install_root=${D} install
-	for r in ${rpcsvc}; do
-		h=`echo $r|sed -e's,\.x$,.h,'`
-		install -m 0644 ${S}/sunrpc/rpcsvc/$h ${D}/${includedir}/rpcsvc/
-	done
 	install -Dm 0644 ${WORKDIR}/etc/ld.so.conf ${D}/${sysconfdir}/ld.so.conf
 	install -d ${D}${localedir}
 	make -f ${WORKDIR}/generate-supported.mk IN="${S}/localedata/SUPPORTED" OUT="${WORKDIR}/SUPPORTED"

meta/classes/license.bbclass

@@ -480,9 +480,7 @@ def find_license_files(d):
 
     for url in lic_files.split():
         try:
-            (method, host, path, user, pswd, parm) = bb.fetch.decodeurl(url)
-            if method != "file" or not path:
-                raise bb.fetch.MalformedUrl()
+            (type, host, path, user, pswd, parm) = bb.fetch.decodeurl(url)
         except bb.fetch.MalformedUrl:
             bb.fatal("%s: LIC_FILES_CHKSUM contains an invalid URL:  %s" % (d.getVar('PF'), url))
         # We want the license filename and path

meta/classes/meson.bbclass

@@ -90,7 +90,7 @@ meson_do_configure() {
     fi
 }
 
-meson_do_configure_prepend_class-target() {
+override_native_tools() {
     # Set these so that meson uses the native tools for its build sanity tests,
     # which require executables to be runnable. The cross file will still
     # override these for the target build. Note that we do *not* set CFLAGS,
@@ -100,18 +100,15 @@ meson_do_configure_prepend_class-target() {
     export CXX="${BUILD_CXX}"
     export LD="${BUILD_LD}"
     export AR="${BUILD_AR}"
+
+}
+
+meson_do_configure_prepend_class-target() {
+    override_native_tools
 }
 
 meson_do_configure_prepend_class-nativesdk() {
-    # Set these so that meson uses the native tools for its build sanity tests,
-    # which require executables to be runnable. The cross file will still
-    # override these for the nativesdk build. Note that we do *not* set CFLAGS,
-    # LDFLAGS, etc. as they will be slurped in by meson and applied to the
-    # nativesdk build, causing errors.
-    export CC="${BUILD_CC}"
-    export CXX="${BUILD_CXX}"
-    export LD="${BUILD_LD}"
-    export AR="${BUILD_AR}"
+    override_native_tools
 }
 
 meson_do_configure_prepend_class-native() {

meta/classes/mirrors.bbclass

@@ -1,5 +1,4 @@
 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 \
@@ -69,7 +68,7 @@ ${CPAN_MIRROR}  http://search.cpan.org/CPAN/ \n \
 
 MIRRORS += "\
 git://salsa.debian.org/.*     git://salsa.debian.org/PATH;protocol=https \n \
-git://git.gnome.org/.*        git://gitlab.gnome.org/GNOME/PATH;protocol=https \n \
+git://git.gnome.org/.*        git://git.gnome.org/browse/PATH;protocol=https \n \
 git://git.savannah.gnu.org/.* git://git.savannah.gnu.org/git/PATH;protocol=https \n \
 git://git.yoctoproject.org/.* git://git.yoctoproject.org/git/PATH;protocol=https \n \
 git://.*/.*                   git://HOST/PATH;protocol=https \n \

meta/classes/multilib.bbclass

@@ -49,7 +49,6 @@ python multilib_virtclass_handler () {
     if bb.data.inherits_class('allarch', e.data) and not bb.data.inherits_class('packagegroup', e.data):
         raise bb.parse.SkipRecipe("Don't extend allarch recipes which are not packagegroups")
 
-
     # Expand this since this won't work correctly once we set a multilib into place
     e.data.setVar("ALL_MULTILIB_PACKAGE_ARCHS", e.data.getVar("ALL_MULTILIB_PACKAGE_ARCHS"))
  
@@ -65,12 +64,11 @@ python multilib_virtclass_handler () {
     e.data.setVar("PN", variant + "-" + e.data.getVar("PN", False))
     e.data.setVar("OVERRIDES", e.data.getVar("OVERRIDES", False) + override)
 
-    # Expand the WHITELISTs with multilib prefix
-    for whitelist in ["WHITELIST_GPL-3.0", "LGPLv2_WHITELIST_GPL-3.0"]:
-        pkgs = e.data.getVar(whitelist)
-        for pkg in pkgs.split():
-            pkgs += " " + variant + "-" + pkg
-        e.data.setVar(whitelist, pkgs)
+    # Expand WHITELIST_GPL-3.0 with multilib prefix
+    pkgs = e.data.getVar("WHITELIST_GPL-3.0")
+    for pkg in pkgs.split():
+        pkgs += " " + variant + "-" + pkg
+    e.data.setVar("WHITELIST_GPL-3.0", pkgs)
 
     # DEFAULTTUNE can change TARGET_ARCH override so expand this now before update_data
     newtune = e.data.getVar("DEFAULTTUNE_" + "virtclass-multilib-" + variant, False)

meta/classes/multilib_script.bbclass

@@ -1,32 +0,0 @@
-#
-# Recipe needs to set MULTILIB_SCRIPTS in the form <pkgname>:<scriptname>, e.g.
-# MULTILIB_SCRIPTS = "${PN}-dev:${bindir}/file1 ${PN}:${base_bindir}/file2"
-# to indicate which script files to process from which packages.
-#
-
-inherit update-alternatives
-
-MULTILIB_SUFFIX = "${@d.getVar('base_libdir',1).split('/')[-1]}"
-
-PACKAGE_PREPROCESS_FUNCS += "multilibscript_rename"
-
-multilibscript_rename() {
-	:
-}
-
-python () {
-    # Do nothing if multilib isn't being used
-    if not d.getVar("MULTILIB_VARIANTS"):
-       return
-    # Do nothing for native/cross
-    if bb.data.inherits_class('native', d) or bb.data.inherits_class('cross', d):
-       return
-
-    for entry in (d.getVar("MULTILIB_SCRIPTS", False) or "").split():
-       pkg, script = entry.split(":")
-       scriptname = os.path.basename(script)
-       d.setVar("ALTERNATIVE_" + pkg, scriptname)
-       d.setVarFlag("ALTERNATIVE_LINK_NAME", scriptname, script)
-       d.setVarFlag("ALTERNATIVE_TARGET", scriptname, script + "-${MULTILIB_SUFFIX}")
-       d.appendVar("multilibscript_rename",  "\n	mv ${PKGD}" + script + " ${PKGD}" + script + "-${MULTILIB_SUFFIX}")
-}

meta/classes/native.bbclass

@@ -44,7 +44,6 @@ CPPFLAGS = "${BUILD_CPPFLAGS}"
 CFLAGS = "${BUILD_CFLAGS}"
 CXXFLAGS = "${BUILD_CXXFLAGS}"
 LDFLAGS = "${BUILD_LDFLAGS}"
-LDFLAGS_build-darwin = "-L${STAGING_LIBDIR_NATIVE} "
 
 STAGING_BINDIR = "${STAGING_BINDIR_NATIVE}"
 STAGING_BINDIR_CROSS = "${STAGING_BINDIR_NATIVE}"
@@ -78,6 +77,7 @@ exec_prefix = "${STAGING_DIR_NATIVE}${prefix_native}"
 
 bindir = "${STAGING_BINDIR_NATIVE}"
 sbindir = "${STAGING_SBINDIR_NATIVE}"
+base_libdir = "${STAGING_LIBDIR_NATIVE}"
 libdir = "${STAGING_LIBDIR_NATIVE}"
 includedir = "${STAGING_INCDIR_NATIVE}"
 sysconfdir = "${STAGING_ETCDIR_NATIVE}"
@@ -89,6 +89,7 @@ export lt_cv_sys_lib_dlsearch_path_spec = "${libdir} ${base_libdir} /lib /lib64
 
 NATIVE_PACKAGE_PATH_SUFFIX ?= ""
 bindir .= "${NATIVE_PACKAGE_PATH_SUFFIX}"
+base_libdir .= "${NATIVE_PACKAGE_PATH_SUFFIX}"
 libdir .= "${NATIVE_PACKAGE_PATH_SUFFIX}"
 libexecdir .= "${NATIVE_PACKAGE_PATH_SUFFIX}"
 
@@ -152,8 +153,6 @@ python native_virtclass_handler () {
                 newdeps.append(dep)
         d.setVar(varname, " ".join(newdeps))
 
-    e.data.setVar("OVERRIDES", e.data.getVar("OVERRIDES", False) + ":virtclass-native")
-
     map_dependencies("DEPENDS", e.data)
     for pkg in [e.data.getVar("PN"), "", "${PN}"]:
         map_dependencies("RDEPENDS", e.data, pkg)

meta/classes/nativesdk.bbclass

@@ -78,7 +78,6 @@ python nativesdk_virtclass_handler () {
 
     e.data.setVar("MLPREFIX", "nativesdk-")
     e.data.setVar("PN", "nativesdk-" + e.data.getVar("PN").replace("-nativesdk", "").replace("nativesdk-", ""))
-    e.data.setVar("OVERRIDES", e.data.getVar("OVERRIDES", False) + ":virtclass-nativesdk")
 }
 
 python () {

meta/classes/package.bbclass

@@ -359,8 +359,7 @@ def append_source_info(file, sourcefile, d, fatal=True):
     # of rpm's debugedit, which was writing them out that way, and the code elsewhere
     # is still assuming that.
     debuglistoutput = '\0'.join(debugsources) + '\0'
-    with open(sourcefile, 'a') as sf:
-        sf.write(debuglistoutput)
+    open(sourcefile, 'a').write(debuglistoutput)
 
 
 def splitdebuginfo(file, debugfile, debugsrcdir, sourcefile, d):
@@ -1412,6 +1411,9 @@ fi
     pkgdest = d.getVar('PKGDEST')
     pkgdatadir = d.getVar('PKGDESTWORK')
 
+    # Take shared lock since we're only reading, not writing
+    lf = bb.utils.lockfile(d.expand("${PACKAGELOCK}"), True)
+
     data_file = pkgdatadir + d.expand("/${PN}" )
     f = open(data_file, 'w')
     f.write("PACKAGES: %s\n" % packages)
@@ -1516,6 +1518,7 @@ fi
     if bb.data.inherits_class('allarch', d) and not bb.data.inherits_class('packagegroup', d):
         write_extra_runtime_pkgs(global_variants, packages, pkgdatadir)
 
+    bb.utils.unlockfile(lf)
 }
 emit_pkgdata[dirs] = "${PKGDESTWORK}/runtime ${PKGDESTWORK}/runtime-reverse ${PKGDESTWORK}/runtime-rprovides"
 
@@ -1614,6 +1617,9 @@ python package_do_shlibs() {
 
     shlibswork_dir = d.getVar('SHLIBSWORKDIR')
 
+    # Take shared lock since we're only reading, not writing
+    lf = bb.utils.lockfile(d.expand("${PACKAGELOCK}"), True)
+
     def linux_so(file, needed, sonames, renames, pkgver):
         needs_ldconfig = False
         ldir = os.path.dirname(file).replace(pkgdest + "/" + pkg, '')
@@ -1726,11 +1732,7 @@ python package_do_shlibs() {
     use_ldconfig = bb.utils.contains('DISTRO_FEATURES', 'ldconfig', True, False, d)
 
     needed = {}
-
-    # Take shared lock since we're only reading, not writing
-    lf = bb.utils.lockfile(d.expand("${PACKAGELOCK}"), True)
     shlib_provider = oe.package.read_shlib_providers(d)
-    bb.utils.unlockfile(lf)
 
     for pkg in packages.split():
         private_libs = d.getVar('PRIVATE_LIBS_' + pkg) or d.getVar('PRIVATE_LIBS') or ""
@@ -1786,6 +1788,8 @@ python package_do_shlibs() {
             d.setVar('pkg_postinst_%s' % pkg, postinst)
         bb.debug(1, 'LIBNAMES: pkg %s sonames %s' % (pkg, sonames))
 
+    bb.utils.unlockfile(lf)
+
     assumed_libs = d.getVar('ASSUME_SHLIBS')
     if assumed_libs:
         libdir = d.getVar("libdir")
@@ -1898,6 +1902,9 @@ python package_do_pkgconfig () {
                             if hdr == 'Requires':
                                 pkgconfig_needed[pkg] += exp.replace(',', ' ').split()
 
+    # Take shared lock since we're only reading, not writing
+    lf = bb.utils.lockfile(d.expand("${PACKAGELOCK}"), True)
+
     for pkg in packages.split():
         pkgs_file = os.path.join(shlibswork_dir, pkg + ".pclist")
         if pkgconfig_provided[pkg] != []:
@@ -1906,9 +1913,6 @@ python package_do_pkgconfig () {
                 f.write('%s\n' % p)
             f.close()
 
-    # Take shared lock since we're only reading, not writing
-    lf = bb.utils.lockfile(d.expand("${PACKAGELOCK}"), True)
-
     # Go from least to most specific since the last one found wins
     for dir in reversed(shlibs_dirs):
         if not os.path.exists(dir):
@@ -1924,8 +1928,6 @@ python package_do_pkgconfig () {
                 for l in lines:
                     pkgconfig_provided[pkg].append(l.rstrip())
 
-    bb.utils.unlockfile(lf)
-
     for pkg in packages.split():
         deps = []
         for n in pkgconfig_needed[pkg]:
@@ -1943,6 +1945,8 @@ python package_do_pkgconfig () {
             for dep in deps:
                 fd.write(dep + '\n')
             fd.close()
+
+    bb.utils.unlockfile(lf)
 }
 
 def read_libdep_files(d):

meta/classes/package_rpm.bbclass

@@ -113,10 +113,6 @@ python write_specfile () {
             source_list = os.listdir(ar_outdir)
             source_number = 0
             for source in source_list:
-                # do_deploy_archives may have already run (from sstate) meaning a .src.rpm may already 
-                # exist in ARCHIVER_OUTDIR so skip if present.
-                if source.endswith(".src.rpm"):
-                    continue
                 # The rpmbuild doesn't need the root permission, but it needs
                 # to know the file's user and group name, the only user and
                 # group in fakeroot is "root" when working in fakeroot.
@@ -694,7 +690,7 @@ python do_package_rpm () {
     cmd = cmd + " --define '_tmppath " + workdir + "'"
     if d.getVarFlag('ARCHIVER_MODE', 'srpm') == '1' and bb.data.inherits_class('archiver', d):
         cmd = cmd + " --define '_sourcedir " + d.getVar('ARCHIVER_OUTDIR') + "'"
-        cmdsrpm = cmd + " --define '_srcrpmdir " + d.getVar('ARCHIVER_RPMOUTDIR') + "'"
+        cmdsrpm = cmd + " --define '_srcrpmdir " + d.getVar('ARCHIVER_OUTDIR') + "'"
         cmdsrpm = cmdsrpm + " -bs " + outspecfile
         # Build the .src.rpm
         d.setVar('SBUILDSPEC', cmdsrpm + "\n")

meta/classes/patch.bbclass

@@ -153,7 +153,6 @@ python patch_do_patch() {
 patch_do_patch[vardepsexclude] = "PATCHRESOLVE"
 
 addtask patch after do_unpack
-do_patch[umask] = "022"
 do_patch[dirs] = "${WORKDIR}"
 do_patch[depends] = "${PATCHDEPENDENCY}"
 

meta/classes/populate_sdk_ext.bbclass

@@ -325,9 +325,8 @@ python copy_buildsystem () {
             f.write('TCLIBCAPPEND = ""\n')
             f.write('DL_DIR = "${TOPDIR}/downloads"\n')
 
-            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('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

@@ -53,6 +53,10 @@ do_rm_work () {
             *do_setscene*)
                 break
                 ;;
+            *_setscene*)
+                i=dummy
+                break
+                ;;
             *sigdata*|*sigbasedata*)
                 i=dummy
                 break
@@ -89,10 +93,6 @@ do_rm_work () {
                 i=dummy
                 break
                 ;;
-            *_setscene*)
-                i=dummy
-                break
-                ;;
             *$j|*$j.*)
                 mv $i `echo $i | sed -e "s#${j}#${j}_setscene#"`
                 i=dummy

meta/classes/sanity.bbclass

@@ -336,11 +336,11 @@ def check_path_length(filepath, pathname, limit):
     return ""
 
 def get_filesystem_id(path):
-    import subprocess
-    try:
-        return subprocess.check_output(["stat", "-f", "-c", "%t", path]).decode('utf-8')
-    except subprocess.CalledProcessError:
-        bb.warn("Can't get filesystem id of: %s" % path)
+    status, result = oe.utils.getstatusoutput("stat -f -c '%s' '%s'" % ("%t", path))
+    if status == 0:
+        return result
+    else:
+        bb.warn("Can't get the filesystem id of: %s" % path)
         return None
 
 # Check that the path isn't located on nfs.
@@ -463,7 +463,7 @@ def check_patch_version(sanity_data):
     import re, subprocess
 
     try:
-        result = subprocess.check_output(["patch", "--version"], stderr=subprocess.STDOUT).decode('utf-8')
+        result = subprocess.check_output(["patch", "--version"], stderr=subprocess.STDOUT, universal_newlines=True)
         version = re.search(r"[0-9.]+", result.splitlines()[0]).group()
         if LooseVersion(version) < LooseVersion("2.7"):
             return "Your version of patch is older than 2.7 and has bugs which will break builds. Please install a newer version of patch.\n"
@@ -476,12 +476,9 @@ def check_patch_version(sanity_data):
 # Use a modified reproducer from http://savannah.gnu.org/bugs/?30612 to validate.
 def check_make_version(sanity_data):
     from distutils.version import LooseVersion
-    import subprocess
-
-    try:
-        result = subprocess.check_output(['make', '--version'], stderr=subprocess.STDOUT).decode('utf-8')
-    except subprocess.CalledProcessError as e:
-        return "Unable to execute make --version, exit code %d\n%s\n" % (e.returncode, e.output)
+    status, result = oe.utils.getstatusoutput("make --version")
+    if status != 0:
+        return "Unable to execute make --version, exit code %d\n" % status
     version = result.split()[2]
     if LooseVersion(version) == LooseVersion("3.82"):
         # Construct a test file
@@ -496,40 +493,28 @@ def check_make_version(sanity_data):
         f.close()
 
         # Check if make 3.82 has been patched
-        try:
-            subprocess.check_call(['make', '-f', 'makefile_test'])
-        except subprocess.CalledProcessError as e:
+        status,result = oe.utils.getstatusoutput("make -f makefile_test")
+
+        os.remove("makefile_test")
+        if os.path.exists("makefile_test_a.c"):
+            os.remove("makefile_test_a.c")
+        if os.path.exists("makefile_test_b.c"):
+            os.remove("makefile_test_b.c")
+        if os.path.exists("makefile_test.a"):
+            os.remove("makefile_test.a")
+
+        if status != 0:
             return "Your version of make 3.82 is broken. Please revert to 3.81 or install a patched version.\n"
-        finally:
-            os.remove("makefile_test")
-            if os.path.exists("makefile_test_a.c"):
-                os.remove("makefile_test_a.c")
-            if os.path.exists("makefile_test_b.c"):
-                os.remove("makefile_test_b.c")
-            if os.path.exists("makefile_test.a"):
-                os.remove("makefile_test.a")
     return None
 
 
-# Check if we're running on WSL (Windows Subsystem for Linux). Its known not to
-# work but we should tell the user that upfront.
-def check_wsl(d):
-    with open("/proc/version", "r") as f:
-        verdata = f.readlines()
-    for l in verdata:
-        if "Microsoft" in l:
-            return "OpenEmbedded doesn't work under WSL at this time, sorry"
-    return None
-
 # Tar version 1.24 and onwards handle overwriting symlinks correctly
 # but earlier versions do not; this needs to work properly for sstate
 def check_tar_version(sanity_data):
     from distutils.version import LooseVersion
-    import subprocess
-    try:
-        result = subprocess.check_output(["tar", "--version"], stderr=subprocess.STDOUT).decode('utf-8')
-    except subprocess.CalledProcessError as e:
-        return "Unable to execute tar --version, exit code %d\n%s\n" % (e.returncode, e.output)
+    status, result = oe.utils.getstatusoutput("tar --version")
+    if status != 0:
+        return "Unable to execute tar --version, exit code %d\n" % status
     version = result.split()[3]
     if LooseVersion(version) < LooseVersion("1.24"):
         return "Your version of tar is older than 1.24 and has bugs which will break builds. Please install a newer version of tar.\n"
@@ -540,11 +525,9 @@ def check_tar_version(sanity_data):
 # The git fetcher also had workarounds for git < 1.7.9.2 which we've dropped
 def check_git_version(sanity_data):
     from distutils.version import LooseVersion
-    import subprocess
-    try:
-        result = subprocess.check_output(["git", "--version"], stderr=subprocess.DEVNULL).decode('utf-8')
-    except subprocess.CalledProcessError as e:
-        return "Unable to execute git --version, exit code %d\n%s\n" % (e.returncode, e.output)
+    status, result = oe.utils.getstatusoutput("git --version 2> /dev/null")
+    if status != 0:
+        return "Unable to execute git --version, exit code %d\n" % status
     version = result.split()[2]
     if LooseVersion(version) < LooseVersion("1.8.3.1"):
         return "Your version of git is older than 1.8.3.1 and has bugs which will break builds. Please install a newer version of git.\n"
@@ -552,15 +535,13 @@ def check_git_version(sanity_data):
 
 # Check the required perl modules which may not be installed by default
 def check_perl_modules(sanity_data):
-    import subprocess
     ret = ""
     modules = ( "Text::ParseWords", "Thread::Queue", "Data::Dumper" )
     errresult = ''
     for m in modules:
-        try:
-            subprocess.check_output(["perl", "-e", "use %s" % m])
-        except subprocess.CalledProcessError as e:
-            errresult += e.output
+        status, result = oe.utils.getstatusoutput("perl -e 'use %s'" % m)
+        if status != 0:
+            errresult += result
             ret += "%s " % m
     if ret:
         return "Required perl module(s) not found: %s\n\n%s\n" % (ret, errresult)
@@ -635,7 +616,6 @@ def check_sanity_version_change(status, d):
     status.addresult(check_tar_version(d))
     status.addresult(check_git_version(d))
     status.addresult(check_perl_modules(d))
-    status.addresult(check_wsl(d))
 
     missing = ""
 

meta/classes/sstate.bbclass

@@ -59,7 +59,6 @@ SSTATEPREINSTFUNCS = ""
 SSTATEPOSTUNPACKFUNCS = "sstate_hardcode_path_unpack"
 SSTATEPOSTINSTFUNCS = ""
 EXTRA_STAGING_FIXMES ?= "HOSTTOOLS_DIR"
-SSTATECLEANFUNCS = ""
 
 # Check whether sstate exists for tasks that support sstate and are in the
 # locked signatures file.
@@ -507,10 +506,6 @@ def sstate_clean(ss, d):
                 stfile.endswith(rm_nohash):
             oe.path.remove(stfile)
 
-    # Removes the users/groups created by the package
-    for cleanfunc in (d.getVar('SSTATECLEANFUNCS') or '').split():
-        bb.build.exec_func(cleanfunc, d)
-
 sstate_clean[vardepsexclude] = "SSTATE_MANFILEPREFIX"
 
 CLEANFUNCS += "sstate_cleanall"

meta/classes/staging.bbclass

@@ -383,6 +383,8 @@ python extend_recipe_sysroot() {
     lock = bb.utils.lockfile(recipesysroot + "/sysroot.lock")
 
     fixme = {}
+    fixme[''] = []
+    fixme['native'] = []
     seendirs = set()
     postinsts = []
     multilibs = {}
@@ -469,14 +471,7 @@ 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:
@@ -484,13 +479,12 @@ python extend_recipe_sysroot() {
 
         if manifest:
             newmanifest = collections.OrderedDict()
-            targetdir = destsysroot
             if native:
+                fm = fixme['native']
                 targetdir = recipesysrootnative
-            if targetdir not in fixme:
-                fixme[targetdir] = []
-            fm = fixme[targetdir]
-
+            else:
+                fm = fixme['']
+                targetdir = destsysroot
             with open(manifest, "r") as f:
                 manifests[dep] = manifest
                 for l in f:
@@ -548,7 +542,12 @@ python extend_recipe_sysroot() {
     bb.note("Skipping as already exists in sysroot: %s" % str(msg_exists))
 
     for f in fixme:
-        staging_processfixme(fixme[f], f, recipesysroot, recipesysrootnative, d)
+        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)
 
     for p in postinsts:
         subprocess.check_output(p, shell=True, stderr=subprocess.STDOUT)