build-appliance-image.bb: Bump SRCREV for 1.3_M5.rc4

Bumping the SRCREV for danny in preparation for 1.3_M5.rc4

Signed-off-by: Elizabeth Flanagan <elizabeth.flanagan@intel.com>

bitbake/bin/bitbake

@@ -40,9 +40,17 @@ from bb import cooker
 from bb import ui
 from bb import server
 
-__version__ = "1.15.3"
+__version__ = "1.16.0"
 logger = logging.getLogger("BitBake")
 
+# Unbuffer stdout to avoid log truncation in the event
+# of an unorderly exit as well as to provide timely
+# updates to log files for use with tail
+try:
+    if sys.stdout.name == '<stdout>':
+        sys.stdout = os.fdopen(sys.stdout.fileno(), 'w', 0)
+except:
+    pass
 
 class BBConfiguration(object):
     """
@@ -174,6 +182,8 @@ Default BBFILES are the .bb files in the current directory.""")
 
     parser.add_option("-B", "--bind", help = "The name/address for the bitbake server to bind to",
                action = "store", dest = "bind", default = False)
+    parser.add_option("", "--no-setscene", help = "Do not run any setscene tasks, forces builds",
+               action = "store_true", dest = "nosetscene", default = False)
     options, args = parser.parse_args(sys.argv)
 
     configuration = BBConfiguration(options)

bitbake/bin/bitbake-diffsigs

@@ -1,12 +1,102 @@
 #!/usr/bin/env python
+
+# bitbake-diffsigs
+# BitBake task signature data comparison utility
+#
+# 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 sys
 import warnings
+import fnmatch
+import optparse
+import logging
+
 sys.path.insert(0, os.path.join(os.path.dirname(os.path.dirname(sys.argv[0])), 'lib'))
 
+import bb.tinfoil
 import bb.siggen
 
-if len(sys.argv) > 2:
-    bb.siggen.compare_sigfiles(sys.argv[1], sys.argv[2])
+logger = logging.getLogger('BitBake')
+
+def find_compare_task(bbhandler, pn, taskname):
+    """ Find the most recent signature files for the specified PN/task and compare them """
+
+    if not hasattr(bb.siggen, 'find_siginfo'):
+        logger.error('Metadata does not support finding signature data files')
+        sys.exit(1)
+
+    filedates = bb.siggen.find_siginfo(pn, taskname, None, bbhandler.config_data)
+    latestfiles = sorted(filedates.keys(), key=lambda f: filedates[f])[-2:]
+    if not latestfiles:
+        logger.error('No sigdata files found matching %s %s' % (pn, taskname))
+        sys.exit(1)
+    elif len(latestfiles) < 2:
+        logger.error('Only one matching sigdata file found for the specified task (%s %s)' % (pn, taskname))
+        sys.exit(1)
+    else:
+        # Define recursion callback
+        def recursecb(key, hash1, hash2):
+            hashes = [hash1, hash2]
+            hashfiles = bb.siggen.find_siginfo(key, None, hashes, bbhandler.config_data)
+
+            recout = []
+            if len(hashfiles) == 2:
+                out2 = bb.siggen.compare_sigfiles(hashfiles[hash1], hashfiles[hash2], recursecb)
+                recout.extend(list('  ' + l for l in out2))
+            else:
+                recout.append("Unable to find matching sigdata for %s with hashes %s or %s" % (key, hash1, hash2))
+
+            return recout
+
+        # Recurse into signature comparison
+        output = bb.siggen.compare_sigfiles(latestfiles[0], latestfiles[1], recursecb)
+        if output:
+            print '\n'.join(output)
+    sys.exit(0)
+
+
+
+parser = optparse.OptionParser(
+    usage = """
+  %prog -t recipename taskname
+  %prog sigdatafile1 sigdatafile2
+  %prog sigdatafile1""")
+
+parser.add_option("-t", "--task",
+        help = "find the signature data files for last two runs of the specified task and compare them",
+        action="store_true", dest="taskmode")
+
+options, args = parser.parse_args(sys.argv)
+
+if len(args) == 1:
+    parser.print_help()
 else:
-    bb.siggen.dump_sigfile(sys.argv[1])
+    tinfoil = bb.tinfoil.Tinfoil()
+    if options.taskmode:
+        if len(args) < 3:
+            logger.error("Please specify a recipe and task name")
+            sys.exit(1)
+        tinfoil.prepare(config_only = True)
+        find_compare_task(tinfoil, args[1], args[2])
+    else:
+        if len(args) == 2:
+            output = bb.siggen.dump_sigfile(sys.argv[1])
+        else:
+            output = bb.siggen.compare_sigfiles(sys.argv[1], sys.argv[2])
+
+        if output:
+            print '\n'.join(output)

bitbake/bin/bitbake-dumpsig

@@ -6,4 +6,6 @@ sys.path.insert(0, os.path.join(os.path.dirname(os.path.dirname(sys.argv[0])), '
 
 import bb.siggen
 
-bb.siggen.dump_sigfile(sys.argv[1])
+output = bb.siggen.dump_sigfile(sys.argv[1])
+if output:
+    print '\n'.join(output)

bitbake/bin/bitbake-layers

@@ -6,10 +6,22 @@
 
 # Copyright (C) 2011 Mentor Graphics Corporation
 # 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 cmd
 import logging
-import warnings
 import os
 import sys
 import fnmatch
@@ -23,26 +35,14 @@ import bb.cache
 import bb.cooker
 import bb.providers
 import bb.utils
-from bb.cooker import state
-import bb.fetch2
+import bb.tinfoil
 
 
 logger = logging.getLogger('BitBake')
 
-warnings.filterwarnings("ignore", category=DeprecationWarning)
 
 def main(args):
-    # Set up logging
-    console = logging.StreamHandler(sys.stdout)
-    format = bb.msg.BBLogFormatter("%(levelname)s: %(message)s")
-    bb.msg.addDefaultlogFilter(console)
-    console.setFormatter(format)
-    logger.addHandler(console)
-
-    initialenv = os.environ.copy()
-    bb.utils.clean_environment()
-
-    cmds = Commands(initialenv)
+    cmds = Commands()
     if args:
         # Allow user to specify e.g. show-layers instead of show_layers
         args = [args[0].replace('-', '_')] + args[1:]
@@ -53,46 +53,11 @@ def main(args):
 
 
 class Commands(cmd.Cmd):
-    def __init__(self, initialenv):
+    def __init__(self):
         cmd.Cmd.__init__(self)
+        self.bbhandler = bb.tinfoil.Tinfoil()
         self.returncode = 0
-        self.config = Config(parse_only=True)
-        self.cooker = bb.cooker.BBCooker(self.config,
-                                         self.register_idle_function,
-                                         initialenv)
-        self.config_data = self.cooker.configuration.data
-        bb.providers.logger.setLevel(logging.ERROR)
-        self.cooker_data = None
-        self.bblayers = (self.config_data.getVar('BBLAYERS', True) or "").split()
-
-    def register_idle_function(self, function, data):
-        pass
-
-    def prepare_cooker(self):
-        sys.stderr.write("Parsing recipes..")
-        logger.setLevel(logging.WARNING)
-
-        try:
-            while self.cooker.state in (state.initial, state.parsing):
-                self.cooker.updateCache()
-        except KeyboardInterrupt:
-            self.cooker.shutdown()
-            self.cooker.updateCache()
-            sys.exit(2)
-
-        logger.setLevel(logging.INFO)
-        sys.stderr.write("done.\n")
-
-        self.cooker_data = self.cooker.status
-        self.cooker_data.appends = self.cooker.appendlist
-
-    def check_prepare_cooker(self, config_only = False):
-        if not self.cooker_data:
-            if config_only:
-                self.cooker.parseConfiguration()
-                self.cooker_data = self.cooker.status
-            else:
-                self.prepare_cooker()
+        self.bblayers = (self.bbhandler.config_data.getVar('BBLAYERS', True) or "").split()
 
     def default(self, line):
         """Handle unrecognised commands"""
@@ -117,13 +82,13 @@ class Commands(cmd.Cmd):
 
     def do_show_layers(self, args):
         """show current configured layers"""
-        self.check_prepare_cooker(config_only = True)
+        self.bbhandler.prepare(config_only = True)
         logger.plain("%s  %s  %s" % ("layer".ljust(20), "path".ljust(40), "priority"))
         logger.plain('=' * 74)
         for layerdir in self.bblayers:
             layername = self.get_layer_name(layerdir)
             layerpri = 0
-            for layer, _, regex, pri in self.cooker.status.bbfile_config_priorities:
+            for layer, _, regex, pri in self.bbhandler.cooker.status.bbfile_config_priorities:
                 if regex.match(os.path.join(layerdir, 'test')):
                     layerpri = pri
                     break
@@ -154,7 +119,7 @@ Options:
        recipes with the ones they overlay indented underneath
   -s   only list overlayed recipes where the version is the same
 """
-        self.check_prepare_cooker()
+        self.bbhandler.prepare()
 
         show_filenames = False
         show_same_ver_only = False
@@ -186,7 +151,7 @@ Options:
         # factor - however, each layer.conf is free to either prepend or append to
         # BBPATH (or indeed do crazy stuff with it). Thus the order in BBPATH might
         # not be exactly the order present in bblayers.conf either.
-        bbpath = str(self.config_data.getVar('BBPATH', True))
+        bbpath = str(self.bbhandler.config_data.getVar('BBPATH', True))
         overlayed_class_found = False
         for (classfile, classdirs) in classes.items():
             if len(classdirs) > 1:
@@ -237,7 +202,7 @@ Options:
   -m   only list where multiple recipes (in the same layer or different
        layers) exist for the same recipe name
 """
-        self.check_prepare_cooker()
+        self.bbhandler.prepare()
 
         show_filenames = False
         show_multi_provider_only = False
@@ -259,15 +224,15 @@ Options:
 
 
     def list_recipes(self, title, pnspec, show_overlayed_only, show_same_ver_only, show_filenames, show_multi_provider_only):
-        pkg_pn = self.cooker.status.pkg_pn
-        (latest_versions, preferred_versions) = bb.providers.findProviders(self.cooker.configuration.data, self.cooker.status, pkg_pn)
-        allproviders = bb.providers.allProviders(self.cooker.status)
+        pkg_pn = self.bbhandler.cooker.status.pkg_pn
+        (latest_versions, preferred_versions) = bb.providers.findProviders(self.bbhandler.cooker.configuration.data, self.bbhandler.cooker.status, pkg_pn)
+        allproviders = bb.providers.allProviders(self.bbhandler.cooker.status)
 
         # Ensure we list skipped recipes
         # We are largely guessing about PN, PV and the preferred version here,
         # but we have no choice since skipped recipes are not fully parsed
-        skiplist = self.cooker.skiplist.keys()
-        skiplist.sort( key=lambda fileitem: self.cooker.calc_bbfile_priority(fileitem) )
+        skiplist = self.bbhandler.cooker.skiplist.keys()
+        skiplist.sort( key=lambda fileitem: self.bbhandler.cooker.calc_bbfile_priority(fileitem) )
         skiplist.reverse()
         for fn in skiplist:
             recipe_parts = os.path.splitext(os.path.basename(fn))[0].split('_')
@@ -375,7 +340,7 @@ build results (as the layer priority order has effectively changed).
             logger.error('Directory %s exists and is non-empty, please clear it out first' % outputdir)
             return
 
-        self.check_prepare_cooker()
+        self.bbhandler.prepare()
         layers = self.bblayers
         if len(arglist) > 2:
             layernames = arglist[:-1]
@@ -405,8 +370,8 @@ build results (as the layer priority order has effectively changed).
         appended_recipes = []
         for layer in layers:
             overlayed = []
-            for f in self.cooker.overlayed.iterkeys():
-                for of in self.cooker.overlayed[f]:
+            for f in self.bbhandler.cooker.overlayed.iterkeys():
+                for of in self.bbhandler.cooker.overlayed[f]:
                     if of.startswith(layer):
                         overlayed.append(of)
 
@@ -430,8 +395,8 @@ build results (as the layer priority order has effectively changed).
                                     logger.warn('Overwriting file %s', fdest)
                             bb.utils.copyfile(f1full, fdest)
                             if ext == '.bb':
-                                if f1 in self.cooker_data.appends:
-                                    appends = self.cooker_data.appends[f1]
+                                if f1 in self.bbhandler.cooker.appendlist:
+                                    appends = self.bbhandler.cooker.appendlist[f1]
                                     if appends:
                                         logger.plain('  Applying appends to %s' % fdest )
                                         for appendname in appends:
@@ -440,9 +405,9 @@ build results (as the layer priority order has effectively changed).
                                     appended_recipes.append(f1)
 
         # Take care of when some layers are excluded and yet we have included bbappends for those recipes
-        for recipename in self.cooker_data.appends.iterkeys():
+        for recipename in self.bbhandler.cooker.appendlist.iterkeys():
             if recipename not in appended_recipes:
-                appends = self.cooker_data.appends[recipename]
+                appends = self.bbhandler.cooker.appendlist[recipename]
                 first_append = None
                 for appendname in appends:
                     layer = layer_path_match(appendname)
@@ -460,14 +425,14 @@ build results (as the layer priority order has effectively changed).
         # have come from)
         first_regex = None
         layerdir = layers[0]
-        for layername, pattern, regex, _ in self.cooker.status.bbfile_config_priorities:
+        for layername, pattern, regex, _ in self.bbhandler.cooker.status.bbfile_config_priorities:
             if regex.match(os.path.join(layerdir, 'test')):
                 first_regex = regex
                 break
 
         if first_regex:
             # Find the BBFILES entries that match (which will have come from this conf/layer.conf file)
-            bbfiles = str(self.config_data.getVar('BBFILES', True)).split()
+            bbfiles = str(self.bbhandler.config_data.getVar('BBFILES', True)).split()
             bbfiles_layer = []
             for item in bbfiles:
                 if first_regex.match(item):
@@ -490,7 +455,7 @@ build results (as the layer priority order has effectively changed).
                                 logger.warning("File %s does not match the flattened layer's BBFILES setting, you may need to edit conf/layer.conf or move the file elsewhere" % f1full)
 
     def get_file_layer(self, filename):
-        for layer, _, regex, _ in self.cooker.status.bbfile_config_priorities:
+        for layer, _, regex, _ in self.bbhandler.cooker.status.bbfile_config_priorities:
             if regex.match(filename):
                 for layerdir in self.bblayers:
                     if regex.match(os.path.join(layerdir, 'test')):
@@ -516,14 +481,14 @@ usage: show-appends
 
 Recipes are listed with the bbappends that apply to them as subitems.
 """
-        self.check_prepare_cooker()
-        if not self.cooker_data.appends:
+        self.bbhandler.prepare()
+        if not self.bbhandler.cooker.appendlist:
             logger.plain('No append files found')
             return
 
         logger.plain('=== Appended recipes ===')
 
-        pnlist = list(self.cooker_data.pkg_pn.keys())
+        pnlist = list(self.bbhandler.cooker_data.pkg_pn.keys())
         pnlist.sort()
         for pn in pnlist:
             self.show_appends_for_pn(pn)
@@ -531,19 +496,19 @@ Recipes are listed with the bbappends that apply to them as subitems.
         self.show_appends_for_skipped()
 
     def show_appends_for_pn(self, pn):
-        filenames = self.cooker_data.pkg_pn[pn]
+        filenames = self.bbhandler.cooker_data.pkg_pn[pn]
 
         best = bb.providers.findBestProvider(pn,
-                                             self.cooker.configuration.data,
-                                             self.cooker_data,
-                                             self.cooker_data.pkg_pn)
+                                             self.bbhandler.cooker.configuration.data,
+                                             self.bbhandler.cooker_data,
+                                             self.bbhandler.cooker_data.pkg_pn)
         best_filename = os.path.basename(best[3])
 
         self.show_appends_output(filenames, best_filename)
 
     def show_appends_for_skipped(self):
         filenames = [os.path.basename(f)
-                    for f in self.cooker.skiplist.iterkeys()]
+                    for f in self.bbhandler.cooker.skiplist.iterkeys()]
         self.show_appends_output(filenames, None, " (skipped)")
 
     def show_appends_output(self, filenames, best_filename, name_suffix = ''):
@@ -569,7 +534,7 @@ Recipes are listed with the bbappends that apply to them as subitems.
                 continue
 
             basename = os.path.basename(filename)
-            appends = self.cooker_data.appends.get(basename)
+            appends = self.bbhandler.cooker.appendlist.get(basename)
             if appends:
                 appended.append((basename, list(appends)))
             else:
@@ -577,22 +542,5 @@ Recipes are listed with the bbappends that apply to them as subitems.
         return appended, notappended
 
 
-class Config(object):
-    def __init__(self, **options):
-        self.pkgs_to_build = []
-        self.debug_domains = []
-        self.extra_assume_provided = []
-        self.prefile = []
-        self.postfile = []
-        self.debug = 0
-        self.__dict__.update(options)
-
-    def __getattr__(self, attribute):
-        try:
-            return super(Config, self).__getattribute__(attribute)
-        except AttributeError:
-            return None
-
-
 if __name__ == '__main__':
     sys.exit(main(sys.argv[1:]) or 0)

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

bitbake/lib/bb/build.py

@@ -470,11 +470,40 @@ def stamp_internal(taskname, d, file_name):
 
     return stamp
 
+def stamp_cleanmask_internal(taskname, d, file_name):
+    """
+    Internal stamp helper function to generate stamp cleaning mask
+    Returns the stamp path+filename
+
+    In the bitbake core, d can be a CacheData and file_name will be set.
+    When called in task context, d will be a data store, file_name will not be set
+    """
+    taskflagname = taskname
+    if taskname.endswith("_setscene") and taskname != "do_setscene":
+        taskflagname = taskname.replace("_setscene", "")
+
+    if file_name:
+        stamp = d.stamp_base_clean[file_name].get(taskflagname) or d.stampclean[file_name]
+        extrainfo = d.stamp_extrainfo[file_name].get(taskflagname) or ""
+    else:
+        stamp = d.getVarFlag(taskflagname, 'stamp-base-clean', True) or d.getVar('STAMPCLEAN', True)
+        file_name = d.getVar('BB_FILENAME', True)
+        extrainfo = d.getVarFlag(taskflagname, 'stamp-extra-info', True) or ""
+
+    if not stamp:
+        return
+
+    return bb.parse.siggen.stampcleanmask(stamp, file_name, taskname, extrainfo)
+
 def make_stamp(task, d, file_name = None):
     """
     Creates/updates a stamp for a given task
     (d can be a data dict or dataCache)
     """
+    cleanmask = stamp_cleanmask_internal(task, d, file_name)
+    if cleanmask:
+        bb.utils.remove(cleanmask)
+
     stamp = stamp_internal(task, d, file_name)
     # Remove the file and recreate to force timestamp
     # change on broken NFS filesystems

bitbake/lib/bb/cache.py

@@ -43,7 +43,7 @@ except ImportError:
     logger.info("Importing cPickle failed. "
                 "Falling back to a very slow implementation.")
 
-__cache_version__ = "144"
+__cache_version__ = "145"
 
 def getCacheFile(path, filename, data_hash):
     return os.path.join(path, filename + "." + data_hash)
@@ -130,7 +130,9 @@ class CoreRecipeInfo(RecipeInfoCommon):
         self.broken = self.getvar('BROKEN', metadata)
         self.not_world = self.getvar('EXCLUDE_FROM_WORLD', metadata)
         self.stamp = self.getvar('STAMP', metadata)
+        self.stampclean = self.getvar('STAMPCLEAN', metadata)        
         self.stamp_base = self.flaglist('stamp-base', self.tasks, metadata)
+        self.stamp_base_clean = self.flaglist('stamp-base-clean', 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)
@@ -157,7 +159,9 @@ class CoreRecipeInfo(RecipeInfoCommon):
         cachedata.pkg_dp = {}
 
         cachedata.stamp = {}
+        cachedata.stampclean = {}
         cachedata.stamp_base = {}
+        cachedata.stamp_base_clean = {}
         cachedata.stamp_extrainfo = {}
         cachedata.file_checksums = {}
         cachedata.fn_provides = {}
@@ -189,7 +193,9 @@ class CoreRecipeInfo(RecipeInfoCommon):
         cachedata.pkg_pepvpr[fn] = (self.pe, self.pv, self.pr)
         cachedata.pkg_dp[fn] = self.defaultpref
         cachedata.stamp[fn] = self.stamp
+        cachedata.stampclean[fn] = self.stampclean
         cachedata.stamp_base[fn] = self.stamp_base
+        cachedata.stamp_base_clean[fn] = self.stamp_base_clean
         cachedata.stamp_extrainfo[fn] = self.stamp_extrainfo
         cachedata.file_checksums[fn] = self.file_checksums
 

bitbake/lib/bb/command.py

@@ -157,7 +157,7 @@ class CommandsSync:
         Set the value of variable in configuration.data
         """
         varname = params[0]
-        value = params[1]
+        value = str(params[1])
         command.cooker.configuration.data.setVar(varname, value)
 
     def initCooker(self, command, params):

bitbake/lib/bb/compat.py

@@ -1,5 +1,11 @@
 """Code pulled from future python versions, here for compatibility"""
 
+from collections import MutableMapping, KeysView, ValuesView, ItemsView
+try:
+    from thread import get_ident as _get_ident
+except ImportError:
+    from dummy_thread import get_ident as _get_ident
+
 def total_ordering(cls):
     """Class decorator that fills in missing ordering methods"""
     convert = {
@@ -26,3 +32,210 @@ def total_ordering(cls):
             opfunc.__doc__ = getattr(int, opname).__doc__
             setattr(cls, opname, opfunc)
     return cls
+
+class OrderedDict(dict):
+    'Dictionary that remembers insertion order'
+    # An inherited dict maps keys to values.
+    # The inherited dict provides __getitem__, __len__, __contains__, and get.
+    # The remaining methods are order-aware.
+    # Big-O running times for all methods are the same as regular dictionaries.
+
+    # The internal self.__map dict maps keys to links in a doubly linked list.
+    # The circular doubly linked list starts and ends with a sentinel element.
+    # The sentinel element never gets deleted (this simplifies the algorithm).
+    # Each link is stored as a list of length three:  [PREV, NEXT, KEY].
+
+    def __init__(self, *args, **kwds):
+        '''Initialize an ordered dictionary.  The signature is the same as
+        regular dictionaries, but keyword arguments are not recommended because
+        their insertion order is arbitrary.
+
+        '''
+        if len(args) > 1:
+            raise TypeError('expected at most 1 arguments, got %d' % len(args))
+        try:
+            self.__root
+        except AttributeError:
+            self.__root = root = []                     # sentinel node
+            root[:] = [root, root, None]
+            self.__map = {}
+        self.__update(*args, **kwds)
+
+    def __setitem__(self, key, value, PREV=0, NEXT=1, dict_setitem=dict.__setitem__):
+        'od.__setitem__(i, y) <==> od[i]=y'
+        # Setting a new item creates a new link at the end of the linked list,
+        # and the inherited dictionary is updated with the new key/value pair.
+        if key not in self:
+            root = self.__root
+            last = root[PREV]
+            last[NEXT] = root[PREV] = self.__map[key] = [last, root, key]
+        dict_setitem(self, key, value)
+
+    def __delitem__(self, key, PREV=0, NEXT=1, dict_delitem=dict.__delitem__):
+        'od.__delitem__(y) <==> del od[y]'
+        # Deleting an existing item uses self.__map to find the link which gets
+        # removed by updating the links in the predecessor and successor nodes.
+        dict_delitem(self, key)
+        link_prev, link_next, key = self.__map.pop(key)
+        link_prev[NEXT] = link_next
+        link_next[PREV] = link_prev
+
+    def __iter__(self):
+        'od.__iter__() <==> iter(od)'
+        # Traverse the linked list in order.
+        NEXT, KEY = 1, 2
+        root = self.__root
+        curr = root[NEXT]
+        while curr is not root:
+            yield curr[KEY]
+            curr = curr[NEXT]
+
+    def __reversed__(self):
+        'od.__reversed__() <==> reversed(od)'
+        # Traverse the linked list in reverse order.
+        PREV, KEY = 0, 2
+        root = self.__root
+        curr = root[PREV]
+        while curr is not root:
+            yield curr[KEY]
+            curr = curr[PREV]
+
+    def clear(self):
+        'od.clear() -> None.  Remove all items from od.'
+        for node in self.__map.itervalues():
+            del node[:]
+        root = self.__root
+        root[:] = [root, root, None]
+        self.__map.clear()
+        dict.clear(self)
+
+    # -- the following methods do not depend on the internal structure --
+
+    def keys(self):
+        'od.keys() -> list of keys in od'
+        return list(self)
+
+    def values(self):
+        'od.values() -> list of values in od'
+        return [self[key] for key in self]
+
+    def items(self):
+        'od.items() -> list of (key, value) pairs in od'
+        return [(key, self[key]) for key in self]
+
+    def iterkeys(self):
+        'od.iterkeys() -> an iterator over the keys in od'
+        return iter(self)
+
+    def itervalues(self):
+        'od.itervalues -> an iterator over the values in od'
+        for k in self:
+            yield self[k]
+
+    def iteritems(self):
+        'od.iteritems -> an iterator over the (key, value) pairs in od'
+        for k in self:
+            yield (k, self[k])
+
+    update = MutableMapping.update
+
+    __update = update # let subclasses override update without breaking __init__
+
+    __marker = object()
+
+    def pop(self, key, default=__marker):
+        '''od.pop(k[,d]) -> v, remove specified key and return the corresponding
+        value.  If key is not found, d is returned if given, otherwise KeyError
+        is raised.
+
+        '''
+        if key in self:
+            result = self[key]
+            del self[key]
+            return result
+        if default is self.__marker:
+            raise KeyError(key)
+        return default
+
+    def setdefault(self, key, default=None):
+        'od.setdefault(k[,d]) -> od.get(k,d), also set od[k]=d if k not in od'
+        if key in self:
+            return self[key]
+        self[key] = default
+        return default
+
+    def popitem(self, last=True):
+        '''od.popitem() -> (k, v), return and remove a (key, value) pair.
+        Pairs are returned in LIFO order if last is true or FIFO order if false.
+
+        '''
+        if not self:
+            raise KeyError('dictionary is empty')
+        key = next(reversed(self) if last else iter(self))
+        value = self.pop(key)
+        return key, value
+
+    def __repr__(self, _repr_running={}):
+        'od.__repr__() <==> repr(od)'
+        call_key = id(self), _get_ident()
+        if call_key in _repr_running:
+            return '...'
+        _repr_running[call_key] = 1
+        try:
+            if not self:
+                return '%s()' % (self.__class__.__name__,)
+            return '%s(%r)' % (self.__class__.__name__, self.items())
+        finally:
+            del _repr_running[call_key]
+
+    def __reduce__(self):
+        'Return state information for pickling'
+        items = [[k, self[k]] for k in self]
+        inst_dict = vars(self).copy()
+        for k in vars(OrderedDict()):
+            inst_dict.pop(k, None)
+        if inst_dict:
+            return (self.__class__, (items,), inst_dict)
+        return self.__class__, (items,)
+
+    def copy(self):
+        'od.copy() -> a shallow copy of od'
+        return self.__class__(self)
+
+    @classmethod
+    def fromkeys(cls, iterable, value=None):
+        '''OD.fromkeys(S[, v]) -> New ordered dictionary with keys from S.
+        If not specified, the value defaults to None.
+
+        '''
+        self = cls()
+        for key in iterable:
+            self[key] = value
+        return self
+
+    def __eq__(self, other):
+        '''od.__eq__(y) <==> od==y.  Comparison to another OD is order-sensitive
+        while comparison to a regular mapping is order-insensitive.
+
+        '''
+        if isinstance(other, OrderedDict):
+            return len(self)==len(other) and self.items() == other.items()
+        return dict.__eq__(self, other)
+
+    def __ne__(self, other):
+        'od.__ne__(y) <==> od!=y'
+        return not self == other
+
+    # -- the following methods support python 3.x style dictionary views --
+
+    def viewkeys(self):
+        "od.viewkeys() -> a set-like object providing a view on od's keys"
+        return KeysView(self)
+
+    def viewvalues(self):
+        "od.viewvalues() -> an object providing a view on od's values"
+        return ValuesView(self)
+
+    def viewitems(self):
+        "od.viewitems() -> a set-like object providing a view on od's items"
+        return ItemsView(self)

bitbake/lib/bb/cooker.py

@@ -278,8 +278,8 @@ class BBCooker:
         pkg_pn = self.status.pkg_pn
         (latest_versions, preferred_versions) = bb.providers.findProviders(self.configuration.data, self.status, pkg_pn)
 
-        logger.plain("%-35s %25s %25s", "Package Name", "Latest Version", "Preferred Version")
-        logger.plain("%-35s %25s %25s\n", "============", "==============", "=================")
+        logger.plain("%-35s %25s %25s", "Recipe Name", "Latest Version", "Preferred Version")
+        logger.plain("%-35s %25s %25s\n", "===========", "==============", "=================")
 
         for p in sorted(pkg_pn):
             pref = preferred_versions[p]
@@ -642,7 +642,8 @@ class BBCooker:
         # Calculate priorities for each file
         matched = set()
         for p in self.status.pkg_fn:
-            self.status.bbfile_priority[p] = self.calc_bbfile_priority(p, matched)
+            realfn, cls = bb.cache.Cache.virtualfn2realfn(p)
+            self.status.bbfile_priority[p] = self.calc_bbfile_priority(realfn, matched)
  
         # Don't show the warning if the BBFILE_PATTERN did match .bbappend files
         unmatched = set()
@@ -938,13 +939,13 @@ class BBCooker:
                                         errors = True
                                         continue
                                     if lver <> depver:
-                                        parselog.error("Layer dependency %s of layer %s is at version %d, expected %d", dep, c, lver, depver)
+                                        parselog.error("Layer '%s' depends on version %d of layer '%s', but version %d is enabled in your configuration", c, depver, dep, lver)
                                         errors = True
                                 else:
-                                    parselog.error("Layer dependency %s of layer %s has no version, expected %d", dep, c, depver)
+                                    parselog.error("Layer '%s' depends on version %d of layer '%s', which exists in your configuration but does not specify a version", c, depver, dep)
                                     errors = True
                         else:
-                            parselog.error("Layer dependency %s of layer %s not found", dep, c)
+                            parselog.error("Layer '%s' depends on layer '%s', but this layer is not enabled in your configuration", c, dep)
                             errors = True
                     collection_depends[c] = depnamelist
                 else:
@@ -1691,8 +1692,13 @@ class CookerParser(object):
         except Exception as exc:
             self.error += 1
             etype, value, tb = sys.exc_info()
-            logger.error('Unable to parse %s', value.recipe,
-                         exc_info=(etype, value, exc.traceback))
+            if hasattr(value, "recipe"):
+                logger.error('Unable to parse %s', value.recipe,
+                            exc_info=(etype, value, exc.traceback))
+            else:
+                # Most likely, an exception occurred during raising an exception
+                import traceback
+                logger.error('Exception during parse: %s' % traceback.format_exc())
             self.shutdown(clean=False)
             return False
 

bitbake/lib/bb/data.py

@@ -323,9 +323,8 @@ def build_dependencies(key, keys, shelldeps, vardepvals, d):
 
         deps |= set((vardeps or "").split())
         deps -= set((d.getVarFlag(key, "vardepsexclude", True) or "").split())
-    except:
-        bb.note("Error expanding variable %s" % key)
-        raise
+    except Exception as e:
+        raise bb.data_smart.ExpansionError(key, None, e)
     return deps, value
     #bb.note("Variable %s references %s and calls %s" % (key, str(deps), str(execs)))
     #d.setVarFlag(key, "vardeps", deps)

bitbake/lib/bb/data_smart.py

@@ -103,7 +103,10 @@ class ExpansionError(Exception):
         self.variablename = varname
         self.exception = exception
         if varname:
-            self.msg = "Failure expanding variable %s, expression was %s which triggered exception %s: %s" % (varname, expression, type(exception).__name__, exception)
+            if expression:
+                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 variable %s: %s: %s" % (varname, 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)

bitbake/lib/bb/event.py

@@ -32,6 +32,7 @@ import logging
 import atexit
 import traceback
 import bb.utils
+import bb.compat
 
 # This is the pid for which we should generate the event. This is set when
 # the runqueue forks off.
@@ -53,7 +54,7 @@ Registered        = 10
 AlreadyRegistered = 14
 
 # Internal
-_handlers = {}
+_handlers = bb.compat.OrderedDict()
 _ui_handlers = {}
 _ui_handler_seq = 0
 
@@ -104,6 +105,18 @@ def print_ui_queue():
         console = logging.StreamHandler(sys.stdout)
         console.setFormatter(BBLogFormatter("%(levelname)s: %(message)s"))
         logger.handlers = [console]
+
+        # First check to see if we have any proper messages
+        msgprint = False
+        for event in ui_queue:
+            if isinstance(event, logging.LogRecord):
+                if event.levelno > logging.DEBUG:
+                    logger.handle(event)
+                    msgprint = True
+        if msgprint:
+            return
+
+        # Nope, so just print all of the messages we have (including debug messages)
         for event in ui_queue:
             if isinstance(event, logging.LogRecord):
                 logger.handle(event)
@@ -497,6 +510,15 @@ class MsgFatal(MsgBase):
 class MsgPlain(MsgBase):
     """General output"""
 
+class LogExecTTY(Event):
+    """Send event containing program to spawn on tty of the logger"""
+    def __init__(self, msg, prog, sleep_delay, retries):
+        Event.__init__(self)
+        self.msg = msg
+        self.prog = prog
+        self.sleep_delay = sleep_delay
+        self.retries = retries
+
 class LogHandler(logging.Handler):
     """Dispatch logging messages as bitbake events"""
 
@@ -540,6 +562,7 @@ class SanityCheckFailed(Event):
     """
     Event to indicate sanity check has failed
     """
-    def __init__(self, msg):
+    def __init__(self, msg, network_error=False):
         Event.__init__(self)
         self._msg = msg
+        self._network_error = network_error

bitbake/lib/bb/fetch2/__init__.py

@@ -54,7 +54,7 @@ class MalformedUrl(BBFetchException):
          msg = "The URL: '%s' is invalid and cannot be interpreted" % url
          self.url = url
          BBFetchException.__init__(self, msg)
-         self.args = url
+         self.args = (url,)
 
 class FetchError(BBFetchException):
     """General fetcher exception when something happens incorrectly"""
@@ -87,7 +87,7 @@ class NoMethodError(BBFetchException):
          msg = "Could not find a fetcher which supports the URL: '%s'" % url
          self.url = url
          BBFetchException.__init__(self, msg)
-         self.args = url
+         self.args = (url,)
 
 class MissingParameterError(BBFetchException):
     """Exception raised when a fetch method is missing a critical parameter in the url"""
@@ -178,6 +178,9 @@ def encodeurl(decoded):
         url += "@"
     if host and type != "file":
         url += "%s" % host
+    # Standardise path to ensure comparisons work
+    while '//' in path:
+        path = path.replace("//", "/")
     url += "%s" % urllib.quote(path)
     if p:
         for parm in p:
@@ -355,7 +358,7 @@ def verify_checksum(u, ud, d):
         mismatch = True;
 
     if mismatch:
-        msg = msg + '\nYour checksums:\nSRC_URI[%s] = "%s"\nSRC_URI[%s] = "%s"' % (ud.md5_name, md5data, ud.sha256_name, sha256data)
+        msg = msg + '\nIf this change is expected (e.g. you have upgraded to a new version without updating the checksums) then you can use these lines within the recipe:\nSRC_URI[%s] = "%s"\nSRC_URI[%s] = "%s"\nOtherwise you should retry the download and/or check with upstream to determine if the file has become corrupted or otherwise unexpectedly modified.\n' % (ud.md5_name, md5data, ud.sha256_name, sha256data)
 
     if len(msg):
         raise ChecksumError('Checksum mismatch!%s' % msg, u)
@@ -468,7 +471,13 @@ def runfetchcmd(cmd, d, quiet = False, cleanup = []):
     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)
+        if e.stdout:
+            output = "output:\n%s\n%s" % (e.stdout, e.stderr)
+        elif e.stderr:
+            output = "output:\n%s" % e.stderr
+        else:
+            output = "no output"
+        error_message = "Fetch command failed with exit code %s, %s" % (e.exitcode, output)
     except bb.process.CmdError as e:
         error_message = "Fetch command %s could not be run:\n%s" % (e.command, e.msg)
     if not success:
@@ -938,14 +947,16 @@ class FetchMethod(object):
                 if dos:
                     cmd = '%s -a' % cmd
                 cmd = "%s '%s'" % (cmd, file)
-            elif file.endswith('.src.rpm') or file.endswith('.srpm'):
+            elif file.endswith('.rpm') or file.endswith('.srpm'):
                 if 'extract' in urldata.parm:
                     unpack_file = urldata.parm.get('extract')
-                    cmd = 'rpm2cpio.sh %s | cpio -i %s' % (file, unpack_file)
+                    cmd = 'rpm2cpio.sh %s | cpio -id %s' % (file, unpack_file)
                     iterate = True
                     iterate_file = unpack_file
                 else:
-                    cmd = 'rpm2cpio.sh %s | cpio -i' % (file)
+                    cmd = 'rpm2cpio.sh %s | cpio -id' % (file)
+            elif file.endswith('.deb') or file.endswith('.ipk'):
+                cmd = 'ar -p %s data.tar.gz | zcat | tar --no-same-owner -xpf -' % file
 
         if not unpack or not cmd:
             # If file == dest, then avoid any copies, as we already put the file into dest!
@@ -1193,8 +1204,9 @@ class Fetch(object):
 
                     except BBFetchException as e:
                         if isinstance(e, ChecksumError):
-                            logger.warn("Checksum error encountered with download (will attempt other sources): %s" % str(e))
-                        if isinstance(e, NoChecksumError):
+                            logger.warn("Checksum failure encountered with download of %s - will attempt other sources if available" % u)
+                            logger.debug(1, str(e))
+                        elif isinstance(e, NoChecksumError):
                             raise
                         else:
                             logger.warn('Failed to fetch URL %s, attempting MIRRORS if available' % u)
@@ -1216,6 +1228,8 @@ class Fetch(object):
             except BBFetchException as e:
                 if isinstance(e, NoChecksumError):
                     logger.error("%s" % str(e))
+                elif isinstance(e, ChecksumError):
+                    logger.error("Checksum failure fetching %s" % u)
                 raise
 
             finally:

bitbake/lib/bb/fetch2/cvs.py

@@ -29,7 +29,6 @@ BitBake build tools.
 import os
 import logging
 import bb
-from   bb import data
 from bb.fetch2 import FetchMethod, FetchError, MissingParameterError, logger
 from bb.fetch2 import runfetchcmd
 
@@ -64,7 +63,7 @@ class Cvs(FetchMethod):
         if 'fullpath' in ud.parm:
             fullpath = '_fullpath'
 
-        ud.localfile = data.expand('%s_%s_%s_%s%s%s.tar.gz' % (ud.module.replace('/', '.'), ud.host, ud.tag, ud.date, norecurse, fullpath), d)
+        ud.localfile = bb.data.expand('%s_%s_%s_%s%s%s.tar.gz' % (ud.module.replace('/', '.'), ud.host, ud.tag, ud.date, norecurse, fullpath), d)
 
     def need_update(self, url, ud, d):
         if (ud.date == "now"):
@@ -88,10 +87,10 @@ class Cvs(FetchMethod):
             cvsroot = ud.path
         else:
             cvsroot = ":" + method
-            cvsproxyhost = data.getVar('CVS_PROXY_HOST', d, True)
+            cvsproxyhost = d.getVar('CVS_PROXY_HOST', True)
             if cvsproxyhost:
                 cvsroot += ";proxy=" + cvsproxyhost
-            cvsproxyport = data.getVar('CVS_PROXY_PORT', d, True)
+            cvsproxyport = d.getVar('CVS_PROXY_PORT', True)
             if cvsproxyport:
                 cvsroot += ";proxyport=" + cvsproxyport
             cvsroot += ":" + ud.user
@@ -112,8 +111,8 @@ class Cvs(FetchMethod):
             options.append("-r %s" % ud.tag)
 
         cvsbasecmd = d.getVar("FETCHCMD_cvs", True)
-        cvscmd = cvsbasecmd + "'-d" + cvsroot + "' co " + " ".join(options) + " " + ud.module
-        cvsupdatecmd = cvsbasecmd + "'-d" + cvsroot + "' update -d -P " + " ".join(options)
+        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)
@@ -121,8 +120,8 @@ class Cvs(FetchMethod):
 
         # create module directory
         logger.debug(2, "Fetch: checking for module directory")
-        pkg = data.expand('${PN}', d)
-        pkgdir = os.path.join(data.expand('${CVSDIR}', localdata), pkg)
+        pkg = d.getVar('PN', True)
+        pkgdir = os.path.join(d.getVar('CVSDIR', True), pkg)
         moddir = os.path.join(pkgdir, localdir)
         if os.access(os.path.join(moddir, 'CVS'), os.R_OK):
             logger.info("Update " + loc)
@@ -163,12 +162,9 @@ class Cvs(FetchMethod):
 
     def clean(self, ud, d):
         """ Clean CVS Files and tarballs """
-        
-        pkg = data.expand('${PN}', d)
-        localdata = data.createCopy(d)
-        data.setVar('OVERRIDES', "cvs:%s" % data.getVar('OVERRIDES', localdata), localdata)
-        data.update_data(localdata)
-        pkgdir = os.path.join(data.expand('${CVSDIR}', localdata), pkg)
+
+        pkg = d.getVar('PN', True)
+        pkgdir = os.path.join(d.getVar("CVSDIR", True), pkg)
 
         bb.utils.remove(pkgdir, True)
         bb.utils.remove(ud.localpath)

bitbake/lib/bb/fetch2/git.py

@@ -257,6 +257,7 @@ class Git(FetchMethod):
             indirectiondir = destdir[:-1] + ".indirectionsymlink"
             if os.path.exists(indirectiondir):
                 os.remove(indirectiondir)
+            bb.utils.mkdirhier(os.path.dirname(indirectiondir))
             os.symlink(ud.clonedir, indirectiondir)
             clonedir = indirectiondir
 

bitbake/lib/bb/fetch2/wget.py

@@ -49,6 +49,9 @@ class Wget(FetchMethod):
         return True
 
     def urldata_init(self, ud, d):
+        if 'protocol' in ud.parm:
+            if ud.parm['protocol'] == 'git':
+                raise bb.fetch2.ParameterError("Invalid protocol - if you wish to fetch from a git repository using http, you need to instead use the git:// prefix with protocol=http", ud.url)
 
         if 'downloadfilename' in ud.parm:
             ud.basename = ud.parm['downloadfilename']

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

@@ -29,7 +29,7 @@ import logging
 import bb.utils
 from bb.parse import ParseError, resolve_file, ast, logger
 
-__config_regexp__  = re.compile( r"(?P<exp>export\s*)?(?P<var>[a-zA-Z0-9\-_+.${}/]+)(\[(?P<flag>[a-zA-Z0-9\-_+.]+)\])?\s*((?P<colon>:=)|(?P<lazyques>\?\?=)|(?P<ques>\?=)|(?P<append>\+=)|(?P<prepend>=\+)|(?P<predot>=\.)|(?P<postdot>\.=)|=)\s*(?P<apo>['\"])(?P<value>.*)(?P=apo)$")
+__config_regexp__  = re.compile( r"(?P<exp>export\s*)?(?P<var>[a-zA-Z0-9\-_+.${}/]+)(\[(?P<flag>[a-zA-Z0-9\-_+.]+)\])?\s*((?P<colon>:=)|(?P<lazyques>\?\?=)|(?P<ques>\?=)|(?P<append>\+=)|(?P<prepend>=\+)|(?P<predot>=\.)|(?P<postdot>\.=)|=)\s*(?!'[^']*'[^']*'$)(?!\"[^\"]*\"[^\"]*\"$)(?P<apo>['\"])(?P<value>.*)(?P=apo)$")
 __include_regexp__ = re.compile( r"include\s+(.+)" )
 __require_regexp__ = re.compile( r"require\s+(.+)" )
 __export_regexp__ = re.compile( r"export\s+([a-zA-Z0-9\-_+.${}/]+)$" )

bitbake/lib/bb/providers.py

@@ -130,7 +130,7 @@ def findPreferredProvider(pn, cfgData, dataCache, pkg_pn = None, item = None):
         m = re.match('(\d+:)*(.*)(_.*)*', preferred_v)
         if m:
             if m.group(1):
-                preferred_e = int(m.group(1)[:-1])
+                preferred_e = m.group(1)[:-1]
             else:
                 preferred_e = None
             preferred_v = m.group(2)

bitbake/lib/bb/runqueue.py

@@ -466,7 +466,7 @@ class RunQueueData:
                 # (makes sure sometask runs after targetname's someothertask)
                 idepends = taskData.tasks_idepends[task]
                 for (depid, idependtask) in idepends:
-                    if depid in taskData.build_targets:
+                    if depid in taskData.build_targets and not depid in taskData.failed_deps:
                         # Won't be in build_targets if ASSUME_PROVIDED
                         depdata = taskData.build_targets[depid][0]
                         if depdata is not None:
@@ -692,13 +692,14 @@ class RunQueueData:
             stampfnwhitelist.append(fn)
         self.stampfnwhitelist = stampfnwhitelist
 
-        # Interate over the task list looking for tasks with a 'setscene' function
+        # Iterate over the task list looking for tasks with a 'setscene' function
         self.runq_setscene = []
-        for task in range(len(self.runq_fnid)):
-            setscene = taskData.gettask_id(self.taskData.fn_index[self.runq_fnid[task]], self.runq_task[task] + "_setscene", False)
-            if not setscene:
-                continue
-            self.runq_setscene.append(task)
+        if not self.cooker.configuration.nosetscene:
+            for task in range(len(self.runq_fnid)):
+                setscene = taskData.gettask_id(self.taskData.fn_index[self.runq_fnid[task]], self.runq_task[task] + "_setscene", False)
+                if not setscene:
+                    continue
+                self.runq_setscene.append(task)
 
         def invalidate_task(fn, taskname, error_nostamp):
             taskdep = self.dataCache.task_deps[fn]
@@ -932,6 +933,8 @@ class RunQueue:
             return self._execute_runqueue()
         except bb.runqueue.TaskFailure:
             raise
+        except SystemExit:
+            raise
         except:
             logger.error("An uncaught exception occured in runqueue, please see the failure below:")
             self.state = runQueueComplete

bitbake/lib/bb/siggen.py

@@ -48,6 +48,9 @@ class SignatureGenerator(object):
     def stampfile(self, stampbase, file_name, taskname, extrainfo):
         return ("%s.%s.%s" % (stampbase, taskname, extrainfo)).rstrip('.')
 
+    def stampcleanmask(self, stampbase, file_name, taskname, extrainfo):
+        return ("%s.%s*.%s" % (stampbase, taskname, extrainfo)).rstrip('.')
+
     def dump_sigtask(self, fn, task, stampbase, runtime):
         return
 
@@ -185,8 +188,8 @@ class SignatureGeneratorBasic(SignatureGenerator):
         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
+                self.file_checksum_values[k][f] = cs
+                data = data + cs
 
         taint = self.read_taint(fn, task, dataCache.stamp[fn])
         if taint:
@@ -266,18 +269,24 @@ class SignatureGeneratorBasic(SignatureGenerator):
 class SignatureGeneratorBasicHash(SignatureGeneratorBasic):
     name = "basichash"
 
-    def stampfile(self, stampbase, fn, taskname, extrainfo):
+    def stampfile(self, stampbase, fn, taskname, extrainfo, clean=False):
         if taskname != "do_setscene" and taskname.endswith("_setscene"):
             k = fn + "." + taskname[:-9]
         else:
             k = fn + "." + taskname
-        if k in self.taskhash:
+        if clean:
+            h = "*"
+            taskname = taskname + "*"
+        elif k in self.taskhash:
             h = self.taskhash[k]
         else:
             # If k is not in basehash, then error
             h = self.basehash[k]
         return ("%s.%s.%s.%s" % (stampbase, taskname, h, extrainfo)).rstrip('.')
 
+    def stampcleanmask(self, stampbase, fn, taskname, extrainfo):
+        return self.stampfile(stampbase, fn, taskname, extrainfo, clean=True)
+        
     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)
@@ -290,7 +299,7 @@ def dump_this_task(outfile, d):
 
 def clean_basepath(a):
     if a.startswith("virtual:"):
-        b = a.rsplit(":", 1)[0] + a.rsplit("/", 1)[1]
+        b = a.rsplit(":", 1)[0] + ":" + a.rsplit("/", 1)[1]
     else:
         b = a.rsplit("/", 1)[1]
     return b
@@ -301,7 +310,9 @@ def clean_basepaths(a):
         b[clean_basepath(x)] = a[x]
     return b
 
-def compare_sigfiles(a, b):
+def compare_sigfiles(a, b, recursecb = None):
+    output = []
+
     p1 = pickle.Unpickler(open(a, "rb"))
     a_data = p1.load()
     p2 = pickle.Unpickler(open(b, "rb"))
@@ -320,114 +331,123 @@ def compare_sigfiles(a, b):
         return changed, added, removed
 
     if 'basewhitelist' in a_data and a_data['basewhitelist'] != b_data['basewhitelist']:
-        print "basewhitelist changed from %s to %s" % (a_data['basewhitelist'], b_data['basewhitelist'])
+        output.append("basewhitelist changed from %s to %s" % (a_data['basewhitelist'], b_data['basewhitelist']))
         if a_data['basewhitelist'] and b_data['basewhitelist']:
-            print "changed items: %s" % a_data['basewhitelist'].symmetric_difference(b_data['basewhitelist'])
+            output.append("changed items: %s" % a_data['basewhitelist'].symmetric_difference(b_data['basewhitelist']))
 
     if 'taskwhitelist' in a_data and a_data['taskwhitelist'] != b_data['taskwhitelist']:
-        print "taskwhitelist changed from %s to %s" % (a_data['taskwhitelist'], b_data['taskwhitelist'])
+        output.append("taskwhitelist changed from %s to %s" % (a_data['taskwhitelist'], b_data['taskwhitelist']))
         if a_data['taskwhitelist'] and b_data['taskwhitelist']:
-            print "changed items: %s" % a_data['taskwhitelist'].symmetric_difference(b_data['taskwhitelist'])
+            output.append("changed items: %s" % a_data['taskwhitelist'].symmetric_difference(b_data['taskwhitelist']))
 
     if a_data['taskdeps'] != b_data['taskdeps']:
-        print "Task dependencies changed from:\n%s\nto:\n%s" % (sorted(a_data['taskdeps']), sorted(b_data['taskdeps']))
+        output.append("Task dependencies changed from:\n%s\nto:\n%s" % (sorted(a_data['taskdeps']), sorted(b_data['taskdeps'])))
 
     if a_data['basehash'] != b_data['basehash']:
-        print "basehash changed from %s to %s" % (a_data['basehash'], b_data['basehash'])
+        output.append("basehash changed from %s to %s" % (a_data['basehash'], b_data['basehash']))
 
     changed, added, removed = dict_diff(a_data['gendeps'], b_data['gendeps'], a_data['basewhitelist'] & b_data['basewhitelist'])
     if changed:
         for dep in changed:
-            print "List of dependencies for variable %s changed from %s to %s" % (dep, a_data['gendeps'][dep], b_data['gendeps'][dep])
+            output.append("List of dependencies for variable %s changed from %s to %s" % (dep, a_data['gendeps'][dep], b_data['gendeps'][dep]))
             if a_data['gendeps'][dep] and b_data['gendeps'][dep]:
-                print "changed items: %s" % a_data['gendeps'][dep].symmetric_difference(b_data['gendeps'][dep])
+                output.append("changed items: %s" % a_data['gendeps'][dep].symmetric_difference(b_data['gendeps'][dep]))
     if added:
         for dep in added:
-            print "Dependency on variable %s was added" % (dep)
+            output.append("Dependency on variable %s was added" % (dep))
     if removed:
         for dep in removed:
-            print "Dependency on Variable %s was removed" % (dep)
+            output.append("Dependency on Variable %s was removed" % (dep))
 
 
     changed, added, removed = dict_diff(a_data['varvals'], b_data['varvals'])
     if changed:
         for dep in changed:
-            print "Variable %s value changed from %s to %s" % (dep, a_data['varvals'][dep], b_data['varvals'][dep])
+            output.append("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])
+            output.append("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)
+            output.append("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)
+            output.append("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'])
+        a = a_data['runtaskhashes']
+        b = b_data['runtaskhashes']
         changed, added, removed = dict_diff(a, b)
         if added:
             for dep in added:
-	        bdep_found = False
-	        if removed:
-		    for bdep in removed:
-		    	if a[dep] == b[bdep]:
-			   #print "Dependency on task %s was replaced by %s with same hash" % (dep, bdep)
-			   bdep_found = True
-		if not bdep_found:
-                    print "Dependency on task %s was added with hash %s" % (dep, a[dep])
+                bdep_found = False
+                if removed:
+                    for bdep in removed:
+                        if a[dep] == b[bdep]:
+                            #output.append("Dependency on task %s was replaced by %s with same hash" % (dep, bdep))
+                            bdep_found = True
+                if not bdep_found:
+                    output.append("Dependency on task %s was added with hash %s" % (clean_basepath(dep), a[dep]))
         if removed:
             for dep in removed:
-	        adep_found = False
-	        if added:
-		    for adep in added:
-		    	if a[adep] == b[dep]:
-			   #print "Dependency on task %s was replaced by %s with same hash" % (adep, dep)
-			   adep_found = True
-		if not adep_found:
-                   print "Dependency on task %s was removed with hash %s" % (dep, b[dep])
+                adep_found = False
+                if added:
+                    for adep in added:
+                        if a[adep] == b[dep]:
+                            #output.append("Dependency on task %s was replaced by %s with same hash" % (adep, dep))
+                            adep_found = True
+                if not adep_found:
+                    output.append("Dependency on task %s was removed with hash %s" % (clean_basepath(dep), b[dep]))
         if changed:
             for dep in changed:
-                print "Hash for dependent task %s changed from %s to %s" % (dep, a[dep], b[dep])
-
+                output.append("Hash for dependent task %s changed from %s to %s" % (clean_basepath(dep), a[dep], b[dep]))
+                if callable(recursecb):
+                    recout = recursecb(dep, a[dep], b[dep])
+                    if recout:
+                        output.extend(recout)
 
     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)
+        output.append("Taint (by forced/invalidated task) changed from %s to %s" % (a_taint, b_taint))
+
+    return output
 
 
 def dump_sigfile(a):
+    output = []
+
     p1 = pickle.Unpickler(open(a, "rb"))
     a_data = p1.load()
 
-    print "basewhitelist: %s" % (a_data['basewhitelist'])
+    output.append("basewhitelist: %s" % (a_data['basewhitelist']))
 
-    print "taskwhitelist: %s" % (a_data['taskwhitelist'])
+    output.append("taskwhitelist: %s" % (a_data['taskwhitelist']))
 
-    print "Task dependencies: %s" % (sorted(a_data['taskdeps']))
+    output.append("Task dependencies: %s" % (sorted(a_data['taskdeps'])))
 
-    print "basehash: %s" % (a_data['basehash'])
+    output.append("basehash: %s" % (a_data['basehash']))
 
     for dep in a_data['gendeps']:
-        print "List of dependencies for variable %s is %s" % (dep, a_data['gendeps'][dep])
+        output.append("List of dependencies for variable %s is %s" % (dep, a_data['gendeps'][dep]))
 
     for dep in a_data['varvals']:
-        print "Variable %s value is %s" % (dep, a_data['varvals'][dep])
+        output.append("Variable %s value is %s" % (dep, a_data['varvals'][dep]))
 
     if 'runtaskdeps' in a_data:
-        print "Tasks this task depends on: %s" % (a_data['runtaskdeps'])
+        output.append("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'])
+        output.append("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])
+            output.append("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']
+        output.append("Tainted (by forced/invalidated task): %s" % a_data['taint'])
+
+    return output

bitbake/lib/bb/tests/utils.py

@@ -34,3 +34,18 @@ class VerCmpString(unittest.TestCase):
         result = bb.utils.vercmp_string('1.1', '1_p2')
         self.assertTrue(result < 0)
 
+    def test_explode_dep_versions(self):
+        correctresult = {"foo" : ["= 1.10"]}
+        result = bb.utils.explode_dep_versions2("foo (= 1.10)")
+        self.assertEqual(result, correctresult)
+        result = bb.utils.explode_dep_versions2("foo (=1.10)")
+        self.assertEqual(result, correctresult)
+        result = bb.utils.explode_dep_versions2("foo ( = 1.10)")
+        self.assertEqual(result, correctresult)
+        result = bb.utils.explode_dep_versions2("foo ( =1.10)")
+        self.assertEqual(result, correctresult)
+        result = bb.utils.explode_dep_versions2("foo ( = 1.10 )")
+        self.assertEqual(result, correctresult)
+        result = bb.utils.explode_dep_versions2("foo ( =1.10 )")
+        self.assertEqual(result, correctresult)
+

bitbake/lib/bb/tinfoil.py

@@ -0,0 +1,98 @@
+# tinfoil: a simple wrapper around cooker for bitbake-based command-line utilities
+#
+# Copyright (C) 2012 Intel Corporation
+# Copyright (C) 2011 Mentor Graphics 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 logging
+import warnings
+import os
+import sys
+
+import bb.cache
+import bb.cooker
+import bb.providers
+import bb.utils
+from bb.cooker import state
+import bb.fetch2
+
+class Tinfoil:
+    def __init__(self):
+        # Needed to avoid deprecation warnings with python 2.6
+        warnings.filterwarnings("ignore", category=DeprecationWarning)
+
+        # Set up logging
+        self.logger = logging.getLogger('BitBake')
+        console = logging.StreamHandler(sys.stdout)
+        format = bb.msg.BBLogFormatter("%(levelname)s: %(message)s")
+        bb.msg.addDefaultlogFilter(console)
+        console.setFormatter(format)
+        self.logger.addHandler(console)
+
+        initialenv = os.environ.copy()
+        bb.utils.clean_environment()
+        self.config = TinfoilConfig(parse_only=True)
+        self.cooker = bb.cooker.BBCooker(self.config,
+                                            self.register_idle_function,
+                                            initialenv)
+        self.config_data = self.cooker.configuration.data
+        bb.providers.logger.setLevel(logging.ERROR)
+        self.cooker_data = None
+
+    def register_idle_function(self, function, data):
+        pass
+
+    def parseRecipes(self):
+        sys.stderr.write("Parsing recipes..")
+        self.logger.setLevel(logging.WARNING)
+
+        try:
+            while self.cooker.state in (state.initial, state.parsing):
+                self.cooker.updateCache()
+        except KeyboardInterrupt:
+            self.cooker.shutdown()
+            self.cooker.updateCache()
+            sys.exit(2)
+
+        self.logger.setLevel(logging.INFO)
+        sys.stderr.write("done.\n")
+
+        self.cooker_data = self.cooker.status
+
+    def prepare(self, config_only = False):
+        if not self.cooker_data:
+            if config_only:
+                self.cooker.parseConfiguration()
+                self.cooker_data = self.cooker.status
+            else:
+                self.parseRecipes()
+
+
+class TinfoilConfig(object):
+    def __init__(self, **options):
+        self.pkgs_to_build = []
+        self.debug_domains = []
+        self.extra_assume_provided = []
+        self.prefile = []
+        self.postfile = []
+        self.debug = 0
+        self.__dict__.update(options)
+
+    def __getattr__(self, attribute):
+        try:
+            return super(TinfoilConfig, self).__getattribute__(attribute)
+        except AttributeError:
+            return None
+

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

@@ -99,6 +99,8 @@ class BuildConfigurationTreeView(gtk.TreeView):
             import os, os.path
             if os.path.exists(path):
                 branch = bb.process.run('cd %s; git branch | grep "^* " | tr -d "* "' % path)[0]
+                if branch.startswith("fatal:"):
+                    branch = "(unknown)"
                 if branch:
                     branch = branch.strip('\n')
                     vars.append(self.set_vars("Branch:", branch))
@@ -165,7 +167,7 @@ class BuildDetailsPage (HobPage):
         self.builder.handler.build.model.connect_after("row-changed", self.scroll_to_present_row, self.scrolled_view_build.get_vadjustment(), self.build_tv)
 
         self.button_box = gtk.HBox(False, 6)
-        self.back_button = HobAltButton('<< Back')
+        self.back_button = HobAltButton('&lt;&lt; Back')
         self.back_button.connect("clicked", self.back_button_clicked_cb)
         self.button_box.pack_start(self.back_button, expand=False, fill=False)
 
@@ -206,7 +208,7 @@ class BuildDetailsPage (HobPage):
 
         color = HobColors.ERROR
         build_fail_top = gtk.EventBox()
-        build_fail_top.set_size_request(-1, 200)
+        #build_fail_top.set_size_request(-1, 200)
         build_fail_top.modify_bg(gtk.STATE_NORMAL, gtk.gdk.color_parse(color))
 
         build_fail_tab = gtk.Table(14, 46, True)
@@ -229,40 +231,103 @@ class BuildDetailsPage (HobPage):
 
         # create button 'Edit packages'
         action_button = HobButton(primary_action)
-        action_button.set_size_request(-1, 40)
+        #action_button.set_size_request(-1, 40)
+        action_button.set_tooltip_text("Edit the %s parameters" % actions)
         action_button.connect('clicked', self.failure_primary_action_button_clicked_cb, primary_action)
         build_fail_tab.attach(action_button, 4, 13, 9, 12)
 
         if log_file:
             open_log_button = HobAltButton("Open log")
             open_log_button.set_relief(gtk.RELIEF_HALF)
-            open_log_button.connect('clicked', self.failure_open_log_button_clicked_cb, log_file)
+            open_log_button.set_tooltip_text("Open the build's log file")
+            open_log_button.connect('clicked', self.open_log_button_clicked_cb, log_file)
             build_fail_tab.attach(open_log_button, 14, 23, 9, 12)
 
         attach_pos = (24 if log_file else 14)
         file_bug_button = HobAltButton('File a bug')
         file_bug_button.set_relief(gtk.RELIEF_HALF)
+        file_bug_button.set_tooltip_text("Open the Yocto Project bug tracking website")
         file_bug_button.connect('clicked', self.failure_activate_file_bug_link_cb)
         build_fail_tab.attach(file_bug_button, attach_pos, attach_pos + 9, 9, 12)
 
         return build_fail_top
 
-    def show_fail_page(self, title, action_names):
+    def show_fail_page(self, title):
         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.builder.current_logfile)
+        self.build_fail_bar = self.add_build_fail_top_bar(title, self.builder.current_logfile)
 
         self.pack_start(self.group_align, expand=True, fill=True)
         self.box_group_area.pack_start(self.build_fail_bar, expand=False, fill=False)
         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 add_build_stop_top_bar(self, action, log_file=None):
+        color = HobColors.LIGHT_GRAY
+        build_stop_top = gtk.EventBox()
+        #build_stop_top.set_size_request(-1, 200)
+        build_stop_top.modify_bg(gtk.STATE_NORMAL, gtk.gdk.color_parse(color))
+        build_stop_top.set_flags(gtk.CAN_DEFAULT)
+        build_stop_top.grab_default()
+
+        build_stop_tab = gtk.Table(11, 46, True)
+        build_stop_top.add(build_stop_tab)
+
+        icon = gtk.Image()
+        icon_pix_buffer = gtk.gdk.pixbuf_new_from_file(hic.ICON_INFO_HOVER_FILE)
+        icon.set_from_pixbuf(icon_pix_buffer)
+        build_stop_tab.attach(icon, 1, 4, 0, 6)
+
+        label = gtk.Label()
+        label.set_alignment(0.0, 0.5)
+        label.set_markup("<span size='x-large'><b>%s</b></span>" % self.title)
+        build_stop_tab.attach(label, 4, 26, 0, 6)
+
+        action_button = HobButton("Edit %s" % action)
+        action_button.set_size_request(-1, 40)
+        if action == "image":
+            action_button.set_tooltip_text("Edit the image parameters")
+        elif action == "recipes":
+            action_button.set_tooltip_text("Edit the included recipes")
+        elif action == "packages":
+            action_button.set_tooltip_text("Edit the included packages")
+        action_button.connect('clicked', self.stop_primary_action_button_clicked_cb, action)
+        build_stop_tab.attach(action_button, 4, 13, 6, 9)
+
+        if log_file:
+            open_log_button = HobAltButton("Open log")
+            open_log_button.set_relief(gtk.RELIEF_HALF)
+            open_log_button.set_tooltip_text("Open the build's log file")
+            open_log_button.connect('clicked', self.open_log_button_clicked_cb, log_file)
+            build_stop_tab.attach(open_log_button, 14, 23, 6, 9)
+
+        attach_pos = (24 if log_file else 14)
+        build_button = HobAltButton("Build new image")
+        #build_button.set_size_request(-1, 40)
+        build_button.set_tooltip_text("Create a new image from scratch")
+        build_button.connect('clicked', self.new_image_button_clicked_cb)
+        build_stop_tab.attach(build_button, attach_pos, attach_pos + 9, 6, 9)
+
+        return build_stop_top, action_button
+
+    def show_stop_page(self, action):
+        self._remove_all_widget()
+        self.title = "Build stopped"
+        self.build_stop_bar, action_button = self.add_build_stop_top_bar(action, self.builder.current_logfile)
+
+        self.pack_start(self.group_align, expand=True, fill=True)
+        self.box_group_area.pack_start(self.build_stop_bar, expand=False, fill=False)
+        self.box_group_area.pack_start(self.vbox, expand=True, fill=True)
+
+        self.vbox.pack_start(self.notebook, expand=True, fill=True)
+        self.show_all()
+        self.back_button.hide()
+        return action_button
+
     def show_page(self, step):
         self._remove_all_widget()
         if step == self.builder.PACKAGE_GENERATING or step == self.builder.FAST_IMAGE_GENERATING:
@@ -296,6 +361,9 @@ class BuildDetailsPage (HobPage):
     def back_button_clicked_cb(self, button):
         self.builder.show_configuration()
 
+    def new_image_button_clicked_cb(self, button):
+        self.builder.reset()
+
     def show_back_button(self):
         self.back_button.show()
 
@@ -322,10 +390,18 @@ class BuildDetailsPage (HobPage):
             self.builder.show_recipes()
         elif "Edit packages" in action:
             self.builder.show_packages()
-        elif "Edit image configuration" in action:
+        elif "Edit image" in action:
             self.builder.show_configuration()
 
-    def failure_open_log_button_clicked_cb(self, button, log_file):
+    def stop_primary_action_button_clicked_cb(self, button, action):
+        if "recipes" in action:
+            self.builder.show_recipes()
+        elif "packages" in action:
+            self.builder.show_packages(ask=False)
+        elif "image" in action:
+            self.builder.show_configuration()
+
+    def open_log_button_clicked_cb(self, button, log_file):
         if log_file:
             os.system("xdg-open /%s" % log_file)
 

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

@@ -21,23 +21,26 @@
 # with this program; if not, write to the Free Software Foundation, Inc.,
 # 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
 
-import gtk
+import glib
+import gtk, gobject
 import copy
 import os
 import subprocess
 import shlex
 import re
 import logging
+import sys
 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, hcc
+from bb.ui.crumbs.sanitycheckpage import SanityCheckPage
+from bb.ui.crumbs.hobwidget import hwc, HobButton, HobAltButton
 from bb.ui.crumbs.hig import CrumbsMessageDialog, ImageSelectionDialog, \
-                             AdvancedSettingDialog, LayerSelectionDialog, \
-                             DeployImageDialog
+                             AdvancedSettingDialog, SimpleSettingsDialog, \
+                             LayerSelectionDialog, DeployImageDialog
 from bb.ui.crumbs.persistenttooltip import PersistentTooltip
 import bb.ui.crumbs.utils
 
@@ -123,6 +126,8 @@ class Configuration:
         self.selected_image = None
         self.selected_recipes = []
         self.selected_packages = []
+        self.initial_selected_packages = []
+        self.initial_user_selected_packages = []
 
     def split_proxy(self, protocol, proxy):
         entry = []
@@ -184,7 +189,7 @@ class Configuration:
         self.curr_distro = template.getVar("DISTRO")
         self.dldir = template.getVar("DL_DIR")
         self.sstatedir = template.getVar("SSTATE_DIR")
-        self.sstatemirror = template.getVar("SSTATE_MIRROR")
+        self.sstatemirror = template.getVar("SSTATE_MIRRORS")
         try:
             self.pmake = int(template.getVar("PARALLEL_MAKE").split()[1])
         except:
@@ -234,7 +239,7 @@ class Configuration:
         template.setVar("DISTRO", self.curr_distro)
         template.setVar("DL_DIR", self.dldir)
         template.setVar("SSTATE_DIR", self.sstatedir)
-        template.setVar("SSTATE_MIRROR", self.sstatemirror)
+        template.setVar("SSTATE_MIRRORS", self.sstatemirror)
         template.setVar("PARALLEL_MAKE", "-j %s" % self.pmake)
         template.setVar("BB_NUMBER_THREADS", self.bbthread)
         template.setVar("PACKAGE_CLASSES", " ".join(["package_" + i for i in self.curr_package_format.split()]))
@@ -263,6 +268,22 @@ class Configuration:
         template.setVar("CVS_PROXY_HOST", self.combine_host_only("cvs"))
         template.setVar("CVS_PROXY_PORT", self.combine_port_only("cvs"))
 
+    def __str__(self):
+        s = "VERSION: '%s', BBLAYERS: '%s', MACHINE: '%s', DISTRO: '%s', DL_DIR: '%s'," % \
+            (hobVer, " ".join(self.layers), self.curr_mach, self.curr_distro, self.dldir )
+        s += "SSTATE_DIR: '%s', SSTATE_MIRROR: '%s', PARALLEL_MAKE: '-j %s', BB_NUMBER_THREADS: '%s', PACKAGE_CLASSES: '%s', " % \
+            (self.sstatedir, self.sstatemirror, self.pmake, self.bbthread, " ".join(["package_" + i for i in self.curr_package_format.split()]))
+        s += "IMAGE_ROOTFS_SIZE: '%s', IMAGE_EXTRA_SPACE: '%s', INCOMPATIBLE_LICENSE: '%s', SDKMACHINE: '%s', CONF_VERSION: '%s', " % \
+            (self.image_rootfs_size, self.image_extra_size, self.incompat_license, self.curr_sdk_machine, self.conf_version)
+        s += "LCONF_VERSION: '%s', EXTRA_SETTING: '%s', TOOLCHAIN_BUILD: '%s', IMAGE_FSTYPES: '%s', __SELECTED_IMAGE__: '%s', " % \
+            (self.lconf_version, self.extra_setting, self.toolchain_build, self.image_fstypes, self.selected_image)
+        s += "DEPENDS: '%s', IMAGE_INSTALL: '%s', enable_proxy: '%s', use_same_proxy: '%s', http_proxy: '%s', " % \
+            (self.selected_recipes, self.user_selected_packages, self.enable_proxy, self.same_proxy, self.combine_proxy("http"))
+        s += "https_proxy: '%s', ftp_proxy: '%s', GIT_PROXY_HOST: '%s', GIT_PROXY_PORT: '%s', CVS_PROXY_HOST: '%s', CVS_PROXY_PORT: '%s'" % \
+            (self.combine_proxy("https"), self.combine_proxy("ftp"),self.combine_host_only("git"), self.combine_port_only("git"),
+             self.combine_host_only("cvs"), self.combine_port_only("cvs"))
+        return s
+
 class Parameters:
     '''Represents other variables like available machines, etc.'''
 
@@ -323,7 +344,7 @@ def hob_conf_filter(fn, data):
 
         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"]
+                "SSTATE_DIR_HOB", "SSTATE_MIRRORS_HOB", "INCOMPATIBLE_LICENSE_HOB"]
         for key in keys:
             var_hob = data.getVar(key)
             if var_hob:
@@ -338,7 +359,8 @@ def hob_conf_filter(fn, data):
 
 class Builder(gtk.Window):
 
-    (MACHINE_SELECTION,
+    (INITIAL_CHECKS,
+     MACHINE_SELECTION,
      RCPPKGINFO_POPULATING,
      RCPPKGINFO_POPULATED,
      BASEIMG_SELECTED,
@@ -351,16 +373,18 @@ class Builder(gtk.Window):
      IMAGE_GENERATED,
      MY_IMAGE_OPENED,
      BACK,
-     END_NOOP) = range(14)
+     END_NOOP) = range(15)
 
-    (IMAGE_CONFIGURATION,
+    (SANITY_CHECK,
+     IMAGE_CONFIGURATION,
      RECIPE_DETAILS,
      BUILD_DETAILS,
      PACKAGE_DETAILS,
      IMAGE_DETAILS,
-     END_TAB) = range(6)
+     END_TAB) = range(7)
 
     __step2page__ = {
+        INITIAL_CHECKS        : SANITY_CHECK,
         MACHINE_SELECTION     : IMAGE_CONFIGURATION,
         RCPPKGINFO_POPULATING : IMAGE_CONFIGURATION,
         RCPPKGINFO_POPULATED  : IMAGE_CONFIGURATION,
@@ -376,14 +400,7 @@ 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
+    SANITY_CHECK_MIN_DISPLAY_TIME = 5
 
     def __init__(self, hobHandler, recipe_model, package_model):
         super(Builder, self).__init__()
@@ -457,8 +474,14 @@ class Builder(gtk.Window):
         self.set_title("Hob")
         self.set_icon_name("applications-development")
         self.set_resizable(True)
-        window_width = self.get_screen().get_width()
-        window_height = self.get_screen().get_height()
+
+        try:
+            window_width = self.get_screen().get_width()
+            window_height = self.get_screen().get_height()
+        except AttributeError:
+            print "Please set DISPLAY variable before running Hob."
+            sys.exit(1)
+
         if window_width >= hwc.MAIN_WIN_WIDTH:
             window_width = hwc.MAIN_WIN_WIDTH
             window_height = hwc.MAIN_WIN_HEIGHT
@@ -474,9 +497,14 @@ class Builder(gtk.Window):
         self.build_details_page       = BuildDetailsPage(self)
         self.package_details_page     = PackageSelectionPage(self)
         self.image_details_page       = ImageDetailsPage(self)
+        self.sanity_check_page        = SanityCheckPage(self)
+        self.display_sanity_check = False
+        self.sanity_check_post_func = False
+        self.had_network_error = False
 
         self.nb = gtk.Notebook()
         self.nb.set_show_tabs(False)
+        self.nb.insert_page(self.sanity_check_page,        None, self.SANITY_CHECK)
         self.nb.insert_page(self.image_configuration_page, None, self.IMAGE_CONFIGURATION)
         self.nb.insert_page(self.recipe_details_page,      None, self.RECIPE_DETAILS)
         self.nb.insert_page(self.build_details_page,       None, self.BUILD_DETAILS)
@@ -487,17 +515,46 @@ class Builder(gtk.Window):
         self.show_all()
         self.nb.set_current_page(0)
 
+    def sanity_check_timeout(self):
+        # The minimum time for showing the 'sanity check' page has passe
+        # If someone set the 'sanity_check_post_step' meanwhile, execute it now
+        self.display_sanity_check = False
+        if self.sanity_check_post_func:
+          temp = self.sanity_check_post_func
+          self.sanity_check_post_func = None
+          temp()
+        return False
+
+    def show_sanity_check_page(self):
+        # This window must stay on screen for at least 5 seconds, according to the design document
+        self.nb.set_current_page(self.SANITY_CHECK)
+        self.sanity_check_post_step = None
+        self.display_sanity_check = True
+        self.sanity_check_page.start()
+        gobject.timeout_add(self.SANITY_CHECK_MIN_DISPLAY_TIME * 1000, self.sanity_check_timeout)
+
+    def execute_after_sanity_check(self, func):
+        if not self.display_sanity_check:
+          func()
+        else:
+          sanity_check_post_func = func
+
+    def generate_configuration(self):
+        self.show_sanity_check_page()
+        self.handler.generate_configuration()
+
     def initiate_new_build_async(self):
         self.switch_page(self.MACHINE_SELECTION)
         if self.load_template(TemplateMgr.convert_to_template_pathfilename("default", ".hob/")) == False:
+            self.show_sanity_check_page()
             self.handler.init_cooker()
             self.handler.set_extra_inherit("image_types")
-            self.handler.generate_configuration()
+            self.generate_configuration()
 
     def update_config_async(self):
         self.switch_page(self.MACHINE_SELECTION)
         self.set_user_config()
-        self.handler.generate_configuration()
+        self.generate_configuration()
 
     def sanity_check(self):
         self.handler.trigger_sanity_check()
@@ -519,6 +576,13 @@ class Builder(gtk.Window):
         self.handler.reset_build()
         self.handler.generate_packages(all_recipes, self.configuration.default_task)
 
+    def restore_initial_selected_packages(self):
+        self.package_model.set_selected_packages(self.configuration.initial_user_selected_packages, True)
+        self.package_model.set_selected_packages(self.configuration.initial_selected_packages)
+        for package in self.configuration.selected_packages:
+            if package not in self.configuration.initial_selected_packages:
+                self.package_model.exclude_item(self.package_model.find_path_for_item(package))
+
     def fast_generate_image_async(self, log = False):
         self.switch_page(self.FAST_IMAGE_GENERATING)
         if log:
@@ -646,6 +710,9 @@ class Builder(gtk.Window):
                 self.recipe_details_page.set_recipe_curr_tab(self.recipe_details_page.INCLUDED)
 
         elif next_step == self.PACKAGE_SELECTION:
+            self.configuration.initial_selected_packages = self.configuration.selected_packages
+            self.configuration.initial_user_selected_packages = self.configuration.user_selected_packages
+            self.package_details_page.set_title("Edit packages")
             if self.recipe_model.get_selected_image() == self.recipe_model.__custom_image__:
                 self.package_details_page.set_packages_curr_tab(self.package_details_page.ALL)
             else:
@@ -658,6 +725,7 @@ class Builder(gtk.Window):
             self.build_details_page.show_page(next_step)
 
         elif next_step == self.PACKAGE_GENERATED:
+            self.package_details_page.set_title("Step 2 of 2: Edit packages")
             if self.recipe_model.get_selected_image() == self.recipe_model.__custom_image__:
                 self.package_details_page.set_packages_curr_tab(self.package_details_page.ALL)
             else:
@@ -688,7 +756,7 @@ class Builder(gtk.Window):
         self.handler.set_distro(self.configuration.curr_distro)
         self.handler.set_dl_dir(self.configuration.dldir)
         self.handler.set_sstate_dir(self.configuration.sstatedir)
-        self.handler.set_sstate_mirror(self.configuration.sstatemirror)
+        self.handler.set_sstate_mirrors(self.configuration.sstatemirror)
         self.handler.set_pmake(self.configuration.pmake)
         self.handler.set_bbthreads(self.configuration.bbthread)
         self.handler.set_rootfs_size(self.configuration.image_rootfs_size)
@@ -717,7 +785,10 @@ class Builder(gtk.Window):
         self.recipe_model.set_selected_image(selected_image)
         self.recipe_model.set_selected_recipes(selected_recipes)
 
-    def update_package_model(self, selected_packages):
+    def update_package_model(self, selected_packages, user_selected_packages=None):
+        if user_selected_packages:
+            left = self.package_model.set_selected_packages(user_selected_packages, True)
+            self.configuration.user_selected_packages += left
         left = self.package_model.set_selected_packages(selected_packages)
         self.configuration.selected_packages += left
 
@@ -745,12 +816,29 @@ class Builder(gtk.Window):
     def handler_package_formats_updated_cb(self, handler, formats):
         self.parameters.all_package_formats = formats
 
+    def switch_to_image_configuration_helper(self):
+        self.sanity_check_page.stop()
+        self.switch_page(self.IMAGE_CONFIGURATION)
+        self.image_configuration_page.switch_machine_combo()
+
+    def show_network_error_dialog_helper(self):
+        self.sanity_check_page.stop()
+        self.show_network_error_dialog()
+
     def handler_command_succeeded_cb(self, handler, initcmd):
         if initcmd == self.handler.GENERATE_CONFIGURATION:
+            if not self.configuration.curr_mach:
+                self.configuration.curr_mach = self.handler.runCommand(["getVariable", "HOB_MACHINE"]) or ""
             self.update_configuration_parameters(self.get_parameters_sync())
             self.sanity_check()
         elif initcmd == self.handler.SANITY_CHECK:
-            self.image_configuration_page.switch_machine_combo()
+            if self.had_network_error:
+                self.had_network_error = False
+                self.execute_after_sanity_check(self.show_network_error_dialog_helper)
+            else:
+                # Switch to the 'image configuration' page now, but we might need
+                # to wait for the minimum display time of the sanity check page
+                self.execute_after_sanity_check(self.switch_to_image_configuration_helper)
         elif initcmd in [self.handler.GENERATE_RECIPES,
                          self.handler.GENERATE_PACKAGES,
                          self.handler.GENERATE_IMAGE]:
@@ -767,23 +855,47 @@ class Builder(gtk.Window):
                 self.generate_image_async(True)
 
     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)
+        lbl = "<b>Hob found an error</b>\n"
+        dialog = CrumbsMessageDialog(self, lbl, gtk.STOCK_DIALOG_ERROR, msg)
         button = dialog.add_button("Close", gtk.RESPONSE_OK)
         HobButton.style_button(button)
         response = dialog.run()
         dialog.destroy()
 
+    def show_network_error_dialog(self):
+        lbl = "<b>Hob cannot connect to the network</b>\n"
+        msg = "Please check your network connection. If you are using a proxy server, please make sure it is configured correctly."
+        lbl = lbl + "%s\n\n" % glib.markup_escape_text(msg)
+        dialog = CrumbsMessageDialog(self, lbl, gtk.STOCK_DIALOG_ERROR)
+        button = dialog.add_button("Close", gtk.RESPONSE_OK)
+        HobButton.style_button(button)
+        button = dialog.add_button("Proxy settings", gtk.RESPONSE_CANCEL)
+        HobButton.style_button(button)
+        res = dialog.run()
+        dialog.destroy()
+        if res == gtk.RESPONSE_CANCEL:
+            res, settings_changed = self.show_simple_settings_dialog(SimpleSettingsDialog.PROXIES_PAGE_ID)
+            if not res:
+                return
+            if settings_changed:
+                self.reparse_post_adv_settings()
+
     def handler_command_failed_cb(self, handler, msg):
         if msg:
             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)
+    def handler_sanity_failed_cb(self, handler, msg, network_error):
         self.reset()
+        if network_error:
+            # Mark this in an internal field. The "network error" dialog will be
+            # shown later, when a SanityCheckPassed event will be handled
+            # (as sent by sanity.bbclass)
+            self.had_network_error = True
+        else:
+            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)
@@ -793,6 +905,7 @@ class Builder(gtk.Window):
         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)
+        self.image_configuration_page.view_adv_configuration_button.set_sensitive(sensitive)
         self.image_configuration_page.config_build_button.set_sensitive(sensitive)
 
         self.recipe_details_page.set_sensitive(sensitive)
@@ -801,9 +914,9 @@ class Builder(gtk.Window):
         self.image_details_page.set_sensitive(sensitive)
 
         if sensitive:
-            self.get_root_window().set_cursor(gtk.gdk.Cursor(gtk.gdk.LEFT_PTR))
+            self.window.set_cursor(None)
         else:
-            self.get_root_window().set_cursor(gtk.gdk.Cursor(gtk.gdk.WATCH))
+            self.window.set_cursor(gtk.gdk.Cursor(gtk.gdk.WATCH))
         self.sensitive = sensitive
 
 
@@ -817,11 +930,12 @@ class Builder(gtk.Window):
         selected_image = self.configuration.selected_image
         selected_recipes = self.configuration.selected_recipes[:]
         selected_packages = self.configuration.selected_packages[:]
+        user_selected_packages = self.configuration.user_selected_packages[:]
 
         self.image_configuration_page.update_image_combo(self.recipe_model, selected_image)
         self.image_configuration_page.update_image_desc()
         self.update_recipe_model(selected_image, selected_recipes)
-        self.update_package_model(selected_packages)
+        self.update_package_model(selected_packages, user_selected_packages)
 
     def recipelist_changed_cb(self, recipe_model):
         self.recipe_details_page.refresh_selection()
@@ -893,8 +1007,13 @@ class Builder(gtk.Window):
                 linkname = 'hob-image-' + self.configuration.curr_mach
             else:
                 linkname = selected_image + '-' + self.configuration.curr_mach
+            image_extension = self.get_image_extension()
             for image_type in self.parameters.image_types:
-                for real_image_type in hcc.SUPPORTED_IMAGE_TYPES[image_type]:
+                if image_type in image_extension:
+                    real_types = image_extension[image_type]
+                else:
+                    real_types = [image_type]
+                for real_image_type in real_types:
                     linkpath = self.parameters.image_addr + '/' + linkname + '.' + real_image_type
                     if os.path.exists(linkpath):
                         self.parameters.image_names.append(os.readlink(linkpath))
@@ -914,6 +1033,18 @@ class Builder(gtk.Window):
             status = "stop"
             message = "Build stopped: "
             fraction = self.build_details_page.progress_bar.get_fraction()
+            stop_to_next_edit = ""
+            if self.current_step == self.FAST_IMAGE_GENERATING:
+                stop_to_next_edit = "image configuration"
+            elif self.current_step == self.IMAGE_GENERATING:
+                if self.previous_step == self.FAST_IMAGE_GENERATING:
+                    stop_to_next_edit = "image configuration"
+                else:
+                    stop_to_next_edit = "packages"
+            elif self.current_step == self.PACKAGE_GENERATING:
+                stop_to_next_edit = "recipes"
+            button = self.build_details_page.show_stop_page(stop_to_next_edit.split(' ')[0])
+            self.set_default(button)
         else:
             fail_to_next_edit = ""
             if self.current_step == self.FAST_IMAGE_GENERATING:
@@ -928,7 +1059,7 @@ class Builder(gtk.Window):
             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)
+            self.build_details_page.show_fail_page(fail_to_next_edit.split(' ')[0])
             status = "fail"
             message = "Build failed: "
         self.build_details_page.update_progress_bar(message, fraction, status)
@@ -951,7 +1082,7 @@ class Builder(gtk.Window):
         self.build_failed()
 
     def handler_no_provider_cb(self, running_build, msg):
-        dialog = CrumbsMessageDialog(self, Builder.interpret_markup(msg), gtk.STOCK_DIALOG_INFO)
+        dialog = CrumbsMessageDialog(self, glib.markup_escape_text(msg), gtk.STOCK_DIALOG_INFO)
         button = dialog.add_button("Close", gtk.RESPONSE_OK)
         HobButton.style_button(button)
         dialog.run()
@@ -996,20 +1127,11 @@ class Builder(gtk.Window):
     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)
-        HobAltButton.style_button(button)
-        button = dialog.add_button("Exit Hob", gtk.RESPONSE_YES)
-        HobButton.style_button(button)
-        dialog.set_default_response(gtk.RESPONSE_YES)
-        response = dialog.run()
-        dialog.destroy()
-        if response == gtk.RESPONSE_YES:
-            gtk.main_quit()
-            return False
-        else:
+        elif self.handler.building:
+            self.stop_build()
             return True
+        else:
+            gtk.main_quit()
 
     def build_packages(self):
         _, all_recipes = self.recipe_model.get_selected_recipes()
@@ -1114,10 +1236,21 @@ class Builder(gtk.Window):
             self.save_template(path)
         dialog.destroy()
 
+    def get_image_extension(self):
+        image_extension = {}
+        for type in self.parameters.image_types:
+            ext = self.handler.runCommand(["getVariable", "IMAGE_EXTENSION_%s" % type])
+            if ext:
+                image_extension[type] = ext.split(' ')
+
+        return image_extension
+
     def show_load_my_images_dialog(self):
+        image_extension = self.get_image_extension()
         dialog = ImageSelectionDialog(self.parameters.image_addr, self.parameters.image_types,
                                       "Open My Images", self,
-                                       gtk.FILE_CHOOSER_ACTION_SAVE)
+                                       gtk.FILE_CHOOSER_ACTION_SAVE, None,
+                                       image_extension)
         button = dialog.add_button("Cancel", gtk.RESPONSE_NO)
         HobAltButton.style_button(button)
         button = dialog.add_button("Open", gtk.RESPONSE_YES)
@@ -1140,8 +1273,8 @@ class Builder(gtk.Window):
 
         dialog.destroy()
 
-    def show_adv_settings_dialog(self):
-        dialog = AdvancedSettingDialog(title = "Settings",
+    def show_adv_settings_dialog(self, tab=None):
+        dialog = AdvancedSettingDialog(title = "Advanced configuration",
             configuration = copy.deepcopy(self.configuration),
             all_image_types = self.parameters.image_types,
             all_package_formats = self.parameters.all_package_formats,
@@ -1156,6 +1289,34 @@ class Builder(gtk.Window):
         HobAltButton.style_button(button)
         button = dialog.add_button("Save", gtk.RESPONSE_YES)
         HobButton.style_button(button)
+        dialog.set_save_button(button)
+        response = dialog.run()
+        settings_changed = False
+        if response == gtk.RESPONSE_YES:
+            self.configuration = dialog.configuration
+            self.save_defaults() # remember settings
+            settings_changed = dialog.settings_changed
+        dialog.destroy()
+        return response == gtk.RESPONSE_YES, settings_changed
+
+    def show_simple_settings_dialog(self, tab=None):
+        dialog = SimpleSettingsDialog(title = "Settings",
+            configuration = copy.deepcopy(self.configuration),
+            all_image_types = self.parameters.image_types,
+            all_package_formats = self.parameters.all_package_formats,
+            all_distros = self.parameters.all_distros,
+            all_sdk_machines = self.parameters.all_sdk_machines,
+            max_threads = self.parameters.max_threads,
+            parent = self,
+            flags = gtk.DIALOG_MODAL
+                    | gtk.DIALOG_DESTROY_WITH_PARENT
+                    | gtk.DIALOG_NO_SEPARATOR)
+        button = dialog.add_button("Cancel", gtk.RESPONSE_NO)
+        HobAltButton.style_button(button)
+        button = dialog.add_button("Save", gtk.RESPONSE_YES)
+        HobButton.style_button(button)
+        if tab:
+            dialog.switch_to_page(tab)
         response = dialog.run()
         settings_changed = False
         if response == gtk.RESPONSE_YES:
@@ -1300,25 +1461,27 @@ class Builder(gtk.Window):
             HobButton.style_button(button)
         else:
             lbl = "<b>Stop build?</b>\n\nAre you sure you want to stop this"
-            lbl = lbl + " build?\n\n'Force Stop' will stop the build as quickly as"
-            lbl = lbl + " possible but may well leave your build directory in an"
-            lbl = lbl + " unusable state that requires manual steps to fix.\n\n"
-            lbl = lbl + "'Stop' will stop the build as soon as all in"
+            lbl = lbl + " build?\n\n'Stop' will stop the build as soon as all in"
             lbl = lbl + " progress build tasks are finished. However if a"
             lbl = lbl + " lengthy compilation phase is in progress this may take"
-            lbl = lbl + " some time."
+            lbl = lbl + " some time.\n\n"
+            lbl = lbl + "'Force Stop' will stop the build as quickly as"
+            lbl = lbl + " possible but may well leave your build directory in an"
+            lbl = lbl + " unusable state that requires manual steps to fix."
             dialog = CrumbsMessageDialog(self, lbl, gtk.STOCK_DIALOG_WARNING)
             button = dialog.add_button("Cancel", gtk.RESPONSE_CANCEL)
             HobAltButton.style_button(button)
-            button = dialog.add_button("Stop", gtk.RESPONSE_OK)
+            button = dialog.add_button("Force stop", gtk.RESPONSE_YES)
             HobAltButton.style_button(button)
-            button = dialog.add_button("Force Stop", gtk.RESPONSE_YES)
+            button = dialog.add_button("Stop", gtk.RESPONSE_OK)
             HobButton.style_button(button)
         response = dialog.run()
         dialog.destroy()
         if response != gtk.RESPONSE_CANCEL:
             self.stopping = True
         if response == gtk.RESPONSE_OK:
+            self.build_details_page.progress_bar.set_title("Stopping the build...")
+            self.build_details_page.progress_bar.set_rcstyle("stop")
             self.cancel_build_sync()
         elif response == gtk.RESPONSE_YES:
             self.cancel_build_sync(True)
@@ -1334,4 +1497,4 @@ class Builder(gtk.Window):
             format = bb.msg.BBLogFormatter("%(levelname)s: %(message)s")
             self.consolelog.setFormatter(format)
 
-            self.logger.addHandler(self.consolelog)
+            self.logger.addHandler(self.consolelog)

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

@@ -22,7 +22,6 @@
 import gobject
 import logging
 from bb.ui.crumbs.runningbuild import RunningBuild
-from bb.ui.crumbs.hobwidget import hcc
 
 class HobHandler(gobject.GObject):
 
@@ -44,7 +43,7 @@ class HobHandler(gobject.GObject):
                                      (gobject.TYPE_STRING,)),
          "sanity-failed"           : (gobject.SIGNAL_RUN_LAST,
                                       gobject.TYPE_NONE,
-                                     (gobject.TYPE_STRING,)),
+                                     (gobject.TYPE_STRING, gobject.TYPE_INT)),
          "generating-data"         : (gobject.SIGNAL_RUN_LAST,
                                       gobject.TYPE_NONE,
                                      ()),
@@ -102,7 +101,14 @@ class HobHandler(gobject.GObject):
 
     def runCommand(self, commandline):
         try:
-            return self.server.runCommand(commandline)
+            result = self.server.runCommand(commandline)
+            result_str = str(result)
+            if (result_str.startswith("Busy (") or
+                    result_str == "No such command"):
+                raise Exception('%s has failed with output "%s". ' %
+                        (str(commandline), result_str) +
+                        "We recommend that you restart Hob.")
+            return result
         except Exception as e:
             self.commands_async = []
             self.clear_busy()
@@ -157,10 +163,16 @@ class HobHandler(gobject.GObject):
                 targets.append(self.toolchain)
             self.runCommand(["buildTargets", targets, self.default_task])
 
+    def display_error(self):
+        self.clear_busy()
+        self.emit("command-failed", self.error_msg)
+        self.error_msg = ""
+        if self.building:
+            self.building = False
+
     def handle_event(self, event):
         if not event:
             return
-
         if self.building:
             self.current_phase = "building"
             self.build.handle_event(event)
@@ -174,11 +186,14 @@ class HobHandler(gobject.GObject):
             self.run_next_command()
 
         elif isinstance(event, bb.event.SanityCheckFailed):
-            self.emit("sanity-failed", event._msg)
+            self.emit("sanity-failed", event._msg, event._network_error)
 
         elif isinstance(event, logging.LogRecord):
-            if event.levelno >= logging.ERROR:
-                self.error_msg += event.msg + '\n'
+            if not self.building:
+                if event.levelno >= logging.ERROR:
+                    formatter = bb.msg.BBLogFormatter()
+                    msg = formatter.format(event)
+                    self.error_msg += msg + '\n'
 
         elif isinstance(event, bb.event.TargetsTreeGenerated):
             self.current_phase = "data generation"
@@ -210,11 +225,7 @@ class HobHandler(gobject.GObject):
             self.run_next_command()
         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
+            self.display_error()
         elif isinstance(event, (bb.event.ParseStarted,
                  bb.event.CacheLoadStarted,
                  bb.event.TreeDataPreparationStarted,
@@ -244,6 +255,9 @@ class HobHandler(gobject.GObject):
             message["title"] = "Parsing recipes: "
             self.emit("parsing-completed", message)
 
+        if self.error_msg and not self.commands_async:
+            self.display_error()
+
         return
 
     def init_cooker(self):
@@ -289,8 +303,8 @@ class HobHandler(gobject.GObject):
     def set_sstate_dir(self, directory):
         self.runCommand(["setVariable", "SSTATE_DIR_HOB", directory])
 
-    def set_sstate_mirror(self, url):
-        self.runCommand(["setVariable", "SSTATE_MIRROR_HOB", url])
+    def set_sstate_mirrors(self, url):
+        self.runCommand(["setVariable", "SSTATE_MIRRORS_HOB", url])
 
     def set_extra_size(self, image_extra_size):
         self.runCommand(["setVariable", "IMAGE_ROOTFS_EXTRA_SPACE", str(image_extra_size)])
@@ -413,7 +427,7 @@ class HobHandler(gobject.GObject):
         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 ""
+        params["sstatemirror"] = self.runCommand(["getVariable", "SSTATE_MIRRORS"]) or ""
 
         num_threads = self.runCommand(["getCpuCount"])
         if not num_threads:

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

@@ -42,7 +42,7 @@ class PackageListModel(gtk.TreeStore):
                                 ()),
     }
 
-    __toolchain_required_packages__ = ["task-core-standalone-sdk-target", "task-core-standalone-sdk-target-dbg"]
+    __toolchain_required_packages__ = ["packagegroup-core-standalone-sdk-target", "packagegroup-core-standalone-sdk-target-dbg"]
 
     def __init__(self):
 
@@ -145,6 +145,12 @@ class PackageListModel(gtk.TreeStore):
         self.pkg_path = {}
         self.rprov_pkg = {}
 
+        def getpkgvalue(pkgdict, key, pkgname, defaultval = None):
+            value = pkgdict.get('%s_%s' % (key, pkgname), None)
+            if not value:
+                value = pkgdict.get(key, defaultval)
+            return value
+
         for pkginfo in pkginfolist:
             pn = pkginfo['PN']
             pv = pkginfo['PV']
@@ -157,25 +163,24 @@ class PackageListModel(gtk.TreeStore):
                                  self.COL_INC, False)
                 self.pn_path[pn] = self.get_path(pniter)
 
+            # PKG is always present
             pkg = pkginfo['PKG']
-            pkgv = pkginfo['PKGV']
-            pkgr = pkginfo['PKGR']
-            pkgsize = pkginfo['PKGSIZE_%s' % pkg] if 'PKGSIZE_%s' % pkg in pkginfo.keys() else "0"
-            pkg_rename = pkginfo['PKG_%s' % pkg] if 'PKG_%s' % pkg in pkginfo.keys() else ""
-            section = pkginfo['SECTION_%s' % pkg] if 'SECTION_%s' % pkg in pkginfo.keys() else ""
-            summary = pkginfo['SUMMARY_%s' % pkg] if 'SUMMARY_%s' % pkg in pkginfo.keys() else ""
-            rdep = pkginfo['RDEPENDS_%s' % pkg] if 'RDEPENDS_%s' % pkg in pkginfo.keys() else ""
-            rrec = pkginfo['RRECOMMENDS_%s' % pkg] if 'RRECOMMENDS_%s' % pkg in pkginfo.keys() else ""
-            rprov = pkginfo['RPROVIDES_%s' % pkg] if 'RPROVIDES_%s' % pkg in pkginfo.keys() else ""
+            pkgv = getpkgvalue(pkginfo, 'PKGV', pkg)
+            pkgr = getpkgvalue(pkginfo, 'PKGR', pkg)
+            # PKGSIZE is artificial, will always be overridden with the package name if present
+            pkgsize = pkginfo.get('PKGSIZE_%s' % pkg, "0")
+            # PKG_%s is the renamed version
+            pkg_rename = pkginfo.get('PKG_%s' % pkg, "")
+            # The rest may be overridden or not
+            section = getpkgvalue(pkginfo, 'SECTION', pkg, "")
+            summary = getpkgvalue(pkginfo, 'SUMMARY', pkg, "")
+            rdep = getpkgvalue(pkginfo, 'RDEPENDS', pkg, "")
+            rrec = getpkgvalue(pkginfo, 'RRECOMMENDS', pkg, "")
+            rprov = getpkgvalue(pkginfo, 'RPROVIDES', pkg, "")
             for i in rprov.split():
                 self.rprov_pkg[i] = pkg
 
-            if 'ALLOW_EMPTY_%s' % pkg in pkginfo.keys():
-                allow_empty = pkginfo['ALLOW_EMPTY_%s' % pkg]
-            elif 'ALLOW_EMPTY' in pkginfo.keys():
-                allow_empty = pkginfo['ALLOW_EMPTY']
-            else:
-                allow_empty = ""
+            allow_empty = getpkgvalue(pkginfo, 'ALLOW_EMPTY', pkg, "")
 
             if pkgsize == "0" and not allow_empty:
                 continue
@@ -332,13 +337,13 @@ class PackageListModel(gtk.TreeStore):
     set_selected_packages(), some packages will not be set included.
     Return the un-set packages list.
     """
-    def set_selected_packages(self, packagelist):
+    def set_selected_packages(self, packagelist, user_selected=False):
         left = []
+        binb = 'User Selected' if user_selected else ''
         for pn in packagelist:
             if pn in self.pkg_path.keys():
                 path = self.pkg_path[pn]
-                self.include_item(item_path=path,
-                                  binb="User Selected")
+                self.include_item(item_path=path, binb=binb)
             else:
                 left.append(pn)
 
@@ -354,7 +359,7 @@ class PackageListModel(gtk.TreeStore):
             while child_it:
                 if self.get_value(child_it, self.COL_INC):
                     binb = self.get_value(child_it, self.COL_BINB)
-                    if not binb or binb == "User Selected":
+                    if binb == "User Selected":
                         name = self.get_value(child_it, self.COL_NAME)
                         packagelist.append(name)
                 child_it = self.iter_next(child_it)
@@ -521,17 +526,24 @@ class RecipeListModel(gtk.ListStore):
         val2 = model.get_value(iter2, RecipeListModel.COL_INC)
         return ((val1 == True) and (val2 == False))
 
+    def include_item_sort_func(self, model, iter1, iter2):
+        val1 = model.get_value(iter1, RecipeListModel.COL_INC)
+        val2 = model.get_value(iter2, RecipeListModel.COL_INC)
+        return ((val1 == False) and (val2 == True))
+
     """
     Create, if required, and return a filtered gtk.TreeModelSort
     containing only the items which are items specified by filter
     """
-    def tree_model(self, filter, excluded_items_ahead=False):
+    def tree_model(self, filter, excluded_items_ahead=False, included_items_ahead=True):
         model = self.filter_new()
         model.set_visible_func(self.tree_model_filter, filter)
 
         sort = gtk.TreeModelSort(model)
         if excluded_items_ahead:
             sort.set_default_sort_func(self.exclude_item_sort_func)
+        elif included_items_ahead:
+            sort.set_default_sort_func(self.include_item_sort_func)
         else:
             sort.set_sort_column_id(RecipeListModel.COL_NAME, gtk.SORT_ASCENDING)
             sort.set_default_sort_func(None)
@@ -583,8 +595,8 @@ class RecipeListModel(gtk.ListStore):
 
             depends = event_model["depends"].get(item, []) + event_model["rdepends-pn"].get(item, [])
 
-            if ('task-' in name):
-                atype = 'task'
+            if ('packagegroup.bbclass' in " ".join(inherits)):
+                atype = 'packagegroup'
             elif ('image.bbclass' in " ".join(inherits)):
                 if name != "hob-image":
                     atype = 'image'
@@ -660,6 +672,10 @@ class RecipeListModel(gtk.ListStore):
                         self[dep_path][self.COL_BINB] = ', '.join(dep_bin).lstrip(', ')
                 elif not dep_included:
                     self.include_item(dep_path, binb=item_name, image_contents=image_contents)
+        dep_bin = self[item_path][self.COL_BINB].split(', ')
+        if self[item_path][self.COL_NAME] in dep_bin:
+            dep_bin.remove(self[item_path][self.COL_NAME])
+        self[item_path][self.COL_BINB] = ', '.join(dep_bin).lstrip(', ')
 
     def exclude_item(self, item_path):
         if not self.path_included(item_path):

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

@@ -38,6 +38,7 @@ class HobPage (gtk.VBox):
             self.title = "Hob -- Image Creator"
         else:
             self.title = title
+        self.title_label = gtk.Label()
 
         self.box_group_area = gtk.VBox(False, 12)
         self.box_group_area.set_size_request(self.builder_width - 73 - 73, self.builder_height - 88 - 15 - 15)
@@ -46,6 +47,9 @@ class HobPage (gtk.VBox):
         self.group_align.add(self.box_group_area)
         self.box_group_area.set_homogeneous(False)
 
+    def set_title(self, title):
+        self.title = title
+        self.title_label.set_markup("<span size='x-large'>%s</span>" % self.title)
 
     def add_onto_top_bar(self, widget = None, padding = 0):
         # the top button occupies 1/7 of the page height
@@ -58,9 +62,9 @@ class HobPage (gtk.VBox):
 
         hbox = gtk.HBox()
 
-        label = gtk.Label()
-        label.set_markup("<span size='x-large'>%s</span>" % self.title)
-        hbox.pack_start(label, expand=False, fill=False, padding=20)
+        self.title_label = gtk.Label()
+        self.title_label.set_markup("<span size='x-large'>%s</span>" % self.title)
+        hbox.pack_start(self.title_label, expand=False, fill=False, padding=20)
 
         if widget:
             # add the widget in the event box

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

@@ -63,35 +63,6 @@ class hic:
     ICON_INDI_TICK_FILE           = os.path.join(HOB_ICON_BASE_DIR, ('indicators/tick.png'))
     ICON_INDI_INFO_FILE           = os.path.join(HOB_ICON_BASE_DIR, ('indicators/info.png'))
 
-class hcc:
-
-    SUPPORTED_IMAGE_TYPES = {
-        "jffs2"         : ["jffs2"],
-        "sum.jffs2"     : ["sum.jffs2"],
-        "cramfs"        : ["cramfs"],
-        "ext2"          : ["ext2"],
-        "ext2.gz"       : ["ext2.gz"],
-        "ext2.bz2"      : ["ext2.bz2"],
-        "ext3"          : ["ext3"],
-        "ext3.gz"       : ["ext3.gz"],
-        "ext2.lzma"     : ["ext2.lzma"],
-        "btrfs"         : ["btrfs"],
-        "live"          : ["hddimg", "iso"],
-        "squashfs"      : ["squashfs"],
-        "squashfs-lzma" : ["squashfs-lzma"],
-        "ubi"           : ["ubi"],
-        "tar"           : ["tar"],
-        "tar.gz"        : ["tar.gz"],
-        "tar.bz2"       : ["tar.bz2"],
-        "tar.xz"        : ["tar.xz"],
-        "cpio"          : ["cpio"],
-        "cpio.gz"       : ["cpio.gz"],
-        "cpio.xz"       : ["cpio.xz"],
-        "vmdk"          : ["vmdk"],
-        "cpio.lzma"     : ["cpio.lzma"],
-        "elf"           : ["elf"],
-    }
-
 class HobViewTable (gtk.VBox):
     """
     A VBox to contain the table for different recipe views and package view
@@ -182,7 +153,12 @@ class HobViewTable (gtk.VBox):
         # Just display the first item
         if binb:
             bin = binb.split(', ')
-            cell.set_property('text', bin[0])
+            total_no = len(bin)
+            if total_no > 1 and bin[0] == "User Selected":
+                present_binb = bin[1] + ' (+' + str(total_no) + ')'
+            else:
+                present_binb = bin[0] + ' (+' + str(total_no) + ')'
+            cell.set_property('text', present_binb)
         else:
             cell.set_property('text', "")
         return True
@@ -243,7 +219,7 @@ def soften_color(widget, state=gtk.STATE_NORMAL):
     color.blue = color.blue * blend + style.base[state].blue * (1.0 - blend)
     return color.to_string()
 
-class HobButton(gtk.Button):
+class BaseHobButton(gtk.Button):
     """
     A gtk.Button subclass which follows the visual design of Hob for primary
     action buttons
@@ -257,24 +233,33 @@ class HobButton(gtk.Button):
     @staticmethod
     def style_button(button):
         style = button.get_style()
-        button_color = gtk.gdk.Color(HobColors.ORANGE)
-        button.modify_bg(gtk.STATE_NORMAL, button_color)
-        button.modify_bg(gtk.STATE_PRELIGHT, button_color)
-        button.modify_bg(gtk.STATE_SELECTED, button_color)
+        style = gtk.rc_get_style_by_paths(gtk.settings_get_default(), 'gtk-button', 'gtk-button', gobject.TYPE_NONE)
 
         button.set_flags(gtk.CAN_DEFAULT)
         button.grab_default()
 
-        label = "<span size='x-large'><b>%s</b></span>" % gobject.markup_escape_text(button.get_label())
+#        label = "<span size='x-large'><b>%s</b></span>" % gobject.markup_escape_text(button.get_label())
+        label = button.get_label()
         button.set_label(label)
         button.child.set_use_markup(True)
 
-class HobAltButton(gtk.Button):
+class HobButton(BaseHobButton):
+    """
+    A gtk.Button subclass which follows the visual design of Hob for primary
+    action buttons
+
+    label: the text to display as the button's label
+    """
+    def __init__(self, label):
+        BaseHobButton.__init__(self, label)
+        HobButton.style_button(self)
+
+class HobAltButton(BaseHobButton):
     """
     A gtk.Button subclass which has no relief, and so is more discrete
     """
     def __init__(self, label):
-        gtk.Button.__init__(self, label)
+        BaseHobButton.__init__(self, label)
         HobAltButton.style_button(self)
 
     """
@@ -300,14 +285,6 @@ class HobAltButton(gtk.Button):
         button.set_label("<span size='large' color='%s'><b>%s</b></span>" % (colour, gobject.markup_escape_text(button.text)))
         button.child.set_use_markup(True)
 
-    @staticmethod
-    def style_button(button):
-        button.text = button.get_label()
-        button.connect("state-changed", HobAltButton.desensitise_on_state_change_cb)
-        HobAltButton.set_text(button)
-        button.child.set_use_markup(True)
-        button.set_relief(gtk.RELIEF_NONE)
-
 class HobImageButton(gtk.Button):
     """
     A gtk.Button with an icon and two rows of text, the second of which is
@@ -360,7 +337,8 @@ class HobInfoButton(gtk.EventBox):
     def __init__(self, tip_markup, parent=None):
         gtk.EventBox.__init__(self)
         self.image = gtk.Image()
-        self.image.set_from_file(hic.ICON_INFO_DISPLAY_FILE)
+        self.image.set_from_file(
+        hic.ICON_INFO_DISPLAY_FILE)
         self.image.show()
         self.add(self.image)
 

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

@@ -138,7 +138,6 @@ class ImageConfigurationPage (HobPage):
         self.show_all()
         if self.builder.recipe_model.get_selected_image() == self.builder.recipe_model.__custom_image__:
             self.just_bake_button.hide()
-            self.or_label.hide()
 
     def create_config_machine(self):
         self.machine_title = gtk.Label()
@@ -168,13 +167,12 @@ class ImageConfigurationPage (HobPage):
         markup += "dev-manual.html#understanding-and-using-layers\">reference manual</a>."
         self.layer_info_icon = HobInfoButton(markup, self.get_parent())
 
-        self.progress_box = gtk.HBox(False, 6)
+#        self.progress_box = gtk.HBox(False, 6)
         self.progress_bar = HobProgressBar()
-        self.progress_box.pack_start(self.progress_bar, expand=True, fill=True)
+#        self.progress_box.pack_start(self.progress_bar, expand=True, fill=True)
         self.stop_button = HobAltButton("Stop")
         self.stop_button.connect("clicked", self.stop_button_clicked_cb)
-        self.progress_box.pack_end(self.stop_button, expand=False, fill=False)
-
+#        self.progress_box.pack_end(stop_button, expand=False, fill=False)
         self.machine_separator = gtk.HSeparator()
 
     def set_config_machine_layout(self, show_progress_bar = False):
@@ -184,7 +182,9 @@ class ImageConfigurationPage (HobPage):
         self.gtable.attach(self.layer_button, 14, 36, 7, 12)
         self.gtable.attach(self.layer_info_icon, 36, 40, 7, 11)
         if show_progress_bar:
-            self.gtable.attach(self.progress_box, 0, 40, 15, 19)
+            #self.gtable.attach(self.progress_box, 0, 40, 15, 18)
+            self.gtable.attach(self.progress_bar, 0, 37, 15, 18)
+            self.gtable.attach(self.stop_button, 37, 40, 15, 18, 0, 0)
         self.gtable.attach(self.machine_separator, 0, 40, 13, 14)
 
     def create_config_baseimg(self):
@@ -205,17 +205,26 @@ class ImageConfigurationPage (HobPage):
 
         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_size_request(256, -1)
         self.image_desc.set_justify(gtk.JUSTIFY_LEFT)
         self.image_desc.set_line_wrap(True)
 
+        # button to view recipes
+        icon_file = hic.ICON_RCIPE_DISPLAY_FILE
+        hover_file = hic.ICON_RCIPE_HOVER_FILE
+        self.view_adv_configuration_button = HobImageButton("Advanced configuration",
+                                                                 "Select image types, package formats, etc",
+                                                                 icon_file, hover_file)        
+        self.view_adv_configuration_button.connect("clicked", self.view_adv_configuration_button_clicked_cb)
+
         self.image_separator = gtk.HSeparator()
 
     def set_config_baseimg_layout(self):
         self.gtable.attach(self.image_title, 0, 40, 15, 17)
         self.gtable.attach(self.image_title_desc, 0, 40, 18, 22)
         self.gtable.attach(self.image_combo, 0, 12, 23, 26)
-        self.gtable.attach(self.image_desc, 13, 38, 23, 28)
+        self.gtable.attach(self.image_desc, 0, 12, 27, 33)
+        self.gtable.attach(self.view_adv_configuration_button, 14, 36, 23, 28)
         self.gtable.attach(self.image_separator, 0, 40, 35, 36)
 
     def create_config_build_button(self):
@@ -224,18 +233,14 @@ class ImageConfigurationPage (HobPage):
 
         # create button "Build image"
         self.just_bake_button = HobButton("Build image")
-        self.just_bake_button.set_size_request(205, 49)
+        #self.just_bake_button.set_size_request(205, 49)
         self.just_bake_button.set_tooltip_text("Build target image")
         self.just_bake_button.connect("clicked", self.just_bake_button_clicked_cb)
         button_box.pack_end(self.just_bake_button, expand=False, fill=False)
 
-        # create separator label
-        self.or_label = gtk.Label(" or ")
-        button_box.pack_end(self.or_label, expand=False, fill=False)
-
         # create button "Edit Image"
-        self.edit_image_button = HobButton("Edit image")
-        self.edit_image_button.set_size_request(205, 49)
+        self.edit_image_button = HobAltButton("Edit image")
+        #self.edit_image_button.set_size_request(205, 49)
         self.edit_image_button.set_tooltip_text("Edit target image")
         self.edit_image_button.connect("clicked", self.edit_image_button_clicked_cb)
         button_box.pack_end(self.edit_image_button, expand=False, fill=False)
@@ -333,7 +338,6 @@ class ImageConfigurationPage (HobPage):
 
         if selected_image == self.builder.recipe_model.__custom_image__:
             self.just_bake_button.hide()
-            self.or_label.hide()
 
         glib.idle_add(self.image_combo_changed_idle_cb, selected_image, selected_recipes, selected_packages)
 
@@ -351,6 +355,7 @@ class ImageConfigurationPage (HobPage):
         # populate image combo
         filter = {RecipeListModel.COL_TYPE : ['image']}
         image_model = recipe_model.tree_model(filter)
+        image_model.set_sort_column_id(recipe_model.COL_NAME, gtk.SORT_ASCENDING)
         active = 0
         cnt = 1
 
@@ -363,6 +368,7 @@ class ImageConfigurationPage (HobPage):
         if self.builder.parameters.image_black_pattern:
             for i in self.builder.parameters.image_black_pattern.split():
                 black_pattern.append(re.compile(i))
+        black_pattern.append(re.compile("hob-image"))
 
         it = image_model.get_iter_first()
         self._image_combo_disconnect_signal()
@@ -413,6 +419,14 @@ class ImageConfigurationPage (HobPage):
     def layer_button_clicked_cb(self, button):
         # Create a layer selection dialog
         self.builder.show_layer_selection_dialog()
+        
+    def view_adv_configuration_button_clicked_cb(self, button):
+        # Create an advanced settings dialog
+        response, settings_changed = self.builder.show_adv_settings_dialog()
+        if not response:
+            return
+        if settings_changed:
+            self.builder.reparse_post_adv_settings()        
 
     def just_bake_button_clicked_cb(self, button):
         self.builder.just_bake()
@@ -432,7 +446,7 @@ class ImageConfigurationPage (HobPage):
 
     def settings_button_clicked_cb(self, button):
         # Create an advanced settings dialog
-        response, settings_changed = self.builder.show_adv_settings_dialog()
+        response, settings_changed = self.builder.show_simple_settings_dialog()
         if not response:
             return
         if settings_changed:

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

@@ -41,10 +41,10 @@ class ImageDetailsPage (HobPage):
             style.bg[gtk.STATE_NORMAL] = self.get_colormap().alloc_color(color, False, False)
             self.set_style(style)
 
-            self.hbox = gtk.HBox()
-            self.hbox.set_border_width(10)
-            self.add(self.hbox)
-
+            self.row = gtk.Table(1, 2, False)
+            self.row.set_border_width(10)
+            self.add(self.row)
+        
             total_rows = 0
             if widget:
                 total_rows = 10
@@ -54,8 +54,8 @@ class ImageDetailsPage (HobPage):
             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)
-
+            self.row.attach(self.table, 0, 1, 0, 1, xoptions=gtk.FILL|gtk.EXPAND, yoptions=gtk.FILL)
+            
             colid = 0
             rowid = 0
             self.line_widgets = {}
@@ -73,11 +73,80 @@ class ImageDetailsPage (HobPage):
             # pack the button on the right
             if button:
                 self.bbox = gtk.VBox()
-                self.bbox.pack_start(button, expand=True, fill=True)
+                self.bbox.pack_start(button, expand=True, fill=False)
                 if button2:
-                    self.bbox.pack_start(button2, expand=True, fill=True)
-                self.hbox.pack_end(self.bbox, expand=False, fill=False)
+                    self.bbox.pack_start(button2, expand=True, fill=False)
+                self.bbox.set_size_request(150,-1)
+                self.row.attach(self.bbox, 1, 2, 0, 1, xoptions=gtk.FILL, yoptions=gtk.EXPAND)
+                
+        def update_line_widgets(self, variable, value):
+            if len(self.line_widgets) == 0:
+                return
+            if not isinstance(self.line_widgets[variable], gtk.Label):
+                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>" % wraped_value
+            return markup
+
+        def text2label(self, variable, value):
+            # append the name:value to the left box
+            # such as "Name: hob-core-minimal-variant-2011-12-15-beagleboard"
+            label = gtk.Label()
+            label.set_alignment(0.0, 0.5)
+            label.set_markup(self.format_line(variable, value))
+            return label
+
+    class BuildDetailBox (gtk.EventBox):
+        def __init__(self, varlist = None, vallist = None, icon = None, color = HobColors.LIGHT_GRAY):
+            gtk.EventBox.__init__(self)
+
+            # set color
+            style = self.get_style().copy()
+            style.bg[gtk.STATE_NORMAL] = self.get_colormap().alloc_color(color, False, False)
+            self.set_style(style)
+
+            self.hbox = gtk.HBox()
+            self.hbox.set_border_width(10)
+            self.add(self.hbox)
+
+            total_rows = 0
+            if varlist and vallist:
+                # pack the icon and the text on the left
+                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 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)
+                
         def update_line_widgets(self, variable, value):
             if len(self.line_widgets) == 0:
                 return
@@ -183,7 +252,7 @@ class ImageDetailsPage (HobPage):
         self.pack_start(self.group_align, expand=True, fill=True)
 
         self.build_result = None
-        if self.build_succeeded:
+        if self.build_succeeded and self.builder.current_step == self.builder.IMAGE_GENERATING:
             # building is the previous step
             icon = gtk.Image()
             pixmap_path = hic.ICON_INDI_CONFIRM_FILE
@@ -192,7 +261,7 @@ class ImageDetailsPage (HobPage):
             icon.set_from_pixbuf(pix_buffer)
             varlist = [""]
             vallist = ["Your image is ready"]
-            self.build_result = self.DetailBox(varlist=varlist, vallist=vallist, icon=icon, color=color)
+            self.build_result = self.BuildDetailBox(varlist=varlist, vallist=vallist, icon=icon, color=color)
             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()
@@ -239,7 +308,7 @@ class ImageDetailsPage (HobPage):
         is_runnable = self.create_bottom_buttons(self.buttonlist, self.toggled_image)
 
         # Generated image files info
-        varlist = ["Name: ", "FileCreated: ", "Directory: "]
+        varlist = ["Name: ", "Files created: ", "Directory: "]
         vallist = []
 
         vallist.append(image_name.split('.')[0])
@@ -249,12 +318,12 @@ class ImageDetailsPage (HobPage):
         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")
-        view_log_button = None
+        open_log_button = None
         if log_file:
-            view_log_button = HobAltButton("View log")
-            view_log_button.connect("clicked", self.view_log_clicked_cb, log_file)
-            view_log_button.set_tooltip_text("Open the building log files")
-        self.image_detail = self.DetailBox(varlist=varlist, vallist=vallist, button=view_files_button, button2=view_log_button)
+            open_log_button = HobAltButton("Open log")
+            open_log_button.connect("clicked", self.open_log_clicked_cb, log_file)
+            open_log_button.set_tooltip_text("Open the build's log file")
+        self.image_detail = self.DetailBox(varlist=varlist, vallist=vallist, button=view_files_button, button2=open_log_button)
         self.box_group_area.pack_start(self.image_detail, expand=False, fill=True)
 
         # The default kernel box for the qemu images
@@ -263,15 +332,15 @@ class ImageDetailsPage (HobPage):
         if 'qemu' in image_name:
             self.sel_kernel = self.get_kernel_file_name()
 
-            varlist = ["Kernel: "]
-            vallist = []
-            vallist.append(self.sel_kernel)
+        #    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)
+        #    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=True, fill=True)
 
         # Machine, Base image and Layers
         layer_num_limit = 15
@@ -316,7 +385,7 @@ class ImageDetailsPage (HobPage):
         else: # get to this page from "My images"
             edit_packages_button = None
         self.package_detail = self.DetailBox(varlist=varlist, vallist=vallist, button=edit_packages_button)
-        self.box_group_area.pack_start(self.package_detail, expand=False, fill=False)
+        self.box_group_area.pack_start(self.package_detail, expand=True, fill=True)
 
         # pack the buttons at the bottom, at this time they are already created.
         if self.build_succeeded:
@@ -333,7 +402,7 @@ class ImageDetailsPage (HobPage):
     def view_files_clicked_cb(self, button, image_addr):
         subprocess.call("xdg-open /%s" % image_addr, shell=True)
 
-    def view_log_clicked_cb(self, button, log_file):
+    def open_log_clicked_cb(self, button, log_file):
         if log_file:
             os.system("xdg-open /%s" % log_file)
 
@@ -357,6 +426,8 @@ class ImageDetailsPage (HobPage):
         return mach_runnable
 
     def test_deployable(self, image_name):
+        if self.builder.configuration.curr_mach.startswith("qemu"):
+            return False
         deployable = False
         for t in self.builder.parameters.deployable_image_types:
             if image_name.endswith(t):
@@ -389,7 +460,13 @@ class ImageDetailsPage (HobPage):
         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)
+        label.set_padding(12,0)
+        if primary_action == "Run image":
+            label.set_markup("<span font_desc='12'>Select the image file you want to run:</span>")
+        elif primary_action == "Deploy image":
+            label.set_markup("<span font_desc='12'>Select the image file you want to deploy:</span>")
+        else:
+            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)
@@ -418,12 +495,12 @@ class ImageDetailsPage (HobPage):
             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)
+                table.attach(sel_btn, 0, 4, curr_row, curr_row + 1, xpadding=24)
             else:
-                table.attach(sel_btn, 7, 10, curr_row - 10, curr_row - 9)
+                table.attach(sel_btn, 5, 9, curr_row - 10, curr_row - 9, xpadding=24)
             curr_row += 1
 
-        dialog.vbox.pack_start(table, expand=False, fill=False, padding = 6)
+        dialog.vbox.pack_start(table, expand=False, fill=False, padding=6)
 
         button = dialog.add_button("Cancel", gtk.RESPONSE_CANCEL)
         HobAltButton.style_button(button)
@@ -472,7 +549,7 @@ class ImageDetailsPage (HobPage):
         name = "Deploy image"
         if name in buttonlist and self.test_deployable(image_name):
             deploy_button = HobButton('Deploy image')
-            deploy_button.set_size_request(205, 49)
+            #deploy_button.set_size_request(205, 49)
             deploy_button.set_tooltip_text("Burn a live image to a USB drive or flash memory")
             deploy_button.set_flags(gtk.CAN_DEFAULT)
             button_id = deploy_button.connect("clicked", self.deploy_button_clicked_cb)
@@ -485,15 +562,15 @@ class ImageDetailsPage (HobPage):
         if name in buttonlist and self.test_type_runnable(image_name) and self.test_mach_runnable(image_name):
             if created == True:
                 # separator
-                label = gtk.Label(" or ")
-                self.details_bottom_buttons.pack_end(label, expand=False, fill=False)
+                #label = gtk.Label(" or ")
+                #self.details_bottom_buttons.pack_end(label, expand=False, fill=False)
 
                 # create button "Run image"
                 run_button = HobAltButton("Run image")
             else:
                 # create button "Run image" as the primary button
                 run_button = HobButton("Run image")
-                run_button.set_size_request(205, 49)
+                #run_button.set_size_request(205, 49)
                 run_button.set_flags(gtk.CAN_DEFAULT)
                 packed = True
             run_button.set_tooltip_text("Start up an image with qemu emulator")
@@ -507,14 +584,14 @@ class ImageDetailsPage (HobPage):
         if name in buttonlist:
             if created == True:
                 # separator
-                label = gtk.Label(" or ")
-                self.details_bottom_buttons.pack_end(label, expand=False, fill=False)
+                #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")
             else:
                 save_button = HobButton("Save as template")
-                save_button.set_size_request(205, 49)
+                #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")
@@ -531,7 +608,7 @@ class ImageDetailsPage (HobPage):
             else:
                 build_new_button = HobButton("Build new image")
                 build_new_button.set_flags(gtk.CAN_DEFAULT)
-            build_new_button.set_size_request(205, 49)
+            #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)
@@ -581,7 +658,7 @@ class ImageDetailsPage (HobPage):
 
     def settings_button_clicked_cb(self, button):
         # Create an advanced settings dialog
-        response, settings_changed = self.builder.show_adv_settings_dialog()
+        response, settings_changed = self.builder.show_simple_settings_dialog()
         if not response:
             return
         if settings_changed:

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

@@ -34,12 +34,19 @@ class PackageSelectionPage (HobPage):
 
     pages = [
         {
-         'name'    : 'Included',
+         'name'    : 'Included packages',
+         'tooltip' : 'The packages currently included for your image',
          'filter'  : { PackageListModel.COL_INC : [True] },
          '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,
+                       'expand'   : 'True'
+                      }, {
+                       'col_name' : 'Size',
+                       'col_id'   : PackageListModel.COL_SIZE,
                        'col_style': 'text',
                        'col_min'  : 100,
                        'col_max'  : 300,
@@ -47,35 +54,24 @@ 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,
                        'expand'   : 'True'
-                      }, {
-                       'col_name' : 'Size',
-                       'col_id'   : PackageListModel.COL_SIZE,
-                       'col_t_id' : PackageListModel.COL_FONT,
-                       'col_style': 'text',
-                       'col_min'  : 100,
-                       'col_max'  : 300,
-                       'expand'   : 'True'
                       }, {
                        '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
                      }]
         }, {
          'name'    : 'All packages',
+         'tooltip' : 'All packages that have been built',
          'filter'  : {},
          '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,
@@ -83,7 +79,6 @@ 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,
@@ -92,7 +87,6 @@ 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
                       }]
@@ -131,16 +125,18 @@ 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":
+            if page['name'] == "Included packages":
                 tab.connect("button-release-event", self.button_click_cb)
                 tab.connect("cell-fadeinout-stopped", self.after_fadeout_checkin_include)
-            self.ins.append_page(tab, page['name'])
+            self.ins.append_page(tab, page['name'], page['tooltip'])
             self.tables.append(tab)
 
         self.ins.set_entry("Search packages:")
         # set the search entry for each table
         for tab in self.tables:
+            search_tip = "Enter a package name to find it"
+            self.ins.search.set_tooltip_text(search_tip)
+            self.ins.search.props.has_tooltip = True
             tab.set_search_entry(0, self.ins.search)
 
         # add all into the dialog
@@ -150,16 +146,16 @@ class PackageSelectionPage (HobPage):
         self.box_group_area.pack_start(self.button_box, expand=False, fill=False)
 
         self.build_image_button = HobButton('Build image')
-        self.build_image_button.set_size_request(205, 49)
+        #self.build_image_button.set_size_request(205, 49)
         self.build_image_button.set_tooltip_text("Build target image")
         self.build_image_button.set_flags(gtk.CAN_DEFAULT)
         self.build_image_button.grab_default()
         self.build_image_button.connect("clicked", self.build_image_clicked_cb)
         self.button_box.pack_end(self.build_image_button, expand=False, fill=False)
 
-        self.back_button = HobAltButton('<< Back')
+        self.back_button = HobAltButton('Cancel')
         self.back_button.connect("clicked", self.back_button_clicked_cb)
-        self.button_box.pack_start(self.back_button, expand=False, fill=False)
+        self.button_box.pack_end(self.back_button, expand=False, fill=False)
 
     def button_click_cb(self, widget, event):
         path, col = widget.table_tree.get_cursor()
@@ -169,7 +165,7 @@ class PackageSelectionPage (HobPage):
             if binb:
                 self.builder.show_binb_dialog(binb)
 
-    def view_log_clicked_cb(self, button, log_file):
+    def open_log_clicked_cb(self, button, log_file):
         if log_file:
             os.system("xdg-open /%s" % log_file)
 
@@ -177,25 +173,26 @@ class PackageSelectionPage (HobPage):
         children = self.button_box.get_children() or []
         for child in children:
             self.button_box.remove(child)
-        # re-packed the buttons as request, add the 'view log' button if build success
-        self.button_box.pack_start(self.back_button, expand=False, fill=False)
+        # re-packed the buttons as request, add the 'open log' button if build success
         self.button_box.pack_end(self.build_image_button, expand=False, fill=False)
         if log_file:
-            view_log_button = HobAltButton("View log")
-            view_log_button.connect("clicked", self.view_log_clicked_cb, log_file)
-            view_log_button.set_tooltip_text("Open the building log files")
-            self.button_box.pack_end(view_log_button, expand=False, fill=False)
-
+            open_log_button = HobAltButton("Open log")
+            open_log_button.connect("clicked", self.open_log_clicked_cb, log_file)
+            open_log_button.set_tooltip_text("Open the build's log file")
+            self.button_box.pack_end(open_log_button, expand=False, fill=False)
+        self.button_box.pack_end(self.back_button, expand=False, fill=False)
         self.show_all()
 
     def build_image_clicked_cb(self, button):
         self.builder.build_image()
 
     def back_button_clicked_cb(self, button):
-        if self.builder.current_step ==  self.builder.PACKAGE_GENERATED:
-            self.builder.show_recipes()
-        elif self.builder.previous_step ==  self.builder.IMAGE_GENERATED:
+        if self.builder.previous_step ==  self.builder.IMAGE_GENERATED:
+            self.builder.restore_initial_selected_packages()
+            self.refresh_selection()
             self.builder.show_image_details()
+        else:
+            self.builder.show_configuration()
 
     def _expand_all(self):
         for tab in self.tables:
@@ -221,13 +218,13 @@ class PackageSelectionPage (HobPage):
 
         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)
+        self.ins.show_indicator_icon("Included packages", selected_packages_num)
 
     def toggle_item_idle_cb(self, path, view_tree, cell, pagename):
         if not self.package_model.path_included(path):
             self.package_model.include_item(item_path=path, binb="User Selected")
         else:
-            if pagename == "Included":
+            if pagename == "Included packages":
                 self.pre_fadeout_checkout_include(view_tree)
                 self.package_model.exclude_item(item_path=path)
                 self.render_fadeout(view_tree, cell)
@@ -284,21 +281,6 @@ class PackageSelectionPage (HobPage):
         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)
-
     def set_packages_curr_tab(self, curr_page):
         self.ins.set_current_page(curr_page)
+

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

@@ -11,6 +11,9 @@ class ProgressBar(gtk.Dialog):
         self.vbox.pack_start(self.progress)
         self.show_all()
 
+    def set_text(self, msg):
+        self.progress.set_text(msg)
+
     def update(self, x, y):
         self.progress.set_fraction(float(x)/float(y))
         self.progress.set_text("%2d %%" % (x*100/y))

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

@@ -33,10 +33,10 @@ from bb.ui.crumbs.hobpages import HobPage
 class RecipeSelectionPage (HobPage):
     pages = [
         {
-         'name'    : 'Included',
+         'name'    : 'Included recipes',
          'tooltip' : 'The recipes currently included for your image',
          'filter'  : { RecipeListModel.COL_INC  : [True],
-                       RecipeListModel.COL_TYPE : ['recipe', 'task'] },
+                       RecipeListModel.COL_TYPE : ['recipe', 'packagegroup'] },
          'columns' : [{
                        'col_name' : 'Recipe name',
                        'col_id'   : RecipeListModel.COL_NAME,
@@ -44,13 +44,6 @@ class RecipeSelectionPage (HobPage):
                        'col_min'  : 100,
                        'col_max'  : 400,
                        'expand'   : 'True'
-                      }, {
-                       'col_name' : 'Brought in by',
-                       'col_id'   : RecipeListModel.COL_BINB,
-                       'col_style': 'binb',
-                       'col_min'  : 100,
-                       'col_max'  : 500,
-                       'expand'   : 'True'
                       }, {
                        'col_name' : 'Group',
                        'col_id'   : RecipeListModel.COL_GROUP,
@@ -58,6 +51,13 @@ class RecipeSelectionPage (HobPage):
                        'col_min'  : 100,
                        'col_max'  : 300,
                        'expand'   : 'True'
+                      }, {
+                       'col_name' : 'Brought in by',
+                       'col_id'   : RecipeListModel.COL_BINB,
+                       'col_style': 'binb',
+                       'col_min'  : 100,
+                       'col_max'  : 500,
+                       'expand'   : 'True'
                       }, {
                        'col_name' : 'Included',
                        'col_id'   : RecipeListModel.COL_INC,
@@ -67,7 +67,7 @@ class RecipeSelectionPage (HobPage):
                       }]
         }, {
          'name'    : 'All recipes',
-         'tooltip' : 'All recipes available in the Yocto Project',
+         'tooltip' : 'All recipes in your configured layers',
          'filter'  : { RecipeListModel.COL_TYPE : ['recipe'] },
          'columns' : [{
                        'col_name' : 'Recipe name',
@@ -76,6 +76,13 @@ class RecipeSelectionPage (HobPage):
                        'col_min'  : 100,
                        'col_max'  : 400,
                        'expand'   : 'True'
+                      }, {
+                       'col_name' : 'Group',
+                       'col_id'   : RecipeListModel.COL_GROUP,
+                       'col_style': 'text',
+                       'col_min'  : 100,
+                       'col_max'  : 400,
+                       'expand'   : 'True'
                       }, {
                        'col_name' : 'License',
                        'col_id'   : RecipeListModel.COL_LIC,
@@ -83,13 +90,6 @@ class RecipeSelectionPage (HobPage):
                        'col_min'  : 100,
                        'col_max'  : 400,
                        'expand'   : 'True'
-                      }, {
-                       'col_name' : 'Group',
-                       'col_id'   : RecipeListModel.COL_GROUP,
-                       'col_style': 'text',
-                       'col_min'  : 100,
-                       'col_max'  : 400,
-                       'expand'   : 'True'
                       }, {
                        'col_name' : 'Included',
                        'col_id'   : RecipeListModel.COL_INC,
@@ -98,23 +98,16 @@ class RecipeSelectionPage (HobPage):
                        'col_max'  : 100
                       }]
         }, {
-         'name'    : 'Tasks',
-         'tooltip' : 'All tasks available in the Yocto Project',
-         'filter'  : { RecipeListModel.COL_TYPE : ['task'] },
+         'name'    : 'Package Groups',
+         'tooltip' : 'All package groups in your configured layers',
+         'filter'  : { RecipeListModel.COL_TYPE : ['packagegroup'] },
          'columns' : [{
-                       'col_name' : 'Task name',
+                       'col_name' : 'Package group name',
                        'col_id'   : RecipeListModel.COL_NAME,
                        'col_style': 'text',
                        'col_min'  : 100,
                        'col_max'  : 400,
                        'expand'   : 'True'
-                      }, {
-                       'col_name' : 'Description',
-                       'col_id'   : RecipeListModel.COL_DESC,
-                       'col_style': 'text',
-                       'col_min'  : 100,
-                       'col_max'  : 400,
-                       'expand'   : 'True'
                       }, {
                        'col_name' : 'Included',
                        'col_id'   : RecipeListModel.COL_INC,
@@ -130,7 +123,7 @@ class RecipeSelectionPage (HobPage):
      TASKS) = range(3)
 
     def __init__(self, builder = None):
-        super(RecipeSelectionPage, self).__init__(builder, "Edit recipes")
+        super(RecipeSelectionPage, self).__init__(builder, "Step 1 of 2: Edit recipes")
 
         # set invisible members
         self.recipe_model = self.builder.recipe_model
@@ -156,7 +149,7 @@ class RecipeSelectionPage (HobPage):
             filter = page['filter']
             tab.set_model(self.recipe_model.tree_model(filter))
             tab.connect("toggled", self.table_toggled_cb, page['name'])
-            if page['name'] == "Included":
+            if page['name'] == "Included recipes":
                 tab.connect("button-release-event", self.button_click_cb)
                 tab.connect("cell-fadeinout-stopped", self.after_fadeout_checkin_include)
             self.ins.append_page(tab, page['name'], page['tooltip'])
@@ -177,16 +170,16 @@ class RecipeSelectionPage (HobPage):
         self.box_group_area.pack_end(button_box, expand=False, fill=False)
 
         self.build_packages_button = HobButton('Build packages')
-        self.build_packages_button.set_size_request(205, 49)
+        #self.build_packages_button.set_size_request(205, 49)
         self.build_packages_button.set_tooltip_text("Build selected recipes into packages")
         self.build_packages_button.set_flags(gtk.CAN_DEFAULT)
         self.build_packages_button.grab_default()
         self.build_packages_button.connect("clicked", self.build_packages_clicked_cb)
         button_box.pack_end(self.build_packages_button, expand=False, fill=False)
 
-        self.back_button = HobAltButton('<< Back')
+        self.back_button = HobAltButton('Cancel')
         self.back_button.connect("clicked", self.back_button_clicked_cb)
-        button_box.pack_start(self.back_button, expand=False, fill=False)
+        button_box.pack_end(self.back_button, expand=False, fill=False)
 
     def button_click_cb(self, widget, event):
         path, col = widget.table_tree.get_cursor()
@@ -205,13 +198,13 @@ 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.ins.show_indicator_icon("Included", len(self.builder.configuration.selected_recipes))
+        self.ins.show_indicator_icon("Included recipes", len(self.builder.configuration.selected_recipes))
 
     def toggle_item_idle_cb(self, path, view_tree, cell, pagename):
         if not self.recipe_model.path_included(path):
             self.recipe_model.include_item(item_path=path, binb="User Selected", image_contents=False)
         else:
-            if pagename == "Included":
+            if pagename == "Included recipes":
                 self.pre_fadeout_checkout_include(view_tree)
                 self.recipe_model.exclude_item(item_path=path)
                 self.render_fadeout(view_tree, cell)
@@ -243,7 +236,7 @@ class RecipeSelectionPage (HobPage):
         # Check out a model which base on the column COL_FADE_INC,
         # it's save the prev state of column COL_INC before do exclude_item
         filter = { RecipeListModel.COL_FADE_INC  : [True],
-                   RecipeListModel.COL_TYPE      : ['recipe', 'task'] }
+                   RecipeListModel.COL_TYPE      : ['recipe', 'packagegroup'] }
         new_model = self.recipe_model.tree_model(filter, excluded_items_ahead=True)
         tree.set_model(new_model)
 

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

@@ -374,7 +374,22 @@ class RunningBuild (gobject.GObject):
                 for reason in event._reasons:
                     msg += ("%s\n" % reason)
             self.emit("no-provider", msg)
-            self.emit("log", msg)
+            self.emit("log", "error", msg)
+        elif isinstance(event, bb.event.LogExecTTY):
+            icon = "dialog-warning"
+            color = HobColors.WARNING
+            if self.sequential or not parent:
+                tree_add = self.model.append
+            else:
+                tree_add = self.model.prepend
+            tree_add(parent,
+                     (None,
+                      package,
+                      task,
+                      event.msg,
+                      icon,
+                      color,
+                      0))
         else:
             if not isinstance(event, (bb.event.BuildBase,
                                       bb.event.StampUpdate,

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

@@ -0,0 +1,85 @@
+#!/usr/bin/env python
+#
+# BitBake Graphical GTK User Interface
+#
+# Copyright (C) 2012        Intel Corporation
+#
+# Authored by Bogdan Marinescu <bogdan.a.marinescu@intel.com>
+#
+# 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 gtk, gobject
+from bb.ui.crumbs.progressbar import HobProgressBar
+from bb.ui.crumbs.hobwidget import hic
+from bb.ui.crumbs.hobpages import HobPage
+
+#
+# SanityCheckPage
+#
+class SanityCheckPage (HobPage):
+
+    def __init__(self, builder):
+        super(SanityCheckPage, self).__init__(builder)
+        self.running = False
+        self.create_visual_elements()
+        self.show_all()
+
+    def make_label(self, text, bold=True):
+        label = gtk.Label()
+        label.set_alignment(0.0, 0.5)
+        mark = "<span %s>%s</span>" % (self.span_tag('x-large', 'bold') if bold else self.span_tag('medium'), text)
+        label.set_markup(mark)
+        return label
+
+    def start(self):
+        if not self.running:
+          self.running = True
+          gobject.timeout_add(100, self.timer_func)
+
+    def stop(self):
+        self.running = False
+
+    def is_running(self):
+        return self.running
+
+    def timer_func(self):
+        self.progress_bar.pulse()
+        return self.running
+
+    def create_visual_elements(self):
+        # Table'd layout. 'rows' and 'cols' give the table size
+        rows, cols = 30, 50
+        self.table = gtk.Table(rows, cols, True)
+        self.pack_start(self.table, expand=False, fill=False)
+        sx, sy = 2, 2
+        # 'info' icon
+        image = gtk.Image()
+        image.set_from_file(hic.ICON_INFO_DISPLAY_FILE)
+        self.table.attach(image, sx, sx + 2, sy, sy + 3 )
+        image.show()
+        # 'Checking' message
+        label = self.make_label('Hob is checking for correct build system setup')
+        self.table.attach(label, sx + 2, cols, sy, sy + 3, xpadding=5 )
+        label.show()
+        # 'Shouldn't take long' message.
+        label = self.make_label("The check shouldn't take long.", False)
+        self.table.attach(label, sx + 2, cols, sy + 3, sy + 4, xpadding=5)
+        label.show()
+        # Progress bar
+        self.progress_bar = HobProgressBar()
+        self.table.attach(self.progress_bar, sx + 2, cols - 3, sy + 5, sy + 7, xpadding=5)
+        self.progress_bar.show()
+        # All done
+        self.table.show()
+

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

@@ -137,7 +137,7 @@ class RecipeFile(ConfigFile):
 
 class TemplateMgr(gobject.GObject):
 
-    __gLocalVars__ = ["MACHINE", "PACKAGE_CLASSES", "DISTRO", "DL_DIR", "SSTATE_DIR", "SSTATE_MIRROR", "PARALLEL_MAKE", "BB_NUMBER_THREADS", "CONF_VERSION"]
+    __gLocalVars__ = ["MACHINE", "PACKAGE_CLASSES", "DISTRO", "DL_DIR", "SSTATE_DIR", "SSTATE_MIRRORS", "PARALLEL_MAKE", "BB_NUMBER_THREADS", "CONF_VERSION"]
     __gBBLayersVars__ = ["BBLAYERS", "LCONF_VERSION"]
     __gRecipeVars__ = ["DEPENDS", "IMAGE_INSTALL"]
 

bitbake/lib/bb/ui/depexp.py

@@ -220,7 +220,8 @@ def main(server, eventHandler):
 
     gtk.gdk.threads_enter()
     dep = DepExplorer()
-    bardialog = gtk.Dialog(parent=dep)
+    bardialog = gtk.Dialog(parent=dep,
+                           flags=gtk.DIALOG_MODAL|gtk.DIALOG_DESTROY_WITH_PARENT)
     bardialog.set_default_size(400, 50)
     pbar = HobProgressBar()
     bardialog.vbox.pack_start(pbar)

bitbake/lib/bb/ui/knotty.py

@@ -27,6 +27,7 @@ import logging
 import progressbar
 import signal
 import bb.msg
+import time
 import fcntl
 import struct
 import copy
@@ -182,11 +183,11 @@ class TerminalFilter(object):
         activetasks = self.helper.running_tasks
         failedtasks = self.helper.failed_tasks
         runningpids = self.helper.running_pids
-        if self.footer_present and (self.lastpids == runningpids):
+        if self.footer_present and (self.lastcount == self.helper.tasknumber_current) and (self.lastpids == runningpids):
             return
         if self.footer_present:
             self.clearFooter()
-        if not activetasks:
+        if not self.helper.tasknumber_total or self.helper.tasknumber_current == self.helper.tasknumber_total:
             return
         tasks = []
         for t in runningpids:
@@ -194,6 +195,8 @@ class TerminalFilter(object):
 
         if self.main.shutdown:
             content = "Waiting for %s running tasks to finish:" % len(activetasks)
+        elif not len(activetasks):
+            content = "No currently running tasks (%s of %s)" % (self.helper.tasknumber_current, self.helper.tasknumber_total)
         else:
             content = "Currently %s running tasks (%s of %s):" % (len(activetasks), self.helper.tasknumber_current, self.helper.tasknumber_total)
         print content
@@ -204,6 +207,7 @@ class TerminalFilter(object):
             lines = lines + 1 + int(len(content) / (self.columns + 1))
         self.footer_present = lines
         self.lastpids = runningpids[:]
+        self.lastcount = self.helper.tasknumber_current
 
     def finish(self):
         if self.stdinbackup:
@@ -216,6 +220,10 @@ def main(server, eventHandler, tf = TerminalFilter):
     includelogs = server.runCommand(["getVariable", "BBINCLUDELOGS"])
     loglines = server.runCommand(["getVariable", "BBINCLUDELOGS_LINES"])
     consolelogfile = server.runCommand(["getVariable", "BB_CONSOLELOG"])
+    if sys.stdin.isatty() and sys.stdout.isatty():
+        log_exec_tty = True
+    else:
+        log_exec_tty = False
 
     helper = uihelper.BBUIHelper()
 
@@ -271,6 +279,20 @@ def main(server, eventHandler, tf = TerminalFilter):
                 if not main.shutdown:
                     main.shutdown = 1
 
+            if isinstance(event, bb.event.LogExecTTY):
+                if log_exec_tty:
+                    tries = event.retries
+                    while tries:
+                        print "Trying to run: %s" % event.prog
+                        if os.system(event.prog) == 0:
+                            break
+                        time.sleep(event.sleep_delay)
+                        tries -= 1
+                    if tries:
+                        continue
+                logger.warn(event.msg)
+                continue
+
             if isinstance(event, logging.LogRecord):
                 if event.levelno >= format.ERROR:
                     errors = errors + 1

bitbake/lib/bb/ui/ncurses.py

@@ -318,6 +318,8 @@ class NCursesUI:
                 if isinstance(event, bb.cooker.CookerExit):
                     exitflag = True
 
+                if isinstance(event, bb.event.LogExecTTY):
+                    mw.appendText('WARN: ' + event.msg + '\n')
                 if helper.needUpdate:
                     activetasks, failedtasks = helper.getTasks()
                     taw.erase()

bitbake/lib/bb/utils.py

@@ -138,7 +138,7 @@ def explode_deps(s):
             #r[-1] += ' ' + ' '.join(j)
     return r
 
-def explode_dep_versions(s):
+def explode_dep_versions2(s):
     """
     Take an RDEPENDS style string of format:
     "DEPEND1 (optional version) DEPEND2 (optional version) ..."
@@ -147,24 +147,70 @@ def explode_dep_versions(s):
     r = {}
     l = s.replace(",", "").split()
     lastdep = None
+    lastcmp = ""
     lastver = ""
+    incmp = False
     inversion = False
     for i in l:
         if i[0] == '(':
-            inversion = True
-            lastver = i[1:] or ""
-            #j = []
-        elif inversion and i.endswith(')'):
-            inversion = False
-            lastver = lastver + " " + (i[:-1] or "")
-            r[lastdep] = lastver
-        elif not inversion:
-            r[i] = None
-            lastdep = i
-            lastver = ""
-        elif inversion:
-            lastver = lastver + " " + i
+            incmp = True
+            i = i[1:].strip()
+            if not i:
+                continue
 
+        if incmp:
+            incmp = False
+            inversion = True
+            # This list is based on behavior and supported comparisons from deb, opkg and rpm.
+            #
+            # Even though =<, <<, ==, !=, =>, and >> may not be supported, 
+            # we list each possibly valid item. 
+            # The build system is responsible for validation of what it supports.
+            if i.startswith(('<=', '=<', '<<', '==', '!=', '>=', '=>', '>>')):
+                lastcmp = i[0:2]
+                i = i[2:]
+            elif i.startswith(('<', '>', '=')):
+                lastcmp = i[0:1]
+                i = i[1:]
+            else:
+                # This is an unsupported case!
+                lastcmp = (i or "")
+                i = ""
+            i.strip()
+            if not i:
+                continue
+
+        if inversion:
+            if i.endswith(')'):
+                i = i[:-1] or ""
+                inversion = False
+                if lastver and i:
+                    lastver += " "
+            if i:
+                lastver += i
+                if lastdep not in r:
+                    r[lastdep] = []
+                r[lastdep].append(lastcmp + " " + lastver)
+            continue
+
+        #if not inversion:
+        lastdep = i
+        lastver = ""
+        lastcmp = ""
+        if not (i in r and r[i]):
+            r[lastdep] = []
+
+    return r
+
+def explode_dep_versions(s):
+    r = explode_dep_versions2(s)
+    for d in r:
+        if not r[d]:
+            r[d] = None
+            continue
+        if len(r[d]) > 1:
+            bb.warn("explode_dep_versions(): Item %s appeared in dependency string '%s' multiple times with different values.  explode_dep_versions cannot cope with this." % (d, s))
+        r[d] = r[d][0]
     return r
 
 def join_deps(deps, commasep=True):
@@ -174,7 +220,11 @@ def join_deps(deps, commasep=True):
     result = []
     for dep in deps:
         if deps[dep]:
-            result.append(dep + " (" + deps[dep] + ")")
+            if isinstance(deps[dep], list):
+                for v in deps[dep]:
+                    result.append(dep + " (" + v + ")")
+            else:
+                result.append(dep + " (" + deps[dep] + ")")
         else:
             result.append(dep)
     if commasep:

documentation/Makefile

@@ -24,13 +24,15 @@
 # manuals are being generated.  The variable BRANCH is used to indicate the 
 # branch (edison or denzil) and is used only when DOC=dev-manual or 
 # DOC=mega-manual.  If you do not specify a BRANCH, the default branch used 
-# will be for the latest Yocto Project release.  
+# will be for the latest Yocto Project release.  If you build for either 
+# edison or denzil, you must use BRANCH. You do not need to use BRANCH for
+# any release beyond denzil.  
 #
 # To build a manual, you must invoke Makefile with the DOC argument.  If you 
 # are going to publish the manual, then you must invoke Makefile with both the 
-# DOC and the VER argument.  If you are building a particular version of the 
-# Yocto Project Development Manual or you are building any version of the 
-# mega-manual, you must use the DOC and BRANCH arguments.  
+# DOC and the VER argument.  Furthermore, if you are building or publishing
+# the edison or denzil versions of the Yocto Poject Development Manual or 
+# the mega-manual, you must also use the BRANCH argument.  
 #
 # Examples:
 #
@@ -47,7 +49,8 @@
 # fourth example generates both the PDF and HTML 'edison' versions of the YP 
 # Development Manual.  The last exmample generates the HTML version of the 
 # mega-manual and uses the 'denzil' branch when choosing figures for the 
-# tarball of figures.
+# tarball of figures.  Any example that does not use the BRANCH argument 
+# builds the current version of the manual set.
 #
 # Use the publish target to push the generated manuals to the Yocto Project 
 # website.  All files needed for the manual's HTML form are pushed as well as the 
@@ -57,16 +60,13 @@
 #    make publish DOC=bsp-guide VER=1.3
 #    make publish DOC=adt-manual VER=1.3
 #    make publish DOC=dev-manual VER=1.1.1 BRANCH=edison
-#    make publish DOC=dev-manual VER=1.2 
-#    make publish DOC=mega-manual VER=1.3 BRANCH=denzil
+#    make publish DOC=dev-manual VER=1.2 BRANCH=denzil 
 #
-# The first example publishes the 1.2 version of both the PDF and HTML versions of 
-# the BSP Guide.  The second example publishes the 1.2 version of both the PDF and 
+# The first example publishes the 1.3 version of both the PDF and HTML versions of 
+# the BSP Guide.  The second example publishes the 1.3 version of both the PDF and 
 # HTML versions of the ADT Manual. The third example publishes the PDF and HTML
 # 'edison' versions of the YP Development Manual.  The fourth example publishes
-# the PDF and HTML 'master' versions of the YP Development Manual.  The last
-# example publishes the 1.3 version of the mega-manual (HTML-only) and the 
-# version generated and published is based on the 'denzil' branch.
+# the PDF and HTML 'denzil' versions of the YP Development Manual.
 #
 
 ifeq ($(DOC),bsp-guide)
@@ -119,9 +119,9 @@ TARFILES = dev-style.css dev-manual.html dev-manual.pdf \
 TARFILES = dev-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/kernel-example-repos-generic.png \
+           figures/kernel-overview-1.png figures/kernel-overview-2-generic.png \
+           figures/kernel-overview-3-generic.png \
            figures/source-repos.png figures/yp-download.png \
            figures/wip.png
 	endif
@@ -184,9 +184,9 @@ TARFILES = mega-manual.html mega-style.css figures/yocto-environment.png figures
 	figures/kernel-title.png figures/kernel-architecture-overview.png \
 	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/kernel-example-repos-generic.png \
+	figures/kernel-overview-1.png figures/kernel-overview-2-generic.png \
+	figures/kernel-overview-3-generic.png \
 	figures/source-repos.png figures/yp-download.png \
 	figures/wip.png
 	endif

documentation/README

@@ -49,6 +49,15 @@ is located in the tools directory.  Also note that the figures folder in the
 mega-manual directory contains duplicates of all the figures in the YP folders
 directories for all YP manuals and guides.
 
+If you want to find HTML versions of the Yocto Project manuals on the web, 
+go to http://www.yoctoproject.org and click on the "Documentation" tab.  From 
+there you have access to archived documentation from previous releases, current
+documentation for the latest release, and "Docs in Progress" for the release 
+currently being developed.
+
+In general, the Yocto Project site (http://www.yoctoproject.org) is a great 
+reference for both information and downloads.
+
 Makefile
 ========
 

documentation/adt-manual/adt-command.xml

@@ -32,7 +32,7 @@
         For an Autotools-based project, you can use the cross-toolchain by just 
         passing the appropriate host option to <filename>configure.sh</filename>.
         The host option you use is derived from the name of the environment setup 
-        script in <filename>/opt/poky</filename> resulting from unpacking the 
+        script in <filename>/opt/poky</filename> resulting from installation of the 
         cross-toolchain tarball.
         For example, the host option for an ARM-based target that uses the GNU EABI 
         is <filename>armv5te-poky-linux-gnueabi</filename>.

documentation/adt-manual/adt-intro.xml

@@ -54,8 +54,8 @@
         <para>
             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 build directory that is based on your metadata 
+            This toolchain is created either by running the ADT Installer script, a toolchain installer
+            script, or 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>

documentation/adt-manual/adt-prepare.xml

@@ -29,8 +29,7 @@
     <note>
         <para>Avoid mixing installation methods when installing toolchains 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. 
+        cross-development toolchains by running the toolchain installer 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 
@@ -46,9 +45,9 @@
                 For example, you can configure the installation to install the QEMU emulator
                 and the user-space NFS, specify which root filesystem profiles to download, 
                 and define the target sysroot location.</para></listitem>
-            <listitem><para><emphasis>Use an Existing Toolchain Tarball:</emphasis>
+            <listitem><para><emphasis>Use an Existing Toolchain:</emphasis>
                 Using this method, you select and download an architecture-specific
-                toolchain tarball and then hand-install the toolchain.
+                toolchain installer and then run the script to hand-install the toolchain.
                 If you use this method, you just get the cross-toolchain and QEMU - you do not 
                 get any of the other mentioned benefits had you run the ADT Installer script.</para></listitem>
             <listitem><para><emphasis>Use the Toolchain from within the Build Directory:</emphasis>
@@ -84,7 +83,7 @@
             <para>
                 If you use BitBake to generate the ADT Installer tarball, you must 
                 <filename>source</filename> the environment setup script 
-                (<filename>oe-init-build-env</filename>) located 
+                (<filename>&OE_INIT_FILE;</filename>) located 
                 in the source directory before running the <filename>bitbake</filename>
                 command that creates the tarball.
             </para>
@@ -188,6 +187,7 @@
                 When you run the installer, the environment must use a 
                 host <filename>gcc</filename>:
                 <literallayout class='monospaced'>
+     $ cd ~/adt-installer
      $ ./adt_installer
                 </literallayout>
             </para>
@@ -200,7 +200,10 @@
             </note>
 
             <para>
-                Once the installer begins to run, you are asked whether you want to run in 
+                Once the installer begins to run, you are asked to enter the location for 
+                cross-toolchain installation.
+                The default location is <filename>/opt/poky/&lt;release&gt;</filename>.
+                After selecting the location, you are prompted to run in  
                 interactive or silent mode.  
                 If you want to closely monitor the installation, choose “I” for interactive 
                 mode rather than “S” for silent mode.  
@@ -223,10 +226,12 @@
         <title>Using a Cross-Toolchain Tarball</title>
 
         <para>
-            If you want to simply install the cross-toolchain by hand, you can do so by using an existing 
-            cross-toolchain tarball.  
+            If you want to simply install the cross-toolchain by hand, you can do so by running the 
+            toolchain installer.  
             If you use this method to install the cross-toolchain and you still need to install the target 
-            sysroot, you will have to install sysroot separately.
+            sysroot, you will have to extract and install sysroot separately.
+            For information on how to do this, see the 
+            "<link linkend='extracting-the-root-filesystem'>Extracting the Root Filesystem</link>" section.
         </para>
 
         <para>
@@ -237,30 +242,43 @@
                     and find the folder that matches your host development system 
                     (i.e. <filename>i686</filename> for 32-bit machines or 
                     <filename>x86-64</filename> for 64-bit machines).</para></listitem>
-                <listitem><para>Go into that folder and download the toolchain tarball whose name 
+                <listitem><para>Go into that folder and download the toolchain installer whose name 
                     includes the appropriate target architecture.
                     For example, if your host development system is an Intel-based 64-bit system and 
                     you are going to use your cross-toolchain for an Intel-based 32-bit target, go into the 
-                    <filename>x86_64</filename> folder and download the following tarball:
+                    <filename>x86_64</filename> folder and download the following installer:
                     <literallayout class='monospaced'>
-     poky-eglibc-x86_64-i586-toolchain-gmae-&DISTRO;.tar.bz2
+     poky-eglibc-x86_64-i586-toolchain-gmae-&DISTRO;.sh
                     </literallayout>
-                    <note><para>As an alternative to steps one and two, you can build the toolchain tarball 
+                    <note><para>As an alternative to steps one and two, you can build the toolchain installer 
                         if you have a <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>.
                         If you need GMAE, you should use the <filename>bitbake meta-toolchain-gmae</filename>
                         command. 
-                        The resulting tarball will support such development.
+                        The resulting installation script when run will support such development.
                         However, if you are not concerned with GMAE, 
-                        you can generate the tarball using <filename>bitbake meta-toolchain</filename>.</para>
+                        you can generate the toolchain installer 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 source
                         directory.  
-                        When the <filename>bitbake</filename> command completes, the tarball will 
+                        When the <filename>bitbake</filename> command completes, the toolchain installer will 
                         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.  
-                    The tarball expands into <filename>&YOCTO_ADTPATH_DIR;</filename>.
+                        </para></note>
+                    </para></listitem>
+                <listitem><para>Once you have the installer, run it to install the toolchain.
+                    You must change the permissions on the toolchain installer 
+                    script so that it is executable.</para>
+                    <para>The following command shows how to run the installer given a toolchain tarball 
+                    for a 64-bit development host system and a 32-bit target architecture.
+                    The example assumes the toolchain installer is located in <filename>~/Downloads/</filename>.
+                    <literallayout class='monospaced'>
+     $ ~/Downloads/poky-eglibc-x86_64-i586-toolchain-gmae-&DISTRO;.sh
+                    </literallayout>
+                    <note>
+                        If you do not have write permissions for the directory into which you are installing 
+                        the toolchain, the toolchain installer notifies you and exits.  
+                        Be sure you have write permissions in the directory and run the installer again.
+                    </note>
                     Once the tarball is expanded, the cross-toolchain is installed.
                     You will notice environment setup files for the cross-toolchain in the directory.
                     </para></listitem>
@@ -285,7 +303,7 @@
             Follow these steps to generate the toolchain into the build directory:
             <orderedlist>
                 <listitem><para>Source the environment setup script 
-                    <filename>oe-init-build-env</filename> located in the 
+                    <filename>&OE_INIT_FILE;</filename> located in the 
                     <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>.
                     </para></listitem> 
                 <listitem><para>At this point, you should be sure that the 
@@ -312,7 +330,11 @@
                     the cross-toolchain is generated and populated within the build directory.
                     You will notice environment setup files for the cross-toolchain in the 
                     build directory in the <filename>tmp</filename> directory.
-                    Setup script filenames contain the strings <filename>environment-setup</filename>.
+                    Setup script filenames contain the strings <filename>environment-setup</filename>.</para>
+                    <para>Be aware that when you use this method to install the toolchain you still need
+                    to separately extract and install the sysroot filesystem.
+                    For information on how to do this, see the 
+                    "<link linkend='extracting-the-root-filesystem'>Extracting the Root Filesystem</link>" section.
                     </para></listitem>
             </orderedlist>
         </para>
@@ -383,7 +405,15 @@
         </para>
 
         <para>
-            If you plan on remotely deploying and debugging your application from within the 
+            If you are planning on developing against your image and you are not
+            building or using one of the Yocto Project development images 
+            (e.g. core-image-*-dev), you must be sure to include the development
+            packages as part of your image recipe.
+        </para>            
+
+        <para>
+            Furthermore, if you plan on remotely deploying and debugging your 
+            application from within the 
             Eclipse IDE, you must have an image that contains the Yocto Target Communication
             Framework (TCF) agent (<filename>tcf-agent</filename>). 
             By default, the Yocto Project provides only one type pre-built image that contains the 

documentation/bsp-guide/bsp.xml

@@ -56,6 +56,7 @@
      BBLAYERS = " \
         /usr/local/src/yocto/meta \
         /usr/local/src/yocto/meta-yocto \
+        /usr/local/src/yocto/meta-yocto-bsp \
         /usr/local/src/yocto/meta-<bsp_name> \
         "
                 </literallayout>
@@ -172,9 +173,6 @@
      meta-crownbay/recipes-bsp/formfactor/formfactor/crownbay/machconfig
      meta-crownbay/recipes-bsp/formfactor/formfactor/crownbay-noemgd/
      meta-crownbay/recipes-bsp/formfactor/formfactor/crownbay-noemgd/machconfig
-     meta-crownbay/recipes-core/
-     meta-crownbay/recipes-core/tasks/
-     meta-crownbay/recipes-core/tasks/task-core-tools-profile.bbappend
      meta-crownbay/recipes-graphics/
      meta-crownbay/recipes-graphics/xorg-xserver/
      meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
@@ -391,7 +389,7 @@
             <para>
                 Tuning files are found in the <filename>meta/conf/machine/include</filename>
                 directory within the 
-                <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>.
+                <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>.
@@ -443,31 +441,10 @@
                 formfactor recipe 
                 <filename>meta/recipes-bsp/formfactor/formfactor_0.0.bb</filename>, 
                 which is found in the 
-                <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>.
+                <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
             </para></note>
             </section>
 
-            <section id='bsp-filelayout-core-recipes'>
-            <title>Core Recipe Files</title>
-            <para>
-                You can find these files in the BSP Layer at:
-                <literallayout class='monospaced'>
-     meta-&lt;bsp_name&gt;/recipes-core/*
-                </literallayout> 
-            </para>
-
-            <para>
-                This directory contains recipe files that are almost always necessary to build a 
-                useful, working Linux image.
-                Thus, the term "core" is used to group these recipes.
-                For example, in the Crown Bay BSP there is the 
-                <filename>task-core-tools-profile.bbappend</filename> file, which is an append file used 
-                to recommend that the 
-                <ulink url='http://sourceware.org/systemtap/wiki'>SystemTap</ulink>
-                package be included as a package when the image is built.
-            </para>
-            </section>
-
             <section id='bsp-filelayout-recipes-graphics'>
             <title>Display Support Files</title>
             <para>
@@ -509,7 +486,7 @@
             </para>
             <para>
                 For your BSP, you typically want to use an existing Yocto Project kernel recipe found in the 
-                <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink> 
+                <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. 
@@ -581,7 +558,7 @@
                 to ensure the build process uses the <filename>standard/default/crownbay</filename>
                 kernel branch.
                 Finally, the append file points to the specific top commits in the 
-                <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</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>
@@ -641,13 +618,6 @@
                     <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. 
-                    For an example showing how to change the BSP configuration, see the
-                    "<ulink url='&YOCTO_DOCS_DEV_URL;#changing-the-bsp-configuration'>Changing the BSP Configuration</ulink>" 
-                    section in the Yocto Project Development Manual.
-                    For a better understanding of working with a local clone of the kernel repository
-                    and a local bare clone of the kernel, see the
-                    "<ulink url='&YOCTO_DOCS_DEV_URL;#modifying-the-kernel-source-code'>Modifying the Kernel
-                    Source Code</ulink>" section also in the Yocto Project Development Manual.
                 </para>
 
                 <para>
@@ -730,7 +700,7 @@
                             <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>, 
+                            <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>.
@@ -738,7 +708,7 @@
                             <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>).
+                            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
@@ -895,7 +865,7 @@
            <para>
                To better understand this, consider an example that customizes a recipe by adding 
                a BSP-specific configuration file named <filename>interfaces</filename> to the 
-               <filename>netbase_4.47.bb</filename> recipe for machine "xyz".
+               <filename>netbase_5.0.bb</filename> recipe for machine "xyz".
                Do the following:
                <orderedlist>
                    <listitem><para>Edit the <filename>netbase_4.47.bbappend</filename> file so that it 
@@ -1041,8 +1011,8 @@
 
             <para>
                 The following sections describe the common location and help features as well 
-                as details for the <filename>yocto-bsp</filename> and <filename>yocto-kernel</filename> 
-                tools.
+                as provide details for the 
+                <filename>yocto-bsp</filename> and <filename>yocto-kernel</filename> tools.
             </para>
 
             <section id='common-features'>
@@ -1061,7 +1031,7 @@
 
                 <para>
                     Both tools reside in the <filename>scripts/</filename> subdirectory 
-                    of the <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</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'>
@@ -1073,30 +1043,27 @@
                     The most immediately useful function is to get help on both tools.
                     The built-in help system makes it easy to drill down at
                     any time and view the syntax required for any specific command.
-                    Simply enter the name of the command, or the command along with 
-                    <filename>help</filename> to display a list of the available sub-commands. 
-                    Here is an example:
+                    Simply enter the name of the command with the <filename>help</filename>
+                    switch:
                     <literallayout class='monospaced'>
-     $ yocto-bsp
      $ yocto-bsp help
+     Usage: 
 
-     Usage:
+      Create a customized Yocto BSP layer.
 
-     Create a customized Yocto BSP layer.
+      usage: yocto-bsp [--version] [--help] COMMAND [ARGS]
 
-     usage: yocto-bsp [--version] [--help] COMMAND [ARGS]
+      Current 'yocto-bsp' commands are:
+         create            Create a new Yocto BSP
+         list              List available values for options and BSP properties
 
-     The most commonly used 'yocto-bsp' commands are:
-     create            Create a new Yocto BSP
-     list              List available values for options and BSP properties
-
-     See 'yocto-bsp help COMMAND' for more information on a specific command.
+      See 'yocto-bsp help COMMAND' for more information on a specific command.
 
 
      Options:
-     --version    show program's version number and exit
-     -h, --help   show this help message and exit
-     -D, --debug  output debug information
+       --version    show program's version number and exit
+       -h, --help   show this help message and exit
+       -D, --debug  output debug information
                     </literallayout>
                 </para>
 
@@ -1106,19 +1073,20 @@
                     <literallayout class='monospaced'>
      $ yocto-bsp create
 
-     Usage:
+     Usage: 
 
-     Create a new Yocto BSP
-     usage: yocto-bsp create &lt;bsp-name&gt; &lt;karch&gt; [-o &lt;DIRNAME&gt; | --outdir &lt;DIRNAME&gt;]
+      Create a new Yocto BSP
+
+      usage: yocto-bsp create &lt;bsp-name&gt; &lt;karch&gt; [-o &lt;DIRNAME&gt; | --outdir &lt;DIRNAME&gt;]
              [-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 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.
+      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 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.
 
-                 ...
+      ...
                     </literallayout>
                 </para>
 
@@ -1129,33 +1097,26 @@
      $ yocto-bsp help create
 
      NAME
-     yocto-bsp create - Create a new Yocto BSP
+         yocto-bsp create - Create a new Yocto BSP
 
      SYNOPSIS
-     yocto-bsp create &lt;bsp-name&gt; &lt;karch&gt; [-o &lt;DIRNAME&gt; | --outdir &lt;DIRNAME&gt;]
+         yocto-bsp create &lt;bsp-name&gt; &lt;karch&gt; [-o &lt;DIRNAME&gt; | --outdir &lt;DIRNAME&gt;]
              [-i &lt;JSON PROPERTY FILE&gt; | --infile &lt;JSON PROPERTY_FILE&gt;]
 
      DESCRIPTION
-     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 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.
-			    
-     The value of the 'karch' parameter determines the set of files
-     that will be generated for the BSP, along with the specific set of
-     'properties' that will be used to fill out the BSP-specific
-     portions of the BSP.
-			    
-     ...
-			    
-     NOTE: Once created, you should add your new layer to your
-     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
-     presence of the of the meta-intel layer, so you should also have a
-     meta-intel layer present and added to your bblayers.conf as well.
+         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 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.
+
+         The value of the 'karch' parameter determines the set of files
+         that will be generated for the BSP, along with the specific set of
+         'properties' that will be used to fill out the BSP-specific
+         portions of the BSP.  The possible values for the 'karch' paramter
+         can be listed via 'yocto-bsp list karch'.
+
+         ...
                     </literallayout>
                 </para>
 
@@ -1182,33 +1143,33 @@
                     For the current set of BSPs, the script prompts you for various important
                     parameters such as:
                     <itemizedlist>
-                        <listitem><para>which kernel to use</para></listitem>
-                        <listitem><para>which branch of that kernel to use (or re-use)</para></listitem>
-                        <listitem><para>whether or not to use X, and if so, which drivers to use</para></listitem>
-                        <listitem><para>whether to turn on SMP</para></listitem>
-                        <listitem><para>whether the BSP has a keyboard</para></listitem>
-                        <listitem><para>whether the BSP has a touchscreen</para></listitem>
-                        <listitem><para>any remaining configurable items associated with the BSP</para></listitem>
+                        <listitem><para>The kernel to use</para></listitem>
+                        <listitem><para>The branch of that kernel to use (or re-use)</para></listitem>
+                        <listitem><para>Whether or not to use X, and if so, which drivers to use</para></listitem>
+                        <listitem><para>Whether to turn on SMP</para></listitem>
+                        <listitem><para>Whether the BSP has a keyboard</para></listitem>
+                        <listitem><para>Whether the BSP has a touchscreen</para></listitem>
+                        <listitem><para>Remaining configurable items associated with the BSP</para></listitem>
                     </itemizedlist>
                 </para>
 
                 <para>
                     You use the <filename>yocto-bsp create</filename> sub-command to create 
                     a new BSP layer. 
-                    This command requires you to specify a particular architecture on which to 
-                    base the BSP.
+                    This command requires you to specify a particular kernel architecture 
+                    (<filename>karch</filename>) on which to base the BSP.
                     Assuming you have sourced the environment, you can use the 
                     <filename>yocto-bsp list karch</filename> sub-command to list the
                     architectures available for BSP creation as follows:
                     <literallayout class='monospaced'>
      $ yocto-bsp list karch
      Architectures available:
-         arm
-         powerpc
-         i386
-         mips
-         x86_64
          qemu
+         x86_64
+         i386
+         powerpc
+         arm
+         mips
                     </literallayout>
                 </para>
 
@@ -1229,53 +1190,46 @@
                     the prompts appear in brackets.
                     Pressing enter without supplying anything on the command line or pressing enter
                     and providing an invalid response causes the script to accept the default value.
+                    Once the script completes, the new <filename>meta-myarm</filename> BSP layer
+                    is created in the current working directory. 
+                    This example assumes you have source the &OE_INIT_FILE; and are currently
+                    in the top-level folder of the 
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
                 </para>
 
                 <para>
                     Following is the complete example:
                     <literallayout class='monospaced'>
      $ yocto-bsp create myarm qemu
-     Which qemu architecture would you like to use? [default: x86]
-             1) common 32-bit x86
-             2) common 64-bit x86
-             3) common 32-bit ARM
-             4) common 32-bit PowerPC
-             5) common 32-bit MIPS
+     Which qemu architecture would you like to use? [default: i386]
+	     1) i386    (32-bit)
+	     2) x86_64  (64-bit)
+	     3) ARM     (32-bit)
+	     4) PowerPC (32-bit)
+	     5) MIPS    (32-bit)
      3
-     Would you like to use the default (3.2) kernel? (Y/n)
-     Do you need a new machine branch for this BSP (the alternative is to re-use an existing branch)? [Y/n]
-     Getting branches from remote repo git://git.yoctoproject.org/linux-yocto-3.2...
-     Please choose a machine branch to base this BSP on => [default: standard/default/common-pc]
-             1) base
+     Would you like to use the default (3.4) kernel? (y/n) [default: y]
+     Do you need a new machine branch for this BSP (the alternative is to re-use an existing branch)? [y/n] [default: y]
+     Getting branches from remote repo git://git.yoctoproject.org/linux-yocto-3.4.git...
+     Please choose a machine branch to base your new BSP branch on: [default: standard/base]
+             1) standard/arm-versatile-926ejs
              2) standard/base
-             3) standard/default/arm-versatile-926ejs
-             4) standard/default/base
-             5) standard/default/beagleboard
-             6) standard/default/cedartrailbsp (copy).xml
-             7) standard/default/common-pc-64/base
-             8) standard/default/common-pc-64/jasperforest
-             9) standard/default/common-pc-64/romley
-             10) standard/default/common-pc-64/sugarbay
-             11) standard/default/common-pc/atom-pc
-             12) standard/default/common-pc/base
-             13) standard/default/crownbay
-             14) standard/default/emenlow
-             15) standard/default/fishriver
-             16) standard/default/fri2
-             17) standard/default/fsl-mpc8315e-rdb
-             18) standard/default/mti-malta32-be
-             19) standard/default/mti-malta32-le
-             20) standard/default/preempt-rt
-             21) standard/default/qemu-ppc32
-             22) standard/default/routerstationpro
-             23) standard/preempt-rt/base
-             24) standard/preempt-rt/qemu-ppc32
-             25) standard/preempt-rt/routerstationpro
-             26) standard/tiny
-     3
-     Do you need SMP support? (Y/n)
-     Does your BSP have a touchscreen? (y/N)
-     Does your BSP have a keyboard? (Y/n)
+             3) standard/beagleboard
+             4) standard/cedartrail
+             5) standard/crownbay
+             6) standard/emenlow
+             7) standard/fishriver
+             8) standard/fri2
+             9) standard/fsl-mpc8315e-rdb
+             10) standard/mti-malta32
+             11) standard/mti-malta64
+             12) standard/qemuppc
+             13) standard/routerstationpro
+             14) standard/sys940x
+     1
+     Would you like SMP support? (y/n) [default: y]
+     Does your BSP have a touchscreen? (y/n) [default: n]
+     Does your BSP have a keyboard? (y/n) [default: y]
      New qemu BSP created in meta-myarm
                     </literallayout>
                     Let's take a closer look at the example now:
@@ -1285,10 +1239,10 @@
                             In the example, we use the <filename>arm</filename> architecture.
                             </para></listitem>
                         <listitem><para>The script then prompts you for the kernel.
-                            The default kernel is 3.2 and is acceptable.  
+                            The default 3.4 kernel is acceptable.  
                             So, the example accepts the default.
                             If you enter 'n', the script prompts you to further enter the kernel
-                            you do want to use (e.g. 3.0, 3.2_preempt-rt, etc.).</para></listitem>
+                            you do want to use (e.g. 3.0, 3.2_preempt-rt, and so forth.).</para></listitem>
                         <listitem><para>Next, the script asks whether you would like to have a new 
                             branch created especially for your BSP in the local 
                             <ulink url='&YOCTO_DOCS_DEV_URL;#local-kernel-files'>Linux Yocto Kernel</ulink> 
@@ -1301,25 +1255,20 @@
                             The reason a new branch is the default is that typically
                             new BSPs do require BSP-specific patches.
                             The tool thus assumes that most of time a new branch is required.
-                            <note>In the current implementation, creation or re-use of a branch does 
-                            not actually matter.
-                            The reason is because the generated BSPs assume that patches and 
-                            configurations live in recipe-space, which is something that can be done 
-                            with or without a dedicated branch.  
-                            Generated BSPs, however, are different.
-                            This difference becomes significant once the tool's 'publish' functionality 
-                            is implemented.</note></para></listitem>
-                        <listitem><para>Regardless of which choice is made in the previous step, 
+                            </para></listitem>
+                        <listitem><para>Regardless of which choice you make in the previous step, 
                             you are now given the opportunity to select a particular machine branch on
-                            which to base your new BSP-specific machine branch on 
+                            which to base your new BSP-specific machine branch 
                             (or to re-use if you had elected to not create a new branch).  
                             Because this example is generating an <filename>arm</filename> BSP, the example 
-                            uses <filename>#3</filename> at the prompt, which selects the arm-versatile branch.
+                            uses <filename>#1</filename> at the prompt, which selects the arm-versatile branch.
                             </para></listitem>
                         <listitem><para>The remainder of the prompts are routine. 
                             Defaults are accepted for each.</para></listitem>
                         <listitem><para>By default, the script creates the new BSP Layer in the 
-                            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>.
+                            current working directory of the 
+                            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>, 
+                            which is <filename>poky</filename> in this case.
                             </para></listitem>
                     </orderedlist> 
                 </para>
@@ -1332,6 +1281,7 @@
      BBLAYERS = " \
         /usr/local/src/yocto/meta \
         /usr/local/src/yocto/meta-yocto \
+        /usr/local/src/yocto/meta-yocto-bsp \
         /usr/local/src/yocto/meta-myarm \
         "
                     </literallayout> 
@@ -1363,21 +1313,28 @@
                     is to use the <filename>yocto-kernel</filename> built-in help as follows:
                     <literallayout class='monospaced'>
      $ yocto-kernel
-     Usage:
+     Usage: 
 
-     Modify and list Yocto BSP kernel config items and patches.
+      Modify and list Yocto BSP kernel config items and patches.
 
-     usage: yocto-kernel [--version] [--help] COMMAND [ARGS]
+      usage: yocto-kernel [--version] [--help] COMMAND [ARGS]
 
-     The most commonly used 'yocto-kernel' commands are:
-     config list       List the modifiable set of bare kernel config options for a BSP
-     config add        Add or modify bare kernel config options for a BSP 
-     config rm         Remove bare kernel config options from a BSP
-     patch list        List the patches associated with a BSP
-     patch add         Patch the Yocto kernel for a BSP
-     patch rm          Remove patches from a BSP
+      Current 'yocto-kernel' commands are:
+        config list       List the modifiable set of bare kernel config options for a BSP
+        config add        Add or modify bare kernel config options for a BSP
+        config rm         Remove bare kernel config options from a BSP
+        patch list        List the patches associated with a BSP
+        patch add         Patch the Yocto kernel for a BSP
+        patch rm          Remove patches from a BSP
 
-     See 'yocto-kernel help COMMAND' for more information on a specific command.
+      See 'yocto-kernel help COMMAND' for more information on a specific command.
+
+
+
+     Options:
+       --version    show program's version number and exit
+       -h, --help   show this help message and exit
+       -D, --debug  output debug information
                     </literallayout>
                 </para>
 

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

@@ -1,716 +0,0 @@
-<!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
-[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
-
-<appendix id='dev-manual-bsp-appendix'>
-
-<title>BSP Development Example</title>
-
-<para>
-    This appendix provides a complete BSP development example.
-    The example assumes the following:
-    <itemizedlist>
-        <listitem><para>No previous preparation or use of the Yocto Project.</para></listitem>
-        <listitem><para>Use of the Crown Bay Board Support Package (BSP) as a "base" BSP from 
-            which to work.  
-            The example begins with the Crown Bay BSP as the starting point
-            but ends by building a new 'atom-pc' BSP, which was based on the Crown Bay BSP.
-            </para></listitem>  
-        <listitem><para>Shell commands assume <filename>bash</filename></para></listitem>
-        <listitem><para>Example was developed on an Intel-based Core i7 platform running 
-            Ubuntu 10.04 LTS released in April of 2010.</para></listitem>        
-    </itemizedlist>             
-</para>
-
-<section id='getting-local-yocto-project-files-and-bsp-files'>
-    <title>Getting Local Source Files and BSP Files</title>
-
-    <para>
-        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 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>:
-        <literallayout class='monospaced'>
-     $ git clone git://git.yoctoproject.org/poky
-     $ cd poky
-        </literallayout> 
-        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;
-        </literallayout> 
-        <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 &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 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 differences.</para></note>
-    </para>
-
-    <para>
-        With the local <filename>poky</filename> Git repository set up, 
-        you have all the development branches available to you from which you can work. 
-        Next, you need to be sure that your local repository reflects the exact
-        release in which you are interested.
-        From inside the repository you can see the development branches that represent
-        areas of development that have diverged from the main (master) branch
-        at some point, such as a branch to track a maintenance release's development.  
-        You can also see the tag names used to mark snapshots of stable releases or 
-        points in the repository.
-        Use the following commands to list out the branches and the tags in the repository, 
-        respectively.
-        <literallayout class='monospaced'>
-     $ git branch -a
-     $ git tag -l
-        </literallayout> 
-        For this example, we are going to use the Yocto Project &DISTRO; Release, which is code
-        named "&DISTRO_NAME;". 
-        To make sure we have a local area (branch in Git terms) on our machine that 
-        reflects the &DISTRO; release, we can use the following commands:
-        <literallayout class='monospaced'>
-     $ cd ~/poky
-     $ git fetch --tags
-     $ git checkout &DISTRO_NAME;-&POKYVERSION; -b &DISTRO_NAME;
-     Switched to a new branch '&DISTRO_NAME;'
-        </literallayout>
-        The <filename>git fetch --tags</filename> is somewhat redundant since you just set 
-        up the repository and should have all the tags.
-        The <filename>fetch</filename> command makes sure all the tags are available in your
-        local repository.
-        The Git <filename>checkout</filename> command with the <filename>-b</filename> option
-        creates a local branch for you named <filename>&DISTRO_NAME;</filename>.
-        Your local branch begins in the same state as the Yocto Project &DISTRO; released tarball 
-        marked with the <filename>&DISTRO_NAME;-&POKYVERSION;</filename> tag in the source repositories.
-    </para>
-</section> 
-
-<section id='choosing-a-base-bsp-app'>
-    <title>Choosing a Base BSP</title>
-
-    <para>
-        For this example, the base BSP is the <trademark class='registered'>Intel</trademark>
-        <trademark class='trade'>Atom</trademark> Processor E660 with Intel Platform 
-        Controller Hub EG20T Development Kit, which is otherwise referred to as "Crown Bay."
-        The BSP layer is <filename>meta-crownbay</filename>.  
-        The base BSP is simply the BSP
-        we will be using as a starting point, so don't worry if you don't actually have Crown Bay
-        hardware.
-        The remainder of the example transforms the base BSP into a BSP that should be
-        able to boot on generic atom-pc (netbook) hardware.
-    </para>
-
-    <para>
-        For information on how to choose a base BSP, see
-        "<link linkend='developing-a-board-support-package-bsp'>Developing a Board Support Package (BSP)</link>".
-    </para>
-</section>
-
-<section id='getting-your-base-bsp-app'>
-    <title>Getting Your Base BSP</title>
-
-    <para>
-        You need to have the base BSP layer on your development system.  
-        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 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>
-
-    <para>
-        This example assumes the BSP layer will be located within a directory named
-        <filename>meta-intel</filename> contained within the <filename>poky</filename>
-        parent directory.  
-        The following steps will automatically create the
-        <filename>meta-intel</filename> directory and the contained 
-        <filename>meta-crownbay</filename> starting point in both the Git and the tarball cases.
-    </para>
-
-    <para>
-        If you're using the Git method, you could do the following to create
-        the starting layout after you have made sure you are in the <filename>poky</filename>
-        directory created in the previous steps:
-        <literallayout class='monospaced'>
-     $ git clone git://git.yoctoproject.org/meta-intel.git
-     $ cd meta-intel
-        </literallayout> 
-        Alternatively, you can start with the downloaded Crown Bay tarball.
-        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;-&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;-&POKYVERSION;.tar.bz2
-     $ cd meta-intel
-        </literallayout> 
-    </para>
-        
-    <para>
-        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 &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
-        to be sure you are in the appropriate branch for your work.
-        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>
-</section>
-
-<section id='making-a-copy-of-the-base bsp-to-create-your-new-bsp-layer-app'>
-    <title>Making a Copy of the Base BSP to Create Your New BSP Layer</title>
-
-    <para>
-        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>
-
-    <para>  
-        For this example, the new layer will be named <filename>meta-mymachine</filename>.  
-        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 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'>
-     $ cp -a meta-crownbay/ meta-mymachine 
-        </literallayout>
-    </para>
-</section>
-
-<section id='making-changes-to-your-bsp-app'>
-    <title>Making Changes to Your BSP</title>
-
-    <para>
-        Right now you have two identical BSP layers with different names:  
-        <filename>meta-crownbay</filename> and <filename>meta-mymachine</filename>.  
-        You need to change your configurations so that they work for your new BSP and 
-        your particular hardware.
-        The following sections look at each of these areas of the BSP.
-    </para>
-
-    <section id='changing-the-bsp-configuration'>
-        <title>Changing the BSP Configuration</title>
-   
-        <para>  
-            We will look first at the configurations, which are all done in the layer’s 
-            <filename>conf</filename> directory.
-        </para>
-
-        <para>
-            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 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>.  
-            <literallayout class='monospaced'>
-     $ rm meta-mymachine/conf/machine/crownbay.conf
-     $ mv meta-mymachine/conf/machine/crownbay-noemgd.conf \
-     meta-mymachine/conf/machine/mymachine.conf
-            </literallayout>
-        </para>
-
-        <para>
-            Next, we need to make changes to the <filename>mymachine.conf</filename> itself.
-            The only changes we want to make for this example are to the comment lines.  
-            Changing comments, of course, is never strictly necessary, but it's alway good form to make
-            them reflect reality as much as possible.
-
-            Here, simply substitute the Crown Bay name with an appropriate name for the BSP 
-            (<filename>mymachine</filename> in this case) and change the description to 
-            something that describes your hardware.
-        </para>
-
-        <para>
-            Note that inside the <filename>mymachine.conf</filename> is the 
-            <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 Yocto Project kernel based on the Linux 3.2 release. 
-        </para>
-
-        <para>
-            The next configuration file in the new BSP layer we need to edit is
-            <filename>meta-mymachine/conf/layer.conf</filename>.
-            This file identifies build information needed for the new layer.  
-            You can see the 
-            "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-filelayout-layer'>Layer Configuration File</ulink>" section
-            in The Board Support Packages (BSP) Development Guide for more information on this configuration file.  
-            Basically, we are changing the existing statements to work with our BSP. 
-        </para>
-
-        <para>
-            The file contains these statements that reference the Crown Bay BSP:
-            <literallayout class='monospaced'>
-     BBFILE_COLLECTIONS += "crownbay"
-     BBFILE_PATTERN_crownbay := "^${LAYERDIR}/"
-     BBFILE_PRIORITY_crownbay = "6"
-
-     LAYERDEPENDS_crownbay = "intel"
-            </literallayout>
-        </para>
-
-        <para>
-            Simply substitute the machine string name <filename>crownbay</filename>
-            with the new machine name <filename>mymachine</filename> to get the following:
-            <literallayout class='monospaced'>
-     BBFILE_COLLECTIONS += "mymachine"
-     BBFILE_PATTERN_mymachine := "^${LAYERDIR}/"
-     BBFILE_PRIORITY_mymachine = "6"
-
-     LAYERDEPENDS_mymachine = "intel"
-            </literallayout>
-        </para>
-    </section>
-
-    <section id='changing-the-recipes-in-your-bsp'>
-        <title>Changing the Recipes in Your BSP</title>
-
-        <para>
-            Now we will take a look at the recipes in your new layer.  
-            The standard BSP structure has areas for BSP, graphics, core, and kernel recipes.  
-            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 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>, 
-            <filename>recipes-core</filename>, and 
-            <filename>recipes-graphics</filename> directories.    
-        </para>
-
-        <section id='changing-recipes-bsp'>
-            <title>Changing&nbsp;&nbsp;<filename>recipes-bsp</filename></title>
-
-            <para>
-                First, let's look at <filename>recipes-bsp</filename>.
-                For this example we are not adding any new BSP recipes.  
-                And, we only need to remove the formfactor we do not want and change the name of 
-                the remaining one that doesn't support EMGD.  
-                These commands take care of the <filename>recipes-bsp</filename> recipes:
-                <literallayout class='monospaced'>
-     $ rm -rf meta-mymachine/recipes-bsp/formfactor/formfactor/crownbay
-     $ mv meta-mymachine/recipes-bsp/formfactor/formfactor/crownbay-noemgd/ \
-     meta-mymachine/recipes-bsp/formfactor/formfactor/mymachine
-                </literallayout>
-            </para>
-        </section>
-
-        <section id='changing-recipes-graphics'>
-            <title>Changing&nbsp;&nbsp;<filename>recipes-graphics</filename></title>
-
-            <para>
-                Now let's look at <filename>recipes-graphics</filename>.
-                For this example we want to remove anything that supports EMGD and 
-                be sure to rename remaining directories appropriately.  
-                The following commands clean up the <filename>recipes-graphics</filename> directory:
-                <literallayout class='monospaced'>
-     $ rm -rf meta-mymachine/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay
-     $ mv meta-mymachine/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay-noemgd \
-        meta-mymachine/recipes-graphics/xorg-xserver/xserver-xf86-config/mymachine   
-                </literallayout>
-            </para>
-
-            <para>
-                At this point the <filename>recipes-graphics</filename> directory just has files that 
-                support Video Electronics Standards Association (VESA) graphics modes and not EMGD.  
-            </para>
-        </section>
-
-        <section id='changing-recipes-core'>
-            <title>Changing&nbsp;&nbsp;<filename>recipes-core</filename></title>
-
-            <para>
-                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 <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.
-                Here are the contents of the file:
-                <literallayout class='monospaced'>
-     RRECOMMENDS_task-core-tools-profile_append_crownbay = " systemtap"
-     RRECOMMENDS_task-core-tools-profile_append_crownbay-noemgd = " systemtap"
-                </literallayout>
-            </para>
-
-            <para>
-                The <filename>RRECOMMENDS</filename> statements list packages that 
-                extend usability.
-                The first <filename>RRECOMMENDS</filename> statement can be removed, while the 
-                second one can be changed to reflect <filename>meta-mymachine</filename>:
-                <literallayout class='monospaced'>
-     RRECOMMENDS_task-core-tools-profile_append_mymachine = " systemtap"
-                </literallayout>
-            </para>
-        </section>
-
-        <section id='changing-recipes-kernel'>
-            <title>Changing&nbsp;&nbsp;<filename>recipes-kernel</filename></title>
-
-            <para>
-                Finally, let's look at <filename>recipes-kernel</filename> changes.
-                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 source directory at 
-                <filename>meta/recipes-kernel/linux</filename> and is 
-                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.
-                In other words, the <filename>SRCREV</filename> values are simply Git commit 
-                IDs that identify which commit on each
-                of the kernel branches (machine and meta) will be checked out and used to build
-                the kernel.
-            </para>
- 
-            <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.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>.
-            </para>
-
-            <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:
-                <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 ?= \
-        "211fc7f4d10ec2b82b424286aabbaff9254b7cbd"
-     SRCREV_meta_pn-linux-yocto_crownbay ?= \
-        "514847185c78c07f52e02750fbe0a03ca3a31d8f"
-
-     SRCREV_machine_pn-linux-yocto_crownbay-noemgd ?= \
-        "211fc7f4d10ec2b82b424286aabbaff9254b7cbd"
-     SRCREV_meta_pn-linux-yocto_crownbay-noemgd ?= \
-        "514847185c78c07f52e02750fbe0a03ca3a31d8f"
-                </literallayout>
-            </para>
-
-            <para>
-                You will notice that there are two pairs of <filename>SRCREV</filename> statements.  
-                The top pair identifies the kernel that supports
-                EMGD, which we don’t care about in this example.  
-                The bottom pair identifies the kernel that we will use:  
-                <filename>linux-yocto</filename>.  
-                At this point though, the unique commit strings all are still associated with 
-                Crown Bay and not <filename>meta-mymachine</filename>.
-            </para>
-
-            <para>  
-                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 &DISTRO_NAME; branch of everything, we
-                need to use the <filename>SRCREV</filename> values for the atom-pc branch
-                that are associated with the &DISTRO_NAME; release.  
-                To find those values, we need to find the <filename>SRCREV</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>
-
-            <para>  
-                The machine <filename>SRCREV</filename> we want is in the 
-                <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.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 ?= \
-        "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 &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.
-                However, if you do base a future BSP on master and
-                if you are familiar with Git repositories, you probably won’t have trouble locating the 
-                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.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>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.2.bbappend</filename> file</para></listitem>
-                </orderedlist>
-            </para>
-
-            <para>
-                For the <filename>SRCREV</filename> statement that points to the <filename>meta</filename>
-                branch use the same procedure except expand the <filename>meta</filename>
-                branch in step 2 above.
-            </para>
-
-            <para>
-                Also in the <filename>linux-yocto_3.2.bbappend</filename> file are 
-                <ulink url='&YOCTO_DOCS_REF_URL;#var-COMPATIBLE_MACHINE'><filename>COMPATIBLE_MACHINE</filename></ulink>, 
-                <ulink url='&YOCTO_DOCS_REF_URL;#var-KMACHINE'><filename>KMACHINE</filename></ulink>, 
-                and 
-                <ulink url='&YOCTO_DOCS_REF_URL;#var-KBRANCH'><filename>KBRANCH</filename></ulink> 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 <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.2.bbappend</filename>
-                file we looked at in a previous step.  
-                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  = "atom-pc"
-     KBRANCH_mymachine  = "standard/default/common-pc/atom-pc"
-
-     SRCREV_machine_pn-linux-yocto_mymachine ?= \
-        "f29531a41df15d74be5ad47d958e4117ca9e489e"
-     SRCREV_meta_pn-linux-yocto_mymachine ?= \
-        "b14a08f5c7b469a5077c10942f4e1aec171faa9d"
-                </literallayout>
-            </para>
-        </section>
-    </section>
-
-    <section id='bsp-recipe-change-summary'>
-        <title>BSP Recipe Change Summary</title>
-
-        <para>
-            In summary, the edits to the layer’s recipe files result in removal of any files and 
-            statements that do not support your targeted hardware in addition to the inclusion 
-            of any new recipes you might need.  
-            In this example, it was simply a matter of ridding the new layer 
-            <filename>meta-mymachine</filename> of any code that supported the EMGD features
-            and making sure we were identifying the kernel that supports our example, which
-            is the <filename>atom-pc-standard</filename> kernel.  
-            We did not introduce any new recipes to the layer. 
-        </para>
-
-        <para>
-            Finally, it is also important to update the layer’s <filename>README</filename>
-            file so that the information in it reflects your BSP.
-        </para>
-    </section>
-</section>
-
-<section id='preparing-for-the-build-app'>
-    <title>Preparing for the Build</title>
-
-    <para>
-        To get ready to build your image that uses the new layer you need to do the following:
-        <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 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 
-                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.  
-                If you do not provide a name for the build directory it defaults to 
-                <filename>build</filename>.  
-                The <filename>yocto-build</filename> directory contains a
-                <filename>conf</filename> directory that has 
-                two configuration files you will need to check:  <filename>bblayers.conf</filename>
-                and <filename>local.conf</filename>.</para></listitem>
-            <listitem><para>Check and edit the resulting <filename>local.conf</filename> file.
-                This file minimally identifies the machine for which to build the image by 
-                configuring the <filename>MACHINE</filename> variable.  
-                For this example you must set the variable to mymachine as follows:
-                <literallayout class='monospaced'>
-     MACHINE ??= “mymachine”
-                </literallayout>
-                You should also be sure any other variables in which you are interested are set.  
-                Some variables to consider are <filename>BB_NUMBER_THREADS</filename>
-                and <filename>PARALLEL_MAKE</filename>, both of which can greatly reduce your build time 
-                if your development system supports multiple cores.
-                For development systems that support multiple cores, a good rule of thumb is to set 
-                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 
-                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>
-    </para>
-
-    <para>
-        The  
-        <ulink url='&YOCTO_DOCS_REF_URL;#ref-variables-glos'>Variables Glossary</ulink> chapter in the 
-        Yocto Project Reference Manual has more information on configuration variables.
-    </para>
-</section>
-
-<section id='building-the-image-app'>
-    <title>Building and Booting the Image</title>
-
-    <para>
-        To build the image for our <filename>meta-mymachine</filename> BSP enter the following command 
-        from the same shell from which you ran the setup script.  
-        You should run the <filename>bitbake</filename> command without any intervening shell commands.  
-        For example, moving your working directory around could cause problems.  
-        Here is the command for this example:
-        <literallayout class='monospaced'>
-     $ bitbake -k core-image-sato
-        </literallayout>
-    </para>
-
-    <para>
-        This command specifies an image that has Sato support and that can be run from a USB device or 
-        from a CD without having to first install anything.  
-        The build process takes significant time and includes thousands of tasks, which are reported 
-        at the console.  
-        If the build results in any type of error you should check for misspellings in the 
-        files you changed or problems with your host development environment such as missing packages.
-    </para>
-
-    <para>
-        Finally, once you have an image, you can try booting it from a device
-        (e.g. a USB device).
-        To prepare a bootable USB device, insert a USB flash drive into your build system and
-        copy the <filename>.hddimg</filename> file, located in the 
-        <filename>poky/build/tmp/deploy/images</filename>
-        directory after a successful build to the flash drive.  
-        Assuming the USB flash drive takes device <filename>/dev/sdf</filename>, 
-        use <filename>dd</filename> to copy the live image to it.  
-        For example:
-        <literallayout class='monospaced'>
-     # dd if=core-image-sato-mymachine-20111101223904.hddimg of=/dev/sdf
-     # sync
-     # eject /dev/sdf
-        </literallayout>
-        You should now have a bootable USB flash device.  
-    </para>
-
-    <para>
-        Insert the device
-        into a bootable USB socket on the target, and power it on.  
-        The system should boot to the Sato graphical desktop.
-        <footnote><para>Because 
-            this new image is not in any way tailored to the system you're
-            booting it on, which is assumed to be some sort of atom-pc (netbook) system for this
-            example, it might not be completely functional though it should at least boot to a text
-            prompt.  
-            Specifically, it might fail to boot into graphics without some tweaking.  
-            If this ends up being the case, a possible next step would be to replace the 
-            <filename>mymachine.conf</filename>
-            contents with the contents of <filename>atom-pc.conf</filename> and replace 
-            <filename>xorg.conf</filename> with <filename>atom-pc xorg.conf</filename>
-            in <filename>meta-yocto</filename> and see if it fares any better.  
-            In any case, following the previous steps will give you a buildable image that 
-            will probably boot on most systems.
-            Getting things working like you want
-            them to for your hardware will normally require some amount of experimentation with
-            configuration settings.</para></footnote> 
-    </para>
-
-    <para>
-        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'>
-     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
-        new BSP.  
-        That file and the <filename>README.hardware</filename> file in the top-level 
-        <filename>poky</filename> directory
-        also provides some suggestions for things to try if booting fails and produces
-        strange error messages.</note>
-    </para>
-</section>
-</appendix>
-
-
-<!--
-vim: expandtab tw=80 ts=4
--->

documentation/dev-manual/dev-manual-common-tasks.xml

@@ -30,7 +30,7 @@
             These types of customizations typically reside in a BSP Layer.
             Furthermore, the machine customizations should be isolated from recipes and metadata that support 
             a new GUI environment, for example. 
-            This situation gives you a couple a layers: one for the machine configurations, and one for the 
+            This situation gives you a couple of layers: one for the machine configurations, and one for the 
             GUI environment.
             It is important to understand, however, that the BSP layer can still make machine-specific 
             additions to recipes within the GUI environment layer without polluting the GUI layer itself 
@@ -50,8 +50,9 @@
                 You can easily identify a layer in the source directory by its folder name.
                 Folders that are layers begin with the string <filename>meta</filename>.
                 For example, when you set up the <link linkend='source-directory'>source directory</link>
-                structure, you will see several layers: <filename>meta</filename>, <filename>meta-demoapps</filename>,
-                <filename>meta-skeleton</filename>, and <filename>meta-yocto</filename>.
+                structure, you will see several layers: <filename>meta</filename>, 
+                <filename>meta-hob</filename>, <filename>meta-skeleton</filename>, 
+                <filename>meta-yocto</filename>, and <filename>meta-yocto-bsp</filename>.
                 Each of these folders is a layer.
             </para>
 
@@ -146,7 +147,10 @@
                         If the layer adds distro policy, add the distro configuration in a
                         <filename>conf/distro/</filename> file with the layer.
                         If the layer introduces new recipes, put the recipes you need in 
-                        <filename>recipes-*</filename> subdirectories within the layer.</para></listitem>
+                        <filename>recipes-*</filename> subdirectories within the layer.
+                        <note>In order to be compliant with the Yocto Project, a layer must contain
+                            a <ulink url='&YOCTO_DOCS_BSP_URL;#bsp-filelayout-readme'>README file.</ulink>
+                            </note></para></listitem>
                 </orderedlist>
             </para>
 
@@ -207,14 +211,17 @@
                 <link linkend='build-directory'>build directory</link>. 
                 The following example shows how to enable a layer named <filename>meta-mylayer</filename>:
                 <literallayout class='monospaced'>
-     LCONF_VERSION = "1"
+     LCONF_VERSION = "6"
 
+     BBPATH = "${TOPDIR}"
      BBFILES ?= ""
-     BBLAYERS = " \
+
+     BBLAYERS ?= " \
        /path/to/poky/meta \
        /path/to/poky/meta-yocto \
+       /path/to/poky/meta-yocto-bsp \
        /path/to/poky/meta-mylayer \
-       "
+       "                
                 </literallayout>
             </para>
 
@@ -225,6 +232,14 @@
                 During the processing of each <filename>conf/layer.conf</filename> file, BitBake adds the 
                 recipes, classes and configurations contained within the particular layer to the source
                 directory.
+                <note>
+                    Removing the <filename>meta-yocto</filename> layer exposes a bug for the 
+                    current release of the Yocto Project.
+                    If for some reason you do remove this layer from the 
+                    <filename>bblayers.conf</filename>, you must set the 
+                    <filename>LCONF_VERSION</filename> variable to "5".
+                    See <ulink url='https://bugzilla.yoctoproject.org/show_bug.cgi?id=3176'>[YOCTO_#3176]</ulink>
+                    for more information.</note>
             </para>
         </section>
 
@@ -234,7 +249,7 @@
             <para>
                 Recipes used to append metadata to other recipes are called BitBake append files.
                 BitBake append files use the <filename>.bbappend</filename> file type suffix, while  
-                underlying recipes to which metadata is being appended use the 
+                the corresponding recipes to which metadata is being appended use the 
                 <filename>.bb</filename> file type suffix.
             </para>
 
@@ -248,14 +263,14 @@
             </para>
 
             <para>
-                Append files files must have the same name as the underlying recipe.
+                Append files files must have the same name as the corresponding recipe.
                 For example, the append file <filename>someapp_&DISTRO;.bbappend</filename> must 
                 apply to <filename>someapp_&DISTRO;.bb</filename>.
                 This means the original recipe and append file names are version number specific.
-                If the underlying recipe is renamed to update to a newer version, the 
-                corresponding <filename>.bbappend</filename> file must be renamed as well.
+                If the corresponding recipe is renamed to update to a newer version, the 
+                underlying <filename>.bbappend</filename> file must be renamed as well.
                 During the build process, BitBake displays an error on starting if it detects a 
-                <filename>.bbappend</filename> file that does not have an underlying recipe 
+                <filename>.bbappend</filename> file that does not have a corresponding recipe 
                 with a matching name.
             </para>
 
@@ -300,7 +315,7 @@
                 <literallayout class='monospaced'>
      FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
  
-     PRINC = "1"
+     PRINC := "${@int(PRINC) + 1}"
                 </literallayout>
                 This example adds or overrides files in 
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
@@ -323,12 +338,6 @@
                     paths in the final list.
                 </note>
             </para>
-
-            <para>
-                For another example on how to use a <filename>.bbappend</filename> file, see the 
-                "<link linkend='changing-recipes-kernel'>Changing <filename>recipes-kernel</filename></link>"
-                section.
-            </para>
         </section>
 
         <section id='prioritizing-your-layer'>
@@ -462,7 +471,7 @@
                 One way to get additional software into an image is to create a custom image. 
                 The following example shows the form for the two lines you need:
                 <literallayout class='monospaced'>
-     IMAGE_INSTALL = "task-core-x11-base package1 package2"
+     IMAGE_INSTALL = "packagegroup-core-x11-base package1 package2"
 
      inherit core-image
                 </literallayout>
@@ -491,58 +500,60 @@
         </section>
 
         <section id='usingpoky-extend-customimage-customtasks'>
-            <title>Customizing Images Using Custom Tasks</title>
+            <title>Customizing Images Using Custom Package Groups</title>
 
             <para>
-                For complex custom images, the best approach is to create a custom task package
+                For complex custom images, the best approach is to create a custom package group recipe
                 that is used to build the image or images. 
-                A good example of a tasks package is 
-                <filename>meta/recipes-core/tasks/task-core-boot.bb</filename>
+                A good example of a package group recipe is 
+                <filename>meta/recipes-core/packagegroups/packagegroup-core-boot.bb</filename>.
                 The 
                 <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGES'>PACKAGES</ulink></filename> 
-                variable lists the task packages to build along with the complementary
-                <filename>-dbg</filename> and <filename>-dev</filename> packages. 
-                For each package added, you can use 
+                variable lists the package group packages you wish to produce. <filename>inherit packagegroup</filename>
+                sets appropriate default values and automatically adds <filename>-dev</filename>
+                and <filename>-dbg</filename> complementary
+                packages for every package specified in <filename>PACKAGES</filename>. 
+                Note that the inherit line should be towards
+                the top of the recipe, certainly before you set <filename>PACKAGES</filename>.
+                For each package you specify in <filename>PACKAGES</filename>, you can use 
                 <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-RDEPENDS'>RDEPENDS</ulink></filename>
                 and 
                 <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-RRECOMMENDS'>RRECOMMENDS</ulink></filename> 
                 entries to provide a list of packages the parent task package should contain. 
                 Following is an example:
                 <literallayout class='monospaced'>
-     DESCRIPTION = "My Custom Tasks"
+     DESCRIPTION = "My Custom Package Groups"
+
+     inherit packagegroup
 
      PACKAGES = "\
-         task-custom-apps \
-         task-custom-apps-dbg \
-         task-custom-apps-dev \
-         task-custom-tools \
-         task-custom-tools-dbg \
-         task-custom-tools-dev \
+         packagegroup-custom-apps \
+         packagegroup-custom-tools \
          "
 
-     RDEPENDS_task-custom-apps = "\
+     RDEPENDS_packagegroup-custom-apps = "\
          dropbear \
          portmap \
          psplash"
 
-     RDEPENDS_task-custom-tools = "\
+     RDEPENDS_packagegroup-custom-tools = "\
          oprofile \
          oprofileui-server \
          lttng-control \
          lttng-viewer"
 
-     RRECOMMENDS_task-custom-tools = "\
+     RRECOMMENDS_packagegroup-custom-tools = "\
          kernel-module-oprofile"
                 </literallayout>
             </para>
 
             <para>
-                In the previous example, two task packages are created with their dependencies and their
-                recommended package dependencies listed: <filename>task-custom-apps</filename>, and 
-                <filename>task-custom-tools</filename>. 
-                To build an image using these task packages, you need to add 
-                <filename>task-custom-apps</filename> and/or 
-                <filename>task-custom-tools</filename> to 
+                In the previous example, two package group packages are created with their dependencies and their
+                recommended package dependencies listed: <filename>packagegroup-custom-apps</filename>, and 
+                <filename>packagegroup-custom-tools</filename>. 
+                To build an image using these package group packages, you need to add 
+                <filename>packagegroup-custom-apps</filename> and/or 
+                <filename>packagegroup-custom-tools</filename> to 
                 <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-IMAGE_INSTALL'>IMAGE_INSTALL</ulink></filename>.
                 For other forms of image dependencies see the other areas of this section.
             </para>
@@ -557,11 +568,12 @@
                 <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-IMAGE_FEATURES'>IMAGE_FEATURES</ulink></filename>
                 variable. 
                 To create these features, the best reference is 
-                <filename>meta/classes/core-image.bbclass</filename>, which shows how to achieve this. 
+                <filename>meta/classes/core-image.bbclass</filename>, which shows how this is 
+                achieved. 
                 In summary, the file looks at the contents of the 
                 <filename>IMAGE_FEATURES</filename>
                 variable and then maps that into a set of tasks or packages. 
-                Based on this information the 
+                Based on this information, the 
                 <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-IMAGE_INSTALL'> IMAGE_INSTALL</ulink></filename> 
                 variable is generated automatically. 
                 Users can add extra features by extending the class or creating a custom class for use 
@@ -768,7 +780,7 @@
                 variable.
                 BitBake passes these options into the <filename>make</filename> GNU invocation. 
                 Note that a <filename>do_install</filename> task is still required.
-                Otherwise BitBake runs an empty <filename>do_install</filename> task by default. 
+                Otherwise, BitBake runs an empty <filename>do_install</filename> task by default. 
             </para>
 
             <para>
@@ -901,7 +913,9 @@
             </para>
 
             <para>
-                The <filename>PACKAGES</filename> and <filename>FILES_*</filename> variables in the 
+                The <ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGES'><filename>PACKAGES</filename></ulink>
+                and <ulink url='&YOCTO_DOCS_REF_URL;#var-FILES'><filename>FILES_*</filename></ulink>
+                variables in the 
                 <filename>meta/conf/bitbake.conf</filename> configuration file define how files installed
                 by the <filename>do_install</filename> task are packaged.
                 By default, the <filename>PACKAGES</filename> variable contains 
@@ -1016,8 +1030,8 @@
         <para>
             For a complete example that shows how to add a new machine, 
             see the 
-            "<ulink url='&YOCTO_DOCS_DEV_URL;#dev-manual-bsp-appendix'>BSP Development Example</ulink>" 
-            in Appendix A.
+            "<ulink url='&YOCTO_DOCS_BSP_URL;#creating-a-new-bsp-layer-using-the-yocto-bsp-script'>Creating a New BSP Layer Using the yocto-bsp Script</ulink>" 
+            in the Yocto Project Board Support Package (BSP) Developer's Guide.
         </para>
 
         <section id="platdev-newmachine-conffile">
@@ -1193,7 +1207,9 @@
                 Many standard recipes are already extended and support multiple libraries.
                 You can check in the <filename>meta/conf/multilib.conf</filename>
                 configuration file in the source directory to see how this is 
-                done using the <filename>BBCLASSEXTEND</filename> variable.
+                done using the 
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-BBCLASSEXTEND'><filename>BBCLASSEXTEND</filename></ulink>
+                variable.
                 Eventually, all recipes will be covered and this list will be unneeded.
             </para>
   
@@ -1202,10 +1218,13 @@
                 extend the package name from <filename>${PN}</filename> to
                 <filename>${MLPREFIX}${PN}</filename>, where <filename>MLPREFIX</filename>
                 is the particular multilib (e.g. "lib32-" or "lib64-"). 
-                Standard variables such as <filename>DEPENDS</filename>, 
-                <filename>RDEPENDS</filename>, <filename>RPROVIDES</filename>, 
-                <filename>RRECOMMENDS</filename>, <filename>PACKAGES</filename>, and 
-                <filename>PACKAGES_DYNAMIC</filename> are automatically extended by the system.
+                Standard variables such as 
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-DEPENDS'><filename>DEPENDS</filename></ulink>, 
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-RDEPENDS'><filename>RDEPENDS</filename></ulink>,
+                <filename>RPROVIDES</filename>, 
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-RRECOMMENDS'><filename>RRECOMMENDS</filename></ulink>,
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGES'><filename>PACKAGES</filename></ulink>,
+                and <filename>PACKAGES_DYNAMIC</filename> are automatically extended by the system.
                 If you are extending any manual code in the recipe, you can use the 
                 <filename>${MLPREFIX}</filename> variable to ensure those names are extended 
                 correctly. 
@@ -1333,6 +1352,8 @@
             <para>
                 The easiest way to define kernel configurations is to set them through the
                 <filename>menuconfig</filename> tool.
+                This tool provides an interactive method with which
+                to set kernel configurations.
                 For general information on <filename>menuconfig</filename>, see
                 <ulink url='http://en.wikipedia.org/wiki/Menuconfig'></ulink>.
             </para>
@@ -1340,6 +1361,9 @@
             <para>
                 To use the <filename>menuconfig</filename> tool in the Yocto Project development
                 environment, you must build the tool using BitBake.
+                Thus, the environment must be set up using the <filename>&OE_INIT_FILE;</filename>
+                script found in the 
+                <link linkend='build-directory'>Build Directory</link>.
                 The following commands build and invoke <filename>menuconfig</filename> assuming the 
                 source directory top-level folder is <filename>~/poky</filename>:
                 <literallayout class='monospaced'>
@@ -1348,17 +1372,86 @@
      $ bitbake linux-yocto -c menuconfig
                 </literallayout>
                 Once <filename>menuconfig</filename> comes up, its standard interface allows you to 
-                examine and configure all the kernel configuration parameters.
-                Once you have made your changes, simply exit the tool and save your changes to 
+                interactively examine and configure all the kernel configuration parameters.
+                After making your changes, simply exit the tool and save your changes to 
                 create an updated version of the <filename>.config</filename> configuration file.
             </para>
 
             <para>
-                For an example that shows how to change a specific kernel option
-                using <filename>menuconfig</filename>, see the 
-                "<link linkend='changing-the-config-smp-configuration-using-menuconfig'>Changing
-                the <filename>CONFIG_SMP</filename> Configuration Using <filename>menuconfig</filename></link>" 
-                section.
+                Consider an example that configures the <filename>linux-yocto-3.4</filename>
+                kernel.
+                The OpenEmbedded build system recognizes this kernel as 
+                <filename>linux-yocto</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>
+            </para>
+
+            <para>
+                Once <filename>menuconfig</filename> launches, you use the interface 
+                to navigate through the selections to find the configuration settings in
+                which you are interested.  
+                For example, consider the <filename>CONFIG_SMP</filename> configuration setting.
+                You can find it at <filename>Processor Type and Features</filename> under 
+                the configuration selection <filename>Symmetric Multi-processing Support</filename>.
+                After highlighting the selection, you can use the arrow keys to select or deselect
+                the setting.
+                When you are finished with all your selections, exit out and save them.
+            </para>
+
+            <para>
+                Saving the selections updates the <filename>.config</filename> configuration file.
+                This is the file that the OpenEmbedded build system uses to configure the 
+                kernel during the build. 
+                You can find and examine this file in the build directory in 
+                <filename>tmp/work/</filename>.
+                The actual <filename>.config</filename> is located in the area where the 
+                specific kernel is built.
+                For example, if you were building a Linux Yocto kernel based on the 
+                Linux 3.4 kernel and you were building a QEMU image targeted for 
+                <filename>x86</filename> architecture, the 
+                <filename>.config</filename> file would be located here:
+                <literallayout class='monospaced'>
+     ~/poky/build/tmp/work/qemux86-poky-linux/linux-yocto-3.4.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 
+                    for <filename>linux-yocto-3.4...</filename> might differ.
+                </note>
+            </para>
+
+            <para>
+                Within the <filename>.config</filename> file, you can see the kernel settings.
+                For example, the following entry shows that symmetric multi-processor support
+                is not set:
+                <literallayout class='monospaced'>
+     # CONFIG_SMP is not set
+                </literallayout>
+            </para>
+
+            <para>
+                A good method to isolate changed configurations is to use a combination of the 
+                <filename>menuconfig</filename> tool and simple shell commands.
+                Before changing configurations with <filename>menuconfig</filename>, copy the 
+                existing <filename>.config</filename> and rename it to something else,
+                use <filename>menuconfig</filename> to make 
+                as many changes an you want and save them, then compare the renamed configuration 
+                file against the newly created file.
+                You can use the resulting differences as your base to create configuration fragments
+                to permanently save in your kernel layer.
+                <note>
+                    Be sure to make a copy of the <filename>.config</filename> and don't just
+                    rename it. 
+                    The build system needs an existing <filename>.config</filename>
+                    from which to work.
+                </note>
             </para>
         </section>
 
@@ -1497,6 +1590,267 @@
         </section>
     </section>
 
+
+
+
+
+
+
+
+
+
+
+
+    <section id="patching-the-kernel">
+        <title>Patching the Kernel</title>
+  
+        <para>
+            Patching the kernel involves changing or adding configurations to an existing kernel,  
+            changing or adding recipes to the kernel that are needed to support specific hardware features, 
+            or even altering the source code itself.  
+            <note>
+                You can use the <filename>yocto-kernel</filename> script
+                found in the <link linkend='source-directory'>Source Directory</link>
+                under <filename>scripts</filename> to manage kernel patches and configuration.
+                See the "<ulink url='&YOCTO_DOCS_BSP_URL;#managing-kernel-patches-and-config-items-with-yocto-kernel'>Managing kernel Patches and Config Items with yocto-kernel</ulink>" 
+                section in the Yocto Project Board Support Packages (BSP) Developer's Guide for
+                more information.</note>
+        </para>
+
+        <para>
+            This example creates a simple patch by adding some QEMU emulator console 
+            output at boot time through <filename>printk</filename> statements in the kernel's
+            <filename>calibrate.c</filename> source code file.
+            Applying the patch and booting the modified image causes the added 
+            messages to appear on the emulator's console.
+        </para> 
+
+        <section id='creating-the-patch'>
+            <title>Creating the Patch</title>
+
+            <para>
+                Describe how to find the source files in the build area.  
+                We are not assuming they are using their own kernel tree.
+
+            </para>
+        </section> 
+
+
+        <section id='changing-the-source-code-and-pushing-it-to-the-bare-clone'>
+            <title>Changing the Source Code and Pushing it to the Bare Clone</title>
+
+            <para>
+                The file you change in this example is named <filename>calibrate.c</filename>
+                and is located in the <filename>my-linux-yocto-3.4-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.
+            </para>
+
+            <para>
+                Here is the unaltered code at the start of this function:
+                <literallayout class='monospaced'>
+     void __cpuinit calibrate_delay(void)
+     {
+     	unsigned long lpj;
+     	static bool printed;
+     	int this_cpu = smp_processor_id();
+
+     	if (per_cpu(cpu_loops_per_jiffy, this_cpu)) {
+               .
+               .
+               .
+               </literallayout>
+           </para>
+
+           <para>
+               Here is the altered code showing five new <filename>printk</filename> statements 
+               near the top of the function:
+                <literallayout class='monospaced'>
+     void __cpuinit calibrate_delay(void)
+     {
+         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 (per_cpu(cpu_loops_per_jiffy, this_cpu)) {
+               .
+               .
+               .
+               </literallayout>
+           </para>
+
+           <para>
+               After making and saving your changes, you need to stage them for the push.
+               The following Git commands are one method of staging and committing your changes:
+               <literallayout class='monospaced'>
+     $ git add calibrate.c
+     $ git commit --signoff
+               </literallayout>
+           </para>
+
+           <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 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 standard-common-pc-base:standard/default/common-pc/base
+               </literallayout>
+           </para>
+       </section>
+
+       <section id='changing-build-parameters-for-your-build'>
+           <title>Changing Build Parameters for Your Build</title>
+
+           <para>
+               At this point, the source has been changed and pushed.
+               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 
+               type of machine you are building and to help speed up the build should your host support
+               multiple-core and thread capabilities.
+           </para>
+
+           <para>
+               Do the following to make sure the build parameters are set up for the example.
+               Once you set up these build parameters, they do not have to change unless you 
+               change the target architecture of the machine you are building or you move
+               the bare clone, copy of the clone, or the <filename>poky-extras</filename> repository:
+               <itemizedlist>
+                   <listitem><para><emphasis>Build for the Correct Target Architecture:</emphasis> The 
+                       <filename>local.conf</filename> file in the build directory defines the build's 
+                       target architecture.
+                       By default, <filename>MACHINE</filename> is set to 
+                       <filename>qemux86</filename>, which specifies a 32-bit 
+                       <trademark class='registered'>Intel</trademark> Architecture 
+                       target machine suitable for the QEMU emulator.  
+                       In this example, <filename>MACHINE</filename> is correctly configured.
+                       </para></listitem>
+                   <listitem><para><emphasis>Optimize Build Time:</emphasis> Also in the 
+                       <filename>local.conf</filename> file are two variables that can speed your 
+                       build time if your host supports multi-core and multi-thread capabilities:
+                       <filename>BB_NUMBER_THREADS</filename> and <filename>PARALLEL_MAKE</filename>.
+                       If the host system has multiple cores then you can optimize build time 
+                       by setting both these variables to twice the number of 
+                       cores.</para></listitem>
+                   <listitem><para><emphasis>Identify Your <filename>meta-kernel-dev</filename>
+                       Layer:</emphasis> The <filename>BBLAYERS</filename> variable in the 
+                       <filename>bblayers.conf</filename> file found in the 
+                       <filename>poky/build/conf</filename> directory needs to have the path to your local
+                       <filename>meta-kernel-dev</filename> layer.  
+                       By default, the <filename>BBLAYERS</filename> variable contains paths to  
+                       <filename>meta</filename> and <filename>meta-yocto</filename> in the 
+                       <filename>poky</filename> Git repository.
+                       Add the path to your <filename>meta-kernel-dev</filename> location.
+                       Be sure to substitute your user information in the statement.
+                       Here is an example:
+                       <literallayout class='monospaced'>
+     BBLAYERS = " \
+       /home/scottrif/poky/meta \
+       /home/scottrif/poky/meta-yocto \
+       /home/scottrif/poky/meta-yocto-bsp \
+       /home/scottrif/poky/poky-extras/meta-kernel-dev \
+       "
+                       </literallayout></para></listitem>
+                   <listitem><para><emphasis>Identify Your Source Files:</emphasis> In the 
+                       <filename>linux-yocto_3.4.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.4.git</filename>.
+                       To do this, set the <filename>KSRC_linux_yocto</filename> variable to point to your
+                       local <filename>linux-yocto-3.4.git</filename> Git repository by adding the 
+                       following statement.
+                       Also, be sure the <filename>SRC_URI</filename> variable is pointing to
+                       your kernel source files by removing the comment.
+                       Finally, be sure to substitute your user information in the statement:
+                       <literallayout class='monospaced'>
+     KSRC_linux_yocto_3_4 ?= "/home/scottrif/linux-yocto-3.4.git"
+     SRC_URI = "git://${KSRC_linux_yocto_3_4};protocol=file;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"
+                       </literallayout></para></listitem>
+               </itemizedlist>
+           </para>
+
+           <note>
+               <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, or simply remove (or rename) all the files 
+               except the one your are using for the build 
+               (i.e. <filename>linux-yocto_3.4.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>
+
+        <section id='building-and-booting-the-modified-qemu-kernel-image'>
+            <title>Building and Booting the Modified QEMU Kernel Image</title>
+
+            <para>
+                Next, you need to build the modified image.
+                Do the following:
+                <orderedlist>
+                    <listitem><para>Your environment should be set up since you previously sourced
+                        the <filename>&OE_INIT_FILE;</filename> script.
+                        If it isn't, source the script again from <filename>poky</filename>.
+                        <literallayout class='monospaced'>
+     $ cd ~/poky
+     $ source &OE_INIT_FILE;
+                        </literallayout>
+                        </para></listitem>
+                    <listitem><para>Be sure old images are cleaned out by running the 
+                        <filename>cleanall</filename> BitBake task as follows from your build directory:
+                        <literallayout class='monospaced'>
+     $ bitbake -c cleanall linux-yocto
+                        </literallayout></para>
+                        <para><note>Never remove any files by hand from the <filename>tmp/deploy</filename>
+                        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:
+                        <literallayout class='monospaced'>
+     $ bitbake -k core-image-minimal
+                        </literallayout></para></listitem>
+                    <listitem><para>Finally, boot the modified image in the QEMU emulator 
+                        using this command:
+                        <literallayout class='monospaced'>
+     $ runqemu qemux86
+                        </literallayout></para></listitem>
+                </orderedlist>
+            </para>
+
+            <para>
+                Log into the machine using <filename>root</filename> with no password and then 
+                use the following shell command to scroll through the console's boot output.
+                <literallayout class='monospaced'>
+     # dmesg | less
+                </literallayout>
+            </para>
+
+            <para>
+                You should see the results of your <filename>printk</filename> statements 
+                as part of the output.
+            </para>
+        </section>
+    </section>
+
     <section id="usingpoky-changes-updatingimages">
         <title>Updating Existing Images</title>
 
@@ -1524,11 +1878,11 @@
             <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PR'>PR</ulink></filename> 
             variable needs to be increased 
             (or "bumped") as part of that commit. 
-            This means that for new recipes you must be sure to add the <filename>PR</filename>
-            variable and set its initial value equal to "r0".  
-            Failing to define <filename>PR</filename> makes it easy to miss when you bump a package.
-            Note that you can only use integer values following the "r" in the 
-            <filename>PR</filename> variable.
+            For new recipes you should add the <filename>PR</filename>
+            variable and set its initial value equal to "r0", which is the default.  
+            Even though the default value is "r0", the practice of adding it to a new recipe makes 
+            it harder to forget to bump the variable when you make changes 
+            to the recipe in future.
         </para>
 
         <para>
@@ -1639,7 +1993,7 @@
             and thus outside of the <link linkend='source-directory'>source directory</link>.
             For example, suppose you have a project that includes a new BSP with a heavily customized 
             kernel, a very minimal image, and some new user-space recipes.
-            And, you want to minimize the exposure to the build system to the 
+            And, you want to minimize exposing the build system to the 
             development team so that they can focus on their project and maintain everyone's workflow
             as much as possible.
             In this case, you want a kernel source directory on the development machine where the 
@@ -1711,8 +2065,9 @@
 
         <para>
             If you're working on a recipe that pulls from an external Source Code Manager (SCM), it 
-            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. 
+            is possible to have the OpenEmbedded build system notice new recipe changes added to the 
+            SCM and then build the resulting package that depends on the new recipes by using the latest 
+            versions. 
             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.
         </para>
@@ -1724,8 +2079,8 @@
             <literallayout class='monospaced'>
      SRCREV_pn-&lt;PN&gt; = "${AUTOREV}"
             </literallayout>
-            where <filename>PN</filename> 
-            is the name of the package for which you want to enable automatic source 
+            where <ulink url='&YOCTO_DOCS_REF_URL;#var-PN'><filename>PN</filename></ulink> 
+            is the name of the recipe for which you want to enable automatic source 
             revision updating.
         </para>
     </section>
@@ -1734,10 +2089,10 @@
         <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. 
+            GDB allows you to examine running programs, which in turn helps 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.
+            installed in SDK images.
             See the "<ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Images</ulink>" chapter 
             in the Yocto Project Reference Manual for a description of these images. 
             You can find information on GDB at <ulink url="http://sourceware.org/gdb/"/>.
@@ -1858,18 +2213,18 @@
                 <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.
+                    The inferior binary (complete with all debugging symbols), as well as any
+                    libraries (and their debugging symbols) on which the inferior binary depends,
+                    needs to be available.
+                    There are a number of ways you can make these items available.
                 </para>
 
                 <para>
-                    Perhaps the easiest way is to have an 'sdk' image that corresponds to the plain
+                    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-sato-sdk</filename> would contain suitable symbols. 
-                    Because the sdk images already have the debugging symbols installed, it is just a 
+                    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>
 
@@ -2000,13 +2355,18 @@
             <filename>-fno-omit-framepointer</filename> flag. 
             You can achieve this by setting the 
             <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-SELECTED_OPTIMIZATION'>SELECTED_OPTIMIZATION</ulink></filename>
-            variable to 
-            <filename>-fexpensive-optimizations -fno-omit-framepointer -frename-registers -O2</filename>. 
+            variable with the following options:
+            <literallayout class='monospaced'>
+     -fexpensive-optimizations
+     -fno-omit-framepointer
+     -frename-registers 
+     -O2
+            </literallayout> 
             You can also achieve it by setting the
             <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-DEBUG_BUILD'>DEBUG_BUILD</ulink></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.
+            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">

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

@@ -23,9 +23,9 @@
         </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 reconfigure the kernel.
-            You can find this information in the appendices of the manual.
+            The Yocto Project Development Manual, however, does provide detailed examples
+            on how to change the kernel source code, reconfigure the kernel, and develop
+            an application using the popular <trademark class='trade'>Eclipse</trademark> IDE.
         </para>
     </section>
 
@@ -44,7 +44,7 @@
                 <listitem><para>Development case overviews for both system development and user-space 
                     applications.</para></listitem>
                 <listitem><para>An overview and understanding of the emulation environment used with 
-                    the Yocto Project (QEMU).</para></listitem>
+                    the Yocto Project - the Quick EMUlator (QEMU).</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>
@@ -59,9 +59,10 @@
             <itemizedlist>
                 <listitem><para>Step-by-step instructions if those instructions exist in other Yocto 
                     Project documentation.  
-                    For example, the Yocto Project Development Manual contains detailed 
-                    instruction on how to obtain and configure the 
-                    <trademark class='trade'>Eclipse</trademark> Yocto Plug-in.</para></listitem>
+                    For example, the Yocto Project Application Developer's Guide contains detailed 
+                    instruction on how to run the 
+                    <ulink url='&YOCTO_DOCS_ADT_URL;#installing-the-adt'>Installing the ADT and Toolchains</ulink>,
+                    which is used to set up a cross-development environment.</para></listitem>
                 <listitem><para>Reference material.  
                     This type of material resides in an appropriate reference manual.  
                     For example, system variables are documented in the 
@@ -114,7 +115,7 @@
                     <ulink url='&YOCTO_WIKI_URL;/wiki/FAQ'>FAQ</ulink>:</emphasis>
                     A list of commonly asked questions and their answers.</para></listitem>
                 <listitem><para><emphasis>
-                    <ulink url='&YOCTO_HOME_URL;/download/yocto/yocto-project-1.1-release-notes-poky-&POKYVERSION;'>
+                    <ulink url='&YOCTO_HOME_URL;/download/yocto/yocto-project-&DISTRO;-release-notes-poky-&POKYVERSION;'>
                     Release Notes</ulink>:</emphasis> Features, updates and known issues for the current 
                     release of the Yocto Project.</para></listitem>
                 <listitem><para><emphasis>
@@ -169,11 +170,13 @@
                     BitBake</ulink>:</emphasis> The tool used by the OpenEmbedded build system 
                     to process project metadata.</para></listitem>
                 <listitem><para><emphasis>
-                    <ulink url='&BITBAKE_DOCS_URL;'>
-                    BitBake User Manual</ulink>:</emphasis> A comprehensive guide to the BitBake tool.
-                    </para></listitem>
+                    BitBake User Manual:</emphasis>
+                    A comprehensive guide to the BitBake tool.
+                    If you want information on BitBake, see the user manual inculded in the 
+                    <filename>bitbake/doc/manual</filename> directory of the 
+                    <link linkend='source-directory'>Source Directory</link>.</para></listitem>
                 <listitem><para><emphasis>
-                    <ulink url='http://wiki.qemu.org/Index.html'>QEMU</ulink>:
+                    <ulink url='http://wiki.qemu.org/Index.html'>Quick EMUlator (QEMU)</ulink>:
                     </emphasis> An open-source machine emulator and virtualizer.</para></listitem>
             </itemizedlist>
         </para>

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

@@ -12,6 +12,13 @@
         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.
+        <note>
+            You can use the <filename>yocto-kernel</filename> script
+            found in the <link linkend='source-directory'>Source Directory</link>
+            under <filename>scripts</filename> to manage kernel patches and configuration.
+            See the "<ulink url='&YOCTO_DOCS_BSP_URL;#managing-kernel-patches-and-config-items-with-yocto-kernel'>Managing kernel Patches and Config Items with yocto-kernel</ulink>" 
+            section in the Yocto Project Board Support Packages (BSP) Developer's Guide for
+            more information.</note>
     </para>
 
     <section id='modifying-the-kernel-source-code'>
@@ -34,11 +41,11 @@
                 Briefly, you need the following: 
                 <itemizedlist>
                     <listitem><para>A local 
-                        <link linkend='source-directory'>source directory</link> for 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 source directory.</para></listitem>  
+                        Git repository placed within the Source Directory.</para></listitem>  
                     <listitem><para>A bare clone of the 
                         <link linkend='local-kernel-files'>Yocto Project Kernel</link> upstream Git 
                         repository to which you want to push your modifications.
@@ -59,7 +66,7 @@
             </para>
 
             <para>
-                <imagedata fileref="figures/kernel-example-repos-denzil.png" width="7in" depth="5in" 
+                <imagedata fileref="figures/kernel-example-repos-generic.png" width="7in" depth="5in" 
                     align="center" scale="100" />
             </para>
 
@@ -69,16 +76,18 @@
                     <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 
+                        In this example, the 
+                        <link linkend='source-directory'>Source Directory</link> also 
+                        contains the 
+                        <link linkend='build-directory'>Build Directory</link>, 
+                        which contains the configuration directory 
                         that lets you control the build.
-                        Also in this example, the source directory contains local copies of 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 on your local system.</para></listitem>
-                    <listitem><para><emphasis>Local copies of the<filename>poky-extras</filename> 
-                        Git Repository:</emphasis> 
+                    <listitem><para><emphasis>Local copies of the&nbsp;<filename>poky-extras</filename>&nbsp;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 
@@ -125,17 +134,19 @@
             <title>Setting Up the Local Source Directory</title>
 
             <para>
-                You can set up the source directory through tarball extraction or by 
+                You can set up the 
+                <link linkend='source-directory'>Source Directory</link>
+                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 source directory.
+                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 source directory set up, 
+                Once you have Source Directory set up, 
                 you have many development branches from which you can work. 
                 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:
@@ -161,7 +172,7 @@
 
             <para>
                 This example creates a local copy of the <filename>poky-extras</filename> Git 
-                repository inside the <filename>poky</filename> source directory.
+                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 set up a local copy of the
@@ -172,11 +183,12 @@
                 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>.
+                branch for <filename>poky-extras</filename>.
                 The following commands create and checkout the local 
                 branch you are using for the <filename>&DISTRO_NAME;</filename>
                 branch:
                 <literallayout class='monospaced'>
+     $ cd ~/poky/poky-extras
      $ 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;'
@@ -188,7 +200,7 @@
             <title>Setting Up the Bare Clone and its Copy</title>
 
             <para>
-                This example modifies the <filename>linux-yocto-3.2</filename> kernel.
+                This example modifies the <filename>linux-yocto-3.4</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
@@ -200,17 +212,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.2-work</filename> in this example) has to have 
+                The copy (<filename>my-linux-yocto-3.4-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.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 
-        standard/default/common-pc/base from origin.
-     Switched to a new branch 'common-pc-base'
+     $ cd ~/my-linux-yocto-3.4-work
+     $ git checkout -b standard-common-pc-base origin/standard/common-pc/base
+     Branch standard-common-pc-base set up to track remote branch 
+        standard/common-pc/base from origin.
+     Switched to a new branch 'standard-common-pc-base'
                 </literallayout>
             </para>
         </section>
@@ -224,7 +235,7 @@
                 <note>
                     Because a full build can take hours, you should check two variables in the 
                     <filename>build</filename> directory that is created after you source the 
-                    <filename>oe-init-build-env</filename> script.
+                    <filename>&OE_INIT_FILE;</filename> script.
                     You can find these variables
                     <filename>BB_NUMBER_THREADS</filename> and <filename>PARALLEL_MAKE</filename>
                     in the <filename>build/conf</filename> directory in the 
@@ -242,11 +253,36 @@
                 If necessary, the script creates the build directory:
                 <literallayout class='monospaced'>
      $ cd ~/poky
-     $ source oe-init-build-env
+     $ source &OE_INIT_FILE;
+     You had no conf/local.conf file. This configuration file has therefore been
+     created for you with some default values. You may wish to edit it to use a 
+     different MACHINE (target hardware) or enable parallel build options to take 
+     advantage of multiple cores for example. See the file for more information as 
+     common configuration options are commented.
 
-          ### Shell environment set up for builds. ###
+     The Yocto Project has extensive documentation about OE including a reference manual
+     which can be found at:
+         http://yoctoproject.org/documentation
 
-     You can now run 'bitbake &lt;target&gt;'
+     For more information about OpenEmbedded see their website:
+         http://www.openembedded.org/
+
+     You had no conf/bblayers.conf file. The configuration file has been created for
+     you with some default values. To add additional metadata layers into your
+     configuration please add entries to this file.
+
+     The Yocto Project has extensive documentation about OE including a reference manual
+     which can be found at:
+         http://yoctoproject.org/documentation
+
+     For more information about OpenEmbedded see their website:
+         http://www.openembedded.org/
+
+
+
+     ### Shell environment set up for builds. ###
+
+     You can now run 'bitbake &lt;target&gt;>'
 
      Common targets are:
          core-image-minimal
@@ -301,7 +337,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.2-work</filename> Git repository
+                and is located in the <filename>my-linux-yocto-3.4-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.
@@ -365,7 +401,7 @@
            <para>
                The following command pushes the changes to the bare clone:
                <literallayout class='monospaced'>
-     $ git push origin common-pc-base:standard/default/common-pc/base
+     $ git push origin standard-common-pc-base:standard/default/common-pc/base
                </literallayout>
            </para>
        </section>
@@ -420,21 +456,25 @@
      BBLAYERS = " \
        /home/scottrif/poky/meta \
        /home/scottrif/poky/meta-yocto \
+       /home/scottrif/poky/meta-yocto-bsp \
        /home/scottrif/poky/poky-extras/meta-kernel-dev \
        "
                        </literallayout></para></listitem>
                    <listitem><para><emphasis>Identify Your Source Files:</emphasis> In the 
-                       <filename>linux-yocto_3.2.bbappend</filename> file located in the 
+                       <filename>linux-yocto_3.4.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.2.git</filename>.
+                       <filename>linux-yocto-3.4.git</filename>.
                        To do this, set the <filename>KSRC_linux_yocto</filename> variable to point to your
-                       local <filename>linux-yocto-3.2.git</filename> Git repository by adding the 
+                       local <filename>linux-yocto-3.4.git</filename> Git repository by adding the 
                        following statement.
-                       Be sure to substitute your user information in the statement:
+                       Also, be sure the <filename>SRC_URI</filename> variable is pointing to
+                       your kernel source files by removing the comment.
+                       Finally, be sure to substitute your user information in the statement:
                        <literallayout class='monospaced'>
-     KSRC_linux_yocto_3_2 ?= "/home/scottrif/linux-yocto-3.2.git"
+     KSRC_linux_yocto_3_4 ?= "/home/scottrif/linux-yocto-3.4.git"
+     SRC_URI = "git://${KSRC_linux_yocto_3_4};protocol=file;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"
                        </literallayout></para></listitem>
                </itemizedlist>
            </para>
@@ -447,7 +487,7 @@
                comment out the <filename>COMPATIBLE_MACHINE</filename> statements in all 
                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.2.bbappend</filename> in this example).</para>
+               (i.e. <filename>linux-yocto_3.4.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
@@ -464,11 +504,11 @@
                 Do the following:
                 <orderedlist>
                     <listitem><para>Your environment should be set up since you previously sourced
-                        the <filename>oe-init-build-env</filename> script.
+                        the <filename>&OE_INIT_FILE;</filename> script.
                         If it isn't, source the script again from <filename>poky</filename>.
                         <literallayout class='monospaced'>
      $ cd ~/poky
-     $ source oe-init-build-env
+     $ source &OE_INIT_FILE;
                         </literallayout>
                         </para></listitem>
                     <listitem><para>Be sure old images are cleaned out by running the 
@@ -506,299 +546,6 @@
             </para>
         </section>
     </section>
-
-    <section id='changing-the-kernel-configuration'>
-        <title>Changing the Kernel Configuration</title>
-
-        <para>
-            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>
-
-        <section id='getting-set-up-to-run-this-example'>
-            <title>Getting Set Up to Run this Example</title>
-
-            <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 source directory set up on your 
-                host machine.
-                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 
-                example.
-            </para>
-
-            <para>
-                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 
-                <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 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 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 &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 &DISTRO_NAME; set up to track remote branch &DISTRO_NAME; from origin.
-     Switched to a new branch '&DISTRO_NAME;'
-                </literallayout>
-            </para>
-
-            <para>
-                Next, you need to build the default <filename>qemux86</filename> image that you 
-                can boot using QEMU.
-                <note>
-                    Because a full build can take hours, you should check two variables in the 
-                    <filename>build</filename> directory that is created after you source the 
-                    <filename>oe-init-build-env</filename> script.
-                    You can find these variables
-                    <filename>BB_NUMBER_THREADS</filename> and <filename>PARALLEL_MAKE</filename>
-                    in the <filename>build/conf</filename> directory in the 
-                    <filename>local.conf</filename> configuration file.
-                    By default, these variables are commented out.
-                    If your host development system supports multi-core and multi-thread capabilities,
-                    you can uncomment these statements and set the variables to significantly shorten
-                    the full build time.
-                    As a guideline, set both the <filename>BB_NUMBER_THREADS</filename> and the 
-                    <filename>PARALLEL_MAKE</filename> variables to twice the number 
-                    of cores your machine supports.
-                </note>
-                The following two commands <filename>source</filename> the build environment setup script
-                and build the default <filename>qemux86</filename> image.
-                If necessary, the script creates the build directory:
-                <literallayout class='monospaced'>
-     $ cd ~/poky
-     $ source oe-init-build-env
-
-          ### Shell environment set up for builds. ###
-
-     You can now run 'bitbake &lt;target&gt;'
-
-     Common targets are:
-         core-image-minimal
-         core-image-sato
-         meta-toolchain
-         meta-toolchain-sdk
-         adt-installer
-         meta-ide-support
-
-     You can also run generated qemu images with a command like 'runqemu qemux86'
-                </literallayout>
-            </para>
-
-            <para>
-                The following <filename>bitbake</filename> command starts the build:
-                <literallayout class='monospaced'>
-     $ bitbake -k core-image-minimal
-                </literallayout>
-                <note>Be sure to check the settings in the <filename>local.conf</filename>
-                before starting the build.</note>
-            </para>
-        </section>
-
-        <section id='examining-the-default-config-smp-behavior'>
-            <title>Examining the Default&nbsp;&nbsp;<filename>CONFIG_SMP</filename> Behavior</title>
-
-            <para>
-                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 4"
-                </literallayout>
-            </para>
-
-            <para>
-                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 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.
-            </para>
-        </section>
-
-        <section id='changing-the-config-smp-configuration-using-menuconfig'>
-            <title>Changing the&nbsp;&nbsp;<filename>CONFIG_SMP</filename> Configuration Using&nbsp;&nbsp;<filename>menuconfig</filename></title>
-
-            <para>
-                The <filename>menuconfig</filename> tool provides an interactive method with which
-                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 build directory.
-                If you have not sourced this script do so with the following commands:
-                <literallayout class='monospaced'>
-     $ cd ~/poky
-     $ source oe-init-build-env
-                </literallayout>
-            </para>
-
-            <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.2</filename>
-                kernel.
-                The OpenEmbedded build system recognizes this kernel as 
-                <filename>linux-yocto</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>
-            </para>
-                  
-            <para>
-                Once <filename>menuconfig</filename> launches, navigate through the user interface
-                to find the <filename>CONFIG_SMP</filename> configuration setting.
-                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 "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 Yocto Project kernel
-                when it is built. 
-                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-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 is not set
-                </literallayout>
-            </para>
-
-            <para>
-                A good method to isolate changed configurations is to use a combination of the 
-                <filename>menuconfig</filename> tool and simple shell commands.
-                Before changing configurations with <filename>menuconfig</filename>, copy the 
-                existing <filename>.config</filename> and rename it to something else,
-                use <filename>menuconfig</filename> to make 
-                as many changes an you want and save them, then compare the renamed configuration 
-                file against the newly created file.
-                You can use the resulting differences as your base to create configuration fragments
-                to permanently save in your kernel layer.
-                <note>
-                    Be sure to make a copy of the <filename>.config</filename> and don't just
-                    rename it. 
-                    The build system needs an existing <filename>.config</filename>
-                    from which to work.
-                </note>
-            </para>
-        </section>
-
-        <section id='recompiling-the-kernel-and-testing-the-new-configuration'>
-            <title>Recompiling the Kernel and Testing the New Configuration</title>
-
-            <para>
-                At this point, you are ready to recompile your kernel image with 
-                the new setting in effect using the BitBake command below:
-                <literallayout class='monospaced'>
-     $ bitbake linux-yocto
-                </literallayout>
-            </para>
- 
-            <para>
-                Now run the QEMU emulator and pass it the same multi-processor option as before:
-                <literallayout class='monospaced'>
-     $ runqemu qemux86 qemuparams="-smp 4"
-                </literallayout>
-            </para>
-
-            <para>
-                Login to the machine using <filename>root</filename> with no password
-                and test for the number of processors the kernel supports:
-                <literallayout class='monospaced'>
-     # cat /proc/cpuinfo | grep processor 
-     processor       : 0
-     #
-                </literallayout>
-            </para>
-
-            <para>
-                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>
-
-    <section id='adding-kernel-recipes'>
-        <title>Adding Kernel Recipes</title>
-
-        <para>
-            A future release of this manual will present an example that adds kernel recipes, which provide 
-            new functionality to the kernel.
-        </para>
-
-        <para>
-            <imagedata fileref="figures/wip.png" 
-                width="2in" depth="3in" align="center" scalefit="1" />
-        </para> 
-    </section> 
 </appendix>
 
 <!--

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

@@ -8,23 +8,26 @@
 
 <para>
     Many development models exist for which you can use the Yocto Project. 
-    This chapter overviews the following methods:
+    This chapter overviews simple methods that use tools provided by the 
+    Yocto Project:
     <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.
+             For an example on how to create a BSP, see the 
+             "<ulink url='&YOCTO_DOCS_BSP_URL;#creating-a-new-bsp-layer-using-the-yocto-bsp-script'>Creating a New BSP Layer Using the yocto-bsp Script</ulink>"
+             section in the Yocto Project Board Support Package (BSP) Developer's Guide.
              </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 
+             For information on how to set up your host development system for user-space
+             application development, see the 
              <ulink url='&YOCTO_DOCS_ADT_URL;'>Yocto Project Application Developer's Guide</ulink>.
+             For a simple example of user-space application development using the 
+             <trademark class='trade'>Eclipse</trademark> IDE, see the 
+             "<link linkend='application-development-workflow'>Application 
+             Development Workflow</link>" section.
              </para></listitem>
          <listitem><para><emphasis>Temporary Source Code Modification:</emphasis>
              Direct modification of temporary source code is a convenient development model
@@ -51,7 +54,7 @@
         a specific hardware target.  
         Usually, when you want to create an image that runs on embedded hardware, the image does 
         not require the same number of features that a full-fledged Linux distribution provides.
-        Thus, you can create a much smaller image that is designed to use only the hardware
+        Thus, you can create a much smaller image that is designed to use only the 
         features for your particular hardware.
     </para>
 
@@ -65,9 +68,9 @@
         <title>Developing a Board Support Package (BSP)</title>
 
         <para>
-            A BSP is a packageof recipes that, when applied, during a build results in 
+            A BSP is a package of 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.  
+            Thus, the package when compiled into the new image, supports the operation of the board.  
         </para>
 
         <note>
@@ -77,9 +80,11 @@
 
         <para>
             The remainder of this section presents the basic steps used to create a BSP 
-            based on an existing BSP that ships with the Yocto Project.
-            You can reference the "<link linkend='dev-manual-bsp-appendix'>BSP Development Example</link>"
-            appendix for a detailed example that uses the Crown Bay BSP as a base BSP from which to start.
+            using the Yocto Project's 
+            <ulink url='&YOCTO_DOCS_BSP_URL;#using-the-yocto-projects-bsp-tools'>BSP Tools</ulink>.
+            For an example that shows how to create a new layer using the tools, see the
+            "<ulink url='&YOCTO_DOCS_BSP_URL;#creating-a-new-bsp-layer-using-the-yocto-bsp-script'>Creating a New BSP Layer Using the yocto-bsp Script</ulink>"
+             section in the Yocto Project Board Support Package (BSP) Developer's Guide.
         </para>
 
         <para>
@@ -99,43 +104,30 @@
                     "<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 project files on your 
-                    system</emphasis>:  You need this <link linkend='source-directory'>source 
-                    directory</link> available on your host system. 
+                    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 set up the source directory, see the
+                    For information on how to set up the 
+                    <link linkend='source-directory'>Source Directory</link>, 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
+                <listitem><para><emphasis>Establish the <filename>meta-intel</filename>
+                    repository on your system</emphasis>:  Having local copies of the 
+                    supported BSP layers 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 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.  
-                    While it is possible to create everything from scratch, basing your new BSP 
-                    on something that is close is much easier.  
-                    Or, at a minimum, leveraging off an existing BSP
-                    gives you some structure with which to start.</para>
-                    <para>At this point you need to understand your target hardware well enough to determine which 
-                    existing BSP it most closely matches.  
-                    Things to consider are your hardware’s on-board features, such as CPU type and graphics support.  
-                    You should look at the README files for supported BSPs to get an idea of which one 
-                    you could use.  
-                    A generic <trademark class='registered'>Intel</trademark> 
-                    <trademark class='trade'>Atom</trademark>-based BSP to consider is the 
-                    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 
-                    <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 
+                <listitem><para><emphasis>Create your own BSP layer using the 
+                    <ulink url='&YOCTO_DOCS_BSP_URL;#creating-a-new-bsp-layer-using-the-yocto-bsp-script'><filename>yocto-bsp</filename></ulink> script</emphasis>:  
+                    Layers are ideal for 
                     isolating and storing work for a given piece of hardware.  
                     A layer is really just a location or area in which you place the recipes for your BSP.
-                    In fact, a BSP is, in itself, a special type of layer.   
+                    In fact, a BSP is, in itself, a special type of layer.
+                    The simplest way to create a new BSP layer that is compliant with the 
+                    Yocto Project is to use the <filename>yocto-bsp</filename> script. 
+                    For information about that script, see the 
+                    "<ulink url='&YOCTO_DOCS_BSP_URL;#creating-a-new-bsp-layer-using-the-yocto-bsp-script'>Creating a New BSP Layer Using the yocto-bsp Script</ulink>" 
+                    section in the Yocto Project Board Support (BSP) Developer's Guide.   
                     </para>
                     <para>
                     Another example that illustrates a layer is an application.  
@@ -156,44 +148,54 @@
                     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 <link linkend='source-directory'>source directory</link>.
-                    On the other hand, BSP layers for Crown Bay, Emenlow, Jasper Forest, 
-                    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>
+                    within the <link linkend='source-directory'>Source Directory</link>.
+                    On the other hand, BSP layers for Cedar Trail, Chief River, Crown Bay, 
+                    Crystal Forest, Emenlow, Fish River, Fish River 2, Jasper Forest, N450, 
+                    Romley, sys940x, Sugar Bay, and tlk exist in their own separate layers 
+                    within the larger <filename>meta-intel</filename> layer.</note>
                     <para>When you set up a layer for a new BSP, you should follow a standard layout.  
                     This layout is described in the section
                     "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-filelayout'>Example Filesystem Layout</ulink>"
                     section of the Board Support Package (BSP) Development Guide.  
                     In the standard layout, you will notice a suggested structure for recipes and  
                     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 
-                    source directory.</para></listitem>
+                    You can see the standard layout for a BSP by examining 
+                    any supported BSP found in the <filename>meta-intel</filename> layer inside
+                    the 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>
                     directories within the BSP layer.
                     Configuration changes identify where your new layer is on the local system
                     and identify which kernel you are going to use.
+                    When you run the <filename>yocto-bsp</filename> script you are able to interactively
+                    configure many things for the BSP (e.g. keyboard, touchscreen, and so forth).
                     </para></listitem>
                 <listitem><para><emphasis>Make recipe changes to your new BSP layer</emphasis>:  Recipe 
                     changes include altering recipes (<filename>.bb</filename> files), removing 
-                    recipes you don't use, and adding new recipes that you need to support your hardware.
+                    recipes you don't use, and adding new recipes or append files 
+                    (<filename>.bbappend</filename>) that you need to support your hardware.
                     </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 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>
+                    and you need to be sure two key configuration files are configured appropriately:
+                    the <filename>conf/local.conf</filename> and the 
+                    <filename>conf/bblayers.conf</filename> file.
+                    You must make the OpenEmbedded build system aware of your new layer.
+                    See the 
+                    "<link linkend='enabling-your-layer'>Enabling Your Layer</link>" section
+                    for information on how to let the build system know about your new layer.</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 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='&BITBAKE_DOCS_URL;'>here</ulink>.</para>
+                    You can find more information about BitBake in the user manual, which is found in the 
+                    <filename>bitbake/doc/manual</filename> directory of the 
+                    <link linkend='source-directory'>Source Directory</link>.</para>
                     <para>The build process supports several types of images to satisfy different needs.  
                     See the 
                     "<ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Images</ulink>" chapter 
@@ -230,9 +232,11 @@
             kernel architecture and the steps to modify the kernel.
             For a complete discussion of the kernel, see the
             <ulink url='&YOCTO_DOCS_KERNEL_URL;'>Yocto Project Kernel Architecture and Use Manual</ulink>.
-            You can reference the appendix 
-            "<link linkend='dev-manual-kernel-appendix'>Kernel Modification Example</link>"
-            for a detailed example that changes the configuration of a kernel.
+            You can reference the  
+            "<link linkend='patching-the-kernel'>Patching the Kernel</link>" section
+            for an example that changes the source code of the kernel.
+            For information on how to configure the kernel, see the 
+            "<link linkend='configuring-the-kernel'>Configuring the Kernel</link> section.
         </para>
 
         <section id='kernel-overview'>
@@ -266,6 +270,9 @@
                     <listitem><para><emphasis><filename>linux-yocto-3.2</filename></emphasis> - The 
                     stable Yocto Project kernel to use with the Yocto Project Release 1.2. This kernel 
                     is based on the Linux 3.2 released kernel.</para></listitem>
+                    <listitem><para><emphasis><filename>linux-yocto-3.4</filename></emphasis> - The 
+                    stable Yocto Project kernel to use with the Yocto Project Release 1.3. This kernel 
+                    is based on the Linux 3.4 released kernel.</para></listitem>
                     <listitem><para><emphasis><filename>linux-yocto-dev</filename></emphasis> - A development
                     kernel based on the latest upstream release candidate available.</para></listitem>
                 </itemizedlist>
@@ -316,8 +323,8 @@
             </note>
 
             <para>
-                Storage of all the available kernel source code is one thing, while representing the 
-                code on your host development system is another.  
+                Upstream storage of all the available kernel source code is one thing, while 
+                representing and using the code on your host development system is another.  
                 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 
@@ -326,43 +333,19 @@
             </para>
 
             <para>
-                You make kernel source code available on your host development system by using 
-                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'>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>
-
-            <para>
-                This next figure illustrates how the kernel source files might be arranged on 
-                your host system.
-            </para>
-
-            <para>
-                <imagedata fileref="figures/kernel-overview-3-denzil.png" 
-                    width="6in" depth="4in" align="center" scale="100" />
-            </para> 
-
-            <para>
-                In the previous figure, the file structure on the left represents the bare clone 
-                set up to track the Yocto Project kernel Git repository. 
-                The structure on the right represents the copy of the bare clone. 
-                When you make modifcations to the kernel source code, this is the area in which 
-                you work.
-                Once you make corrections, you must use Git to push the committed changes to the 
-                bare clone.
-                The example in <xref linkend='modifying-the-kernel-source-code'>
-                Modifying the Kernel Source Code</xref> provides a detailed example.
+                Kernel source code is available on your host system a couple of different
+                ways.
+                If you are working in the kernel all the time, you probably would want
+                to set up your own local Git repository of the kernel tree.
+                If you just need to make some patches to the kernel, you can get at 
+                temporary kernel source files extracted and used during the OpenEmbedded
+                build system. 
+                We will just talk about working with the temporary source code.
             </para>
 
             <para>
                 What happens during the build?  
-                When you build the kernel on your development system all files needed for the build
+                When you build the kernel on your development system, all files needed for the build
                 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.
@@ -371,11 +354,13 @@
             </para>
                 The following figure shows the temporary file structure
                 created on your host system when the build occurs. 
-                This build directory contains all the source files used during the build.
+                This 
+                <link linkend='build-directory'>Build Directory</link> contains all the 
+                source files used during the build.
             </para>
 
             <para>
-                <imagedata fileref="figures/kernel-overview-2.png" 
+                <imagedata fileref="figures/kernel-overview-2-generic.png" 
                     width="6in" depth="5in" align="center" scale="100" />
             </para> 
 
@@ -384,7 +369,7 @@
                 branching strategy, see the
                 <ulink url='&YOCTO_DOCS_KERNEL_URL;'>Yocto Project Kernel Architecture and Use Manual</ulink>.
                 You can also reference the
-                "<link linkend='modifying-the-kernel-source-code'>Modifying the Kernel Source Code</link>"
+                "<link linkend='patching-the-kernel'>Patching the Kernel</link>"
                 section for a detailed example that modifies the kernel.
             </para>
         </section> 
@@ -398,7 +383,7 @@
 
             <para>
                 <imagedata fileref="figures/kernel-dev-flow.png" 
-                    width="6in" depth="7.5in" align="center" scalefit="1" />
+                    width="6in" depth="5in" align="center" scalefit="1" />
             </para> 
 
             <para>
@@ -415,43 +400,39 @@
                         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 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 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 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 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). 
-                        The copy of the bare clone is a local Git repository that contains all the kernel's 
-                        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'>Yocto Project Kernel</link>" 
-                        earlier in this manual.</para></listitem>
+                    <listitem><para><emphasis>Establish the temporary kernel source files</emphasis>:  
+                        Temporary kernel source files are kept in the Build Directory created by the 
+                        OpenEmbedded build system when you run BitBake.
+                        If you have never built the kernel you are interested in, you need to run 
+                        an initial build to establish local kernel source files.</para>
+                        <para>If you are building an image for the first time, you need to get the build 
+                        environment ready by sourcing 
+                        the environment setup script.
+                        You also need to be sure two key configuration files 
+                        (<filename>local.conf</filename> and <filename>bblayers.conf</filename>)
+                        are configured appropriately.</para>
+                        <para>The entire process for building an image is overviewed in the 
+                        "<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.
+                        You can find more information on BitBake in the user manual, which is found in the
+                        <filename>bitbake/doc/manual</filename> directory of the 
+                        <link linkend='source-directory'>Source Directory</link>.</para>
+                        <para>The build process supports several types of images to satisfy different needs.  
+                        See the "<ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Images</ulink>" chapter in 
+                        the Yocto Project Reference Manual for information on supported images.
+                        </para></listitem>
                     <listitem><para><emphasis>Make changes to the kernel source code if 
                         applicable</emphasis>:  Modifying the kernel does not always mean directly
                         changing source files. 
-                        However, if you have to do this, you make the changes in the local 
-                        Git repository you set up to hold the source files (i.e. the copy of the 
-                        bare clone).
-                        Once the changes are made, you need to use Git commands to commit the changes
-                        and then push them to the bare clone.</para></listitem>                      
+                        However, if you have to do this, you make the changes to the files in the 
+                        Build directory.</para></listitem>                      
                     <listitem><para><emphasis>Make kernel configuration changes
                         if applicable</emphasis>:  
                         If your situation calls for changing the kernel's configuration, you can 
-                        use <filename>menuconfig</filename>
+                        use the <filename>yocto-kernel</filename> script or <filename>menuconfig</filename>
                         to enable and disable kernel configurations.  
+                        Using the script lets you interactively set up kernel configurations.
                         Using <filename>menuconfig</filename> allows you to interactively develop and test the 
                         configuration changes you are making to the kernel.
                         When saved, changes using <filename>menuconfig</filename> update the kernel's
@@ -467,51 +448,8 @@
                         <filename>.config</filename> file against a saved original and gather those
                         changes into a config fragment to be referenced from within the kernel's   
                         <filename>.bbappend</filename> file.</para></listitem>                      
-                    <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 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> 
-                        file that appends information to the kernel's recipe file used during the 
-                        build.
-                        </para></listitem>
-                    <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 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 
-                        (<filename>local.conf</filename> and <filename>bblayers.conf</filename>)
-                        are configured appropriately.</para>
-                        <para>The entire process for building an image is overviewed in the 
-                        "<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.
-                        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 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='&BITBAKE_DOCS_URL;'>here</ulink>.</para>
-                        <para>The build process supports several types of images to satisfy different needs.  
-                        See the "<ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Images</ulink>" chapter in 
-                        the Yocto Project Reference Manual for information on supported images.</para></listitem>
-                    <listitem><para><emphasis>Make your configuration changes available
-                        in the kernel layer</emphasis>:  Up to this point, all the configuration changes to the 
-                        kernel have been done and tested iteratively.  
-                        Once they are tested and ready to go, you can move them into the kernel layer, 
-                        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 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> 
+                    <listitem><para><emphasis>Rebuild the kernel image with your changes</emphasis>:  
+                        Rebuilding the kernel image applies your changes.</para></listitem>
                 </orderedlist>
             </para>
         </section>
@@ -530,7 +468,8 @@
         facilitate quick development and integration of your application into its run-time environment. 
         Using the ADT and toolchains, you can compile and link your application. 
         You can then deploy your application to the actual hardware or to the QEMU emulator for testing.
-        If you are familiar with the popular Eclipse IDE, you can use an Eclipse Yocto Plug-in to 
+        If you are familiar with the popular <trademark class='trade'>Eclipse</trademark> IDE, 
+        you can use an Eclipse Yocto Plug-in to 
         allow you to develop, deploy, and test your application all from within Eclipse.
     </para>
 
@@ -574,10 +513,9 @@
                     (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;'>  
-                                <filename>machines</filename></ulink> if your target architecture is supported
-                                and you are going to develop and test your application on actual hardware. 
-                                </para></listitem>
+                                <ulink url='&YOCTO_MACHINES_DL_URL;'><filename>machines</filename></ulink>
+                                if your target architecture is supported and you are going to develop 
+                                and test your application on actual hardware.</para></listitem>
                             <listitem><para>Download the image from the 
                                 <ulink url='&YOCTO_QEMU_DL_URL;'>  
                                 <filename>machines/qemu</filename></ulink> if your target architecture is supported
@@ -588,9 +526,8 @@
                                 If your target architecture is similar to a supported architecture, you can 
                                 modify the kernel image before you build it.
                                 See the 
-                                "<link linkend='kernel-modification-workflow'>Kernel Modification Workflow</link>"
-                                section earlier in this manual for information on how to create a modified 
-                                Yocto Project kernel.</para></listitem>
+                                "<link linkend='patching-the-kernel'>Patching the Kernel</link>"
+                                section for an example.</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
@@ -606,14 +543,27 @@
                     "<ulink url='&YOCTO_DOCS_ADT_URL;#using-the-adt-installer'>Using the ADT Installer</ulink>"
                     section 
                     in the Yocto Project Application Developer's Guide.</para></listitem>
-                <listitem><para><emphasis>If Applicable, Secure the Target Root Filesystem</emphasis>:  
+                <listitem><para><emphasis>If Applicable, Secure the Target Root Filesystem 
+                    and the Cross-development Toolchain</emphasis>:  
                     If you choose not to install the ADT using the ADT Installer,
-                    you need to find and download the 
-                    appropriate root filesystems.
-                    You can find these tarballs in the same areas used for the kernel images.
+                    you need to find and download the appropriate root filesystem and 
+                    the cross-development toolchain.</para>
+                    <para>You can find the tarballs for the root filesystem in the same area used 
+                    for the kernel image.
                     Depending on the type of image you are running, the root filesystem you need differs. 
                     For example, if you are developing an application that runs on an image that 
-                    supports Sato, you need to get root filesystem that supports Sato.
+                    supports Sato, you need to get root filesystem that supports Sato.</para>
+                    <para>You can find the cross-development toolchains at
+                    <ulink url='&YOCTO_TOOLCHAIN_DL_URL;'><filename>toolchains</filename></ulink>.
+                    Be sure to get the correct toolchain for your development host and your 
+                    target architecture.
+                    See the "<ulink url='&YOCTO_DOCS_ADT_URL;#using-an-existing-toolchain-tarball'>Using a Cross-Toolchain Tarball</ulink>"
+                    section in the Yocto Project Application Developer's Guide for information 
+                    and the 
+                    "<ulink url='&YOCTO_DOCS_QS_URL;#installing-the-toolchain'>Installing the Toolchain</ulink>"
+                    in the Yocto Project Quick Start for information on finding and installing 
+                    the correct toolchain based on your host development system and your target
+                    architecture.
                     </para></listitem>
                 <listitem><para><emphasis>Create and Build your Application</emphasis>:  
                     At this point, you need to have source files for your application.
@@ -624,13 +574,13 @@
                 <listitem><para><emphasis>Deploy the Image with the Application</emphasis>:  
                     If you are using the Eclipse IDE, you can deploy your image to the hardware or to 
                     QEMU through the project's preferences.  
-                    If you are not using the Eclipse IDE, then you need to deploy the application using 
-                    other methods to the hardware.
+                    If you are not using the Eclipse IDE, then you need to deploy the application 
+                    to the hardware using other methods.
                     Or, if you are using QEMU, you need to use that tool and load your image in for testing. 
                     </para></listitem>                      
                 <listitem><para><emphasis>Test and Debug the Application</emphasis>:  
                     Once your application is deployed, you need to test it.
-                    Within the Eclipse IDE, you can use the debubbing environment along with the 
+                    Within the Eclipse IDE, you can use the debugging environment along with the 
                     set of user-space tools installed along with the ADT to debug your application. 
                     Of course, the same user-space tools are available separately if you choose
                     not to use the Eclipse IDE.</para></listitem>
@@ -712,9 +662,9 @@
                 <para>
                     Once you have downloaded the tarball, extract it into a clean 
                     directory.
-                    For example, the following commands unpack and install the Eclipse IDE
-                    tarball found in the <filename>Downloads</filename> area 
-                    into a clean directory using the default name <filename>eclipse</filename>:
+                    For example, the following commands unpack and install the 
+                    downloaded Eclipse IDE tarball into a clean directory 
+                    using the default name <filename>eclipse</filename>:
                     <literallayout class='monospaced'>
      $ cd ~
      $ tar -xzvf ~/Downloads/eclipse-SDK-4.2-linux-gtk-x86_64.tar.gz
@@ -857,7 +807,7 @@
                     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 
-                    Yocto Project source repositories.
+                    Yocto Project's Source Repositories.
                 </para>
 
                 <section id='new-software'>
@@ -898,24 +848,36 @@
                                 </literallayout>
                                 For this example, the repository is named     
                                 <filename>~/yocto-eclipse</filename>.</para></listitem>
+                            <listitem><para>Be sure you are in the right branch for your Git repository.
+                                For this release set the branch to <filename>&DISTRO_NAME;</filename>:
+                                <literallayout class='monospaced'>
+     $ git checkout -b &DISTRO_NAME; origin/&DISTRO_NAME;
+                                </literallayout></para></listitem>
                             <listitem><para>Locate the <filename>build.sh</filename> script in the 
                                 Git repository you created in the previous step.
                                 The script is located in the <filename>scripts</filename>.</para></listitem>
                             <listitem><para>Be sure to set and export the <filename>ECLIPSE_HOME</filename> environment
-                                variable to the top-level directory in which you installed the Indigo  
-                                version of Eclipse.
+                                variable to the top-level directory in which you installed your version of Eclipse.
                                 For example, if your Eclipse directory is <filename>$HOME/eclipse</filename>, 
                                 use the following:
                                 <literallayout class='monospaced'>
      $ export ECLIPSE_HOME=$HOME/eclipse
                                 </literallayout></para></listitem>
-                            <listitem><para>Run the <filename>build.sh</filename> script and provide the 
-                                name of the Git branch along with the Yocto Project release you are 
-                                using.
-                                Here is an example that uses the <filename>master</filename> Git repository
-                                and the <filename>1.1M4</filename> release:
+                            <listitem><para>Be sure you have the right branch in the Poky Git repository
+                                checked out.
+                                For example, the following commands checkout the <filename>&DISTRO_NAME;</filename>
+                                branch in the local Poky Git repository:
                                 <literallayout class='monospaced'>
-     $ scripts/build.sh master 1.1M4 
+     $ cd ~/poky
+     $ git checkout -b &DISTRO_NAME; origin/&DISTRO_NAME;
+                                </literallayout></para></listitem>
+                            <listitem><para>Move back to your Yocto Eclipse directory and 
+                                run the <filename>build.sh</filename> script.  
+                                Provide the name of the Git branch along with the Yocto Project release you are 
+                                using.
+                                Here is an example that uses the <filename>&DISTRO_NAME;</filename> branches:
+                                <literallayout class='monospaced'>
+     $ scripts/build.sh &DISTRO_NAME; &DISTRO_NAME; 
                                 </literallayout>
                                 After running the script, the file
                                 <filename>org.yocto.sdk-&lt;release&gt;-&lt;date&gt;-archive.zip</filename>
@@ -928,9 +890,10 @@
                             <listitem><para>Provide anything you want in the "Name" field.</para></listitem>
                             <listitem><para>Click "Archive" and browse to the ZIP file you built 
                                 in step four.  
-                               This ZIP file should not be "unzipped", and must be the 
+                                This ZIP file should not be "unzipped", and must be the 
                                 <filename>*archive.zip</filename> file created by running the 
                                 <filename>build.sh</filename> script.</para></listitem>
+                            <listitem><para>Click through the "Okay" buttons.</para></listitem>
                             <listitem><para>Check the box next to the new entry in the installation window and complete
                         the installation.</para></listitem>
                             <listitem><para>Restart the Eclipse IDE if necessary.</para></listitem>
@@ -1051,10 +1014,17 @@
                                 Developer's Guide for information on how to install the toolchain into the build 
 directory.</para></listitem> 
                             <listitem><para><emphasis>Specify the Sysroot Location:</emphasis>
-                                This location is where the root filesystem for the 
-                                target hardware is created on the development system by the ADT Installer.
-                                The QEMU user-space tools, the 
-                                NFS boot process, and the cross-toolchain all use the sysroot location.
+                                This location is where the root filesystem for the target hardware resides. 
+                                If you used the ADT Installer, then the location is 
+                                <filename>/opt/poky/&lt;release&gt;</filename>.
+                                Additionally, when you use the ADT Installer, the same location is used for 
+                                the QEMU user-space tools and the NFS boot process.</para>
+                                <para>If you used either of the other two methods to install the toolchain, then the 
+                                location of the sysroot filesystem depends on where you separately
+                                extracted and intalled the filesystem.</para>
+                                <para>For information on how to install the toolchain and on how to extract 
+                                and install the sysroot filesystem, see the
+                                "<ulink url='&YOCTO_DOCS_ADT_URL;#installing-the-adt'>Installing the ADT and Toolchains</ulink>" section.
                                 </para></listitem>
                             <listitem><para><emphasis>Select the Target Architecture:</emphasis>
                                 The target architecture is the type of hardware you are 
@@ -1175,7 +1145,11 @@ directory.</para></listitem>
                         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>
+                    <listitem><para>Make your configurations for the project and click "OK".
+                        If you are running the Juno version of Eclipse, you can skip down to the next
+                        section where you build the project. 
+                        If you are not working with Juno, you need to reconfigure the project as 
+                        described in the next step.</para></listitem>
                     <listitem><para>Select <filename>Project -&gt; Reconfigure Project</filename>:   
                         This selection reconfigures the project by running
                        <filename>autogen.sh</filename> in the workspace for your project.  
@@ -1193,7 +1167,9 @@ directory.</para></listitem>
             <title>Building the Project</title>
 
             <para>
-                To build the project, select <filename>Project -&gt; Build Project</filename>.  
+                To build the project in Juno, right click on the project in the navigator pane and select
+                <filename>Build Project</filename>.
+                If you are not running Juno, select <filename>Project -&gt; Build Project</filename>.  
                 The console should update and you can note the cross-compiler you are using.
             </para>
         </section>
@@ -1252,7 +1228,7 @@ directory.</para></listitem>
                         <filename>New Connections</filename> Dialog.</para></listitem>
                     <listitem><para>Use the drop-down menu now in the <filename>Connection</filename> field and pick 
                         the IP Address you entered.</para></listitem>
-                    <listitem><para>Click <filename>Debug</filename> to bring up a login screen 
+                    <listitem><para>Click <filename>Run</filename> to bring up a login screen 
                         and login.</para></listitem>
                     <listitem><para>Accept the debug perspective.</para></listitem>
                 </orderedlist>
@@ -1300,7 +1276,7 @@ directory.</para></listitem>
                         to the local host machine, and uses the <filename>lttng</filename> Eclipse plug-in to 
                         graphically display the output. 
                         For information on how to use <filename>lttng</filename> to trace an application, see
-                        <ulink url='http://lttng.org/files/ust/manual/ust.html'></ulink>.</para>
+                        <ulink url='http://lttng.org/documentation'></ulink>.</para>
                         <para>For <filename>Application</filename>, you must supply the absolute path name of the 
                         application to be traced by user mode <filename>lttng</filename>.  
                         For example, typing <filename>/path/to/foo</filename> triggers 
@@ -1313,8 +1289,8 @@ directory.</para></listitem>
                         project.
                         Do the following:
                         <orderedlist>
-                            <listitem><para>Follow these 
-                                <ulink url='http://wiki.eclipse.org/Linux_Tools_Project/LTTng#Downloading_and_installing_the_LTTng_parser_library'>instructions</ulink>
+                            <listitem><para>Follow the instructions from the  
+                                <ulink url='http://wiki.eclipse.org/Linux_Tools_Project/LTTng2/User_Guide'>Linux Tools Projec/LTTng2/User Guide</ulink>
                                 to download and install the <filename>lttng</filename> parser library.
                                 </para></listitem>
                             <listitem><para>Select <filename>Window -> Open Perspective -> Other</filename>
@@ -1407,7 +1383,7 @@ directory.</para></listitem>
                             to open a new recipe wizard.</para></listitem>
                         <listitem><para>Point to your source by filling in the "SRC_URL" field.
                             For example, you can add a recipe to your 
-                            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>
+                            <link linkend='source-directory'>Source Directory</link>
                             by defining "SRC_URL" as follows:
                             <literallayout class='monospaced'>
      ftp://ftp.gnu.org/gnu/m4/m4-1.4.9.tar.gz
@@ -1519,7 +1495,7 @@ directory.</para></listitem>
             <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>:
+            <link linkend='source-directory'>Source Directory</link>:
             <literallayout class='monospaced'>
      S = ${WORKDIR}/${BP}
             </literallayout>
@@ -1527,8 +1503,9 @@ directory.</para></listitem>
             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:
+                The
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-BP'><filename>BP</filename></ulink>
+                represents the base recipe name, which consists of the name and version:
                 <literallayout class='monospaced'>
      BP = ${BPN}-${PV}
                 </literallayout>
@@ -1538,26 +1515,30 @@ directory.</para></listitem>
         <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:
+            on the recipe name and the architecture of the target device.
+            For example, here is the work directory for recipes and resulting packages that 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>
+            Assuming a top-level <link linkend='source-directory'>Source Directory</link>
+            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:
+            the following is the work directory for the <filename>acl</filename> recipe that 
+            creates 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:
+            If your resulting 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>
+            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:
@@ -1582,9 +1563,9 @@ directory.</para></listitem>
         </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.
+            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>
 
@@ -1670,10 +1651,10 @@ directory.</para></listitem>
                     <literallayout class='monospaced'>
      SRC_URI += "file://my_changes.patch"
                     </literallayout></para></listitem>
-                <listitem><para><emphasis>Increment the Package Revision Number:</emphasis>
+                <listitem><para><emphasis>Increment the Recipe 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>
+                    value in the recipe since the resulting packages have changed.</para></listitem>
             </orderedlist>
         </para>     </section>
 
@@ -1796,10 +1777,10 @@ directory.</para></listitem>
                     <literallayout class='monospaced'>
      SRC_URI += "file://my_changes.patch"
                     </literallayout></para></listitem>
-                <listitem><para><emphasis>Increment the Package Revision Number:</emphasis>
+                <listitem><para><emphasis>Increment the Recipe 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>
+                    value in the recipe since the resulting packages have changed.</para></listitem>
             </orderedlist>
         </para>
     </section>
@@ -1883,7 +1864,7 @@ directory.</para></listitem>
         or <filename>compile</filename> commands as if they were being run by 
         the OpenEmbedded build system itself.
         As noted earlier, the working directory also automatically changes to the 
-        source directory (<ulink url='&YOCTO_DOCS_REF_URL;#var-S'><filename>S</filename></ulink>).
+        Source Directory (<ulink url='&YOCTO_DOCS_REF_URL;#var-S'><filename>S</filename></ulink>).
     </para>
 
     <para> 

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

@@ -75,12 +75,12 @@
         Experience shows that buildbot is a good fit for this role. 
         What works well is to configure buildbot to make two types of builds:
         incremental and full (from scratch).  
-        See <ulink url='http://autobuilder.yoctoproject.org:8010/'>the buildbot for the 
+        See <ulink url='http://autobuilder.yoctoproject.org:8010/'>Welcome to the buildbot for the 
         Yocto Project</ulink> for an example implementation that uses buildbot.
     </para>
 
     <para>
-        You can tie incremental builds to a commit hook that triggers the build
+        You can tie an incremental build to a commit hook that triggers the build
         each time a commit is made to the metadata.  
         This practice results in useful acid tests that determine whether a given commit 
         breaks the build in some serious way. 
@@ -170,7 +170,7 @@
             <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, installers for 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 local copy of the 
                 Git repository but rather a snapshot of a particular release or image.</para>
@@ -207,14 +207,15 @@
                 <filename>formfactor_0.0.bb</filename> and <filename>formfactor_0.0.bbappend</filename>).
                 </para>
                 <para>Information in append files overrides the information in the similarly-named recipe file.
-                For examples of <filename>.bbappend</filename> file in use, see the
-                "<link linkend='using-bbappend-files'>Using .bbappend Files</link>" and 
-                "<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 
+                For an example of an append file in use, see the
+                "<link linkend='using-bbappend-files'>Using .bbappend Files</link>" section.
+                </para></listitem>
+            <listitem><para id='bitbake-term'><emphasis>BitBake:</emphasis>
+                The task executor and scheduler used by 
                 the OpenEmbedded build system to build images. 
-                For more information on BitBake, see the <ulink url='&BITBAKE_DOCS_URL;'>
-                BitBake documentation</ulink>.</para></listitem>
+                For more information on BitBake, see the BitBake documentation 
+                in the <filename>bitbake/doc/manual</filename> directory of the 
+                <link linkend='source-directory'>Source Directory</link>.</para></listitem>
             <listitem>
                 <para id='build-directory'><emphasis>Build Directory:</emphasis>
                 This term refers to the area used by the OpenEmbedded build system for builds.  
@@ -281,16 +282,16 @@
                 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.
+                You can use the OpenEmbedded build system to build a cross-development toolchain
+                installer that when run installs the toolchain that contains the development tools you 
+                need to cross-compile and test your software.
+                The Yocto Project ships with images that contain installers for 
+                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.
+                Images are the binary output that run on specific hardware or QEMU 
+                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'>Images</ulink>"
                 chapter in the Yocto Project Reference Manual.</para></listitem>
@@ -302,13 +303,27 @@
             <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 
+            <listitem><para id='oe-core'><emphasis>OE-Core:</emphasis> A core set of metadata originating 
                 with OpenEmbedded (OE) that is shared between OE and the Yocto Project.
                 This metadata is found in the <filename>meta</filename> directory of the source
                 directory.</para></listitem>
-            <listitem><para><emphasis>Package:</emphasis> The packaged output from a baked recipe.
+            <listitem><para><emphasis>Package:</emphasis> In the context of the Yocto Project, 
+                this term refers to 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>
+                You ‘bake’ something by running it through BitBake.</para>
+                <para>It is worth noting that the term "package" can, in general, have subtle
+                meanings.  For example, the packages refered to in the 
+                "<ulink url='&YOCTO_DOCS_QS_URL;#packages'>The Packages</ulink>" section are
+                compiled binaries that when installed add functionality to your Linux 
+                distribution.</para>
+                <para>Another point worth noting is that historically within the Yocto Project,
+                recipes were referred to as packages - thus, the existence of several BitBake 
+                variables that are seemingly mis-named, 
+                (e.g. <ulink url='&YOCTO_DOCS_REF_URL;#var-PR'><filename>PR</filename></ulink>,
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-PRINC'><filename>PRINC</filename></ulink>,
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-PV'><filename>PV</filename></ulink>, and 
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-PE'><filename>PE</filename></ulink>).
+                </para></listitem>
             <listitem><para 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
@@ -329,7 +344,8 @@
                 <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>.
+                the <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>
 
@@ -365,7 +381,7 @@
                 <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>
+                You do this by using Git tags that are part of the repository.</para>
 
                 <para>For more information on concepts around Git repositories, branches, and tags,
                 see the  
@@ -416,8 +432,8 @@
     </para>
 
     <para>
-        When you build an image using Yocto Project, the build process uses a known list of licenses to 
-        ensure compliance.
+        When you build an image using the Yocto Project, the build process uses a 
+        known list of licenses to ensure compliance.
         You can find this list in the Yocto Project files directory at 
         <filename>meta/files/common-licenses</filename>.  
         Once the build completes, the list of all licenses found and used during that build are 
@@ -513,10 +529,9 @@
             It is important to understand that Git tracks content change and not files.
             Git uses "branches" to organize different development efforts. 
             For example, the <filename>poky</filename> repository has 
-            <filename>laverne</filename>, <filename>bernard</filename>, 
-            <filename>edison</filename>, <filename>denzil</filename> and 
-            <filename>master</filename> branches among 
-            others.
+            <filename>bernard</filename>, 
+            <filename>edison</filename>, <filename>denzil</filename>, <filename>danny</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 
             clicking on the 
@@ -561,9 +576,8 @@
             at the time you created your local branch, which could be
             different than the files at the time of a similarly named release.
             In other words, creating and checking out a local branch based on the 
-            <filename>&DISTRO_NAME;</filename> branch name is not the same as creating and 
-            checking out a local branch based on the <filename>&DISTRO_NAME;-&DISTRO;</filename>
-            release.
+            <filename>&DISTRO_NAME;</filename> branch name is not the same as 
+            cloning and checking out the <filename>master</filename> branch.
             Keep reading to see how you create a local snapshot of a Yocto Project Release.
         </para>
 
@@ -579,7 +593,7 @@
         </para>
 
         <para>
-            Some key tags are <filename>laverne-4.0</filename>, <filename>bernard-5.0</filename>,
+            Some key tags are <filename>bernard-5.0</filename>, <filename>denzil-7.0</filename>,
             and <filename>&DISTRO_NAME;-&POKYVERSION;</filename>.
             These tags represent Yocto Project releases.
         </para>
@@ -661,17 +675,18 @@
                     a working branch on your local machine where you can isolate work.  
                     It is a good idea to use local branches when adding specific features or changes.  
                     This way if you don’t like what you have done you can easily get rid of the work.</para></listitem>
-                <listitem><para><emphasis><filename>git branch</filename>:</emphasis> Reports existing branches and 
-                    tells you which branch in which you are currently working.</para></listitem>
+                <listitem><para><emphasis><filename>git branch</filename>:</emphasis> Reports 
+                    existing local branches and 
+                    tells you the branch in which you are currently working.</para></listitem>
                 <listitem><para><emphasis><filename>git branch -D &lt;branch-name&gt;</filename>:</emphasis> 
-                    Deletes an existing branch.  
-                    You need to be in a branch other than the one you are deleting 
-                    in order to delete &lt;branch-name&gt;.</para></listitem>
+                    Deletes an existing local branch.  
+                    You need to be in a local branch other than the one you are deleting 
+                    in order to delete <filename>&lt;branch-name&gt;</filename>.</para></listitem>
                 <listitem><para><emphasis><filename>git pull</filename>:</emphasis> Retrieves information 
                     from an upstream Git 
                     repository and places it in your local Git repository.  
                     You use this command to make sure you are synchronized with the repository 
-                    from which you are basing changes (.e.g. the master repository).</para></listitem>
+                    from which you are basing changes (.e.g. the master branch).</para></listitem>
                 <listitem><para><emphasis><filename>git push</filename>:</emphasis> Sends all your local changes you 
                     have committed to an upstream Git repository (e.g. a contribution repository).  
                     The maintainer of the project draws from these repositories when adding your changes to the 
@@ -753,6 +768,8 @@
         A somewhat formal method exists by which developers commit changes and push them into the 
         "contrib" area and subsequently request that the maintainer include them into "master"  
         This process is called “submitting a patch” or “submitting a change.”  
+        For information on submitting patches and changes, see the 
+        "<link linkend='how-to-submit-a-change'>How to Submit a Change</link>" section.
     </para>
 
     <para>
@@ -815,13 +832,18 @@
                 <filename>send-pull-request</filename> that ship with the release to facilitate this 
                 workflow.
                 You can find these scripts in the local Yocto Project files Git repository in
-                the <filename>scripts</filename> directory.</para></listitem>
+                the <filename>scripts</filename> directory.</para>
+                <para>You can find more information on these scripts in the 
+                "<link linkend='pushing-a-change-upstream'>Using
+                Scripts to Push a Change Upstream and Request a Pull</link>" section.
+                </para></listitem>
             <listitem><para><emphasis>Patch Workflow:</emphasis> This workflow allows you to notify the 
                 maintainer through an email that you have a change (or patch) you would like considered 
                 for the "master" branch of the Git repository.  
                 To send this type of change you format the patch and then send the email using the Git commands 
                 <filename>git format-patch</filename> and <filename>git send-email</filename>. 
-                You can find information on how to submit later in this chapter.</para></listitem>
+                You can find information on how to submit changes 
+                later in this chapter.</para></listitem>
         </itemizedlist>
     </para>
 </section>
@@ -853,8 +875,9 @@
                 a bug.</para></listitem>
             <listitem><para>When submitting a new bug, be sure to choose the appropriate
                 Classification, Product, and Component for which the issue was found.
-                Defects for Yocto Project fall into one of four classifications:  Yocto Projects, 
-                Infrastructure, Poky, and Yocto Metadata Layers.
+                Defects for Yocto Project fall into one of six classifications:  Yocto Project
+                Components, Infrastructure, Build System &amp; Metadata, Documentation,
+                QA/Testing, and Runtime. 
                 Each of these Classifications break down into multiple Products and, in some 
                 cases, multiple Components.</para></listitem>
             <listitem><para>Use the bug form to choose the correct Hardware and Architecture
@@ -903,7 +926,8 @@
                 <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
+            <listitem><para>For changes to other layers hosted on 
+                <filename>yoctoproject.org</filename> (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>
@@ -967,7 +991,8 @@
         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.
+        change is a simple, self-explanatory change that needs no further description 
+        beyond the summary.
         Here are the guidelines for composing a commit message:
         <itemizedlist>
             <listitem><para>Provide a single-line, short summary of the change.
@@ -1028,8 +1053,8 @@
                     pull requests to the Yocto Project.
                     These scripts are <filename>create-pull-request</filename> and 
                     <filename>send-pull-request</filename>.
-                    You can find these scripts in the <filename>scripts</filename> directory of the 
-                    Yocto Project file structure.</para>
+                    You can find these scripts in the <filename>scripts</filename> directory 
+                    within the <link linkend='source-directory'>Source Directory</link>.</para>
                     <para>Using these scripts correctly formats the requests without introducing any
                     whitespace or HTML formatting.
                     The maintainer that receives your patches needs to be able to save and apply them 

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

@@ -32,7 +32,7 @@
 
     <para>
         You can use the OpenEmbedded build system, which uses 
-        <ulink url='&BITBAKE_DOCS_URL;'>BitBake</ulink>, to develop complete Linux 
+        BitBake to develop complete Linux 
         images and associated user-space applications for architectures based on ARM, MIPS, PowerPC, 
         x86 and x86-64.  
         While the Yocto Project does not provide a strict testing framework,
@@ -54,7 +54,11 @@
                 Linux-based host system.
                 You will have the best results with a recent release of Fedora, 
                 OpenSUSE, Ubuntu, or CentOS as these releases are frequently tested against the Yocto Project
-                and officially supported.  
+                and officially supported. 
+                For a list of the distributions under validation and their status, see the
+                <ulink url='&YOCTO_WIKI_URL;/wiki/Distribution_Support'>Distribution
+                Support</ulink> wiki page.</para>
+                <para>
                 You should also have about 100 gigabytes of free disk space for building images.
                 </para></listitem>
             <listitem><para><emphasis>Packages:</emphasis>  The OpenEmbedded build system
@@ -119,7 +123,7 @@
                 If you are going to be making modifications to a supported Yocto Project kernel, you 
                 need to establish local copies of the source.
                 You can find Git repositories of supported Yocto Project Kernels organized under
-                "Yocto Project Linux Kernel" in the Yocto Project Source Repositories at
+                "Yocto 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 Yocto Project kernel and then 
                 copying that cloned repository.
@@ -127,18 +131,18 @@
                 For simplicity, it is recommended that you create these structures outside of the 
                 source directory (usually <filename>poky</filename>).</para>
                 <para>As an example, the following transcript shows how to create the bare clone
-                of the <filename>linux-yocto-3.2</filename> kernel and then create a copy of 
+                of the <filename>linux-yocto-3.4</filename> kernel and then create a copy of 
                 that clone.
                 <note>When you have a local Yocto Project kernel Git repository, you can 
                 reference that repository rather than the upstream Git repository as 
                 part of the <filename>clone</filename> command.
                 Doing so can speed up the process.</note></para>
                 <para>In the following example, the bare clone is named 
-                <filename>linux-yocto-3.2.git</filename>, while the 
-                copy is named <filename>my-linux-yocto-3.2-work</filename>: 
+                <filename>linux-yocto-3.4.git</filename>, while the 
+                copy is named <filename>my-linux-yocto-3.4-work</filename>: 
                 <literallayout class='monospaced'>
-     $ 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/
+     $ git clone --bare git://git.yoctoproject.org/linux-yocto-3.4 linux-yocto-3.4.git
+     Initialized empty Git repository in /home/scottrif/linux-yocto-3.4.git/
      remote: Counting objects: 2468027, done.
      remote: Compressing objects: 100% (392255/392255), done.
      remote: Total 2468027 (delta 2071693), reused 2448773 (delta 2052498)
@@ -147,9 +151,9 @@
                 </literallayout></para>
                 <para>Now create a clone of the bare clone just created:
                 <literallayout class='monospaced'>
-     $ 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.
+     $ git clone linux-yocto-3.4.git my-linux-yocto-3.4-work
+     Cloning into 'my-linux-yocto-3.4-work'...
+     done.
                 </literallayout></para></listitem>
             <listitem id='poky-extras-repo'><para><emphasis>
                 The <filename>poky-extras</filename> Git Repository</emphasis>:
@@ -169,6 +173,7 @@
                 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: 618, done.
@@ -193,7 +198,7 @@
                 <literallayout class='monospaced'> 
      meta-&lt;BSP_name&gt; 
                 </literallayout>
-                where &lt;BSP_name&gt; is the recognized BSP name.
+                where <filename>&lt;BSP_name&gt;</filename> is the recognized BSP name.
                 Here are some examples:
                 <literallayout class='monospaced'>
      meta-crownbay
@@ -224,6 +229,7 @@
                         <filename>meta-intel</filename>
                         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: 3380, done.
@@ -277,8 +283,9 @@
                 a centralized tarball download directory through the  
                 <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-DL_DIR'>DL_DIR</ulink></filename> variable.</para></listitem>
             <listitem><para>Build the image using the <filename>bitbake</filename> command.
-                If you want information on BitBake, see the user manual at
-                <ulink url='&OE_DOCS_URL;/bitbake/html'></ulink>.</para></listitem>
+                If you want information on BitBake, see the user manual inculded in the 
+                <filename>bitbake/doc/manual</filename> directory of the 
+                <link linkend='source-directory'>Source Directory</link>.</para></listitem>
             <listitem><para>Run the image either on the actual hardware or using the QEMU 
                 emulator.</para></listitem>
         </orderedlist>
@@ -312,9 +319,9 @@
         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
+        You can get architecture-specific binaries and filesystems from
         <ulink url='&YOCTO_MACHINES_DL_URL;'>machines</ulink>.
-        You can get stand-alone toolchains from
+        You can get installation scripts for 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. 

documentation/dev-manual/dev-manual.xml

@@ -76,13 +76,9 @@
 
     <xi:include href="dev-manual-newbie.xml"/>
 
-    <xi:include href="dev-manual-common-tasks.xml"/>
-
     <xi:include href="dev-manual-model.xml"/>
 
-    <xi:include href="dev-manual-bsp-appendix.xml"/>
-
-    <xi:include href="dev-manual-kernel-appendix.xml"/>
+    <xi:include href="dev-manual-common-tasks.xml"/>
 
 </book>
 <!-- 

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

@@ -55,7 +55,7 @@
                 "<ulink url='&YOCTO_DOCS_DEV_URL;#kernel-modification-workflow'>Kernel Modification Workflow</ulink>"
                 </para></listitem>
             <listitem><para> 
-                "<ulink url='&YOCTO_DOCS_DEV_URL;#dev-manual-kernel-appendix'>Kernel Modification Example</ulink>"</para></listitem>
+                "<ulink url='&YOCTO_DOCS_DEV_URL;#patching-the-kernel'>Patching the Kernel</ulink>"</para></listitem>
         </itemizedlist>
     </para>
 

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

@@ -784,9 +784,9 @@
                 This section overviews the process of creating a BSP based on an 
                 existing similar BSP.
                 The information is introductory in nature and does not provide step-by-step examples. 
-                For detailed information on how to create a BSP given an existing similar BSP, see
-                the "<ulink url='&YOCTO_DOCS_DEV_URL;#dev-manual-bsp-appendix'>BSP Development 
-                Example</ulink>" appendix in the Yocto Project Development Manual, or see the 
+                For detailed information on how to create a new BSP, see
+                the "<ulink url='&YOCTO_DOCS_BSP_URL;#creating-a-new-bsp-layer-using-the-yocto-bsp-script'>Creating a New BSP Layer Using the yocto-bsp Script</ulink>" section in the 
+                Yocto Project Board Support Package (BSP) Developer's Guide, or see the 
                 <ulink url='&YOCTO_WIKI_URL;/wiki/Transcript:_creating_one_generic_Atom_BSP_from_another'>Transcript:_creating_one_generic_Atom_BSP_from_another</ulink>
                 wiki page.
             </para>

documentation/poky-ref-manual/faq.xml

@@ -13,14 +13,16 @@
         </question>
         <answer>
             <para>
-                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.
+                The term "Poky" refers to the specific reference build system that
+                the Yocto Project provides.
+                Poky is based on <ulink url='&YOCTO_DOCS_DEV_URL;#oe-core'>OE-Core</ulink>
+                and BitBake.
+                Thus, the generic term used here for the build system is
+                the "OpenEmbedded build system."
+                Development in the Yocto Project using Poky is closely tied to OpenEmbedded, with 
+                changes always being merged to OE-Core or BitBake first before being pulled back
+                into Poky.
+                This practice benefits both projects immediately.
                 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.
@@ -63,7 +65,7 @@
     <qandaentry>
         <question>
             <para>
-                How can you claim Poky is stable?
+                How can you claim Poky / OpenEmbedded-Core is stable?
             </para>
         </question>
         <answer>
@@ -71,11 +73,13 @@
                 There are three areas that help with stability;
                 <itemizedlist>
                     <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 
-                        team has access to for testing.</para></listitem>
+                        <ulink url='&YOCTO_DOCS_DEV_URL;#oe-core'>OE-Core</ulink> small
+                        and focused, containing around 830 recipes as opposed to the thousands
+                        available in other OpenEmbedded community layers.
+                        Keeping it small makes it easy to test and maintain.</para></listitem>
+                    <listitem><para>The Yocto Project team runs manual and automated tests 
+                        using a small, fixed set of reference hardware as well as emulated
+                        targets.</para></listitem>
                     <listitem><para>The Yocto Project uses an an autobuilder,
                         which provides continuous build and integration tests.</para></listitem>
                 </itemizedlist>
@@ -91,13 +95,11 @@
         </question>
         <answer>
             <para>
-                There are two main ways to get a board supported in the Yocto Project;
-                <itemizedlist>
-                    <listitem><para>Send the Yocto Project team information on the board
-                        and if the team does not have it yet they will consider adding it.</para></listitem>
-                    <listitem><para>Send the Yocto Project team the BitBake recipes if you have them.
-                        </para></listitem>
-                </itemizedlist>
+                Support for an additional board is added by creating a BSP layer for it.
+                For more information on how to create a BSP layer, see the
+                <ulink url='&YOCTO_DOCS_BSP_URL;'>Yocto Project Board Support Package (BSP) Developer's Guide</ulink>.
+            </para>
+            <para>
                 Usually, if the board is not completely exotic, adding support in 
                 the Yocto Project is fairly straightforward.
             </para>
@@ -107,15 +109,15 @@
     <qandaentry>
         <question>
             <para>
-                Are there any products using the OpenEmbedded build system (poky)?
+                Are there any products built using the OpenEmbedded build system?
             </para>
         </question>
         <answer>
             <para>
-                The <ulink url='http://vernier.com/labquest/'>Vernier LabQuest</ulink> is using 
-                the OpenEmbedded build system.  
+                The software running on the <ulink url='http://vernier.com/labquest/'>Vernier LabQuest</ulink>
+                is built using the OpenEmbedded build system.  
                 See the <ulink url='http://www.vernier.com/products/interfaces/labq/'>Vernier LabQuest</ulink>
-                for more information.
+                website for more information.
                 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.
@@ -307,28 +309,6 @@
         </answer>
     </qandaentry>
 
-    <qandaentry>
-        <question>
-            <para>
-                I'm using Ubuntu Intrepid and am seeing build failures. What’s wrong?
-            </para>
-        </question>
-        <answer>
-            <para>
-	            In Intrepid, Ubuntu turns on by default the normally optional compile-time security features 
-		        and warnings. 
-                There are more details at 
-                <ulink url='https://wiki.ubuntu.com/CompilerFlags'>https://wiki.ubuntu.com/CompilerFlags</ulink>.
-		        You can work around this problem by disabling those options by adding 
-                the following to the <filename>BUILD_CPPFLAGS</filename> variable in the
-                <filename>conf/bitbake.conf</filename> file.
-                <literallayout class='monospaced'>
-     " -Wno-format-security -U_FORTIFY_SOURCE" 
-                </literallayout>
-            </para>
-        </answer>
-    </qandaentry>
-
     <qandaentry>
         <question>
             <para>
@@ -421,7 +401,7 @@
                 For example, add the following files to your layer:
                 <literallayout class='monospaced'>
      meta-MACHINE/recipes-bsp/netbase/netbase/MACHINE/interfaces
-     meta-MACHINE/recipes-bsp/netbase/netbase_4.44.bbappend
+     meta-MACHINE/recipes-bsp/netbase/netbase_5.0.bbappend
                 </literallayout>
             </para>
         </answer>

documentation/poky-ref-manual/introduction.xml

@@ -87,10 +87,178 @@
 <section id='intro-requirements'>
 <title>System Requirements</title>
     <para>
-        For Yocto Project system requirements, see the
+        For general Yocto Project system requirements, see the
         <ulink url='&YOCTO_DOCS_QS_URL;#yp-resources'>
         What You Need and How You Get It</ulink> section in the Yocto Project Quick Start.
+        The remainder of this section provides details on system requirements
+        not covered in the Yocto Project Quick Start.
     </para>
+
+    <section id='detailed-supported-distros'>
+    <title>Supported Linux Distributions</title>
+
+        <para>
+            TBD - a list of very specific distros and versions. 
+            The list will be kept up-to-date via a script provided that can 
+            be run prior to a release. 
+            The scripts output will yield the list and it can be copied 
+            into this section.
+        </para>
+    </section>
+
+    <section id='required-packages-for-the-host-development-system'>
+    <title>Required Packages for the Host Development System</title>
+
+        <para>
+            The list of packages you need on the host development system can 
+            be large when covering all build scenarios using the Yocto Project. 
+            This section provides required packages by Linux distribution and 
+            further categorized by function.
+        </para>
+
+        <section id='ubuntu-packages'>
+            <title>Ubuntu</title>
+
+            <para>
+                The following list shows the required packages by function
+                given a supported Ubuntu Linux distribution:
+                <itemizedlist>
+                    <listitem><para><emphasis>Essentials:</emphasis>
+                        Packages needed to build an image on a headless 
+                        system:
+                        <literallayout class='monospaced'>
+     $ sudo apt-get install &UBUNTU_HOST_PACKAGES_ESSENTIAL;
+                        </literallayout></para></listitem>
+                    <listitem><para><emphasis>Graphical Extras:</emphasis>
+                        Packages recommended if the host system has graphics support:
+                        <literallayout class='monospaced'>
+     $ sudo apt-get install libsdl1.2-dev xterm
+                        </literallayout></para></listitem>
+                    <listitem><para><emphasis>Documentation:</emphasis>
+                        Packages needed if you are going to build out the 
+                        Yocto Project documentation manuals:
+                        <literallayout class='monospaced'>
+     $ sudo apt-get install make xsltproc docbook-utils fop
+                        </literallayout></para></listitem>
+                    <listitem><para><emphasis>ADT Installer Extras:</emphasis>
+                        Packages needed if you are going to be using the 
+                        <ulink url='&YOCTO_DOCS_ADT_URL;#using-the-adt-installer'>Application Development Toolkit (ADT) Installer</ulink>:
+                        <literallayout class='monospaced'>
+     $ sudo apt-get install autoconf automake libtool libglib2.0-dev
+                        </literallayout></para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id='fedora-packages'>
+            <title>Fedora Packages</title>
+
+            <para>
+                The following list shows the required packages by function
+                given a supported Fedora Linux distribution:
+                <itemizedlist>
+                    <listitem><para><emphasis>Essentials:</emphasis>
+                        Packages needed to build an image for a headless 
+                        system:
+                        <literallayout class='monospaced'>
+     $ sudo yum install &FEDORA_HOST_PACKAGES_ESSENTIAL;
+                        </literallayout></para></listitem>
+                    <listitem><para><emphasis>Graphical Extras:</emphasis>
+                        Packages recommended if the host system has graphics support:
+                        <literallayout class='monospaced'>
+     $ sudo yum install SDL-devel xterm
+                        </literallayout></para></listitem>
+                    <listitem><para><emphasis>Documentation:</emphasis>
+                        Packages needed if you are going to build out the 
+                        Yocto Project documentation manuals:
+                        <literallayout class='monospaced'>
+     $ sudo yum install make docbook-style-dsssl docbook-style-xsl \
+     docbook-dtds docbook-utils fop libxslt
+                        </literallayout></para></listitem>
+                    <listitem><para><emphasis>ADT Installer Extras:</emphasis>
+                        Packages needed if you are going to be using the 
+                        <ulink url='&YOCTO_DOCS_ADT_URL;#using-the-adt-installer'>Application Development Toolkit (ADT) Installer</ulink>:
+                        <literallayout class='monospaced'>
+     $ sudo yum install autoconf automake libtool glib2-devel
+                        </literallayout></para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id='opensuse-packages'>
+            <title>OpenSUSE Packages</title>
+
+            <para>
+                The following list shows the required packages by function
+                given a supported OpenSUSE Linux distribution:
+                <itemizedlist>
+                    <listitem><para><emphasis>Essentials:</emphasis>
+                        Packages needed to build an image for a headless 
+                        system:
+                        <literallayout class='monospaced'>
+     $ sudo zypper install &OPENSUSE_HOST_PACKAGES_ESSENTIAL;
+                        </literallayout></para></listitem>
+                    <listitem><para><emphasis>Graphical Extras:</emphasis>
+                        Packages recommended if the host system has graphics support:
+                        <literallayout class='monospaced'>
+     $ sudo zypper install libSDL-devel xterm
+                        </literallayout></para></listitem>
+                    <listitem><para><emphasis>Documentation:</emphasis>
+                        Packages needed if you are going to build out the 
+                        Yocto Project documentation manuals:
+                        <literallayout class='monospaced'>
+     $ sudo zypper install make fop xsltproc
+                        </literallayout></para></listitem>
+                    <listitem><para><emphasis>ADT Installer Extras:</emphasis>
+                        Packages needed if you are going to be using the 
+                        <ulink url='&YOCTO_DOCS_ADT_URL;#using-the-adt-installer'>Application Development Toolkit (ADT) Installer</ulink>:
+                        <literallayout class='monospaced'>
+     $ sudo zypper install autoconf automake libtool glib2-devel
+                        </literallayout></para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id='centos-packages'>
+            <title>CentOS Packages</title>
+
+            <para>
+                The following list shows the required packages by function
+                given a supported CentOS Linux distribution:
+                <itemizedlist>
+                    <listitem><para><emphasis>Essentials:</emphasis>
+                        Packages needed to build an image for a headless 
+                        system:
+                        <literallayout class='monospaced'>
+     $ sudo yum -y install &CENTOS_HOST_PACKAGES_ESSENTIAL;
+                        </literallayout></para></listitem>
+                    <listitem><para><emphasis>Graphical Extras:</emphasis>
+                        Packages recommended if the host system has graphics support:
+                        <literallayout class='monospaced'>
+     $ sudo yum -y install SDL-devel xterm
+                        </literallayout></para></listitem>
+                    <listitem><para><emphasis>Documentation:</emphasis>
+                        Packages needed if you are going to build out the 
+                        Yocto Project documentation manuals:
+                        <literallayout class='monospaced'>
+     $ sudo yum -y install make docbook-style-dsssl docbook-style-xsl \
+     docbook-dtds docbook-utils fop libxslt
+                        </literallayout></para></listitem>
+                    <listitem><para><emphasis>ADT Installer Extras:</emphasis>
+                        Packages needed if you are going to be using the 
+                        <ulink url='&YOCTO_DOCS_ADT_URL;#using-the-adt-installer'>Application Development Toolkit (ADT) Installer</ulink>:
+                        <literallayout class='monospaced'>
+     $ sudo yum -y install autoconf automake libtool glib2-devel
+                        </literallayout></para></listitem>
+                </itemizedlist>
+                <note>Depending on the CentOS version you are using, other requirements 
+                    and dependencies might exist. 
+                    For details, you should look at the CentOS sections on the 
+                    <ulink url='https://wiki.yoctoproject.org/wiki/Poky/GettingStarted/Dependencies'>Poky/GettingStarted/Dependencies</ulink>
+                    wiki page.</note>
+            </para>
+        </section>
+    </section>
 </section>
 
 <section id='intro-getit'>
@@ -103,7 +271,7 @@
                 <ulink url='&YOCTO_DL_URL;/releases/yocto/'/>.</para></listitem>
             <listitem><para><emphasis>Nightly Builds:</emphasis> These releases are available at
                 <ulink url='http://autobuilder.yoctoproject.org/nightly'/>.  
-                These builds include Yocto Project releases, meta-toolchain tarballs, and 
+                These builds include Yocto Project releases, meta-toolchain tarball installation scripts, and 
                 experimental builds.</para></listitem>
             <listitem><para><emphasis>Yocto Project Website:</emphasis> You can find releases
                 of the Yocto Project and supported BSPs at the

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

@@ -124,10 +124,10 @@
             Once a provider is selected, BitBake resolves all the dependencies for  
             the target. 
             In the case of <filename>core-image-sato</filename>, it would lead to 
-            <filename>task-base.bb</filename>,  
-            which in turn leads to packages like <filename>Contacts</filename>, 
-            <filename>Dates</filename> and <filename>BusyBox</filename>.
-            These packages in turn depend on <filename>eglibc</filename> and the toolchain.
+            <filename>packagegroup-core-x11-sato</filename>, 
+            which in turn leads to recipes like <filename>matchbox-terminal</filename>, 
+            <filename>pcmanfm</filename> and <filename>gthumb</filename>.
+            These recipes in turn depend on <filename>eglibc</filename> and the toolchain.
         </para>
 
         <para>
@@ -185,8 +185,9 @@
   
         <para>
             Dependencies are defined through several variables.
-            You can find information about variables BitBake uses in the 
-            <ulink url='&BITBAKE_DOCS_URL;'>BitBake manual</ulink>. 
+            You can find information about variables BitBake uses in the BitBake documentation,
+            which is found in the <filename>bitbake/doc/manual</filename> directory within the
+            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>. 
             At a basic level, it is sufficient to know that BitBake uses the 
             <filename><link linkend='var-DEPENDS'>DEPENDS</link></filename> and 
             <filename><link linkend='var-RDEPENDS'>RDEPENDS</link></filename> variables when 
@@ -274,7 +275,7 @@
             <orderedlist>
                 <listitem><para>Tell BitBake to load what you want from the environment
                     into the data store. 
-                    You can do so through the <filename>BB_ENV_WHITELIST</filename>
+                    You can do so through the <filename>BB_ENV_EXTRAWHITE</filename>
                     variable.
                     For example, assume you want to prevent the build system from 
                     accessing your <filename>$HOME/.ccache</filename> directory.
@@ -393,7 +394,9 @@ Options:
             Fetchers are usually triggered by entries in 
             <filename><link linkend='var-SRC_URI'>SRC_URI</link></filename>. 
             You can find information about the options and formats of entries for specific 
-            fetchers in the <ulink url='&BITBAKE_DOCS_URL;'>BitBake manual</ulink>.
+            fetchers in the BitBake manual located in the 
+            <filename>bitbake/doc/manual</filename> directory of the 
+            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
         </para>
 
         <para>

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

@@ -262,6 +262,28 @@
     </para>
 </section>
 
+<section id='ref-classes-packagegroup'>
+    <title>Package Groups - <filename>packagegroup.bbclass</filename></title>
+
+    <para>
+        This class sets default values appropriate for package group recipes (such as 
+        <filename><link linkend='var-PACKAGES'>PACKAGES</link></filename>, 
+        <filename><link linkend='var-PACKAGE_ARCH'>PACKAGE_ARCH</link></filename>, 
+        <filename><link linkend='var-ALLOW_EMPTY'>ALLOW_EMPTY</link></filename>, 
+        and so forth. 
+        It is highly recommended that all package group recipes inherit this class.
+    </para>
+    <para>
+        For information on how to use this class, see the 
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#usingpoky-extend-customimage-customtasks'>Customizing Images Using Custom Package Tasks</ulink>" 
+        section in the Yocto Project Development Manual.
+    </para>
+    <para>
+        Previously, this class was named <filename>task.bbclass</filename>.
+    </para>
+</section>
+
+
 <section id='ref-classes-package'>
     <title>Packaging - <filename>package*.bbclass</filename></title>
 
@@ -602,33 +624,54 @@
 
 <!-- Undocumented classes are:
         allarch.bbclass
+        archive*.bbclass
         binconfig.bbclass
+        blacklist.bbclass
         bootimg.bbclass
+        boot-directdisk.bbclass
+        bugzilla.bbclass
+        buildhistory.bbclass
         buildstats.bbclass
-        ccache.inc
+        ccache.bbclass
+        chrpath.bbclass
         cmake.bbclass
         cml1.bbclass
+        copyleft_compliance.bbclass
+        core-image.bbclass
         cross.bbclass
         cross-canadian.bbclass
+        crosssdk.bbclass
         deploy.bbclass
         distrodata.bbclass
+        dummy.bbclass
         gconf.bbclass
         gettext.bbclass
+        gnomebase.bbclass
         gnome.bbclass
         gtk-doc.bbclass
         gtk-icon-cache.bbclass
+        gzipnative.bbclass
         icecc.bbclass
+        image-empty.bbclass
+        image-live.bbclass
+        image-vmdk.bbclass
         image-mklibs.bbclass
         image-prelink.bbclass
         image-swab.bbclass
         imagetest-dummy.bbclass
         imagetest-qemu.bbclass
+        image_types.bbclass
+        image_types_uboot.bbclass
         insserv.bbclass
+        kernel-arch.bbclass
+        kernel-yocto.bbclass
         lib_package.bbclass
+        linux-kernel-base.bbclass
         license.bbclass
         logging.bbclass
         meta.bbclass
         metadata_scm.bbclass
+        mime.bbclass
         mirrors.bbclass
         multilib*.bbclass
         native.bbclass
@@ -636,14 +679,17 @@
         oelint.bbclass
         own-mirrors.bbclass
         packagedata.bbclass
-        packagehistory.bbclass
+        packageinfo.bbclass
         patch.bbclass
         perlnative.bbclass
         pkg_distribute.bbclass
         pkg_metainfo.bbclass
         populate_sdk*.bbclass
+        prexport.bbclass
+        primport.bbclass
         prserv.bbclass
         python-dir.bbclass
+        pythonnative.bbclass
         qemu.bbclass
         qmake*.bbclass
         qt4*.bbclass
@@ -659,7 +705,6 @@
         sstate.bbclass
         staging.bbclass
         syslinux.bbclass
-        task.bbclass
         terminal.bbclass
         tinderclient.bbclass
         toolchain-scripts.bbclass

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

@@ -112,7 +112,7 @@
     </section>
 
     <section id='ref-features-image'>
-        <title>Reference: Images</title>
+        <title>Images</title>
 
         <para>
             The contents of images generated by the OpenEmbedded build system can be controlled by the 
@@ -128,30 +128,46 @@
             Current list of 
             <filename>IMAGE_FEATURES</filename> contains the following:
             <itemizedlist>
-                <listitem><para><emphasis>apps-console-core:</emphasis> Core console applications such as 
-                    <filename>ssh</filename>, <filename>daemon</filename>, <filename>avahi daemon</filename>,
-                    <filename>portmap</filename> (for mounting NFS shares)</para></listitem>
-                <listitem><para><emphasis>x11-base:</emphasis> X11 server + minimal desktop</para></listitem>
-                <listitem><para><emphasis>x11-sato:</emphasis> OpenedHand Sato environment</para></listitem>
-                <listitem><para><emphasis>apps-x11-core:</emphasis> Core X11 applications such as an 
-                    X Terminal, file manager, and file editor</para></listitem>
-                <listitem><para><emphasis>apps-x11-games:</emphasis> A set of X11 games</para></listitem>
-                <listitem><para><emphasis>tools-sdk:</emphasis> A full SDK that runs on the device
+                <listitem><para><emphasis>splash:</emphasis> Enables showing a splash screen during boot. 
+                    By default, this screen is provided by <filename>psplash</filename>, which does 
+                    allow customization. 
+                    If you prefer to use an alternative splash screen package, you can do so by 
+                    setting the <filename>SPLASH</filename> variable
+                    to a different package name (or names) within the image recipe or at the distro
+                    configuration level.</para></listitem>
+                <listitem><para><emphasis>ssh-server-dropbear:</emphasis> Installs the Dropbear minimal 
+                    SSH server.
                     </para></listitem>
-                <listitem><para><emphasis>tools-debug:</emphasis> Debugging tools such as 
-                    <filename>strace</filename> and <filename>gdb</filename>
+                <listitem><para><emphasis>ssh-server-openssh:</emphasis> Installs the OpenSSH SSH server,
+                    which is more full-featured than Dropbear. 
+                    Note that if both the OpenSSH SSH server and the Dropbear minimal SSH server
+                    are present in <filename>IMAGE_FEATURES</filename>, then OpenSSH will take
+                    precedence and Dropbear will not be installed.</para></listitem>
+                <listitem><para><emphasis>x11:</emphasis> Installs the X server</para></listitem>
+                <listitem><para><emphasis>x11-base:</emphasis> Installs the X server with a 
+                    minimal environment.</para></listitem>
+                <listitem><para><emphasis>x11-sato:</emphasis> Installs the OpenedHand Sato environment.
                     </para></listitem>
-                <listitem><para><emphasis>tools-profile:</emphasis> Profiling tools such as 
+                <listitem><para><emphasis>tools-sdk:</emphasis> Installs a full SDK that runs on the device.
+                    </para></listitem>
+                <listitem><para><emphasis>tools-debug:</emphasis> Installs debugging tools such as 
+                    <filename>strace</filename> and <filename>gdb</filename>.
+                    </para></listitem>
+                <listitem><para><emphasis>tools-profile:</emphasis> Installs profiling tools such as 
                     <filename>oprofile</filename>, <filename>exmap</filename>, and 
-                    <filename>LTTng</filename></para></listitem>
-                <listitem><para><emphasis>tools-testapps:</emphasis> Device testing tools (e.g.
-                    touchscreen debugging)</para></listitem>
-                <listitem><para><emphasis>nfs-server:</emphasis> NFS server (exports / over NFS 
-                    to everybody)</para></listitem>
-                <listitem><para><emphasis>dev-pkgs:</emphasis> Development packages (headers and 
-                    extra library links) for all packages installed in a given image</para></listitem>
-                <listitem><para><emphasis>dbg-pkgs:</emphasis> Debug packages for all packages 
-                    installed in a given image</para></listitem>
+                    <filename>LTTng</filename>.</para></listitem>
+                <listitem><para><emphasis>tools-testapps:</emphasis> Installs device testing tools (e.g.
+                    touchscreen debugging).</para></listitem>
+                <listitem><para><emphasis>nfs-server:</emphasis> Installs an NFS server.</para></listitem>
+                <listitem><para><emphasis>dev-pkgs:</emphasis> Installs development packages (headers and 
+                    extra library links) for all packages installed in a given image.</para></listitem>
+                <listitem><para><emphasis>staticdev-pkgs:</emphasis> Installs static development 
+                    packages (i.e. static libraries containing <filename>*.a</filename> files) for all 
+                    packages installed in a given image.</para></listitem>
+                <listitem><para><emphasis>dbg-pkgs:</emphasis> Installs debug symbol packages for all packages 
+                    installed in a given image.</para></listitem>
+                <listitem><para><emphasis>doc-pkgs:</emphasis> Installs documentation packages for all packages 
+                    installed in a given image.</para></listitem>
             </itemizedlist>
         </para>
     </section>

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

@@ -12,8 +12,8 @@
     </para>
 
     <note>
-        Building an image without GNU Public License Version 3 (GPLv3) components is 
-        only supported for minimal and base images.
+        Building an image without GNU General Public License Version 3 (GPLv3) components
+        is only supported for minimal and base images.
         Furthermore, if you are going to build an image using non-GPLv3 components,
         you must make the following changes in the <filename>local.conf</filename> file
         before using the BitBake command to build the minimal or base image:
@@ -40,9 +40,6 @@
     <itemizedlist>
         <listitem><para><emphasis><filename>core-image-base</filename>:</emphasis>
             A console-only image that fully supports the target device hardware.</para></listitem>
-        <listitem><para><emphasis><filename>core-image-core</filename>:</emphasis>
-            An X11 image with simple applications such as terminal, editor, and file manager.
-            </para></listitem>
         <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>
@@ -61,12 +58,14 @@
             for the Minimal MTD Utilities, which let the user interact with the 
             MTD subsystem in the kernel to perform operations on flash devices.
             </para></listitem>
+        <listitem><para><emphasis><filename>core-image-x11</filename>:</emphasis>
+            A very basic X11 image with a terminal.
+            </para></listitem>
         <listitem><para><emphasis><filename>core-image-basic</filename>:</emphasis>
-            A foundational basic image without support for X that can be reasonably used for 
-            customization.</para></listitem>
+            A console-only image with more full-featured Linux system
+            functionality installed.</para></listitem>
         <listitem><para><emphasis><filename>core-image-lsb</filename>:</emphasis>
-            A <filename>core-image-basic</filename> image suitable for implementations 
-            that conform to Linux Standard Base (LSB).</para></listitem>
+            An image that conforms to the Linux Standard Base (LSB) specification.</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
             using the host.
@@ -83,8 +82,8 @@
         <listitem><para><emphasis><filename>core-image-sato</filename>:</emphasis>
             An image with Sato support, a mobile environment and visual style that works well 
             with mobile devices.
-            The image supports X11 with a Sato theme and Pimlico applications and also  
-            contains terminal, editor, and file manager.</para></listitem>
+            The image supports X11 with a Sato theme and applications such as
+            a terminal, editor, file manager, media player, and so forth.</para></listitem>
         <listitem><para><emphasis><filename>core-image-sato-dev</filename>:</emphasis>
             A <filename>core-image-sato</filename> image suitable for development 
             using the host.

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

@@ -46,8 +46,9 @@
         </para>
 
         <para>
-            For more information on BitBake, see the BitBake on-line manual at 
-            <ulink url="http://docs.openembedded.org/bitbake/html/"/>.
+            For more information on BitBake, see the BitBake documentation 
+            inculded in the <filename>bitbake/doc/manual</filename> directory of the 
+            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
         </para>
     </section>
 

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

@@ -31,11 +31,11 @@
        <link linkend='var-MACHINE'>M</link> 
 <!--               <link linkend='var-glossary-n'>N</link> -->
 <!--               <link linkend='var-glossary-o'>O</link> -->
-       <link linkend='var-PACKAGE_ARCH'>P</link> 
+       <link linkend='var-P'>P</link> 
 <!--               <link linkend='var-glossary-q'>Q</link> -->
        <link linkend='var-RCONFLICTS'>R</link> 
        <link linkend='var-S'>S</link> 
-       <link linkend='var-TARGET_ARCH'>T</link> 
+       <link linkend='var-T'>T</link> 
 <!--               <link linkend='var-glossary-u'>U</link> -->
 <!--               <link linkend='var-glossary-v'>V</link> -->
        <link linkend='var-WORKDIR'>W</link> 
@@ -61,7 +61,7 @@
                    conjunction with a package name override.
                    Here is an example:
                    <literallayout class='monospaced'>
-     ALLOW_EMPTY_${PN}
+     ALLOW_EMPTY_${PN} = "1"
                    </literallayout>
                 </para>
             </glossdef>
@@ -76,9 +76,13 @@
 
         <glossentry id='var-AUTOREV'><glossterm>AUTOREV</glossterm>
             <glossdef>
-                <para>Specifies to use the current (newest) source revision.
-                    This variable is with the <filename><link linkend='var-SRCREV'>SRCREV</link></filename>
-                    variable.</para>
+                <para>When <filename><link linkend='var-SRCREV'>SRCREV</link></filename>
+                    is set to the value of this variable, it specifies that the latest
+                    source revision in the repository should be used. Here is an example:
+                    <literallayout class='monospaced'>
+     SRCREV = "${AUTOREV}"
+                    </literallayout>
+                </para>
             </glossdef>
         </glossentry>
 
@@ -89,14 +93,15 @@
         <glossentry id='var-B'><glossterm>B</glossterm>
             <glossdef>
                 <para>
-                    The directory in which the OpenEmbedded build system places
-                    generated objects during a recipe's build process.
+                    The <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>.
+                    The OpenEmbedded build system places generated objects into the build directory
+                    during a recipe's build process.
                     By default, this directory is the same as the <link linkend='var-S'><filename>S</filename></link>
                     directory:
                     <literallayout class='monospaced'>
      B = ${WORKDIR}/${BPN}-{PV}/
                     </literallayout>
-                    You can separate the source directory (<filename>S</filename>) and the directory pointed to 
+                    You can separate the (<filename>S</filename>) directory and the directory pointed to 
                     by the <filename>B</filename> variable.
                     Most autotools-based recipes support separating these directories.
                     The build system defaults to using separate directories for <filename>gcc</filename>
@@ -251,18 +256,39 @@
      BBLAYERS = " \
        /home/scottrif/poky/meta \
        /home/scottrif/poky/meta-yocto \
+       /home/scottrif/poky/meta-yocto-bsp \
        /home/scottrif/poky/meta-mykernel \
        "
                     </literallayout>
-                    This example enables three layers, one of which is a custom, user-defined layer 
+                    This example enables four layers, one of which is a custom, user-defined layer 
                     named <filename>meta-mykernel</filename>.
                 </para>
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-BP'><glossterm>BP</glossterm>
+            <glossdef>
+                <para>The base recipe name and version but without any special 
+                    package name suffix (i.e. <filename>-native</filename>, <filename>lib64-</filename>,
+                    and so forth).
+                    <filename>BP</filename> is comprised of the following:
+                    <literallayout class="monospaced">
+     ${BPN}-${PV}
+                    </literallayout></para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-BPN'><glossterm>BPN</glossterm>
             <glossdef>
-                <para>Bare name of package with any suffixes like -cross -native removed.</para>
+                <para>The bare name of the recipe or package.
+                    This variable is a version of the <link linkend='var-PN'><filename>PN</filename></link> variable 
+                    but has common suffixes and prefixes such as "-native", "-cross" and "multilib" 
+                    removed.
+                    The exact list of suffixes removed is specified by the 
+                    <link linkend='var-SPECIAL_PKGSUFFIX'><filename>SPECIAL_PKGSUFFIX</filename></link> variable.
+                    The exact list of prefixes removed is specified by the 
+                    <link linkend='var-MLPREFIX'><filename>MLPREFIX</filename></link> variable.
+                    Prefixes are removed for multilib and nativesdk cases.</para>
             </glossdef>
         </glossentry>
 
@@ -307,7 +333,7 @@
 
                 <para>  
                     To use the <filename>CONFFILES</filename> variable, provide a package name
-                    override that identifies the package.
+                    override that identifies the resulting package.
                     Then, provide a space-separated list of files.
                     Here is an example:
                     <literallayout class='monospaced'>                       
@@ -561,12 +587,11 @@
                  For example, ssh root access has a blank 
                  password.  You should remove this feature 
                  before you produce a production image.  
-                       
-                 There are other application targets too, see
-                 <filename>meta/classes/poky-image.bbclass</filename>
-                 and <filename>meta/packages/tasks/task-poky.bb</filename>
-                 for more details.
                     </literallayout> 
+
+                 <para>There are other valid features too, see the
+                 <link linkend='ref-features-image'>Images</link>
+                 section for more details.</para>
             </glossdef>
         </glossentry>
 
@@ -619,9 +644,9 @@
 
                 <para>
                     To use the <filename>FILES</filename> variable, provide a package name
-                    override that identifies the package.
+                    override that identifies the resulting package.
                     Then, provide a space-separated list of files or paths that identifies the 
-                    files you want included as part of the package.
+                    files you want included as part of the resulting package.
                     Here is an example:
                     <literallayout class='monospaced'>                       
   FILES_${PN} += "${bindir}/mydir1/ ${bindir}/mydir2/myfile"
@@ -781,12 +806,13 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \
 
         <glossentry id='var-IMAGE_FEATURES'><glossterm>IMAGE_FEATURES</glossterm>
             <glossdef>
-                <para>The list of features present in images.
-                Typically, you configure this variable in image recipes.
-                Note that you can add extra features to the image by using the
+                <para>The list of features to include in an image.
+                Typically, you configure this variable in an image recipe.
+                Note that you can also 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">Images</link>" chapter for the 
-                list of features present in images built by the OpenEmbedded build system.</para>
+                See the "<link linkend="ref-features-image">Images</link>" section for the 
+                full list of features that can be included in images built by the
+                OpenEmbedded build system.</para>
             </glossdef>
         </glossentry>
 
@@ -947,23 +973,53 @@ FILESPATH = "${@base_set_filespath([ "${FILE_DIRNAME}/${PF}", \
 
         <glossentry id='var-INC_PR'><glossterm>INC_PR</glossterm>
             <glossdef>
-                <para>Defines the Package revision.  
-                    You manually combine values for <filename>INC_PR</filename> into the 
-                    <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>Helps define the recipe revision for recipes that share
+                    a common <filename>include</filename> file.
+                    You can think of this variable as part of the recipe revision 
+                    as set from within an include file.</para>
+                <para>Suppose, for example, you have a set of recipes that 
+                    are used across several projects.
+                    And, within each of those recipes the revision
+                    (its <filename>PR</filename> value) is set accordingly.
+                    In this case, when the revision of those recipes changes
+                    the burden is on you to find all those recipes and 
+                    be sure that they get changed to reflect the updated 
+                    version of the recipe.
+                    In this scenario, it can get complicated when recipes
+                    used in many places and that provide common functionality 
+                    are upgraded to a new revision.</para>
+                <para>A more efficient way of dealing with this situation is
+                    to set the <filename>INC_PR</filename> variable inside
+                    the <filename>include</filename> files that the recipes
+                    share and then expand the <filename>INC_PR</filename>
+                    variable within the recipes to help 
+                    define the recipe revision.
+                    </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:
-                </para>
-                <literallayout class='monospaced'>
+                    The following provides an example that shows how to use 
+                    the <filename>INC_PR</filename> variable
+                    given a common <filename>include</filename> file that 
+                    defines the variable.
+                    Once the variable is defined in the 
+                    <filename>include</filename> file, you can use the 
+                    variable to set the <filename>PR</filename> values in
+                    each recipe. 
+                    You will notice that when you set a recipe's  
+                    <filename>PR</filename> you can provide more granular
+                    revisioning by appending values to the 
+                    <filename>INC_PR</filename> variable:
+                    <literallayout class='monospaced'>
+recipes-graphics/xorg-font/xorg-font-common.inc:INC_PR = "r2"
 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>
+                    </literallayout>
+                    The first line of the example establishes the baseline 
+                    revision to be used for all recipes that use the 
+                    <filename>include</filename> file.
+                    The remaining lines in the example are from individual
+                    recipes and show how the <filename>PR</filename> value
+                    is set.</para>
             </glossdef>
         </glossentry>
 
@@ -1113,7 +1169,7 @@ recipes-graphics/xorg-font/xorg-font-common.inc:INC_PR = "r2"
      KERNEL_FEATURES="features/netfilter"
 
      # Add sound support to the qemux86 machine
-     KERNEL_FEATURES_append_qemux86="cfg/sound"
+     KERNEL_FEATURES_append_qemux86=" cfg/sound"
                     </literallayout></para>
             </glossdef>
         </glossentry>
@@ -1311,7 +1367,7 @@ recipes-graphics/xorg-font/xorg-font-common.inc:INC_PR = "r2"
                     The build process depends on these packages being present.
                     Furthermore, because this is a "machine essential" variable, the list of 
                     packages are essential for the machine to boot.
-                    The impact of this variable affects images based on <filename>task-core-boot</filename>,
+                    The impact of this variable affects images based on <filename>packagegroup-core-boot</filename>,
                     including the <filename>core-image-minimal</filename> image.
                 </para>
                 <para>
@@ -1341,7 +1397,7 @@ recipes-graphics/xorg-font/xorg-font-common.inc:INC_PR = "r2"
                     The build process does not depend on these packages being present.
                     Furthermore, because this is a "machine essential" variable, the list of 
                     packages are essential for the machine to boot.
-                    The impact of this variable affects images based on <filename>task-core-boot</filename>,
+                    The impact of this variable affects images based on <filename>packagegroup-core-boot</filename>,
                     including the <filename>core-image-minimal</filename> image.
                 </para>
                 <para>
@@ -1388,7 +1444,7 @@ recipes-graphics/xorg-font/xorg-font-common.inc:INC_PR = "r2"
                     Even though these packages are not essential for the machine to boot,  
                     the build process depends on them being present.
                     The impact of this variable affects all images based on
-                    <filename>task-base</filename>, which does not include the 
+                    <filename>packagegroup-base</filename>, which does not include the 
                     <filename>core-image-minimal</filename> or <filename>core-image-basic</filename> 
                     images.
                 </para>
@@ -1425,7 +1481,7 @@ recipes-graphics/xorg-font/xorg-font-common.inc:INC_PR = "r2"
                     The package being built has no build dependency on the list of packages 
                     with this variable.  
                     The impact of this variable affects only images based on 
-                    <filename>task-base</filename>, which does not include the 
+                    <filename>packagegroup-base</filename>, which does not include the 
                     <filename>core-image-minimal</filename> or <filename>core-image-basic</filename> 
                     images.
                 </para>
@@ -1467,6 +1523,21 @@ recipes-graphics/xorg-font/xorg-font-common.inc:INC_PR = "r2"
                 <para>The email address of the distribution maintainer.</para>
             </glossdef>
         </glossentry>
+
+        <glossentry id='var-MLPREFIX'><glossterm>MLPREFIX</glossterm>
+            <glossdef>
+                <para>
+                    Specifies a prefix has been added to
+                    <link linkend='var-PN'><filename>PN</filename></link> to create a special version 
+                    of a recipe or package, such as a multilib version.
+                    The variable is used in places where the prefix needs to be 
+                    added to or removed from a the name (e.g. the
+                    <link linkend='var-BPN'><filename>BPN</filename></link> variable).
+                    <filename>MLPREFIX</filename> gets set when a prefix has been 
+                    added to <filename>PN</filename>. 
+                </para>
+            </glossdef>
+        </glossentry>
     </glossdiv>
 
 <!--            <glossdiv id='var-glossary-n'><title>N</title>-->
@@ -1477,9 +1548,28 @@ recipes-graphics/xorg-font/xorg-font-common.inc:INC_PR = "r2"
 
     <glossdiv id='var-glossary-p'><title>P</title>
 
+        <glossentry id='var-P'><glossterm>P</glossterm>
+            <glossdef>
+                <para>The recipe name and version.
+                    <filename>P</filename> is comprised of the following:
+                    <literallayout class='monospaced'>
+     ${PN}-${PV}
+                    </literallayout></para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-PACKAGE_ARCH'><glossterm>PACKAGE_ARCH</glossterm>
             <glossdef>
-                <para>The architecture of the resulting package.</para>
+                <para>The architecture of the resulting package or packages.</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-PACKAGE_BEFORE_PN'><glossterm>PACKAGE_BEFORE_PN</glossterm>
+            <glossdef>
+                <para>Enables easily adding packages to 
+                <filename><link linkend='var-PACKAGES'>PACKAGES</link></filename>
+                before <filename>${PN}</filename> so that the packages can pick 
+                up files that would normally be included in the default package.</para>
             </glossdef>
         </glossentry>
 
@@ -1513,7 +1603,10 @@ recipes-graphics/xorg-font/xorg-font-common.inc:INC_PR = "r2"
         <glossentry id='var-PACKAGES'><glossterm>PACKAGES</glossterm>
             <glossdef>
                 <para>The list of packages to be created from the recipe.
-                    The default value is "${PN}-dbg ${PN} ${PN}-doc ${PN}-dev".</para>
+                    The default value is the following:
+                    <literallayout class='monospaced'>
+     ${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale ${PACKAGE_BEFORE_PN} ${PN}
+                    </literallayout></para>
             </glossdef>
         </glossentry>
 
@@ -1528,30 +1621,78 @@ recipes-graphics/xorg-font/xorg-font-common.inc:INC_PR = "r2"
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-PF'><glossterm>PF</glossterm>
+            <glossdef>
+                <para>Specifies the recipe or package name and includes all version and revision
+                    numbers (i.e. <filename>eglibc-2.13-r20+svnr15508/</filename> and
+                    <filename>bash-4.2-r1/</filename>).
+                    This variable is comprised of the following:
+                    <literallayout class='monospaced'>
+     ${PN}-${EXTENDPE}${PV}-${PR}
+                    </literallayout></para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-PN'><glossterm>PN</glossterm>
             <glossdef>
-                <para>The name of the package.
-                    </para>
+                <para>This variable can have two separate functions depending on the context: a recipe
+                    name or a resulting package name.</para>
+                <para><filename>PN</filename> refers to a recipe name in the context of a file used 
+                    by the OpenEmbedded build system as input to create a package.
+                    The name is normally extracted from the recipe file name.
+                    For example, if the recipe is named 
+                    <filename>expat_2.0.1.bb</filename>, then the default value of <filename>PN</filename>
+                    will be "expat".</para>
+                <para> 
+                    The variable refers to a package name in the context of a file created or produced by the
+                    OpenEmbedded build system.</para>
+                <para>If applicable, the <filename>PN</filename> variable also contains any special 
+                    suffix or prefix.
+                    For example, using <filename>bash</filename> to build packages for the native
+                    machine, <filename>PN</filename> is <filename>bash-native</filename>.
+                    Using <filename>bash</filename> to build packages for the target and for Multilib,
+                    <filename>PN</filename> would be <filename>bash</filename> and  
+                    <filename>lib64-bash</filename>, respectively.
+                </para>
             </glossdef>
         </glossentry>
 
         <glossentry id='var-PR'><glossterm>PR</glossterm>
             <glossdef>
-                <para>The revision of the package. 
+                <para>The revision of the recipe. 
                     The default value for this variable is "r0".
                     </para>
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-PRINC'><glossterm>PRINC</glossterm>
+            <glossdef>
+                <para>Causes the <filename>PR</filename> variable of 
+                    <filename>.bbappend</filename> files to dynamically increment.
+                    This increment minimizes the impact of layer ordering.</para>
+                <para>In order to ensure multiple <filename>.bbappend</filename> files can co-exist, 
+                    <filename>PRINC</filename> should be self referencing.
+                    This variable defaults to 0.</para>
+                <para>Following is an example that increments <filename>PR</filename> by two:
+                    <literallayout class='monospaced'>
+     PRINC := "${@int(PRINC) + 2}"
+                    </literallayout>
+                    It is adviseable not to use strings such as ".= '.1'" with the variable because
+                    this usage is very sensitive to layer ordering. 
+                    Explicit assignments should be avoided as they cannot adequately represent multiple 
+                    <filename>.bbappend</filename> files.</para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-PV'><glossterm>PV</glossterm>
             <glossdef>
-                <para>The version of the package.
-                    The version is normally extracted from the recipe name.
+                <para>The version of the recipe.
+                    The version is normally extracted from the recipe filename.
                     For example, if the recipe is named 
-                    <filename>expat_2.0.1.bb</filename>, then <filename>PV</filename>
-                    will be <filename>2.0.1</filename>. 
+                    <filename>expat_2.0.1.bb</filename>, then the default value of <filename>PV</filename> 
+                    will be "2.0.1". 
                     <filename>PV</filename> is generally not overridden within 
-                    a recipe unless it is building an unstable version from a source code repository 
+                    a recipe unless it is building an unstable (i.e. development) version from a source code repository 
                     (e.g. Git or Subversion).
                  </para>
             </glossdef>
@@ -1560,7 +1701,7 @@ recipes-graphics/xorg-font/xorg-font-common.inc:INC_PR = "r2"
         <glossentry id='var-PE'><glossterm>PE</glossterm>
             <glossdef>
                 <para>
-                    the epoch of the package. 
+                    the epoch of the recipe. 
                     The default value is "0". 
                     The field is used to make upgrades possible when the versioning scheme changes in 
                     some backwards incompatible way.
@@ -1575,7 +1716,7 @@ recipes-graphics/xorg-font/xorg-font-common.inc:INC_PR = "r2"
                     determines which recipe should be given preference. 
                     The variable must always be suffixed with the name of the 
                     provided item, and should be set to the 
-                    <filename>$PN</filename> of the recipe 
+                    <filename>PN</filename> of the recipe 
                     to which you want to give precedence.
                     Here is an example:
                     <literallayout class='monospaced'>
@@ -1590,9 +1731,9 @@ recipes-graphics/xorg-font/xorg-font-common.inc:INC_PR = "r2"
                 <para>
                     If there are multiple versions of recipes available, this
                     variable determines which recipe should be given preference.
-                    The variable must always be suffixed with the <filename>$PN</filename> 
+                    The variable must always be suffixed with the <filename>PN</filename> 
                     for which to select, and should be set to the 
-                    <filename>$PV</filename> to which you want to give precedence.
+                    <filename>PV</filename> to which you want to give precedence.
                     You can use the "<filename>%</filename>" character as a wildcard
                     to match any number of characters, which can be useful when 
                     specifying versions that contain long revision number that could 
@@ -1615,9 +1756,17 @@ recipes-graphics/xorg-font/xorg-font-common.inc:INC_PR = "r2"
 
         <glossentry id='var-RCONFLICTS'><glossterm>RCONFLICTS</glossterm>
             <glossdef>
-                <para>The list of packages that conflict with this package.
+                <para>The list of packages that conflict with a package.
                     Note that the package will not be installed if the conflicting packages are not
                     first removed.</para>
+                <para>
+                   Like all package-controlling variables, you must always use them in 
+                   conjunction with a package name override.
+                   Here is an example:
+                   <literallayout class='monospaced'>
+     RCONFLICTS_${PN} = "another-conflicting-package-name"
+                   </literallayout>
+                </para>
             </glossdef>
         </glossentry>
 
@@ -1744,10 +1893,20 @@ recipes-graphics/xorg-font/xorg-font-common.inc:INC_PR = "r2"
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-SDKIMAGE_FEATURES'><glossterm>SDKIMAGE_FEATURES</glossterm>
+            <glossdef>
+                <para>Equivalent to 
+                <filename><link linkend='var-IMAGE_FEATURES'>IMAGE_FEATURES</link></filename>.
+                However, this variable applies to the SDK generated from an image using 
+                <filename>bitbake -c populate_sdk imagename</filename>).
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-SECTION'><glossterm>SECTION</glossterm>
             <glossdef>
-                <para>The section where package should be put.
-                    Package managers use this variable.</para>
+                <para>The section in which packages should be categorized.
+                    Package management utilities can make use of this variable.</para>
             </glossdef>
         </glossentry>
 
@@ -1784,7 +1943,7 @@ recipes-graphics/xorg-font/xorg-font-common.inc:INC_PR = "r2"
             <glossdef>
                 <para>
                     Specifies the endian byte order of the target system. 
-                    The variable is either "le" for little-endian or "be" for big-endian.
+                    The value should be either "le" for little-endian or "be" for big-endian.
                 </para>
             </glossdef>
         </glossentry>
@@ -1793,14 +1952,152 @@ recipes-graphics/xorg-font/xorg-font-common.inc:INC_PR = "r2"
             <glossdef>
                 <para>
                     Specifies the number of bits for the target system CPU.
-                    The variable is either "32" or "64".
+                    The value should be either "32" or "64".
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-SPECIAL_PKGSUFFIX'><glossterm>SPECIAL_PKGSUFFIX</glossterm>
+            <glossdef>
+                <para>
+                    A list of prefixes for <link linkend='var-PN'><filename>PN</filename></link> used by the 
+                    OpenEmbedded build system to create variants of recipes or packages.
+                    The list specifies the prefixes to strip off during certain circumstances
+                    such as the generation of the <link linkend='var-BPN'><filename>BPN</filename></link> variable.
                 </para>
             </glossdef>
         </glossentry>
 
         <glossentry id='var-SRC_URI'><glossterm>SRC_URI</glossterm>
             <glossdef>
-                <para>The list of source files - local or remote.</para>
+                <para>The list of source files - local or remote.
+                    This variable tells the OpenEmbedded build system which bits to pull
+                    in for the build and how to pull them in.
+                    For example, if the recipe only needs to fetch a tarball from the 
+                    internet, the recipe uses a single <filename>SRC_URI</filename> entry.
+                    On the other hand, if the recipe needs to fetch a tarball, apply
+                    two patches, and include a custom file, the recipe would include four
+                    instances of the variable.</para>
+                <para>The following list explains the available URI protocols:
+                    <itemizedlist>
+                        <listitem><para><emphasis><filename>file://</filename> -</emphasis> Fetches files, which is usually
+                            a file shipped with the metadata, from the local machine. 
+                            The path is relative to the 
+                            <link linkend='var-FILESPATH'><filename>FILESPATH</filename></link> 
+                            variable.
+                            Thus, the build system searches, in order, from the following directories,
+                            which are assumed to be a subdirectories of the directory in which the 
+                            recipe file resides:
+                            <itemizedlist>
+                                <listitem><para><emphasis><filename>${PN}</filename> -</emphasis> The recipe name 
+                                    with any special suffix or prefix, if applicable.
+                                    For example, using <filename>bash</filename> to build for the native
+                                    machine, <filename>PN</filename> is <filename>bash-native</filename>.
+                                    Using <filename>bash</filename> to build for the target and for Multilib,
+                                    <filename>PN</filename> would be <filename>bash</filename> and  
+                                    <filename>lib64-bash</filename>, respectively.
+                                    </para></listitem>
+                                <listitem><para><emphasis><filename>${PF}</filename> - </emphasis>
+                                    <filename>${PN}-${EXTENDPE}${PV}-${PR}</filename>.
+                                    The recipe name including all version and revision numbers 
+                                    (i.e. <filename>eglibc-2.13-r20+svnr15508/</filename> and
+                                    <filename>bash-4.2-r1/</filename>).</para></listitem>
+                                <listitem><para><emphasis><filename>${P}</filename> -</emphasis> 
+                                    <filename>${PN}-${PV}</filename>. 
+                                    The recipe name and version (i.e. <filename>bash-4.2</filename>).
+                                    </para></listitem>
+                                <listitem><para><emphasis><filename>${BPN}</filename> -</emphasis> The 
+                                    base recipe name without any special suffix or version numbers.
+                                    </para></listitem>
+                                <listitem><para><emphasis><filename>${BP}</filename> -</emphasis> 
+                                    <filename>${BPN}-${PV}</filename>.
+                                    The base recipe name and version but without any special 
+                                    package name suffix.</para></listitem>
+                                <listitem><para><emphasis>Files -</emphasis> Files beneath the directory in which the recipe
+                                    resides.</para></listitem>
+                                <listitem><para><emphasis>Directory -</emphasis> The directory itself in which the recipe
+                                    resides.</para></listitem>
+                            </itemizedlist></para></listitem>
+                        <listitem><para><emphasis><filename>bzr://</filename> -</emphasis> Fetches files from a 
+                            Bazaar revision control repository.</para></listitem>
+                        <listitem><para><emphasis><filename>git://</filename> -</emphasis> Fetches files from a 
+                            Git revision control repository.</para></listitem>
+                        <listitem><para><emphasis><filename>osc://</filename> -</emphasis> Fetches files from 
+                            an OSC (OpenSuse Build service) revision control repository.</para></listitem>
+                        <listitem><para><emphasis><filename>repo://</filename> -</emphasis> Fetches files from 
+                            a repo (Git) repository.</para></listitem>
+                        <listitem><para><emphasis><filename>svk://</filename> -</emphasis> Fetches files from 
+                            an SVK revision control repository.</para></listitem>
+                        <listitem><para><emphasis><filename>http://</filename> -</emphasis> Fetches files from 
+                            the Internet using <filename>http</filename>.</para></listitem>
+                        <listitem><para><emphasis><filename>https://</filename> -</emphasis> Fetches files 
+                            from the Internet using <filename>https</filename>.</para></listitem>
+                        <listitem><para><emphasis><filename>ftp://</filename> -</emphasis> Fetches files 
+                            from the Internet using <filename>ftp</filename>.</para></listitem>
+                        <listitem><para><emphasis><filename>cvs://</filename> -</emphasis> Fetches files from 
+                            a CVS revision control repository.</para></listitem>
+                        <listitem><para><emphasis><filename>hg://</filename> -</emphasis> Fetches files from 
+                            a Mercurial (<filename>hg</filename>) revision control repository.</para></listitem>
+                        <listitem><para><emphasis><filename>p4://</filename> -</emphasis> Fetches files from 
+                            a Perforce (<filename>p4</filename>) revision control repository.</para></listitem>
+                        <listitem><para><emphasis><filename>ssh://</filename> -</emphasis> Fetches files from 
+                            a secure shell.</para></listitem>
+                        <listitem><para><emphasis><filename>svn://</filename> -</emphasis> Fetches files from 
+                            a Subversion (<filename>svn</filename>) revision control repository.</para></listitem>
+                    </itemizedlist>
+                </para>
+                <para>Standard and recipe-specific options for <filename>SRC_URI</filename> exist.
+                    Here are standard options:
+                    <itemizedlist>
+                        <listitem><para><emphasis><filename>apply</filename> -</emphasis> Whether to apply 
+                            the patch or not. 
+                            The default action is to apply the patch.</para></listitem>
+                        <listitem><para><emphasis><filename>striplevel</filename> -</emphasis> Which 
+                            striplevel to use when applying the patch.
+                            The default level is 1.</para></listitem>
+                    </itemizedlist>
+                </para>
+                <para>Here are options specific to recipes building code from a revision control system:
+                    <itemizedlist>
+                        <listitem><para><emphasis><filename>mindate</filename> -</emphasis> Only applies 
+                            the patch if <link linkend='var-SRCDATE'><filename>SRCDATE</filename></link> 
+                            is equal to or greater than <filename>mindate</filename>.</para></listitem>
+                        <listitem><para><emphasis><filename>maxdate</filename> -</emphasis> Only applies 
+                            the patch if <link linkend='var-SRCDATE'><filename>SRCDATE</filename></link> 
+                            is not later than <filename>mindate</filename>.</para></listitem>
+                        <listitem><para><emphasis><filename>minrev</filename> -</emphasis> Only applies 
+                            the patch if <link linkend='var-SRCREV'><filename>SRCREV</filename></link> 
+                            is equal to or greater than <filename>minrev</filename>.</para></listitem>
+                        <listitem><para><emphasis><filename>maxrev</filename> -</emphasis> Only applies 
+                            the patch if <link linkend='var-SRCREV'><filename>SRCREV</filename></link> 
+                            is not later than <filename>maxrev</filename>.</para></listitem>
+                        <listitem><para><emphasis><filename>rev</filename> -</emphasis> Only applies the 
+                            patch if <link linkend='var-SRCREV'><filename>SRCREV</filename></link> 
+                            is equal to <filename>rev</filename>.</para></listitem>
+                        <listitem><para><emphasis><filename>notrev</filename> -</emphasis> Only applies 
+                            the patch if <link linkend='var-SRCREV'><filename>SRCREV</filename></link> 
+                            is not equal to <filename>rev</filename>.</para></listitem>
+                    </itemizedlist>
+                </para>
+                <para>Here are some additional options worth mentioning:
+                    <itemizedlist>
+                        <listitem><para><emphasis><filename>unpack</filename> -</emphasis> Controls 
+                            whether or not to unpack the file if it is an archive.
+                            The default action is to upack the file.</para></listitem>
+                        <listitem><para><emphasis><filename>subdir</filename> -</emphasis> Places the file 
+                            (or extracts its contents) into the specified 
+                            subdirectory of <link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>.
+                            This option is useful for unusual tarballs or other archives that 
+                            don't have their files already in a subdirectory within the archive.
+                            </para></listitem>
+                        <listitem><para><emphasis><filename>name</filename> -</emphasis> Specifies a 
+                            name to be used for association with <filename>SRC_URI</filename> checksums 
+                            when you have more than one file specified in <filename>SRC_URI</filename>.
+                            </para></listitem>
+                        <listitem><para><emphasis><filename>downloadfilename</filename> -</emphasis> Specifies  
+                            the filename used when storing the downloaded file.</para></listitem>
+                    </itemizedlist>
+                </para>
             </glossdef>
         </glossentry>
 
@@ -1872,6 +2169,25 @@ recipes-graphics/xorg-font/xorg-font-common.inc:INC_PR = "r2"
 
     <glossdiv id='var-glossary-t'><title>T</title>
 
+        <glossentry id='var-T'><glossterm>T</glossterm>
+            <glossdef>
+                <para>This variable points to a directory were Bitbake places temporary 
+                    files when building a particular package. 
+                    It is typically set as follows:
+                    <literallayout class='monospaced'>
+     T = ${WORKDIR}/temp
+                    </literallayout>
+                    The <link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>
+                    is the directory into which Bitbake unpacks and builds the package. 
+                    The default <filename>bitbake.conf</filename> file sets this variable.</para>
+                    <para>The <filename>T</filename> variable is not to be confused with 
+                    the <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link> variable,
+                    which points to the root of the directory tree where Bitbake 
+                    places the output of an entire build.
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-TARGET_ARCH'><glossterm>TARGET_ARCH</glossterm>
             <glossdef>
                 <para>The architecture of the device being built. 

documentation/poky-ref-manual/resources.xml

@@ -83,8 +83,11 @@
                 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 metadata.</para></listitem>
-            <listitem><para><emphasis><ulink url='&BITBAKE_DOCS_URL;'>
-                BitBake User Manual</ulink>:</emphasis> A comprehensive guide to the BitBake tool.
+            <listitem><para><emphasis>BitBake User Manual:</emphasis>
+                A comprehensive guide to the BitBake tool.
+                You can find the BitBake User Manual in the <filename>bitbake/doc/manual</filename> 
+                directory, which is found in the 
+                <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
                 </para></listitem>
             <listitem><para><emphasis><ulink url='http://wiki.qemu.org/Index.html'>QEMU</ulink>:
                 </emphasis> An open source machine emulator and virtualizer.</para></listitem>

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

@@ -650,6 +650,7 @@
      BBLAYERS ?= " \
         /home/nitin/prj/poky.git/meta \
         /home/nitin/prj/poky.git/meta-yocto \
+        /home/nitin/prj/poky.git/meta-yocto-bsp \
         /home/nitin/prj/meta-x32.git \
      "
                     </literallayout></para></listitem>
@@ -809,7 +810,7 @@
      LICENSE_FLAGS = "commercial"
             </literallayout>
             Here is a slightly more complicated example that contains both an
-            explicit package name and version (after variable expansion):
+            explicit recipe name and version (after variable expansion):
             <literallayout class='monospaced'>
      LICENSE_FLAGS = "license_${PN}_${PV}"
             </literallayout>
@@ -830,7 +831,7 @@
             <literallayout class='monospaced'>
      LICENSE_FLAGS_WHITELIST = "commercial_gst-plugins-ugly"
             </literallayout>
-	        Likewise, to additionally enable the package containing
+	        Likewise, to additionally enable the package built from the recipe containing
 	        <filename>LICENSE_FLAGS = "license_${PN}_${PV}"</filename>, and assuming
 	        that the actual recipe name was <filename>emgd_1.10.bb</filename>,
 	        the following string would enable that package as well as

documentation/poky-ref-manual/usingpoky.xml

@@ -66,8 +66,8 @@
         </para>
 
         <note>
-            Building an image without GNU Public License Version 3 (GPLv3) components is 
-            only supported for minimal and base images.
+            Building an image without GNU General Public License Version 3 (GPLv3) components
+            is only supported for minimal and base images.
             See the "<link linkend='ref-images'>Images</link>" chapter for more information.
         </note>
     </section>
@@ -78,7 +78,7 @@
         <para>
             When building an image using GPL components, you need to maintain your original 
             settings and not switch back and forth applying different versions of the GNU
-            Public License.  
+            General Public License.  
             If you rebuild using different versions of GPL, dependency errors might occur
             due to some components not being rebuilt.
         </para>

documentation/poky.ent

@@ -1,5 +1,5 @@
 <!ENTITY DISTRO "1.3">
-<!ENTITY DISTRO_NAME "1.2+snapshot">
+<!ENTITY DISTRO_NAME "danny">
 <!ENTITY YOCTO_DOC_VERSION "1.3">
 <!ENTITY POKYVERSION "8.0">
 <!ENTITY YOCTO_POKY "poky-&DISTRO_NAME;-&POKYVERSION;">
@@ -17,7 +17,6 @@
 <!ENTITY OE_DOCS_URL "http://docs.openembedded.org">
 <!ENTITY OH_HOME_URL "http://o-hand.com">
 <!ENTITY BITBAKE_HOME_URL "http://developer.berlios.de/projects/bitbake/">
-<!ENTITY BITBAKE_DOCS_URL "http://docs.openembedded.org/bitbake/html/">
 <!ENTITY ECLIPSE_MAIN_URL "http://www.eclipse.org/downloads">
 <!ENTITY ECLIPSE_DL_URL "http://download.eclipse.org">
 <!ENTITY ECLIPSE_DL_PLUGIN_URL "&YOCTO_DL_URL;/releases/eclipse-plugin/&DISTRO;">
@@ -48,3 +47,11 @@
 <!ENTITY YOCTO_ADTPATH_DIR "/opt/poky/&DISTRO;">
 <!ENTITY YOCTO_POKY_TARBALL "&YOCTO_POKY;.tar.bz2">
 <!ENTITY OE_INIT_PATH "&YOCTO_POKY;/oe-init-build-env">
+<!ENTITY OE_INIT_FILE "oe-init-build-env">
+<!ENTITY UBUNTU_HOST_PACKAGES_ESSENTIAL "awk wget git-core diffstat unzip texinfo build-essential chrpath">
+<!ENTITY FEDORA_HOST_PACKAGES_ESSENTIAL "awk make wget tar bzip2 gzip python unzip perl patch diffutils diffstat git
+cpp gcc gcc-c++ eglibc-devel texinfo chrpath ccache">
+<!ENTITY OPENSUSE_HOST_PACKAGES_ESSENTIAL "python gcc gcc-c++ git chrpath make wget diffstat texinfo python-curses">
+<!ENTITY CENTOS_HOST_PACKAGES_ESSENTIAL "gawk make wget tar bzip2 gzip python unzip perl patch diffutils diffstat git
+cpp gcc gcc-c++ glibc-devel texinfo chrpath">
+

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

@@ -104,11 +104,11 @@
             <para>Provides a recent Linux kernel along with a set of system commands and libraries suitable for the embedded environment.</para>
         </listitem>
         <listitem>
-            <para>Makes available system components such as X11, Matchbox, GTK+, Pimlico, Clutter,
-            GuPNP and Qt (among others) so you can create a richer user interface experience on 
-            devices that use displays or have a GUI.
-            For devices that don't have a GUI or display, you simply would not employ these 
-            components.</para>
+            <para>Makes available system components such as X11, GTK+, Qt, Clutter, and SDL
+            (among others) so you can create a rich user experience on devices
+            that have display hardware.
+            For devices that don't have a display or where you wish to use alternative UI
+            frameworks, these components need not be installed.</para>
         </listitem>
         <listitem>
             <para>Creates a focused and stable core compatible with the OpenEmbedded 
@@ -211,94 +211,85 @@
         <title>The Packages</title>
 
         <para>
-            Packages and package installation vary depending on your development system.  
-            In general, you need to have root access and then install the required packages.
-            The next few sections show you how to get set up with the right packages for
-            Ubuntu, Fedora, openSUSE, and CentOS.
+            Packages and package installation vary depending on your development system
+            and on your intent. 
+            For example, if you want to build an image that can run
+            on QEMU in graphical mode (a minimal, basic build
+            requirement), then the number of packages is different than if you want to
+            build an image on a headless system or build out the Yocto Project
+            documentation set. 
+            Collectively, the number of required packages is large
+            if you want to be able to cover all cases.
+            <note>In general, you need to have root access and then install the 
+                required packages.
+                Thus, the commands in the following section may or may not work 
+                depending on whether or not your Linux distribution has 
+                <filename>sudo</filename> installed.</note>
         </para>
-  
+
+        <para>
+            The next few sections list, by supported Linux Distributions, the required
+            packages needed to build an image that runs on QEMU in graphical mode
+            (e.g. essential plus graphics support).
+        </para>
+
+        <para> 
+            For lists of required packages for other scenarios, see the 
+            "<ulink url='&YOCTO_DOCS_REF_URL;#required-packages-for-the-host-development-system'>Required Packages for the Host Development System</ulink>" 
+            section in the Yocto Project Reference Manual.
+        </para>
+
         <section id='ubuntu'>
             <title>Ubuntu</title>
 
             <para>
-                The packages you need for a supported Ubuntu distribution are shown in the following command:
-            </para>
-
+                The essential packages you need for a supported Ubuntu distribution 
+                are shown in the following command:
                 <literallayout class='monospaced'>
-     $ sudo apt-get install sed wget subversion git-core coreutils \
-     unzip texi2html texinfo libsdl1.2-dev docbook-utils fop gawk \
-     python-pysqlite2 diffstat make gcc build-essential xsltproc \
-     g++ desktop-file-utils chrpath libgl1-mesa-dev libglu1-mesa-dev \
-     autoconf automake groff libtool xterm libxml-parser-perl dblatex
+     $ sudo apt-get install &UBUNTU_HOST_PACKAGES_ESSENTIAL; libsdl1.2-dev xterm
                 </literallayout>
+            </para>
         </section>
 
         <section id='fedora'>
             <title>Fedora</title>
 
             <para>
-                The packages you need for a supported Fedora distribution are shown in the following
-                commands:
-            </para>
-
+                The essential packages you need for a supported Fedora distribution 
+                are shown in the following command:
                 <literallayout class='monospaced'>
-     $ sudo yum groupinstall "development tools"
-     $ sudo yum install python m4 make wget curl ftp tar bzip2 gzip \
-     unzip perl texinfo texi2html diffstat openjade \
-     docbook-style-dsssl sed docbook-style-xsl docbook-dtds fop libxslt \
-     docbook-utils sed bc eglibc-devel ccache pcre pcre-devel quilt \
-     groff linuxdoc-tools patch cmake \
-     perl-ExtUtils-MakeMaker tcl-devel gettext chrpath ncurses apr \
-     SDL-devel mesa-libGL-devel mesa-libGLU-devel gnome-doc-utils \
-     autoconf automake libtool xterm dblatex
+     $ sudo yum install &FEDORA_HOST_PACKAGES_ESSENTIAL; SDL-devel xterm
                 </literallayout>
-
+            </para>
         </section>
 
         <section id='opensuse'>
             <title>openSUSE</title>
 
             <para>
-                The packages you need for a supported openSUSE distribution are shown in the following 
-                command:
-            </para>
-
+                The essential packages you need for a supported openSUSE 
+                distribution are shown in the following command:
                 <literallayout class='monospaced'>
-     $ sudo zypper install python gcc gcc-c++ libtool fop \
-     subversion git chrpath automake make wget xsltproc \
-     diffstat texinfo freeglut-devel libSDL-devel dblatex \
-     python-curses
+     $ sudo zypper install &OPENSUSE_HOST_PACKAGES_ESSENTIAL; libSDL-devel xterm
                 </literallayout>
+            </para>
         </section>
 
         <section id='centos'>
             <title>CentOS</title>
 
             <para>
-                The packages you need for a supported CentOS distribution are shown in the following 
-                commands:
-            </para>
-
+                The essential packages you need for a supported CentOS 
+                distribution are shown in the following command:
                 <literallayout class='monospaced'>
-     $ sudo yum -y groupinstall "development tools"
-     $ sudo yum -y install tetex gawk sqlite-devel vim-common redhat-lsb xz \
-       m4 make wget curl ftp tar bzip2 gzip python-devel \
-       unzip perl texinfo texi2html diffstat openjade zlib-devel \
-       docbook-style-dsssl sed docbook-style-xsl docbook-dtds \
-       docbook-utils bc glibc-devel pcre pcre-devel \
-       groff linuxdoc-tools patch cmake \
-       tcl-devel gettext ncurses apr \
-       SDL-devel mesa-libGL-devel mesa-libGLU-devel gnome-doc-utils \
-       autoconf automake libtool xterm dblatex
+     $ sudo yum -y install &CENTOS_HOST_PACKAGES_ESSENTIAL; SDL-devel xterm
                 </literallayout>
-            <note><para>
-                Depending on the CentOS version you are using, other requirements and dependencies
-                might exist. 
-                For details, you should look at the CentOS sections on the 
-                <ulink url='&YOCTO_WIKI_URL;/wiki/Poky/GettingStarted/Dependencies'>Poky/GettingStarted/Dependencies</ulink>
-                wiki page.
-            </para></note>
-
+                <note>Depending on the CentOS version you are using, other requirements 
+                    and dependencies might exist. 
+                    For details, you should look at the CentOS sections on the 
+                    <ulink url='https://wiki.yoctoproject.org/wiki/Poky/GettingStarted/Dependencies'>Poky/GettingStarted/Dependencies</ulink>
+                    wiki page.</note>
+            </para>
         </section>
     </section>
 
@@ -387,7 +378,8 @@
              <literallayout class='monospaced'>
      $ wget &YOCTO_POKY_DL_URL;
      $ tar xjf &YOCTO_POKY;.tar.bz2
-     $ source &OE_INIT_PATH; &YOCTO_POKY;-build
+     $ cd &YOCTO_POKY;
+     $ source &OE_INIT_FILE;
              </literallayout>
          </para>
 
@@ -412,12 +404,15 @@
              <listitem><para>The second command extracts the files from the tarball and places 
                  them into a directory named <filename>&YOCTO_POKY;</filename> in the current 
                  directory.</para></listitem>
-             <listitem><para>The third command runs the Yocto Project environment setup script.
-                 Running this script defines OpenEmbedded build environment settings needed to 
+             <listitem><para>The third and fourth commands change the working directory to the
+                 <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>
+                 and run the Yocto Project environment setup script.
+                 Running this script defines OpenEmbedded build environment settings needed to
                  complete the build.
                  The script also creates the 
                  <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>,
-                 which is <filename>&YOCTO_POKY;-build</filename> in this case.
+                 which is <filename>build</filename> in this case and is located in the 
+                 source directory.
                  After the script runs, your current working directory is set 
                  to the build directory.
                  Later, when the build completes, the build directory contains all the files 
@@ -426,7 +421,7 @@
          </itemizedlist>
          <para>
              Take some time to examine your <filename>local.conf</filename> file 
-             in your project's configuration directory.
+             in your project's configuration directory, which is found in the build directory.
              The defaults in that file should work fine.
              However, there are some variables of interest at which you might look.
          </para>
@@ -526,20 +521,20 @@
         <section id='installing-the-toolchain'>
             <title>Installing the Toolchain</title>
             <para>
-                You can download a tarball with the pre-built toolchain, which includes the 
+                You can download a tarball installer, which includes the pre-built toolchain, the 
                 <filename>runqemu</filename> 
-                script and support files, from the appropriate directory under
+                script, and support files from the appropriate directory under
                 <ulink url='&YOCTO_TOOLCHAIN_DL_URL;'></ulink>.  
                 Toolchains are available for 32-bit and 64-bit development systems from the 
                 <filename>i686</filename> and <filename>x86-64</filename> directories, respectively. 
                 Each type of development system supports five target architectures.
-                The names of the tarballs are such that a string representing the host system appears 
-                first in the filename and then is immediately followed by a string representing
-                the target architecture.
+                The names of the tarball installer scripts are such that a string representing the 
+                host system appears first in the filename and then is immediately followed by a 
+                string representing the target architecture.
             </para>
 
             <literallayout class='monospaced'>
-     poky-eglibc-&lt;<emphasis>host_system</emphasis>&gt;-&lt;<emphasis>arch</emphasis>&gt;-toolchain-gmae-&lt;<emphasis>release</emphasis>&gt;.tar.bz2
+     poky-eglibc-&lt;<emphasis>host_system</emphasis>&gt;-&lt;<emphasis>arch</emphasis>&gt;-toolchain-gmae-&lt;<emphasis>release</emphasis>&gt;.sh
 
      Where:
          &lt;<emphasis>host_system</emphasis>&gt; is a string representing your development system: 
@@ -552,26 +547,38 @@
             </literallayout>
 
             <para>       
-                For example, the following toolchain tarball is for a 64-bit development 
+                For example, the following toolchain installer is for a 64-bit development 
                 host system and a 32-bit target architecture:
             </para>
 
             <literallayout class='monospaced'>
-     poky-eglibc-x86_64-i586-toolchain-gmae-&DISTRO;.tar.bz2
+     poky-eglibc-x86_64-i586-toolchain-gmae-&DISTRO;.sh
             </literallayout>
 
             <para>
-                The toolchain tarballs are self-contained and must be installed into <filename>/opt/poky</filename>.
-                The following commands show how you install the toolchain tarball given a 64-bit development 
-                host system and a 32-bit target architecture.
-                The example assumes the toolchain tarball is located in <filename>~/toolchains/</filename>.
-                You must have your working directory set to root before unpacking the tarball:
+                Toolchains are self-contained and by default are installed into <filename>/opt/poky</filename>.
+                However, when you run the toolchain installer, you can choose an installation directory.
+            </para>
+
+            <para>
+                The following command shows how to run the installer given a toolchain tarball 
+                for a 64-bit development host system and a 32-bit target architecture.
+                You must change the permissions on the toolchain 
+                installer script so that it is executable.
+            </para>
+
+            <para>
+                The example assumes the toolchain installer is located in <filename>~/Downloads/</filename>.
+                <note>
+                    If you do not have write permissions for the directory into which you are installing 
+                    the toolchain, the toolchain installer notifies you and exits.  
+                    Be sure you have write permissions in the directory and run the installer again.
+                </note>
             </para>
 
             <para>
                 <literallayout class='monospaced'>
-     $ cd /
-     $ sudo tar -xvjf ~/toolchains/poky-eglibc-x86_64-i586-toolchain-gmae-&DISTRO;.tar.bz2
+     $ ~/Downloads/poky-eglibc-x86_64-i586-toolchain-gmae-&DISTRO;.sh
                 </literallayout>
             </para>
 
@@ -724,7 +731,7 @@
                 pages.
             </para>
         </footnote>
-        gives you a very fast description of how to use the Yocto Project to build images 
+        gives you a minimal description of how to use the Yocto Project to build images 
         for a BeagleBoard xM starting from scratch. 
         The steps were performed on a 64-bit Ubuntu 10.04 system.
     </para>
@@ -766,16 +773,18 @@
         <title>Initializing the Build Environment</title>
 
         <para>
-            From the parent directory of local source directory, initialize your environment 
-            and provide a meaningful 
+            From the parent directory your
+            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>, 
+            initialize your environment and provide a meaningful 
             <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>
             name:
             <literallayout class='monospaced'>
-     $ source poky/oe-init-build-env mybuilds
+     $ source poky/&OE_INIT_FILE; mybuilds
             </literallayout>
             At this point, the <filename>mybuilds</filename> directory has been created for you 
             and it is now your current working directory.
-            If you don't provide your own directory name it defaults to <filename>build</filename>.
+            If you don't provide your own directory name it defaults to <filename>build</filename>,
+            which is inside the source directory.
         </para>
     </section>
 
@@ -840,7 +849,7 @@
      $ bitbake -c fetchall core-image-minimal
                     </literallayout>
                     This variation guarantees that you have all the sources for that BitBake target 
-                    should you to disconnect from the net and want to do the build later offline.
+                    should you disconnect from the net and want to do the build later offline.
                     </para></listitem>
                 <listitem><para>Specify to continue the build even if BitBake encounters an error.
                     By default, BitBake aborts the build when it encounters an error.

meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb

@@ -13,7 +13,8 @@
 #
 #   You must also provide a Linux kernel configuration. The most direct
 #   method is to copy your .config to files/defconfig in your layer,
-#   in the same directory as the bbappend.
+#   in the same directory as the bbappend and add file://defconfig to
+#   your SRC_URI.
 #
 #   To use the yocto kernel tooling to generate a BSP configuration
 #   using modular configuration fragments, see the yocto-bsp and

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

@@ -29,7 +29,7 @@ EXTRA_IMAGECMD_jffs2 = "-lnp "
 SERIAL_CONSOLE = "115200 ttyO2"
 
 PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
-PREFERRED_VERSION_linux-yocto ?= "3.0%"
+PREFERRED_VERSION_linux-yocto ?= "3.4%"
 
 KERNEL_IMAGETYPE = "uImage"
 

meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf

@@ -3,7 +3,7 @@
 
 TARGET_FPU = ""
 
-require conf/machine/include/tune-ppc603e.inc
+require conf/machine/include/tune-ppce300c3.inc
 
 KERNEL_IMAGETYPE = "uImage"
 

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

@@ -19,6 +19,7 @@ XSERVER ?= "xserver-xorg \
             xf86-video-fbdev"
 
 SERIAL_CONSOLE = "115200 ttyS0"
+USE_VT ?= "0"
 
 MACHINE_EXTRA_RRECOMMENDS = " kernel-modules"
 

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

@@ -3,13 +3,12 @@ KBRANCH_routerstationpro = "standard/routerstationpro"
 KBRANCH_mpc8315e-rdb = "standard/fsl-mpc8315e-rdb"
 KBRANCH_beagleboard = "standard/beagleboard"
 
-SRCREV_machine_atom-pc ?= "0985844fa6235422c67ef269952fa4e765f252f9"
-SRCREV_machine_routerstationpro ?= "a2907c57acfb8fa71095a3ce5b20994ff859dbc5"
-SRCREV_machine_mpc8315e-rdb ?= "363a6f7e0c95aabec779a7ea3474662d191b935c"
-SRCREV_machine_beagleboard ?= "0985844fa6235422c67ef269952fa4e765f252f9"
-
+SRCREV_machine_atom-pc ?= "449f7f520350700858f21a5554b81cc8ad23267d"
+SRCREV_machine_routerstationpro ?= "27e8b8dabfed786aaaafd2f7104c141597830089"
+SRCREV_machine_mpc8315e-rdb ?= "524ce8107febcfd88717f54d50d36ca7c6e6e437"
+SRCREV_machine_beagleboard ?= "449f7f520350700858f21a5554b81cc8ad23267d"
 
 COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb"
 COMPATIBLE_MACHINE_routerstationpro = "routerstationpro"
-# COMPATIBLE_MACHINE_beagleboard = "beagleboard"
+COMPATIBLE_MACHINE_beagleboard = "beagleboard"
 COMPATIBLE_MACHINE_atom-pc = "atom-pc"

meta-yocto/classes/poky-sanity.bbclass

@@ -0,0 +1,16 @@
+python check_bblayers_conf_append() {
+    if current_lconf != lconf_version:
+        if current_lconf == 5:
+            index, meta_yocto_line = find_line('meta-yocto\s*\\\\\\n', lines)
+            if meta_yocto_line:
+                lines.insert(index + 1, meta_yocto_line.replace('meta-yocto',
+                                                                'meta-yocto-bsp'))
+            else:
+                sys.exit()
+
+            index, line = find_line('LCONF_VERSION', lines)
+            current_lconf += 1
+            lines[index] = 'LCONF_VERSION = "%d"\n' % current_lconf
+            with open(bblayers_fn, "w") as f:
+                f.write(''.join(lines))
+}

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

@@ -13,8 +13,11 @@ DISTRO_PN_ALIAS_pn-aaina = "Intel"
 DISTRO_PN_ALIAS_pn-abiword-embedded = "Fedora=abiword Ubuntu=abiword"
 DISTRO_PN_ALIAS_pn-adt-installer = "Intel"
 DISTRO_PN_ALIAS_pn-alsa-state = "OE-Core"
+DISTRO_PN_ALIAS_pn-anjuta-remote-run = "OpenedHand"
 DISTRO_PN_ALIAS_pn-augeas = "Ubuntu=libaugeas0 Debian=libaugeas0"
 DISTRO_PN_ALIAS_pn-avahi-ui = "Ubuntu=avahi-discover Debian=avahi-discover"
+DISTRO_PN_ALIAS_pn-babeltrace = "OSPDT"
+DISTRO_PN_ALIAS_pn-bdwgc = "OSPDT"
 DISTRO_PN_ALIAS_pn-bigreqsproto = "Meego=xorg-x11-proto-bigreqsproto"
 DISTRO_PN_ALIAS_pn-blktool = "Debian=blktool Mandriva=blktool"
 DISTRO_PN_ALIAS_pn-bluez4= "Fedora=bluez Ubuntu=bluez Debian=bluez-utils Opensuse=bluez"
@@ -22,6 +25,7 @@ DISTRO_PN_ALIAS_pn-bluez4="Meego=bluz Fedora=bluz Ubuntu=bluz OpenSuSE=bluz Mand
 DISTRO_PN_ALIAS_pn-bluez-dtl1-workaround = "OE-Core"
 DISTRO_PN_ALIAS_pn-btrfs-tools = "Debian=btrfs-tools Fedora=btrfs-progs"
 DISTRO_PN_ALIAS_pn-builder = "OE-Core"
+DISTRO_PN_ALIAS_pn-build-appliance-image = "OSPDT"
 DISTRO_PN_ALIAS_pn-calibrateproto = "OSPDT upstream=http://cgit.freedesktop.org/xorg/lib/libXCalibrate/"
 DISTRO_PN_ALIAS_pn-calibrateproto = "OSPDT upstream=http://cgit.freedesktop.org/xorg/proto/calibrateproto"
 DISTRO_PN_ALIAS_pn-cdrtools = "OpenSUSE=cdrtools OSPDT"
@@ -30,8 +34,9 @@ DISTRO_PN_ALIAS_pn-claws-plugin-maildir = "Fedora=claws-mail-plugins OpenSuSE=cl
 DISTRO_PN_ALIAS_pn-claws-plugin-mailmbox = "Fedora=claws-mail-plugins OpenSuSE=claws-mail-extra-plugins Debian=claws-mail-extra-plugins"
 DISTRO_PN_ALIAS_pn-claws-plugin-rssyl = "Fedora=claws-mail-plugins OpenSuSE=claws-mail-extra-plugins Debian=claws-mail-extra-plugins"
 DISTRO_PN_ALIAS_pn-clipboard-manager = "OpenedHand"
-DISTRO_PN_ALIAS_pn-clutter-1.8 = "Fedora=clutter OpenSuse=clutter Ubuntu=clutter-1.0 Mandriva=clutter Debian=clutter"
 DISTRO_PN_ALIAS_pn-clutter = "Fedora=clutter OpenSuse=clutter Ubuntu=clutter-1.0 Mandriva=clutter Debian=clutter"
+DISTRO_PN_ALIAS_pn-clutter-1.8 = "Fedora=clutter OpenSuse=clutter Ubuntu=clutter-1.0 Mandriva=clutter Debian=clutter"
+DISTRO_PN_ALIAS_pn-clutter-box2d = "Meego=clutter-box2d"
 DISTRO_PN_ALIAS_pn-clutter-gst-1.8 = "Fedora=clutter-gst Debian=libclutter-gst"
 DISTRO_PN_ALIAS_pn-clutter-gtk-1.8 = "Fedora=clutter-gtk OpenSuSE=clutter-gtk Ubuntu=clutter-gtk-0.10 Mandriva=clutter-gtk Debian=clutter-gtk"
 DISTRO_PN_ALIAS_pn-cogl = "Fedora=cogl OpenSuse=cogl Ubuntu=cogl Mandriva=cogl Debian=cogl"
@@ -64,7 +69,7 @@ DISTRO_PN_ALIAS_pn-core-image-sato-sdk-directdisk = "OE-Core"
 DISTRO_PN_ALIAS_pn-core-image-sato-sdk-live = "OE-Core"
 DISTRO_PN_ALIAS_pn-core-image-sato-sdk = "OE-Core"
 DISTRO_PN_ALIAS_pn-core-image-sdk = "OE-Core"
-DISTRO_PN_ALIAS_pn-core-x11 = "OE-Core"
+DISTRO_PN_ALIAS_pn-core-image-x11 = "OE-Core"
 DISTRO_PN_ALIAS_pn-cross-localedef = "OSPDT"
 DISTRO_PN_ALIAS_pn-cwautomacros= "OSPDT upstream=http://cwautomacros.berlios.de/"
 DISTRO_PN_ALIAS_pn-damageproto = "Meego=xorg-x11-proto-damageproto"
@@ -72,9 +77,9 @@ DISTRO_PN_ALIAS_pn-db = "Debian=db5.1 Ubuntu=db5.1"
 DISTRO_PN_ALIAS_pn-dbus-wait = "OpenedHand"
 DISTRO_PN_ALIAS_pn-directfb-examples = "Debian=directfb Fedora=directfb"
 DISTRO_PN_ALIAS_pn-distcc = "Debian=distcc Fedora=distcc"
+DISTRO_PN_ALIAS_pn-distcc-config = "OpenedHand"
 DISTRO_PN_ALIAS_pn-dmxproto = "Meego=xorg-x11-proto-dmxproto Ubuntu=x11proto-dmx Debian=x11proto-dmx"
-DISTRO_PN_ALIAS_pn-docbook-dsssl-stylesheet = "Fedora=docbook-style-dsssl Ubuntu=docbook-dsssl"
-DISTRO_PN_ALIAS_pn-docbook-dsssl-stylesheet-native = "Fedora=docbook-style-dsssl Ubuntu=docbook-dsssl"
+DISTRO_PN_ALIAS_pn-docbook-dsssl-stylesheets = "Fedora=docbook-style-dsssl Ubuntu=docbook-dsssl"
 DISTRO_PN_ALIAS_pn-docbook-sgml-dtd-3.1 = "Fedora=docbook-dtds Mandriva=docbook-dtd31-sgml"
 DISTRO_PN_ALIAS_pn-docbook-sgml-dtd-4.1 = "Fedora=docbook-dtds Mandriva=docbook-dtd41-sgml"
 DISTRO_PN_ALIAS_pn-docbook-sgml-dtd-4.5 = "Fedora=docbook-dtds Mandriva=docbook-dtd42-sgml"
@@ -84,7 +89,8 @@ DISTRO_PN_ALIAS_pn-dtc = "Fedora=dtc Ubuntu=dtc"
 DISTRO_PN_ALIAS_pn-dtc-native = "Fedora=dtc Ubuntu=dtc"
 DISTRO_PN_ALIAS_pn-eds-tools = "OpenedHand"
 DISTRO_PN_ALIAS_pn-eee-acpi-scripts = "Debian=eeepc-acpi-scripts Ubuntu=eeepc-acpi-scripts"
-DISTRO_PN_ALIAS_pn-eglibc-locale-nativesdk = "OE-Core"
+DISTRO_PN_ALIAS_pn-eglibc = "OE-Core"
+DISTRO_PN_ALIAS_pn-eglibc-initial = "OE-Core"
 DISTRO_PN_ALIAS_pn-eglibc-locale = "OE-Core"
 DISTRO_PN_ALIAS_pn-emgd-driver-bin = "Intel"
 DISTRO_PN_ALIAS_pn-encodings = "Ubuntu=xfonts-encodings Mandriva=x11-font-encodings Debian=xfonts-encodings"
@@ -111,9 +117,11 @@ DISTRO_PN_ALIAS_pn-gcc-runtime = "Ubuntu=gcc Fedora=gcc"
 DISTRO_PN_ALIAS_pn-gconf-dbus = "Meego=GConf-dbus"
 DISTRO_PN_ALIAS_pn-gdk-pixbuf-csource-native = "Debian=libgdk-pixbuf2.0-0 Fedora=gdk-pixbuf2"
 DISTRO_PN_ALIAS_pn-gdk-pixbuf = "Debian=libgdk-pixbuf2.0 Fedora=gdk-pixbuf"
+DISTRO_PN_ALIAS_pn-gettext-minimal-native = "Debian=gettext Fedora=gettext"
 DISTRO_PN_ALIAS_pn-glib-2.0 = "Meego=glib2 Fedora=glib2 OpenSuSE=glib2 Ubuntu=glib2.0 Mandriva=glib2.0 Debian=glib2.0"
 DISTRO_PN_ALIAS_pn-glproto = "Meego=xorg-x11-proto-glproto"
 DISTRO_PN_ALIAS_pn-gnu-config = "OpenedHand"
+DISTRO_PN_ALIAS_pn-grub-efi-i586 = "Ubuntu=grub Fedora=grub"
 DISTRO_PN_ALIAS_pn-gst-ffmpeg = "Mandriva=gstreamer0.10-ffmpeg Debian=gstreamer0.10-ffmpeg"
 DISTRO_PN_ALIAS_pn-gst-fluendo-mp3 = "Debian=gstreamer0.10-fluendo-mp3 Ubuntu=gstreamer0.10-fluendo-mp3"
 DISTRO_PN_ALIAS_pn-gst-fluendo-mpegdemux = "Ubuntu=gstreamer0.10-fluendo-mpegdemux Debian=gstreamer0.10-fluendo-mpegdemux"
@@ -124,6 +132,7 @@ DISTRO_PN_ALIAS_pn-gst-plugins-bad = "Fedora=gstreamer-plugins-bad-free OpenSuSE
 DISTRO_PN_ALIAS_pn-gst-plugins-base = "Meego=gst-plugins-base Fedora=gstreamer-plugins-base OpenSuSE=gstreamer-plugins-base Ubuntu=gst-plugins-base0.10 Mandriva=gstreamer0.10-plugins-base Debian=gst-plugins-base0.10"
 DISTRO_PN_ALIAS_pn-gst-plugins-good = "Meego=gst-plugins-good Fedora=gstreamer-plugins-good OpenSuSE=gstreamer-plugins-good Ubuntu=gst-plugins-good0.10 Mandriva=gstreamer0.10-plugins-good Debian=gst-plugins-good0.10"
 DISTRO_PN_ALIAS_pn-gst-plugins-ugly = "OpenSuSE=gstreamer-plugins-ugly Mandriva=gstreamer0.10-plugins-ugly Debian=gst-plugins-ugly0.10"
+DISTRO_PN_ALIAS_pn-gtk-doc-stub = "Fedora=gtk-doc Ubuntu=gtk-doc"
 DISTRO_PN_ALIAS_pn-gtk-engines = "Fedora=gtk2-engines OpenSuSE=gtk2-engines Ubuntu=gtk2-engines Mandriva=gtk-engines2 Debian=gtk2-engines"
 DISTRO_PN_ALIAS_pn-gtkhtml2 = "Debian=libgtkhtml2-0 Fedora=gtkhtml2"
 DISTRO_PN_ALIAS_pn-gtk+ = "Meego=gtk2 Fedora=gtk2 OpenSuSE=gtk2 Ubuntu=gtk+2.0 Mandriva=gtk+2.0 Debian=gtk+2.0"
@@ -136,6 +145,7 @@ DISTRO_PN_ALIAS_pn-imake = "Mandriva=xutils Ubuntu=xutils"
 DISTRO_PN_ALIAS_pn-initramfs-boot = "OE-Core"
 DISTRO_PN_ALIAS_pn-initramfs-live-boot = "OE-Core"
 DISTRO_PN_ALIAS_pn-initramfs-live-install = "OE-Core"
+DISTRO_PN_ALIAS_pn-initramfs-live-install-efi = "OE-Core"
 DISTRO_PN_ALIAS_pn-inputproto = "Meego=xorg-x11-proto-inputproto"
 DISTRO_PN_ALIAS_pn-iproute2 = "OSPDT"
 DISTRO_PN_ALIAS_pn-jpeg="OpenSuSE=libjpeg Ubuntu=libjpeg62"
@@ -183,7 +193,6 @@ DISTRO_PN_ALIAS_pn-liburcu = "Fedora=userspace-rcu Ubuntu=liburcu0"
 DISTRO_PN_ALIAS_pn-libusb-compat = "OSPDT"
 DISTRO_PN_ALIAS_pn-libx11 = "Debian=libx11-6 Fedora=libX11 Ubuntu=libx11-6 OpenSuSE=xorg-x11-libX11"
 DISTRO_PN_ALIAS_pn-libx11-diet = "Debian=libx11-6 Fedora=libX11 Ubuntu=libx11-6 OpenSuSE=xorg-x11-libX11"
-DISTRO_PN_ALIAS_pn-libx11-trim = "Debian=libx11-6 Fedora=libX11 Ubuntu=libx11-6 OpenSuSE=xorg-x11-libX11"
 DISTRO_PN_ALIAS_pn-libxcalibrate = "OSPDT upstream=http://cgit.freedesktop.org/xorg/lib/libXCalibrate/"
 DISTRO_PN_ALIAS_pn-libxfontcache = "Mandriva=libxfontcache Debian=libxfontcache"
 DISTRO_PN_ALIAS_pn-libxft = "Mandriva=libxft Debian=libxft2 Ubuntu=libxft2"
@@ -198,11 +207,17 @@ DISTRO_PN_ALIAS_pn-linux-libc-headers = "Debian=linux-kernel-headers Ubuntu=linu
 DISTRO_PN_ALIAS_pn-linux-libc-headers-yocto = "Debian=linux-kernel-headers Ubuntu=linux-kernel-headers"
 DISTRO_PN_ALIAS_pn-linux-yocto = "Debian=linux-base Ubuntu=linux"
 DISTRO_PN_ALIAS_pn-linux-yocto-rt = "Debian=linux-base Ubuntu=linux"
+DISTRO_PN_ALIAS_pn-linux-yocto-tiny = "OSPDT"
+DISTRO_PN_ALIAS_pn-lsbinitscripts = "Windriver"
 DISTRO_PN_ALIAS_pn-lsbsetup = "Windriver"
+DISTRO_PN_ALIAS_pn-lsbtest = "Windriver"
 DISTRO_PN_ALIAS_pn-ltp = "Ubuntu=ltp"
 DISTRO_PN_ALIAS_pn-lttng-control = "OSPDT upstream=http://lttng.org/"
+DISTRO_PN_ALIAS_pn-lttng-modules = "OSPDT upstream=http://lttng.org/"
+DISTRO_PN_ALIAS_pn-lttng-tools = "OSPDT upstream=http://lttng.org/"
 DISTRO_PN_ALIAS_pn-lttng-ust = "OSPDT upstream=http://lttng.org/"
 DISTRO_PN_ALIAS_pn-lttng-viewer = "OSPDT upstream=http://lttng.org/"
+DISTRO_PN_ALIAS_pn-lttng2-ust = "OSPDT upstream=http://lttng.org/"
 DISTRO_PN_ALIAS_pn-makedepend = "Mandriva=makedepend Ubuntu=xutils-dev"
 DISTRO_PN_ALIAS_pn-makedevs = "OE-Core"
 DISTRO_PN_ALIAS_pn-matchbox-config-gtk = "OpenedHand"
@@ -223,14 +238,14 @@ DISTRO_PN_ALIAS_pn-matchbox-wm = "OpenedHand"
 DISTRO_PN_ALIAS_pn-menu-cache = "OSPDT"
 DISTRO_PN_ALIAS_pn-mesa-dri = "Fedora=mesa Ubuntu=libgl1-mesa-dri"
 DISTRO_PN_ALIAS_pn-mesa-dri-glsl-native = "Fedora=mesa Ubuntu=libgl1-mesa-dri"
-DISTRO_PN_ALIAS_pn-mesa-xlib = "Fedora=mesa Ubuntu=libgl1-mesa-swx11"
 DISTRO_PN_ALIAS_pn-meta-environment-i586 = "OE-Core"
-DISTRO_PN_ALIAS_pn-meta-ide-support = 'OE-Core'
+DISTRO_PN_ALIAS_pn-meta-ide-support = "OE-Core"
 DISTRO_PN_ALIAS_pn-meta-toolchain-gmae = "OE-Core"
 DISTRO_PN_ALIAS_pn-meta-toolchain = "OE-Core"
 DISTRO_PN_ALIAS_pn-meta-toolchain-qte = "OE-Core"
-DISTRO_PN_ALIAS_pn-meta-toolchain-sdk = "OE-Core"
 DISTRO_PN_ALIAS_pn-mkfontdir = "Mandriva=mkfontdir Ubuntu=xfonts-utils Fedora=xorg-x11-font-utils"
+DISTRO_PN_ALIAS_pn-meta-toolchain-sdk = "OE-Core"
+DISTRO_PN_ALIAS_pn-mini-x-session = "OSPDT"
 DISTRO_PN_ALIAS_pn-mkfontscale = "Mandriva=mkfontscale Ubuntu=xfonts-utils Fedora=xorg-x11-font-utils"
 DISTRO_PN_ALIAS_pn-mktemp = "Mandriva=mktemp Fedora=mktemp"
 DISTRO_PN_ALIAS_pn-moblin-proto = "OE-Core"
@@ -239,20 +254,53 @@ DISTRO_PN_ALIAS_pn-modutils-initscripts = "OE-Core"
 DISTRO_PN_ALIAS_pn-msynctool = "OpenSuse=msynctool Mandriva=msynctool"
 DISTRO_PN_ALIAS_pn-n450-audio = "Intel"
 DISTRO_PN_ALIAS_pn-network-suspend-scripts = "OE-Core"
+DISTRO_PN_ALIAS_pn-nfs-export-root = "OpenedHand"
+DISTRO_PN_ALIAS_pn-ocf-linux = "OSPDT"
 DISTRO_PN_ALIAS_pn-ofono = "Debian=ofono Ubuntu=ofono"
 DISTRO_PN_ALIAS_pn-oh-puzzles = "OpenedHand"
 DISTRO_PN_ALIAS_pn-opkg-collateral = "OE-Core"
 DISTRO_PN_ALIAS_pn-opkg-config-base = "OE-Core"
-DISTRO_PN_ALIAS_pn-opkg-nogpg-native = "OE-Core"
-DISTRO_PN_ALIAS_pn-opkg-nogpg-nativesdk = "OE-Core"
-DISTRO_PN_ALIAS_pn-opkg-nogpg = "OE-Core"
-DISTRO_PN_ALIAS_pn-opkg_nogpg = "OSPDT upstream=http://svn.openmoko.org/trunk/src/tar"
+DISTRO_PN_ALIAS_pn-opkg-nogpg = "OSPDT upstream=http://svn.openmoko.org/trunk/src/tar"
 DISTRO_PN_ALIAS_pn-opkg = "OSPDT upstream=http://svn.openmoko.org/trunk/src/tar"
 DISTRO_PN_ALIAS_pn-opkg-utils = "OSPDT upstream=http://svn.openmoko.org/trunk/src/target/opkg/"
 DISTRO_PN_ALIAS_pn-oprofileui = "Fedora=oprofileui Ubuntu=oprofile-gui Debian=oprofile-gui"
+DISTRO_PN_ALIAS_pn-oprofileui-server = "Fedora=oprofileui Ubuntu=oprofile-gui Debian=oprofile-gui"
 DISTRO_PN_ALIAS_pn-orinoco-conf = "OE-Core"
 DISTRO_PN_ALIAS_pn-owl-video = "OpenedHand"
 DISTRO_PN_ALIAS_pn-package-index = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-base = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core-basic = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core-boot = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core-clutter = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core-console = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core-device-devel = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core-gtk-directfb = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core-lsb = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core-nfs = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core-qt = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core-qt4e = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core-sdk-gmae = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core-sdk = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core-ssh-dropbear = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core-ssh-openssh = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core-standalone-gmae-sdk-target = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core-standalone-sdk-target = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core-tools-debug = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core-tools = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core-tools-profile = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core-tools-testapps = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core-x11-mini = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core-x11 = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core-x11-base = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core-x11-sato = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core-x11-xserver = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-cross-canadian-i586 = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-qt4e = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-qte-toolchain-host = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-qte-toolchain-target = "Intel"
+DISTRO_PN_ALIAS_pn-packagegroup-sdk-host = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-self-hosted = "OE-Core"
 DISTRO_PN_ALIAS_pn-pointercal = "OE-Core"
 DISTRO_PN_ALIAS_pn-poky-feed-config-opkg = "OE-Core"
 DISTRO_PN_ALIAS_pn-pong-clock = "OpenedHand"
@@ -273,6 +321,7 @@ DISTRO_PN_ALIAS_pn-python-pygtk = "Debian=python-gtk2 Fedora=pygtk2 OpenSuSE=pyt
 DISTRO_PN_ALIAS_pn-python-pyrex = "Mandriva=python-pyrex Ubuntu=python-pyrex"
 DISTRO_PN_ALIAS_pn-python-scons = "Fedora=scons OpenSuSE=scons Ubuntu=scons Mandriva=scons Debian=scons"
 DISTRO_PN_ALIAS_pn-python-ZSI = "OE-Core"
+DISTRO_PN_ALIAS_pn-qemu-helper = "OpenedHand"
 DISTRO_PN_ALIAS_pn-qemu-config = "OpenedHand"
 DISTRO_PN_ALIAS_pn-qemugl = "OpenedHand"
 DISTRO_PN_ALIAS_pn-qemu-helper-native = "OpenedHand"
@@ -283,7 +332,7 @@ DISTRO_PN_ALIAS_pn-qt4-embedded = "OSPDT"
 DISTRO_PN_ALIAS_pn-qt4-graphics-system = "OE-Core"
 DISTRO_PN_ALIAS_pn-qt4-native = "Fedora=qt4 Debian=qt4-dev-tools"
 DISTRO_PN_ALIAS_pn-qt4-native = "Mandriva=libqt4-devel Ubuntu=libqt4-dev"
-DISTRO_PN_ALIAS_pn-qt4-tools-nativesdk = "Mandriva=libqt4-devel Ubuntu=libqt4-dev"
+DISTRO_PN_ALIAS_pn-qt4-tools = "Mandriva=libqt4-devel Ubuntu=libqt4-dev"
 DISTRO_PN_ALIAS_pn-qt4-x11-free = "Ubuntu=qt-x11-free Debian=qt-x11-free"
 DISTRO_PN_ALIAS_pn-qt-demo-init = "OE-Core"
 DISTRO_PN_ALIAS_pn-qt-mobility-embedded = "Ubuntu=qtmobility-dev Debian=qtmobility-dev"
@@ -291,6 +340,7 @@ DISTRO_PN_ALIAS_pn-qt-mobility-x11 = "Ubuntu=qtmobility-dev Debian=qtmobility-de
 DISTRO_PN_ALIAS_pn-quicky = "OSPDT"
 DISTRO_PN_ALIAS_pn-randrproto = "Meego=xorg-x11-proto-randrproto"
 DISTRO_PN_ALIAS_pn-recordproto = "Meego=xorg-x11-proto-recordproto"
+DISTRO_PN_ALIAS_pn-remake = "Mandriva=remake Debian=remake"
 DISTRO_PN_ALIAS_pn-renderproto = "Meego=xorg-x11-proto-renderproto"
 DISTRO_PN_ALIAS_pn-resourceproto = "Meego=xorg-x11-proto-resourceproto"
 DISTRO_PN_ALIAS_pn-rgb = "Fedora=xorg-X11-server-utils Debian=x11-xserver-utils"
@@ -306,6 +356,7 @@ DISTRO_PN_ALIAS_pn-sgmlspl = "Debian=sgmlspl Ubuntu=sgmlspl"
 DISTRO_PN_ALIAS_pn-shadow-securetty = "Ubuntu=shadow Fedora=shadow"
 DISTRO_PN_ALIAS_pn-shadow-sysroot = "Ubuntu=shadow Fedora=shadow"
 DISTRO_PN_ALIAS_pn-shasum-native = "OE-Core"
+DISTRO_PN_ALIAS_pn-shutdown-desktop = "OpenedHand"
 DISTRO_PN_ALIAS_pn-signgp-native = "OE-Core"
 DISTRO_PN_ALIAS_pn-stat = "Debian=coreutils Fedora=coreutils"
 DISTRO_PN_ALIAS_pn-swabber-native = "OE-Core"
@@ -313,41 +364,14 @@ DISTRO_PN_ALIAS_pn-systemtap-uprobes = "Ubuntu=systemtap Debian=systemtap"
 DISTRO_PN_ALIAS_pn-sysvinit-inittab = "OE-Core"
 DISTRO_PN_ALIAS_pn-table = "Intel"
 DISTRO_PN_ALIAS_pn-tar-replacement-native = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-base = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-core-basic = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-core-boot = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-core-clutter = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-core-console = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-core-gtk-directfb = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-core-lsb = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-core-nfs = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-core = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-core-qt = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-core-sdk-gmae = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-core-sdk = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-core-ssh-dropbear = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-core-ssh-openssh = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-core-standalone-gmae-sdk-target = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-core-standalone-sdk-target = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-core-tools-debug = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-core-tools = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-core-tools-profile = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-core-tools-testapps = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-core-x11-mini = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-core-x11 = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-core-x11-sato = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-cross-canadian-i586 = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-qt4e = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-qte-toolchain-host-nativesdk = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-qte-toolchain-host-natives = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-qte-toolchain-target = "Intel"
-DISTRO_PN_ALIAS_pn-packagegroup-sdk-host = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-self-hosted = "OE-Core"
 DISTRO_PN_ALIAS_pn-tcf-agent = "Windriver upstream=http://www.eclipse.org/dsdp/tm/"
+DISTRO_PN_ALIAS_pn-telepathy-python = "Debian=telepathy-python Ubuntu=telepathy-python"
+DISTRO_PN_ALIAS_pn-tiny-init = "OSPDT"
 DISTRO_PN_ALIAS_pn-tinylogin = "Debian=busybox Ubuntu=busybox Mandriva=busybox"
 DISTRO_PN_ALIAS_pn-trace-cmd = "Mandriva=trace-cmd Ubuntu=trace-cmd"
 DISTRO_PN_ALIAS_pn-trapproto = "Meego=xorg-x11-proto-trapproto"
 DISTRO_PN_ALIAS_pn-tremor = "OSPDT upstream=http://www.xiph.org/vorbis/"
+DISTRO_PN_ALIAS_pn-tslib = "Debian=tslib Ubuntu=tslib"
 DISTRO_PN_ALIAS_pn-ttf-bitstream-vera = "Debian=ttf-bitstream-vera Ubuntu=ttf-bitstream-vera"
 DISTRO_PN_ALIAS_pn-tzcode = "OSPDT"
 DISTRO_PN_ALIAS_pn-ubootchart = "OSPDT upstream=http://code.google.com/p/ubootchart"
@@ -363,14 +387,17 @@ DISTRO_PN_ALIAS_pn-util-macros = "Meego=xorg-x11-util-macros Fedora=xorg-x11-uti
 DISTRO_PN_ALIAS_pn-v86d = "Debian=v86d Ubuntu=v86d"
 DISTRO_PN_ALIAS_pn-videoproto = "Meego=xorg-x11-proto-videoproto"
 DISTRO_PN_ALIAS_pn-watchdog = "Debian=watchdog Ubuntu=watchdog Mandriva=watchdog"
-DISTRO_PN_ALIAS_pn-webkit-gtk = "Fedora=webkitgtk"
 DISTRO_PN_ALIAS_pn-webkit-gtk = "Fedora=webkitgtk Ubuntu=libwebkit"
 DISTRO_PN_ALIAS_pn-web = "OpenedHand"
 DISTRO_PN_ALIAS_pn-web-webkit = "OpenedHand"
+DISTRO_PN_ALIAS_pn-which = "Mandriva=which Fedora=which"
 DISTRO_PN_ALIAS_pn-wpa-supplicant = "Meego=wpa_supplicant Fedora=wpa_supplicant OpenSuSE=wpa_supplicant Ubuntu=wpasupplicant Mandriva=wpa_supplicant Debian=wpasupplicant"
 DISTRO_PN_ALIAS_pn-x11-common = "OE-Core"
 DISTRO_PN_ALIAS_pn-x11perf = "Fedora=xorg-x11-apps Ubuntu=x11-apps"
 DISTRO_PN_ALIAS_pn-x11vnc = "Fedora=x11vnc Ubuntu=x11vnc"
+DISTRO_PN_ALIAS_pn-xcb-util-wm = "Debian=xcb-util Fedora=xcb-util"
+DISTRO_PN_ALIAS_pn-xcb-util-image = "Debian=xcb-util Fedora=xcb-util"
+DISTRO_PN_ALIAS_pn-xcb-util-keysyms = "Debian=xcb-util Fedora=xcb-util"
 DISTRO_PN_ALIAS_pn-xcmiscproto = "Meego=xorg-x11-proto-xcmiscproto"
 DISTRO_PN_ALIAS_pn-xcursor-transparent-theme = "OpenedHand"
 DISTRO_PN_ALIAS_pn-xdpyinfo = "Fedora=xorg-x11-utils Ubuntu=x11-utils"
@@ -409,7 +436,6 @@ DISTRO_PN_ALIAS_pn-xserver-xf86-config = "OE-Core"
 DISTRO_PN_ALIAS_pn-xserver-xf86-dri-lite = "Fedora=xorg-x11-server Ubuntu=xserver-xorg"
 DISTRO_PN_ALIAS_pn-xserver-xf86-lite = "Fedora=xorg-x11-server Ubuntu=xserver-xorg"
 DISTRO_PN_ALIAS_pn-xserver-xorg = "Fedora=xorg-x11-server Ubuntu=xserver-xorg"
-DISTRO_PN_ALIAS_pn-xserver-xorg-lite = "Fedora=xorg-x11-server Ubuntu=xserver-xorg"
 DISTRO_PN_ALIAS_pn-xset = "Fedora=xorg-x11-server-utils Ubuntu=x11-xserver-utils Debian=x11-xserver-utils Opensuse=xorg-x11"
 DISTRO_PN_ALIAS_pn-xtscal = "OSPDT upstream=http://gpe.linuxtogo.org/download/source/"
 DISTRO_PN_ALIAS_pn-xvideo-tests = "OpenedHand"

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

@@ -358,7 +358,6 @@ RECIPE_MAINTAINER_pn-libuser = "Valentin Popa <valentin.popa@intel.com>"
 RECIPE_MAINTAINER_pn-libvorbis = "Cristian Iorga <cristian.iorga@intel.com>"
 RECIPE_MAINTAINER_pn-libx11 = "Valentin Popa <valentin.popa@intel.com>"
 RECIPE_MAINTAINER_pn-libx11-diet = "Kai Kang <kai.kang@windriver.com>"
-RECIPE_MAINTAINER_pn-libx11-trim = "Valentin Popa <valentin.popa@intel.com>"
 RECIPE_MAINTAINER_pn-libxau = "Valentin Popa <valentin.popa@intel.com>"
 RECIPE_MAINTAINER_pn-libxaw = "Valentin Popa <valentin.popa@intel.com>"
 RECIPE_MAINTAINER_pn-libxcalibrate = "Valentin Popa <valentin.popa@intel.com>"
@@ -449,7 +448,6 @@ RECIPE_MAINTAINER_pn-mdadm = "Laurentiu Palcu <laurentiu.palcu@intel.com>"
 RECIPE_MAINTAINER_pn-menu-cache = "Valentin Popa <valentin.popa@intel.com>"
 RECIPE_MAINTAINER_pn-mesa-dri = "Valentin Popa <valentin.popa@intel.com>"
 RECIPE_MAINTAINER_pn-mesa-dri-glsl-native = "Valentin Popa <valentin.popa@intel.com>"
-RECIPE_MAINTAINER_pn-mesa-xlib = "Valentin Popa <valentin.popa@intel.com>"
 RECIPE_MAINTAINER_pn-meta-ide-support = "Saul Wold <sgw@linux.intel.com>"
 RECIPE_MAINTAINER_pn-metacity = "Valentin Popa <valentin.popa@intel.com>"
 RECIPE_MAINTAINER_pn-mingetty = "Kai Kang <kai.kang@windriver.com>"
@@ -722,7 +720,6 @@ RECIPE_MAINTAINER_pn-xrestop = "Laurentiu Palcu <laurentiu.palcu@intel.com>"
 RECIPE_MAINTAINER_pn-xserver-nodm-init = "Laurentiu Palcu <laurentiu.palcu@intel.com>"
 RECIPE_MAINTAINER_pn-xserver-xf86-config = "Laurentiu Palcu <laurentiu.palcu@intel.com>"
 RECIPE_MAINTAINER_pn-xserver-xorg = "Laurentiu Palcu <laurentiu.palcu@intel.com>"
-RECIPE_MAINTAINER_pn-xserver-xorg-lite = "Kai Kang <kai.kang@windriver.com>"
 RECIPE_MAINTAINER_pn-xset = "Laurentiu Palcu <laurentiu.palcu@intel.com>"
 RECIPE_MAINTAINER_pn-xtrans = "Laurentiu Palcu <laurentiu.palcu@intel.com>"
 RECIPE_MAINTAINER_pn-xtscal = "Laurentiu Palcu <laurentiu.palcu@intel.com>"

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

@@ -210,7 +210,6 @@ RECIPE_COLOR_pn-liburcu = "yellow"
 RECIPE_COLOR_pn-libusb1 = "yellow"
 RECIPE_COLOR_pn-libuser = "yellow"
 RECIPE_COLOR_pn-libx11 = "yellow"
-RECIPE_COLOR_pn-libx11-trim = "yellow"
 RECIPE_COLOR_pn-libxau = "yellow"
 RECIPE_COLOR_pn-libxaw = "red"
 RECIPE_COLOR_pn-libxcalibrate = "yellow"

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

@@ -37,7 +37,7 @@ DISTRO = "poky-tiny"
 # Distro config is evaluated after the machine config, so we have to explicitly
 # set the kernel provider to override a machine config.
 PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-tiny"
-PREFERRED_VERSION_linux-yocto-tiny = "3.2%"
+PREFERRED_VERSION_linux-yocto-tiny = "3.4%"
 
 # We can use packagegroup-core-boot, but in the future we may need a new packagegroup-core-tiny
 #POKY_DEFAULT_EXTRA_RDEPENDS += "packagegroup-core-boot"
@@ -63,6 +63,7 @@ ASSUME_PROVIDED += "pkgconfig$"
 # Reconfigure eglibc for a smaller installation
 # Comment out any of the lines below to disable them in the build
 DISTRO_FEATURES_LIBC_TINY = "libc-libm libc-crypt"
+DISTRO_FEATURES_LIBC_TINY_append_x86-64 = " libc-libm-big"
 
 # Required for "who"
 DISTRO_FEATURES_LIBC_MINIMAL = "libc-utmp libc-getlogin"

meta-yocto/conf/distro/poky.conf

@@ -1,8 +1,8 @@
 DISTRO = "poky"
-DISTRO_NAME = "Yocto (Built by Poky 7.0)"
-DISTRO_VERSION = "1.2+snapshot-${DATE}"
+DISTRO_NAME = "Poky 8.0 (Yocto Project 1.3 Reference Distro)"
+DISTRO_VERSION = "1.3"
 SDK_VENDOR = "-pokysdk"
-SDK_VERSION := "${@'${DISTRO_VERSION}'.replace('snapshot-${DATE}','snapshot')}"
+SDK_VERSION := "${DISTRO_VERSION}"
 
 MAINTAINER = "Poky <poky@yoctoproject.org>"
 
@@ -62,25 +62,33 @@ https://.*/.*    http://downloads.yoctoproject.org/mirror/sources/ \n"
 # The CONNECTIVITY_CHECK_URI's are used to test whether we can succesfully
 # fetch from the network (and warn you if not). To disable the test set
 # the variable to be empty.
-CONNECTIVITY_CHECK_URIS ?= "git://git.yoctoproject.org/yocto-firewall-test;protocol=git;rev=HEAD \
-                          https://eula-downloads.yoctoproject.org/index.php \
-                          http://bugzilla.yoctoproject.org/report.cgi"
+# Git example url: git://git.yoctoproject.org/yocto-firewall-test;protocol=git;rev=HEAD
+
+CONNECTIVITY_CHECK_URIS ?= " \
+             https://eula-downloads.yoctoproject.org/index.php \
+             http://bugzilla.yoctoproject.org/report.cgi"
 
 SANITY_TESTED_DISTROS ?= " \
             Yocto (Built by Poky 7.0) 1.2 \n \
+            Yocto (Built by Poky 8.0) 1.3 \n \
+            Poky 7.0 (Yocto Project 1.2 Reference Distro) 1.2 \n \
+            Poky 8.0 (Yocto Project 1.3 Reference Distro) 1.3 \n \
             Ubuntu 10.04.4 LTS \n \
             Ubuntu 11.10 \n \
             Ubuntu 12.04 LTS \n \
             Ubuntu 12.04.1 LTS \n \
-            Fedora release 15 (Lovelock) \n \
+            Ubuntu 12.10 \n \
             Fedora release 16 (Verne) \n \
             Fedora release 17 (Beefy Miracle) \n \
+            Fedora release 18 (Spherical Cow) \n \
             CentOS release 5.6 (Final) \n \
             CentOS release 5.7 (Final) \n \
-            CentOS release 6.2 (Final) \n \
-            Debian GNU/Linux 6.0.4 (squeeze) \n \
+            CentOS release 5.8 (Final) \n \
+            CentOS release 6.3 (Final) \n \
+            Debian GNU/Linux 6.0.6 (squeeze) \n \
             openSUSE 11.4 \n \
             openSUSE 12.1 \n \
+            openSUSE 12.2 \n \
 	    "
 
 # Default hash policy for distro
@@ -93,6 +101,10 @@ BB_SIGNATURE_HANDLER ?= 'OEBasicHash'
 #
 OELAYOUT_ABI = "8"
 
-WARN_QA = "unsafe-references-in-binaries unsafe-references-in-scripts"
+# add poky sanity bbclass
+INHERIT += "poky-sanity"
+
+#WARN_QA = "unsafe-references-in-binaries unsafe-references-in-scripts"
+WARN_QA = ""
 ERROR_QA = "dev-so debug-deps dev-deps debug-files arch la2 pkgconfig la perms useless-rpaths rpaths staticdev ldflags"
 

meta-yocto/conf/local.conf.sample

@@ -141,7 +141,7 @@ PACKAGE_CLASSES ?= "package_rpm"
 #                     (useful if you want to develop against libs in the image)
 #  "tools-sdk"      - add development tools (gcc, make, pkgconfig etc.)
 #  "tools-debug"    - add debugging tools (gdb, strace)
-#  "tools-profile"  - add profiling tools (oprofile, exmap, lttng valgrind (x86 only))
+#  "tools-profile"  - add profiling tools (oprofile, exmap, lttng, valgrind)
 #  "tools-testapps" - add useful testing tools (ts_print, aplay, arecord etc.)
 #  "debug-tweaks"   - make an image suitable for development
 #                     e.g. ssh root access has a blank password

meta/classes/autotools.bbclass

@@ -89,92 +89,105 @@ oe_runconf () {
 
 AUTOTOOLS_AUXDIR ?= "${S}"
 
-autotools_do_configure() {
-	case ${PN} in
-	autoconf*)
-	;;
-	automake*)
-	;;
-	*)
-		# WARNING: gross hack follows:
-		# An autotools built package generally needs these scripts, however only
-		# automake or libtoolize actually install the current versions of them.
-		# This is a problem in builds that do not use libtool or automake, in the case
-		# where we -need- the latest version of these scripts.  e.g. running a build
-		# for a package whose autotools are old, on an x86_64 machine, which the old
-		# config.sub does not support.  Work around this by installing them manually
-		# regardless.
-		( for ac in `find ${S} -name configure.in -o -name configure.ac`; do
-			rm -f `dirname $ac`/configure
-			done )
-		if [ -e ${S}/configure.in -o -e ${S}/configure.ac ]; then
-			olddir=`pwd`
-			cd ${S}
-			# Remove any previous copy of the m4 macros
-			rm -rf ${B}/aclocal-copy/
-			if [ x"${acpaths}" = xdefault ]; then
-				acpaths=
-				for i in `find ${S} -maxdepth 2 -name \*.m4|grep -v 'aclocal.m4'| \
-					grep -v 'acinclude.m4' | sed -e 's,\(.*/\).*$,\1,'|sort -u`; do
-					acpaths="$acpaths -I $i"
-				done
-			else
-				acpaths="${acpaths}"
-			fi
-			AUTOV=`automake --version |head -n 1 |sed "s/.* //;s/\.[0-9]\+$//"`
-			automake --version
-			echo "AUTOV is $AUTOV"
-			if [ -d ${STAGING_DATADIR_NATIVE}/aclocal-$AUTOV ]; then
-				acpaths="$acpaths -I${STAGING_DATADIR_NATIVE}/aclocal-$AUTOV"
-			fi
-			# The aclocal directory could get modified by other processes 
-			# uninstalling data from the sysroot. See Yocto #861 for details.
-			# We avoid this by taking a copy here and then files cannot disappear.
-			if [ -d ${STAGING_DATADIR}/aclocal ]; then
-				# for scratch build this directory can be empty
-				# so avoid cp's no files to copy error
-				cp-noerror ${STAGING_DATADIR}/aclocal ${B}/aclocal-copy/
-				acpaths="$acpaths -I ${B}/aclocal-copy/"
-			fi
-			# autoreconf is too shy to overwrite aclocal.m4 if it doesn't look
-			# like it was auto-generated.  Work around this by blowing it away
-			# by hand, unless the package specifically asked not to run aclocal.
-			if ! echo ${EXTRA_AUTORECONF} | grep -q "aclocal"; then
-				rm -f aclocal.m4
-			fi
-			if [ -e configure.in ]; then
-			  CONFIGURE_AC=configure.in
-			else
-			  CONFIGURE_AC=configure.ac
-			fi
-			if ! echo ${EXTRA_OECONF} | grep -q "\-\-disable-nls"; then
-			  if grep "^[[:space:]]*AM_GLIB_GNU_GETTEXT" $CONFIGURE_AC >/dev/null; then
-			    if grep "sed.*POTFILES" $CONFIGURE_AC >/dev/null; then
-			      : do nothing -- we still have an old unmodified configure.ac
-			    else
-			      bbnote Executing glib-gettextize --force --copy
-			      echo "no" | glib-gettextize --force --copy
-			    fi
-			  else if grep "^[[:space:]]*AM_GNU_GETTEXT" $CONFIGURE_AC >/dev/null; then
-                            # We'd call gettextize here if it wasn't so broken...
-			    cp ${STAGING_DATADIR}/gettext/config.rpath ${AUTOTOOLS_AUXDIR}/
-			    if [ -d ${S}/po/ -a ! -e ${S}/po/Makefile.in.in ]; then
-			      cp ${STAGING_DATADIR}/gettext/po/Makefile.in.in ${S}/po/
-                            fi
-			  fi
-			fi
-			fi
-			mkdir -p m4
-			if grep "^[[:space:]]*[AI][CT]_PROG_INTLTOOL" $CONFIGURE_AC >/dev/null; then
-			  bbnote Executing intltoolize --copy --force --automake
-			  intltoolize --copy --force --automake
-			fi
-			bbnote Executing autoreconf --verbose --install --force ${EXTRA_AUTORECONF} $acpaths
-			autoreconf -Wcross --verbose --install --force ${EXTRA_AUTORECONF} $acpaths || bbfatal "autoreconf execution failed."
-			cd $olddir
+CONFIGURESTAMPFILE = "${WORKDIR}/configure.sstate"
+
+autotools_preconfigure() {
+	if [ -n "${CONFIGURESTAMPFILE}" -a -e "${CONFIGURESTAMPFILE}" ]; then
+		if [ "`cat ${CONFIGURESTAMPFILE}`" != "${BB_TASKHASH}" -a "${S}" != "${B}" ]; then
+			echo "Previously configured separate build directory detected, cleaning ${B}"
+			rm -rf ${B}
+			mkdir ${B}
 		fi
-	;;
-	esac
+	fi
+}
+
+autotools_postconfigure(){
+	if [ -n "${CONFIGURESTAMPFILE}" ]; then
+		echo ${BB_TASKHASH} > ${CONFIGURESTAMPFILE}
+	fi
+}
+
+do_configure[prefuncs] += "autotools_preconfigure"
+do_configure[postfuncs] += "autotools_postconfigure"
+
+autotools_do_configure() {
+	# WARNING: gross hack follows:
+	# An autotools built package generally needs these scripts, however only
+	# automake or libtoolize actually install the current versions of them.
+	# This is a problem in builds that do not use libtool or automake, in the case
+	# where we -need- the latest version of these scripts.  e.g. running a build
+	# for a package whose autotools are old, on an x86_64 machine, which the old
+	# config.sub does not support.  Work around this by installing them manually
+	# regardless.
+	( for ac in `find ${S} -name configure.in -o -name configure.ac`; do
+		rm -f `dirname $ac`/configure
+		done )
+	if [ -e ${S}/configure.in -o -e ${S}/configure.ac ]; then
+		olddir=`pwd`
+		cd ${S}
+		# Remove any previous copy of the m4 macros
+		rm -rf ${B}/aclocal-copy/
+		if [ x"${acpaths}" = xdefault ]; then
+			acpaths=
+			for i in `find ${S} -maxdepth 2 -name \*.m4|grep -v 'aclocal.m4'| \
+				grep -v 'acinclude.m4' | sed -e 's,\(.*/\).*$,\1,'|sort -u`; do
+				acpaths="$acpaths -I $i"
+			done
+		else
+			acpaths="${acpaths}"
+		fi
+		AUTOV=`automake --version |head -n 1 |sed "s/.* //;s/\.[0-9]\+$//"`
+		automake --version
+		echo "AUTOV is $AUTOV"
+		if [ -d ${STAGING_DATADIR_NATIVE}/aclocal-$AUTOV ]; then
+			acpaths="$acpaths -I${STAGING_DATADIR_NATIVE}/aclocal-$AUTOV"
+		fi
+		# The aclocal directory could get modified by other processes 
+		# uninstalling data from the sysroot. See Yocto #861 for details.
+		# We avoid this by taking a copy here and then files cannot disappear.
+		if [ -d ${STAGING_DATADIR}/aclocal ]; then
+			# for scratch build this directory can be empty
+			# so avoid cp's no files to copy error
+			cp-noerror ${STAGING_DATADIR}/aclocal ${B}/aclocal-copy/
+			acpaths="$acpaths -I ${B}/aclocal-copy/"
+		fi
+		# autoreconf is too shy to overwrite aclocal.m4 if it doesn't look
+		# like it was auto-generated.  Work around this by blowing it away
+		# by hand, unless the package specifically asked not to run aclocal.
+		if ! echo ${EXTRA_AUTORECONF} | grep -q "aclocal"; then
+			rm -f aclocal.m4
+		fi
+		if [ -e configure.in ]; then
+			CONFIGURE_AC=configure.in
+		else
+			CONFIGURE_AC=configure.ac
+		fi
+		if ! echo ${EXTRA_OECONF} | grep -q "\-\-disable-nls"; then
+			if grep "^[[:space:]]*AM_GLIB_GNU_GETTEXT" $CONFIGURE_AC >/dev/null; then
+				if grep "sed.*POTFILES" $CONFIGURE_AC >/dev/null; then
+					: do nothing -- we still have an old unmodified configure.ac
+		    		else
+					bbnote Executing glib-gettextize --force --copy
+					echo "no" | glib-gettextize --force --copy
+				fi
+			else if grep "^[[:space:]]*AM_GNU_GETTEXT" $CONFIGURE_AC >/dev/null; then
+				# We'd call gettextize here if it wasn't so broken...
+					cp ${STAGING_DATADIR}/gettext/config.rpath ${AUTOTOOLS_AUXDIR}/
+					if [ -d ${S}/po/ -a ! -e ${S}/po/Makefile.in.in ]; then
+						cp ${STAGING_DATADIR}/gettext/po/Makefile.in.in ${S}/po/
+					fi
+				fi
+			fi
+		fi
+		mkdir -p m4
+		if grep "^[[:space:]]*[AI][CT]_PROG_INTLTOOL" $CONFIGURE_AC >/dev/null; then
+			bbnote Executing intltoolize --copy --force --automake
+			intltoolize --copy --force --automake
+		fi
+		bbnote Executing autoreconf --verbose --install --force ${EXTRA_AUTORECONF} $acpaths
+		autoreconf -Wcross --verbose --install --force ${EXTRA_AUTORECONF} $acpaths || bbfatal "autoreconf execution failed."
+		cd $olddir
+	fi
 	if [ -e ${S}/configure ]; then
 		oe_runconf
 	else

meta/classes/bin_package.bbclass

@@ -0,0 +1,36 @@
+#
+# ex:ts=4:sw=4:sts=4:et
+# -*- tab-width: 4; c-basic-offset: 4; indent-tabs-mode: nil -*-
+#
+# Common variable and task for the binary package recipe.
+# Basic principle:
+# * The files have been unpacked to ${S} by base.bbclass
+# * Skip do_configure and do_compile
+# * Use do_install to install the files to ${D}
+#
+# Note:
+# The "subdir" parameter in the SRC_URI is useful when the input package
+# is rpm, ipk, deb and so on, for example:
+#
+# SRC_URI = "http://foo.com/foo-1.0-r1.i586.rpm;subdir=foo-1.0"
+#
+# Then the files would be unpacked to ${WORKDIR}/foo-1.0, otherwise
+# they would be in ${WORKDIR}.
+#
+
+# Skip the unwanted steps
+do_configure[noexec] = "1"
+do_compile[noexec] = "1"
+
+# Install the files to ${D}
+bin_package_do_install () {
+    # Do it carefully
+    [ -d "${S}" ] || exit 1
+    cd ${S} || exit 1
+    tar --no-same-owner --exclude='./patches' --exclude='./.pc' -cpf - . \
+        | tar --no-same-owner -xpf - -C ${D}
+}
+
+FILES_${PN} = "/"
+
+EXPORT_FUNCTIONS do_install