documentation: Updated the date in Manual Revision History table

Updated the manuals for a December 2014 1.5.4 release date.

(From yocto-docs rev: 34d5133e8b97a8debb2458733a2b15ad3f0988d0)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

README.hardware

@@ -75,14 +75,32 @@ Intel x86 based PCs and devices (genericx86)
 
 The genericx86 MACHINE is tested on the following platforms:
 
-  o Asus EeePC 901
-  o Acer Aspire One
-  o Toshiba NB305
-  o Intel Embedded Development Board 1-N450 (Black Sand)
+Intel Xeon/Core i-Series:
+  + Intel Romley Server: Sandy Bridge Xeon processor, C600 PCH (Patsburg), (Canoe Pass CRB)
+  + Intel Romley Server: Ivy Bridge Xeon processor, C600 PCH (Patsburg), (Intel SDP S2R3)
+  + Intel Crystal Forest Server: Sandy Bridge Xeon processor, DH89xx PCH (Cave Creek), (Stargo CRB)
+  + Intel Chief River Mobile: Ivy Bridge Mobile processor, QM77 PCH (Panther Point-M), (Emerald Lake II CRB, Sabino Canyon CRB)
+  + Intel Huron River Mobile: Sandy Bridge processor, QM67 PCH (Cougar Point), (Emerald Lake CRB, EVOC EC7-1817LNAR board)
+  + Intel Calpella Platform: Core i7 processor, QM57 PCH (Ibex Peak-M), (Red Fort CRB, Emerson MATXM CORE-411-B)
+  + Intel Nehalem/Westmere-EP Server: Xeon 56xx/55xx processors, 5520 chipset, ICH10R IOH (82801), (Hanlan Creek CRB)
+  + Intel Nehalem Workstation: Xeon 56xx/55xx processors, System SC5650SCWS (Greencity CRB)
+  + Intel Picket Post Server: Xeon 56xx/55xx processors (Jasper Forest), 3420 chipset (Ibex Peak), (Osage CRB)
+  + Intel Storage Platform: Sandy Bridge Xeon processor, C600 PCH (Patsburg), (Oak Creek Canyon CRB)
+  + Intel Shark Bay Client Platform: Haswell processor, LynxPoint PCH, (Walnut Canyon CRB, Lava Canyon CRB, Basking Ridge CRB, Flathead Creek CRB)
+  + Intel Shark Bay Ultrabook Platform: Haswell ULT processor, Lynx Point-LP PCH, (WhiteTip Mountain 1 CRB)
 
-and is likely to work on many unlisted Atom based devices. The MACHINE type
-supports ethernet, wifi, sound, and i915 graphics by default in addition to
-common PC input devices, busses, and so on.
+Intel Atom platforms:
+  + Intel embedded Menlow: Intel Atom Z510/530 CPU, System Controller Hub US15W (Portwell NANO-8044)
+  + Intel Luna Pier: Intel Atom N4xx/D5xx series CPU (aka: Pineview-D & -M), 82801HM I/O Hub (ICH8M), (Advantech AIMB-212, Moon Creek CRB)
+  + Intel Queens Bay platform: Intel Atom E6xx CPU (aka: Tunnel Creek), Topcliff EG20T I/O Hub (Emerson NITX-315, Crown Bay CRB, Minnow Board)
+  + Intel Fish River Island platform: Intel Atom E6xx CPU (aka: Tunnel Creek), Topcliff EG20T I/O Hub (Kontron KM2M806)
+  + Intel Cedar Trail platform: Intel Atom N2000 & D2000 series CPU (aka: Cedarview), NM10 Express Chipset (Norco kit BIS-6630, Cedar Rock CRB)
+
+and is likely to work on many unlisted Atom/Core/Xeon based devices. The MACHINE
+type supports ethernet, wifi, sound, and Intel/vesa graphics by default in
+addition to common PC input devices, busses, and so on.  Note that it does not
+included the binary-only graphic drivers used on some Atom platforms, for
+accelerated graphics on these machines please refer to meta-intel.
 
 Depending on the device, it can boot from a traditional hard-disk, a USB device,
 or over the network. Writing generated images to physical media is

bitbake/bin/bitbake

@@ -41,7 +41,7 @@ from bb import ui
 from bb import server
 from bb import cookerdata
 
-__version__ = "1.19.1"
+__version__ = "1.20.0"
 logger = logging.getLogger("BitBake")
 
 # Python multiprocessing requires /dev/shm
@@ -75,18 +75,6 @@ def get_ui(config):
         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")
@@ -112,59 +100,58 @@ 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 ...]
+            usage = """%prog [options] [recipename/target ...]
 
-    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.""")
+    Executes the specified task (default is 'build') for a given set of target recipes (.bb files).
+    It is assumed there is a conf/bblayers.conf available in cwd or in BBPATH which
+    will provide the layer, BBFILES and other configuration information.""")
 
-        parser.add_option("-b", "--buildfile", help = "execute the task against this .bb file, rather than a package from BBFILES. Does not handle any dependencies.",
+        parser.add_option("-b", "--buildfile", help = "Execute tasks from a specific .bb recipe directly. WARNING: Does not handle any dependencies from other recipes.",
                    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.",
+        parser.add_option("-k", "--continue", help = "Continue as much as possible after an error. While the target that failed and anything depending on it cannot be built, as much as possible will be built before stopping.",
                    action = "store_false", dest = "abort", default = True)
 
-        parser.add_option("-a", "--tryaltconfigs", help = "continue with builds by trying to use alternative providers where possible.",
+        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",
+        parser.add_option("-f", "--force", help = "Force the specified targets/task to run (invalidating any existing stamp file).",
                    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",
+        parser.add_option("-c", "--cmd", help = "Specify the task to execute. The exact options available depend on the metadata. Some examples might be 'compile' or 'populate_sysroot' or 'listtasks' may give a list of the tasks available.",
                    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)",
+        parser.add_option("-C", "--clear-stamp", help = "Invalidate the stamp for the specified task such as 'compile' and then 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",
+        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",
+        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",
+        parser.add_option("-v", "--verbose", help = "Output more log message data 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",
+        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",
+        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)",
+        parser.add_option("-p", "--parse-only", help = "Quit after parsing the BB recipes.",
                    action = "store_true", dest = "parse_only", default = False)
 
-        parser.add_option("-s", "--show-versions", help = "show current and preferred versions of all recipes",
+        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)",
+        parser.add_option("-e", "--environment", help = "Show the global or per-package environment complete with information about where variables were set/changed.",
                    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",
+        parser.add_option("-g", "--graphviz", help = "Save dependency tree information for the specified targets in the dot syntax.",
                     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""",
@@ -173,34 +160,34 @@ class BitBakeConfigParameters(cookerdata.ConfigParameters):
         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",
+        parser.add_option("-P", "--profile", help = "Profile the command and save reports.",
                    action = "store_true", dest = "profile", default = False)
 
-        parser.add_option("-u", "--ui", help = "userinterface to use",
+        parser.add_option("-u", "--ui", help = "The user interface to use (e.g. knotty, hob, depexp).",
                    action = "store", dest = "ui")
 
-        parser.add_option("-t", "--servertype", help = "Choose which server to use, process or xmlrpc",
+        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",
+        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",
+        parser.add_option("", "--server-only", help = "Run bitbake without a UI, only starting a server (cooker) process.",
                    action = "store_true", dest = "server_only", default = False)
 
-        parser.add_option("-B", "--bind", help = "The name/address for the bitbake server to bind to",
+        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",
+        parser.add_option("", "--no-setscene", help = "Do not run any setscene tasks. sstate will be ignored and everything needed, built.",
                    action = "store_true", dest = "nosetscene", default = False)
 
-        parser.add_option("", "--remote-server", help = "Connect to the specified server",
+        parser.add_option("", "--remote-server", help = "Connect to the specified server.",
                    action = "store", dest = "remote_server", default = False)
 
-        parser.add_option("-m", "--kill-server", help = "Terminate the remote server",
+        parser.add_option("-m", "--kill-server", help = "Terminate the remote server.",
                     action = "store_true", dest = "kill_server", default = False)
 
-        parser.add_option("", "--observe-only", help = "Connect to a server as an observing-only client",
+        parser.add_option("", "--observe-only", help = "Connect to a server as an observing-only client.",
                    action = "store_true", dest = "observe_only", default = False)
 
         options, targets = parser.parse_args(sys.argv)
@@ -275,8 +262,8 @@ def main():
         if not configParams.bind:
             sys.exit("FATAL: The '--server-only' option requires a name/address to bind to with the -B option.\n")
         if configParams.remote_server:
-            sys.exit("FATAL: The '--server-only' option conflicts with the '--remote-server' option. %s\n" % 
-                ("Please check your BBSERVER environment" if "BBSERVER" in os.environ else "" ))
+            sys.exit("FATAL: The '--server-only' option conflicts with %s.\n" % 
+                ("the BBSERVER environment variable" if "BBSERVER" in os.environ else "the '--remote-server' option" ))
 
     if configParams.bind and configParams.servertype != "xmlrpc":
         sys.exit("FATAL: If '-B' or '--bind' is defined, we must set the servertype as 'xmlrpc'.\n")
@@ -302,30 +289,28 @@ def main():
     # Clear away any spurious environment variables while we stoke up the cooker
     cleanedvars = bb.utils.clean_environment()
 
-    # Collect all the caches we need
-    if configParams.server_only:
-        configuration.extra_caches = gather_extra_cache_data()
-    else:
-        configuration.extra_caches = getattr(ui_module, "extraCaches", [])
-
     if not configParams.remote_server:
         # we start a server with a given configuration
         server = start_server(servermodule, configParams, configuration)
+        bb.event.ui_queue = []
     else:
-        # we start a stub server that is actually a XMLRPClient to
+        # we start a stub server that is actually a XMLRPClient that connects to a real server
         server = servermodule.BitBakeXMLRPCClient(configParams.observe_only)
         server.saveConnectionDetails(configParams.remote_server)
 
-    logger.removeHandler(handler)
-
     if not configParams.server_only:
+        # Collect the feature set for the UI
+        featureset = getattr(ui_module, "featureSet", [])
+
         # Setup a connection to the server (cooker)
-        server_connection = server.establishConnection()
+        server_connection = server.establishConnection(featureset)
 
         # Restore the environment in case the UI needs it
         for k in cleanedvars:
             os.environ[k] = cleanedvars[k]
 
+        logger.removeHandler(handler)
+
         try:
             return ui_module.main(server_connection.connection, server_connection.events, configParams)
         finally:
@@ -339,6 +324,8 @@ def main():
 if __name__ == "__main__":
     try:
         ret = main()
+    except bb.BBHandledException:
+        ret = 1
     except Exception:
         ret = 1
         import traceback

bitbake/bin/bitbake-diffsigs

@@ -3,7 +3,7 @@
 # bitbake-diffsigs
 # BitBake task signature data comparison utility
 #
-# Copyright (C) 2012 Intel Corporation
+# Copyright (C) 2012-2013 Intel Corporation
 #
 # This program is free software; you can redistribute it and/or modify
 # it under the terms of the GNU General Public License version 2 as
@@ -30,7 +30,18 @@ sys.path.insert(0, os.path.join(os.path.dirname(os.path.dirname(sys.argv[0])), '
 import bb.tinfoil
 import bb.siggen
 
-logger = logging.getLogger('BitBake')
+def logger_create(name, output=sys.stderr):
+    logger = logging.getLogger(name)
+    console = logging.StreamHandler(output)
+    format = bb.msg.BBLogFormatter("%(levelname)s: %(message)s")
+    if output.isatty():
+        format.enable_color()
+    console.setFormatter(format)
+    logger.addHandler(console)
+    logger.setLevel(logging.INFO)
+    return logger
+
+logger = logger_create('bitbake-diffsigs')
 
 def find_compare_task(bbhandler, pn, taskname):
     """ Find the most recent signature files for the specified PN/task and compare them """
@@ -39,6 +50,9 @@ def find_compare_task(bbhandler, pn, taskname):
         logger.error('Metadata does not support finding signature data files')
         sys.exit(1)
 
+    if not taskname.startswith('do_'):
+        taskname = 'do_%s' % taskname
+
     filedates = bb.siggen.find_siginfo(pn, taskname, None, bbhandler.config_data)
     latestfiles = sorted(filedates.keys(), key=lambda f: filedates[f])[-2:]
     if not latestfiles:
@@ -71,6 +85,7 @@ def find_compare_task(bbhandler, pn, taskname):
 
 
 parser = optparse.OptionParser(
+    description = "Compares siginfo/sigdata files written out by BitBake",
     usage = """
   %prog -t recipename taskname
   %prog sigdatafile1 sigdatafile2
@@ -78,25 +93,30 @@ parser = optparse.OptionParser(
 
 parser.add_option("-t", "--task",
         help = "find the signature data files for last two runs of the specified task and compare them",
-        action="store_true", dest="taskmode")
+        action="store", dest="taskargs", nargs=2, metavar='recipename taskname')
 
 options, args = parser.parse_args(sys.argv)
 
-if len(args) == 1:
-    parser.print_help()
+if options.taskargs:
+    tinfoil = bb.tinfoil.Tinfoil()
+    tinfoil.prepare(config_only = True)
+    find_compare_task(tinfoil, options.taskargs[0], options.taskargs[1])
 else:
-    if options.taskmode:
-        tinfoil = bb.tinfoil.Tinfoil()
-        if len(args) < 3:
-            logger.error("Please specify a recipe and task name")
-            sys.exit(1)
-        tinfoil.prepare(config_only = True)
-        find_compare_task(tinfoil, args[1], args[2])
+    if len(args) == 1:
+        parser.print_help()
     else:
-        if len(args) == 2:
-            output = bb.siggen.dump_sigfile(sys.argv[1])
-        else:
-            output = bb.siggen.compare_sigfiles(sys.argv[1], sys.argv[2])
+        import cPickle
+        try:
+            if len(args) == 2:
+                output = bb.siggen.dump_sigfile(sys.argv[1])
+            else:
+                output = bb.siggen.compare_sigfiles(sys.argv[1], sys.argv[2])
+        except IOError as e:
+            logger.error(str(e))
+            sys.exit(1)
+        except cPickle.UnpicklingError, EOFError:
+            logger.error('Invalid signature data - ensure you are specifying sigdata/siginfo files')
+            sys.exit(1)
 
-        if output:
-            print '\n'.join(output)
+    if output:
+        print '\n'.join(output)

bitbake/bin/bitbake-dumpsig

@@ -1,11 +1,65 @@
 #!/usr/bin/env python
+
+# bitbake-dumpsig
+# BitBake task signature dump utility
+#
+# Copyright (C) 2013 Intel Corporation
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License version 2 as
+# published by the Free Software Foundation.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License along
+# with this program; if not, write to the Free Software Foundation, Inc.,
+# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+
 import os
 import sys
 import warnings
+import optparse
+import logging
+
 sys.path.insert(0, os.path.join(os.path.dirname(os.path.dirname(sys.argv[0])), 'lib'))
 
 import bb.siggen
 
-output = bb.siggen.dump_sigfile(sys.argv[1])
-if output:
-    print '\n'.join(output)
+def logger_create(name, output=sys.stderr):
+    logger = logging.getLogger(name)
+    console = logging.StreamHandler(output)
+    format = bb.msg.BBLogFormatter("%(levelname)s: %(message)s")
+    if output.isatty():
+        format.enable_color()
+    console.setFormatter(format)
+    logger.addHandler(console)
+    logger.setLevel(logging.INFO)
+    return logger
+
+logger = logger_create('bitbake-dumpsig')
+
+parser = optparse.OptionParser(
+    description = "Dumps siginfo/sigdata files written out by BitBake",
+    usage = """
+  %prog sigdatafile""")
+
+options, args = parser.parse_args(sys.argv)
+
+if len(args) == 1:
+    parser.print_help()
+else:
+    import cPickle
+    try:
+        output = bb.siggen.dump_sigfile(args[1])
+    except IOError as e:
+        logger.error(str(e))
+        sys.exit(1)
+    except cPickle.UnpicklingError, EOFError:
+        logger.error('Invalid signature data - ensure you are specifying a sigdata/siginfo file')
+        sys.exit(1)
+
+    if output:
+        print '\n'.join(output)

bitbake/bin/bitbake-worker

@@ -97,7 +97,8 @@ def fork_off_task(cfg, data, workerdata, fn, task, taskname, appends, quieterror
         except TypeError:
              umask = taskdep['umask'][taskname]
 
-    if 'fakeroot' in taskdep and taskname in taskdep['fakeroot']:
+    # We can't use the fakeroot environment in a dry run as it possibly hasn't been built
+    if 'fakeroot' in taskdep and taskname in taskdep['fakeroot'] and not cfg.dry_run:
         envvars = (workerdata["fakerootenv"][fn] or "").split()
         for key, value in (var.split('=') for var in envvars):
             envbackup[key] = os.environ.get(key)

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.19.1"
+__version__ = "1.20.0"
 
 import sys
 if sys.version_info < (2, 7, 3):

bitbake/lib/bb/build.py

@@ -72,6 +72,8 @@ class TaskBase(event.Event):
     def __init__(self, t, logfile, d):
         self._task = t
         self._package = d.getVar("PF", True)
+        self.taskfile = d.getVar("FILE", True)
+        self.taskname = self._task
         self.logfile = logfile
         event.Event.__init__(self)
         self._message = "recipe %s: task %s: %s" % (d.getVar("PF", True), t, self.getDisplayName())
@@ -283,7 +285,7 @@ set -e
         if bb.msg.loggerVerboseLogs:
             script.write("set -x\n")
         if cwd:
-            script.write("cd %s\n" % cwd)
+            script.write("cd '%s'\n" % cwd)
         script.write("%s\n" % func)
         script.write('''
 # cleanup
@@ -344,6 +346,14 @@ def _exec_task(fn, task, d, quieterr):
     if not tempdir:
         bb.fatal("T variable not set, unable to build")
 
+    # Change nice level if we're asked to
+    nice = localdata.getVar("BB_TASK_NICE_LEVEL", True)
+    if nice:
+        curnice = os.nice(0)
+        nice = int(nice) - curnice
+        newnice = os.nice(nice)
+        logger.debug(1, "Renice to %s " % newnice)
+
     bb.utils.mkdirhier(tempdir)
 
     # Determine the logfile to generate

bitbake/lib/bb/cache_extra.py

@@ -35,6 +35,12 @@ class HobRecipeInfo(RecipeInfoCommon):
     # such as (bb_cache.dat, bb_extracache_hob.dat) 
     cachefile = "bb_extracache_" + classname +".dat"        
 
+    # override this member with the list of extra cache fields
+    # that this class will provide
+    cachefields = ['summary', 'license', 'section',
+            'description', 'homepage', 'bugtracker',
+            'prevision', 'files_info']
+
     def __init__(self, filename, metadata):
 
         self.summary = self.getvar('SUMMARY', metadata)

bitbake/lib/bb/command.py

@@ -86,6 +86,8 @@ class Command:
 
     def runAsyncCommand(self):
         try:
+            if self.cooker.state == bb.cooker.state.error:
+                return False
             if self.currentAsyncCommand is not None:
                 (command, options) = self.currentAsyncCommand
                 commandmethod = getattr(CommandsAsync, command)
@@ -145,6 +147,15 @@ class CommandsSync:
         """
         command.cooker.shutdown(True)
 
+    def getAllKeysWithFlags(self, command, params):
+        """
+        Returns a dump of the global state. Call with
+        variable flags to be retrieved as params.
+        """
+        flaglist = params[0]
+        return command.cooker.getAllKeysWithFlags(flaglist)
+    getAllKeysWithFlags.readonly = True
+
     def getVariable(self, command, params):
         """
         Read the value of a variable from data
@@ -232,6 +243,13 @@ class CommandsSync:
         op = params[3]
         command.cooker.modifyConfigurationVar(var, val, default_file, op)
 
+    def removeVarFile(self, command, params):
+        """
+        Remove a variable declaration from a file
+        """
+        var = params[0]
+        command.cooker.removeConfigurationVar(var)
+
     def createConfigFile(self, command, params):
         """
         Create an extra configuration file

bitbake/lib/bb/cooker.py

@@ -61,7 +61,7 @@ class CollectionError(bb.BBHandledException):
     """
 
 class state:
-    initial, parsing, running, shutdown, forceshutdown, stopped = range(6)
+    initial, parsing, running, shutdown, forceshutdown, stopped, error = range(7)
 
 
 class SkippedPackage:
@@ -79,6 +79,29 @@ class SkippedPackage:
         elif reason:
             self.skipreason = reason
 
+
+class CookerFeatures(object):
+    _feature_list = [HOB_EXTRA_CACHES, SEND_DEPENDS_TREE] = range(2)
+
+    def __init__(self):
+        self._features=set()
+
+    def setFeature(self, f):
+        # validate we got a request for a feature we support
+        if f not in CookerFeatures._feature_list:
+            return
+        self._features.add(f)
+
+    def __contains__(self, f):
+        return f in self._features
+
+    def __iter__(self):
+        return self._features.__iter__()
+
+    def next(self):
+        return self._features.next()
+
+
 #============================================================================#
 # BBCooker
 #============================================================================#
@@ -90,6 +113,7 @@ class BBCooker:
     def __init__(self, configuration):
         self.recipecache = None
         self.skiplist = {}
+        self.featureset = CookerFeatures()
 
         self.configuration = configuration
 
@@ -122,7 +146,13 @@ class BBCooker:
         self.state = state.initial
 
         self.caches_array = []
-        caches_name_array = ['bb.cache:CoreRecipeInfo'] + self.configuration.extra_caches
+
+        all_extra_cache_names = []
+        # We hardcode all known cache types in a single place, here.
+        if CookerFeatures.HOB_EXTRA_CACHES in self.featureset:
+            all_extra_cache_names.append("bb.cache_extra:HobRecipeInfo")
+
+        caches_name_array = ['bb.cache:CoreRecipeInfo'] + all_extra_cache_names
 
         # At least CoreRecipeInfo will be loaded, so caches_array will never be empty!
         # This is the entry point, no further check needed!
@@ -130,7 +160,7 @@ class BBCooker:
             try:
                 module_name, cache_name = var.split(':')
                 module = __import__(module_name, fromlist=(cache_name,))
-                self.caches_array.append(getattr(module, cache_name)) 
+                self.caches_array.append(getattr(module, cache_name))
             except ImportError as exc:
                 logger.critical("Unable to import extra RecipeInfo '%s' from '%s': %s" % (cache_name, module_name, exc))
                 sys.exit("FATAL: Failed to import extra cache class '%s'." % cache_name)
@@ -163,7 +193,10 @@ class BBCooker:
         if op == "append":
             self.appendConfigurationVar(var, val, default_file)
         elif op == "set":
-            self.saveConfigurationVar(var, val, default_file)
+            self.saveConfigurationVar(var, val, default_file, "=")
+        elif op == "earlyAssign":
+            self.saveConfigurationVar(var, val, default_file, "?=")
+
 
     def appendConfigurationVar(self, var, val, default_file):
         #add append var operation to the end of default_file
@@ -177,7 +210,7 @@ class BBCooker:
         for c in contents:
             total += c
 
-        total += "#added by bitbake"
+        total += "#added by hob"
         total += "\n%s += \"%s\"\n" % (var, val)
 
         with open(default_file, 'w') as f:
@@ -188,7 +221,7 @@ class BBCooker:
         loginfo = {"op":append, "file":default_file, "line":total.count("\n")}
         self.data.appendVar(var, val, **loginfo)
 
-    def saveConfigurationVar(self, var, val, default_file):
+    def saveConfigurationVar(self, var, val, default_file, op):
 
         replaced = False
         #do not save if nothing changed
@@ -230,8 +263,8 @@ class BBCooker:
                     #check if the variable was saved before in the same way
                     #if true it replace the place where the variable was declared
                     #else it comments it
-                    if contents[begin_line-1]== "#added by bitbake\n":
-                        contents[begin_line] = "%s = \"%s\"\n" % (var, val)
+                    if contents[begin_line-1]== "#added by hob\n":
+                        contents[begin_line] = "%s %s \"%s\"\n" % (var, op, val)
                         replaced = True
                     else:
                         for ii in range(begin_line, end_line):
@@ -260,8 +293,8 @@ class BBCooker:
                 total += c
 
             #add the variable on a single line, to be easy to replace the second time
-            total += "\n#added by bitbake"
-            total += "\n%s = \"%s\"\n" % (var, val)
+            total += "\n#added by hob"
+            total += "\n%s %s \"%s\"\n" % (var, op, val)
 
             with open(default_file, 'w') as f:
                 f.write(total)
@@ -271,6 +304,44 @@ class BBCooker:
             loginfo = {"op":set, "file":default_file, "line":total.count("\n")}
             self.data.setVar(var, val, **loginfo)
 
+    def removeConfigurationVar(self, var):
+        conf_files = self.data.varhistory.get_variable_files(var)
+        topdir = self.data.getVar("TOPDIR")
+
+        for conf_file in conf_files:
+            if topdir in conf_file:
+                with open(conf_file, 'r') as f:
+                    contents = f.readlines()
+                f.close()
+
+                lines = self.data.varhistory.get_variable_lines(var, conf_file)
+                for line in lines:
+                    total = ""
+                    i = 0
+                    for c in contents:
+                        total += c
+                        i = i + 1
+                        if i==int(line):
+                            end_index = len(total)
+                    index = total.rfind(var, 0, end_index)
+
+                    begin_line = total.count("\n",0,index)
+
+                    #check if the variable was saved before in the same way
+                    if contents[begin_line-1]== "#added by hob\n":
+                        contents[begin_line-1] = contents[begin_line] = "\n"
+                    else:
+                        contents[begin_line] = "\n"
+                    #remove var from history
+                    self.data.varhistory.del_var_history(var, conf_file, line)
+
+                total = ""
+                for c in contents:
+                    total += c
+                with open(conf_file, 'w') as f:
+                    f.write(total)
+                f.close()
+
     def createConfigFile(self, name):
         path = os.getcwd()
         confpath = os.path.join(path, "conf", name)
@@ -427,7 +498,10 @@ class BBCooker:
         runlist, taskdata = self.prepareTreeData(pkgs_to_build, task)
         rq = bb.runqueue.RunQueue(self, self.data, self.recipecache, taskdata, runlist)
         rq.rqdata.prepare()
+        return self.buildDependTree(rq, taskdata)
 
+
+    def buildDependTree(self, rq, taskdata):
         seen_fnids = []
         depend_tree = {}
         depend_tree["depends"] = {}
@@ -448,6 +522,19 @@ class BBCooker:
                 depend_tree["pn"][pn] = {}
                 depend_tree["pn"][pn]["filename"] = fn
                 depend_tree["pn"][pn]["version"] = version
+
+                # if we have extra caches, list all attributes they bring in
+                extra_info = []
+                for cache_class in self.caches_array:
+                    if type(cache_class) is type and issubclass(cache_class, bb.cache.RecipeInfoCommon) and hasattr(cache_class, 'cachefields'):
+                        cachefields = getattr(cache_class, 'cachefields', [])
+                        extra_info = extra_info + cachefields
+
+                # for all attributes stored, add them to the dependency tree
+                for ei in extra_info:
+                    depend_tree["pn"][pn][ei] = vars(self.recipecache)[ei][fn]
+
+
             for dep in rq.rqdata.runq_depends[task]:
                 depfn = taskdata.fn_index[rq.rqdata.runq_fnid[dep]]
                 deppn = self.recipecache.pkg_fn[depfn]
@@ -510,35 +597,30 @@ class BBCooker:
         depend_tree["rdepends-pkg"] = {}
         depend_tree["rrecs-pkg"] = {}
 
+        # if we have extra caches, list all attributes they bring in
+        extra_info = []
+        for cache_class in self.caches_array:
+            if type(cache_class) is type and issubclass(cache_class, bb.cache.RecipeInfoCommon) and hasattr(cache_class, 'cachefields'):
+                cachefields = getattr(cache_class, 'cachefields', [])
+                extra_info = extra_info + cachefields
+
         for task in xrange(len(tasks_fnid)):
             fnid = tasks_fnid[task]
             fn = taskdata.fn_index[fnid]
             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
+                version  = "%s:%s-%s" % self.recipecache.pkg_pepvpr[fn]
                 depend_tree["pn"][pn]["version"] = version
-                depend_tree["pn"][pn]["summary"] = summary
-                depend_tree["pn"][pn]["license"] = lic
-                depend_tree["pn"][pn]["section"] = section
-                depend_tree["pn"][pn]["description"] = description
-                depend_tree["pn"][pn]["inherits"] = inherits
-                depend_tree["pn"][pn]["homepage"] = homepage
-                depend_tree["pn"][pn]["bugtracker"] = bugtracker
-                depend_tree["pn"][pn]["files_info"] = files_info
-                depend_tree["pn"][pn]["revision"] = prevision
+                rdepends = self.recipecache.rundeps[fn]
+                rrecs = self.recipecache.runrecs[fn]
+                depend_tree["pn"][pn]["inherits"] = self.recipecache.inherits.get(fn, None)
+
+                # for all extra attributes stored, add them to the dependency tree
+                for ei in extra_info:
+                    depend_tree["pn"][pn][ei] = vars(self.recipecache)[ei][fn]
 
             if fnid not in seen_fnids:
                 seen_fnids.append(fnid)
@@ -1113,6 +1195,21 @@ class BBCooker:
 
         self.configuration.server_register_idlecallback(buildTargetsIdle, rq)
 
+
+    def getAllKeysWithFlags(self, flaglist):
+        dump = {}
+        for k in self.data.keys():
+            try:
+                v = self.data.getVar(k, True)
+                if not k.startswith("__") and not isinstance(v, bb.data_smart.DataSmart):
+                    dump[k] = { 'v' : v }
+                    for d in flaglist:
+                        dump[k][d] = self.data.getVarFlag(k, d)
+            except Exception as e:
+                print(e)
+        return dump
+
+
     def generateNewImage(self, image, base_image, package_queue, timestamp, description):
         '''
         Create a new image with a "require"/"inherit" base_image statement
@@ -1224,6 +1321,7 @@ class BBCooker:
             self.prhost = prserv.serv.auto_start(self.data)
         except prserv.serv.PRServiceConfigError:
             bb.event.fire(CookerExit(), self.event_data)
+            self.state = state.error
         return
 
     def post_serve(self):

bitbake/lib/bb/cookerdata.py

@@ -127,7 +127,6 @@ class CookerConfiguration(object):
         self.dump_signatures = False
         self.dry_run = False
         self.tracking = False
-        self.extra_caches = []
 
         self.env = {}
 

bitbake/lib/bb/data.py

@@ -214,7 +214,7 @@ def emit_var(var, o=sys.__stdout__, d = init(), all=False):
         o.write('unset %s\n' % varExpanded)
         return 0
 
-    if not val:
+    if val is None:
         return 0
 
     val = str(val)
@@ -229,7 +229,7 @@ def emit_var(var, o=sys.__stdout__, d = init(), all=False):
 
     # if we're going to output this within doublequotes,
     # to a shell, we need to escape the quotes in the var
-    alter = re.sub('"', '\\"', val.strip())
+    alter = re.sub('"', '\\"', val)
     alter = re.sub('\n', ' \\\n', alter)
     o.write('%s="%s"\n' % (varExpanded, alter))
     return 0

bitbake/lib/bb/data_smart.py

@@ -40,7 +40,7 @@ logger = logging.getLogger("BitBake.Data")
 
 __setvar_keyword__ = ["_append", "_prepend", "_remove"]
 __setvar_regexp__ = re.compile('(?P<base>.*?)(?P<keyword>_append|_prepend|_remove)(_(?P<add>.*))?$')
-__expand_var_regexp__ = re.compile(r"\${[^{}@]+}")
+__expand_var_regexp__ = re.compile(r"\${[^{}@\n\t ]+}")
 __expand_python_regexp__ = re.compile(r"\${@.+?}")
 
 def infer_caller_details(loginfo, parent = False, varval = True):
@@ -281,9 +281,13 @@ class VariableHistory(object):
                 lines.append(line)
         return lines
 
-    def del_var_history(self, var):
+    def del_var_history(self, var, f=None, line=None):
+        """If file f and line are not given, the entire history of var is deleted"""
         if var in self.variables:
-            self.variables[var] = []
+            if f and line:
+                self.variables[var] = [ x for x in self.variables[var] if x['file']!=f and x['line']!=line]
+            else:
+                self.variables[var] = []
 
 class DataSmart(MutableMapping):
     def __init__(self, special = COWDictBase.copy(), seen = COWDictBase.copy() ):

bitbake/lib/bb/event.py

@@ -589,6 +589,16 @@ class PackageInfo(Event):
         Event.__init__(self)
         self._pkginfolist = pkginfolist
 
+class MetadataEvent(Event):
+    """
+    Generic event that target for OE-Core classes
+    to report information during asynchrous execution
+    """
+    def __init__(self, eventtype, eventdata):
+        Event.__init__(self)
+        self.type = eventtype
+        self.data = eventdata
+
 class SanityCheck(Event):
     """
     Event to issue sanity check

bitbake/lib/bb/fetch2/__init__.py

@@ -329,7 +329,7 @@ def decodeurl(url):
     user, password, parameters).
     """
 
-    m = re.compile('(?P<type>[^:]*)://((?P<user>.+)@)?(?P<location>[^;]+)(;(?P<parm>.*))?').match(url)
+    m = re.compile('(?P<type>[^:]*)://((?P<user>[^/]+)@)?(?P<location>[^;]+)(;(?P<parm>.*))?').match(url)
     if not m:
         raise MalformedUrl(url)
 
@@ -805,7 +805,11 @@ def try_mirror_url(newuri, origud, ud, ld, check = False):
             dest = os.path.join(dldir, os.path.basename(ud.localpath))
             if not os.path.exists(dest):
                 os.symlink(ud.localpath, dest)
-            return None
+            if not os.path.exists(origud.donestamp) or origud.method.need_update(origud.url, origud, ld):
+                origud.method.download(origud.url, origud, ld)
+                if hasattr(origud.method,"build_mirror_data"):
+                    origud.method.build_mirror_data(origud.url, origud, ld)
+            return ud.localpath
         # Otherwise the result is a local file:// and we symlink to it
         if not os.path.exists(origud.localpath):
             if os.path.islink(origud.localpath):

bitbake/lib/bb/fetch2/git.py

@@ -305,8 +305,8 @@ class Git(FetchMethod):
             username = ""
 
         basecmd = data.getVar("FETCHCMD_git", d, True) or "git"
-        cmd = "%s ls-remote %s://%s%s%s %s" % \
-              (basecmd, ud.proto, username, ud.host, ud.path, ud.branches[name])
+        cmd = "%s ls-remote %s://%s%s%s refs/heads/%s refs/tags/%s" % \
+              (basecmd, ud.proto, username, ud.host, ud.path, ud.branches[name], ud.branches[name])
         if ud.proto.lower() != 'file':
             bb.fetch2.check_network_access(d, cmd)
         output = runfetchcmd(cmd, d, True)

bitbake/lib/bb/fetch2/hg.py

@@ -92,7 +92,10 @@ class Hg(FetchMethod):
         if not ud.user:
             hgroot = host + ud.path
         else:
-            hgroot = ud.user + "@" + host + ud.path
+            if ud.pswd:
+                hgroot = ud.user + ":" + ud.pswd + "@" + host + ud.path
+            else:
+                hgroot = ud.user + "@" + host + ud.path
 
         if command == "info":
             return "%s identify -i %s://%s/%s" % (basecmd, proto, hgroot, ud.module)
@@ -112,7 +115,10 @@ class Hg(FetchMethod):
             # do not pass options list; limiting pull to rev causes the local
             # repo not to contain it and immediately following "update" command
             # will crash
-            cmd = "%s pull" % (basecmd)
+            if ud.user and ud.pswd:
+                cmd = "%s --config auth.default.prefix=* --config auth.default.username=%s --config auth.default.password=%s --config \"auth.default.schemes=%s\" pull" % (basecmd, ud.user, ud.pswd, proto)
+            else:
+                cmd = "%s pull" % (basecmd)
         elif command == "update":
             cmd = "%s update -C %s" % (basecmd, " ".join(options))
         else:

bitbake/lib/bb/fetch2/perforce.py

@@ -112,7 +112,7 @@ class Perforce(FetchMethod):
         base = path
         which = path.find('/...')
         if which != -1:
-            base = path[:which]
+            base = path[:which-1]
 
         base = self._strip_leading_slashes(base)
 

bitbake/lib/bb/fetch2/svn.py

@@ -27,6 +27,7 @@ import os
 import sys
 import logging
 import bb
+import re
 from   bb import data
 from   bb.fetch2 import FetchMethod
 from   bb.fetch2 import FetchError
@@ -91,6 +92,8 @@ class Svn(FetchMethod):
 
         if command == "info":
             svncmd = "%s info %s %s://%s/%s/" % (ud.basecmd, " ".join(options), proto, svnroot, ud.module)
+        elif command == "log1":
+            svncmd = "%s log --limit 1 %s %s://%s/%s/" % (ud.basecmd, " ".join(options), proto, svnroot, ud.module)
         else:
             suffix = ""
             if ud.revision:
@@ -167,14 +170,13 @@ class Svn(FetchMethod):
         """
         Return the latest upstream revision number
         """
-        bb.fetch2.check_network_access(d, self._buildsvncommand(ud, d, "info"))
+        bb.fetch2.check_network_access(d, self._buildsvncommand(ud, d, "log1"))
 
-        output = runfetchcmd("LANG=C LC_ALL=C " + self._buildsvncommand(ud, d, "info"), d, True)
+        output = runfetchcmd("LANG=C LC_ALL=C " + self._buildsvncommand(ud, d, "log1"), d, True)
 
-        revision = None
-        for line in output.splitlines():
-            if "Last Changed Rev" in line:
-                revision = line.split(":")[1].strip()
+        # skip the first line, as per output of svn log
+        # then we expect the revision on the 2nd line
+        revision = re.search('^r([0-9]*)', output.splitlines()[1]).group(1)
 
         return revision
 

bitbake/lib/bb/monitordisk.py

@@ -225,7 +225,7 @@ class diskMonitor:
                         self.preFreeS[k] = freeSpace
 
                     if action == "STOPTASKS" and not self.checked[k]:
-                        logger.error("No new tasks can be excuted since the disk space monitor action is \"STOPTASKS\"!")
+                        logger.error("No new tasks can be executed since the disk space monitor action is \"STOPTASKS\"!")
                         self.checked[k] = True
                         rq.finish_runqueue(False)
                         bb.event.fire(bb.event.DiskFull(dev, 'disk', freeSpace, path), self.configuration)
@@ -243,7 +243,7 @@ class diskMonitor:
                     # zero, this is a feature of the fs, we disable the inode
                     # 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)
+                        logger.info("Inode check for %s is unavaliable, will remove it from disk monitor" % path)
                         self.devDict[k][2] = None
                         continue
                     # Always show warning, the self.checked would always be False if the action is WARN
@@ -253,7 +253,7 @@ class diskMonitor:
                         self.preFreeI[k] = freeInode
 
                     if action  == "STOPTASKS" and not self.checked[k]:
-                        logger.error("No new tasks can be excuted since the disk space monitor action is \"STOPTASKS\"!")
+                        logger.error("No new tasks can be executed since the disk space monitor action is \"STOPTASKS\"!")
                         self.checked[k] = True
                         rq.finish_runqueue(False)
                         bb.event.fire(bb.event.DiskFull(dev, 'inode', freeInode, path), self.configuration)

bitbake/lib/bb/parse/__init__.py

@@ -73,9 +73,17 @@ def update_mtime(f):
 def mark_dependency(d, f):
     if f.startswith('./'):
         f = "%s/%s" % (os.getcwd(), f[2:])
-    deps = (d.getVar('__depends') or []) + [(f, cached_mtime(f))]
-    d.setVar('__depends', deps)
+    deps = (d.getVar('__depends') or [])
+    s = (f, cached_mtime_noerror(f))
+    if s not in deps:
+        deps.append(s)
+        d.setVar('__depends', deps)
 
+def check_dependency(d, f):
+    s = (f, cached_mtime_noerror(f))
+    deps = (d.getVar('__depends') or [])
+    return s in deps
+   
 def supports(fn, data):
     """Returns true if we have a handler for this file, false otherwise"""
     for h in handlers:
@@ -102,11 +110,14 @@ def init_parser(d):
 def resolve_file(fn, d):
     if not os.path.isabs(fn):
         bbpath = d.getVar("BBPATH", True)
-        newfn = bb.utils.which(bbpath, fn)
+        newfn, attempts = bb.utils.which(bbpath, fn, history=True)
+        for af in attempts:
+            mark_dependency(d, af)
         if not newfn:
             raise IOError("file %s not found in %s" % (fn, bbpath))
         fn = newfn
 
+    mark_dependency(d, fn)
     if not os.path.isfile(fn):
         raise IOError("file %s not found" % fn)
 

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

@@ -77,7 +77,10 @@ def inherit(files, fn, lineno, d):
         if not os.path.isabs(file):
             dname = os.path.dirname(fn)
             bbpath = "%s:%s" % (dname, d.getVar("BBPATH", True))
-            abs_fn = bb.utils.which(bbpath, file)
+            abs_fn, attempts = bb.utils.which(bbpath, file, history=True)
+            for af in attempts:
+                if af != abs_fn:
+                    bb.parse.mark_dependency(d, af)
             if abs_fn:
                 file = abs_fn
 

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

@@ -82,9 +82,15 @@ def include(oldfn, fn, lineno, data, error_out):
     if not os.path.isabs(fn):
         dname = os.path.dirname(oldfn)
         bbpath = "%s:%s" % (dname, data.getVar("BBPATH", True))
-        abs_fn = bb.utils.which(bbpath, fn)
+        abs_fn, attempts = bb.utils.which(bbpath, fn, history=True)
+        if abs_fn and bb.parse.check_dependency(data, abs_fn):
+            bb.warn("Duplicate inclusion for %s in %s" % (abs_fn, data.getVar('FILE', True)))
+        for af in attempts:
+            bb.parse.mark_dependency(data, af)
         if abs_fn:
             fn = abs_fn
+    elif bb.parse.check_dependency(data, fn):
+        bb.warn("Duplicate inclusion for %s in %s" % (fn, data.getVar('FILE', True)))
 
     from bb.parse import handle
     try:
@@ -93,6 +99,7 @@ def include(oldfn, fn, lineno, data, error_out):
         if error_out:
             raise ParseError("Could not %(error_out)s file %(fn)s" % vars(), oldfn, lineno)
         logger.debug(2, "CONF file '%s' not found", fn)
+        bb.parse.mark_dependency(data, fn)
 
 # We have an issue where a UI might want to enforce particular settings such as
 # an empty DISTRO variable. If configuration files do something like assigning

bitbake/lib/bb/runqueue.py

@@ -217,6 +217,15 @@ class RunQueueData:
             ret.extend([nam])
         return ret
 
+    def get_task_name(self, task):
+        return self.runq_task[task]
+
+    def get_task_file(self, task):
+        return self.taskData.fn_index[self.runq_fnid[task]]
+
+    def get_task_hash(self, task):
+        return self.runq_hash[task]
+
     def get_user_idstring(self, task, task_name_suffix = ""):
         fn = self.taskData.fn_index[self.runq_fnid[task]]
         taskname = self.runq_task[task] + task_name_suffix
@@ -999,6 +1008,11 @@ class RunQueue:
             else:
                 self.state = runQueueSceneInit
 
+                # we are ready to run, see if any UI client needs the dependency info
+                if bb.cooker.CookerFeatures.SEND_DEPENDS_TREE in self.cooker.featureset:
+                    depgraph = self.cooker.buildDependTree(self, self.rqdata.taskData)
+                    bb.event.fire(bb.event.DepTreeGenerated(depgraph), self.cooker.data)
+
         if self.state is runQueueSceneInit:
             if self.cooker.configuration.dump_signatures:
                 self.dump_signatures()
@@ -1190,6 +1204,8 @@ class RunQueueExecuteTasks(RunQueueExecute):
 
         self.stampcache = {}
 
+        initial_covered = self.rq.scenequeue_covered.copy()
+
         # Mark initial buildable tasks
         for task in xrange(self.stats.total):
             self.runq_running.append(0)
@@ -1243,13 +1259,28 @@ class RunQueueExecuteTasks(RunQueueExecute):
             except TypeError:
                 covered_remove = bb.utils.better_eval(call2, locs)
 
-        for task in covered_remove:
+        def removecoveredtask(task):
             fn = self.rqdata.taskData.fn_index[self.rqdata.runq_fnid[task]]
             taskname = self.rqdata.runq_task[task] + '_setscene'
             bb.build.del_stamp(taskname, self.rqdata.dataCache, fn)
-            logger.debug(1, 'Not skipping task %s due to setsceneverify', task)
             self.rq.scenequeue_covered.remove(task)
 
+        toremove = covered_remove
+        for task in toremove:
+            logger.debug(1, 'Not skipping task %s due to setsceneverify', task)
+        while toremove:
+            covered_remove = []
+            for task in toremove:
+                removecoveredtask(task)
+                for deptask in self.rqdata.runq_depends[task]:
+                    if deptask not in self.rq.scenequeue_covered:
+                        continue
+                    if deptask in toremove or deptask in covered_remove or deptask in initial_covered:
+                        continue
+                    logger.debug(1, 'Task %s depends on task %s so not skipping' % (task, deptask))
+                    covered_remove.append(deptask)
+            toremove = covered_remove
+
         logger.debug(1, 'Full skip list %s', self.rq.scenequeue_covered)
 
         event.fire(bb.event.StampUpdate(self.rqdata.target_pairs, self.rqdata.dataCache.stamp), self.cfgData)
@@ -1377,7 +1408,7 @@ class RunQueueExecuteTasks(RunQueueExecute):
                 bb.event.fire(startevent, self.cfgData)
 
             taskdep = self.rqdata.dataCache.task_deps[fn]
-            if 'fakeroot' in taskdep and taskname in taskdep['fakeroot']:
+            if 'fakeroot' in taskdep and taskname in taskdep['fakeroot'] and not self.cooker.configuration.dry_run:
                 if not self.rq.fakeworker:
                     self.rq.start_fakeworker(self)
                 self.rq.fakeworker.stdin.write("<runtask>" + pickle.dumps((fn, task, taskname, False, self.cooker.collection.get_file_appends(fn))) + "</runtask>")
@@ -1781,6 +1812,9 @@ class runQueueEvent(bb.event.Event):
     def __init__(self, task, stats, rq):
         self.taskid = task
         self.taskstring = rq.rqdata.get_user_idstring(task)
+        self.taskname = rq.rqdata.get_task_name(task)
+        self.taskfile = rq.rqdata.get_task_file(task)
+        self.taskhash = rq.rqdata.get_task_hash(task)
         self.stats = stats.copy()
         bb.event.Event.__init__(self)
 
@@ -1792,6 +1826,9 @@ class sceneQueueEvent(runQueueEvent):
         runQueueEvent.__init__(self, task, stats, rq)
         realtask = rq.rqdata.runq_setscene[task]
         self.taskstring = rq.rqdata.get_user_idstring(realtask, "_setscene")
+        self.taskname = rq.rqdata.get_task_name(realtask) + "_setscene"
+        self.taskfile = rq.rqdata.get_task_file(realtask)
+        self.taskhash = rq.rqdata.get_task_hash(task)
 
 class runQueueTaskStarted(runQueueEvent):
     """

bitbake/lib/bb/server/__init__.py

@@ -89,7 +89,7 @@ class BitBakeBaseServer(object):
     def detach(self):
         return
 
-    def establishConnection(self):
+    def establishConnection(self, featureset):
         raise   "Must redefine the %s.establishConnection()" % self.__class__.__name__
 
     def endSession(self):

bitbake/lib/bb/server/process.py

@@ -31,7 +31,7 @@ import sys
 import time
 import select
 from Queue import Empty
-from multiprocessing import Event, Process, util, Queue, Pipe, queues
+from multiprocessing import Event, Process, util, Queue, Pipe, queues, Manager
 
 from . import BitBakeBaseServer, BitBakeBaseServerConnection, BaseImplServer
 
@@ -78,12 +78,13 @@ class ProcessServer(Process, BaseImplServer):
     profile_filename = "profile.log"
     profile_processed_filename = "profile.log.processed"
 
-    def __init__(self, command_channel, event_queue):
+    def __init__(self, command_channel, event_queue, featurelist):
         BaseImplServer.__init__(self)
-        Process.__init__(self)
+        Process.__init__(self, args=(featurelist))
         self.command_channel = command_channel
         self.event_queue = event_queue
         self.event = EventAdapter(event_queue)
+        self.featurelist = featurelist
         self.quit = False
 
         self.keep_running = Event()
@@ -94,6 +95,14 @@ class ProcessServer(Process, BaseImplServer):
         for event in bb.event.ui_queue:
             self.event_queue.put(event)
         self.event_handle.value = bb.event.register_UIHhandler(self)
+
+        # process any feature changes based on what UI requested
+        original_featureset = list(self.cooker.featureset)
+        while len(self.featurelist)> 0:
+            self.cooker.featureset.setFeature(self.featurelist.pop())
+        if (original_featureset != list(self.cooker.featureset)):
+            self.cooker.reset()
+
         bb.cooker.server_main(self.cooker, self.main)
 
     def main(self):
@@ -198,13 +207,17 @@ class BitBakeServer(BitBakeBaseServer):
         #
         self.ui_channel, self.server_channel = Pipe()
         self.event_queue = ProcessEventQueue(0)
-        self.serverImpl = ProcessServer(self.server_channel, self.event_queue)
+        manager = Manager()
+        self.featurelist = manager.list()
+        self.serverImpl = ProcessServer(self.server_channel, self.event_queue, self.featurelist)
 
     def detach(self):
         self.serverImpl.start()
         return
 
-    def establishConnection(self):
+    def establishConnection(self, featureset):
+        for f in featureset:
+            self.featurelist.append(f)
         self.connection = BitBakeProcessServerConnection(self.serverImpl, self.ui_channel, self.event_queue)
         signal.signal(signal.SIGTERM, lambda i, s: self.connection.terminate())
         return self.connection

bitbake/lib/bb/server/xmlrpc.py

@@ -89,12 +89,23 @@ class BitBakeServerCommands():
         self.server = server
         self.has_client = False
 
-    def registerEventHandler(self, host, port):
+    def registerEventHandler(self, host, port, featureset = []):
         """
         Register a remote UI Event Handler
         """
         s, t = _create_server(host, port)
 
+        # we don't allow connections if the cooker is running
+        if (self.cooker.state in [bb.cooker.state.parsing, bb.cooker.state.running]):
+            return None
+
+        original_featureset = list(self.cooker.featureset)
+        for f in featureset:
+            self.cooker.featureset.setFeature(f)
+
+        if (original_featureset != list(self.cooker.featureset)):
+            self.cooker.reset()
+
         self.event_handle = bb.event.register_UIHhandler(s)
         return self.event_handle
 
@@ -263,11 +274,12 @@ class XMLRPCServer(SimpleXMLRPCServer, BaseImplServer):
         self.connection_token = token
 
 class BitBakeXMLRPCServerConnection(BitBakeBaseServerConnection):
-    def __init__(self, serverImpl, clientinfo=("localhost", 0), observer_only = False):
+    def __init__(self, serverImpl, clientinfo=("localhost", 0), observer_only = False, featureset = []):
         self.connection, self.transport = _create_server(serverImpl.host, serverImpl.port)
         self.clientinfo = clientinfo
         self.serverImpl = serverImpl
         self.observer_only = observer_only
+        self.featureset = featureset
 
     def connect(self):
         if not self.observer_only:
@@ -277,7 +289,8 @@ class BitBakeXMLRPCServerConnection(BitBakeBaseServerConnection):
         if token is None:
             return None
         self.transport.set_connection_token(token)
-        self.events = uievent.BBUIEventQueue(self.connection, self.clientinfo)
+
+        self.events = uievent.BBUIEventQueue(self.connection, self.clientinfo, self.featureset)
         for event in bb.event.ui_queue:
             self.events.queue_event(event)
         return self
@@ -301,14 +314,15 @@ class BitBakeXMLRPCServerConnection(BitBakeBaseServerConnection):
 
 class BitBakeServer(BitBakeBaseServer):
     def initServer(self, interface = ("localhost", 0)):
+        self.interface = interface
         self.serverImpl = XMLRPCServer(interface)
 
     def detach(self):
         daemonize.createDaemon(self.serverImpl.serve_forever, "bitbake-cookerdaemon.log")
         del self.cooker
 
-    def establishConnection(self):
-        self.connection = BitBakeXMLRPCServerConnection(self.serverImpl)
+    def establishConnection(self, featureset):
+        self.connection = BitBakeXMLRPCServerConnection(self.serverImpl, self.interface, False, featureset)
         return self.connection.connect()
 
     def set_connection_token(self, token):
@@ -318,12 +332,13 @@ class BitBakeXMLRPCClient(BitBakeBaseServer):
 
     def __init__(self, observer_only = False):
         self.observer_only = observer_only
+        # if we need extra caches, just tell the server to load them all
         pass
 
     def saveConnectionDetails(self, remote):
         self.remote = remote
 
-    def establishConnection(self):
+    def establishConnection(self, featureset):
         # The format of "remote" must be "server:port"
         try:
             [host, port] = self.remote.split(":")
@@ -339,9 +354,12 @@ class BitBakeXMLRPCClient(BitBakeBaseServer):
             s.close()
         except:
             return None
-        self.serverImpl = XMLRPCProxyServer(host, port)
-        self.connection = BitBakeXMLRPCServerConnection(self.serverImpl, (ip, 0), self.observer_only)
-        return self.connection.connect()
+        try:
+            self.serverImpl = XMLRPCProxyServer(host, port)
+            self.connection = BitBakeXMLRPCServerConnection(self.serverImpl, (ip, 0), self.observer_only, featureset)
+            return self.connection.connect()
+        except Exception as e:
+            bb.fatal("Could not connect to server at %s:%s (%s)" % (host, port, str(e)))
 
     def endSession(self):
         self.connection.removeClient()

bitbake/lib/bb/tests/data.py

@@ -27,21 +27,21 @@ import bb.data
 class DataExpansions(unittest.TestCase):
     def setUp(self):
         self.d = bb.data.init()
-        self.d["foo"] = "value of foo"
-        self.d["bar"] = "value of bar"
-        self.d["value of foo"] = "value of 'value of foo'"
+        self.d["foo"] = "value_of_foo"
+        self.d["bar"] = "value_of_bar"
+        self.d["value_of_foo"] = "value_of_'value_of_foo'"
 
     def test_one_var(self):
         val = self.d.expand("${foo}")
-        self.assertEqual(str(val), "value of foo")
+        self.assertEqual(str(val), "value_of_foo")
 
     def test_indirect_one_var(self):
         val = self.d.expand("${${foo}}")
-        self.assertEqual(str(val), "value of 'value of foo'")
+        self.assertEqual(str(val), "value_of_'value_of_foo'")
 
     def test_indirect_and_another(self):
         val = self.d.expand("${${foo}} ${bar}")
-        self.assertEqual(str(val), "value of 'value of foo' value of bar")
+        self.assertEqual(str(val), "value_of_'value_of_foo' value_of_bar")
 
     def test_python_snippet(self):
         val = self.d.expand("${@5*12}")
@@ -49,11 +49,11 @@ class DataExpansions(unittest.TestCase):
 
     def test_expand_in_python_snippet(self):
         val = self.d.expand("${@'boo ' + '${foo}'}")
-        self.assertEqual(str(val), "boo value of foo")
+        self.assertEqual(str(val), "boo value_of_foo")
 
     def test_python_snippet_getvar(self):
         val = self.d.expand("${@d.getVar('foo', True) + ' ${bar}'}")
-        self.assertEqual(str(val), "value of foo value of bar")
+        self.assertEqual(str(val), "value_of_foo value_of_bar")
 
     def test_python_snippet_syntax_error(self):
         self.d.setVar("FOO", "${@foo = 5}")
@@ -70,7 +70,7 @@ class DataExpansions(unittest.TestCase):
 
     def test_value_containing_value(self):
         val = self.d.expand("${@d.getVar('foo', True) + ' ${bar}'}")
-        self.assertEqual(str(val), "value of foo value of bar")
+        self.assertEqual(str(val), "value_of_foo value_of_bar")
 
     def test_reference_undefined_var(self):
         val = self.d.expand("${undefinedvar} meh")
@@ -109,7 +109,7 @@ class DataExpansions(unittest.TestCase):
 
     def test_rename(self):
         self.d.renameVar("foo", "newfoo")
-        self.assertEqual(self.d.getVar("newfoo"), "value of foo")
+        self.assertEqual(self.d.getVar("newfoo"), "value_of_foo")
         self.assertEqual(self.d.getVar("foo"), None)
 
     def test_deletion(self):
@@ -118,17 +118,17 @@ class DataExpansions(unittest.TestCase):
 
     def test_keys(self):
         keys = self.d.keys()
-        self.assertEqual(keys, ['value of foo', 'foo', 'bar'])
+        self.assertEqual(keys, ['value_of_foo', 'foo', 'bar'])
 
 class TestNestedExpansions(unittest.TestCase):
     def setUp(self):
         self.d = bb.data.init()
         self.d["foo"] = "foo"
         self.d["bar"] = "bar"
-        self.d["value of foobar"] = "187"
+        self.d["value_of_foobar"] = "187"
 
     def test_refs(self):
-        val = self.d.expand("${value of ${foo}${bar}}")
+        val = self.d.expand("${value_of_${foo}${bar}}")
         self.assertEqual(str(val), "187")
 
     #def test_python_refs(self):
@@ -154,11 +154,11 @@ class TestNestedExpansions(unittest.TestCase):
     #    self.assertEqual(str(val), str(depth + 1))
 
     def test_mixed(self):
-        val = self.d.expand("${value of ${@('${foo}'+'bar')[0:3]}${${@'BAR'.lower()}}}")
+        val = self.d.expand("${value_of_${@('${foo}'+'bar')[0:3]}${${@'BAR'.lower()}}}")
         self.assertEqual(str(val), "187")
 
     def test_runtime(self):
-        val = self.d.expand("${${@'value of' + ' f'+'o'+'o'+'b'+'a'+'r'}}")
+        val = self.d.expand("${${@'value_of' + '_f'+'o'+'o'+'b'+'a'+'r'}}")
         self.assertEqual(str(val), "187")
 
 class TestMemoize(unittest.TestCase):

bitbake/lib/bb/tests/fetch.py

@@ -407,7 +407,8 @@ class URLHandle(unittest.TestCase):
     datatable = {
        "http://www.google.com/index.html" : ('http', 'www.google.com', '/index.html', '', '', {}),
        "cvs://anoncvs@cvs.handhelds.org/cvs;module=familiar/dist/ipkg" : ('cvs', 'cvs.handhelds.org', '/cvs', 'anoncvs', '', {'module': 'familiar/dist/ipkg'}),
-       "cvs://anoncvs:anonymous@cvs.handhelds.org/cvs;tag=V0-99-81;module=familiar/dist/ipkg" : ('cvs', 'cvs.handhelds.org', '/cvs', 'anoncvs', 'anonymous', {'tag': 'V0-99-81', 'module': 'familiar/dist/ipkg'})
+       "cvs://anoncvs:anonymous@cvs.handhelds.org/cvs;tag=V0-99-81;module=familiar/dist/ipkg" : ('cvs', 'cvs.handhelds.org', '/cvs', 'anoncvs', 'anonymous', {'tag': 'V0-99-81', 'module': 'familiar/dist/ipkg'}),
+       "git://git.openembedded.org/bitbake;branch=@foo" : ('git', 'git.openembedded.org', '/bitbake', '', '', {'branch': '@foo'})
     }
 
     def test_decodeurl(self):

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

@@ -31,6 +31,7 @@ import re
 import logging
 import sys
 import signal
+import time
 from bb.ui.crumbs.imageconfigurationpage import ImageConfigurationPage
 from bb.ui.crumbs.recipeselectionpage import RecipeSelectionPage
 from bb.ui.crumbs.packageselectionpage import PackageSelectionPage
@@ -197,7 +198,7 @@ class Configuration:
         handler.set_var_in_file("BBLAYERS", self.layers, "bblayers.conf")
         # local.conf
         if not defaults:
-            handler.set_var_in_file("MACHINE", self.curr_mach, "local.conf")
+            handler.early_assign_var_in_file("MACHINE", self.curr_mach, "local.conf")
         handler.set_var_in_file("DISTRO", self.curr_distro, "local.conf")
         handler.set_var_in_file("DL_DIR", self.dldir, "local.conf")
         handler.set_var_in_file("SSTATE_DIR", self.sstatedir, "local.conf")
@@ -217,7 +218,7 @@ class Configuration:
         handler.set_var_in_file("SDKMACHINE", self.curr_sdk_machine, "local.conf")
         handler.set_var_in_file("CONF_VERSION", self.conf_version, "local.conf")
         handler.set_var_in_file("LCONF_VERSION", self.lconf_version, "bblayers.conf")
-        handler.set_var_in_file("EXTRA_SETTING", self.extra_setting, "local.conf")
+        handler.set_extra_config(self.extra_setting)
         handler.set_var_in_file("TOOLCHAIN_BUILD", self.toolchain_build, "local.conf")
         handler.set_var_in_file("IMAGE_FSTYPES", self.image_fstypes, "local.conf")
         if not defaults:
@@ -1466,3 +1467,10 @@ class Builder(gtk.Window):
 
     def get_topdir(self):
         return self.handler.get_topdir()
+
+    def wait(self, delay):
+        time_start = time.time()
+        time_end = time_start + delay
+        while time_end > time.time():
+            while gtk.events_pending():
+                gtk.main_iteration()

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

@@ -234,7 +234,10 @@ class AdvancedSettingsDialog (CrumbsDialog, SettingsUIHelper):
             article = ""
             if image_type.startswith(("a", "e", "i", "o", "u")):
                 article = "n"
-            self.image_types_checkbuttons[image_type].set_tooltip_text("Build a%s %s image" % (article, image_type))
+            if image_type == "live":
+                self.image_types_checkbuttons[image_type].set_tooltip_text("Build iso and hddimg images")
+            else:
+                self.image_types_checkbuttons[image_type].set_tooltip_text("Build a%s %s image" % (article, image_type))
             table.attach(self.image_types_checkbuttons[image_type], j - 1, j + 3, i, i + 1)
             if image_type in self.configuration.image_fstypes.split():
                 self.image_types_checkbuttons[image_type].set_active(True)

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

@@ -21,6 +21,7 @@
 
 import gobject
 import logging
+import ast
 from bb.ui.crumbs.runningbuild import RunningBuild
 
 class HobHandler(gobject.GObject):
@@ -315,7 +316,7 @@ class HobHandler(gobject.GObject):
 
     def set_machine(self, machine):
         if machine:
-            self.set_var_in_file("MACHINE", machine, "local.conf")
+            self.early_assign_var_in_file("MACHINE", machine, "local.conf")
 
     def set_sdk_machine(self, sdk_machine):
         self.set_var_in_file("SDKMACHINE", sdk_machine, "local.conf")
@@ -357,7 +358,20 @@ class HobHandler(gobject.GObject):
     def set_incompatible_license(self, incompat_license):
         self.set_var_in_file("INCOMPATIBLE_LICENSE", incompat_license, "local.conf")
 
+    def set_extra_setting(self, extra_setting):
+        self.set_var_in_file("EXTRA_SETTING", extra_setting, "local.conf")
+
     def set_extra_config(self, extra_setting):
+        old_extra_setting = ast.literal_eval(self.runCommand(["getVariable", "EXTRA_SETTING"]) or "{}")
+        if extra_setting:
+            self.set_var_in_file("EXTRA_SETTING", extra_setting, "local.conf")
+        else:
+            self.remove_var_from_file("EXTRA_SETTING")
+
+        #remove not needed settings from conf
+        for key in old_extra_setting:
+            if key not in extra_setting:
+                self.remove_var_from_file(key)
         for key in extra_setting.keys():
             value = extra_setting[key]
             self.set_var_in_file(key, value, "local.conf")
@@ -472,6 +486,14 @@ class HobHandler(gobject.GObject):
         self.server.runCommand(["setVarFile", var, val, default_file, "set"])
         self.runCommand(["disableDataTracking"])
 
+    def early_assign_var_in_file(self, var, val, default_file=None):
+        self.runCommand(["enableDataTracking"])
+        self.server.runCommand(["setVarFile", var, val, default_file, "earlyAssign"])
+        self.runCommand(["disableDataTracking"])
+
+    def remove_var_from_file(self, var):
+        self.server.runCommand(["removeVarFile", var])
+
     def append_var_in_file(self, var, val, default_file=None):
         self.server.runCommand(["setVarFile", var, val, default_file, "append"])
 

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

@@ -199,7 +199,9 @@ class PackageListModel(gtk.ListStore):
         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):
+        if val1 is None or val2 is None:
+            return 0
+        elif 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
@@ -575,7 +577,9 @@ class RecipeListModel(gtk.ListStore):
         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):
+        if val1 is None or val2 is None:
+            return 0
+        elif 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
@@ -690,7 +694,7 @@ class RecipeListModel(gtk.ListStore):
             inherits = event_model["pn"][item]["inherits"]
             summary = event_model["pn"][item]["summary"]
             version = event_model["pn"][item]["version"]
-            revision = event_model["pn"][item]["revision"]
+            revision = event_model["pn"][item]["prevision"]
             homepage = event_model["pn"][item]["homepage"]
             bugtracker = event_model["pn"][item]["bugtracker"]
             filename = event_model["pn"][item]["filename"]

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

@@ -300,7 +300,12 @@ class ImageConfigurationPage (HobPage):
     def view_warnings_button_clicked_cb(self, button):
         self.builder.show_warning_dialog()
 
+    def machine_combo_changed_idle_cb(self):
+        self.builder.window.set_cursor(None)
+
     def machine_combo_changed_cb(self, machine_combo):
+        self.builder.window.set_cursor(gtk.gdk.Cursor(gtk.gdk.WATCH))
+        self.builder.wait(0.1) #wait for combo and cursor to update
         self.stopping = False
         self.builder.parsing_warnings = []
         combo_item = machine_combo.get_active_text()
@@ -324,6 +329,8 @@ class ImageConfigurationPage (HobPage):
         # Do reparse recipes
         self.builder.populate_recipe_package_info_async()
 
+        glib.idle_add(self.machine_combo_changed_idle_cb)
+
     def update_machine_combo(self):
         self.disable_warnings_bar()
         all_machines = [self.__dummy_machine__] + self.builder.parameters.all_machines
@@ -527,7 +534,10 @@ class ImageConfigurationPage (HobPage):
         if not response:
             return
         if settings_changed:
+            self.builder.window.set_cursor(gtk.gdk.Cursor(gtk.gdk.WATCH))
+            self.builder.wait(0.1) #wait for adv_settings_dialog to terminate
             self.builder.reparse_post_adv_settings()
+            self.builder.window.set_cursor(None)
 
     def just_bake_button_clicked_cb(self, button):
         self.builder.parsing_warnings = []

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

@@ -355,9 +355,9 @@ class ImageDetailsPage (HobPage):
             vallist.append(base_image)
             i = 0
             for layer in layers:
-                varlist.append(" - ")
                 if i > layer_num_limit:
                     break
+                varlist.append(" - ")
                 i += 1
             vallist.append("")
             i = 0
@@ -635,6 +635,14 @@ class ImageDetailsPage (HobPage):
         images_dir = topdir + "/recipes/images/"
         self.builder.ensure_dir(images_dir)
 
+        self.name_field_template = self.builder.image_configuration_page.custom_image_selected
+        if self.name_field_template:
+            image_path = self.builder.recipe_model.pn_path[self.name_field_template]
+            image_iter = self.builder.recipe_model.get_iter(image_path)
+            self.description_field_template = self.builder.recipe_model.get_value(image_iter, self.builder.recipe_model.COL_DESC)
+        else:
+            self.name_field_template = ""
+
         dialog = SaveImageDialog(images_dir, self.name_field_template, self.description_field_template,
                  "Save image recipe", self.builder, gtk.DIALOG_MODAL | gtk.DIALOG_DESTROY_WITH_PARENT)
         response = dialog.run()

bitbake/lib/bb/ui/hob.py

@@ -46,7 +46,7 @@ from bb.ui.crumbs.hoblistmodel import RecipeListModel, PackageListModel
 from bb.ui.crumbs.hobeventhandler import HobHandler
 from bb.ui.crumbs.builder import Builder
 
-extraCaches = ['bb.cache_extra:HobRecipeInfo']
+featureSet = [bb.cooker.CookerFeatures.HOB_EXTRA_CACHES]
 
 def event_handle_idle_func(eventHandler, hobHandler):
     # Consume as many messages as we can in the time available to us

bitbake/lib/bb/ui/knotty.py

@@ -472,8 +472,12 @@ def main(server, eventHandler, params, tf = TerminalFilter):
                              event.taskid, event.taskstring, event.exitcode)
                 continue
 
+            if isinstance(event, bb.event.DepTreeGenerated):
+                continue
+
             # ignore
             if isinstance(event, (bb.event.BuildBase,
+                                  bb.event.MetadataEvent,
                                   bb.event.StampUpdate,
                                   bb.event.ConfigParsed,
                                   bb.event.RecipeParsed,

bitbake/lib/bb/ui/uievent.py

@@ -28,7 +28,7 @@ import socket, threading, pickle
 from SimpleXMLRPCServer import SimpleXMLRPCServer, SimpleXMLRPCRequestHandler
 
 class BBUIEventQueue:
-    def __init__(self, BBServer, clientinfo=("localhost, 0")):
+    def __init__(self, BBServer, clientinfo=("localhost, 0"), featureset=[]):
 
         self.eventQueue = []
         self.eventQueueLock = threading.Lock()
@@ -44,7 +44,10 @@ class BBUIEventQueue:
         server.register_function( self.send_event, "event.sendpickle" )
         server.socket.settimeout(1)
 
-        self.EventHandle = self.BBServer.registerEventHandler(self.host, self.port)
+        self.EventHandle = self.BBServer.registerEventHandler(self.host, self.port, featureset)
+
+        if (self.EventHandle == None):
+            bb.fatal("Could not register UI event handler")
 
         self.server = server
 

bitbake/lib/bb/utils.py

@@ -724,7 +724,7 @@ def copyfile(src, dest, newmtime = None, sstat = None):
         if not sstat:
             sstat = os.lstat(src)
     except Exception as e:
-        print("copyfile: Stating source file failed...", e)
+        logger.warn("copyfile: stat of %s failed (%s)" % (src, e))
         return False
 
     destexists = 1
@@ -751,7 +751,7 @@ def copyfile(src, dest, newmtime = None, sstat = None):
             #os.lchown(dest,sstat[stat.ST_UID],sstat[stat.ST_GID])
             return os.lstat(dest)
         except Exception as e:
-            print("copyfile: failed to properly create symlink:", dest, "->", target, e)
+            logger.warn("copyfile: failed to create symlink %s to %s (%s)" % (dest, target, e))
             return False
 
     if stat.S_ISREG(sstat[stat.ST_MODE]):
@@ -766,7 +766,7 @@ def copyfile(src, dest, newmtime = None, sstat = None):
             shutil.copyfile(src, dest + "#new")
             os.rename(dest + "#new", dest)
         except Exception as e:
-            print('copyfile: copy', src, '->', dest, 'failed.', e)
+            logger.warn("copyfile: copy %s to %s failed (%s)" % (src, dest, e))
             return False
         finally:
             if srcchown:
@@ -777,13 +777,13 @@ def copyfile(src, dest, newmtime = None, sstat = None):
         #we don't yet handle special, so we need to fall back to /bin/mv
         a = getstatusoutput("/bin/cp -f " + "'" + src + "' '" + dest + "'")
         if a[0] != 0:
-            print("copyfile: Failed to copy special file:" + src + "' to '" + dest + "'", a)
+            logger.warn("copyfile: failed to copy special file %s to %s (%s)" % (src, dest, a))
             return False # failure
     try:
         os.lchown(dest, sstat[stat.ST_UID], sstat[stat.ST_GID])
         os.chmod(dest, stat.S_IMODE(sstat[stat.ST_MODE])) # Sticky is reset on chown
     except Exception as e:
-        print("copyfile: Failed to chown/chmod/unlink", dest, e)
+        logger.warn("copyfile: failed to chown/chmod %s (%s)" % (dest, e))
         return False
 
     if newmtime:
@@ -793,22 +793,28 @@ def copyfile(src, dest, newmtime = None, sstat = None):
         newmtime = sstat[stat.ST_MTIME]
     return newmtime
 
-def which(path, item, direction = 0):
+def which(path, item, direction = 0, history = False):
     """
     Locate a file in a PATH
     """
 
+    hist = []
     paths = (path or "").split(':')
     if direction != 0:
         paths.reverse()
 
     for p in paths:
         next = os.path.join(p, item)
+        hist.append(next)
         if os.path.exists(next):
             if not os.path.isabs(next):
                 next = os.path.abspath(next)
+            if history:
+                return next, hist
             return next
 
+    if history:
+        return "", hist
     return ""
 
 def to_boolean(string, default=None):

documentation/Makefile

@@ -200,7 +200,8 @@ TARFILES = mega-manual.html mega-style.css figures/yocto-environment.png figures
 	figures/yocto-environment-ref.png figures/user-configuration.png figures/source-input.png \
 	figures/package-feeds.png figures/layer-input.png figures/images.png figures/sdk.png \
 	figures/source-fetching.png figures/patching.png figures/configuration-compile-autoreconf.png \
-	figures/analysis-for-package-splitting.png
+	figures/analysis-for-package-splitting.png figures/image-generation.png \
+	figures/sdk-generation.png
 	endif
 
 MANUALS = $(DOC)/$(DOC).html
@@ -219,7 +220,8 @@ TARFILES = ref-manual.html ref-style.css figures/poky-title.png \
 	figures/user-configuration.png figures/yocto-environment-ref.png \
 	figures/images.png figures/sdk.png figures/source-fetching.png \
 	figures/patching.png figures/configuration-compile-autoreconf.png \
-	figures/analysis-for-package-splitting.png
+	figures/analysis-for-package-splitting.png figures/image-generation.png \
+	figures/sdk-generation.png
 MANUALS = $(DOC)/$(DOC).html $(DOC)/$(DOC).pdf $(DOC)/eclipse
 FIGURES = figures
 STYLESHEET = $(DOC)/*.css
@@ -381,8 +383,8 @@ publish:
             echo " "; \
             echo "******** Publishing "$(DOC)".html"; \
             echo " "; \
-            scp -r $(MANUALS) $(STYLESHEET) www.yoctoproject.org:/srv/www/www.yoctoproject.org-docs/$(VER)/$(DOC); \
-            cd $(DOC); scp -r $(FIGURES) www.yoctoproject.org:/srv/www/www.yoctoproject.org-docs/$(VER)/$(DOC); \
+            scp -r $(MANUALS) $(STYLESHEET) docs.yp:/var/www/www.yoctoproject.org-docs/$(VER)/$(DOC); \
+            cd $(DOC); scp -r $(FIGURES) docs.yp:/var/www/www.yoctoproject.org-docs/$(VER)/$(DOC); \
 	else \
           echo " "; \
           echo $(DOC)".html missing.  Generate the file first then try again."; \

documentation/adt-manual/adt-command.xml

@@ -8,23 +8,32 @@
     <para>
         Recall that earlier the manual discussed how to use an existing toolchain
         tarball that had been installed into the default installation
-        directory, <filename>/opt/poky</filename>, which is outside of the
+        directory, <filename>/opt/poky/&DISTRO;</filename>, which is outside of the
         <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
         (see the section "<link linkend='using-an-existing-toolchain-tarball'>Using a Cross-Toolchain Tarball)</link>".
         And, that sourcing your architecture-specific environment setup script
         initializes a suitable cross-toolchain development environment.
-        During the setup, locations for the compiler, QEMU scripts, QEMU binary,
+    </para>
+
+    <para>
+        During this setup, locations for the compiler, QEMU scripts, QEMU binary,
         a special version of <filename>pkgconfig</filename> and other useful
         utilities are added to the <filename>PATH</filename> variable.
-        Variables to assist <filename>pkgconfig</filename> and <filename>autotools</filename>
-        are also defined so that,
-        for example, <filename>configure.sh</filename> can find pre-generated
-        test results for tests that need target hardware on which to run.
-        These conditions allow you to easily use the toolchain outside of the
-        OpenEmbedded build environment on both autotools-based projects and
-        Makefile-based projects.
+        Also, variables to assist
+        <filename>pkgconfig</filename> and <filename>autotools</filename>
+        are also defined so that, for example, <filename>configure.sh</filename>
+        can find pre-generated test results for tests that need target hardware
+        on which to run.
     </para>
 
+    <para>
+        Collectively, these conditions allow you to easily use the toolchain
+        outside of the OpenEmbedded build environment on both autotools-based
+        projects and Makefile-based projects.
+        This chapter provides information for both these types of projects.
+    </para>
+
+
 <section id='autotools-based-projects'>
 <title>Autotools-Based Projects</title>
 
@@ -179,7 +188,7 @@
                 If <filename>configure</filename> script results in problems recognizing the
                 <filename>--with-libtool-sysroot=&lt;sysroot-dir&gt;</filename> option,
                 regenerate the script to enable the support by doing the following and then
-                re-running the script:
+                run the script again:
                 <literallayout class='monospaced'>
      $ libtoolize --automake
      $ aclocal -I ${OECORE_NATIVE_SYSROOT}/usr/share/aclocal \

documentation/adt-manual/adt-intro.xml

@@ -22,8 +22,8 @@
     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.  
+        The ADT is distribution-neutral and does not require the Yocto
+        Project reference distribution, which is called Poky.
         This manual, however, uses examples that use the Poky distribution.
     </note>
 </para>
@@ -43,7 +43,7 @@
         <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 
+                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.
@@ -149,8 +149,7 @@
                     that causes skips in audio,
                     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='https://latencytop.org/'></ulink>.</para></listitem>
+                    </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

@@ -63,9 +63,29 @@
             </revision>
             <revision>
                 <revnumber>1.5</revnumber>
-                <date>Sometime in 2013</date>
+                <date>October 2013</date>
                 <revremark>Released with the Yocto Project 1.5 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>1.5.1</revnumber>
+                <date>January 2014</date>
+                <revremark>Released with the Yocto Project 1.5.1 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.5.2</revnumber>
+                <date>May 2014</date>
+                <revremark>Released with the Yocto Project 1.5.2 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.5.3</revnumber>
+                <date>July 2014</date>
+                <revremark>Released with the Yocto Project 1.5.3 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.5.4</revnumber>
+                <date>December 2014</date>
+                <revremark>Released with the Yocto Project 1.5.4 Release.</revremark>
+            </revision>
        </revhistory>
 
     <copyright>
@@ -79,11 +99,10 @@
         the terms of the <ulink type="http" url="http://creativecommons.org/licenses/by-sa/2.0/uk/">Creative Commons Attribution-Share Alike 2.0 UK: England &amp; Wales</ulink> as published by Creative Commons.
       </para>
       <note>
-          Due to production processes, there could be differences between the Yocto Project
-          documentation bundled in the release tarball and the
-          <ulink url='&YOCTO_DOCS_ADT_URL;'>Yocto Project Application Developer's Guide</ulink> on
-          the <ulink url='&YOCTO_HOME_URL;'>Yocto Project</ulink> website.
-          For the latest version of this manual, see the manual on the website.
+          For the latest version of this manual associated with this
+          Yocto Project release, see the
+          <ulink url='&YOCTO_DOCS_ADT_URL;'>Yocto Project Application Developer's Guide</ulink>
+          from the Yocto Project website.
       </note>
 
     </legalnotice>

documentation/adt-manual/adt-prepare.xml

@@ -80,39 +80,48 @@
 
             <para>
                 The ADT Installer is contained in the ADT Installer tarball.
-                You can download the tarball into any directory from the
-                <ulink url='&YOCTO_DL_URL;/releases'>Index of Releases</ulink>, specifically
-                at
-                <ulink url='&YOCTO_ADTINSTALLER_DL_URL;'></ulink>.
-                Or, you can use BitBake to generate the tarball inside the existing
-                <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
-            </para>
-
-            <para>
-                If you use BitBake to generate the ADT Installer tarball, you must
-                <filename>source</filename> the environment setup script
-                (<ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>
-                or 
-                <ulink url='&YOCTO_DOCS_REF_URL;#structure-memres-core-script'><filename>oe-init-build-env-memres</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 BitBake command that results in the tarball
-                <filename>~/yocto-project/build/tmp/deploy/sdk/adt_installer.tar.bz2</filename>:
-                <literallayout class='monospaced'>
+                You can get the tarball using either of these methods:
+                <itemizedlist>
+                    <listitem><para><emphasis>Download the Tarball:</emphasis>
+                        You can download the tarball from
+                        <ulink url='&YOCTO_ADTINSTALLER_DL_URL;'></ulink> into
+                        any directory.</para></listitem>
+                    <listitem><para><emphasis>Build the Tarball:</emphasis>
+                        You can use BitBake to generate the tarball inside an
+                        existing
+                        <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+                        </para>
+                        <para>If you use BitBake to generate the ADT Installer
+                        tarball, you must <filename>source</filename> the
+                        environment setup script
+                        (<ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>
+                        or
+                        <ulink url='&YOCTO_DOCS_REF_URL;#structure-memres-core-script'><filename>oe-init-build-env-memres</filename></ulink>)
+                        located in the Source Directory before running the
+                        BitBake command that creates the tarball.</para>
+                        <para>The following example commands establish
+                        the
+                        <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>,
+                        check out the current release branch, set up the
+                        build environment while also creating the default
+                        Build Directory, and run the BitBake command that
+                        results in the tarball
+                        <filename>poky/build/tmp/deploy/sdk/adt_installer.tar.bz2</filename>:
+                        <note>
+                            Before using BitBake to build the ADT tarball, be
+                            sure to make sure your
+                            <filename>local.conf</filename> file is properly
+                            configured.
+                        </note>
+                        <literallayout class='monospaced'>
      $ cd ~
-     $ mkdir yocto-project
-     $ cd yocto-project
-     $ wget &YOCTO_RELEASE_DL_URL;/&YOCTO_POKY_TARBALL;
-     $ tar xjf &YOCTO_POKY_TARBALL;
-     $ source &OE_INIT_PATH;
+     $ git clone git://git.yoctoproject.org/poky
+     $ cd poky
+     $ git checkout -b &DISTRO_NAME; origin/&DISTRO_NAME;
+     $ source &OE_INIT_FILE;
      $ bitbake adt-installer
-                </literallayout>
+                        </literallayout></para></listitem>
+                </itemizedlist>
             </para>
         </section>
 
@@ -127,7 +136,7 @@
                 a top-level directory named <filename>adt-installer</filename>:
                 <literallayout class='monospaced'>
      $ cd ~
-     $ cp ~/poky/build/tmp/deploy/sdk/adt_installer.tar.bz2 $HOME
+     $ cp poky/build/tmp/deploy/sdk/adt_installer.tar.bz2 $HOME
      $ tar -xjf adt_installer.tar.bz2
                 </literallayout>
                 Unpacking it creates the directory <filename>adt-installer</filename>,
@@ -192,12 +201,9 @@
 
             <para>
                 After you have configured the <filename>adt_installer.conf</filename> file,
-                run the installer using the following command.
-                Be sure that you are not trying to use cross-compilation tools.
-                When you run the installer, the environment must use a
-                host <filename>gcc</filename>:
+                run the installer using the following command:
                 <literallayout class='monospaced'>
-     $ cd ~/adt-installer
+     $ cd adt-installer
      $ ./adt_installer
                 </literallayout>
                 Once the installer begins to run, you are asked to enter the
@@ -268,7 +274,7 @@
                             target, go into the <filename>x86_64</filename>
                             folder and download the following installer:
                             <literallayout class='monospaced'>
-     poky-eglibc-x86_64-core-image-sato-i586.sh
+     poky-eglibc-x86_64-core-image-sato-i586-toolchain-&DISTRO;.sh
                             </literallayout></para></listitem>
                         <listitem><para>Build your own toolchain installer.
                             For cases where you cannot use an installer
@@ -279,27 +285,32 @@
                     </itemizedlist></para></listitem>
                 <listitem><para>Once you have the installer, run it to install
                     the toolchain.
-                    You must change the permissions on the toolchain installer
-                    script so that it is executable.</para>
+                    <note>
+                        You must change the permissions on the toolchain
+                        installer script so that it is executable.
+                    </note></para>
                     <para>The following command shows how to run the installer
                     given a toolchain tarball for a 64-bit x86 development host
                     system and a 32-bit x86 target architecture.
                     The example assumes the toolchain installer is located
                     in <filename>~/Downloads/</filename>.
                     <literallayout class='monospaced'>
-     $ ~/Downloads/poky-eglibc-x86_64-core-image-sato-i586.sh
+     $ ~/Downloads/poky-eglibc-x86_64-core-image-sato-i586-toolchain-&DISTRO;.sh
                     </literallayout>
-                    <note>
-                        If you do not have write permissions for the directory
-                        into which you are installing the toolchain, the
-                        toolchain installer notifies you and exits.
-                        Be sure you have write permissions in the directory and
-                        run the installer again.
-                    </note>
-                    Once the tarball is expanded, the cross-toolchain is
+                    The first thing the installer prompts you for is the
+                    directory into which you want to install the toolchain.
+                    The default directory used is
+                    <filename>/opt/poky/&DISTRO;</filename>.
+                    If you do not have write permissions for the directory
+                    into which you are installing the toolchain, the
+                    toolchain installer notifies you and exits.
+                    Be sure you have write permissions in the directory and
+                    run the installer again.</para>
+                    <para>When the script finishes, the cross-toolchain is
                     installed.
                     You will notice environment setup files for the
-                    cross-toolchain in the directory.</para></listitem>
+                    cross-toolchain in the installation directory.
+                    </para></listitem>
             </orderedlist>
         </para>
     </section>
@@ -320,37 +331,43 @@
         <para>
             Follow these steps to generate the toolchain into the Build Directory:
             <orderedlist>
-                <listitem><para>Source the environment setup script
-                    <filename>&OE_INIT_FILE;</filename> located in the
+                <listitem><para><emphasis>Set up the Build Environment:</emphasis>
+                    Source the OpenEmbedded build environment setup
+                    script (i.e.
+                    <ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>
+                    or
+                    <ulink url='&YOCTO_DOCS_REF_URL;#structure-memres-core-script'><filename>oe-init-build-env-memres</filename></ulink>)
+                    located in the
                     <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
                     </para></listitem>
-                <listitem><para>At this point, you should be sure that the
+                <listitem><para><emphasis>Check your Local Configuration File:</emphasis>
+                    At this point, you should be sure that the
                     <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink> variable
                     in the <filename>local.conf</filename> file found in the
                     <filename>conf</filename> directory of the Build Directory
                     is set for the target architecture.
-                    Comments within the <filename>local.conf</filename> file list the values you
-                    can use for the <filename>MACHINE</filename> variable.
-                    <note>You can populate the Build Directory with the cross-toolchains for more
-                        than a single architecture.
-                        You just need to edit the <filename>MACHINE</filename> variable in the
-                        <filename>local.conf</filename> file and re-run the BitBake
-                        command.</note></para></listitem>
-                <listitem><para>Run <filename>bitbake meta-ide-support</filename> to complete the
-                    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 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 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.
-                    Setup script filenames contain the strings <filename>environment-setup</filename>.</para>
-                    <para>Be aware that when you use this method to install the toolchain you still need
-                    to separately extract and install the sysroot filesystem.
+                    Comments within the <filename>local.conf</filename> file
+                    list the values you can use for the
+                    <filename>MACHINE</filename> variable.
+                    <note>
+                        You can populate the Build Directory with the
+                        cross-toolchains for more than a single architecture.
+                        You just need to edit the <filename>MACHINE</filename>
+                        variable in the <filename>local.conf</filename> file and
+                        re-run the BitBake command.
+                    </note></para></listitem>
+                <listitem><para><emphasis>Generate the Cross-Toolchain:</emphasis>
+                    Run <filename>bitbake meta-ide-support</filename> to
+                    complete the cross-toolchain generation.
+                    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 that contain the string
+                    "<filename>environment-setup</filename>" in the
+                    Build Directory's <filename>tmp</filename> folder.</para>
+                    <para>Be aware that when you use this method to install the
+                    toolchain, you still need to separately extract and install
+                    the sysroot filesystem.
                     For information on how to do this, see the
                     "<link linkend='extracting-the-root-filesystem'>Extracting the Root Filesystem</link>" section.
                     </para></listitem>
@@ -376,10 +393,11 @@
     </para>
 
     <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>"
-        and include as part of their name the architecture.
+        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>" 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
         would be the following:
@@ -436,8 +454,8 @@
             application from within the
             Eclipse IDE, you must have an image that contains the Yocto Target Communication
             Framework (TCF) agent (<filename>tcf-agent</filename>).
-            By default, the Yocto Project provides only one type pre-built image that contains the
-            <filename>tcf-agent</filename>.
+            By default, the Yocto Project provides only one type of pre-built
+            image that contains the <filename>tcf-agent</filename>.
             And, those images are SDK (e.g.<filename>core-image-sato-sdk</filename>).
         </para>
 
@@ -466,13 +484,16 @@
                             the following commands:
                             <literallayout class='monospaced'>
      $ git clone http://git.eclipse.org/gitroot/tcf/org.eclipse.tcf.agent.git
-     $ cd agent
+     $ cd org.eclipse.tcf.agent/agent
                             </literallayout></para></listitem>
-                        <listitem><para>Modify the <filename>Makefile.inc</filename> file
+                        <listitem><para>Locate the
+                            <filename>Makefile.inc</filename> file inside the
+                            <filename>agent</filename> folder and modify it
                             for the cross-compilation environment by setting the
                             <filename>OPSYS</filename> and
                             <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink>
-                            variables according to your target.</para></listitem>
+                            variables according to your target.
+                            </para></listitem>
                         <listitem><para>Use the cross-development tools to build the
                             <filename>tcf-agent</filename>.
                             Before you "Make" the file, be sure your cross-tools are set up first.
@@ -492,32 +513,63 @@
         <title>Extracting the Root Filesystem</title>
 
         <para>
-            You must extract the root filesystem if you want to boot the image using NFS
-            or you want to use the root filesystem as the target sysroot.
-            For example, the Eclipse IDE environment with the Eclipse Yocto Plug-in installed allows you
-            to use QEMU to boot under NFS.
-            Another example is if you want to develop your target application using the
-            root filesystem as the target sysroot.
+            If you install your toolchain by hand or build it using BitBake and
+            you need a root filesystem, you need to extract it separately.
+            If you use the ADT Installer to install the ADT, the root
+            filesystem is automatically extracted and installed.
+        </para>
+
+        <para>
+            Here are some cases where you need to extract the root filesystem:
+            <itemizedlist>
+                <listitem><para>You want to boot the image using NFS.
+                    </para></listitem>
+                <listitem><para>You want to use the root filesystem as the
+                    target sysroot.
+                    For example, the Eclipse IDE environment with the Eclipse
+                    Yocto Plug-in installed allows you to use QEMU to boot
+                    under NFS.</para></listitem>
+                <listitem><para>You want to develop your target application
+                    using the root filesystem as the target sysroot.
+                    </para></listitem>
+            </itemizedlist>
         </para>
 
         <para>
             To extract the root filesystem, first <filename>source</filename>
-            the cross-development environment setup script and then
-            use the <filename>runqemu-extract-sdk</filename> command on the
+            the cross-development environment setup script.
+            If you built the toolchain in the Build Directory, you will find
+            the toolchain environment script in the
+            <filename>tmp</filename> directory.
+            If you installed the toolchain by hand, the environment setup
+            script is located in <filename>/opt/poky/&DISTRO;</filename>.
+        </para>
+
+        <para>
+            After sourcing the environment script, use the
+            <filename>runqemu-extract-sdk</filename> command and provide the
             filesystem image.
-            For example, the following commands set up the environment and then extract
-            the root filesystem from a previously built filesystem image tarball named
-            <filename>core-image-sato-sdk-qemux86-2011091411831.rootfs.tar.bz2</filename>.
-            The example extracts the root filesystem into the <filename>$HOME/qemux86-sato</filename>
-            directory:
+        </para>
+
+        <para>
+            Following is an example.
+            The second command sets up the environment.
+            In this case, the setup script is located in the
+            <filename>/opt/poky/&DISTRO;</filename> directory.
+            The third command extracts the root filesystem from a previously
+            built filesystem that is located in the
+            <filename>~/Downloads</filename> directory.
+            Furthermore, this command extracts the root filesystem into the
+            <filename>qemux86-sato</filename> directory:
             <literallayout class='monospaced'>
-     $ source $HOME/toolchain_dir/environment-setup-i586-poky-linux
+     $ cd ~
+     $ source /opt/poky/&DISTRO;/environment-setup-i586-poky-linux
      $ runqemu-extract-sdk \
-        ~Downloads/core-image-sato-sdk-qemux86-2011091411831.rootfs.tar.bz2 \
+        ~/Downloads/core-image-sato-sdk-qemux86-2011091411831.rootfs.tar.bz2 \
         $HOME/qemux86-sato
             </literallayout>
-            In this case, you could now point to the target sysroot at
-            <filename>$HOME/qemux86-sato</filename>.
+            You could now point to the target sysroot at
+            <filename>qemux86-sato</filename>.
         </para>
     </section>
 </section>
@@ -527,31 +579,27 @@
 
     <para>
         As an alternative to locating and downloading a toolchain installer,
-        you can build the toolchain installer if you have a
-        <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+        you can build the toolchain installer one of two ways if you have a
+        <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>:
+        <itemizedlist>
+            <listitem><para>Use <filename>bitbake meta-toolchain</filename>.
+                This method requires you to still install the target
+                sysroot by installing and extracting it separately.
+                For information on how to install the sysroot, see the
+                "<link linkend='extracting-the-root-filesystem'>Extracting the Root Filesystem</link>"
+                section.</para></listitem>
+            <listitem><para>Use
+                <filename>bitbake image -c populate_sdk</filename>.
+                This method has significant advantages over the previous method
+                because it results in a toolchain installer that contains the
+                sysroot that matches your target root filesystem.
+                </para></listitem>
+        </itemizedlist>
     </para>
 
     <para>
-        You can build the toolchain
-        installer using <filename>bitbake meta-toolchain</filename>.
-        This method requires you to still install the target
-        sysroot by installing and extracting it separately.
-        For information on how to install the sysroot, see the
-        "<link linkend='extracting-the-root-filesystem'>Extracting the Root Filesystem</link>" section.
-    </para>
-
-    <para>
-        A final method of building the toolchain installer exists that has
-        significant advantages over the previous two methods.
-        This method results in a toolchain installer that contains the sysroot
-        that matches your target root filesystem.
-        To build this installer, use the
-        <filename>bitbake image -c populate_sdk</filename> command.
-    </para>
-
-    <para>
-         Remember, before using any <filename>bitbake</filename> command, you
-         must source the build environment setup script 
+         Remember, before using any BitBake command, you
+         must source the build environment setup script
          (i.e.
          <ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>
          or
@@ -566,12 +614,27 @@
          variable is correctly set if you are building a toolchain designed to
          run on an architecture that differs from your current development host
          machine (i.e. the build machine).
-     </para>
+    </para>
 
-     <para>
-         When the BitBake command completes, the toolchain installer will be in
-         <filename>tmp/deploy/sdk</filename> in the Build Directory.
-     </para>
+    <para>
+        When the BitBake command completes, the toolchain installer will be in
+        <filename>tmp/deploy/sdk</filename> in the Build Directory.
+        <note>
+            By default, this toolchain does not build static binaries.
+            If you want to use the toolchain to build these types of libraries,
+            you need to be sure your image has the appropriate static
+            development libraries.
+            Use the
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-IMAGE_INSTALL'><filename>IMAGE_INSTALL</filename></ulink>
+            variable inside your <filename>local.conf</filename> file to
+            install the appropriate library packages.
+            Following is an example using <filename>eglibc</filename> static
+            development libraries:
+            <literallayout class='monospaced'>
+     IMAGE_INSTALL_append = " eglibc-staticdev"
+            </literallayout>
+        </note>
+    </para>
 </section>
 
 </chapter>

documentation/bsp-guide/bsp-guide.xml

@@ -75,9 +75,29 @@
             </revision>
             <revision>
                 <revnumber>1.5</revnumber>
-                <date>Sometime in 2013</date>
+                <date>October 2013</date>
                 <revremark>Released with the Yocto Project 1.5 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>1.5.1</revnumber>
+                <date>January 2014</date>
+                <revremark>Released with the Yocto Project 1.5.1 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.5.2</revnumber>
+                <date>May 2014</date>
+                <revremark>Released with the Yocto Project 1.5.2 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.5.3</revnumber>
+                <date>July 2014</date>
+                <revremark>Released with the Yocto Project 1.5.3 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.5.4</revnumber>
+                <date>December 2014</date>
+                <revremark>Released with the Yocto Project 1.5.4 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>
@@ -91,11 +111,10 @@
         the terms of the <ulink type="http" url="http://creativecommons.org/licenses/by-nc-sa/2.0/uk/">Creative Commons Attribution-Non-Commercial-Share Alike 2.0 UK: England &amp; Wales</ulink> as published by Creative Commons.
       </para>
       <note>
-          Due to production processes, there could be differences between the Yocto Project
-          documentation bundled in the release tarball and the
-          <ulink url='&YOCTO_DOCS_BSP_URL;'>Yocto Project Board Support Package (BSP) Developer's Guide</ulink> on
-          the <ulink url='&YOCTO_HOME_URL;'>Yocto Project</ulink> website.
-          For the latest version of this manual, see the manual on the website.
+          For the latest version of this manual associated with this
+          Yocto Project release, see the
+          <ulink url='&YOCTO_DOCS_BSP_URL;'>Yocto Project Board Support Package (BSP) Developer's Guide</ulink>
+          from the Yocto Project website.
       </note>
     </legalnotice>
 

documentation/bsp-guide/bsp.xml

@@ -183,17 +183,15 @@
      meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config/
      meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay/
      meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay/xorg.conf
-     meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay-noemgd/
-     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_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_3.10.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
+     meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.10.bbappend
                 </literallayout>
             </para>
 
@@ -376,15 +374,6 @@
             <para>
                 Each BSP Layer requires at least one machine file.
                 However, you can supply more than one file.
-                For example, in the Crown Bay BSP shown earlier in this section, the
-                <filename>conf/machine</filename> directory contains two configuration files:
-                <filename>crownbay.conf</filename> and <filename>crownbay-noemgd.conf</filename>.
-                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</filename> file is used for the
-                Crown Bay BSP that supports Video Electronics Standards Association (VESA)
-                graphics only.
             </para>
 
             <para>
@@ -405,12 +394,13 @@
 
             <para>
                 To use an include file, you simply include them in the machine configuration file.
-                For example, the Crown Bay BSP <filename>crownbay.conf</filename> has the
+                For example, the Crown Bay BSP <filename>crownbay.conf</filename> contains the
                 following statements:
                 <literallayout class='monospaced'>
      require conf/machine/include/tune-atom.inc
      require conf/machine/include/ia32-base.inc
      require conf/machine/include/meta-intel.inc
+     require conf/machine/include/meta-intel-emgd.inc
                 </literallayout>
             </para>
             </section>
@@ -428,15 +418,13 @@
                 This optional directory contains miscellaneous recipe files for the BSP.
                 Most notably would be the formfactor files.
                 For example, in the Crown Bay BSP there is the
-                <filename>formfactor_0.0.bbappend</filename> file, which is an append file used
-                to augment the recipe that starts the build.
-                Furthermore, there are machine-specific settings used during the build that are
-                defined by the <filename>machconfig</filename> files.
-                In the Crown Bay example, two <filename>machconfig</filename> files exist:
-                one that supports the
-                <trademark class='registered'>Intel</trademark> Embedded
-                Media and Graphics Driver (<trademark class='registered'>Intel</trademark>
-                EMGD) and one that does not:
+                <filename>formfactor_0.0.bbappend</filename> file, which is an
+                append file used to augment the recipe that starts the build.
+                Furthermore, there are machine-specific settings used during the
+                build that are defined by the <filename>machconfig</filename> file.
+                In the Crown Bay example, two <filename>machconfig</filename> files
+                exist: one that supports the Intel® Embedded Media and Graphics
+                Driver (Intel® EMGD) and one that does not:
                 <literallayout class='monospaced'>
      meta-crownbay/recipes-bsp/formfactor/formfactor/crownbay/machconfig
      meta-crownbay/recipes-bsp/formfactor/formfactor/crownbay-noemgd/machconfig
@@ -467,16 +455,13 @@
                 This optional directory contains recipes for the BSP if it has
                 special requirements for graphics support.
                 All files that are needed for the BSP to support a display are kept here.
-                For example, the Crown Bay BSP contains two versions of the
-                <filename>xorg.conf</filename> file.
-                The version in <filename>crownbay</filename> builds a BSP that supports the
-                <trademark class='registered'>Intel</trademark> Embedded Media Graphics Driver (EMGD),
-                while the version in <filename>crownbay-noemgd</filename> builds
-                a BSP that supports Video Electronics Standards Association (VESA) graphics only:
+                For example, the Crown Bay BSP's <filename>xorg.conf</filename> file
+                detects the graphics support needed (i.e. the Intel® Embedded Media
+                Graphics Driver (EMGD) or the Video Electronics Standards Association
+                (VESA) graphics):
                 <literallayout class='monospaced'>
      meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
      meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay/xorg.conf
-     meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay-noemgd/xorg.conf
                 </literallayout>
             </para>
             </section>
@@ -502,28 +487,28 @@
                 the <filename>meta-&lt;bsp_name&gt;/recipes-kernel/linux</filename> directory).
             </para>
             <para>
-                Suppose you are using the <filename>linux-yocto_3.8.bb</filename> recipe to build
+                Suppose you are using the <filename>linux-yocto_3.10.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.8%"
+     PREFERRED_VERSION_linux-yocto ?= "3.10%"
                 </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.8.bbappend</filename> file to append
+                You would use the <filename>linux-yocto_3.10.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.8.bbappend
+     meta-crownbay/recipes-kernel/linux/linux-yocto_3.10.bbappend
                 </literallayout>
                 The following listing shows the file.
                 Be aware that the actual commit ID strings in this example listing might be different
@@ -532,46 +517,18 @@
                 <literallayout class='monospaced'>
      FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
 
-     COMPATIBLE_MACHINE_crownbay = "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"
-     KERNEL_FEATURES_crownbay-noemgd_append = " cfg/vesafb"
+     KERNEL_FEATURES_append_crownbay-noemgd = " cfg/vesafb"
 
-     LINUX_VERSION = "3.8.4"
+     LINUX_VERSION = "3.10.11"
 
-     SRCREV_meta_crownbay = "2a6d36e75ca0a121570a389d7bab76ec240cbfda"
-     SRCREV_machine_crownbay = "47aed0c17c1c55988198ad39f86ae88894c8e0a4"
-     SRCREV_emgd_crownbay = "c780732f175ff0ec866fac2130175876b519b576"
-
-     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"
+     SRCREV_meta_crownbay-noemgd = "285f93bf942e8f6fa678ffc6cc53696ed5400718"
+     SRCREV_machine_crownbay-noemgd = "702040ac7c7ec66a29b4d147665ccdd0ff015577"
                 </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.8.bbappend</filename>
-                file are follows:
-                <literallayout class='monospaced'>
-     FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
-
-     COMPATIBLE_MACHINE_crownbay = "crownbay"
-     KMACHINE_crownbay = "crownbay"
-     KBRANCH_crownbay = "standard/crownbay"
-     KERNEL_FEATURES_crownbay_append = " features/drm-emgd/drm-emgd-1.16 cfg/vesafb"
-
-     SRCREV_meta_crownbay = "2a6d36e75ca0a121570a389d7bab76ec240cbfda"
-     SRCREV_machine_crownbay = "47aed0c17c1c55988198ad39f86ae88894c8e0a4"
-     SRCREV_emgd_crownbay = "c780732f175ff0ec866fac2130175876b519b576"
-                </literallayout>
-                The append file defines <filename>crownbay</filename> as the
+                This append file contains statements used to support the Crown Bay BSP.
+                The file defines <filename>crownbay</filename> as the
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-COMPATIBLE_MACHINE'><filename>COMPATIBLE_MACHINE</filename></ulink>
                 and uses the
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-KMACHINE'><filename>KMACHINE</filename></ulink> variable to
@@ -588,12 +545,6 @@
                 <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink> Git
                 repository and the <filename>meta</filename> Git repository branches to identify the
                 exact kernel needed to build the Crown Bay BSP.
-                <note>
-                    For <filename>crownbay</filename>, a specific commit is also needed to point
-                    to the branch that supports EMGD graphics.
-                    At a minimum, every BSP points to the
-                    <filename>machine</filename> and <filename>meta</filename> commits.
-                </note>
             </para>
 
             <para>
@@ -611,7 +562,7 @@
             <para>
                 For example, suppose you had some configuration options in a file called
                 <filename>network_configs.cfg</filename>.
-                You can place that file inside a directory named <filename>/linux-yocto</filename> and then add
+                You can place that file inside a directory named <filename>linux-yocto</filename> and then add
                 a <filename>SRC_URI</filename> statement such as the following to the append file.
                 When the OpenEmbedded build system builds the kernel, the configuration options are
                 picked up and applied.
@@ -797,7 +748,7 @@
                                 <listitem><para>Instructions on how to boot the BSP build from
                                     the BSP layer.</para></listitem>
                                 <listitem><para>Instructions on how to boot the binary images
-                                    contained in the <filename>/binary</filename> directory,
+                                    contained in the <filename>binary</filename> directory,
                                     if present.</para></listitem>
                                 <listitem><para>Information on any known bugs or issues that users
                                     should know about when either building or booting the BSP
@@ -808,7 +759,7 @@
                             <filename>meta-&lt;bsp_name&gt;</filename> directory.
                             This file specifies exactly where you can find the sources used to
                             generate the binary images contained in the
-                            <filename>/binary</filename> directory, if present.
+                            <filename>binary</filename> directory, if present.
                             See the
                             <ulink url='&YOCTO_GIT_URL;/cgit.cgi/meta-intel/tree/meta-fri2/README.sources'><filename>README.sources</filename></ulink>
                             file for the Fish River Island 2 BSP in the <filename>meta-fri2</filename> BSP layer
@@ -1281,31 +1232,35 @@
                     Following is the complete example:
                     <literallayout class='monospaced'>
      $ yocto-bsp create myarm qemu
+     Checking basic git connectivity...
+     Done.
+
      Which qemu architecture would you like to use? [default: i386]
-	     1) i386    (32-bit)
+     	     1) i386    (32-bit)
 	     2) x86_64  (64-bit)
 	     3) ARM     (32-bit)
 	     4) PowerPC (32-bit)
 	     5) MIPS    (32-bit)
      3
-     Would you like to use the default (3.8) kernel? (y/n) [default: y]
+     Would you like to use the default (3.10) kernel? (y/n) [default: y] 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.8.git...
+     Getting branches from remote repo git://git.yoctoproject.org/linux-yocto-3.10.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/ck
-             5) standard/crownbay
-             6) standard/edf
-             7) standard/emenlow
-             8) standard/fri2
-             9) standard/fsl-mpc8315e-rdb
-             10) standard/mti-malta32
-             11) standard/mti-malta64
-             12) standard/qemuppc
-             13) standard/routerstationpro
-             14) standard/sys940x
+	     1) standard/arm-versatile-926ejs
+	     2) standard/base
+	     3) standard/beagleboard
+	     4) standard/ck
+	     5) standard/crownbay
+	     6) standard/edf
+	     7) standard/emenlow
+	     8) standard/fri2
+	     9) standard/fsl-mpc8315e-rdb
+	     10) standard/minnow
+	     11) standard/mti-malta32
+	     12) standard/mti-malta64
+	     13) standard/qemuppc
+	     14) standard/routerstationpro
+	     15) standard/sys940x
      1
      Would you like SMP support? (y/n) [default: y]
      Does your BSP have a touchscreen? (y/n) [default: n]
@@ -1320,7 +1275,7 @@
                             In the example, we use the ARM architecture.
                             </para></listitem>
                         <listitem><para>The script then prompts you for the kernel.
-                            The default 3.8 kernel is acceptable.
+                            The default 3.10 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.2, 3.2_preempt-rt, and so forth.).</para></listitem>

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

@@ -24,17 +24,6 @@
             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.
-                However, you can create your own distribution by providing key
-                <link linkend='metadata'>Metadata</link>.
-                A good example is Angstrom, which has had a distribution
-                based on the Yocto Project since its inception.
-                Other examples include  commercial distributions like
-                Wind River Linux, Mentor Embedded Linux, and ENEA Linux.
-                See the "<link linkend='creating-your-own-distribution'>Creating Your Own Distribution</link>"
-                section for more information.
-            </note>
         </para>
 
         <para>
@@ -43,13 +32,25 @@
             reconfigure the kernel, and develop an application using the
             popular <trademark class='trade'>Eclipse</trademark> IDE.
         </para>
+
+        <note>
+            By default, using the Yocto Project creates a Poky distribution.
+            However, you can create your own distribution by providing key
+            <link linkend='metadata'>Metadata</link>.
+            A good example is Angstrom, which has had a distribution
+            based on the Yocto Project since its inception.
+            Other examples include  commercial distributions like
+            Wind River Linux, Mentor Embedded Linux, and ENEA Linux.
+            See the "<link linkend='creating-your-own-distribution'>Creating Your Own Distribution</link>"
+            section for more information.
+        </note>
     </section>
 
     <section id='what-this-manual-provides'>
         <title>What This Manual Provides</title>
 
         <para>
-            The following list describes what you can get from this guide:
+            The following list describes what you can get from this manual:
             <itemizedlist>
                 <listitem><para>Information that lets you get set
                     up to develop using the Yocto Project.</para></listitem>
@@ -75,17 +76,17 @@
         <para>
             This manual will not give you the following:
             <itemizedlist>
-                <listitem><para>Step-by-step instructions if those instructions exist in other Yocto
-                    Project documentation.
+                <listitem><para><emphasis>Step-by-step instructions when those instructions exist in other Yocto
+                    Project documentation:</emphasis>
                     For example, the Yocto Project Application Developer's Guide contains detailed
                     instructions on how to run the
-                    <ulink url='&YOCTO_DOCS_ADT_URL;#installing-the-adt'>Installing the ADT and Toolchains</ulink>,
+                    <ulink url='&YOCTO_DOCS_ADT_URL;#installing-the-adt'>ADT Installer</ulink>,
                     which is used to set up a cross-development environment.</para></listitem>
-                <listitem><para>Reference material.
+                <listitem><para><emphasis>Reference material:</emphasis>
                     This type of material resides in an appropriate reference manual.
                     For example, system variables are documented in the
                     <ulink url='&YOCTO_DOCS_REF_URL;'>Yocto Project Reference Manual</ulink>.</para></listitem>
-                <listitem><para>Detailed public information that is not specific to the Yocto Project.
+                <listitem><para><emphasis>Detailed public information that is not specific to the Yocto Project:</emphasis>
                     For example, exhaustive information on how to use Git is covered better through the
                     Internet than in this manual.</para></listitem>
             </itemizedlist>
@@ -109,7 +110,8 @@
                     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."
+                    guide to the OpenEmbedded build system, which is based on BitBake.
+                    The build system is sometimes referred to as "Poky".
                     </para></listitem>
                 <listitem><para><emphasis>
                     <ulink url='&YOCTO_DOCS_ADT_URL;'>Yocto Project Application Developer's Guide</ulink>:</emphasis>

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

@@ -254,9 +254,9 @@
                 <listitem><para><ulink url='http://sitaramc.github.com/gitolite/master-toc.html'>The <filename>gitolite</filename> master index</ulink>:
                     All topics for <filename>gitolite</filename>.
                     </para></listitem>
-                <listitem><para><ulink url='http://hjemli.net/git/cgit/tree/README'><filename>cgit</filename> index</ulink>:
-                    A <filename>README</filename> file on how to create a
-                    fast web interface for Git.</para></listitem>
+                <listitem><para><ulink url='https://git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools'>Interfaces, frontends, and tools</ulink>:
+                    Documentation on how to create interfaces and frontends
+                    for Git.</para></listitem>
             </itemizedlist>
         </note>
     </section>
@@ -275,9 +275,8 @@
         </para>
 
         <para>
-            See "<ulink url='http://autobuilder.yoctoproject.org:8010/'>Welcome to the buildbot for the Yocto Project</ulink>"
-            for the Yocto Project's reference implementation that uses
-            buildbot.
+            See "<ulink url='http://autobuilder.yoctoproject.org'>Yocto Project Autobuilder</ulink>"
+            for more information and links to buildbot.
             The Yocto Project team has found this implementation
             works well in this role.
             A public example of this is the Yocto Project
@@ -394,7 +393,7 @@
                     For some guidance on mailing lists to use, see the list in the
                     "<link linkend='how-to-submit-a-change'>How to Submit a Change</link>"
                     section.
-                    For a description of the available mailing lists, see
+                    For a description of the available mailing lists, see the
                     "<ulink url='&YOCTO_DOCS_REF_URL;#resources-mailinglist'>Mailing Lists</ulink>"
                     section in the Yocto Project Reference Manual.
                     </para></listitem>
@@ -430,15 +429,17 @@
     <para>
         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
-        using the Yocto Project.
-    </para>
-
-    <para>
-        Once you are set up through either tarball extraction or a checkout of Git repositories,
-        you are ready to develop.
+        select the "Downloads" tab and get a released tarball of the
+        <filename>poky</filename> repository or any supported BSP tarballs.
+        Unpacking these tarballs gives you a snapshot of the released
+        files.
+        <note>
+            The recommended method for setting up the Yocto Project
+            <link linkend='source-directory'>Source Directory</link> and the
+            files for supported BSPs (e.g., <filename>meta-intel</filename>) is to
+            use <link linkend='git'>Git</link> to create a local copy of the
+            upstream repositories.
+        </note>
     </para>
 
     <para>
@@ -515,27 +516,40 @@
                 The <ulink url='&YOCTO_DOCS_REF_URL;#var-TOPDIR'><filename>TOPDIR</filename></ulink>
                 variable points to the Build Directory.</para>
 
-                <para>You have a lot of flexibility when creating the Build Directory.
-                Following are some examples that show how to create the directory:
+                <para>
+                    You have a lot of flexibility when creating the Build
+                    Directory.
+                    Following are some examples that show how to create the
+                    directory.
+                    The examples assume your
+                    <link linkend='source-directory'>Source Directory</link> is
+                    named <filename>poky</filename>:
                    <itemizedlist>
-                        <listitem><para>Create the Build Directory in your current working directory
-                            and name it <filename>build</filename>.
-                            This is the default behavior.
+                        <listitem><para>Create the Build Directory inside your
+                            Source Directory and let the name of the Build
+                            Directory default to <filename>build</filename>:
                             <literallayout class='monospaced'>
-     $ source &OE_INIT_PATH;
+     $ cd $HOME/poky
+     $ source &OE_INIT_FILE;
                             </literallayout></para></listitem>
-                        <listitem><para>Provide a directory path and specifically name the build
-                            directory.
-                            This next example creates a Build Directory named <filename>YP-&POKYVERSION;</filename>
-                            in your home directory within the directory <filename>mybuilds</filename>.
-                            If <filename>mybuilds</filename> does not exist, the directory is created for you:
+                        <listitem><para>Create the Build Directory inside your
+                            home directory and specifically name it
+                            <filename>test-builds</filename>:
                             <literallayout class='monospaced'>
-     $ source &OE_INIT_PATH; $HOME/mybuilds/YP-&POKYVERSION;
+     $ cd $HOME
+     $ source poky/&OE_INIT_FILE; test-builds
                             </literallayout></para></listitem>
-                        <listitem><para>Provide an existing directory to use as the Build Directory
-                            and use the default <filename>build</filename> name.
+                        <listitem><para>Provide a directory path and
+                            specifically name the build directory.
+                            Any intermediate folders in the pathname must
+                            exist.
+                            This next example creates a Build Directory named
+                            <filename>YP-&POKYVERSION;</filename>
+                            in your home directory within the existing
+                            directory <filename>mybuilds</filename>:
                             <literallayout class='monospaced'>
-     $ source &OE_INIT_PATH; $HOME/mybuilds/
+     $cd $HOME
+     $ source $HOME/poky/&OE_INIT_FILE; $HOME/mybuilds/YP-&POKYVERSION;
                             </literallayout></para></listitem>
                     </itemizedlist>
                 </para></listitem>
@@ -615,7 +629,7 @@
                 "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-layers'>BSP Layers</ulink>"
                 section in the Yocto Project Board Support Packages (BSP)
                 Developer's Guide.</para></listitem>
-            <listitem><para id='meta-toochain'><emphasis>Meta-Toolchain:</emphasis>
+            <listitem><para id='meta-toolchain'><emphasis>Meta-Toolchain:</emphasis>
                 A term sometimes used for
                 <link linkend='cross-development-toolchain'>Cross-Development Toolchain</link>.
                 </para></listitem>
@@ -648,6 +662,17 @@
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-PV'><filename>PV</filename></ulink>, and
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-PE'><filename>PE</filename></ulink>).
                 </para></listitem>
+            <listitem><para><emphasis>Package Groups:</emphasis>
+                Arbitrary groups of software Recipes.
+                You use package groups to hold recipes that, when built,
+                usually accomplish a single task.
+                For example, a package group could contain the recipes for a
+                company’s proprietary or value-add software.
+                Or, the package group could contain the recipes that enable
+                graphics.
+                A package group is really just another recipe.
+                Because package group files are recipes, they end with the
+                <filename>.bb</filename> filename extension.</para></listitem>
             <listitem><para id='poky'><emphasis>Poky:</emphasis> The term "poky" can mean several things.
                 In its most general sense, it is an open-source project that was initially developed
                 by OpenedHand.  With OpenedHand, poky was developed off of the existing OpenEmbedded
@@ -689,7 +714,7 @@
                 For example, downloading and unpacking <filename>&YOCTO_POKY_TARBALL;</filename>
                 results in a Source Directory whose top-level folder is named
                 <filename>&YOCTO_POKY;</filename>.
-                If you create a local copy of the Git repository, then you can name the repository
+                If you create a local copy of the Git repository, you can name the repository
                 anything you like.
                 Throughout much of the documentation, <filename>poky</filename> is used as the name of
                 the top-level folder of the local copy of the poky Git repository.
@@ -717,13 +742,12 @@
                 see the
                 "<link linkend='repositories-tags-and-branches'>Repositories, Tags, and Branches</link>"
                 section.</para></listitem>
-            <listitem><para><emphasis>Tasks:</emphasis> Arbitrary groups of software Recipes.
-                You use tasks to hold recipes that, when built, usually accomplish a single task.
-                For example, a task could contain the recipes for a company’s proprietary or value-add software.
-                Or, the task could contain the recipes that enable graphics.
-                A task is really just another recipe.
-                Because task files are recipes, they end with the <filename>.bb</filename> filename
-                extension.</para></listitem>
+            <listitem><para><emphasis>Task:</emphasis>
+                A unit of execution for BitBake (e.g.
+                <filename>do_compile</filename>,
+                <filename>do_fetch</filename>, <filename>do_patch</filename>,
+                and so forth).
+                </para></listitem>
             <listitem><para><emphasis>Upstream:</emphasis> A reference to source code or repositories
                 that are not local to the development system but located in a master area that is controlled
                 by the maintainer of the source code.
@@ -808,7 +832,8 @@
     <title>Git</title>
 
     <para>
-        The Yocto Project uses Git, which is a free, open source distributed version control system.
+        The Yocto Project makes extensive use of Git,
+        which is a free, open source distributed version control system.
         Git supports distributed development, non-linear development, and can handle large projects.
         It is best that you have some fundamental understanding of how Git tracks projects and
         how to work with Git if you are going to use the Yocto Project for development.
@@ -865,8 +890,8 @@
             It is important to understand that Git tracks content change and not files.
             Git uses "branches" to organize different development efforts.
             For example, the <filename>poky</filename> repository has
-            <filename>bernard</filename>,
-            <filename>edison</filename>, <filename>denzil</filename>, <filename>danny</filename>
+            <filename>denzil</filename>, <filename>danny</filename>,
+            <filename>dylan</filename>, <filename>dora</filename>,
             and <filename>master</filename> branches among others.
             You can see all the branches by going to
             <ulink url='&YOCTO_GIT_URL;/cgit.cgi/poky/'></ulink> and
@@ -912,7 +937,7 @@
             local working branch based on a branch name,
             your local environment matches the "tip" of that development branch
             at the time you created your local branch, which could be
-            different than the files at the time of a similarly named release.
+            different from the files at the time of a similarly named release.
             In other words, creating and checking out a local branch based on the
             <filename>&DISTRO_NAME;</filename> branch name is not the same as
             cloning and checking out the <filename>master</filename> branch.
@@ -1005,7 +1030,7 @@
                     will allow the change, and for ultimately pushing the change from your local Git repository
                     into the project’s upstream (or master) repository.</para></listitem>
                 <listitem><para><emphasis><filename>git status</filename>:</emphasis> Reports any modified files that
-                    possibly need staged and committed.</para></listitem>
+                    possibly need to be staged and committed.</para></listitem>
                 <listitem><para><emphasis><filename>git checkout &lt;branch-name&gt;</filename>:</emphasis> Changes
                     your working branch.
                     This command is analogous to "cd".</para></listitem>
@@ -1233,6 +1258,10 @@
                 occurred.</para></listitem>
             <listitem><para>Be sure to indicate the Severity of the bug.
                 Severity communicates how the bug impacted your work.</para></listitem>
+            <listitem><para>Select the appropriate "Documentation change" item
+                for the bug.
+                Fixing a bug may or may not affect the Yocto Project
+                documentation.</para></listitem>
             <listitem><para>Provide a brief summary of the issue.
                 Try to limit your summary to just a line or two and be sure to capture the
                 essence of the issue.</para></listitem>
@@ -1278,10 +1307,9 @@
             <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.
+                In addition, some layers (such as the <filename>meta-intel</filename> layer),
+                include a <filename>MAINTAINERS</filename> file which contains
+                a list of all supported BSP maintainers for that layer.
                 </para></listitem>
             <listitem><para><emphasis>Search by File:</emphasis>
                 Using <link linkend='git'>Git</link>, you can enter the
@@ -1456,8 +1484,8 @@
                     <para>For help on using these scripts, simply provide the
                     <filename>-h</filename> argument as follows:
                     <literallayout class='monospaced'>
-     $ ~/poky/scripts/create-pull-request -h
-     $ ~/poky/scripts/send-pull-request -h
+     $ poky/scripts/create-pull-request -h
+     $ poky/scripts/send-pull-request -h
                     </literallayout></para></listitem>
             </itemizedlist>
         </para>

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

@@ -32,7 +32,7 @@
 
     <para>
         You can use the OpenEmbedded build system, which uses
-        BitBake to develop complete Linux
+        BitBake, to develop complete Linux
         images and associated user-space applications for architectures based
         on ARM, MIPS, PowerPC, x86 and x86-64.
         <note>
@@ -55,12 +55,12 @@
     <title>Getting Set Up</title>
 
     <para>
-        Here is what you need to get set up to use the Yocto Project:
+        Here is what you need to use the Yocto Project:
         <itemizedlist>
-            <listitem><para><emphasis>Host System:</emphasis>  You should have a reasonably current
-                Linux-based host system.
+            <listitem><para><emphasis>Host System:</emphasis>
+                You should have a reasonably current Linux-based host system.
                 You will have the best results with a recent release of Fedora,
-                OpenSUSE, Debian, Ubuntu, or CentOS as these releases are frequently tested against the Yocto Project
+                openSUSE, Debian, Ubuntu, or CentOS as these releases are frequently tested against the Yocto Project
                 and officially supported.
                 For a list of the distributions under validation and their status, see the
                 "<ulink url='&YOCTO_DOCS_REF_URL;#detailed-supported-distros'>Supported Linux Distributions</ulink>" section
@@ -69,23 +69,35 @@
                 <para>
                 You should also have about 100 gigabytes of free disk space for building images.
                 </para></listitem>
-            <listitem><para><emphasis>Packages:</emphasis>  The OpenEmbedded build system
-                requires certain packages exist on your development system (e.g. Python 2.6 or 2.7).
+            <listitem><para><emphasis>Packages:</emphasis>
+                The OpenEmbedded build system requires that certain packages
+                exist on your development system (e.g. Python 2.6 or 2.7).
                 See "<ulink url='&YOCTO_DOCS_QS_URL;#packages'>The Packages</ulink>"
                 section in the Yocto Project Quick Start and the
                 "<ulink url='&YOCTO_DOCS_REF_URL;#required-packages-for-the-host-development-system'>Required Packages for the Host Development System</ulink>"
                 section in the Yocto Project Reference Manual for the exact
                 package requirements and the installation commands to install
-                them for the supported distributions.
-                </para></listitem>
+                them for the supported distributions.</para></listitem>
             <listitem id='local-yp-release'><para><emphasis>Yocto Project Release:</emphasis>
-                You need a release of the Yocto Project.
-                You set that up with a local <link linkend='source-directory'>Source Directory</link>
-                one of two ways depending on whether you
-                are going to contribute back into the Yocto Project or not.
-                <note>
-                    Regardless of the method you use, this manual refers to the resulting local
-                    hierarchical set of files as the "Source Directory."
+                You need a release of the Yocto Project installed locally on
+                your development system.
+                This local area is referred to as the
+                <link linkend='source-directory'>Source Directory</link>
+                and is created when you use
+                <link linkend='git'>Git</link> to clone a local copy
+                of the upstream <filename>poky</filename> repository,
+                or when you download an official release of the corresponding
+                tarball.</para>
+                <para>Working from a copy of the upstream repository allows you
+                to contribute back into the Yocto Project or simply work with
+                the latest software on a development branch.
+                Because Git maintains and creates an upstream repository with
+                a complete history of changes and you are working with a local
+                clone of that repository, you have access to all the Yocto
+                Project development branches and tag names used in the upstream
+                repository.
+                <note>You can view the Yocto Project Source Repositories at
+                    <ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink>
                 </note>
                 <itemizedlist>
                     <listitem><para><emphasis>Tarball Extraction:</emphasis>
@@ -97,46 +109,62 @@
                         directory of your choice.</para>
                         <para>For example, the following command extracts the
                         Yocto Project &DISTRO; release tarball
-                        into the current working directory and sets up the local Source Directory
-                        with a top-level folder named <filename>&YOCTO_POKY;</filename>:
+                        into the current working directory and sets up the local
+                        Source Directory
+                        with a top-level folder named
+                        <filename>&YOCTO_POKY;</filename>:
                         <literallayout class='monospaced'>
      $ tar xfj &YOCTO_POKY_TARBALL;
                         </literallayout></para>
-                        <para>This method does not produce a local Git repository.
-                        Instead, you simply end up with a snapshot of the release.</para></listitem>
-                    <listitem><para><emphasis>Git Repository Method:</emphasis>  If you are going to be contributing
-                        back into the Yocto Project or you simply want to keep up
-                        with the latest developments, you should use Git commands to set up a local
-                        Git repository of the upstream <filename>poky</filename> source repository.
-                        Doing so creates a repository with a complete history of changes and allows
-                        you to easily submit your changes upstream to the project.
-                        Because you clone the repository, you have access to all the Yocto Project development
-                        branches and tag names used in the upstream repository.</para>
-                        <note>You can view the Yocto Project Source Repositories at
-                        <ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink></note>
-                        <para>The following transcript shows how to clone the <filename>poky</filename>
-                        Git repository into the current working directory.
-                        The command creates the local repository in a directory named <filename>poky</filename>.
-                        For information on Git used within the Yocto Project, see the
+                        <para>This method does not produce a local Git
+                        repository.
+                        Instead, you simply end up with a snapshot of the
+                        release.</para></listitem>
+                    <listitem><para><emphasis>Git Repository Method:</emphasis>
+                        If you are going to be contributing back into the Yocto
+                        Project or you simply want to keep up with the latest
+                        developments, you should use Git commands to set up a
+                        local Git repository of the upstream
+                        <filename>poky</filename> source repository.
+                        Doing so creates a repository with a complete history
+                        of changes and allows you to easily submit your changes
+                        upstream to the project.
+                        Because you clone the repository, you have access to all
+                        the Yocto Project development branches and tag names
+                        used in the upstream repository.
+                        <note>You can view the Yocto Project Source Repositories
+                            at
+                            <ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink>
+                        </note></para>
+                        <para>The following transcript shows how to clone the
+                        <filename>poky</filename> Git repository into the
+                        current working directory.
+                        The command creates the local repository in a directory
+                        named <filename>poky</filename>.
+                        For information on Git used within the Yocto Project,
+                        see the
                         "<link linkend='git'>Git</link>" section.
                         <literallayout class='monospaced'>
      $ git clone git://git.yoctoproject.org/poky
      Cloning into 'poky'...
-     remote: Counting objects: 183981, done.
-     remote: Compressing objects: 100% (47428/47428), done.
-     remote: Total 183981 (delta 132271), reused 183703 (delta 132044)
-     Receiving objects: 100% (183981/183981), 89.71 MiB | 2.93 MiB/s, done.
-     Resolving deltas: 100% (132271/132271), done.
-                        </literallayout></para>
-                        <para>For another example of how to set up your own local Git repositories, see this
-                        <ulink url='&YOCTO_WIKI_URL;/wiki/Transcript:_from_git_checkout_to_meta-intel_BSP'>
-                        wiki page</ulink>, which describes how to create both <filename>poky</filename>
-                        and <filename>meta-intel</filename> Git repositories.</para></listitem>
+     remote: Counting objects: 203728, done.
+     remote: Compressing objects: 100% (52371/52371), done.
+     remote: Total 203728 (delta 147444), reused 202891 (delta 146614)
+     Receiving objects: 100% (203728/203728), 95.54 MiB | 308 KiB/s, done.
+     Resolving deltas: 100% (147444/147444), done.
+                        </literallayout>
+                        For another example of how to set up your own local
+                        Git repositories, see this
+                        <ulink url='&YOCTO_WIKI_URL;/wiki/Transcript:_from_git_checkout_to_meta-intel_BSP'>wiki page</ulink>,
+                        which describes how to create both
+                        <filename>poky</filename> and
+                        <filename>meta-intel</filename> Git repositories.
+                        </para></listitem>
                 </itemizedlist></para></listitem>
             <listitem id='local-kernel-files'><para><emphasis>Yocto Project Kernel:</emphasis>
                 If you are going to be making modifications to a supported Yocto Project kernel, you
                 need to establish local copies of the source.
-                You can find Git repositories of supported Yocto Project Kernels organized under
+                You can find Git repositories of supported Yocto Project kernels organized under
                 "Yocto Linux Kernel" in the Yocto Project Source Repositories at
                 <ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink>.</para>
                 <para>This setup can involve creating a bare clone of the Yocto Project kernel and then
@@ -145,27 +173,28 @@
                 For simplicity, it is recommended that you create these structures outside of the
                 Source Directory (usually <filename>poky</filename>).</para>
                 <para>As an example, the following transcript shows how to create the bare clone
-                of the <filename>linux-yocto-3.8</filename> kernel and then create a copy of
+                of the <filename>linux-yocto-3.10</filename> kernel and then create a copy of
                 that clone.
                 <note>When you have a local Yocto Project kernel Git repository, you can
                 reference that repository rather than the upstream Git repository as
                 part of the <filename>clone</filename> command.
                 Doing so can speed up the process.</note></para>
                 <para>In the following example, the bare clone is named
-                <filename>linux-yocto-3.8.git</filename>, while the
-                copy is named <filename>my-linux-yocto-3.8-work</filename>:
+                <filename>linux-yocto-3.10.git</filename>, while the
+                copy is named <filename>my-linux-yocto-3.10-work</filename>:
                 <literallayout class='monospaced'>
-     $ git clone --bare git://git.yoctoproject.org/linux-yocto-3.8 linux-yocto-3.8.git
-     Cloning into bare repository 'linux-yocto-3.8.git'...
-     remote: Counting objects: 2847090, done.
-     remote: Compressing objects: 100% (454675/454675), done.
-     remote: Total 2847090 (delta 2386170), reused 2825793 (delta 2364886)
-     Receiving objects: 100% (2847090/2847090), 603.19 MiB | 3.54 MiB/s, done.
-     Resolving deltas: 100% (2386170/2386170), done.                </literallayout></para>
+     $ git clone &dash;&dash;bare git://git.yoctoproject.org/linux-yocto-3.10 linux-yocto-3.10.git
+     Cloning into bare repository 'linux-yocto-3.10.git'...
+     remote: Counting objects: 3364487, done.
+     remote: Compressing objects: 100% (507178/507178), done.
+     remote: Total 3364487 (delta 2827715), reused 3364481 (delta 2827709)
+     Receiving objects: 100% (3364487/3364487), 722.95 MiB | 423 KiB/s, done.
+     Resolving deltas: 100% (2827715/2827715), done.
+                </literallayout></para>
                 <para>Now create a clone of the bare clone just created:
                 <literallayout class='monospaced'>
-     $ git clone linux-yocto-3.8.git my-linux-yocto-3.8-work
-     Cloning into 'my-linux-yocto-3.8-work'...
+     $ git clone linux-yocto-3.10.git my-linux-yocto-3.10-work
+     Cloning into 'my-linux-yocto-3.10-work'...
      done.
                 </literallayout></para></listitem>
             <listitem id='meta-yocto-kernel-extras-repo'><para><emphasis>
@@ -189,11 +218,12 @@
      $ cd ~/poky
      $ git clone git://git.yoctoproject.org/meta-yocto-kernel-extras meta-yocto-kernel-extras
      Cloning into 'meta-yocto-kernel-extras'...
-     remote: Counting objects: 690, done.
-     remote: Compressing objects: 100% (431/431), done.
-     remote: Total 690 (delta 238), reused 690 (delta 238)
-     Receiving objects: 100% (690/690), 532.60 KiB, done.
-     Resolving deltas: 100% (238/238), done.                </literallayout></para></listitem>
+     remote: Counting objects: 727, done.
+     remote: Compressing objects: 100% (452/452), done.
+     remote: Total 727 (delta 260), reused 719 (delta 252)
+     Receiving objects: 100% (727/727), 536.36 KiB | 102 KiB/s, done.
+     Resolving deltas: 100% (260/260), done.
+               </literallayout></para></listitem>
            <listitem><para id='supported-board-support-packages-(bsps)'><emphasis>Supported Board
                 Support Packages (BSPs):</emphasis>
                 The Yocto Project provides a layer called <filename>meta-intel</filename> and
@@ -219,43 +249,54 @@
                 </literallayout>
                 See the
                 "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-layers'>BSP Layers</ulink>"
-                section in the Yocto Project Board Support Package (BSP) Developer's Guide for more
-                information on BSP Layers.
+                section in the Yocto Project Board Support Package (BSP)
+                Developer's Guide for more information on BSP Layers.
                 <itemizedlist>
-                    <listitem><para><emphasis>Tarball Extraction:</emphasis>  You can download any released
-                        BSP tarball from the same "Downloads" page of the
-                        <ulink url='&YOCTO_HOME_URL;'>Yocto Project Website</ulink>
+                    <listitem><para><emphasis>Tarball Extraction:</emphasis>
+                        You can download any released BSP tarball from the same
+                        "Downloads" page of the Yocto Project
+                        <ulink url='https://www.yoctoproject.org/downloads'>Website</ulink>
                         to get the Yocto Project release.
-                        Once on the "Download" page, look for "BSP" under the
-                        "Type" heading.</para>
-                        <para>Once you have the tarball, just extract it into a directory of your choice.
-                        Again, this method just produces a snapshot of the BSP layer in the form
-                        of a hierarchical directory structure.</para></listitem>
-                    <listitem><para><emphasis>Git Repository Method:</emphasis>  If you are working
-                        with a local Git repository for your Source Directory, you should also use this method
-                        to set up the <filename>meta-intel</filename> Git repository.
-                        You can locate the <filename>meta-intel</filename> Git repository in the
-                        "Yocto Metadata Layers" area of the Yocto Project Source Repositories at
+                        Once on the "Download" page, look to the right of the
+                        page and scroll down to find the BSP tarballs.</para>
+                        <para>Once you have the tarball, just extract it into a
+                        directory of your choice.
+                        Again, this method just produces a snapshot of the BSP
+                        layer in the form of a hierarchical directory
+                        structure.</para></listitem>
+                    <listitem><para><emphasis>Git Repository Method:</emphasis>
+                        If you are working with a local Git repository for your
+                        Source Directory, you should also use this method to
+                        set up the <filename>meta-intel</filename> Git
+                        repository.
+                        You can locate the <filename>meta-intel</filename> Git
+                        repository in the "Yocto Metadata Layers" area of the
+                        Yocto Project Source Repositories at
                         <ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink>.</para>
-                        <para>Typically, you set up the <filename>meta-intel</filename> Git repository inside
+                        <para>Using
+                        <link linkend='git'>Git</link> to create a local clone
+                        of the upstream repository can be helpful if you are
+                        working with BSPs.
+                        Typically, you set up the
+                        <filename>meta-intel</filename> Git repository inside
                         the Source Directory.
-                        For example, the following transcript shows the steps to clone the
-                        <filename>meta-intel</filename>
-                        Git repository inside the local <filename>poky</filename> Git repository.
+                        For example, the following transcript shows the steps
+                        to clone <filename>meta-intel</filename>.
                         <literallayout class='monospaced'>
      $ cd ~/poky
      $ git clone git://git.yoctoproject.org/meta-intel.git
      Cloning into 'meta-intel'...
-     remote: Counting objects: 6264, done.
-     remote: Compressing objects: 100% (2135/2135), done.
-     remote: Total 6264 (delta 3321), reused 6235 (delta 3293)
-     Receiving objects: 100% (6264/6264), 2.17 MiB | 2.63 MiB/s, done.
-     Resolving deltas: 100% (3321/3321), done.
-                        </literallayout></para>
-                        <para>The same
-                        <ulink url='&YOCTO_WIKI_URL;/wiki/Transcript:_from_git_checkout_to_meta-intel_BSP'>
-                        wiki page</ulink> referenced earlier covers how to
-                        set up the <filename>meta-intel</filename> Git repository.</para></listitem>
+     remote: Counting objects: 7366, done.
+     remote: Compressing objects: 100% (2491/2491), done.
+     remote: Total 7366 (delta 3997), reused 7299 (delta 3930)
+     Receiving objects: 100% (7366/7366), 2.31 MiB | 95 KiB/s, done.
+     Resolving deltas: 100% (3997/3997), done.
+                        </literallayout>
+                        The same
+                        <ulink url='&YOCTO_WIKI_URL;/wiki/Transcript:_from_git_checkout_to_meta-intel_BSP'>wiki page</ulink>
+                        referenced earlier covers how to
+                        set up the <filename>meta-intel</filename> Git
+                        repository.</para></listitem>
                 </itemizedlist></para></listitem>
             <listitem><para><emphasis>Eclipse Yocto Plug-in:</emphasis>  If you are developing
                 applications using the Eclipse Integrated Development Environment (IDE),

documentation/dev-manual/dev-manual.xml

@@ -53,9 +53,29 @@
             </revision>
             <revision>
                 <revnumber>1.5</revnumber>
-                <date>Sometime in 2013</date>
+                <date>October 2013</date>
                 <revremark>Released with the Yocto Project 1.5 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>1.5.1</revnumber>
+                <date>January 2014</date>
+                <revremark>Released with the Yocto Project 1.5.1 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.5.2</revnumber>
+                <date>May 2014</date>
+                <revremark>Released with the Yocto Project 1.5.2 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.5.3</revnumber>
+                <date>July 2014</date>
+                <revremark>Released with the Yocto Project 1.5.3 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.5.4</revnumber>
+                <date>December 2014</date>
+                <revremark>Released with the Yocto Project 1.5.4 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>
@@ -72,11 +92,10 @@
       </para>
 
       <note>
-          Due to production processes, there could be differences between the Yocto Project
-          documentation bundled in the release tarball and the
-          <ulink url='&YOCTO_DOCS_DEV_URL;'>Yocto Project Development Manual</ulink> on
-          the <ulink url='&YOCTO_HOME_URL;'>Yocto Project</ulink> website.
-          For the latest version of this manual, see the manual on the website.
+          For the latest version of this manual associated with this
+          Yocto Project release, see the
+          <ulink url='&YOCTO_DOCS_DEV_URL;'>Yocto Project Development Manual</ulink>
+          from the Yocto Project website.
       </note>
     </legalnotice>
 

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

@@ -296,6 +296,20 @@
      $ git commit --allow-empty -m "Create orphan meta branch"
             </literallayout>
         </para>
+
+        <para>
+            If you modify the Metadata in the linux-yocto 
+            <filename>meta</filename> branch, you must not forget to update 
+            the 
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-SRCREV'><filename>SRCREV</filename></ulink>
+            statements in the kernel's recipe.
+            In particular, you need to update the 
+            <filename>SRCREV_meta</filename> variable to match the commit in 
+            the <filename>KMETA</filename> branch you wish to use.
+            Changing the data in these branches and not updating the 
+            <filename>SRCREV</filename> statements to match will cause the 
+            build to fetch an older commit.
+        </para>
     </section>
 </section>
 

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

@@ -95,7 +95,7 @@
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></ulink>
                 variable as follows:
                 <literallayout class='monospaced'>
-     FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}"
+     FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
                 </literallayout>
                 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

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

@@ -45,7 +45,7 @@
             Here is an example that assumes the local Git repository for the kernel is in
             a top-level directory named <filename>linux-yocto-3.4</filename>:
             <literallayout class='monospaced'>
-     $ cd ~/linux-yocto-3.4
+     $ cd linux-yocto-3.4
      $ git checkout -b meta origin/meta
             </literallayout>
             Once you have checked out and switched to the <filename>meta</filename> branch,
@@ -208,7 +208,7 @@
             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 
+            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.

documentation/kernel-dev/kernel-dev.xml

@@ -38,9 +38,29 @@
             </revision>
             <revision>
                 <revnumber>1.5</revnumber>
-                <date>Sometime in 2013</date>
+                <date>October 2013</date>
                 <revremark>Released with the Yocto Project 1.5 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>1.5.1</revnumber>
+                <date>January 2014</date>
+                <revremark>Released with the Yocto Project 1.5.1 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.5.2</revnumber>
+                <date>May 2014</date>
+                <revremark>Released with the Yocto Project 1.5.2 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.5.3</revnumber>
+                <date>July 2014</date>
+                <revremark>Released with the Yocto Project 1.5.3 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.5.4</revnumber>
+                <date>December 2014</date>
+                <revremark>Released with the Yocto Project 1.5.4 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>
@@ -54,11 +74,10 @@
         the terms of the <ulink type="http" url="http://creativecommons.org/licenses/by-sa/2.0/uk/">Creative Commons Attribution-Share Alike 2.0 UK: England &amp; Wales</ulink> as published by Creative Commons.
       </para>
       <note>
-          Due to production processes, there could be differences between the Yocto Project
-          documentation bundled in the release tarball and the
-          <ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;'>Yocto Project Linux Kernel Development Manual</ulink> on
-          the <ulink url='&YOCTO_HOME_URL;'>Yocto Project</ulink> website.
-          For the latest version of this manual, see the manual on the website.
+          For the latest version of this manual associated with this
+          Yocto Project release, see the
+          <ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;'>Yocto Project Linux Kernel Development Manual</ulink>
+          from the Yocto Project website.
       </note>
     </legalnotice>
 

documentation/poky.ent

@@ -1,11 +1,11 @@
-<!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 DISTRO "1.5.4">
+<!ENTITY DISTRO_COMPRESSED "154">
+<!ENTITY DISTRO_NAME "dora">
+<!ENTITY YOCTO_DOC_VERSION "1.5.4">
+<!ENTITY POKYVERSION "10.0.4">
+<!ENTITY POKYVERSION_COMPRESSED "1004">
 <!ENTITY YOCTO_POKY "poky-&DISTRO_NAME;-&POKYVERSION;">
-<!ENTITY COPYRIGHT_YEAR "2010-2013">
+<!ENTITY COPYRIGHT_YEAR "2010-2014">
 <!ENTITY YOCTO_DL_URL "http://downloads.yoctoproject.org">
 <!ENTITY YOCTO_HOME_URL "http://www.yoctoproject.org">
 <!ENTITY YOCTO_LISTS_URL "http://lists.yoctoproject.org">
@@ -14,9 +14,9 @@
 <!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 YOCTO_RELEASE_NOTES "&YOCTO_HOME_URL;/downloads/core/&DISTRO_NAME;&DISTRO_COMPRESSED;">
 <!ENTITY OE_HOME_URL "http://www.openembedded.org">
-<!ENTITY OE_LISTS_URL "http://lists.linuxtogo.org/cgi-bin/mailman">
+<!ENTITY OE_LISTS_URL "http://lists.openembedded.org/mailman">
 <!ENTITY OE_DOCS_URL "http://docs.openembedded.org">
 <!ENTITY OH_HOME_URL "http://o-hand.com">
 <!ENTITY BITBAKE_HOME_URL "http://developer.berlios.de/projects/bitbake/">
@@ -26,6 +26,7 @@
 <!ENTITY ECLIPSE_UPDATES_URL "&ECLIPSE_DL_URL;/tm/updates/3.3">
 <!ENTITY ECLIPSE_INDIGO_URL "&ECLIPSE_DL_URL;/releases/indigo">
 <!ENTITY ECLIPSE_JUNO_URL "&ECLIPSE_DL_URL;/releases/juno">
+<!ENTITY ECLIPSE_KEPLER_URL "&ECLIPSE_DL_URL;/releases/kepler">
 <!ENTITY ECLIPSE_INDIGO_CDT_URL "&ECLIPSE_DL_URL;tools/cdt/releases/indigo">
 <!ENTITY YOCTO_DOCS_URL "&YOCTO_HOME_URL;/docs">
 <!ENTITY YOCTO_SOURCES_URL "&YOCTO_HOME_URL;/sources/">
@@ -35,7 +36,7 @@
 <!ENTITY YOCTO_RELEASE_DL_URL "&YOCTO_DL_URL;/releases/yocto/yocto-&DISTRO;">
 <!ENTITY YOCTO_TOOLCHAIN_DL_URL "&YOCTO_RELEASE_DL_URL;/toolchain/">
 <!ENTITY YOCTO_ECLIPSE_DL_URL "&YOCTO_RELEASE_DL_URL;/eclipse-plugin/indigo;">
-<!ENTITY YOCTO_ADTINSTALLER_DL_URL "&YOCTO_RELEASE_DL_URL;/adt_installer">
+<!ENTITY YOCTO_ADTINSTALLER_DL_URL "&YOCTO_RELEASE_DL_URL;/adt-installer">
 <!ENTITY YOCTO_POKY_DL_URL "&YOCTO_RELEASE_DL_URL;/&YOCTO_POKY;.tar.bz2">
 <!ENTITY YOCTO_MACHINES_DL_URL "&YOCTO_RELEASE_DL_URL;/machines">
 <!ENTITY YOCTO_QEMU_DL_URL "&YOCTO_MACHINES_DL_URL;/qemu">
@@ -53,11 +54,11 @@
 <!ENTITY YOCTO_POKY_TARBALL "&YOCTO_POKY;.tar.bz2">
 <!ENTITY OE_INIT_PATH "&YOCTO_POKY;/oe-init-build-env">
 <!ENTITY OE_INIT_FILE "oe-init-build-env">
-<!ENTITY UBUNTU_HOST_PACKAGES_ESSENTIAL "gawk wget git-core diffstat unzip texinfo \
+<!ENTITY UBUNTU_HOST_PACKAGES_ESSENTIAL "gawk wget git-core diffstat unzip texinfo gcc-multilib \
      build-essential chrpath">
 <!ENTITY FEDORA_HOST_PACKAGES_ESSENTIAL "gawk make wget tar bzip2 gzip python unzip perl patch \
-     diffutils diffstat git cpp gcc gcc-c++ eglibc-devel texinfo chrpath \
-     ccache">
+     diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath \
+     ccache perl-Data-Dumper perl-Text-ParseWords">
 <!ENTITY OPENSUSE_HOST_PACKAGES_ESSENTIAL "python gcc gcc-c++ git chrpath make wget python-xml \
      diffstat texinfo python-curses patch">
 <!ENTITY CENTOS_HOST_PACKAGES_ESSENTIAL "gawk make wget tar bzip2 gzip python unzip perl patch \

documentation/profile-manual/profile-manual-intro.xml

@@ -4,7 +4,7 @@
 
 <chapter id='profile-manual-intro'>
 
-<title>Yocto Project Tracing and Profiling Manual</title>
+<title>Yocto Project Profiling and Tracing Manual</title>
     <section id='intro'>
         <title>Introduction</title>
 
@@ -78,7 +78,7 @@
         </para>
 
         <para>
-            If you've already build a stripped image, you can generate
+            If you've already built a stripped image, you can generate
             debug packages (xxx-dbg) which you can manually install as
             needed.
         </para>

documentation/profile-manual/profile-manual-usage.xml

@@ -22,7 +22,7 @@
     <para>
         Don't let the fact that it's part of the kernel fool you into thinking
         that it's only for tracing and profiling the kernel - you can indeed
-        use it to trace and profile just the kernel , but you can also use it
+        use it to trace and profile just the kernel, but you can also use it
         to profile specific applications separately (with or without kernel
         context), and you can also use it to trace and profile the kernel
         and all applications on the system simultaneously to gain a system-wide
@@ -30,10 +30,10 @@
     </para>
 
     <para>
-        In many ways, it aims to be a superset of all the tracing and profiling
+        In many ways, perf aims to be a superset of all the tracing and profiling
         tools available in Linux today, including all the other tools covered
         in this HOWTO. The past couple of years have seen perf subsume a lot
-        of the functionality of those other tools, and at the same time those
+        of the functionality of those other tools and, at the same time, those
         other tools have removed large portions of their previous functionality
         and replaced it with calls to the equivalent functionality now
         implemented by the perf subsystem. Extrapolation suggests that at
@@ -126,7 +126,7 @@
      wget <ulink url='http://downloads.yoctoproject.org/mirror/sources/linux-2.6.19.2.tar.bz2'>http://downloads.yoctoproject.org/mirror/sources/linux-2.6.19.2.tar.bz2</ulink>
                 </literallayout>
                 The quickest and easiest way to get some basic overall data about
-                what's going on for a particular workload it to profile it using
+                what's going on for a particular workload is to profile it using
                 'perf stat'. 'perf stat' basically profiles using a few default
                 counters and displays the summed counts at the end of the run:
                 <literallayout class='monospaced'>
@@ -201,7 +201,7 @@
                 As our first attempt at profiling this workload, we'll simply
                 run 'perf record', handing it the workload we want to profile
                 (everything after 'perf record' and any perf options we hand
-                it - here none - will be executedin a new shell). perf collects
+                it - here none - will be executed in a new shell). perf collects
                 samples until the process exits and records them in a file named
                 'perf.data' in the current working directory.
                 <literallayout class='monospaced'>
@@ -241,7 +241,7 @@
                 Notice also that the above report shows an entry for 'busybox',
                 which is the executable that implements 'wget' in Yocto, but that
                 instead of a useful function name in that entry, it displays
-                an not-so-friendly hex value instead. The steps below will show
+                a not-so-friendly hex value instead. The steps below will show
                 how to fix that problem.
             </para>
 
@@ -308,7 +308,7 @@
             </para>
 
             <para>
-                Notice also that here there's also a case where the a hex value
+                Notice also that here there's also a case where the hex value
                 is displayed in the callstack, here in the expanded
                 sys_clock_gettime() function. Later we'll see it resolve to a
                 userspace function call in busybox.
@@ -367,7 +367,7 @@
 
             <para>
                 To generate the debug info for the packages in the image, we can
-                to add dbg-pkgs to EXTRA_IMAGE_FEATURES in local.conf. For example:
+                add dbg-pkgs to EXTRA_IMAGE_FEATURES in local.conf. For example:
                 <literallayout class='monospaced'>
      EXTRA_IMAGE_FEATURES = "debug-tweaks tools-profile dbg-pkgs"
                 </literallayout>
@@ -462,7 +462,7 @@
                 The tracing and profiling infrastructure in Linux has become
                 unified in a way that allows us to use the same tool with a
                 completely different set of counters, not just the standard
-                hardware counters that traditionally tools have had to restrict
+                hardware counters that traditional tools have had to restrict
                 themselves to (of course the traditional tools can also make use
                 of the expanded possibilities now available to them, and in some
                 cases have, as mentioned previously).
@@ -828,7 +828,7 @@
             </para>
 
             <para>
-                Luckily, there is general-purpose way to handle such needs,
+                Luckily, there is a general-purpose way to handle such needs,
                 called 'programming languages'. Making programming languages
                 easily available to apply to such problems given the specific
                 format of data is called a 'programming language binding' for
@@ -842,7 +842,7 @@
                 idea.  One of the first projects to do this was IBM's DProbes
                 dpcc compiler, an ANSI C compiler which targeted a low-level
                 assembly language running on an in-kernel interpreter on the
-                target system.  This is exactly analagous to what Sun's DTrace
+                target system.  This is exactly analogous to what Sun's DTrace
                 did, except that DTrace invented its own language for the purpose.
                 Systemtap, heavily inspired by DTrace, also created its own
                 one-off language, but rather than running the product on an
@@ -925,9 +925,9 @@
                 </literallayout>
                 Each event handler function in the generated code is modified
                 to do this. For convenience, we define a common function called
-                inc_counts() that each handler calls; inc_counts simply tallies
+                inc_counts() that each handler calls; inc_counts() simply tallies
                 a count for each event using the 'counts' hash, which is a
-                specialized has function that does Perl-like autovivification, a
+                specialized hash function that does Perl-like autovivification, a
                 capability that's extremely useful for kinds of multi-level
                 aggregation commonly used in processing traces (see perf's
                 documentation on the Python language binding for details):
@@ -1275,7 +1275,7 @@
             </para>
 
             <informalexample>
-                <emphasis>Tying it Together:</emphasis> The trace events subsystem accomodate static
+                <emphasis>Tying it Together:</emphasis> The trace events subsystem accommodate static
                 and dynamic tracepoints in exactly the same way - there's no
                 difference as far as the infrastructure is concerned.  See the
                 ftrace section for more details on the trace event subsystem.
@@ -1377,7 +1377,7 @@
             the /tracing directory of the mounted debugfs filesystem
             (Yocto follows the standard convention and mounts it
             at /sys/kernel/debug). Here's a listing of all the files
-            found in /sys/kernel/debug/tracing on a Yocto system.:
+            found in /sys/kernel/debug/tracing on a Yocto system:
             <literallayout class='monospaced'>
      root@sugarbay:/sys/kernel/debug/tracing# ls
      README                      kprobe_events               trace
@@ -1634,7 +1634,7 @@
             Also notice that there are various annotations on the left
             hand side of the display. For example if the total time it
             took for a given function to execute is above a certain
-            threshold, and exclamation point or plus sign appears on the
+            threshold, an exclamation point or plus sign appears on the
             left hand side. Please see the ftrace documentation for
             details on all these fields.
         </para>
@@ -1842,7 +1842,7 @@
             </literallayout>
             You can enable any number of events or complete subsystems
             (by using the 'enable' file in the subsystem directory) and
-            get am arbitrarily fine-grained idea of what's going on in the
+            get an arbitrarily fine-grained idea of what's going on in the
             system by enabling as many of the appropriate tracepoints
             as applicable.
         </para>
@@ -1878,14 +1878,14 @@
             in /sys/kernel/debug/tracing, allowing users to specify
             specific particular events within the
             /sys/kernel/debug/tracing/events/ subdirectory and to collect
-            traces and avoiding having to deal with those details directly.
+            traces and avoid having to deal with those details directly.
         </para>
 
         <para>
             As yet another layer on top of that, kernelshark provides a GUI
             that allows users to start and stop traces and specify sets
             of events using an intuitive interface, and view the
-            output as both trace events and as a per-cpu graphical
+            output as both trace events and as a per-CPU graphical
             display. It directly uses 'trace-cmd' as the plumbing
             that accomplishes all that underneath the covers (and
             actually displays the trace-cmd command it uses, as we'll see).
@@ -1896,13 +1896,13 @@
             <literallayout class='monospaced'>
      root@sugarbay:~# kernelshark
             </literallayout>
-            The bring up the 'Capture' dialog by choosing from the
+            Then bring up the 'Capture' dialog by choosing from the
             kernelshark menu:
             <literallayout class='monospaced'>
      Capture | Record
             </literallayout>
             That will display the following dialog, which allows you to
-            choose on or more events (or even one or more complete
+            choose one or more events (or even one or more complete
             subsystems) to trace:
         </para>
 
@@ -1911,7 +1911,7 @@
         </para>
 
         <para>
-            Note that these are exactly the same set of events described
+            Note that these are exactly the same sets of events described
             in the previous trace events subsystem section, and in fact
             is where trace-cmd gets them for kernelshark.
         </para>
@@ -1980,13 +1980,15 @@
             <literallayout class='monospaced'>
      Documentation/trace/events.txt
             </literallayout>
-            There are a nice series of articles on using
+            There is a nice series of articles on using
             ftrace and trace-cmd at LWN:
             <itemizedlist>
                 <listitem><para><ulink url='http://lwn.net/Articles/365835/'>Debugging the kernel using Ftrace - part 1</ulink>
                     </para></listitem>
                 <listitem><para><ulink url='http://lwn.net/Articles/366796/'>Debugging the kernel using Ftrace - part 2</ulink>
                     </para></listitem>
+                <listitem><para><ulink url='http://lwn.net/Articles/370423/'>Secrets of the Ftrace function tracer</ulink>
+                    </para></listitem>
                 <listitem><para><ulink url='https://lwn.net/Articles/410200/'>trace-cmd: A front-end for Ftrace</ulink>
                     </para></listitem>
             </itemizedlist>
@@ -2022,7 +2024,7 @@
         <ulink url='http://sourceware.org/systemtap/tutorial/'>SystemTap tutorial</ulink>
         simply prints a line every time any process on the system open()s
         a file. For each line, it prints the executable name of the
-        program that opened the file, along with its pid, and the name
+        program that opened the file, along with its PID, and the name
         of the file it opened (or tried to open), which it extracts
         from the open syscall's argstr.
         <literallayout class='monospaced'>
@@ -2096,6 +2098,15 @@
             booted. The 'crosstap' script provides details on how
             to do this if you run the script on the host without having
             done a build:
+            <note>
+                SystemTap, which uses 'crosstap', assumes you can establish an
+                ssh connection to the remote target.
+                Please refer to the crosstap wiki page for details on verifying
+                ssh connections at
+                <ulink url='https://wiki.yoctoproject.org/wiki/Tracing_and_Profiling#systemtap'></ulink>.
+                Also, the ability to ssh into the target system is not enabled
+                by default in *-minimal images.
+            </note>
             <literallayout class='monospaced'>
      $ crosstap root@192.168.1.88 trace_open.stp
 
@@ -2122,9 +2133,6 @@
             the EXTRA_IMAGE_FEATURES variable ]
           $ bitbake core-image-sato
 
-      [ NOTE that 'crosstap' needs to be able to ssh into the target
-        system, which isn't enabled by default in -minimal images. ]
-
      Once you've build the image on the host system, you're ready to
      boot it (or the equivalent pre-built image) and use 'crosstap'
      to probe it (you need to source the environment as usual first):
@@ -2195,7 +2203,7 @@
         <para>
             If everything worked as planned, you should see something
             like this (enter the password when prompted, or press enter
-            if its set up to use no password):
+            if it's set up to use no password):
             <literallayout class='monospaced'>
      $ crosstap root@192.168.7.2 trace_open.stp
      root@192.168.7.2's password:
@@ -2240,7 +2248,7 @@
         </para>
 
         <para>
-            For the the section that deals with oprofile from the command-line,
+            For the section that deals with running oprofile from the command-line,
             we assume you've ssh'ed to the host and will be running
             oprofile on the target.
         </para>
@@ -2260,7 +2268,7 @@
             Oprofile as configured in Yocto is a system-wide profiler
             (i.e. the version in Yocto doesn't yet make use of the
             perf_events interface which would allow it to profile
-            specific processes and workloads). It's relies on hardware
+            specific processes and workloads). It relies on hardware
             counter support in the hardware (but can fall back to a
             timer-based mode), which means that it doesn't take
             advantage of tracepoints or other event sources for example.
@@ -2281,8 +2289,8 @@
         <para>
             The oprofile daemon should already be running, but before
             you start profiling, you may need to change some settings
-            and some of these settings may require the daemon not
-            be running. One of these settings is the path the the
+            and some of these settings may require the daemon to not
+            be running. One of these settings is the path to the
             vmlinux file, which you'll want to set using the --vmlinux
             option if you want the kernel profiled:
             <literallayout class='monospaced'>
@@ -2313,7 +2321,7 @@
      Using log file /var/lib/oprofile/samples/oprofiled.log
      Daemon started.
             </literallayout>
-            If we get the status again we now see our updated settings:
+            If we check the status again we now see our updated settings:
             <literallayout class='monospaced'>
      root@crownbay:~# opcontrol --status
      Daemon paused: pid 1649
@@ -2322,7 +2330,7 @@
      Image filter: none
      Call-graph depth: 6
             </literallayout>
-            We're now in a position to run a profile. For that we used
+            We're now in a position to run a profile. For that we use
             'opcontrol --start':
             <literallayout class='monospaced'>
      root@crownbay:~# opcontrol --start
@@ -2334,10 +2342,10 @@
      Connecting to downloads.yoctoproject.org (140.211.169.59:80)
      linux-2.6.19.2.tar.b 100% |*******************************| 41727k  0:00:00 ETA
             </literallayout>
-            To stop the profile we use 'opcontrol --shudown', which not
+            To stop the profile we use 'opcontrol --shutdown', which not
             only stops the profile but shuts down the daemon as well:
             <literallayout class='monospaced'>
-     root@crownbay:~# opcontrol --start
+     root@crownbay:~# opcontrol --shutdown
      Stopping profiling.
      Killing daemon.
             </literallayout>
@@ -2896,7 +2904,7 @@
 
         <para>
             Once you've applied the above commits and built and booted your
-            image (you need to build the core-image-sato-sdk image or the
+            image (you need to build the core-image-sato-sdk image or use one of the
             other methods described in the General Setup section), you're
             ready to start tracing.
         </para>
@@ -2905,7 +2913,7 @@
             <title>Collecting and viewing a trace on the target (inside a shell)</title>
 
             <para>
-                First, from the target, ssh to the target:
+                First, from the host, ssh to the target:
                 <literallayout class='monospaced'>
      $ ssh -l root 192.168.1.47
      The authenticity of host '192.168.1.47 (192.168.1.47)' can't be established.
@@ -3006,7 +3014,7 @@
             <title>Collecting and viewing a userspace trace on the target (inside a shell)</title>
 
             <para>
-                For lttng userspace tracing, you need to have a properly
+                For LTTng userspace tracing, you need to have a properly
                 instrumented userspace program. For this example, we'll use
                 the 'hello' test program generated by the lttng-ust build.
             </para>
@@ -3028,7 +3036,7 @@
             </para>
 
             <para>
-                First, from the target, ssh to the target:
+                First, from the host, ssh to the target:
                 <literallayout class='monospaced'>
      $ ssh -l root 192.168.1.47
      The authenticity of host '192.168.1.47 (192.168.1.47)' can't be established.
@@ -3094,7 +3102,7 @@
                 If you already have an LTTng trace on a remote target and
                 would like to view it in Eclipse on the host, you can easily
                 copy it from the target to the host and import it into
-                Eclipse to view it using the LTTng Eclipse plugin already
+                Eclipse to view it using the LTTng Eclipse plug-in already
                 bundled in the Eclipse (Juno SR1 or greater).
             </para>
 
@@ -3172,7 +3180,7 @@
 
             <para>
                 You can access extensive help information on how to use
-                the LTTng plugin to search and analyze captured traces via
+                the LTTng plug-in to search and analyze captured traces via
                 the Eclipse help system:
                 <literallayout class='monospaced'>
      Help | Help Contents | LTTng Plug-in User Guide
@@ -3250,15 +3258,25 @@
         <title>Documentation</title>
 
         <para>
-            There doesn't seem to be any current documentation covering
-            LTTng 2.0, but maybe that's because the project is in transition.
-            The LTTng 2.0 website, however, is here:
-            <ulink url='http://lttng.org/lttng2.0'>LTTng Project</ulink>
+            You can find the primary LTTng Documentation on the
+            <ulink url='https://lttng.org/docs/'>LTTng Documentation</ulink>
+            site.
+            The documentation on this site is appropriate for intermediate to
+            advanced software developers who are working in a Linux environment
+            and are interested in efficient software tracing.
         </para>
 
         <para>
-            You can access extensive help information on how to use the
-            LTTng plug-in to search and analyze captured traces via the
+            For information on LTTng in general, visit the
+            <ulink url='http://lttng.org/lttng2.0'>LTTng Project</ulink>
+            site.
+            You can find a "Getting Started" link on this site that takes
+            you to an LTTng Quick Start.
+        </para>
+
+        <para>
+            Finally, you can access extensive help information on how to use
+            the LTTng plug-in to search and analyze captured traces via the
             Eclipse help system:
             <literallayout class='monospaced'>
      Help | Help Contents | LTTng Plug-in User Guide
@@ -3594,7 +3612,7 @@
                 It's also possible to trace block I/O using only
                 <link linkend='the-trace-events-subsystem'>trace events subsystem</link>,
                 which can be useful for casual tracing
-                if you don't want bother dealing with the userspace tools.
+                if you don't want to bother dealing with the userspace tools.
             </para>
 
             <para>

documentation/profile-manual/profile-manual.xml

@@ -38,9 +38,29 @@
             </revision>
             <revision>
                 <revnumber>1.5</revnumber>
-                <date>Sometime in 2013</date>
+                <date>October 2013</date>
                 <revremark>Released with the Yocto Project 1.5 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>1.5.1</revnumber>
+                <date>January 2014</date>
+                <revremark>Released with the Yocto Project 1.5.1 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.5.2</revnumber>
+                <date>May 2014</date>
+                <revremark>Released with the Yocto Project 1.5.2 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.5.3</revnumber>
+                <date>July 2014</date>
+                <revremark>Released with the Yocto Project 1.5.3 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.5.4</revnumber>
+                <date>December 2014</date>
+                <revremark>Released with the Yocto Project 1.5.4 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>
@@ -57,11 +77,10 @@
       </para>
 
       <note>
-          Due to production processes, there could be differences between the Yocto Project
-          documentation bundled in the release tarball and the
-          <ulink url='&YOCTO_DOCS_PROF_URL;'>Yocto Project Tracing and Profiling Manual</ulink> on
-          the <ulink url='&YOCTO_HOME_URL;'>Yocto Project</ulink> website.
-          For the latest version of this manual, see the manual on the website.
+          For the latest version of this manual associated with this
+          Yocto Project release, see the
+          <ulink url='&YOCTO_DOCS_PROF_URL;'>Yocto Project Profiling and Tracing Manual</ulink>
+          from the Yocto Project website.
       </note>
     </legalnotice>
 

documentation/ref-manual/closer-look.xml

@@ -106,7 +106,7 @@
             configuration files.
             These example files are used as a basis for creating actual
             configuration files when you source the build environment
-            script 
+            script
             (i.e.
             <link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>
             or
@@ -129,8 +129,8 @@
         <para>
             Because the Poky repository is fundamentally an aggregation of
             existing repositories, some users might be familiar with running
-            the <filename>&OE_INIT_FILE;</filename> or 
-            <filename>oe-init-build-env-memres</filename> script in the context 
+            the <filename>&OE_INIT_FILE;</filename> or
+            <filename>oe-init-build-env-memres</filename> script in the context
             of separate OpenEmbedded-Core and BitBake repositories rather than a
             single Poky repository.
             This discussion assumes the script is executed from within a cloned
@@ -267,7 +267,7 @@
 
         <para>
             The previous section described the user configurations that
-            define the BitBake's global behavior.
+            define BitBake's global behavior.
             This section takes a closer look at the layers the build system
             uses to further control the build.
             These layers provide Metadata for the software, machine, and
@@ -297,7 +297,7 @@
         <para>
             The following figure shows an expanded representation of the
             Metadata, Machine Configuration, and Policy Configuration input
-            (layers) boxes of the 
+            (layers) boxes of the
             <link linkend='general-yocto-environment-figure'>general Yocto Project Development Environment figure</link>:
         </para>
 
@@ -363,7 +363,7 @@
                 for what you typically find in the distribution layer:
                 <itemizedlist>
                     <listitem><para><emphasis>classes:</emphasis>
-                        Class files (<filename>.bbclass</filename>) holds
+                        Class files (<filename>.bbclass</filename>) hold
                         common functionality that can be shared among
                         recipes in the distribution.
                         When your recipes inherit a class, they take on the
@@ -381,7 +381,7 @@
                     <listitem><para><emphasis>recipes-*:</emphasis>
                         Recipes and append files that affect common
                         functionality across the distribution.
-                        This area could include recipes and append files to
+                        This area could include recipes and append files
                         to add distribution-specific configuration,
                         initialization scripts, custom image recipes,
                         and so forth.</para></listitem>
@@ -421,7 +421,7 @@
                 Metadata can exist for multiple formfactors, graphics
                 support systems, and so forth.
                 <note>
-                    While the figure shows several <filename>recipe-*</filename>
+                    While the figure shows several <filename>recipes-*</filename>
                     directories, not all these directories appear in all
                     BSP layers.
                 </note>
@@ -452,7 +452,7 @@
         <para>
             In order for the OpenEmbedded build system to create an image or
             any target, it must be able to access source files.
-            The 
+            The
             <link linkend='general-yocto-environment-figure'>general Yocto Project Development Environment figure</link>
             represents source files using the "Upstream Project Releases",
             "Local Projects", and "SCMs (optional)" boxes.
@@ -487,10 +487,18 @@
 
         <para>
             Another area that plays a significant role in where source files
-            comes from is pointed to by the
+            come from is pointed to by the
             <link linkend='var-DL_DIR'><filename>DL_DIR</filename></link>
             variable.
             This area is a cache that can hold previously downloaded source.
+            You can also instruct the OpenEmbedded build system to create
+            tarballs from Git repositories, which is not the default behavior,
+            and store them in the <filename>DL_DIR</filename> by using the
+            <link linkend='var-BB_GENERATE_MIRROR_TARBALLS'><filename>BB_GENERATE_MIRROR_TARBALLS</filename></link>
+            variable.
+        </para>
+
+        <para>
             Judicious use of a <filename>DL_DIR</filename> directory can
             save the build system a trip across the Internet when looking
             for files.
@@ -538,7 +546,7 @@
                 The canonical method through which to include a local project
                 is to use the
                 <link linkend='ref-classes-externalsrc'><filename>externalsrc.bbclass</filename></link>
-                class to include local project.
+                class to include that local project.
                 You use either the <filename>local.conf</filename> or a
                 recipe's append file to override or set the
                 recipe to point to the local directory on your disk to pull
@@ -566,6 +574,15 @@
                 fetcher module.
             </para>
 
+            <note>
+                For information on how to have the OpenEmbedded build system
+                generate tarballs for Git repositories and place them in the
+                <link linkend='var-DL_DIR'><filename>DL_DIR</filename></link>
+                directory, see the
+                <link linkend='var-BB_GENERATE_MIRROR_TARBALLS'><filename>BB_GENERATE_MIRROR_TARBALLS</filename></link>
+                variable.
+            </note>
+
             <para>
                 When fetching a repository, BitBake uses the
                 <link linkend='var-SRCREV'><filename>SRCREV</filename></link>
@@ -601,6 +618,58 @@
         </section>
     </section>
 
+    <section id="package-feeds-dev-environment">
+        <title>Package Feeds</title>
+
+        <para>
+            When the OpenEmbedded build system generates an image or an SDK,
+            it gets the packages from a package feed area located in the
+            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+            The
+            <link linkend='general-yocto-environment-figure'>general Yocto Project Development Environment figure</link>
+            shows this package feeds area in the upper-right corner.
+        </para>
+
+        <para>
+            This section looks a little closer into the package feeds area used
+            by the build system.
+            Here is a more detailed look at the area:
+            <imagedata fileref="figures/package-feeds.png" align="center" width="7in" depth="6in" />
+        </para>
+
+        <para>
+            Package feeds are an intermediary step in the build process.
+            BitBake generates packages whose type is defined by the
+            <link linkend='var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></link>
+            variable.
+            Before placing the packages into package feeds,
+            the build process validates them with generated output quality
+            assurance checks through the
+            <link linkend='ref-classes-insane'><filename>insane.bbclass</filename></link>
+            class.
+        </para>
+
+        <para>
+            The package feed area resides in
+            <filename>tmp/deploy</filename> of the Build Directory.
+            Folders are created that correspond to the package type
+            (IPK, DEB, or RPM) created.
+            Further organization is derived through the value of the
+            <link linkend='var-PACKAGE_ARCH'><filename>PACKAGE_ARCH</filename></link>
+            variable for each package.
+            For example, packages can exist for the i586 or qemux86
+            architectures.
+            The package files themselves reside within the appropriate
+            architecture folder.
+        </para>
+
+        <para>
+            BitBake uses the <filename>do_package_write_*</filename> task to
+            place generated packages into the package holding area (e.g.
+            <filename>do_package_write_ipk</filename> for IPK packages).
+        </para>
+    </section>
+
     <section id='bitbake-dev-environment'>
         <title>BitBake</title>
 
@@ -618,13 +687,13 @@
             <para>
                 The first stages of building a recipe are to fetch and unpack
                 the source code:
-                <imagedata fileref="figures/source-fetching.png" align="center" width="6.5in" depth="4in" />
+                <imagedata fileref="figures/source-fetching.png" align="center" width="6.5in" depth="5in" />
             </para>
 
             <para>
                 The <filename>do_fetch</filename> and
                 <filename>do_unpack</filename> tasks fetch the source files
-                and unpack them into a working directory.
+                and unpack them into the work directory.
                 By default, everything is accomplished in the
                 <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>,
                 which has a defined structure.
@@ -635,11 +704,11 @@
             </para>
 
             <para>
-                Unpacked source source files are pointed to by the
+                Unpacked source files are pointed to by the
                 <link linkend='var-S'><filename>S</filename></link> variable.
                 Each recipe has an area in the Build Directory where the
                 unpacked source code resides.
-                The name of directory for any given recipe is defined from
+                The name of that directory for any given recipe is defined from
                 several different variables.
                 You can see the variables that define these directories
                 by looking at the figure:
@@ -740,7 +809,7 @@
                         variable.
                         For information on how this variable works within
                         that class, see the
-                        <filename>meta/classes/autotools.bbclass</filename>.
+                        <filename>meta/classes/autotools.bbclass</filename> file.
                         </para></listitem>
                     <listitem><para><emphasis><filename>do_compile</filename>:</emphasis>
                         Once a configuration task has been satisfied, BitBake
@@ -749,8 +818,8 @@
                         Compilation occurs in the directory pointed to by the
                         <link linkend='var-B'><filename>B</filename></link>
                         variable.
-                        Realize that the <filename>B</filename> directory, by
-                        default, is the same as the
+                        Realize that the <filename>B</filename> directory is, by
+                        default, the same as the
                         <link linkend='var-S'><filename>S</filename></link>
                         directory.</para></listitem>
                     <listitem><para><emphasis><filename>do_install</filename>:</emphasis>
@@ -830,58 +899,151 @@
                 </note>
             </para>
         </section>
-    </section>
 
-    <section id="package-feeds-dev-environment">
-        <title>Package Feeds</title>
+        <section id='image-generation-dev-environment'>
+            <title>Image Generation</title>
 
-        <para>
-            When the OpenEmbedded build system generates an image or an SDK,
-            it gets the packages from a package feed area located in the
-            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
-            The 
-            <link linkend='general-yocto-environment-figure'>general Yocto Project Development Environment figure</link>
-            shows this package feeds area in the upper-right corner.
-        </para>
+            <para>
+                Once packages are split and stored in the Package Feeds area,
+                the OpenEmbedded build system uses BitBake to generate the
+                root filesystem image:
+                <imagedata fileref="figures/image-generation.png" align="center" width="6in" depth="7in" />
+            </para>
 
-        <para>
-            This section looks a little closer into the package feeds area used
-            by the build system.
-            Here is a more detailed look at the area:
-            <imagedata fileref="figures/package-feeds.png" align="center" width="7in" depth="6in" />
-        </para>
+            <para>
+                The image generation process consists of several stages and
+                depends on many variables.
+                The <filename>do_rootfs</filename> task uses these key variables
+                to help create the list of packages to actually install:
+                <itemizedlist>
+                    <listitem><para><link linkend='var-IMAGE_INSTALL'><filename>IMAGE_INSTALL</filename></link>:
+                        Lists out the base set of packages to install from
+                        the Package Feeds area.</para></listitem>
+                    <listitem><para><link linkend='var-PACKAGE_EXCLUDE'><filename>PACKAGE_EXCLUDE</filename></link>:
+                        Specifies packages that should not be installed.
+                        </para></listitem>
+                    <listitem><para><link linkend='var-IMAGE_FEATURES'><filename>IMAGE_FEATURES</filename></link>:
+                        Specifies features to include in the image.
+                        Most of these features map to additional packages for
+                        installation.</para></listitem>
+                    <listitem><para><link linkend='var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></link>:
+                        Specifies the package backend to use and consequently
+                        helps determine where to locate packages within the
+                        Package Feeds area.</para></listitem>
+                    <listitem><para><link linkend='var-IMAGE_LINGUAS'><filename>IMAGE_LINGUAS</filename></link>:
+                        Determines the language(s) for which additional
+                        language support packages are installed.
+                        </para></listitem>
+                </itemizedlist>
+            </para>
 
-        <para>
-            Package feeds are an intermediary step in the build process.
-            BitBake generates packages whose type is defined by the
-            <link linkend='var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></link>
-            variable.
-            Before placing the packages into package feeds,
-            the build process validates them with generated output quality
-            assurance checks through the
-            <link linkend='ref-classes-insane'><filename>insane.bbclass</filename></link>
-            class.
-        </para>
+            <para>
+                Package installation is under control of the package manager
+                (e.g. smart/rpm, opkg, or apt/dpkg) regardless of whether or
+                not package management is enabled for the target.
+                At the end of the process, if package management is not
+                enabled for the target, the package manager's data files
+                are deleted from the root filesystem.
+            </para>
 
-        <para>
-            The package feed area resides in
-            <filename>tmp/deploy</filename> of the Build Directory.
-            Folders are created that correspond to the package type
-            (IPK, DEB, or RPM) created.
-            Further organization is derived through the value of the
-            <link linkend='var-PACKAGE_ARCH'><filename>PACKAGE_ARCH</filename></link>
-            variable for each package.
-            For example, packages can exist for the i586 or qemux86
-            architectures.
-            The package files themselves reside within the appropriate
-            architecture folder.
-        </para>
+            <para>
+                During image generation, the build system attempts to run
+                all post-installation scripts.
+                Any that fail to run on the build host are run on the
+                target when the target system is first booted.
+                If you are using a
+                <ulink url='&YOCTO_DOCS_DEV_URL;#creating-a-read-only-root-filesystem'>read-only root filesystem</ulink>,
+                all the post installation scripts must succeed during the
+                package installation phase since the root filesystem cannot be
+                written into.
+            </para>
 
-        <para>
-            BitBake uses the <filename>do_package_write_*</filename> task to
-            place generated packages into the package holding area (e.g.
-            <filename>do_package_write_ipk</filename> for IPK packages).
-        </para>
+            <para>
+                During Optimization, optimizing processes are run across
+                the image.
+                These processes include <filename>mklibs</filename> and
+                <filename>prelink</filename>.
+                The <filename>mklibs</filename> process optimizes the size
+                of the libraries.
+                A <filename>prelink</filename> process optimizes the dynamic
+                linking of shared libraries to reduce start up time of
+                executables.
+            </para>
+
+            <para>
+                Part of the image generation process includes compressing the
+                root filesystem image.
+                Compression is accomplished through several optimization
+                routines designed to reduce the overall size of the image.
+            </para>
+
+            <para>
+                After the root filesystem has been constructed, the image
+                generation process turns everything into an image file or
+                a set of image files.
+                The formats used for the root filesystem depend on the
+                <link linkend='var-IMAGE_FSTYPES'><filename>IMAGE_FSTYPES</filename></link>
+                variable.
+            </para>
+
+            <note>
+                The entire image generation process is run under Pseudo.
+                Running under Pseudo ensures that the files in the root
+                filesystem have correct ownership.
+            </note>
+        </section>
+
+        <section id='sdk-generation-dev-environment'>
+            <title>SDK Generation</title>
+
+            <para>
+                The OpenEmbedded build system uses BitBake to generate the
+                Software Development Kit (SDK) installer script:
+                <imagedata fileref="figures/sdk-generation.png" align="center" width="6in" depth="7in" />
+            </para>
+
+            <note>
+                For more information on the cross-development toolchain
+                generation, see the
+                "<link linkend='cross-development-toolchain-generation'>Cross-Development Toolchain Generation</link>"
+                section.
+            </note>
+
+            <para>
+                Like image generation, the SDK script process consists of
+                several stages and depends on many variables.
+                The <filename>do_populate_sdk</filename> task uses these
+                key variables to help create the list of packages to actually
+                install.
+                For information on the variables listed in the figure, see the
+                "<link linkend='sdk-dev-environment'>Application Development SDK</link>"
+                section.
+            </para>
+
+            <para>
+                The <filename>do_populate_sdk</filename> task handles two
+                parts: a target part and a host part.
+                The target part is the part built for the target hardware and
+                includes libraries and headers.
+                The host part is the part of the SDK that runs on the
+                <link linkend='var-SDKMACHINE'><filename>SDKMACHINE</filename></link>.
+            </para>
+
+            <para>
+                Once both parts are constructed, the
+                <filename>do_populate_sdk</filename> task performs some cleanup
+                on both parts.
+                After the cleanup, the task creates a cross-development
+                environment setup script and any configuration files that
+                might be needed.
+            </para>
+
+            <para>
+                The final output of the task is the Cross-development
+                toolchain installation script (<filename>.sh</filename> file),
+                which includes the environment setup script.
+            </para>
+        </section>
     </section>
 
     <section id='images-dev-environment'>
@@ -890,8 +1052,8 @@
         <para>
             The images produced by the OpenEmbedded build system
             are compressed forms of the
-            root filesystems that are ready to boot on a target device.
-            You can see from the 
+            root filesystem that are ready to boot on a target device.
+            You can see from the
             <link linkend='general-yocto-environment-figure'>general Yocto Project Development Environment figure</link>
             that BitBake output in part consists of images.
             This section is going to look more closely at this output:
@@ -900,20 +1062,24 @@
 
         <para>
             For a list of example images that the Yocto Project provides,
-            the
+            see the
             "<link linkend='ref-images'>Images</link>" chapter.
         </para>
 
         <para>
             Images are written out to the
             <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
-            inside the <filename>deploy/images</filename> folder as shown
-            in the figure.
+            inside the <filename>tmp/deploy/images/&lt;machine&gt;/</filename>
+            folder as shown in the figure.
             This folder contains any files expected to be loaded on the
             target device.
             The
             <link linkend='var-DEPLOY_DIR'><filename>DEPLOY_DIR</filename></link>
-            variable points to the <filename>deploy</filename> directory.
+            variable points to the <filename>deploy</filename> directory,
+            while the
+            <link linkend='var-DEPLOY_DIR_IMAGE'><filename>DEPLOY_DIR_IMAGE</filename></link>
+            variable points to the appropriate directory containing images for
+            the current configuration.
             <itemizedlist>
                 <listitem><para><filename>&lt;kernel-image&gt;</filename>:
                     A kernel binary file.
@@ -922,8 +1088,9 @@
                     kernel image file.
                     Depending on that variable, the file could begin with
                     a variety of naming strings.
-                    The <filename>deploy/images</filename> directory can
-                    contain multiple image files.</para></listitem>
+                    The <filename>deploy/images/&lt;machine&gt;</filename>
+                    directory can contain multiple image files for the
+                    machine.</para></listitem>
                 <listitem><para><filename>&lt;root-filesystem-image&gt;</filename>:
                     Root filesystems for the target device (e.g.
                     <filename>*.ext3</filename> or <filename>*.bz2</filename>
@@ -931,25 +1098,27 @@
                     The <link linkend='var-IMAGE_FSTYPES'><filename>IMAGE_FSTYPES</filename></link>
                     variable setting determines the root filesystem image
                     type.
-                    The <filename>deploy/images</filename> directory can
-                    contain multiple root filesystems.</para></listitem>
+                    The <filename>deploy/images/&lt;machine&gt;</filename>
+                    directory can contain multiple root filesystems for the
+                    machine.</para></listitem>
                 <listitem><para><filename>&lt;kernel-modules&gt;</filename>:
                     Tarballs that contain all the modules built for the kernel.
                     Kernel module tarballs exist for legacy purposes and
                     can be suppressed by setting the
                     <link linkend='var-MODULE_TARBALL_DEPLOY'><filename>MODULE_TARBALL_DEPLOY</filename></link>
                     variable to "0".
-                    The <filename>deploy/images</filename> directory can
-                    contain multiple kernel module tarballs.
-                    </para></listitem>
+                    The <filename>deploy/images/&lt;machine&gt;</filename>
+                    directory can contain multiple kernel module tarballs
+                    for the machine.</para></listitem>
                 <listitem><para><filename>&lt;bootloaders&gt;</filename>:
                     Bootloaders supporting the image, if applicable to the
                     target machine.
-                    The <filename>deploy/images</filename> directory can
-                    contain multiple bootloaders.
-                    </para></listitem>
+                    The <filename>deploy/images/&lt;machine&gt;</filename>
+                    directory can contain multiple bootloaders for the
+                    machine.</para></listitem>
                 <listitem><para><filename>&lt;symlinks&gt;</filename>:
-                    The <filename>deploy/images</filename> folder contains
+                    The <filename>deploy/images/&lt;machine&gt;</filename>
+                    folder contains
                     a symbolic link that points to the most recently built file
                     for each machine.
                     These links might be useful for external scripts that
@@ -963,7 +1132,7 @@
         <title>Application Development SDK</title>
 
         <para>
-            In the 
+            In the
             <link linkend='general-yocto-environment-figure'>general Yocto Project Development Environment figure</link>,
             the output labeled "Application Development SDK" represents an
             SDK.

documentation/ref-manual/faq.xml

@@ -31,31 +31,19 @@
     <qandaentry>
         <question>
             <para>
-                I only have Python 2.4 or 2.5 but BitBake requires Python 2.6 or 2.7.
+                My development system does not have Python 2.7.3 or greater,
+                which the Yocto Project requires.
                 Can I still use the Yocto Project?
             </para>
         </question>
         <answer>
             <para>
-                You can use a stand-alone tarball to provide Python 2.6.
-                You can find pre-built 32 and 64-bit versions of Python 2.6 at the following locations:
-                <itemizedlist>
-                    <listitem><para><ulink url='&YOCTO_PYTHON-i686_DL_URL;'>32-bit tarball</ulink></para></listitem>
-                    <listitem><para><ulink url='&YOCTO_PYTHON-x86_64_DL_URL;'>64-bit tarball</ulink></para></listitem>
-                </itemizedlist>
-            </para>
-            <para>
-                These tarballs are self-contained with all required libraries and should work
-                on most Linux systems.
-                To use the tarballs extract them into the root
-                directory and run the appropriate command:
-                <literallayout class='monospaced'>
-     $ export PATH=/opt/poky/sysroots/i586-pokysdk-linux/usr/bin/:$PATH
-     $ export PATH=/opt/poky/sysroots/x86_64-pokysdk-linux/usr/bin/:$PATH
-                </literallayout>
-            </para>
-            <para>
-                Once you run the command, BitBake uses Python 2.6.
+                You can get the required tools on your host development
+                system a couple different ways (i.e. building a tarball or
+                downloading a tarball).
+                See the
+                "<link linkend='required-git-tar-and-python-versions'>Required Git, tar, and Python Versions</link>"
+                section for steps on how to update your build tools.
             </para>
         </answer>
     </qandaentry>
@@ -211,7 +199,7 @@
         </answer>
     </qandaentry>
 
-    <qandaentry>
+<!--    <qandaentry>
         <question>
             <para>
                 How do I make the Yocto Project work in RHEL/CentOS?
@@ -258,7 +246,7 @@
                 Wiki page.</para>
             </note>
         </answer>
-    </qandaentry>
+    </qandaentry> -->
 
     <qandaentry>
         <question>
@@ -682,7 +670,7 @@
             <para>
                 Yes - you can easily do this.
                 When you use BitBake to build an image, all the build output
-                goes into the directory created when you run the 
+                goes into the directory created when you run the
                 build environment setup script (i.e.
                 <link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>
                 or

documentation/ref-manual/introduction.xml

@@ -121,11 +121,6 @@
                 </para>
 
                 <para>
-                    Refer to
-                    <ulink url='&OE_HOME_URL;/index.php?title=OEandYourDistro'>OE and Your Distro</ulink> and
-                    <ulink url='&OE_HOME_URL;/index.php?title=Required_software'>Required Software</ulink>
-                    for information for information about dependencies and
-                    requirements.
                     If you encounter problems, please go to
                     <ulink url='&YOCTO_BUGZILLA_URL;'>Yocto Project Bugzilla</ulink>
                     and submit a bug.
@@ -133,17 +128,26 @@
                 </para>
             </note>
             <itemizedlist>
-                <listitem><para>Ubuntu 10.04</para></listitem>
-                <listitem><para>Ubuntu 11.10</para></listitem>
+<!--                <listitem><para>Ubuntu 10.04</para></listitem>
+                <listitem><para>Ubuntu 11.10</para></listitem> -->
                 <listitem><para>Ubuntu 12.04 (LTS)</para></listitem>
                 <listitem><para>Ubuntu 12.10</para></listitem>
                 <listitem><para>Ubuntu 13.04</para></listitem>
-                <listitem><para>Fedora release 17 (Beefy Miracle)</para></listitem>
+<!--                <listitem><para>Fedora 16 (Verne)</para></listitem>
+                <listitem><para>Fedora 17 (Spherical)</para></listitem> -->
                 <listitem><para>Fedora release 18 (Spherical Cow)</para></listitem>
-                <listitem><para>CentOS release 6.3 (Final)</para></listitem>
-                <listitem><para>CentOS release 6.4 (Final)</para></listitem>
-                <listitem><para>Debian GNU/Linux 6.0 (Squeeze)</para></listitem>
+                <listitem><para>Fedora release 19 (Schrödinger's Cat)</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>CentOS release 6.4</para></listitem>
+<!--                <listitem><para>Debian GNU/Linux 6.0 (Squeeze)</para></listitem> -->
+                <listitem><para>Debian GNU/Linux 6.0.7 (Squeeze)</para></listitem>
                 <listitem><para>Debian GNU/Linux 7.0 (Wheezy)</para></listitem>
+                <listitem><para>Debian GNU/Linux 7.1 (Wheezy)</para></listitem>
+<!--                <listitem><para>openSUSE 11.4</para></listitem>
+                <listitem><para>openSUSE 12.1</para></listitem> -->
                 <listitem><para>openSUSE 12.2</para></listitem>
                 <listitem><para>openSUSE 12.3</para></listitem>
             </itemizedlist>
@@ -242,11 +246,11 @@
         </section>
 
         <section id='opensuse-packages'>
-            <title>OpenSUSE Packages</title>
+            <title>openSUSE Packages</title>
 
             <para>
                 The following list shows the required packages by function
-                given a supported OpenSUSE Linux distribution:
+                given a supported openSUSE Linux distribution:
                 <itemizedlist>
                     <listitem><para><emphasis>Essentials:</emphasis>
                         Packages needed to build an image for a headless
@@ -281,11 +285,17 @@
             <para>
                 The following list shows the required packages by function
                 given a supported CentOS Linux distribution:
-                <note>Depending on the CentOS version you are using, other requirements
-                    and dependencies might exist.
-                    For details, you should look at the CentOS sections on the
-                    <ulink url='https://wiki.yoctoproject.org/wiki/Poky/GettingStarted/Dependencies'>Poky/GettingStarted/Dependencies</ulink>
-                    wiki page.
+                <note>
+                    For CentOS 6.x, some of the versions of the components
+                    provided by the distribution are too old (e.g. Git, Python,
+                    and tar).
+                    It is recommended that you install the buildtools in order
+                    to provide versions that will work with the OpenEmbedded
+                    build system.
+                    For information on how to install the buildtools tarball,
+                    see the
+                    "<link linkend='required-git-tar-and-python-versions'>Required Git, Tar, and Python Versions</link>"
+                    section.
                 </note>
                 <itemizedlist>
                     <listitem><para><emphasis>Essentials:</emphasis>
@@ -337,8 +347,8 @@
             you can resolve this by either downloading a pre-built tarball
             containing these tools, or building such a tarball on another
             system.
-            Regardless of the method, once you have the tarball you simply
-            install it somewhere on you system, such as a directory in your
+            Regardless of the method, once you have the tarball, you simply
+            install it somewhere on your system, such as a directory in your
             home directory, and then source the environment script provided,
             which adds the tools into <filename>PATH</filename> and sets
             any other environment variables required to run the tools.
@@ -349,7 +359,7 @@
         <para>
             If downloading a pre-built tarball, locate the
             <filename>*.sh</filename> at
-            <ulink url='&YOCTO_DL_URL;/releases/yocto/yocto-1.5/buildtools/'></ulink>.
+            <ulink url='&YOCTO_DL_URL;/releases/yocto/yocto-&DISTRO;/buildtools/'></ulink>.
         </para>
 
         <para>
@@ -362,7 +372,7 @@
                 variable determines whether you build tools for a 32-bit
                 or 64-bit system.
             </note>
-            Once the build completes, you can find the file that installs the
+            Once the build completes, you can find the file that installs
             the tools in the <filename>tmp/deploy/sdk</filename> subdirectory
             of the
             <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.

documentation/ref-manual/migration.xml

@@ -34,7 +34,7 @@
             <para>
                 The shared state cache (sstate-cache), as pointed to by
                 <link linkend='var-SSTATE_DIR'><filename>SSTATE_DIR</filename></link>, by default
-                now has two-character subdirectories to prevent issues rising
+                now has two-character subdirectories to prevent issues arising
                 from too many files in the same directory.
                 Also, native sstate-cache packages will go into a subdirectory named using
                 the distro ID string.
@@ -157,7 +157,7 @@
                 <link linkend='var-LIC_FILES_CHKSUM'><filename>LIC_FILES_CHKSUM</filename></link>,
                 and so forth.
                 See the
-                "<link linkend='ref-classes-packagegroup'>Package Groups - packagegroup.bbclass</link>"
+                "<link linkend='ref-classes-packagegroup'><filename>packagegroup.bbclass</filename></link>"
                 section for further details.
             </para>
         </section>
@@ -580,6 +580,509 @@
         </para>
     </section>
 </section>
+
+<section id='moving-to-the-yocto-project-1.5-release'>
+    <title>Moving to the Yocto Project 1.5 Release</title>
+
+    <para>
+        This section provides migration information for moving to the
+        Yocto Project 1.5 Release from the prior release.
+    </para>
+
+    <section id='migration-1.5-host-dependency-changes'>
+        <title>Host Dependency Changes</title>
+
+        <para>
+            The OpenEmbedded build system now has some additional requirements
+            on the host system:
+            <itemizedlist>
+                <listitem><para>Python 2.7.3+</para></listitem>
+                <listitem><para>Tar 1.24+</para></listitem>
+                <listitem><para>Git 1.7.5+</para></listitem>
+                <listitem><para>Patched version of Make if you are using
+                    3.82.
+                    Most distributions that provide Make 3.82 use the patched
+                    version.</para></listitem>
+            </itemizedlist>
+            If the Linux distribution you are using on your build host
+            does not provide packages for these, you can install and use
+            the Buildtools tarball, which provides an SDK-like environment
+            containing them.
+        </para>
+
+        <para>
+            For more information on this requirement, see the
+            "<link linkend='required-git-tar-and-python-versions'>Required Git, tar, and Python Versions</link>"
+            section.
+        </para>
+    </section>
+
+    <section id='migration-1.5-atom-pc-bsp'>
+        <title><filename>atom-pc</filename> Board Support Package (BSP)</title>
+
+        <para>
+            The <filename>atom-pc</filename> hardware reference BSP has been
+            replaced by a <filename>genericx86</filename> BSP.
+            This BSP is not necessarily guaranteed to work on all x86
+            hardware, but it will run on a wider range of systems than the
+            <filename>atom-pc</filename> did.
+            <note>
+                Additionally, a <filename>genericx86-64</filename> BSP has been
+                added for 64-bit systems.
+            </note>
+        </para>
+    </section>
+
+    <section id='migration-1.5-bitbake'>
+        <title>BitBake</title>
+
+        <para>
+            The following changes have been made that relate to BitBake:
+            <itemizedlist>
+                <listitem><para>
+                    BitBake now supports a <filename>_remove</filename>
+                    operator.
+                    The addition of this operator means you will have to
+                    rename any items in recipe space (functions, variables)
+                    whose names currently contain
+                    <filename>_remove_</filename> or end with
+                    <filename>_remove</filename> to avoid unexpected behavior.
+                    </para></listitem>
+                <listitem><para>
+                    BitBake's global method pool has been removed.
+                    This method is not particularly useful and led to clashes
+                    between recipes containing functions that had the
+                    same name.</para></listitem>
+                <listitem><para>
+                    The "none" server backend has been removed.
+                    The "process" server backend has been serving well as the
+                    default for a long time now.</para></listitem>
+                <listitem><para>
+                    The <filename>bitbake-runtask</filename> script has been
+                    removed.</para></listitem>
+                <listitem><para>
+                    <filename>${</filename><link linkend='var-P'><filename>P</filename></link><filename>}</filename>
+                    and
+                    <filename>${</filename><link linkend='var-PF'><filename>PF</filename></link><filename>}</filename>
+                    are no longer added to
+                    <link linkend='var-PROVIDES'><filename>PROVIDES</filename></link>
+                    by default in <filename>bitbake.conf</filename>.
+                    These version-specific <filename>PROVIDES</filename>
+                    items were seldom used.
+                    Attempting to use them could result in two versions being
+                    built simultaneously rather than just one version due to
+                    the way BitBake resolves dependencies.</para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-1.5-qa-warnings'>
+        <title>QA Warnings</title>
+
+        <para>
+            The following changes have been made to the package QA checks:
+            <itemizedlist>
+                <listitem><para>
+                    If you have customized
+                    <link linkend='var-ERROR_QA'><filename>ERROR_QA</filename></link>
+                    or <link linkend='var-WARN_QA'><filename>WARN_QA</filename></link>
+                    values in your configuration, check that they contain all of
+                    the issues that you wish to be reported.
+                    Previous Yocto Project versions contained a bug that meant
+                    that any item not mentioned in <filename>ERROR_QA</filename>
+                    or <filename>WARN_QA</filename> would be treated as a
+                    warning.
+                    Consequently, several important items were not already in
+                    the default value of <filename>WARN_QA</filename>.
+                    All of the possible QA checks are now documented in the
+                    "<link linkend='ref-classes-insane'><filename>insane.bbclass</filename></link>"
+                    section.</para></listitem>
+                <listitem><para>
+                    An additional QA check has been added to check if
+                    <filename>/usr/share/info/dir</filename> is being installed.
+                    Your recipe should delete this file within
+                    <filename>do_install</filename> if "make install" is
+                    installing it.</para></listitem>
+                <listitem><para>
+                    If you are using the buildhistory class, the check for the
+                    package version going backwards is now controlled using a
+                    standard QA check.
+                    Thus, if you have customized your
+                    <filename>ERROR_QA</filename> or
+                    <filename>WARN_QA</filename> values and still wish to have
+                    this check performed, you should add
+                    "version-going-backwards" to your value for one or the
+                    other variables depending on how you wish it to be handled.
+                    See the documented QA checks in the
+                    "<link linkend='ref-classes-insane'><filename>insane.bbclass</filename></link>"
+                    section.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-1.5-directory-layout-changes'>
+        <title>Directory Layout Changes</title>
+
+        <para>
+            The following directory changes exist:
+            <itemizedlist>
+                <listitem><para>
+                    Output SDK installer files are now named to include the
+                    image name and tuning architecture through the
+                    <link linkend='var-SDK_NAME'><filename>SDK_NAME</filename></link>
+                    variable.</para></listitem>
+                <listitem><para>
+                    Images and related files are now installed into a directory
+                    that is specific to the machine, instead of a parent
+                    directory containing output files for multiple machines.
+                    The
+                    <link linkend='var-DEPLOY_DIR_IMAGE'><filename>DEPLOY_DIR_IMAGE</filename></link>
+                    variable continues to point to the directory containing
+                    images for the current
+                    <link linkend='var-MACHINE'><filename>MACHINE</filename></link>
+                    and should be used anywhere there is a need to refer to
+                    this directory.
+                    The <filename>runqemu</filename> script now uses this
+                    variable to find images and kernel binaries and will use
+                    BitBake to determine the directory.
+                    Alternatively, you can set the
+                    <filename>DEPLOY_DIR_IMAGE</filename> variable in the
+                    external environment.</para></listitem>
+                <listitem><para>
+                    When buildhistory is enabled, its output is now written
+                    under the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
+                    rather than
+                    <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link>.
+                    Doing so makes it easier to delete
+                    <filename>TMPDIR</filename> and preserve the build history.
+                    Additionally, data for produced SDKs is now split by
+                    <link linkend='var-IMAGE_NAME'><filename>IMAGE_NAME</filename></link>.
+                    </para></listitem>
+                <listitem><para>
+                    The <filename>pkgdata</filename> directory produced as
+                    part of the packaging process has been collapsed into a
+                    single machine-specific directory.
+                    This directory is located under
+                    <filename>sysroots</filename> and uses a machine-specific
+                    name (i.e.
+                    <filename>tmp/sysroots/&lt;machine&gt;/pkgdata</filename>).
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-1.5-shortened-git-srcrev-values'>
+        <title>Shortened Git <filename>SRCREV</filename> Values</title>
+
+        <para>
+            BitBake will now shorten revisions from Git repositories from the
+            normal 40 characters down to 10 characters within
+            <link linkend='var-SRCPV'><filename>SRCPV</filename></link>
+            for improved usability in path and file names.
+            This change should be safe within contexts where these revisions
+            are used because the chances of spatially close collisions
+            is very low.
+            Distant collisions are not a major issue in the way
+            the values are used.
+        </para>
+    </section>
+
+    <section id='migration-1.5-image-features'>
+        <title><filename>IMAGE_FEATURES</filename></title>
+
+        <para>
+            The following changes have been made that relate to
+            <link linkend='var-IMAGE_FEATURES'><filename>IMAGE_FEATURES</filename></link>:
+            <itemizedlist>
+                <listitem><para>
+                    The value of
+                    <link linkend='var-IMAGE_FEATURES'><filename>IMAGE_FEATURES</filename></link>
+                    is now validated to ensure invalid feature items are not
+                    added.
+                    Some users mistakenly add package names to this variable
+                    instead of using
+                    <link linkend='var-IMAGE_INSTALL'><filename>IMAGE_INSTALL</filename></link>
+                    in order to have the package added to the image, which does
+                    not work.
+                    This change is intended to catch those kinds of situations.
+                    Valid <filename>IMAGE_FEATURES</filename> are drawn from
+                    <link linkend='var-PACKAGE_GROUP'><filename>PACKAGE_GROUP</filename></link>
+                    definitions,
+                    <link linkend='var-COMPLEMENTARY_GLOB'><filename>COMPLEMENTARY_GLOB</filename></link>
+                    and a new "validitems" varflag on
+                    <filename>IMAGE_FEATURES</filename>.
+                    The "validitems" varflag change allows additional features
+                    to be added if they are not provided using the previous
+                    two mechanisms.
+                    </para></listitem>
+                <listitem><para>
+                    The previously deprecated "apps-console-core"
+                    <filename>IMAGE_FEATURES</filename> item is no longer
+                    supported.
+                    Add "splash" to <filename>IMAGE_FEATURES</filename> if you
+                    wish to have the splash screen enabled, since this is
+                    all that apps-console-core was doing.</para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-1.5-run'>
+        <title><filename>run</filename></title>
+
+        <para>
+            The <filename>run</filename> directory from the Filesystem
+            Hierarchy Standard 3.0 has been introduced.
+            You can find some of the implications for this change
+            <ulink url='http://cgit.openembedded.org/openembedded-core/commit/?id=0e326280a15b0f2c4ef2ef4ec441f63f55b75873'>here</ulink>.
+            The change also means that recipes that install files to
+            <filename>/var/run</filename> must be changed.
+            You can find a guide on how to make these changes
+            <ulink url='http://permalink.gmane.org/gmane.comp.handhelds.openembedded/58530'>here</ulink>.
+        </para>
+    </section>
+
+    <section id='migration-1.5-removal-of-package-manager-database-within-image-recipes'>
+        <title>Removal of Package Manager Database Within Image Recipes</title>
+
+        <para>
+            The image <filename>core-image-minimal</filename> no longer adds
+            <filename>remove_packaging_data_files</filename> to
+            <link linkend='var-ROOTFS_POSTPROCESS_COMMAND'><filename>ROOTFS_POSTPROCESS_COMMAND</filename></link>.
+            This addition is now handled automatically when "package-management"
+            is not in
+            <link linkend='var-IMAGE_FEATURES'><filename>IMAGE_FEATURES</filename></link>.
+            If you have custom image recipes that make this addition,
+            you should remove the lines, as they are not needed and might
+            interfere with correct operation of postinstall scripts.
+        </para>
+    </section>
+
+    <section id='migration-1.5-images-now-rebuild-only-on-changes-instead-of-every-time'>
+        <title>Images Now Rebuild Only on Changes Instead of Every Time</title>
+
+        <para>
+            The <filename>do_rootfs</filename> and other related image
+            construction tasks are no longer marked as "nostamp".
+            Consequently, they will only be re-executed when their inputs have
+            changed.
+            Previous versions of the OpenEmbedded build system always rebuilt
+            the image when requested rather when necessary.
+        </para>
+    </section>
+
+    <section id='migration-1.5-task-recipes'>
+        <title>Task Recipes</title>
+
+        <para>
+            The previously deprecated <filename>task.bbclass</filename> has
+            now been dropped.
+            For recipes that previously inherited from this task, you should
+            rename them from <filename>task-*</filename> to
+            <filename>packagegroup-*</filename> and inherit packagegroup
+            instead.
+        </para>
+
+        <para>
+            For more information, see the
+            "<link linkend='ref-classes-packagegroup'><filename>packagegroup.bbclass</filename></link>"
+            section.
+        </para>
+    </section>
+
+    <section id='migration-1.5-busybox'>
+        <title>BusyBox</title>
+
+        <para>
+            By default, we now split BusyBox into two binaries:
+            one that is suid root for those components that need it, and
+            another for the rest of the components.
+            Splitting BusyBox allows for optimization that eliminates the
+            <filename>tinylogin</filename> recipe as recommended by upstream.
+            You can disable this split by setting
+            <link linkend='var-BUSYBOX_SPLIT_SUID'><filename>BUSYBOX_SPLIT_SUID</filename></link>
+            to "0".
+        </para>
+    </section>
+
+    <section id='migration-1.5-automated-image-testing'>
+        <title>Automated Image Testing</title>
+
+        <para>
+            A new automated image testing framework has been added
+            through the
+            <link linkend='ref-classes-testimage'><filename>testimage*.bbclass</filename></link>
+            class.
+            This framework replaces the older
+            <filename>imagetest-qemu</filename> framework.
+        </para>
+
+        <para>
+            You can learn more about performing automated image tests in the
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing'>Performing Automated Runtime Testing</ulink>"
+            section.
+        </para>
+    </section>
+
+    <section id='migration-1.5-build-history'>
+        <title>Build History</title>
+
+        <para>
+            Following are changes to Build History:
+            <itemizedlist>
+                <listitem><para>
+                     Installed package sizes:
+                     <filename>installed-package-sizes.txt</filename> for an
+                     image now records the size of the files installed by each
+                     package instead of the size of each compressed package
+                     archive file.</para></listitem>
+                <listitem><para>
+                    The dependency graphs (<filename>depends*.dot</filename>)
+                    now use the actual package names instead of replacing
+                    dashes, dots and plus signs with underscores.
+                    </para></listitem>
+                <listitem><para>
+                    The <filename>buildhistory-diff</filename> and
+                    <filename>buildhistory-collect-srcrevs</filename>
+                    utilities have improved command-line handling.
+                    Use the <filename>&dash;&dash;help</filename> option for
+                    each utility for more information on the new syntax.
+                    </para></listitem>
+            </itemizedlist>
+            For more information on Build History, see the
+            "<link linkend='maintaining-build-output-quality'>Maintaining Build Output Quality</link>"
+            section.
+        </para>
+    </section>
+
+    <section id='migration-1.5-udev'>
+        <title><filename>udev</filename></title>
+
+        <para>
+            Following are changes to <filename>udev</filename>:
+            <itemizedlist>
+                <listitem><para>
+                    <filename>udev</filename> no longer brings in
+                    <filename>udev-extraconf</filename> automatically
+                    through
+                    <link linkend='var-RRECOMMENDS'><filename>RRECOMMENDS</filename></link>,
+                    since this was originally intended to be optional.
+                    If you need the extra rules, then add
+                    <filename>udev-extraconf</filename> to your image.
+                    </para></listitem>
+                <listitem><para>
+                    <filename>udev</filename> no longer brings in
+                    <filename>pciutils-ids</filename> or
+                    <filename>usbutils-ids</filename> through
+                    <filename>RRECOMMENDS</filename>.
+                    These are not needed by <filename>udev</filename> itself
+                    and removing them saves around 350KB.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='removed-renamed-recipes'>
+        <title>Removed and Renamed Recipes</title>
+
+        <itemizedlist>
+            <listitem><para>
+                The <filename>linux-yocto</filename> 3.2 kernel has been
+                removed.</para></listitem>
+            <listitem><para>
+                <filename>libtool-nativesdk</filename> has been renamed to
+                <filename>nativesdk-libtool</filename>.</para></listitem>
+            <listitem><para>
+                <filename>tinylogin</filename> has been removed.
+                It has been replaced by a suid portion of Busybox.
+                See the
+                "<link linkend='migration-1.5-busybox'>BusyBox</link>" section
+                for more information.</para></listitem>
+            <listitem><para>
+                <filename>external-python-tarball</filename> has been renamed
+                to <filename>buildtools-tarball</filename>.
+                </para></listitem>
+            <listitem><para>
+                <filename>web-webkit</filename> has been removed.
+                It has been functionally replaced by
+                <filename>midori</filename>.</para></listitem>
+            <listitem><para>
+                <filename>imake</filename> has been removed.
+                It is no longer needed by any other recipe.
+                </para></listitem>
+            <listitem><para>
+                <filename>transfig-native</filename> has been removed.
+                It is no longer needed by any other recipe.
+                </para></listitem>
+            <listitem><para>
+                <filename>anjuta-remote-run</filename> has been removed.
+                Anjuta IDE integration has not been officially supported for
+                several releases.</para></listitem>
+        </itemizedlist>
+    </section>
+
+    <section id='migration-1.5-other-changes'>
+        <title>Other Changes</title>
+
+        <para>
+            Following is a list of short entries describing other changes:
+            <itemizedlist>
+                <listitem><para>
+                    <filename>run-postinsts</filename>: Make this generic.
+                    </para></listitem>
+                <listitem><para>
+                    <filename>base-files</filename>: Remove the unnecessary
+                    <filename>media/xxx</filename> directories.
+                    </para></listitem>
+                <listitem><para>
+                    <filename>alsa-state</filename>: Provide an empty
+                    <filename>asound.conf</filename> by default.
+                    </para></listitem>
+                <listitem><para>
+                    <filename>classes/image</filename>: Ensure
+                    <link linkend='var-BAD_RECOMMENDATIONS'><filename>BAD_RECOMMENDATIONS</filename></link>
+                    supports pre-renamed package names.</para></listitem>
+                <listitem><para>
+                    <filename>classes/rootfs_rpm</filename>: Implement
+                    <link linkend='var-BAD_RECOMMENDATIONS'><filename>BAD_RECOMMENDATIONS</filename></link>
+                    for RPM.</para></listitem>
+                <listitem><para>
+                    <filename>systemd</filename>: Remove
+                    <filename>systemd_unitdir</filename> if
+                    <filename>systemd</filename> is not in
+                    <link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link>.
+                    </para></listitem>
+                <listitem><para>
+                    <filename>systemd</filename>: Remove
+                    <filename>init.d</filename> dir if
+                    <filename>systemd</filename> unit file is present and
+                    <filename>sysvinit</filename> is not a distro feature.
+                    </para></listitem>
+                <listitem><para>
+                    <filename>libpam</filename>: Deny all services for the
+                    <filename>OTHER</filename> entries.
+                    </para></listitem>
+                <listitem><para>
+                    <filename>image.bbclass</filename>: Move
+                    <filename>runtime_mapping_rename</filename> to avoid
+                    conflict with <filename>multilib</filename>.
+                    See
+                    <ulink url='https://bugzilla.yoctoproject.org/show_bug.cgi?id=4993'><filename>YOCTO #4993</filename></ulink>
+                    in Bugzilla for more information.
+                    </para></listitem>
+                <listitem><para>
+                    <filename>linux-dtb</filename>: Use kernel build system
+                    to generate the <filename>dtb</filename> files.
+                    </para></listitem>
+                <listitem><para>
+                    <filename>kern-tools</filename>: Switch from guilt to
+                    new <filename>kgit-s2q</filename> tool.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+</section>
 </chapter>
 <!--
 vim: expandtab tw=80 ts=4

documentation/ref-manual/ref-bitbake.xml

@@ -23,7 +23,7 @@
     <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 
+        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>
@@ -222,7 +222,7 @@
         <para>
             As each task completes, a timestamp is written to the directory specified by the
             <filename><link linkend='var-STAMP'>STAMP</link></filename> variable.
-            On subsequent runs, BitBake looks within the <filename>/build/tmp/stamps</filename>
+            On subsequent runs, BitBake looks within the <filename>build/tmp/stamps</filename>
             directory and does not rerun
             tasks that are already completed unless a timestamp is found to be invalid.
             Currently, invalid timestamps are only considered on a per
@@ -320,76 +320,74 @@
 
         <screen>
 $ bitbake --help
-Usage: bitbake [options] [package ...]
+Usage: bitbake [options] [recipename/target ...]
 
-    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.
+    Executes the specified task (default is 'build') for a given set of target recipes (.bb files).
+    It is assumed there is a conf/bblayers.conf available in cwd or in BBPATH which
+    will provide the layer, BBFILES and other configuration information.
 
 Options:
   --version             show program's version number and exit
   -h, --help            show this help message and exit
   -b BUILDFILE, --buildfile=BUILDFILE
-                        execute the task against this .bb file, rather than a
-                        package from BBFILES. Does not handle any
-                        dependencies.
-  -k, --continue        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.
-  -a, --tryaltconfigs   continue with builds by trying to use alternative
+                        Execute tasks from a specific .bb recipe directly.
+                        WARNING: Does not handle any dependencies from other
+                        recipes.
+  -k, --continue        Continue as much as possible after an error. While the
+                        target that failed and anything depending on it cannot
+                        be built, as much as possible will be built before
+                        stopping.
+  -a, --tryaltconfigs   Continue with builds by trying to use alternative
                         providers where possible.
-  -f, --force           force run of specified cmd, regardless of stamp status
-  -c CMD, --cmd=CMD     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
+  -f, --force           Force the specified targets/task to run (invalidating
+                        any existing stamp file).
+  -c CMD, --cmd=CMD     Specify the task to execute. The exact options
+                        available depend on the metadata. Some examples might
+                        be 'compile' or 'populate_sysroot' or 'listtasks' may
+                        give a list of the tasks available.
   -C INVALIDATE_STAMP, --clear-stamp=INVALIDATE_STAMP
-                        Invalidate the stamp for the specified cmd such as
-                        'compile' and run the default task for the specified
-                        target(s)
+                        Invalidate the stamp for the specified task such as
+                        'compile' and then run the default task for the
+                        specified target(s).
   -r PREFILE, --read=PREFILE
-                        read the specified file before bitbake.conf
+                        Read the specified file before bitbake.conf.
   -R POSTFILE, --postread=POSTFILE
-                        read the specified file after bitbake.conf
-  -v, --verbose         output more chit-chat to the terminal
+                        Read the specified file after bitbake.conf.
+  -v, --verbose         Output more log message data to the terminal.
   -D, --debug           Increase the debug level. You can specify this more
                         than once.
-  -n, --dry-run         don't execute, just go through the motions
+  -n, --dry-run         Don't execute, just go through the motions.
   -S, --dump-signatures
-                        don't execute, just dump out the signature
-                        construction information
-  -p, --parse-only      quit after parsing the BB files (developers only)
-  -s, --show-versions   show current and preferred versions of all recipes
-  -e, --environment     show the global or per-package environment (this is
-                        what used to be bbread)
-  -g, --graphviz        emit the dependency trees of the specified packages in
-                        the dot syntax, and the pn-buildlist to show the build
-                        list
+                        Don't execute, just dump out the signature
+                        construction information.
+  -p, --parse-only      Quit after parsing the BB recipes.
+  -s, --show-versions   Show current and preferred versions of all recipes.
+  -e, --environment     Show the global or per-package environment complete
+                        with information about where variables were
+                        set/changed.
+  -g, --graphviz        Save dependency tree information for the specified
+                        targets in the dot syntax.
   -I EXTRA_ASSUME_PROVIDED, --ignore-deps=EXTRA_ASSUME_PROVIDED
                         Assume these dependencies don't exist and are already
                         provided (equivalent to ASSUME_PROVIDED). Useful to
                         make dependency graphs more appealing
   -l DEBUG_DOMAINS, --log-domains=DEBUG_DOMAINS
                         Show debug logging for the specified logging domains
-  -P, --profile         profile the command and print a report
-  -u UI, --ui=UI        userinterface to use
+  -P, --profile         Profile the command and save reports.
+  -u UI, --ui=UI        The user interface to use (e.g. knotty, hob, depexp).
   -t SERVERTYPE, --servertype=SERVERTYPE
-                        Choose which server to use, process or xmlrpc
+                        Choose which server to use, process or xmlrpc.
   --revisions-changed   Set the exit code depending on whether upstream
-                        floating revisions have changed or not
-  --server-only         Run bitbake without UI,  the frontend can connect with
-                        bitbake server itself
-  -B BIND, --bind=BIND  The name/address for the bitbake server to bind to
-  --no-setscene         Do not run any setscene tasks, forces builds
+                        floating revisions have changed or not.
+  --server-only         Run bitbake without a UI, only starting a server
+                        (cooker) process.
+  -B BIND, --bind=BIND  The name/address for the bitbake server to bind to.
+  --no-setscene         Do not run any setscene tasks. sstate will be ignored
+                        and everything needed, built.
   --remote-server=REMOTE_SERVER
-                        Connect to the specified server
-  -m, --kill-server     Terminate the remote server
-  --observe-only        Connect to a server as an observing-only client
+                        Connect to the specified server.
+  -m, --kill-server     Terminate the remote server.
+  --observe-only        Connect to a server as an observing-only client.
         </screen>
     </section>
 

documentation/ref-manual/ref-features.xml

@@ -3,7 +3,7 @@
 [<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <chapter id='ref-features'>
-    <title>Reference: Features</title>
+    <title>Features</title>
 
     <para>
         This chapter provides a reference of shipped machine and distro features
@@ -38,23 +38,34 @@
         Here is an example that discovers the recipes whose build is potentially
         changed based on a given feature:
         <literallayout class='monospaced'>
-     $ cd $HOME/poky
+     $ cd poky
      $ git grep 'contains.*MACHINE_FEATURES.*&lt;feature&gt;'
         </literallayout>
     </para>
 
     <section id='ref-features-distro'>
-        <title>Distro</title>
+        <title>Distro Features</title>
 
         <para>
             The items below are features you can use with
-            <link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link>.
-            Features do not have a one-to-one correspondence to packages, and they can
-            go beyond simply controlling the installation of a package or packages.
-            Sometimes a feature can influence how certain recipes are built.
-            For example, a feature might determine whether a particular configure option
-            is specified within <filename>do_configure</filename> for a particular
-            recipe.
+            <link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link>
+            to enable features across your distribution.
+            Features do not have a one-to-one correspondence to packages,
+            and they can go beyond simply controlling the installation of a
+            package or packages.
+            In most cases, the presence or absence of a feature translates to
+            the appropriate option supplied to the configure script during
+            <filename>do_configure</filename> for the recipes that optionally
+            support the feature.
+        </para>
+
+        <para>
+            Some distro features are also machine features.
+            These select features make sense to be controlled both at
+            the machine and distribution configuration level.
+            See the
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-COMBINED_FEATURES'><filename>COMBINED_FEATURES</filename></ulink>
+            variable for more information.
         </para>
 
         <para>
@@ -67,6 +78,9 @@
                     bluetooth support (integrated BT only).</para></listitem>
                 <listitem><para><emphasis>cramfs:</emphasis> Include CramFS
                     support.</para></listitem>
+                <listitem><para><emphasis>directfb:</emphasis>
+                    Include DirectFB support.
+                    </para></listitem>
                 <listitem><para><emphasis>ext2:</emphasis> Include tools for
                     supporting for devices with internal HDD/Microdrive for
                     storing files (instead of Flash only devices).
@@ -75,7 +89,7 @@
                     support.</para></listitem>
                 <listitem><para><emphasis>ipv6:</emphasis> Include IPv6 support.
                     </para></listitem>
-                <listitem><para><emphasis>irda:</emphasis> Include Irda support.
+                <listitem><para><emphasis>irda:</emphasis> Include IrDA support.
                     </para></listitem>
                 <listitem><para><emphasis>keyboard:</emphasis> Include keyboard
                     support (e.g. keymaps will be loaded during boot).
@@ -120,7 +134,7 @@
     </section>
 
     <section id='ref-features-machine'>
-        <title>Machine</title>
+        <title>Machine Features</title>
 
         <para>
             The items below are features you can use with
@@ -146,7 +160,7 @@
                     </para></listitem>
                 <listitem><para><emphasis>ext2:</emphasis> Hardware HDD or Microdrive
                     </para></listitem>
-                <listitem><para><emphasis>irda:</emphasis> Hardware has Irda support
+                <listitem><para><emphasis>irda:</emphasis> Hardware has IrDA support
                     </para></listitem>
                 <listitem><para><emphasis>keyboard:</emphasis> Hardware has a keyboard
                     </para></listitem>
@@ -171,7 +185,7 @@
     </section>
 
     <section id='ref-features-image'>
-        <title>Images</title>
+        <title>Image Features</title>
 
         <para>
             The contents of images generated by the OpenEmbedded build system can be controlled by the
@@ -194,7 +208,7 @@
                 <listitem><para><emphasis>doc-pkgs:</emphasis> Installs documentation packages for all packages
                     installed in a given image.</para></listitem>
                 <listitem><para><emphasis>nfs-server:</emphasis> Installs an NFS server.</para></listitem>
-                <listitem><para><emphasis>read-only-fsroot:</emphasis> Creates
+                <listitem><para><emphasis>read-only-rootfs:</emphasis> Creates
                     an image whose root filesystem is read-only.
                     See the
                     "<ulink url='&YOCTO_DOCS_DEV_URL;#creating-a-read-only-root-filesystem'>Creating a Read-Only Root Filesystem</ulink>"

documentation/ref-manual/ref-images.xml

@@ -90,14 +90,18 @@
         <listitem><para><emphasis><filename>core-image-clutter</filename>:</emphasis>
             An image with support for the Open GL-based toolkit Clutter, which enables development of
             rich and animated graphical user interfaces.</para></listitem>
-        <listitem><para><emphasis><filename>core-image-gtk-directfb</filename>:</emphasis>
-            An image that uses <filename>gtk+</filename> over <filename>directfb</filename>
-            instead of X11.
-            In order to build, this image requires specific distro configuration that enables
-            <filename>gtk</filename> over <filename>directfb</filename>.</para></listitem>
+        <listitem><para><emphasis><filename>core-image-directfb</filename>:</emphasis>
+            An image that uses <filename>directfb</filename> instead of X11.
+            </para></listitem>
         <listitem><para><emphasis><filename>core-image-x11</filename>:</emphasis>
             A very basic X11 image with a terminal.
             </para></listitem>
+        <listitem><para><emphasis><filename>core-image-weston</filename>:</emphasis>
+            An image that provides the Wayland protocol libraries and the
+            reference Weston compositor.
+            For more information, see the
+            "<link linkend='wayland'>Wayland</link>" section.
+            </para></listitem>
         <listitem><para><emphasis><filename>qt4e-demo-image</filename>:</emphasis>
             An image that launches into the demo application for the embedded
             (not based on X11) version of Qt.</para></listitem>

documentation/ref-manual/ref-manual.xml

@@ -69,9 +69,29 @@
             </revision>
             <revision>
                 <revnumber>1.5</revnumber>
-                <date>Sometime in 2013</date>
+                <date>October 2013</date>
                 <revremark>Released with the Yocto Project 1.5 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>1.5.1</revnumber>
+                <date>January 2014</date>
+                <revremark>Released with the Yocto Project 1.5.1 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.5.2</revnumber>
+                <date>May 2014</date>
+                <revremark>Released with the Yocto Project 1.5.2 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.5.3</revnumber>
+                <date>July 2014</date>
+                <revremark>Released with the Yocto Project 1.5.3 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.5.4</revnumber>
+                <date>December 2014</date>
+                <revremark>Released with the Yocto Project 1.5.4 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>
@@ -85,11 +105,10 @@
         the terms of the <ulink type="http" url="http://creativecommons.org/licenses/by-sa/2.0/uk/">Creative Commons Attribution-Share Alike 2.0 UK: England &amp; Wales</ulink> as published by Creative Commons.
       </para>
       <note>
-          Due to production processes, there could be differences between the Yocto Project
-          documentation bundled in the release tarball and the
-          <ulink url='&YOCTO_DOCS_REF_URL;'>Yocto Project Reference Manual</ulink> on
-          the <ulink url='&YOCTO_HOME_URL;'>Yocto Project</ulink> website.
-          For the latest version of this manual, see the manual on the website.
+          For the latest version of this manual associated with this
+          Yocto Project release, see the
+          <ulink url='&YOCTO_DOCS_REF_URL;'>Yocto Project Reference Manual</ulink>
+          from the Yocto Project website.
       </note>
     </legalnotice>
 

documentation/ref-manual/ref-structure.xml

@@ -39,23 +39,27 @@
 
         <para>
             This directory includes a copy of BitBake for ease of use.
-            The copy usually matches the current stable BitBake release from the BitBake project.
+            The copy usually matches the current stable BitBake release from
+            the BitBake project.
             BitBake, a
             <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
-            interpreter, reads the Yocto Project metadata and runs the tasks
+            interpreter, reads the Yocto Project Metadata and runs the tasks
             defined by that data.
-            Failures are usually from the metadata and not from BitBake itself.
+            Failures are usually from the Metadata and not from BitBake itself.
             Consequently, most users do not need to worry about BitBake.
         </para>
 
         <para>
-            When you run the <filename>bitbake</filename> command, the wrapper script in
-            <filename>scripts/</filename> is executed to run the main BitBake executable,
-            which resides in the <filename>bitbake/bin/</filename> directory.
-            Sourcing the <link linkend="structure-core-script"><filename>&OE_INIT_FILE;</filename></link>
-            script places the <filename>scripts</filename> and <filename>bitbake/bin</filename>
-            directories (in that order) into the shell's <filename>PATH</filename> environment
-            variable.
+            When you run the <filename>bitbake</filename> command, the
+            main BitBake executable, which resides in the
+            <filename>bitbake/bin/</filename> directory, starts.
+            Sourcing an environment setup script (e.g.
+            <link linkend="structure-core-script"><filename>&OE_INIT_FILE;</filename></link>
+            or
+            <link linkend="structure-memres-core-script"><filename>oe-init-build-env-memres</filename></link>)
+            places the <filename>scripts</filename> and
+            <filename>bitbake/bin</filename> directories (in that order) into
+            the shell's <filename>PATH</filename> environment variable.
         </para>
 
         <para>
@@ -74,7 +78,7 @@
             the source tree is combined with the output.
             The <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
             is created initially when you <filename>source</filename>
-            the OpenEmbedded build environment setup script 
+            the OpenEmbedded build environment setup script
             (i.e.
             <link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>
             or
@@ -97,7 +101,7 @@
     </section>
 
     <section id='handbook'>
-        <title><filename>documentation</filename></title>
+        <title><filename>documentation/</filename></title>
 
         <para>
             This directory holds the source for the Yocto Project documentation
@@ -105,7 +109,7 @@
             versions of the manuals.
             Each manual is contained in a sub-folder.
             For example, the files for this manual reside in
-            <filename>ref-manual</filename>.
+            the <filename>ref-manual/</filename> directory.
         </para>
     </section>
 
@@ -175,9 +179,9 @@
         </para>
 
         <para>
-            The <filename>scripts</filename> directory has useful scripts that assist contributing
-            back to the Yocto Project, such as <filename>create_pull_request</filename> and
-            <filename>send_pull_request</filename>.
+            The <filename>scripts</filename> directory has useful scripts that assist in contributing
+            back to the Yocto Project, such as <filename>create-pull-request</filename> and
+            <filename>send-pull-request</filename>.
         </para>
     </section>
 
@@ -185,9 +189,9 @@
         <title><filename>&OE_INIT_FILE;</filename></title>
 
         <para>
-            This script is one of two scripts that set up the OpenEmbedded build 
+            This script is one of two scripts that set up the OpenEmbedded build
             environment.
-            For information on the other script, see the 
+            For information on the other script, see the
             "<link linkend='structure-memres-core-script'><filename>oe-init-build-env-memres</filename></link>"
             section.
         </para>
@@ -196,7 +200,7 @@
             Running this script with the <filename>source</filename> command in
             a shell makes changes to <filename>PATH</filename> and sets other
             core BitBake variables based on the current working directory.
-            You need to run an environment setup script before running BitBake 
+            You need to run an environment setup script before running BitBake
             commands.
             The script uses other scripts within the
             <filename>scripts</filename> directory to do the bulk of the work.
@@ -205,7 +209,8 @@
         <para>
             By default, running this script without a
             <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
-            argument creates the <filename>build</filename> directory.
+            argument creates the <filename>build</filename> directory
+            in your current working directory.
             If you provide a Build Directory argument when you
             <filename>source</filename> the script, you direct the OpenEmbedded
             build system to create a Build Directory of your choice.
@@ -231,11 +236,11 @@
         <title><filename>oe-init-build-env-memres</filename></title>
 
         <para>
-            This script is one of two scripts that set up the OpenEmbedded build 
-            environment.
-            Setting up the environment with this script uses a 
-            memory-resident BitBake.
-            For information on the other setup script, see the 
+            This script is one of two scripts that set up the OpenEmbedded
+            build environment.
+            Aside from setting up the environment, this script starts a
+            memory-resident BitBake server.
+            For information on the other setup script, see the
             "<link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>"
             section.
         </para>
@@ -252,14 +257,14 @@
             Running this script with the <filename>source</filename> command in
             a shell makes changes to <filename>PATH</filename> and sets other
             core BitBake variables based on the current working directory.
-            One of these variables is the 
+            One of these variables is the
             <link linkend='var-BBSERVER'><filename>BBSERVER</filename></link>
-            variable, which allows the OpenEmbedded build system to locate 
+            variable, which allows the OpenEmbedded build system to locate
             the server that is running BitBake.
         </para>
 
         <para>
-            You need to run an environment setup script before running BitBake 
+            You need to run an environment setup script before using BitBake
             commands.
             Following is the script syntax:
             <literallayout class='monospaced'>
@@ -270,33 +275,34 @@
         </para>
 
         <para>
-            If you do not provide a port number with the script, the default
-            port "12345" is used.
+            If you do not provide a port number with the script, the
+            BitBake server at port "12345" is started.
         </para>
 
         <para>
             By default, running this script without a
             <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
-            argument creates the <filename>build</filename> directory.
+            argument creates a build directory named
+            <filename>build</filename>.
             If you provide a Build Directory argument when you
-            <filename>source</filename> the script, you direct the OpenEmbedded
-            build system to create a Build Directory of your choice.
-            For example, the following command uses the default port number
-            "12345" and creates a Build Directory named
+            <filename>source</filename> the script, the Build Directory is
+            created using that name.
+            For example, the following command starts the BitBake server using
+            the default port "12345" and creates a Build Directory named
             <filename>mybuilds</filename> that is outside of the
             <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>:
             <literallayout class='monospaced'>
      $ source oe-init-build-env-memres ~/mybuilds
             </literallayout>
             <note>
-                The OpenEmbedded build system does not support file or 
+                The OpenEmbedded build system does not support file or
                 directory names that contain spaces.
-                If you attempt to run the 
+                If you attempt to run the
                 <filename>oe-init-build-env-memres</filename> script
-                from a Source Directory that contains spaces in either the 
-                filenames or directory names, the script returns an error 
+                from a Source Directory that contains spaces in either the
+                filenames or directory names, the script returns an error
                 indicating no such file or directory.
-                Be sure to use a Source Directory free of names containing 
+                Be sure to use a Source Directory free of names containing
                 spaces.
             </note>
         </para>
@@ -321,81 +327,72 @@
         By default, this directory is named <filename>build</filename>.
     </para>
 
-    <section id='structure-build-pseudodone'>
-        <title><filename>build/pseudodone</filename></title>
-
-        <para>
-            This tag file indicates that the initial pseudo binary was created.
-            The file is built the first time BitBake is invoked.
-        </para>
-    </section>
-
     <section id='structure-build-conf-local.conf'>
         <title><filename>build/conf/local.conf</filename></title>
 
         <para>
-            This configuration file contains all the local user configurations 
+            This configuration file contains all the local user configurations
             for your build environment.
-            The <filename>local.conf</filename> file contains documentation on 
+            The <filename>local.conf</filename> file contains documentation on
             the various configuration options.
-            Any variable set here overrides any variable set elsewhere within 
-            the environment unless that variable is hard-coded within a file 
+            Any variable set here overrides any variable set elsewhere within
+            the environment unless that variable is hard-coded within a file
             (e.g. by using '=' instead of '?=').
-            Some variables are hard-coded for various reasons but these 
+            Some variables are hard-coded for various reasons but these
             variables are relatively rare.
         </para>
 
         <para>
-            Edit this file to set the 
+            Edit this file to set the
             <filename><link linkend='var-MACHINE'>MACHINE</link></filename>
             for which you want to build, which package types you wish to use
             (<link linkend='var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></link>),
-            the location from which you want to downloaded files
+            the location from which you want to access downloaded files
             (<filename><link linkend='var-DL_DIR'>DL_DIR</link></filename>),
             and how you want your host machine to use resources
-            (<link linkend='var-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename></link> 
+            (<link linkend='var-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename></link>
             and
             <link linkend='var-PARALLEL_MAKE'><filename>PARALLEL_MAKE</filename></link>).
         </para>
 
         <para>
-            If <filename>local.conf</filename> is not present when you 
-            start the build, the OpenEmbedded build system creates it from 
+            If <filename>local.conf</filename> is not present when you
+            start the build, the OpenEmbedded build system creates it from
             <filename>local.conf.sample</filename> when
-            you <filename>source</filename> the top-level build environment 
+            you <filename>source</filename> the top-level build environment
             setup script (i.e.
             <link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>
-            or 
+            or
             <link linkend='structure-memres-core-script'><filename>oe-init-build-env-memres</filename></link>).
         </para>
 
         <para>
-            The source <filename>local.conf.sample</filename> file used 
+            The source <filename>local.conf.sample</filename> file used
             depends on the <filename>$TEMPLATECONF</filename> script variable,
-            which defaults to <filename>/meta-yocto/conf</filename>
-            when you are building from the Yocto Project development 
-            environment and defaults to <filename>/meta/conf</filename> when 
+            which defaults to <filename>meta-yocto/conf</filename>
+            when you are building from the Yocto Project development
+            environment and defaults to <filename>meta/conf</filename> when
             you are building from the OpenEmbedded Core environment.
-            Because the script variable points to the source of the 
-            <filename>local.conf.sample</filename> file, this implies that 
-            you can configure your build environment from any layer by setting     
-            the variable in the top-level build environment setup script as 
+            Because the script variable points to the source of the
+            <filename>local.conf.sample</filename> file, this implies that
+            you can configure your build environment from any layer by setting
+            the variable in the top-level build environment setup script as
             follows:
             <literallayout class='monospaced'>
      TEMPLATECONF=&lt;your_layer&gt;/conf
             </literallayout>
-            Once the build process gets the sample file, it uses 
-            <filename>sed</filename> to substitute final 
-            <filename>${</filename><link linkend='var-OEROOT'><filename>OEROOT</filename></link><filename>}</filename> 
+            Once the build process gets the sample file, it uses
+            <filename>sed</filename> to substitute final
+            <filename>${</filename><link linkend='var-OEROOT'><filename>OEROOT</filename></link><filename>}</filename>
             values for all <filename>##OEROOT##</filename> values.
             <note>
                 You can see how the <filename>TEMPLATECONF</filename> variable
-                is used by looking at the       
-                <filename>/scripts/oe-setup-builddir</filename> script in the 
+                is used by looking at the
+                <filename>scripts/oe-setup-builddir</filename> script in the
                 <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
-                You can find the Yocto Project version of the 
-                <filename>local.conf.sample</filename> file in the 
-                <filename>/meta-yocto/conf</filename> directory.                
+                You can find the Yocto Project version of the
+                <filename>local.conf.sample</filename> file in the
+                <filename>meta-yocto/conf</filename> directory.
             </note>
         </para>
     </section>
@@ -408,48 +405,48 @@
             <ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>layers</ulink>,
             which are directory trees, traversed (or walked) by BitBake.
             The <filename>bblayers.conf</filename> file uses the
-            <link linkend='var-BBLAYERS'><filename>BBLAYERS</filename></link> 
+            <link linkend='var-BBLAYERS'><filename>BBLAYERS</filename></link>
             variable to list the layers BitBake tries to find, and uses the
             <link linkend='var-BBLAYERS_NON_REMOVABLE'><filename>BBLAYERS_NON_REMOVABLE</filename></link>
             variable to list layers that must not be removed.
         </para>
 
         <para>
-            If <filename>bblayers.conf</filename> is not present when you 
-            start the build, the OpenEmbedded build system creates it from 
+            If <filename>bblayers.conf</filename> is not present when you
+            start the build, the OpenEmbedded build system creates it from
             <filename>bblayers.conf.sample</filename> when
-            you <filename>source</filename> the top-level build environment 
+            you <filename>source</filename> the top-level build environment
             setup script (i.e.
             <link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>
-            or 
+            or
             <link linkend='structure-memres-core-script'><filename>oe-init-build-env-memres</filename></link>).
         </para>
 
         <para>
-            The source <filename>bblayers.conf.sample</filename> file used 
+            The source <filename>bblayers.conf.sample</filename> file used
             depends on the <filename>$TEMPLATECONF</filename> script variable,
-            which defaults to <filename>/meta-yocto/conf</filename>
-            when you are building from the Yocto Project development 
-            environment and defaults to <filename>/meta/conf</filename> when 
+            which defaults to <filename>meta-yocto/conf</filename>
+            when you are building from the Yocto Project development
+            environment and defaults to <filename>meta/conf</filename> when
             you are building from the OpenEmbedded Core environment.
-            Because the script variable points to the source of the 
-            <filename>bblayers.conf.sample</filename> file, this implies that 
+            Because the script variable points to the source of the
+            <filename>bblayers.conf.sample</filename> file, this implies that
             you can base your build from any layer by setting the variable in
             the top-level build environment setup script as follows:
             <literallayout class='monospaced'>
      TEMPLATECONF=&lt;your_layer&gt;/conf
             </literallayout>
-            Once the build process gets the sample file, it uses 
-            <filename>sed</filename> to substitute final 
-            <filename>${</filename><link linkend='var-OEROOT'><filename>OEROOT</filename></link><filename>}</filename> 
+            Once the build process gets the sample file, it uses
+            <filename>sed</filename> to substitute final
+            <filename>${</filename><link linkend='var-OEROOT'><filename>OEROOT</filename></link><filename>}</filename>
             values for all <filename>##OEROOT##</filename> values.
             <note>
                 You can see how the <filename>TEMPLATECONF</filename> variable
-                <filename>/scripts/oe-setup-builddir</filename> script in the 
+                <filename>scripts/oe-setup-builddir</filename> script in the
                 <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
-                You can find the Yocto Project version of the 
-                <filename>bblayers.conf.sample</filename> file in the 
-                <filename>/meta-yocto/conf</filename> directory.                
+                You can find the Yocto Project version of the
+                <filename>bblayers.conf.sample</filename> file in the
+                <filename>meta-yocto/conf</filename> directory.
             </note>
         </para>
     </section>
@@ -491,7 +488,7 @@
         <title><filename>build/tmp/</filename></title>
 
         <para>
-            This directory receives all the OpenEmbedded build system's output.
+            This directory receives all of the OpenEmbedded build system's output.
             BitBake creates this directory if it does not exist.
             As a last resort, to clean up a build and start it from scratch (other than the downloads),
             you can remove everything in the <filename>tmp</filename> directory or get rid of the
@@ -555,6 +552,15 @@
         </para>
     </section>
 
+    <section id='structure-build-tmp-deploy-ipk'>
+        <title><filename>build/tmp/deploy/ipk/</filename></title>
+
+        <para>
+            This directory receives <filename>.ipk</filename> packages produced by
+            the build process.
+        </para>
+    </section>
+
     <section id='structure-build-tmp-deploy-licenses'>
         <title><filename>build/tmp/deploy/licenses/</filename></title>
 
@@ -601,14 +607,6 @@
         </para>
     </section>
 
-    <section id='structure-build-tmp-deploy-ipk'>
-        <title><filename>build/tmp/deploy/ipk/</filename></title>
-
-        <para>
-            This directory receives <filename>.ipk</filename> packages produced by
-            the build process.</para>
-    </section>
-
     <section id='structure-build-tmp-sysroots'>
         <title><filename>build/tmp/sysroots/</filename></title>
 
@@ -650,15 +648,6 @@
         </para>
     </section>
 
-    <section id='structure-build-tmp-pkgdata'>
-        <title><filename>build/tmp/pkgdata/</filename></title>
-
-        <para>
-            This directory contains intermediate packaging data that is used later in the packaging process.
-            For more information, see the "<link linkend='ref-classes-package'>Packaging - package*.bbclass</link>" section.
-        </para>
-    </section>
-
     <section id='structure-build-tmp-work'>
         <title><filename>build/tmp/work/</filename></title>
 
@@ -790,7 +779,7 @@
             This directory contains common license files and several text files
             used by the build system.
             The text files contain minimal device information and
-            lists of files and directories with knows permissions.
+            lists of files and directories with known permissions.
         </para>
     </section>
 

documentation/ref-manual/technical-details.xml

@@ -60,9 +60,10 @@
             and is responsible for parsing the
             <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>,
             generating a list of tasks from it, and then executing those tasks.
-            To see a list of the options BitBake supports, use the following
-            help command:
+            To see a list of the options BitBake supports, use either of
+            the following commands:
             <literallayout class='monospaced'>
+     $ bitbake -h
      $ bitbake --help
             </literallayout>
         </para>
@@ -72,7 +73,7 @@
             <filename>packagename</filename> is the name of the package you want to build
             (referred to as the "target" in this manual).
             The target often equates to the first part of a <filename>.bb</filename> filename.
-            So, to run the <filename>matchbox-desktop_1.2.3.bb</filename> file, you
+            So, to process the <filename>matchbox-desktop_1.2.3.bb</filename> recipe file, you
             might type the following:
             <literallayout class='monospaced'>
      $ bitbake matchbox-desktop
@@ -111,14 +112,15 @@
         <para>
             The <filename>.bb</filename> files are usually referred to as "recipes."
             In general, a recipe contains information about a single piece of software.
-            The information includes the location from which to download the source patches
-            (if any are needed), which special configuration options to apply,
+            This information includes the location from which to download the
+            unaltered source, any source patches to be applied to that source
+            (if needed), which special configuration options to apply,
             how to compile the source files, and how to package the compiled output.
         </para>
 
         <para>
-            The term "package" can also be used to describe recipes.
-            However, since the same word is used for the packaged output from the OpenEmbedded
+            The term "package" is sometimes used to refer to recipes. However,
+            since the word "package" is used for the packaged output from the OpenEmbedded
             build system (i.e. <filename>.ipk</filename> or <filename>.deb</filename> files),
             this document avoids using the term "package" when referring to recipes.
         </para>
@@ -162,7 +164,7 @@
         <ulink url='&YOCTO_DOCS_DEV_URL;#cross-development-toolchain'>cross-development toolchains</ulink>.
         This section provides some technical background information on how
         cross-development toolchains are created and used.
-        For more information on these toolchain, you can also see the
+        For more information on toolchains, you can also see the
         <ulink url='&YOCTO_DOCS_ADT_URL;'>the Yocto Project Application Developer's Guide</ulink>.
     </para>
 
@@ -347,7 +349,7 @@
         As mentioned in the previous paragraph, building from scratch ensures that
         everything is current and starts from a known state.
         However, building from scratch also takes much longer as it generally means
-        rebuilding things that do not necessarily need rebuilt.
+        rebuilding things that do not necessarily need to be rebuilt.
     </para>
 
     <para>
@@ -355,10 +357,11 @@
         The implementation of the shared state code answers the following questions that
         were fundamental roadblocks within the OpenEmbedded incremental build support system:
         <itemizedlist>
-            <listitem>What pieces of the system have changed and what pieces have not changed?</listitem>
-            <listitem>How are changed pieces of software removed and replaced?</listitem>
-            <listitem>How are pre-built components that do not need to be rebuilt from scratch
-                used when they are available?</listitem>
+            <listitem><para>What pieces of the system have changed and what pieces have
+                not changed?</para></listitem>
+            <listitem><para>How are changed pieces of software removed and replaced?</para></listitem>
+            <listitem><para>How are pre-built components that do not need to be rebuilt from scratch
+                used when they are available?</para></listitem>
         </itemizedlist>
     </para>
 
@@ -397,16 +400,16 @@
 
         <para>
             When determining what parts of the system need to be built, BitBake
-            uses a per-task basis and does not use a per-recipe basis.
+            works on a per-task basis rather than a per-recipe basis.
             You might wonder why using a per-task basis is preferred over a per-recipe basis.
             To help explain, consider having the IPK packaging backend enabled and then switching to DEB.
             In this case, <filename>do_install</filename> and <filename>do_package</filename>
-            output are still valid.
+            outputs are still valid.
             However, with a per-recipe approach, the build would not include the
             <filename>.deb</filename> files.
             Consequently, you would have to invalidate the whole build and rerun it.
-            Rerunning everything is not the best situation.
-            Also in this case, the core must be "taught" much about specific tasks.
+            Rerunning everything is not the best solution.
+            Also, in this case, the core must be "taught" much about specific tasks.
             This methodology does not scale well and does not allow users to easily add new tasks
             in layers or as external recipes without touching the packaged-staging core.
         </para>
@@ -431,11 +434,11 @@
             the checksum.
             First, there is the actual specific build path of a given task -
             the <link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>.
-            It does not matter if the working directory changes because it should not
+            It does not matter if the work directory changes because it should not
             affect the output for target packages.
             Also, the build process has the objective of making native or cross packages relocatable.
             The checksum therefore needs to exclude <filename>WORKDIR</filename>.
-            The simplistic approach for excluding the working directory is to set
+            The simplistic approach for excluding the work directory is to set
             <filename>WORKDIR</filename> to some fixed value and create the checksum
             for the "run" script.
         </para>
@@ -512,17 +515,18 @@
             dependent task hashes can be influenced.
             Within the BitBake configuration file, we can give BitBake some extra information
             to help it construct the basehash.
-            The following statements effectively result in a list of global variable
+            The following statement effectively results in a list of global variable
             dependency excludes - variables never included in any checksum:
             <literallayout class='monospaced'>
-  BB_HASHBASE_WHITELIST ?= "TMPDIR FILE PATH PWD BB_TASKHASH BBPATH"
-  BB_HASHBASE_WHITELIST += "DL_DIR SSTATE_DIR THISDIR FILESEXTRAPATHS"
-  BB_HASHBASE_WHITELIST += "FILE_DIRNAME HOME LOGNAME SHELL TERM USER"
-  BB_HASHBASE_WHITELIST += "FILESPATH USERNAME STAGING_DIR_HOST STAGING_DIR_TARGET"
+     BB_HASHBASE_WHITELIST ?= "TMPDIR FILE PATH PWD BB_TASKHASH BBPATH DL_DIR \
+         SSTATE_DIR THISDIR FILESEXTRAPATHS FILE_DIRNAME HOME LOGNAME SHELL TERM \
+         USER FILESPATH STAGING_DIR_HOST STAGING_DIR_TARGET COREBASE PRSERV_HOST \
+         PRSERV_DUMPDIR PRSERV_DUMPFILE PRSERV_LOCKDOWN PARALLEL_MAKE \
+         CCACHE_DIR EXTERNAL_TOOLCHAIN CCACHE CCACHE_DISABLE LICENSE_PATH SDKPKGSUFFIX"
             </literallayout>
-            The previous example actually excludes
+            The previous example excludes
             <link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>
-            since it is actually constructed as a path within
+            since that variable is actually constructed as a path within
             <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link>, which is on
             the whitelist.
         </para>
@@ -541,7 +545,7 @@
             <filename>OE-Core</filename> uses the "OEBasicHash" signature handler by default
             through this setting in the <filename>bitbake.conf</filename> file:
             <literallayout class='monospaced'>
-  BB_SIGNATURE_HANDLER ?= "OEBasicHash"
+     BB_SIGNATURE_HANDLER ?= "OEBasicHash"
             </literallayout>
             The "OEBasicHash" <filename>BB_SIGNATURE_HANDLER</filename> is the same as the
             "OEBasic" version but adds the task hash to the stamp files.
@@ -550,7 +554,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.
+            values, and changes to Metadata automatically ripple across the build.
         </para>
 
         <para>
@@ -558,10 +562,10 @@
             make some dependency and hash information available to the build.
             This information includes:
             <literallayout class='monospaced'>
-  BB_BASEHASH_task-&lt;taskname&gt; - the base hashes for each task in the recipe
-  BB_BASEHASH_&lt;filename:taskname&gt; - the base hashes for each dependent task
-  BBHASHDEPS_&lt;filename:taskname&gt; - The task dependencies for each task
-  BB_TASKHASH - the hash of the currently running task
+     BB_BASEHASH_task-&lt;taskname&gt; - the base hashes for each task in the recipe
+     BB_BASEHASH_&lt;filename:taskname&gt; - the base hashes for each dependent task
+     BBHASHDEPS_&lt;filename:taskname&gt; - The task dependencies for each task
+     BB_TASKHASH - the hash of the currently running task
             </literallayout>
         </para>
     </section>
@@ -571,7 +575,7 @@
 
         <para>
             Checksums and dependencies, as discussed in the previous section, solve half the
-            problem.
+            problem of supporting a shared state.
             The other part of the problem is being able to use checksum information during the build
             and being able to reuse or rebuild specific components.
         </para>
@@ -581,7 +585,7 @@
             is a relatively generic implementation of how to "capture" a snapshot of a given task.
             The idea is that the build process does not care about the source of a task's output.
             Output could be freshly built or it could be downloaded and unpacked from
-            somewhere - the build process does not need to worry about its source.
+            somewhere - the build process does not need to worry about its origin.
         </para>
 
         <para>
@@ -598,7 +602,7 @@
             <filename>sstate.bbclass</filename>.
             From a user's perspective, adding shared state wrapping to a task
             is as simple as this <filename>do_deploy</filename> example taken from
-            <filename>do_deploy.bbclass</filename>:
+            <filename>deploy.bbclass</filename>:
             <literallayout class='monospaced'>
      DEPLOYDIR = "${WORKDIR}/deploy-${PN}"
      SSTATETASKS += "do_deploy"
@@ -610,8 +614,9 @@
          sstate_setscene(d)
      }
      addtask do_deploy_setscene
+     do_deploy[dirs] = "${DEPLOYDIR} ${B}"
             </literallayout>
-            In the example, we add some extra flags to the task, a name field ("deploy"), an
+            In this example, we add some extra flags to the task, a name field ("deploy"), an
             input directory where the task sends data, and the output
             directory where the data from the task should eventually be copied.
             We also add a <filename>_setscene</filename> variant of the task and add the task
@@ -730,43 +735,61 @@
             <title>Invalidating Shared State</title>
 
             <para>
-                The shared state code uses checksums and shared state
+                The OpenEmbedded build system uses checksums and shared state
                 cache to avoid unnecessarily rebuilding tasks.
+                Collectively, this scheme is known as "shared state code."
+            </para>
+
+            <para>
                 As with all schemes, this one has some drawbacks.
-                It is possible that you could make implicit changes that are not factored
-                into the checksum calculation, but do affect a task's output.
-                A good example is perhaps when a tool changes its output.
-                Assume that the output of <filename>rpmdeps</filename> needed to change.
+                It is possible that you could make implicit changes to your
+                code that the checksum calculations do not take into
+                account (i.e. implicit changes).
+                These implicit changes affect a task's output but do not trigger
+                the shared state code into rebuilding a recipe.
+                Consider an example during which a tool changes its output.
+                Assume that the output of <filename>rpmdeps</filename> changes.
                 The result of the change should be that all the
-                <filename>package</filename>, <filename>package_write_rpm</filename>,
-                and <filename>package_deploy-rpm</filename> shared state cache
-                items would become invalid.
-                But, because this is a change that is external to the code and therefore implicit,
-                the associated shared state cache items do not become invalidated.
-                In this case, the build process uses the cached items rather than running the
-                task again.
+                <filename>package</filename> and
+                <filename>package_write_rpm</filename> shared state cache
+                items become invalid.
+                However, because the change to the output is
+                external to the code and therefore implicit,
+                the associated shared state cache items do not become
+                invalidated.
+                In this case, the build process uses the cached items rather
+                than running the task again.
                 Obviously, these types of implicit changes can cause problems.
             </para>
 
             <para>
-                To avoid these problems during the build, you need to understand the effects of any
-                change you make.
-                Note that any changes you make directly to a function automatically are factored into
-                the checksum calculation and thus, will invalidate the associated area of sstate cache.
-                You need to be aware of any implicit changes that are not obvious changes to the
-                code and could affect the output of a given task.
-                Once you are aware of such changes, you can take steps to invalidate the cache
-                and force the tasks to run.
-                The steps to take are as simple as changing function's comments in the source code.
-                For example, to invalidate package shared state files, change the comment statements
-                of <filename>do_package</filename> or the comments of one of the functions it calls.
-                The change is purely cosmetic, but it causes the checksum to be recalculated and
-                forces the task to be run again.
+                To avoid these problems during the build, you need to
+                understand the effects of any changes you make.
+                Realize that changes you make directly to a function
+                are automatically factored into the checksum calculation.
+                Thus, these explicit changes invalidate the associated area of
+                sstate cache.
+                However, you need to be aware of any implicit changes that
+                are not obvious changes to the code and could affect the output
+                of a given task.
+            </para>
+
+            <para>
+                When you identify an implicit change, you can easily take steps
+                to invalidate the cache and force the tasks to run.
+                The steps you can take are as simple as changing a function's
+                comments in the source code.
+                For example, to invalidate package shared state files, change
+                the comment statements of <filename>do_package</filename> or
+                the comments of one of the functions it calls.
+                Even though the change is purely cosmetic, it causes the
+                checksum to be recalculated and forces the OpenEmbedded build
+                system to run the task again.
             </para>
 
             <note>
-                For an example of a commit that makes a cosmetic change to invalidate
-                a shared state, see this
+                For an example of a commit that makes a cosmetic change to
+                invalidate shared state, see this
                 <ulink url='&YOCTO_GIT_URL;/cgit.cgi/poky/commit/meta/classes/package.bbclass?id=737f8bbb4f27b4837047cb9b4fbfe01dfde36d54'>commit</ulink>.
             </note>
         </section>
@@ -868,7 +891,7 @@
 
     <para>
         <ulink url='http://en.wikipedia.org/wiki/Wayland_(display_server_protocol)#Weston'>Wayland</ulink>
-        is a computer display server protocol that when implemented
+        is a computer display server protocol that
         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.
@@ -879,7 +902,7 @@
 
     <para>
         The Yocto Project provides the Wayland protocol libraries and the
-        reference Weston compositor as part of it release.
+        reference Weston compositor as part of its 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>
@@ -974,7 +997,7 @@
         <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
+            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
@@ -982,7 +1005,7 @@
                     <literallayout class='monospaced'>
      mkdir -p /tmp/$USER-weston
      chmod 0700 /tmp/$USER-weston
-     export XDG_RUNTIME_DIR=/tmp/$USER=weston
+     export XDG_RUNTIME_DIR=/tmp/$USER-weston
                     </literallayout></para></listitem>
                 <listitem><para>Launch Weston in the shell:
                     <literallayout class='monospaced'>
@@ -1126,7 +1149,7 @@
             recipe-by-recipe basis through the <filename>LICENSE_FLAGS</filename> variable
             definition in the affected recipe.
             For instance, the
-            <filename>$HOME/poky/meta/recipes-multimedia/gstreamer/gst-plugins-ugly</filename>
+            <filename>poky/meta/recipes-multimedia/gstreamer/gst-plugins-ugly</filename>
             recipe contains the following statement:
             <literallayout class='monospaced'>
      LICENSE_FLAGS = "commercial"
@@ -1142,7 +1165,7 @@
 	        <filename>LICENSE_FLAGS_WHITELIST</filename> variable, which is a variable
 	        typically defined in your <filename>local.conf</filename> file.
             For example, to enable
-	        the <filename>$HOME/poky/meta/recipes-multimedia/gstreamer/gst-plugins-ugly</filename>
+	        the <filename>poky/meta/recipes-multimedia/gstreamer/gst-plugins-ugly</filename>
 	        package, you could add either the string
 	        "commercial_gst-plugins-ugly" or the more general string
 	        "commercial" to <filename>LICENSE_FLAGS_WHITELIST</filename>.
@@ -1163,7 +1186,7 @@
             </literallayout>
 	        As a convenience, you do not need to specify the complete license string
 	        in the whitelist for every package.
-            you can use an abbreviated form, which consists
+            You can use an abbreviated form, which consists
 	        of just the first portion or portions of the license string before
 	        the initial underscore character or characters.
             A partial string will match
@@ -1185,10 +1208,10 @@
 		        License flag matching allows you to control what recipes the
                 OpenEmbedded build system includes in the build.
                 Fundamentally, the build system attempts to match
-                <filename>LICENSE_FLAG</filename> strings found in
+                <filename>LICENSE_FLAGS</filename> strings found in
                 recipes against <filename>LICENSE_FLAGS_WHITELIST</filename>
                 strings found in the whitelist.
-                A match, causes the build system to include a recipe in the
+                A match causes the build system to include a recipe in the
                 build, while failure to find a match causes the build system to
                 exclude a recipe.
             </para>
@@ -1249,7 +1272,7 @@
 
             <para>
                 This scheme works even if the
-                <filename>LICENSE_FLAG</filename> string already
+                <filename>LICENSE_FLAGS</filename> string already
                 has <filename>_${PN}</filename> appended.
                 For example, the build system turns the license flag
                 "commercial_1.2_foo" into "commercial_1.2_foo_foo" and would
@@ -1289,7 +1312,7 @@
             <para>
                 Other helpful variables related to commercial
                 license handling exist and are defined in the
-                <filename>$HOME/poky/meta/conf/distro/include/default-distrovars.inc</filename> file:
+                <filename>poky/meta/conf/distro/include/default-distrovars.inc</filename> file:
                 <literallayout class='monospaced'>
      COMMERCIAL_AUDIO_PLUGINS ?= ""
      COMMERCIAL_VIDEO_PLUGINS ?= ""

documentation/ref-manual/usingpoky.xml

@@ -27,7 +27,7 @@
         <title>Build Overview</title>
 
         <para>
-            The first thing you need to do is set up the OpenEmbedded build 
+            The first thing you need to do is set up the OpenEmbedded build
             environment by sourcing an environment setup script
             (i.e.
             <link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>
@@ -40,7 +40,7 @@
         </para>
 
         <para>
-            The <filename>build_dir</filename> is optional and specifies the directory the
+            The <filename>build_dir</filename> argument 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 a directory
@@ -62,7 +62,7 @@
         <para>
             The <filename>target</filename> is the name of the recipe you want to build.
             Common targets are the images in <filename>meta/recipes-core/images</filename>,
-            <filename>/meta/recipes-sato/images</filename>, etc. all found in the
+            <filename>meta/recipes-sato/images</filename>, etc. all found in the
             <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
             Or, the target can be the name of a recipe for a specific piece of software such as
             BusyBox.
@@ -72,7 +72,7 @@
 
         <note>
             Building an image without GNU General Public License Version 3 (GPLv3) components
-            is only supported for minimal and base images.
+            is supported for only minimal and base images.
             See the "<link linkend='ref-images'>Images</link>" chapter for more information.
         </note>
     </section>
@@ -158,7 +158,7 @@
             <filename>package_write</filename>, and <filename>build</filename>.
             The default task is <filename>build</filename> and any tasks on which it depends
             build first.
-            Some tasks exist, such as <filename>devshell</filename>, that are not part of the
+            Some tasks, such as <filename>devshell</filename>, 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.
@@ -169,14 +169,15 @@
         </para>
 
         <para>
-            If you wish to rerun a task, use the <filename>-f</filename> force option.
-            For example, the following sequence forces recompilation after changing files in the
-            working directory.
+            If you wish to rerun a task, use the <filename>-f</filename> force
+            option.
+            For example, the following sequence forces recompilation after
+            changing files in the work directory.
             <literallayout class='monospaced'>
      $ bitbake matchbox-desktop
                .
                .
-        [make some changes to the source code in the working directory]
+        [make some changes to the source code in the work directory]
                .
                .
      $ bitbake matchbox-desktop -c compile -f
@@ -206,14 +207,19 @@
         <title>Dependency Graphs</title>
 
         <para>
-            Sometimes it can be hard to see why BitBake wants to build some other packages before a given
-            package you have specified.
-            The <filename>bitbake -g targetname</filename> command creates the
-            <filename>depends.dot</filename>, <filename>package-depends.dot</filename>,
-            and <filename>task-depends.dot</filename> files in the current directory.
-            These files show the package and task dependencies and are useful for debugging problems.
-            You can use the <filename>bitbake -g -u depexp targetname</filename> command to
-            display the results in a more human-readable form.
+            Sometimes it can be hard to see why BitBake wants to build
+            other packages before building a given package you have specified.
+            The <filename>bitbake -g &lt;targetname&gt;</filename> command
+            creates the <filename>pn-buildlist</filename>,
+            <filename>pn-depends.dot</filename>,
+            <filename>package-depends.dot</filename>, and
+            <filename>task-depends.dot</filename> files in the current
+            directory.
+            These files show what will be built and the package and task
+            dependencies, which are useful for debugging problems.
+            You can use the
+            <filename>bitbake -g -u depexp &lt;targetname&gt;</filename>
+            command to display the results in a more human-readable form.
         </para>
     </section>
 
@@ -271,12 +277,18 @@
     <section id='usingpoky-debugging-buildfile'>
         <title>Building with No Dependencies</title>
         <para>
-            If you really want to build a specific <filename>.bb</filename> file, you can use
-            the command form <filename>bitbake -b &lt;somepath/somefile.bb&gt;</filename>.
-            This command form does not check for dependencies so you should use it
-            only when you know its dependencies already exist.
-            You can also specify fragments of the filename.
-            In this case, BitBake checks for a unique match.
+            To build a specific recipe (<filename>.bb</filename> file),
+            you can use the following command form:
+            <literallayout class='monospaced'>
+     $ bitbake -b &lt;somepath/somerecipe.bb&gt;
+            </literallayout>
+            This command form does not check for dependencies.
+            Consequently, you should use it
+            only when you know dependencies already exist.
+            <note>
+                You can also specify fragments of the filename.
+                In this case, BitBake checks for a unique match.
+            </note>
         </para>
     </section>
 
@@ -284,11 +296,16 @@
         <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 do specify the package.
-            If you want to show the environment resulting from parsing a single
-            recipe, use the <filename>-b recipename</filename> form.
+            display the parsing environment for a configuration.
+            The following displays the general parsing environment:
+            <literallayout class='monospaced'>
+     $ bitbake -e
+            </literallayout>
+            This next example shows the parsing environment for a specific
+            recipe:
+            <literallayout class='monospaced'>
+     $ bitbake -e &lt;recipename&gt;
+            </literallayout>
         </para>
     </section>
 
@@ -479,11 +496,11 @@
             from your <filename>conf/local.conf</filename> file.
             However, you should realize that enabling and disabling
             build history in this manner can change the
-            <filename>do_package</filename> task checksums, which if you
+            <filename>do_package</filename> task checksums which, if you
             are using the OEBasicHash signature generator (the default
             for many current distro configurations including
             <filename>DISTRO = "poky"</filename> and
-            <filename>DISTRO = ""</filename>) and will result in the packaging
+            <filename>DISTRO = ""</filename>) will result in the packaging
             tasks being re-run during the subsequent build.
         </para>
 
@@ -508,7 +525,8 @@
             <imagedata fileref="figures/buildhistory.png" align="center" width="6in" depth="4in" />
         </para>
 
-        <para>At the top level, there is a <filename>metadata-revs</filename> file
+        <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.
             The rest of the data splits into separate
@@ -632,6 +650,12 @@
             <para>
                 The files produced for each image are as follows:
                 <itemizedlist>
+                    <listitem><para><filename>image-files:</filename>
+                        A directory containing selected files from the root
+                        filesystem.
+                        The files are defined by
+                        <filename>BUILDHISTORY_IMAGE_FILES</filename>.
+                        </para></listitem>
                     <listitem><para><filename>build-id:</filename>
                         Human-readable information about the build configuration
                         and metadata source revisions.</para></listitem>

documentation/tools/mega-manual.sed

@@ -1,13 +1,14 @@
 # Processes ref-manual and yocto-project-qs manual (<word>-<word>-<word> style)
-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
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.5.4\/[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.5\/[a-z]*-[a-z]*\/[a-z]*-[a-z]*.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.5.4\/[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.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-dev\/kernel-dev.html\" target=\"_top\">Yocto Project Linux Kernel Development Manual<\/a>/Yocto Project Linux Kernel Development Manual/g
-s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.5\/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.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.5.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.5.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.5.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.5.4\/profile-manual\/profile-manual.html\" target=\"_top\">Yocto Project Profiling and Tracing Manual<\/a>/Yocto Project Profiling and Tracing Manual/g
+s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.5.4\/kernel-dev\/kernel-dev.html\" target=\"_top\">Yocto Project Linux Kernel Development Manual<\/a>/Yocto Project Linux Kernel Development Manual/g
+s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.5.4\/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

@@ -17,11 +17,10 @@
                 the terms of the <ulink type="http" url="http://creativecommons.org/licenses/by-sa/2.0/uk/">Creative Commons Attribution-Share Alike 2.0 UK: England &amp; Wales</ulink> as published by Creative Commons.
             </para>
             <note>
-                Due to production processes, there could be differences between the Yocto Project
-                documentation bundled in the release tarball and the
-                <ulink url='&YOCTO_DOCS_QS_URL;'>Yocto Project Quick Start</ulink> on
-                the <ulink url='&YOCTO_HOME_URL;'>Yocto Project</ulink> website.
-                For the latest version of this manual, see the manual on the website.
+                For the latest version of this manual associated with this
+                Yocto Project release, see the
+                <ulink url='&YOCTO_DOCS_QS_URL;'>Yocto Project Quick Start</ulink>
+                from the Yocto Project website.
             </note>
         </legalnotice>
 
@@ -88,13 +87,6 @@
                 new to the Yocto Project but familiar with Linux build systems.</para></listitem>
         </itemizedlist>
     </para>
-    <note>
-        Due to production processes, there could be differences between the Yocto Project
-        documentation bundled in a released tarball and the
-        <ulink url='&YOCTO_DOCS_QS_URL;'>Yocto Project Quick Start</ulink> on
-        the <ulink url='&YOCTO_HOME_URL;'>Yocto Project</ulink> website.
-        For the latest version of this manual, see the manual on the website.
-    </note>
 </section>
 
 <section id='yp-intro'>
@@ -239,11 +231,6 @@
                 distributions listed in the
                 "<ulink url='&YOCTO_DOCS_REF_URL;#detailed-supported-distros'>Supported Linux Distributions</ulink>"
                 section of the Yocto Project Reference Manual.
-                Refer to
-                <ulink url='&OE_HOME_URL;/index.php?title=OEandYourDistro'>OE and Your Distro</ulink> and
-                <ulink url='&OE_HOME_URL;/index.php?title=Required_software'>Required Software</ulink>
-                for information for information about dependencies and
-                requirements.
                 If you encounter problems, please go to
                 <ulink url='&YOCTO_BUGZILLA_URL;'>Yocto Project Bugzilla</ulink>
                 and submit a bug.
@@ -288,8 +275,9 @@
             <title>Ubuntu and Debian</title>
 
             <para>
-                The essential packages you need for a supported Ubuntu
-                or Debian distribution are shown in the following command:
+                The essential and graphical support packages you need for a
+                supported Ubuntu or Debian distribution are shown in the
+                following command:
                 <literallayout class='monospaced'>
      $ sudo apt-get install &UBUNTU_HOST_PACKAGES_ESSENTIAL; libsdl1.2-dev xterm
                 </literallayout>
@@ -300,8 +288,8 @@
             <title>Fedora</title>
 
             <para>
-                The essential packages you need for a supported Fedora distribution
-                are shown in the following command:
+                The essential and graphical packages you need for a supported
+                Fedora distribution are shown in the following command:
                 <literallayout class='monospaced'>
      $ sudo yum install &FEDORA_HOST_PACKAGES_ESSENTIAL; SDL-devel xterm
                 </literallayout>
@@ -309,11 +297,11 @@
         </section>
 
         <section id='opensuse'>
-            <title>openSUSE</title>
+            <title>OpenSUSE</title>
 
             <para>
-                The essential packages you need for a supported openSUSE
-                distribution are shown in the following command:
+                The essential and graphical packages you need for a supported
+                OpenSUSE distribution are shown in the following command:
                 <literallayout class='monospaced'>
      $ sudo zypper install &OPENSUSE_HOST_PACKAGES_ESSENTIAL; libSDL-devel xterm
                 </literallayout>
@@ -324,8 +312,8 @@
             <title>CentOS</title>
 
             <para>
-                The essential packages you need for a supported CentOS
-                distribution are shown in the following command:
+                The essential and graphical packages you need for a supported
+                CentOS distribution are shown in the following command:
                 <literallayout class='monospaced'>
      $ sudo yum install &CENTOS_HOST_PACKAGES_ESSENTIAL; SDL-devel xterm
                 </literallayout>
@@ -346,8 +334,8 @@
             <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.
+            Current and archived releases are available for download to the
+            right.
             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.
@@ -482,8 +470,9 @@
              By default, the target architecture for the build is <filename>qemux86</filename>,
              which produces an image that can be used in the QEMU emulator and is targeted at an
              <trademark class='registered'>Intel</trademark> 32-bit based architecture.
-             To change this default, edit the value of the <filename>MACHINE</filename> variable
-             in the configuration file before launching the build.
+             To change this default, edit the value of the
+             <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink>
+             variable in the configuration file before launching the build.
          </para>
 
          <para>
@@ -596,11 +585,12 @@
             </para>
 
             <literallayout class='monospaced'>
-     poky-eglibc-&lt;<emphasis>host_system</emphasis>&gt;-&lt;<emphasis>image_type</emphasis>&gt;-&lt;<emphasis>arch</emphasis>&gt;.sh
+     poky-eglibc-&lt;<emphasis>host_system</emphasis>&gt;-&lt;<emphasis>image_type</emphasis>&gt;-&lt;<emphasis>arch</emphasis>&gt;-toolchain-&lt;<emphasis>release_version</emphasis>&gt;.sh
 
      Where:
          &lt;<emphasis>host_system</emphasis>&gt; is a string representing your development system:
-                i686 or x86_64.
+
+                    i686 or x86_64.
 
          &lt;<emphasis>image_type</emphasis>&gt; is a string representing the image you wish to
                 develop a Software Development Toolkit (SDK) for use against.
@@ -611,7 +601,12 @@
 
          &lt;<emphasis>arch</emphasis>&gt; is a string representing the tuned target architecture:
 
-                i586, x86_64, powerpc, mips, armv7a or armv5te
+                    i586, x86_64, powerpc, mips, armv7a or armv5te
+
+         &lt;<emphasis>release_version</emphasis>&gt; is a string representing the release number of the
+                Yocto Project:
+
+                    &DISTRO;, &DISTRO;+snapshot
             </literallayout>
 
             <para>
@@ -619,7 +614,7 @@
                 development host system and a i586-tuned target architecture
                 based off the SDK for <filename>core-image-sato</filename>:
                 <literallayout class='monospaced'>
-     poky-eglibc-x86_64-core-image-sato-i586.sh
+     poky-eglibc-x86_64-core-image-sato-i586-toolchain-&DISTRO;.sh
                 </literallayout>
             </para>
 
@@ -648,7 +643,7 @@
 
             <para>
                 <literallayout class='monospaced'>
-     $ ~/Downloads/poky-eglibc-x86_64-core-image-sato-i586.sh
+     $ ~/Downloads/poky-eglibc-x86_64-core-image-sato-i586-toolchain-&DISTRO;.sh
                 </literallayout>
             </para>
 
@@ -713,19 +708,14 @@
 
      Where:
          &lt;<emphasis>profile</emphasis>&gt; is the filesystem image's profile:
-                   lsb, lsb-dev, lsb-sdk, lsb-qt3, minimal, minimal-dev, sato, sato-dev, or sato-sdk.
-                   For information on these types of image profiles, see the
-                   "<ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Images</ulink>" chapter
-                   in the Yocto Project Reference Manual.
+                   lsb, lsb-dev, lsb-sdk, lsb-qt3, minimal, minimal-dev, sato,
+                   sato-dev, or sato-sdk. For information on these types of image
+                   profiles, see the "<ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Images</ulink>" chapter in the Yocto Project
+                   Reference Manual.
 
          &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>
 
@@ -904,6 +894,17 @@
             </literallayout>
         </para>
 
+        <para>
+            In the previous example, the
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-BB_GENERATE_MIRROR_TARBALLS'><filename>BB_GENERATE_MIRROR_TARBALLS</filename></ulink>
+            variable causes the OpenEmbedded build system to generate tarballs
+            of the Git repositories and store them in the
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-DL_DIR'><filename>DL_DIR</filename></ulink>
+            directory.
+            Due to performance reasons, generating and storing these tarballs
+            is not the build system's default behavior.
+        </para>
+
         <para>
             You can also use the
             <ulink url='&YOCTO_DOCS_REF_URL;#var-PREMIRRORS'><filename>PREMIRRORS</filename></ulink>

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

@@ -7,11 +7,11 @@ KBRANCH_beagleboard = "standard/beagleboard"
 KMACHINE_genericx86 ?= "common-pc"
 KMACHINE_genericx86-64 ?= "common-pc-64"
 
-SRCREV_machine_genericx86 ?= "702040ac7c7ec66a29b4d147665ccdd0ff015577"
-SRCREV_machine_genericx86-64 ?= "702040ac7c7ec66a29b4d147665ccdd0ff015577"
-SRCREV_machine_routerstationpro ?= "d4e6adefaf92a1e7b6539d371ba49b78bd194a84"
-SRCREV_machine_mpc8315e-rdb ?= "12dc46ba4efb80e135fec4dce913eeb87ee671b3"
-SRCREV_machine_beagleboard ?= "702040ac7c7ec66a29b4d147665ccdd0ff015577"
+SRCREV_machine_genericx86 ?= "c03195ed6e3066494e3fb4be69154a57066e845b"
+SRCREV_machine_genericx86-64 ?= "c03195ed6e3066494e3fb4be69154a57066e845b"
+SRCREV_machine_routerstationpro ?= "2d91e201018c15e24fb83336dcb4029b8569eb9d"
+SRCREV_machine_mpc8315e-rdb ?= "ac071526ffac37c907532933b628e4f64070f155"
+SRCREV_machine_beagleboard ?= "3d9b0d130a00dd32e6061ac708eaaaed69e35c3d"
 
 COMPATIBLE_MACHINE_genericx86 = "genericx86"
 COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64"

meta-yocto/conf/bblayers.conf.sample

@@ -6,11 +6,11 @@ BBPATH = "${TOPDIR}"
 BBFILES ?= ""
 
 BBLAYERS ?= " \
-  ##COREBASE##/meta \
-  ##COREBASE##/meta-yocto \
-  ##COREBASE##/meta-yocto-bsp \
+  ##OEROOT##/meta \
+  ##OEROOT##/meta-yocto \
+  ##OEROOT##/meta-yocto-bsp \
   "
 BBLAYERS_NON_REMOVABLE ?= " \
-  ##COREBASE##/meta \
-  ##COREBASE##/meta-yocto \
+  ##OEROOT##/meta \
+  ##OEROOT##/meta-yocto \
   "

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

@@ -13,20 +13,23 @@ DISTRO_PN_ALIAS_pn-aaina = "Intel"
 DISTRO_PN_ALIAS_pn-abiword-embedded = "Fedora=abiword Ubuntu=abiword"
 DISTRO_PN_ALIAS_pn-adt-installer = "Intel"
 DISTRO_PN_ALIAS_pn-alsa-state = "OE-Core"
-DISTRO_PN_ALIAS_pn-anjuta-remote-run = "OpenedHand"
+DISTRO_PN_ALIAS_pn-alsa-utils-alsaconf = "OE-Core"
+DISTRO_PN_ALIAS_pn-atk = "Fedora=atk OpenSuSE=atk"
+DISTRO_PN_ALIAS_pn-atk-native = "Fedora=atk OpenSuSE=atk"
 DISTRO_PN_ALIAS_pn-augeas = "Ubuntu=libaugeas0 Debian=libaugeas0"
 DISTRO_PN_ALIAS_pn-avahi-ui = "Ubuntu=avahi-discover Debian=avahi-discover"
 DISTRO_PN_ALIAS_pn-babeltrace = "OSPDT"
 DISTRO_PN_ALIAS_pn-bdwgc = "OSPDT"
 DISTRO_PN_ALIAS_pn-bigreqsproto = "Meego=xorg-x11-proto-bigreqsproto"
+DISTRO_PN_ALIAS_pn-bjam-native = "OpenSuSE=boost-jam Debina=bjam"
 DISTRO_PN_ALIAS_pn-blktool = "Debian=blktool Mandriva=blktool"
-DISTRO_PN_ALIAS_pn-bluez4= "Fedora=bluez Ubuntu=bluez Debian=bluez-utils Opensuse=bluez"
-DISTRO_PN_ALIAS_pn-bluez4="Meego=bluz Fedora=bluz Ubuntu=bluz OpenSuSE=bluz Mandriva=bluz"
+DISTRO_PN_ALIAS_pn-bluez4 = "Ubuntu=bluez Debian=bluez-utils"
+DISTRO_PN_ALIAS_pn-bluez5 = "Fedora=bluez  Opensuse=bluez"
 DISTRO_PN_ALIAS_pn-bluez-dtl1-workaround = "OE-Core"
 DISTRO_PN_ALIAS_pn-btrfs-tools = "Debian=btrfs-tools Fedora=btrfs-progs"
-DISTRO_PN_ALIAS_pn-builder = "OE-Core"
 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-builder = "OE-Core"
+DISTRO_PN_ALIAS_pn-buildtools-tarball = "OE-Core"
 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"
@@ -37,44 +40,51 @@ DISTRO_PN_ALIAS_pn-claws-plugin-rssyl = "Fedora=claws-mail-plugins OpenSuSE=claw
 DISTRO_PN_ALIAS_pn-clipboard-manager = "OpenedHand"
 DISTRO_PN_ALIAS_pn-clutter = "Fedora=clutter OpenSuse=clutter Ubuntu=clutter-1.0 Mandriva=clutter Debian=clutter"
 DISTRO_PN_ALIAS_pn-clutter-1.8 = "Fedora=clutter OpenSuse=clutter Ubuntu=clutter-1.0 Mandriva=clutter Debian=clutter"
+DISTRO_PN_ALIAS_pn-clutter-gst-1.0 = "Debian=clutter-gst Ubuntu=clutter-gst Fedora=clutter-gst"
 DISTRO_PN_ALIAS_pn-clutter-gst-1.8 = "Fedora=clutter-gst Debian=libclutter-gst"
+DISTRO_PN_ALIAS_pn-clutter-gtk-1.0 = "Debian=clutter-gtk Ubuntu=clutter-gtk Fedora=clutter-gtk"
 DISTRO_PN_ALIAS_pn-clutter-gtk-1.8 = "Fedora=clutter-gtk OpenSuSE=clutter-gtk Ubuntu=clutter-gtk-0.10 Mandriva=clutter-gtk Debian=clutter-gtk"
+DISTRO_PN_ALIAS_pn-cogl-1.0 = "Debian=cogl Ubuntu=cogl Fedora=cogl"
 DISTRO_PN_ALIAS_pn-cogl = "Fedora=cogl OpenSuse=cogl Ubuntu=cogl Mandriva=cogl Debian=cogl"
 DISTRO_PN_ALIAS_pn-compositeproto = "Meego=xorg-x11-proto-compositeproto"
-DISTRO_PN_ALIAS_pn-connman-gnome = "Intel"
 DISTRO_PN_ALIAS_pn-connman = "Meego=connman"
+DISTRO_PN_ALIAS_pn-connman-conf = "OE-Core"
+DISTRO_PN_ALIAS_pn-connman-gnome = "Intel"
 DISTRO_PN_ALIAS_pn-console-tools = "Debian=console-tools Ubuntu=console-tools"
 DISTRO_PN_ALIAS_pn-core-console = "OE-Core"
 DISTRO_PN_ALIAS_pn-core-image-base = "OE-Core"
 DISTRO_PN_ALIAS_pn-core-image-basic = "OE-Core"
 DISTRO_PN_ALIAS_pn-core-image-clutter = "OE-Core"
 DISTRO_PN_ALIAS_pn-core-image-core = "OE-Core"
-DISTRO_PN_ALIAS_pn-core-image-lsb-dev = "OE-Core"
 DISTRO_PN_ALIAS_pn-core-image-lsb = "OE-Core"
+DISTRO_PN_ALIAS_pn-core-image-lsb-dev = "OE-Core"
 DISTRO_PN_ALIAS_pn-core-image-lsb-qt3 = "OE-Core"
 DISTRO_PN_ALIAS_pn-core-image-lsb-sdk = "OE-Core"
+DISTRO_PN_ALIAS_pn-core-image-minimal = "OE-Core"
 DISTRO_PN_ALIAS_pn-core-image-minimal-dev = "OE-Core"
 DISTRO_PN_ALIAS_pn-core-image-minimal-directdisk = "OE-Core"
 DISTRO_PN_ALIAS_pn-core-image-minimal-initramfs = "OE-Core"
 DISTRO_PN_ALIAS_pn-core-image-minimal-live = "OE-Core"
 DISTRO_PN_ALIAS_pn-core-image-minimal-mtdutils = "OE-Core"
-DISTRO_PN_ALIAS_pn-core-image-minimal = "OE-Core"
 DISTRO_PN_ALIAS_pn-core-image-rt = "OE-Core"
 DISTRO_PN_ALIAS_pn-core-image-rt-sdk = "OE-Core"
+DISTRO_PN_ALIAS_pn-core-image-sato = "OE-Core"
 DISTRO_PN_ALIAS_pn-core-image-sato-dev = "OE-Core"
 DISTRO_PN_ALIAS_pn-core-image-sato-directdisk = "OE-Core"
 DISTRO_PN_ALIAS_pn-core-image-sato-live = "OE-Core"
-DISTRO_PN_ALIAS_pn-core-image-sato = "OE-Core"
+DISTRO_PN_ALIAS_pn-core-image-sato-sdk = "OE-Core"
 DISTRO_PN_ALIAS_pn-core-image-sato-sdk-directdisk = "OE-Core"
 DISTRO_PN_ALIAS_pn-core-image-sato-sdk-live = "OE-Core"
-DISTRO_PN_ALIAS_pn-core-image-sato-sdk = "OE-Core"
 DISTRO_PN_ALIAS_pn-core-image-sdk = "OE-Core"
+DISTRO_PN_ALIAS_pn-core-image-weston = "OE-Core"
 DISTRO_PN_ALIAS_pn-core-image-x11 = "OE-Core"
 DISTRO_PN_ALIAS_pn-cross-localedef = "OSPDT"
-DISTRO_PN_ALIAS_pn-cwautomacros= "OSPDT upstream=http://cwautomacros.berlios.de/"
+DISTRO_PN_ALIAS_pn-cwautomacros = "OSPDT upstream=http://cwautomacros.berlios.de/"
 DISTRO_PN_ALIAS_pn-damageproto = "Meego=xorg-x11-proto-damageproto"
 DISTRO_PN_ALIAS_pn-db = "Debian=db5.1 Ubuntu=db5.1"
+DISTRO_PN_ALIAS_pn-dbus-ptest = "Fedora=dbus Ubuntu=dbus"
 DISTRO_PN_ALIAS_pn-dbus-wait = "OpenedHand"
+DISTRO_PN_ALIAS_pn-depmodwrapper-cross = "OE-Core"
 DISTRO_PN_ALIAS_pn-directfb-examples = "Debian=directfb Fedora=directfb"
 DISTRO_PN_ALIAS_pn-distcc = "Debian=distcc Fedora=distcc"
 DISTRO_PN_ALIAS_pn-distcc-config = "OpenedHand"
@@ -92,6 +102,10 @@ DISTRO_PN_ALIAS_pn-eee-acpi-scripts = "Debian=eeepc-acpi-scripts Ubuntu=eeepc-ac
 DISTRO_PN_ALIAS_pn-eglibc = "OE-Core"
 DISTRO_PN_ALIAS_pn-eglibc-initial = "OE-Core"
 DISTRO_PN_ALIAS_pn-eglibc-locale = "OE-Core"
+DISTRO_PN_ALIAS_pn-eglibc-mtrace = "OE-Core"
+DISTRO_PN_ALIAS_pn-eglibc-scripts = "OE-Core"
+DISTRO_PN_ALIAS_pn-eglinfo-fb = "OE-Core"
+DISTRO_PN_ALIAS_pn-eglinfo-x11 = "OE-Core"
 DISTRO_PN_ALIAS_pn-emgd-driver-bin = "Intel"
 DISTRO_PN_ALIAS_pn-encodings = "Ubuntu=xfonts-encodings Mandriva=x11-font-encodings Debian=xfonts-encodings"
 DISTRO_PN_ALIAS_pn-evieext = "Meego=xorg-x11-proto-evieext Debian=x11proto-evie"
@@ -114,26 +128,34 @@ DISTRO_PN_ALIAS_pn-gcc-crosssdk-initial = "OE-Core"
 DISTRO_PN_ALIAS_pn-gccmakedep = "Mandriva=gccmakedep Ubuntu=xutils-dev"
 DISTRO_PN_ALIAS_pn-gcc-runtime = "Ubuntu=gcc Fedora=gcc"
 DISTRO_PN_ALIAS_pn-gconf-dbus = "Meego=GConf-dbus"
-DISTRO_PN_ALIAS_pn-gdk-pixbuf-csource-native = "Debian=libgdk-pixbuf2.0-0 Fedora=gdk-pixbuf2"
 DISTRO_PN_ALIAS_pn-gdk-pixbuf = "Debian=libgdk-pixbuf2.0 Fedora=gdk-pixbuf"
+DISTRO_PN_ALIAS_pn-gdk-pixbuf-csource-native = "Debian=libgdk-pixbuf2.0-0 Fedora=gdk-pixbuf2"
 DISTRO_PN_ALIAS_pn-gettext-minimal-native = "Debian=gettext Fedora=gettext"
 DISTRO_PN_ALIAS_pn-glib-2.0 = "Meego=glib2 Fedora=glib2 OpenSuSE=glib2 Ubuntu=glib2.0 Mandriva=glib2.0 Debian=glib2.0"
 DISTRO_PN_ALIAS_pn-glproto = "Meego=xorg-x11-proto-glproto"
 DISTRO_PN_ALIAS_pn-gnu-config = "OpenedHand"
 DISTRO_PN_ALIAS_pn-grub-efi-i586 = "Ubuntu=grub Fedora=grub"
+DISTRO_PN_ALIAS_pn-grub-efi-x86-64-native = "Ubuntu=grub Fedora=grub"
 DISTRO_PN_ALIAS_pn-gst-ffmpeg = "Mandriva=gstreamer0.10-ffmpeg Debian=gstreamer0.10-ffmpeg"
 DISTRO_PN_ALIAS_pn-gst-fluendo-mp3 = "Debian=gstreamer0.10-fluendo-mp3 Ubuntu=gstreamer0.10-fluendo-mp3"
 DISTRO_PN_ALIAS_pn-gst-fluendo-mpegdemux = "Ubuntu=gstreamer0.10-fluendo-mpegdemux Debian=gstreamer0.10-fluendo-mpegdemux"
 DISTRO_PN_ALIAS_pn-gst-meta-base = "Meego=gstreamer Fedora=gstreamer OpenSuSE=gstreamer Ubuntu=gstreamer0.10 Mandriva=gstreamer0.10 Debian=gstreamer0.10"
-DISTRO_PN_ALIAS_pn-gst-openmax="OSPDT upstream=http://cgit.freedesktop.org/gstreamer/gst-openmax"
+DISTRO_PN_ALIAS_pn-gst-openmax = "OSPDT upstream=http://cgit.freedesktop.org/gstreamer/gst-openmax"
 DISTRO_PN_ALIAS_pn-gst-plugin-bluetooth = "Ubuntu=libgstreamer-plugins-base Fedora=gstreamer-plugins-base"
 DISTRO_PN_ALIAS_pn-gst-plugins-bad = "Fedora=gstreamer-plugins-bad-free OpenSuSE=gstreamer-plugins-bad Debian=gst-plugins-bad0.10"
 DISTRO_PN_ALIAS_pn-gst-plugins-base = "Meego=gst-plugins-base Fedora=gstreamer-plugins-base OpenSuSE=gstreamer-plugins-base Ubuntu=gst-plugins-base0.10 Mandriva=gstreamer0.10-plugins-base Debian=gst-plugins-base0.10"
+DISTRO_PN_ALIAS_pn-gst-plugins-gl = "Debian=gstreamer0.10-plugins-gl OpenSuSE=gstreamer-0_10-plugins-gl" 
 DISTRO_PN_ALIAS_pn-gst-plugins-good = "Meego=gst-plugins-good Fedora=gstreamer-plugins-good OpenSuSE=gstreamer-plugins-good Ubuntu=gst-plugins-good0.10 Mandriva=gstreamer0.10-plugins-good Debian=gst-plugins-good0.10"
 DISTRO_PN_ALIAS_pn-gst-plugins-ugly = "OpenSuSE=gstreamer-plugins-ugly Mandriva=gstreamer0.10-plugins-ugly Debian=gst-plugins-ugly0.10"
+DISTRO_PN_ALIAS_pn-gstreamer1.0 = "Debian=gstreamer1.0 Ubuntu=gstreamer1.0"
+DISTRO_PN_ALIAS_pn-gstreamer1.0-plugins-bad = "Debian=gstreamer1.0-plugins-bad Ubuntu=gstreamer1.0-plugins-bad"
+DISTRO_PN_ALIAS_pn-gstreamer1.0-plugins-base = "Debian=gstreamer1.0-plugins-base Ubuntu=gstreamer1.0-plugins-base"
+DISTRO_PN_ALIAS_pn-gstreamer1.0-plugins-good = "Debian=gstreamer1.0-plugins-good Ubuntu=gstreamer1.0-plugins-bad"
+DISTRO_PN_ALIAS_pn-gstreamer = "Debian=gstreamer1.0 Ubuntu=gstreamer1.0"
+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+3 = "Ubuntu=gtk+3.0 Debian=gtk+3.0 Fedora=gtk3"
 DISTRO_PN_ALIAS_pn-gtk-doc-stub = "Fedora=gtk-doc Ubuntu=gtk-doc"
 DISTRO_PN_ALIAS_pn-gtk-engines = "Fedora=gtk2-engines OpenSuSE=gtk2-engines Ubuntu=gtk2-engines Mandriva=gtk-engines2 Debian=gtk2-engines"
-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"
@@ -141,19 +163,19 @@ DISTRO_PN_ALIAS_pn-hello-mod = "OE-Core"
 DISTRO_PN_ALIAS_pn-hostap-conf = "OE-Core"
 DISTRO_PN_ALIAS_pn-hwlatdetect = "OSPDT"
 DISTRO_PN_ALIAS_pn-icecc-create-env = "OE-Core"
-DISTRO_PN_ALIAS_pn-imake = "Mandriva=xutils Ubuntu=xutils"
+DISTRO_PN_ALIAS_pn-init-ifupdown = "Debian=ifupdown Ubuntu=ifupdown"
 DISTRO_PN_ALIAS_pn-initramfs-boot = "OE-Core"
 DISTRO_PN_ALIAS_pn-initramfs-framework = "OE-Core"
 DISTRO_PN_ALIAS_pn-initramfs-live-boot = "OE-Core"
 DISTRO_PN_ALIAS_pn-initramfs-live-install = "OE-Core"
 DISTRO_PN_ALIAS_pn-initramfs-live-install-efi = "OE-Core"
+DISTRO_PN_ALIAS_pn-initscripts = "Fedora=initscripts Mandravia=initscripts"
 DISTRO_PN_ALIAS_pn-inputproto = "Meego=xorg-x11-proto-inputproto"
 DISTRO_PN_ALIAS_pn-iproute2 = "OSPDT"
-DISTRO_PN_ALIAS_pn-jpeg="OpenSuSE=libjpeg Ubuntu=libjpeg62"
+DISTRO_PN_ALIAS_pn-jpeg = "OpenSuSE=libjpeg Ubuntu=libjpeg62"
 DISTRO_PN_ALIAS_pn-kbproto = "Meego=xorg-x11-proto-kbproto Ubuntu=x11proto-kb-dev Debian=x11proto-kb-dev"
 DISTRO_PN_ALIAS_pn-kconfig-frontends = "OSPDT"
 DISTRO_PN_ALIAS_pn-kernelshark = "Mandriva=kernelshark Ubuntu=kernelshark"
-DISTRO_PN_ALIAS_pn-kern-tools-native = "OpenedHand"
 DISTRO_PN_ALIAS_pn-kern-tools-native = "Windriver"
 DISTRO_PN_ALIAS_pn-keymaps = "OE-Core"
 DISTRO_PN_ALIAS_pn-kf = "OSPDT"
@@ -161,50 +183,59 @@ DISTRO_PN_ALIAS_pn-lame = "Debian=lame Ubuntu=lame"
 DISTRO_PN_ALIAS_pn-latencytop = "Meego=latencytop Fedora=latencytop Debian=latencytop OpenSuSE=latencytop"
 DISTRO_PN_ALIAS_pn-ldconfig-native = "Ubuntu=libc-bin Fedora=glibc"
 DISTRO_PN_ALIAS_pn-liba52 = "Mandriva=a52dec Debian=a52dec"
-DISTRO_PN_ALIAS_pn-libacpi="Ubuntu=libacpi Mandriva=libacpi"
+DISTRO_PN_ALIAS_pn-libacpi = "Ubuntu=libacpi Mandriva=libacpi"
 DISTRO_PN_ALIAS_pn-libatomics-ops = "Meego=libatomic-ops Debian=libatomic-ops Ubuntu=libatomic-ops OpenSuSE=libatomic-ops Mandriva=libatomic-ops"
+DISTRO_PN_ALIAS_pn-libcgroup = "Ubuntu=libcgroup1 Debian=libcgroup1"
 DISTRO_PN_ALIAS_pn-libcheck = "Ubuntu=check Fedora=check OpenSuSE=check"
 DISTRO_PN_ALIAS_pn-libclass-isa-perl = "OSPDT"
 DISTRO_PN_ALIAS_pn-libdrm-poulsbo = "Debian=libdrm-intel1 Ubuntu=libdrm-intel1"
 DISTRO_PN_ALIAS_pn-libdumpvalue-perl = "OSPDT"
 DISTRO_PN_ALIAS_pn-libenv-perl = "OSPDT"
-DISTRO_PN_ALIAS_pn-libfakekey="Meego1.0=libfakekey Debian=libfakekey"
+DISTRO_PN_ALIAS_pn-libfakekey = "Meego1.0=libfakekey Debian=libfakekey"
 DISTRO_PN_ALIAS_pn-libfile-checktree-perl = "OSPDT"
 DISTRO_PN_ALIAS_pn-libfribidi = "OpenSuSE=fribidi Ubuntu=fribidi Mandriva=fribidi Debian=fribidi"
 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-libglu = "Debian=libglu Ubuntu=libglu Opensuse=mesa-libglu"
 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-libgu = "OpenSuSE=glu OSPDT"
 DISTRO_PN_ALIAS_pn-libi18n-collate-perl = "OSPDT"
+DISTRO_PN_ALIAS_pn-libical = "Ubuntu=libical Fedora=libical"
 DISTRO_PN_ALIAS_pn-libiconv = "Fedora=mingw-libiconv Opensuse=cross-mingw-libiconv"
 DISTRO_PN_ALIAS_pn-libjson = "Ubuntu=libjson0-dev Debian=libjson0-dev"
 DISTRO_PN_ALIAS_pn-libksba = "Fedora=libksba Debian=libksba8"
 DISTRO_PN_ALIAS_pn-liblbxutil = "Mandriva=liblbxutil OpenSuse=xorg-x11-devel"
 DISTRO_PN_ALIAS_pn-libmpc = "Fedora=libmpc OpenSuse=libmpc2"
 DISTRO_PN_ALIAS_pn-libnewt = "Debian=libnewt0.52 Fedora=newt"
+DISTRO_PN_ALIAS_pn-libnewt-python = "Ubuntu=python-newt Fedora=newt-python"
 DISTRO_PN_ALIAS_pn-libnss-mdns = "Meego=nss-mdns OpenSuSE=nss-mdns Ubuntu=nss-mdns Mandriva=nss_mdns Debian=nss-mdns"
 DISTRO_PN_ALIAS_pn-libomxil = "OSPDT upstream=http://omxil.sourceforge.net/"
-DISTRO_PN_ALIAS_pn-libowl-av = "OpenedHand"
 DISTRO_PN_ALIAS_pn-libowl = "Debian=owl OpenedHand"
+DISTRO_PN_ALIAS_pn-libowl-av = "OpenedHand"
 DISTRO_PN_ALIAS_pn-libpam = "Meego=pam Fedora=pam OpenSuSE=pam Ubuntu=pam Mandriva=pam Debian=pam"
 DISTRO_PN_ALIAS_pn-libpcre = "Mandriva=libpcre0 Fedora=pcre"
+DISTRO_PN_ALIAS_pn-libpng12 = "Debian=libpng12-0 Fedora=libpng"
 DISTRO_PN_ALIAS_pn-libpod-plainer-perl = "OSPDT"
 DISTRO_PN_ALIAS_pn-libsamplerate0 = "Meego=libsamplerate Fedora=libsamplerate OpenSuSE=libsamplerate Ubuntu=libsamplerate Mandriva=libsamplerate Debian=libsamplerate"
 DISTRO_PN_ALIAS_pn-libsdl = "Fedora=SDL Opensuse=SDL"
+DISTRO_PN_ALIAS_pn-libsdl2 = "Fedora=sdl2 Opensuse=libsdl2 Ubuntu=libsdl2 Debian=libsdl2"
 DISTRO_PN_ALIAS_pn-libsndfile1 = "Meego=libsndfile Fedora=libsndfile OpenSuSE=libsndfile Ubuntu=libsndfile Mandriva=libsndfile Debian=libsndfile"
 DISTRO_PN_ALIAS_pn-libsoup-2.4 = "Meego=libsoup Fedora=libsoup OpenSuSE=libsoup Ubuntu=libsoup2.4 Mandriva=libsoup Debian=libsoup2.4"
 DISTRO_PN_ALIAS_pn-libsync = "OSPDT"
 DISTRO_PN_ALIAS_pn-libtelepathy = "Debian=libtelepathy2 Ubuntu=libtelepathy2"
 DISTRO_PN_ALIAS_pn-libtimedate-perl = "Debian=libtimedate-perl Ubuntu=libtimedate-perl"
 DISTRO_PN_ALIAS_pn-liburcu = "Fedora=userspace-rcu Ubuntu=liburcu0"
+DISTRO_PN_ALIAS_pn-libusb1 = "Debian=libusb-1.0-0 Fedora=libusb1"
+DISTRO_PN_ALIAS_pn-libusb1-native = "Debian=libusb-1.0-0 Fedora=libusb1"
 DISTRO_PN_ALIAS_pn-libusb-compat = "OSPDT"
 DISTRO_PN_ALIAS_pn-libx11 = "Debian=libx11-6 Fedora=libX11 Ubuntu=libx11-6 OpenSuSE=xorg-x11-libX11"
 DISTRO_PN_ALIAS_pn-libx11-diet = "Debian=libx11-6 Fedora=libX11 Ubuntu=libx11-6 OpenSuSE=xorg-x11-libX11"
 DISTRO_PN_ALIAS_pn-libxcalibrate = "OSPDT upstream=http://cgit.freedesktop.org/xorg/lib/libXCalibrate/"
 DISTRO_PN_ALIAS_pn-libxfontcache = "Mandriva=libxfontcache Debian=libxfontcache"
 DISTRO_PN_ALIAS_pn-libxft = "Mandriva=libxft Debian=libxft2 Ubuntu=libxft2"
+DISTRO_PN_ALIAS_pn-libxkbcommon = "Fedora=libxkbcommon Debian=libxkbcommon"
 DISTRO_PN_ALIAS_pn-libxprintapputil = "Debian=libxprintapputil Ubuntu=libxprintapputil1 Mandriva=libxprintapputil"
 DISTRO_PN_ALIAS_pn-libxscrnsaver = "Fedora=libXScrnSaver Ubuntu=libxss1 Mandriva=libxscrnsaver"
 DISTRO_PN_ALIAS_pn-libxsettings-client = "Debian=libxsettings-client0 Ubuntu=libxsettings-client0 Mandriva=libXsettings-client0"
@@ -219,10 +250,13 @@ DISTRO_PN_ALIAS_pn-linux-yocto-tiny = "OSPDT"
 DISTRO_PN_ALIAS_pn-lsbinitscripts = "Windriver"
 DISTRO_PN_ALIAS_pn-lsbsetup = "Windriver"
 DISTRO_PN_ALIAS_pn-lsbtest = "Windriver"
-DISTRO_PN_ALIAS_pn-ltp = "Ubuntu=ltp"
+DISTRO_PN_ALIAS_pn-ltp = "Mandriva=ltp Ubuntu=ltp"
 DISTRO_PN_ALIAS_pn-lttng-modules = "OSPDT upstream=http://lttng.org/"
 DISTRO_PN_ALIAS_pn-lttng-tools = "OSPDT upstream=http://lttng.org/"
 DISTRO_PN_ALIAS_pn-lttng-ust = "OSPDT upstream=http://lttng.org/"
+DISTRO_PN_ALIAS_pn-lzo = "Debian=liblzo Ubuntu=liblzo Fedora=lzp"
+DISTRO_PN_ALIAS_pn-lzo-native = "Debian=liblzo Ubuntu=liblzo Fedora=lzp"
+DISTRO_PN_ALIAS_pn-mailx = "Debian=bsd-mailx Ubuntu=bsd-mailx"
 DISTRO_PN_ALIAS_pn-makedepend = "Mandriva=makedepend Ubuntu=xutils-dev"
 DISTRO_PN_ALIAS_pn-makedevs = "OE-Core"
 DISTRO_PN_ALIAS_pn-matchbox-config-gtk = "OpenedHand"
@@ -233,94 +267,117 @@ DISTRO_PN_ALIAS_pn-matchbox-panel-2 = "Debian=matchbox-panel Mandriva=matchbox-p
 DISTRO_PN_ALIAS_pn-matchbox-session = "OpenedHand"
 DISTRO_PN_ALIAS_pn-matchbox-session-sato = "OpenedHand"
 DISTRO_PN_ALIAS_pn-matchbox-terminal = "OpenedHand"
-DISTRO_PN_ALIAS_pn-matchbox-theme-sato-2 = "OpenedHand"
 DISTRO_PN_ALIAS_pn-matchbox-theme-sato = "OpenedHand"
+DISTRO_PN_ALIAS_pn-matchbox-theme-sato-2 = "OpenedHand"
 DISTRO_PN_ALIAS_pn-matchbox-themes-extra = "Ubuntu=matchbox-themes-extra Mandriva=matchbox-themes-extra"
 DISTRO_PN_ALIAS_pn-matchbox-themes-gtk = "OpenedHand"
-DISTRO_PN_ALIAS_pn-matchbox-wm-2 = "Mandriva=matchbox-window-manager Debian=matchbox-window-manager"
 DISTRO_PN_ALIAS_pn-matchbox-wm = "OpenedHand"
+DISTRO_PN_ALIAS_pn-matchbox-wm-2 = "Mandriva=matchbox-window-manager Debian=matchbox-window-manager"
 DISTRO_PN_ALIAS_pn-menu-cache = "OSPDT"
 DISTRO_PN_ALIAS_pn-mesa = "Fedora=mesa Ubuntu=libgl1-mesa-dri"
+DISTRO_PN_ALIAS_pn-mesa-gl = "Fedora=mesa Ubuntu=libgl1-mesa-dri"
 DISTRO_PN_ALIAS_pn-mesa-glsl-native = "Fedora=mesa Ubuntu=libgl1-mesa-dri"
 DISTRO_PN_ALIAS_pn-meta-environment-i586 = "OE-Core"
+DISTRO_PN_ALIAS_pn-meta-environment-qemux86 = "OE-Core"
+DISTRO_PN_ALIAS_pn-meta-environment-qemux86-64 = "OE-Core"
 DISTRO_PN_ALIAS_pn-meta-ide-support = "OE-Core"
-DISTRO_PN_ALIAS_pn-meta-toolchain-gmae = "OE-Core"
 DISTRO_PN_ALIAS_pn-meta-toolchain = "OE-Core"
+DISTRO_PN_ALIAS_pn-meta-toolchain-gmae = "OE-Core"
+DISTRO_PN_ALIAS_pn-meta-toolchain-qt = "OE-Core"
 DISTRO_PN_ALIAS_pn-meta-toolchain-qte = "OE-Core"
-DISTRO_PN_ALIAS_pn-mkfontdir = "Mandriva=mkfontdir Ubuntu=xfonts-utils Fedora=xorg-x11-font-utils"
 DISTRO_PN_ALIAS_pn-meta-toolchain-sdk = "OE-Core"
 DISTRO_PN_ALIAS_pn-mini-x-session = "OSPDT"
+DISTRO_PN_ALIAS_pn-mkfontdir = "Mandriva=mkfontdir Ubuntu=xfonts-utils Fedora=xorg-x11-font-utils"
 DISTRO_PN_ALIAS_pn-mkfontscale = "Mandriva=mkfontscale Ubuntu=xfonts-utils Fedora=xorg-x11-font-utils"
 DISTRO_PN_ALIAS_pn-mktemp = "Mandriva=mktemp Fedora=mktemp"
 DISTRO_PN_ALIAS_pn-moblin-proto = "OE-Core"
 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-mtd-utils = "Debian=mtd-utils Ubuntu=mtd-utils"
+DISTRO_PN_ALIAS_pn-mx-1.0 = "Ubuntu=mx Debian=mx Fedora=mx"
 DISTRO_PN_ALIAS_pn-n450-audio = "Intel"
+DISTRO_PN_ALIAS_pn-nativesdk-libusb1 = "Debian=libusb-1.0-0 Fedora=libusb1"
+DISTRO_PN_ALIAS_pn-nativesdk-lzo = "Debian=liblzo Ubuntu=liblzo Fedora=lzp"
+DISTRO_PN_ALIAS_pn-nativesdk-packagegroup-qt-toolchain-host = "OE-Core"
+DISTRO_PN_ALIAS_pn-nativesdk-pkgconfig = "Ubuntu=pkg-config Fedora=pkgconfig"
+DISTRO_PN_ALIAS_pn-nativesdk-python-git = "Debian=python-git Fedora=GitPython"
+DISTRO_PN_ALIAS_pn-nativesdk-readline = "Fedora=readline Ubuntu=readline-common"
 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-nss-myhostname = "Meego=nss-mdns OpenSuSE=nss-mdns Ubuntu=nss-mdns Mandriva=nss_mdns Debian=nss-mdns"
 DISTRO_PN_ALIAS_pn-ocf-linux = "OSPDT"
 DISTRO_PN_ALIAS_pn-ofono = "Debian=ofono Ubuntu=ofono"
 DISTRO_PN_ALIAS_pn-oh-puzzles = "OpenedHand"
+DISTRO_PN_ALIAS_pn-opkg = "OSPDT upstream=http://svn.openmoko.org/trunk/src/tar"
 DISTRO_PN_ALIAS_pn-opkg-collateral = "OE-Core"
 DISTRO_PN_ALIAS_pn-opkg-config-base = "OE-Core"
 DISTRO_PN_ALIAS_pn-opkg-nogpg = "OSPDT upstream=http://svn.openmoko.org/trunk/src/tar"
-DISTRO_PN_ALIAS_pn-opkg = "OSPDT upstream=http://svn.openmoko.org/trunk/src/tar"
 DISTRO_PN_ALIAS_pn-opkg-utils = "OSPDT upstream=http://svn.openmoko.org/trunk/src/target/opkg/"
 DISTRO_PN_ALIAS_pn-oprofileui = "Fedora=oprofileui Ubuntu=oprofile-gui Debian=oprofile-gui"
 DISTRO_PN_ALIAS_pn-oprofileui-server = "Fedora=oprofileui Ubuntu=oprofile-gui Debian=oprofile-gui"
 DISTRO_PN_ALIAS_pn-owl-video = "OpenedHand"
-DISTRO_PN_ALIAS_pn-package-index = "OE-Core"
 DISTRO_PN_ALIAS_pn-packagegroup-base = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core = "OE-Core"
 DISTRO_PN_ALIAS_pn-packagegroup-core-basic = "OE-Core"
 DISTRO_PN_ALIAS_pn-packagegroup-core-boot = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core-buildessential = "OE-Core"
 DISTRO_PN_ALIAS_pn-packagegroup-core-clutter = "OE-Core"
 DISTRO_PN_ALIAS_pn-packagegroup-core-console = "OE-Core"
 DISTRO_PN_ALIAS_pn-packagegroup-core-device-devel = "OE-Core"
 DISTRO_PN_ALIAS_pn-packagegroup-core-directfb = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core-eclipse-debug = "OE-Core"
 DISTRO_PN_ALIAS_pn-packagegroup-core-lsb = "OE-Core"
 DISTRO_PN_ALIAS_pn-packagegroup-core-nfs = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-core = "OE-Core"
 DISTRO_PN_ALIAS_pn-packagegroup-core-qt = "OE-Core"
 DISTRO_PN_ALIAS_pn-packagegroup-core-qt4e = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-core-sdk-gmae = "OE-Core"
 DISTRO_PN_ALIAS_pn-packagegroup-core-sdk = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core-sdk-gmae = "OE-Core"
 DISTRO_PN_ALIAS_pn-packagegroup-core-ssh-dropbear = "OE-Core"
 DISTRO_PN_ALIAS_pn-packagegroup-core-ssh-openssh = "OE-Core"
 DISTRO_PN_ALIAS_pn-packagegroup-core-standalone-gmae-sdk-target = "OE-Core"
 DISTRO_PN_ALIAS_pn-packagegroup-core-standalone-sdk-target = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-core-tools-debug = "OE-Core"
 DISTRO_PN_ALIAS_pn-packagegroup-core-tools = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core-tools-debug = "OE-Core"
 DISTRO_PN_ALIAS_pn-packagegroup-core-tools-profile = "OE-Core"
 DISTRO_PN_ALIAS_pn-packagegroup-core-tools-testapps = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-core-x11-mini = "OE-Core"
 DISTRO_PN_ALIAS_pn-packagegroup-core-x11 = "OE-Core"
 DISTRO_PN_ALIAS_pn-packagegroup-core-x11-base = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core-x11-mini = "OE-Core"
 DISTRO_PN_ALIAS_pn-packagegroup-core-x11-sato = "OE-Core"
 DISTRO_PN_ALIAS_pn-packagegroup-core-x11-xserver = "OE-Core"
 DISTRO_PN_ALIAS_pn-packagegroup-cross-canadian-i586 = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-cross-canadian-qemux86 = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-cross-canadian-qemux86-64 = "OE-Core"
 DISTRO_PN_ALIAS_pn-packagegroup-qt4e = "OE-Core"
 DISTRO_PN_ALIAS_pn-packagegroup-qte-toolchain-host = "OE-Core"
 DISTRO_PN_ALIAS_pn-packagegroup-qte-toolchain-target = "Intel"
+DISTRO_PN_ALIAS_pn-packagegroup-qt-toolchain-target = "OE-Core"
 DISTRO_PN_ALIAS_pn-packagegroup-sdk-host = "OE-Core"
 DISTRO_PN_ALIAS_pn-packagegroup-self-hosted = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-toolset-native = "OE-Core"
+DISTRO_PN_ALIAS_pn-package-index = "OE-Core"
 DISTRO_PN_ALIAS_pn-perf = "OSPDT"
+DISTRO_PN_ALIAS_pn-pkgconfig = "Ubuntu=pkg-config Fedora=pkgconfig"
+DISTRO_PN_ALIAS_pn-pkgconfig-native = "Ubuntu=pkg-config Fedora=pkgconfig"
 DISTRO_PN_ALIAS_pn-pointercal = "OE-Core"
+DISTRO_PN_ALIAS_pn-pointercal-xinput = "OE-Core"
 DISTRO_PN_ALIAS_pn-poky-feed-config-opkg = "OE-Core"
 DISTRO_PN_ALIAS_pn-pong-clock = "OpenedHand"
-DISTRO_PN_ALIAS_pn-portmap = "OpenSuSE=portmap"
-DISTRO_PN_ALIAS_pn-powertop ="Meego=powertop Fedora=powertop Debian=powertop OpenSuSE=powertop Mandriva=powertop"
+DISTRO_PN_ALIAS_pn-portmap = "Debian=rpcbind Fedora=rpcbind"
+DISTRO_PN_ALIAS_pn-powertop = "Meego=powertop Fedora=powertop Debian=powertop OpenSuSE=powertop Mandriva=powertop"
 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-argparse = "Fedora=python-argparse OpenSuSE=python-argparse"
+DISTRO_PN_ALIAS_pn-python-argparse-native = "Fedora=python-argparse OpenSuSE=python-argparse"
 DISTRO_PN_ALIAS_pn-python-dbus = "Ubuntu=python-dbus Debian=python-dbus Mandriva=python-dbus"
+DISTRO_PN_ALIAS_pn-python-git = "Debian=python-git Fedora=GitPython"
 DISTRO_PN_ALIAS_pn-python-gst = "OpenSuSE=python-gstreamer Ubuntu=gst0.10-python Debian=gst0.10-python"
 DISTRO_PN_ALIAS_pn-python-pycairo = "Meego=pycairo Fedora=pycairo Ubuntu=pycairo Debian=pycairo"
 DISTRO_PN_ALIAS_pn-python-pycurl = "Debian=python-pycurl Ubuntu=python-pycurl"
@@ -329,18 +386,18 @@ DISTRO_PN_ALIAS_pn-python-pygtk = "Debian=python-gtk2 Fedora=pygtk2 OpenSuSE=pyt
 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-smartpm = "Debian=smart OpenSuSE=smart"
 DISTRO_PN_ALIAS_pn-python-ZSI = "OE-Core"
-DISTRO_PN_ALIAS_pn-qemu-helper = "OpenedHand"
 DISTRO_PN_ALIAS_pn-qemu-config = "OpenedHand"
 DISTRO_PN_ALIAS_pn-qemugl = "OpenedHand"
+DISTRO_PN_ALIAS_pn-qemu-helper = "OpenedHand"
 DISTRO_PN_ALIAS_pn-qemu-helper-native = "OpenedHand"
 DISTRO_PN_ALIAS_pn-qemu-helper-nativesdk = "OpenedHand"
-DISTRO_PN_ALIAS_pn-qmmp = "Fedora=qmmp"
+DISTRO_PN_ALIAS_pn-qemuwrapper-cross = "OE-Core"
+DISTRO_PN_ALIAS_pn-qmmp = "Fedora=qmmp Debian=qmmp"
 DISTRO_PN_ALIAS_pn-qt4e-demo-image = "OE-Core"
 DISTRO_PN_ALIAS_pn-qt4-embedded = "OSPDT"
 DISTRO_PN_ALIAS_pn-qt4-graphics-system = "OE-Core"
-DISTRO_PN_ALIAS_pn-qt4-native = "Fedora=qt4 Debian=qt4-dev-tools"
 DISTRO_PN_ALIAS_pn-qt4-native = "Mandriva=libqt4-devel Ubuntu=libqt4-dev"
 DISTRO_PN_ALIAS_pn-qt4-tools = "Mandriva=libqt4-devel Ubuntu=libqt4-dev"
 DISTRO_PN_ALIAS_pn-qt4-x11-free = "Ubuntu=qt-x11-free Debian=qt-x11-free"
@@ -349,6 +406,8 @@ DISTRO_PN_ALIAS_pn-qt-mobility-embedded = "Ubuntu=qtmobility-dev Debian=qtmobili
 DISTRO_PN_ALIAS_pn-qt-mobility-x11 = "Ubuntu=qtmobility-dev Debian=qtmobility-dev"
 DISTRO_PN_ALIAS_pn-quicky = "OSPDT"
 DISTRO_PN_ALIAS_pn-randrproto = "Meego=xorg-x11-proto-randrproto"
+DISTRO_PN_ALIAS_pn-readline = "Fedora=readline Debian=readline-common"
+DISTRO_PN_ALIAS_pn-readline-native = "Fedora=readline Debian=readline-common"
 DISTRO_PN_ALIAS_pn-recordproto = "Meego=xorg-x11-proto-recordproto"
 DISTRO_PN_ALIAS_pn-remake = "Mandriva=remake Debian=remake"
 DISTRO_PN_ALIAS_pn-renderproto = "Meego=xorg-x11-proto-renderproto"
@@ -359,9 +418,12 @@ DISTRO_PN_ALIAS_pn-rt-tests = "Debian=rt-tests Ubuntu=rt-tests"
 DISTRO_PN_ALIAS_pn-run-postinsts = "OE-Core"
 DISTRO_PN_ALIAS_pn-sato-icon-theme = "OpenedHand"
 DISTRO_PN_ALIAS_pn-sato-screenshot = "OpenedHand"
+DISTRO_PN_ALIAS_pn-sbc = "Fedora=sbc Debian=libsbc1"
 DISTRO_PN_ALIAS_pn-screenshot = "OpenedHand"
 DISTRO_PN_ALIAS_pn-scrnsaverproto = "Meego=xorg-x11-proto-scrnsaverproto Ubuntu=x11proto-scrnsaver-dev Debian=x11proto-scrnsaver-dev"
 DISTRO_PN_ALIAS_pn-settings-daemon = "OpenedHand"
+DISTRO_PN_ALIAS_pn-sgml-common = "OpenSuSE=sgml-common Fedora=sgml-common"
+DISTRO_PN_ALIAS_pn-sgml-common-native = "OpenSuSE=sgml-common Fedora=sgml-common"
 DISTRO_PN_ALIAS_pn-sgmlspl = "Debian=sgmlspl Ubuntu=sgmlspl"
 DISTRO_PN_ALIAS_pn-shadow-securetty = "Ubuntu=shadow Fedora=shadow"
 DISTRO_PN_ALIAS_pn-shadow-sysroot = "Ubuntu=shadow Fedora=shadow"
@@ -370,9 +432,12 @@ DISTRO_PN_ALIAS_pn-shutdown-desktop = "OpenedHand"
 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-sysklogd = "Debian=sysklogd Mandriva=sysklogd"
+DISTRO_PN_ALIAS_pn-sysprof = "Fedora=sysprof Debian=sysprof"
 DISTRO_PN_ALIAS_pn-systemd-compat-units = "Fedora=systemd Ubuntu=systemd"
+DISTRO_PN_ALIAS_pn-systemd-systemctl-native = "OE-Core"
 DISTRO_PN_ALIAS_pn-systemd-systemdctl-native = "Fedora=systemd Ubuntu=systemd"
+DISTRO_PN_ALIAS_pn-systemtap-uprobes = "Ubuntu=systemtap Debian=systemtap"
 DISTRO_PN_ALIAS_pn-sysvinit-inittab = "OE-Core"
 DISTRO_PN_ALIAS_pn-table = "Intel"
 DISTRO_PN_ALIAS_pn-tar-replacement-native = "OE-Core"
@@ -400,14 +465,16 @@ DISTRO_PN_ALIAS_pn-videoproto = "Meego=xorg-x11-proto-videoproto"
 DISTRO_PN_ALIAS_pn-watchdog = "Debian=watchdog Ubuntu=watchdog Mandriva=watchdog"
 DISTRO_PN_ALIAS_pn-webkit-gtk = "Fedora=webkitgtk Ubuntu=libwebkit"
 DISTRO_PN_ALIAS_pn-web-webkit = "OpenedHand"
+DISTRO_PN_ALIAS_pn-weston = "Fedora=weston OpenSuSE=weston"
+DISTRO_PN_ALIAS_pn-weston-init = "OE-Core"
 DISTRO_PN_ALIAS_pn-which = "Mandriva=which Fedora=which"
 DISTRO_PN_ALIAS_pn-wpa-supplicant = "Meego=wpa_supplicant Fedora=wpa_supplicant OpenSuSE=wpa_supplicant Ubuntu=wpasupplicant Mandriva=wpa_supplicant Debian=wpasupplicant"
 DISTRO_PN_ALIAS_pn-x11-common = "OE-Core"
 DISTRO_PN_ALIAS_pn-x11perf = "Fedora=xorg-x11-apps Ubuntu=x11-apps"
 DISTRO_PN_ALIAS_pn-x11vnc = "Fedora=x11vnc Ubuntu=x11vnc"
-DISTRO_PN_ALIAS_pn-xcb-util-wm = "Debian=xcb-util Fedora=xcb-util"
 DISTRO_PN_ALIAS_pn-xcb-util-image = "Debian=xcb-util Fedora=xcb-util"
 DISTRO_PN_ALIAS_pn-xcb-util-keysyms = "Debian=xcb-util Fedora=xcb-util"
+DISTRO_PN_ALIAS_pn-xcb-util-wm = "Debian=xcb-util Fedora=xcb-util"
 DISTRO_PN_ALIAS_pn-xcmiscproto = "Meego=xorg-x11-proto-xcmiscproto"
 DISTRO_PN_ALIAS_pn-xcursor-transparent-theme = "OpenedHand"
 DISTRO_PN_ALIAS_pn-xdpyinfo = "Fedora=xorg-x11-utils Ubuntu=x11-utils"
@@ -426,15 +493,17 @@ DISTRO_PN_ALIAS_pn-xf86miscproto = "Meego=xorg-x11-proto-xf86miscproto"
 DISTRO_PN_ALIAS_pn-xf86rushproto = "Meego=xorg-x11-proto-xf86rushproto"
 DISTRO_PN_ALIAS_pn-xf86-video-fbdev = "Ubuntu=xserver-xorg-video-fbdev Debian=xserver-xorg-video-fbdev"
 DISTRO_PN_ALIAS_pn-xf86-video-intel = "Debian=xserver-xorg-video-intel Fedora=xorg-x11-drv-intel Mandriva=x11-driver-video-intel Meego=xorg-x11-drv-intel Ubuntu=xserver-xorg-video-intel"
+DISTRO_PN_ALIAS_pn-xf86-video-modesetting = "Debian=xserver-xorg-video-modesetting Fedora=xf86-video-modesetting"
+DISTRO_PN_ALIAS_pn-xf86-video-omap = "Ubuntu=xf86-video-omap Debian=xf86-video-omap"
 DISTRO_PN_ALIAS_pn-xf86-video-omapfb = "OSPDT"
 DISTRO_PN_ALIAS_pn-xf86-video-vesa = "Debian=xserver-xorg-video-vesa Fedora=xorg-x11-drv-vesa Mandriva=x11-driver-video-vesa Ubuntu=xserver-xorg-video-vesa"
 DISTRO_PN_ALIAS_pn-xf86-video-vmware = "Debian=xserver-xorg-video-vmware Fedora=xorg-x11-drv-vmware Mandriva=x11-driver-video-vmware Ubuntu=xserver-xorg-video-vmware"
 DISTRO_PN_ALIAS_pn-xf86vidmodeproto = "Meego=xorg-x11-proto-xf86vidmodeproto Ubuntu=x11proto-xf86vidmode Debian=x11proto-xf86vidmode"
 DISTRO_PN_ALIAS_pn-xhost = "Ubuntu=x11-xserver-utils Fedora=xorg-x11-server-utils"
 DISTRO_PN_ALIAS_pn-xineramaproto = "Meego=xorg-x11-proto-xineramaproto Ubuntu=x11proto-xinerama Debian=x11proto-xinerama"
+DISTRO_PN_ALIAS_pn-xinput-calibrator = "Fedora=xinput-calibrator Mandravia=xinput-calibrator Ubuntu=xinput-calibrator"
 DISTRO_PN_ALIAS_pn-xkbcomp = "Ubuntu=x11-xkb-utils Fedora=xorg-x11-xkb-utils"
 DISTRO_PN_ALIAS_pn-xmodmap = "Meego=xorg-x11-utils-xmodmap Fedora=xorg-x11-server-utils Ubuntu=x11-xserver-utils"
-DISTRO_PN_ALIAS_pn-xorg-cf-files = "OE-Core"
 DISTRO_PN_ALIAS_pn-xorg-minimal-fonts = "Ubuntu=xfonts-base Fedora=xorg-x11-fonts-base"
 DISTRO_PN_ALIAS_pn-xprop = "Meego=xorg-x11-utils-xprop Fedora=xorg-x11-utils Ubuntu=x11-utils"
 DISTRO_PN_ALIAS_pn-xproto = "Meego=xorg-x11-proto-xproto Fedora=xorg-x11-proto-devel Ubuntu=x11proto-core-dev Debian=x11proto-core-dev Opensuse=xorg-x11-proto-devel Mandriva=x11-proto-devel"
@@ -448,6 +517,7 @@ DISTRO_PN_ALIAS_pn-xserver-xf86-lite = "Fedora=xorg-x11-server Ubuntu=xserver-xo
 DISTRO_PN_ALIAS_pn-xserver-xorg = "Fedora=xorg-x11-server Ubuntu=xserver-xorg"
 DISTRO_PN_ALIAS_pn-xset = "Fedora=xorg-x11-server-utils Ubuntu=x11-xserver-utils Debian=x11-xserver-utils Opensuse=xorg-x11"
 DISTRO_PN_ALIAS_pn-xtscal = "OSPDT upstream=http://gpe.linuxtogo.org/download/source/"
+DISTRO_PN_ALIAS_pn-xuser-account = "OE-Core"
 DISTRO_PN_ALIAS_pn-xvideo-tests = "OpenedHand"
 DISTRO_PN_ALIAS_pn-xvinfo = "Fedora=xorg-x11-utils Ubuntu=x11-utils"
 DISTRO_PN_ALIAS_pn-xwininfo = "Fedora=xorg-x11-utils Ubuntu=x11-utils"

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

@@ -35,7 +35,6 @@ 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 = "Paul Eggleton <paul.eggleton@linux.intel.com>"
 RECIPE_MAINTAINER_pn-apmd = "Cristian Iorga <cristian.iorga@intel.com>"
 RECIPE_MAINTAINER_pn-apr = "Cristiana Voicu <cristiana.voicu@intel.com>"
 RECIPE_MAINTAINER_pn-apr-util = "Cristiana Voicu <cristiana.voicu@intel.com>"
@@ -43,6 +42,8 @@ RECIPE_MAINTAINER_pn-apt = "Cristiana Voicu <cristiana.voicu@intel.com>"
 RECIPE_MAINTAINER_pn-aspell = "Cristiana Voicu <cristiana.voicu@intel.com>"
 RECIPE_MAINTAINER_pn-atk = "Cristiana Voicu <cristiana.voicu@intel.com>"
 RECIPE_MAINTAINER_pn-at = "Cristiana Voicu <cristiana.voicu@intel.com>"
+RECIPE_MAINTAINER_pn-at-spi2-atk = "Cristiana Voicu <cristiana.voicu@intel.com>"
+RECIPE_MAINTAINER_pn-at-spi2-core = "Cristiana Voicu <cristiana.voicu@intel.com>"
 RECIPE_MAINTAINER_pn-attr = "Saul Wold <sgw@linux.intel.com>"
 RECIPE_MAINTAINER_pn-augeas = "Paul Eggleton <paul.eggleton@linux.intel.com>"
 RECIPE_MAINTAINER_pn-autoconf = "Laurentiu Palcu <laurentiu.palcu@intel.com>"
@@ -64,6 +65,7 @@ RECIPE_MAINTAINER_pn-bison = "Laurentiu Palcu <laurentiu.palcu@intel.com>"
 RECIPE_MAINTAINER_pn-blktool = "Paul Eggleton <paul.eggleton@linux.intel.com>"
 RECIPE_MAINTAINER_pn-blktrace = "Tom Zanussi <tom.zanussi@intel.com>"
 RECIPE_MAINTAINER_pn-bluez4 = "Cristian Iorga <cristian.iorga@intel.com>"
+RECIPE_MAINTAINER_pn-bluez5 = "Cristian Iorga <cristian.iorga@intel.com>"
 RECIPE_MAINTAINER_pn-bluez-hcidump = "Cristian Iorga <cristian.iorga@intel.com>"
 RECIPE_MAINTAINER_pn-boost = "Saul Wold <sgw@linux.intel.com>"
 RECIPE_MAINTAINER_pn-btrfs-tools = "Laurentiu Palcu <laurentiu.palcu@intel.com>"
@@ -82,9 +84,11 @@ RECIPE_MAINTAINER_pn-chrpath = "Paul Eggleton <paul.eggleton@linux.intel.com>"
 RECIPE_MAINTAINER_pn-clutter-gst-1.0 = "Ross Burton <ross.burton@intel.com>"
 RECIPE_MAINTAINER_pn-clutter-gtk-1.0 = "Ross Burton <ross.burton@intel.com>"
 RECIPE_MAINTAINER_pn-clutter = "Ross Burton <ross.burton@intel.com>"
+RECIPE_MAINTAINER_pn-clutter-1.0 = "Ross Burton <ross.burton@intel.com>"
 RECIPE_MAINTAINER_pn-cmake-native = "Paul Eggleton <paul.eggleton@linux.intel.com>"
 RECIPE_MAINTAINER_pn-cmake = "Paul Eggleton <paul.eggleton@linux.intel.com>"
 RECIPE_MAINTAINER_pn-cogl = "Ross Burton <ross.burton@intel.com>"
+RECIPE_MAINTAINER_pn-cogl-1.0 = "Ross Burton <ross.burton@intel.com>"
 RECIPE_MAINTAINER_pn-compositeproto = "Ross Burton <ross.burton@intel.com>"
 RECIPE_MAINTAINER_pn-connman = "Cristian Iorga <cristian.iorga@intel.com>"
 RECIPE_MAINTAINER_pn-connman-gnome = "Cristian Iorga <cristian.iorga@intel.com>"
@@ -202,6 +206,7 @@ RECIPE_MAINTAINER_pn-gpgme = "Paul Eggleton <paul.eggleton@linux.intel.com>"
 RECIPE_MAINTAINER_pn-grep = "Cristiana Voicu <cristiana.voicu@intel.com>"
 RECIPE_MAINTAINER_pn-groff = "Valentin Popa <valentin.popa@intel.com>"
 RECIPE_MAINTAINER_pn-grub = "Paul Eggleton <paul.eggleton@linux.intel.com>"
+RECIPE_MAINTAINER_pn-gsettings-desktop-schemas = "Valentin Popa <valentin.popa@intel.com>"
 RECIPE_MAINTAINER_pn-gst-ffmpeg = "Cristian Iorga <cristian.iorga@intel.com>"
 RECIPE_MAINTAINER_pn-gst-fluendo-mp3 = "Cristian Iorga <cristian.iorga@intel.com>"
 RECIPE_MAINTAINER_pn-gst-fluendo-mpegdemux = "Cristian Iorga <cristian.iorga@intel.com>"
@@ -240,7 +245,6 @@ RECIPE_MAINTAINER_pn-hostap-utils = "Cristian Iorga <cristian.iorga@intel.com>"
 RECIPE_MAINTAINER_pn-hwlatdetect = "Darren Hart <dvhart@linux.intel.com>"
 RECIPE_MAINTAINER_pn-icecc-create-env-native = "Saul Wold <sgw@linux.intel.com>"
 RECIPE_MAINTAINER_pn-icu = "Valentin Popa <valentin.popa@intel.com>"
-RECIPE_MAINTAINER_pn-imake = "Cristiana Voicu <cristiana.voicu@intel.com>"
 RECIPE_MAINTAINER_pn-initramfs-boot = "Saul Wold <sgw@linux.intel.com>"
 RECIPE_MAINTAINER_pn-initramfs-framework = "Saul Wold <sgw@linux.intel.com>"
 RECIPE_MAINTAINER_pn-initramfs-live-boot = "Saul Wold <sgw@linux.intel.com>"
@@ -278,6 +282,7 @@ RECIPE_MAINTAINER_pn-libart-lgpl = "Ross Burton <ross.burton@intel.com>"
 RECIPE_MAINTAINER_pn-libassuan = "Cristiana Voicu <cristiana.voicu@intel.com>"
 RECIPE_MAINTAINER_pn-libatomics-ops = "Cristian Iorga <cristian.iorga@intel.com>"
 RECIPE_MAINTAINER_pn-libav = "Paul Eggleton <paul.eggleton@linux.intel.com>"
+RECIPE_MAINTAINER_pn-libbsd = "Saul Wold <sgw@linux.intel.com>"
 RECIPE_MAINTAINER_pn-libcap = "Saul Wold <sgw@linux.intel.com>"
 RECIPE_MAINTAINER_pn-libcgroup = "Saul Wold <sgw@linux.intel.com>"
 RECIPE_MAINTAINER_pn-libcheck = "Saul Wold <sgw@linux.intel.com>"
@@ -315,6 +320,7 @@ RECIPE_MAINTAINER_pn-libmpc = "Laurentiu Palcu <laurentiu.palcu@intel.com>"
 RECIPE_MAINTAINER_pn-libnewt = "Kai Kang <kai.kang@windriver.com>"
 RECIPE_MAINTAINER_pn-libnfsidmap = "Paul Eggleton <paul.eggleton@linux.intel.com>"
 RECIPE_MAINTAINER_pn-libnl = "Saul Wold <sgw@linux.intel.com>"
+RECIPE_MAINTAINER_pn-libnotify = "Ross Burton <ross.burton@intel.com>"
 RECIPE_MAINTAINER_pn-libnss-mdns = "Saul Wold <sgw@linux.intel.com>"
 RECIPE_MAINTAINER_pn-libogg = "Cristian Iorga <cristian.iorga@intel.com>"
 RECIPE_MAINTAINER_pn-liboil = "Cristiana Voicu <cristiana.voicu@intel.com>"
@@ -437,6 +443,7 @@ RECIPE_MAINTAINER_pn-meta-ide-support = "Jessica Zhang <jessica.zhang@intel.com>
 RECIPE_MAINTAINER_pn-meta-toolchain-gmae = "Jessica Zhang <jessica.zhang@intel.com>"
 RECIPE_MAINTAINER_pn-meta-toolchain-qte = "Paul Eggleton <paul.eggleton@linux.intel.com>"
 RECIPE_MAINTAINER_pn-meta-toolchain = "Jessica Zhang <jessica.zhang@intel.com>"
+RECIPE_MAINTAINER_pn-midori = "Ross Burton <ross.burton@intel.com>"
 RECIPE_MAINTAINER_pn-mingetty = "Kai Kang <kai.kang@windriver.com>"
 RECIPE_MAINTAINER_pn-minicom = "Cristian Iorga <cristian.iorga@intel.com>"
 RECIPE_MAINTAINER_pn-mini-x-session = "Saul Wold <sgw@linux.intel.com>"
@@ -545,6 +552,7 @@ RECIPE_MAINTAINER_pn-puzzles = "Valentin Popa <valentin.popa@intel.com>"
 RECIPE_MAINTAINER_pn-python-argparse = "Laurentiu Palcu <laurentiu.palcu@intel.com>"
 RECIPE_MAINTAINER_pn-python = "Laurentiu Palcu <laurentiu.palcu@intel.com>"
 RECIPE_MAINTAINER_pn-python-dbus = "Laurentiu Palcu <laurentiu.palcu@intel.com>"
+RECIPE_MAINTAINER_pn-python-docutils = "Laurentiu Palcu <laurentiu.palcu@intel.com>"
 RECIPE_MAINTAINER_pn-python-gst = "Laurentiu Palcu <laurentiu.palcu@intel.com>"
 RECIPE_MAINTAINER_pn-python-imaging = "Laurentiu Palcu <laurentiu.palcu@intel.com>"
 RECIPE_MAINTAINER_pn-python-pycairo = "Laurentiu Palcu <laurentiu.palcu@intel.com>"
@@ -636,7 +644,6 @@ RECIPE_MAINTAINER_pn-tiff = "Saul Wold <sgw@linux.intel.com>"
 RECIPE_MAINTAINER_pn-time = "Saul Wold <sgw@linux.intel.com>"
 RECIPE_MAINTAINER_pn-tiny-init = "Saul Wold <sgw@linux.intel.com>"
 RECIPE_MAINTAINER_pn-trace-cmd = "Darren Hart <dvhart@linux.intel.com>"
-RECIPE_MAINTAINER_pn-transfig = "Cristiana Voicu <cristiana.voicu@intel.com>"
 RECIPE_MAINTAINER_pn-tremor = "Cristian Iorga <cristian.iorga@intel.com>"
 RECIPE_MAINTAINER_pn-tslib = "Paul Eggleton <paul.eggleton@linux.intel.com>"
 RECIPE_MAINTAINER_pn-ttf-bitstream-vera = "Valentin Popa <valentin.popa@intel.com>"
@@ -655,6 +662,7 @@ RECIPE_MAINTAINER_pn-usbutils = "Cristiana Voicu <cristiana.voicu@intel.com>"
 RECIPE_MAINTAINER_pn-util-linux = "Saul Wold <sgw@linux.intel.com>"
 RECIPE_MAINTAINER_pn-util-macros = "Saul Wold <sgw@linux.intel.com>"
 RECIPE_MAINTAINER_pn-v86d = "Laurentiu Palcu <laurentiu.palcu@intel.com>"
+RECIPE_MAINTAINER_pn-vala = "Ross Burton <ross.burton@intel.com>"
 RECIPE_MAINTAINER_pn-valgrind = "Cristiana Voicu <cristiana.voicu@intel.com>"
 RECIPE_MAINTAINER_pn-videoproto = "Valentin Popa <valentin.popa@intel.com>"
 RECIPE_MAINTAINER_pn-vte ="Saul Wold <sgw@linux.intel.com>"
@@ -705,10 +713,10 @@ RECIPE_MAINTAINER_pn-xineramaproto = "Laurentiu Palcu <laurentiu.palcu@intel.com
 RECIPE_MAINTAINER_pn-xinetd = "Laurentiu Palcu <laurentiu.palcu@intel.com>"
 RECIPE_MAINTAINER_pn-xinit = "Laurentiu Palcu <laurentiu.palcu@intel.com>"
 RECIPE_MAINTAINER_pn-xinput = "Laurentiu Palcu <laurentiu.palcu@intel.com>"
+RECIPE_MAINTAINER_pn-xinput-calibrator = "Laurentiu Palcu <laurentiu.palcu@intel.com>"
 RECIPE_MAINTAINER_pn-xkbcomp = "Laurentiu Palcu <laurentiu.palcu@intel.com>"
 RECIPE_MAINTAINER_pn-xkeyboard-config = "Laurentiu Palcu <laurentiu.palcu@intel.com>"
 RECIPE_MAINTAINER_pn-xmodmap = "Laurentiu Palcu <laurentiu.palcu@intel.com>"
-RECIPE_MAINTAINER_pn-xorg-cf-files = "Saul Wold <sgw@linux.intel.com>"
 RECIPE_MAINTAINER_pn-xorg-minimal-fonts = "Laurentiu Palcu <laurentiu.palcu@intel.com>"
 RECIPE_MAINTAINER_pn-xprop = "Laurentiu Palcu <laurentiu.palcu@intel.com>"
 RECIPE_MAINTAINER_pn-xproto = "Laurentiu Palcu <laurentiu.palcu@intel.com>"

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

@@ -215,6 +215,8 @@ REGEX_pn-prelink = "(?P<pver>cross_prelink)"
 REGEX_URI_pn-psmisc = "http://sourceforge.net/projects/psmisc/files/psmisc/"
 REGEX_pn-psmisc = "[hH][rR][eE][fF]=\"http://sourceforge.net/projects/psmisc/files/psmisc/psmisc\-(?P<pver>((\d+[\.\-_]*)+))\.tar\.gz/download\""
 REGEX_URI_pn-python-argparse = "https://code.google.com/p/argparse/downloads/list"
+REGEX_URI_pn-python-docutils = "http://sourceforge.net/projects/docutils/files/docutils/"
+REGEX_pn-python-docutils = "[hH][rR][eE][fF]=\"/projects/docutils/files/docutils/(?P<pver>((\d+[\.\-_]*)+)).*/\""
 REGEX_URI_pn-python-pycurl = "http://pycurl.sourceforge.net/download/"
 REGEX_pn-python-pycurl = "[hH][rR][eE][fF]=\"pycurl-(?P<pver>((\d+[\.\-_]*)+)).tar.gz\""
 REGEX_URI_pn-python-scons = "http://sourceforge.net/projects/scons/files/scons/"
@@ -257,8 +259,6 @@ REGEX_URI_pn-tiff = "ftp://ftp.remotesensing.org/pub/libtiff/"
 REGEX_pn-tiff = "[hH][rR][eE][fF]=\"ftp://ftp.remotesensing.org:21/pub/libtiff/tiff-(?P<pver>((\d+[\.\-_]*)+))\.tar\.gz\""
 REGEX_URI_pn-tiff-native = "ftp://ftp.remotesensing.org/pub/libtiff/"
 REGEX_pn-tiff-native = "[hH][rR][eE][fF]=\"ftp://ftp.remotesensing.org:21/pub/libtiff/tiff-(?P<pver>((\d+[\.\-_]*)+))\.tar\.gz\""
-REGEX_URI_pn-transfig-native = "http://sourceforge.net/projects/mcj/files/mcj-source/"
-REGEX_pn-transfig-native = "[hH][rR][eE][fF]=\"http://sourceforge.net/projects/mcj/files/mcj-source/transfig.(?P<pver>((\d+[\.\-_]*)+[a-z]?)).tar.gz/download\""
 REGEX_URI_pn-tslib = "http://sourceforge.net/projects/tslib.berlios/files/"
 REGEX_pn-tslib = "[hH][rR][eE][fF]=\"http://sourceforge.net/projects/tslib.berlios/files/tslib\-(?P<pver>((\d+[\.\-_]*)+))\.tar\.bz2/download\""
 REGEX_URI_pn-tzdata = "ftp://ftp.iana.org/tz/releases/"

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

@@ -127,7 +127,6 @@ RECIPE_COLOR_pn-hostap-conf = "red"
 RECIPE_COLOR_pn-hostap-utils="yellow"
 RECIPE_COLOR_pn-icon-naming-utils = "red"
 RECIPE_COLOR_pn-icu = "yellow"
-RECIPE_COLOR_pn-imake = "red"
 RECIPE_COLOR_pn-initramfs-boot = "yellow"
 RECIPE_COLOR_pn-initramfs-live-boot = "yellow"
 RECIPE_COLOR_pn-initramfs-live-install = "yellow"
@@ -383,7 +382,6 @@ RECIPE_COLOR_pn-telepathy-gabble = "red"
 RECIPE_COLOR_pn-tidy = "red"
 RECIPE_COLOR_pn-time = "yellow"
 RECIPE_COLOR_pn-tinylogin = "yellow"
-RECIPE_COLOR_pn-transfig = "yellow"
 RECIPE_COLOR_pn-trapproto = "yellow"
 RECIPE_COLOR_pn-tslib = "yellow"
 RECIPE_COLOR_pn-ttf-bitstream-vera = "yellow"

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

@@ -137,11 +137,13 @@ RECIPE_UPSTREAM_VERSION_pn-libiconv = "1.14"
 RECIPE_UPSTREAM_DATE_pn-libiconv = "Aug 07, 2011"
 CHECK_DATE_pn-libiconv = "Aug 30, 2012"
 RECIPE_NO_UPDATE_REASON_pn-libnl = "libnl-3.2.2 is incompatible with libnl2, so no Upgrade"
-RECIPE_NO_UPDATE_REASON_pn-libpng = "1.4.3 and later changes the API and breaks libmatchbox. Sticking with the 1.2.x series instead"
 RECIPE_UPSTREAM_VERSION_pn-libsoup = "2.41.90"
+RECIPE_UPSTREAM_VERSION_pn-libpng = "1.6.6"
+RECIPE_UPSTREAM_DATE_pn-libpng = "Sep 16, 2013"
+CHECK_DATE_pn-libpng = "Oct 02, 2013"
 RECIPE_UPSTREAM_VERSION_pn-libpng12 = "1.2.50"
 RECIPE_UPSTREAM_DATE_pn-libpng12 = "Jul 10, 2012"
-CHECK_DATE_pn-libpng12 = "Aug 21, 2013"
+CHECK_DATE_pn-libpng12 = "Oct 02, 2013"
 RECIPE_UPSTREAM_DATE_pn-libsoup = "Feb 19, 2013"
 CHECK_DATE_pn-libsoup = "Mar 5, 2013"
 RECIPE_NO_UPDATE_REASON_pn-libsoup = "2.41.90 is unstable"
@@ -164,7 +166,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 = "Jun 10, 2013"
+CHECK_DATE_pn-minicom = "Oct 02, 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"
@@ -203,9 +205,9 @@ CHECK_DATE_pn-rpm = "Sep 03, 2012"
 RECIPE_UPSTREAM_VERSION_pn-run-postinsts = "check"
 RECIPE_NO_UPDATE_REASON_pn-sato-screenshot = "PRS Reports Incorrectly"
 RECIPE_NO_UPDATE_REASON_pn-socat = "2.0.0 is beta"
-RECIPE_UPSTREAM_VERSION_pn-sqlite3 = "3.7.17"
-RECIPE_UPSTREAM_DATE_pn-sqlite3 = "Aug 20, 2013"
-CHECK_DATE_pn-sqlite3= "Aug 21, 2013"
+RECIPE_UPSTREAM_VERSION_pn-sqlite3 = "3.8.0.2"
+RECIPE_UPSTREAM_DATE_pn-sqlite3 = "Sep 03, 2013"
+CHECK_DATE_pn-sqlite3= "Oct 02, 2013"
 RECIPE_UPSTREAM_VERSION_pn-squashfs-tools = "4.2"
 RECIPE_UPSTREAM_DATE_pn-squashfs-tools = "Feb 28, 2011"
 CHECK_DATE_pn-squashfs-tools = "Nov 09, 2012"

meta-yocto/conf/distro/poky.conf

@@ -1,7 +1,7 @@
 DISTRO = "poky"
-DISTRO_NAME = "Poky Next (Yocto Project Reference Distro)"
-DISTRO_VERSION = "1.4+snapshot-${DATE}"
-DISTRO_CODENAME = "next"
+DISTRO_NAME = "Poky (Yocto Project Reference Distro)"
+DISTRO_VERSION = "1.5.4"
+DISTRO_CODENAME = "dora"
 SDK_VENDOR = "-pokysdk"
 SDK_VERSION := "${@'${DISTRO_VERSION}'.replace('snapshot-${DATE}','snapshot')}"
 
@@ -72,21 +72,24 @@ CONNECTIVITY_CHECK_URIS ?= " \
              http://bugzilla.yoctoproject.org/report.cgi"
 
 SANITY_TESTED_DISTROS ?= " \
-            Poky-1.3 \n \
             Poky-1.4 \n \
+            Poky-1.5 \n \
             Ubuntu-12.04 \n \
             Ubuntu-12.10 \n \
             Ubuntu-13.04 \n \
-            Fedora-17 \n \
+            Ubuntu-13.10 \n \
             Fedora-18 \n \
-            CentOS-6.3 \n \
+            Fedora-19 \n \
+            Fedora-20 \n \
             CentOS-6.4 \n \
-            Debian-6.0 \n \
+            Debian-6.0.7 \n \
             Debian-7.0 \n \
             Debian-7.1 \n \
+            Debian-7.2 \n \
+            Debian-7.3 \n \
             SUSE-LINUX-12.2 \n \
             openSUSE-project-12.3 \n \
-	    "
+            "
 
 # Default hash policy for distro
 BB_SIGNATURE_HANDLER ?= 'OEBasicHash'

meta-yocto/conf/local.conf.sample

@@ -173,23 +173,9 @@ USER_CLASSES ?= "buildstats image-mklibs image-prelink"
 #
 # The build system can test booting virtual machine images under qemu (an emulator)
 # after any root filesystems are created and run tests against those images. To
-# enable this uncomment this line
-#IMAGETEST = "qemu"
-#
-# This variable controls which tests are run against virtual images if enabled
-# above. The following would enable bat, boot the test case under the sanity suite
-# and perform toolchain tests
-#TEST_SCEN = "sanity bat sanity:boot toolchain"
-#
-# Because of the QEMU booting slowness issue (see bug #646 and #618), the
-# autobuilder may suffer a timeout issue when running sanity tests. We introduce
-# the variable TEST_SERIALIZE here to reduce the time taken by the sanity tests.
-# It is set to 1 by default, which will boot the image and run cases in the same
-# image without rebooting or killing the machine instance. If it is set to 0, the
-# image will be copied and tested for each case, which will take longer but be
-# more precise.
-#TEST_SERIALIZE = "1"
-
+# enable this uncomment this line. See classes/testimage(-auto).bbclass for
+# further details.
+#TEST_IMAGE = "1"
 #
 # Interactive shell configuration
 #

meta-yocto/recipes-core/busybox/busybox_1.21.1.bbappend

@@ -1,2 +1,2 @@
-FILESEXTRAPATHS_prepend_poky := "${THISDIR}/${P}:"
+FILESEXTRAPATHS_prepend := "${THISDIR}/${BPN}:"
 

meta/classes/base.bbclass

@@ -210,7 +210,7 @@ def preferred_ml_updates(d):
             virt = "virtual/"
         for p in prefixes:
             if pkg != "kernel":
-                val = p + "-" + val
+                newval = p + "-" + val
 
             # implement variable keys
             localdata = bb.data.createCopy(d)
@@ -219,12 +219,12 @@ def preferred_ml_updates(d):
             bb.data.update_data(localdata)
             newname = localdata.expand(prov)
             if newname != prov and not d.getVar(newname, False):
-                d.setVar(newname, localdata.expand(val))
+                d.setVar(newname, localdata.expand(newval))
 
             # implement alternative multilib name
             newname = localdata.expand("PREFERRED_PROVIDER_" + virt + p + "-" + pkg)
             if not d.getVar(newname, False):
-                d.setVar(newname, val)
+                d.setVar(newname, newval)
         # Avoid future variable key expansion
         provexp = d.expand(prov)
         if prov != provexp and d.getVar(prov, False):
@@ -433,7 +433,7 @@ python () {
         extradeps = []
         extrardeps = []
         extraconf = []
-        for flag, flagval in pkgconfigflags.items():
+        for flag, flagval in sorted(pkgconfigflags.items()):
             if flag == "defaultval":
                 continue
             items = flagval.split(",")
@@ -485,14 +485,15 @@ python () {
     # If we're building a target package we need to use fakeroot (pseudo)
     # in order to capture permissions, owners, groups and special files
     if not bb.data.inherits_class('native', d) and not bb.data.inherits_class('cross', d):
-        d.setVarFlag('do_configure', 'umask', 022)
-        d.setVarFlag('do_compile', 'umask', 022)
+        d.setVarFlag('do_unpack', 'umask', '022')
+        d.setVarFlag('do_configure', 'umask', '022')
+        d.setVarFlag('do_compile', 'umask', '022')
         d.appendVarFlag('do_install', 'depends', ' virtual/fakeroot-native:do_populate_sysroot')
         d.setVarFlag('do_install', 'fakeroot', 1)
-        d.setVarFlag('do_install', 'umask', 022)
+        d.setVarFlag('do_install', 'umask', '022')
         d.appendVarFlag('do_package', 'depends', ' virtual/fakeroot-native:do_populate_sysroot')
         d.setVarFlag('do_package', 'fakeroot', 1)
-        d.setVarFlag('do_package', 'umask', 022)
+        d.setVarFlag('do_package', 'umask', '022')
         d.setVarFlag('do_package_setscene', 'fakeroot', 1)
         d.appendVarFlag('do_package_setscene', 'depends', ' virtual/fakeroot-native:do_populate_sysroot')
         d.setVarFlag('do_devshell', 'fakeroot', 1)
@@ -581,6 +582,10 @@ python () {
     if ".zip" in srcuri:
         d.appendVarFlag('do_unpack', 'depends', ' unzip-native:do_populate_sysroot')
 
+    # file is needed by rpm2cpio.sh
+    if ".src.rpm" in srcuri:
+        d.appendVarFlag('do_unpack', 'depends', ' file-native:do_populate_sysroot')
+
     set_packagetriplet(d)
 
     # 'multimachine' handling