bitbake: hob2: add elf to hcc supported image types

[Yocto #2709]

OE Core Commit c9b01af84b add elf image
type. This will cause hob build image failed.
Add elf to hcc supoorted image types to fix this issue.

(Bitbake rev: a93a58b7cea2ddb9596cb4d718c0801db5d1a295)

Signed-off-by: Kang Kai <kai.kang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

.gitignore

@@ -1,10 +1,8 @@
+bitbake
 *.pyc
 *.pyo
-build*/conf/local.conf
-build*/conf/bblayers.conf
-build*/downloads
-build*/tmp/
-build*/sstate-cache
+/*.patch
+build*/
 pyshtables.py
 pstage/
 scripts/oe-git-proxy-socks

README

@@ -18,7 +18,7 @@ e.g. for the hardware support. Poky is in turn a component of the Yocto Project.
 
 The Yocto Project has extensive documentation about the system including a 
 reference manual which can be found at:
-    http://yoctoproject.org/community/documentation
+    http://yoctoproject.org/documentation
 
 OpenEmbedded-Core is a layer containing the core metadata for current versions
 of OpenEmbedded. It is distro-less (can build a functional image with

bitbake/bin/bitbake

@@ -40,7 +40,7 @@ from bb import cooker
 from bb import ui
 from bb import server
 
-__version__ = "1.15.1"
+__version__ = "1.15.2"
 logger = logging.getLogger("BitBake")
 
 
@@ -56,10 +56,11 @@ class BBConfiguration(object):
 
 
 def get_ui(config):
-    if config.ui:
-        interface = config.ui
-    else:
-        interface = 'knotty'
+    if not config.ui:
+        # modify 'ui' attribute because it is also read by cooker
+        config.ui = os.environ.get('BITBAKE_UI', 'knotty')
+
+    interface = config.ui
 
     try:
         # Dynamically load the UI based on the ui name. Although we
@@ -117,6 +118,9 @@ Default BBFILES are the .bb files in the current directory.""")
     parser.add_option("-c", "--cmd", help = "Specify task to execute. Note that this only executes the specified task for the providee and the packages it depends on, i.e. 'compile' does not implicitly call stage for the dependencies (IOW: use only if you know what you are doing). Depending on the base.bbclass a listtasks tasks is defined and will show available tasks",
                action = "store", dest = "cmd")
 
+    parser.add_option("-C", "--clear-stamp", help = "Invalidate the stamp for the specified cmd such as 'compile' and run the default task for the specified target(s)",
+                action = "store", dest = "invalidate_stamp")
+
     parser.add_option("-r", "--read", help = "read the specified file before bitbake.conf",
                action = "append", dest = "prefile", default = [])
 
@@ -144,7 +148,7 @@ Default BBFILES are the .bb files in the current directory.""")
     parser.add_option("-e", "--environment", help = "show the global or per-package environment (this is what used to be bbread)",
                action = "store_true", dest = "show_environment", default = False)
 
-    parser.add_option("-g", "--graphviz", help = "emit the dependency trees of the specified packages in the dot syntax",
+    parser.add_option("-g", "--graphviz", help = "emit the dependency trees of the specified packages in the dot syntax, and the pn-buildlist to show the build list",
                 action = "store_true", dest = "dot_graph", default = False)
 
     parser.add_option("-I", "--ignore-deps", help = """Assume these dependencies don't exist and are already provided (equivalent to ASSUME_PROVIDED). Useful to make dependency graphs more appealing""",

bitbake/bin/bitbake-layers

@@ -9,6 +9,7 @@
 
 import cmd
 import logging
+import warnings
 import os
 import sys
 import fnmatch
@@ -28,6 +29,7 @@ import bb.fetch2
 
 logger = logging.getLogger('BitBake')
 
+warnings.filterwarnings("ignore", category=DeprecationWarning)
 
 def main(args):
     # Set up logging

bitbake/bin/bitbake-selftest

@@ -0,0 +1,38 @@
+#!/usr/bin/env python
+#
+# Copyright (C) 2012 Richard Purdie
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License version 2 as
+# published by the Free Software Foundation.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License along
+# with this program; if not, write to the Free Software Foundation, Inc.,
+# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+
+import os
+import sys, logging
+sys.path.insert(0, os.path.join(os.path.dirname(os.path.dirname(__file__)), 'lib'))
+
+import unittest
+try:
+    import bb
+except RuntimeError as exc:
+    sys.exit(str(exc))
+
+tests = ["bb.tests.codeparser", 
+         "bb.tests.cow",
+         "bb.tests.data",
+         "bb.tests.fetch",
+         "bb.tests.utils"]
+
+for t in tests:
+    __import__(t)
+
+unittest.main(argv=["bitbake-selftest"] + tests)
+

bitbake/bin/image-writer

@@ -0,0 +1,120 @@
+#!/usr/bin/env python
+
+# Copyright (c) 2012 Wind River Systems, Inc.
+#
+# 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+
+import os
+import sys
+sys.path.insert(0, os.path.join(os.path.dirname(os.path.dirname( \
+                                    os.path.abspath(__file__))), 'lib'))
+try:
+    import bb
+except RuntimeError as exc:
+    sys.exit(str(exc))
+
+import gtk
+import optparse
+import pygtk
+
+from bb.ui.crumbs.hig import DeployImageDialog, ImageSelectionDialog, CrumbsMessageDialog
+from bb.ui.crumbs.hobwidget import HobAltButton, HobButton
+
+# I put all the fs bitbake supported here. Need more test.
+DEPLOYABLE_IMAGE_TYPES = ["jffs2", "cramfs", "ext2", "ext3", "btrfs", "squashfs", "ubi", "vmdk"]
+Title = "USB Image Writer"
+
+class DeployWindow(gtk.Window):
+    def __init__(self, image_path=''):
+        super(DeployWindow, self).__init__()
+
+        if len(image_path) > 0:
+            valid = True
+            if not os.path.exists(image_path):
+                valid = False
+                lbl = "<b>Invalid image file path: %s.</b>\nPress <b>Select Image</b> to select an image." % image_path
+            else:
+                image_path = os.path.abspath(image_path)
+                extend_name = os.path.splitext(image_path)[1][1:]
+                if extend_name not in DEPLOYABLE_IMAGE_TYPES:
+                    valid = False
+                    lbl = "<b>Undeployable imge type: %s</b>\nPress <b>Select Image</b> to select an image." % extend_name
+
+            if not valid:
+                image_path = ''
+                crumbs_dialog = CrumbsMessageDialog(self, lbl, gtk.STOCK_DIALOG_INFO)
+                button = crumbs_dialog.add_button("Close", gtk.RESPONSE_OK)
+                HobButton.style_button(button)
+                crumbs_dialog.run()
+                crumbs_dialog.destroy()
+
+        self.deploy_dialog = DeployImageDialog(Title, image_path, self,
+                                        gtk.DIALOG_MODAL | gtk.DIALOG_DESTROY_WITH_PARENT
+                                        | gtk.DIALOG_NO_SEPARATOR, None, standalone=True)
+        close_button = self.deploy_dialog.add_button("Close", gtk.RESPONSE_NO)
+        HobAltButton.style_button(close_button)
+        close_button.connect('clicked', gtk.main_quit)
+
+        write_button = self.deploy_dialog.add_button("Write USB image", gtk.RESPONSE_YES)
+        HobAltButton.style_button(write_button)
+
+        self.deploy_dialog.connect('select_image_clicked', self.select_image_clicked_cb)
+        self.deploy_dialog.connect('destroy', gtk.main_quit)
+        response = self.deploy_dialog.show()
+
+    def select_image_clicked_cb(self, dialog):
+        cwd = os.getcwd()
+        dialog = ImageSelectionDialog(cwd, DEPLOYABLE_IMAGE_TYPES, Title, self, gtk.FILE_CHOOSER_ACTION_SAVE )
+        button = dialog.add_button("Cancel", gtk.RESPONSE_NO)
+        HobAltButton.style_button(button)
+        button = dialog.add_button("Open", gtk.RESPONSE_YES)
+        HobAltButton.style_button(button)
+        response = dialog.run()
+
+        if response == gtk.RESPONSE_YES:
+            if not dialog.image_names:
+                lbl = "<b>No selections made</b>\nClicked the radio button to select a image."
+                crumbs_dialog = CrumbsMessageDialog(self, lbl, gtk.STOCK_DIALOG_INFO)
+                button = crumbs_dialog.add_button("Close", gtk.RESPONSE_OK)
+                HobButton.style_button(button)
+                crumbs_dialog.run()
+                crumbs_dialog.destroy()
+                dialog.destroy()
+                return
+
+            # get the full path of image
+            image_path = os.path.join(dialog.image_folder, dialog.image_names[0])
+            self.deploy_dialog.set_image_text_buffer(image_path)
+            self.deploy_dialog.set_image_path(image_path)
+
+        dialog.destroy()
+
+def main():
+    parser = optparse.OptionParser(
+                usage = """%prog [-h] [image_file]
+
+%prog writes bootable images to USB devices. You can
+provide the image file on the command line or select it using the GUI.""")
+
+    options, args = parser.parse_args(sys.argv)
+    image_file = args[1] if len(args) > 1 else ''
+    dw = DeployWindow(image_file)
+
+if __name__ == '__main__':
+    try:
+        main()
+        gtk.main()
+    except Exception:
+        import traceback
+        traceback.print_exc(3)

bitbake/doc/bitbake.1

@@ -103,7 +103,13 @@ Show debug logging for the specified logging domains
 .TP
 .B \-P, \-\-profile
 profile the command and print a report
+
+.SH ENVIRONMENT VARIABLES
+bitbake uses the following environment variables to control its
+operation:
 .TP
+.B BITBAKE_UI
+The bitbake user interface; overridden by the \fB-u\fP commandline option.
 
 .SH AUTHORS
 BitBake was written by 

bitbake/doc/manual/usermanual.xml

@@ -228,7 +228,7 @@ addtask printdate before do_build</screen></para>
                 <para>'nostamp' - don't generate a stamp file for a task. This means the task is always rexecuted.</para>
                 <para>'fakeroot' - this task needs to be run in a fakeroot environment, obtained by adding the variables in FAKEROOTENV to the environment.</para>
                 <para>'umask' - the umask to run the task under.</para>
-                <para> For the 'deptask', 'rdeptask', 'recdeptask' and 'recrdeptask' flags please see the dependencies section.</para>
+                <para> For the 'deptask', 'rdeptask', 'depends', 'rdepends' and 'recrdeptask' flags please see the dependencies section.</para>
             </section>
 
             <section>
@@ -308,37 +308,35 @@ SRC_URI_append_1.0.7+ = "file://some_patch_which_the_new_versions_need.patch;pat
         </section>
         <section>
             <title>Dependency handling</title>
-            <para>BitBake 1.7.x onwards works with the metadata at the task level since this is optimal when dealing with multiple threads of execution. A robust method of specifing task dependencies is therefore needed. </para>
+            <para>BitBake handles dependencies at the task level since to allow for efficient operation with multiple processed executing in parallel. A robust method of specifying task dependencies is therefore needed. </para>
             <section>
                 <title>Dependencies internal to the .bb file</title>
                 <para>Where the dependencies are internal to a given .bb file, the dependencies are handled by the previously detailed addtask directive.</para>
             </section>
 
             <section>
-                <title>DEPENDS</title>
+                <title>Build Dependencies</title>
                 <para>DEPENDS lists build time dependencies. The 'deptask' flag for tasks is used to signify the task of each item listed in DEPENDS which must have completed before that task can be executed.</para>
                 <para><screen>do_configure[deptask] = "do_populate_staging"</screen></para>
                 <para>means the do_populate_staging task of each item in DEPENDS must have completed before do_configure can execute.</para>
             </section>
             <section>
-                <title>RDEPENDS</title>
-                <para>RDEPENDS lists runtime dependencies. The 'rdeptask' flag for tasks is used to signify the task of each item listed in RDEPENDS which must have completed before that task can be executed.</para>
+                <title>Runtime Dependencies</title>
+                <para>The PACKAGES variable lists runtime packages and each of these can have RDEPENDS and RRECOMMENDS runtime dependencies. The 'rdeptask' flag for tasks is used to signify the task of each item runtime dependency which must have completed before that task can be executed.</para>
                 <para><screen>do_package_write[rdeptask] = "do_package"</screen></para>
                 <para>means the do_package task of each item in RDEPENDS must have completed before do_package_write can execute.</para>
             </section>
             <section>
-                <title>Recursive DEPENDS</title>
-                <para>These are specified with the 'recdeptask' flag and is used signify the task(s) of each DEPENDS which must have completed before that task can be executed. It applies recursively so the DEPENDS of each item in the original DEPENDS must be met and so on.</para>
-            </section>
-            <section>
-                <title>Recursive RDEPENDS</title>
-                <para>These are specified with the 'recrdeptask' flag and is used signify the task(s) of each RDEPENDS which must have completed before that task can be executed. It applies recursively so the RDEPENDS of each item in the original RDEPENDS must be met and so on. It also runs all DEPENDS first.</para>
+                <title>Recursive Dependencies</title>
+                <para>These are specified with the 'recrdeptask' flag which is used signify the task(s) of dependencies which must have completed before that task can be executed. It works by looking though the build and runtime dependencies of the current recipe as well as any inter-task dependencies the task has, then adding a dependency on the listed task. It will then recurse through the dependencies of those tasks and so on.</para>
+                <para>It may be desireable to recurse not just through the dependencies of those tasks but through the build and runtime dependencies of dependent tasks too. If that is the case, the taskname itself should be referenced in the task list, e.g. do_a[recrdeptask] = "do_a do_b".</para>
             </section>
             <section>
                 <title>Inter task</title>
-                <para>The 'depends' flag for tasks is a more generic form of which allows an interdependency on specific tasks rather than specifying the data in DEPENDS or RDEPENDS.</para>
+                <para>The 'depends' flag for tasks is a more generic form of which allows an interdependency on specific tasks rather than specifying the data in DEPENDS.</para>
                 <para><screen>do_patch[depends] = "quilt-native:do_populate_staging"</screen></para>
                 <para>means the do_populate_staging task of the target quilt-native must have completed before the do_patch can execute.</para>
+                <para>The 'rdepends' flag works in a similar way but takes targets in the runtime namespace instead of the build time dependency namespace.</para>
             </section>
         </section>
 

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

bitbake/lib/bb/build.py

@@ -135,7 +135,8 @@ class LogTee(object):
 
     def __repr__(self):
         return '<LogTee {0}>'.format(self.name)
-
+    def flush(self):
+        self.outfile.flush()
 
 def exec_func(func, d, dirs = None):
     """Execute an BB 'function'"""
@@ -174,8 +175,19 @@ def exec_func(func, d, dirs = None):
         lockfiles = None
 
     tempdir = data.getVar('T', d, 1)
-    bb.utils.mkdirhier(tempdir)
-    runfile = os.path.join(tempdir, 'run.{0}.{1}'.format(func, os.getpid()))
+
+    # or func allows items to be executed outside of the normal
+    # task set, such as buildhistory
+    task = data.getVar('BB_RUNTASK', d, 1) or func
+    if task == func:
+        taskfunc = task
+    else:
+        taskfunc = "%s.%s" % (task, func)
+
+    runfmt = data.getVar('BB_RUNFMT', d, 1) or "run.{func}.{pid}"
+    runfn = runfmt.format(taskfunc=taskfunc, task=task, func=func, pid=os.getpid())
+    runfile = os.path.join(tempdir, runfn)
+    bb.utils.mkdirhier(os.path.dirname(runfile))
 
     with bb.utils.fileslocked(lockfiles):
         if ispython:
@@ -206,6 +218,8 @@ def exec_func_python(func, d, runfile, cwd=None):
             olddir = None
         os.chdir(cwd)
 
+    bb.debug(2, "Executing python function %s" % func)
+
     try:
         comp = utils.better_compile(code, func, bbfile)
         utils.better_exec(comp, {"d": d}, code, bbfile)
@@ -215,13 +229,15 @@ def exec_func_python(func, d, runfile, cwd=None):
 
         raise FuncFailed(func, None)
     finally:
+        bb.debug(2, "Python function %s finished" % func)
+
         if cwd and olddir:
             try:
                 os.chdir(olddir)
             except OSError:
                 pass
 
-def exec_func_shell(function, d, runfile, cwd=None):
+def exec_func_shell(func, d, runfile, cwd=None):
     """Execute a shell function from the metadata
 
     Note on directory behavior.  The 'dirs' varflag should contain a list
@@ -234,18 +250,18 @@ def exec_func_shell(function, d, runfile, cwd=None):
 
     with open(runfile, 'w') as script:
         script.write('#!/bin/sh -e\n')
-        data.emit_func(function, script, d)
+        data.emit_func(func, script, d)
 
         if bb.msg.loggerVerboseLogs:
             script.write("set -x\n")
         if cwd:
             script.write("cd %s\n" % cwd)
-        script.write("%s\n" % function)
+        script.write("%s\n" % func)
 
     os.chmod(runfile, 0775)
 
     cmd = runfile
-    if d.getVarFlag(function, 'fakeroot'):
+    if d.getVarFlag(func, 'fakeroot'):
         fakerootcmd = d.getVar('FAKEROOT', True)
         if fakerootcmd:
             cmd = [fakerootcmd, runfile]
@@ -255,11 +271,15 @@ def exec_func_shell(function, d, runfile, cwd=None):
     else:
         logfile = sys.stdout
 
+    bb.debug(2, "Executing shell function %s" % func)
+
     try:
         bb.process.run(cmd, shell=False, stdin=NULL, log=logfile)
     except bb.process.CmdError:
         logfn = d.getVar('BB_LOGFILE', True)
-        raise FuncFailed(function, logfn)
+        raise FuncFailed(func, logfn)
+
+    bb.debug(2, "Shell function %s finished" % func)
 
 def _task_data(fn, task, d):
     localdata = data.createCopy(d)
@@ -290,8 +310,23 @@ def _exec_task(fn, task, d, quieterr):
         bb.fatal("T variable not set, unable to build")
 
     bb.utils.mkdirhier(tempdir)
+
+    # Determine the logfile to generate
+    logfmt = localdata.getVar('BB_LOGFMT', True) or 'log.{task}.{pid}'
+    logbase = logfmt.format(task=task, pid=os.getpid())
+
+    # Document the order of the tasks...
+    logorder = os.path.join(tempdir, 'log.task_order')
+    try:
+        logorderfile = file(logorder, 'a')
+    except OSError:
+        logger.exception("Opening log file '%s'", logorder)
+        pass
+    logorderfile.write('{0} ({1}): {2}\n'.format(task, os.getpid(), logbase))
+    logorderfile.close()
+
+    # Setup the courtesy link to the logfn
     loglink = os.path.join(tempdir, 'log.{0}'.format(task))
-    logbase = 'log.{0}.{1}'.format(task, os.getpid())
     logfn = os.path.join(tempdir, logbase)
     if loglink:
         bb.utils.remove(loglink)
@@ -314,6 +349,7 @@ def _exec_task(fn, task, d, quieterr):
     # Handle logfiles
     si = file('/dev/null', 'r')
     try:
+        bb.utils.mkdirhier(os.path.dirname(logfn))
         logfile = file(logfn, 'w')
     except OSError:
         logger.exception("Opening log file '%s'", logfn)
@@ -340,6 +376,7 @@ def _exec_task(fn, task, d, quieterr):
     bblogger.addHandler(errchk)
 
     localdata.setVar('BB_LOGFILE', logfn)
+    localdata.setVar('BB_RUNTASK', task)
 
     event.fire(TaskStarted(task, localdata), localdata)
     try:
@@ -458,6 +495,24 @@ def del_stamp(task, d, file_name = None):
     stamp = stamp_internal(task, d, file_name)
     bb.utils.remove(stamp)
 
+def write_taint(task, d, file_name = None):
+    """
+    Creates a "taint" file which will force the specified task and its
+    dependents to be re-run the next time by influencing the value of its
+    taskhash.
+    (d can be a data dict or dataCache)
+    """
+    import uuid
+    if file_name:
+        taintfn = d.stamp[file_name] + '.' + task + '.taint'
+    else:
+        taintfn = d.getVar('STAMP', True) + '.' + task + '.taint'
+    bb.utils.mkdirhier(os.path.dirname(taintfn))
+    # The specific content of the taint file is not really important,
+    # we just need it to be random, so a random UUID is used
+    with open(taintfn, 'w') as taintf:
+        taintf.write(str(uuid.uuid4()))
+
 def stampfile(taskname, d, file_name = None):
     """
     Return the stamp for a given task
@@ -489,6 +544,7 @@ def add_tasks(tasklist, d):
                 deptask = data.expand(flags[name], d)
                 task_deps[name][task] = deptask
         getTask('depends')
+        getTask('rdepends')
         getTask('deptask')
         getTask('rdeptask')
         getTask('recrdeptask')

bitbake/lib/bb/cache.py

@@ -1,11 +1,12 @@
 # ex:ts=4:sw=4:sts=4:et
 # -*- tab-width: 4; c-basic-offset: 4; indent-tabs-mode: nil -*-
 #
-# BitBake 'Event' implementation
+# BitBake Cache implementation
 #
 # Caching of bitbake variables before task execution
 
 # Copyright (C) 2006        Richard Purdie
+# Copyright (C) 2012        Intel Corporation
 
 # but small sections based on code from bin/bitbake:
 # Copyright (C) 2003, 2004  Chris Larson
@@ -42,7 +43,7 @@ except ImportError:
     logger.info("Importing cPickle failed. "
                 "Falling back to a very slow implementation.")
 
-__cache_version__ = "143"
+__cache_version__ = "144"
 
 def getCacheFile(path, filename, data_hash):
     return os.path.join(path, filename + "." + data_hash)
@@ -75,9 +76,13 @@ class RecipeInfoCommon(object):
                     for task in tasks)
 
     @classmethod
-    def flaglist(cls, flag, varlist, metadata):
-        return dict((var, metadata.getVarFlag(var, flag, True))
+    def flaglist(cls, flag, varlist, metadata, squash=False):
+        out_dict = dict((var, metadata.getVarFlag(var, flag, True))
                     for var in varlist)
+        if squash:
+            return dict((k,v) for (k,v) in out_dict.iteritems() if v)
+        else:
+            return out_dict
 
     @classmethod
     def getvar(cls, var, metadata):
@@ -127,6 +132,7 @@ class CoreRecipeInfo(RecipeInfoCommon):
         self.stamp = self.getvar('STAMP', metadata)
         self.stamp_base = self.flaglist('stamp-base', self.tasks, metadata)
         self.stamp_extrainfo = self.flaglist('stamp-extra-info', self.tasks, metadata)
+        self.file_checksums = self.flaglist('file-checksums', self.tasks, metadata, True)
         self.packages_dynamic = self.listvar('PACKAGES_DYNAMIC', metadata)
         self.depends          = self.depvar('DEPENDS', metadata)
         self.provides         = self.depvar('PROVIDES', metadata)
@@ -153,6 +159,7 @@ class CoreRecipeInfo(RecipeInfoCommon):
         cachedata.stamp = {}
         cachedata.stamp_base = {}
         cachedata.stamp_extrainfo = {}
+        cachedata.file_checksums = {}
         cachedata.fn_provides = {}
         cachedata.pn_provides = defaultdict(list)
         cachedata.all_depends = []
@@ -184,6 +191,7 @@ class CoreRecipeInfo(RecipeInfoCommon):
         cachedata.stamp[fn] = self.stamp
         cachedata.stamp_base[fn] = self.stamp_base
         cachedata.stamp_extrainfo[fn] = self.stamp_extrainfo
+        cachedata.file_checksums[fn] = self.file_checksums
 
         provides = [self.pn]
         for provide in self.provides:
@@ -703,4 +711,115 @@ class CacheData(object):
         for info in info_array:
             info.add_cacheData(self, fn)
 
-        
+
+class MultiProcessCache(object):
+    """
+    BitBake multi-process cache implementation
+
+    Used by the codeparser & file checksum caches
+    """
+
+    def __init__(self):
+        self.cachefile = None
+        self.cachedata = self.create_cachedata()
+        self.cachedata_extras = self.create_cachedata()
+
+    def init_cache(self, d):
+        cachedir = (d.getVar("PERSISTENT_DIR", True) or
+                    d.getVar("CACHE", True))
+        if cachedir in [None, '']:
+            return
+        bb.utils.mkdirhier(cachedir)
+        self.cachefile = os.path.join(cachedir, self.__class__.cache_file_name)
+        logger.debug(1, "Using cache in '%s'", self.cachefile)
+
+        try:
+            p = pickle.Unpickler(file(self.cachefile, "rb"))
+            data, version = p.load()
+        except:
+            return
+
+        if version != self.__class__.CACHE_VERSION:
+            return
+
+        self.cachedata = data
+
+    def internSet(self, items):
+        new = set()
+        for i in items:
+            new.add(intern(i))
+        return new
+
+    def compress_keys(self, data):
+        # Override in subclasses if desired
+        return
+
+    def create_cachedata(self):
+        data = [{}]
+        return data
+
+    def save_extras(self, d):
+        if not self.cachefile:
+            return
+
+        glf = bb.utils.lockfile(self.cachefile + ".lock", shared=True)
+
+        i = os.getpid()
+        lf = None
+        while not lf:
+            lf = bb.utils.lockfile(self.cachefile + ".lock." + str(i), retry=False)
+            if not lf or os.path.exists(self.cachefile + "-" + str(i)):
+                if lf:
+                    bb.utils.unlockfile(lf)
+                    lf = None
+                i = i + 1
+                continue
+
+            p = pickle.Pickler(file(self.cachefile + "-" + str(i), "wb"), -1)
+            p.dump([self.cachedata_extras, self.__class__.CACHE_VERSION])
+
+        bb.utils.unlockfile(lf)
+        bb.utils.unlockfile(glf)
+
+    def merge_data(self, source, dest):
+        for j in range(0,len(dest)):
+            for h in source[j]:
+                if h not in dest[j]:
+                    dest[j][h] = source[j][h]
+
+    def save_merge(self, d):
+        if not self.cachefile:
+            return
+
+        glf = bb.utils.lockfile(self.cachefile + ".lock")
+
+        try:
+            p = pickle.Unpickler(file(self.cachefile, "rb"))
+            data, version = p.load()
+        except (IOError, EOFError):
+            data, version = None, None
+
+        if version != self.__class__.CACHE_VERSION:
+            data = self.create_cachedata()
+
+        for f in [y for y in os.listdir(os.path.dirname(self.cachefile)) if y.startswith(os.path.basename(self.cachefile) + '-')]:
+            f = os.path.join(os.path.dirname(self.cachefile), f)
+            try:
+                p = pickle.Unpickler(file(f, "rb"))
+                extradata, version = p.load()
+            except (IOError, EOFError):
+                extradata, version = self.create_cachedata(), None
+
+            if version != self.__class__.CACHE_VERSION:
+                continue
+
+            self.merge_data(extradata, data)
+            os.unlink(f)
+
+        self.compress_keys(data)
+
+        p = pickle.Pickler(file(self.cachefile, "wb"), -1)
+        p.dump([data, self.__class__.CACHE_VERSION])
+
+        bb.utils.unlockfile(glf)
+

bitbake/lib/bb/checksum.py

@@ -0,0 +1,90 @@
+# Local file checksum cache implementation
+#
+# Copyright (C) 2012 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 stat
+import bb.utils
+import logging
+from bb.cache import MultiProcessCache
+
+logger = logging.getLogger("BitBake.Cache")
+
+try:
+    import cPickle as pickle
+except ImportError:
+    import pickle
+    logger.info("Importing cPickle failed. "
+                "Falling back to a very slow implementation.")
+
+
+# mtime cache (non-persistent)
+# based upon the assumption that files do not change during bitbake run
+class FileMtimeCache(object):
+    cache = {}
+
+    def cached_mtime(self, f):
+        if f not in self.cache:
+            self.cache[f] = os.stat(f)[stat.ST_MTIME]
+        return self.cache[f]
+
+    def cached_mtime_noerror(self, f):
+        if f not in self.cache:
+            try:
+                self.cache[f] = os.stat(f)[stat.ST_MTIME]
+            except OSError:
+                return 0
+        return self.cache[f]
+
+    def update_mtime(self, f):
+        self.cache[f] = os.stat(f)[stat.ST_MTIME]
+        return self.cache[f]
+
+    def clear(self):
+        self.cache.clear()
+
+# Checksum + mtime cache (persistent)
+class FileChecksumCache(MultiProcessCache):
+    cache_file_name = "local_file_checksum_cache.dat"
+    CACHE_VERSION = 1
+
+    def __init__(self):
+        self.mtime_cache = FileMtimeCache()
+        MultiProcessCache.__init__(self)
+
+    def get_checksum(self, f):
+        entry = self.cachedata[0].get(f)
+        cmtime = self.mtime_cache.cached_mtime(f)
+        if entry:
+            (mtime, hashval) = entry
+            if cmtime == mtime:
+                return hashval
+            else:
+                bb.debug(2, "file %s changed mtime, recompute checksum" % f)
+
+        hashval = bb.utils.md5_file(f)
+        self.cachedata_extras[0][f] = (cmtime, hashval)
+        return hashval
+
+    def merge_data(self, source, dest):
+        for h in source[0]:
+            if h in dest:
+                (smtime, _) = source[0][h]
+                (dmtime, _) = dest[0][h]
+                if smtime > dmtime:
+                    dest[0][h] = source[0][h]
+            else:
+                dest[0][h] = source[0][h]

bitbake/lib/bb/codeparser.py

@@ -5,10 +5,10 @@ import os.path
 import bb.utils, bb.data
 from itertools import chain
 from pysh import pyshyacc, pyshlex, sherrors
+from bb.cache import MultiProcessCache
 
 
 logger = logging.getLogger('BitBake.CodeParser')
-PARSERCACHE_VERSION = 2
 
 try:
     import cPickle as pickle
@@ -32,133 +32,56 @@ def check_indent(codestr):
 
     return codestr
 
-pythonparsecache = {}
-shellparsecache = {}
-pythonparsecacheextras = {}
-shellparsecacheextras = {}
 
+class CodeParserCache(MultiProcessCache):
+    cache_file_name = "bb_codeparser.dat"
+    CACHE_VERSION = 2
 
-def parser_cachefile(d):
-    cachedir = (d.getVar("PERSISTENT_DIR", True) or
-                d.getVar("CACHE", True))
-    if cachedir in [None, '']:
-        return None
-    bb.utils.mkdirhier(cachedir)
-    cachefile = os.path.join(cachedir, "bb_codeparser.dat")
-    logger.debug(1, "Using cache in '%s' for codeparser cache", cachefile)
-    return cachefile
+    def __init__(self):
+        MultiProcessCache.__init__(self)
+        self.pythoncache = self.cachedata[0]
+        self.shellcache = self.cachedata[1]
+        self.pythoncacheextras = self.cachedata_extras[0]
+        self.shellcacheextras = self.cachedata_extras[1]
+
+    def init_cache(self, d):
+        MultiProcessCache.init_cache(self, d)
+
+        # cachedata gets re-assigned in the parent
+        self.pythoncache = self.cachedata[0]
+        self.shellcache = self.cachedata[1]
+
+    def compress_keys(self, data):
+        # When the dicts are originally created, python calls intern() on the set keys
+        # which significantly improves memory usage. Sadly the pickle/unpickle process
+        # doesn't call intern() on the keys and results in the same strings being duplicated
+        # in memory. This also means pickle will save the same string multiple times in
+        # the cache file. By interning the data here, the cache file shrinks dramatically
+        # meaning faster load times and the reloaded cache files also consume much less
+        # memory. This is worth any performance hit from this loops and the use of the
+        # intern() data storage.
+        # Python 3.x may behave better in this area
+        for h in data[0]:
+            data[0][h]["refs"] = self.internSet(data[0][h]["refs"])
+            data[0][h]["execs"] = self.internSet(data[0][h]["execs"])
+        for h in data[1]:
+            data[1][h]["execs"] = self.internSet(data[1][h]["execs"])
+        return
+
+    def create_cachedata(self):
+        data = [{}, {}]
+        return data
+
+codeparsercache = CodeParserCache()
 
 def parser_cache_init(d):
-    global pythonparsecache
-    global shellparsecache
-
-    cachefile = parser_cachefile(d)
-    if not cachefile:
-        return
-
-    try:
-        p = pickle.Unpickler(file(cachefile, "rb"))
-        data, version = p.load()
-    except:
-        return
-
-    if version != PARSERCACHE_VERSION:
-        return
-
-    pythonparsecache = data[0]
-    shellparsecache = data[1]
+    codeparsercache.init_cache(d)
 
 def parser_cache_save(d):
-    cachefile = parser_cachefile(d)
-    if not cachefile:
-        return
-
-    glf = bb.utils.lockfile(cachefile + ".lock", shared=True)
-
-    i = os.getpid()
-    lf = None
-    while not lf:
-        shellcache = {}
-        pythoncache = {}
-
-        lf = bb.utils.lockfile(cachefile + ".lock." + str(i), retry=False)
-        if not lf or os.path.exists(cachefile + "-" + str(i)):
-            if lf:
-               bb.utils.unlockfile(lf) 
-               lf = None
-            i = i + 1
-            continue
-
-        shellcache = shellparsecacheextras
-        pythoncache = pythonparsecacheextras
-
-        p = pickle.Pickler(file(cachefile + "-" + str(i), "wb"), -1)
-        p.dump([[pythoncache, shellcache], PARSERCACHE_VERSION])
-
-    bb.utils.unlockfile(lf)
-    bb.utils.unlockfile(glf)
-
-def internSet(items):
-    new = set()
-    for i in items:
-        new.add(intern(i))
-    return new
+    codeparsercache.save_extras(d)
 
 def parser_cache_savemerge(d):
-    cachefile = parser_cachefile(d)
-    if not cachefile:
-        return
-
-    glf = bb.utils.lockfile(cachefile + ".lock")
-
-    try:
-        p = pickle.Unpickler(file(cachefile, "rb"))
-        data, version = p.load()
-    except (IOError, EOFError):
-        data, version = None, None
-
-    if version != PARSERCACHE_VERSION:
-        data = [{}, {}]
-
-    for f in [y for y in os.listdir(os.path.dirname(cachefile)) if y.startswith(os.path.basename(cachefile) + '-')]:
-        f = os.path.join(os.path.dirname(cachefile), f)
-        try:
-            p = pickle.Unpickler(file(f, "rb"))
-            extradata, version = p.load()
-        except (IOError, EOFError):
-            extradata, version = [{}, {}], None
-        
-        if version != PARSERCACHE_VERSION:
-            continue
-
-        for h in extradata[0]:
-            if h not in data[0]:
-                data[0][h] = extradata[0][h]
-        for h in extradata[1]:
-            if h not in data[1]:
-                data[1][h] = extradata[1][h]
-        os.unlink(f)
-
-    # When the dicts are originally created, python calls intern() on the set keys
-    # which significantly improves memory usage. Sadly the pickle/unpickle process 
-    # doesn't call intern() on the keys and results in the same strings being duplicated
-    # in memory. This also means pickle will save the same string multiple times in 
-    # the cache file. By interning the data here, the cache file shrinks dramatically
-    # meaning faster load times and the reloaded cache files also consume much less 
-    # memory. This is worth any performance hit from this loops and the use of the 
-    # intern() data storage.
-    # Python 3.x may behave better in this area
-    for h in data[0]:
-        data[0][h]["refs"] = internSet(data[0][h]["refs"])
-        data[0][h]["execs"] = internSet(data[0][h]["execs"])
-    for h in data[1]:
-        data[1][h]["execs"] = internSet(data[1][h]["execs"])
-
-    p = pickle.Pickler(file(cachefile, "wb"), -1)
-    p.dump([data, PARSERCACHE_VERSION])
-
-    bb.utils.unlockfile(glf)
-
+    codeparsercache.save_merge(d)
 
 Logger = logging.getLoggerClass()
 class BufferedLogger(Logger):
@@ -235,14 +158,14 @@ class PythonParser():
     def parse_python(self, node):
         h = hash(str(node))
 
-        if h in pythonparsecache:
-            self.references = pythonparsecache[h]["refs"]
-            self.execs = pythonparsecache[h]["execs"]
+        if h in codeparsercache.pythoncache:
+            self.references = codeparsercache.pythoncache[h]["refs"]
+            self.execs = codeparsercache.pythoncache[h]["execs"]
             return
 
-        if h in pythonparsecacheextras:
-            self.references = pythonparsecacheextras[h]["refs"]
-            self.execs = pythonparsecacheextras[h]["execs"]
+        if h in codeparsercache.pythoncacheextras:
+            self.references = codeparsercache.pythoncacheextras[h]["refs"]
+            self.execs = codeparsercache.pythoncacheextras[h]["execs"]
             return
 
 
@@ -256,9 +179,9 @@ class PythonParser():
         self.references.update(self.var_references)
         self.references.update(self.var_execs)
 
-        pythonparsecacheextras[h] = {}
-        pythonparsecacheextras[h]["refs"] = self.references
-        pythonparsecacheextras[h]["execs"] = self.execs
+        codeparsercache.pythoncacheextras[h] = {}
+        codeparsercache.pythoncacheextras[h]["refs"] = self.references
+        codeparsercache.pythoncacheextras[h]["execs"] = self.execs
 
 class ShellParser():
     def __init__(self, name, log):
@@ -276,12 +199,12 @@ class ShellParser():
 
         h = hash(str(value))
 
-        if h in shellparsecache:
-            self.execs = shellparsecache[h]["execs"]
+        if h in codeparsercache.shellcache:
+            self.execs = codeparsercache.shellcache[h]["execs"]
             return self.execs
 
-        if h in shellparsecacheextras:
-            self.execs = shellparsecacheextras[h]["execs"]
+        if h in codeparsercache.shellcacheextras:
+            self.execs = codeparsercache.shellcacheextras[h]["execs"]
             return self.execs
 
         try:
@@ -293,8 +216,8 @@ class ShellParser():
             self.process_tokens(token)
         self.execs = set(cmd for cmd in self.allexecs if cmd not in self.funcdefs)
 
-        shellparsecacheextras[h] = {}
-        shellparsecacheextras[h]["execs"] = self.execs
+        codeparsercache.shellcacheextras[h] = {}
+        codeparsercache.shellcacheextras[h]["execs"] = self.execs
 
         return self.execs
 

bitbake/lib/bb/command.py

@@ -179,6 +179,13 @@ class CommandsSync:
         """
         return bb.utils.cpu_count()
 
+    def setConfFilter(self, command, params):
+        """
+        Set the configuration file parsing filter
+        """
+        filterfunc = params[0]
+        bb.parse.parse_py.ConfHandler.confFilters.append(filterfunc)
+
 class CommandsAsync:
     """
     A class of asynchronous commands

bitbake/lib/bb/cooker.py

@@ -534,11 +534,15 @@ class BBCooker:
 
         # Prints a flattened form of package-depends below where subpackages of a package are merged into the main pn
         depends_file = file('pn-depends.dot', 'w' )
+        buildlist_file = file('pn-buildlist', 'w' )
         print("digraph depends {", file=depends_file)
         for pn in depgraph["pn"]:
             fn = depgraph["pn"][pn]["filename"]
             version = depgraph["pn"][pn]["version"]
             print('"%s" [label="%s %s\\n%s"]' % (pn, pn, version, fn), file=depends_file)
+            print("%s" % pn, file=buildlist_file)
+        buildlist_file.close()
+        logger.info("PN build list saved to 'pn-buildlist'")
         for pn in depgraph["depends"]:
             for depend in depgraph["depends"][pn]:
                 print('"%s" -> "%s"' % (pn, depend), file=depends_file)
@@ -985,12 +989,12 @@ class BBCooker:
         """
         Find the .bb files which match the expression in 'buildfile'.
         """
-
         if bf.startswith("/") or bf.startswith("../"):
             bf = os.path.abspath(bf)
         filelist, masked = self.collect_bbfiles()
         try:
             os.stat(bf)
+            bf = os.path.abspath(bf)
             return [bf]
         except OSError:
             regexp = re.compile(bf)
@@ -1066,10 +1070,10 @@ class BBCooker:
         self.status.rundeps[fn] = []
         self.status.runrecs[fn] = []
 
-        # Remove stamp for target if force mode active
+        # Invalidate task for target if force mode active
         if self.configuration.force:
-            logger.verbose("Remove stamp %s, %s", task, fn)
-            bb.build.del_stamp('do_%s' % task, self.status, fn)
+            logger.verbose("Invalidate task %s, %s", task, fn)
+            bb.parse.siggen.invalidate_task('do_%s' % task, self.status, fn)
 
         # Setup taskdata structure
         taskdata = bb.taskdata.TaskData(self.configuration.abort)
@@ -1175,7 +1179,7 @@ class BBCooker:
             return
 
         if self.state in (state.shutdown, state.stop):
-            self.parser.shutdown(clean=False)
+            self.parser.shutdown(clean=False, force = True)
             sys.exit(1)
 
         if self.state != state.parsing:
@@ -1570,6 +1574,7 @@ class CookerParser(object):
             def init():
                 Parser.cfg = self.cfgdata
                 multiprocessing.util.Finalize(None, bb.codeparser.parser_cache_save, args=(self.cfgdata,), exitpriority=1)
+                multiprocessing.util.Finalize(None, bb.fetch.fetcher_parse_save, args=(self.cfgdata,), exitpriority=1)
 
             self.feeder_quit = multiprocessing.Queue(maxsize=1)
             self.parser_quit = multiprocessing.Queue(maxsize=self.num_processes)
@@ -1608,16 +1613,20 @@ class CookerParser(object):
                 self.parser_quit.put(None)
 
             self.jobs.cancel_join_thread()
-            sys.exit(1)
 
         for process in self.processes:
-            process.join()
+            if force:
+                process.join(.1)
+                process.terminate()
+            else:
+                process.join()
         self.feeder.join()
 
         sync = threading.Thread(target=self.bb_cache.sync)
         sync.start()
         multiprocessing.util.Finalize(None, sync.join, exitpriority=-100)
         bb.codeparser.parser_cache_savemerge(self.cooker.configuration.data)
+        bb.fetch.fetcher_parse_done(self.cooker.configuration.data)
 
     def load_cached(self):
         for filename, appends in self.fromcache:
@@ -1641,6 +1650,8 @@ class CookerParser(object):
                     yield result
 
     def parse_next(self):
+        result = []
+        parsed = None
         try:
             parsed, result = self.results.next()
         except StopIteration:
@@ -1650,9 +1661,13 @@ class CookerParser(object):
             logger.error('Unable to parse %s: %s' %
                      (exc.recipe, bb.exceptions.to_string(exc.realexception)))
             self.shutdown(clean=False)
-        except (bb.parse.ParseError, bb.data_smart.ExpansionError) as exc:
+        except bb.parse.ParseError as exc:
             logger.error(str(exc))
             self.shutdown(clean=False)
+        except bb.data_smart.ExpansionError as exc:
+            _, value, _ = sys.exc_info()
+            logger.error('ExpansionError during parsing %s: %s', value.recipe, str(exc))
+            self.shutdown(clean=False)
         except SyntaxError as exc:
             logger.error('Unable to parse %s', exc.recipe)
             self.shutdown(clean=False)

bitbake/lib/bb/data.py

@@ -279,7 +279,12 @@ def build_dependencies(key, keys, shelldeps, vardepvals, d):
     deps = set()
     vardeps = d.getVarFlag(key, "vardeps", True)
     try:
-        value = d.getVar(key, False)
+        if key[-1] == ']':
+            vf = key[:-1].split('[')
+            value = d.getVarFlag(vf[0], vf[1], False)
+        else:
+            value = d.getVar(key, False)
+
         if key in vardepvals:
            value =  d.getVarFlag(key, "vardepvalue", True)
         elif d.getVarFlag(key, "func"):
@@ -301,6 +306,19 @@ def build_dependencies(key, keys, shelldeps, vardepvals, d):
             parser = d.expandWithRefs(value, key)
             deps |= parser.references
             deps = deps | (keys & parser.execs)
+
+        # Add varflags, assuming an exclusion list is set
+        varflagsexcl = d.getVar('BB_SIGNATURE_EXCLUDE_FLAGS', True)
+        if varflagsexcl:
+            varfdeps = []
+            varflags = d.getVarFlags(key)
+            if varflags:
+                for f in varflags:
+                    if f not in varflagsexcl:
+                        varfdeps.append('%s[%s]' % (key, f))
+            if varfdeps:
+                deps |= set(varfdeps)
+
         deps |= set((vardeps or "").split())
         deps -= set((d.getVarFlag(key, "vardepsexclude", True) or "").split())
     except:

bitbake/lib/bb/data_smart.py

@@ -102,7 +102,10 @@ class ExpansionError(Exception):
         self.expression = expression
         self.variablename = varname
         self.exception = exception
-        self.msg = "Failure expanding variable %s, expression was %s which triggered exception %s: %s" % (varname, expression, type(exception).__name__, exception)
+        if varname:
+            self.msg = "Failure expanding variable %s, expression was %s which triggered exception %s: %s" % (varname, expression, type(exception).__name__, exception)
+        else:
+            self.msg = "Failure expanding expression %s which triggered exception %s: %s" % (expression, type(exception).__name__, exception)
         Exception.__init__(self, self.msg)
         self.args = (varname, expression, exception)
     def __str__(self):
@@ -195,7 +198,12 @@ class DataSmart(MutableMapping):
                 for append in appends:
                     keep = []
                     for (a, o) in self.getVarFlag(append, op) or []:
-                        if o and not o in overrides:
+                        match = True
+                        if o:
+                            for o2 in o.split("_"):
+                                if not o2 in overrides:
+                                    match = False
+                        if not match:
                             keep.append((a ,o))
                             continue
 
@@ -462,13 +470,14 @@ class DataSmart(MutableMapping):
         self.delVar(var)
 
     def get_hash(self):
-        data = ""
+        data = {}
         config_whitelist = set((self.getVar("BB_HASHCONFIG_WHITELIST", True) or "").split())
         keys = set(key for key in iter(self) if not key.startswith("__"))
         for key in keys:
             if key in config_whitelist:
                 continue
             value = self.getVar(key, False) or ""
-            data = data + key + ': ' + str(value) + '\n'
+            data.update({key:value})
 
-        return hashlib.md5(data).hexdigest()
+        data_str = str([(k, data[k]) for k in sorted(data.keys())])
+        return hashlib.md5(data_str).hexdigest()

bitbake/lib/bb/event.py

@@ -517,3 +517,21 @@ class PackageInfo(Event):
     def __init__(self, pkginfolist):
         Event.__init__(self)
         self._pkginfolist = pkginfolist
+
+class SanityCheck(Event):
+    """
+    Event to issue sanity check
+    """
+
+class SanityCheckPassed(Event):
+    """
+    Event to indicate sanity check is passed
+    """
+
+class SanityCheckFailed(Event):
+    """
+    Event to indicate sanity check has failed
+    """
+    def __init__(self, msg):
+        Event.__init__(self)
+        self._msg = msg

bitbake/lib/bb/exceptions.py

@@ -32,7 +32,14 @@ class TracebackEntry(namedtuple.abc):
 def _get_frame_args(frame):
     """Get the formatted arguments and class (if available) for a frame"""
     arginfo = inspect.getargvalues(frame)
-    if not arginfo.args:
+
+    try:
+        if not arginfo.args:
+            return '', None
+    # There have been reports from the field of python 2.6 which doesn't 
+    # return a namedtuple here but simply a tuple so fallback gracefully if
+    # args isn't present.
+    except AttributeError:
         return '', None
 
     firstarg = arginfo.args[0]

bitbake/lib/bb/fetch2/__init__.py

@@ -8,6 +8,7 @@ BitBake build tools.
 """
 
 # Copyright (C) 2003, 2004  Chris Larson
+# Copyright (C) 2012  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
@@ -28,10 +29,13 @@ from __future__ import absolute_import
 from __future__ import print_function
 import os, re
 import logging
+import urllib
 import bb.persist_data, bb.utils
+import bb.checksum
 from bb import data
 
 __version__ = "2"
+_checksum_cache = bb.checksum.FileChecksumCache()
 
 logger = logging.getLogger("BitBake.Fetcher")
 
@@ -63,6 +67,9 @@ class FetchError(BBFetchException):
          BBFetchException.__init__(self, msg)
          self.args = (message, url)
 
+class ChecksumError(FetchError):
+    """Exception when mismatched checksum encountered"""
+
 class UnpackError(BBFetchException):
     """General fetcher exception when something happens incorrectly when unpacking"""
     def __init__(self, message, url):
@@ -99,12 +106,15 @@ class ParameterError(BBFetchException):
 class NetworkAccess(BBFetchException):
     """Exception raised when network access is disabled but it is required."""
     def __init__(self, url, cmd):
-         msg = "Network access disabled through BB_NO_NETWORK but access rquested with command %s (for url %s)" % (cmd, url)
+         msg = "Network access disabled through BB_NO_NETWORK but access requested with command %s (for url %s)" % (cmd, url)
          self.url = url
          self.cmd = cmd
          BBFetchException.__init__(self, msg)
          self.args = (url, cmd)
 
+class NonLocalMethod(Exception):
+    def __init__(self):
+        Exception.__init__(self)
 
 def decodeurl(url):
     """Decodes an URL into the tokens (scheme, network location, path,
@@ -144,14 +154,14 @@ def decodeurl(url):
             s1, s2 = s.split('=')
             p[s1] = s2
 
-    return (type, host, path, user, pswd, p)
+    return type, host, urllib.unquote(path), user, pswd, p
 
 def encodeurl(decoded):
     """Encodes a URL from tokens (scheme, network location, path,
     user, password, parameters).
     """
 
-    (type, host, path, user, pswd, p) = decoded
+    type, host, path, user, pswd, p = decoded
 
     if not path:
         raise MissingParameterError('path', "encoded from the data %s" % str(decoded))
@@ -165,43 +175,64 @@ def encodeurl(decoded):
         url += "@"
     if host and type != "file":
         url += "%s" % host
-    url += "%s" % path
+    url += "%s" % urllib.quote(path)
     if p:
         for parm in p:
             url += ";%s=%s" % (parm, p[parm])
 
     return url
 
-def uri_replace(ud, uri_find, uri_replace, d):
+def uri_replace(ud, uri_find, uri_replace, replacements, d):
     if not ud.url or not uri_find or not uri_replace:
-        logger.debug(1, "uri_replace: passed an undefined value, not replacing")
+        logger.error("uri_replace: passed an undefined value, not replacing")
+        return None
     uri_decoded = list(decodeurl(ud.url))
     uri_find_decoded = list(decodeurl(uri_find))
     uri_replace_decoded = list(decodeurl(uri_replace))
     logger.debug(2, "For url %s comparing %s to %s" % (uri_decoded, uri_find_decoded, uri_replace_decoded))
     result_decoded = ['', '', '', '', '', {}]
-    for i in uri_find_decoded:
-        loc = uri_find_decoded.index(i)
+    for loc, i in enumerate(uri_find_decoded):
         result_decoded[loc] = uri_decoded[loc]
-        if isinstance(i, basestring):
-            if (re.match(i, uri_decoded[loc])):
-                if not uri_replace_decoded[loc]:
-                    result_decoded[loc] = ""    
-                else:
-                    result_decoded[loc] = re.sub(i, uri_replace_decoded[loc], uri_decoded[loc])
-                if uri_find_decoded.index(i) == 2:
-                    basename = None
-                    if ud.mirrortarball:
-                        basename = os.path.basename(ud.mirrortarball)
-                    elif ud.localpath:
-                        basename = os.path.basename(ud.localpath)
-                    if basename and result_decoded[loc].endswith("/"):
-                        result_decoded[loc] = os.path.dirname(result_decoded[loc])
-                    if basename and not result_decoded[loc].endswith(basename):
-                        result_decoded[loc] = os.path.join(result_decoded[loc], basename)
+        regexp = i
+        if loc == 0 and regexp and not regexp.endswith("$"):
+            # Leaving the type unanchored can mean "https" matching "file" can become "files"
+            # which is clearly undesirable.
+            regexp += "$"
+        if loc == 5:
+            # Handle URL parameters
+            if i:
+                # Any specified URL parameters must match
+                for k in uri_replace_decoded[loc]:
+                    if uri_decoded[loc][k] != uri_replace_decoded[loc][k]:
+                        return None
+            # Overwrite any specified replacement parameters
+            for k in uri_replace_decoded[loc]:
+                result_decoded[loc][k] = uri_replace_decoded[loc][k]
+        elif (re.match(regexp, uri_decoded[loc])):
+            if not uri_replace_decoded[loc]:
+                result_decoded[loc] = ""    
             else:
-                return ud.url
+                for k in replacements:
+                    uri_replace_decoded[loc] = uri_replace_decoded[loc].replace(k, replacements[k])
+                #bb.note("%s %s %s" % (regexp, uri_replace_decoded[loc], uri_decoded[loc]))
+                result_decoded[loc] = re.sub(regexp, uri_replace_decoded[loc], uri_decoded[loc])
+            if loc == 2:
+                # Handle path manipulations
+                basename = None
+                if uri_decoded[0] != uri_replace_decoded[0] and ud.mirrortarball:
+                    # If the source and destination url types differ, must be a mirrortarball mapping
+                    basename = os.path.basename(ud.mirrortarball)
+                    # Kill parameters, they make no sense for mirror tarballs
+                    uri_decoded[5] = {}
+                elif ud.localpath and ud.method.supports_checksum(ud):
+                    basename = os.path.basename(ud.localpath)
+                if basename and not result_decoded[loc].endswith(basename):
+                    result_decoded[loc] = os.path.join(result_decoded[loc], basename)
+        else:
+            return None
     result = encodeurl(result_decoded)
+    if result == ud.url:
+        return None
     logger.debug(2, "For url %s returning %s" % (ud.url, result))
     return result
 
@@ -229,10 +260,18 @@ def fetcher_init(d):
     else:
         raise FetchError("Invalid SRCREV cache policy of: %s" % srcrev_policy)
 
+    _checksum_cache.init_cache(d)
+
     for m in methods:
         if hasattr(m, "init"):
             m.init(d)
 
+def fetcher_parse_save(d):
+    _checksum_cache.save_extras(d)
+
+def fetcher_parse_done(d):
+    _checksum_cache.save_merge(d)
+
 def fetcher_compare_revisions(d):
     """
     Compare the revisions in the persistant cache with current values and
@@ -259,39 +298,37 @@ def verify_checksum(u, ud, d):
     """
     verify the MD5 and SHA256 checksum for downloaded src
 
-    return value:
-        - True: a checksum matched
-        - False: neither checksum matched
+    Raises a FetchError if one or both of the SRC_URI checksums do not match
+    the downloaded file, or if BB_STRICT_CHECKSUM is set and there are no
+    checksums specified.
 
-    if checksum is missing in recipes file, "BB_STRICT_CHECKSUM" decide the return value.
-    if BB_STRICT_CHECKSUM = "1" then return false as unmatched, otherwise return true as
-    matched
     """
 
-    if not ud.type in ["http", "https", "ftp", "ftps"]:
+    if not ud.method.supports_checksum(ud):
         return
 
     md5data = bb.utils.md5_file(ud.localpath)
     sha256data = bb.utils.sha256_file(ud.localpath)
 
-    # If strict checking enabled and neither sum defined, raise error
-    strict = d.getVar("BB_STRICT_CHECKSUM", True) or None
-    if (strict and ud.md5_expected == None and ud.sha256_expected == None):
-        raise FetchError('No checksum specified for %s, please add at least one to the recipe:\n'
-                         'SRC_URI[%s] = "%s"\nSRC_URI[%s] = "%s"' %
-                         (ud.localpath, ud.md5_name, md5data,
-                         ud.sha256_name, sha256data), u)
+    if ud.method.recommends_checksum(ud):
+        # If strict checking enabled and neither sum defined, raise error
+        strict = d.getVar("BB_STRICT_CHECKSUM", True) or None
+        if (strict and ud.md5_expected == None and ud.sha256_expected == None):
+            raise FetchError('No checksum specified for %s, please add at least one to the recipe:\n'
+                             'SRC_URI[%s] = "%s"\nSRC_URI[%s] = "%s"' %
+                             (ud.localpath, ud.md5_name, md5data,
+                              ud.sha256_name, sha256data), u)
 
-    # Log missing sums so user can more easily add them
-    if ud.md5_expected == None:
-        logger.warn('Missing md5 SRC_URI checksum for %s, consider adding to the recipe:\n'
-                    'SRC_URI[%s] = "%s"',
-                    ud.localpath, ud.md5_name, md5data)
+        # Log missing sums so user can more easily add them
+        if ud.md5_expected == None:
+            logger.warn('Missing md5 SRC_URI checksum for %s, consider adding to the recipe:\n'
+                        'SRC_URI[%s] = "%s"',
+                        ud.localpath, ud.md5_name, md5data)
 
-    if ud.sha256_expected == None:
-        logger.warn('Missing sha256 SRC_URI checksum for %s, consider adding to the recipe:\n'
-                    'SRC_URI[%s] = "%s"',
-                    ud.localpath, ud.sha256_name, sha256data)
+        if ud.sha256_expected == None:
+            logger.warn('Missing sha256 SRC_URI checksum for %s, consider adding to the recipe:\n'
+                        'SRC_URI[%s] = "%s"',
+                        ud.localpath, ud.sha256_name, sha256data)
 
     md5mismatch = False
     sha256mismatch = False
@@ -312,7 +349,7 @@ def verify_checksum(u, ud, d):
         msg = msg + "\nFile: '%s' has %s checksum %s when %s was expected" % (ud.localpath, 'sha256', sha256data, ud.sha256_expected)
 
     if len(msg):
-        raise FetchError('Checksum mismatch!%s' % msg, u)
+        raise ChecksumError('Checksum mismatch!%s' % msg, u)
 
 
 def update_stamp(u, ud, d):
@@ -421,11 +458,10 @@ def runfetchcmd(cmd, d, quiet = False, cleanup = []):
         success = True
     except bb.process.NotFoundError as e:
         error_message = "Fetch command %s" % (e.command)
+    except bb.process.ExecutionError as e:
+        error_message = "Fetch command %s failed with exit code %s, output:\nSTDOUT: %s\nSTDERR: %s" % (e.command, e.exitcode, e.stdout, e.stderr)
     except bb.process.CmdError as e:
         error_message = "Fetch command %s could not be run:\n%s" % (e.command, e.msg)
-    except bb.process.ExecutionError as e:
-        error_message = "Fetch command %s failed with exit code %s, output:\n%s" % (e.command, e.exitcode, e.stderr)
-
     if not success:
         for f in cleanup:
             try:
@@ -446,6 +482,101 @@ def check_network_access(d, info = "", url = None):
     else:
         logger.debug(1, "Fetcher accessed the network with the command %s" % info)
 
+def build_mirroruris(origud, mirrors, ld):
+    uris = []
+    uds = []
+
+    replacements = {}
+    replacements["TYPE"] = origud.type
+    replacements["HOST"] = origud.host
+    replacements["PATH"] = origud.path
+    replacements["BASENAME"] = origud.path.split("/")[-1]
+    replacements["MIRRORNAME"] = origud.host.replace(':','.') + origud.path.replace('/', '.').replace('*', '.')
+
+    def adduri(uri, ud, uris, uds):
+        for line in mirrors:
+            try:
+                (find, replace) = line
+            except ValueError:
+                continue
+            newuri = uri_replace(ud, find, replace, replacements, ld)
+            if not newuri or newuri in uris or newuri == origud.url:
+                continue
+            try:
+                newud = FetchData(newuri, ld)
+                newud.setup_localpath(ld)
+            except bb.fetch2.BBFetchException as e:
+                logger.debug(1, "Mirror fetch failure for url %s (original url: %s)" % (newuri, origud.url))
+                logger.debug(1, str(e))
+                try:
+                    ud.method.clean(ud, ld)
+                except UnboundLocalError:
+                    pass
+                continue   
+            uris.append(newuri)
+            uds.append(newud)
+
+            adduri(newuri, newud, uris, uds)
+
+    adduri(None, origud, uris, uds)
+
+    return uris, uds
+
+def try_mirror_url(newuri, origud, ud, ld, check = False):
+    # Return of None or a value means we're finished
+    # False means try another url
+    try:
+        if check:
+            found = ud.method.checkstatus(newuri, ud, ld)
+            if found:
+                return found
+            return False
+
+        os.chdir(ld.getVar("DL_DIR", True))
+
+        if not os.path.exists(ud.donestamp) or ud.method.need_update(newuri, ud, ld):
+            ud.method.download(newuri, ud, ld)
+            if hasattr(ud.method,"build_mirror_data"):
+                ud.method.build_mirror_data(newuri, ud, ld)
+
+        if not ud.localpath or not os.path.exists(ud.localpath):
+            return False
+
+        if ud.localpath == origud.localpath:
+            return ud.localpath
+
+        # We may be obtaining a mirror tarball which needs further processing by the real fetcher
+        # If that tarball is a local file:// we need to provide a symlink to it
+        dldir = ld.getVar("DL_DIR", True)
+        if origud.mirrortarball and os.path.basename(ud.localpath) == os.path.basename(origud.mirrortarball) \
+                and os.path.basename(ud.localpath) != os.path.basename(origud.localpath):
+            open(ud.donestamp, 'w').close()
+            dest = os.path.join(dldir, os.path.basename(ud.localpath))
+            if not os.path.exists(dest):
+                os.symlink(ud.localpath, dest)
+            return None
+        # Otherwise the result is a local file:// and we symlink to it
+        if not os.path.exists(origud.localpath):
+             os.symlink(ud.localpath, origud.localpath)
+        update_stamp(newuri, origud, ld)
+        return ud.localpath
+
+    except bb.fetch2.NetworkAccess:
+        raise
+
+    except bb.fetch2.BBFetchException as e:
+        if isinstance(e, ChecksumError):
+            logger.warn("Mirror checksum failure for url %s (original url: %s)\nCleaning and trying again." % (newuri, origud.url))
+            logger.warn(str(e))
+        else:
+            logger.debug(1, "Mirror fetch failure for url %s (original url: %s)" % (newuri, origud.url))
+            logger.debug(1, str(e))
+        try:
+            ud.method.clean(ud, ld)
+        except UnboundLocalError:
+            pass
+        return False
+
 def try_mirrors(d, origud, mirrors, check = False):
     """
     Try to use a mirrored version of the sources.
@@ -456,62 +587,13 @@ def try_mirrors(d, origud, mirrors, check = False):
     mirrors is the list of mirrors we're going to try
     """
     ld = d.createCopy()
-    for line in mirrors:
-        try:
-            (find, replace) = line
-        except ValueError:
-            continue
-        newuri = uri_replace(origud, find, replace, ld)
-        if newuri == origud.url:
-            continue
-        try:
-            ud = FetchData(newuri, ld)
-            ud.setup_localpath(ld)
 
-            if check:
-                found = ud.method.checkstatus(newuri, ud, ld)
-                if found:
-                    return found
-                continue
+    uris, uds = build_mirroruris(origud, mirrors, ld)
 
-            if not os.path.exists(ud.donestamp) or ud.method.need_update(newuri, ud, ld):
-                ud.method.download(newuri, ud, ld)
-                if os.path.exists(ud.localpath):
-                    open(ud.donestamp, 'w').close()
-                    if hasattr(ud.method,"build_mirror_data"):
-                        ud.method.build_mirror_data(newuri, ud, ld)
-
-            if not ud.localpath or not os.path.exists(ud.localpath):
-                continue
-
-            if ud.localpath == origud.localpath:
-                return ud.localpath
-
-            # We may be obtaining a mirror tarball which needs further processing by the real fetcher
-            # If that tarball is a local file:// we need to provide a symlink to it
-            dldir = ld.getVar("DL_DIR", True)
-            if os.path.basename(ud.localpath) != os.path.basename(origud.localpath):
-                dest = os.path.join(dldir, os.path.basename(ud.localpath))
-                if not os.path.exists(dest):
-                    os.symlink(ud.localpath, dest)
-                return None
-            # Otherwise the result is a local file:// and we symlink to it
-            if not os.path.exists(origud.localpath):
-                 os.symlink(ud.localpath, origud.localpath)
-            return ud.localpath
-
-        except bb.fetch2.NetworkAccess:
-            raise
-
-        except bb.fetch2.BBFetchException as e:
-            logger.debug(1, "Mirror fetch failure for url %s (original url: %s)" % (newuri, origud.url))
-            logger.debug(1, str(e))
-            try:
-                if os.path.isfile(ud.localpath):
-                    bb.utils.remove(ud.localpath)
-            except UnboundLocalError:
-                pass
-            continue
+    for index, uri in enumerate(uris):
+        ret = try_mirror_url(uri, origud, uds[index], ld, check)
+        if ret != False:
+            return ret
     return None
 
 def srcrev_internal_helper(ud, d, name):
@@ -545,11 +627,85 @@ def srcrev_internal_helper(ud, d, name):
 
     return rev
 
+
+def get_checksum_file_list(d):
+    """ Get a list of files checksum in SRC_URI
+
+    Returns the resolved local paths of all local file entries in
+    SRC_URI as a space-separated string
+    """
+    fetch = Fetch([], d, cache = False, localonly = True)
+
+    dl_dir = d.getVar('DL_DIR', True)
+    filelist = []
+    for u in fetch.urls:
+        ud = fetch.ud[u]
+
+        if ud and isinstance(ud.method, local.Local):
+            ud.setup_localpath(d)
+            f = ud.localpath
+            if f.startswith(dl_dir):
+                # The local fetcher's behaviour is to return a path under DL_DIR if it couldn't find the file anywhere else
+                if os.path.exists(f):
+                    bb.warn("Getting checksum for %s SRC_URI entry %s: file not found except in DL_DIR" % (d.getVar('PN', True), os.path.basename(f)))
+                else:
+                    bb.warn("Unable to get checksum for %s SRC_URI entry %s: file could not be found" % (d.getVar('PN', True), os.path.basename(f)))
+                    continue
+            filelist.append(f)
+
+    return " ".join(filelist)
+
+
+def get_file_checksums(filelist, pn):
+    """Get a list of the checksums for a list of local files
+
+    Returns the checksums for a list of local files, caching the results as
+    it proceeds
+
+    """
+
+    def checksum_file(f):
+        try:
+            checksum = _checksum_cache.get_checksum(f)
+        except OSError as e:
+            import traceback
+            bb.warn("Unable to get checksum for %s SRC_URI entry %s: %s" % (pn, os.path.basename(f), e))
+            return None
+        return checksum
+
+    checksums = []
+    for pth in filelist.split():
+        checksum = None
+        if '*' in pth:
+            # Handle globs
+            import glob
+            for f in glob.glob(pth):
+                checksum = checksum_file(f)
+                if checksum:
+                    checksums.append((f, checksum))
+        elif os.path.isdir(pth):
+            # Handle directories
+            for root, dirs, files in os.walk(pth):
+                for name in files:
+                    fullpth = os.path.join(root, name)
+                    checksum = checksum_file(fullpth)
+                    if checksum:
+                        checksums.append((fullpth, checksum))
+        else:
+            checksum = checksum_file(pth)
+
+        if checksum:
+            checksums.append((pth, checksum))
+
+    checksums.sort()
+    return checksums
+
+
 class FetchData(object):
     """
     A class which represents the fetcher state for a given URI.
     """
-    def __init__(self, url, d):
+    def __init__(self, url, d, localonly = False):
         # localpath is the location of a downloaded result. If not set, the file is local.
         self.donestamp = None
         self.localfile = ""
@@ -574,10 +730,14 @@ class FetchData(object):
             self.sha256_name = "sha256sum"
         if self.md5_name in self.parm:
             self.md5_expected = self.parm[self.md5_name]
+        elif self.type not in ["http", "https", "ftp", "ftps"]:
+            self.md5_expected = None
         else:
             self.md5_expected = d.getVarFlag("SRC_URI", self.md5_name)
         if self.sha256_name in self.parm:
             self.sha256_expected = self.parm[self.sha256_name]
+        elif self.type not in ["http", "https", "ftp", "ftps"]:
+            self.sha256_expected = None
         else:
             self.sha256_expected = d.getVarFlag("SRC_URI", self.sha256_name)
 
@@ -592,6 +752,13 @@ class FetchData(object):
         if not self.method:
             raise NoMethodError(url)
 
+        if localonly and not isinstance(self.method, local.Local):
+            raise NonLocalMethod()
+
+        if self.parm.get("proto", None) and "protocol" not in self.parm:
+            logger.warn('Consider updating %s recipe to use "protocol" not "proto" in SRC_URI.', d.getVar('PN', True))
+            self.parm["protocol"] = self.parm.get("proto", None)
+
         if hasattr(self.method, "urldata_init"):
             self.method.urldata_init(self, d)
 
@@ -656,6 +823,26 @@ class FetchMethod(object):
         """
         return os.path.join(data.getVar("DL_DIR", d, True), urldata.localfile)
 
+    def supports_checksum(self, urldata):
+        """
+        Is localpath something that can be represented by a checksum?
+        """
+
+        # We cannot compute checksums for directories
+        if os.path.isdir(urldata.localpath) == True:
+            return False
+        if urldata.localpath.find("*") != -1:
+             return False
+
+        return True
+
+    def recommends_checksum(self, urldata):
+        """
+        Is the backend on where checksumming is recommended (should warnings 
+        by displayed if there is no checksum)?
+        """
+        return False
+
     def _strip_leading_slashes(self, relpath):
         """
         Remove leading slash as os.path.join can't cope
@@ -706,7 +893,7 @@ class FetchMethod(object):
 
         dots = file.split(".")
         if dots[-1] in ['gz', 'bz2', 'Z']:
-            efile = os.path.join(data.getVar('WORKDIR', True),os.path.basename('.'.join(dots[0:-1])))
+            efile = os.path.join(rootdir, os.path.basename('.'.join(dots[0:-1])))
         else:
             efile = file
         cmd = None
@@ -782,7 +969,9 @@ class FetchMethod(object):
             bb.utils.mkdirhier(newdir)
             os.chdir(newdir)
 
-        cmd = "PATH=\"%s\" %s" % (data.getVar('PATH', True), cmd)
+        path = data.getVar('PATH', True)
+        if path:
+            cmd = "PATH=\"%s\" %s" % (path, cmd)
         bb.note("Unpacking %s to %s/" % (file, os.getcwd()))
         ret = subprocess.call(cmd, preexec_fn=subprocess_setup, shell=True)
 
@@ -893,7 +1082,10 @@ class FetchMethod(object):
         return "%s-%s" % (key, d.getVar("PN", True) or "")
 
 class Fetch(object):
-    def __init__(self, urls, d, cache = True):
+    def __init__(self, urls, d, cache = True, localonly = False):
+        if localonly and cache:
+            raise Exception("bb.fetch2.Fetch.__init__: cannot set cache and localonly at same time")
+
         if len(urls) == 0:
             urls = d.getVar("SRC_URI", True).split()
         self.urls = urls
@@ -901,14 +1093,19 @@ class Fetch(object):
         self.ud = {}
 
         fn = d.getVar('FILE', True)
-        if cache and fn in urldata_cache:
+        if cache and fn and fn in urldata_cache:
             self.ud = urldata_cache[fn]
 
         for url in urls:
             if url not in self.ud:
-                self.ud[url] = FetchData(url, d)
+                try:
+                    self.ud[url] = FetchData(url, d, localonly)
+                except NonLocalMethod:
+                    if localonly:
+                        self.ud[url] = None
+                        pass
 
-        if cache:
+        if fn and cache:
             urldata_cache[fn] = self.ud
 
     def localpath(self, url):
@@ -962,6 +1159,8 @@ class Fetch(object):
                 if premirroronly:
                     self.d.setVar("BB_NO_NETWORK", "1")
 
+                os.chdir(self.d.getVar("DL_DIR", True))
+
                 firsterr = None
                 if not localpath and ((not os.path.exists(ud.donestamp)) or m.need_update(u, ud, self.d)):
                     try:
@@ -978,12 +1177,14 @@ class Fetch(object):
                         raise
 
                     except BBFetchException as e:
-                        logger.warn('Failed to fetch URL %s' % u)
-                        logger.debug(1, str(e))
+                        if isinstance(e, ChecksumError):
+                            logger.warn("Checksum error encountered with download (will attempt other sources): %s" % str(e))
+                        else:
+                            logger.warn('Failed to fetch URL %s, attempting MIRRORS if available' % u)
+                            logger.debug(1, str(e))
                         firsterr = e
                         # Remove any incomplete fetch
-                        if os.path.isfile(ud.localpath):
-                            bb.utils.remove(ud.localpath)
+                        m.clean(ud, self.d)
                         logger.debug(1, "Trying MIRRORS")
                         mirrors = mirror_from_string(self.d.getVar('MIRRORS', True))
                         localpath = try_mirrors (self.d, ud, mirrors)
@@ -1021,7 +1222,7 @@ class Fetch(object):
                 except:
                     # Finally, try checking uri, u, from MIRRORS
                     mirrors = mirror_from_string(self.d.getVar('MIRRORS', True))
-                    ret = try_mirrors (self.d, ud, mirrors, True)
+                    ret = try_mirrors(self.d, ud, mirrors, True)
 
             if not ret:
                 raise FetchError("URL %s doesn't work" % u, u)

bitbake/lib/bb/fetch2/bzr.py

@@ -60,7 +60,7 @@ class Bzr(FetchMethod):
 
         basecmd = data.expand('${FETCHCMD_bzr}', d)
 
-        proto =  ud.parm.get('proto', 'http')
+        proto =  ud.parm.get('protocol', 'http')
 
         bzrroot = ud.host + ud.path
 

bitbake/lib/bb/fetch2/cvs.py

@@ -111,15 +111,9 @@ class Cvs(FetchMethod):
         if ud.tag:
             options.append("-r %s" % ud.tag)
 
-        localdata = data.createCopy(d)
-        data.setVar('OVERRIDES', "cvs:%s" % data.getVar('OVERRIDES', localdata), localdata)
-        data.update_data(localdata)
-
-        data.setVar('CVSROOT', cvsroot, localdata)
-        data.setVar('CVSCOOPTS', " ".join(options), localdata)
-        data.setVar('CVSMODULE', ud.module, localdata)
-        cvscmd = data.getVar('FETCHCOMMAND', localdata, True)
-        cvsupdatecmd = data.getVar('UPDATECOMMAND', localdata, True)
+        cvsbasecmd = d.getVar("FETCHCMD_cvs", True)
+        cvscmd = cvsbasecmd + "'-d" + cvsroot + "' co " + " ".join(options) + " " + ud.module
+        cvsupdatecmd = cvsbasecmd + "'-d" + cvsroot + "' update -d -P " + " ".join(options)
 
         if cvs_rsh:
             cvscmd = "CVS_RSH=\"%s\" %s" % (cvs_rsh, cvscmd)

bitbake/lib/bb/fetch2/git.py

@@ -82,6 +82,9 @@ class Git(FetchMethod):
         """
         return ud.type in ['git']
 
+    def supports_checksum(self, urldata):
+        return False
+
     def urldata_init(self, ud, d):
         """
         init git specific variable within url data
@@ -123,10 +126,11 @@ class Git(FetchMethod):
         for name in ud.names:
             # Ensure anything that doesn't look like a sha256 checksum/revision is translated into one
             if not ud.revisions[name] or len(ud.revisions[name]) != 40  or (False in [c in "abcdef0123456789" for c in ud.revisions[name]]):
-                ud.branches[name] = ud.revisions[name]
+                if ud.revisions[name]:
+                    ud.branches[name] = ud.revisions[name]
                 ud.revisions[name] = self.latest_revision(ud.url, ud, d, name)
 
-        gitsrcname = '%s%s' % (ud.host.replace(':','.'), ud.path.replace('/', '.'))
+        gitsrcname = '%s%s' % (ud.host.replace(':','.'), ud.path.replace('/', '.').replace('*', '.'))
         # for rebaseable git repo, it is necessary to keep mirror tar ball
         # per revision, so that even the revision disappears from the
         # upstream repo in the future, the mirror will remain intact and still
@@ -135,8 +139,9 @@ class Git(FetchMethod):
             for name in ud.names:
                 gitsrcname = gitsrcname + '_' + ud.revisions[name]
         ud.mirrortarball = 'git2_%s.tar.gz' % (gitsrcname)
-        ud.fullmirror = os.path.join(data.getVar("DL_DIR", d, True), ud.mirrortarball)
-        ud.clonedir = os.path.join(data.expand('${GITDIR}', d), gitsrcname)
+        ud.fullmirror = os.path.join(d.getVar("DL_DIR", True), ud.mirrortarball)
+        gitdir = d.getVar("GITDIR", True) or (d.getVar("DL_DIR", True) + "/git2/")
+        ud.clonedir = os.path.join(gitdir, gitsrcname)
 
         ud.localfile = ud.clonedir
 
@@ -183,8 +188,12 @@ class Git(FetchMethod):
 
         # If the repo still doesn't exist, fallback to cloning it
         if not os.path.exists(ud.clonedir):
+            # We do this since git will use a "-l" option automatically for local urls where possible
+            if repourl.startswith("file://"):
+                repourl = repourl[7:]
             clone_cmd = "%s clone --bare --mirror %s %s" % (ud.basecmd, repourl, ud.clonedir)
-            bb.fetch2.check_network_access(d, clone_cmd)
+            if ud.proto.lower() != 'file':
+                bb.fetch2.check_network_access(d, clone_cmd)
             runfetchcmd(clone_cmd, d)
 
         os.chdir(ud.clonedir)
@@ -195,14 +204,14 @@ class Git(FetchMethod):
                 needupdate = True
         if needupdate:
             try: 
-                runfetchcmd("%s remote prune origin" % ud.basecmd, d) 
                 runfetchcmd("%s remote rm origin" % ud.basecmd, d) 
             except bb.fetch2.FetchError:
                 logger.debug(1, "No Origin")
 
             runfetchcmd("%s remote add --mirror=fetch origin %s" % (ud.basecmd, repourl), d)
             fetch_cmd = "%s fetch -f --prune %s refs/*:refs/*" % (ud.basecmd, repourl)
-            bb.fetch2.check_network_access(d, fetch_cmd, ud.url)
+            if ud.proto.lower() != 'file':
+                bb.fetch2.check_network_access(d, fetch_cmd, ud.url)
             runfetchcmd(fetch_cmd, d)
             runfetchcmd("%s prune-packed" % ud.basecmd, d)
             runfetchcmd("%s pack-redundant --all | xargs -r rm" % ud.basecmd, d)
@@ -281,7 +290,8 @@ class Git(FetchMethod):
         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])
-        bb.fetch2.check_network_access(d, cmd)
+        if ud.proto.lower() != 'file':
+            bb.fetch2.check_network_access(d, cmd)
         output = runfetchcmd(cmd, d, True)
         if not output:
             raise bb.fetch2.FetchError("The command %s gave empty output unexpectedly" % cmd, url)

bitbake/lib/bb/fetch2/hg.py

@@ -82,7 +82,7 @@ class Hg(FetchMethod):
 
         basecmd = data.expand('${FETCHCMD_hg}', d)
 
-        proto = ud.parm.get('proto', 'http')
+        proto = ud.parm.get('protocol', 'http')
 
         host = ud.host
         if proto == "file":

bitbake/lib/bb/fetch2/local.py

@@ -26,6 +26,7 @@ BitBake build tools.
 # Based on functions from the base bb module, Copyright 2003 Holger Schurig
 
 import os
+import urllib
 import bb
 import bb.utils
 from   bb import data
@@ -40,7 +41,7 @@ class Local(FetchMethod):
 
     def urldata_init(self, ud, d):
         # We don't set localfile as for this fetcher the file is already local!
-        ud.basename = os.path.basename(ud.url.split("://")[1].split(";")[0])
+        ud.basename = os.path.basename(urllib.unquote(ud.url.split("://")[1].split(";")[0]))
         return
 
     def localpath(self, url, urldata, d):
@@ -49,6 +50,7 @@ class Local(FetchMethod):
         """
         path = url.split("://")[1]
         path = path.split(";")[0]
+        path = urllib.unquote(path)
         newpath = path
         if path[0] != "/":
             filespath = data.getVar('FILESPATH', d, True)

bitbake/lib/bb/fetch2/osc.py

@@ -57,7 +57,7 @@ class Osc(FetchMethod):
 
         basecmd = data.expand('${FETCHCMD_osc}', d)
 
-        proto = ud.parm.get('proto', 'ocs')
+        proto = ud.parm.get('protocol', 'ocs')
 
         options = []
 

bitbake/lib/bb/fetch2/perforce.py

@@ -27,6 +27,7 @@ BitBake build tools.
 
 from future_builtins import zip
 import os
+import subprocess
 import logging
 import bb
 from   bb import data
@@ -90,8 +91,8 @@ class Perforce(FetchMethod):
 
         p4cmd = data.getVar('FETCHCOMMAND_p4', d, True)
         logger.debug(1, "Running %s%s changes -m 1 %s", p4cmd, p4opt, depot)
-        p4file = os.popen("%s%s changes -m 1 %s" % (p4cmd, p4opt, depot))
-        cset = p4file.readline().strip()
+        p4file, errors = bb.process.run("%s%s changes -m 1 %s" % (p4cmd, p4opt, depot))
+        cset = p4file.strip()
         logger.debug(1, "READ %s", cset)
         if not cset:
             return -1
@@ -154,8 +155,8 @@ class Perforce(FetchMethod):
         logger.debug(2, "Fetch: creating temporary directory")
         bb.utils.mkdirhier(data.expand('${WORKDIR}', localdata))
         data.setVar('TMPBASE', data.expand('${WORKDIR}/oep4.XXXXXX', localdata), localdata)
-        tmppipe = os.popen(data.getVar('MKTEMPDIRCMD', localdata, True) or "false")
-        tmpfile = tmppipe.readline().strip()
+        tmpfile, errors = bb.process.run(data.getVar('MKTEMPDIRCMD', localdata, True) or "false")
+        tmpfile = tmpfile.strip()
         if not tmpfile:
             raise FetchError("Fetch: unable to create temporary directory.. make sure 'mktemp' is in the PATH.", loc)
 
@@ -168,7 +169,8 @@ class Perforce(FetchMethod):
         os.chdir(tmpfile)
         logger.info("Fetch " + loc)
         logger.info("%s%s files %s", p4cmd, p4opt, depot)
-        p4file = os.popen("%s%s files %s" % (p4cmd, p4opt, depot))
+        p4file, errors = bb.process.run("%s%s files %s" % (p4cmd, p4opt, depot))
+        p4file = p4file.strip()
 
         if not p4file:
             raise FetchError("Fetch: unable to get the P4 files from %s" % depot, loc)
@@ -184,7 +186,7 @@ class Perforce(FetchMethod):
             dest = list[0][len(path)+1:]
             where = dest.find("#")
 
-            os.system("%s%s print -o %s/%s %s" % (p4cmd, p4opt, module, dest[:where], list[0]))
+            subprocess.call("%s%s print -o %s/%s %s" % (p4cmd, p4opt, module, dest[:where], list[0]), shell=True)
             count = count + 1
 
         if count == 0:

bitbake/lib/bb/fetch2/ssh.py

@@ -69,6 +69,9 @@ class SSH(FetchMethod):
     def supports(self, url, urldata, d):
         return __pattern__.match(url) != None
 
+    def supports_checksum(self, urldata):
+        return False
+
     def localpath(self, url, urldata, d):
         m = __pattern__.match(urldata.url)
         path = m.group('path')

bitbake/lib/bb/fetch2/svk.py

@@ -77,8 +77,8 @@ class Svk(FetchMethod):
         logger.debug(2, "Fetch: creating temporary directory")
         bb.utils.mkdirhier(data.expand('${WORKDIR}', localdata))
         data.setVar('TMPBASE', data.expand('${WORKDIR}/oesvk.XXXXXX', localdata), localdata)
-        tmppipe = os.popen(data.getVar('MKTEMPDIRCMD', localdata, True) or "false")
-        tmpfile = tmppipe.readline().strip()
+        tmpfile, errors = bb.process.run(data.getVar('MKTEMPDIRCMD', localdata, True) or "false")
+        tmpfile = tmpfile.strip()
         if not tmpfile:
             logger.error()
             raise FetchError("Fetch: unable to create temporary directory.. make sure 'mktemp' is in the PATH.", loc)

bitbake/lib/bb/fetch2/svn.py

@@ -49,6 +49,8 @@ class Svn(FetchMethod):
         if not "module" in ud.parm:
             raise MissingParameterError('module', ud.url)
 
+        ud.basecmd = d.getVar('FETCHCMD_svn', True)
+
         ud.module = ud.parm["module"]
 
         # Create paths to svn checkouts
@@ -69,8 +71,6 @@ class Svn(FetchMethod):
         command is "fetch", "update", "info"
         """
 
-        basecmd = data.expand('${FETCHCMD_svn}', d)
-
         proto = ud.parm.get('proto', 'svn')
 
         svn_rsh = None
@@ -88,7 +88,7 @@ class Svn(FetchMethod):
             options.append("--password %s" % ud.pswd)
 
         if command == "info":
-            svncmd = "%s info %s %s://%s/%s/" % (basecmd, " ".join(options), proto, svnroot, ud.module)
+            svncmd = "%s info %s %s://%s/%s/" % (ud.basecmd, " ".join(options), proto, svnroot, ud.module)
         else:
             suffix = ""
             if ud.revision:
@@ -96,9 +96,9 @@ class Svn(FetchMethod):
                 suffix = "@%s" % (ud.revision)
 
             if command == "fetch":
-                svncmd = "%s co %s %s://%s/%s%s %s" % (basecmd, " ".join(options), proto, svnroot, ud.module, suffix, ud.module)
+                svncmd = "%s co %s %s://%s/%s%s %s" % (ud.basecmd, " ".join(options), proto, svnroot, ud.module, suffix, ud.module)
             elif command == "update":
-                svncmd = "%s update %s" % (basecmd, " ".join(options))
+                svncmd = "%s update %s" % (ud.basecmd, " ".join(options))
             else:
                 raise FetchError("Invalid svn command %s" % command, ud.url)
 
@@ -117,6 +117,11 @@ class Svn(FetchMethod):
             logger.info("Update " + loc)
             # update sources there
             os.chdir(ud.moddir)
+            # We need to attempt to run svn upgrade first in case its an older working format
+            try:
+                runfetchcmd(ud.basecmd + " upgrade", d)
+            except FetchError:
+                pass
             logger.debug(1, "Running %s", svnupdatecmd)
             bb.fetch2.check_network_access(d, svnupdatecmd, ud.url)
             runfetchcmd(svnupdatecmd, d)

bitbake/lib/bb/fetch2/wget.py

@@ -45,6 +45,9 @@ class Wget(FetchMethod):
         """
         return ud.type in ['http', 'https', 'ftp']
 
+    def recommends_checksum(self, urldata):
+        return True
+
     def urldata_init(self, ud, d):
 
         ud.basename = os.path.basename(ud.path)
@@ -53,39 +56,34 @@ class Wget(FetchMethod):
     def download(self, uri, ud, d, checkonly = False):
         """Fetch urls"""
 
-        def fetch_uri(uri, ud, d):
-            if checkonly:
-                fetchcmd = data.getVar("CHECKCOMMAND", d, True)
-            elif os.path.exists(ud.localpath):
-                # file exists, but we didnt complete it.. trying again..
-                fetchcmd = data.getVar("RESUMECOMMAND", d, True)
-            else:
-                fetchcmd = data.getVar("FETCHCOMMAND", d, True)
+        basecmd = d.getVar("FETCHCMD_wget", True) or "/usr/bin/env wget -t 2 -T 30 -nv --passive-ftp --no-check-certificate"
 
-            uri = uri.split(";")[0]
-            uri_decoded = list(decodeurl(uri))
-            uri_type = uri_decoded[0]
-            uri_host = uri_decoded[1]
+        if checkonly:
+            fetchcmd = d.getVar("CHECKCOMMAND_wget", True) or d.expand(basecmd + " -c -P ${DL_DIR} '${URI}'")
+        elif os.path.exists(ud.localpath):
+            # file exists, but we didnt complete it.. trying again..
+            fetchcmd = d.getVar("RESUMECOMMAND_wget", True) or d.expand(basecmd + " --spider -P ${DL_DIR} '${URI}'")
+        else:
+            fetchcmd = d.getVar("FETCHCOMMAND_wget", True) or d.expand(basecmd + " -P ${DL_DIR} '${URI}'")
 
-            fetchcmd = fetchcmd.replace("${URI}", uri.split(";")[0])
-            fetchcmd = fetchcmd.replace("${FILE}", ud.basename)
-            if not checkonly:
-                logger.info("fetch " + uri)
-                logger.debug(2, "executing " + fetchcmd)
-            bb.fetch2.check_network_access(d, fetchcmd)
-            runfetchcmd(fetchcmd, d, quiet=checkonly)
+        uri = uri.split(";")[0]
+        uri_decoded = list(decodeurl(uri))
+        uri_type = uri_decoded[0]
+        uri_host = uri_decoded[1]
 
-            # Sanity check since wget can pretend it succeed when it didn't
-            # Also, this used to happen if sourceforge sent us to the mirror page
-            if not os.path.exists(ud.localpath) and not checkonly:
-                raise FetchError("The fetch command returned success for url %s but %s doesn't exist?!" % (uri, ud.localpath), uri)
+        fetchcmd = fetchcmd.replace("${URI}", uri.split(";")[0])
+        fetchcmd = fetchcmd.replace("${FILE}", ud.basename)
+        if not checkonly:
+            logger.info("fetch " + uri)
+            logger.debug(2, "executing " + fetchcmd)
+        bb.fetch2.check_network_access(d, fetchcmd)
+        runfetchcmd(fetchcmd, d, quiet=checkonly)
 
-        localdata = data.createCopy(d)
-        data.setVar('OVERRIDES', "wget:" + data.getVar('OVERRIDES', localdata), localdata)
-        data.update_data(localdata)
+        # Sanity check since wget can pretend it succeed when it didn't
+        # Also, this used to happen if sourceforge sent us to the mirror page
+        if not os.path.exists(ud.localpath) and not checkonly:
+            raise FetchError("The fetch command returned success for url %s but %s doesn't exist?!" % (uri, ud.localpath), uri)
 
-        fetch_uri(uri, ud, localdata)
-        
         return True
 
     def checkstatus(self, uri, ud, d):

bitbake/lib/bb/methodpool.py

@@ -52,7 +52,7 @@ def insert_method(modulename, code, fn):
         if name in ['None', 'False']:
             continue
         elif name in _parsed_fns and not _parsed_fns[name] == modulename:
-            error( "Error Method already seen: %s in' %s' now in '%s'" % (name, _parsed_fns[name], modulename))
+            error("The function %s defined in %s was already declared in %s. BitBake has a global python function namespace so shared functions should be declared in a common include file rather than being duplicated, or if the functions are different, please use different function names." % (name, modulename, _parsed_fns[name]))
         else:
             _parsed_fns[name] = modulename
 

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

@@ -69,7 +69,7 @@ def supports(fn, d):
     return os.path.splitext(fn)[-1] in [".bb", ".bbclass", ".inc"]
 
 def inherit(files, fn, lineno, d):
-    __inherit_cache = data.getVar('__inherit_cache', d) or []
+    __inherit_cache = d.getVar('__inherit_cache') or []
     files = d.expand(files).split()
     for file in files:
         if not os.path.isabs(file) and not file.endswith(".bbclass"):
@@ -80,7 +80,7 @@ def inherit(files, fn, lineno, d):
             __inherit_cache.append( file )
             data.setVar('__inherit_cache', __inherit_cache, d)
             include(fn, file, lineno, d, "inherit")
-            __inherit_cache = data.getVar('__inherit_cache', d) or []
+            __inherit_cache = d.getVar('__inherit_cache') or []
 
 def get_statements(filename, absolute_filename, base_name):
     global cached_statements
@@ -126,13 +126,13 @@ def handle(fn, d, include):
     if ext == ".bbclass":
         __classname__ = root
         classes.append(__classname__)
-        __inherit_cache = data.getVar('__inherit_cache', d) or []
+        __inherit_cache = d.getVar('__inherit_cache') or []
         if not fn in __inherit_cache:
             __inherit_cache.append(fn)
             data.setVar('__inherit_cache', __inherit_cache, d)
 
     if include != 0:
-        oldfile = data.getVar('FILE', d)
+        oldfile = d.getVar('FILE')
     else:
         oldfile = None
 

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

@@ -71,6 +71,14 @@ def include(oldfn, fn, lineno, data, error_out):
             raise ParseError("Could not %(error_out)s file %(fn)s" % vars(), oldfn, lineno)
         logger.debug(2, "CONF file '%s' not found", 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
+# a weak default, it turns out to be very difficult to filter out these changes,
+# particularly when the weak default might appear half way though parsing a chain 
+# of configuration files. We therefore let the UIs hook into configuration file
+# parsing. This turns out to be a hard problem to solve any other way.
+confFilters = []
+
 def handle(fn, data, include):
     init(data)
 
@@ -107,6 +115,9 @@ def handle(fn, data, include):
     if oldfile:
         data.setVar('FILE', oldfile)
 
+    for f in confFilters:
+        f(fn, data)
+
     return data
 
 def feeder(lineno, s, fn, statements):

bitbake/lib/bb/process.py

@@ -1,6 +1,8 @@
 import logging
 import signal
 import subprocess
+import errno
+import select
 
 logger = logging.getLogger('BitBake.Process')
 
@@ -68,20 +70,38 @@ def _logged_communicate(pipe, log, input):
             pipe.stdin.write(input)
         pipe.stdin.close()
 
-    bufsize = 512
     outdata, errdata = [], []
-    while pipe.poll() is None:
-        if pipe.stdout is not None:
-            data = pipe.stdout.read(bufsize)
-            if data is not None:
-                outdata.append(data)
-                log.write(data)
+    rin = []
 
-        if pipe.stderr is not None:
-            data = pipe.stderr.read(bufsize)
-            if data is not None:
-                errdata.append(data)
-                log.write(data)
+    if pipe.stdout is not None:
+        bb.utils.nonblockingfd(pipe.stdout.fileno())
+        rin.append(pipe.stdout)
+    if pipe.stderr is not None:
+        bb.utils.nonblockingfd(pipe.stderr.fileno())
+        rin.append(pipe.stderr)
+
+    try:
+        while pipe.poll() is None:
+            rlist = rin
+            try:
+                r,w,e = select.select (rlist, [], [])
+            except OSError, e:
+                if e.errno != errno.EINTR:
+                    raise
+
+            if pipe.stdout in r:
+                data = pipe.stdout.read()
+                if data is not None:
+                    outdata.append(data)
+                    log.write(data)
+
+            if pipe.stderr in r:
+                data = pipe.stderr.read()
+                if data is not None:
+                    errdata.append(data)
+                    log.write(data)
+    finally:    
+        log.flush()
     return ''.join(outdata), ''.join(errdata)
 
 def run(cmd, input=None, log=None, **options):

bitbake/lib/bb/providers.py

@@ -35,6 +35,8 @@ class NoProvider(bb.BBHandledException):
 class NoRProvider(bb.BBHandledException):
     """Exception raised when no provider of a runtime dependency can be found"""
 
+class MultipleRProvider(bb.BBHandledException):
+    """Exception raised when multiple providers of a runtime dependency can be found"""
 
 def findProviders(cfgData, dataCache, pkg_pn = None):
     """

bitbake/lib/bb/runqueue.py

@@ -375,9 +375,8 @@ class RunQueueData:
         """
 
         runq_build = []
-        recursive_tdepends = {}
-        runq_recrdepends = []
-        tdepends_fnid = {}
+        recursivetasks = {}
+        recursivetasksselfref = set()
 
         taskData = self.taskData
 
@@ -406,11 +405,10 @@ class RunQueueData:
                 depdata = taskData.build_targets[depid][0]
                 if depdata is None:
                     continue
-                dep = taskData.fn_index[depdata]
                 for taskname in tasknames:
-                    taskid = taskData.gettask_id(dep, taskname, False)
+                    taskid = taskData.gettask_id_fromfnid(depdata, taskname)
                     if taskid is not None:
-                        depends.append(taskid)
+                        depends.add(taskid)
 
         def add_runtime_dependencies(depids, tasknames, depends):
             for depid in depids:
@@ -419,15 +417,20 @@ class RunQueueData:
                 depdata = taskData.run_targets[depid][0]
                 if depdata is None:
                     continue
-                dep = taskData.fn_index[depdata]
                 for taskname in tasknames:
-                    taskid = taskData.gettask_id(dep, taskname, False)
+                    taskid = taskData.gettask_id_fromfnid(depdata, taskname)
                     if taskid is not None:
-                        depends.append(taskid)
+                        depends.add(taskid)
+
+        def add_resolved_dependencies(depids, tasknames, depends):
+            for depid in depids:
+                for taskname in tasknames:
+                    taskid = taskData.gettask_id_fromfnid(depid, taskname)
+                    if taskid is not None:
+                        depends.add(taskid)
 
         for task in xrange(len(taskData.tasks_name)):
-            depends = []
-            recrdepends = []
+            depends = set()
             fnid = taskData.tasks_fnid[task]
             fn = taskData.fn_index[fnid]
             task_deps = self.dataCache.task_deps[fn]
@@ -439,7 +442,7 @@ class RunQueueData:
                 # Resolve task internal dependencies
                 #
                 # e.g. addtask before X after Y
-                depends = taskData.tasks_tdepends[task]
+                depends = set(taskData.tasks_tdepends[task])
 
                 # Resolve 'deptask' dependencies
                 #
@@ -454,99 +457,91 @@ class RunQueueData:
                 # e.g. do_sometask[rdeptask] = "do_someothertask"
                 # (makes sure sometask runs after someothertask of all RDEPENDS)
                 if 'rdeptask' in task_deps and taskData.tasks_name[task] in task_deps['rdeptask']:
-                    taskname = task_deps['rdeptask'][taskData.tasks_name[task]]
-                    add_runtime_dependencies(taskData.rdepids[fnid], [taskname], depends)
+                    tasknames = task_deps['rdeptask'][taskData.tasks_name[task]].split()
+                    add_runtime_dependencies(taskData.rdepids[fnid], tasknames, depends)
 
                 # Resolve inter-task dependencies
                 #
                 # e.g. do_sometask[depends] = "targetname:do_someothertask"
                 # (makes sure sometask runs after targetname's someothertask)
-                if fnid not in tdepends_fnid:
-                    tdepends_fnid[fnid] = set()
                 idepends = taskData.tasks_idepends[task]
                 for (depid, idependtask) in idepends:
                     if depid in taskData.build_targets:
                         # Won't be in build_targets if ASSUME_PROVIDED
                         depdata = taskData.build_targets[depid][0]
                         if depdata is not None:
-                            dep = taskData.fn_index[depdata]
-                            taskid = taskData.gettask_id(dep, idependtask, False)
+                            taskid = taskData.gettask_id_fromfnid(depdata, idependtask)
                             if taskid is None:
                                 bb.msg.fatal("RunQueue", "Task %s in %s depends upon non-existent task %s in %s" % (taskData.tasks_name[task], fn, idependtask, dep))
-                            depends.append(taskid)
-                            if depdata != fnid:
-                                tdepends_fnid[fnid].add(taskid)
+                            depends.add(taskid)
+                irdepends = taskData.tasks_irdepends[task]
+                for (depid, idependtask) in irdepends:
+                    if depid in taskData.run_targets:
+                        # Won't be in run_targets if ASSUME_PROVIDED
+                        depdata = taskData.run_targets[depid][0]
+                        if depdata is not None:
+                            taskid = taskData.gettask_id_fromfnid(depdata, idependtask)
+                            if taskid is None:
+                                bb.msg.fatal("RunQueue", "Task %s in %s rdepends upon non-existent task %s in %s" % (taskData.tasks_name[task], fn, idependtask, dep))
+                            depends.add(taskid)
 
-
-                # Resolve recursive 'recrdeptask' dependencies (A)
+                # Resolve recursive 'recrdeptask' dependencies (Part A)
                 #
                 # e.g. do_sometask[recrdeptask] = "do_someothertask"
                 # (makes sure sometask runs after someothertask of all DEPENDS, RDEPENDS and intertask dependencies, recursively)
                 # We cover the recursive part of the dependencies below
                 if 'recrdeptask' in task_deps and taskData.tasks_name[task] in task_deps['recrdeptask']:
-                    for taskname in task_deps['recrdeptask'][taskData.tasks_name[task]].split():
-                        recrdepends.append(taskname)
-                        add_build_dependencies(taskData.depids[fnid], [taskname], depends)
-                        add_runtime_dependencies(taskData.rdepids[fnid], [taskname], depends)
-
-                # Rmove all self references
-                if task in depends:
-                    newdep = []
-                    logger.debug(2, "Task %s (%s %s) contains self reference! %s", task, taskData.fn_index[taskData.tasks_fnid[task]], taskData.tasks_name[task], depends)
-                    for dep in depends:
-                        if task != dep:
-                            newdep.append(dep)
-                    depends = newdep
+                    tasknames = task_deps['recrdeptask'][taskData.tasks_name[task]].split()
+                    recursivetasks[task] = tasknames
+                    add_build_dependencies(taskData.depids[fnid], tasknames, depends)
+                    add_runtime_dependencies(taskData.rdepids[fnid], tasknames, depends)
+                    if taskData.tasks_name[task] in tasknames:
+                        recursivetasksselfref.add(task)
 
             self.runq_fnid.append(taskData.tasks_fnid[task])
             self.runq_task.append(taskData.tasks_name[task])
-            self.runq_depends.append(set(depends))
+            self.runq_depends.append(depends)
             self.runq_revdeps.append(set())
             self.runq_hash.append("")
 
             runq_build.append(0)
-            runq_recrdepends.append(recrdepends)
 
-        #
-        # Build a list of recursive cumulative dependencies for each fnid
-        # We do this by fnid, since if A depends on some task in B
-        # we're interested in later tasks B's fnid might have but B itself
-        # doesn't depend on
-        #
-        # Algorithm is O(tasks) + O(tasks)*O(fnids)
-        #
-        reccumdepends = {}
-        for task in xrange(len(self.runq_fnid)):
-            fnid = self.runq_fnid[task]
-            if fnid not in reccumdepends:
-                if fnid in tdepends_fnid:
-                    reccumdepends[fnid] = tdepends_fnid[fnid]
-                else:
-                    reccumdepends[fnid] = set()
-            reccumdepends[fnid].update(self.runq_depends[task])
-        for task in xrange(len(self.runq_fnid)):
-            taskfnid = self.runq_fnid[task]
-            for fnid in reccumdepends:
-                if task in reccumdepends[fnid]:
-                    reccumdepends[fnid].add(task)
-                    if taskfnid in reccumdepends:
-                        reccumdepends[fnid].update(reccumdepends[taskfnid])
-
-
-        # Resolve recursive 'recrdeptask' dependencies (B)
+        # Resolve recursive 'recrdeptask' dependencies (Part B)
         #
         # e.g. do_sometask[recrdeptask] = "do_someothertask"
         # (makes sure sometask runs after someothertask of all DEPENDS, RDEPENDS and intertask dependencies, recursively)
-        for task in xrange(len(self.runq_fnid)):
-            if len(runq_recrdepends[task]) > 0:
-                taskfnid = self.runq_fnid[task]
-                for dep in reccumdepends[taskfnid]:
-                    # Ignore self references
-                    if dep == task:
-                        continue
-                    for taskname in runq_recrdepends[task]:
-                        if taskData.tasks_name[dep] == taskname:
-                            self.runq_depends[task].add(dep)
+        # We need to do this separately since we need all of self.runq_depends to be complete before this is processed
+        extradeps = {}
+        for task in recursivetasks:
+            extradeps[task] = set(self.runq_depends[task])
+            tasknames = recursivetasks[task]
+            seendeps = set()
+            seenfnid = []
+
+            def generate_recdeps(t):
+                newdeps = set()
+                add_resolved_dependencies([taskData.tasks_fnid[t]], tasknames, newdeps)
+                extradeps[task].update(newdeps)
+                seendeps.add(t)
+                newdeps.add(t)
+                for i in newdeps:
+                    for n in self.runq_depends[i]:
+                        if n not in seendeps:
+                            generate_recdeps(n)
+            generate_recdeps(task)
+
+        # Remove circular references so that do_a[recrdeptask] = "do_a do_b" can work
+        for task in recursivetasks:
+            extradeps[task].difference_update(recursivetasksselfref)
+
+        for task in xrange(len(taskData.tasks_name)):
+            # Add in extra dependencies
+            if task in extradeps:
+                 self.runq_depends[task] = extradeps[task]
+            # Remove all self references
+            if task in self.runq_depends[task]:
+                logger.debug(2, "Task %s (%s %s) contains self reference! %s", task, taskData.fn_index[taskData.tasks_fnid[task]], taskData.tasks_name[task], self.runq_depends[task])
+                self.runq_depends[task].remove(task)
 
         # Step B - Mark all active tasks
         #
@@ -705,6 +700,28 @@ class RunQueueData:
                 continue
             self.runq_setscene.append(task)
 
+        def invalidate_task(fn, taskname, error_nostamp):
+            taskdep = self.dataCache.task_deps[fn]
+            if 'nostamp' in taskdep and taskname in taskdep['nostamp']:
+                if error_nostamp:
+                    bb.fatal("Task %s is marked nostamp, cannot invalidate this task" % taskname)
+                else:
+                    bb.debug(1, "Task %s is marked nostamp, cannot invalidate this task" % taskname)
+            else:
+                logger.verbose("Invalidate task %s, %s", taskname, fn)
+                bb.parse.siggen.invalidate_task(taskname, self.dataCache, fn)
+
+        # Invalidate task if force mode active
+        if self.cooker.configuration.force:
+            for (fn, target) in self.target_pairs:
+                invalidate_task(fn, target, False)
+
+        # Invalidate task if invalidate mode active
+        if self.cooker.configuration.invalidate_stamp:
+            for (fn, target) in self.target_pairs:
+                for st in self.cooker.configuration.invalidate_stamp.split(','):
+                    invalidate_task(fn, "do_%s" % st, True)
+
         # Interate over the task list and call into the siggen code
         dealtwith = set()
         todeal = set(range(len(self.runq_fnid)))
@@ -731,12 +748,6 @@ class RunQueueData:
                 deps.append(depidentifier)
             self.hash_deps[identifier] = deps
 
-        # Remove stamps for targets if force mode active
-        if self.cooker.configuration.force:
-            for (fn, target) in self.target_pairs:
-                logger.verbose("Remove stamp %s, %s", target, fn)
-                bb.build.del_stamp(target, self.dataCache, fn)
-
         return len(self.runq_fnid)
 
     def dump_data(self, taskQueue):
@@ -781,101 +792,7 @@ class RunQueue:
 
         self.rqexe = None
 
-    def check_stamps(self):
-        unchecked = {}
-        current = []
-        notcurrent = []
-        buildable = []
-
-        if self.stamppolicy == "perfile":
-            fulldeptree = False
-        else:
-            fulldeptree = True
-            stampwhitelist = []
-            if self.stamppolicy == "whitelist":
-                stampwhitelist = self.rqdata.stampfnwhitelist
-
-        for task in xrange(len(self.rqdata.runq_fnid)):
-            unchecked[task] = ""
-            if len(self.rqdata.runq_depends[task]) == 0:
-                buildable.append(task)
-
-        def check_buildable(self, task, buildable):
-            for revdep in self.rqdata.runq_revdeps[task]:
-                alldeps = 1
-                for dep in self.rqdata.runq_depends[revdep]:
-                    if dep in unchecked:
-                        alldeps = 0
-                if alldeps == 1:
-                    if revdep in unchecked:
-                        buildable.append(revdep)
-
-        for task in xrange(len(self.rqdata.runq_fnid)):
-            if task not in unchecked:
-                continue
-            fn = self.rqdata.taskData.fn_index[self.rqdata.runq_fnid[task]]
-            taskname = self.rqdata.runq_task[task]
-            stampfile = bb.build.stampfile(taskname, self.rqdata.dataCache, fn)
-            # If the stamp is missing its not current
-            if not os.access(stampfile, os.F_OK):
-                del unchecked[task]
-                notcurrent.append(task)
-                check_buildable(self, task, buildable)
-                continue
-            # If its a 'nostamp' task, it's not current
-            taskdep = self.rqdata.dataCache.task_deps[fn]
-            if 'nostamp' in taskdep and task in taskdep['nostamp']:
-                del unchecked[task]
-                notcurrent.append(task)
-                check_buildable(self, task, buildable)
-                continue
-
-        while (len(buildable) > 0):
-            nextbuildable = []
-            for task in buildable:
-                if task in unchecked:
-                    fn = self.taskData.fn_index[self.rqdata.runq_fnid[task]]
-                    taskname = self.rqdata.runq_task[task]
-                    stampfile = bb.build.stampfile(taskname, self.rqdata.dataCache, fn)
-                    iscurrent = True
-
-                    t1 = os.stat(stampfile)[stat.ST_MTIME]
-                    for dep in self.rqdata.runq_depends[task]:
-                        if iscurrent:
-                            fn2 = self.taskData.fn_index[self.rqdata.runq_fnid[dep]]
-                            taskname2 = self.rqdata.runq_task[dep]
-                            stampfile2 = bb.build.stampfile(taskname2, self.rqdata.dataCache, fn2)
-                            if fn == fn2 or (fulldeptree and fn2 not in stampwhitelist):
-                                if dep in notcurrent:
-                                    iscurrent = False
-                                else:
-                                    t2 = os.stat(stampfile2)[stat.ST_MTIME]
-                                    if t1 < t2:
-                                        iscurrent = False
-                    del unchecked[task]
-                    if iscurrent:
-                        current.append(task)
-                    else:
-                        notcurrent.append(task)
-
-                check_buildable(self, task, nextbuildable)
-
-            buildable = nextbuildable
-
-        #for task in range(len(self.runq_fnid)):
-        #    fn = self.taskData.fn_index[self.runq_fnid[task]]
-        #    taskname = self.runq_task[task]
-        #    print "%s %s.%s" % (task, taskname, fn)
-
-        #print "Unchecked: %s" % unchecked
-        #print "Current: %s" % current
-        #print "Not current: %s" % notcurrent
-
-        if len(unchecked) > 0:
-            bb.msg.fatal("RunQueue", "check_stamps fatal internal error")
-        return current
-
-    def check_stamp_task(self, task, taskname = None, recurse = False):
+    def check_stamp_task(self, task, taskname = None, recurse = False, cache = None):
         def get_timestamp(f):
             try:
                 if not os.access(f, os.F_OK):
@@ -911,10 +828,16 @@ class RunQueue:
         if taskname != "do_setscene" and taskname.endswith("_setscene"):
             return True
 
+        if cache is None:
+            cache = {}
+
         iscurrent = True
         t1 = get_timestamp(stampfile)
         for dep in self.rqdata.runq_depends[task]:
             if iscurrent:
+                if dep in cache:
+                    iscurrent = cache[dep]
+                    continue
                 fn2 = self.rqdata.taskData.fn_index[self.rqdata.runq_fnid[dep]]
                 taskname2 = self.rqdata.runq_task[dep]
                 stampfile2 = bb.build.stampfile(taskname2, self.rqdata.dataCache, fn2)
@@ -931,7 +854,9 @@ class RunQueue:
                         logger.debug(2, 'Stampfile %s < %s', stampfile, stampfile2)
                         iscurrent = False
                     if recurse and iscurrent:
-                        iscurrent = self.check_stamp_task(dep, recurse=True)
+                        iscurrent = self.check_stamp_task(dep, recurse=True, cache=cache)
+                        cache[dep] = iscurrent
+        cache[task] = iscurrent
         return iscurrent
 
     def execute_runqueue(self):
@@ -1041,23 +966,36 @@ class RunQueueExecute:
         self.build_stamps = {}
         self.failed_fnids = []
 
+        self.stampcache = {}
+
     def runqueue_process_waitpid(self):
         """
         Return none is there are no processes awaiting result collection, otherwise
         collect the process exit codes and close the information pipe.
         """
-        result = os.waitpid(-1, os.WNOHANG)
-        if result[0] == 0 and result[1] == 0:
+        pid, status = os.waitpid(-1, os.WNOHANG)
+        if pid == 0 or os.WIFSTOPPED(status):
             return None
-        task = self.build_pids[result[0]]
-        del self.build_pids[result[0]]
-        self.build_pipes[result[0]].close()
-        del self.build_pipes[result[0]]
-        # self.build_stamps[result[0]] may not exist when use shared work directory.
-        if result[0] in self.build_stamps.keys():
-            del self.build_stamps[result[0]]
-        if result[1] != 0:
-            self.task_fail(task, result[1]>>8)
+
+        if os.WIFEXITED(status):
+            status = os.WEXITSTATUS(status)
+        elif os.WIFSIGNALED(status):
+            # Per shell conventions for $?, when a process exits due to
+            # a signal, we return an exit code of 128 + SIGNUM
+            status = 128 + os.WTERMSIG(status)
+
+        task = self.build_pids[pid]
+        del self.build_pids[pid]
+
+        self.build_pipes[pid].close()
+        del self.build_pipes[pid]
+
+        # self.build_stamps[pid] may not exist when use shared work directory.
+        if pid in self.build_stamps:
+            del self.build_stamps[pid]
+
+        if status != 0:
+            self.task_fail(task, status)
         else:
             self.task_complete(task)
         return True
@@ -1164,8 +1102,6 @@ class RunQueueExecute:
                 os.umask(umask)
 
             self.cooker.configuration.data.setVar("BB_WORKERCONTEXT", "1")
-            self.cooker.configuration.data.setVar("__RUNQUEUE_DO_NOT_USE_EXTERNALLY", self)
-            self.cooker.configuration.data.setVar("__RUNQUEUE_DO_NOT_USE_EXTERNALLY2", fn)
             bb.parse.siggen.set_taskdata(self.rqdata.hashes, self.rqdata.hash_deps)
             ret = 0
             try:
@@ -1373,7 +1309,7 @@ class RunQueueExecuteTasks(RunQueueExecute):
                 self.task_skip(task)
                 return True
 
-            if self.rq.check_stamp_task(task, taskname):
+            if self.rq.check_stamp_task(task, taskname, cache=self.stampcache):
                 logger.debug(2, "Stamp current task %s (%s)", task,
                                 self.rqdata.get_user_idstring(task))
                 self.task_skip(task)
@@ -1557,7 +1493,7 @@ class RunQueueExecuteScenequeue(RunQueueExecute):
                     bb.build.make_stamp(taskname + "_setscene", self.rqdata.dataCache, fn)
                     continue
 
-                if self.rq.check_stamp_task(realtask, taskname + "_setscene"):
+                if self.rq.check_stamp_task(realtask, taskname + "_setscene", cache=self.stampcache):
                     logger.debug(2, 'Setscene stamp current for task %s(%s)', task, self.rqdata.get_user_idstring(realtask))
                     stamppresent.append(task)
                     self.task_skip(task)
@@ -1650,7 +1586,7 @@ class RunQueueExecuteScenequeue(RunQueueExecute):
             fn = self.rqdata.taskData.fn_index[self.rqdata.runq_fnid[realtask]]
 
             taskname = self.rqdata.runq_task[realtask] + "_setscene"
-            if self.rq.check_stamp_task(realtask, self.rqdata.runq_task[realtask], recurse = True):
+            if self.rq.check_stamp_task(realtask, self.rqdata.runq_task[realtask], recurse = True, cache=self.stampcache):
                 logger.debug(2, 'Stamp for underlying task %s(%s) is current, so skipping setscene variant',
                              task, self.rqdata.get_user_idstring(realtask))
                 self.task_failoutright(task)
@@ -1662,7 +1598,7 @@ class RunQueueExecuteScenequeue(RunQueueExecute):
                         self.task_failoutright(task)
                         return True
 
-            if self.rq.check_stamp_task(realtask, taskname):
+            if self.rq.check_stamp_task(realtask, taskname, cache=self.stampcache):
                 logger.debug(2, 'Setscene stamp current task %s(%s), so skip it and its dependencies',
                              task, self.rqdata.get_user_idstring(realtask))
                 self.task_skip(task)
@@ -1776,15 +1712,6 @@ class runQueueTaskCompleted(runQueueEvent):
     Event notifing a task completed
     """
 
-def check_stamp_fn(fn, taskname, d):
-    rqexe = d.getVar("__RUNQUEUE_DO_NOT_USE_EXTERNALLY")
-    fn = d.getVar("__RUNQUEUE_DO_NOT_USE_EXTERNALLY2")
-    fnid = rqexe.rqdata.taskData.getfn_id(fn)
-    taskid = rqexe.rqdata.get_task_id(fnid, taskname)
-    if taskid is not None:
-        return rqexe.rq.check_stamp_task(taskid)
-    return None
-
 class runQueuePipe():
     """
     Abstraction for a pipe between a worker thread and the server
@@ -1792,7 +1719,7 @@ class runQueuePipe():
     def __init__(self, pipein, pipeout, d):
         self.input = pipein
         pipeout.close()
-        fcntl.fcntl(self.input, fcntl.F_SETFL, fcntl.fcntl(self.input, fcntl.F_GETFL) | os.O_NONBLOCK)
+        bb.utils.nonblockingfd(self.input)
         self.queue = ""
         self.d = d
 

bitbake/lib/bb/siggen.py

@@ -50,6 +50,10 @@ class SignatureGenerator(object):
     def dump_sigtask(self, fn, task, stampbase, runtime):
         return
 
+    def invalidate_task(self, task, d, fn):
+        bb.build.del_stamp(task, d, fn)
+
+
 class SignatureGeneratorBasic(SignatureGenerator):
     """
     """
@@ -60,6 +64,7 @@ class SignatureGeneratorBasic(SignatureGenerator):
         self.taskhash = {}
         self.taskdeps = {}
         self.runtaskdeps = {}
+        self.file_checksum_values = {}
         self.gendeps = {}
         self.lookupcache = {}
         self.pkgnameextract = re.compile("(?P<fn>.*)\..*")
@@ -107,6 +112,10 @@ class SignatureGeneratorBasic(SignatureGenerator):
                 data = data + dep
                 if dep in lookupcache:
                     var = lookupcache[dep]
+                elif dep[-1] == ']':
+                    vf = dep[:-1].split('[')
+                    var = d.getVarFlag(vf[0], vf[1], False)
+                    lookupcache[dep] = var
                 else:
                     var = d.getVar(dep, False)
                     lookupcache[dep] = var
@@ -148,10 +157,20 @@ class SignatureGeneratorBasic(SignatureGenerator):
                 return False
         return True
 
+    def read_taint(self, fn, task, stampbase):
+        taint = None
+        try:
+            with open(stampbase + '.' + task + '.taint', 'r') as taintf:
+                taint = taintf.read()
+        except IOError:
+            pass
+        return taint
+
     def get_taskhash(self, fn, task, deps, dataCache):
         k = fn + "." + task
         data = dataCache.basetaskhash[k]
         self.runtaskdeps[k] = []
+        self.file_checksum_values[k] = {}
         recipename = dataCache.pkg_fn[fn]
         for dep in sorted(deps, key=clean_basepath):
             depname = dataCache.pkg_fn[self.pkgnameextract.search(dep).group('fn')]
@@ -161,6 +180,17 @@ class SignatureGeneratorBasic(SignatureGenerator):
                 bb.fatal("%s is not in taskhash, caller isn't calling in dependency order?", dep)
             data = data + self.taskhash[dep]
             self.runtaskdeps[k].append(dep)
+
+        if task in dataCache.file_checksums[fn]:
+            checksums = bb.fetch2.get_file_checksums(dataCache.file_checksums[fn][task], recipename)
+            for (f,cs) in checksums:
+               self.file_checksum_values[k][f] = cs
+               data = data + cs
+
+        taint = self.read_taint(fn, task, dataCache.stamp[fn])
+        if taint:
+            data = data + taint
+
         h = hashlib.md5(data).hexdigest()
         self.taskhash[k] = h
         #d.setVar("BB_TASKHASH_task-%s" % task, taskhash[task])
@@ -197,12 +227,19 @@ class SignatureGeneratorBasic(SignatureGenerator):
 
         if runtime and k in self.taskhash:
             data['runtaskdeps'] = self.runtaskdeps[k]
+            data['file_checksum_values'] = self.file_checksum_values[k]
             data['runtaskhashes'] = {}
             for dep in data['runtaskdeps']:
                 data['runtaskhashes'][dep] = self.taskhash[dep]
 
-        p = pickle.Pickler(file(sigfile, "wb"), -1)
-        p.dump(data)
+        taint = self.read_taint(fn, task, stampbase)
+        if taint:
+            data['taint'] = taint
+
+        with open(sigfile, "wb") as f:
+            p = pickle.Pickler(f, -1)
+            p.dump(data)
+        os.chmod(sigfile, 0664)
 
     def dump_sigs(self, dataCache):
         for fn in self.taskdeps:
@@ -230,6 +267,10 @@ class SignatureGeneratorBasicHash(SignatureGeneratorBasic):
             h = self.basehash[k]
         return ("%s.%s.%s.%s" % (stampbase, taskname, h, extrainfo)).rstrip('.')
 
+    def invalidate_task(self, task, d, fn):
+        bb.note("Tainting hash to force rebuild of task %s, %s" % (fn, task))
+        bb.build.write_taint(task, d, fn)
+
 def dump_this_task(outfile, d):
     import bb.parse
     fn = d.getVar("BB_FILENAME", True)
@@ -250,9 +291,9 @@ def clean_basepaths(a):
     return b
 
 def compare_sigfiles(a, b):
-    p1 = pickle.Unpickler(file(a, "rb"))
+    p1 = pickle.Unpickler(open(a, "rb"))
     a_data = p1.load()
-    p2 = pickle.Unpickler(file(b, "rb"))
+    p2 = pickle.Unpickler(open(b, "rb"))
     b_data = p2.load()
 
     def dict_diff(a, b, whitelist=set()):
@@ -302,6 +343,18 @@ def compare_sigfiles(a, b):
         for dep in changed:
             print "Variable %s value changed from %s to %s" % (dep, a_data['varvals'][dep], b_data['varvals'][dep])
 
+    changed, added, removed = dict_diff(a_data['file_checksum_values'], b_data['file_checksum_values'])
+    if changed:
+        for f in changed:
+            print "Checksum for file %s changed from %s to %s" % (f, a_data['file_checksum_values'][f], b_data['file_checksum_values'][f])
+    if added:
+        for f in added:
+            print "Dependency on checksum of file %s was added" % (f)
+    if removed:
+        for f in removed:
+            print "Dependency on checksum of file %s was removed" % (f)
+
+
     if 'runtaskhashes' in a_data and 'runtaskhashes' in b_data:
         a = clean_basepaths(a_data['runtaskhashes'])
         b = clean_basepaths(b_data['runtaskhashes'])
@@ -330,8 +383,15 @@ def compare_sigfiles(a, b):
             for dep in changed:
                 print "Hash for dependent task %s changed from %s to %s" % (dep, a[dep], b[dep])
 
+
+    a_taint = a_data.get('taint', None)
+    b_taint = b_data.get('taint', None)
+    if a_taint != b_taint:
+        print "Taint (by forced/invalidated task) changed from %s to %s" % (a_taint, b_taint)
+
+
 def dump_sigfile(a):
-    p1 = pickle.Unpickler(file(a, "rb"))
+    p1 = pickle.Unpickler(open(a, "rb"))
     a_data = p1.load()
 
     print "basewhitelist: %s" % (a_data['basewhitelist'])
@@ -351,6 +411,12 @@ def dump_sigfile(a):
     if 'runtaskdeps' in a_data:
         print "Tasks this task depends on: %s" % (a_data['runtaskdeps'])
 
+    if 'file_checksum_values' in a_data:
+        print "This task depends on the checksums of files: %s" % (a_data['file_checksum_values'])
+
     if 'runtaskhashes' in a_data:
         for dep in a_data['runtaskhashes']:
             print "Hash for dependent task %s is %s" % (dep, a_data['runtaskhashes'][dep])
+
+    if 'taint' in a_data:
+        print "Tainted (by forced/invalidated task): %s" % a_data['taint']

bitbake/lib/bb/taskdata.py

@@ -55,6 +55,7 @@ class TaskData:
         self.tasks_name = []
         self.tasks_tdepends = []
         self.tasks_idepends = []
+        self.tasks_irdepends = []
         # Cache to speed up task ID lookups
         self.tasks_lookup = {}
 
@@ -115,6 +116,16 @@ class TaskData:
                 ids.append(self.tasks_lookup[fnid][task])
         return ids
 
+    def gettask_id_fromfnid(self, fnid, task):
+        """
+        Return an ID number for the task matching fnid and task.
+        """
+        if fnid in self.tasks_lookup:
+            if task in self.tasks_lookup[fnid]:
+                return self.tasks_lookup[fnid][task]
+
+        return None
+
     def gettask_id(self, fn, task, create = True):
         """
         Return an ID number for the task matching fn and task.
@@ -134,6 +145,7 @@ class TaskData:
         self.tasks_fnid.append(fnid)
         self.tasks_tdepends.append([])
         self.tasks_idepends.append([])
+        self.tasks_irdepends.append([])
 
         listid = len(self.tasks_name) - 1
 
@@ -178,6 +190,15 @@ class TaskData:
                             bb.msg.fatal("TaskData", "Error for %s, dependency %s does not contain ':' character\n. Task 'depends' should be specified in the form 'packagename:task'" % (fn, dep))
                         ids.append(((self.getbuild_id(dep.split(":")[0])), dep.split(":")[1]))
                 self.tasks_idepends[taskid].extend(ids)
+            if 'rdepends' in task_deps and task in task_deps['rdepends']:
+                ids = []
+                for dep in task_deps['rdepends'][task].split():
+                    if dep:
+                        if ":" not in dep:
+                            bb.msg.fatal("TaskData", "Error for %s, dependency %s does not contain ':' character\n. Task 'rdepends' should be specified in the form 'packagename:task'" % (fn, dep))
+                        ids.append(((self.getrun_id(dep.split(":")[0])), dep.split(":")[1]))
+                self.tasks_irdepends[taskid].extend(ids)
+
 
         # Work out build dependencies
         if not fnid in self.depids:
@@ -461,6 +482,7 @@ class TaskData:
                     providers_list.append(dataCache.pkg_fn[fn])
                 bb.event.fire(bb.event.MultipleProviders(item, providers_list, runtime=True), cfgData)
             self.consider_msgs_cache.append(item)
+            raise bb.providers.MultipleRProvider(item)
 
         # run through the list until we find one that we can build
         for fn in eligible:
@@ -533,6 +555,11 @@ class TaskData:
         dependees = self.get_rdependees(targetid)
         for fnid in dependees:
             self.fail_fnid(fnid, missing_list)
+        for taskid in xrange(len(self.tasks_irdepends)):
+            irdepends = self.tasks_irdepends[taskid]
+            for (idependid, idependtask) in irdepends:
+                if idependid == targetid:
+                    self.fail_fnid(self.tasks_fnid[taskid], missing_list)
 
     def add_unresolved(self, cfgData, dataCache):
         """
@@ -554,7 +581,7 @@ class TaskData:
                 try:
                     self.add_rprovider(cfgData, dataCache, target)
                     added = added + 1
-                except bb.providers.NoRProvider:
+                except (bb.providers.NoRProvider, bb.providers.MultipleRProvider):
                     self.remove_runtarget(self.getrun_id(target))
             logger.debug(1, "Resolved " + str(added) + " extra dependencies")
             if added == 0:

bitbake/lib/bb/tests/codeparser.py

@@ -0,0 +1,369 @@
+#
+# BitBake Test for codeparser.py
+#
+# Copyright (C) 2010 Chris Larson
+# Copyright (C) 2012 Richard Purdie
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License version 2 as
+# published by the Free Software Foundation.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License along
+# with this program; if not, write to the Free Software Foundation, Inc.,
+# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+#
+
+import unittest
+import logging
+import bb
+
+logger = logging.getLogger('BitBake.TestCodeParser')
+
+import bb.data
+
+class ReferenceTest(unittest.TestCase):
+    def setUp(self):
+        self.d = bb.data.init()
+
+    def setEmptyVars(self, varlist):
+        for k in varlist:
+            self.d.setVar(k, "")
+
+    def setValues(self, values):
+        for k, v in values.items():
+            self.d.setVar(k, v)
+
+    def assertReferences(self, refs):
+        self.assertEqual(self.references, refs)
+
+    def assertExecs(self, execs):
+        self.assertEqual(self.execs, execs)
+
+class VariableReferenceTest(ReferenceTest):
+
+    def parseExpression(self, exp):
+        parsedvar = self.d.expandWithRefs(exp, None)
+        self.references = parsedvar.references
+
+    def test_simple_reference(self):
+        self.setEmptyVars(["FOO"])
+        self.parseExpression("${FOO}")
+        self.assertReferences(set(["FOO"]))
+
+    def test_nested_reference(self):
+        self.setEmptyVars(["BAR"])
+        self.d.setVar("FOO", "BAR")
+        self.parseExpression("${${FOO}}")
+        self.assertReferences(set(["FOO", "BAR"]))
+
+    def test_python_reference(self):
+        self.setEmptyVars(["BAR"])
+        self.parseExpression("${@bb.data.getVar('BAR', d, True) + 'foo'}")
+        self.assertReferences(set(["BAR"]))
+
+class ShellReferenceTest(ReferenceTest):
+
+    def parseExpression(self, exp):
+        parsedvar = self.d.expandWithRefs(exp, None)
+        parser = bb.codeparser.ShellParser("ParserTest", logger)
+        parser.parse_shell(parsedvar.value)
+
+        self.references = parsedvar.references
+        self.execs = parser.execs
+
+    def test_quotes_inside_assign(self):
+        self.parseExpression('foo=foo"bar"baz')
+        self.assertReferences(set([]))
+
+    def test_quotes_inside_arg(self):
+        self.parseExpression('sed s#"bar baz"#"alpha beta"#g')
+        self.assertExecs(set(["sed"]))
+
+    def test_arg_continuation(self):
+        self.parseExpression("sed -i -e s,foo,bar,g \\\n *.pc")
+        self.assertExecs(set(["sed"]))
+
+    def test_dollar_in_quoted(self):
+        self.parseExpression('sed -i -e "foo$" *.pc')
+        self.assertExecs(set(["sed"]))
+
+    def test_quotes_inside_arg_continuation(self):
+        self.setEmptyVars(["bindir", "D", "libdir"])
+        self.parseExpression("""
+sed -i -e s#"moc_location=.*$"#"moc_location=${bindir}/moc4"# \\
+-e s#"uic_location=.*$"#"uic_location=${bindir}/uic4"# \\
+${D}${libdir}/pkgconfig/*.pc
+""")
+        self.assertReferences(set(["bindir", "D", "libdir"]))
+
+    def test_assign_subshell_expansion(self):
+        self.parseExpression("foo=$(echo bar)")
+        self.assertExecs(set(["echo"]))
+
+    def test_shell_unexpanded(self):
+        self.setEmptyVars(["QT_BASE_NAME"])
+        self.parseExpression('echo "${QT_BASE_NAME}"')
+        self.assertExecs(set(["echo"]))
+        self.assertReferences(set(["QT_BASE_NAME"]))
+
+    def test_incomplete_varexp_single_quotes(self):
+        self.parseExpression("sed -i -e 's:IP{:I${:g' $pc")
+        self.assertExecs(set(["sed"]))
+
+
+    def test_until(self):
+        self.parseExpression("until false; do echo true; done")
+        self.assertExecs(set(["false", "echo"]))
+        self.assertReferences(set())
+
+    def test_case(self):
+        self.parseExpression("""
+case $foo in
+*)
+bar
+;;
+esac
+""")
+        self.assertExecs(set(["bar"]))
+        self.assertReferences(set())
+
+    def test_assign_exec(self):
+        self.parseExpression("a=b c='foo bar' alpha 1 2 3")
+        self.assertExecs(set(["alpha"]))
+
+    def test_redirect_to_file(self):
+        self.setEmptyVars(["foo"])
+        self.parseExpression("echo foo >${foo}/bar")
+        self.assertExecs(set(["echo"]))
+        self.assertReferences(set(["foo"]))
+
+    def test_heredoc(self):
+        self.setEmptyVars(["theta"])
+        self.parseExpression("""
+cat <<END
+alpha
+beta
+${theta}
+END
+""")
+        self.assertReferences(set(["theta"]))
+
+    def test_redirect_from_heredoc(self):
+        v = ["B", "SHADOW_MAILDIR", "SHADOW_MAILFILE", "SHADOW_UTMPDIR", "SHADOW_LOGDIR", "bindir"]
+        self.setEmptyVars(v)
+        self.parseExpression("""
+cat <<END >${B}/cachedpaths
+shadow_cv_maildir=${SHADOW_MAILDIR}
+shadow_cv_mailfile=${SHADOW_MAILFILE}
+shadow_cv_utmpdir=${SHADOW_UTMPDIR}
+shadow_cv_logdir=${SHADOW_LOGDIR}
+shadow_cv_passwd_dir=${bindir}
+END
+""")
+        self.assertReferences(set(v))
+        self.assertExecs(set(["cat"]))
+
+#    def test_incomplete_command_expansion(self):
+#        self.assertRaises(reftracker.ShellSyntaxError, reftracker.execs,
+#                          bbvalue.shparse("cp foo`", self.d), self.d)
+
+#    def test_rogue_dollarsign(self):
+#        self.setValues({"D" : "/tmp"})
+#        self.parseExpression("install -d ${D}$")
+#        self.assertReferences(set(["D"]))
+#        self.assertExecs(set(["install"]))
+
+
+class PythonReferenceTest(ReferenceTest):
+
+    def setUp(self):
+        self.d = bb.data.init()
+        if hasattr(bb.utils, "_context"):
+            self.context = bb.utils._context
+        else:
+            import __builtin__
+            self.context = __builtin__.__dict__
+
+    def parseExpression(self, exp):
+        parsedvar = self.d.expandWithRefs(exp, None)
+        parser = bb.codeparser.PythonParser("ParserTest", logger)
+        parser.parse_python(parsedvar.value)
+
+        self.references = parsedvar.references | parser.references
+        self.execs = parser.execs
+
+    @staticmethod
+    def indent(value):
+        """Python Snippets have to be indented, python values don't have to
+be. These unit tests are testing snippets."""
+        return " " + value
+
+    def test_getvar_reference(self):
+        self.parseExpression("bb.data.getVar('foo', d, True)")
+        self.assertReferences(set(["foo"]))
+        self.assertExecs(set())
+
+    def test_getvar_computed_reference(self):
+        self.parseExpression("bb.data.getVar('f' + 'o' + 'o', d, True)")
+        self.assertReferences(set())
+        self.assertExecs(set())
+
+    def test_getvar_exec_reference(self):
+        self.parseExpression("eval('bb.data.getVar(\"foo\", d, True)')")
+        self.assertReferences(set())
+        self.assertExecs(set(["eval"]))
+
+    def test_var_reference(self):
+        self.context["foo"] = lambda x: x
+        self.setEmptyVars(["FOO"])
+        self.parseExpression("foo('${FOO}')")
+        self.assertReferences(set(["FOO"]))
+        self.assertExecs(set(["foo"]))
+        del self.context["foo"]
+
+    def test_var_exec(self):
+        for etype in ("func", "task"):
+            self.d.setVar("do_something", "echo 'hi mom! ${FOO}'")
+            self.d.setVarFlag("do_something", etype, True)
+            self.parseExpression("bb.build.exec_func('do_something', d)")
+            self.assertReferences(set(["do_something"]))
+
+    def test_function_reference(self):
+        self.context["testfunc"] = lambda msg: bb.msg.note(1, None, msg)
+        self.d.setVar("FOO", "Hello, World!")
+        self.parseExpression("testfunc('${FOO}')")
+        self.assertReferences(set(["FOO"]))
+        self.assertExecs(set(["testfunc"]))
+        del self.context["testfunc"]
+
+    def test_qualified_function_reference(self):
+        self.parseExpression("time.time()")
+        self.assertExecs(set(["time.time"]))
+
+    def test_qualified_function_reference_2(self):
+        self.parseExpression("os.path.dirname('/foo/bar')")
+        self.assertExecs(set(["os.path.dirname"]))
+
+    def test_qualified_function_reference_nested(self):
+        self.parseExpression("time.strftime('%Y%m%d',time.gmtime())")
+        self.assertExecs(set(["time.strftime", "time.gmtime"]))
+
+    def test_function_reference_chained(self):
+        self.context["testget"] = lambda: "\tstrip me "
+        self.parseExpression("testget().strip()")
+        self.assertExecs(set(["testget"]))
+        del self.context["testget"]
+
+
+class DependencyReferenceTest(ReferenceTest):
+
+    pydata = """
+bb.data.getVar('somevar', d, True)
+def test(d):
+    foo = 'bar %s' % 'foo'
+def test2(d):
+    d.getVar(foo, True)
+    d.getVar('bar', False)
+    test2(d)
+
+def a():
+    \"\"\"some
+    stuff
+    \"\"\"
+    return "heh"
+
+test(d)
+
+bb.data.expand(bb.data.getVar("something", False, d), d)
+bb.data.expand("${inexpand} somethingelse", d)
+bb.data.getVar(a(), d, False)
+"""
+
+    def test_python(self):
+        self.d.setVar("FOO", self.pydata)
+        self.setEmptyVars(["inexpand", "a", "test2", "test"])
+        self.d.setVarFlags("FOO", {"func": True, "python": True})
+
+        deps, values = bb.data.build_dependencies("FOO", set(self.d.keys()), set(), set(), self.d)
+
+        self.assertEquals(deps, set(["somevar", "bar", "something", "inexpand", "test", "test2", "a"]))
+
+
+    shelldata = """
+foo () {
+bar
+}
+{
+echo baz
+$(heh)
+eval `moo`
+}
+a=b
+c=d
+(
+true && false
+test -f foo
+testval=something
+$testval
+) || aiee
+! inverted
+echo ${somevar}
+
+case foo in
+bar)
+echo bar
+;;
+baz)
+echo baz
+;;
+foo*)
+echo foo
+;;
+esac
+"""
+
+    def test_shell(self):
+        execs = ["bar", "echo", "heh", "moo", "true", "aiee"]
+        self.d.setVar("somevar", "heh")
+        self.d.setVar("inverted", "echo inverted...")
+        self.d.setVarFlag("inverted", "func", True)
+        self.d.setVar("FOO", self.shelldata)
+        self.d.setVarFlags("FOO", {"func": True})
+        self.setEmptyVars(execs)
+
+        deps, values = bb.data.build_dependencies("FOO", set(self.d.keys()), set(), set(), self.d)
+
+        self.assertEquals(deps, set(["somevar", "inverted"] + execs))
+
+
+    def test_vardeps(self):
+        self.d.setVar("oe_libinstall", "echo test")
+        self.d.setVar("FOO", "foo=oe_libinstall; eval $foo")
+        self.d.setVarFlag("FOO", "vardeps", "oe_libinstall")
+
+        deps, values = bb.data.build_dependencies("FOO", set(self.d.keys()), set(), set(), self.d)
+
+        self.assertEquals(deps, set(["oe_libinstall"]))
+
+    def test_vardeps_expand(self):
+        self.d.setVar("oe_libinstall", "echo test")
+        self.d.setVar("FOO", "foo=oe_libinstall; eval $foo")
+        self.d.setVarFlag("FOO", "vardeps", "${@'oe_libinstall'}")
+
+        deps, values = bb.data.build_dependencies("FOO", set(self.d.keys()), set(), set(), self.d)
+
+        self.assertEquals(deps, set(["oe_libinstall"]))
+
+    #Currently no wildcard support
+    #def test_vardeps_wildcards(self):
+    #    self.d.setVar("oe_libinstall", "echo test")
+    #    self.d.setVar("FOO", "foo=oe_libinstall; eval $foo")
+    #    self.d.setVarFlag("FOO", "vardeps", "oe_*")
+    #    self.assertEquals(deps, set(["oe_libinstall"]))
+
+

bitbake/lib/bb/tests/cow.py

@@ -0,0 +1,134 @@
+#
+# BitBake Tests for Copy-on-Write (cow.py)
+#
+# Copyright 2006 Holger Freyther <freyther@handhelds.org>
+#
+# 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 unittest
+import os
+
+class COWTestCase(unittest.TestCase):
+    """
+    Test case for the COW module from mithro
+    """
+
+    def testGetSet(self):
+        """
+        Test and set
+        """
+        from bb.COW import COWDictBase
+        a = COWDictBase.copy()
+
+        self.assertEquals(False, a.has_key('a'))
+
+        a['a'] = 'a'
+        a['b'] = 'b'
+        self.assertEquals(True, a.has_key('a'))
+        self.assertEquals(True, a.has_key('b'))
+        self.assertEquals('a', a['a'] )
+        self.assertEquals('b', a['b'] )
+
+    def testCopyCopy(self):
+        """
+        Test the copy of copies
+        """
+
+        from bb.COW import COWDictBase
+
+        # create two COW dict 'instances'
+        b = COWDictBase.copy()
+        c = COWDictBase.copy()
+
+        # assign some keys to one instance, some keys to another
+        b['a'] = 10
+        b['c'] = 20
+        c['a'] = 30
+
+        # test separation of the two instances
+        self.assertEquals(False, c.has_key('c'))
+        self.assertEquals(30, c['a'])
+        self.assertEquals(10, b['a'])
+
+        # test copy
+        b_2 = b.copy()
+        c_2 = c.copy()
+
+        self.assertEquals(False, c_2.has_key('c'))
+        self.assertEquals(10, b_2['a'])
+
+        b_2['d'] = 40
+        self.assertEquals(False, c_2.has_key('d'))
+        self.assertEquals(True, b_2.has_key('d'))
+        self.assertEquals(40, b_2['d'])
+        self.assertEquals(False, b.has_key('d'))
+        self.assertEquals(False, c.has_key('d'))
+
+        c_2['d'] = 30
+        self.assertEquals(True, c_2.has_key('d'))
+        self.assertEquals(True, b_2.has_key('d'))
+        self.assertEquals(30, c_2['d'])
+        self.assertEquals(40, b_2['d'])
+        self.assertEquals(False, b.has_key('d'))
+        self.assertEquals(False, c.has_key('d'))
+
+        # test copy of the copy
+        c_3 = c_2.copy()
+        b_3 = b_2.copy()
+        b_3_2 = b_2.copy()
+
+        c_3['e'] = 4711
+        self.assertEquals(4711, c_3['e'])
+        self.assertEquals(False, c_2.has_key('e'))
+        self.assertEquals(False, b_3.has_key('e'))
+        self.assertEquals(False, b_3_2.has_key('e'))
+        self.assertEquals(False, b_2.has_key('e'))
+
+        b_3['e'] = 'viel'
+        self.assertEquals('viel', b_3['e'])
+        self.assertEquals(4711, c_3['e'])
+        self.assertEquals(False, c_2.has_key('e'))
+        self.assertEquals(True, b_3.has_key('e'))
+        self.assertEquals(False, b_3_2.has_key('e'))
+        self.assertEquals(False, b_2.has_key('e'))
+
+    def testCow(self):
+        from bb.COW import COWDictBase
+        c = COWDictBase.copy()
+        c['123'] = 1027
+        c['other'] = 4711
+        c['d'] = { 'abc' : 10, 'bcd' : 20 }
+
+        copy = c.copy()
+
+        self.assertEquals(1027, c['123'])
+        self.assertEquals(4711, c['other'])
+        self.assertEquals({'abc':10, 'bcd':20}, c['d'])
+        self.assertEquals(1027, copy['123'])
+        self.assertEquals(4711, copy['other'])
+        self.assertEquals({'abc':10, 'bcd':20}, copy['d'])
+
+        # cow it now
+        copy['123'] = 1028
+        copy['other'] = 4712
+        copy['d']['abc'] = 20
+
+
+        self.assertEquals(1027, c['123'])
+        self.assertEquals(4711, c['other'])
+        self.assertEquals({'abc':10, 'bcd':20}, c['d'])
+        self.assertEquals(1028, copy['123'])
+        self.assertEquals(4712, copy['other'])
+        self.assertEquals({'abc':20, 'bcd':20}, copy['d'])

bitbake/lib/bb/tests/data.py

@@ -0,0 +1,252 @@
+#
+# BitBake Tests for the Data Store (data.py/data_smart.py)
+#
+# Copyright (C) 2010 Chris Larson
+# Copyright (C) 2012 Richard Purdie
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License version 2 as
+# published by the Free Software Foundation.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License along
+# with this program; if not, write to the Free Software Foundation, Inc.,
+# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+#
+
+import unittest
+import bb
+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'"
+
+    def test_one_var(self):
+        val = self.d.expand("${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'")
+
+    def test_indirect_and_another(self):
+        val = self.d.expand("${${foo}} ${bar}")
+        self.assertEqual(str(val), "value of 'value of foo' value of bar")
+
+    def test_python_snippet(self):
+        val = self.d.expand("${@5*12}")
+        self.assertEqual(str(val), "60")
+
+    def test_expand_in_python_snippet(self):
+        val = self.d.expand("${@'boo ' + '${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")
+
+    def test_python_snippet_syntax_error(self):
+        self.d.setVar("FOO", "${@foo = 5}")
+        self.assertRaises(bb.data_smart.ExpansionError, self.d.getVar, "FOO", True)
+
+    def test_python_snippet_runtime_error(self):
+        self.d.setVar("FOO", "${@int('test')}")
+        self.assertRaises(bb.data_smart.ExpansionError, self.d.getVar, "FOO", True)
+
+    def test_python_snippet_error_path(self):
+        self.d.setVar("FOO", "foo value ${BAR}")
+        self.d.setVar("BAR", "bar value ${@int('test')}")
+        self.assertRaises(bb.data_smart.ExpansionError, self.d.getVar, "FOO", True)
+
+    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")
+
+    def test_reference_undefined_var(self):
+        val = self.d.expand("${undefinedvar} meh")
+        self.assertEqual(str(val), "${undefinedvar} meh")
+
+    def test_double_reference(self):
+        self.d.setVar("BAR", "bar value")
+        self.d.setVar("FOO", "${BAR} foo ${BAR}")
+        val = self.d.getVar("FOO", True)
+        self.assertEqual(str(val), "bar value foo bar value")
+
+    def test_direct_recursion(self):
+        self.d.setVar("FOO", "${FOO}")
+        self.assertRaises(bb.data_smart.ExpansionError, self.d.getVar, "FOO", True)
+
+    def test_indirect_recursion(self):
+        self.d.setVar("FOO", "${BAR}")
+        self.d.setVar("BAR", "${BAZ}")
+        self.d.setVar("BAZ", "${FOO}")
+        self.assertRaises(bb.data_smart.ExpansionError, self.d.getVar, "FOO", True)
+
+    def test_recursion_exception(self):
+        self.d.setVar("FOO", "${BAR}")
+        self.d.setVar("BAR", "${${@'FOO'}}")
+        self.assertRaises(bb.data_smart.ExpansionError, self.d.getVar, "FOO", True)
+
+    def test_incomplete_varexp_single_quotes(self):
+        self.d.setVar("FOO", "sed -i -e 's:IP{:I${:g' $pc")
+        val = self.d.getVar("FOO", True)
+        self.assertEqual(str(val), "sed -i -e 's:IP{:I${:g' $pc")
+
+    def test_nonstring(self):
+        self.d.setVar("TEST", 5)
+        val = self.d.getVar("TEST", True)
+        self.assertEqual(str(val), "5")
+
+    def test_rename(self):
+        self.d.renameVar("foo", "newfoo")
+        self.assertEqual(self.d.getVar("newfoo"), "value of foo")
+        self.assertEqual(self.d.getVar("foo"), None)
+
+    def test_deletion(self):
+        self.d.delVar("foo")
+        self.assertEqual(self.d.getVar("foo"), None)
+
+    def test_keys(self):
+        keys = self.d.keys()
+        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"
+
+    def test_refs(self):
+        val = self.d.expand("${value of ${foo}${bar}}")
+        self.assertEqual(str(val), "187")
+
+    #def test_python_refs(self):
+    #    val = self.d.expand("${@${@3}**2 + ${@4}**2}")
+    #    self.assertEqual(str(val), "25")
+
+    def test_ref_in_python_ref(self):
+        val = self.d.expand("${@'${foo}' + 'bar'}")
+        self.assertEqual(str(val), "foobar")
+
+    def test_python_ref_in_ref(self):
+        val = self.d.expand("${${@'f'+'o'+'o'}}")
+        self.assertEqual(str(val), "foo")
+
+    def test_deep_nesting(self):
+        depth = 100
+        val = self.d.expand("${" * depth + "foo" + "}" * depth)
+        self.assertEqual(str(val), "foo")
+
+    #def test_deep_python_nesting(self):
+    #    depth = 50
+    #    val = self.d.expand("${@" * depth + "1" + "+1}" * depth)
+    #    self.assertEqual(str(val), str(depth + 1))
+
+    def test_mixed(self):
+        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'}}")
+        self.assertEqual(str(val), "187")
+
+class TestMemoize(unittest.TestCase):
+    def test_memoized(self):
+        d = bb.data.init()
+        d.setVar("FOO", "bar")
+        self.assertTrue(d.getVar("FOO") is d.getVar("FOO"))
+
+    def test_not_memoized(self):
+        d1 = bb.data.init()
+        d2 = bb.data.init()
+        d1.setVar("FOO", "bar")
+        d2.setVar("FOO", "bar2")
+        self.assertTrue(d1.getVar("FOO") is not d2.getVar("FOO"))
+
+    def test_changed_after_memoized(self):
+        d = bb.data.init()
+        d.setVar("foo", "value of foo")
+        self.assertEqual(str(d.getVar("foo")), "value of foo")
+        d.setVar("foo", "second value of foo")
+        self.assertEqual(str(d.getVar("foo")), "second value of foo")
+
+    def test_same_value(self):
+        d = bb.data.init()
+        d.setVar("foo", "value of")
+        d.setVar("bar", "value of")
+        self.assertEqual(d.getVar("foo"),
+                         d.getVar("bar"))
+
+class TestConcat(unittest.TestCase):
+    def setUp(self):
+        self.d = bb.data.init()
+        self.d.setVar("FOO", "foo")
+        self.d.setVar("VAL", "val")
+        self.d.setVar("BAR", "bar")
+
+    def test_prepend(self):
+        self.d.setVar("TEST", "${VAL}")
+        self.d.prependVar("TEST", "${FOO}:")
+        self.assertEqual(self.d.getVar("TEST", True), "foo:val")
+
+    def test_append(self):
+        self.d.setVar("TEST", "${VAL}")
+        self.d.appendVar("TEST", ":${BAR}")
+        self.assertEqual(self.d.getVar("TEST", True), "val:bar")
+
+    def test_multiple_append(self):
+        self.d.setVar("TEST", "${VAL}")
+        self.d.prependVar("TEST", "${FOO}:")
+        self.d.appendVar("TEST", ":val2")
+        self.d.appendVar("TEST", ":${BAR}")
+        self.assertEqual(self.d.getVar("TEST", True), "foo:val:val2:bar")
+
+class TestOverrides(unittest.TestCase):
+    def setUp(self):
+        self.d = bb.data.init()
+        self.d.setVar("OVERRIDES", "foo:bar:local")
+        self.d.setVar("TEST", "testvalue")
+
+    def test_no_override(self):
+        bb.data.update_data(self.d)
+        self.assertEqual(self.d.getVar("TEST", True), "testvalue")
+
+    def test_one_override(self):
+        self.d.setVar("TEST_bar", "testvalue2")
+        bb.data.update_data(self.d)
+        self.assertEqual(self.d.getVar("TEST", True), "testvalue2")
+
+    def test_multiple_override(self):
+        self.d.setVar("TEST_bar", "testvalue2")
+        self.d.setVar("TEST_local", "testvalue3")
+        self.d.setVar("TEST_foo", "testvalue4")
+        bb.data.update_data(self.d)
+        self.assertEqual(self.d.getVar("TEST", True), "testvalue3")
+
+
+class TestFlags(unittest.TestCase):
+    def setUp(self):
+        self.d = bb.data.init()
+        self.d.setVar("foo", "value of foo")
+        self.d.setVarFlag("foo", "flag1", "value of flag1")
+        self.d.setVarFlag("foo", "flag2", "value of flag2")
+
+    def test_setflag(self):
+        self.assertEqual(self.d.getVarFlag("foo", "flag1"), "value of flag1")
+        self.assertEqual(self.d.getVarFlag("foo", "flag2"), "value of flag2")
+
+    def test_delflag(self):
+        self.d.delVarFlag("foo", "flag2")
+        self.assertEqual(self.d.getVarFlag("foo", "flag1"), "value of flag1")
+        self.assertEqual(self.d.getVarFlag("foo", "flag2"), None)
+
+

bitbake/lib/bb/tests/fetch.py

@@ -0,0 +1,191 @@
+#
+# BitBake Tests for the Fetcher (fetch2/)
+#
+# Copyright (C) 2012 Richard Purdie
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License version 2 as
+# published by the Free Software Foundation.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License along
+# with this program; if not, write to the Free Software Foundation, Inc.,
+# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+#
+
+import unittest
+import tempfile
+import subprocess
+import os
+import bb
+
+
+class FetcherTest(unittest.TestCase):
+
+    replaceuris = {
+        ("git://git.invalid.infradead.org/mtd-utils.git;tag=1234567890123456789012345678901234567890", "git://.*/.*", "http://somewhere.org/somedir/") 
+            : "http://somewhere.org/somedir/git2_git.invalid.infradead.org.mtd-utils.git.tar.gz",
+        ("git://git.invalid.infradead.org/mtd-utils.git;tag=1234567890123456789012345678901234567890", "git://.*/([^/]+/)*([^/]*)", "git://somewhere.org/somedir/\\2;protocol=http") 
+            : "git://somewhere.org/somedir/mtd-utils.git;tag=1234567890123456789012345678901234567890;protocol=http", 
+        ("git://git.invalid.infradead.org/foo/mtd-utils.git;tag=1234567890123456789012345678901234567890", "git://.*/([^/]+/)*([^/]*)", "git://somewhere.org/somedir/\\2;protocol=http") 
+            : "git://somewhere.org/somedir/mtd-utils.git;tag=1234567890123456789012345678901234567890;protocol=http", 
+        ("git://git.invalid.infradead.org/foo/mtd-utils.git;tag=1234567890123456789012345678901234567890", "git://.*/([^/]+/)*([^/]*)", "git://somewhere.org/\\2;protocol=http") 
+            : "git://somewhere.org/mtd-utils.git;tag=1234567890123456789012345678901234567890;protocol=http", 
+        ("git://someserver.org/bitbake;tag=1234567890123456789012345678901234567890", "git://someserver.org/bitbake", "git://git.openembedded.org/bitbake")
+            : "git://git.openembedded.org/bitbake;tag=1234567890123456789012345678901234567890",
+        ("file://sstate-xyz.tgz", "file://.*", "file:///somewhere/1234/sstate-cache") 
+            : "file:///somewhere/1234/sstate-cache/sstate-xyz.tgz",
+        ("file://sstate-xyz.tgz", "file://.*", "file:///somewhere/1234/sstate-cache/") 
+            : "file:///somewhere/1234/sstate-cache/sstate-xyz.tgz",
+        ("http://somewhere.org/somedir1/somedir2/somefile_1.2.3.tar.gz", "http://.*/.*", "http://somewhere2.org/somedir3") 
+            : "http://somewhere2.org/somedir3/somefile_1.2.3.tar.gz",
+        ("http://somewhere.org/somedir1/somefile_1.2.3.tar.gz", "http://somewhere.org/somedir1/somefile_1.2.3.tar.gz", "http://somewhere2.org/somedir3/somefile_1.2.3.tar.gz") 
+            : "http://somewhere2.org/somedir3/somefile_1.2.3.tar.gz",
+        ("http://www.apache.org/dist/subversion/subversion-1.7.1.tar.bz2", "http://www.apache.org/dist", "http://archive.apache.org/dist")
+            : "http://archive.apache.org/dist/subversion/subversion-1.7.1.tar.bz2",
+        ("http://www.apache.org/dist/subversion/subversion-1.7.1.tar.bz2", "http://.*/.*", "file:///somepath/downloads/")
+            : "file:///somepath/downloads/subversion-1.7.1.tar.bz2",
+        ("git://git.invalid.infradead.org/mtd-utils.git;tag=1234567890123456789012345678901234567890", "git://.*/.*", "git://somewhere.org/somedir/BASENAME;protocol=http") 
+            : "git://somewhere.org/somedir/mtd-utils.git;tag=1234567890123456789012345678901234567890;protocol=http", 
+        ("git://git.invalid.infradead.org/foo/mtd-utils.git;tag=1234567890123456789012345678901234567890", "git://.*/.*", "git://somewhere.org/somedir/BASENAME;protocol=http") 
+            : "git://somewhere.org/somedir/mtd-utils.git;tag=1234567890123456789012345678901234567890;protocol=http", 
+        ("git://git.invalid.infradead.org/foo/mtd-utils.git;tag=1234567890123456789012345678901234567890", "git://.*/.*", "git://somewhere.org/somedir/MIRRORNAME;protocol=http") 
+            : "git://somewhere.org/somedir/git.invalid.infradead.org.foo.mtd-utils.git;tag=1234567890123456789012345678901234567890;protocol=http", 
+
+        #Renaming files doesn't work
+        #("http://somewhere.org/somedir1/somefile_1.2.3.tar.gz", "http://somewhere.org/somedir1/somefile_1.2.3.tar.gz", "http://somewhere2.org/somedir3/somefile_2.3.4.tar.gz") : "http://somewhere2.org/somedir3/somefile_2.3.4.tar.gz"
+        #("file://sstate-xyz.tgz", "file://.*/.*", "file:///somewhere/1234/sstate-cache") : "file:///somewhere/1234/sstate-cache/sstate-xyz.tgz",
+    }
+
+    mirrorvar = "http://.*/.* file:///somepath/downloads/ \n" \
+                "git://someserver.org/bitbake git://git.openembedded.org/bitbake \n" \
+                "https://.*/.* file:///someotherpath/downloads/ \n" \
+                "http://.*/.* file:///someotherpath/downloads/ \n"
+
+    def setUp(self):
+        self.d = bb.data.init()
+        self.tempdir = tempfile.mkdtemp()
+        self.dldir = os.path.join(self.tempdir, "download")
+        os.mkdir(self.dldir)
+        self.d.setVar("DL_DIR", self.dldir)
+        self.unpackdir = os.path.join(self.tempdir, "unpacked")
+        os.mkdir(self.unpackdir)
+        persistdir = os.path.join(self.tempdir, "persistdata")
+        self.d.setVar("PERSISTENT_DIR", persistdir)
+
+    def tearDown(self):
+        bb.utils.prunedir(self.tempdir)
+
+    def test_fetch(self):
+        fetcher = bb.fetch.Fetch(["http://downloads.yoctoproject.org/releases/bitbake/bitbake-1.0.tar.gz", "http://downloads.yoctoproject.org/releases/bitbake/bitbake-1.1.tar.gz"], self.d)
+        fetcher.download()
+        self.assertEqual(os.path.getsize(self.dldir + "/bitbake-1.0.tar.gz"), 57749)
+        self.assertEqual(os.path.getsize(self.dldir + "/bitbake-1.1.tar.gz"), 57892)
+        self.d.setVar("BB_NO_NETWORK", "1")
+        fetcher = bb.fetch.Fetch(["http://downloads.yoctoproject.org/releases/bitbake/bitbake-1.0.tar.gz", "http://downloads.yoctoproject.org/releases/bitbake/bitbake-1.1.tar.gz"], self.d)
+        fetcher.download()
+        fetcher.unpack(self.unpackdir)
+        self.assertEqual(len(os.listdir(self.unpackdir + "/bitbake-1.0/")), 9)
+        self.assertEqual(len(os.listdir(self.unpackdir + "/bitbake-1.1/")), 9)
+
+    def test_fetch_mirror(self):
+        self.d.setVar("MIRRORS", "http://.*/.* http://downloads.yoctoproject.org/releases/bitbake")
+        fetcher = bb.fetch.Fetch(["http://invalid.yoctoproject.org/releases/bitbake/bitbake-1.0.tar.gz"], self.d)
+        fetcher.download()
+        self.assertEqual(os.path.getsize(self.dldir + "/bitbake-1.0.tar.gz"), 57749)
+
+    def test_fetch_premirror(self):
+        self.d.setVar("PREMIRRORS", "http://.*/.* http://downloads.yoctoproject.org/releases/bitbake")
+        fetcher = bb.fetch.Fetch(["http://invalid.yoctoproject.org/releases/bitbake/bitbake-1.0.tar.gz"], self.d)
+        fetcher.download()
+        self.assertEqual(os.path.getsize(self.dldir + "/bitbake-1.0.tar.gz"), 57749)
+
+    def gitfetcher(self, url1, url2):
+        def checkrevision(self, fetcher):
+            fetcher.unpack(self.unpackdir)
+            revision = subprocess.check_output("git rev-parse HEAD", shell=True, cwd=self.unpackdir + "/git").strip()
+            self.assertEqual(revision, "270a05b0b4ba0959fe0624d2a4885d7b70426da5")
+
+        self.d.setVar("BB_GENERATE_MIRROR_TARBALLS", "1")
+        self.d.setVar("SRCREV", "270a05b0b4ba0959fe0624d2a4885d7b70426da5")
+        fetcher = bb.fetch.Fetch([url1], self.d)
+        fetcher.download()
+        checkrevision(self, fetcher)
+        # Wipe out the dldir clone and the unpacked source, turn off the network and check mirror tarball works
+        bb.utils.prunedir(self.dldir + "/git2/")
+        bb.utils.prunedir(self.unpackdir)
+        self.d.setVar("BB_NO_NETWORK", "1")
+        fetcher = bb.fetch.Fetch([url2], self.d)
+        fetcher.download()
+        checkrevision(self, fetcher)
+
+    def test_gitfetch(self):
+        url1 = url2 = "git://git.openembedded.org/bitbake"
+        self.gitfetcher(url1, url2)
+
+    def test_gitfetch_premirror(self):
+        url1 = "git://git.openembedded.org/bitbake"
+        url2 = "git://someserver.org/bitbake"
+        self.d.setVar("PREMIRRORS", "git://someserver.org/bitbake git://git.openembedded.org/bitbake \n")
+        self.gitfetcher(url1, url2)
+
+    def test_gitfetch_premirror2(self):
+        url1 = url2 = "git://someserver.org/bitbake"
+        self.d.setVar("PREMIRRORS", "git://someserver.org/bitbake git://git.openembedded.org/bitbake \n")
+        self.gitfetcher(url1, url2)
+
+    def test_gitfetch_premirror3(self):
+        realurl = "git://git.openembedded.org/bitbake"
+        dummyurl = "git://someserver.org/bitbake"
+        self.sourcedir = self.unpackdir.replace("unpacked", "sourcemirror.git")
+        os.chdir(self.tempdir)
+        subprocess.check_output("git clone %s %s 2> /dev/null" % (realurl, self.sourcedir), shell=True)
+        self.d.setVar("PREMIRRORS", "%s git://%s;protocol=file \n" % (dummyurl, self.sourcedir))
+        self.gitfetcher(dummyurl, dummyurl)
+
+    def test_urireplace(self):
+        for k, v in self.replaceuris.items():
+            ud = bb.fetch.FetchData(k[0], self.d)
+            ud.setup_localpath(self.d)
+            mirrors = bb.fetch2.mirror_from_string("%s %s" % (k[1], k[2]))
+            newuris, uds = bb.fetch2.build_mirroruris(ud, mirrors, self.d)
+            self.assertEqual([v], newuris)
+
+    def test_urilist1(self):
+        fetcher = bb.fetch.FetchData("http://downloads.yoctoproject.org/releases/bitbake/bitbake-1.0.tar.gz", self.d)
+        mirrors = bb.fetch2.mirror_from_string(self.mirrorvar)
+        uris, uds = bb.fetch2.build_mirroruris(fetcher, mirrors, self.d)
+        self.assertEqual(uris, ['file:///somepath/downloads/bitbake-1.0.tar.gz', 'file:///someotherpath/downloads/bitbake-1.0.tar.gz'])
+
+    def test_urilist2(self):
+        # Catch https:// -> files:// bug
+        fetcher = bb.fetch.FetchData("https://downloads.yoctoproject.org/releases/bitbake/bitbake-1.0.tar.gz", self.d)
+        mirrors = bb.fetch2.mirror_from_string(self.mirrorvar)
+        uris, uds = bb.fetch2.build_mirroruris(fetcher, mirrors, self.d)
+        self.assertEqual(uris, ['file:///someotherpath/downloads/bitbake-1.0.tar.gz'])
+
+
+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'})
+    }
+
+    def test_decodeurl(self):
+        for k, v in self.datatable.items():
+            result = bb.fetch.decodeurl(k)
+            self.assertEqual(result, v)
+
+    def test_encodeurl(self):
+        for k, v in self.datatable.items():
+            result = bb.fetch.encodeurl(v)
+            self.assertEqual(result, k)
+
+
+

bitbake/lib/bb/tests/utils.py

@@ -0,0 +1,36 @@
+#
+# BitBake Tests for utils.py
+#
+# Copyright (C) 2012 Richard Purdie
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License version 2 as
+# published by the Free Software Foundation.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License along
+# with this program; if not, write to the Free Software Foundation, Inc.,
+# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+#
+
+import unittest
+import bb
+
+class VerCmpString(unittest.TestCase):
+
+    def test_vercmpstring(self):
+        result = bb.utils.vercmp_string('1', '2')
+        self.assertTrue(result < 0)
+        result = bb.utils.vercmp_string('2', '1')
+        self.assertTrue(result > 0)
+        result = bb.utils.vercmp_string('1', '1.0')
+        self.assertTrue(result < 0)
+        result = bb.utils.vercmp_string('1', '1.1')
+        self.assertTrue(result < 0)
+        result = bb.utils.vercmp_string('1.1', '1_p2')
+        self.assertTrue(result < 0)
+

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

@@ -23,11 +23,13 @@
 import gtk
 import pango
 import gobject
+import bb.process
 from bb.ui.crumbs.progressbar import HobProgressBar
-from bb.ui.crumbs.hobwidget import hic, HobNotebook, HobAltButton, HobWarpCellRendererText
+from bb.ui.crumbs.hobwidget import hic, HobNotebook, HobAltButton, HobWarpCellRendererText, HobButton
 from bb.ui.crumbs.runningbuild import RunningBuildTreeView
 from bb.ui.crumbs.runningbuild import BuildFailureTreeView
 from bb.ui.crumbs.hobpages import HobPage
+from bb.ui.crumbs.hobcolor import HobColors
 
 class BuildConfigurationTreeView(gtk.TreeView):
     def __init__ (self):
@@ -81,26 +83,25 @@ class BuildConfigurationTreeView(gtk.TreeView):
         # renew the tree model after get the configuration messages
         self.set_model(listmodel)
 
-    def show(self, src_config_info):
+    def show(self, src_config_info, src_params):
         vars = []
-        vars.append(self.set_vars("BB version:", src_config_info.bb_version))
-        vars.append(self.set_vars("Target arch:", src_config_info.target_arch))
-        vars.append(self.set_vars("Target OS:", src_config_info.target_os))
+        vars.append(self.set_vars("BB version:", src_params.bb_version))
+        vars.append(self.set_vars("Target arch:", src_params.target_arch))
+        vars.append(self.set_vars("Target OS:", src_params.target_os))
         vars.append(self.set_vars("Machine:", src_config_info.curr_mach))
         vars.append(self.set_vars("Distro:", src_config_info.curr_distro))
-        vars.append(self.set_vars("Distro version:", src_config_info.distro_version))
+        vars.append(self.set_vars("Distro version:", src_params.distro_version))
         vars.append(self.set_vars("SDK machine:", src_config_info.curr_sdk_machine))
-        vars.append(self.set_vars("Tune feature:", src_config_info.tune_pkgarch))
+        vars.append(self.set_vars("Tune features:", src_params.tune_pkgarch))
         vars.append(self.set_vars("Layers:", src_config_info.layers))
 
         for path in src_config_info.layers:
             import os, os.path
             if os.path.exists(path):
-                f = os.popen('cd %s; git branch 2>&1 | grep "^* " | tr -d "* "' % path)
-                if f:
-                    branch = f.readline().lstrip('\n').rstrip('\n')
+                branch = bb.process.run('cd %s; git branch | grep "^* " | tr -d "* "' % path)[0]
+                if branch:
+                    branch = branch.strip('\n')
                     vars.append(self.set_vars("Branch:", branch))
-                    f.close()
                 break
 
         self.set_config_model(vars)
@@ -144,7 +145,7 @@ class BuildDetailsPage (HobPage):
         self.scrolled_view_config = gtk.ScrolledWindow ()
         self.scrolled_view_config.set_policy(gtk.POLICY_NEVER, gtk.POLICY_ALWAYS)
         self.scrolled_view_config.add(self.config_tv)
-        self.notebook.append_page(self.scrolled_view_config, gtk.Label("Build configuration"))
+        self.notebook.append_page(self.scrolled_view_config, "Build configuration")
 
         self.failure_tv = BuildFailureTreeView()
         self.failure_model = self.builder.handler.build.model.failure_model()
@@ -152,14 +153,14 @@ class BuildDetailsPage (HobPage):
         self.scrolled_view_failure = gtk.ScrolledWindow ()
         self.scrolled_view_failure.set_policy(gtk.POLICY_NEVER, gtk.POLICY_ALWAYS)
         self.scrolled_view_failure.add(self.failure_tv)
-        self.notebook.append_page(self.scrolled_view_failure, gtk.Label("Issues"))
+        self.notebook.append_page(self.scrolled_view_failure, "Issues")
 
         self.build_tv = RunningBuildTreeView(readonly=True, hob=True)
         self.build_tv.set_model(self.builder.handler.build.model)
         self.scrolled_view_build = gtk.ScrolledWindow ()
         self.scrolled_view_build.set_policy(gtk.POLICY_NEVER, gtk.POLICY_ALWAYS)
         self.scrolled_view_build.add(self.build_tv)
-        self.notebook.append_page(self.scrolled_view_build, gtk.Label("Log"))
+        self.notebook.append_page(self.scrolled_view_build, "Log")
 
         self.builder.handler.build.model.connect_after("row-changed", self.scroll_to_present_row, self.scrolled_view_build.get_vadjustment(), self.build_tv)
 
@@ -198,6 +199,87 @@ class BuildDetailsPage (HobPage):
         for child in children:
             self.remove(child)
 
+    def update_failures_sum_display(self):
+        num = 0
+        it = self.failure_model.get_iter_first()
+        while it:
+            color = self.failure_model.get_value(it, self.builder.handler.build.model.COL_COLOR)
+            if color == HobColors.ERROR:
+                num += 1
+            it = self.failure_model.iter_next(it)
+
+        return num
+
+    def add_build_fail_top_bar(self, actions):
+        mainly_action = "Edit %s" % actions
+        if 'image' in actions:
+            next_action   = ""
+        else:
+            next_action   = "Create new image"
+
+        #set to issue page
+        self.notebook.set_page("Issues")
+
+        color = HobColors.ERROR
+        build_fail_top = gtk.EventBox()
+        build_fail_top.set_size_request(-1, 260)
+        build_fail_top.modify_bg(gtk.STATE_NORMAL, gtk.gdk.color_parse(color))
+
+        build_fail_tab = gtk.Table(7, 40, True)
+        build_fail_top.add(build_fail_tab)
+
+        icon = gtk.Image()
+        icon_pix_buffer = gtk.gdk.pixbuf_new_from_file(hic.ICON_INDI_ERROR_FILE)
+        icon.set_from_pixbuf(icon_pix_buffer)
+        build_fail_tab.attach(icon, 1, 4, 0, 3)
+
+        label = gtk.Label()
+        label.set_alignment(0.0, 0.5)
+        label.set_markup("<span size='x-large'>%s</span>" % self.title)
+        build_fail_tab.attach(label, 4, 20, 0, 3)
+
+        label = gtk.Label()
+        label.set_alignment(0.0, 0.5)
+        num_of_fails = self.update_failures_sum_display()
+        current_fail, recipe_task_status = self.task_status.get_text().split('\n')
+        label.set_markup(" %d tasks failed,  %s, %s" % (num_of_fails, current_fail, recipe_task_status))
+        build_fail_tab.attach(label, 4, 40, 2, 4)
+
+        # create button 'Edit packages'
+        action_button = HobButton(mainly_action)
+        action_button.set_size_request(-1, 49)
+        action_button.connect('clicked', self.failure_main_action_button_clicked_cb, mainly_action)
+        build_fail_tab.attach(action_button, 4, 16, 4, 6)
+
+        if next_action:
+            next_button = HobAltButton(next_action)
+            next_button.set_alignment(0.0, 0.5)
+            next_button.connect('clicked', self.failure_next_action_button_clicked_cb, next_action)
+            build_fail_tab.attach(next_button, 17, 24, 4, 5)
+
+        file_bug_button = HobAltButton('File a bug')
+        file_bug_button.set_alignment(0.0, 0.5)
+        file_bug_button.connect('clicked', self.failure_file_bug_activate_link_cb)
+        build_fail_tab.attach(file_bug_button, 17, 24, 4 + abs(next_action != ""), 6)
+
+        return build_fail_top
+
+    def show_fail_page(self, title, action_names):
+        self._remove_all_widget()
+        self.title = "Hob cannot build your %s" % title
+
+        self.build_fail_bar = self.add_build_fail_top_bar(action_names)
+        self.pack_start(self.build_fail_bar)
+        self.pack_start(self.group_align, expand=True, fill=True)
+
+        self.box_group_area.pack_start(self.vbox, expand=True, fill=True)
+
+        self.vbox.pack_start(self.notebook, expand=True, fill=True)
+
+        self.box_group_area.pack_end(self.button_box, expand=False, fill=False)
+        self.show_all()
+        self.back_button.hide()
+
     def show_page(self, step):
         self._remove_all_widget()
         if step == self.builder.PACKAGE_GENERATING or step == self.builder.FAST_IMAGE_GENERATING:
@@ -238,6 +320,7 @@ class BuildDetailsPage (HobPage):
         self.builder.stop_build()
 
     def hide_stop_button(self):
+        self.stop_button.set_sensitive(False)
         self.stop_button.hide()
 
     def scroll_to_present_row(self, model, path, iter, v_adj, treeview):
@@ -248,5 +331,20 @@ class BuildDetailsPage (HobPage):
                 if (v_adj.upper <= v_adj.page_size) or (v_adj.value == v_adj.upper - v_adj.page_size):
                     treeview.scroll_to_cell(path)
 
-    def show_configurations(self, configurations):
-        self.config_tv.show(configurations)
+    def show_configurations(self, configurations, params):
+        self.config_tv.show(configurations, params)
+
+    def failure_main_action_button_clicked_cb(self, button, action):
+        if "Edit recipes" in action:
+            self.builder.show_recipes()
+        elif "Edit packages" in action:
+            self.builder.show_packages()
+        elif "Edit image configuration" in action:
+            self.builder.show_configuration()
+
+    def failure_next_action_button_clicked_cb(self, button, action):
+        if "Create new image" in action:
+            self.builder.initiate_new_build_async()
+
+    def failure_file_bug_activate_link_cb(self, button):
+        button.child.emit('activate-link', "http://bugzilla.yoctoproject.org")

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

@@ -26,62 +26,127 @@ import copy
 import os
 import subprocess
 import shlex
+import re
 from bb.ui.crumbs.template import TemplateMgr
 from bb.ui.crumbs.imageconfigurationpage import ImageConfigurationPage
 from bb.ui.crumbs.recipeselectionpage import RecipeSelectionPage
 from bb.ui.crumbs.packageselectionpage import PackageSelectionPage
 from bb.ui.crumbs.builddetailspage import BuildDetailsPage
 from bb.ui.crumbs.imagedetailspage import ImageDetailsPage
-from bb.ui.crumbs.hobwidget import hwc, HobButton, HobAltButton
+from bb.ui.crumbs.hobwidget import hwc, HobButton, HobAltButton, hcc
 from bb.ui.crumbs.hig import CrumbsMessageDialog, ImageSelectionDialog, \
                              AdvancedSettingDialog, LayerSelectionDialog, \
                              DeployImageDialog
 from bb.ui.crumbs.persistenttooltip import PersistentTooltip
 import bb.ui.crumbs.utils
 
+hobVer = 20120530
+
 class Configuration:
     '''Represents the data structure of configuration.'''
 
-    def __init__(self, params):
-        # Settings
+    @classmethod
+    def parse_proxy_string(cls, proxy):
+        pattern = "^\s*((http|https|ftp|git|cvs)://)?((\S+):(\S+)@)?(\S+):(\d+)/?"
+        match = re.search(pattern, proxy)
+        if match:
+            return match.group(2), match.group(4), match.group(5), match.group(6), match.group(7)
+        else:
+            return None, None, None, "", ""
+
+    @classmethod
+    def make_host_string(cls, prot, user, passwd, host, default_prot=""):
+        if host == None or host == "":
+            return ""
+
+        passwd = passwd or ""
+
+        if user != None and user != "":
+            if prot == None or prot == "":
+                prot = default_prot
+            return prot + "://" + user + ":" + passwd + "@" + host
+        else:
+            if prot == None or prot == "":
+                return host
+            else:
+                return prot + "://" + host
+
+    @classmethod
+    def make_port_string(cls, port):
+        port = port or ""
+        return port
+
+    @classmethod
+    def make_proxy_string(cls, prot, user, passwd, host, port, default_prot=""):
+        if host == None or host == "" or port == None or port == "":
+            return ""
+
+        return Configuration.make_host_string(prot, user, passwd, host, default_prot) + ":" + Configuration.make_port_string(port)
+
+    def __init__(self):
         self.curr_mach = ""
-        self.curr_distro = params["distro"]
-        self.dldir = params["dldir"]
-        self.sstatedir = params["sstatedir"]
-        self.sstatemirror = params["sstatemirror"]
-        self.pmake = int(params["pmake"].split()[1])
-        self.bbthread = params["bbthread"]
-        self.curr_package_format = " ".join(params["pclass"].split("package_")).strip()
-        self.image_rootfs_size = params["image_rootfs_size"]
-        self.image_extra_size = params["image_extra_size"]
-        self.image_overhead_factor = params['image_overhead_factor']
-        self.incompat_license = params["incompat_license"]
-        self.curr_sdk_machine = params["sdk_machine"]
-        self.conf_version = params["conf_version"]
-        self.lconf_version = params["lconf_version"]
+        # settings
+        self.curr_distro = ""
+        self.dldir = self.sstatedir = self.sstatemirror = ""
+        self.pmake = self.bbthread = 0
+        self.curr_package_format = ""
+        self.image_rootfs_size = self.image_extra_size = 0
+        self.image_overhead_factor = 1
+        self.incompat_license = ""
+        self.curr_sdk_machine = ""
+        self.conf_version = self.lconf_version = ""
         self.extra_setting = {}
         self.toolchain_build = False
-        self.image_fstypes = params["image_fstypes"]
+        self.image_fstypes = ""
         # bblayers.conf
-        self.layers = params["layer"].split()
+        self.layers = []
         # image/recipes/packages
+        self.clear_selection()
+
+        self.user_selected_packages = []
+
+        self.default_task = "build"
+
+        # proxy settings
+        self.enable_proxy = None
+        self.same_proxy = False
+        self.proxies = {
+            "http"  : [None, None, None, "", ""],  # protocol : [prot, user, passwd, host, port]
+            "https" : [None, None, None, "", ""],
+            "ftp"   : [None, None, None, "", ""],
+            "git"   : [None, None, None, "", ""],
+            "cvs"   : [None, None, None, "", ""],
+        }
+
+    def clear_selection(self):
         self.selected_image = None
         self.selected_recipes = []
         self.selected_packages = []
 
-        self.user_selected_packages = []
+    def split_proxy(self, protocol, proxy):
+        entry = []
+        prot, user, passwd, host, port = Configuration.parse_proxy_string(proxy)
+        entry.append(prot)
+        entry.append(user)
+        entry.append(passwd)
+        entry.append(host)
+        entry.append(port)
+        self.proxies[protocol] = entry
 
-        # proxy settings
-        self.all_proxy = params["all_proxy"]
-        self.http_proxy = params["http_proxy"]
-        self.ftp_proxy = params["ftp_proxy"]
-        self.https_proxy = params["https_proxy"]
-        self.git_proxy_host = params["git_proxy_host"]
-        self.git_proxy_port = params["git_proxy_port"]
-        self.cvs_proxy_host = params["cvs_proxy_host"]
-        self.cvs_proxy_port = params["cvs_proxy_port"]
+    def combine_proxy(self, protocol):
+        entry = self.proxies[protocol]
+        return Configuration.make_proxy_string(entry[0], entry[1], entry[2], entry[3], entry[4], protocol)
+
+    def combine_host_only(self, protocol):
+        entry = self.proxies[protocol]
+        return Configuration.make_host_string(entry[0], entry[1], entry[2], entry[3], protocol)
+
+    def combine_port_only(self, protocol):
+        entry = self.proxies[protocol]
+        return Configuration.make_port_string(entry[4])
 
     def update(self, params):
+        # settings
         self.curr_distro = params["distro"]
         self.dldir = params["dldir"]
         self.sstatedir = params["sstatedir"]
@@ -97,14 +162,20 @@ class Configuration:
         self.conf_version = params["conf_version"]
         self.lconf_version = params["lconf_version"]
         self.image_fstypes = params["image_fstypes"]
-        self.tune_arch = params["tune_arch"]
-        self.bb_version = params["bb_version"]
-        self.target_arch = params["target_arch"]
-        self.target_os = params["target_os"]
-        self.distro_version = params["distro_version"]
-        self.tune_pkgarch = params["tune_pkgarch"]
+        # self.extra_setting/self.toolchain_build
         # bblayers.conf
         self.layers = params["layer"].split()
+        self.default_task = params["default_task"]
+
+        # proxy settings
+        self.enable_proxy = params["http_proxy"] != "" or params["https_proxy"] != "" or params["ftp_proxy"] != "" \
+            or params["git_proxy_host"] != "" or params["git_proxy_port"] != ""                                    \
+            or params["cvs_proxy_host"] != "" or params["cvs_proxy_port"] != ""
+        self.split_proxy("http", params["http_proxy"])
+        self.split_proxy("https", params["https_proxy"])
+        self.split_proxy("ftp", params["ftp_proxy"])
+        self.split_proxy("git", params["git_proxy_host"] + ":" + params["git_proxy_port"])
+        self.split_proxy("cvs", params["cvs_proxy_host"] + ":" + params["cvs_proxy_port"])
 
     def load(self, template):
         self.curr_mach = template.getVar("MACHINE")
@@ -144,20 +215,21 @@ class Configuration:
         self.selected_recipes = template.getVar("DEPENDS").split()
         self.selected_packages = template.getVar("IMAGE_INSTALL").split()
         # proxy
-        self.all_proxy = template.getVar("all_proxy")
-        self.http_proxy = template.getVar("http_proxy")
-        self.ftp_proxy = template.getVar("ftp_proxy")
-        self.https_proxy = template.getVar("https_proxy")
-        self.git_proxy_host = template.getVar("GIT_PROXY_HOST")
-        self.git_proxy_port = template.getVar("GIT_PROXY_PORT")
-        self.cvs_proxy_host = template.getVar("CVS_PROXY_HOST")
-        self.cvs_proxy_port = template.getVar("CVS_PROXY_PORT")
+        self.enable_proxy = eval(template.getVar("enable_proxy"))
+        self.same_proxy = eval(template.getVar("use_same_proxy"))
+        self.split_proxy("http", template.getVar("http_proxy"))
+        self.split_proxy("https", template.getVar("https_proxy"))
+        self.split_proxy("ftp", template.getVar("ftp_proxy"))
+        self.split_proxy("git", template.getVar("GIT_PROXY_HOST") + ":" + template.getVar("GIT_PROXY_PORT"))
+        self.split_proxy("cvs", template.getVar("CVS_PROXY_HOST") + ":" + template.getVar("CVS_PROXY_PORT"))
 
-    def save(self, template, filename):
+    def save(self, template, defaults=False):
+        template.setVar("VERSION", "%s" % hobVer)
         # bblayers.conf
         template.setVar("BBLAYERS", " ".join(self.layers))
         # local.conf
-        template.setVar("MACHINE", self.curr_mach)
+        if not defaults:
+            template.setVar("MACHINE", self.curr_mach)
         template.setVar("DISTRO", self.curr_distro)
         template.setVar("DL_DIR", self.dldir)
         template.setVar("SSTATE_DIR", self.sstatedir)
@@ -174,41 +246,94 @@ class Configuration:
         template.setVar("EXTRA_SETTING", self.extra_setting)
         template.setVar("TOOLCHAIN_BUILD", self.toolchain_build)
         template.setVar("IMAGE_FSTYPES", self.image_fstypes)
-        # image/recipes/packages
-        self.selected_image = filename
-        template.setVar("__SELECTED_IMAGE__", self.selected_image)
-        template.setVar("DEPENDS", self.selected_recipes)
-        template.setVar("IMAGE_INSTALL", self.user_selected_packages)
+        if not defaults:
+            # image/recipes/packages
+            template.setVar("__SELECTED_IMAGE__", self.selected_image)
+            template.setVar("DEPENDS", self.selected_recipes)
+            template.setVar("IMAGE_INSTALL", self.user_selected_packages)
         # proxy
-        template.setVar("all_proxy", self.all_proxy)
-        template.setVar("http_proxy", self.http_proxy)
-        template.setVar("ftp_proxy", self.ftp_proxy)
-        template.setVar("https_proxy", self.https_proxy)
-        template.setVar("GIT_PROXY_HOST", self.git_proxy_host)
-        template.setVar("GIT_PROXY_PORT", self.git_proxy_port)
-        template.setVar("CVS_PROXY_HOST", self.cvs_proxy_host)
-        template.setVar("CVS_PROXY_PORT", self.cvs_proxy_port)
+        template.setVar("enable_proxy", self.enable_proxy)
+        template.setVar("use_same_proxy", self.same_proxy)
+        template.setVar("http_proxy", self.combine_proxy("http"))
+        template.setVar("https_proxy", self.combine_proxy("https"))
+        template.setVar("ftp_proxy", self.combine_proxy("ftp"))
+        template.setVar("GIT_PROXY_HOST", self.combine_host_only("git"))
+        template.setVar("GIT_PROXY_PORT", self.combine_port_only("git"))
+        template.setVar("CVS_PROXY_HOST", self.combine_host_only("cvs"))
+        template.setVar("CVS_PROXY_PORT", self.combine_port_only("cvs"))
 
 class Parameters:
     '''Represents other variables like available machines, etc.'''
 
-    def __init__(self, params):
+    def __init__(self):
         # Variables
+        self.max_threads = 65535
+        self.core_base = ""
+        self.image_addr = ""
+        self.image_types = []
+        self.runnable_image_types = []
+        self.runnable_machine_patterns = []
+        self.deployable_image_types = []
+        self.tmpdir = ""
+
         self.all_machines = []
         self.all_package_formats = []
         self.all_distros = []
         self.all_sdk_machines = []
-        self.max_threads = params["max_threads"]
         self.all_layers = []
-        self.core_base = params["core_base"]
         self.image_names = []
+        self.image_white_pattern = ""
+        self.image_black_pattern = ""
+
+        # for build log to show
+        self.bb_version = ""
+        self.target_arch = ""
+        self.target_os = ""
+        self.distro_version = ""
+        self.tune_pkgarch = ""
+
+    def update(self, params):
+        self.max_threads = params["max_threads"]
+        self.core_base = params["core_base"]
         self.image_addr = params["image_addr"]
         self.image_types = params["image_types"].split()
         self.runnable_image_types = params["runnable_image_types"].split()
         self.runnable_machine_patterns = params["runnable_machine_patterns"].split()
         self.deployable_image_types = params["deployable_image_types"].split()
         self.tmpdir = params["tmpdir"]
-        self.enable_proxy = False
+        self.image_white_pattern = params["image_white_pattern"]
+        self.image_black_pattern = params["image_black_pattern"]
+        self.kernel_image_type = params["kernel_image_type"]
+        # for build log to show
+        self.bb_version = params["bb_version"]
+        self.target_arch = params["target_arch"]
+        self.target_os = params["target_os"]
+        self.distro_version = params["distro_version"]
+        self.tune_pkgarch = params["tune_pkgarch"]
+
+def hob_conf_filter(fn, data):
+    if fn.endswith("/local.conf"):
+        distro = data.getVar("DISTRO_HOB")
+        if distro:
+            if distro != "defaultsetup":
+                data.setVar("DISTRO", distro)
+            else:
+                data.delVar("DISTRO")
+
+        keys = ["MACHINE_HOB", "SDKMACHINE_HOB", "PACKAGE_CLASSES_HOB", \
+                "BB_NUMBER_THREADS_HOB", "PARALLEL_MAKE_HOB", "DL_DIR_HOB", \
+                "SSTATE_DIR_HOB", "SSTATE_MIRROR_HOB", "INCOMPATIBLE_LICENSE_HOB"]
+        for key in keys:
+            var_hob = data.getVar(key)
+            if var_hob:
+                data.setVar(key.split("_HOB")[0], var_hob)
+        return
+
+    if fn.endswith("/bblayers.conf"):
+        layers = data.getVar("BBLAYERS_HOB")
+        if layers:
+            data.setVar("BBLAYERS", layers)
+        return
 
 class Builder(gtk.Window):
 
@@ -250,6 +375,15 @@ class Builder(gtk.Window):
         END_NOOP              : None,
     }
 
+    @classmethod
+    def interpret_markup(cls, msg):
+        msg = msg.replace('&', '&')
+        msg = msg.replace('<', '&lt;')
+        msg = msg.replace('>', '&gt;')
+        msg = msg.replace('"', '&quot;')
+        msg = msg.replace("'", "&acute;")
+        return msg
+
     def __init__(self, hobHandler, recipe_model, package_model):
         super(Builder, self).__init__()
 
@@ -261,6 +395,10 @@ class Builder(gtk.Window):
 
         self.template = None
 
+        # configuration and parameters
+        self.configuration = Configuration()
+        self.parameters = Parameters()
+
         # build step
         self.current_step = None
         self.previous_step = None
@@ -274,6 +412,9 @@ class Builder(gtk.Window):
         # Indicate whether user has customized the image
         self.customized = False
 
+        # Indicate whether the UI is working
+        self.sensitive = True
+
         # create visual elements
         self.create_visual_elements()
 
@@ -291,10 +432,16 @@ class Builder(gtk.Window):
         self.handler.build.connect("build-failed",       self.handler_build_failed_cb)
         self.handler.build.connect("task-started",       self.handler_task_started_cb)
         self.handler.build.connect("log-error",          self.handler_build_failure_cb)
+        self.handler.build.connect("no-provider",        self.handler_no_provider_cb)
         self.handler.connect("generating-data",          self.handler_generating_data_cb)
         self.handler.connect("data-generated",           self.handler_data_generated_cb)
         self.handler.connect("command-succeeded",        self.handler_command_succeeded_cb)
         self.handler.connect("command-failed",           self.handler_command_failed_cb)
+        self.handler.connect("sanity-failed",            self.handler_sanity_failed_cb)
+        self.handler.connect("recipe-populated",         self.handler_recipe_populated_cb)
+        self.handler.connect("package-populated",        self.handler_package_populated_cb)
+
+        self.handler.set_config_filter(hob_conf_filter)
 
         self.initiate_new_build_async()
 
@@ -334,14 +481,18 @@ class Builder(gtk.Window):
 
     def initiate_new_build_async(self):
         self.switch_page(self.MACHINE_SELECTION)
-        self.handler.init_cooker()
-        self.handler.set_extra_inherit("image_types")
-        self.handler.parse_config()
+        if self.load_template(TemplateMgr.convert_to_template_pathfilename("default", ".hob/")) == False:
+            self.handler.init_cooker()
+            self.handler.set_extra_inherit("image_types")
+            self.handler.generate_configuration()
 
     def update_config_async(self):
         self.switch_page(self.MACHINE_SELECTION)
         self.set_user_config()
-        self.handler.parse_generate_configuration()
+        self.handler.generate_configuration()
+
+    def sanity_check(self):
+        self.handler.trigger_sanity_check()
 
     def populate_recipe_package_info_async(self):
         self.switch_page(self.RCPPKGINFO_POPULATING)
@@ -355,7 +506,7 @@ class Builder(gtk.Window):
         _, all_recipes = self.recipe_model.get_selected_recipes()
         self.set_user_config()
         self.handler.reset_build()
-        self.handler.generate_packages(all_recipes)
+        self.handler.generate_packages(all_recipes, self.configuration.default_task)
 
     def fast_generate_image_async(self):
         self.switch_page(self.FAST_IMAGE_GENERATING)
@@ -363,21 +514,27 @@ class Builder(gtk.Window):
         _, all_recipes = self.recipe_model.get_selected_recipes()
         self.set_user_config()
         self.handler.reset_build()
-        self.handler.generate_packages(all_recipes)
+        self.handler.generate_packages(all_recipes, self.configuration.default_task)
 
     def generate_image_async(self):
         self.switch_page(self.IMAGE_GENERATING)
+        self.handler.reset_build()
         # Build image
         self.set_user_config()
-        packages = self.package_model.get_selected_packages()
         toolchain_packages = []
         if self.configuration.toolchain_build:
             toolchain_packages = self.package_model.get_selected_packages_toolchain()
-        self.handler.reset_build()
-        self.handler.generate_image(packages,
-                                    self.hob_image,
+        if self.configuration.selected_image == self.recipe_model.__custom_image__:
+            packages = self.package_model.get_selected_packages()
+            image = self.hob_image
+        else:
+            packages = []
+            image = self.configuration.selected_image
+        self.handler.generate_image(image,
                                     self.hob_toolchain,
-                                    toolchain_packages)
+                                    packages,
+                                    toolchain_packages,
+                                    self.configuration.default_task)
 
     def get_parameters_sync(self):
         return self.handler.get_parameters()
@@ -388,27 +545,40 @@ class Builder(gtk.Window):
     def cancel_build_sync(self, force=False):
         self.handler.cancel_build(force)
 
-    def generate_configuration_async(self):
-        self.handler.generate_configuration()
-
     def cancel_parse_sync(self):
         self.handler.cancel_parse()
 
     def load_template(self, path):
+        if not os.path.isfile(path):
+            return False
+
         self.template = TemplateMgr()
-        self.template.load(path)
-        self.configuration.load(self.template)
+        # check compatibility
+        tempVer = self.template.getVersion(path)
+        if not tempVer or int(tempVer) < hobVer:
+            self.template.destroy()
+            self.template = None
+            return False
+
+        try:
+            self.template.load(path)
+            self.configuration.load(self.template)
+        except Exception as e:
+            self.show_error_dialog("Hob Exception - %s" % (str(e)))
+            self.reset()
+        finally:
+            self.template.destroy()
+            self.template = None
 
         for layer in self.configuration.layers:
             if not os.path.exists(layer+'/conf/layer.conf'):
                 return False
 
+        self.save_defaults() # remember layers and settings
         self.update_config_async()
+        return True
 
-        self.template.destroy()
-        self.template = None
-
-    def save_template(self, path):
+    def save_template(self, path, defaults=False):
         if path.rfind("/") == -1:
             filename = "default"
             path = "."
@@ -417,12 +587,22 @@ class Builder(gtk.Window):
             path = path[0:path.rfind("/")]
 
         self.template = TemplateMgr()
-        self.template.open(filename, path)
-        self.configuration.save(self.template, filename)
+        try:
+            self.template.open(filename, path)
+            self.configuration.save(self.template, defaults)
 
-        self.template.save()
-        self.template.destroy()
-        self.template = None
+            self.template.save()
+        except Exception as e:
+            self.show_error_dialog("Hob Exception - %s" % (str(e)))
+            self.reset()
+        finally:
+            self.template.destroy()
+            self.template = None
+
+    def save_defaults(self):
+        if not os.path.exists(".hob/"):
+            os.mkdir(".hob/")
+        self.save_template(".hob/default", True)
 
     def switch_page(self, next_step):
         # Main Workflow (Business Logic)
@@ -491,13 +671,18 @@ class Builder(gtk.Window):
         self.handler.set_extra_inherit("packageinfo")
         self.handler.set_extra_inherit("image_types")
         # set proxies
-        if self.parameters.enable_proxy:
-            self.handler.set_http_proxy(self.configuration.http_proxy)
-            self.handler.set_https_proxy(self.configuration.https_proxy)
-            self.handler.set_ftp_proxy(self.configuration.ftp_proxy)
-            self.handler.set_all_proxy(self.configuration.all_proxy)
-            self.handler.set_git_proxy(self.configuration.git_proxy_host, self.configuration.git_proxy_port)
-            self.handler.set_cvs_proxy(self.configuration.cvs_proxy_host, self.configuration.cvs_proxy_port)
+        if self.configuration.enable_proxy == True:
+            self.handler.set_http_proxy(self.configuration.combine_proxy("http"))
+            self.handler.set_https_proxy(self.configuration.combine_proxy("https"))
+            self.handler.set_ftp_proxy(self.configuration.combine_proxy("ftp"))
+            self.handler.set_git_proxy(self.configuration.combine_host_only("git"), self.configuration.combine_port_only("git"))
+            self.handler.set_cvs_proxy(self.configuration.combine_host_only("cvs"), self.configuration.combine_port_only("cvs"))
+        elif self.configuration.enable_proxy == False:
+            self.handler.set_http_proxy("")
+            self.handler.set_https_proxy("")
+            self.handler.set_ftp_proxy("")
+            self.handler.set_git_proxy("", "")
+            self.handler.set_cvs_proxy("", "")
 
     def update_recipe_model(self, selected_image, selected_recipes):
         self.recipe_model.set_selected_image(selected_image)
@@ -507,6 +692,17 @@ class Builder(gtk.Window):
         left = self.package_model.set_selected_packages(selected_packages)
         self.configuration.selected_packages += left
 
+    def update_configuration_parameters(self, params):
+        if params:
+            self.configuration.update(params)
+            self.parameters.update(params)
+
+    def reset(self):
+        self.configuration.curr_mach = ""
+        self.configuration.clear_selection()
+        self.image_configuration_page.switch_machine_combo()
+        self.switch_page(self.MACHINE_SELECTION)
+
     # Callback Functions
     def handler_config_updated_cb(self, handler, which, values):
         if which == "distro":
@@ -521,21 +717,15 @@ class Builder(gtk.Window):
         self.parameters.all_package_formats = formats
 
     def handler_command_succeeded_cb(self, handler, initcmd):
-        if initcmd == self.handler.PARSE_CONFIG:
-            # settings
-            params = self.get_parameters_sync()
-            self.configuration = Configuration(params)
-            self.parameters = Parameters(params)
-            self.generate_configuration_async()
-        elif initcmd == self.handler.GENERATE_CONFIGURATION:
-            params = self.get_parameters_sync()
-            self.configuration.update(params)
+        if initcmd == self.handler.GENERATE_CONFIGURATION:
+            self.update_configuration_parameters(self.get_parameters_sync())
+            self.sanity_check()
+        elif initcmd == self.handler.SANITY_CHECK:
             self.image_configuration_page.switch_machine_combo()
         elif initcmd in [self.handler.GENERATE_RECIPES,
                          self.handler.GENERATE_PACKAGES,
                          self.handler.GENERATE_IMAGE]:
-            params = self.get_parameters_sync()
-            self.configuration.update(params)
+            self.update_configuration_parameters(self.get_parameters_sync())
             self.request_package_info_async()
         elif initcmd == self.handler.POPULATE_PACKAGEINFO:
             if self.current_step == self.RCPPKGINFO_POPULATING:
@@ -546,28 +736,31 @@ class Builder(gtk.Window):
             self.rcppkglist_populated()
             if self.current_step == self.FAST_IMAGE_GENERATING:
                 self.generate_image_async()
-            elif self.current_step == self.PACKAGE_GENERATING:
-                self.switch_page(self.PACKAGE_GENERATED)
-            elif self.current_step == self.IMAGE_GENERATING:
-                self.switch_page(self.IMAGE_GENERATED)
+
+    def show_error_dialog(self, msg):
+        lbl = "<b>Error</b>\n"
+        lbl = lbl + "%s\n\n" % Builder.interpret_markup(msg)
+        dialog = CrumbsMessageDialog(self, lbl, gtk.STOCK_DIALOG_ERROR)
+        button = dialog.add_button("Close", gtk.RESPONSE_OK)
+        HobButton.style_button(button)
+        response = dialog.run()
+        dialog.destroy()
 
     def handler_command_failed_cb(self, handler, msg):
         if msg:
-            msg = msg.replace("your local.conf", "Settings")
-            lbl = "<b>Error</b>\n"
-            lbl = lbl + "%s\n\n" % msg
-            dialog = CrumbsMessageDialog(self, lbl, gtk.STOCK_DIALOG_ERROR)
-            button = dialog.add_button("Close", gtk.RESPONSE_OK)
-            HobButton.style_button(button)
-            response = dialog.run()
-            dialog.destroy()
-        self.configuration.curr_mach = ""
-        self.image_configuration_page.switch_machine_combo()
-        self.switch_page(self.MACHINE_SELECTION)
+            self.show_error_dialog(msg)
+        self.reset()
+
+    def handler_sanity_failed_cb(self, handler, msg):
+        msg = msg.replace("your local.conf", "Settings")
+        self.show_error_dialog(msg)
+        self.reset()
 
     def window_sensitive(self, sensitive):
         self.image_configuration_page.machine_combo.set_sensitive(sensitive)
+        self.image_configuration_page.machine_combo.child.set_sensitive(sensitive)
         self.image_configuration_page.image_combo.set_sensitive(sensitive)
+        self.image_configuration_page.image_combo.child.set_sensitive(sensitive)
         self.image_configuration_page.layer_button.set_sensitive(sensitive)
         self.image_configuration_page.layer_info_icon.set_sensitive(sensitive)
         self.image_configuration_page.toolbar.set_sensitive(sensitive)
@@ -584,6 +777,7 @@ class Builder(gtk.Window):
             self.get_root_window().set_cursor(gtk.gdk.Cursor(gtk.gdk.LEFT_PTR))
         else:
             self.get_root_window().set_cursor(gtk.gdk.Cursor(gtk.gdk.WATCH))
+        self.sensitive = sensitive
 
 
     def handler_generating_data_cb(self, handler):
@@ -597,12 +791,8 @@ class Builder(gtk.Window):
         selected_recipes = self.configuration.selected_recipes[:]
         selected_packages = self.configuration.selected_packages[:]
 
-        self.recipe_model.image_list_append(selected_image,
-                                            " ".join(selected_recipes),
-                                            " ".join(selected_packages))
-
         self.image_configuration_page.update_image_combo(self.recipe_model, selected_image)
-        self.image_configuration_page.update_image_desc(selected_image)
+        self.image_configuration_page.update_image_desc()
         self.update_recipe_model(selected_image, selected_recipes)
         self.update_package_model(selected_packages)
 
@@ -612,6 +802,12 @@ class Builder(gtk.Window):
     def packagelist_changed_cb(self, package_model):
         self.package_details_page.refresh_selection()
 
+    def handler_recipe_populated_cb(self, handler):
+        self.image_configuration_page.update_progress_bar("Populated recipes", 0.99)
+
+    def handler_package_populated_cb(self, handler):
+        self.image_configuration_page.update_progress_bar("Populated packages", 1.0)
+
     def handler_parsing_started_cb(self, handler, message):
         if self.current_step != self.RCPPKGINFO_POPULATING:
             return
@@ -631,7 +827,7 @@ class Builder(gtk.Window):
 
         fraction = message["current"] * 1.0/message["total"]
         if message["eventname"] == "TreeDataPreparationProgress":
-            fraction = 0.6 + 0.4 * fraction
+            fraction = 0.6 + 0.38 * fraction
         else:
             fraction = 0.6 * fraction
         self.image_configuration_page.update_progress_bar(message["title"], fraction)
@@ -641,7 +837,7 @@ class Builder(gtk.Window):
             return
 
         if message["eventname"] == "TreeDataPreparationCompleted":
-            fraction = 1.0
+            fraction = 0.98
         else:
             fraction = 0.6
         self.image_configuration_page.update_progress_bar(message["title"], fraction)
@@ -657,7 +853,7 @@ class Builder(gtk.Window):
         elif self.current_step == self.PACKAGE_GENERATING:
             fraction = 0
         self.build_details_page.update_progress_bar("Build Started: ", fraction)
-        self.build_details_page.show_configurations(self.configuration)
+        self.build_details_page.show_configurations(self.configuration, self.parameters)
 
     def build_succeeded(self):
         if self.current_step == self.FAST_IMAGE_GENERATING:
@@ -665,29 +861,47 @@ class Builder(gtk.Window):
         elif self.current_step == self.IMAGE_GENERATING:
             fraction = 1.0
             self.parameters.image_names = []
-            linkname = 'hob-image-' + self.configuration.curr_mach
+            selected_image = self.recipe_model.get_selected_image()
+            if selected_image == self.recipe_model.__custom_image__:
+                linkname = 'hob-image-' + self.configuration.curr_mach
+            else:
+                linkname = selected_image + '-' + self.configuration.curr_mach
             for image_type in self.parameters.image_types:
-                linkpath = self.parameters.image_addr + '/' + linkname + '.' + image_type
-                if os.path.exists(linkpath):
-                    self.parameters.image_names.append(os.readlink(linkpath))
+                for real_image_type in hcc.SUPPORTED_IMAGE_TYPES[image_type]:
+                    linkpath = self.parameters.image_addr + '/' + linkname + '.' + real_image_type
+                    if os.path.exists(linkpath):
+                        self.parameters.image_names.append(os.readlink(linkpath))
         elif self.current_step == self.PACKAGE_GENERATING:
             fraction = 1.0
         self.build_details_page.update_progress_bar("Build Completed: ", fraction)
         self.handler.build_succeeded_async()
         self.stopping = False
 
+        if self.current_step == self.PACKAGE_GENERATING:
+            self.switch_page(self.PACKAGE_GENERATED)
+        elif self.current_step == self.IMAGE_GENERATING:
+            self.switch_page(self.IMAGE_GENERATED)
+
     def build_failed(self):
         if self.stopping:
             status = "stop"
             message = "Build stopped: "
             fraction = self.build_details_page.progress_bar.get_fraction()
         else:
+            fail_to_next_edit = ""
             if self.current_step == self.FAST_IMAGE_GENERATING:
+                fail_to_next_edit = "image configuration"
                 fraction = 0.9
             elif self.current_step == self.IMAGE_GENERATING:
+                if self.previous_step == self.FAST_IMAGE_GENERATING:
+                    fail_to_next_edit = "image configuration"
+                else:
+                    fail_to_next_edit = "packages"
                 fraction = 1.0
             elif self.current_step == self.PACKAGE_GENERATING:
+                fail_to_next_edit = "recipes"
                 fraction = 1.0
+            self.build_details_page.show_fail_page(fail_to_next_edit.split(' ')[0], fail_to_next_edit)
             status = "fail"
             message = "Build failed: "
         self.build_details_page.update_progress_bar(message, fraction, status)
@@ -706,6 +920,14 @@ class Builder(gtk.Window):
     def handler_build_failed_cb(self, running_build):
         self.build_failed()
 
+    def handler_no_provider_cb(self, running_build, msg):
+        dialog = CrumbsMessageDialog(self, Builder.interpret_markup(msg), gtk.STOCK_DIALOG_INFO)
+        button = dialog.add_button("Close", gtk.RESPONSE_OK)
+        HobButton.style_button(button)
+        dialog.run()
+        dialog.destroy()
+        self.build_failed()
+
     def handler_task_started_cb(self, running_build, message): 
         fraction = message["current"] * 1.0/message["total"]
         title = "Build packages"
@@ -738,6 +960,8 @@ class Builder(gtk.Window):
         self.build_details_page.show_issues()
 
     def destroy_window_cb(self, widget, event):
+        if not self.sensitive:
+            return True
         lbl = "<b>Do you really want to exit the Hob image creator?</b>"
         dialog = CrumbsMessageDialog(self, lbl, gtk.STOCK_DIALOG_INFO)
         button = dialog.add_button("Cancel", gtk.RESPONSE_NO)
@@ -784,7 +1008,7 @@ class Builder(gtk.Window):
         selected_packages = self.package_model.get_selected_packages() or []
 
         # If no base image and no selected packages don't build anything
-        if not (selected_packages or selected_image != self.recipe_model.__dummy_image__):
+        if not (selected_packages or selected_image != self.recipe_model.__custom_image__):
             lbl = "<b>No selections made</b>\nYou have not made any selections"
             lbl = lbl + " so there isn't anything to bake at this time."
             dialog = CrumbsMessageDialog(self, lbl, gtk.STOCK_DIALOG_INFO)
@@ -798,7 +1022,7 @@ class Builder(gtk.Window):
 
     def show_binb_dialog(self, binb):
         markup = "<b>Brought in by:</b>\n%s" % binb
-        ptip = PersistentTooltip(markup)
+        ptip = PersistentTooltip(markup, self)
 
         ptip.show()
 
@@ -817,6 +1041,7 @@ class Builder(gtk.Window):
         response = dialog.run()
         if response == gtk.RESPONSE_YES:
             self.configuration.layers = dialog.layers
+            self.save_defaults() # remember layers
             # DO refresh layers
             if dialog.layers_changed:
                 self.update_config_async()
@@ -889,7 +1114,6 @@ class Builder(gtk.Window):
             all_distros = self.parameters.all_distros,
             all_sdk_machines = self.parameters.all_sdk_machines,
             max_threads = self.parameters.max_threads,
-            enable_proxy = self.parameters.enable_proxy,
             parent = self,
             flags = gtk.DIALOG_MODAL
                     | gtk.DIALOG_DESTROY_WITH_PARENT
@@ -901,17 +1125,18 @@ class Builder(gtk.Window):
         response = dialog.run()
         settings_changed = False
         if response == gtk.RESPONSE_YES:
-            self.parameters.enable_proxy = dialog.enable_proxy
             self.configuration = dialog.configuration
+            self.save_defaults() # remember settings
             settings_changed = dialog.settings_changed
         dialog.destroy()
         return response == gtk.RESPONSE_YES, settings_changed
 
     def reparse_post_adv_settings(self):
-        # DO reparse recipes
         if not self.configuration.curr_mach:
             self.update_config_async()
         else:
+            self.configuration.clear_selection()
+            # DO reparse recipes
             self.populate_recipe_package_info_async()
 
     def deploy_image(self, image_name):
@@ -938,16 +1163,7 @@ class Builder(gtk.Window):
         response = dialog.run()
         dialog.destroy()
 
-    def runqemu_image(self, image_name):
-        if not image_name:
-            lbl = "<b>Please select an image to launch in QEMU.</b>"
-            dialog = CrumbsMessageDialog(self, lbl, gtk.STOCK_DIALOG_INFO)
-            button = dialog.add_button("Close", gtk.RESPONSE_OK)
-            HobButton.style_button(button)
-            dialog.run()
-            dialog.destroy()
-            return
-
+    def show_load_kernel_dialog(self):
         dialog = gtk.FileChooserDialog("Load Kernel Files", self,
                                        gtk.FILE_CHOOSER_ACTION_SAVE)
         button = dialog.add_button("Cancel", gtk.RESPONSE_NO)
@@ -962,35 +1178,50 @@ class Builder(gtk.Window):
         dialog.set_current_folder(self.parameters.image_addr)
 
         response = dialog.run()
+        kernel_path = ""
         if response == gtk.RESPONSE_YES:
             kernel_path = dialog.get_filename()
-            image_path = os.path.join(self.parameters.image_addr, image_name)
+
         dialog.destroy()
 
-        if response == gtk.RESPONSE_YES:
-            source_env_path = os.path.join(self.parameters.core_base, "oe-init-build-env")
-            tmp_path = self.parameters.tmpdir
-            cmdline = bb.ui.crumbs.utils.which_terminal()
-            if os.path.exists(image_path) and os.path.exists(kernel_path) \
-               and os.path.exists(source_env_path) and os.path.exists(tmp_path) \
-               and cmdline:
-                cmdline += "\' bash -c \"export OE_TMPDIR=" + tmp_path + "; "
-                cmdline += "source " + source_env_path + " " + os.getcwd() + "; "
-                cmdline += "runqemu " + kernel_path + " " + image_path + "\"\'"
-                subprocess.Popen(shlex.split(cmdline))
-            else:
-                lbl = "<b>Path error</b>\nOne of your paths is wrong,"
-                lbl = lbl + " please make sure the following paths exist:\n"
-                lbl = lbl + "image path:" + image_path + "\n"
-                lbl = lbl + "kernel path:" + kernel_path + "\n"
-                lbl = lbl + "source environment path:" + source_env_path + "\n"
-                lbl = lbl + "tmp path: " + tmp_path + "."
-                lbl = lbl + "You may be missing either xterm or vte for terminal services."
-                dialog = CrumbsMessageDialog(self, lbl, gtk.STOCK_DIALOG_ERROR)
-                button = dialog.add_button("Close", gtk.RESPONSE_OK)
-                HobButton.style_button(button)
-                dialog.run()
-                dialog.destroy()
+        return kernel_path
+
+    def runqemu_image(self, image_name, kernel_name):
+        if not image_name or not kernel_name:
+            lbl = "<b>Please select an %s to launch in QEMU.</b>" % ("kernel" if image_name else "image")
+            dialog = CrumbsMessageDialog(self, lbl, gtk.STOCK_DIALOG_INFO)
+            button = dialog.add_button("Close", gtk.RESPONSE_OK)
+            HobButton.style_button(button)
+            dialog.run()
+            dialog.destroy()
+            return
+
+        kernel_path = os.path.join(self.parameters.image_addr, kernel_name)
+        image_path = os.path.join(self.parameters.image_addr, image_name)
+
+        source_env_path = os.path.join(self.parameters.core_base, "oe-init-build-env")
+        tmp_path = self.parameters.tmpdir
+        cmdline = bb.ui.crumbs.utils.which_terminal()
+        if os.path.exists(image_path) and os.path.exists(kernel_path) \
+           and os.path.exists(source_env_path) and os.path.exists(tmp_path) \
+           and cmdline:
+            cmdline += "\' bash -c \"export OE_TMPDIR=" + tmp_path + "; "
+            cmdline += "source " + source_env_path + " " + os.getcwd() + "; "
+            cmdline += "runqemu " + kernel_path + " " + image_path + "\"\'"
+            subprocess.Popen(shlex.split(cmdline))
+        else:
+            lbl = "<b>Path error</b>\nOne of your paths is wrong,"
+            lbl = lbl + " please make sure the following paths exist:\n"
+            lbl = lbl + "image path:" + image_path + "\n"
+            lbl = lbl + "kernel path:" + kernel_path + "\n"
+            lbl = lbl + "source environment path:" + source_env_path + "\n"
+            lbl = lbl + "tmp path: " + tmp_path + "."
+            lbl = lbl + "You may be missing either xterm or vte for terminal services."
+            dialog = CrumbsMessageDialog(self, lbl, gtk.STOCK_DIALOG_ERROR)
+            button = dialog.add_button("Close", gtk.RESPONSE_OK)
+            HobButton.style_button(button)
+            dialog.run()
+            dialog.destroy()
 
     def show_packages(self, ask=True):
         _, selected_recipes = self.recipe_model.get_selected_recipes()

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

@@ -20,17 +20,20 @@
 # with this program; if not, write to the Free Software Foundation, Inc.,
 # 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
 
+import glob
 import gtk
 import gobject
 import hashlib
 import os
 import re
-import subprocess
 import shlex
+import subprocess
+import tempfile
 from bb.ui.crumbs.hobcolor import HobColors
 from bb.ui.crumbs.hobwidget import hcc, hic, HobViewTable, HobInfoButton, HobButton, HobAltButton, HobIconChecker
 from bb.ui.crumbs.progressbar import HobProgressBar
 import bb.ui.crumbs.utils
+import bb.process
 
 """
 The following are convenience classes for implementing GNOME HIG compliant
@@ -63,7 +66,7 @@ class CrumbsMessageDialog(CrumbsDialog):
     """
     def __init__(self, parent=None, label="", icon=gtk.STOCK_INFO):
         super(CrumbsMessageDialog, self).__init__("", parent, gtk.DIALOG_DESTROY_WITH_PARENT)
-        
+
         self.set_border_width(6)
         self.vbox.set_property("spacing", 12)
         self.action_area.set_property("spacing", 12)
@@ -137,6 +140,8 @@ class AdvancedSettingDialog (CrumbsDialog):
     def entry_widget_select_path_cb(self, action, parent, entry):
         dialog = gtk.FileChooserDialog("", parent,
                                        gtk.FILE_CHOOSER_ACTION_SELECT_FOLDER)
+        text = entry.get_text()
+        dialog.set_current_folder(text if len(text) > 0 else os.getcwd())
         button = dialog.add_button("Cancel", gtk.RESPONSE_NO)
         HobAltButton.style_button(button)
         button = dialog.add_button("Open", gtk.RESPONSE_YES)
@@ -172,6 +177,45 @@ class AdvancedSettingDialog (CrumbsDialog):
         hbox.show_all()
         return hbox, entry
 
+    def details_cb(self, button, parent, protocol):
+        dialog = ProxyDetailsDialog(title = protocol.upper() + " Proxy Details",
+            user = self.configuration.proxies[protocol][1],
+            passwd = self.configuration.proxies[protocol][2],
+            parent = parent,
+            flags = gtk.DIALOG_MODAL
+                    | gtk.DIALOG_DESTROY_WITH_PARENT
+                    | gtk.DIALOG_NO_SEPARATOR)
+        dialog.add_button(gtk.STOCK_CLOSE, gtk.RESPONSE_OK)
+        response = dialog.run()
+        if response == gtk.RESPONSE_OK:
+            self.configuration.proxies[protocol][1] = dialog.user
+            self.configuration.proxies[protocol][2] = dialog.passwd
+            self.refresh_proxy_components()
+        dialog.destroy()
+
+    def gen_proxy_entry_widget(self, protocol, parent, need_button=True):
+        hbox = gtk.HBox(False, 12)
+
+        label = gtk.Label(protocol.upper() + " proxy")
+        hbox.pack_start(label, expand=True, fill=False, padding=24)
+
+        proxy_entry = gtk.Entry()
+        proxy_entry.set_size_request(300, -1)
+        hbox.pack_start(proxy_entry, expand=False, fill=False)
+
+        hbox.pack_start(gtk.Label(":"), expand=False, fill=False)
+
+        port_entry = gtk.Entry()
+        port_entry.set_size_request(60, -1)
+        hbox.pack_start(port_entry, expand=False, fill=False)
+
+        details_button = HobAltButton("Details")
+        details_button.connect("clicked", self.details_cb, parent, protocol)
+        hbox.pack_start(details_button, expand=False, fill=False)
+
+        hbox.show_all()
+        return hbox, proxy_entry, port_entry, details_button
+
     def rootfs_combo_changed_cb(self, rootfs_combo, all_package_format, check_hbox):
         combo_item = self.rootfs_combo.get_active_text()
         for child in check_hbox.get_children():
@@ -309,7 +353,7 @@ class AdvancedSettingDialog (CrumbsDialog):
 
     def __init__(self, title, configuration, all_image_types,
             all_package_formats, all_distros, all_sdk_machines,
-            max_threads, enable_proxy, parent, flags, buttons=None):
+            max_threads, parent, flags, buttons=None):
         super(AdvancedSettingDialog, self).__init__(title, parent, flags, buttons)
 
         # class members from other objects
@@ -320,7 +364,6 @@ class AdvancedSettingDialog (CrumbsDialog):
         self.all_distros = all_distros
         self.all_sdk_machines = all_sdk_machines
         self.max_threads = max_threads
-        self.enable_proxy = enable_proxy
 
         # class members for internal use
         self.distro_combo = None
@@ -356,6 +399,10 @@ class AdvancedSettingDialog (CrumbsDialog):
         data += ("SDK_MACHINE: "          + self._get_sorted_value(self.configuration.curr_sdk_machine))
         data += ("TOOLCHAIN_BUILD: "      + self._get_sorted_value(self.configuration.toolchain_build))
         data += ("IMAGE_FSTYPES: "        + self._get_sorted_value(self.configuration.image_fstypes))
+        data += ("ENABLE_PROXY: "         + self._get_sorted_value(self.configuration.enable_proxy))
+        if self.configuration.enable_proxy:
+            for protocol in self.configuration.proxies.keys():
+                data += (protocol + ": " + self._get_sorted_value(self.configuration.combine_proxy(protocol)))
         for key in self.configuration.extra_setting.keys():
             data += (key + ": " + self._get_sorted_value(self.configuration.extra_setting[key]))
         return hashlib.md5(data).hexdigest()
@@ -392,7 +439,10 @@ class AdvancedSettingDialog (CrumbsDialog):
         j = 1
         for image_type in self.image_types:
             self.image_types_checkbuttons[image_type] = gtk.CheckButton(image_type)
-            self.image_types_checkbuttons[image_type].set_tooltip_text("Build an %s image" % image_type)
+            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))
             table.attach(self.image_types_checkbuttons[image_type], j, j + 4, i, i + 1)
             if image_type in self.configuration.image_fstypes.split():
                 self.image_types_checkbuttons[image_type].set_active(True)
@@ -420,15 +470,15 @@ class AdvancedSettingDialog (CrumbsDialog):
         advanced_vbox.pack_start(sub_vbox, expand=False, fill=False)
         label = self.gen_label_widget("<span weight=\"bold\">Image rootfs size: (MB)</span>")
         tooltip = "Sets the basic size of your target image.\nThis is the basic size of your target image unless your selected package size exceeds this value or you select \'Image Extra Size\'."
-        rootfs_size_widget, self.rootfs_size_spinner = self.gen_spinner_widget(int(self.configuration.image_rootfs_size*1.0/1024), 0, 1024, tooltip)
+        rootfs_size_widget, self.rootfs_size_spinner = self.gen_spinner_widget(int(self.configuration.image_rootfs_size*1.0/1024), 0, 65536, tooltip)
         sub_vbox.pack_start(label, expand=False, fill=False)
         sub_vbox.pack_start(rootfs_size_widget, expand=False, fill=False)
 
         sub_vbox = gtk.VBox(False, 6)
         advanced_vbox.pack_start(sub_vbox, expand=False, fill=False)
         label = self.gen_label_widget("<span weight=\"bold\">Image extra size: (MB)</span>")
-        tooltip = "Sets the extra free space of your target image.\nBy default, the system reserves 30% of your image size as free space. If your image contains zypper, it brings in 50MB more space. The maximum free space is 1024MB."
-        extra_size_widget, self.extra_size_spinner = self.gen_spinner_widget(int(self.configuration.image_extra_size*1.0/1024), 0, 1024, tooltip)
+        tooltip = "Sets the extra free space of your target image.\nBy default, the system reserves 30% of your image size as free space. If your image contains zypper, it brings in 50MB more space. The maximum free space is 64GB."
+        extra_size_widget, self.extra_size_spinner = self.gen_spinner_widget(int(self.configuration.image_extra_size*1.0/1024), 0, 65536, tooltip)
         sub_vbox.pack_start(label, expand=False, fill=False)
         sub_vbox.pack_start(extra_size_widget, expand=False, fill=False)
 
@@ -447,7 +497,7 @@ class AdvancedSettingDialog (CrumbsDialog):
         self.toolchain_checkbox.set_active(self.configuration.toolchain_build)
         sub_hbox.pack_start(self.toolchain_checkbox, expand=False, fill=False)
 
-        tooltip = "Selects the Host platform for which you want to run the toolchain"
+        tooltip = "Selects the host platform for which you want to run the toolchain"
         sdk_machine_widget, self.sdk_machine_combo = self.gen_combo_widget(self.configuration.curr_sdk_machine, self.all_sdk_machines, tooltip)
         sub_hbox.pack_start(sdk_machine_widget, expand=False, fill=False)
 
@@ -517,60 +567,56 @@ class AdvancedSettingDialog (CrumbsDialog):
 
         sub_vbox = gtk.VBox(False, 6)
         advanced_vbox.pack_start(sub_vbox, expand=False, fill=False)
-        self.proxy_checkbox = gtk.CheckButton("Enable proxy")
+        label = self.gen_label_widget("<span weight=\"bold\">Set the proxies that will be used during fetching source code</span>")
+        tooltip = "Set the proxies that will be used during fetching source code or set none for direct the Internet connection"
+        info = HobInfoButton(tooltip, self)
+        hbox = gtk.HBox(False, 12)
+        hbox.pack_start(label, expand=True, fill=True)
+        hbox.pack_start(info, expand=False, fill=False)
+        sub_vbox.pack_start(hbox, expand=False, fill=False)
+
+        self.direct_checkbox = gtk.RadioButton(None, "Direct internet connection")
+        self.direct_checkbox.set_tooltip_text("Check this box to connect the Internet directly without any proxy")
+        self.direct_checkbox.set_active(not self.configuration.enable_proxy)
+        sub_vbox.pack_start(self.direct_checkbox, expand=False, fill=False)
+
+        self.proxy_checkbox = gtk.RadioButton(self.direct_checkbox, "Manual proxy configuration")
         self.proxy_checkbox.set_tooltip_text("Check this box to setup the proxy you specified")
-        self.proxy_checkbox.set_active(self.enable_proxy)
-        self.proxy_checkbox.connect("toggled", self.proxy_checkbox_toggled_cb)
+        self.proxy_checkbox.set_active(self.configuration.enable_proxy)
         sub_vbox.pack_start(self.proxy_checkbox, expand=False, fill=False)
 
-        label = self.gen_label_widget("<span weight=\"bold\">Set all proxy:</span>")
-        tooltip = "Set the all proxy that will be used if the proxy for a URL isn't specified."
-        proxy_widget, self.all_proxy_text = self.gen_entry_widget(self.configuration.all_proxy, self, tooltip, False)
-        self.all_proxy_text.set_editable(self.enable_proxy)
-        self.all_proxy_text.set_sensitive(self.enable_proxy)
-        sub_vbox.pack_start(label, expand=False, fill=False)
+        self.same_checkbox = gtk.CheckButton("Use the same proxy for all protocols")
+        self.same_checkbox.set_tooltip_text("Use the same proxy as the first proxy i.e. http proxy for all protocols")
+        self.same_checkbox.set_active(self.configuration.same_proxy)
+        hbox = gtk.HBox(False, 12)
+        hbox.pack_start(self.same_checkbox, expand=False, fill=False, padding=24)
+        sub_vbox.pack_start(hbox, expand=False, fill=False)
+
+        proxy_widget, self.http_proxy, self.http_proxy_port, self.http_proxy_details = self.gen_proxy_entry_widget(
+            "http", self, True)
         sub_vbox.pack_start(proxy_widget, expand=False, fill=False)
 
-        label = self.gen_label_widget("<span weight=\"bold\">Set http proxy:</span>")
-        tooltip = "Set the http proxy that will be used in do_fetch() source code"
-        proxy_widget, self.http_proxy_text = self.gen_entry_widget(self.configuration.http_proxy, self, tooltip, False)
-        self.http_proxy_text.set_editable(self.enable_proxy)
-        self.http_proxy_text.set_sensitive(self.enable_proxy)
-        sub_vbox.pack_start(label, expand=False, fill=False)
+        proxy_widget, self.https_proxy, self.https_proxy_port, self.https_proxy_details = self.gen_proxy_entry_widget(
+            "https", self, True)
         sub_vbox.pack_start(proxy_widget, expand=False, fill=False)
 
-        label = self.gen_label_widget("<span weight=\"bold\">Set https proxy:</span>")
-        tooltip = "Set the https proxy that will be used in do_fetch() source code"
-        proxy_widget, self.https_proxy_text = self.gen_entry_widget(self.configuration.https_proxy, self, tooltip, False)
-        self.https_proxy_text.set_editable(self.enable_proxy)
-        self.https_proxy_text.set_sensitive(self.enable_proxy)
-        sub_vbox.pack_start(label, expand=False, fill=False)
+        proxy_widget, self.ftp_proxy, self.ftp_proxy_port, self.ftp_proxy_details = self.gen_proxy_entry_widget(
+            "ftp", self, True)
         sub_vbox.pack_start(proxy_widget, expand=False, fill=False)
 
-        label = self.gen_label_widget("<span weight=\"bold\">Set ftp proxy:</span>")
-        tooltip = "Set the ftp proxy that will be used in do_fetch() source code"
-        proxy_widget, self.ftp_proxy_text = self.gen_entry_widget(self.configuration.ftp_proxy, self, tooltip, False)
-        self.ftp_proxy_text.set_editable(self.enable_proxy)
-        self.ftp_proxy_text.set_sensitive(self.enable_proxy)
-        sub_vbox.pack_start(label, expand=False, fill=False)
+        proxy_widget, self.git_proxy, self.git_proxy_port, self.git_proxy_details = self.gen_proxy_entry_widget(
+            "git", self, True)
         sub_vbox.pack_start(proxy_widget, expand=False, fill=False)
 
-        label = self.gen_label_widget("<span weight=\"bold\">Set git proxy:</span>")
-        tooltip = "Set the git proxy that will be used in do_fetch() source code"
-        proxy_widget, self.git_proxy_text = self.gen_entry_widget(self.configuration.git_proxy_host + ':' + self.configuration.git_proxy_port, self, tooltip, False)
-        self.git_proxy_text.set_editable(self.enable_proxy)
-        self.git_proxy_text.set_sensitive(self.enable_proxy)
-        sub_vbox.pack_start(label, expand=False, fill=False)
+        proxy_widget, self.cvs_proxy, self.cvs_proxy_port, self.cvs_proxy_details = self.gen_proxy_entry_widget(
+            "cvs", self, True)
         sub_vbox.pack_start(proxy_widget, expand=False, fill=False)
 
-        label = self.gen_label_widget("<span weight=\"bold\">Set cvs proxy:</span>")
-        tooltip = "Set the cvs proxy that will be used in do_fetch() source code"
-        proxy_widget, self.cvs_proxy_text = self.gen_entry_widget(self.configuration.cvs_proxy_host + ':' + self.configuration.cvs_proxy_port, self, tooltip, False)
-        self.cvs_proxy_text.set_editable(self.enable_proxy)
-        self.cvs_proxy_text.set_sensitive(self.enable_proxy)
-        sub_vbox.pack_start(label, expand=False, fill=False)
-        sub_vbox.pack_start(proxy_widget, expand=False, fill=False)
+        self.direct_checkbox.connect("toggled", self.proxy_checkbox_toggled_cb)
+        self.proxy_checkbox.connect("toggled", self.proxy_checkbox_toggled_cb)
+        self.same_checkbox.connect("toggled", self.same_checkbox_toggled_cb)
 
+        self.refresh_proxy_components()
         return advanced_vbox
 
     def create_others_page(self):
@@ -587,20 +633,59 @@ class AdvancedSettingDialog (CrumbsDialog):
 
         return advanced_vbox
 
+    def refresh_proxy_components(self):
+        self.same_checkbox.set_sensitive(self.configuration.enable_proxy)
+
+        self.http_proxy.set_text(self.configuration.combine_host_only("http"))
+        self.http_proxy.set_editable(self.configuration.enable_proxy)
+        self.http_proxy.set_sensitive(self.configuration.enable_proxy)
+        self.http_proxy_port.set_text(self.configuration.combine_port_only("http"))
+        self.http_proxy_port.set_editable(self.configuration.enable_proxy)
+        self.http_proxy_port.set_sensitive(self.configuration.enable_proxy)
+        self.http_proxy_details.set_sensitive(self.configuration.enable_proxy)
+
+        self.https_proxy.set_text(self.configuration.combine_host_only("https"))
+        self.https_proxy.set_editable(self.configuration.enable_proxy and (not self.configuration.same_proxy))
+        self.https_proxy.set_sensitive(self.configuration.enable_proxy and (not self.configuration.same_proxy))
+        self.https_proxy_port.set_text(self.configuration.combine_port_only("https"))
+        self.https_proxy_port.set_editable(self.configuration.enable_proxy and (not self.configuration.same_proxy))
+        self.https_proxy_port.set_sensitive(self.configuration.enable_proxy and (not self.configuration.same_proxy))
+        self.https_proxy_details.set_sensitive(self.configuration.enable_proxy and (not self.configuration.same_proxy))
+
+        self.ftp_proxy.set_text(self.configuration.combine_host_only("ftp"))
+        self.ftp_proxy.set_editable(self.configuration.enable_proxy and (not self.configuration.same_proxy))
+        self.ftp_proxy.set_sensitive(self.configuration.enable_proxy and (not self.configuration.same_proxy))
+        self.ftp_proxy_port.set_text(self.configuration.combine_port_only("ftp"))
+        self.ftp_proxy_port.set_editable(self.configuration.enable_proxy and (not self.configuration.same_proxy))
+        self.ftp_proxy_port.set_sensitive(self.configuration.enable_proxy and (not self.configuration.same_proxy))
+        self.ftp_proxy_details.set_sensitive(self.configuration.enable_proxy and (not self.configuration.same_proxy))
+
+        self.git_proxy.set_text(self.configuration.combine_host_only("git"))
+        self.git_proxy.set_editable(self.configuration.enable_proxy and (not self.configuration.same_proxy))
+        self.git_proxy.set_sensitive(self.configuration.enable_proxy and (not self.configuration.same_proxy))
+        self.git_proxy_port.set_text(self.configuration.combine_port_only("git"))
+        self.git_proxy_port.set_editable(self.configuration.enable_proxy and (not self.configuration.same_proxy))
+        self.git_proxy_port.set_sensitive(self.configuration.enable_proxy and (not self.configuration.same_proxy))
+        self.git_proxy_details.set_sensitive(self.configuration.enable_proxy and (not self.configuration.same_proxy))
+
+        self.cvs_proxy.set_text(self.configuration.combine_host_only("cvs"))
+        self.cvs_proxy.set_editable(self.configuration.enable_proxy and (not self.configuration.same_proxy))
+        self.cvs_proxy.set_sensitive(self.configuration.enable_proxy and (not self.configuration.same_proxy))
+        self.cvs_proxy_port.set_text(self.configuration.combine_port_only("cvs"))
+        self.cvs_proxy_port.set_editable(self.configuration.enable_proxy and (not self.configuration.same_proxy))
+        self.cvs_proxy_port.set_sensitive(self.configuration.enable_proxy and (not self.configuration.same_proxy))
+        self.cvs_proxy_details.set_sensitive(self.configuration.enable_proxy and (not self.configuration.same_proxy))
+
     def proxy_checkbox_toggled_cb(self, button):
-        self.enable_proxy = self.proxy_checkbox.get_active()
-        self.all_proxy_text.set_editable(self.enable_proxy)
-        self.all_proxy_text.set_sensitive(self.enable_proxy)
-        self.http_proxy_text.set_editable(self.enable_proxy)
-        self.http_proxy_text.set_sensitive(self.enable_proxy)
-        self.https_proxy_text.set_editable(self.enable_proxy)
-        self.https_proxy_text.set_sensitive(self.enable_proxy)
-        self.ftp_proxy_text.set_editable(self.enable_proxy)
-        self.ftp_proxy_text.set_sensitive(self.enable_proxy)
-        self.git_proxy_text.set_editable(self.enable_proxy)
-        self.git_proxy_text.set_sensitive(self.enable_proxy)
-        self.cvs_proxy_text.set_editable(self.enable_proxy)
-        self.cvs_proxy_text.set_sensitive(self.enable_proxy)
+        self.configuration.enable_proxy = self.proxy_checkbox.get_active()
+        if not self.configuration.enable_proxy:
+            self.configuration.same_proxy = False
+            self.same_checkbox.set_active(self.configuration.same_proxy)
+        self.refresh_proxy_components()
+
+    def same_checkbox_toggled_cb(self, button):
+        self.configuration.same_proxy = self.same_checkbox.get_active()
+        self.refresh_proxy_components()
 
     def response_cb(self, dialog, response_id):
         package_format = []
@@ -644,12 +729,17 @@ class AdvancedSettingDialog (CrumbsDialog):
             self.configuration.extra_setting[key] = value
             it = self.setting_store.iter_next(it)
 
-        self.configuration.all_proxy = self.all_proxy_text.get_text()
-        self.configuration.http_proxy = self.http_proxy_text.get_text()
-        self.configuration.https_proxy = self.https_proxy_text.get_text()
-        self.configuration.ftp_proxy = self.ftp_proxy_text.get_text()
-        self.configuration.git_proxy_host, self.configuration.git_proxy_port = self.git_proxy_text.get_text().split(':')
-        self.configuration.cvs_proxy_host, self.configuration.cvs_proxy_port = self.cvs_proxy_text.get_text().split(':')
+        self.configuration.split_proxy("http", self.http_proxy.get_text() + ":" + self.http_proxy_port.get_text())
+        if self.configuration.same_proxy:
+            self.configuration.split_proxy("https", self.http_proxy.get_text() + ":" + self.http_proxy_port.get_text())
+            self.configuration.split_proxy("ftp", self.http_proxy.get_text() + ":" + self.http_proxy_port.get_text())
+            self.configuration.split_proxy("git", self.http_proxy.get_text() + ":" + self.http_proxy_port.get_text())
+            self.configuration.split_proxy("cvs", self.http_proxy.get_text() + ":" + self.http_proxy_port.get_text())
+        else:
+            self.configuration.split_proxy("https", self.https_proxy.get_text() + ":" + self.https_proxy_port.get_text())
+            self.configuration.split_proxy("ftp", self.ftp_proxy.get_text() + ":" + self.ftp_proxy_port.get_text())
+            self.configuration.split_proxy("git", self.git_proxy.get_text() + ":" + self.git_proxy_port.get_text())
+            self.configuration.split_proxy("cvs", self.cvs_proxy.get_text() + ":" + self.cvs_proxy_port.get_text())
 
         md5 = self.config_md5()
         self.settings_changed = (self.md5 != md5)
@@ -661,21 +751,28 @@ class DeployImageDialog (CrumbsDialog):
 
     __dummy_usb__ = "--select a usb drive--"
 
-    def __init__(self, title, image_path, parent, flags, buttons=None):
+    def __init__(self, title, image_path, parent, flags, buttons=None, standalone=False):
         super(DeployImageDialog, self).__init__(title, parent, flags, buttons)
 
         self.image_path = image_path
+        self.standalone = standalone
 
         self.create_visual_elements()
         self.connect("response", self.response_cb)
 
     def create_visual_elements(self):
+        self.set_size_request(600, 400)
         label = gtk.Label()
         label.set_alignment(0.0, 0.5)
         markup = "<span font_desc='12'>The image to be written into usb drive:</span>"
         label.set_markup(markup)
         self.vbox.pack_start(label, expand=False, fill=False, padding=2)
 
+        table = gtk.Table(2, 10, False)
+        table.set_col_spacings(5)
+        table.set_row_spacings(5)
+        self.vbox.pack_start(table, expand=True, fill=True)
+
         scroll = gtk.ScrolledWindow()
         scroll.set_policy(gtk.POLICY_NEVER, gtk.POLICY_AUTOMATIC)
         scroll.set_shadow_type(gtk.SHADOW_IN)
@@ -683,11 +780,31 @@ class DeployImageDialog (CrumbsDialog):
         tv.set_editable(False)
         tv.set_wrap_mode(gtk.WRAP_WORD)
         tv.set_cursor_visible(False)
-        buf = gtk.TextBuffer()
-        buf.set_text(self.image_path)
-        tv.set_buffer(buf)
+        self.buf = gtk.TextBuffer()
+        self.buf.set_text(self.image_path)
+        tv.set_buffer(self.buf)
         scroll.add(tv)
-        self.vbox.pack_start(scroll, expand=True, fill=True)
+        table.attach(scroll, 0, 10, 0, 1)
+
+        # There are 2 ways to use DeployImageDialog
+        # One way is that called by HOB when the 'Deploy Image' button is clicked
+        # The other way is that called by a standalone script.
+        # Following block of codes handles the latter way. It adds a 'Select Image' button and
+        # emit a signal when the button is clicked.
+        if self.standalone:
+                gobject.signal_new("select_image_clicked", self, gobject.SIGNAL_RUN_FIRST,
+                                   gobject.TYPE_NONE, ())
+                icon = gtk.Image()
+                pix_buffer = gtk.gdk.pixbuf_new_from_file(hic.ICON_IMAGES_DISPLAY_FILE)
+                icon.set_from_pixbuf(pix_buffer)
+                button = gtk.Button("Select Image")
+                button.set_image(icon)
+                button.set_size_request(140, 50)
+                table.attach(button, 9, 10, 1, 2, gtk.FILL, 0, 0, 0)
+                button.connect("clicked", self.select_image_button_clicked_cb)
+
+        separator = gtk.HSeparator()
+        self.vbox.pack_start(separator, expand=False, fill=False, padding=10)
 
         self.usb_desc = gtk.Label()
         self.usb_desc.set_alignment(0.0, 0.5)
@@ -702,7 +819,7 @@ class DeployImageDialog (CrumbsDialog):
         for usb in self.find_all_usb_devices():
             self.usb_combo.append_text("/dev/" + usb)
         self.usb_combo.set_active(0)
-        self.vbox.pack_start(self.usb_combo, expand=True, fill=True)
+        self.vbox.pack_start(self.usb_combo, expand=False, fill=False)
         self.vbox.pack_start(self.usb_desc, expand=False, fill=False, padding=2)
 
         self.progress_bar = HobProgressBar()
@@ -713,12 +830,19 @@ class DeployImageDialog (CrumbsDialog):
         self.vbox.show_all()
         self.progress_bar.hide()
 
+    def set_image_text_buffer(self, image_path):
+        self.buf.set_text(image_path)
+
+    def set_image_path(self, image_path):
+        self.image_path = image_path
+
     def popen_read(self, cmd):
-        return os.popen("%s 2>/dev/null" % cmd).read().strip()
+        tmpout, errors = bb.process.run("%s" % cmd)
+        return tmpout.strip()
 
     def find_all_usb_devices(self):
         usb_devs = [ os.readlink(u)
-            for u in self.popen_read('ls /dev/disk/by-id/usb*').split()
+            for u in glob.glob('/dev/disk/by-id/usb*')
             if not re.search(r'part\d+', u) ]
         return [ '%s' % u[u.rfind('/')+1:] for u in usb_devs ]
 
@@ -727,6 +851,9 @@ class DeployImageDialog (CrumbsDialog):
             (self.popen_read('cat /sys/class/block/%s/device/vendor' % dev),
             self.popen_read('cat /sys/class/block/%s/device/model' % dev))
 
+    def select_image_button_clicked_cb(self, button):
+            self.emit('select_image_clicked')
+
     def usb_combo_changed_cb(self, usb_combo):
         combo_item = self.usb_combo.get_active_text()
         if not combo_item or combo_item == self.__dummy_usb__:
@@ -738,12 +865,32 @@ class DeployImageDialog (CrumbsDialog):
 
     def response_cb(self, dialog, response_id):
         if response_id == gtk.RESPONSE_YES:
+            lbl = ''
             combo_item = self.usb_combo.get_active_text()
-            if combo_item and combo_item != self.__dummy_usb__:
+            if combo_item and combo_item != self.__dummy_usb__ and self.image_path:
                 cmdline = bb.ui.crumbs.utils.which_terminal()
                 if cmdline:
-                    cmdline += "\"sudo dd if=" + self.image_path + " of=" + combo_item + "\""
-                    subprocess.Popen(args=shlex.split(cmdline))
+                    tmpfile = tempfile.NamedTemporaryFile()
+                    cmdline += "\"sudo dd if=" + self.image_path + \
+                                " of=" + combo_item + "; echo $? > " + tmpfile.name + "\""
+                    subprocess.call(shlex.split(cmdline))
+
+                    if int(tmpfile.readline().strip()) == 0:
+                        lbl = "<b>Deploy image successfully.</b>"
+                    else:
+                        lbl = "<b>Failed to deploy image.</b>\nPlease check image <b>%s</b> exists and USB device <b>%s</b> is writable." % (self.image_path, combo_item)
+                    tmpfile.close()
+            else:
+                if not self.image_path:
+                    lbl = "<b>No selection made.</b>\nYou have not selected an image to deploy."
+                else:
+                    lbl = "<b>No selection made.</b>\nYou have not selected a USB device."
+            if len(lbl):
+                crumbs_dialog = CrumbsMessageDialog(self, lbl, gtk.STOCK_DIALOG_INFO)
+                button = crumbs_dialog.add_button("Close", gtk.RESPONSE_OK)
+                HobButton.style_button(button)
+                crumbs_dialog.run()
+                crumbs_dialog.destroy()
 
     def update_progress_bar(self, title, fraction, status=None):
         self.progress_bar.update(fraction)
@@ -947,7 +1094,7 @@ class LayerSelectionDialog (CrumbsDialog):
         # create visual elements on the dialog
         self.create_visual_elements()
         self.connect("response", self.response_cb)
-                
+
     def create_visual_elements(self):
         layer_widget, self.layer_store = self.gen_layer_widget(self.layers, self.all_layers, self, None)
         layer_widget.set_size_request(450, 250)
@@ -1061,12 +1208,13 @@ class ImageSelectionDialog (CrumbsDialog):
         self.image_table = HobViewTable(self.__columns__)
         self.image_table.set_size_request(-1, 300)
         self.image_table.connect("toggled", self.toggled_cb)
+        self.image_table.connect_group_selection(self.table_selected_cb)
+        self.image_table.connect("row-activated", self.row_actived_cb)
         self.vbox.pack_start(self.image_table, expand=True, fill=True)
 
         self.show_all()
 
-    def toggled_cb(self, table, cell, path, columnid, tree):
-        model = tree.get_model()
+    def change_image_cb(self, model, path, columnid):
         if not model:
             return
         iter = model.get_iter_first()
@@ -1077,9 +1225,24 @@ class ImageSelectionDialog (CrumbsDialog):
 
         model[path][columnid] = True
 
+    def toggled_cb(self, table, cell, path, columnid, tree):
+        model = tree.get_model()
+        self.change_image_cb(model, path, columnid)
+
+    def table_selected_cb(self, selection):
+        model, paths = selection.get_selected_rows()
+        if paths:
+            self.change_image_cb(model, paths[0], 1)
+
+    def row_actived_cb(self, tab, model, path):
+        self.change_image_cb(model, path, 1)
+        self.emit('response', gtk.RESPONSE_YES)
+
     def select_path_cb(self, action, parent, entry):
         dialog = gtk.FileChooserDialog("", parent,
                                        gtk.FILE_CHOOSER_ACTION_SELECT_FOLDER)
+        text = entry.get_text()
+        dialog.set_current_folder(text if len(text) > 0 else os.getcwd())
         button = dialog.add_button("Cancel", gtk.RESPONSE_NO)
         HobAltButton.style_button(button)
         button = dialog.add_button("Open", gtk.RESPONSE_YES)
@@ -1104,9 +1267,9 @@ class ImageSelectionDialog (CrumbsDialog):
                 for image_type in self.image_types:
                     for real_image_type in hcc.SUPPORTED_IMAGE_TYPES[image_type]:
                         if f.endswith('.' + real_image_type):
-                            imageset.add(f.rsplit('.' + real_image_type)[0])
+                            imageset.add(f.rsplit('.' + real_image_type)[0].rsplit('.rootfs')[0])
                             self.image_list.append(f)
-        
+
         for image in imageset:
             self.image_store.set(self.image_store.append(), 0, image, 1, False)
 
@@ -1122,5 +1285,65 @@ class ImageSelectionDialog (CrumbsDialog):
                     for f in self.image_list:
                         if f.startswith(self.image_store[path][0] + '.'):
                             self.image_names.append(f)
-                    break            
+                    break
                 iter = self.image_store.iter_next(iter)
+
+class ProxyDetailsDialog (CrumbsDialog):
+
+    def __init__(self, title, user, passwd, parent, flags, buttons=None):
+        super(ProxyDetailsDialog, self).__init__(title, parent, flags, buttons)
+        self.connect("response", self.response_cb)
+
+        self.auth = not (user == None or passwd == None or user == "")
+        self.user = user or ""
+        self.passwd = passwd or ""
+
+        # create visual elements on the dialog
+        self.create_visual_elements()
+
+    def create_visual_elements(self):
+        self.auth_checkbox = gtk.CheckButton("Use authentication")
+        self.auth_checkbox.set_tooltip_text("Check this box to set the username and the password")
+        self.auth_checkbox.set_active(self.auth)
+        self.auth_checkbox.connect("toggled", self.auth_checkbox_toggled_cb)
+        self.vbox.pack_start(self.auth_checkbox, expand=False, fill=False)
+
+        hbox = gtk.HBox(False, 6)
+        self.user_label = gtk.Label("Username:")
+        self.user_text = gtk.Entry()
+        self.user_text.set_text(self.user)
+        hbox.pack_start(self.user_label, expand=False, fill=False)
+        hbox.pack_end(self.user_text, expand=False, fill=False)
+        self.vbox.pack_start(hbox, expand=False, fill=False)
+
+        hbox = gtk.HBox(False, 6)
+        self.passwd_label = gtk.Label("Password:")
+        self.passwd_text = gtk.Entry()
+        self.passwd_text.set_text(self.passwd)
+        hbox.pack_start(self.passwd_label, expand=False, fill=False)
+        hbox.pack_end(self.passwd_text, expand=False, fill=False)
+        self.vbox.pack_start(hbox, expand=False, fill=False)
+
+        self.refresh_auth_components()
+        self.show_all()
+
+    def refresh_auth_components(self):
+        self.user_label.set_sensitive(self.auth)
+        self.user_text.set_editable(self.auth)
+        self.user_text.set_sensitive(self.auth)
+        self.passwd_label.set_sensitive(self.auth)
+        self.passwd_text.set_editable(self.auth)
+        self.passwd_text.set_sensitive(self.auth)
+
+    def auth_checkbox_toggled_cb(self, button):
+        self.auth = self.auth_checkbox.get_active()
+        self.refresh_auth_components()
+
+    def response_cb(self, dialog, response_id):
+        if response_id == gtk.RESPONSE_OK:
+            if self.auth:
+                self.user = self.user_text.get_text()
+                self.passwd = self.passwd_text.get_text()
+            else:
+                self.user = None
+                self.passwd = None

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

@@ -42,6 +42,9 @@ class HobHandler(gobject.GObject):
          "command-failed"          : (gobject.SIGNAL_RUN_LAST,
                                       gobject.TYPE_NONE,
                                      (gobject.TYPE_STRING,)),
+         "sanity-failed"           : (gobject.SIGNAL_RUN_LAST,
+                                      gobject.TYPE_NONE,
+                                     (gobject.TYPE_STRING,)),
          "generating-data"         : (gobject.SIGNAL_RUN_LAST,
                                       gobject.TYPE_NONE,
                                      ()),
@@ -57,10 +60,16 @@ class HobHandler(gobject.GObject):
          "parsing-completed"       : (gobject.SIGNAL_RUN_LAST,
                                       gobject.TYPE_NONE,
                                      (gobject.TYPE_PYOBJECT,)),
+         "recipe-populated"        : (gobject.SIGNAL_RUN_LAST,
+                                      gobject.TYPE_NONE,
+                                     ()),
+         "package-populated"       : (gobject.SIGNAL_RUN_LAST,
+                                      gobject.TYPE_NONE,
+                                     ()),
     }
 
-    (PARSE_CONFIG, GENERATE_CONFIGURATION, GENERATE_RECIPES, GENERATE_PACKAGES, GENERATE_IMAGE, POPULATE_PACKAGEINFO) = range(6)
-    (SUB_PATH_LAYERS, SUB_FILES_DISTRO, SUB_FILES_MACH, SUB_FILES_SDKMACH, SUB_MATCH_CLASS, SUB_PARSE_CONFIG, SUB_GNERATE_TGTS, SUB_GENERATE_PKGINFO, SUB_BUILD_RECIPES, SUB_BUILD_IMAGE) = range(10)
+    (GENERATE_CONFIGURATION, GENERATE_RECIPES, GENERATE_PACKAGES, GENERATE_IMAGE, POPULATE_PACKAGEINFO, SANITY_CHECK) = range(6)
+    (SUB_PATH_LAYERS, SUB_FILES_DISTRO, SUB_FILES_MACH, SUB_FILES_SDKMACH, SUB_MATCH_CLASS, SUB_PARSE_CONFIG, SUB_SANITY_CHECK, SUB_GNERATE_TGTS, SUB_GENERATE_PKGINFO, SUB_BUILD_RECIPES, SUB_BUILD_IMAGE) = range(11)
 
     def __init__(self, server, recipe_model, package_model):
         super(HobHandler, self).__init__()
@@ -91,6 +100,15 @@ class HobHandler(gobject.GObject):
             self.emit("data-generated")
             self.generating = False
 
+    def runCommand(self, commandline):
+        try:
+            return self.server.runCommand(commandline)
+        except Exception as e:
+            self.commands_async = []
+            self.clear_busy()
+            self.emit("command-failed", "Hob Exception - %s" % (str(e)))
+            return None
+
     def run_next_command(self, initcmd=None):
         if initcmd != None:
             self.initcmd = initcmd
@@ -105,36 +123,39 @@ class HobHandler(gobject.GObject):
             return
 
         if next_command == self.SUB_PATH_LAYERS:
-            self.server.runCommand(["findConfigFilePath", "bblayers.conf"])
+            self.runCommand(["findConfigFilePath", "bblayers.conf"])
         elif next_command == self.SUB_FILES_DISTRO:
-            self.server.runCommand(["findConfigFiles", "DISTRO"])
+            self.runCommand(["findConfigFiles", "DISTRO"])
         elif next_command == self.SUB_FILES_MACH:
-            self.server.runCommand(["findConfigFiles", "MACHINE"])
+            self.runCommand(["findConfigFiles", "MACHINE"])
         elif next_command == self.SUB_FILES_SDKMACH:
-            self.server.runCommand(["findConfigFiles", "MACHINE-SDK"])
+            self.runCommand(["findConfigFiles", "MACHINE-SDK"])
         elif next_command == self.SUB_MATCH_CLASS:
-            self.server.runCommand(["findFilesMatchingInDir", "rootfs_", "classes"])
+            self.runCommand(["findFilesMatchingInDir", "rootfs_", "classes"])
         elif next_command == self.SUB_PARSE_CONFIG:
-            self.server.runCommand(["parseConfigurationFiles", "", ""])
+            self.runCommand(["parseConfigurationFiles", "", ""])
         elif next_command == self.SUB_GNERATE_TGTS:
-            self.server.runCommand(["generateTargetsTree", "classes/image.bbclass", []])
+            self.runCommand(["generateTargetsTree", "classes/image.bbclass", []])
         elif next_command == self.SUB_GENERATE_PKGINFO:
-            self.server.runCommand(["triggerEvent", "bb.event.RequestPackageInfo()"])
+            self.runCommand(["triggerEvent", "bb.event.RequestPackageInfo()"])
+        elif next_command == self.SUB_SANITY_CHECK:
+            self.runCommand(["triggerEvent", "bb.event.SanityCheck()"])
         elif next_command == self.SUB_BUILD_RECIPES:
             self.clear_busy()
             self.building = True
-            self.server.runCommand(["buildTargets", self.recipe_queue, "build"])
+            self.runCommand(["buildTargets", self.recipe_queue, self.default_task])
             self.recipe_queue = []
         elif next_command == self.SUB_BUILD_IMAGE:
             self.clear_busy()
             self.building = True
-            targets = [self.hob_image]
-            self.server.runCommand(["setVariable", "LINGUAS_INSTALL", ""])
-            self.server.runCommand(["setVariable", "PACKAGE_INSTALL", " ".join(self.package_queue)])
+            targets = [self.image]
+            if self.package_queue:
+                self.runCommand(["setVariable", "LINGUAS_INSTALL", ""])
+                self.runCommand(["setVariable", "PACKAGE_INSTALL", " ".join(self.package_queue)])
             if self.toolchain_packages:
-                self.server.runCommand(["setVariable", "TOOLCHAIN_TARGET_TASK", " ".join(self.toolchain_packages)])
-                targets.append(self.hob_toolchain)
-            self.server.runCommand(["buildTargets", targets, "build"])
+                self.runCommand(["setVariable", "TOOLCHAIN_TARGET_TASK", " ".join(self.toolchain_packages)])
+                targets.append(self.toolchain)
+            self.runCommand(["buildTargets", targets, self.default_task])
 
     def handle_event(self, event):
         if not event:
@@ -146,8 +167,15 @@ class HobHandler(gobject.GObject):
 
         if isinstance(event, bb.event.PackageInfo):
             self.package_model.populate(event._pkginfolist)
+            self.emit("package-populated")
             self.run_next_command()
 
+        elif isinstance(event, bb.event.SanityCheckPassed):
+            self.run_next_command()
+
+        elif isinstance(event, bb.event.SanityCheckFailed):
+            self.emit("sanity-failed", event._msg)
+
         elif isinstance(event, logging.LogRecord):
             if event.levelno >= logging.ERROR:
                 self.error_msg += event.msg + '\n'
@@ -156,6 +184,7 @@ class HobHandler(gobject.GObject):
             self.current_phase = "data generation"
             if event._model:
                 self.recipe_model.populate(event._model)
+                self.emit("recipe-populated")
         elif isinstance(event, bb.event.ConfigFilesFound):
             self.current_phase = "configuration lookup"
             var = event._variable
@@ -179,32 +208,13 @@ class HobHandler(gobject.GObject):
         elif isinstance(event, bb.command.CommandCompleted):
             self.current_phase = None
             self.run_next_command()
-        # TODO: Currently there are NoProvider issues when generate
-        # universe tree dependency for non-x86 architecture.
-        # Comment the follow code to enable the build of non-x86
-        # architectures in Hob.
-        #elif isinstance(event, bb.event.NoProvider):
-        #    if event._runtime:
-        #        r = "R"
-        #    else:
-        #        r = ""
-        #    if event._dependees:
-        #        self.error_msg += " Nothing %sPROVIDES '%s' (but %s %sDEPENDS on or otherwise requires it)" % (r, event._item, ", ".join(event._dependees), r)
-        #    else:
-        #        self.error_msg += " Nothing %sPROVIDES '%s'" % (r, event._item)
-        #    if event._reasons:
-        #        for reason in event._reasons:
-        #            self.error_msg += " %s" % reason
-
-        #    self.commands_async = []
-        #    self.emit("command-failed", self.error_msg)
-        #    self.error_msg = ""
-
         elif isinstance(event, bb.command.CommandFailed):
             self.commands_async = []
             self.clear_busy()
             self.emit("command-failed", self.error_msg)
             self.error_msg = ""
+            if self.building:
+                self.building = False
         elif isinstance(event, (bb.event.ParseStarted,
                  bb.event.CacheLoadStarted,
                  bb.event.TreeDataPreparationStarted,
@@ -237,99 +247,95 @@ class HobHandler(gobject.GObject):
         return
 
     def init_cooker(self):
-        self.server.runCommand(["initCooker"])
-
-    def parse_config(self):
-        self.commands_async.append(self.SUB_PARSE_CONFIG)
-        self.run_next_command(self.PARSE_CONFIG)
-
-    def parse_generate_configuration(self):
-        self.commands_async.append(self.SUB_PARSE_CONFIG)
-        self.generate_configuration()
+        self.runCommand(["initCooker"])
 
     def set_extra_inherit(self, bbclass):
-        inherits = self.server.runCommand(["getVariable", "INHERIT"]) or ""
+        inherits = self.runCommand(["getVariable", "INHERIT"]) or ""
         inherits = inherits + " " + bbclass
-        self.server.runCommand(["setVariable", "INHERIT", inherits])
+        self.runCommand(["setVariable", "INHERIT", inherits])
 
     def set_bblayers(self, bblayers):
-        self.server.runCommand(["setVariable", "BBLAYERS", " ".join(bblayers)])
+        self.runCommand(["setVariable", "BBLAYERS_HOB", " ".join(bblayers)])
 
     def set_machine(self, machine):
         if machine:
-            self.server.runCommand(["setVariable", "MACHINE", machine])
+            self.runCommand(["setVariable", "MACHINE_HOB", machine])
 
     def set_sdk_machine(self, sdk_machine):
-        self.server.runCommand(["setVariable", "SDKMACHINE", sdk_machine])
+        self.runCommand(["setVariable", "SDKMACHINE_HOB", sdk_machine])
 
     def set_image_fstypes(self, image_fstypes):
-        self.server.runCommand(["setVariable", "IMAGE_FSTYPES", image_fstypes])
+        self.runCommand(["setVariable", "IMAGE_FSTYPES", image_fstypes])
 
     def set_distro(self, distro):
-        if distro != "defaultsetup":
-            self.server.runCommand(["setVariable", "DISTRO", distro])
+        self.runCommand(["setVariable", "DISTRO_HOB", distro])
 
     def set_package_format(self, format):
         package_classes = ""
         for pkgfmt in format.split():
             package_classes += ("package_%s" % pkgfmt + " ")
-        self.server.runCommand(["setVariable", "PACKAGE_CLASSES", package_classes])
+        self.runCommand(["setVariable", "PACKAGE_CLASSES_HOB", package_classes])
 
     def set_bbthreads(self, threads):
-        self.server.runCommand(["setVariable", "BB_NUMBER_THREADS", threads])
+        self.runCommand(["setVariable", "BB_NUMBER_THREADS_HOB", threads])
 
     def set_pmake(self, threads):
         pmake = "-j %s" % threads
-        self.server.runCommand(["setVariable", "PARALLEL_MAKE", pmake])
+        self.runCommand(["setVariable", "PARALLEL_MAKE_HOB", pmake])
 
     def set_dl_dir(self, directory):
-        self.server.runCommand(["setVariable", "DL_DIR", directory])
+        self.runCommand(["setVariable", "DL_DIR_HOB", directory])
 
     def set_sstate_dir(self, directory):
-        self.server.runCommand(["setVariable", "SSTATE_DIR", directory])
+        self.runCommand(["setVariable", "SSTATE_DIR_HOB", directory])
 
     def set_sstate_mirror(self, url):
-        self.server.runCommand(["setVariable", "SSTATE_MIRROR", url])
+        self.runCommand(["setVariable", "SSTATE_MIRROR_HOB", url])
 
     def set_extra_size(self, image_extra_size):
-        self.server.runCommand(["setVariable", "IMAGE_ROOTFS_EXTRA_SPACE", str(image_extra_size)])
+        self.runCommand(["setVariable", "IMAGE_ROOTFS_EXTRA_SPACE", str(image_extra_size)])
 
     def set_rootfs_size(self, image_rootfs_size):
-        self.server.runCommand(["setVariable", "IMAGE_ROOTFS_SIZE", str(image_rootfs_size)])
+        self.runCommand(["setVariable", "IMAGE_ROOTFS_SIZE", str(image_rootfs_size)])
 
     def set_incompatible_license(self, incompat_license):
-        self.server.runCommand(["setVariable", "INCOMPATIBLE_LICENSE", incompat_license])
+        self.runCommand(["setVariable", "INCOMPATIBLE_LICENSE_HOB", incompat_license])
 
     def set_extra_config(self, extra_setting):
         for key in extra_setting.keys():
             value = extra_setting[key]
-            self.server.runCommand(["setVariable", key, value])
+            self.runCommand(["setVariable", key, value])
+
+    def set_config_filter(self, config_filter):
+        self.runCommand(["setConfFilter", config_filter])
 
     def set_http_proxy(self, http_proxy):
-        self.server.runCommand(["setVariable", "http_proxy", http_proxy])
+        self.runCommand(["setVariable", "http_proxy", http_proxy])
 
     def set_https_proxy(self, https_proxy):
-        self.server.runCommand(["setVariable", "https_proxy", https_proxy])
+        self.runCommand(["setVariable", "https_proxy", https_proxy])
 
     def set_ftp_proxy(self, ftp_proxy):
-        self.server.runCommand(["setVariable", "ftp_proxy", ftp_proxy])
-
-    def set_all_proxy(self, all_proxy):
-        self.server.runCommand(["setVariable", "all_proxy", all_proxy])
+        self.runCommand(["setVariable", "ftp_proxy", ftp_proxy])
 
     def set_git_proxy(self, host, port):
-        self.server.runCommand(["setVariable", "GIT_PROXY_HOST", host])
-        self.server.runCommand(["setVariable", "GIT_PROXY_PORT", port])
+        self.runCommand(["setVariable", "GIT_PROXY_HOST", host])
+        self.runCommand(["setVariable", "GIT_PROXY_PORT", port])
 
     def set_cvs_proxy(self, host, port):
-        self.server.runCommand(["setVariable", "CVS_PROXY_HOST", host])
-        self.server.runCommand(["setVariable", "CVS_PROXY_PORT", port])
+        self.runCommand(["setVariable", "CVS_PROXY_HOST", host])
+        self.runCommand(["setVariable", "CVS_PROXY_PORT", port])
 
     def request_package_info(self):
         self.commands_async.append(self.SUB_GENERATE_PKGINFO)
         self.run_next_command(self.POPULATE_PACKAGEINFO)
 
+    def trigger_sanity_check(self):
+        self.commands_async.append(self.SUB_SANITY_CHECK)
+        self.run_next_command(self.SANITY_CHECK)
+
     def generate_configuration(self):
+        self.commands_async.append(self.SUB_PARSE_CONFIG)
         self.commands_async.append(self.SUB_PATH_LAYERS)
         self.commands_async.append(self.SUB_FILES_DISTRO)
         self.commands_async.append(self.SUB_FILES_MACH)
@@ -341,20 +347,22 @@ class HobHandler(gobject.GObject):
         self.commands_async.append(self.SUB_PARSE_CONFIG)
         self.commands_async.append(self.SUB_GNERATE_TGTS)
         self.run_next_command(self.GENERATE_RECIPES)
-                 
-    def generate_packages(self, tgts):
+
+    def generate_packages(self, tgts, default_task="build"):
         targets = []
         targets.extend(tgts)
         self.recipe_queue = targets
+        self.default_task = default_task
         self.commands_async.append(self.SUB_PARSE_CONFIG)
         self.commands_async.append(self.SUB_BUILD_RECIPES)
         self.run_next_command(self.GENERATE_PACKAGES)
 
-    def generate_image(self, tgts, hob_image, hob_toolchain, toolchain_packages=[]):
-        self.package_queue = tgts
-        self.hob_image = hob_image
-        self.hob_toolchain = hob_toolchain
+    def generate_image(self, image, toolchain, image_packages=[], toolchain_packages=[], default_task="build"):
+        self.image = image
+        self.toolchain = toolchain
+        self.package_queue = image_packages
         self.toolchain_packages = toolchain_packages
+        self.default_task = default_task
         self.commands_async.append(self.SUB_PARSE_CONFIG)
         self.commands_async.append(self.SUB_BUILD_IMAGE)
         self.run_next_command(self.GENERATE_IMAGE)
@@ -368,16 +376,16 @@ class HobHandler(gobject.GObject):
         self.building = False
 
     def cancel_parse(self):
-        self.server.runCommand(["stateStop"])
+        self.runCommand(["stateStop"])
 
     def cancel_build(self, force=False):
         if force:
             # Force the cooker to stop as quickly as possible
-            self.server.runCommand(["stateStop"])
+            self.runCommand(["stateStop"])
         else:
             # Wait for tasks to complete before shutting down, this helps
             # leave the workdir in a usable state
-            self.server.runCommand(["stateShutdown"])
+            self.runCommand(["stateShutdown"])
 
     def reset_build(self):
         self.build.reset()
@@ -392,19 +400,19 @@ class HobHandler(gobject.GObject):
     def get_parameters(self):
         # retrieve the parameters from bitbake
         params = {}
-        params["core_base"] = self.server.runCommand(["getVariable", "COREBASE"]) or ""
+        params["core_base"] = self.runCommand(["getVariable", "COREBASE"]) or ""
         hob_layer = params["core_base"] + "/meta-hob"
-        params["layer"] = self.server.runCommand(["getVariable", "BBLAYERS"]) or ""
+        params["layer"] = self.runCommand(["getVariable", "BBLAYERS"]) or ""
         if hob_layer not in params["layer"].split():
             params["layer"] += (" " + hob_layer)
-        params["dldir"] = self.server.runCommand(["getVariable", "DL_DIR"]) or ""
-        params["machine"] = self.server.runCommand(["getVariable", "MACHINE"]) or ""
-        params["distro"] = self.server.runCommand(["getVariable", "DISTRO"]) or "defaultsetup"
-        params["pclass"] = self.server.runCommand(["getVariable", "PACKAGE_CLASSES"]) or ""
-        params["sstatedir"] = self.server.runCommand(["getVariable", "SSTATE_DIR"]) or ""
-        params["sstatemirror"] = self.server.runCommand(["getVariable", "SSTATE_MIRROR"]) or ""
+        params["dldir"] = self.runCommand(["getVariable", "DL_DIR"]) or ""
+        params["machine"] = self.runCommand(["getVariable", "MACHINE"]) or ""
+        params["distro"] = self.runCommand(["getVariable", "DISTRO"]) or "defaultsetup"
+        params["pclass"] = self.runCommand(["getVariable", "PACKAGE_CLASSES"]) or ""
+        params["sstatedir"] = self.runCommand(["getVariable", "SSTATE_DIR"]) or ""
+        params["sstatemirror"] = self.runCommand(["getVariable", "SSTATE_MIRROR"]) or ""
 
-        num_threads = self.server.runCommand(["getCpuCount"])
+        num_threads = self.runCommand(["getCpuCount"])
         if not num_threads:
             num_threads = 1
             max_threads = 65536
@@ -417,7 +425,7 @@ class HobHandler(gobject.GObject):
                 max_threads = 65536
         params["max_threads"] = max_threads
 
-        bbthread = self.server.runCommand(["getVariable", "BB_NUMBER_THREADS"])
+        bbthread = self.runCommand(["getVariable", "BB_NUMBER_THREADS"])
         if not bbthread:
             bbthread = num_threads
         else:
@@ -427,7 +435,7 @@ class HobHandler(gobject.GObject):
                 bbthread = num_threads
         params["bbthread"] = bbthread
 
-        pmake = self.server.runCommand(["getVariable", "PARALLEL_MAKE"])
+        pmake = self.runCommand(["getVariable", "PARALLEL_MAKE"])
         if not pmake:
             pmake = num_threads
         elif isinstance(pmake, int):
@@ -439,9 +447,9 @@ class HobHandler(gobject.GObject):
                 pmake = num_threads
         params["pmake"] = "-j %s" % pmake
 
-        params["image_addr"] = self.server.runCommand(["getVariable", "DEPLOY_DIR_IMAGE"]) or ""
+        params["image_addr"] = self.runCommand(["getVariable", "DEPLOY_DIR_IMAGE"]) or ""
 
-        image_extra_size = self.server.runCommand(["getVariable", "IMAGE_ROOTFS_EXTRA_SPACE"])
+        image_extra_size = self.runCommand(["getVariable", "IMAGE_ROOTFS_EXTRA_SPACE"])
         if not image_extra_size:
             image_extra_size = 0
         else:
@@ -451,7 +459,7 @@ class HobHandler(gobject.GObject):
                 image_extra_size = 0
         params["image_extra_size"] = image_extra_size
 
-        image_rootfs_size = self.server.runCommand(["getVariable", "IMAGE_ROOTFS_SIZE"])
+        image_rootfs_size = self.runCommand(["getVariable", "IMAGE_ROOTFS_SIZE"])
         if not image_rootfs_size:
             image_rootfs_size = 0
         else:
@@ -461,7 +469,7 @@ class HobHandler(gobject.GObject):
                 image_rootfs_size = 0
         params["image_rootfs_size"] = image_rootfs_size
 
-        image_overhead_factor = self.server.runCommand(["getVariable", "IMAGE_OVERHEAD_FACTOR"])
+        image_overhead_factor = self.runCommand(["getVariable", "IMAGE_OVERHEAD_FACTOR"])
         if not image_overhead_factor:
             image_overhead_factor = 1
         else:
@@ -471,36 +479,39 @@ class HobHandler(gobject.GObject):
                 image_overhead_factor = 1
         params['image_overhead_factor'] = image_overhead_factor
 
-        params["incompat_license"] = self._remove_redundant(self.server.runCommand(["getVariable", "INCOMPATIBLE_LICENSE"]) or "")
-        params["sdk_machine"] = self.server.runCommand(["getVariable", "SDKMACHINE"]) or self.server.runCommand(["getVariable", "SDK_ARCH"]) or ""
+        params["incompat_license"] = self._remove_redundant(self.runCommand(["getVariable", "INCOMPATIBLE_LICENSE"]) or "")
+        params["sdk_machine"] = self.runCommand(["getVariable", "SDKMACHINE"]) or self.runCommand(["getVariable", "SDK_ARCH"]) or ""
 
-        params["image_fstypes"] = self._remove_redundant(self.server.runCommand(["getVariable", "IMAGE_FSTYPES"]) or "")
+        params["image_fstypes"] = self._remove_redundant(self.runCommand(["getVariable", "IMAGE_FSTYPES"]) or "")
 
-        params["image_types"] = self._remove_redundant(self.server.runCommand(["getVariable", "IMAGE_TYPES"]) or "")
+        params["image_types"] = self._remove_redundant(self.runCommand(["getVariable", "IMAGE_TYPES"]) or "")
 
-        params["conf_version"] = self.server.runCommand(["getVariable", "CONF_VERSION"]) or ""
-        params["lconf_version"] = self.server.runCommand(["getVariable", "LCONF_VERSION"]) or ""
+        params["conf_version"] = self.runCommand(["getVariable", "CONF_VERSION"]) or ""
+        params["lconf_version"] = self.runCommand(["getVariable", "LCONF_VERSION"]) or ""
 
-        params["runnable_image_types"] = self._remove_redundant(self.server.runCommand(["getVariable", "RUNNABLE_IMAGE_TYPES"]) or "")
-        params["runnable_machine_patterns"] = self._remove_redundant(self.server.runCommand(["getVariable", "RUNNABLE_MACHINE_PATTERNS"]) or "")
-        params["deployable_image_types"] = self._remove_redundant(self.server.runCommand(["getVariable", "DEPLOYABLE_IMAGE_TYPES"]) or "")
-        params["tmpdir"] = self.server.runCommand(["getVariable", "TMPDIR"]) or ""
-        params["distro_version"] = self.server.runCommand(["getVariable", "DISTRO_VERSION"]) or ""
-        params["target_os"] = self.server.runCommand(["getVariable", "TARGET_OS"]) or ""
-        params["target_arch"] = self.server.runCommand(["getVariable", "TARGET_ARCH"]) or ""
-        params["tune_pkgarch"] = self.server.runCommand(["getVariable", "TUNE_PKGARCH"])  or ""
-        params["bb_version"] = self.server.runCommand(["getVariable", "BB_MIN_VERSION"]) or ""
-        params["tune_arch"] = self.server.runCommand(["getVariable", "TUNE_ARCH"]) or ""
+        params["runnable_image_types"] = self._remove_redundant(self.runCommand(["getVariable", "RUNNABLE_IMAGE_TYPES"]) or "")
+        params["runnable_machine_patterns"] = self._remove_redundant(self.runCommand(["getVariable", "RUNNABLE_MACHINE_PATTERNS"]) or "")
+        params["deployable_image_types"] = self._remove_redundant(self.runCommand(["getVariable", "DEPLOYABLE_IMAGE_TYPES"]) or "")
+        params["kernel_image_type"] = self.runCommand(["getVariable", "KERNEL_IMAGETYPE"]) or ""
+        params["tmpdir"] = self.runCommand(["getVariable", "TMPDIR"]) or ""
+        params["distro_version"] = self.runCommand(["getVariable", "DISTRO_VERSION"]) or ""
+        params["target_os"] = self.runCommand(["getVariable", "TARGET_OS"]) or ""
+        params["target_arch"] = self.runCommand(["getVariable", "TARGET_ARCH"]) or ""
+        params["tune_pkgarch"] = self.runCommand(["getVariable", "TUNE_PKGARCH"])  or ""
+        params["bb_version"] = self.runCommand(["getVariable", "BB_MIN_VERSION"]) or ""
 
-        params["git_proxy_host"] = self.server.runCommand(["getVariable", "GIT_PROXY_HOST"]) or ""
-        params["git_proxy_port"] = self.server.runCommand(["getVariable", "GIT_PROXY_PORT"]) or ""
+        params["default_task"] = self.runCommand(["getVariable", "BB_DEFAULT_TASK"]) or "build"
 
-        params["http_proxy"] = self.server.runCommand(["getVariable", "http_proxy"]) or ""
-        params["ftp_proxy"] = self.server.runCommand(["getVariable", "ftp_proxy"]) or ""
-        params["https_proxy"] = self.server.runCommand(["getVariable", "https_proxy"]) or ""
-        params["all_proxy"] = self.server.runCommand(["getVariable", "all_proxy"]) or ""
+        params["git_proxy_host"] = self.runCommand(["getVariable", "GIT_PROXY_HOST"]) or ""
+        params["git_proxy_port"] = self.runCommand(["getVariable", "GIT_PROXY_PORT"]) or ""
 
-        params["cvs_proxy_host"] = self.server.runCommand(["getVariable", "CVS_PROXY_HOST"]) or ""
-        params["cvs_proxy_port"] = self.server.runCommand(["getVariable", "CVS_PROXY_PORT"]) or ""
+        params["http_proxy"] = self.runCommand(["getVariable", "http_proxy"]) or ""
+        params["ftp_proxy"] = self.runCommand(["getVariable", "ftp_proxy"]) or ""
+        params["https_proxy"] = self.runCommand(["getVariable", "https_proxy"]) or ""
 
+        params["cvs_proxy_host"] = self.runCommand(["getVariable", "CVS_PROXY_HOST"]) or ""
+        params["cvs_proxy_port"] = self.runCommand(["getVariable", "CVS_PROXY_PORT"]) or ""
+
+        params["image_white_pattern"] = self.runCommand(["getVariable", "BBUI_IMAGE_WHITE_PATTERN"]) or ""
+        params["image_black_pattern"] = self.runCommand(["getVariable", "BBUI_IMAGE_BLACK_PATTERN"]) or ""
         return params

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

@@ -34,7 +34,7 @@ class PackageListModel(gtk.TreeStore):
     providing convenience functions to access gtk.TreeModel subclasses which
     provide filtered views of the data.
     """
-    (COL_NAME, COL_VER, COL_REV, COL_RNM, COL_SEC, COL_SUM, COL_RDEP, COL_RPROV, COL_SIZE, COL_BINB, COL_INC, COL_FADE_INC) = range(12)
+    (COL_NAME, COL_VER, COL_REV, COL_RNM, COL_SEC, COL_SUM, COL_RDEP, COL_RPROV, COL_SIZE, COL_BINB, COL_INC, COL_FADE_INC, COL_FONT) = range(13)
 
     __gsignals__ = {
         "package-selection-changed" : (gobject.SIGNAL_RUN_LAST,
@@ -42,6 +42,8 @@ class PackageListModel(gtk.TreeStore):
                                 ()),
     }
 
+    __toolchain_required_packages__ = ["task-core-standalone-sdk-target", "task-core-standalone-sdk-target-dbg"]
+
     def __init__(self):
 
         self.contents = None
@@ -63,7 +65,8 @@ class PackageListModel(gtk.TreeStore):
                                 gobject.TYPE_STRING,
                                 gobject.TYPE_STRING,
                                 gobject.TYPE_BOOLEAN,
-                                gobject.TYPE_BOOLEAN)
+                                gobject.TYPE_BOOLEAN,
+                                gobject.TYPE_STRING)
 
 
     """
@@ -187,7 +190,7 @@ class PackageListModel(gtk.TreeStore):
                      self.COL_SEC, section, self.COL_SUM, summary,
                      self.COL_RDEP, rdep + ' ' + rrec,
                      self.COL_RPROV, rprov, self.COL_SIZE, size,
-                     self.COL_BINB, "", self.COL_INC, False)
+                     self.COL_BINB, "", self.COL_INC, False, self.COL_FONT, '10')
 
     """
     Check whether the item at item_path is included or not
@@ -389,7 +392,7 @@ class PackageListModel(gtk.TreeStore):
                     child_it = self.iter_next(child_it)
             it = self.iter_next(it)
 
-        return packagelist
+        return list(set(packagelist + self.__toolchain_required_packages__));
     """
     Return the selected package size, unit is B.
     """
@@ -453,7 +456,7 @@ class RecipeListModel(gtk.ListStore):
     """
     (COL_NAME, COL_DESC, COL_LIC, COL_GROUP, COL_DEPS, COL_BINB, COL_TYPE, COL_INC, COL_IMG, COL_INSTALL, COL_PN, COL_FADE_INC) = range(12)
 
-    __dummy_image__ = "Create your own image"
+    __custom_image__ = "Create your own image"
 
     __gsignals__ = {
         "recipe-selection-changed" : (gobject.SIGNAL_RUN_LAST,
@@ -562,12 +565,14 @@ class RecipeListModel(gtk.ListStore):
         self.clear()
 
         # dummy image for prompt
-        self.set(self.append(), self.COL_NAME, self.__dummy_image__,
-                 self.COL_DESC, "",
+        self.set(self.append(), self.COL_NAME, self.__custom_image__,
+                 self.COL_DESC, "Use the 'View recipes' and 'View packages' " \
+                                "options to select what you want to include " \
+                                "in your image.",
                  self.COL_LIC, "", self.COL_GROUP, "",
                  self.COL_DEPS, "", self.COL_BINB, "",
                  self.COL_TYPE, "image", self.COL_INC, False,
-                 self.COL_IMG, False, self.COL_INSTALL, "", self.COL_PN, self.__dummy_image__)
+                 self.COL_IMG, False, self.COL_INSTALL, "", self.COL_PN, self.__custom_image__)
 
         for item in event_model["pn"]:
             name = item
@@ -615,22 +620,6 @@ class RecipeListModel(gtk.ListStore):
     def path_included(self, item_path):
         return self[item_path][self.COL_INC]
 
-    """
-    Append a certain image into the combobox
-    """
-    def image_list_append(self, name, deps, install):
-        # check whether a certain image is there
-        if not name or self.find_path_for_item(name):
-            return
-        it = self.append()
-        self.set(it, self.COL_NAME, name, self.COL_DESC, "",
-                 self.COL_LIC, "", self.COL_GROUP, "",
-                 self.COL_DEPS, deps, self.COL_BINB, "",
-                 self.COL_TYPE, "image", self.COL_INC, False,
-                 self.COL_IMG, False, self.COL_INSTALL, install,
-                 self.COL_PN, name)
-        self.pn_path[name] = self.get_path(it)
-
     """
     Add this item, and any of its dependencies, to the image contents
     """

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

@@ -23,6 +23,7 @@ import os
 import os.path
 import sys
 import pango, pangocairo
+import cairo
 import math
 
 from bb.ui.crumbs.hobcolor import HobColors
@@ -88,6 +89,7 @@ class hcc:
         "cpio.xz"       : ["cpio.xz"],
         "vmdk"          : ["vmdk"],
         "cpio.lzma"     : ["cpio.lzma"],
+        "elf"           : ["elf"],
     }
 
 class HobViewTable (gtk.VBox):
@@ -119,6 +121,7 @@ class HobViewTable (gtk.VBox):
         self.table_tree.set_headers_clickable(True)
         self.table_tree.set_enable_search(True)
         self.table_tree.set_rules_hint(True)
+        self.table_tree.set_enable_tree_lines(True)
         self.table_tree.get_selection().set_mode(gtk.SELECTION_SINGLE)
         self.toggle_columns = []
         self.table_tree.connect("row-activated", self.row_activated_cb)
@@ -140,6 +143,8 @@ class HobViewTable (gtk.VBox):
                 cell = gtk.CellRendererText()
                 col.pack_start(cell, True)
                 col.set_attributes(cell, text=column['col_id'])
+                if 'col_t_id' in column.keys():
+                    col.add_attribute(cell, 'font', column['col_t_id'])
             elif column['col_style'] == 'check toggle':
                 cell = HobCellRendererToggle()
                 cell.set_property('activatable', True)
@@ -149,6 +154,8 @@ class HobViewTable (gtk.VBox):
                 col.pack_end(cell, True)
                 col.set_attributes(cell, active=column['col_id'])
                 self.toggle_columns.append(column['col_name'])
+                if 'col_group' in column.keys():
+                    col.set_cell_data_func(cell, self.set_group_number_cb)
             elif column['col_style'] == 'radio toggle':
                 cell = gtk.CellRendererToggle()
                 cell.set_property('activatable', True)
@@ -162,10 +169,11 @@ class HobViewTable (gtk.VBox):
                 cell = gtk.CellRendererText()
                 col.pack_start(cell, True)
                 col.set_cell_data_func(cell, self.display_binb_cb, column['col_id'])
+                if 'col_t_id' in column.keys():
+                    col.add_attribute(cell, 'font', column['col_t_id'])
 
         scroll = gtk.ScrolledWindow()
         scroll.set_policy(gtk.POLICY_NEVER, gtk.POLICY_ALWAYS)
-        scroll.set_shadow_type(gtk.SHADOW_IN)
         scroll.add(self.table_tree)
         self.pack_start(scroll, True, True, 0)
 
@@ -175,7 +183,8 @@ class HobViewTable (gtk.VBox):
         if binb:
             bin = binb.split(', ')
             cell.set_property('text', bin[0])
-
+        else:
+            cell.set_property('text', "")
         return True
 
     def set_model(self, tree_model):
@@ -204,6 +213,15 @@ class HobViewTable (gtk.VBox):
     def stop_cell_fadeinout_cb(self, ctrl, cell, tree):
         self.emit("cell-fadeinout-stopped", ctrl, cell, tree)
 
+    def set_group_number_cb(self, col, cell, model, iter):
+        if model and (model.iter_parent(iter) == None):
+            cell.cell_attr["number_of_children"] = model.iter_n_children(iter)
+        else:
+            cell.cell_attr["number_of_children"] = 0
+
+    def connect_group_selection(self, cb_func):
+        self.table_tree.get_selection().connect("changed", cb_func)
+
 """
 A method to calculate a softened value for the colour of widget when in the
 provided state.
@@ -380,363 +398,95 @@ class HobInfoButton(gtk.EventBox):
     def mouse_out_cb(self, widget, event):
         self.image.set_from_file(hic.ICON_INFO_DISPLAY_FILE)
 
-class HobTabBar(gtk.DrawingArea):
-    __gsignals__ = {
-        "blank-area-changed" : (gobject.SIGNAL_RUN_LAST,
-                                gobject.TYPE_NONE,
-                               (gobject.TYPE_INT,
-                                gobject.TYPE_INT,
-                                gobject.TYPE_INT,
-                                gobject.TYPE_INT,)),
-
-        "tab-switched" : (gobject.SIGNAL_RUN_LAST,
-                          gobject.TYPE_NONE,
-                         (gobject.TYPE_INT,)),
-    }
-
-    def __init__(self):
+class HobIndicator(gtk.DrawingArea):
+    def __init__(self, count):
         gtk.DrawingArea.__init__(self)
-        self.children = []
+        # Set no window for transparent background
+        self.set_has_window(False)
+        self.set_size_request(38,38)
+        # We need to pass through button clicks
+        self.add_events(gtk.gdk.BUTTON_PRESS_MASK | gtk.gdk.BUTTON_RELEASE_MASK)
 
-        self.tab_width = 140
-        self.tab_height = 52
-        self.tab_x = 10
-        self.tab_y = 0
+        self.connect('expose-event', self.expose)
 
-        self.width = 500
-        self.height = 53
-        self.tab_w_ratio = 140 * 1.0/500
-        self.tab_h_ratio = 52 * 1.0/53
-        self.set_size_request(self.width, self.height)
+        self.count = count
+        self.color = HobColors.GRAY
 
-        self.current_child = None
-        self.font = self.get_style().font_desc
-        self.font.set_size(pango.SCALE * 13) 
-        self.update_children_text_layout_and_bg_color()
+    def expose(self, widget, event):
+        if self.count and self.count > 0:
+            ctx = widget.window.cairo_create()
 
-        self.blank_rectangle = None
-        self.tab_pressed = False
+            x, y, w, h = self.allocation
 
-        self.set_property('can-focus', True)
-        self.set_events(gtk.gdk.EXPOSURE_MASK | gtk.gdk.POINTER_MOTION_MASK |
-                        gtk.gdk.BUTTON1_MOTION_MASK | gtk.gdk.BUTTON_PRESS_MASK |
-                        gtk.gdk.BUTTON_RELEASE_MASK)
+            ctx.set_operator(cairo.OPERATOR_OVER)
+            ctx.set_source_color(gtk.gdk.color_parse(self.color))
+            ctx.translate(w/2, h/2)
+            ctx.arc(x, y, min(w,h)/2 - 2, 0, 2*math.pi)
+            ctx.fill_preserve()
 
-        self.connect("expose-event", self.on_draw)
-        self.connect("button-press-event", self.button_pressed_cb)
-        self.connect("button-release-event", self.button_released_cb)
-        self.connect("query-tooltip", self.query_tooltip_cb)
-        self.show_all()
+            layout = self.create_pango_layout(str(self.count))
+            textw, texth = layout.get_pixel_size()
+            x = (w/2)-(textw/2) + x
+            y = (h/2) - (texth/2) + y
+            ctx.move_to(x, y)
+            self.window.draw_layout(self.style.light_gc[gtk.STATE_NORMAL], int(x), int(y), layout)
 
-    def button_released_cb(self, widget, event):
-        self.tab_pressed = False
-        self.queue_draw()
+    def set_count(self, count):
+        self.count = count
 
-    def button_pressed_cb(self, widget, event):
-        if event.type == gtk.gdk._2BUTTON_PRESS:
-            return
-
-        result = False
-        if self.is_focus() or event.type == gtk.gdk.BUTTON_PRESS:
-            x, y = event.get_coords()
-            # check which tab be clicked
-            for child in self.children:
-               if      (child["x"] < x) and (x < child["x"] + self.tab_width) \
-                   and (child["y"] < y) and (y < child["y"] + self.tab_height):
-                   self.current_child = child
-                   result = True
-                   self.grab_focus()
-                   break
-
-            # check the blank area is focus in or not
-            if (self.blank_rectangle) and (self.blank_rectangle.x > 0) and (self.blank_rectangle.y > 0):
-                if      (self.blank_rectangle.x < x) and (x < self.blank_rectangle.x + self.blank_rectangle.width) \
-                    and (self.blank_rectangle.y < y) and (y < self.blank_rectangle.y + self.blank_rectangle.height):
-                   self.grab_focus()
-
-        if result == True:
-            page = self.current_child["toggled_page"]
-            self.emit("tab-switched", page)
-            self.tab_pressed = True
-            self.queue_draw()
-
-    def update_children_size(self):
-        # calculate the size of tabs
-        self.tab_width = int(self.width * self.tab_w_ratio)
-        self.tab_height = int(self.height * self.tab_h_ratio)
-        for i, child in enumerate(self.children):
-            child["x"] = self.tab_x + i * self.tab_width
-            child["y"] = self.tab_y
-
-        if self.blank_rectangle:
-            self.resize_blank_rectangle()
-
-    def resize_blank_rectangle(self):
-        width = self.width - self.tab_width * len(self.children) - self.tab_x
-        x = self.tab_x + self.tab_width * len(self.children)
-        hpadding = vpadding = 5
-        self.blank_rectangle = self.set_blank_size(x + hpadding, self.tab_y + vpadding,
-            width - 2 * hpadding, self.tab_height - 2 * vpadding)
-
-    def update_children_text_layout_and_bg_color(self):
-        style = self.get_style().copy()
-        color = style.base[gtk.STATE_NORMAL]
-        for child in self.children:
-            pangolayout = self.create_pango_layout(child["title"])
-            pangolayout.set_font_description(self.font)
-            child["title_layout"] = pangolayout
-            child["r"] = color.red
-            child["g"] = color.green
-            child["b"] = color.blue
-
-    def append_tab_child(self, title, page, tooltip=""):
-        num = len(self.children) + 1
-        self.tab_width = self.tab_width * len(self.children) / num
-
-        i = 0
-        for i, child in enumerate(self.children):
-            child["x"] = self.tab_x + i * self.tab_width
-            i += 1
-
-        x = self.tab_x + i * self.tab_width
-        y = self.tab_y
-        pangolayout = self.create_pango_layout(title)
-        pangolayout.set_font_description(self.font)
-        color = self.style.base[gtk.STATE_NORMAL]
-        new_one = {
-            "x" : x,
-            "y" : y,
-            "r" : color.red,
-            "g" : color.green,
-            "b" : color.blue,
-            "title_layout" : pangolayout,
-            "toggled_page" : page,
-            "title"        : title,
-            "indicator_show"   : False,
-            "indicator_number" : 0,
-            "tooltip_markup"   : tooltip,
-        }
-        self.children.append(new_one)
-        if tooltip and (not self.props.has_tooltip):
-            self.props.has_tooltip = True
-        # set the default current child
-        if not self.current_child:
-            self.current_child = new_one
-
-    def on_draw(self, widget, event):
-        cr = widget.window.cairo_create()
-
-        self.width = self.allocation.width
-        self.height = self.allocation.height
-
-        self.update_children_size()
-
-        self.draw_background(cr)
-        self.draw_toggled_tab(cr)
-
-        for child in self.children:
-            if child["indicator_show"] == True:
-                self.draw_indicator(cr, child)
-
-        self.draw_tab_text(cr)
-
-    def draw_background(self, cr):
-        style = self.get_style()
-
-        if self.is_focus():
-            cr.set_source_color(style.base[gtk.STATE_SELECTED])
+    def set_active(self, active):
+        if active:
+            self.color = HobColors.DEEP_RED
         else:
-            cr.set_source_color(style.base[gtk.STATE_NORMAL])
+            self.color = HobColors.GRAY
 
-        y = 6
-        h = self.height - 6 - 1
-        gap = 1
+class HobTabLabel(gtk.HBox):
+    def __init__(self, text, count=0):
+        gtk.HBox.__init__(self, False, 0)
+        self.indicator = HobIndicator(count)
+        self.indicator.show()
+        self.pack_end(self.indicator, False, False)
+        self.lbl = gtk.Label(text)
+        self.lbl.set_alignment(0.0, 0.5)
+        self.lbl.show()
+        self.pack_end(self.lbl, True, True, 6)
 
-        w = self.children[0]["x"]
-        cr.set_source_color(gtk.gdk.color_parse(HobColors.GRAY))
-        cr.rectangle(0, y, w - gap, h) # start rectangle
-        cr.fill()
+    def set_count(self, count):
+        self.indicator.set_count(count)
 
-        cr.set_source_color(style.base[gtk.STATE_NORMAL])
-        cr.rectangle(w - gap, y, w, h) #first gap
-        cr.fill()
-
-        w = self.tab_width
-        for child in self.children:
-            x = child["x"]
-            cr.set_source_color(gtk.gdk.color_parse(HobColors.GRAY))
-            cr.rectangle(x, y, w - gap, h) # tab rectangle
-            cr.fill()
-            cr.set_source_color(style.base[gtk.STATE_NORMAL])
-            cr.rectangle(x + w - gap, y, w, h) # gap
-            cr.fill()
-
-        cr.set_source_color(gtk.gdk.color_parse(HobColors.GRAY))
-        cr.rectangle(x + w, y, self.width - x - w, h) # last rectangle
-        cr.fill()
-
-    def draw_tab_text(self, cr):
-        style = self.get_style()
-
-        for child in self.children:
-            pangolayout = child["title_layout"]
-            if pangolayout:
-                fontw, fonth = pangolayout.get_pixel_size()
-                # center pos
-                off_x = (self.tab_width - fontw) / 2
-                off_y = (self.tab_height - fonth) / 2
-                x = child["x"] + off_x
-                y = child["y"] + off_y
-                if not child == self.current_child:
-                    self.window.draw_layout(self.style.fg_gc[gtk.STATE_NORMAL], int(x), int(y), pangolayout, gtk.gdk.Color(HobColors.WHITE))
-                else:
-                    self.window.draw_layout(self.style.fg_gc[gtk.STATE_NORMAL], int(x), int(y), pangolayout)
-
-    def draw_toggled_tab(self, cr):
-        if not self.current_child:
-            return
-        x = self.current_child["x"]
-        y = self.current_child["y"]
-        width = self.tab_width
-        height = self.tab_height
-        style = self.get_style()
-        color = style.base[gtk.STATE_NORMAL]
-
-        r = height / 10
-        if self.tab_pressed == True:
-            for xoff, yoff, c1, c2 in [(1, 0, HobColors.SLIGHT_DARK, HobColors.DARK), (2, 0, HobColors.GRAY, HobColors.LIGHT_GRAY)]:
-                cr.set_source_color(gtk.gdk.color_parse(c1))
-                cr.move_to(x + xoff, y + height + yoff)
-                cr.line_to(x + xoff, r + yoff)
-                cr.arc(x + r + xoff, y + r + yoff, r, math.pi, 1.5*math.pi)
-                cr.move_to(x + r + xoff, y + yoff)
-                cr.line_to(x + width - r + xoff, y + yoff)
-                cr.arc(x + width - r + xoff, y + r + yoff, r, 1.5*math.pi, 2*math.pi)
-                cr.stroke()
-                cr.set_source_color(gtk.gdk.color_parse(c2))
-                cr.move_to(x + width + xoff, r + yoff)
-                cr.line_to(x + width + xoff, y + height + yoff)
-                cr.line_to(x + xoff, y + height + yoff)
-                cr.stroke()
-            x = x + 2
-            y = y + 2
-        cr.set_source_rgba(color.red, color.green, color.blue, 1)
-        cr.move_to(x + r, y)
-        cr.line_to(x + width - r , y)
-        cr.arc(x + width - r, y + r, r, 1.5*math.pi, 2*math.pi)
-        cr.move_to(x + width, r)
-        cr.line_to(x + width, y + height)
-        cr.line_to(x, y + height)
-        cr.line_to(x, r)
-        cr.arc(x + r, y + r, r, math.pi, 1.5*math.pi)
-        cr.fill()
-
-    def draw_indicator(self, cr, child):
-        text = ("%d" % child["indicator_number"])
-        layout = self.create_pango_layout(text)
-        layout.set_font_description(self.font)
-        textw, texth = layout.get_pixel_size()
-        # draw the back round area
-        tab_x = child["x"]
-        tab_y = child["y"]
-        dest_w = int(32 * self.tab_w_ratio)
-        dest_h = int(32 * self.tab_h_ratio)
-        if dest_h < self.tab_height:
-            dest_w = dest_h
-        # x position is offset(tab_width*3/4 - icon_width/2) + start_pos(tab_x)
-        x = tab_x + self.tab_width * 3/4 - dest_w/2
-        y = tab_y + self.tab_height/2 - dest_h/2
-
-        r = min(dest_w, dest_h)/2
-        if not child == self.current_child:
-            color = cr.set_source_color(gtk.gdk.color_parse(HobColors.DEEP_RED))
-        else:
-            color = cr.set_source_color(gtk.gdk.color_parse(HobColors.GRAY))
-        # check round back area can contain the text or not
-        back_round_can_contain_width = float(2 * r * 0.707)
-        if float(textw) > back_round_can_contain_width:
-            xoff = (textw - int(back_round_can_contain_width)) / 2
-            cr.move_to(x + r - xoff, y + r + r)
-            cr.arc((x + r - xoff), (y + r), r, 0.5*math.pi, 1.5*math.pi)
-            cr.fill() # left half round
-            cr.rectangle((x + r - xoff), y, 2 * xoff, 2 * r)
-            cr.fill() # center rectangle
-            cr.arc((x + r + xoff), (y + r), r, 1.5*math.pi, 0.5*math.pi)
-            cr.fill() # right half round
-        else:
-            cr.arc((x + r), (y + r), r, 0, 2*math.pi)
-            cr.fill()
-        # draw the number text
-        x = x + (dest_w/2)-(textw/2)
-        y = y + (dest_h/2) - (texth/2)
-        cr.move_to(x, y)
-        self.window.draw_layout(self.style.fg_gc[gtk.STATE_NORMAL], int(x), int(y), layout, gtk.gdk.Color(HobColors.WHITE))
-
-    def show_indicator_icon(self, child, number):
-        child["indicator_show"] = True
-        child["indicator_number"] = number
-        self.queue_draw()
-
-    def hide_indicator_icon(self, child):
-        child["indicator_show"] = False
-        self.queue_draw()
-
-    def set_blank_size(self, x, y, w, h):
-        if not self.blank_rectangle or self.blank_rectangle.x != x or self.blank_rectangle.width != w:
-            self.emit("blank-area-changed", x, y, w, h)
-
-        return gtk.gdk.Rectangle(x, y, w, h)
-
-    def query_tooltip_cb(self, widget, x, y, keyboardtip, tooltip):
-        if keyboardtip or (not tooltip):
-            return False
-        # check which tab be clicked
-        for child in self.children:
-           if      (child["x"] < x) and (x < child["x"] + self.tab_width) \
-               and (child["y"] < y) and (y < child["y"] + self.tab_height):
-               tooltip.set_markup(child["tooltip_markup"])
-               return True
-
-        return False
-
-class HobNotebook(gtk.VBox):
+    def set_active(self, active=True):
+        self.indicator.set_active(active)
 
+class HobNotebook(gtk.Notebook):
     def __init__(self):
-        gtk.VBox.__init__(self, False, 0)
+        gtk.Notebook.__init__(self)
+        self.set_property('homogeneous', True)
 
-        self.notebook = gtk.Notebook()
-        self.notebook.set_property('homogeneous', True)
-        self.notebook.set_property('show-tabs', False)
-
-        self.tabbar = HobTabBar()
-        self.tabbar.connect("tab-switched",   self.tab_switched_cb)
-        self.notebook.connect("page-added",   self.page_added_cb)
-        self.notebook.connect("page-removed", self.page_removed_cb)
+        self.pages = []
 
         self.search = None
         self.search_name = ""
 
-        self.tb = gtk.Table(1, 100, False)
-        self.hbox= gtk.HBox(False, 0)
-        self.hbox.pack_start(self.tabbar, True, True)
-        self.tb.attach(self.hbox, 0, 100, 0, 1)
-
-        self.pack_start(self.tb, False, False)
-        self.pack_start(self.notebook)
+        self.connect("switch-page", self.page_changed_cb)
 
         self.show_all()
 
-    def append_page(self, child, tab_label):
-        self.notebook.set_current_page(self.notebook.append_page(child, tab_label))
+    def page_changed_cb(self, nb, page, page_num):
+        for p, lbl in enumerate(self.pages):
+            if p == page_num:
+                lbl.set_active()
+            else:
+                lbl.set_active(False)
+
+    def append_page(self, child, tab_label, tab_tooltip=None):
+        label = HobTabLabel(tab_label)
+        if tab_tooltip:
+            label.set_tooltip_text(tab_tooltip)
+        label.set_active(False)
+        self.pages.append(label)
+        gtk.Notebook.append_page(self, child, label)
 
     def set_entry(self, name="Search:"):
-        for child in self.tb.get_children(): 
-            if child:
-                self.tb.remove(child)
-
-        hbox_entry = gtk.HBox(False, 0)
-        hbox_entry.show()
-
         self.search = gtk.Entry()
         self.search_name = name
         style = self.search.get_style()
@@ -747,59 +497,20 @@ class HobNotebook(gtk.VBox):
         self.search.set_icon_from_stock(gtk.ENTRY_ICON_SECONDARY, gtk.STOCK_CLEAR)
         self.search.connect("icon-release", self.set_search_entry_clear_cb)
         self.search.show()
-        self.align = gtk.Alignment(xalign=1.0, yalign=0.7)
-        self.align.add(self.search)
-        self.align.show()
-        hbox_entry.pack_end(self.align, False, False)
-        self.tabbar.resize_blank_rectangle()
 
-        self.tb.attach(hbox_entry, 75, 100, 0, 1, xpadding=5)
-        self.tb.attach(self.hbox, 0, 100, 0, 1)
-
-        self.tabbar.connect("blank-area-changed", self.blank_area_resize_cb)
         self.search.connect("focus-in-event", self.set_search_entry_editable_cb)
         self.search.connect("focus-out-event", self.set_search_entry_reset_cb)
- 
-        self.tb.show()
+        self.set_action_widget(self.search, gtk.PACK_END)
 
     def show_indicator_icon(self, title, number):
-        for child in self.tabbar.children:
-            if child["toggled_page"] == -1:
-                continue
-            if child["title"] == title:
-                self.tabbar.show_indicator_icon(child, number)
+        for child in self.pages:
+            if child.lbl.get_label() == title:
+                child.set_count(number)
 
     def hide_indicator_icon(self, title):
-        for child in self.tabbar.children:
-            if child["toggled_page"] == -1:
-                continue
-            if child["title"] == title:
-                self.tabbar.hide_indicator_icon(child)
-
-    def tab_switched_cb(self, widget, page):
-        self.notebook.set_current_page(page)
-
-    def page_added_cb(self, notebook, notebook_child, page):
-        if not notebook:
-            return
-        title = notebook.get_tab_label_text(notebook_child)
-        label = notebook.get_tab_label(notebook_child)
-        tooltip_markup = label.get_tooltip_markup()
-        if not title:
-            return
-        for child in self.tabbar.children:
-            if child["title"] == title:
-                child["toggled_page"] = page
-                return
-        self.tabbar.append_tab_child(title, page, tooltip_markup)
-
-    def page_removed_cb(self, notebook, notebook_child, page, title=""):
-        for child in self.tabbar.children:
-            if child["title"] == title:
-                child["toggled_page"] = -1
-
-    def blank_area_resize_cb(self, widget, request_x, request_y, request_width, request_height):
-        self.search.set_size_request(request_width, request_height)
+        for child in self.pages:
+            if child.lbl.get_label() == title:
+                child.set_count(0)
 
     def set_search_entry_editable_cb(self, search, event):
         search.set_editable(True)
@@ -819,7 +530,14 @@ class HobNotebook(gtk.VBox):
         self.reset_entry(search)
 
     def set_search_entry_clear_cb(self, search, icon_pos, event):
-        self.reset_entry(search)
+        if search.get_editable() == True:
+            search.set_text("")
+
+    def set_page(self, title):
+        for child in self.pages:
+            if child.lbl.get_label() == title:
+                child.grab_focus()
+                self.set_current_page(self.page_num(child))
 
 class HobWarpCellRendererText(gtk.CellRendererText):
     def __init__(self, col_number):
@@ -1057,7 +775,7 @@ class HobCellRendererPixbuf(gtk.CellRendererPixbuf):
             if self.control.is_active():
                 self.control.on_draw_pixbuf_cb(pix, window.cairo_create(), x, y, w, h, True)
             else:
-                self.control.start_run(200, 0, 0, 1000, 200, tree)
+                self.control.start_run(200, 0, 0, 1000, 150, tree)
         else:
             self.control.remove_running_cell_area(cell_area)
             self.control.on_draw_pixbuf_cb(pix, window.cairo_create(), x, y, w, h, False)
@@ -1084,11 +802,17 @@ class HobCellRendererToggle(gtk.CellRendererToggle):
         gtk.CellRendererToggle.__init__(self)
         self.ctrl = HobCellRendererController(is_draw_row=True)
         self.ctrl.running_mode = self.ctrl.MODE_ONE_SHORT
-        self.cell_attr = {"fadeout": False}
+        self.cell_attr = {"fadeout": False, "number_of_children": 0}
 
     def do_render(self, window, widget, background_area, cell_area, expose_area, flags):
         if (not self.ctrl) or (not widget):
             return
+
+        if flags & gtk.CELL_RENDERER_SELECTED:
+            state = gtk.STATE_SELECTED
+        else:
+            state = gtk.STATE_NORMAL
+
         if self.ctrl.is_active():
             path = widget.get_path_at_pos(cell_area.x + cell_area.width/2, cell_area.y + cell_area.height/2)
             # sometimes the parameters of cell_area will be a negative number,such as pull up down the scroll bar
@@ -1097,14 +821,23 @@ class HobCellRendererToggle(gtk.CellRendererToggle):
             path = path[0]
             if path in self.ctrl.running_cell_areas:
                 cr = window.cairo_create()
-                color = gtk.gdk.Color(HobColors.WHITE)
+                color = widget.get_style().base[state]
 
                 row_x, _, row_width, _ = widget.get_visible_rect()
                 border_y = self.get_property("ypad")
                 self.ctrl.on_draw_fadeinout_cb(cr, color, row_x, cell_area.y - border_y, row_width, \
                                                cell_area.height + border_y * 2, self.cell_attr["fadeout"])
+        # draw number of a group
+        if self.cell_attr["number_of_children"]:
+            text = "%d pkg" % self.cell_attr["number_of_children"]
+            pangolayout = widget.create_pango_layout(text)
+            textw, texth = pangolayout.get_pixel_size()
+            x = cell_area.x + (cell_area.width/2) - (textw/2)
+            y = cell_area.y + (cell_area.height/2) - (texth/2)
 
-        return gtk.CellRendererToggle.do_render(self, window, widget, background_area, cell_area, expose_area, flags)
+            widget.style.paint_layout(window, state, True, cell_area, widget, "checkbox", x, y, pangolayout)
+        else:
+            return gtk.CellRendererToggle.do_render(self, window, widget, background_area, cell_area, expose_area, flags)
 
     '''delay: normally delay time is 1000ms
        cell_list: whilch cells need to be render

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

@@ -22,6 +22,7 @@
 
 import gtk
 import glib
+import re
 from bb.ui.crumbs.progressbar import HobProgressBar
 from bb.ui.crumbs.hobcolor import HobColors
 from bb.ui.crumbs.hobwidget import hic, HobImageButton, HobInfoButton, HobAltButton, HobButton
@@ -33,6 +34,9 @@ from bb.ui.crumbs.hobpages import HobPage
 #
 class ImageConfigurationPage (HobPage):
 
+    __dummy_machine__ = "--select a machine--"
+    __dummy_image__   = "--select a base image--"
+
     def __init__(self, builder):
         super(ImageConfigurationPage, self).__init__(builder, "Image configuration")
 
@@ -147,7 +151,6 @@ class ImageConfigurationPage (HobPage):
         self.machine_title_desc.set_markup(mark)
 
         self.machine_combo = gtk.combo_box_new_text()
-        self.machine_combo.set_wrap_width(1)
         self.machine_combo.connect("changed", self.machine_combo_changed_cb)
 
         icon_file = hic.ICON_LAYERS_DISPLAY_FILE
@@ -196,11 +199,12 @@ class ImageConfigurationPage (HobPage):
         self.image_title_desc.set_markup(mark)
 
         self.image_combo = gtk.combo_box_new_text()
-        self.image_combo.set_wrap_width(1)
         self.image_combo_id = self.image_combo.connect("changed", self.image_combo_changed_cb)
 
         self.image_desc = gtk.Label()
         self.image_desc.set_alignment(0.0, 0.5)
+        self.image_desc.set_size_request(360, -1)
+        self.image_desc.set_justify(gtk.JUSTIFY_LEFT)
         self.image_desc.set_line_wrap(True)
 
         # button to view recipes
@@ -259,14 +263,18 @@ class ImageConfigurationPage (HobPage):
 
     def machine_combo_changed_cb(self, machine_combo):
         combo_item = machine_combo.get_active_text()
-        if not combo_item:
+        if not combo_item or combo_item == self.__dummy_machine__:
             return
 
+        # remove __dummy_machine__ item from the store list after first user selection
+        # because it is no longer valid
+        combo_store = machine_combo.get_model()
+        if len(combo_store) and (combo_store[0][0] == self.__dummy_machine__):
+            machine_combo.remove_text(0)
+
         self.builder.configuration.curr_mach = combo_item
         if self.machine_combo_changed_by_manual:
-            self.builder.configuration.selected_image = None
-            self.builder.configuration.selected_recipes = []
-            self.builder.configuration.selected_packages = []
+            self.builder.configuration.clear_selection()
         # reset machine_combo_changed_by_manual
         self.machine_combo_changed_by_manual = True
 
@@ -274,13 +282,13 @@ class ImageConfigurationPage (HobPage):
         self.builder.populate_recipe_package_info_async()
 
     def update_machine_combo(self):
-        all_machines = self.builder.parameters.all_machines
+        all_machines = [self.__dummy_machine__] + self.builder.parameters.all_machines
 
         model = self.machine_combo.get_model()
         model.clear()
         for machine in all_machines:
             self.machine_combo.append_text(machine)
-        self.machine_combo.set_active(-1)
+        self.machine_combo.set_active(0)
 
     def switch_machine_combo(self):
         self.machine_combo_changed_by_manual = False
@@ -291,10 +299,15 @@ class ImageConfigurationPage (HobPage):
                 self.machine_combo.set_active(active)
                 return
             active += 1
-        self.machine_combo.set_active(-1)
 
-    def update_image_desc(self, selected_image):
+        if model[0][0] != self.__dummy_machine__:
+            self.machine_combo.insert_text(0, self.__dummy_machine__)
+
+        self.machine_combo.set_active(0)
+
+    def update_image_desc(self):
         desc = ""
+        selected_image = self.image_combo.get_active_text()
         if selected_image and selected_image in self.builder.recipe_model.pn_path.keys():
             image_path = self.builder.recipe_model.pn_path[selected_image]
             image_iter = self.builder.recipe_model.get_iter(image_path)
@@ -311,9 +324,15 @@ class ImageConfigurationPage (HobPage):
     def image_combo_changed_cb(self, combo):
         self.builder.window_sensitive(False)
         selected_image = self.image_combo.get_active_text()
-        if not selected_image:
+        if not selected_image or (selected_image == self.__dummy_image__):
             return
 
+        # remove __dummy_image__ item from the store list after first user selection
+        # because it is no longer valid
+        combo_store = combo.get_model()
+        if len(combo_store) and (combo_store[0][0] == self.__dummy_image__):
+            combo.remove_text(0)
+
         self.builder.customized = False
 
         selected_recipes = []
@@ -321,7 +340,7 @@ class ImageConfigurationPage (HobPage):
         image_path = self.builder.recipe_model.pn_path[selected_image]
         image_iter = self.builder.recipe_model.get_iter(image_path)
         selected_packages = self.builder.recipe_model.get_value(image_iter, self.builder.recipe_model.COL_INSTALL).split()
-        self.update_image_desc(selected_image)
+        self.update_image_desc()
 
         self.builder.recipe_model.reset()
         self.builder.package_model.reset()
@@ -344,32 +363,61 @@ class ImageConfigurationPage (HobPage):
         # populate image combo
         filter = {RecipeListModel.COL_TYPE : ['image']}
         image_model = recipe_model.tree_model(filter)
-        active = -1
-        cnt = 0
+        active = 0
+        cnt = 1
+
+        white_pattern = []
+        if self.builder.parameters.image_white_pattern:
+            for i in self.builder.parameters.image_white_pattern.split():
+                white_pattern.append(re.compile(i))
+
+        black_pattern = []
+        if self.builder.parameters.image_black_pattern:
+            for i in self.builder.parameters.image_black_pattern.split():
+                black_pattern.append(re.compile(i))
 
         it = image_model.get_iter_first()
         self._image_combo_disconnect_signal()
         model = self.image_combo.get_model()
         model.clear()
+        # Set a indicator text to combo store when first open
+        self.image_combo.append_text(self.__dummy_image__)
         # append and set active
         while it:
             path = image_model.get_path(it)
             it = image_model.iter_next(it)
             image_name = image_model[path][recipe_model.COL_NAME]
-            if image_name == self.builder.recipe_model.__dummy_image__:
+            if image_name == self.builder.recipe_model.__custom_image__:
                 continue
-            self.image_combo.append_text(image_name)
-            if image_name == selected_image:
-                active = cnt
-            cnt = cnt + 1
-        self.image_combo.append_text(self.builder.recipe_model.__dummy_image__)
-        if selected_image == self.builder.recipe_model.__dummy_image__:
+
+            if black_pattern:
+                allow = True
+                for pattern in black_pattern:
+                    if pattern.search(image_name):
+                        allow = False
+                        break
+            elif white_pattern:
+                allow = False
+                for pattern in white_pattern:
+                    if pattern.search(image_name):
+                        allow = True
+                        break
+            else:
+                allow = True
+
+            if allow:
+                self.image_combo.append_text(image_name)
+                if image_name == selected_image:
+                    active = cnt
+                cnt = cnt + 1
+
+        self.image_combo.append_text(self.builder.recipe_model.__custom_image__)
+        if selected_image == self.builder.recipe_model.__custom_image__:
             active = cnt
 
-        self.image_combo.set_active(-1)
         self.image_combo.set_active(active)
 
-        if active != -1:
+        if active != 0:
             self.show_baseimg_selected()
 
         self._image_combo_connect_signal()

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

@@ -25,32 +25,13 @@ import gtk
 from bb.ui.crumbs.hobcolor import HobColors
 from bb.ui.crumbs.hobwidget import hic, HobViewTable, HobAltButton, HobButton
 from bb.ui.crumbs.hobpages import HobPage
-
+import subprocess
+from bb.ui.crumbs.hig import CrumbsDialog
 #
 # ImageDetailsPage
 #
 class ImageDetailsPage (HobPage):
 
-    __columns__ = [{
-            'col_name' : 'Image name',
-            'col_id'   : 0,
-            'col_style': 'text',
-            'col_min'  : 500,
-            'col_max'  : 500
-        }, {
-            'col_name' : 'Image size',
-            'col_id'   : 1,
-            'col_style': 'text',
-            'col_min'  : 100,
-            'col_max'  : 100
-        }, {
-            'col_name' : 'Select',
-            'col_id'   : 2,
-            'col_style': 'radio toggle',
-            'col_min'  : 100,
-            'col_max'  : 100
-    }]
-
     class DetailBox (gtk.EventBox):
         def __init__(self, widget = None, varlist = None, vallist = None, icon = None, button = None, color = HobColors.LIGHT_GRAY):
             gtk.EventBox.__init__(self)
@@ -61,30 +42,34 @@ class ImageDetailsPage (HobPage):
             self.set_style(style)
 
             self.hbox = gtk.HBox()
-            self.hbox.set_border_width(15)
+            self.hbox.set_border_width(10)
             self.add(self.hbox)
 
+            total_rows = 0
             if widget:
-                row = 1
-            elif varlist and vallist:
+                total_rows = 10
+            if varlist and vallist:
                 # pack the icon and the text on the left
-                row = len(varlist)
-            self.table = gtk.Table(row, 20, True)
+                total_rows += len(varlist)
+            self.table = gtk.Table(total_rows, 20, True)
+            self.table.set_row_spacings(6)
             self.table.set_size_request(100, -1)
             self.hbox.pack_start(self.table, expand=True, fill=True, padding=15)
 
             colid = 0
+            rowid = 0
             self.line_widgets = {}
             if icon:
                 self.table.attach(icon, colid, colid + 2, 0, 1)
                 colid = colid + 2
             if widget:
-                self.table.attach(widget, colid, 20, 0, 1)
-            elif varlist and vallist:
-                for line in range(0, row):
-                    self.line_widgets[varlist[line]] = self.text2label(varlist[line], vallist[line])
-                    self.table.attach(self.line_widgets[varlist[line]], colid, 20, line, line + 1)
-
+                self.table.attach(widget, colid, 20, 0, 10)
+                rowid = 10
+            if varlist and vallist:
+                for row in range(rowid, total_rows):
+                    index = row - rowid
+                    self.line_widgets[varlist[index]] = self.text2label(varlist[index], vallist[index])
+                    self.table.attach(self.line_widgets[varlist[index]], colid, 20, row, row + 1)
             # pack the button on the right
             if button:
                 self.hbox.pack_end(button, expand=False, fill=False)
@@ -96,9 +81,23 @@ class ImageDetailsPage (HobPage):
                 return
             self.line_widgets[variable].set_markup(self.format_line(variable, value))
 
+        def wrap_line(self, inputs):
+            # wrap the long text of inputs
+            wrap_width_chars = 75
+            outputs = ""
+            tmps = inputs
+            less_chars = len(inputs)
+            while (less_chars - wrap_width_chars) > 0:
+                less_chars -= wrap_width_chars
+                outputs += tmps[:wrap_width_chars] + "\n               "
+                tmps = inputs[less_chars:]
+            outputs += tmps
+            return outputs
+
         def format_line(self, variable, value):
+            wraped_value = self.wrap_line(value)
             markup = "<span weight=\'bold\'>%s</span>" % variable
-            markup += "<span weight=\'normal\' foreground=\'#1c1c1c\' font_desc=\'14px\'>%s</span>" % value
+            markup += "<span weight=\'normal\' foreground=\'#1c1c1c\' font_desc=\'14px\'>%s</span>" % wraped_value
             return markup
 
         def text2label(self, variable, value):
@@ -112,7 +111,7 @@ class ImageDetailsPage (HobPage):
     def __init__(self, builder):
         super(ImageDetailsPage, self).__init__(builder, "Image details")
 
-        self.image_store = gtk.ListStore(gobject.TYPE_STRING, gobject.TYPE_STRING, gobject.TYPE_BOOLEAN)
+        self.image_store = []
         self.button_ids = {}
         self.details_bottom_buttons = gtk.HBox(False, 6)
         self.create_visual_elements()
@@ -157,10 +156,10 @@ class ImageDetailsPage (HobPage):
             self.details_bottom_buttons.remove(child)
 
     def show_page(self, step):
-        build_succeeded = (step == self.builder.IMAGE_GENERATED)
+        self.build_succeeded = (step == self.builder.IMAGE_GENERATED)
         image_addr = self.builder.parameters.image_addr
         image_names = self.builder.parameters.image_names
-        if build_succeeded:
+        if self.build_succeeded:
             machine = self.builder.configuration.curr_mach
             base_image = self.builder.recipe_model.get_selected_image()
             layers = self.builder.configuration.layers
@@ -172,12 +171,13 @@ class ImageDetailsPage (HobPage):
         for button_id, button in self.button_ids.items():
             button.disconnect(button_id)
         self._remove_all_widget()
+
         # repack
         self.pack_start(self.details_top_buttons, expand=False, fill=False)
         self.pack_start(self.group_align, expand=True, fill=True)
 
         self.build_result = None
-        if build_succeeded:
+        if self.build_succeeded:
             # building is the previous step
             icon = gtk.Image()
             pixmap_path = hic.ICON_INDI_CONFIRM_FILE
@@ -190,45 +190,83 @@ class ImageDetailsPage (HobPage):
             self.box_group_area.pack_start(self.build_result, expand=False, fill=False)
 
         # create the buttons at the bottom first because the buttons are used in apply_button_per_image()
-        if build_succeeded:
+        if self.build_succeeded:
             self.buttonlist = ["Build new image", "Save as template", "Run image", "Deploy image"]
         else: # get to this page from "My images"
             self.buttonlist = ["Build new image", "Run image", "Deploy image"]
 
         # Name
-        self.image_store.clear()
-        default_toggled = False
+        self.image_store = []
+        self.toggled_image = ""
         default_image_size = 0
+        self.num_toggled = 0
         i = 0
         for image_name in image_names:
             image_size = HobPage._size_to_string(os.stat(os.path.join(image_addr, image_name)).st_size)
-            if not default_toggled:
-                default_toggled = (self.test_type_runnable(image_name) and self.test_mach_runnable(image_name)) \
-                    or self.test_deployable(image_name)
+
+            image_attr = ("run" if (self.test_type_runnable(image_name) and self.test_mach_runnable(image_name)) else \
+                          ("deploy" if self.test_deployable(image_name) else ""))
+            is_toggled = (image_attr != "")
+
+            if not self.toggled_image:
                 if i == (len(image_names) - 1):
-                    default_toggled = True
-                self.image_store.set(self.image_store.append(), 0, image_name, 1, image_size, 2, default_toggled)
-                if default_toggled:
+                    is_toggled = True
+                if is_toggled:
                     default_image_size = image_size
-                    self.create_bottom_buttons(self.buttonlist, image_name)
+                    self.toggled_image = image_name
+
+            split_stuff = image_name.split('.')
+            if "rootfs" in split_stuff:
+                image_type = image_name[(len(split_stuff[0]) + len(".rootfs") + 1):]
             else:
-                self.image_store.set(self.image_store.append(), 0, image_name, 1, image_size, 2, False)
+                image_type = image_name[(len(split_stuff[0]) + 1):]
+
+            self.image_store.append({'name': image_name,
+                                    'type': image_type,
+                                    'size': image_size,
+                                    'is_toggled': is_toggled,
+                                    'action_attr': image_attr,})
+
             i = i + 1
-        image_table = HobViewTable(self.__columns__)
-        image_table.set_model(self.image_store)
-        image_table.connect("toggled", self.toggled_cb)
+            self.num_toggled += is_toggled
+
+        is_runnable = self.create_bottom_buttons(self.buttonlist, self.toggled_image)
+
+        # Generated image files info
+        varlist = ["Name: ", "FileCreated: ", "Directory: "]
+        vallist = []
+
+        vallist.append(image_name.split('.')[0])
+        vallist.append(',  '.join(fileitem['type'] for fileitem in self.image_store))
+        vallist.append(image_addr)
+
         view_files_button = HobAltButton("View files")
         view_files_button.connect("clicked", self.view_files_clicked_cb, image_addr)
         view_files_button.set_tooltip_text("Open the directory containing the image files")
-        self.image_detail = self.DetailBox(widget=image_table, button=view_files_button)
-        self.box_group_area.pack_start(self.image_detail, expand=True, fill=True)
+        self.image_detail = self.DetailBox(varlist=varlist, vallist=vallist, button=view_files_button)
+        self.box_group_area.pack_start(self.image_detail, expand=False, fill=True)
+
+        # The default kernel box for the qemu images
+        self.sel_kernel = ""
+        if 'qemu' in image_name:
+            self.sel_kernel = self.get_kernel_file_name()
+
+            varlist = ["Kernel: "]
+            vallist = []
+            vallist.append(self.sel_kernel)
+
+            change_kernel_button = HobAltButton("Change")
+            change_kernel_button.connect("clicked", self.change_kernel_cb)
+            change_kernel_button.set_tooltip_text("Change qemu kernel file")
+            self.kernel_detail = self.DetailBox(varlist=varlist, vallist=vallist, button=change_kernel_button)
+            self.box_group_area.pack_start(self.kernel_detail, expand=False, fill=False)
 
         # Machine, Base image and Layers
         layer_num_limit = 15
         varlist = ["Machine: ", "Base image: ", "Layers: "]
         vallist = []
         self.setting_detail = None
-        if build_succeeded:
+        if self.build_succeeded:
             vallist.append(machine)
             vallist.append(base_image)
             i = 0
@@ -252,14 +290,14 @@ class ImageDetailsPage (HobPage):
             edit_config_button.set_tooltip_text("Edit machine, base image and recipes")
             edit_config_button.connect("clicked", self.edit_config_button_clicked_cb)
             self.setting_detail = self.DetailBox(varlist=varlist, vallist=vallist, button=edit_config_button)
-            self.box_group_area.pack_start(self.setting_detail, expand=False, fill=False)
+            self.box_group_area.pack_start(self.setting_detail, expand=True, fill=True)
 
         # Packages included, and Total image size
         varlist = ["Packages included: ", "Total image size: "]
         vallist = []
         vallist.append(pkg_num)
         vallist.append(default_image_size)
-        if build_succeeded:
+        if self.build_succeeded:
             edit_packages_button = HobAltButton("Edit packages")
             edit_packages_button.set_tooltip_text("Edit the packages included in your image")
             edit_packages_button.connect("clicked", self.edit_packages_button_clicked_cb)
@@ -269,12 +307,19 @@ class ImageDetailsPage (HobPage):
         self.box_group_area.pack_start(self.package_detail, expand=False, fill=False)
 
         # pack the buttons at the bottom, at this time they are already created.
-        self.box_group_area.pack_end(self.details_bottom_buttons, expand=False, fill=False)
+        if self.build_succeeded:
+            self.box_group_area.pack_end(self.details_bottom_buttons, expand=False, fill=False)
+        else: # for "My images" page
+            self.details_separator = gtk.HSeparator()
+            self.box_group_area.pack_start(self.details_separator, expand=False, fill=False)
+            self.box_group_area.pack_start(self.details_bottom_buttons, expand=False, fill=False)
 
         self.show_all()
+        if not is_runnable:
+            self.kernel_detail.hide()
 
     def view_files_clicked_cb(self, button, image_addr):
-        os.system("xdg-open /%s" % image_addr)
+        subprocess.call("xdg-open /%s" % image_addr, shell=True)
 
     def refresh_package_detail_box(self, image_size):
         self.package_detail.update_line_widgets("Total image size: ", image_size)
@@ -303,43 +348,109 @@ class ImageDetailsPage (HobPage):
                 break
         return deployable
 
-    def toggled_cb(self, table, cell, path, columnid, tree):
-        model = tree.get_model()
-        if not model:
+    def get_kernel_file_name(self, kernel_addr=""):
+        kernel_name = ""
+
+        if not kernel_addr:
+            kernel_addr = self.builder.parameters.image_addr
+
+        files = [f for f in os.listdir(kernel_addr) if f[0] <> '.']
+        for check_file in files:
+            if check_file.endswith(".bin"):
+                name_splits = check_file.split(".")[0]
+                if self.builder.parameters.kernel_image_type in name_splits.split("-"):
+                    kernel_name = check_file
+                    break
+
+        return kernel_name
+
+    def show_builded_images_dialog(self, widget, primary_action=""):
+        title = primary_action if primary_action else "Your builded images"
+        dialog = CrumbsDialog(title, self.builder,
+                              gtk.DIALOG_MODAL | gtk.DIALOG_DESTROY_WITH_PARENT)
+        dialog.set_border_width(12)
+
+        label = gtk.Label()
+        label.set_use_markup(True)
+        label.set_alignment(0.0, 0.5)
+        label.set_markup("<span font_desc='12'>Select the image file you want to %s</span>" % primary_action)
+        dialog.vbox.pack_start(label, expand=False, fill=False)
+
+        # filter created images as action attribution (deploy or run)
+        action_attr = ""
+        action_images = []
+        for fileitem in self.image_store:
+            action_attr = fileitem['action_attr']
+            if  (action_attr == 'run' and primary_action == "Run image") \
+             or (action_attr == 'deploy' and primary_action == "Deploy image"):
+                action_images.append(fileitem)
+
+        # pack the corresponding 'runnable' or 'deploy' radio_buttons, if there has no more than one file.
+        # assume that there does not both have 'deploy' and 'runnable' files in the same building result
+        # in possible as design.
+        curr_row = 0
+        rows = (len(action_images)) if len(action_images) < 10 else 10
+        table = gtk.Table(rows, 10, True)
+        table.set_row_spacings(6)
+        table.set_col_spacing(0, 12)
+        table.set_col_spacing(5, 12)
+
+        sel_parent_btn = None
+        for fileitem in action_images:
+            sel_btn = gtk.RadioButton(sel_parent_btn, fileitem['type'])
+            sel_parent_btn = sel_btn if not sel_parent_btn else sel_parent_btn
+            sel_btn.set_active(fileitem['is_toggled'])
+            sel_btn.connect('toggled', self.table_selected_cb, fileitem)
+            if curr_row < 10:
+                table.attach(sel_btn, 2, 5, curr_row, curr_row + 1)
+            else:
+                table.attach(sel_btn, 7, 10, curr_row - 10, curr_row - 9)
+            curr_row += 1
+
+        dialog.vbox.pack_start(table, expand=False, fill=False, padding = 6)
+
+        button = dialog.add_button("Cancel", gtk.RESPONSE_CANCEL)
+        HobAltButton.style_button(button)
+
+        if primary_action:
+            button = dialog.add_button(primary_action, gtk.RESPONSE_YES)
+            HobButton.style_button(button)
+
+        dialog.show_all()
+
+        response = dialog.run()
+        dialog.destroy()
+
+        if response != gtk.RESPONSE_YES:
             return
-        iter = model.get_iter_first()
-        while iter:
-            rowpath = model.get_path(iter)
-            model[rowpath][columnid] = False
-            iter = model.iter_next(iter)
 
-        model[path][columnid] = True
-        self.refresh_package_detail_box(model[path][1])
+        for fileitem in self.image_store:
+            if fileitem['is_toggled']:
+                if fileitem['action_attr'] == 'run':
+                    self.builder.runqemu_image(fileitem['name'], self.sel_kernel)
+                elif fileitem['action_attr'] == 'deploy':
+                    self.builder.deploy_image(fileitem['name'])
 
-        image_name = model[path][0]
+    def table_selected_cb(self, tbutton, image):
+        image['is_toggled'] = tbutton.get_active()
+        if image['is_toggled']:
+            self.toggled_image = image['name']
 
-        # remove
-        for button_id, button in self.button_ids.items():
-            button.disconnect(button_id)
-        self._remove_all_widget()
-        # repack
-        self.pack_start(self.details_top_buttons, expand=False, fill=False)
-        self.pack_start(self.group_align, expand=True, fill=True)
-        if self.build_result:
-            self.box_group_area.pack_start(self.build_result, expand=False, fill=False)
-        self.box_group_area.pack_start(self.image_detail, expand=True, fill=True)
-        if self.setting_detail:
-            self.box_group_area.pack_start(self.setting_detail, expand=False, fill=False)
-        self.box_group_area.pack_start(self.package_detail, expand=False, fill=False)
-        self.create_bottom_buttons(self.buttonlist, image_name)
-        self.box_group_area.pack_end(self.details_bottom_buttons, expand=False, fill=False)
-        self.show_all()
+    def change_kernel_cb(self, widget):
+        kernel_path = self.builder.show_load_kernel_dialog()
+        if kernel_path and self.kernel_detail:
+            import os.path
+            self.sel_kernel = os.path.basename(kernel_path)
+            markup = self.kernel_detail.format_line("Kernel: ", self.sel_kernel)
+            label = ((self.kernel_detail.get_children()[0]).get_children()[0]).get_children()[0]
+            label.set_markup(markup)
 
     def create_bottom_buttons(self, buttonlist, image_name):
         # Create the buttons at the bottom
         created = False
         packed = False
         self.button_ids = {}
+        is_runnable = False
 
         # create button "Deploy image"
         name = "Deploy image"
@@ -374,15 +485,7 @@ class ImageDetailsPage (HobPage):
             self.button_ids[button_id] = run_button
             self.details_bottom_buttons.pack_end(run_button, expand=False, fill=False)
             created = True
-
-        if not packed:
-            box = gtk.HBox(False, 6)
-            box.show()
-            subbox = gtk.HBox(False, 0)
-            subbox.set_size_request(205, 49)
-            subbox.show()
-            box.add(subbox)
-            self.details_bottom_buttons.pack_end(box, False, False)
+            is_runnable = True
 
         name = "Save as template"
         if name in buttonlist:
@@ -391,8 +494,13 @@ class ImageDetailsPage (HobPage):
                 label = gtk.Label(" or ")
                 self.details_bottom_buttons.pack_end(label, expand=False, fill=False)
 
-            # create button "Save as template"
-            save_button = HobAltButton("Save as template")
+                # create button "Save as template"
+                save_button = HobAltButton("Save as template")
+            else:
+                save_button = HobButton("Save as template")
+                save_button.set_size_request(205, 49)
+                save_button.set_flags(gtk.CAN_DEFAULT)
+                packed = True
             save_button.set_tooltip_text("Save the image configuration for reuse")
             button_id = save_button.connect("clicked", self.save_button_clicked_cb)
             self.button_ids[button_id] = save_button
@@ -402,34 +510,39 @@ class ImageDetailsPage (HobPage):
         name = "Build new image"
         if name in buttonlist:
             # create button "Build new image"
-            build_new_button = HobAltButton("Build new image")
+            if packed:
+                build_new_button = HobAltButton("Build new image")
+            else:
+                build_new_button = HobButton("Build new image")
+                build_new_button.set_flags(gtk.CAN_DEFAULT)
+            build_new_button.set_size_request(205, 49)
+            self.details_bottom_buttons.pack_end(build_new_button, expand=False, fill=False)
             build_new_button.set_tooltip_text("Create a new image from scratch")
             button_id = build_new_button.connect("clicked", self.build_new_button_clicked_cb)
             self.button_ids[button_id] = build_new_button
-            self.details_bottom_buttons.pack_start(build_new_button, expand=False, fill=False)
 
-    def _get_selected_image(self):
-        image_name = ""
-        iter = self.image_store.get_iter_first()
-        while iter:
-            path = self.image_store.get_path(iter)
-            if self.image_store[path][2]:
-                image_name = self.image_store[path][0]
-                break
-            iter = self.image_store.iter_next(iter)
-
-        return image_name
+        return is_runnable
 
     def save_button_clicked_cb(self, button):
         self.builder.show_save_template_dialog()
 
     def deploy_button_clicked_cb(self, button):
-        image_name = self._get_selected_image()
-        self.builder.deploy_image(image_name)
+        if self.toggled_image:
+            if self.num_toggled > 1:
+                self.set_sensitive(False)
+                self.show_builded_images_dialog(None, "Deploy image")
+                self.set_sensitive(True)
+            else:
+                self.builder.deploy_image(self.toggled_image)
 
     def run_button_clicked_cb(self, button):
-        image_name = self._get_selected_image()
-        self.builder.runqemu_image(image_name)
+        if self.toggled_image:
+            if self.num_toggled > 1:
+                self.set_sensitive(False)
+                self.show_builded_images_dialog(None, "Run image")
+                self.set_sensitive(True)
+            else:
+                self.builder.runqemu_image(self.toggled_image, self.sel_kernel)
 
     def build_new_button_clicked_cb(self, button):
         self.builder.initiate_new_build_async()

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

@@ -39,6 +39,7 @@ class PackageSelectionPage (HobPage):
          'columns' : [{
                        'col_name' : 'Package name',
                        'col_id'   : PackageListModel.COL_NAME,
+                       'col_t_id' : PackageListModel.COL_FONT,
                        'col_style': 'text',
                        'col_min'  : 100,
                        'col_max'  : 300,
@@ -46,6 +47,7 @@ class PackageSelectionPage (HobPage):
                       }, {
                        'col_name' : 'Brought in by',
                        'col_id'   : PackageListModel.COL_BINB,
+                       'col_t_id' : PackageListModel.COL_FONT,
                        'col_style': 'binb',
                        'col_min'  : 100,
                        'col_max'  : 350,
@@ -53,6 +55,7 @@ class PackageSelectionPage (HobPage):
                       }, {
                        'col_name' : 'Size',
                        'col_id'   : PackageListModel.COL_SIZE,
+                       'col_t_id' : PackageListModel.COL_FONT,
                        'col_style': 'text',
                        'col_min'  : 100,
                        'col_max'  : 300,
@@ -60,7 +63,9 @@ class PackageSelectionPage (HobPage):
                       }, {
                        'col_name' : 'Included',
                        'col_id'   : PackageListModel.COL_INC,
+                       'col_t_id' : PackageListModel.COL_FONT,
                        'col_style': 'check toggle',
+                       'col_group': 'tree store group',
                        'col_min'  : 100,
                        'col_max'  : 100
                      }]
@@ -70,6 +75,7 @@ class PackageSelectionPage (HobPage):
          'columns' : [{
                        'col_name' : 'Package name',
                        'col_id'   : PackageListModel.COL_NAME,
+                       'col_t_id' : PackageListModel.COL_FONT,
                        'col_style': 'text',
                        'col_min'  : 100,
                        'col_max'  : 400,
@@ -77,6 +83,7 @@ class PackageSelectionPage (HobPage):
                       }, {
                        'col_name' : 'Size',
                        'col_id'   : PackageListModel.COL_SIZE,
+                       'col_t_id' : PackageListModel.COL_FONT,
                        'col_style': 'text',
                        'col_min'  : 100,
                        'col_max'  : 500,
@@ -85,6 +92,7 @@ class PackageSelectionPage (HobPage):
                        'col_name' : 'Included',
                        'col_id'   : PackageListModel.COL_INC,
                        'col_style': 'check toggle',
+                       'col_group': 'tree store group',
                        'col_min'  : 100,
                        'col_max'  : 100
                       }]
@@ -101,13 +109,16 @@ class PackageSelectionPage (HobPage):
         # create visual elements
         self.create_visual_elements()
 
+    def included_clicked_cb(self, button):
+        self.ins.set_current_page(0)
+
     def create_visual_elements(self):
         self.label = gtk.Label("Packages included: 0\nSelected packages size: 0 MB")
         self.eventbox = self.add_onto_top_bar(self.label, 73)
         self.pack_start(self.eventbox, expand=False, fill=False)
         self.pack_start(self.group_align, expand=True, fill=True)
 
-        # set visiable members
+        # set visible members
         self.ins = HobNotebook()
         self.tables = [] # we need to modify table when the dialog is shown
         # append the tab
@@ -117,11 +128,11 @@ class PackageSelectionPage (HobPage):
             filter = page['filter']
             tab.set_model(self.package_model.tree_model(filter))
             tab.connect("toggled", self.table_toggled_cb, page['name'])
+            tab.connect_group_selection(self.table_selected_cb)
             if page['name'] == "Included":
                 tab.connect("button-release-event", self.button_click_cb)
                 tab.connect("cell-fadeinout-stopped", self.after_fadeout_checkin_include)
-            label = gtk.Label(page['name'])
-            self.ins.append_page(tab, label)
+            self.ins.append_page(tab, page['name'])
             self.tables.append(tab)
 
         self.ins.set_entry("Search packages:")
@@ -183,7 +194,7 @@ class PackageSelectionPage (HobPage):
             image_total_size += (51200 * 1024)
         image_total_size_str = HobPage._size_to_string(image_total_size)
 
-        self.label.set_text("Packages included: %s\nSelected packages size: %s\nTotal image size: %s" %
+        self.label.set_label("Packages included: %s\nSelected packages size: %s\nTotal image size: %s" %
                             (selected_packages_num, selected_packages_size_str, image_total_size_str))
         self.ins.show_indicator_icon("Included", selected_packages_num)
 
@@ -201,7 +212,7 @@ class PackageSelectionPage (HobPage):
         self.refresh_selection()
         if not self.builder.customized:
             self.builder.customized = True
-            self.builder.configuration.selected_image = self.recipe_model.__dummy_image__
+            self.builder.configuration.selected_image = self.recipe_model.__custom_image__
             self.builder.rcppkglist_populated()
 
         self.builder.window_sensitive(True)
@@ -247,3 +258,20 @@ class PackageSelectionPage (HobPage):
     def after_fadeout_checkin_include(self, table, ctrl, cell, tree):
         tree.set_model(self.package_model.tree_model(self.pages[0]['filter']))
         tree.expand_all()
+
+    def foreach_cell_change_font(self, model, path, iter, paths=None):
+        # Changed the font for a group cells
+        if path and iter and path[0] == paths[0]:
+            self.package_model.set(iter, self.package_model.COL_FONT, "bold")
+        else:
+            if iter and model.iter_parent(iter) == None:
+                self.package_model.set(iter, self.package_model.COL_FONT, '11')
+            else:
+                self.package_model.set(iter, self.package_model.COL_FONT, '10')
+
+    def table_selected_cb(self, selection):
+        model, paths = selection.get_selected_rows()
+        if paths:
+            child_path = self.package_model.convert_vpath_to_path(model, paths[0])
+            self.package_model.foreach(self.foreach_cell_change_font, child_path)
+

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

@@ -35,7 +35,7 @@ class PersistentTooltip(gtk.Window):
 
     markup: some Pango text markup to display in the tooltip
     """
-    def __init__(self, markup):
+    def __init__(self, markup, parent_win=None):
         gtk.Window.__init__(self, gtk.WINDOW_POPUP)
 
         # Inherit the system theme for a tooltip
@@ -76,6 +76,10 @@ class PersistentTooltip(gtk.Window):
         # Ensure a reasonable minimum size
         self.set_geometry_hints(self, 100, 50)
 
+        # Set this window as a transient window for parent(main window)
+        if parent_win:
+            self.set_transient_for(parent_win)
+            self.set_destroy_with_parent(True)
         # Draw our label and close buttons
         hbox = gtk.HBox(False, 0)
         hbox.show()
@@ -121,11 +125,17 @@ class PersistentTooltip(gtk.Window):
                 style.fg[gtk.STATE_NORMAL] = gtk.gdk.color_parse(val)
                 self.label.set_style(style)
                 break # we only care for the tooltip_fg_color
+
         self.label.set_markup(markup)
         self.label.show()
         bin.add(self.label)
         hbox.pack_end(bin, True, True, 6)
 
+        # add the original URL display for user reference
+        if 'a href' in markup:
+            hbox.set_tooltip_text(self.get_markup_url(markup))
+        hbox.show()
+
         self.connect("key-press-event", self._catch_esc_cb)
 
     """
@@ -161,3 +171,16 @@ class PersistentTooltip(gtk.Window):
     def hide(self):
         self.shown = False
         gtk.Window.hide(self)
+
+    """
+    Called to get the hyperlink URL from markup text.
+    """
+    def get_markup_url(self, markup):
+        url = "http:"
+        if markup and type(markup) == str:
+            s = markup
+            if 'http:' in s:
+                import re
+                url = re.search('(http:[^,\\ "]+)', s).group(0)
+
+        return url

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

@@ -99,7 +99,7 @@ class RecipeSelectionPage (HobPage):
                       }]
         }, {
          'name'    : 'Tasks',
-         'tooltip' : 'All tasks availabel in the Yocto Project',
+         'tooltip' : 'All tasks available in the Yocto Project',
          'filter'  : { RecipeListModel.COL_TYPE : ['task'] },
          'columns' : [{
                        'col_name' : 'Task name',
@@ -134,13 +134,15 @@ class RecipeSelectionPage (HobPage):
         # create visual elements
         self.create_visual_elements()
 
+    def included_clicked_cb(self, button):
+        self.ins.set_current_page(0)
+
     def create_visual_elements(self):
-        self.label = gtk.Label()
-        self.eventbox = self.add_onto_top_bar(self.label, 73)
+        self.eventbox = self.add_onto_top_bar(None, 73)
         self.pack_start(self.eventbox, expand=False, fill=False)
         self.pack_start(self.group_align, expand=True, fill=True)
 
-        # set visiable members
+        # set visible members
         self.ins = HobNotebook()
         self.tables = [] # we need modify table when the dialog is shown
         # append the tabs in order
@@ -153,10 +155,7 @@ class RecipeSelectionPage (HobPage):
             if page['name'] == "Included":
                 tab.connect("button-release-event", self.button_click_cb)
                 tab.connect("cell-fadeinout-stopped", self.after_fadeout_checkin_include)
-            label = gtk.Label(page['name'])
-            label.set_selectable(False)
-            label.set_tooltip_text(page['tooltip'])
-            self.ins.append_page(tab, label)
+            self.ins.append_page(tab, page['name'], page['tooltip'])
             self.tables.append(tab)
 
         self.ins.set_entry("Search recipes:")
@@ -202,7 +201,6 @@ class RecipeSelectionPage (HobPage):
     def refresh_selection(self):
         self.builder.configuration.selected_image = self.recipe_model.get_selected_image()
         _, self.builder.configuration.selected_recipes = self.recipe_model.get_selected_recipes()
-        self.label.set_text("Recipes included: %s" % len(self.builder.configuration.selected_recipes))
         self.ins.show_indicator_icon("Included", len(self.builder.configuration.selected_recipes))
 
     def toggle_item_idle_cb(self, path, view_tree, cell, pagename):
@@ -219,7 +217,7 @@ class RecipeSelectionPage (HobPage):
         self.refresh_selection()
         if not self.builder.customized:
             self.builder.customized = True
-            self.builder.configuration.selected_image = self.recipe_model.__dummy_image__
+            self.builder.configuration.selected_image = self.recipe_model.__custom_image__
             self.builder.rcppkglist_populated()
 
         self.builder.window_sensitive(True)

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

@@ -82,6 +82,9 @@ class RunningBuild (gobject.GObject):
           'log-error'       :  (gobject.SIGNAL_RUN_LAST,
                                 gobject.TYPE_NONE,
                                ()),
+          'no-provider'     :  (gobject.SIGNAL_RUN_LAST,
+                                gobject.TYPE_NONE,
+                               (gobject.TYPE_PYOBJECT,)),
           }
     pids_to_task = {}
     tasks_to_iter = {}
@@ -320,6 +323,20 @@ class RunningBuild (gobject.GObject):
             message["title"] = ""
             message["task"] = event.taskstring
             self.emit("task-started", message)
+        elif isinstance(event, bb.event.NoProvider):
+            msg = ""
+            if event._runtime:
+                r = "R"
+            else:
+                r = ""
+            if event._dependees:
+                msg = "Nothing %sPROVIDES '%s' (but %s %sDEPENDS on or otherwise requires it)\n" % (r, event._item, ", ".join(event._dependees), r)
+            else:
+                msg = "Nothing %sPROVIDES '%s'\n" % (r, event._item)
+            if event._reasons:
+                for reason in event._reasons:
+                    msg += ("%s\n" % reason)
+            self.emit("no-provider", msg)
 
         return
 

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

@@ -101,7 +101,19 @@ class HobTemplateFile(ConfigFile):
             return self.dictionary[var]
         else:
             return ""
- 
+
+    def getVersion(self):
+        contents = ConfigFile.readFile(self)
+
+        pattern = "^\s*(\S+)\s*=\s*(\".*?\")"
+
+        for line in contents:
+            match = re.search(pattern, line)
+            if match:
+                if match.group(1) == "VERSION":
+                    return match.group(2).strip('"')
+        return None
+
     def load(self):
         contents = ConfigFile.readFile(self)
         self.dictionary.clear()
@@ -136,11 +148,27 @@ class TemplateMgr(gobject.GObject):
         self.local_conf = None
         self.image_bb = None
 
+    @classmethod
+    def convert_to_template_pathfilename(cls, filename, path):
+        return "%s/%s%s%s" % (path, "template-", filename, ".hob")
+
+    @classmethod
+    def convert_to_bblayers_pathfilename(cls, filename, path):
+        return "%s/%s%s%s" % (path, "bblayers-", filename, ".conf")
+
+    @classmethod
+    def convert_to_local_pathfilename(cls, filename, path):
+        return "%s/%s%s%s" % (path, "local-", filename, ".conf")
+
+    @classmethod
+    def convert_to_image_pathfilename(cls, filename, path):
+        return "%s/%s%s%s" % (path, "hob-image-", filename, ".bb")
+
     def open(self, filename, path):
-        self.template_hob = HobTemplateFile("%s/%s%s%s" % (path, "template-", filename, ".hob"))
-        self.bblayers_conf = ConfigFile("%s/%s%s%s" % (path, "bblayers-", filename, ".conf"))
-        self.local_conf = ConfigFile("%s/%s%s%s" % (path, "local-", filename, ".conf"))
-        self.image_bb = RecipeFile("%s/%s%s%s" % (path, "hob-image-", filename, ".bb"))
+        self.template_hob = HobTemplateFile(TemplateMgr.convert_to_template_pathfilename(filename, path))
+        self.bblayers_conf = ConfigFile(TemplateMgr.convert_to_bblayers_pathfilename(filename, path))
+        self.local_conf = ConfigFile(TemplateMgr.convert_to_local_pathfilename(filename, path))
+        self.image_bb = RecipeFile(TemplateMgr.convert_to_image_pathfilename(filename, path))
 
     def setVar(self, var, val):
         if var in TemplateMgr.__gLocalVars__:
@@ -158,6 +186,9 @@ class TemplateMgr(gobject.GObject):
         self.image_bb.save()
         self.template_hob.save()
 
+    def getVersion(self, path):
+        return HobTemplateFile(path).getVersion()
+
     def load(self, path):
         self.template_hob = HobTemplateFile(path)
         self.dictionary = self.template_hob.load()

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

@@ -22,6 +22,7 @@
 # bitbake which will allow more flexibility.
 
 import os
+import bb
 
 def which_terminal():
     term = bb.utils.which(os.environ["PATH"], "xterm")

bitbake/lib/bb/ui/depexp.py

@@ -24,7 +24,7 @@ import threading
 import xmlrpclib
 import bb
 import bb.event
-from bb.ui.crumbs.progress import ProgressBar
+from bb.ui.crumbs.progressbar import HobProgressBar
 
 # Package Model
 (COL_PKG_NAME) = (0)
@@ -220,8 +220,12 @@ def main(server, eventHandler):
 
     gtk.gdk.threads_enter()
     dep = DepExplorer()
-    pbar = ProgressBar(dep)
-    pbar.connect("delete-event", gtk.main_quit)
+    bardialog = gtk.Dialog(parent=dep)
+    bardialog.set_default_size(400, 50)
+    pbar = HobProgressBar()
+    bardialog.vbox.pack_start(pbar)
+    bardialog.show_all()
+    bardialog.connect("delete-event", gtk.main_quit)
     gtk.gdk.threads_leave()
 
     progress_total = 0
@@ -238,19 +242,20 @@ def main(server, eventHandler):
             if isinstance(event, bb.event.CacheLoadStarted):
                 progress_total = event.total
                 gtk.gdk.threads_enter()
-                pbar.set_title("Loading Cache")
-                pbar.update(0, progress_total)
+                bardialog.set_title("Loading Cache")
+                pbar.update(0)
                 gtk.gdk.threads_leave()
 
             if isinstance(event, bb.event.CacheLoadProgress):
                 x = event.current
                 gtk.gdk.threads_enter()
-                pbar.update(x, progress_total)
+                pbar.update(x * 1.0 / progress_total)
+                pbar.set_title('')
                 gtk.gdk.threads_leave()
                 continue
 
             if isinstance(event, bb.event.CacheLoadCompleted):
-                pbar.hide()
+                bardialog.hide()
                 continue
 
             if isinstance(event, bb.event.ParseStarted):
@@ -258,19 +263,21 @@ def main(server, eventHandler):
                 if progress_total == 0:
                     continue
                 gtk.gdk.threads_enter()
-                pbar.set_title("Processing recipes")
-                pbar.update(0, progress_total)
+                pbar.update(0)
+                bardialog.set_title("Processing recipes")
+
                 gtk.gdk.threads_leave()
 
             if isinstance(event, bb.event.ParseProgress):
                 x = event.current
                 gtk.gdk.threads_enter()
-                pbar.update(x, progress_total)
+                pbar.update(x * 1.0 / progress_total)
+                pbar.set_title('')
                 gtk.gdk.threads_leave()
                 continue
 
             if isinstance(event, bb.event.ParseCompleted):
-                pbar.hide()
+                bardialog.hide()
                 continue
 
             if isinstance(event, bb.event.DepTreeGenerated):

bitbake/lib/bb/ui/hob.py

@@ -30,7 +30,7 @@ try:
     pygtk.require('2.0') # to be certain we don't have gtk+ 1.x !?!
     gtkver = gtk.gtk_version
     pygtkver = gtk.pygtk_version
-    if gtkver  < (2, 18, 0) or pygtkver < (2, 16, 0):
+    if gtkver  < (2, 20, 0) or pygtkver < (2, 21, 0):
         sys.exit("%s,\nYou have Gtk+ %s and PyGtk %s." % (requirements,
                 ".".join(map(str, gtkver)),
                 ".".join(map(str, pygtkver))))

bitbake/lib/bb/ui/knotty2.py

@@ -106,4 +106,4 @@ class TerminalFilter2(object):
             self.termios.tcsetattr(fd, self.termios.TCSADRAIN, self.stdinbackup)
 
 def main(server, eventHandler):
-    bb.ui.knotty.main(server, eventHandler, TerminalFilter2)
+    return bb.ui.knotty.main(server, eventHandler, TerminalFilter2)

bitbake/lib/bb/ui/ncurses.py

@@ -47,7 +47,7 @@
 
 from __future__ import division
 import logging
-import os, sys, curses, itertools, time
+import os, sys, curses, itertools, time, subprocess
 import bb
 import xmlrpclib
 from bb import ui
@@ -286,7 +286,7 @@ class NCursesUI:
 #                            bb.error("log data follows (%s)" % logfile)
 #                            number_of_lines = data.getVar("BBINCLUDELOGS_LINES", d)
 #                            if number_of_lines:
-#                                os.system('tail -n%s %s' % (number_of_lines, logfile))
+#                                subprocess.call('tail -n%s %s' % (number_of_lines, logfile), shell=True)
 #                            else:
 #                                f = open(logfile, "r")
 #                                while True:

bitbake/lib/bb/utils.py

@@ -26,14 +26,12 @@ import logging
 import bb
 import bb.msg
 import multiprocessing
+import fcntl
 from commands import getstatusoutput
 from contextlib import contextmanager
 
 logger = logging.getLogger("BitBake.Util")
 
-# Version comparison
-separators = ".-"
-
 # Context used in better_exec, eval
 _context = {
     "os": os,
@@ -48,15 +46,18 @@ def explode_version(s):
     while (s != ''):
         if s[0] in string.digits:
             m = numeric_regexp.match(s)
-            r.append(int(m.group(1)))
+            r.append((0, int(m.group(1))))
             s = m.group(2)
             continue
         if s[0] in string.letters:
             m = alpha_regexp.match(s)
-            r.append(m.group(1))
+            r.append((1, m.group(1)))
             s = m.group(2)
             continue
-        r.append(s[0])
+        if s[0] == '~':
+            r.append((-1, s[0]))
+        else:
+            r.append((2, s[0]))
         s = s[1:]
     return r
 
@@ -77,33 +78,25 @@ def split_version(s):
 def vercmp_part(a, b):
     va = explode_version(a)
     vb = explode_version(b)
-    sa = False
-    sb = False
     while True:
         if va == []:
-            ca = None
+            (oa, ca) = (0, None)
         else:
-            ca = va.pop(0)
+            (oa, ca) = va.pop(0)
         if vb == []:
-            cb = None
+            (ob, cb) = (0, None)
         else:
-            cb = vb.pop(0)
-        if ca == None and cb == None:
+            (ob, cb) = vb.pop(0)
+        if (oa, ca) == (0, None) and (ob, cb) == (0, None):
             return 0
-
-        if isinstance(ca, basestring):
-            sa = ca in separators
-        if isinstance(cb, basestring):
-            sb = cb in separators
-        if sa and not sb:
+        if oa < ob:
             return -1
-        if not sa and sb:
+        elif oa > ob:
             return 1
-
-        if ca > cb:
-            return 1
-        if ca < cb:
+        elif ca < cb:
             return -1
+        elif ca > cb:
+            return 1
 
 def vercmp(ta, tb):
     (ea, va, ra) = ta
@@ -116,130 +109,10 @@ def vercmp(ta, tb):
         r = vercmp_part(ra, rb)
     return r
 
-_package_weights_ = {"pre":-2, "p":0, "alpha":-4, "beta":-3, "rc":-1}    # dicts are unordered
-_package_ends_ = ["pre", "p", "alpha", "beta", "rc", "cvs", "bk", "HEAD" ]            # so we need ordered list
-
-def relparse(myver):
-    """Parses the last elements of a version number into a triplet, that can
-    later be compared.
-    """
-
-    number = 0
-    p1 = 0
-    p2 = 0
-    mynewver = myver.split('_')
-    if len(mynewver) == 2:
-        # an _package_weights_
-        number = float(mynewver[0])
-        match = 0
-        for x in _package_ends_:
-            elen = len(x)
-            if mynewver[1][:elen] == x:
-                match = 1
-                p1 = _package_weights_[x]
-                try:
-                    p2 = float(mynewver[1][elen:])
-                except:
-                    p2 = 0
-                break
-        if not match:
-            # normal number or number with letter at end
-            divider = len(myver)-1
-            if myver[divider:] not in "1234567890":
-                # letter at end
-                p1 = ord(myver[divider:])
-                number = float(myver[0:divider])
-            else:
-                number = float(myver)
-    else:
-        # normal number or number with letter at end
-        divider = len(myver)-1
-        if myver[divider:] not in "1234567890":
-            #letter at end
-            p1 = ord(myver[divider:])
-            number = float(myver[0:divider])
-        else:
-            number = float(myver)
-    return [number, p1, p2]
-
-__vercmp_cache__ = {}
-
-def vercmp_string(val1, val2):
-    """This takes two version strings and returns an integer to tell you whether
-    the versions are the same, val1>val2 or val2>val1.
-    """
-
-    # quick short-circuit
-    if val1 == val2:
-        return 0
-    valkey = val1 + " " + val2
-
-    # cache lookup
-    try:
-        return __vercmp_cache__[valkey]
-        try:
-            return - __vercmp_cache__[val2 + " " + val1]
-        except KeyError:
-            pass
-    except KeyError:
-        pass
-
-    # consider 1_p2 vc 1.1
-    # after expansion will become (1_p2,0) vc (1,1)
-    # then 1_p2 is compared with 1 before 0 is compared with 1
-    # to solve the bug we need to convert it to (1,0_p2)
-    # by splitting _prepart part and adding it back _after_expansion
-
-    val1_prepart = val2_prepart = ''
-    if val1.count('_'):
-        val1, val1_prepart = val1.split('_', 1)
-    if val2.count('_'):
-        val2, val2_prepart = val2.split('_', 1)
-
-    # replace '-' by '.'
-    # FIXME: Is it needed? can val1/2 contain '-'?
-
-    val1 = val1.split("-")
-    if len(val1) == 2:
-        val1[0] = val1[0] + "." + val1[1]
-    val2 = val2.split("-")
-    if len(val2) == 2:
-        val2[0] = val2[0] + "." + val2[1]
-
-    val1 = val1[0].split('.')
-    val2 = val2[0].split('.')
-
-    # add back decimal point so that .03 does not become "3" !
-    for x in xrange(1, len(val1)):
-        if val1[x][0] == '0' :
-            val1[x] = '.' + val1[x]
-    for x in xrange(1, len(val2)):
-        if val2[x][0] == '0' :
-            val2[x] = '.' + val2[x]
-
-    # extend varion numbers
-    if len(val2) < len(val1):
-        val2.extend(["0"]*(len(val1)-len(val2)))
-    elif len(val1) < len(val2):
-        val1.extend(["0"]*(len(val2)-len(val1)))
-
-    # add back _prepart tails
-    if val1_prepart:
-        val1[-1] += '_' + val1_prepart
-    if val2_prepart:
-        val2[-1] += '_' + val2_prepart
-    # The above code will extend version numbers out so they
-    # have the same number of digits.
-    for x in xrange(0, len(val1)):
-        cmp1 = relparse(val1[x])
-        cmp2 = relparse(val2[x])
-        for y in xrange(0, 3):
-            myret = cmp1[y] - cmp2[y]
-            if myret != 0:
-                __vercmp_cache__[valkey] = myret
-                return myret
-    __vercmp_cache__[valkey] = 0
-    return 0
+def vercmp_string(a, b):
+    ta = split_version(a)
+    tb = split_version(b)
+    return vercmp(ta, tb)
 
 def explode_deps(s):
     """
@@ -550,8 +423,6 @@ def preserved_envvars():
         'BB_PRESERVE_ENV',
         'BB_ENV_WHITELIST',
         'BB_ENV_EXTRAWHITE',
-        'LANG',
-        '_',
     ]
     return v + preserved_envvars_exported() + preserved_envvars_exported_interactive()
 
@@ -849,6 +720,8 @@ def which(path, item, direction = 0):
     for p in paths:
         next = os.path.join(p, item)
         if os.path.exists(next):
+            if not os.path.isabs(next):
+                next = os.path.abspath(next)
             return next
 
     return ""
@@ -880,3 +753,7 @@ def contains(variable, checkvalues, truevalue, falsevalue, d):
 
 def cpu_count():
     return multiprocessing.cpu_count()
+
+def nonblockingfd(fd):
+    fcntl.fcntl(fd, fcntl.F_SETFL, fcntl.fcntl(fd, fcntl.F_GETFL) | os.O_NONBLOCK)
+

documentation/Makefile

@@ -82,7 +82,8 @@ ALLPREQ = html pdf tarball
 #
 # Note that the tarfile might produce the "Cannot stat: No such file or directory" error
 # message for .PNG files that are not present when building a particular branch.  The 
-# list of files is all-inclusive for all branches.
+# list of files is all-inclusive for all branches.  Note, if you don't provide a BRANCH
+# option, it defaults to the latest stuff.  This would be appropriate for "master" branch.
 #
 
 	ifeq ($(BRANCH),edison)
@@ -94,13 +95,22 @@ TARFILES = style.css dev-manual.html dev-manual.pdf \
            figures/kernel-overview-3-edison.png \
            figures/source-repos.png figures/yp-download.png \
            figures/wip.png
-	else
+	else ifeq ($(BRANCH),denzil)
 TARFILES = style.css dev-manual.html dev-manual.pdf \
            figures/app-dev-flow.png figures/bsp-dev-flow.png figures/dev-title.png \
            figures/git-workflow.png figures/index-downloads.png figures/kernel-dev-flow.png \
-           figures/kernel-example-repos.png \
+           figures/kernel-example-repos-denzil.png \
            figures/kernel-overview-1.png figures/kernel-overview-2.png \
-           figures/kernel-overview-3.png \
+           figures/kernel-overview-3-denzil.png \
+           figures/source-repos.png figures/yp-download.png \
+           figures/wip.png
+        else
+TARFILES = style.css dev-manual.html dev-manual.pdf \
+           figures/app-dev-flow.png figures/bsp-dev-flow.png figures/dev-title.png \
+           figures/git-workflow.png figures/index-downloads.png figures/kernel-dev-flow.png \
+           figures/kernel-example-repos-denzil.png \
+           figures/kernel-overview-1.png figures/kernel-overview-2.png \
+           figures/kernel-overview-3-denzil.png \
            figures/source-repos.png figures/yp-download.png \
            figures/wip.png
 	endif
@@ -195,7 +205,7 @@ validate:
 
 publish:
 	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)/figures
+	cd $(DOC); scp -r $(FIGURES) www.yoctoproject.org:/srv/www/www.yoctoproject.org-docs/$(VER)/$(DOC)
 
 clean:
 	rm -f $(MANUALS)

documentation/adt-manual/adt-command.xml

@@ -8,7 +8,7 @@
     <para>
         Recall that earlier the manual discussed how to use an existing toolchain 
         tarball that had been installed into <filename>/opt/poky</filename>, 
-        which is outside of the Yocto Project build tree 
+        which is outside of the build directory 
         (see the section "<link linkend='using-an-existing-toolchain-tarball'>Using an Existing 
         Toolchain Tarball)</link>".  
         And, that sourcing your architecture-specific environment setup script 
@@ -21,7 +21,7 @@
         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 
-        Yocto Project build environment on both autotools-based projects and 
+        OpenEmbedded build environment on both autotools-based projects and 
         Makefile-based projects.
     </para>
 

documentation/adt-manual/adt-eclipse.xml

@@ -7,9 +7,9 @@
 
     <para>
         The Eclipse IDE is a popular development environment and it fully supports 
-        development using Yocto Project.  
+        development using the Yocto Project.  
         When you install and configure the Eclipse Yocto Project Plug-in into 
-        the Eclipse IDE, you maximize your Yocto Project design experience.  
+        the Eclipse IDE, you maximize your Yocto Project experience.  
         Installing and configuring the Plug-in results in an environment that 
         has extensions specifically designed to let you more easily develop software.  
         These extensions allow for cross-compilation, deployment, and execution of 
@@ -21,7 +21,7 @@
     </para>
     <para>
         This section describes how to install and configure the Eclipse IDE 
-        Yocto Plug-in and how to use it to develop your Yocto Project.
+        Yocto Plug-in and how to use it to develop your application.
     </para>
 
 <section id='setting-up-the-eclipse-ide'>
@@ -35,6 +35,11 @@
             <listitem><para>Install the Eclipse Yocto Plug-in.</para></listitem>
             <listitem><para>Configure the Eclipse Yocto Plug-in.</para></listitem>
         </orderedlist>
+        <note>
+            Do not install Eclipse from your distribution's package repository.
+            Be sure to install Eclipse from the official Eclipse download site as directed
+            in the next section.
+        </note>
     </para>
 
     <section id='installing-eclipse-ide'>
@@ -59,7 +64,7 @@
             into a clean directory using the default name <filename>eclipse</filename>:
             <literallayout class='monospaced'>
      $ cd ~
-     $ tar -xzvf ~/Downloads/eclipse-SDK-3.7.1-linux-gtk-x86_64.tar.gz
+     $ tar -xzvf ~/Downloads/eclipse-SDK-3.7.2-linux-gtk-x86_64.tar.gz
             </literallayout>
         </para>
 
@@ -147,7 +152,7 @@
 
         <para>
             You can install the Eclipse Yocto Plug-in into the Eclipse IDE
-            one of two ways:  use the Yocto Project update site to install the pre-built plug-in,
+            one of two ways:  use the Yocto Project's Eclipse Update site to install the pre-built plug-in,
             or build and install the plug-in from the latest source code.
             If you don't want to permanently install the plug-in but just want to try it out
             within the Eclipse environment, you can import the plug-in project from the 
@@ -288,7 +293,7 @@
             <itemizedlist>
                 <listitem><para>Choose <filename>Windows -&gt; Preferences</filename> to display 
                     the <filename>Preferences</filename> Dialog</para></listitem>
-                <listitem><para>Click <filename>Yocto ADT</filename></para></listitem>
+                <listitem><para>Click <filename>Yocto Project ADT</filename></para></listitem>
             </itemizedlist>
         </para>
 
@@ -315,16 +320,16 @@
                                <listitem><para><emphasis>
                                     <filename>Build System Derived Toolchain:</filename></emphasis> 
                                     Select this mode if the cross-toolchain has been installed and built 
-                                    as part of the Yocto Project build tree.  
+                                    as part of the build directory.  
                                     When you select <filename>Build system derived toolchain</filename>,
                                     you are using the toolchain bundled 
-                                    inside the Yocto Project build tree.
+                                    inside the build directory.
                                     </para></listitem>
                             </itemizedlist>
                         </para></listitem>
                     <listitem><para><emphasis>Point to the Toolchain:</emphasis>
                         If you are using a stand-alone pre-built toolchain, you should be pointing to the
-                        <filename>/opt/poky/1.1</filename> directory.
+                        <filename>&YOCTO_ADTPATH_DIR;</filename> directory.
                         This is the location for toolchains installed by the ADT Installer or by hand.
                         Sections "<link linkend='configuring-and-running-the-adt-installer-script'>Configuring 
                         and Running the ADT Installer Script</link>" and 
@@ -337,11 +342,10 @@
                         However, doing so is discouraged.</note></para>
                         <para>If you are using a system-derived toolchain, the path you provide 
                         for the <filename>Toolchain Root Location</filename>
-                        field is the Yocto Project's build directory.
+                        field is the build directory.
                         See section "<link linkend='using-the-toolchain-from-within-the-build-tree'>Using 
-                        BitBake and the Yocto Project Build Tree</link>" for 
-                        information on how to install the toolchain into the Yocto 
-                        Project build tree.</para></listitem> 
+                        BitBake and the build directory</link>" for 
+                        information on how to install the toolchain into the build directory.</para></listitem> 
                     <listitem><para><emphasis>Specify the Sysroot Location:</emphasis>
                         This location is where the root filesystem for the 
                         target hardware is created on the development system by the ADT Installer.
@@ -375,7 +379,7 @@
                         and specify any custom options.</para>
                         <para>If you selected <filename>Build system derived toolchain</filename>, 
                         the target kernel you built will be located in the 
-                        Yocto Project build tree in <filename>tmp/deploy/images</filename> directory.   
+                        build directory in <filename>tmp/deploy/images</filename> directory.   
                         If you selected <filename>Standalone pre-built toolchain</filename>, the 
                         pre-built image you downloaded is located 
                         in the directory you specified when you downloaded the image.</para>
@@ -426,9 +430,9 @@
             <listitem><para>Select <filename>File -&gt; New -&gt; Project</filename>.</para></listitem>
             <listitem><para>Double click <filename>CC++</filename>.</para></listitem>
             <listitem><para>Double click <filename>C Project</filename> to create the project.</para></listitem>
-            <listitem><para>Expand <filename>Yocto ADT Project</filename>.</para></listitem>
+            <listitem><para>Expand <filename>Yocto Project ADT Project</filename>.</para></listitem>
             <listitem><para>Select <filename>Hello World ANSI C Autotools Project</filename>.  
-                This is an Autotools-based project based on a Yocto Project template.</para></listitem>
+                This is an Autotools-based project based on a Yocto template.</para></listitem>
             <listitem><para>Put a name in the <filename>Project name:</filename> field.
                 Do not use hyphens as part of the name.</para></listitem>
             <listitem><para>Click <filename>Next</filename>.</para></listitem>
@@ -455,7 +459,7 @@
         You can override these settings for a given project by following these steps:
         <orderedlist>
             <listitem><para>Select <filename>Project -&gt; Change Yocto Project Settings</filename>:  
-                This selection brings up the <filename>Project Yocto Settings</filename> Dialog
+                This selection brings up the <filename>Yocot Project Settings</filename> Dialog
                 and allows you to make changes specific to an individual project.  
                 </para>
                 <para>By default, the Cross Compiler Options and Target Options for a project
@@ -463,7 +467,7 @@
                 Dialog as described earlier 
                 in the "<link linkend='configuring-the-eclipse-yocto-plug-in'>Configuring the Eclipse 
                 Yocto Plug-in</link>" section.
-                The <filename>Project Yocto Settings</filename>
+                The <filename>Yocto Project Settings</filename>
                 Dialog allows you to override those default settings
                 for a given project.</para></listitem>
             <listitem><para>Make your configurations for the project and click "OK".</para></listitem>
@@ -672,7 +676,7 @@
                     <filename>&lt;project_location&gt;/&lt;project_name&gt;</filename>. 
                     If that directory does not exist, you need to check 
                     the "Clone from Yocto Git Repository" box, which would execute a 
-                    <filename>git clone</filename> command to get the Yocto project's metadata files.
+                    <filename>git clone</filename> command to get the project's metadata files.
                     </para></listitem>
                 <listitem><para>Select <filename>Finish</filename> to create the project.</para></listitem>
             </orderedlist>
@@ -697,9 +701,9 @@
                 <listitem><para>Select <filename>File -> New -> Yocto BitBake Commander -> BitBake Recipe</filename>
                     to open a new recipe wizard.</para></listitem>
                 <listitem><para>Point to your source by filling in the "SRC_URL" field.
-                    For example, you can add a recipe in the 
-                    <ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-source-files'>Yocto Project Source Files</ulink>,
-                    input the "SRC_URL" as follows:
+                    For example, you can add a recipe to your 
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-source-files'>source directory structure</ulink>
+                    by defining "SRC_URL" as follows:
                     <literallayout class='monospaced'>
      ftp://ftp.gnu.org/gnu/m4/m4-1.4.9.tar.gz
                     </literallayout></para></listitem>

documentation/adt-manual/adt-intro.xml

@@ -17,7 +17,7 @@
 
     <para>
         Fundamentally, the ADT consists of an architecture-specific cross-toolchain and 
-        a matching sysroot that are both built by the Yocto Project build system Poky.  
+        a matching sysroot that are both built by the OpenEmbedded build system Poky.  
         The toolchain and sysroot are based on a metadata configuration and extensions, 
         which allows you to cross-develop on the host machine for the target.
     </para>
@@ -50,7 +50,7 @@
             The cross-toolchain consists of a cross-compiler, cross-linker, and cross-debugger 
             that are used to develop user-space applications for targeted hardware.
             This toolchain is created either by running the ADT Installer script or 
-            through a Yocto Project build tree that is based on your metadata 
+            through a build directory that is based on your metadata 
             configuration or extension for your targeted device.  
             The cross-toolchain works with a matching target sysroot.
         </para>
@@ -63,7 +63,7 @@
             The matching target sysroot contains needed headers and libraries for generating 
             binaries that run on the target architecture.  
             The sysroot is based on the target root filesystem image that is built by 
-            the Yocto Project's build system Poky and uses the same metadata configuration 
+            the OpenEmbedded build system Poky and uses the same metadata configuration 
             used to build the cross-toolchain.
         </para>
     </section>
@@ -79,8 +79,8 @@
                 <listitem><para>If you use the ADT Installer script to install ADT, you can 
                     specify whether or not to install QEMU.</para></listitem>
                 <listitem><para>If you have downloaded a Yocto Project release and unpacked 
-                    it to create a Yocto Project file structure and you have sourced  
-                    the Yocto Project environment setup script, QEMU is installed and automatically 
+                    it to create a source directory and you have sourced  
+                    the environment setup script, QEMU is installed and automatically 
                     available.</para></listitem>
                 <listitem><para>If you have installed the cross-toolchain 
                     tarball and you have sourcing the toolchain's setup environment script, QEMU
@@ -120,7 +120,7 @@
                 <listitem><para><emphasis>SystemTap:</emphasis> A free software infrastructure 
                     that simplifies information gathering about a running Linux system.  
                     This information helps you diagnose performance or functional problems.  
-                    SystemTap is not available as a user-space tool through the Yocto Eclipse IDE Plug-in.  
+                    SystemTap is not available as a user-space tool through the Eclipse IDE Yocto Plug-in.  
                     See <ulink url='http://sourceware.org/systemtap'></ulink> for more information 
                     on SystemTap.</para></listitem>
                 <listitem><para><emphasis>Lttng-ust:</emphasis> A User-space Tracer designed to 

documentation/adt-manual/adt-manual.xml

@@ -46,8 +46,13 @@
             </revision>
             <revision>
                 <revnumber>1.2</revnumber>
-                <date>TBD 2012</date>
-                <revremark>Work in progress for the Yocto Project 1.2 Release.</revremark>
+                <date>April 2012</date>
+                <revremark>Released with the Yocto Project 1.2 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.3</revnumber>
+                <date>Sometime in 2012</date>
+                <revremark>Released with the Yocto Project 1.3 Release.</revremark>
             </revision>
         </revhistory>
 

documentation/adt-manual/adt-package.xml

@@ -17,7 +17,7 @@
     <title>Package Management Systems</title>
 
     <para>
-        The Yocto Project supports the generation of sysroot files using 
+        The OpenEmbedded build system supports the generation of sysroot files using 
         three different Package Management Systems (PMS):
         <itemizedlist>
             <listitem><para><emphasis>OPKG:</emphasis> A less well known PMS whose use 
@@ -28,7 +28,7 @@
             <listitem><para><emphasis>RPM:</emphasis> A more widely known PMS intended for GNU/Linux 
                 distributions.  
                 This PMS works with files packaged in an <filename>.rms</filename> format.
-                The Yocto Project currently installs through this PMS by default.  
+                The build system currently installs through this PMS by default.  
                 See <ulink url='http://en.wikipedia.org/wiki/RPM_Package_Manager'></ulink>
                 for more information about RPM.</para></listitem>
             <listitem><para><emphasis>Debian:</emphasis> The PMS for Debian-based systems 
@@ -75,7 +75,7 @@
     </para>
 
     <para>
-        Next, source the environment setup script found in the Yocto Project files.  
+        Next, source the environment setup script found in the source directory.  
         Follow that by setting up the installation destination to point to your 
         sysroot as <filename>&lt;sysroot_dir&gt;</filename>.  
         Finally, have an OPKG configuration file <filename>&lt;conf_file&gt;</filename>

documentation/adt-manual/adt-prepare.xml

@@ -23,6 +23,21 @@
         See the "<link linkend='setting-up-the-cross-development-environment'>Setting Up the 
         Cross-Development Environment</link>"
         section for more information.
+    </para>
+
+    <note>
+        <para>Avoid mixing installation methods when installing the ADT for different architectures.
+        For example, avoid using the ADT Installer to install some toolchains and then hand-installing
+        cross-development toolchains from downloaded tarballs to install toolchains
+        for different architectures. 
+        Mixing installation methods can result in situations where the ADT Installer becomes
+        unreliable and might not install the toolchain.</para>
+        <para>If you must mix installation methods, you might avoid problems by deleting 
+        <filename>/var/lib/opkg</filename>, thus purging the <filename>opkg</filename> package 
+        metadata</para>
+    </note>
+    
+    <para>
         <itemizedlist>
             <listitem><para><emphasis>Use the ADT Installer Script:</emphasis>
                 This method is the recommended way to install the ADT because it
@@ -36,8 +51,8 @@
                 If you use this method, you just get the cross-toolchain and QEMU - you do not 
                 get any of the other mentioned benefits had you run the ADT Installer script.</para></listitem>
             <listitem><para><emphasis>Use the Toolchain from within a Yocto Project Build Tree:</emphasis>
-                If you already have a Yocto Project build tree, you can build the cross-toolchain 
-                within tree.
+                If you already have a build directory, you can build the cross-toolchain 
+                within that structure.
                 However, like the previous method mentioned, you only get the cross-toolchain and QEMU - you 
                 do not get any of the other benefits without taking separate steps.</para></listitem>
         </itemizedlist>
@@ -60,22 +75,21 @@
                 <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 Yocto Project 
-                build tree.
+                Or, you can use BitBake to generate the tarball inside the existing build directory.
             </para>
 
             <para>
                 If you use BitBake to generate the ADT Installer tarball, you must 
-                <filename>source</filename> the Yocto Project environment setup script 
+                <filename>source</filename> the environment setup script 
                 (<filename>oe-init-build-env</filename>) located 
-                in the Yocto Project file structure before running the <filename>bitbake</filename>
+                in the source directory before running the <filename>bitbake</filename>
                 command that creates the tarball.
             </para>
 
             <para>
-                The following example commands download the Yocto Project release tarball, set up the Yocto 
-                Project files structure, set up the environment while also creating the 
-                default Yocto Project build tree, 
+                The following example commands download the Yocto Project release tarball, set up the 
+                source directory, set up the environment while also creating the 
+                default build directory, 
                 and run the <filename>bitbake</filename> command that results in the tarball 
                 <filename>~/yocto-project/build/tmp/deploy/sdk/adt_installer.tar.bz2</filename>:
                 <literallayout class='monospaced'>
@@ -136,7 +150,7 @@
                         or not to install the emulator QEMU.</para></listitem>
                     <listitem><para><filename>YOCTOADT_NFS_UTIL</filename>: Indicates whether 
                         or not to install user-mode NFS.  
-                        If you plan to use the Yocto Eclipse IDE plug-in against QEMU, 
+                        If you plan to use the Eclipse IDE Yocto plug-in against QEMU, 
                         you should install NFS.
                         <note>To boot QEMU images using our userspace NFS server, you need 
                             to be running <filename>portmap</filename> or <filename>rpcbind</filename>. 
@@ -166,7 +180,10 @@
 
             <para>
                 After you have configured the <filename>adt_installer.conf</filename> file, 
-                run the installer using the following command:
+                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>:
                 <literallayout class='monospaced'>
      $ ./adt_installer
                 </literallayout>
@@ -226,17 +243,17 @@
      poky-eglibc-x86_64-i586-toolchain-gmae-&DISTRO;.tar.bz2
                     </literallayout>
                     <note><para>As an alternative to steps one and two, you can build the toolchain tarball 
-                        if you have a Yocto Project build tree.
+                        if you have a build directory.
                         If you need GMAE, you should use the <filename>bitbake meta-toolchain-gmae</filename>
                         command. 
                         The resulting tarball will support such development.
                         However, if you are not concerned with GMAE, 
                         you can generate the tarball using <filename>bitbake meta-toolchain</filename>.</para>
                         <para>Use the appropriate <filename>bitbake</filename> command only after you have 
-                        sourced the <filename>oe-build-init-env</filename> script located in the Yocto 
-                        Project files.  
+                        sourced the <filename>oe-build-init-env</filename> script located in the source
+                        directory.  
                         When the <filename>bitbake</filename> command completes, the tarball will 
-                        be in <filename>tmp/deploy/sdk</filename> in the Yocto Project build tree.
+                        be in <filename>tmp/deploy/sdk</filename> in the build directory.
                         </para></note></para></listitem>
                 <listitem><para>Make sure you are in the root directory with root privileges and then expand 
                     the tarball.  
@@ -249,26 +266,27 @@
     </section>
 
     <section id='using-the-toolchain-from-within-the-build-tree'>
-        <title>Using BitBake and the Yocto Project Build Tree</title>
+        <title>Using BitBake and the Build Directory</title>
 
         <para>
-            A final way of installing just the cross-toolchain is to use BitBake to build the 
-            toolchain within an existing Yocto Project build tree.
-            This method does not install the toolchain into the <filename>/opt</filename> directory.
+            A final way of making the cross-toolchain available is to use BitBake 
+            to generate the toolchain within an existing build directory.
+            This method does not install the toolchain into the 
+            <filename>/opt</filename> directory.
             As with the previous method, if you need to install the target sysroot, you must 
             do this separately.
         </para>
 
         <para>
-            Follow these steps to build and install the toolchain into the build tree:
+            Follow these steps to generate the toolchain into the build tree:
             <orderedlist>
                 <listitem><para>Source the environment setup script 
-                    <filename>oe-init-build-env</filename> located in the Yocto Project
-                    files.</para></listitem> 
+                    <filename>oe-init-build-env</filename> located in the source directory.
+                    </para></listitem> 
                 <listitem><para>At this point, you should be sure that the 
                     <filename>MACHINE</filename> variable 
                     in the <filename>local.conf</filename> file found in the 
-                    <filename>conf</filename> directory of the Yocto Project build directory
+                    <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.  
@@ -278,17 +296,17 @@
                         <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 installation.
-                    <note>If change out of your working directory after you 
+                    cross-toolchain generation.
+                    <note>If you change out of your working directory after you 
                         <filename>source</filename> the environment setup script and before you run
                         the <filename>bitbake</filename> command, the command might not work. 
                         Be sure to run the <filename>bitbake</filename> command immediately 
                         after checking or editing the <filename>local.conf</filename> but without 
                         changing out of your working directory.</note>
                     Once the <filename>bitbake</filename> command finishes, 
-                    the tarball for the cross-toolchain is generated within the Yocto Project build tree.
+                    the cross-toolchain is generated and populated within the build directory.
                     You will notice environment setup files for the cross-toolchain in the 
-                    Yocto Project build tree in the <filename>tmp</filename> directory.
+                    build directory in the <filename>tmp</filename> directory.
                     Setup script filenames contain the strings <filename>environment-setup</filename>.
                     </para></listitem>
             </orderedlist>
@@ -306,7 +324,7 @@
         then you can find this script in the <filename>&YOCTO_ADTPATH_DIR;</filename>
         directory.  
         If you installed the toolchain in the build tree, you can find the environment setup 
-        script for the toolchain in the Yocto Project build tree's <filename>tmp</filename> directory.
+        script for the toolchain in the build directory's <filename>tmp</filename> directory.
     </para>
 
     <para> 
@@ -344,14 +362,15 @@
         </para>
 
         <para> 
-            The Yocto Project provides basic kernel and filesystem images for several 
+            The Yocto Project ships basic kernel and filesystem images for several 
             architectures (<filename>x86</filename>, <filename>x86-64</filename>, 
             <filename>mips</filename>, <filename>powerpc</filename>, and <filename>arm</filename>) 
             that you can use unaltered in the QEMU emulator.  
-            These kernel images reside in the Yocto Project release 
+            These kernel images reside in the release 
             area - <ulink url='&YOCTO_MACHINES_DL_URL;'></ulink>
-            and are ideal for experimentation within Yocto Project.
-            For information on the image types you can build using the Yocto Project, see the
+            and are ideal for experimentation using Yocto Project.
+            For information on the image types you can build using the OpenEmbedded build system, 
+            see the
             "<ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Reference: Images</ulink>" appendix in  
             The Yocto Project Reference Manual.
         </para>
@@ -370,7 +389,7 @@
             you can do so one of two ways:
             <itemizedlist>
                 <listitem><para>Modify the <filename>conf/local.conf</filename> configuration in 
-                    the Yocto Project build directory and then rebuild the image.
+                    the build directory and then rebuild the image.
                     With this method, you need to modify the <filename>EXTRA_IMAGE_FEATURES</filename>
                     variable to have the value of "tools-debug" before rebuilding the image. 
                     Once the image is rebuilt, the <filename>tcf-agent</filename> will be included

documentation/bsp-guide/bsp-guide.xml

@@ -58,8 +58,13 @@
             </revision>
             <revision>
                 <revnumber>1.2</revnumber>
-                <date>TBD 2012</date>
-                <revremark>Work in progress for the Yocto Project 1.2 Release.</revremark>
+                <date>April 2012</date>
+                <revremark>Released with the Yocto Project 1.2 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.3</revnumber>
+                <date>Sometime in 2012</date>
+                <revremark>Released with the Yocto Project 1.3 Release.</revremark>
             </revision>
         </revhistory>
 

documentation/bsp-guide/bsp.xml

@@ -48,8 +48,8 @@
                 This root is what you add to the 
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-BBLAYERS'><filename>BBLAYERS</filename></ulink>
                 variable in the <filename>conf/bblayers.conf</filename> file found in the 
-                <ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-build-directory'>Yocto Project Build Directory</ulink>.
-                Adding the root allows the Yocto Project build system to recognize the BSP 
+                <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>.
+                Adding the root allows the OpenEmbedded build system to recognize the BSP 
                 definition and from it build an image.
                 Here is an example:
                 <literallayout class='monospaced'>
@@ -75,7 +75,7 @@
 
             <para>
                 Some layers function as a layer to hold other BSP layers.
-                An example of this type of layers is the <filename>meta-intel</filename> layer.  
+                An example of this type of layer is the <filename>meta-intel</filename> layer.  
                 The <filename>meta-intel</filename> layer contains over 10 individual BSP layers.
             </para>
 
@@ -99,13 +99,14 @@
             </para>
 
             <para>
-                The proposed form does have elements that are specific to the Yocto Project and 
-                OpenEmbedded build systems. 
+                The proposed form does have elements that are specific to the  
+                OpenEmbedded build system. 
                 It is intended that this information can be 
-                used by other systems besides Yocto Project and OpenEmbedded and that it will be simple
+                used by other build systems besides the OpenEmbedded build system 
+                and that it will be simple
                 to extract information and convert it to other formats if required.
-                Yocto Project, through its standard layers mechanism, can directly accept the format 
-                described as a layer.
+                The OpenEmbedded build system, through its standard layers mechanism, can directly 
+                accept the format described as a layer.
                 The BSP captures all 
                 the hardware-specific details in one place in a standard format, which is 
                 useful for any person wishing to use the hardware platform regardless of 
@@ -121,6 +122,15 @@
                 are separate components that happen to be combined in certain end products.
             </para>
 
+            <para>
+                Before looking at the common form for the file structure inside a BSP Layer, 
+                you should be aware that some requirements do exist in order for a BSP to 
+                be considered compliant with the Yocto Project.
+                For that list of requirements, see the
+                "<link linkend='released-bsp-requirements'>Released BSP Requirements</link>"
+                section.
+            </para>
+
             <para>
                 Below is the common form for the file structure inside a BSP Layer.
                 While you can use this basic form for the standard, realize that the actual structures
@@ -288,9 +298,10 @@
             </para>
 
             <para>
-                The <filename>conf/layer.conf</filename> file identifies the file structure as a Yocto 
-                Project layer, identifies the  
-                contents of the layer, and contains information about how Yocto Project should use it. 
+                The <filename>conf/layer.conf</filename> file identifies the file structure as a  
+                layer, identifies the  
+                contents of the layer, and contains information about how the build
+                system should use it. 
                 Generally, a standard boilerplate file such as the following works.
                 In the following example, you would replace "<filename>bsp</filename>" and 
                 "<filename>_bsp</filename>" with the actual name
@@ -324,7 +335,7 @@
 
             <para>
                 This file simply makes BitBake aware of the recipes and configuration directories.
-                The file must exist so that the Yocto Project build system can recognize the BSP.
+                The file must exist so that the OpenEmbedded build system can recognize the BSP.
             </para>
             </section>
 
@@ -339,7 +350,7 @@
 
             <para>
                 The machine files bind together all the information contained elsewhere
-                in the BSP into a format that the Yocto Project build system can understand. 
+                in the BSP into a format that the build system can understand. 
                 If the BSP supports multiple machines, multiple machine configuration files
                 can be present. 
                 These filenames correspond to the values to which users have set the 
@@ -379,8 +390,8 @@
 
             <para>
                 Tuning files are found in the <filename>meta/conf/machine/include</filename>
-                directory of the 
-                <ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-files'>Yocto Project Files</ulink>.
+                directory within the 
+                <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>.
                 Tuning files can also reside in the BSP Layer itself.  
                 For example, the <filename>ia32-base.inc</filename> file resides in the 
                 <filename>meta-intel</filename> BSP Layer in <filename>conf/machine/include</filename>.
@@ -432,7 +443,7 @@
                 formfactor recipe 
                 <filename>meta/recipes-bsp/formfactor/formfactor_0.0.bb</filename>, 
                 which is found in the 
-                <ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-files'>Yocto Project Files</ulink>.
+                <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>.
             </para></note>
             </section>
 
@@ -498,8 +509,8 @@
             </para>
             <para>
                 For your BSP, you typically want to use an existing Yocto Project kernel found in the 
-                <ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-files'>Yocto 
-                Project Files</ulink> at <filename>meta/recipes-kernel/linux</filename>.
+                <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink> 
+                at <filename>meta/recipes-kernel/linux</filename>.
                 You can append your specific changes to the kernel recipe by using a
                 similarly named append file, which is located in the BSP Layer (e.g. 
                 the <filename>meta-&lt;bsp_name&gt;/recipes-kernel/linux</filename> directory).
@@ -564,10 +575,10 @@
                 The file also points to some configuration fragments to use by setting the 
                 <filename>KERNEL_FEATURES</filename> variable.
                 The location for the configuration fragments is the kernel tree itself in the 
-                <ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-build-directory'>Yocto Project Build
-                Directory</ulink> under <filename>linux/meta</filename>.
+                <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink> 
+                under <filename>linux/meta</filename>.
                 Finally, the append file points to the specific commits in the 
-                <ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-files'>Yocto Project Files</ulink> Git 
+                <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.
             </para>
@@ -620,7 +631,7 @@
                 For example, if you are working with a local clone of the kernel repository, 
                 you could checkout the kernel's <filename>meta</filename> branch, make your changes, 
                 and then push the changes to the local bare clone of the kernel.
-                The result is that you directly add configuration options to the Yocto kernel 
+                The result is that you directly add configuration options to the  
                 <filename>meta</filename> branch for your BSP.
                 The configuration options will likely end up in that location anyway if the BSP gets 
                 added to the Yocto Project. 
@@ -644,6 +655,219 @@
             </section>
         </section>
 
+        <section id='requirements-and-recommendations-for-released-bsps'>
+            <title>Requirements and Recommendations for Released BSPs</title>
+
+            <para>
+                Certain requirements exist for a released BSP to be considered
+                compliant with the Yocto Project.
+                Additionally, a single recommendation also exists. 
+                This section describes the requirements and recommendation for
+                released BSPs.
+            </para>
+
+            <section id='released-bsp-requirements'>
+                <title>Released BSP Requirements</title>
+
+                <para>
+                    Before looking at BSP requirements, you should consider the following:
+                    <itemizedlist>
+                        <listitem><para>The requirements here assume the BSP layer is a well-formed, "legal"
+                            layer that can be added to the Yocto Project.
+                            For guidelines on creating a layer that meets these base requirements, see the
+                            "<link linkend='bsp-layers'>BSP Layers</link>" and the 
+                            "<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding
+                            and Creating Layers"</ulink> in the Yocto Project Development Manual.</para></listitem>
+                        <listitem><para>The requirements in this section apply regardless of how you 
+                            ultimately package a BSP.
+                            You should consult the packaging and distribution guidelines for your
+                            specific release process. 
+                            For an example of packaging and distribution requirements, see the 
+                            <ulink url='https://wiki.yoctoproject.org/wiki/Third_Party_BSP_Release_Process'>Third 
+                            Party BSP Release Process</ulink> wiki page.</para></listitem>
+                        <listitem><para>The requirements for the BSP as it is made available to a developer
+                            are completely independent of the released form of the BSP. 
+                            For example, the BSP metadata can be contained within a Git repository
+                            and could have a directory structure completely different from what appears
+                            in the officially released BSP layer.</para></listitem>
+                        <listitem><para>It is not required that specific packages or package 
+                            modifications exist in the BSP layer, beyond the requirements for general 
+                            compliance with the Yocto Project.
+                            For example, no requirement exists dictating that a specific kernel or 
+                            kernel version be used in a given BSP.</para></listitem>
+                    </itemizedlist>
+                </para>
+
+                <para>
+                    Following are the requirements for a released BSP that conforms to the 
+                    Yocto Project:
+                    <itemizedlist>
+                        <listitem><para><emphasis>Layer Name:</emphasis>
+                            The BSP must have a layer name that follows the Yocto
+                            Project standards.  
+                            For information on BSP layer names, see the
+                            "<link linkend='bsp-layers'>BSP Layers</link>" section.
+                            </para></listitem>
+                        <listitem><para><emphasis>File System Layout:</emphasis>
+                            When possible, use the same directory names in your 
+                            BSP layer as listed in the <filename>recipes.txt</filename> file.
+                            In particular, you should place recipes 
+                            (<filename>.bb</filename> files) and recipe
+                            modifications (<filename>.bbappend</filename> files) into  
+                            <filename>recipes-*</filename> subdirectories by functional area 
+                            as outlined in <filename>recipes.txt</filename>.
+                            If you cannot find a category in <filename>recipes.txt</filename>
+                            to fit a particular recipe, you can make up your own 
+                            <filename>recipe-*</filename> subdirectory.
+                            You can find <filename>recipes.txt</filename> in the
+                            <filename>meta</filename> directory of the 
+                            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>, 
+                            or in the OpenEmbedded Core Layer
+                            (<filename>openembedded-core</filename>) found at 
+                            <ulink url='http://git.openembedded.org/openembedded-core/tree/meta'></ulink>.
+                            </para>
+                            <para>Within any particular <filename>recipes-*</filename> category, the layout
+                            should match what is found in the OpenEmbedded Core
+                            Git repository (<filename>openembedded-core</filename>)
+                            or the source directory (<filename>poky</filename>).
+                            In other words, make sure you place related files in appropriately
+                            related <filename>recipes-*</filename> subdirectories specific to the
+                            recipe's function, or within a subdirectory containing a set of closely-related
+                            recipes.  
+                            The recipes themselves should follow the general guidelines
+                            for recipes used in the Yocto Project found in the 
+                            <ulink url='https://wiki.yoctoproject.org/wiki/Recipe_%26_Patch_Style_Guide'>Yocto
+                            Recipe and Patch Style Guide</ulink>.</para></listitem>
+                        <listitem><para><emphasis>License File:</emphasis>
+                            You must include a license file in the 
+                            <filename>meta-&lt;bsp_name&gt;</filename> directory.
+                            This license covers the BSP metadata as a whole.
+                            You must specify which license to use since there is no 
+                            default license if one is not specified.
+                            See the 
+                            <ulink url='&YOCTO_GIT_URL;/cgit.cgi/meta-intel/tree/meta-fishriver/COPYING.MIT'><filename>COPYING.MIT</filename></ulink>
+                            file for the Fish River BSP in the <filename>meta-fishriver</filename> BSP layer 
+                            as an example.</para></listitem>
+                        <listitem><para><emphasis>README File:</emphasis>
+                            You must include a <filename>README</filename> file in the 
+                            <filename>meta-&lt;bsp_name&gt;</filename> directory.
+                            See the 
+                            <ulink url='&YOCTO_GIT_URL;/cgit.cgi/meta-intel/tree/meta-fishriver/README'><filename>README</filename></ulink>
+                            file for the Fish River BSP in the <filename>meta-fishriver</filename> BSP layer 
+                            as an example.</para>
+                            <para>At a minimum, the <filename>README</filename> file should 
+                            contain the following:
+                            <itemizedlist>
+                                <listitem><para>A brief description about the hardware the BSP 
+                                    targets.</para></listitem>
+                                <listitem><para>A list of all the dependencies a 
+                                    on which a BSP layer depends.
+                                    These dependencies are typically a list of required layers needed 
+                                    to build the BSP.
+                                    However, the dependencies should also contain information regarding 
+                                    any other dependencies the BSP might have.</para></listitem>
+                                <listitem><para>Any required special licensing information.
+                                    For example, this information includes information on 
+                                    special variables needed to satisfy a EULA,
+                                    or instructions on information needed to build or distribute
+                                    binaries built from the BSP metadata.</para></listitem>
+                                <listitem><para>The name and contact information for the 
+                                    BSP layer maintainer.
+                                    This is the person to whom patches and questions should
+                                    be sent.</para></listitem>
+                                <listitem><para>Instructions on how to build the BSP using the BSP 
+                                    layer.</para></listitem>
+                                <listitem><para>Instructions on how to boot the BSP build from 
+                                    the BSP layer.</para></listitem>
+                                <listitem><para>Instructions on how to boot the binary images 
+                                    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 
+                                    binaries.</para></listitem>
+                            </itemizedlist></para></listitem>
+                        <listitem><para><emphasis>README.sources File:</emphasis>
+                            You must include a <filename>README.sources</filename> in the 
+                            <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.
+                            See the 
+                            <ulink url='&YOCTO_GIT_URL;/cgit.cgi/meta-intel/tree/meta-fishriver/README.sources'><filename>README.sources</filename></ulink>
+                            file for the Fish River BSP in the <filename>meta-fishriver</filename> BSP layer 
+                            as an example.</para></listitem>
+                        <listitem><para><emphasis>Layer Configuration File:</emphasis>
+                            You must include a <filename>conf/layer.conf</filename> in the
+                            <filename>meta-&lt;bsp_name&gt;</filename> directory.
+                            This file identifies the <filename>meta-&lt;bsp_name&gt;</filename>
+                            BSP layer as a layer to the build system.</para></listitem>
+                        <listitem><para><emphasis>Machine Configuration File:</emphasis>
+                            You must include a <filename>conf/machine/&lt;bsp_name&gt;.conf</filename>
+                            in the <filename>meta-&lt;bsp_name&gt;</filename> directory.
+                            This configuration file defines a machine target that can be built
+                            using the BSP layer.
+                            Multiple machine configuration files define variations of machine 
+                            configurations that are supported by the BSP.
+                            If a BSP supports more multiple machine variations, you need to 
+                            adequately describe each variation in the BSP 
+                            <filename>README</filename> file.
+                            Do not use multiple machine configuration files to describe disparate
+                            hardware. 
+                            Multiple machine configuration files should describe very similar targets.
+                            If you do have very different targets, you should create a separate
+                            BSP.
+                            <note>It is completely possible for a developer to structure the 
+                            working repository as a conglomeration of unrelated BSP
+                            files, and to possibly generate specifically targeted 'release' BSPs 
+                            from that directory using scripts or some other mechanism.  
+                            Such considerations are outside the scope of this document.</note>
+                            </para></listitem>
+                    </itemizedlist>
+                </para>
+            </section>
+
+            <section id='released-bsp-recommendations'>
+                <title>Released BSP Recommendations</title>
+
+                <para>
+                    Following are recommendations for a released BSP that conforms to the 
+                    Yocto Project:
+                    <itemizedlist>
+                        <listitem><para><emphasis>Bootable Images:</emphasis>
+                            BSP releases 
+                            can contain one or more bootable images.
+                            Including bootable images allows users to easily try out the BSP
+                            on their own hardware.</para>
+                            <para>In some cases, it might not be convenient to include a 
+                            bootable image. 
+                            In this case, you might want to make two versions of the 
+                            BSP available: one that contains binary images, and one
+                            that does not.
+                            The version that does not contain bootable images avoids 
+                            unnecessary download times for users not interested in the images.
+                            </para>
+                            <para>If you need to distribute a BSP and include bootable images or build kernel and
+                            filesystems meant to allow users to boot the BSP for evaluation
+                            purposes, you should put the images and artifacts within a 
+                            <filename>binary/</filename> subdirectory located in the 
+                            <filename>meta-&lt;bsp_name&gt;</filename> directory.
+                            <note>If you do include a bootable image as part of the BSP and the image
+                            was built by software covered by the GPL or other open source licenses,
+                            it is your responsibility to understand
+                            and meet all licensing requirements, which could include distribution
+                            of source files.</note></para></listitem>
+                        <listitem><para><emphasis>Use a Yocto Linux Kernel:</emphasis>
+                            Kernel recipes in the BSP should be based on a Yocto Linux kernel. 
+                            Basing your recipes on these kernels reduces the costs for maintaining 
+                            the BSP and increases its scalability.
+                            See the <filename>Yocto Linux Kernel</filename> category in the 
+                            <ulink url='&YOCTO_GIT_URL;/cgit.cgi'><filename>Yocto Source Repositories</filename></ulink>
+                            for these kernels.</para></listitem>
+                    </itemizedlist>
+                </para>
+            </section>
+        </section>
+
         <section id='customizing-a-recipe-for-a-bsp'>
             <title>Customizing a Recipe for a BSP</title>
 
@@ -688,7 +912,7 @@
                 for a component or components.
                 For these cases, you are required to accept the terms of a commercial or other 
                 type of license that requires some kind of explicit End User License Agreement (EULA).  
-                Once the license is accepted, the Yocto Project build system can then build and 
+                Once the license is accepted, the OpenEmbedded build system can then build and 
                 include the corresponding component in the final BSP image.
                 If the BSP is available as a pre-built image, you can download the image after
                 agreeing to the license or EULA.
@@ -731,13 +955,12 @@
             </para>
 
             <para> 
-                A couple different methods exist within the Yocto
-                Project build system to satisfy the licensing
-                requirements for an encumbered BSP.  
+                A couple different methods exist within the OpenEmbedded build system to 
+                satisfy the licensing requirements for an encumbered BSP.  
                 The following list describes them in order of preference:
 	        <orderedlist>
                     <listitem><para><emphasis>Use the <filename>LICENSE_FLAGS</filename> variable
-                        to define the Yocto Project recipes that have commercial or other types of
+                        to define the recipes that have commercial or other types of
                         specially-licensed packages:</emphasis>  
                         For each of those recipes, you can 
                         specify a matching license string in a
@@ -760,7 +983,7 @@
 		        restart the build to continue where it left off.
 		        During the build, the prompt will not appear again
 		        since you have satisfied the requirement.</para>
-                        <para>Once the appropriate license flags are whitelisted
+                        <para>Once the appropriate license flags are on the white list
 		        in the <filename>LICENSE_FLAGS_WHITELIST</filename> variable, you 
 		        can build the encumbered image with no change at all
 		        to the normal build process.</para></listitem> 
@@ -802,7 +1025,7 @@
                 The Yocto Project includes a couple of tools that enable
                 you to create a <link linkend='bsp-layers'>BSP layer</link> 
                 from scratch and do basic configuration and maintenance 
-                of the kernel without ever looking at a Yocto Project metadata file.
+                of the kernel without ever looking at a metadata file.
                 These tools are <filename>yocto-bsp</filename> and <filename>yocto-kernel</filename>,
                 respectively. 
 	    </para>
@@ -829,8 +1052,7 @@
 
                 <para>
                     Both tools reside in the <filename>scripts/</filename> subdirectory 
-                    of the <ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-files'>Yocto Project 
-                    Files</ulink>.
+                    of the <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>.
                     Consequently, to use the scripts, you must <filename>source</filename> the 
                     environment just as you would when invoking a build:
                     <literallayout class='monospaced'>
@@ -882,7 +1104,7 @@
              [-i &lt;JSON PROPERTY FILE&gt; | --infile &lt;JSON PROPERTY_FILE&gt;]
 
                  This command creates a Yocto BSP based on the specified parameters.
-                 The new BSP will be a new Yocto BSP layer contained by default within
+                 The new BSP will be a new BSP layer contained by default within
                  the top-level directory specified as 'meta-bsp-name'.  The -o option
                  can be used to place the BSP layer in a directory with a different
                  name and location.
@@ -919,7 +1141,7 @@
      ...
 			    
      NOTE: Once created, you should add your new layer to your
-     bblayers.conf file in order for it to be subsquently seen and
+     bblayers.conf file in order for it to be subsequently seen and
      modified by the yocto-kernel tool.
 			    
      NOTE for x86- and x86_64-based BSPs: The generated BSP assumes the
@@ -931,7 +1153,7 @@
                 <para>
                     Now that you know where these two commands reside and how to access information 
                     on them, you should find it relatively straightforward to discover the commands 
-                    necessary to create a BSP and perform basic kernel maintainence on that BSP using
+                    necessary to create a BSP and perform basic kernel maintenance on that BSP using
                     the tools.
                     The next sections provide a concrete starting point to expand on a few points that 
                     might not be immediately obvious or that could use further explanation.
@@ -990,7 +1212,7 @@
                     In every other way, this architecture is representative of how creating a BSP for
                     a 'real' machine would work.
                     The reason the example uses this architecture is because it is an emulated architecture
-                    and can easily be followed without requireing actual hardware.
+                    and can easily be followed without requiring actual hardware.
                 </para>
 
                 <para>
@@ -1059,7 +1281,7 @@
                             If you enter 'n', the script prompts you to further enter the kernel
                             you do want to use (e.g. 3.0, 3.2_preempt-rt, etc.).</para></listitem>
                         <listitem><para>Next, the script asks whether you would like to have a new 
-                            branch created especially for your BSPin the local 
+                            branch created especially for your BSP in the local 
                             <ulink url='&YOCTO_DOCS_DEV_URL;#local-kernel-files'>Linux Yocto Kernel</ulink> 
                             Git repository .
                             If not, then the script re-uses an existing branch.</para>
@@ -1088,8 +1310,8 @@
                         <listitem><para>The remainder of the prompts are routine. 
                             Defaults are accepted for each.</para></listitem>
                         <listitem><para>By default, the script creates the new BSP Layer in the 
-                            <ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-build-directory'>Yocto Project
-                            Build Directory</ulink>.</para></listitem>
+                            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>.
+                            </para></listitem>
                     </orderedlist> 
                 </para>
 
@@ -1114,8 +1336,7 @@
                 <title>Managing Kernel Patches and Config Items with yocto-kernel</title>
 
                 <para>
-                    Assuming you have created a Yocto Project 
-                    <link linkend='bsp-layers'>BSP Layer</link> using
+                    Assuming you have created a <link linkend='bsp-layers'>BSP Layer</link> using
                     <link linkend='creating-a-new-bsp-layer-using-the-yocto-bsp-script'>
                     <filename>yocto-bsp</filename></link> and you added it to your
                     <ulink url='&YOCTO_DOCS_REF_URL;#var-BBLAYERS'><filename>BBLAYERS</filename></ulink>
@@ -1126,7 +1347,7 @@
 
                 <para>
                     The <filename>yocto-kernel</filename> script allows you to add, remove, and list patches
-                    and kernel config settings to a Yocto Project BSP's kernel 
+                    and kernel config settings to a BSP's kernel 
                     <filename>.bbappend</filename> file.
                     All you need to do is use the appropriate sub-command.
                     Recall that the easiest way to see exactly what sub-commands are available

documentation/dev-manual/dev-manual-bsp-appendix.xml

@@ -23,19 +23,20 @@
 </para>
 
 <section id='getting-local-yocto-project-files-and-bsp-files'>
-    <title>Getting Local Yocto Project Files and BSP Files</title>
+    <title>Getting Local Source Files and BSP Files</title>
 
     <para>
-        You need to have the Yocto Project files available on your host system.  
-        You can get files through tarball extraction or by cloning the <filename>poky</filename>
-        Git repository.
+        You need to have the <link linkend='source-directory'>source directory</link>
+        available on your host system.  
+        You can set up this directory through tarball extraction or by cloning the 
+        <filename>poky</filename> Git repository.
         The following paragraphs describe both methods.
         For additional information, see the bulleted item
         "<link linkend='local-yp-release'>Yocto Project Release</link>".
     </para> 
 
     <para>
-        As mentioned, one way to get the Yocto Project files is to use Git to clone the 
+        As mentioned, one way to set up the source directory is to use Git to clone the 
         <filename>poky</filename> repository. 
         These commands create a local copy of the Git repository.
         By default, the top-level directory of the repository is named <filename>poky</filename>:
@@ -43,10 +44,10 @@
      $ git clone git://git.yoctoproject.org/poky
      $ cd poky
         </literallayout> 
-        Alternatively, you can start with the downloaded Poky "edison" tarball.
-        These commands unpack the tarball into a Yocto Project File directory structure.
-        By default, the top-level directory of the file structure is named
-        <filename>poky-&YOCTO_POKY;</filename>:
+        Alternatively, you can start with the downloaded Poky "&DISTRO_NAME;" tarball.
+        These commands unpack the tarball into a source directory structure.
+        By default, the top-level directory of the source directory is named
+        <filename>&YOCTO_POKY;</filename>:
         <literallayout class='monospaced'>
      $ tar xfj &YOCTO_POKY_TARBALL;
      $ cd &YOCTO_POKY;
@@ -54,20 +55,19 @@
         <note><para>If you're using the tarball method, you can ignore all the following steps that
         ask you to carry out Git operations.  
         You already have the results of those operations
-        in the form of the edison release tarballs.
+        in the form of the &DISTRO_NAME; release tarballs.
         Consequently, there is nothing left to do other than extract those tarballs into the 
         proper locations.</para>
 
         <para>Once you expand the released tarball, you have a snapshot of the Git repository
         that represents a specific release.
-        Fundamentally, this is different than having a local copy of the Yocto Project 
-        Git repository.  
+        Fundamentally, this is different than having a local copy of the Poky Git repository.  
         Given the tarball method, changes you make are building on top of a release.
         With the Git repository method you have the ability to track development
         and keep changes in revision control.
         See the 
         "<link linkend='repositories-tags-and-branches'>Repositories, Tags, and Branches</link>" section
-        for more discussion around these differneces.</para></note>
+        for more discussion around these differences.</para></note>
     </para>
 
     <para>
@@ -133,11 +133,12 @@
 
     <para>
         You need to have the base BSP layer on your development system.  
-        Similar to the local Yocto Project files, you can get the BSP 
+        Similar to the local <link linkend='source-directory'>source directory</link>, 
+        you can get the BSP 
         layer in a couple of different ways:  
         download the BSP tarball and extract it, or set up a local Git repository that 
-        has the Yocto Project BSP layers.  
-        You should use the same method that you used to get the local Yocto Project files earlier.
+        has the BSP layers.  
+        You should use the same method that you used to set up the source directory earlier.
         See "<link linkend='getting-setup'>Getting Setup</link>" for information on how to get 
         the BSP files.
     </para>
@@ -160,15 +161,15 @@
      $ cd meta-intel
         </literallayout> 
         Alternatively, you can start with the downloaded Crown Bay tarball.
-        You can download the edison version of the BSP tarball from the
+        You can download the &DISTRO_NAME; version of the BSP tarball from the
         <ulink url='&YOCTO_HOME_URL;/download'>Download</ulink> page of the 
         Yocto Project website. 
         Here is the specific link for the tarball needed for this example:
-        <ulink url='&YOCTO_MACHINES_DL_URL;/crownbay-noemgd/crownbay-noemgd-&DISTRO_NAME;-6.0.0.tar.bz2'></ulink>.
+        <ulink url='&YOCTO_MACHINES_DL_URL;/crownbay-noemgd/crownbay-noemgd-&DISTRO_NAME;-&POKYVERSION;.tar.bz2'></ulink>.
         Again, be sure that you are already in the <filename>poky</filename> directory
         as described previously before installing the tarball:
         <literallayout class='monospaced'>
-     $ tar xfj crownbay-noemgd-&DISTRO_NAME;-6.0.0.tar.bz2
+     $ tar xfj crownbay-noemgd-&DISTRO_NAME;-&POKYVERSION;.tar.bz2
      $ cd meta-intel
         </literallayout> 
     </para>
@@ -177,7 +178,7 @@
         The <filename>meta-intel</filename> directory contains all the metadata 
         that supports BSP creation.  
         If you're using the Git method, the following
-        step will switch to the edison metadata.
+        step will switch to the &DISTRO_NAME; metadata.
         If you're using the tarball method, you already have the correct metadata and can 
         skip to the next step.
         Because <filename>meta-intel</filename> is its own Git repository, you will want
@@ -185,6 +186,7 @@
         For this example we are going to use the <filename>&DISTRO_NAME;</filename> branch. 
         <literallayout class='monospaced'>
      $ git checkout -b &DISTRO_NAME; origin/&DISTRO_NAME;
+     Branch &DISTRO_NAME; set up to track remote branch &DISTRO_NAME; from origin.
      Switched to a new branch '&DISTRO_NAME;'
         </literallayout>
     </para>
@@ -194,8 +196,8 @@
     <title>Making a Copy of the Base BSP to Create Your New BSP Layer</title>
 
     <para>
-        Now that you have the local Yocto Project files and the base BSP files, you need to create a 
-        new layer for your BSP.
+        Now that you have set up the source directory and included the base BSP files, you need to 
+        create a new layer for your BSP.
         To create your BSP layer, you simply copy the <filename>meta-crownbay</filename>
         layer to a new layer.
     </para>
@@ -205,7 +207,7 @@
         The name should follow the BSP layer naming convention, which is 
         <filename>meta-&lt;name&gt;</filename>.  
         The following assumes your working directory is <filename>meta-intel</filename> 
-        inside the local Yocto Project files.  
+        inside your source directory.  
         To start your new layer, just copy the new layer alongside the existing
         BSP layers in the <filename>meta-intel</filename> directory:
         <literallayout class='monospaced'>
@@ -237,7 +239,7 @@
             First, since in this example the new BSP will not support EMGD, we will get rid of the 
             <filename>crownbay.conf</filename> file and then rename the 
             <filename>crownbay-noemgd.conf</filename> file to <filename>mymachine.conf</filename>.  
-            Much of what we do in the configuration directory is designed to help the Yocto Project 
+            Much of what we do in the configuration directory is designed to help the OpenEmbedded 
             build system work with the new layer and to be able to find and use the right software.  
             The following two commands result in a single machine configuration file named 
             <filename>mymachine.conf</filename>.  
@@ -261,10 +263,10 @@
 
         <para>
             Note that inside the <filename>mymachine.conf</filename> is the 
-            <filename>PREFERRED_PROVIDER_virtual/kernel</filename> statement. 
+            <filename>PREFERRED_VERSION_linux-yocto</filename> statement. 
             This statement identifies the kernel that the BSP is going to use.
             In this case, the BSP is using <filename>linux-yocto</filename>, which is the 
-            current Linux Yocto kernel based on the Linux 3.0 release. 
+            current Yocto Project kernel based on the Linux 3.2 release. 
         </para>
 
         <para>
@@ -283,6 +285,8 @@
      BBFILE_COLLECTIONS += "crownbay"
      BBFILE_PATTERN_crownbay := "^${LAYERDIR}/"
      BBFILE_PRIORITY_crownbay = "6"
+
+     LAYERDEPENDS_crownbay = "intel"
             </literallayout>
         </para>
 
@@ -293,6 +297,8 @@
      BBFILE_COLLECTIONS += "mymachine"
      BBFILE_PATTERN_mymachine := "^${LAYERDIR}/"
      BBFILE_PRIORITY_mymachine = "6"
+
+     LAYERDEPENDS_mymachine = "intel"
             </literallayout>
         </para>
     </section>
@@ -306,7 +312,7 @@
             When you create a BSP, you use these areas for appropriate recipes and append files.  
             Recipes take the form of <filename>.bb</filename> files, while append files take
             the form of <filename>.bbappend</filename> files.  
-            If you want to leverage the existing recipes the Yocto Project build system uses
+            If you want to leverage the existing recipes the OpenEmbedded build system uses
             but change those recipes, you can use <filename>.bbappend</filename> files.  
             All new recipes and append files for your layer must go in the layer’s 
             <filename>recipes-bsp</filename>, <filename>recipes-kernel</filename>, 
@@ -359,7 +365,7 @@
                 Now let's look at changes in <filename>recipes-core</filename>.
                 The file <filename>task-core-tools.bbappend</filename> in 
                 <filename>recipes-core/tasks</filename> appends the similarly named recipe
-                located in the local <link linkend='yocto-project-files'>Yocto Project Files</link> at 
+                located in the <link linkend='source-directory'>source directory</link> at 
                 <filename>meta/recipes-core/tasks</filename>.
                 The append file in our layer right now is Crown Bay-specific and supports 
                 EMGD and non-EMGD.
@@ -389,9 +395,9 @@
                 Recall that the BSP uses the <filename>linux-yocto</filename> kernel as determined
                 earlier in the <filename>mymachine.conf</filename>.
                 The recipe for that kernel is not located in the  
-                BSP layer but rather in the local Yocto Project files at 
+                BSP layer but rather in the source directory at 
                 <filename>meta/recipes-kernel/linux</filename> and is 
-                named <filename>linux-yocto_3.0.bb</filename>.
+                named <filename>linux-yocto_3.2.bb</filename>.
                 The <filename>SRCREV_machine</filename> and <filename>SRCREV_meta</filename>
                 statements point to the exact commits used by the Yocto Project development team
                 in their source repositories that identify the right kernel for our hardware.
@@ -404,7 +410,7 @@
             <para>
                 However, in the <filename>meta-mymachine</filename> layer in 
                 <filename>recipes-kernel/linux</filename> resides a <filename>.bbappend</filename>
-                file named <filename>linux-yocto_3.0.bbappend</filename> that 
+                file named <filename>linux-yocto_3.2.bbappend</filename> that 
                 appends information to the recipe of the same name in <filename>meta/recipes-kernel/linux</filename>.
                 Thus, the <filename>SRCREV</filename> statements in the append file override
                 the more general statements found in <filename>meta</filename>.
@@ -413,17 +419,20 @@
             <para>
                 The <filename>SRCREV</filename> statements in the append file currently identify
                 the kernel that supports the Crown Bay BSP with and without EMGD support.
-                Here are the statements: 
+                Here are the statements:
+                <note>The commit ID strings used in this manual might not match the actual commit
+                    ID strings found in the <filename>linux-yocto_3.2.bbappend</filename> file.
+                    For the example, this difference does not matter.</note> 
                 <literallayout class='monospaced'>
      SRCREV_machine_pn-linux-yocto_crownbay ?= \
-        "2247da9131ea7e46ed4766a69bb1353dba22f873"
+        "211fc7f4d10ec2b82b424286aabbaff9254b7cbd"
      SRCREV_meta_pn-linux-yocto_crownbay ?= \
-        "d05450e4aef02c1b7137398ab3a9f8f96da74f52"
+        "514847185c78c07f52e02750fbe0a03ca3a31d8f"
 
      SRCREV_machine_pn-linux-yocto_crownbay-noemgd ?= \
-        "2247da9131ea7e46ed4766a69bb1353dba22f873"
+        "211fc7f4d10ec2b82b424286aabbaff9254b7cbd"
      SRCREV_meta_pn-linux-yocto_crownbay-noemgd ?= \
-        "d05450e4aef02c1b7137398ab3a9f8f96da74f52"
+        "514847185c78c07f52e02750fbe0a03ca3a31d8f"
                 </literallayout>
             </para>
 
@@ -438,19 +447,19 @@
             </para>
 
             <para>  
-                To fix this situation in <filename>linux-yocto_3.0.bbappend</filename>,
+                To fix this situation in <filename>linux-yocto_3.2.bbappend</filename>,
                 we delete the two <filename>SRCREV</filename> statements that support 
                 EMGD (the top pair).
                 We also change the remaining pair to specify <filename>mymachine</filename>
                 and insert the commit identifiers to identify the kernel in which we 
                 are interested, which will be based on the <filename>atom-pc-standard</filename>
                 kernel.
-                In this case, because we're working with the edison branch of everything, we
+                In this case, because we're working with the &DISTRO_NAME; branch of everything, we
                 need to use the <filename>SRCREV</filename> values for the atom-pc branch
-                that are associated with the edison release.  
+                that are associated with the &DISTRO_NAME; release.  
                 To find those values, we need to find the <filename>SRCREV</filename>
-                values that edison uses for the atom-pc branch, which we find in the
-                <filename>poky/meta-yocto/recipes-kernel/linux/linux-yocto_3.0.bbappend</filename>
+                values that &DISTRO_NAME; uses for the atom-pc branch, which we find in the
+                <filename>poky/meta-yocto/recipes-kernel/linux/linux-yocto_3.2.bbappend</filename>
                 file.
             </para>
 
@@ -459,23 +468,21 @@
                 <filename>SRCREV_machine_atom-pc</filename> variable.  
                 The meta <filename>SRCREV</filename> isn't specified in this file, so it must be 
                 specified in the base kernel recipe in the
-                <filename>poky/meta/recipes-kernel/linux/linux-yocto_3.0.bb</filename>
-                file, in the <filename>SRCREV_meta variable</filename> found there.  
-                It happens to be the same as the value we already inherited from the 
-                <filename>meta-crownbay</filename> BSP.
+                <filename>poky/meta/recipes-kernel/linux/linux-yocto_3.2.bb</filename>
+                file, in the <filename>SRCREV_meta</filename>  variable found there.  
                 Here are the final <filename>SRCREV</filename> statements:
                 <literallayout class='monospaced'>
-     SRCREV_machine_pn-linux-yocto_mymachine ?= \ 
-        "1e18e44adbe79b846e382370eb29bc4b8cd5a1a0"
-     SRCREV_meta_pn-linux-yocto_mymachine ?= \ 
-        "d05450e4aef02c1b7137398ab3a9f8f96da74f52"
+     SRCREV_machine_pn-linux-yocto_mymachine ?= \
+        "f29531a41df15d74be5ad47d958e4117ca9e489e"
+     SRCREV_meta_pn-linux-yocto_mymachine ?= \
+        "b14a08f5c7b469a5077c10942f4e1aec171faa9d"
                 </literallayout>
             </para>
 
             <para>
                 In this example, we're using the <filename>SRCREV</filename> values we 
-                found already captured in the edison release because we're creating a BSP based on 
-                edison.  
+                found already captured in the &DISTRO_NAME; release because we're creating a BSP based on 
+                &DISTRO_NAME;.  
                 If, instead, we had based our BSP on the master branches, we would want to use 
                 the most recent <filename>SRCREV</filename> values taken directly from the kernel repo.
                 We will not be doing that for this example.
@@ -484,19 +491,19 @@
                 exact commit strings in the Yocto Project source repositories you need to change 
                 the <filename>SRCREV</filename> statements.  
                 You can find all the <filename>machine</filename> and <filename>meta</filename> 
-                branch points (commits) for the <filename>linux-yocto-3.0</filename> kernel at
-                <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/linux-yocto-3.0'></ulink>.  
+                branch points (commits) for the <filename>linux-yocto-3.2</filename> kernel at
+                <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/linux-yocto-3.2'></ulink>.  
             </para>
 
             <para>
                 If you need a little more assistance after going to the link then do the following:
                 <orderedlist>
                     <listitem><para>Expand the list of branches by clicking <filename>[…]</filename></para></listitem>
-                    <listitem><para>Click on the <filename>yocto/standard/common-pc/atom-pc</filename> 
+                    <listitem><para>Click on the <filename>standard/default/common-pc/atom-pc</filename> 
                         branch</para></listitem>
                     <listitem><para>Click on the commit column header to view the top commit</para></listitem>
                     <listitem><para>Copy the commit string for use in the 
-                        <filename>linux-yocto_3.0.bbappend</filename> file</para></listitem>
+                        <filename>linux-yocto_3.2.bbappend</filename> file</para></listitem>
                 </orderedlist>
             </para>
 
@@ -507,32 +514,34 @@
             </para>
 
             <para>
-                Also in the <filename>linux-yocto_3.0.bbappend</filename> file are 
+                Also in the <filename>linux-yocto_3.2.bbappend</filename> file are 
                 <filename>COMPATIBLE_MACHINE</filename>, <filename>KMACHINE</filename>, 
-                and <filename>KERNEL_FEATURES</filename> statements.  
+                and <filename>KBRANCH</filename> statements.  
                 Two sets of these exist: one set supports EMGD and one set does not.
                 Because we are not interested in supporting EMGD those three can be deleted.
                 The remaining three must be changed so that <filename>mymachine</filename> replaces
                 <filename>crownbay-noemgd</filename> and <filename>crownbay</filename>.
-                Because we are using the atom-pc branch for this new BSP, we can also find
-                the exact branch we need for the KMACHINE variable in our new BSP from the value
+                Because we are using the <filename>atom-pc</filename> branch for this new BSP, we can also find
+                the exact branch we need for the <filename>KMACHINE</filename>  
+                and <filename>KBRANCH</filename> variables in our new BSP from the value
                 we find in the
-                <filename>poky/meta-yocto/recipes-kernel/linux/linux-yocto_3.0.bbappend</filename>
+                <filename>poky/meta-yocto/recipes-kernel/linux/linux-yocto_3.2.bbappend</filename>
                 file we looked at in a previous step.  
-                In this case, the value we want is in the KMACHINE_atom-pc variable in that file.
-                Here is the final <filename>linux-yocto_3.0.bbappend</filename> file after all 
+                In this case, the values we want are in the <filename>KMACHINE_atom-pc</filename> variable
+                and the <filename>KBRANCH_atom-pc</filename> variables in that file.
+                Here is the final <filename>linux-yocto_3.2.bbappend</filename> file after all 
                 the edits:
                 <literallayout class='monospaced'>
      FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
 
      COMPATIBLE_MACHINE_mymachine = "mymachine"
-     KMACHINE_mymachine  = "yocto/standard/common-pc/atom-pc"
-     KERNEL_FEATURES_append_mymachine += " cfg/smp.scc"
+     KMACHINE_mymachine  = "atom-pc"
+     KBRANCH_mymachine  = "standard/default/common-pc/atom-pc"
 
      SRCREV_machine_pn-linux-yocto_mymachine ?= \
-        "1e18e44adbe79b846e382370eb29bc4b8cd5a1a0"
+        "f29531a41df15d74be5ad47d958e4117ca9e489e"
      SRCREV_meta_pn-linux-yocto_mymachine ?= \
-        "d05450e4aef02c1b7137398ab3a9f8f96da74f52"
+        "b14a08f5c7b469a5077c10942f4e1aec171faa9d"
                 </literallayout>
             </para>
         </section>
@@ -567,15 +576,14 @@
         <orderedlist>
             <listitem><para>Get the environment ready for the build by sourcing the environment 
                 script. 
-                The environment script is in the top-level of the local Yocto Project files
-                directory structure.
+                The environment script is in the top-level of the source directory.
                 The script has the string 
                 <filename>init-build-env</filename> in the file’s name.  
                 For this example, the following command gets the build environment ready:                       
                 <literallayout class='monospaced'>
      $ source oe-init-build-env yocto-build
                 </literallayout>
-                When you source the script a build directory is created in the current 
+                When you source the script, a build directory is created in the current 
                 working directory.  
                 In our example we were in the <filename>poky</filename> directory.  
                 Thus, entering the previous command created the <filename>yocto-build</filename> directory.  
@@ -600,11 +608,12 @@
                 both the <filename>BB_NUMBER_THREADS</filename> and <filename>PARALLEL_MAKE</filename> 
                 variables to twice the number of cores your system supports.</para></listitem>
             <listitem><para>Update the <filename>bblayers.conf</filename> file so that it includes 
-                the path to your new BSP layer.  
-                In this example you need to include the pathname to <filename>meta-mymachine</filename>.
-                For this example the 
-                <filename>BBLAYERS</filename> variable in the file would need to include the following path:
+                both the path to your new BSP layer and the path to the 
+                <filename>meta-intel</filename> layer.  
+                In this example, you need to include both these paths as part of the 
+                <filename>BBLAYERS</filename> variable:
                 <literallayout class='monospaced'>
+     $HOME/poky/meta-intel
      $HOME/poky/meta-intel/meta-mymachine
                 </literallayout></para></listitem>
         </orderedlist>
@@ -682,12 +691,12 @@
     </para>
 
     <para>
-        For reference, the sato image produced by the previous steps for edison 
+        For reference, the sato image produced by the previous steps for &DISTRO_NAME; 
         should look like the following in terms of size.
         If your sato image is much different from this,
         you probably made a mistake in one of the above steps:
         <literallayout class='monospaced'>
-     358715392 2011-11-01 19:11 core-image-sato-mymachine-20111101223904.hddimg
+     260538368 2012-04-27 01:44 core-image-sato-mymachine-20120427025051.hddimg
         </literallayout>
         <note>The previous instructions are also present in the README that was copied
         from meta-crownbay, which should also be updated to reflect the specifics of your

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

@@ -18,12 +18,13 @@
             sources where you can find more detail.
             For example, detailed information on Git, repositories and open source in general
             can be found in many places.  
-            Another example is how to get set up to use the Yocto Project, which our Yocto Project Quick Start covers.
+            Another example is how to get set up to use the Yocto Project, which our Yocto Project 
+            Quick Start covers.
         </para>
 
         <para>  
             The Yocto Project Development Manual, however, does provide detailed examples on how to create a 
-            Board Support Package (BSP), change the kernel source code, and re-configure the kernel.
+            Board Support Package (BSP), change the kernel source code, and reconfigure the kernel.
             You can find this information in the appendices of the manual.
         </para>
     </section>
@@ -44,13 +45,7 @@
                     applications.</para></listitem>
                 <listitem><para>An overview and understanding of the emulation environment used with 
                     the Yocto Project (QEMU).</para></listitem>
-<!--                <listitem><para>A discussion of target-level analysis techniques, tools, tips, 
-                    and tricks.</para></listitem>
-                <listitem><para>Considerations for deploying your final product.</para></listitem> -->
-                <listitem><para>An understanding of basic kernel architecture and 
-                    concepts.</para></listitem>
-<!--                <listitem><para>Information that will help you migrate an existing project to the 
-                    Yocto Project development environment.</para></listitem> -->
+                <listitem><para>An understanding of basic kernel architecture and concepts.</para></listitem>
                 <listitem><para>Many references to other sources of related information.</para></listitem>
             </itemizedlist>
         </para>
@@ -97,7 +92,7 @@
                 <listitem><para><emphasis> 
                     <ulink url='&YOCTO_DOCS_REF_URL;'>
                     The Yocto Project Reference Manual</ulink>:</emphasis> This manual is a reference 
-                    guide to the Yocto Project build component known as "Poky."  
+                    guide to the OpenEmbedded build system known as "Poky."  
                     The manual also contains a reference chapter on Board Support Package (BSP) 
                     layout.</para></listitem>
                 <listitem><para><emphasis>
@@ -117,7 +112,7 @@
                     some work flow examples.</para></listitem>
                 <listitem><para><emphasis>
                     <ulink url='http://www.youtube.com/watch?v=3ZlOu-gLsh0'>
-                    Yocto Eclipse Plug-in</ulink>:</emphasis> A step-by-step instructional video that
+                    Eclipse IDE Yocto Plug-in</ulink>:</emphasis> A step-by-step instructional video that
                     demonstrates how an application developer uses Yocto Plug-in features within 
                     the Eclipse IDE.</para></listitem>
                 <listitem><para><emphasis>
@@ -127,6 +122,17 @@
                     <ulink url='&YOCTO_HOME_URL;/download/yocto/yocto-project-1.1-release-notes-poky-&POKYVERSION;'>
                     Release Notes</ulink>:</emphasis> Features, updates and known issues for the current 
                     release of the Yocto Project.</para></listitem>
+                <listitem><para><emphasis>
+                    <ulink url='&YOCTO_HOME_URL;/projects/hob'>
+                    Hob</ulink>:</emphasis> A graphical user interface for BitBake. 
+                    Hob's primary goal is to enable a user to perform common tasks more easily.</para></listitem>
+                <listitem><para><emphasis>
+                    <ulink url='&YOCTO_HOME_URL;/documentation/build-appliance'>
+                    Build Appliance</ulink>:</emphasis> A bootable custom embedded Linux image you can 
+                    either build using a non-Linux development system (VMware applications) or download 
+                    from the Yocto Project website.
+                    See the <ulink url='&YOCTO_HOME_URL;/documentation/build-appliance'>Build Appliance</ulink>
+                    page for more information.</para></listitem>
                 <listitem><para><emphasis>
                     <ulink url='&YOCTO_BUGZILLA_URL;'>Bugzilla</ulink>:</emphasis>
                     The bug tracking application the Yocto Project uses.
@@ -141,28 +147,32 @@
                         <listitem><para><ulink url='&YOCTO_LISTS_URL;/listinfo/poky'></ulink> for a 
                             Yocto Project Discussions mailing list about the Poky build system.</para></listitem>
                         <listitem><para><ulink url='&YOCTO_LISTS_URL;/listinfo/yocto-announce'></ulink>
-                            for a mailing list to receive offical Yocto Project announcements for developments and 
+                            for a mailing list to receive official Yocto Project announcements for developments and
                             as well as Yocto Project milestones.</para></listitem>
                     </itemizedlist></para></listitem>
                 <listitem><para><emphasis>Internet Relay Chat (IRC):</emphasis>
                     Two IRC channels on freenode are available 
                     for Yocto Project and Poky discussions: <filename>#yocto</filename> and 
-                    <filename>#poky</filename>.</para></listitem>
+                    <filename>#poky</filename>, respectively.</para></listitem>
                 <listitem><para><emphasis>
                     <ulink url='&OH_HOME_URL;'>OpenedHand</ulink>:</emphasis>
-                    The company where the Yocto Project build system Poky was first developed.
-                    OpenedHand has since been acquired by Intel Corporation.</para></listitem>
+                    The company that initially developed the Poky project, which is the basis
+                    for the OpenEmbedded build system used by the Yocto Project.
+                    OpenedHand was acquired by Intel Corporation in 2008.</para></listitem>
                 <listitem><para><emphasis>
                     <ulink url='http://www.intel.com/'>Intel Corporation</ulink>:</emphasis>
-                    The company that acquired OpenedHand in 2008 and continues development on the 
-                    Yocto Project.</para></listitem>
+                    A multinational semiconductor chip manufacturer company whose Software and 
+                    Services Group created and supports the Yocto Project.
+                    Intel acquired OpenedHand in 2008.</para></listitem>
                 <listitem><para><emphasis>
                     <ulink url='&OE_HOME_URL;'>OpenEmbedded</ulink>:</emphasis>
-                    The upstream, generic, embedded distribution the Yocto Project build system (Poky) derives
-                    from and to which it contributes.</para></listitem>
+                    The build system used by the Yocto Project. 
+                    This project is the upstream, generic, embedded distribution from which the Yocto 
+                    Project derives its build system (Poky) from and to which it contributes.</para></listitem>
                 <listitem><para><emphasis>
                     <ulink url='http://developer.berlios.de/projects/bitbake/'>
-                    BitBake</ulink>:</emphasis> The tool used to process Yocto Project metadata.</para></listitem>
+                    BitBake</ulink>:</emphasis> The tool used by the OpenEmbedded build systm 
+                    to process project metadata.</para></listitem>
                 <listitem><para><emphasis>
                     <ulink url='http://bitbake.berlios.de/manual/'>
                     BitBake User Manual</ulink>:</emphasis> A comprehensive guide to the BitBake tool.

documentation/dev-manual/dev-manual-kernel-appendix.xml

@@ -12,17 +12,6 @@
         or even altering the source code itself.  
         This appendix presents simple examples that modify the kernel source code, 
         change the kernel configuration, and add a kernel source recipe.
-<!--        [WRITER'S NOTE:  I might want to work in information about applying a local
-            change to a kernel layer and also pushing a change upstream into the tree]
-        <orderedlist>
-            <listitem><para>Iteratively determine and set kernel configurations and make 
-                kernel recipe changes.</para></listitem>
-            <listitem><para>Apply your configuration changes to your local kernel layer.
-                </para></listitem>
-            <listitem><para>Push your configuration and recipe changes upstream into the 
-                Yocto Project source repositories to make them available to the community.
-                </para></listitem>
-        </orderedlist> -->
     </para>
 
     <section id='modifying-the-kernel-source-code'>
@@ -45,18 +34,17 @@
                 Briefly, you need the following: 
                 <itemizedlist>
                     <listitem><para>A local 
-                        <link linkend='yocto-project-files'>Yocto Project Files</link>
-                        Git repository</para></listitem>
-                    <listitem><para>The 
+                        <link linkend='source-directory'>source directory</link> for the 
+                        poky Git repository</para></listitem>
+                    <listitem><para>Local copies of the
                         <link linkend='poky-extras-repo'><filename>poky-extras</filename></link>
-                        Git repository placed within the local Yocto Project files Git 
-                        repository</para></listitem>  
+                        Git repository placed within the source directory.</para></listitem>  
                     <listitem><para>A bare clone of the 
-                        <link linkend='local-kernel-files'>Linux Yocto Kernel</link> upstream Git 
+                        <link linkend='local-kernel-files'>Yocto Project Kernel</link> upstream Git 
                         repository to which you want to push your modifications.
                         </para></listitem>
                     <listitem><para>A copy of that bare clone in which you make your source 
-                        modifcations</para></listitem>
+                        modifications</para></listitem>
                 </itemizedlist>
             </para>
 
@@ -71,37 +59,38 @@
             </para>
 
             <para>
-                <imagedata fileref="figures/kernel-example-repos.png" width="7in" depth="5in" 
+                <imagedata fileref="figures/kernel-example-repos-denzil.png" width="7in" depth="5in" 
                     align="center" scale="100" />
             </para>
 
             <para>
                 Here is a brief description of the four areas:
                 <itemizedlist>
-                    <listitem><para><emphasis>Local Yocto Project Files Git Repository:</emphasis> 
-                        This area contains all the metadata that supports building images in the 
-                        Yocto Project build environment - the local Yocto Project files.
-                        In this example, the local Yocto Project files Git repository also 
+                    <listitem><para><emphasis>Local Source Directory:</emphasis> 
+                        This area contains all the metadata that supports building images 
+                        using the OpenEmbedded build system.
+                        In this example, the source directory also 
                         contains the build directory, which contains the configuration directory 
                         that lets you control the build.
-                        In this example, the repository also contains the 
+                        Also in this example, the source directory contains local copies of the 
                         <filename>poky-extras</filename> Git repository.</para>
                         <para>See the bulleted item
                         "<link linkend='local-yp-release'>Yocto Project Release</link>"
-                        for information on how to get these files.</para></listitem>
-                    <listitem><para><emphasis><filename>poky-extras</filename> Git Repository:</emphasis> 
+                        for information on how to get these files on your local system.</para></listitem>
+                    <listitem><para><emphasis>Local copies of the<filename>poky-extras</filename> 
+                        Git Repository:</emphasis> 
                         This area contains the <filename>meta-kernel-dev</filename> layer, 
                         which is where you make changes that append the kernel build recipes.
                         You edit <filename>.bbappend</filename> files to locate your 
                         local kernel source files and to identify the kernel being built.
-                        This Git repository is a gathering place for extensions to the Linux Yocto 
+                        This Git repository is a gathering place for extensions to the Yocto Project
                         (or really any) kernel recipes that faciliate the creation and development
                         of kernel features, BSPs or configurations.</para>
                         <para>See the bulleted item
                         "<link linkend='poky-extras-repo'>The 
                         <filename>poky-extras</filename> Git Repository</link>" 
                         for information on how to get these files.</para></listitem>                
-                    <listitem><para><emphasis>Bare Clone of the Linux Yocto kernel:</emphasis> 
+                    <listitem><para><emphasis>Bare Clone of the Yocto Project kernel:</emphasis> 
                         This bare Git repository tracks the upstream Git repository of the Linux 
                         Yocto kernel source code you are changing.
                         When you modify the kernel you must work through a bare clone.
@@ -111,15 +100,15 @@
                         <filename>poky-extras</filename> repository points to the bare clone
                         so that the build process can locate the locally changed source files.</para>
                         <para>See the bulleted item
-                        "<link linkend='local-kernel-files'>Linux Yocto Kernel</link>"
+                        "<link linkend='local-kernel-files'>Yocto Project Kernel</link>"
                         for information on how to set up the bare clone.
                         </para></listitem>
-                    <listitem><para><emphasis>Copy of the Linux Yocto Kernel Bare Clone:</emphasis>
+                    <listitem><para><emphasis>Copy of the Yocto Project Kernel Bare Clone:</emphasis>
                         This Git repository contains the actual source files that you modify.  
                         Any changes you make to files in this location need to ultimately be pushed
                         to the bare clone using the <filename>git push</filename> command.</para>
                         <para>See the bulleted item
-                        "<link linkend='local-kernel-files'>Linux Yocto Kernel</link>"
+                        "<link linkend='local-kernel-files'>Yocto Project Kernel</link>"
                         for information on how to set up the bare clone.
                         <note>Typically, Git workflows follow a scheme where changes made to a local area 
                         are pulled into a Git repository.
@@ -133,50 +122,65 @@
         </section>
 
         <section id='setting-up-the-local-yocto-project-files-git-repository'>
-            <title>Setting Up the Local Yocto Project Files Git Repository</title>
+            <title>Setting Up the Local Source Directory</title>
 
             <para>
-                You can get the local Yocto Project files through tarball extraction or by 
+                You can set up the source directory through tarball extraction or by 
                 cloning the <filename>poky</filename> Git repository.  
                 This example uses <filename>poky</filename> as the root directory of the 
-                local Yocto Project files Git repository.
+                local source directory.
                 See the bulleted item
                 "<link linkend='local-yp-release'>Yocto Project Release</link>"
                 for information on how to get these files.
             </para>
 
             <para>
-                Once you have the repository set up, 
+                Once you have source directory set up, 
                 you have many development branches from which you can work. 
-                From inside the repository you can see the branch names and the tag names used 
-                in the Git repository using either of the following two commands:
+                From inside the local repository you can see the branch names and the tag names used 
+                in the upstream Git repository by using either of the following commands:
                 <literallayout class='monospaced'>
      $ cd poky
      $ git branch -a
      $ git tag -l
                 </literallayout> 
-                This example uses the Yocto Project 1.1 Release code named "edison", 
-                which maps to the <filename>edison</filename> branch in the repository. 
-                The following commands create and checkout the local <filename>edison</filename>
+                This example uses the Yocto Project &DISTRO; Release code named "&DISTRO_NAME;", 
+                which maps to the <filename>&DISTRO_NAME;</filename> branch in the repository. 
+                The following commands create and checkout the local <filename>&DISTRO_NAME;</filename>
                 branch:
                 <literallayout class='monospaced'>
      $ git checkout -b &DISTRO_NAME; origin/&DISTRO_NAME;
-     Branch edison set up to track remote branch &DISTRO_NAME; from origin.
+     Branch &DISTRO_NAME; set up to track remote branch &DISTRO_NAME; from origin.
      Switched to a new branch '&DISTRO_NAME;'
                 </literallayout>
             </para>
         </section>
 
         <section id='setting-up-the-poky-extras-git-repository'>
-            <title>Setting Up the poky-extras Git Repository</title>
+            <title>Setting Up the Local poky-extras Git Repository</title>
 
             <para>
-                This example places the <filename>poky-extras</filename> Git repository inside
-                of <filename>poky</filename>.
-                See the bulleted item
-                "<link linkend='poky-extras-repo'>The 
+                This example creates a local copy of the <filename>poky-extras</filename> Git 
+                repository inside the <filename>poky</filename> source directory.
+                See the bulleted item "<link linkend='poky-extras-repo'>The 
                 <filename>poky-extras</filename> Git Repository</link>" 
-                for information on how to get the <filename>poky-extras</filename> repository.
+                for information on how to set up a local copy of the
+                <filename>poky-extras</filename> repository.
+            </para>
+
+            <para>
+                Because this example uses the Yocto Project &DISTRO; Release code 
+                named "&DISTRO_NAME;", which maps to the <filename>&DISTRO_NAME;</filename> 
+                branch in the repository, you need to be sure you are using that 
+                branch for <filename>poky-extra</filename>.
+                The following commands create and checkout the local 
+                branch you are using for the <filename>&DISTRO_NAME;</filename>
+                branch:
+                <literallayout class='monospaced'>
+     $ git checkout -b &DISTRO_NAME; origin/&DISTRO_NAME;
+     Branch &DISTRO_NAME; set up to track remote branch &DISTRO_NAME; from origin.
+     Switched to a new branch '&DISTRO_NAME;'
+                </literallayout>
             </para>
         </section>
 
@@ -184,11 +188,11 @@
             <title>Setting Up the Bare Clone and its Copy</title>
 
             <para>
-                This example modifies the <filename>linux-yocto-3.0-1.1.x</filename> kernel.
+                This example modifies the <filename>linux-yocto-3.2</filename> kernel.
                 Thus, you need to create a bare clone of that kernel and then make a copy of the 
                 bare clone.
                 See the bulleted item
-                "<link linkend='local-kernel-files'>Linux Yocto Kernel</link>" 
+                "<link linkend='local-kernel-files'>Yocto Project Kernel</link>" 
                 for information on how to do that.
             </para>
 
@@ -196,15 +200,16 @@
                 The bare clone exists for the kernel build tools and simply as the receiving end 
                 of <filename>git push</filename>
                 commands after you make edits and commits inside the copy of the clone.
-                The copy (<filename>my-linux-yocto-3.0-1.1.x-work</filename> in this example) has to have 
+                The copy (<filename>my-linux-yocto-3.2-work</filename> in this example) has to have 
                 a local branch created and checked out for your work.
                 This example uses <filename>common-pc-base</filename> as the local branch.
                 The following commands create and checkout the branch:
                 <literallayout class='monospaced'>
-     $ cd ~/my-linux-yocto-3.0-1.1.x-work
-     $ git checkout -b common-pc-base origin/yocto/standard/common-pc/base
+     $ cd ~/my-linux-yocto-3.2-work
+     $ git checkout -b common-pc-base origin/standard/default/common-pc/base
+     Checking out files: 100% (532/532), done.
      Branch common-pc-base set up to track remote branch 
-        yocto/standard/common-pc/base from origin.
+        standard/default/common-pc/base from origin.
      Switched to a new branch 'common-pc-base'
                 </literallayout>
             </para>
@@ -296,7 +301,7 @@
 
             <para>
                 The file you change in this example is named <filename>calibrate.c</filename>
-                and is located in the <filename>my-linux-yocto-3.0-1.1.x-work</filename> Git repository
+                and is located in the <filename>my-linux-yocto-3.2-work</filename> Git repository
                 (the copy of the bare clone) in <filename>init</filename>.
                 This example simply inserts several <filename>printk</filename> statements
                 at the beginning of the <filename>calibrate_delay</filename> function.
@@ -307,10 +312,11 @@
                 <literallayout class='monospaced'>
      void __cpuinit calibrate_delay(void)
      {
-	     unsigned long lpj;
-	     static bool printed;
+     	unsigned long lpj;
+     	static bool printed;
+     	int this_cpu = smp_processor_id();
 
-         if (preset_lpj) {
+     	if (per_cpu(cpu_loops_per_jiffy, this_cpu)) {
                .
                .
                .
@@ -319,19 +325,21 @@
 
            <para>
                Here is the altered code showing five new <filename>printk</filename> statements 
-               just after initializing <filename>lps_precision</filename>:
+               near the top of the function:
                 <literallayout class='monospaced'>
      void __cpuinit calibrate_delay(void)
      {
-	     unsigned long lpj;
-	     static bool printed;
+         unsigned long lpj;
+         static bool printed;
+         int this_cpu = smp_processor_id();
+
          printk("*************************************\n");
          printk("*                                   *\n");
          printk("*        HELLO YOCTO KERNEL         *\n");
          printk("*                                   *\n");
          printk("*************************************\n");
 
-         if (preset_lpj) {
+     	if (per_cpu(cpu_loops_per_jiffy, this_cpu)) {
                .
                .
                .
@@ -350,14 +358,14 @@
            <para>
                Once the source code has been modified, you need to use Git to push the changes to 
                the bare clone.  
-               If you do not push the changes, then the Yocto Project build system will not pick 
+               If you do not push the changes, then the OpenEmbedded build system will not pick 
                up the changed source files.
            </para>
 
            <para>
                The following command pushes the changes to the bare clone:
                <literallayout class='monospaced'>
-     $ git push origin common-pc-base:yocto/standard/common-pc/base
+     $ git push origin common-pc-base:standard/default/common-pc/base
                </literallayout>
            </para>
        </section>
@@ -367,7 +375,7 @@
 
            <para>
                At this point, the source has been changed and pushed.
-               The example now defines some variables used by the Yocto Project build system 
+               The example now defines some variables used by the OpenEmbedded build system 
                to locate your kernel source.
                You essentially need to identify where to find the kernel recipe and the changed source code.
                You also need to be sure some basic configurations are in place that identify the 
@@ -416,37 +424,35 @@
        "
                        </literallayout></para></listitem>
                    <listitem><para><emphasis>Identify Your Source Files:</emphasis> In the 
-                       <filename>linux-yocto_3.0.bbappend</filename> file located in the 
+                       <filename>linux-yocto_3.2.bbappend</filename> file located in the 
                        <filename>poky-extras/meta-kernel-dev/recipes-kernel/linux</filename>
                        directory, you need to identify the location of the 
                        local source code, which in this example is the bare clone named
-                       <filename>linux-yocto-3.0-1.1.x.git</filename>.
+                       <filename>linux-yocto-3.2.git</filename>.
                        To do this, set the <filename>KSRC_linux_yocto</filename> variable to point to your
-                       local <filename>linux-yocto-3.0-1.1.x.git</filename> Git repository by adding the 
+                       local <filename>linux-yocto-3.2.git</filename> Git repository by adding the 
                        following statement.
                        Be sure to substitute your user information in the statement:
                        <literallayout class='monospaced'>
-     KSRC_linux_yocto ?= /home/scottrif/linux-yocto-3.0-1.1.x.git
-                       </literallayout></para></listitem>
-                   <listitem><para><emphasis>Specify the Kernel Machine:</emphasis> Also in the 
-                       <filename>linux-yocto_3.0.bbappend</filename> file, you need to specify
-                       the kernel machine with the following statement:
-                       <literallayout class='monospaced'>
-     KMACHINE_qemux86 = "yocto/standard/common-pc/base"
+     KSRC_linux_yocto_3_2 ?= "/home/scottrif/linux-yocto-3.2.git"
                        </literallayout></para></listitem>
                </itemizedlist>
            </para>
 
            <note>
-               Before attempting to build the modified kernel, there is one more set of changes you 
+               <para>Before attempting to build the modified kernel, there is one more set of changes you 
                need to make in the <filename>meta-kernel-dev</filename> layer.
                Because all the kernel <filename>.bbappend</filename> files are parsed during the 
                build process regardless of whether you are using them or not, you should either 
                comment out the <filename>COMPATIBLE_MACHINE</filename> statements in all 
-               unused <filename>.bbappend</filename> files.
-               Alternatively, you can simply remove all the files 
+               unused <filename>.bbappend</filename> files, or simply remove (or rename) all the files 
                except the one your are using for the build 
-               (i.e. <filename>linux-yocto_3.0.bbappend</filename> in this example).
+               (i.e. <filename>linux-yocto_3.2.bbappend</filename> in this example).</para>
+               <para>If you do not make one of these two adjustments, your machine will be compatible
+               with all the kernel recipes in the <filename>meta-kernel-dev</filename> layer. 
+               When your machine is comapatible with all the kernel recipes, the build attempts
+               to build all kernels in the layer.
+               You could end up with build errors blocking your work.</para>
            </note>            
        </section>
 
@@ -471,7 +477,7 @@
      $ bitbake -c cleanall linux-yocto
                         </literallayout></para>
                         <para><note>Never remove any files by hand from the <filename>tmp/deploy</filename>
-                        directory insided the local Yocto Project files build directory.
+                        directory insided the build directory.
                         Always use the BitBake <filename>cleanall</filename> task to clear
                         out previous builds.</note></para></listitem>
                     <listitem><para>Next, build the kernel image using this command:
@@ -505,8 +511,8 @@
         <title>Changing the Kernel Configuration</title>
 
         <para>
-            This example changes the default behavior, which is "off", of the Symmetric 
-            Multi-processing Support (<filename>CONFIG_SMP</filename>) to "on".  
+            This example changes the default behavior, which is "on", of the Symmetric 
+            Multi-processing Support (<filename>CONFIG_SMP</filename>) to "off".  
             It is a simple example that demonstrates how to reconfigure the kernel.
         </para>
 
@@ -516,42 +522,42 @@
             <para>
                 If you took the time to work through the example that modifies the kernel source code 
                 in "<link linkend='modifying-the-kernel-source-code'>Modifying the Kernel Source
-                Code</link>" you should already have the Yocto Project files set up on your 
+                Code</link>" you should already have the source directory set up on your 
                 host machine.
-                If this is the case, go to then next section titled
+                If this is the case, go to the next section, which is titled
                 "<link linkend='examining-the-default-config-smp-behavior'>Examining the Default
-                <filename>CONFIG_SMP</filename> Behavior</link>" and continue with the 
+                <filename>CONFIG_SMP</filename> Behavior</link>", and continue with the 
                 example.
             </para>
 
             <para>
-                If you don't have the Yocto Project files established on your system, 
+                If you don't have the source directory established on your system, 
                 you can get them through tarball extraction or by 
                 cloning the <filename>poky</filename> Git repository.  
                 This example uses <filename>poky</filename> as the root directory of the 
-                local Yocto Project files Git repository.
+                <link linkend='source-directory'>source directory</link>.
                 See the bulleted item
                 "<link linkend='local-yp-release'>Yocto Project Release</link>"
                 for information on how to get these files.
             </para>
 
             <para>
-                Once you have the repository set up, 
+                Once you have the local copy of the repository set up, 
                 you have many development branches from which you can work. 
                 From inside the repository you can see the branch names and the tag names used 
-                in the Git repository using either of the following two commands:
+                in the upstream Git repository using either of the following commands:
                 <literallayout class='monospaced'>
      $ cd poky
      $ git branch -a
      $ git tag -l
                 </literallayout> 
-                This example uses the Yocto Project 1.1.1 Release code named "&DISTRO_NAME;", 
+                This example uses the Yocto Project &DISTRO; Release code named "&DISTRO_NAME;", 
                 which maps to the <filename>&DISTRO_NAME;</filename> branch in the repository. 
                 The following commands create and checkout the local <filename>&DISTRO_NAME;</filename>
                 branch:
                 <literallayout class='monospaced'>
      $ git checkout -b &DISTRO_NAME; origin/&DISTRO_NAME;
-     Branch edison set up to track remote branch &DISTRO_NAME; from origin.
+     Branch &DISTRO_NAME; set up to track remote branch &DISTRO_NAME; from origin.
      Switched to a new branch '&DISTRO_NAME;'
                 </literallayout>
             </para>
@@ -612,11 +618,11 @@
             <title>Examining the Default&nbsp;&nbsp;<filename>CONFIG_SMP</filename> Behavior</title>
 
             <para>
-                By default, <filename>CONFIG_SMP</filename> supports single processor machines.
+                By default, <filename>CONFIG_SMP</filename> supports multiple processor machines.
                 To see this default setting from within the QEMU emulator, boot your image using 
                 the emulator as follows:
                 <literallayout class='monospaced'>
-     $ runqemu qemux86 qemuparams="-smp 2"
+     $ runqemu qemux86 qemuparams="-smp 4"
                 </literallayout>
             </para>
 
@@ -624,11 +630,25 @@
                 Login to the machine using <filename>root</filename> with no password.
                 After logging in, enter the following command to see how many processors are 
                 being supported in the emulator.
-                The emulator reports support for a single processor:
+                The emulator reports support for the number of processors you specified using 
+                the <filename>-smp</filename> option, four in this case:
                 <literallayout class='monospaced'>
      # cat /proc/cpuinfo | grep processor 
      processor       : 0
+     processor       : 1
+     processor       : 2
+     processor       : 3
      #
+                </literallayout>
+                To check the setting for <filename>CONFIG_SMP</filename>, you can use the 
+                following command:
+                <literallayout class='monospaced'>
+     zcat /proc/config.gz | grep CONFIG_SMP
+                </literallayout>
+                The console returns the following showing that multi-processor machine support
+                is set:
+                <literallayout class='monospaced'>
+     CONFIG_SMP=y
                 </literallayout>
                 Logout of the emulator using the <filename>exit</filename> command and 
                 then close it down.
@@ -643,7 +663,7 @@
                 to set kernel configurations.
                 You need to run <filename>menuconfig</filename> inside the Yocto BitBake environment.
                 Thus, the environment must be set up using the <filename>oe-init-build-env</filename>
-                script found in the Yocto Project files Git repository build directory.
+                script found in the build directory.
                 If you have not sourced this script do so with the following commands:
                 <literallayout class='monospaced'>
      $ cd ~/poky
@@ -654,12 +674,14 @@
             <para>
                 After setting up the environment to run <filename>menuconfig</filename>, you are ready 
                 to use the tool to interactively change the kernel configuration.
-                In this example, we are basing our changes on the <filename>linux-yocto-3.0-1.1.x</filename>
+                In this example, we are basing our changes on the <filename>linux-yocto-3.2</filename>
                 kernel.
-                The Yocto Project build environment recognizes this kernel as 
+                The OpenEmbedded build system recognizes this kernel as 
                 <filename>linux-yocto</filename>.
-                Thus, the following command from the shell in which you previously sourced the 
-                environment initialization script launches <filename>menuconfig</filename>:
+                Thus, the following commands from the shell in which you previously sourced the 
+                environment initialization script cleans the shared state cache and the 
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-WORKDIR'><filename>WORKDIR</filename></ulink>
+                directory and then builds and launches <filename>menuconfig</filename>:
                 <literallayout class='monospaced'>
      $ bitbake linux-yocto -c menuconfig
                 </literallayout>
@@ -671,31 +693,33 @@
                 You can find it at <filename>Processor Type and Features</filename>.
                 The configuration selection is 
                 <filename>Symmetric Multi-processing Support</filename>.
-                After using the arrow keys to highlight this selection, press "y" to select it.
+                After using the arrow keys to highlight this selection, press "n" to turn it off.
                 Then, exit out and save your selections.
             </para>
 
             <para>
                 Once you save the selection, the <filename>.config</filename> configuration file
                 is updated. 
-                This is the file that the build system uses to configure the Linux Yocto kernel
+                This is the file that the build system uses to configure the Yocto Project kernel
                 when it is built. 
-                You can find and examine this file in the Yocto Project files Git repository in 
-                the build directory. 
-                This example uses the following.
-                Note that this example directory is artificially split and many of the characters 
-                in the actually filename are omitted in order to make it more
-                readable:
+                You can find and examine this file in the build directory. 
+                This example uses the following:
                 <literallayout class='monospaced'>
-     ~/poky/build/tmp/work/qemux86-poky-linux/linux-yocto-2.6.37+git1+84f...
-        ...r20/linux-qemux86-standard-build
+     ~/poky/build/tmp/work/qemux86-poky-linux/linux-yocto-3.2.11+git1+84f...
+        ...656ed30-r1/linux-qemux86-standard-build
                 </literallayout>
+                <note>
+                    The previous example directory is artificially split and many of the characters 
+                    in the actual filename are omitted in order to make it more readable.
+                    Also, depending on the kernel you are using, the exact pathname might differ 
+                    slightly.
+                </note>
             </para>
 
             <para>
                 Within the <filename>.config</filename> file, you can see the following setting:
                 <literallayout class='monospaced'>
-     CONFIG_SMP=y
+     # CONFIG_SMP is not set
                 </literallayout>
             </para>
 
@@ -712,7 +736,7 @@
                 <note>
                     Be sure to make a copy of the <filename>.config</filename> and don't just
                     rename it. 
-                    The Yocto Project build system needs an existing <filename>.config</filename>
+                    The build system needs an existing <filename>.config</filename>
                     from which to work.
                 </note>
             </para>
@@ -723,17 +747,16 @@
 
             <para>
                 At this point, you are ready to recompile your kernel image with 
-                the new setting in effect using the BitBake commands below:
+                the new setting in effect using the BitBake command below:
                 <literallayout class='monospaced'>
-     $ bitbake linux-yocto -c compile -f
      $ bitbake linux-yocto
                 </literallayout>
             </para>
  
             <para>
-                Now run the QEMU emulator:
+                Now run the QEMU emulator and pass it the same multi-processor option as before:
                 <literallayout class='monospaced'>
-     $ runqemu qemux86 qemuparams="-smp 2"
+     $ runqemu qemux86 qemuparams="-smp 4"
                 </literallayout>
             </para>
 
@@ -743,13 +766,22 @@
                 <literallayout class='monospaced'>
      # cat /proc/cpuinfo | grep processor 
      processor       : 0
-     processor       : 1
      #
                 </literallayout>
             </para>
 
             <para>
-                From the output, you can see that you have successfully reconfigured the kernel.
+                From the output, you can see that the kernel no longer supports multi-processor systems.
+                The output indicates support for a single processor.  You can verify the 
+                <filename>CONFIG_SMP</filename> setting by using this command:
+                <literallayout class='monospaced'>
+     zcat /proc/config.gz | grep CONFIG_SMP
+                </literallayout>
+                The console returns the following output:
+                <literallayout class='monospaced'>
+     # CONFIG_SMP is not set
+                </literallayout>
+                You have successfully reconfigured the kernel.
             </para>
         </section>
     </section>
@@ -767,352 +799,8 @@
                 width="2in" depth="3in" align="center" scalefit="1" />
         </para> 
     </section> 
-
-
-
-<!--        <section id='is-vfat-supported'>
-            <title>Is VFAT Supported?</title>
-            
-            <para>
-                <literallayout class='monospaced'>
-I entered runqemu qemux86 and it fires upthis fires up the emulator and uses the
-image and filesystem in the build area created in the previous section.
-
-Then I copied over a pre-created and formated 5.2MB VFAT file named vfat.img.
-I did this with scp vfat.img root@192.168.7.2:
-The file is in the root directory.
-I had to do this because the mkfs.vfat vfat.img command does not work.
-mkfs is not recognized in the qemu terminal session.
-
-when I try mount -o loop -t vfat vfat.img mnt/ I get the error
-mount: can't set up loop device: No space left on device.
-This error is because the loop module is not currently in the kernel image.
-However, this module is available in the 
-build area in the tarball modules-2.6.37.6-yocto-starndard+-20-qemux86.tgz.
-You can add this to the kernel image by adding the 
-IMAGE_INSTALL += " kernel-module-loop" statement at the top of the local.conf
-file in the build area and then rebuilding the kernel using bitbake.
-It should just build whatever is necessary and not go through an entire build again.
-
-
-
-
-                The <filename>menuconfig</filename> tool provides an interactive method with which
-                to set kernel configurations.
-                In order to use <filename>menuconfig</filename> from within the BitBake environment
-                you need to source an environment setup script.
-                This script is located in the local Yocto Project file structure and is called
-                <filename>oe-init-build-env</filename>.
-            </para>
-
-            <para>
-                The following command sets up the environment:
-                <literallayout class='monospaced'>
-     $ cd ~/poky
-     $ source oe-init-build-env
-     $ runqemu qemux86
-     Continuing with the following parameters:
-     KERNEL: [/home/scottrif/poky/build/tmp/deploy/images/bzImage-qemux86.bin]
-     ROOTFS: [/home/scottrif/poky/build/tmp/deploy/images/core-image-sato-qemux86.ext3]
-     FSTYPE: [ext3]
-     Setting up tap interface under sudo
-     Acquiring lockfile for tap0...
-     WARNING: distccd not present, no distcc support loaded.
-     Running qemu...
-     /home/scottrif/poky/build/tmp/sysroots/x86_64-linux/usr/bin/qemu 
-        -kernel /home/scottrif/poky/build/tmp/deploy/images/bzImage-qemux86.bin 
-        -net nic,vlan=0 -net tap,vlan=0,ifname=tap0,script=no,downscript=no 
-        -hda /home/scottrif/poky/build/tmp/deploy/images/core-image-sato-qemux86.ext3 
-        -show-cursor -usb -usbdevice wacom-tablet -vga vmware -enable-gl -no-reboot 
-        -m 128 &dash;&dash;append "vga=0 root=/dev/hda rw mem=128M ip=192.168.7.2::192.168.7.1:255.255.255.0 oprofile.timer=1 "
-     Enabling opengl
-     vmsvga_value_write: guest runs Linux.
-                </literallayout>
-            </para>
-        </section> 
-
-        <section id='prepare-to-use-menuconfig'>
-            <title>Prepare to use <filename>menuconfig</filename></title>
-            
-
-            <para>
-                [WRITER'S NOTE: Stuff from here down are crib notes]
-            </para>
-
-            <para>
-                Once menuconfig fires up you see all kinds of categories that you can interactively
-                investigate.
-                If they have an "M" in it then the feature is "modularized".
-                I guess that means that means that it needs to be manually linked in when the 
-                kernel is booted??? (Not sure).
-                If they have an "*" then the feature is automatically part of the kernel.]
-            </para>
-
-            <para>
-                So the tmp/work/ area was created in poky and there is a .config file in there and
-                a .config.old file.  
-                The old one must have been created when I exited from menuconfig after poking around 
-                a bit.
-                Nope - appears to just be created automatically.
-            </para>
-
-            <para>
-                A good practice is to first determine what configurations you have for the kernel.
-                You can see the results by looking in the .config file in the build/tmp/work/qemux86-poky-linux area
-                of the local YP files. 
-                There is a directory named linux-yocto-2.6.37* in the directory.
-                In that directory is a directory named linux-qemux86-standard-build.
-                In that directory you will find a file named .config that is the configuration file
-                for the kernel that will be used when you build the kernel.
-                You can open that file up and examine it. 
-                If you do a search for "VFAT" you will see that that particular configuration is not 
-                enabled for the kernel.
-                This means that you cannot print a VFAT text file, or for that matter, even mount one
-                from the image if you were to build it at this point.
-            </para>
-
-            <para>
-                You can prove the point by actually trying it at this point.
-                Here are the commands:
-                <literallayout class='monospaced'>
-     $ mkdir ~/vfat-test
-     $ cd ~/vfat-test
-     $ dd if=/dev/zero of=vfat.img bs=1024 count=5000  [creates a 5MB disk image]
-     5+0 records in
-     5+0 records out
-     5242880 bytes (5.2 MB) copied, 0.00798912 s, 656 MB/s
-     $ ls -lah   [lists the contents of the new image. l=long, a=all, h=human readable]
-     total 5.1M
-     drwxr-xr-x  2 srifenbark scottrif 4.0K 2011-08-01 08:18 .
-     drwxr-xr-x 66 srifenbark scottrif 4.0K 2011-08-01 08:14 ..
-     -rw-r&dash;&dash;r&dash;&dash;  1 srifenbark scottrif 5.0M 2011-08-01 08:18 vfat.img
-     $ mkfs.vfat vfat.img                      [formats the disk image]
-     mkfs.vfat 3.0.7 (24 Dec 2009)
-     $ mkdir mnt                               [mounts the disk image]
-     $ sudo su                                 [gives you root privilege]
-     # mount -o loop vfat.img mnt              [mounts it as a loop device]
-     # ls mnt                                  [shows nothing in mnt]
-     # mount                                   [lists the mounted filesystems - note/dev/loop0]
-     /dev/sda1 on / type ext4 (rw,errors=remount-ro)
-     proc on /proc type proc (rw,noexec,nosuid,nodev)
-     none on /sys type sysfs (rw,noexec,nosuid,nodev)
-     none on /sys/fs/fuse/connections type fusectl (rw)
-     none on /sys/kernel/debug type debugfs (rw)
-     none on /sys/kernel/security type securityfs (rw)
-     none on /dev type devtmpfs (rw,mode=0755)
-     none on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
-     none on /dev/shm type tmpfs (rw,nosuid,nodev)
-     none on /var/run type tmpfs (rw,nosuid,mode=0755)
-     none on /var/lock type tmpfs (rw,noexec,nosuid,nodev)
-     none on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
-     binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)
-     gvfs-fuse-daemon on /home/scottrif/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=srifenbark)
-     /dev/loop0 on /home/scottrif/vfat-test/mnt type vfat (rw)
-     # echo "hello world" > mnt/hello.txt    [creates a text file in the mounted VFAT system]
-     # ls mnt                                [verifies the file is there]
-     hello.txt
-     # cat mnt/hello.txt                     [displays the contents of the file created]
-     hello world 
-     # umount mnt                            [unmounts the system and destroys the loop]
-     # exit                                  [gets out of privileged user mode]
-     exit
-
-     $ lsmod                                 [this stuff Darren did to show me ]
-     Module                  Size  Used by   [the status of modules in the regular linux kernel]
-     nls_iso8859_1           4633  0 
-     nls_cp437               6351  0 
-     vfat                   10866  0 
-     fat                    55350  1 vfat
-     snd_hda_codec_atihdmi     3023  1 
-     binfmt_misc             7960  1 
-     snd_hda_codec_realtek   279008  1 
-     ppdev                   6375  0 
-     snd_hda_intel          25805  2 
-     fbcon                  39270  71 
-     tileblit                2487  1 fbcon
-     font                    8053  1 fbcon
-     bitblit                 5811  1 fbcon
-     snd_hda_codec          85759  3 snd_hda_codec_atihdmi,snd_hda_codec_realtek,snd_hda_intel
-     softcursor              1565  1 bitblit
-     snd_seq_dummy           1782  0 
-     snd_hwdep               6924  1 snd_hda_codec
-     vga16fb                12757  0 
-     snd_pcm_oss            41394  0 
-     snd_mixer_oss          16299  1 snd_pcm_oss
-     snd_pcm                87946  3 snd_hda_intel,snd_hda_codec,snd_pcm_oss
-     vgastate                9857  1 vga16fb
-     snd_seq_oss            31191  0 
-     snd_seq_midi            5829  0 
-     snd_rawmidi            23420  1 snd_seq_midi
-     radeon                744506  3 
-     snd_seq_midi_event      7267  2 snd_seq_oss,snd_seq_midi
-     ttm                    61007  1 radeon
-     snd_seq                57481  6 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_seq_midi_event
-     drm_kms_helper         30742  1 radeon
-     snd_timer              23649  2 snd_pcm,snd_seq
-     snd_seq_device          6888  5 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_rawmidi,snd_seq
-     usb_storage            50377  0 
-     snd                    71283  16 \
-                                      snd_hda_codec_realtek,snd_hda_intel,snd_hda_codec, \
-                                      snd_hwdep,snd_pcm_oss,snd_mixer_oss,snd_pcm, \
-                                      snd_seq_oss,snd_rawmidi,snd_seq,snd_timer,snd_seq_device
-     soundcore               8052  1 snd
-     psmouse                65040  0 
-     drm                   198886  5 radeon,ttm,drm_kms_helper
-     i2c_algo_bit            6024  1 radeon
-     serio_raw               4918  0 
-     snd_page_alloc          8500  2 snd_hda_intel,snd_pcm
-     dell_wmi                2177  0 
-     dcdbas                  6886  0 
-     lp                      9336  0 
-     parport                37160  2 ppdev,lp
-     usbhid                 41116  0 
-     ohci1394               30260  0 
-     hid                    83888  1 usbhid
-     ieee1394               94771  1 ohci1394
-     tg3                   122382  0
-                </literallayout>
-            </para>
-        </section>
-    </section> -->
 </appendix>
 
-<!--
-
-
-EXTRA STUFF I MIGHT NEED BUT NOW SURE RIGHT NOW.
-
-In the standard layer structure you have several areas that you need to examine or 
-                    modify.
-                    For this example the layer contains four areas:
-                    <itemizedlist>
-                        <listitem><para><emphasis><filename>conf</filename></emphasis> - Contains the 
-                        <filename>layer.conf</filename> that identifies the location of the recipe files. 
-                        </para></listitem>
-                        <listitem><para><emphasis><filename>images</filename></emphasis> - Contains the 
-                        image recipe file. 
-                        This recipe includes the base image you will be using and specifies other 
-                        packages the image might need.</para></listitem>
-                        <listitem><para><emphasis><filename>recipes-bsp</filename></emphasis> - Contains 
-                        recipes specific to the hardware for which you are developing the kernel.
-                        </para></listitem>
-                        <listitem><para><emphasis><filename>recipes-kernel</filename></emphasis> - Contains the 
-                        "append" files that add information to the main recipe kernel.  
-                        </para></listitem>
-                    </itemizedlist>
-                </para>
-
-                <para>
-                    Let's take a look at the <filename>layer.conf</filename> in the 
-                    <filename>conf</filename> directory first.
-                    This configuration file enables the Yocto Project build system to locate and 
-                    use the information in your new layer.
-                </para>
-
-                <para>
-                    The variable <filename>BBPATH</filename> needs to include the path to your layer
-                    as follows:
-                    <literallayout class='monospaced'>
-     BBPATH := "${BBPATH}:${LAYERDIR}"
-                    </literallayout>
-                    And, the variable <filename>BBFILES</filename> needs to be modified to include your 
-                    recipe and append files:
-                    <literallayout class='monospaced'>
-     BBFILES := "${BBFILES} ${LAYERDIR}/images/*.bb \ 
-        ${LAYERDIR}/images/*.bbappend \
-        ${LAYERDIR}/recipes-*/*/*.bb \
-        ${LAYERDIR}/recipes-*/*/*.bbappend"
-                    </literallayout>
-                    Finally, you need to be sure to use your layer name in these variables at the 
-                    end of the file:
-                    <literallayout class='monospaced'>
-     BBFILE_COLLECTIONS += "elc"
-     BBFILE_PATTERN_elc := "^${LAYERDIR}/"
-     BBFILE_PRIORITY_elc = "9"
-                   </literallayout>
-                </para>
-
-                <para>
-                    The <filename>images</filename> directory contains an append file that helps 
-                    further define the image.
-                    In our example, the base image is <filename>core-image-minimal</filename>.  
-                    The image does, however, need some additional modules that we are using
-                    for this example.
-                    These modules support the amixer functionality.
-                    Here is the append file:
-                    <literallayout class='monospaced'>
-     require recipes-core/images/poky-image-minimal.bb
-
-     IMAGE_INSTALL += "dropbear alsa-utils-aplay alsa-utils-alsamixer"
-     IMAGE_INSTALL_append_qemux86 += " kernel-module-snd-ens1370 \
-        kernel-module-snd-rawmidi kernel-module-loop kernel-module-nls-cp437 \
-        kernel-module-nls-iso8859-1 qemux86-audio alsa-utils-amixer"
-
-     LICENSE = "MIT"
-                   </literallayout>
-               </para>
-
-               <para>
-                   While the focus of this example is not on the BSP, it is worth mentioning that the
-                   <filename>recipes-bsp</filename> directory has the recipes and append files for 
-                   features that the hardware requires. 
-                   In this example, there is a script and a recipe to support the 
-                   <filename>amixer</filename> functionality in QEMU.
-                   It is beyond the scope of this manual to go too deeply into the script.
-                   Suffice it to say that the script tests for the presence of the mixer, sets up 
-                   default mixer values, enables the mixer, unmutes master and then 
-                   sets the volume to 100.
-               </para>
-
-               <para>
-                   The recipe <filename>qemu86-audio.bb</filename> installs and runs the 
-                   <filename>amixer</filename> when the system boots.
-                   Here is the recipe:
-                   <literallayout class='monospaced'>
-     SUMMARY = "Provide a basic init script to enable audio"
-     DESCRIPTION = "Set the volume and unmute the Front mixer setting during boot."
-     SECTION = "base"
-     LICENSE = "MIT"
-     LIC_FILES_CHKSUM = "file://${POKYBASE}/LICENSE;md5=3f40d7994397109285ec7b81fdeb3b58"
-
-     PR = "r4"
-
-     inherit update-rc.d
-
-     RDEPENDS = "alsa-utils-amixer"
-
-     SRC_URI = "file://qemux86-audio"
-
-     INITSCRIPT_NAME = "qemux86-audio"
-     INITSCRIPT_PARAMS = "defaults 90"
-
-     do_install() {
-	     install -d ${D}${sysconfdir} \
-     	           ${D}${sysconfdir}/init.d
-     	install -m 0755 ${WORKDIR}/qemux86-audio ${D}${sysconfdir}/init.d
-             cat ${WORKDIR}/${INITSCRIPT_NAME} | \
-                 sed -e 's,/etc,${sysconfdir},g' \
-                     -e 's,/usr/sbin,${sbindir},g' \
-                     -e 's,/var,${localstatedir},g' \
-                     -e 's,/usr/bin,${bindir},g' \
-                     -e 's,/usr,${prefix},g' > ${D}${sysconfdir}/init.d/${INITSCRIPT_NAME}
-             chmod 755 ${D}${sysconfdir}/init.d/${INITSCRIPT_NAME}
-     }
-                </literallayout>
-                </para>
-
-                <para>
-                    The last area to look at is <filename>recipes-kernel</filename>.
-                    This area holds configuration fragments and kernel append files.
-                    The append file must have the same name as the kernel recipe, which is 
-                    <filename>linux-yocto-2.6.37</filename> in this example.
-                    The file can <filename>SRC_URI</filename> statements to point to configuration 
-                    fragments you might have in the layer. 
-                    The file can also contain <filename>KERNEL_FEATURES</filename> statements that specify
-                    included kernel configurations that ship with the Yocto Project.
-                </para>
--->
-
 <!--
 vim: expandtab tw=80 ts=4
 -->

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

@@ -8,32 +8,35 @@
 
 <para>
     Many development models exist for which you can use the Yocto Project. 
-    However, for the purposes of this manual we are going to focus on two common models:  
-    System Development and User Application Development.
-    System Development covers Board Support Package (BSP) development and kernel modification
-    or configuration.  
-    User Application Development covers development of applications that you intend to run on some 
-    target hardware.  
-</para>
-
-<para>
-    This chapter presents overviews of both system and application models.
-    If you want to examine specific examples of the system development models, 
-    see the "<link linkend='dev-manual-bsp-appendix'>BSP Development Example</link>" 
-    appendix and the 
-    "<link linkend='dev-manual-kernel-appendix'>Kernel Modification Example</link>" appendix.
-    For a user-space application development example that uses the 
-    <trademark class='trade'>Eclipse</trademark> IDE,
-    see the 
-    <ulink url='&YOCTO_DOCS_ADT_URL;'>
-    The Yocto Project Application Development Toolkit (ADT) User's Guide</ulink>.
-</para>
-
-<para>
-    Aside from these two models, this chapter will also briefly introduce and discuss
-    development using 
-    <ulink url='&YOCTO_HOME_URL;/projects/hob'>Hob</ulink>, which is a graphical interface 
-    to the Yocto Project build system.
+    This chapter overviews the following methods:
+    <itemizedlist>
+        <listitem><para><emphasis>System Development:</emphasis>
+             System Development covers Board Support Package (BSP) development and kernel 
+             modification or configuration.
+             If you want to examine specific examples of the system development models, 
+             see the "<link linkend='dev-manual-bsp-appendix'>BSP Development Example</link>" 
+             appendix and the 
+             "<link linkend='dev-manual-kernel-appendix'>Kernel Modification Example</link>" appendix.
+             </para></listitem>
+         <listitem><para><emphasis>User Application Development:</emphasis>
+             User Application Development covers development of applications that you intend 
+             to run on some target hardware.
+             For a user-space application development example that uses the 
+             <trademark class='trade'>Eclipse</trademark> IDE,
+             see the 
+             <ulink url='&YOCTO_DOCS_ADT_URL;'>
+             The Yocto Project Application Development Toolkit (ADT) User's Guide</ulink>.
+             </para></listitem>
+         <listitem><para><emphasis>Temporary Source Code Modification:</emphasis>
+             Direct modification of temporary source code is a convenient development model
+             to quickly iterate and develop towards a solution.
+             Once the solution has been implemented, you should of course take steps to 
+             get the changes upstream and applied in the affected recipes.</para></listitem>
+         <listitem><para><emphasis>Image Development using Hob:</emphasis>
+             You can use the <ulink url='&YOCTO_HOME_URL;/projects/hob'>Hob</ulink> to build 
+             custom operating system images within the build environment.
+             Hob provides an efficient interface to the OpenEmbedded build system.</para></listitem>
+     </itemizedlist>
 </para>
 
 <section id='system-development-model'>
@@ -58,7 +61,7 @@
         <title>Developing a Board Support Package (BSP)</title>
 
         <para>
-            A BSP is a package of recipes that, when applied, during a build results in 
+            A BSP is a packageof recipes that, when applied, during a build results in 
             an image that you can run on a particular board.  
             Thus, the package, when compiled into the new image, supports the operation of the board.  
         </para>
@@ -91,18 +94,20 @@
                     and the 
                     "<ulink url='&YOCTO_DOCS_QS_URL;#packages'>The Packages</ulink>" sections both
                     in the Yocto Project Quick Start for requirements.</para></listitem>
-                <listitem><para><emphasis>Establish a local copy of the Yocto Project files on your 
-                    system</emphasis>:  You need to have the Yocto Project files available on your host system. 
-                    Having the Yocto Project files on your system gives you access to the build
+                <listitem><para><emphasis>Establish a local copy of the project files on your 
+                    system</emphasis>:  You need this <link linkend='source-directory'>source 
+                    directory</link> available on your host system. 
+                    Having these files on your system gives you access to the build
                     process and to the tools you need.
-                    For information on how to get these files, see the
+                    For information on how to set up the source directory, see the
                     "<link linkend='getting-setup'>Getting Setup</link>" section.</para></listitem>
                 <listitem><para><emphasis>Establish a local copy of the base BSP files</emphasis>:  Having    
                     the BSP files on your system gives you access to the build
                     process and to the tools you need for creating a BSP.
                     For information on how to get these files, see the
                     "<link linkend='getting-setup'>Getting Setup</link>" section.</para></listitem>    
-                <listitem><para><emphasis>Choose a Yocto Project-supported BSP as your base BSP</emphasis>:  
+                <listitem><para><emphasis>Choose a BSP that is supported by the Yocto Project 
+                    as your base BSP</emphasis>:  
                     The Yocto Project ships with several BSPs that support various hardware.  
                     It is best to base your new BSP on an existing BSP rather than create all the 
                     recipes and configuration files from scratch.  
@@ -120,30 +125,38 @@
                     Crown Bay that does not support the <trademark class='registered'>Intel</trademark> 
                     Embedded Media Graphics Driver (EMGD).  
                     The remainder of this example uses that base BSP.</para>
-                    <para>To see the supported BSPs, go to the Yocto Project
-                    <ulink url='&YOCTO_DL_URL;/download'>download page</ulink> and click 
-                    on “BSP Downloads.”</para></listitem>
+                    <para>To see the supported BSPs, go to the 
+                    <ulink url='&YOCTO_HOME_URL;/download'>Download</ulink> page on the Yocto Project
+                    website and click on “BSP Downloads.”</para></listitem>
                 <listitem><para><emphasis>Create your own BSP layer</emphasis>:  Layers are ideal for 
                     isolating and storing work for a given piece of hardware.  
-                    A layer is really just a location or area in which you place the recipes for your BSP.  
+                    A layer is really just a location or area in which you place the recipes for your BSP.
                     In fact, a BSP is, in itself, a special type of layer.   
+                    </para>
+                    <para>
                     Another example that illustrates a layer is an application.  
                     Suppose you are creating an application that has library or other dependencies in 
                     order for it to compile and run.  
                     The layer, in this case, would be where all the recipes that define those dependencies 
                     are kept.  
                     The key point for a layer is that it is an isolated area that contains 
-                    all the relevant information for the project that the Yocto Project build 
-                    system knows about.</para>
-                    <note>The Yocto Project supports four BSPs that are part of the 
+                    all the relevant information for the project that the OpenEmbedded build 
+                    system knows about.
+                    For more information on layers, see the 
+                    "<link linkend='understanding-and-creating-layers'>Understanding and Creating Layers</link>"
+                    section.
+                    For more information on BSP layers, 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.</para>
+                    <note>Four BSPs exist that are part of the 
                     Yocto Project release: <filename>atom-pc</filename>, <filename>beagleboard</filename>,
                     <filename>mpc8315e</filename>, and <filename>routerstationpro</filename>.  
                     The recipes and configurations for these four BSPs are located and dispersed 
-                    within the local Yocto Project files.
-                    Consequently, they are not totally isolated in the spirit of layers unless you think 
-                    of <filename>meta-yocto</filename> as a layer itself.  
+                    within the <link linkend='source-directory'>source directory</link>.
                     On the other hand, BSP layers for Crown Bay, Emenlow, Jasper Forest, 
-                    N450, and Sugar Bay are isolated.</note>
+                    N450, Cedar Trail, Fish River, Fish River Island II, Romley, sys940x, tlk, 
+                    and Sugar Bay exist in their own separate layers within the larger 
+                    <filename>meta-intel</filename> layer.</note>
                     <para>When you set up a layer for a new BSP, you should follow a standard layout.  
                     This layout is described in the section
                     "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-filelayout'>Example Filesystem Layout</ulink>"
@@ -152,7 +165,7 @@
                     configuration information.  
                     You can see the standard layout for the Crown Bay BSP in this example by examining the 
                     directory structure of the <filename>meta-crownbay</filename> layer inside the 
-                    local Yocto Project files.</para></listitem>
+                    source directory.</para></listitem>
                 <listitem><para><emphasis>Make configuration changes to your new BSP 
                     layer</emphasis>:  The standard BSP layer structure organizes the files you need 
                     to edit in <filename>conf</filename> and several <filename>recipes-*</filename>
@@ -166,15 +179,15 @@
                     </para></listitem>
                 <listitem><para><emphasis>Prepare for the build</emphasis>:  Once you have made all the 
                     changes to your BSP layer, there remains a few things 
-                    you need to do for the Yocto Project build system in order for it to create your image.  
+                    you need to do for the OpenEmbedded build system in order for it to create your image.  
                     You need to get the build environment ready by sourcing an environment setup script 
                     and you need to be sure two key configuration files are configured appropriately.</para>
                     <para>The entire process for building an image is overviewed in the section
                     "<ulink url='&YOCTO_DOCS_QS_URL;#building-image'>Building an Image</ulink>" section 
                     of the Yocto Project Quick Start.    
                     You might want to reference this information.</para></listitem>
-                <listitem><para><emphasis>Build the image</emphasis>:  The Yocto Project uses the BitBake 
-                    tool to build images based on the type of image you want to create.  
+                <listitem><para><emphasis>Build the image</emphasis>:  The OpenEmbedded build system 
+                    uses the BitBake tool to build images based on the type of image you want to create.  
                     You can find more information on BitBake 
                     <ulink url='http://bitbake.berlios.de/manual/'>here</ulink>.</para>
                     <para>The build process supports several types of images to satisfy different needs.  
@@ -201,7 +214,7 @@
         <title><anchor id='kernel-spot' />Modifying the Kernel</title>
 
         <para>
-            Kernel modification involves changing the Linux Yocto kernel, which could involve changing
+            Kernel modification involves changing the Yocto Project kernel, which could involve changing
             configuration options as well as adding new kernel recipes.  
             Configuration changes can be added in the form of configuration fragments, while recipe
             modification comes through the kernel's <filename>recipes-kernel</filename> area
@@ -209,8 +222,8 @@
         </para>
 
         <para>
-            The remainder of this section presents a high-level overview of the Linux Yocto 
-            kernel architecture and the steps to modify the Linux Yocto kernel.
+            The remainder of this section presents a high-level overview of the Yocto Project
+            kernel architecture and the steps to modify the kernel.
             For a complete discussion of the kernel, see  
             <ulink url='&YOCTO_DOCS_KERNEL_URL;'>
             The Yocto Project Kernel Architecture and Use Manual</ulink>.
@@ -231,22 +244,25 @@
             </para>
 
             <para>
-                You can find a web interface to the Linux Yocto kernel source repositories at
+                You can find a web interface to the Yocto Project kernel source repositories at
                 <ulink url='&YOCTO_GIT_URL;'></ulink>.
                 If you look at the interface, you will see to the left a grouping of 
                 Git repositories titled "Yocto Linux Kernel."  
-                Within this group, you will find the four different kernels supported by 
+                Within this group, you will find several kernels supported by 
                 the Yocto Project:
                 <itemizedlist>
                     <listitem><para><emphasis><filename>linux-yocto-2.6.34</filename></emphasis> - The 
-                    stable Linux Yocto kernel that is based on the Linux 2.6.34 release.</para></listitem>
+                    stable Yocto Project kernel that is based on the Linux 2.6.34 released kernel.</para></listitem>
                     <listitem><para><emphasis><filename>linux-yocto-2.6.37</filename></emphasis> - The
-                    stable Linux Yocto kernel that is based on the Linux 2.6.37 release.</para></listitem>
+                    stable Yocto Project kernel that is based on the Linux 2.6.37 released kernel.</para></listitem>
                     <listitem><para><emphasis><filename>linux-yocto-3.0</filename></emphasis> - The stable
-                    Linux Yocto kernel that is based on the Linux 3.0 release.</para></listitem>
+                    Yocto Project kernel that is based on the Linux 3.0 released kernel.</para></listitem>
                     <listitem><para><emphasis><filename>linux-yocto-3.0-1.1.x</filename></emphasis> - The 
-                    stable Linux Yocto kernel to use with the Yocto Project Release 1.1.x. This kernel 
-                    is based on the Linux 3.0 release</para></listitem>
+                    stable Yocto Project kernel to use with the Yocto Project Release 1.1.x. This kernel 
+                    is based on the Linux 3.0 released kernel.</para></listitem>
+                    <listitem><para><emphasis><filename>linux-yocto-3.2</filename></emphasis> - The 
+                    stable Yocto Project kernel to use with the Yocto Project Release 1.2. This kernel 
+                    is based on the Linux 3.2 released kernel.</para></listitem>
                     <listitem><para><emphasis><filename>linux-yocto-dev</filename></emphasis> - A development
                     kernel based on the latest upstream release candidate available.</para></listitem>
                 </itemizedlist>
@@ -281,15 +297,15 @@
 
             <para>
                 The overall result is a Git-maintained repository from which all the supported
-                Yocto Project kernel types can be derived for all the supported Yocto Project devices.
+                kernel types can be derived for all the supported devices.
                 A big advantage to this scheme is the sharing of common features by keeping them in 
                 "larger" branches within the tree.  
                 This practice eliminates redundant storage of similar features shared among kernels.
             </para>
 
             <note>
-                Keep in mind the figure does not take into account all four supported Linux Yocto
-                kernel types, but rather shows a single generic kernel just for conceptual purposes.
+                Keep in mind the figure does not take into account all the supported Yocto
+                Project kernel types, but rather shows a single generic kernel just for conceptual purposes.
                 Also keep in mind that this structure represents the Yocto Project source repositories 
                 that are either pulled from during the build or established on the host development system
                 prior to the build by either cloning a particular kernel's Git repository or by 
@@ -299,7 +315,7 @@
             <para>
                 Storage of all the available kernel source code is one thing, while representing the 
                 code on your host development system is another.  
-                Conceptually, you can think of the Yocto Project kernel source repositories as all the 
+                Conceptually, you can think of the kernel source repositories as all the 
                 source files necessary for all the supported kernels. 
                 As a developer, you are just interested in the source files for the kernel on 
                 on which you are working.
@@ -308,13 +324,13 @@
 
             <para>
                 You make kernel source code available on your host development system by using 
-                Git to create a bare clone of the Linux Yocto kernel Git repository 
+                Git to create a bare clone of the Yocto Project kernel Git repository 
                 in which you are interested.
                 Then, you use Git again to clone a copy of that bare clone.  
                 This copy represents the directory structure on your host system that is particular
                 to the kernel you want.  
                 These are the files you actually modify to change the kernel.
-                See the <link linkend='local-kernel-files'>Linux Yocto Kernel</link> item earlier
+                See the <link linkend='local-kernel-files'>Yocto Project Kernel</link> item earlier
                 in this manual for an example of how to set up the kernel source directory
                 structure on your host system.
             </para>
@@ -325,7 +341,7 @@
             </para>
 
             <para>
-                <imagedata fileref="figures/kernel-overview-3.png" 
+                <imagedata fileref="figures/kernel-overview-3-denzil.png" 
                     width="6in" depth="4in" align="center" scale="100" />
             </para> 
 
@@ -344,7 +360,7 @@
             <para>
                 What happens during the build?  
                 When you build the kernel on your development system all files needed for the build
-                are taken from the Yocto Project source repositories pointed to by the 
+                are taken from the source repositories pointed to by the 
                 <filename>SRC_URI</filename> variable and gathered in a temporary work area
                 where they are subsequently used to create the unique kernel.
                 Thus, in a sense, the process constructs a local source tree specific to your 
@@ -361,13 +377,13 @@
             </para> 
 
             <para>
-                Again, for a complete discussion of the Yocto Project kernel's architcture and its 
+                Again, for a complete discussion of the Yocto Project kernel's architecture and its 
                 branching strategy,
-                see the <ulink url='&YOCTO_DOCS_KERNEL_URL;'>
+                see <ulink url='&YOCTO_DOCS_KERNEL_URL;'>
                 The Yocto Project Kernel Architecture and Use Manual</ulink>.
-                Also, you can reference 
-                <xref linkend='modifying-the-kernel-source-code'>Modifying the Kernel Source Code</xref>
-                for a detailed example that modifies the kernel.
+                You can also reference the
+                "<link linkend='modifying-the-kernel-source-code'>Modifying the Kernel Source Code</link>"
+                section for a detailed example that modifies the kernel.
             </para>
         </section> 
 
@@ -390,27 +406,28 @@
                         "<ulink url='&YOCTO_DOCS_QS_URL;#the-linux-distro'>The Linux Distributions</ulink>" and  
                         "<ulink url='&YOCTO_DOCS_QS_URL;#packages'>The Packages</ulink>" sections both
                         in the Yocto Project Quick Start for requirements.</para></listitem>
-                    <listitem><para><emphasis>Establish a local copy of the Yocto Project files on your 
-                        system</emphasis>:  Having the Yocto Project files on your system gives you access to 
-                        the build process and tools you need.
+                    <listitem><para><emphasis>Establish a local copy of project files on your 
+                        system</emphasis>:  Having the <link linkend='source-directory'>source
+                        directory</link> on your system gives you access to the build process and tools 
+                        you need.
                         For information on how to get these files, see the bulleted item
                         "<link linkend='local-yp-release'>Yocto Project Release</link>" earlier in this manual.
                         </para></listitem>
-                    <listitem><para><emphasis>Set up the <filename>poky-extras</filename> Git 
-                        repository</emphasis>:  This repository is the area for your configuration 
+                    <listitem><para><emphasis>Set up a local copy of the <filename>poky-extras</filename> Git 
+                        repository</emphasis>:  This local repository is the area for your configuration 
                         fragments, new kernel recipes, and the kernel <filename>.bbappend</filename>
                         file used during the build. 
-                        It is good practice to set this repository up inside the local Yocto
-                        Project files Git repository.
+                        It is good practice to set this repository up inside your local 
+                        source directory.
                         For information on how to get these files, see the bulleted item
                         "<link linkend='poky-extras-repo'>The <filename>poky-extras</filename> Git Repository</link>"
                         earlier in this manual.
                         <note>While it is certainly possible to modify the kernel without involving
                             a local Git repository, the suggested workflow for kernel modification
                             using the Yocto Project does use a Git repository.</note></para></listitem>
-                    <listitem><para><emphasis>Establish a local copy of the Linux Yocto kernel files on your 
+                    <listitem><para><emphasis>Establish a local copy of the Yocto Project kernel files on your 
                         system</emphasis>:  In order to make modifications to the kernel you need two things:
-                        a bare clone of the Linux Yocto kernel you are modifying and  
+                        a bare clone of the Yocto Project kernel you are modifying and  
                         a copy of that bare clone. 
                         The bare clone is required by the build process and is the area to which you 
                         push your kernel source changes (pulling does not work with bare clones). 
@@ -418,7 +435,7 @@
                         source files. 
                         You make your changes to the files in this copy of the bare clone.
                         For information on how to set these two items up, see the bulleted item
-                        "<link linkend='local-kernel-files'>Linux Yocto Kernel</link>" 
+                        "<link linkend='local-kernel-files'>Yocto Project Kernel</link>" 
                         earlier in this manual.</para></listitem>
                     <listitem><para><emphasis>Make changes to the kernel source code if 
                         applicable</emphasis>:  Modifying the kernel does not always mean directly
@@ -439,9 +456,9 @@
                         <filename>.config</filename>.
                         Try to resist the temptation of directly editing the <filename>.config</filename> 
                         file found in the 
-                        <link linkend='yocto-project-build-directory'>Yocto Project Build Directory</link> at 
+                        <link linkend='build-directory'>build directory</link> at 
                         <filename>tmp/sysroots/&lt;machine-name&gt;/kernel</filename>.
-                        Doing so, can produce unexpected results when the Yocto Project build system 
+                        Doing so, can produce unexpected results when the OpenEmbedded build system 
                         regenerates the configuration file.</para>
                         <para>Once you are satisfied with the configuration changes made using 
                         <filename>menuconfig</filename>, you can directly examine the 
@@ -451,7 +468,7 @@
                     <listitem><para><emphasis>Add or extend kernel recipes if applicable</emphasis>:  
                         The standard 
                         layer structure organizes recipe files inside the 
-                        <filename>meta-kernel-dev</filename> layer that is within the 
+                        <filename>meta-kernel-dev</filename> layer that is within the local
                         <filename>poky-extras</filename> Git repository.
                         If you need to add new kernel recipes, you add them within this layer. 
                         Also within this area, you will find the <filename>.bbappend</filename> 
@@ -461,7 +478,7 @@
                     <listitem><para><emphasis>Prepare for the build</emphasis>:  Once you have made all the 
                         changes to your kernel (configurations, source code changes, recipe additions, 
                         or recipe changes), there remains a few things 
-                        you need to do in order for the Yocto Project build system to create your image.  
+                        you need to do in order for the build system to create your image.  
                         If you have not done so, you need to get the build environment ready by sourcing 
                         the environment setup script described earlier.
                         You also need to be sure two key configuration files 
@@ -473,8 +490,8 @@
                         You might want to reference this information.
                         Also, you should look at the detailed examples found in the appendices at 
                         at the end of this manual.</para></listitem>
-                    <listitem><para><emphasis>Build the image</emphasis>:  The Yocto Project 
-                        build system Poky uses the BitBake 
+                    <listitem><para><emphasis>Build the image</emphasis>:  The OpenEmbedded 
+                        build system uses the BitBake 
                         tool to build images based on the type of image you want to create.  
                         You can find more information on BitBake 
                         <ulink url='http://bitbake.berlios.de/manual/'>here</ulink>.</para>
@@ -489,8 +506,8 @@
                         which allows you to distribute the layer.</para></listitem>
                     <listitem><para><emphasis>If applicable, share your in-tree changes</emphasis>:  
                         If the changes you made
-                        are suited for all Linux Yocto users, you might want to send them on for inclusion
-                        into the Linux Yocto Git repository. 
+                        are suited for all Yocto Project kernel users, you might want to send them on 
+                        for inclusion into the upstream kernel's Git repository. 
                         If the changes are accepted, the Yocto Project Maintainer pulls them into 
                         the master branch of the kernel tree. 
                         Doing so makes them available to everyone using the kernel.</para></listitem> 
@@ -500,12 +517,12 @@
     </section>
 </section>
 
-<section id='place-holder-section-two'>
+<section id='application-development-workflow'>
     <title>Application Development Workflow</title>
 
     <para>
         Application development involves creation of an application that you want to be able
-        to run on your target hardware, which is running a Linux Yocto image.
+        to run on your target hardware, which is running a Yocto Project kernel image.
         The Yocto Project provides an Application Development Toolkit (ADT) that 
         facilitates quick development and integration of your application into its run-time environment. 
         Using the ADT you can employ cross-development toolchains designed for your target hardware
@@ -516,7 +533,7 @@
     </para>
 
     <para>
-        While we strongly suggest using the Yocto Project ADT to develop your application, you might
+        While we strongly suggest using the ADT to develop your application, you might
         not want to.  
         If this is the case, you can still use pieces of the Yocto Project for your development process. 
         However, because the process can vary greatly, this manual does not provide detail on the process.
@@ -526,8 +543,7 @@
         <title>Workflow Using the ADT and <trademark class='trade'>Eclipse</trademark></title>
 
         <para>
-            To help you understand how application development works in the Yocto Project ADT
-            environment, this section 
+            To help you understand how application development works using the ADT, this section 
             provides an overview of the general development process.
             If you want to see a detailed example of the process as it is used from within the Eclipse 
             IDE, see 
@@ -536,7 +552,7 @@
         </para>
 
         <para>
-            This illustration and the following list summarizes the application development general workflow.
+            The following illustration and list summarize the application development general workflow.
         </para>
 
         <para>
@@ -551,30 +567,12 @@
                     "<ulink url='&YOCTO_DOCS_QS_URL;#the-linux-distro'>The Linux Distributions</ulink>" and  
                     "<ulink url='&YOCTO_DOCS_QS_URL;#packages'>The Packages</ulink>" sections both
                     in the Yocto Project Quick Start for requirements.</para></listitem>
-
-<!--
-WRITER NOTE:  The areas to get the kernel and root filesystem are located in the Index of 
-              downloads.  There are many forms of each.  The files that have "rootfs" are just the 
-              target root filesystems.  The file that is very small and starts with bzImage is just
-              the kernel image isolated so that it can be written to a special on-board area of 
-              flash memory.  Some systems require this.  In the machines directory there are  
-              files that combine the kernel image and the root filesystem.  These files are the ISO 
-              and HDDIMG files.  ISO images are designed to be deployed on a DVD or CD.  The ISO
-              images are designed to be deployed on a USB stick.  There might be some relics in 
-              the machine directory.  For example, there is the "emenlow-bernard-5.0.0.tar.bz2" 
-              file.  Nobody seems to know what this is.  If a developer needs the image and the 
-              root filesystem I think that they want the small kernel image and a matching root 
-              filesystem.  Although, Paul Eggleton says that the HDDIMG types could be used to 
-              develop on.  I am not sure that we can use one of those in the ADT though as they 
-              want you to point to the kernel image and the target root filesystem.  Maybe you 
-              could just point to the same spot.  I am not sure.
--->
-
-                <listitem><para><emphasis>Secure the Linux Yocto Kernel Target Image</emphasis>:  
-                    You must have a target kernel image that has been built using the Yocto Project.</para>
+                <listitem><para><emphasis>Secure the Yocto Project Kernel Target Image</emphasis>:  
+                    You must have a target kernel image that has been built using the OpenEmbeded
+                    build system.</para>
                     <para>Depending on whether the Yocto Project has a pre-built image that matches your target
                     architecture and where you are going to run the image while you develop your application
-                    (QEMU or real hardware), the area you get the image from differs.
+                    (QEMU or real hardware), the area from which you get the image differs.
                         <itemizedlist>
                             <listitem><para>Download the image from  
                                 <ulink url='&YOCTO_MACHINES_DL_URL;'>  
@@ -593,7 +591,7 @@ WRITER NOTE:  The areas to get the kernel and root filesystem are located in the
                                 See the 
                                 "<link linkend='kernel-modification-workflow'>Kernel Modification Workflow</link>"
                                 section earlier in this manual for information on how to create a modified 
-                                Linux Yocto kernel.</para></listitem>
+                                Yocto Project kernel.</para></listitem>
                         </itemizedlist></para>
                     <para>For information on pre-built kernel image naming schemes for images 
                     that can run on the QEMU emulator, see the
@@ -602,7 +600,7 @@ WRITER NOTE:  The areas to get the kernel and root filesystem are located in the
                 <listitem><para><emphasis>Install the ADT</emphasis>:  
                     The ADT provides a target-specific cross-development toolchain, the root filesystem,
                     the QEMU emulator, and other tools that can help you develop your application.
-                    While it is possible to get these pieces separately, the Yocto Project provides an 
+                    While it is possible to get these pieces separately, the ADT Installer provides an 
                     easy method.
                     You can get these pieces by running an ADT installer script, which is configurable.
                     For information on how to install the ADT, see the
@@ -689,15 +687,331 @@ WRITER NOTE:  The areas to get the kernel and root filesystem are located in the
     </section>
 </section>
 
+<section id="modifying-temporary-source-code">
+    <title>Modifying Temporary Source Code</title>
+
+    <para>
+        You might
+        find it helpful during development to modify the temporary source code used by recipes
+        to build packages.
+        For example, suppose you are developing a patch and you need to experiment a bit
+        to figure out your solution.
+        After you have initially built the package, you can iteratively tweak the 
+        source code, which is located in the 
+        <link linkend='build-directory'>build directory</link>, and then 
+        you can force a re-compile and quickly test your altered code.
+        Once you settle on a solution, you can then preserve your changes in the form of 
+        patches.
+        You can accomplish these steps all within either a 
+        <ulink url='http://savannah.nongnu.org/projects/quilt'>Quilt</ulink> or 
+        <link linkend='git'>Git</link> workflow.
+    </para>
+
+    <section id='finding-the-temporary-source-code'>
+        <title>Finding the Temporary Source Code</title>
+
+        <para>
+            During a build, the unpacked temporary source code used by recipes 
+            to build packages is available in the build directory as 
+            defined by the 
+            <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-S'>S</ulink></filename> variable.
+            Below is the default value for the <filename>S</filename> variable as defined in the 
+            <filename>meta/conf/bitbake.conf</filename> configuration file in the 
+            <link linkend='source-directory'>source directory</link>:
+            <literallayout class='monospaced'>
+     S = ${WORKDIR}/${BP}
+            </literallayout>
+            You should be aware that many recipes override the <filename>S</filename> variable.
+            For example, recipes that fetch their source from Git usually set 
+            <filename>S</filename> to <filename>${WORKDIR}/git</filename>.
+            <note>
+                <filename>BP</filename> represents the "Base Package", which is the base package
+                name and the package version:
+                <literallayout class='monospaced'>
+     BP = ${BPN}-${PV}
+                </literallayout>
+            </note> 
+        </para>
+
+        <para>
+            The path to the work directory for the recipe 
+            (<ulink url='&YOCTO_DOCS_REF_URL;#var-WORKDIR'><filename>WORKDIR</filename></ulink>) depends
+            on the package name and the architecture of the target device.
+            For example, here is the work directory for packages whose targets are not device-dependent:
+            <literallayout class='monospaced'>
+     ${TMPDIR}/work/${PACKAGE_ARCH}-poky-${TARGET_OS}/${PN}-${PV}-${PR}
+            </literallayout>
+            Let's look at an example without variables.
+            Assuming a top-level source directory named <filename>poky</filename>
+            and a default build directory of <filename>poky/build</filename>, 
+            the following is the work directory for the <filename>acl</filename> package:
+            <literallayout class='monospaced'>
+     ~/poky/build/tmp/work/i586-poky-linux/acl-2.2.51-r3
+            </literallayout>
+        </para>
+
+        <para>
+            If your package is dependent on the target device, the work directory varies slightly:
+            <literallayout class='monospaced'>
+     ${TMPDIR}/work/${MACHINE}-poky-${TARGET_OS}/${PN}-${PV}-${PR}
+            </literallayout>
+            Again, assuming top-level source directory named <filename>poky</filename>
+            and a default build directory of <filename>poky/build</filename>, the 
+            following is the work directory for the <filename>acl</filename> package that is being 
+            built for a MIPS-based device:
+            <literallayout class='monospaced'>
+     ~/poky/build/tmp/work/mips-poky-linux/acl-2.2.51-r2
+            </literallayout>
+        </para>
+
+        <note>
+            To better understand how the OpenEmbedded build system resolves directories during the 
+            build process, see the glossary entries for the
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-WORKDIR'><filename>WORKDIR</filename></ulink>,
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-TMPDIR'><filename>TMPDIR</filename></ulink>,
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-TOPDIR'><filename>TOPDIR</filename></ulink>,
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGE_ARCH'><filename>PACKAGE_ARCH</filename></ulink>,
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-TARGET_OS'><filename>TARGET_OS</filename></ulink>,
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-PN'><filename>PN</filename></ulink>,
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-PV'><filename>PV</filename></ulink>,
+            and
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-PR'><filename>PR</filename></ulink>
+            variables in the Yocto Project Reference Manual.
+        </note>
+
+        <para>
+            Now that you know where to locate the directory that has the temporary source code, you can use a 
+            Quilt or Git workflow to make your edits, test the changes, and preserve the 
+            changes in the form of patches.
+        </para>
+    </section>
+
+    <section id="using-a-quilt-workflow">
+        <title>Using a Quilt Workflow</title>
+            
+        <para>
+            <ulink url='http://savannah.nongnu.org/projects/quilt'>Quilt</ulink>
+            is a powerful tool that allows you to capture source code changes without having 
+            a clean source tree.
+            This section outlines the typical workflow you can use to modify temporary source code, 
+            test changes, and then preserve the changes in the form of a patch all using Quilt.
+        </para>
+
+        <para>
+            Follow these general steps:
+            <orderedlist>
+                <listitem><para><emphasis>Find the Source Code:</emphasis>
+                    The temporary source code used by the OpenEmbedded build system is kept in the 
+                    build directory.  
+                    See the 
+                    "<link linkend='finding-the-temporary-source-code'>Finding the Temporary Source Code</link>"
+                    section to learn how to locate the directory that has the temporary source code for a 
+                    particular package.</para></listitem>
+                <listitem><para><emphasis>Change Your Working Directory:</emphasis>
+                    You need to be in the directory that has the temporary source code.
+                    That directory is defined by the 
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-S'>S</ulink>
+                    variable.</para></listitem>
+                <listitem><para><emphasis>Create a New Patch:</emphasis>
+                    Before modifying source code, you need to create a new patch.
+                    To create a new patch file, use <filename>quilt new</filename> as below:
+                    <literallayout class='monospaced'>
+     $ quilt new my_changes.patch
+                    </literallayout></para></listitem>
+                <listitem><para><emphasis>Notify Quilt and Add Files:</emphasis>
+                    After creating the patch, you need to notify Quilt about the files you will 
+                    be changing.
+                    Add the files you will be modifying into the patch you just created:
+                    <literallayout class='monospaced'>
+     $ quilt add file1.c file2.c file3.c
+                    </literallayout></para></listitem>
+                <listitem><para><emphasis>Edit the Files:</emphasis>
+                    Make the changes to the temporary source code.</para></listitem>
+                <listitem><para><emphasis>Test Your Changes:</emphasis>
+                    Once you have modified the source code, the easiest way to test your changes 
+                    is by calling the <filename>compile</filename> task as shown in the following example:
+                    <literallayout class='monospaced'>
+     $ bitbake -c compile -f &lt;name_of_package&gt;
+                    </literallayout>
+                    The <filename>-f</filename> or <filename>--force</filename>
+                    option forces re-execution of the specified task.
+                    If you find problems with your code, you can just keep editing and 
+                    re-testing iteratively until things work as expected.
+                    <note>All the modifications you make to the temporary source code
+                    disappear once you <filename>-c clean</filename> or 
+                    <filename>-c cleanall</filename> with BitBake for the package.
+                    Modifications will also disappear if you use the <filename>rm_work</filename>
+                    feature as described in the
+                    "<ulink url='&YOCTO_DOCS_QS_URL;#building-image'>Building an Image</ulink>" 
+                    section of the Yocto Project Quick Start.
+                    </note></para></listitem>
+                <listitem><para><emphasis>Generate the Patch:</emphasis>
+                    Once your changes work as expected, you need to use Quilt to generate the final patch that 
+                    contains all your modifications.
+                    <literallayout class='monospaced'>
+     $ quilt refresh
+                    </literallayout>
+                    At this point the <filename>my_changes.patch</filename> file has all your edits made 
+                    to the <filename>file1.c</filename>, <filename>file2.c</filename>, and 
+                    <filename>file3.c</filename> files.</para>
+                    <para>You can find the resulting patch file in the <filename>patches/</filename> 
+                    subdirectory of the source (<filename>S</filename>) directory.</para></listitem>
+                <listitem><para><emphasis>Copy the Patch File:</emphasis> 
+                    For simplicity, copy the patch file into a directory named <filename>files</filename>,
+                    which you can create in the same directory as the recipe.
+                    Placing the patch here guarantees that the OpenEmbedded build system will find
+                    the patch.
+                    Next, add the patch into the  
+                    <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'>SRC_URI</ulink></filename> 
+                    of the recipe.  
+                    Here is an example:
+                    <literallayout class='monospaced'>
+     SRC_URI += "file://my_changes.patch"
+                    </literallayout></para></listitem>
+                <listitem><para><emphasis>Increment the Package Revision Number:</emphasis>
+                    Finally, don't forget to 'bump' the 
+                    <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PR'>PR</ulink></filename>
+                    value in the same recipe since the resulting packages have changed.</para></listitem>
+            </orderedlist>
+        </para>     </section>
+
+    <section id='using-a-git-workflow'>
+        <title>Using a Git Workflow</title>
+        <para>
+            Git is an even more powerful tool that allows you to capture source code changes without having 
+            a clean source tree.
+            This section outlines the typical workflow you can use to modify temporary source code, 
+            test changes, and then preserve the changes in the form of a patch all using Git.
+            For general information on Git as it is used in the Yocto Project, see the 
+            "<link linkend='git'>Git</link>" section.
+        </para>
+
+        <note>
+            This workflow uses Git only for its ability to manage local changes to the source code 
+            and produce patches independent of any version control system used with the Yocto Project.
+        </note>
+
+        <para>
+            Follow these general steps:
+            <orderedlist>
+                <listitem><para><emphasis>Find the Source Code:</emphasis>
+                    The temporary source code used by the OpenEmbedded build system is kept in the 
+                    build directory.  
+                    See the 
+                    "<link linkend='finding-the-temporary-source-code'>Finding the Temporary Source Code</link>"
+                    section to learn how to locate the directory that has the temporary source code for a 
+                    particular package.</para></listitem>
+                <listitem><para><emphasis>Change Your Working Directory:</emphasis>
+                    You need to be in the directory that has the temporary source code.
+                    That directory is defined by the 
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-S'>S</ulink>
+                    variable.</para></listitem>
+                <listitem><para><emphasis>Initialize a Git Repository:</emphasis>
+                    Use the <filename>git init</filename> command to initialize a new local repository
+                    that is based on the work directory:
+                    <literallayout class='monospaced'>
+     $ git init
+                    </literallayout></para></listitem>
+                <listitem><para><emphasis>Stage all the files:</emphasis>
+                    Use the <filename>git add *</filename> command to stage all the files in the source
+                    code directory so that they can be committed:
+                    <literallayout class='monospaced'>
+     $ git add *
+                    </literallayout></para></listitem>
+                <listitem><para><emphasis>Commit the Source Files:</emphasis>
+                    Use the <filename>git commit</filename> command to initially commit all the files in 
+                    the work directory:
+                    <literallayout class='monospaced'>
+     $ git commit
+                    </literallayout>
+                    At this point, your Git repository is aware of all the source code files.
+                    Any edits you now make to files will be tracked by Git.</para></listitem>
+                <listitem><para><emphasis>Edit the Files:</emphasis>
+                    Make the changes to the temporary source code.</para></listitem>
+                <listitem><para><emphasis>Test Your Changes:</emphasis>
+                    Once you have modified the source code, the easiest way to test your changes 
+                    is by calling the <filename>compile</filename> task as shown in the following example:
+                    <literallayout class='monospaced'>
+     $ bitbake -c compile -f &lt;name_of_package&gt;
+                    </literallayout>
+                    The <filename>-f</filename> or <filename>--force</filename>
+                    option forces re-execution of the specified task.
+                    If you find problems with your code, you can just keep editing and 
+                    re-testing iteratively until things work as expected.
+                    <note>All the modifications you make to the temporary source code
+                    disappear once you <filename>-c clean</filename> or 
+                    <filename>-c cleanall</filename> with BitBake for the package.
+                    Modifications will also disappear if you use the <filename>rm_work</filename>
+                    feature as described in the
+                    "<ulink url='&YOCTO_DOCS_QS_URL;#building-image'>Building an Image</ulink>" 
+                    section of the Yocto Project Quick Start.
+                    </note></para></listitem>
+                <listitem><para><emphasis>See the List of Files You Changed:</emphasis>
+                    Use the <filename>git status</filename> command to see what files you have actually edited. 
+                    The ability to have Git track the files you have changed is an advantage that this
+                    workflow has over the Quilt workflow.
+                    Here is the Git command to list your changed files:
+                    <literallayout class='monospaced'>
+     $ git status
+                    </literallayout></para></listitem>
+                <listitem><para><emphasis>Stage the Modified Files:</emphasis>
+                    Use the <filename>git add</filename> command to stage the changed files so they
+                    can be committed as follows:
+                    <literallayout class='monospaced'>
+     $ git add file1.c file2.c file3.c
+                    </literallayout></para></listitem>
+                <listitem><para><emphasis>Commit the Staged Files and View Your Changes:</emphasis>
+                    Use the <filename>git commit</filename> command to commit the changes to the 
+                    local repository.  
+                    Once you have committed the files, you can use the <filename>git log</filename>
+                    command to see your changes:
+                    <literallayout class='monospaced'>
+     $ git commit
+     $ git log
+                    </literallayout></para></listitem>
+                <listitem><para><emphasis>Generate the Patch:</emphasis>
+                    Once the changes are committed, use the <filename>git format-patch</filename>
+                    command to generate a patch file:
+                    <literallayout class='monospaced'>
+     $ git format-patch HEAD~1
+                    </literallayout>
+                    The <filename>HEAD~1</filename> part of the command causes Git to generate the 
+                    patch file for the most recent commit.</para>
+                    <para>At this point, the patch file has all your edits made 
+                    to the <filename>file1.c</filename>, <filename>file2.c</filename>, and 
+                    <filename>file3.c</filename> files.
+                    You can find the resulting patch file in the current directory.
+                    The patch file ends with <filename>.patch</filename>.</para></listitem>
+                <listitem><para><emphasis>Copy the Patch File:</emphasis> 
+                    For simplicity, copy the patch file into a directory named <filename>files</filename>,
+                    which you can create in the same directory as the recipe.
+                    Placing the patch here guarantees that the OpenEmbedded build system will find
+                    the patch.
+                    Next, add the patch into the  
+                    <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'>SRC_URI</ulink></filename> 
+                    of the recipe.  
+                    Here is an example:
+                    <literallayout class='monospaced'>
+     SRC_URI += "file://my_changes.patch"
+                    </literallayout></para></listitem>
+                <listitem><para><emphasis>Increment the Package Revision Number:</emphasis>
+                    Finally, don't forget to 'bump' the 
+                    <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PR'>PR</ulink></filename>
+                    value in the same recipe since the resulting packages have changed.</para></listitem>
+            </orderedlist>
+        </para>
+    </section>
+</section>
+
 <section id='image-development-using-hob'>
     <title>Image Development Using Hob</title>
 
     <para>
-        The <ulink url='&YOCTO_HOME_URL;/projects/hob'>Hob</ulink> is a graphical user interface for the Yocto 
-        Project build system based on BitBake.
+        The <ulink url='&YOCTO_HOME_URL;/projects/hob'>Hob</ulink> is a graphical user interface for the 
+        OpenEmbedded build system, which is based on BitBake.
         You can use the Hob to build custom operating system images within the Yocto Project build environment.
         Hob simply provides a friendly interface over the build system used during system development.
-        In other words, building images with the Hob lets you take care of common Yocto Project build tasks more easily.
+        In other words, building images with the Hob lets you take care of common build tasks more easily.
     </para>
 
     <para>
@@ -717,8 +1031,8 @@ WRITER NOTE:  The areas to get the kernel and root filesystem are located in the
             <listitem><para>You can modify various policy settings such as the package format used to build with, 
                 the parrallelism BitBake uses, whether or not to build an external toolchain, and which host 
                 to build against.</para></listitem>
-            <listitem><para>You can manage <link linkend='understanding-and-creating-layers'>Understanding 
-                and Creating layers</link>.</para></listitem>
+            <listitem><para>You can manage 
+                <link linkend='understanding-and-creating-layers'>layers</link>.</para></listitem>
             <listitem><para>You can select a base image and then add extra packages for your custom build.
                 </para></listitem>
             <listitem><para>You can launch and monitor the build from within Hob.</para></listitem>

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

@@ -23,7 +23,7 @@
         Open source philosophy is characterized by software development directed by peer production 
         and collaboration through an active community of developers.
         Contrast this to the more standard centralized development models used by commercial software 
-        companies where a finite set of developers produce a product for sale using a defined set 
+        companies where a finite set of developers produces a product for sale using a defined set
         of procedures that ultimately result in an end product whose architecture and source material
         are closed to the public.
     </para>
@@ -55,7 +55,7 @@
 </section>
 
 <section id="usingpoky-changes-collaborate">
-    <title>Using The Yocto Project in a Team Environment</title>
+    <title>Using the Yocto Project in a Team Environment</title>
 
     <para>
         It might not be immediately clear how you can use the Yocto Project in a team environment, 
@@ -97,19 +97,20 @@
     <para>
         Most teams have many pieces of software undergoing active development at any given time. 
         You can derive large benefits by putting these pieces under the control of a source 
-        control system that is compatible with the Yocto Project (i.e. Git or Subversion (SVN).
+        control system that is compatible (i.e. Git or Subversion (SVN)) with the OpenEmbeded 
+        build system that the Yocto Project uses.
         You can then set the autobuilder to pull the latest revisions of the packages 
         and test the latest commits by the builds.
         This practice quickly highlights issues. 
-        The Yocto Project easily supports testing configurations that use both a 
+        The build system easily supports testing configurations that use both a 
         stable known good revision and a floating revision.
-        The Yocto Project can also take just the changes from specific source control branches.
+        The build system can also take just the changes from specific source control branches.
         This capability allows you to track and test specific changes.
     </para>
 
     <para>
         Perhaps the hardest part of setting this up is defining the software project or 
-        the Yocto Project metadata policies that surround the different source control systems.
+        the metadata policies that surround the different source control systems.
         Of course circumstances will be different in each case.
         However, this situation reveals one of the Yocto Project's advantages - 
         the system itself does not
@@ -129,7 +130,7 @@
         From the interface, you can click on any particular item in the "Name" column and 
         see the URL at the bottom of the page that you need to set up a Git repository for 
         that particular item.
-        Having a local Git repository of the Yocto Project files allows you to 
+        Having a local Git repository of the source directory (poky) allows you to 
         make changes, contribute to the history, and ultimately enhance the Yocto Project's 
         tools, Board Support Packages, and so forth.
     </para>
@@ -147,8 +148,8 @@
         <ulink url='&YOCTO_HOME_URL;/download'>download page</ulink> 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 directory structure of Yocto Project 
-        files that lets you develop using the Yocto Project.
+        Unpacking the tarball gives you a hierarchical source directory that lets you develop 
+        using the Yocto Project.
     </para>
 
     <para>
@@ -157,22 +158,22 @@
     </para>
 
     <para>
-        In summary, here is where you can get the Yocto Project files needed for development:
+        In summary, here is where you can get the project files needed for development:
         <itemizedlist>
             <listitem><para id='source-repositories'><emphasis><ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi'>Source Repositories:</ulink></emphasis>
                 This area contains IDE Plugins, Matchbox, Poky, Poky Support, Tools, Yocto Linux Kernel, and Yocto 
                 Metadata Layers.
-                You can create Git repositories for each of these areas.</para>
+                You can create local copies of Git repositories for each of these areas.</para>
                 <para>
                 <imagedata fileref="figures/source-repos.png" align="center" width="6in" depth="4in" />
                 </para></listitem>
             <listitem><para><anchor id='index-downloads' /><emphasis><ulink url='&YOCTO_DL_URL;/releases/'>Index of /releases:</ulink></emphasis>
                 This area contains index releases such as 
                 the <trademark class='trade'>Eclipse</trademark>
-                Yocto Plug-in, miscellaneous support, Poky, pseudo, cross-development toolchains,
+                Yocto Plug-in, miscellaneous support, poky, pseudo, cross-development toolchains,
                 and all released versions of Yocto Project in the form of images or tarballs.
-                Downloading and extracting these files does not produce a Git repository but rather 
-                a snapshot of a particular release or image.</para>
+                Downloading and extracting these files does not produce a local copy of the 
+                Git repository but rather a snapshot of a particular release or image.</para>
                 <para>
                 <imagedata fileref="figures/index-downloads.png" align="center" width="6in" depth="4in" />
                 </para></listitem>
@@ -199,7 +200,7 @@
             <listitem><para><emphasis>Append Files:</emphasis> Files that append build information to 
                 a recipe file.
                 Append files are known as BitBake append files and <filename>.bbappend</filename> files.
-                The Yocto Project build system expects every append file to have a corresponding and 
+                The OpenEmbedded build system expects every append file to have a corresponding and 
                 underlying recipe (<filename>.bb</filename>) file.
                 Furthermore, the append file and the underlying recipe must have the same root filename.
                 The filenames can differ only in the file type suffix used (e.g. 
@@ -211,140 +212,25 @@
                 "<link linkend='changing-recipes-kernel'>Changing <filename>recipes-kernel</filename></link>"
                 sections.</para></listitem>
             <listitem><para><emphasis>BitBake:</emphasis> The task executor and scheduler used by 
-                the Yocto Project to build images. 
+                the OpenEmbedded build system to build images. 
                 For more information on BitBake, see the <ulink url='http://bitbake.berlios.de/manual/'>
                 BitBake documentation</ulink>.</para></listitem>
-            <listitem><para><emphasis>Classes:</emphasis> Files that provide for logic encapsulation
-                and inheritance allowing commonly used patterns to be defined once and easily used 
-                in multiple recipes.  
-                Class files end with the <filename>.bbclass</filename> filename extension.
-                </para></listitem>
-            <listitem><para><emphasis>Configuration File:</emphasis>  Configuration information in various
-                <filename>.conf</filename> files provides global definitions of variables.
-                The <filename>conf/local.conf</filename> configuration file in the 
-                <link linkend='yocto-project-build-directory'>Yocto Project Build Directory</link>
-                contains user-defined variables that affect each build.
-                The <filename>meta-yocto/conf/distro/poky.conf</filename> configuration file
-                defines Yocto ‘distro’ configuration
-                variables used only when building with this policy.  
-                Machine configuration files, which 
-                are located throughout the Yocto Project file structure, define
-                variables for specific hardware and are only used when building for that target 
-                (e.g. the <filename>machine/beagleboard.conf</filename> configuration file defines 
-                variables for the Texas Instruments ARM Cortex-A8 development board).  
-                Configuration files end with a <filename>.conf</filename> filename extension.
-                </para></listitem>
-            <listitem><para><emphasis>Cross-Development Toolchain:</emphasis> 
-                A collection of software development
-                tools and utilities that allow you to develop software for targeted architectures.
-                This toolchain contains cross-compilers, linkers, and debuggers that are specific to 
-                an architecture.
-                You can use the Yocto Project to build cross-development toolchains in tarball form that when 
-                unpacked contain the development tools you need to cross-compile and test your software.
-                The Yocto Project ships with images that contain toolchains for supported architectures
-                as well.
-                Sometimes this toolchain is referred to as the meta-toolchain.</para></listitem>
-            <listitem><para><emphasis>Image:</emphasis> An image is the result produced when 
-                BitBake processes a given collection of recipes and related metadata.
-                Images are the binary output that runs on specific hardware and for specific
-                use cases.
-                For a list of the supported image types that the Yocto Project provides, see the
-                "<ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Reference: Images</ulink>"
-                appendix in The Yocto Project Reference Manual.</para></listitem>
-            <listitem><para id='layer'><emphasis>Layer:</emphasis> A collection of recipes representing the core, 
-                a BSP, or an application stack.
-                For a discussion on BSP Layers, see the 
-                "<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='metadata'><emphasis>Metadata:</emphasis> The files that BitBake parses when 
-                building an image. 
-                Metadata includes recipes, classes, and configuration files.</para></listitem>
-            <listitem><para><emphasis>OE-Core:</emphasis> A core set of metadata originating 
-                with OpenEmbedded (OE) that is shared between OE and the Yocto Project.
-                This metadata is found in the <filename>meta</filename> directory of the Yocto Project
-                files.</para></listitem>
-            <listitem><para><emphasis>Package:</emphasis> The packaged output from a baked recipe.
-                A package is generally the compiled binaries produced from the recipe's sources.  
-                You ‘bake’ something by running it through BitBake.</para></listitem>
-            <listitem><para><emphasis>Poky:</emphasis> The build tool that the Yocto Project 
-                uses to create images.</para></listitem>
-            <listitem><para><emphasis>Recipe:</emphasis> A set of instructions for building packages.  
-                A recipe describes where you get source code and which patches to apply.
-                Recipes describe dependencies for libraries or for other recipes, and they 
-                also contain configuration and compilation options.  
-                Recipes contain the logical unit of execution, the software/images to build, and 
-                use the <filename>.bb</filename> file extension.</para></listitem>
-            <listitem><para><emphasis>Tasks:</emphasis> Arbitrary groups of software Recipes.  
-                You simply 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>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.
-                For example, in order for a developer to work on a particular piece of code, they need to 
-                first get a copy of it from an "upstream" source.</para></listitem>
             <listitem>
-                <para id='yocto-project-files'><emphasis>Yocto Project Files:</emphasis>
-                This term refers to the directory structure created as a result of either downloading 
-                and unpacking a Yocto Project release tarball or setting up a Git repository
-                by cloning <filename>git://git.yoctoproject.org/poky</filename>.
-                Sometimes the term "the Yocto Project Files structure" is used as well.</para>
-
-                <para>The Yocto Project Files contain BitBake, Documentation, metadata and 
-                other files that all support the development environment. 
-                Consequently, you must have the Yocto Project Files in place on your development 
-                system in order to do any development using the Yocto Project.</para>
-
-                <para>The name of the top-level directory of the Yocto Project Files structure  
-                is derived from the Yocto Project release tarball.
-                For example, downloading and unpacking <filename>&YOCTO_POKY_TARBALL;</filename>
-                results in a Yocto Project file structure whose Yocto Project source directory is named 
-                <filename>&YOCTO_POKY;</filename>.
-                If you create a Git repository, then you can name the repository anything you like.
-                Throughout much of the documentation, the name of the Git repository is used as the 
-                name for the local folder.
-                So, for example, cloning the <filename>poky</filename> Git repository results in a 
-                local Git repository also named <filename>poky</filename>.</para>
-
-                <para>It is important to understand the differences between Yocto Project Files created
-                by unpacking a release tarball as compared to cloning 
-                <filename>git://git.yoctoproject.org/poky</filename>.
-                When you unpack a tarball, you have an exact copy of the files based on the time of 
-                release - a fixed release point.
-                Any changes you make to your local Yocto Project Files are on top of the release.
-                On the other hand, when you clone the Yocto Project Git repository, you have an
-                active development repository.
-                In this case, any local changes you make to the Yocto Project can be later applied 
-                to active development branches of the upstream Yocto Project Git repository.</para>
-
-                <para>Finally, if you want to track a set of local changes while starting from the same point
-                as a release tarball, you can create a local Git branch that 
-                reflects the exact copy of the files at the time of their release. 
-                You do this using Git tags that are part of the repository.</para>
-
-                <para>For more information on concepts around Git repositories, branches, and tags,
-                see the  
-                "<link linkend='repositories-tags-and-branches'>Repositories, Tags, and Branches</link>"
-                section.</para></listitem>
-            <listitem>
-                <para id='yocto-project-build-directory'><emphasis>Yocto Project Build Directory:</emphasis>
-                This term refers to the area used by the Yocto Project for builds.  
-                The area is created when you <filename>source</filename> the Yocto Project setup 
-                environment script that is found in the Yocto Project files area
+                <para id='build-directory'><emphasis>Build Directory:</emphasis>
+                This term refers to the area used by the OpenEmbedded build system for builds.  
+                The area is created when you <filename>source</filename> the setup 
+                environment script that is found in the source directory
                 (i.e. <filename>oe-init-build-env</filename>).
-                The <filename>TOPDIR</filename> variable points to the build directory.</para>
+                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 Yocto Project Build Directory.
+                <para>You have a lot of flexibility when creating the build directory.
                 Following are some examples that show how to create the directory:
                    <itemizedlist>
                         <listitem><para>Create the build directory in your current working directory
                             and name it <filename>build</filename>.
                             This is the default behavior.
                             <literallayout class='monospaced'>
-     $ cd ~/poky
      $ source oe-init-build-env
                             </literallayout></para></listitem>
                         <listitem><para>Provide a directory path and specifically name the build 
@@ -363,6 +249,140 @@
                             </literallayout></para></listitem>
                     </itemizedlist> 
                 </para></listitem> 
+            <listitem><para><emphasis>Build System:</emphasis> In the context of the Yocto Project 
+                this term refers to the OpenEmbedded build system used by the project. 
+                This build system is based on the project known as "Poky."
+                For some historical information about Poky, see the 
+                <link linkend='poky'>poky</link> term further along in this section.
+                </para></listitem>
+            <listitem><para><emphasis>Classes:</emphasis> Files that provide for logic encapsulation
+                and inheritance allowing commonly used patterns to be defined once and easily used 
+                in multiple recipes.  
+                Class files end with the <filename>.bbclass</filename> filename extension.
+                </para></listitem>
+            <listitem><para><emphasis>Configuration File:</emphasis>  Configuration information in various
+                <filename>.conf</filename> files provides global definitions of variables.
+                The <filename>conf/local.conf</filename> configuration file in the 
+                <link linkend='build-directory'>build directory</link>
+                contains user-defined variables that affect each build.
+                The <filename>meta-yocto/conf/distro/poky.conf</filename> configuration file
+                defines Yocto ‘distro’ configuration
+                variables used only when building with this policy.  
+                Machine configuration files, which 
+                are located throughout the 
+                <link linkend='source-directory'>source directory</link>, define
+                variables for specific hardware and are only used when building for that target 
+                (e.g. the <filename>machine/beagleboard.conf</filename> configuration file defines 
+                variables for the Texas Instruments ARM Cortex-A8 development board).  
+                Configuration files end with a <filename>.conf</filename> filename extension.
+                </para></listitem>
+            <listitem><para><emphasis>Cross-Development Toolchain:</emphasis> 
+                A collection of software development
+                tools and utilities that allow you to develop software for targeted architectures.
+                This toolchain contains cross-compilers, linkers, and debuggers that are specific to 
+                an architecture.
+                You can use the OpenEmbedded build system to build cross-development toolchains in tarball 
+                form that, when
+                unpacked, contain the development tools you need to cross-compile and test your software.
+                The Yocto Project ships with images that contain toolchains for supported architectures
+                as well.
+                Sometimes this toolchain is referred to as the meta-toolchain.</para></listitem>
+            <listitem><para><emphasis>Image:</emphasis> An image is the result produced when 
+                BitBake processes a given collection of recipes and related metadata.
+                Images are the binary output that run on specific hardware and for specific
+                use cases.
+                For a list of the supported image types that the Yocto Project provides, see the
+                "<ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Reference: Images</ulink>"
+                appendix in The Yocto Project Reference Manual.</para></listitem>
+            <listitem><para id='layer'><emphasis>Layer:</emphasis> A collection of recipes representing the core, 
+                a BSP, or an application stack.
+                For a discussion on BSP Layers, see the 
+                "<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='metadata'><emphasis>Metadata:</emphasis> The files that BitBake parses when 
+                building an image. 
+                Metadata includes recipes, classes, and configuration files.</para></listitem>
+            <listitem><para><emphasis>OE-Core:</emphasis> A core set of metadata originating 
+                with OpenEmbedded (OE) that is shared between OE and the Yocto Project.
+                This metadata is found in the <filename>meta</filename> directory of the source
+                directory.</para></listitem>
+            <listitem><para><emphasis>Package:</emphasis> The packaged output from a baked recipe.
+                A package is generally the compiled binaries produced from the recipe's sources.  
+                You ‘bake’ something by running it through BitBake.</para></listitem>
+            <listitem><para id='poky'><emphasis>Poky:</emphasis> The term "poky" can mean several things.
+                In its most general sence, it is an open-source project that was initially developed
+                by OpenedHand.  With OpenedHand, poky was developed off of the existing OpenEmbedded
+                build system becoming a build system for embedded images. 
+                After Intel Corporation aquired OpenedHand, the project poky became the basis for 
+                the Yocto Project's build system.
+                Within the Yocto Project source repositories, poky exists as a separate Git repository
+                that can be cloned to yield a local copy on the host system. 
+                Thus, "poky" can refer to the local copy of the source directory used to develop within
+                the Yocto Project.</para></listitem>
+            <listitem><para><emphasis>Recipe:</emphasis> A set of instructions for building packages.  
+                A recipe describes where you get source code and which patches to apply.
+                Recipes describe dependencies for libraries or for other recipes, and they 
+                also contain configuration and compilation options.  
+                Recipes contain the logical unit of execution, the software/images to build, and 
+                use the <filename>.bb</filename> file extension.</para></listitem>
+            <listitem>
+                <para id='source-directory'><emphasis>Source Directory:</emphasis>
+                This term refers to the directory structure created as a result of either downloading 
+                and unpacking a Yocto Project release tarball or creating a local copy of 
+                <filename>poky</filename> Git repository <filename>git://git.yoctoproject.org/poky</filename>.
+                Sometimes you might here the term "poky directory" used to refer to this 
+                directory structure.</para>
+
+                <para>The source directory contains BitBake, Documentation, metadata and 
+                other files that all support the Yocto Project. 
+                Consequently, you must have the source directory in place on your development 
+                system in order to do any development using the Yocto Project.</para>
+
+                <para>For tarball expansion, the name of the top-level directory of the source directory  
+                is derived from the Yocto Project release tarball.
+                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 
+                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.
+                So, for example, cloning the <filename>poky</filename> Git repository results in a 
+                local Git repository whose top-level folder is also named <filename>poky</filename>.</para>
+
+                <para>It is important to understand the differences between the source directory created
+                by unpacking a released tarball as compared to cloning 
+                <filename>git://git.yoctoproject.org/poky</filename>.
+                When you unpack a tarball, you have an exact copy of the files based on the time of 
+                release - a fixed release point.
+                Any changes you make to your local files in the source directory are on top of the release.
+                On the other hand, when you clone the <filename>poky</filename> Git repository, you have an
+                active development repository.
+                In this case, any local changes you make to the source directory can be later applied 
+                to active development branches of the upstream <filename>poky</filename> Git 
+                repository.</para>
+
+                <para>Finally, if you want to track a set of local changes while starting from the same point
+                as a release tarball, you can create a local Git branch that 
+                reflects the exact copy of the files at the time of their release. 
+                You do this using Git tags that are part of the repository.</para>
+
+                <para>For more information on concepts around Git repositories, branches, and tags,
+                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 simply 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>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.
+                For example, in order for a developer to work on a particular piece of code, they need to 
+                first get a copy of it from an "upstream" source.</para></listitem>
         </itemizedlist>
     </para>
 </section>
@@ -402,7 +422,7 @@
         <filename>meta/files/common-licenses</filename>.  
         Once the build completes, the list of all licenses found and used during that build are 
         kept in the 
-        <link linkend='yocto-project-build-directory'>Yocto Project Build Directory</link> at 
+        <link linkend='build-directory'>build directory</link> at 
         <filename>tmp/deploy/images/licenses</filename>.
     </para>
 
@@ -494,7 +514,8 @@
             Git uses "branches" to organize different development efforts. 
             For example, the <filename>poky</filename> repository has 
             <filename>laverne</filename>, <filename>bernard</filename>, 
-            <filename>edison</filename>, and <filename>master</filename> branches among 
+            <filename>edison</filename>, <filename>denzil</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 
@@ -525,12 +546,12 @@
      $ cd ~
      $ git clone git://git.yoctoproject.org/poky
      $ cd poky
-     $ git checkout &DISTRO_NAME; -b &DISTRO_NAME;
+     $ git checkout -b &DISTRO_NAME; origin/&DISTRO_NAME;
             </literallayout>
             In this example, the name of the top-level directory of your local Yocto Project 
-            Files Git repository is <filename>poky</filename>.
-            And, the name of the local working area (or local branch) you have created and checked 
-            out is named <filename>&DISTRO_NAME;</filename>.
+            Files Git repository is <filename>poky</filename>,
+            and the name of the local working area (or local branch) you have created and checked
+            out is <filename>&DISTRO_NAME;</filename>.
             The files in your repository now reflect the same files that are in the 
             <filename>&DISTRO_NAME;</filename> development branch of the Yocto Project's 
             <filename>poky</filename> repository.
@@ -577,14 +598,14 @@
      $ cd ~
      $ git clone git://git.yoctoproject.org/poky
      $ cd poky
-     $ git checkout &DISTRO_NAME;-&POKYVERSION; -b &DISTRO_NAME;-&POKYVERSION;
+     $ git checkout -b my-&DISTRO_NAME;-&POKYVERSION; &DISTRO_NAME;-&POKYVERSION;
             </literallayout>
             In this example, the name of the top-level directory of your local Yocto Project 
             Files Git repository is <filename>poky</filename>.
             And, the name of the local branch you have created and checked out is
-            <filename>&DISTRO_NAME;-&POKYVERSION;</filename>.
+            <filename>my-&DISTRO_NAME;-&POKYVERSION;</filename>.
             The files in your repository now exactly match the Yocto Project &DISTRO;
-            Release tag (&DISTRO_NAME;).
+            Release tag (<filename>&DISTRO_NAME;-&POKYVERSION;</filename>).
             It is important to understand that when you create and checkout a local 
             working branch based on a tag, your environment matches a specific point 
             in time and not a development branch.
@@ -853,54 +874,53 @@
             <listitem><para>Submit the bug by clicking the "Submit Bug" button.</para></listitem>
         </orderedlist>
     </para>
- 
-    <note>
-        Bugs in the Yocto Project Bugzilla follow naming convention: 
-        <filename>[YOCTO #&lt;number&gt;]</filename>, where <filename>&lt;number&gt;</filename> is the 
-        assigned defect ID used in Bugzilla.  
-        So, for example, a valid way to refer to a defect would be <filename>[YOCTO #1011]</filename>.   
-        This convention becomes important if you are submitting patches against the Yocto Project 
-        code itself.
-    </note>
 </section>
 
 <section id='how-to-submit-a-change'>
     <title>How to Submit a Change</title>
 
     <para>
-        Contributions to the Yocto Project are very welcome. 
-        Because the Yocto Project is extremely configurable and flexible, we recognize that developers 
+        Contributions to the Yocto Project and OpenEmbedded are very welcome.
+        Because the system is extremely configurable and flexible, we recognize that developers
         will want to extend, configure or optimize it for their specific uses.
-        You should send patches to the appropriate Yocto Project mailing list to get them 
-        in front of the Yocto Project Maintainer.
-        For a list of the Yocto Project mailing lists, see the
+        You should send patches to the appropriate mailing list so that they
+        can be reviewed and merged by the appropriate maintainer.
+        For a list of the Yocto Project and related mailing lists, see the
         "<ulink url='&YOCTO_DOCS_REF_URL;#resources-mailinglist'>Mailing lists</ulink>" section in 
         The Yocto Project Reference Manual.
     </para>
 
     <para>
-        The following is some guidance on which mailing list to use for what type of defect:
+        The following is some guidance on which mailing list to use for what type of change:
         <itemizedlist>
-            <listitem><para>For defects against the Yocto Project build system Poky, send 
-                your patch to the  
-                <ulink url='&YOCTO_LISTS_URL;/listinfo/poky'></ulink> mailing list. 
-                This mailing list corresponds to issues that are not specific to the Yocto Project but
-                are part of the OE-core.
-                For example, a defect against anything in the <filename>meta</filename> layer 
-                or the BitBake Manual could be sent to this mailing list.</para></listitem>
-            <listitem><para>For defects against Yocto-specific layers, tools, and Yocto Project 
-                documentation use the 
-                <ulink url='&YOCTO_LISTS_URL;/listinfo/yocto'></ulink> mailing list.
-                This mailing list corresponds to Yocto-specific areas such as 
-                <filename>meta-yocto</filename>, <filename>meta-intel</filename>, 
-                <filename>linux-yocto</filename>, and <filename>documentation</filename>.</para></listitem>
+            <listitem><para>For changes to the core metadata, send your patch to the
+                <ulink url='&OE_LISTS_URL;/listinfo/openembedded-core'>openembedded-core</ulink> mailing list.
+                For example, a change to anything under the <filename>meta</filename> or
+                <filename>scripts</filename> directories
+                should be sent to this mailing list.</para></listitem>
+            <listitem><para>For changes to BitBake (anything under the <filename>bitbake</filename>
+                directory), send your patch to the
+                <ulink url='&OE_LISTS_URL;/listinfo/bitbake-devel'>bitbake-devel</ulink> mailing list.</para></listitem>
+            <listitem><para>For changes to <filename>meta-yocto</filename>, send your patch to the
+                <ulink url='&YOCTO_LISTS_URL;/listinfo/poky'>poky</ulink> mailing list.</para></listitem>
+            <listitem><para>For changes to other layers hosted on yoctoproject.org (unless the
+                layer's documentation specifies otherwise), tools, and Yocto Project
+                documentation, use the
+                <ulink url='&YOCTO_LISTS_URL;/listinfo/yocto'>yocto</ulink> mailing list.</para></listitem>
+            <listitem><para>For additional recipes that do not fit into the core metadata,
+                you should determine which layer the recipe should go into and submit the
+                change in the manner recommended by the documentation (e.g. README) supplied
+                with the layer. If in doubt, please ask on the
+                <ulink url='&YOCTO_LISTS_URL;/listinfo/yocto'>yocto</ulink> or
+                <ulink url='&OE_LISTS_URL;/listinfo/openembedded-devel'>openembedded-devel</ulink>
+                mailing lists.</para></listitem>
         </itemizedlist>      
     </para>
 
     <para>  
         When you send a patch, be sure to include a "Signed-off-by:"
         line in the same style as required by the Linux kernel. 
-        Adding this line signifies the developer has agreed to the Developer's Certificate of Origin 1.1
+        Adding this line signifies that you, the submitter, have agreed to the Developer's Certificate of Origin 1.1
         as follows:
         <literallayout class='monospaced'>
      Developer's Certificate of Origin 1.1
@@ -929,52 +949,52 @@
          maintained indefinitely and may be redistributed consistent with
          this project or the open source license(s) involved.
         </literallayout>
-        A Poky contributions tree (<filename>poky-contrib</filename>, 
-        <filename>git://git.yoctoproject.org/poky-contrib.git</filename>)
-        exists for contributors to stage contributions.
-        If people desire such access, please ask on the mailing list. 
-        Usually, the Yocto Project team will grant access to anyone with a proven track 
-        record of good patches.
     </para>
 
     <para>
         In a collaborative environment, it is necessary to have some sort of standard 
         or method through which you submit changes.  
         Otherwise, things could get quite chaotic.
-        One general practice to follow is to make small, controlled changes to the 
-        Yocto Project.
-        Keeping changes small and isolated lets you best keep pace with future Yocto Project changes.
+        One general practice to follow is to make small, controlled changes.
+        Keeping changes small and isolated aids review, makes merging/rebasing easier
+        and keeps the change history clean when anyone needs to refer to it in future.
     </para>
 
     <para>
-        When you create a commit, you must follow certain standards established by the
-        Yocto Project development team. 
-        For each commit, you must provide a single-line summary of the change and you 
-        almost always provide a more detailed description of what you did (i.e. the body 
-        of the commit).
+        When you make a commit, you must follow certain standards established by the
+        OpenEmbedded and Yocto Project development teams.
+        For each commit, you must provide a single-line summary of the change and you
+        should almost always provide a more detailed description of what you did (i.e.
+        the body of the commit message).
         The only exceptions for not providing a detailed description would be if your 
         change is a simple, self-explanatory change that needs no description.
-        Here are the Yocto Project commit message guidelines:
+        Here are the guidelines for composing a commit message:
         <itemizedlist>
             <listitem><para>Provide a single-line, short summary of the change.
-                This summary is typically viewable by source control systems.
+                This summary is typically viewable in the "shortlist" of changes.
                 Thus, providing something short and descriptive that gives the reader 
                 a summary of the change is useful when viewing a list of many commits.
+                This should be prefixed by the recipe name (if changing a recipe), or
+                else the short form path to the file being changed.
                 </para></listitem>
             <listitem><para>For the body of the commit message, provide detailed information
                 that describes what you changed, why you made the change, and the approach
-                you used.  
+                you used. It may also be helpful if you mention how you tested the change.
                 Provide as much detail as you can in the body of the commit message.
                 </para></listitem>
             <listitem><para>If the change addresses a specific bug or issue that is 
-                associated with a bug-tracking ID, prefix your detailed description
-                with the bug or issue ID.  
-                For example, the Yocto Project tracks bugs using a bug-naming convention.
-                Any commits that address a bug must start with the bug ID in the description
-                as follows:
+                associated with a bug-tracking ID, include a reference to that ID in
+                your detailed description.
+                For example, the Yocto Project uses a specific convention for bug
+                references - any commit that addresses a specific bug should include the
+                bug ID in the description (typically at the end) as follows:
                 <literallayout class='monospaced'>
-     YOCTO #&lt;bug-id&gt;:  &lt;Detailed description of commit&gt;
+     &lt;detailed description of change&gt;
+
+     [YOCTO #&lt;bug-id&gt;]
                 </literallayout></para></listitem>
+                Where &lt;bug-id&gt; is replaced with the specific bug ID from the
+                Yocto Project Bugzilla instance.
         </itemizedlist>
     </para>
 
@@ -995,11 +1015,11 @@
             The basic flow for pushing a change to an upstream "contrib" Git repository is as follows:
             <itemizedlist>
                 <listitem><para>Make your changes in your local Git repository.</para></listitem>
-                <listitem><para>Stage your commit (or change) by using the <filename>git add</filename>
-                    command.</para></listitem>
+                <listitem><para>Stage your changes by using the <filename>git add</filename>
+                    command on each file you changed.</para></listitem>
                 <listitem><para>Commit the change by using the <filename>git commit</filename>
                     command and push it to the "contrib" repository.  
-                    Be sure to provide a commit message that follows the project’s commit standards
+                    Be sure to provide a commit message that follows the project’s commit message standards
                     as described earlier.</para></listitem>
                 <listitem><para>Notify the maintainer that you have pushed a change by making a pull 
                     request.
@@ -1010,10 +1030,10 @@
                     You can find these scripts in the <filename>scripts</filename> directory of the 
                     Yocto Project file structure.</para>
                     <para>For help on using these scripts, simply provide the 
-                    <filename>--help</filename> argument as follows:
+                    <filename>-h</filename> argument as follows:
                     <literallayout class='monospaced'>
-     $ ~/poky/scripts/create-pull-request --help
-     $ ~/poky/scripts/send-pull-request --help
+     $ ~/poky/scripts/create-pull-request -h
+     $ ~/poky/scripts/send-pull-request -h
                     </literallayout></para></listitem>
             </itemizedlist>
         </para>
@@ -1028,13 +1048,24 @@
         <title>Submitting a Patch Through Email</title>
 
         <para>
-            If you have a just a few changes, you can commit them and then submit them as an 
+            If you have a just few changes, you can commit them and then submit them as an 
             email to the maintainer.
-            Here is a general procedure:
+            Depending on the components changed, you need to submit the email to a specific
+            mailing list.
+            For some guidance on which mailing list to use, see the list in the 
+            "<link linkend='how-to-submit-a-change'>How to Submit a Change</link>" section
+            earlier in this manual.
+            For a description of the available mailing lists, see
+            "<ulink url='&YOCTO_DOCS_REF_URL;#resources-mailinglist'>Mailing Lists</ulink>"
+            section in the Yocto Project Reference Manual.
+        </para>
+
+        <para>            
+            Here is the general procedure on how to submit a patch through email:
             <itemizedlist>
                 <listitem><para>Make your changes in your local Git repository.</para></listitem>
-                <listitem><para>Stage your commit (or change) by using the <filename>git add</filename>
-                    command.</para></listitem>
+                <listitem><para>Stage your changes by using the <filename>git add</filename>
+                    command on each file you changed.</para></listitem>
                 <listitem><para>Commit the change by using the 
                     <filename>git commit --signoff</filename> command.
                     Using the <filename>--signoff</filename> option identifies you as the person 
@@ -1067,7 +1098,17 @@
                     the series of patches.
                     For information on the <filename>git format-patch</filename> command, 
                     see <filename>GIT_FORMAT_PATCH(1)</filename> displayed using the  
-                    <filename>man git-format-patch</filename> command.</para></listitem>
+                    <filename>man git-format-patch</filename> command.</para>
+                    <note>If you have many patches to submit, you might consider using the 
+                    method described in the "<link linkend='pushing-a-change-upstream'>Pushing
+                    a change Upstream and Requesting a Pull</link>" section described 
+                    earlier in the manual.
+                    This method uses the <filename>create-pull-request</filename> and 
+                    <filename>send-pull-request</filename> scripts that automate much of the 
+                    process.
+                    You might also consider requesting a contrib area and the associated rights
+                    needed if you become a regular contributor to either the Yocto Project or 
+                    OpenEmbedded.</note></listitem>
                 <listitem><para>Import the files into your mail client by using the 
                     <filename>git send-email</filename> command.
                     <note>In order to use <filename>git send-email</filename>, you must have the 

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

@@ -24,14 +24,16 @@
 
     <para>
         The Yocto Project is an open-source collaboration project focused on embedded Linux development.  
-        The project currently provides a build system, which is sometimes referred to as "Poky",
-        and provides various ancillary tools suitable for the embedded developer.  
-        The Yocto Project also features the Sato reference User Interface, which is optimized for 
+        The project currently provides a build system, which is 
+        referred to as the OpenEmbedded build system in the Yocto Project documentation.
+        The Yocto Project provides various ancillary tools suitable for the embedded developer  
+        and also features the Sato reference User Interface, which is optimized for 
         stylus driven, low-resolution screens.
     </para>
 
     <para>
-        You can use the Yocto Project, which uses the BitBake build tool, to develop complete Linux 
+        You can use the OpenEmbedded build system, which uses 
+        <ulink url='http://bitbake.berlios.de/manual/'>BitBake</ulink>, to develop complete Linux 
         images and associated user-space applications for architectures based on ARM, MIPS, PowerPC, 
         x86 and x86-64.  
         While the Yocto Project does not provide a strict testing framework,
@@ -52,56 +54,50 @@
             <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, or Ubuntu as these releases are frequently tested against the Yocto Project
+                OpenSUSE, Ubuntu, or CentOS as these releases are frequently tested against the Yocto Project
                 and officially supported.  
                 You should also have about 100 gigabytes of free disk space for building images.
                 </para></listitem>
-            <listitem><para><emphasis>Packages:</emphasis>  The Yocto Project 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 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 for the exact package 
+                section in the Yocto Project Quick Start for the exact package
                 requirements and the installation commands to install 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 can get set up with local 
-                <link linkend='yocto-project-files'>Yocto Project Files</link> one of two ways 
-                depending on whether you 
-                are going to be contributing back into the Yocto Project source repository or not.
+                You set up a with 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 
-                    hierarchical set of files as the "Yocto Project Files" or the "Yocto Project File
-                    Structure."
+                    Regardless of the method you use, this manual refers to the resulting local
+                    hierarchical set of files as the "source directory."
                 </note>
                 <itemizedlist>
                     <listitem><para><emphasis>Tarball Extraction:</emphasis>  If you are not going to contribute 
-                        back into the Yocto Project, you can simply download the Yocto Project release you want 
+                        back into the Yocto Project, you can simply download a Yocto Project release you want 
                         from the website’s <ulink url='&YOCTO_HOME_URL;/download'>download page</ulink>.
                         Once you have the tarball, just extract it into a 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 Yocto Project file structure
-                        with a top-level directory 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 Git repository. 
-                        Instead, you simply end up with a local snapshot of the 
-                        Yocto Project files that are based on the particular release in the 
-                        tarball.</para></listitem>
+                        <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 Yocto Project Files.
-                        Doing so creates a Git repository with a complete history of changes and allows 
+                        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 cloned the repository, you have access to all the Yocto Project development
                         branches and tag names used in the upstream repository.</para>
-                        <para>The following transcript shows how to clone the Yocto Project Files'  
+                        <para>The following transcript shows how to clone the <filename>poky</filename>  
                         Git repository into the current working directory.
-                        <note>The name of the Yocto Project Files Git repository in the Yocto Project Files
-                        Source Repositories is <filename>poky</filename>.
-                        You can view the Yocto Project Source Repositories at
+                        <note>You can view the Yocto Project Source Repositories at
                         <ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink></note>  
                         The command creates the local repository in a directory named <filename>poky</filename>.
                         For information on Git used within the Yocto Project, see the
@@ -109,52 +105,52 @@
                         <literallayout class='monospaced'>
      $ git clone git://git.yoctoproject.org/poky
      Initialized empty Git repository in /home/scottrif/poky/.git/
-     remote: Counting objects: 116882, done.
-     remote: Compressing objects: 100% (35987/35987), done.
-     remote: Total 116882 (delta 80651), reused 113045 (delta 77578)
-     Receiving objects: 100% (116882/116882), 72.13 MiB | 2.68 MiB/s, done.
-     Resolving deltas: 100% (80651/80651), done.
+     remote: Counting objects: 141863, done.
+     remote: Compressing objects: 100% (38624/38624), done.
+     remote: Total 141863 (delta 99661), reused 141816 (delta 99614)
+     Receiving objects: 100% (141863/141863), 76.64 MiB | 126 KiB/s, done.
+     Resolving deltas: 100% (99661/99661), 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>
                 </itemizedlist></para></listitem>
-            <listitem id='local-kernel-files'><para><emphasis>Linux Yocto Kernel:</emphasis>  
-                If you are going to be making modifications to a supported Linux Yocto kernel, you 
+            <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 Linux Yocto Kernels organized under
-                "Yocto Linux Kernel" in the Yocto Project Source Repositories at
+                You can find Git repositories of supported Yocto Project Kernels organized under
+                "Yocto Project Linux Kernel" in the Yocto Project Source Repositories at
                 <ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink>.</para>
-                <para>This setup involves creating a bare clone of the Linux Yocto kernel and then 
+                <para>This setup involves creating a bare clone of the Yocto Project kernel and then 
                 copying that cloned repository.
                 You can create the bare clone and the copy of the bare clone anywhere you like.
                 For simplicity, it is recommended that you create these structures outside of the 
-                Yocto Project Files Git repository.</para>
+                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.0-1.1.x</filename> kernel and then create a copy of 
+                of the <filename>linux-yocto-3.2</filename> kernel and then create a copy of 
                 that clone.
-                <note>When you have a local Linux Yocto kernel Git repository, you can 
+                <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.0-1.1.x.git</filename>, while the 
-                copy is named <filename>my-linux-yocto-3.0-1.1.x-work</filename>: 
+                <filename>linux-yocto-3.2.git</filename>, while the 
+                copy is named <filename>my-linux-yocto-3.2-work</filename>: 
                 <literallayout class='monospaced'>
-     $ git clone --bare git://git.yoctoproject.org/linux-yocto-3.0-1.1.x linux-yocto-3.0-1.1.x.git
-     Initialized empty Git repository in /home/scottrif/linux-yocto-3.0-1.1.x.git/
-     remote: Counting objects: 2259181, done.
-     remote: Compressing objects: 100% (373259/373259), done.
-     remote: Total 2259181 (delta 1892638), reused 2231556 (delta 1865300)
-     Receiving objects: 100% (2259181/2259181), 482.44 MiB | 580 KiB/s, done.
-     Resolving deltas: 100% (1892638/1892638), done.
+     $ git clone --bare git://git.yoctoproject.org/linux-yocto-3.2 linux-yocto-3.2.git
+     Initialized empty Git repository in /home/scottrif/linux-yocto-3.2.git/
+     remote: Counting objects: 2468027, done.
+     remote: Compressing objects: 100% (392255/392255), done.
+     remote: Total 2468027 (delta 2071693), reused 2448773 (delta 2052498)
+     Receiving objects: 100% (2468027/2468027), 530.46 MiB | 129 KiB/s, done.
+     Resolving deltas: 100% (2071693/2071693), done.
                 </literallayout></para>
                 <para>Now create a clone of the bare clone just created:
                 <literallayout class='monospaced'>
-     $ git clone linux-yocto-3.0-1.1.x.git my-linux-yocto-3.0-1.1.x-work
-     Initialized empty Git repository in /home/scottrif/my-linux-yocto-3.0-1.1.x/.git/
-     Checking out files: 100% (36898/36898), done.
+     $ git clone linux-yocto-3.2.git my-linux-yocto-3.2-work
+     Initialized empty Git repository in /home/scottrif/my-linux-yocto-3.2-work/.git/
+     Checking out files: 100% (37619/37619), done.
                 </literallayout></para></listitem>
             <listitem id='poky-extras-repo'><para><emphasis>
                 The <filename>poky-extras</filename> Git Repository</emphasis>:
@@ -165,24 +161,22 @@
                 edit to point to your locally modified kernel source files and to build the kernel
                 image. 
                 Pointing to these local files is much more efficient than requiring a download of the 
-                source files from upstream each time you make changes to the kernel.</para>
+                kernel's source files from upstream each time you make changes to the kernel.</para>
                 <para>You can find the <filename>poky-extras</filename> Git Repository in the 
                 "Yocto Metadata Layers" area of the Yocto Project Source Repositories at 
                 <ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink>.
-                It is good practice to create this Git repository inside the Yocto Project
-                files Git repository.</para>
+                It is good practice to create this Git repository inside the source directory.</para>
                 <para>Following is an example that creates the <filename>poky-extras</filename> Git 
-                repository inside the Yocto Project files Git repository, which is named 
-                <filename>poky</filename> in this case:
+                repository inside the source directory, which is named <filename>poky</filename> 
+                in this case:
                 <literallayout class='monospaced'>
-     $ cd ~/poky
      $ git clone git://git.yoctoproject.org/poky-extras poky-extras
      Initialized empty Git repository in /home/scottrif/poky/poky-extras/.git/
-     remote: Counting objects: 561, done.
-     remote: Compressing objects: 100% (501/501), done.
-     remote: Total 561 (delta 159), reused 306 (delta 39)
-     Receiving objects: 100% (561/561), 519.96 KiB | 479 KiB/s, done.
-     Resolving deltas: 100% (159/159), done.
+     remote: Counting objects: 618, done.
+     remote: Compressing objects: 100% (558/558), done.
+     remote: Total 618 (delta 192), reused 307 (delta 39)
+     Receiving objects: 100% (618/618), 526.26 KiB | 111 KiB/s, done.
+     Resolving deltas: 100% (192/192), done.
                 </literallayout></para></listitem>
            <listitem><para id='supported-board-support-packages-(bsps)'><emphasis>Supported Board 
                 Support Packages (BSPs):</emphasis>  
@@ -194,7 +188,7 @@
                 layer.  
                 You can get set up for BSP development one of two ways: tarball extraction or
                 with a local Git repository.
-                It is a good idea to use the same method used to set up the Yocto Project Files.
+                It is a good idea to use the same method that you used to set up the source directory.
                 Regardless of the method you use, the Yocto Project uses the following BSP layer 
                 naming scheme:
                 <literallayout class='monospaced'> 
@@ -220,25 +214,24 @@
                         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 Yocto Project Files Git repository, you should also use this method 
+                        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
-                        the Yocto Project Files Git repository.
+                        the source directory.
                         For example, the following transcript shows the steps to clone the 
                         <filename>meta-intel</filename>
-                        Git repository inside the <filename>poky</filename> Git repository.
+                        Git repository inside the local <filename>poky</filename> Git repository.
                         <literallayout class='monospaced'>
-     $ cd poky
      $ git clone git://git.yoctoproject.org/meta-intel.git
      Initialized empty Git repository in /home/scottrif/poky/meta-intel/.git/
-     remote: Counting objects: 1325, done.
-     remote: Compressing objects: 100% (1078/1078), done.
-     remote: Total 1325 (delta 546), reused 85 (delta 27)
-     Receiving objects: 100% (1325/1325), 1.56 MiB | 330 KiB/s, done.
-     Resolving deltas: 100% (546/546), done.
+     remote: Counting objects: 3380, done.
+     remote: Compressing objects: 100% (2750/2750), done.
+     remote: Total 3380 (delta 1689), reused 227 (delta 113)
+     Receiving objects: 100% (3380/3380), 1.77 MiB | 128 KiB/s, done.
+     Resolving deltas: 100% (1689/1689), done.
                         </literallayout></para>
                         <para>The same  
                         <ulink url='&YOCTO_WIKI_URL;/wiki/Transcript:_from_git_checkout_to_meta-intel_BSP'>
@@ -269,13 +262,13 @@
     <para>
         The build process is as follows:
         <orderedlist>
-            <listitem><para>Make sure you have the Yocto Project files as described in the 
+            <listitem><para>Make sure you have set up the source directory described in the 
                 previous section.</para></listitem>
             <listitem><para>Initialize the build environment by sourcing a build environment 
                 script.</para></listitem>
-            <listitem><para>Optionally ensure the <filename>/conf/local.conf</filename> configuration file, 
+            <listitem><para>Optionally ensure the <filename>conf/local.conf</filename> configuration file,
                 which is found in the 
-                <link linkend='yocto-project-build-directory'>Yocto Project Build Directory</link>, 
+                <link linkend='build-directory'>build directory</link>, 
                 is set up how you want it.  
                 This file defines many aspects of the build environment including 
                 the target machine architecture through the 
@@ -298,20 +291,85 @@
     <title>Using Pre-Built Binaries and QEMU</title>
 
     <para>
-        Another option you have to get started is to use pre-built binaries.  
-        This scenario is ideal for developing software applications to run on your target hardware.  
-        To do this, you need to install the stand-alone Yocto Project cross-toolchain tarball and 
-        then download the pre-built kernel that you will boot in the QEMU emulator.  
-        Next, you must download and extract the target root filesystem for your target 
-        machine’s architecture.  
-        Finally, you set up the environment to emulate the hardware and then start the QEMU emulator.
+        Another option you have to get started is to use pre-built binaries. 
+        The Yocto Project provides many types of binaries with each release. 
+        See the <ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Reference: Images</ulink>
+        section for descriptions of the types of binaries that ship with a Yocto Project
+        release.
     </para>
 
     <para>
+        Using a pre-built binary is ideal for developing software applications to run on your 
+        target hardware.  
+        To do this, you need to be able to access the appropriate cross-toolchain tarball for 
+        the architecture on which you are developing.  
+        If you are using an SDK type image, the image ships with the complete toolchain native to 
+        the architecture. 
+        If you are not using an SDK type image, you need to separately download and 
+        install the stand-alone Yocto Project cross-toolchain tarball.
+    </para>
+
+    <para>
+        Regardless of the type of image you are using, you need to download the pre-built kernel 
+        that you will boot in the QEMU emulator and then download and extract the target root 
+        filesystem for your target machine’s architecture.
+        You can get architecture-specific binaries and filesystem from
+        <ulink url='&YOCTO_MACHINES_DL_URL;'>machines</ulink>.
+        You can get stand-alone toolchains from
+        <ulink url='&YOCTO_TOOLCHAIN_DL_URL;'>toolchains</ulink>.
+        Once you have all your files, you set up the environment to emulate the hardware 
+        by sourcing an environment setup script. 
+        Finally, you start the QEMU emulator.
         You can find details on all these steps in the 
         "<ulink url='&YOCTO_DOCS_QS_URL;#using-pre-built'>Using Pre-Built Binaries and QEMU</ulink>"
         section of the Yocto Project Quick Start. 
     </para>
+
+    <para> 
+        Using QEMU to emulate your hardware can result in speed issues
+        depending on the target and host architecture mix.
+        For example, using the <filename>qemux86</filename> image in the emulator 
+        on an Intel-based 32-bit (x86) host machine is fast because the target and 
+        host architectures match.
+        On the other hand, using the <filename>qemuarm</filename> image on the same Intel-based
+        host can be slower.
+        But, you still achieve faithful emulation of ARM-specific issues. 
+    </para>
+
+    <para>
+        To speed things up, the QEMU images support using <filename>distcc</filename>
+        to call a cross-compiler outside the emulated system. 
+        If you used <filename>runqemu</filename> to start QEMU, and the
+        <filename>distccd</filename> application is present on the host system, any 
+        BitBake cross-compiling toolchain available from the build system is automatically
+        used from within QEMU simply by calling <filename>distcc</filename>.
+        You can accomplish this by defining the cross-compiler variable 
+        (e.g. <filename>export CC="distcc"</filename>).
+        Alternatively, if you are using a suitable SDK image or the appropriate
+        stand-alone toolchain is present in <filename>/opt/poky</filename>,
+        the toolchain is also automatically used.
+    </para>
+
+    <note>
+        Several mechanisms exist that let you connect to the system running on the 
+        QEMU emulator:
+        <itemizedlist>
+            <listitem><para>QEMU provides a framebuffer interface that makes standard 
+                consoles available.</para></listitem>
+            <listitem><para>Generally, headless embedded devices have a serial port.
+                If so, you can configure the operating system of the running image
+                to use that port to run a console. 
+                The connection uses standard IP networking.</para></listitem>
+            <listitem><para>The QEMU images have a Dropbear secure shell (ssh) server 
+                that runs with the root password disabled.
+                This allows you to use standard <filename>ssh</filename> and 
+                <filename>scp</filename> commands.</para></listitem>
+            <listitem><para>The QEMU images also contain an embedded Network File
+                System (NFS) server that exports the image's root filesystem.
+                This allows you to make the filesystem available to the 
+                host.</para></listitem>
+        </itemizedlist>
+    </note>
 </section>
 </chapter>
 <!--

documentation/dev-manual/dev-manual.xml

@@ -36,8 +36,13 @@
             </revision>
             <revision>
                 <revnumber>1.2</revnumber>
-                <date>TBD 2012</date>
-                <revremark>Work in progress for the Yocto Project 1.2 Release.</revremark>
+                <date>April 2012</date>
+                <revremark>Released with the Yocto Project 1.2 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.3</revnumber>
+                <date>Sometime in 2012</date>
+                <revremark>Released with the Yocto Project 1.3 Release.</revremark>
             </revision>
         </revhistory>
 

documentation/kernel-manual/kernel-concepts.xml

@@ -9,10 +9,10 @@
 <section id='concepts-org'>
     <title>Introduction</title>
     <para>
-        This chapter provides conceptual information about the Yocto Project kernel:
+        This chapter provides conceptual information about the kernel:
         <itemizedlist>
             <listitem><para>Kernel Goals</para></listitem>
-            <listitem><para>Yocto Project Kernel Development and Maintenance Overview</para></listitem>
+            <listitem><para>Kernel Development and Maintenance Overview</para></listitem>
             <listitem><para>Kernel Architecture</para></listitem>
             <listitem><para>Kernel Tools</para></listitem>
         </itemizedlist>
@@ -25,8 +25,8 @@
             The complexity of embedded kernel design has increased dramatically. 
             Whether it is managing multiple implementations of a particular feature or tuning and
             optimizing board specific features, flexibility and maintainability are key concerns. 
-            The Yocto Project Linux kernel is presented with the embedded
-            developer's needs in mind and has evolved to assist in these key concerns. 
+            The Linux kernels available through the Yocto Project are presented with the embedded
+            developer's needs in mind and have evolved to assist in these key concerns. 
             For example, prior methods such as applying hundreds of patches to an extracted
             tarball have been replaced with proven techniques that allow easy inspection,
             bisection and analysis of changes. 
@@ -34,7 +34,7 @@
             collaboration with the thousands of upstream development projects.
         </para>
         <para>
-            With all these considerations in mind, the Yocto Project kernel and development team
+            With all these considerations in mind, the Yocto Project's kernel and development team
             strives to attain these goals:
         <itemizedlist>
             <listitem><para>Allow the end user to leverage community best practices to seamlessly 
@@ -63,12 +63,12 @@
     <section id='kernel-big-picture'>
         <title>Yocto Project Kernel Development and Maintenance Overview</title>
         <para>
-            The Yocto Project kernel, like other kernels, is based off the Linux kernel release
-            from <ulink url='http://www.kernel.org'></ulink>.  
+            Kernels available through the Yocto Project, like other kernels, are based off the Linux 
+            kernel releases from <ulink url='http://www.kernel.org'></ulink>.  
             At the beginning of a major development cycle, the Yocto Project team
-            chooses its Yocto Project kernel 
-            based on factors like release timing, the anticipated release timing of final
-            upstream <filename>kernel.org</filename> versions, and Yocto Project feature requirements.
+            chooses its kernel based on factors such as release timing, the anticipated release 
+            timing of final upstream <filename>kernel.org</filename> versions, and Yocto Project 
+            feature requirements.
             Typically, the kernel chosen is in the
             final stages of development by the community.
             In other words, the kernel is in the release
@@ -80,21 +80,21 @@
         <para>
             This balance allows the team to deliver the most up-to-date kernel
             as possible, while still ensuring that the team has a stable official release for
-            the baseline kernel version.
+            the baseline Linux kernel version.
         </para>
         <para>
-            The ultimate source for the Yocto Project kernel is a released kernel 
+            The ultimate source for kernels available through the Yocto Project are released kernels 
             from <filename>kernel.org</filename>.
-            In addition to a foundational kernel from <filename>kernel.org</filename>, the released 
-            Yocto Project kernel contains a mix of important new mainline
+            In addition to a foundational kernel from <filename>kernel.org</filename>, the  
+            kernels available through the contain a mix of important new mainline
             developments, non-mainline developments (when there is no alternative),
             Board Support Package (BSP) developments,
             and custom features.
-            These additions result in a commercially released Yocto Project kernel that caters 
+            These additions result in a commercially released Yocto Project Linux kernel that caters 
             to specific embedded designer needs for targeted hardware.
         </para>
         <para>
-            Once a Yocto Project kernel is officially released, the Yocto Project team goes into 
+            Once a kernel is officially released, the Yocto Project team goes into 
             their next development cycle, or upward revision (uprev) cycle, while still 
             continuing maintenance on the released kernel.
             It is important to note that the most sustainable and stable way
@@ -127,8 +127,8 @@
             These policies result in both a stable and a cutting
             edge kernel that mixes forward ports of existing features and significant and critical 
             new functionality. 
-            Forward porting functionality in the Yocto Project kernel can be thought of as a
-            "micro uprev."
+            Forward porting functionality in the kernels available through the Yocto Project kernel 
+            can be thought of as a "micro uprev."
             The many “micro uprevs” produce a kernel version with a mix of 
             important new mainline, non-mainline, BSP developments and feature integrations. 
             This kernel gives insight into new features and allows focused
@@ -142,7 +142,8 @@
     <section id='kernel-architecture'>
         <title>Kernel Architecture</title>
         <para>
-            This section describes the architecture of the Yocto Project kernel and provides information
+            This section describes the architecture of the kernels available through the 
+            Yocto Project and provides information
             on the mechanisms used to achieve that architecture.
         </para>
         
@@ -156,7 +157,7 @@
                 upstream <filename>kernel.org</filename>.
             </para>
             <para>
-                You can think of the Yocto Project kernel as consisting of a baseline kernel with
+                You can think of a Yocto Project kernel as consisting of a baseline Linux kernel with
                 added features logically structured on top of the baseline.
                 The features are tagged and organized by way of a branching strategy implemented by the 
                 source code manager (SCM) Git.
@@ -305,9 +306,9 @@
     <section id='kernel-configuration'>
         <title>Kernel Configuration</title>
         <para>
-            Kernel configuration, along with kernel features, defines how a Linux Yocto
-            kernel image is built. 
-            Through configuration settings, you can customize a Linux Yocto kernel to be
+            Kernel configuration, along with kernel features, defines how a kernel
+            image is built for the Yocto Project. 
+            Through configuration settings, you can customize a Yocto Project kernel to be
             specific to particular hardware.
             For example, you can specify sound support or networking support.
             This section describes basic concepts behind Kernel configuration within the 
@@ -316,9 +317,9 @@
         </para>
 
         <para>
-            Conceptually, Linux Yocto kernel configuration occurs similarly to that needed for any
+            Conceptually, configuration of a Yocto Project kernel occurs similarly to that needed for any
             Linux kernel.
-            The Linux Yocto kernel build process uses a <filename>.config</filename> file, which 
+            The build process for a Yocto Project kernel uses a <filename>.config</filename> file, which 
             is created through the Linux Kernel Coinfiguration (LKC) tool.
             You can directly set various configurations in the 
             <filename>.config</filename> file by using the <filename>menuconfig</filename> 
@@ -352,7 +353,7 @@
                     list of kernel options just as they would appear syntactically in the 
                     <filename>.config</filename> file.
                     Configuration fragments are typically logical groupings and are assembled
-                    by the Yocto Project build system to produce input used by the LKC
+                    by the OpenEmbedded build system to produce input used by the LKC
                     that ultimately generates the <filename>.config</filename> file.</para>
                     <para>The 
                     <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-KERNEL_FEATURES'>KERNEL_FEATURES</ulink></filename>
@@ -384,20 +385,6 @@
                     with the <filename>kernel.org</filename> history and development.</para></listitem>
             </itemizedlist>
         </para>
-<!--<para>
-WRITER NOTE: Put this in for post 1.1 if possible:
-
-The tools that construct a kernel tree will be discussed later in this 
-document. The following tools form the foundation of the Yocto Project 
-kernel toolkit:
-<itemizedlist>
-    <listitem><para>git  : distributed revision control system created by Linus Torvalds</para></listitem>
-    <listitem><para>guilt: quilt on top of git</para></listitem>
-    <listitem><para>*cfg : kernel configuration management and classification</para></listitem>
-    <listitem><para>kgit*: Yocto Project kernel tree creation and management tools</para></listitem>
-    <listitem><para>scc  : series &amp; configuration compiler</para></listitem>
-</itemizedlist>
-</para> -->
     </section> 
 </chapter>
 <!--

documentation/kernel-manual/kernel-doc-intro.xml

@@ -9,26 +9,26 @@
 <section id='book-intro'>
     <title>Introduction</title>
     <para>
-        The Yocto Project presents the kernel as a fully patched, history-clean Git
-        repository. 
-        The Git tree represents the selected features, board support,
+        The Yocto Project presents kernels as a fully patched, history-clean Git
+        repositories. 
+        Each repository represents selected features, board support,
         and configurations extensively tested by the Yocto Project. 
-        The Yocto Project kernel allows the end user to leverage community
+        Yocto Project kernels allow the end user to leverage community
         best practices to seamlessly manage the development, build and debug cycles.
     </para>
     <para>
-        This manual describes the Yocto Project kernel by providing information
-        on its history, organization, benefits, and use.
+        This manual describes Yocto Project kernels by providing information
+        on history, organization, benefits, and use.
         The manual consists of two sections:
         <itemizedlist>
-            <listitem><para><emphasis>Concepts:</emphasis> Describes concepts behind the kernel.
-                You will understand how the kernel is organized and why it is organized in 
-                the way it is.  You will understand the benefits of the kernel's organization 
+            <listitem><para><emphasis>Concepts:</emphasis> Describes concepts behind a kernel.
+                You will understand how a kernel is organized and why it is organized in 
+                the way it is.  You will understand the benefits of a kernel's organization 
                 and the mechanisms used to work with the kernel and how to apply it in your 
                 design process.</para></listitem>
-            <listitem><para><emphasis>Using the Kernel:</emphasis> Describes best practices 
+            <listitem><para><emphasis>Using a Kernel:</emphasis> Describes best practices 
                 and "how-to" information
-                that lets you put the kernel to practical use.  
+                that lets you put a kernel to practical use.  
                 Some examples are how to examine changes in a branch and how to 
                 save kernel modifications.</para></listitem>
         </itemizedlist>

documentation/kernel-manual/kernel-how-to.xml

@@ -10,7 +10,7 @@
 <section id='actions-org'>
     <title>Introduction</title>
     <para>
-        This chapter describes how to accomplish tasks involving the kernel's tree structure. 
+        This chapter describes how to accomplish tasks involving a kernel's tree structure. 
         The information is designed to help the developer that wants to modify the Yocto 
         Project kernel and contribute changes upstream to the Yocto Project.
         The information covers the following:
@@ -25,7 +25,7 @@
     <section id='tree-construction'>
         <title>Tree Construction</title>
         <para>
-            This section describes construction of the Yocto Project kernel repositories 
+            This section describes construction of the Yocto Project kernel source repositories 
             as accomplished by the Yocto Project team to create kernel repositories.
             These kernel repositories are found at
             <ulink url='&YOCTO_GIT_URL;/cgit.cgi'>&YOCTO_GIT_URL;/cgit.cgi</ulink>
@@ -34,33 +34,35 @@
             compiling and executing the set of feature descriptions for every BSP/feature
             in the product. 
             Those feature descriptions list all necessary patches,
-            configuration, branching, tagging and feature divisions found in the kernel.
+            configuration, branching, tagging and feature divisions found in a kernel.
             Thus, the Yocto Project kernel repository (or tree) is built.
         </para>
         <para>
             The existence of this tree allows you to access and clone a particular 
-            Linux Yocto kernel repository and use it to build images based on their configurations
+            Yocto Project kernel repository and use it to build images based on their configurations
             and features.
         </para>
         <para>
             You can find the files used to describe all the valid features and BSPs 
-            in the Yocto Project kernel in any clone of the Linux Yocto kernel source repository Git tree.
+            in the Yocto Project kernel in any clone of the Yocto Project kernel source repository 
+            Git tree.
             For example, the following command clones the Yocto Project baseline kernel that 
-            branched off of <filename>linux.org</filename> version 3.0:
+            branched off of <filename>linux.org</filename> version 3.4:
             <literallayout class='monospaced'>
-     $ git clone git://git.yoctoproject.org/linux-yocto-3.0
+     $ git clone git://git.yoctoproject.org/linux-yocto-3.4
             </literallayout>
-            For another example of how to set up a local Git repository of the Linux Yocto 
+            For another example of how to set up a local Git repository of the Yocto Project
             kernel files, see the 
-            "<ulink url='&YOCTO_DOCS_DEV_URL;#local-kernel-files'>Linux Yocto Kernel</ulink>" bulleted item in The Yocto Project Development Manual.
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#local-kernel-files'>Linux Yocto Kernel</ulink>" bulleted 
+            item in The Yocto Project Development Manual.
         </para>
         <para>  
             Once you have cloned the kernel Git repository on your local machine, you can 
             switch to the <filename>meta</filename> branch within the repository.
             Here is an example that assumes the local Git repository for the kernel is in 
-            a top-level directory named <filename>linux-yocto-3.0</filename>:
+            a top-level directory named <filename>linux-yocto-3.4</filename>:
             <literallayout class='monospaced'>
-     $ cd ~/linux-yocto-3.0
+     $ 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,
@@ -85,7 +87,7 @@
         </para>
         <para>
             The following steps describe what happens when the Yocto Project Team constructs
-            the Yocto Linux kernel source Git repository (or tree) found at 
+            the Yocto Project kernel source Git repository (or tree) found at 
             <ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink> given the 
             introduction of a new top-level kernel feature or BSP. 
             These are the actions that effectively create the tree 
@@ -130,7 +132,7 @@
         </para>
         <para>
             The kernel tree is now ready for developer consumption to be locally cloned,
-            configured, and built into a Linux Yocto kernel specific to some target hardware. 
+            configured, and built into a Yocto Project kernel specific to some target hardware. 
             <note><para>The generated <filename>meta-*</filename> directories add to the kernel 
                 as shipped with the Yocto Project release. 
                 Any add-ons and configuration data are applied to the end of an existing branch. 
@@ -149,7 +151,7 @@
     <section id='build-strategy'>
         <title>Build Strategy</title>
         <para>
-            Once a local Git repository of the Linux Yocto kernel exists on a development system, 
+            Once a local Git repository of the Yocto Project kernel exists on a development system, 
             you can consider the compilation phase of kernel development - building a kernel image.
             Some prerequisites exist that are validated by the build process before compilation
             starts:
@@ -166,7 +168,7 @@
         </itemizedlist>
 
         <para>
-            The Yocto Project makes sure these conditions exist before attempting compilation.
+            The OpenEmbedded build system makes sure these conditions exist before attempting compilation.
             Other means, however, do exist, such as as bootstrapping a BSP, see 
             the "<link linkend='workflow-examples'>Workflow Examples</link>".
         </para>
@@ -308,32 +310,35 @@
                 <title>Show a Particular Feature or Branch Change</title>
 
                 <para>
-                    Significant features or branches are tagged in the Yocto Project tree to divide
-                    changes. 
-                    Remember to first determine (or add) the tag of interest.  
+                    Developers use tags in the Yocto Project kernel tree to divide changes for significant 
+                    features or branches. 
+                    Once you know a particular tag, you can use Git commands 
+                    to show changes associated with the tag and find the branches that contain
+                    the feature.  
                     <note>
                         Because BSP branch, <filename>kernel.org</filename>, and feature tags are all 
                         present, there could be many tags.
                     </note>
+                    The <filename>git show &lt;tag&gt;</filename> command shows changes that are tagged by 
+                    a feature.
+                    Here is an example that shows changes tagged by the <filename>systemtap</filename>
+                    feature:
                     <literallayout class='monospaced'>
-     # show the changes tagged by a feature
-     &gt; git show &lt;tag&gt; 
-        &gt; eg: git show yaffs2
-
-     # determine which branches contain a feature
-     &gt; git branch --contains &lt;tag&gt;
-
-     # show the changes in a kernel type
-     &gt; git whatchanged yocto/base..&lt;kernel type&gt;
-        &gt; eg: git whatchanged yocto/base..yocto/standard/base
+     $ git show systemtap
+                    </literallayout>
+                    You can use the <filename>git branch --contains &lt;tag&gt;</filename> command
+                    to show the branches that contain a particular feature.
+                    This command shows the branches that contain the <filename>systemtap</filename>
+                    feature:
+                    <literallayout class='monospaced'>
+     $ git branch --contains systemtap
                     </literallayout>
                 </para>
 
                 <para>
-                    You can use many other comparisons to isolate BSP changes.
+                    You can use many other comparisons to isolate BSP and kernel changes.
                     For example, you can compare against <filename>kernel.org</filename> tags 
-                    (e.g. v2.6.27.18, etc), or
-                    you can compare against subsystems (e.g. <filename>git whatchanged mm</filename>).
+                    such as the <filename>v3.4</filename> tag.
                 </para>
             </section>
         </section>
@@ -520,7 +525,7 @@
                     "permanent" and you should not modify them.
                     If the commits need to be changed, you can incrementally do so with new commits.
                     These practices follow standard Git workflow and the <filename>kernel.org</filename> best 
-                    practices, which Yocto Project recommends.
+                    practices, which is recommended.
                     <note>
                         It is recommended to tag or branch before adding changes to a Yocto Project
                         BSP or before creating a new one.
@@ -598,9 +603,9 @@
                     <para>
                         For example, the following command pushes the changes from your local branch
                         <filename>yocto/standard/common-pc/base</filename> to the remote branch with the same name 
-                        in the master repository <filename>//git.mycompany.com/pub/git/kernel-3.0</filename>.
+                        in the master repository <filename>//git.mycompany.com/pub/git/kernel-3.4</filename>.
                         <literallayout class='monospaced'>
-     &gt; git push ssh://git.mycompany.com/pub/git/kernel-3.0 \
+     &gt; git push ssh://git.mycompany.com/pub/git/kernel-3.4 \
         yocto/standard/common-pc/base:yocto/standard/common-pc/base
                         </literallayout>
                     </para>
@@ -688,7 +693,7 @@
                     However, if the patches are manually applied to a secondary tree and then 
                     that tree is checked into the SCM, you can lose change information such as 
                     commit logs.
-                    The Yocto Project does not recommend this process.
+                    This process is not recommended.
                 </para>
 
                 <para>
@@ -705,14 +710,14 @@
             <para>
                 This section describes kernel development in an SCM other than Git, 
                 which is not the same as exporting changes to another SCM described earlier.
-                For this scenario, you use the Yocto Project build system to 
+                For this scenario, you use the OpenEmbedded build system to 
                 develop the kernel in a different SCM.
                 The following must be true for you to accomplish this:
                 <itemizedlist>
                     <listitem><para>The delivered Yocto Project kernel must be exported into the second
                         SCM.</para></listitem>
                     <listitem><para>Development must be exported from that secondary SCM into a 
-                        format that can be used by the Yocto Project build system.</para></listitem>
+                        format that can be used by the OpenEmbedded build system.</para></listitem>
                 </itemizedlist>
             </para>
 
@@ -788,9 +793,10 @@
             <para>
                 The basic steps you need to follow are:
                 <orderedlist>
-                    <listitem><para><emphasis>Make sure you have the Yocto Project source tree available:</emphasis>
-                        You should either create a Yocto Project Git repository (recommended), or 
-                        you should get the Yocto Project release tarball and extract it.</para></listitem>
+                    <listitem><para><emphasis>Make sure you have set up a local source directory:</emphasis>
+                        You must create a local <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source
+                        directory</ulink> by either creating a Git repository (recommended) or 
+                        extracting a Yocto Project release tarball.</para></listitem>
                     <listitem><para><emphasis>Choose an existing BSP available with the Yocto Project:</emphasis>
                         Try to map your board features as closely to the features of a BSP that is  
                         already supported and exists in the Yocto Project.  
@@ -800,12 +806,12 @@
                         on the Yocto Project's Download page at 
                         <ulink url='&YOCTO_HOME_URL;/download'></ulink>.</para></listitem>
                     <listitem><para><emphasis>Be sure you have the Base BSP:</emphasis>
-                        You need to either have the Yocto Project Git repository set up or download
-                        the tarball of the base BSP.
+                        You need to either have a local Git repository of the base BSP set up or 
+                        have downloaded and extracted the files from a release BSP tarball.
                         Either method gives you access to the BSP source files.</para></listitem>
                     <listitem><para><emphasis>Make a copy of the existing BSP, thus isolating your new 
                         BSP work:</emphasis>
-                        Copying the existing BSP structure gives you a new area in which to work.</para></listitem>
+                        Copying the existing BSP file structure gives you a new area in which to work.</para></listitem>
                     <listitem><para><emphasis>Make configuration and recipe changes to your new BSP:</emphasis>
                         Configuration changes involve the files in the BSP's <filename>conf</filename>
                         directory. 
@@ -821,7 +827,7 @@
                         changes to the <filename>local.conf</filename> and <filename>bblayers.conf</filename>
                         files.</para></listitem>
                     <listitem><para><emphasis>Build the image:</emphasis>
-                        The Yocto Project uses the BitBake tool to create the image. 
+                        The OpenEmbedded build system uses BitBake to create the image. 
                         You need to decide on the type of image you are going to build (e.g. minimal, base, 
                         core, sato, and so forth) and then start the build using the <filename>bitbake</filename>
                         command.</para></listitem>

documentation/kernel-manual/kernel-manual.xml

@@ -51,8 +51,13 @@
             </revision>
             <revision>
                 <revnumber>1.2</revnumber>
-                <date>TBD 2012</date>
-                <revremark>Work in progress for the Yocto Project 1.2 Release.</revremark>
+                <date>April 2012</date>
+                <revremark>Released with the Yocto Project 1.2 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.3</revnumber>
+                <date>Sometime in 2012</date>
+                <revremark>Released with the Yocto Project 1.3 Release.</revremark>
             </revision>
         </revhistory>
 

documentation/poky-ref-manual/development.xml

@@ -10,210 +10,11 @@
     <para>
         The Yocto Project supports several methods of application development through which 
         you can create user-space software designed to run on an embedded device that uses
-        a Linux Yocto image developed with the Yocto Project. 
+        a Yocto Project image, which was developed with the OpenEmbedded build system. 
         This flexibility allows you to choose the method that works best for you.  
         This chapter describes each development method.
     </para>
 
-        <section id="platdev-appdev-external-sdk">
-        <title>External Development Using the Meta-Toolchain</title>
-        <para>
-            The Yocto Project provides toolchains that allow you to develop your application 
-            outside of the Yocto Project build system for specific hardware.
-            These toolchains (called meta-toolchains) contain cross-development tools such as compilers, 
-            linkers, and debuggers that build your application for your target device.
-            The Yocto Project also provides images that have toolchains for supported 
-            architectures included within the image.
-            This allows you to compile, debug, or profile applications directly on the target device.
-            See the 
-            "<link linkend='ref-images'>Reference: Images</link>" appendix for a listing of the image
-            types that Yocto Project supports.
-        </para> 
-        <para>
-            Using the BitBake tool you can build a meta-toolchain or meta-toolchain-sdk target,
-            which generates a tarball. 
-            Unpacking  this tarball into the <filename class="directory">/opt/poky</filename> directory 
-            on your host produces a setup script 
-            (e.g. <filename>/opt/poky/environment-setup-i586-poky-linux</filename>) that 
-            you can <filename>source</filename> to initialize your build environment. 
-            Sourcing this script adds the compiler, QEMU scripts, QEMU binary, a special version of 
-            <filename>pkgconfig</filename> and other 
-            useful utilities to the <filename>PATH</filename> variable used by the Yocto Project
-            build environment. 
-            Variables to assist <filename>pkgconfig</filename> and 
-            Autotools are also defined so that, for example, <filename>configure</filename>
-            can find pre-generated test results for tests that need target hardware on which to run.
-        </para>
-        <para>
-            Using the toolchain with Autotool-enabled packages is straightforward - just pass the 
-            appropriate <filename>host</filename> option to <filename>configure</filename>. 
-            Following is an example:
-            <literallayout class='monospaced'>
-     $ ./configure --host=arm-poky-linux-gnueabi
-            </literallayout>
-            For projects that are not Autotool-enabled, it is usually just a case of ensuring 
-            you point to and use the cross-toolchain.
-            For example, the following two lines of code in a <filename>Makefile</filename>
-            that builds your application
-            specify to use the cross-compiler <filename>arm-poky-linux-gnueabi-gcc</filename>
-            and linker <filename>arm-poky-linux-gnueabi-ld</filename>, which are part of the 
-            meta-toolchain you would have previously established:
-            <literallayout class='monospaced'>
-     CC=arm-poky-linux-gnueabi-gcc;
-     LD=arm-poky-linux-gnueabi-ld;
-            </literallayout>
-        </para>
-        </section>
-
-        <section id="using-the-eclipse-and-anjuta-plug-ins">
-        <title>External Development Using the Eclipse Plug-in</title>
-        <para>
-            The current release of the Yocto Project supports the Eclipse IDE plug-in
-            to make developing software easier for the application developer. 
-            The plug-in provides capability extensions to the graphical IDE to allow
-            for cross compilation, deployment and execution of the application within a QEMU 
-            emulation session. 
-            Support of the Eclipse plug-in also allows for cross debugging and
-            profiling.  
-            Additionally, the Eclipse plug-in provides a suite of tools 
-            that allows the developer to perform remote profiling, tracing, collection of 
-            power consumption data, collection of latency data and collection of performance data.
-        </para>
-        <note>
-            The current release of the Yocto Project no longer supports the Anjuta plug-in.
-            However, the Poky Anjuta Plug-in is available to download directly from the Poky 
-            Git repository located through the web interface at
-            <ulink url='&YOCTO_GIT_URL;'></ulink> under IDE Plugins.
-            The community is free to continue supporting it beyond the Yocto Project 0.9
-            Release.            
-        </note>
-        <para>
-            To use the Eclipse plug-in you need the Eclipse Framework (Helios 3.6.1) along 
-            with other plug-ins installed into the Eclipse IDE.
-            Once you have your environment setup you need to configure the Eclipse plug-in.
-            For information on how to install and configure the Eclipse plug-in, see the
-            "<ulink url='&YOCTO_DOCS_ADT_URL;#adt-eclipse'>Working Within Eclipse</ulink>"
-            chapter in the Yocto Project Application Development Toolkit (ADT) User's Guide.
-         </para>
-         </section>
-
-        <section id="platdev-appdev-qemu">
-        <title>External Development Using the QEMU Emulator</title>
-        <para>
-            Running Poky QEMU images is covered in the 
-            "<ulink url='&YOCTO_DOCS_QS_URL;#test-run'>A Quick Test Run</ulink>"
-            section of the Yocto Project Quick Start.
-        </para>
-        <para>
-            The QEMU images shipped with the Yocto Project contain complete toolchains
-            native to their target architectures.
-            This support allows you to develop applications within QEMU similar to the way 
-            you would using a normal host development system.
-        </para>
-
-        <para> 
-            Speed can be an issue depending on the target and host architecture mix.
-            For example, using the <filename>qemux86</filename> image in the emulator 
-            on an Intel-based 32-bit (x86) host machine is fast because the target and 
-            host architectures match.
-            On the other hand, using the <filename>qemuarm</filename> image on the same Intel-based
-            host can be slower.
-            But, you still achieve faithful emulation of ARM-specific issues. 
-        </para>
-
-        <para>
-            To speed things up, the QEMU images support using <filename>distcc</filename>
-            to call a cross-compiler outside the emulated system. 
-            If you used <filename>runqemu</filename> to start QEMU, and 
-            <filename>distccd</filename> is present on the host system, any BitBake cross-compiling 
-            toolchain available from the build system is automatically
-            used from within QEMU simply by calling <filename>distcc</filename>.
-            You can accomplish this by defining the cross-compiler variable 
-            (e.g. <filename>export CC="distcc"</filename>).
-            Alternatively, if a suitable SDK/toolchain is present in 
-            <filename>/opt/poky</filename> the toolchain is also automatically used.
-        </para>
-
-        <para>
-            Several mechanisms exist that let you connect to the system running on the 
-            QEMU emulator:
-            <itemizedlist>
-                <listitem><para>QEMU provides a framebuffer interface that makes standard 
-                    consoles available.</para></listitem>
-                <listitem><para>Generally, headless embedded devices have a serial port.
-                    If so, you can configure the operating system of the running image
-                    to use that port to run a console. 
-                    The connection uses standard IP networking.</para></listitem>
-                <listitem><para>The QEMU images have a Dropbear secure shell (ssh) server 
-                    that runs with the root password disabled.
-                    This allows you to use standard <filename>ssh</filename> and 
-                    <filename>scp</filename> commands.</para></listitem>
-                <listitem><para>The QEMU images also contain an embedded Network Files
-                    System (NFS) server that exports the image's root filesystem.
-                    This allows you to make the filesystem available to the 
-                    host.</para></listitem>
-            </itemizedlist>
-        </para>
-        </section>              
-
-        <section id="platdev-appdev-insitu">
-        <title>Development Using Yocto Project Directly</title>
-        <para>
-            Working directly with the Yocto Project is a fast and effective development technique.
-            The idea is that you can directly edit files in a working directory
-            (<filename><link linkend='var-WORKDIR'>WORKDIR</link></filename>) 
-            or the source directory (<filename><link linkend='var-S'>S</link></filename>) 
-            and then force specific tasks to rerun in order to test the changes. 
-            An example session working on the matchbox-desktop package might 
-            look like this:
-        </para>
-
-        <para>
-            <literallayout class='monospaced'>
-     $ bitbake matchbox-desktop
-     $ sh
-     $ cd tmp/work/armv5te-poky-linux-gnueabi/matchbox-desktop-2.0+svnr1708-r0/
-     $ cd matchbox-desktop-2
-     $ vi src/main.c
-           .
-           .
-      [Make your changes]
-           .
-           .
-     $ exit
-     $ bitbake matchbox-desktop -c compile -f
-     $ bitbake matchbox-desktop
-            </literallayout>
-        </para>
-
-        <para>
-            This example builds the <filename>matchbox-desktop</filename> package, 
-            creates a new terminal, changes into the work directory for the package,
-            changes a file, exits out of the terminal, and then recompiles the 
-            package. 
-            Instead of using <filename>sh</filename>,
-            you can also use two different terminals. 
-            However, the risk of using two terminals is that a command like 
-            <filename>unpack</filename> could destroy your changes in the
-            work directory.  
-            Consequently, you need to work carefully.
-        </para>
-
-        <para>
-            It is useful when making changes directly to the work directory files to do
-            so using the Quilt tool as detailed in the 
-            "<ulink url='&YOCTO_DOCS_DEV_URL;#using-a-quilt-workflow'>Using a Quilt Workflow</ulink>" section in the Yocto Project Development Manual. 
-            Using Quilt, you can copy patches into the recipe directory and use the patches directly 
-            through use of the <filename><link linkend='var-SRC_URI'>SRC_URI</link></filename> variable.
-        </para>
-
-        <para>
-            For a review of the skills used in this section, see the 
-            "<link linkend='usingpoky-components-bitbake'>BitBake</link>" and 
-            "<link linkend='usingpoky-debugging-taskrunning'>Running Specific Tasks</link>" sections.
-        </para>
-        </section>
-
         <section id="platdev-appdev-devshell">
         <title>Development Within a Development Shell</title>
 
@@ -224,12 +25,12 @@
             section in that when you invoke <filename>devshell</filename> source files are 
             extracted into your working directory and patches are applied. 
             Then, a new terminal is opened and you are placed in the working directory.
-            In the new terminal all the Yocto Project build-related environment variables are 
+            In the new terminal, all the OpenEmbedded build-related environment variables are 
             still defined so you can use commands such as <filename>configure</filename> and 
             <filename>make</filename>. 
-            The commands execute just as if the Yocto Project build system were executing them. 
+            The commands execute just as if the OpenEmbedded build system were executing them. 
             Consequently, working this way can be helpful when debugging a build or preparing 
-            software to be used with the Yocto Project build system.
+            software to be used with the OpenEmbedded build system.
         </para>
 
         <para>
@@ -244,7 +45,7 @@
         </para>
 
         <para>
-            This command opens a terminal with a shell prompt within the Poky 
+            This command opens a terminal with a shell prompt within the Yocto Project 
             environment. 
             The following occurs:
             <itemizedlist>
@@ -257,7 +58,7 @@
             </itemizedlist>
             Within this environment, you can run <filename>configure</filename>
             or <filename>compile</filename> commands as if they were being run by 
-            the Yocto Project build system itself.
+            the OpenEmbedded build system itself.
             As noted earlier, the working directory also automatically changes to the 
             source directory (<filename><link linkend='var-S'>S</link></filename>).
         </para>
@@ -270,8 +71,8 @@
             The default shell used by <filename>devshell</filename> is xterm. 
             For examples of available options, see the "UI/Interaction Configuration"
             section of the  
-            <filename>meta/conf/bitbake.conf</filename> configuration file in the Yocto Project
-            files. 
+            <filename>meta/conf/bitbake.conf</filename> configuration file in the 
+            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>. 
         </para>
 
         <para>
@@ -298,7 +99,7 @@
 
         <para>
             If you're working on a recipe that pulls from an external Source Code Manager (SCM), it 
-            is possible to have the Yocto Project build system notice new changes added to the 
+            is possible to have the OpenEmbedded build system notice new changes added to the 
             SCM and then build the package that depends on them using the latest version. 
             This only works for SCMs from which it is possible to get a sensible revision number for changes.
             Currently, you can do this with Apache Subversion (SVN), Git, and Bazaar (BZR) repositories.
@@ -306,7 +107,8 @@
 
         <para>
             To enable this behavior, simply add the following to the <filename>local.conf</filename>
-            configuration file in the build directory of the Yocto Project files:
+            configuration file found in the 
+            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>:
             <literallayout class='monospaced'>
      SRCREV_pn-&lt;PN&gt; = "${AUTOREV}"
             </literallayout>
@@ -316,487 +118,6 @@
         </para>
         </section>
     </section>
-
-<section id="platdev-gdb-remotedebug">
-    <title>Debugging With the GNU Project Debugger (GDB) Remotely</title>
-
-    <para>
-        GDB allows you to examine running programs, which in turn help you to understand and fix problems. 
-        It also allows you to perform post-mortem style analysis of program crashes. 
-        GDB is available as a package within the Yocto Project and by default is 
-        installed in sdk images.
-        See the "<link linkend='ref-images'>Reference: Images</link>" appendix for a description of these
-        images. 
-        You can find information on GDB at <ulink url="http://sourceware.org/gdb/"/>.
-    </para>
-
-    <tip>
-        For best results, install <filename>-dbg</filename> packages for the applications 
-        you are going to debug.
-        Doing so makes available extra debug symbols that give you more meaningful output.
-    </tip>
-
-    <para>
-        Sometimes, due to memory or disk space constraints, it is not possible
-        to use GDB directly on the remote target to debug applications. 
-        These constraints arise because GDB needs to load the debugging information and the 
-        binaries of the process being debugged. 
-        Additionally, GDB needs to perform many computations to locate information such as function 
-        names, variable names and values, stack traces and so forth - even before starting the 
-        debugging process. 
-        These extra computations place more load on the target system and can alter the
-        characteristics of the program being debugged.
-    </para>
-
-    <para>
-        To help get past the previously mentioned constraints, you can use Gdbserver.
-        Gdbserver runs on the remote target and does not load any debugging information 
-        from the debugged process.
-        Instead, a GDB instance processes the debugging information that is run on a 
-        remote computer - the host GDB. 
-        The host GDB then sends control commands to Gdbserver to make it stop or start the debugged 
-        program, as well as read or write memory regions of that debugged program. 
-        All the debugging information loaded and processed as well
-        as all the heavy debugging is done by the host GDB.
-        Offloading these processes gives the Gdbserver running on the target a chance to remain 
-        small and fast.
-    </para>
-
-    <para>
-        Because the host GDB is responsible for loading the debugging information and 
-        for doing the necessary processing to make actual debugging happen, the 
-        user has to make sure the host can access the unstripped binaries complete
-        with their debugging information and also be sure the target is compiled with no optimizations. 
-        The host GDB must also have local access to all the libraries used by the 
-        debugged program. 
-        Because Gdbserver does not need any local debugging information, the binaries on
-        the remote target can remain stripped. 
-        However, the binaries must also be compiled without optimization 
-        so they match the host's binaries.
-    </para>
-
-    <para>
-        To remain consistent with GDB documentation and terminology, the binary being debugged 
-        on the remote target machine is referred to as the "inferior" binary.
-        For documentation on GDB see the  
-        <ulink url="http://sourceware.org/gdb/documentation/">GDB site</ulink>.
-    </para>
-
-    <section id="platdev-gdb-remotedebug-launch-gdbserver">
-        <title>Launching Gdbserver on the Target</title>
-
-        <para>
-            First, make sure Gdbserver is installed on the target. 
-            If it is not, install the package <filename>gdbserver</filename>, which needs the 
-            <filename>libthread-db1</filename> package.
-        </para>
-
-        <para>
-            As an example, to launch Gdbserver on the target and make it ready to "debug" a 
-            program located at <filename>/path/to/inferior</filename>, connect
-            to the target and launch:
-            <literallayout class='monospaced'>
-     $ gdbserver localhost:2345 /path/to/inferior
-            </literallayout>
-            Gdbserver should now be listening on port 2345 for debugging
-            commands coming from a remote GDB process that is running on the host computer.
-            Communication between Gdbserver and the host GDB are done using TCP. 
-            To use other communication protocols, please refer to the  
-            <ulink url='http://www.gnu.org/software/gdb/'>Gdbserver documentation</ulink>.
-        </para>
-    </section>
-
-    <section id="platdev-gdb-remotedebug-launch-gdb">
-        <title>Launching GDB on the Host Computer</title>
-
-        <para>
-            Running GDB on the host computer takes a number of stages.
-            This section describes those stages.
-        </para>
-
-        <section id="platdev-gdb-remotedebug-launch-gdb-buildcross">
-            <title>Building the Cross-GDB Package</title>
-            <para>
-                A suitable GDB cross-binary is required that runs on your host computer but
-                also knows about the the ABI of the remote target. 
-                You can get this binary from the the Yocto Project meta-toolchain.
-                Here is an example:
-                <literallayout class='monospaced'> 
-     /usr/local/poky/eabi-glibc/arm/bin/arm-poky-linux-gnueabi-gdb
-                </literallayout> 
-                where <filename>arm</filename> is the target architecture and 
-                <filename>linux-gnueabi</filename> the target ABI.
-            </para>
-
-            <para>
-                Alternatively, the Yocto Project can build the <filename>gdb-cross</filename> binary. 
-                Here is an example:
-                <literallayout class='monospaced'>
-     $ bitbake gdb-cross
-                </literallayout>
-                Once the binary is built, you can find it here: 
-                <literallayout class='monospaced'>
-     tmp/sysroots/&lt;host-arch&gt;/usr/bin/&lt;target-abi&gt;-gdb 
-                </literallayout>
-            </para>
-        </section>
-
-        <section id="platdev-gdb-remotedebug-launch-gdb-inferiorbins">
-            <title>Making the Inferior Binaries Available</title>
-
-            <para>
-                The inferior binary (complete with all debugging symbols) as well as any
-                libraries (and their debugging symbols) on which the inferior binary depends
-                need to be available.
-                There are a number of ways you can make these available.
-            </para>
-
-            <para>
-                Perhaps the easiest way is to have an 'sdk' image that corresponds to the plain
-                image installed on the device. 
-                In the case of <filename>core-image-sato</filename>, 
-                <filename>core-image-sdk</filename> would contain suitable symbols. 
-                Because the sdk images already have the debugging symbols installed, it is just a 
-                question of expanding the archive to some location and then informing GDB. 
-            </para>
-
-            <para>
-                Alternatively, Yocto Project can build a custom directory of files for a specific 
-                debugging purpose by reusing its <filename>tmp/rootfs</filename> directory.
-                This directory contains the contents of the last built image. 
-                This process assumes two things:
-                <itemizedlist>
-                    <listitem><para>The image running on the target was the last image to 
-                    be built by the Yocto Project.</para></listitem>
-                    <listitem><para>The package (<filename>foo</filename> in the following 
-                    example) that contains the inferior binary to be debugged has been built 
-                    without optimization and has debugging information available.</para></listitem>
-                </itemizedlist>
-            </para>
-
-            <para>
-                The following steps show how to build the custom directory of files:
-                <orderedlist>
-                    <listitem><para>Install the package (<filename>foo</filename> in this case) to 
-                        <filename>tmp/rootfs</filename>:
-                        <literallayout class='monospaced'>
-     $ tmp/sysroots/i686-linux/usr/bin/opkg-cl -f \
-     tmp/work/&lt;target-abi&gt;/core-image-sato-1.0-r0/temp/opkg.conf -o \
-     tmp/rootfs/ update
-                        </literallayout></para></listitem>
-                    <listitem><para>Install the debugging information:
-                        <literallayout class='monospaced'>
-     $ tmp/sysroots/i686-linux/usr/bin/opkg-cl -f \
-     tmp/work/&lt;target-abi&gt;/core-image-sato-1.0-r0/temp/opkg.conf \
-     -o tmp/rootfs install foo
-
-     $ tmp/sysroots/i686-linux/usr/bin/opkg-cl -f \
-     tmp/work/&lt;target-abi&gt;/core-image-sato-1.0-r0/temp/opkg.conf \
-     -o tmp/rootfs install foo-dbg
-                        </literallayout></para></listitem>
-                </orderedlist>
-            </para>
-        </section>
-
-        <section id="platdev-gdb-remotedebug-launch-gdb-launchhost">
-            <title>Launch the Host GDB</title>
-
-            <para>
-                To launch the host GDB, you run the <filename>cross-gdb</filename> binary and provide 
-                the inferior binary as part of the command line.  
-                For example, the following command form continues with the example used in 
-                the previous section.  
-                This command form loads the <filename>foo</filename> binary
-                as well as the debugging information:
-                <literallayout class='monospaced'>
-     $ &lt;target-abi&gt;-gdb rootfs/usr/bin/foo
-                </literallayout>
-                Once the GDB prompt appears, you must instruct GDB to load all the libraries
-                of the inferior binary from <filename>tmp/rootfs</filename> as follows:
-                <literallayout class='monospaced'>
-     $ set solib-absolute-prefix /path/to/tmp/rootfs
-                </literallayout>
-                The pathname <filename>/path/to/tmp/rootfs</filename> must either be
-                the absolute path to <filename>tmp/rootfs</filename> or the location at which 
-                binaries with debugging information reside.
-            </para>
-
-            <para>
-                At this point you can have GDB connect to the Gdbserver that is running 
-                on the remote target by using the following command form:
-                <literallayout class='monospaced'>
-     $ target remote remote-target-ip-address:2345
-                </literallayout>
-                The <filename>remote-target-ip-address</filename> is the IP address of the
-                remote target where the Gdbserver is running. 
-                Port 2345 is the port on which the GDBSERVER is running.
-            </para>
-        </section>
-
-        <section id="platdev-gdb-remotedebug-launch-gdb-using">
-            <title>Using the Debugger</title>
-
-            <para>
-                You can now proceed with debugging as normal - as if you were debugging
-                on the local machine.
-                For example, to instruct GDB to break in the "main" function and then 
-                continue with execution of the inferior binary use the following commands
-                from within GDB:
-                <literallayout class='monospaced'>
-     (gdb) break main
-     (gdb) continue
-                </literallayout>
-            </para>
-
-            <para>
-                For more information about using GDB, see the project's online documentation at 
-                <ulink url="http://sourceware.org/gdb/download/onlinedocs/"/>.
-            </para>
-        </section>
-    </section>
-</section>
-
-<section id="platdev-oprofile">
-    <title>Profiling with OProfile</title>
-
-    <para>
-        <ulink url="http://oprofile.sourceforge.net/">OProfile</ulink> is a 
-        statistical profiler well suited for finding performance 
-        bottlenecks in both userspace software and in the kernel. 
-        This profiler provides answers to questions like "Which functions does my application spend 
-        the most time in when doing X?" 
-        Because the Yocto Project is well integrated with OProfile, it makes profiling applications on target 
-        hardware straightforward.
-    </para>
-
-    <para>
-        To use OProfile, you need an image that has OProfile installed. 
-        The easiest way to do this is with <filename>tools-profile</filename> in the
-        <filename><link linkend='var-IMAGE_FEATURES'>IMAGE_FEATURES</link></filename> variable. 
-        You also need debugging symbols to be available on the system where the analysis 
-        takes place. 
-        You can gain access to the symbols by using <filename>dbg-pkgs</filename> in the
-        <filename>IMAGE_FEATURES</filename> variable or by
-        installing the appropriate <filename>-dbg</filename> packages. 
-    </para>
-
-    <para>
-        For successful call graph analysis, the binaries must preserve the frame 
-        pointer register and should also be compiled with the 
-        <filename>-fno-omit-framepointer</filename> flag. 
-        In the Yocto Project you can achieve this by setting the 
-        <filename><link linkend='var-SELECTED_OPTIMIZATION'>SELECTED_OPTIMIZATION
-        </link></filename> variable to 
-        <filename>-fexpensive-optimizations -fno-omit-framepointer -frename-registers -O2</filename>. 
-        You can also achieve it by setting the
-        <filename><link linkend='var-DEBUG_BUILD'>DEBUG_BUILD</link></filename> variable to "1" in 
-        the <filename>local.conf</filename> configuration file.
-        If you use the <filename>DEBUG_BUILD</filename> variable you will also add extra debug information 
-        that can make the debug packages large.
-    </para>
-
-    <section id="platdev-oprofile-target">
-        <title>Profiling on the Target</title>
-
-        <para>
-            Using OProfile you can perform all the profiling work on the target device. 
-            A simple OProfile session might look like the following:
-        </para>
-
-        <para>
-            <literallayout class='monospaced'>
-     # opcontrol --reset
-     # opcontrol --start --separate=lib --no-vmlinux -c 5
-              .
-              .
-        [do whatever is being profiled]
-              .
-              .
-     # opcontrol --stop
-     $ opreport -cl
-            </literallayout>
-        </para>
-
-        <para>
-            In this example, the <filename>reset</filename> command clears any previously profiled data.
-            The next command starts OProfile.
-            The options used when starting the profiler separate dynamic library data 
-            within applications, disable kernel profiling, and enable callgraphing up to
-            five levels deep.
-            <note>
-                To profile the kernel, you would specify the 
-                <filename>--vmlinux=/path/to/vmlinux</filename> option.
-                The <filename>vmlinux</filename> file is usually in the Yocto Project file's 
-                <filename>/boot/</filename> directory and must match the running kernel.
-            </note>
-        </para>
-
-        <para> 
-            After you perform your profiling tasks, the next command stops the profiler. 
-            After that, you can view results with the <filename>opreport</filename> command with options
-            to see the separate library symbols and callgraph information.
-        </para>
-
-        <para>
-            Callgraphing logs information about time spent in functions and about a function's
-            calling function (parent) and called functions (children).
-            The higher the callgraphing depth, the more accurate the results.  
-            However, higher depths also increase the logging overhead.
-            Consequently, you should take care when setting the callgraphing depth. 
-            <note>
-                On ARM, binaries need to have the frame pointer enabled for callgraphing to work.
-                To accomplish this use the <filename>-fno-omit-framepointer</filename> option 
-                with <filename>gcc</filename>.
-            </note>
-        </para>
-
-        <para>
-            For more information on using OProfile, see the OProfile 
-            online documentation at 
-            <ulink url="http://oprofile.sourceforge.net/docs/"/>.
-        </para>
-    </section>
-
-    <section id="platdev-oprofile-oprofileui">
-        <title>Using OProfileUI</title>
-
-        <para>
-            A graphical user interface for OProfile is also available. 
-            You can download and build this interface from the Yocto Project at
-            <ulink url="&YOCTO_GIT_URL;/cgit.cgi/oprofileui/"></ulink>. 
-            If the "tools-profile" image feature is selected, all necessary binaries
-            are installed onto the target device for OProfileUI interaction.
-        </para>
-
-        <para>
-            Even though the Yocto Project usually includes all needed patches on the target device, you 
-            might find you need other OProfile patches for recent OProfileUI features.
-            If so, see the <ulink url='&YOCTO_GIT_URL;/cgit.cgi/oprofileui/tree/README'>
-            OProfileUI README</ulink> for the most recent information.
-        </para>
-
-        <section id="platdev-oprofile-oprofileui-online">
-            <title>Online Mode</title>
-
-            <para>
-                Using OProfile in online mode assumes a working network connection with the target 
-                hardware. 
-                With this connection, you just need to run "oprofile-server" on the device. 
-                By default, OProfile listens on port 4224. 
-                <note>
-                    You can change the port using the <filename>--port</filename> command-line 
-                    option.
-                </note>
-            </para>
-
-            <para>
-                The client program is called <filename>oprofile-viewer</filename> and its UI is relatively 
-                straightforward.
-                You access key functionality through the buttons on the toolbar, which
-                are duplicated in the menus.
-                Here are the buttons:
-                <itemizedlist>
-                    <listitem><para><emphasis>Connect:</emphasis> Connects to the remote host.
-                        You can also supply the IP address or hostname.</para></listitem>
-                    <listitem><para><emphasis>Disconnect:</emphasis> Disconnects from the target.
-                        </para></listitem>
-                    <listitem><para><emphasis>Start:</emphasis> Starts profiling on the device.
-                        </para></listitem>
-                    <listitem><para><emphasis>Stop:</emphasis> Stops profiling on the device and 
-                        downloads the data to the local host. 
-                        Stopping the profiler generates the profile and displays it in the viewer.
-                        </para></listitem>
-                    <listitem><para><emphasis>Download:</emphasis> Downloads the data from the 
-                        target and generates the profile, which appears in the viewer.</para></listitem>
-                    <listitem><para><emphasis>Reset:</emphasis> Resets the sample data on the device. 
-                        Resetting the data removes sample information collected from previous
-                        sampling runs. 
-                        Be sure you reset the data if you do not want to include old sample information.
-                        </para></listitem>
-                    <listitem><para><emphasis>Save:</emphasis> Saves the data downloaded from the
-                        target to another directory for later examination.</para></listitem>
-                    <listitem><para><emphasis>Open:</emphasis> Loads previously saved data.
-                        </para></listitem>
-                </itemizedlist>
-            </para>
-
-            <para>
-                The client downloads the complete 'profile archive' from
-                the target to the host for processing. 
-                This archive is a directory that contains the sample data, the object files, 
-                and the debug information for the object files. 
-                The archive is then converted using the <filename>oparchconv</filename> script, which is 
-                included in this distribution.
-                The script uses <filename>opimport</filename> to convert the archive from
-                the target to something that can be processed on the host.
-            </para>
-
-            <para>
-                Downloaded archives reside in the Yocto Project's build directory in 
-                <filename>/tmp</filename> and are cleared up when they are no longer in use.
-            </para>
-
-            <para>
-                If you wish to perform kernel profiling, you need to be sure 
-                a <filename>vmlinux</filename> file that matches the running kernel is available. 
-                In the Yocto Project, that file is usually located in 
-                <filename>/boot/vmlinux-KERNELVERSION</filename>, where 
-                <filename>KERNEL-version</filename> is the version of the kernel. 
-                The Yocto Project generates separate <filename>vmlinux</filename> packages for each kernel
-                it builds.
-                Thus, it should just be a question of making sure a matching package is 
-                installed (e.g. <filename>opkg install kernel-vmlinux</filename>. 
-                The files are automatically installed into development and profiling images 
-                alongside OProfile. 
-                A configuration option exists within the OProfileUI settings page that you can use to 
-                enter the location of the <filename>vmlinux</filename> file. 
-            </para>
-
-            <para>
-                Waiting for debug symbols to transfer from the device can be slow, and it
-                is not always necessary to actually have them on the device for OProfile use. 
-                All that is needed is a copy of the filesystem with the debug symbols present 
-                on the viewer system. 
-                The "<link linkend='platdev-gdb-remotedebug-launch-gdb'>Launching GDB on the Host Computer</link>"
-                section covers how to create such a directory with 
-                the Yocto Project and how to use the OProfileUI Settings dialog to specify the location.
-                If you specify the directory, it will be used when the file checksums 
-                match those on the system you are profiling.
-            </para>
-        </section>
-
-        <section id="platdev-oprofile-oprofileui-offline">
-            <title>Offline Mode</title>
-
-            <para>
-                If network access to the target is unavailable, you can generate
-                an archive for processing in <filename>oprofile-viewer</filename> as follows:
-                <literallayout class='monospaced'>
-     # opcontrol --reset
-     # opcontrol --start --separate=lib --no-vmlinux -c 5
-            .
-            .
-     [do whatever is being profiled]
-            .
-            .
-     # opcontrol --stop
-     # oparchive -o my_archive
-                </literallayout>
-            </para>
-
-            <para>
-                In the above example, <filename>my_archive</filename> is the name of the 
-                archive directory where you would like the profile archive to be kept. 
-                After the directory is created, you can copy it to another host and load it
-                using <filename>oprofile-viewer</filename> open functionality.
-                If necessary, the archive is converted.
-            </para>
-        </section>
-    </section>
-</section>
-
-
-
 </chapter> 
 <!-- 
 vim: expandtab tw=80 ts=4 

documentation/poky-ref-manual/faq.xml

@@ -13,11 +13,17 @@
         </question>
         <answer>
             <para>
-                Poky is the Yocto Project build system that was derived from <ulink 
+                The term "Poky" is sometimes used to refer to the build system that the 
+                Yocto Project uses.  
+                The build system used in the Yocto project is referred to as the 
+                OpenEmbedded build system because "Poky" was derived from <ulink 
                 url='&OE_HOME_URL;'>OpenEmbedded</ulink>.
                 Poky is a stable, smaller subset focused on the mobile environment. 
                 Development in the Yocto Project using Poky is closely tied to OpenEmbedded with 
                 features being merged regularly between the two for mutual benefit.
+                For a fuller description of the term "Poky", see the 
+                <ulink url='&YOCTO_DOCS_DEV_URL;#poky'>poky</ulink> term in the Yocto Project
+                Development Manual.
             </para>
         </answer>
     </qandaentry>
@@ -64,7 +70,8 @@
             <para>
                 There are three areas that help with stability;
                 <itemizedlist>
-                    <listitem><para>The Yocto Project team keeps Poky small and focused.
+                    <listitem><para>The Yocto Project team keeps 
+                        <ulink url='&YOCTO_DOCS_DEV_URL;#poky'>Poky</ulink> small and focused.
                         It contains around 650 packages as compared to over 5000 for full 
                         OpenEmbedded.</para></listitem>
                     <listitem><para>The Yocto Project only supports hardware that the 
@@ -100,16 +107,17 @@
     <qandaentry>
         <question>
             <para>
-                Are there any products using Poky?
+                Are there any products using the OpenEmbedded build system (poky)?
             </para>
         </question>
         <answer>
             <para>
                 The <ulink url='http://vernier.com/labquest/'>Vernier LabQuest</ulink> is using 
-                the Yocto Project build system Poky.  
+                the OpenEmbedded build system.  
                 See the <ulink url='http://www.vernier.com/products/interfaces/labq/'>Vernier LabQuest</ulink>
                 for more information.
-                There are a number of pre-production devices using Poky and the Yocto Project team
+                There are a number of pre-production devices using the OpenEmbedded build system 
+                and the Yocto Project team
                 announces them as soon as they are released.
             </para>
         </answer>
@@ -118,13 +126,13 @@
     <qandaentry>
         <question>
             <para>
-                What does the Yocto Project build system Poky produce as output?
+                What does the OpenEmbedded build system produce as output?
             </para>
         </question>
         <answer>
             <para>
                 Because the same set of recipes can be used to create output of various formats, the 
-                output of a Yocto Project build depends on how it was started. 
+                output of an OpenEmbedded build depends on how it was started. 
                 Usually, the output is a flashable image ready for the target device.
             </para>
         </answer>
@@ -155,7 +163,7 @@
         </question>
         <answer>
             <para>
-                The Yocto Project can build packages in various formats such as
+                The OpenEmbedded build system can build packages in various formats such as
                 <filename>ipk</filename> for <filename>ipkg</filename>/<filename>opkg</filename>, 
                 Debian package (<filename>.deb</filename>), or RPM. 
                 The packages can then be upgraded using the package tools on the device, much like 
@@ -223,8 +231,8 @@
             </para>
 
             <para>
-                Once these packages are installed, the Yocto Project will be able to build standard 
-                images.
+                Once these packages are installed, the OpenEmbedded build system will be able 
+                to build standard images.
                 However, there might be a problem with the QEMU emulator segfaulting. 
                 You can either disable the generation of binary locales by setting 
                 <filename><link linkend='var-ENABLE_BINARY_LOCALE_GENERATION'>ENABLE_BINARY_LOCALE_GENERATION</link>
@@ -244,14 +252,14 @@
         <answer>
             <para>
                 Nothing is wrong.
-                The Yocto Project checks any configured source mirrors before downloading 
+                The OpenEmbedded build system checks any configured source mirrors before downloading 
                 from the upstream sources. 
-                The Yocto Project does this searching for both source archives and 
+                The build system does this searching for both source archives and 
                 pre-checked out versions of SCM managed software. 
                 These checks help in large installations because it can reduce load on the SCM servers 
                 themselves. 
                 The address above is one of the default mirrors configured into the 
-                Yocto Project.
+                build system.
                 Consequently, if an upstream source disappears, the team 
                 can place sources there so builds continue to work.
             </para>
@@ -284,7 +292,7 @@
         </question>
         <answer>
             <para>
-                Most source fetching by the Yocto Project is done by <filename>wget</filename>
+                Most source fetching by the OpenEmbedded build system is done by <filename>wget</filename>
                 and you therefore need to specify the proxy settings in a 
                 <filename>.wgetrc</filename> file in your home directory. 
                 Example settings in that file would be 
@@ -350,7 +358,7 @@
                 the most likely explanation is that either the hardware you're running the 
                 build on has some problem, or, if you are running the build under virtualisation, 
                 the virtualisation probably has bugs. 
-                The Yocto Project processes a massive amount of data causing lots of network, disk and 
+                The OpenEmbedded build system processes a massive amount of data causing lots of network, disk and 
                 CPU activity and is sensitive to even single bit failures in any of these areas. 
                 True random failures have always been traced back to hardware or virtualisation issues.
             </para>
@@ -449,7 +457,7 @@
         <answer>
             <para>
                 The Yocto Project team has tried to do this before but too many of the tools 
-                the Yocto Project depends on such as <filename>autoconf</filename> 
+                the OpenEmbedded build system depends on such as <filename>autoconf</filename> 
                 break when they find spaces in pathnames.  
                 Until that situation changes, the team will not support spaces in pathnames.
             </para>
@@ -467,14 +475,16 @@
                 The toolchain configuration is very flexible and customizable.
                 It is primarily controlled with the 
                 <filename><link linkend='var-TCMODE'>TCMODE</link></filename> variable.
-                This variable controls which file to include 
-                (<filename>conf/distro/include/tcmode-*.inc</filename>).
+                This variable controls which <filename>tcmode-*.inc</filename> file to include 
+                from the <filename>meta/conf/distro/include</filename> directory within the 
+                <ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-files'>Yocto Project Files</ulink>.
             </para>
             <para>
-                The default value of <filename>TCMODE</filename> is "default".
+                The default value of <filename>TCMODE</filename> is "default"
+                (i.e. <filename>tcmode-default.inc</filename>.
                 However, other patterns are accepted.
-                In particular, "external-*" refers to external toolchains of which there are some basic examples
-                included with the core.
+                In particular, "external-*" refers to external toolchains of which there are some
+                basic examples included with the core.
                 A user can use their own custom toolchain definition in their own layer 
                 (or as defined in the <filename>local.conf</filename> file) at the location 
                 <filename>conf/distro/include/tcmode-*.inc</filename>.
@@ -493,14 +503,14 @@
     <qandaentry>
         <question>
             <para id='how-does-the-yocto-project-obtain-source-code-and-will-it-work-behind-my-firewall-or-proxy-server'>
-                How does the Yocto Project build system obtain source code and will it work behind my 
+                How does the OpenEmbedded build system obtain source code and will it work behind my 
                 firewall or proxy server?
             </para>
         </question>
         <answer>
             <para>
-                The way the Yocto Project obtains source code is highly configurable.
-                You can setup the Yocto Project to get source code in most environments if
+                The way the build system obtains source code is highly configurable.
+                You can setup the build system to get source code in most environments if
                 HTTP transport is available.
             </para>
             <para>
@@ -509,7 +519,8 @@
                 and then MIRRORS in that order.
             </para>
             <para>
-                By default, Poky uses the Yocto Project source PREMIRRORS for SCM-based sources, 
+                By default, the OpenEmbedded build system uses the Yocto Project source PREMIRRORS 
+                for SCM-based sources, 
                 upstreams for normal tarballs, and then falls back to a number of other mirrors 
                 including the Yocto Project source mirror if those fail.
             </para>
@@ -572,13 +583,40 @@
                  any network accesses to anything other than the PREMIRROR would fail.
              </para>
              <para>
-                 Poky also honors the standard shell environment variables 
+                 The build system also honors the standard shell environment variables 
                  <filename>http_proxy</filename>, <filename>ftp_proxy</filename>, 
                  <filename>https_proxy</filename>, and <filename>all_proxy</filename>
                  to redirect requests through proxy servers.
              </para>
         </answer>
     </qandaentry>
+
+    <qandaentry>
+        <question>
+            <para>
+                Can I get rid of build output so I can start over?
+            </para>
+        </question>
+        <answer>
+            <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 source the <filename>oe-init-build-env</filename>
+                setup file.
+                By default, this <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink> 
+                is named <filename>build</filename> but can be named
+                anything you want.
+            </para>
+
+            <para>
+                Within the build directory is the <filename>tmp</filename> directory. 
+                To remove all the build output yet preserve any source code or downloaded files
+                from previous builds, simply remove the <filename>tmp</filename> directory.
+            </para>
+        </answer>
+    </qandaentry>
+
+
 </qandaset>
 </appendix>
 <!-- 

documentation/poky-ref-manual/introduction.xml

@@ -12,8 +12,8 @@
         This manual provides reference information for the current release of the Yocto Project.
         The Yocto Project is an open-source collaboration project focused on embedded Linux
         developers.
-        Amongst other things, the Yocto Project uses the Poky build tool to 
-        construct complete Linux images.
+        Amongst other things, the Yocto Project uses the OpenEmbedded build system, which 
+        is based on the Poky project, to construct complete Linux images.
         You can find complete introductory and getting started information on the Yocto Project
         by reading the 
         <ulink url='&YOCTO_DOCS_QS_URL;'>   
@@ -51,9 +51,13 @@
                 the Yocto Project.</para></listitem>
             <listitem><para><emphasis>
                 <link linkend='ref-structure'>Reference: Directory Structure</link>:</emphasis> 
-                This appendix describes the directory structure of the Yocto Project files.
-                The Yocto Project files represent the file structure or Git repository created 
-                as a result of setting up the Yocto Project on your host development system.
+                This appendix describes the directory structure of the 
+                Yocto Project files, referred to as the 
+                <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>.
+                The source directory represents the local file structure created 
+                as a result from either cloning the upstream 
+                <ulink url='&YOCTO_DOCS_DEV_URL;#poky'>Poky</ulink> Git repository or unpacking a 
+                released Yocto Project tarball on your host development system.
                 </para></listitem>
             <listitem><para><emphasis>
                 <link linkend='ref-bitbake'>Reference: BitBake</link>:</emphasis> 
@@ -69,7 +73,7 @@
             <listitem><para><emphasis>
                 <link linkend='ref-features'>Reference: Features</link>:</emphasis> 
                 This appendix describes mechanisms for creating distribution, machine, and image 
-                features during the build process using the Yocto Project.</para></listitem>
+                features during the build process using the OpenEmbedded build system.</para></listitem>
             <listitem><para><emphasis>
                 <link linkend='ref-variables-glos'>Reference: Variables Glossary</link>:</emphasis> 
                 This appendix presents most Yocto Project variables.
@@ -124,9 +128,11 @@
 <section id='intro-getit-dev'>
     <title>Development Checkouts</title>
     <para>
-        Development using the Yocto Project requires a local copy of the Yocto Project files. 
-        You can get these files by downloading a Yocto Project release tarball and unpacking it,  
-        or by establishing a Git repository of the files.
+        Development using the Yocto Project requires a local copy of the Yocto Project files
+        referred to as the <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>. 
+        You can set source directory up by downloading a Yocto Project release tarball and unpacking it,  
+        or by cloning a copy of the upstream
+        <ulink url='&YOCTO_DOCS_DEV_URL;#poky'>Poky</ulink> Git repository.
         For information on both these methods, see the
         "<ulink url='&YOCTO_DOCS_DEV_URL;#getting-setup'>Getting Setup</ulink>" 
         section in The Yocto Project Development Manual.

documentation/poky-ref-manual/poky-ref-manual.xml

@@ -27,19 +27,6 @@
                 <email>richard.purdie@linuxfoundation.org</email>
             </author>
 
-<!--            <author>
-                <firstname>Tomas</firstname> <surname>Frydrych</surname>
-                <affiliation>
-                    <orgname>Intel Corporation</orgname>
-                </affiliation>
-            </author>
-
-            <author>
-                <firstname>Marcin</firstname> <surname>Juszkiewicz</surname>
-            </author>
-            <author>
-                <firstname>Dodji</firstname> <surname>Seketeli</surname>
-            </author> -->
         </authorgroup>
 
         <revhistory>
@@ -65,8 +52,13 @@
             </revision>
             <revision>
                 <revnumber>1.2</revnumber>
-                <date>TBD 2012</date>
-                <revremark>Work in progress for the Yocto Project 1.2 Release.</revremark>
+                <date>April 2012</date>
+                <revremark>Released with the Yocto Project 1.2 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.3</revnumber>
+                <date>Sometime in 2012</date>
+                <revremark>Released with the Yocto Project 1.3 Release.</revremark>
             </revision>
         </revhistory>
 

documentation/poky-ref-manual/ref-bitbake.xml

@@ -7,7 +7,8 @@
     <title>Reference: BitBake</title>
 
     <para>
-        BitBake is a program written in Python that interprets the metadata that makes up the Yocto Project. 
+        BitBake is a program written in Python that interprets the metadata used by the Yocto Project. 
+        The OpenEmbedded build system uses BitBake.
         At some point, developers wonder what actually happens when you enter:
         <literallayout class='monospaced'>
      $ bitbake core-image-sato
@@ -34,20 +35,22 @@
 
         <para>
             The first thing BitBake does is look for the <filename>bitbake.conf</filename> file.
-            The Yocto Project keeps this file in the Yocto Project file's <filename>meta/conf/</filename>
-            directory.
-            BitBake finds it by examining its <filename>BBPATH</filename> environment 
+            This file resides in the 
+            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>
+            within the <filename>meta/conf/</filename> directory.
+            BitBake finds it by examining its 
+            <link linkend='var-BBPATH'><filename>BBPATH</filename></link> environment 
             variable and looking for the <filename>meta/conf/</filename> 
             directory.
         </para>
 
         <para>
-            In the Yocto Project, <filename>bitbake.conf</filename> lists other configuration 
+            The <filename>bitbake.conf</filename> file lists other configuration 
             files to include from a <filename>conf/</filename> 
             directory below the directories listed in <filename>BBPATH</filename>. 
             In general, the most important configuration file from a user's perspective 
             is <filename>local.conf</filename>, which contains a user's customized 
-            settings for the Yocto Project build environment. 
+            settings for the OpenEmbedded build environment. 
             Other notable configuration files are the distribution 
             configuration file (set by the 
             <filename><link linkend='var-DISTRO'>DISTRO</link></filename> variable) 

documentation/poky-ref-manual/ref-classes.xml

@@ -12,10 +12,11 @@
     file. 
     Class files are identified by the extension <filename>.bbclass</filename> and are usually placed 
     in a <filename>classes/</filename> directory beneath the 
-    <filename>meta*/</filename> directory found in the Yocto Project file's area
+    <filename>meta*/</filename> directory found in the 
+    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>.
     Class files can also be pointed to by BUILDDIR (e.g. <filename>build/</filename>)in the same way as
     <filename>.conf</filename> files in the <filename>conf</filename> directory. 
-    Class files are searched for in <filename>BBPATH</filename>
+    Class files are searched for in <link linkend='var-BBPATH'><filename>BBPATH</filename></link>
     using the same method by which <filename>.conf</filename> files are searched.
 </para>
 
@@ -111,7 +112,7 @@
     </para>
 
     <para>
-	Currently, the Yocto Project supports only one binary per package.
+	Currently, the OpenEmbedded build system supports only one binary per package.
     </para>
 </section>
 
@@ -121,7 +122,7 @@
     <para>
         This class uses <filename>update-rc.d</filename> to safely install an 
         initialization script on behalf of the package. 
-        The Yocto Project takes care of details such as making sure the script is stopped before 
+        The OpenEmbedded build system takes care of details such as making sure the script is stopped before 
         a package is removed and started when the package is installed. 
         Three variables control this class: 
         <filename><link linkend='var-INITSCRIPT_PACKAGES'>INITSCRIPT_PACKAGES</link></filename>, 
@@ -254,7 +255,7 @@
 
     <para>
         This class adds the <filename>devshell</filename> task. 
-        Distribution policy dictates whether to include this class as the Yocto Project does.
+        Distribution policy dictates whether to include this class.
         See the 
         "<link linkend='platdev-appdev-devshell'>Development Within a Development Shell</link>" section 
         for more information about using devshell.
@@ -277,8 +278,9 @@
     <para>
         You can control the list of resulting package formats by using the 
         <filename><link linkend='var-PACKAGE_CLASSES'>PACKAGE_CLASSES</link></filename> 
-        variable defined in the <filename>local.conf</filename> configuration file 
-        found in the Yocto Project file's <filename>conf</filename> directory. 
+        variable defined in the <filename>local.conf</filename> configuration file, 
+        which is located in the <filename>conf</filename> folder of the 
+        <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>. 
         When defining the variable, you can specify one or more package types.
         Since images are generated from packages, a packaging class is 
         needed to enable image generation.
@@ -380,7 +382,7 @@
         The class also performs basic user configuration checks from 
         the <filename>local.conf</filename> configuration file to
         prevent common mistakes that cause build failures. 
-        Distribution policy usually whether to include this class as the Yocto Project does.
+        Distribution policy usually determines whether to include this class.
     </para>
 </section>
 
@@ -389,10 +391,10 @@
 
     <para>
         This class adds a step to the package generation process that sanity checks the
-        packages generated by the Yocto Project.
+        packages generated by the OpenEmbedded build system.
         A range of checks are performed that check the build's output
         for common problems that show up during runtime.
-        Distribution policy usually dictates whether to include this class as the Yocto Project does.
+        Distribution policy usually dictates whether to include this class.
     </para>
 
     <para>
@@ -514,7 +516,8 @@
         you can use this class to specify those packages and associate the users and groups
         with those packages.
         The <filename>meta-skeleton/recipes-skeleton/useradd/useradd-example.bb</filename> 
-        recipe in the Yocto Project Files provides a simple exmample that shows how to add three 
+        recipe in the <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>
+        provides a simple exmample that shows how to add three 
         users and groups to two packages.
         See the <filename>useradd-example.bb</filename> for more information on how to 
         use this class.
@@ -526,7 +529,7 @@
 
     <para>
         You can use this class to build software from source code that is external to the 
-        Yocto Project build system.  
+        OpenEmbedded build system.  
         In other words, your source code resides in an external tree outside of the Yocto Project.
         Building software from an external source tree means that the normal fetch, unpack, and 
         patch process is not used.
@@ -541,7 +544,7 @@
     <para>
         This class expects the source code to support recipe builds that use the 
         <link linkend='var-B'><filename>B</filename></link> variable to point to the directory in 
-        which the Yocto Project build system places the generated objects built from the recipes.
+        which the OpenEmbedded build system places the generated objects built from the recipes.
         By default, the <filename>B</filename> directory is set to the following, which is separate from the 
         source directory (<filename>S</filename>):
         <literallayout class='monospaced'>
@@ -570,7 +573,7 @@
         When you do, the <link linkend='var-B'><filename>B</filename></link> variable must support the 
         recipe's ability to build variants in different working directories.
         Most autotools-based recipes support separating these directories.
-        The Yocto Project defaults to using separate directories for <filename>gcc</filename>
+        The OpenEmbedded build system defaults to using separate directories for <filename>gcc</filename>
         and some kernel recipes.
         Alternatively, you can make sure that separate recipes exist that each 
         use the <filename>BBCLASSEXTEND</filename> variable to build each variant.
@@ -591,7 +594,7 @@
         Thus far, this appendix has discussed only the most useful and important 
         classes.
         However, other classes exist within the <filename>meta/classes</filename> directory 
-        in the Yocto Project file's directory structure.
+        in the <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>.
         You can examine the <filename>.bbclass</filename> files directly for more 
         information. 
     </para>

documentation/poky-ref-manual/ref-features.xml

@@ -115,7 +115,7 @@
         <title>Reference: Images</title>
 
         <para>
-            The contents of images generated by the Yocto Project can be controlled by the 
+            The contents of images generated by the OpenEmbedded build system can be controlled by the 
             <filename><link linkend='var-IMAGE_FEATURES'>IMAGE_FEATURES</link></filename>
             and <filename><link linkend='var-EXTRA_IMAGE_FEATURES'>EXTRA_IMAGE_FEATURES</link></filename>
             variables that you typically configure in your image recipes.

documentation/poky-ref-manual/ref-images.xml

@@ -6,7 +6,7 @@
     <title>Reference: Images</title>
 
     <para>
-        The Yocto Project build process supports several types of images to satisfy different needs.  
+        The OpenEmbedded build process supports several types of images to satisfy different needs.  
         When you issue the <filename>bitbake</filename> command you provide a “top-level” recipe 
         that essentially begins the build for the type of image you want.
     </para>
@@ -32,8 +32,8 @@
         These recipes reside in the <filename>meta/recipes-core/images</filename>,
         <filename>meta/recipes-extended/images</filename>, 
         <filename>meta/recipes-graphics/images</filename>, and 
-        <filename>meta/recipes-sato/images</filename> directories of your local Yocto Project 
-        file structure (Git repository or extracted release tarball).  
+        <filename>meta/recipes-sato/images</filename> directories 
+        within the <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>.  
         Although the recipe names are somewhat explanatory, here is a list that describes them:
     </para>
 
@@ -46,7 +46,10 @@
         <listitem><para><emphasis><filename>core-image-minimal</filename>:</emphasis>
             A small image just capable of allowing a device to boot.</para></listitem>
         <listitem><para><emphasis><filename>core-image-minimal-dev</filename>:</emphasis>
-            A <filename>core-image-minimal</filename> image suitable for development work.
+            A <filename>core-image-minimal</filename> image suitable for development work
+            using the host.
+            The image includes headers and libraries you can use in a host development 
+            environment.
             </para></listitem>
         <listitem><para><emphasis><filename>core-image-minimal-initramfs</filename>:</emphasis>
             A <filename>core-image-minimal</filename> image that has the Minimal RAM-based 
@@ -65,13 +68,15 @@
             A <filename>core-image-basic</filename> image suitable for implementations 
             that conform to Linux Standard Base (LSB).</para></listitem>
         <listitem><para><emphasis><filename>core-image-lsb-dev</filename>:</emphasis>
-            A <filename>core-image-lsb</filename> image that is suitable for development work.
+            A <filename>core-image-lsb</filename> image that is suitable for development work
+            using the host.
+            The image includes headers and libraries you can use in a host development 
+            environment.
             </para></listitem>
         <listitem><para><emphasis><filename>core-image-lsb-sdk</filename>:</emphasis>
             A <filename>core-image-lsb</filename> that includes everything in meta-toolchain 
-            but also includes development headers and libraries to form a complete standalone SDK. 
-            See the "<link linkend='platdev-appdev-external-sdk'>External Development Using the Meta-Toolchain</link>"
-            section for more information.</para></listitem>
+            but also includes development headers and libraries to form a complete standalone SDK.
+            This image is suitable for development using the target.</para></listitem>
         <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>
@@ -81,16 +86,15 @@
             The image supports X11 with a Sato theme and Pimlico applications and also  
             contains terminal, editor, and file manager.</para></listitem>
         <listitem><para><emphasis><filename>core-image-sato-dev</filename>:</emphasis>
-            A <filename>core-image-sato</filename> image suitable for development
-            that also includes a native toolchain and libraries needed to build applications on 
-            the device itself. 
-            The image also includes testing and profiling tools as well as debug symbols.  
+            A <filename>core-image-sato</filename> image suitable for development 
+            using the host.
+            The image includes libraries needed to build applications on the device itself, 
+            testing and profiling tools, and debug symbols.  
             This image was formerly <filename>core-image-sdk</filename>.</para></listitem>
         <listitem><para><emphasis><filename>core-image-sato-sdk</filename>:</emphasis>
             A <filename>core-image-sato</filename> image that includes everything in meta-toolchain. 
-            The image also includes development headers and libraries to form a complete standalone SDK. 
-            See the "<link linkend='platdev-appdev-external-sdk'>External Development Using the Meta-Toolchain</link>" 
-            section for more information.</para></listitem>
+            The image also includes development headers and libraries to form a complete standalone SDK
+            and is suitable for development using the target.</para></listitem>
         <listitem><para><emphasis><filename>core-image-rt</filename>:</emphasis>
             A <filename>core-image-minimal</filename> image plus a real-time test suite and 
             tools appropriate for real-time use.</para></listitem>
@@ -98,14 +102,19 @@
             A <filename>core-image-rt</filename> image that includes everything in 
             <filename>meta-toolchain</filename>.  
             The image also includes development headers and libraries to form a complete 
-            stand-alone SDK.  
-            See the "<link linkend='platdev-appdev-external-sdk'>External Development Using the Meta-Toolchain</link>"
-            section for more information.</para></listitem>
+            stand-alone SDK and is suitable for development using the target.</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>build-appliance-image</filename>:</emphasis>
+            An image you can boot and run using either the
+            <ulink url='http://www.vmware.com/products/player/overview.html'>VMware Player</ulink>
+            or <ulink url='http://www.vmware.com/products/workstation/overview.html'>VMware Workstation</ulink>.
+            For more information on this image, see the
+            <ulink url='&YOCTO_HOME_URL;/documentation/build-appliance'>Build Appliance</ulink> page on 
+            the Yocto Project website.</para></listitem>
     </itemizedlist>
 
     <tip>

documentation/poky-ref-manual/ref-structure.xml

@@ -9,12 +9,12 @@
 <para>
     The Yocto Project consists of several components.
     Understanding them and knowing where they are located is key to using the Yocto Project well.
-    This appendix describes the Yocto Project file's directory structure and gives information about the various 
-    files and directories.
+    This appendix describes the <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>
+    and gives information about the various files and directories.
 </para>
 
 <para>
-    For information on how to establish the Yocto Project files on your local development system, see the
+    For information on how to establish a local source directory on your development system, see the
     "<ulink url='&YOCTO_DOCS_DEV_URL;#getting-setup'>Getting Set Up</ulink>"
     section in the Yocto Project Development Manual.
 </para>
@@ -30,17 +30,23 @@
             The copy usually matches the current stable BitBake release from the BitBake project. 
             BitBake, a metadata 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.
-            The <filename>bitbake/bin/</filename> directory is placed 
-            into the shell's <filename>PATH</filename> environment variable by the 
-            <link linkend="structure-core-script">oe-init-build-env</link> script.
+        </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">oe-init-build-env</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.
         </para>
 
         <para>
             For more information on BitBake, see the BitBake on-line manual at 
-            <ulink url="http://bitbake.berlios.de/manual/"/>.
+            <ulink url="http://docs.openembedded.org/bitbake/html/"/>.
         </para>
     </section>
 
@@ -49,18 +55,20 @@
 
         <para>
             This directory contains user configuration files and the output 
-            generated by the Yocto Project in its standard configuration where the source tree is 
-            combined with the output.
-            The build directory is created initially when you <filename>source</filename>
+            generated by the OpenEmbedded build system in its standard configuration where 
+            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 Yocto Project environment setup script <filename>oe-init-build-env</filename>.
         </para>
 
         <para> 
             It is also possible to place output and configuration 
-            files in a directory separate from the Yocto Project files
+            files in a directory separate from the 
+            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>
             by providing a directory name when you <filename>source</filename>
             the setup script.
-            For information on separating output from the Yocto Project files, see <link 
+            For information on separating output from your local source directory files, see <link 
             linkend='structure-core-script'>oe-init-build-env</link>.
         </para>
     </section>
@@ -147,9 +155,11 @@
             By default, running this script without a build directory argument creates the 
             <filename>build</filename> directory. 
             If you provide a build directory argument when you <filename>source</filename>
-            the script, you direct the Yocto Project to create a build directory of your choice.
+            the script, you direct OpenEmbedded build system to create a 
+            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink> of your choice.
             For example, the following command creates a build directory named 
-            <filename>mybuilds</filename> that is outside of the Yocto Project files:
+            <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 ~/mybuilds
             </literallayout>
@@ -181,12 +191,12 @@
         <title><filename>build/conf/local.conf</filename></title>
 
         <para>
-            This file contains all the local user configuration of the Yocto Project. 
+            This file contains all the local user configuration for your build environment. 
             If there is no <filename>local.conf</filename> present, it is created from 
             <filename>local.conf.sample</filename>. 
             The <filename>local.conf</filename> file contains documentation on the various configuration options.  
-            Any variable set here overrides any variable set elsewhere within the Yocto Project unless 
-            that variable is hard-coded within the Yocto Project (e.g. by using '=' instead of '?='). 
+            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 variables are 
             relatively rare.
         </para>
@@ -244,10 +254,11 @@
         <title><filename>build/tmp/</filename></title>
 
         <para>
-            This directory receives all the Yocto Project output.
+            This directory receives all the OpenEmbedded build system's output.
             BitBake creates this directory if it does not exist. 
-            As a last resort, to clean the Yocto Project and start a build from scratch (other than downloads), 
-            you can remove everything in this directory or get rid of the directory completely.
+            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 
+            directory completely.
             If you do, you should also completely remove the <filename>build/sstate-cache</filename>
             directory as well.
         </para>
@@ -275,7 +286,7 @@
         <title><filename>build/tmp/deploy/</filename></title>
 
         <para>
-            This directory contains any 'end result' output from the Yocto Project build process.
+            This directory contains any 'end result' output from the OpenEmbedded build process.
         </para>
     </section>
 
@@ -283,7 +294,8 @@
         <title><filename>build/tmp/deploy/deb/</filename></title>
 
         <para>
-            This directory receives any <filename>.deb</filename> packages produced by the Yocto Project.
+            This directory receives any <filename>.deb</filename> packages produced by 
+            the build process.
             The packages are sorted into feeds for different architecture types.
         </para>
     </section>
@@ -292,11 +304,23 @@
         <title><filename>build/tmp/deploy/rpm/</filename></title>
 
         <para>
-            This directory receives any <filename>.rpm</filename> packages produced by the Yocto Project.  
+            This directory receives any <filename>.rpm</filename> packages produced by 
+            the build process.  
             The packages are sorted into feeds for different architecture types.
         </para>
     </section>
 
+    <section id='structure-build-tmp-deploy-licenses'>
+        <title><filename>build/tmp/deploy/licenses/</filename></title>
+
+        <para>
+            This directory receives package licensing information.
+            For example, the directory contains sub-directories for <filename>bash</filename>,
+            <filename>busybox</filename>, and <filename>eglibc</filename> (among others) that in turn
+            contain appropriate <filename>COPYING</filename> license files with other licensing information.
+        </para>
+    </section>
+
     <section id='structure-build-tmp-deploy-images'>
         <title><filename>build/tmp/deploy/images/</filename></title>
 
@@ -319,7 +343,9 @@
     <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 Yocto Project.</para>
+        <para>
+            This directory receives <filename>.ipk</filename> packages produced by 
+            the build process.</para>
     </section>
 
     <section id='structure-build-tmp-sysroots'>
@@ -354,6 +380,7 @@
             package's <filename><link linkend='var-WORKDIR'>WORKDIR</link></filename>.
             Examples of logs are the output from the <filename>check_pkg</filename> or 
             <filename>distro_check</filename> tasks.
+            Running a build does not necessarily mean this directory is created.
         </para>
     </section>
 
@@ -380,7 +407,8 @@
 
         <para>
             It is worth considering the structure of a typical work directory. 
-            As an example, consider the linux-yocto kernel 3.0 on the machine <filename>qemux86</filename> 
+            As an example, consider the <filename>linux-yocto-kernel-3.0</filename>
+            on the machine <filename>qemux86</filename> 
             built within the Yocto Project.  
             For this package, a work directory of 
             <filename>tmp/work/qemux86-poky-linux/linux-yocto-3.0+git1+&lt;.....&gt;</filename>, 
@@ -455,7 +483,7 @@
         <para>
             This directory contains all the machine configuration files. 
             If you set <filename>MACHINE="qemux86"</filename>, 
-            Yocto Project looks for a <filename>qemux86.conf</filename> file in this 
+            the OpenEmbedded build system looks for a <filename>qemux86.conf</filename> file in this 
             directory. 
             The <filename>include</filename> directory contains various data common to multiple machines. 
             If you want to add support for a new machine to the Yocto Project, look in this directory.
@@ -467,12 +495,11 @@
 
         <para>
             Any distribution-specific configuration is controlled from this directory. 
-            The Yocto Project only contains the Yocto Project distribution so 
-            <filename>defaultsetup.conf</filename> is the main file here.  
+            For the Yocto Project, the <filename>defaultsetup.conf</filename> is the main file here.  
             This directory includes the versions and the 
             <filename>SRCDATE</filename> definitions for applications that are configured here. 
-            An example of an alternative configuration is <filename>poky-bleeding.conf</filename>
-            although this file mainly inherits its configuration from the Yocto Project itself.
+            An example of an alternative configuration might be <filename>poky-bleeding.conf</filename>.
+            Although this file mainly inherits its configuration from Poky.
         </para>
     </section>
 
@@ -563,6 +590,15 @@
         </para>
     </section>
 
+    <section id='structure-meta-recipes-rt'>
+        <title><filename>meta/recipes-rt/</filename></title>
+
+        <para>
+            This directory contains package and image recipes for using and testing
+            the <filename>PREEMPT_RT</filename> kernel. 
+        </para>
+    </section>
+
     <section id='structure-meta-recipes-sato'>
         <title><filename>meta/recipes-sato/</filename></title>
 
@@ -593,7 +629,7 @@
     </section>
 
     <section id='structure-meta-recipes-txt'>
-        <title><filename>meta/recipes.txt/</filename></title>
+        <title><filename>meta/recipes.txt</filename></title>
 
         <para>
             This file is a description of the contents of <filename>recipes-*</filename>.

documentation/poky-ref-manual/ref-variables.xml

@@ -8,7 +8,7 @@
 <title>Reference: Variables Glossary</title>
 
 <para>
-    This section lists common variables used in the Yocto Project and gives an overview
+    This section lists common variables used in the OpenEmbedded build system and gives an overview
     of their function and contents.
 </para>
 
@@ -89,7 +89,7 @@
         <glossentry id='var-B'><glossterm>B</glossterm>
             <glossdef>
                 <para>
-                    The directory in which the Yocto Project build system places
+                    The directory in which the OpenEmbedded build system places
                     generated objects during a recipe's build process.
                     By default, this directory is the same as the <link linkend='var-S'><filename>S</filename></link>
                     directory:
@@ -99,7 +99,7 @@
                     You can separate the source directory (<filename>S</filename>) and the directory pointed to 
                     by the <filename>B</filename> variable.
                     Most autotools-based recipes support separating these directories.
-                    The Yocto Project defaults to using separate directories for <filename>gcc</filename>
+                    The build system defaults to using separate directories for <filename>gcc</filename>
                     and some kernel recipes.
                 </para>
             </glossdef>
@@ -160,7 +160,7 @@
                     </literallayout></para>
                 <para>Use the <filename>BBMASK</filename> variable from within the 
                     <filename>conf/local.conf</filename> file found 
-                    in the Yocto Project build directory.</para>
+                    in the <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>.</para>
             </glossdef>
         </glossentry>
 
@@ -243,9 +243,9 @@
 
         <glossentry id='var-BBLAYERS'><glossterm>BBLAYERS</glossterm>
             <glossdef>
-                <para>Lists the layers to enable during the Yocto Project build. 
+                <para>Lists the layers to enable during the build. 
                     This variable is defined in the <filename>bblayers.conf</filename> configuration 
-                    file in the Yocto Project build directory. 
+                    file in the <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>. 
                     Here is an example:
                     <literallayout class='monospaced'>
      BBLAYERS = " \
@@ -335,8 +335,8 @@
                     <filename>/etc</filename> or <filename>${bindir}</filename> rather 
                     than <filename>/usr/bin</filename>.
                     You can find a list of these variables at the top of the 
-                    <filename>/meta/conf/bitbake.conf</filename> file in the Yocto Project
-                    files directory.
+                    <filename>/meta/conf/bitbake.conf</filename> file in the 
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>.
                 </note>
             </glossdef>
         </glossentry>
@@ -358,7 +358,7 @@
                     Specifies the list of packages to be added to the image. 
                     This variable should only be set in the <filename>local.conf</filename>
                     configuration file found in the 
-                    <ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-build-directory'>Yocto Project Build Directory</ulink>.
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>.
                 </para>
 
                 <para>
@@ -479,7 +479,7 @@
                     This directory is self-maintaining and you should not have
                     to touch it. 
                     By default, the directory is <filename>downloads</filename> in the 
-                    Yocto Project build directory.
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>.
                     <literallayout class='monospaced'>
      #DL_DIR ?= "${TOPDIR}/downloads"
                     </literallayout>
@@ -635,8 +635,8 @@
                     <filename>/etc</filename> or <filename>${bindir}</filename> rather 
                     than <filename>/usr/bin</filename>.
                     You can find a list of these variables at the top of the 
-                    <filename>/meta/conf/bitbake.conf</filename> file in the Yocto Project
-                    files directory.
+                    <filename>/meta/conf/bitbake.conf</filename> file in the 
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>.
                 </note>
 
                 <para>
@@ -655,7 +655,7 @@
         <glossentry id='var-FILESEXTRAPATHS'><glossterm>FILESEXTRAPATHS</glossterm>
             <glossdef>
                 <para>
-                    Extends the search path the Yocto Project build system uses when 
+                    Extends the search path the OpenEmbedded build system uses when 
                     looking for files and patches as it processes recipes. 
                     The directories BitBake uses when it processes recipes is defined by the
                     <link linkend='var-FILESPATH'><filename>FILESPATH</filename></link> variable. 
@@ -691,7 +691,7 @@
         <glossentry id='var-FILESPATH'><glossterm>FILESPATH</glossterm>
             <glossdef>
                 <para>
-                    The default set of directories the Yocto Project build system uses
+                    The default set of directories the OpenEmbedded build system uses
                     when searching for patches and files.
                     During the build process, BitBake searches each directory in 
                     <filename>FILESPATH</filename> in the specified order when looking for 
@@ -702,7 +702,7 @@
                     The default value for the <filename>FILESPATH</filename> variable is defined
                     in the <filename>base.bbclass</filename> class found in 
                     <filename>meta/classes</filename> in the 
-                    <ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-files'>Yocto Project Files</ulink>:
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>:
                     <literallayout class='monospaced'>
 FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \
    "${FILE_DIRNAME}/${P}", "${FILE_DIRNAME}/${PN}", \
@@ -727,16 +727,17 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \
                     possible.
                 </para>
                 <para>
-                    By default, the Yocto Project uses the <filename>fs-perms.txt</filename>, which
-                    is located in the <filename>meta/files</filename> directory of the Yocto Project
-                    files directory.
+                    By default, the OpenEmbedded build system uses the <filename>fs-perms.txt</filename>, which
+                    is located in the <filename>meta/files</filename> folder in the 
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>.
                     If you create your own file permissions setting table, you should place it in your
                     layer or the distros layer. 
                 </para>
                 <para>
                     You define the <filename>FILESYSTEM_PERMS_TABLES</filename> variable in the 
-                    <filename>conf/local.conf</filename> file, which is found in the Yocto Project's 
-                    build directory, to point to your custom <filename>fs-perms.txt</filename>.
+                    <filename>conf/local.conf</filename> file, which is found in the 
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>, to 
+                    point to your custom <filename>fs-perms.txt</filename>.
                     You can specify more than a single file permissions setting table.
                     The paths you specify to these files must be defined within the 
                     <filename>BBPATH</filename> variable.  
@@ -785,7 +786,7 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \
                 Note that you can add extra features to the image by using the
                 <filename><link linkend='var-EXTRA_IMAGE_FEATURES'>EXTRA_IMAGE_FEATURES</link></filename> variable.
                 See the "<link linkend="ref-features-image">Reference: Images</link>" section for the 
-                list of features present in images built by the Yocto Project.</para>
+                list of features present in images built by the OpenEmbedded build system.</para>
             </glossdef>
         </glossentry>
 
@@ -908,7 +909,7 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \
             <glossdef>
                 <para>
                     Defines the size in Kbytes for the generated image.
-                    The Yocto Project build system determines the final size for the generated 
+                    The OpenEmbedded build system determines the final size for the generated 
                     image using an algorithm that takes into account the initial disk space used
                     for the generated image, a requested size for the image, and requested 
                     additional free disk space to be added to the image.
@@ -948,19 +949,20 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \
             <glossdef>
                 <para>Defines the Package revision.  
                     You manually combine values for <filename>INC_PR</filename> into the 
-                    <filename>PR</filename> field of the parent recipe.
+                    <link linkend='var-PR'><filename>PR</filename></link> field of the parent recipe.
                     When you change this variable, you change the <filename>PR</filename>
                     value for every person that includes the file.</para>
                 <para>
                     The following example shows how to use the <filename>INC_PR</filename> variable
                     given a common <filename>.inc</filename> file that defines the variable.
-                    Once defined, you can use the variable to set the <filename>PR</filename> value:
+                    Once defined, you can use the variable to set the 
+                    <filename>PR</filename> value:
                 </para>
                 <literallayout class='monospaced'>
- recipes-graphics/xorg-font/font-util_1.1.1.bb:PR - "$(INC_PR).1"
- recipes-graphics/xorg-font/xorg-font-common.inc:INC_PR - "r1"
- recipes-graphics/xorg-font/encondings_1.0.3.bb:PR - "$(INC_PR).1"
- recipes-graphics/xorg-font/fiont-alias_1.0.2.bb:PR - "$(INC_PR).0"
+recipes-graphics/xorg-font/encodings_1.0.4.bb:PR = "${INC_PR}.1"
+recipes-graphics/xorg-font/font-util_1.3.0.bb:PR = "${INC_PR}.0"
+recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
+recipes-graphics/xorg-font/xorg-font-common.inc:INC_PR = "r2"
                 </literallayout>
             </glossdef>
         </glossentry>
@@ -1035,8 +1037,8 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \
 
         <glossentry id='var-KERNEL_FEATURES'><glossterm>KERNEL_FEATURES</glossterm>
             <glossdef>
-                <para>Includes additional metadata from the Linux Yocto kernel Git repository.
-                    In the Yocto Project build system, the default Board Support Packages (BSPs)
+                <para>Includes additional metadata from the Yocto Project kernel Git repository.
+                    In the OpenEmbedded build system, the default Board Support Packages (BSPs)
                     metadata is provided through 
                     the <filename>KMACHINE</filename> and <filename>KBRANCH</filename> variables.
                     You can use the <filename>KERNEL_FEATURES</filename> variable to further 
@@ -1049,7 +1051,7 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \
                     In this way, you can provide validated, but optional, sets of kernel
                     configurations and features.</para>
                 <para>For example, the following adds <filename>netfilter</filename> to all 
-                    the Linux Yocto kernels and adds sound support to the <filename>qemux86</filename>
+                    the Yocto Project kernels and adds sound support to the <filename>qemux86</filename>
                     machine:
                     <literallayout class='monospaced'>
      # Add netfilter to all linux-yocto kernels
@@ -1137,7 +1139,7 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \
         <glossentry id='var-LICENSE_DIR'><glossterm>LICENSE_DIR</glossterm>
             <glossdef>
                 <para>Path to additional licenses used during the build.
-                    By default, the Yocto Project uses <filename>COMMON_LICENSE_DIR</filename>  
+                    By default, the OpenEmbedded build system uses <filename>COMMON_LICENSE_DIR</filename>  
                     to define the directory that holds common license text used during the build. 
                     The <filename>LICENSE_DIR</filename> variable allows you to extend that
                     location to other areas that have additional licenses: 
@@ -1341,7 +1343,8 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \
         <glossentry id='var-PACKAGE_CLASSES'><glossterm>PACKAGE_CLASSES</glossterm>
             <glossdef>
                 <para>This variable, which is set in the <filename>local.conf</filename> configuration
-                    file found in the Yocto Project file's <filename>conf</filename> directory,
+                    file found in the <filename>conf</filename> folder of the 
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>,
                     specifies the package manager to use when packaging data.
                     You can provide one or more arguments for the variable with the first 
                     argument being the package manager used to create images:
@@ -1534,7 +1537,7 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \
                     <filename><link linkend='var-RDEPENDS'>RDEPENDS</link></filename> variable.
                 </para>
                 <para>
-                    The Yocto Project build process automatically installs the list of packages
+                    The OpenEmbedded build process automatically installs the list of packages
                     as part of the built package.
                     However, you can remove them later if you want.
                     If, during the build, a package from the list cannot be found, the build
@@ -1572,8 +1575,8 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \
         <glossentry id='var-S'><glossterm>S</glossterm>
             <glossdef>
                 <para>
-                    The location in the <ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-build-directory'>
-                    Yocto Project Build Directory</ulink> where unpacked package source code resides.
+                    The location in the <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>
+                    where unpacked package source code resides.
                     This location is within the working directory 
                     (<filename><link linkend='var-WORKDIR'>WORKDIR</link></filename>), which 
                     is not static.
@@ -1585,9 +1588,10 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \
  ${WORKDIR}/${PN}-${PV}
                     </literallayout>
                     As an example, assume a 
-                    <ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-files'>
-                    Yocto Project Files</ulink> top-level directory named <filename>poky</filename> 
-                    and a default Yocto Project Build Directory of <filename>poky/build</filename>.
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink> top-level 
+                    folder named <filename>poky</filename> 
+                    and a default <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>
+                    at <filename>poky/build</filename>.
                     In this case, the working directory the build system uses to build 
                     the <filename>db</filename> package is the following:
                     <literallayout class='monospaced'>
@@ -1661,10 +1665,10 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \
             <glossdef>
                 <para></para>
                 <para>
-                    By default, the Yocto Project automatically detects whether 
+                    By default, the OpenEmbedded build system automatically detects whether 
                     <filename><link linkend='var-SRC_URI'>SRC_URI</link></filename>  
                     contains files that are machine-specific.
-                    If so, the Yocto Project automatically changes 
+                    If so, the build system automatically changes 
                     <filename><link linkend='var-PACKAGE_ARCH'>PACKAGE_ARCH</link></filename>. 
                     Setting this variable to "0" disables this behavior.
                 </para>
@@ -1728,7 +1732,7 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \
         <glossentry id='var-TARGET_ARCH'><glossterm>TARGET_ARCH</glossterm>
             <glossdef>
                 <para>The architecture of the device being built. 
-                While a number of values are possible, the Yocto Project primarily supports
+                While a number of values are possible, the OpenEmbedded build system primarily supports
                 <filename>arm</filename> and <filename>i586</filename>.</para>
             </glossdef>
         </glossentry>
@@ -1790,15 +1794,18 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \
                 </para>
                 <para>
                     The <filename>TCMODE</filename> variable selects the external toolchain
-                    built from the Yocto Project or a few supported combinations of
+                    built using the OpenEmbedded build system or a few supported combinations of
                     the upstream GCC or CodeSourcery Labs toolchain.
-                    The variable determines which of the files in 
-                    <filename>meta/conf/distro/include/tcmode-*</filename> is used. 
+                    The variable determines which of the <filename>tcmode-*</filename> files in 
+                    the <filename>meta/conf/distro/include</filename> directory, which is found in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>,
+                    is used. 
                 </para>
                 <para>
                     By default, <filename>TCMODE</filename> is set to "default", which 
-                    chooses <filename>tcmode-default.inc</filename>.
-                    The variable is similar to <filename>TCLIBC</filename>, which controls 
+                    chooses the <filename>tcmode-default.inc</filename> file.
+                    The variable is similar to 
+                    <link linkend='var-TCLIBC'><filename>TCLIBC</filename></link>, which controls 
                     the variant of the GNU standard C library (<filename>libc</filename>)
                     used during the build process: <filename>eglibc</filename> or <filename>uclibc</filename>.
                 </para>
@@ -1808,20 +1815,18 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \
         <glossentry id='var-TMPDIR'><glossterm>TMPDIR</glossterm>
             <glossdef>
                 <para>
-                    This variable is the temporary directory the Yocto Project build system 
+                    This variable is the temporary directory the OpenEmbedded build system 
                     uses when it does its work building images. 
                     By default, the <filename>TMPDIR</filename> variable is named 
                     <filename>tmp</filename> within the 
-                    <ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-build-directory'>
-                    Yocto Project Build Directory</ulink>.
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>.
                 </para>
 
                 <para>
                     If you want to establish this directory in a location other than the
                     default, you can uncomment the following statement in the 
                     <filename>conf/local.conf</filename> file in the 
-                    <ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-files'>
-                    Yocto Project Files</ulink>:
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>:
                     <literallayout class='monospaced'>
      #TMPDIR = "${TOPDIR}/tmp"
                     </literallayout> 
@@ -1833,10 +1838,9 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \
             <glossdef>
                 <para>
                     This variable is the 
-                    <ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-build-directory'>
-                    Yocto Project Build Directory</ulink>.
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>.
                     BitBake automatically sets this variable.
-                    The Yocto Project build system uses the build directory when building images. 
+                    The OpenEmbedded build system uses the build directory when building images. 
                 </para>
             </glossdef>
         </glossentry>
@@ -1854,7 +1858,7 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \
         <glossentry id='var-WORKDIR'><glossterm>WORKDIR</glossterm>
             <glossdef>
                 <para>
-                    The pathname of the working directory in which the Yocto Project build system  
+                    The pathname of the working directory in which the OpenEmbedded build system  
                     builds packages.
                     This directory is located within the
                     <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link> directory structure and changes
@@ -1881,11 +1885,10 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \
  ${TMPDIR}/work/${PACKAGE_ARCH}-poky-${TARGET_OS}/${PN}-${PV}-${PR}
                     </literallayout>
                     As an example, assume a 
-                    <ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-files'>
-                    Yocto Project Files</ulink> top-level directory named <filename>poky</filename> 
-                    and a default 
-                    <ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-build-directory'>
-                    Yocto Project Build Directory</ulink> of <filename>poky/build</filename>.
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink> top-level 
+                    folder name <filename>poky</filename> and a default 
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink> 
+                    at <filename>poky/build</filename>.
                     In this case, the working directory the build system uses to build 
                     the <filename>v86d</filename> package is the following:
                     <literallayout class='monospaced'>
@@ -1899,9 +1902,9 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \
                     <literallayout class='monospaced'>
  ${TMPDIR}/work/${MACHINE}-poky-${TARGET_OS}/${PN}-${PV}-${PR}
                     </literallayout>
-                    As an example, again assume a Yocto Project Files top-level directory 
-                    named <filename>poky</filename> and a default Yocto Project build directory 
-                    of <filename>poky/build</filename>.
+                    As an example, again assume a source directory top-level folder 
+                    named <filename>poky</filename> and a default build directory 
+                    at <filename>poky/build</filename>.
                     In this case, the working directory the build system uses to build
                     the <filename>acl</filename> package, which is dependent on a 
                     MIPS-based device, is the following:

documentation/poky-ref-manual/resources.xml

@@ -29,18 +29,24 @@
     <title>Mailing lists</title>
 
     <para>
-        To subscribe to the Yocto Project mailing lists, click on the following URLs and follow the instructions:
+        There are a number of mailing lists maintained by the Yocto Project as well as
+        related OpenEmbedded mailing lists for discussion, patch submission and announcements.
+        To subscribe to one of the following mailing lists, click on the appropriate URL
+        in the following list and follow the instructions:
         <itemizedlist>
-            <listitem><para><emphasis>
-                <ulink url='&YOCTO_LISTS_URL;/listinfo/yocto-announce'></ulink></emphasis>:
-                Use this list to receive offical Yocto Project announcements for developments and 
-                to learn about Yocto Project milestones.</para></listitem>
-            <listitem><para><emphasis><ulink url='&YOCTO_LISTS_URL;/listinfo/yocto'></ulink></emphasis>:
-                Use this list to monitor Yocto Project development discussions, ask questions, and 
-                get help.</para></listitem>
-            <listitem><para><emphasis><ulink url='&YOCTO_LISTS_URL;/listinfo/poky'></ulink></emphasis>:
-                Use this list to monitor discussions about the Yocto Project build system Poky, 
-                ask questions, and get help.</para></listitem>
+            <listitem><para><ulink url='&YOCTO_LISTS_URL;/listinfo/yocto'></ulink> -
+                General Yocto Project discussion mailing list. </para></listitem>
+            <listitem><para><ulink url='&OE_LISTS_URL;/listinfo/openembedded-core'></ulink> -
+                Discussion mailing list about OpenEmbedded-Core (the core metadata).</para></listitem>
+            <listitem><para><ulink url='&OE_LISTS_URL;/listinfo/openembedded-devel'></ulink> -
+                Discussion mailing list about OpenEmbedded.</para></listitem>
+            <listitem><para><ulink url='&OE_LISTS_URL;/listinfo/bitbake-devel'></ulink> -
+                Discussion mailing list about the BitBake build tool.</para></listitem>
+            <listitem><para><ulink url='&YOCTO_LISTS_URL;/listinfo/poky'></ulink> -
+                Discussion mailing list about Poky.</para></listitem>
+            <listitem><para><ulink url='&YOCTO_LISTS_URL;/listinfo/yocto-announce'></ulink> -
+                Mailing list to receive official Yocto Project release and milestone
+                announcements.</para></listitem>
         </itemizedlist>
     </para>
 </section>
@@ -65,15 +71,16 @@
         <itemizedlist>
             <listitem><para><emphasis><ulink url='&YOCTO_HOME_URL;'>The Yocto Project website</ulink>:
                 </emphasis> The home site for the Yocto Project.</para></listitem>
-            <listitem><para><emphasis><ulink url='&OH_HOME_URL;'>OpenedHand</ulink>:</emphasis>
+<!--            <listitem><para><emphasis><ulink url='&OH_HOME_URL;'>OpenedHand</ulink>:</emphasis>
                 The company where the Yocto Project build system Poky was first developed.
-                OpenedHand has since been acquired by Intel Corporation.</para></listitem>
+                OpenedHand has since been acquired by Intel Corporation.</para></listitem> -->
             <listitem><para><emphasis><ulink url='http://www.intel.com/'>Intel Corporation</ulink>:</emphasis>
-                The company who acquired OpenedHand in 2008 and continues development on the 
+                The company who acquired OpenedHand in 2008 and began development on the 
                 Yocto Project.</para></listitem>
             <listitem><para><emphasis><ulink url='&OE_HOME_URL;'>OpenEmbedded</ulink>:</emphasis>
-                The upstream, generic, embedded distribution the Yocto Project build system (Poky) derives
-                from and to which it contributes.</para></listitem>
+                The upstream, generic, embedded distribution used as the basis for the build system in the 
+                Yocto Project.
+                Poky derives from and contributes back to the OpenEmbedded project.</para></listitem>
             <listitem><para><emphasis><ulink url='http://developer.berlios.de/projects/bitbake/'>
                 BitBake</ulink>:</emphasis> The tool used to process Yocto Project metadata.</para></listitem>
             <listitem><para><emphasis><ulink url='http://bitbake.berlios.de/manual/'>