bitbake: cooker: ensure graceful exit after exception during BuildCompleted handler

If an event handler for bb.event.BuildCompleted fails, we still need to
call finishAsyncCommand() or else BitBake will just exit immediately
without showing any error summary, or worse in the case of memory
resident mode BitBake will hang and if you Ctrl+C to break out, the
command won't be marked as finished which means that no further commands
will be able to be executed until the server is manually restarted.

(Bitbake rev: 5639faa3eef55cc476a82e810e61ca228cbdf221)

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

README.hardware

@@ -255,21 +255,16 @@ Reset the board
 
     and flash it to NOR flash as described above.
 
- 6. Set fdtaddr and loadaddr. This is not necessary if you set them before.
-
- => setenv fdtaddr a00000
- => setenv loadaddr 1000000
-
- 7. Load the kernel and dtb from first partition of the USB disk:
+ 6. Load the kernel and dtb from the first partition of the USB disk:
 
  => usb start
- => ext2load usb 0:1 $loadaddr uImage
- => ext2load usb 0:1 $fdtaddr dtb
+ => ext2load usb 0:1 1000000 uImage
+ => ext2load usb 0:1 2000000 dtb
 
- 8. Set bootargs and boot up the device
+ 7. Set bootargs and boot up the device
 
  => setenv bootargs root=/dev/sdb2 rw rootwait console=ttyS0,115200
- => bootm $loadaddr - $fdtaddr
+ => bootm 1000000 - 2000000
 
 
 --- Booting from NFS root ---

bitbake/LICENSE

@@ -15,3 +15,5 @@ Foundation and individual contributors.
 * QUnit is redistributed under the MIT license.
 
 * Font Awesome fonts redistributed under the SIL Open Font License 1.1
+
+* simplediff is distributed under the zlib license.

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.\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.33.2"
+__version__ = "1.34.0"
 
 if __name__ == "__main__":
     if __version__ != bb.__version__:

bitbake/bin/bitbake-diffsigs

@@ -3,7 +3,7 @@
 # bitbake-diffsigs
 # BitBake task signature data comparison utility
 #
-# Copyright (C) 2012-2013 Intel Corporation
+# Copyright (C) 2012-2013, 2017 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
@@ -22,7 +22,7 @@ import os
 import sys
 import warnings
 import fnmatch
-import optparse
+import argparse
 import logging
 import pickle
 
@@ -30,29 +30,13 @@ sys.path.insert(0, os.path.join(os.path.dirname(os.path.dirname(sys.argv[0])), '
 
 import bb.tinfoil
 import bb.siggen
+import bb.msg
 
-def logger_create(name, output=sys.stderr):
-    logger = logging.getLogger(name)
-    console = logging.StreamHandler(output)
-    format = bb.msg.BBLogFormatter("%(levelname)s: %(message)s")
-    if output.isatty():
-        format.enable_color()
-    console.setFormatter(format)
-    logger.addHandler(console)
-    logger.setLevel(logging.INFO)
-    return logger
+logger = bb.msg.logger_create('bitbake-diffsigs')
 
-logger = logger_create('bitbake-diffsigs')
-
-def find_compare_task(bbhandler, pn, taskname):
+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 """
 
-    def get_hashval(siginfo):
-        if siginfo.endswith('.siginfo'):
-            return siginfo.rpartition(':')[2].partition('_')[0]
-        else:
-            return siginfo.rpartition('.')[2]
-
     if not hasattr(bb.siggen, 'find_siginfo'):
         logger.error('Metadata does not support finding signature data files')
         sys.exit(1)
@@ -60,88 +44,119 @@ def find_compare_task(bbhandler, pn, taskname):
     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])[-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)
+    if sig1 and sig2:
+        sigfiles = bb.siggen.find_siginfo(pn, taskname, [sig1, sig2], bbhandler.config_data)
+        if len(sigfiles) == 0:
+            logger.error('No sigdata files found matching %s %s matching either %s or %s' % (pn, taskname, sig1, sig2))
+            sys.exit(1)
+        elif not sig1 in sigfiles:
+            logger.error('No sigdata files found matching %s %s with signature %s' % (pn, taskname, sig1))
+            sys.exit(1)
+        elif not sig2 in sigfiles:
+            logger.error('No sigdata files found matching %s %s with signature %s' % (pn, taskname, sig2))
+            sys.exit(1)
+        latestfiles = [sigfiles[sig1], sigfiles[sig2]]
     else:
-        # It's possible that latestfiles contain 3 elements and the first two have the same hash value.
-        # In this case, we delete the second element.
-        # The above case is actually the most common one. Because we may have sigdata file and siginfo
-        # file having the same hash value. Comparing such two files makes no sense.
-        if len(latestfiles) == 3:
-            hash0 = get_hashval(latestfiles[0])
-            hash1 = get_hashval(latestfiles[1])
-            if hash0 == hash1:
-                latestfiles.pop(1)
+        filedates = bb.siggen.find_siginfo(pn, taskname, None, bbhandler.config_data)
+        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)
 
-        # Define recursion callback
-        def recursecb(key, hash1, hash2):
-            hashes = [hash1, hash2]
-            hashfiles = bb.siggen.find_siginfo(key, None, hashes, bbhandler.config_data)
+    # Define recursion callback
+    def recursecb(key, hash1, hash2):
+        hashes = [hash1, hash2]
+        hashfiles = bb.siggen.find_siginfo(key, None, hashes, bbhandler.config_data)
 
-            recout = []
-            if len(hashfiles) == 2:
-                out2 = bb.siggen.compare_sigfiles(hashfiles[hash1], hashfiles[hash2], recursecb)
-                recout.extend(list('  ' + l for l in out2))
-            else:
-                recout.append("Unable to find matching sigdata for %s with hashes %s or %s" % (key, hash1, hash2))
+        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)
 
-            return recout
+        return recout
 
-        # Recurse into signature comparison
-        logger.debug("Signature file (previous): %s" % latestfiles[0])
-        logger.debug("Signature file (latest): %s" % latestfiles[1])
-        output = bb.siggen.compare_sigfiles(latestfiles[0], latestfiles[1], recursecb)
-        if output:
-            print('\n'.join(output))
+    # 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)
 
 
 
-parser = optparse.OptionParser(
-    description = "Compares siginfo/sigdata files written out by BitBake",
-    usage = """
-  %prog -t recipename taskname
-  %prog sigdatafile1 sigdatafile2
-  %prog sigdatafile1""")
+parser = argparse.ArgumentParser(
+    description="Compares siginfo/sigdata files written out by BitBake")
 
-parser.add_option("-D", "--debug",
-        help = "enable debug",
-        action = "store_true", dest="debug", default = False)
+parser.add_argument('-d', '--debug',
+                    help='Enable debug output',
+                    action='store_true')
 
-parser.add_option("-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('--color',
+        help='Colorize output (where %(metavar)s is %(choices)s)',
+        choices=['auto', 'always', 'never'], default='auto', metavar='color')
 
-options, args = parser.parse_args(sys.argv)
+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("-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("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 options.debug:
     logger.setLevel(logging.DEBUG)
 
+color = (options.color == 'always' or (options.color == 'auto' and sys.stdout.isatty()))
+
 if options.taskargs:
     with bb.tinfoil.Tinfoil() as tinfoil:
         tinfoil.prepare(config_only=True)
-        find_compare_task(tinfoil, options.taskargs[0], options.taskargs[1])
+        if options.sigargs:
+            find_compare_task(tinfoil, options.taskargs[0], options.taskargs[1], options.sigargs[0], options.sigargs[1], color=color)
+        else:
+            find_compare_task(tinfoil, options.taskargs[0], options.taskargs[1], color=color)
 else:
-    if len(args) == 1:
-        parser.print_help()
-    else:
-        try:
-            if len(args) == 2:
-                output = bb.siggen.dump_sigfile(sys.argv[1])
-            else:
-                output = bb.siggen.compare_sigfiles(sys.argv[1], sys.argv[2])
-        except IOError as e:
-            logger.error(str(e))
-            sys.exit(1)
-        except (pickle.UnpicklingError, EOFError):
-            logger.error('Invalid signature data - ensure you are specifying sigdata/siginfo files')
+    if options.sigargs:
+        logger.error('-s/--signature can only be used together with -t/--task')
+        sys.exit(1)
+    try:
+        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:
+            logger.error('Must specify signature file(s) or -t/--task')
+            parser.print_help()
             sys.exit(1)
+    except IOError as e:
+        logger.error(str(e))
+        sys.exit(1)
+    except (pickle.UnpicklingError, EOFError):
+        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

@@ -29,19 +29,9 @@ sys.path.insert(0, os.path.join(os.path.dirname(os.path.dirname(sys.argv[0])), '
 
 import bb.tinfoil
 import bb.siggen
+import bb.msg
 
-def logger_create(name, output=sys.stderr):
-    logger = logging.getLogger(name)
-    console = logging.StreamHandler(output)
-    format = bb.msg.BBLogFormatter("%(levelname)s: %(message)s")
-    if output.isatty():
-        format.enable_color()
-    console.setFormatter(format)
-    logger.addHandler(console)
-    logger.setLevel(logging.INFO)
-    return logger
-
-logger = logger_create('bitbake-dumpsig')
+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 """

bitbake/bin/bitbake-layers

@@ -24,40 +24,26 @@ import logging
 import os
 import sys
 import argparse
+import signal
 
 bindir = os.path.dirname(__file__)
 topdir = os.path.dirname(bindir)
 sys.path[0:0] = [os.path.join(topdir, 'lib')]
 
 import bb.tinfoil
+import bb.msg
 
-def logger_create(name, output=sys.stderr):
-    logger = logging.getLogger(name)
-    loggerhandler = logging.StreamHandler(output)
-    loggerhandler.setFormatter(logging.Formatter("%(levelname)s: %(message)s"))
-    logger.addHandler(loggerhandler)
-    logger.setLevel(logging.INFO)
-    return logger
-
-def logger_setup_color(logger, color='auto'):
-    from bb.msg import BBLogFormatter
-    console = logging.StreamHandler(sys.stdout)
-    formatter = BBLogFormatter("%(levelname)s: %(message)s")
-    console.setFormatter(formatter)
-    logger.handlers = [console]
-    if color == 'always' or (color == 'auto' and console.stream.isatty()):
-        formatter.enable_color()
-
-
-logger = logger_create('bitbake-layers', sys.stdout)
+logger = bb.msg.logger_create('bitbake-layers', sys.stdout)
 
 def main():
+    signal.signal(signal.SIGPIPE, signal.SIG_DFL)
     parser = argparse.ArgumentParser(
         description="BitBake layers utility",
         epilog="Use %(prog)s <subcommand> --help to get help on a specific command",
         add_help=False)
     parser.add_argument('-d', '--debug', help='Enable debug output', action='store_true')
     parser.add_argument('-q', '--quiet', help='Print only errors', action='store_true')
+    parser.add_argument('-F', '--force', help='Force add without recipe parse verification', action='store_true')
     parser.add_argument('--color', choices=['auto', 'always', 'never'], default='auto', help='Colorize output (where %(metavar)s is %(choices)s)', metavar='COLOR')
 
     global_args, unparsed_args = parser.parse_known_args()
@@ -74,7 +60,9 @@ def main():
     elif global_args.quiet:
         logger.setLevel(logging.ERROR)
 
-    logger_setup_color(logger, global_args.color)
+    # Need to re-run logger_create with color argument
+    # (will be the same logger since it has the same name)
+    bb.msg.logger_create('bitbake-layers', output=sys.stdout, color=global_args.color)
 
     plugins = []
     tinfoil = bb.tinfoil.Tinfoil(tracking=True)

bitbake/bin/git-make-shallow

@@ -0,0 +1,165 @@
+#!/usr/bin/env python3
+"""git-make-shallow: make the current git repository shallow
+
+Remove the history of the specified revisions, then optionally filter the
+available refs to those specified.
+"""
+
+import argparse
+import collections
+import errno
+import itertools
+import os
+import subprocess
+import sys
+
+version = 1.0
+
+
+def main():
+    if sys.version_info < (3, 4, 0):
+        sys.exit('Python 3.4 or greater is required')
+
+    git_dir = check_output(['git', 'rev-parse', '--git-dir']).rstrip()
+    shallow_file = os.path.join(git_dir, 'shallow')
+    if os.path.exists(shallow_file):
+        try:
+            check_output(['git', 'fetch', '--unshallow'])
+        except subprocess.CalledProcessError:
+            try:
+                os.unlink(shallow_file)
+            except OSError as exc:
+                if exc.errno != errno.ENOENT:
+                    raise
+
+    args = process_args()
+    revs = check_output(['git', 'rev-list'] + args.revisions).splitlines()
+
+    make_shallow(shallow_file, args.revisions, args.refs)
+
+    ref_revs = check_output(['git', 'rev-list'] + args.refs).splitlines()
+    remaining_history = set(revs) & set(ref_revs)
+    for rev in remaining_history:
+        if check_output(['git', 'rev-parse', '{}^@'.format(rev)]):
+            sys.exit('Error: %s was not made shallow' % rev)
+
+    filter_refs(args.refs)
+
+    if args.shrink:
+        shrink_repo(git_dir)
+        subprocess.check_call(['git', 'fsck', '--unreachable'])
+
+
+def process_args():
+    # TODO: add argument to automatically keep local-only refs, since they
+    # can't be easily restored with a git fetch.
+    parser = argparse.ArgumentParser(description='Remove the history of the specified revisions, then optionally filter the available refs to those specified.')
+    parser.add_argument('--ref', '-r', metavar='REF', action='append', dest='refs', help='remove all but the specified refs (cumulative)')
+    parser.add_argument('--shrink', '-s', action='store_true', help='shrink the git repository by repacking and pruning')
+    parser.add_argument('revisions', metavar='REVISION', nargs='+', help='a git revision/commit')
+    if len(sys.argv) < 2:
+        parser.print_help()
+        sys.exit(2)
+
+    args = parser.parse_args()
+
+    if args.refs:
+        args.refs = check_output(['git', 'rev-parse', '--symbolic-full-name'] + args.refs).splitlines()
+    else:
+        args.refs = get_all_refs(lambda r, t, tt: t == 'commit' or tt == 'commit')
+
+    args.refs = list(filter(lambda r: not r.endswith('/HEAD'), args.refs))
+    args.revisions = check_output(['git', 'rev-parse'] + ['%s^{}' % i for i in args.revisions]).splitlines()
+    return args
+
+
+def check_output(cmd, input=None):
+    return subprocess.check_output(cmd, universal_newlines=True, input=input)
+
+
+def make_shallow(shallow_file, revisions, refs):
+    """Remove the history of the specified revisions."""
+    for rev in follow_history_intersections(revisions, refs):
+        print("Processing %s" % rev)
+        with open(shallow_file, 'a') as f:
+            f.write(rev + '\n')
+
+
+def get_all_refs(ref_filter=None):
+    """Return all the existing refs in this repository, optionally filtering the refs."""
+    ref_output = check_output(['git', 'for-each-ref', '--format=%(refname)\t%(objecttype)\t%(*objecttype)'])
+    ref_split = [tuple(iter_extend(l.rsplit('\t'), 3)) for l in ref_output.splitlines()]
+    if ref_filter:
+        ref_split = (e for e in ref_split if ref_filter(*e))
+    refs = [r[0] for r in ref_split]
+    return refs
+
+
+def iter_extend(iterable, length, obj=None):
+    """Ensure that iterable is the specified length by extending with obj."""
+    return itertools.islice(itertools.chain(iterable, itertools.repeat(obj)), length)
+
+
+def filter_refs(refs):
+    """Remove all but the specified refs from the git repository."""
+    all_refs = get_all_refs()
+    to_remove = set(all_refs) - set(refs)
+    if to_remove:
+        check_output(['xargs', '-0', '-n', '1', 'git', 'update-ref', '-d', '--no-deref'],
+                     input=''.join(l + '\0' for l in to_remove))
+
+
+def follow_history_intersections(revisions, refs):
+    """Determine all the points where the history of the specified revisions intersects the specified refs."""
+    queue = collections.deque(revisions)
+    seen = set()
+
+    for rev in iter_except(queue.popleft, IndexError):
+        if rev in seen:
+            continue
+
+        parents = check_output(['git', 'rev-parse', '%s^@' % rev]).splitlines()
+
+        yield rev
+        seen.add(rev)
+
+        if not parents:
+            continue
+
+        check_refs = check_output(['git', 'merge-base', '--independent'] + sorted(refs)).splitlines()
+        for parent in parents:
+            for ref in check_refs:
+                print("Checking %s vs %s" % (parent, ref))
+                try:
+                    merge_base = check_output(['git', 'merge-base', parent, ref]).rstrip()
+                except subprocess.CalledProcessError:
+                    continue
+                else:
+                    queue.append(merge_base)
+
+
+def iter_except(func, exception, start=None):
+    """Yield a function repeatedly until it raises an exception."""
+    try:
+        if start is not None:
+            yield start()
+        while True:
+            yield func()
+    except exception:
+        pass
+
+
+def shrink_repo(git_dir):
+    """Shrink the newly shallow repository, removing the unreachable objects."""
+    subprocess.check_call(['git', 'reflog', 'expire', '--expire-unreachable=now', '--all'])
+    subprocess.check_call(['git', 'repack', '-ad'])
+    try:
+        os.unlink(os.path.join(git_dir, 'objects', 'info', 'alternates'))
+    except OSError as exc:
+        if exc.errno != errno.ENOENT:
+            raise
+    subprocess.check_call(['git', 'prune', '--expire', 'now'])
+
+
+if __name__ == '__main__':
+    main()

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

@@ -268,15 +268,6 @@
                 <link linkend='var-FILESPATH'><filename>FILESPATH</filename></link>
                 variable is used in the same way
                 <filename>PATH</filename> is used to find executables.
-                Failing that,
-                <link linkend='var-FILESDIR'><filename>FILESDIR</filename></link>
-                is used to find the appropriate relative file.
-                <note>
-                    <filename>FILESDIR</filename> is deprecated and can
-                    be replaced with <filename>FILESPATH</filename>.
-                    Because <filename>FILESDIR</filename> is likely to be
-                    removed, you should not use this variable in any new code.
-                </note>
                 If the file cannot be found, it is assumed that it is available in
                 <link linkend='var-DL_DIR'><filename>DL_DIR</filename></link>
                 by the time the <filename>download()</filename> method is called.

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

@@ -504,9 +504,19 @@
                              Read the specified file before bitbake.conf.
        -R POSTFILE, --postread=POSTFILE
                              Read the specified file after bitbake.conf.
-       -v, --verbose         Output more log message data to the terminal.
-       -D, --debug           Increase the debug level. You can specify this more
-                             than once.
+       -v, --verbose         Enable tracing of shell tasks (with 'set -x').
+                             Also print bb.note(...) messages to stdout (in
+                             addition to writing them to ${T}/log.do_<task>).
+       -D, --debug           Increase the debug level. You can specify this
+                             more than once. -D sets the debug level to 1,
+                             where only bb.debug(1, ...) messages are printed
+                             to stdout; -DD sets the debug level to 2, where
+                             both bb.debug(1, ...) and bb.debug(2, ...)
+                             messages are printed; etc. Without -D, no debug
+                             messages are printed. Note that -D only affects
+                             output to stdout. All debug messages are written
+                             to ${T}/log.do_taskname, regardless of the debug
+                             level.
        -n, --dry-run         Don't execute, just go through the motions.
        -S SIGNATURE_HANDLER, --dump-signatures=SIGNATURE_HANDLER
                              Dump out the signature construction information, with

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

@@ -1072,7 +1072,8 @@
                 <note>
                     Because <filename>.conf</filename> files are parsed
                     first during BitBake's execution, using
-                    <filename>INHERIT</filename> to inherit a class effectively
+                    <link linkend='var-INHERIT'><filename>INHERIT</filename></link>
+                    to inherit a class effectively
                     inherits the class globally (i.e. for all recipes).
                 </note>
                 If you want to use the directive to inherit
@@ -2029,7 +2030,7 @@
             before any tasks are executed so would be in the global
             configuration datastore namespace.
             No recipe-specific metadata exists in that namespace.
-            The "BuildStarted" and "buildCompleted" events also run in
+            The "BuildStarted" and "BuildCompleted" events also run in
             the main cooker/server process rather than any worker context.
             Thus, any changes made to the datastore would be seen by other
             cooker/server events within the current build but not seen

bitbake/doc/bitbake-user-manual/bitbake-user-manual-ref-variables.xml

@@ -1539,24 +1539,6 @@
             </glossdef>
         </glossentry>
 
-        <glossentry id='var-FILESDIR'><glossterm>FILESDIR</glossterm>
-            <glossdef>
-                <para>
-                    Specifies directories BitBake uses when searching for
-                    patches and files.
-                    The "local" fetcher module uses these directories when
-                    handling <filename>file://</filename> URLs if the file
-                    was not found using
-                    <link linkend='var-FILESPATH'><filename>FILESPATH</filename></link>.
-                    <note>
-                        The <filename>FILESDIR</filename> variable is
-                        deprecated and you should use
-                        <filename>FILESPATH</filename> in all new code.
-                    </note>
-                </para>
-            </glossdef>
-        </glossentry>
-
         <glossentry id='var-FILESPATH'><glossterm>FILESPATH</glossterm>
             <glossdef>
                 <para>
@@ -1614,9 +1596,19 @@
         <glossentry id='var-INHERIT'><glossterm>INHERIT</glossterm>
             <glossdef>
                 <para>
-                    Causes the named class to be inherited at
-                    this point during parsing.
-                    The variable is only valid in configuration files.
+                    Causes the named class or classes to be inherited globally.
+                    Anonymous functions in the class or classes
+                    are not executed for the
+                    base configuration and in each individual recipe.
+                    The OpenEmbedded build system ignores changes to
+                    <filename>INHERIT</filename> in individual recipes.
+                </para>
+
+                <para>
+                    For more information on <filename>INHERIT</filename>, see
+                    the
+                    "<link linkend="inherit-configuration-directive"><filename>INHERIT</filename> Configuration Directive</link>"
+                    section.
                 </para>
             </glossdef>
         </glossentry>

bitbake/lib/bb/COW.py

@@ -3,7 +3,7 @@
 #
 # This is a copy on write dictionary and set which abuses classes to try and be nice and fast.
 #
-# Copyright (C) 2006 Tim Amsell
+# Copyright (C) 2006 Tim Ansell
 #
 # 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

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.33.2"
+__version__ = "1.34.0"
 
 import sys
 if sys.version_info < (3, 4, 0):

bitbake/lib/bb/cache.py

@@ -37,7 +37,7 @@ import bb.utils
 
 logger = logging.getLogger("BitBake.Cache")
 
-__cache_version__ = "150"
+__cache_version__ = "151"
 
 def getCacheFile(path, filename, data_hash):
     return os.path.join(path, filename + "." + data_hash)
@@ -462,6 +462,10 @@ class Cache(NoCache):
                         self.depends_cache[key] = [value]
                     # only fire events on even percentage boundaries
                     current_progress = cachefile.tell() + previous_progress
+                    if current_progress > cachesize:
+                        # we might have calculated incorrect total size because a file
+                        # might've been written out just after we checked its size
+                        cachesize = current_progress
                     current_percent = 100 * current_progress / cachesize
                     if current_percent > previous_percent:
                         previous_percent = current_percent

bitbake/lib/bb/codeparser.py

@@ -1,3 +1,22 @@
+"""
+BitBake code parser
+
+Parses actual code (i.e. python and shell) for functions and in-line
+expressions. Used mainly to determine dependencies on other functions
+and variables within the BitBake metadata. Also provides a cache for
+this information in order to speed up processing.
+
+(Not to be confused with the code that parses the metadata itself,
+see lib/bb/parse/ for that).
+
+NOTE: if you change how the parsers gather information you will almost
+certainly need to increment CodeParserCache.CACHE_VERSION below so that
+any existing codeparser cache gets invalidated. Additionally you'll need
+to increment __cache_version__ in cache.py in order to ensure that old
+recipe caches don't trigger "Taskhash mismatch" errors.
+
+"""
+
 import ast
 import sys
 import codegen
@@ -117,7 +136,11 @@ class shellCacheLine(object):
 
 class CodeParserCache(MultiProcessCache):
     cache_file_name = "bb_codeparser.dat"
-    CACHE_VERSION = 8
+    # NOTE: you must increment this if you change how the parsers gather information,
+    # so that an existing cache gets invalidated. Additionally you'll need
+    # to increment __cache_version__ in cache.py in order to ensure that old
+    # recipe caches don't trigger "Taskhash mismatch" errors.
+    CACHE_VERSION = 9
 
     def __init__(self):
         MultiProcessCache.__init__(self)
@@ -186,13 +209,15 @@ class BufferedLogger(Logger):
 
     def flush(self):
         for record in self.buffer:
-            self.target.handle(record)
+            if self.target.isEnabledFor(record.levelno):
+                self.target.handle(record)
         self.buffer = []
 
 class PythonParser():
     getvars = (".getVar", ".appendVar", ".prependVar")
     getvarflags = (".getVarFlag", ".appendVarFlag", ".prependVarFlag")
-    containsfuncs = ("bb.utils.contains", "base_contains", "bb.utils.contains_any")
+    containsfuncs = ("bb.utils.contains", "base_contains")
+    containsanyfuncs = ("bb.utils.contains_any",  "bb.utils.filter")
     execfuncs = ("bb.build.exec_func", "bb.build.exec_task")
 
     def warn(self, func, arg):
@@ -211,13 +236,17 @@ class PythonParser():
 
     def visit_Call(self, node):
         name = self.called_node_name(node.func)
-        if name and (name.endswith(self.getvars) or name.endswith(self.getvarflags) or name in self.containsfuncs):
+        if name and (name.endswith(self.getvars) or name.endswith(self.getvarflags) or name in self.containsfuncs or name in self.containsanyfuncs):
             if isinstance(node.args[0], ast.Str):
                 varname = node.args[0].s
                 if name in self.containsfuncs and isinstance(node.args[1], ast.Str):
                     if varname not in self.contains:
                         self.contains[varname] = set()
                     self.contains[varname].add(node.args[1].s)
+                elif name in self.containsanyfuncs and isinstance(node.args[1], ast.Str):
+                    if varname not in self.contains:
+                        self.contains[varname] = set()
+                    self.contains[varname].update(node.args[1].s.split())
                 elif name.endswith(self.getvarflags):
                     if isinstance(node.args[1], ast.Str):
                         self.references.add('%s[%s]' % (varname, node.args[1].s))

bitbake/lib/bb/command.py

@@ -141,6 +141,12 @@ class Command:
         self.currentAsyncCommand = None
         self.cooker.finishcommand()
 
+def split_mc_pn(pn):
+    if pn.startswith("multiconfig:"):
+        _, mc, pn = pn.split(":", 2)
+        return (mc, pn)
+    return ('', pn)
+
 class CommandsSync:
     """
     A class of synchronous commands
@@ -227,60 +233,11 @@ class CommandsSync:
         command.cooker.configuration.postfile = postfiles
     setPrePostConfFiles.needconfig = False
 
-    def getCpuCount(self, command, params):
-        """
-        Get the CPU count on the bitbake server
-        """
-        return bb.utils.cpu_count()
-    getCpuCount.readonly = True
-    getCpuCount.needconfig = False
-
     def matchFile(self, command, params):
         fMatch = params[0]
         return command.cooker.matchFile(fMatch)
     matchFile.needconfig = False
 
-    def generateNewImage(self, command, params):
-        image = params[0]
-        base_image = params[1]
-        package_queue = params[2]
-        timestamp = params[3]
-        description = params[4]
-        return command.cooker.generateNewImage(image, base_image,
-                        package_queue, timestamp, description)
-
-    def ensureDir(self, command, params):
-        directory = params[0]
-        bb.utils.mkdirhier(directory)
-    ensureDir.needconfig = False
-
-    def setVarFile(self, command, params):
-        """
-        Save a variable in a file; used for saving in a configuration file
-        """
-        var = params[0]
-        val = params[1]
-        default_file = params[2]
-        op = params[3]
-        command.cooker.modifyConfigurationVar(var, val, default_file, op)
-    setVarFile.needconfig = False
-
-    def removeVarFile(self, command, params):
-        """
-        Remove a variable declaration from a file
-        """
-        var = params[0]
-        command.cooker.removeConfigurationVar(var)
-    removeVarFile.needconfig = False
-
-    def createConfigFile(self, command, params):
-        """
-        Create an extra configuration file
-        """
-        name = params[0]
-        command.cooker.createConfigFile(name)
-    createConfigFile.needconfig = False
-
     def setEventMask(self, command, params):
         handlerNum = params[0]
         llevel = params[1]
@@ -304,7 +261,8 @@ class CommandsSync:
     def updateConfig(self, command, params):
         options = params[0]
         environment = params[1]
-        command.cooker.updateConfigOpts(options, environment)
+        cmdline = params[2]
+        command.cooker.updateConfigOpts(options, environment, cmdline)
     updateConfig.needconfig = False
 
     def parseConfiguration(self, command, params):
@@ -425,8 +383,8 @@ class CommandsSync:
     findProviders.readonly = True
 
     def findBestProvider(self, command, params):
-        pn = params[0]
-        return command.cooker.findBestProvider(pn)
+        (mc, pn) = split_mc_pn(params[0])
+        return command.cooker.findBestProvider(pn, mc)
     findBestProvider.readonly = True
 
     def allProviders(self, command, params):
@@ -473,6 +431,9 @@ class CommandsSync:
                         '_connector_overrides': overridedata}
             else:
                 value['_connector_overrides'] = overridedata
+        else:
+            value = {}
+            value['_connector_overrides'] = overridedata
         return value
     dataStoreConnectorFindVar.readonly = True
 
@@ -636,17 +597,6 @@ class CommandsAsync:
         command.finishAsyncCommand()
     generateTargetsTree.needcache = True
 
-    def findCoreBaseFiles(self, command, params):
-        """
-        Find certain files in COREBASE directory. i.e. Layers
-        """
-        subdir = params[0]
-        filename = params[1]
-
-        command.cooker.findCoreBaseFiles(subdir, filename)
-        command.finishAsyncCommand()
-    findCoreBaseFiles.needcache = False
-
     def findConfigFiles(self, command, params):
         """
         Find config files which provide appropriate values

bitbake/lib/bb/cooker.py

@@ -192,6 +192,8 @@ class BBCooker:
         bb.parse.__mtime_cache = {}
         bb.parse.BBHandler.cached_statements = {}
 
+        self.ui_cmdline = None
+
         self.initConfigurationData()
 
         # we log all events to a file if so directed
@@ -213,9 +215,6 @@ class BBCooker:
 
         self.configuration.server_register_idlecallback(_process_inotify_updates, [self.confignotifier, self.notifier])
 
-        self.baseconfig_valid = True
-        self.parsecache_valid = False
-
         # Take a lock so only one copy of bitbake can run against a given build
         # directory at a time
         if not self.lockBitbake():
@@ -363,6 +362,8 @@ class BBCooker:
         if consolelog:
             self.data.setVar("BB_CONSOLELOG", consolelog)
 
+        self.data.setVar('BB_CMDLINE', self.ui_cmdline)
+
         #
         # Copy of the data store which has been expanded.
         # Used for firing events and accessing variables where expansion needs to be accounted for
@@ -375,6 +376,8 @@ class BBCooker:
         self.data.renameVar("__depends", "__base_depends")
         self.add_filewatch(self.data.getVar("__base_depends", False), self.configwatcher)
 
+        self.baseconfig_valid = True
+        self.parsecache_valid = False
 
     def enableDataTracking(self):
         self.configuration.tracking = True
@@ -386,138 +389,6 @@ class BBCooker:
         if hasattr(self, "data"):
             self.data.disableTracking()
 
-    def modifyConfigurationVar(self, var, val, default_file, op):
-        if op == "append":
-            self.appendConfigurationVar(var, val, default_file)
-        elif op == "set":
-            self.saveConfigurationVar(var, val, default_file, "=")
-        elif op == "earlyAssign":
-            self.saveConfigurationVar(var, val, default_file, "?=")
-
-
-    def appendConfigurationVar(self, var, val, default_file):
-        #add append var operation to the end of default_file
-        default_file = bb.cookerdata.findConfigFile(default_file, self.data)
-
-        total = "#added by hob"
-        total += "\n%s += \"%s\"\n" % (var, val)
-
-        with open(default_file, 'a') as f:
-            f.write(total)
-
-        #add to history
-        loginfo = {"op":"append", "file":default_file, "line":total.count("\n")}
-        self.data.appendVar(var, val, **loginfo)
-
-    def saveConfigurationVar(self, var, val, default_file, op):
-
-        replaced = False
-        #do not save if nothing changed
-        if str(val) == self.data.getVar(var, False):
-            return
-
-        conf_files = self.data.varhistory.get_variable_files(var)
-
-        #format the value when it is a list
-        if isinstance(val, list):
-            listval = ""
-            for value in val:
-                listval += "%s   " % value
-            val = listval
-
-        topdir = self.data.getVar("TOPDIR", False)
-
-        #comment or replace operations made on var
-        for conf_file in conf_files:
-            if topdir in conf_file:
-                with open(conf_file, 'r') as f:
-                    contents = f.readlines()
-
-                lines = self.data.varhistory.get_variable_lines(var, conf_file)
-                for line in lines:
-                    total = ""
-                    i = 0
-                    for c in contents:
-                        total += c
-                        i = i + 1
-                        if i==int(line):
-                            end_index = len(total)
-                    index = total.rfind(var, 0, end_index)
-
-                    begin_line = total.count("\n",0,index)
-                    end_line = int(line)
-
-                    #check if the variable was saved before in the same way
-                    #if true it replace the place where the variable was declared
-                    #else it comments it
-                    if contents[begin_line-1]== "#added by hob\n":
-                        contents[begin_line] = "%s %s \"%s\"\n" % (var, op, val)
-                        replaced = True
-                    else:
-                        for ii in range(begin_line, end_line):
-                            contents[ii] = "#" + contents[ii]
-
-                with open(conf_file, 'w') as f:
-                    f.writelines(contents)
-
-        if replaced == False:
-            #remove var from history
-            self.data.varhistory.del_var_history(var)
-
-            #add var to the end of default_file
-            default_file = bb.cookerdata.findConfigFile(default_file, self.data)
-
-            #add the variable on a single line, to be easy to replace the second time
-            total = "\n#added by hob"
-            total += "\n%s %s \"%s\"\n" % (var, op, val)
-
-            with open(default_file, 'a') as f:
-                f.write(total)
-
-            #add to history
-            loginfo = {"op":"set", "file":default_file, "line":total.count("\n")}
-            self.data.setVar(var, val, **loginfo)
-
-    def removeConfigurationVar(self, var):
-        conf_files = self.data.varhistory.get_variable_files(var)
-        topdir = self.data.getVar("TOPDIR", False)
-
-        for conf_file in conf_files:
-            if topdir in conf_file:
-                with open(conf_file, 'r') as f:
-                    contents = f.readlines()
-
-                lines = self.data.varhistory.get_variable_lines(var, conf_file)
-                for line in lines:
-                    total = ""
-                    i = 0
-                    for c in contents:
-                        total += c
-                        i = i + 1
-                        if i==int(line):
-                            end_index = len(total)
-                    index = total.rfind(var, 0, end_index)
-
-                    begin_line = total.count("\n",0,index)
-
-                    #check if the variable was saved before in the same way
-                    if contents[begin_line-1]== "#added by hob\n":
-                        contents[begin_line-1] = contents[begin_line] = "\n"
-                    else:
-                        contents[begin_line] = "\n"
-                    #remove var from history
-                    self.data.varhistory.del_var_history(var, conf_file, line)
-                    #remove variable
-                    self.data.delVar(var)
-
-                with open(conf_file, 'w') as f:
-                    f.writelines(contents)
-
-    def createConfigFile(self, name):
-        path = os.getcwd()
-        confpath = os.path.join(path, "conf", name)
-        open(confpath, 'w').close()
-
     def parseConfiguration(self):
         # Set log file verbosity
         verboselogs = bb.utils.to_boolean(self.data.getVar("BB_VERBOSE_LOGS", False))
@@ -540,20 +411,28 @@ class BBCooker:
 
         self.handleCollections(self.data.getVar("BBFILE_COLLECTIONS"))
 
-    def updateConfigOpts(self, options, environment):
+    def updateConfigOpts(self, options, environment, cmdline):
+        self.ui_cmdline = cmdline
         clean = True
         for o in options:
-            if o in ['prefile', 'postfile']:
-                clean = False
-                server_val = getattr(self.configuration, "%s_server" % o)
+            if o in ['prefile', 'postfile', 'tracking']:
+                server_val = getattr(self.configuration, "%s_server" % o, None)
                 if not options[o] and server_val:
                     # restore value provided on server start
+                    logger.debug(1, "Restoring server value for option '%s'" % o)
                     setattr(self.configuration, o, server_val)
+                    clean = False
                     continue
+                if getattr(self.configuration, o) == options[o]:
+                    # Value is the same, no need to mark dirty
+                    continue
+                else:
+                    logger.debug(1, "Marking as dirty due to '%s' option change to '%s'" % (o, options[o]))
+                    clean = False
             setattr(self.configuration, o, options[o])
         for k in bb.utils.approved_variables():
             if k in environment and k not in self.configuration.env:
-                logger.debug(1, "Updating environment variable %s to %s" % (k, environment[k]))
+                logger.debug(1, "Updating new environment variable %s to %s" % (k, environment[k]))
                 self.configuration.env[k] = environment[k]
                 clean = False
             if k in self.configuration.env and k not in environment:
@@ -563,12 +442,11 @@ class BBCooker:
             if k not in self.configuration.env and k not in environment:
                  continue
             if environment[k] != self.configuration.env[k]:
-                logger.debug(1, "Updating environment variable %s to %s" % (k, environment[k]))
+                logger.debug(1, "Updating environment variable %s from %s to %s" % (k, self.configuration.env[k], environment[k]))
                 self.configuration.env[k] = environment[k]
                 clean = False
         if not clean:
             logger.debug(1, "Base environment change, triggering reparse")
-            self.baseconfig_valid = False        
             self.reset()
 
     def runCommands(self, server, data, abort):
@@ -905,13 +783,13 @@ class BBCooker:
                 seen_fns.append(taskfn)
 
                 depend_tree["depends"][pn] = []
-                for item in taskdata[mc].depids[taskfn]:
+                for dep in taskdata[mc].depids[taskfn]:
                     pn_provider = ""
                     if dep in taskdata[mc].build_targets and taskdata[mc].build_targets[dep]:
                         fn_provider = taskdata[mc].build_targets[dep][0]
                         pn_provider = self.recipecaches[mc].pkg_fn[fn_provider]
                     else:
-                        pn_provider = item
+                        pn_provider = dep
                     pn_provider = self.add_mc_prefix(mc, pn_provider)
                     depend_tree["depends"][pn].append(pn_provider)
 
@@ -1038,18 +916,6 @@ class BBCooker:
                     providerlog.error("conflicting preferences for %s: both %s and %s specified", providee, provider, self.recipecaches[mc].preferred[providee])
                 self.recipecaches[mc].preferred[providee] = provider
 
-    def findCoreBaseFiles(self, subdir, configfile):
-        corebase = self.data.getVar('COREBASE') or ""
-        paths = []
-        for root, dirs, files in os.walk(corebase + '/' + subdir):
-            for d in dirs:
-                configfilepath = os.path.join(root, d, configfile)
-                if os.path.exists(configfilepath):
-                    paths.append(os.path.join(root, d))
-
-        if paths:
-            bb.event.fire(bb.event.CoreBaseFilesFound(paths), self.data)
-
     def findConfigFilePath(self, configfile):
         """
         Find the location on disk of configfile and if it exists and was parsed by BitBake
@@ -1313,6 +1179,18 @@ class BBCooker:
         self.data.setVar("DATE", time.strftime('%Y%m%d', t))
         self.data.setVar("TIME", time.strftime('%H%M%S', t))
 
+    def reset_mtime_caches(self):
+        """
+        Reset mtime caches - this is particularly important when memory resident as something
+        which is cached is not unlikely to have changed since the last invocation (e.g. a
+        file associated with a recipe might have been modified by the user).
+        """
+        build.reset_cache()
+        bb.fetch._checksum_cache.mtime_cache.clear()
+        siggen_cache = getattr(bb.parse.siggen, 'checksum_cache', None)
+        if siggen_cache:
+            bb.parse.siggen.checksum_cache.mtime_cache.clear()
+
     def matchFiles(self, bf):
         """
         Find the .bb files which match the expression in 'buildfile'.
@@ -1483,14 +1361,16 @@ class BBCooker:
                 return False
 
             if not retval:
-                bb.event.fire(bb.event.BuildCompleted(len(rq.rqdata.runtaskentries), buildname, targets, failures, interrupted), self.data)
-                self.command.finishAsyncCommand(msg)
+                try:
+                    bb.event.fire(bb.event.BuildCompleted(len(rq.rqdata.runtaskentries), buildname, targets, failures, interrupted), self.data)
+                finally:
+                    self.command.finishAsyncCommand(msg)
                 return False
             if retval is True:
                 return True
             return retval
 
-        build.reset_cache()
+        self.reset_mtime_caches()
         self.buildSetVars()
 
         # If we are told to do the None task then query the default task
@@ -1548,55 +1428,6 @@ class BBCooker:
         return dump
 
 
-    def generateNewImage(self, image, base_image, package_queue, timestamp, description):
-        '''
-        Create a new image with a "require"/"inherit" base_image statement
-        '''
-        if timestamp:
-            image_name = os.path.splitext(image)[0]
-            timestr = time.strftime("-%Y%m%d-%H%M%S")
-            dest = image_name + str(timestr) + ".bb"
-        else:
-            if not image.endswith(".bb"):
-                dest = image + ".bb"
-            else:
-                dest = image
-
-        basename = False
-        if base_image:
-            with open(base_image, 'r') as f:
-                require_line = f.readline()
-                p = re.compile("IMAGE_BASENAME *=")
-                for line in f:
-                    if p.search(line):
-                        basename = True
-
-        with open(dest, "w") as imagefile:
-            if base_image is None:
-                imagefile.write("inherit core-image\n")
-            else:
-                topdir = self.data.getVar("TOPDIR", False)
-                if topdir in base_image:
-                    base_image = require_line.split()[1]
-                imagefile.write("require " + base_image + "\n")
-            image_install = "IMAGE_INSTALL = \""
-            for package in package_queue:
-                image_install += str(package) + " "
-            image_install += "\"\n"
-            imagefile.write(image_install)
-
-            description_var = "DESCRIPTION = \"" + description + "\"\n"
-            imagefile.write(description_var)
-
-            if basename:
-                # If this is overwritten in a inherited image, reset it to default
-                image_basename = "IMAGE_BASENAME = \"${PN}\"\n"
-                imagefile.write(image_basename)
-
-        self.state = state.initial
-        if timestamp:
-            return timestr
-
     def updateCacheSync(self):
         if self.state == state.running:
             return
@@ -1611,8 +1442,6 @@ class BBCooker:
         if not self.baseconfig_valid:
             logger.debug(1, "Reloading base configuration data")
             self.initConfigurationData()
-            self.baseconfig_valid = True
-            self.parsecache_valid = False
 
     # This is called for all async commands when self.state != running
     def updateCache(self):

bitbake/lib/bb/cookerdata.py

@@ -76,10 +76,10 @@ class ConfigParameters(object):
         for o in ["abort", "tryaltconfigs", "force", "invalidate_stamp", 
                   "verbose", "debug", "dry_run", "dump_signatures", 
                   "debug_domains", "extra_assume_provided", "profile",
-                  "prefile", "postfile"]:
+                  "prefile", "postfile", "tracking"]:
             options[o] = getattr(self.options, o)
 
-        ret, error = server.runCommand(["updateConfig", options, environment])
+        ret, error = server.runCommand(["updateConfig", options, environment, sys.argv])
         if error:
                 raise Exception("Unable to update the server configuration with local parameters: %s" % error)
 
@@ -346,6 +346,27 @@ class CookerDataBuilder(object):
             data.delVar('LAYERDIR_RE')
             data.delVar('LAYERDIR')
 
+            bbfiles_dynamic = (data.getVar('BBFILES_DYNAMIC') or "").split()
+            collections = (data.getVar('BBFILE_COLLECTIONS') or "").split()
+            invalid = []
+            for entry in bbfiles_dynamic:
+                parts = entry.split(":", 1)
+                if len(parts) != 2:
+                    invalid.append(entry)
+                    continue
+                l, f = parts
+                if l in collections:
+                    data.appendVar("BBFILES", " " + f)
+            if invalid:
+                bb.fatal("BBFILES_DYNAMIC entries must be of the form <collection name>:<filename pattern>, not:\n    %s" % "\n    ".join(invalid))
+
+            layerseries = set((data.getVar("LAYERSERIES_CORENAMES") or "").split())
+            for c in collections:
+                compat = set((data.getVar("LAYERSERIES_COMPAT_%s" % c) or "").split())
+                if compat and not (compat & layerseries):
+                    bb.fatal("Layer %s is not compatible with the core layer which only supports these series: %s (layer is compatible with %s)"
+                              % (c, " ".join(layerseries), " ".join(compat)))
+
         if not data.getVar("BBPATH"):
             msg = "The BBPATH variable is not set"
             if not layerconf:

bitbake/lib/bb/data.py

@@ -296,11 +296,13 @@ def build_dependencies(key, keys, shelldeps, varflagsexcl, d):
             newvalue = ""
             for k in sorted(contains):
                 l = (d.getVar(k) or "").split()
-                for word in sorted(contains[k]):
-                    if word in l:
-                        newvalue += "\n%s{%s} = Set" %  (k, word)
+                for item in sorted(contains[k]):
+                    for word in item.split():
+                        if not word in l:
+                            newvalue += "\n%s{%s} = Unset" % (k, item)
+                            break
                     else:
-                        newvalue += "\n%s{%s} = Unset" %  (k, word)
+                        newvalue += "\n%s{%s} = Set" % (k, item)
             if not newvalue:
                 return value
             if not value:
@@ -357,6 +359,8 @@ def build_dependencies(key, keys, shelldeps, varflagsexcl, d):
 
         deps |= set((vardeps or "").split())
         deps -= set(varflags.get("vardepsexclude", "").split())
+    except bb.parse.SkipRecipe:
+        raise
     except Exception as e:
         bb.warn("Exception during build_dependencies for %s" % key)
         raise

bitbake/lib/bb/data_smart.py

@@ -39,7 +39,7 @@ from bb.COW  import COWDictBase
 logger = logging.getLogger("BitBake.Data")
 
 __setvar_keyword__ = ["_append", "_prepend", "_remove"]
-__setvar_regexp__ = re.compile('(?P<base>.*?)(?P<keyword>_append|_prepend|_remove)(_(?P<add>.*))?$')
+__setvar_regexp__ = re.compile('(?P<base>.*?)(?P<keyword>_append|_prepend|_remove)(_(?P<add>[^A-Z]*))?$')
 __expand_var_regexp__ = re.compile(r"\${[^{}@\n\t :]+}")
 __expand_python_regexp__ = re.compile(r"\${@.+?}")
 
@@ -546,6 +546,8 @@ class DataSmart(MutableMapping):
                 del self.dict[var]["_append"]
             if "_prepend" in self.dict[var]:
                 del self.dict[var]["_prepend"]
+            if "_remove" in self.dict[var]:
+                del self.dict[var]["_remove"]
             if var in self.overridedata:
                 active = []
                 self.need_overrides()

bitbake/lib/bb/fetch2/__init__.py

@@ -425,7 +425,7 @@ def encodeurl(decoded):
 
     return url
 
-def uri_replace(ud, uri_find, uri_replace, replacements, d):
+def uri_replace(ud, uri_find, uri_replace, replacements, d, mirrortarball=None):
     if not ud.url or not uri_find or not uri_replace:
         logger.error("uri_replace: passed an undefined value, not replacing")
         return None
@@ -464,9 +464,9 @@ def uri_replace(ud, uri_find, uri_replace, replacements, d):
             if loc == 2:
                 # Handle path manipulations
                 basename = None
-                if uri_decoded[0] != uri_replace_decoded[0] and ud.mirrortarball:
+                if uri_decoded[0] != uri_replace_decoded[0] and mirrortarball:
                     # If the source and destination url types differ, must be a mirrortarball mapping
-                    basename = os.path.basename(ud.mirrortarball)
+                    basename = os.path.basename(mirrortarball)
                     # Kill parameters, they make no sense for mirror tarballs
                     uri_decoded[5] = {}
                 elif ud.localpath and ud.method.supports_checksum(ud):
@@ -625,7 +625,7 @@ def verify_donestamp(ud, d, origud=None):
     Returns True, if the donestamp exists and is valid, False otherwise. When
     returning False, any existing done stamps are removed.
     """
-    if not ud.needdonestamp:
+    if not ud.needdonestamp or (origud and not origud.needdonestamp):
         return True
 
     if not os.path.exists(ud.donestamp):
@@ -892,45 +892,47 @@ def build_mirroruris(origud, mirrors, ld):
     replacements["BASENAME"] = origud.path.split("/")[-1]
     replacements["MIRRORNAME"] = origud.host.replace(':','.') + origud.path.replace('/', '.').replace('*', '.')
 
-    def adduri(ud, uris, uds, mirrors):
+    def adduri(ud, uris, uds, mirrors, tarballs):
         for line in mirrors:
             try:
                 (find, replace) = line
             except ValueError:
                 continue
-            newuri = uri_replace(ud, find, replace, replacements, ld)
-            if not newuri or newuri in uris or newuri == origud.url:
-                continue
 
-            if not trusted_network(ld, newuri):
-                logger.debug(1, "Mirror %s not in the list of trusted networks, skipping" %  (newuri))
-                continue
+            for tarball in tarballs:
+                newuri = uri_replace(ud, find, replace, replacements, ld, tarball)
+                if not newuri or newuri in uris or newuri == origud.url:
+                    continue
 
-            # Create a local copy of the mirrors minus the current line
-            # this will prevent us from recursively processing the same line
-            # as well as indirect recursion A -> B -> C -> A
-            localmirrors = list(mirrors)
-            localmirrors.remove(line)
+                if not trusted_network(ld, newuri):
+                    logger.debug(1, "Mirror %s not in the list of trusted networks, skipping" %  (newuri))
+                    continue
+
+                # Create a local copy of the mirrors minus the current line
+                # this will prevent us from recursively processing the same line
+                # as well as indirect recursion A -> B -> C -> A
+                localmirrors = list(mirrors)
+                localmirrors.remove(line)
 
-            try:
-                newud = FetchData(newuri, ld)
-                newud.setup_localpath(ld)
-            except bb.fetch2.BBFetchException as e:
-                logger.debug(1, "Mirror fetch failure for url %s (original url: %s)" % (newuri, origud.url))
-                logger.debug(1, str(e))
                 try:
-                    # setup_localpath of file:// urls may fail, we should still see 
-                    # if mirrors of the url exist
-                    adduri(newud, uris, uds, localmirrors)
-                except UnboundLocalError:
-                    pass
-                continue   
-            uris.append(newuri)
-            uds.append(newud)
+                    newud = FetchData(newuri, ld)
+                    newud.setup_localpath(ld)
+                except bb.fetch2.BBFetchException as e:
+                    logger.debug(1, "Mirror fetch failure for url %s (original url: %s)" % (newuri, origud.url))
+                    logger.debug(1, str(e))
+                    try:
+                        # setup_localpath of file:// urls may fail, we should still see 
+                        # if mirrors of the url exist
+                        adduri(newud, uris, uds, localmirrors, tarballs)
+                    except UnboundLocalError:
+                        pass
+                    continue
+                uris.append(newuri)
+                uds.append(newud)
 
-            adduri(newud, uris, uds, localmirrors)
+                adduri(newud, uris, uds, localmirrors, tarballs)
 
-    adduri(origud, uris, uds, mirrors)
+    adduri(origud, uris, uds, mirrors, origud.mirrortarballs or [None])
 
     return uris, uds
 
@@ -975,18 +977,25 @@ def try_mirror_url(fetch, origud, ud, ld, check = False):
         # We may be obtaining a mirror tarball which needs further processing by the real fetcher
         # If that tarball is a local file:// we need to provide a symlink to it
         dldir = ld.getVar("DL_DIR")
-        if origud.mirrortarball and os.path.basename(ud.localpath) == os.path.basename(origud.mirrortarball) \
-                and os.path.basename(ud.localpath) != os.path.basename(origud.localpath):
+
+        if origud.mirrortarballs and os.path.basename(ud.localpath) in origud.mirrortarballs and os.path.basename(ud.localpath) != os.path.basename(origud.localpath):
             # Create donestamp in old format to avoid triggering a re-download
             if ud.donestamp:
                 bb.utils.mkdirhier(os.path.dirname(ud.donestamp))
                 open(ud.donestamp, 'w').close()
             dest = os.path.join(dldir, os.path.basename(ud.localpath))
             if not os.path.exists(dest):
-                os.symlink(ud.localpath, dest)
+                # In case this is executing without any file locks held (as is
+                # the case for file:// URLs), two tasks may end up here at the
+                # same time, in which case we do not want the second task to
+                # fail when the link has already been created by the first task.
+                try:
+                    os.symlink(ud.localpath, dest)
+                except FileExistsError:
+                    pass
             if not verify_donestamp(origud, ld) or origud.method.need_update(origud, ld):
                 origud.method.download(origud, ld)
-                if hasattr(origud.method,"build_mirror_data"):
+                if hasattr(origud.method, "build_mirror_data"):
                     origud.method.build_mirror_data(origud, ld)
             return origud.localpath
         # Otherwise the result is a local file:// and we symlink to it
@@ -995,7 +1004,11 @@ def try_mirror_url(fetch, origud, ud, ld, check = False):
                 # Broken symbolic link
                 os.unlink(origud.localpath)
 
-            os.symlink(ud.localpath, origud.localpath)
+            # As per above, in case two tasks end up here simultaneously.
+            try:
+                os.symlink(ud.localpath, origud.localpath)
+            except FileExistsError:
+                pass
         update_stamp(origud, ld)
         return ud.localpath
 
@@ -1119,7 +1132,7 @@ def srcrev_internal_helper(ud, d, name):
         if srcrev == "INVALID" or not srcrev:
             return parmrev
         if srcrev != parmrev:
-            raise FetchError("Conflicting revisions (%s from SRCREV and %s from the url) found, please spcify one valid value" % (srcrev, parmrev))
+            raise FetchError("Conflicting revisions (%s from SRCREV and %s from the url) found, please specify one valid value" % (srcrev, parmrev))
         return parmrev
 
     if srcrev == "INVALID" or not srcrev:
@@ -1179,7 +1192,7 @@ class FetchData(object):
         self.localfile = ""
         self.localpath = None
         self.lockfile = None
-        self.mirrortarball = None
+        self.mirrortarballs = []
         self.basename = None
         self.basepath = None
         (self.type, self.host, self.path, self.user, self.pswd, self.parm) = decodeurl(d.expand(url))

bitbake/lib/bb/fetch2/git.py

@@ -70,11 +70,14 @@ Supported SRC_URI options are:
 # with this program; if not, write to the Free Software Foundation, Inc.,
 # 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
 
+import collections
 import errno
+import fnmatch
 import os
 import re
+import subprocess
+import tempfile
 import bb
-import errno
 import bb.progress
 from   bb.fetch2 import FetchMethod
 from   bb.fetch2 import runfetchcmd
@@ -172,18 +175,66 @@ class Git(FetchMethod):
         branches = ud.parm.get("branch", "master").split(',')
         if len(branches) != len(ud.names):
             raise bb.fetch2.ParameterError("The number of name and branch parameters is not balanced", ud.url)
+
+        ud.cloneflags = "-s -n"
+        if ud.bareclone:
+            ud.cloneflags += " --mirror"
+
+        ud.shallow = d.getVar("BB_GIT_SHALLOW") == "1"
+        ud.shallow_extra_refs = (d.getVar("BB_GIT_SHALLOW_EXTRA_REFS") or "").split()
+
+        depth_default = d.getVar("BB_GIT_SHALLOW_DEPTH")
+        if depth_default is not None:
+            try:
+                depth_default = int(depth_default or 0)
+            except ValueError:
+                raise bb.fetch2.FetchError("Invalid depth for BB_GIT_SHALLOW_DEPTH: %s" % depth_default)
+            else:
+                if depth_default < 0:
+                    raise bb.fetch2.FetchError("Invalid depth for BB_GIT_SHALLOW_DEPTH: %s" % depth_default)
+        else:
+            depth_default = 1
+        ud.shallow_depths = collections.defaultdict(lambda: depth_default)
+
+        revs_default = d.getVar("BB_GIT_SHALLOW_REVS", True)
+        ud.shallow_revs = []
         ud.branches = {}
         for pos, name in enumerate(ud.names):
             branch = branches[pos]
             ud.branches[name] = branch
             ud.unresolvedrev[name] = branch
 
+            shallow_depth = d.getVar("BB_GIT_SHALLOW_DEPTH_%s" % name)
+            if shallow_depth is not None:
+                try:
+                    shallow_depth = int(shallow_depth or 0)
+                except ValueError:
+                    raise bb.fetch2.FetchError("Invalid depth for BB_GIT_SHALLOW_DEPTH_%s: %s" % (name, shallow_depth))
+                else:
+                    if shallow_depth < 0:
+                        raise bb.fetch2.FetchError("Invalid depth for BB_GIT_SHALLOW_DEPTH_%s: %s" % (name, shallow_depth))
+                    ud.shallow_depths[name] = shallow_depth
+
+            revs = d.getVar("BB_GIT_SHALLOW_REVS_%s" % name)
+            if revs is not None:
+                ud.shallow_revs.extend(revs.split())
+            elif revs_default is not None:
+                ud.shallow_revs.extend(revs_default.split())
+
+        if (ud.shallow and
+                not ud.shallow_revs and
+                all(ud.shallow_depths[n] == 0 for n in ud.names)):
+            # Shallow disabled for this URL
+            ud.shallow = False
+
         if ud.usehead:
             ud.unresolvedrev['default'] = 'HEAD'
 
         ud.basecmd = d.getVar("FETCHCMD_git") or "git -c core.fsyncobjectfiles=0"
 
-        ud.write_tarballs = ((d.getVar("BB_GENERATE_MIRROR_TARBALLS") or "0") != "0") or ud.rebaseable
+        write_tarballs = d.getVar("BB_GENERATE_MIRROR_TARBALLS") or "0"
+        ud.write_tarballs = write_tarballs != "0" or ud.rebaseable
+        ud.write_shallow_tarballs = (d.getVar("BB_GENERATE_SHALLOW_TARBALLS") or write_tarballs) != "0"
 
         ud.setup_revisions(d)
 
@@ -205,13 +256,42 @@ class Git(FetchMethod):
         if ud.rebaseable:
             for name in ud.names:
                 gitsrcname = gitsrcname + '_' + ud.revisions[name]
-        ud.mirrortarball = 'git2_%s.tar.gz' % gitsrcname
-        ud.fullmirror = os.path.join(d.getVar("DL_DIR"), ud.mirrortarball)
-        gitdir = d.getVar("GITDIR") or (d.getVar("DL_DIR") + "/git2/")
-        ud.clonedir = os.path.join(gitdir, gitsrcname)
 
+        dl_dir = d.getVar("DL_DIR")
+        gitdir = d.getVar("GITDIR") or (dl_dir + "/git2/")
+        ud.clonedir = os.path.join(gitdir, gitsrcname)
         ud.localfile = ud.clonedir
 
+        mirrortarball = 'git2_%s.tar.gz' % gitsrcname
+        ud.fullmirror = os.path.join(dl_dir, mirrortarball)
+        ud.mirrortarballs = [mirrortarball]
+        if ud.shallow:
+            tarballname = gitsrcname
+            if ud.bareclone:
+                tarballname = "%s_bare" % tarballname
+
+            if ud.shallow_revs:
+                tarballname = "%s_%s" % (tarballname, "_".join(sorted(ud.shallow_revs)))
+
+            for name, revision in sorted(ud.revisions.items()):
+                tarballname = "%s_%s" % (tarballname, ud.revisions[name][:7])
+                depth = ud.shallow_depths[name]
+                if depth:
+                    tarballname = "%s-%s" % (tarballname, depth)
+
+            shallow_refs = []
+            if not ud.nobranch:
+                shallow_refs.extend(ud.branches.values())
+            if ud.shallow_extra_refs:
+                shallow_refs.extend(r.replace('refs/heads/', '').replace('*', 'ALL') for r in ud.shallow_extra_refs)
+            if shallow_refs:
+                tarballname = "%s_%s" % (tarballname, "_".join(sorted(shallow_refs)).replace('/', '.'))
+
+            fetcher = self.__class__.__name__.lower()
+            ud.shallowtarball = '%sshallow_%s.tar.gz' % (fetcher, tarballname)
+            ud.fullshallow = os.path.join(dl_dir, ud.shallowtarball)
+            ud.mirrortarballs.insert(0, ud.shallowtarball)
+
     def localpath(self, ud, d):
         return ud.clonedir
 
@@ -221,6 +301,8 @@ class Git(FetchMethod):
         for name in ud.names:
             if not self._contains_ref(ud, d, name, ud.clonedir):
                 return True
+        if ud.shallow and ud.write_shallow_tarballs and not os.path.exists(ud.fullshallow):
+            return True
         if ud.write_tarballs and not os.path.exists(ud.fullmirror):
             return True
         return False
@@ -237,8 +319,16 @@ class Git(FetchMethod):
     def download(self, ud, d):
         """Fetch url"""
 
-        # If the checkout doesn't exist and the mirror tarball does, extract it
-        if not os.path.exists(ud.clonedir) and os.path.exists(ud.fullmirror):
+        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:
+            ud.localpath = ud.fullshallow
+            return
+        elif os.path.exists(ud.fullmirror) and no_clone:
             bb.utils.mkdirhier(ud.clonedir)
             runfetchcmd("tar -xzf %s" % ud.fullmirror, d, workdir=ud.clonedir)
 
@@ -284,9 +374,21 @@ class Git(FetchMethod):
                 raise bb.fetch2.FetchError("Unable to find revision %s in branch %s even from upstream" % (ud.revisions[name], ud.branches[name]))
 
     def build_mirror_data(self, ud, d):
-        # Generate a mirror tarball if needed
-        if ud.write_tarballs and not os.path.exists(ud.fullmirror):
-            # it's possible that this symlink points to read-only filesystem with PREMIRROR
+        if ud.shallow and ud.write_shallow_tarballs:
+            if not os.path.exists(ud.fullshallow):
+                if os.path.islink(ud.fullshallow):
+                    os.unlink(ud.fullshallow)
+                tempdir = tempfile.mkdtemp(dir=d.getVar('DL_DIR'))
+                shallowclone = os.path.join(tempdir, 'git')
+                try:
+                    self.clone_shallow_local(ud, shallowclone, d)
+
+                    logger.info("Creating tarball of git repository")
+                    runfetchcmd("tar -czf %s ." % ud.fullshallow, d, workdir=shallowclone)
+                    runfetchcmd("touch %s.done" % ud.fullshallow, d)
+                finally:
+                    bb.utils.remove(tempdir, recurse=True)
+        elif ud.write_tarballs and not os.path.exists(ud.fullmirror):
             if os.path.islink(ud.fullmirror):
                 os.unlink(ud.fullmirror)
 
@@ -294,6 +396,62 @@ class Git(FetchMethod):
             runfetchcmd("tar -czf %s ." % ud.fullmirror, d, workdir=ud.clonedir)
             runfetchcmd("touch %s.done" % ud.fullmirror, d)
 
+    def clone_shallow_local(self, ud, dest, d):
+        """Clone the repo and make it shallow.
+
+        The upstream url of the new clone isn't set at this time, as it'll be
+        set correctly when unpacked."""
+        runfetchcmd("%s clone %s %s %s" % (ud.basecmd, ud.cloneflags, ud.clonedir, dest), d)
+
+        to_parse, shallow_branches = [], []
+        for name in ud.names:
+            revision = ud.revisions[name]
+            depth = ud.shallow_depths[name]
+            if depth:
+                to_parse.append('%s~%d^{}' % (revision, depth - 1))
+
+            # For nobranch, we need a ref, otherwise the commits will be
+            # removed, and for non-nobranch, we truncate the branch to our
+            # srcrev, to avoid keeping unnecessary history beyond that.
+            branch = ud.branches[name]
+            if ud.nobranch:
+                ref = "refs/shallow/%s" % name
+            elif ud.bareclone:
+                ref = "refs/heads/%s" % branch
+            else:
+                ref = "refs/remotes/origin/%s" % branch
+
+            shallow_branches.append(ref)
+            runfetchcmd("%s update-ref %s %s" % (ud.basecmd, ref, revision), d, workdir=dest)
+
+        # Map srcrev+depths to revisions
+        parsed_depths = runfetchcmd("%s rev-parse %s" % (ud.basecmd, " ".join(to_parse)), d, workdir=dest)
+
+        # Resolve specified revisions
+        parsed_revs = runfetchcmd("%s rev-parse %s" % (ud.basecmd, " ".join('"%s^{}"' % r for r in ud.shallow_revs)), d, workdir=dest)
+        shallow_revisions = parsed_depths.splitlines() + parsed_revs.splitlines()
+
+        # Apply extra ref wildcards
+        all_refs = runfetchcmd('%s for-each-ref "--format=%%(refname)"' % ud.basecmd,
+                               d, workdir=dest).splitlines()
+        for r in ud.shallow_extra_refs:
+            if not ud.bareclone:
+                r = r.replace('refs/heads/', 'refs/remotes/origin/')
+
+            if '*' in r:
+                matches = filter(lambda a: fnmatch.fnmatchcase(a, r), all_refs)
+                shallow_branches.extend(matches)
+            else:
+                shallow_branches.append(r)
+
+        # Make the repository shallow
+        shallow_cmd = ['git', 'make-shallow', '-s']
+        for b in shallow_branches:
+            shallow_cmd.append('-r')
+            shallow_cmd.append(b)
+        shallow_cmd.extend(shallow_revisions)
+        runfetchcmd(subprocess.list2cmdline(shallow_cmd), d, workdir=dest)
+
     def unpack(self, ud, destdir, d):
         """ unpack the downloaded src to destdir"""
 
@@ -310,11 +468,12 @@ class Git(FetchMethod):
         if os.path.exists(destdir):
             bb.utils.prunedir(destdir)
 
-        cloneflags = "-s -n"
-        if ud.bareclone:
-            cloneflags += " --mirror"
+        if ud.shallow and (not os.path.exists(ud.clonedir) or self.need_update(ud, d)):
+            bb.utils.mkdirhier(destdir)
+            runfetchcmd("tar -xzf %s" % ud.fullshallow, d, workdir=destdir)
+        else:
+            runfetchcmd("%s clone %s %s/ %s" % (ud.basecmd, ud.cloneflags, ud.clonedir, destdir), d)
 
-        runfetchcmd("%s clone %s %s/ %s" % (ud.basecmd, cloneflags, ud.clonedir, destdir), d)
         repourl = self._get_repo_url(ud)
         runfetchcmd("%s remote set-url origin %s" % (ud.basecmd, repourl), d, workdir=destdir)
         if not ud.nocheckout:
@@ -379,14 +538,26 @@ class Git(FetchMethod):
         """
         Run git ls-remote with the specified search string
         """
-        repourl = self._get_repo_url(ud)
-        cmd = "%s ls-remote %s %s" % \
-              (ud.basecmd, repourl, search)
-        if ud.proto.lower() != 'file':
-            bb.fetch2.check_network_access(d, cmd, repourl)
-        output = runfetchcmd(cmd, d, True)
-        if not output:
-            raise bb.fetch2.FetchError("The command %s gave empty output unexpectedly" % cmd, ud.url)
+        # Prevent recursion e.g. in OE if SRCPV is in PV, PV is in WORKDIR,
+        # and WORKDIR is in PATH (as a result of RSS), our call to
+        # runfetchcmd() exports PATH so this function will get called again (!)
+        # In this scenario the return call of the function isn't actually
+        # important - WORKDIR isn't needed in PATH to call git ls-remote
+        # anyway.
+        if d.getVar('_BB_GIT_IN_LSREMOTE', False):
+            return ''
+        d.setVar('_BB_GIT_IN_LSREMOTE', '1')
+        try:
+            repourl = self._get_repo_url(ud)
+            cmd = "%s ls-remote %s %s" % \
+                (ud.basecmd, repourl, search)
+            if ud.proto.lower() != 'file':
+                bb.fetch2.check_network_access(d, cmd, repourl)
+            output = runfetchcmd(cmd, d, True)
+            if not output:
+                raise bb.fetch2.FetchError("The command %s gave empty output unexpectedly" % cmd, ud.url)
+        finally:
+            d.delVar('_BB_GIT_IN_LSREMOTE')
         return output
 
     def _latest_revision(self, ud, d, name):

bitbake/lib/bb/fetch2/gitannex.py

@@ -33,6 +33,11 @@ class GitANNEX(Git):
         """
         return ud.type in ['gitannex']
 
+    def urldata_init(self, ud, d):
+        super(GitANNEX, self).urldata_init(ud, d)
+        if ud.shallow:
+            ud.shallow_extra_refs += ['refs/heads/git-annex', 'refs/heads/synced/*']
+
     def uses_annex(self, ud, d, wd):
         for name in ud.names:
             try:
@@ -55,9 +60,21 @@ class GitANNEX(Git):
     def download(self, ud, d):
         Git.download(self, ud, d)
 
-        annex = self.uses_annex(ud, d, ud.clonedir)
-        if annex:
-            self.update_annex(ud, d, ud.clonedir)
+        if not ud.shallow or ud.localpath != ud.fullshallow:
+            if self.uses_annex(ud, d, ud.clonedir):
+                self.update_annex(ud, d, ud.clonedir)
+
+    def clone_shallow_local(self, ud, dest, d):
+        super(GitANNEX, self).clone_shallow_local(ud, dest, d)
+
+        try:
+            runfetchcmd("%s annex init" % ud.basecmd, d, workdir=dest)
+        except bb.fetch.FetchError:
+            pass
+
+        if self.uses_annex(ud, d, dest):
+            runfetchcmd("%s annex get" % ud.basecmd, d, workdir=dest)
+            runfetchcmd("chmod u+w -R %s/.git/annex" % (dest), d, quiet=True, workdir=dest)
 
     def unpack(self, ud, destdir, d):
         Git.unpack(self, ud, destdir, d)

bitbake/lib/bb/fetch2/gitsm.py

@@ -117,14 +117,19 @@ class GitSM(Git):
     def download(self, ud, d):
         Git.download(self, ud, d)
 
-        submodules = self.uses_submodules(ud, d, ud.clonedir)
-        if submodules:
-            self.update_submodules(ud, d)
+        if not ud.shallow or ud.localpath != ud.fullshallow:
+            submodules = self.uses_submodules(ud, d, ud.clonedir)
+            if submodules:
+                self.update_submodules(ud, d)
+
+    def clone_shallow_local(self, ud, dest, d):
+        super(GitSM, self).clone_shallow_local(ud, dest, d)
+
+        runfetchcmd('cp -fpPRH "%s/modules" "%s/"' % (ud.clonedir, os.path.join(dest, '.git')), d)
 
     def unpack(self, ud, destdir, d):
         Git.unpack(self, ud, destdir, d)
-        
-        submodules = self.uses_submodules(ud, d, ud.destdir)
-        if submodules:
+
+        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)

bitbake/lib/bb/fetch2/hg.py

@@ -76,8 +76,9 @@ class Hg(FetchMethod):
         # Create paths to mercurial checkouts
         hgsrcname = '%s_%s_%s' % (ud.module.replace('/', '.'), \
                             ud.host, ud.path.replace('/', '.'))
-        ud.mirrortarball = 'hg_%s.tar.gz' % hgsrcname
-        ud.fullmirror = os.path.join(d.getVar("DL_DIR"), ud.mirrortarball)
+        mirrortarball = 'hg_%s.tar.gz' % hgsrcname
+        ud.fullmirror = os.path.join(d.getVar("DL_DIR"), mirrortarball)
+        ud.mirrortarballs = [mirrortarball]
 
         hgdir = d.getVar("HGDIR") or (d.getVar("DL_DIR") + "/hg/")
         ud.pkgdir = os.path.join(hgdir, hgsrcname)

bitbake/lib/bb/fetch2/local.py

@@ -67,12 +67,6 @@ class Local(FetchMethod):
             logger.debug(2, "Searching for %s in paths:\n    %s" % (path, "\n    ".join(filespath.split(":"))))
             newpath, hist = bb.utils.which(filespath, path, history=True)
             searched.extend(hist)
-        if not newpath:
-            filesdir = d.getVar('FILESDIR')
-            if filesdir:
-                logger.debug(2, "Searching for %s in path: %s" % (path, filesdir))
-                newpath = os.path.join(filesdir, path)
-                searched.append(newpath)
         if (not newpath or not os.path.exists(newpath)) and path.find("*") != -1:
             # For expressions using '*', best we can do is take the first directory in FILESPATH that exists
             newpath, hist = bb.utils.which(filespath, ".", history=True)
@@ -102,9 +96,6 @@ class Local(FetchMethod):
             filespath = d.getVar('FILESPATH')
             if filespath:
                 locations = filespath.split(":")
-            filesdir = d.getVar('FILESDIR')
-            if filesdir:
-                locations.append(filesdir)
             locations.append(d.getVar("DL_DIR"))
 
             msg = "Unable to find file " + urldata.url + " anywhere. The paths that were searched were:\n    " + "\n    ".join(locations)

bitbake/lib/bb/fetch2/npm.py

@@ -91,9 +91,10 @@ class Npm(FetchMethod):
         ud.prefixdir = prefixdir
 
         ud.write_tarballs = ((d.getVar("BB_GENERATE_MIRROR_TARBALLS") or "0") != "0")
-        ud.mirrortarball = 'npm_%s-%s.tar.xz' % (ud.pkgname, ud.version)
-        ud.mirrortarball = ud.mirrortarball.replace('/', '-')
-        ud.fullmirror = os.path.join(d.getVar("DL_DIR"), ud.mirrortarball)
+        mirrortarball = 'npm_%s-%s.tar.xz' % (ud.pkgname, ud.version)
+        mirrortarball = ud.mirrortarball.replace('/', '-')
+        ud.fullmirror = os.path.join(d.getVar("DL_DIR"), mirrortarball)
+        ud.mirrortarballs = [mirrortarball]
 
     def need_update(self, ud, d):
         if os.path.exists(ud.localpath):

bitbake/lib/bb/fetch2/s3.py

@@ -55,13 +55,15 @@ class S3(FetchMethod):
 
         ud.localfile = d.expand(urllib.parse.unquote(ud.basename))
 
+        ud.basecmd = d.getVar("FETCHCMD_s3") or "/usr/bin/env aws s3"
+
     def download(self, ud, d):
         """
         Fetch urls
         Assumes localpath was called first
         """
 
-        cmd = 'aws s3 cp s3://%s%s %s' % (ud.host, ud.path, ud.localpath)
+        cmd = '%s cp s3://%s%s %s' % (ud.basecmd, ud.host, ud.path, ud.localpath)
         bb.fetch2.check_network_access(d, cmd, ud.url)
         runfetchcmd(cmd, d)
 
@@ -83,7 +85,7 @@ class S3(FetchMethod):
         Check the status of a URL
         """
 
-        cmd = 'aws s3 ls s3://%s%s' % (ud.host, ud.path)
+        cmd = '%s ls s3://%s%s' % (ud.basecmd, ud.host, ud.path)
         bb.fetch2.check_network_access(d, cmd, ud.url)
         output = runfetchcmd(cmd, d)
 

bitbake/lib/bb/fetch2/wget.py

@@ -107,9 +107,8 @@ class Wget(FetchMethod):
             bb.utils.mkdirhier(os.path.dirname(dldir + os.sep + ud.localfile))
             fetchcmd += " -O " + dldir + os.sep + ud.localfile
 
-        if ud.user:
-            up = ud.user.split(":")
-            fetchcmd += " --user=%s --password=%s --auth-no-challenge" % (up[0],up[1])
+        if ud.user and ud.pswd:
+            fetchcmd += " --user=%s --password=%s --auth-no-challenge" % (ud.user, ud.pswd)
 
         uri = ud.url.split(";")[0]
         if os.path.exists(ud.localpath):

bitbake/lib/bb/main.py

@@ -174,10 +174,21 @@ class BitBakeConfigParameters(cookerdata.ConfigParameters):
                           help="Read the specified file after bitbake.conf.")
 
         parser.add_option("-v", "--verbose", action="store_true", dest="verbose", default=False,
-                          help="Output more log message data to the terminal.")
+                          help="Enable tracing of shell tasks (with 'set -x'). "
+                               "Also print bb.note(...) messages to stdout (in "
+                               "addition to writing them to ${T}/log.do_<task>).")
 
         parser.add_option("-D", "--debug", action="count", dest="debug", default=0,
-                          help="Increase the debug level. You can specify this more than once.")
+                          help="Increase the debug level. You can specify this "
+                               "more than once. -D sets the debug level to 1, "
+                               "where only bb.debug(1, ...) messages are printed "
+                               "to stdout; -DD sets the debug level to 2, where "
+                               "both bb.debug(1, ...) and bb.debug(2, ...) "
+                               "messages are printed; etc. Without -D, no debug "
+                               "messages are printed. Note that -D only affects "
+                               "output to stdout. All debug messages are written "
+                               "to ${T}/log.do_taskname, regardless of the debug "
+                               "level.")
 
         parser.add_option("-q", "--quiet", action="count", dest="quiet", default=0,
                           help="Output less log message data to the terminal. You can specify this more than once.")
@@ -466,10 +477,10 @@ def bitbake_main(configParams, configuration):
 
     return 1
 
-def setup_bitbake(configParams, configuration, extrafeatures=None):
+def setup_bitbake(configParams, configuration, extrafeatures=None, setup_logging=True):
     # Ensure logging messages get sent to the UI as events
     handler = bb.event.LogHandler()
-    if not configParams.status_only:
+    if setup_logging and not configParams.status_only:
         # In status only mode there are no logs and no UI
         logger.addHandler(handler)
 

bitbake/lib/bb/msg.py

@@ -201,3 +201,25 @@ def fatal(msgdomain, msg):
         logger = logging.getLogger("BitBake")
     logger.critical(msg)
     sys.exit(1)
+
+def logger_create(name, output=sys.stderr, level=logging.INFO, preserve_handlers=False, color='auto'):
+    """Standalone logger creation function"""
+    logger = logging.getLogger(name)
+    console = logging.StreamHandler(output)
+    format = bb.msg.BBLogFormatter("%(levelname)s: %(message)s")
+    if color == 'always' or (color == 'auto' and output.isatty()):
+        format.enable_color()
+    console.setFormatter(format)
+    if preserve_handlers:
+        logger.addHandler(console)
+    else:
+        logger.handlers = [console]
+    logger.setLevel(level)
+    return logger
+
+def has_console_handler(logger):
+    for handler in logger.handlers:
+        if isinstance(handler, logging.StreamHandler):
+            if handler.stream in [sys.stderr, sys.stdout]:
+                return True
+    return False

bitbake/lib/bb/parse/parse_py/ConfHandler.py

@@ -32,7 +32,7 @@ from bb.parse import ParseError, resolve_file, ast, logger, handle
 
 __config_regexp__  = re.compile( r"""
     ^
-    (?P<exp>export\s*)?
+    (?P<exp>export\s+)?
     (?P<var>[a-zA-Z0-9\-_+.${}/~]+?)
     (\[(?P<flag>[a-zA-Z0-9\-_+.]+)\])?
 
@@ -69,18 +69,26 @@ def init(data):
 def supports(fn, d):
     return fn[-5:] == ".conf"
 
-def include(parentfn, fn, lineno, data, error_out):
+def include(parentfn, fns, lineno, data, error_out):
     """
     error_out: A string indicating the verb (e.g. "include", "inherit") to be
     used in a ParseError that will be raised if the file to be included could
     not be included. Specify False to avoid raising an error in this case.
     """
+    fns = data.expand(fns)
+    parentfn = data.expand(parentfn)
+
+    # "include" or "require" accept zero to n space-separated file names to include.
+    for fn in fns.split():
+        include_single_file(parentfn, fn, lineno, data, error_out)
+
+def include_single_file(parentfn, fn, lineno, data, error_out):
+    """
+    Helper function for include() which does not expand or split its parameters.
+    """
     if parentfn == fn: # prevent infinite recursion
         return None
 
-    fn = data.expand(fn)
-    parentfn = data.expand(parentfn)
-
     if not os.path.isabs(fn):
         dname = os.path.dirname(parentfn)
         bbpath = "%s:%s" % (dname, data.getVar("BBPATH"))

bitbake/lib/bb/process.py

@@ -94,46 +94,53 @@ def _logged_communicate(pipe, log, input, extrafiles):
                 if data is not None:
                     func(data)
 
+    def read_all_pipes(log, rin, outdata, errdata):
+        rlist = rin
+        stdoutbuf = b""
+        stderrbuf = b""
+
+        try:
+            r,w,e = select.select (rlist, [], [], 1)
+        except OSError as e:
+            if e.errno != errno.EINTR:
+                raise
+
+        readextras(r)
+
+        if pipe.stdout in r:
+            data = stdoutbuf + pipe.stdout.read()
+            if data is not None and len(data) > 0:
+                try:
+                    data = data.decode("utf-8")
+                    outdata.append(data)
+                    log.write(data)
+                    log.flush()
+                    stdoutbuf = b""
+                except UnicodeDecodeError:
+                    stdoutbuf = data
+
+        if pipe.stderr in r:
+            data = stderrbuf + pipe.stderr.read()
+            if data is not None and len(data) > 0:
+                try:
+                    data = data.decode("utf-8")
+                    errdata.append(data)
+                    log.write(data)
+                    log.flush()
+                    stderrbuf = b""
+                except UnicodeDecodeError:
+                    stderrbuf = data
+
     try:
+        # Read all pipes while the process is open
         while pipe.poll() is None:
-            rlist = rin
-            stdoutbuf = b""
-            stderrbuf = b""
-            try:
-                r,w,e = select.select (rlist, [], [], 1)
-            except OSError as e:
-                if e.errno != errno.EINTR:
-                    raise
+            read_all_pipes(log, rin, outdata, errdata)
 
-            if pipe.stdout in r:
-                data = stdoutbuf + pipe.stdout.read()
-                if data is not None and len(data) > 0:
-                    try:
-                        data = data.decode("utf-8")
-                        outdata.append(data)
-                        log.write(data)
-                        stdoutbuf = b""
-                    except UnicodeDecodeError:
-                        stdoutbuf = data
-
-            if pipe.stderr in r:
-                data = stderrbuf + pipe.stderr.read()
-                if data is not None and len(data) > 0:
-                    try:
-                        data = data.decode("utf-8")
-                        errdata.append(data)
-                        log.write(data)
-                        stderrbuf = b""
-                    except UnicodeDecodeError:
-                        stderrbuf = data
-
-            readextras(r)
-
-    finally:    
+        # Pocess closed, drain all pipes...
+        read_all_pipes(log, rin, outdata, errdata)
+    finally:
         log.flush()
 
-    readextras([fobj for fobj, _ in extrafiles])
-
     if pipe.stdout is not None:
         pipe.stdout.close()
     if pipe.stderr is not None:

bitbake/lib/bb/runqueue.py

@@ -697,6 +697,9 @@ class RunQueueData:
                 seendeps.add(t)
                 newdeps.add(t)
                 for i in newdeps:
+                    if i not in self.runtaskentries:
+                        # Not all recipes might have the recrdeptask task as a task
+                        continue
                     task = self.runtaskentries[i].task
                     for n in self.runtaskentries[i].depends:
                         if n not in seendeps:
@@ -1929,7 +1932,7 @@ class RunQueueExecuteTasks(RunQueueExecute):
                         self.rq.state = runQueueFailed
                         self.stats.taskFailed()
                         return True
-                self.rq.fakeworker[mc].process.stdin.write(b"<runtask>" + pickle.dumps((taskfn, task, taskname, False, self.cooker.collection.get_file_appends(fn), taskdepdata, self.rqdata.setscene_enforce)) + b"</runtask>")
+                self.rq.fakeworker[mc].process.stdin.write(b"<runtask>" + pickle.dumps((taskfn, task, taskname, False, self.cooker.collection.get_file_appends(taskfn), taskdepdata, self.rqdata.setscene_enforce)) + b"</runtask>")
                 self.rq.fakeworker[mc].process.stdin.flush()
             else:
                 self.rq.worker[mc].process.stdin.write(b"<runtask>" + pickle.dumps((taskfn, task, taskname, False, self.cooker.collection.get_file_appends(taskfn), taskdepdata, self.rqdata.setscene_enforce)) + b"</runtask>")

bitbake/lib/bb/siggen.py

@@ -5,6 +5,8 @@ import re
 import tempfile
 import pickle
 import bb.data
+import difflib
+import simplediff
 from bb.checksum import FileChecksumCache
 
 logger = logging.getLogger('BitBake.SigGen')
@@ -155,6 +157,8 @@ class SignatureGeneratorBasic(SignatureGenerator):
 
         try:
             taskdeps = self._build_data(fn, d)
+        except bb.parse.SkipRecipe:
+            raise
         except:
             bb.warn("Error during finalise of %s" % fn)
             raise
@@ -351,11 +355,62 @@ def dump_this_task(outfile, d):
     referencestamp = bb.build.stamp_internal(task, d, None, True)
     bb.parse.siggen.dump_sigtask(fn, task, outfile, "customfile:" + referencestamp)
 
+def init_colors(enable_color):
+    """Initialise colour dict for passing to compare_sigfiles()"""
+    # First set up the colours
+    colors = {'color_title':   '\033[1;37;40m',
+              'color_default': '\033[0;37;40m',
+              'color_add':     '\033[1;32;40m',
+              'color_remove':  '\033[1;31;40m',
+             }
+    # Leave all keys present but clear the values
+    if not enable_color:
+        for k in colors.keys():
+            colors[k] = ''
+    return colors
+
+def worddiff_str(oldstr, newstr, colors=None):
+    if not colors:
+        colors = init_colors(False)
+    diff = simplediff.diff(oldstr.split(' '), newstr.split(' '))
+    ret = []
+    for change, value in diff:
+        value = ' '.join(value)
+        if change == '=':
+            ret.append(value)
+        elif change == '+':
+            item = '{color_add}{{+{value}+}}{color_default}'.format(value=value, **colors)
+            ret.append(item)
+        elif change == '-':
+            item = '{color_remove}[-{value}-]{color_default}'.format(value=value, **colors)
+            ret.append(item)
+    whitespace_note = ''
+    if oldstr != newstr and ' '.join(oldstr.split()) == ' '.join(newstr.split()):
+        whitespace_note = ' (whitespace changed)'
+    return '"%s"%s' % (' '.join(ret), whitespace_note)
+
+def list_inline_diff(oldlist, newlist, colors=None):
+    if not colors:
+        colors = init_colors(False)
+    diff = simplediff.diff(oldlist, newlist)
+    ret = []
+    for change, value in diff:
+        value = ' '.join(value)
+        if change == '=':
+            ret.append("'%s'" % value)
+        elif change == '+':
+            item = '{color_add}+{value}{color_default}'.format(value=value, **colors)
+            ret.append(item)
+        elif change == '-':
+            item = '{color_remove}-{value}{color_default}'.format(value=value, **colors)
+            ret.append(item)
+    return '[%s]' % (', '.join(ret))
+
 def clean_basepath(a):
     mc = None
     if a.startswith("multiconfig:"):
         _, mc, a = a.split(":", 2)
-    b = a.rsplit("/", 2)[1] + a.rsplit("/", 2)[2]
+    b = a.rsplit("/", 2)[1] + '/' + a.rsplit("/", 2)[2]
     if a.startswith("virtual:"):
         b = b + ":" + a.rsplit(":", 1)[0]
     if mc:
@@ -374,9 +429,26 @@ def clean_basepaths_list(a):
         b.append(clean_basepath(x))
     return b
 
-def compare_sigfiles(a, b, recursecb = None):
+def compare_sigfiles(a, b, recursecb=None, color=False, collapsed=False):
     output = []
 
+    colors = init_colors(color)
+    def color_format(formatstr, **values):
+        """
+        Return colour formatted string.
+        NOTE: call with the format string, not an already formatted string
+        containing values (otherwise you could have trouble with { and }
+        characters)
+        """
+        if not formatstr.endswith('{color_default}'):
+            formatstr += '{color_default}'
+        # In newer python 3 versions you can pass both of these directly,
+        # but we only require 3.4 at the moment
+        formatparams = {}
+        formatparams.update(colors)
+        formatparams.update(values)
+        return formatstr.format(**formatparams)
+
     with open(a, 'rb') as f:
         p1 = pickle.Unpickler(f)
         a_data = p1.load()
@@ -430,39 +502,59 @@ def compare_sigfiles(a, b, recursecb = None):
         return changed, added, removed
 
     if 'basewhitelist' in a_data and a_data['basewhitelist'] != b_data['basewhitelist']:
-        output.append("basewhitelist changed from '%s' to '%s'" % (a_data['basewhitelist'], b_data['basewhitelist']))
+        output.append(color_format("{color_title}basewhitelist changed{color_default} from '%s' to '%s'") % (a_data['basewhitelist'], b_data['basewhitelist']))
         if a_data['basewhitelist'] and b_data['basewhitelist']:
             output.append("changed items: %s" % a_data['basewhitelist'].symmetric_difference(b_data['basewhitelist']))
 
     if 'taskwhitelist' in a_data and a_data['taskwhitelist'] != b_data['taskwhitelist']:
-        output.append("taskwhitelist changed from '%s' to '%s'" % (a_data['taskwhitelist'], b_data['taskwhitelist']))
+        output.append(color_format("{color_title}taskwhitelist changed{color_default} from '%s' to '%s'") % (a_data['taskwhitelist'], b_data['taskwhitelist']))
         if a_data['taskwhitelist'] and b_data['taskwhitelist']:
             output.append("changed items: %s" % a_data['taskwhitelist'].symmetric_difference(b_data['taskwhitelist']))
 
     if a_data['taskdeps'] != b_data['taskdeps']:
-        output.append("Task dependencies changed from:\n%s\nto:\n%s" % (sorted(a_data['taskdeps']), sorted(b_data['taskdeps'])))
+        output.append(color_format("{color_title}Task dependencies changed{color_default} from:\n%s\nto:\n%s") % (sorted(a_data['taskdeps']), sorted(b_data['taskdeps'])))
 
-    if a_data['basehash'] != b_data['basehash']:
-        output.append("basehash changed from %s to %s" % (a_data['basehash'], b_data['basehash']))
+    if a_data['basehash'] != b_data['basehash'] and not collapsed:
+        output.append(color_format("{color_title}basehash changed{color_default} from %s to %s") % (a_data['basehash'], b_data['basehash']))
 
     changed, added, removed = dict_diff(a_data['gendeps'], b_data['gendeps'], a_data['basewhitelist'] & b_data['basewhitelist'])
     if changed:
         for dep in changed:
-            output.append("List of dependencies for variable %s changed from '%s' to '%s'" % (dep, a_data['gendeps'][dep], b_data['gendeps'][dep]))
+            output.append(color_format("{color_title}List of dependencies for variable %s changed from '{color_default}%s{color_title}' to '{color_default}%s{color_title}'") % (dep, a_data['gendeps'][dep], b_data['gendeps'][dep]))
             if a_data['gendeps'][dep] and b_data['gendeps'][dep]:
                 output.append("changed items: %s" % a_data['gendeps'][dep].symmetric_difference(b_data['gendeps'][dep]))
     if added:
         for dep in added:
-            output.append("Dependency on variable %s was added" % (dep))
+            output.append(color_format("{color_title}Dependency on variable %s was added") % (dep))
     if removed:
         for dep in removed:
-            output.append("Dependency on Variable %s was removed" % (dep))
+            output.append(color_format("{color_title}Dependency on Variable %s was removed") % (dep))
 
 
     changed, added, removed = dict_diff(a_data['varvals'], b_data['varvals'])
     if changed:
         for dep in changed:
-            output.append("Variable %s value changed from '%s' to '%s'" % (dep, a_data['varvals'][dep], b_data['varvals'][dep]))
+            oldval = a_data['varvals'][dep]
+            newval = b_data['varvals'][dep]
+            if newval and oldval and ('\n' in oldval or '\n' in newval):
+                diff = difflib.unified_diff(oldval.splitlines(), newval.splitlines(), lineterm='')
+                # Cut off the first two lines, since we aren't interested in
+                # the old/new filename (they are blank anyway in this case)
+                difflines = list(diff)[2:]
+                if color:
+                    # Add colour to diff output
+                    for i, line in enumerate(difflines):
+                        if line.startswith('+'):
+                            line = color_format('{color_add}{line}', line=line)
+                            difflines[i] = line
+                        elif line.startswith('-'):
+                            line = color_format('{color_remove}{line}', line=line)
+                            difflines[i] = line
+                output.append(color_format("{color_title}Variable {var} value changed:{color_default}\n{diff}", var=dep, diff='\n'.join(difflines)))
+            elif newval and oldval and (' ' in oldval or ' ' in newval):
+                output.append(color_format("{color_title}Variable {var} value changed:{color_default}\n{diff}", var=dep, diff=worddiff_str(oldval, newval, colors)))
+            else:
+                output.append(color_format("{color_title}Variable {var} value changed from '{color_default}{oldval}{color_title}' to '{color_default}{newval}{color_title}'{color_default}", var=dep, oldval=oldval, newval=newval))
 
     if not 'file_checksum_values' in a_data:
          a_data['file_checksum_values'] = {}
@@ -472,32 +564,38 @@ def compare_sigfiles(a, b, recursecb = None):
     changed, added, removed = file_checksums_diff(a_data['file_checksum_values'], b_data['file_checksum_values'])
     if changed:
         for f, old, new in changed:
-            output.append("Checksum for file %s changed from %s to %s" % (f, old, new))
+            output.append(color_format("{color_title}Checksum for file %s changed{color_default} from %s to %s") % (f, old, new))
     if added:
         for f in added:
-            output.append("Dependency on checksum of file %s was added" % (f))
+            output.append(color_format("{color_title}Dependency on checksum of file %s was added") % (f))
     if removed:
         for f in removed:
-            output.append("Dependency on checksum of file %s was removed" % (f))
+            output.append(color_format("{color_title}Dependency on checksum of file %s was removed") % (f))
 
     if not 'runtaskdeps' in a_data:
          a_data['runtaskdeps'] = {}
     if not 'runtaskdeps' in b_data:
          b_data['runtaskdeps'] = {}
 
-    if len(a_data['runtaskdeps']) != len(b_data['runtaskdeps']):
-        changed = ["Number of task dependencies changed"]
-    else:
-        changed = []
-        for idx, task in enumerate(a_data['runtaskdeps']):
-            a = a_data['runtaskdeps'][idx]
-            b = b_data['runtaskdeps'][idx]
-            if a_data['runtaskhashes'][a] != b_data['runtaskhashes'][b]:
-                changed.append("%s with hash %s\n changed to\n%s with hash %s" % (a, a_data['runtaskhashes'][a], b, b_data['runtaskhashes'][b]))
+    if not collapsed:
+        if len(a_data['runtaskdeps']) != len(b_data['runtaskdeps']):
+            changed = ["Number of task dependencies changed"]
+        else:
+            changed = []
+            for idx, task in enumerate(a_data['runtaskdeps']):
+                a = a_data['runtaskdeps'][idx]
+                b = b_data['runtaskdeps'][idx]
+                if a_data['runtaskhashes'][a] != b_data['runtaskhashes'][b] and not collapsed:
+                    changed.append("%s with hash %s\n changed to\n%s with hash %s" % (clean_basepath(a), a_data['runtaskhashes'][a], clean_basepath(b), b_data['runtaskhashes'][b]))
 
-    if changed:
-        output.append("runtaskdeps changed from %s to %s" % (clean_basepaths_list(a_data['runtaskdeps']), clean_basepaths_list(b_data['runtaskdeps'])))
-        output.append("\n".join(changed))
+        if changed:
+            clean_a = clean_basepaths_list(a_data['runtaskdeps'])
+            clean_b = clean_basepaths_list(b_data['runtaskdeps'])
+            if clean_a != clean_b:
+                output.append(color_format("{color_title}runtaskdeps changed:{color_default}\n%s") % list_inline_diff(clean_a, clean_b, colors))
+            else:
+                output.append(color_format("{color_title}runtaskdeps changed:"))
+            output.append("\n".join(changed))
 
 
     if 'runtaskhashes' in a_data and 'runtaskhashes' in b_data:
@@ -513,7 +611,7 @@ def compare_sigfiles(a, b, recursecb = None):
                             #output.append("Dependency on task %s was replaced by %s with same hash" % (dep, bdep))
                             bdep_found = True
                 if not bdep_found:
-                    output.append("Dependency on task %s was added with hash %s" % (clean_basepath(dep), b[dep]))
+                    output.append(color_format("{color_title}Dependency on task %s was added{color_default} with hash %s") % (clean_basepath(dep), b[dep]))
         if removed:
             for dep in removed:
                 adep_found = False
@@ -523,21 +621,25 @@ def compare_sigfiles(a, b, recursecb = None):
                             #output.append("Dependency on task %s was replaced by %s with same hash" % (adep, dep))
                             adep_found = True
                 if not adep_found:
-                    output.append("Dependency on task %s was removed with hash %s" % (clean_basepath(dep), a[dep]))
+                    output.append(color_format("{color_title}Dependency on task %s was removed{color_default} with hash %s") % (clean_basepath(dep), a[dep]))
         if changed:
             for dep in changed:
-                output.append("Hash for dependent task %s changed from %s to %s" % (clean_basepath(dep), a[dep], b[dep]))
+                if not collapsed:
+                    output.append(color_format("{color_title}Hash for dependent task %s changed{color_default} from %s to %s") % (clean_basepath(dep), a[dep], b[dep]))
                 if callable(recursecb):
-                    # If a dependent hash changed, might as well print the line above and then defer to the changes in 
-                    # that hash since in all likelyhood, they're the same changes this task also saw.
                     recout = recursecb(dep, a[dep], b[dep])
                     if recout:
-                        output = [output[-1]] + recout
+                        if collapsed:
+                            output.extend(recout)
+                        else:
+                            # If a dependent hash changed, might as well print the line above and then defer to the changes in 
+                            # that hash since in all likelyhood, they're the same changes this task also saw.
+                            output = [output[-1]] + recout
 
     a_taint = a_data.get('taint', None)
     b_taint = b_data.get('taint', None)
     if a_taint != b_taint:
-        output.append("Taint (by forced/invalidated task) changed from %s to %s" % (a_taint, b_taint))
+        output.append(color_format("{color_title}Taint (by forced/invalidated task) changed{color_default} from %s to %s") % (a_taint, b_taint))
 
     return output
 
@@ -565,7 +667,8 @@ def calc_taskhash(sigdata):
         data = data + sigdata['runtaskhashes'][dep]
 
     for c in sigdata['file_checksum_values']:
-        data = data + c[1]
+        if c[1]:
+            data = data + c[1]
 
     if 'taint' in sigdata:
         if 'nostamp:' in sigdata['taint']:

bitbake/lib/bb/tests/codeparser.py

@@ -49,6 +49,9 @@ class ReferenceTest(unittest.TestCase):
     def assertExecs(self, execs):
         self.assertEqual(self.execs, execs)
 
+    def assertContains(self, contains):
+        self.assertEqual(self.contains, contains)
+
 class VariableReferenceTest(ReferenceTest):
 
     def parseExpression(self, exp):
@@ -201,6 +204,7 @@ class PythonReferenceTest(ReferenceTest):
 
         self.references = parsedvar.references | parser.references
         self.execs = parser.execs
+        self.contains = parser.contains
 
     @staticmethod
     def indent(value):
@@ -265,6 +269,26 @@ be. These unit tests are testing snippets."""
         self.assertExecs(set(["testget"]))
         del self.context["testget"]
 
+    def test_contains(self):
+        self.parseExpression('bb.utils.contains("TESTVAR", "one", "true", "false", d)')
+        self.assertContains({'TESTVAR': {'one'}})
+
+    def test_contains_multi(self):
+        self.parseExpression('bb.utils.contains("TESTVAR", "one two", "true", "false", d)')
+        self.assertContains({'TESTVAR': {'one two'}})
+
+    def test_contains_any(self):
+        self.parseExpression('bb.utils.contains_any("TESTVAR", "hello", "true", "false", d)')
+        self.assertContains({'TESTVAR': {'hello'}})
+
+    def test_contains_any_multi(self):
+        self.parseExpression('bb.utils.contains_any("TESTVAR", "one two three", "true", "false", d)')
+        self.assertContains({'TESTVAR': {'one', 'two', 'three'}})
+
+    def test_contains_filter(self):
+        self.parseExpression('bb.utils.filter("TESTVAR", "hello there world", d)')
+        self.assertContains({'TESTVAR': {'hello', 'there', 'world'}})
+
 
 class DependencyReferenceTest(ReferenceTest):
 
@@ -370,6 +394,30 @@ esac
 
         self.assertEqual(deps, set(["oe_libinstall"]))
 
+    def test_contains_vardeps(self):
+        expr = '${@bb.utils.filter("TESTVAR", "somevalue anothervalue", d)} \
+                ${@bb.utils.contains("TESTVAR", "testval testval2", "yetanothervalue", "", d)} \
+                ${@bb.utils.contains("TESTVAR", "testval2 testval3", "blah", "", d)} \
+                ${@bb.utils.contains_any("TESTVAR", "testval2 testval3", "lastone", "", d)}'
+        parsedvar = self.d.expandWithRefs(expr, None)
+        # Check contains
+        self.assertEqual(parsedvar.contains, {'TESTVAR': {'testval2 testval3', 'anothervalue', 'somevalue', 'testval testval2', 'testval2', 'testval3'}})
+        # Check dependencies
+        self.d.setVar('ANOTHERVAR', expr)
+        self.d.setVar('TESTVAR', 'anothervalue testval testval2')
+        deps, values = bb.data.build_dependencies("ANOTHERVAR", set(self.d.keys()), set(), set(), self.d)
+        self.assertEqual(sorted(values.splitlines()),
+                         sorted([expr,
+                          'TESTVAR{anothervalue} = Set',
+                          'TESTVAR{somevalue} = Unset',
+                          'TESTVAR{testval testval2} = Set',
+                          'TESTVAR{testval2 testval3} = Unset',
+                          'TESTVAR{testval2} = Set',
+                          'TESTVAR{testval3} = Unset'
+                          ]))
+        # Check final value
+        self.assertEqual(self.d.getVar('ANOTHERVAR').split(), ['anothervalue', 'yetanothervalue', 'lastone'])
+
     #Currently no wildcard support
     #def test_vardeps_wildcards(self):
     #    self.d.setVar("oe_libinstall", "echo test")

bitbake/lib/bb/tests/data.py

@@ -283,6 +283,12 @@ class TestConcatOverride(unittest.TestCase):
         self.d.setVar("TEST_remove", "val")
         self.assertEqual(self.d.getVar("TEST"), "bar")
 
+    def test_remove_cleared(self):
+        self.d.setVar("TEST", "${VAL} ${BAR}")
+        self.d.setVar("TEST_remove", "val")
+        self.d.setVar("TEST", "${VAL} ${BAR}")
+        self.assertEqual(self.d.getVar("TEST"), "val bar")
+
     # Ensure the value is unchanged if we have an inactive remove override
     # (including that whitespace is preserved)
     def test_remove_inactive_override(self):

bitbake/lib/bb/tests/fetch.py

@@ -852,3 +852,606 @@ class FetchCheckStatusTest(FetcherTest):
                 self.assertTrue(ret, msg="URI %s, can't check status" % (u))
 
             connection_cache.close_connections()
+
+
+class GitMakeShallowTest(FetcherTest):
+    bitbake_dir = os.path.join(os.path.dirname(os.path.join(__file__)), '..', '..', '..')
+    make_shallow_path = os.path.join(bitbake_dir, 'bin', 'git-make-shallow')
+
+    def setUp(self):
+        FetcherTest.setUp(self)
+        self.gitdir = os.path.join(self.tempdir, 'gitshallow')
+        bb.utils.mkdirhier(self.gitdir)
+        bb.process.run('git init', cwd=self.gitdir)
+
+    def assertRefs(self, expected_refs):
+        actual_refs = self.git(['for-each-ref', '--format=%(refname)']).splitlines()
+        full_expected = self.git(['rev-parse', '--symbolic-full-name'] + expected_refs).splitlines()
+        self.assertEqual(sorted(full_expected), sorted(actual_refs))
+
+    def assertRevCount(self, expected_count, args=None):
+        if args is None:
+            args = ['HEAD']
+        revs = self.git(['rev-list'] + args)
+        actual_count = len(revs.splitlines())
+        self.assertEqual(expected_count, actual_count, msg='Object count `%d` is not the expected `%d`' % (actual_count, expected_count))
+
+    def git(self, cmd):
+        if isinstance(cmd, str):
+            cmd = 'git ' + cmd
+        else:
+            cmd = ['git'] + cmd
+        return bb.process.run(cmd, cwd=self.gitdir)[0]
+
+    def make_shallow(self, args=None):
+        if args is None:
+            args = ['HEAD']
+        return bb.process.run([self.make_shallow_path] + args, cwd=self.gitdir)
+
+    def add_empty_file(self, path, msg=None):
+        if msg is None:
+            msg = path
+        open(os.path.join(self.gitdir, path), 'w').close()
+        self.git(['add', path])
+        self.git(['commit', '-m', msg, path])
+
+    def test_make_shallow_single_branch_no_merge(self):
+        self.add_empty_file('a')
+        self.add_empty_file('b')
+        self.assertRevCount(2)
+        self.make_shallow()
+        self.assertRevCount(1)
+
+    def test_make_shallow_single_branch_one_merge(self):
+        self.add_empty_file('a')
+        self.add_empty_file('b')
+        self.git('checkout -b a_branch')
+        self.add_empty_file('c')
+        self.git('checkout master')
+        self.add_empty_file('d')
+        self.git('merge --no-ff --no-edit a_branch')
+        self.git('branch -d a_branch')
+        self.add_empty_file('e')
+        self.assertRevCount(6)
+        self.make_shallow(['HEAD~2'])
+        self.assertRevCount(5)
+
+    def test_make_shallow_at_merge(self):
+        self.add_empty_file('a')
+        self.git('checkout -b a_branch')
+        self.add_empty_file('b')
+        self.git('checkout master')
+        self.git('merge --no-ff --no-edit a_branch')
+        self.git('branch -d a_branch')
+        self.assertRevCount(3)
+        self.make_shallow()
+        self.assertRevCount(1)
+
+    def test_make_shallow_annotated_tag(self):
+        self.add_empty_file('a')
+        self.add_empty_file('b')
+        self.git('tag -a -m a_tag a_tag')
+        self.assertRevCount(2)
+        self.make_shallow(['a_tag'])
+        self.assertRevCount(1)
+
+    def test_make_shallow_multi_ref(self):
+        self.add_empty_file('a')
+        self.add_empty_file('b')
+        self.git('checkout -b a_branch')
+        self.add_empty_file('c')
+        self.git('checkout master')
+        self.add_empty_file('d')
+        self.git('checkout -b a_branch_2')
+        self.add_empty_file('a_tag')
+        self.git('tag a_tag')
+        self.git('checkout master')
+        self.git('branch -D a_branch_2')
+        self.add_empty_file('e')
+        self.assertRevCount(6, ['--all'])
+        self.make_shallow()
+        self.assertRevCount(5, ['--all'])
+
+    def test_make_shallow_multi_ref_trim(self):
+        self.add_empty_file('a')
+        self.git('checkout -b a_branch')
+        self.add_empty_file('c')
+        self.git('checkout master')
+        self.assertRevCount(1)
+        self.assertRevCount(2, ['--all'])
+        self.assertRefs(['master', 'a_branch'])
+        self.make_shallow(['-r', 'master', 'HEAD'])
+        self.assertRevCount(1, ['--all'])
+        self.assertRefs(['master'])
+
+    def test_make_shallow_noop(self):
+        self.add_empty_file('a')
+        self.assertRevCount(1)
+        self.make_shallow()
+        self.assertRevCount(1)
+
+    if os.environ.get("BB_SKIP_NETTESTS") == "yes":
+        print("Unset BB_SKIP_NETTESTS to run network tests")
+    else:
+        def test_make_shallow_bitbake(self):
+            self.git('remote add origin https://github.com/openembedded/bitbake')
+            self.git('fetch --tags origin')
+            orig_revs = len(self.git('rev-list --all').splitlines())
+            self.make_shallow(['refs/tags/1.10.0'])
+            self.assertRevCount(orig_revs - 1746, ['--all'])
+
+class GitShallowTest(FetcherTest):
+    def setUp(self):
+        FetcherTest.setUp(self)
+        self.gitdir = os.path.join(self.tempdir, 'git')
+        self.srcdir = os.path.join(self.tempdir, 'gitsource')
+
+        bb.utils.mkdirhier(self.srcdir)
+        self.git('init', cwd=self.srcdir)
+        self.d.setVar('WORKDIR', self.tempdir)
+        self.d.setVar('S', self.gitdir)
+        self.d.delVar('PREMIRRORS')
+        self.d.delVar('MIRRORS')
+
+        uri = 'git://%s;protocol=file;subdir=${S}' % self.srcdir
+        self.d.setVar('SRC_URI', uri)
+        self.d.setVar('SRCREV', '${AUTOREV}')
+        self.d.setVar('AUTOREV', '${@bb.fetch2.get_autorev(d)}')
+
+        self.d.setVar('BB_GIT_SHALLOW', '1')
+        self.d.setVar('BB_GENERATE_MIRROR_TARBALLS', '0')
+        self.d.setVar('BB_GENERATE_SHALLOW_TARBALLS', '1')
+
+    def assertRefs(self, expected_refs, cwd=None):
+        if cwd is None:
+            cwd = self.gitdir
+        actual_refs = self.git(['for-each-ref', '--format=%(refname)'], cwd=cwd).splitlines()
+        full_expected = self.git(['rev-parse', '--symbolic-full-name'] + expected_refs, cwd=cwd).splitlines()
+        self.assertEqual(sorted(set(full_expected)), sorted(set(actual_refs)))
+
+    def assertRevCount(self, expected_count, args=None, cwd=None):
+        if args is None:
+            args = ['HEAD']
+        if cwd is None:
+            cwd = self.gitdir
+        revs = self.git(['rev-list'] + args, cwd=cwd)
+        actual_count = len(revs.splitlines())
+        self.assertEqual(expected_count, actual_count, msg='Object count `%d` is not the expected `%d`' % (actual_count, expected_count))
+
+    def git(self, cmd, cwd=None):
+        if isinstance(cmd, str):
+            cmd = 'git ' + cmd
+        else:
+            cmd = ['git'] + cmd
+        if cwd is None:
+            cwd = self.gitdir
+        return bb.process.run(cmd, cwd=cwd)[0]
+
+    def add_empty_file(self, path, cwd=None, msg=None):
+        if msg is None:
+            msg = path
+        if cwd is None:
+            cwd = self.srcdir
+        open(os.path.join(cwd, path), 'w').close()
+        self.git(['add', path], cwd)
+        self.git(['commit', '-m', msg, path], cwd)
+
+    def fetch(self, uri=None):
+        if uri is None:
+            uris = self.d.getVar('SRC_URI', True).split()
+            uri = uris[0]
+            d = self.d
+        else:
+            d = self.d.createCopy()
+            d.setVar('SRC_URI', uri)
+            uri = d.expand(uri)
+            uris = [uri]
+
+        fetcher = bb.fetch2.Fetch(uris, d)
+        fetcher.download()
+        ud = fetcher.ud[uri]
+        return fetcher, ud
+
+    def fetch_and_unpack(self, uri=None):
+        fetcher, ud = self.fetch(uri)
+        fetcher.unpack(self.d.getVar('WORKDIR'))
+        assert os.path.exists(self.d.getVar('S'))
+        return fetcher, ud
+
+    def fetch_shallow(self, uri=None, disabled=False, keepclone=False):
+        """Fetch a uri, generating a shallow tarball, then unpack using it"""
+        fetcher, ud = self.fetch_and_unpack(uri)
+        assert os.path.exists(ud.clonedir), 'Git clone in DLDIR (%s) does not exist for uri %s' % (ud.clonedir, uri)
+
+        # Confirm that the unpacked repo is unshallow
+        if not disabled:
+            assert os.path.exists(os.path.join(self.dldir, ud.mirrortarballs[0]))
+
+        # fetch and unpack, from the shallow tarball
+        bb.utils.remove(self.gitdir, recurse=True)
+        bb.utils.remove(ud.clonedir, recurse=True)
+
+        # confirm that the unpacked repo is used when no git clone or git
+        # mirror tarball is available
+        fetcher, ud = self.fetch_and_unpack(uri)
+        if not disabled:
+            assert os.path.exists(os.path.join(self.gitdir, '.git', 'shallow')), 'Unpacked git repository at %s is not shallow' % self.gitdir
+        else:
+            assert not os.path.exists(os.path.join(self.gitdir, '.git', 'shallow')), 'Unpacked git repository at %s is shallow' % self.gitdir
+        return fetcher, ud
+
+    def test_shallow_disabled(self):
+        self.add_empty_file('a')
+        self.add_empty_file('b')
+        self.assertRevCount(2, cwd=self.srcdir)
+
+        self.d.setVar('BB_GIT_SHALLOW', '0')
+        self.fetch_shallow(disabled=True)
+        self.assertRevCount(2)
+
+    def test_shallow_nobranch(self):
+        self.add_empty_file('a')
+        self.add_empty_file('b')
+        self.assertRevCount(2, cwd=self.srcdir)
+
+        srcrev = self.git('rev-parse HEAD', cwd=self.srcdir).strip()
+        self.d.setVar('SRCREV', srcrev)
+        uri = self.d.getVar('SRC_URI', True).split()[0]
+        uri = '%s;nobranch=1;bare=1' % uri
+
+        self.fetch_shallow(uri)
+        self.assertRevCount(1)
+
+        # shallow refs are used to ensure the srcrev sticks around when we
+        # have no other branches referencing it
+        self.assertRefs(['refs/shallow/default'])
+
+    def test_shallow_default_depth_1(self):
+        # Create initial git repo
+        self.add_empty_file('a')
+        self.add_empty_file('b')
+        self.assertRevCount(2, cwd=self.srcdir)
+
+        self.fetch_shallow()
+        self.assertRevCount(1)
+
+    def test_shallow_depth_0_disables(self):
+        self.add_empty_file('a')
+        self.add_empty_file('b')
+        self.assertRevCount(2, cwd=self.srcdir)
+
+        self.d.setVar('BB_GIT_SHALLOW_DEPTH', '0')
+        self.fetch_shallow(disabled=True)
+        self.assertRevCount(2)
+
+    def test_shallow_depth_default_override(self):
+        self.add_empty_file('a')
+        self.add_empty_file('b')
+        self.assertRevCount(2, cwd=self.srcdir)
+
+        self.d.setVar('BB_GIT_SHALLOW_DEPTH', '2')
+        self.d.setVar('BB_GIT_SHALLOW_DEPTH_default', '1')
+        self.fetch_shallow()
+        self.assertRevCount(1)
+
+    def test_shallow_depth_default_override_disable(self):
+        self.add_empty_file('a')
+        self.add_empty_file('b')
+        self.add_empty_file('c')
+        self.assertRevCount(3, cwd=self.srcdir)
+
+        self.d.setVar('BB_GIT_SHALLOW_DEPTH', '0')
+        self.d.setVar('BB_GIT_SHALLOW_DEPTH_default', '2')
+        self.fetch_shallow()
+        self.assertRevCount(2)
+
+    def test_current_shallow_out_of_date_clone(self):
+        # Create initial git repo
+        self.add_empty_file('a')
+        self.add_empty_file('b')
+        self.add_empty_file('c')
+        self.assertRevCount(3, cwd=self.srcdir)
+
+        # Clone and generate mirror tarball
+        fetcher, ud = self.fetch()
+
+        # Ensure we have a current mirror tarball, but an out of date clone
+        self.git('update-ref refs/heads/master refs/heads/master~1', cwd=ud.clonedir)
+        self.assertRevCount(2, cwd=ud.clonedir)
+
+        # Fetch and unpack, from the current tarball, not the out of date clone
+        bb.utils.remove(self.gitdir, recurse=True)
+        fetcher, ud = self.fetch()
+        fetcher.unpack(self.d.getVar('WORKDIR'))
+        self.assertRevCount(1)
+
+    def test_shallow_single_branch_no_merge(self):
+        self.add_empty_file('a')
+        self.add_empty_file('b')
+        self.assertRevCount(2, cwd=self.srcdir)
+
+        self.fetch_shallow()
+        self.assertRevCount(1)
+        assert os.path.exists(os.path.join(self.gitdir, 'a'))
+        assert os.path.exists(os.path.join(self.gitdir, 'b'))
+
+    def test_shallow_no_dangling(self):
+        self.add_empty_file('a')
+        self.add_empty_file('b')
+        self.assertRevCount(2, cwd=self.srcdir)
+
+        self.fetch_shallow()
+        self.assertRevCount(1)
+        assert not self.git('fsck --dangling')
+
+    def test_shallow_srcrev_branch_truncation(self):
+        self.add_empty_file('a')
+        self.add_empty_file('b')
+        b_commit = self.git('rev-parse HEAD', cwd=self.srcdir).rstrip()
+        self.add_empty_file('c')
+        self.assertRevCount(3, cwd=self.srcdir)
+
+        self.d.setVar('SRCREV', b_commit)
+        self.fetch_shallow()
+
+        # The 'c' commit was removed entirely, and 'a' was removed from history
+        self.assertRevCount(1, ['--all'])
+        self.assertEqual(self.git('rev-parse HEAD').strip(), b_commit)
+        assert os.path.exists(os.path.join(self.gitdir, 'a'))
+        assert os.path.exists(os.path.join(self.gitdir, 'b'))
+        assert not os.path.exists(os.path.join(self.gitdir, 'c'))
+
+    def test_shallow_ref_pruning(self):
+        self.add_empty_file('a')
+        self.add_empty_file('b')
+        self.git('branch a_branch', cwd=self.srcdir)
+        self.assertRefs(['master', 'a_branch'], cwd=self.srcdir)
+        self.assertRevCount(2, cwd=self.srcdir)
+
+        self.fetch_shallow()
+
+        self.assertRefs(['master', 'origin/master'])
+        self.assertRevCount(1)
+
+    def test_shallow_submodules(self):
+        self.add_empty_file('a')
+        self.add_empty_file('b')
+
+        smdir = os.path.join(self.tempdir, 'gitsubmodule')
+        bb.utils.mkdirhier(smdir)
+        self.git('init', cwd=smdir)
+        self.add_empty_file('asub', cwd=smdir)
+
+        self.git('submodule init', cwd=self.srcdir)
+        self.git('submodule add file://%s' % smdir, cwd=self.srcdir)
+        self.git('submodule update', cwd=self.srcdir)
+        self.git('commit -m submodule -a', cwd=self.srcdir)
+
+        uri = 'gitsm://%s;protocol=file;subdir=${S}' % self.srcdir
+        fetcher, ud = self.fetch_shallow(uri)
+
+        self.assertRevCount(1)
+        assert './.git/modules/' in bb.process.run('tar -tzf %s' % os.path.join(self.dldir, ud.mirrortarballs[0]))[0]
+        assert os.listdir(os.path.join(self.gitdir, 'gitsubmodule'))
+
+    if any(os.path.exists(os.path.join(p, 'git-annex')) for p in os.environ.get('PATH').split(':')):
+        def test_shallow_annex(self):
+            self.add_empty_file('a')
+            self.add_empty_file('b')
+            self.git('annex init', cwd=self.srcdir)
+            open(os.path.join(self.srcdir, 'c'), 'w').close()
+            self.git('annex add c', cwd=self.srcdir)
+            self.git('commit -m annex-c -a', cwd=self.srcdir)
+            bb.process.run('chmod u+w -R %s' % os.path.join(self.srcdir, '.git', 'annex'))
+
+            uri = 'gitannex://%s;protocol=file;subdir=${S}' % self.srcdir
+            fetcher, ud = self.fetch_shallow(uri)
+
+            self.assertRevCount(1)
+            assert './.git/annex/' in bb.process.run('tar -tzf %s' % os.path.join(self.dldir, ud.mirrortarballs[0]))[0]
+            assert os.path.exists(os.path.join(self.gitdir, 'c'))
+
+    def test_shallow_multi_one_uri(self):
+        # Create initial git repo
+        self.add_empty_file('a')
+        self.add_empty_file('b')
+        self.git('checkout -b a_branch', cwd=self.srcdir)
+        self.add_empty_file('c')
+        self.add_empty_file('d')
+        self.git('checkout master', cwd=self.srcdir)
+        self.git('tag v0.0 a_branch', cwd=self.srcdir)
+        self.add_empty_file('e')
+        self.git('merge --no-ff --no-edit a_branch', cwd=self.srcdir)
+        self.add_empty_file('f')
+        self.assertRevCount(7, cwd=self.srcdir)
+
+        uri = self.d.getVar('SRC_URI', True).split()[0]
+        uri = '%s;branch=master,a_branch;name=master,a_branch' % uri
+
+        self.d.setVar('BB_GIT_SHALLOW_DEPTH', '0')
+        self.d.setVar('BB_GIT_SHALLOW_REVS', 'v0.0')
+        self.d.setVar('SRCREV_master', '${AUTOREV}')
+        self.d.setVar('SRCREV_a_branch', '${AUTOREV}')
+
+        self.fetch_shallow(uri)
+
+        self.assertRevCount(5)
+        self.assertRefs(['master', 'origin/master', 'origin/a_branch'])
+
+    def test_shallow_multi_one_uri_depths(self):
+        # Create initial git repo
+        self.add_empty_file('a')
+        self.add_empty_file('b')
+        self.git('checkout -b a_branch', cwd=self.srcdir)
+        self.add_empty_file('c')
+        self.add_empty_file('d')
+        self.git('checkout master', cwd=self.srcdir)
+        self.add_empty_file('e')
+        self.git('merge --no-ff --no-edit a_branch', cwd=self.srcdir)
+        self.add_empty_file('f')
+        self.assertRevCount(7, cwd=self.srcdir)
+
+        uri = self.d.getVar('SRC_URI', True).split()[0]
+        uri = '%s;branch=master,a_branch;name=master,a_branch' % uri
+
+        self.d.setVar('BB_GIT_SHALLOW_DEPTH', '0')
+        self.d.setVar('BB_GIT_SHALLOW_DEPTH_master', '3')
+        self.d.setVar('BB_GIT_SHALLOW_DEPTH_a_branch', '1')
+        self.d.setVar('SRCREV_master', '${AUTOREV}')
+        self.d.setVar('SRCREV_a_branch', '${AUTOREV}')
+
+        self.fetch_shallow(uri)
+
+        self.assertRevCount(4, ['--all'])
+        self.assertRefs(['master', 'origin/master', 'origin/a_branch'])
+
+    def test_shallow_clone_preferred_over_shallow(self):
+        self.add_empty_file('a')
+        self.add_empty_file('b')
+
+        # Fetch once to generate the shallow tarball
+        fetcher, ud = self.fetch()
+        assert os.path.exists(os.path.join(self.dldir, ud.mirrortarballs[0]))
+
+        # Fetch and unpack with both the clonedir and shallow tarball available
+        bb.utils.remove(self.gitdir, recurse=True)
+        fetcher, ud = self.fetch_and_unpack()
+
+        # The unpacked tree should *not* be shallow
+        self.assertRevCount(2)
+        assert not os.path.exists(os.path.join(self.gitdir, '.git', 'shallow'))
+
+    def test_shallow_mirrors(self):
+        self.add_empty_file('a')
+        self.add_empty_file('b')
+
+        # Fetch once to generate the shallow tarball
+        fetcher, ud = self.fetch()
+        mirrortarball = ud.mirrortarballs[0]
+        assert os.path.exists(os.path.join(self.dldir, mirrortarball))
+
+        # Set up the mirror
+        mirrordir = os.path.join(self.tempdir, 'mirror')
+        bb.utils.mkdirhier(mirrordir)
+        self.d.setVar('PREMIRRORS', 'git://.*/.* file://%s/\n' % mirrordir)
+
+        os.rename(os.path.join(self.dldir, mirrortarball),
+                  os.path.join(mirrordir, mirrortarball))
+
+        # Fetch from the mirror
+        bb.utils.remove(self.dldir, recurse=True)
+        bb.utils.remove(self.gitdir, recurse=True)
+        self.fetch_and_unpack()
+        self.assertRevCount(1)
+
+    def test_shallow_invalid_depth(self):
+        self.add_empty_file('a')
+        self.add_empty_file('b')
+
+        self.d.setVar('BB_GIT_SHALLOW_DEPTH', '-12')
+        with self.assertRaises(bb.fetch2.FetchError):
+            self.fetch()
+
+    def test_shallow_invalid_depth_default(self):
+        self.add_empty_file('a')
+        self.add_empty_file('b')
+
+        self.d.setVar('BB_GIT_SHALLOW_DEPTH_default', '-12')
+        with self.assertRaises(bb.fetch2.FetchError):
+            self.fetch()
+
+    def test_shallow_extra_refs(self):
+        self.add_empty_file('a')
+        self.add_empty_file('b')
+        self.git('branch a_branch', cwd=self.srcdir)
+        self.assertRefs(['master', 'a_branch'], cwd=self.srcdir)
+        self.assertRevCount(2, cwd=self.srcdir)
+
+        self.d.setVar('BB_GIT_SHALLOW_EXTRA_REFS', 'refs/heads/a_branch')
+        self.fetch_shallow()
+
+        self.assertRefs(['master', 'origin/master', 'origin/a_branch'])
+        self.assertRevCount(1)
+
+    def test_shallow_extra_refs_wildcard(self):
+        self.add_empty_file('a')
+        self.add_empty_file('b')
+        self.git('branch a_branch', cwd=self.srcdir)
+        self.git('tag v1.0', cwd=self.srcdir)
+        self.assertRefs(['master', 'a_branch', 'v1.0'], cwd=self.srcdir)
+        self.assertRevCount(2, cwd=self.srcdir)
+
+        self.d.setVar('BB_GIT_SHALLOW_EXTRA_REFS', 'refs/tags/*')
+        self.fetch_shallow()
+
+        self.assertRefs(['master', 'origin/master', 'v1.0'])
+        self.assertRevCount(1)
+
+    def test_shallow_missing_extra_refs(self):
+        self.add_empty_file('a')
+        self.add_empty_file('b')
+
+        self.d.setVar('BB_GIT_SHALLOW_EXTRA_REFS', 'refs/heads/foo')
+        with self.assertRaises(bb.fetch2.FetchError):
+            self.fetch()
+
+    def test_shallow_missing_extra_refs_wildcard(self):
+        self.add_empty_file('a')
+        self.add_empty_file('b')
+
+        self.d.setVar('BB_GIT_SHALLOW_EXTRA_REFS', 'refs/tags/*')
+        self.fetch()
+
+    def test_shallow_remove_revs(self):
+        # Create initial git repo
+        self.add_empty_file('a')
+        self.add_empty_file('b')
+        self.git('checkout -b a_branch', cwd=self.srcdir)
+        self.add_empty_file('c')
+        self.add_empty_file('d')
+        self.git('checkout master', cwd=self.srcdir)
+        self.git('tag v0.0 a_branch', cwd=self.srcdir)
+        self.add_empty_file('e')
+        self.git('merge --no-ff --no-edit a_branch', cwd=self.srcdir)
+        self.git('branch -d a_branch', cwd=self.srcdir)
+        self.add_empty_file('f')
+        self.assertRevCount(7, cwd=self.srcdir)
+
+        self.d.setVar('BB_GIT_SHALLOW_DEPTH', '0')
+        self.d.setVar('BB_GIT_SHALLOW_REVS', 'v0.0')
+
+        self.fetch_shallow()
+
+        self.assertRevCount(5)
+
+    def test_shallow_invalid_revs(self):
+        self.add_empty_file('a')
+        self.add_empty_file('b')
+
+        self.d.setVar('BB_GIT_SHALLOW_DEPTH', '0')
+        self.d.setVar('BB_GIT_SHALLOW_REVS', 'v0.0')
+
+        with self.assertRaises(bb.fetch2.FetchError):
+            self.fetch()
+
+    if os.environ.get("BB_SKIP_NETTESTS") == "yes":
+        print("Unset BB_SKIP_NETTESTS to run network tests")
+    else:
+        def test_bitbake(self):
+            self.git('remote add --mirror=fetch origin git://github.com/openembedded/bitbake', cwd=self.srcdir)
+            self.git('config core.bare true', cwd=self.srcdir)
+            self.git('fetch --tags', cwd=self.srcdir)
+
+            self.d.setVar('BB_GIT_SHALLOW_DEPTH', '0')
+            # Note that the 1.10.0 tag is annotated, so this also tests
+            # reference of an annotated vs unannotated tag
+            self.d.setVar('BB_GIT_SHALLOW_REVS', '1.10.0')
+
+            self.fetch_shallow()
+
+            # Confirm that the history of 1.10.0 was removed
+            orig_revs = len(self.git('rev-list master', cwd=self.srcdir).splitlines())
+            revs = len(self.git('rev-list master').splitlines())
+            self.assertNotEqual(orig_revs, revs)
+            self.assertRefs(['master', 'origin/master'])
+            self.assertRevCount(orig_revs - 1758)

bitbake/lib/bb/tests/parse.py

@@ -83,7 +83,28 @@ unset B[flag]
         self.assertEqual(d.getVar("A"), None)
         self.assertEqual(d.getVarFlag("A","flag"), None)
         self.assertEqual(d.getVar("B"), "2")
-        
+
+    exporttest = """
+A = "a"
+export B = "b"
+export C
+exportD = "d"
+"""
+
+    def test_parse_exports(self):
+        f = self.parsehelper(self.exporttest)
+        d = bb.parse.handle(f.name, self.d)['']
+        self.assertEqual(d.getVar("A"), "a")
+        self.assertIsNone(d.getVarFlag("A", "export"))
+        self.assertEqual(d.getVar("B"), "b")
+        self.assertEqual(d.getVarFlag("B", "export"), 1)
+        self.assertIsNone(d.getVar("C"))
+        self.assertEqual(d.getVarFlag("C", "export"), 1)
+        self.assertIsNone(d.getVar("D"))
+        self.assertIsNone(d.getVarFlag("D", "export"))
+        self.assertEqual(d.getVar("exportD"), "d")
+        self.assertIsNone(d.getVarFlag("exportD", "export"))
+
 
     overridetest = """
 RRECOMMENDS_${PN} = "a"

bitbake/lib/bb/tinfoil.py

@@ -210,13 +210,17 @@ class TinfoilCookerAdapter:
 
 class Tinfoil:
 
-    def __init__(self, output=sys.stdout, tracking=False):
+    def __init__(self, output=sys.stdout, tracking=False, setup_logging=True):
         self.logger = logging.getLogger('BitBake')
         self.config_data = None
         self.cooker = None
         self.tracking = tracking
         self.ui_module = None
         self.server_connection = None
+        if setup_logging:
+            # This is the *client-side* logger, nothing to do with
+            # logging messages from the server
+            bb.msg.logger_create('BitBake', output)
 
     def __enter__(self):
         return self
@@ -224,12 +228,15 @@ class Tinfoil:
     def __exit__(self, type, value, traceback):
         self.shutdown()
 
-    def prepare(self, config_only=False, config_params=None, quiet=0):
+    def prepare(self, config_only=False, config_params=None, quiet=0, extra_features=None):
         if self.tracking:
             extrafeatures = [bb.cooker.CookerFeatures.BASEDATASTORE_TRACKING]
         else:
             extrafeatures = []
 
+        if extra_features:
+            extrafeatures += extra_features
+
         if not config_params:
             config_params = TinfoilConfigParameters(config_only=config_only, quiet=quiet)
 
@@ -238,7 +245,8 @@ class Tinfoil:
 
         server, self.server_connection, ui_module = setup_bitbake(config_params,
                             cookerconfig,
-                            extrafeatures)
+                            extrafeatures,
+                            setup_logging=False)
 
         self.ui_module = ui_module
 
@@ -359,14 +367,14 @@ class Tinfoil:
         skipped.
         """
         best = self.find_best_provider(pn)
-        if not best:
+        if not best or (len(best) > 3 and not best[3]):
             skiplist = self.get_skipped_recipes()
             taskdata = bb.taskdata.TaskData(None, skiplist=skiplist)
             skipreasons = taskdata.get_reasons(pn)
             if skipreasons:
-                raise bb.providers.NoProvider(skipreasons)
+                raise bb.providers.NoProvider('%s is unavailable:\n  %s' % (pn, '  \n'.join(skipreasons)))
             else:
-                raise bb.providers.NoProvider('Unable to find any recipe file matching %s' % pn)
+                raise bb.providers.NoProvider('Unable to find any recipe file matching "%s"' % pn)
         return best[3]
 
     def get_file_appends(self, fn):

bitbake/lib/bb/ui/buildinfohelper.py

@@ -1663,6 +1663,36 @@ class BuildInfoHelper(object):
                 break
         return endswith
 
+    def scan_task_artifacts(self, event):
+        """
+        The 'TaskArtifacts' event passes the manifest file content for the
+        tasks 'do_deploy', 'do_image_complete', 'do_populate_sdk', and
+        'do_populate_sdk_ext'. The first two will be implemented later.
+        """
+        task_vars = BuildInfoHelper._get_data_from_event(event)
+        task_name = task_vars['task'][task_vars['task'].find(':')+1:]
+        task_artifacts = task_vars['artifacts']
+
+        if task_name in ['do_populate_sdk', 'do_populate_sdk_ext']:
+            targets = [target for target in self.internal_state['targets'] \
+                if target.task == task_name[3:]]
+            if not targets:
+                logger.warning("scan_task_artifacts: SDK targets not found: %s\n", task_name)
+                return
+            for artifact_path in task_artifacts:
+                if not os.path.isfile(artifact_path):
+                    logger.warning("scan_task_artifacts: artifact file not found: %s\n", artifact_path)
+                    continue
+                for target in targets:
+                    # don't record the file if it's already been added
+                    # to this target
+                    matching_files = TargetSDKFile.objects.filter(
+                        target=target, file_name=artifact_path)
+                    if matching_files.count() == 0:
+                        artifact_size = os.stat(artifact_path).st_size
+                        self.orm_wrapper.save_target_sdk_file(
+                            target, artifact_path, artifact_size)
+
     def _get_image_files(self, deploy_dir_image, image_name, image_file_extensions):
         """
         Find files in deploy_dir_image whose basename starts with the

bitbake/lib/bb/ui/knotty.py

@@ -365,8 +365,9 @@ def main(server, eventHandler, params, tf = TerminalFilter):
     bb.msg.addDefaultlogFilter(errconsole, bb.msg.BBLogFilterStdErr)
     console.setFormatter(format)
     errconsole.setFormatter(format)
-    logger.addHandler(console)
-    logger.addHandler(errconsole)
+    if not bb.msg.has_console_handler(logger):
+        logger.addHandler(console)
+        logger.addHandler(errconsole)
 
     bb.utils.set_process_name("KnottyUI")
 

bitbake/lib/bb/ui/ncurses.py

@@ -297,7 +297,7 @@ class NCursesUI:
 #                            bb.error("log data follows (%s)" % logfile)
 #                            number_of_lines = data.getVar("BBINCLUDELOGS_LINES", d)
 #                            if number_of_lines:
-#                                subprocess.call('tail -n%s %s' % (number_of_lines, logfile), shell=True)
+#                                subprocess.check_call('tail -n%s %s' % (number_of_lines, logfile), shell=True)
 #                            else:
 #                                f = open(logfile, "r")
 #                                while True:

bitbake/lib/bb/ui/toasterui.py

@@ -438,9 +438,7 @@ def main(server, eventHandler, params):
                 elif event.type == "SetBRBE":
                     buildinfohelper.brbe = buildinfohelper._get_data_from_event(event)
                 elif event.type == "TaskArtifacts":
-                    # not implemented yet
-                    # see https://bugzilla.yoctoproject.org/show_bug.cgi?id=10283 for details
-                    pass
+                    buildinfohelper.scan_task_artifacts(event)
                 elif event.type == "OSErrorException":
                     logger.error(event)
                 else:

bitbake/lib/bb/utils.py

@@ -680,7 +680,7 @@ def remove(path, recurse=False):
             if _check_unsafe_delete_path(path):
                 raise Exception('bb.utils.remove: called with dangerous path "%s" and recurse=True, refusing to delete!' % path)
         # shutil.rmtree(name) would be ideal but its too slow
-        subprocess.call(['rm', '-rf'] + glob.glob(path))
+        subprocess.check_call(['rm', '-rf'] + glob.glob(path))
         return
     for name in glob.glob(path):
         try:
@@ -899,11 +899,20 @@ def copyfile(src, dest, newmtime = None, sstat = None):
         newmtime = sstat[stat.ST_MTIME]
     return newmtime
 
-def which(path, item, direction = 0, history = False):
+def which(path, item, direction = 0, history = False, executable=False):
     """
-    Locate a file in a PATH
+    Locate `item` in the list of paths `path` (colon separated string like $PATH).
+    If `direction` is non-zero then the list is reversed.
+    If `history` is True then the list of candidates also returned as result,history.
+    If `executable` is True then the candidate has to be an executable file,
+    otherwise the candidate simply has to exist.
     """
 
+    if executable:
+        is_candidate = lambda p: os.path.isfile(p) and os.access(p, os.X_OK)
+    else:
+        is_candidate = lambda p: os.path.exists(p)
+
     hist = []
     paths = (path or "").split(':')
     if direction != 0:
@@ -912,7 +921,7 @@ def which(path, item, direction = 0, history = False):
     for p in paths:
         next = os.path.join(p, item)
         hist.append(next)
-        if os.path.exists(next):
+        if is_candidate(next):
             if not os.path.isabs(next):
                 next = os.path.abspath(next)
             if history:

bitbake/lib/bblayers/action.py

@@ -1,7 +1,9 @@
 import fnmatch
 import logging
 import os
+import shutil
 import sys
+import tempfile
 
 import bb.utils
 
@@ -32,10 +34,26 @@ class ActionPlugin(LayerPlugin):
             sys.stderr.write("Unable to find bblayers.conf\n")
             return 1
 
-        notadded, _ = bb.utils.edit_bblayers_conf(bblayers_conf, layerdir, None)
-        if notadded:
-            for item in notadded:
-                sys.stderr.write("Specified layer %s is already in BBLAYERS\n" % item)
+        # Back up bblayers.conf to tempdir before we add layers
+        tempdir = tempfile.mkdtemp()
+        backup = tempdir + "/bblayers.conf.bak"
+        shutil.copy2(bblayers_conf, backup)
+
+        try:
+            notadded, _ = bb.utils.edit_bblayers_conf(bblayers_conf, layerdir, None)
+            if not (args.force or notadded):
+                try:
+                    self.tinfoil.parseRecipes()
+                except bb.tinfoil.TinfoilUIException:
+                    # Restore the back up copy of bblayers.conf
+                    shutil.copy2(backup, bblayers_conf)
+                    bb.fatal("Parse failure with the specified layer added")
+                else:
+                    for item in notadded:
+                        sys.stderr.write("Specified layer %s is already in BBLAYERS\n" % item)
+        finally:
+            # Remove the back up copy of bblayers.conf
+            shutil.rmtree(tempdir)
 
     def do_remove_layer(self, args):
         """Remove a layer from bblayers.conf."""

bitbake/lib/simplediff/LICENSE

@@ -0,0 +1,22 @@
+Copyright (c) 2008 - 2013 Paul Butler and contributors
+
+This sofware may be used under a zlib/libpng-style license:
+
+This software is provided 'as-is', without any express or implied warranty. In
+no event will the authors be held liable for any damages arising from the use
+of this software.
+
+Permission is granted to anyone to use this software for any purpose, including
+commercial applications, and to alter it and redistribute it freely, subject to
+the following restrictions:
+
+1. The origin of this software must not be misrepresented; you must not claim
+that you wrote the original software. If you use this software in a product, an
+acknowledgment in the product documentation would be appreciated but is not
+required.
+
+2. Altered source versions must be plainly marked as such, and must not be
+misrepresented as being the original software.
+
+3. This notice may not be removed or altered from any source distribution.
+

bitbake/lib/simplediff/__init__.py

@@ -0,0 +1,198 @@
+'''
+Simple Diff for Python version 1.0
+
+Annotate two versions of a list with the values that have been
+changed between the versions, similar to unix's `diff` but with
+a dead-simple Python interface.
+
+(C) Paul Butler 2008-2012 <http://www.paulbutler.org/>
+May be used and distributed under the zlib/libpng license
+<http://www.opensource.org/licenses/zlib-license.php>
+'''
+
+__all__ = ['diff', 'string_diff', 'html_diff']
+__version__ = '1.0'
+
+
+def diff(old, new):
+    '''
+    Find the differences between two lists. Returns a list of pairs, where the
+    first value is in ['+','-','='] and represents an insertion, deletion, or
+    no change for that list. The second value of the pair is the list
+    of elements.
+
+    Params:
+        old     the old list of immutable, comparable values (ie. a list
+                of strings)
+        new     the new list of immutable, comparable values
+   
+    Returns:
+        A list of pairs, with the first part of the pair being one of three
+        strings ('-', '+', '=') and the second part being a list of values from
+        the original old and/or new lists. The first part of the pair
+        corresponds to whether the list of values is a deletion, insertion, or
+        unchanged, respectively.
+
+    Examples:
+        >>> diff([1,2,3,4],[1,3,4])
+        [('=', [1]), ('-', [2]), ('=', [3, 4])]
+
+        >>> diff([1,2,3,4],[2,3,4,1])
+        [('-', [1]), ('=', [2, 3, 4]), ('+', [1])]
+
+        >>> diff('The quick brown fox jumps over the lazy dog'.split(),
+        ...      'The slow blue cheese drips over the lazy carrot'.split())
+        ... # doctest: +NORMALIZE_WHITESPACE
+        [('=', ['The']),
+         ('-', ['quick', 'brown', 'fox', 'jumps']),
+         ('+', ['slow', 'blue', 'cheese', 'drips']),
+         ('=', ['over', 'the', 'lazy']),
+         ('-', ['dog']),
+         ('+', ['carrot'])]
+
+    '''
+
+    # Create a map from old values to their indices
+    old_index_map = dict()
+    for i, val in enumerate(old):
+        old_index_map.setdefault(val,list()).append(i)
+
+    # Find the largest substring common to old and new.
+    # We use a dynamic programming approach here.
+    # 
+    # We iterate over each value in the `new` list, calling the
+    # index `inew`. At each iteration, `overlap[i]` is the
+    # length of the largest suffix of `old[:i]` equal to a suffix
+    # of `new[:inew]` (or unset when `old[i]` != `new[inew]`).
+    #
+    # At each stage of iteration, the new `overlap` (called
+    # `_overlap` until the original `overlap` is no longer needed)
+    # is built from the old one.
+    #
+    # If the length of overlap exceeds the largest substring
+    # seen so far (`sub_length`), we update the largest substring
+    # to the overlapping strings.
+
+    overlap = dict()
+    # `sub_start_old` is the index of the beginning of the largest overlapping
+    # substring in the old list. `sub_start_new` is the index of the beginning
+    # of the same substring in the new list. `sub_length` is the length that
+    # overlaps in both.
+    # These track the largest overlapping substring seen so far, so naturally
+    # we start with a 0-length substring.
+    sub_start_old = 0
+    sub_start_new = 0
+    sub_length = 0
+
+    for inew, val in enumerate(new):
+        _overlap = dict()
+        for iold in old_index_map.get(val,list()):
+            # now we are considering all values of iold such that
+            # `old[iold] == new[inew]`.
+            _overlap[iold] = (iold and overlap.get(iold - 1, 0)) + 1
+            if(_overlap[iold] > sub_length):
+                # this is the largest substring seen so far, so store its
+                # indices
+                sub_length = _overlap[iold]
+                sub_start_old = iold - sub_length + 1
+                sub_start_new = inew - sub_length + 1
+        overlap = _overlap
+
+    if sub_length == 0:
+        # If no common substring is found, we return an insert and delete...
+        return (old and [('-', old)] or []) + (new and [('+', new)] or [])
+    else:
+        # ...otherwise, the common substring is unchanged and we recursively
+        # diff the text before and after that substring
+        return diff(old[ : sub_start_old], new[ : sub_start_new]) + \
+               [('=', new[sub_start_new : sub_start_new + sub_length])] + \
+               diff(old[sub_start_old + sub_length : ],
+                       new[sub_start_new + sub_length : ])
+
+
+def string_diff(old, new):
+    '''
+    Returns the difference between the old and new strings when split on
+    whitespace. Considers punctuation a part of the word
+
+    This function is intended as an example; you'll probably want
+    a more sophisticated wrapper in practice.
+
+    Params:
+        old     the old string
+        new     the new string
+
+    Returns:
+        the output of `diff` on the two strings after splitting them
+        on whitespace (a list of change instructions; see the docstring
+        of `diff`)
+
+    Examples:
+        >>> string_diff('The quick brown fox', 'The fast blue fox')
+        ... # doctest: +NORMALIZE_WHITESPACE
+        [('=', ['The']),
+         ('-', ['quick', 'brown']),
+         ('+', ['fast', 'blue']),
+         ('=', ['fox'])]
+
+    '''
+    return diff(old.split(), new.split())
+
+
+def html_diff(old, new):
+    '''
+    Returns the difference between two strings (as in stringDiff) in
+    HTML format. HTML code in the strings is NOT escaped, so you
+    will get weird results if the strings contain HTML.
+
+    This function is intended as an example; you'll probably want
+    a more sophisticated wrapper in practice.
+
+    Params:
+        old     the old string
+        new     the new string
+
+    Returns:
+        the output of the diff expressed with HTML <ins> and <del>
+        tags.
+
+    Examples:
+        >>> html_diff('The quick brown fox', 'The fast blue fox')
+        'The <del>quick brown</del> <ins>fast blue</ins> fox'
+    '''
+    con = {'=': (lambda x: x),
+           '+': (lambda x: "<ins>" + x + "</ins>"),
+           '-': (lambda x: "<del>" + x + "</del>")}
+    return " ".join([(con[a])(" ".join(b)) for a, b in string_diff(old, new)])
+
+
+def check_diff(old, new):
+    '''
+    This tests that diffs returned by `diff` are valid. You probably won't
+    want to use this function, but it's provided for documentation and
+    testing.
+
+    A diff should satisfy the property that the old input is equal to the
+    elements of the result annotated with '-' or '=' concatenated together.
+    Likewise, the new input is equal to the elements of the result annotated
+    with '+' or '=' concatenated together. This function compares `old`,
+    `new`, and the results of `diff(old, new)` to ensure this is true.
+
+    Tests:
+        >>> check_diff('ABCBA', 'CBABA')
+        >>> check_diff('Foobarbaz', 'Foobarbaz')
+        >>> check_diff('Foobarbaz', 'Boobazbam')
+        >>> check_diff('The quick brown fox', 'Some quick brown car')
+        >>> check_diff('A thick red book', 'A quick blue book')
+        >>> check_diff('dafhjkdashfkhasfjsdafdasfsda', 'asdfaskjfhksahkfjsdha')
+        >>> check_diff('88288822828828288282828', '88288882882828282882828')
+        >>> check_diff('1234567890', '24689')
+    '''
+    old = list(old)
+    new = list(new)
+    result = diff(old, new)
+    _old = [val for (a, vals) in result if (a in '=-') for val in vals]
+    assert old == _old, 'Expected %s, got %s' % (old, _old)
+    _new = [val for (a, vals) in result if (a in '=+') for val in vals]
+    assert new == _new, 'Expected %s, got %s' % (new, _new)
+

bitbake/lib/toaster/orm/fixtures/oe-core.xml

@@ -8,9 +8,9 @@
 
   <!-- Bitbake versions which correspond to the metadata release -->
   <object model="orm.bitbakeversion" pk="1">
-    <field type="CharField" name="name">morty</field>
+    <field type="CharField" name="name">pyro</field>
     <field type="CharField" name="giturl">git://git.openembedded.org/bitbake</field>
-    <field type="CharField" name="branch">1.32</field>
+    <field type="CharField" name="branch">1.34</field>
   </object>
   <object model="orm.bitbakeversion" pk="2">
     <field type="CharField" name="name">HEAD</field>
@@ -25,11 +25,11 @@
 
   <!-- Releases available -->
   <object model="orm.release" pk="1">
-    <field type="CharField" name="name">morty</field>
-    <field type="CharField" name="description">Openembedded Morty</field>
+    <field type="CharField" name="name">pyro</field>
+    <field type="CharField" name="description">Openembedded Pyro</field>
     <field rel="ManyToOneRel" to="orm.bitbakeversion" name="bitbake_version">1</field>
-    <field type="CharField" name="branch_name">morty</field>
-    <field type="TextField" name="helptext">Toaster will run your builds using the tip of the &lt;a href=\"http://cgit.openembedded.org/openembedded-core/log/?h=morty\"&gt;OpenEmbedded Morty&lt;/a&gt; branch.</field>
+    <field type="CharField" name="branch_name">pyro</field>
+    <field type="TextField" name="helptext">Toaster will run your builds using the tip of the &lt;a href=\"http://cgit.openembedded.org/openembedded-core/log/?h=pyro\"&gt;OpenEmbedded Pyro&lt;/a&gt; branch.</field>
   </object>
   <object model="orm.release" pk="2">
     <field type="CharField" name="name">local</field>

bitbake/lib/toaster/orm/fixtures/poky.xml

@@ -8,9 +8,9 @@
 
   <!-- Bitbake versions which correspond to the metadata release -->
   <object model="orm.bitbakeversion" pk="1">
-    <field type="CharField" name="name">morty</field>
+    <field type="CharField" name="name">pyro</field>
     <field type="CharField" name="giturl">git://git.yoctoproject.org/poky</field>
-    <field type="CharField" name="branch">morty</field>
+    <field type="CharField" name="branch">pyro</field>
     <field type="CharField" name="dirpath">bitbake</field>
   </object>
   <object model="orm.bitbakeversion" pk="2">
@@ -29,11 +29,11 @@
 
   <!-- Releases available -->
   <object model="orm.release" pk="1">
-    <field type="CharField" name="name">morty</field>
-    <field type="CharField" name="description">Yocto Project 2.2 "Morty"</field>
+    <field type="CharField" name="name">pyro</field>
+    <field type="CharField" name="description">Yocto Project 2.3 "Pyro"</field>
     <field rel="ManyToOneRel" to="orm.bitbakeversion" name="bitbake_version">1</field>
-    <field type="CharField" name="branch_name">morty</field>
-    <field type="TextField" name="helptext">Toaster will run your builds using the tip of the &lt;a href="http://git.yoctoproject.org/cgit/cgit.cgi/poky/log/?h=morty"&gt;Yocto Project Morty branch&lt;/a&gt;.</field>
+    <field type="CharField" name="branch_name">pyro</field>
+    <field type="TextField" name="helptext">Toaster will run your builds using the tip of the &lt;a href="http://git.yoctoproject.org/cgit/cgit.cgi/poky/log/?h=pyro"&gt;Yocto Project Pyro branch&lt;/a&gt;.</field>
   </object>
   <object model="orm.release" pk="2">
     <field type="CharField" name="name">local</field>
@@ -102,7 +102,7 @@
     <field rel="ManyToOneRel" to="orm.layer" name="layer">1</field>
     <field type="IntegerField" name="layer_source">0</field>
     <field rel="ManyToOneRel" to="orm.release" name="release">1</field>
-    <field type="CharField" name="branch">morty</field>
+    <field type="CharField" name="branch">pyro</field>
     <field type="CharField" name="dirpath">meta</field>
   </object>
   <object model="orm.layer_version" pk="2">
@@ -130,7 +130,7 @@
     <field rel="ManyToOneRel" to="orm.layer" name="layer">2</field>
     <field type="IntegerField" name="layer_source">0</field>
     <field rel="ManyToOneRel" to="orm.release" name="release">1</field>
-    <field type="CharField" name="branch">morty</field>
+    <field type="CharField" name="branch">pyro</field>
     <field type="CharField" name="dirpath">meta-poky</field>
   </object>
   <object model="orm.layer_version" pk="5">
@@ -158,7 +158,7 @@
     <field rel="ManyToOneRel" to="orm.layer" name="layer">3</field>
     <field type="IntegerField" name="layer_source">0</field>
     <field rel="ManyToOneRel" to="orm.release" name="release">1</field>
-    <field type="CharField" name="branch">morty</field>
+    <field type="CharField" name="branch">pyro</field>
     <field type="CharField" name="dirpath">meta-yocto-bsp</field>
   </object>
   <object model="orm.layer_version" pk="8">

bitbake/lib/toaster/tests/builds/buildtest.py

@@ -41,6 +41,61 @@ logger = logging.getLogger("toaster")
 # want to wrap everything in a database transaction as an external process
 # (bitbake needs access to the database)
 
+def load_build_environment():
+    call_command('loaddata', 'settings.xml', app_label="orm")
+    call_command('loaddata', 'poky.xml', app_label="orm")
+
+    current_builddir = os.environ.get("BUILDDIR")
+    if current_builddir:
+        BuildTest.BUILDDIR = current_builddir
+    else:
+        # Setup a builddir based on default layout
+        # bitbake inside openebedded-core
+        oe_init_build_env_path = os.path.join(
+            os.path.dirname(os.path.abspath(__file__)),
+            os.pardir,
+            os.pardir,
+            os.pardir,
+            os.pardir,
+            os.pardir,
+            'oe-init-build-env'
+        )
+        if not os.path.exists(oe_init_build_env_path):
+            raise Exception("We had no BUILDDIR set and couldn't "
+                            "find oe-init-build-env to set this up "
+                            "ourselves please run oe-init-build-env "
+                            "before running these tests")
+
+        oe_init_build_env_path = os.path.realpath(oe_init_build_env_path)
+        cmd = "bash -c 'source oe-init-build-env %s'" % BuildTest.BUILDDIR
+        p = subprocess.Popen(
+            cmd,
+            cwd=os.path.dirname(oe_init_build_env_path),
+            shell=True,
+            stdout=subprocess.PIPE,
+            stderr=subprocess.PIPE)
+
+        output, err = p.communicate()
+        p.wait()
+
+        logger.info("oe-init-build-env %s %s" % (output, err))
+
+        os.environ['BUILDDIR'] = BuildTest.BUILDDIR
+
+    # Setup the path to bitbake we know where to find this
+    bitbake_path = os.path.join(
+        os.path.dirname(os.path.abspath(__file__)),
+        os.pardir,
+        os.pardir,
+        os.pardir,
+        os.pardir,
+        'bin',
+        'bitbake')
+    if not os.path.exists(bitbake_path):
+        raise Exception("Could not find bitbake at the expected path %s"
+                        % bitbake_path)
+
+    os.environ['BBBASEDIR'] = bitbake_path
 
 class BuildTest(unittest.TestCase):
 
@@ -59,60 +114,7 @@ class BuildTest(unittest.TestCase):
         if built:
             return built
 
-        call_command('loaddata', 'settings.xml', app_label="orm")
-        call_command('loaddata', 'poky.xml', app_label="orm")
-
-        current_builddir = os.environ.get("BUILDDIR")
-        if current_builddir:
-            BuildTest.BUILDDIR = current_builddir
-        else:
-            # Setup a builddir based on default layout
-            # bitbake inside openebedded-core
-            oe_init_build_env_path = os.path.join(
-                os.path.dirname(os.path.abspath(__file__)),
-                os.pardir,
-                os.pardir,
-                os.pardir,
-                os.pardir,
-                os.pardir,
-                'oe-init-build-env'
-            )
-            if not os.path.exists(oe_init_build_env_path):
-                raise Exception("We had no BUILDDIR set and couldn't "
-                                "find oe-init-build-env to set this up "
-                                "ourselves please run oe-init-build-env "
-                                "before running these tests")
-
-            oe_init_build_env_path = os.path.realpath(oe_init_build_env_path)
-            cmd = "bash -c 'source oe-init-build-env %s'" % BuildTest.BUILDDIR
-            p = subprocess.Popen(
-                cmd,
-                cwd=os.path.dirname(oe_init_build_env_path),
-                shell=True,
-                stdout=subprocess.PIPE,
-                stderr=subprocess.PIPE)
-
-            output, err = p.communicate()
-            p.wait()
-
-            logger.info("oe-init-build-env %s %s" % (output, err))
-
-            os.environ['BUILDDIR'] = BuildTest.BUILDDIR
-
-        # Setup the path to bitbake we know where to find this
-        bitbake_path = os.path.join(
-            os.path.dirname(os.path.abspath(__file__)),
-            os.pardir,
-            os.pardir,
-            os.pardir,
-            os.pardir,
-            'bin',
-            'bitbake')
-        if not os.path.exists(bitbake_path):
-            raise Exception("Could not find bitbake at the expected path %s"
-                            % bitbake_path)
-
-        os.environ['BBBASEDIR'] = bitbake_path
+        load_build_environment()
 
         BuildEnvironment.objects.get_or_create(
             betype=BuildEnvironment.TYPE_LOCAL,

bitbake/lib/toaster/tests/functional/functional_helpers.py

@@ -0,0 +1,122 @@
+#! /usr/bin/env python
+# ex:ts=4:sw=4:sts=4:et
+# -*- tab-width: 4; c-basic-offset: 4; indent-tabs-mode: nil -*-
+#
+# BitBake Toaster functional tests implementation
+#
+# Copyright (C) 2017 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 logging
+import subprocess
+import signal
+import time
+import re
+
+from tests.browser.selenium_helpers_base import SeleniumTestCaseBase
+from tests.builds.buildtest import load_build_environment
+
+logger = logging.getLogger("toaster")
+
+class SeleniumFunctionalTestCase(SeleniumTestCaseBase):
+    wait_toaster_time = 5
+
+    @classmethod
+    def setUpClass(cls):
+        # So that the buildinfo helper uses the test database'
+        if os.environ.get('DJANGO_SETTINGS_MODULE', '') != \
+            'toastermain.settings_test':
+            raise RuntimeError("Please initialise django with the tests settings:  " \
+                "DJANGO_SETTINGS_MODULE='toastermain.settings_test'")
+
+        load_build_environment()
+
+        # start toaster
+        cmd = "bash -c 'source toaster start'"
+        p = subprocess.Popen(
+            cmd,
+            cwd=os.environ.get("BUILDDIR"),
+            shell=True)
+        if p.wait() != 0:
+            raise RuntimeError("Can't initialize toaster")
+
+        super(SeleniumFunctionalTestCase, cls).setUpClass()
+        cls.live_server_url = 'http://localhost:8000/'
+
+    @classmethod
+    def tearDownClass(cls):
+        super(SeleniumFunctionalTestCase, cls).tearDownClass()
+
+        # XXX: source toaster stop gets blocked, to review why?
+        # from now send SIGTERM by hand
+        time.sleep(cls.wait_toaster_time)
+        builddir = os.environ.get("BUILDDIR")
+
+        with open(os.path.join(builddir, '.toastermain.pid'), 'r') as f:
+            toastermain_pid = int(f.read())
+            os.kill(toastermain_pid, signal.SIGTERM)
+        with open(os.path.join(builddir, '.runbuilds.pid'), 'r') as f:
+            runbuilds_pid = int(f.read())
+            os.kill(runbuilds_pid, signal.SIGTERM)
+
+
+    def get_URL(self):
+         rc=self.get_page_source()
+         project_url=re.search("(projectPageUrl\s:\s\")(.*)(\",)",rc)
+         return project_url.group(2)
+
+
+    def find_element_by_link_text_in_table(self, table_id, link_text):
+        """
+        Assume there're multiple suitable "find_element_by_link_text".
+        In this circumstance we need to specify "table".
+        """
+        try:
+            table_element = self.get_table_element(table_id)
+            element = table_element.find_element_by_link_text(link_text)
+        except NoSuchElementException as e:
+            print('no element found')
+            raise
+        return element
+
+    def get_table_element(self, table_id, *coordinate):
+        if len(coordinate) == 0:
+#return whole-table element
+            element_xpath = "//*[@id='" + table_id + "']"
+            try:
+                element = self.driver.find_element_by_xpath(element_xpath)
+            except NoSuchElementException as e:
+                raise
+            return element
+        row = coordinate[0]
+
+        if len(coordinate) == 1:
+#return whole-row element
+            element_xpath = "//*[@id='" + table_id + "']/tbody/tr[" + str(row) + "]"
+            try:
+                element = self.driver.find_element_by_xpath(element_xpath)
+            except NoSuchElementException as e:
+                return False
+            return element
+#now we are looking for an element with specified X and Y
+        column = coordinate[1]
+
+        element_xpath = "//*[@id='" + table_id + "']/tbody/tr[" + str(row) + "]/td[" + str(column) + "]"
+        try:
+            element = self.driver.find_element_by_xpath(element_xpath)
+        except NoSuchElementException as e:
+            return False
+        return element

bitbake/lib/toaster/tests/functional/test_functional_basic.py

@@ -0,0 +1,243 @@
+#! /usr/bin/env python
+# ex:ts=4:sw=4:sts=4:et
+# -*- tab-width: 4; c-basic-offset: 4; indent-tabs-mode: nil -*-
+#
+# BitBake Toaster functional tests implementation
+#
+# Copyright (C) 2017 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 time
+import re
+from tests.functional.functional_helpers import SeleniumFunctionalTestCase
+from orm.models import Project
+
+class FuntionalTestBasic(SeleniumFunctionalTestCase):
+
+#   testcase (1514)
+    def test_create_slenium_project(self):
+        project_name = 'selenium-project'
+        self.get('')
+        self.driver.find_element_by_link_text("To start building, create your first Toaster project").click()
+        self.driver.find_element_by_id("new-project-name").send_keys(project_name)
+        self.driver.find_element_by_id('projectversion').click()
+        self.driver.find_element_by_id("create-project-button").click()
+        element = self.wait_until_visible('#project-created-notification')
+        self.assertTrue(self.element_exists('#project-created-notification'),'Project creation notification not shown')
+        self.assertTrue(project_name in element.text,
+                        "New project name not in new project notification")
+        self.assertTrue(Project.objects.filter(name=project_name).count(),
+                        "New project not found in database")
+
+ #  testcase (1515)
+    def test_verify_left_bar_menu(self):
+        self.get('')
+        self.wait_until_visible('#projectstable')
+        self.find_element_by_link_text_in_table('projectstable', 'selenium-project').click()
+        self.assertTrue(self.element_exists('#config-nav'),'Configuration Tab does not exist')
+        project_URL=self.get_URL()
+        self.driver.find_element_by_xpath('//a[@href="'+project_URL+'"]').click()
+
+        try:
+            self.driver.find_element_by_xpath("//*[@id='config-nav']/ul/li/a[@href="+'"'+project_URL+'customimages/"'+"]").click()
+            self.assertTrue(re.search("Custom images",self.driver.find_element_by_xpath("//div[@class='col-md-10']").text),'Custom images information is not loading properly')
+        except:
+            self.fail(msg='No Custom images tab available')
+
+        try:
+            self.driver.find_element_by_xpath("//*[@id='config-nav']/ul/li/a[@href="+'"'+project_URL+'images/"'+"]").click()
+            self.assertTrue(re.search("Compatible image recipes",self.driver.find_element_by_xpath("//div[@class='col-md-10']").text),'The Compatible image recipes information is not loading properly')
+        except:
+            self.fail(msg='No Compatible image tab available')
+
+        try:
+            self.driver.find_element_by_xpath("//*[@id='config-nav']/ul/li/a[@href="+'"'+project_URL+'softwarerecipes/"'+"]").click()
+            self.assertTrue(re.search("Compatible software recipes",self.driver.find_element_by_xpath("//div[@class='col-md-10']").text),'The Compatible software recipe information is not loading properly')
+        except:
+            self.fail(msg='No Compatible software recipe tab available')
+
+        try:
+            self.driver.find_element_by_xpath("//*[@id='config-nav']/ul/li/a[@href="+'"'+project_URL+'machines/"'+"]").click()
+            self.assertTrue(re.search("Compatible machines",self.driver.find_element_by_xpath("//div[@class='col-md-10']").text),'The Compatible machine information is not loading properly')
+        except:
+            self.fail(msg='No Compatible machines tab available')
+
+        try:
+            self.driver.find_element_by_xpath("//*[@id='config-nav']/ul/li/a[@href="+'"'+project_URL+'layers/"'+"]").click()
+            self.assertTrue(re.search("Compatible layers",self.driver.find_element_by_xpath("//div[@class='col-md-10']").text),'The Compatible layer information is not loading properly')
+        except:
+            self.fail(msg='No Compatible layers tab available')
+
+        try:
+            self.driver.find_element_by_xpath("//*[@id='config-nav']/ul/li/a[@href="+'"'+project_URL+'configuration"'+"]").click()
+            self.assertTrue(re.search("Bitbake variables",self.driver.find_element_by_xpath("//div[@class='col-md-10']").text),'The Bitbake variables information is not loading properly')
+        except:
+            self.fail(msg='No Bitbake variables tab available')
+
+#   testcase (1516)
+    def test_review_configuration_information(self):
+        self.get('')
+        self.driver.find_element_by_xpath("//div[@id='global-nav']/ul/li/a[@href="+'"'+'/toastergui/projects/'+'"'+"]").click()
+        self.wait_until_visible('#projectstable')
+        self.find_element_by_link_text_in_table('projectstable', 'selenium-project').click()
+        project_URL=self.get_URL()
+
+        try:
+           self.assertTrue(self.element_exists('#machine-section'),'Machine section for the project configuration page does not exist')
+           self.assertTrue(re.search("qemux86",self.driver.find_element_by_xpath("//span[@id='project-machine-name']").text),'The machine type is not assigned')
+           self.driver.find_element_by_xpath("//span[@id='change-machine-toggle']").click()
+           self.wait_until_visible('#select-machine-form')
+           self.wait_until_visible('#cancel-machine-change')
+           self.driver.find_element_by_xpath("//form[@id='select-machine-form']/a[@id='cancel-machine-change']").click()
+        except:
+           self.fail(msg='The machine information is wrong in the configuration page')
+
+        try:
+           self.driver.find_element_by_id('no-most-built')
+        except:
+           self.fail(msg='No Most built information in project detail page')
+
+        try:
+           self.assertTrue(re.search("Yocto Project master",self.driver.find_element_by_xpath("//span[@id='project-release-title']").text),'The project release is not defined')
+        except:
+           self.fail(msg='No project release title information in project detail page')
+
+        try:
+           self.driver.find_element_by_xpath("//div[@id='layer-container']")
+           self.assertTrue(re.search("3",self.driver.find_element_by_id("project-layers-count").text),'There should be 3 layers listed in the layer count')
+           layer_list = self.driver.find_element_by_id("layers-in-project-list")
+           layers = layer_list.find_elements_by_tag_name("li")
+           for layer in layers:
+               if re.match ("openembedded-core",layer.text):
+                    print ("openembedded-core layer is a default layer in the project configuration")
+               elif re.match ("meta-poky",layer.text):
+                  print ("meta-poky layer is a default layer in the project configuration")
+               elif re.match ("meta-yocto-bsp",layer.text):
+                  print ("meta-yocto-bsp is a default layer in the project configuratoin")
+               else:
+                  self.fail(msg='default layers are missing from the project configuration')
+        except:
+           self.fail(msg='No Layer information in project detail page')
+
+#   testcase (1517)
+    def test_verify_machine_information(self):
+        self.get('')
+        self.driver.find_element_by_xpath("//div[@id='global-nav']/ul/li/a[@href="+'"'+'/toastergui/projects/'+'"'+"]").click()
+        self.wait_until_visible('#projectstable')
+        self.find_element_by_link_text_in_table('projectstable', 'selenium-project').click()
+
+        try:
+            self.assertTrue(self.element_exists('#machine-section'),'Machine section for the project configuration page does not exist')
+            self.assertTrue(re.search("qemux86",self.driver.find_element_by_id("project-machine-name").text),'The machine type is not assigned')
+            self.driver.find_element_by_id("change-machine-toggle").click()
+            self.wait_until_visible('#select-machine-form')
+            self.wait_until_visible('#cancel-machine-change')
+            self.driver.find_element_by_id("cancel-machine-change").click()
+        except:
+            self.fail(msg='The machine information is wrong in the configuration page')
+
+#   testcase (1518)
+    def test_verify_most_built_recipes_information(self):
+        self.get('')
+        self.driver.find_element_by_xpath("//div[@id='global-nav']/ul/li/a[@href="+'"'+'/toastergui/projects/'+'"'+"]").click()
+        self.wait_until_visible('#projectstable')
+        self.find_element_by_link_text_in_table('projectstable', 'selenium-project').click()
+        project_URL=self.get_URL()
+
+        try:
+            self.assertTrue(re.search("You haven't built any recipes yet",self.driver.find_element_by_id("no-most-built").text),'Default message of no builds is not present')
+            self.driver.find_element_by_xpath("//div[@id='no-most-built']/p/a[@href="+'"'+project_URL+'images/"'+"]").click()
+            self.assertTrue(re.search("Compatible image recipes",self.driver.find_element_by_xpath("//div[@class='col-md-10']").text),'The Choose a recipe to build link  is not working  properly')
+        except:
+            self.fail(msg='No Most built information in project detail page')
+
+#   testcase (1519)
+    def test_verify_project_release_information(self):
+        self.get('')
+        self.driver.find_element_by_xpath("//div[@id='global-nav']/ul/li/a[@href="+'"'+'/toastergui/projects/'+'"'+"]").click()
+        self.wait_until_visible('#projectstable')
+        self.find_element_by_link_text_in_table('projectstable', 'selenium-project').click()
+
+        try:
+            self.assertTrue(re.search("Yocto Project master",self.driver.find_element_by_id("project-release-title").text),'The project release is not defined')
+        except:
+            self.fail(msg='No project release title information in project detail page')
+
+#   testcase (1520)
+    def test_verify_layer_information(self):
+        self.get('')
+        self.driver.find_element_by_xpath("//div[@id='global-nav']/ul/li/a[@href="+'"'+'/toastergui/projects/'+'"'+"]").click()
+        self.wait_until_visible('#projectstable')
+        self.find_element_by_link_text_in_table('projectstable', 'selenium-project').click()
+        project_URL=self.get_URL()
+
+        try:
+           self.driver.find_element_by_xpath("//div[@id='layer-container']")
+           self.assertTrue(re.search("3",self.driver.find_element_by_id("project-layers-count").text),'There should be 3 layers listed in the layer count')
+           layer_list = self.driver.find_element_by_id("layers-in-project-list")
+           layers = layer_list.find_elements_by_tag_name("li")
+
+           for layer in layers:
+               if re.match ("openembedded-core",layer.text):
+                    print ("openembedded-core layer is a default layer in the project configuration")
+               elif re.match ("meta-poky",layer.text):
+                  print ("meta-poky layer is a default layer in the project configuration")
+               elif re.match ("meta-yocto-bsp",layer.text):
+                  print ("meta-yocto-bsp is a default layer in the project configuratoin")
+               else:
+                  self.fail(msg='default layers are missing from the project configuration')
+
+           self.driver.find_element_by_xpath("//input[@id='layer-add-input']")
+           self.driver.find_element_by_xpath("//button[@id='add-layer-btn']")
+           self.driver.find_element_by_xpath("//div[@id='layer-container']/form[@class='form-inline']/p/a[@id='view-compatible-layers']")
+           self.driver.find_element_by_xpath("//div[@id='layer-container']/form[@class='form-inline']/p/a[@href="+'"'+project_URL+'importlayer"'+"]")
+        except:
+            self.fail(msg='No Layer information in project detail page')
+
+#   testcase (1521)
+    def test_verify_project_detail_links(self):
+        self.get('')
+        self.driver.find_element_by_xpath("//div[@id='global-nav']/ul/li/a[@href="+'"'+'/toastergui/projects/'+'"'+"]").click()
+        self.wait_until_visible('#projectstable')
+        self.find_element_by_link_text_in_table('projectstable', 'selenium-project').click()
+        project_URL=self.get_URL()
+
+        self.driver.find_element_by_xpath("//div[@id='project-topbar']/ul[@class='nav nav-tabs']/li[@id='topbar-configuration-tab']/a[@href="+'"'+project_URL+'"'+"]").click()
+        self.assertTrue(re.search("Configuration",self.driver.find_element_by_xpath("//div[@id='project-topbar']/ul[@class='nav nav-tabs']/li[@id='topbar-configuration-tab']/a[@href="+'"'+project_URL+'"'+"]").text), 'Configuration tab in project topbar is misspelled')
+
+        try:
+            self.driver.find_element_by_xpath("//div[@id='project-topbar']/ul[@class='nav nav-tabs']/li/a[@href="+'"'+project_URL+'builds/"'+"]").click()
+            self.assertTrue(re.search("Builds",self.driver.find_element_by_xpath("//div[@id='project-topbar']/ul[@class='nav nav-tabs']/li/a[@href="+'"'+project_URL+'builds/"'+"]").text), 'Builds tab in project topbar is misspelled')
+            self.driver.find_element_by_xpath("//div[@id='empty-state-projectbuildstable']")
+        except:
+            self.fail(msg='Builds tab information is not present')
+
+        try:
+            self.driver.find_element_by_xpath("//div[@id='project-topbar']/ul[@class='nav nav-tabs']/li/a[@href="+'"'+project_URL+'importlayer"'+"]").click()
+            self.assertTrue(re.search("Import layer",self.driver.find_element_by_xpath("//div[@id='project-topbar']/ul[@class='nav nav-tabs']/li/a[@href="+'"'+project_URL+'importlayer"'+"]").text), 'Import layer tab in project topbar is misspelled')
+            self.driver.find_element_by_xpath("//fieldset[@id='repo-select']")
+            self.driver.find_element_by_xpath("//fieldset[@id='git-repo']")
+        except:
+            self.fail(msg='Import layer tab not loading properly')
+
+        try:
+            self.driver.find_element_by_xpath("//div[@id='project-topbar']/ul[@class='nav nav-tabs']/li/a[@href="+'"'+project_URL+'newcustomimage/"'+"]").click()
+            self.assertTrue(re.search("New custom image",self.driver.find_element_by_xpath("//div[@id='project-topbar']/ul[@class='nav nav-tabs']/li/a[@href="+'"'+project_URL+'newcustomimage/"'+"]").text), 'New custom image tab in project topbar is misspelled')
+            self.assertTrue(re.search("Select the image recipe you want to customise",self.driver.find_element_by_xpath("//div[@class='col-md-12']/h2").text),'The new custom image tab is not loading correctly')
+        except:
+            self.fail(msg='New custom image tab not loading properly')
+
+
+

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

@@ -12,6 +12,8 @@ function projectPageInit(ctx) {
   var machineChangeFormToggle = $("#change-machine-toggle");
   var machineNameTitle = $("#project-machine-name");
   var machineChangeCancel = $("#cancel-machine-change");
+  var machineInputForm = $("#machine-input-form");
+  var invalidMachineNameHelp = $("#invalid-machine-name-help");
 
   var freqBuildBtn =  $("#freq-build-btn");
   var freqBuildList = $("#freq-build-list");
@@ -208,8 +210,23 @@ function projectPageInit(ctx) {
 
 
   /* Change machine functionality */
+  machineChangeInput.keyup(function(){
+    if ($(this).val().indexOf(' ') >= 0) {
+        machineChangeBtn.attr("disabled", "disabled");
+        invalidMachineNameHelp.show();
+        machineInputForm.addClass('has-error');
+    } else {
+        machineChangeBtn.removeAttr("disabled");
+        invalidMachineNameHelp.hide();
+        machineInputForm.removeClass('has-error');
+    }
+  });
 
   machineChangeFormToggle.click(function(){
+    machineChangeInput.val(machineNameTitle.text());
+    machineChangeBtn.removeAttr("disabled");
+    invalidMachineNameHelp.hide();
+    machineInputForm.removeClass('has-error');
     machineForm.slideDown();
     machineNameTitle.hide();
     $(this).hide();

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

@@ -708,7 +708,7 @@ function tableInit(ctx){
             if (action) {
               // Setup the current selected filter; default to 'all' if
               // no current filter selected
-              var radioInput = action.find('input[name]="filter"]');
+              var radioInput = action.find('input[name="filter"]');
               if ((tableParams.filter &&
                   tableParams.filter === radioInput.val()) ||
                   filterActionData.action_name == 'all') {

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

@@ -7,8 +7,8 @@
 <a class="btn btn-default btn-block layerbtn
 layer-add-{{data.layer_version.id}}" data-layer='{ "id":
    {{data.layer_version.id}}, "name":  "{{data.layer_version.layer.name}}",
-   "layerdetailurl": "{%url 'layerdetails' extra.pid data.layer_version.id %},
-   "xhrLayerUrl": "{% url "xhr_layer" extra.pid data.pk %}",
+   "layerdetailurl": "{%url 'layerdetails' extra.pid data.layer_version.id %}",
+   "xhrLayerUrl": "{% url "xhr_layer" extra.pid data.layer_version.id %}"
    }' data-directive="add"
     {% if data.layer_version.pk in extra.current_layers %}
     style="display:none;"

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

@@ -67,11 +67,12 @@
 
       <form id="select-machine-form" style="display:none;" class="form-inline">
         <span class="help-block">Machine suggestions come from the list of layers added to your project. If you don't see the machine you are looking for, <a href="{% url 'projectmachines' project.id %}">check the full list of machines</a></span>
-        <div class="form-group">
+        <div class="form-group" id="machine-input-form">
           <input class="form-control" id="machine-change-input" autocomplete="off" value="" data-provide="typeahead" data-minlength="1" data-autocomplete="off" type="text">
         </div>
         <button id="machine-change-btn" class="btn btn-default" type="button">Save</button>
         <a href="#" id="cancel-machine-change" class="btn btn-link">Cancel</a>
+        <span class="help-block text-danger" id="invalid-machine-name-help" style="display:none">A valid machine name cannot include spaces.</span>
         <p class="form-link"><a href="{% url 'projectmachines' project.id %}">View compatible machines</a></p>
       </form>
     </div>

documentation/bsp-guide/bsp-guide.xml

@@ -118,6 +118,11 @@
                 <date>May 2017</date>
                 <revremark>Released with the Yocto Project 2.3 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>2.4</revnumber>
+                <date>Usually October</date>
+                <revremark>Released with the Yocto Project 2.4 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>

documentation/bsp-guide/bsp.xml

@@ -352,135 +352,139 @@
             </para>
 
             <section id="bsp-filelayout-license">
-            <title>License Files</title>
+                <title>License Files</title>
 
-            <para>
-                You can find these files in the BSP Layer at:
-                <literallayout class='monospaced'>
+                <para>
+                    You can find these files in the BSP Layer at:
+                    <literallayout class='monospaced'>
      meta-<replaceable>bsp_name</replaceable>/<replaceable>bsp_license_file</replaceable>
-                </literallayout>
-            </para>
+                    </literallayout>
+                </para>
 
-            <para>
-                These optional files satisfy licensing requirements for the BSP.
-                The type or types of files here can vary depending on the licensing requirements.
-                For example, in the Raspberry Pi BSP all licensing requirements are handled with the
-                <filename>COPYING.MIT</filename> file.
-            </para>
+                <para>
+                    These optional files satisfy licensing requirements for the BSP.
+                    The type or types of files here can vary depending on the licensing requirements.
+                    For example, in the Raspberry Pi BSP all licensing requirements are handled with the
+                    <filename>COPYING.MIT</filename> file.
+                </para>
 
-            <para>
-                Licensing files can be MIT, BSD, GPLv*, and so forth.
-                These files are recommended for the BSP but are optional and totally up to the BSP developer.
-            </para>
+                <para>
+                    Licensing files can be MIT, BSD, GPLv*, and so forth.
+                    These files are recommended for the BSP but are optional and totally up to the BSP developer.
+                </para>
             </section>
 
             <section id="bsp-filelayout-readme">
-            <title>README File</title>
-            <para>
-                You can find this file in the BSP Layer at:
-                <literallayout class='monospaced'>
+                <title>README File</title>
+
+                <para>
+                    You can find this file in the BSP Layer at:
+                    <literallayout class='monospaced'>
      meta-<replaceable>bsp_name</replaceable>/README
-                </literallayout>
-            </para>
+                    </literallayout>
+                </para>
 
-            <para>
-                This file provides information on how to boot the live images that are optionally
-                included in the <filename>binary/</filename> directory.
-                The <filename>README</filename> file also provides special information needed for
-                building the image.
-            </para>
+                <para>
+                    This file provides information on how to boot the live images that are optionally
+                    included in the <filename>binary/</filename> directory.
+                    The <filename>README</filename> file also provides special information needed for
+                    building the image.
+                </para>
 
-            <para>
-                At a minimum, the <filename>README</filename> file must
-                contain a list of dependencies, such as the names of
-                any other layers on which the BSP depends and the name of
-                the BSP maintainer with his or her contact information.
-            </para>
+                <para>
+                    At a minimum, the <filename>README</filename> file must
+                    contain a list of dependencies, such as the names of
+                    any other layers on which the BSP depends and the name of
+                    the BSP maintainer with his or her contact information.
+                </para>
             </section>
 
             <section id="bsp-filelayout-readme-sources">
-            <title>README.sources File</title>
-            <para>
-                You can find this file in the BSP Layer at:
-                <literallayout class='monospaced'>
-     meta-<replaceable>bsp_name</replaceable>/README.sources
-                </literallayout>
-            </para>
+                <title>README.sources File</title>
 
-            <para>
-                This file provides information on where to locate the BSP
-                source files used to build the images (if any) that reside in
-                <filename>meta-<replaceable>bsp_name</replaceable>/binary</filename>.
-                Images in the <filename>binary</filename> would be images
-                released with the BSP.
-                The information in the <filename>README.sources</filename>
-                file also helps you find the
-                <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
-                used to generate the images that ship with the BSP.
-                <note>
-                    If the BSP's <filename>binary</filename> directory is
-                    missing or the directory has no images, an existing
-                    <filename>README.sources</filename> file is
-                    meaningless.
-                </note>
-            </para>
+                <para>
+                    You can find this file in the BSP Layer at:
+                    <literallayout class='monospaced'>
+     meta-<replaceable>bsp_name</replaceable>/README.sources
+                    </literallayout>
+                </para>
+
+                <para>
+                    This file provides information on where to locate the BSP
+                    source files used to build the images (if any) that reside in
+                    <filename>meta-<replaceable>bsp_name</replaceable>/binary</filename>.
+                    Images in the <filename>binary</filename> would be images
+                    released with the BSP.
+                    The information in the <filename>README.sources</filename>
+                    file also helps you find the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
+                    used to generate the images that ship with the BSP.
+                    <note>
+                        If the BSP's <filename>binary</filename> directory is
+                        missing or the directory has no images, an existing
+                        <filename>README.sources</filename> file is
+                        meaningless.
+                    </note>
+                </para>
             </section>
 
             <section id="bsp-filelayout-binary">
-            <title>Pre-built User Binaries</title>
-            <para>
-                You can find these files in the BSP Layer at:
-                <literallayout class='monospaced'>
+                <title>Pre-built User Binaries</title>
+
+                <para>
+                    You can find these files in the BSP Layer at:
+                    <literallayout class='monospaced'>
      meta-<replaceable>bsp_name</replaceable>/binary/<replaceable>bootable_images</replaceable>
-                </literallayout>
-            </para>
+                    </literallayout>
+                </para>
 
-            <para>
-                This optional area contains useful pre-built kernels and
-                user-space filesystem images released with the BSP that are
-                appropriate to the target system.
-                This directory typically contains graphical (e.g. Sato) and
-                minimal live images when the BSP tarball has been created and
-                made available in the
-                <ulink url='&YOCTO_HOME_URL;'>Yocto Project</ulink> website.
-                You can use these kernels and images to get a system running
-                and quickly get started on development tasks.
-            </para>
+                <para>
+                    This optional area contains useful pre-built kernels and
+                    user-space filesystem images released with the BSP that are
+                    appropriate to the target system.
+                    This directory typically contains graphical (e.g. Sato) and
+                    minimal live images when the BSP tarball has been created and
+                    made available in the
+                    <ulink url='&YOCTO_HOME_URL;'>Yocto Project</ulink> website.
+                    You can use these kernels and images to get a system running
+                    and quickly get started on development tasks.
+                </para>
 
-            <para>
-                The exact types of binaries present are highly
-                hardware-dependent.
-                The <filename>README</filename> file should be present in the
-                BSP Layer and it will explain how to use the images with the
-                target hardware.
-                Additionally, the <filename>README.sources</filename> file
-                should be present to locate the sources used to build the
-                images and provide information on the Metadata.
-            </para>
+                <para>
+                    The exact types of binaries present are highly
+                    hardware-dependent.
+                    The <filename>README</filename> file should be present in the
+                    BSP Layer and it will explain how to use the images with the
+                    target hardware.
+                    Additionally, the <filename>README.sources</filename> file
+                    should be present to locate the sources used to build the
+                    images and provide information on the Metadata.
+                </para>
             </section>
 
             <section id='bsp-filelayout-layer'>
-            <title>Layer Configuration File</title>
-            <para>
-                You can find this file in the BSP Layer at:
-                <literallayout class='monospaced'>
+                <title>Layer Configuration File</title>
+
+                <para>
+                    You can find this file in the BSP Layer at:
+                    <literallayout class='monospaced'>
      meta-<replaceable>bsp_name</replaceable>/conf/layer.conf
-                </literallayout>
-            </para>
+                    </literallayout>
+                </para>
 
-            <para>
-                The <filename>conf/layer.conf</filename> file identifies the file structure as a
-                layer, identifies the
-                contents of the layer, and contains information about how the build
-                system should use it.
-                Generally, a standard boilerplate file such as the following works.
-                In the following example, you would replace "<replaceable>bsp</replaceable>" and
-                "<replaceable>_bsp</replaceable>" with the actual name
-                of the BSP (i.e. <replaceable>bsp_name</replaceable> from the example template).
-            </para>
+                <para>
+                    The <filename>conf/layer.conf</filename> file identifies the file structure as a
+                    layer, identifies the
+                    contents of the layer, and contains information about how the build
+                    system should use it.
+                    Generally, a standard boilerplate file such as the following works.
+                    In the following example, you would replace "<replaceable>bsp</replaceable>" and
+                    "<replaceable>_bsp</replaceable>" with the actual name
+                    of the BSP (i.e. <replaceable>bsp_name</replaceable> from the example template).
+                </para>
 
-            <para>
-               <literallayout class='monospaced'>
+                <para>
+                   <literallayout class='monospaced'>
      # We have a conf and classes directory, add to BBPATH
      BBPATH .= ":${LAYERDIR}"
 
@@ -493,13 +497,13 @@
      BBFILE_PRIORITY_<replaceable>bsp</replaceable> = "6"
 
      LAYERDEPENDS_<replaceable>bsp</replaceable> = "intel"
-                </literallayout>
-            </para>
+                    </literallayout>
+                </para>
 
-            <para>
-                To illustrate the string substitutions, here are the corresponding statements
-                from the Raspberry Pi <filename>conf/layer.conf</filename> file:
-               <literallayout class='monospaced'>
+                <para>
+                    To illustrate the string substitutions, here are the corresponding statements
+                    from the Raspberry Pi <filename>conf/layer.conf</filename> file:
+                   <literallayout class='monospaced'>
      # We have a conf and classes directory, append to BBPATH
      BBPATH .= ":${LAYERDIR}"
 
@@ -513,316 +517,196 @@
 
      # Additional license directories.
      LICENSE_PATH += "${LAYERDIR}/files/custom-licenses"
-                </literallayout>
-            </para>
+                    </literallayout>
+                </para>
 
-            <para>
-                This file simply makes
-                <ulink url='&YOCTO_DOCS_DEV_URL;#bitbake-term'>BitBake</ulink>
-                aware of the recipes and configuration directories.
-                The file must exist so that the OpenEmbedded build system can recognize the BSP.
-            </para>
+                <para>
+                    This file simply makes
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#bitbake-term'>BitBake</ulink>
+                    aware of the recipes and configuration directories.
+                    The file must exist so that the OpenEmbedded build system can recognize the BSP.
+                </para>
             </section>
 
             <section id="bsp-filelayout-machine">
-            <title>Hardware Configuration Options</title>
-            <para>
-                You can find these files in the BSP Layer at:
-                <literallayout class='monospaced'>
+                <title>Hardware Configuration Options</title>
+
+                <para>
+                    You can find these files in the BSP Layer at:
+                    <literallayout class='monospaced'>
      meta-<replaceable>bsp_name</replaceable>/conf/machine/*.conf
-                </literallayout>
-            </para>
+                    </literallayout>
+                </para>
 
-            <para>
-                The machine files bind together all the information contained elsewhere
-                in the BSP into a format that the build system can understand.
-                If the BSP supports multiple machines, multiple machine configuration files
-                can be present.
-                These filenames correspond to the values to which users have set the
-                <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink> variable.
-            </para>
+                <para>
+                    The machine files bind together all the information contained elsewhere
+                    in the BSP into a format that the build system can understand.
+                    If the BSP supports multiple machines, multiple machine configuration files
+                    can be present.
+                    These filenames correspond to the values to which users have set the
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink> variable.
+                </para>
 
-            <para>
-                These files define things such as the kernel package to use
-                (<ulink url='&YOCTO_DOCS_REF_URL;#var-PREFERRED_PROVIDER'><filename>PREFERRED_PROVIDER</filename></ulink>
-                of virtual/kernel), the hardware drivers to
-                include in different types of images, any special software components
-                that are needed, any bootloader information, and also any special image
-                format requirements.
-            </para>
+                <para>
+                    These files define things such as the kernel package to use
+                    (<ulink url='&YOCTO_DOCS_REF_URL;#var-PREFERRED_PROVIDER'><filename>PREFERRED_PROVIDER</filename></ulink>
+                    of virtual/kernel), the hardware drivers to
+                    include in different types of images, any special software components
+                    that are needed, any bootloader information, and also any special image
+                    format requirements.
+                </para>
 
-            <para>
-                Each BSP Layer requires at least one machine file.
-                However, you can supply more than one file.
-            </para>
+                <para>
+                    Each BSP Layer requires at least one machine file.
+                    However, you can supply more than one file.
+                </para>
 
-            <para>
-                This configuration file could also include a hardware "tuning"
-                file that is commonly used to define the package architecture
-                and specify optimization flags, which are carefully chosen
-                to give best performance on a given processor.
-            </para>
+                <para>
+                    This configuration file could also include a hardware "tuning"
+                    file that is commonly used to define the package architecture
+                    and specify optimization flags, which are carefully chosen
+                    to give best performance on a given processor.
+                </para>
 
-            <para>
-                Tuning files are found in the <filename>meta/conf/machine/include</filename>
-                directory within the
-                <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
-                For example, the <filename>ia32-base.inc</filename> file resides in the
-                <filename>meta/conf/machine/include</filename> directory.
-            </para>
+                <para>
+                    Tuning files are found in the <filename>meta/conf/machine/include</filename>
+                    directory within the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+                    For example, the <filename>ia32-base.inc</filename> file resides in the
+                    <filename>meta/conf/machine/include</filename> directory.
+                </para>
 
-            <para>
-                To use an include file, you simply include them in the
-                machine configuration file.
-                For example, the Raspberry Pi BSP
-                <filename>raspberrypi3.conf</filename> contains the
-                following statement:
-                <literallayout class='monospaced'>
+                <para>
+                    To use an include file, you simply include them in the
+                    machine configuration file.
+                    For example, the Raspberry Pi BSP
+                    <filename>raspberrypi3.conf</filename> contains the
+                    following statement:
+                    <literallayout class='monospaced'>
      include conf/machine/raspberrypi2.conf
-                </literallayout>
-            </para>
+                    </literallayout>
+                </para>
             </section>
 
             <section id='bsp-filelayout-misc-recipes'>
-            <title>Miscellaneous BSP-Specific Recipe Files</title>
-            <para>
-                You can find these files in the BSP Layer at:
-                <literallayout class='monospaced'>
-     meta-<replaceable>bsp_name</replaceable>/recipes-bsp/*
-                </literallayout>
-            </para>
+                <title>Miscellaneous BSP-Specific Recipe Files</title>
 
-            <para>
-                This optional directory contains miscellaneous recipe files for
-                the BSP.
-                Most notably would be the formfactor files.
-                For example, in the Raspberry Pi BSP there is the
-                <filename>formfactor_0.0.bbappend</filename> file, which is an
-                append file used to augment the recipe that starts the build.
-                Furthermore, there are machine-specific settings used during
-                the build that are defined by the
-                <filename>machconfig</filename> file further down in the
-                directory.
-                Here is the <filename>machconfig</filename>
-                file for the Raspberry Pi BSP:
-                <literallayout class='monospaced'>
+                <para>
+                    You can find these files in the BSP Layer at:
+                    <literallayout class='monospaced'>
+     meta-<replaceable>bsp_name</replaceable>/recipes-bsp/*
+                    </literallayout>
+                </para>
+
+                <para>
+                    This optional directory contains miscellaneous recipe files for
+                    the BSP.
+                    Most notably would be the formfactor files.
+                    For example, in the Raspberry Pi BSP there is the
+                    <filename>formfactor_0.0.bbappend</filename> file, which is an
+                    append file used to augment the recipe that starts the build.
+                    Furthermore, there are machine-specific settings used during
+                    the build that are defined by the
+                    <filename>machconfig</filename> file further down in the
+                    directory.
+                    Here is the <filename>machconfig</filename>
+                    file for the Raspberry Pi BSP:
+                    <literallayout class='monospaced'>
      HAVE_TOUCHSCREEN=0
      HAVE_KEYBOARD=1
 
      DISPLAY_CAN_ROTATE=0
      DISPLAY_ORIENTATION=0
      DISPLAY_DPI=133
-                </literallayout>
-            </para>
+                    </literallayout>
+                </para>
 
-            <note><para>
-                If a BSP does not have a formfactor entry, defaults are established according to
-                the formfactor configuration file that is installed by the main
-                formfactor recipe
-                <filename>meta/recipes-bsp/formfactor/formfactor_0.0.bb</filename>,
-                which is found in the
-                <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
-            </para></note>
+                <note><para>
+                    If a BSP does not have a formfactor entry, defaults are established according to
+                    the formfactor configuration file that is installed by the main
+                    formfactor recipe
+                    <filename>meta/recipes-bsp/formfactor/formfactor_0.0.bb</filename>,
+                    which is found in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+                </para></note>
             </section>
 
             <section id='bsp-filelayout-recipes-graphics'>
-            <title>Display Support Files</title>
-            <para>
-                You can find these files in the BSP Layer at:
-                <literallayout class='monospaced'>
-     meta-<replaceable>bsp_name</replaceable>/recipes-graphics/*
-                </literallayout>
-            </para>
+                <title>Display Support Files</title>
 
-            <para>
-                This optional directory contains recipes for the BSP if it has
-                special requirements for graphics support.
-                All files that are needed for the BSP to support a display are
-                kept here.
-            </para>
+                <para>
+                    You can find these files in the BSP Layer at:
+                    <literallayout class='monospaced'>
+     meta-<replaceable>bsp_name</replaceable>/recipes-graphics/*
+                    </literallayout>
+                </para>
+
+                <para>
+                    This optional directory contains recipes for the BSP if it has
+                    special requirements for graphics support.
+                    All files that are needed for the BSP to support a display are
+                    kept here.
+                </para>
             </section>
 
             <section id='bsp-filelayout-kernel'>
-            <title>Linux Kernel Configuration</title>
-            <para>
-                You can find these files in the BSP Layer at:
-                <literallayout class='monospaced'>
-     meta-<replaceable>bsp_name</replaceable>/recipes-kernel/linux/linux-yocto*.bbappend
-                </literallayout>
-            </para>
+                <title>Linux Kernel Configuration</title>
 
-            <para>
-                These files append your specific changes to the main kernel recipe you are using.
-            </para>
-            <para>
-                For your BSP, you typically want to use an existing Yocto Project kernel recipe found in the
-                <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
-                at <filename>meta/recipes-kernel/linux</filename>.
-                You can append your specific changes to the kernel recipe by using a
-                similarly named append file, which is located in the BSP Layer (e.g.
-                the <filename>meta-<replaceable>bsp_name</replaceable>/recipes-kernel/linux</filename> directory).
-            </para>
-            <para>
-                Suppose you are using the <filename>linux-yocto_4.4.bb</filename> recipe to build
-                the kernel.
-                In other words, you have selected the kernel in your
-                <replaceable>bsp_name</replaceable><filename>.conf</filename> file by adding these types
-                of statements:
-                <literallayout class='monospaced'>
+                <para>
+                    You can find these files in the BSP Layer at:
+                    <literallayout class='monospaced'>
+     meta-<replaceable>bsp_name</replaceable>/recipes-kernel/linux/linux-yocto*.bbappend
+                    </literallayout>
+                </para>
+
+                <para>
+                    These files append machine-specific changes to the main
+                    kernel recipe you are using.
+                </para>
+
+                <para>
+                    For your BSP, you typically want to use an existing Yocto
+                    Project kernel recipe found in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+                    at <filename>meta/recipes-kernel/linux</filename>.
+                    You can append machine-specific changes to the kernel recipe
+                    by using a similarly named append file, which is located in
+                    the BSP Layer for your target device (e.g. the
+                    <filename>meta-<replaceable>bsp_name</replaceable>/recipes-kernel/linux</filename> directory).
+                </para>
+
+                <para>
+                    Suppose you are using the <filename>linux-yocto_4.4.bb</filename>
+                    recipe to build the kernel.
+                    In other words, you have selected the kernel in your
+                    <replaceable>bsp_name</replaceable><filename>.conf</filename>
+                    file by adding
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-PREFERRED_PROVIDER'><filename>PREFERRED_PROVIDER</filename></ulink>
+                    and
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-PREFERRED_VERSION'><filename>PREFERRED_VERSION</filename></ulink>
+                    statements as follows:
+                    <literallayout class='monospaced'>
      PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
      PREFERRED_VERSION_linux-yocto ?= "4.4%"
-                </literallayout>
-                <note>
-                    When the preferred provider is assumed by default, the
-                    <filename>PREFERRED_PROVIDER</filename> statement does not appear in the
-                    <replaceable>bsp_name</replaceable><filename>.conf</filename> file.
-                </note>
-                You would use the <filename>linux-yocto_4.4.bbappend</filename>
-                file to append specific BSP settings to the kernel, thus
-                configuring the kernel for your particular BSP.
-            </para>
-
-            <para>
-                As an example, consider the following append file
-                used by the BSPs in <filename>meta-yocto-bsp</filename>:
-                <literallayout class='monospaced'>
-     meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.4.bbappend
-                </literallayout>
-                The following listing shows the file.
-                Be aware that the actual commit ID strings in this
-                example listing might be different than the actual strings
-                in the file from the <filename>meta-yocto-bsp</filename>
-                layer upstream.
-                <literallayout class='monospaced'>
-     KBRANCH_genericx86  = "standard/base"
-     KBRANCH_genericx86-64  = "standard/base"
-
-     KMACHINE_genericx86 ?= "common-pc"
-     KMACHINE_genericx86-64 ?= "common-pc-64"
-     KBRANCH_edgerouter = "standard/edgerouter"
-     KBRANCH_beaglebone = "standard/beaglebone"
-     KBRANCH_mpc8315e-rdb = "standard/fsl-mpc8315e-rdb"
-
-     SRCREV_machine_genericx86    ?= "ff4c4ef15b51f45b9106d71bf1f62fe7c02e63c2"
-     SRCREV_machine_genericx86-64 ?= "ff4c4ef15b51f45b9106d71bf1f62fe7c02e63c2"
-     SRCREV_machine_edgerouter ?= "ff4c4ef15b51f45b9106d71bf1f62fe7c02e63c2"
-     SRCREV_machine_beaglebone ?= "ff4c4ef15b51f45b9106d71bf1f62fe7c02e63c2"
-     SRCREV_machine_mpc8315e-rdb ?= "df00877ef9387b38b9601c82db57de2a1b23ce53"
-
-     COMPATIBLE_MACHINE_genericx86 = "genericx86"
-     COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64"
-     COMPATIBLE_MACHINE_edgerouter = "edgerouter"
-     COMPATIBLE_MACHINE_beaglebone = "beaglebone"
-     COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb"
-
-     LINUX_VERSION_genericx86 = "4.4.3"
-     LINUX_VERSION_genericx86-64 = "4.4.3"
-                </literallayout>
-                This append file contains statements used to support
-                several BSPs that ship with the Yocto Project.
-                The file defines machines using the
-                <ulink url='&YOCTO_DOCS_REF_URL;#var-COMPATIBLE_MACHINE'><filename>COMPATIBLE_MACHINE</filename></ulink>
-                variable and uses the
-                <ulink url='&YOCTO_DOCS_REF_URL;#var-KMACHINE'><filename>KMACHINE</filename></ulink>
-                variable to ensure the machine name used by the OpenEmbedded
-                build system maps to the machine name used by the Linux Yocto
-                kernel.
-                The file also uses the optional
-                <ulink url='&YOCTO_DOCS_REF_URL;#var-KBRANCH'><filename>KBRANCH</filename></ulink>
-                variable to ensure the build process uses the
-                appropriate kernel branch.
-            </para>
-
-            <para>
-                Although this particular example does not use it, the
-                <ulink url='&YOCTO_DOCS_REF_URL;#var-KERNEL_FEATURES'><filename>KERNEL_FEATURES</filename></ulink>
-                variable could be used to enable features specific to
-                the kernel.
-                The append file points to specific commits in the
-                <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
-                Git repository and the <filename>meta</filename> Git repository
-                branches to identify the exact kernel needed to build the
-                BSP.
-            </para>
-
-            <para>
-                One thing missing in this particular BSP, which you will
-                typically need when developing a BSP, is the kernel configuration
-                file (<filename>.config</filename>) for your BSP.
-                When developing a BSP, you probably have a kernel configuration
-                file or a set of kernel configuration files that, when taken
-                together, define the kernel configuration for your BSP.
-                You can accomplish this definition by putting the configurations
-                in a file or a set of files inside a directory located at the
-                same level as your kernel's append file and having the same
-                name as the kernel's main recipe file.
-                With all these conditions met, simply reference those files in the
-                <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
-                statement in the append file.
-            </para>
-
-            <para>
-                For example, suppose you had some configuration options
-                in a file called <filename>network_configs.cfg</filename>.
-                You can place that file inside a directory named
-                <filename>linux-yocto</filename> and then add
-                a <filename>SRC_URI</filename> statement such as the
-                following to the append file.
-                When the OpenEmbedded build system builds the kernel, the
-                configuration options are picked up and applied.
-                <literallayout class='monospaced'>
-     SRC_URI += "file://network_configs.cfg"
-                </literallayout>
-            </para>
-
-            <para>
-                To group related configurations into multiple files, you
-                perform a similar procedure.
-                Here is an example that groups separate configurations
-                specifically for Ethernet and graphics into their own
-                files and adds the configurations by using a
-                <filename>SRC_URI</filename> statement like the following
-                in your append file:
-                <literallayout class='monospaced'>
-     SRC_URI += "file://myconfig.cfg \
-                 file://eth.cfg \
-                 file://gfx.cfg"
-                </literallayout>
-            </para>
-
-            <para>
-                Another variable you can use in your kernel recipe append
-                file is the
-                <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></ulink>
-                variable.
-                When you use this statement, you are extending the locations
-                used by the OpenEmbedded system to look for files and
-                patches as the recipe is processed.
-            </para>
-
-            <note>
-                <para>
-                    Other methods exist to accomplish grouping and defining configuration options.
-                    For example, if you are working with a local clone of the kernel repository,
-                    you could checkout the kernel's <filename>meta</filename> branch, make your changes,
-                    and then push the changes to the local bare clone of the kernel.
-                    The result is that you directly add configuration options to the
-                    <filename>meta</filename> branch for your BSP.
-                    The configuration options will likely end up in that location anyway if the BSP gets
-                    added to the Yocto Project.
+                    </literallayout>
+                    <note>
+                        When the preferred provider is assumed by default, the
+                        <filename>PREFERRED_PROVIDER</filename>
+                        statement does not appear in the
+                        <replaceable>bsp_name</replaceable><filename>.conf</filename> file.
+                    </note>
+                    You would use the <filename>linux-yocto_4.4.bbappend</filename>
+                    file to append specific BSP settings to the kernel, thus
+                    configuring the kernel for your particular BSP.
                 </para>
 
                 <para>
-                    In general, however, the Yocto Project maintainers take care of moving the
-                    <filename>SRC_URI</filename>-specified
-                    configuration options to the kernel's <filename>meta</filename> branch.
-                    Not only is it easier for BSP developers to not have to worry about putting those
-                   configurations in the branch, but having the maintainers do it allows them to apply
-                    'global' knowledge about the kinds of common configuration options multiple BSPs in
-                    the tree are typically using.
-                    This allows for promotion of common configurations into common features.
+                    You can find more information on what your append file
+                    should contain in the
+                    "<ulink url='&YOCTO_DOCS_KERNEL_URL;#creating-the-append-file'>Creating the Append File</ulink>"
+                    section in the Yocto Project Linux Kernel Development
+                    Manual.
                 </para>
-            </note>
             </section>
         </section>
 

documentation/dev-manual/dev-manual-intro.xml

@@ -109,136 +109,13 @@
         <title>Other Information</title>
 
         <para>
-            Because this manual presents overview information for many different
+            Because this manual presents information for many different
             topics, supplemental information is recommended for full
             comprehension.
-            The following list presents other sources of information you might find helpful:
-            <itemizedlist>
-                <listitem><para><emphasis><ulink url='&YOCTO_HOME_URL;'>Yocto Project Website</ulink>:
-                    </emphasis> The home page for the Yocto Project provides lots of information on the project
-                    as well as links to software and documentation.
-                    </para></listitem>
-                <listitem><para><emphasis>
-                    <ulink url='&YOCTO_DOCS_QS_URL;'>Yocto Project Quick Start</ulink>:</emphasis>
-                    This short document lets you get started
-                    with the Yocto Project and quickly begin building an image.
-                    </para></listitem>
-                <listitem><para><emphasis>
-                    <ulink url='&YOCTO_DOCS_REF_URL;'>Yocto Project Reference Manual</ulink>:</emphasis>
-                    This manual is a reference
-                    guide to the OpenEmbedded build system, which is based on BitBake.
-                    The build system is sometimes referred to as "Poky".
-                    </para></listitem>
-                <listitem><para><emphasis>
-                    <ulink url='&YOCTO_DOCS_SDK_URL;'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>:</emphasis>
-                    This guide provides information that lets you get going
-                    with the standard or extensible SDK.
-                    An SDK, with its cross-development toolchains, allows you
-                    to develop projects inside or outside of the Yocto Project
-                    environment.
-                    </para></listitem>
-                <listitem><para><emphasis>
-                    <ulink url='&YOCTO_DOCS_BSP_URL;'>Yocto Project Board Support Package (BSP) Developer's Guide</ulink>:</emphasis>
-                    This guide defines the structure for BSP components.
-                    Having a commonly understood structure encourages standardization.
-                    </para></listitem>
-                <listitem><para><emphasis>
-                    <ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;'>Yocto Project Linux Kernel Development Manual</ulink>:</emphasis>
-                    This manual describes how to work with Linux Yocto kernels as well as provides a bit
-                    of conceptual information on the construction of the Yocto Linux kernel tree.
-                    </para></listitem>
-                <listitem><para><emphasis>
-                    <ulink url='&YOCTO_DOCS_PROF_URL;'>Yocto Project Profiling and Tracing Manual</ulink>:</emphasis>
-                    This manual presents a set of common and generally useful tracing and
-                    profiling schemes along with their applications (as appropriate) to each tool.
-                    </para></listitem>
-                <listitem><para><emphasis>
-                    <ulink url='&YOCTO_DOCS_TOAST_URL;'>Toaster User Manual</ulink>:</emphasis>
-                    This manual introduces and describes how to set up and use
-                    Toaster, which is a web interface to the Yocto Project's
-                    <link linkend='build-system-term'>OpenEmbedded Build System</link>.
-                    </para></listitem>
-                <listitem><para><emphasis>
-                    <ulink url='http://www.youtube.com/watch?v=3ZlOu-gLsh0'>
-                    Eclipse IDE Yocto Plug-in</ulink>:</emphasis>
-                    A step-by-step instructional video that
-                    demonstrates how an application developer uses Yocto Plug-in features within
-                    the Eclipse IDE.
-                    </para></listitem>
-                <listitem><para><emphasis>
-                    <ulink url='&YOCTO_WIKI_URL;/wiki/FAQ'>FAQ</ulink>:</emphasis>
-                    A list of commonly asked questions and their answers.
-                    </para></listitem>
-                <listitem><para><emphasis>
-                    <ulink url='&YOCTO_RELEASE_NOTES;'>Release Notes</ulink>:</emphasis>
-                    Features, updates and known issues for the current
-                    release of the Yocto Project.
-                    </para></listitem>
-                <listitem><para><emphasis>
-                    <ulink url='&YOCTO_HOME_URL;/tools-resources/projects/toaster'>Toaster</ulink>:</emphasis>
-                    An Application Programming Interface (API) and web-based
-                    interface to the OpenEmbedded build system, which uses
-                    BitBake, that reports build information.
-                    </para></listitem>
-                <listitem><para><emphasis>
-                    <ulink url='&YOCTO_HOME_URL;/tools-resources/projects/build-appliance'>Build Appliance</ulink>:</emphasis>
-                    A virtual machine that
-                    enables you to build and boot a custom embedded Linux image
-                    with the Yocto Project using a non-Linux development system.
-                    </para></listitem>
-                <listitem><para><emphasis>
-                    <ulink url='&YOCTO_BUGZILLA_URL;'>Bugzilla</ulink>:</emphasis>
-                    The bug tracking application the Yocto Project uses.
-                    If you find problems with the Yocto Project, you should report them using this
-                    application.
-                    </para></listitem>
-                <listitem><para><emphasis>Yocto Project Mailing Lists:</emphasis>
-                    To subscribe to the Yocto Project mailing
-                    lists, click on the following URLs and follow the instructions:
-                    <itemizedlist>
-                        <listitem><para><ulink url='&YOCTO_LISTS_URL;/listinfo/yocto'></ulink>
-                            for a Yocto Project Discussions mailing list.
-                            </para></listitem>
-                        <listitem><para><ulink url='&YOCTO_LISTS_URL;/listinfo/poky'></ulink>
-                            for a Yocto Project Discussions mailing list about the
-                            OpenEmbedded build system (Poky).
-                            </para></listitem>
-                        <listitem><para><ulink url='&YOCTO_LISTS_URL;/listinfo/yocto-announce'></ulink>
-                            for a mailing list to receive official Yocto Project announcements
-                            as well as Yocto Project milestones.
-                            </para></listitem>
-                        <listitem><para><ulink url='&YOCTO_LISTS_URL;/listinfo'></ulink>
-                            for a listing of all public mailing lists on
-                            <filename>lists.yoctoproject.org</filename>.
-                            </para></listitem>
-                    </itemizedlist></para></listitem>
-                <listitem><para><emphasis>Internet Relay Chat (IRC):</emphasis>
-                    Two IRC channels on freenode are available
-                    for Yocto Project and Poky discussions: <filename>#yocto</filename> and
-                    <filename>#poky</filename>, respectively.
-                    </para></listitem>
-                <listitem><para><emphasis>
-                    <ulink url='&OE_HOME_URL;'>OpenEmbedded</ulink>:</emphasis>
-                    The build system used by the Yocto Project.
-                    This project is the upstream, generic, embedded distribution
-                    from which the Yocto Project derives its build system (Poky)
-                    and to which it contributes.
-                    </para></listitem>
-                <listitem><para><emphasis>
-                    <ulink url='http://www.openembedded.org/wiki/BitBake'>BitBake</ulink>:</emphasis>
-                    The tool used by the OpenEmbedded build system
-                    to process project metadata.
-                    </para></listitem>
-                <listitem><para><emphasis>
-                    <ulink url='&YOCTO_DOCS_BB_URL;'>BitBake User Manual:</ulink></emphasis>
-                    A comprehensive guide to the BitBake tool.
-                    If you want information on BitBake, see this manual.
-                    </para></listitem>
-                <listitem><para><emphasis>
-                    <ulink url='http://wiki.qemu.org/Index.html'>Quick EMUlator (QEMU)</ulink>:</emphasis>
-                    An open-source machine emulator and virtualizer.
-                    </para></listitem>
-            </itemizedlist>
+            See the
+            "<ulink url='&YOCTO_DOCS_REF_URL;#resources-links-and-related-documentation'>Links and Related Documentation</ulink>"
+            section in the Yocto Project Reference Manual for helpful
+            sources.
         </para>
     </section>
 </chapter>

documentation/dev-manual/dev-manual-model.xml

@@ -255,19 +255,6 @@
                     supported images.</para></listitem>
             </orderedlist>
         </para>
-
-        <para>
-            You can view a video presentation on "Building Custom Embedded Images with Yocto"
-            at <ulink url='http://free-electrons.com/blog/elc-2011-videos'>Free Electrons</ulink>.
-            After going to the page, just search for "Embedded".
-            You can also find supplemental information in the
-            <ulink url='&YOCTO_DOCS_BSP_URL;'>
-            Yocto Project Board Support Package (BSP) Developer's Guide</ulink>.
-            Finally, there is helpful material and links on this
-            <ulink url='&YOCTO_WIKI_URL;/wiki/Transcript:_creating_one_generic_Atom_BSP_from_another'>wiki page</ulink>.
-            Although a bit dated, you might find the information on the wiki
-            helpful.
-       </para>
     </section>
 
     <section id='modifying-the-kernel'>
@@ -532,8 +519,11 @@
                         <note><title>Warning</title>
                             Try to resist the temptation to directly edit an
                             existing <filename>.config</filename> file, which is
-                            found in the Build Directory at
-                            <filename>tmp/sysroots/<replaceable>machine-name</replaceable>/kernel</filename>.
+                            found in the Build Directory among the source code
+                            used for the build (e.g. see the bottom
+                            illustration in the
+                            "<link linkend='kernel-overview'>Kernel Overview</link>"
+                            section).
                             Doing so, can produce unexpected results when the
                             OpenEmbedded build system regenerates the configuration
                             file.
@@ -978,7 +968,7 @@
                                 extracts them.
                                 Providing the <replaceable>srctree</replaceable>
                                 argument instructs <filename>devtool</filename> where
-                                place the extracted source.</para>
+                                to place the extracted source.</para>
 
                                 <para>Within workspace, <filename>devtool</filename>
                                 creates an append file for the recipe.
@@ -1108,11 +1098,8 @@
             </para>
 
             <para>
-                Depending on your particular scenario, the arguments and options
-                you use with <filename>devtool upgrade</filename> form different
-                combinations.
-                The following diagram shows a common development flow
-                you would use with the <filename>devtool modify</filename>
+                The following diagram shows the common development flow
+                you would use with the <filename>devtool upgrade</filename>
                 command:
             </para>
 
@@ -1272,7 +1259,7 @@
                 clean a recipe or have <filename>rm_work</filename> enabled,
                 the workflow described in the
                 "<link linkend='using-devtool-in-your-workflow'>Using <filename>devtool</filename> in Your Workflow</link>"
-                section is a safer development flow than than the flow that
+                section is a safer development flow than the flow that
                 uses Quilt.
             </note>
         </para>
@@ -1314,7 +1301,7 @@
                     </para></listitem>
                 <listitem><para><emphasis>Test Your Changes:</emphasis>
                     Once you have modified the source code, the easiest way to
-                    your changes is by calling the
+                    test your changes is by calling the
                     <filename>do_compile</filename> task as shown in the
                     following example:
                     <literallayout class='monospaced'>

documentation/dev-manual/dev-manual-newbie.xml

@@ -1323,63 +1323,88 @@
     </para>
 </section>
 
-<section id='tracking-bugs'>
-    <title>Tracking Bugs</title>
+<section id='submitting-a-defect-against-the-yocto-project'>
+    <title>Submitting a Defect Against the Yocto Project</title>
 
     <para>
-        The Yocto Project uses its own implementation of
-        <ulink url='http://www.bugzilla.org/about/'>Bugzilla</ulink> to track bugs.
-        Implementations of Bugzilla work well for group development because they track bugs and code
-        changes, can be used to communicate changes and problems with developers, can be used to
-        submit and review patches, and can be used to manage quality assurance.
-        The home page for the Yocto Project implementation of Bugzilla is
-        <ulink url='&YOCTO_BUGZILLA_URL;'>&YOCTO_BUGZILLA_URL;</ulink>.
+        Use the Yocto Project implementation of
+        <ulink url='http://www.bugzilla.org/about/'>Bugzilla</ulink>
+        to submit a defect (bug) against the Yocto Project.
+        For additional information on this implementation of Bugzilla see the
+        "<ulink url='&YOCTO_DOCS_REF_URL;#resources-bugtracker'>Yocto Project Bugzilla</ulink>"
+        section in the Yocto Project Reference Manual.
+        For more detail on any of the following steps, see the Yocto Project
+        <ulink url='&YOCTO_WIKI_URL;/wiki/Bugzilla_Configuration_and_Bug_Tracking'>Bugzilla wiki page</ulink>.
     </para>
 
     <para>
-        Sometimes it is helpful to submit, investigate, or track a bug against the Yocto Project itself
-        such as when discovering an issue with some component of the build system that acts contrary
-        to the documentation or your expectations.
-        Following is the general procedure for submitting a new bug using the Yocto Project
-        Bugzilla.
-        You can find more information on defect management, bug tracking, and feature request
-        processes all accomplished through the Yocto Project Bugzilla on the
-        <ulink url='&YOCTO_WIKI_URL;/wiki/Bugzilla_Configuration_and_Bug_Tracking'>wiki page</ulink>.
+        Use the following general steps to submit a bug"
+
         <orderedlist>
-            <listitem><para>Always use the Yocto Project implementation of Bugzilla to submit
-                a bug.</para></listitem>
-            <listitem><para>When submitting a new bug, be sure to choose the appropriate
-                Classification, Product, and Component for which the issue was found.
-                Defects for the Yocto Project fall into one of seven classifications:
-                Yocto Project Components, Infrastructure, Build System &amp; Metadata,
-                Documentation, QA/Testing, Runtime and Hardware.
-                Each of these Classifications break down into multiple Products and, in some
-                cases, multiple Components.</para></listitem>
-            <listitem><para>Use the bug form to choose the correct Hardware and Architecture
-                for which the bug applies.</para></listitem>
-            <listitem><para>Indicate the Yocto Project version you were using when the issue
-                occurred.</para></listitem>
-            <listitem><para>Be sure to indicate the Severity of the bug.
-                Severity communicates how the bug impacted your work.</para></listitem>
-            <listitem><para>Select the appropriate "Documentation change" item
-                for the bug.
-                Fixing a bug may or may not affect the Yocto Project
-                documentation.</para></listitem>
-            <listitem><para>Provide a brief summary of the issue.
-                Try to limit your summary to just a line or two and be sure to capture the
-                essence of the issue.</para></listitem>
-            <listitem><para>Provide a detailed description of the issue.
-                You should provide as much detail as you can about the context, behavior, output,
-                and so forth that surrounds the issue.
+            <listitem><para>
+                Open the Yocto Project implementation of
+                <ulink url='&YOCTO_BUGZILLA_URL;'>Bugzilla</ulink>.
+                </para></listitem>
+            <listitem><para>
+                Click "File a Bug" to enter a new bug.
+                </para></listitem>
+            <listitem><para>
+                Choose the appropriate "Classification", "Product", and
+                "Component" for which the bug was found.
+                Bugs for the Yocto Project fall into one of several
+                classifications, which in turn break down into several
+                products and components.
+                For example, for a bug against the
+                <filename>meta-intel</filename> layer, you would choose
+                "Build System, Metadata &amp; Runtime", "BSPs", and
+                "bsps-meta-intel", respectively.
+                </para></listitem>
+            <listitem><para>
+                Choose the "Version" of the Yocto Project for which you found
+                the bug (e.g. &DISTRO;).
+                </para></listitem>
+            <listitem><para>
+                Determine and select the "Severity" of the bug.
+                The severity indicates how the bug impacted your work.
+                </para></listitem>
+            <listitem><para>
+                Choose the "Hardware" that the bug impacts.
+                </para></listitem>
+            <listitem><para>
+                Choose the "Architecture" that the bug impacts.
+                </para></listitem>
+            <listitem><para>
+                Choose a "Documentation change" item for the bug.
+                Fixing a bug might or might not affect the Yocto Project
+                documentation.
+                If you are unsure of the impact to the documentation, select
+                "Don't Know".
+                </para></listitem>
+            <listitem><para>
+                Provide a brief "Summary" of the bug.
+                Try to limit your summary to just a line or two and be sure
+                to capture the essence of the bug.
+                </para></listitem>
+            <listitem><para>
+                Provide a detailed "Description" of the bug.
+                You should provide as much detail as you can about the context,
+                behavior, output, and so forth that surrounds the bug.
                 You can even attach supporting files for output from logs by
-                using the "Add an attachment" button.</para></listitem>
-            <listitem><para>Be sure to copy the appropriate people in the
-                "CC List" for the bug.
-                See the "<link linkend='how-to-submit-a-change'>How to Submit a Change</link>"
-                section for information about finding out who is responsible
-                for code.</para></listitem>
-            <listitem><para>Submit the bug by clicking the "Submit Bug" button.</para></listitem>
+                using the "Add an attachment" button.
+                </para></listitem>
+            <listitem><para>
+                Click the "Submit Bug" button submit the bug.
+                A new Bugzilla number is assigned to the bug and the defect
+                is logged in the bug tracking system.
+                </para></listitem>
         </orderedlist>
+        Once you file a bug, the bug is processed by the Yocto Project Bug
+        Triage Team and further details concerning the bug are assigned
+        (e.g. priority and owner).
+        You are the "Submitter" of the bug and any further categorization,
+        progress, or comments on the bug result in Bugzilla sending you an
+        automated email concerning the particular change or progress to the
+        bug.
     </para>
 </section>
 
@@ -1551,7 +1576,8 @@
                     </literallayout>
                     Just provide the name of the file for which you are interested.
                     The information returned is not ordered by history but does
-                    include a list of all committers grouped by name.
+                    include a list of everyone who has committed grouped by
+                    name.
                     From the list, you can see who is responsible for the bulk of
                     the changes against the file.
                     </para></listitem>
@@ -1722,8 +1748,8 @@
         </para>
 
         <para>
-            Depending on the components changed, you need to submit the email to a specific
-            mailing list.
+            Depending on the components changed, you need to submit the email
+            to a specific mailing list.
             For some guidance on which mailing list to use, see the list in the
             "<link linkend='how-to-submit-a-change'>How to Submit a Change</link>"
             section.
@@ -1735,24 +1761,34 @@
         <para>
             Here is the general procedure on how to submit a patch through email without using the
             scripts:
-            <itemizedlist>
-                <listitem><para>Make your changes in your local Git repository.</para></listitem>
-                <listitem><para>Stage your changes by using the <filename>git add</filename>
-                    command on each file you changed.</para></listitem>
-                <listitem><para>Commit the change by using the
+            <orderedlist>
+                <listitem><para>
+                    Make your changes in your local Git repository.
+                    </para></listitem>
+                <listitem><para>
+                    Stage your changes by using the
+                    <filename>git add</filename> command on each file you
+                    changed.
+                    </para></listitem>
+                <listitem><para>
+                    Commit the change by using the
                     <filename>git commit --signoff</filename> command.
-                    Using the <filename>--signoff</filename> option identifies you as the person
-                    making the change and also satisfies the Developer's Certificate of
-                    Origin (DCO) shown earlier.</para>
-                    <para>When you form a commit, you must follow certain standards established by the
-                    Yocto Project development team.
+                    Using the <filename>--signoff</filename> option identifies
+                    you as the person making the change and also satisfies
+                    the Developer's Certificate of Origin (DCO) shown earlier.
+                    </para>
+                    <para>When you form a commit, you must follow certain
+                    standards established by the Yocto Project development
+                    team.
                     See the earlier section
                     "<link linkend='how-to-submit-a-change'>How to Submit a Change</link>"
-                    for Yocto Project commit message standards.</para></listitem>
+                    for Yocto Project commit message standards.
+                    </para></listitem>
                 <listitem><para>Format the commit into an email message.
-                    To format commits, use the <filename>git format-patch</filename> command.
-                    When you provide the command, you must include a revision list or a number of patches
-                    as part of the command.
+                    To format commits, use the
+                    <filename>git format-patch</filename> command.
+                    When you provide the command, you must include a revision
+                    list or a number of patches as part of the command.
                     For example, either of these two commands takes your most
                     recent single commit and formats it as an email message in
                     the current directory:
@@ -1763,50 +1799,70 @@
                     <literallayout class='monospaced'>
      $ git format-patch HEAD~
                     </literallayout></para>
-                    <para>After the command is run, the current directory contains a
-                    numbered <filename>.patch</filename> file for the commit.</para>
-                    <para>If you provide several commits as part of the command,
-                    the <filename>git format-patch</filename> command produces a
-                    series of numbered files in the current directory – one for each commit.
+                    <para>After the command is run, the current directory
+                    contains a numbered <filename>.patch</filename> file for
+                    the commit.</para>
+                    <para>If you provide several commits as part of the
+                    command, the <filename>git format-patch</filename> command
+                    produces a series of numbered files in the current
+                    directory – one for each commit.
                     If you have more than one patch, you should also use the
-                    <filename>--cover</filename> option with the command, which generates a
-                    cover letter as the first "patch" in the series.
-                    You can then edit the cover letter to provide a description for
-                    the series of patches.
-                    For information on the <filename>git format-patch</filename> command,
-                    see <filename>GIT_FORMAT_PATCH(1)</filename> displayed using the
-                    <filename>man git-format-patch</filename> command.</para>
-                    <note>If you are or will be a frequent contributor to the Yocto Project
-                    or to OpenEmbedded, you might consider requesting a contrib area and the
-                    necessary associated rights.</note></listitem>
-                <listitem><para>Import the files into your mail client by using the
+                    <filename>--cover</filename> option with the command,
+                    which generates a cover letter as the first "patch" in
+                    the series.
+                    You can then edit the cover letter to provide a
+                    description for the series of patches.
+                    For information on the
+                    <filename>git format-patch</filename> command,
+                    see <filename>GIT_FORMAT_PATCH(1)</filename> displayed
+                    using the <filename>man git-format-patch</filename>
+                    command.
+                    <note>
+                        If you are or will be a frequent contributor to the
+                        Yocto Project or to OpenEmbedded, you might consider
+                        requesting a contrib area and the necessary associated
+                        rights.
+                    </note>
+                    </para></listitem>
+                <listitem><para>
+                    Import the files into your mail client by using the
                     <filename>git send-email</filename> command.
-                    <note>In order to use <filename>git send-email</filename>, you must have the
-                    the proper Git packages installed.
-                    For Ubuntu, Debian, and Fedora the package is <filename>git-email</filename>.</note></para>
-                    <para>The <filename>git send-email</filename> command sends email by using a local
-                    or remote Mail Transport Agent (MTA) such as
-                    <filename>msmtp</filename>, <filename>sendmail</filename>, or through a direct
-                    <filename>smtp</filename> configuration in your Git <filename>config</filename>
-                    file.
-                    If you are submitting patches through email only, it is very important
-                    that you submit them without any whitespace or HTML formatting that
-                    either you or your mailer introduces.
-                    The maintainer that receives your patches needs to be able to save and
-                    apply them directly from your emails.
-                    A good way to verify that what you are sending will be applicable by the
-                    maintainer is to do a dry run and send them to yourself and then
-                    save and apply them as the maintainer would.</para>
-                    <para>The <filename>git send-email</filename> command is the preferred method
-                    for sending your patches since there is no risk of compromising whitespace
-                    in the body of the message, which can occur when you use your own mail client.
+                    <note>
+                        In order to use <filename>git send-email</filename>,
+                        you must have the proper Git packages installed on
+                        your host.
+                        For Ubuntu, Debian, and Fedora the package is
+                        <filename>git-email</filename>.
+                    </note></para>
+                    <para>The <filename>git send-email</filename> command
+                    sends email by using a local or remote Mail Transport Agent
+                    (MTA) such as <filename>msmtp</filename>,
+                    <filename>sendmail</filename>, or through a direct
+                    <filename>smtp</filename> configuration in your Git
+                    <filename>~/.gitconfig</filename> file.
+                    If you are submitting patches through email only, it is
+                    very important that you submit them without any whitespace
+                    or HTML formatting that either you or your mailer
+                    introduces.
+                    The maintainer that receives your patches needs to be able
+                    to save and apply them directly from your emails.
+                    A good way to verify that what you are sending will be
+                    applicable by the maintainer is to do a dry run and send
+                    them to yourself and then save and apply them as the
+                    maintainer would.</para>
+                    <para>The <filename>git send-email</filename> command is
+                    the preferred method for sending your patches since there
+                    is no risk of compromising whitespace in the body of the
+                    message, which can occur when you use your own mail client.
                     The command also has several options that let you
-                    specify recipients and perform further editing of the email message.
-                    For information on how to use the <filename>git send-email</filename> command,
+                    specify recipients and perform further editing of the
+                    email message.
+                    For information on how to use the
+                    <filename>git send-email</filename> command,
                     see <filename>GIT-SEND-EMAIL(1)</filename> displayed using
                     the <filename>man git-send-email</filename> command.
                     </para></listitem>
-            </itemizedlist>
+            </orderedlist>
         </para>
     </section>
 </section>

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

@@ -278,7 +278,7 @@
                 applications using the Eclipse Integrated Development Environment (IDE),
                 you will need this plug-in.
                 See the
-                "<ulink url='&YOCTO_DOCS_SDK_URL;#setting-up-the-eclipse-ide'>Setting up the Eclipse IDE</ulink>"
+                "<ulink url='&YOCTO_DOCS_SDK_URL;#sdk-appendix-latest-yp-eclipse-plug-in'>Using Eclipse</ulink>"
                 section in the Yocto Project Software Development Kit (SDK)
                 Developer's Guide for more information.</para></listitem>
         </itemizedlist>

documentation/dev-manual/dev-manual.xml

@@ -96,6 +96,11 @@
                 <date>May 2017</date>
                 <revremark>Released with the Yocto Project 2.3 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>2.4</revnumber>
+                <date>Usually October</date>
+                <revremark>Released with the Yocto Project 2.4 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>

documentation/kernel-dev/kernel-dev-advanced.xml

@@ -524,170 +524,219 @@
         <title>BSP Descriptions</title>
 
         <para>
-            BSP descriptions combine kernel types with hardware-specific
-            features.
-            The hardware-specific portion is typically defined
-            independently, and then aggregated with each supported kernel
-            type.
-            Consider this simple BSP description that supports the
-            <replaceable>mybsp</replaceable> machine:
-            <literallayout class='monospaced'>
-     <replaceable>mybsp</replaceable>.scc:
-        define KMACHINE <replaceable>mybsp</replaceable>
-        define KTYPE standard
-        define KARCH i386
-
-        kconf <replaceable>mybsp</replaceable>.cfg
-            </literallayout>
-            Every BSP description should define the
-            <ulink url='&YOCTO_DOCS_REF_URL;#var-KMACHINE'><filename>KMACHINE</filename></ulink>,
-            <ulink url='&YOCTO_DOCS_REF_URL;#var-KTYPE'><filename>KTYPE</filename></ulink>,
-            and <ulink url='&YOCTO_DOCS_REF_URL;#var-KARCH'><filename>KARCH</filename></ulink>
-            variables.
-            These variables allow the OpenEmbedded build system to identify
-            the description as meeting the criteria set by the recipe being
-            built.
-            This simple example supports the "mybsp" machine for the "standard"
-            kernel and the "i386" architecture.
-        </para>
-
-        <para>
-            Be aware that a hard link between the
-            <filename>KTYPE</filename> variable and a kernel type
-            description file does not exist.
-            Thus, if you do not have kernel types defined in your kernel
-            Metadata, you only need to ensure that the kernel recipe's
-            <ulink url='&YOCTO_DOCS_REF_URL;#var-LINUX_KERNEL_TYPE'><filename>LINUX_KERNEL_TYPE</filename></ulink>
-            variable and the <filename>KTYPE</filename> variable in the
-            BSP description file match.
+            BSP descriptions (i.e. <filename>*.scc</filename> files)
+            combine kernel types with hardware-specific features.
+            The hardware-specific Metadata is typically defined
+            independently in the BSP layer, and then aggregated with each
+            supported kernel type.
             <note>
-                Future versions of the tooling make the specification of
-                <filename>KTYPE</filename> in the BSP optional.
+                For BSPs supported by the Yocto Project, the BSP description
+                files are located in the <filename>bsp</filename> directory
+                of the <filename>yocto-kernel-cache</filename> repository
+                organized under the "Yocto Linux Kernel" heading in the
+                <ulink url='http://git.yoctoproject.org/cgit/cgit.cgi'>Yocto Project Source Repositories</ulink>.
             </note>
         </para>
 
         <para>
-            If you did want to separate your kernel policy from your
-            hardware configuration, you could do so by specifying a kernel
-            type, such as "standard" and including that description file
-            in the BSP description file.
-            See the "<link linkend='kernel-types'>Kernel Types</link>" section
-            for more information.
+            This section provides a BSP description structural overview along
+            with aggregation concepts as well as a detailed example using
+            a BSP supported by the Yocto Project (i.e. Minnow Board).
         </para>
 
-        <para>
-            You might also have multiple hardware configurations that you
-            aggregate into a single hardware description file that you
-            could include in the BSP description file, rather than referencing
-            a single <filename>.cfg</filename> file.
-            Consider the following:
-            <literallayout class='monospaced'>
-     <replaceable>mybsp</replaceable>.scc:
-        define KMACHINE mybsp
-        define KTYPE standard
-        define KARCH i386
+        <section id='bsp-description-file-overview'>
+            <title>Overview</title>
 
-        include standard.scc
-        include <replaceable>mybsp</replaceable>-hw.scc
-            </literallayout>
-        </para>
+            <para>
+                For simplicity, consider the following top-level BSP
+                description file.
+                Top-level BSP descriptions files employ both a structure
+                and naming convention for consistency.
+                The naming convention for the file is as follows:
+                <literallayout class='monospaced'>
+     <replaceable>bsp_name</replaceable>-<replaceable>kernel_type</replaceable>.scc
+                </literallayout>
+                Here are some example top-level BSP filenames for the
+                Minnow Board BSP, which is supported by the Yocto Project:
+                <literallayout class='monospaced'>
+     minnow-standard.scc
+     minnow-preempt-rt.scc
+     minnow-tiny.scc
+                </literallayout>
+                Each file uses the BSP name followed by the kernel type.
+            </para>
 
-        <para>
-            In the above example, <filename>standard.scc</filename>
-            aggregates all the configuration fragments, patches, and
-            features that make up your standard kernel policy whereas
-            <replaceable>mybsp</replaceable><filename>-hw.scc</filename>
-            aggregates all those necessary
-            to support the hardware available on the
-            <replaceable>mybsp</replaceable> machine.
-            For information on how to break a complete
-            <filename>.config</filename> file into the various
-            configuration fragments, see the
-            "<link linkend='generating-configuration-files'>Generating Configuration Files</link>"
-            section.
-        </para>
+            <para>
+                is simple BSP description file whose name has the
+                form
+                <replaceable>mybsp</replaceable><filename>-standard</filename>
+                and supports the <replaceable>mybsp</replaceable> machine using
+                a standard kernel:
+                <literallayout class='monospaced'>
+     define KMACHINE <replaceable>mybsp</replaceable>
+     define KTYPE standard
+     define KARCH i386
 
-        <para>
-            Many real-world examples are more complex.
-            Like any other <filename>.scc</filename> file, BSP
-            descriptions can aggregate features.
-            Consider the Minnow BSP definition from the
-            <filename>linux-yocto-3.19</filename>
-            Git repository:
-            <literallayout class='monospaced'>
+     include ktypes/standard
+
+     include <replaceable>mybsp</replaceable>.scc
+
+     kconf hardware <replaceable>mybsp</replaceable>-<replaceable>extra</replaceable>.cfg
+                </literallayout>
+                Every top-level BSP description file should define the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-KMACHINE'><filename>KMACHINE</filename></ulink>,
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-KTYPE'><filename>KTYPE</filename></ulink>,
+                and <ulink url='&YOCTO_DOCS_REF_URL;#var-KARCH'><filename>KARCH</filename></ulink>
+                variables.
+                These variables allow the OpenEmbedded build system to identify
+                the description as meeting the criteria set by the recipe being
+                built.
+                This simple example supports the "mybsp" machine for the "standard"
+                kernel and the "i386" architecture.
+            </para>
+
+            <para>
+                Be aware that a hard link between the
+                <filename>KTYPE</filename> variable and a kernel type description
+                file does not exist.
+                Thus, if you do not have kernel types defined in your kernel
+                Metadata, you only need to ensure that the kernel recipe's
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-LINUX_KERNEL_TYPE'><filename>LINUX_KERNEL_TYPE</filename></ulink>
+                variable and the <filename>KTYPE</filename> variable in the
+                BSP description file match.
+                <note>
+                    Future versions of the tooling make the specification of
+                    <filename>KTYPE</filename> in the BSP optional.
+                </note>
+            </para>
+
+            <para>
+                To separate your kernel policy from your hardware configuration,
+                you include a kernel type (<filename>ktype</filename>), such as
+                "standard".
+                In the previous example, this is done using the following:
+                <literallayout class='monospaced'>
+     include ktypes/standard
+                </literallayout>
+                In the previous example, <filename>ktypes/standard.scc</filename>
+                aggregates all the configuration fragments, patches, and
+                features that make up your standard kernel policy.
+                See the "<link linkend='kernel-types'>Kernel Types</link>" section
+                for more information.
+            </para>
+
+            <para>
+                To aggregate common configurations and features specific to the
+                kernel for <replaceable>mybsp</replaceable>, use the following:
+                <literallayout class='monospaced'>
+     include <replaceable>mybsp</replaceable>.scc
+                </literallayout>
+                For information on how to break a complete
+                <filename>.config</filename> file into the various
+                configuration fragments, see the
+                "<link linkend='generating-configuration-files'>Generating Configuration Files</link>"
+                section.
+            </para>
+
+            <para>
+                Finally, if you have any configurations specific to the
+                hardware that are not in a <filename>*.scc</filename> file,
+                you can include them as follows:
+                <literallayout class='monospaced'>
+     kconf hardware <replaceable>mybsp</replaceable>-<replaceable>extra</replaceable>.cfg
+                </literallayout>
+            </para>
+        </section>
+
+        <section id='bsp-description-file-example-minnow'>
+            <title>Example</title>
+
+            <para>
+                Many real-world examples are more complex.
+                Like any other <filename>.scc</filename> file, BSP
+                descriptions can aggregate features.
+                Consider the Minnow BSP definition from the
+                <filename>linux-yocto-4.4</filename> in the
+                Yocto Project
+                <ulink url='&YOCTO_DOCS_DEV_URL;#source-repositories'>Source Repositories</ulink>
+                (i.e.
+                <filename>yocto-kernel-cache/bsp/minnow</filename>):
+                <literallayout class='monospaced'>
      minnow.scc:
-        include cfg/x86.scc
-        include features/eg20t/eg20t.scc
-        include cfg/dmaengine.scc
-        include features/power/intel.scc
-        include cfg/efi.scc
-        include features/usb/ehci-hcd.scc
-        include features/usb/ohci-hcd.scc
-        include features/usb/usb-gadgets.scc
-        include features/usb/touchscreen-composite.scc
-        include cfg/timer/hpet.scc
-        include cfg/timer/rtc.scc
-        include features/leds/leds.scc
-        include features/spi/spidev.scc
-        include features/i2c/i2cdev.scc
+         include cfg/x86.scc
+         include features/eg20t/eg20t.scc
+         include cfg/dmaengine.scc
+         include features/power/intel.scc
+         include cfg/efi.scc
+         include features/usb/ehci-hcd.scc
+         include features/usb/ohci-hcd.scc
+         include features/usb/usb-gadgets.scc
+         include features/usb/touchscreen-composite.scc
+         include cfg/timer/hpet.scc
+         include features/leds/leds.scc
+         include features/spi/spidev.scc
+         include features/i2c/i2cdev.scc
+         include features/mei/mei-txe.scc
 
-        # Earlyprintk and port debug requires 8250
-        kconf hardware cfg/8250.cfg
+         # Earlyprintk and port debug requires 8250
+         kconf hardware cfg/8250.cfg
 
-        kconf hardware minnow.cfg
-        kconf hardware minnow-dev.cfg
-            </literallayout>
-        </para>
+         kconf hardware minnow.cfg
+         kconf hardware minnow-dev.cfg
+                </literallayout>
+            </para>
 
-        <para>
-            The <filename>minnow.scc</filename> description file includes
-            a hardware configuration fragment
-            (<filename>minnow.cfg</filename>) specific to the Minnow
-            BSP as well as several more general configuration
-            fragments and features enabling hardware found on the
-            machine.
-            This description file is then included in each of the three
-            "minnow" description files for the supported kernel types
-            (i.e. "standard", "preempt-rt", and "tiny").
-            Consider the "minnow" description for the "standard" kernel
-            type:
-            <literallayout class='monospaced'>
+            <para>
+                The <filename>minnow.scc</filename> description file includes
+                a hardware configuration fragment
+                (<filename>minnow.cfg</filename>) specific to the Minnow
+                BSP as well as several more general configuration
+                fragments and features enabling hardware found on the
+                machine.
+                This <filename>minnow.scc</filename> description file is then
+                included in each of the three
+                "minnow" description files for the supported kernel types
+                (i.e. "standard", "preempt-rt", and "tiny").
+                Consider the "minnow" description for the "standard" kernel
+                type:
+                <literallayout class='monospaced'>
      minnow-standard.scc:
-        define KMACHINE minnow
-        define KTYPE standard
-        define KARCH i386
+         define KMACHINE minnow
+         define KTYPE standard
+         define KARCH i386
 
-        include ktypes/standard
+         include ktypes/standard
 
-        include minnow.scc
+         include minnow.scc
 
-        # Extra minnow configs above the minimal defined in minnow.scc
-        include cfg/efi-ext.scc
-        include features/media/media-all.scc
-        include features/sound/snd_hda_intel.scc
+         # Extra minnow configs above the minimal defined in minnow.scc
+         include cfg/efi-ext.scc
+         include features/media/media-all.scc
+         include features/sound/snd_hda_intel.scc
 
-        # The following should really be in standard.scc
-        # USB live-image support
-        include cfg/usb-mass-storage.scc
-        include cfg/boot-live.scc
+         # The following should really be in standard.scc
+         # USB live-image support
+         include cfg/usb-mass-storage.scc
+         include cfg/boot-live.scc
 
-        # Basic profiling
-        include features/latencytop/latencytop.scc
-        include features/profiling/profiling.scc
+         # Basic profiling
+         include features/latencytop/latencytop.scc
+         include features/profiling/profiling.scc
 
-        # Requested drivers that don't have an existing scc
-        kconf hardware minnow-drivers-extra.cfg
-            </literallayout>
-            The <filename>include</filename> command midway through the file
-            includes the <filename>minnow.scc</filename> description that
-            defines all hardware enablements for the BSP that is common to all
-            kernel types.
-            Using this command significantly reduces duplication.
-        </para>
+         # Requested drivers that don't have an existing scc
+         kconf hardware minnow-drivers-extra.cfg
+                </literallayout>
+                The <filename>include</filename> command midway through the file
+                includes the <filename>minnow.scc</filename> description that
+                defines all enabled hardware for the BSP that is common to
+                all kernel types.
+                Using this command significantly reduces duplication.
+            </para>
 
-        <para>
-            Now consider the "minnow" description for the "tiny" kernel type:
-            <literallayout class='monospaced'>
+            <para>
+                Now consider the "minnow" description for the "tiny" kernel
+                type:
+                <literallayout class='monospaced'>
      minnow-tiny.scc:
         define KMACHINE minnow
         define KTYPE tiny
@@ -696,22 +745,24 @@
         include ktypes/tiny
 
         include minnow.scc
-            </literallayout>
-            As you might expect, the "tiny" description includes quite a
-            bit less.
-            In fact, it includes only the minimal policy defined by the
-            "tiny" kernel type and the hardware-specific configuration required
-            for booting the machine along with the most basic functionality of
-            the system as defined in the base "minnow" description file.
-        </para>
+                </literallayout>
+                As you might expect, the "tiny" description includes quite a
+                bit less.
+                In fact, it includes only the minimal policy defined by the
+                "tiny" kernel type and the hardware-specific configuration
+                required for booting the machine along with the most basic
+                functionality of the system as defined in the base "minnow"
+                description file.
+            </para>
 
-        <para>
-            Notice again the three critical variables:
-            <filename>KMACHINE</filename>, <filename>KTYPE</filename>,
-            and <filename>KARCH</filename>.
-            Of these variables, only the <filename>KTYPE</filename> has changed.
-            It is now set to "tiny".
-        </para>
+            <para>
+                Notice again the three critical variables:
+                <filename>KMACHINE</filename>, <filename>KTYPE</filename>,
+                and <filename>KARCH</filename>.
+                Of these variables, only the <filename>KTYPE</filename> has changed.
+                It is now set to "tiny".
+            </para>
+        </section>
     </section>
 </section>
 
@@ -795,6 +846,18 @@
             value when changing the content of files not explicitly listed
             in the <filename>SRC_URI</filename>.
         </para>
+
+        <para>
+            If the BSP description is in recipe space, you cannot simply list
+            the <filename>*.scc</filename> in the <filename>SRC_URI</filename>
+            statement.
+            You need to use the following form from your kernel append file:
+            <literallayout class='monospaced'>
+     SRC_URI_append_<replaceable>myplatform</replaceable> = " \
+        file://<replaceable>myplatform</replaceable>;type=kmeta;destsuffix=<replaceable>myplatform</replaceable> \
+        "
+            </literallayout>
+        </para>
     </section>
 
     <section id='metadata-outside-the-recipe-space'>
@@ -817,7 +880,8 @@
             <filename>${KMETA}</filename>, in this context, is simply used to
             name the directory into which the Git fetcher places the Metadata.
             This behavior is no different than any multi-repository
-            <filename>SRC_URI</filename> statement used in a recipe.
+            <filename>SRC_URI</filename> statement used in a recipe (e.g.
+            see the previous section).
         </para>
 
         <para>

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

@@ -84,11 +84,11 @@
                 You also name it accordingly based on the linux-yocto recipe
                 you are using.
                 For example, if you are modifying the
-                <filename>meta/recipes-kernel/linux/linux-yocto_3.19.bb</filename>
+                <filename>meta/recipes-kernel/linux/linux-yocto_4.4.bb</filename>
                 recipe, the append file will typically be located as follows
                 within your custom layer:
                 <literallayout class='monospaced'>
-     <replaceable>your-layer</replaceable>/recipes-kernel/linux/linux-yocto_3.19.bbappend
+     <replaceable>your-layer</replaceable>/recipes-kernel/linux/linux-yocto_4.4.bbappend
                 </literallayout>
                 The append file should initially extend the
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESPATH'><filename>FILESPATH</filename></ulink>
@@ -114,6 +114,151 @@
                     <ulink url='&YOCTO_DOCS_BSP_URL;'>Yocto Project Board Support Package (BSP) Developer's Guide</ulink>.
                 </note>
             </para>
+
+            <para>
+                As an example, consider the following append file
+                used by the BSPs in <filename>meta-yocto-bsp</filename>:
+                <literallayout class='monospaced'>
+     meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.4.bbappend
+                </literallayout>
+                The following listing shows the file.
+                Be aware that the actual commit ID strings in this
+                example listing might be different than the actual strings
+                in the file from the <filename>meta-yocto-bsp</filename>
+                layer upstream.
+                <literallayout class='monospaced'>
+     KBRANCH_genericx86  = "standard/base"
+     KBRANCH_genericx86-64  = "standard/base"
+
+     KMACHINE_genericx86 ?= "common-pc"
+     KMACHINE_genericx86-64 ?= "common-pc-64"
+     KBRANCH_edgerouter = "standard/edgerouter"
+     KBRANCH_beaglebone = "standard/beaglebone"
+     KBRANCH_mpc8315e-rdb = "standard/fsl-mpc8315e-rdb"
+
+     SRCREV_machine_genericx86    ?= "ad8b1d659ddd2699ebf7d50ef9de8940b157bfc2"
+     SRCREV_machine_genericx86-64 ?= "ad8b1d659ddd2699ebf7d50ef9de8940b157bfc2"
+     SRCREV_machine_edgerouter ?= "cebe1ad56aebd89e0de29412e19433fb441bf13c"
+     SRCREV_machine_beaglebone ?= "cebe1ad56aebd89e0de29412e19433fb441bf13c"
+     SRCREV_machine_mpc8315e-rdb ?= "06c0dbdcba374ca7f92a53d69292d6bb7bc9b0f3"
+
+     COMPATIBLE_MACHINE_genericx86 = "genericx86"
+     COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64"
+     COMPATIBLE_MACHINE_edgerouter = "edgerouter"
+     COMPATIBLE_MACHINE_beaglebone = "beaglebone"
+     COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb"
+
+     LINUX_VERSION_genericx86 = "4.4.41"
+     LINUX_VERSION_genericx86-64 = "4.4.41"
+     LINUX_VERSION_edgerouter = "4.4.53"
+     LINUX_VERSION_beaglebone = "4.4.53"
+     LINUX_VERSION_mpc8315e-rdb = "4.4.53"
+                </literallayout>
+                This append file contains statements used to support
+                several BSPs that ship with the Yocto Project.
+                The file defines machines using the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-COMPATIBLE_MACHINE'><filename>COMPATIBLE_MACHINE</filename></ulink>
+                variable and uses the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-KMACHINE'><filename>KMACHINE</filename></ulink>
+                variable to ensure the machine name used by the OpenEmbedded
+                build system maps to the machine name used by the Linux Yocto
+                kernel.
+                The file also uses the optional
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-KBRANCH'><filename>KBRANCH</filename></ulink>
+                variable to ensure the build process uses the
+                appropriate kernel branch.
+            </para>
+
+            <para>
+                Although this particular example does not use it, the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-KERNEL_FEATURES'><filename>KERNEL_FEATURES</filename></ulink>
+                variable could be used to enable features specific to
+                the kernel.
+                The append file points to specific commits in the
+                <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+                Git repository and the <filename>meta</filename> Git repository
+                branches to identify the exact kernel needed to build the
+                BSP.
+            </para>
+
+            <para>
+                One thing missing in this particular BSP, which you will
+                typically need when developing a BSP, is the kernel configuration
+                file (<filename>.config</filename>) for your BSP.
+                When developing a BSP, you probably have a kernel configuration
+                file or a set of kernel configuration files that, when taken
+                together, define the kernel configuration for your BSP.
+                You can accomplish this definition by putting the configurations
+                in a file or a set of files inside a directory located at the
+                same level as your kernel's append file and having the same
+                name as the kernel's main recipe file.
+                With all these conditions met, simply reference those files in the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
+                statement in the append file.
+            </para>
+
+            <para>
+                For example, suppose you had some configuration options
+                in a file called <filename>network_configs.cfg</filename>.
+                You can place that file inside a directory named
+                <filename>linux-yocto</filename> and then add
+                a <filename>SRC_URI</filename> statement such as the
+                following to the append file.
+                When the OpenEmbedded build system builds the kernel, the
+                configuration options are picked up and applied.
+                <literallayout class='monospaced'>
+     SRC_URI += "file://network_configs.cfg"
+                </literallayout>
+            </para>
+
+            <para>
+                To group related configurations into multiple files, you
+                perform a similar procedure.
+                Here is an example that groups separate configurations
+                specifically for Ethernet and graphics into their own
+                files and adds the configurations by using a
+                <filename>SRC_URI</filename> statement like the following
+                in your append file:
+                <literallayout class='monospaced'>
+     SRC_URI += "file://myconfig.cfg \
+                 file://eth.cfg \
+                 file://gfx.cfg"
+                </literallayout>
+            </para>
+
+            <para>
+                Another variable you can use in your kernel recipe append
+                file is the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></ulink>
+                variable.
+                When you use this statement, you are extending the locations
+                used by the OpenEmbedded system to look for files and
+                patches as the recipe is processed.
+            </para>
+
+            <note>
+                <para>
+                    Other methods exist to accomplish grouping and defining configuration options.
+                    For example, if you are working with a local clone of the kernel repository,
+                    you could checkout the kernel's <filename>meta</filename> branch, make your changes,
+                    and then push the changes to the local bare clone of the kernel.
+                    The result is that you directly add configuration options to the
+                    <filename>meta</filename> branch for your BSP.
+                    The configuration options will likely end up in that location anyway if the BSP gets
+                    added to the Yocto Project.
+                </para>
+
+                <para>
+                    In general, however, the Yocto Project maintainers take care of moving the
+                    <filename>SRC_URI</filename>-specified
+                    configuration options to the kernel's <filename>meta</filename> branch.
+                    Not only is it easier for BSP developers to not have to worry about putting those
+                    configurations in the branch, but having the maintainers do it allows them to apply
+                    'global' knowledge about the kinds of common configuration options multiple BSPs in
+                    the tree are typically using.
+                    This allows for promotion of common configurations into common features.
+                </para>
+            </note>
         </section>
 
         <section id='applying-patches'>

documentation/kernel-dev/kernel-dev.xml

@@ -81,6 +81,11 @@
                 <date>May 2017</date>
                 <revremark>Released with the Yocto Project 2.3 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>2.4</revnumber>
+                <date>Usually October</date>
+                <revremark>Released with the Yocto Project 2.4 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>

documentation/mega-manual/mega-manual.xml

@@ -65,6 +65,11 @@
                 <date>May 2017</date>
                 <revremark>Released with the Yocto Project 2.3 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>2.4</revnumber>
+                <date>Usually October</date>
+                <revremark>Released with the Yocto Project 2.4 Release.</revremark>
+            </revision>
        </revhistory>
 
     <copyright>

documentation/poky.ent

@@ -1,10 +1,10 @@
-<!ENTITY DISTRO "2.3">
-<!ENTITY DISTRO_COMPRESSED "23">
-<!ENTITY DISTRO_NAME_NO_CAP "pyro">
-<!ENTITY DISTRO_NAME "Pyro">
-<!ENTITY YOCTO_DOC_VERSION "2.3">
-<!ENTITY POKYVERSION "18.0.0">
-<!ENTITY POKYVERSION_COMPRESSED "1800">
+<!ENTITY DISTRO "2.4">
+<!ENTITY DISTRO_COMPRESSED "24">
+<!ENTITY DISTRO_NAME_NO_CAP "tbd">
+<!ENTITY DISTRO_NAME "Tbd">
+<!ENTITY YOCTO_DOC_VERSION "2.4">
+<!ENTITY POKYVERSION "19.0.0">
+<!ENTITY POKYVERSION_COMPRESSED "1900">
 <!ENTITY YOCTO_POKY "poky-&DISTRO_NAME_NO_CAP;-&POKYVERSION;">
 <!ENTITY COPYRIGHT_YEAR "2010-2017">
 <!ENTITY YOCTO_DL_URL "http://downloads.yoctoproject.org">
@@ -61,16 +61,18 @@
 <!ENTITY OE_INIT_PATH "&YOCTO_POKY;/oe-init-build-env">
 <!ENTITY OE_INIT_FILE "oe-init-build-env">
 <!ENTITY UBUNTU_HOST_PACKAGES_ESSENTIAL "gawk wget git-core diffstat unzip texinfo gcc-multilib \
-     build-essential chrpath socat cpio python python3 python3-pip python3-expect \
-     xz which">
+     build-essential chrpath socat cpio python python3 python3-pip python3-pexpect \
+     xz-utils debianutils iputils-ping">
 <!ENTITY FEDORA_HOST_PACKAGES_ESSENTIAL "gawk make wget tar bzip2 gzip python3 unzip perl patch \
      diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath \
      ccache perl-Data-Dumper perl-Text-ParseWords perl-Thread-Queue perl-bignum socat \
-     findutils which file cpio python python3-pip python3-expect xz which">
+     python3-pexpect findutils which file cpio python python3-pip xz which">
 <!ENTITY OPENSUSE_HOST_PACKAGES_ESSENTIAL "python gcc gcc-c++ git chrpath make wget python-xml \
      diffstat makeinfo python-curses patch socat python3 python3-curses tar python3-pip \
-     python3-expect xz which">
-<!ENTITY CENTOS_HOST_PACKAGES_ESSENTIAL "gawk make wget tar bzip2 gzip python unzip perl patch \
+     python3-pexpect xz which">
+<!ENTITY CENTOS_HOST_PACKAGES_ESSENTIAL "-y epel-release
+     $ sudo yum makecache
+     $ sudo yum install gawk make wget tar bzip2 gzip python unzip perl patch \
      diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath socat \
-     perl-Data-Dumper perl-Text-ParseWords perl-Thread-Queue python3-pip python3-expect xz \
+     perl-Data-Dumper perl-Text-ParseWords perl-Thread-Queue python34-pip xz \
      which">

documentation/profile-manual/profile-manual.xml

@@ -81,6 +81,11 @@
                 <date>May 2017</date>
                 <revremark>Released with the Yocto Project 2.3 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>2.4</revnumber>
+                <date>Usually October</date>
+                <revremark>Released with the Yocto Project 2.4 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>

documentation/ref-manual/closer-look.xml

@@ -867,6 +867,19 @@
             <para>
                 This step in the build process consists of three tasks:
                 <itemizedlist>
+                    <listitem><para>
+                        <emphasis><link linkend='ref-tasks-prepare_recipe_sysroot'><filename>do_prepare_recipe_sysroot</filename></link>:</emphasis>
+                        This task sets up the two sysroots in
+                        <filename>${</filename><link linkend='var-WORKDIR'><filename>WORKDIR</filename></link><filename>}</filename>
+                        (i.e. <filename>recipe-sysroot</filename> and
+                        <filename>recipe-sysroot-native</filename>) so that
+                        the sysroots contain the contents of the
+                        <link linkend='ref-tasks-populate_sysroot'><filename>do_populate_sysroot</filename></link>
+                        tasks of the recipes on which the recipe
+                        containing the tasks depends.
+                        A sysroot exists for both the target and for the native
+                        binaries, which run on the host system.
+                        </para></listitem>
                     <listitem><para><emphasis><filename>do_configure</filename>:</emphasis>
                         This task configures the source by enabling and
                         disabling any build-time and configuration options for
@@ -1054,7 +1067,7 @@
 
             <para>
                 Package installation is under control of the package manager
-                (e.g. smart/rpm, opkg, or apt/dpkg) regardless of whether or
+                (e.g. dnf/rpm, opkg, or apt/dpkg) regardless of whether or
                 not package management is enabled for the target.
                 At the end of the process, if package management is not
                 enabled for the target, the package manager's data files
@@ -1392,17 +1405,6 @@
                 relationship the function needs to be passed.
                 The function returns a True or False value.
             </para>
-
-            <para>
-                Once the setscene process completes, the OpenEmbedded build
-                system has a list of tasks that it believes it can "accelerate"
-                and therefore does not need to run.
-                There is a final function call to the function specified by the
-                <ulink url='&YOCTO_DOCS_BB_URL;#var-BB_SETSCENE_VERIFY_FUNCTION2'><filename>BB_SETSCENE_VERIFY_FUNCTION2</filename></ulink>
-                variable that is able to require the tasks to be run that
-                that the OpenEmbedded build system initially was going to
-                skip.
-            </para>
         </section>
     </section>
 

documentation/ref-manual/introduction.xml

@@ -44,75 +44,114 @@
     <para>
         This reference manual consists of the following:
         <itemizedlist>
-            <listitem><para><emphasis>
-                <link linkend='usingpoky'>Using the Yocto Project</link>:</emphasis>
-                Provides an overview of the components that make up the Yocto Project
-                followed by information about debugging images created in the Yocto Project.
+            <listitem><para>
+                <emphasis>
+                <link linkend='usingpoky'>Using the Yocto Project</link>:
+                </emphasis>
+                Provides an overview of the components that make up the Yocto
+                Project followed by information about debugging images created
+                in the Yocto Project.
                 </para></listitem>
-            <listitem><para><emphasis>
-                <link linkend='closer-look'>A Closer Look at the Yocto Project Development Environment</link>:</emphasis>
+            <listitem><para>
+                <emphasis>
+                <link linkend='closer-look'>A Closer Look at the Yocto Project Development Environment</link>:
+                </emphasis>
                 Provides a more detailed look at the Yocto Project development
                 environment within the context of development.
                 </para></listitem>
-            <listitem><para><emphasis>
-                <link linkend='technical-details'>Technical Details</link>:</emphasis>
-                Describes fundamental Yocto Project components as well as an explanation
-                behind how the Yocto Project uses shared state (sstate) cache to speed build time.
+            <listitem><para>
+                <emphasis>
+                <link linkend='technical-details'>Technical Details</link>:
+                </emphasis>
+                Describes fundamental Yocto Project components as well as an
+                explanation behind how the Yocto Project uses shared state
+                (sstate) cache to speed build time.
                 </para></listitem>
-            <listitem><para><emphasis>
-                <link linkend='migration'>Migrating to a Newer Yocto Project Release</link>:</emphasis>
+            <listitem><para>
+                <emphasis>
+                <link linkend='migration'>Migrating to a Newer Yocto Project Release</link>:
+                </emphasis>
                 Describes release-specific information that helps you move from
                 one Yocto Project Release to another.
                 </para></listitem>
-            <listitem><para><emphasis>
-                <link linkend='ref-structure'>Directory Structure</link>:</emphasis>
-                Describes the
-                <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink> created
-                either by unpacking a released Yocto Project tarball on your host development system,
-                or by cloning the upstream
-                <ulink url='&YOCTO_DOCS_DEV_URL;#poky'>Poky</ulink> Git repository.
+            <listitem><para>
+                <emphasis>
+                <link linkend='ref-structure'>Directory Structure</link>:
+                </emphasis> Describes the
+                <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+                created either by unpacking a released Yocto Project tarball on
+                your host development system, or by cloning the upstream
+                <ulink url='&YOCTO_DOCS_DEV_URL;#poky'>Poky</ulink>
+                Git repository.
                 </para></listitem>
-            <listitem><para><emphasis>
-                <link linkend='ref-classes'>Classes</link>:</emphasis>
-                Describes the classes used in the Yocto Project.</para></listitem>
-            <listitem><para><emphasis>
-                <link linkend='ref-tasks'>Tasks</link>:</emphasis>
+            <listitem><para>
+                <emphasis>
+                <link linkend='ref-classes'>Classes</link>:
+                </emphasis>
+                Describes the classes used in the Yocto Project.
+                </para></listitem>
+            <listitem><para>
+                <emphasis>
+                <link linkend='ref-tasks'>Tasks</link>:
+                </emphasis>
                 Describes the tasks defined by the OpenEmbedded build system.
                 </para></listitem>
-            <listitem><para><emphasis>
-                <link linkend='ref-devtool-reference'><filename>devtool</filename> Quick Reference</link>:</emphasis>
+            <listitem><para>
+                <emphasis>
+                <link linkend='ref-devtool-reference'><filename>devtool</filename> Quick Reference</link>:
+                </emphasis>
                 Provides a quick reference for the <filename>devtool</filename>
                 command.
                 </para></listitem>
-            <listitem><para><emphasis>
-                <link linkend='ref-qa-checks'>QA Error and Warning Messages</link>:</emphasis>
+            <listitem><para>
+                <emphasis>
+                <link linkend='ref-qa-checks'>QA Error and Warning Messages</link>:
+                </emphasis>
                 Lists and describes QA warning and error messages.
                 </para></listitem>
-            <listitem><para><emphasis>
-                <link linkend='ref-images'>Images</link>:</emphasis>
+            <listitem><para>
+                <emphasis>
+                <link linkend='ref-images'>Images</link>:
+                </emphasis>
                 Describes the standard images that the Yocto Project supports.
                 </para></listitem>
-            <listitem><para><emphasis>
-                <link linkend='ref-features'>Features</link>:</emphasis>
-                Describes mechanisms for creating distribution, machine, and image
-                features during the build process using the OpenEmbedded build system.</para></listitem>
-            <listitem><para><emphasis>
-                <link linkend='ref-variables-glos'>Variables Glossary</link>:</emphasis>
-                Presents most variables used by the OpenEmbedded build system, which
-                uses BitBake.
-                Entries describe the function of the variable and how to apply them.
+            <listitem><para>
+                <emphasis>
+                <link linkend='ref-features'>Features</link>:
+                </emphasis>
+                Describes mechanisms for creating distribution, machine, and
+                image features during the build process using the OpenEmbedded
+                build system.
+                </para></listitem>
+            <listitem><para>
+                <emphasis>
+                <link linkend='ref-variables-glos'>Variables Glossary</link>:
+                </emphasis>
+                Presents most variables used by the OpenEmbedded build system,
+                which uses BitBake.
+                Entries describe the function of the variable and how to
+                apply them.
+                </para></listitem>
+            <listitem><para>
+                <emphasis>
+                <link linkend='ref-varlocality'>Variable Context</link>:
+                </emphasis>
+                Provides variable locality or context.
+                </para></listitem>
+            <listitem><para>
+                <emphasis>
+                <link linkend='faq'>FAQ</link>:
+                </emphasis>
+                Provides answers for commonly asked questions in the Yocto
+                Project development environment.
+                </para></listitem>
+            <listitem><para>
+                <emphasis>
+                <link linkend='resources'>Contributions and Additional Information</link>:
+                </emphasis>
+                Provides an overview of methods by which you can
+                contribute to and participate in the Yocto Project.
                 </para></listitem>
-            <listitem><para><emphasis>
-                <link linkend='ref-varlocality'>Variable Context</link>:</emphasis>
-                Provides variable locality or context.</para></listitem>
-            <listitem><para><emphasis>
-                <link linkend='faq'>FAQ</link>:</emphasis>
-                Provides answers for commonly asked questions in the Yocto Project
-                development environment.</para></listitem>
-            <listitem><para><emphasis>
-                <link linkend='resources'>Contributing to the Yocto Project</link>:</emphasis>
-                Provides guidance on how you can contribute back to the Yocto
-                Project.</para></listitem>
         </itemizedlist>
     </para>
 </section>
@@ -368,8 +407,28 @@
                         Packages needed to build an image for a headless
                         system:
                         <literallayout class='monospaced'>
-     $ sudo yum install &CENTOS_HOST_PACKAGES_ESSENTIAL;
-                        </literallayout></para></listitem>
+     $ sudo yum install &CENTOS_HOST_PACKAGES_ESSENTIAL; SDL-devel xterm
+                        </literallayout>
+                        <note><title>Notes</title>
+                            <itemizedlist>
+                                <listitem><para>
+                                    Extra Packages for Enterprise Linux
+                                    (i.e. <filename>epel-release</filename>)
+                                    is a collection of packages from Fedora
+                                    built on RHEL/CentOS for easy installation
+                                    of packages not included in enterprise
+                                    Linux by default.
+                                    You need to install these packages
+                                    separately.
+                                    </para></listitem>
+                                <listitem><para>
+                                    The <filename>makecache</filename> command
+                                    consumes additional Metadata from
+                                    <filename>epel-release</filename>.
+                                    </para></listitem>
+                            </itemizedlist>
+                        </note>
+                        </para></listitem>
                     <listitem><para><emphasis>Graphical and Eclipse Plug-In Extras:</emphasis>
                         Packages recommended if the host system has graphics
                         support or if you are going to use the Eclipse

documentation/ref-manual/migration.xml

@@ -3689,7 +3689,7 @@ $ runqemu qemux86-64 tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.
                     by <filename>BB_SETSCENE_VERIFY_FUNCTION</filename>
                     needed to change signature.
                     Consequently, a new variable named
-                    <ulink url='&YOCTO_DOCS_BB_URL;#var-BB_SETSCENE_VERIFY_FUNCTION2'><filename>BB_SETSCENE_VERIFY_FUNCTION2</filename></ulink>
+                    <filename>BB_SETSCENE_VERIFY_FUNCTION2</filename>
                     has been added allowing multiple versions of BitBake
                     to work with suitably written metadata, which includes
                     OpenEmbedded-Core and Poky.
@@ -3955,6 +3955,768 @@ $ runqemu qemux86-64 tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.
     </section>
 </section>
 
+<section id='moving-to-the-yocto-project-2.3-release'>
+    <title>Moving to the Yocto Project 2.3 Release</title>
+
+    <para>
+        This section provides migration information for moving to the
+        Yocto Project 2.3 Release from the prior release.
+    </para>
+
+    <section id='migration-2.3-recipe-specific-sysroots'>
+        <title>Recipe-specific Sysroots</title>
+
+        <para>
+            The Open-Embedded build system now uses one sysroot per
+            recipe to resolve long-standing issues with configuration
+            script auto-detection of undeclared dependencies.
+            Consequently, you might find that some of your previously
+            written custom recipes are missing declared dependencies,
+            particularly those dependencies that are incidentally built
+            earlier in a typical build process and thus are already likely
+            to be present in the shared sysroot in previous releases.
+        </para>
+
+        <para>
+            Consider the following:
+            <itemizedlist>
+                <listitem><para>
+                    <emphasis>Declare Build-Time Dependencies:</emphasis>
+                    Because of this new feature, you must explicitly
+                    declare all build-time dependencies for your recipe.
+                    If you do not declare these dependencies, they are not
+                    populated into the sysroot for the recipe.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis>Specify Pre-Installation and Post-Installation
+                    Native Tool Dependencies:</emphasis>
+                    You must specifically specify any special native tool
+                    dependencies of <filename>pkg_preinst</filename> and
+                    <filename>pkg_postinst</filename> scripts by using the
+                    <link linkend='var-PACKAGE_WRITE_DEPS'><filename>PACKAGE_WRITE_DEPS</filename></link>
+                    variable.
+                    Specifying these dependencies ensures that these tools
+                    are available if these scripts need to be run on the
+                    build host during the
+                    <link linkend='ref-tasks-rootfs'><filename>do_rootfs</filename></link>
+                    task.</para>
+
+                    <para>As an example, see the <filename>dbus</filename>
+                    recipe.
+                    You will see that this recipe has a
+                    <filename>pkg_postinst</filename> that calls
+                    <filename>systemctl</filename> if "systemd" is in
+                    <link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link>.
+                    In the example,
+                    <filename>systemd-systemctl-native</filename> is added to
+                    <filename>PACKAGE_WRITE_DEPS</filename>, which is also
+                    conditional on "systemd" being in
+                    <filename>DISTRO_FEATURES</filename>.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis>Examine Recipes that Use
+                    <filename>SSTATEPOSTINSTFUNCS</filename>:</emphasis>
+                    You need to examine any recipe that uses
+                    <filename>SSTATEPOSTINSTFUNCS</filename> and determine
+                    steps to take.</para>
+
+                    <para>Functions added to
+                    <filename>SSTATEPOSTINSTFUNCS</filename> are still
+                    called as they were in previous Yocto Project releases.
+                    However, since a separate sysroot is now being populated
+                    for every recipe and if existing functions being called
+                    through <filename>SSTATEPOSTINSTFUNCS</filename> are
+                    doing relocation, then you will need to change these
+                    to use a post-installation script that is installed by a
+                    function added to
+                    <link linkend='var-SYSROOT_PREPROCESS_FUNCS'><filename>SYSROOT_PREPROCESS_FUNCS</filename></link>.
+                    </para>
+
+                    <para>For an example, see the
+                    <filename>pixbufcache</filename> class in
+                    <filename>meta/classes/</filename> in the Yocto Project
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-repositories'>Source Repositories</ulink>.
+                    <note>
+                        The <filename>SSTATEPOSTINSTFUNCS</filename> variable
+                        itself is now deprecated in favor of the
+                        <filename>do_populate_sysroot[postfuncs]</filename>
+                        task.
+                        Consequently, if you do still have any function or
+                        functions that need to be called after the sysroot
+                        component is created for a recipe, then you would be
+                        well advised to take steps to use a post installation
+                        script as described previously.
+                        Taking these steps prepares your code for when
+                        <filename>SSTATEPOSTINSTFUNCS</filename> is
+                        removed in a future Yocto Project release.
+                    </note>
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis>Specify Which
+                    <filename>STAGING_DIR_NATIVE</filename> is Used:</emphasis>
+                    Because the shared sysroot is now gone, the scripts
+                    <filename>oe-find-native-sysroot</filename> and
+                    <filename>oe-run-native</filename> have been changed such
+                    that you need to specify which recipe's
+                    <link linkend='var-STAGING_DIR_NATIVE'><filename>STAGING_DIR_NATIVE</filename></link>
+                    is used.
+                    </para></listitem>
+            </itemizedlist>
+            <note>
+                You can find more information on how recipe-specific sysroots
+                work in the
+                "<link linkend='ref-classes-staging'><filename>staging.bbclass</filename></link>"
+                section.
+            </note>
+        </para>
+    </section>
+
+    <section id='migration-2.3-path-variable'>
+        <title><filename>PATH</filename> Variable</title>
+
+        <para>
+            Within the environment used to run build tasks, the environment
+            variable <filename>PATH</filename> is now sanitized such that
+            the normal native binary paths
+            (<filename>/bin</filename>, <filename>/sbin</filename>,
+            <filename>/usr/bin</filename> and so forth) are
+            removed and a directory containing symbolic links linking only
+            to the binaries from the host mentioned in the
+            <link linkend='var-HOSTTOOLS'><filename>HOSTTOOLS</filename></link>
+            and
+            <link linkend='var-HOSTTOOLS_NONFATAL'><filename>HOSTTOOLS_NONFATAL</filename></link>
+            variables is added to <filename>PATH</filename>.
+        </para>
+
+        <para>
+            Consequently, any native binaries provided by the host that you
+            need to call needs to be in one of these two variables at
+            the configuration level.
+        </para>
+
+        <para>
+            Alternatively, you can add a native recipe (i.e.
+            <filename>-native</filename>) that provides the
+            binary to the recipe's
+            <link linkend='var-DEPENDS'><filename>DEPENDS</filename></link>
+            value.
+            <note>
+                <filename>PATH</filename> is not sanitized in the same way
+                within <filename>devshell</filename>.
+                If it were, you would have difficulty running host tools for
+                development and debugging within the shell.
+            </note>
+        </para>
+    </section>
+
+    <section id='migration-2.3-scripts'>
+        <title>Changes to Scripts</title>
+
+        <para>
+            The following changes to scripts took place:
+            <itemizedlist>
+                <listitem><para>
+                    <emphasis><filename>oe-find-native-sysroot</filename>:</emphasis>
+                    The usage for the
+                    <filename>oe-find-native-sysroot</filename> script has
+                    changed to the following:
+                    <literallayout class='monospaced'>
+     $ . oe-find-native-sysroot <replaceable>recipe</replaceable>
+                    </literallayout>
+                    You must now supply a recipe for
+                    <replaceable>recipe</replaceable> as part of the command.
+                    Prior to the Yocto Project &DISTRO; release, it was not
+                    necessary to provide the script with the command.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis><filename>oe-run-native</filename>:</emphasis>
+                    The usage for the
+                    <filename>oe-run-native</filename> script has changed
+                    to the following:
+                    <literallayout class='monospaced'>
+     $ oe-run-native <replaceable>native_recipe</replaceable> <replaceable>tool</replaceable>
+                    </literallayout>
+                    You must supply the name of the native recipe and the tool
+                    you want to run as part of the command.
+                    Prior to the Yocto Project &DISTRO; release, it was not
+                    necessary to provide the native recipe with the command.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis><filename>cleanup-workdir</filename>:</emphasis>
+                    The <filename>cleanup-workdir</filename> script has been
+                    removed because the script was found to be deleting
+                    files it should not have, which lead to broken build
+                    trees.
+                    Rather than trying to delete portions of
+                    <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link>
+                    and getting it wrong, it is recommended that you
+                    delete <filename>TMPDIR</filename> and have it restored
+                    from shared state (sstate) on subsequent builds.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis><filename>wipe-sysroot</filename>:</emphasis>
+                    The <filename>wipe-sysroot</filename> script has been
+                    removed as it is no longer needed with recipe-specific
+                    sysroots.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-2.3-functions'>
+        <title>Changes to Functions</title>
+
+        <para>
+            The previously deprecated
+            <filename>bb.data.getVar()</filename>,
+            <filename>bb.data.setVar()</filename>, and
+            related functions have been removed in favor of
+            <filename>d.getVar()</filename>,
+            <filename>d.setVar()</filename>, and so forth.
+        </para>
+
+        <para>
+            You need to fix any references to these old functions.
+        </para>
+    </section>
+
+    <section id='migration-2.3-bitbake-changes'>
+        <title>BitBake Changes</title>
+
+        <para>
+            The following changes took place for BitBake:
+            <itemizedlist>
+                <listitem><para>
+                    <emphasis>BitBake's Graphical Dependency Explorer UI Replaced:</emphasis>
+                    BitBake's graphical dependency explorer UI
+                    <filename>depexp</filename> was replaced by
+                    <filename>taskexp</filename> ("Task Explorer"), which
+                    provides a graphical way of exploring the
+                    <filename>task-depends.dot</filename> file.
+                    The data presented by Task Explorer is much more
+                    accurate than the data that was presented by
+                    <filename>depexp</filename>.
+                    Being able to visualize the data is an often requested
+                    feature as standard <filename>*.dot</filename> file
+                    viewers cannot usual cope with the size of
+                    the <filename>task-depends.dot</filename> file.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis>BitBake "-g" Output Changes:</emphasis>
+                    The <filename>package-depends.dot</filename> and
+                    <filename>pn-depends.dot</filename> files as previously
+                    generated using the <filename>bitbake -g</filename> command
+                    have been removed.
+                    A <filename>recipe-depends.dot</filename> file
+                    is now generated as a collapsed version of
+                    <filename>task-depends.dot</filename> instead.
+                    </para>
+
+                    <para>The reason for this change is because
+                    <filename>package-depends.dot</filename> and
+                    <filename>pn-depends.dot</filename> largely date back
+                    to a time before task-based execution and do not take
+                    into account task-level dependencies between recipes,
+                    which could be misleading.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis>Mirror Variable Splitting Changes:</emphasis>
+                    Mirror variables including
+                    <link linkend='var-MIRRORS'><filename>MIRRORS</filename></link>,
+                    <link linkend='var-PREMIRRORS'><filename>PREMIRRORS</filename></link>,
+                    and
+                    <link linkend='var-SSTATE_MIRRORS'><filename>SSTATE_MIRRORS</filename></link>
+                    can now separate values entirely with spaces.
+                    Consequently, you no longer need "\\n".
+                    BitBake looks for pairs of values, which simplifies usage.
+                    There should be no change required to existing mirror
+                    variable values themselves.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis>The Subversion (SVN) Fetcher Uses an "ssh" Parameter and Not an "rsh" Parameter:</emphasis>
+                    The SVN fetcher now takes an "ssh" parameter instead of an
+                    "rsh" parameter.
+                    This new optional parameter is used when the "protocol"
+                    parameter is set to "svn+ssh".
+                    You can only use the new parameter to specify the
+                    <filename>ssh</filename> program used by SVN.
+                    The SVN fetcher passes the new parameter through the
+                    <filename>SVN_SSH</filename> environment variable during
+                    the
+                    <link linkend='ref-tasks-fetch'><filename>do_fetch</filename></link>
+                    task.</para>
+
+                    <para>See the
+                    "<ulink url='&YOCTO_DOCS_BB_URL;#svn-fetcher'>Subversion (SVN) Fetcher (svn://)</ulink>"
+                    section in the Yocto Project BitBake User Manual for
+                    additional information.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis><filename>BB_SETSCENE_VERIFY_FUNCTION</filename>
+                    and <filename>BB_SETSCENE_VERIFY_FUNCTION2</filename>
+                    Removed:</emphasis>
+                    Because the mechanism they were part of is no longer
+                    necessary with recipe-specific sysroots, the
+                    <filename>BB_SETSCENE_VERIFY_FUNCTION</filename> and
+                    <filename>BB_SETSCENE_VERIFY_FUNCTION2</filename>
+                    variables have been removed.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-2.3-absolute-symlinks'>
+        <title>Absolute Symbolic Links</title>
+
+        <para>
+            Absolute symbolic links (symlinks) within staged files are no
+            longer permitted and now trigger an error.
+            Any explicit creation of symlinks can use the
+            <filename>lnr</filename> script, which is a replacement for
+            <filename>ln -r</filename>.
+        </para>
+
+        <para>
+            If the build scripts in the software that the recipe is building
+            are creating a number of absolute symlinks that need to be
+            corrected, you can inherit
+            <filename>relative_symlinks</filename> within the recipe to turn
+            those absolute symlinks into relative symlinks.
+        </para>
+    </section>
+
+    <section id='migration-2.3-gplv2-and-gplv3-moves'>
+        <title>GPLv2 Versions of GPLv3 Recipes Moved</title>
+
+        <para>
+            Older GPLv2 versions of GPLv3 recipes have moved to a
+            separate <filename>meta-gplv2</filename> layer.
+        </para>
+
+        <para>
+            If you use
+            <link linkend='var-INCOMPATIBLE_LICENSE'><filename>INCOMPATIBLE_LICENSE</filename></link>
+            to exclude GPLv3 or set
+            <link linkend='var-PREFERRED_VERSION'><filename>PREFERRED_VERSION</filename></link>
+            to substitute a GPLv2 version of a GPLv3 recipe, then you must add
+            the <filename>meta-gplv2</filename> layer to your configuration.
+            <note>
+                You can find <filename>meta-gplv2</filename> layer in the
+                OpenEmbedded layer index at
+                <ulink url='https://layers.openembedded.org/layerindex/branch/master/layer/meta-gplv2/'></ulink>.
+            </note>
+        </para>
+
+        <para>
+            These relocated GPLv2 recipes do not receive the same level of
+            maintenance as other core recipes.
+            The recipes do not get security fixes and upstream no longer
+            maintains them.
+            In fact, the upstream community is actively hostile towards people
+            that use the old versions of the recipes.
+            Moving these recipes into a separate layer both makes the different
+            needs of the recipes clearer and clearly identifies the number of
+            these recipes.
+            <note>
+                The long-term solution might be to move to BSD-licensed
+                replacements of the GPLv3 components for those that need to
+                exclude GPLv3-licensed components from the target system.
+                This solution will be investigated for future Yocto
+                Project releases.
+            </note>
+        </para>
+    </section>
+
+    <section id='migration-2.3-package-management-changes'>
+        <title>Package Management Changes</title>
+
+        <para>
+            The following package management changes took place:
+            <itemizedlist>
+                <listitem><para>
+                    Smart package manager is replaced by DNF package manager.
+                    Smart has become unmaintained upstream, is not ported
+                    to Python 3.x.
+                    Consequently, Smart needed to be replaced.
+                    DNF is the only feasible candidate.</para>
+                    <para>The change in functionality is that the on-target
+                    runtime package management from remote package feeds is
+                    now done with a different tool that has a
+                    different set of command-line options.
+                    If you have scripts that call the
+                    tool directly, or use its API, they need to be fixed.</para>
+                    <para>For more information, see the
+                    <ulink url='http://dnf.readthedocs.io/en/latest/'>DNF Documentation</ulink>.
+                    </para></listitem>
+                <listitem><para>
+                    Rpm 5.x is replaced with Rpm 4.x.
+                    This is done for two major reasons:
+                    <itemizedlist>
+                        <listitem><para>
+                            DNF is API-incompatible with Rpm 5.x and porting
+                            it and maintaining the port is non-trivial.
+                            </para></listitem>
+                        <listitem><para>
+                            Rpm 5.x itself has limited maintenance upstream,
+                            and the Yocto Project is one of the very few
+                            remaining users.
+                            </para></listitem>
+                    </itemizedlist>
+                    </para></listitem>
+                <listitem><para>
+                    Berkeley DB 6.x is removed and Berkeley DB 5.x becomes
+                    the default:
+                    <itemizedlist>
+                        <listitem><para>
+                            Version 6.x of Berkeley DB has largely been
+                            rejected by the open source community due to its
+                            AGPLv3 license.
+                            As a result, most mainstream open source projects
+                            that require DB are still developed and tested with
+                            DB 5.x.
+                            </para></listitem>
+                        <listitem><para>
+                            In OE-core, the only thing that was requiring
+                            DB 6.x was Rpm 5.x.
+                            Thus, no reason exists to continue carrying DB 6.x
+                            in OE-core.
+                            </para></listitem>
+                    </itemizedlist>
+                    </para></listitem>
+                <listitem><para>
+                    <filename>createrepo</filename> is replaced with
+                    <filename>createrepo_c</filename>.</para>
+                    <para><filename>createrepo_c</filename> is the current
+                    incarnation of the tool that generates remote repository
+                    metadata.
+                    It is written in C as compared to
+                    <filename>createrepo</filename>, which is written in
+                    Python.
+                    <filename>createrepo_c</filename> is faster and is
+                    maintained.
+                    </para></listitem>
+                <listitem><para>
+                    Architecture-independent RPM packages are "noarch"
+                    instead of "all".</para>
+                    <para>This change was made because too many places in
+                    DNF/RPM4 stack already make that assumption.
+                    Only the filenames and the architecture tag has changed.
+                    Nothing else has changed in OE-core system, particularly
+                    in the
+                    <link linkend='ref-classes-allarch'><filename>allarch.bbclass</filename></link>
+                    class.
+                    </para></listitem>
+                <listitem><para>
+                    Signing of remote package feeds using
+                    <filename>PACKAGE_FEED_SIGN</filename>
+                    is not currently supported.
+                    This issue will be fully addressed in a future
+                    Yocto Project release.
+                    See <ulink url='https://bugzilla.yoctoproject.org/show_bug.cgi?id=11209'>defect 11209</ulink>
+                    for more information on a solution to package feed
+                    signing with RPM in the Yocto Project 2.3 release.
+                    </para></listitem>
+                <listitem><para>
+                    OPKG now uses the libsolv backend for resolving package
+                    dependencies by default.
+                    This is vastly superior to OPKG's internal ad-hoc solver
+                    that was previously used.
+                    This change does have a small impact on disk (around
+                    500 KB) and memory footprint.
+                    <note>
+                        For further details on this change, see the
+                        <ulink url='http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?
+id=f4d4f99cfbc2396e49c1613a7d237b9e57f06f81'>commit message</ulink>.
+                    </note>
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-2.3-removed-recipes'>
+        <title>Removed Recipes</title>
+
+        <para>
+            The following recipes have been removed:
+            <itemizedlist>
+                <listitem><para>
+                    <emphasis><filename>linux-yocto 4.8:</filename></emphasis>
+                    Version 4.8 has been removed.
+                    Versions 4.1 (LTSI), 4.4 (LTS), 4.9 (LTS/LTSI) and 4.10
+                    are now present.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis><filename>python-smartpm:</filename></emphasis>
+                    Functionally replaced by <filename>dnf</filename>.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis><filename>createrepo:</filename></emphasis>
+                    Replaced by the <filename>createrepo-c</filename> recipe.
+                    </para></listitem>
+                 <listitem><para>
+                    <emphasis><filename>rpmresolve:</filename></emphasis>
+                    No longer needed with the move to RPM 4 as RPM itself is
+                    used instead.
+                    </para></listitem>
+                 <listitem><para>
+                    <emphasis><filename>gstreamer:</filename></emphasis>
+                    Removed the GStreamer Git version recipes as they have
+                    been stale.
+                    <filename>1.10.</filename><replaceable>x</replaceable>
+                    recipes are still present.
+                    </para></listitem>
+                 <listitem><para>
+                    <emphasis><filename>alsa-conf-base:</filename></emphasis>
+                    Merged into <filename>alsa-conf</filename> since
+                    <filename>libasound</filename> depended on both.
+                    Essentially, no way existed to install only one of these.
+                    </para></listitem>
+                 <listitem><para>
+                    <emphasis><filename>tremor:</filename></emphasis>
+                    Moved to <filename>meta-multimedia</filename>.
+                    Fixed-integer Vorbis decoding is not
+                    needed by current hardware.
+                    Thus, GStreamer's ivorbis plugin has been disabled
+                    by default eliminating the need for the
+                    <filename>tremor</filename> recipe in OE-Core.
+                    </para></listitem>
+                 <listitem><para>
+                    <emphasis><filename>gummiboot:</filename></emphasis>
+                    Replaced by <filename>systemd-boot</filename>.
+                    </para></listitem>
+           </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-2.3-wic-changes'>
+        <title>Wic Changes</title>
+
+        <para>
+            The following changes have been made to Wic:
+            <note>
+                For more information on Wic, see the
+                "<ulink url='&YOCTO_DOCS_DEV_URL;#creating-partitioned-images'>Creating Partitioned Images</ulink>"
+                section in the Yocto Project Development Manual.
+            </note>
+            <itemizedlist>
+                <listitem><para>
+                    <emphasis>Default Output Directory Changed:</emphasis>
+                    Wic's default output directory is now the current directory
+                    by default instead of the unusual
+                    <filename>/var/tmp/wic</filename>.</para>
+
+                    <para>The "-o" and "--outdir" options remain unchanged
+                    and are used to specify your preferred output directory
+                    if you do not want to use the default directory.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis>fsimage Plug-in Removed:</emphasis>
+                    The Wic fsimage plug-in has been removed as it duplicates
+                    functionality of the rawcopy plug-in.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-2.3-qa-changes'>
+        <title>QA Changes</title>
+
+        <para>
+            The following QA checks have changed:
+            <itemizedlist>
+                <listitem><para>
+                    <emphasis><filename>unsafe-references-in-binaries</filename>:</emphasis>
+                    The <filename>unsafe-references-in-binaries</filename>
+                    QA check, which was disabled by default, has now been
+                    removed.
+                    This check was intended to detect binaries in
+                    <filename>/bin</filename> that link to libraries in
+                    <filename>/usr/lib</filename> and have the case where
+                    the user has <filename>/usr</filename> on a separate
+                    filesystem to <filename>/</filename>.</para>
+
+                    <para>The removed QA check was buggy.
+                    Additionally, <filename>/usr</filename> residing on a
+                    separate partition from <filename>/</filename> is now
+                    a rare configuration.
+                    Consequently,
+                    <filename>unsafe-references-in-binaries</filename> was
+                    removed.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis><filename>file-rdeps</filename>:</emphasis>
+                    The <filename>file-rdeps</filename> QA check is now an
+                    error by default instead of a warning.
+                    Because it is an error instead of a warning, you need to
+                    address missing runtime dependencies.</para>
+
+                    <para>For additional information, see the
+                    <link linkend='ref-classes-insane'><filename>insane</filename></link>
+                    class and the
+                    "<link linkend='qa-errors-and-warnings'>Errors and Warnings</link>"
+                    section.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-2.3-miscellaneous-changes'>
+        <title>Miscellaneous Changes</title>
+
+        <para>
+            The following miscellaneous changes have occurred:
+            <itemizedlist>
+                <listitem><para>
+                    In this release, a number of recipes have been changed to
+                    ignore the <filename>largefile</filename>
+                    <link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link>
+                    item, enabling large file support unconditionally.
+                    This feature has always been enabled by default.
+                    Disabling the feature has not been widely tested.
+                    <note>
+                        Future releases of the Yocto Project will remove
+                        entirely the ability to disable the
+                        <filename>largefile</filename> feature,
+                        which would make it unconditionally enabled everywhere.
+                    </note>
+                    </para></listitem>
+                <listitem><para>
+                    If the
+                    <link linkend='var-DISTRO_VERSION'><filename>DISTRO_VERSION</filename></link>
+                    value contains the value of the
+                    <link linkend='var-DATE'><filename>DATE</filename></link>
+                    variable, which is the default between Poky releases,
+                    the <filename>DATE</filename> value is explicitly excluded
+                    from <filename>/etc/issue</filename> and
+                    <filename>/etc/issue.net</filename>, which is displayed at
+                    the login prompt, in order to avoid conflicts with
+                    Multilib enabled.
+                    Regardless, the <filename>DATE</filename> value is
+                    inaccurate if the <filename>base-files</filename>
+                    recipe is restored from shared state (sstate) rather
+                    than rebuilt.</para>
+
+                    <para>If you need the build date recorded in
+                    <filename>/etc/issue*</filename> or anywhere else in your
+                    image, a better method is to define a post-processing
+                    function to do it and have the function called from
+                    <link linkend='var-ROOTFS_POSTPROCESS_COMMAND'><filename>ROOTFS_POSTPROCESS_COMMAND</filename></link>.
+                    Doing so ensures the value is always up-to-date with the
+                    created image.
+                    </para></listitem>
+                <listitem><para>
+                    Dropbear's <filename>init</filename> script now disables
+                    DSA host keys by default.
+                    This change is in line with the systemd service
+                    file, which supports RSA keys only, and with recent
+                    versions of OpenSSH, which deprecates DSA host keys.
+                    </para></listitem>
+                <listitem><para>
+                    The
+                    <link linkend='ref-classes-buildhistory'><filename>buildhistory</filename></link>
+                    class now correctly uses tabs as separators between all
+                    columns in <filename>installed-package-sizes.txt</filename>
+                    in order to aid import into other tools.
+                    </para></listitem>
+                <listitem><para>
+                    The <filename>USE_LDCONFIG</filename> variable has been
+                    replaced with the "ldconfig"
+                    <link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link>
+                    feature.
+                    Distributions that previously set:
+                    <literallayout class='monospaced'>
+     USE_LDCONFIG = "0"
+                    </literallayout>
+                    should now instead use the following:
+                    <literallayout class='monospaced'>
+     DISTRO_FEATURES_BACKFILL_CONSIDERED_append = " ldconfig"
+                    </literallayout>
+                    </para></listitem>
+                <listitem><para>
+                    The default value of
+                    <link linkend='var-COPYLEFT_LICENSE_INCLUDE'><filename>COPYLEFT_LICENSE_INCLUDE</filename></link>
+                    now includes all versions of AGPL licenses in addition
+                    to GPL and LGPL.
+                    <note>
+                        The default list is not intended to be guaranteed
+                        as a complete safe list.
+                        You should seek legal advice based on what you are
+                        distributing if you are unsure.
+                    </note>
+                    </para></listitem>
+                <listitem><para>
+                    Kernel module packages are now suffixed with the kernel
+                    version in order to allow module packages from multiple
+                    kernel versions to co-exist on a target system.
+                    If you wish to return to the previous naming scheme
+                    that does not include the version suffix, use the
+                    following:
+                    <literallayout class='monospaced'>
+     KERNEL_MODULE_PACKAGE_SUFFIX to ""
+                    </literallayout>
+                    </para></listitem>
+                <listitem><para>
+                    Removal of <filename>libtool</filename>
+                    <filename>*.la</filename> files is now enabled by default.
+                    The <filename>*.la</filename> files are not actually
+                    needed on Linux and relocating them is an unnecessary
+                    burden.</para>
+
+                    <para>If you need to preserve these
+                    <filename>.la</filename> files (e.g. in a custom
+                    distribution), you must change
+                    <link linkend='var-INHERIT_DISTRO'><filename>INHERIT_DISTRO</filename></link>
+                    such that "remove-libtool" is not included in the value.
+                    </para></listitem>
+                <listitem><para>
+                    Extensible SDKs built for GCC 5+ now refuse to install on a
+                    distribution where the host GCC version is 4.8 or 4.9.
+                    This change resulted from the fact that the installation
+                    is known to fail due to the way the
+                    <filename>uninative</filename> shared state (sstate)
+                    package is built.
+                    See the
+                    <link linkend='ref-classes-uninative'><filename>uninative</filename></link>
+                    class for additional information.
+                    </para></listitem>
+                <listitem><para>
+                    All native and nativesdk recipes now use a separate
+                    <link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link>
+                    value instead of sharing the value used by recipes for the
+                    target, in order to avoid unnecessary rebuilds.</para>
+
+                    <para>The <filename>DISTRO_FEATURES</filename> for
+                    <filename>native</filename> recipes is
+                    <link linkend='var-DISTRO_FEATURES_NATIVE'><filename>DISTRO_FEATURES_NATIVE</filename></link>
+                    added to an intersection of
+                    <filename>DISTRO_FEATURES</filename> and
+                    <link linkend='var-DISTRO_FEATURES_FILTER_NATIVE'><filename>DISTRO_FEATURES_FILTER_NATIVE</filename></link>.
+                    </para>
+
+                    <para>For nativesdk recipes, the
+                    corresponding variables are
+                    <link linkend='var-DISTRO_FEATURES_NATIVESDK'><filename>DISTRO_FEATURES_NATIVESDK</filename></link>
+                    and
+                    <link linkend='var-DISTRO_FEATURES_FILTER_NATIVESDK'><filename>DISTRO_FEATURES_FILTER_NATIVESDK</filename></link>.
+                    </para></listitem>
+                <listitem><para>
+                    The <filename>FILESDIR</filename>
+                    variable, which was previously deprecated and rarely used,
+                    has now been removed.
+                    You should change any recipes that set
+                    <filename>FILESDIR</filename> to set
+                    <link linkend='var-FILESPATH'><filename>FILESPATH</filename></link>
+                    instead.
+                    </para></listitem>
+                <listitem><para>
+                    The <filename>MULTIMACH_HOST_SYS</filename>
+                    variable has been removed as it is no longer needed
+                    with recipe-specific sysroots.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+</section>
 </chapter>
 <!--
 vim: expandtab tw=80 ts=4

documentation/ref-manual/ref-bitbake.xml

@@ -414,7 +414,7 @@ Options:
   -l DEBUG_DOMAINS, --log-domains=DEBUG_DOMAINS
                         Show debug logging for the specified logging domains
   -P, --profile         Profile the command and save reports.
-  -u UI, --ui=UI        The user interface to use (e.g. knotty and depexp).
+  -u UI, --ui=UI        The user interface to use (e.g. knotty and taskexp).
   -t SERVERTYPE, --servertype=SERVERTYPE
                         Choose which server to use, process or xmlrpc.
   --revisions-changed   Set the exit code depending on whether upstream

documentation/ref-manual/ref-classes.xml

@@ -1301,19 +1301,27 @@
     <title><filename>image-live.bbclass</filename></title>
 
     <para>
-        The <filename>image-live</filename> class supports building "live"
-        images.
+        This class controls building "live" (i.e. HDDIMG and ISO) images.
+        Live images contain syslinux for legacy booting, as well as the
+        bootloader specified by
+        <link linkend='var-EFI_PROVIDER'><filename>EFI_PROVIDER</filename></link>
+        if
+        <link linkend='var-MACHINE_FEATURES'><filename>MACHINE_FEATURES</filename></link>
+        contains "efi".
     </para>
 
     <para>
         Normally, you do not use this class directly.
         Instead, you add "live" to
         <link linkend='var-IMAGE_FSTYPES'><filename>IMAGE_FSTYPES</filename></link>.
+        You can selectively build just one of these types through the
+        <link linkend='var-NOISO'><filename>NOISO</filename></link>
+        and
+        <link linkend='var-NOHDD'><filename>NOHDD</filename></link> variables.
         For example, if you were building an ISO image, you would add "live"
         to <filename>IMAGE_FSTYPES</filename>, set the
-        <link linkend='var-NOISO'><filename>NOISO</filename></link> variable to
-        "0" and the build system would use the <filename>image-live</filename>
-        class to build the ISO image.
+        <filename>NOISO</filename> variable to "0" and the build system would
+        use the <filename>image-live</filename> class to build the ISO image.
     </para>
 </section>
 
@@ -1755,6 +1763,9 @@
                 <link linkend='qa-issue-textrel'><filename>ELF binary</filename></link>
                 message for more information regarding runtime performance issues.
                 </para></listitem>
+<!--
+This check was removed for YP 2.3 release
+
             <listitem><para><emphasis><filename>unsafe-references-in-binaries:</filename></emphasis>
                 Reports when a binary installed in
                 <filename>${base_libdir}</filename>,
@@ -1776,6 +1787,7 @@
                     <filename>/usr</filename>.
                 </note>
                 </para></listitem>
+-->
             <listitem><para><emphasis><filename>unsafe-references-in-scripts:</filename></emphasis>
                 Reports when a script file installed in
                 <filename>${base_libdir}</filename>,
@@ -2216,6 +2228,14 @@
                 functionality specific to the respective native or target
                 case.</para></listitem>
         </itemizedlist>
+        <note><title>Warning</title>
+            When creating a recipe, you must follow this naming convention:
+            <literallayout class='monospaced'>
+     native-<replaceable>myrecipe</replaceable>.bb
+            </literallayout>
+            Not doing so can lead to subtle problems because code exists
+            that depends on the naming convention.
+        </note>
     </para>
 
     <para>
@@ -2258,6 +2278,14 @@
                 functionality specific to the respective SDK machine or target
                 case.</para></listitem>
         </itemizedlist>
+        <note><title>Warning</title>
+            When creating a recipe, you must follow this naming convention:
+            <literallayout class='monospaced'>
+     nativesdk-<replaceable>myrecipe</replaceable>.bb
+            </literallayout>
+            Not doing so can lead to subtle problems because code exists
+            that depends on the naming convention.
+        </note>
     </para>
 
     <para>
@@ -2374,7 +2402,7 @@
 
     <para>
         If you take the optional step to set up a repository (package feed)
-        on the development host that can be used by Smart, you can
+        on the development host that can be used by DNF, you can
         install packages from the feed while you are running the image
         on the target (i.e. runtime installation of packages).
         For more information, see the
@@ -3190,13 +3218,144 @@
     <title><filename>staging.bbclass</filename></title>
 
     <para>
-        The <filename>staging</filename> class provides the
-        <link linkend='ref-tasks-populate_sysroot'><filename>do_populate_sysroot</filename></link>
-        task, which stages files into the sysroot to make them available to
-        other recipes at build time.
-        The class is enabled by default because it is inherited by the
-        <link linkend='ref-classes-base'><filename>base</filename></link>
-        class.
+        The <filename>staging</filename> class installs files into individual
+        recipe work directories for sysroots.
+        The class contains the following key tasks:
+        <itemizedlist>
+            <listitem><para>
+                The
+                <link linkend='ref-tasks-populate_sysroot'><filename>do_populate_sysroot</filename></link>
+                task, which is responsible for handing the files that end up
+                in the recipe sysroots.
+                </para></listitem>
+            <listitem><para>
+                The
+                <link linkend='ref-tasks-prepare_recipe_sysroot'><filename>do_prepare_recipe_sysroot</filename></link>
+                task (a "partner" task to the
+                <filename>populate_sysroot</filename> task), which installs
+                the files into the individual recipe work directories (i.e.
+                <link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>).
+                </para></listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        The code in the <filename>staging</filename> class is complex and
+        basically works in two stages:
+        <itemizedlist>
+            <listitem><para>
+                <emphasis>Stage One:</emphasis>
+                The first stage addresses recipes that have files they want
+                to share with other recipes that have dependencies on the
+                originating recipe.
+                Normally these dependencies are installed through the
+                <link linkend='ref-tasks-install'><filename>do_install</filename></link>
+                task into
+                <filename>${</filename><link linkend='var-D'><filename>D</filename></link><filename>}</filename>.
+                The <filename>do_populate_sysroot</filename> task copies
+                a subset of these files into
+                <filename>${SYSROOT_DESTDIR}</filename>.
+                This subset of files is controlled by the
+                <link linkend='var-SYSROOT_DIRS'><filename>SYSROOT_DIRS</filename></link>,
+                <link linkend='var-SYSROOT_DIRS_NATIVE'><filename>SYSROOT_DIRS_NATIVE</filename></link>,
+                and
+                <link linkend='var-SYSROOT_DIRS_BLACKLIST'><filename>SYSROOT_DIRS_BLACKLIST</filename></link>
+                variables.
+                <note>
+                    Additionally, a recipe can customize the files further by
+                declaring a processing function in the
+                    <link linkend='var-SYSROOT_PREPROCESS_FUNCS'><filename>SYSROOT_PREPROCESS_FUNCS</filename></link>
+                    variable.
+                </note>
+                </para>
+
+                <para>
+                A shared state (sstate) object is built from these files
+                and the files are placed into a subdirectory of
+                <filename>tmp/sysroot-components/</filename>.
+                The files are scanned for hardcoded paths to the original
+                installation location.
+                If the location is found in text files, the hardcoded
+                locations are replaced by tokens and a list of the files
+                needing such replacements is created.
+                These adjustments are referred to as "FIXMEs".
+                The list of files that are scanned for paths is controlled by
+                the
+                <link linkend='var-SSTATE_SCAN_FILES'><filename>SSTATE_SCAN_FILES</filename></link>
+                variable.
+                </para></listitem>
+            <listitem><para>
+                <emphasis>Stage Two:</emphasis>
+                The second stage addresses recipes that want to use something
+                from another recipe and declare a dependency on that recipe
+                through the
+                <link linkend='var-DEPENDS'><filename>DEPENDS</filename></link>
+                variable.
+                The recipe will have a
+                <link linkend='ref-tasks-prepare_recipe_sysroot'><filename>do_prepare_recipe_sysroot</filename></link>
+                task and when
+                this task executes, it creates the
+                <filename>recipe-sysroot</filename> and
+                <filename>recipe-sysroot-native</filename> in the recipe
+                work directory (i.e.
+                <link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>.
+                The OpenEmbedded build system creates hard links to copies of the
+                relevant files from <filename>sysroot-components</filename>
+                into the recipe work directory.
+                <note>
+                    If hard links are not possible, the build system uses
+                    actual copies.
+                </note>
+                The build system then addresses any "FIXMEs" to paths as
+                defined from the list created in the first stage.
+                </para>
+
+                <para>
+                Finally, any files in <filename>${bindir}</filename>
+                within the sysroot that have the prefix
+                "<filename>postinst-</filename>" are executed.
+                <note>
+                    Although these files are not recommended for general use,
+                    the files do allow some issues such as user creation
+                    and module indexes to be addressed.
+                </note>
+                </para>
+
+                <para>
+                Because recipes can have other dependencies outside of
+                <filename>DEPENDS</filename> (e.g.
+                <filename>do_unpack[depends] += "tar-native:do_populate_sysroot"</filename>),
+                the sysroot creation function
+                <filename>extend_recipe_sysroot</filename> is also added as
+                a pre-function for those tasks whose dependencies are not
+                through <filename>DEPENDS</filename> but operate similarly.
+                </para>
+
+                <para>
+                When installing dependencies into the sysroot, the code
+                traverses the dependency graph and processes dependencies
+                in exactly the same way as the dependencies would or would not
+                be when installed from sstate.
+                This processing means, for example, a native tool would have
+                its native dependencies added but a target library would not
+                have its dependencies traversed or installed.
+                The same sstate dependency code is used so that
+                builds should be identical regardless of whether sstate
+                was used or not.
+                For a closer look, see the
+                <filename>setscene_depvalid()</filename> function in the
+                <link linkend='ref-classes-sstate'><filename>sstate</filename></link>
+                class.
+                </para>
+
+                <para>
+                The build system is careful to maintain manifests of the files
+                it installs so that any given dependency can be installed as
+                needed.
+                The sstate hash of the installed item is also stored so that
+                if it changes, the build system can reinstall it.
+                </para></listitem>
+        </itemizedlist>
     </para>
 </section>
 
@@ -3532,6 +3691,14 @@
         For an example, see the
         <filename>meta/conf/distro/include/yocto-uninative.inc</filename>.
     </para>
+
+    <para>
+        The <filename>uninative</filename> class is also used unconditionally
+        by the extensible SDK.
+        When building the extensible SDK,
+        <filename>uninative-tarball</filename> is built and the resulting
+        tarball is included within the SDK.
+    </para>
 </section>
 
 <section id='ref-classes-update-alternatives'>

documentation/ref-manual/ref-devtool-reference.xml

@@ -520,9 +520,9 @@
             the potential to not behave correctly when run on the target:
             <itemizedlist>
                 <listitem><para>
-                    You are deploying a new application to the target that
-                    has correctly defined runtime dependencies defined in
-                    recipe you used to build the application.
+                    You are deploying a new application to the target and
+                    the recipe you used to build the application had
+                    correctly defined runtime dependencies.
                     </para></listitem>
                 <listitem><para>
                     The target does not physically have the packages on which

documentation/ref-manual/ref-features.xml

@@ -195,6 +195,10 @@
                 <listitem><para><emphasis>keyboard:</emphasis> Include keyboard
                     support (e.g. keymaps will be loaded during boot).
                     </para></listitem>
+                <listitem><para><emphasis>ldconfig:</emphasis>
+                    Include support for ldconfig and
+                    <filename>ld.so.conf</filename> on the target.
+                    </para></listitem>
                 <listitem><para><emphasis>nfs:</emphasis> Include NFS client
                     support (for mounting NFS exports on device).
                     </para></listitem>

documentation/ref-manual/ref-manual.xml

@@ -112,6 +112,11 @@
                 <date>May 2017</date>
                 <revremark>Released with the Yocto Project 2.3 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>2.4</revnumber>
+                <date>Usually October</date>
+                <revremark>Released with the Yocto Project 2.4 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>

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

@@ -1170,45 +1170,6 @@ can be found then it should be implemented.  I can't find one at the moment.
             </listitem>
         </itemizedlist>
     </para>
-
-<!--
-Here are some messages that might be documented in the future.
-Right now we are not documenting them because the QA checks are not
-enabled by default:
-
-    <para>
-        <itemizedlist>
-            <listitem><para>
-                <literallayout class='monospaced'>
-     Desktop file issue: &lt;error&gt; [desktop]
-                </literallayout>
-                NEED A DESCRIPTION AND SOLUTION
-                </para></listitem>
-        </itemizedlist>
-    </para>
-
-    <para>
-        <itemizedlist>
-            <listitem><para>
-                <literallayout class='monospaced'>
-     &lt;packagename&gt;: &lt;file&gt;, installed in the base_prefix, requires a shared library under exec_prefix (&lt;exec_prefix&t;g) [unsafe-references-in-binaries]
-                </literallayout>
-                NEED A DESCRIPTION AND SOLUTION
-                </para></listitem>
-        </itemizedlist>
-    </para>
-
-    <para>
-        <itemizedlist>
-            <listitem><para>
-                <literallayout class='monospaced'>
-     &lt;packagename&gt;: Found a reference to &lt;exec_prefix&gt;/ in &lt;path&gt; - Shell scripts in base_bindir and base_sbindir should not reference anything in exec_prefix [unsafe-references-in-scripts]
-                </literallayout>
-                NEED A DESCRIPTION AND SOLUTION
-                </para></listitem>
-        </itemizedlist>
-    </para>
--->
 </section>
 
 <section id='configuring-and-disabling-qa-checks'>

documentation/ref-manual/ref-release-process.xml

@@ -117,6 +117,137 @@
     </para>
 </section>
 
+<section id='testing-and-quality-assurance'>
+    <title>Testing and Quality Assurance</title>
+
+    <para>
+        Part of the Yocto Project development and release process is quality
+        assurance through the execution of test strategies.
+        Test strategies provide the Yocto Project team a way to ensure a
+        release is validated.
+        Additionally, because the test strategies are visible to you as a
+        developer, you can validate your projects.
+        This section overviews the available test infrastructure used in the
+        Yocto Project.
+        For information on how to run available tests on your projects, see the
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing'>Performing Automated Runtime Testing</ulink>"
+        section in the Yocto Project Development Manual.
+    </para>
+
+    <para>
+        The QA/testing infrastructure is woven into the project to the point
+        where core developers take some of it for granted.
+        The infrastructure consists of the following pieces:
+        <itemizedlist>
+            <listitem><para>
+                <filename>bitbake-selftest</filename>:
+                A standalone command that runs unit tests on key pieces of
+                BitBake and its fetchers.
+                </para></listitem>
+            <listitem><para>
+                <link linkend='ref-classes-sanity'><filename>sanity.bbclass</filename></link>:
+                This automatically included class checks the build environment
+                for missing tools (e.g. <filename>gcc</filename>) or common
+                misconfigurations such as
+                <link linkend='var-MACHINE'><filename>MACHINE</filename></link>
+                set incorrectly.
+                </para></listitem>
+            <listitem><para>
+                <link linkend='ref-classes-insane'><filename>insane.bbclass</filename></link>:
+                This class checks the generated output from builds for sanity.
+                For example, if building for an ARM target, did the build
+                produce ARM binaries.
+                If, for example, the build produced PPC binaries then there
+                is a problem.
+                </para></listitem>
+            <listitem><para>
+                <link linkend='ref-classes-testimage*'><filename>testimage.bbclass</filename></link>:
+                This class performs runtime testing of images after they are
+                built.
+                The tests are usually used with
+                <ulink url='&YOCTO_DOCS_DEV_URL;#dev-manual-qemu'>QEMU</ulink>
+                to boot the images and check the combined runtime result
+                boot operation and functions.
+                However, the test can also use the IP address of a machine to
+                test.
+                </para></listitem>
+            <listitem><para>
+                <ulink url='&YOCTO_DOCS_DEV_URL;#testing-packages-with-ptest'><filename>ptest</filename></ulink>:
+                Runs tests against packages produced during the build for a
+                given piece of software.
+                The test allows the packages to be be run within a target
+                image.
+                </para></listitem>
+            <listitem><para>
+                <filename>oe-selftest</filename>:
+                Tests combination BitBake invocations.
+                These tests operate outside the OpenEmbedded build system
+                itself.
+                The <filename>oe-selftest</filename> can run all tests by
+                default or can run selected tests or test suites.
+                <note>
+                    Running <filename>oe-selftest</filename> requires
+                    host packages beyond the "Essential" grouping.
+                    See the
+                    "<link linkend='required-packages-for-the-host-development-system'>Required Packages for the Host Development System</link>"
+                    section for more information.
+                </note>
+                </para></listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        Originally, much of this testing was done manually.
+        However, significant effort has been made to automate the tests so
+        that more people can use them and the Yocto Project development team
+        can run them faster and more efficiently.
+    </para>
+
+    <para>
+        The Yocto Project's main Autobuilder
+        (<filename>autobuilder.yoctoproject.org</filename>) publicly tests
+        each Yocto Project release's code in the OE-Core, Poky, and BitBake
+        repositories.
+        The testing occurs for both the current state of the
+        "master" branch and also for submitted patches.
+        Testing for submitted patches usually occurs in the
+        "ross/mut" branch in the <filename>poky-contrib</filename> repository
+        (i.e. the master-under-test branch) or in the "master-next" branch
+        in the <filename>poky</filename> repository.
+        <note>
+            You can find all these branches in the Yocto Project
+            <ulink url='&YOCTO_DOCS_DEV_URL;#source-repositories'>Source Repositories</ulink>.
+        </note>
+        Testing within these public branches ensures in a publicly visible way
+        that all of the main supposed architectures and recipes in OE-Core
+        successfully build and behave properly.
+    </para>
+
+    <para>
+        Various features such as <filename>multilib</filename>, sub
+        architectures (e.g. <filename>x32</filename>,
+        <filename>poky-tiny</filename>, <filename>musl</filename>,
+        <filename>no-x11</filename> and and so forth),
+        <filename>bitbake-selftest</filename>, and
+        <filename>oe-selftest</filename> are tested as part of
+        the QA process of a release.
+        Complete testing and validation for a release takes the Autobuilder
+        workers several hours.
+        <note>
+            The Autobuilder workers are non-homogeneous, which means regular
+            testing across a variety of Linux distributions occurs.
+            The Autobuilder is limited to only testing QEMU-based setups and
+            not real hardware.
+        </note>
+    </para>
+
+    <para>
+        Finally, in addition to the Autobuilder's tests, the Yocto Project
+        QA team also performs testing on a variety of platforms, which includes
+        actual hardware, to ensure expected results.
+    </para>
+</section>
+
 </chapter>
 <!--
 vim: expandtab tw=80 ts=4

documentation/ref-manual/ref-structure.xml

@@ -801,11 +801,24 @@
         <title><filename>build/tmp/sysroots/</filename></title>
 
         <para>
-            This directory contains shared header files and libraries as well as other shared
-            data.
-            Packages that need to share output with other packages do so within this directory.
-            The directory is subdivided by architecture so multiple builds can run within
-            the one Build Directory.
+            Previous versions of the OpenEmbedded build system used to
+            create a global shared sysroot per machine along with a native
+            sysroot.
+            Beginning with the &DISTRO; version of the Yocto Project,
+            sysroots exist in recipe-specific
+            <link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>
+            directories.
+            Thus, the <filename>build/tmp/sysroots/</filename> directory
+            is unused.
+            <note>
+                The <filename>build/tmp/sysroots/</filename> directory
+                can still be populated using the
+                <filename>bitbake build-sysroots</filename> command and can
+                be used for compatibility in some cases.
+                However, in general it is not recommended to populate
+                this directory.
+                Individual recipe-specific sysroots should be used.
+            </note>
         </para>
     </section>
 
@@ -894,6 +907,101 @@
         </para>
     </section>
 
+    <section id='structure-build-tmp-work-tunearch-recipename-version'>
+        <title><filename>build/tmp/work/<replaceable>tunearch</replaceable>/<replaceable>recipename</replaceable>/<replaceable>version</replaceable>/</filename></title>
+
+        <para>
+            The recipe work directory (<replaceable>recipe_work_directory</replaceable>).
+        </para>
+
+        <para>
+            As described earlier in the
+            "<link linkend='structure-build-tmp-sysroots'><filename>build/tmp/sysroots/</filename></link>"
+            section, beginning with the &DISTRO; release of the Yocto
+            Project, the OpenEmbedded build system builds each recipe in its
+            own work directory (i.e.
+            <link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>).
+            The path to the work directory is constructed using the
+            architecture of the given build (e.g.
+            <link linkend='var-TUNE_PKGARCH'><filename>TUNE_PKGARCH</filename></link>,
+            <link linkend='var-MACHINE_ARCH'><filename>MACHINE_ARCH</filename></link>,
+            or "allarch"), the recipe name, and the version of the recipe (i.e.
+            <link linkend='var-PE'><filename>PE</filename></link><filename>:</filename><link linkend='var-PV'><filename>PV</filename></link><filename>-</filename><link linkend='var-PR'><filename>PR</filename></link>).
+        </para>
+
+        <para>
+            A number of key subdirectories exist within each recipe
+            work directory:
+            <itemizedlist>
+                <listitem><para>
+                    <filename><replaceable>recipe_work_directory</replaceable>/temp</filename>:
+                    Contains the log files of each task executed for this
+                    recipe, the "run" files for each executed task, which
+                    contain the code run, and a
+                    <filename>log.task_order</filename> file, which lists the
+                    order in which tasks were executed.
+                   </para></listitem>
+                <listitem><para>
+                    <filename><replaceable>recipe_work_directory</replaceable>/image</filename>:
+                    Contains the output of the
+                    <link linkend='ref-tasks-install'><filename>do_install</filename></link>
+                    task, which corresponds to the
+                    <filename>${</filename><link linkend='var-D'><filename>D</filename></link><filename>}</filename>
+                    variable in that task.
+                   </para></listitem>
+                <listitem><para>
+                    <filename><replaceable>recipe_work_directory</replaceable>/pseudo</filename>:
+                    Contains the pseudo database and log for any tasks executed
+                    under pseudo for the recipe.
+                   </para></listitem>
+                <listitem><para>
+                    <filename><replaceable>recipe_work_directory</replaceable>/sysroot-destdir</filename>:
+                    Contains the output of the
+                    <link linkend='ref-tasks-populate_sysroot'><filename>do_populate_sysroot</filename></link>
+                    task.
+                   </para></listitem>
+                <listitem><para>
+                    <filename><replaceable>recipe_work_directory</replaceable>/package</filename>:
+                    Contains the output of the
+                    <link linkend='ref-tasks-package'><filename>do_package</filename></link>
+                    task before the output is split into individual packages.
+                   </para></listitem>
+                <listitem><para>
+                    <filename><replaceable>recipe_work_directory</replaceable>/packages-split</filename>:
+                    Contains the output of the <filename>do_package</filename>
+                    task after the output has been split into individual
+                    packages.
+                    Subdirectories exist for each individual package created
+                    by the recipe.
+                   </para></listitem>
+                <listitem><para>
+                    <filename><replaceable>recipe_work_directory</replaceable>/recipe-sysroot</filename>:
+                    A directory populated with the target dependencies of the
+                    recipe.
+                    This directory looks like the target filesystem and
+                    contains libraries that the recipe might need to link
+                    against (e.g. the C library).
+                   </para></listitem>
+                <listitem><para>
+                    <filename><replaceable>recipe_work_directory</replaceable>/recipe-sysroot-native</filename>:
+                    A directory populated with the native dependencies of the
+                    recipe.
+                    This directory contains the tools the recipe needs to build
+                    (e.g. the compiler, Autoconf, libtool, and so forth).
+                   </para></listitem>
+                <listitem><para>
+                    <filename><replaceable>recipe_work_directory</replaceable>/build</filename>:
+                    This subdirectory applies only to recipes that support
+                    builds where the source is separate from the
+                    build artifacts.
+                    The OpenEmbedded build system uses this directory as a
+                    separate build directory (i.e.
+                    <filename>${</filename><link linkend='var-B'><filename>B</filename></link><filename>}</filename>).
+                   </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
     <section id='structure-build-work-shared'>
         <title><filename>build/tmp/work-shared/</filename></title>
 

documentation/ref-manual/ref-tasks.xml

@@ -490,6 +490,18 @@
         </para>
     </section>
 
+    <section id='ref-tasks-prepare_recipe_sysroot'>
+        <title><filename>do_prepare_recipe_sysroot</filename></title>
+
+        <para>
+            Installs the files into the individual recipe work directories
+            (i.e. WORKDIR).
+            See the
+            "<link linkend='ref-classes-staging'><filename>staging</filename></link>"
+            class for more information.
+        </para>
+    </section>
+
     <section id='ref-tasks-rm_work'>
         <title><filename>do_rm_work</filename></title>
 

documentation/ref-manual/ref-variables.xml

@@ -484,6 +484,12 @@
                     in your recipe so that it does contain
                     <filename>${SRCPV}</filename>.
                 </para>
+
+                <para>
+                    For more information see the
+                    "<ulink url='&YOCTO_DOCS_DEV_URL;#automatically-incrementing-a-binary-package-revision-number'>Automatically Incrementing a Binary Package Revision Number</ulink>"
+                    section in the Yocto Project Development Manual.
+                    </para>
             </glossdef>
         </glossentry>
 
@@ -2415,12 +2421,11 @@
                 </para>
 
                 <para>
-                    The default value, which is "GPL* LGPL*", for
-                    <filename>COPYLEFT_LICENSE_INCLUDE</filename> is set
-                    by the
+                    The default value is set by the
                     <link linkend='ref-classes-copyleft_filter'><filename>copyleft_filter</filename></link>
                     class, which is inherited by the
                     <filename>archiver</filename> class.
+                    The default value includes "GPL*", "LGPL*", and "AGPL*".
                 </para>
             </glossdef>
         </glossentry>
@@ -3618,6 +3623,47 @@
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-DISTRO_FEATURES_FILTER_NATIVE'><glossterm>DISTRO_FEATURES_FILTER_NATIVE</glossterm>
+            <info>
+                DISTRO_FEATURES_FILTER_NATIVE[doc] = "Specifies a list of features that if present in the target DISTRO_FEATURES value should be included in DISTRO_FEATURES when building native recipes."
+            </info>
+            <glossdef>
+                <para role="glossdeffirst">
+<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+                    Specifies a list of features that if present in
+                    the target
+                    <link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link>
+                    value should be included in
+                    <filename>DISTRO_FEATURES</filename> when building native
+                    recipes.
+                    This variable is used in addition to the features
+                    filtered using the
+                    <link linkend='var-DISTRO_FEATURES_NATIVE'><filename>DISTRO_FEATURES_NATIVE</filename></link>
+                    variable.
+               </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-DISTRO_FEATURES_FILTER_NATIVESDK'><glossterm>DISTRO_FEATURES_FILTER_NATIVESDK</glossterm>
+            <info>
+                DISTRO_FEATURES_FILTER_NATIVESDK[doc] = "Specifies a list of features that if present in the target DISTRO_FEATURES value should be included in DISTRO_FEATURES when building nativesdk recipes."
+            </info>
+            <glossdef>
+                <para role="glossdeffirst">
+<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+                    Specifies a list of features that if present in the target
+                    <link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link>
+                    value should be included in
+                    <filename>DISTRO_FEATURES</filename> when building
+                    nativesdk recipes.
+                    This variable is used in addition to the features
+                    filtered using the
+                    <link linkend='var-DISTRO_FEATURES_NATIVESDK'><filename>DISTRO_FEATURES_NATIVESDK</filename></link>
+                    variable.
+               </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-DISTRO_FEATURES_LIBC'><glossterm>DISTRO_FEATURES_LIBC</glossterm>
             <info>
                 DISTRO_FEATURES_LIBC[doc] = "Specifies the list of distro features that are specific to the C library (libc)."
@@ -3635,6 +3681,42 @@
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-DISTRO_FEATURES_NATIVE'><glossterm>DISTRO_FEATURES_NATIVE</glossterm>
+            <info>
+                DISTRO_FEATURES_NATIVE[doc] = "Specifies a list of features that should be included in DISTRO_FEATURES when building native recipes."
+            </info>
+            <glossdef>
+                <para role="glossdeffirst">
+<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+                    Specifies a list of features that should be included in
+                    <link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link>
+                    when building native recipes.
+                    This variable is used in addition to the features
+                    filtered using the
+                    <link linkend='var-DISTRO_FEATURES_FILTER_NATIVE'><filename>DISTRO_FEATURES_FILTER_NATIVE</filename></link>
+                    variable.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-DISTRO_FEATURES_NATIVESDK'><glossterm>DISTRO_FEATURES_NATIVESDK</glossterm>
+            <info>
+                DISTRO_FEATURES_NATIVESDK[doc] = "Specifies a list of features that should be included in DISTRO_FEATURES when building nativesdk recipes."
+            </info>
+            <glossdef>
+                <para role="glossdeffirst">
+<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+                    Specifies a list of features that should be included in
+                    <link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link>
+                    when building nativesdk recipes.
+                    This variable is used in addition to the features
+                    filtered using the
+                    <link linkend='var-DISTRO_FEATURES_FILTER_NATIVESDK'><filename>DISTRO_FEATURES_FILTER_NATIVESDK</filename></link>
+                    variable.
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-DISTRO_NAME'><glossterm>DISTRO_NAME</glossterm>
             <info>
                 DISTRO_NAME[doc] = "The long name of the distribution."
@@ -3798,7 +3880,9 @@
                 <para>
                     See the
                     <link linkend='ref-classes-systemd-boot'><filename>systemd-boot</filename></link>
-                    class for more information.
+                    and
+                    <link linkend='ref-classes-image-live'><filename>image-live</filename></link>
+                    classes for more information.
                 </para>
             </glossdef>
         </glossentry>
@@ -5109,6 +5193,53 @@
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-HOSTTOOLS'><glossterm>HOSTTOOLS</glossterm>
+            <info>
+                HOSTTOOLS[doc] = "A space-separated list (filter) of tools on the build host that should be allowed to be called from within build tasks."
+            </info>
+            <glossdef>
+                <para role="glossdeffirst">
+<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+                    A space-separated list (filter) of tools on the build host
+                    that should be allowed to be called from within build tasks.
+                    Using this filter helps reduce the possibility of host
+                    contamination.
+                    If a tool specified in the value of
+                    <filename>HOSTTOOLS</filename> is not found on the
+                    build host, the OpenEmbedded build system produces
+                    an error and the build is not started.
+                </para>
+
+                <para>
+                    For additional information, see
+                    <link linkend='var-HOSTTOOLS_NONFATAL'><filename>HOSTTOOLS_NONFATAL</filename></link>.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-HOSTTOOLS_NONFATAL'><glossterm>HOSTTOOLS_NONFATAL</glossterm>
+            <info>
+                HOSTTOOLS_NONFATAL[doc] = "A space-separated list (filter) of tools on the build host that should be allowed to be called from within build tasks."
+            </info>
+            <glossdef>
+                <para role="glossdeffirst">
+<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+                    A space-separated list (filter) of tools on the build host
+                    that should be allowed to be called from within build tasks.
+                    Using this filter helps reduce the possibility of host
+                    contamination.
+                    Unlike
+                    <link linkend='var-HOSTTOOLS'><filename>HOSTTOOLS</filename></link>,
+                    the OpenEmbedded build system does not produce and error
+                    if a tool specified in the value of
+                    <filename>HOSTTOOLS_NONFATAL</filename> is not found on the
+                    build host.
+                    Thus, you can use <filename>HOSTTOOLS_NONFATAL</filename>
+                    to filter optional host tools.
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-HOST_VENDOR'><glossterm>HOST_VENDOR</glossterm>
             <info>
                 HOST_VENDOR[doc] = "The name of the vendor. Normally same as the TARGET_VENDOR."
@@ -6185,14 +6316,24 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
 
         <glossentry id='var-INHERIT'><glossterm>INHERIT</glossterm>
             <info>
-                INHERIT[doc] = "Causes the named class to be inherited at this point during parsing. The variable is only valid in configuration files."
+                INHERIT[doc] = "Causes the named class or classes to be inherited globally."
             </info>
             <glossdef>
                 <para role="glossdeffirst">
 <!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
-                    Causes the named class to be inherited at
-                    this point during parsing.
-                    The variable is only valid in configuration files.
+                    Causes the named class or classes to be inherited globally.
+                    Anonymous functions in the class or classes
+                    are not executed for the
+                    base configuration and in each individual recipe.
+                    The OpenEmbedded build system ignores changes to
+                    <filename>INHERIT</filename> in individual recipes.
+                </para>
+
+                <para>
+                    For more information on <filename>INHERIT</filename>, see
+                    the
+                    "<ulink url="&YOCTO_DOCS_BB_URL;#inherit-configuration-directive"><filename>INHERIT</filename> Configuration Directive</ulink>"
+                    section in the Yocto Project Bitbake User Manual.
                 </para>
             </glossdef>
         </glossentry>
@@ -7300,21 +7441,30 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
 
         <glossentry id='var-LAYERDEPENDS'><glossterm>LAYERDEPENDS</glossterm>
             <info>
-                LAYERDEPENDS[doc] = "Lists the layers, separated by spaces, upon which this recipe depends. This variable is used in the conf/layer.conf file and must be suffixed with the name of the specific layer."
+                LAYERDEPENDS[doc] = "Lists the layers, separated by spaces, on which this recipe depends. This variable is used in the conf/layer.conf file and must be suffixed with the name of the specific layer."
             </info>
             <glossdef>
                 <para role="glossdeffirst">
 <!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
-                    Lists the layers that this recipe depends upon, separated by spaces.
-                    Optionally, you can specify a specific layer version for a dependency
-                    by adding it to the end of the layer name with a colon, (e.g. "anotherlayer:3"
-                    to be compared against
-                    <link linkend='var-LAYERVERSION'><filename>LAYERVERSION</filename></link><filename>_anotherlayer</filename>
-                    in this case).
-                    An error will be produced if any dependency is missing or
-                    the version numbers do not match exactly (if specified).
-                    This variable is used in the <filename>conf/layer.conf</filename> file
-                    and must be suffixed with the name of the specific layer (e.g.
+                    Lists the layers, separated by spaces, on which this
+                    recipe depends.
+                    Optionally, you can specify a specific layer version for a
+                    dependency by adding it to the end of the layer name.
+                    Here is an example:
+                    <literallayout class='monospaced'>
+     LAYERDEPENDS_mylayer = "anotherlayer (=3)"
+                    </literallayout>
+                    In this previous example, version 3 of "anotherlayer"
+                    is compared against
+                    <link linkend='var-LAYERVERSION'><filename>LAYERVERSION</filename></link><filename>_anotherlayer</filename>.
+                </para>
+
+                <para>
+                    An error is produced if any dependency is missing or
+                    the version numbers (if specified) do not match exactly.
+                    This variable is used in the
+                    <filename>conf/layer.conf</filename> file and must be
+                    suffixed with the name of the specific layer (e.g.
                     <filename>LAYERDEPENDS_mylayer</filename>).
                 </para>
             </glossdef>
@@ -7335,6 +7485,38 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-LAYERRECOMMENDS'><glossterm>LAYERRECOMMENDS</glossterm>
+            <info>
+                LAYERRECOMMENDS[doc] = "Lists the layers, separated by spaces, recommended for use with this layer."
+            </info>
+            <glossdef>
+                <para role="glossdeffirst">
+<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+                    Lists the layers, separated by spaces, recommended for
+                    use with this layer.
+                    Optionally, you can specify a specific layer version for a
+                    recommendation by adding the version to the end of the
+                    layer name.
+                    Here is an example:
+                    <literallayout class='monospaced'>
+     LAYERRECOMMENDS_mylayer = "anotherlayer (=3)"
+                    </literallayout>
+                    In this previous example, version 3 of "anotherlayer" is
+                    compared against
+                    <filename>LAYERVERSION_anotherlayer</filename>.
+                </para>
+
+                <para>
+                    An error is produced if any dependency is missing or the
+                    version numbers (if specified) do not match exactly.
+                    This variable is used in the
+                    <filename>conf/layer.conf</filename> file and must be
+                    suffixed with the name of the specific layer (e.g.
+                    <filename>LAYERRECOMMENDS_mylayer</filename>).
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-LAYERVERSION'><glossterm>LAYERVERSION</glossterm>
             <info>
                 LAYERVERSION[doc] = "Optionally specifies the version of a layer as a single number. This variable is used in the conf/layer.conf file and must be suffixed with the name of the specific layer."
@@ -8353,13 +8535,16 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
             </glossdef>
         </glossentry>
 
+<!--
         <glossentry id='var-MULTIMACH_HOST_SYS'><glossterm>MULTIMACH_HOST_SYS</glossterm>
             <info>
                 MULTIMACH_HOST_SYS[doc] = "Separates files for different machines such that you can build for multiple host machines using the same output directories."
             </info>
             <glossdef>
                 <para role="glossdeffirst">
+-->
 <!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+<!--
                     Serves the same purpose as
                     <link linkend='var-MULTIMACH_TARGET_SYS'><filename>MULTIMACH_TARGET_SYS</filename></link>,
                     but for the "HOST" system, in situations that involve a
@@ -8377,6 +8562,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                 </para>
             </glossdef>
         </glossentry>
+-->
 
         <glossentry id='var-MULTIMACH_TARGET_SYS'><glossterm>MULTIMACH_TARGET_SYS</glossterm>
             <info>
@@ -8406,9 +8592,6 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     See the
                     <link linkend='var-STAMP'><filename>STAMP</filename></link>
                     variable for an example.
-                    <link linkend='var-MULTIMACH_HOST_SYS'><filename>MULTIMACH_HOST_SYS</filename></link>
-                    is the corresponding variable for the host system in
-                    situations that involve a "HOST" and a "TARGET" system.
                     See the
                     <link linkend='var-STAGING_DIR_TARGET'><filename>STAGING_DIR_TARGET</filename></link>
                     variable for more information.
@@ -9318,6 +9501,31 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-PACKAGE_WRITE_DEPS'><glossterm>PACKAGE_WRITE_DEPS</glossterm>
+            <info>
+                PACKAGE_WRITE_DEPS[doc] = "Specifies post-installation and pre-installation script dependencies on native/cross tools."
+            </info>
+            <glossdef>
+                <para role="glossdeffirst">
+<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+                    Specifies a list of dependencies for post-installation and
+                    pre-installation scripts on native/cross tools.
+                    If your post-installation or pre-installation script can
+                    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_DEPENDS</filename>.
+                </para>
+
+                <para>
+                    For information on running post-installation scripts, see
+                    the
+                    "<ulink url='&YOCTO_DOCS_DEV_URL;#new-recipe-post-installation-scripts'>Post-Installation Scripts</ulink>"
+                    section in the Yocto Project Development Manual.
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-PACKAGECONFIG'><glossterm>PACKAGECONFIG</glossterm>
             <info>
                 PACKAGECONFIG[doc] = "This variable provides a means of enabling or disabling features of a recipe on a per-recipe basis."
@@ -9445,7 +9653,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
 
         <glossentry id='var-PACKAGECONFIG_CONFARGS'><glossterm>PACKAGECONFIG_CONFARGS</glossterm>
             <info>
-                PACKAGECONFIG_CONFARGS[doc] = "A space-separated list of configuration options generated from PACKAGECONFIG."
+                PACKAGECONFIG_CONFARGS[doc] = "A space-separated list of configuration options generated from the PACKAGECONFIG setting."
             </info>
             <glossdef>
                 <para role="glossdeffirst">
@@ -9454,29 +9662,22 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     from the
                     <link linkend='var-PACKAGECONFIG'><filename>PACKAGECONFIG</filename></link>
                     setting.
-                    This list of options helps other classes and
-                    recipes take advantage of the
-                    <filename>PACKAGECONFIG</filename> mechanism without
-                    having to include options from
-                    <link linkend='var-EXTRA_OECONF'><filename>EXTRA_OECONF</filename></link>.
                 </para>
 
                 <para>
-                    To illustrate how to use
-                    <filename>PACKAGECONFIG_CONFARGS</filename>, consider the
-                    following example:
-                    <literallayout class='monospaced'>
-     PACKAGECONFIG_CONFARGS = " \
-          -prefix ${prefix} \
-          -sysroot ${STAGING_DIR_NATIVE} \
-          -no-gcc-sysroot
-          "
-                    </literallayout>
-                    In the previous example,
-                    <filename>PACKAGECONFIG_CONFARGS</filename> is set with
-                    three configuration options that can be passed using the
-                    <filename>PACKAGECONFIG</filename> mechanism, thus
-                    avoiding having to use <filename>EXTRA_OECONF</filename>.
+                    Classes such as
+                    <link linkend='ref-classes-autotools'><filename>autotools</filename></link>
+                    and
+                    <link linkend='ref-classes-cmake'><filename>cmake</filename></link>
+                    use <filename>PACKAGECONFIG_CONFARGS</filename> to pass
+                    <link linkend='var-PACKAGECONFIG'><filename>PACKAGECONFIG</filename></link>
+                    options to <filename>configure</filename> and
+                    <filename>cmake</filename>, respectively.
+                    If you are using
+                    <filename>PACKAGECONFIG</filename> but not a class that
+                    handles the <filename>do_configure</filename> task, then
+                    you need to use
+                    <filename>PACKAGECONFIG_CONFARGS</filename> appropriately.
                 </para>
 
                 <para>
@@ -12654,15 +12855,17 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     every time BitBake parses your recipe, you should specify
                     a <filename>SRCREV</filename> that is a
                     full revision identifier and not just a tag.
+                    <note>
+                        For information on limitations when inheriting the
+                        latest revision of software using
+                        <filename>SRCREV</filename>, see the
+                        <link linkend='var-AUTOREV'><filename>AUTOREV</filename></link>
+                        variable description and the
+                        "<ulink url='&YOCTO_DOCS_DEV_URL;#automatically-incrementing-a-binary-package-revision-number'>Automatically Incrementing a Binary Package Revision Number</ulink>"
+                        section, which is in the Yocto Project Development Manual.
+                    </note>
                 </para>
 
-                <note>
-                    For information on limitations when inheriting the latest
-                    revision of software using <filename>SRCREV</filename>,
-                    see the
-                    <link linkend='var-AUTOREV'><filename>AUTOREV</filename></link>
-                    variable description.
-                </note>
             </glossdef>
         </glossentry>
 
@@ -12743,6 +12946,35 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-SSTATE_SCAN_FILES'><glossterm>SSTATE_SCAN_FILES</glossterm>
+            <info>
+                SSTATE_SCAN_FILES[doc] = "Controls the list of files the OpenEmbedded build system scans for hardcoded installation paths."
+            </info>
+            <glossdef>
+                <para role="glossdeffirst">
+<!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
+                    Controls the list of files the OpenEmbedded build system
+                    scans for hardcoded installation paths.
+                </para>
+
+                <para>
+                    During a build, the OpenEmbedded build system creates a
+                    shared state (sstate) object during the first stage of
+                    preparing the sysroots.
+                    During the build, the object is scanned for hardcoded paths
+                    for original installation locations.
+                    The list of files that are scanned for paths is controlled
+                    by the <filename>SSTATE_SCAN_FILES</filename> variable.
+                </para>
+
+                <para>
+                    For details on the process, see the
+                    <link linkend='ref-classes-staging'><filename>staging</filename></link>
+                    class.
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-STAGING_BASE_LIBDIR_NATIVE'><glossterm>STAGING_BASE_LIBDIR_NATIVE</glossterm>
             <info>
                 STAGING_BASE_LIBDIR_NATIVE[doc] = "Specifies the path to the /lib subdirectory of the sysroot directory for the build host."
@@ -12956,12 +13188,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                                 they make use of host headers and libraries.
                                 </para>
                                 </note>
-                           </para></listitem>
-                        <listitem><para>For native SDK
-                           recipes that build for the SDK
-                           (<filename>nativesdk</filename>), the value is
-                           "${STAGING_DIR}/${<link linkend='var-MULTIMACH_HOST_SYS'>MULTIMACH_HOST_SYS</link>}".
-                           </para></listitem>
+                            </para></listitem>
                     </itemizedlist>
                 </para>
             </glossdef>
@@ -14352,8 +14579,9 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     <note>
                         The <filename>TEST_SERVER_IP</filename> variable
                         is only used for a small number of tests such as
-                        the "smart" test suite, which needs to download
-                        packages from <filename>DEPLOY_DIR/rpm</filename>.
+                        the "dnf" test suite, which needs to download
+                        packages from
+                        <filename>WORKDIR/oe-rootfs-repo</filename>.
                     </note>
                 </para>
             </glossdef>

documentation/ref-manual/resources.xml

@@ -3,25 +3,71 @@
 [<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <chapter id='resources'>
-<title>Contributing to the Yocto Project</title>
+<title>Contributions and Additional Information</title>
 
 <section id='resources-intro'>
     <title>Introduction</title>
     <para>
-        The Yocto Project team is happy for people to experiment with the Yocto Project.
-        A number of places exist to find help if you run into difficulties or find bugs.
-        To find out how to download source code,
-        see the "<ulink url='&YOCTO_DOCS_DEV_URL;#local-yp-release'>Yocto Project Release</ulink>"
+        The Yocto Project team is happy for people to experiment with the
+        Yocto Project.
+        A number of places exist to find help if you run into difficulties
+        or find bugs.
+        This presents information about contributing and participating in
+        the Yocto Project.
+    </para>
+</section>
+
+<section id='resources-contributions'>
+    <title>Contributions</title>
+
+    <para>
+        The Yocto Project gladly accepts contributions.
+        You can submit changes to the project either by creating and sending
+        pull requests,
+        or by submitting patches through email.
+        For information on how to do both as well as information on how
+        to identify the maintainer for each area of code, see the
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#how-to-submit-a-change'>How to Submit a Change</ulink>"
         section in the Yocto Project Development Manual.
     </para>
 </section>
 
 <section id='resources-bugtracker'>
-    <title>Tracking Bugs</title>
+    <title>Yocto Project Bugzilla</title>
 
     <para>
-        If you find problems with the Yocto Project, you should report them using the
-        Bugzilla application at <ulink url='&YOCTO_BUGZILLA_URL;'></ulink>.
+        The Yocto Project uses its own implementation of
+        <ulink url='http://www.bugzilla.org/about/'>Bugzilla</ulink> to track
+        defects (bugs).
+        Implementations of Bugzilla work well for group development because
+        they track bugs and code changes, can be used to communicate changes
+        and problems with developers, can be used to submit and review patches,
+        and can be used to manage quality assurance.
+    </para>
+
+    <para>
+        Sometimes it is helpful to submit, investigate, or track a bug against
+        the Yocto Project itself (e.g. when discovering an issue with some
+        component of the build system that acts contrary to the documentation
+        or your expectations).
+    </para>
+
+    <para>
+        A general procedure and guidelines exist for when you use Bugzilla to
+        submit a bug.
+        For information on how to use Bugzilla to submit a bug against the
+        Yocto Project, see the following:
+        <itemizedlist>
+            <listitem><para>
+                The
+                "<ulink url='&YOCTO_DOCS_DEV_URL;#submitting-a-defect-against-the-yocto-project'>Submitting a Defect Against the Yocto Project</ulink>"
+                section in the Yocto Project Development Manual.
+                </para></listitem>
+            <listitem><para>
+                The Yocto Project
+                <ulink url='&YOCTO_WIKI_URL;/wiki/Bugzilla_Configuration_and_Bug_Tracking'>Bugzilla wiki page</ulink>
+                </para></listitem>
+        </itemizedlist>
     </para>
 </section>
 
@@ -70,53 +116,173 @@
     </para>
 </section>
 
-<section id='resources-links'>
-    <title>Links</title>
+<section id='resources-links-and-related-documentation'>
+    <title>Links and Related Documentation</title>
 
     <para>
-        Here is a list of resources you will find helpful:
+        Here is a list of resources you might find helpful:
         <itemizedlist>
-            <listitem><para><emphasis>
+            <listitem><para>
+                <emphasis>
                 <ulink url='&YOCTO_HOME_URL;'>The Yocto Project website</ulink>:
-                </emphasis> The home site for the Yocto
-                Project.</para></listitem>
-<!--
-            <listitem><para><emphasis>
-                <ulink url='http://www.intel.com/'>Intel Corporation</ulink>:</emphasis>
-                The company that acquired OpenedHand in 2008 and began
-                development on the Yocto Project.</para></listitem>
--->
-            <listitem><para><emphasis>
-                <ulink url='&OE_HOME_URL;'>OpenEmbedded</ulink>:</emphasis>
-                The upstream, generic, embedded distribution used as the basis
-                for the build system in the Yocto Project.
-                Poky derives from and contributes back to the OpenEmbedded
-                project.</para></listitem>
-            <listitem><para><emphasis>
+                </emphasis> The home site for the Yocto Project.
+                </para></listitem>
+            <listitem><para>
+                <emphasis>
+                <ulink url='&YOCTO_WIKI_URL;/wiki/Main_Page'>The Yocto Project Main Wiki Page</ulink>:
+                </emphasis>
+                The main wiki page for the Yocto Project.
+                This page contains information about project planning,
+                release engineering, QA &amp; automation, a reference
+                site map, and other resources related to the Yocto Project.
+                </para></listitem>
+            <listitem><para>
+                <emphasis>
+                <ulink url='&OE_HOME_URL;'>OpenEmbedded</ulink>:
+                </emphasis>
+                The build system used by the Yocto Project.
+                This project is the upstream, generic, embedded distribution
+                from which the Yocto Project derives its build system (Poky)
+                and to which it contributes.
+                </para></listitem>
+            <listitem><para>
+                <emphasis>
                 <ulink url='http://www.openembedded.org/wiki/BitBake'>
-                BitBake</ulink>:</emphasis> The tool used to process metadata.</para></listitem>
+                BitBake</ulink>:
+                </emphasis> The tool used to process metadata.
+                </para></listitem>
+            <listitem><para>
+                <emphasis>
+                <ulink url='&YOCTO_DOCS_BB_URL;'>BitBake User Manual:</ulink>
+                </emphasis>
+                A comprehensive guide to the BitBake tool.
+                If you want information on BitBake, see this manual.
+                </para></listitem>
+            <listitem><para>
+                <emphasis>
+                <ulink url='&YOCTO_DOCS_QS_URL;'>Yocto Project Quick Start</ulink>:
+                </emphasis>
+                This short document lets you get started
+                with the Yocto Project and quickly begin building an image.
+                </para></listitem>
+            <listitem><para>
+                <emphasis>
+                <ulink url='&YOCTO_DOCS_DEV_URL;'>Yocto Project Development Manual</ulink>:
+                </emphasis>
+                This manual is a "how-to" guide that presents procedures
+                useful to both application and system developers who use the
+                Yocto Project.
+                </para></listitem>
+            <listitem><para>
+                <emphasis>
+                <ulink url='&YOCTO_DOCS_SDK_URL;'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>:
+                </emphasis>
+                This guide provides information that lets you get going
+                with the standard or extensible SDK.
+                An SDK, with its cross-development toolchains, allows you
+                to develop projects inside or outside of the Yocto Project
+                environment.
+                </para></listitem>
+            <listitem><para>
+                <emphasis>
+                <ulink url='&YOCTO_DOCS_BSP_URL;'>Yocto Project Board Support Package (BSP) Developer's Guide</ulink>:
+                </emphasis>
+                This guide defines the structure for BSP components.
+                Having a commonly understood structure encourages
+                standardization.
+                </para></listitem>
+            <listitem><para>
+                <emphasis>
+                <ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;'>Yocto Project Linux Kernel Development Manual</ulink>:
+                </emphasis>
+                This manual describes how to work with Linux Yocto kernels as
+                well as provides a bit of conceptual information on the
+                construction of the Yocto Linux kernel tree.
+                </para></listitem>
+            <listitem><para>
+                <emphasis>
+                <ulink url='&YOCTO_DOCS_PROF_URL;'>Yocto Project Profiling and Tracing Manual</ulink>:
+                </emphasis>
+                This manual presents a set of common and generally useful
+                tracing and profiling schemes along with their applications
+                (as appropriate) to each tool.
+                </para></listitem>
+            <listitem><para>
+                <emphasis>
+                <ulink url='&YOCTO_DOCS_SDK_URL;#sdk-appendix-latest-yp-eclipse-plug-in'>Eclipse IDE Yocto Plug-in</ulink>:
+                </emphasis>
+                Instructions that demonstrate how an application developer
+                uses the Eclipse Yocto Project Plug-in feature within
+                the Eclipse IDE.
+                </para></listitem>
+            <listitem><para>
+                <emphasis>
+                <ulink url='&YOCTO_WIKI_URL;/wiki/FAQ'>FAQ</ulink>:
+                </emphasis>
+                A list of commonly asked questions and their answers.
+                </para></listitem>
+            <listitem><para>
+                <emphasis>
+                <ulink url='&YOCTO_RELEASE_NOTES;'>Release Notes</ulink>:
+                </emphasis>
+                Features, updates and known issues for the current
+                release of the Yocto Project.
+                </para></listitem>
+            <listitem><para>
+                <emphasis>
+                <ulink url='&YOCTO_HOME_URL;/tools-resources/projects/toaster'>Toaster</ulink>:
+                </emphasis>
+                An Application Programming Interface (API) and web-based
+                interface to the OpenEmbedded build system, which uses
+                BitBake, that reports build information.
+                </para></listitem>
+            <listitem><para>
+                <emphasis>
+                <ulink url='&YOCTO_DOCS_TOAST_URL;'>Toaster User Manual</ulink>:
+                </emphasis>
+                This manual introduces and describes how to set up and use
+                Toaster, which is a web interface to the Yocto Project's
+                <ulink url='&YOCTO_DOCS_DEV_URL;#build-system-term'>OpenEmbedded Build System</ulink>.
+                </para></listitem>
+            <listitem><para>
+                <emphasis>
+                <ulink url='&YOCTO_HOME_URL;/tools-resources/projects/build-appliance'>Build Appliance</ulink>:
+                </emphasis>
+                A virtual machine that
+                enables you to build and boot a custom embedded Linux image
+                with the Yocto Project using a non-Linux development system.
+                </para></listitem>
+            <listitem><para>
+                <emphasis>
+                <ulink url='&YOCTO_BUGZILLA_URL;'>Bugzilla</ulink>:
+                </emphasis>
+                The bug tracking application the Yocto Project uses.
+                If you find problems with the Yocto Project, you should report
+                them using this application.
+                </para></listitem>
+            <listitem><para>
+                <emphasis>
+                <ulink url='&YOCTO_WIKI_URL;/wiki/Bugzilla_Configuration_and_Bug_Tracking'>Bugzilla Configuration and Bug Tracking Wiki Page</ulink>:
+                </emphasis>
+                Information on how to get set up and use the Yocto Project
+                implementation of Bugzilla for logging and tracking Yocto
+                Project defects.
+                </para></listitem>
+            <listitem><para>
+                <emphasis>Internet Relay Chat (IRC):</emphasis>
+                Two IRC channels on freenode are available
+                for Yocto Project and Poky discussions: <filename>#yocto</filename> and
+                <filename>#poky</filename>, respectively.
+                </para></listitem>
+            <listitem><para>
+                <emphasis>
+                <ulink url='http://wiki.qemu.org/Index.html'>Quick EMUlator (QEMU)</ulink>:
+                </emphasis>
+                An open-source machine emulator and virtualizer.
+                </para></listitem>
         </itemizedlist>
-        For more links, see the
-        "<ulink url='&YOCTO_DOCS_DEV_URL;#other-information'>Other Information</ulink>"
-        section in the Yocto Project Development Manual.
     </para>
 </section>
-
-<section id='resources-contributions'>
-    <title>Contributions</title>
-
-    <para>
-        The Yocto Project gladly accepts contributions.
-        You can submit changes to the project either by creating and sending
-        pull requests,
-        or by submitting patches through email.
-        For information on how to do both as well as information on how
-        to identify the maintainer for each area of code, see the
-        "<ulink url='&YOCTO_DOCS_DEV_URL;#how-to-submit-a-change'>How to Submit a Change</ulink>"
-        section in the Yocto Project Development Manual.
-    </para>
-</section>
-
 </chapter>
 <!--
 vim: expandtab tw=80 ts=4

documentation/ref-manual/technical-details.xml

@@ -432,7 +432,7 @@
         For information on how the OpenEmbedded build system
         works with packages and can
         track incrementing <filename>PR</filename> information, see the
-        "<ulink url='&YOCTO_DOCS_DEV_URL;#incrementing-a-package-revision-number'>Incrementing a Package Revision Number</ulink>"
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#automatically-incrementing-a-binary-package-revision-number'>Automatically Incrementing a Binary Package Revision Number</ulink>"
         section.
     </note>
 
@@ -1460,9 +1460,9 @@
                         <listitem><para>
                             When using "beginline" and "endline", realize that
                             line numbering begins with one and not zero.
-                            Also, the lines included are inclusive (e.g. lines
-                            five through 29 in the previous example for
-                            <filename>licfile1.txt</filename>.
+                            Also, the included lines are inclusive (i.e. lines
+                            five through and including 29 in the previous
+                            example for <filename>licfile1.txt</filename>).
                             </para></listitem>
                         <listitem><para>
                             When a license check fails, the selected license

documentation/ref-manual/usingpoky.xml

@@ -480,7 +480,7 @@
             You can use a different method to view dependency information
             by using the following command:
             <literallayout class='monospaced'>
-     $ bitbake -g -u depexp <replaceable>recipename</replaceable>
+     $ bitbake -g -u taskexp <replaceable>recipename</replaceable>
             </literallayout>
             This command displays a GUI window from which you can view
             build-time and runtime dependencies for the recipes involved in
@@ -736,79 +736,6 @@
         </para>
     </section>
 
-    <section id='checking-for-missing-build-time-dependencies'>
-        <title>Checking for Missing Build-Time Dependencies</title>
-
-        <para>
-            A recipe might build successfully even though some of its
-            build-time dependencies are missing from
-            <link linkend='var-DEPENDS'><filename>DEPENDS</filename></link>.
-            Following are the two most common ways in which that can happen:
-            <itemizedlist>
-                <listitem><para>
-                    The build-time dependency just happens to already exist in
-                    the staging sysroot
-                    (<link linkend='var-STAGING_DIR_HOST'><filename>STAGING_DIR_HOST</filename></link>)
-                    by the time the recipe is built.
-                    This situation occurs when the build-time dependency is
-                    built earlier during recipe processing.
-                    </para></listitem>
-                <listitem><para>
-                    The component built by the recipe conditionally enables
-                    functionality depending on whether it can find the
-                    build-time dependency in the staging sysroot.
-                    If the build-time dependency is missing, the corresponding
-                    functionality is disabled.
-                    This condition is known as a "floating dependency".
-                    </para></listitem>
-            </itemizedlist>
-        </para>
-
-        <para>
-            Because dealing with the second case is more complex, focus will
-            be on the first case.
-            The
-            <link linkend='ref-classes-insane'><filename>build-deps</filename></link>
-            QA check checks that every library the component linked against is
-            declared as a build-time dependency.
-            If that is not the case, then the first situation described in the
-            previous list exists, and <filename>build-deps</filename> reports
-            a missing build-time dependency.
-        </para>
-
-        <para>
-            Another, more manual, way to check a recipe for missing build-time
-            dependencies of the first type is to build with an empty staging
-            sysroot.
-            This method can also find missing build-time dependencies
-            that are not in the form of libraries, which the
-            <filename>build-deps</filename> QA check is unable to find.
-        </para>
-
-        <para>
-            An easy way to empty the staging sysroots is to simply remove
-            <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link>,
-            which is usually
-            <filename>${</filename><link linkend='var-BUILDDIR'><filename>BUILDDIR</filename></link><filename>}/tmp</filename>,
-            as it includes the staging sysroots.
-            Another, faster method to empty the staging sysroots is to use the
-            <filename>scripts/wipe-sysroot</filename> script,
-            which removes just the staging sysroots and keeps everything else
-            in <filename>TMPDIR</filename>.
-            <note>
-                The <filename>scripts/</filename> directory appears in
-                <filename>PATH</filename> after running the build environment
-                initialization script (i.e.
-                <link linkend='structure-core-script'><filename>oe-init-build-env</filename></link>
-                or
-                <link linkend='structure-memres-core-script'><filename>oe-init-build-env-memres</filename></link>),
-                which results in the ability to to run
-                <filename>wipe-sysroot</filename> immediately.
-            </note>
-        </para>
-
-    </section>
-
     <section id='usingpoky-debugging-bitbake'>
         <title>General BitBake Problems</title>
 
@@ -1104,9 +1031,11 @@
                     the Yocto Project implementation of
                     <ulink url='https://bugzilla.yoctoproject.org/'>Bugzilla</ulink>.
                     For general information on how to submit a bug against
-                    the Yocto Project, see the
-                    "<ulink url='&YOCTO_DOCS_DEV_URL;#tracking-bugs'>Tracking Bugs</ulink>"
-                    section in the Yocto Project Development Manual.
+                    the Yocto Project, see the Yocto Project Bugzilla
+                    <ulink url='&YOCTO_WIKI_URL;/wiki/Bugzilla_Configuration_and_Bug_Tracking'>wiki page</ulink>"
+                    or the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#submitting-a-defect-against-the-yocto-project'>Submitting a Defect Against the Yocto Project</ulink>"
+                    section, which is in the Yocto Project Development Manual.
                     <note>
                         The manuals might not be the right place to document
                         variables that are purely internal and have a limited

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

@@ -2,7 +2,7 @@
 "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
 [<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
-<appendix id='sdk-appendix-mars'>
+<appendix id='sdk-appendix-latest-yp-eclipse-plug-in'>
     <title>Using Eclipse Mars</title>
 
     <para>

documentation/sdk-manual/sdk-extensible.xml

@@ -612,7 +612,7 @@
                                 extracts them.
                                 Providing the <replaceable>srctree</replaceable>
                                 argument instructs <filename>devtool</filename> where
-                                place the extracted source.</para>
+                                to place the extracted source.</para>
 
                                 <para>Within workspace, <filename>devtool</filename>
                                 creates an append file for the recipe.

documentation/sdk-manual/sdk-manual.xml

@@ -46,6 +46,11 @@
                 <date>May 2017</date>
                 <revremark>Released with the Yocto Project 2.3 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>2.4</revnumber>
+                <date>Usually October</date>
+                <revremark>Released with the Yocto Project 2.4 Release.</revremark>
+            </revision>
        </revhistory>
 
     <copyright>

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

@@ -459,7 +459,7 @@
                     release with the Yocto Project.
                     For information on how to use the Mars version of Eclipse
                     with the Yocto Project, see
-                    "<link linkend='sdk-appendix-mars'>Appendix C</link>.
+                    "<link linkend='sdk-appendix-latest-yp-eclipse-plug-in'>Appendix C</link>.
                 </note>
             </para>
 
@@ -501,7 +501,7 @@
                             <listitem><para>
                                 <emphasis>Locate the Neon Download:</emphasis>
                                 Open a browser and go to
-                                <ulink url='http://www.eclipse.org/mars/'>http://www.eclipse.org/neon/</ulink>.
+                                <ulink url='http://www.eclipse.org/neon/'>http://www.eclipse.org/neon/</ulink>.
                                 </para></listitem>
                             <listitem><para>
                                 <emphasis>Download the Tarball:</emphasis>

documentation/toaster-manual/toaster-manual.xml

@@ -56,6 +56,11 @@
                 <date>May 2017</date>
                 <revremark>Released with the Yocto Project 2.3 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>2.4</revnumber>
+                <date>Usually October</date>
+                <revremark>Released with the Yocto Project 2.4 Release.</revremark>
+            </revision>
        </revhistory>
 
     <copyright>

documentation/tools/mega-manual.sed

@@ -2,32 +2,32 @@
 # 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.3\/[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.3\/yocto-project-qs\/yocto-project-qs.html#/\"link\" href=\"#/g
-s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.3\/poky-ref-manual\/poky-ref-manual.html#/\"link\" href=\"#/g
+# s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.4\/[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.4\/yocto-project-qs\/yocto-project-qs.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.4\/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.3\/[a-z]*-[a-z]*\/[a-z]*-[a-z]*.html#/\"link\" href=\"#/g
+# s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.4\/[a-z]*-[a-z]*\/[a-z]*-[a-z]*.html#/\"link\" href=\"#/g
 
-s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.3\/sdk-manual\/sdk-manual.html#/\"link\" href=\"#/g
-s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.3\/bsp-guide\/bsp-guide.html#/\"link\" href=\"#/g
-s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.3\/dev-manual\/dev-manual.html#/\"link\" href=\"#/g
-s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.3\/kernel-dev\/kernel-dev.html#/\"link\" href=\"#/g
-s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.3\/profile-manual\/profile-manual.html#/\"link\" href=\"#/g
-s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.3\/ref-manual\/ref-manual.html#/\"link\" href=\"#/g
-s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.3\/toaster-manual\/toaster-manual.html#/\"link\" href=\"#/g
-s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.3\/yocto-project-qs\/yocto-project-qs.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.4\/sdk-manual\/sdk-manual.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.4\/bsp-guide\/bsp-guide.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.4\/dev-manual\/dev-manual.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.4\/kernel-dev\/kernel-dev.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.4\/profile-manual\/profile-manual.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.4\/ref-manual\/ref-manual.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.4\/toaster-manual\/toaster-manual.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.4\/yocto-project-qs\/yocto-project-qs.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.3\/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.3\/dev-manual\/dev-manual.html\" target=\"_top\">Yocto Project Development Manual<\/a>/Yocto Project Development Manual/g
-s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.3\/sdk-manual\/sdk-manual.html\" target=\"_top\">Yocto Project Software Development Kit (SDK) Developer's Guide<\/a>/Yocto Project Software Development Kit (SDK) Developer's Guide/g
-s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.3\/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.3\/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.3\/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.3\/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.3\/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.4\/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.4\/dev-manual\/dev-manual.html\" target=\"_top\">Yocto Project Development Manual<\/a>/Yocto Project Development Manual/g
+s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.4\/sdk-manual\/sdk-manual.html\" target=\"_top\">Yocto Project Software Development Kit (SDK) Developer's Guide<\/a>/Yocto Project Software Development Kit (SDK) Developer's Guide/g
+s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.4\/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.4\/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.4\/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.4\/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.4\/toaster-manual\/toaster-manual.html\" target=\"_top\">Toaster User Manual<\/a>/Toaster User Manual/g

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

@@ -64,7 +64,8 @@
             tool, to construct complete Linux images.
             The BitBake and OE components are combined together to form
             a reference build host, historically known as
-            <ulink url='&YOCTO_DOCS_DEV_URL;#poky'>Poky</ulink>.
+            <ulink url='&YOCTO_DOCS_DEV_URL;#poky'>Poky</ulink>
+            (<emphasis>Pah</emphasis>-key).
         </para>
 
         <para>
@@ -145,11 +146,8 @@
         <mediaobject>
             <imageobject>
                 <imagedata fileref="figures/yocto-environment.png"
-                    format="PNG" align='center' scalefit='1' width="100%"/>
+                    format="PNG" align='center' width="8in"/>
             </imageobject>
-            <caption>
-                <para>The Yocto Project Development Environment</para>
-            </caption>
          </mediaobject>
 
         <para>
@@ -339,13 +337,33 @@
                         <literallayout class='monospaced'>
      $ sudo yum install &CENTOS_HOST_PACKAGES_ESSENTIAL; SDL-devel xterm
                         </literallayout>
-                        <note>
-                            CentOS 6.x users need to ensure that the required
-                            versions of Git, tar and Python are available.
-                            For details, See the
-                            "<ulink url='&YOCTO_DOCS_REF_URL;#required-git-tar-and-python-versions'>Required Git, tar, and Python Versions</ulink>"
-                            section in the Yocto Project Reference Manual for
-                            information.
+                        <note><title>Notes</title>
+                            <itemizedlist>
+                                <listitem><para>
+                                    CentOS 6.x users need to ensure that the
+                                    required versions of Git, tar and Python
+                                    are available.
+                                    For details, See the
+                                    "<ulink url='&YOCTO_DOCS_REF_URL;#required-git-tar-and-python-versions'>Required Git, tar, and Python Versions</ulink>"
+                                    section in the Yocto Project Reference
+                                    Manual for information.
+                                    </para></listitem>
+                                <listitem><para>
+                                    Extra Packages for Enterprise Linux
+                                    (i.e. <filename>epel-release</filename>)
+                                    is a collection of packages from Fedora
+                                    built on RHEL/CentOS for easy installation
+                                    of packages not included in enterprise
+                                    Linux by default.
+                                    You need to install these packages
+                                    separately.
+                                    </para></listitem>
+                                <listitem><para>
+                                    The <filename>makecache</filename> command
+                                    consumes additional Metadata from
+                                    <filename>epel-release</filename>.
+                                    </para></listitem>
+                            </itemizedlist>
                         </note>
                         </para></listitem>
                 </itemizedlist>
@@ -374,11 +392,12 @@
                 <literallayout class='monospaced'>
      $ git clone git://git.yoctoproject.org/poky
      Cloning into 'poky'...
-     remote: Counting objects: 226790, done.
-     remote: Compressing objects: 100% (57465/57465), done.
-     remote: Total 226790 (delta 165212), reused 225887 (delta 164327)
-     Receiving objects: 100% (226790/226790), 100.98 MiB | 263 KiB/s, done.
-     Resolving deltas: 100% (165212/165212), 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 &DISTRO_NAME_NO_CAP;
                 </literallayout>
                 You can also get the Yocto Project Files by downloading
@@ -689,11 +708,11 @@
      $ cd $HOME/poky
      $ git clone git://git.yoctoproject.org/meta-intel
      Cloning into 'meta-intel'...
-     remote: Counting objects: 11988, done.
-     remote: Compressing objects: 100% (3884/3884), done.
-     Receiving objects: 100% (11988/11988), 2.93 MiB | 2.51 MiB/s, done.
-     remote: Total 11988 (delta 6881), reused 11752 (delta 6645)
-     Resolving deltas: 100% (6881/6881), done.
+     remote: Counting objects: 14039, done.
+     remote: Compressing objects: 100% (4471/4471), done.
+     remote: Total 14039 (delta 8130), reused 13837 (delta 7947)
+     Receiving objects: 100% (14039/14039), 4.27 MiB | 3.98 MiB/s, done.
+     Resolving deltas: 100% (8130/8130), done.
      Checking connectivity... done.
                         </literallayout>
                         By default when you clone a Git repository, the

meta-poky/conf/distro/include/maintainers.inc

@@ -61,9 +61,9 @@ RECIPE_MAINTAINER_pn-bash = "Hongxu Jia <hongxu.jia@windriver.com>"
 RECIPE_MAINTAINER_pn-bash-completion = "Alexander Kanavin <alexander.kanavin@intel.com>"
 RECIPE_MAINTAINER_pn-bc = "Jose Lamego <jose.a.lamego@linux.intel.com>"
 RECIPE_MAINTAINER_pn-bdwgc = "Alexander Kanavin <alexander.kanavin@intel.com>"
-RECIPE_MAINTAINER_pn-beecrypt = "Chen Qi <Qi.Chen@windriver.com>"
+RECIPE_MAINTAINER_pn-beecrypt = "Armin Kuster <akuster@mvista.com>"
 RECIPE_MAINTAINER_pn-bigreqsproto = "Jussi Kukkonen <jussi.kukkonen@intel.com>"
-RECIPE_MAINTAINER_pn-bind = "Robert Yang <liezhi.yang@windriver.com>"
+RECIPE_MAINTAINER_pn-bind = "Armin Kuster <akuster@mvista.com>"
 RECIPE_MAINTAINER_pn-binutils = "Khem Raj <raj.khem@gmail.com>"
 RECIPE_MAINTAINER_pn-binutils-cross = "Khem Raj <raj.khem@gmail.com>"
 RECIPE_MAINTAINER_pn-binutils-cross-canadian = "Khem Raj <raj.khem@gmail.com>"
@@ -82,9 +82,9 @@ RECIPE_MAINTAINER_pn-build-appliance-image = "Cristian Iorga <cristian.iorga@int
 RECIPE_MAINTAINER_pn-build-compare = "Randy Witt <randy.e.witt@linux.intel.com>"
 RECIPE_MAINTAINER_pn-builder = "Cristian Iorga <cristian.iorga@intel.com>"
 RECIPE_MAINTAINER_pn-buildtools-tarball = "Cristian Iorga <cristian.iorga@intel.com>"
-RECIPE_MAINTAINER_pn-busybox = "Chen Qi <Qi.Chen@windriver.com>"
+RECIPE_MAINTAINER_pn-busybox = "Armin Kuster <akuster808@gmail.com>"
 RECIPE_MAINTAINER_pn-byacc = "Chen Qi <Qi.Chen@windriver.com>"
-RECIPE_MAINTAINER_pn-bzip2 = "Chen Qi <Qi.Chen@windriver.com>"
+RECIPE_MAINTAINER_pn-bzip2 = "Armin Kuster <akuster@mvista.com>"
 RECIPE_MAINTAINER_pn-ca-certificates = "Alexander Kanavin <alexander.kanavin@intel.com>"
 RECIPE_MAINTAINER_pn-cairo = "Jussi Kukkonen <jussi.kukkonen@intel.com>"
 RECIPE_MAINTAINER_pn-calibrateproto = "Jussi Kukkonen <jussi.kukkonen@intel.com>"
@@ -97,8 +97,8 @@ RECIPE_MAINTAINER_pn-chrpath = "Dengke Du <dengke.du@windriver.com>"
 RECIPE_MAINTAINER_pn-clutter-1.0 = "Jussi Kukkonen <jussi.kukkonen@intel.com>"
 RECIPE_MAINTAINER_pn-clutter-gst-3.0 = "Jussi Kukkonen <jussi.kukkonen@intel.com>"
 RECIPE_MAINTAINER_pn-clutter-gtk-1.0 = "Jussi Kukkonen <jussi.kukkonen@intel.com>"
-RECIPE_MAINTAINER_pn-cmake = "Alexander Kanavin <alexander.kanavin@intel.com>"
-RECIPE_MAINTAINER_pn-cmake-native = "Alexander Kanavin <alexander.kanavin@intel.com>"
+RECIPE_MAINTAINER_pn-cmake = "Otavio Salvador <otavio.salvador@ossystems.com.br>"
+RECIPE_MAINTAINER_pn-cmake-native = "Otavio Salvador <otavio.salvador@ossystems.com.br>"
 RECIPE_MAINTAINER_pn-cogl-1.0 = "Jussi Kukkonen <jussi.kukkonen@intel.com>"
 RECIPE_MAINTAINER_pn-compositeproto = "Jussi Kukkonen <jussi.kukkonen@intel.com>"
 RECIPE_MAINTAINER_pn-connman = "Maxin B. John <maxin.john@intel.com>"
@@ -128,17 +128,17 @@ RECIPE_MAINTAINER_pn-core-image-testmaster-initramfs = "Ross Burton <ross.burton
 RECIPE_MAINTAINER_pn-core-image-weston = "Ross Burton <ross.burton@intel.com>"
 RECIPE_MAINTAINER_pn-core-image-x11 = "Ross Burton <ross.burton@intel.com>"
 RECIPE_MAINTAINER_pn-coreutils = "Chen Qi <Qi.Chen@windriver.com>"
-RECIPE_MAINTAINER_pn-cpio = "Chen Qi <Qi.Chen@windriver.com>"
-RECIPE_MAINTAINER_pn-cracklib = "Hongxu Jia <hongxu.jia@windriver.com>"
+RECIPE_MAINTAINER_pn-cpio = "Denys Dmytriyenko <denis@denix.org>"
+RECIPE_MAINTAINER_pn-cracklib = "Armin Kuster <akuster@mvista.com>"
 RECIPE_MAINTAINER_pn-createrepo = "Hongxu Jia <hongxu.jia@windriver.com>"
-RECIPE_MAINTAINER_pn-cronie = "Edwin Plauchu <edwin.plauchu.camacho@linux.intel.com>"
+RECIPE_MAINTAINER_pn-cronie = "Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com>"
 RECIPE_MAINTAINER_pn-cross-localedef-native = "Khem Raj <raj.khem@gmail.com>"
 RECIPE_MAINTAINER_pn-cryptodev-linux = "Robert Yang <liezhi.yang@windriver.com>"
 RECIPE_MAINTAINER_pn-cryptodev-module = "Robert Yang <liezhi.yang@windriver.com>"
 RECIPE_MAINTAINER_pn-cryptodev-tests = "Robert Yang <liezhi.yang@windriver.com>"
 RECIPE_MAINTAINER_pn-cups = "Chen Qi <Qi.Chen@windriver.com>"
-RECIPE_MAINTAINER_pn-curl = "Chen Qi <Qi.Chen@windriver.com>"
-RECIPE_MAINTAINER_pn-cve-check-tool = "Mariano Lopez <mariano.lopez@linux.intel.com>"
+RECIPE_MAINTAINER_pn-curl = "Armin Kuster <akuster@mvista.com>"
+RECIPE_MAINTAINER_pn-cve-check-tool = "Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com>"
 RECIPE_MAINTAINER_pn-cwautomacros = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-damageproto = "Jussi Kukkonen <jussi.kukkonen@intel.com>"
 RECIPE_MAINTAINER_pn-db = "Mark Hatle <mark.hatle@windriver.com>"
@@ -236,12 +236,13 @@ RECIPE_MAINTAINER_pn-gnome-themes-standard = "Jussi Kukkonen <jussi.kukkonen@int
 RECIPE_MAINTAINER_pn-gnu-config = "Robert Yang <liezhi.yang@windriver.com>"
 RECIPE_MAINTAINER_pn-gnu-efi = "Robert Yang <liezhi.yang@windriver.com>"
 RECIPE_MAINTAINER_pn-gnupg = "Hongxu Jia <hongxu.jia@windriver.com>"
-RECIPE_MAINTAINER_pn-gnutls = "Alexander Kanavin <alexander.kanavin@intel.com>"
+RECIPE_MAINTAINER_pn-gnutls = "Armin Kuster <akuster@mvista.com>"
 RECIPE_MAINTAINER_pn-gobject-introspection = "Alexander Kanavin <alexander.kanavin@intel.com>"
+RECIPE_MAINTAINER_pn-go-native = "Armin Kuster <akuster808@gmail.com>"
 RECIPE_MAINTAINER_pn-gperf = "Alexander Kanavin <alexander.kanavin@intel.com>"
 RECIPE_MAINTAINER_pn-gpgme = "Hongxu Jia <hongxu.jia@windriver.com>"
 RECIPE_MAINTAINER_pn-gptfdisk = "Alexander Kanavin <alexander.kanavin@intel.com>"
-RECIPE_MAINTAINER_pn-grep = "Chen Qi <Qi.Chen@windriver.com>"
+RECIPE_MAINTAINER_pn-grep = "Denys Dmytriyenko <denis@denix.org>"
 RECIPE_MAINTAINER_pn-groff = "Hongxu Jia <hongxu.jia@windriver.com>"
 RECIPE_MAINTAINER_pn-grub = "Alexander Kanavin <alexander.kanavin@intel.com>"
 RECIPE_MAINTAINER_pn-grub-efi = "Alexander Kanavin <alexander.kanavin@intel.com>"
@@ -265,9 +266,9 @@ RECIPE_MAINTAINER_pn-gtk-sato-engine = "Jussi Kukkonen <jussi.kukkonen@intel.com
 RECIPE_MAINTAINER_pn-guile = "Robert Yang <liezhi.yang@windriver.com>"
 RECIPE_MAINTAINER_pn-guilt-native = "Bruce Ashfield <bruce.ashfield@windriver.com>"
 RECIPE_MAINTAINER_pn-gummiboot = "Alexander Kanavin <alexander.kanavin@intel.com>"
-RECIPE_MAINTAINER_pn-gzip = "Chen Qi <Qi.Chen@windriver.com>"
+RECIPE_MAINTAINER_pn-gzip = "Armin Kuster <akuster@mvista.com>"
 RECIPE_MAINTAINER_pn-harfbuzz = "Maxin B. John <maxin.john@intel.com>"
-RECIPE_MAINTAINER_pn-hdparm = "Robert Yang <liezhi.yang@windriver.com>"
+RECIPE_MAINTAINER_pn-hdparm = "Denys Dmytriyenko <denis@denix.org>"
 RECIPE_MAINTAINER_pn-help2man-native = "Hongxu Jia <hongxu.jia@windriver.com>"
 RECIPE_MAINTAINER_pn-hicolor-icon-theme = "Jussi Kukkonen <jussi.kukkonen@intel.com>"
 RECIPE_MAINTAINER_pn-hostap-conf = "Maxin B. John <maxin.john@intel.com>"
@@ -279,8 +280,8 @@ RECIPE_MAINTAINER_pn-icon-naming-utils = "Alexander Kanavin <alexander.kanavin@i
 RECIPE_MAINTAINER_pn-icu = "Alexander Kanavin <alexander.kanavin@intel.com>"
 RECIPE_MAINTAINER_pn-ifupdown = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-init-ifupdown = "Maxin B. John <maxin.john@intel.com>"
-RECIPE_MAINTAINER_pn-initramfs-boot = "Ross Burton <ross.burton@intel.com>"
-RECIPE_MAINTAINER_pn-initramfs-framework = "Ross Burton <ross.burton@intel.com>"
+RECIPE_MAINTAINER_pn-initramfs-boot = "Otavio Salvador <otavio.salvador@ossystems.com.br>"
+RECIPE_MAINTAINER_pn-initramfs-framework = "Otavio Salvador <otavio.salvador@ossystems.com.br>"
 RECIPE_MAINTAINER_pn-initramfs-live-boot = "Ross Burton <ross.burton@intel.com>"
 RECIPE_MAINTAINER_pn-initramfs-live-install = "Ross Burton <ross.burton@intel.com>"
 RECIPE_MAINTAINER_pn-initramfs-live-install-efi = "Ross Burton <ross.burton@intel.com>"
@@ -289,8 +290,8 @@ RECIPE_MAINTAINER_pn-initramfs-live-install-testfs = "Ross Burton <ross.burton@i
 RECIPE_MAINTAINER_pn-initscripts = "Ross Burton <ross.burton@intel.com>"
 RECIPE_MAINTAINER_pn-inputproto = "Jussi Kukkonen <jussi.kukkonen@intel.com>"
 RECIPE_MAINTAINER_pn-intltool = "Alexander Kanavin <alexander.kanavin@intel.com>"
-RECIPE_MAINTAINER_pn-iproute2 = "Maxin B. John <maxin.john@intel.com>"
-RECIPE_MAINTAINER_pn-iptables = "Maxin B. John <maxin.john@intel.com>"
+RECIPE_MAINTAINER_pn-iproute2 = "Armin Kuster <akuster@mvista.com>"
+RECIPE_MAINTAINER_pn-iptables = "Armin Kuster <akuster@mvista.com>"
 RECIPE_MAINTAINER_pn-iputils = "Robert Yang <liezhi.yang@windriver.com>"
 RECIPE_MAINTAINER_pn-irda-utils = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-iso-codes = "Alexander Kanavin <alexander.kanavin@intel.com>"
@@ -304,7 +305,7 @@ RECIPE_MAINTAINER_pn-kconfig-frontends = "Alexander Kanavin <alexander.kanavin@i
 RECIPE_MAINTAINER_pn-kern-tools-native = "Bruce Ashfield <bruce.ashfield@windriver.com>"
 RECIPE_MAINTAINER_pn-kernelshark = "Alexander Kanavin <alexander.kanavin@intel.com>"
 RECIPE_MAINTAINER_pn-kernel-devsrc = "Bruce Ashfield <bruce.ashfield@windriver.com>"
-RECIPE_MAINTAINER_pn-kexec-tools = "Alexander Kanavin <alexander.kanavin@intel.com>"
+RECIPE_MAINTAINER_pn-kexec-tools = "Armin Kuster <akuster@mvista.com>"
 RECIPE_MAINTAINER_pn-keymaps = "Alexander Kanavin <alexander.kanavin@intel.com>"
 RECIPE_MAINTAINER_pn-kmod = "Chen Qi <Qi.Chen@windriver.com>"
 RECIPE_MAINTAINER_pn-kmod-native = "Chen Qi <Qi.Chen@windriver.com>"
@@ -316,9 +317,9 @@ RECIPE_MAINTAINER_pn-less = "Robert Yang <liezhi.yang@windriver.com>"
 RECIPE_MAINTAINER_pn-liba52 = "Tanu Kaskinen <tanuk@iki.fi>"
 RECIPE_MAINTAINER_pn-libacpi = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-libaio = "Alexander Kanavin <alexander.kanavin@intel.com>"
-RECIPE_MAINTAINER_pn-libarchive = "Alexander Kanavin <alexander.kanavin@intel.com>"
+RECIPE_MAINTAINER_pn-libarchive = "Otavio Salvador <otavio.salvador@ossystems.com.br>"
 RECIPE_MAINTAINER_pn-libart-lgpl = "Jussi Kukkonen <jussi.kukkonen@intel.com>"
-RECIPE_MAINTAINER_pn-libassuan = "Alexander Kanavin <alexander.kanavin@intel.com>"
+RECIPE_MAINTAINER_pn-libassuan = "Armin Kuster <akuster@mvista.com>"
 RECIPE_MAINTAINER_pn-libatomic-ops = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-libav = "Jussi Kukkonen <jussi.kukkonen@intel.com>"
 RECIPE_MAINTAINER_pn-libbsd = "Robert Yang <liezhi.yang@windriver.com>"
@@ -331,7 +332,7 @@ RECIPE_MAINTAINER_pn-libconvert-asn1-perl = "Aníbal Limón <anibal.limon@linux.
 RECIPE_MAINTAINER_pn-libcroco = "Jussi Kukkonen <jussi.kukkonen@intel.com>"
 RECIPE_MAINTAINER_pn-libdaemon = "Alexander Kanavin <alexander.kanavin@intel.com>"
 RECIPE_MAINTAINER_pn-libdmx = "Jussi Kukkonen <jussi.kukkonen@intel.com>"
-RECIPE_MAINTAINER_pn-libdrm = "Jussi Kukkonen <jussi.kukkonen@intel.com>"
+RECIPE_MAINTAINER_pn-libdrm = "Otavio Salvador <otavio.salvador@ossystems.com.br>"
 RECIPE_MAINTAINER_pn-libdumpvalue-perl = "Aníbal Limón <anibal.limon@linux.intel.com>"
 RECIPE_MAINTAINER_pn-libenv-perl = "Aníbal Limón <anibal.limon@linux.intel.com>"
 RECIPE_MAINTAINER_pn-libepoxy = "Jussi Kukkonen <jussi.kukkonen@intel.com>"
@@ -378,7 +379,7 @@ RECIPE_MAINTAINER_pn-libpam = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-libpcap = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-libpciaccess = "Alexander Kanavin <alexander.kanavin@intel.com>"
 RECIPE_MAINTAINER_pn-libpcre = "Robert Yang <liezhi.yang@windriver.com>"
-RECIPE_MAINTAINER_pn-libpcre2 = "Armin Kuster  <akuster@mvista.com>"
+RECIPE_MAINTAINER_pn-libpcre2 = "Armin Kuster <akuster@mvista.com>"
 RECIPE_MAINTAINER_pn-libpfm4 = "Matthew McClintock <msm@freescale.com>"
 RECIPE_MAINTAINER_pn-libpng = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-libpng12 = "Maxin B. John <maxin.john@intel.com>"
@@ -453,7 +454,7 @@ RECIPE_MAINTAINER_pn-libxxf86vm = "Jussi Kukkonen <jussi.kukkonen@intel.com>"
 RECIPE_MAINTAINER_pn-libyaml = "Alexander Kanavin <alexander.kanavin@intel.com>"
 RECIPE_MAINTAINER_pn-lighttpd = "Alexander Kanavin <alexander.kanavin@intel.com>"
 RECIPE_MAINTAINER_pn-linux-dummy = "Alexander Kanavin <alexander.kanavin@intel.com>"
-RECIPE_MAINTAINER_pn-linux-firmware = "Maxin B. John <maxin.john@intel.com>"
+RECIPE_MAINTAINER_pn-linux-firmware = "Otavio Salvador <otavio.salvador@ossystems.com.br>"
 RECIPE_MAINTAINER_pn-linux-libc-headers = "Bruce Ashfield <bruce.ashfield@windriver.com>"
 RECIPE_MAINTAINER_pn-linux-yocto = "Bruce Ashfield <bruce.ashfield@windriver.com>"
 RECIPE_MAINTAINER_pn-linux-yocto-dev = "Bruce Ashfield <bruce.ashfield@windriver.com>"
@@ -470,8 +471,8 @@ RECIPE_MAINTAINER_pn-lttng-modules = "Richard Purdie <richard.purdie@linuxfounda
 RECIPE_MAINTAINER_pn-lttng-tools = "Richard Purdie <richard.purdie@linuxfoundation.org>"
 RECIPE_MAINTAINER_pn-lttng-ust = "Richard Purdie <richard.purdie@linuxfoundation.org>"
 RECIPE_MAINTAINER_pn-lz4 = "Armin Kuster <akuster808@gmail.com>"
-RECIPE_MAINTAINER_pn-lzo = "Alexander Kanavin <alexander.kanavin@intel.com>"
-RECIPE_MAINTAINER_pn-lzop = "Alexander Kanavin <alexander.kanavin@intel.com>"
+RECIPE_MAINTAINER_pn-lzo = "Armin Kuster <akuster808@gmail.com>"
+RECIPE_MAINTAINER_pn-lzop = "Armin Kuster <akuster808@gmail.com>"
 RECIPE_MAINTAINER_pn-m4 = "Robert Yang <liezhi.yang@windriver.com>"
 RECIPE_MAINTAINER_pn-m4-native = "Robert Yang <liezhi.yang@windriver.com>"
 RECIPE_MAINTAINER_pn-mailx = "Robert Yang <liezhi.yang@windriver.com>"
@@ -493,9 +494,9 @@ RECIPE_MAINTAINER_pn-matchbox-wm = "Jussi Kukkonen <jussi.kukkonen@intel.com>"
 RECIPE_MAINTAINER_pn-mc = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-mdadm = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-menu-cache = "Jussi Kukkonen <jussi.kukkonen@intel.com>"
-RECIPE_MAINTAINER_pn-mesa = "Jussi Kukkonen <jussi.kukkonen@intel.com>"
-RECIPE_MAINTAINER_pn-mesa-demos = "Jussi Kukkonen <jussi.kukkonen@intel.com>"
-RECIPE_MAINTAINER_pn-mesa-gl = "Jussi Kukkonen <jussi.kukkonen@intel.com>"
+RECIPE_MAINTAINER_pn-mesa = "Otavio Salvador <otavio.salvador@ossystems.com.br>"
+RECIPE_MAINTAINER_pn-mesa-demos = "Otavio Salvador <otavio.salvador@ossystems.com.br>"
+RECIPE_MAINTAINER_pn-mesa-gl = "Otavio Salvador <otavio.salvador@ossystems.com.br>"
 RECIPE_MAINTAINER_pn-meta-environment = "Richard Purdie <richard.purdie@linuxfoundation.org>"
 RECIPE_MAINTAINER_pn-meta-environment-extsdk = "Richard Purdie <richard.purdie@linuxfoundation.org>"
 RECIPE_MAINTAINER_pn-meta-extsdk-toolchain = "Richard Purdie <richard.purdie@linuxfoundation.org>"
@@ -517,7 +518,7 @@ RECIPE_MAINTAINER_pn-mpeg2dec = "Alexander Kanavin <alexander.kanavin@intel.com>
 RECIPE_MAINTAINER_pn-mpfr = "Khem Raj <raj.khem@gmail.com>"
 RECIPE_MAINTAINER_pn-mpg123 = "Alexander Kanavin <alexander.kanavin@intel.com>"
 RECIPE_MAINTAINER_pn-msmtp = "Alexander Kanavin <alexander.kanavin@intel.com>"
-RECIPE_MAINTAINER_pn-mtd-utils = "Alexander Kanavin <alexander.kanavin@intel.com>"
+RECIPE_MAINTAINER_pn-mtd-utils = "Denys Dmytriyenko <denis@denix.org>"
 RECIPE_MAINTAINER_pn-mtdev = "Jussi Kukkonen <jussi.kukkonen@intel.com>"
 RECIPE_MAINTAINER_pn-mtools = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-musl = "Khem Raj <raj.khem@gmail.com>"
@@ -531,18 +532,18 @@ RECIPE_MAINTAINER_pn-nativesdk-postinst-intercept = "Aníbal Limón <anibal.limo
 RECIPE_MAINTAINER_pn-ncurses = "Hongxu Jia <hongxu.jia@windriver.com>"
 RECIPE_MAINTAINER_pn-neard = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-neon = "Maxin B. John <maxin.john@intel.com>"
-RECIPE_MAINTAINER_pn-net-tools = "Maxin B. John <maxin.john@intel.com>"
-RECIPE_MAINTAINER_pn-netbase = "Maxin B. John <maxin.john@intel.com>"
+RECIPE_MAINTAINER_pn-net-tools = "Armin Kuster <akuster@mvista.com>"
+RECIPE_MAINTAINER_pn-netbase = "Armin Kuster <akuster@mvista.com>"
 RECIPE_MAINTAINER_pn-nettle = "Armin Kuster <akuster808@gmail.com>"
 RECIPE_MAINTAINER_pn-nfs-export-root = "Robert Yang <liezhi.yang@windriver.com>"
-RECIPE_MAINTAINER_pn-nfs-utils = "Mariano Lopez <mariano.lopez@linux.intel.com>"
+RECIPE_MAINTAINER_pn-nfs-utils = "Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com>"
 RECIPE_MAINTAINER_pn-npth = "Alexander Kanavin <alexander.kanavin@intel.com>"
-RECIPE_MAINTAINER_pn-nspr = "Alexander Kanavin <alexander.kanavin@intel.com>"
-RECIPE_MAINTAINER_pn-nss = "Alexander Kanavin <alexander.kanavin@intel.com>"
+RECIPE_MAINTAINER_pn-nspr = "Armin Kuster <akuster@mvista.com>"
+RECIPE_MAINTAINER_pn-nss = "Armin Kuster <akuster@mvista.com>"
 RECIPE_MAINTAINER_pn-nss-myhostname = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-ofono = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-oh-puzzles = "Jussi Kukkonen <jussi.kukkonen@intel.com>"
-RECIPE_MAINTAINER_pn-openssh = "Dengke Du <dengke.du@windriver.com>"
+RECIPE_MAINTAINER_pn-openssh = "Armin Kuster <akuster@mvista.com>"
 RECIPE_MAINTAINER_pn-openssl = "Alexander Kanavin <alexander.kanavin@intel.com>"
 RECIPE_MAINTAINER_pn-opkg = "Alejandro del Castillo <alejandro.delcastillo@ni.com>"
 RECIPE_MAINTAINER_pn-opkg-arch-config = "Alejandro del Castillo <alejandro.delcastillo@ni.com>"
@@ -583,7 +584,7 @@ RECIPE_MAINTAINER_pn-patch = "Hongxu Jia <hongxu.jia@windriver.com>"
 RECIPE_MAINTAINER_pn-patchelf = "Richard Purdie <richard.purdie@linuxfoundation.org>"
 RECIPE_MAINTAINER_pn-pax = "Hongxu Jia <hongxu.jia@windriver.com>"
 RECIPE_MAINTAINER_pn-pax-utils = "Hongxu Jia <hongxu.jia@windriver.com>"
-RECIPE_MAINTAINER_pn-pbzip2 = "Alexander Kanavin <alexander.kanavin@intel.com>"
+RECIPE_MAINTAINER_pn-pbzip2 = "Armin Kuster <akuster@mvista.com>"
 RECIPE_MAINTAINER_pn-pciutils = "Chen Qi <Qi.Chen@windriver.com>"
 RECIPE_MAINTAINER_pn-pcmanfm = "Alexander Kanavin <alexander.kanavin@intel.com>"
 RECIPE_MAINTAINER_pn-pcmciautils = "Robert Yang <liezhi.yang@windriver.com>"
@@ -594,7 +595,7 @@ RECIPE_MAINTAINER_pn-piglit = "Jussi Kukkonen <jussi.kukkonen@intel.com>"
 RECIPE_MAINTAINER_pn-pigz = "Hongxu Jia <hongxu.jia@windriver.com>"
 RECIPE_MAINTAINER_pn-pinentry = "Armin Kuster <akuster808@gmail.com>"
 RECIPE_MAINTAINER_pn-pixman = "Jussi Kukkonen <jussi.kukkonen@intel.com>"
-RECIPE_MAINTAINER_pn-pixz = "Richard Purdie <richard.purdie@linuxfoundation.org>"
+RECIPE_MAINTAINER_pn-pixz = "Armin Kuster <akuster808@gmail.com>"
 RECIPE_MAINTAINER_pn-pkgconfig = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-pm-utils = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-pointercal = "Alexander Kanavin <alexander.kanavin@intel.com>"
@@ -625,7 +626,7 @@ RECIPE_MAINTAINER_pn-python-imaging = "Jose Lamego <jose.a.lamego@linux.intel.co
 RECIPE_MAINTAINER_pn-python-mako = "Jose Lamego <jose.a.lamego@linux.intel.com>"
 RECIPE_MAINTAINER_pn-python-native = "Alejandro Hernandez <alejandro.hernandez@linux.intel.com>"
 RECIPE_MAINTAINER_pn-python-nose = "Jose Lamego <jose.a.lamego@linux.intel.com>"
-RECIPE_MAINTAINER_pn-python-numpy = "Edwin Plauchu <edwin.plauchu.camacho@linux.intel.com>"
+RECIPE_MAINTAINER_pn-python-numpy = "Jose Lamego <jose.a.lamego@linux.intel.com>"
 RECIPE_MAINTAINER_pn-python-pexpect = "Jose Lamego <jose.a.lamego@linux.intel.com>"
 RECIPE_MAINTAINER_pn-python-ptyprocess = "Jose Lamego <jose.a.lamego@linux.intel.com>"
 RECIPE_MAINTAINER_pn-python-pycairo = "Jose Lamego <jose.a.lamego@linux.intel.com>"
@@ -634,26 +635,26 @@ RECIPE_MAINTAINER_pn-python-pygtk = "Jose Lamego <jose.a.lamego@linux.intel.com>
 RECIPE_MAINTAINER_pn-python-pyrex = "Jose Lamego <jose.a.lamego@linux.intel.com>"
 RECIPE_MAINTAINER_pn-python-scons = "Jose Lamego <jose.a.lamego@linux.intel.com>"
 RECIPE_MAINTAINER_pn-python-scons-native = "Jose Lamego <jose.a.lamego@linux.intel.com>"
-RECIPE_MAINTAINER_pn-python-setuptools = "Edwin Plauchu <edwin.plauchu.camacho@linux.intel.com>"
+RECIPE_MAINTAINER_pn-python-setuptools = "Jose Lamego <jose.a.lamego@linux.intel.com>"
 RECIPE_MAINTAINER_pn-python-six = "Jose Lamego <jose.a.lamego@linux.intel.com>"
 RECIPE_MAINTAINER_pn-python-smartpm = "Jose Lamego <jose.a.lamego@linux.intel.com>"
 RECIPE_MAINTAINER_pn-python-smmap = "Jose Lamego <jose.a.lamego@linux.intel.com>"
 RECIPE_MAINTAINER_pn-python3 = "Alejandro Hernandez <alejandro.hernandez@linux.intel.com>"
-RECIPE_MAINTAINER_pn-python3-async = "Edwin Plauchu <edwin.plauchu.camacho@linux.intel.com>"
-RECIPE_MAINTAINER_pn-python3-dbus = "Edwin Plauchu <edwin.plauchu.camacho@linux.intel.com>"
-RECIPE_MAINTAINER_pn-python3-distribute = "Edwin Plauchu <edwin.plauchu.camacho@linux.intel.com>"
-RECIPE_MAINTAINER_pn-python3-docutils = "Edwin Plauchu <edwin.plauchu.camacho@linux.intel.com>"
+RECIPE_MAINTAINER_pn-python3-async = "Jose Lamego <jose.a.lamego@linux.intel.com>"
+RECIPE_MAINTAINER_pn-python3-dbus = "Jose Lamego <jose.a.lamego@linux.intel.com>"
+RECIPE_MAINTAINER_pn-python3-distribute = "Jose Lamego <jose.a.lamego@linux.intel.com>"
+RECIPE_MAINTAINER_pn-python3-docutils = "Jose Lamego <jose.a.lamego@linux.intel.com>"
 RECIPE_MAINTAINER_pn-python3-git = "Jose Lamego <jose.a.lamego@linux.intel.com>"
-RECIPE_MAINTAINER_pn-python3-gitdb = "Edwin Plauchu <edwin.plauchu.camacho@linux.intel.com>"
+RECIPE_MAINTAINER_pn-python3-gitdb = "Jose Lamego <jose.a.lamego@linux.intel.com>"
 RECIPE_MAINTAINER_pn-python3-mako = "Jose Lamego <jose.a.lamego@linux.intel.com>"
 RECIPE_MAINTAINER_pn-python3-native = "Alejandro Hernandez <alejandro.hernandez@linux.intel.com>"
-RECIPE_MAINTAINER_pn-python3-nose = "Edwin Plauchu <edwin.plauchu.camacho@linux.intel.com>"
-RECIPE_MAINTAINER_pn-python3-numpy = "Edwin Plauchu <edwin.plauchu.camacho@linux.intel.com>"
-RECIPE_MAINTAINER_pn-python3-pip = "Edwin Plauchu <edwin.plauchu.camacho@linux.intel.com>"
-RECIPE_MAINTAINER_pn-python3-pygobject = "Edwin Plauchu <edwin.plauchu.camacho@linux.intel.com>"
-RECIPE_MAINTAINER_pn-python3-setuptools = "Edwin Plauchu <edwin.plauchu.camacho@linux.intel.com>"
-RECIPE_MAINTAINER_pn-python3-six = "Edwin Plauchu <edwin.plauchu.camacho@linux.intel.com>"
-RECIPE_MAINTAINER_pn-python3-smmap = "Edwin Plauchu <edwin.plauchu.camacho@linux.intel.com>"
+RECIPE_MAINTAINER_pn-python3-nose = "Jose Lamego <jose.a.lamego@linux.intel.com>"
+RECIPE_MAINTAINER_pn-python3-numpy = "Jose Lamego <jose.a.lamego@linux.intel.com>"
+RECIPE_MAINTAINER_pn-python3-pip = "Jose Lamego <jose.a.lamego@linux.intel.com>"
+RECIPE_MAINTAINER_pn-python3-pygobject = "Jose Lamego <jose.a.lamego@linux.intel.com>"
+RECIPE_MAINTAINER_pn-python3-setuptools = "Jose Lamego <jose.a.lamego@linux.intel.com>"
+RECIPE_MAINTAINER_pn-python3-six = "Jose Lamego <jose.a.lamego@linux.intel.com>"
+RECIPE_MAINTAINER_pn-python3-smmap = "Jose Lamego <jose.a.lamego@linux.intel.com>"
 RECIPE_MAINTAINER_pn-qemu = "Aníbal Limón <anibal.limon@linux.intel.com>"
 RECIPE_MAINTAINER_pn-qemu-helper-native = "Aníbal Limón <anibal.limon@linux.intel.com>"
 RECIPE_MAINTAINER_pn-qemuwrapper-cross = "Aníbal Limón <anibal.limon@linux.intel.com>"
@@ -706,7 +707,7 @@ RECIPE_MAINTAINER_pn-stress = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-subversion = "Richard Purdie <richard.purdie@linuxfoundation.org>"
 RECIPE_MAINTAINER_pn-sudo = "Chen Qi <Qi.Chen@windriver.com>"
 RECIPE_MAINTAINER_pn-swabber-native = "Alexander Kanavin <alexander.kanavin@intel.com>"
-RECIPE_MAINTAINER_pn-swig = "Edwin Plauchu <edwin.plauchu.camacho@linux.intel.com>"
+RECIPE_MAINTAINER_pn-swig = "Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com>"
 RECIPE_MAINTAINER_pn-sysfsutils = "Chen Qi <Qi.Chen@windriver.com>"
 RECIPE_MAINTAINER_pn-sysklogd = "Chen Qi <Qi.Chen@windriver.com>"
 RECIPE_MAINTAINER_pn-syslinux = "Alexander Kanavin <alexander.kanavin@intel.com>"
@@ -737,18 +738,18 @@ RECIPE_MAINTAINER_pn-tiny-init = "Alexander Kanavin <alexander.kanavin@intel.com
 RECIPE_MAINTAINER_pn-trace-cmd = "Alexander Kanavin <alexander.kanavin@intel.com>"
 RECIPE_MAINTAINER_pn-tremor = "Tanu Kaskinen <tanuk@iki.fi>"
 RECIPE_MAINTAINER_pn-tslib = "Jussi Kukkonen <jussi.kukkonen@intel.com>"
-RECIPE_MAINTAINER_pn-ttf-bitstream-vera = "Mariano Lopez <mariano.lopez@linux.intel.com>"
-RECIPE_MAINTAINER_pn-tzcode-native = "Robert Yang <liezhi.yang@windriver.com>"
-RECIPE_MAINTAINER_pn-tzdata = "Robert Yang <liezhi.yang@windriver.com>"
-RECIPE_MAINTAINER_pn-u-boot = "Denys Dmytriyenko <denis@denix.org>"
-RECIPE_MAINTAINER_pn-u-boot-fw-utils = "Denys Dmytriyenko <denis@denix.org>"
-RECIPE_MAINTAINER_pn-u-boot-mkimage = "Denys Dmytriyenko <denis@denix.org>"
+RECIPE_MAINTAINER_pn-ttf-bitstream-vera = "Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com>"
+RECIPE_MAINTAINER_pn-tzcode-native = "Armin Kuster <akuster@mvista.com>"
+RECIPE_MAINTAINER_pn-tzdata = "Armin Kuster <akuster@mvista.com>"
+RECIPE_MAINTAINER_pn-u-boot = "Marek Vasut <marek.vasut@gmail.com>"
+RECIPE_MAINTAINER_pn-u-boot-fw-utils = "Marek Vasut <marek.vasut@gmail.com>"
+RECIPE_MAINTAINER_pn-u-boot-mkimage = "Marek Vasut <marek.vasut@gmail.com>"
 RECIPE_MAINTAINER_pn-ubootchart = "Ross Burton <ross.burton@intel.com>"
 RECIPE_MAINTAINER_pn-udev-extraconf = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-unfs3 = "Randy Witt <randy.e.witt@linux.intel.com>"
 RECIPE_MAINTAINER_pn-unifdef = "Ross Burton <ross.burton@intel.com>"
 RECIPE_MAINTAINER_pn-uninative-tarball = "Richard Purdie <richard.purdie@linuxfoundation.org>"
-RECIPE_MAINTAINER_pn-unzip = "Edwin Plauchu <edwin.plauchu.camacho@linux.intel.com>"
+RECIPE_MAINTAINER_pn-unzip = "Armin Kuster <akuster808@gmail.com>"
 RECIPE_MAINTAINER_pn-update-rc.d = "Ross Burton <ross.burton@intel.com>"
 RECIPE_MAINTAINER_pn-usbinit = "Alexander Kanavin <alexander.kanavin@intel.com>"
 RECIPE_MAINTAINER_pn-usbutils = "Alexander Kanavin <alexander.kanavin@intel.com>"
@@ -760,16 +761,17 @@ RECIPE_MAINTAINER_pn-valgrind = "Alexander Kanavin <alexander.kanavin@intel.com>
 RECIPE_MAINTAINER_pn-videoproto = "Jussi Kukkonen <jussi.kukkonen@intel.com>"
 RECIPE_MAINTAINER_pn-volatile-binds = "Chen Qi <Qi.Chen@windriver.com>"
 RECIPE_MAINTAINER_pn-vte = "Jussi Kukkonen <jussi.kukkonen@intel.com>"
+RECIPE_MAINTAINER_pn-vulkan = "Jussi Kukkonen <jussi.kukkonen@intel.com>"
 RECIPE_MAINTAINER_pn-waffle = "Jussi Kukkonen <jussi.kukkonen@intel.com>"
 RECIPE_MAINTAINER_pn-watchdog = "Alexander Kanavin <alexander.kanavin@intel.com>"
 RECIPE_MAINTAINER_pn-watchdog-config = "Alexander Kanavin <alexander.kanavin@intel.com>"
-RECIPE_MAINTAINER_pn-wayland = "Jussi Kukkonen <jussi.kukkonen@intel.com>"
-RECIPE_MAINTAINER_pn-wayland-protocols = "Jussi Kukkonen <jussi.kukkonen@intel.com>"
+RECIPE_MAINTAINER_pn-wayland = "Denys Dmytriyenko <denis@denix.org>"
+RECIPE_MAINTAINER_pn-wayland-protocols = "Denys Dmytriyenko <denis@denix.org>"
 RECIPE_MAINTAINER_pn-webkitgtk = "Alexander Kanavin <alexander.kanavin@intel.com>"
-RECIPE_MAINTAINER_pn-weston = "Jussi Kukkonen <jussi.kukkonen@intel.com>"
-RECIPE_MAINTAINER_pn-weston-init = "Jussi Kukkonen <jussi.kukkonen@intel.com>"
+RECIPE_MAINTAINER_pn-weston = "Denys Dmytriyenko <denis@denix.org>"
+RECIPE_MAINTAINER_pn-weston-init = "Denys Dmytriyenko <denis@denix.org>"
 RECIPE_MAINTAINER_pn-wget = "Robert Yang <liezhi.yang@windriver.com>"
-RECIPE_MAINTAINER_pn-which = "Mariano Lopez <mariano.lopez@linux.intel.com>"
+RECIPE_MAINTAINER_pn-which = "Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com>"
 RECIPE_MAINTAINER_pn-wireless-tools = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-wpa-supplicant = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-x11-common = "Jussi Kukkonen <jussi.kukkonen@intel.com>"
@@ -831,8 +833,8 @@ RECIPE_MAINTAINER_pn-xuser-account = "Jussi Kukkonen <jussi.kukkonen@intel.com>"
 RECIPE_MAINTAINER_pn-xvideo-tests = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-xvinfo = "Jussi Kukkonen <jussi.kukkonen@intel.com>"
 RECIPE_MAINTAINER_pn-xwininfo = "Jussi Kukkonen <jussi.kukkonen@intel.com>"
-RECIPE_MAINTAINER_pn-xz = "Chen Qi <Qi.Chen@windriver.com>"
+RECIPE_MAINTAINER_pn-xz = "Armin Kuster <akuster808@gmail.com>"
 RECIPE_MAINTAINER_pn-yasm = "Dengke Du <dengke.du@windriver.com>"
-RECIPE_MAINTAINER_pn-zip = "Chen Qi <Qi.Chen@windriver.com>"
+RECIPE_MAINTAINER_pn-zip = "Armin Kuster <akuster808@gmail.com>"
 RECIPE_MAINTAINER_pn-zisofs-tools-native = "Alexander Kanavin <alexander.kanavin@intel.com>"
-RECIPE_MAINTAINER_pn-zlib = "Chen Qi <Qi.Chen@windriver.com>"
+RECIPE_MAINTAINER_pn-zlib = "Armin Kuster <akuster808@gmail.com>"