lrzsz: check locale.h in configure

fix the build failure:
lrz.c:284:13: error: 'LC_ALL' undeclared (first use in this function)

(From OE-Core rev: 8a2ac668d99f7d64c2acffc3a39cedb2d152be6e)

Signed-off-by: Jackie Huang <jackie.huang@windriver.com>
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

README.hardware

@@ -308,9 +308,9 @@ Load the kernel and dtb (device tree blob), and boot the system as follows:
 
  5. Download the kernel and dtb, and boot:
 
- => tftp 800000 uImage-mpc8315e-rdb.bin
- => tftp 780000 uImage-mpc8315e-rdb.dtb
- => bootm 800000 - 780000
+ => tftp 1000000 uImage-mpc8315e-rdb.bin
+ => tftp 2000000 uImage-mpc8315e-rdb.dtb
+ => bootm 1000000 - 2000000
 
 
 Ubiquiti Networks RouterStation Pro (routerstationpro)

bitbake/bin/bitbake

@@ -39,10 +39,15 @@ import bb.msg
 from bb import cooker
 from bb import ui
 from bb import server
+from bb import cookerdata
 
-__version__ = "1.18.0"
+__version__ = "1.19.0"
 logger = logging.getLogger("BitBake")
 
+# Python multiprocessing requires /dev/shm
+if not os.access('/dev/shm', os.W_OK | os.X_OK):
+    sys.exit("FATAL: /dev/shm does not exist or is not writable")
+
 # Unbuffer stdout to avoid log truncation in the event
 # of an unorderly exit as well as to provide timely
 # updates to log files for use with tail
@@ -52,16 +57,6 @@ try:
 except:
     pass
 
-class BBConfiguration(object):
-    """
-    Manages build options and configurations for one run
-    """
-
-    def __init__(self, options):
-        for key, val in options.__dict__.items():
-            setattr(self, key, val)
-        self.pkgs_to_build = []
-
 
 def get_ui(config):
     if not config.ui:
@@ -75,11 +70,23 @@ def get_ui(config):
         # suggest a fixed set this allows you to have flexibility in which
         # ones are available.
         module = __import__("bb.ui", fromlist = [interface])
-        return getattr(module, interface).main
+        return getattr(module, interface)
     except AttributeError:
         sys.exit("FATAL: Invalid user interface '%s' specified.\n"
                  "Valid interfaces: depexp, goggle, ncurses, hob, knotty [default]." % interface)
 
+def gather_extra_cache_data():
+    extra = []
+    interfaces = ['depexp', 'goggle', 'ncurses', 'hob', 'knotty']
+    for i in interfaces:
+        try:
+            ui = __import__("bb.ui." + i, fromlist = [i])
+            if hasattr(ui, "extraCaches"):
+                extra = extra + ui.extraCaches
+            del ui
+        except:
+            pass
+    return extra
 
 # Display bitbake/OE warnings via the BitBake.Warnings logger, ignoring others"""
 warnlog = logging.getLogger("BitBake.Warnings")
@@ -100,159 +107,199 @@ warnings.filterwarnings("ignore", category=ImportWarning)
 warnings.filterwarnings("ignore", category=DeprecationWarning, module="<string>$")
 warnings.filterwarnings("ignore", message="With-statements now directly support multiple context managers")
 
+class BitBakeConfigParameters(cookerdata.ConfigParameters):
+
+    def parseCommandLine(self):
+        parser = optparse.OptionParser(
+            version = "BitBake Build Tool Core version %s, %%prog version %s" % (bb.__version__, __version__),
+            usage = """%prog [options] [package ...]
+
+    Executes the specified task (default is 'build') for a given set of BitBake files.
+    It expects that BBFILES is defined, which is a space separated list of files to
+    be executed.  BBFILES does support wildcards.
+    Default BBFILES are the .bb files in the current directory.""")
+
+        parser.add_option("-b", "--buildfile", help = "execute the task against this .bb file, rather than a package from BBFILES. Does not handle any dependencies.",
+                   action = "store", dest = "buildfile", default = None)
+
+        parser.add_option("-k", "--continue", help = "continue as much as possible after an error. While the target that failed, and those that depend on it, cannot be remade, the other dependencies of these targets can be processed all the same.",
+                   action = "store_false", dest = "abort", default = True)
+
+        parser.add_option("-a", "--tryaltconfigs", help = "continue with builds by trying to use alternative providers where possible.",
+                   action = "store_true", dest = "tryaltconfigs", default = False)
+
+        parser.add_option("-f", "--force", help = "force run of specified cmd, regardless of stamp status",
+                   action = "store_true", dest = "force", default = False)
+
+        parser.add_option("-c", "--cmd", help = "Specify task to execute. Note that this only executes the specified task for the providee and the packages it depends on, i.e. 'compile' does not implicitly call stage for the dependencies (IOW: use only if you know what you are doing). Depending on the base.bbclass a listtasks tasks is defined and will show available tasks",
+                   action = "store", dest = "cmd")
+
+        parser.add_option("-C", "--clear-stamp", help = "Invalidate the stamp for the specified cmd such as 'compile' and run the default task for the specified target(s)",
+                    action = "store", dest = "invalidate_stamp")
+
+        parser.add_option("-r", "--read", help = "read the specified file before bitbake.conf",
+                   action = "append", dest = "prefile", default = [])
+
+        parser.add_option("-R", "--postread", help = "read the specified file after bitbake.conf",
+                          action = "append", dest = "postfile", default = [])
+
+        parser.add_option("-v", "--verbose", help = "output more chit-chat to the terminal",
+                   action = "store_true", dest = "verbose", default = False)
+
+        parser.add_option("-D", "--debug", help = "Increase the debug level. You can specify this more than once.",
+                   action = "count", dest="debug", default = 0)
+
+        parser.add_option("-n", "--dry-run", help = "don't execute, just go through the motions",
+                   action = "store_true", dest = "dry_run", default = False)
+
+        parser.add_option("-S", "--dump-signatures", help = "don't execute, just dump out the signature construction information",
+                   action = "store_true", dest = "dump_signatures", default = False)
+
+        parser.add_option("-p", "--parse-only", help = "quit after parsing the BB files (developers only)",
+                   action = "store_true", dest = "parse_only", default = False)
+
+        parser.add_option("-s", "--show-versions", help = "show current and preferred versions of all recipes",
+                   action = "store_true", dest = "show_versions", default = False)
+
+        parser.add_option("-e", "--environment", help = "show the global or per-package environment (this is what used to be bbread)",
+                   action = "store_true", dest = "show_environment", default = False)
+
+        parser.add_option("-g", "--graphviz", help = "emit the dependency trees of the specified packages in the dot syntax, and the pn-buildlist to show the build list",
+                    action = "store_true", dest = "dot_graph", default = False)
+
+        parser.add_option("-I", "--ignore-deps", help = """Assume these dependencies don't exist and are already provided (equivalent to ASSUME_PROVIDED). Useful to make dependency graphs more appealing""",
+                    action = "append", dest = "extra_assume_provided", default = [])
+
+        parser.add_option("-l", "--log-domains", help = """Show debug logging for the specified logging domains""",
+                    action = "append", dest = "debug_domains", default = [])
+
+        parser.add_option("-P", "--profile", help = "profile the command and print a report",
+                   action = "store_true", dest = "profile", default = False)
+
+        parser.add_option("-u", "--ui", help = "userinterface to use",
+                   action = "store", dest = "ui")
+
+        parser.add_option("-t", "--servertype", help = "Choose which server to use, process or xmlrpc",
+                   action = "store", dest = "servertype")
+
+        parser.add_option("", "--revisions-changed", help = "Set the exit code depending on whether upstream floating revisions have changed or not",
+                   action = "store_true", dest = "revisions_changed", default = False)
+
+        parser.add_option("", "--server-only", help = "Run bitbake without UI,  the frontend can connect with bitbake server itself",
+                   action = "store_true", dest = "server_only", default = False)
+
+        parser.add_option("-B", "--bind", help = "The name/address for the bitbake server to bind to",
+                   action = "store", dest = "bind", default = False)
+
+        parser.add_option("", "--no-setscene", help = "Do not run any setscene tasks, forces builds",
+                   action = "store_true", dest = "nosetscene", default = False)
+
+        parser.add_option("", "--remote-server", help = "Connect to the specified server",
+                   action = "store", dest = "remote_server", default = False)
+
+        options, targets = parser.parse_args(sys.argv)
+        return options, targets[1:]
+
+
+def start_server(servermodule, configParams, configuration):
+    server = servermodule.BitBakeServer()
+    if configParams.bind:
+        server.initServer((configParams.bind, 0))
+    else:
+        server.initServer()
+
+    try:
+        configuration.setServerRegIdleCallback(server.getServerIdleCB())
+
+        cooker = bb.cooker.BBCooker(configuration)
+
+        server.addcooker(cooker)
+        server.saveConnectionDetails()
+    except Exception as e:
+        exc_info = sys.exc_info()
+        while True:
+            try:
+                import queue
+            except ImportError:
+                import Queue as queue
+            try:
+                event = server.event_queue.get(block=False)
+            except (queue.Empty, IOError):
+                break
+            if isinstance(event, logging.LogRecord):
+                logger.handle(event)
+        raise exc_info[1], None, exc_info[2]
+    server.detach()
+    return server
+
+
 
 def main():
-    parser = optparse.OptionParser(
-        version = "BitBake Build Tool Core version %s, %%prog version %s" % (bb.__version__, __version__),
-        usage = """%prog [options] [package ...]
 
-Executes the specified task (default is 'build') for a given set of BitBake files.
-It expects that BBFILES is defined, which is a space separated list of files to
-be executed.  BBFILES does support wildcards.
-Default BBFILES are the .bb files in the current directory.""")
+    configParams = BitBakeConfigParameters()
+    configuration = cookerdata.CookerConfiguration()
+    configuration.setConfigParameters(configParams)
 
-    parser.add_option("-b", "--buildfile", help = "execute the task against this .bb file, rather than a package from BBFILES. Does not handle any dependencies.",
-               action = "store", dest = "buildfile", default = None)
+    ui_module = get_ui(configParams)
 
-    parser.add_option("-k", "--continue", help = "continue as much as possible after an error. While the target that failed, and those that depend on it, cannot be remade, the other dependencies of these targets can be processed all the same.",
-               action = "store_false", dest = "abort", default = True)
-
-    parser.add_option("-a", "--tryaltconfigs", help = "continue with builds by trying to use alternative providers where possible.",
-               action = "store_true", dest = "tryaltconfigs", default = False)
-
-    parser.add_option("-f", "--force", help = "force run of specified cmd, regardless of stamp status",
-               action = "store_true", dest = "force", default = False)
-
-    parser.add_option("-c", "--cmd", help = "Specify task to execute. Note that this only executes the specified task for the providee and the packages it depends on, i.e. 'compile' does not implicitly call stage for the dependencies (IOW: use only if you know what you are doing). Depending on the base.bbclass a listtasks tasks is defined and will show available tasks",
-               action = "store", dest = "cmd")
-
-    parser.add_option("-C", "--clear-stamp", help = "Invalidate the stamp for the specified cmd such as 'compile' and run the default task for the specified target(s)",
-                action = "store", dest = "invalidate_stamp")
-
-    parser.add_option("-r", "--read", help = "read the specified file before bitbake.conf",
-               action = "append", dest = "prefile", default = [])
-
-    parser.add_option("-R", "--postread", help = "read the specified file after bitbake.conf",
-                      action = "append", dest = "postfile", default = [])
-
-    parser.add_option("-v", "--verbose", help = "output more chit-chat to the terminal",
-               action = "store_true", dest = "verbose", default = False)
-
-    parser.add_option("-D", "--debug", help = "Increase the debug level. You can specify this more than once.",
-               action = "count", dest="debug", default = 0)
-
-    parser.add_option("-n", "--dry-run", help = "don't execute, just go through the motions",
-               action = "store_true", dest = "dry_run", default = False)
-
-    parser.add_option("-S", "--dump-signatures", help = "don't execute, just dump out the signature construction information",
-               action = "store_true", dest = "dump_signatures", default = False)
-
-    parser.add_option("-p", "--parse-only", help = "quit after parsing the BB files (developers only)",
-               action = "store_true", dest = "parse_only", default = False)
-
-    parser.add_option("-s", "--show-versions", help = "show current and preferred versions of all recipes",
-               action = "store_true", dest = "show_versions", default = False)
-
-    parser.add_option("-e", "--environment", help = "show the global or per-package environment (this is what used to be bbread)",
-               action = "store_true", dest = "show_environment", default = False)
-
-    parser.add_option("-g", "--graphviz", help = "emit the dependency trees of the specified packages in the dot syntax, and the pn-buildlist to show the build list",
-                action = "store_true", dest = "dot_graph", default = False)
-
-    parser.add_option("-I", "--ignore-deps", help = """Assume these dependencies don't exist and are already provided (equivalent to ASSUME_PROVIDED). Useful to make dependency graphs more appealing""",
-                action = "append", dest = "extra_assume_provided", default = [])
-
-    parser.add_option("-l", "--log-domains", help = """Show debug logging for the specified logging domains""",
-                action = "append", dest = "debug_domains", default = [])
-
-    parser.add_option("-P", "--profile", help = "profile the command and print a report",
-               action = "store_true", dest = "profile", default = False)
-
-    parser.add_option("-u", "--ui", help = "userinterface to use",
-               action = "store", dest = "ui")
-
-    parser.add_option("-t", "--servertype", help = "Choose which server to use, none, process or xmlrpc",
-               action = "store", dest = "servertype")
-
-    parser.add_option("", "--revisions-changed", help = "Set the exit code depending on whether upstream floating revisions have changed or not",
-               action = "store_true", dest = "revisions_changed", default = False)
-
-    parser.add_option("", "--server-only", help = "Run bitbake without UI,  the frontend can connect with bitbake server itself",
-               action = "store_true", dest = "server_only", default = False)
-
-    parser.add_option("-B", "--bind", help = "The name/address for the bitbake server to bind to",
-               action = "store", dest = "bind", default = False)
-    parser.add_option("", "--no-setscene", help = "Do not run any setscene tasks, forces builds",
-               action = "store_true", dest = "nosetscene", default = False)
-    options, args = parser.parse_args(sys.argv)
-
-    configuration = BBConfiguration(options)
-    configuration.pkgs_to_build.extend(args[1:])
-
-    ui_main = get_ui(configuration)
-
-    # Server type can be xmlrpc, process or none currently, if nothing is specified,
+    # Server type can be xmlrpc or process currently, if nothing is specified,
     # the default server is process
-    if configuration.servertype:
-        server_type = configuration.servertype
+    if configParams.servertype:
+        server_type = configParams.servertype
     else:
         server_type = 'process'
 
     try:
         module = __import__("bb.server", fromlist = [server_type])
-        server = getattr(module, server_type)
+        servermodule = getattr(module, server_type)
     except AttributeError:
         sys.exit("FATAL: Invalid server type '%s' specified.\n"
-                 "Valid interfaces: xmlrpc, process [default], none." % servertype)
+                 "Valid interfaces: xmlrpc, process [default]." % servertype)
 
-    if configuration.server_only:
-        if configuration.servertype != "xmlrpc":
+    if configParams.server_only:
+        if configParams.servertype != "xmlrpc":
             sys.exit("FATAL: If '--server-only' is defined, we must set the servertype as 'xmlrpc'.\n")
-        if not configuration.bind:
+        if not configParams.bind:
             sys.exit("FATAL: The '--server-only' option requires a name/address to bind to with the -B option.\n")
 
-    if configuration.bind and configuration.servertype != "xmlrpc":
+    if configParams.bind and configParams.servertype != "xmlrpc":
         sys.exit("FATAL: If '-B' or '--bind' is defined, we must set the servertype as 'xmlrpc'.\n")
 
+    if configParams.remote_server and configParams.servertype != "xmlrpc":
+        sys.exit("FATAL: If '--remote-server' is defined, we must set the servertype as 'xmlrpc'.\n")
+
     if "BBDEBUG" in os.environ:
         level = int(os.environ["BBDEBUG"])
         if level > configuration.debug:
             configuration.debug = level
 
-    bb.msg.init_msgconfig(configuration.verbose, configuration.debug,
+    bb.msg.init_msgconfig(configParams.verbose, configuration.debug,
                          configuration.debug_domains)
 
     # Ensure logging messages get sent to the UI as events
     handler = bb.event.LogHandler()
     logger.addHandler(handler)
 
-    # Before we start modifying the environment we should take a pristine
-    # copy for possible later use
-    initialenv = os.environ.copy()
     # Clear away any spurious environment variables while we stoke up the cooker
     cleanedvars = bb.utils.clean_environment()
 
-    server = server.BitBakeServer()
-    if configuration.bind:
-        server.initServer((configuration.bind, 0))
+    # Collect all the caches we need
+    if configParams.server_only:
+        configuration.extra_caches = gather_extra_cache_data()
     else:
-        server.initServer()
+        configuration.extra_caches = getattr(ui_module, "extraCaches", [])
 
-    idle = server.getServerIdleCB()
-
-    cooker = bb.cooker.BBCooker(configuration, idle, initialenv)
-    cooker.parseCommandLine()
-
-    server.addcooker(cooker)
-    server.saveConnectionDetails()
-    server.detach()
-
-    # Should no longer need to ever reference cooker
-    del cooker
+    if not configParams.remote_server:
+        # we start a server with a given configuration
+        server = start_server(servermodule, configParams, configuration)
+    else:
+        # we start a stub server that is actually a XMLRPClient to
+        server = servermodule.BitBakeXMLRPCClient()
+        server.saveConnectionDetails(configParams.remote_server)
 
     logger.removeHandler(handler)
 
-    if not configuration.server_only:
+    if not configParams.server_only:
         # Setup a connection to the server (cooker)
         server_connection = server.establishConnection()
 
@@ -261,7 +308,7 @@ Default BBFILES are the .bb files in the current directory.""")
             os.environ[k] = cleanedvars[k]
 
         try:
-            return server.launchUI(ui_main, server_connection.connection, server_connection.events)
+            return ui_module.main(server_connection.connection, server_connection.events, configParams)
         finally:
             bb.event.ui_queue = []
             server_connection.terminate()
@@ -276,6 +323,6 @@ if __name__ == "__main__":
     except Exception:
         ret = 1
         import traceback
-        traceback.print_exc(5)
+        traceback.print_exc()
     sys.exit(ret)
 

bitbake/bin/bitbake-layers

@@ -89,7 +89,7 @@ class Commands(cmd.Cmd):
         for layerdir in self.bblayers:
             layername = self.get_layer_name(layerdir)
             layerpri = 0
-            for layer, _, regex, pri in self.bbhandler.cooker.status.bbfile_config_priorities:
+            for layer, _, regex, pri in self.bbhandler.cooker.recipecache.bbfile_config_priorities:
                 if regex.match(os.path.join(layerdir, 'test')):
                     layerpri = pri
                     break
@@ -225,15 +225,15 @@ Options:
 
 
     def list_recipes(self, title, pnspec, show_overlayed_only, show_same_ver_only, show_filenames, show_multi_provider_only):
-        pkg_pn = self.bbhandler.cooker.status.pkg_pn
-        (latest_versions, preferred_versions) = bb.providers.findProviders(self.bbhandler.cooker.configuration.data, self.bbhandler.cooker.status, pkg_pn)
-        allproviders = bb.providers.allProviders(self.bbhandler.cooker.status)
+        pkg_pn = self.bbhandler.cooker.recipecache.pkg_pn
+        (latest_versions, preferred_versions) = bb.providers.findProviders(self.bbhandler.cooker.configuration.data, self.bbhandler.cooker.recipecache, pkg_pn)
+        allproviders = bb.providers.allProviders(self.bbhandler.cooker.recipecache)
 
         # Ensure we list skipped recipes
         # We are largely guessing about PN, PV and the preferred version here,
         # but we have no choice since skipped recipes are not fully parsed
         skiplist = self.bbhandler.cooker.skiplist.keys()
-        skiplist.sort( key=lambda fileitem: self.bbhandler.cooker.calc_bbfile_priority(fileitem) )
+        skiplist.sort( key=lambda fileitem: self.bbhandler.cooker.collection.calc_bbfile_priority(fileitem) )
         skiplist.reverse()
         for fn in skiplist:
             recipe_parts = os.path.splitext(os.path.basename(fn))[0].split('_')
@@ -371,8 +371,8 @@ build results (as the layer priority order has effectively changed).
         appended_recipes = []
         for layer in layers:
             overlayed = []
-            for f in self.bbhandler.cooker.overlayed.iterkeys():
-                for of in self.bbhandler.cooker.overlayed[f]:
+            for f in self.bbhandler.cooker.collection.overlayed.iterkeys():
+                for of in self.bbhandler.cooker.collection.overlayed[f]:
                     if of.startswith(layer):
                         overlayed.append(of)
 
@@ -396,8 +396,8 @@ build results (as the layer priority order has effectively changed).
                                     logger.warn('Overwriting file %s', fdest)
                             bb.utils.copyfile(f1full, fdest)
                             if ext == '.bb':
-                                if f1 in self.bbhandler.cooker.appendlist:
-                                    appends = self.bbhandler.cooker.appendlist[f1]
+                                if f1 in self.bbhandler.cooker.collection.appendlist:
+                                    appends = self.bbhandler.cooker.collection.appendlist[f1]
                                     if appends:
                                         logger.plain('  Applying appends to %s' % fdest )
                                         for appendname in appends:
@@ -406,9 +406,9 @@ build results (as the layer priority order has effectively changed).
                                     appended_recipes.append(f1)
 
         # Take care of when some layers are excluded and yet we have included bbappends for those recipes
-        for recipename in self.bbhandler.cooker.appendlist.iterkeys():
+        for recipename in self.bbhandler.cooker.collection.appendlist.iterkeys():
             if recipename not in appended_recipes:
-                appends = self.bbhandler.cooker.appendlist[recipename]
+                appends = self.bbhandler.cooker.collection.appendlist[recipename]
                 first_append = None
                 for appendname in appends:
                     layer = layer_path_match(appendname)
@@ -426,7 +426,7 @@ build results (as the layer priority order has effectively changed).
         # have come from)
         first_regex = None
         layerdir = layers[0]
-        for layername, pattern, regex, _ in self.bbhandler.cooker.status.bbfile_config_priorities:
+        for layername, pattern, regex, _ in self.bbhandler.cooker.recipecache.bbfile_config_priorities:
             if regex.match(os.path.join(layerdir, 'test')):
                 first_regex = regex
                 break
@@ -456,7 +456,7 @@ build results (as the layer priority order has effectively changed).
                                 logger.warning("File %s does not match the flattened layer's BBFILES setting, you may need to edit conf/layer.conf or move the file elsewhere" % f1full)
 
     def get_file_layer(self, filename):
-        for layer, _, regex, _ in self.bbhandler.cooker.status.bbfile_config_priorities:
+        for layer, _, regex, _ in self.bbhandler.cooker.recipecache.bbfile_config_priorities:
             if regex.match(filename):
                 for layerdir in self.bblayers:
                     if regex.match(os.path.join(layerdir, 'test')) and re.match(layerdir, filename):
@@ -464,7 +464,7 @@ build results (as the layer priority order has effectively changed).
         return "?"
 
     def get_file_layerdir(self, filename):
-        for layer, _, regex, _ in self.bbhandler.cooker.status.bbfile_config_priorities:
+        for layer, _, regex, _ in self.bbhandler.cooker.recipecache.bbfile_config_priorities:
             if regex.match(filename):
                 for layerdir in self.bblayers:
                     if regex.match(os.path.join(layerdir, 'test')) and re.match(layerdir, filename):
@@ -498,7 +498,7 @@ usage: show-appends
 Recipes are listed with the bbappends that apply to them as subitems.
 """
         self.bbhandler.prepare()
-        if not self.bbhandler.cooker.appendlist:
+        if not self.bbhandler.cooker.collection.appendlist:
             logger.plain('No append files found')
             return
 
@@ -550,7 +550,7 @@ Recipes are listed with the bbappends that apply to them as subitems.
                 continue
 
             basename = os.path.basename(filename)
-            appends = self.bbhandler.cooker.appendlist.get(basename)
+            appends = self.bbhandler.cooker.collection.appendlist.get(basename)
             if appends:
                 appended.append((basename, list(appends)))
             else:

bitbake/bin/bitbake-runtask

@@ -1,119 +0,0 @@
-#!/usr/bin/env python
-
-import os
-import sys
-import warnings
-sys.path.insert(0, os.path.join(os.path.dirname(os.path.dirname(sys.argv[0])), 'lib'))
-from bb import fetch2
-import logging
-
-logger = logging.getLogger("BitBake")
-
-try:
-    import cPickle as pickle
-except ImportError:
-    import pickle
-    bb.msg.note(1, bb.msg.domain.Cache, "Importing cPickle failed. Falling back to a very slow implementation.")
-
-class BBConfiguration(object):
-    """
-    Manages build options and configurations for one run
-    """
-
-    def __init__(self, **options):
-        self.data = {}
-        self.file = []
-        self.cmd = None
-        self.dump_signatures = True
-        self.prefile = []
-        self.postfile = []
-        self.parse_only = True
-
-    def __getattr__(self, attribute):
-        try:
-            return super(BBConfiguration, self).__getattribute__(attribute)
-        except AttributeError:
-            return None
-
-_warnings_showwarning = warnings.showwarning
-def _showwarning(message, category, filename, lineno, file=None, line=None):
-    """Display python warning messages using bb.msg"""
-    if file is not None:
-        if _warnings_showwarning is not None:
-            _warnings_showwarning(message, category, filename, lineno, file, line)
-    else:
-        s = warnings.formatwarning(message, category, filename, lineno)
-        s = s.split("\n")[0]
-        bb.msg.warn(None, s)
-
-warnings.showwarning = _showwarning
-warnings.simplefilter("ignore", DeprecationWarning)
-
-import bb.event
-import bb.cooker
-
-buildfile = sys.argv[1]
-taskname = sys.argv[2]
-if len(sys.argv) >= 4:
-    dryrun = sys.argv[3]    
-else:
-    dryrun = False
-if len(sys.argv) >= 5:
-    hashfile = sys.argv[4]
-    p = pickle.Unpickler(file(hashfile, "rb"))
-    hashdata = p.load()
-else:
-    hashdata = None
-
-handler = bb.event.LogHandler()
-logger.addHandler(handler)
-
-#An example to make debug log messages show up
-#bb.msg.init_msgconfig(True, 3, [])
-
-console = logging.StreamHandler(sys.stdout)
-format = bb.msg.BBLogFormatter("%(levelname)s: %(message)s")
-bb.msg.addDefaultlogFilter(console)
-console.setFormatter(format)
-
-def worker_fire(event, d):
-    if isinstance(event, logging.LogRecord):
-        console.handle(event)
-bb.event.worker_fire = worker_fire
-bb.event.worker_pid = os.getpid()
-
-initialenv = os.environ.copy()
-config = BBConfiguration()
-
-def register_idle_function(self, function, data):
-    pass
-
-cooker = bb.cooker.BBCooker(config, register_idle_function, initialenv)
-config_data = cooker.configuration.data
-cooker.status = config_data
-cooker.handleCollections(config_data.getVar("BBFILE_COLLECTIONS", 1))
-
-fn, cls = bb.cache.Cache.virtualfn2realfn(buildfile)
-buildfile = cooker.matchFile(fn)
-fn = bb.cache.Cache.realfn2virtual(buildfile, cls)
-
-cooker.buildSetVars()
-
-# Load data into the cache for fn and parse the loaded cache data
-the_data = bb.cache.Cache.loadDataFull(fn, cooker.get_file_appends(fn), cooker.configuration.data)
-
-if taskname.endswith("_setscene"):
-    the_data.setVarFlag(taskname, "quieterrors", "1")
-
-if hashdata:
-    bb.parse.siggen.set_taskdata(hashdata["hashes"], hashdata["deps"])
-    for h in hashdata["hashes"]:
-        the_data.setVar("BBHASH_%s" % h, hashdata["hashes"][h])
-    for h in hashdata["deps"]:
-        the_data.setVar("BBHASHDEPS_%s" % h, hashdata["deps"][h])
-
-ret = 0
-if dryrun != "True":
-    ret = bb.build.exec_task(fn, taskname, the_data)
-sys.exit(ret)
-

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.18.0"
+__version__ = "1.19.0"
 
 import sys
 if sys.version_info < (2, 6, 0):

bitbake/lib/bb/build.py

@@ -60,7 +60,7 @@ class FuncFailed(Exception):
 
     def __str__(self):
         if self.logfile and os.path.exists(self.logfile):
-            msg = ("%s (see %s for further information)" %
+            msg = ("%s (log file is located at %s)" %
                    (self.msg, self.logfile))
         else:
             msg = self.msg
@@ -275,7 +275,8 @@ def exec_func_shell(func, d, runfile, cwd=None):
     bb.debug(2, "Executing shell function %s" % func)
 
     try:
-        bb.process.run(cmd, shell=False, stdin=NULL, log=logfile)
+        with open(os.devnull, 'r+') as stdin:
+            bb.process.run(cmd, shell=False, stdin=stdin, log=logfile)
     except bb.process.CmdError:
         logfn = d.getVar('BB_LOGFILE', True)
         raise FuncFailed(func, logfn)
@@ -319,12 +320,11 @@ def _exec_task(fn, task, d, quieterr):
     # Document the order of the tasks...
     logorder = os.path.join(tempdir, 'log.task_order')
     try:
-        logorderfile = file(logorder, 'a')
+        with open(logorder, 'a') as logorderfile:
+            logorderfile.write('{0} ({1}): {2}\n'.format(task, os.getpid(), logbase))
     except OSError:
         logger.exception("Opening log file '%s'", logorder)
         pass
-    logorderfile.write('{0} ({1}): {2}\n'.format(task, os.getpid(), logbase))
-    logorderfile.close()
 
     # Setup the courtesy link to the logfn
     loglink = os.path.join(tempdir, 'log.{0}'.format(task))
@@ -348,10 +348,10 @@ def _exec_task(fn, task, d, quieterr):
             self.triggered = True
 
     # Handle logfiles
-    si = file('/dev/null', 'r')
+    si = open('/dev/null', 'r')
     try:
         bb.utils.mkdirhier(os.path.dirname(logfn))
-        logfile = file(logfn, 'w')
+        logfile = open(logfn, 'w')
     except OSError:
         logger.exception("Opening log file '%s'", logfn)
         pass
@@ -533,8 +533,7 @@ def make_stamp(task, d, file_name = None):
     # change on broken NFS filesystems
     if stamp:
         bb.utils.remove(stamp)
-        f = open(stamp, "w")
-        f.close()
+        open(stamp, "w").close()
 
     # If we're in task context, write out a signature file for each task
     # as it completes

bitbake/lib/bb/cache.py

@@ -526,7 +526,7 @@ class Cache(object):
 
         if appends != info_array[0].appends:
             logger.debug(2, "Cache: appends for %s changed", fn)
-            bb.note("%s to %s" % (str(appends), str(info_array[0].appends)))
+            logger.debug(2, "%s to %s" % (str(appends), str(info_array[0].appends)))
             self.remove(fn)
             return False
 
@@ -738,8 +738,9 @@ class MultiProcessCache(object):
         logger.debug(1, "Using cache in '%s'", self.cachefile)
 
         try:
-            p = pickle.Unpickler(file(self.cachefile, "rb"))
-            data, version = p.load()
+            with open(self.cachefile, "rb") as f:
+                p = pickle.Unpickler(f)
+                data, version = p.load()
         except:
             return
 
@@ -779,8 +780,9 @@ class MultiProcessCache(object):
                 i = i + 1
                 continue
 
-            p = pickle.Pickler(file(self.cachefile + "-" + str(i), "wb"), -1)
-            p.dump([self.cachedata_extras, self.__class__.CACHE_VERSION])
+            with open(self.cachefile + "-" + str(i), "wb") as f:
+                p = pickle.Pickler(f, -1)
+                p.dump([self.cachedata_extras, self.__class__.CACHE_VERSION])
 
         bb.utils.unlockfile(lf)
         bb.utils.unlockfile(glf)
@@ -798,8 +800,9 @@ class MultiProcessCache(object):
         glf = bb.utils.lockfile(self.cachefile + ".lock")
 
         try:
-            p = pickle.Unpickler(file(self.cachefile, "rb"))
-            data, version = p.load()
+            with open(self.cachefile, "rb") as f:
+                p = pickle.Unpickler(f)
+                data, version = p.load()
         except (IOError, EOFError):
             data, version = None, None
 
@@ -809,8 +812,9 @@ class MultiProcessCache(object):
         for f in [y for y in os.listdir(os.path.dirname(self.cachefile)) if y.startswith(os.path.basename(self.cachefile) + '-')]:
             f = os.path.join(os.path.dirname(self.cachefile), f)
             try:
-                p = pickle.Unpickler(file(f, "rb"))
-                extradata, version = p.load()
+                with open(f, "rb") as fd:
+                    p = pickle.Unpickler(fd)
+                    extradata, version = p.load()
             except (IOError, EOFError):
                 extradata, version = self.create_cachedata(), None
 
@@ -822,8 +826,9 @@ class MultiProcessCache(object):
 
         self.compress_keys(data)
 
-        p = pickle.Pickler(file(self.cachefile, "wb"), -1)
-        p.dump([data, self.__class__.CACHE_VERSION])
+        with open(self.cachefile, "wb") as f:
+            p = pickle.Pickler(f, -1)
+            p.dump([data, self.__class__.CACHE_VERSION])
 
         bb.utils.unlockfile(glf)
 

bitbake/lib/bb/command.py

@@ -78,7 +78,7 @@ class Command:
         if command not in CommandsAsync.__dict__:
             return None, "No such command"
         self.currentAsyncCommand = (command, commandline)
-        self.cooker.server_registration_cb(self.cooker.runCommands, self.cooker)
+        self.cooker.configuration.server_register_idlecallback(self.cooker.runCommands, self.cooker)
         return True, None
 
     def runAsyncCommand(self):
@@ -143,18 +143,6 @@ class CommandsSync:
         """
         command.cooker.stop()
 
-    def getCmdLineAction(self, command, params):
-        """
-        Get any command parsed from the commandline
-        """
-        cmd_action = command.cooker.commandlineAction
-        if cmd_action is None:
-            return None
-        elif 'msg' in cmd_action and cmd_action['msg']:
-            raise CommandError(cmd_action['msg'])
-        else:
-            return cmd_action['action']
-
     def getVariable(self, command, params):
         """
         Read the value of a variable from configuration.data
@@ -174,6 +162,14 @@ class CommandsSync:
         value = str(params[1])
         command.cooker.configuration.data.setVar(varname, value)
 
+    def setConfig(self, command, params):
+        """
+        Set the value of variable in configuration
+        """
+        varname = params[0]
+        value = str(params[1])
+        setattr(command.cooker.configuration, varname, value)
+
     def enableDataTracking(self, command, params):
         """
         Enable history tracking for variables
@@ -391,7 +387,9 @@ class CommandsAsync:
         """
         prefiles = params[0]
         postfiles = params[1]
-        command.cooker.parseConfigurationFiles(prefiles, postfiles)
+        command.cooker.configuration.prefile = prefiles
+        command.cooker.configuration.postfile = postfiles
+        command.cooker.loadConfigurationData()
         command.finishAsyncCommand()
     parseConfigurationFiles.needcache = False
 

bitbake/lib/bb/compat.py

@@ -343,7 +343,7 @@ def worker(inqueue, outqueue, initializer=None, initargs=(), maxtasks=None):
         job, i, func, args, kwds = task
         try:
             result = (True, func(*args, **kwds))
-        except Exception, e:
+        except Exception as e:
             result = (False, e)
         try:
             put((job, i, result))

bitbake/lib/bb/cooker.py

@@ -87,46 +87,15 @@ class BBCooker:
     Manages one bitbake build run
     """
 
-    def __init__(self, configuration, server_registration_cb, savedenv={}):
-        self.status = None
-        self.appendlist = {}
+    def __init__(self, configuration):
+        self.recipecache = None
         self.skiplist = {}
 
-        self.server_registration_cb = server_registration_cb
-
         self.configuration = configuration
 
-        # Keep a datastore of the initial environment variables and their
-        # values from when BitBake was launched to enable child processes
-        # to use environment variables which have been cleaned from the
-        # BitBake processes env
-        self.savedenv = bb.data.init()
-        for k in savedenv:
-            self.savedenv.setVar(k, savedenv[k])
-
         self.caches_array = []
-        # Currently, only Image Creator hob ui needs extra cache.
-        # So, we save Extra Cache class name and container file
-        # information into a extraCaches field in hob UI.  
-        # TODO: In future, bin/bitbake should pass information into cooker,
-        # instead of getting information from configuration.ui. Also, some
-        # UI start up issues need to be addressed at the same time.
-        caches_name_array = ['bb.cache:CoreRecipeInfo']
-        if configuration.ui:
-            try:
-                module = __import__('bb.ui', fromlist=[configuration.ui])
-                name_array = (getattr(module, configuration.ui)).extraCaches
-                for recipeInfoName in name_array:
-                    caches_name_array.append(recipeInfoName)
-            except ImportError as exc:
-                # bb.ui.XXX is not defined and imported. It's an error!
-                logger.critical("Unable to import '%s' interface from bb.ui: %s" % (configuration.ui, exc))
-                sys.exit("FATAL: Failed to import '%s' interface." % configuration.ui)
-            except AttributeError:
-                # This is not an error. If the field is not defined in the ui,
-                # this interface might need no extra cache fields, so
-                # just skip this error!
-                logger.debug(2, "UI '%s' does not require extra cache!" % (configuration.ui))
+
+        caches_name_array = ['bb.cache:CoreRecipeInfo'] + configuration.extra_caches
 
         # At least CoreRecipeInfo will be loaded, so caches_array will never be empty!
         # This is the entry point, no further check needed!
@@ -140,6 +109,7 @@ class BBCooker:
                 sys.exit("FATAL: Failed to import extra cache class '%s'." % cache_name)
 
         self.configuration.data = None
+        self.initConfigurationData()
         self.loadConfigurationData()
 
         # Take a lock so only one copy of bitbake can run against a given build
@@ -149,10 +119,6 @@ class BBCooker:
         if not self.lock:
             bb.fatal("Only one copy of bitbake should be run against a build directory")
 
-        bbpkgs = self.configuration.data.getVar('BBPKGS', True)
-        if bbpkgs and len(self.configuration.pkgs_to_build) == 0:
-            self.configuration.pkgs_to_build.extend(bbpkgs.split())
-
         #
         # Special updated configuration we use for firing events
         #
@@ -176,16 +142,12 @@ class BBCooker:
         self.parser = None
 
     def initConfigurationData(self):
-        self.configuration.data = bb.data.init()
-        if self.configuration.show_environment:
-            self.configuration.data.enableTracking()
+        worker = False
+        if not self.configuration.server_register_idlecallback:
+            worker = True
 
-        if not self.server_registration_cb:
-            self.configuration.data.setVar("BB_WORKERCONTEXT", "1")
-
-        filtered_keys = bb.utils.approved_variables()
-        bb.data.inheritFromOS(self.configuration.data, self.savedenv, filtered_keys)
-        self.configuration.data.setVar("BB_ORIGENV", self.savedenv)
+        self.databuilder = bb.cookerdata.CookerDataBuilder(self.configuration, worker)
+        self.configuration.data = self.databuilder.data
 
     def enableDataTracking(self):
         self.configuration.data.enableTracking()
@@ -194,19 +156,9 @@ class BBCooker:
         self.configuration.data.disableTracking()
 
     def loadConfigurationData(self):
-        self.initConfigurationData()
-
-        try:
-            self.parseConfigurationFiles(self.configuration.prefile,
-                                         self.configuration.postfile)
-        except SyntaxError:
-            sys.exit(1)
-        except Exception:
-            logger.exception("Error parsing configuration files")
-            sys.exit(1)
-
-        if not self.configuration.cmd:
-            self.configuration.cmd = self.configuration.data.getVar("BB_DEFAULT_TASK", True) or "build"
+        self.databuilder.parseBaseConfiguration()
+        self.configuration.data = self.databuilder.data
+        self.configuration.data_hash = self.databuilder.data_hash
 
     def saveConfigurationVar(self, var, val, default_file):
 
@@ -269,7 +221,7 @@ class BBCooker:
             self.configuration.data.varhistory.del_var_history(var)
 
             #add var to the end of default_file
-            default_file = self._findConfigFile(default_file)
+            default_file = bb.cookerdata.findConfigFile(default_file)
 
             with open(default_file, 'r') as f:
                 contents = f.readlines()
@@ -305,50 +257,12 @@ class BBCooker:
             nice = int(nice) - curnice
             buildlog.verbose("Renice to %s " % os.nice(nice))
 
-        if self.status:
-            del self.status
-        self.status = bb.cache.CacheData(self.caches_array)
+        if self.recipecache:
+            del self.recipecache
+        self.recipecache = bb.cache.CacheData(self.caches_array)
 
         self.handleCollections( self.configuration.data.getVar("BBFILE_COLLECTIONS", True) )
 
-    def parseCommandLine(self):
-        # Parse any commandline into actions
-        self.commandlineAction = {'action':None, 'msg':None}
-        if self.configuration.show_environment:
-            if 'world' in self.configuration.pkgs_to_build:
-                self.commandlineAction['msg'] = "'world' is not a valid target for --environment."
-            elif 'universe' in self.configuration.pkgs_to_build:
-                self.commandlineAction['msg'] = "'universe' is not a valid target for --environment."
-            elif len(self.configuration.pkgs_to_build) > 1:
-                self.commandlineAction['msg'] = "Only one target can be used with the --environment option."
-            elif self.configuration.buildfile and len(self.configuration.pkgs_to_build) > 0:
-                self.commandlineAction['msg'] = "No target should be used with the --environment and --buildfile options."
-            elif len(self.configuration.pkgs_to_build) > 0:
-                self.commandlineAction['action'] = ["showEnvironmentTarget", self.configuration.pkgs_to_build]
-                self.configuration.data.setVar("BB_CONSOLELOG", None)
-            else:
-                self.commandlineAction['action'] = ["showEnvironment", self.configuration.buildfile]
-                self.configuration.data.setVar("BB_CONSOLELOG", None)
-        elif self.configuration.buildfile is not None:
-            self.commandlineAction['action'] = ["buildFile", self.configuration.buildfile, self.configuration.cmd]
-        elif self.configuration.revisions_changed:
-            self.commandlineAction['action'] = ["compareRevisions"]
-        elif self.configuration.show_versions:
-            self.commandlineAction['action'] = ["showVersions"]
-        elif self.configuration.parse_only:
-            self.commandlineAction['action'] = ["parseFiles"]
-        elif self.configuration.dot_graph:
-            if self.configuration.pkgs_to_build:
-                self.commandlineAction['action'] = ["generateDotGraph", self.configuration.pkgs_to_build, self.configuration.cmd]
-            else:
-                self.commandlineAction['msg'] = "Please specify a package name for dependency graph generation."
-        else:
-            if self.configuration.pkgs_to_build:
-                self.commandlineAction['action'] = ["buildTargets", self.configuration.pkgs_to_build, self.configuration.cmd]
-            else:
-                #self.commandlineAction['msg'] = "Nothing to do.  Use 'bitbake world' to build everything, or run 'bitbake --help' for usage information."
-                self.commandlineAction = None
-
     def runCommands(self, server, data, abort):
         """
         Run any queued asynchronous command
@@ -360,11 +274,8 @@ class BBCooker:
 
     def showVersions(self):
 
-        # Need files parsed
-        self.updateCache()
-
-        pkg_pn = self.status.pkg_pn
-        (latest_versions, preferred_versions) = bb.providers.findProviders(self.configuration.data, self.status, pkg_pn)
+        pkg_pn = self.recipecache.pkg_pn
+        (latest_versions, preferred_versions) = bb.providers.findProviders(self.configuration.data, self.recipecache, pkg_pn)
 
         logger.plain("%-35s %25s %25s", "Recipe Name", "Latest Version", "Preferred Version")
         logger.plain("%-35s %25s %25s\n", "===========", "==============", "=================")
@@ -397,8 +308,6 @@ class BBCooker:
             fn = self.matchFile(fn)
             fn = bb.cache.Cache.realfn2virtual(fn, cls)
         elif len(pkgs_to_build) == 1:
-            self.updateCache()
-
             ignore = self.configuration.data.getVar("ASSUME_PROVIDED", True) or ""
             if pkgs_to_build[0] in set(ignore.split()):
                 bb.fatal("%s is in ASSUME_PROVIDED" % pkgs_to_build[0])
@@ -408,8 +317,8 @@ class BBCooker:
             bb.data.expandKeys(localdata)
 
             taskdata = bb.taskdata.TaskData(self.configuration.abort)
-            taskdata.add_provider(localdata, self.status, pkgs_to_build[0])
-            taskdata.add_unresolved(localdata, self.status)
+            taskdata.add_provider(localdata, self.recipecache, pkgs_to_build[0])
+            taskdata.add_unresolved(localdata, self.recipecache)
 
             targetid = taskdata.getbuild_id(pkgs_to_build[0])
             fnid = taskdata.build_targets[targetid][0]
@@ -419,7 +328,7 @@ class BBCooker:
 
         if fn:
             try:
-                envdata = bb.cache.Cache.loadDataFull(fn, self.get_file_appends(fn), self.configuration.data)
+                envdata = bb.cache.Cache.loadDataFull(fn, self.collection.get_file_appends(fn), self.configuration.data)
             except Exception as e:
                 parselog.exception("Unable to read %s", fn)
                 raise
@@ -446,8 +355,7 @@ class BBCooker:
         Prepare a runqueue and taskdata object for iteration over pkgs_to_build
         """
         bb.event.fire(bb.event.TreeDataPreparationStarted(), self.configuration.data)
-        # Need files parsed
-        self.updateCache()
+
         # If we are told to do the None task then query the default task
         if (task == None):
             task = self.configuration.cmd
@@ -464,11 +372,11 @@ class BBCooker:
         runlist = []
         current = 0
         for k in pkgs_to_build:
-            taskdata.add_provider(localdata, self.status, k)
+            taskdata.add_provider(localdata, self.recipecache, k)
             runlist.append([k, "do_%s" % task])
             current += 1
             bb.event.fire(bb.event.TreeDataPreparationProgress(current, len(pkgs_to_build)), self.configuration.data)
-        taskdata.add_unresolved(localdata, self.status)
+        taskdata.add_unresolved(localdata, self.recipecache)
         bb.event.fire(bb.event.TreeDataPreparationCompleted(len(pkgs_to_build)), self.configuration.data)
         return runlist, taskdata
     
@@ -480,7 +388,7 @@ class BBCooker:
         information.
         """
         runlist, taskdata = self.prepareTreeData(pkgs_to_build, task)
-        rq = bb.runqueue.RunQueue(self, self.configuration.data, self.status, taskdata, runlist)
+        rq = bb.runqueue.RunQueue(self, self.configuration.data, self.recipecache, taskdata, runlist)
         rq.rqdata.prepare()
 
         seen_fnids = []
@@ -497,15 +405,15 @@ class BBCooker:
             taskname = rq.rqdata.runq_task[task]
             fnid = rq.rqdata.runq_fnid[task]
             fn = taskdata.fn_index[fnid]
-            pn = self.status.pkg_fn[fn]
-            version  = "%s:%s-%s" % self.status.pkg_pepvpr[fn]
+            pn = self.recipecache.pkg_fn[fn]
+            version  = "%s:%s-%s" % self.recipecache.pkg_pepvpr[fn]
             if pn not in depend_tree["pn"]:
                 depend_tree["pn"][pn] = {}
                 depend_tree["pn"][pn]["filename"] = fn
                 depend_tree["pn"][pn]["version"] = version
             for dep in rq.rqdata.runq_depends[task]:
                 depfn = taskdata.fn_index[rq.rqdata.runq_fnid[dep]]
-                deppn = self.status.pkg_fn[depfn]
+                deppn = self.recipecache.pkg_fn[depfn]
                 dotname = "%s.%s" % (pn, rq.rqdata.runq_task[task])
                 if not dotname in depend_tree["tdepends"]:
                     depend_tree["tdepends"][dotname] = []
@@ -522,14 +430,14 @@ class BBCooker:
                 for rdep in taskdata.rdepids[fnid]:
                     depend_tree["rdepends-pn"][pn].append(taskdata.run_names_index[rdep])
 
-                rdepends = self.status.rundeps[fn]
+                rdepends = self.recipecache.rundeps[fn]
                 for package in rdepends:
                     depend_tree["rdepends-pkg"][package] = []
                     for rdepend in rdepends[package]:
                         depend_tree["rdepends-pkg"][package].append(rdepend)
                     packages.append(package)
 
-                rrecs = self.status.runrecs[fn]
+                rrecs = self.recipecache.runrecs[fn]
                 for package in rrecs:
                     depend_tree["rrecs-pkg"][package] = []
                     for rdepend in rrecs[package]:
@@ -568,19 +476,19 @@ class BBCooker:
         for task in xrange(len(tasks_fnid)):
             fnid = tasks_fnid[task]
             fn = taskdata.fn_index[fnid]
-            pn = self.status.pkg_fn[fn]
-            version  = "%s:%s-%s" % self.status.pkg_pepvpr[fn]
-            summary = self.status.summary[fn]
-            lic = self.status.license[fn]
-            section = self.status.section[fn]
-            description = self.status.description[fn]
-            homepage = self.status.homepage[fn]
-            bugtracker = self.status.bugtracker[fn]
-            files_info = self.status.files_info[fn]
-            rdepends = self.status.rundeps[fn]
-            rrecs = self.status.runrecs[fn]
-            prevision = self.status.prevision[fn]
-            inherits = self.status.inherits.get(fn, None)
+            pn = self.recipecache.pkg_fn[fn]
+            version  = "%s:%s-%s" % self.recipecache.pkg_pepvpr[fn]
+            summary = self.recipecache.summary[fn]
+            lic = self.recipecache.license[fn]
+            section = self.recipecache.section[fn]
+            description = self.recipecache.description[fn]
+            homepage = self.recipecache.homepage[fn]
+            bugtracker = self.recipecache.bugtracker[fn]
+            files_info = self.recipecache.files_info[fn]
+            rdepends = self.recipecache.rundeps[fn]
+            rrecs = self.recipecache.runrecs[fn]
+            prevision = self.recipecache.prevision[fn]
+            inherits = self.recipecache.inherits.get(fn, None)
             if pn not in depend_tree["pn"]:
                 depend_tree["pn"][pn] = {}
                 depend_tree["pn"][pn]["filename"] = fn
@@ -606,7 +514,7 @@ class BBCooker:
                     if targetid in taskdata.build_targets and taskdata.build_targets[targetid]:
                         id = taskdata.build_targets[targetid][0]
                         fn_provider = taskdata.fn_index[id]
-                        pn_provider = self.status.pkg_fn[fn_provider]
+                        pn_provider = self.recipecache.pkg_fn[fn_provider]
                     else:
                         pn_provider = item
                     depend_tree["depends"][pn].append(pn_provider)
@@ -619,7 +527,7 @@ class BBCooker:
                     if targetid in taskdata.run_targets and taskdata.run_targets[targetid]:
                         id = taskdata.run_targets[targetid][0]
                         fn_rprovider = taskdata.fn_index[id]
-                        pn_rprovider = self.status.pkg_fn[fn_rprovider]
+                        pn_rprovider = self.recipecache.pkg_fn[fn_rprovider]
                     else:
                         pn_rprovider = item
                     depend_tree["rdepends-pn"][pn].append(pn_rprovider)
@@ -698,22 +606,13 @@ class BBCooker:
         print("}", file=tdepends_file)
         logger.info("Task dependencies saved to 'task-depends.dot'")
 
-    def calc_bbfile_priority( self, filename, matched = None ):
-        for _, _, regex, pri in self.status.bbfile_config_priorities:
-            if regex.match(filename):
-                if matched != None:
-                    if not regex in matched:
-                        matched.add(regex)
-                return pri
-        return 0
-
     def show_appends_with_no_recipes( self ):
         recipes = set(os.path.basename(f)
-                      for f in self.status.pkg_fn.iterkeys())
+                      for f in self.recipecache.pkg_fn.iterkeys())
         recipes |= set(os.path.basename(f)
                       for f in self.skiplist.iterkeys())
-        appended_recipes = self.appendlist.iterkeys()
-        appends_without_recipes = [self.appendlist[recipe]
+        appended_recipes = self.collection.appendlist.iterkeys()
+        appends_without_recipes = [self.collection.appendlist[recipe]
                                    for recipe in appended_recipes
                                    if recipe not in recipes]
         if appends_without_recipes:
@@ -728,9 +627,7 @@ class BBCooker:
             else:
                 bb.fatal(msg)
 
-    def buildDepgraph( self ):
-        all_depends = self.status.all_depends
-        pn_provides = self.status.pn_provides
+    def handlePrefProviders(self):
 
         localdata = data.createCopy(self.configuration.data)
         bb.data.update_data(localdata)
@@ -743,36 +640,9 @@ class BBCooker:
             except:
                 providerlog.critical("Malformed option in PREFERRED_PROVIDERS variable: %s" % p)
                 continue
-            if providee in self.status.preferred and self.status.preferred[providee] != provider:
-                providerlog.error("conflicting preferences for %s: both %s and %s specified", providee, provider, self.status.preferred[providee])
-            self.status.preferred[providee] = provider
-
-        # Calculate priorities for each file
-        matched = set()
-        for p in self.status.pkg_fn:
-            realfn, cls = bb.cache.Cache.virtualfn2realfn(p)
-            self.status.bbfile_priority[p] = self.calc_bbfile_priority(realfn, matched)
- 
-        # Don't show the warning if the BBFILE_PATTERN did match .bbappend files
-        unmatched = set()
-        for _, _, regex, pri in self.status.bbfile_config_priorities:        
-            if not regex in matched:
-                unmatched.add(regex)
-
-        def findmatch(regex):
-            for bbfile in self.appendlist:
-                for append in self.appendlist[bbfile]:
-                    if regex.match(append):
-                        return True
-            return False
-
-        for unmatch in unmatched.copy():
-            if findmatch(unmatch):
-                unmatched.remove(unmatch)
-
-        for collection, pattern, regex, _ in self.status.bbfile_config_priorities:
-            if regex in unmatched:
-                collectlog.warn("No bb files matched BBFILE_PATTERN_%s '%s'" % (collection, pattern))
+            if providee in self.recipecache.preferred and self.recipecache.preferred[providee] != provider:
+                providerlog.error("conflicting preferences for %s: both %s and %s specified", providee, provider, self.recipecache.preferred[providee])
+            self.recipecache.preferred[providee] = provider
 
     def findCoreBaseFiles(self, subdir, configfile):
         corebase = self.configuration.data.getVar('COREBASE', True) or ""
@@ -791,7 +661,7 @@ class BBCooker:
         Find the location on disk of configfile and if it exists and was parsed by BitBake
         emit the ConfigFilePathFound event with the path to the file.
         """
-        path = self._findConfigFile(configfile)
+        path = bb.cookerdata.findConfigFile(configfile)
         if not path:
             return
 
@@ -869,10 +739,10 @@ class BBCooker:
         """
         pkg_list = []
 
-        for pfn in self.status.pkg_fn:
-            inherits = self.status.inherits.get(pfn, None)
+        for pfn in self.recipecache.pkg_fn:
+            inherits = self.recipecache.inherits.get(pfn, None)
             if inherits and inherits.count(klass) > 0:
-                pkg_list.append(self.status.pkg_fn[pfn])
+                pkg_list.append(self.recipecache.pkg_fn[pfn])
 
         return pkg_list
 
@@ -898,25 +768,23 @@ class BBCooker:
         """
          Build package list for "bitbake world"
         """
-        all_depends = self.status.all_depends
-        pn_provides = self.status.pn_provides
         parselog.debug(1, "collating packages for \"world\"")
-        for f in self.status.possible_world:
+        for f in self.recipecache.possible_world:
             terminal = True
-            pn = self.status.pkg_fn[f]
+            pn = self.recipecache.pkg_fn[f]
 
-            for p in pn_provides[pn]:
+            for p in self.recipecache.pn_provides[pn]:
                 if p.startswith('virtual/'):
                     parselog.debug(2, "World build skipping %s due to %s provider starting with virtual/", f, p)
                     terminal = False
                     break
-                for pf in self.status.providers[p]:
-                    if self.status.pkg_fn[pf] != pn:
+                for pf in self.recipecache.providers[p]:
+                    if self.recipecache.pkg_fn[pf] != pn:
                         parselog.debug(2, "World build skipping %s due to both us and %s providing %s", f, pf, p)
                         terminal = False
                         break
             if terminal:
-                self.status.world_target.add(pn)
+                self.recipecache.world_target.add(pn)
 
     def interactiveMode( self ):
         """Drop off into a shell"""
@@ -928,81 +796,11 @@ class BBCooker:
         else:
             shell.start( self )
 
-    def _findConfigFile(self, configfile):
-        path = os.getcwd()
-        while path != "/":
-            confpath = os.path.join(path, "conf", configfile)
-            if os.path.exists(confpath):
-                return confpath
-
-            path, _ = os.path.split(path)
-        return None
-
-    def _findLayerConf(self):
-        return self._findConfigFile("bblayers.conf")
-
-    def parseConfigurationFiles(self, prefiles, postfiles):
-        data = self.configuration.data
-        bb.parse.init_parser(data)
-
-        # Parse files for loading *before* bitbake.conf and any includes
-        for f in prefiles:
-            data = _parse(f, data)
-
-        layerconf = self._findLayerConf()
-        if layerconf:
-            parselog.debug(2, "Found bblayers.conf (%s)", layerconf)
-            data = _parse(layerconf, data)
-
-            layers = (data.getVar('BBLAYERS', True) or "").split()
-
-            data = bb.data.createCopy(data)
-            for layer in layers:
-                parselog.debug(2, "Adding layer %s", layer)
-                data.setVar('LAYERDIR', layer)
-                data = _parse(os.path.join(layer, "conf", "layer.conf"), data)
-                data.expandVarref('LAYERDIR')
-
-            data.delVar('LAYERDIR')
-
-        if not data.getVar("BBPATH", True):
-            raise SystemExit("The BBPATH variable is not set")
-
-        data = _parse(os.path.join("conf", "bitbake.conf"), data)
-
-        # Parse files for loading *after* bitbake.conf and any includes
-        for p in postfiles:
-            data = _parse(p, data)
-
-        # Handle any INHERITs and inherit the base class
-        bbclasses  = ["base"] + (data.getVar('INHERIT', True) or "").split()
-        for bbclass in bbclasses:
-            data = _inherit(bbclass, data)
-
-        # Nomally we only register event handlers at the end of parsing .bb files
-        # We register any handlers we've found so far here...
-        for var in data.getVar('__BBHANDLERS') or []:
-            bb.event.register(var, data.getVar(var))
-
-        if data.getVar("BB_WORKERCONTEXT", False) is None:
-            bb.fetch.fetcher_init(data)
-        bb.codeparser.parser_cache_init(data)
-        bb.event.fire(bb.event.ConfigParsed(), data)
-
-        if data.getVar("BB_INVALIDCONF") is True:
-            data.setVar("BB_INVALIDCONF", False)
-            self.parseConfigurationFiles(self.configuration.prefile,
-                                         self.configuration.postfile)
-        else:
-            bb.parse.init_parser(data)
-            data.setVar('BBINCLUDED',bb.parse.get_file_depends(data))
-            self.configuration.data = data
-            self.configuration.data_hash = data.get_hash()
 
     def handleCollections( self, collections ):
         """Handle collections"""
         errors = False
-        self.status.bbfile_config_priorities = []
+        self.recipecache.bbfile_config_priorities = []
         if collections:
             collection_priorities = {}
             collection_depends = {}
@@ -1052,7 +850,7 @@ class BBCooker:
                                         parselog.error("invalid value for LAYERVERSION_%s: \"%s\"", c, layerver)
                                         errors = True
                                         continue
-                                    if lver <> depver:
+                                    if lver != depver:
                                         parselog.error("Layer '%s' depends on version %d of layer '%s', but version %d is enabled in your configuration", c, depver, dep, lver)
                                         errors = True
                                 else:
@@ -1092,7 +890,7 @@ class BBCooker:
                     parselog.error("BBFILE_PATTERN_%s \"%s\" is not a valid regular expression", c, regex)
                     errors = True
                     continue
-                self.status.bbfile_config_priorities.append((c, regex, cre, collection_priorities[c]))
+                self.recipecache.bbfile_config_priorities.append((c, regex, cre, collection_priorities[c]))
         if errors:
             # We've already printed the actual error(s)
             raise CollectionError("Errors during parsing layer configuration")
@@ -1111,7 +909,9 @@ class BBCooker:
         """
         if bf.startswith("/") or bf.startswith("../"):
             bf = os.path.abspath(bf)
-        filelist, masked = self.collect_bbfiles()
+
+        self.collection = CookerCollectFiles(self.recipecache.bbfile_config_priorities)
+        filelist, masked = self.collection.collect_bbfiles(self.configuration.data, self.configuration.event_data)
         try:
             os.stat(bf)
             bf = os.path.abspath(bf)
@@ -1164,8 +964,8 @@ class BBCooker:
 
         self.buildSetVars()
 
-        self.status = bb.cache.CacheData(self.caches_array)
-        infos = bb.cache.Cache.parse(fn, self.get_file_appends(fn), \
+        self.recipecache = bb.cache.CacheData(self.caches_array)
+        infos = bb.cache.Cache.parse(fn, self.collection.get_file_appends(fn), \
                                      self.configuration.data,
                                      self.caches_array)
         infos = dict(infos)
@@ -1179,27 +979,27 @@ class BBCooker:
         if info_array[0].skipped:
             bb.fatal("%s was skipped: %s" % (fn, info_array[0].skipreason))
 
-        self.status.add_from_recipeinfo(fn, info_array)
+        self.recipecache.add_from_recipeinfo(fn, info_array)
 
         # Tweak some variables
         item = info_array[0].pn
-        self.status.ignored_dependencies = set()
-        self.status.bbfile_priority[fn] = 1
+        self.recipecache.ignored_dependencies = set()
+        self.recipecache.bbfile_priority[fn] = 1
 
         # Remove external dependencies
-        self.status.task_deps[fn]['depends'] = {}
-        self.status.deps[fn] = []
-        self.status.rundeps[fn] = []
-        self.status.runrecs[fn] = []
+        self.recipecache.task_deps[fn]['depends'] = {}
+        self.recipecache.deps[fn] = []
+        self.recipecache.rundeps[fn] = []
+        self.recipecache.runrecs[fn] = []
 
         # Invalidate task for target if force mode active
         if self.configuration.force:
             logger.verbose("Invalidate task %s, %s", task, fn)
-            bb.parse.siggen.invalidate_task('do_%s' % task, self.status, fn)
+            bb.parse.siggen.invalidate_task('do_%s' % task, self.recipecache, fn)
 
         # Setup taskdata structure
         taskdata = bb.taskdata.TaskData(self.configuration.abort)
-        taskdata.add_provider(self.configuration.data, self.status, item)
+        taskdata.add_provider(self.configuration.data, self.recipecache, item)
 
         buildname = self.configuration.data.getVar("BUILDNAME")
         bb.event.fire(bb.event.BuildStarted(buildname, [item]), self.configuration.event_data)
@@ -1207,7 +1007,7 @@ class BBCooker:
         # Execute the runqueue
         runlist = [[item, "do_%s" % task]]
 
-        rq = bb.runqueue.RunQueue(self, self.configuration.data, self.status, taskdata, runlist)
+        rq = bb.runqueue.RunQueue(self, self.configuration.data, self.recipecache, taskdata, runlist)
 
         def buildFileIdle(server, rq, abort):
 
@@ -1233,16 +1033,13 @@ class BBCooker:
                 return True
             return retval
 
-        self.server_registration_cb(buildFileIdle, rq)
+        self.configuration.server_register_idlecallback(buildFileIdle, rq)
 
     def buildTargets(self, targets, task):
         """
         Attempt to build the targets specified
         """
 
-        # Need files parsed
-        self.updateCache()
-
         # If we are told to do the NULL task then query the default task
         if (task == None):
             task = self.configuration.cmd
@@ -1286,15 +1083,15 @@ class BBCooker:
 
         runlist = []
         for k in targets:
-            taskdata.add_provider(localdata, self.status, k)
+            taskdata.add_provider(localdata, self.recipecache, k)
             runlist.append([k, "do_%s" % task])
-        taskdata.add_unresolved(localdata, self.status)
+        taskdata.add_unresolved(localdata, self.recipecache)
 
-        rq = bb.runqueue.RunQueue(self, self.configuration.data, self.status, taskdata, runlist)
+        rq = bb.runqueue.RunQueue(self, self.configuration.data, self.recipecache, taskdata, runlist)
         if universe:
             rq.rqdata.warn_multi_bb = True
 
-        self.server_registration_cb(buildTargetsIdle, rq)
+        self.configuration.server_register_idlecallback(buildTargetsIdle, rq)
 
     def generateNewImage(self, image, base_image, package_queue):
         '''
@@ -1327,12 +1124,14 @@ class BBCooker:
             self.parseConfiguration ()
 
             ignore = self.configuration.data.getVar("ASSUME_PROVIDED", True) or ""
-            self.status.ignored_dependencies = set(ignore.split())
+            self.recipecache.ignored_dependencies = set(ignore.split())
 
             for dep in self.configuration.extra_assume_provided:
-                self.status.ignored_dependencies.add(dep)
+                self.recipecache.ignored_dependencies.add(dep)
+
+            self.collection = CookerCollectFiles(self.recipecache.bbfile_config_priorities)
+            (filelist, masked) = self.collection.collect_bbfiles(self.configuration.data, self.configuration.event_data)
 
-            (filelist, masked) = self.collect_bbfiles()
             self.configuration.data.renameVar("__depends", "__base_depends")
 
             self.parser = CookerParser(self, filelist, masked)
@@ -1343,7 +1142,8 @@ class BBCooker:
             if self.parser.error:
                 sys.exit(1)
             self.show_appends_with_no_recipes()
-            self.buildDepgraph()
+            self.handlePrefProviders()
+            self.recipecache.bbfile_priority = self.collection.collection_priorities(self.recipecache.pkg_fn)
             self.state = state.running
             return None
 
@@ -1357,49 +1157,128 @@ class BBCooker:
         if 'world' in pkgs_to_build:
             self.buildWorldTargetList()
             pkgs_to_build.remove('world')
-            for t in self.status.world_target:
+            for t in self.recipecache.world_target:
                 pkgs_to_build.append(t)
 
         if 'universe' in pkgs_to_build:
             parselog.warn("The \"universe\" target is only intended for testing and may produce errors.")
             parselog.debug(1, "collating packages for \"universe\"")
             pkgs_to_build.remove('universe')
-            for t in self.status.universe_target:
+            for t in self.recipecache.universe_target:
                 pkgs_to_build.append(t)
 
         return pkgs_to_build
 
-    def get_bbfiles( self, path = os.getcwd() ):
+
+
+
+    def pre_serve(self):
+        # Empty the environment. The environment will be populated as
+        # necessary from the data store.
+        #bb.utils.empty_environment()
+        try:
+            prserv.serv.auto_start(self.configuration.data)
+        except prserv.serv.PRServiceConfigError:
+            bb.event.fire(CookerExit(), self.configuration.event_data)
+        return
+
+    def post_serve(self):
+        prserv.serv.auto_shutdown(self.configuration.data)
+        bb.event.fire(CookerExit(), self.configuration.event_data)
+
+    def shutdown(self):
+        self.state = state.shutdown
+
+    def stop(self):
+        self.state = state.stop
+
+    def reparseFiles(self):
+        return
+
+    def initialize(self):
+        self.state = state.initial
+        self.initConfigurationData()
+
+    def reset(self):
+        self.state = state.initial
+        self.initConfigurationData()
+        self.loadConfigurationData()
+
+def server_main(cooker, func, *args):
+    cooker.pre_serve()
+
+    if cooker.configuration.profile:
+        try:
+            import cProfile as profile
+        except:
+            import profile
+        prof = profile.Profile()
+
+        ret = profile.Profile.runcall(prof, func, *args)
+
+        prof.dump_stats("profile.log")
+        bb.utils.process_profilelog("profile.log")
+        print("Raw profiling information saved to profile.log and processed statistics to profile.log.processed")
+
+    else:
+        ret = func(*args)
+
+    cooker.post_serve()
+
+    return ret
+
+class CookerExit(bb.event.Event):
+    """
+    Notify clients of the Cooker shutdown
+    """
+
+    def __init__(self):
+        bb.event.Event.__init__(self)
+
+
+class CookerCollectFiles(object):
+    def __init__(self, priorities):
+        self.appendlist = {}
+        self.bbfile_config_priorities = priorities
+
+    def calc_bbfile_priority( self, filename, matched = None ):
+        for _, _, regex, pri in self.bbfile_config_priorities:
+            if regex.match(filename):
+                if matched != None:
+                    if not regex in matched:
+                        matched.add(regex)
+                return pri
+        return 0
+
+    def get_bbfiles(self):
         """Get list of default .bb files by reading out the current directory"""
+        path = os.getcwd()
         contents = os.listdir(path)
         bbfiles = []
         for f in contents:
-            (root, ext) = os.path.splitext(f)
-            if ext == ".bb":
-                bbfiles.append(os.path.abspath(os.path.join(os.getcwd(), f)))
+            if f.endswith(".bb"):
+                bbfiles.append(os.path.abspath(os.path.join(path, f)))
         return bbfiles
 
-    def find_bbfiles( self, path ):
+    def find_bbfiles(self, path):
         """Find all the .bb and .bbappend files in a directory"""
-        from os.path import join
-
         found = []
         for dir, dirs, files in os.walk(path):
             for ignored in ('SCCS', 'CVS', '.svn'):
                 if ignored in dirs:
                     dirs.remove(ignored)
-            found += [join(dir, f) for f in files if (f.endswith('.bb') or f.endswith('.bbappend'))]
+            found += [os.path.join(dir, f) for f in files if (f.endswith('.bb') or f.endswith('.bbappend'))]
 
         return found
 
-    def collect_bbfiles( self ):
+    def collect_bbfiles(self, config, eventdata):
         """Collect all available .bb build files"""
-        parsed, cached, skipped, masked = 0, 0, 0, 0
+        masked = 0
 
         collectlog.debug(1, "collecting .bb files")
 
-        files = (data.getVar( "BBFILES", self.configuration.data, True) or "").split()
-        data.setVar("BBFILES", " ".join(files), self.configuration.data)
+        files = (config.getVar( "BBFILES", True) or "").split()
+        config.setVar("BBFILES", " ".join(files))
 
         # Sort files by priority
         files.sort( key=lambda fileitem: self.calc_bbfile_priority(fileitem) )
@@ -1409,7 +1288,7 @@ class BBCooker:
 
         if not len(files):
             collectlog.error("no recipe files to build, check your BBPATH and BBFILES?")
-            bb.event.fire(CookerExit(), self.configuration.event_data)
+            bb.event.fire(CookerExit(), eventdata)
 
         # Can't use set here as order is important
         newfiles = []
@@ -1427,7 +1306,7 @@ class BBCooker:
                     if g not in newfiles:
                         newfiles.append(g)
 
-        bbmask = self.configuration.data.getVar('BBMASK', True)
+        bbmask = config.getVar('BBMASK', True)
 
         if bbmask:
             try:
@@ -1475,91 +1354,44 @@ class BBCooker:
     def get_file_appends(self, fn):
         """
         Returns a list of .bbappend files to apply to fn
-        NB: collect_bbfiles() must have been called prior to this
         """
         f = os.path.basename(fn)
         if f in self.appendlist:
             return self.appendlist[f]
         return []
 
-    def pre_serve(self):
-        # Empty the environment. The environment will be populated as
-        # necessary from the data store.
-        #bb.utils.empty_environment()
-        prserv.serv.auto_start(self.configuration.data)
-        return
+    def collection_priorities(self, pkgfns):
 
-    def post_serve(self):
-        prserv.serv.auto_shutdown(self.configuration.data)
-        bb.event.fire(CookerExit(), self.configuration.event_data)
+        priorities = {}
 
-    def shutdown(self):
-        self.state = state.shutdown
+        # Calculate priorities for each file
+        matched = set()
+        for p in pkgfns:
+            realfn, cls = bb.cache.Cache.virtualfn2realfn(p)
+            priorities[p] = self.calc_bbfile_priority(realfn, matched)
+ 
+        # Don't show the warning if the BBFILE_PATTERN did match .bbappend files
+        unmatched = set()
+        for _, _, regex, pri in self.bbfile_config_priorities:        
+            if not regex in matched:
+                unmatched.add(regex)
 
-    def stop(self):
-        self.state = state.stop
+        def findmatch(regex):
+            for bbfile in self.appendlist:
+                for append in self.appendlist[bbfile]:
+                    if regex.match(append):
+                        return True
+            return False
 
-    def reparseFiles(self):
-        return
+        for unmatch in unmatched.copy():
+            if findmatch(unmatch):
+                unmatched.remove(unmatch)
 
-    def initialize(self):
-        self.state = state.initial
-        self.initConfigurationData()
+        for collection, pattern, regex, _ in self.bbfile_config_priorities:
+            if regex in unmatched:
+                collectlog.warn("No bb files matched BBFILE_PATTERN_%s '%s'" % (collection, pattern))
 
-    def reset(self):
-        self.state = state.initial
-        self.loadConfigurationData()
-
-def server_main(cooker, func, *args):
-    cooker.pre_serve()
-
-    if cooker.configuration.profile:
-        try:
-            import cProfile as profile
-        except:
-            import profile
-        prof = profile.Profile()
-
-        ret = profile.Profile.runcall(prof, func, *args)
-
-        prof.dump_stats("profile.log")
-        bb.utils.process_profilelog("profile.log")
-        print("Raw profiling information saved to profile.log and processed statistics to profile.log.processed")
-
-    else:
-        ret = func(*args)
-
-    cooker.post_serve()
-
-    return ret
-
-class CookerExit(bb.event.Event):
-    """
-    Notify clients of the Cooker shutdown
-    """
-
-    def __init__(self):
-        bb.event.Event.__init__(self)
-
-def catch_parse_error(func):
-    """Exception handling bits for our parsing"""
-    @wraps(func)
-    def wrapped(fn, *args):
-        try:
-            return func(fn, *args)
-        except (IOError, bb.parse.ParseError, bb.data_smart.ExpansionError) as exc:
-            parselog.critical("Unable to parse %s: %s" % (fn, exc))
-            sys.exit(1)
-    return wrapped
-
-@catch_parse_error
-def _parse(fn, data, include=True):
-    return bb.parse.handle(fn, data, include)
-
-@catch_parse_error
-def _inherit(bbclass, data):
-    bb.parse.BBHandler.inherit(bbclass, "configuration INHERITs", 0, data)
-    return data
+        return priorities
 
 class ParsingFailure(Exception):
     def __init__(self, realexception, recipe):
@@ -1603,6 +1435,8 @@ class Parser(multiprocessing.Process):
         self.quit = quit
         self.init = init
         multiprocessing.Process.__init__(self)
+        self.context = bb.utils.get_context().copy()
+        self.handlers = bb.event.get_class_handlers().copy()
 
     def run(self):
         if self.init:
@@ -1637,6 +1471,9 @@ class Parser(multiprocessing.Process):
 
     def parse(self, filename, appends, caches_array):
         try:
+            # Reset our environment and handlers to the original settings
+            bb.utils.set_context(self.context.copy())
+            bb.event.set_class_handlers(self.handlers.copy())
             return True, bb.cache.Cache.parse(filename, appends, self.cfg, caches_array)
         except Exception as exc:
             tb = sys.exc_info()[2]
@@ -1674,7 +1511,7 @@ class CookerParser(object):
         self.fromcache = []
         self.willparse = []
         for filename in self.filelist:
-            appends = self.cooker.get_file_appends(filename)
+            appends = self.cooker.collection.get_file_appends(filename)
             if not self.bb_cache.cacheValid(filename, appends):
                 self.willparse.append((filename, appends, cooker.caches_array))
             else:
@@ -1831,13 +1668,13 @@ class CookerParser(object):
             if info_array[0].skipped:
                 self.skipped += 1
                 self.cooker.skiplist[virtualfn] = SkippedPackage(info_array[0])
-            self.bb_cache.add_info(virtualfn, info_array, self.cooker.status,
+            self.bb_cache.add_info(virtualfn, info_array, self.cooker.recipecache,
                                         parsed=parsed)
         return True
 
     def reparse(self, filename):
         infos = self.bb_cache.parse(filename,
-                                    self.cooker.get_file_appends(filename),
+                                    self.cooker.collection.get_file_appends(filename),
                                     self.cfgdata, self.cooker.caches_array)
         for vfn, info_array in infos:
-            self.cooker.status.add_from_recipeinfo(vfn, info_array)
+            self.cooker.recipecache.add_from_recipeinfo(vfn, info_array)

bitbake/lib/bb/cookerdata.py

@@ -0,0 +1,272 @@
+#!/usr/bin/env python
+# ex:ts=4:sw=4:sts=4:et
+# -*- tab-width: 4; c-basic-offset: 4; indent-tabs-mode: nil -*-
+#
+# Copyright (C) 2003, 2004  Chris Larson
+# Copyright (C) 2003, 2004  Phil Blundell
+# Copyright (C) 2003 - 2005 Michael 'Mickey' Lauer
+# Copyright (C) 2005        Holger Hans Peter Freyther
+# Copyright (C) 2005        ROAD GmbH
+# Copyright (C) 2006        Richard Purdie
+#
+# 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, sys
+from functools import wraps
+import logging
+from bb import data
+
+logger      = logging.getLogger("BitBake")
+parselog    = logging.getLogger("BitBake.Parsing")
+
+class ConfigParameters(object):
+    def __init__(self):
+        self.options, targets = self.parseCommandLine()
+        self.environment = self.parseEnvironment()
+
+        self.options.pkgs_to_build = targets or []
+
+        self.options.tracking = False
+        if hasattr(self.options, "show_environment") and self.options.show_environment:
+            self.options.tracking = True
+
+        for key, val in self.options.__dict__.items():
+            setattr(self, key, val)
+
+    def parseCommandLine(self):
+        raise Exception("Caller must implement commandline option parsing")
+
+    def parseEnvironment(self):
+        return os.environ.copy()
+
+    def updateFromServer(self, server):
+        if not self.options.cmd:
+            defaulttask, error = server.runCommand(["getVariable", "BB_DEFAULT_TASK"])
+            if error:
+                raise Exception("Unable to get the value of BB_DEFAULT_TASK from the server: %s" % error)
+            self.options.cmd = defaulttask or "build"
+        _, error = server.runCommand(["setConfig", "cmd", self.options.cmd])
+        if error:
+            raise Exception("Unable to set configuration option 'cmd' on the server: %s" % error)
+
+        if not self.options.pkgs_to_build:
+            bbpkgs, error = server.runCommand(["getVariable", "BBPKGS"])
+            if error:
+                raise Exception("Unable to get the value of BBPKGS from the server: %s" % error)
+            if bbpkgs:
+                self.options.pkgs_to_build.extend(bbpkgs.split())
+
+    def parseActions(self):
+        # Parse any commandline into actions
+        action = {'action':None, 'msg':None}
+        if self.options.show_environment:
+            if 'world' in self.options.pkgs_to_build:
+                action['msg'] = "'world' is not a valid target for --environment."
+            elif 'universe' in self.options.pkgs_to_build:
+                action['msg'] = "'universe' is not a valid target for --environment."
+            elif len(self.options.pkgs_to_build) > 1:
+                action['msg'] = "Only one target can be used with the --environment option."
+            elif self.options.buildfile and len(self.options.pkgs_to_build) > 0:
+                action['msg'] = "No target should be used with the --environment and --buildfile options."
+            elif len(self.options.pkgs_to_build) > 0:
+                action['action'] = ["showEnvironmentTarget", self.options.pkgs_to_build]
+            else:
+                action['action'] = ["showEnvironment", self.options.buildfile]
+        elif self.options.buildfile is not None:
+            action['action'] = ["buildFile", self.options.buildfile, self.options.cmd]
+        elif self.options.revisions_changed:
+            action['action'] = ["compareRevisions"]
+        elif self.options.show_versions:
+            action['action'] = ["showVersions"]
+        elif self.options.parse_only:
+            action['action'] = ["parseFiles"]
+        elif self.options.dot_graph:
+            if self.options.pkgs_to_build:
+                action['action'] = ["generateDotGraph", self.options.pkgs_to_build, self.options.cmd]
+            else:
+                action['msg'] = "Please specify a package name for dependency graph generation."
+        else:
+            if self.options.pkgs_to_build:
+                action['action'] = ["buildTargets", self.options.pkgs_to_build, self.options.cmd]
+            else:
+                #action['msg'] = "Nothing to do.  Use 'bitbake world' to build everything, or run 'bitbake --help' for usage information."
+                action = None
+        self.options.initialaction = action
+        return action
+
+class CookerConfiguration(object):
+    """
+    Manages build options and configurations for one run
+    """
+
+    def __init__(self):
+        self.debug_domains = []
+        self.extra_assume_provided = []
+        self.prefile = []
+        self.postfile = []
+        self.debug = 0
+        self.cmd = None
+        self.abort = True
+        self.force = False
+        self.profile = False
+        self.nosetscene = False
+        self.invalidate_stamp = False
+        self.dump_signatures = False
+        self.dry_run = False
+        self.tracking = False
+        self.extra_caches = []
+
+        self.env = {}
+
+    def setConfigParameters(self, parameters):
+        for key in self.__dict__.keys():
+            if key in parameters.options.__dict__:
+                setattr(self, key, parameters.options.__dict__[key])
+        self.env = parameters.environment.copy()
+        self.tracking = parameters.tracking
+
+    def setServerRegIdleCallback(self, srcb):
+        self.server_register_idlecallback = srcb
+
+def catch_parse_error(func):
+    """Exception handling bits for our parsing"""
+    @wraps(func)
+    def wrapped(fn, *args):
+        try:
+            return func(fn, *args)
+        except (IOError, bb.parse.ParseError, bb.data_smart.ExpansionError) as exc:
+            parselog.critical("Unable to parse %s: %s" % (fn, exc))
+            sys.exit(1)
+    return wrapped
+
+@catch_parse_error
+def parse_config_file(fn, data, include=True):
+    return bb.parse.handle(fn, data, include)
+
+@catch_parse_error
+def _inherit(bbclass, data):
+    bb.parse.BBHandler.inherit(bbclass, "configuration INHERITs", 0, data)
+    return data
+
+def findConfigFile(configfile):
+    path = os.getcwd()
+    while path != "/":
+        confpath = os.path.join(path, "conf", configfile)
+        if os.path.exists(confpath):
+            return confpath
+
+        path, _ = os.path.split(path)
+    return None
+
+class CookerDataBuilder(object):
+
+    def __init__(self, cookercfg, worker = False):
+
+        self.prefiles = cookercfg.prefile
+        self.postfiles = cookercfg.postfile
+        self.tracking = cookercfg.tracking
+
+        bb.utils.set_context(bb.utils.clean_context())
+        bb.event.set_class_handlers(bb.event.clean_class_handlers())
+        self.data = bb.data.init()
+        if self.tracking:
+            self.data.enableTracking()
+
+        # Keep a datastore of the initial environment variables and their
+        # values from when BitBake was launched to enable child processes
+        # to use environment variables which have been cleaned from the
+        # BitBake processes env
+        self.savedenv = bb.data.init()
+        for k in cookercfg.env:
+            self.savedenv.setVar(k, cookercfg.env[k])
+
+        filtered_keys = bb.utils.approved_variables()
+        bb.data.inheritFromOS(self.data, self.savedenv, filtered_keys)
+        self.data.setVar("BB_ORIGENV", self.savedenv)
+        
+        if worker:
+            self.data.setVar("BB_WORKERCONTEXT", "1")
+
+    def parseBaseConfiguration(self):
+        try:
+            self.parseConfigurationFiles(self.prefiles, self.postfiles)
+        except SyntaxError:
+            sys.exit(1)
+        except Exception:
+            logger.exception("Error parsing configuration files")
+            sys.exit(1)
+
+    def _findLayerConf(self):
+        return findConfigFile("bblayers.conf")
+
+    def parseConfigurationFiles(self, prefiles, postfiles):
+        data = self.data
+        bb.parse.init_parser(data)
+
+        # Parse files for loading *before* bitbake.conf and any includes
+        for f in prefiles:
+            data = parse_config_file(f, data)
+
+        layerconf = self._findLayerConf()
+        if layerconf:
+            parselog.debug(2, "Found bblayers.conf (%s)", layerconf)
+            data = parse_config_file(layerconf, data)
+
+            layers = (data.getVar('BBLAYERS', True) or "").split()
+
+            data = bb.data.createCopy(data)
+            for layer in layers:
+                parselog.debug(2, "Adding layer %s", layer)
+                data.setVar('LAYERDIR', layer)
+                data = parse_config_file(os.path.join(layer, "conf", "layer.conf"), data)
+                data.expandVarref('LAYERDIR')
+
+            data.delVar('LAYERDIR')
+
+        if not data.getVar("BBPATH", True):
+            raise SystemExit("The BBPATH variable is not set")
+
+        data = parse_config_file(os.path.join("conf", "bitbake.conf"), data)
+
+        # Parse files for loading *after* bitbake.conf and any includes
+        for p in postfiles:
+            data = parse_config_file(p, data)
+
+        # Handle any INHERITs and inherit the base class
+        bbclasses  = ["base"] + (data.getVar('INHERIT', True) or "").split()
+        for bbclass in bbclasses:
+            data = _inherit(bbclass, data)
+
+        # Nomally we only register event handlers at the end of parsing .bb files
+        # We register any handlers we've found so far here...
+        for var in data.getVar('__BBHANDLERS') or []:
+            bb.event.register(var, data.getVar(var))
+
+        if data.getVar("BB_WORKERCONTEXT", False) is None:
+            bb.fetch.fetcher_init(data)
+        bb.codeparser.parser_cache_init(data)
+        bb.event.fire(bb.event.ConfigParsed(), data)
+
+        if data.getVar("BB_INVALIDCONF") is True:
+            data.setVar("BB_INVALIDCONF", False)
+            self.parseConfigurationFiles(self.prefiles, self.postfiles)
+            return
+
+        bb.parse.init_parser(data)
+        data.setVar('BBINCLUDED',bb.parse.get_file_depends(data))
+        self.data = data
+        self.data_hash = data.get_hash()
+
+
+

bitbake/lib/bb/data.py

@@ -158,9 +158,9 @@ def expandKeys(alterdata, readdata = None):
 
     for key in todolist:
         ekey = todolist[key]
-        if ekey in keys(alterdata):
+        newval = alterdata.getVar(ekey, 0)
+        if newval:
             val = alterdata.getVar(key, 0)
-            newval = alterdata.getVar(ekey, 0)
             if val is not None and newval is not None:
                 bb.warn("Variable key %s (%s) replaces original key %s (%s)." % (key, val, ekey, newval))
         alterdata.renameVar(key, ekey)
@@ -274,6 +274,7 @@ def emit_func(func, o=sys.__stdout__, d = init()):
             if d.getVarFlag(dep, "func"):
                emit_var(dep, o, d, False) and o.write('\n')
                newdeps |=  bb.codeparser.ShellParser(dep, logger).parse_shell(d.getVar(dep, True))
+               newdeps |= set((d.getVarFlag(dep, "vardeps", True) or "").split())
         newdeps -= seen
 
 def update_data(d):

bitbake/lib/bb/data_smart.py

@@ -738,5 +738,15 @@ class DataSmart(MutableMapping):
             value = d.getVar(key, False) or ""
             data.update({key:value})
 
+        for key in ["__BBTASKS", "__BBANONFUNCS", "__BBHANDLERS"]:
+            bb_list = d.getVar(key, False) or []
+            bb_list.sort()
+            data.update({key:str(bb_list)})
+
+            if key == "__BBANONFUNCS":
+                for i in bb_list:
+                    value = d.getVar(i, True) or ""
+                    data.update({i:value})
+
         data_str = str([(k, data[k]) for k in sorted(data.keys())])
         return hashlib.md5(data_str).hexdigest()

bitbake/lib/bb/event.py

@@ -47,21 +47,23 @@ class Event(object):
     def __init__(self):
         self.pid = worker_pid
 
-NotHandled = 0
-Handled    = 1
-
 Registered        = 10
 AlreadyRegistered = 14
 
+def get_class_handlers():
+    return _handlers
+
+def set_class_handlers(h):
+    _handlers = h
+
+def clean_class_handlers():
+    return bb.compat.OrderedDict()
+
 # Internal
-_handlers = bb.compat.OrderedDict()
+_handlers = clean_class_handlers()
 _ui_handlers = {}
 _ui_handler_seq = 0
 
-# For compatibility
-bb.utils._context["NotHandled"] = NotHandled
-bb.utils._context["Handled"] = Handled
-
 def execute_handler(name, handler, event, d):
     event.data = d
     try:
@@ -80,10 +82,6 @@ def execute_handler(name, handler, event, d):
     finally:
         del event.data
 
-    if ret is not None:
-        warnings.warn("Using Handled/NotHandled in event handlers is deprecated",
-                        DeprecationWarning, stacklevel = 2)
-
 def fire_class_handlers(event, d):
     if isinstance(event, logging.LogRecord):
         return

bitbake/lib/bb/fetch2/__init__.py

@@ -28,6 +28,8 @@ BitBake build tools.
 from __future__ import absolute_import
 from __future__ import print_function
 import os, re
+import signal
+import glob
 import logging
 import urllib
 import urlparse
@@ -38,6 +40,8 @@ import operator
 import bb.persist_data, bb.utils
 import bb.checksum
 from bb import data
+import bb.process
+import subprocess
 
 __version__ = "2"
 _checksum_cache = bb.checksum.FileChecksumCache()
@@ -74,6 +78,9 @@ class FetchError(BBFetchException):
 
 class ChecksumError(FetchError):
     """Exception when mismatched checksum encountered"""
+    def __init__(self, message, url = None, checksum = None):
+        self.checksum = checksum
+        FetchError.__init__(self, message, url)
 
 class NoChecksumError(FetchError):
     """Exception when no checksum is specified, but BB_STRICT_CHECKSUM is set"""
@@ -561,7 +568,7 @@ def verify_checksum(u, ud, d):
         msg = msg + '\nIf this change is expected (e.g. you have upgraded to a new version without updating the checksums) then you can use these lines within the recipe:\nSRC_URI[%s] = "%s"\nSRC_URI[%s] = "%s"\nOtherwise you should retry the download and/or check with upstream to determine if the file has become corrupted or otherwise unexpectedly modified.\n' % (ud.md5_name, md5data, ud.sha256_name, sha256data)
 
     if len(msg):
-        raise ChecksumError('Checksum mismatch!%s' % msg, u)
+        raise ChecksumError('Checksum mismatch!%s' % msg, u, md5data)
 
 
 def update_stamp(u, ud, d):
@@ -581,7 +588,6 @@ def update_stamp(u, ud, d):
         open(ud.donestamp, 'w').close()
 
 def subprocess_setup():
-    import signal
     # Python installs a SIGPIPE handler by default. This is usually not what
     # non-Python subprocesses expect.
     # SIGPIPE errors are known issues with gzip/bash
@@ -613,7 +619,12 @@ def get_srcrev(d):
         raise FetchError("SRCREV was used yet no valid SCM was found in SRC_URI")
 
     if len(scms) == 1 and len(urldata[scms[0]].names) == 1:
-        return urldata[scms[0]].method.sortable_revision(scms[0], urldata[scms[0]], d, urldata[scms[0]].names[0])
+        autoinc, rev = urldata[scms[0]].method.sortable_revision(scms[0], urldata[scms[0]], d, urldata[scms[0]].names[0])
+        if len(rev) > 10:
+            rev = rev[:10]
+        if autoinc:
+            return "AUTOINC+" + rev
+        return rev
 
     #
     # Mutiple SCMs are in SRC_URI so we resort to SRCREV_FORMAT
@@ -622,18 +633,16 @@ def get_srcrev(d):
     if not format:
         raise FetchError("The SRCREV_FORMAT variable must be set when multiple SCMs are used.")
 
-    autoinc = False
-    autoinc_templ = 'AUTOINC+'
+    seenautoinc = False
     for scm in scms:
         ud = urldata[scm]
         for name in ud.names:
-            rev = ud.method.sortable_revision(scm, ud, d, name)
-            if rev.startswith(autoinc_templ):
-                if not autoinc:
-                    autoinc = True
-                    format = "%s%s" % (autoinc_templ, format)
-                rev = rev[len(autoinc_templ):]
-
+            autoinc, rev = ud.method.sortable_revision(scm, ud, d, name)
+            if len(rev) > 10:
+                rev = rev[:10]
+            if autoinc and not seenautoinc:
+                rev = "AUTOINC+" + rev
+                seenautoinc = True
             format = format.replace(name, rev)
 
     return format
@@ -650,9 +659,6 @@ def runfetchcmd(cmd, d, quiet = False, cleanup = []):
     Optionally remove the files/directories listed in cleanup upon failure
     """
 
-    import bb.process
-    import subprocess
-
     # Need to export PATH as binary could be in metadata paths
     # rather than host provided
     # Also include some other variables.
@@ -753,6 +759,19 @@ def build_mirroruris(origud, mirrors, ld):
 
     return uris, uds
 
+def rename_bad_checksum(ud, suffix):
+    """
+    Renames files to have suffix from parameter
+    """
+
+    if ud.localpath is None:
+        return
+
+    new_localpath = "%s_bad-checksum_%s" % (ud.localpath, suffix)
+    bb.warn("Renaming %s to %s" % (ud.localpath, new_localpath))
+    bb.utils.movefile(ud.localpath, new_localpath)
+
+
 def try_mirror_url(newuri, origud, ud, ld, check = False):
     # Return of None or a value means we're finished
     # False means try another url
@@ -804,6 +823,7 @@ def try_mirror_url(newuri, origud, ud, ld, check = False):
         if isinstance(e, ChecksumError):
             logger.warn("Mirror checksum failure for url %s (original url: %s)\nCleaning and trying again." % (newuri, origud.url))
             logger.warn(str(e))
+            rename_bad_checksum(ud, e.checksum)
         elif isinstance(e, NoChecksumError):
             raise
         else:
@@ -909,7 +929,6 @@ def get_file_checksums(filelist, pn):
         try:
             checksum = _checksum_cache.get_checksum(f)
         except OSError as e:
-            import traceback
             bb.warn("Unable to get checksum for %s SRC_URI entry %s: %s" % (pn, os.path.basename(f), e))
             return None
         return checksum
@@ -919,7 +938,6 @@ def get_file_checksums(filelist, pn):
         checksum = None
         if '*' in pth:
             # Handle globs
-            import glob
             for f in glob.glob(pth):
                 checksum = checksum_file(f)
                 if checksum:
@@ -1129,7 +1147,6 @@ class FetchMethod(object):
         raise NoMethodError(url)
 
     def unpack(self, urldata, rootdir, data):
-        import subprocess
         iterate = False
         file = urldata.localpath
 
@@ -1276,14 +1293,8 @@ class FetchMethod(object):
             return rev
 
     def sortable_revision(self, url, ud, d, name):
-        """
-
-        """
-        if hasattr(self, "_sortable_revision"):
-            return self._sortable_revision(url, ud, d)
-
         latest_rev = self._build_revision(url, ud, d, name)
-        return 'AUTOINC+%s' % str(latest_rev)
+        return True, str(latest_rev)
 
     def generate_revision_key(self, url, ud, d, name):
         key = self._revision_key(url, ud, d, name)
@@ -1388,6 +1399,7 @@ class Fetch(object):
                         if isinstance(e, ChecksumError):
                             logger.warn("Checksum failure encountered with download of %s - will attempt other sources if available" % u)
                             logger.debug(1, str(e))
+                            rename_bad_checksum(ud, e.checksum)
                         elif isinstance(e, NoChecksumError):
                             raise
                         else:

bitbake/lib/bb/fetch2/bzr.py

@@ -132,12 +132,12 @@ class Bzr(FetchMethod):
 
         return output.strip()
 
-    def _sortable_revision(self, url, ud, d):
+    def sortable_revision(self, url, ud, d, name):
         """
         Return a sortable revision number which in our case is the revision number
         """
 
-        return self._build_revision(url, ud, d)
+        return False, self._build_revision(url, ud, d)
 
     def _build_revision(self, url, ud, d):
         return ud.revision

bitbake/lib/bb/fetch2/git.py

@@ -217,6 +217,10 @@ class Git(FetchMethod):
     def build_mirror_data(self, url, ud, d):
         # Generate a mirror tarball if needed
         if ud.write_tarballs and (ud.repochanged or not os.path.exists(ud.fullmirror)):
+            # it's possible that this symlink points to read-only filesystem with PREMIRROR
+            if os.path.islink(ud.fullmirror):
+                os.unlink(ud.fullmirror)
+
             os.chdir(ud.clonedir)
             logger.info("Creating tarball of git repository")
             runfetchcmd("tar -czf %s %s" % (ud.fullmirror, os.path.join(".") ), d)

bitbake/lib/bb/fetch2/svn.py

@@ -81,6 +81,8 @@ class Svn(FetchMethod):
 
         options = []
 
+        options.append("--no-auth-cache")
+
         if ud.user:
             options.append("--username %s" % ud.user)
 
@@ -176,12 +178,12 @@ class Svn(FetchMethod):
 
         return revision
 
-    def _sortable_revision(self, url, ud, d):
+    def sortable_revision(self, url, ud, d, name):
         """
         Return a sortable revision number which in our case is the revision number
         """
 
-        return self._build_revision(url, ud, d)
+        return False, self._build_revision(url, ud, d)
 
     def _build_revision(self, url, ud, d):
         return ud.revision

bitbake/lib/bb/methodpool.py

@@ -17,24 +17,7 @@
 # with this program; if not, write to the Free Software Foundation, Inc.,
 # 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
 
-
-"""
-    What is a method pool?
-
-    BitBake has a global method scope where .bb, .inc and .bbclass
-    files can install methods. These methods are parsed from strings.
-    To avoid recompiling and executing these string we introduce
-    a method pool to do this task.
-
-    This pool will be used to compile and execute the functions. It
-    will be smart enough to
-"""
-
 from bb.utils import better_compile, better_exec
-from bb       import error
-
-# A dict of function names we have seen
-_parsed_fns     = { }
 
 def insert_method(modulename, code, fn):
     """
@@ -44,28 +27,3 @@ def insert_method(modulename, code, fn):
     comp = better_compile(code, modulename, fn )
     better_exec(comp, None, code, fn)
 
-    # now some instrumentation
-    code = comp.co_names
-    for name in code:
-        if name in ['None', 'False']:
-            continue
-        elif name in _parsed_fns and not _parsed_fns[name] == modulename:
-            error("The function %s defined in %s was already declared in %s. BitBake has a global python function namespace so shared functions should be declared in a common include file rather than being duplicated, or if the functions are different, please use different function names." % (name, modulename, _parsed_fns[name]))
-        else:
-            _parsed_fns[name] = modulename
-
-# A dict of modules the parser has finished with
-_parsed_methods = {}
-
-def parsed_module(modulename):
-    """
-    Has module been parsed?
-    """
-    return modulename in _parsed_methods
-
-def set_parsed_module(modulename):
-    """
-    Set module as parsed
-    """
-    _parsed_methods[modulename] = True
-

bitbake/lib/bb/monitordisk.py

@@ -244,7 +244,7 @@ class diskMonitor:
                     # checking for such a fs.
                     if st.f_files == 0:
                         logger.warn("Inode check for %s is unavaliable, will remove it from disk monitor" % path)
-                        minInode = None
+                        self.devDict[k][2] = None
                         continue
                     # Always show warning, the self.checked would always be False if the action is WARN
                     if self.preFreeI[k] == 0 or self.preFreeI[k] - freeInode > self.inodeInterval and not self.checked[k]:

bitbake/lib/bb/parse/ast.py

@@ -148,9 +148,8 @@ class MethodNode(AstNode):
         text = '\n'.join(self.body)
         if self.func_name == "__anonymous":
             funcname = ("__anon_%s_%s" % (self.lineno, self.filename.translate(string.maketrans('/.+-', '____'))))
-            if not funcname in bb.methodpool._parsed_fns:
-                text = "def %s(d):\n" % (funcname) + text
-                bb.methodpool.insert_method(funcname, text, self.filename)
+            text = "def %s(d):\n" % (funcname) + text
+            bb.methodpool.insert_method(funcname, text, self.filename)
             anonfuncs = data.getVar('__BBANONFUNCS') or []
             anonfuncs.append(funcname)
             data.setVar('__BBANONFUNCS', anonfuncs)
@@ -171,8 +170,7 @@ class PythonMethodNode(AstNode):
         # 'this' file. This means we will not parse methods from
         # bb classes twice
         text = '\n'.join(self.body)
-        if not bb.methodpool.parsed_module(self.modulename):
-            bb.methodpool.insert_method(self.modulename, text, self.filename)
+        bb.methodpool.insert_method(self.modulename, text, self.filename)
         data.setVarFlag(self.function, "func", 1)
         data.setVarFlag(self.function, "python", 1)
         data.setVar(self.function, text)

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

@@ -104,6 +104,7 @@ def get_statements(filename, absolute_filename, base_name):
             if not s: break
             s = s.rstrip()
             feeder(lineno, s, filename, base_name, statements)
+        file.close()
         if __inpython__:
             # add a blank line to close out any python definition
             feeder(IN_PYTHON_EOF, "", filename, base_name, statements)
@@ -166,10 +167,6 @@ def handle(fn, d, include):
     if oldfile:
         d.setVar("FILE", oldfile)
 
-    # we have parsed the bb class now
-    if ext == ".bbclass" or ext == ".inc":
-        bb.methodpool.set_parsed_module(base_name)
-
     return d
 
 def feeder(lineno, s, fn, root, statements):

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

@@ -145,6 +145,8 @@ def handle(fn, data, include):
     if oldfile:
         data.setVar('FILE', oldfile)
 
+    f.close()
+
     for f in confFilters:
         f(fn, data)
 

bitbake/lib/bb/process.py

@@ -85,7 +85,7 @@ def _logged_communicate(pipe, log, input):
             rlist = rin
             try:
                 r,w,e = select.select (rlist, [], [])
-            except OSError, e:
+            except OSError as e:
                 if e.errno != errno.EINTR:
                     raise
 
@@ -102,6 +102,10 @@ def _logged_communicate(pipe, log, input):
                     log.write(data)
     finally:    
         log.flush()
+    if pipe.stdout is not None:
+        pipe.stdout.close()
+    if pipe.stderr is not None:
+        pipe.stderr.close()
     return ''.join(outdata), ''.join(errdata)
 
 def run(cmd, input=None, log=None, **options):

bitbake/lib/bb/providers.py

@@ -92,9 +92,9 @@ def sortPriorities(pn, dataCache, pkg_pn = None):
             priorities[priority][preference] = []
         priorities[priority][preference].append(f)
     tmp_pn = []
-    for pri in sorted(priorities, lambda a, b: a - b):
+    for pri in sorted(priorities):
         tmp_pref = []
-        for pref in sorted(priorities[pri], lambda a, b: b - a):
+        for pref in sorted(priorities[pri]):
             tmp_pref.extend(priorities[pri][pref])
         tmp_pn = [tmp_pref] + tmp_pn
 

bitbake/lib/bb/pysh/pyshlex.py

@@ -292,7 +292,7 @@ class WordLexer:
         elif sep=='${':
             parsefunc = self._parse_parameter
         else:
-            raise NotImplementedError()
+            raise NotImplementedError(sep)
             
         pos, closed = parsefunc(buf, result, eof)
         return pos, closed

bitbake/lib/bb/runqueue.py

@@ -957,7 +957,7 @@ class RunQueue:
         for task in range(len(self.rqdata.runq_fnid)):
             if self.rqdata.runq_fnid[task] not in done:
                 fn = self.rqdata.taskData.fn_index[self.rqdata.runq_fnid[task]]
-                the_data = bb.cache.Cache.loadDataFull(fn, self.cooker.get_file_appends(fn), self.cooker.configuration.data)
+                the_data = bb.cache.Cache.loadDataFull(fn, self.cooker.collection.get_file_appends(fn), self.cooker.configuration.data)
                 done.add(self.rqdata.runq_fnid[task])
 
         bb.parse.siggen.dump_sigs(self.rqdata.dataCache)
@@ -1123,7 +1123,7 @@ class RunQueueExecute:
             bb.parse.siggen.set_taskdata(self.rqdata.hashes, self.rqdata.hash_deps)
             ret = 0
             try:
-                the_data = bb.cache.Cache.loadDataFull(fn, self.cooker.get_file_appends(fn), self.cooker.configuration.data)
+                the_data = bb.cache.Cache.loadDataFull(fn, self.cooker.collection.get_file_appends(fn), self.cooker.configuration.data)
                 the_data.setVar('BB_TASKHASH', self.rqdata.runq_hash[task])
                 for h in self.rqdata.hashes:
                     the_data.setVar("BBHASH_%s" % h, self.rqdata.hashes[h])
@@ -1139,6 +1139,7 @@ class RunQueueExecute:
                 for e in fakeenv:
                     os.environ[e] = fakeenv[e]
                     the_data.setVar(e, fakeenv[e])
+                    the_data.setVarFlag(e, 'export', "1")
 
                 if quieterrors:
                     the_data.setVarFlag(taskname, "quieterrors", "1")

bitbake/lib/bb/server/none.py

@@ -1,203 +0,0 @@
-#
-# BitBake 'dummy' Passthrough Server
-#
-# Copyright (C) 2006 - 2007  Michael 'Mickey' Lauer
-# Copyright (C) 2006 - 2008  Richard Purdie
-#
-# 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.
-
-"""
-    This module implements a passthrough server for BitBake.
-
-    Use register_idle_function() to add a function which the server
-    calls from within idle_commands when no requests are pending. Make sure
-    that those functions are non-blocking or else you will introduce latency
-    in the server's main loop.
-"""
-
-import time
-import bb
-import signal
-
-DEBUG = False
-
-import inspect, select
-
-class BitBakeServerCommands():
-    def __init__(self, server):
-        self.server = server
-
-    def runCommand(self, command):
-        """
-        Run a cooker command on the server
-        """
-        #print "Running Command %s" % command
-        return self.cooker.command.runCommand(command)
-
-    def terminateServer(self):
-        """
-        Trigger the server to quit
-        """
-        self.server.server_exit()
-        #print "Server (cooker) exitting"
-        return
-
-    def ping(self):
-        """
-        Dummy method which can be used to check the server is still alive
-        """
-        return True
-
-eventQueue = []
-
-class BBUIEventQueue:
-    class event:
-        def __init__(self, parent):
-            self.parent = parent
-        @staticmethod
-        def send(event):
-            bb.server.none.eventQueue.append(event)
-        @staticmethod
-        def quit():
-            return
-
-    def __init__(self, BBServer):
-        self.eventQueue = bb.server.none.eventQueue
-        self.BBServer = BBServer
-        self.EventHandle = bb.event.register_UIHhandler(self)
-
-    def __popEvent(self):
-        if len(self.eventQueue) == 0:
-            return None
-        return self.eventQueue.pop(0)
-
-    def getEvent(self):
-        if len(self.eventQueue) == 0:
-          self.BBServer.idle_commands(0)
-        return self.__popEvent()
-
-    def waitEvent(self, delay):
-        event = self.__popEvent()
-        if event:
-            return event
-        self.BBServer.idle_commands(delay)
-        return self.__popEvent()
-
-    def queue_event(self, event):
-        self.eventQueue.append(event)
-
-    def system_quit( self ):
-        bb.event.unregister_UIHhandler(self.EventHandle)
-
-# Dummy signal handler to ensure we break out of sleep upon SIGCHLD
-def chldhandler(signum, stackframe):
-    pass
-
-class BitBakeNoneServer():
-    # remove this when you're done with debugging
-    # allow_reuse_address = True
-
-    def __init__(self):
-        self._idlefuns = {}
-        self.commands = BitBakeServerCommands(self)
-
-    def addcooker(self, cooker):
-        self.cooker = cooker
-        self.commands.cooker = cooker
-
-    def register_idle_function(self, function, data):
-        """Register a function to be called while the server is idle"""
-        assert hasattr(function, '__call__')
-        self._idlefuns[function] = data
-
-    def idle_commands(self, delay):
-        #print "Idle queue length %s" % len(self._idlefuns)
-        #print "Idle timeout, running idle functions"
-        #if len(self._idlefuns) == 0:
-        nextsleep = delay
-        for function, data in self._idlefuns.items():
-            try:
-                retval = function(self, data, False)
-                #print "Idle function returned %s" % (retval)
-                if retval is False:
-                    del self._idlefuns[function]
-                elif retval is True:
-                    nextsleep = None
-                elif nextsleep is None:
-                    continue
-                elif retval < nextsleep:
-                    nextsleep = retval
-            except SystemExit:
-                raise
-            except:
-                import traceback
-                traceback.print_exc()
-                self.commands.runCommand(["stateShutdown"])
-                pass
-        if nextsleep is not None:
-            #print "Sleeping for %s (%s)" % (nextsleep, delay)
-            signal.signal(signal.SIGCHLD, chldhandler)
-            time.sleep(nextsleep)
-            signal.signal(signal.SIGCHLD, signal.SIG_DFL)
-
-    def server_exit(self):
-        # Tell idle functions we're exiting
-        for function, data in self._idlefuns.items():
-            try:
-                retval = function(self, data, True)
-            except:
-                pass
-
-class BitBakeServerConnection():
-    def __init__(self, server):
-        self.server = server.server
-        self.connection = self.server.commands
-        self.events = bb.server.none.BBUIEventQueue(self.server)
-        for event in bb.event.ui_queue:
-            self.events.queue_event(event)
-
-    def terminate(self):
-        try:
-            self.events.system_quit()
-        except:
-            pass
-        try:
-            self.connection.terminateServer()
-        except:
-            pass
-
-class BitBakeServer(object):
-    def initServer(self):
-        self.server = BitBakeNoneServer()
-
-    def addcooker(self, cooker):
-        self.cooker = cooker
-        self.server.addcooker(cooker)
-
-    def getServerIdleCB(self):
-        return self.server.register_idle_function
-
-    def saveConnectionDetails(self):
-        return
-
-    def detach(self):
-        return
-
-    def establishConnection(self):
-        self.connection = BitBakeServerConnection(self)
-        return self.connection
-
-    def launchUI(self, uifunc, *args):
-        return bb.cooker.server_main(self.cooker, uifunc, *args)
-

bitbake/lib/bb/server/process.py

@@ -264,7 +264,3 @@ class BitBakeServer(object):
         self.connection = BitBakeServerConnection(self)
         signal.signal(signal.SIGTERM, lambda i, s: self.connection.terminate(force=True))
         return self.connection
-
-    def launchUI(self, uifunc, *args):
-        return uifunc(*args)
-

bitbake/lib/bb/server/xmlrpc.py

@@ -35,6 +35,14 @@ import bb
 import xmlrpclib, sys
 from bb import daemonize
 from bb.ui import uievent
+import hashlib, time
+import socket
+import os, signal
+import threading
+try:
+    import cPickle as pickle
+except ImportError:
+    import pickle
 
 DEBUG = False
 
@@ -54,82 +62,104 @@ if sys.hexversion < 0x020600F0:
 # Upstream Python bug is #8194 (http://bugs.python.org/issue8194)
 # This bug is relevant for Python 2.7.0 and 2.7.1 but was fixed for
 # Python > 2.7.2
+#
+# To implement a simple form of client control, we use a special transport
+# that adds a HTTP header field ("Bitbake-token") to ensure that a server
+# can communicate with only a client at a given time (the client must use
+# the same token).
 ##
+if (2, 7, 0) <= sys.version_info < (2, 7, 2):
+    class BBTransport(xmlrpclib.Transport):
+        def __init__(self):
+            self.connection_token = None
+            xmlrpclib.Transport.__init__(self)
 
-class BBTransport(xmlrpclib.Transport):
-    def request(self, host, handler, request_body, verbose=0):
-        h = self.make_connection(host)
-        if verbose:
-            h.set_debuglevel(1)
+        def request(self, host, handler, request_body, verbose=0):
+            h = self.make_connection(host)
+            if verbose:
+                h.set_debuglevel(1)
 
-        self.send_request(h, handler, request_body)
-        self.send_host(h, host)
-        self.send_user_agent(h)
-        self.send_content(h, request_body)
+            self.send_request(h, handler, request_body)
+            self.send_host(h, host)
+            self.send_user_agent(h)
+            if self.connection_token:
+                h.putheader("Bitbake-token", self.connection_token)
+            self.send_content(h, request_body)
 
-        errcode, errmsg, headers = h.getreply()
+            errcode, errmsg, headers = h.getreply()
 
-        if errcode != 200:
-            raise ProtocolError(
-                host + handler,
-                errcode, errmsg,
-                headers
-                )
+            if errcode != 200:
+                raise ProtocolError(
+                    host + handler,
+                    errcode, errmsg,
+                    headers
+                    )
 
-        self.verbose = verbose
+            self.verbose = verbose
 
-        try:
-            sock = h._conn.sock
-        except AttributeError:
-            sock = None
+            try:
+                sock = h._conn.sock
+            except AttributeError:
+                sock = None
 
-        return self._parse_response(h.getfile(), sock)
+            return self._parse_response(h.getfile(), sock)
 
-    def make_connection(self, host):
-        import httplib
-        host, extra_headers, x509 = self.get_host_info(host)
-        return httplib.HTTP(host)
+        def make_connection(self, host):
+            import httplib
+            host, extra_headers, x509 = self.get_host_info(host)
+            return httplib.HTTP(host)
 
-    def _parse_response(self, file, sock):
-        p, u = self.getparser()
+        def _parse_response(self, file, sock):
+            p, u = self.getparser()
 
-        while 1:
-            if sock:
-                response = sock.recv(1024)
-            else:
-                response = file.read(1024)
-            if not response:
-                break
-            if self.verbose:
-                print "body:", repr(response)
-            p.feed(response)
+            while 1:
+                if sock:
+                    response = sock.recv(1024)
+                else:
+                    response = file.read(1024)
+                if not response:
+                    break
+                if self.verbose:
+                    print("body:", repr(response))
+                p.feed(response)
 
-        file.close()
-        p.close()
+            file.close()
+            p.close()
 
-        return u.close()
+            return u.close()
+
+        def set_connection_token(self, token):
+            self.connection_token = token
+else:
+    class BBTransport(xmlrpclib.Transport):
+        def __init__(self):
+            self.connection_token = None
+            xmlrpclib.Transport.__init__(self)
+
+        def set_connection_token(self, token):
+            self.connection_token = token
+
+        def send_content(self, h, body):
+            if self.connection_token:
+                h.putheader("Bitbake-token", self.connection_token)
+            xmlrpclib.Transport.send_content(self, h, body)
 
 def _create_server(host, port):
-    # Python 2.7.0 and 2.7.1 have a buggy Transport implementation
-    # For those versions of Python, and only those versions, use our
-    # own copy/paste BBTransport class.
-    if (2, 7, 0) <= sys.version_info < (2, 7, 2):
-        t = BBTransport()
-        s = xmlrpclib.Server("http://%s:%d/" % (host, port), transport=t, allow_none=True)
-    else:
-        s = xmlrpclib.Server("http://%s:%d/" % (host, port), allow_none=True)
-
-    return s
+    t = BBTransport()
+    s = xmlrpclib.Server("http://%s:%d/" % (host, port), transport=t, allow_none=True)
+    return s, t
 
 class BitBakeServerCommands():
+
     def __init__(self, server):
         self.server = server
+        self.has_client = False
 
     def registerEventHandler(self, host, port):
         """
         Register a remote UI Event Handler
         """
-        s = _create_server(host, port)
+        s, t = _create_server(host, port)
 
         return bb.event.register_UIHhandler(s)
 
@@ -153,11 +183,145 @@ class BitBakeServerCommands():
         print("Server (cooker) exiting")
         return
 
-    def ping(self):
+    def addClient(self):
+        if self.has_client:
+            return None
+        token = hashlib.md5(str(time.time())).hexdigest()
+        self.server.set_connection_token(token)
+        self.has_client = True
+        return token
+
+    def removeClient(self):
+        if self.has_client:
+            self.server.set_connection_token(None)
+            self.has_client = False
+
+# This request handler checks if the request has a "Bitbake-token" header
+# field (this comes from the client side) and compares it with its internal
+# "Bitbake-token" field (this comes from the server). If the two are not
+# equal, it is assumed that a client is trying to connect to the server
+# while another client is connected to the server. In this case, a 503 error
+# ("service unavailable") is returned to the client.
+class BitBakeXMLRPCRequestHandler(SimpleXMLRPCRequestHandler):
+    def __init__(self, request, client_address, server):
+        self.connection_token = server.connection_token
+        SimpleXMLRPCRequestHandler.__init__(self, request, client_address, server)
+
+    def do_POST(self):
+        try:
+            remote_token = self.headers["Bitbake-token"]
+        except:
+            remote_token = None
+        if remote_token != self.connection_token:
+            self.report_503()
+        else:
+            SimpleXMLRPCRequestHandler.do_POST(self)
+
+    def report_503(self):
+        self.send_response(503)
+        response = 'No more client allowed'
+        self.send_header("Content-type", "text/plain")
+        self.send_header("Content-length", str(len(response)))
+        self.end_headers()
+        self.wfile.write(response)
+
+
+class BitBakeUIEventServer(threading.Thread):
+    class EventAdapter():
         """
-        Dummy method which can be used to check the server is still alive
+        Adapter to wrap our event queue since the caller (bb.event) expects to
+        call a send() method, but our actual queue only has put()
         """
-        return True
+        def __init__(self, notify):
+            self.queue = []
+            self.notify = notify
+            self.qlock = threading.Lock()
+
+        def send(self, event):
+            self.qlock.acquire()
+            self.queue.append(event)
+            self.qlock.release()
+            self.notify.set()
+
+        def get(self):
+            self.qlock.acquire()
+            if len(self.queue) == 0:
+                self.qlock.release()
+                return None
+            e = self.queue.pop(0)
+            if len(self.queue) == 0:
+                self.notify.clear()
+            self.qlock.release()
+            return e
+
+    def __init__(self, connection):
+        self.connection = connection
+        self.notify = threading.Event()
+        self.event = BitBakeUIEventServer.EventAdapter(self.notify)
+        self.quit = False
+        threading.Thread.__init__(self)
+
+    def terminateServer(self):
+        self.quit = True
+
+    def run(self):
+        while not self.quit:
+            self.notify.wait(0.1)
+            evt = self.event.get()
+            if evt:
+                self.connection.event.sendpickle(pickle.dumps(evt))
+
+class BitBakeXMLRPCEventServerController(SimpleXMLRPCServer):
+    def __init__(self, interface):
+        SimpleXMLRPCServer.__init__(self, interface, logRequests=False, allow_none=True)
+        self.register_function(self.registerEventHandler, "registerEventHandler")
+        self.register_function(self.unregisterEventHandler, "unregisterEventHandler")
+        self.register_function(self.terminateServer, "terminateServer")
+        #self.register_function(self.runCommand, "runCommand")
+        self.quit = False
+        self.clients = {}
+        self.client_ui_ids = {}
+
+    def registerEventHandler(self, host, port):
+        """
+        Register a remote UI Event Handler
+        """
+        print "registering handler %s:%s" % (host,port) 
+        connection = xmlrpclib.ServerProxy("http://%s:%d/" % (host, port), allow_none=True)
+        client_hash = "%s:%d" % (host, port)
+        if self.clients.has_key(client_hash):
+            return None
+        client_ui_server = BitBakeUIEventServer(connection)
+        self.client_ui_ids[client_hash] = bb.event.register_UIHhandler(client_ui_server)
+        client_ui_server.start()
+        self.clients[client_hash] = client_ui_server
+        return client_hash
+
+    def unregisterEventHandler(self, client_hash):
+        """
+        Unregister a remote UI Event Handler
+        """
+        print "unregistering handler %s:%s" % (host,port)
+        client_thread = self.clients[client_hash]
+        if client_thread:
+            bb.event.unregister_UIHhandler(self.clients_ui_ids[client_hash])
+            client_thread.terminateServer()
+            client_thread.join()
+            return True
+        else:
+            return False
+
+    def terminateServer(self):
+        self.quit = True
+
+    def runCommand(self, cmd):
+        return None
+
+    def serve_forever(self, main_server):
+        self.main_server = main_server
+        while not self.quit:
+            self.handle_request()
+        self.server_close()
 
 class BitBakeXMLRPCServer(SimpleXMLRPCServer):
     # remove this when you're done with debugging
@@ -168,13 +332,15 @@ class BitBakeXMLRPCServer(SimpleXMLRPCServer):
         Constructor
         """
         SimpleXMLRPCServer.__init__(self, interface,
-                                    requestHandler=SimpleXMLRPCRequestHandler,
+                                    requestHandler=BitBakeXMLRPCRequestHandler,
                                     logRequests=False, allow_none=True)
         self._idlefuns = {}
         self.host, self.port = self.socket.getsockname()
+        self.connection_token = None
         #self.register_introspection_functions()
         self.commands = BitBakeServerCommands(self)
         self.autoregister_all_functions(self.commands, "")
+        self.interface = interface
 
     def addcooker(self, cooker):
         self.cooker = cooker
@@ -196,8 +362,16 @@ class BitBakeXMLRPCServer(SimpleXMLRPCServer):
         self._idlefuns[function] = data
 
     def serve_forever(self):
+        # Create and run the event server controller in a separate thread
+        evt_server_ctrl = BitBakeXMLRPCEventServerController((self.host, self.port + 2))
+        self.event_controller_thread = threading.Thread(target = evt_server_ctrl.serve_forever, args = (self,))
+        self.event_controller_thread.start()
+        # Start the actual XMLRPC server
         bb.cooker.server_main(self.cooker, self._serve_forever)
 
+    def removeClient(self):
+        self.commands.removeClient()
+
     def _serve_forever(self):
         """
         Serve Requests. Overloaded to honor a quit command
@@ -237,10 +411,15 @@ class BitBakeXMLRPCServer(SimpleXMLRPCServer):
                 retval = function(self, data, True)
             except:
                 pass
-
+        # Terminate the event server
+        self.event_controller_thread.terminateServer()
+        self.event_controller_thread.join()
         self.server_close()
         return
 
+    def set_connection_token(self, token):
+        self.connection_token = token
+
 class BitbakeServerInfo():
     def __init__(self, host, port):
         self.host = host
@@ -248,10 +427,22 @@ class BitbakeServerInfo():
 
 class BitBakeServerConnection():
     def __init__(self, serverinfo, clientinfo=("localhost", 0)):
-        self.connection = _create_server(serverinfo.host, serverinfo.port)
-        self.events = uievent.BBUIEventQueue(self.connection, clientinfo)
+        self.connection, self.transport = _create_server(serverinfo.host, serverinfo.port)
+        self.clientinfo = clientinfo
+        self.serverinfo = serverinfo
+
+    def connect(self):
+        token = self.connection.addClient()
+        if token is None:
+            return None
+        self.transport.set_connection_token(token)
+        self.events = uievent.BBUIEventQueue(self.connection, self.clientinfo)
         for event in bb.event.ui_queue:
             self.events.queue_event(event)
+        return self
+
+    def removeClient(self):
+        self.connection.removeClient()
 
     def terminate(self):
         # Don't wait for server indefinitely
@@ -277,7 +468,7 @@ class BitBakeServer(object):
     def getServerIdleCB(self):
         return self.server.register_idle_function
 
-    def saveConnectionDetails(self): 
+    def saveConnectionDetails(self):
         self.serverinfo = BitbakeServerInfo(self.server.host, self.server.port)
 
     def detach(self):
@@ -287,9 +478,41 @@ class BitBakeServer(object):
 
     def establishConnection(self):
         self.connection = BitBakeServerConnection(self.serverinfo)
-        return self.connection
+        return self.connection.connect()
 
-    def launchUI(self, uifunc, *args):
-        return uifunc(*args)
+    def set_connection_token(self, token):
+        self.connection.transport.set_connection_token(token)
 
+    def endSession(self):
+        self.connection.terminate()
 
+class BitBakeXMLRPCClient(object):
+
+    def __init__(self):
+        pass
+
+    def saveConnectionDetails(self, remote):
+        self.remote = remote
+
+    def establishConnection(self):
+        # The format of "remote" must be "server:port"
+        try:
+            [host, port] = self.remote.split(":")
+            port = int(port)
+        except:
+            return None
+        # We need our IP for the server connection. We get the IP
+        # by trying to connect with the server
+        try:
+            s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
+            s.connect((host, port))
+            ip = s.getsockname()[0]
+            s.close()
+        except:
+            return None
+        self.serverinfo = BitbakeServerInfo(host, port)
+        self.connection = BitBakeServerConnection(self.serverinfo, (ip, 0))
+        return self.connection.connect()
+
+    def endSession(self):
+        self.connection.removeClient()

bitbake/lib/bb/siggen.py

@@ -24,7 +24,7 @@ def init(d):
             break
     else:
         logger.error("Invalid signature generator '%s', using default 'noop'\n"
-                     "Available generators: %s",
+                     "Available generators: %s", desired,
                      ', '.join(obj.name for obj in siggens))
         return SignatureGenerator(d)
 
@@ -249,7 +249,7 @@ class SignatureGeneratorBasic(SignatureGenerator):
                 os.fsync(fd)
             os.chmod(tmpfile, 0664)
             os.rename(tmpfile, sigfile)
-        except (OSError, IOError), err:
+        except (OSError, IOError) as err:
             try:
                 os.unlink(tmpfile)
             except OSError:

bitbake/lib/bb/tests/fetch.py

@@ -251,9 +251,24 @@ class URITest(unittest.TestCase):
             self.assertEqual(uri.params, {})
             self.assertEqual(str(uri), (str(uri).split(";"))[0])
 
-
 class FetcherTest(unittest.TestCase):
 
+    def setUp(self):
+        self.d = bb.data.init()
+        self.tempdir = tempfile.mkdtemp()
+        self.dldir = os.path.join(self.tempdir, "download")
+        os.mkdir(self.dldir)
+        self.d.setVar("DL_DIR", self.dldir)
+        self.unpackdir = os.path.join(self.tempdir, "unpacked")
+        os.mkdir(self.unpackdir)
+        persistdir = os.path.join(self.tempdir, "persistdata")
+        self.d.setVar("PERSISTENT_DIR", persistdir)
+
+    def tearDown(self):
+        bb.utils.prunedir(self.tempdir)
+
+class MirrorUriTest(FetcherTest):
+
     replaceuris = {
         ("git://git.invalid.infradead.org/mtd-utils.git;tag=1234567890123456789012345678901234567890", "git://.*/.*", "http://somewhere.org/somedir/") 
             : "http://somewhere.org/somedir/git2_git.invalid.infradead.org.mtd-utils.git.tar.gz",
@@ -294,101 +309,6 @@ class FetcherTest(unittest.TestCase):
                 "https://.*/.* file:///someotherpath/downloads/ \n" \
                 "http://.*/.* file:///someotherpath/downloads/ \n"
 
-    def setUp(self):
-        self.d = bb.data.init()
-        self.tempdir = tempfile.mkdtemp()
-        self.dldir = os.path.join(self.tempdir, "download")
-        os.mkdir(self.dldir)
-        self.d.setVar("DL_DIR", self.dldir)
-        self.unpackdir = os.path.join(self.tempdir, "unpacked")
-        os.mkdir(self.unpackdir)
-        persistdir = os.path.join(self.tempdir, "persistdata")
-        self.d.setVar("PERSISTENT_DIR", persistdir)
-
-    def tearDown(self):
-        bb.utils.prunedir(self.tempdir)
-
-    @unittest.skipIf(os.environ.get("BB_SKIP_NETTESTS") == "yes",
-                     "Unset BB_SKIP_NETTESTS to run network tests")
-    def test_fetch(self):
-        fetcher = bb.fetch.Fetch(["http://downloads.yoctoproject.org/releases/bitbake/bitbake-1.0.tar.gz", "http://downloads.yoctoproject.org/releases/bitbake/bitbake-1.1.tar.gz"], self.d)
-        fetcher.download()
-        self.assertEqual(os.path.getsize(self.dldir + "/bitbake-1.0.tar.gz"), 57749)
-        self.assertEqual(os.path.getsize(self.dldir + "/bitbake-1.1.tar.gz"), 57892)
-        self.d.setVar("BB_NO_NETWORK", "1")
-        fetcher = bb.fetch.Fetch(["http://downloads.yoctoproject.org/releases/bitbake/bitbake-1.0.tar.gz", "http://downloads.yoctoproject.org/releases/bitbake/bitbake-1.1.tar.gz"], self.d)
-        fetcher.download()
-        fetcher.unpack(self.unpackdir)
-        self.assertEqual(len(os.listdir(self.unpackdir + "/bitbake-1.0/")), 9)
-        self.assertEqual(len(os.listdir(self.unpackdir + "/bitbake-1.1/")), 9)
-
-    @unittest.skipIf(os.environ.get("BB_SKIP_NETTESTS") == "yes",
-                     "Unset BB_SKIP_NETTESTS to run network tests")
-    def test_fetch_mirror(self):
-        self.d.setVar("MIRRORS", "http://.*/.* http://downloads.yoctoproject.org/releases/bitbake")
-        fetcher = bb.fetch.Fetch(["http://invalid.yoctoproject.org/releases/bitbake/bitbake-1.0.tar.gz"], self.d)
-        fetcher.download()
-        self.assertEqual(os.path.getsize(self.dldir + "/bitbake-1.0.tar.gz"), 57749)
-
-    @unittest.skipIf(os.environ.get("BB_SKIP_NETTESTS") == "yes",
-                     "Unset BB_SKIP_NETTESTS to run network tests")
-    def test_fetch_premirror(self):
-        self.d.setVar("PREMIRRORS", "http://.*/.* http://downloads.yoctoproject.org/releases/bitbake")
-        fetcher = bb.fetch.Fetch(["http://invalid.yoctoproject.org/releases/bitbake/bitbake-1.0.tar.gz"], self.d)
-        fetcher.download()
-        self.assertEqual(os.path.getsize(self.dldir + "/bitbake-1.0.tar.gz"), 57749)
-
-    def gitfetcher(self, url1, url2):
-        def checkrevision(self, fetcher):
-            fetcher.unpack(self.unpackdir)
-            revision = subprocess.check_output("git rev-parse HEAD", shell=True, cwd=self.unpackdir + "/git").strip()
-            self.assertEqual(revision, "270a05b0b4ba0959fe0624d2a4885d7b70426da5")
-
-        self.d.setVar("BB_GENERATE_MIRROR_TARBALLS", "1")
-        self.d.setVar("SRCREV", "270a05b0b4ba0959fe0624d2a4885d7b70426da5")
-        fetcher = bb.fetch.Fetch([url1], self.d)
-        fetcher.download()
-        checkrevision(self, fetcher)
-        # Wipe out the dldir clone and the unpacked source, turn off the network and check mirror tarball works
-        bb.utils.prunedir(self.dldir + "/git2/")
-        bb.utils.prunedir(self.unpackdir)
-        self.d.setVar("BB_NO_NETWORK", "1")
-        fetcher = bb.fetch.Fetch([url2], self.d)
-        fetcher.download()
-        checkrevision(self, fetcher)
-
-    @unittest.skipIf(os.environ.get("BB_SKIP_NETTESTS") == "yes",
-                     "Unset BB_SKIP_NETTESTS to run network tests")
-    def test_gitfetch(self):
-        url1 = url2 = "git://git.openembedded.org/bitbake"
-        self.gitfetcher(url1, url2)
-
-    @unittest.skipIf(os.environ.get("BB_SKIP_NETTESTS") == "yes",
-                     "Unset BB_SKIP_NETTESTS to run network tests")
-    def test_gitfetch_premirror(self):
-        url1 = "git://git.openembedded.org/bitbake"
-        url2 = "git://someserver.org/bitbake"
-        self.d.setVar("PREMIRRORS", "git://someserver.org/bitbake git://git.openembedded.org/bitbake \n")
-        self.gitfetcher(url1, url2)
-
-    @unittest.skipIf(os.environ.get("BB_SKIP_NETTESTS") == "yes",
-                     "Unset BB_SKIP_NETTESTS to run network tests")
-    def test_gitfetch_premirror2(self):
-        url1 = url2 = "git://someserver.org/bitbake"
-        self.d.setVar("PREMIRRORS", "git://someserver.org/bitbake git://git.openembedded.org/bitbake \n")
-        self.gitfetcher(url1, url2)
-
-    @unittest.skipIf(os.environ.get("BB_SKIP_NETTESTS") == "yes",
-                     "Unset BB_SKIP_NETTESTS to run network tests")
-    def test_gitfetch_premirror3(self):
-        realurl = "git://git.openembedded.org/bitbake"
-        dummyurl = "git://someserver.org/bitbake"
-        self.sourcedir = self.unpackdir.replace("unpacked", "sourcemirror.git")
-        os.chdir(self.tempdir)
-        subprocess.check_output("git clone %s %s 2> /dev/null" % (realurl, self.sourcedir), shell=True)
-        self.d.setVar("PREMIRRORS", "%s git://%s;protocol=file \n" % (dummyurl, self.sourcedir))
-        self.gitfetcher(dummyurl, dummyurl)
-
     def test_urireplace(self):
         for k, v in self.replaceuris.items():
             ud = bb.fetch.FetchData(k[0], self.d)
@@ -410,6 +330,77 @@ class FetcherTest(unittest.TestCase):
         uris, uds = bb.fetch2.build_mirroruris(fetcher, mirrors, self.d)
         self.assertEqual(uris, ['file:///someotherpath/downloads/bitbake-1.0.tar.gz'])
 
+class FetcherNetworkTest(FetcherTest):
+
+    if os.environ.get("BB_SKIP_NETTESTS") == "yes":
+        print("Unset BB_SKIP_NETTESTS to run network tests")
+    else:
+        def test_fetch(self):
+            fetcher = bb.fetch.Fetch(["http://downloads.yoctoproject.org/releases/bitbake/bitbake-1.0.tar.gz", "http://downloads.yoctoproject.org/releases/bitbake/bitbake-1.1.tar.gz"], self.d)
+            fetcher.download()
+            self.assertEqual(os.path.getsize(self.dldir + "/bitbake-1.0.tar.gz"), 57749)
+            self.assertEqual(os.path.getsize(self.dldir + "/bitbake-1.1.tar.gz"), 57892)
+            self.d.setVar("BB_NO_NETWORK", "1")
+            fetcher = bb.fetch.Fetch(["http://downloads.yoctoproject.org/releases/bitbake/bitbake-1.0.tar.gz", "http://downloads.yoctoproject.org/releases/bitbake/bitbake-1.1.tar.gz"], self.d)
+            fetcher.download()
+            fetcher.unpack(self.unpackdir)
+            self.assertEqual(len(os.listdir(self.unpackdir + "/bitbake-1.0/")), 9)
+            self.assertEqual(len(os.listdir(self.unpackdir + "/bitbake-1.1/")), 9)
+
+        def test_fetch_mirror(self):
+            self.d.setVar("MIRRORS", "http://.*/.* http://downloads.yoctoproject.org/releases/bitbake")
+            fetcher = bb.fetch.Fetch(["http://invalid.yoctoproject.org/releases/bitbake/bitbake-1.0.tar.gz"], self.d)
+            fetcher.download()
+            self.assertEqual(os.path.getsize(self.dldir + "/bitbake-1.0.tar.gz"), 57749)
+
+        def test_fetch_premirror(self):
+            self.d.setVar("PREMIRRORS", "http://.*/.* http://downloads.yoctoproject.org/releases/bitbake")
+            fetcher = bb.fetch.Fetch(["http://invalid.yoctoproject.org/releases/bitbake/bitbake-1.0.tar.gz"], self.d)
+            fetcher.download()
+            self.assertEqual(os.path.getsize(self.dldir + "/bitbake-1.0.tar.gz"), 57749)
+
+        def gitfetcher(self, url1, url2):
+            def checkrevision(self, fetcher):
+                fetcher.unpack(self.unpackdir)
+                revision = bb.process.run("git rev-parse HEAD", shell=True, cwd=self.unpackdir + "/git")[0].strip()
+                self.assertEqual(revision, "270a05b0b4ba0959fe0624d2a4885d7b70426da5")
+
+            self.d.setVar("BB_GENERATE_MIRROR_TARBALLS", "1")
+            self.d.setVar("SRCREV", "270a05b0b4ba0959fe0624d2a4885d7b70426da5")
+            fetcher = bb.fetch.Fetch([url1], self.d)
+            fetcher.download()
+            checkrevision(self, fetcher)
+            # Wipe out the dldir clone and the unpacked source, turn off the network and check mirror tarball works
+            bb.utils.prunedir(self.dldir + "/git2/")
+            bb.utils.prunedir(self.unpackdir)
+            self.d.setVar("BB_NO_NETWORK", "1")
+            fetcher = bb.fetch.Fetch([url2], self.d)
+            fetcher.download()
+            checkrevision(self, fetcher)
+
+        def test_gitfetch(self):
+            url1 = url2 = "git://git.openembedded.org/bitbake"
+            self.gitfetcher(url1, url2)
+
+        def test_gitfetch_premirror(self):
+            url1 = "git://git.openembedded.org/bitbake"
+            url2 = "git://someserver.org/bitbake"
+            self.d.setVar("PREMIRRORS", "git://someserver.org/bitbake git://git.openembedded.org/bitbake \n")
+            self.gitfetcher(url1, url2)
+
+        def test_gitfetch_premirror2(self):
+            url1 = url2 = "git://someserver.org/bitbake"
+            self.d.setVar("PREMIRRORS", "git://someserver.org/bitbake git://git.openembedded.org/bitbake \n")
+            self.gitfetcher(url1, url2)
+
+        def test_gitfetch_premirror3(self):
+            realurl = "git://git.openembedded.org/bitbake"
+            dummyurl = "git://someserver.org/bitbake"
+            self.sourcedir = self.unpackdir.replace("unpacked", "sourcemirror.git")
+            os.chdir(self.tempdir)
+            bb.process.run("git clone %s %s 2> /dev/null" % (realurl, self.sourcedir), shell=True)
+            self.d.setVar("PREMIRRORS", "%s git://%s;protocol=file \n" % (dummyurl, self.sourcedir))
+            self.gitfetcher(dummyurl, dummyurl)
 
 class URLHandle(unittest.TestCase):
 

bitbake/lib/bb/tinfoil.py

@@ -25,7 +25,8 @@ import bb.cache
 import bb.cooker
 import bb.providers
 import bb.utils
-from bb.cooker import state
+from bb.cooker import state, BBCooker
+from bb.cookerdata import CookerConfiguration, ConfigParameters
 import bb.fetch2
 
 class Tinfoil:
@@ -43,12 +44,11 @@ class Tinfoil:
         console.setFormatter(format)
         self.logger.addHandler(console)
 
-        initialenv = os.environ.copy()
-        bb.utils.clean_environment()
-        self.config = TinfoilConfig(parse_only=True)
-        self.cooker = bb.cooker.BBCooker(self.config,
-                                            self.register_idle_function,
-                                            initialenv)
+        self.config = CookerConfiguration()
+        configparams = TinfoilConfigParameters(parse_only=True)
+        self.config.setConfigParameters(configparams)
+        self.config.setServerRegIdleCallback(self.register_idle_function)
+        self.cooker = BBCooker(self.config)
         self.config_data = self.cooker.configuration.data
         bb.providers.logger.setLevel(logging.ERROR)
         self.cooker_data = None
@@ -71,30 +71,26 @@ class Tinfoil:
         self.logger.setLevel(logging.INFO)
         sys.stderr.write("done.\n")
 
-        self.cooker_data = self.cooker.status
+        self.cooker_data = self.cooker.recipecache
 
     def prepare(self, config_only = False):
         if not self.cooker_data:
             if config_only:
                 self.cooker.parseConfiguration()
-                self.cooker_data = self.cooker.status
+                self.cooker_data = self.cooker.recipecache
             else:
                 self.parseRecipes()
 
+class TinfoilConfigParameters(ConfigParameters):
 
-class TinfoilConfig(object):
     def __init__(self, **options):
-        self.pkgs_to_build = []
-        self.debug_domains = []
-        self.extra_assume_provided = []
-        self.prefile = []
-        self.postfile = []
-        self.debug = 0
-        self.__dict__.update(options)
+        self.initial_options = options
+        super(TinfoilConfigParameters, self).__init__()
 
-    def __getattr__(self, attribute):
-        try:
-            return super(TinfoilConfig, self).__getattribute__(attribute)
-        except AttributeError:
-            return None
+    def parseCommandLine(self):
+        class DummyOptions:
+            def __init__(self, initial_options):
+                for key, val in initial_options.items():
+                    setattr(self, key, val)
 
+        return DummyOptions(self.initial_options), None

bitbake/lib/bb/ui/crumbs/builder.py

@@ -108,6 +108,8 @@ class Configuration:
         self.extra_setting = {}
         self.toolchain_build = False
         self.image_fstypes = ""
+        self.image_size = None
+        self.image_packages = []
         # bblayers.conf
         self.layers = []
         # image/recipes/packages
@@ -538,7 +540,7 @@ class Builder(gtk.Window):
         if not self.display_sanity_check:
           func()
         else:
-          sanity_check_post_func = func
+          self.sanity_check_post_func = func
 
     def generate_configuration(self):
         if not self.sanity_checked:

bitbake/lib/bb/ui/crumbs/hig/advancedsettingsdialog.py

@@ -264,7 +264,7 @@ class AdvancedSettingsDialog (CrumbsDialog, SettingsUIHelper):
         sub_vbox = gtk.VBox(False, 6)
         advanced_vbox.pack_start(sub_vbox, expand=False, fill=False)
         label = self.gen_label_widget("Image basic size (in MB)")
-        tooltip = "Sets the basic size of your target image.\nThis is the basic size of your target image unless your selected package size exceeds this value or you select \'Image Extra Size\'."
+        tooltip = "Defines the size for the generated image. The OpenEmbedded build system determines the final size for the generated image using an algorithm that takes into account the initial disk space used for the generated image, the Image basic size value, and the Additional free space value.\n\nFor more information, check the <a href=\"http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#var-IMAGE_ROOTFS_SIZE\">Yocto Project Reference Manual</a>."
         rootfs_size_widget, self.rootfs_size_spinner = self.gen_spinner_widget(int(self.configuration.image_rootfs_size*1.0/1024), 0, 65536,"<b>Image basic size</b>" + "*" + tooltip)
         sub_vbox.pack_start(label, expand=False, fill=False)
         sub_vbox.pack_start(rootfs_size_widget, expand=False, fill=False)
@@ -272,7 +272,7 @@ class AdvancedSettingsDialog (CrumbsDialog, SettingsUIHelper):
         sub_vbox = gtk.VBox(False, 6)
         advanced_vbox.pack_start(sub_vbox, expand=False, fill=False)
         label = self.gen_label_widget("Additional free space (in MB)")
-        tooltip = "Sets the extra free space of your target image.\nBy default, the system reserves 30% of your image size as free space. If your image contains zypper, it brings in 50MB more space. The maximum free space is 64GB."
+        tooltip = "Sets extra free disk space to be added to the generated image. Use this variable when you want to ensure that a specific amount of free disk space is available on a device after an image is installed and running."
         extra_size_widget, self.extra_size_spinner = self.gen_spinner_widget(int(self.configuration.image_extra_size*1.0/1024), 0, 65536,"<b>Additional free space</b>" + "*" + tooltip)
         sub_vbox.pack_start(label, expand=False, fill=False)
         sub_vbox.pack_start(extra_size_widget, expand=False, fill=False)

bitbake/lib/bb/ui/crumbs/hig/imageselectiondialog.py

@@ -84,7 +84,7 @@ class ImageSelectionDialog (CrumbsDialog):
         open_button.connect("clicked", self.select_path_cb, self, entry)
         table.attach(open_button, 9, 10, 0, 1)
 
-        self.image_table = HobViewTable(self.__columns__)
+        self.image_table = HobViewTable(self.__columns__, "Images")
         self.image_table.set_size_request(-1, 300)
         self.image_table.connect("toggled", self.toggled_cb)
         self.image_table.connect_group_selection(self.table_selected_cb)

bitbake/lib/bb/ui/crumbs/hig/propertydialog.py

@@ -87,6 +87,7 @@ class PropertyDialog(CrumbsDialog):
                 self.table.attach(self.info_label, 0,1,1,2, xoptions=gtk.FILL|gtk.EXPAND, yoptions=gtk.FILL,xpadding=40,ypadding=10)
         
                 self.vbox.add(self.table)
+                self.connect('delete-event', lambda w, e: self.destroy() or True) 
 
         def treeViewTooltip( self, widget, e, tooltips, cell, emptyText="" ):
                  try:

bitbake/lib/bb/ui/crumbs/hoblistmodel.py

@@ -63,6 +63,7 @@ class PackageListModel(gtk.ListStore):
                                 gobject.TYPE_BOOLEAN,
                                 gobject.TYPE_STRING,
                                 gobject.TYPE_STRING)
+        self.sort_column_id, self.sort_order = PackageListModel.COL_NAME, gtk.SORT_ASCENDING
 
     """
     Find the model path for the item_name
@@ -103,51 +104,108 @@ class PackageListModel(gtk.ListStore):
     Create, if required, and return a filtered gtk.TreeModelSort
     containing only the items specified by filter
     """
-    def tree_model(self, filter, excluded_items_ahead=False, included_items_ahead=True, search_data=None):
+    def tree_model(self, filter, excluded_items_ahead=False, included_items_ahead=False, search_data=None, initial=False):
         model = self.filter_new()
         self.filtered_nb = 0
         model.set_visible_func(self.tree_model_filter, filter)
 
         sort = gtk.TreeModelSort(model)
-        if excluded_items_ahead:
+        sort.connect ('sort-column-changed', self.sort_column_changed_cb)
+        if initial:
+            sort.set_sort_column_id(PackageListModel.COL_NAME, gtk.SORT_ASCENDING)
+            sort.set_default_sort_func(None)
+        elif excluded_items_ahead:
             sort.set_default_sort_func(self.exclude_item_sort_func, search_data)
         elif included_items_ahead:
             sort.set_default_sort_func(self.include_item_sort_func, search_data)
         else:
-            sort.set_sort_column_id(RecipeListModel.COL_NAME, gtk.SORT_ASCENDING)
-            sort.set_default_sort_func(None)
+            if search_data and search_data!='Search recipes by name' and search_data!='Search package groups by name':
+                sort.set_default_sort_func(self.sort_func, search_data)
+            else:
+                sort.set_sort_column_id(self.sort_column_id, self.sort_order)
+                sort.set_default_sort_func(None)
+
+        sort.set_sort_func(PackageListModel.COL_INC, self.sort_column, PackageListModel.COL_INC)
+        sort.set_sort_func(PackageListModel.COL_SIZE, self.sort_column, PackageListModel.COL_SIZE)
+        sort.set_sort_func(PackageListModel.COL_BINB, self.sort_binb_column)
+        sort.set_sort_func(PackageListModel.COL_RCP, self.sort_column, PackageListModel.COL_RCP)
         return sort
 
+    def sort_column_changed_cb (self, data):
+        self.sort_column_id, self.sort_order = data.get_sort_column_id ()
+
+    def sort_column(self, model, row1, row2, col):
+        value1 = model.get_value(row1, col)
+        value2 = model.get_value(row2, col)
+        if col==PackageListModel.COL_SIZE:
+            value1 = HobPage._string_to_size(value1)
+            value2 = HobPage._string_to_size(value2)
+
+        cmp_res = cmp(value1, value2)
+        if cmp_res!=0:
+            if col==PackageListModel.COL_INC:
+                return -cmp_res
+            else:
+                return cmp_res
+        else:
+            name1 = model.get_value(row1, PackageListModel.COL_NAME)
+            name2 = model.get_value(row2, PackageListModel.COL_NAME)
+            return cmp(name1,name2)
+
+    def sort_binb_column(self, model, row1, row2):
+        value1 = model.get_value(row1, PackageListModel.COL_BINB)
+        value2 = model.get_value(row2, PackageListModel.COL_BINB)
+        value1_list = value1.split(', ')
+        value2_list = value2.split(', ')
+
+        value1 = value1_list[0]
+        value2 = value2_list[0]
+
+        cmp_res = cmp(value1, value2)
+        if cmp_res==0:
+            cmp_size = cmp(len(value1_list), len(value2_list))
+            if cmp_size==0:
+                name1 = model.get_value(row1, PackageListModel.COL_NAME)
+                name2 = model.get_value(row2, PackageListModel.COL_NAME)
+                return cmp(name1,name2)
+            else:
+                return cmp_size
+        else:
+            return cmp_res
+
     def exclude_item_sort_func(self, model, iter1, iter2, user_data=None):
         if user_data:
-            val1 = model.get_value(iter1, RecipeListModel.COL_NAME)
-            val2 = model.get_value(iter2, RecipeListModel.COL_NAME)
-            if val1.startswith(user_data) and not val2.startswith(user_data):
-                return -1
-            elif not val1.startswith(user_data) and val2.startswith(user_data):
-                return 1
-            else:
-                return 0
+            val1 = model.get_value(iter1, PackageListModel.COL_NAME)
+            val2 = model.get_value(iter2, PackageListModel.COL_NAME)
+            return self.cmp_vals(val1, val2, user_data)
         else:
-            val1 = model.get_value(iter1, RecipeListModel.COL_FADE_INC)
-            val2 = model.get_value(iter2, RecipeListModel.COL_INC)
+            val1 = model.get_value(iter1, PackageListModel.COL_FADE_INC)
+            val2 = model.get_value(iter2, PackageListModel.COL_INC)
             return ((val1 == True) and (val2 == False))
 
     def include_item_sort_func(self, model, iter1, iter2, user_data=None):
         if user_data:
-            val1 = model.get_value(iter1, RecipeListModel.COL_NAME)
-            val2 = model.get_value(iter2, RecipeListModel.COL_NAME)
-            if val1.startswith(user_data) and not val2.startswith(user_data):
-                return -1
-            elif not val1.startswith(user_data) and val2.startswith(user_data):
-                return 1
-            else:
-                return 0
+            val1 = model.get_value(iter1, PackageListModel.COL_NAME)
+            val2 = model.get_value(iter2, PackageListModel.COL_NAME)
+            return self.cmp_vals(val1, val2, user_data)
         else:
-            val1 = model.get_value(iter1, RecipeListModel.COL_INC)
-            val2 = model.get_value(iter2, RecipeListModel.COL_INC)
+            val1 = model.get_value(iter1, PackageListModel.COL_INC)
+            val2 = model.get_value(iter2, PackageListModel.COL_INC)
             return ((val1 == False) and (val2 == True))
 
+    def sort_func(self, model, iter1, iter2, user_data):
+        val1 = model.get_value(iter1, PackageListModel.COL_NAME)
+        val2 = model.get_value(iter2, PackageListModel.COL_NAME)
+        return self.cmp_vals(val1, val2, user_data)
+
+    def cmp_vals(self, val1, val2, user_data):
+        if val1.startswith(user_data) and not val2.startswith(user_data):
+            return -1
+        elif not val1.startswith(user_data) and val2.startswith(user_data):
+            return 1
+        else:
+            return cmp(val1, val2)
+
     def convert_vpath_to_path(self, view_model, view_path):
         # view_model is the model sorted
         # get the path of the model filtered
@@ -162,7 +220,7 @@ class PackageListModel(gtk.ListStore):
         it = view_model.get_iter_first()
         while it:
             name = self.find_item_for_path(path)
-            view_name = view_model.get_value(it, RecipeListModel.COL_NAME)
+            view_name = view_model.get_value(it, PackageListModel.COL_NAME)
             if view_name == name:
                 view_path = view_model.get_path(it)
                 return view_path
@@ -213,7 +271,6 @@ class PackageListModel(gtk.ListStore):
 
             # pkgsize is in KB
             size = HobPage._size_to_string(HobPage._string_to_size(pkgsize + ' KB'))
-
             self.set(self.append(), self.COL_NAME, pkg, self.COL_VER, pkgv,
                      self.COL_REV, pkgr, self.COL_RNM, pkg_rename,
                      self.COL_SEC, section, self.COL_SUM, summary,
@@ -448,6 +505,7 @@ class RecipeListModel(gtk.ListStore):
                                 gobject.TYPE_STRING,
                                 gobject.TYPE_STRING,
                                 gobject.TYPE_STRING)
+        self.sort_column_id, self.sort_order = RecipeListModel.COL_NAME, gtk.SORT_ASCENDING
 
     """
     Find the model path for the item_name
@@ -494,12 +552,7 @@ class RecipeListModel(gtk.ListStore):
         if user_data:
             val1 = model.get_value(iter1, RecipeListModel.COL_NAME)
             val2 = model.get_value(iter2, RecipeListModel.COL_NAME)
-            if val1.startswith(user_data) and not val2.startswith(user_data):
-                return -1
-            elif not val1.startswith(user_data) and val2.startswith(user_data):
-                return 1
-            else:
-                return 0
+            return self.cmp_vals(val1, val2, user_data)
         else:
             val1 = model.get_value(iter1, RecipeListModel.COL_FADE_INC)
             val2 = model.get_value(iter2, RecipeListModel.COL_INC)
@@ -509,36 +562,94 @@ class RecipeListModel(gtk.ListStore):
         if user_data:
             val1 = model.get_value(iter1, RecipeListModel.COL_NAME)
             val2 = model.get_value(iter2, RecipeListModel.COL_NAME)
-            if val1.startswith(user_data) and not val2.startswith(user_data):
-                return -1
-            elif not val1.startswith(user_data) and val2.startswith(user_data):
-                return 1
-            else:
-                return 0
+            return self.cmp_vals(val1, val2, user_data)
         else:
             val1 = model.get_value(iter1, RecipeListModel.COL_INC)
             val2 = model.get_value(iter2, RecipeListModel.COL_INC)
             return ((val1 == False) and (val2 == True))
 
+    def sort_func(self, model, iter1, iter2, user_data):
+        val1 = model.get_value(iter1, RecipeListModel.COL_NAME)
+        val2 = model.get_value(iter2, RecipeListModel.COL_NAME)
+        return self.cmp_vals(val1, val2, user_data)
+
+    def cmp_vals(self, val1, val2, user_data):
+        if val1.startswith(user_data) and not val2.startswith(user_data):
+            return -1
+        elif not val1.startswith(user_data) and val2.startswith(user_data):
+            return 1
+        else:
+            return cmp(val1, val2)
+
     """
     Create, if required, and return a filtered gtk.TreeModelSort
     containing only the items specified by filter
     """
-    def tree_model(self, filter, excluded_items_ahead=False, included_items_ahead=True, search_data=None):
+    def tree_model(self, filter, excluded_items_ahead=False, included_items_ahead=False, search_data=None, initial=False):
         model = self.filter_new()
         self.filtered_nb = 0
         model.set_visible_func(self.tree_model_filter, filter)
 
         sort = gtk.TreeModelSort(model)
-        if excluded_items_ahead:
+        sort.connect ('sort-column-changed', self.sort_column_changed_cb)
+        if initial:
+            sort.set_sort_column_id(RecipeListModel.COL_NAME, gtk.SORT_ASCENDING)
+            sort.set_default_sort_func(None)
+        elif excluded_items_ahead:
             sort.set_default_sort_func(self.exclude_item_sort_func, search_data)
         elif included_items_ahead:
             sort.set_default_sort_func(self.include_item_sort_func, search_data)
         else:
-            sort.set_sort_column_id(RecipeListModel.COL_NAME, gtk.SORT_ASCENDING)
-            sort.set_default_sort_func(None)
+            if search_data and search_data!='Search recipes by name' and search_data!='Search package groups by name':
+                sort.set_default_sort_func(self.sort_func, search_data)
+            else:
+                sort.set_sort_column_id(self.sort_column_id, self.sort_order)
+                sort.set_default_sort_func(None)
+
+        sort.set_sort_func(RecipeListModel.COL_INC, self.sort_column, RecipeListModel.COL_INC)
+        sort.set_sort_func(RecipeListModel.COL_GROUP, self.sort_column, RecipeListModel.COL_GROUP)
+        sort.set_sort_func(RecipeListModel.COL_BINB, self.sort_binb_column)
+        sort.set_sort_func(RecipeListModel.COL_LIC, self.sort_column, RecipeListModel.COL_LIC)
         return sort
 
+    def sort_column_changed_cb (self, data):
+        self.sort_column_id, self.sort_order = data.get_sort_column_id ()
+
+    def sort_column(self, model, row1, row2, col):
+        value1 = model.get_value(row1, col)
+        value2 = model.get_value(row2, col)
+        cmp_res = cmp(value1, value2)
+        if cmp_res!=0:
+            if col==RecipeListModel.COL_INC:
+                return -cmp_res
+            else:
+                return cmp_res
+        else:
+            name1 = model.get_value(row1, RecipeListModel.COL_NAME)
+            name2 = model.get_value(row2, RecipeListModel.COL_NAME)
+            return cmp(name1,name2)
+
+    def sort_binb_column(self, model, row1, row2):
+        value1 = model.get_value(row1, RecipeListModel.COL_BINB)
+        value2 = model.get_value(row2, RecipeListModel.COL_BINB)
+        value1_list = value1.split(', ')
+        value2_list = value2.split(', ')
+
+        value1 = value1_list[0]
+        value2 = value2_list[0]
+
+        cmp_res = cmp(value1, value2)
+        if cmp_res==0:
+            cmp_size = cmp(len(value1_list), len(value2_list))
+            if cmp_size==0:
+                name1 = model.get_value(row1, RecipeListModel.COL_NAME)
+                name2 = model.get_value(row2, RecipeListModel.COL_NAME)
+                return cmp(name1,name2)
+            else:
+                return cmp_size
+        else:
+            return cmp_res
+
     def convert_vpath_to_path(self, view_model, view_path):
         filtered_model_path = view_model.convert_path_to_child_path(view_path)
         filtered_model = view_model.get_model()

bitbake/lib/bb/ui/crumbs/hobwidget.py

@@ -83,7 +83,7 @@ class HobViewTable (gtk.VBox):
                             gobject.TYPE_PYOBJECT,)),
     }
 
-    def __init__(self, columns):
+    def __init__(self, columns, name):
         gtk.VBox.__init__(self, False, 6)
         self.table_tree = gtk.TreeView()
         self.table_tree.set_headers_visible(True)
@@ -94,12 +94,18 @@ class HobViewTable (gtk.VBox):
         self.toggle_columns = []
         self.table_tree.connect("row-activated", self.row_activated_cb)
         self.top_bar = None
+        self.tab_name = name
 
         for i, column in enumerate(columns):
-            col = gtk.TreeViewColumn(column['col_name'])
+            col_name = column['col_name']
+            col = gtk.TreeViewColumn(col_name)
             col.set_clickable(True)
             col.set_resizable(True)
-            col.set_sort_column_id(column['col_id'])
+            if self.tab_name.startswith('Included'):
+                if col_name!='Included':
+                    col.set_sort_column_id(column['col_id'])
+            else:
+                col.set_sort_column_id(column['col_id'])
             if 'col_min' in column.keys():
                 col.set_min_width(column['col_min'])
             if 'col_max' in column.keys():
@@ -122,7 +128,7 @@ class HobViewTable (gtk.VBox):
                 self.toggle_id = i
                 col.pack_end(cell, True)
                 col.set_attributes(cell, active=column['col_id'])
-                self.toggle_columns.append(column['col_name'])
+                self.toggle_columns.append(col_name)
                 if 'col_group' in column.keys():
                     col.set_cell_data_func(cell, self.set_group_number_cb)
             elif column['col_style'] == 'radio toggle':
@@ -133,7 +139,7 @@ class HobViewTable (gtk.VBox):
                 self.toggle_id = i
                 col.pack_end(cell, True)
                 col.set_attributes(cell, active=column['col_id'])
-                self.toggle_columns.append(column['col_name'])
+                self.toggle_columns.append(col_name)
             elif column['col_style'] == 'binb':
                 cell = gtk.CellRendererText()
                 col.pack_start(cell, True)

bitbake/lib/bb/ui/crumbs/imagedetailspage.py

@@ -369,6 +369,8 @@ class ImageDetailsPage (HobPage):
         vallist = []
         vallist.append(pkg_num)
         vallist.append(default_image_size)
+        self.builder.configuration.image_size = default_image_size
+        self.builder.configuration.image_packages = self.builder.configuration.selected_packages
         if self.build_succeeded:
             edit_packages_button = HobAltButton("Edit packages")
             edit_packages_button.set_tooltip_text("Edit the packages included in your image")

bitbake/lib/bb/ui/crumbs/packageselectionpage.py

@@ -142,19 +142,16 @@ class PackageSelectionPage (HobPage):
         # append the tab
         for page in self.pages:
             columns = page['columns']
-            tab = HobViewTable(columns)
+            name = page['name']
+            tab = HobViewTable(columns, name)
             search_names.append(page['search'])
             search_tips.append(page['searchtip'])
             filter = page['filter']
-            sort_model = self.package_model.tree_model(filter)
+            sort_model = self.package_model.tree_model(filter, initial=True)
             tab.set_model(sort_model)
-            tab.connect("toggled", self.table_toggled_cb, page['name'])
-            if page['name'] == "Included packages":
-                tab.connect("button-release-event", self.button_click_cb)
-                tab.connect("cell-fadeinout-stopped", self.after_fadeout_checkin_include)
-            if page['name'] == "All packages":
-                tab.connect("button-release-event", self.button_click_cb)
-                tab.connect("cell-fadeinout-stopped", self.after_fadeout_checkin_include)
+            tab.connect("toggled", self.table_toggled_cb, name)
+            tab.connect("button-release-event", self.button_click_cb)
+            tab.connect("cell-fadeinout-stopped", self.after_fadeout_checkin_include, filter)
             self.ins.append_page(tab, page['name'], page['tooltip'])
             self.tables.append(tab)
 
@@ -198,6 +195,7 @@ class PackageSelectionPage (HobPage):
         if self.package_model.filtered_nb == 0:
             if not self.ins.get_nth_page(current_tab).top_bar:
                 self.ins.get_nth_page(current_tab).add_no_result_bar(entry)
+                self.ins.get_nth_page(current_tab).top_bar.set_no_show_all(True)
             self.ins.get_nth_page(current_tab).top_bar.show()
             self.ins.get_nth_page(current_tab).scroll.hide()
         else:
@@ -245,6 +243,13 @@ class PackageSelectionPage (HobPage):
         self.builder.parsing_warnings = []
         self.builder.build_image()
 
+    def refresh_tables(self):
+        self.ins.reset_entry(self.ins.search, 0)
+        for tab in self.tables:
+            index = self.tables.index(tab)
+            filter = self.pages[index]['filter']
+            tab.set_model(self.package_model.tree_model(filter, initial=True))
+
     def back_button_clicked_cb(self, button):
         if self.builder.previous_step ==  self.builder.IMAGE_GENERATED:
             self.builder.restore_initial_selected_packages()
@@ -252,6 +257,7 @@ class PackageSelectionPage (HobPage):
             self.builder.show_image_details()
         else:
             self.builder.show_configuration()
+        self.refresh_tables()
 
     def refresh_selection(self):
         self.builder.configuration.selected_packages = self.package_model.get_selected_packages()
@@ -260,14 +266,17 @@ class PackageSelectionPage (HobPage):
         selected_packages_size = self.package_model.get_packages_size()
         selected_packages_size_str = HobPage._size_to_string(selected_packages_size)
 
-        image_overhead_factor = self.builder.configuration.image_overhead_factor
-        image_rootfs_size = self.builder.configuration.image_rootfs_size / 1024 # image_rootfs_size is KB
-        image_extra_size = self.builder.configuration.image_extra_size / 1024 # image_extra_size is KB
-        base_size = image_overhead_factor * selected_packages_size
-        image_total_size = max(base_size, image_rootfs_size) + image_extra_size
-        if "zypper" in self.builder.configuration.selected_packages:
-            image_total_size += (51200 * 1024)
-        image_total_size_str = HobPage._size_to_string(image_total_size)
+        if self.builder.configuration.image_packages == self.builder.configuration.selected_packages:
+            image_total_size_str = self.builder.configuration.image_size
+        else:
+            image_overhead_factor = self.builder.configuration.image_overhead_factor
+            image_rootfs_size = self.builder.configuration.image_rootfs_size / 1024 # image_rootfs_size is KB
+            image_extra_size = self.builder.configuration.image_extra_size / 1024 # image_extra_size is KB
+            base_size = image_overhead_factor * selected_packages_size
+            image_total_size = max(base_size, image_rootfs_size) + image_extra_size
+            if "zypper" in self.builder.configuration.selected_packages:
+                image_total_size += (51200 * 1024)
+            image_total_size_str = HobPage._size_to_string(image_total_size)
 
         self.label.set_label("Packages included: %s\nSelected packages size: %s\nTotal image size: %s" %
                             (selected_packages_num, selected_packages_size_str, image_total_size_str))
@@ -277,20 +286,21 @@ class PackageSelectionPage (HobPage):
         if not self.package_model.path_included(path):
             self.package_model.include_item(item_path=path, binb="User Selected")
         else:
-            if pagename == "Included packages":
-                self.pre_fadeout_checkout_include(view_tree)
-                self.package_model.exclude_item(item_path=path)
-                self.render_fadeout(view_tree, cell)
-            else:
-                self.package_model.exclude_item(item_path=path)
+            self.pre_fadeout_checkout_include(view_tree)
+            self.package_model.exclude_item(item_path=path)
+            self.render_fadeout(view_tree, cell)
 
         self.refresh_selection()
         if not self.builder.customized:
             self.builder.customized = True
+            self.builder.configuration.initial_selected_image = self.builder.configuration.selected_image
             self.builder.configuration.selected_image = self.recipe_model.__custom_image__
             self.builder.rcppkglist_populated()
 
         self.builder.window_sensitive(True)
+        view_model = view_tree.get_model()
+        vpath = self.package_model.convert_path_to_vpath(view_model, path)
+        view_tree.set_cursor(vpath)
 
     def table_toggled_cb(self, table, cell, view_path, toggled_columnid, view_tree, pagename):
         # Click to include a package
@@ -300,11 +310,15 @@ class PackageSelectionPage (HobPage):
         glib.idle_add(self.toggle_item_idle_cb, path, view_tree, cell, pagename)
 
     def pre_fadeout_checkout_include(self, tree):
+        #after the fadeout the table will be sorted as before
+        self.sort_column_id = self.package_model.sort_column_id
+        self.sort_order = self.package_model.sort_order
+
         self.package_model.resync_fadeout_column(self.package_model.get_iter_first())
         # Check out a model which base on the column COL_FADE_INC,
         # it's save the prev state of column COL_INC before do exclude_item
         filter = { PackageListModel.COL_FADE_INC  : [True]}
-        new_model = self.package_model.tree_model(filter)
+        new_model = self.package_model.tree_model(filter, excluded_items_ahead=True)
         tree.set_model(new_model)
         tree.expand_all()
 
@@ -330,8 +344,10 @@ class PackageSelectionPage (HobPage):
 
         cell.fadeout(tree, 1000, to_render_cells)
 
-    def after_fadeout_checkin_include(self, table, ctrl, cell, tree):
-        tree.set_model(self.package_model.tree_model(self.pages[0]['filter']))
+    def after_fadeout_checkin_include(self, table, ctrl, cell, tree, filter):
+        self.package_model.sort_column_id = self.sort_column_id
+        self.package_model.sort_order = self.sort_order
+        tree.set_model(self.package_model.tree_model(filter))
         tree.expand_all()
 
     def set_packages_curr_tab(self, curr_page):

bitbake/lib/bb/ui/crumbs/recipeselectionpage.py

@@ -154,22 +154,16 @@ class RecipeSelectionPage (HobPage):
         # append the tabs in order
         for page in self.pages:
             columns = page['columns']
-            tab = HobViewTable(columns)
+            name = page['name']
+            tab = HobViewTable(columns, name)
             search_names.append(page['search'])
             search_tips.append(page['searchtip'])
             filter = page['filter']
-            sort_model = self.recipe_model.tree_model(filter)
+            sort_model = self.recipe_model.tree_model(filter, initial=True)
             tab.set_model(sort_model)
-            tab.connect("toggled", self.table_toggled_cb, page['name'])
-            if page['name'] == "Included recipes":
-                tab.connect("button-release-event", self.button_click_cb)
-                tab.connect("cell-fadeinout-stopped", self.after_fadeout_checkin_include)
-            if page['name'] == "Package Groups":
-                tab.connect("button-release-event", self.button_click_cb)
-                tab.connect("cell-fadeinout-stopped", self.after_fadeout_checkin_include)
-            if page['name'] == "All recipes":
-                tab.connect("button-release-event", self.button_click_cb)
-                tab.connect("cell-fadeinout-stopped", self.button_click_cb)
+            tab.connect("toggled", self.table_toggled_cb, name)
+            tab.connect("button-release-event", self.button_click_cb)
+            tab.connect("cell-fadeinout-stopped", self.after_fadeout_checkin_include, filter)
             self.ins.append_page(tab, page['name'], page['tooltip'])
             self.tables.append(tab)
 
@@ -213,6 +207,7 @@ class RecipeSelectionPage (HobPage):
         if self.recipe_model.filtered_nb == 0:
             if not self.ins.get_nth_page(current_tab).top_bar:
                 self.ins.get_nth_page(current_tab).add_no_result_bar(entry)
+                self.ins.get_nth_page(current_tab).top_bar.set_no_show_all(True)
             self.ins.get_nth_page(current_tab).top_bar.show()
             self.ins.get_nth_page(current_tab).scroll.hide()
         else:
@@ -241,15 +236,23 @@ class RecipeSelectionPage (HobPage):
             properties['description'] = tree_model.get_value(tree_model.get_iter(path), RecipeListModel.COL_DESC)
             self.builder.show_recipe_property_dialog(properties)
 
-
     def build_packages_clicked_cb(self, button):
+        self.refresh_tables()
         self.builder.build_packages()
 
+    def refresh_tables(self):
+        self.ins.reset_entry(self.ins.search, 0)
+        for tab in self.tables:
+            index = self.tables.index(tab)
+            filter = self.pages[index]['filter']
+            tab.set_model(self.recipe_model.tree_model(filter, search_data="", initial=True))
+
     def back_button_clicked_cb(self, button):
         self.builder.recipe_model.set_selected_image(self.builder.configuration.initial_selected_image)
         self.builder.image_configuration_page.update_image_combo(self.builder.recipe_model, self.builder.configuration.initial_selected_image)
         self.builder.image_configuration_page.update_image_desc()
         self.builder.show_configuration()
+        self.refresh_tables()
 
     def refresh_selection(self):
         self.builder.configuration.selected_image = self.recipe_model.get_selected_image()
@@ -260,12 +263,9 @@ class RecipeSelectionPage (HobPage):
         if not self.recipe_model.path_included(path):
             self.recipe_model.include_item(item_path=path, binb="User Selected", image_contents=False)
         else:
-            if pagename == "Included recipes":
-                self.pre_fadeout_checkout_include(view_tree)
-                self.recipe_model.exclude_item(item_path=path)
-                self.render_fadeout(view_tree, cell)
-            else:
-                self.recipe_model.exclude_item(item_path=path)
+            self.pre_fadeout_checkout_include(view_tree, pagename)
+            self.recipe_model.exclude_item(item_path=path)
+            self.render_fadeout(view_tree, cell)
 
         self.refresh_selection()
         if not self.builder.customized:
@@ -275,6 +275,10 @@ class RecipeSelectionPage (HobPage):
 
         self.builder.window_sensitive(True)
 
+        view_model = view_tree.get_model()
+        vpath = self.recipe_model.convert_path_to_vpath(view_model, path)
+        view_tree.set_cursor(vpath)
+
     def table_toggled_cb(self, table, cell, view_path, toggled_columnid, view_tree, pagename):
         # Click to include a recipe
         self.builder.window_sensitive(False)
@@ -282,7 +286,11 @@ class RecipeSelectionPage (HobPage):
         path = self.recipe_model.convert_vpath_to_path(view_model, view_path)
         glib.idle_add(self.toggle_item_idle_cb, path, view_tree, cell, pagename)
 
-    def pre_fadeout_checkout_include(self, tree):
+    def pre_fadeout_checkout_include(self, tree, pagename):
+        #after the fadeout the table will be sorted as before
+        self.sort_column_id = self.recipe_model.sort_column_id
+        self.sort_order = self.recipe_model.sort_order
+
         #resync the included items to a backup fade include column
         it = self.recipe_model.get_iter_first()
         while it:
@@ -291,8 +299,14 @@ class RecipeSelectionPage (HobPage):
             it = self.recipe_model.iter_next(it)
         # Check out a model which base on the column COL_FADE_INC,
         # it's save the prev state of column COL_INC before do exclude_item
-        filter = { RecipeListModel.COL_FADE_INC  : [True],
-                   RecipeListModel.COL_TYPE      : ['recipe', 'packagegroup'] }
+        filter = { RecipeListModel.COL_FADE_INC:[True] }
+        if pagename == "Included recipes":
+            filter[RecipeListModel.COL_TYPE] = ['recipe', 'packagegroup']
+        elif pagename == "All recipes":
+            filter[RecipeListModel.COL_TYPE] = ['recipe']
+        else:
+            filter[RecipeListModel.COL_TYPE] = ['packagegroup']
+
         new_model = self.recipe_model.tree_model(filter, excluded_items_ahead=True)
         tree.set_model(new_model)
 
@@ -312,8 +326,10 @@ class RecipeSelectionPage (HobPage):
 
         cell.fadeout(tree, 1000, to_render_cells)
 
-    def after_fadeout_checkin_include(self, table, ctrl, cell, tree):
-        tree.set_model(self.recipe_model.tree_model(self.pages[0]['filter']))
+    def after_fadeout_checkin_include(self, table, ctrl, cell, tree, filter):
+        self.recipe_model.sort_column_id = self.sort_column_id
+        self.recipe_model.sort_order = self.sort_order
+        tree.set_model(self.recipe_model.tree_model(filter))
 
     def set_recipe_curr_tab(self, curr_page):
         self.ins.set_current_page(curr_page)

bitbake/lib/bb/ui/depexp.py

@@ -196,16 +196,18 @@ class gtkthread(threading.Thread):
         gtkthread.quit.set()
 
 
-def main(server, eventHandler):
+def main(server, eventHandler, params):
     try:
-        cmdline, error = server.runCommand(["getCmdLineAction"])
-        if error:
-            print("Error getting bitbake commandline: %s" % error)
-            return 1
-        elif not cmdline:
+        params.updateFromServer(server)
+        cmdline = params.parseActions()
+        if not cmdline:
             print("Nothing to do.  Use 'bitbake world' to build everything, or run 'bitbake --help' for usage information.")
             return 1
-        elif not cmdline or cmdline[0] != "generateDotGraph":
+        if 'msg' in cmdline and cmdline['msg']:
+            logger.error(cmdline['msg'])
+            return 1
+        cmdline = cmdline['action']
+        if not cmdline or cmdline[0] != "generateDotGraph":
             print("This UI is only compatible with the -g option")
             return 1
         ret, error = server.runCommand(["generateDepTreeEvent", cmdline[1], cmdline[2]])

bitbake/lib/bb/ui/goggle.py

@@ -63,7 +63,7 @@ class MainWindow (gtk.Window):
         scrolled_window.add (self.cur_build_tv)
 
 
-def main (server, eventHandler):
+def main (server, eventHandler, params):
     gobject.threads_init()
     gtk.gdk.threads_init()
 
@@ -80,13 +80,15 @@ def main (server, eventHandler):
     running_build.connect ("build-failed", running_build_failed_cb)
 
     try:
-        cmdline, error = server.runCommand(["getCmdLineAction"])
-        if err:
-            print("Error getting bitbake commandline: %s" % error)
-            return 1
-        elif not cmdline:
+        params.updateFromServer(server)
+        cmdline = params.parseActions()
+        if not cmdline:
             print("Nothing to do.  Use 'bitbake world' to build everything, or run 'bitbake --help' for usage information.")
             return 1
+        if 'msg' in cmdline and cmdline['msg']:
+            logger.error(cmdline['msg'])
+            return 1
+        cmdline = cmdline['action']
         ret, error = server.runCommand(cmdline)
         if error:
             print("Error running command '%s': %s" % (cmdline, error))

bitbake/lib/bb/ui/hob.py

@@ -58,7 +58,8 @@ def event_handle_idle_func(eventHandler, hobHandler):
         event = eventHandler.getEvent()
     return True
 
-def main (server = None, eventHandler = None):
+def main (server, eventHandler, params):
+    params.updateFromServer(server)
     gobject.threads_init()
 
     # That indicates whether the Hob and the bitbake server are

bitbake/lib/bb/ui/knotty.py

@@ -201,11 +201,11 @@ class TerminalFilter(object):
             content = "No currently running tasks (%s of %s)" % (self.helper.tasknumber_current, self.helper.tasknumber_total)
         else:
             content = "Currently %s running tasks (%s of %s):" % (len(activetasks), self.helper.tasknumber_current, self.helper.tasknumber_total)
-        print content
+        print(content)
         lines = 1 + int(len(content) / (self.columns + 1))
         for tasknum, task in enumerate(tasks):
             content = "%s: %s" % (tasknum, task)
-            print content
+            print(content)
             lines = lines + 1 + int(len(content) / (self.columns + 1))
         self.footer_present = lines
         self.lastpids = runningpids[:]
@@ -216,7 +216,7 @@ class TerminalFilter(object):
             fd = sys.stdin.fileno()
             self.termios.tcsetattr(fd, self.termios.TCSADRAIN, self.stdinbackup)
 
-def main(server, eventHandler, tf = TerminalFilter):
+def main(server, eventHandler, params, tf = TerminalFilter):
 
     # Get values of variables which control our output
     includelogs, error = server.runCommand(["getVariable", "BBINCLUDELOGS"])
@@ -245,7 +245,8 @@ def main(server, eventHandler, tf = TerminalFilter):
     bb.msg.addDefaultlogFilter(console)
     console.setFormatter(format)
     logger.addHandler(console)
-    if consolelogfile:
+
+    if consolelogfile and not params.options.show_environment:
         bb.utils.mkdirhier(os.path.dirname(consolelogfile))
         conlogformat = bb.msg.BBLogFormatter(format_str)
         consolelog = logging.FileHandler(consolelogfile)
@@ -254,14 +255,16 @@ def main(server, eventHandler, tf = TerminalFilter):
         logger.addHandler(consolelog)
 
     try:
-        cmdline, error = server.runCommand(["getCmdLineAction"])
-        if error:
-            logger.error("Unable to get bitbake commandline arguments: %s" % error)
-            return 1
-        elif not cmdline:
+        params.updateFromServer(server)
+        cmdline = params.parseActions()
+        if not cmdline:
             print("Nothing to do.  Use 'bitbake world' to build everything, or run 'bitbake --help' for usage information.")
             return 1
-        ret, error = server.runCommand(cmdline)
+        if 'msg' in cmdline and cmdline['msg']:
+            logger.error(cmdline['msg'])
+            return 1
+
+        ret, error = server.runCommand(cmdline['action'])
         if error:
             logger.error("Command '%s' failed: %s" % (cmdline, error))
             return 1
@@ -300,7 +303,7 @@ def main(server, eventHandler, tf = TerminalFilter):
                 if log_exec_tty:
                     tries = event.retries
                     while tries:
-                        print "Trying to run: %s" % event.prog
+                        print("Trying to run: %s" % event.prog)
                         if os.system(event.prog) == 0:
                             break
                         time.sleep(event.sleep_delay)

bitbake/lib/bb/ui/ncurses.py

@@ -196,7 +196,7 @@ class NCursesUI:
 #            t.start()
 
     #-------------------------------------------------------------------------#
-    def main(self, stdscr, server, eventHandler):
+    def main(self, stdscr, server, eventHandler, params):
     #-------------------------------------------------------------------------#
         height, width = stdscr.getmaxyx()
 
@@ -236,13 +236,15 @@ class NCursesUI:
         shutdown = 0
 
         try:
-            cmdline, error = server.runCommand(["getCmdLineAction"])
+            params.updateFromServer(server)
+            cmdline = params.parseActions()
             if not cmdline:
                 print("Nothing to do.  Use 'bitbake world' to build everything, or run 'bitbake --help' for usage information.")
-                return
-            elif error:
-                print("Error getting bitbake commandline: %s" % error)
-                return
+                return 1
+            if 'msg' in cmdline and cmdline['msg']:
+                logger.error(cmdline['msg'])
+                return 1
+            cmdline = cmdline['action']
             ret, error = server.runCommand(cmdline)
             if error:
                 print("Error running command '%s': %s" % (cmdline, error))

bitbake/lib/bb/utils.py

@@ -27,17 +27,31 @@ import bb
 import bb.msg
 import multiprocessing
 import fcntl
+import subprocess
+import glob
+import traceback
+import errno
 from commands import getstatusoutput
 from contextlib import contextmanager
 
 logger = logging.getLogger("BitBake.Util")
 
+def clean_context():
+    return {
+        "os": os,
+        "bb": bb,
+        "time": time,
+    }
+
+def get_context():
+    return _context
+    
+
+def set_context(ctx):
+    _context = ctx
+
 # Context used in better_exec, eval
-_context = {
-    "os": os,
-    "bb": bb,
-    "time": time,
-}
+_context = clean_context()
 
 def explode_version(s):
     r = []
@@ -236,14 +250,16 @@ def _print_trace(body, line):
     """
     Print the Environment of a Text Body
     """
+    error = []
     # print the environment of the method
     min_line = max(1, line-4)
     max_line = min(line + 4, len(body))
-    for i in xrange(min_line, max_line + 1):
+    for i in range(min_line, max_line + 1):
         if line == i:
-            logger.error(' *** %.4d:%s', i, body[i-1])
+            error.append(' *** %.4d:%s' % (i, body[i-1].rstrip()))
         else:
-            logger.error('     %.4d:%s', i, body[i-1])
+            error.append('     %.4d:%s' % (i, body[i-1].rstrip()))
+    return error
 
 def better_compile(text, file, realfile, mode = "exec"):
     """
@@ -253,22 +269,78 @@ def better_compile(text, file, realfile, mode = "exec"):
     try:
         return compile(text, file, mode)
     except Exception as e:
+        error = []
         # split the text into lines again
         body = text.split('\n')
-        logger.error("Error in compiling python function in %s", realfile)
-        logger.error(str(e))
+        error.append("Error in compiling python function in %s:\n" % realfile)
         if e.lineno:
-            logger.error("The lines leading to this error were:")
-            logger.error("\t%d:%s:'%s'", e.lineno, e.__class__.__name__, body[e.lineno-1])
-            _print_trace(body, e.lineno)
+            error.append("The code lines resulting in this error were:")
+            error.extend(_print_trace(body, e.lineno))
         else:
-            logger.error("The function causing this error was:")
+            error.append("The function causing this error was:")
             for line in body:
-                logger.error(line)
+                error.append(line)
+        error.append("%s: %s" % (e.__class__.__name__, str(e)))
+
+        logger.error("\n".join(error))
 
         e = bb.BBHandledException(e)
         raise e
 
+def _print_exception(t, value, tb, realfile, text, context):
+    error = []
+    try:
+        exception = traceback.format_exception_only(t, value)
+        error.append('Error executing a python function in %s:\n' % realfile)
+
+        # Strip 'us' from the stack (better_exec call)
+        tb = tb.tb_next
+
+        textarray = text.split('\n')
+
+        linefailed = tb.tb_lineno
+
+        tbextract = traceback.extract_tb(tb)
+        tbformat = traceback.format_list(tbextract)
+        error.append("The stack trace of python calls that resulted in this exception/failure was:")
+        error.append("File: '%s', lineno: %s, function: %s" % (tbextract[0][0], tbextract[0][1], tbextract[0][2]))
+        error.extend(_print_trace(textarray, linefailed))
+
+        # See if this is a function we constructed and has calls back into other functions in
+        # "text". If so, try and improve the context of the error by diving down the trace
+        level = 0
+        nexttb = tb.tb_next
+        while nexttb is not None and (level+1) < len(tbextract):
+            error.append("File: '%s', lineno: %s, function: %s" % (tbextract[level+1][0], tbextract[level+1][1], tbextract[level+1][2]))
+            if tbextract[level][0] == tbextract[level+1][0] and tbextract[level+1][2] == tbextract[level][0]:
+                # The code was possibly in the string we compiled ourselves
+                error.extend(_print_trace(textarray, tbextract[level+1][1]))
+            elif tbextract[level+1][0].startswith("/"):
+                # The code looks like it might be in a file, try and load it
+                try:
+                    with open(tbextract[level+1][0], "r") as f:
+                        text = f.readlines()
+                        error.extend(_print_trace(text, tbextract[level+1][1]))
+                except:
+                    error.append(tbformat[level+1])
+            elif "d" in context and tbextract[level+1][2]:
+                # Try and find the code in the datastore based on the functionname
+                d = context["d"]
+                functionname = tbextract[level+1][2]
+                text = d.getVar(functionname, True)
+                if text:
+                    error.extend(_print_trace(text.split('\n'), tbextract[level+1][1]))
+                else:
+                    error.append(tbformat[level+1])
+            else:
+                error.append(tbformat[level+1])
+            nexttb = tb.tb_next
+            level = level + 1
+
+        error.append("Exception: %s" % ''.join(exception))
+    finally:
+        logger.error("\n".join(error))
+
 def better_exec(code, context, text = None, realfile = "<code>"):
     """
     Similiar to better_compile, better_exec will
@@ -281,64 +353,25 @@ def better_exec(code, context, text = None, realfile = "<code>"):
     if not hasattr(code, "co_filename"):
         code = better_compile(code, realfile, realfile)
     try:
-        exec(code, _context, context)
+        exec(code, get_context(), context)
     except Exception as e:
         (t, value, tb) = sys.exc_info()
 
         if t in [bb.parse.SkipPackage, bb.build.FuncFailed]:
             raise
-
-        import traceback
-        exception = traceback.format_exception_only(t, value)
-        logger.error('Error executing a python function in %s:\n%s',
-                     realfile, ''.join(exception))
-
-        # Strip 'us' from the stack (better_exec call)
-        tb = tb.tb_next
-
-        textarray = text.split('\n')
-        linefailed = traceback.tb_lineno(tb)
-
-        tbextract = traceback.extract_tb(tb)
-        tbformat = "\n".join(traceback.format_list(tbextract))
-        logger.error("The stack trace of python calls that resulted in this exception/failure was:")
-        for line in tbformat.split('\n'):
-            logger.error(line)
-
-        logger.error("The code that was being executed was:")
-        _print_trace(textarray, linefailed)
-        logger.error("[From file: '%s', lineno: %s, function: %s]", tbextract[0][0], tbextract[0][1], tbextract[0][2])
-
-        # See if this is a function we constructed and has calls back into other functions in
-        # "text". If so, try and improve the context of the error by diving down the trace
-        level = 0
-        nexttb = tb.tb_next
-        while nexttb is not None and (level+1) < len(tbextract):
-            if tbextract[level][0] == tbextract[level+1][0] and tbextract[level+1][2] == tbextract[level][0]:
-                _print_trace(textarray, tbextract[level+1][1])
-                logger.error("[From file: '%s', lineno: %s, function: %s]", tbextract[level+1][0], tbextract[level+1][1], tbextract[level+1][2])
-            elif "d" in context and tbextract[level+1][2]:
-                d = context["d"]
-                functionname = tbextract[level+1][2]
-                text = d.getVar(functionname, True)
-                if text:
-                    _print_trace(text.split('\n'), tbextract[level+1][1])
-                    logger.error("[From file: '%s', lineno: %s, function: %s]", tbextract[level+1][0], tbextract[level+1][1], tbextract[level+1][2])
-                else:
-                    break
-            else:
-                 break
-            nexttb = tb.tb_next
-            level = level + 1
+        try:
+            _print_exception(t, value, tb, realfile, text, context)
+        except Exception as e:
+            logger.error("Exception handler error: %s" % str(e))
 
         e = bb.BBHandledException(e)
         raise e
 
 def simple_exec(code, context):
-    exec(code, _context, context)
+    exec(code, get_context(), context)
 
 def better_eval(source, locals):
-    return eval(source, _context, locals)
+    return eval(source, get_context(), locals)
 
 @contextmanager
 def fileslocked(files):
@@ -394,6 +427,10 @@ def lockfile(name, shared=False, retry=True):
                     return lf
             lf.close()
         except Exception:
+            try:
+                lf.close()
+            except Exception:
+                pass
             pass
         if not retry:
             return None
@@ -423,8 +460,9 @@ def md5_file(filename):
         import md5
         m = md5.new()
 
-    for line in open(filename):
-        m.update(line)
+    with open(filename, "rb") as f:
+        for line in f:
+            m.update(line)
     return m.hexdigest()
 
 def sha256_file(filename):
@@ -440,8 +478,9 @@ def sha256_file(filename):
         return None
 
     s = hashlib.sha256()
-    for line in open(filename):
-        s.update(line)
+    with open(filename, "rb") as f:
+        for line in f:
+            s.update(line)
     return s.hexdigest()
 
 def preserved_envvars_exported():
@@ -539,11 +578,9 @@ def remove(path, recurse=False):
     if not path:
         return
     if recurse:
-        import subprocess, glob
         # shutil.rmtree(name) would be ideal but its too slow
         subprocess.call(['rm', '-rf'] + glob.glob(path))
         return
-    import os, errno, glob
     for name in glob.glob(path):
         try:
             os.unlink(name)

bitbake/lib/prserv/__init__.py

@@ -10,5 +10,5 @@ def init_logger(logfile, loglevel):
     FORMAT = '%(asctime)-15s %(message)s'
     logging.basicConfig(level=numeric_level, filename=logfile, format=FORMAT)
 
-class NotFoundError(StandardError):
+class NotFoundError(Exception):
     pass

bitbake/lib/prserv/serv.py

@@ -183,7 +183,7 @@ class PRServerConnection():
             host, port = singleton.getinfo()
         self.host = host
         self.port = port
-        self.connection = bb.server.xmlrpc._create_server(self.host, self.port)
+        self.connection, self.transport = bb.server.xmlrpc._create_server(self.host, self.port)
 
     def terminate(self):
         # Don't wait for server indefinitely
@@ -263,6 +263,9 @@ def is_local_special(host, port):
     else:
         return False
 
+class PRServiceConfigError(Exception):
+    pass
+
 def auto_start(d):
     global singleton
 
@@ -273,14 +276,14 @@ def auto_start(d):
     if len(host_params) != 2:
         logger.critical('\n'.join(['PRSERV_HOST: incorrect format',
                 'Usage: PRSERV_HOST = "<hostname>:<port>"']))
-        return True
+        raise PRServiceConfigError
 
     if is_local_special(host_params[0], int(host_params[1])) and not singleton:
         import bb.utils
         cachedir = (d.getVar("PERSISTENT_DIR", True) or d.getVar("CACHE", True))
         if not cachedir:
             logger.critical("Please set the 'PERSISTENT_DIR' or 'CACHE' variable")
-            sys.exit(1)
+            raise PRServiceConfigError
         bb.utils.mkdirhier(cachedir)
         dbfile = os.path.join(cachedir, "prserv.sqlite3")
         logfile = os.path.join(cachedir, "prserv.log")
@@ -296,7 +299,7 @@ def auto_start(d):
         return PRServerConnection(host,port).ping()
     except Exception:
         logger.critical("PRservice %s:%d not available" % (host, port))
-    return False
+        raise PRServiceConfigError
 
 def auto_shutdown(d=None):
     global singleton

documentation/adt-manual/adt-command.xml

@@ -95,7 +95,7 @@
                     <literallayout class='monospaced'>
      $ source /opt/poky/&DISTRO;/environment-setup-i586-poky-linux
                     </literallayout></para></listitem>
-                <listitem><para><emphasis>Generate the local <filename>aclocal.m4</filename>
+                <listitem><para><emphasis>Generate the local aclocal.m4
                     files and create the configure script:</emphasis>
                     The following GNU Autotools generate the local
                     <filename>aclocal.m4</filename> files and create the
@@ -112,7 +112,7 @@
                     <literallayout class='monospaced'>
      $ touch NEWS README AUTHORS ChangeLog
                     </literallayout></para></listitem>
-                <listitem><para><emphasis>Generate the <filename>configure</filename>
+                <listitem><para><emphasis>Generate the configure
                     file:</emphasis>
                     This command generates the <filename>configure</filename>:
                     <literallayout class='monospaced'>

documentation/adt-manual/adt-intro.xml

@@ -19,7 +19,8 @@
     how to access and use the cross-development toolchains, how to
     customize the development packages installation,
     how to use command line development for both Autotools-based and Makefile-based projects,
-    and an introduction to the Eclipse Yocto Plug-in.
+    and an introduction to the <trademark class='trade'>Eclipse</trademark> IDE
+    Yocto Plug-in.
     <note>
         The ADT is distribution-neutral and does not require the Yocto 
         Project reference distribution, which is called Poky.  
@@ -42,7 +43,9 @@
         <itemizedlist>
             <listitem><para>An architecture-specific cross-toolchain and matching
                 sysroot both built by the OpenEmbedded build system.
-                The toolchain and sysroot are based on a metadata configuration and extensions,
+                The toolchain and sysroot are based on a 
+                <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
+                configuration and extensions,
                 which allows you to cross-develop on the host machine for the target hardware.
                 </para></listitem>
             <listitem><para>The Eclipse IDE Yocto Plug-in.</para></listitem>
@@ -65,7 +68,7 @@
             This toolchain is created either by running the ADT Installer
             script, a toolchain installer script, or through a
             <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
-            that is based on your metadata configuration or extension for
+            that is based on your Metadata configuration or extension for
             your targeted device.
             The cross-toolchain works with a matching target sysroot.
         </para>
@@ -78,7 +81,7 @@
             The matching target sysroot contains needed headers and libraries for generating
             binaries that run on the target architecture.
             The sysroot is based on the target root filesystem image that is built by
-            the OpenEmbedded build system and uses the same metadata configuration
+            the OpenEmbedded build system and uses the same Metadata configuration
             used to build the cross-toolchain.
         </para>
     </section>
@@ -127,7 +130,7 @@
                     the environment setup script, QEMU is installed and automatically
                     available.</para></listitem>
                 <listitem><para>If you have installed the cross-toolchain
-                    tarball and you have sourcing the toolchain's setup environment script, QEMU
+                    tarball and you have sourced the toolchain's setup environment script, QEMU
                     is also installed and automatically available.</para></listitem>
             </itemizedlist>
         </para>
@@ -147,7 +150,7 @@
                     stutters in your desktop experience, or situations that overload your server
                     even when you have plenty of CPU power left.
                     You can find out more about LatencyTOP at
-                    <ulink url='http://www.latencytop.org/'></ulink>.</para></listitem>
+                    <ulink url='https://latencytop.org/'></ulink>.</para></listitem>
                 <listitem><para><emphasis>PowerTOP:</emphasis> Helps you determine what
                     software is using the most power.
                     You can find out more about PowerTOP at

documentation/adt-manual/adt-manual.xml

@@ -61,7 +61,12 @@
                 <date>April 2013</date>
                 <revremark>Released with the Yocto Project 1.4 Release.</revremark>
             </revision>
-        </revhistory>
+            <revision>
+                <revnumber>1.5</revnumber>
+                <date>Sometime in 2013</date>
+                <revremark>Released with the Yocto Project 1.5 Release.</revremark>
+            </revision>
+       </revhistory>
 
     <copyright>
       <year>&COPYRIGHT_YEAR;</year>

documentation/adt-manual/adt-package.xml

@@ -55,9 +55,9 @@
     </para>
 
     <note>
-        For build performance information related to the PMS, see
-        <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-package'>Packaging - <filename>package*.bbclass</filename></ulink>
-        in the Yocto Project Reference Manual.
+        For build performance information related to the PMS, see the
+        "<ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-package'>Packaging - <filename>package*.bbclass</filename></ulink>" 
+        section in the Yocto Project Reference Manual.
     </note>
 
     <para>

documentation/adt-manual/adt-prepare.xml

@@ -39,18 +39,18 @@
 
     <para>
         <itemizedlist>
-            <listitem><para><emphasis>Use the ADT Installer Script:</emphasis>
+            <listitem><para><emphasis>Use the ADT installer script:</emphasis>
                 This method is the recommended way to install the ADT because it
                 automates much of the process for you.
                 For example, you can configure the installation to install the QEMU emulator
                 and the user-space NFS, specify which root filesystem profiles to download,
                 and define the target sysroot location.</para></listitem>
-            <listitem><para><emphasis>Use an Existing Toolchain:</emphasis>
+            <listitem><para><emphasis>Use an existing toolchain:</emphasis>
                 Using this method, you select and download an architecture-specific
                 toolchain installer and then run the script to hand-install the toolchain.
                 If you use this method, you just get the cross-toolchain and QEMU - you do not
                 get any of the other mentioned benefits had you run the ADT Installer script.</para></listitem>
-            <listitem><para><emphasis>Use the Toolchain from within the Build Directory:</emphasis>
+            <listitem><para><emphasis>Use the toolchain from within the Build Directory:</emphasis>
                 If you already have a
                 <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>,
                 you can build the cross-toolchain within the directory.
@@ -91,16 +91,16 @@
             <para>
                 If you use BitBake to generate the ADT Installer tarball, you must
                 <filename>source</filename> the environment setup script
-                (<filename>&OE_INIT_FILE;</filename>) located
-                in the Source Directory before running the <filename>bitbake</filename>
-                command that creates the tarball.
+                (<ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>) 
+                located in the Source Directory before running the 
+                BitBake command that creates the tarball.
             </para>
 
             <para>
                 The following example commands download the Poky tarball, set up the
                 <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>,
                 set up the environment while also creating the default Build Directory,
-                and run the <filename>bitbake</filename> command that results in the tarball
+                and run the BitBake command that results in the tarball
                 <filename>~/yocto-project/build/tmp/deploy/sdk/adt_installer.tar.bz2</filename>:
                 <literallayout class='monospaced'>
      $ cd ~
@@ -293,7 +293,7 @@
                         variable is correctly set if you are building
                         a toolchain for an architecture that differs from your
                         current development host machine.</para>
-                        <para>When the <filename>bitbake</filename> command
+                        <para>When the BitBake command
                         completes, the toolchain installer will be in
                         <filename>tmp/deploy/sdk</filename> in the Build
                         Directory.</para>
@@ -326,7 +326,7 @@
             A final way of making the cross-toolchain available is to use BitBake
             to generate the toolchain within an existing
             <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
-            This method does not install the toolchain into the
+            This method does not install the toolchain into the default
             <filename>/opt</filename> directory.
             As with the previous method, if you need to install the target sysroot, you must
             do that separately as well.
@@ -355,11 +355,11 @@
                     cross-toolchain generation.
                     <note>If you change out of your working directory after you
                         <filename>source</filename> the environment setup script and before you run
-                        the <filename>bitbake</filename> command, the command might not work.
-                        Be sure to run the <filename>bitbake</filename> command immediately
+                        the BitBake command, the command might not work.
+                        Be sure to run the BitBake command immediately
                         after checking or editing the <filename>local.conf</filename> but without
                         changing out of your working directory.</note>
-                    Once the <filename>bitbake</filename> command finishes,
+                    Once the BitBake command finishes,
                     the cross-toolchain is generated and populated within the Build Directory.
                     You will notice environment setup files for the cross-toolchain in the
                     Build Directory in the <filename>tmp</filename> directory.
@@ -393,7 +393,7 @@
     <para>
         Be sure to run the environment setup script that matches the architecture for
         which you are developing.
-        Environment setup scripts begin with the string “<filename>environment-setup</filename>”
+        Environment setup scripts begin with the string "<filename>environment-setup</filename>"
         and include as part of their name the architecture.
         For example, the toolchain environment setup script for a 64-bit
         IA-based architecture installed in the default installation directory
@@ -442,8 +442,8 @@
         <para>
             If you are planning on developing against your image and you are not
             building or using one of the Yocto Project development images
-            (e.g. core-image-*-dev), you must be sure to include the development
-            packages as part of your image recipe.
+            (e.g. <filename>core-image-*-dev</filename>), you must be sure to
+            include the development packages as part of your image recipe.
         </para>
 
         <para>

documentation/bsp-guide/bsp-guide.xml

@@ -73,6 +73,11 @@
                 <date>April 2013</date>
                 <revremark>Released with the Yocto Project 1.4 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>1.5</revnumber>
+                <date>Sometime in 2013</date>
+                <revremark>Released with the Yocto Project 1.5 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>

documentation/bsp-guide/bsp.xml

@@ -34,11 +34,13 @@
                 The BSP consists of a file structure inside a base directory.
                 Collectively, you can think of the base directory and the file structure
                 as a BSP Layer.
-                BSP Layers use the following naming convention:
+                Although not a strict requirement, layers in the Yocto Project use the
+                following well established naming convention:
                 <literallayout class='monospaced'>
      meta-&lt;bsp_name&gt;
                 </literallayout>
-                "bsp_name" is a placeholder for the machine or platform name.
+                The string "meta-" is prepended to the machine or platform name, which is
+                "bsp_name" in the above form.
             </para>
 
             <para>
@@ -52,7 +54,7 @@
                 definition and from it build an image.
                 Here is an example:
                 <literallayout class='monospaced'>
-     BBLAYERS = ?" \
+     BBLAYERS ?= " \
        /usr/local/src/yocto/meta \
        /usr/local/src/yocto/meta-yocto \
        /usr/local/src/yocto/meta-yocto-bsp \
@@ -185,10 +187,13 @@
      meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay-noemgd/xorg.conf
      meta-crownbay/recipes-kernel/
      meta-crownbay/recipes-kernel/linux/
-     meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend
-     meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.4.bbappend
      meta-crownbay/recipes-kernel/linux/linux-yocto_3.2.bbappend
      meta-crownbay/recipes-kernel/linux/linux-yocto_3.4.bbappend
+     meta-crownbay/recipes-kernel/linux/linux-yocto_3.8.bbappend
+     meta-crownbay/recipes-kernel/linux/linux-yocto-dev.bbappend
+     meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend
+     meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.4.bbappend
+     meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.8.bbappend
                 </literallayout>
             </para>
 
@@ -256,8 +261,9 @@
                 This file provides information on where to locate the BSP source files.
                 For example, information provides where to find the sources that comprise
                 the images shipped with the BSP.
-                Information is also included to help you find the metadata used to generate the images
-                that ship with the BSP.
+                Information is also included to help you find the
+                <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
+                used to generate the images that ship with the BSP.
             </para>
             </section>
 
@@ -273,7 +279,7 @@
             <para>
                 This optional area contains useful pre-built kernels and user-space filesystem
                 images appropriate to the target system.
-                This directory typically contains graphical (e.g. sato) and minimal live images
+                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
@@ -314,9 +320,9 @@
      # We have a conf and classes directory, add to BBPATH
      BBPATH .= ":${LAYERDIR}"
 
-     # We have recipes-* directories, add to BBFILES
-     BBFILES += "${LAYERDIR}/recipes-*/*.bb \
-                 ${LAYERDIR}/recipes-*/*.bbappend"
+     # We have a recipes directory, add to BBFILES
+     BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
+             ${LAYERDIR}/recipes-*/*/*.bbappend"
 
      BBFILE_COLLECTIONS += "bsp"
      BBFILE_PATTERN_bsp = "^${LAYERDIR}/"
@@ -325,8 +331,8 @@
             </para>
 
             <para>
-                To illustrate the string substitutions, here are the last three statements from the Crown
-                Bay <filename>conf/layer.conf</filename> file:
+                To illustrate the string substitutions, here are the corresponding statements
+                from the Crown Bay <filename>conf/layer.conf</filename> file:
                <literallayout class='monospaced'>
      BBFILE_COLLECTIONS += "crownbay"
      BBFILE_PATTERN_crownbay = "^${LAYERDIR}/"
@@ -376,9 +382,9 @@
                 The <filename>crownbay.conf</filename> file is used for the Crown Bay BSP
                 that supports the <trademark class='registered'>Intel</trademark> Embedded
                 Media and Graphics Driver (<trademark class='registered'>Intel</trademark>
-                EMGD), while the <filename>crownbay-noemgd.conf</filename> file is used for the
-                Crown Bay BSP that does not support the <trademark class='registered'>Intel</trademark>
-                EMGD.
+                EMGD), while the <filename>crownbay-noemgd</filename> file is used for the
+                Crown Bay BSP that supports Video Electronics Standards Association (VESA)
+                graphics only.
             </para>
 
             <para>
@@ -393,9 +399,8 @@
                 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>.
-                Tuning files can also reside in the BSP Layer itself.
                 For example, the <filename>ia32-base.inc</filename> file resides in the
-                <filename>meta-intel</filename> BSP Layer in <filename>conf/machine/include</filename>.
+                <filename>meta/conf/machine/include</filename> directory.
             </para>
 
             <para>
@@ -405,12 +410,13 @@
                 <literallayout class='monospaced'>
      require conf/machine/include/tune-atom.inc
      require conf/machine/include/ia32-base.inc
+     require conf/machine/include/meta-intel.inc
                 </literallayout>
             </para>
             </section>
 
             <section id='bsp-filelayout-misc-recipes'>
-            <title>Miscellaneous Recipe Files</title>
+            <title>Miscellaneous BSP-Specific Recipe Files</title>
             <para>
                 You can find these files in the BSP Layer at:
                 <literallayout class='monospaced'>
@@ -496,28 +502,28 @@
                 the <filename>meta-&lt;bsp_name&gt;/recipes-kernel/linux</filename> directory).
             </para>
             <para>
-                Suppose you are using the <filename>linux-yocto_3.4.bb</filename> recipe to build
+                Suppose you are using the <filename>linux-yocto_3.8.bb</filename> recipe to build
                 the kernel.
                 In other words, you have selected the kernel in your
                 <filename>&lt;bsp_name&gt;.conf</filename> file by adding these types
                 of statements:
                 <literallayout class='monospaced'>
      PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
-     PREFERRED_VERSION_linux-yocto = "3.4%"
+     PREFERRED_VERSION_linux-yocto ?= "3.8%"
                 </literallayout>
                 <note>
                     When the preferred provider is assumed by default, the
                     <filename>PREFERRED_PROVIDER</filename> statement does not appear in the
                     <filename>&lt;bsp_name&gt;.conf</filename> file.
                 </note>
-                You would use the <filename>linux-yocto_3.4.bbappend</filename> file to append
+                You would use the <filename>linux-yocto_3.8.bbappend</filename> file to append
                 specific BSP settings to the kernel, thus configuring the kernel for your particular BSP.
             </para>
             <para>
                 As an example, look at the existing Crown Bay BSP.
                 The append file used is:
                 <literallayout class='monospaced'>
-     meta-crownbay/recipes-kernel/linux/linux-yocto_3.4.bbappend
+     meta-crownbay/recipes-kernel/linux/linux-yocto_3.8.bbappend
                 </literallayout>
                 The following listing shows the file.
                 Be aware that the actual commit ID strings in this example listing might be different
@@ -527,40 +533,43 @@
      FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
 
      COMPATIBLE_MACHINE_crownbay = "crownbay"
-     KMACHINE_crownbay  = "crownbay"
-     KBRANCH_crownbay  = "standard/crownbay"
+     KMACHINE_crownbay = "crownbay"
+     KBRANCH_crownbay = "standard/crownbay"
+     KERNEL_FEATURES_crownbay_append = " features/drm-emgd/drm-emgd-1.16 cfg/vesafb"
 
      COMPATIBLE_MACHINE_crownbay-noemgd = "crownbay-noemgd"
-     KMACHINE_crownbay-noemgd  = "crownbay"
-     KBRANCH_crownbay-noemgd  = "standard/crownbay"
+     KMACHINE_crownbay-noemgd = "crownbay"
+     KBRANCH_crownbay-noemgd = "standard/crownbay"
+     KERNEL_FEATURES_crownbay-noemgd_append = " cfg/vesafb"
 
-     SRCREV_machine_pn-linux-yocto_crownbay ?= "449f7f520350700858f21a5554b81cc8ad23267d"
-     SRCREV_meta_pn-linux-yocto_crownbay ?= "9e3bdb7344054264b750e53fbbb6394cc1c942ac"
-     SRCREV_emgd_pn-linux-yocto_crownbay ?= "86643bdd8cbad616a161ab91f51108cf0da827bc"
+     LINUX_VERSION = "3.8.4"
 
-     SRCREV_machine_pn-linux-yocto_crownbay-noemgd ?= "449f7f520350700858f21a5554b81cc8ad23267d"
-     SRCREV_meta_pn-linux-yocto_crownbay-noemgd ?= "9e3bdb7344054264b750e53fbbb6394cc1c942ac"
+     SRCREV_meta_crownbay = "2a6d36e75ca0a121570a389d7bab76ec240cbfda"
+     SRCREV_machine_crownbay = "47aed0c17c1c55988198ad39f86ae88894c8e0a4"
+     SRCREV_emgd_crownbay = "c780732f175ff0ec866fac2130175876b519b576"
 
-     KSRC_linux_yocto_3_4 ?= "git.yoctoproject.org/linux-yocto-3.4.git"
-     SRC_URI_crownbay = "git://git.yoctoproject.org/linux-yocto-3.4.git;protocol=git;nocheckout=1;branch=${KBRANCH},meta,emgd-1.14;name=machine,meta,emgd"
-     SRC_URI_crownbay-noemgd = "git://git.yoctoproject.org/linux-yocto-3.4.git;protocol=git;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"
+     SRCREV_meta_crownbay-noemgd = "2a6d36e75ca0a121570a389d7bab76ec240cbfda"
+     SRCREV_machine_crownbay-noemgd = "47aed0c17c1c55988198ad39f86ae88894c8e0a4"
+
+     SRC_URI_crownbay = "git://git.yoctoproject.org/linux-yocto-3.8.git;protocol=git;nocheckout=1;branch=${KBRANCH},${KMETA},emgd-1.16;name=machine,meta,emgd"
                 </literallayout>
                 This append file contains statements used to support the Crown Bay BSP for both
                 <trademark class='registered'>Intel</trademark> EMGD and the VESA graphics.
                 The build process, in this case, recognizes and uses only the statements that
                 apply to the defined machine name - <filename>crownbay</filename> in this case.
-                So, the applicable statements in the <filename>linux-yocto_3.4.bbappend</filename>
+                So, the applicable statements in the <filename>linux-yocto_3.8.bbappend</filename>
                 file are follows:
                 <literallayout class='monospaced'>
      FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
 
      COMPATIBLE_MACHINE_crownbay = "crownbay"
-     KMACHINE_crownbay  = "crownbay"
-     KBRANCH_crownbay  = "standard/crownbay"
+     KMACHINE_crownbay = "crownbay"
+     KBRANCH_crownbay = "standard/crownbay"
+     KERNEL_FEATURES_crownbay_append = " features/drm-emgd/drm-emgd-1.16 cfg/vesafb"
 
-     SRCREV_machine_pn-linux-yocto_crownbay ?= "449f7f520350700858f21a5554b81cc8ad23267d"
-     SRCREV_meta_pn-linux-yocto_crownbay ?= "9e3bdb7344054264b750e53fbbb6394cc1c942ac"
-     SRCREV_emgd_pn-linux-yocto_crownbay ?= "86643bdd8cbad616a161ab91f51108cf0da827bc"
+     SRCREV_meta_crownbay = "2a6d36e75ca0a121570a389d7bab76ec240cbfda"
+     SRCREV_machine_crownbay = "47aed0c17c1c55988198ad39f86ae88894c8e0a4"
+     SRCREV_emgd_crownbay = "c780732f175ff0ec866fac2130175876b519b576"
                 </literallayout>
                 The append file defines <filename>crownbay</filename> as the
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-COMPATIBLE_MACHINE'><filename>COMPATIBLE_MACHINE</filename></ulink>
@@ -570,8 +579,11 @@
                 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 <filename>standard/default/crownbay</filename>
+                to ensure the build process uses the <filename>standard/crownbay</filename>
                 kernel branch.
+                The
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-KERNEL_FEATURES'><filename>KERNEL_FEATURES</filename></ulink>
+                variable enables features specific to the kernel.
                 Finally, 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
@@ -597,7 +609,7 @@
             </para>
 
             <para>
-                For example, suppose you had a some configuration options in a file called
+                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.
@@ -662,8 +674,8 @@
             <para>
                 Certain requirements exist for a released BSP to be considered
                 compliant with the Yocto Project.
-                Additionally, a single recommendation also exists.
-                This section describes the requirements and recommendation for
+                Additionally, recommendations also exist.
+                This section describes the requirements and recommendations for
                 released BSPs.
             </para>
 
@@ -684,11 +696,11 @@
                             You should consult the packaging and distribution guidelines for your
                             specific release process.
                             For an example of packaging and distribution requirements, see the
-                            <ulink url='https://wiki.yoctoproject.org/wiki/Third_Party_BSP_Release_Process'>Third
-                            Party BSP Release Process</ulink> wiki page.</para></listitem>
+                            "<ulink url='https://wiki.yoctoproject.org/wiki/Third_Party_BSP_Release_Process'>Third Party BSP Release Process</ulink>"
+                            wiki page.</para></listitem>
                         <listitem><para>The requirements for the BSP as it is made available to a developer
                             are completely independent of the released form of the BSP.
-                            For example, the BSP metadata can be contained within a Git repository
+                            For example, the BSP Metadata can be contained within a Git repository
                             and could have a directory structure completely different from what appears
                             in the officially released BSP layer.</para></listitem>
                         <listitem><para>It is not required that specific packages or package
@@ -719,7 +731,7 @@
                             as outlined in <filename>recipes.txt</filename>.
                             If you cannot find a category in <filename>recipes.txt</filename>
                             to fit a particular recipe, you can make up your own
-                            <filename>recipe-*</filename> subdirectory.
+                            <filename>recipes-*</filename> subdirectory.
                             You can find <filename>recipes.txt</filename> in the
                             <filename>meta</filename> directory of the
                             <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>,
@@ -737,12 +749,12 @@
                             recipes.
                             The recipes themselves should follow the general guidelines
                             for recipes used in the Yocto Project found in the
-                            <ulink url='https://wiki.yoctoproject.org/wiki/Recipe_%26_Patch_Style_Guide'>Yocto
-                            Recipe and Patch Style Guide</ulink>.</para></listitem>
+                            "<ulink url='https://wiki.yoctoproject.org/wiki/Recipe_%26_Patch_Style_Guide'>Yocto Recipe and Patch Style Guide</ulink>".
+                            </para></listitem>
                         <listitem><para><emphasis>License File:</emphasis>
                             You must include a license file in the
                             <filename>meta-&lt;bsp_name&gt;</filename> directory.
-                            This license covers the BSP metadata as a whole.
+                            This license covers the BSP Metadata as a whole.
                             You must specify which license to use since there is no
                             default license if one is not specified.
                             See the
@@ -771,11 +783,15 @@
                                     For example, this information includes information on
                                     special variables needed to satisfy a EULA,
                                     or instructions on information needed to build or distribute
-                                    binaries built from the BSP metadata.</para></listitem>
+                                    binaries built from the BSP Metadata.</para></listitem>
                                 <listitem><para>The name and contact information for the
                                     BSP layer maintainer.
                                     This is the person to whom patches and questions should
-                                    be sent.</para></listitem>
+                                    be sent.
+                                    For information on how to find the right person, 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></listitem>
                                 <listitem><para>Instructions on how to build the BSP using the BSP
                                     layer.</para></listitem>
                                 <listitem><para>Instructions on how to boot the BSP build from
@@ -803,9 +819,9 @@
                             This file identifies the <filename>meta-&lt;bsp_name&gt;</filename>
                             BSP layer as a layer to the build system.</para></listitem>
                         <listitem><para><emphasis>Machine Configuration File:</emphasis>
-                            You must include a <filename>conf/machine/&lt;bsp_name&gt;.conf</filename>
-                            in the <filename>meta-&lt;bsp_name&gt;</filename> directory.
-                            This configuration file defines a machine target that can be built
+                            You must include one or more <filename>conf/machine/&lt;bsp_name&gt;.conf</filename>
+                            files in the <filename>meta-&lt;bsp_name&gt;</filename> directory.
+                            These configuration files define machine targets that can be built
                             using the BSP layer.
                             Multiple machine configuration files define variations of machine
                             configurations that are supported by the BSP.
@@ -818,8 +834,9 @@
                             BSP layers for each target.
                             <note>It is completely possible for a developer to structure the
                             working repository as a conglomeration of unrelated BSP
-                            files, and to possibly generate specifically targeted 'release' BSPs
-                            from that directory using scripts or some other mechanism.
+                            files, and to possibly generate BSPs targeted for release
+                            from that directory using scripts or some other mechanism
+                            (e.g. <filename>meta-yocto-bsp</filename> layer).
                             Such considerations are outside the scope of this document.</note>
                             </para></listitem>
                     </itemizedlist>
@@ -875,31 +892,59 @@
                If you plan on customizing a recipe for a particular BSP, you need to do the
                following:
                <itemizedlist>
-                   <listitem><para>Include within the BSP layer a <filename>.bbappend</filename>
-                       file for the modified recipe.</para></listitem>
-                   <listitem><para>Place the BSP-specific file in the BSP's recipe
-                       <filename>.bbappend</filename> file path under a directory named
-                       after the machine.</para></listitem>
+                   <listitem><para>Create a <filename>.bbappend</filename>
+                       file for the modified recipe.
+                       For information on using append files, see the
+                       "<ulink url='&YOCTO_DOCS_DEV_URL;#using-bbappend-files'>Using .bbappend Files</ulink>"
+                       section in the Yocto Project Development Manual.
+                       </para></listitem>
+                   <listitem><para>
+                       Ensure your directory structure in the BSP layer
+                       that supports your machine is such that it can be found
+                       by the build system.
+                       See the example later in this section for more information.
+                       </para></listitem>
+                   <listitem><para>
+                       Put the append file in a directory whose name matches
+                       the machine's name and is located in an appropriate
+                       sub-directory inside the BSP layer (i.e.
+                       <filename>recipes-bsp</filename>, <filename>recipes-graphics</filename>,
+                       <filename>recipes-core</filename>, and so forth).
+                       </para></listitem>
+                   <listitem><para>Place the BSP-specific files in the directory named for
+                       your machine inside the BSP layer.
+                       </para></listitem>
                </itemizedlist>
            </para>
 
            <para>
-               To better understand this, consider an example that customizes a recipe by adding
+               Following is a specific example to help you better understand the process.
+               Consider an example that customizes a recipe by adding
                a BSP-specific configuration file named <filename>interfaces</filename> to the
-               <filename>netbase_5.0.bb</filename> recipe for machine "xyz".
+               <filename>init-ifupdown_1.0.bb</filename> recipe for machine "xyz".
                Do the following:
                <orderedlist>
-                   <listitem><para>Edit the <filename>netbase_4.47.bbappend</filename> file so that it
+                   <listitem><para>Edit the <filename>init-ifupdown_1.0.bbappend</filename> file so that it
                        contains the following:
                        <literallayout class='monospaced'>
      FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
      PRINC := "${@int(PRINC) + 2}"
-                       </literallayout></para></listitem>
+                       </literallayout>
+                       The append file needs to be in the
+                       <filename>meta-xyz/recipes-core/init-ifupdown</filename> directory.
+                       </para></listitem>
                    <listitem><para>Create and place the new <filename>interfaces</filename>
                        configuration file in the BSP's layer here:
                        <literallayout class='monospaced'>
-     meta-xyz/recipes-core/netbase/files/xyz/interfaces
-                       </literallayout></para></listitem>
+     meta-xyz/recipes-core/init-ifupdown/files/xyz/interfaces
+                       </literallayout>
+                       The
+                       <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></ulink>
+                       variable in the append files extends the search path
+                       the build system uses to find files during the build.
+                       Consequently, for this example you need to have the
+                       <filename>files</filename> directory in the same location
+                       as your append file.</para></listitem>
                </orderedlist>
             </para>
         </section>
@@ -933,9 +978,9 @@
 
             <para>
                 For cases where you can substitute a free component and still
-                maintain the system's functionality, the Yocto Project website's
-                <ulink url='&YOCTO_HOME_URL;/download/all?keys=&amp;download_type=1&amp;download_version='>BSP
-                Download Page</ulink> makes available de-featured BSPs
+                maintain the system's functionality, the "Downloads" page from the
+                <ulink url='&YOCTO_HOME_URL;'>Yocto Project website's</ulink>
+                makes available de-featured BSPs
                 that are completely free of any IP encumbrances.
                 For these cases, you can use the substitution directly and
                 without any further licensing requirements.
@@ -988,9 +1033,9 @@
 		        can build the encumbered image with no change at all
 		        to the normal build process.</para></listitem>
                     <listitem><para><emphasis>Get a pre-built version of the BSP:</emphasis>
-                        You can get this type of BSP by visiting the Yocto Project website's
-                        <ulink url='&YOCTO_HOME_URL;/download'>Download</ulink>
-                        page and clicking on "BSP Downloads".
+                        You can get this type of BSP by visiting the
+                        "Downloads" page of the
+                        <ulink url='&YOCTO_HOME_URL;'>Yocto Project website</ulink>.
                         You can download BSP tarballs that contain proprietary components
                         after agreeing to the licensing
                         requirements of each of the individually encumbered
@@ -1025,7 +1070,7 @@
                 The Yocto Project includes a couple of tools that enable
                 you to create a <link linkend='bsp-layers'>BSP layer</link>
                 from scratch and do basic configuration and maintenance
-                of the kernel without ever looking at a metadata file.
+                of the kernel without ever looking at a Metadata file.
                 These tools are <filename>yocto-bsp</filename> and <filename>yocto-kernel</filename>,
                 respectively.
 	    </para>
@@ -1112,7 +1157,7 @@
                 </para>
 
                 <para>
-                    For any sub-command, you can also use the word 'help' just before the
+                    For any sub-command, you can use the word "help" option just before the
                     sub-command to get more extensive documentation:
                     <literallayout class='monospaced'>
      $ yocto-bsp help create
@@ -1134,7 +1179,7 @@
          The value of the 'karch' parameter determines the set of files
          that will be generated for the BSP, along with the specific set of
          'properties' that will be used to fill out the BSP-specific
-         portions of the BSP.  The possible values for the 'karch' paramter
+         portions of the BSP.  The possible values for the 'karch' parameter
          can be listed via 'yocto-bsp list karch'.
 
          ...
@@ -1146,6 +1191,16 @@
                     on them, you should find it relatively straightforward to discover the commands
                     necessary to create a BSP and perform basic kernel maintenance on that BSP using
                     the tools.
+                    <note>
+                        You can also use the <filename>yocto-layer</filename> tool to create
+                        a "generic" layer.
+                        For information on this tool, see the
+                        "<ulink url='&YOCTO_DOCS_DEV_URL;#creating-a-general-layer-using-the-yocto-layer-script'>Creating a General Layer Using the yocto-layer Script</ulink>"
+                        section in the Yocto Project Development Guide.
+                    </note>
+                </para>
+
+                <para>
                     The next sections provide a concrete starting point to expand on a few points that
                     might not be immediately obvious or that could use further explanation.
                 </para>
@@ -1161,6 +1216,9 @@
                     by the Yocto Project, as well as QEMU versions of the same.
                     The default mode of the script's operation is to prompt you for information needed
                     to generate the BSP layer.
+                </para>
+
+                <para>
                     For the current set of BSPs, the script prompts you for various important
                     parameters such as:
                     <itemizedlist>
@@ -1201,7 +1259,7 @@
                     Of the available architectures, <filename>qemu</filename> is the only architecture
                     that causes the script to prompt you further for an actual architecture.
                     In every other way, this architecture is representative of how creating a BSP for
-                    a 'real' machine would work.
+                    an actual machine would work.
                     The reason the example uses this architecture is because it is an emulated architecture
                     and can easily be followed without requiring actual hardware.
                 </para>
@@ -1210,11 +1268,12 @@
                     As the <filename>yocto-bsp create</filename> command runs, default values for
                     the prompts appear in brackets.
                     Pressing enter without supplying anything on the command line or pressing enter
-                    and providing an invalid response causes the script to accept the default value.
+                    with an invalid response causes the script to accept the default value.
                     Once the script completes, the new <filename>meta-myarm</filename> BSP layer
                     is created in the current working directory.
-                    This example assumes you have source the &OE_INIT_FILE; and are currently
-                    in the top-level folder of the
+                    This example assumes you have sourced the
+                    <ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>
+                    and are currently in the top-level folder of the
                     <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
                 </para>
 
@@ -1229,17 +1288,17 @@
 	     4) PowerPC (32-bit)
 	     5) MIPS    (32-bit)
      3
-     Would you like to use the default (3.4) kernel? (y/n) [default: y]
+     Would you like to use the default (3.8) kernel? (y/n) [default: y]
      Do you need a new machine branch for this BSP (the alternative is to re-use an existing branch)? [y/n] [default: y]
-     Getting branches from remote repo git://git.yoctoproject.org/linux-yocto-3.4.git...
+     Getting branches from remote repo git://git.yoctoproject.org/linux-yocto-3.8.git...
      Please choose a machine branch to base your new BSP branch on: [default: standard/base]
              1) standard/arm-versatile-926ejs
              2) standard/base
              3) standard/beagleboard
-             4) standard/cedartrail
+             4) standard/ck
              5) standard/crownbay
-             6) standard/emenlow
-             7) standard/fishriver
+             6) standard/edf
+             7) standard/emenlow
              8) standard/fri2
              9) standard/fsl-mpc8315e-rdb
              10) standard/mti-malta32
@@ -1251,25 +1310,26 @@
      Would you like SMP support? (y/n) [default: y]
      Does your BSP have a touchscreen? (y/n) [default: n]
      Does your BSP have a keyboard? (y/n) [default: y]
+
      New qemu BSP created in meta-myarm
                     </literallayout>
                     Let's take a closer look at the example now:
                     <orderedlist>
-                        <listitem><para>For the <filename>qemu</filename> architecture,
+                        <listitem><para>For the QEMU architecture,
                             the script first prompts you for which emulated architecture to use.
-                            In the example, we use the <filename>arm</filename> architecture.
+                            In the example, we use the ARM architecture.
                             </para></listitem>
                         <listitem><para>The script then prompts you for the kernel.
-                            The default 3.4 kernel is acceptable.
+                            The default 3.8 kernel is acceptable.
                             So, the example accepts the default.
                             If you enter 'n', the script prompts you to further enter the kernel
-                            you do want to use (e.g. 3.0, 3.2_preempt-rt, and so forth.).</para></listitem>
+                            you do want to use (e.g. 3.2, 3.2_preempt-rt, and so forth.).</para></listitem>
                         <listitem><para>Next, the script asks whether you would like to have a new
                             branch created especially for your BSP in the local
                             <ulink url='&YOCTO_DOCS_DEV_URL;#local-kernel-files'>Linux Yocto Kernel</ulink>
                             Git repository .
                             If not, then the script re-uses an existing branch.</para>
-                            <para>In this example, the default (or 'yes') is accepted.
+                            <para>In this example, the default (or "yes") is accepted.
                             Thus, a new branch is created for the BSP rather than using a common, shared
                             branch.
                             The new branch is the branch committed to for any patches you might later add.
@@ -1281,8 +1341,8 @@
                             you are now given the opportunity to select a particular machine branch on
                             which to base your new BSP-specific machine branch
                             (or to re-use if you had elected to not create a new branch).
-                            Because this example is generating an <filename>arm</filename> BSP, the example
-                            uses <filename>#1</filename> at the prompt, which selects the arm-versatile branch.
+                            Because this example is generating an ARM-based BSP, the example
+                            uses <filename>#1</filename> at the prompt, which selects the ARM-versatile branch.
                             </para></listitem>
                         <listitem><para>The remainder of the prompts are routine.
                             Defaults are accepted for each.</para></listitem>
@@ -1299,7 +1359,7 @@
                     <filename>bblayers.conf</filename> file.
                     Here is an example:
                     <literallayout class='monospaced'>
-     BBLAYERS = ?" \
+     BBLAYERS = ? " \
         /usr/local/src/yocto/meta \
         /usr/local/src/yocto/meta-yocto \
         /usr/local/src/yocto/meta-yocto-bsp \
@@ -1313,7 +1373,7 @@
                     </literallayout>
                     Adding the layer to this file allows the build system to build the BSP and
                     the <filename>yocto-kernel</filename> tool to be able to find the layer and
-                    other metadata it needs on which to operate.
+                    other Metadata it needs on which to operate.
                 </para>
             </section>
 
@@ -1352,6 +1412,13 @@
         patch list        List the patches associated with a BSP
         patch add         Patch the Yocto kernel for a BSP
         patch rm          Remove patches from a BSP
+        feature list      List the features used by a BSP
+        feature add       Have a BSP use a feature
+        feature rm        Have a BSP stop using a feature
+        features list     List the features available to BSPs
+        feature describe  Describe a particular feature
+        feature create    Create a new BSP-local feature
+        feature destroy   Remove a BSP-local feature
 
       See 'yocto-kernel help COMMAND' for more information on a specific command.
 
@@ -1428,7 +1495,7 @@
      Added items:
              CONFIG_MISC_DEVICES=y
 
-     $ yocto-kernel config add myarm KCONFIG_YOCTO_TESTMOD=y
+     $ yocto-kernel config add myarm CONFIG_YOCTO_TESTMOD=y
      Added items:
              CONFIG_YOCTO_TESTMOD=y
                     </literallayout>

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

@@ -18,11 +18,11 @@
             Because much of the information in this manual is general, it
             contains many references to other sources where you can find more
             detail.
-            For example, you can find detailed information on Git, repositories, 
+            For example, you can find detailed information on Git, repositories,
             and open source in general in many places on the Internet.
-            Another example specific to the Yocto Project is how to quickly 
-            set up your host development system and build an image, which you 
-            find in the 
+            Another example specific to the Yocto Project is how to quickly
+            set up your host development system and build an image, which you
+            find in the
             <ulink url='&YOCTO_DOCS_QS_URL;'>Yocto Project Quick Start</ulink>.
             <note>
                 By default, using the Yocto Project creates a Poky distribution.
@@ -40,7 +40,7 @@
         <para>
             The Yocto Project Development Manual does, however, provide
             guidance and examples on how to change the kernel source code,
-            reconfigure the kernel, and develop an application using the 
+            reconfigure the kernel, and develop an application using the
             popular <trademark class='trade'>Eclipse</trademark> IDE.
         </para>
     </section>
@@ -53,17 +53,17 @@
             <itemizedlist>
                 <listitem><para>Information that lets you get set
                     up to develop using the Yocto Project.</para></listitem>
-                <listitem><para>Information to help developers who are new to 
-                    the open source environment and to the distributed revision 
+                <listitem><para>Information to help developers who are new to
+                    the open source environment and to the distributed revision
                     control system Git, which the Yocto Project uses.
                     </para></listitem>
-                <listitem><para>An understanding of common end-to-end 
+                <listitem><para>An understanding of common end-to-end
                     development models and tasks.</para></listitem>
                 <listitem><para>Information about common development tasks
-                    generally used during image development for 
+                    generally used during image development for
                     embedded devices.
                     </para></listitem>
-                <listitem><para>Many references to other sources of related 
+                <listitem><para>Many references to other sources of related
                     information.</para></listitem>
             </itemizedlist>
         </para>
@@ -78,7 +78,7 @@
                 <listitem><para>Step-by-step instructions if those instructions exist in other Yocto
                     Project documentation.
                     For example, the Yocto Project Application Developer's Guide contains detailed
-                    instruction on how to run the
+                    instructions on how to run the
                     <ulink url='&YOCTO_DOCS_ADT_URL;#installing-the-adt'>Installing the ADT and Toolchains</ulink>,
                     which is used to set up a cross-development environment.</para></listitem>
                 <listitem><para>Reference material.
@@ -96,8 +96,9 @@
         <title>Other Information</title>
 
         <para>
-            Because this manual presents overview information for many different topics, you will
-            need to supplement it with other information.
+            Because this manual presents overview 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>:
@@ -105,7 +106,7 @@
                     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 quickly and start building an image.</para></listitem>
+                    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 known as "Poky."
@@ -138,7 +139,8 @@
                     <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_HOME_URL;/download/yocto/yocto-project-&DISTRO;-release-notes-poky-&POKYVERSION;'>Release Notes</ulink>:</emphasis> Features, updates and known issues for the current
+                    <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/hob'>
@@ -147,8 +149,8 @@
                 <listitem><para><emphasis>
                     <ulink url='&YOCTO_HOME_URL;/download/build-appliance-0'>
                     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. 
+                    enables you to build and boot a custom embedded Linux image
+                    with the Yocto Project using a non-Linux development system.
                     For more information, see the
                     <ulink url='&YOCTO_HOME_URL;/documentation/build-appliance-manual'>Build Appliance</ulink>
                     page.
@@ -165,11 +167,11 @@
                         <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 
+                            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 for developments and
+                            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>.
@@ -182,7 +184,7 @@
                 <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
+                    This project is the upstream, generic, embedded distribution that the Yocto
                     Project derives its build system (Poky) from and to which it contributes.</para></listitem>
                 <listitem><para><emphasis>
                     <ulink url='http://developer.berlios.de/projects/bitbake/'>

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

@@ -23,7 +23,7 @@
              </para></listitem>
          <listitem><para><emphasis>User Application Development:</emphasis>
              User Application Development covers development of applications that you intend
-             to run on some target hardware.
+             to run on target hardware.
              For information on how to set up your host development system for user-space
              application development, see the
              <ulink url='&YOCTO_DOCS_ADT_URL;'>Yocto Project Application Developer's Guide</ulink>.
@@ -35,10 +35,10 @@
          <listitem><para><emphasis>Temporary Source Code Modification:</emphasis>
              Direct modification of temporary source code is a convenient development model
              to quickly iterate and develop towards a solution.
-             Once the solution has been implemented, you should of course take steps to
+             Once you implement the solution, you should of course take steps to
              get the changes upstream and applied in the affected recipes.</para></listitem>
          <listitem><para><emphasis>Image Development using Hob:</emphasis>
-             You can use the <ulink url='&YOCTO_HOME_URL;/projects/hob'>Hob</ulink> to build
+             You can use the <ulink url='&YOCTO_HOME_URL;/tools-resources/projects/hob'>Hob</ulink> to build
              custom operating system images within the build environment.
              Hob provides an efficient interface to the OpenEmbedded build system.</para></listitem>
          <listitem><para><emphasis>Using a Development Shell:</emphasis>
@@ -117,21 +117,22 @@
                     Directory</link> available on your host system.
                     Having these files on your system gives you access to the build
                     process and to the tools you need.
-                    For information on how to set up the
-                    <link linkend='source-directory'>Source Directory</link>, see the
-                    "<link linkend='getting-setup'>Getting Set up</link>" section.</para></listitem>
+                    For information on how to set up the Source Directory,
+                    see the
+                    "<link linkend='getting-setup'>Getting Set Up</link>" section.</para></listitem>
                 <listitem><para><emphasis>Establish the <filename>meta-intel</filename>
                     repository on your system</emphasis>:  Having local copies
                     of these supported BSP layers on your system gives you
                     access to layers you might be able to build on or modify
                     to create your BSP.
                     For information on how to get these files, see the
-                    "<link linkend='getting-setup'>Getting Setup</link>" section.</para></listitem>
+                    "<link linkend='getting-setup'>Getting Set Up</link>" section.</para></listitem>
                 <listitem><para><emphasis>Create your own BSP layer using the
                     <ulink url='&YOCTO_DOCS_BSP_URL;#creating-a-new-bsp-layer-using-the-yocto-bsp-script'><filename>yocto-bsp</filename></ulink> script</emphasis>:
                     Layers are ideal for
                     isolating and storing work for a given piece of hardware.
-                    A layer is really just a location or area in which you place the recipes for your BSP.
+                    A layer is really just a location or area in which you place 
+                    the recipes and configurations for your BSP.
                     In fact, a BSP is, in itself, a special type of layer.
                     The simplest way to create a new BSP layer that is compliant with the
                     Yocto Project is to use the <filename>yocto-bsp</filename> script.
@@ -159,12 +160,12 @@
                     <filename>mpc8315e</filename>, and <filename>routerstationpro</filename>.
                     The recipes and configurations for these four BSPs are located and dispersed
                     within the <link linkend='source-directory'>Source Directory</link>.
-                    On the other hand, BSP layers for Cedar Trail, Chief River, Crown Bay,
-                    Crystal Forest, Emenlow, Fish River, Fish River 2, Jasper Forest, N450,
+                    On the other hand, BSP layers for Chief River, Crown Bay,
+                    Crystal Forest, Emenlow, Fish River Island 2, Jasper Forest, N450, NUC DC3217IYE,
                     Romley, sys940x, Sugar Bay, and tlk exist in their own separate layers
                     within the larger <filename>meta-intel</filename> layer.</note>
                     <para>When you set up a layer for a new BSP, you should follow a standard layout.
-                    This layout is described in the section
+                    This layout is described in the 
                     "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-filelayout'>Example Filesystem Layout</ulink>"
                     section of the Board Support Package (BSP) Development Guide.
                     In the standard layout, you will notice a suggested structure for recipes and
@@ -178,7 +179,7 @@
                     directories within the BSP layer.
                     Configuration changes identify where your new layer is on the local system
                     and identify which kernel you are going to use.
-                    When you run the <filename>yocto-bsp</filename> script you are able to interactively
+                    When you run the <filename>yocto-bsp</filename> script, you are able to interactively
                     configure many things for the BSP (e.g. keyboard, touchscreen, and so forth).
                     </para></listitem>
                 <listitem><para><emphasis>Make recipe changes to your new BSP layer</emphasis>:  Recipe
@@ -268,21 +269,15 @@
                 Within this group, you will find several kernels supported by
                 the Yocto Project:
                 <itemizedlist>
-                    <listitem><para><emphasis><filename>linux-yocto-2.6.34</filename></emphasis> - The
-                    stable Yocto Project kernel that is based on the Linux 2.6.34 released kernel.</para></listitem>
-                    <listitem><para><emphasis><filename>linux-yocto-2.6.37</filename></emphasis> - The
-                    stable Yocto Project kernel that is based on the Linux 2.6.37 released kernel.</para></listitem>
-                    <listitem><para><emphasis><filename>linux-yocto-3.0</filename></emphasis> - The stable
-                    Yocto Project kernel that is based on the Linux 3.0 released kernel.</para></listitem>
-                    <listitem><para><emphasis><filename>linux-yocto-3.0-1.1.x</filename></emphasis> - The
-                    stable Yocto Project kernel to use with the Yocto Project Release 1.1.x. This kernel
-                    is based on the Linux 3.0 released kernel.</para></listitem>
                     <listitem><para><emphasis><filename>linux-yocto-3.2</filename></emphasis> - The
                     stable Yocto Project kernel to use with the Yocto Project Release 1.2. This kernel
                     is based on the Linux 3.2 released kernel.</para></listitem>
                     <listitem><para><emphasis><filename>linux-yocto-3.4</filename></emphasis> - The
                     stable Yocto Project kernel to use with the Yocto Project Release 1.3. This kernel
                     is based on the Linux 3.4 released kernel.</para></listitem>
+                    <listitem><para><emphasis><filename>linux-yocto-3.8</filename></emphasis> - The
+                    stable Yocto Project kernel to use with the Yocto Project Release 1.4. This kernel
+                    is based on the Linux 3.8 released kernel.</para></listitem>
                     <listitem><para><emphasis><filename>linux-yocto-dev</filename></emphasis> - A development
                     kernel based on the latest upstream release candidate available.</para></listitem>
                 </itemizedlist>
@@ -292,8 +287,8 @@
                 The kernels are maintained using the Git revision control system
                 that structures them using the familiar "tree", "branch", and "leaf" scheme.
                 Branches represent diversions from general code to more specific code, while leaves
-                represent the end-points for a complete and unique kernel whose source files
-                when gathered from the root of the tree to the leaf accumulate to create the files
+                represent the end-points for a complete and unique kernel whose source files,
+                when gathered from the root of the tree to the leaf, accumulate to create the files
                 necessary for a specific piece of hardware and its features.
                 The following figure displays this concept:
             <para>
@@ -304,12 +299,12 @@
             <para>
                 Within the figure, the "Kernel.org Branch Point" represents the point in the tree
                 where a supported base kernel is modified from the Linux kernel.
-                For example, this could be the branch point for the <filename>linux-yocto-3.0</filename>
+                For example, this could be the branch point for the <filename>linux-yocto-3.4</filename>
                 kernel.
                 Thus, everything further to the right in the structure is based on the
-                <filename>linux-yocto-3.0</filename> kernel.
+                <filename>linux-yocto-3.4</filename> kernel.
                 Branch points to right in the figure represent where the
-                <filename>linux-yocto-3.0</filename> kernel is modified for specific hardware
+                <filename>linux-yocto-3.4</filename> kernel is modified for specific hardware
                 or types of kernels, such as real-time kernels.
                 Each leaf thus represents the end-point for a kernel designed to run on a specific
                 targeted device.
@@ -347,10 +342,14 @@
                 ways.
                 If you are working in the kernel all the time, you probably would want
                 to set up your own local Git repository of the kernel tree.
-                If you just need to make some patches to the kernel, you can get at
-                temporary kernel source files extracted and used during the OpenEmbedded
-                build system.
+                If you just need to make some patches to the kernel, you can access
+                temporary kernel source files that were extracted and used 
+                during a build.
                 We will just talk about working with the temporary source code.
+                For more information on how to get kernel source code onto your 
+                host system, see the
+                "<link linkend='local-kernel-files'>Yocto Project Kernel</link>"
+                bulleted item earlier in the manual.
             </para>
 
             <para>
@@ -412,7 +411,9 @@
                         "<link linkend='local-yp-release'>Yocto Project Release</link>" earlier in this manual.
                         </para></listitem>
                     <listitem><para><emphasis>Establish the temporary kernel source files</emphasis>:
-                        Temporary kernel source files are kept in the Build Directory created by the
+                        Temporary kernel source files are kept in the 
+                        <link linkend='build-directory'>Build Directory</link>
+                        created by the
                         OpenEmbedded build system when you run BitBake.
                         If you have never built the kernel you are interested in, you need to run
                         an initial build to establish local kernel source files.</para>
@@ -428,7 +429,7 @@
                         You might want to reference this information.
                         You can find more information on BitBake in the user manual, which is found in the
                         <filename>bitbake/doc/manual</filename> directory of the
-                        <link linkend='source-directory'>Source Directory</link>.</para>
+                        Source Directory.</para>
                         <para>The build process supports several types of images to satisfy different needs.
                         See the "<ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Images</ulink>" chapter in
                         the Yocto Project Reference Manual for information on supported images.
@@ -447,10 +448,9 @@
                         Using <filename>menuconfig</filename> allows you to interactively develop and test the
                         configuration changes you are making to the kernel.
                         When saved, changes using <filename>menuconfig</filename> update the kernel's
-                        <filename>.config</filename>.
+                        <filename>.config</filename> file.
                         Try to resist the temptation of directly editing the <filename>.config</filename>
-                        file found in the
-                        <link linkend='build-directory'>Build Directory</link> at
+                        file found in the Build Directory at
                         <filename>tmp/sysroots/&lt;machine-name&gt;/kernel</filename>.
                         Doing so, can produce unexpected results when the OpenEmbedded build system
                         regenerates the configuration file.</para>
@@ -474,9 +474,11 @@
         Application development involves creating an application that you want
         to run on your target hardware, which is running a kernel image created using the
         OpenEmbedded build system.
-        The Yocto Project provides an Application Development Toolkit (ADT) and
-        stand-alone cross-development toolchains that
-        facilitate quick development and integration of your application into its run-time environment.
+        The Yocto Project provides an 
+        <ulink url='&YOCTO_DOCS_ADT_URL;#adt-intro-section'>Application Development Toolkit (ADT)</ulink>
+        and stand-alone
+        <ulink url='&YOCTO_DOCS_ADT_URL;#the-cross-development-toolchain'>cross-development toolchains</ulink>
+        that facilitate quick development and integration of your application into its runtime environment.
         Using the ADT and toolchains, you can compile and link your application.
         You can then deploy your application to the actual hardware or to the QEMU emulator for testing.
         If you are familiar with the popular <trademark class='trade'>Eclipse</trademark> IDE,
@@ -511,12 +513,12 @@
 
         <para>
             <orderedlist>
-                <listitem><para><emphasis>Prepare the Host System for the Yocto Project</emphasis>:
+                <listitem><para><emphasis>Prepare the host system for the Yocto Project</emphasis>:
                     See
                     "<ulink url='&YOCTO_DOCS_QS_URL;#the-linux-distro'>The Linux Distribution</ulink>" and
                     "<ulink url='&YOCTO_DOCS_QS_URL;#packages'>The Packages</ulink>" sections both
                     in the Yocto Project Quick Start for requirements.</para></listitem>
-                <listitem><para><emphasis>Secure the Yocto Project Kernel Target Image</emphasis>:
+                <listitem><para><emphasis>Secure the Yocto Project kernel target image</emphasis>:
                     You must have a target kernel image that has been built using the OpenEmbedded
                     build system.</para>
                     <para>Depending on whether the Yocto Project has a pre-built image that matches your target
@@ -548,14 +550,14 @@
                     The ADT provides a target-specific cross-development toolchain, the root filesystem,
                     the QEMU emulator, and other tools that can help you develop your application.
                     While it is possible to get these pieces separately, the ADT Installer provides an
-                    easy method.
+                    easy, inclusive method.
                     You can get these pieces by running an ADT installer script, which is configurable.
                     For information on how to install the ADT, see the
                     "<ulink url='&YOCTO_DOCS_ADT_URL;#using-the-adt-installer'>Using the ADT Installer</ulink>"
                     section
                     in the Yocto Project Application Developer's Guide.</para></listitem>
-                <listitem><para><emphasis>If Applicable, Secure the Target Root Filesystem
-                    and the Cross-development Toolchain</emphasis>:
+                <listitem><para><emphasis>If applicable, secure the target root filesystem
+                    and the Cross-development toolchain</emphasis>:
                     If you choose not to install the ADT using the ADT Installer,
                     you need to find and download the appropriate root filesystem and
                     the cross-development toolchain.</para>
@@ -563,7 +565,7 @@
                     for the kernel image.
                     Depending on the type of image you are running, the root filesystem you need differs.
                     For example, if you are developing an application that runs on an image that
-                    supports Sato, you need to get root filesystem that supports Sato.</para>
+                    supports Sato, you need to get a root filesystem that supports Sato.</para>
                     <para>You can find the cross-development toolchains at
                     <ulink url='&YOCTO_TOOLCHAIN_DL_URL;'><filename>toolchains</filename></ulink>.
                     Be sure to get the correct toolchain for your development host and your
@@ -576,20 +578,20 @@
                     the correct toolchain based on your host development system and your target
                     architecture.
                     </para></listitem>
-                <listitem><para><emphasis>Create and Build your Application</emphasis>:
+                <listitem><para><emphasis>Create and build your application</emphasis>:
                     At this point, you need to have source files for your application.
                     Once you have the files, you can use the Eclipse IDE to import them and build the
                     project.
                     If you are not using Eclipse, you need to use the cross-development tools you have
                     installed to create the image.</para></listitem>
-                <listitem><para><emphasis>Deploy the Image with the Application</emphasis>:
+                <listitem><para><emphasis>Deploy the image with the application</emphasis>:
                     If you are using the Eclipse IDE, you can deploy your image to the hardware or to
                     QEMU through the project's preferences.
                     If you are not using the Eclipse IDE, then you need to deploy the application
                     to the hardware using other methods.
                     Or, if you are using QEMU, you need to use that tool and load your image in for testing.
                     </para></listitem>
-                <listitem><para><emphasis>Test and Debug the Application</emphasis>:
+                <listitem><para><emphasis>Test and debug the application</emphasis>:
                     Once your application is deployed, you need to test it.
                     Within the Eclipse IDE, you can use the debugging environment along with the
                     set of user-space tools installed along with the ADT to debug your application.
@@ -617,7 +619,8 @@
             Installing and configuring the Plug-in results in an environment that
             has extensions specifically designed to let you more easily develop software.
             These extensions allow for cross-compilation, deployment, and execution of
-            your output into a QEMU emulation session.
+            your output into a QEMU emulation session as well as actual target
+            hardware.
             You can also perform cross-debugging and profiling.
             The environment also supports a suite of tools that allows you to perform
             remote profiling, tracing, collection of power data, collection of
@@ -662,7 +665,7 @@
                 </para>
 
                 <para>
-                    If you don’t have the Juno 4.2 Eclipse IDE installed, you can find the tarball at
+                    If you do not have the Juno 4.2 Eclipse IDE installed, you can find the tarball at
                     <ulink url='&ECLIPSE_MAIN_URL;'></ulink>.
                     From that site, choose the Eclipse Classic version particular to your development
                     host.
@@ -731,7 +734,7 @@
                         <listitem><para>Select <filename>Juno - &ECLIPSE_JUNO_URL;</filename>
                             from the "Work with:" pull-down menu.</para></listitem>
                         <listitem><para>Expand the box next to "Linux Tools" and select the
-                            "LTTng - Linux Tracing Toolkit" boxes.</para></listitem>
+                            <filename>LTTng - Linux Tracing Toolkit</filename> boxes.</para></listitem>
                         <listitem><para>Expand the box next to "Mobile and Device Development" and select the
                             following boxes:
                             <itemizedlist>
@@ -742,7 +745,7 @@
                                 <listitem><para><filename>TCF Remote System Explorer add-in</filename></para></listitem>
                                 <listitem><para><filename>TCF Target Explorer</filename></para></listitem>
                             </itemizedlist></para></listitem>
-                        <listitem><para>Expand the box next to <filename>Programming Languages</filename>
+                        <listitem><para>Expand the box next to "Programming Languages"
                             and select the <filename>Autotools Support for CDT</filename>
                             and <filename>C/C++ Development Tools</filename> boxes.</para></listitem>
                         <listitem><para>Complete the installation and restart the Eclipse IDE.</para></listitem>
@@ -770,11 +773,12 @@
                             </para></listitem>
                         <listitem><para>Select <filename>indigo - &ECLIPSE_INDIGO_URL;</filename>
                             from the "Work with:" pull-down menu.</para></listitem>
-                        <listitem><para>Expand the box next to <filename>Programming Languages</filename>
+                        <listitem><para>Expand the box next to "Programming Languages"
                             and select the <filename>Autotools Support for CDT (incubation)</filename>
                             and <filename>C/C++ Development Tools</filename> boxes.</para></listitem>
                         <listitem><para>Expand the box next to "Linux Tools" and select the
-                            "LTTng - Linux Tracing Toolkit(incubation)" boxes.</para></listitem>
+                            <filename>LTTng - Linux Tracing Toolkit(incubation)</filename>
+                            boxes.</para></listitem>
                         <listitem><para>Complete the installation and restart the Eclipse IDE.</para></listitem>
                         <listitem><para>After the Eclipse IDE restarts and from the Workbench, select
                             "Install New Software" from the "Help" pull-down menu.</para></listitem>
@@ -801,7 +805,7 @@
                             from the "Work with:" pull-down menu.</para></listitem>
                         <listitem><para>Check the box next to <filename>CDT Main Features</filename>.
                             </para></listitem>
-                        <listitem><para>Expand the box next to <filename>CDT Optional Features</filename>
+                        <listitem><para>Expand the box next to "CDT Optional Features"
                             and select <filename>C/C++ Remote Launch</filename> and
                             <filename>Target Communication Framework (incubation)</filename>.</para></listitem>
                         <listitem><para>Complete the installation and restart the Eclipse IDE.</para></listitem>
@@ -816,7 +820,7 @@
                     You can install the Eclipse Yocto Plug-in into the Eclipse IDE
                     one of two ways:  use the Yocto Project's Eclipse Update site to install the pre-built plug-in,
                     or build and install the plug-in from the latest source code.
-                    If you don't want to permanently install the plug-in but just want to try it out
+                    If you do not want to permanently install the plug-in but just want to try it out
                     within the Eclipse environment, you can import the plug-in project from the
                     Yocto Project's Source Repositories.
                 </para>
@@ -889,7 +893,7 @@
                                 as directed.
                                 Be sure to provide the name of the Git branch along with the
                                 Yocto Project release you are using.
-                                Here is an example that uses the <filename>&DISTRO_NAME;</filename> branches:
+                                Here is an example that uses the <filename>&DISTRO_NAME;</filename> branch:
                                 <literallayout class='monospaced'>
      $ ECLIPSE_HOME=/home/scottrif/yocto-eclipse/scripts/eclipse ./build.sh &DISTRO_NAME; &DISTRO_NAME;
                                 </literallayout>
@@ -930,6 +934,9 @@
                         It is important to understand when you import the plug-in you are not installing
                         it into the Eclipse application.
                         Rather, you are importing the project and just using it.
+                    </para>
+
+                    <para>
                         To import the plug-in project, follow these steps:
                         <orderedlist>
                             <listitem><para>Open a shell and create a Git repository with:
@@ -943,16 +950,18 @@
                                 and then click "Next".</para></listitem>
                             <listitem><para>Select the root directory and browse to
                                 <filename>~/yocto-eclipse/plugins</filename>.</para></listitem>
-                            <listitem><para>Three plug-ins exist: "org.yocto.bc.ui", "org.yocto.sdk.ide", and
-                                "org.yocto.sdk.remotetools".
+                            <listitem><para>Three plug-ins exist: 
+                                <filename>org.yocto.bc.ui</filename>,
+                                <filename>org.yocto.sdk.ide</filename>, and
+                                <filename>org.yocto.sdk.remotetools</filename>.
                                 Select and import all of them.</para></listitem>
                         </orderedlist>
                     </para>
 
                     <para>
                         The left navigation pane in the Eclipse application shows the default projects.
-                        Right-click on one of these projects and run it as an Eclipse application.
-                        This brings up a second instance of Eclipse IDE that has the Yocto Plug-in.
+                        Right-click on one of these projects and run it as an Eclipse application
+                        to bring up a second instance of Eclipse IDE that has the Yocto Plug-in.
                     </para>
                 </section>
             </section>
@@ -971,9 +980,10 @@
                 <para>
                     To start, you need to do the following from within the Eclipse IDE:
                     <itemizedlist>
-                        <listitem><para>Choose <filename>Windows -&gt; Preferences</filename> to display
-                            the <filename>Preferences</filename> Dialog</para></listitem>
-                        <listitem><para>Click <filename>Yocto Project ADT</filename></para></listitem>
+                        <listitem><para>Choose "Preferences" from the 
+                            "Windows" menu to display
+                            the Preferences Dialog</para></listitem>
+                        <listitem><para>Click "Yocto Project ADT"</para></listitem>
                     </itemizedlist>
                 </para>
 
@@ -1000,7 +1010,8 @@
                                        <listitem><para><emphasis>
                                             <filename>Build System Derived Toolchain:</filename></emphasis>
                                             Select this mode if the cross-toolchain has been installed and built
-                                            as part of the Build Directory.
+                                            as part of the 
+                                            <link linkend='build-directory'>Build Directory</link>.
                                             When you select <filename>Build system derived toolchain</filename>,
                                             you are using the toolchain bundled
                                             inside the Build Directory.
@@ -1009,33 +1020,35 @@
                                 </para></listitem>
                             <listitem><para><emphasis>Point to the Toolchain:</emphasis>
                                 If you are using a stand-alone pre-built toolchain, you should be pointing to the
-                                <filename>&YOCTO_ADTPATH_DIR;</filename> directory.
-                                This is the location for toolchains installed by the ADT Installer or by hand.
+                                where it is installed.
+                                If you used the ADT Installer script and accepted the default
+                                installation directory, the toolchain will be installed in 
+                                the <filename>&YOCTO_ADTPATH_DIR;</filename> directory.
                                 Sections "<ulink url='&YOCTO_DOCS_ADT_URL;#configuring-and-running-the-adt-installer-script'>Configuring
                                 and Running the ADT Installer Script</ulink>" and
                                 "<ulink url='&YOCTO_DOCS_ADT_URL;#using-an-existing-toolchain-tarball'>Using a Cross-Toolchain Tarball</ulink>"
                                 in the Yocto Project Application Developer's Guide
-                                describe two ways to install a stand-alone cross-toolchain in the
-                                <filename>/opt/poky</filename> directory.
-                                <note>It is possible to install a stand-alone cross-toolchain in a directory
-                                other than <filename>/opt/poky</filename>.
-                                However, doing so is discouraged.</note></para>
+                                describe how to install a stand-alone cross-toolchain.</para>
                                 <para>If you are using a system-derived toolchain, the path you provide
                                 for the <filename>Toolchain Root Location</filename>
-                                field is the Build Directory.
+                                field is the <link linkend='build-directory'>Build Directory</link>.
                                 See the "<ulink url='&YOCTO_DOCS_ADT_URL;#using-the-toolchain-from-within-the-build-tree'>Using
                                 BitBake and the Build Directory</ulink>" section in the Yocto Project Application
-                                Developer's Guide for information on how to install the toolchain into the build
-directory.</para></listitem>
+                                Developer's Guide for information on how to install 
+                                the toolchain into the Build Directory.</para></listitem>
                             <listitem><para><emphasis>Specify the Sysroot Location:</emphasis>
                                 This location is where the root filesystem for the target hardware resides.
-                                If you used the ADT Installer, then the location is
+                                If you used the ADT Installer script and accepted the 
+                                default installation directory, then the location is
                                 <filename>/opt/poky/&lt;release&gt;</filename>.
-                                Additionally, when you use the ADT Installer, the same location is used for
+                                Additionally, when you use the ADT Installer script,
+                                the same location is used for
                                 the QEMU user-space tools and the NFS boot process.</para>
-                                <para>If you used either of the other two methods to install the toolchain, then the
+                                <para>If you used either of the other two methods to 
+                                install the toolchain or did not accept the ADT Installer
+                                script's default installation directory, then the
                                 location of the sysroot filesystem depends on where you separately
-                                extracted and intalled the filesystem.</para>
+                                extracted and installed the filesystem.</para>
                                 <para>For information on how to install the toolchain and on how to extract
                                 and install the sysroot filesystem, see the
                                 "<ulink url='&YOCTO_DOCS_ADT_URL;#installing-the-adt'>Installing the ADT and Toolchains</ulink>" section.
@@ -1086,7 +1099,7 @@ directory.</para></listitem>
                                 </literallayout></para>
                                 <para>
                                 Regardless of the mode, Sysroot is already defined as part of the
-                                Cross Compiler Options configuration in the
+                                Cross-Compiler Options configuration in the
                                 <filename>Sysroot Location:</filename> field.</para></listitem>
                             <listitem><para><emphasis><filename>External HW:</filename></emphasis> Select this option
                                 if you will be using actual hardware.</para></listitem>
@@ -1094,7 +1107,7 @@ directory.</para></listitem>
                     </para>
 
                     <para>
-                        Click the <filename>OK</filename> button to save your plug-in configurations.
+                        Click the "OK" to save your plug-in configurations.
                     </para>
                 </section>
             </section>
@@ -1116,7 +1129,7 @@ directory.</para></listitem>
                 To create a project based on a Yocto template and then display the source code,
                 follow these steps:
                 <orderedlist>
-                    <listitem><para>Select <filename>File -&gt; New -&gt; Project</filename>.</para></listitem>
+                    <listitem><para>Select "Project" from the "File -> New" menu.</para></listitem>
                     <listitem><para>Double click <filename>CC++</filename>.</para></listitem>
                     <listitem><para>Double click <filename>C Project</filename> to create the project.</para></listitem>
                     <listitem><para>Expand <filename>Yocto Project ADT Project</filename>.</para></listitem>
@@ -1124,11 +1137,11 @@ directory.</para></listitem>
                         This is an Autotools-based project based on a Yocto template.</para></listitem>
                     <listitem><para>Put a name in the <filename>Project name:</filename> field.
                         Do not use hyphens as part of the name.</para></listitem>
-                    <listitem><para>Click <filename>Next</filename>.</para></listitem>
+                    <listitem><para>Click "Next".</para></listitem>
                     <listitem><para>Add information in the <filename>Author</filename> and
                         <filename>Copyright notice</filename> fields.</para></listitem>
                     <listitem><para>Be sure the <filename>License</filename> field is correct.</para></listitem>
-                    <listitem><para>Click <filename>Finish</filename>.</para></listitem>
+                    <listitem><para>Click "Finish".</para></listitem>
                     <listitem><para>If the "open perspective" prompt appears, click "Yes" so that you
                         in the C/C++ perspective.</para></listitem>
                     <listitem><para>The left-hand navigation pane shows your project.
@@ -1147,31 +1160,32 @@ directory.</para></listitem>
                 configurations.
                 You can override these settings for a given project by following these steps:
                 <orderedlist>
-                    <listitem><para>Select <filename>Project -&gt; Change Yocto Project Settings</filename>:
-                        This selection brings up the <filename>Yocot Project Settings</filename> Dialog
+                    <listitem><para>Select "Change Yocto Project Settings" from the 
+                        "Project" menu.
+                        This selection brings up the Yocto Project Settings Dialog
                         and allows you to make changes specific to an individual project.
                         </para>
                         <para>By default, the Cross Compiler Options and Target Options for a project
-                        are inherited from settings you provide using the <filename>Preferences</filename>
+                        are inherited from settings you provide using the Preferences
                         Dialog as described earlier
                         in the "<link linkend='configuring-the-eclipse-yocto-plug-in'>Configuring the Eclipse
                         Yocto Plug-in</link>" section.
-                        The <filename>Yocto Project Settings</filename>
-                        Dialog allows you to override those default settings
-                        for a given project.</para></listitem>
+                        The Yocto Project Settings Dialog allows you to override 
+                        those default settings for a given project.</para></listitem>
                     <listitem><para>Make your configurations for the project and click "OK".
                         If you are running the Juno version of Eclipse, you can skip down to the next
                         section where you build the project.
                         If you are not working with Juno, you need to reconfigure the project as
                         described in the next step.</para></listitem>
-                    <listitem><para>Select <filename>Project -&gt; Reconfigure Project</filename>:
+                    <listitem><para>Select "Reconfigure Project" from the 
+                        "Project" menu.
                         This selection reconfigures the project by running
                        <filename>autogen.sh</filename> in the workspace for your project.
                         The script also runs <filename>libtoolize</filename>, <filename>aclocal</filename>,
                         <filename>autoconf</filename>, <filename>autoheader</filename>,
                         <filename>automake --a</filename>, and
                         <filename>./configure</filename>.
-                        Click on the <filename>Console</filename> tab beneath your source code to
+                        Click on the "Console" tab beneath your source code to
                         see the results of reconfiguring your project.</para></listitem>
                 </orderedlist>
             </para>
@@ -1182,19 +1196,21 @@ directory.</para></listitem>
 
             <para>
                 To build the project in Juno, right click on the project in the navigator pane and select
-                <filename>Build Project</filename>.
-                If you are not running Juno, select <filename>Project -&gt; Build Project</filename>.
+                "Build Project".
+                If you are not running Juno, select "Build Project" from the 
+                "Project" menu.
                 The console should update and you can note the cross-compiler you are using.
             </para>
         </section>
 
         <section id='starting-qemu-in-user-space-nfs-mode'>
-            <title>Starting QEMU in User Space NFS Mode</title>
+            <title>Starting QEMU in User-Space NFS Mode</title>
 
             <para>
                 To start the QEMU emulator from within Eclipse, follow these steps:
                 <orderedlist>
-                    <listitem><para>Expose the <filename>Run -&gt; External Tools</filename> menu.
+                    <listitem><para>Expose and select "External Tools" from 
+                        the "Run" menu.
                         Your image should appear as a selectable menu item.
                         </para></listitem>
                     <listitem><para>Select your image from the menu to launch the
@@ -1216,33 +1232,36 @@ directory.</para></listitem>
             <title>Deploying and Debugging the Application</title>
 
             <para>
-                Once the QEMU emulator is running the image, using the Eclipse IDE
-                you can deploy your application and use the emulator to perform debugging.
+                Once the QEMU emulator is running the image, you can deploy 
+                your application using the Eclipse IDE and use then use 
+                the emulator to perform debugging.
                 Follow these steps to deploy the application.
                 <orderedlist>
-                    <listitem><para>Select <filename>Run -&gt; Debug Configurations...</filename></para></listitem>
+                    <listitem><para>Select "Debug Configurations..." from the 
+                    "Run" menu.</para></listitem>
                     <listitem><para>In the left area, expand <filename>C/C++Remote Application</filename>.</para></listitem>
                     <listitem><para>Locate your project and select it to bring up a new
-                        tabbed view in the <filename>Debug Configurations</filename> Dialog.</para></listitem>
+                        tabbed view in the Debug Configurations Dialog.</para></listitem>
                     <listitem><para>Enter the absolute path into which you want to deploy
                         the application.
-                        Use the <filename>Remote Absolute File Path for C/C++Application:</filename> field.
+                        Use the "Remote Absolute File Path for C/C++Application:" field.
                         For example, enter <filename>/usr/bin/&lt;programname&gt;</filename>.</para></listitem>
-                    <listitem><para>Click on the <filename>Debugger</filename> tab to see the cross-tool debugger
+                    <listitem><para>Click on the "Debugger" tab to see the cross-tool debugger
                         you are using.</para></listitem>
-                    <listitem><para>Click on the <filename>Main</filename> tab.</para></listitem>
+                    <listitem><para>Click on the "Main" tab.</para></listitem>
                     <listitem><para>Create a new connection to the QEMU instance
-                        by clicking on <filename>new</filename>.</para></listitem>
+                        by clicking on "new".</para></listitem>
                     <listitem><para>Select <filename>TCF</filename>, which means Target Communication
                         Framework.</para></listitem>
-                    <listitem><para>Click <filename>Next</filename>.</para></listitem>
-                    <listitem><para>Clear out the <filename>host name</filename> field and enter the IP Address
+                    <listitem><para>Click "Next".</para></listitem>
+                    <listitem><para>Clear out the "host name" field and enter the IP Address
                         determined earlier.</para></listitem>
-                    <listitem><para>Click <filename>Finish</filename> to close the
-                        <filename>New Connections</filename> Dialog.</para></listitem>
-                    <listitem><para>Use the drop-down menu now in the <filename>Connection</filename> field and pick
-                        the IP Address you entered.</para></listitem>
-                    <listitem><para>Click <filename>Run</filename> to bring up a login screen
+                    <listitem><para>Click "Finish" to close the
+                        New Connections Dialog.</para></listitem>
+                    <listitem><para>Use the drop-down menu now in the 
+                        "Connection" field and pick the IP Address you entered.
+                         </para></listitem>
+                    <listitem><para>Click "Run" to bring up a login screen
                         and login.</para></listitem>
                     <listitem><para>Accept the debug perspective.</para></listitem>
                 </orderedlist>
@@ -1257,14 +1276,14 @@ directory.</para></listitem>
                 your development experience.
                 These tools are aids in developing and debugging applications and images.
                 You can run these user-space tools from within the Eclipse IDE through the
-                <filename>YoctoTools</filename> menu.
+                "YoctoTools" menu.
             </para>
 
             <para>
                 Once you pick a tool, you need to configure it for the remote target.
                 Every tool needs to have the connection configured.
                 You must select an existing TCF-based RSE connection to the remote target.
-                If one does not exist, click <filename>New</filename> to create one.
+                If one does not exist, click "New" to create one.
             </para>
 
             <para>
@@ -1279,10 +1298,10 @@ directory.</para></listitem>
                         You must compile and install the <filename>oprofile-viewer</filename> from the source code
                         on your local host machine.
                         Furthermore, in order to convert the target's sample format data into a form that the
-                        host can use, you must have <filename>oprofile</filename> version 0.9.4 or
+                        host can use, you must have OProfile version 0.9.4 or
                         greater installed on the host.</para>
                         <para>You can locate both the viewer and server from
-                        <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/oprofileui/'></ulink>
+                        <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/oprofileui/'></ulink>.
                         You can also find more information on setting up and
                         using this tool in the
                         "<ulink url='&YOCTO_DOCS_PROF_URL;#profile-manual-oprofile'>OProfile</ulink>"
@@ -1292,64 +1311,71 @@ directory.</para></listitem>
                     <listitem><para><emphasis><filename>Lttng2.0 ust trace import</filename>:</emphasis>
                         Selecting this tool transfers the remote target's
                         <filename>Lttng</filename> tracing data back to the local host machine
-                        and uses the <filename>Lttng</filename> Eclipse plug-in to graphically
+                        and uses the Lttng Eclipse plug-in to graphically
                         display the output.
-                        For information on how to use <filename>Lttng</filename> to trace an application,
-                        see <ulink url='http://lttng.org/documentation'></ulink>.
+                        For information on how to use Lttng to trace an application,
+                        see <ulink url='http://lttng.org/documentation'></ulink>
+                        and the 
+                        "<ulink url='&YOCTO_DOCS_PROF_URL;#lttng-linux-trace-toolkit-next-generation'>LTTng (Linux Trace Toolkit, next generation)</ulink>" 
+                        section, which is in the Yocto Project Profiling and Tracing Manual.
                         <note>Do not use <filename>Lttng-user space (legacy)</filename> tool.
                             This tool no longer has any upstream support.</note>
                         </para>
                         <para>Before you use the <filename>Lttng2.0 ust trace import</filename> tool,
-                        you need to setup the <filename>Lttng</filename> Eclipse plug-in and create a
-                        <filename>Tracing</filename> project.
+                        you need to setup the Lttng Eclipse plug-in and create a
+                        Tracing project.
                         Do the following:
                         <orderedlist>
-                            <listitem><para>Select <filename>Window -> Open Perspective -> Other</filename>
-                                and then select <filename>Tracing</filename>.</para></listitem>
-                            <listitem><para>Click <filename>OK</filename> to change the Eclipse perspective
-                                into the <filename>Tracing</filename> perspective.</para></listitem>
-                            <listitem><para>Create a new <filename>Tracing</filename> project by selecting
-                                <filename>File -> New -> Project</filename>.</para></listitem>
-                            <listitem><para>Choose <filename>Tracing -> Tracing Project</filename>.
+                            <listitem><para>Select "Open Perspective" from the 
+                                "Window" menu and then select "Tracing".</para></listitem>
+                            <listitem><para>Click "OK" to change the Eclipse perspective
+                                into the Tracing perspective.</para></listitem>
+                            <listitem><para>Create a new Tracing project by selecting
+                                "Project" from the "File -> New" menu.</para></listitem>
+                            <listitem><para>Choose "Tracing Project" from the 
+                                "Tracing" menu.
                                 </para></listitem>
                             <listitem><para>Generate your tracing data on the remote target.
                                 </para></listitem>
-                            <listitem><para>Click
-                                <filename>Yocto Project Tools -> Lttng2.0 ust trace import</filename>
-                                to start the data import process.</para></listitem>
+                            <listitem><para>Select "Lttng2.0 ust trace import" from 
+                                the "Yocto Project Tools" menu to
+                                start the data import process.</para></listitem>
                             <listitem><para>Specify your remote connection name.</para></listitem>
                             <listitem><para>For the Ust directory path, specify the location of
                                 your remote tracing data.
                                 Make sure the location ends with <filename>ust</filename> (e.g.
-                                <filename>/usr/mysession/ust</filename>.</para></listitem>
-                            <listitem><para>Click <filename>OK</filename> to complete the import process.
+                                <filename>/usr/mysession/ust</filename>).</para></listitem>
+                            <listitem><para>Click "OK" to complete the import process.
                                 The data is now in the local tracing project you created.</para></listitem>
                             <listitem><para>Right click on the data and then use the menu to
-                                <filename>Select Trace Type... -> Common Trace Format -> Generic CTF Trace</filename>
-                                to map the tracing type.</para></listitem>
-                            <listitem><para>Right click the mouse and select <filename>Open</filename>
-                                to bring up the Eclipse <filename>Lttng</filename> Trace Viewer so you
+                                Select "Generic CTF Trace" from the 
+                                "Trace Type... -> Common Trace Format" menu to map 
+                                the tracing type.</para></listitem>
+                            <listitem><para>Right click the mouse and select "Open"
+                                to bring up the Eclipse Lttng Trace Viewer so you
                                 view the tracing data.</para></listitem>
                         </orderedlist></para></listitem>
                     <listitem><para><emphasis><filename>PowerTOP</filename>:</emphasis> Selecting this tool runs
-                        <filename>powertop</filename> on the remote target machine and displays the results in a
-                        new view called <filename>powertop</filename>.</para>
-                        <para><filename>Time to gather data(sec):</filename> is the time passed in seconds before data
+                        PowerTOP on the remote target machine and displays the results in a
+                        new view called PowerTOP.</para>
+                        <para>The "Time to gather data(sec):" field is the time passed in seconds before data
                         is gathered from the remote target for analysis.</para>
-                        <para><filename>show pids in wakeups list:</filename> corresponds to the
+                        <para>The "show pids in wakeups list:" field corresponds to the
                         <filename>-p</filename> argument
-                        passed to <filename>powertop</filename>.</para></listitem>
-                        <listitem><para><emphasis><filename>LatencyTOP and Perf</filename>:</emphasis>
-                        <filename>latencytop</filename> identifies system latency, while
-                        <filename>perf</filename> monitors the system's
-                        performance counter registers.
+                        passed to <filename>PowerTOP</filename>.</para></listitem>
+                    <listitem><para><emphasis><filename>LatencyTOP and Perf</filename>:</emphasis>
+                        LatencyTOP identifies system latency, while
+                        Perf monitors the system's performance counter registers.
                         Selecting either of these tools causes an RSE terminal view to appear
                         from which you can run the tools.
                         Both tools refresh the entire screen to display results while they run.
-                        For more informationi on setting up and using <filename>perf</filename>,
+                        For more information on setting up and using <filename>perf</filename>,
                         see the
                         "<ulink url='&YOCTO_DOCS_PROF_URL;#profile-manual-perf'>perf</ulink>"
                         section in the Yocto Project Profiling and Tracing Manual.
+                        For information on LatencyTOP, see the
+                        <ulink url='https://latencytop.org/'>LatencyTOP</ulink>
+                        website.
                         </para></listitem>
                 </itemizedlist>
             </para>
@@ -1359,9 +1385,9 @@ directory.</para></listitem>
             <title>Customizing an Image Using a BitBake Commander Project and Hob</title>
 
             <para>
-                Within Eclipse, you can create a Yocto BitBake Commander project,
-                edit the metadata, and then use the
-                <ulink url='&YOCTO_HOME_URL;/projects/hob'>Hob</ulink> to build a customized
+                Within the Eclipse IDE, you can create a Yocto BitBake Commander project,
+                edit the <link linkend='metadata'>Metadata</link>, and then use 
+                <ulink url='&YOCTO_HOME_URL;/tools-resources/projects/hob'>Hob</ulink> to build a customized
                 image all within one IDE.
             </para>
 
@@ -1371,31 +1397,35 @@ directory.</para></listitem>
                 <para>
                     To create a Yocto BitBake Commander project, follow these steps:
                     <orderedlist>
-                        <listitem><para>Select <filename>Window -> Open Perspective -> Other</filename>
-                            and then choose <filename>Bitbake Commander</filename>.</para></listitem>
-                        <listitem><para>Click <filename>OK</filename> to change the Eclipse perspective into the
-                            Bitbake Commander perspective.</para></listitem>
-                        <listitem><para>Select <filename>File -> New -> Project</filename> to create a new Yocto
+                        <listitem><para>Select "Other" from the 
+                            "Window -> Open Perspective" menu 
+                            and then choose "Bitbake Commander".</para></listitem>
+                        <listitem><para>Click "OK" to change the perspective to
+                            Bitbake Commander.</para></listitem>
+                        <listitem><para>Select "Project" from the "File -> New"
+                            menu to create a new Yocto
                             Bitbake Commander project.</para></listitem>
-                        <listitem><para>Choose <filename>Yocto Project Bitbake Commander -> New Yocto Project</filename>
-                            and click <filename>Next</filename>.</para></listitem>
+                        <listitem><para>Choose "New Yocto Project" from the 
+                            "Yocto Project Bitbake Commander" menu and click 
+                            "Next".</para></listitem>
                         <listitem><para>Enter the Project Name and choose the Project Location.
-                            The Yocto project's metadata files will be put under the directory
+                            The Yocto project's Metadata files will be put under the directory
                             <filename>&lt;project_location&gt;/&lt;project_name&gt;</filename>.
                             If that directory does not exist, you need to check
                             the "Clone from Yocto Git Repository" box, which would execute a
-                            <filename>git clone</filename> command to get the project's metadata files.
+                            <filename>git clone</filename> command to get the project's Metadata files.
                             </para></listitem>
                         <listitem><para>Select <filename>Finish</filename> to create the project.</para></listitem>
                     </orderedlist>
                 </para>
             </section>
 
-            <section id='editing-the-metadata-files'>
-                <title>Editing the Metadata Files</title>
+            <section id='editing-the-metadata'>
+                <title>Editing the Metadata</title>
 
                 <para>
-                    After you create the Yocto Bitbake Commander project, you can modify the metadata files
+                    After you create the Yocto Bitbake Commander project, you can modify the 
+                    <link linkend='metadata'>Metadata</link> files
                     by opening them in the project.
                     When editing recipe files (<filename>.bb</filename> files), you can view BitBake
                     variable values and information by hovering the mouse pointer over the variable name and
@@ -1403,10 +1433,11 @@ directory.</para></listitem>
                 </para>
 
                 <para>
-                    To edit the metadata, follow these steps:
+                    To edit the Metadata, follow these steps:
                     <orderedlist>
                         <listitem><para>Select your Yocto Bitbake Commander project.</para></listitem>
-                        <listitem><para>Select <filename>File -> New -> Yocto BitBake Commander -> BitBake Recipe</filename>
+                        <listitem><para>Select "BitBake Recipe" from the 
+                        "File -> New -> Yocto BitBake Commander" menu 
                             to open a new recipe wizard.</para></listitem>
                         <listitem><para>Point to your source by filling in the "SRC_URL" field.
                             For example, you can add a recipe to your
@@ -1419,24 +1450,28 @@ directory.</para></listitem>
                             license checksum values and to auto-generate the recipe filename.</para></listitem>
                         <listitem><para>Fill in the "Description" field.</para></listitem>
                         <listitem><para>Be sure values for all required fields exist.</para></listitem>
-                        <listitem><para>Click <filename>Finish</filename>.</para></listitem>
+                        <listitem><para>Click "Finish".</para></listitem>
                     </orderedlist>
                 </para>
             </section>
 
-            <section id='buiding-and-customizing-the-image'>
-                <title>Building and Customizing the Image</title>
+            <section id='biding-and-customizing-the-image-using-hob'>
+                <title>Building and Customizing the Image Using Hob</title>
 
                 <para>
-                    To build and customize the image in Eclipse, follow these steps:
+                    To build and customize the image using Hob from within the 
+                    Eclipse IDE, follow these steps:
                     <orderedlist>
                         <listitem><para>Select your Yocto Bitbake Commander project.</para></listitem>
-                        <listitem><para>Select <filename>Project -> Launch HOB</filename>.</para></listitem>
-                        <listitem><para>Enter the Build Directory where you want to put your final images.</para></listitem>
-                        <listitem><para>Click <filename>OK</filename> to launch Hob.</para></listitem>
+                        <listitem><para>Select "Launch Hob" from the "Project"
+                            menu.</para></listitem>
+                        <listitem><para>Enter the 
+                            <link linkend='build-directory'>Build Directory</link>
+                            where you want to put your final images.</para></listitem>
+                        <listitem><para>Click "OK" to launch Hob.</para></listitem>
                         <listitem><para>Use Hob to customize and build your own images.
                             For information on Hob, see the
-                            <ulink url='&YOCTO_HOME_URL;/projects/hob'>Hob Project Page</ulink> on the
+                            <ulink url='&YOCTO_HOME_URL;/tools-resources/projects/hob'>Hob Project Page</ulink> on the
                             Yocto Project website.</para></listitem>
                     </orderedlist>
                 </para>
@@ -1445,7 +1480,7 @@ directory.</para></listitem>
     </section>
 
     <section id='workflow-using-stand-alone-cross-development-toolchains'>
-        <title>Workflow Using Stand-alone Cross-development Toolchains</title>
+        <title>Workflow Using Stand-Alone Cross-Development Toolchains</title>
 
         <para>
             If you want to develop an application without prior installation
@@ -1473,7 +1508,8 @@ directory.</para></listitem>
                     support development using actual hardware.
                     For example, the area might contain
                     <filename>.hddimg</filename> files that combine the
-                    kernel image with the filesystem, boot loaders, etc.
+                    kernel image with the filesystem, boot loaders, and 
+                    so forth.
                     Be sure to get the files you need for your particular
                     development process.</para>
                     <para>If you are going to develop your application and
@@ -1660,7 +1696,7 @@ directory.</para></listitem>
      $ bitbake -c compile -f &lt;name_of_package&gt;
                     </literallayout>
                     The <filename>-f</filename> or <filename>--force</filename>
-                    option forces re-execution of the specified task.
+                    option forces the specified task to execute.
                     If you find problems with your code, you can just keep editing and
                     re-testing iteratively until things work as expected.
                     <note>All the modifications you make to the temporary source code
@@ -1677,7 +1713,7 @@ directory.</para></listitem>
                     <literallayout class='monospaced'>
      $ quilt refresh
                     </literallayout>
-                    At this point the <filename>my_changes.patch</filename> file has all your edits made
+                    At this point, the <filename>my_changes.patch</filename> file has all your edits made
                     to the <filename>file1.c</filename>, <filename>file2.c</filename>, and
                     <filename>file3.c</filename> files.</para>
                     <para>You can find the resulting patch file in the <filename>patches/</filename>
@@ -1757,7 +1793,7 @@ directory.</para></listitem>
      $ bitbake -c compile -f &lt;name_of_package&gt;
                     </literallayout>
                     The <filename>-f</filename> or <filename>--force</filename>
-                    option forces re-execution of the specified task.
+                    option forces the specified task to execute.
                     If you find problems with your code, you can just keep editing and
                     re-testing iteratively until things work as expected.
                     <note>All the modifications you make to the temporary source code
@@ -1834,17 +1870,19 @@ directory.</para></listitem>
     <title>Image Development Using Hob</title>
 
     <para>
-        The <ulink url='&YOCTO_HOME_URL;/projects/hob'>Hob</ulink> is a graphical user interface for the
+        The <ulink url='&YOCTO_HOME_URL;/tools-resources/projects/hob'>Hob</ulink> is a graphical user interface for the
         OpenEmbedded build system, which is based on BitBake.
         You can use the Hob to build custom operating system images within the Yocto Project build environment.
-        Hob simply provides a friendly interface over the build system used during system development.
+        Hob simply provides a friendly interface over the build system used during development.
         In other words, building images with the Hob lets you take care of common build tasks more easily.
     </para>
 
     <para>
         For a better understanding of Hob, see the project page at
-        <ulink url='&YOCTO_HOME_URL;/projects/hob'></ulink> on the Yocto Project website.
-        The page has a short introductory training video on Hob.
+        <ulink url='&YOCTO_HOME_URL;/tools-resources/projects/hob'></ulink> 
+        on the Yocto Project website.
+        If you follow the "Documentation" link from the Hob page, you will 
+        find a short introductory training video on Hob.
         The following lists some features of Hob:
         <itemizedlist>
             <listitem><para>You can setup and run Hob using these commands:
@@ -1855,9 +1893,11 @@ directory.</para></listitem>
             <listitem><para>You can set the
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink>
                 for which you are building the image.</para></listitem>
-            <listitem><para>You can modify various policy settings such as the package format used to build with,
-                the parallelism BitBake uses, whether or not to build an external toolchain, and which host
-                to build against.</para></listitem>
+            <listitem><para>You can modify various policy settings such as the 
+                package format with which to build,
+                the parallelism BitBake uses, whether or not to build an 
+                external toolchain, and which host to build against.
+                </para></listitem>
             <listitem><para>You can manage
                 <link linkend='understanding-and-creating-layers'>layers</link>.</para></listitem>
             <listitem><para>You can select a base image and then add extra packages for your custom build.
@@ -1895,7 +1935,7 @@ directory.</para></listitem>
     <para>
         This command spawns a terminal with a shell prompt within the OpenEmbedded build environment.
         The <ulink url='&YOCTO_DOCS_REF_URL;#var-OE_TERMINAL'><filename>OE_TERMINAL</filename></ulink>
-        controls what type of shell is opened.
+        variable controls what type of shell is opened.
     </para>
 
     <para>
@@ -1935,7 +1975,7 @@ directory.</para></listitem>
 
         <para>
             It is also worth noting that <filename>devshell</filename> still works over
-            X11 forwarding and similar situations
+            X11 forwarding and similar situations.
         </para>
     </note>
 </section>

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

@@ -12,9 +12,9 @@
     closed, proprietary environment.
     Additionally, the Yocto Project uses specific tools and constructs as part of its development
     environment.
-    This chapter specifically addresses open source philosophy, using the 
+    This chapter specifically addresses open source philosophy, using the
     Yocto Project in a team environment, source repositories, Yocto Project
-    terms, licensing, the open source distributed version control system Git, 
+    terms, licensing, the open source distributed version control system Git,
     workflows, bug tracking, and how to submit changes.
 </para>
 
@@ -190,15 +190,15 @@
                         extensive testing while they continue to develop
                         locally using their primary development system.
                         </para></listitem>
-                    <listitem><para>Enable the PR Service when package feeds 
-                        need to be incremental with continually increasing 
-                        <ulink url='&YOCTO_DOCS_REF_URL;#var-PR'>PR</ulink> 
+                    <listitem><para>Enable the PR Service when package feeds
+                        need to be incremental with continually increasing
+                        <ulink url='&YOCTO_DOCS_REF_URL;#var-PR'>PR</ulink>
                         values.
-                        Typically, this situation occurs when you use or  
+                        Typically, this situation occurs when you use or
                         publish package feeds and use a shared state.
                         You should enable the PR Service for all users who
                         use the shared state pool.
-                        For more information on the PR Service, see the 
+                        For more information on the PR Service, see the
                         "<link linkend='working-with-a-pr-service'>Working With a PR Service</link>".
                         </para></listitem>
                 </itemizedlist>
@@ -218,9 +218,9 @@
             Of the SCMs BitBake supports, the
             Yocto Project team strongly recommends using
             <link linkend='git'>Git</link>.
-            Git is a distributed system that is easy to backup
-            (each checkout is a backup in itself), allows you to work
-            remotely, and then connects back to the infrastructure.
+            Git is a distributed system that is easy to backup,
+            allows you to work remotely, and then connects back to the
+            infrastructure.
             <note>
                 For information about BitBake and SCMs, see the
                 BitBake manual located in the
@@ -428,8 +428,8 @@
     </para>
 
     <para>
-        For any supported release of Yocto Project, you can go to the 
-        <ulink url='&YOCTO_HOME_URL;'>Yocto Project Website</ulink> and 
+        For any supported release of Yocto Project, you can go to the
+        <ulink url='&YOCTO_HOME_URL;'>Yocto Project Website</ulink> and
         select the "Downloads" tab and get a tarball of the release.
         You can also go to this site to download any supported BSP tarballs.
         Unpacking the tarball gives you a hierarchical Source Directory that lets you develop
@@ -461,7 +461,7 @@
                 <para>
                 <imagedata fileref="figures/index-downloads.png" align="center" width="6in" depth="3.5in" />
                 </para></listitem>
-            <listitem><para><emphasis>"Downloads" page for the 
+            <listitem><para><emphasis>"Downloads" page for the
                 <ulink url='&YOCTO_HOME_URL;'>Yocto Project Website</ulink>:</emphasis>
                 Access this page by going to the website and then selecting
                 the "Downloads" tab.
@@ -489,7 +489,7 @@
                 Append files are known as BitBake append files and <filename>.bbappend</filename> files.
                 The OpenEmbedded build system expects every append file to have a corresponding
                 recipe (<filename>.bb</filename>) file.
-                Furthermore, the append file and corresponding recipe file 
+                Furthermore, the append file and corresponding recipe file
                 must use the same root filename.
                 The filenames can differ only in the file type suffix used (e.g.
                 <filename>formfactor_0.0.bb</filename> and <filename>formfactor_0.0.bbappend</filename>).
@@ -641,7 +641,7 @@
                 </para></listitem>
             <listitem><para id='oe-core'><emphasis>OE-Core:</emphasis> A core set of Metadata originating
                 with OpenEmbedded (OE) that is shared between OE and the Yocto Project.
-                This Metadata is found in the <filename>meta</filename> directory of the 
+                This Metadata is found in the <filename>meta</filename> directory of the
                 <link linkend='source-directory'>Source Directory</link>.</para></listitem>
             <listitem><para><emphasis>Package:</emphasis> In the context of the Yocto Project,
                 this term refers to the packaged output from a baked recipe.
@@ -776,7 +776,7 @@
     <para>
         When you build an image using the Yocto Project, the build process uses a
         known list of licenses to ensure compliance.
-        You can find this list in the 
+        You can find this list in the
         <link linkend='source-directory'>Source Directory</link> at
         <filename>meta/files/common-licenses</filename>.
         Once the build completes, the list of all licenses found and used during that build are
@@ -869,7 +869,7 @@
             When you clone a Git repository, you end up with an identical copy of the
             repository on your development system.
             Once you have a local copy of a repository, you can take steps to develop locally.
-            For examples on how to clone Git repositories, see the 
+            For examples on how to clone Git repositories, see the
             "<link linkend='getting-setup'>Getting Set Up</link>" section.
         </para>
 
@@ -911,14 +911,14 @@
      $ cd poky
      $ git checkout -b &DISTRO_NAME; origin/&DISTRO_NAME;
             </literallayout>
-            In this example, the name of the top-level directory of your local 
-            <link linkend='source-directory'>Source Directory</link> 
+            In this example, the name of the top-level directory of your local
+            <link linkend='source-directory'>Source Directory</link>
             is <filename>poky</filename>,
-            and the name of that local working area (local branch) you just 
+            and the name of that local working area (local branch) you just
             created and checked out is <filename>&DISTRO_NAME;</filename>.
-            The files in your local repository now reflect the same files that 
-            are in the <filename>&DISTRO_NAME;</filename> development 
-            branch of the Yocto Project's <filename>poky</filename> 
+            The files in your local repository now reflect the same files that
+            are in the <filename>&DISTRO_NAME;</filename> development
+            branch of the Yocto Project's <filename>poky</filename>
             upstream repository.
             It is important to understand that when you create and checkout a
             local working branch based on a branch name,
@@ -1037,10 +1037,10 @@
                     repository and places it in your local Git repository.
                     You use this command to make sure you are synchronized with the repository
                     from which you are basing changes (.e.g. the master branch).</para></listitem>
-                <listitem><para><emphasis><filename>git push</filename>:</emphasis> 
-                    Sends all your committed local changes to an upstream Git 
+                <listitem><para><emphasis><filename>git push</filename>:</emphasis>
+                    Sends all your committed local changes to an upstream Git
                     repository (e.g. a contribution repository).
-                    The maintainer of the project draws from these repositories 
+                    The maintainer of the project draws from these repositories
                     when adding changes to the project’s master repository or
                     other development branch.
                     </para></listitem>
@@ -1088,9 +1088,11 @@
         The "master" branch is the “upstream” repository where the final builds of the project occur.
         The maintainer is responsible for allowing changes in from other developers and for
         organizing the underlying branch structure to reflect release strategies and so forth.
-        <note>You can see who is the maintainer for Yocto Project files by examining the
-        <filename>maintainers.inc</filename> file in the Yocto Project
-        <filename>meta-yocto/conf/distro/include</filename> directory.</note>
+        <note>For information on finding out who is responsible (maintains)
+            for a particular area of code, see the
+            "<link linkend='how-to-submit-a-change'>How to Submit a Change</link>"
+            section.
+        </note>
     </para>
 
     <para>
@@ -1158,8 +1160,8 @@
                 You can name these branches anything you like.
                 It is helpful to give them names associated with the particular feature or change
                 on which you are working.
-                Once you are done with a feature or change and have merged it 
-                into your local master branch, simply discard the temporary 
+                Once you are done with a feature or change and have merged it
+                into your local master branch, simply discard the temporary
                 branch.</para></listitem>
             <listitem><para><emphasis>Merge Changes:</emphasis> The <filename>git merge</filename>
                 command allows you to take the
@@ -1187,9 +1189,9 @@
                 <filename>send-pull-request</filename> that ship with the release to facilitate this
                 workflow.
                 You can find these scripts in the <filename>scripts</filename>
-                folder of the 
+                folder of the
                 <link linkend='source-directory'>Source Directory</link>.
-                For information on how to use these scripts, see the 
+                For information on how to use these scripts, see the
                 "<link linkend='pushing-a-change-upstream'>Using Scripts to Push a Change Upstream and Request a Pull</link>" section.
                 </para></listitem>
             <listitem><para><emphasis>Patch Workflow:</emphasis> This workflow allows you to notify the
@@ -1197,7 +1199,7 @@
                 for the "master" branch of the Git repository.
                 To send this type of change, you format the patch and then send the email using the Git commands
                 <filename>git format-patch</filename> and <filename>git send-email</filename>.
-                For information on how to use these scripts, see the 
+                For information on how to use these scripts, see the
                 "<link linkend='how-to-submit-a-change'>How to Submit a Change</link>"
                 section.
                 </para></listitem>
@@ -1249,8 +1251,13 @@
             <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.
-                You can even attach supporting files for output from logs by 
+                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>
         </orderedlist>
     </para>
@@ -1265,6 +1272,46 @@
         will want to extend, configure or optimize it for their specific uses.
         You should send patches to the appropriate mailing list so that they
         can be reviewed and merged by the appropriate maintainer.
+    </para>
+
+    <para>
+        Before submitting any change, be sure to find out who you should be
+        notifying.
+        Several methods exist through which you find out who you should be copying
+        or notifying:
+        <itemizedlist>
+            <listitem><para><emphasis>Maintenance File:</emphasis>
+                Examine the <filename>maintainers.inc</filename> file, which is
+                located in the
+                <link linkend='source-directory'>Source Directory</link>
+                at <filename>meta-yocto/conf/distro/include</filename>, to
+                see who is responsible for code.
+                </para></listitem>
+            <listitem><para><emphasis>Board Support Package (BSP) README Files:</emphasis>
+                For BSP maintainers of supported BSPs, you can examine
+                individual BSP <filename>README</filename> files.
+                Alternatively, you can examine the
+                <filename>MAINTAINERS</filename> file, which is found in the
+                <filename>meta-intel</filename>, for a list of all supported
+                BSP maintainers.
+                </para></listitem>
+            <listitem><para><emphasis>Search by File:</emphasis>
+                Using <link linkend='git'>Git</link>, you can enter the
+                following command to bring up a short list of all commits
+                against a specific file:
+                <literallayout class='monospaced'>
+     git shortlog -- &lt;filename&gt;
+                </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.
+                From the list, you can see who is responsible for the bulk of
+                the changes against the file.
+                </para></listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
         For a list of the Yocto Project and related mailing lists, see the
         "<ulink url='&YOCTO_DOCS_REF_URL;#resources-mailinglist'>Mailing lists</ulink>" section in
         the Yocto Project Reference Manual.
@@ -1273,7 +1320,7 @@
     <para>
         Here is some guidance on which mailing list to use for what type of change:
         <itemizedlist>
-            <listitem><para>For changes to the core 
+            <listitem><para>For changes to the core
                 <link linkend='metadata'>Metadata</link>, send your patch to the
                 <ulink url='&OE_LISTS_URL;/listinfo/openembedded-core'>openembedded-core</ulink> mailing list.
                 For example, a change to anything under the <filename>meta</filename> or
@@ -1388,7 +1435,7 @@
     </para>
 
     <para>
-        The next two sections describe general instructions for both pushing 
+        The next two sections describe general instructions for both pushing
         changes upstream and for submitting changes as patches.
     </para>
 
@@ -1446,7 +1493,7 @@
             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>" 
+            "<link linkend='how-to-submit-a-change'>How to Submit a Change</link>"
             section.
             For a description of the available mailing lists, see the
             "<ulink url='&YOCTO_DOCS_REF_URL;#resources-mailinglist'>Mailing Lists</ulink>"
@@ -1474,8 +1521,8 @@
                     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 
+                    For example, either of these two commands takes your most
+                    recent single commit and formats it as an email message in
                     the current directory:
                     <literallayout class='monospaced'>
      $ git format-patch -1
@@ -1487,7 +1534,7 @@
                     <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 
+                    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
@@ -1524,7 +1571,7 @@
                     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,
-                    see <filename>GIT-SEND-EMAIL(1)</filename> displayed using 
+                    see <filename>GIT-SEND-EMAIL(1)</filename> displayed using
                     the <filename>man git-send-email</filename> command.
                     </para></listitem>
             </itemizedlist>

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

@@ -23,9 +23,9 @@
 
     <para>
         The Yocto Project is an open-source collaboration project focused on embedded Linux development.
-        The project currently provides a build system, which is
+        The project currently provides a build system that is
         referred to as the OpenEmbedded build system in the Yocto Project documentation.
-        The Yocto Project provides various ancillary tools suitable for the embedded developer
+        The Yocto Project provides various ancillary tools for the embedded developer
         and also features the Sato reference User Interface, which is optimized for
         stylus driven, low-resolution screens.
     </para>

documentation/dev-manual/dev-manual.xml

@@ -51,6 +51,11 @@
                 <date>April 2013</date>
                 <revremark>Released with the Yocto Project 1.4 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>1.5</revnumber>
+                <date>Sometime in 2013</date>
+                <revremark>Released with the Yocto Project 1.5 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>

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

@@ -18,26 +18,6 @@
         to help you manage the complexity of the configuration and sources
         used to support multiple BSPs and Linux kernel types.
     </para>
-
-    <para>
-        In particular, the kernel tools allow you to specify only what you
-        must, and nothing more.
-        Where a complete Linux kernel <filename>.config</filename> includes
-        all the automatically selected <filename>CONFIG</filename> options,
-        the configuration fragments only need to contain the highest level
-        visible <filename>CONFIG</filename> options as presented by the Linux
-        kernel <filename>menuconfig</filename> system.
-        This reduces your maintenance effort and allows you
-        to further separate your configuration in ways that make sense for
-        your project.
-        A common split is policy and hardware.
-        For example, all your kernels might support
-        the <filename>proc</filename> and <filename>sys</filename> filesystems,
-        but only specific boards will require sound, USB, or specific drivers.
-        Specifying these individually allows you to aggregate them
-        together as needed, but maintain them in only one place.
-        Similar logic applies to source changes.
-    </para>
 </section>
 
 <section id='using-kernel-metadata-in-a-recipe'>
@@ -50,7 +30,7 @@
         This Metadata defines Board Support Packages (BSPs) that
         correspond to definitions in linux-yocto recipes for the same BSPs.
         A BSP consists of an aggregation of kernel policy and hardware-specific
-        feature enablement.
+        feature enablements.
         The BSP can be influenced from within the linux-yocto recipe.
         <note>
             Linux kernel source that contains kernel Metadata is said to be
@@ -223,7 +203,7 @@
             <filename>oe-core/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb</filename>
             to a recipe in your layer, <filename>FILESEXTRAPATHS</filename>
             is typically set to
-            <filename>${THISDIR}/${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PN'><filename>PN</filename></ulink><filename>}</filename>.
+            <filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-THISDIR'><filename>THISDIR</filename></ulink><filename>}/${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PN'><filename>PN</filename></ulink><filename>}</filename>.
             See the "<link linkend='modifying-an-existing-recipe'>Modifying an Existing Recipe</link>"
             section for more information.
         </para>
@@ -807,7 +787,7 @@
             </literallayout>
             The <filename>include</filename> command midway through the file
             includes the <filename>fri2.scc</filename> description that
-            defines all hardware enablement for the BSP that is common to all
+            defines all hardware enablements for the BSP that is common to all
             kernel types.
             Using this command significantly reduces duplication.
         </para>
@@ -909,7 +889,7 @@
             if you are reusing patches from an external tree and are not
             working on the patches, you might find the encapsulated feature
             to be appropriate.
-            Given this scenario, you don't need to create any branches in the
+            Given this scenario, you do not need to create any branches in the
             source repository.
             Rather, you just take the static patches you need and encapsulate
             them within a feature description.
@@ -1049,9 +1029,8 @@
             <listitem><para><filename>branch [ref]</filename>:
                 Creates a new branch relative to the current branch
                 (typically <filename>${KTYPE}</filename>) using
-                the currently checked-out branch, or "ref" if specified.</para>
-                <para><emphasis>TODO:</emphasis> Bruce, we need to clarify
-                the "relative to the current branch" bit.</para></listitem>
+                the currently checked-out branch, or "ref" if specified.
+                </para></listitem>
             <listitem><para><filename>define</filename>:
                 Defines variables, such as <filename>KMACHINE</filename>,
                 <filename>KTYPE</filename>, <filename>KARCH</filename>,

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

@@ -34,7 +34,7 @@
             <itemizedlist>
                 <listitem><para>"<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and Creating Layers</ulink>" for
                     general information on layers and how to create layers.</para></listitem>
-                <listitem><para>"<ulink url='&YOCTO_DOCS_DEV_URL;#get-your-layer-setup-for-the-build'>Get Your Layer Setup for the Build</ulink>" for
+                <listitem><para>"<ulink url='&YOCTO_DOCS_DEV_URL;#set-up-your-layer-for-the-build'>Set Up Your Layer for the Build</ulink>" for
                     specific instructions on setting up a layer for kernel
                     development.</para></listitem>
             </itemizedlist>
@@ -69,7 +69,7 @@
             See the "<link linkend='creating-and-preparing-a-layer'>Creating and Preparing a Layer</link>"
             section for some general resources.
             You can also see the
-            "<ulink url='&YOCTO_DOCS_DEV_URL;#get-your-layer-setup-for-the-build'>Get Your Layer Setup for the Build</ulink>" section
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#set-up-your-layer-for-the-build'>Set Up Your Layer for the Build</ulink>" section
             of the Yocto Project Development Manual for a detailed
             example.
         </para>
@@ -88,14 +88,22 @@
                 <literallayout class='monospaced'>
      &lt;your-layer&gt;/recipes-kernel/linux/linux-yocto_3.4.bbappend
                 </literallayout>
-                The append file should initially contain the following text:
+                The append file should initially extend the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESPATH'><filename>FILESPATH</filename></ulink>
+                search path by prepending the directory that contains your
+                files to the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></ulink>
+                variable as follows:
                 <literallayout class='monospaced'>
-     <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS'>FILESEXTRAPATHS</ulink> := "${THISDIR}/${PN}"
+     FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}"
                 </literallayout>
-                The path <filename>${THISDIR}/${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PN'><filename>PN</filename></ulink><filename>}</filename> expands
-                to "linux-yocto" in the current directory for this example.
-                If you add any new files that modify the kernel recipe,
-                you need to place them in your layer in the following area:
+                The path <filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-THISDIR'><filename>THISDIR</filename></ulink><filename>}/${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PN'><filename>PN</filename></ulink><filename>}</filename>
+                expands to "linux-yocto" in the current directory for this
+                example.
+                If you add any new files that modify the kernel recipe and you
+                have extended <filename>FILESPATH</filename> as
+                described above, you must place the files in your layer in the
+                following area:
                 <literallayout class='monospaced'>
      &lt;your-layer&gt;/recipes-kernel/linux/linux-yocto/
                 </literallayout>
@@ -148,29 +156,53 @@
             <para>
                 You can make wholesale or incremental changes to the Linux
                 kernel <filename>.config</filename> file by including a
-                <filename>defconfig</filename> or by specifying
-                configuration fragments in the <filename>SRC_URI</filename>.
+                <filename>defconfig</filename> and by specifying
+                configuration fragments in the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>.
             </para>
 
             <para>
-                If you have a complete Linux kernel <filename>.config</filename>
-                file you want to use, copy it to the
-                <filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-FILES'><filename>FILES</filename></ulink><filename>}</filename>
-                directory within your layer and name it "defconfig".
-                Then, add the following line to your linux-yocto
+                If you have a final Linux kernel <filename>.config</filename>
+                file you want to use, copy it to a directory named
+                <filename>files</filename>, which must be in
+                your layer's <filename>recipes-kernel/linux</filename>
+                directory, and name the file "defconfig".
+                Then, add the following lines to your linux-yocto
                 <filename>.bbappend</filename> file in your layer:
                 <literallayout class='monospaced'>
+     FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
      SRC_URI += "file://defconfig"
                 </literallayout>
+                The <filename>SRC_URI</filename> tells the build system how to
+                search for the file, while the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></ulink>
+                extends the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESPATH'><filename>FILESPATH</filename></ulink>
+                variable (search directories) to include the
+                <filename>files</filename> directory you created for the
+                configuration changes.
             </para>
 
+            <note>
+                The build system applies the configurations from the
+                <filename>.config</filename> file before applying any
+                subsequent configuration fragments.
+                The final kernel configuration is a combination of the
+                configurations in the <filename>.config</filename> file and
+                any configuration fragments you provide.
+                You need to realize that if you have any configuration
+                fragments, the build system applies these on top of and
+                after applying the existing <filename>.config</filename>
+                file configurations.
+            </note>
+
             <para>
                 Generally speaking, the preferred approach is to determine the
                 incremental change you want to make and add that as a
                 configuration fragment.
                 For example, if you want to add support for a basic serial
-                console, create a file named <filename>8250.cfg</filename> in the
-                <filename>${FILES}</filename> directory with the following
+                console, create a file named <filename>8250.cfg</filename> in
+                the <filename>files</filename> directory with the following
                 content (without indentation):
                 <literallayout class='monospaced'>
      CONFIG_SERIAL_8250=y
@@ -181,10 +213,11 @@
      CONFIG_SERIAL_CORE=y
      CONFIG_SERIAL_CORE_CONSOLE=y
                 </literallayout>
-                Next, include this configuration fragment in a
-                <filename>SRC_URI</filename> statement in your
+                Next, include this configuration fragment and extend the
+                <filename>FILESPATH</filename> variable in your
                 <filename>.bbappend</filename> file:
                 <literallayout class='monospaced'>
+     FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
      SRC_URI += "file://8250.cfg"
                 </literallayout>
                 The next time you run BitBake to build the Linux kernel, BitBake
@@ -371,7 +404,7 @@
 
      WARNING: There were 2 hardware options requested that do not
               have a corresponding value present in the final ".config" file.
-              This probably means you aren't getting the config you wanted.
+              This probably means you are not't getting the config you wanted.
               The full list can be found in your kernel src dir at:
               meta/cfg/standard/mybsp/mismatch.cfg
                 </literallayout>
@@ -725,7 +758,7 @@
             "What changes have been applied to this tree?"
             Rather than using "grep" across directories to see what has
             changed, you can use Git to inspect or search the kernel tree.
-            Using Git is an efficent way to see what has changed in the tree.
+            Using Git is an efficient way to see what has changed in the tree.
         </para>
 
         <section id='what-changed-in-a-kernel'>
@@ -766,7 +799,7 @@
             </para>
 
             <para>
-                To see short, oneline summaries of changes use the
+                To see short, one line summaries of changes use the
                 <filename>git log</filename> command:
                 <literallayout class='monospaced'>
      $ git log --oneline origin/standard/base..origin/standard/emenlow

documentation/kernel-dev/kernel-dev-concepts-appx.xml

@@ -132,7 +132,7 @@
                 The "Yocto Project Baseline Kernel" contains functionality that is common to every kernel
                 type and BSP that is organized further up the tree.
                 Placing these common features in the
-                tree this way means features don't have to be duplicated along individual branches of the
+                tree this way means features do not have to be duplicated along individual branches of the
                 structure.
             </para>
             <para>

documentation/kernel-dev/kernel-dev-maint-appx.xml

@@ -14,8 +14,8 @@
             <ulink url='&YOCTO_GIT_URL;/cgit.cgi'>&YOCTO_GIT_URL;/cgit.cgi</ulink>
             and can be shipped as part of a Yocto Project release.
             The team creates these repositories by
-            compiling and executing the set of feature descriptions for every BSP/feature
-            in the product.
+            compiling and executing the set of feature descriptions for every BSP
+            and feature in the product.
             Those feature descriptions list all necessary patches,
             configuration, branching, tagging and feature divisions found in a kernel.
             Thus, the Yocto Project kernel repository (or tree) is built.
@@ -59,8 +59,6 @@
             particular kernel branch.
             Instead, you should use Git directly to discover the changes in a branch.
             Using Git is an efficient and flexible way to inspect changes to the kernel.
-            For examples showing how to use Git to inspect kernel commits, see the following sections
-            in this chapter.
             <note>
                 Ground up reconstruction of the complete kernel tree is an action only taken by the
                 Yocto Project team during an active development cycle.
@@ -210,7 +208,9 @@
             the build tree directory.
             The files include the final <filename>.config</filename> file, all the <filename>.o</filename>
             files, the <filename>.a</filename> files, and so forth.
-            Since each machine or BSP has its own separate build directory in its own separate branch
+            Since each machine or BSP has its own separate 
+            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
+            in its own separate branch
             of the Git repository, you can easily switch between different builds.
         </para>
     </section>

documentation/kernel-dev/kernel-dev.xml

@@ -36,6 +36,11 @@
                 <date>April 2013</date>
                 <revremark>Released with the Yocto Project 1.4 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>1.5</revnumber>
+                <date>Sometime in 2013</date>
+                <revremark>Released with the Yocto Project 1.5 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>

documentation/poky.ent

@@ -1,7 +1,9 @@
-<!ENTITY DISTRO "1.4">
-<!ENTITY DISTRO_NAME "dylan">
-<!ENTITY YOCTO_DOC_VERSION "1.4">
-<!ENTITY POKYVERSION "9.0">
+<!ENTITY DISTRO "1.5">
+<!ENTITY DISTRO_COMPRESSED "15">
+<!ENTITY DISTRO_NAME "tbd">
+<!ENTITY YOCTO_DOC_VERSION "1.5">
+<!ENTITY POKYVERSION "10.0.0">
+<!ENTITY POKYVERSION_COMPRESSED "1000">
 <!ENTITY YOCTO_POKY "poky-&DISTRO_NAME;-&POKYVERSION;">
 <!ENTITY COPYRIGHT_YEAR "2010-2013">
 <!ENTITY YOCTO_DL_URL "http://downloads.yoctoproject.org">
@@ -12,6 +14,7 @@
 <!ENTITY YOCTO_AB_URL "http://autobuilder.yoctoproject.org">
 <!ENTITY YOCTO_GIT_URL "http://git.yoctoproject.org">
 <!ENTITY YOCTO_ADTREPO_URL "http://adtrepo.yoctoproject.org">
+<!ENTITY YOCTO_RELEASE_NOTES "&YOCTO_HOME_URL;/download/yocto-project-&DISTRO_COMPRESSED;-poky-&POKYVERSION_COMPRESSED;">
 <!ENTITY OE_HOME_URL "http://www.openembedded.org">
 <!ENTITY OE_LISTS_URL "http://lists.linuxtogo.org/cgi-bin/mailman">
 <!ENTITY OE_DOCS_URL "http://docs.openembedded.org">
@@ -56,6 +59,6 @@
      diffutils diffstat git cpp gcc gcc-c++ eglibc-devel texinfo chrpath \
      ccache">
 <!ENTITY OPENSUSE_HOST_PACKAGES_ESSENTIAL "python gcc gcc-c++ git chrpath make wget python-xml \
-     diffstat texinfo python-curses">
+     diffstat texinfo python-curses patch">
 <!ENTITY CENTOS_HOST_PACKAGES_ESSENTIAL "gawk make wget tar bzip2 gzip python unzip perl patch \
      diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath">

documentation/profile-manual/profile-manual.xml

@@ -36,6 +36,11 @@
                 <date>April 2013</date>
                 <revremark>Released with the Yocto Project 1.4 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>1.5</revnumber>
+                <date>Sometime in 2013</date>
+                <revremark>Released with the Yocto Project 1.5 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>

documentation/ref-manual/faq.xml

@@ -173,7 +173,8 @@
                 (<filename>.deb</filename>), or RPM.
                 You can then upgrade the packages using the package tools on 
                 the device, much like on a desktop distribution such as 
-                Ubuntu or Fedora.
+                Ubuntu or Fedora. 
+                However, package management on the target is entirely optional.
             </para>
         </answer>
     </qandaentry>
@@ -364,7 +365,7 @@
                 data that causes lots of network, disk and CPU activity and 
                 is sensitive to even single-bit failures in any of these areas.
                 True random failures have always been traced back to hardware 
-                or visualization issues.
+                or virtualization issues.
             </para>
         </answer>
     </qandaentry>
@@ -406,7 +407,7 @@
         <answer>
             <para>
                 You need to create a form factor file as described in the
-                "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-filelayout-misc-recipes'>Miscellaneous Recipe Files</ulink>"
+                "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-filelayout-misc-recipes'>Miscellaneous BSP-Specific Recipe Files</ulink>"
                 section in the Yocto Project Board Support Packages (BSP)
                 Developer's Guide.
                 Set the <filename>HAVE_TOUCHSCREEN</filename> variable equal to 
@@ -430,7 +431,7 @@
                 automatically bring up network interfaces.
                 Therefore, you will need to add a BSP-specific netbase that includes an interfaces
                 file.
-                See the "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-filelayout-misc-recipes'>Miscellaneous Recipe Files</ulink>"
+                See the "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-filelayout-misc-recipes'>Miscellaneous BSP-Specific Recipe Files</ulink>"
                 section in the Yocto Project Board Support Packages (BSP)
                 Developer's Guide for information on creating these types of 
                 miscellaneous recipe files.

documentation/ref-manual/introduction.xml

@@ -20,9 +20,9 @@
         For task-based information using the Yocto Project, see the
         <ulink url='&YOCTO_DOCS_DEV_URL;'>Yocto Project Development Manual</ulink>
         and the <ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;'>Yocto Project Linux Kernel Development Manual</ulink>.
-        For Board Support Package (BSP) structure information, see the 
+        For Board Support Package (BSP) structure information, see the
         <ulink url='&YOCTO_DOCS_BSP_URL;'>Yocto Project Board Support Package (BSP) Developer's Guide</ulink>.
-        You can also find lots of Yocto Project information on the 
+        You can also find lots of Yocto Project information on the
         <ulink url="&YOCTO_HOME_URL;">Yocto Project website</ulink>.
     </para>
 </section>
@@ -33,7 +33,7 @@
         This reference manual consists of the following:
         <itemizedlist>
             <listitem><para><emphasis>
-                <link linkend='usingpoky'>Using the Yocto Project</link>:</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>
@@ -103,22 +103,19 @@
         <para>
             Currently, the Yocto Project is supported on the following distributions:
             <itemizedlist>
-                <listitem><para>Ubuntu 10.04.4 LTS</para></listitem>
+                <listitem><para>Ubuntu 10.04</para></listitem>
                 <listitem><para>Ubuntu 11.10</para></listitem>
-                <listitem><para>Ubuntu 12.04.1 LTS</para></listitem>
-                <listitem><para>Ubuntu 12.04.1 LTS</para></listitem>
+                <listitem><para>Ubuntu 12.04 (LTS)</para></listitem>
                 <listitem><para>Ubuntu 12.10</para></listitem>
-                <listitem><para>Fedora release 16 (Verne)</para></listitem>
+                <listitem><para>Ubuntu 13.04</para></listitem>
                 <listitem><para>Fedora release 17 (Beefy Miracle)</para></listitem>
                 <listitem><para>Fedora release 18 (Spherical Cow)</para></listitem>
-                <listitem><para>CentOS release 5.6 (Final)</para></listitem>
-                <listitem><para>CentOS release 5.7 (Final)</para></listitem>
-                <listitem><para>CentOS release 5.8 (Final)</para></listitem>
                 <listitem><para>CentOS release 6.3 (Final)</para></listitem>
-                <listitem><para>Debian GNU/Linux 6.0.6 (squeeze)</para></listitem>
-                <listitem><para>openSUSE 11.4</para></listitem>
-                <listitem><para>openSUSE 12.1</para></listitem>
+                <listitem><para>CentOS release 6.4 (Final)</para></listitem>
+                <listitem><para>Debian GNU/Linux 6.0 (squeeze)</para></listitem>
+                <listitem><para>Debian GNU/Linux 7.0</para></listitem>
                 <listitem><para>openSUSE 12.2</para></listitem>
+                <listitem><para>openSUSE 12.3</para></listitem>
             </itemizedlist>
         </para>
 
@@ -161,7 +158,7 @@
                         Packages needed if you are going to build out the
                         Yocto Project documentation manuals:
                         <literallayout class='monospaced'>
-     $ sudo apt-get install make xsltproc docbook-utils fop
+     $ sudo apt-get install make xsltproc docbook-utils fop dblatex xmlto
                         </literallayout></para></listitem>
                     <listitem><para><emphasis>ADT Installer Extras:</emphasis>
                         Packages needed if you are going to be using the
@@ -196,7 +193,7 @@
                         Yocto Project documentation manuals:
                         <literallayout class='monospaced'>
      $ sudo yum install make docbook-style-dsssl docbook-style-xsl \
-     docbook-dtds docbook-utils fop libxslt
+     docbook-dtds docbook-utils fop libxslt dblatex xmlto
                         </literallayout></para></listitem>
                     <listitem><para><emphasis>ADT Installer Extras:</emphasis>
                         Packages needed if you are going to be using the
@@ -230,7 +227,7 @@
                         Packages needed if you are going to build out the
                         Yocto Project documentation manuals:
                         <literallayout class='monospaced'>
-     $ sudo zypper install make fop xsltproc
+     $ sudo zypper install make fop xsltproc dblatex xmlto
                         </literallayout></para></listitem>
                     <listitem><para><emphasis>ADT Installer Extras:</emphasis>
                         Packages needed if you are going to be using the
@@ -265,7 +262,7 @@
                         Yocto Project documentation manuals:
                         <literallayout class='monospaced'>
      $ sudo yum -y install make docbook-style-dsssl docbook-style-xsl \
-     docbook-dtds docbook-utils fop libxslt
+     docbook-dtds docbook-utils fop libxslt dblatex xmlto
                         </literallayout></para></listitem>
                     <listitem><para><emphasis>ADT Installer Extras:</emphasis>
                         Packages needed if you are going to be using the

documentation/ref-manual/migration.xml

@@ -258,8 +258,8 @@
                     The runtime package specific variables 
                     <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>,
                     <link linkend='var-RRECOMMENDS'><filename>RRECOMMENDS</filename></link>,
-                    <filename>RSUGGESTS</filename>, 
-                    <filename>RPROVIDES</filename>,
+                    <link linkend='var-RSUGGESTS'><filename>RSUGGESTS</filename></link>, 
+                    <link linkend='var-RPROVIDES'><filename>RPROVIDES</filename></link>,
                     <link linkend='var-RCONFLICTS'><filename>RCONFLICTS</filename></link>,
                     <link linkend='var-RREPLACES'><filename>RREPLACES</filename></link>,
                     <link linkend='var-FILES'><filename>FILES</filename></link>,
@@ -310,9 +310,13 @@
                     you previously added to <filename>OVERRIDES</filename>,
                     you might now need to add it to 
                     <filename>FILESOVERRIDES</filename> unless you are already 
-                    adding it through the <filename>MACHINEOVERRIDES</filename> 
-                    or <filename>DISTROOVERRIDES</filename> variables, 
-                    as appropriate.
+                    adding it through the 
+                    <link linkend='var-MACHINEOVERRIDES'><filename>MACHINEOVERRIDES</filename></link> 
+                    or <link linkend='var-DISTROOVERRIDES'><filename>DISTROOVERRIDES</filename></link>
+                    variables, as appropriate.
+                    For more related changes, see the
+                    "<link linkend='migration-1.4-variables'>Variables</link>"
+                    section.
                     </para></listitem>
             </itemizedlist>
         </para>
@@ -331,6 +335,24 @@
         </para>
     </section>
 
+    <section id='migration-1.4-custom-interfaces-file-netbase-change'>
+        <title>Custom Interfaces File (netbase change)</title>
+
+        <para>
+            If you have created your own custom 
+            <filename>etc/network/interfaces</filename> file by creating 
+            an append file for the <filename>netbase</filename> recipe, 
+            you now need to create an append file for the 
+            <filename>init-ifupdown</filename> recipe instead, which you can 
+            find in the 
+            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+            at <filename>meta/recipes-core/init-ifupdown</filename>.
+            For information on how to use append files, see the 
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#using-bbappend-files'>Using .bbappend Files</ulink>"
+            in the Yocto Project Development Manual.
+        </para>
+    </section>
+
     <section id='migration-1.4-remote-debugging'>
         <title>Remote Debugging</title>
 
@@ -350,14 +372,54 @@
         <title>Variables</title>
 
         <para>
-            The <filename>SANITY_TESTED_DISTROS</filename> variable now uses a
-            distribution ID, which is composed of the host distributor ID 
-            followed by the release.
-            Previously, it was composed of the description field.
-            For example, "Ubuntu 12.10" becomes "Ubuntu-12.10". 
-            You do not need to worry about this change if you are not 
-            specifically setting this variable, or if you are
-            specifically setting it to "".
+            The following variables have changed:
+            <itemizedlist>
+                <listitem><para><emphasis><filename>SANITY_TESTED_DISTROS</filename>:</emphasis>
+                    This variable now uses a distribution ID, which is composed 
+                    of the host distributor ID followed by the release.
+                    Previously, 
+                    <link linkend='var-SANITY_TESTED_DISTROS'><filename>SANITY_TESTED_DISTROS</filename></link>
+                    was composed of the description field.
+                    For example, "Ubuntu 12.10" becomes "Ubuntu-12.10". 
+                    You do not need to worry about this change if you are not 
+                    specifically setting this variable, or if you are
+                    specifically setting it to "".
+                    </para></listitem>
+                <listitem><para><emphasis><filename>SRC_URI</filename>:</emphasis>
+                    The <filename>${</filename><link linkend='var-PN'><filename>PN</filename></link><filename>}</filename>, 
+                    <filename>${</filename><link linkend='var-PF'><filename>PF</filename></link><filename>}</filename>, 
+                    <filename>${</filename><link linkend='var-P'><filename>P</filename></link><filename>}</filename>, 
+                    and <filename>FILE_DIRNAME</filename> directories have been 
+                    dropped from the default value of the 
+                    <link linkend='var-FILESPATH'><filename>FILESPATH</filename></link>
+                    variable, which is used as the search path for finding files 
+                    referred to in 
+                    <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>. 
+                    If you have a recipe that relied upon these directories, 
+                    which would be unusual, then you will need to add the 
+                    appropriate paths within the recipe or, alternatively,
+                    rearrange the files. 
+                    The most common locations are still covered by 
+                    <filename>${BP}</filename>, <filename>${BPN}</filename>,
+                    and "files", which all remain in the default value of
+                    <link linkend='var-FILESPATH'><filename>FILESPATH</filename></link>. 
+                    </para></listitem>
+            </itemizedlist>           
+        </para>
+    </section>
+
+    <section id='migration-target-package-management-with-rpm'>
+        <title>Target Package Management with RPM</title>
+
+        <para>
+            If runtime package management is enabled and the RPM backend 
+            is selected, Smart is now installed for package download, dependency 
+            resolution, and upgrades instead of Zypper.
+            For more information on how to use Smart, run the following command 
+            on the target:
+            <literallayout class='monospaced'>
+     smart --help
+            </literallayout>
         </para>
     </section>
 

documentation/ref-manual/ref-bitbake.xml

@@ -23,8 +23,9 @@
     <note>
         BitBake strives to be a generic "task" executor that is capable of handling complex dependency relationships.
         As such, it has no real knowledge of what the tasks being executed actually do.
-        BitBake just considers a list of tasks with dependencies and handles metadata
-        that consists of variables in a certain format that get passed to the tasks.
+        BitBake just considers a list of tasks with dependencies and handles 
+        <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
+        consisting of variables in a certain format that get passed to the tasks.
     </note>
 
     <section id='ref-bitbake-parsing'>

documentation/ref-manual/ref-classes.xml

@@ -17,7 +17,7 @@
     <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
     Class files can also be pointed to by
     <link linkend='var-BUILDDIR'><filename>BUILDDIR</filename></link>
-    (e.g. <filename>build/</filename>)in the same way as
+    (e.g. <filename>build/</filename>) in the same way as
     <filename>.conf</filename> files in the <filename>conf</filename> directory.
     Class files are searched for in <link linkend='var-BBPATH'><filename>BBPATH</filename></link>
     using the same method by which <filename>.conf</filename> files are searched.
@@ -171,7 +171,7 @@
     <para>
         This class renames packages so that they follow the Debian naming
         policy (i.e. <filename>eglibc</filename> becomes <filename>libc6</filename>
-        and <filename>eglibc-devel</filename> becomes <filename>libc6-dev</filename>.
+        and <filename>eglibc-devel</filename> becomes <filename>libc6-dev</filename>.)
     </para>
 </section>
 
@@ -179,9 +179,10 @@
     <title>Pkg-config - <filename>pkgconfig.bbclass</filename></title>
 
     <para>
-        <filename>pkg-config</filename> brought standardization and this class
-        aims to smooth integration of <filename>pkg-config</filename>
-        into libraries that use it.
+        <filename>pkg-config</filename> provides a standard way to get 
+        header and library information.
+        This class aims to smooth integration of
+        <filename>pkg-config</filename> into libraries that use it.
     </para>
 
     <para>
@@ -192,37 +193,26 @@
     </para>
 </section>
 
-<section id='ref-classes-src-distribute'>
-    <title>Distribution of Sources - <filename>src_distribute_local.bbclass</filename></title>
+<section id='ref-classes-archiver'>
+    <title>Archiving Sources - <filename>archive*.bbclass</filename></title>
 
     <para>
-        Many software licenses require that source files be provided along with the binaries.
-        To simplify this process, two classes were created:
-        <filename>src_distribute.bbclass</filename> and
-        <filename>src_distribute_local.bbclass</filename>.
-    </para>
-
-    <para>
-        The results of these classes are <filename>tmp/deploy/source/</filename>
-        subdirectories with sources sorted by
-        <filename><link linkend='var-LICENSE'>LICENSE</link></filename> field.
-        If recipes list few licenses (or have entries like "Bitstream Vera"),
-        the source archive is placed in each license directory.
-    </para>
-
-    <para>
-        This class operates using three modes:
+        Many software licenses require that source code and other materials be
+        released with the binaries. 
+        To help with that task, the following classes are provided:
         <itemizedlist>
-            <listitem><para><emphasis>copy:</emphasis> Copies the files to the
-                distribution directory.</para></listitem>
-            <listitem><para><emphasis>symlink:</emphasis> Creates symbolic
-                links for the files to the distribution directory.
-                </para></listitem>
-            <listitem><para><emphasis>move+symlink:</emphasis> Moves the files
-                into the distribution directory and then creates symbolic
-                links back to where they originated.</para></listitem>
+            <listitem><filename>archive-original-sources.bbclass</filename></listitem>
+            <listitem><filename>archive-patched-sources.bbclass</filename></listitem>
+            <listitem><filename>archive-configured-sources.bbclass</filename></listitem>
+            <listitem><filename>archiver.bbclass</filename></listitem>
         </itemizedlist>
     </para>
+
+    <para>
+        For more details on the source archiver, see the
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#maintaining-open-source-license-compliance-during-your-products-lifecycle'>Maintaining Open Source License Compliance During Your Product's Lifecycle</ulink>"
+        section in the Yocto Project Development Manual.
+    </para>
 </section>
 
 <section id='ref-classes-perl'>
@@ -435,8 +425,8 @@
     <title>Host System Sanity Checks - <filename>sanity.bbclass</filename></title>
 
     <para>
-        This class checks to see if prerequisite software is present so that
-        users can be notified of potential problems that might affect their build.
+        This class checks to see if prerequisite software is present on the host system
+        so that users can be notified of potential problems that might affect their build.
         The class also performs basic user configuration checks from
         the <filename>local.conf</filename> configuration file to
         prevent common mistakes that cause build failures.
@@ -524,6 +514,54 @@
                 Any <filename>.pc</filename> file containing these paths is incorrect
                 since <filename>pkg-config</filename> itself adds the correct sysroot prefix
                 when the files are accessed.</para></listitem>
+            <listitem><para><emphasis><filename>textrel:</filename></emphasis>
+                Checks for ELF binaries that contain relocations in their 
+                <filename>.text</filename> sections, which can result in a 
+                performance impact at runtime.</para></listitem>
+            <listitem><para><emphasis><filename>pkgvarcheck:</filename></emphasis>
+                Checks through the variables 
+                <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>, 
+                <link linkend='var-RRECOMMENDS'><filename>RRECOMMENDS</filename></link>, 
+                <link linkend='var-RSUGGESTS'><filename>RSUGGESTS</filename></link>,
+                <link linkend='var-RCONFLICTS'><filename>RCONFLICTS</filename></link>,
+                <link linkend='var-RPROVIDES'><filename>RPROVIDES</filename></link>,
+                <link linkend='var-RREPLACES'><filename>RREPLACES</filename></link>, 
+                <link linkend='var-FILES'><filename>FILES</filename></link>,
+                <link linkend='var-ALLOW_EMPTY'><filename>ALLOW_EMPTY</filename></link>,
+                <filename>pkg_preinst</filename>, 
+                <filename>pkg_postinst</filename>, 
+                <filename>pkg_prerm</filename>
+                and <filename>pkg_postrm</filename>, and reports if there are 
+                variable sets that are not package-specific.
+                Using these variables without a package suffix is bad practice,
+                and might unnecessarily complicate dependencies of other packages
+                within the same recipe or have other unintended consequences.
+                </para></listitem>
+            <listitem><para><emphasis><filename>xorg-driver-abi:</filename></emphasis>
+                Checks that all packages containing Xorg drivers have ABI 
+                dependencies.
+                The <filename>xserver-xorg</filename> recipe provides driver 
+                ABI names.
+                All drivers should depend on the ABI versions that they have 
+                been built against. 
+                Driver recipes that include 
+                <filename>xorg-driver-input.inc</filename>
+                or <filename>xorg-driver-video.inc</filename> will 
+                automatically get these versions.
+                Consequently, you should only need to explicitly add 
+                dependencies to binary driver recipes.
+                </para></listitem>
+            <listitem><para><emphasis><filename>libexec:</filename></emphasis>
+                Checks if a package contains files in 
+                <filename>/usr/libexec</filename>.
+                This check is not performed if the 
+                <filename>libexecdir</filename> variable has been set 
+                explicitly to <filename>/usr/libexec</filename>.
+                </para></listitem>
+            <listitem><para><emphasis><filename>staticdev:</filename></emphasis>
+                Checks for static library files (<filename>*.a</filename>) in
+                non-<filename>staticdev</filename> packages.
+                </para></listitem>
             <listitem><para><emphasis><filename>la:</filename></emphasis>
                 Checks <filename>.la</filename> files for any <filename>TMPDIR</filename>
                 paths.
@@ -536,8 +574,63 @@
                 the specification for <filename>.desktop</filename> files.</para></listitem>
         </itemizedlist>
     </para>
+    <note>
+        You can use the <filename>WARN_QA</filename> and 
+        <filename>ERROR_QA</filename> variables to control the behavior of 
+        these checks at the global level (i.e. in your custom distro 
+        configuration).
+        However, to skip one or more checks in recipes, you should use 
+        <link linkend='var-INSANE_SKIP'><filename>INSANE_SKIP</filename></link>. 
+        For example, to skip the check for symbolic link 
+        <filename>.so</filename> files in the main package of a recipe, 
+        add the following to the recipe.
+        You need to realize that the package name override, in this example
+        <filename>${PN}</filename>, must be used:
+        <literallayout class='monospaced'>
+     INSANE_SKIP_${PN} += "dev-so"
+        </literallayout>
+        Please keep in mind that the QA checks exist in order to detect real 
+        or potential problems in the packaged output.
+        So exercise caution when disabling these checks.
+    </note>
 </section>
 
+<section id='ref-classes-rm-work'>
+    <title>Removing Work Files During the Build - <filename>rm_work.bbclass</filename></title>
+
+    <para>
+        The OpenEmbedded build system can use a substantial amount of disk 
+        space during the build process.
+        A portion of this space is the work files under the 
+        <filename>${TMPDIR}/work</filename> directory for each recipe. 
+        Once the build system generates the packages for a recipe, the work 
+        files for that recipe are no longer needed.
+        However, by default, the build system preserves these files
+        for inspection and possible debugging purposes.
+        If you would rather have these files deleted to save disk space 
+        as the build progresses, you can enable <filename>rm_work</filename>
+        by adding the following to your <filename>local.conf</filename> file,
+        which is found in the 
+        <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+        <literallayout class='monospaced'>
+    INHERIT += "rm_work"
+        </literallayout>
+        If you are modifying and building source code out of the work directory 
+        for a recipe, enabling <filename>rm_work</filename> will potentially 
+        result in your changes to the source being lost. 
+        To exclude some recipes from having their work directories deleted by
+        <filename>rm_work</filename>, you can add the names of the recipe or 
+        recipes you are working on to the <filename>RM_WORK_EXCLUDE</filename> 
+        variable, which can also be set in your <filename>local.conf</filename>
+        file.
+        Here is an example:
+        <literallayout class='monospaced'>
+    RM_WORK_EXCLUDE += "busybox eglibc"
+        </literallayout>
+    </para>
+</section>
+
+
 <section id='ref-classes-siteinfo'>
     <title>Autotools Configuration Data Cache - <filename>siteinfo.bbclass</filename></title>
 
@@ -681,12 +774,16 @@
         deploy.bbclass
         distrodata.bbclass
         dummy.bbclass
+        fontcache.bbclass
         gconf.bbclass
         gettext.bbclass
         gnomebase.bbclass
         gnome.bbclass
+        grub-efi.bbclass
+        gsettings.bbclass
         gtk-doc.bbclass
         gtk-icon-cache.bbclass
+        gtk-immodules-cache.bbclass
         gzipnative.bbclass
         icecc.bbclass
         image-empty.bbclass
@@ -708,6 +805,7 @@
         logging.bbclass
         meta.bbclass
         metadata_scm.bbclass
+        migrate_localcount.bbclass
         mime.bbclass
         mirrors.bbclass
         multilib*.bbclass
@@ -719,12 +817,14 @@
         packageinfo.bbclass
         patch.bbclass
         perlnative.bbclass
+        pixbufcache.bbclass
         pkg_distribute.bbclass
         pkg_metainfo.bbclass
         populate_sdk*.bbclass
         prexport.bbclass
         primport.bbclass
         prserv.bbclass
+        ptest.bbclass
         python-dir.bbclass
         pythonnative.bbclass
         qemu.bbclass
@@ -732,7 +832,6 @@
         qt4*.bbclass
         recipe_sanity.bbclass
         relocatable.bbclass
-        rm_work.bbclass
         scons.bbclass
         sdl.bbclass
         setuptools.bbclass
@@ -742,6 +841,7 @@
         sstate.bbclass
         staging.bbclass
         syslinux.bbclass
+        systemd.bbclass
         terminal.bbclass
         tinderclient.bbclass
         toolchain-scripts.bbclass

documentation/ref-manual/ref-manual.xml

@@ -67,6 +67,11 @@
                 <date>April 2013</date>
                 <revremark>Released with the Yocto Project 1.4 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>1.5</revnumber>
+                <date>Sometime in 2013</date>
+                <revremark>Released with the Yocto Project 1.5 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>

documentation/ref-manual/ref-variables.xml

@@ -100,7 +100,7 @@
                     By default, this directory is the same as the <link linkend='var-S'><filename>S</filename></link>
                     directory:
                     <literallayout class='monospaced'>
-     B = ${WORKDIR}/${BPN}/{PV}/
+     B = "${WORKDIR}/${BPN}/{PV}/"
                     </literallayout>
                     You can separate the (<filename>S</filename>) directory and the directory pointed to
                     by the <filename>B</filename> variable.
@@ -598,16 +598,35 @@ Core layer for images cannot be removed
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-COMPATIBLE_HOST'><glossterm>COMPATIBLE_HOST</glossterm>
+            <glossdef>
+                <para>A regular expression that resolves to one or more hosts
+                    (when the recipe is native) or one or more targets (when
+                    the recipe is non-native) with which a recipe is compatible.
+                    The regular expression is matched against
+                    <link linkend="var-HOST_SYS"><filename>HOST_SYS</filename></link>.
+                    You can use the variable to stop recipes from being built
+                    for classes of systems with which the recipes are not
+                    compatible.
+                    Stopping these builds is particularly useful with kernels.
+                    The variable also helps to increase parsing speed
+                    since the build system skips parsing recipes not
+                    compatible with the current system.</para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-COMPATIBLE_MACHINE'><glossterm>COMPATIBLE_MACHINE</glossterm>
             <glossdef>
-                <para>A regular expression that evaluates to match the machines
-                    with which the recipe works.
-                    You can use the variable to stop recipes from being run
-                    on machines for which they are not compatible.
-                    This is particularly useful with kernels.
-                    The variable also helps to increase parsing speed as
-                    further parsing of the recipe is skipped if it is found
-                    the current machine is not compatible.</para>
+                <para>A regular expression that resolves to one or more
+                    target machines with which a recipe is compatible.
+                    The regular expression is matched against
+                    <link linkend="var-MACHINEOVERRIDES"><filename>MACHINEOVERRIDES</filename></link>.
+                    You can use the variable to stop recipes from being built
+                    for machines with which the recipes are not compatible.
+                    Stopping these builds is particularly useful with kernels.
+                    The variable also helps to increase parsing speed
+                    since the build system skips parsing recipes not
+                    compatible with the current machine.</para>
             </glossdef>
         </glossentry>
 
@@ -723,7 +742,25 @@ Core layer for images cannot be removed
 
         <glossentry id='var-DEFAULT_PREFERENCE'><glossterm>DEFAULT_PREFERENCE</glossterm>
             <glossdef>
-                <para>Specifies the priority of recipes.</para>
+                <para>
+                    Specifies a weak bias for recipe selection priority.
+                </para>
+                <para>
+                    The most common usage of this is variable is to set
+                    it to "-1" within a recipe for a development version of a
+                    piece of software.
+                    Using the variable in this way causes the stable version
+                    of the recipe to build by default in the absence of
+                    <filename><link linkend='var-PREFERRED_VERSION'>PREFERRED_VERSION</link></filename>
+                    being used to build the development version.
+                </para>
+                <note>
+                    The bias provided by <filename>DEFAULT_PREFERENCE</filename>
+                    is weak and is overridden by
+                    <filename><link linkend='var-BBFILE_PRIORITY'>BBFILE_PRIORITY</link></filename>
+                    if the that variable is different between two layers
+                    that contain different versions of the same recipe.
+                </note>
             </glossdef>
         </glossentry>
 
@@ -869,6 +906,22 @@ Core layer for images cannot be removed
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-DISTROOVERRIDES'><glossterm>DISTROOVERRIDES</glossterm>
+            <glossdef>
+                <para>
+                    This variable lists overrides specific to the current
+                    distribution.
+                    By default, the variable list includes the value of the
+                    <filename><link linkend='var-DISTRO'>DISTRO</link></filename>
+                    variable.
+                    You can extend the variable to apply any variable overrides
+                    you want as part of the distribution and are not
+                    already in <filename>OVERRIDES</filename> through
+                    some other means.
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-DL_DIR'><glossterm>DL_DIR</glossterm>
             <glossdef>
                 <para>
@@ -1103,42 +1156,63 @@ Core layer for images cannot be removed
             <glossdef>
                 <para>
                     Extends the search path the OpenEmbedded build system uses
-                    when looking for files and patches as it processes recipes.
-                    The directories BitBake uses when it processes recipes are
-                    defined by the
-                    <link linkend='var-FILESPATH'><filename>FILESPATH</filename></link> variable.
-                    You can add directories to the search path by defining the
-                    <filename>FILESEXTRAPATHS</filename> variable.
+                    when looking for files and patches as it processes recipes
+                    and append files.
+                    The directories BitBake uses when it processes recipes
+                    are defined by the
+                    <link linkend='var-FILESPATH'><filename>FILESPATH</filename></link>
+                    variable, and can be extended using
+                    <filename>FILESEXTRAPATHS</filename>.
                 </para>
 
                 <para>
-                    To add paths to the front of the search order, prepend
-                    them and use the immediate expansion
-                    (<filename>:=</filename>) operator.
-                    Provide a list of directories and separate
-                    each path using a colon character as follows:
-                    <literallayout class='monospaced'>
-     FILESEXTRAPATHS_prepend := "path_1:path_2:path_3:"
-                    </literallayout>
-                    You can add paths to the end of the search order by simply
-                    adding them as follows:
-                    <literallayout class='monospaced'>
-     FILESEXTRAPATHS := "path_1:path_2:path_3:"
-                    </literallayout>
-                    To maintain the integrity of the
-                    <filename>FILESPATH</filename> variable, you must include
-                    the appropriate beginning or ending (as needed) colon
-                    character.
-                </para>
-
-                <para>
-                    The <filename>FILESEXTRAPATHS</filename> variable is
-                    intended for use in <filename>.bbappend</filename> files
-                    to include any additional files provided in that layer.
-                    You typically accomplish this with the following:
+                    Best practices dictate that you accomplish this by using the
+                    variable from within a <filename>.bbappend</filename> file
+                    and that you prepend paths as follows:
                     <literallayout class='monospaced'>
      FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
                     </literallayout>
+                    In the above example, the build system looks for files in
+                    a directory that has the same name as the corresponding
+                    append file.
+                    <note>
+                        <para>When extending <filename>FILESEXTRAPATHS</filename>,
+                        be sure to use the immediate expansion
+                        (<filename>:=</filename>) operator.
+                        Immediate expansion makes sure that BitBake evaluates
+                        <link linkend='var-THISDIR'><filename>THISDIR</filename></link>
+                        at the time the directive
+                        is encountered rather than at some later time when
+                        expansion might result in a directory that does not
+                        contain the files you need.</para>
+                        <para>Also, include the trailing separating colon
+                        character if you are prepending.
+                        The trailing colon character is necessary because you
+                        are directing BitBake to extend the path by prepending
+                        directories to the search path.</para>
+                    </note>
+                    Here is another common use:
+                    <literallayout class='monospaced'>
+     FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
+                    </literallayout>
+                    In this example, the build system extends the
+                    <filename>FILESPATH</filename> variable to include a
+                    directory named <filename>files</filename> that is in the
+                    same directory as the corresponding append file.
+                </para>
+
+                <para>
+                    Here is a final example that specifically adds three paths:
+                    <literallayout class='monospaced'>
+     FILESEXTRAPATHS_prepend := "path_1:path_2:path_3:"
+                    </literallayout>
+                </para>
+
+                <para>
+                    By prepending paths in <filename>.bbappend</filename>
+                    files, you allow multiple append files that reside in
+                    different layers but are used for the same recipe to
+                    correctly extend the path.
                 </para>
             </glossdef>
         </glossentry>
@@ -1146,26 +1220,37 @@ Core layer for images cannot be removed
         <glossentry id='var-FILESPATH'><glossterm>FILESPATH</glossterm>
             <glossdef>
                 <para>
-                    The default set of directories the OpenEmbedded build system uses
-                    when searching for patches and files.
+                    The default set of directories the OpenEmbedded build system
+                    uses when searching for patches and files.
                     During the build process, BitBake searches each directory in
-                    <filename>FILESPATH</filename> in the specified order when looking for
-                    files and patches specified by each <filename>file://</filename> URI in a recipe.
+                    <filename>FILESPATH</filename> in the specified order when
+                    looking for files and patches specified by each
+                    <filename>file://</filename> URI in a recipe.
                 </para>
 
                 <para>
-                    The default value for the <filename>FILESPATH</filename> variable is defined
-                    in the <filename>base.bbclass</filename> class found in
-                    <filename>meta/classes</filename> in the
+                    The default value for the <filename>FILESPATH</filename>
+                    variable is defined in the <filename>base.bbclass</filename>
+                    class found in <filename>meta/classes</filename> in the
                     <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>:
                     <literallayout class='monospaced'>
      FILESPATH = "${@base_set_filespath(["${FILE_DIRNAME}/${BP}", \
         "${FILE_DIRNAME}/${BPN}", "${FILE_DIRNAME}/files"], d)}"
                     </literallayout>
-                    Do not hand-edit the <filename>FILESPATH</filename> variable.
-                    If you want to extend the set of pathnames that BitBake uses when searching for
-                    files and patches, use the
-                    <link linkend='var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></link> variable.
+                    <note>
+                        Do not hand-edit the <filename>FILESPATH</filename>
+                        variable.
+                    </note>
+                    Be aware that the default <filename>FILESPATH</filename>
+                    directories do not map to directories in custom layers
+                    where append files (<filename>.bbappend</filename>)
+                    are used.
+                    If you want the build system to find patches or files
+                    that reside with your append files, you need to extend
+                    the <filename>FILESPATH</filename> variable by using
+                    the
+                    <link linkend='var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></link>
+                    variable.
                 </para>
             </glossdef>
         </glossentry>
@@ -1229,6 +1314,34 @@ Core layer for images cannot be removed
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-HOST_SYS'><glossterm>HOST_SYS</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the system, including the architecture and the
+                    operating system, for with the build is occurring
+                    in the context of the current
+                    recipe.
+                    The OpenEmbedded build system automatically sets this
+                    variable.
+                    You do not need to set the variable yourself.
+                </para>
+
+                <para>
+                    Here are two examples:
+                    <itemizedlist>
+                        <listitem><para>Given a native recipe on a 32-bit
+                            x86 machine running Linux, the value is
+                            "i686-linux".
+                            </para></listitem>
+                        <listitem><para>Given a recipe being built for a
+                            little-endian MIPS target running Linux,
+                            the value might be "mipsel-linux".
+                            </para></listitem>
+                    </itemizedlist>
+                </para>
+            </glossdef>
+        </glossentry>
+
     </glossdiv>
 
     <glossdiv id='var-glossary-i'><title>I</title>
@@ -1312,6 +1425,35 @@ Core layer for images cannot be removed
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-IMAGE_LINGUAS'><glossterm>IMAGE_LINGUAS</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the list of locales to install into the image
+                    during the root filesystem construction process.
+                    The OpenEmbedded build system automatically splits locale
+                    files, which are used for localization, into separate
+                    packages.
+                    Setting the <filename>IMAGE_LINGUAS</filename> variable
+                    ensures that any locale packages that correspond to packages
+                    already selected for installation into the image are also
+                    installed.
+                    Here is an example:
+                    <literallayout class='monospaced'>
+     IMAGE_LINGUAS = "pt-br de-de"
+                    </literallayout>
+                    In this example, the build system ensures any Brazilian
+                    Portuguese and German locale files that correspond to
+                    packages in the image are installed (i.e.
+                    <filename>*-locale-pt-br</filename>
+                    and <filename>*-locale-de-de</filename> as well as
+                    <filename>*-locale-pt</filename>
+                    and <filename>*-locale-de</filename>, since some software
+                    packages only provide locale files by language and not by
+                    country-specific language).
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-IMAGE_OVERHEAD_FACTOR'><glossterm>IMAGE_OVERHEAD_FACTOR</glossterm>
             <glossdef>
                 <para>
@@ -1476,7 +1618,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
         <glossentry id='var-INHIBIT_PACKAGE_STRIP'><glossterm>INHIBIT_PACKAGE_STRIP</glossterm>
             <glossdef>
                 <para>
-                    Causes the build to not strip binaries in resulting packages.
+                    If set to "1", causes the build to not strip binaries in resulting packages.
                 </para>
             </glossdef>
         </glossentry>
@@ -1538,6 +1680,28 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-INSANE_SKIP'><glossterm>INSANE_SKIP</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the QA checks to skip for a specific package
+                    within a recipe.
+                    For example, to skip the check for symbolic link
+                    <filename>.so</filename> files in the main package of a
+                    recipe, add the following to the recipe.
+                    The package name override must be used, which in this
+                    example is <filename>${PN}</filename>:
+                    <literallayout class='monospaced'>
+     INSANE_SKIP_${PN} += "dev-so"
+                    </literallayout>
+                </para>
+                <para>
+                    See the "<link linkend='ref-classes-insane'>Generated Output Quality Assurance Checks - <filename>insane.bbclass</filename></link>"
+                    section for a list of the valid QA checks you can
+                    specify using this variable.
+                </para>
+            </glossdef>
+        </glossentry>
+
 
     </glossdiv>
 
@@ -1635,6 +1799,16 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-KERNEL_EXTRA_ARGS'><glossterm>KERNEL_EXTRA_ARGS</glossterm>
+            <glossdef>
+                <para>
+                    Specifies additional <filename>make</filename>
+                    command-line arguments the OpenEmbedded build system
+                    passes on when compiling the kernel.
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-KERNEL_FEATURES'><glossterm>KERNEL_FEATURES</glossterm>
             <glossdef>
                 <para>Includes additional metadata from the Yocto Project kernel Git repository.
@@ -2033,6 +2207,21 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-LOG_DIR'><glossterm>LOG_DIR</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the directory to which the OpenEmbedded build
+                    system writes overall log files.
+                    The default directory is <filename>${TMPDIR}/log</filename>.
+                </para>
+                <para>
+                    For the directory containing logs specific to each task,
+                    see the <link linkend='var-T'><filename>T</filename></link>
+                    variable.
+                </para>
+            </glossdef>
+        </glossentry>
+
     </glossdiv>
 
     <glossdiv id='var-glossary-m'><title>M</title>
@@ -2293,6 +2482,35 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-MACHINEOVERRIDES'><glossterm>MACHINEOVERRIDES</glossterm>
+            <glossdef>
+                <para>
+                    Lists overrides specific to the current machine.
+                    By default, this list includes the value
+                    of <filename><link linkend='var-MACHINE'>MACHINE</link></filename>.
+                    You can extend the list to apply variable overrides for
+                    classes of machines.
+                    For example, all QEMU emulated machines (e.g. qemuarm,
+                    qemux86, and so forth) include a common file named
+                    <filename>meta/conf/machine/include/qemu.inc</filename>
+                    that prepends <filename>MACHINEOVERRIDES</filename> with
+                    the following variable override:
+                    <literallayout class='monospaced'>
+    MACHINEOVERRIDES =. "qemuall:"
+                    </literallayout>
+                    Applying an override like <filename>qemuall</filename>
+                    affects all QEMU emulated machines elsewhere.
+                    Here is an example from the
+                    <filename>connman-conf</filename> recipe:
+                    <literallayout class='monospaced'>
+    SRC_URI_append_qemuall = "file://wired.config \
+                              file://wired-setup \
+                             "
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-MAINTAINER'><glossterm>MAINTAINER</glossterm>
             <glossdef>
                 <para>The email address of the distribution maintainer.</para>
@@ -2339,6 +2557,18 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-MODULE_TARBALL_DEPLOY'><glossterm>MODULE_TARBALL_DEPLOY</glossterm>
+            <glossdef>
+                <para>
+                    Controls creation of the <filename>modules-*.tgz</filename>
+                    file.
+                    Set this variable to "0" to disable creation of this
+                    file, which contains all of the kernel modules resulting
+                    from a kernel build.
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-MULTIMACH_TARGET_SYS'><glossterm>MULTIMACH_TARGET_SYS</glossterm>
             <glossdef>
                 <para>
@@ -2352,8 +2582,34 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
 
     </glossdiv>
 
-<!--            <glossdiv id='var-glossary-n'><title>N</title>-->
-<!--            </glossdiv>-->
+    <glossdiv id='var-glossary-n'><title>N</title>
+
+        <glossentry id='var-NATIVELSBSTRING'><glossterm>NATIVELSBSTRING</glossterm>
+            <glossdef>
+                <para>
+                    A string identifying the host distribution.
+                    Strings consist of the host distributor ID
+                    followed by the release, as reported by the
+                    <filename>lsb_release</filename> tool
+                    or as read from <filename>/etc/lsb-release</filename>.
+                    For example, when running a build on Ubuntu 12.10, the value
+                    is "Ubuntu-12.10".
+                    If this information is unable to be determined, the value
+                    resolves to "Unknown".
+                </para>
+                <para>
+                    This variable is used by default to isolate native shared
+                    state packages for different distributions (e.g. to avoid
+                    problems with <filename>glibc</filename> version
+                    incompatibilities).
+                    Additionally, the variable is checked against
+                    <link linkend='var-SANITY_TESTED_DISTROS'><filename>SANITY_TESTED_DISTROS</filename></link>
+                    if that variable is set.
+                </para>
+            </glossdef>
+        </glossentry>
+
+    </glossdiv>
 
     <glossdiv id='var-glossary-o'><title>O</title>
 
@@ -2672,6 +2928,23 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-PROVIDES'><glossterm>PROVIDES</glossterm>
+            <glossdef>
+                <para>
+                    A list of aliases that a recipe also provides.
+                    These aliases are useful for satisfying dependencies of
+                    other recipes during the build (as specified by
+                    <filename><link linkend='var-DEPENDS'>DEPENDS</link></filename>).
+                    <note>
+                        A recipe's own
+                        <filename><link linkend='var-PN'>PN</link></filename>
+                        is implicitly already in its
+                        <filename>PROVIDES</filename> list.
+                    </note>
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-PV'><glossterm>PV</glossterm>
             <glossdef>
                 <para>The version of the recipe.
@@ -2825,6 +3098,42 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-RM_WORK_EXCLUDE'><glossterm>RM_WORK_EXCLUDE</glossterm>
+            <glossdef>
+                <para>
+                    With <filename>rm_work</filename> enabled, this
+                    variable specifies a list of packages whose work directories
+                    should not be removed.
+                    See the "<link linkend='ref-classes-rm-work'>Removing Work Files During the Build - <filename>rm_work.bbclass</filename></link>"
+                    section for more details.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-RPROVIDES'><glossterm>RPROVIDES</glossterm>
+            <glossdef>
+                <para>
+                    A list of package name aliases that a package also provides.
+                    These aliases are useful for satisfying runtime dependencies
+                    of other packages both during the build and on the target
+                    (as specified by
+                    <filename><link linkend='var-RDEPENDS'>RDEPENDS</link></filename>).
+                    <note>
+                        A package's own name is implicitly already in its
+                        <filename>RPROVIDES</filename> list.
+                    </note>
+                </para>
+                <para>
+                   As with all package-controlling variables, you must always
+                   use the variable in conjunction with a package name override.
+                   Here is an example:
+                   <literallayout class='monospaced'>
+     RPROVIDES_${PN} = "widget-abi-2"
+                   </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-RRECOMMENDS'><glossterm>RRECOMMENDS</glossterm>
             <glossdef>
                 <para>
@@ -2864,8 +3173,45 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
 
         <glossentry id='var-RREPLACES'><glossterm>RREPLACES</glossterm>
             <glossdef>
-                <para>The list of packages replaced by the package in which
-                    <filename>RREPLACES</filename> appears.</para>
+                <para>
+                    A list of packages replaced by a package.
+                    The package manager uses this variable to determine which
+                    package should be installed to replace other package(s)
+                    during an upgrade.
+                    In order to also have the other package(s) removed at the
+                    same time, you must add the name of the other
+                    package to the
+                    <filename><link linkend='var-RCONFLICTS'>RCONFLICTS</link></filename> variable.
+                </para>
+                <para>
+                   As with all package-controlling variables, you must use
+                   this variable in conjunction with a package name
+                   override.
+                   Here is an example:
+                   <literallayout class='monospaced'>
+     RREPLACES_${PN} = "other-package-being-replaced"
+                   </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-RSUGGESTS'><glossterm>RSUGGESTS</glossterm>
+            <glossdef>
+                <para>
+                    A list of additional packages that you can suggest for
+                    installation by the package manager at the time a package
+                    is installed.
+                    Not all package managers support this functionality.
+                </para>
+                <para>
+                   As with all package-controlling variables, you must always
+                   use this variable in conjunction with a package name
+                   override.
+                   Here is an example:
+                   <literallayout class='monospaced'>
+     RSUGGESTS_${PN} = "useful-package another-package"
+                   </literallayout>
+                </para>
             </glossdef>
         </glossentry>
 
@@ -2901,6 +3247,27 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-SANITY_TESTED_DISTROS'><glossterm>SANITY_TESTED_DISTROS</glossterm>
+            <glossdef>
+                <para>
+                    A list of the host distribution identifiers that the
+                    build system has been tested against.
+                    Identifiers consist of the host distributor ID
+                    followed by the release,
+                    as reported by the <filename>lsb_release</filename> tool
+                    or as read from <filename>/etc/lsb-release</filename>.
+                    Separate the list items with explicit newline
+                    characters (<filename>\n</filename>).
+                    If <filename>SANITY_TESTED_DISTROS</filename> is not empty
+                    and the current value of
+                    <link linkend='var-NATIVELSBSTRING'><filename>NATIVELSBSTRING</filename></link>
+                    does not appear in the list, then the build system reports
+                    a warning that indicates the current host distribution has
+                    not been tested as a build host.
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-SDKIMAGE_FEATURES'><glossterm>SDKIMAGE_FEATURES</glossterm>
             <glossdef>
                 <para>Equivalent to
@@ -2943,6 +3310,54 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-SIGGEN_EXCLUDERECIPES_ABISAFE'><glossterm>SIGGEN_EXCLUDERECIPES_ABISAFE</glossterm>
+            <glossdef>
+                <para>
+                    A list of recipes that are completely stable and will
+                    never change.
+                    The ABI for the recipes in the list are presented by
+                    output from the tasks run to build the recipe.
+                    Use of this variable is one way to remove dependencies from
+                    one recipe on another that affect task signatures and
+                    thus force rebuilds when the recipe changes.
+                    <caution>
+                        If you add an inappropriate variable to this list,
+                        the software might break at runtime if the
+                        interface of the recipe was changed after the other
+                        had been built.
+                    </caution>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS'><glossterm>SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS</glossterm>
+            <glossdef>
+                <para>
+                    A list of recipe dependencies that should not be used to
+                    determine signatures of tasks from one recipe when they
+                    depend on tasks from another recipe.
+                    For example:
+                    <literallayout class='monospaced'>
+    SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS += "intone->mplayer2"
+                    </literallayout>
+                    In this example, <filename>intone</filename> depends on
+                    <filename>mplayer2</filename>.
+                </para>
+
+                <para>
+                    Use of this variable is one mechanism to remove dependencies
+                    that affect task signatures and thus force rebuilds when a
+                    recipe changes.
+                    <caution>
+                        If you add an inappropriate dependency for a recipe
+                        relationship, the software might break during
+                        runtime if the interface of the second recipe was
+                        changed after the first recipe had been built.
+                    </caution>
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-SITEINFO_ENDIANNESS'><glossterm>SITEINFO_ENDIANNESS</glossterm>
             <glossdef>
                 <para>
@@ -2961,6 +3376,24 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-SOC_FAMILY'><glossterm>SOC_FAMILY</glossterm>
+            <glossdef>
+                <para>
+                    Groups together machines based upon the same family
+                    of SOC (System On Chip).
+                    You typically set this variable in a common
+                    <filename>.inc</filename> file that you include in the
+                    configuration files of all the machines.
+                    <note>
+                        You must include
+                        <filename>conf/machine/include/soc-family.inc</filename>
+                        for this variable to appear in
+                    <link linkend='var-MACHINEOVERRIDES'><filename>MACHINEOVERRIDES</filename></link>.
+                    </note>
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-SPECIAL_PKGSUFFIX'><glossterm>SPECIAL_PKGSUFFIX</glossterm>
             <glossdef>
                 <para>
@@ -2975,56 +3408,60 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
         <glossentry id='var-SRC_URI'><glossterm>SRC_URI</glossterm>
             <glossdef>
                 <para>The list of source files - local or remote.
-                    This variable tells the OpenEmbedded build system which bits to pull
-                    in for the build and how to pull them in.
-                    For example, if the recipe only needs to fetch a tarball from the
-                    Internet, the recipe uses a single <filename>SRC_URI</filename> entry.
-                    On the other hand, if the recipe needs to fetch a tarball, apply
-                    two patches, and include a custom file, the recipe would include four
+                    This variable tells the OpenEmbedded build system which bits
+                    to pull in for the build and how to pull them in.
+                    For example, if the recipe or append file only needs to
+                    fetch a tarball from the Internet, the recipe or
+                    append file uses a single <filename>SRC_URI</filename>
+                    entry.
+                    On the other hand, if the recipe or append file needs to
+                    fetch a tarball, apply two patches, and include a custom
+                    file, the recipe or append file would include four
                     instances of the variable.</para>
                 <para>The following list explains the available URI protocols:
                     <itemizedlist>
-                        <listitem><para><emphasis><filename>file://</filename> -</emphasis> Fetches files, which is usually
-                            a file shipped with the
+                        <listitem><para><emphasis><filename>file://</filename> -</emphasis>
+                            Fetches files, which are usually files shipped with
+                            the
                             <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>,
                             from the local machine.
                             The path is relative to the
                             <link linkend='var-FILESPATH'><filename>FILESPATH</filename></link>
                             variable.
-                            Thus, the build system searches, in order, from the following directories,
-                            which are assumed to be a subdirectories of the directory in which the
-                            recipe file resides:
+                            Thus, the build system searches, in order, from the
+                            following directories, which are assumed to be a
+                            subdirectories of the directory in which the
+                            recipe file (<filename>.bb</filename>) or
+                            append file (<filename>.bbappend</filename>)
+                            resides:
                             <itemizedlist>
-                                <listitem><para><emphasis><filename>${PN}</filename> -</emphasis> The recipe name
-                                    with any special suffix or prefix, if applicable.
-                                    For example, using <filename>bash</filename> to build for the native
-                                    machine, <filename>PN</filename> is <filename>bash-native</filename>.
-                                    Using <filename>bash</filename> to build for the target and for Multilib,
-                                    <link linkend='var-PN'><filename>PN</filename></link>
-                                    would be <filename>bash</filename> and
-                                    <filename>lib64-bash</filename>, respectively.
-                                    </para></listitem>
-                                <listitem><para><emphasis><filename>${PF}</filename> - </emphasis>
-                                    <filename>${PN}-${EXTENDPE}${<link linkend='var-PV'>PV</link>}-${<link linkend='var-PR'>PR</link>}</filename>.
-                                    The recipe name including all version and revision numbers
-                                    (i.e. <filename>eglibc-2.13-r20+svnr15508/</filename> and
-                                    <filename>bash-4.2-r1/</filename>).</para></listitem>
-                                <listitem><para><emphasis><filename>${P}</filename> -</emphasis>
-                                    <filename>${PN}-${PV}</filename>.
-                                    The recipe name and version (i.e. <filename>bash-4.2</filename>).
-                                    </para></listitem>
-                                <listitem><para><emphasis><filename>${BPN}</filename> -</emphasis> The
-                                    base recipe name without any special suffix or version numbers.
+                                <listitem><para><emphasis><filename>${BPN}</filename> -</emphasis>
+                                    The base recipe name without any special
+                                    suffix or version numbers.
                                     </para></listitem>
                                 <listitem><para><emphasis><filename>${BP}</filename> -</emphasis>
                                     <filename>${<link linkend='var-BPN'>BPN</link>}-${PV}</filename>.
-                                    The base recipe name and version but without any special
-                                    package name suffix.</para></listitem>
-                                <listitem><para><emphasis>Files -</emphasis> Files beneath the directory in which the recipe
-                                    resides.</para></listitem>
-                                <listitem><para><emphasis>Directory -</emphasis> The directory itself in which the recipe
-                                    resides.</para></listitem>
-                            </itemizedlist></para></listitem>
+                                    The base recipe name and version but without
+                                    any special package name suffix.
+                                    </para></listitem>
+                                <listitem><para><emphasis>files -</emphasis>
+                                    Files within a directory, which is named
+                                    <filename>files</filename> and is also
+                                    alongside the recipe or append file.
+                                    </para></listitem>
+                            </itemizedlist>
+                            <note>
+                                If you want the build system to pick up files
+                                specified through a
+                                <filename>SRC_URI</filename>
+                                statement from your append file, you need to be
+                                sure to extend the
+                                <filename>FILESPATH</filename>
+                                variable by also using the
+                                <link linkend='var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></link>
+                                variable from within your append file.
+                            </note>
+                            </para></listitem>
                         <listitem><para><emphasis><filename>bzr://</filename> -</emphasis> Fetches files from a
                             Bazaar revision control repository.</para></listitem>
                         <listitem><para><emphasis><filename>git://</filename> -</emphasis> Fetches files from a
@@ -3249,9 +3686,9 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     as set in the <filename>meta/conf/bitbake.conf</filename> file
                     is:
                     <literallayout class='monospaced'>
-     STAMP = "${TMPDIR}/stamps/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}"
+     STAMP = "${STAMPS_DIR}/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}"
                     </literallayout>
-                    See <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link>,
+                    See <link linkend='var-STAMPS_DIR'><filename>STAMPS_DIR</filename></link>,
                     <link linkend='var-MULTIMACH_TARGET_SYS'><filename>MULTIMACH_TARGET_SYS</filename></link>,
                     <link linkend='var-PN'><filename>PN</filename></link>,
                     <link linkend='var-EXTENDPE'><filename>EXTENDPE</filename></link>,
@@ -3262,6 +3699,17 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-STAMPS_DIR'><glossterm>STAMPS_DIR</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the base directory in which the OpenEmbedded
+                    build system places stamps.
+                    The default directory is
+                    <filename>${TMPDIR}/stamps</filename>.
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-SUMMARY'><glossterm>SUMMARY</glossterm>
             <glossdef>
                 <para>The short (72 characters or less) summary of the binary package for packaging
@@ -3275,20 +3723,34 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-SYSROOT_PREPROCESS_FUNCS'><glossterm>SYSROOT_PREPROCESS_FUNCS</glossterm>
+            <glossdef>
+                <para>
+                    A list of functions to execute after files are staged into
+                    the sysroot.
+                    These functions are usually used to apply additional
+                    processing on the staged files, or to stage additional
+                    files.
+                </para>
+            </glossdef>
+        </glossentry>
+
     </glossdiv>
 
     <glossdiv id='var-glossary-t'><title>T</title>
 
         <glossentry id='var-T'><glossterm>T</glossterm>
             <glossdef>
-                <para>This variable points to a directory were BitBake places temporary
-                    files when building a particular package.
-                    It is typically set as follows:
+                <para>This variable points to a directory were BitBake places
+                    temporary files, which consist mostly of task logs and
+                    scripts, when building a particular recipe.
+                    The variable is typically set as follows:
                     <literallayout class='monospaced'>
-     T = ${WORKDIR}/temp
+     T = "${WORKDIR}/temp"
                     </literallayout>
                     The <link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>
-                    is the directory into which BitBake unpacks and builds the package.
+                    is the directory into which BitBake unpacks and builds the
+                    recipe.
                     The default <filename>bitbake.conf</filename> file sets this variable.</para>
                     <para>The <filename>T</filename> variable is not to be confused with
                     the <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link> variable,
@@ -3388,6 +3850,16 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-THISDIR'><glossterm>THISDIR</glossterm>
+            <glossdef>
+                <para>
+                    The directory in which the file BitBake is currently
+                    parsing is located.
+                    Do not manually set this variable.
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-TMPDIR'><glossterm>TMPDIR</glossterm>
             <glossdef>
                 <para>

documentation/ref-manual/resources.xml

@@ -112,9 +112,11 @@
 
     <para>
         The Yocto Project gladly accepts contributions.
-        You can submit changes to the project either by creating and sending pull requests,
+        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, see the
+        For information on how to do both as well as information on how
+        to find out who is the maintainer for areas 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>

documentation/ref-manual/technical-details.xml

@@ -373,9 +373,7 @@
             change that changes the task hash, automatically
             causing the task to be run again.
             This removes the need to bump <link linkend='var-PR'><filename>PR</filename></link>
-            values and changes to metadata automatically ripple across the build.
-            Currently, this behavior is not the default behavior for <filename>OE-Core</filename>
-            but is the default in <filename>poky</filename>.
+            values and changes to Metadata automatically ripple across the build.
         </para>
 
         <para>
@@ -643,7 +641,7 @@
         <title>Stabilizing and Completing x32</title>
 
         <para>
-            As of this Yocto Project release, the x32 psABI kernel and library 
+            As of this Yocto Project release, the x32 psABI kernel and library
             interfaces specifications are not finalized.
         </para>
 
@@ -688,6 +686,114 @@
     </section>
 </section>
 
+<section id="wayland">
+    <title>Wayland</title>
+
+    <para>
+        <ulink url='http://en.wikipedia.org/wiki/Wayland_(display_server_protocol)#Weston'>Wayland</ulink>
+        is a computer display server protocol that when implemented
+        provides a method for compositing window managers to communicate
+        directly with applications and video hardware and expects them to
+        communicate with input hardware using other libraries.
+        Using Wayland with supporting targets can result in better control
+        over graphics frame rendering than an application might otherwise
+        achieve.
+    </para>
+
+    <para>
+        The Yocto Project provides the Wayland protocol libraries and the
+        reference Weston compositor as part of it release.
+        This section describes what you need to do to implement Wayland and
+        use the compositor when building an image for a supporting target.
+    </para>
+
+    <section id="wayland-support">
+        <title>Support</title>
+
+        <para>
+            The Wayland protocol libraries and the reference Weston compositor
+            ship as integrated packages in the <filename>meta</filename> layer
+            of the
+            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+            Specifically, you can find the recipes that build both Wayland
+            and Weston at <filename>meta/recipes-graphics/wayland</filename>.
+        </para>
+
+        <para>
+            You can build both the Wayland and Weston packages for use only
+            with targets that accept the
+            <ulink url='http://dri.freedesktop.org/wiki/'>Mesa 3D and Direct Rendering Infrastructure</ulink>,
+            which is also known as Mesa DRI.
+            This implies that you cannot build and use the packages if your
+            target uses, for example, the
+            <trademark class='registered'>Intel</trademark> Embedded Media and
+            Graphics Driver (<trademark class='registered'>Intel</trademark>
+            EMGD) that overrides Mesa DRI.
+        </para>
+
+        <note>
+            Due to lack of EGL support, Weston 1.0.3 will not run directly on
+            the emulated QEMU hardware.
+            However, this version of Weston will run under X emulation without
+            issues.
+        </note>
+    </section>
+
+    <section id="enabling-wayland-in-an-image">
+        <title>Enabling Wayland in an Image</title>
+
+        <para>
+            This section talks about two different ways to enable Wayland:
+            to run under X11 (the default), or to run under Kernel Mode
+            Setting (<ulink url='https://wiki.archlinux.org/index.php/Kernel_Mode_Setting'>KMS</ulink>).
+        </para>
+
+        <para>
+            I don't clearly understand the steps as they are described in the
+            <ulink url='https://wiki.yoctoproject.org/wiki/Wayland'>Enable Wayland in an Image</ulink>
+            section of the wiki.
+            I need help in understanding this section before I can complete
+            this first draft of the new section.
+            What I don't understand is what you have to do exactly for each
+            method.
+            The description in the wiki implies that you need to append the
+            "wayland" feature to use KMS/DRI as well as X11 (both).
+            I need some clarification and clearer steps for the user.
+        </para>
+    </section>
+
+    <section id="running-weston">
+        <title>Running Weston</title>
+
+        <para>
+            To run Weston inside X11, enabling it as described earlier and
+            building a Sato image is sufficient.
+            If you are running your image under Sato, a Weston Launcher appears
+            in the "Utility" category.
+        </para>
+
+        <para>
+            Alternatively, you can run Weston through the command-line
+            interpretor (CLI), which is better suited for development work.
+            To run Weston under the CLI you need to do the following after
+            your image is built:
+            <orderedlist>
+                <listitem><para>Run these commands to export
+                    <filename>XDG_RUNTIME_DIR</filename>:
+                    <literallayout class='monospaced'>
+     mkdir -p /tmp/$USER-weston
+     chmod 0700 /tmp/$USER-weston
+     export XDG_RUNTIME_DIR=/tmp/$USER=weston
+                    </literallayout></para></listitem>
+                <listitem><para>Launch Weston in the shell:
+                    <literallayout class='monospaced'>
+     weston
+                    </literallayout></para></listitem>
+            </orderedlist>
+        </para>
+    </section>
+</section>
+
 <section id="licenses">
     <title>Licenses</title>
 

documentation/ref-manual/usingpoky.xml

@@ -38,8 +38,8 @@
             The <filename>build_dir</filename> is optional and specifies the directory the
             OpenEmbedded build system uses for the build -
             the <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
-            If you do not specify a Build Directory, it defaults to <filename>build</filename>
-            in your current working directory.
+            If you do not specify a Build Directory, it defaults to a directory
+            named <filename>build</filename> in your current working directory.
             A common practice is to use a different Build Directory for different targets.
             For example, <filename>~/build/x86</filename> for a <filename>qemux86</filename>
             target, and <filename>~/build/arm</filename> for a <filename>qemuarm</filename> target.
@@ -117,11 +117,11 @@
     </para>
 
     <para>
-        For discussions on debugging, see the 
+        For discussions on debugging, see the
         "<ulink url='&YOCTO_DOCS_DEV_URL;#platdev-gdb-remotedebug'>Debugging With the GNU Project Debugger (GDB) Remotely</ulink>"
-        and 
+        and
         "<ulink url='&YOCTO_DOCS_DEV_URL;#adt-eclipse'>Working within Eclipse</ulink>"
-        sections in the Yocto Project Development Manual. 
+        sections in the Yocto Project Development Manual.
     </para>
 
     <section id='usingpoky-debugging-taskfailures'>
@@ -156,7 +156,7 @@
             Some tasks exist, such as <filename>devshell</filename>, that are not part of the
             default build chain.
             If you wish to run a task that is not part of the default build chain, you can use the
-            <filename>-c</filename> option in BitBake. 
+            <filename>-c</filename> option in BitBake.
             Here is an example:
             <literallayout class='monospaced'>
      $ bitbake matchbox-desktop -c devshell
@@ -180,7 +180,7 @@
         </para>
 
         <para>
-            This sequence first builds and then recompiles 
+            This sequence first builds and then recompiles
             <filename>matchbox-desktop</filename>.
             The last command reruns all tasks (basically the packaging tasks) after the compile.
             BitBake recognizes that the <filename>compile</filename> task was rerun and therefore
@@ -240,7 +240,7 @@
             build to fail.
             Following are known, host-specific problems.
             Be sure to always consult the
-            <ulink url='&YOCTO_HOME_URL;/download/yocto/yocto-project-&DISTRO;-release-notes-poky-&POKYVERSION;'>Release Notes</ulink>
+            <ulink url='&YOCTO_RELEASE_NOTES;'>Release Notes</ulink>
             for a look at all release-related issues.
             <itemizedlist>
                 <listitem><para><emphasis><filename>eglibc-initial</filename> fails to build</emphasis>:
@@ -278,9 +278,9 @@
     <section id='usingpoky-debugging-variables'>
         <title>Variables</title>
         <para>
-            You can use the <filename>-e</filename> BitBake option to 
-            display the resulting environment for a configuration 
-            when you do not specify a package or for a specific package when 
+            You can use the <filename>-e</filename> BitBake option to
+            display the resulting environment for a configuration
+            when you do not specify a package or for a specific package when
             you do specify the package.
             If you want to show the environment resulting from parsing a single
             recipe, use the <filename>-b recipename</filename> form.
@@ -395,7 +395,7 @@
                 <listitem><para>If you want to remove the <filename>psplash</filename>
                     boot splashscreen,
                     add <filename>psplash=false</filename> to  the kernel command line.
-                    Doing so prevents <filename>psplash</filename> from loading 
+                    Doing so prevents <filename>psplash</filename> from loading
                     and thus allows you to see the console.
                     It is also possible to switch out of the splashscreen by
                     switching the virtual console (e.g. Fn+Left or Fn+Right on a Zaurus).
@@ -505,7 +505,7 @@
 
         <para>At the top level, there is a <filename>metadata-revs</filename> file
             that lists the revisions of the repositories for the layers enabled
-            when the build was produced. 
+            when the build was produced.
             The rest of the data splits into separate
             <filename>packages</filename>, <filename>images</filename> and
             <filename>sdk</filename> directories, the contents of which are
@@ -560,11 +560,11 @@
                 system (e.g., Git), a file exists that lists source revisions
                 that are specified in the recipe and lists the actual revisions
                 used during the build.
-                Listed and actual revisions might differ when 
+                Listed and actual revisions might differ when
                 <link linkend='var-SRCREV'><filename>SRCREV</filename></link>
-                is set to 
-                <filename>${<link linkend='var-AUTOREV'>AUTOREV</link>}</filename>. 
-                Here is an example assuming 
+                is set to
+                <filename>${<link linkend='var-AUTOREV'>AUTOREV</link>}</filename>.
+                Here is an example assuming
                 <filename>buildhistory/packages/emenlow-poky-linux/linux-yocto/latest_srcrev</filename>):
                 <literallayout class='monospaced'>
      # SRCREV_machine = "b5c37fe6e24eec194bb29d22fdd55d73bcc709bf"
@@ -578,7 +578,7 @@
                 command to collect the stored <filename>SRCREV</filename> values
                 from build history and report them in a format suitable for use in
                 global configuration (e.g., <filename>local.conf</filename>
-                or a distro include file) to override floating 
+                or a distro include file) to override floating
                 <filename>AUTOREV</filename> values to a fixed set of revisions.
                 Here is some example output from this command:
                 <literallayout class='monospaced'>
@@ -592,14 +592,14 @@
      SRCREV_pn-opkg = "649"
                 </literallayout>
                 <note>
-                    Here are some notes on using the 
+                    Here are some notes on using the
                     <filename>buildhistory-collect-srcrevs</filename> command:
                     <itemizedlist>
-                        <listitem><para>By default, only values where the 
+                        <listitem><para>By default, only values where the
                             <filename>SRCREV</filename> was
                             not hardcoded (usually when <filename>AUTOREV</filename>
                             was used) are reported.
-                            Use the <filename>-a</filename> option to see all 
+                            Use the <filename>-a</filename> option to see all
                             <filename>SRCREV</filename> values.
                             </para></listitem>
                         <listitem><para>The output statements might not have any effect
@@ -726,13 +726,13 @@
                         See the following listing example for more information.
                         </para></listitem>
                     <listitem><para>The following information appears under
-                        each of the <filename>host</filename> 
-                        and <filename>target</filename> directories 
-                        for the portions of the SDK that run on the host and 
+                        each of the <filename>host</filename>
+                        and <filename>target</filename> directories
+                        for the portions of the SDK that run on the host and
                         on the target, respectively:
                         <itemizedlist>
                             <listitem><para><filename>depends.dot:</filename>
-                                Dependency graph for the SDK that is 
+                                Dependency graph for the SDK that is
                                 compatible with <filename>graphviz</filename>.
                                 </para></listitem>
                             <listitem><para><filename>installed-package-names.txt:</filename>
@@ -756,17 +756,17 @@
      DISTRO_VERSION = 1.3+snapshot-20130327
      SDK_NAME = poky-eglibc-i686-arm
      SDK_VERSION = 1.3+snapshot
-     SDKMACHINE = 
+     SDKMACHINE =
      SDKIMAGE_FEATURES = dev-pkgs dbg-pkgs
-     BAD_RECOMMENDATIONS = 
+     BAD_RECOMMENDATIONS =
      SDKSIZE = 352712
                 </literallayout>
                 Other than <filename>SDKSIZE</filename>, which is the
                 total size of the files in the SDK in Kbytes, the
                 name-value pairs are variables that might have influenced the
                 content of the SDK.
-                This information is often useful when you are trying to 
-                determine why a change in the package or file listings 
+                This information is often useful when you are trying to
+                determine why a change in the package or file listings
                 has occurred.
             </para>
         </section>

documentation/tools/mega-manual.sed

@@ -1,14 +1,14 @@
 # Processes ref-manual and yocto-project-qs manual (<word>-<word>-<word> style)
-s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.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\/1.5\/[a-z]*-[a-z]*-[a-z]*\/[a-z]*-[a-z]*-[a-z]*.html#/\"link\" href=\"#/g
 
 # Processes all other manuals (<word>-<word> style)
-s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.4\/[a-z]*-[a-z]*\/[a-z]*-[a-z]*.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.5\/[a-z]*-[a-z]*\/[a-z]*-[a-z]*.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\/1.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\/1.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\/1.4\/adt-manual\/adt-manual.html\" target=\"_top\">Yocto Project Application Developer's Guide<\/a>/Yocto Project Application Developer's Guide/g
-s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.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\/1.4\/kernel-manual\/kernel-manual.html\" target=\"_top\">Yocto Project Kernel Architecture and Use Manual<\/a>/Yocto Project Kernel Architecture and Use Manual/g
-s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.4\/kernel-ref\/kernel-ref.html\" target=\"_top\">Yocto Project Kernel Development Manual<\/a>/Yocto Project Kernel Development Manual/g
-s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.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\/1.5\/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\/1.5\/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\/1.5\/adt-manual\/adt-manual.html\" target=\"_top\">Yocto Project Application Developer's Guide<\/a>/Yocto Project Application Developer's Guide/g
+s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.5\/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\/1.5\/kernel-manual\/kernel-manual.html\" target=\"_top\">Yocto Project Kernel Architecture and Use Manual<\/a>/Yocto Project Kernel Architecture and Use Manual/g
+s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.5\/kernel-ref\/kernel-ref.html\" target=\"_top\">Yocto Project Kernel Development Manual<\/a>/Yocto Project Kernel Development Manual/g
+s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.5\/ref-manual\/ref-manual.html\" target=\"_top\">Yocto Project Reference Manual<\/a>/Yocto Project Reference Manual/g

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

@@ -307,11 +307,11 @@
 
         <para>
             You can download the latest Yocto Project release by going to the
-            <ulink url="&YOCTO_HOME_URL;/download">Yocto Project Download page</ulink>.
-            Just go to the page and click the "Yocto Downloads" link found in the "Download"
-            navigation pane to the right to view all available Yocto Project releases.
-            Then, click the "Yocto Release" link for the release you want from the list to
-            begin the download.
+            <ulink url="&YOCTO_HOME_URL;">Yocto Project website</ulink>
+            clicking "Downloads" in the navigation pane to the left to view all 
+            available Yocto Project releases.
+            Be sure to scroll down and look for "Yocto Project" under the 
+            "Type" heading in the list.
             Nightly and developmental builds are also maintained at
             <ulink url="&YOCTO_AB_NIGHTLY_URL;"></ulink>.
             However, for this document a released version of Yocto Project is used.
@@ -408,15 +408,16 @@
                  release tarball from the source repositories using the
                  <filename>wget</filename> command.
                  Alternatively, you can go to the
-                 <ulink url='&YOCTO_HOME_URL;/download'>Yocto Project website's Downloads page</ulink>
-                 to retrieve the tarball.</para></listitem>
+                 <ulink url='&YOCTO_HOME_URL;'>Yocto Project website's</ulink>
+                 "Downloads" page to retrieve the tarball.</para></listitem>
              <listitem><para>The second command extracts the files from the tarball and places
                  them into a directory named <filename>&YOCTO_POKY;</filename> in the current
                  directory.</para></listitem>
              <listitem><para>The third and fourth commands change the working directory to the
                  <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
                  and run the Yocto Project
-                 <ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'>environment setup script</ulink>.
+                 <ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>
+                 environment setup script.
                  Running this script defines OpenEmbedded build environment settings needed to
                  complete the build.
                  The script also creates the
@@ -461,9 +462,9 @@
             By default, the OpenEmbedded build system uses the RPM package manager.
             You can control this configuration by using the
             <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></ulink></filename> variable.
-             For additional package manager selection information, see
+             For additional package manager selection information, see the
              "<ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-package'>Packaging - <filename>package*.bbclass</filename></ulink>"
-             in the Yocto Project Reference Manual.
+             section in the Yocto Project Reference Manual.
         </para>
 
          <para>
@@ -661,6 +662,11 @@
          &lt;<emphasis>arch</emphasis>&gt; is a string representing the target architecture:
                 x86, x86-64, ppc, mips, or arm.
                 </literallayout>
+                <note>
+                    For the <filename>qemu</filename> architecture, 
+                    <filename>ext3</filename> and <filename>tar</filename>
+                    files start with the "lib32" string.
+                </note>
             </para>
         </section>
 

meta-skeleton/recipes-kernel/hello-mod/hello-mod_0.1.bb

@@ -13,3 +13,11 @@ SRC_URI = "file://Makefile \
           "
 
 S = "${WORKDIR}"
+
+# Kernel module packages MUST begin with 'kernel-module-', otherwise
+# multilib image generation can fail.
+#
+# The following line is only necessary if the recipe name does not begin
+# with kernel-module-.
+#
+PKG_${PN} = "kernel-module-${PN}"

meta-yocto-bsp/conf/machine/routerstationpro.conf

@@ -6,11 +6,12 @@ require conf/machine/include/tune-mips32.inc
 
 MACHINE_FEATURES = "screen keyboard pci usbhost ext2 ext3 serial"
 
-KERNEL_ALT_IMAGETYPE = "vmlinux"
-KERNEL_IMAGETYPE = "vmlinux.bin"
+KERNEL_IMAGETYPE = "vmlinux"
+KERNEL_ALT_IMAGETYPE = "vmlinux.bin"
+KERNEL_IMAGE_STRIP_EXTRA_SECTIONS  = ".comment"
 
 PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
-PREFERRED_VERSION_linux-yocto ?= "3.4%"
+PREFERRED_VERSION_linux-yocto ?= "3.8%"
 
 PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xorg"
 XSERVER ?= "xserver-xorg \

meta-yocto-bsp/recipes-graphics/xorg-xserver/xserver-xf86-config/beagleboard/xorg.conf

@@ -30,5 +30,4 @@ EndSection
 
 Section "ServerFlags"
 	Option		"DontZap"  "0"
-        Option		"AutoAddDevices" "False"
 EndSection

meta-yocto-bsp/recipes-kernel/linux/linux-yocto_3.2.bbappend

@@ -1,14 +0,0 @@
-KBRANCH_atom-pc  = "standard/default/common-pc/atom-pc"
-KBRANCH_routerstationpro = "standard/default/routerstationpro"
-KBRANCH_mpc8315e-rdb = "standard/default/fsl-mpc8315e-rdb"
-KBRANCH_beagleboard = "standard/default/beagleboard"
-
-SRCREV_machine_atom-pc ?= "41074a778d251a77e036fd8a99915cd4da6cd8f7"
-SRCREV_machine_routerstationpro ?= "94abc0d75d0a99c40c53402570cd9c569539fee9"
-SRCREV_machine_mpc8315e-rdb ?= "a04e94f4dae9cf6d32d059cf9e0308abe7341a3a"
-SRCREV_machine_beagleboard ?= "40bde7a43ef3cd85729ab02464a7ecdf71e522a6"
-
-COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb"
-COMPATIBLE_MACHINE_routerstationpro = "routerstationpro"
-COMPATIBLE_MACHINE_beagleboard = "beagleboard"
-COMPATIBLE_MACHINE_atom-pc = "atom-pc"

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

@@ -12,3 +12,6 @@ COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb"
 COMPATIBLE_MACHINE_routerstationpro = "routerstationpro"
 COMPATIBLE_MACHINE_beagleboard = "beagleboard"
 COMPATIBLE_MACHINE_atom-pc = "atom-pc"
+
+# routerstationpro has a flash size of 16mb
+KERNEL_IMAGE_MAXSIZE_routerstationpro = "16777216"

meta-yocto/classes/poky-sanity.bbclass

@@ -1,16 +1,24 @@
-python check_bblayers_conf_append() {
-    if current_lconf != lconf_version:
-        if current_lconf == 5:
-            index, meta_yocto_line = find_line('meta-yocto\s*\\\\\\n', lines)
+python poky_update_bblayersconf() {
+    current_version = int(d.getVar('LCONF_VERSION', True) or -1)
+    latest_version = int(d.getVar('LAYER_CONF_VERSION', True) or -1)
+
+    bblayers_fn = bblayers_conf_file(d)
+    lines = sanity_conf_read(bblayers_fn)
+
+    if current_version == 5 and latest_version == 6:
+        if '/meta-yocto-bsp' not in d.getVar('BBLAYERS', True):
+            index, meta_yocto_line = sanity_conf_find_line('meta-yocto\s*\\\\\\n', lines)
             if meta_yocto_line:
                 lines.insert(index + 1, meta_yocto_line.replace('meta-yocto',
                                                                 'meta-yocto-bsp'))
             else:
                 sys.exit()
 
-            index, line = find_line('LCONF_VERSION', lines)
-            current_lconf += 1
-            lines[index] = 'LCONF_VERSION = "%d"\n' % current_lconf
-            with open(bblayers_fn, "w") as f:
-                f.write(''.join(lines))
+        current_version += 1
+        sanity_conf_update(bblayers_fn, lines, 'LCONF_VERSION', current_version)
+        return
+
+    sys.exit()
 }
+
+BBLAYERS_CONF_UPDATE_FUNCS += "poky_update_bblayersconf"

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

@@ -29,6 +29,7 @@ DISTRO_PN_ALIAS_pn-build-appliance-image = "OSPDT"
 DISTRO_PN_ALIAS_pn-calibrateproto = "OSPDT upstream=http://cgit.freedesktop.org/xorg/lib/libXCalibrate/"
 DISTRO_PN_ALIAS_pn-calibrateproto = "OSPDT upstream=http://cgit.freedesktop.org/xorg/proto/calibrateproto"
 DISTRO_PN_ALIAS_pn-cdrtools = "OpenSUSE=cdrtools OSPDT"
+DISTRO_PN_ALIAS_pn-chkconfig-alternatives-native = "Mandriva=chkconfig Debian=chkconfig"
 DISTRO_PN_ALIAS_pn-claws-plugin-gtkhtml2-viewer = "Fedora=claws-mail-plugins OpenSuSE=claws-mail-extra-plugins Debian=claws-mail-extra-plugins"
 DISTRO_PN_ALIAS_pn-claws-plugin-maildir = "Fedora=claws-mail-plugins OpenSuSE=claws-mail-extra-plugins Debian=claws-mail-extra-plugins"
 DISTRO_PN_ALIAS_pn-claws-plugin-mailmbox = "Fedora=claws-mail-plugins OpenSuSE=claws-mail-extra-plugins Debian=claws-mail-extra-plugins"
@@ -135,6 +136,7 @@ DISTRO_PN_ALIAS_pn-gtk-engines = "Fedora=gtk2-engines OpenSuSE=gtk2-engines Ubun
 DISTRO_PN_ALIAS_pn-gtk+ = "Meego=gtk2 Fedora=gtk2 OpenSuSE=gtk2 Ubuntu=gtk+2.0 Mandriva=gtk+2.0 Debian=gtk+2.0"
 DISTRO_PN_ALIAS_pn-gtk-sato-engine = "OpenedHand"
 DISTRO_PN_ALIAS_pn-gtk-theme-torturer = "OSPDT upstream=http://wiki.laptop.org/go/GTK_for_OLPC"
+DISTRO_PN_ALIAS_pn-gtk-update-icon-cache-native = "OSPDT"
 DISTRO_PN_ALIAS_pn-hello-mod = "OE-Core"
 DISTRO_PN_ALIAS_pn-hostap-conf = "OE-Core"
 DISTRO_PN_ALIAS_pn-hwlatdetect = "OSPDT"
@@ -172,6 +174,7 @@ DISTRO_PN_ALIAS_pn-libfribidi = "OpenSuSE=fribidi Ubuntu=fribidi Mandriva=fribid
 DISTRO_PN_ALIAS_pn-libgcc = "Debian=libgcc4 Ubuntu=libgcc1 OpenSuSE=libgcc46"
 DISTRO_PN_ALIAS_pn-libgdbus = "Intel"
 DISTRO_PN_ALIAS_pn-libglade = "Meego=libglade2 Fedora=libglade2 OpenSuSE=libglade2 Ubuntu=libglade2 Mandriva=libglade2.0 Debian=libglade2"
+DISTRO_PN_ALIAS_pn-libgu = "OpenSuSE=glu OSPDT"
 DISTRO_PN_ALIAS_pn-libgsmd = "Fedora=gsm Ubuntu=libgsm Debian=libgsm Opensuse=libgsm"
 DISTRO_PN_ALIAS_pn-libgtkstylus = "Debian=libgtkstylus Ubuntu=libgtkstylus"
 DISTRO_PN_ALIAS_pn-libi18n-collate-perl = "OSPDT"
@@ -254,8 +257,10 @@ DISTRO_PN_ALIAS_pn-modutils-collateral = "OE-Core"
 DISTRO_PN_ALIAS_pn-modutils-initscripts = "OE-Core"
 DISTRO_PN_ALIAS_pn-msynctool = "OpenSuse=msynctool Mandriva=msynctool"
 DISTRO_PN_ALIAS_pn-n450-audio = "Intel"
+DISTRO_PN_ALIAS_pn-neard = "Intel"
 DISTRO_PN_ALIAS_pn-network-suspend-scripts = "OE-Core"
 DISTRO_PN_ALIAS_pn-nfs-export-root = "OpenedHand"
+DISTRO_PN_ALIAS_pn-nss-myhostname = "Meego=nss-mdns OpenSuSE=nss-mdns Ubuntu=nss-mdns Mandriva=nss_mdns Debian=nss-mdns"
 DISTRO_PN_ALIAS_pn-npth = "OSPDT"
 DISTRO_PN_ALIAS_pn-ocf-linux = "OSPDT"
 DISTRO_PN_ALIAS_pn-ofono = "Debian=ofono Ubuntu=ofono"
@@ -312,6 +317,7 @@ DISTRO_PN_ALIAS_pn-ppp-dialin = "OE-Core"
 DISTRO_PN_ALIAS_pn-printproto = "Debian=x11proto-print-dev Ubuntu=x11proto-print-dev Mandriva=x11-proto-devel"
 DISTRO_PN_ALIAS_pn-pseudo = "Windriver"
 DISTRO_PN_ALIAS_pn-psplash = "OpenedHand"
+DISTRO_PN_ALIAS_pn-ptest-runner = "OE-Core"
 DISTRO_PN_ALIAS_pn-puzzles = "Debian=sgt-puzzles"
 DISTRO_PN_ALIAS_pn-puzzles = "Debian=sgt-puzzles Fedora=puzzles"
 DISTRO_PN_ALIAS_pn-python-dbus = "Ubuntu=python-dbus Debian=python-dbus Mandriva=python-dbus"
@@ -322,6 +328,8 @@ DISTRO_PN_ALIAS_pn-python-pygobject = "Meego=pygobject2 Fedora=pygobject2 Ubuntu
 DISTRO_PN_ALIAS_pn-python-pygtk = "Debian=python-gtk2 Fedora=pygtk2 OpenSuSE=python-gtk"
 DISTRO_PN_ALIAS_pn-python-pyrex = "Mandriva=python-pyrex Ubuntu=python-pyrex"
 DISTRO_PN_ALIAS_pn-python-scons = "Fedora=scons OpenSuSE=scons Ubuntu=scons Mandriva=scons Debian=scons"
+DISTRO_PN_ALIAS_pn-python-setuptools = "Mandriva=python-setup OpenSuSE=python-setup-git"
+DISTRO_PN_ALIAS_pn-python-smartpm = "Debian=smart OSPDT"
 DISTRO_PN_ALIAS_pn-python-ZSI = "OE-Core"
 DISTRO_PN_ALIAS_pn-qemu-helper = "OpenedHand"
 DISTRO_PN_ALIAS_pn-qemu-config = "OpenedHand"
@@ -363,6 +371,8 @@ DISTRO_PN_ALIAS_pn-signgp-native = "OE-Core"
 DISTRO_PN_ALIAS_pn-stat = "Debian=coreutils Fedora=coreutils"
 DISTRO_PN_ALIAS_pn-swabber-native = "OE-Core"
 DISTRO_PN_ALIAS_pn-systemtap-uprobes = "Ubuntu=systemtap Debian=systemtap"
+DISTRO_PN_ALIAS_pn-systemd-compat-units = "Fedora=systemd Ubuntu=systemd"
+DISTRO_PN_ALIAS_pn-systemd-systemdctl-native = "Fedora=systemd Ubuntu=systemd"
 DISTRO_PN_ALIAS_pn-sysvinit-inittab = "OE-Core"
 DISTRO_PN_ALIAS_pn-table = "Intel"
 DISTRO_PN_ALIAS_pn-tar-replacement-native = "OE-Core"

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

@@ -34,6 +34,7 @@ RECIPE_MAINTAINER_pn-alsa-lib = "Cristian Iorga <cristian.iorga@intel.com>"
 RECIPE_MAINTAINER_pn-alsa-state = "Cristian Iorga <cristian.iorga@intel.com>"
 RECIPE_MAINTAINER_pn-alsa-tools = "Kai Kang <kai.kang@windriver.com>"
 RECIPE_MAINTAINER_pn-alsa-utils = "Cristian Iorga <cristian.iorga@intel.com>"
+RECIPE_MAINTAINER_pn-alsa-utils-alsaconf = "Cristian Iorga <cristian.iorga@intel.com>"
 RECIPE_MAINTAINER_pn-anjuta-remote-run = "Saul Wold <sgw@linux.intel.com>"
 RECIPE_MAINTAINER_pn-apmd = "Andrei Dinu <andrei.adrianx.dinu@intel.com>"
 RECIPE_MAINTAINER_pn-apr = "Radu Moisan <radu.moisan@intel.com>"
@@ -559,6 +560,7 @@ RECIPE_MAINTAINER_pn-nativesdk-qt4-tools = "Paul Eggleton <paul.eggleton@linux.i
 RECIPE_MAINTAINER_pn-nativesdk-unfs-server = "Saul Wold <sgw@linux.intel.com>"
 RECIPE_MAINTAINER_pn-nativesdk-util-macros = "Saul Wold <sgw@linux.intel.com>"
 RECIPE_MAINTAINER_pn-ncurses = "Saul Wold <sgw@linux.intel.com>"
+RECIPE_MAINTAINER_pn-neard = "Cristian Iorga <cristian.iorga@intel.com>"
 RECIPE_MAINTAINER_pn-neon = "Cristian Iorga <cristian.iorga@intel.com>"
 RECIPE_MAINTAINER_pn-netbase = "Cristian Iorga <cristian.iorga@intel.com>"
 RECIPE_MAINTAINER_pn-net-tools = "Cristian Iorga <cristian.iorga@intel.com>"
@@ -707,6 +709,7 @@ RECIPE_MAINTAINER_pn-run-postinsts = "Cristian Iorga <cristian.iorga@intel.com>"
 RECIPE_MAINTAINER_pn-rxvt-unicode = "Radu Moisan <radu.moisan@intel.com>"
 RECIPE_MAINTAINER_pn-sato-icon-theme = "Constantin Musca <constantinx.musca@intel.com>"
 RECIPE_MAINTAINER_pn-sato-screenshot = "Saul Wold <sgw@linux.intel.com>"
+RECIPE_MAINTAINER_pn-sbc = "Cristian Iorga <cristian.iorga@intel.com>"
 RECIPE_MAINTAINER_pn-screenshot = "Constantin Musca <constantinx.musca@intel.com>"
 RECIPE_MAINTAINER_pn-screen = "Constantin Musca <constantinx.musca@intel.com>"
 RECIPE_MAINTAINER_pn-scrnsaverproto = "Laurentiu Palcu <laurentiu.palcu@intel.com>"

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

@@ -159,7 +159,7 @@ CHECK_DATE_pn-makedevs = "Aug 31, 2012"
 RECIPE_UPSTREAM_VERSION_pn-meta-ide-support = "check"
 RECIPE_UPSTREAM_VERSION_pn-minicom = "2.6.2"
 RECIPE_UPSTREAM_DATE_pn-minicom = "Feb 06, 2013"
-CHECK_DATE_pn-minicom = "Feb 20, 2013"
+CHECK_DATE_pn-minicom = "Apr 30, 2013"
 RECIPE_UPSTREAM_DATE_pn-module-init-tools = "Jun 02, 2011"
 RECIPE_UPSTREAM_VERSION_pn-module-init-tools = "3.15"
 CHECK_DATE_pn-module-init-tools = "Aug 31, 2012"
@@ -185,6 +185,7 @@ RECIPE_UPSTREAM_VERSION_pn-pong-clock = "1.0"
 RECIPE_NO_UPDATE_REASON_pn-powertop = "Do not upgrade to version 1.97 since it's a beta release of the comming PowerTOP 2.0"
 RECIPE_UPSTREAM_VERSION_pn-ppp-dialin = "check"
 RECIPE_UPSTREAM_VERSION_pn-prelink="1.0+git1+9552f214c7faa816fdb55b289a457f0cab034f00"
+RECIPE_NO_UPDATE_REASON_pn-python-pygobject = "Newer versions of python-pygobject depend on gobject-introspection which doesn't cross-compile"
 CHECK_DATE_pn-prelink = "Aug 31, 2012"
 RECIPE_UPSTREAM_DATE_pn-qemu-helper-native = "n/a"
 RECIPE_NO_UPDATE_REASON_pn-qemugl = "Do not upgrade to version: 33466cd8 because the upstream is broken in x86_64 build"

meta-yocto/conf/distro/poky-lsb.conf

@@ -6,4 +6,7 @@ DISTROOVERRIDES = "poky:linuxstdbase"
 DISTRO_FEATURES_append = " pam largefile opengl"
 PREFERRED_PROVIDER_virtual/libx11 = "libx11"
 
+# Ensure the kernel nfs server is enabled
+KERNEL_FEATURES_append_pn-linux-yocto = " features/nfsd/nfsd-enable.scc"
+
 

meta-yocto/conf/distro/poky.conf

@@ -1,7 +1,7 @@
 DISTRO = "poky"
-DISTRO_NAME = "Poky 8.0 (Yocto Project 1.3 Reference Distro)"
-DISTRO_VERSION = "1.3+snapshot-${DATE}"
-DISTRO_CODENAME = "dylan"
+DISTRO_NAME = "Poky Next (Yocto Project Reference Distro)"
+DISTRO_VERSION = "1.4+snapshot-${DATE}"
+DISTRO_CODENAME = "next"
 SDK_VENDOR = "-pokysdk"
 SDK_VERSION := "${@'${DISTRO_VERSION}'.replace('snapshot-${DATE}','snapshot')}"
 
@@ -19,6 +19,7 @@ PREFERRED_VERSION_linux-yocto_qemux86 ?= "3.8%"
 PREFERRED_VERSION_linux-yocto_qemux86-64 ?= "3.8%"
 PREFERRED_VERSION_linux-yocto_qemuarm ?= "3.8%"
 PREFERRED_VERSION_linux-yocto_qemumips ?= "3.8%"
+PREFERRED_VERSION_linux-yocto_qemumips64 ?= "3.8%"
 PREFERRED_VERSION_linux-yocto_qemuppc ?= "3.8%"
 
 SDK_NAME = "${DISTRO}-${TCLIBC}-${SDK_ARCH}-${TARGET_ARCH}"
@@ -70,25 +71,19 @@ CONNECTIVITY_CHECK_URIS ?= " \
              http://bugzilla.yoctoproject.org/report.cgi"
 
 SANITY_TESTED_DISTROS ?= " \
-            Yocto-1.2 \n \
-            Poky-1.2 \n \
             Poky-1.3 \n \
-            Ubuntu-10.04 \n \
-            Ubuntu-11.10 \n \
+            Poky-1.4 \n \
             Ubuntu-12.04 \n \
             Ubuntu-12.10 \n \
-            Fedora-16 \n \
+            Ubuntu-13.04 \n \
             Fedora-17 \n \
             Fedora-18 \n \
-            CentOS-5.6 \n \
-            CentOS-5.7 \n \
-            CentOS-5.8 \n \
             CentOS-6.3 \n \
+            CentOS-6.4 \n \
             Debian-6.0 \n \
             Debian-7.0 \n \
-            SUSE-LINUX-11.4 \n \
-            SUSE-LINUX-12.1 \n \
             SUSE-LINUX-12.2 \n \
+            openSUSE-project-12.3 \n \
 	    "
 
 # Default hash policy for distro

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

@@ -211,3 +211,6 @@
 # Put the following two lines in the conf file with intact.
 #ARCHIVER_CLASS = "${@'archive-${ARCHIVER_MODE}-source' if ARCHIVER_MODE != 'none' else ''}"
 #INHERIT += "${ARCHIVER_CLASS}"
+
+# Remove the old image before the new one generated to save disk space
+#RM_OLD_IMAGE = "1"

meta/classes/archive-configured-source.bbclass

@@ -34,7 +34,10 @@ python () {
         d.appendVarFlag('do_compile', 'depends', ' %s:do_archive_configured_sources' %pn)
         build_deps += ' %s:do_archive_configured_sources' %pn
 
-    d.appendVarFlag('do_build', 'depends', build_deps)
+    if bb.data.inherits_class('image', d):
+        d.appendVarFlag('do_rootfs', 'depends', build_deps)
+    else:
+        d.appendVarFlag('do_build', 'depends', build_deps)
 }
 
 ARCHIVE_SSTATE_OUTDIR = "${DEPLOY_DIR}/sources/"

meta/classes/archive-original-source.bbclass

@@ -34,7 +34,10 @@ python () {
         d.appendVarFlag('do_patch', 'depends', ' %s:do_archive_original_sources_patches' %pn)
         build_deps += ' %s:do_archive_original_sources_patches' %pn
 
-    d.appendVarFlag('do_build', 'depends', build_deps)
+    if bb.data.inherits_class('image', d):
+        d.appendVarFlag('do_rootfs', 'depends', build_deps)
+    else:
+        d.appendVarFlag('do_build', 'depends', build_deps)
 }
 
 ARCHIVE_SSTATE_OUTDIR = "${DEPLOY_DIR}/sources/"

meta/classes/archive-patched-source.bbclass

@@ -34,7 +34,10 @@ python () {
         d.appendVarFlag('do_configure', 'depends', ' %s:do_archive_patched_sources' %pn)
         build_deps += ' %s:do_archive_patched_sources' %pn
 
-    d.appendVarFlag('do_build', 'depends', build_deps)
+    if bb.data.inherits_class('image', d):
+        d.appendVarFlag('do_rootfs', 'depends', build_deps)
+    else:
+        d.appendVarFlag('do_build', 'depends', build_deps)
 }
 
 ARCHIVE_SSTATE_OUTDIR = "${DEPLOY_DIR}/sources/"

meta/classes/autotools.bbclass

@@ -127,6 +127,26 @@ EXTRACONFFUNCS ??= ""
 do_configure[prefuncs] += "autotools_preconfigure ${EXTRACONFFUNCS}"
 do_configure[postfuncs] += "autotools_postconfigure"
 
+ACLOCALDIR = "${B}/aclocal-copy"
+
+autotools_copy_aclocal () {
+	# Remove any previous copy of the m4 macros
+	rm -rf ${ACLOCALDIR}/
+
+	# The aclocal directory could get modified by other processes
+	# uninstalling data from the sysroot. See Yocto #861 for details.
+	# We avoid this by taking a copy here and then files cannot disappear.
+	# We copy native first, then target. This avoids certain races since cp-noerror
+	# won't overwrite existing files.
+	mkdir -p ${ACLOCALDIR}/
+	if [ -d ${STAGING_DATADIR_NATIVE}/aclocal ]; then
+		cp-noerror ${STAGING_DATADIR_NATIVE}/aclocal/ ${ACLOCALDIR}/
+	fi
+	if [ -d ${STAGING_DATADIR}/aclocal -a "${STAGING_DATADIR_NATIVE}/aclocal" != "${STAGING_DATADIR}/aclocal" ]; then
+		cp-noerror ${STAGING_DATADIR}/aclocal/ ${ACLOCALDIR}/
+	fi
+}
+
 autotools_do_configure() {
 	# WARNING: gross hack follows:
 	# An autotools built package generally needs these scripts, however only
@@ -142,9 +162,8 @@ autotools_do_configure() {
 	if [ -e ${S}/configure.in -o -e ${S}/configure.ac ]; then
 		olddir=`pwd`
 		cd ${S}
-		# Remove any previous copy of the m4 macros
-		rm -rf ${B}/aclocal-copy/
-		ACLOCAL="aclocal --system-acdir=${B}/aclocal-copy/"
+		autotools_copy_aclocal
+		ACLOCAL="aclocal --system-acdir=${ACLOCALDIR}/"
 		if [ x"${acpaths}" = xdefault ]; then
 			acpaths=
 			for i in `find ${S} -maxdepth 2 -name \*.m4|grep -v 'aclocal.m4'| \
@@ -160,18 +179,6 @@ autotools_do_configure() {
 		if [ -d ${STAGING_DATADIR_NATIVE}/aclocal-$AUTOV ]; then
 			ACLOCAL="$ACLOCAL --automake-acdir=${STAGING_DATADIR_NATIVE}/aclocal-$AUTOV"
 		fi
-		# The aclocal directory could get modified by other processes 
-		# uninstalling data from the sysroot. See Yocto #861 for details.
-		# We avoid this by taking a copy here and then files cannot disappear.
-		# We copy native first, then target. This avoids certain races since cp-noerror
-		# won't overwrite existing files.
-		mkdir -p ${B}/aclocal-copy/
-		if [ -d ${STAGING_DATADIR_NATIVE}/aclocal ]; then
-			cp-noerror ${STAGING_DATADIR_NATIVE}/aclocal/ ${B}/aclocal-copy/
-		fi
-		if [ -d ${STAGING_DATADIR}/aclocal -a "${STAGING_DATADIR_NATIVE}/aclocal" != "${STAGING_DATADIR}/aclocal" ]; then
-			cp-noerror ${STAGING_DATADIR}/aclocal/ ${B}/aclocal-copy/
-		fi
 		# autoreconf is too shy to overwrite aclocal.m4 if it doesn't look
 		# like it was auto-generated.  Work around this by blowing it away
 		# by hand, unless the package specifically asked not to run aclocal.