multilib.conf: Clean up file and add missing entries for various dependencies

This patch adds in various missing dependencies to ensure the set
of recipes listed for multilib support can be cleanly built.

(From OE-Core rev: 1d2697e6f00cc3771f39f5a7d4384a22d9696b16)

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

.gitignore

@@ -9,11 +9,9 @@ build*/pyshtables.py
 pstage/
 scripts/oe-git-proxy-socks
 sources/
-meta-darwin
-meta-maemo
-meta-extras
-meta-m2
-meta-prvt*
+meta-*
+!meta-skeleton
+!meta-demoapps
 *.swp
 *.orig
 *.rej

README

@@ -20,6 +20,10 @@ The Yocto Project has extensive documentation about the system including a
 reference manual which can be found at:
     http://yoctoproject.org/community/documentation
 
-For information about OpenEmbedded see their website:
+OpenEmbedded-Core is a layer containing the core metadata for current versions
+of OpenEmbedded. It is distro-less (can build a functional image with
+DISTRO = "") and contains only emulated machine support.
+
+For information about OpenEmbedded, see the OpenEmbedded website:
     http://www.openembedded.org/
 

README.hardware

@@ -68,12 +68,12 @@ Intel Atom based PCs and devices (atom-pc)
 
 The atom-pc MACHINE is tested on the following platforms:
 
-  o Asus eee901
+  o Asus EeePC 901
   o Acer Aspire One
   o Toshiba NB305
   o Intel Embedded Development Board 1-N450 (Black Sand)
 
-and is likely to work on many unlisted atom based devices. The MACHINE type
+and is likely to work on many unlisted Atom based devices. The MACHINE type
 supports ethernet, wifi, sound, and i915 graphics by default in addition to
 common PC input devices, busses, and so on.
 
@@ -83,26 +83,18 @@ straightforward with a caveat for USB devices. The following examples assume the
 target boot device is /dev/sdb, be sure to verify this and use the correct
 device as the following commands are run as root and are not reversable.
 
-Hard Disk:
-  1. Build a directdisk image format. This will generate proper partition tables
-     that will in turn be written to the physical media. For example:
-
-     $ bitbake core-image-minimal-directdisk
-  
-  2. Use the "dd" utility to write the image to the raw block device. For example:
-
-     # dd if=core-image-minimal-directdisk-atom-pc.hdddirect of=/dev/sdb
-
 USB Device:
-  1. Build an hddimg image format. This is a simple filesystem without partition
-     tables and is suitable for USB keys. For example:
+  1. Build a live image. This image type consists of a simple filesystem
+     without a partition table, which is suitable for USB keys, and with the
+     default setup for the atom-pc machine, this image type is built
+     automatically for any image you build. For example:
 
-     $ bitbake core-image-minimal-live
+     $ bitbake core-image-minimal
 
   2. Use the "dd" utility to write the image to the raw block device. For
      example:
 
-     # dd if=core-image-minimal-live-atom-pc.hddimg of=/dev/sdb
+     # dd if=core-image-minimal-atom-pc.hddimg of=/dev/sdb
 
   If the device fails to boot with "Boot error" displayed, it is likely the BIOS
   cannot understand the physical layout of the disk (or rather it expects a
@@ -126,7 +118,7 @@ USB Device:
 
      b. Copy the contents of the poky image to the USB-ZIP mode device:
 
-     # mount -o loop core-image-minimal-live-atom-pc.hddimg  /tmp/image
+     # mount -o loop core-image-minimal-atom-pc.hddimg  /tmp/image
      # mount /dev/sdb4 /tmp/usbkey
      # cp -rf /tmp/image/* /tmp/usbkey
 
@@ -150,7 +142,7 @@ faster CPU, more RAM, an ethernet port, more USB ports, microSD, and removes
 the NAND flash. The beagleboard MACHINE is tested on the following platforms:
 
   o Beagleboard C4
-  o Beagleboard xM Rev A
+  o Beagleboard xM rev A & B
 
 The Beagleboard C4 has NAND, while the xM does not. For the sake of simplicity,
 these instructions assume you have erased the NAND on the C4 so its boot

bitbake/bin/bitbake

@@ -40,7 +40,7 @@ from bb import cooker
 from bb import ui
 from bb import server
 
-__version__ = "1.13.3"
+__version__ = "1.15.0"
 logger = logging.getLogger("BitBake")
 
 
@@ -165,6 +165,9 @@ Default BBFILES are the .bb files in the current directory.""")
     parser.add_option("", "--revisions-changed", help = "Set the exit code depending on whether upstream floating revisions have changed or not",
                action = "store_true", dest = "revisions_changed", default = False)
 
+    parser.add_option("", "--server-only", help = "Run bitbake without UI,  the frontend can connect with bitbake server itself",
+               action = "store_true", dest = "server_only", default = False)
+
     options, args = parser.parse_args(sys.argv)
 
     configuration = BBConfiguration(options)
@@ -186,6 +189,9 @@ Default BBFILES are the .bb files in the current directory.""")
         sys.exit("FATAL: Invalid server type '%s' specified.\n"
                  "Valid interfaces: xmlrpc, process [default], none." % servertype)
 
+    if configuration.server_only and configuration.servertype != "xmlrpc":
+        sys.exit("FATAL: If '--server-only' is defined, we must set the servertype as 'xmlrpc'.\n")
+
     # Save a logfile for cooker into the current working directory. When the
     # server is daemonized this logfile will be truncated.
     cooker_logfile = os.path.join(os.getcwd(), "cooker.log")
@@ -222,14 +228,17 @@ Default BBFILES are the .bb files in the current directory.""")
 
     logger.removeHandler(handler)
 
-    # Setup a connection to the server (cooker)
-    server_connection = server.establishConnection()
+    if not configuration.server_only:
+        # Setup a connection to the server (cooker)
+        server_connection = server.establishConnection()
 
-    try:
-        return server.launchUI(ui_main, server_connection.connection, server_connection.events)
-    finally:
-        bb.event.ui_queue = []
-        server_connection.terminate()
+        try:
+            return server.launchUI(ui_main, server_connection.connection, server_connection.events)
+        finally:
+            bb.event.ui_queue = []
+            server_connection.terminate()
+    else:
+        print("server address: %s, server port: %s" % (server.serverinfo.host, server.serverinfo.port))
 
     return 1
 

bitbake/bin/bitbake-layers

@@ -8,6 +8,7 @@ import cmd
 import logging
 import os
 import sys
+import fnmatch
 
 bindir = os.path.dirname(__file__)
 topdir = os.path.dirname(bindir)
@@ -18,6 +19,7 @@ import bb.cooker
 import bb.providers
 import bb.utils
 from bb.cooker import state
+import bb.fetch2
 
 
 logger = logging.getLogger('BitBake')
@@ -138,9 +140,10 @@ Highest priority recipes are listed with the recipes they overlay as subitems.
     def do_flatten(self, args):
         """flattens layer configuration into a separate output directory.
 
-usage: flatten <outputdir>
+usage: flatten [layer1 layer2 [layer3]...] <outputdir>
 
-Takes the current layer configuration and builds a "flattened" directory
+Takes the specified layers (or all layers in the current layer
+configuration if none are specified) and builds a "flattened" directory
 containing the contents of all layers, with any overlayed recipes removed
 and bbappends appended to the corresponding recipes. Note that some manual
 cleanup may still be necessary afterwards, in particular:
@@ -148,21 +151,63 @@ cleanup may still be necessary afterwards, in particular:
 * where non-recipe files (such as patches) are overwritten (the flatten
   command will show a warning for these)
 * where anything beyond the normal layer setup has been added to
-  layer.conf (only the lowest priority layer's layer.conf is used)
+  layer.conf (only the lowest priority number layer's layer.conf is used)
 * overridden/appended items from bbappends will need to be tidied up
+* when the flattened layers do not have the same directory structure (the
+  flatten command should show a warning when this will cause a problem)
+
+Warning: if you flatten several layers where another layer is intended to
+be used "inbetween" them (in layer priority order) such that recipes /
+bbappends in the layers interact, and then attempt to use the new output
+layer together with that other layer, you may no longer get the same
+build results (as the layer priority order has effectively changed).
 """
         arglist = args.split()
-        if len(arglist) != 1:
+        if len(arglist) < 1:
             logger.error('Please specify an output directory')
             self.do_help('flatten')
             return
 
-        if os.path.exists(arglist[0]) and os.listdir(arglist[0]):
-            logger.error('Directory %s exists and is non-empty, please clear it out first' % arglist[0])
+        if len(arglist) == 2:
+            logger.error('If you specify layers to flatten you must specify at least two')
+            self.do_help('flatten')
+            return
+
+        outputdir = arglist[-1]
+        if os.path.exists(outputdir) and os.listdir(outputdir):
+            logger.error('Directory %s exists and is non-empty, please clear it out first' % outputdir)
             return
 
         self.check_prepare_cooker()
         layers = (self.config_data.getVar('BBLAYERS', True) or "").split()
+        if len(arglist) > 2:
+            layernames = arglist[:-1]
+            found_layernames = []
+            found_layerdirs = []
+            for layerdir in layers:
+                for layername, _, regex, _ in self.cooker.status.bbfile_config_priorities:
+                    if layername in layernames:
+                        if regex.match(os.path.join(layerdir, 'test')):
+                            found_layerdirs.append(layerdir)
+                            found_layernames.append(layername)
+                            break
+
+            for layername in layernames:
+                if not layername in found_layernames:
+                    logger.error('Unable to find layer %s in current configuration, please run "%s show_layers" to list configured layers' % (layername, os.path.basename(sys.argv[0])))
+                    return
+            layers = found_layerdirs
+        else:
+            layernames = []
+
+        # Ensure a specified path matches our list of layers
+        def layer_path_match(path):
+            for layerdir in layers:
+                if path.startswith(os.path.join(layerdir, '')):
+                    return layerdir
+            return None
+
+        appended_recipes = []
         for layer in layers:
             overlayed = []
             for f in self.cooker.overlayed.iterkeys():
@@ -180,7 +225,7 @@ cleanup may still be necessary afterwards, in particular:
                         ext = os.path.splitext(f1)[1]
                         if ext != '.bbappend':
                             fdest = f1full[len(layer):]
-                            fdest = os.path.normpath(os.sep.join([arglist[0],fdest]))
+                            fdest = os.path.normpath(os.sep.join([outputdir,fdest]))
                             bb.utils.mkdirhier(os.path.dirname(fdest))
                             if os.path.exists(fdest):
                                 if f1 == 'layer.conf' and root.endswith('/conf'):
@@ -195,7 +240,60 @@ cleanup may still be necessary afterwards, in particular:
                                     if appends:
                                         logger.plain('  Applying appends to %s' % fdest )
                                         for appendname in appends:
-                                            self.apply_append(appendname, fdest)
+                                            if layer_path_match(appendname):
+                                                self.apply_append(appendname, fdest)
+                                    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():
+            if recipename not in appended_recipes:
+                appends = self.cooker_data.appends[recipename]
+                first_append = None
+                for appendname in appends:
+                    layer = layer_path_match(appendname)
+                    if layer:
+                        if first_append:
+                            self.apply_append(appendname, first_append)
+                        else:
+                            fdest = appendname[len(layer):]
+                            fdest = os.path.normpath(os.sep.join([outputdir,fdest]))
+                            bb.utils.mkdirhier(os.path.dirname(fdest))
+                            bb.utils.copyfile(appendname, fdest)
+                            first_append = fdest
+
+        # Get the regex for the first layer in our list (which is where the conf/layer.conf file will
+        # have come from)
+        first_regex = None
+        layerdir = layers[0]
+        for layername, pattern, regex, _ in self.cooker.status.bbfile_config_priorities:
+            if (not layernames) or layername in layernames:
+                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_layer = []
+            for item in bbfiles:
+                if first_regex.match(item):
+                    newpath = os.path.join(outputdir, item[len(layerdir)+1:])
+                    bbfiles_layer.append(newpath)
+
+            if bbfiles_layer:
+                # Check that all important layer files match BBFILES
+                for root, dirs, files in os.walk(outputdir):
+                    for f1 in files:
+                        ext = os.path.splitext(f1)[1]
+                        if ext in ['.bb', '.bbappend']:
+                            f1full = os.sep.join([root, f1])
+                            entry_found = False
+                            for item in bbfiles_layer:
+                                if fnmatch.fnmatch(f1full, item):
+                                    entry_found = True
+                                    break
+                            if not entry_found:
+                                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_append_layer(self, appendname):
         for layer, _, regex, _ in self.cooker.status.bbfile_config_priorities:
@@ -209,6 +307,8 @@ cleanup may still be necessary afterwards, in particular:
         recipefile.write('\n')
         recipefile.write('##### bbappended from %s #####\n' % self.get_append_layer(appendname))
         recipefile.writelines(appendfile.readlines())
+        recipefile.close()
+        appendfile.close()
 
     def do_show_appends(self, args):
         """list bbappend files and recipe files they apply to

bitbake/bin/bitbake-prserv

@@ -10,37 +10,39 @@ import prserv.serv
 
 __version__="1.0.0"
 
-PRHOST_DEFAULT=''
+PRHOST_DEFAULT='0.0.0.0'
 PRPORT_DEFAULT=8585
 
 def main():
     parser = optparse.OptionParser(
         version="Bitbake PR Service Core version %s, %%prog version %s" % (prserv.__version__, __version__),
-        usage = "%prog [options]")
+        usage = "%prog < --start | --stop > [options]")
 
-    parser.add_option("-f", "--file", help="database filename(default prserv.db)", action="store",
-                      dest="dbfile", type="string", default="prserv.db")
-    parser.add_option("-l", "--log", help="log filename(default prserv.log)", action="store",
+    parser.add_option("-f", "--file", help="database filename(default: prserv.sqlite3)", action="store",
+                      dest="dbfile", type="string", default="prserv.sqlite3")
+    parser.add_option("-l", "--log", help="log filename(default: prserv.log)", action="store",
                       dest="logfile", type="string", default="prserv.log")
     parser.add_option("--loglevel", help="logging level, i.e. CRITICAL, ERROR, WARNING, INFO, DEBUG",
-                      action = "store", type="string", dest="loglevel", default = "WARNING")
+                      action = "store", type="string", dest="loglevel", default = "INFO")
     parser.add_option("--start", help="start daemon",
-                      action="store_true", dest="start", default="True")
+                      action="store_true", dest="start")
     parser.add_option("--stop", help="stop daemon",
-                      action="store_false", dest="start")
+                      action="store_true", dest="stop")
     parser.add_option("--host", help="ip address to bind", action="store",
                       dest="host", type="string", default=PRHOST_DEFAULT)
-    parser.add_option("--port", help="port number(default 8585)", action="store",
+    parser.add_option("--port", help="port number(default: 8585)", action="store",
                       dest="port", type="int", default=PRPORT_DEFAULT)
 
     options, args = parser.parse_args(sys.argv)
-
     prserv.init_logger(os.path.abspath(options.logfile),options.loglevel)
 
     if options.start:
-        prserv.serv.start_daemon(options)
+        ret=prserv.serv.start_daemon(options.dbfile, options.host, options.port,os.path.abspath(options.logfile))
+    elif options.stop:
+        ret=prserv.serv.stop_daemon(options.host, options.port)
     else:
-        prserv.serv.stop_daemon()
+        ret=parser.print_help()
+    return ret
 
 if __name__ == "__main__":
     try:

bitbake/bin/bitbake-runtask

@@ -4,6 +4,10 @@ import os
 import sys
 import warnings
 sys.path.insert(0, os.path.join(os.path.dirname(os.path.dirname(sys.argv[0])), 'lib'))
+from bb import fetch2
+import logging
+
+logger = logging.getLogger("BitBake")
 
 try:
     import cPickle as pickle
@@ -16,13 +20,20 @@ class BBConfiguration(object):
     Manages build options and configurations for one run
     """
 
-    def __init__(self, debug, debug_domains):
-        setattr(self, "data", {})
-        setattr(self, "file", [])
-        setattr(self, "cmd", None)
-        setattr(self, "dump_signatures", True)
-        setattr(self, "debug", debug)
-        setattr(self, "debug_domains", debug_domains)
+    def __init__(self, **options):
+        self.data = {}
+        self.file = []
+        self.cmd = None
+        self.dump_signatures = True
+        self.prefile = []
+        self.postfile = []
+        self.parse_only = True
+
+    def __getattr__(self, attribute):
+        try:
+            return super(BBConfiguration, self).__getattribute__(attribute)
+        except AttributeError:
+            return None
 
 _warnings_showwarning = warnings.showwarning
 def _showwarning(message, category, filename, lineno, file=None, line=None):
@@ -39,82 +50,70 @@ warnings.showwarning = _showwarning
 warnings.simplefilter("ignore", DeprecationWarning)
 
 import bb.event
-
-# Need to map our I/O correctly. stdout is a pipe to the server expecting 
-# events. We save this and then map stdout to stderr.
-
-eventfd = os.dup(sys.stdout.fileno())
-bb.event.worker_pipe = os.fdopen(eventfd, 'w', 0)
-
-# map stdout to stderr
-os.dup2(sys.stderr.fileno(), sys.stdout.fileno())
-
-# Replace those fds with our own
-#logout = data.expand("${TMPDIR}/log/stdout.%s" % os.getpid(), self.cfgData, True)
-#mkdirhier(os.path.dirname(logout))
-#newso = open("/tmp/stdout.%s" % os.getpid(), 'w')
-#os.dup2(newso.fileno(), sys.stdout.fileno())
-#os.dup2(newso.fileno(), sys.stderr.fileno())
-
-# Don't read from stdin from the parent
-si = file("/dev/null", 'r')
-os.dup2(si.fileno( ), sys.stdin.fileno( ))
-
-# We don't want to see signals to our parent, e.g. Ctrl+C
-os.setpgrp()
-
-# Save out the PID so that the event can include it the
-# events
-bb.event.worker_pid = os.getpid()
-bb.event.useStdout = False
-
-hashfile = sys.argv[1]
-buildfile = sys.argv[2]
-taskname = sys.argv[3]
-
 import bb.cooker
 
-p = pickle.Unpickler(file(hashfile, "rb"))
-hashdata = p.load()
+buildfile = sys.argv[1]
+taskname = sys.argv[2]
+if len(sys.argv) >= 4:
+    dryrun = sys.argv[3]    
+else:
+    dryrun = False
+if len(sys.argv) >= 5:
+    hashfile = sys.argv[4]
+    p = pickle.Unpickler(file(hashfile, "rb"))
+    hashdata = p.load()
+else:
+    hashdata = None
 
-debug = hashdata["msg-debug"]
-debug_domains = hashdata["msg-debug-domains"]
-verbose = hashdata["verbose"]
+handler = bb.event.LogHandler()
+logger.addHandler(handler)
 
-bb.utils.init_logger(bb.msg, verbose, debug, debug_domains)
+#An example to make debug log messages show up
+#bb.msg.init_msgconfig(True, 3, [])
 
-cooker = bb.cooker.BBCooker(BBConfiguration(debug, debug_domains), None)
-cooker.parseConfiguration()
+console = logging.StreamHandler(sys.stdout)
+format = bb.msg.BBLogFormatter("%(levelname)s: %(message)s")
+bb.msg.addDefaultlogFilter(console)
+console.setFormatter(format)
 
-cooker.bb_cache = bb.cache.init(cooker)
-cooker.status = bb.cache.CacheData()
+def worker_fire(event, d):
+    if isinstance(event, logging.LogRecord):
+        console.handle(event)
+bb.event.worker_fire = worker_fire
+bb.event.worker_pid = os.getpid()
 
-(fn, cls) = cooker.bb_cache.virtualfn2realfn(buildfile)
+initialenv = os.environ.copy()
+config = BBConfiguration()
+
+def register_idle_function(self, function, data):
+    pass
+
+cooker = bb.cooker.BBCooker(config, register_idle_function, initialenv)
+config_data = cooker.configuration.data
+cooker.status = config_data
+cooker.handleCollections(config_data.getVar("BBFILE_COLLECTIONS", 1))
+
+fn, cls = bb.cache.Cache.virtualfn2realfn(buildfile)
 buildfile = cooker.matchFile(fn)
-fn = cooker.bb_cache.realfn2virtual(buildfile, cls)
+fn = bb.cache.Cache.realfn2virtual(buildfile, cls)
 
 cooker.buildSetVars()
 
 # Load data into the cache for fn and parse the loaded cache data
-the_data = cooker.bb_cache.loadDataFull(fn, cooker.get_file_appends(fn), cooker.configuration.data)
-cooker.bb_cache.setData(fn, buildfile, the_data)
-cooker.bb_cache.handle_data(fn, cooker.status)
-
-#exportlist = bb.utils.preserved_envvars_export_list()
-#bb.utils.filter_environment(exportlist)
+the_data = bb.cache.Cache.loadDataFull(fn, cooker.get_file_appends(fn), cooker.configuration.data)
 
 if taskname.endswith("_setscene"):
     the_data.setVarFlag(taskname, "quieterrors", "1")
 
-bb.parse.siggen.set_taskdata(hashdata["hashes"], hashdata["deps"])
-
-for h in hashdata["hashes"]:
-    bb.data.setVar("BBHASH_%s" % h, hashdata["hashes"][h], the_data)
-for h in hashdata["deps"]:
-    bb.data.setVar("BBHASHDEPS_%s" % h, hashdata["deps"][h], the_data)
+if hashdata:
+    bb.parse.siggen.set_taskdata(hashdata["hashes"], hashdata["deps"])
+    for h in hashdata["hashes"]:
+        the_data.setVar("BBHASH_%s" % h, hashdata["hashes"][h])
+    for h in hashdata["deps"]:
+        the_data.setVar("BBHASHDEPS_%s" % h, hashdata["deps"][h])
 
 ret = 0
-if sys.argv[4] != "True":
+if dryrun != "True":
     ret = bb.build.exec_task(fn, taskname, the_data)
 sys.exit(ret)
 

bitbake/bin/bitdoc

@@ -462,7 +462,7 @@ def main():
     state_group = 2
 
     for key in bb.data.keys(documentation):
-        data   = bb.data.getVarFlag(key, "doc", documentation)
+        data   = documentation.getVarFlag(key, "doc")
         if not data:
             continue
 

bitbake/contrib/vim/syntax/bitbake.vim

@@ -52,8 +52,8 @@ syn match bbExport            "^export" nextgroup=bbIdentifier skipwhite
 syn keyword bbExportFlag        export contained nextgroup=bbIdentifier skipwhite
 syn match bbIdentifier          "[a-zA-Z0-9\-_\.\/\+]\+" display contained
 syn match bbVarDeref            "${[a-zA-Z0-9\-_\.\/\+]\+}" contained
-syn match bbVarEq               "\(:=\|+=\|=+\|\.=\|=\.\|?=\|=\)" contained nextgroup=bbVarValue
-syn match bbVarDef              "^\(export\s*\)\?\([a-zA-Z0-9\-_\.\/\+]\+\(_[${}a-zA-Z0-9\-_\.\/\+]\+\)\?\)\s*\(:=\|+=\|=+\|\.=\|=\.\|?=\|=\)\@=" contains=bbExportFlag,bbIdentifier,bbVarDeref nextgroup=bbVarEq
+syn match bbVarEq               "\(:=\|+=\|=+\|\.=\|=\.\|?=\|??=\|=\)" contained nextgroup=bbVarValue
+syn match bbVarDef              "^\(export\s*\)\?\([a-zA-Z0-9\-_\.\/\+]\+\(_[${}a-zA-Z0-9\-_\.\/\+]\+\)\?\)\s*\(:=\|+=\|=+\|\.=\|=\.\|?=\|??=\|=\)\@=" contains=bbExportFlag,bbIdentifier,bbVarDeref nextgroup=bbVarEq
 syn match bbVarValue            ".*$" contained contains=bbString,bbVarDeref,bbVarPyValue
 syn region bbVarPyValue         start=+${@+ skip=+\\$+ excludenl end=+}+ contained contains=@python
 

bitbake/doc/manual/usermanual.xml

@@ -186,7 +186,7 @@ include</literal> directive.</para>
                 <title>Defining Python functions into the global Python namespace</title>
                 <para><emphasis>NOTE:</emphasis> This is only supported in .bb and .bbclass files.</para>
                 <para><screen>def get_depends(bb, d):
-    if bb.data.getVar('SOMECONDITION', d, True):
+    if d.getVar('SOMECONDITION', True):
         return "dependencywithcond"
     else:
         return "dependency"
@@ -388,7 +388,7 @@ ftp://.*/.*      http://somemirror.org/sources/ \n \
 http://.*/.*     http://somemirror.org/sources/ \n \
 https://.*/.*    http://somemirror.org/sources/ \n"</screen></para>
 
-            <para>Non-local downloaded output is placed into the directory specified by the <varname>DL_DIR</varname>. For non local downloads the code can check checksums for the download to ensure the file has been downloaded correctly. These are specified in the form <varname>SRC_URI[md5sum]</varname> for the md5 checksum and <varname>SRC_URI[sha256sum]</varname> for the sha256 checksum. If <varname>BB_STRICT_CHECKSUM</varname> is set, any download without a checksum will trigger an error message. In cases where multiple files are listed in SRC_URI, the name parameter is used assign names to the urls and these are then specified in the checksums in the form SRC_URI[name.sha256sum].</para>
+            <para>Non-local downloaded output is placed into the directory specified by the <varname>DL_DIR</varname>. For non local archive downloads the code can verify sha256 and md5 checksums for the download to ensure the file has been downloaded correctly. These may be specified either in the form <varname>SRC_URI[md5sum]</varname> for the md5 checksum and <varname>SRC_URI[sha256sum]</varname> for the sha256 checksum or as parameters on the SRC_URI such as SRC_URI="http://example.com/foobar.tar.bz2;md5sum=4a8e0f237e961fd7785d19d07fdb994d". If <varname>BB_STRICT_CHECKSUM</varname> is set, any download without a checksum will trigger an error message. In cases where multiple files are listed in SRC_URI, the name parameter is used assign names to the urls and these are then specified in the checksums in the form SRC_URI[name.sha256sum].</para>
 
         </section>
 

bitbake/lib/bb/__init__.py

@@ -21,12 +21,24 @@
 # with this program; if not, write to the Free Software Foundation, Inc.,
 # 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
 
-__version__ = "1.13.3"
+__version__ = "1.15.0"
 
 import sys
 if sys.version_info < (2, 6, 0):
     raise RuntimeError("Sorry, python 2.6.0 or later is required for this version of bitbake")
 
+
+class BBHandledException(Exception):
+    """
+    The big dilemma for generic bitbake code is what information to give the user
+    when an exception occurs. Any exception inheriting this base exception class
+    has already provided information to the user via some 'fired' message type such as
+    an explicitly fired event using bb.fire, or a bb.error message. If bitbake 
+    encounters an exception derived from this class, no backtrace or other information 
+    will be given to the user, its assumed the earlier event provided the relevant information.
+    """
+    pass
+
 import os
 import logging
 
@@ -67,7 +79,7 @@ if "BBDEBUG" in os.environ:
     if level:
         bb.msg.set_debug_level(level)
 
-if True or os.environ.get("BBFETCH2"):
+if os.environ.get("BBFETCH2"):
     from bb import fetch2 as fetch
     sys.modules['bb.fetch'] = sys.modules['bb.fetch2']
 

bitbake/lib/bb/build.py

@@ -70,9 +70,9 @@ class TaskBase(event.Event):
 
     def __init__(self, t, d ):
         self._task = t
-        self._package = bb.data.getVar("PF", d, 1)
+        self._package = d.getVar("PF", 1)
         event.Event.__init__(self)
-        self._message = "package %s: task %s: %s" % (bb.data.getVar("PF", d, 1), t, bb.event.getName(self)[4:])
+        self._message = "package %s: task %s: %s" % (d.getVar("PF", 1), t, bb.event.getName(self)[4:])
 
     def getTask(self):
         return self._task
@@ -149,8 +149,7 @@ def exec_func(func, d, dirs = None):
         adir = dirs[-1]
     else:
         adir = data.getVar('B', d, 1)
-        if not os.path.exists(adir):
-            adir = None
+        bb.utils.mkdirhier(adir)
 
     ispython = flags.get('python')
     if flags.get('fakeroot') and not flags.get('task'):
@@ -223,7 +222,7 @@ def exec_func_shell(function, d, runfile, cwd=None):
 
     with open(runfile, 'w') as script:
         script.write('#!/bin/sh -e\n')
-        if bb.msg.loggerVerbose:
+        if bb.msg.loggerDefaultVerbose:
             script.write("set -x\n")
         data.emit_func(function, script, d)
         if cwd:
@@ -234,7 +233,7 @@ def exec_func_shell(function, d, runfile, cwd=None):
 
     cmd = runfile
 
-    if bb.msg.loggerVerbose:
+    if bb.msg.loggerDefaultVerbose:
         logfile = LogTee(logger, sys.stdout)
     else:
         logfile = sys.stdout

bitbake/lib/bb/cache.py

@@ -31,7 +31,6 @@
 import os
 import logging
 from collections import defaultdict
-import bb.data
 import bb.utils
 
 logger = logging.getLogger("BitBake.Cache")
@@ -143,6 +142,7 @@ class CoreRecipeInfo(RecipeInfoCommon):
         self.section          = self.getvar('SECTION', metadata)
         self.fakerootenv      = self.getvar('FAKEROOTENV', metadata)
         self.fakerootdirs     = self.getvar('FAKEROOTDIRS', metadata)
+        self.fakerootnoenv    = self.getvar('FAKEROOTNOENV', metadata)
 
     @classmethod
     def init_cacheData(cls, cachedata):
@@ -178,6 +178,7 @@ class CoreRecipeInfo(RecipeInfoCommon):
         cachedata.license = {}
         cachedata.section = {}
         cachedata.fakerootenv = {}
+        cachedata.fakerootnoenv = {}
         cachedata.fakerootdirs = {}
 
     def add_cacheData(self, cachedata, fn):
@@ -243,6 +244,7 @@ class CoreRecipeInfo(RecipeInfoCommon):
         cachedata.license[fn] = self.license
         cachedata.section[fn] = self.section
         cachedata.fakerootenv[fn] = self.fakerootenv
+        cachedata.fakerootnoenv[fn] = self.fakerootnoenv
         cachedata.fakerootdirs[fn] = self.fakerootdirs
 
 
@@ -257,7 +259,7 @@ class Cache(object):
         # It will be used in later for deciding whether we 
         # need extra cache file dump/load support 
         self.caches_array = caches_array
-        self.cachedir = bb.data.getVar("CACHE", data, True)
+        self.cachedir = data.getVar("CACHE", True)
         self.clean = set()
         self.checked = set()
         self.depends_cache = {}
@@ -280,7 +282,7 @@ class Cache(object):
         # If any of configuration.data's dependencies are newer than the
         # cache there isn't even any point in loading it...
         newest_mtime = 0
-        deps = bb.data.getVar("__base_depends", data)
+        deps = data.getVar("__base_depends")
 
         old_mtimes = [old_mtime for _, old_mtime in deps]
         old_mtimes.append(newest_mtime)

bitbake/lib/bb/codeparser.py

@@ -36,8 +36,8 @@ pythonparsecache = {}
 shellparsecache = {}
 
 def parser_cachefile(d):
-    cachedir = (bb.data.getVar("PERSISTENT_DIR", d, True) or
-                bb.data.getVar("CACHE", d, True))
+    cachedir = (d.getVar("PERSISTENT_DIR", True) or
+                d.getVar("CACHE", True))
     if cachedir in [None, '']:
         return None
     bb.utils.mkdirhier(cachedir)
@@ -150,117 +150,79 @@ def parser_cache_savemerge(d):
     bb.utils.unlockfile(glf)
 
 
+Logger = logging.getLoggerClass()
+class BufferedLogger(Logger):
+    def __init__(self, name, level=0, target=None):
+        Logger.__init__(self, name)
+        self.setLevel(level)
+        self.buffer = []
+        self.target = target
+
+    def handle(self, record):
+        self.buffer.append(record)
+
+    def flush(self):
+        for record in self.buffer:
+            self.target.handle(record)
+        self.buffer = []
+
 class PythonParser():
-    class ValueVisitor():
-        """Visitor to traverse a python abstract syntax tree and obtain
-        the variables referenced via bitbake metadata APIs, and the external
-        functions called.
+    getvars = ("d.getVar", "bb.data.getVar", "data.getVar")
+    execfuncs = ("bb.build.exec_func", "bb.build.exec_task")
+
+    def warn(self, func, arg):
+        """Warn about calls of bitbake APIs which pass a non-literal
+        argument for the variable name, as we're not able to track such
+        a reference.
         """
 
-        getvars = ("d.getVar", "bb.data.getVar", "data.getVar")
-        expands = ("d.expand", "bb.data.expand", "data.expand")
-        execs = ("bb.build.exec_func", "bb.build.exec_task")
+        try:
+            funcstr = codegen.to_source(func)
+            argstr = codegen.to_source(arg)
+        except TypeError:
+            self.log.debug(2, 'Failed to convert function and argument to source form')
+        else:
+            self.log.debug(1, self.unhandled_message % (funcstr, argstr))
 
-        @classmethod
-        def _compare_name(cls, strparts, node):
-            """Given a sequence of strings representing a python name,
-            where the last component is the actual Name and the prior
-            elements are Attribute nodes, determine if the supplied node
-            matches.
-            """
+    def visit_Call(self, node):
+        name = self.called_node_name(node.func)
+        if name in self.getvars:
+            if isinstance(node.args[0], ast.Str):
+                self.var_references.add(node.args[0].s)
+            else:
+                self.warn(node.func, node.args[0])
+        elif name in self.execfuncs:
+            if isinstance(node.args[0], ast.Str):
+                self.var_execs.add(node.args[0].s)
+            else:
+                self.warn(node.func, node.args[0])
+        elif name and isinstance(node.func, (ast.Name, ast.Attribute)):
+            self.execs.add(name)
 
-            if not strparts:
-                return True
-
-            current, rest = strparts[0], strparts[1:]
+    def called_node_name(self, node):
+        """Given a called node, return its original string form"""
+        components = []
+        while node:
             if isinstance(node, ast.Attribute):
-                if current == node.attr:
-                    return cls._compare_name(rest, node.value)
+                components.append(node.attr)
+                node = node.value
             elif isinstance(node, ast.Name):
-                if current == node.id:
-                    return True
-            return False
-
-        @classmethod
-        def compare_name(cls, value, node):
-            """Convenience function for the _compare_node method, which
-            can accept a string (which is split by '.' for you), or an
-            iterable of strings, in which case it checks to see if any of
-            them match, similar to isinstance.
-            """
-
-            if isinstance(value, basestring):
-                return cls._compare_name(tuple(reversed(value.split("."))),
-                                         node)
+                components.append(node.id)
+                return '.'.join(reversed(components))
             else:
-                return any(cls.compare_name(item, node) for item in value)
+                break
 
-        def __init__(self, value):
-            self.var_references = set()
-            self.var_execs = set()
-            self.direct_func_calls = set()
-            self.var_expands = set()
-            self.value = value
-
-        @classmethod
-        def warn(cls, func, arg):
-            """Warn about calls of bitbake APIs which pass a non-literal
-            argument for the variable name, as we're not able to track such
-            a reference.
-            """
-
-            try:
-                funcstr = codegen.to_source(func)
-                argstr = codegen.to_source(arg)
-            except TypeError:
-                logger.debug(2, 'Failed to convert function and argument to source form')
-            else:
-                logger.debug(1, "Warning: in call to '%s', argument '%s' is "
-                                "not a literal", funcstr, argstr)
-
-        def visit_Call(self, node):
-            if self.compare_name(self.getvars, node.func):
-                if isinstance(node.args[0], ast.Str):
-                    self.var_references.add(node.args[0].s)
-                else:
-                    self.warn(node.func, node.args[0])
-            elif self.compare_name(self.expands, node.func):
-                if isinstance(node.args[0], ast.Str):
-                    self.warn(node.func, node.args[0])
-                    self.var_expands.update(node.args[0].s)
-                elif isinstance(node.args[0], ast.Call) and \
-                     self.compare_name(self.getvars, node.args[0].func):
-                    pass
-                else:
-                    self.warn(node.func, node.args[0])
-            elif self.compare_name(self.execs, node.func):
-                if isinstance(node.args[0], ast.Str):
-                    self.var_execs.add(node.args[0].s)
-                else:
-                    self.warn(node.func, node.args[0])
-            elif isinstance(node.func, ast.Name):
-                self.direct_func_calls.add(node.func.id)
-            elif isinstance(node.func, ast.Attribute):
-                # We must have a qualified name.  Therefore we need
-                # to walk the chain of 'Attribute' nodes to determine
-                # the qualification.
-                attr_node = node.func.value
-                identifier = node.func.attr
-                while isinstance(attr_node, ast.Attribute):
-                    identifier = attr_node.attr + "." + identifier
-                    attr_node = attr_node.value
-                if isinstance(attr_node, ast.Name):
-                    identifier = attr_node.id + "." + identifier
-                self.direct_func_calls.add(identifier)
-
-    def __init__(self):
-        #self.funcdefs = set()
+    def __init__(self, name, log):
+        self.var_references = set()
+        self.var_execs = set()
         self.execs = set()
-        #self.external_cmds = set()
         self.references = set()
+        self.log = BufferedLogger('BitBake.Data.%s' % name, logging.DEBUG, log)
+
+        self.unhandled_message = "in call of %s, argument '%s' is not a string literal"
+        self.unhandled_message = "while parsing %s, %s" % (name, self.unhandled_message)
 
     def parse_python(self, node):
-
         h = hash(str(node))
 
         if h in pythonparsecache:
@@ -271,24 +233,25 @@ class PythonParser():
         code = compile(check_indent(str(node)), "<string>", "exec",
                        ast.PyCF_ONLY_AST)
 
-        visitor = self.ValueVisitor(code)
         for n in ast.walk(code):
             if n.__class__.__name__ == "Call":
-                visitor.visit_Call(n)
+                self.visit_Call(n)
 
-        self.references.update(visitor.var_references)
-        self.references.update(visitor.var_execs)
-        self.execs = visitor.direct_func_calls
+        self.references.update(self.var_references)
+        self.references.update(self.var_execs)
 
         pythonparsecache[h] = {}
         pythonparsecache[h]["refs"] = self.references
         pythonparsecache[h]["execs"] = self.execs
 
 class ShellParser():
-    def __init__(self):
+    def __init__(self, name, log):
         self.funcdefs = set()
         self.allexecs = set()
         self.execs = set()
+        self.log = BufferedLogger('BitBake.Data.%s' % name, logging.DEBUG, log)
+        self.unhandled_template = "unable to handle non-literal command '%s'"
+        self.unhandled_template = "while parsing %s, %s" % (name, self.unhandled_template)
 
     def parse_shell(self, value):
         """Parse the supplied shell code in a string, returning the external
@@ -403,8 +366,7 @@ class ShellParser():
 
                 cmd = word[1]
                 if cmd.startswith("$"):
-                    logger.debug(1, "Warning: execution of non-literal "
-                                    "command '%s'", cmd)
+                    self.log.debug(1, self.unhandled_template % cmd)
                 elif cmd == "eval":
                     command = " ".join(word for _, word in words[1:])
                     self.parse_shell(command)

bitbake/lib/bb/command.py

@@ -30,11 +30,6 @@ Commands are queued in a CommandQueue
 
 import bb.event
 import bb.cooker
-import bb.data
-
-async_cmds = {}
-sync_cmds = {}
-
 
 class CommandCompleted(bb.event.Event):
     pass
@@ -61,16 +56,6 @@ class Command:
         # FIXME Add lock for this
         self.currentAsyncCommand = None
 
-        for attr in CommandsSync.__dict__:
-            command = attr[:].lower()
-            method = getattr(CommandsSync, attr)
-            sync_cmds[command] = (method)
-
-        for attr in CommandsAsync.__dict__:
-            command = attr[:].lower()
-            method = getattr(CommandsAsync, attr)
-            async_cmds[command] = (method)
-
     def runCommand(self, commandline):
         try:
             command = commandline.pop(0)
@@ -113,9 +98,12 @@ class Command:
             else:
                 self.finishAsyncCommand("Exited with %s" % arg)
             return False
-        except Exception:
+        except Exception as exc:
             import traceback
-            self.finishAsyncCommand(traceback.format_exc())
+            if isinstance(exc, bb.BBHandledException):
+                self.finishAsyncCommand("")
+            else:
+                self.finishAsyncCommand(traceback.format_exc())
             return False
 
     def finishAsyncCommand(self, msg=None, code=None):
@@ -162,7 +150,7 @@ class CommandsSync:
         if len(params) > 1:
             expand = params[1]
 
-        return bb.data.getVar(varname, command.cooker.configuration.data, expand)
+        return command.cooker.configuration.data.getVar(varname, expand)
 
     def setVariable(self, command, params):
         """
@@ -170,7 +158,13 @@ class CommandsSync:
         """
         varname = params[0]
         value = params[1]
-        bb.data.setVar(varname, value, command.cooker.configuration.data)
+        command.cooker.configuration.data.setVar(varname, value)
+
+    def initCooker(self, command, params):
+        """
+        Init the cooker to initial state with nothing parsed
+        """
+        command.cooker.initialize()
 
     def resetCooker(self, command, params):
         """
@@ -247,6 +241,17 @@ class CommandsAsync:
         command.finishAsyncCommand()
     generateTargetsTree.needcache = True
 
+    def findCoreBaseFiles(self, command, params):
+        """
+        Find certain files in COREBASE directory. i.e. Layers
+        """
+        subdir = params[0]
+        filename = params[1]
+
+        command.cooker.findCoreBaseFiles(subdir, filename)
+        command.finishAsyncCommand()
+    findCoreBaseFiles.needcache = False
+
     def findConfigFiles(self, command, params):
         """
         Find config files which provide appropriate values
@@ -256,7 +261,7 @@ class CommandsAsync:
 
         command.cooker.findConfigFiles(varname)
         command.finishAsyncCommand()
-    findConfigFiles.needcache = True
+    findConfigFiles.needcache = False
 
     def findFilesMatchingInDir(self, command, params):
         """
@@ -268,7 +273,7 @@ class CommandsAsync:
 
         command.cooker.findFilesMatchingInDir(pattern, directory)
         command.finishAsyncCommand()
-    findFilesMatchingInDir.needcache = True
+    findFilesMatchingInDir.needcache = False
 
     def findConfigFilePath(self, command, params):
         """
@@ -335,3 +340,13 @@ class CommandsAsync:
         else:
             command.finishAsyncCommand()
     compareRevisions.needcache = True
+
+    def parseConfigurationFiles(self, command, params):
+        """
+        Parse the configuration files
+        """
+        prefiles = params[0]
+        postfiles = params[1]
+        command.cooker.parseConfigurationFiles(prefiles, postfiles)
+        command.finishAsyncCommand()
+    parseConfigurationFiles.needcache = False

bitbake/lib/bb/cooker.py

@@ -34,8 +34,9 @@ from cStringIO import StringIO
 from contextlib import closing
 from functools import wraps
 from collections import defaultdict
-import bb, bb.exceptions
-from bb import utils, data, parse, event, cache, providers, taskdata, command, runqueue
+import bb, bb.exceptions, bb.command
+from bb import utils, data, parse, event, cache, providers, taskdata, runqueue
+import prserv.serv
 
 logger      = logging.getLogger("BitBake")
 collectlog  = logging.getLogger("BitBake.Collection")
@@ -135,10 +136,14 @@ class BBCooker:
         self.configuration.data = None
         self.loadConfigurationData()
 
-        if not self.configuration.cmd:
-            self.configuration.cmd = bb.data.getVar("BB_DEFAULT_TASK", self.configuration.data, True) or "build"
+        # Take a lock so only one copy of bitbake can run against a given build
+        # directory at a time
+        lockfile = self.configuration.data.expand("${TOPDIR}/bitbake.lock")
+        self.lock = bb.utils.lockfile(lockfile, False, False)
+        if not self.lock:
+            bb.fatal("Only one copy of bitbake should be run against a build directory")
 
-        bbpkgs = bb.data.getVar('BBPKGS', self.configuration.data, True)
+        bbpkgs = self.configuration.data.getVar('BBPKGS', True)
         if bbpkgs and len(self.configuration.pkgs_to_build) == 0:
             self.configuration.pkgs_to_build.extend(bbpkgs.split())
 
@@ -163,7 +168,7 @@ class BBCooker:
 
         self.parser = None
 
-    def loadConfigurationData(self):
+    def initConfigurationData(self):
         self.configuration.data = bb.data.init()
 
         if not self.server_registration_cb:
@@ -172,6 +177,15 @@ class BBCooker:
         filtered_keys = bb.utils.approved_variables()
         bb.data.inheritFromOS(self.configuration.data, self.savedenv, filtered_keys)
 
+    def loadConfigurationData(self):
+        self.configuration.data = bb.data.init()
+
+        if not self.server_registration_cb:
+            self.configuration.data.setVar("BB_WORKERCONTEXT", "1")
+
+        filtered_keys = bb.utils.approved_variables()
+        bb.data.inheritFromOS(self.configuration.data, self.savedenv, filtered_keys)
+
         try:
             self.parseConfigurationFiles(self.configuration.prefile,
                                          self.configuration.postfile)
@@ -182,13 +196,13 @@ class BBCooker:
             sys.exit(1)
 
         if not self.configuration.cmd:
-            self.configuration.cmd = bb.data.getVar("BB_DEFAULT_TASK", self.configuration.data, True) or "build"
+            self.configuration.cmd = self.configuration.data.getVar("BB_DEFAULT_TASK", True) or "build"
 
     def parseConfiguration(self):
 
 
         # Change nice level if we're asked to
-        nice = bb.data.getVar("BB_NICE_LEVEL", self.configuration.data, True)
+        nice = self.configuration.data.getVar("BB_NICE_LEVEL", True)
         if nice:
             curnice = os.nice(0)
             nice = int(nice) - curnice
@@ -286,9 +300,11 @@ class BBCooker:
             # this showEnvironment() code path doesn't use the cache
             self.parseConfiguration()
             self.status = bb.cache.CacheData(self.caches_array)
-            self.handleCollections( bb.data.getVar("BBFILE_COLLECTIONS", self.configuration.data, 1) )
+            self.handleCollections( self.configuration.data.getVar("BBFILE_COLLECTIONS", 1) )
 
-            fn = self.matchFile(buildfile)
+            fn, cls = bb.cache.Cache.virtualfn2realfn(buildfile)
+            fn = self.matchFile(fn)
+            fn = bb.cache.Cache.realfn2virtual(fn, cls)
         elif len(pkgs_to_build) == 1:
             self.updateCache()
 
@@ -590,7 +606,7 @@ class BBCooker:
         bb.data.expandKeys(localdata)
 
         # Handle PREFERRED_PROVIDERS
-        for p in (bb.data.getVar('PREFERRED_PROVIDERS', localdata, True) or "").split():
+        for p in (localdata.getVar('PREFERRED_PROVIDERS', True) or "").split():
             try:
                 (providee, provider) = p.split(':')
             except:
@@ -626,6 +642,18 @@ class BBCooker:
             if regex in unmatched:
                 collectlog.warn("No bb files matched BBFILE_PATTERN_%s '%s'" % (collection, pattern))
 
+    def findCoreBaseFiles(self, subdir, configfile):
+        corebase = self.configuration.data.getVar('COREBASE', True) or ""
+        paths = []
+        for root, dirs, files in os.walk(corebase + '/' + subdir):
+            for d in dirs:
+                configfilepath = os.path.join(root, d, configfile)
+                if os.path.exists(configfilepath):
+                    paths.append(os.path.join(root, d))
+
+        if paths:
+            bb.event.fire(bb.event.CoreBaseFilesFound(paths), self.configuration.data)
+
     def findConfigFilePath(self, configfile):
         """
         Find the location on disk of configfile and if it exists and was parsed by BitBake
@@ -638,8 +666,8 @@ class BBCooker:
         # Generate a list of parsed configuration files by searching the files
         # listed in the __depends and __base_depends variables with a .conf suffix.
         conffiles = []
-        dep_files = bb.data.getVar('__depends', self.configuration.data) or set()
-        dep_files.union(bb.data.getVar('__base_depends', self.configuration.data) or set())
+        dep_files = self.configuration.data.getVar('__depends') or set()
+        dep_files.union(self.configuration.data.getVar('__base_depends') or set())
 
         for f in dep_files:
             if f[0].endswith(".conf"):
@@ -667,7 +695,7 @@ class BBCooker:
 
         matches = []
         p = re.compile(re.escape(filepattern))
-        bbpaths = bb.data.getVar('BBPATH', self.configuration.data, True).split(':')
+        bbpaths = self.configuration.data.getVar('BBPATH', True).split(':')
         for path in bbpaths:
             dirpath = os.path.join(path, directory)
             if os.path.exists(dirpath):
@@ -689,7 +717,7 @@ class BBCooker:
 
         data = self.configuration.data
         # iterate configs
-        bbpaths = bb.data.getVar('BBPATH', data, True).split(':')
+        bbpaths = data.getVar('BBPATH', True).split(':')
         for path in bbpaths:
             confpath = os.path.join(path, "conf", var)
             if os.path.exists(confpath):
@@ -794,16 +822,16 @@ class BBCooker:
             parselog.debug(2, "Found bblayers.conf (%s)", layerconf)
             data = _parse(layerconf, data)
 
-            layers = (bb.data.getVar('BBLAYERS', data, True) or "").split()
+            layers = (data.getVar('BBLAYERS', True) or "").split()
 
             data = bb.data.createCopy(data)
             for layer in layers:
                 parselog.debug(2, "Adding layer %s", layer)
-                bb.data.setVar('LAYERDIR', layer, data)
+                data.setVar('LAYERDIR', layer)
                 data = _parse(os.path.join(layer, "conf", "layer.conf"), data)
                 data.expandVarref('LAYERDIR')
 
-            bb.data.delVar('LAYERDIR', data)
+            data.delVar('LAYERDIR')
 
         if not data.getVar("BBPATH", True):
             raise SystemExit("The BBPATH variable is not set")
@@ -821,8 +849,8 @@ class BBCooker:
 
         # Nomally we only register event handlers at the end of parsing .bb files
         # We register any handlers we've found so far here...
-        for var in bb.data.getVar('__BBHANDLERS', data) or []:
-            bb.event.register(var, bb.data.getVar(var, data))
+        for var in data.getVar('__BBHANDLERS') or []:
+            bb.event.register(var, data.getVar(var))
 
         if data.getVar("BB_WORKERCONTEXT", False) is None:
             bb.fetch.fetcher_init(data)
@@ -841,7 +869,7 @@ class BBCooker:
             min_prio = 0
             for c in collection_list:
                 # Get collection priority if defined explicitly
-                priority = bb.data.getVar("BBFILE_PRIORITY_%s" % c, self.configuration.data, 1)
+                priority = self.configuration.data.getVar("BBFILE_PRIORITY_%s" % c, 1)
                 if priority:
                     try:
                         prio = int(priority)
@@ -854,7 +882,7 @@ class BBCooker:
                     collection_priorities[c] = None
 
                 # Check dependencies and store information for priority calculation
-                deps = bb.data.getVar("LAYERDEPENDS_%s" % c, self.configuration.data, 1)
+                deps = self.configuration.data.getVar("LAYERDEPENDS_%s" % c, 1)
                 if deps:
                     depnamelist = []
                     deplist = deps.split()
@@ -873,7 +901,7 @@ class BBCooker:
 
                         if dep in collection_list:
                             if depver:
-                                layerver = bb.data.getVar("LAYERVERSION_%s" % dep, self.configuration.data, 1)
+                                layerver = self.configuration.data.getVar("LAYERVERSION_%s" % dep, 1)
                                 if layerver:
                                     try:
                                         lver = int(layerver)
@@ -906,7 +934,7 @@ class BBCooker:
             # Calculate all layer priorities using calc_layer_priority and store in bbfile_config_priorities
             for c in collection_list:
                 calc_layer_priority(c)
-                regex = bb.data.getVar("BBFILE_PATTERN_%s" % c, self.configuration.data, 1)
+                regex = self.configuration.data.getVar("BBFILE_PATTERN_%s" % c, 1)
                 if regex == None:
                     parselog.error("BBFILE_PATTERN_%s not defined" % c)
                     continue
@@ -921,9 +949,9 @@ class BBCooker:
         """
         Setup any variables needed before starting a build
         """
-        if not bb.data.getVar("BUILDNAME", self.configuration.data):
-            bb.data.setVar("BUILDNAME", time.strftime('%Y%m%d%H%M'), self.configuration.data)
-        bb.data.setVar("BUILDSTART", time.strftime('%m/%d/%Y %H:%M:%S', time.gmtime()), self.configuration.data)
+        if not self.configuration.data.getVar("BUILDNAME"):
+            self.configuration.data.setVar("BUILDNAME", time.strftime('%Y%m%d%H%M'))
+        self.configuration.data.setVar("BUILDSTART", time.strftime('%m/%d/%Y %H:%M:%S', time.gmtime()))
 
     def matchFiles(self, bf):
         """
@@ -970,7 +998,7 @@ class BBCooker:
         # buildFile() doesn't use the cache
         self.parseConfiguration()
         self.status = bb.cache.CacheData(self.caches_array)
-        self.handleCollections( bb.data.getVar("BBFILE_COLLECTIONS", self.configuration.data, 1) )
+        self.handleCollections( self.configuration.data.getVar("BBFILE_COLLECTIONS", 1) )
 
         # If we are told to do the None task then query the default task
         if (task == None):
@@ -1014,7 +1042,7 @@ class BBCooker:
         taskdata = bb.taskdata.TaskData(self.configuration.abort)
         taskdata.add_provider(self.configuration.data, self.status, item)
 
-        buildname = bb.data.getVar("BUILDNAME", self.configuration.data)
+        buildname = self.configuration.data.getVar("BUILDNAME")
         bb.event.fire(bb.event.BuildStarted(buildname, [item]), self.configuration.event_data)
 
         # Execute the runqueue
@@ -1082,7 +1110,7 @@ class BBCooker:
                 return False
 
             if not retval:
-                bb.event.fire(bb.event.BuildCompleted(buildname, targets, failures), self.configuration.event_data)
+                bb.event.fire(bb.event.BuildCompleted(buildname, targets, failures), self.configuration.data)
                 self.command.finishAsyncCommand()
                 return False
             if retval is True:
@@ -1091,8 +1119,8 @@ class BBCooker:
 
         self.buildSetVars()
 
-        buildname = bb.data.getVar("BUILDNAME", self.configuration.data)
-        bb.event.fire(bb.event.BuildStarted(buildname, targets), self.configuration.event_data)
+        buildname = self.configuration.data.getVar("BUILDNAME")
+        bb.event.fire(bb.event.BuildStarted(buildname, targets), self.configuration.data)
 
         localdata = data.createCopy(self.configuration.data)
         bb.data.update_data(localdata)
@@ -1125,16 +1153,16 @@ class BBCooker:
                 del self.status
             self.status = bb.cache.CacheData(self.caches_array)
 
-            ignore = bb.data.getVar("ASSUME_PROVIDED", self.configuration.data, 1) or ""
+            ignore = self.configuration.data.getVar("ASSUME_PROVIDED", 1) or ""
             self.status.ignored_dependencies = set(ignore.split())
 
             for dep in self.configuration.extra_assume_provided:
                 self.status.ignored_dependencies.add(dep)
 
-            self.handleCollections( bb.data.getVar("BBFILE_COLLECTIONS", self.configuration.data, 1) )
+            self.handleCollections( self.configuration.data.getVar("BBFILE_COLLECTIONS", 1) )
 
             (filelist, masked) = self.collect_bbfiles()
-            bb.data.renameVar("__depends", "__base_depends", self.configuration.data)
+            self.configuration.data.renameVar("__depends", "__base_depends")
 
             self.parser = CookerParser(self, filelist, masked)
             self.state = state.parsing
@@ -1225,7 +1253,7 @@ class BBCooker:
                     if g not in newfiles:
                         newfiles.append(g)
 
-        bbmask = bb.data.getVar('BBMASK', self.configuration.data, 1)
+        bbmask = self.configuration.data.getVar('BBMASK', 1)
 
         if bbmask:
             try:
@@ -1284,9 +1312,11 @@ class BBCooker:
         # Empty the environment. The environment will be populated as
         # necessary from the data store.
         #bb.utils.empty_environment()
+        prserv.serv.auto_start(self.configuration.data)
         return
 
     def post_serve(self):
+        prserv.serv.auto_shutdown(self.configuration.data)
         bb.event.fire(CookerExit(), self.configuration.event_data)
 
     def shutdown(self):
@@ -1298,6 +1328,10 @@ class BBCooker:
     def reparseFiles(self):
         return
 
+    def initialize(self):
+        self.state = state.initial
+        self.initConfigurationData()
+
     def reset(self):
         self.state = state.initial
         self.loadConfigurationData()

bitbake/lib/bb/data.py

@@ -49,6 +49,7 @@ from bb import data_smart
 from bb import codeparser
 import bb
 
+logger = data_smart.logger
 _dict_type = data_smart.DataSmart
 
 def init():
@@ -258,48 +259,54 @@ def emit_func(func, o=sys.__stdout__, d = init()):
         emit_var(key, o, d, False) and o.write('\n')
 
     emit_var(func, o, d, False) and o.write('\n')
-    newdeps = bb.codeparser.ShellParser().parse_shell(d.getVar(func, True))
+    newdeps = bb.codeparser.ShellParser(func, logger).parse_shell(d.getVar(func, True))
     seen = set()
     while newdeps:
         deps = newdeps
         seen |= deps
         newdeps = set()
         for dep in deps:
-            if bb.data.getVarFlag(dep, "func", d):
+            if d.getVarFlag(dep, "func"):
                emit_var(dep, o, d, False) and o.write('\n')
-               newdeps |=  bb.codeparser.ShellParser().parse_shell(d.getVar(dep, True))
+               newdeps |=  bb.codeparser.ShellParser(dep, logger).parse_shell(d.getVar(dep, True))
         newdeps -= seen
 
 def update_data(d):
     """Performs final steps upon the datastore, including application of overrides"""
     d.finalize()
 
-def build_dependencies(key, keys, shelldeps, d):
+def build_dependencies(key, keys, shelldeps, vardepvals, d):
     deps = set()
+    vardeps = d.getVarFlag(key, "vardeps", True)
     try:
-        if d.getVarFlag(key, "func"):
+        value = d.getVar(key, False)
+        if key in vardepvals:
+           value =  d.getVarFlag(key, "vardepvalue", True)
+        elif d.getVarFlag(key, "func"):
             if d.getVarFlag(key, "python"):
-                parsedvar = d.expandWithRefs(d.getVar(key, False), key)
-                parser = bb.codeparser.PythonParser()
+                parsedvar = d.expandWithRefs(value, key)
+                parser = bb.codeparser.PythonParser(key, logger)
                 parser.parse_python(parsedvar.value)
                 deps = deps | parser.references
             else:
-                parsedvar = d.expandWithRefs(d.getVar(key, False), key)
-                parser = bb.codeparser.ShellParser()
+                parsedvar = d.expandWithRefs(value, key)
+                parser = bb.codeparser.ShellParser(key, logger)
                 parser.parse_shell(parsedvar.value)
                 deps = deps | shelldeps
+            if vardeps is None:
+                parser.log.flush()
             deps = deps | parsedvar.references
             deps = deps | (keys & parser.execs) | (keys & parsedvar.execs)
         else:
-            parser = d.expandWithRefs(d.getVar(key, False), key)
+            parser = d.expandWithRefs(value, key)
             deps |= parser.references
             deps = deps | (keys & parser.execs)
-        deps |= set((d.getVarFlag(key, "vardeps", True) or "").split())
+        deps |= set((vardeps or "").split())
         deps -= set((d.getVarFlag(key, "vardepsexclude", True) or "").split())
     except:
         bb.note("Error expanding variable %s" % key)
         raise
-    return deps
+    return deps, value
     #bb.note("Variable %s references %s and calls %s" % (key, str(deps), str(execs)))
     #d.setVarFlag(key, "vardeps", deps)
 
@@ -307,12 +314,14 @@ def generate_dependencies(d):
 
     keys = set(key for key in d.keys() if not key.startswith("__"))
     shelldeps = set(key for key in keys if d.getVarFlag(key, "export") and not d.getVarFlag(key, "unexport"))
+    vardepvals = set(key for key in keys if d.getVarFlag(key, "vardepvalue"))
 
     deps = {}
+    values = {}
 
-    tasklist = bb.data.getVar('__BBTASKS', d) or []
+    tasklist = d.getVar('__BBTASKS') or []
     for task in tasklist:
-        deps[task] = build_dependencies(task, keys, shelldeps, d)
+        deps[task], values[task] = build_dependencies(task, keys, shelldeps, vardepvals, d)
         newdeps = deps[task]
         seen = set()
         while newdeps:
@@ -321,11 +330,11 @@ def generate_dependencies(d):
             newdeps = set()
             for dep in nextdeps:
                 if dep not in deps:
-                    deps[dep] = build_dependencies(dep, keys, shelldeps, d)
+                    deps[dep], values[dep] = build_dependencies(dep, keys, shelldeps, vardepvals, d)
                 newdeps |=  deps[dep]
             newdeps -= seen
         #print "For %s: %s" % (task, str(taskdeps[task]))
-    return tasklist, deps
+    return tasklist, deps, values
 
 def inherits_class(klass, d):
     val = getVar('__inherit_cache', d) or []

bitbake/lib/bb/data_smart.py

@@ -68,8 +68,14 @@ class VariableParse:
             code = match.group()[3:-1]
             codeobj = compile(code.strip(), self.varname or "<expansion>", "eval")
 
-            parser = bb.codeparser.PythonParser()
+            parser = bb.codeparser.PythonParser(self.varname, logger)
             parser.parse_python(code)
+            if self.varname:
+                vardeps = self.d.getVarFlag(self.varname, "vardeps", True)
+                if vardeps is None:
+                    parser.log.flush()
+            else:
+                parser.log.flush()
             self.references |= parser.references
             self.execs |= parser.execs
 
@@ -140,7 +146,7 @@ class DataSmart(MutableMapping):
 
         return varparse
 
-    def expand(self, s, varname):
+    def expand(self, s, varname = None):
         return self.expandWithRefs(s, varname).value
 
 
@@ -298,6 +304,14 @@ class DataSmart(MutableMapping):
 
         self.delVar(key)
 
+    def appendVar(self, key, value):
+        value = (self.getVar(key, False) or "") + value
+        self.setVar(key, value)
+
+    def prependVar(self, key, value):
+        value = value + (self.getVar(key, False) or "")
+        self.setVar(key, value)
+
     def delVar(self, var):
         self.expand_cache = {}
         self.dict[var] = {}
@@ -333,6 +347,14 @@ class DataSmart(MutableMapping):
         if var in self.dict and flag in self.dict[var]:
             del self.dict[var][flag]
 
+    def appendVarFlag(self, key, flag, value):
+        value = (self.getVarFlag(key, flag, False) or "") + value
+        self.setVarFlag(key, flag, value)
+
+    def prependVarFlag(self, key, flag, value):
+        value = value + (self.getVarFlag(key, flag, False) or "")
+        self.setVarFlag(key, flag, value)
+
     def setVarFlags(self, var, flags):
         if not var in self.dict:
             self._makeShadowCopy(var)

bitbake/lib/bb/event.py

@@ -402,6 +402,14 @@ class FilesMatchingFound(Event):
         self._pattern = pattern
         self._matches = matches
 
+class CoreBaseFilesFound(Event):
+    """
+    Event when a list of appropriate config files has been generated
+    """
+    def __init__(self, paths):
+        Event.__init__(self)
+        self._paths = paths
+
 class ConfigFilesFound(Event):
     """
     Event when a list of appropriate config files has been generated

bitbake/lib/bb/fetch/__init__.py

@@ -154,7 +154,7 @@ def fetcher_init(d):
     Calls before this must not hit the cache.
     """
     # When to drop SCM head revisions controlled by user policy
-    srcrev_policy = bb.data.getVar('BB_SRCREV_POLICY', d, 1) or "clear"
+    srcrev_policy = d.getVar('BB_SRCREV_POLICY', 1) or "clear"
     if srcrev_policy == "cache":
         logger.debug(1, "Keeping SRCREV cache due to cache policy of: %s", srcrev_policy)
     elif srcrev_policy == "clear":
@@ -200,7 +200,7 @@ def fetcher_compare_revisions(d):
 def init(urls, d, setup = True):
     urldata = {}
 
-    fn = bb.data.getVar('FILE', d, 1)
+    fn = d.getVar('FILE', 1)
     if fn in urldata_cache:
         urldata = urldata_cache[fn]
 
@@ -243,7 +243,7 @@ def verify_checksum(u, ud, d):
                     'SRC_URI[%s] = "%s"\nSRC_URI[%s] = "%s"',
                     ud.localpath, ud.md5_name, md5data,
                     ud.sha256_name, sha256data)
-        if bb.data.getVar("BB_STRICT_CHECKSUM", d, True) == "1":
+        if d.getVar("BB_STRICT_CHECKSUM", True) == "1":
             raise FetchError("No checksum specified for %s." % u)
         return
 
@@ -276,7 +276,7 @@ def go(d, urls = None):
 
         if m.try_premirror(u, ud, d):
             # First try fetching uri, u, from PREMIRRORS
-            mirrors = mirror_from_string(bb.data.getVar('PREMIRRORS', d, True))
+            mirrors = mirror_from_string(d.getVar('PREMIRRORS', True))
             localpath = try_mirrors(d, u, mirrors, False, m.forcefetch(u, ud, d))
         elif os.path.exists(ud.localfile):
             localpath = ud.localfile
@@ -291,7 +291,7 @@ def go(d, urls = None):
                 # Remove any incomplete file
                 bb.utils.remove(ud.localpath)
                 # Finally, try fetching uri, u, from MIRRORS
-                mirrors = mirror_from_string(bb.data.getVar('MIRRORS', d, True))
+                mirrors = mirror_from_string(d.getVar('MIRRORS', True))
                 localpath = try_mirrors (d, u, mirrors)
                 if not localpath or not os.path.exists(localpath):
                     raise FetchError("Unable to fetch URL %s from any source." % u)
@@ -327,7 +327,7 @@ def checkstatus(d, urls = None):
         m = ud.method
         logger.debug(1, "Testing URL %s", u)
         # First try checking uri, u, from PREMIRRORS
-        mirrors = mirror_from_string(bb.data.getVar('PREMIRRORS', d, True))
+        mirrors = mirror_from_string(d.getVar('PREMIRRORS', True))
         ret = try_mirrors(d, u, mirrors, True)
         if not ret:
             # Next try checking from the original uri, u
@@ -335,7 +335,7 @@ def checkstatus(d, urls = None):
                 ret = m.checkstatus(u, ud, d)
             except:
                 # Finally, try checking uri, u, from MIRRORS
-                mirrors = mirror_from_string(bb.data.getVar('MIRRORS', d, True))
+                mirrors = mirror_from_string(d.getVar('MIRRORS', True))
                 ret = try_mirrors (d, u, mirrors, True)
 
         if not ret:
@@ -383,7 +383,7 @@ def get_srcrev(d):
     scms = []
 
     # Only call setup_localpath on URIs which supports_srcrev()
-    urldata = init(bb.data.getVar('SRC_URI', d, 1).split(), d, False)
+    urldata = init(d.getVar('SRC_URI', 1).split(), d, False)
     for u in urldata:
         ud = urldata[u]
         if ud.method.supports_srcrev():
@@ -395,8 +395,8 @@ def get_srcrev(d):
         logger.error("SRCREV was used yet no valid SCM was found in SRC_URI")
         raise ParameterError
 
-    if bb.data.getVar('BB_SRCREV_POLICY', d, True) != "cache":
-        bb.data.setVar('__BB_DONT_CACHE', '1', d)
+    if d.getVar('BB_SRCREV_POLICY', True) != "cache":
+        d.setVar('__BB_DONT_CACHE', '1')
 
     if len(scms) == 1:
         return urldata[scms[0]].method.sortable_revision(scms[0], urldata[scms[0]], d)
@@ -404,7 +404,7 @@ def get_srcrev(d):
     #
     # Mutiple SCMs are in SRC_URI so we resort to SRCREV_FORMAT
     #
-    format = bb.data.getVar('SRCREV_FORMAT', d, 1)
+    format = d.getVar('SRCREV_FORMAT', 1)
     if not format:
         logger.error("The SRCREV_FORMAT variable must be set when multiple SCMs are used.")
         raise ParameterError
@@ -539,8 +539,8 @@ class FetchData(object):
         else:
             self.md5_name = "md5sum"
             self.sha256_name = "sha256sum"
-        self.md5_expected = bb.data.getVarFlag("SRC_URI", self.md5_name, d)
-        self.sha256_expected = bb.data.getVarFlag("SRC_URI", self.sha256_name, d)
+        self.md5_expected = d.getVarFlag("SRC_URI", self.md5_name)
+        self.sha256_expected = d.getVarFlag("SRC_URI", self.sha256_name)
 
         for m in methods:
             if m.supports(url, self, d):
@@ -555,7 +555,7 @@ class FetchData(object):
             self.localpath = self.parm["localpath"]
             self.basename = os.path.basename(self.localpath)
         else:
-            premirrors = bb.data.getVar('PREMIRRORS', d, True)
+            premirrors = d.getVar('PREMIRRORS', True)
             local = ""
             if premirrors and self.url:
                 aurl = self.url.split(";")[0]
@@ -775,7 +775,7 @@ class Fetch(object):
 
         latest_rev = self._build_revision(url, ud, d)
         last_rev = localcounts.get(key + '_rev')
-        uselocalcount = bb.data.getVar("BB_LOCALCOUNT_OVERRIDE", d, True) or False
+        uselocalcount = d.getVar("BB_LOCALCOUNT_OVERRIDE", True) or False
         count = None
         if uselocalcount:
             count = Fetch.localcount_internal_helper(ud, d)
@@ -803,7 +803,7 @@ class Fetch(object):
 
     def generate_revision_key(self, url, ud, d):
         key = self._revision_key(url, ud, d)
-        return "%s-%s" % (key, bb.data.getVar("PN", d, True) or "")
+        return "%s-%s" % (key, d.getVar("PN", True) or "")
 
 from . import cvs
 from . import git

bitbake/lib/bb/fetch/git.py

@@ -34,7 +34,7 @@ class Git(Fetch):
         #
         # Only enable _sortable revision if the key is set
         #
-        if bb.data.getVar("BB_GIT_CLONE_FOR_SRCREV", d, True):
+        if d.getVar("BB_GIT_CLONE_FOR_SRCREV", True):
             self._sortable_buildindex = self._sortable_buildindex_disabled
     def supports(self, url, ud, d):
         """
@@ -220,7 +220,7 @@ class Git(Fetch):
 
     def generate_revision_key(self, url, ud, d, branch=False):
         key = self._revision_key(url, ud, d, branch)
-        return "%s-%s" % (key, bb.data.getVar("PN", d, True) or "")
+        return "%s-%s" % (key, d.getVar("PN", True) or "")
 
     def _latest_revision(self, url, ud, d):
         """
@@ -276,7 +276,7 @@ class Git(Fetch):
                 del localcounts[oldkey + '_rev']
                 localcounts[key + '_rev'] = last_rev
 
-        uselocalcount = bb.data.getVar("BB_LOCALCOUNT_OVERRIDE", d, True) or False
+        uselocalcount = d.getVar("BB_LOCALCOUNT_OVERRIDE", True) or False
         count = None
         if uselocalcount:
             count = Fetch.localcount_internal_helper(ud, d)

bitbake/lib/bb/fetch2/__init__.py

@@ -28,7 +28,7 @@ from __future__ import absolute_import
 from __future__ import print_function
 import os, re
 import logging
-import bb.data, bb.persist_data, bb.utils
+import bb.persist_data, bb.utils
 from bb import data
 
 __version__ = "2"
@@ -93,28 +93,6 @@ class ParameterError(BBFetchException):
          BBFetchException.__init__(self, msg)
          self.args = (message, url)
 
-class MD5SumError(BBFetchException):
-    """Exception raised when a MD5 checksum of a file does not match for a downloaded file"""
-    def __init__(self, path, wanted, got, url):
-         msg = "File: '%s' has md5 checksum %s when %s was expected (from URL: '%s')" % (path, got, wanted, url)
-         self.url = url
-         self.path = path
-         self.wanted = wanted
-         self.got = got
-         BBFetchException.__init__(self, msg)
-         self.args = (path, wanted, got, url)
-
-class SHA256SumError(MD5SumError):
-    """Exception raised when a SHA256 checksum of a file does not match for a downloaded file"""
-    def __init__(self, path, wanted, got, url):
-         msg = "File: '%s' has sha256 checksum %s when %s was expected (from URL: '%s')" % (path, got, wanted, url)
-         self.url = url
-         self.path = path
-         self.wanted = wanted
-         self.got = got
-         BBFetchException.__init__(self, msg)
-         self.args = (path, wanted, got, url)
-
 class NetworkAccess(BBFetchException):
     """Exception raised when network access is disabled but it is required."""
     def __init__(self, url, cmd):
@@ -197,6 +175,7 @@ def uri_replace(ud, uri_find, uri_replace, d):
     uri_decoded = list(decodeurl(ud.url))
     uri_find_decoded = list(decodeurl(uri_find))
     uri_replace_decoded = list(decodeurl(uri_replace))
+    logger.debug(2, "For url %s comparing %s to %s" % (uri_decoded, uri_find_decoded, uri_replace_decoded))
     result_decoded = ['', '', '', '', '', {}]
     for i in uri_find_decoded:
         loc = uri_find_decoded.index(i)
@@ -209,12 +188,18 @@ def uri_replace(ud, uri_find, uri_replace, d):
                     result_decoded[loc] = re.sub(i, uri_replace_decoded[loc], uri_decoded[loc])
                 if uri_find_decoded.index(i) == 2:
                     if ud.mirrortarball:
-                        result_decoded[loc] = os.path.join(os.path.dirname(result_decoded[loc]), os.path.basename(ud.mirrortarball))
+                        if result_decoded[loc].endswith("/"):
+                            result_decoded[loc] = os.path.dirname(result_decoded[loc])
+                        result_decoded[loc] = os.path.join(result_decoded[loc], os.path.basename(ud.mirrortarball))
                     elif ud.localpath:
-                        result_decoded[loc] = os.path.join(os.path.dirname(result_decoded[loc]), os.path.basename(ud.localpath))
+                        if result_decoded[loc].endswith("/"):
+                            result_decoded[loc] = os.path.dirname(result_decoded[loc])
+                        result_decoded[loc] = os.path.join(result_decoded[loc], os.path.basename(ud.localpath))
             else:
                 return ud.url
-    return encodeurl(result_decoded)
+    result = encodeurl(result_decoded)
+    logger.debug(2, "For url %s returning %s" % (ud.url, result))
+    return result
 
 methods = []
 urldata_cache = {}
@@ -226,7 +211,7 @@ def fetcher_init(d):
     Calls before this must not hit the cache.
     """
     # When to drop SCM head revisions controlled by user policy
-    srcrev_policy = bb.data.getVar('BB_SRCREV_POLICY', d, True) or "clear"
+    srcrev_policy = d.getVar('BB_SRCREV_POLICY', True) or "clear"
     if srcrev_policy == "cache":
         logger.debug(1, "Keeping SRCREV cache due to cache policy of: %s", srcrev_policy)
     elif srcrev_policy == "clear":
@@ -271,8 +256,8 @@ def verify_checksum(u, ud, d):
     verify the MD5 and SHA256 checksum for downloaded src
 
     return value:
-        - True: checksum matched
-        - False: checksum unmatched
+        - True: a checksum matched
+        - False: neither checksum matched
 
     if checksum is missing in recipes file, "BB_STRICT_CHECKSUM" decide the return value.
     if BB_STRICT_CHECKSUM = "1" then return false as unmatched, otherwise return true as
@@ -285,20 +270,46 @@ def verify_checksum(u, ud, d):
     md5data = bb.utils.md5_file(ud.localpath)
     sha256data = bb.utils.sha256_file(ud.localpath)
 
-    if (ud.md5_expected == None or ud.sha256_expected == None):
-        logger.warn('Missing SRC_URI checksum for %s, consider adding to the recipe:\n'
-                    'SRC_URI[%s] = "%s"\nSRC_URI[%s] = "%s"',
-                    ud.localpath, ud.md5_name, md5data,
-                    ud.sha256_name, sha256data)
-        if bb.data.getVar("BB_STRICT_CHECKSUM", d, True) == "1":
-            raise FetchError("No checksum specified for %s." % u, u)
-        return
+    # If strict checking enabled and neither sum defined, raise error
+    strict = d.getVar("BB_STRICT_CHECKSUM", True) or None
+    if (strict and ud.md5_expected == None and ud.sha256_expected == None):
+        raise FetchError('No checksum specified for %s, please add at least one to the recipe:\n'
+                         'SRC_URI[%s] = "%s"\nSRC_URI[%s] = "%s"' %
+                         (ud.localpath, ud.md5_name, md5data,
+                         ud.sha256_name, sha256data), u)
+
+    # Log missing sums so user can more easily add them
+    if ud.md5_expected == None:
+        logger.warn('Missing md5 SRC_URI checksum for %s, consider adding to the recipe:\n'
+                    'SRC_URI[%s] = "%s"',
+                    ud.localpath, ud.md5_name, md5data)
+
+    if ud.sha256_expected == None:
+        logger.warn('Missing sha256 SRC_URI checksum for %s, consider adding to the recipe:\n'
+                    'SRC_URI[%s] = "%s"',
+                    ud.localpath, ud.sha256_name, sha256data)
+
+    md5mismatch = False
+    sha256mismatch = False
 
     if ud.md5_expected != md5data:
-        raise MD5SumError(ud.localpath, ud.md5_expected, md5data, u)
+        md5mismatch = True
 
     if ud.sha256_expected != sha256data:
-        raise SHA256SumError(ud.localpath, ud.sha256_expected, sha256data, u)
+        sha256mismatch = True
+
+    # We want to alert the user if a checksum is defined in the recipe but
+    # it does not match.
+    msg = ""
+    if md5mismatch and ud.md5_expected:
+        msg = msg + "\nFile: '%s' has %s checksum %s when %s was expected (from URL: '%s')" % (ud.localpath, 'md5', md5data, ud.md5_expected, u)
+
+    if sha256mismatch and ud.sha256_expected:
+        msg = msg + "\nFile: '%s' has %s checksum %s when %s was expected (from URL: '%s')" % (ud.localpath, 'sha256', sha256data, ud.sha256_expected, u)
+
+    if len(msg):
+        raise FetchError('Checksum mismatch!%s' % msg, u)
+
 
 def update_stamp(u, ud, d):
     """
@@ -325,8 +336,8 @@ def subprocess_setup():
 
 def get_autorev(d):
     #  only not cache src rev in autorev case
-    if bb.data.getVar('BB_SRCREV_POLICY', d, True) != "cache":
-        bb.data.setVar('__BB_DONT_CACHE', '1', d)
+    if d.getVar('BB_SRCREV_POLICY', True) != "cache":
+        d.setVar('__BB_DONT_CACHE', '1')
     return "AUTOINC"
 
 def get_srcrev(d):
@@ -339,7 +350,7 @@ def get_srcrev(d):
     """
 
     scms = []
-    fetcher = Fetch(bb.data.getVar('SRC_URI', d, True).split(), d)
+    fetcher = Fetch(d.getVar('SRC_URI', True).split(), d)
     urldata = fetcher.ud
     for u in urldata:
         if urldata[u].method.supports_srcrev():
@@ -354,7 +365,7 @@ def get_srcrev(d):
     #
     # Mutiple SCMs are in SRC_URI so we resort to SRCREV_FORMAT
     #
-    format = bb.data.getVar('SRCREV_FORMAT', d, True)
+    format = d.getVar('SRCREV_FORMAT', True)
     if not format:
         raise FetchError("The SRCREV_FORMAT variable must be set when multiple SCMs are used.")
 
@@ -385,10 +396,11 @@ def runfetchcmd(cmd, d, quiet = False, cleanup = []):
     exportvars = ['PATH', 'GIT_PROXY_COMMAND', 'GIT_PROXY_HOST',
                   'GIT_PROXY_PORT', 'GIT_CONFIG', 'http_proxy', 'ftp_proxy',
                   'https_proxy', 'no_proxy', 'ALL_PROXY', 'all_proxy',
-                  'SSH_AUTH_SOCK', 'SSH_AGENT_PID', 'HOME']
+                  'SSH_AUTH_SOCK', 'SSH_AGENT_PID', 'HOME',
+                  'GIT_PROXY_IGNORE', 'SOCKS5_USER', 'SOCKS5_PASSWD']
 
     for var in exportvars:
-        val = bb.data.getVar(var, d, True)
+        val = d.getVar(var, True)
         if val:
             cmd = 'export ' + var + '=\"%s\"; %s' % (val, cmd)
 
@@ -428,7 +440,7 @@ def check_network_access(d, info = "", url = None):
     """
     log remote network access, and error if BB_NO_NETWORK is set
     """
-    if bb.data.getVar("BB_NO_NETWORK", d, True) == "1":
+    if d.getVar("BB_NO_NETWORK", True) == "1":
         raise NetworkAccess(url, info)
     else:
         logger.debug(1, "Fetcher accessed the network with the command %s" % info)
@@ -514,15 +526,15 @@ def srcrev_internal_helper(ud, d, name):
         return ud.parm['tag']
 
     rev = None
-    pn = bb.data.getVar("PN", d, True)
+    pn = d.getVar("PN", True)
     if name != '':
-        rev = bb.data.getVar("SRCREV_%s_pn-%s" % (name, pn), d, True)
+        rev = d.getVar("SRCREV_%s_pn-%s" % (name, pn), True)
         if not rev:
-            rev = bb.data.getVar("SRCREV_%s" % name, d, True)
+            rev = d.getVar("SRCREV_%s" % name, True)
     if not rev:
-       rev = bb.data.getVar("SRCREV_pn-%s" % pn, d, True)
+       rev = d.getVar("SRCREV_pn-%s" % pn, True)
     if not rev:
-        rev = bb.data.getVar("SRCREV", d, True)
+        rev = d.getVar("SRCREV", True)
     if rev == "INVALID":
         raise FetchError("Please set SRCREV to a valid value", ud.url)
     if rev == "AUTOINC":
@@ -557,8 +569,14 @@ class FetchData(object):
         else:
             self.md5_name = "md5sum"
             self.sha256_name = "sha256sum"
-        self.md5_expected = bb.data.getVarFlag("SRC_URI", self.md5_name, d)
-        self.sha256_expected = bb.data.getVarFlag("SRC_URI", self.sha256_name, d)
+        if self.md5_name in self.parm:
+            self.md5_expected = self.parm[self.md5_name]
+        else:
+            self.md5_expected = d.getVarFlag("SRC_URI", self.md5_name)
+        if self.sha256_name in self.parm:
+            self.sha256_expected = self.parm[self.sha256_name]
+        else:
+            self.sha256_expected = d.getVarFlag("SRC_URI", self.sha256_name)
 
         self.names = self.parm.get("name",'default').split(',')
 
@@ -582,7 +600,7 @@ class FetchData(object):
             self.localpath = self.method.localpath(self.url, self, d)
 
         # Note: These files should always be in DL_DIR whereas localpath may not be.
-        basepath = bb.data.expand("${DL_DIR}/%s" % os.path.basename(self.localpath or self.basename), d)
+        basepath = d.expand("${DL_DIR}/%s" % os.path.basename(self.localpath or self.basename))
         self.donestamp = basepath + '.done'
         self.lockfile = basepath + '.lock'
 
@@ -608,12 +626,12 @@ class FetchData(object):
         if "srcdate" in self.parm:
             return self.parm['srcdate']
 
-        pn = bb.data.getVar("PN", d, True)
+        pn = d.getVar("PN", True)
 
         if pn:
-            return bb.data.getVar("SRCDATE_%s" % pn, d, True) or bb.data.getVar("SRCDATE", d, True) or bb.data.getVar("DATE", d, True)
+            return d.getVar("SRCDATE_%s" % pn, True) or d.getVar("SRCDATE", True) or d.getVar("DATE", True)
 
-        return bb.data.getVar("SRCDATE", d, True) or bb.data.getVar("DATE", d, True)
+        return d.getVar("SRCDATE", True) or d.getVar("DATE", True)
 
 class FetchMethod(object):
     """Base class for 'fetch'ing data"""
@@ -685,7 +703,7 @@ class FetchMethod(object):
 
         dots = file.split(".")
         if dots[-1] in ['gz', 'bz2', 'Z']:
-            efile = os.path.join(bb.data.getVar('WORKDIR', data, True),os.path.basename('.'.join(dots[0:-1])))
+            efile = os.path.join(data.getVar('WORKDIR', True),os.path.basename('.'.join(dots[0:-1])))
         else:
             efile = file
         cmd = None
@@ -729,7 +747,7 @@ class FetchMethod(object):
             dest = os.path.join(rootdir, os.path.basename(file))
             if (file != dest) and not (os.path.exists(dest) and os.path.samefile(file, dest)):
                 if os.path.isdir(file):
-                    filesdir = os.path.realpath(bb.data.getVar("FILESDIR", data, True))
+                    filesdir = os.path.realpath(data.getVar("FILESDIR", True))
                     destdir = "."
                     if file[0:len(filesdir)] == filesdir:
                         destdir = file[len(filesdir):file.rfind('/')]
@@ -761,7 +779,7 @@ class FetchMethod(object):
             bb.utils.mkdirhier(newdir)
             os.chdir(newdir)
 
-        cmd = "PATH=\"%s\" %s" % (bb.data.getVar('PATH', data, True), cmd)
+        cmd = "PATH=\"%s\" %s" % (data.getVar('PATH', True), cmd)
         bb.note("Unpacking %s to %s/" % (file, os.getcwd()))
         ret = subprocess.call(cmd, preexec_fn=subprocess_setup, shell=True)
 
@@ -806,10 +824,10 @@ class FetchMethod(object):
 
         localcount = None
         if name != '':
-            pn = bb.data.getVar("PN", d, True)
-            localcount = bb.data.getVar("LOCALCOUNT_" + name, d, True)
+            pn = d.getVar("PN", True)
+            localcount = d.getVar("LOCALCOUNT_" + name, True)
         if not localcount:
-            localcount = bb.data.getVar("LOCALCOUNT", d, True)
+            localcount = d.getVar("LOCALCOUNT", True)
         return localcount
 
     localcount_internal_helper = staticmethod(localcount_internal_helper)
@@ -841,7 +859,7 @@ class FetchMethod(object):
 
         latest_rev = self._build_revision(url, ud, d, name)
         last_rev = localcounts.get(key + '_rev')
-        uselocalcount = bb.data.getVar("BB_LOCALCOUNT_OVERRIDE", d, True) or False
+        uselocalcount = d.getVar("BB_LOCALCOUNT_OVERRIDE", True) or False
         count = None
         if uselocalcount:
             count = FetchMethod.localcount_internal_helper(ud, d, name)
@@ -869,7 +887,7 @@ class FetchMethod(object):
 
     def generate_revision_key(self, url, ud, d, name):
         key = self._revision_key(url, ud, d, name)
-        return "%s-%s" % (key, bb.data.getVar("PN", d, True) or "")
+        return "%s-%s" % (key, d.getVar("PN", True) or "")
 
 class Fetch(object):
     def __init__(self, urls, d, cache = True):
@@ -879,7 +897,7 @@ class Fetch(object):
         self.d = d
         self.ud = {}
 
-        fn = bb.data.getVar('FILE', d, True)
+        fn = d.getVar('FILE', True)
         if cache and fn in urldata_cache:
             self.ud = urldata_cache[fn]
 
@@ -895,7 +913,7 @@ class Fetch(object):
             self.ud[url] = FetchData(url, self.d)
 
         self.ud[url].setup_localpath(self.d)
-        return bb.data.expand(self.ud[url].localpath, self.d)
+        return self.d.expand(self.ud[url].localpath)
 
     def localpaths(self):
         """
@@ -917,8 +935,8 @@ class Fetch(object):
         if len(urls) == 0:
             urls = self.urls
 
-        network = bb.data.getVar("BB_NO_NETWORK", self.d, True)
-        premirroronly = (bb.data.getVar("BB_FETCH_PREMIRRORONLY", self.d, True) == "1")
+        network = self.d.getVar("BB_NO_NETWORK", True)
+        premirroronly = (self.d.getVar("BB_FETCH_PREMIRRORONLY", True) == "1")
 
         for u in urls:
             ud = self.ud[u]
@@ -929,17 +947,17 @@ class Fetch(object):
             lf = bb.utils.lockfile(ud.lockfile)
 
             try:
-                bb.data.setVar("BB_NO_NETWORK", network, self.d)
+                self.d.setVar("BB_NO_NETWORK", network)
  
                 if not m.need_update(u, ud, self.d):
                     localpath = ud.localpath
                 elif m.try_premirror(u, ud, self.d):
                     logger.debug(1, "Trying PREMIRRORS")
-                    mirrors = mirror_from_string(bb.data.getVar('PREMIRRORS', self.d, True))
+                    mirrors = mirror_from_string(self.d.getVar('PREMIRRORS', True))
                     localpath = try_mirrors(self.d, ud, mirrors, False)
 
                 if premirroronly:
-                    bb.data.setVar("BB_NO_NETWORK", "1", self.d)
+                    self.d.setVar("BB_NO_NETWORK", "1")
 
                 if not localpath and m.need_update(u, ud, self.d):
                     try:
@@ -961,7 +979,7 @@ class Fetch(object):
                         if os.path.isfile(ud.localpath):
                             bb.utils.remove(ud.localpath)
                         logger.debug(1, "Trying MIRRORS")
-                        mirrors = mirror_from_string(bb.data.getVar('MIRRORS', self.d, True))
+                        mirrors = mirror_from_string(self.d.getVar('MIRRORS', True))
                         localpath = try_mirrors (self.d, ud, mirrors)
 
                 if not localpath or ((not os.path.exists(localpath)) and localpath.find("*") == -1):
@@ -986,7 +1004,7 @@ class Fetch(object):
             m = ud.method
             logger.debug(1, "Testing URL %s", u)
             # First try checking uri, u, from PREMIRRORS
-            mirrors = mirror_from_string(bb.data.getVar('PREMIRRORS', self.d, True))
+            mirrors = mirror_from_string(self.d.getVar('PREMIRRORS', True))
             ret = try_mirrors(self.d, ud, mirrors, True)
             if not ret:
                 # Next try checking from the original uri, u
@@ -994,7 +1012,7 @@ class Fetch(object):
                     ret = m.checkstatus(u, ud, self.d)
                 except:
                     # Finally, try checking uri, u, from MIRRORS
-                    mirrors = mirror_from_string(bb.data.getVar('MIRRORS', self.d, True))
+                    mirrors = mirror_from_string(self.d.getVar('MIRRORS', True))
                     ret = try_mirrors (self.d, ud, mirrors, True)
 
             if not ret:
@@ -1012,7 +1030,7 @@ class Fetch(object):
             ud = self.ud[u]
             ud.setup_localpath(self.d)
 
-            if bb.data.expand(self.localpath, self.d) is None:
+            if self.d.expand(self.localpath) is None:
                 continue
 
             if ud.lockfile:

bitbake/lib/bb/fetch2/git.py

@@ -68,7 +68,7 @@ class Git(FetchMethod):
         #
         # Only enable _sortable revision if the key is set
         #
-        if bb.data.getVar("BB_GIT_CLONE_FOR_SRCREV", d, True):
+        if d.getVar("BB_GIT_CLONE_FOR_SRCREV", True):
             self._sortable_buildindex = self._sortable_buildindex_disabled
     def supports(self, url, ud, d):
         """
@@ -115,7 +115,7 @@ class Git(FetchMethod):
                 ud.branches[name] = ud.revisions[name]
                 ud.revisions[name] = self.latest_revision(ud.url, ud, d, name)
 
-        gitsrcname = '%s%s' % (ud.host, ud.path.replace('/', '.'))
+        gitsrcname = '%s%s' % (ud.host.replace(':','.'), ud.path.replace('/', '.'))
         # for rebaseable git repo, it is necessary to keep mirror tar ball
         # per revision, so that even the revision disappears from the
         # upstream repo in the future, the mirror will remain intact and still
@@ -146,7 +146,7 @@ class Git(FetchMethod):
     def try_premirror(self, u, ud, d):
         # If we don't do this, updating an existing checkout with only premirrors
         # is not possible
-        if bb.data.getVar("BB_FETCH_PREMIRRORONLY", d, True) is not None:
+        if d.getVar("BB_FETCH_PREMIRRORONLY", True) is not None:
             return True
         if os.path.exists(ud.clonedir):
             return False
@@ -190,7 +190,7 @@ class Git(FetchMethod):
                 logger.debug(1, "No Origin")
 
             runfetchcmd("%s remote add --mirror=fetch origin %s" % (ud.basecmd, repourl), d)
-            fetch_cmd = "%s fetch --prune %s refs/*:refs/*" % (ud.basecmd, repourl)
+            fetch_cmd = "%s fetch -f --prune %s refs/*:refs/*" % (ud.basecmd, repourl)
             bb.fetch2.check_network_access(d, fetch_cmd, ud.url)
             runfetchcmd(fetch_cmd, d)
             runfetchcmd("%s prune-packed" % ud.basecmd, d)

bitbake/lib/bb/fetch2/local.py

@@ -50,9 +50,6 @@ class Local(FetchMethod):
         path = url.split("://")[1]
         path = path.split(";")[0]
         newpath = path
-        dldirfile = os.path.join(data.getVar("DL_DIR", d, True), os.path.basename(path))
-        if os.path.exists(dldirfile):
-            return dldirfile
         if path[0] != "/":
             filespath = data.getVar('FILESPATH', d, True)
             if filespath:
@@ -62,6 +59,7 @@ class Local(FetchMethod):
                 if filesdir:
                     newpath = os.path.join(filesdir, path)
         if not os.path.exists(newpath) and path.find("*") == -1:
+            dldirfile = os.path.join(data.getVar("DL_DIR", d, True), os.path.basename(path))
             return dldirfile
         return newpath
 

bitbake/lib/bb/msg.py

@@ -106,8 +106,8 @@ def init_msgconfig(verbose, debug, debug_domains = []):
     """
     Set default verbosity and debug levels config the logger
     """
-    bb.msg.loggerDebugLevel = debug
-    bb.msg.loggerVerbose = verbose
+    bb.msg.loggerDefaultDebugLevel = debug
+    bb.msg.loggerDefaultVerbose = verbose
     bb.msg.loggerDefaultDomains = debug_domains
 
 def addDefaultlogFilter(handler):

bitbake/lib/bb/parse/__init__.py

@@ -62,9 +62,9 @@ def update_mtime(f):
 def mark_dependency(d, f):
     if f.startswith('./'):
         f = "%s/%s" % (os.getcwd(), f[2:])
-    deps = bb.data.getVar('__depends', d) or set()
+    deps = d.getVar('__depends') or set()
     deps.update([(f, cached_mtime(f))])
-    bb.data.setVar('__depends', deps, d)
+    d.setVar('__depends', deps)
 
 def supports(fn, data):
     """Returns true if we have a handler for this file, false otherwise"""
@@ -90,7 +90,7 @@ def init_parser(d):
 
 def resolve_file(fn, d):
     if not os.path.isabs(fn):
-        bbpath = bb.data.getVar("BBPATH", d, True)
+        bbpath = d.getVar("BBPATH", True)
         newfn = bb.utils.which(bbpath, fn)
         if not newfn:
             raise IOError("file %s not found in %s" % (fn, bbpath))

bitbake/lib/bb/parse/ast.py

@@ -54,7 +54,7 @@ class IncludeNode(AstNode):
         """
         Include the file and evaluate the statements
         """
-        s = bb.data.expand(self.what_file, data)
+        s = data.expand(self.what_file)
         logger.debug(2, "CONF %s:%s: including %s", self.filename, self.lineno, s)
 
         # TODO: Cache those includes... maybe not here though
@@ -69,7 +69,7 @@ class ExportNode(AstNode):
         self.var = var
 
     def eval(self, data):
-        bb.data.setVarFlag(self.var, "export", 1, data)
+        data.setVarFlag(self.var, "export", 1)
 
 class DataNode(AstNode):
     """
@@ -92,7 +92,7 @@ class DataNode(AstNode):
         groupd = self.groupd
         key = groupd["var"]
         if "exp" in groupd and groupd["exp"] != None:
-            bb.data.setVarFlag(key, "export", 1, data)
+            data.setVarFlag(key, "export", 1)
         if "ques" in groupd and groupd["ques"] != None:
             val = self.getFunc(key, data)
             if val == None:
@@ -100,7 +100,7 @@ class DataNode(AstNode):
         elif "colon" in groupd and groupd["colon"] != None:
             e = data.createCopy()
             bb.data.update_data(e)
-            val = bb.data.expand(groupd["value"], e, key + "[:=]")
+            val = e.expand(groupd["value"], key + "[:=]")
         elif "append" in groupd and groupd["append"] != None:
             val = "%s %s" % ((self.getFunc(key, data) or ""), groupd["value"])
         elif "prepend" in groupd and groupd["prepend"] != None:
@@ -113,11 +113,11 @@ class DataNode(AstNode):
             val = groupd["value"]
 
         if 'flag' in groupd and groupd['flag'] != None:
-            bb.data.setVarFlag(key, groupd['flag'], val, data)
+            data.setVarFlag(key, groupd['flag'], val)
         elif groupd["lazyques"]:
-            bb.data.setVarFlag(key, "defaultval", val, data)
+            data.setVarFlag(key, "defaultval", val)
         else:
-            bb.data.setVar(key, val, data)
+            data.setVar(key, val)
 
 class MethodNode(AstNode):
     def __init__(self, filename, lineno, func_name, body):
@@ -131,12 +131,12 @@ class MethodNode(AstNode):
             if not funcname in bb.methodpool._parsed_fns:
                 text = "def %s(d):\n" % (funcname) + '\n'.join(self.body)
                 bb.methodpool.insert_method(funcname, text, self.filename)
-            anonfuncs = bb.data.getVar('__BBANONFUNCS', data) or []
+            anonfuncs = data.getVar('__BBANONFUNCS') or []
             anonfuncs.append(funcname)
-            bb.data.setVar('__BBANONFUNCS', anonfuncs, data)
+            data.setVar('__BBANONFUNCS', anonfuncs)
         else:
-            bb.data.setVarFlag(self.func_name, "func", 1, data)
-            bb.data.setVar(self.func_name, '\n'.join(self.body), data)
+            data.setVarFlag(self.func_name, "func", 1)
+            data.setVar(self.func_name, '\n'.join(self.body))
 
 class PythonMethodNode(AstNode):
     def __init__(self, filename, lineno, function, define, body):
@@ -152,9 +152,9 @@ class PythonMethodNode(AstNode):
         text = '\n'.join(self.body)
         if not bb.methodpool.parsed_module(self.define):
             bb.methodpool.insert_method(self.define, text, self.filename)
-        bb.data.setVarFlag(self.function, "func", 1, data)
-        bb.data.setVarFlag(self.function, "python", 1, data)
-        bb.data.setVar(self.function, text, data)
+        data.setVarFlag(self.function, "func", 1)
+        data.setVarFlag(self.function, "python", 1)
+        data.setVar(self.function, text)
 
 class MethodFlagsNode(AstNode):
     def __init__(self, filename, lineno, key, m):
@@ -163,19 +163,19 @@ class MethodFlagsNode(AstNode):
         self.m = m
 
     def eval(self, data):
-        if bb.data.getVar(self.key, data):
+        if data.getVar(self.key):
             # clean up old version of this piece of metadata, as its
             # flags could cause problems
-            bb.data.setVarFlag(self.key, 'python', None, data)
-            bb.data.setVarFlag(self.key, 'fakeroot', None, data)
+            data.setVarFlag(self.key, 'python', None)
+            data.setVarFlag(self.key, 'fakeroot', None)
         if self.m.group("py") is not None:
-            bb.data.setVarFlag(self.key, "python", "1", data)
+            data.setVarFlag(self.key, "python", "1")
         else:
-            bb.data.delVarFlag(self.key, "python", data)
+            data.delVarFlag(self.key, "python")
         if self.m.group("fr") is not None:
-            bb.data.setVarFlag(self.key, "fakeroot", "1", data)
+            data.setVarFlag(self.key, "fakeroot", "1")
         else:
-            bb.data.delVarFlag(self.key, "fakeroot", data)
+            data.delVarFlag(self.key, "fakeroot")
 
 class ExportFuncsNode(AstNode):
     def __init__(self, filename, lineno, fns, classes):
@@ -197,25 +197,25 @@ class ExportFuncsNode(AstNode):
                 vars.append([allvars[0], allvars[2]])
 
             for (var, calledvar) in vars:
-                if bb.data.getVar(var, data) and not bb.data.getVarFlag(var, 'export_func', data):
+                if data.getVar(var) and not data.getVarFlag(var, 'export_func'):
                     continue
 
-                if bb.data.getVar(var, data):
-                    bb.data.setVarFlag(var, 'python', None, data)
-                    bb.data.setVarFlag(var, 'func', None, data)
+                if data.getVar(var):
+                    data.setVarFlag(var, 'python', None)
+                    data.setVarFlag(var, 'func', None)
 
                 for flag in [ "func", "python" ]:
-                    if bb.data.getVarFlag(calledvar, flag, data):
-                        bb.data.setVarFlag(var, flag, bb.data.getVarFlag(calledvar, flag, data), data)
+                    if data.getVarFlag(calledvar, flag):
+                        data.setVarFlag(var, flag, data.getVarFlag(calledvar, flag))
                 for flag in [ "dirs" ]:
-                    if bb.data.getVarFlag(var, flag, data):
-                        bb.data.setVarFlag(calledvar, flag, bb.data.getVarFlag(var, flag, data), data)
+                    if data.getVarFlag(var, flag):
+                        data.setVarFlag(calledvar, flag, data.getVarFlag(var, flag))
 
-                if bb.data.getVarFlag(calledvar, "python", data):
-                    bb.data.setVar(var, "\tbb.build.exec_func('" + calledvar + "', d)\n", data)
+                if data.getVarFlag(calledvar, "python"):
+                    data.setVar(var, "\tbb.build.exec_func('" + calledvar + "', d)\n")
                 else:
-                    bb.data.setVar(var, "\t" + calledvar + "\n", data)
-                bb.data.setVarFlag(var, 'export_func', '1', data)
+                    data.setVar(var, "\t" + calledvar + "\n")
+                data.setVarFlag(var, 'export_func', '1')
 
 class AddTaskNode(AstNode):
     def __init__(self, filename, lineno, func, before, after):
@@ -229,25 +229,25 @@ class AddTaskNode(AstNode):
         if self.func[:3] != "do_":
             var = "do_" + self.func
 
-        bb.data.setVarFlag(var, "task", 1, data)
-        bbtasks = bb.data.getVar('__BBTASKS', data) or []
+        data.setVarFlag(var, "task", 1)
+        bbtasks = data.getVar('__BBTASKS') or []
         if not var in bbtasks:
             bbtasks.append(var)
-        bb.data.setVar('__BBTASKS', bbtasks, data)
+        data.setVar('__BBTASKS', bbtasks)
 
-        existing = bb.data.getVarFlag(var, "deps", data) or []
+        existing = data.getVarFlag(var, "deps") or []
         if self.after is not None:
             # set up deps for function
             for entry in self.after.split():
                 if entry not in existing:
                     existing.append(entry)
-        bb.data.setVarFlag(var, "deps", existing, data)
+        data.setVarFlag(var, "deps", existing)
         if self.before is not None:
             # set up things that depend on this func
             for entry in self.before.split():
-                existing = bb.data.getVarFlag(entry, "deps", data) or []
+                existing = data.getVarFlag(entry, "deps") or []
                 if var not in existing:
-                    bb.data.setVarFlag(entry, "deps", [var] + existing, data)
+                    data.setVarFlag(entry, "deps", [var] + existing)
 
 class BBHandlerNode(AstNode):
     def __init__(self, filename, lineno, fns):
@@ -255,11 +255,11 @@ class BBHandlerNode(AstNode):
         self.hs = fns.split()
 
     def eval(self, data):
-        bbhands = bb.data.getVar('__BBHANDLERS', data) or []
+        bbhands = data.getVar('__BBHANDLERS') or []
         for h in self.hs:
             bbhands.append(h)
-            bb.data.setVarFlag(h, "handler", 1, data)
-        bb.data.setVar('__BBHANDLERS', bbhands, data)
+            data.setVarFlag(h, "handler", 1)
+        data.setVar('__BBHANDLERS', bbhands)
 
 class InheritNode(AstNode):
     def __init__(self, filename, lineno, classes):
@@ -308,9 +308,9 @@ def handleInherit(statements, filename, lineno, m):
 
 def finalize(fn, d, variant = None):
     all_handlers = {}
-    for var in bb.data.getVar('__BBHANDLERS', d) or []:
+    for var in d.getVar('__BBHANDLERS') or []:
         # try to add the handler
-        handler = bb.data.getVar(var, d)
+        handler = d.getVar(var)
         bb.event.register(var, handler)
 
     bb.event.fire(bb.event.RecipePreFinalise(fn), d)
@@ -318,12 +318,12 @@ def finalize(fn, d, variant = None):
     bb.data.expandKeys(d)
     bb.data.update_data(d)
     code = []
-    for funcname in bb.data.getVar("__BBANONFUNCS", d) or []:
+    for funcname in d.getVar("__BBANONFUNCS") or []:
         code.append("%s(d)" % funcname)
     bb.utils.simple_exec("\n".join(code), {"d": d})
     bb.data.update_data(d)
 
-    tasklist = bb.data.getVar('__BBTASKS', d) or []
+    tasklist = d.getVar('__BBTASKS') or []
     bb.build.add_tasks(tasklist, d)
 
     bb.parse.siggen.finalise(fn, d, variant)
@@ -378,7 +378,7 @@ def multi_finalize(fn, d):
     try:
         finalize(fn, d)
     except bb.parse.SkipPackage as e:
-        bb.data.setVar("__SKIPPED", e.args[0], d)
+        d.setVar("__SKIPPED", e.args[0])
     datastores = {"": safe_d}
 
     versions = (d.getVar("BBVERSIONS", True) or "").split()
@@ -421,7 +421,7 @@ def multi_finalize(fn, d):
             try:
                 finalize(fn, d)
             except bb.parse.SkipPackage as e:
-                bb.data.setVar("__SKIPPED", e.args[0], d)
+                d.setVar("__SKIPPED", e.args[0])
 
         _create_variants(datastores, versions, verfunc)
 
@@ -461,7 +461,7 @@ def multi_finalize(fn, d):
                 if not onlyfinalise or variant in onlyfinalise:
                     finalize(fn, variant_d, variant)
             except bb.parse.SkipPackage as e:
-                bb.data.setVar("__SKIPPED", e.args[0], variant_d)
+                variant_d.setVar("__SKIPPED", e.args[0])
 
     if len(datastores) > 1:
         variants = filter(None, datastores.iterkeys())

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

@@ -148,7 +148,7 @@ def handle(fn, d, include):
 
     # DONE WITH PARSING... time to evaluate
     if ext != ".bbclass":
-        data.setVar('FILE', fn, d)
+        data.setVar('FILE', abs_fn, d)
 
     statements.eval(d)
 
@@ -159,7 +159,7 @@ def handle(fn, d, include):
             return ast.multi_finalize(fn, d)
 
     if oldfile:
-        bb.data.setVar("FILE", oldfile, d)
+        d.setVar("FILE", oldfile)
 
     # we have parsed the bb class now
     if ext == ".bbclass" or ext == ".inc":
@@ -193,7 +193,6 @@ def feeder(lineno, s, fn, root, statements):
             if lineno == IN_PYTHON_EOF:
                 return
 
-
     if s and s[0] == '#':
         if len(__residue__) != 0 and __residue__[0][0] != "#":
             bb.error("There is a comment on line %s of file %s (%s) which is in the middle of a multiline expression.\nBitbake used to ignore these but no longer does so, please fix your metadata as errors are likely as a result of this change." % (lineno, fn, s))

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

@@ -24,7 +24,7 @@
 # with this program; if not, write to the Free Software Foundation, Inc.,
 # 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
 
-import re, bb.data, os
+import re, os
 import logging
 import bb.utils
 from bb.parse import ParseError, resolve_file, ast, logger
@@ -36,9 +36,9 @@ __require_regexp__ = re.compile( r"require\s+(.+)" )
 __export_regexp__ = re.compile( r"export\s+(.+)" )
 
 def init(data):
-    topdir = bb.data.getVar('TOPDIR', data)
+    topdir = data.getVar('TOPDIR')
     if not topdir:
-        bb.data.setVar('TOPDIR', os.getcwd(), data)
+        data.setVar('TOPDIR', os.getcwd())
 
 
 def supports(fn, d):
@@ -53,12 +53,12 @@ def include(oldfn, fn, data, error_out):
         return None
 
     import bb
-    fn = bb.data.expand(fn, data)
-    oldfn = bb.data.expand(oldfn, data)
+    fn = data.expand(fn)
+    oldfn = data.expand(oldfn)
 
     if not os.path.isabs(fn):
         dname = os.path.dirname(oldfn)
-        bbpath = "%s:%s" % (dname, bb.data.getVar("BBPATH", data, 1))
+        bbpath = "%s:%s" % (dname, data.getVar("BBPATH", 1))
         abs_fn = bb.utils.which(bbpath, fn)
         if abs_fn:
             fn = abs_fn
@@ -77,7 +77,7 @@ def handle(fn, data, include):
     if include == 0:
         oldfile = None
     else:
-        oldfile = bb.data.getVar('FILE', data)
+        oldfile = data.getVar('FILE')
 
     abs_fn = resolve_file(fn, data)
     f = open(abs_fn, 'r')
@@ -102,10 +102,10 @@ def handle(fn, data, include):
         feeder(lineno, s, fn, statements)
 
     # DONE WITH PARSING... time to evaluate
-    bb.data.setVar('FILE', fn, data)
+    data.setVar('FILE', abs_fn)
     statements.eval(data)
     if oldfile:
-        bb.data.setVar('FILE', oldfile, data)
+        data.setVar('FILE', oldfile)
 
     return data
 

bitbake/lib/bb/persist_data.py

@@ -192,9 +192,9 @@ def connect(database):
 
 def persist(domain, d):
     """Convenience factory for SQLTable objects based upon metadata"""
-    import bb.data, bb.utils
-    cachedir = (bb.data.getVar("PERSISTENT_DIR", d, True) or
-                bb.data.getVar("CACHE", d, True))
+    import bb.utils
+    cachedir = (d.getVar("PERSISTENT_DIR", True) or
+                d.getVar("CACHE", True))
     if not cachedir:
         logger.critical("Please set the 'PERSISTENT_DIR' or 'CACHE' variable")
         sys.exit(1)

bitbake/lib/bb/providers.py

@@ -28,10 +28,10 @@ import bb
 
 logger = logging.getLogger("BitBake.Provider")
 
-class NoProvider(Exception):
+class NoProvider(bb.BBHandledException):
     """Exception raised when no provider of a build dependency can be found"""
 
-class NoRProvider(Exception):
+class NoRProvider(bb.BBHandledException):
     """Exception raised when no provider of a runtime dependency can be found"""
 
 
@@ -84,10 +84,10 @@ def findPreferredProvider(pn, cfgData, dataCache, pkg_pn = None, item = None):
     preferred_ver = None
 
     localdata = data.createCopy(cfgData)
-    bb.data.setVar('OVERRIDES', "%s:pn-%s:%s" % (data.getVar('OVERRIDES', localdata), pn, pn), localdata)
+    localdata.setVar('OVERRIDES', "%s:pn-%s:%s" % (data.getVar('OVERRIDES', localdata), pn, pn))
     bb.data.update_data(localdata)
 
-    preferred_v = bb.data.getVar('PREFERRED_VERSION', localdata, True)
+    preferred_v = localdata.getVar('PREFERRED_VERSION', True)
     if preferred_v:
         m = re.match('(\d+:)*(.*)(_.*)*', preferred_v)
         if m:
@@ -248,7 +248,7 @@ def filterProviders(providers, item, cfgData, dataCache):
 
     eligible = _filterProviders(providers, item, cfgData, dataCache)
 
-    prefervar = bb.data.getVar('PREFERRED_PROVIDER_%s' % item, cfgData, 1)
+    prefervar = cfgData.getVar('PREFERRED_PROVIDER_%s' % item, 1)
     if prefervar:
         dataCache.preferred[item] = prefervar
 
@@ -286,7 +286,7 @@ def filterProvidersRunTime(providers, item, cfgData, dataCache):
         pn = dataCache.pkg_fn[p]
         provides = dataCache.pn_provides[pn]
         for provide in provides:
-            prefervar = bb.data.getVar('PREFERRED_PROVIDER_%s' % provide, cfgData, 1)
+            prefervar = cfgData.getVar('PREFERRED_PROVIDER_%s' % provide, 1)
             logger.debug(1, "checking PREFERRED_PROVIDER_%s (value %s) against %s", provide, prefervar, pns.keys())
             if prefervar in pns and pns[prefervar] not in preferred:
                 var = "PREFERRED_PROVIDER_%s = %s" % (provide, prefervar)

bitbake/lib/bb/runqueue.py

@@ -188,8 +188,8 @@ class RunQueueData:
         self.targets = targets
         self.rq = rq
 
-        self.stampwhitelist = bb.data.getVar("BB_STAMP_WHITELIST", cfgData, 1) or ""
-        self.multi_provider_whitelist = (bb.data.getVar("MULTI_PROVIDER_WHITELIST", cfgData, 1) or "").split()
+        self.stampwhitelist = cfgData.getVar("BB_STAMP_WHITELIST", 1) or ""
+        self.multi_provider_whitelist = (cfgData.getVar("MULTI_PROVIDER_WHITELIST", 1) or "").split()
 
         self.reset()
 
@@ -765,8 +765,9 @@ class RunQueue:
         self.cfgData = cfgData
         self.rqdata = RunQueueData(self, cooker, cfgData, dataCache, taskData, targets)
 
-        self.stamppolicy = bb.data.getVar("BB_STAMP_POLICY", cfgData, True) or "perfile"
-        self.hashvalidate = bb.data.getVar("BB_HASHCHECK_FUNCTION", cfgData, True) or None
+        self.stamppolicy = cfgData.getVar("BB_STAMP_POLICY", True) or "perfile"
+        self.hashvalidate = cfgData.getVar("BB_HASHCHECK_FUNCTION", True) or None
+        self.setsceneverify = cfgData.getVar("BB_SETSCENE_VERIFY_FUNCTION", True) or None
 
         self.state = runQueuePrepare
 
@@ -1006,8 +1007,8 @@ class RunQueueExecute:
         self.cfgData = rq.cfgData
         self.rqdata = rq.rqdata
 
-        self.number_tasks = int(bb.data.getVar("BB_NUMBER_THREADS", self.cfgData, 1) or 1)
-        self.scheduler = bb.data.getVar("BB_SCHEDULER", self.cfgData, 1) or "speed"
+        self.number_tasks = int(self.cfgData.getVar("BB_NUMBER_THREADS", 1) or 1)
+        self.scheduler = self.cfgData.getVar("BB_SCHEDULER", 1) or "speed"
 
         self.runq_buildable = []
         self.runq_running = []
@@ -1096,6 +1097,12 @@ class RunQueueExecute:
 
             logger.debug(2, 'Running %s:%s under fakeroot, fakedirs: %s' %
                             (fn, taskname, ', '.join(fakedirs)))
+        else:
+            envvars = (self.rqdata.dataCache.fakerootnoenv[fn] or "").split()
+            for key, value in (var.split('=') for var in envvars):
+                envbackup[key] = os.environ.get(key)
+                os.environ[key] = value
+                fakeenv[key] = value
 
         sys.stdout.flush()
         sys.stderr.flush()
@@ -1125,9 +1132,9 @@ class RunQueueExecute:
             if umask:
                 os.umask(umask)
 
-            bb.data.setVar("BB_WORKERCONTEXT", "1", self.cooker.configuration.data)
-            bb.data.setVar("__RUNQUEUE_DO_NOT_USE_EXTERNALLY", self, self.cooker.configuration.data)
-            bb.data.setVar("__RUNQUEUE_DO_NOT_USE_EXTERNALLY2", fn, self.cooker.configuration.data)
+            self.cooker.configuration.data.setVar("BB_WORKERCONTEXT", "1")
+            self.cooker.configuration.data.setVar("__RUNQUEUE_DO_NOT_USE_EXTERNALLY", self)
+            self.cooker.configuration.data.setVar("__RUNQUEUE_DO_NOT_USE_EXTERNALLY2", fn)
             bb.parse.siggen.set_taskdata(self.rqdata.hashes, self.rqdata.hash_deps)
             ret = 0
             try:
@@ -1202,34 +1209,38 @@ class RunQueueExecuteTasks(RunQueueExecute):
             for task in xrange(self.stats.total):
                 if task in self.rq.scenequeue_covered:
                     continue
-                if len(self.rqdata.runq_revdeps[task]) > 0 and self.rqdata.runq_revdeps[task].issubset(self.rq.scenequeue_covered):
-                    self.rq.scenequeue_covered.add(task)
-                    found = True
+                logger.debug(1, 'Considering %s (%s): %s' % (task, self.rqdata.get_user_idstring(task), str(self.rqdata.runq_revdeps[task])))
 
-        # Detect when the real task needs to be run anyway by looking to see
-        # if any of its dependencies within the same package are scheduled
-        # to be run.
+                if len(self.rqdata.runq_revdeps[task]) > 0 and self.rqdata.runq_revdeps[task].issubset(self.rq.scenequeue_covered):
+                    ok = True
+                    for revdep in self.rqdata.runq_revdeps[task]:
+                        if self.rqdata.runq_fnid[task] != self.rqdata.runq_fnid[revdep]:
+                            logger.debug(1, 'Found "bad" dep %s (%s) for %s (%s)' % (revdep, self.rqdata.get_user_idstring(revdep), task, self.rqdata.get_user_idstring(task)))
+
+                            ok = False
+                            break
+                    if ok:
+                        found = True
+                        self.rq.scenequeue_covered.add(task)
+
+        logger.debug(1, 'Skip list (pre setsceneverify) %s', sorted(self.rq.scenequeue_covered))
+
+        # Allow the metadata to elect for setscene tasks to run anyway
         covered_remove = set()
-        for task in self.rq.scenequeue_covered:
-            task_fnid = self.rqdata.runq_fnid[task]
-            for dep in self.rqdata.runq_depends[task]:
-                if self.rqdata.runq_fnid[dep] == task_fnid:
-                    if dep not in self.rq.scenequeue_covered:
-                        covered_remove.add(task)
-                        break
+        if self.rq.setsceneverify:
+            call = self.rq.setsceneverify + "(covered, tasknames, fnids, fns, d)"
+            locs = { "covered" : self.rq.scenequeue_covered, "tasknames" : self.rqdata.runq_task, "fnids" : self.rqdata.runq_fnid, "fns" : self.rqdata.taskData.fn_index, "d" : self.cooker.configuration.data }
+            covered_remove = bb.utils.better_eval(call, locs)
 
         for task in covered_remove:
             fn = self.rqdata.taskData.fn_index[self.rqdata.runq_fnid[task]]
             taskname = self.rqdata.runq_task[task] + '_setscene'
             bb.build.del_stamp(taskname, self.rqdata.dataCache, fn)
-            logger.debug(1, 'Not skipping task %s because it will have to be run anyway', task)
+            logger.debug(1, 'Not skipping task %s due to setsceneverify', task)
             self.rq.scenequeue_covered.remove(task)
 
         logger.debug(1, 'Full skip list %s', self.rq.scenequeue_covered)
 
-        for task in self.rq.scenequeue_covered:
-            self.task_skip(task)
-
         event.fire(bb.event.StampUpdate(self.rqdata.target_pairs, self.rqdata.dataCache.stamp), self.cfgData)
 
         schedulers = self.get_schedulers()
@@ -1248,7 +1259,7 @@ class RunQueueExecuteTasks(RunQueueExecute):
                              if type(obj) is type and
                                 issubclass(obj, RunQueueScheduler))
 
-        user_schedulers = bb.data.getVar("BB_SCHEDULERS", self.cfgData, True)
+        user_schedulers = self.cfgData.getVar("BB_SCHEDULERS", True)
         if user_schedulers:
             for sched in user_schedulers.split():
                 if not "." in sched:
@@ -1323,8 +1334,14 @@ class RunQueueExecuteTasks(RunQueueExecute):
         task = self.sched.next()
         if task is not None:
             fn = self.rqdata.taskData.fn_index[self.rqdata.runq_fnid[task]]
-
             taskname = self.rqdata.runq_task[task]
+
+            if task in self.rq.scenequeue_covered:
+                logger.debug(2, "Setscene covered task %s (%s)", task,
+                                self.rqdata.get_user_idstring(task))
+                self.task_skip(task)
+                return True
+
             if self.rq.check_stamp_task(task, taskname):
                 logger.debug(2, "Stamp current task %s (%s)", task,
                                 self.rqdata.get_user_idstring(task))
@@ -1506,8 +1523,9 @@ class RunQueueExecuteScenequeue(RunQueueExecute):
 
             for task in xrange(len(self.sq_revdeps)):
                 if task not in valid_new and task not in noexec:
+                    realtask = self.rqdata.runq_setscene[task]
                     logger.debug(2, 'No package found, so skipping setscene task %s',
-                                 self.rqdata.get_user_idstring(task))
+                                 self.rqdata.get_user_idstring(realtask))
                     self.task_failoutright(task)
 
         logger.info('Executing SetScene Tasks')
@@ -1580,7 +1598,7 @@ class RunQueueExecuteScenequeue(RunQueueExecute):
             taskname = self.rqdata.runq_task[realtask] + "_setscene"
             if self.rq.check_stamp_task(realtask, self.rqdata.runq_task[realtask]):
                 logger.debug(2, 'Stamp for underlying task %s(%s) is current, so skipping setscene variant',
-                             task, self.rqdata.get_user_idstring(task))
+                             task, self.rqdata.get_user_idstring(realtask))
                 self.task_failoutright(task)
                 return True
 
@@ -1622,7 +1640,7 @@ class RunQueueExecuteScenequeue(RunQueueExecute):
         for task in oldcovered:
             self.rq.scenequeue_covered.add(self.rqdata.runq_setscene[task])
 
-        logger.debug(1, 'We can skip tasks %s', self.rq.scenequeue_covered)
+        logger.debug(1, 'We can skip tasks %s', sorted(self.rq.scenequeue_covered))
 
         self.rq.state = runQueueRunInit
         return True
@@ -1688,8 +1706,8 @@ class runQueueTaskCompleted(runQueueEvent):
     """
 
 def check_stamp_fn(fn, taskname, d):
-    rqexe = bb.data.getVar("__RUNQUEUE_DO_NOT_USE_EXTERNALLY", d)
-    fn = bb.data.getVar("__RUNQUEUE_DO_NOT_USE_EXTERNALLY2", d)
+    rqexe = d.getVar("__RUNQUEUE_DO_NOT_USE_EXTERNALLY")
+    fn = d.getVar("__RUNQUEUE_DO_NOT_USE_EXTERNALLY2")
     fnid = rqexe.rqdata.taskData.getfn_id(fn)
     taskid = rqexe.rqdata.get_task_id(fnid, taskname)
     if taskid is not None:

bitbake/lib/bb/server/xmlrpc.py

@@ -242,9 +242,9 @@ class BitBakeXMLRPCServer(SimpleXMLRPCServer):
         return
 
 class BitbakeServerInfo():
-    def __init__(self, server):
-        self.host = server.host
-        self.port = server.port
+    def __init__(self, host, port):
+        self.host = host
+        self.port = port
 
 class BitBakeServerConnection():
     def __init__(self, serverinfo):
@@ -278,7 +278,7 @@ class BitBakeServer(object):
         return self.server.register_idle_function
 
     def saveConnectionDetails(self): 
-        self.serverinfo = BitbakeServerInfo(self.server)
+        self.serverinfo = BitbakeServerInfo(self.server.host, self.server.port)
 
     def detach(self, cooker_logfile):
         daemonize.createDaemon(self.server.serve_forever, cooker_logfile)

bitbake/lib/bb/siggen.py

@@ -16,7 +16,7 @@ def init(d):
     siggens = [obj for obj in globals().itervalues()
                       if type(obj) is type and issubclass(obj, SignatureGenerator)]
 
-    desired = bb.data.getVar("BB_SIGNATURE_HANDLER", d, True) or "noop"
+    desired = d.getVar("BB_SIGNATURE_HANDLER", True) or "noop"
     for sg in siggens:
         if desired == sg.name:
             return sg(d)
@@ -72,11 +72,10 @@ class SignatureGeneratorBasic(SignatureGenerator):
 
     def _build_data(self, fn, d):
 
-        tasklist, gendeps = bb.data.generate_dependencies(d)
+        tasklist, gendeps, lookupcache = bb.data.generate_dependencies(d)
 
         taskdeps = {}
         basehash = {}
-        lookupcache = {}
 
         for task in tasklist:
             data = d.getVar(task, False)
@@ -101,6 +100,7 @@ class SignatureGeneratorBasic(SignatureGenerator):
             alldeps = seen - self.basewhitelist
 
             for dep in sorted(alldeps):
+                data = data + dep
                 if dep in lookupcache:
                     var = lookupcache[dep]
                 else:
@@ -135,7 +135,7 @@ class SignatureGeneratorBasic(SignatureGenerator):
         k = fn + "." + task
         data = dataCache.basetaskhash[k]
         self.runtaskdeps[k] = []
-        for dep in sorted(deps):
+        for dep in sorted(deps, key=clean_basepath):
             # We only manipulate the dependencies for packages not in the whitelist
             if self.twl and not self.twl.search(dataCache.pkg_fn[fn]):
                 # then process the actual dependencies
@@ -159,7 +159,7 @@ class SignatureGeneratorBasic(SignatureGenerator):
         k = fn + "." + task
         if runtime == "customfile":
             sigfile = stampbase
-        elif runtime:
+        elif runtime and k in self.taskhash:
             sigfile = stampbase + "." + task + ".sigdata" + "." + self.taskhash[k]
         else:
             sigfile = stampbase + "." + task + ".sigbasedata" + "." + self.basehash[k]
@@ -180,7 +180,7 @@ class SignatureGeneratorBasic(SignatureGenerator):
             data['gendeps'][dep] = self.gendeps[fn][dep]
             data['varvals'][dep] = self.lookupcache[fn][dep]
 
-        if runtime:
+        if runtime and k in self.taskhash:
             data['runtaskdeps'] = self.runtaskdeps[k]
             data['runtaskhashes'] = {}
             for dep in data['runtaskdeps']:
@@ -217,19 +217,32 @@ def dump_this_task(outfile, d):
     task = "do_" + d.getVar("BB_CURRENTTASK", True)
     bb.parse.siggen.dump_sigtask(fn, task, outfile, "customfile")
 
+def clean_basepath(a):
+    if a.startswith("virtual:"):
+        b = a.rsplit(":", 1)[0] + a.rsplit("/", 1)[1]
+    else:
+        b = a.rsplit("/", 1)[1]
+    return b
+
+def clean_basepaths(a):
+    b = {}
+    for x in a:
+        b[clean_basepath(x)] = a[x]
+    return b
+
 def compare_sigfiles(a, b):
     p1 = pickle.Unpickler(file(a, "rb"))
     a_data = p1.load()
     p2 = pickle.Unpickler(file(b, "rb"))
     b_data = p2.load()
 
-    def dict_diff(a, b):
+    def dict_diff(a, b, whitelist=set()):
         sa = set(a.keys())
         sb = set(b.keys())
         common = sa & sb
         changed = set()
         for i in common:
-            if a[i] != b[i]:
+            if a[i] != b[i] and i not in whitelist:
                 changed.add(i)
         added = sa - sb
         removed = sb - sa
@@ -237,20 +250,23 @@ def compare_sigfiles(a, b):
 
     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'])
+        print "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'])
+        print "changed items: %s" % a_data['taskwhitelist'].symmetric_difference(b_data['taskwhitelist'])
 
     if a_data['taskdeps'] != b_data['taskdeps']:
-        print "Task dependencies changed from %s to %s" % (sorted(a_data['taskdeps']), sorted(b_data['taskdeps']))
+        print "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'])
 
-    changed, added, removed = dict_diff(a_data['gendeps'], b_data['gendeps'])
+    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])
+            print "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)
@@ -265,7 +281,9 @@ def compare_sigfiles(a, b):
             print "Variable %s value changed from %s to %s" % (dep, a_data['varvals'][dep], b_data['varvals'][dep])
 
     if 'runtaskhashes' in a_data and 'runtaskhashes' in b_data:
-        changed, added, removed = dict_diff(a_data['runtaskhashes'], b_data['runtaskhashes'])
+        a = clean_basepaths(a_data['runtaskhashes'])
+        b = clean_basepaths(b_data['runtaskhashes'])
+        changed, added, removed = dict_diff(a, b)
         if added:
             for dep in added:
                 print "Dependency on task %s was added" % (dep)
@@ -274,9 +292,10 @@ def compare_sigfiles(a, b):
                 print "Dependency on task %s was removed" % (dep)
         if changed:
             for dep in changed:
-                print "Hash for dependent task %s changed from %s to %s" % (dep, a_data['runtaskhashes'][dep], b_data['runtaskhashes'][dep])
+                print "Hash for dependent task %s changed from %s to %s" % (dep, a[dep], b[dep])
     elif 'runtaskdeps' in a_data and 'runtaskdeps' in b_data and sorted(a_data['runtaskdeps']) != sorted(b_data['runtaskdeps']):
         print "Tasks this task depends on changed from %s to %s" % (sorted(a_data['runtaskdeps']), sorted(b_data['runtaskdeps']))
+        print "changed items: %s" % a_data['runtaskdeps'].symmetric_difference(b_data['runtaskdeps'])
 
 def dump_sigfile(a):
     p1 = pickle.Unpickler(file(a, "rb"))

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

@@ -58,7 +58,7 @@ class Configurator(gobject.GObject):
 
     def _loadConf(self, path):
         def getString(var):
-            return bb.data.getVar(var, data, True) or ""
+            return data.getVar(var, True) or ""
 
         if self.orig_config:
             del self.orig_config
@@ -125,7 +125,7 @@ class Configurator(gobject.GObject):
         self.loaded_layers = {}
         data = bb.data.init()
         data = self._parse(self.bblayers, data)
-        layers = (bb.data.getVar('BBLAYERS', data, True) or "").split()
+        layers = (data.getVar('BBLAYERS', True) or "").split()
         for layer in layers:
             # TODO: we may be better off calling the layer by its
             # BBFILE_COLLECTIONS value?

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

@@ -88,6 +88,8 @@ class HobHandler(gobject.GObject):
         deploy_dir = self.server.runCommand(["getVariable", "DEPLOY_DIR"])
         self.image_out_dir = os.path.join(deploy_dir, "images")
         self.image_output_types = self.server.runCommand(["getVariable", "IMAGE_FSTYPES"]).split(" ")
+        self.bbpath = self.server.runCommand(["getVariable", "BBPATH"])
+        self.bbfiles = self.server.runCommand(["getVariable", "BBFILES"])
 
     def run_next_command(self):
         if self.current_command and not self.generating:
@@ -263,8 +265,7 @@ class HobHandler(gobject.GObject):
         self.build_queue = targets
 
         if not self.bbpath_ok:
-            bbpath = self.server.runCommand(["getVariable", "BBPATH"])
-            if self.image_dir in bbpath.split(":"):
+            if self.image_dir in self.bbpath.split(":"):
                 self.bbpath_ok = True
             else:
                 nbbp = self.image_dir
@@ -272,8 +273,8 @@ class HobHandler(gobject.GObject):
         if not self.bbfiles_ok:
             import re
             pattern = "%s/\*.bb" % self.image_dir
-            bbfiles = self.server.runCommand(["getVariable", "BBFILES"]).split(" ")
-            for files in bbfiles:
+
+            for files in self.bbfiles.split(" "):
                 if re.match(pattern, files):
                     self.bbfiles_ok = True
 
@@ -327,7 +328,7 @@ class HobHandler(gobject.GObject):
         return self.image_output_types
 
     def get_image_deploy_dir(self):
-        return self.img_out_dir
+        return self.image_out_dir
 
     def make_temp_dir(self):
         bb.utils.mkdirhier(self.image_dir)

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

@@ -39,6 +39,7 @@ class HobPrefs(gtk.Dialog):
             self.selected_image_types = handler.remove_image_output_type(ot)
 
         self.configurator.setConfVar('IMAGE_FSTYPES', "%s" % " ".join(self.selected_image_types).lstrip(" "))
+        self.reload_required = True
 
     def sdk_machine_combo_changed_cb(self, combo, handler):
         sdk_mach = combo.get_active_text()

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

@@ -179,6 +179,10 @@ class RunningBuild (gobject.GObject):
             # that we need to attach to a task.
             self.tasks_to_iter[(package, task)] = i
 
+        # If we don't handle these the GUI does not proceed
+        elif isinstance(event, bb.build.TaskInvalid):
+            return
+
         elif isinstance(event, bb.build.TaskBase):
             current = self.tasks_to_iter[(package, task)]
             parent = self.tasks_to_iter[(package, None)]

bitbake/lib/bb/ui/hob.py

@@ -304,13 +304,11 @@ class MainWindow (gtk.Window):
                 self.image_combo.disconnect(self.image_combo_id)
                 self.image_combo_id = None
             self.model.set_selected_image(self.selected_image)
-            self.selected_image = None
             if not self.image_combo_id:
                 self.image_combo_id = self.image_combo.connect("changed", self.image_changed_cb)
 
         if self.selected_packages:
             self.model.set_selected_packages(self.selected_packages)
-            self.selected_packages = None
 
     def reset_clicked_cb(self, button):
         lbl = "<b>Reset your selections?</b>\n\nAny new changes you have made will be lost"
@@ -398,11 +396,13 @@ class MainWindow (gtk.Window):
                                                  gtk.RESPONSE_OK))
         response  = chooser.run()
         rep = BuildRep(None, None, None)
+        recipe = chooser.get_filename()
         if response == gtk.RESPONSE_OK:
-            rep.loadRecipe(chooser.get_filename())
+            rep.loadRecipe(recipe)
+            self.save_path = recipe
+            self.model.load_image_rep(rep)
+            self.dirty = False
         chooser.destroy()
-        self.model.load_image_rep(rep)
-        self.dirty = False
 
     def bake_clicked_cb(self, button):
         build_image = True

bitbake/lib/bb/ui/knotty.py

@@ -69,6 +69,7 @@ def main(server, eventHandler):
     # Get values of variables which control our output
     includelogs = server.runCommand(["getVariable", "BBINCLUDELOGS"])
     loglines = server.runCommand(["getVariable", "BBINCLUDELOGS_LINES"])
+    consolelogfile = server.runCommand(["getVariable", "BB_CONSOLELOG"])
 
     helper = uihelper.BBUIHelper()
 
@@ -77,6 +78,11 @@ def main(server, eventHandler):
     bb.msg.addDefaultlogFilter(console)
     console.setFormatter(format)
     logger.addHandler(console)
+    if consolelogfile:
+        consolelog = logging.FileHandler(consolelogfile)
+        bb.msg.addDefaultlogFilter(consolelog)
+        consolelog.setFormatter(format)
+        logger.addHandler(consolelog)
 
     try:
         cmdline = server.runCommand(["getCmdLineAction"])
@@ -99,6 +105,8 @@ def main(server, eventHandler):
     cacheprogress = None
     shutdown = 0
     return_value = 0
+    errors = 0
+    warnings = 0
     while True:
         try:
             event = eventHandler.waitEvent(0.25)
@@ -117,13 +125,15 @@ def main(server, eventHandler):
 
             if isinstance(event, logging.LogRecord):
                 if event.levelno >= format.ERROR:
+                    errors = errors + 1
                     return_value = 1
+                if event.levelno >= format.WARNING:
+                    warnings = warnings + 1
                 # For "normal" logging conditions, don't show note logs from tasks
                 # but do show them if the user has changed the default log level to 
                 # include verbose/debug messages
-                #if logger.getEffectiveLevel() > format.VERBOSE:
                 if event.taskpid != 0 and event.levelno <= format.NOTE:
-                        continue
+                    continue
                 logger.handle(event)
                 continue
 
@@ -202,6 +212,7 @@ def main(server, eventHandler):
                 continue
             if isinstance(event, bb.event.NoProvider):
                 return_value = 1
+                errors = errors + 1
                 if event._runtime:
                     r = "R"
                 else:
@@ -261,4 +272,8 @@ def main(server, eventHandler):
                 server.runCommand(["stateShutdown"])
             shutdown = shutdown + 1
             pass
+    if warnings:
+        print("Summary: There were %s WARNING messages shown.\n" % warnings)
+    if return_value:
+        print("Summary: There were %s ERROR messages shown, returning a non-zero exit code.\n" % errors)
     return return_value

bitbake/lib/bb/utils.py

@@ -443,7 +443,7 @@ def lockfile(name, shared=False, retry=True):
                     return lf
             lf.close()
         except Exception:
-            continue
+            pass
         if not retry:
             return None
 
@@ -505,7 +505,6 @@ def preserved_envvars_exported():
         'SHELL',
         'TERM',
         'USER',
-        'USERNAME',
     ]
 
 def preserved_envvars_exported_interactive():
@@ -563,7 +562,7 @@ def filter_environment(good_vars):
 
 def create_interactive_env(d):
     for k in preserved_envvars_exported_interactive():
-        os.setenv(k, bb.data.getVar(k, d, True))
+        os.setenv(k, d.getVar(k, True))
 
 def approved_variables():
     """
@@ -602,9 +601,9 @@ def build_environment(d):
     """
     import bb.data
     for var in bb.data.keys(d):
-        export = bb.data.getVarFlag(var, "export", d)
+        export = d.getVarFlag(var, "export")
         if export:
-            os.environ[var] = bb.data.getVar(var, d, True) or ""
+            os.environ[var] = d.getVar(var, True) or ""
 
 def remove(path, recurse=False):
     """Equivalent to rm -f or rm -rf"""

bitbake/lib/prserv/__init__.py

@@ -7,5 +7,8 @@ def init_logger(logfile, loglevel):
     numeric_level = getattr(logging, loglevel.upper(), None)
     if not isinstance(numeric_level, int):
         raise ValueError('Invalid log level: %s' % loglevel)
-    logging.basicConfig(level=numeric_level, filename=logfile)
+    FORMAT = '%(asctime)-15s %(message)s'
+    logging.basicConfig(level=numeric_level, filename=logfile, format=FORMAT)
 
+class NotFoundError(StandardError):
+    pass

bitbake/lib/prserv/db.py

@@ -1,86 +1,233 @@
 import logging
 import os.path
 import errno
-import sys
-import warnings
-import sqlite3
+import prserv
 
 try:
     import sqlite3
 except ImportError:
     from pysqlite2 import dbapi2 as sqlite3
 
+logger = logging.getLogger("BitBake.PRserv")
+
 sqlversion = sqlite3.sqlite_version_info
 if sqlversion[0] < 3 or (sqlversion[0] == 3 and sqlversion[1] < 3):
     raise Exception("sqlite3 version 3.3.0 or later is required.")
 
-class NotFoundError(StandardError):
-    pass
-
 class PRTable():
-    def __init__(self,cursor,table):
-        self.cursor = cursor
-        self.table = table
+    def __init__(self, conn, table, nohist):
+        self.conn = conn
+        self.nohist = nohist
+        if nohist:
+            self.table = "%s_nohist" % table 
+        else:
+            self.table = "%s_hist" % table 
 
-        #create the table
         self._execute("CREATE TABLE IF NOT EXISTS %s \
                     (version TEXT NOT NULL, \
+                    pkgarch TEXT NOT NULL,  \
                     checksum TEXT NOT NULL, \
                     value INTEGER, \
-                    PRIMARY KEY (version,checksum));"
-                      % table)
+                    PRIMARY KEY (version, pkgarch, checksum));" % self.table)
 
     def _execute(self, *query):
         """Execute a query, waiting to acquire a lock if necessary"""
         count = 0
         while True:
             try:
-                return self.cursor.execute(*query)
+                return self.conn.execute(*query)
             except sqlite3.OperationalError as exc:
                 if 'database is locked' in str(exc) and count < 500:
                     count = count + 1
                     continue
-                raise
-            except sqlite3.IntegrityError as exc:
-                print "Integrity error %s" % str(exc)
-                break
+                raise exc
 
-    def getValue(self, version, checksum):
-        data=self._execute("SELECT value FROM %s WHERE version=? AND checksum=?;" % self.table,
-                           (version,checksum))
+    def _getValueHist(self, version, pkgarch, checksum):
+        data=self._execute("SELECT value FROM %s WHERE version=? AND pkgarch=? AND checksum=?;" % self.table,
+                           (version, pkgarch, checksum))
         row=data.fetchone()
         if row != None:
             return row[0]
         else:
             #no value found, try to insert
-            self._execute("INSERT INTO %s VALUES (?, ?, (select ifnull(max(value)+1,0) from %s where version=?));" 
+            try:
+                self._execute("BEGIN")
+                self._execute("INSERT OR ROLLBACK INTO %s VALUES (?, ?, ?, (select ifnull(max(value)+1,0) from %s where version=? AND pkgarch=?));"
                            % (self.table,self.table),
-                           (version,checksum,version))
-            data=self._execute("SELECT value FROM %s WHERE version=? AND checksum=?;" % self.table,
-                               (version,checksum))
+                           (version,pkgarch, checksum,version, pkgarch))
+                self.conn.commit()
+            except sqlite3.IntegrityError as exc:
+                logger.error(str(exc))
+
+            data=self._execute("SELECT value FROM %s WHERE version=? AND pkgarch=? AND checksum=?;" % self.table,
+                               (version, pkgarch, checksum))
             row=data.fetchone()
             if row != None:
                 return row[0]
             else:
-                raise NotFoundError
+                raise prserv.NotFoundError
+
+    def _getValueNohist(self, version, pkgarch, checksum):
+        data=self._execute("SELECT value FROM %s \
+                            WHERE version=? AND pkgarch=? AND checksum=? AND \
+                            value >= (select max(value) from %s where version=? AND pkgarch=?);" 
+                            % (self.table, self.table),
+                            (version, pkgarch, checksum, version, pkgarch))
+        row=data.fetchone()
+        if row != None:
+            return row[0]
+        else:
+            #no value found, try to insert
+            try:
+                self._execute("BEGIN")
+                self._execute("INSERT OR REPLACE INTO %s VALUES (?, ?, ?, (select ifnull(max(value)+1,0) from %s where version=? AND pkgarch=?));"
+                               % (self.table,self.table),
+                               (version, pkgarch, checksum, version, pkgarch))
+                self.conn.commit()
+            except sqlite3.IntegrityError as exc:
+                logger.error(str(exc))
+                self.conn.rollback()
+
+            data=self._execute("SELECT value FROM %s WHERE version=? AND pkgarch=? AND checksum=?;" % self.table,
+                               (version, pkgarch, checksum))
+            row=data.fetchone()
+            if row != None:
+                return row[0]
+            else:
+                raise prserv.NotFoundError
+
+    def getValue(self, version, pkgarch, checksum):
+        if self.nohist:
+            return self._getValueNohist(version, pkgarch, checksum)
+        else:
+            return self._getValueHist(version, pkgarch, checksum)
+
+    def _importHist(self, version, pkgarch, checksum, value):
+        val = None 
+        data = self._execute("SELECT value FROM %s WHERE version=? AND pkgarch=? AND checksum=?;" % self.table,
+                           (version, pkgarch, checksum))
+        row = data.fetchone()
+        if row != None:
+            val=row[0]
+        else:
+            #no value found, try to insert
+            try:
+                self._execute("BEGIN")
+                self._execute("INSERT OR ROLLBACK INTO %s VALUES (?, ?, ?, ?);"  % (self.table),
+                           (version, pkgarch, checksum, value))
+                self.conn.commit()
+            except sqlite3.IntegrityError as exc:
+                logger.error(str(exc))
+
+            data = self._execute("SELECT value FROM %s WHERE version=? AND pkgarch=? AND checksum=?;" % self.table,
+                           (version, pkgarch, checksum))
+            row = data.fetchone()
+            if row != None:
+                val = row[0]
+        return val
+
+    def _importNohist(self, version, pkgarch, checksum, value):
+        try:
+            #try to insert
+            self._execute("BEGIN")
+            self._execute("INSERT OR ROLLBACK INTO %s VALUES (?, ?, ?, ?);"  % (self.table),
+                           (version, pkgarch, checksum,value))
+            self.conn.commit()
+        except sqlite3.IntegrityError as exc:
+            #already have the record, try to update
+            try:
+                self._execute("BEGIN")
+                self._execute("UPDATE %s SET value=? WHERE version=? AND pkgarch=? AND checksum=? AND value<?"  
+                              % (self.table),
+                               (value,version,pkgarch,checksum,value))
+                self.conn.commit()
+            except sqlite3.IntegrityError as exc:
+                logger.error(str(exc))
+
+        data = self._execute("SELECT value FROM %s WHERE version=? AND pkgarch=? AND checksum=? AND value>=?;" % self.table,
+                            (version,pkgarch,checksum,value))
+        row=data.fetchone()
+        if row != None:
+            return row[0]
+        else:
+            return None
+
+    def importone(self, version, pkgarch, checksum, value):
+        if self.nohist:
+            return self._importNohist(version, pkgarch, checksum, value)
+        else:
+            return self._importHist(version, pkgarch, checksum, value)
+
+    def export(self, version, pkgarch, checksum, colinfo):
+        metainfo = {}
+        #column info 
+        if colinfo:
+            metainfo['tbl_name'] = self.table
+            metainfo['core_ver'] = prserv.__version__
+            metainfo['col_info'] = []
+            data = self._execute("PRAGMA table_info(%s);" % self.table)
+            for row in data:
+                col = {}
+                col['name'] = row['name']
+                col['type'] = row['type']
+                col['notnull'] = row['notnull']
+                col['dflt_value'] = row['dflt_value']
+                col['pk'] = row['pk']
+                metainfo['col_info'].append(col)
+
+        #data info
+        datainfo = []
+
+        if self.nohist:
+            sqlstmt = "SELECT T1.version, T1.pkgarch, T1.checksum, T1.value FROM %s as T1, \
+                    (SELECT version,pkgarch,max(value) as maxvalue FROM %s GROUP BY version,pkgarch) as T2 \
+                    WHERE T1.version=T2.version AND T1.pkgarch=T2.pkgarch AND T1.value=T2.maxvalue " % (self.table, self.table)
+        else:
+            sqlstmt = "SELECT * FROM %s as T1 WHERE 1=1 " % self.table
+        sqlarg = []
+        where = ""
+        if version:
+            where += "AND T1.version=? "
+            sqlarg.append(str(version))
+        if pkgarch:
+            where += "AND T1.pkgarch=? "
+            sqlarg.append(str(pkgarch))
+        if checksum:
+            where += "AND T1.checksum=? "
+            sqlarg.append(str(checksum))
+
+        sqlstmt += where + ";"
+
+        if len(sqlarg):
+            data = self._execute(sqlstmt, tuple(sqlarg))
+        else:
+            data = self._execute(sqlstmt)
+        for row in data:
+            if row['version']:
+                col = {}
+                col['version'] = row['version']
+                col['pkgarch'] = row['pkgarch']
+                col['checksum'] = row['checksum']
+                col['value'] = row['value']
+                datainfo.append(col)
+        return (metainfo, datainfo)
 
 class PRData(object):
     """Object representing the PR database"""
-    def __init__(self, filename):
+    def __init__(self, filename, nohist=True):
         self.filename=os.path.abspath(filename)
+        self.nohist=nohist
         #build directory hierarchy
         try:
             os.makedirs(os.path.dirname(self.filename))
         except OSError as e:
             if e.errno != errno.EEXIST:
                 raise e
-        self.connection=sqlite3.connect(self.filename, timeout=5,
-                                          isolation_level=None)
-        self.cursor=self.connection.cursor()
+        self.connection=sqlite3.connect(self.filename, isolation_level="DEFERRED")
+        self.connection.row_factory=sqlite3.Row
         self._tables={}
 
     def __del__(self):
-        print "PRData: closing DB %s" % self.filename
         self.connection.close()
 
     def __getitem__(self,tblname):
@@ -90,11 +237,11 @@ class PRData(object):
         if tblname in self._tables:
             return self._tables[tblname]
         else:
-            tableobj = self._tables[tblname] = PRTable(self.cursor, tblname)
+            tableobj = self._tables[tblname] = PRTable(self.connection, tblname, self.nohist)
             return tableobj
 
     def __delitem__(self, tblname):
         if tblname in self._tables:
             del self._tables[tblname]
-        logging.info("drop table %s" % (tblname))
-        self.cursor.execute("DROP TABLE IF EXISTS %s;" % tblname) 
+        logger.info("drop table %s" % (tblname))
+        self.connection.execute("DROP TABLE IF EXISTS %s;" % tblname) 

bitbake/lib/prserv/serv.py

@@ -1,5 +1,5 @@
 import os,sys,logging
-import signal,time, atexit
+import signal, time, atexit, threading
 from SimpleXMLRPCServer import SimpleXMLRPCServer, SimpleXMLRPCRequestHandler
 import xmlrpclib,sqlite3
 
@@ -7,6 +7,8 @@ import bb.server.xmlrpc
 import prserv
 import prserv.db
 
+logger = logging.getLogger("BitBake.PRserv")
+
 if sys.hexversion < 0x020600F0:
     print("Sorry, python 2.6 or later is required.")
     sys.exit(1)
@@ -21,8 +23,10 @@ class Handler(SimpleXMLRPCRequestHandler):
             raise
         return value
 
+PIDPREFIX = "/tmp/PRServer_%s_%s.pid"
+singleton = None
+
 class PRServer(SimpleXMLRPCServer):
-    pidfile="/tmp/PRServer.pid"
     def __init__(self, dbfile, logfile, interface, daemon=True):
         ''' constructor '''
         SimpleXMLRPCServer.__init__(self, interface,
@@ -31,66 +35,88 @@ class PRServer(SimpleXMLRPCServer):
         self.dbfile=dbfile
         self.daemon=daemon
         self.logfile=logfile
+        self.working_thread=None
         self.host, self.port = self.socket.getsockname()
         self.db=prserv.db.PRData(dbfile)
         self.table=self.db["PRMAIN"]
+        self.pidfile=PIDPREFIX % (self.host, self.port)
 
         self.register_function(self.getPR, "getPR")
         self.register_function(self.quit, "quit")
         self.register_function(self.ping, "ping")
+        self.register_function(self.export, "export")
+        self.register_function(self.importone, "importone")
         self.register_introspection_functions()
 
+    def export(self, version=None, pkgarch=None, checksum=None, colinfo=True):
+        try:
+            return self.table.export(version, pkgarch, checksum, colinfo)
+        except sqlite3.Error as exc:
+            logger.error(str(exc))
+            return None
+
+    def importone(self, version, pkgarch, checksum, value):
+        return self.table.importone(version, pkgarch, checksum, value)
+
     def ping(self):
         return not self.quit
- 
-    def getPR(self, version, checksum):
+
+    def getinfo(self):
+        return (self.host, self.port)
+
+    def getPR(self, version, pkgarch, checksum):
         try:
-            return self.table.getValue(version,checksum)
+            return self.table.getValue(version, pkgarch, checksum)
         except prserv.NotFoundError:
-            logging.error("can not find value for (%s, %s)",version,checksum)
+            logger.error("can not find value for (%s, %s)",version, checksum)
             return None
         except sqlite3.Error as exc:
-            logging.error(str(exc))
+            logger.error(str(exc))
             return None
 
     def quit(self):
         self.quit=True
         return
 
-    def _serve_forever(self):
+    def work_forever(self,):
         self.quit = False
         self.timeout = 0.5
+        logger.info("PRServer: started! DBfile: %s, IP: %s, PORT: %s, PID: %s" %
+                     (self.dbfile, self.host, self.port, str(os.getpid())))
+
         while not self.quit:
             self.handle_request()
 
-        logging.info("PRServer: stopping...")
+        logger.info("PRServer: stopping...")
         self.server_close()
         return
 
     def start(self):
         if self.daemon is True:
-            logging.info("PRServer: starting daemon...")
+            logger.info("PRServer: try to start daemon...")
             self.daemonize()
         else:
-            logging.info("PRServer: starting...")
-            self._serve_forever()
+            atexit.register(self.delpid)
+            pid = str(os.getpid()) 
+            pf = file(self.pidfile, 'w+')
+            pf.write("%s\n" % pid)
+            pf.close()
+            self.work_forever()
 
     def delpid(self):
-        os.remove(PRServer.pidfile)
+        os.remove(self.pidfile)
 
     def daemonize(self):
         """
         See Advanced Programming in the UNIX, Sec 13.3
         """
-        os.umask(0)
-
         try:
             pid = os.fork()
-            if pid > 0: 
-                sys.exit(0)
+            if pid > 0:
+                #parent return instead of exit to give control 
+                return
         except OSError as e:
-            sys.stderr.write("1st fork failed: %d %s\n" % (e.errno, e.strerror))
-            sys.exit(1)
+            raise Exception("%s [%d]" % (e.strerror, e.errno))
 
         os.setsid()
         """
@@ -102,9 +128,9 @@ class PRServer(SimpleXMLRPCServer):
             if pid > 0: #parent
                 sys.exit(0)
         except OSError as e:
-            sys.stderr.write("2nd fork failed: %d %s\n" % (e.errno, e.strerror))
-            sys.exit(1)
+            raise Exception("%s [%d]" % (e.strerror, e.errno))
 
+        os.umask(0)
         os.chdir("/")
 
         sys.stdout.flush()
@@ -119,19 +145,44 @@ class PRServer(SimpleXMLRPCServer):
         # write pidfile
         atexit.register(self.delpid)
         pid = str(os.getpid()) 
-        pf = file(PRServer.pidfile, 'w+')
+        pf = file(self.pidfile, 'w')
         pf.write("%s\n" % pid)
-        pf.write("%s\n" % self.host)
-        pf.write("%s\n" % self.port)
         pf.close()
 
-        self._serve_forever()
+        self.work_forever()
+        sys.exit(0)
+
+class PRServSingleton():
+    def __init__(self, dbfile, logfile, interface):
+        self.dbfile = dbfile
+        self.logfile = logfile
+        self.interface = interface
+        self.host = None
+        self.port = None
+        self.event = threading.Event()
+
+    def _work(self):
+        self.prserv = PRServer(self.dbfile, self.logfile, self.interface, False)
+        self.host, self.port = self.prserv.getinfo()
+        self.event.set()
+        self.prserv.work_forever()
+        del self.prserv.db
+
+    def start(self):
+        self.working_thread = threading.Thread(target=self._work)
+        self.working_thread.start()
+
+    def getinfo(self):
+        self.event.wait()
+        return (self.host, self.port)
 
 class PRServerConnection():
     def __init__(self, host, port):
-        self.connection = bb.server.xmlrpc._create_server(host, port)
+        if is_local_special(host, port):
+            host, port = singleton.getinfo()
         self.host = host
         self.port = port
+        self.connection = bb.server.xmlrpc._create_server(self.host, self.port)
 
     def terminate(self):
         # Don't wait for server indefinitely
@@ -139,18 +190,25 @@ class PRServerConnection():
         socket.setdefaulttimeout(2)
         try:
             self.connection.quit()
-        except:
-            pass
+        except Exception as exc:
+            sys.stderr.write("%s\n" % str(exc))
 
-    def getPR(self, version, checksum):
-        return self.connection.getPR(version, checksum)
+    def getPR(self, version, pkgarch, checksum):
+        return self.connection.getPR(version, pkgarch, checksum)
 
     def ping(self):
         return self.connection.ping()
 
-def start_daemon(options):
+    def export(self,version=None, pkgarch=None, checksum=None, colinfo=True):
+        return self.connection.export(version, pkgarch, checksum, colinfo)
+
+    def importone(self, version, pkgarch, checksum, value):
+        return self.connection.importone(version, pkgarch, checksum, value)
+
+def start_daemon(dbfile, host, port, logfile):
+    pidfile = PIDPREFIX % (host, port)
     try:
-        pf = file(PRServer.pidfile,'r')
+        pf = file(pidfile,'r')
         pid = int(pf.readline().strip())
         pf.close()
     except IOError:
@@ -158,41 +216,89 @@ def start_daemon(options):
 
     if pid:
         sys.stderr.write("pidfile %s already exist. Daemon already running?\n"
-                            % PRServer.pidfile)
-        sys.exit(1)
+                            % pidfile)
+        return 1
 
-    server = PRServer(options.dbfile, interface=(options.host, options.port),
-                      logfile=os.path.abspath(options.logfile))
+    server = PRServer(os.path.abspath(dbfile), os.path.abspath(logfile), (host,port))
     server.start()
+    return 0
 
-def stop_daemon():
+def stop_daemon(host, port):
+    pidfile = PIDPREFIX % (host, port)
     try:
-        pf = file(PRServer.pidfile,'r')
+        pf = file(pidfile,'r')
         pid = int(pf.readline().strip())
-        host = pf.readline().strip()
-        port = int(pf.readline().strip())
         pf.close()
     except IOError:
         pid = None
 
     if not pid:
         sys.stderr.write("pidfile %s does not exist. Daemon not running?\n"
-                        % PRServer.pidfile)
-        sys.exit(1)
+                        % pidfile)
 
-    PRServerConnection(host,port).terminate()
+    try:
+        PRServerConnection(host, port).terminate()
+    except:
+        logger.critical("Stop PRService %s:%d failed" % (host,port))
     time.sleep(0.5)
 
     try:
-        while 1:
+        if pid:
+            if os.path.exists(pidfile):
+                os.remove(pidfile)
             os.kill(pid,signal.SIGTERM)
             time.sleep(0.1)
-    except OSError as err:
-        err = str(err)
-        if err.find("No such process") > 0:
-            if os.path.exists(PRServer.pidfile):
-                os.remove(PRServer.pidfile)
-        else:
-            print err
-            sys.exit(1)
+    except OSError as e:
+        err = str(e)
+        if err.find("No such process") <= 0:
+            raise e
 
+    return 0
+
+def is_local_special(host, port):
+    if host.strip().upper() == 'localhost'.upper() and (not port):
+        return True
+    else:
+        return False
+
+def auto_start(d):
+    global singleton
+    if d.getVar('USE_PR_SERV', True) == '0':
+        return True
+
+    if is_local_special(d.getVar('PRSERV_HOST', True), int(d.getVar('PRSERV_PORT', True))) and not singleton:
+        import bb.utils
+        cachedir = (d.getVar("PERSISTENT_DIR", True) or d.getVar("CACHE", True))
+        if not cachedir:
+            logger.critical("Please set the 'PERSISTENT_DIR' or 'CACHE' variable")
+            sys.exit(1)
+        bb.utils.mkdirhier(cachedir)
+        dbfile = os.path.join(cachedir, "prserv.sqlite3")
+        logfile = os.path.join(cachedir, "prserv.log")
+        singleton = PRServSingleton(os.path.abspath(dbfile), os.path.abspath(logfile), ("localhost",0))
+        singleton.start()
+    if singleton:
+        host, port = singleton.getinfo()
+    else:
+        host = d.getVar('PRSERV_HOST', True)
+        port = int(d.getVar('PRSERV_PORT', True))
+
+    try:
+        return PRServerConnection(host,port).ping()
+    except Exception:
+        logger.critical("PRservice %s:%d not available" % (host, port))
+    return False
+
+def auto_shutdown(d=None):
+    global singleton
+    if singleton:
+        host, port = singleton.getinfo()
+        try:
+            PRServerConnection(host, port).terminate()
+        except:
+            logger.critical("Stop PRService %s:%d failed" % (host,port))
+        singleton = None
+
+def ping(host, port):
+    conn=PRServerConnection(host, port)
+    return conn.ping()

documentation/Makefile

@@ -69,7 +69,8 @@ ALLPREQ = html pdf tarball
 TARFILES = style.css dev-manual.html dev-manual.pdf figures/bsp-dev-flow.png figures/dev-title.png \
            figures/git-workflow.png figures/index-downloads.png figures/kernel-dev-flow.png \
            figures/kernel-example-repos.png figures/kernel-overview-1.png figures/kernel-overview-2.png \
-           figures/kernel-overview-3.png figures/source-repos.png figures/yp-download.png
+           figures/kernel-overview-3.png figures/source-repos.png figures/yp-download.png \
+           figures/wip.png
 MANUALS = $(DOC)/$(DOC).html $(DOC)/$(DOC).pdf
 FIGURES = figures
 STYLESHEET = $(DOC)/*.css

documentation/adt-manual/adt-command.xml

@@ -28,7 +28,7 @@
 <title>Autotools-Based Projects</title>
 
     <para>
-        For an autotools-based project, you can use the cross-toolchain by just 
+        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 
@@ -47,6 +47,20 @@
         This single command updates your project and rebuilds it using the appropriate 
         cross-toolchain tools.
     </para>
+    <note>
+        If <filename>configure</filename> script results in problems recognizing the 
+        <filename>--with-libtool-sysroot=&lt;sysroot-dir&gt;</filename> option, 
+        regenerate the script to enable the support by doing the following and then 
+        re-running the script:
+        <literallayout class='monospaced'>
+     $ libtoolize --automake
+     $ aclocal -I ${OECORE_NATIVE_SYSROOT}/usr/share/aclocal \
+        [-I &lt;dir_containing_your_project-specific_m4_macros&gt;]
+     $ autoconf
+     $ autoheader
+     $ automake -a
+        </literallayout>
+    </note>       
 </section>
 
 <section id='makefile-based-projects'>

documentation/adt-manual/adt-eclipse.xml

@@ -29,8 +29,7 @@
     <para>
         To develop within the Eclipse IDE, you need to do the following:
         <orderedlist>
-            <listitem><para>Be sure the optimal version of the Eclipse IDE 
-                is installed.</para></listitem>
+            <listitem><para>Install the optimal version of the Eclipse IDE.</para></listitem>
             <listitem><para>Configure the Eclipse IDE.</para></listitem>
             <listitem><para>Install the Eclipse Yocto Plug-in.</para></listitem>
             <listitem><para>Configure the Eclipse Yocto Plug-in.</para></listitem>
@@ -55,7 +54,7 @@
             Once you have downloaded the tarball, extract it into a clean 
             directory.
             For example, the following command unpacks and installs the Eclipse IDE
-            into a clean directory named <filename>eclipse</filename>:
+            into a clean directory using the default name <filename>eclipse</filename>:
             <literallayout class='monospaced'>
      $ tar -xzvf ~/Downloads/Eclipse-SDK-3.7-linux-gtk-x86_64.tar.gz
             </literallayout>
@@ -96,16 +95,18 @@
             Follow these general steps to configure Eclipse:
             <orderedlist>
                 <listitem><para>Start the Eclipse IDE.</para></listitem>
-                <listitem><para>Select "Install New Software" from the "Help" pull-down menu.
+                <listitem><para>Make sure you are in your Workbench and select 
+                    "Install New Software" from the "Help" pull-down menu.
                     </para></listitem>
-                <listitem><para>Select <filename>Indego - http://download.eclipse.org/releases/indego</filename>
+                <listitem><para>Select <filename>indigo - http://download.eclipse.org/releases/indigo</filename>
                     from the "Work with:" pull-down menu.</para></listitem>
                 <listitem><para>Expand the box next to <filename>Programming Languages</filename>
                     and select the <filename>Autotools Support for CDT (incubation)</filename>
                     and <filename>C/C++ Development Tools</filename> boxes.</para></listitem>
                 <listitem><para>Complete the installation and restart the Eclipse IDE.</para></listitem>
-                <listitem><para>Select "Install New Software" from the "Help" pull-down menu.</para></listitem>
-                <listitem><para>After the Eclipse IDE restarts, click the 
+                <listitem><para>After the Eclipse IDE restarts and from the Workbench, select 
+                    "Install New Software" from the "Help" pull-down menu.</para></listitem>
+                <listitem><para>Click the 
                     "Available Software Sites" link.</para></listitem>
                 <listitem><para>Check the box next to 
                     <filename>http://download.eclipse.org/tm/updates/3.3</filename>
@@ -118,12 +119,13 @@
                     and select every item except <filename>RSE Unit Tests</filename> and 
                     <filename>RSE WinCE Services (incubation)</filename>.</para></listitem>
                 <listitem><para>Complete the installation and restart the Eclipse IDE.</para></listitem>
-                <listitem><para>After the Eclipse IDE restarts, click the 
-                    "Available Software Sites" link.</para></listitem>
-                <listitem><para>Check the box next to 
-                    <filename>http://download.eclipse.org/tools/cdt/releases/indego</filename>
+                <listitem><para>If necessary, select 
+                    "Install New Software" from the "Help" pull-down menu so you can click the 
+                    "Available Software Sites" link again.</para></listitem>
+                <listitem><para>After clicking "Available Software Sites", check the box next to 
+                    <filename>http://download.eclipse.org/tools/cdt/releases/indigo</filename>
                     and click "OK".</para></listitem>
-                <listitem><para>Select <filename>http://download.eclipse.org/tools/cdt/releases/indego</filename>
+                <listitem><para>Select <filename>http://download.eclipse.org/tools/cdt/releases/indigo</filename>
                     from the "Work with:" pull-down menu.</para></listitem>
                 <listitem><para>Check the box next to <filename>CDT Main Features</filename>.
                     </para></listitem>
@@ -139,36 +141,128 @@
     <title>Installing the Eclipse Yocto Plug-in</title>
 
         <para>
-            To install the Eclipse Yocto Plug-in, follow these special steps.  
-            The steps are WIP and are not final. 
-            Once they are final they will be replaced with the actual steps:
-            <orderedlist>
-                <listitem><para>Open a shell and create a Git repository with:
-                    <literallayout class='monospaced'>
-     $ git clone git://git.yoctoproject.org/yocto-eclipse yocto-eclipse
-                    </literallayout></para></listitem>
-                <listitem><para>In Eclipse, select "Import" from the "File" menu.</para></listitem>
-                <listitem><para>Expand the "General" box and pick "existing projects into workspace".
-                    </para></listitem>
-                <listitem><para>Select the root directory and browse to "~/yocto-eclipse/plugins".
-                    </para></listitem>
-                <listitem><para>There will be three things there.
-                    Select each one and install one at a time.
-                    Do all three.</para></listitem>
-                <listitem><para>Restart everything.</para></listitem>
-            </orderedlist>
+            You can install the Eclipse Yocto Plug-in one of three methods: as new software
+            from within the Eclipse IDE, from the Yocto Project source repositories, or as a built zip file.
         </para>
 
-        <para>
-            At this point I should be able to invoke Eclipse from the shell using the following:
-                    <literallayout class='monospaced'>
+        <section id='new-software'>
+        <title>New Software</title>
+
+            <para>
+                To install the Eclipse Yocto Plug-in directly into the Eclipse IDE, 
+                follow these steps:
+                <orderedlist>
+                    <listitem><para>Start up the Eclipse IDE.</para></listitem>
+                    <listitem><para>In Eclipse, select "Install New Software" from the "Help" menu.</para></listitem>
+                    <listitem><para>Click "Add..." in the "Work with:" area.</para></listitem>
+                    <listitem><para>Enter 
+                        <filename>http://www.yoctoproject.org/downloads/eclipse-plugin/1.1</filename> 
+                        in the URL field and provide a meaningful name in the "Name" field.</para></listitem>
+                    <listitem><para>Click "OK" to have the entry added to the "Work with:" 
+                        drop-down list.</para></listitem>
+                    <listitem><para>Select the entry for the plug-in from the "Work with:" drop-down 
+                        list.</para></listitem>
+                    <listitem><para>Complete the remaining software installation steps and 
+                        then restart the Eclipse IDE to finish the installation of the plug-in.
+                        </para></listitem>
+                </orderedlist>
+            </para>
+        </section>
+
+
+        <section id='yocto-project-source'>
+        <title>Yocto Project Source</title>
+
+            <para>
+                To install the Eclipse Yocto Plug-in from the Yocto Project source repositories, 
+                follow these steps:
+                <orderedlist>
+                    <listitem><para>Open a shell and create a Git repository with:
+                        <literallayout class='monospaced'>
+     $ git clone git://git.yoctoproject.org/eclipse-poky yocto-eclipse
+                        </literallayout>
+                        For this example, the repository is named 
+                        <filename>~/yocto-eclipse</filename>.</para></listitem>
+                    <listitem><para>In Eclipse, select "Import" from the "File" menu.</para></listitem>
+                    <listitem><para>Expand the "General" box and pick "existing projects into workspace".
+                        </para></listitem>
+                    <listitem><para>Select the root directory and browse to "~/yocto-eclipse/plugins".
+                        </para></listitem>
+                    <listitem><para>There will be three things there.
+                        Select each one and install one at a time.
+                        Do all three.</para></listitem>
+                    <listitem><para>Restart everything.</para></listitem>
+                </orderedlist>
+            </para>
+
+            <para>
+                At this point you should be able to invoke Eclipse from the shell using the following:
+                <literallayout class='monospaced'>
      $ cd ~/eclipse
      $ ./eclipse -vmargs -XX:PermSize=256M
-                    </literallayout>
-            What is shown is the default projects in the left pane. 
-            I should be able to right-click on one of these and run as an Eclipse application to 
-           bring up the Eclipse instance again with the Eclipse Yocto Plug-in working.
-       </para>            
+                </literallayout>
+                The left navigation pane shows the default projects. 
+                Right-click on one of these projects and run it as an Eclipse application.
+                This brings up a second instance of Eclipse IDE that has the Yocto Plug-in.
+           </para>
+       </section>
+
+       <section id='zip-file-method'>
+       <title>Zip File Method</title>
+            <para>
+                To install the Eclipse Yocto Plug-in by building and installing a plug-in 
+                zip file, follow these steps:
+                <orderedlist>
+                    <listitem><para>Open a shell and create a Git repository with:
+                        <literallayout class='monospaced'>
+     $ git clone git://git.yoctoproject.org/eclipse-poky yocto-eclipse
+                        </literallayout>
+                        For this example, the repository is named     
+                        <filename>~/yocto-eclipse</filename>.</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.
+                        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:
+                        <literallayout class='monospaced'>
+     $ scripts/build.sh master 1.1M4 
+                        </literallayout>
+                        After running the script, the file
+                        <filename>org.yocto.sdk-&lt;release&gt;-&lt;date&gt;-archive.zip</filename>
+                        is in the current directory.</para></listitem>
+                    <listitem><para>If necessary, start the Eclipse IDE and be sure you are in the 
+                        Workbench.</para></listitem>
+                    <listitem><para>Select "Install New Software" from the "Help" pull-down menu.
+                        </para></listitem>
+                    <listitem><para>Click "Add".</para></listitem>
+                    <listitem><para>Provide anything you want in the "Name" field.</para></listitem>
+                    <listitem><para>For the "Archive" field, select the ZIP file you built in step 
+                        4.
+                        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>Select the new entry in the installation window and complete
+                        the installation.</para></listitem>
+                    <listitem><para>Restart the Eclipse IDE if necessary.</para></listitem>
+                </orderedlist>
+            </para>
+
+            <para>
+                At this point you should be able to configure the Eclipse Yocto Plug-in as described in
+                the next section.
+           </para>
+       </section>            
     </section>
 
     <section id='configuring-the-eclipse-yocto-plug-in'>
@@ -186,7 +280,7 @@
             To start, you need to do the following from within the Eclipse IDE:
             <itemizedlist>
                 <listitem><para>Choose <filename>Windows -&gt; Preferences</filename> to display 
-                    the Preferences Dialog</para></listitem>
+                    the <filename>Preferences</filename> Dialog</para></listitem>
                 <listitem><para>Click <filename>Yocto ADT</filename></para></listitem>
             </itemizedlist>
         </para>
@@ -223,12 +317,12 @@
                         </para></listitem>
                     <listitem><para><emphasis>Point to the Toolchain:</emphasis>
                         If you are using a stand-alone pre-built toolchain, you should be pointing to the
-                        <filename>/opt/poky/$SDKVERSION</filename> directory.
+                        <filename>/opt/poky/1.1</filename> directory.
                         This is the location for toolchains installed by the ADT Installer or by hand.
-                        Sections <link linkend='configuring-and-running-the-adt-installer-script'>
-                        Configuring and Running the ADT Installer Script</link> and 
-                        <link linkend='using-an-existing-toolchain-tarball'>
-                        Using a Cross-Toolchain Tarball</link> describe two ways to install
+                        Sections "<link linkend='configuring-and-running-the-adt-installer-script'>Configuring 
+                        and Running the ADT Installer Script</link>" and 
+                        "<link linkend='using-an-existing-toolchain-tarball'>Using a Cross-Toolchain 
+                        Tarball</link>" describe two ways to install
                         a stand-alone cross-toolchain in the 
                         <filename>/opt/poky</filename> directory.
                         <note>It is possible to install a stand-alone cross-toolchain in a directory
@@ -237,8 +331,8 @@
                         <para>If you are using a system-derived toolchain, the path you provide 
                         for the <filename>Toolchain Root Location</filename>
                         field is the Yocto Project's build directory.
-                        See section <link linkend='using-the-toolchain-from-within-the-build-tree'>
-                        Using BitBake and the Yocto Project Build Tree</link> for 
+                        See section "<link linkend='using-the-toolchain-from-within-the-build-tree'>Using 
+                        BitBake and the Yocto Project Build Tree</link>" for 
                         information on how to install the toolchain into the Yocto 
                         Project build tree.</para></listitem> 
                     <listitem><para><emphasis>Specify the Sysroot Location:</emphasis>
@@ -255,9 +349,8 @@
                         The pull-down menu should have the supported architectures.  
                         If the architecture you need is not listed in the menu, you 
                         will need to build the image.
-                        See the 
-                        <ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#building-image'> Building an Image</ulink> section of the  
-                        <ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html'>
+                        See the "<ulink url='http://www.yoctoproject.org/docs/latest/yocto-project-qs/yocto-project-qs.html#building-image'>Building an Image</ulink>" section of the  
+                        <ulink url='http://www.yoctoproject.org/docs/latest/yocto-project-qs/yocto-project-qs.html'>
                         The Yocto Project Quick Start</ulink> for more information.</para></listitem>
                 </itemizedlist>
             </para>
@@ -350,21 +443,24 @@
 <title>Configuring the Cross-Toolchains</title>
 
     <para>
-        The previous section, "<link linkend='configuring-the-eclipse-yocto-plug-in'>
-        Configuring the Eclipse Yocto Plug-in</link>", set up the default project 
+        The earlier section, "<link linkend='configuring-the-eclipse-yocto-plug-in'>Configuring 
+        the Eclipse Yocto Plug-in</link>", sets up the default project 
         configurations.  
-        You can change these settings for a given project by following these steps:
+        You can override these settings for a given project by following these steps:
         <orderedlist>
-            <listitem><para>Select <filename>Window -&gt; Preferences</filename>:  
-                This selection brings up the <filename>Preferences</filename> Dialog.  
-                If the Yocto ADT Preferences are not automatically displayed, you can navigate to 
-                that dialog by selection <filename>Yocto ADT</filename> in the left-hand 
-                panel.</para>
-                <para>Yocto ADT Settings are inherited from the default project configuration.  
-                The information in this dialog is identical to that chosen earlier 
-                for the Cross Compiler Options and Target Options as described in 
-                <link linkend='configuring-the-eclipse-yocto-plug-in'>
-                Configuring the Eclipse Yocto Plug-in</link> section.</para></listitem>
+            <listitem><para>Select <filename>Project -&gt; Change Yocto Project Settings</filename>:  
+                This selection brings up the <filename>Project Yocto Settings</filename> Dialog
+                and allows you to make changes specific to an individual project.  
+                </para>
+                <para>By default, the Cross Compiler Options and Target Options for a project
+                are inherited from settings you provide using the <filename>Preferences</filename>
+                Dialog as described earlier 
+                in the "<link linkend='configuring-the-eclipse-yocto-plug-in'>Configuring the Eclipse 
+                Yocto Plug-in</link>" section.
+                The <filename>Project Yocto Settings</filename>
+                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>Select <filename>Project -&gt; Reconfigure Project</filename>:   
                 This selection reconfigures the project by running
                 <filename>autogen.sh</filename> in the workspace for your project.  
@@ -391,20 +487,20 @@
     <para>
         To start the QEMU emulator from within Eclipse, follow these steps:
         <orderedlist>
-            <listitem><para>Expose the <filename>Run -&gt; External Tools -&gt; External Tools 
-                Configurations...</filename> menu.
+            <listitem><para>Expose the <filename>Run -&gt; External Tools</filename> menu.
                 Your image should appear as a selectable menu item.
                 </para></listitem>
-            <listitem><para>Select your image from the menu.
-                Doing so launches a new window.</para></listitem>
-            <listitem><para>Enter your host root password in the shell window at the prompt.  
+            <listitem><para>Select your image in the navigation pane to launch the 
+                emulator in a new window.</para></listitem>
+            <listitem><para>If needed, enter your host root password in the shell window at the prompt.  
                 This sets up a <filename>Tap 0</filename> connection needed for running in user-space 
                 NFS mode.</para></listitem>
             <listitem><para>Wait for QEMU to launch.</para></listitem>
-            <listitem><para>Once QEMU launches you need to determine the IP Address 
-                for the user-space NFS.  
-                You can do that by going to a terminal in the QEMU and entering the 
-            <filename>ifconfig</filename> command.</para></listitem>
+            <listitem><para>Once QEMU launches, you can begin operating within that 
+                environment.
+                For example, you could determine the IP Address 
+                for the user-space NFS by using the <filename>ifconfig</filename> command.
+                </para></listitem>
         </orderedlist>
     </para>
 </section>
@@ -435,8 +531,8 @@
             <listitem><para>Click <filename>Next</filename>.</para></listitem>
             <listitem><para>Clear out the <filename>host name</filename> field and enter the IP Address 
                 determined earlier.</para></listitem>
-            <listitem><para>Click <filename>Finish</filename> to close the new connections 
-                Dialog.</para></listitem>
+            <listitem><para>Click <filename>Finish</filename> to close the 
+                <filename>New Connections</filename> Dialog.</para></listitem>
             <listitem><para>Use the drop-down menu now in the <filename>Connection</filename> field and pick 
                 the IP Address you entered.</para></listitem>
             <listitem><para>Click <filename>Debug</filename> to bring up a login screen 

documentation/adt-manual/adt-manual.xml

@@ -31,12 +31,17 @@
             <revision>
                 <revnumber>1.0</revnumber>
                 <date>6 April 2011</date>
-                <revremark>Initial Document released with Yocto Project 1.0 on 6 April 2011.</revremark>
+                <revremark>Released with the Yocto Project 1.0 Release.</revremark>
             </revision>
             <revision>
                 <revnumber>1.0.1</revnumber>
                 <date>23 May 2011</date>
-                <revremark>Released with Yocto Project 1.0.1 on 23 May 2011.</revremark>
+                <revremark>Released with the Yocto Project 1.0.1 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.1</revnumber>
+                <date>6 October 2011</date>
+                <revremark>Released with the Yocto Project 1.1 Release.</revremark>
             </revision>
         </revhistory>
 
@@ -53,7 +58,7 @@
       <note>
           Due to production processes, there could be differences between the Yocto Project
           documentation bundled in the release tarball and the 
-          <ulink url='http://www.yoctoproject.org/docs/1.1/adt-manual/adt-manual.html'>
+          <ulink url='http://www.yoctoproject.org/docs/latest/adt-manual/adt-manual.html'>
           Application Developer's Toolkit (ADT) User's Guide</ulink> on
           the <ulink url='http://www.yoctoproject.org'>Yocto Project</ulink> website.
           For the latest version of this manual, see the manual on the website.

documentation/adt-manual/adt-package.xml

@@ -54,8 +54,8 @@
 
     <note>
         For build performance information related to the PMS, see
-        <ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html#ref-classes-package'>Packaging - <filename>package*.bbclass</filename></ulink> 
-        in <ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html'>
+        <ulink url='http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html#ref-classes-package'>Packaging - <filename>package*.bbclass</filename></ulink> 
+        in <ulink url='http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html'>
         The Yocto Project Reference Manual</ulink>.
     </note>
 

documentation/adt-manual/adt-prepare.xml

@@ -9,60 +9,9 @@
     In order to use the ADT, you must install it, <filename>source</filename> a script to set up the 
     environment, and be sure both the kernel and filesystem image specific to the target architecture 
     exist. 
+    This chapter describes how to be sure you meet the ADT requirements.
 </para>
 
-<para> 
-    This chapter describes two important terms and how to be sure you meet the ADT requirements.
-</para>
-
-<section id='yocto-project-files'>
-    <title>Yocto Project Files and Build Areas</title>
-
-    <para>
-        Before learning how to prepare your system for the ADT, you need to understand
-        two important terms used throughout this manual:
-        <itemizedlist>
-            <listitem><para><emphasis>The Yocto Project Files:</emphasis>
-                This term refers to the directory structure created as a result of downloading 
-                and unpacking a Yocto Project release tarball or setting up a Git repository
-                by cloning <filename>git://git.yoctoproject.org/poky</filename>.</para>
-                <para>The Yocto Project files contain BitBake, Documentation, metadata and 
-                other files that all support the development environment. 
-                Consequently, you must have the Yocto Project files in place on your development 
-                system in order to do any development using the Yocto Project.</para>
-                <para>The name of the top-level directory of the Yocto Project file structure  
-                is derived from the Yocto Project release tarball.
-                For example, downloading and unpacking <filename>poky-edison-6.0.tar.bz2</filename>
-                results in a Yocto Project source tree whose Yocto Project source directory is named 
-                <filename>poky-edison-6.0</filename>.
-                If you create a Git repository, then you can name the repository anything you like.</para>
-                <para>You can find instruction on how to set up the Yocto Project files on your 
-                host development system by reading the 
-                <ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html#getting-setup'>
-                Getting Setup</ulink> section in
-                <ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html'>
-                The Yocto Project Development Manual</ulink>.</para></listitem>
-            <listitem><para><emphasis>Yocto Project Build Tree:</emphasis>
-                This term refers to the area where the Yocto Project builds images.  
-                The area is created when you <filename>source</filename> the Yocto Project setup 
-                environment script that is found in the Yocto Project files area. 
-                (e.g. <filename>oe-init-build-env</filename>).
-                You can create the Yocto Project build tree anywhere you want on your 
-                development system.
-                Here is an example that creates the tree in <filename>mybuilds</filename> 
-                and names the Yocto Project build directory <filename>YP-6.0</filename>:
-                <literallayout class='monospaced'> 
-     $ source poky-edison-6.0/oe-init-build-env $HOME/mybuilds/YP-6.0
-                </literallayout>
-                If you don't specifically name the build directory, then BitBake creates it 
-                in the current directory and uses the name <filename>build</filename>.
-                Also, if you supply an existing directory, then BitBake uses that 
-                directory as the Yocto Project build directory and populates the build tree
-                beneath it.</para></listitem>
-        </itemizedlist>
-    </para>
-</section>
-
 <section id='installing-the-adt'>
     <title>Installing the ADT</title>
 
@@ -70,7 +19,8 @@
         The following list describes how you can install the ADT, which includes the cross-toolchain.
         Regardless of the installation you choose, you must <filename>source</filename> the cross-toolchain
         environment setup script before you use the toolchain.
-        See the "<link linkend='setting-up-the-environment'>Setting Up the Environment</link>"
+        See the "<link linkend='setting-up-the-cross-development-environment'>Setting Up the 
+        Cross-Development Environment</link>"
         section for more information.
         <itemizedlist>
             <listitem><para><emphasis>Use the ADT Installer Script:</emphasis>
@@ -85,8 +35,8 @@
                 If you use this method, you just get the cross-toolchain and QEMU - you do not 
                 get any of the other mentioned benefits had you run the ADT Installer script.</para></listitem>
             <listitem><para><emphasis>Use the Toolchain from within a Yocto Project Build Tree:</emphasis>
-                If you already have a Yocto Project build tree, you can install the cross-toolchain 
-                using that tree.
+                If you already have a Yocto Project build tree, you can build the cross-toolchain 
+                within tree.
                 However, like the previous method mentioned, you only get the cross-toolchain and QEMU - you 
                 do not get any of the other benefits without taking separate steps.</para></listitem>
         </itemizedlist>
@@ -106,14 +56,15 @@
             <para>
                 The ADT Installer is contained in the ADT Installer tarball.
                 You can download the tarball into any directory from  
-                <ulink url='http://autobuilder.yoctoproject.org/downloads/yocto-1.1/adt-installer/'></ulink>.
+                <ulink url='http://downloads.yoctoproject.org/releases/yocto/yocto-1.1/adt_installer'></ulink>.
                 Or, you can use BitBake to generate the tarball inside the existing Yocto Project 
                 build tree.
             </para>
 
             <para>
                 If you use BitBake to generate the ADT Installer tarball, you must 
-                <filename>source</filename> the Yocto Project environment setup script located 
+                <filename>source</filename> the Yocto Project environment setup script 
+                (<filename>oe-init-build-env</filename>) located 
                 in the Yocto Project file structure before running the <filename>bitbake</filename>
                 command that creates the tarball.
             </para>
@@ -128,7 +79,7 @@
      $ cd ~
      $ mkdir yocto-project
      $ cd yocto-project
-     $ wget http://www.yoctoproject.org/downloads/poky/poky-edison-6.0.tar.bz2
+     $ wget http://downloads.yoctoproject.org/releases/yocto/yocto-1.1/poky-edison-6.0.tar.bz2
      $ tar xjf poky-edison-6.0.tar.bz2
      $ source poky-edison-6.0/oe-init-build-env
      $ bitbake adt-installer
@@ -213,9 +164,9 @@
             <note>
                 The ADT Installer requires the <filename>libtool</filename> package to complete.  
                 If you install the recommended packages as described in the 
-                <ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#packages'>
-                Packages</ulink> section of 
-                <ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html'>
+                "<ulink url='http://www.yoctoproject.org/docs/latest/yocto-project-qs/yocto-project-qs.html#packages'>Packages</ulink>"
+                section of 
+                <ulink url='http://www.yoctoproject.org/docs/latest/yocto-project-qs/yocto-project-qs.html'>
                 The Yocto Project Quick Start</ulink>, then you will have libtool installed.
             </note>
 
@@ -230,7 +181,7 @@
             <para>
                 Once the installation completes, the ADT, which includes the cross-toolchain, is installed.
                 You will notice environment setup files for the cross-toolchain in 
-                <filename>/opt/poky/$SDKVERSION</filename>,
+                <filename>/opt/poky/1.1</filename>,
                 and image tarballs in the <filename>adt-installer</filename>
                 directory according to your installer configurations, and the target sysroot located
                 according to the <filename>YOCTOADT_TARGET_SYSROOT_LOC_&lt;arch&gt;</filename> variable
@@ -245,64 +196,70 @@
         <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 install the cross-toolchain by hand, you will have to set up the target sysroot separately.
+            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.
         </para>
 
         <para>
             Follow these steps:
             <orderedlist>
                 <listitem><para>Go to  
-                    <ulink url='http://autobuilder.yoctoproject.org/downloads/yocto-1.1/toolchain'></ulink> 
+                    <ulink url='http://downloads.yoctoproject.org/releases/yocto/yocto-1.1/toolchain'></ulink> 
                     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 
                     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 ARM-based target, go into the 
+                    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:
                     <literallayout class='monospaced'>
-     yocto-eglibc-x86_64-arm-toolchain-gmae-1.1.tar.bz2
-                   </literallayout>
-                    <note>As an alternative to steps one and two, you can build the toolchain tarball 
+     poky-eglibc-x86_64-i586-toolchain-gmae-1.1.tar.bz2
+                    </literallayout>
+                    <note><para>As an alternative to steps one and two, you can build the toolchain tarball 
                         if you have a Yocto Project build tree.
-                        Use the <filename>bitbake meta-toolchain</filename> command after you have 
-                        sourced the <filename>oe-build-init script</filename> located in the Yocto 
+                        If you need GMAE, you should use the <filename>bitbake meta-toolchain-gmae</filename>
+                        command. 
+                        The resulting tarball will support such development.
+                        However, if you are not concerned with GMAE, 
+                        you can generate the tarball using <filename>bitbake meta-toolchain</filename>.</para>
+                        <para>Use the appropriate <filename>bitbake</filename> command only after you have 
+                        sourced the <filename>oe-build-init-env</filename> script located in the Yocto 
                         Project files.  
-                        When the <filename>bitbake</filename> command completes, the toolchain tarball will 
+                        When the <filename>bitbake</filename> command completes, the tarball will 
                         be in <filename>tmp/deploy/sdk</filename> in the Yocto Project build tree.
-                        </note></para></listitem>
+                        </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>/opt/poky/$SDKVERSION</filename>.
-                    Once the tarball in unpacked, the cross-toolchain is installed.
+                    The tarball expands into <filename>/opt/poky/1.1</filename>.
+                    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>
             </orderedlist>
         </para>
-
-        <para>
-            After installing the toolchain, you must locate the target sysroot tarball and unpack it
-            into a location of your choice.
-        </para>  
     </section>
 
     <section id='using-the-toolchain-from-within-the-build-tree'>
         <title>Using BitBake and the Yocto Project Build Tree</title>
 
         <para>
-            A final way of installing just the cross-toolchain is to use BitBake within an existing 
-            Yocto Project build tree.
-            Follow these steps:
+            A final way of installing just the cross-toolchain is to use BitBake to build the 
+            toolchain within an existing Yocto Project build tree.
+            This method does not install the toolchain into the <filename>/opt</filename> directory.
+            As with the previous method, if you need to install the target sysroot, you must 
+            do this separately.
+        </para>
+
+        <para>
+            Follow these steps to build and install the toolchain into the build tree:
             <orderedlist>
-                <listitem><para>Source the environment setup script located in the Yocto Project
-                    files.
-                    The script has the string <filename>init-build-env</filename>
-                    as part of the name.</para></listitem> 
+                <listitem><para>Source the environment setup script 
+                    <filename>oe-init-build-env</filename> located in the Yocto Project
+                    files.</para></listitem> 
                 <listitem><para>At this point, you should be sure that the 
                     <filename>MACHINE</filename> variable 
-                    in the <filename>local.conf</filename> file found in the Yocto Project 
-                    file structure's <filename>conf</filename> directory 
+                    in the <filename>local.conf</filename> file found in the 
+                    <filename>conf</filename> directory of the Yocto Project build directory
                     is set for the target architecture.
                     Comments within the <filename>local.conf</filename> file list the values you 
                     can use for the <filename>MACHINE</filename> variable.  
@@ -313,39 +270,34 @@
                         command.</note></para></listitem>
                 <listitem><para>Run <filename>bitbake meta-ide-support</filename> to complete the 
                     cross-toolchain installation.
-                    <note>If you change your working directory after you 
+                    <note>If change out of your working directory after you 
                         <filename>source</filename> the environment setup script and before you run
-                        the BitBake command, the command will not work. 
+                        the <filename>bitbake</filename> command, the command might not work. 
                         Be sure to run the <filename>bitbake</filename> command immediately 
                         after checking or editing the <filename>local.conf</filename> but without 
-                        changing your working directory.</note>
-                    Once BitBake finishes, the cross-toolchain is installed.
+                        changing out of your working directory.</note>
+                    Once the <filename>bitbake</filename> command finishes, 
+                    the tarball for the cross-toolchain is generated within the Yocto Project build tree.
                     You will notice environment setup files for the cross-toolchain in the 
                     Yocto Project build tree in the <filename>tmp</filename> directory.
                     Setup script filenames contain the strings <filename>environment-setup</filename>.
                     </para></listitem>
             </orderedlist>
         </para>
-
-        <para>
-            After installing the toolchain, you must locate the target sysroot tarball and unpack
-            it in a directory of your choice.
-        </para>
     </section>
 </section>
 
-<section id='setting-up-the-environment'>
-    <title>Setting Up the Environment</title>
+<section id='setting-up-the-cross-development-environment'>
+    <title>Setting Up the Cross-Development Environment</title>
 
     <para>
-        Before you can use the cross-toolchain, you need to set up the toolchain environment by 
-        sourcing the environment setup script.  
+        Before you can develop using the cross-toolchain, you need to set up the 
+        cross-development environment by sourcing the toolchain's environment setup script.  
         If you used the ADT Installer or used an existing ADT tarball to install the ADT,
-        then you can find this script in the <filename>/opt/poky/$SDKVERSION</filename>
+        then you can find this script in the <filename>/opt/poky/1.1</filename>
         directory.  
-        If you used BitBake and the Yocto Project Build Tree to install the cross-toolchain,
-        then you can find the environment setup scripts in in the Yocto Project build tree 
-        in the <filename>tmp</filename> directory.
+        If you installed the toolchain in the build tree, you can find the environment setup 
+        script for the toolchain in the Yocto Project build tree's <filename>tmp</filename> directory.
     </para>
 
     <para> 
@@ -353,7 +305,7 @@
         which you are developing.  
         Environment setup scripts begin with the string “<filename>environment-setup</filename>”
         and include as part of their name the architecture.  
-        For example, the environment setup script for a 64-bit IA-based architecture would 
+        For example, the toolchain environment setup script for a 64-bit IA-based architecture would 
         be the following: 
         <literallayout class='monospaced'>
      /opt/poky/1.1/environment-setup-x86_64-poky-linux
@@ -361,35 +313,128 @@
     </para>
 </section>
 
-<section id='kernels-and-filesystem-images'>
-    <title>Kernels and Filesystem Images</title>
+<section id='securing-kernel-and-filesystem-images'>
+    <title>Securing Kernel and Filesystem Images</title>
 
     <para>
         You will need to have a kernel and filesystem image to boot using your 
-        hardware or the QEMU emulator.  
-        That means you either have to build them or know where to get them.
-        You can find a quick example of how to build an image in the 
-        <ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#building-image'>
-        Building an Image</ulink> section of   
-        <ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html'>
-        The Yocto Project Quick Start</ulink>.
-        <note><para> 
-            The Yocto Project provides basic kernels and filesystem images for several 
+        hardware or the QEMU emulator.
+        Furthermore, if you plan on booting your image using NFS or you want to use the root filesystem
+        as the target sysroot, you need to extract the root filesystem.
+    </para>
+
+    <section id='getting-the-images'>
+        <title>Getting the Images</title>
+
+        <para>
+            To get the kernel and filesystem images, you either have to build them or download
+            pre-built versions.
+            You can find examples for both these situations in the 
+            "<ulink url='http://www.yoctoproject.org/docs/latest/yocto-project-qs/yocto-project-qs.html#test-run'>A
+            Quick Test Run</ulink>" section of   
+            <ulink url='http://www.yoctoproject.org/docs/latest/yocto-project-qs/yocto-project-qs.html'>
+            The Yocto Project Quick Start</ulink>.
+        </para>
+
+        <para> 
+            The Yocto Project provides basic kernel and filesystem images for several 
             architectures (<filename>x86</filename>, <filename>x86-64</filename>, 
             <filename>mips</filename>, <filename>powerpc</filename>, and <filename>arm</filename>) 
             that you can use unaltered in the QEMU emulator.  
-            These kernels and filesystem images reside in the Yocto Project release 
-            area - <ulink url='http://autobuilder.yoctoproject.org/downloads/yocto-1.1/machines/'></ulink>
-            and are ideal for experimentation within Yocto Project.</para>
-            <para>If you plan on remotely deploying and debugging your application from within the 
-            Eclipse IDE, you must have an image that supports Sato.
-            For information on the image types you can build using the Yocto Project, see
-            <ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html#ref-images'>
-            Reference: Images</ulink> in  
-            <ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html'>
-            The Yocto Project Reference Manual</ulink>.</para>
-        </note>
-    </para>
+            These kernel images reside in the Yocto Project release 
+            area - <ulink url='http://downloads.yoctoproject.org/releases/yocto/yocto-1.1/machines/'></ulink>
+            and are ideal for experimentation within Yocto Project.
+            For information on the image types you can build using the Yocto Project, see the
+            "<ulink url='http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html#ref-images'>Reference: Images</ulink>" appendix in  
+            <ulink url='http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html'>
+            The Yocto Project Reference Manual</ulink>.
+        </para>
+
+        <para>
+            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 
+            <filename>tcf-agent</filename>.
+            And, those images are SDK (e.g.<filename>core-image-sato-sdk</filename>).
+        </para>
+
+        <para>
+            If you want to use a different image type that contains the <filename>tcf-agent</filename>, 
+            you can do so one of two ways:
+            <itemizedlist>
+                <listitem><para>Modify the <filename>conf/local.conf</filename> configuration in 
+                    the Yocto Project build directory and then rebuild the image.
+                    With this method, you need to modify the <filename>EXTRA_IMAGE_FEATURES</filename>
+                    variable to have the value of "tools-debug" before rebuilding the image. 
+                    Once the image is rebuilt, the <filename>tcf-agent</filename> will be included
+                    in the image and is launched automatically after the boot.</para></listitem>
+                <listitem><para>Manually build the <filename>tcf-agent</filename>.
+                    To build the agent, follow these steps:
+                    <orderedlist>
+                        <listitem><para>Be sure the ADT is installed as described in the 
+                            "<link linkend='installing-the-adt'>Installing the ADT</link>" section.
+                            </para></listitem>
+                        <listitem><para>Set up the cross-development environment as described in the 
+                            "<link linkend='setting-up-the-cross-development-environment'>Setting 
+                            Up the Cross-Development Environment</link>" section.</para></listitem>
+                        <listitem><para>Get the <filename>tcf-agent</filename> source code, which is 
+                            stored using the Subversion SCM, using the following command:
+                            <literallayout class='monospaced'>
+     $ svn checkout svn://dev.eclipse.org/svnroot/dsdp/org.eclipse.tm.tcf/trunk/agent \
+        &lt;-r #rev_number&gt;
+                            </literallayout></para></listitem>
+                        <listitem><para>Modify the <filename>Makefile.inc</filename> file
+                            for the cross-compilation environment by setting the 
+                            <filename>OPSYS</filename> and <filename>MACHINE</filename>
+                            variables according to your target.</para></listitem>
+                        <listitem><para>Use the cross-development tools to build the 
+                            <filename>tcf-agent</filename>.  
+                            Before you "Make" the file, be sure your cross-tools are set up first.
+                            See the "<link linkend='makefile-based-projects'>Makefile-Based Projects</link>"
+                            section for information on how to make sure the cross-tools are set up
+                            correctly.</para>
+                            <para>If the build is successful, the <filename>tcf-agent</filename> output will 
+                            be <filename>obj/$(OPSYS)/$(MACHINE)/Debug/agent</filename>.</para></listitem>
+                        <listitem><para>Deploy the agent into the image's root filesystem.</para></listitem>
+                    </orderedlist>
+                </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='extracting-the-root-filesystem'>
+        <title>Extracting the Root Filesystem</title>
+
+        <para>
+            You must extract the root filesystem if you want to boot the image using NFS
+            or you want to use the root filesystem as the target sysroot.
+            For example, the Eclipse IDE environment with the Eclipse Yocto Plug-in installed allows you 
+            to use QEMU to boot under NFS.
+            Another example is if you want to develop your target application using the
+            root filesystem as the target sysroot. 
+        </para>
+
+        <para> 
+            To extract the root filesystem, first <filename>source</filename>
+            the cross-development environment setup script and then 
+            use the <filename>runqemu-extract-sdk</filename> command on the 
+            filesystem image. 
+            For example, the following commands set up the environment and then extract
+            the root filesystem from a previously built filesystem image tarball named  
+            <filename>core-image-sato-sdk-qemux86-2011091411831.rootfs.tar.bz2</filename>.
+            The example extracts the root filesystem into the <filename>$HOME/qemux86-sato</filename>
+            directory:
+            <literallayout class='monospaced'>
+     $ source $HOME/poky/build/tmp/environment-setup-i586-poky-linux
+     $ runqemu-extract-sdk \
+        tmp/deploy/images/core-image-sato-sdk-qemux86-2011091411831.rootfs.tar.bz2 \
+        $HOME/qemux86-sato
+            </literallayout>
+            In this case, you could now point to the target sysroot at 
+            <filename>$HOME/qemux86-sato</filename>.
+        </para>
+    </section>
 </section>
 
 </chapter>

documentation/adt-manual/style.css

@@ -966,3 +966,9 @@ table {
    color: #fff;   
    text-decoration: underline;
 }
+
+.footnote {
+   font-size: small;
+   color: #333;
+}
+

documentation/bsp-guide/bsp-guide.xml

@@ -19,10 +19,17 @@
 
         <authorgroup>
             <author>
-                <firstname>Richard</firstname> <surname>Purdie</surname>
+                <firstname>Tom</firstname> <surname>Zanussi</surname>
                 <affiliation>
                     <orgname>Intel Corporation</orgname>
                 </affiliation>
+                <email>tom.zanussi@intel.com</email>
+            </author>
+            <author>
+                <firstname>Richard</firstname> <surname>Purdie</surname>
+                <affiliation>
+                    <orgname>Linux Foundation</orgname>
+                </affiliation>
                 <email>richard.purdie@linuxfoundation.org</email>
             </author>
         </authorgroup>
@@ -30,19 +37,23 @@
         <revhistory>
             <revision>
                 <revnumber>0.9</revnumber>
-                <date>27 October 2010</date>
-                <revremark>This manual revision is the initial manual and corresponds to the 
-                    Yocto Project 0.9 Release.</revremark>
+                <date>24 November 2010</date>
+                <revremark>The initial document draft released with the Yocto Project 0.9 Release.</revremark>
             </revision>
             <revision>
                 <revnumber>1.0</revnumber>
                 <date>6 April 2011</date>
-                <revremark>This manual revision corresponds to the Yocto Project 1.0 Release.</revremark>
+                <revremark>Released with the Yocto Project 1.0 Release.</revremark>
             </revision>
             <revision>
                 <revnumber>1.0.1</revnumber>
                 <date>23 May 2011</date>
-                <revremark>Released with Yocto Project 1.0.1 on 23 May 2011.</revremark>
+                <revremark>Released with the Yocto Project 1.0.1 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.1</revnumber>
+                <date>6 October 2011</date>
+                <revremark>Released with the Yocto Project 1.1 Release.</revremark>
             </revision>
         </revhistory>
 
@@ -59,7 +70,7 @@
       <note>
           Due to production processes, there could be differences between the Yocto Project
           documentation bundled in the release tarball and the 
-          <ulink url='http://www.yoctoproject.org/docs/1.1/bsp-guide/bsp-guide.html'>
+          <ulink url='http://www.yoctoproject.org/docs/latest/bsp-guide/bsp-guide.html'>
           Board Support Package (BSP) Developer's Guide</ulink> on
           the <ulink url='http://www.yoctoproject.org'>Yocto Project</ulink> website.
           For the latest version of this manual, see the manual on the website.

documentation/bsp-guide/bsp.xml

@@ -30,9 +30,9 @@
         <note>
             The information here does not provide an example of how to create a BSP.
             For examples on how to create a BSP, see the
-            <ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html#dev-manual-bsp-appendix'>
+            <ulink url='http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#dev-manual-bsp-appendix'>
             BSP Development Example</ulink> in  
-            <ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html'>
+            <ulink url='http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html'>
             The Yocto Project Development Manual</ulink>.
             You can also see the 
             <ulink url='https://wiki.yoctoproject.org/wiki/Transcript:_creating_one_generic_Atom_BSP_from_another'>
@@ -100,10 +100,9 @@
         "
                 </literallayout>
                 For more detailed information on layers, see the 
-                <ulink url='http://www.yoctoproject.org/docs/poky-ref-manual/poky-ref-manual.html#usingpoky-changes-layers'>
-                BitBake Layers</ulink> section of the Yocto Project Reference Manual.
+                "<ulink url='http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html#usingpoky-changes-layers'>BitBake Layers</ulink>" section of the Yocto Project Reference Manual.
                 You can also see the detailed examples in the appendices of  
-                <ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html'>
+                <ulink url='http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html'>
                 The Yocto Project Development Manual</ulink>.
             </para>
 
@@ -145,6 +144,9 @@
      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.bbappend
      meta-crownbay/recipes-graphics/
      meta-crownbay/recipes-graphics/xorg-xserver/
      meta-crownbay/recipes-graphics/xorg-xserver/emgd-driver-bin_1.6.bb
@@ -371,6 +373,24 @@
             </para></note>
             </section>
 
+            <section id='bsp-filelayout-core-recipes'>
+            <title>Core Recipe Files</title>
+            <para>
+                You can find these files in the Yocto Project file's directory structure at:
+                <literallayout class='monospaced'>
+     meta-&lt;bsp_name&gt;/recipes-core/*
+                </literallayout> 
+            </para>
+
+            <para>
+                This directory contains recipe files for the core.
+                For example, in the Crown Bay BSP there is the 
+                <filename>task-core-tools.bbappend</filename> file, which is an append file used 
+                to recommend that the SystemTap 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>
@@ -522,7 +542,7 @@
                 The configuration options will likely end up in that location anyway if the BSP gets 
                 added to the Yocto Project. 
                 For information on how to add these configurations directly, see  
-                <ulink url='http://yoctoproject.org/docs/1.1/kernel-manual/kernel-manual.html'>
+                <ulink url='http://yoctoproject.org/docs/latest/kernel-manual/kernel-manual.html'>
                 The Yocto Project Kernel Architecture and Use Manual</ulink>.</para>
                 <para>
                 In general, however, the Yocto Project maintainers take care of moving the 
@@ -652,9 +672,9 @@
               <listitem>
 		<para>
 		  Get a full-featured BSP recipe rather than a key.
-                  You can do this by visiting the applicable BSP download page from the Yocto 
-                  Project website at
-                  <ulink url='http://yoctoproject.org/download/board-support-package-bsp-downloads'></ulink>.
+                  You can do this by visiting the Yocto Project website's
+                  <ulink url='http://www.yoctoproject.org/download'>Download</ulink> page and 
+                  clicking on "BSP Downloads".
 		  BSP tarballs that have proprietary information can be downloaded after agreeing 
                   to licensing requirements as part of the download process. 
                   Obtaining the code this way allows you to build an encumbered image with 

documentation/bsp-guide/style.css

@@ -956,3 +956,9 @@ table {
    color: #fff;   
    text-decoration: underline;
 }
+
+.footnote {
+   font-size: small;
+   color: #333;
+}
+

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

@@ -6,12 +6,15 @@
 <title>BSP Development Example</title>
 
 <para>
-    This appendix provides a complete BSP example.
+    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 from.</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>        
@@ -24,11 +27,30 @@
     <para>
         You need to have the Yocto Project files available on your host system.  
         You can get files through tarball extraction or by cloning the <filename>poky</filename>
-        Git repository.  
-        See the bulleted item
-        <link linkend='local-yp-release'>Yocto Project Release</link> in
-        <xref linkend='getting-setup'>Getting Setup</xref> earlier in this manual
-        for information on how to get these files.
+        Git repository.
+        The following paragraphs describe both methods.
+        For additional information, see the bulleted item
+        "<link linkend='local-yp-release'>Yocto Project Release</link>".
+    </para>
+
+    <para>
+        As mentioned, one way to get the Yocto Project files is to use Git to clone the 
+        <filename>poky</filename> repository:
+        <literallayout class='monospaced'>
+     $ git clone git://git.yoctoproject.org/poky
+     $ cd poky
+        </literallayout> 
+        Alternatively, you can start with the downloaded Poky "edison" tarball:
+        <literallayout class='monospaced'>
+     $ tar xfj poky-edison-6.0.tar.bz2
+     $ cd poky
+        </literallayout> 
+        <note>If you're using the tarball method, you can ignore all the following steps that
+        ask you to carry out Git operations.  
+        You already have the results of those operations
+        in the form of the edison release tarballs.
+        Consequently, there is nothing left to do other than extract those tarballs into the 
+        proper locations.</note>
     </para>
 
     <para>
@@ -40,14 +62,13 @@
      $ git branch -a
      $ git tag -l
         </literallayout> 
-        For this example we are going to use the Yocto Project 1.1 Release, 
-        which maps to the <filename>1.1</filename> branch in the repository. 
-        These commands create a local branch named <filename>1.1</filename>
+        For this example we are going to use the Yocto Project 1.1 Release, which is code
+        named "edison". 
+        These commands create a local branch named <filename>edison</filename>
         that tracks the remote branch of the same name.
         <literallayout class='monospaced'>
-     $ cd poky
-     $ git checkout -b 1.1 origin/1.1
-     Switched to a new branch '1.1'
+     $ git checkout -b edison origin/edison
+     Switched to a new branch 'edison'
         </literallayout>
     </para>
 </section>
@@ -56,15 +77,20 @@
     <title>Choosing a Base BSP</title>
 
     <para>
-        For this example, the base BSP is the Intel Atom Processor E660 with Intel Platform 
+        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 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
-        <xref linkend='developing-a-board-support-package-bsp'>Developing a Board Support Package (BSP)</xref>
-        earlier in this manual.
+        "<link linkend='developing-a-board-support-package-bsp'>Developing a Board Support Package (BSP)</link>".
     </para>
 </section>
 
@@ -73,30 +99,59 @@
 
     <para>
         You need to have the base BSP layer on your development system.  
-        Like the local Yocto Project files, you can get the BSP 
-        layer one of two ways:  
+        Similar to the local Yocto Project files, you can get the BSP 
+        layer in a couple of different ways:  
         download the BSP tarball and extract it, or set up a local Git repository that 
         has the Yocto Project BSP layers.  
         You should use the same method that you used to get the local Yocto Project files earlier.
-        See <xref linkend='getting-setup'>Getting Setup</xref> earlier in this manual
-        for information on how to get the BSP files.
-    </para>
-        
-    <para>
-        This example assumes a local <filename>meta-intel</filename> Git repository
-        inside the local <filename>poky</filename> Git repository.
-        The <filename>meta-intel</filename> Git repository contains all the metadata 
-        that supports BSP creation.
+        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 edison version of the BSP tarball from the
+        <ulink url='http://www.yoctoproject.org/download'>Download</ulink> page of the 
+        Yocto Project website. 
+        Here is the specific link for the tarball needed for this example:
+        <ulink url='http://downloads.yoctoproject.org/releases/yocto/yocto-1.1/machines/crownbay-noemgd/crownbay-noemgd-edison-6.0.0.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-edison-6.0.0.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 edison 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>1.1</filename> branch. 
+        For this example we are going to use the <filename>edison</filename> branch. 
         <literallayout class='monospaced'>
-     $ cd meta-intel
-     $ git checkout -b 1.1 origin/1.1
-     Switched to a new branch 'bernard'
+     $ git checkout -b edison origin/edison
+     Switched to a new branch 'edison'
         </literallayout>
     </para>
 </section>
@@ -105,23 +160,20 @@
     <title>Making a Copy of the Base BSP to Create Your New BSP Layer</title>
 
     <para>
-        Now that you have the local Yocto Project files and the base BSP files you need to create a 
+        Now that you have the local Yocto Project files and 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>
+        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 must follow the BSP layer naming convention, which is 
+        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 example assumes your working directory is <filename>meta-intel</filename> 
+        The following assumes your working directory is <filename>meta-intel</filename> 
         inside the local Yocto Project files.  
-        If you downloaded and expanded a Crown Bay tarball then you simply copy the resulting 
-        <filename>meta-crownbay</filename> directory structure to a location of your choice.
-        Good practice for a Git repository, however, is to just copy the new layer alongside 
-        the existing
-        BSP layers in the <filename>meta-intel</filename> Git repository:
+        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>
@@ -148,7 +200,7 @@
         </para>
 
         <para>
-            First, since in this example the new BSP will not support EMGD we will get rid of the 
+            First, since in this example the new BSP will not support EMGD, we will get rid of the 
             <filename>crownbay.conf</filename> file and then rename the 
             <filename>crownbay-noemgd.conf</filename> file to <filename>mymachine.conf</filename>.  
             Much of what we do in the configuration directory is designed to help the Yocto Project 
@@ -163,25 +215,32 @@
         </para>
 
         <para>
-            The next step makes changes to <filename>mymachine.conf</filename> itself.  
-            The only changes needed for this example are changes to the comment lines.
-            Here we simply substitute the Crown Bay name with an appropriate name.
+            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_PROVIDER_virtual/kernel</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 
+            In this case, the BSP is using <filename>linux-yocto</filename>, which is the 
             current Linux Yocto kernel based on the Linux 3.0 release. 
         </para>
 
         <para>
-            The next configuration file in the new BSP layer we need to edit is <filename>layer.conf</filename>.
+            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='http://www.yoctoproject.org/docs/1.1/bsp-guide/bsp-guide.html#bsp-filelayout-layer'>
-            Layer Configuration File</ulink> section in the Board Support Packages (BSP) Development Guide
+            "<ulink url='http://www.yoctoproject.org/docs/latest/bsp-guide/bsp-guide.html#bsp-filelayout-layer'>Layer Configuration File</ulink>" section in  
+            <ulink url='http://www.yoctoproject.org/docs/latest/bsp-guide/bsp-guide.html'>The Board 
+            Support Packages (BSP) Development Guide</ulink>
             for more information on this configuration file.  
             Basically, we are changing the existing statements to work with our BSP. 
         </para>
@@ -212,10 +271,10 @@
         <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.  
+            When you create a BSP, you use these areas for appropriate recipes and append files.  
             Recipes take the form of <filename>.bb</filename> files.  
             If you want to leverage the existing recipes the Yocto Project build system uses
-            but change those recipes you can use <filename>.bbappend</filename> files.  
+            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 
@@ -223,7 +282,7 @@
         </para>
 
         <section id='changing-recipes-bsp'>
-            <title>Changing <filename>recipes-bsp</filename></title>
+            <title>Changing&nbsp;&nbsp;<filename>recipes-bsp</filename></title>
 
             <para>
                 First, let's look at <filename>recipes-bsp</filename>.
@@ -232,7 +291,7 @@
                 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-graphics/xorg-xserver/*emgd*
+     $ 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>
@@ -240,7 +299,7 @@
         </section>
 
         <section id='changing-recipes-graphics'>
-            <title>Changing <filename>recipes-graphics</filename></title>
+            <title>Changing&nbsp;&nbsp;<filename>recipes-graphics</filename></title>
 
             <para>
                 Now let's look at <filename>recipes-graphics</filename>.
@@ -248,7 +307,6 @@
                 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-emgd*
      $ 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   
@@ -262,7 +320,7 @@
         </section>
 
         <section id='changing-recipes-core'>
-            <title>Changing <filename>recipes-core</filename></title>
+            <title>Changing&nbsp;&nbsp;<filename>recipes-core</filename></title>
 
             <para>
                 Now let's look at changes in <filename>recipes-core</filename>.
@@ -291,7 +349,7 @@
         </section>
 
         <section id='changing-recipes-kernel'>
-            <title>Changing <filename>recipes-kernel</filename></title>
+            <title>Changing&nbsp;&nbsp;<filename>recipes-kernel</filename></title>
 
             <para>
                 Finally, let's look at <filename>recipes-kernel</filename> changes.
@@ -304,13 +362,17 @@
                 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.0.bbappend</filename> that 
-                is appended to the recipe of the same name in <filename>meta/recipes-kernel/link</filename>.
+                is appended 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>
@@ -321,14 +383,14 @@
                 Here are the statements: 
                 <literallayout class='monospaced'>
      SRCREV_machine_pn-linux-yocto_crownbay ?= \
-        "372c0ab135978bd8ca3a77c88816a25c5ed8f303"
+        "2247da9131ea7e46ed4766a69bb1353dba22f873"
      SRCREV_meta_pn-linux-yocto_crownbay ?= \
-        "d5d3c6480d61f83503ccef7fbcd765f7aca8b71b"
+        "d05450e4aef02c1b7137398ab3a9f8f96da74f52"
 
      SRCREV_machine_pn-linux-yocto_crownbay-noemgd ?= \
-        "372c0ab135978bd8ca3a77c88816a25c5ed8f303"
+        "2247da9131ea7e46ed4766a69bb1353dba22f873"
      SRCREV_meta_pn-linux-yocto_crownbay-noemgd ?= \
-        "d5d3c6480d61f83503ccef7fbcd765f7aca8b71b"
+        "d05450e4aef02c1b7137398ab3a9f8f96da74f52"
                 </literallayout>
             </para>
 
@@ -343,30 +405,54 @@
             </para>
 
             <para>  
-                To fix this situation in <filename>linux-yocto_3.0.bbappend</filename>
+                To fix this situation in <filename>linux-yocto_3.0.bbappend</filename>,
                 we delete the two <filename>SRCREV</filename> statements that support 
-               EMGD (the top pair).
+                EMGD (the top pair).
                 We also change the remaining pair to specify <filename>mymachine</filename>
                 and insert the commit identifiers to identify the kernel in which we 
                 are interested, which will be based on the <filename>atom-pc-standard</filename>
                 kernel.
+                In this case, because we're working with the edison branch of everything, we
+                need to use the <filename>SRCREV</filename> values for the atom-pc branch
+                that are associated with the edison release.  
+                To find those values, we need to find the <filename>SRCREV</filename>
+                values that edison uses for the atom-pc branch, which we find in the
+                <filename>poky/meta-yocto/recipes-kernel/linux/linux-yocto_3.0.bbappend</filename>
+                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.0.bb</filename>
+                file, in the <filename>SRCREV_meta variable</filename> found there.  
+                It happens to be the same as the value we already inherited from the 
+                <filename>meta-crownbay</filename> BSP.
                 Here are the final <filename>SRCREV</filename> statements:
                 <literallayout class='monospaced'>
      SRCREV_machine_pn-linux-yocto_mymachine ?= \ 
-        "fce17f046d3756045e4dfb49221d1cf60fcae329"
+        "1e18e44adbe79b846e382370eb29bc4b8cd5a1a0"
      SRCREV_meta_pn-linux-yocto_mymachine ?= \ 
-        "84f1a422d7e21fbc23a687035bdf9d42471f19e0"
+        "d05450e4aef02c1b7137398ab3a9f8f96da74f52"
                 </literallayout>
             </para>
 
             <para>
-                If you are familiar with Git repositories you probably won’t have trouble locating the 
+                In this example, we're using the <filename>SRCREV</filename> values we 
+                found already captured in the edison release because we're creating a BSP based on 
+                edison.  
+                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.0</filename> kernel 
-                <ulink url='http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-2.6.37'>here</ulink>
-                [WRITER's NOTE:  Need new link to the 3.0 source repo area when it is available].  
+                branch points (commits) for the <filename>linux-yocto-3.0</filename> kernel at
+                <ulink url='http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.0'></ulink>.  
             </para>
 
             <para>
@@ -395,19 +481,25 @@
                 Because we are not interested in supporting EMGD those three can be deleted.
                 The remaining three must be changed so that <filename>mymachine</filename> replaces
                 <filename>crownbay-noemgd</filename> and <filename>crownbay</filename>.
+                Because we are using the atom-pc branch for this new BSP, we can also find
+                the exact branch we need for the KMACHINE variable in our new BSP from the value
+                we find in the
+                <filename>poky/meta-yocto/recipes-kernel/linux/linux-yocto_3.0.bbappend</filename>
+                file we looked at in a previous step.  
+                In this case, the value we want is in the KMACHINE_atom-pc variable in that file.
                 Here is the final <filename>linux-yocto_3.0.bbappend</filename> file after all 
                 the edits:
                 <literallayout class='monospaced'>
      FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
 
      COMPATIBLE_MACHINE_mymachine = "mymachine"
-     KMACHINE_mymachine  = "yocto/standard/mymachine"
+     KMACHINE_mymachine  = "yocto/standard/common-pc/atom-pc"
      KERNEL_FEATURES_append_mymachine += " cfg/smp.scc"
 
      SRCREV_machine_pn-linux-yocto_mymachine ?= \
-        "fce17f046d3756045e4dfb49221d1cf60fcae329"
+        "1e18e44adbe79b846e382370eb29bc4b8cd5a1a0"
      SRCREV_meta_pn-linux-yocto_mymachine ?= \
-        "84f1a422d7e21fbc23a687035bdf9d42471f19e0"
+        "d05450e4aef02c1b7137398ab3a9f8f96da74f52"
                 </literallayout>
             </para>
         </section>
@@ -421,7 +513,7 @@
             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-machine</filename> of any code that supported the EMGD features
+            <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. 
@@ -456,7 +548,7 @@
                 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>yocot-build</filename> directory contains a 
+                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>
@@ -470,9 +562,10 @@
                 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 you are using a multi-threaded development system (e.g. values of 
-                <filename>8</filename> and <filename>j 6</filename>, respectively are optimal 
-                for a development machine that has four available cores).</para></listitem>
+                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 
                 the path to your new BSP layer.  
                 In this example you need to include the pathname to <filename>meta-mymachine</filename>.
@@ -486,14 +579,14 @@
 
     <para>
         The appendix 
-        <ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html#ref-variables-glos'>
+        <ulink url='http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html#ref-variables-glos'>
         Reference: Variables Glossary</ulink> in the Yocto Project Reference Manual has more information 
          on configuration variables.
     </para>
 </section>
 
 <section id='building-the-image-app'>
-    <title>Building the Image</title>
+    <title>Building and Booting the Image</title>
 
     <para>
         To build the image for our <filename>meta-mymachine</filename> BSP enter the following command 
@@ -502,7 +595,7 @@
         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-live
+     $ bitbake -k core-image-sato
         </literallayout>
     </para>
 
@@ -514,6 +607,63 @@
         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 edison 
+        should look like the following in terms of size.
+        If your sato image is much different from this,
+        you probably made a mistake in one of the above steps:
+        <literallayout class='monospaced'>
+     358715392 2011-11-01 19:11 core-image-sato-mymachine-20111101223904.hddimg
+        </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>
 

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

@@ -4,179 +4,178 @@
 <chapter id='dev-manual-intro'>
 
 <title>The Yocto Project Development Manual</title>
+    <section id='intro'>
+        <title>Introduction</title>
 
-<para>
-    WRITER NOTE: The goal of this manual is to provide an over-arching development guide for using the Yocto Project.  
-    The intent is to give the reader the “big picture” around development.  
-    Much of the information in the manual will be detailed in other manuals.  
-    For example, detailed information on Git, repositories and open-source in general can be found in many places.  
-    Another example is getting set up to use the Yocto Project, which our Yocto Project Quick Start covers.  
-    However, this manual needs to at least address it.  
-    One might ask “What becomes of the Poky Reference Manual?”  
-    This manual, over time, needs to develop into a pure reference manual where all procedural information 
-    eventually ends up in an appropriate guide.   
-    A good example of information perfect for the Poky Reference Manual is the appendix on variable 
-    definitions (glossary).
-</para>
+        <para>
+            Welcome to the Yocto Project Development Manual!
+            This manual gives you an idea of how to use the Yocto Project to develop embedded Linux 
+            images and user-space applications to run on targeted devices. 
+            Reading this manual gives you an overview of image, kernel, and user-space application development
+            using the Yocto Project. 
+            Because much of the information in this manual is general, it contains many references to other
+            sources where you can find more detail.
+            For example, detailed information on Git, repositories and open source in general
+            can be found in many places.  
+            Another example is how to get set up to use the Yocto Project, which our Yocto Project Quick Start covers.
+        </para>
 
-<section id='intro'>
-    <title>Introduction</title>
+        <para>  
+            The Yocto Project Development Manual, however, does provide detailed examples on how to create a 
+            Board Support Package (BSP), change the kernel source code, and re-configure the kernel.
+            You can find this information in the appendices of the manual.
+        </para>
+    </section>
 
-    <para>
-        Welcome to the Yocto Project Development Guide!  
-        This guide provides a general view of the development process using the Yocto Project.  
-        This guide is just that – a guide.  
-        It helps you understand the bigger picture involving development using the Yocto Project.  
-    </para>
-</section>
+    <section id='what-this-manual-provides'>
+        <title>What this Manual Provides</title>
 
-<section id='what-this-manual-provides'>
-    <title>What this Manual Provides</title>
+        <para>
+            The following list describes what you can get from this guide:
+            <itemizedlist>
+                <listitem><para>Information that lets you get set 
+                    up to develop using the Yocto Project.</para></listitem>
+                <listitem><para>Information to help developers who are new to the open source environment 
+                    and to the distributed revision control system Git, which the Yocto Project 
+                    uses.</para></listitem>
+                <listitem><para>An understanding of common end-to-end development models.</para></listitem>
+                <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>
+<!--                <listitem><para>A discussion of target-level analysis techniques, tools, tips, 
+                    and tricks.</para></listitem>
+                <listitem><para>Considerations for deploying your final product.</para></listitem> -->
+                <listitem><para>An understanding of basic kernel architecture and 
+                    concepts.</para></listitem>
+<!--                <listitem><para>Information that will help you migrate an existing project to the 
+                    Yocto Project development environment.</para></listitem> -->
+                <listitem><para>Many references to other sources of related information.</para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
 
-    <para>
-        The following list describes what you can get from this guide:
-        <itemizedlist>
-            <listitem><para>Information that lets you get set 
-                up to develop using the Yocto Project.</para></listitem>
-            <listitem><para>Information to help developers that are new to the open source environment 
-                and to the distributed revision control system Git, which the Yocto Project 
-                uses.</para></listitem>
-            <listitem><para>An understanding of common end-to-end development models.</para></listitem>
-            <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>
-            <listitem><para>A discussion of target-level analysis techniques, tools, tips, 
-                and tricks.</para></listitem>
-            <listitem><para>Considerations for deploying your final product.</para></listitem>
-            <listitem><para>An understanding of basic kernel architecture and 
-                concepts.</para></listitem>
-            <listitem><para>Information that will help you migrate an existing project to the 
-                Yocto Project development environment.</para></listitem>
-            <listitem><para>Many references to other sources of related information.</para></listitem>
-        </itemizedlist>
-    </para>
-</section>
+    <section id='what-this-manual-does-not-provide'>
+        <title>What this Manual Does Not Provide</title>
 
-<section id='what-this-manual-does-not-provide'>
-    <title>What this Manual Does Not Provide</title>
+        <para>
+            This manual will not give you the following:
+            <itemizedlist>
+                <listitem><para>Step-by-step instructions if those instructions exist in other Yocto 
+                    Project documentation.  
+                    For example, the Application Development Toolkit (ADT) User’s Guide contains detailed 
+                    instruction on how to obtain and configure the 
+                    <trademark class='trade'>Eclipse</trademark> Yocto Plug-in.</para></listitem>
+                <listitem><para>Reference material.  
+                    This type of material resides in an appropriate reference manual.  
+                    For example, system variables are documented in the 
+                    <ulink url='http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html'>
+                    Yocto Project Reference Manual</ulink>.</para></listitem>
+                <listitem><para>Detailed public information that is not specific to the Yocto Project.  
+                    For example, exhaustive information on how to use Git is covered better through the 
+                    Internet than in this manual.</para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
 
-    <para>
-        This manual will not give you the following:
-        <itemizedlist>
-            <listitem><para>Step-by-step instructions if those instructions exist in other Yocto 
-                Project documentation.  
-                For example, The Application Development Toolkit (ADT) User’s Guide contains detailed 
-                instruction on how to obtain and configure the Eclipse Yocto Plug-in.</para></listitem>
-            <listitem><para>Reference material.  
-                This type of material resides in an appropriate reference manual.  
-                For example, system variables are documented in the Poky Reference Manual.</para></listitem>
-            <listitem><para>Detailed public information that is not specific to the Yocto Project.  
-                For example, exhaustive information on how to use Git is covered better through the 
-                Internet than in this manual.</para></listitem>
-        </itemizedlist>
-    </para>
-</section>
-
-<section id='other-information'>
-    <title>Other Information</title>
+    <section id='other-information'>
+        <title>Other Information</title>
  
-    <para>
-        Because this manual presents overview information for many different topics, you will
-        need to supplement it with other information.
-        The following list presents other sources of information you might find helpful:
-        <itemizedlist>
-            <listitem><para><emphasis>The <ulink url='http://www.yoctoproject.org'>Yocto Project Website</ulink>:
-                </emphasis> The home page for the Yocto Project provides lots of information on the project 
-                as well as links to software and documentation.</para></listitem>
-            <listitem><para><emphasis>
-                <ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html'>
-                The Yocto Project Quick Start</ulink>:</emphasis> This short document lets you get started 
-                with the Yocto Project quickly and start building an image.</para></listitem>
-            <listitem><para><emphasis> 
-                <ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html'>
-                The Yocto Project Reference Manual</ulink>:</emphasis> This manual is a reference 
-                guide to the Yocto Project build component known as "Poky."  
-                The manual also contains a reference chapter on Board Support Package (BSP) 
-                layout.</para></listitem>
-            <listitem><para><emphasis>
-                <ulink url='http://www.yoctoproject.org/docs/1.1/adt-manual/adt-manual.html'>
-                The Yocto Project Application Development Toolkit (ADT) User's Guide</ulink>:</emphasis>
-                This guide provides information that lets you get going with the ADT to 
-                develop projects using the Yocto Project.</para></listitem>
-            <listitem><para><emphasis>
-                <ulink url='http://www.yoctoproject.org/docs/1.1/bsp-guide/bsp-guide.html'>
-                The Yocto Project Board Support Package (BSP) Developer's Guide</ulink>:</emphasis>
-                This guide defines the structure for BSP components.  
-                Having a commonly understood structure encourages standardization.</para></listitem>
-            <listitem><para><emphasis>
-                <ulink url='http://www.yoctoproject.org/docs/1.1/kernel-manual/kernel-manual.html'>
-                The Yocto Project Kernel Architecture and Use Manual</ulink>:</emphasis>
-                This manual describes the architecture of the Yocto Project kernel and provides 
-                some work flow examples.</para></listitem>
-            <listitem><para><emphasis>
-                <ulink url='http://www.youtube.com/watch?v=3ZlOu-gLsh0'>
-                Yocto Eclipse Plug-in</ulink>:</emphasis> A step-by-step instructional video that
-                demonstrates how an application developer uses Yocto Plug-in features within 
-                the Eclipse IDE.</para></listitem>
-            <listitem><para><emphasis>
-                <ulink url='http://wiki.yoctoproject.org/wiki/FAQ'>FAQ</ulink>:</emphasis>
-                A list of commonly asked questions and their answers.</para></listitem>
-            <listitem><para><emphasis>
-                <ulink url='http://www.yoctoproject.org/download/yocto/yocto-project-1.0-release-notes-poky-5.0'>
-                Release Notes</ulink>:</emphasis> Features, updates and known issues for the current 
-                release of the Yocto Project.</para></listitem>
-            <listitem><para><emphasis>
-                <ulink url='http://bugzilla.yoctoproject.org/'>Bugzilla</ulink>:</emphasis>
-                The bug tracking application the Yocto Project uses.
-                If you find problems with the Yocto Project, you should report them using this
-                application.</para></listitem>
-            <listitem><para><emphasis>
-                Yocto Project Mailing Lists:</emphasis> To subscribe to the Yocto Project mailing 
-                lists, click on the following URLs and follow the instructions:
-                <itemizedlist>
-                    <listitem><para><ulink url='http://lists.yoctoproject.org/listinfo/yocto'></ulink> for a 
-                        Yocto Discussions mailing list.</para></listitem>
-                    <listitem><para><ulink url='http://lists.yoctoproject.org/listinfo/poky'></ulink> for a 
-                        Yocto Project Discussions mailing list.</para></listitem>
-                    <listitem><para><ulink url='http://lists.yoctoproject.org/listinfo/yocto-announce'></ulink>
-                        for a mailing list to receive offical Yocto Project announcements for developments and 
-                        as well as Yocto Project milestones.</para></listitem>
-                </itemizedlist></para></listitem>
-            <listitem><para><emphasis>Internet Relay Chat (IRC):</emphasis>
-                Two IRC channels on freenode are available 
-                for Yocto Project and Poky discussions: <filename>#yocto</filename> and 
-                <filename>#poky</filename>.</para></listitem>
-            <listitem><para><emphasis>
-                <ulink url='http://www.openedhand.com/'>OpenedHand</ulink>:</emphasis>
-                The company where the Yocto Project build system Poky was first developed.
-                OpenedHand has since been acquired by Intel Corporation.</para></listitem>
-            <listitem><para><emphasis>
-                <ulink url='http://www.intel.com/'>Intel Corporation</ulink>:</emphasis>
-                The company who acquired OpenedHand in 2008 and continues development on the 
-                Yocto Project.</para></listitem>
-            <listitem><para><emphasis>
-                <ulink url='http://www.openembedded.org/'>OpenEmbedded</ulink>:</emphasis>
-                The upstream, generic, embedded distribution the Yocto Project build system (Poky) derives
-                from and to which it contributes.</para></listitem>
-            <listitem><para><emphasis>
-                <ulink url='http://developer.berlios.de/projects/bitbake/'>
-                Bitbake</ulink>:</emphasis> The tool used to process Yocto Project metadata.</para></listitem>
-            <listitem><para><emphasis>
-                <ulink url='http://bitbake.berlios.de/manual/'>
-                BitBake User Manual</ulink>:</emphasis> A comprehensive guide to the BitBake tool.
-                </para></listitem>
-            <listitem><para><emphasis>
-                <ulink url='http://pimlico-project.org/'>Pimlico</ulink>:</emphasis>
-                A suite of lightweight Personal Information Management (PIM) applications designed 
-                primarily for handheld and mobile devices.</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>
-        </itemizedlist>
-    </para>
-</section>
-            
+        <para>
+            Because this manual presents overview information for many different topics, you will
+            need to supplement it with other information.
+            The following list presents other sources of information you might find helpful:
+            <itemizedlist>
+                <listitem><para><emphasis>The <ulink url='http://www.yoctoproject.org'>Yocto Project Website</ulink>:
+                    </emphasis> The home page for the Yocto Project provides lots of information on the project 
+                    as well as links to software and documentation.</para></listitem>
+                <listitem><para><emphasis>
+                    <ulink url='http://www.yoctoproject.org/docs/latest/yocto-project-qs/yocto-project-qs.html'>
+                    The Yocto Project Quick Start</ulink>:</emphasis> This short document lets you get started 
+                    with the Yocto Project quickly and start building an image.</para></listitem>
+                <listitem><para><emphasis> 
+                    <ulink url='http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html'>
+                    The Yocto Project Reference Manual</ulink>:</emphasis> This manual is a reference 
+                    guide to the Yocto Project build component known as "Poky."  
+                    The manual also contains a reference chapter on Board Support Package (BSP) 
+                    layout.</para></listitem>
+                <listitem><para><emphasis>
+                    <ulink url='http://www.yoctoproject.org/docs/latest/adt-manual/adt-manual.html'>
+                    The Yocto Project Application Development Toolkit (ADT) User's Guide</ulink>:</emphasis>
+                    This guide provides information that lets you get going with the ADT to 
+                    develop projects using the Yocto Project.</para></listitem>
+                <listitem><para><emphasis>
+                    <ulink url='http://www.yoctoproject.org/docs/latest/bsp-guide/bsp-guide.html'>
+                    The Yocto Project Board Support Package (BSP) Developer's Guide</ulink>:</emphasis>
+                    This guide defines the structure for BSP components.  
+                    Having a commonly understood structure encourages standardization.</para></listitem>
+                <listitem><para><emphasis>
+                    <ulink url='http://www.yoctoproject.org/docs/latest/kernel-manual/kernel-manual.html'>
+                    The Yocto Project Kernel Architecture and Use Manual</ulink>:</emphasis>
+                    This manual describes the architecture of the Yocto Project kernel and provides 
+                    some work flow examples.</para></listitem>
+                <listitem><para><emphasis>
+                    <ulink url='http://www.youtube.com/watch?v=3ZlOu-gLsh0'>
+                    Yocto Eclipse Plug-in</ulink>:</emphasis> A step-by-step instructional video that
+                    demonstrates how an application developer uses Yocto Plug-in features within 
+                    the Eclipse IDE.</para></listitem>
+                <listitem><para><emphasis>
+                    <ulink url='http://wiki.yoctoproject.org/wiki/FAQ'>FAQ</ulink>:</emphasis>
+                    A list of commonly asked questions and their answers.</para></listitem>
+                <listitem><para><emphasis>
+                    <ulink url='http://www.yoctoproject.org/download/yocto/yocto-project-1.1-release-notes-poky-6.0'>
+                    Release Notes</ulink>:</emphasis> Features, updates and known issues for the current 
+                    release of the Yocto Project.</para></listitem>
+                <listitem><para><emphasis>
+                    <ulink url='http://bugzilla.yoctoproject.org/'>Bugzilla</ulink>:</emphasis>
+                    The bug tracking application the Yocto Project uses.
+                    If you find problems with the Yocto Project, you should report them using this
+                    application.</para></listitem>
+                <listitem><para><emphasis>
+                    Yocto Project Mailing Lists:</emphasis> To subscribe to the Yocto Project mailing 
+                    lists, click on the following URLs and follow the instructions:
+                    <itemizedlist>
+                        <listitem><para><ulink url='http://lists.yoctoproject.org/listinfo/yocto'></ulink> for a 
+                            Yocto Project Discussions mailing list.</para></listitem>
+                        <listitem><para><ulink url='http://lists.yoctoproject.org/listinfo/poky'></ulink> for a 
+                            Yocto Project Discussions mailing list about the Poky build system.</para></listitem>
+                        <listitem><para><ulink url='http://lists.yoctoproject.org/listinfo/yocto-announce'></ulink>
+                            for a mailing list to receive offical Yocto Project announcements for developments and 
+                            as well as Yocto Project milestones.</para></listitem>
+                    </itemizedlist></para></listitem>
+                <listitem><para><emphasis>Internet Relay Chat (IRC):</emphasis>
+                    Two IRC channels on freenode are available 
+                    for Yocto Project and Poky discussions: <filename>#yocto</filename> and 
+                    <filename>#poky</filename>.</para></listitem>
+                <listitem><para><emphasis>
+                    <ulink url='http://www.openedhand.com/'>OpenedHand</ulink>:</emphasis>
+                    The company where the Yocto Project build system Poky was first developed.
+                    OpenedHand has since been acquired by Intel Corporation.</para></listitem>
+                <listitem><para><emphasis>
+                    <ulink url='http://www.intel.com/'>Intel Corporation</ulink>:</emphasis>
+                    The company that acquired OpenedHand in 2008 and continues development on the 
+                    Yocto Project.</para></listitem>
+                <listitem><para><emphasis>
+                    <ulink url='http://www.openembedded.org/'>OpenEmbedded</ulink>:</emphasis>
+                    The upstream, generic, embedded distribution the Yocto Project build system (Poky) derives
+                    from and to which it contributes.</para></listitem>
+                <listitem><para><emphasis>
+                    <ulink url='http://developer.berlios.de/projects/bitbake/'>
+                    BitBake</ulink>:</emphasis> The tool used to process Yocto Project metadata.</para></listitem>
+                <listitem><para><emphasis>
+                    <ulink url='http://bitbake.berlios.de/manual/'>
+                    BitBake User Manual</ulink>:</emphasis> A comprehensive guide to the BitBake tool.
+                    </para></listitem>
+                <listitem><para><emphasis>
+                    <ulink url='http://pimlico-project.org/'>Pimlico</ulink>:</emphasis>
+                    A suite of lightweight Personal Information Management (PIM) applications designed 
+                    primarily for handheld and mobile devices.</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>
+            </itemizedlist>
+        </para>
+    </section>   
 </chapter>
 <!--
 vim: expandtab tw=80 ts=4

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

@@ -47,7 +47,7 @@
                     <listitem><para>The <filename>poky-extras</filename> Git repository placed 
                         within the local Yocto Project files Git repository</para></listitem>  
                     <listitem><para>A bare clone of the Linux Yocto kernel upstream Git 
-                        repository that you want to modify
+                        repository to which you want to push your modifications.
                         </para></listitem>
                     <listitem><para>A copy of that bare clone in which you make your source 
                         modifcations</para></listitem>
@@ -56,9 +56,10 @@
 
             <para> 
                 The following figure summarizes these four areas.  
-                Within each rectangular that represents a data structure an URL appears at the 
+                Within each rectangular that represents a data structure, a  
+                host development directory pathname appears at the 
                 lower left-hand corner of the box.  
-                These URLs are the locations used in this example.
+                These pathnames are the locations used in this example.
                 The figure also provides key statements and commands used during the kernel
                 modification process:
             </para>
@@ -74,13 +75,12 @@
                     <listitem><para><emphasis>Local Yocto Project Files Git Repository:</emphasis> 
                         This area contains all the metadata that supports building images in the 
                         Yocto Project build environment - the local Yocto Project files.
-                        The Local Yocto Project files Git repository also contains the build directory
+                        The local Yocto Project files Git repository also contains the build directory
                         and a configuration directory that let you control the build.
-                        Note also that in this example the repository also contains the 
+                        Note also that in this example, the repository also contains the 
                         <filename>poky-extras</filename> Git repository.</para>
                         <para>See the bulleted item
-                        <link linkend='local-yp-release'>Yocto Project Release</link> in
-                        <xref linkend='getting-setup'>Getting Setup</xref> earlier in this manual
+                        "<link linkend='local-yp-release'>Yocto Project Release</link>"
                         for information on how to get these files.</para></listitem>
                     <listitem><para><emphasis><filename>poky-extras</filename> Git Repository:</emphasis> 
                         This area contains the <filename>meta-kernel-dev</filename> layer, 
@@ -91,9 +91,8 @@
                         (or really any) kernel recipes that faciliate the creation and development
                         of kernel features, BSPs or configurations.</para>
                         <para>See the bulleted item
-                        <link linkend='poky-extras-repo'>The 
-                        <filename>poky-extras</filename> Git Repository</link> in
-                        <xref linkend='getting-setup'>Getting Setup</xref> earlier in this manual
+                        "<link linkend='poky-extras-repo'>The 
+                        <filename>poky-extras</filename> Git Repository</link>" 
                         for information on how to get these files.</para></listitem>                
                     <listitem><para><emphasis>Bare Clone of the Linux Yocto kernel:</emphasis> 
                         This bare Git repository tracks the upstream Git repository of the Linux 
@@ -105,8 +104,7 @@
                         <filename>poky-extras</filename> repository points to the bare clone
                         so that the build process can locate the locally changed source files.</para>
                         <para>See the bulleted item
-                        <link linkend='local-kernel-files'>Linux Yocto Kernel</link> in  
-                        <xref linkend='getting-setup'>Getting Setup</xref> earlier in this manual
+                        "<link linkend='local-kernel-files'>Linux Yocto Kernel</link>"
                         for information on how to set up the bare clone.
                         </para></listitem>
                     <listitem><para><emphasis>Copy of the Linux Yocto Kernel Bare Clone:</emphasis>
@@ -114,9 +112,14 @@
                         Any changes you make to files in this location need to ultimately be pushed
                         to the bare clone using the <filename>git push</filename> command.</para>
                         <para>See the bulleted item
-                        <link linkend='local-kernel-files'>Linux Yocto Kernel</link> in  
-                        <xref linkend='getting-setup'>Getting Setup</xref> earlier in this manual
+                        "<link linkend='local-kernel-files'>Linux Yocto Kernel</link>"
                         for information on how to set up the bare clone.
+                        <note>Typically, Git workflows follow a scheme where changes made to a local area 
+                        are pulled into a Git repository.
+                        However, because the <filename>git pull</filename> command does not work 
+                        with bare clones, this workflow pushes changes to the 
+                        repository even though you could use other more complicated methods to
+                        get changes into the bare clone.</note>
                         </para></listitem>
                 </itemizedlist>
             </para>
@@ -131,8 +134,7 @@
                 This example uses <filename>poky</filename> as the root directory of the 
                 local Yocto Project files Git repository.
                 See the bulleted item
-                <link linkend='local-yp-release'>Yocto Project Release</link> in
-                <xref linkend='getting-setup'>Getting Setup</xref> earlier in this manual
+                "<link linkend='local-yp-release'>Yocto Project Release</link>"
                 for information on how to get these files.
             </para>
 
@@ -146,14 +148,14 @@
      $ git branch -a
      $ git tag -l
                 </literallayout> 
-                This example uses the Yocto Project 1.1_M3 Release, 
-                which maps to the <filename>1.1_M3</filename> branch in the repository. 
-                The following commands create and checkout the local <filename>1.1_M3</filename>
+                This example uses the Yocto Project 1.1 Release code named "edison", 
+                which maps to the <filename>edison</filename> branch in the repository. 
+                The following commands create and checkout the local <filename>edison</filename>
                 branch:
                 <literallayout class='monospaced'>
-     $ git checkout -b 1.1_M3 origin/1.1_M3
-     Branch 1.1_M3 set up to track remote branch 1.1_M3 from origin.
-     Switched to a new branch '1.1_M3'
+     $ git checkout -b edison origin/edison
+     Branch edison set up to track remote branch edison from origin.
+     Switched to a new branch 'edison'
                 </literallayout>
             </para>
         </section>
@@ -165,9 +167,8 @@
                 This example places the <filename>poky-extras</filename> Git repository inside
                 of <filename>poky</filename>.
                 See the bulleted item
-                <link linkend='poky-extras-repo'>The 
-                <filename>poky-extras</filename> Git Repository</link> in
-                <xref linkend='getting-setup'>Getting Setup</xref> earlier in this manual
+                "<link linkend='poky-extras-repo'>The 
+                <filename>poky-extras</filename> Git Repository</link>" 
                 for information on how to get the <filename>poky-extras</filename> repository.
             </para>
         </section>
@@ -180,8 +181,7 @@
                 Thus, you need to create a bare clone of that kernel and then make a copy of the 
                 bare clone.
                 See the bulleted item
-                <link linkend='local-kernel-files'>Linux Yocto Kernel</link> in  
-                <xref linkend='getting-setup'>Getting Setup</xref> earlier in this manual
+                "<link linkend='local-kernel-files'>Linux Yocto Kernel</link>" 
                 for information on how to do that.
             </para>
 
@@ -196,7 +196,8 @@
                 <literallayout class='monospaced'>
      $ cd ~/linux-yocto-3.0
      $ git checkout -b common-pc-base origin/yocto/standard/common-pc/base
-     Branch common-pc-base set up to track remote branch yocto/standard/common-pc/base from origin.
+     Branch common-pc-base set up to track remote branch 
+        yocto/standard/common-pc/base from origin.
      Switched to a new branch 'common-pc-base'
                 </literallayout>
             </para>
@@ -220,11 +221,15 @@
                     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 <filename>BB_NUMBER_THREADS</filename> to twice the number 
-                    of cores your machine supports and set <filename>PARALLEL_MAKE</filename> to one and 
-                    a half times the number of cores your machine supports.
+                    As a guideline, set both <filename>BB_NUMBER_THREADS</filename> and 
+                    <filename>PARALLEL_MAKE</filename> to twice the number 
+                    of cores your machine supports.
                 </note>
-                The following commands build the default <filename>qemux86</filename> image:
+                </para>
+                <para>
+                The following two commands build the default <filename>qemux86</filename> image and 
+                <filename>source</filename> build environment setup script.
+                If necessary, the script creates the build directory:
                 <literallayout class='monospaced'>
      $ cd ~/poky
      $ source oe-init-build-env
@@ -242,15 +247,14 @@
          meta-ide-support
 
      You can also run generated qemu images with a command like 'runqemu qemux86'
-
-     $ bitbake -k core-image-minimal
                 </literallayout>
             </para>
 
             <para>
-                The <filename>source</filename> command sets up the build environment and, 
-                if necessary, creates the build directory.
-                The following <filename>bitbake</filename> command starts the build.
+                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>
@@ -298,8 +302,7 @@
                 <literallayout class='monospaced'>
      void __cpuinit calibrate_delay(void)
      {
-	     unsigned long ticks, loopbit;
-	     int lps_precision = LPS_PREC;
+	     unsigned long lpj;
 	     static bool printed;
 
          if (preset_lpj) {
@@ -315,8 +318,7 @@
                 <literallayout class='monospaced'>
      void __cpuinit calibrate_delay(void)
      {
-	     unsigned long ticks, loopbit;
-	     int lps_precision = LPS_PREC;
+	     unsigned long lpj;
 	     static bool printed;
          printk("*************************************\n");
          printk("*                                   *\n");
@@ -374,24 +376,24 @@
                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 
+                   <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 Intel Architecture 
+                       <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 
+                   <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 <filename>BB_NUMBER_THREADS</filename> to twice the number of 
-                       cores and setting <filename>PARALLEL_MAKE</filename> to one and a half times the 
-                       number of cores.</para></listitem>
+                       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 
+                       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.  
@@ -408,7 +410,7 @@
        /home/scottrif/poky/poky-extras/meta-kernel-dev \
        "
                        </literallayout></para></listitem>
-                   <listitem><para><emphasis>Identify Your Source Files</emphasis> - In the 
+                   <listitem><para><emphasis>Identify Your Source Files:</emphasis> In the 
                        <filename>linux-yocto_3.0.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 
@@ -421,7 +423,7 @@
                        <literallayout class='monospaced'>
      KSRC_linux_yocto ?= /home/scottrif/linux-yocto-3.0.git
                        </literallayout></para></listitem>
-                   <listitem><para><emphasis>Specify the Kernel Machine</emphasis> - Also in the 
+                   <listitem><para><emphasis>Specify the Kernel Machine:</emphasis> Also in the 
                        <filename>linux-yocto_3.0.bbappend</filename> file, you need to specify
                        the kernel machine with the following statement:
                        <literallayout class='monospaced'>
@@ -451,14 +453,15 @@
                 <orderedlist>
                     <listitem><para>Your environment should be set up since you previously sourced
                         the <filename>oe-init-build-env</filename> script.
-                        If it isn't, source the script again from <filename>poky</filename>
+                        If it isn't, source the script again from <filename>poky</filename>.
                         </para></listitem>
                     <listitem><para>Be sure old images are cleaned out by running the 
                         <filename>cleanall</filename> BitBake task as follows:
                         <literallayout class='monospaced'>
+     $ cd ~/poky
      $ bitbake -c cleanall linux-yocto
                         </literallayout></para>
-                        <para><note>Never remove by hand any files from the <filename>tmp/deploy</filename>
+                        <para><note>Never remove any files by hand from the <filename>tmp/deploy</filename>
                         directory insided the local Yocto Project files build directory.
                         Always use the BitBake <filename>cleanall</filename> task to clear
                         out previous builds.</note></para></listitem>
@@ -466,14 +469,12 @@
                         <literallayout class='monospaced'>
      $ bitbake -k core-image-minimal
                         </literallayout></para></listitem>
-                </orderedlist>
-            </para>
-
-            <para>
-                Finally, boot the modified image in the QEMU emulator using this command:
-                <literallayout class='monospaced'>
+                    <listitem><para>Finally, boot the modified image in the QEMU emulator 
+                        using this command:
+                        <literallayout class='monospaced'>
      $ runqemu qemux86
-                </literallayout>
+                        </literallayout></para></listitem>
+                </orderedlist>
             </para>
 
             <para>
@@ -495,8 +496,8 @@
         <title>Changing the Kernel Configuration</title>
 
         <para>
-            This example changes the default behavior (off) of the Symmetric Multi-processing Support 
-            (<filename>CONFIG_SMP</filename>) to on.  
+            This example changes the default behavior, which is "off", of the Symmetric 
+            Multi-processing Support (<filename>CONFIG_SMP</filename>) to "on".  
             It is a simple example that demonstrates how to reconfigure the kernel.
         </para>
 
@@ -505,45 +506,60 @@
 
             <para>
                 If you took the time to work through the example that modifies the kernel source code 
-                in <xref linkend='modifying-the-kernel-source-code'>Modifying the Kernel Source
-                Code</xref> you are set up to quickly work through this example.
+                in "<link linkend='modifying-the-kernel-source-code'>Modifying the Kernel Source
+                Code</link>" you should already have the Yocto Project files set up on your 
+                host machine.
+            </para>
+
+            <para>
+                If you don't have the Yocto Project files established on your system, 
+                See "<link linkend='setting-up-the-local-yocto-project-files-git-repository'>Setting 
+                Up the Local Yocto Project Files Git Repository</link>" for 
+                information.
+                To reconfigure the kernel, this is the only Git repository you need to have set up. 
+            </para>
+
+<!--
+
+            <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 are already set up to quickly work through this example.
                 If not, then work through the following list to prepare:
                 <itemizedlist>
                     <listitem><para><emphasis>Understand the development environment:</emphasis>
-                        See <xref linkend='understanding-the-files-you-need'> 
-                        Understanding the Files You Need</xref> for information.</para></listitem>
+                        See "<link linkend='understanding-the-files-you-need'>Understanding 
+                        the Files You Need</link>" for information.</para></listitem>
                     <listitem><para><emphasis>Set up the local Yocto Project files Git 
                         repository:</emphasis>
-                        See <xref linkend='setting-up-the-local-yocto-project-files-git-repository'>
-                        Setting Up the Local Yocto Project Files Git Repository</xref> for 
+                        See "<link linkend='setting-up-the-local-yocto-project-files-git-repository'>Setting 
+                        Up the Local Yocto Project Files Git Repository</link>" for 
                         information.</para></listitem>
                     <listitem><para><emphasis>Set up the <filename>poky-extras</filename> Git 
                         repository:</emphasis>
-                        See <xref linkend='setting-up-the-poky-extras-git-repository'>
-                        Setting Up <filename>poky-extras</filename> Git repository</xref> for
+                        See "<link linkend='setting-up-the-poky-extras-git-repository'>Setting 
+                        Up <filename>poky-extras</filename> Git repository</link>" for
                         information.</para></listitem>
                     <listitem><para><emphasis>Set up the the bare clone and its copy:</emphasis>
-                        See <xref linkend='setting-up-the-bare-clone-and-its-copy'>
-                        Setting Up the Bare Clone and its Copy</xref> for information.
-                        </para></listitem>
+                        See "<link linkend='setting-up-the-bare-clone-and-its-copy'>Setting Up the 
+                        Bare Clone and its Copy</link>" for information.</para></listitem>
                     <listitem><para><emphasis>Build the default QEMU kernel image:</emphasis>
-                        See <xref linkend='building-and-booting-the-default-qemu-kernel-image'>
-                        Building and Booting the Default QEMU Kernel image</xref> 
-                        for information.
+                        See "<link linkend='building-and-booting-the-default-qemu-kernel-image'>Building 
+                        and Booting the Default QEMU Kernel image</link>" for information.
                         Do not boot the image in the QEMU emulator at this point.</para></listitem>
                 </itemizedlist>
-            </para>
+            </para> -->
         </section>
 
         <section id='examining-the-default-config-smp-behavior'>
-            <title>Examining the Default <filename>CONFIG_SMP</filename> Behavior</title>
+            <title>Examining the Default&nbsp;&nbsp;<filename>CONFIG_SMP</filename> Behavior</title>
 
             <para>
                 By default, <filename>CONFIG_SMP</filename> supports single processor machines.
-                To see this default setting from within the QEMU emulator boot your image using 
+                To see this default setting from within the QEMU emulator, boot your image using 
                 the emulator as follows:
                 <literallayout class='monospaced'>
-     $ runqemu qemux86
+     $ runqemu qemux86 qemuparams="-smp 2"
                 </literallayout>
             </para>
 
@@ -557,16 +573,18 @@
      processor       : 0
      #
                 </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 <filename>CONFIG_SMP</filename> Configuration Using <filename>menuconfig</filename></title>
+            <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 BitBake environment.
+                You need to run <filename>menuconfig</filename> inside the Yocto BitBake environment.
                 Thus, the environment must be set up using the <filename>oe-init-build-env</filename>
                 script found in the Yocto Project files Git repository build directory.
                 If you have not sourced this script do so with the following commands:
@@ -579,7 +597,7 @@
             <para>
                 After setting up the environment to run <filename>menuconfig</filename>, you are ready 
                 to use the tool to interactively change the kernel configuration.
-                In this example we are basing our changes on the <filename>linux-yocto-3.0</filename>
+                In this example, we are basing our changes on the <filename>linux-yocto-3.0</filename>
                 kernel.
                 The Yocto Project build environment recognizes this kernel as 
                 <filename>linux-yocto</filename>.
@@ -596,23 +614,29 @@
                 You can find it at <filename>Processor Type and Features</filename>.
                 The configuration selection is 
                 <filename>Symmetric Multi-processing Support</filename>.
+                After using the arrow keys to highlight this selection, press "y" to select it.
+                Then, exit out and save your selections.
             </para>
 
             <para>
-                Once you save the selection the <filename>.config</filename> configuration file
+                Once you save the selection, the <filename>.config</filename> configuration file
                 is updated. 
                 This is the file that the build system uses to configure the Linux Yocto kernel
                 when it is built. 
                 You can find and examine this file in the Yocto Project files Git repository in 
                 the build directory. 
-                This example uses the following:
+                This example uses the following.
+                Note that this example directory is artificially split and many of the characters 
+                in the actually filename are omitted in order to make it more
+                readable:
                 <literallayout class='monospaced'>
-     ~/poky/build/tmp/work/qemux86-poky-linux/linux-yocto-2.6.37+git1+84f...r20/linux-qemux86-standard-build
+     ~/poky/build/tmp/work/qemux86-poky-linux/linux-yocto-2.6.37+git1+84f...
+        ...r20/linux-qemux86-standard-build
                 </literallayout>
             </para>
 
             <para>
-                Within the <filename>.config</filename> you can see the following setting:
+                Within the <filename>.config</filename> file, you can see the following setting:
                 <literallayout class='monospaced'>
      CONFIG_SMP=y
                 </literallayout>
@@ -621,13 +645,19 @@
             <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> simply rename
-                the default <filename>.config</filename>, use <filename>menuconfig</filename> to make 
+                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.
-                For an example of this procedure, see [WRITER'S NOTE: need forwarding link to section].
+                <note>
+                    Be sure to make a copy of the <filename>.config</filename> and don't just
+                    rename it. 
+                    The Yocto Project build system needs an existing <filename>.config</filename>
+                    from which to work.
+                </note>
             </para>
         </section>
 
@@ -635,7 +665,7 @@
             <title>Recompiling the Kernel and Testing the New Configuration</title>
 
             <para>
-                At this point you are ready to recompile your kernel image with 
+                At this point, you are ready to recompile your kernel image with 
                 the new setting in effect using the BitBake commands below:
                 <literallayout class='monospaced'>
      $ bitbake linux-yocto -c compile -f
@@ -646,7 +676,7 @@
             <para>
                 Now run the QEMU emulator:
                 <literallayout class='monospaced'>
-     $ runqemu qemux86
+     $ runqemu qemux86 qemuparams="-smp 2"
                 </literallayout>
             </para>
 
@@ -662,7 +692,7 @@
             </para>
 
             <para>
-                From the output you can see that you have successfully reconfigured the kernel.
+                From the output, you can see that you have successfully reconfigured the kernel.
             </para>
         </section>
     </section>
@@ -671,13 +701,14 @@
         <title>Adding Kernel Recipes</title>
 
         <para>
-            This section presents an example that adds kernel recipes, which provide 
+            A future release of this manual will present an example that adds kernel recipes, which provide 
             new functionality to the kernel.
         </para>
 
         <para>
-            [Example to be supplied]
-        </para>
+            <imagedata fileref="figures/wip.png" 
+                width="2in" depth="3in" align="center" scalefit="1" />
+        </para> 
     </section> 
 
 

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

@@ -9,16 +9,23 @@
     Many development models exist for which you can use the Yocto Project. 
     However, for the purposes of this manual we are going to focus on two common ones:  
     System Development and User Application Development.  
-    System Development covers Board Support Package (BSP) development and kernel modification.  
+    System Development covers Board Support Package (BSP) development and kernel modification
+    or configuration.  
     User Application Development covers development of applications that you intend to run on some 
     target hardware.  
 </para>
 
 <para>
     This chapter presents overviews of both system and application models.
-    If you want to reference specific examples of these development models, 
-    see <xref linkend='dev-manual-bsp-appendix'>BSP Development Example</xref> and 
-    <xref linkend='dev-manual-kernel-appendix'>Kernel Modification Example</xref>.
+    If you want to examine specific examples of the system development models, 
+    see the "<link linkend='dev-manual-bsp-appendix'>BSP Development Example</link>" 
+    appendix and the 
+    "<link linkend='dev-manual-kernel-appendix'>Kernel Modification Example</link>" appendix.
+    For a user-space application development example that uses the 
+    <trademark class='trade'>Eclipse</trademark> IDE,
+    see the 
+    <ulink url='http://www.yoctoproject.org/docs/latest/adt-manual/adt-manual.html'>
+    The Yocto Project Application Development Toolkit (ADT) User's Guide</ulink>.
 </para>
 
 <section id='system-development-model'>
@@ -27,41 +34,41 @@
     <para>
         System development involves modification or creation of an image that you want to run on 
         a specific hardware target.  
-        Usually when you want to create an image that runs on embedded hardware the image does 
-        not require the same amount of features that a full-fledged Linux distribution provides.  
-        Thus, you can create a much smaller image that is designed to just use the hardware 
+        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
         features for your particular hardware.
     </para>
 
     <para>
         To help you understand how system development works in the Yocto Project, this section 
-        covers two types of image development:  BSP creation and kernel modification
-        (see <xref linkend='kernel-spot'></xref>).
+        covers two types of image development:  BSP creation and kernel modification or 
+        configuration.
     </para>
 
     <section id='developing-a-board-support-package-bsp'>
         <title>Developing a Board Support Package (BSP)</title>
 
         <para>
-            A BSP is a package of recipes that when applied during a build results in 
-            an image you can run on a particular board.  
+            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.  
         </para>
 
         <note>
             For a brief list of terms used when describing the development process in the Yocto Project, 
-            see <xref linkend='yocto-project-terms'>Yocto Project Terms</xref> in this manual.
+            see the "<link linkend='yocto-project-terms'>Yocto Project Terms</link>" section.
         </note>
 
         <para>
-            The remainder of this section presents the basic steps to create a BSP basing it on an 
-            existing BSP that ships with the Yocto Project.
-            You can reference <xref linkend='dev-manual-bsp-appendix'>BSP Development Example</xref>
-            for a detailed example that uses the Crown Bay BSP as a base BSP from which to start.
+            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.
         </para>
 
         <para>
-            This illustration and the following list summarizes the BSP creation general workflow.
+            The following illustration and list summarize the BSP creation general workflow.
         </para>
 
         <para>
@@ -71,37 +78,38 @@
         <para>
             <orderedlist>
                 <listitem><para><emphasis>Set up your host development system to support 
-                    development using the Yocto Project</emphasis>:  See  
-                    <ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#the-linux-distro'>
-                    The Linux Distributions</ulink> section and  
-                    <ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#packages'>
-                    The Packages</ulink> section both
+                    development using the Yocto Project</emphasis>:  See the
+                    "<ulink url='http://www.yoctoproject.org/docs/latest/yocto-project-qs/yocto-project-qs.html#the-linux-distro'>The Linux Distributions</ulink>" and the 
+                    "<ulink url='http://www.yoctoproject.org/docs/latest/yocto-project-qs/yocto-project-qs.html#packages'>The Packages</ulink>" sections both
                     in the Yocto Project Quick Start for requirements.</para></listitem>
                 <listitem><para><emphasis>Establish a local copy of the Yocto Project files on your 
                     system</emphasis>:  You need to have the Yocto Project files available on your host system. 
                     Having the Yocto Project files on your system gives you access to the build
-                    process and tools you need.
+                    process and to the tools you need.
                     For information on how to get these files, see the
-                    <xref linkend='getting-setup'>Getting Setup</xref> section in this manual.</para></listitem>
+                    "<link linkend='getting-setup'>Getting Setup</link>" section.</para></listitem>
                 <listitem><para><emphasis>Establish a local copy of the base BSP files</emphasis>:  Having    
                     the BSP files on your system gives you access to the build
-                    process and tools you need.
-                    For information on how to get these files, see 
-                    <xref linkend='getting-setup'>Getting Setup</xref> earlier in this manual.</para></listitem>    
+                    process and to the tools you need for creating a BSP.
+                    For information on how to get these files, see the
+                    "<link linkend='getting-setup'>Getting Setup</link>" section.</para></listitem>    
                 <listitem><para><emphasis>Choose a Yocto Project-supported BSP as your base BSP</emphasis>:  
                     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, it gives you some structure with which to start.</para>
+                    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.  
+                    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 Atom-based BSP to consider is the Crown Bay that does not support
-                    the Intel® Embedded Media Graphics Driver (EMGD).  
+                    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 Yocto Project
                     <ulink url='http://www.yoctoproject.org/download'>download page</ulink> and click 
@@ -110,35 +118,34 @@
                     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.   
-                    Consider an application as another example that illustrates a layer.  
+                    Another example that illustrates a layer is an application.  
                     Suppose you are creating an application that has library or other dependencies in 
                     order for it to compile and run.  
                     The layer, in this case, would be where all the recipes that define those dependencies 
-                    are kept.  The key point for a layer is that it is an isolated area that contains 
+                    are kept.  
+                    The key point for a layer is that it is an isolated area that contains 
                     all the relevant information for the project that the Yocto Project build 
                     system knows about.</para>
                     <note>The Yocto Project supports four BSPs that are part of the 
                     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 local Yocto Project files.
+                    within the local Yocto Project files.
                     Consequently, they are not totally isolated in the spirit of layers unless you think 
                     of <filename>meta-yocto</filename> as a layer itself.  
                     On the other hand, BSP layers for Crown Bay, Emenlow, Jasper Forest, 
                     N450, and Sugar Bay are isolated.</note>
-                    <para>When you set up a layer for a new BSP you should follow a standard layout.  
-                    This layout is described in the
-                    <ulink url='http://www.yoctoproject.org/docs/1.1/bsp-guide/bsp-guide.html#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  
+                    <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='http://www.yoctoproject.org/docs/latest/bsp-guide/bsp-guide.html#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 
                     local Yocto Project files.</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> within the 
+                    <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.
@@ -148,23 +155,21 @@
                     recipes you don't use, and adding new recipes 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 
+                    changes to your BSP layer, there remains a few things 
                     you need to do for the Yocto Project build system in order for it to create your image.  
                     You need to get the build environment ready by sourcing an environment setup script 
                     and you need to be sure two key configuration files are configured appropriately.</para>
-                    <para>The entire process for building an image is overviewed in the 
-                    <ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#building-image'>
-                    Building an Image</ulink> section of the Yocto Project Quick Start.    
+                    <para>The entire process for building an image is overviewed in the section
+                    "<ulink url='http://www.yoctoproject.org/docs/latest/yocto-project-qs/yocto-project-qs.html#building-image'>Building an Image</ulink>" section of the Yocto Project Quick Start.    
                     You might want to reference this information.</para></listitem>
                 <listitem><para><emphasis>Build the image</emphasis>:  The Yocto Project uses the BitBake 
                     tool to build images based on the type of image you want to create.  
                     You can find more information on BitBake 
                     <ulink url='http://bitbake.berlios.de/manual/'>here</ulink>.</para>
                     <para>The build process supports several types of images to satisfy different needs.  
-                    See 
-                    <ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html#ref-images'>
-                    Reference: Images</ulink> in the 
-                    <ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html'>
+                    See the 
+                    "<ulink url='http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html#ref-images'>Reference: Images</ulink>" appendix in the 
+                    <ulink url='http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html'>
                     Yocto Project Reference Manual</ulink>for information on supported images.</para></listitem>
             </orderedlist>
         </para>
@@ -173,11 +178,11 @@
             You can view a video presentation on "Building Custom Embedded Images with Yocto"
             at <ulink url='http://free-electrons.com/blog/elc-2011-videos'>Free Electrons</ulink>.  
             You can also find supplemental information in  
-            <ulink url='http://yoctoproject.org/docs/1.1/bsp-guide/bsp-guide.html'>
+            <ulink url='http://yoctoproject.org/docs/latest/bsp-guide/bsp-guide.html'>
             The Board Support Package (BSP) Development Guide</ulink>.
-            Finally, there is wiki page write up of the example located 
+            Finally, there is wiki page write up of the example also located 
             <ulink url='https://wiki.yoctoproject.org/wiki/Transcript:_creating_one_generic_Atom_BSP_from_another'>
-            here</ulink> you might find helpful.
+            here</ulink> that you might find helpful.
        </para>
     </section>
 
@@ -186,7 +191,7 @@
 
         <para>
             Kernel modification involves changing the Linux Yocto kernel, which could involve changing
-            configuration variables as well as adding new kernel recipes.  
+            configuration options as well as adding new kernel recipes.  
             Configuration changes can be added in the form of configuration fragments, while recipe
             modification comes through the kernel's <filename>recipes-kernel</filename> area
             in a kernel layer you create.
@@ -196,9 +201,10 @@
             The remainder of this section presents a high-level overview of the Linux Yocto 
             kernel architecture and the steps to modify the Linux Yocto kernel.
             For a complete discussion of the kernel, see  
-            <ulink url='http://www.yoctoproject.org/docs/1.1/kernel-manual/kernel-manual.html'>
+            <ulink url='http://www.yoctoproject.org/docs/latest/kernel-manual/kernel-manual.html'>
             The Yocto Project Kernel Architecture and Use Manual</ulink>.
-            You can reference <xref linkend='dev-manual-kernel-appendix'>Kernel Modification Example</xref>
+            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.
         </para>
 
@@ -206,10 +212,11 @@
             <title>Kernel Overview</title>
 
             <para>
-                When one thinks of the source files for a kernel they usually think of a fixed structure 
-                of files that contain kernel patches.
-                The Yocto Project, however, employs mechanisims, that in a sense, result in a kernel source
+                Traditionally, when one thinks of a patched kernel, they think of a base kernel
+                source tree and a fixed structure that contains kernel patches.
+                The Yocto Project, however, employs mechanisms, that in a sense, result in a kernel source
                 generator.
+                By the end of this section, this analogy will become clearer.
             </para>
 
             <para>
@@ -232,8 +239,8 @@
             </para>
 
             <para>
-                The kernels are maintained using the Git application that, in a sense, structures
-                them in a "tree" complete with branches and leaves.
+                The kernels are maintained using the Git revision control system
+                that structures them using the familiar "tree", "branch", and "leaf" scheme.
                 Branches represent diversions from general code to more specific code, while leaves
                 represent the end-points for a complete and unique kernel whose source files 
                 when gathered from the root of the tree to the leaf accumulate to create the files
@@ -246,7 +253,7 @@
 
             <para>
                 Within the figure, the "Kernel.org Branch Point" represents the point in the tree
-                where a supported base kernel diverges from the Linux kernel.
+                where a supported base kernel is modified from the Linux kernel.
                 For example, this could be the branch point for the <filename>linux-yocto-3.0</filename>
                 kernel.
                 Thus, everything further to the right in the structure is based on the 
@@ -260,7 +267,7 @@
 
             <para>
                 The overall result is a Git-maintained repository from which all the supported
-                Yocto Project kernels can be derived for all the supported Yocto Project devices.
+                Yocto Project kernel types can be derived for all the supported Yocto Project devices.
                 A big advantage to this scheme is the sharing of common features by keeping them in 
                 "larger" branches within the tree.  
                 This practice eliminates redundant storage of similar features shared among kernels.
@@ -342,7 +349,7 @@
             <para>
                 Again, for a complete discussion of the Yocto Project kernel's architcture and its 
                 branching strategy,
-                see the <ulink url='http://www.yoctoproject.org/docs/1.1/kernel-manual/kernel-manual.html'>
+                see the <ulink url='http://www.yoctoproject.org/docs/latest/kernel-manual/kernel-manual.html'>
                 The Yocto Project Kernel Architecture and Use Manual</ulink>.
                 Also, you can reference 
                 <xref linkend='modifying-the-kernel-source-code'>Modifying the Kernel Source Code</xref>
@@ -358,24 +365,22 @@
             </para>
 
             <para>
-                <imagedata fileref="figures/kernel-dev-flow.png" width="6in" depth="7in" align="center" scalefit="1" />
+                <imagedata fileref="figures/kernel-dev-flow.png" 
+                    width="6in" depth="7.5in" align="center" scalefit="1" />
             </para> 
 
             <para>
                 <orderedlist>
                     <listitem><para><emphasis>Set up your host development system to support 
                         development using the Yocto Project</emphasis>:  See  
-                        <ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#the-linux-distro'>
-                        The Linux Distributions</ulink> section and  
-                        <ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#packages'>
-                        The Packages</ulink> section both
+                        "<ulink url='http://www.yoctoproject.org/docs/latest/yocto-project-qs/yocto-project-qs.html#the-linux-distro'>The Linux Distributions</ulink>" and  
+                        "<ulink url='http://www.yoctoproject.org/docs/latest/yocto-project-qs/yocto-project-qs.html#packages'>The Packages</ulink>" sections both
                         in the Yocto Project Quick Start for requirements.</para></listitem>
                     <listitem><para><emphasis>Establish a local copy of the Yocto Project files on your 
                         system</emphasis>:  Having the Yocto Project files on your system gives you access to 
                         the build process and tools you need.
                         For information on how to get these files, see the bulleted item
-                        <link linkend='local-yp-release'>Yocto Project Release</link> in  
-                        <xref linkend='getting-setup'>Getting Setup</xref> earlier in this manual.
+                        "<link linkend='local-yp-release'>Yocto Project Release</link>" earlier in this manual.
                         </para></listitem>
                     <listitem><para><emphasis>Set up the <filename>poky-extras</filename> Git 
                         repository</emphasis>:  This repository is the area for your configuration 
@@ -384,85 +389,97 @@
                         It is good practice to set this repository up inside the local Yocto
                         Project files Git repository.
                         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> in
-                        <xref linkend='getting-setup'>Getting Setup</xref> earlier in this manual.
-                        </para></listitem>
+                        "<link linkend='poky-extras-repo'>The <filename>poky-extras</filename> Git Repository</link>"
+                        earlier in this manual.
+                        <note>While it is certainly possible to modify the kernel without involving
+                            a local Git repository, the suggested workflow for kernel modification
+                            using the Yocto Project does use a Git repository.</note></para></listitem>
                     <listitem><para><emphasis>Establish a local copy of the Linux Yocto kernel files on your 
                         system</emphasis>:  In order to make modifications to the kernel you need two things:
-                        a bare clone of the Linux Yocto kernel you are modifying and a copy of that 
-                        bare clone. 
+                        a bare clone of the Linux Yocto 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. 
+                        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'>Linux Yocto Kernel</link> in  
-                        <xref linkend='getting-setup'>Getting Setup</xref> earlier in this manual.
-                        </para></listitem>
+                        "<link linkend='local-kernel-files'>Linux Yocto Kernel</link>" 
+                        earlier in this manual.</para></listitem>
                     <listitem><para><emphasis>Make changes to the kernel source code if 
                         applicable</emphasis>:  Modifying the kernel does not always mean directly
                         changing source files. 
-                        However, if you have to do this then you make the changes in the local 
+                        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
+                        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>                      
                     <listitem><para><emphasis>Make kernel configuration changes
-                        to your local kernel layer if applicable</emphasis>:  
-                        If your situation calls for changing the kernel's configuration you can 
+                        if applicable</emphasis>:  
+                        If your situation calls for changing the kernel's configuration, you can 
                         use <filename>menuconfig</filename>
                         to enable and disable kernel configurations.  
-                        Using <filename>menuconfig</filename> allows you to develop and test the 
-                        configuration changes you are making to the kernel.</para></listitem>                      
-                    <listitem><para><emphasis>Add new kernel recipes if applicable</emphasis>:  The standard 
+                        Using <filename>menuconfig</filename> allows you to interactively develop and test the 
+                        configuration changes you are making to the kernel.
+                        When saved, changes using <filename>menuconfig</filename> update the kernel's
+                        <filename>.config</filename>.
+                        Try to resist the temptation of directly editing the <filename>.config</filename> 
+                        file found in the Yocto Project build directory at 
+                        <filename>tmp/sysroots/&lt;machine-name&gt;/kernel</filename>.
+                        Doing so, can produce unexpected results when the Yocto Project build system 
+                        regenerates the configuration file.</para>
+                        <para>Once you are satisfied with the configuration changes made using 
+                        <filename>menuconfig</filename>, you can directly examine the 
+                        <filename>.config</filename> file against a saved original and gather those
+                        changes into a config fragment to be placed inside a  
+                        <filename>.bbappend</filename></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 
                         <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> 
+                        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 for the Yocto Project build system in order for it to create your image.  
-                        If you have not done so you need to get the build environment ready by sourcing 
+                        or recipe changes), there remains a few things 
+                        you need to do in order for the Yocto Project 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='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#building-image'>
-                        Building an Image</ulink> section of the Yocto Project Quick Start.    
+                        "<ulink url='http://www.yoctoproject.org/docs/latest/yocto-project-qs/yocto-project-qs.html#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 
-                        end of this manual.</para></listitem>
-                    <listitem><para><emphasis>Build the image</emphasis>:  The Yocto Project uses the BitBake 
+                        at the end of this manual.</para></listitem>
+                    <listitem><para><emphasis>Build the image</emphasis>:  The Yocto Project 
+                        build system Poky uses the BitBake 
                         tool to build images based on the type of image you want to create.  
                         You can find more information on BitBake 
                         <ulink url='http://bitbake.berlios.de/manual/'>here</ulink>.</para>
                         <para>The build process supports several types of images to satisfy different needs.  
-                        See 
-                        <ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html#ref-images'>
-                        Reference: Images</ulink> in the 
-                        <ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html'>
+                        See the appendix
+                        "<ulink url='http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html#ref-images'>Reference: Images</ulink>" in the 
+                        <ulink url='http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html'>
                         Yocto Project Reference Manual</ulink> 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 
+                        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.
-                        [WRITER'S NOTE:  Not sure if the layer is meta-kernel-dev or if it would be 
-                        a new layer copied from the work done there.]</para></listitem>
-                    <listitem><para><emphasis>Push your configuration and recipe changes upstream to the 
-                        linux Yocto Git repository (in-tree changes)</emphasis>:  If the changes you made
-                        are suited for all Linux Yocto users you might want to push the changes up into 
-                        the Linux Yocto Git repository so that they become part of the kernel tree
-                        and available to everyone using the kernel.</para></listitem> 
+                        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 Linux Yocto users, you might want to send them on for inclusion
+                        into the Linux Yocto 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> 
                 </orderedlist>
             </para>
         </section>
@@ -470,11 +487,194 @@
 </section>
 
 <section id='place-holder-section-two'>
-    <title>Place-Holder Section For Application Development</title>
+    <title>Application Development Workflow</title>
 
     <para>
-        Text needed here.
+        Application development involves creation of an application that you want to be able
+        to run on your target hardware, which is running a Linux Yocto image.
+        The Yocto Project provides an Application Development Toolkit (ADT) that 
+        facilitates quick development and integration of your application into its run-time environment. 
+        Using the ADT you can employ cross-development toolchains designed for your target hardware
+        to 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 
+        allow you to develop, deploy, and test your application all from within Eclipse.
     </para>
+
+    <para>
+        While we strongly suggest using the Yocto Project ADT to develop your application, you might
+        not want to.  
+        If this is the case, you can still use pieces of the Yocto Project for your development process. 
+        However, because the process can vary greatly, this manual does not provide detail on the process.
+    </para>
+
+    <section id='workflow-using-the-adt-and-eclipse'>
+        <title>Workflow Using the ADT and <trademark class='trade'>Eclipse</trademark></title>
+
+        <para>
+            To help you understand how application development works in the Yocto Project ADT
+            environment, this section 
+            provides an overview of the general development process.
+            If you want to see a detailed example of the process as it is used from within the Eclipse 
+            IDE, see 
+            <ulink url='http://www.yoctoproject.org/docs/latest/adt-manual/adt-manual.html'>
+            The Application Development Toolkit (ADT) User's Manual</ulink>.
+        </para>
+
+        <para>
+            This illustration and the following list summarizes the application development general workflow.
+        </para>
+
+        <para>
+            <imagedata fileref="figures/app-dev-flow.png" 
+                width="7in" depth="8in" align="center" scale="100" />
+        </para> 
+
+        <para>
+            <orderedlist>
+                <listitem><para><emphasis>Prepare the Host System for the Yocto Project</emphasis>:  
+                    See  
+                    "<ulink url='http://www.yoctoproject.org/docs/latest/yocto-project-qs/yocto-project-qs.html#the-linux-distro'>The Linux Distributions</ulink>" and  
+                    "<ulink url='http://www.yoctoproject.org/docs/latest/yocto-project-qs/yocto-project-qs.html#packages'>The Packages</ulink>" sections both
+                    in the Yocto Project Quick Start for requirements.</para></listitem>
+
+<!--
+WRITER NOTE:  The areas to get the kernel and root filesystem are located in the Index of 
+              downloads.  There are many forms of each.  The files that have "rootfs" are just the 
+              target root filesystems.  The file that is very small and starts with bzImage is just
+              the kernel image isolated so that it can be written to a special on-board area of 
+              flash memory.  Some systems require this.  In the machines directory there are  
+              files that combine the kernel image and the root filesystem.  These files are the ISO 
+              and HDDIMG files.  ISO images are designed to be deployed on a DVD or CD.  The ISO
+              images are designed to be deployed on a USB stick.  There might be some relics in 
+              the machine directory.  For example, there is the "emenlow-bernard-5.0.0.tar.bz2" 
+              file.  Nobody seems to know what this is.  If a developer needs the image and the 
+              root filesystem I think that they want the small kernel image and a matching root 
+              filesystem.  Although, Paul Eggleton says that the HDDIMG types could be used to 
+              develop on.  I am not sure that we can use one of those in the ADT though as they 
+              want you to point to the kernel image and the target root filesystem.  Maybe you 
+              could just point to the same spot.  I am not sure.
+-->
+
+                <listitem><para><emphasis>Secure the Linux Yocto Kernel Target Image</emphasis>:  
+                    You must have a target kernel image that has been built using the Yocto Project.</para>
+                    <para>Depending on whether the Yocto Project has a pre-built image that matches your target
+                    architecture and where you are going to run the image while you develop your application
+                    (QEMU or real hardware), the area you get the image from differs.
+                        <itemizedlist>
+                            <listitem><para>Download the image from  
+                                <ulink url='http://www.yoctoproject.org/downloads/yocto-1.1/machines/'>  
+                                <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='http://www.yoctoproject.org/downloads/yocto-1.1/machines/qemu/'>  
+                                <filename>machines/qemu</filename></ulink> if your target architecture is supported
+                                and you are going to develop and test your application using the QEMU 
+                                emulator.</para></listitem>
+                            <listitem><para>Build your image if you cannot find a pre-built image that matches
+                                your target architecture.
+                                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 
+                                Linux Yocto kernel.</para></listitem>
+                        </itemizedlist></para>
+                    <para>For information on pre-built kernel image naming schemes for images 
+                    that can run on the QEMU emulator, see the
+                    "<ulink url='http://www.yoctoproject.org/docs/latest/yocto-project-qs/yocto-project-qs.html#using-pre-built'>Using Pre-Built Binaries and QEMU</ulink>"
+                    section in  
+                    <ulink url='http://www.yoctoproject.org/docs/latest/yocto-project-qs/yocto-project-qs.html'>
+                    The Yocto Project Quick Start</ulink>.</para></listitem>
+                <listitem><para><emphasis>Install the ADT</emphasis>:  
+                    The ADT provides a target-specific cross-development toolchain, the root filesystem,
+                    the QEMU emulator, and other tools that can help you develop your application.
+                    While it is possible to get these pieces separately, the Yocto Project provides an 
+                    easy method.
+                    You can get these pieces by running an ADT installer script, which is configurable.
+                    For information on how to install the ADT, see the
+                    "<ulink url='http://www.yoctoproject.org/docs/latest/adt-manual/adt-manual.html#using-the-adt-installer'>Using the ADT Installer</ulink>" section in
+                    <ulink url='http://www.yoctoproject.org/docs/latest/adt-manual/adt-manual.html'>The Yocto Project
+                    Application Development (ADT) User's Manual</ulink>.</para></listitem>
+                <listitem><para><emphasis>If Applicable, Secure the Target Root Filesystem</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.
+                    Depending on the type of image you are running, the root filesystem you need differs. 
+                    For example, if you are developing an application that runs on an image that 
+                    supports Sato, you need to get root filesystem that supports Sato.
+                    </para></listitem>
+                <listitem><para><emphasis>Create and Build your Application</emphasis>:  
+                    At this point, you need to have source files for your application.
+                    Once you have the files, you can use the Eclipse IDE to import them and build the 
+                    project. 
+                    If you are not using Eclipse, you need to use the cross-development tools you have 
+                    installed to create the image.</para></listitem>                      
+                <listitem><para><emphasis>Deploy the Image with the Application</emphasis>:  
+                    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.
+                    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 
+                    set of user-space tools installed along with the ADT to debug your application. 
+                    Of course, the same user-space tools are available separately to use if you choose
+                    not to use the Eclipse IDE.</para></listitem>
+           </orderedlist>
+        </para>
+    </section>
+
+    <section id='workflow-without-adt'>
+        <title>Workflow Without ADT</title>
+
+        <para>
+            If you want to develop an application outside of the Yocto Project ADT environment, you 
+            can still employ the cross-development toolchain, the QEMU emulator, and a number of supported
+            target image files.  
+            You just need to follow these general steps:
+            <orderedlist>
+                <listitem><para><emphasis>Install the cross-development toolchain for your target hardware:</emphasis> 
+                    For information on how to install the toolchain, see the
+                    "<ulink url='http://www.yoctoproject/docs/1.1/adt-manual/adt-manual.html#using-an-existing-toolchain-tarball'>Using a Cross-Toolchain Tarball</ulink>" section in
+                    <ulink url='http://www.yoctoproject/docs/1.1/adt-manual/adt-manual.html'>The Yocto Project
+                    Application Development (ADT) User's Manual</ulink>.</para></listitem>
+                <listitem><para><emphasis>Download the Target Image:</emphasis>  The Yocto Project supports
+                    several target architectures and has many pre-built kernel images and root filesystem 
+                    images.</para>
+                    <para>If you are going to develop your application on hardware, go to the 
+                    <ulink url='http://www.yoctoproject.org/downloads/yocto-1.1/machines/'>  
+                    <filename>machines</filename></ulink> download area and choose a target machine area
+                    from which to download the kernel image and root filesystem.
+                    This download area could have several files in it that support development using   
+                    actual hardware. 
+                    For example, the area might contain <filename>.hddimg</filename> files that combine the 
+                    kernel image with the filesystem, boot loaders, etc.
+                    Be sure to get the files you need for your particular development process.</para>
+                    <para>If you are going to develop your application and then run and test it using the QEMU
+                    emulator, go to the 
+                    <ulink url='http://www.yoctoproject.org/downloads/yocto-1.1/machines/qemu/'>  
+                    <filename>machines/qemu</filename></ulink> download area.
+                    From this area, go down into the directory for your target architecture
+                    (e.g. <filename>qemux86_64</filename> for an 
+                    <trademark class='registered'>Intel</trademark>-based 64-bit architecture).
+                    Download kernel, root filesystem, and any other files you need for your process.
+                    <note>In order to use the root filesystem in QEMU, you need to extract it.
+                    See the 
+                    "<ulink url='http://www.yoctoproject.org/docs/latest/adt-manual/adt-manual.html#extracting-the-root-filesystem'>Extracting the Root Filesystem</ulink>" section for information on how to extract the 
+                    root filesystem.</note></para></listitem>
+                <listitem><para><emphasis>Develop and Test your Application:</emphasis>  At this point, 
+                    you have the tools to develop your application.  
+                    If you need to separately install and use the QEMU emulator, you can go to 
+                    <ulink url='http://www.qemu.org'>QEMU Home Page</ulink> to download and learn about the 
+                    emulator.</para></listitem>
+            </orderedlist>
+        </para>
+    </section>
 </section>
 
 </chapter>

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

@@ -7,12 +7,12 @@
 
 <para>
     This chapter helps you understand the Yocto Project as an open source development project.
-    In general, working in an open-source environment is very different than working in a 
-    proprietary environment.  
+    In general, working in an open source environment is very different from working in a 
+    closed, proprietary environment.  
     Additionally, the Yocto Project uses specific tools and constructs as part of its development 
     environment.  
-    The chapter specifically addresses open source philosophy, licensing issues, code repositories, 
-    the open source distributed version control system Git, and best practices using Yocto Project.
+    This chapter specifically addresses open source philosophy, licensing issues, code repositories, 
+    the open source distributed version control system Git, and best practices using the Yocto Project.
 </para>
 
 <section id='open-source-philosophy'>
@@ -20,10 +20,10 @@
 
     <para>
         Open source philosophy is characterized by software development directed by peer production 
-        and collaboration through a concerned community of developers.  
+        and collaboration through an active community of developers.
         Contrast this to the more standard centralized development models used by commercial software 
         companies where a finite set of developers produce a product for sale using a defined set 
-        of procedures that ultimately result in an end-product whose architecture and source material 
+        of procedures that ultimately result in an end product whose architecture and source material
         are closed to the public.
     </para>
 
@@ -33,23 +33,21 @@
         stake in the software project.  
         The open source environment contains new copyright, licensing, domain, and consumer issues 
         that differ from the more traditional development environment.  
-        In an open source environment the end-product, source material, and documentation are 
+        In an open source environment, the end product, source material, and documentation are
         all available to the public at no cost.
     </para>
 
     <para>
         A benchmark example of an open source project is the Linux Kernel, which was initially conceived 
         and created by Finnish computer science student Linus Torvalds in 1991.  
-        Conversely, a good example of a non-open source project is the Windows family of operating 
-        systems developed by Microsoft Corporation.
+        Conversely, a good example of a non-open source project is the 
+        <trademark class='registered'>Windows</trademark> family of operating 
+        systems developed by <trademark class='registered'>Microsoft</trademark> Corporation.
     </para>
 
     <para>
         Wikipedia has a good historical description of the Open Source Philosophy  
         <ulink url='http://en.wikipedia.org/wiki/Open_source'>here</ulink>. 
-    </para>
-
-    <para>
         You can also find helpful information on how to participate in the Linux Community 
         <ulink url='http://ldn.linuxfoundation.org/book/how-participate-linux-community'>here</ulink>.
     </para>
@@ -66,21 +64,21 @@
         From the interface, you can click on any particular item in the "Name" column and 
         see the URL at the bottom of the page that you need to set up a Git repository for 
         that particular item.
-        The ability to create Git repositories of the Yocto Project source allows you to 
+        Having a local Git repository of the Yocto Project files allows you to 
         make changes, contribute to the history, and ultimately enhance the Yocto Project's 
         tools, Board Support Packages, and so forth.
     </para>
 
     <para>  
         Conversely, if you are a developer that is not interested in contributing back to the 
-        Yocto Project you have the ability to simply download and extract release tarballs
+        Yocto Project, you have the ability to simply download and extract release tarballs
         and use them within the Yocto Project environment.
-        All that is required is a particular release of Yocto Project, a kernel, and 
+        All that is required is a particular release of the Yocto Project and 
         your application source code.  
     </para>
 
     <para>
-        For any supported release of Yocto Project you can go to the Yocto Project website’s 
+        For any supported release of Yocto Project, you can go to the Yocto Project website’s 
         <ulink url='http://www.yoctoproject.org/download'>download page</ulink> and get a 
         tarball of the release.  
         You can also go to this site to download any supported BSP tarballs.
@@ -103,12 +101,13 @@
                 <para>
                 <imagedata fileref="figures/source-repos.png" align="center" width="6in" depth="4in" />
                 </para></listitem>
-            <listitem><para><anchor id='index-downloads' /><emphasis><ulink url='http://autobuilder.yoctoproject.org/downloads/'>Index of /downloads:</ulink></emphasis>
-                This area contains an index of the Eclipse-plugin, miscellaneous support, poky, pseudo, and 
-                all released versions of Yocto Project in the form of images or tarballs.
+            <listitem><para><anchor id='index-downloads' /><emphasis><ulink url='http://downloads.yoctoproject.org/releases/'>Index of /releases:</ulink></emphasis>
+                This area contains an index of downloads such as 
+                the <trademark class='trade'>Eclipse</trademark>
+                Yocto Plug-in, miscellaneous support, Poky, pseudo, cross-development toolchains,
+                and all released versions of Yocto Project in the form of images or tarballs.
                 Downloading and extracting these files does not produce a Git repository but rather 
-                a snapshot of a particular release or image. 
-                [WRITER NOTE: link will be http://downloads.yoctoproject.org.]</para>
+                a snapshot of a particular release or image.</para>
                 <para>
                 <imagedata fileref="figures/index-downloads.png" align="center" width="6in" depth="4in" />
                 </para></listitem>
@@ -116,7 +115,7 @@
                 This page on the Yocto Project website allows you to download any Yocto Project
                 release or Board Support Package (BSP) in tarball form.
                 The tarballs are similar to those found in the 
-                <ulink url='http://autobuilder.yoctoproject.org/downloads/'>Index of /downloads:</ulink> area.</para>
+                <ulink url='http://downloads.yoctoproject.org/releases/'>Index of /releases:</ulink> area.</para>
                 <para>
                 <imagedata fileref="figures/yp-download.png" align="center" width="6in" depth="4in" />
             </para></listitem>
@@ -130,77 +129,119 @@
     <para>
         Following is a list of terms and definitions users new to the Yocto Project development 
         environment might find helpful.
-        Some terms are universal but are included here just in case:
+        While some of these terms are universal, the list includes them just in case:
     <itemizedlist>
-        <listitem><para><emphasis>Image</emphasis> - An image is the result produced when 
+        <listitem><para><emphasis>Append Files:</emphasis> Files that append build information to 
+            a recipe file.  
+            Information in append files overrides the information in the similarly-named recipe file.
+            Append files use the <filename>.bbappend</filename> filename suffix.</para></listitem>
+        <listitem><para><emphasis>BitBake:</emphasis> The task executor and scheduler used by 
+            the Yocto Project to build images. 
+            For more information on BitBake, see the <ulink url='http://bitbake.berlios.de/manual/'>
+            BitBake documentation</ulink>.</para></listitem>
+        <listitem><para><emphasis>Classes:</emphasis> Files that provide for logic encapsulation
+            and inheritance allowing commonly used patterns to be defined once and easily used 
+            in multiple recipes.  
+            Class files end with the <filename>.bbclass</filename> filename extension.</para></listitem>
+        <listitem><para><emphasis>Configuration File:</emphasis>  Configuration information in various
+            <filename>.conf</filename> files provides global definitions of variables.
+            The <filename>conf/local.conf</filename> configuration file in the Yocto Project
+            build directory contains user-defined variables that affect each build.
+            The <filename>meta-yocto/conf/distro/poky.conf</filename> configuration file
+            defines Yocto ‘distro’ configuration
+            variables used only when building with this policy.  
+            Machine configuration files, which 
+            are located throughout the Yocto Project file structure, define
+            variables for specific hardware and are only used when building for that target 
+            (e.g. the <filename>machine/beagleboard.conf</filename> configuration file defines 
+            variables for the Texas Instruments ARM Cortex-A8 development board).  
+            Configuration files end with a <filename>.conf</filename> filename extension.</para></listitem>
+        <listitem><para><emphasis>Cross-Development Toolchain:</emphasis> A collection of software development
+            tools and utilities that allow you to develop software for targeted architectures.
+            This toolchain contains cross-compilers, linkers, and debuggers that are specific to 
+            an architecture.
+            You can use the Yocto Project to build cross-development toolchains in tarball form that when 
+            unpacked contain the development tools you need to cross-compile and test your software.
+            The Yocto Project ships with images that contain toolchains for supported architectures
+            as well.
+            Sometimes this toolchain is referred to as the meta-toolchain.</para></listitem>
+        <listitem><para><emphasis>Image:</emphasis> An image is the result produced when 
             BitBake processes a given collection of recipes and related metadata.
             Images are the binary output that runs on specific hardware and for specific
             use cases.
             For a list of the supported image types that the Yocto Project provides, see the
-            <ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html#ref-images'>
-            Reference: Images</ulink> appendix in
-            <ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html'>
+            "<ulink url='http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html#ref-images'>Reference: Images</ulink>"
+            appendix in
+            <ulink url='http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html'>
             The Yocto Project Reference Manual</ulink>.</para></listitem>
-        <listitem><para><emphasis>Recipe</emphasis> - A set of instructions for building packages.  
-            A recipe describes where you get source code and which patches to apply.
-            Recipes describe dependencies for libraries or for other recipes and they 
-            also contain configuration and compilation options.  
-            Recipes contain the logical unit of execution, the software/images to build, and 
-            use the <filename>.bb</filename> file extension.</para></listitem>
-        <listitem><para><emphasis>BitBake</emphasis> - The task executor and scheduler used by Yocto Project
-            to build images. 
-            For more information on BitBake, see the <ulink url='http://bitbake.berlios.de/manual/'>
-            BitBake documentation</ulink>.</para></listitem>
-        <listitem><para><emphasis>Package</emphasis> - The packaged output from a baked recipe.
-            A package is generally the compiled binaries produced from the recipe's sources.  
-            You ‘bake’ something by running it through BitBake.</para></listitem>
-        <listitem><para><emphasis>Layer</emphasis> - A collection of recipes representing the core, 
+        <listitem><para><emphasis>Layer:</emphasis> A collection of recipes representing the core, 
             a BSP, or an application stack.</para></listitem>
-        <listitem><para><emphasis>Metadata</emphasis> - A term used throughout the Yocto Project 
-            documentation that refers to the files that BitBake parses when building an image. 
+        <listitem><para><emphasis>Metadata:</emphasis> The files that BitBake parses when building an image. 
             Metadata includes recipes, classes, and configuration files.</para></listitem>
-        <listitem><para><emphasis>Meta-Toolchain</emphasis> - A collection of software development
-            tools and utilities that allow you to develop software for targeted architectures.
-            These toolchains contain cross-compilers, linkers, and debuggers that are specific to 
-            an architecure.
-            You can use the Yocto Project to build meta-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.</para></listitem>
-        <listitem><para><emphasis>Configuration File</emphasis>:  Configuration information in the 
-            <filename>.conf</filename> files provides global definitions of variables.  
-            The <filename>build/conf/local.conf</filename> configuration file defines user-defined variables
-            that effect each build.  
-            The <filename>distro/poky.conf</filename> configuration file defines Yocto ‘distro’ configuration 
-            variables used only when building with this policy.  
-            The <filename>machine/beagleboard.conf</filename> configuration file defines variables
-            for the Beagleboard and are only used when building for that target 
-            (i.e. Texas Instruments ARM Cortex-A8 development board).  
-            Configuration files end with a <filename>.conf</filename> filename extension.</para></listitem>
-        <listitem><para><emphasis>Classes</emphasis> - Files that provide for logic encapsulation
-            and inheritance allowing commonly used patterns to be defined once and easily used 
-            in multiple recipes.  
-            Class files end with the <filename>.bbclass</filename> filename extension.</para></listitem>
-        <listitem><para><emphasis>Append Files</emphasis> - Files that append build information to 
-            a recipe file.  
-            Information in append files override the information in the similarly-named recipe file.
-            Append files use the <filename>.bbappend</filename> filename suffix.</para></listitem>
-        <listitem><para><emphasis>Tasks</emphasis> - Arbitrary groups of software Recipes.  
-            You simply use Tasks to hold recipes that when built usually accomplish a single task.  
-            For example, a task could contain the recipes for a company’s proprietary or value-add software.  
-            Or the task could contain the recipes that enable graphics. 
-            A task is really just another recipe.  
-            Because task files are recipes, they end with the <filename>.bb</filename> filename 
-            extension.</para></listitem>
-        <listitem><para><emphasis>OE-Core</emphasis> - A core set of metadata originating 
+        <listitem><para><emphasis>OE-Core:</emphasis> A core set of metadata originating 
             with OpenEmbedded (OE) that is shared between OE and the Yocto Project.
             This metadata is found in the <filename>meta</filename> directory of the Yocto Project
             files.</para></listitem>
-        <listitem><para><emphasis>Upstream</emphasis> - A reference to source code or repositories
+        <listitem><para><emphasis>Package:</emphasis> The packaged output from a baked recipe.
+            A package is generally the compiled binaries produced from the recipe's sources.  
+            You ‘bake’ something by running it through BitBake.</para></listitem>
+        <listitem><para><emphasis>Poky:</emphasis> The build tool that the Yocto Project 
+            uses to create images.</para></listitem>
+        <listitem><para><emphasis>Recipe:</emphasis> A set of instructions for building packages.  
+            A recipe describes where you get source code and which patches to apply.
+            Recipes describe dependencies for libraries or for other recipes, and they 
+            also contain configuration and compilation options.  
+            Recipes contain the logical unit of execution, the software/images to build, and 
+            use the <filename>.bb</filename> file extension.</para></listitem>
+        <listitem><para><emphasis>Tasks:</emphasis> Arbitrary groups of software Recipes.  
+            You simply use Tasks to hold recipes that, when built, usually accomplish a single task.  
+            For example, a task could contain the recipes for a company’s proprietary or value-add software.  
+            Or, the task could contain the recipes that enable graphics. 
+            A task is really just another recipe.  
+            Because task files are recipes, they end with the <filename>.bb</filename> filename 
+            extension.</para></listitem>
+        <listitem><para><emphasis>Upstream:</emphasis> A reference to source code or repositories
             that are not local to the development system but located in a master area that is controlled
             by the maintainer of the source code.
-            For example, in order for a developer to work on a particular piece of code they need to 
+            For example, in order for a developer to work on a particular piece of code, they need to 
             first get a copy of it from an "upstream" source.</para></listitem>
+        <listitem><para><emphasis>Yocto Project Files:</emphasis>
+            This term refers to the directory structure created as a result of downloading 
+            and unpacking a Yocto Project release tarball or setting up a Git repository
+            by cloning <filename>git://git.yoctoproject.org/poky</filename>.
+            Sometimes the term "the Yocto Project Files structure" is used as well.</para>
+            <para>The Yocto Project files contain BitBake, Documentation, metadata and 
+            other files that all support the development environment. 
+            Consequently, you must have the Yocto Project files in place on your development 
+            system in order to do any development using the Yocto Project.</para>
+            <para>The name of the top-level directory of the Yocto Project file structure  
+            is derived from the Yocto Project release tarball.
+            For example, downloading and unpacking <filename>poky-edison-6.0.tar.bz2</filename>
+            results in a Yocto Project file structure whose Yocto Project source directory is named 
+            <filename>poky-edison-6.0</filename>.
+            If you create a Git repository, then you can name the repository anything you like.</para>
+            <para>You can find instruction on how to set up the Yocto Project files on your 
+            host development system by reading 
+            the 
+            "<ulink url='http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#getting-setup'>Getting
+            Setup</ulink>" section.</para></listitem>
+        <listitem><para><emphasis>Yocto Project Build Directory:</emphasis>
+            This term refers to the area used by the Yocto Project for builds.  
+            The area is created when you <filename>source</filename> the Yocto Project setup 
+            environment script that is found in the Yocto Project files area. 
+            (e.g. <filename>oe-init-build-env</filename>).
+            You can create the Yocto Project build directory anywhere you want on your 
+            development system.
+            Here is an example that creates the directory in <filename>mybuilds</filename> 
+            and names the Yocto Project build directory <filename>YP-6.0</filename>:
+            <literallayout class='monospaced'> 
+     $ source poky-edison-6.0/oe-init-build-env $HOME/mybuilds/YP-6.0
+            </literallayout>
+            If you don't specifically name the directory, BitBake creates it 
+            in the current directory and uses the name <filename>build</filename>.
+            Also, if you supply an existing directory, then BitBake uses that 
+            directory as the Yocto Project build directory and populates the build hierarchy
+            beneath it.</para></listitem>
     </itemizedlist>
     </para>
 </section>
@@ -209,9 +250,9 @@
     <title>Licensing</title>
 
     <para>
-        Because open source projects are open to the public they have different licensing structures in place.  
+        Because open source projects are open to the public, they have different licensing structures in place.  
         License evolution for both Open Source and Free Software has an interesting history.  
-        If you are interested in the history you can find basic information here:
+        If you are interested in this history, you can find basic information here:
     <itemizedlist>
         <listitem><para><ulink url='http://en.wikipedia.org/wiki/Open-source_license'>Open source license history</ulink>
             </para></listitem>
@@ -235,15 +276,20 @@
 
     <para>
         When you build an image using Yocto Project, the build process uses a known list of licenses to 
-        ensure compliance.  
-        Once the build completes, the list of all licenses found and used during the build are 
-        kept in the resulting build directory at 
-        <filename>&lt;build_directory&gt;/tmp/deploy/images/licenses</filename>.  
+        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 
+        kept in the Yocto Project build directory at 
+        <filename>tmp/deploy/images/licenses</filename>.
+    </para>
+
+    <para>  
         If a module requires a license that is not in the base list, the build process 
         generates a warning during the build.  
         These tools make it easier for a developer to be certain of the licenses with which
         their shipped products must comply.
-        However, it is still up to the developer to resolve potential licensing issues.
+        However, even with these tools it is still up to the developer to resolve potential licensing issues.
     </para>
 
     <para>
@@ -254,14 +300,13 @@
         for a standard format for communicating the components, licenses, and copyrights 
         associated with a software package.  
         <ulink url='http://opensource.org'>OSI</ulink> is a corporation dedicated to the Open Source 
-        Definition and the effort for reviewing 
-        and approving licenses that are OSD-conformant.  
+        Definition and the effort for reviewing and approving licenses that are OSD-conformant.  
     </para>
 
     <para>
         You can find a list of the combined SPDX and OSI licenses that the Yocto Project uses 
         <ulink url='http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/files/common-licenses'>here</ulink>.
-        The wiki page discusses the license infrastructure used by the Yocto Project.
+        This wiki page discusses the license infrastructure used by the Yocto Project.
     </para>
 </section>
 
@@ -282,7 +327,7 @@
         You do not have to be an expert in Git to be functional.  
         A good place to look for instruction on a minimal set of Git commands is 
         <ulink url='http://git-scm.com/documentation'>here</ulink>.   
-        If you need to download Git you can do so 
+        If you need to download Git, you can do so 
         <ulink url='http://git-scm.com/download'>here</ulink>. 
     </para>
 
@@ -294,7 +339,7 @@
         This methodology also allows for an environment in which you can do lots of 
         experimentation on your project as you develop changes or new features.  
         For example, you can create a “branch”, experiment with some feature, and then 
-        if you like the feature you incorporate the branch into the tree.  
+        if you like the feature, you incorporate the branch into the tree.  
         If you don’t, you cut the branch off by deleting it.  
     </para>
 
@@ -309,55 +354,63 @@
         omits the many arguments they support.  
         See the Git documentation for complete descriptions and strategies on how to use these commands:
     <itemizedlist>
-        <listitem><para><emphasis><filename>git init</filename></emphasis> – Initializes an empty Git repository.  
+        <listitem><para><emphasis><filename>git init</filename>:</emphasis> Initializes an empty Git repository.  
             You cannot use Git commands unless you have a <filename>.git</filename> repository.</para></listitem>
-        <listitem><para><emphasis><filename>git clone</filename></emphasis> – Creates a clone of a repository.  
-            During collaboration this command allows you to create a local repository that is on 
+        <listitem><para><emphasis><filename>git clone</filename>:</emphasis> Creates a clone of a repository.  
+            During collaboration, this command allows you to create a local repository that is on 
             equal footing with a fellow developer’s repository.</para></listitem>
-        <listitem><para><emphasis><filename>git add</filename></emphasis> – Adds updated file contents to the index that 
+        <listitem><para><emphasis><filename>git add</filename>:</emphasis> Adds updated file contents 
+            to the index that 
             Git uses to track changes.  
-            All files that have changed must be added before they can be committed.</para></listitem>
-        <listitem><para><emphasis><filename>git commit</filename></emphasis> – Creates a “commit” that documents 
+            You must add all files that have changed before you can commit them.</para></listitem>
+        <listitem><para><emphasis><filename>git commit</filename>:</emphasis> Creates a “commit” that documents 
             the changes you made.  
             Commits are used for historical purposes, for determining if a maintainer of a project 
             will allow the change, and for ultimately pushing the change from your local Git repository 
             into the project’s upstream (or master) repository.</para></listitem>
-        <listitem><para><emphasis><filename>git status</filename></emphasis> – Reports any modified files that 
-            possibly need added and committed.</para></listitem>
-        <listitem><para><emphasis><filename>git checkout &lt;branch-name&gt;</filename></emphasis> - Changes 
-            your working branch.  This command is analogous to “cd”.</para></listitem>
-        <listitem><para><emphasis><filename>git checkout –b &lt;working-branch&gt;</filename></emphasis> - Creates 
+        <listitem><para><emphasis><filename>git status</filename>:</emphasis> Reports any modified files that 
+            possibly need to be added and committed.</para></listitem>
+        <listitem><para><emphasis><filename>git checkout &lt;branch-name&gt;</filename>:</emphasis> Changes 
+            your working branch.  
+            This command is analogous to “cd”.</para></listitem>
+        <listitem><para><emphasis><filename>git checkout –b &lt;working-branch&gt;</filename>:</emphasis> Creates 
             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 
+        <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 -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 
+        <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>
-        <listitem><para><emphasis><filename>git pull</filename></emphasis> – Retrieves information from an upstream Git 
+        <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 upstream repository 
-            from which the project’s maintainer uses to pull changes into the master repository.</para></listitem>
-        <listitem><para><emphasis><filename>git push</filename></emphasis> – Sends all your local changes you 
-            have committed to an upstream 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>
+        <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 
             project’s master repository.</para></listitem>
-        <listitem><para><emphasis><filename>git merge</filename></emphasis> – Combines or adds changes from one 
+        <listitem><para><emphasis><filename>git merge</filename>:</emphasis> Combines or adds changes from one 
             local branch of your repository with another branch.  
-            When you create a local Git repository the default branch is named “master”.  
+            When you create a local Git repository, the default branch is named “master”.  
             A typical workflow is to create a temporary branch for isolated work, make and commit your 
-            changes, switch to the master branch, merge the changes from the temporary branch into the 
-            master branch, and then delete the temporary branch</para></listitem>
-        <listitem><para><emphasis><filename>git cherry-pick</filename></emphasis> – Choose and apply specific 
+            changes, switch to your local master branch, merge the changes from the temporary branch into the 
+            local master branch, and then delete the temporary branch.</para></listitem>
+        <listitem><para><emphasis><filename>git cherry-pick</filename>:</emphasis> Choose and apply specific 
             commits from one branch into another branch.  
             There are times when you might not be able to merge all the changes in one branch with 
             another but need to pick out certain ones.</para></listitem>
-        <listitem><para><emphasis><filename>gitk</filename></emphasis> – Provides a GUI view of the branches 
+        <listitem><para><emphasis><filename>gitk</filename>:</emphasis> Provides a GUI view of the branches 
             and changes in your local Git repository.  
-            This command is a good way to see where things have diverged in your local repository.</para></listitem>
-        <listitem><para><emphasis><filename>git log</filename></emphasis> – Reports a history of your changes to the 
+            This command is a good way to graphically see where things have diverged in your 
+            local repository.</para></listitem>
+        <listitem><para><emphasis><filename>git log</filename>:</emphasis> Reports a history of your changes to the 
             repository.</para></listitem>
+        <listitem><para><emphasis><filename>git diff</filename>:</emphasis> Displays line-by-line differences
+            between your local working files and the same files in the upstream Git repository that your 
+            branch currently tracks.</para></listitem>
     </itemizedlist>
     </para>
 </section>
@@ -369,17 +422,22 @@
         This section provides some overview on workflows using Git.  
         In particular, the information covers basic practices that describe roles and actions in a 
         collaborative development environment.  
-        Again, if you are familiar with this type of development environment you might want to just skip the section. 
+        Again, if you are familiar with this type of development environment, you might want to just 
+        skip this section.
     </para>
 
     <para>
         The Yocto Project files are maintained using Git in a "master" branch whose Git history 
         tracks every change and whose structure provides branches for all diverging functionality.
-        Although there is no need to use Git, This practice is typical for open-source projects.
-        For the Yocto Project a key individual called the "maintainer" is responsible for "master".  
+        Although there is no need to use Git, many open source projects do so.
+        For the Yocto Project, a key individual called the "maintainer" is responsible for the "master"
+        branch of the Git repository.
         The "master" branch is the “upstream” repository where the final builds of the project occur.  
         The maintainer is responsible for allowing changes in from other developers and for 
         organizing the underlying branch structure to reflect release strategies and so forth.  
+        <note>You can see who is the maintainer for Yocto Project files by examining the 
+        <filename>distro_tracking_fields.inc</filename> file in the Yocto Project
+        <filename>meta/conf/distro/include</filename> directory.</note>  
     </para>
 
     <para>
@@ -394,7 +452,7 @@
         Developers (including contributing community members) create and maintain cloned repositories 
         of the upstream "master" branch.  
         These repositories are local to their development platforms and are used to develop changes.  
-        When a developer is satisfied with a particular feature or change they “push” the changes 
+        When a developer is satisfied with a particular feature or change, they “push” the changes 
         to the appropriate "contrib" repository.
     </para>
 
@@ -417,7 +475,7 @@
         "master" branch of the Git repository, which is controlled by the project’s maintainer.  
         And, we have a set of developers who independently develop, test, and submit changes 
         to "contrib" areas for the maintainer to examine.  
-        The maintainer then chooses which changes are going to become permanently a part of the project.  
+        The maintainer then chooses which changes are going to become a permanent part of the project.
     </para>
 
     <para>
@@ -430,53 +488,56 @@
         The following list describes some of these practices.  
         For more detailed information about these strategies see 
         <ulink url='http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html'>Git Workflows</ulink>. 
-    <itemizedlist>
-        <listitem><para><emphasis>Make Small Changes</emphasis> - It is best to keep your changes you commit 
-            small as compared to bundling many disparate changes into a single commit.  
-            This practice not only keeps things manageable but also allows the maintainer 
-            to more easily include or refuse changes.</para>
-            <para>It is also good practice to leave the repository in a state that allows you to 
-            still successfully build your project.</para></listitem>
-        <listitem><para><emphasis>Use Branches Liberally</emphasis> - It is very easy to create, use, and 
-            delete local branches in your working Git repository.  
-            You can name these branches anything you like.  
-            It is helpful to give them names associated with the particular feature or change 
-            on which you are working.  
-            Once you are done with a feature or change you simply discard the branch.</para></listitem>
-        <listitem><para><emphasis>Merge Changes</emphasis> - The <filename>git merge</filename>
-            command allows you to take the 
-            changes from one branch and fold them into another branch.  
-            This process is especially helpful when more than a single developer might be working 
-            on different parts of the same feature.  
-            Merging changes also automatically identifies any collisions or “conflicts” 
-            that might happen resulting from the same lines of code being altered by two different 
-            developers.</para></listitem>
-        <listitem><para><emphasis>Manage Branches</emphasis> - Because branches are easy to use, you should 
-            use a system where branches indicate varying levels of code readiness.  
-            For example, you can have a “work” branch to develop in, a “test” branch where the code or 
-            change is tested, a “stage” branch where changes are ready to be committed, and so forth.  
-            As your project develops, you can merge code across the branches to reflect ever-increasing 
-            stable states of the development.</para></listitem>
-        <listitem><para><emphasis>Use Push and Pull</emphasis> - The push-pull workflow is based on the 
-            concept of developers “pushing” local commits to a remote repository, which is 
-            usually a contribution repository.  
-            It is also based on the developers “pulling” known states of the project down into their 
-            local development repositories.  
-            This workflow easily allows you to pull changes submitted by other developers from the 
-            upstream repository into your work area ensuring that you have the most recent software 
-            on which to develop.
-            The Yocto Project has two scripts named <filename>create-pull-request</filename> and 
-            <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
-            <filename>scripts</filename>.</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>
-    </itemizedlist>
+        <itemizedlist>
+            <listitem><para><emphasis>Make Small Changes:</emphasis> It is best to keep the changes you commit
+                small as compared to bundling many disparate changes into a single commit.  
+                This practice not only keeps things manageable but also allows the maintainer 
+                to more easily include or refuse changes.</para>
+                <para>It is also good practice to leave the repository in a state that allows you to 
+                still successfully build your project.  In other words, do not commit half of a feature,
+                then add the other half in a separate, later commit.  
+                Each commit should take you from one buildable project state to another 
+                buildable state.</para></listitem>
+            <listitem><para><emphasis>Use Branches Liberally:</emphasis> It is very easy to create, use, and 
+                delete local branches in your working Git repository.  
+                You can name these branches anything you like.  
+                It is helpful to give them names associated with the particular feature or change 
+                on which you are working.  
+                Once you are done with a feature or change, simply discard the branch.</para></listitem>
+            <listitem><para><emphasis>Merge Changes:</emphasis> The <filename>git merge</filename>
+                command allows you to take the 
+                changes from one branch and fold them into another branch.  
+                This process is especially helpful when more than a single developer might be working 
+                on different parts of the same feature.  
+                Merging changes also automatically identifies any collisions or “conflicts” 
+                that might happen as a result of the same lines of code being altered by two different 
+                developers.</para></listitem>
+            <listitem><para><emphasis>Manage Branches:</emphasis> Because branches are easy to use, you should 
+                use a system where branches indicate varying levels of code readiness.  
+                For example, you can have a “work” branch to develop in, a “test” branch where the code or 
+                change is tested, a “stage” branch where changes are ready to be committed, and so forth.  
+                As your project develops, you can merge code across the branches to reflect ever-increasing 
+                stable states of the development.</para></listitem>
+            <listitem><para><emphasis>Use Push and Pull:</emphasis> The push-pull workflow is based on the 
+                concept of developers “pushing” local commits to a remote repository, which is 
+                usually a contribution repository.  
+                This workflow is also based on developers “pulling” known states of the project down into their 
+                local development repositories.  
+                The workflow easily allows you to pull changes submitted by other developers from the 
+                upstream repository into your work area ensuring that you have the most recent software 
+                on which to develop.
+                The Yocto Project has two scripts named <filename>create-pull-request</filename> and 
+                <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>
+            <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>
+        </itemizedlist>
     </para>
 </section>
 
@@ -484,44 +545,59 @@
     <title>Tracking Bugs</title>
 
     <para>
-        The Yocto Project uses <ulink url='http://www.bugzilla.org/about/'>Bugzilla</ulink> to track bugs.  
-        This bug-tracking application works well for group development because it tracks bugs and code 
+        The Yocto Project uses its own implementation of 
+        <ulink url='http://www.bugzilla.org/about/'>Bugzilla</ulink> to track bugs.  
+        Implementations of Bugzilla work well for group development because they track bugs and code 
         changes, can be used to communicate changes and problems with developers, can be used to 
-        submit and review patches, and can be used to manage quality assurance.  
-        You can find a good overview of Bugzilla <ulink url='http://www.bugzilla.org/about/'>here</ulink>.     
+        submit and review patches, and can be used to manage quality assurance. 
+        The home page for the Yocto Project implementation of Bugzilla is   
+        <ulink url='http://bugzilla.yoctoproject.org'>http://bugzilla.yoctoproject.org</ulink>.
     </para>
 
     <para>
         Sometimes it is helpful to submit, investigate, or track a bug against the Yocto Project itself
         such as when discovering an issue with some component of the build system that acts contrary 
-        to the documentation or expectations.  
-        You can find information 
-        for Bugzilla configuration and bug tracking procedures specific to the Yocto Project 
+        to the documentation or your expectations.  
+        Following is the general procedure for submitting a new bug using the Yocto Project
+        Bugzilla.
+        You can find more information on defect management, bug tracking, and feature request
+        processes all accomplished through the Yocto Project Bugzilla on the wiki page
         <ulink url='https://wiki.yoctoproject.org/wiki/Bugzilla_Configuration_and_Bug_Tracking'>here</ulink>.     
+        <orderedlist>
+            <listitem><para>Always use the Yocto Project implementation of Bugzilla to submit
+                a bug.</para></listitem>
+            <listitem><para>When submitting a new bug, be sure to choose the appropriate
+                Classification, Product, and Component for which the issue was found.
+                Defects for Yocto Project fall into one of four classifications:  Yocto Projects, 
+                Infrastructure, Poky, and Yocto Metadata Layers.
+                Each of these Classifications break down into multiple Products and, in some 
+                cases, multiple Components.</para></listitem>
+            <listitem><para>Use the bug form to choose the correct Hardware and Architecture
+                for which the bug applies.</para></listitem>
+            <listitem><para>Indicate the Yocto Project version you were using when the issue
+                occurred.</para></listitem>
+            <listitem><para>Be sure to indicate the Severity of the bug.  
+                Severity communicates how the bug impacted your work.</para></listitem>
+            <listitem><para>Provide a brief summary of the issue. 
+                Try to limit your summary to just a line or two and be sure to capture the 
+                essence of the issue.</para></listitem>
+            <listitem><para>Provide a detailed description of the issue.  
+                You should provide as much detail as you can about the context, behavior, output, 
+                and so forth that surround the issue.  
+                You can even attach supporting files for output or log by using the "Add an attachment"
+                button.</para></listitem>
+            <listitem><para>Submit the bug by clicking the "Submit Bug" button.</para></listitem>
+        </orderedlist>
     </para>
-
-    <para>
-        The Yocto Project uses its own version of the Bugzilla application.  
-        You can find the home page <ulink url='http://bugzilla.yoctoproject.org'>here</ulink>.  
-        You need to use this implementation of Bugzilla when logging a defect against anything released 
-        by the Yocto Project team.     
-    </para>
-
-    <para>
-        Here are some things to remember when dealing with bugs against the Yocto Project:   
-    <itemizedlist>
-        <listitem><para>The Yocto Project follows a naming bug-naming convention: 
-            <filename>[YOCTO #&lt;number&gt;]</filename>, where <filename>&lt;number&gt;</filename> is the 
-            assigned defect ID used in Bugzilla.  
-            So, for example, a valid way to refer to a defect when creating a commit comment 
-            would be <filename>[YOCTO 1011]</filename>.   
-            This convention becomes important if you are submitting patches against the Yocto Project 
-            code itself.
-            See the following section for more information.</para></listitem>
-        <listitem><para>Defects for Yocto Project fall into one of four classifications:  Yocto Projects, 
-            Infrastructure, Poky, and Yocto Metadata Layers.</para></listitem>
-    </itemizedlist>
-    </para>
+ 
+    <note>
+        Bugs in the Yocto Project Bugzilla follow naming convention: 
+        <filename>[YOCTO #&lt;number&gt;]</filename>, where <filename>&lt;number&gt;</filename> is the 
+        assigned defect ID used in Bugzilla.  
+        So, for example, a valid way to refer to a defect would be <filename>[YOCTO #1011]</filename>.   
+        This convention becomes important if you are submitting patches against the Yocto Project 
+        code itself.
+    </note>
 </section>
 
 <section id='how-to-submit-a-change'>
@@ -529,9 +605,35 @@
 
     <para>
         Contributions to the Yocto Project are very welcome. 
-        You should send patches to the Yocto Project mailing list to get it in front of the 
-        Yocto Project Maintainer.  
-        When you send your patch, be sure to include a "signed-off-by:"
+        You should send patches to the appropriate Yocto Project mailing list to get them 
+        in front of the Yocto Project Maintainer.
+        For a list of the Yocto Project mailing lists, see the
+        "<ulink url='http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html#resources-mailinglist'>Mailing lists</ulink>" section in 
+        <ulink url='http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html'> The 
+        Yocto Project Reference Manual</ulink>.
+    </para>
+
+    <para>
+        The following is some guidance on which mailing list to use for what type of defect:
+        <itemizedlist>
+            <listitem><para>For defects against the Yocto Project build system Poky, send 
+                your patch to the  
+                <ulink url='http://lists.yoctoproject.org/listinfo/poky'></ulink> mailing list. 
+                This mailing list corresponds to issues that are not specific to the Yocto Project but
+                are part of the OE-core.
+                For example, a defect against anything in the <filename>meta</filename> layer 
+                or the BitBake Manual could be sent to this mailing list.</para></listitem>
+            <listitem><para>For defects against Yocto-specific layers, tools, and Yocto Project 
+                documentation use the 
+                <ulink url='http://lists.yoctoproject.org/listinfo/yocto'></ulink> mailing list.
+                This mailing list corresponds to Yocto-specific areas such as 
+                <filename>meta-yocto</filename>, <filename>meta-intel</filename>, 
+                <filename>linux-yocto</filename>, and <filename>documentation</filename>.</para></listitem>
+        </itemizedlist>      
+    </para>
+
+    <para>  
+        When you send a patch, be sure to include a "Signed-off-by:"
         line in the same style as required by the Linux kernel. 
         Adding this line signifies the developer has agreed to the Developer's Certificate of Origin 1.1
         as follows:
@@ -573,35 +675,82 @@
     <para>
         In a collaborative environment, it is necessary to have some sort of standard 
         or method through which you submit changes.  
-        Otherwise, things would get quite chaotic.  
+        Otherwise, things could get quite chaotic.  
     </para>
 
     <para>
-        When you submit a change or patch to the Yocto Project, you must follow certain procedures.  
-        In particular, the headers in patches and the commit messages must follow a certain standard.  
-        The general process is the same as described earlier in this chapter.  
-        For complete details on how to create proper commit messages and patch headers see 
-        [WRITER NOTE:  I need the link to Mark's wiki page here that describes the process.]
+        When you create a commit, you must follow certain standards established by the
+        Yocto Project development team. 
+        For each commit, you must provide a single-line summary of the change and you 
+        almost always provide a more detailed description of what you did (i.e. the body 
+        of the commit).
+        The only exceptions for not providing a detailed description would be if your 
+        change is a simple, self-explanatory change that needs no description.
+        Here are the Yocto Project commit message guidelines:
+        <itemizedlist>
+            <listitem><para>Provide a single-line, short summary of the change.
+                This summary is typically viewable by source control systems.
+                Thus, providing something short and descriptive that gives the reader 
+                a summary of the change is useful when viewing a list of many commits.
+                </para></listitem>
+            <listitem><para>For the body of the commit message, provide detailed information
+                that describes what you changed, why you made the change, and the approach
+                you used.  
+                Provide as much detail as you can in the body of the commit message.
+                </para></listitem>
+            <listitem><para>If the change addresses a specific bug or issue that is 
+                associated with a bug-tracking ID, prefix your detailed description
+                with the bug or issue ID.  
+                For example, the Yocto Project tracks bugs using a bug-naming convention.
+                Any commits that address a bug must start with the bug ID in the description
+                as follows:
+                <literallayout class='monospaced'>
+     YOCTO #&lt;bug-id&gt;:  &lt;Detailed description of commit&gt;
+                </literallayout></para></listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        You can find more guidance on creating well-formed commit messages at this OpenEmbedded 
+        wiki page:
+        <ulink url='http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines'></ulink>.
     </para>
 
     <para>
         Following are general instructions for both pushing changes upstream and for submitting changes as patches.
-    </para>
+    </para> 
 
     <section id='pushing-a-change-upstream'>
-        <title>Pushing a Change Upstream</title>
+        <title>Pushing a Change Upstream and Requesting a Pull</title>
 
         <para>
             The basic flow for pushing a change to an upstream "contrib" Git repository is as follows:
-        <itemizedlist>
-            <listitem><para>Make your changes in your local Git repository.</para></listitem>
-            <listitem><para>Stage your commit (or change) by using the <filename>git add</filename>
-                command.</para></listitem>
-            <listitem><para>Commit the change by using the <filename>git commit</filename>
-                command and push it to the upstream "contrib" repository.  
-                Be sure to provide a commit message that follows the project’s commit standards.</para></listitem>
-            <listitem><para>Notify the maintainer that you have pushed a change.</para></listitem>
-        </itemizedlist>
+            <itemizedlist>
+                <listitem><para>Make your changes in your local Git repository.</para></listitem>
+                <listitem><para>Stage your commit (or change) by using the <filename>git add</filename>
+                    command.</para></listitem>
+                <listitem><para>Commit the change by using the <filename>git commit</filename>
+                    command and push it to the "contrib" repository.  
+                    Be sure to provide a commit message that follows the project’s commit standards
+                    as described earlier.</para></listitem>
+                <listitem><para>Notify the maintainer that you have pushed a change by making a pull 
+                    request.
+                    The Yocto Project provides two scripts that conveniently let you generate and send
+                    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>
+                    <para>For help on using these scripts, simply provide the 
+                    <filename>--help</filename> argument as follows:
+                    <literallayout class='monospaced'>
+     $ ~/poky/scripts/create-pull-request --help
+     $ ~/poky/scripts/send-pull-request --help
+                    </literallayout></para></listitem>
+            </itemizedlist>
+        </para>
+
+        <para>            
             You can find general Git information on how to push a change upstream 
             <ulink url='http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#Developing-With-git'>
             here</ulink>.
@@ -609,30 +758,75 @@
     </section>
 
     <section id='submitting-a-patch'>
-        <title>Submitting a Patch</title>
+        <title>Submitting a Patch Through Email</title>
 
         <para>
-            If you have a just a few changes you can commit them and then submit them as an email to the maintainer.
+            If you have a just a few changes, you can commit them and then submit them as an 
+            email to the maintainer.
             Here is a general procedure:
-        <itemizedlist>
-            <listitem><para>Make your changes in your local Git repository.</para></listitem>
-            <listitem><para>Stage your commit (or change) by using the <filename>git add</filename>
-                command.</para></listitem>
-            <listitem><para>Commit the change by using the <filename>git commit</filename> command.  
-                Be sure to provide a commit message that follows the project’s commit standards.</para></listitem>
-            <listitem><para>Format the commit by using the <filename>git format-patch</filename>
-                command.  
-                This step produces a numbered series of files in the current directory – one for 
-                each commit.</para></listitem>
-            <listitem><para>Import the files into your mail client by using the 
-                <filename>git-send-email</filename> command.</para></listitem>
-            <listitem><para>Send the email by hand to the maintainer.</para></listitem>
-        </itemizedlist>
-             Be aware that there could be protocols and standards that you need to follow for your particular 
-             project.
-             You can find general Git information for submitting a patch  
-             <ulink url='http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#sharing-development'>
-             here</ulink>. 
+            <itemizedlist>
+                <listitem><para>Make your changes in your local Git repository.</para></listitem>
+                <listitem><para>Stage your commit (or change) by using the <filename>git add</filename>
+                    command.</para></listitem>
+                <listitem><para>Commit the change by using the 
+                    <filename>git commit --signoff</filename> command.
+                    Using the <filename>--signoff</filename> option identifies you as the person 
+                    making the change and also satisfies the Developer's Certificate of 
+                    Origin (DCO) shown earlier.</para>
+                    <para>When you form a commit you must follow certain standards established by the 
+                    Yocto Project development team. 
+                    See the earlier section
+                    "<link linkend='how-to-submit-a-change'>How to Submit a Change</link>" 
+                    for Yocto Project commit message standards.</para></listitem>
+                <listitem><para>Format the commit into an email messsage.
+                    To format commits, use the <filename>git format-patch</filename> command.
+                    When you provide the command, you must include a revision list or a number of patches
+                    as part of the command.
+                    For example, these two commands each take the most recent single commit and 
+                    format it as an email message in the current directory:  
+                    <literallayout class='monospaced'>
+     $ git format-patch -1
+     $ git format-patch HEAD~
+                    </literallayout></para>
+                    <para>After the command is run, the current directory contains a 
+                    numbered <filename>.patch</filename> file for the commit.</para>
+                    <para>If you provide several commits as part of the command, 
+                    the <filename>git format-patch</filename> command produces a numbered 
+                    series of files in the current directory – one for each commit.
+                    If you have more than one patch, you should also use the 
+                    <filename>--cover</filename> option with the command, which generates a 
+                    cover letter as the first "patch" in the series.  
+                    You can then edit the cover letter to provide a description for 
+                    the series of patches.
+                    For information on the <filename>git format-patch</filename> command, 
+                    see <filename>GIT_FORMAT_PATCH(1)</filename> displayed using the  
+                    <filename>man git-format-patch</filename> command.</para></listitem>
+                <listitem><para>Import the files into your mail client by using the 
+                    <filename>git send-email</filename> command.
+                    <note>In order to use <filename>git send-email</filename>, you must have the 
+                    the proper Git packages installed.
+                    For Ubuntu and Fedora the package is <filename>git-email</filename>.</note></para>
+                    <para>The <filename>git send-email</filename> command sends email by using a local
+                    or remote Mail Transport Agent (MTA) such as 
+                    <filename>msmtp</filename>, <filename>sendmail</filename>, or through a direct
+                    <filename>smtp</filename> configuration in your Git <filename>config</filename>
+                    file.
+                    If you are submitting patches through email only, it is very important
+                    that you submit them without any whitespace or HTML formatting that 
+                    either you or your mailer introduces.
+                    The maintainer that receives your patches needs to be able to save and 
+                    apply them directly from your emails.
+                    A good way to verify that what you are sending will be applicable by the 
+                    maintainer is to do a dry run and send them to yourself and then 
+                    save and apply them as the maintainer would.</para>
+                    <para>The <filename>git send-email</filename> command is the preferred method
+                    for sending your patches since there is no risk of compromising whitespace
+                    in the body of the message, which can occur when you use your own mail client.
+                    The command also has several options that let you 
+                    specify recipients and perform further editing of the email message.
+                    For information on how to use the <filename>git send-email</filename> command,
+                    use the <filename>man git-send-email</filename> command.</para></listitem>
+            </itemizedlist>
         </para>
     </section>
 </section>

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

@@ -7,16 +7,15 @@
 
 <para>
     This chapter introduces the Yocto Project and gives you an idea of what you need to get started.  
-    You can find enough information to set your development host up and build or use images for 
-    hardware supported by the Yocto Project by reading the 
-    <ulink url='http://www.yoctoproject.org/docs/yocto-quick-start/yocto-project-qs.html'>
-    Yocto Project Quick Start</ulink> located on the <ulink url='http://www.yoctoproject.org'>
-    Yocto Project website</ulink>.
+    You can find enough information to set up your development host and build or use images for 
+    hardware supported by the Yocto Project by reading  
+    <ulink url='http://www.yoctoproject.org/docs/latest/yocto-project-qs/yocto-project-qs.html'>
+    The Yocto Project Quick Start</ulink>.
 </para>
 
 <para>
     The remainder of this chapter summarizes what is in the Yocto Project Quick Start and provides 
-    some higher level concepts you might want to consider.
+    some higher-level concepts you might want to consider.
 </para>
 
 <section id='introducing-the-yocto-project'>
@@ -24,8 +23,8 @@
 
     <para>
         The Yocto Project is an open-source collaboration project focused on embedded Linux development.  
-        The project currently provides a build system and various ancillary tools suitable for the 
-        embedded developer.  
+        The project currently provides a build system, which is sometimes referred to as "Poky",
+        and provides various ancillary tools suitable for the embedded developer.  
         The Yocto Project also features the Sato reference User Interface, which is optimized for 
         stylus driven, low-resolution screens.
     </para>
@@ -37,13 +36,14 @@
         While the Yocto Project does not provide a strict testing framework,
         it does provide or generate for you artifacts that let you perform target-level and 
         emulated testing and debugging.  
-        And, if you are an Eclipse user, you can install an Eclipse Yocto Plug-in to allow you to 
+        Additionally, if you are an <trademark class='trade'>Eclipse</trademark>
+        IDE user, you can install an Eclipse Yocto Plug-in to allow you to 
         develop within that familiar environment.
     </para>
 </section>
 
 <section id='getting-setup'>
-    <title>Getting Setup</title>
+    <title>Getting Set Up</title>
 
     <para>
         Here is what you need to get set up to use the Yocto Project:
@@ -51,103 +51,100 @@
             <listitem><para><emphasis>Host System:</emphasis>  You should have a reasonably current 
                 Linux-based host system.
                 You will have the best results with a recent release of Fedora, 
-                OpenSUSE, or Ubuntu as these releases are frequently tested and officially supported 
-                host systems.  
+                OpenSUSE, or Ubuntu as these releases are frequently tested against the Yocto Project
+                and officially supported.  
                 You should also have about 100 gigabytes of free disk space for building images.
                 </para></listitem>
             <listitem><para><emphasis>Packages:</emphasis>  The Yocto Project requires certain packages
                 exist on your development system (e.g. Python 2.6 or 2.7).  
-                See <ulink url='http://www.yoctoproject.org/docs/yocto-quick-start/yocto-project-qs.html#packages'>
-                The Packages</ulink> section in the Yocto Project Quick start for the exact package 
-                requirements and the installation commands for the supported distributions.</para></listitem>
+                See "<ulink url='http://www.yoctoproject.org/docs/latest/yocto-project-qs/yocto-project-qs.html#packages'>The Packages</ulink>" 
+                section in the Yocto Project Quick start for the exact package 
+                requirements and the installation commands to install them 
+                for the supported distributions.</para></listitem>
             <listitem id='local-yp-release'><para><emphasis>Yocto Project Release:</emphasis>  
                 You need a release of the Yocto Project.  
                 You can get set up with local Yocto Project files one of two ways depending on whether you 
                 are going to be contributing back into the Yocto Project source repository or not.
                 <note>
-                    Regardless of the method you use, this manual will refer to the resulting 
-                    hierarchical set of files as "the local Yocto Project files."
+                    Regardless of the method you use, this manual refers to the resulting 
+                    hierarchical set of files as "the Yocto Project files" or "the Yocto Project file
+                    structure."
                 </note>
                 <itemizedlist>
                     <listitem><para><emphasis>Tarball Extraction:</emphasis>  If you are not going to contribute 
-                        back into the Yocto Project you can simply download the Yocto Project release you want 
+                        back into the Yocto Project, you can simply download the Yocto Project release you want 
                         from the website’s <ulink url='http://yoctoproject.org/download'>download page</ulink>.
                         Once you have the tarball, just extract it into a directory of your choice.</para>
-
                         <para>For example, the following command extracts the Yocto Project 1.1 release tarball 
-                            into the current working directory and sets up a file structure whose top-level 
-                            directory is named <filename>poky-1.1</filename>:
-                            <literallayout class='monospaced'>
-     $ tar xfj poky-1.1.tar.bz2
-                            </literallayout></para>
-                        <para>This method does not produce a <filename>poky</filename> Git repository. 
-                            You end up simply with a local snapshot of Yocto Project files that are based on the 
-                            particular release in the tarball.</para></listitem>
+                        into the current working directory and sets up the Yocto Project file structure
+                        with a top-level directory named <filename>poky-edison-6.0</filename>:
+                        <literallayout class='monospaced'>
+     $ tar xfj poky-edison-6.0.tar.bz2
+                        </literallayout></para>
+                        <para>This method does not produce a Git repository. 
+                        Instead, you simply end up with a local snapshot of the 
+                        Yocto Project files that are based on the particular release in the 
+                        tarball.</para></listitem>
                     <listitem><para><emphasis>Git Repository Method:</emphasis>  If you are going to be contributing
-                        back into the Yocto Project you should use Git commands to set up a local 
-                        <filename>poky</filename> Git repository of the Yocto Project.  
+                        back into the Yocto Project, you should use Git commands to set up a local 
+                        Git repository of the Yocto Project files.  
                         Doing so creates a Git repository with a complete history of changes and allows 
                         you to easily submit your changes upstream to the project.</para>
- 
-                       <para>The following transcript shows how to clone the <filename>poky</filename> 
+                       <para>The following transcript shows how to clone the Yocto Project files'  
                        Git repository into the current working directory.  
                        The command creates the repository in a directory named <filename>poky</filename>.
-                       For information on the Yocto Project and Git, see
-                       <xref linkend='git'>Git</xref> in  
-                       <xref linkend='dev-manual-newbie'>Working with Open Source Code</xref>.
+                       For information on the Yocto Project and Git, see the
+                       "<link linkend='git'>Git</link>" section.
                        <literallayout class='monospaced'>
      $ git clone git://git.yoctoproject.org/poky
      Initialized empty Git repository in /home/scottrif/poky/.git/
-     remote: Counting objects: 107624, done.
-     remote: Compressing objects: 100% (37128/37128), done.
-     remote: Total 107624 (delta 73393), reused 99851 (delta 67287)
-     Receiving objects: 100% (107624/107624), 69.74 MiB | 483 KiB/s, done.
-     Resolving deltas: 100% (73393/73393), done.
-                       </literallayout></para>
-
-                       <para>For another example of how to set up your own local Git repositories see this
+     remote: Counting objects: 116882, done.
+     remote: Compressing objects: 100% (35987/35987), done.
+     remote: Total 116882 (delta 80651), reused 113045 (delta 77578)
+     Receiving objects: 100% (116882/116882), 72.13 MiB | 2.68 MiB/s, done.
+     Resolving deltas: 100% (80651/80651), done.                       </literallayout></para>
+                       <para>For another example of how to set up your own local Git repositories, see this
                         <ulink url='https://wiki.yoctoproject.org/wiki/Transcript:_from_git_checkout_to_meta-intel_BSP'>
                         wiki page</ulink>, which describes how to create both <filename>poky</filename>
                         and <filename>meta-intel</filename> Git repositories.</para></listitem>
                 </itemizedlist></para></listitem>
             <listitem id='local-kernel-files'><para><emphasis>Linux Yocto Kernel:</emphasis>  
-                If you are going to be making modifications to a supported Linux Yocto kernel you 
-                need to get set up so that you can edit local copies of the source.
+                If you are going to be making modifications to a supported Linux Yocto kernel, you 
+                need to establish local copies of the source.
                 This setup involves creating a bare clone of the Linux Yocto kernel and then cloning 
                 that repository.
                 You can create the bare clone and the copy of the bare clone anywhere you like.
                 For simplicity, it is recommended that you create these structures outside of the 
-                Yocto Project files Git repository.</para>
+                Yocto Project files' Git repository.</para>
                 <para>As an example, the following transcript shows how to create the bare clone
                 of the <filename>linux-yocto-3.0</filename> kernel and then create a copy of 
                 that clone.
-                <note>If you currently have a local Linux Yocto kernel Git repository, you can 
-                reference this local repository rather than the upstream Git repository as 
+                <note>When you have a local Linux Yocto 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>
-                The bare clone is named <filename>linux-yocto-3.0.git</filename>, while the 
+                Doing so can speed up the process.</note></para>
+                <para>In the following example, the bare clone is named 
+                <filename>linux-yocto-3.0.git</filename>, while the 
                 copy is named <filename>linux-yocto-3.0</filename>: 
                 <literallayout class='monospaced'>
      $ git clone --bare git://git.yoctoproject.org/linux-yocto-3.0 linux-yocto-3.0.git
-     Initialized empty Git repository in /home/scottrif/poky/linux-yocto-3.0.git/
-     remote: Counting objects: 1886034, done.
-     remote: Compressing objects: 100% (314326/314326), done.
-     remote: Total 1886034 (delta 1570200), reused 1870337 (delta 1554798)
-     Receiving objects: 100% (1886034/1886034), 401.51 MiB | 3.27 MiB/s, done.
-     Resolving deltas: 100% (1570200/1570200), done.
-                </literallayout></para>
+     Initialized empty Git repository in /home/scottrif/linux-yocto-3.0.git/
+     remote: Counting objects: 2123870, done.
+     remote: Compressing objects: 100% (341338/341338), done.
+     remote: Total 2123870 (delta 1778780), reused 2107534 (delta 1762583)
+     Receiving objects: 100% (2123870/2123870), 445.72 MiB | 2.06 MiB/s, done.
+     Resolving deltas: 100% (1778780/1778780), done.                </literallayout></para>
                 <para>Now create a clone of the bare clone just created:
                 <literallayout class='monospaced'>
      $ git clone linux-yocto-3.0.git linux-yocto-3.0
-     Initialized empty Git repository in /home/scottrif/poky/linux-yocto-3.0/.git/
-     Checking out files: 100% (35188/35188), done.
-                </literallayout></para></listitem>
+     Initialized empty Git repository in /home/scottrif/linux-yocto-3.0/.git/
+     Checking out files: 100% (36898/36898), done.                </literallayout></para></listitem>
             <listitem id='poky-extras-repo'><para><emphasis>
                 The <filename>poky-extras</filename> Git Repository</emphasis>:
-                The <filename>poky-extras</filename> Git repository contains metadata needed to 
-                build the kernel image.
+                The <filename>poky-extras</filename> Git repository contains metadata needed 
+                only if you are modifying and building the kernel image.
                 In particular, it contains the kernel <filename>.bbappend</filename> files that you 
-                edit to point to your locally modified kernel source files and to build kernel
+                edit to point to your locally modified kernel source files and to build the kernel
                 image. 
                 Pointing to these local files is much more efficient than requiring a download of the 
                 source files from upstream each time you make changes to the kernel.</para>
@@ -160,14 +157,13 @@
      $ 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: 531, done.
-     remote: Compressing objects: 100% (471/471), done.
-     remote: Total 531 (delta 138), reused 307 (delta 39)
-     Receiving objects: 100% (531/531), 517.86 KiB, done.
-     Resolving deltas: 100% (138/138), done.
-                </literallayout></para></listitem>
-           <listitem><para><emphasis>Supported Board Support Packages (BSPs):</emphasis>  The same considerations 
-                exist for BSPs.  
+     remote: Counting objects: 543, done.
+     remote: Compressing objects: 100% (483/483), done.
+     remote: Total 543 (delta 144), reused 307 (delta 39)
+     Receiving objects: 100% (543/543), 520.55 KiB, done.
+     Resolving deltas: 100% (144/144), done.                </literallayout></para></listitem>
+           <listitem><para><emphasis>Supported Board Support Packages (BSPs):</emphasis>  
+                Similar considerations exist for BSPs.  
                 You can get set up for BSP development one of two ways: tarball extraction or
                 with a local Git repository.
                 Regardless of the method you use, the Yocto Project uses the following BSP layer 
@@ -185,21 +181,21 @@
                 <itemizedlist>
                     <listitem><para><emphasis>Tarball Extraction:</emphasis>  You can download any released 
                         BSP tarball from the same 
-                        <ulink url='http://yoctoproject.org/download'>download site</ulink>.  
-                        Once you have the tarball just extract it into a directory of your choice.
+                        <ulink url='http://yoctoproject.org/download'>download site</ulink> used 
+                        to get the Yocto Project release.  
+                        Once you have the tarball, just extract it into a directory of your choice.
                         Again, this method just produces a snapshot of the BSP layer in the form
                         of a hierarchical directory structure.</para></listitem>
                     <listitem><para><emphasis>Git Repository Method:</emphasis>  If you are working 
-                        with a <filename>poky</filename> Git repository you should also set up a 
+                        with a Yocto Project files Git repository, you should also set up a 
                         <filename>meta-intel</filename> Git repository.  
                         Typically, you set up the <filename>meta-intel</filename> Git repository inside
-                        the <filename>poky</filename> Git repository.</para>
-
+                        the Yocto Project files Git repository.</para>
                         <para>For example, the following transcript shows the steps to clone the 
                         <filename>meta-intel</filename>
                         Git repository inside the <filename>poky</filename> Git repository.
                         <literallayout class='monospaced'>
-     $cd poky
+     $ cd poky
      $ git clone git://git.yoctoproject.org/meta-intel.git
      Initialized empty Git repository in /home/scottrif/poky/meta-intel/.git/
      remote: Counting objects: 1325, done.
@@ -208,18 +204,17 @@
      Receiving objects: 100% (1325/1325), 1.56 MiB | 330 KiB/s, done.
      Resolving deltas: 100% (546/546), done.
                         </literallayout></para>
-
                         <para>The same  
                         <ulink url='https://wiki.yoctoproject.org/wiki/Transcript:_from_git_checkout_to_meta-intel_BSP'>
                         wiki page</ulink> referenced earlier covers how to 
                         set up the <filename>meta-intel</filename> Git repository.</para></listitem>
                 </itemizedlist></para></listitem>
             <listitem><para><emphasis>Eclipse Yocto Plug-in:</emphasis>  If you are developing 
-                applications using the 
-                Eclipse Integrated Development Environment (IDE) you will need this plug-in.  
+                applications using the Eclipse Integrated Development Environment (IDE),
+                you will need this plug-in.  
                 See the 
-                <ulink url='http://www.yoctoproject.org/docs/adt-manual/adt-manual.html#setting-up-the-eclipse-ide'>
-                Setting up the Eclipse IDE</ulink> section in the Yocto Application Development Toolkit (ADT) 
+                "<ulink url='http://www.yoctoproject.org/docs/latest/adt-manual/adt-manual.html#setting-up-the-eclipse-ide'>Setting up the Eclipse IDE</ulink>"
+                section in the Yocto Application Development Toolkit (ADT) 
                 User’s Guide for more information.</para></listitem>
         </itemizedlist>
     </para>
@@ -231,8 +226,8 @@
     <para>
         The build process creates an entire Linux distribution, including the toolchain, from source.  
         For more information on this topic, see the 
-        <ulink url='http://www.yoctoproject.org/docs/yocto-quick-start/yocto-project-qs.html#building-image'>
-        Building an Image</ulink> section in the Yocto Project Quick Start.
+        "<ulink url='http://www.yoctoproject.org/docs/latest/yocto-project-qs/yocto-project-qs.html#building-image'>Building an Image</ulink>"
+        section in the Yocto Project Quick Start.
     </para>
 
     <para>
@@ -244,9 +239,9 @@
                 script.</para></listitem>
             <listitem><para>Optionally ensure the <filename>conf/local.conf</filename> configuration file is set 
                 up how you want it.  
-                This file defines the target machine architecture and and other build options.</para></listitem>
-            <listitem><para>Build the image using the BitBake command.  
-                If you want information on Bitbake, see the user manual at 
+                This file defines the target machine architecture and other build options.</para></listitem>
+            <listitem><para>Build the image using the <command>bitbake</command> command.
+                If you want information on BitBake, see the user manual at
                 <ulink url='http://docs.openembedded.org/bitbake/html'></ulink>.</para></listitem>
             <listitem><para>Run the image either on the actual hardware or using the QEMU 
                 emulator.</para></listitem>
@@ -260,16 +255,17 @@
     <para>
         Another option you have to get started is to use pre-built binaries.  
         This scenario is ideal for developing software applications to run on your target hardware.  
-        To do this you need to install the stand-alone Yocto toolchain tarball and then download the 
-        pre-built kernel that you will boot using the QEMU emulator.  
-        Next, you must download the filesystem for your target machine’s architecture.  
-        Finally, you set up the environment to emulate the hardware then start the emulator.
+        To do this, you need to install the stand-alone Yocto Project cross-toolchain tarball and 
+        then download the pre-built kernel that you will boot in the QEMU emulator.  
+        Next, you must download and extract the target root filesystem for your target 
+        machine’s architecture.  
+        Finally, you set up the environment to emulate the hardware and then start the QEMU emulator.
     </para>
 
     <para>
         You can find details on all these steps in the 
-        <ulink url='http://www.yoctoproject.org/docs/yocto-quick-start/yocto-project-qs.html#using-pre-built'>
-        Using Pre-Built Binaries and QEMU</ulink> section in the Yocto Project Quick Start. 
+        "<ulink url='http://www.yoctoproject.org/docs/latest/yocto-project-qs/yocto-project-qs.html#using-pre-built'>Using Pre-Built Binaries and QEMU</ulink>"
+        section of the Yocto Project Quick Start. 
     </para>
 </section>
 </chapter>

documentation/dev-manual/dev-manual.xml

@@ -30,9 +30,8 @@
         <revhistory>
             <revision>
                 <revnumber>1.1</revnumber>
-                <date>TBD 2011</date>
-                <revremark>This revision is the initial document draft and corresponds with 
-                    the Yocto Project 1.1 Release.</revremark>
+                <date>6 October 2011</date>
+                <revremark>The initial document released with the Yocto Project 1.1 Release.</revremark>
             </revision>
         </revhistory>
 
@@ -52,7 +51,7 @@
       <note>
           Due to production processes, there could be differences between the Yocto Project
           documentation bundled in the release tarball and  
-          <ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html'>
+          <ulink url='http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html'>
           The Yocto Project Development Manual</ulink> on
           the <ulink url='http://www.yoctoproject.org'>Yocto Project</ulink> website.
           For the latest version of this manual, see the manual on the website.

documentation/dev-manual/style.css

@@ -435,7 +435,6 @@ b.keycap,
   font-family: Courier, monospace;
 }
 
-
 div.navheader, div.heading{
   position: absolute;
   left: 0em;
@@ -966,3 +965,9 @@ table {
    color: #fff;   
    text-decoration: underline;
 }
+
+.footnote {
+   font-size: small;
+   color: #333;
+}
+

documentation/kernel-manual/kernel-concepts.xml

@@ -44,14 +44,16 @@
             management techniques.</para></listitem>
             <listitem><para>Deliver the most up-to-date kernel possible while still ensuring that 
             the baseline kernel is the most stable official release.</para></listitem>
-            <listitem><para>Include major technological features as part of Yocto Project's up-rev 
-            strategy.</para></listitem>
-            <listitem><para>Present a Git tree, that just like the upstream kernel.org tree, has a 
-            clear and continuous history.</para></listitem>
+            <listitem><para>Include major technological features as part of Yocto Project's 
+            upward revision strategy.</para></listitem>
+            <listitem><para>Present a kernel Git repository that, similar to the upstream 
+            <filename>kernel.org</filename> tree, 
+            has a clear and continuous history.</para></listitem>
             <listitem><para>Deliver a key set of supported kernel types, where each type is tailored 
-            to a specific use case (i.e. networking, consumer, devices, and so forth).</para></listitem>
-            <listitem><para>Employ a Git branching strategy that from a customer's point of view
-            results in a linear path from the baseline kernel.org, through a select group of features and
+            to meet a specific use (e.g. networking, consumer, devices, and so forth).</para></listitem>
+            <listitem><para>Employ a Git branching strategy that, from a developer's point of view,
+            results in a linear path from the baseline <filename>kernel.org</filename>, 
+            through a select group of features and
             ends with their BSP-specific commits.</para></listitem>
         </itemizedlist>
         </para>
@@ -60,27 +62,29 @@
     <section id='kernel-big-picture'>
         <title>Yocto Project Kernel Development and Maintenance Overview</title>
         <para>
-            Yocto Project kernel, like other kernels, is based off the Linux kernel release
+            The Yocto Project kernel, like other kernels, is based off the Linux kernel release
             from <ulink url='http://www.kernel.org'></ulink>.  
-            At the beginning of our major development cycle, we choose our Yocto Project kernel 
-            based on factors like release timing, the anticipated release timing of "final" (i.e. non "rc")
-            upstream kernel.org versions, and Yocto Project feature requirements.
-            Typically this will be a kernel that is in the
-            final stages of development by the community (i.e. still in the release
-            candidate or "rc" phase) and not yet a final release. 
-            But by being in the final stages of external development, we know that the 
-            kernel.org final release will clearly land within the early stages of 
+            At the beginning of a major development cycle, the Yocto Project team
+            chooses its Yocto Project kernel 
+            based on factors like release timing, the anticipated release timing of final
+            upstream <filename>kernel.org</filename> versions, and Yocto Project feature requirements.
+            Typically, the kernel chosen is in the
+            final stages of development by the community.
+            In other words, the kernel is in the release
+            candidate or "rc" phase and not yet a final release. 
+            But, by being in the final stages of external development, the team knows that the 
+            <filename>kernel.org</filename> final release will clearly be within the early stages of 
             the Yocto Project development window.
         </para>
         <para>
-            This balance allows us to deliver the most up-to-date kernel
-            as possible, while still ensuring that we have a stable official release as
-            our baseline kernel version.
+            This balance allows the team to deliver the most up-to-date kernel
+            as possible, while still ensuring that the team has a stable official release for
+            the baseline kernel version.
         </para>
         <para>
             The ultimate source for the Yocto Project kernel is a released kernel 
-            from kernel.org.
-            In addition to a foundational kernel from kernel.org the released 
+            from <filename>kernel.org</filename>.
+            In addition to a foundational kernel from <filename>kernel.org</filename>, the released 
             Yocto Project kernel contains a mix of important new mainline
             developments, non-mainline developments (when there is no alternative),
             Board Support Package (BSP) developments,
@@ -88,37 +92,21 @@
             These additions result in a commercially released Yocto Project kernel that caters 
             to specific embedded designer needs for targeted hardware.
         </para>
-<!--        <para>
-            The following figure represents the overall place the Yocto Project kernel fills.
-        </para>
         <para>
-        <imagedata fileref="figures/kernel-big-picture.png" width="6in" depth="6in" align="center" scale="100" />
-        </para>
-        <para>
-            In the figure the ultimate source for the Yocto Project kernel is a released kernel 
-            from kernel.org.
-            In addition to a foundational kernel from kernel.org the commercially released 
-            Yocto Project kernel contains a mix of important new mainline
-            developments, non-mainline developments, Board Support Package (BSP) developments,
-            and custom features.
-            These additions result in a commercially released Yocto Project kernel that caters 
-            to specific embedded designer needs for targeted hardware. 
-        </para> -->
-        <para>
-            Once a Yocto Project kernel is officially released the Yocto Project team goes into 
-            their next development cycle, or "uprev" cycle while continuing maintenance on the 
-            released kernel.
+            Once a Yocto Project kernel is officially released, the Yocto Project team goes into 
+            their next development cycle, or upward revision (uprev) cycle, while still 
+            continuing maintenance on the released kernel.
             It is important to note that the most sustainable and stable way
             to include feature development upstream is through a kernel uprev process.
-            Back-porting of hundreds of individual fixes and minor features from various
-            kernel versions is not sustainable and can easily compromise quality. 
+            Back-porting hundreds of individual fixes and minor features from various
+            kernel versions is not sustainable and can easily compromise quality.
+        </para>
+        <para> 
             During the uprev cycle, the Yocto Project team uses an ongoing analysis of
             kernel development, BSP support, and release timing to select the best
-            possible kernel.org version.
+            possible <filename>kernel.org</filename> version.
             The team continually monitors community kernel
             development to look for significant features of interest.
-<!--            The illustration depicts this by showing the team looking back to kernel.org for new features, 
-            BSP features, and significant bug fixes. -->
             The team does consider back-porting large features if they have a significant advantage. 
             User or community demand can also trigger a back-port or creation of new
             functionality in the Yocto Project baseline kernel during the uprev cycle. 
@@ -130,7 +118,7 @@
             It is the Yocto Project team's policy to not back-port minor features to the released kernel. 
             They only consider back-porting significant technological jumps - and, that is done 
             after a complete gap analysis. 
-            The reason for this policy is that simply back-porting any small to medium sized change 
+            The reason for this policy is that back-porting any small to medium sized change 
             from an evolving kernel can easily create mismatches, incompatibilities and very 
             subtle errors.
         </para>
@@ -160,21 +148,27 @@
         <section id='architecture-overview'>
             <title>Overview</title>
             <para>
-                As mentioned earlier, a key goal of Yocto Project is to present the developer with 
+                As mentioned earlier, a key goal of the Yocto Project is to present the 
+                developer with 
                 a kernel that has a clear and continuous history that is visible to the user. 
                 The architecture and mechanisms used achieve that goal in a manner similar to the 
-                upstream kernel.org.
-                
+                upstream <filename>kernel.org</filename>.
             </para>
             <para>
                 You can think of the Yocto Project kernel as consisting of a baseline kernel with
                 added features logically structured on top of the baseline.
                 The features are tagged and organized by way of a branching strategy implemented by the 
-                source code manager (SCM) Git. 
+                source code manager (SCM) Git.
+                For information on Git as applied to the Yocto Project, see the
+                "<ulink url='http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#git'>Git</ulink>"
+                section in <ulink url='http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html'>The 
+                Yocto Project Development Manual</ulink>.
+            </para>
+            <para>
                 The result is that the user has the ability to see the added features and 
                 the commits that make up those features.
                 In addition to being able to see added features, the user can also view the history of what 
-                made up the baseline kernel as well.
+                made up the baseline kernel.
             </para>
             <para>
                 The following illustration shows the conceptual Yocto Project kernel.
@@ -183,18 +177,20 @@
                 <imagedata fileref="figures/kernel-architecture-overview.png" width="6in" depth="7in" align="center" scale="100" />
             </para>
             <para>
-                In the illustration, the "kernel.org Branch Point" marks the specific spot (or release) from 
-                which the Yocto Project kernel is created.  From this point "up" in the tree features and 
-                differences are organized and tagged.
+                In the illustration, the "Kernel.org Branch Point" 
+                marks the specific spot (or release) from 
+                which the Yocto Project kernel is created.  
+                From this point "up" in the tree, features and differences are organized and tagged.
             </para>
             <para>
                 The "Yocto Project Baseline Kernel" contains functionality that is common to every kernel
-                type and BSP that is organized further up the tree.  Placing these common features in the 
+                type and BSP that is organized further up the tree.  
+                Placing these common features in the 
                 tree this way means features don't have to be duplicated along individual branches of the 
                 structure.
             </para>
             <para>
-                From the Yocto Project Baseline Kernel branch points represent specific functionality
+                From the Yocto Project Baseline Kernel, branch points represent specific functionality
                 for individual BSPs as well as real-time kernels.
                 The illustration represents this through three BSP-specific branches and a real-time 
                 kernel branch.  
@@ -209,8 +205,9 @@
                 kernel as they apply to a given BSP.
             </para>
             <para>
-                The resulting tree structure presents a clear path of markers (or branches) to the user
-                that for all practical purposes is the kernel needed for any given set of requirements.
+                The resulting tree structure presents a clear path of markers (or branches) to the 
+                developer that, for all practical purposes, is the kernel needed for any given set 
+                of requirements.
             </para>
         </section>
  
@@ -221,50 +218,52 @@
                 no longer shared and thus, needs to be isolated.
                 For example, board-specific incompatibilities would require different functionality
                 and would require a branch to separate the features. 
-                Likewise, for specific kernel features the same branching strategy is used.
+                Likewise, for specific kernel features, the same branching strategy is used.
+            </para>
+            <para>
                 This branching strategy results in a tree that has features organized to be specific 
                 for particular functionality, single kernel types, or a subset of kernel types.  
-                This strategy results in not having to store the same feature twice internally in the 
-                tree.
-                Rather we store the unique differences required to apply the feature onto the kernel type 
-                in question.
+                This strategy also results in not having to store the same feature twice 
+                internally in the tree.
+                Rather, the kernel team stores the unique differences required to apply the 
+                feature onto the kernel type in question.
+                <note>
+                    The Yocto Project team strives to place features in the tree such that they can be 
+                    shared by all boards and kernel types where possible.
+                    However, during development cycles or when large features are merged,
+                    the team cannot always follow this practice. 
+                    In those cases, the team uses isolated branches to merge features.
+                </note>
             </para>
-            <note><para>
-                The Yocto Project team strives to place features in the tree such that they can be 
-                shared by all boards and kernel types where possible.
-                However, during development cycles or when large features are merged this practice 
-                cannot always be followed. 
-                In those cases isolated branches are used for feature merging.
-            </para></note>
             <para>
                 BSP-specific code additions are handled in a similar manner to kernel-specific additions. 
                 Some BSPs only make sense given certain kernel types.
-                So, for these types, we create branches off the end of that kernel type for all 
+                So, for these types, the team creates branches off the end of that kernel type for all 
                 of the BSPs that are supported on that kernel type.  
                 From the perspective of the tools that create the BSP branch, the BSP is really no 
                 different than a feature.
                 Consequently, the same branching strategy applies to BSPs as it does to features.
-                So again, rather than store the BSP twice, only the unique differences for the BSP across
-                the supported multiple kernels are uniquely stored.
+                So again, rather than store the BSP twice, the team only stores the unique 
+                differences for the BSP across the supported multiple kernels.
             </para>
             <para>
                 While this strategy can result in a tree with a significant number of branches, it is
-                important to realize that from the user's point of view, there is a linear
-                path that travels from the baseline kernel.org, through a select group of features and
-                ends with their BSP-specific commits.
+                important to realize that from the developer's point of view, there is a linear
+                path that travels from the baseline <filename>kernel.org</filename>, through a select
+                group of features and ends with their BSP-specific commits.
                 In other words, the divisions of the kernel are transparent and are not relevant 
                 to the developer on a day-to-day basis.  
-                From the user's perspective, this is the "master" branch.
-                They do not need not be aware of the existence of any other branches at all.  
-                Of course there is value in the existence of these branches
+                From the developer's perspective, this path is the "master" branch.
+                The developer does not need not be aware of the existence of any other branches at all.  
+                Of course, there is value in the existence of these branches
                 in the tree, should a person decide to explore them. 
                 For example, a comparison between two BSPs at either the commit level or at the line-by-line 
-                code diff level is now a trivial operation.
+                code <filename>diff</filename> level is now a trivial operation.
             </para>
             <para>
                 Working with the kernel as a structured tree follows recognized community best practices. 
-                In particular, the kernel as shipped with the product should be
-                considered an 'upstream source' and viewed as a series of
+                In particular, the kernel as shipped with the product, should be
+                considered an "upstream source" and viewed as a series of
                 historical and documented modifications (commits). 
                 These modifications represent the development and stabilization done
                 by the Yocto Project kernel development team.
@@ -273,7 +272,7 @@
                 Because commits only change at significant release points in the product life cycle,
                 developers can work on a branch created
                 from the last relevant commit in the shipped Yocto Project kernel. 
-                As mentioned previously, the structure is transparent to the user
+                As mentioned previously, the structure is transparent to the developer
                 because the kernel tree is left in this state after cloning and building the kernel.
             </para>
         </section>
@@ -281,20 +280,26 @@
         <section id='source-code-manager-git'>
             <title>Source Code Manager - Git</title>
             <para>
-                The Source Code Manager (SCM) is Git and it is the obvious mechanism for meeting the 
-                previously mentioned goals.  
-                Not only is it the SCM for kernel.org but Git continues to grow in popularity and
-                supports many different work flows, front-ends and management techniques.
+                The Source Code Manager (SCM) is Git.
+                This SCM is the obvious mechanism for meeting the previously mentioned goals.  
+                Not only is it the SCM for <filename>kernel.org</filename> but,
+                Git continues to grow in popularity and supports many different work flows, 
+                front-ends and management techniques.
             </para>
             <para>
                 You can find documentation on Git at <ulink url='http://git-scm.com/documentation'></ulink>.
-                Also, the Yocto Project Development manual has an introduction to Git and describes a 
-                minimal set of commands that allow you to be functional with Git.
+                You can also get an introduction to Git as it applies to the Yocto Project in the
+                "<ulink url='http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#git'>Git</ulink>"
+                section in <ulink url='http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html'>The 
+                Yocto Project Development Manual</ulink>. 
+                These referenced sections overview Git and describe a minimal set of 
+                commands that allow you to be functional using Git.
+                <note>
+                    You can use as much, or as little, of what Git has to offer to accomplish what
+                    you need for your project.
+                    You do not have to be a "Git Master" in order to use it with the Yocto Project.
+                </note>
             </para>
-            <note><para> 
-                It should be noted that you can use as much, or as little, of what Git has to offer 
-                as is appropriate to your project.
-            </para></note>
         </section>
     </section>
 
@@ -307,17 +312,19 @@
             present a simplified view of the kernel for ease of use.
         </para>
         <para>
-            The fundamental properties of the tools that manage and construct the
-            Yocto Project kernel are:
+            Fundamentally, the kernel tools that manage and construct the
+            Yocto Project kernel accomplish the following:
             <itemizedlist>
                 <listitem><para>Group patches into named, reusable features.</para></listitem>
-                <listitem><para>Allow top down control of included features.</para></listitem>
-                <listitem><para>Bind kernel configuration to kernel patches and features.</para></listitem>
+                <listitem><para>Allow top-down control of included features.</para></listitem>
+                <listitem><para>Bind kernel configurations to kernel patches and features.</para></listitem>
                 <listitem><para>Present a seamless Git repository that blends Yocto Project value 
-                    with the kernel.org history and development.</para></listitem>
+                    with the <filename>kernel.org</filename> history and development.</para></listitem>
             </itemizedlist>
         </para>
 <!--<para>
+WRITER NOTE: Put this in for post 1.1 if possible:
+
 The tools that construct a kernel tree will be discussed later in this 
 document. The following tools form the foundation of the Yocto Project 
 kernel toolkit:

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

@@ -11,7 +11,7 @@
         The Yocto Project presents the kernel as a fully patched, history-clean Git
         repository. 
         The Git tree represents the selected features, board support,
-        and configurations extensively tested by Yocto Project. 
+        and configurations extensively tested by the Yocto Project. 
         The Yocto Project kernel allows the end user to leverage community
         best practices to seamlessly manage the development, build and debug cycles.
     </para>
@@ -20,28 +20,47 @@
         on its history, organization, benefits, and use.
         The manual consists of two sections:
         <itemizedlist>
-            <listitem><para>Concepts - Describes concepts behind the kernel.
+            <listitem><para><emphasis>Concepts:</emphasis> Describes concepts behind the kernel.
                 You will understand how the kernel is organized and why it is organized in 
                 the way it is.  You will understand the benefits of the kernel's organization 
                 and the mechanisms used to work with the kernel and how to apply it in your 
                 design process.</para></listitem>
-            <listitem><para>Using the Kernel - Describes best practices and "how-to" information
-                that lets you put the kernel to practical use.  Some examples are "How to Build a 
-                Project Specific Tree", "How to Examine Changes in a Branch", and "Saving Kernel
-                Modifications."</para></listitem>
+            <listitem><para><emphasis>Using the Kernel:</emphasis> Describes best practices 
+                and "how-to" information
+                that lets you put the kernel to practical use.  
+                Some examples are how to examine changes in a branch and how to 
+                save kernel modifications.</para></listitem>
         </itemizedlist>
     </para>
+
     <para>
-        For more information on the kernel, see the following links:
+        For more information on the Linux kernel, see the following links:
         <itemizedlist>
-            <listitem><para><ulink url='http://ldn.linuxfoundation.org/book/1-a-guide-kernel-development-process'></ulink></para></listitem>
-            <listitem><para><ulink url='http://userweb.kernel.org/~akpm/stuff/tpp.txt'></ulink></para></listitem>
-            <listitem><para><ulink url='http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/HOWTO;hb=HEAD'></ulink></para></listitem> 
+            <listitem><para>The Linux Foundation's guide for kernel development
+                process - <ulink url='http://ldn.linuxfoundation.org/book/1-a-guide-kernel-development-process'></ulink></para></listitem>
+<!--            <listitem><para><ulink url='http://userweb.kernel.org/~akpm/stuff/tpp.txt'></ulink></para></listitem> -->
+            <listitem><para>A fairly emcompassing guide on Linux kernel development - 
+                <ulink url='http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/HOWTO;hb=HEAD'></ulink></para></listitem> 
         </itemizedlist>
-        <para> 
-        You can find more information on Yocto Project by visiting the website at
+    </para>
+
+    <para>
+        For more discussion on the Yocto Project kernel, you can see these sections
+        in <ulink url='http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html'>The Yocto Project Development Manual</ulink>:
+        <itemizedlist>
+            <listitem><para>
+                "<ulink url='http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#kernel-overview'>Kernel Overview</ulink>"</para></listitem>
+            <listitem><para>
+                "<ulink url='http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#kernel-modification-workflow'>Kernel Modification Workflow</ulink>"
+                </para></listitem>
+            <listitem><para> 
+                "<ulink url='http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#dev-manual-kernel-appendix'>Kernel Modification Example</ulink>".</para></listitem>
+        </itemizedlist>
+    </para>
+
+    <para> 
+        For general information on the Yocto Project, visit the website at
         <ulink url='http://www.yoctoproject.org'></ulink>.
-        </para>
     </para>
 </section>
 

documentation/kernel-manual/kernel-manual.xml

@@ -31,18 +31,22 @@
             <revision>
                 <revnumber>0.9</revnumber>
                 <date>24 November 2010</date>
-                <revremark>This revision is the initial document draft and corresponds with 
-                    the Yocto Project 0.9 Release.</revremark>
+                <revremark>The initial document draft released with the Yocto Project 0.9 Release.</revremark>
             </revision>
             <revision>
                 <revnumber>1.0</revnumber>
                 <date>6 April 2011</date>
-                <revremark>This revision corresponds with the Yocto Project 1.0 Release.</revremark>
+                <revremark>Released with the Yocto Project 1.0 Release.</revremark>
             </revision>
             <revision>
                 <revnumber>1.0.1</revnumber>
                 <date>23 May 2011</date>
-                <revremark>Released with Yocto Project 1.0.1 on 23 May 2011.</revremark>
+                <revremark>Released with the Yocto Project 1.0.1 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.1</revnumber>
+                <date>6 October 2011</date>
+                <revremark>Released with the Yocto Project 1.1 Release.</revremark>
             </revision>
         </revhistory>
 
@@ -59,7 +63,7 @@
       <note>
           Due to production processes, there could be differences between the Yocto Project
           documentation bundled in the release tarball and 
-          <ulink url='http://www.yoctoproject.org/docs/1.1/kernel-manual/kernel-manual.html'>
+          <ulink url='http://www.yoctoproject.org/docs/latest/kernel-manual/kernel-manual.html'>
           The Yocto Project Kernel Architecture and Use Manual</ulink> on
           the <ulink url='http://www.yoctoproject.org'>Yocto Project</ulink> website.
           For the latest version of this manual, see the manual on the website.

documentation/kernel-manual/style.css

@@ -966,3 +966,9 @@ table {
    color: #fff;   
    text-decoration: underline;
 }
+
+.footnote {
+   font-size: small;
+   color: #333;
+}
+

documentation/poky-ref-manual/development.xml

@@ -91,9 +91,9 @@
             with other plug-ins installed into the Eclipse IDE.
             Once you have your environment setup you need to configure the Eclipse plug-in.
             For information on how to install and configure the Eclipse plug-in, see the
-            <ulink url='http://www.yoctoproject.org/docs/adt-manual/adt-manual.html#adt-eclipse'>
+            <ulink url='http://www.yoctoproject.org/docs/latest/adt-manual/adt-manual.html#adt-eclipse'>
             "Working Within Eclipse"</ulink> chapter in the 
-            <ulink url='http://www.yoctoproject.org/docs/adt-manual/adt-manual.html'>
+            <ulink url='http://www.yoctoproject.org/docs/latest/adt-manual/adt-manual.html'>
             "Application Development Toolkit (ADT) User's Guide."</ulink>
          </para>
          </section>
@@ -102,7 +102,7 @@
         <title>External Development Using the QEMU Emulator</title>
         <para>
             Running Poky QEMU images is covered in the 
-            <ulink url="http://www.yoctoproject.org/docs/yocto-quick-start/yocto-project-qs.html">
+            <ulink url="http://www.yoctoproject.org/docs/latest/yocto-project-qs/yocto-project-qs.html">
             Yocto Project Quick Start</ulink> in the "A Quick Test Run" section.
         </para>
         <para>
@@ -284,7 +284,7 @@
 
         <para>
             Because an external shell is launched rather than opening directly into the 
-            original terminal window, it allows easier interaction with Bitbake's multiple 
+            original terminal window, it allows easier interaction with BitBake's multiple
             threads as well as accomodates a future client/server split.
         </para>
 

documentation/poky-ref-manual/extendpoky.xml

@@ -3,13 +3,13 @@
 
 <chapter id='extendpoky'>
 
-<title>Extending the Yocto Project</title>
+<title>Common Tasks</title>
     <para>
-        This chapter provides information about how to extend the functionality
-        already present in the Yocto Project.
-        The chapter also documents standard tasks such as adding new
+        This chapter describes standard tasks such as adding new
         software packages, extending or customizing images or porting the Yocto Project to
         new hardware (adding a new machine). 
+        The chapter also describes ways to modify package source code, combine multiple 
+        versions of library files into a single image, and handle a package name alias.
         Finally, the chapter contains advice about how to make changes to the 
         Yocto Project to achieve the best results.
     </para>
@@ -79,7 +79,8 @@
                 By default, the <filename>helloworld</filename>, <filename>helloworld-dbg</filename>,
                 and <filename>helloworld-dev</filename> packages are built. 
                 For information on how to customize the packaging process, see the
-                <link linkend='usingpoky-extend-addpkg-files'>Controlling Package Content</link> section.
+                "<link linkend='splitting-an-application-into-multiple-packages'>Splitting an Application
+                into Multiple Packages</link>" section.
             </para>
         </section>
 
@@ -174,8 +175,8 @@
             </para>
         </section>
 
-        <section id='usingpoky-extend-addpkg-files'>
-            <title>Controlling Package Content</title>
+        <section id='splitting-an-application-into-multiple-packages'>
+            <title>Splitting an Application into Multiple Packages</title>
 
             <para>                        
                 You can use the variables <filename><link linkend='var-PACKAGES'>PACKAGES</link></filename> and 
@@ -222,6 +223,59 @@
             </para>
         </section>
 
+        <section id='including-static-library-files'>
+            <title>Including Static Library Files</title>
+
+            <para>                        
+                If you are building a library and the library offers static linking, you can control
+                which static library files (<filename>*.a</filename> files) get included in the 
+                built library.  
+            </para>
+
+            <para>
+                The <filename>PACKAGES</filename> and <filename>FILES_*</filename> 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 
+                <filename>${PN}-staticdev</filename>, which includes all static library files.
+                <note>
+                    Previously released versions of the Yocto Project defined the static library files 
+                    through <filename>${PN}-dev</filename>.
+                </note>
+                Following, is part of the BitBake configuration file. 
+                You can see where the static library files are defined:
+                <literallayout class='monospaced'>
+     PACKAGES = "${PN}-dbg ${PN} ${PN}-doc ${PN}-dev ${PN}-staticdev ${PN}-locale"
+     PACKAGES_DYNAMIC = "${PN}-locale-*"
+     FILES = ""
+
+     FILES_${PN} = "${bindir}/* ${sbindir}/* ${libexecdir}/* ${libdir}/lib*${SOLIBS} \
+                 ${sysconfdir} ${sharedstatedir} ${localstatedir} \
+                 ${base_bindir}/* ${base_sbindir}/* \
+                 ${base_libdir}/*${SOLIBS} \
+                 ${datadir}/${BPN} ${libdir}/${BPN}/* \
+                 ${datadir}/pixmaps ${datadir}/applications \
+                 ${datadir}/idl ${datadir}/omf ${datadir}/sounds \
+                 ${libdir}/bonobo/servers"
+
+     FILES_${PN}-doc = "${docdir} ${mandir} ${infodir} ${datadir}/gtk-doc \
+                 ${datadir}/gnome/help"
+     SECTION_${PN}-doc = "doc"
+     
+     FILES_${PN}-dev = "${includedir} ${libdir}/lib*${SOLIBSDEV} ${libdir}/*.la \
+                     ${libdir}/*.o ${libdir}/pkgconfig ${datadir}/pkgconfig \
+                     ${datadir}/aclocal ${base_libdir}/*.o"
+     SECTION_${PN}-dev = "devel"
+     ALLOW_EMPTY_${PN}-dev = "1"
+     RDEPENDS_${PN}-dev = "${PN} (= ${EXTENDPKGV})"
+     
+     FILES_${PN}-staticdev = "${libdir}/*.a ${base_libdir}/*.a"
+     SECTION_${PN}-staticdev = "devel"
+     RDEPENDS_${PN}-staticdev = "${PN}-dev (= ${EXTENDPKGV})"
+                </literallayout>
+            </para>
+        </section>
+
         <section id='usingpoky-extend-addpkg-postinstalls'>
             <title>Post Install Scripts</title>
 
@@ -303,7 +357,7 @@
                 It is important to use the correct names of packages in the 
                 <filename><link linkend='var-IMAGE_INSTALL'>IMAGE_INSTALL</link></filename> variable. 
                 You must use the OpenEmbedded notation and not the Debian notation for the names 
-                (e.g. <filename>glibc-dev</filename> instead of <filename>libc6-dev</filename>).
+                (e.g. <filename>eglibc-dev</filename> instead of <filename>libc6-dev</filename>).
             </para>
 
             <para>
@@ -470,16 +524,16 @@
             The information covers adding machines similar to those the Yocto Project already supports. 
             Although well within the capabilities of the Yocto Project, adding a totally new architecture 
             might require 
-            changes to <filename>gcc/glibc</filename> and to the site information, which is 
+            changes to <filename>gcc/eglibc</filename> and to the site information, which is 
             beyond the scope of this manual.
         </para>
 
         <para>
             For a complete example that shows how to add a new machine to the Yocto Project, 
             see the 
-            <ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html#dev-manual-bsp-appendix'>
+            <ulink url='http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#dev-manual-bsp-appendix'>
             BSP Development Example</ulink> in Appendix A of  
-            <ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html'>
+            <ulink url='http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html'>
             The Yocto Project Development Manual</ulink>.
         </para>
 
@@ -604,6 +658,307 @@
         </section>
     </section>
 
+    <section id="usingpoky-modifing-packages">
+        <title>Modifying Package Source Code</title>
+        <para>
+            Although the Yocto Project is usually used to build software, you can use it to modify software. 
+        </para>
+
+        <para>
+            During a build, source is available in the 
+            <filename><link linkend='var-WORKDIR'>WORKDIR</link></filename> directory.
+            The actual location depends on the type of package and the architecture of the target device. 
+            For a standard recipe not related to 
+            <filename><link linkend='var-MACHINE'>MACHINE</link></filename>, the location is
+            <filename>tmp/work/PACKAGE_ARCH-poky-TARGET_OS/PN-PV-PR/</filename>.
+            For target device-dependent packages, you should use the <filename>MACHINE</filename>
+            variable instead of 
+            <filename><link linkend='var-PACKAGE_ARCH'>PACKAGE_ARCH</link></filename> 
+            in the directory name.
+        </para>
+
+        <tip>
+            Be sure the package recipe sets the 
+            <filename><link linkend='var-S'>S</link></filename> variable to something
+            other than the standard <filename>WORKDIR/PN-PV/</filename> value.
+        </tip>
+
+        <para>
+            After building a package, you can modify the package source code without problems. 
+            The easiest way to test your changes is by calling the 
+            <filename>compile</filename> task as shown in the following example:
+            <literallayout class='monospaced'>
+     $ bitbake -c compile -f NAME_OF_PACKAGE
+            </literallayout>
+        </para>
+
+        <para>
+            The <filename>-f</filename> or <filename>--force</filename>
+            option forces re-execution of the specified task.
+            You can call other tasks this way as well. 
+            But note that all the modifications in 
+            <filename><link linkend='var-WORKDIR'>WORKDIR</link></filename>
+            are gone once you execute <filename>-c clean</filename> for a package.
+        </para>
+    </section>
+
+    <section id="usingpoky-modifying-packages-quilt">
+        <title>Modifying Package Source Code with Quilt</title>
+            
+        <para>
+            By default Poky uses <ulink url='http://savannah.nongnu.org/projects/quilt'>Quilt</ulink>
+            to manage patches in the <filename>do_patch</filename> task. 
+            This is a powerful tool that you can use to track all modifications to package sources.
+        </para>
+
+        <para>
+            Before modifying source code, it is important to notify Quilt so it can track the changes 
+            into the new patch file:
+            <literallayout class='monospaced'>
+     $ quilt new NAME-OF-PATCH.patch
+            </literallayout>
+        </para>
+
+        <para>
+            After notifying Quilt, add all modified files into that patch:
+            <literallayout class='monospaced'>
+     $ quilt add file1 file2 file3
+            </literallayout>
+        </para>
+
+        <para>
+            You can now start editing. 
+            Once you are done editing, you need to use Quilt to generate the final patch that 
+            will contain all your modifications.
+            <literallayout class='monospaced'>
+     $ quilt refresh
+            </literallayout>
+        </para>
+
+        <para>
+            You can find the resulting patch file in the
+            <filename>patches/</filename> subdirectory of the source 
+            (<filename><link linkend='var-S'>S</link></filename>) directory. 
+            For future builds, you should copy the patch into the Yocto Project metadata and add it into the 
+            <filename><link linkend='var-SRC_URI'>SRC_URI</link></filename> of a recipe.  
+            Here is an example:
+            <literallayout class='monospaced'>
+     SRC_URI += "file://NAME-OF-PATCH.patch"
+            </literallayout>
+        </para>
+
+        <para>
+            Finally, don't forget to 'bump' the 
+            <filename><link linkend='var-PR'>PR</link></filename> value in the same recipe since 
+            the resulting packages have changed.
+        </para>
+    </section>
+
+    <section id="building-multiple-architecture-libraries-into-one-image">
+        <title>Combining Multiple Versions of Library Files into One Image</title>
+
+        <para>
+            The build system offers the ability to build libraries with different
+            target optimizations or architecture formats and combine these together
+            into one system image. 
+            You can link different binaries in the image 
+            against the different libraries as needed for specific use cases.
+            This feature is called "Multilib."
+        </para>
+
+        <para>
+            An example would be where you have most of a system compiled in 32-bit
+            mode using 32-bit libraries, but you have something large, like a database
+            engine, that needs to be a 64-bit application and use 64-bit libraries.
+            Multilib allows you to get the best of both 32-bit and 64-bit libraries.
+        </para>
+
+        <para>
+            While the Multilib feature is most commonly used for 32 and 64-bit differences,
+            the approach the build system uses facilitates different target optimizations. 
+            You could compile some binaries to use one set of libraries and other binaries
+            to use other different sets of libraries.
+            The libraries could differ in architecture, compiler options, or other 
+            optimizations.
+        </para>
+
+        <para>
+            This section overviews the Multilib process only. 
+            For more details on how to implement Multilib, see the 
+            <ulink url='https://wiki.yoctoproject.org/wiki/Multilib'>Multilib</ulink> wiki 
+            page.
+        </para>
+
+        <section id='preparing-to-use-multilib'>
+            <title>Preparing to use Multilib</title>
+
+            <para>
+                User-specific requirements drive the Multilib feature,
+                Consequently, there is no one "out-of-the-box" configuration that likely
+                exists to meet your needs.
+            </para>
+
+            <para>
+                In order to enable Multilib, you first need to ensure your recipe is
+                extended to support multiple libraries. 
+                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 Yocto Project files directory to see how this is 
+                done using the <filename>BBCLASSEXTEND</filename> variable.
+                Eventually, all recipes will be covered and this list will be unneeded.
+            </para>
+  
+            <para>
+                For the most part, the Multilib class extension works automatically to
+                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.
+                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. 
+                This automatic extension code resides in <filename>multilib.bbclass</filename>.
+            </para>
+        </section>
+
+        <section id='using-multilib'>
+            <title>Using Multilib</title>
+
+            <para>
+                After you have set up the recipes, you need to define the actual
+                combination of multiple libraries you want to build. 
+                You accomplish this through your <filename>local.conf</filename>
+                configuration file in the Yocto Project build directory. 
+                An example configuration would be as follows:
+                <literallayout class='monospaced'>
+     MACHINE = "qemux86-64"
+     require conf/multilib.conf
+     MULTILIBS = "multilib:lib32"
+     DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
+     MULTILIB_IMAGE_INSTALL = "lib32-connman"
+                </literallayout>
+                This example enables an
+                additional library named <filename>lib32</filename> alongside the 
+                normal target packages.
+                When combining these "lib32" alternatives, the example uses "x86" for tuning.
+                For information on this particular tuning, see
+                <filename>meta/conf/machine/include/ia32/arch-ia32.inc</filename>.
+            </para>
+
+            <para>
+                The example then includes <filename>lib32-connman</filename>
+                in all the images, which illustrates one method of including a 
+                multiple library dependency. 
+                You can use a normal image build to include this dependency,
+                for example:
+                <literallayout class='monospaced'>
+     $ bitbake core-image-sato
+                </literallayout>
+                You can also build Multilib packages specifically with a command like this:
+                <literallayout class='monospaced'>
+     $  bitbake lib32-connman
+                </literallayout>
+            </para>
+        </section>
+
+        <section id='additional-implementation-details'>
+            <title>Additional Implementation Details</title>
+
+            <para>
+                Different packaging systems have different levels of native Multilib
+                support. 
+                For the RPM Package Management System, the following implementation details 
+                exist:
+                <itemizedlist>
+                    <listitem><para>A unique architecture is defined for the Multilib packages,
+                        along with creating a unique deploy folder under 
+                        <filename>tmp/deploy/rpm</filename> in the Yocto
+                        Project build directory. 
+                        For example, consider <filename>lib32</filename> in a 
+                        <filename>qemux86-64</filename> image. 
+                        The possible architectures in the system are "all", "qemux86_64",
+                        "lib32_qemux86_64", and "lib32_x86".</para></listitem>
+                    <listitem><para>The <filename>${MLPREFIX}</filename> variable is stripped from 
+                        <filename>${PN}</filename> during RPM packaging.
+                        The naming for a normal RPM package and a Multilib RPM package in a
+                        <filename>qemux86-64</filename> system resolves to something similar to
+                        <filename>bash-4.1-r2.x86_64.rpm</filename> and 
+                        <filename>bash-4.1.r2.lib32_x86.rpm</filename>, respectively.
+                        </para></listitem>
+                    <listitem><para>When installing a Multilib image, the RPM backend first 
+                        installs the base image and then installs the Multilib libraries.
+                        </para></listitem>
+                    <listitem><para>The build system relies on RPM to resolve the identical files in the 
+                        two (or more) Multilib packages.</para></listitem>
+                </itemizedlist>
+            </para>
+
+            <para>
+                For the IPK Package Management System, the following implementation details exist:
+                <itemizedlist>
+                    <listitem><para>The <filename>${MLPREFIX}</filename> is not stripped from 
+                        <filename>${PN}</filename> during IPK packaging.
+                        The naming for a normal RPM package and a Multilib IPK package in a
+                        <filename>qemux86-64</filename> system resolves to something like 
+                        <filename>bash_4.1-r2.x86_64.ipk</filename> and
+                        <filename>lib32-bash_4.1-rw_x86.ipk</filename>, respectively.
+                        </para></listitem>
+                    <listitem><para>The IPK deploy folder is not modified with 
+                        <filename>${MLPREFIX}</filename> because packages with and without 
+                        the Multilib feature can exist in the same folder due to the 
+                        <filename>${PN}</filename> differences.</para></listitem>
+                    <listitem><para>IPK defines a sanity check for Multilib installation 
+                        using certain rules for file comparison, overridden, etc.
+                        </para></listitem>
+                </itemizedlist>
+            </para>
+        </section> 
+    </section>
+
+    <section id="usingpoky-configuring-DISTRO_PN_ALIAS">
+        <title>Handling a Package Name Alias</title>
+        <para>
+            Sometimes a package name you are using might exist under an alias or as a similarly named
+            package in a different distribution.
+            The Yocto Project implements a <filename>distro_check</filename>
+            task that automatically connects to major distributions
+            and checks for these situations. 
+            If the package exists under a different name in a different distribution, you get a 
+            <filename>distro_check</filename> mismatch.  
+            You can resolve this problem by defining a per-distro recipe name alias using the 
+            <filename><link linkend='var-DISTRO_PN_ALIAS'>DISTRO_PN_ALIAS</link></filename> variable.
+        </para>
+
+        <para>
+            Following is an example that shows how you specify the <filename>DISTRO_PN_ALIAS</filename>
+            variable:
+            <literallayout class='monospaced'>
+     DISTRO_PN_ALIAS_pn-PACKAGENAME = "distro1=package_name_alias1 \
+                                       distro2=package_name_alias2 \
+                                       distro3=package_name_alias3 \
+                                       ..."
+            </literallayout>
+        </para>
+        
+        <para>
+            If you have more than one distribution alias, separate them with a space.
+            Note that the Yocto Project currently automatically checks the 
+            Fedora, OpenSuSE, Debian, Ubuntu, 
+            and Mandriva distributions for source package recipes without having to specify them 
+            using the <filename>DISTRO_PN_ALIAS</filename> variable.
+            For example, the following command generates a report that lists the Linux distributions
+            that include the sources for each of the Yocto Project recipes.
+            <literallayout class='monospaced'>
+     $ bitbake world -f -c distro_check
+            </literallayout>
+            The results are stored in the <filename>build/tmp/log/distro_check-${DATETIME}.results</filename> 
+            file found in the Yocto Project files area.
+        </para>
+    </section>
+
     <section id="usingpoky-changes">
         <title>Making and Maintaining Changes</title>
         <para>
@@ -860,7 +1215,7 @@
                 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://www.yoctoproject.org:8010'>the buildbot for the 
                 Yocto Project</ulink> for an example implementation that uses buildbot.
             </para>
 
@@ -922,247 +1277,6 @@
         </section>
     </section>
 
-    <section id="usingpoky-modifing-packages">
-        <title>Modifying Package Source Code</title>
-        <para>
-            Although the Yocto Project is usually used to build software, you can use it to modify software. 
-        </para>
-
-        <para>
-            During a build, source is available in the 
-            <filename><link linkend='var-WORKDIR'>WORKDIR</link></filename> directory.
-            The actual location depends on the type of package and the architecture of the target device. 
-            For a standard recipe not related to 
-            <filename><link linkend='var-MACHINE'>MACHINE</link></filename>, the location is
-            <filename>tmp/work/PACKAGE_ARCH-poky-TARGET_OS/PN-PV-PR/</filename>.
-            For target device-dependent packages, you should use the <filename>MACHINE</filename>
-            variable instead of 
-            <filename><link linkend='var-PACKAGE_ARCH'>PACKAGE_ARCH</link></filename> 
-            in the directory name.
-        </para>
-
-        <tip>
-            Be sure the package recipe sets the 
-            <filename><link linkend='var-S'>S</link></filename> variable to something
-            other than the standard <filename>WORKDIR/PN-PV/</filename> value.
-        </tip>
-
-        <para>
-            After building a package, you can modify the package source code without problems. 
-            The easiest way to test your changes is by calling the 
-            <filename>compile</filename> task as shown in the following example:
-            <literallayout class='monospaced'>
-     $ bitbake -c compile -f NAME_OF_PACKAGE
-            </literallayout>
-        </para>
-
-        <para>
-            The <filename>-f</filename> or <filename>--force</filename>
-            option forces re-execution of the specified task.
-            You can call other tasks this way as well. 
-            But note that all the modifications in 
-            <filename><link linkend='var-WORKDIR'>WORKDIR</link></filename>
-            are gone once you execute <filename>-c clean</filename> for a package.
-        </para>
-    </section>
-
-    <section id="usingpoky-modifying-packages-quilt">
-        <title>Modifying Package Source Code with Quilt</title>
-            
-        <para>
-            By default Poky uses <ulink url='http://savannah.nongnu.org/projects/quilt'>Quilt</ulink>
-            to manage patches in the <filename>do_patch</filename> task. 
-            This is a powerful tool that you can use to track all modifications to package sources.
-        </para>
-
-        <para>
-            Before modifying source code, it is important to notify Quilt so it can track the changes 
-            into the new patch file:
-            <literallayout class='monospaced'>
-     $ quilt new NAME-OF-PATCH.patch
-            </literallayout>
-        </para>
-
-        <para>
-            After notifying Quilt, add all modified files into that patch:
-            <literallayout class='monospaced'>
-     $ quilt add file1 file2 file3
-            </literallayout>
-        </para>
-
-        <para>
-            You can now start editing. 
-            Once you are done editing, you need to use Quilt to generate the final patch that 
-            will contain all your modifications.
-            <literallayout class='monospaced'>
-     $ quilt refresh
-            </literallayout>
-        </para>
-
-        <para>
-            You can find the resulting patch file in the
-            <filename>patches/</filename> subdirectory of the source 
-            (<filename><link linkend='var-S'>S</link></filename>) directory. 
-            For future builds, you should copy the patch into the Yocto Project metadata and add it into the 
-            <filename><link linkend='var-SRC_URI'>SRC_URI</link></filename> of a recipe.  
-            Here is an example:
-            <literallayout class='monospaced'>
-     SRC_URI += "file://NAME-OF-PATCH.patch"
-            </literallayout>
-        </para>
-
-        <para>
-            Finally, don't forget to 'bump' the 
-            <filename><link linkend='var-PR'>PR</link></filename> value in the same recipe since 
-            the resulting packages have changed.
-        </para>
-    </section>
-
-    <section id="usingpoky-configuring-LIC_FILES_CHKSUM">
-        <title>Tracking License Changes</title>
-
-        <para>
-            The license of an upstream project might change in the future. In order to prevent these changes
-            going unnoticed, the Yocto Project provides a 
-            <filename><link linkend='var-LIC_FILES_CHKSUM'>LIC_FILES_CHKSUM</link></filename>
-            variable to track changes to the license text. The checksums are validated at the end of the
-            configure step, and if the checksums do not match, the build will fail.
-        </para>
-
-        <section id="usingpoky-specifying-LIC_FILES_CHKSUM">
-            <title>Specifying the <filename>LIC_FILES_CHKSUM</filename> Variable</title>
-
-            <para>
-                The <filename>LIC_FILES_CHKSUM</filename>
-                variable contains checksums of the license text in the source code for the recipe.
-                Following is an example of how to specify <filename>LIC_FILES_CHKSUM</filename>:
-                <literallayout class='monospaced'>
-     LIC_FILES_CHKSUM = "file://COPYING;md5=xxxx \
-                         file://licfile1.txt;beginline=5;endline=29;md5=yyyy \
-                         file://licfile2.txt;endline=50;md5=zzzz \
-                         ..."
-                </literallayout>
-            </para>
-
-            <para>
-                The Yocto Project uses the 
-                <filename><link linkend='var-S'>S</link></filename> variable as the 
-                default directory used when searching files listed in 
-                <filename>LIC_FILES_CHKSUM</filename>.
-                The previous example employs the default directory.
-            </para>
-
-            <para>
-                You can also use relative paths as shown in the following example: 
-                <literallayout class='monospaced'>
-     LIC_FILES_CHKSUM = "file://src/ls.c;startline=5;endline=16;\
-                                         md5=bb14ed3c4cda583abc85401304b5cd4e"
-     LIC_FILES_CHKSUM = "file://../license.html;md5=5c94767cedb5d6987c902ac850ded2c6"
-                </literallayout>
-            </para>
-
-            <para>
-                In this example, the first line locates a file in 
-                <filename><link linkend='var-S'>S</link>/src/ls.c</filename>. 
-                The second line refers to a file in 
-                <filename><link linkend='var-WORKDIR'>WORKDIR</link></filename>, which is the parent
-                of <filename>S</filename>.
-            </para>
-            <para>
-                Note that this variable is mandatory for all recipes, unless the 
-                <filename>LICENSE</filename> variable is set to "CLOSED".
-            </para>
-        </section>
-
-        <section id="usingpoky-LIC_FILES_CHKSUM-explanation-of-syntax">
-            <title>Explanation of Syntax</title>
-            <para>
-                As mentioned in the previous section, the 
-                <filename>LIC_FILES_CHKSUM</filename> variable lists all the 
-                important files that contain the license text for the source code. 
-                It is possible to specify a checksum for an entire file, or a specific section of a
-                file (specified by beginning and ending line numbers with the "beginline" and "endline"
-                parameters respectively). 
-                The latter is useful for source files with a license notice header,
-                README documents, and so forth.
-                If you do not use the "beginline" parameter, then it is assumed that the text begins on the 
-                first line of the file. 
-                Similarly, if you do not use the "endline" parameter, it is assumed that the license text 
-                ends with the last line of the file. 
-            </para>
-
-            <para>
-                The "md5" parameter stores the md5 checksum of the license text. 
-                If the license text changes in any way as compared to this parameter
-                then a mismatch occurs.
-                This mismatch triggers a build failure and notifies the developer.
-                Notification allows the developer to review and address the license text changes.
-                Also note that if a mismatch occurs during the build, the correct md5 
-                checksum is placed in the build log and can be easily copied to the recipe.
-            </para>
-
-            <para>
-                There is no limit to how many files you can specify using the 
-                <filename>LIC_FILES_CHKSUM</filename> variable.
-                Generally, however, every project requires a few specifications for license tracking. 
-                Many projects have a "COPYING" file that stores the license information for all the source 
-                code files.
-                This practice allows you to just track the "COPYING" file as long as it is kept up to date. 
-            </para>
-
-            <tip>
-                If you specify an empty or invalid "md5" parameter, BitBake returns an md5 mis-match 
-                error and displays the correct "md5" parameter value during the build. 
-                The correct parameter is also captured in the build log. 
-            </tip>
-
-            <tip>
-                If the whole file contains only license text, you do not need to use the "beginline" and 
-                "endline" parameters. 
-            </tip>
-        </section>
-    </section>
-
-    <section id="usingpoky-configuring-DISTRO_PN_ALIAS">
-        <title>Handling a Package Name Alias</title>
-        <para>
-            Sometimes a package name you are using might exist under an alias or as a similarly named
-            package in a different distribution.
-            The Yocto Project implements a <filename>distro_check</filename>
-            task that automatically connects to major distributions
-            and checks for these situations. 
-            If the package exists under a different name in a different distribution, you get a 
-            <filename>distro_check</filename> mismatch.  
-            You can resolve this problem by defining a per-distro recipe name alias using the 
-            <filename><link linkend='var-DISTRO_PN_ALIAS'>DISTRO_PN_ALIAS</link></filename> variable.
-        </para>
-
-        <para>
-            Following is an example that shows how you specify the <filename>DISTRO_PN_ALIAS</filename>
-            variable:
-            <literallayout class='monospaced'>
-     DISTRO_PN_ALIAS_pn-PACKAGENAME = "distro1=package_name_alias1 \
-                                       distro2=package_name_alias2 \
-                                       distro3=package_name_alias3 \
-                                       ..."
-            </literallayout>
-        </para>
-        
-        <para>
-            If you have more than one distribution alias, separate them with a space.
-            Note that the Yocto Project currently automatically checks the 
-            Fedora, OpenSuSE, Debian, Ubuntu, 
-            and Mandriva distributions for source package recipes without having to specify them 
-            using the <filename>DISTRO_PN_ALIAS</filename> variable.
-            For example, the following command generates a report that lists the Linux distributions
-            that include the sources for each of the Yocto Project recipes.
-            <literallayout class='monospaced'>
-     $ bitbake world -f -c distro_check
-            </literallayout>
-            The results are stored in the <filename>build/tmp/log/distro_check-${DATETIME}.results</filename> 
-            file found in the Yocto Project files area.
-        </para>
-    </section>
 </chapter>
 
 <!-- 

documentation/poky-ref-manual/faq.xml

@@ -14,7 +14,7 @@
             <para>
                 Poky is the Yocto Project build system that was derived from <ulink 
                 url='http://www.openembedded.org/'>OpenEmbedded</ulink>.
-                Poky is a stable, smaller subset focused on the GNOME Mobile environment. 
+                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.
             </para>
@@ -33,8 +33,8 @@
                 You can use a stand-alone tarball to provide Python 2.6.
                 You can find pre-built 32 and 64-bit versions of Python 2.6 at the following locations:
                 <itemizedlist>
-                    <listitem><para><ulink url='http://autobuilder.yoctoproject.org/downloads/miscsupport/yocto-1.0-python-nativesdk/python-nativesdk-standalone-i686.tar.bz2'>32-bit tarball</ulink></para></listitem>
-                    <listitem><para><ulink url='http://autobuilder.yoctoproject.org/downloads/miscsupport/yocto-1.0-python-nativesdk/python-nativesdk-standalone-x86_64.tar.bz2'>64-bit tarball</ulink></para></listitem>
+                    <listitem><para><ulink url='http://www.yoctoproject.org/downloads/miscsupport/yocto-1.1-python-nativesdk/python-nativesdk-standalone-i686.tar.bz2'>32-bit tarball</ulink></para></listitem>
+                    <listitem><para><ulink url='http://www.yoctoproject.org/downloads/miscsupport/yocto-1.1-python-nativesdk/python-nativesdk-standalone-x86_64.tar.bz2'>64-bit tarball</ulink></para></listitem>
                 </itemizedlist>
             </para>
             <para>
@@ -237,7 +237,7 @@
         <question>
             <para>
                 I see lots of 404 responses for files on 
-                <filename>http://autobuilder.yoctoproject.org/sources/*</filename>. Is something wrong?
+                <filename>http://www.yoctoproject.org/sources/*</filename>. Is something wrong?
             </para>
         </question>
         <answer>
@@ -520,10 +520,10 @@
                 configuration file:
                 <literallayout class='monospaced'>
      PREMIRRORS_prepend = "\
-     git://.*/.* http://autobuilder.yoctoproject.org/sources/ \n \
-     ftp://.*/.* http://autobuilder.yoctoproject.org/sources/ \n \
-     http://.*/.* http://autobuilder.yoctoproject.org/sources/ \n \
-     https://.*/.* http://autobuilder.yoctoproject.org/sources/ \n"
+     git://.*/.* http://www.yoctoproject.org/sources/ \n \
+     ftp://.*/.* http://www.yoctoproject.org/sources/ \n \
+     http://.*/.* http://www.yoctoproject.org/sources/ \n \
+     https://.*/.* http://www.yoctoproject.org/sources/ \n"
                 </literallayout>
             </para>
             <para>
@@ -564,9 +564,9 @@
                  configuration file as long as the PREMIRROR server is up to date:
                  <literallayout class='monospaced'>
      PREMIRRORS_prepend = "\
-     ftp://.*/.* http://autobuilder.yoctoproject.org/sources/ \n \
-     http://.*/.* http://autobuilder.yoctoproject.org/sources/ \n \
-     https://.*/.* http://autobuilder.yoctoproject.org/sources/ \n"
+     ftp://.*/.* http://www.yoctoproject.org/sources/ \n \
+     http://.*/.* http://www.yoctoproject.org/sources/ \n \
+     https://.*/.* http://www.yoctoproject.org/sources/ \n"
      BB_FETCH_PREMIRRORONLY = "1" 
                  </literallayout>
                  These changes would cause Poky to successfully fetch source over HTTP and 

documentation/poky-ref-manual/introduction.xml

@@ -15,8 +15,11 @@
         construct complete Linux images.
         You can find complete introductory and getting started information on the Yocto Project
         by reading the 
-        <ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html'>   
+        <ulink url='http://www.yoctoproject.org/docs/latest/yocto-project-qs/yocto-project-qs.html'>   
         Yocto Project Quick Start</ulink>.
+        For task-based information using the Yocto Project, see 
+        <ulink url='http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html'>
+        The Yocto Project Development Manual</ulink>.
         You can also find lots of information on the Yocto Project on the 
         <ulink url="http://www.yoctoproject.org">Yocto Project website</ulink>.
     </para>
@@ -36,6 +39,11 @@
                 <link linkend='extendpoky'>Extending the Yocto Project</link>:</emphasis> This chapter
                 provides information about how to extend and customize the Yocto Project 
                 along with advice on how to manage these changes.</para></listitem>
+            <listitem><para><emphasis>
+                <link linkend='technical-details'>Technical Details</link>:</emphasis> 
+                This chapter describes fundamental Yocto Project components as well as an explanation
+                behind how the Yocto Project uses shared state (sstate) cache to speed build time.
+                </para></listitem>
             <listitem><para><emphasis>
                 <link linkend='bsp'>Board Support Packages (BSP) - Developer's Guide</link>:</emphasis> 
                 This chapter describes the example filesystem layout for BSP development and 
@@ -89,10 +97,10 @@
 <section id='intro-requirements'>
 <title>System Requirements</title>
     <para>
-        For system Yocto Project system requirements, see the 
-        <ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#resources'>
+        For Yocto Project system requirements, see the
+        <ulink url='http://www.yoctoproject.org/docs/latest/yocto-project-qs/yocto-project-qs.html#resources'>
         What You Need and How You Get It</ulink> section in the 
-        <ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html'>
+        <ulink url='http://www.yoctoproject.org/docs/latest/yocto-project-qs/yocto-project-qs.html'>
         Yocto Project Quick Start</ulink>.
     </para>
 </section>
@@ -104,9 +112,9 @@
         of methods:
         <itemizedlist>
             <listitem><para><emphasis>Releases:</emphasis> Stable, tested releases are available through 
-                <ulink url='http://yoctoproject.org/downloads/poky/'/>.</para></listitem>
+                <ulink url='http://downloads.yoctoproject.org/releases/yocto/'/>.</para></listitem>
             <listitem><para><emphasis>Nightly Builds:</emphasis> These releases are available at
-                <ulink url='http://autobuilder.yoctoproject.org/'/>.  
+                <ulink url='http://autobuilder.yoctoproject.org/nightly'/>.  
                 These builds include Yocto Project releases, meta-toolchain tarballs, and 
                 experimental builds.</para></listitem>
             <listitem><para><emphasis>Yocto Project Website:</emphasis> You can find releases
@@ -125,9 +133,9 @@
         You can get these files by downloading a Yocto Project release tarball and unpacking it,  
         or by establishing a Git repository of the files.
         For information on both these methods, see
-        <ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html#getting-setup'>
+        <ulink url='http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#getting-setup'>
         Getting Setup</ulink> section in  
-        <ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html'>
+        <ulink url='http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html'>
         The Yocto Project Development Manual</ulink>.
     </para>
 </section>

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

@@ -26,7 +26,7 @@
                 <email>richard.purdie@linuxfoundation.org</email>
             </author>
 
-            <author>
+<!--            <author>
                 <firstname>Tomas</firstname> <surname>Frydrych</surname>
                 <affiliation>
                     <orgname>Intel Corporation</orgname>
@@ -38,24 +38,29 @@
             </author>
             <author>
                 <firstname>Dodji</firstname> <surname>Seketeli</surname>
-            </author>
+            </author> -->
         </authorgroup>
 
         <revhistory>
             <revision>
                 <revnumber>4.0+git</revnumber>
                 <date>24 November 2010</date>
-                <revremark>Poky Master Documentation</revremark>
+                <revremark>Released with the Yocto Project 0.9 Release</revremark>
             </revision>
             <revision>
-                <revnumber>5.0+git</revnumber>
+                <revnumber>1.0</revnumber>
                 <date>6 April 2011</date>
-                <revremark>Released with Yocto Project 1.0 (Bernard 5.0).</revremark>
+                <revremark>Released with the Yocto Project 1.0 Release.</revremark>
             </revision>
             <revision>
                 <revnumber>1.0.1</revnumber>
                 <date>23 May 2011</date>
-                <revremark>Released with Yocto Project 1.0.1 on 23 May 2011.</revremark>
+                <revremark>Released with the Yocto Project 1.0.1 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.1</revnumber>
+                <date>6 October 2011</date>
+                <revremark>Released with the Yocto Project 1.1 Release.</revremark>
             </revision>
         </revhistory>
 
@@ -72,7 +77,7 @@
       <note>
           Due to production processes, there could be differences between the Yocto Project
           documentation bundled in the release tarball and 
-          <ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html'>
+          <ulink url='http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html'>
           The Yocto Project Reference Manual</ulink> on
           the <ulink url='http://www.yoctoproject.org'>Yocto Project</ulink> website.
           For the latest version of this manual, see the manual on the website.
@@ -87,6 +92,8 @@
 
     <xi:include href="extendpoky.xml"/>
 
+    <xi:include href="technical-details.xml"/>
+
     <xi:include href="../bsp-guide/bsp.xml"/>
 
     <xi:include href="development.xml"/>

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

@@ -122,7 +122,7 @@
             <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 glibc and the toolchain.
+            These packages in turn depend on <filename>eglibc</filename> and the toolchain.
         </para>
 
         <para>
@@ -207,9 +207,9 @@
             It is worth noting that you can greatly speed up the build time by properly setting 
             the <filename>BB_NUMBER_THREADS</filename> variable.  
             See the
-            <ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#building-image'>
+            <ulink url='http://www.yoctoproject.org/docs/latest/yocto-project-qs/yocto-project-qs.html#building-image'>
             Building an Image</ulink> section in the 
-            <ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html'>
+            <ulink url='http://www.yoctoproject.org/docs/latest/yocto-project-qs/yocto-project-qs.html'>
             Yocto Project Quick Start</ulink> for more information.
         </para>
 
@@ -260,8 +260,50 @@
         <para>
             Once all the tasks have been completed BitBake exits.
         </para> 
-    </section>
 
+        <para>
+            When running a task, BitBake tightly controls the execution environment 
+            of the build tasks to make sure unwanted contamination from the build machine
+            cannot influence the build. 
+            Consequently, if you do want something to get passed into the build 
+            task's environment, you must take a few steps:
+            <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>
+                    variable.
+                    For example, assume you want to prevent the build system from 
+                    accessing your <filename>$HOME/.ccache</filename> directory.
+                    The following command tells BitBake to load 
+                    <filename>CCACHE_DIR</filename> from the environment into the data
+                    store:
+                    <literallayout class='monospaced'>
+     export BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE CCACHE_DIR" 
+                    </literallayout></para></listitem>
+                <listitem><para>Tell BitBake to export what you have loaded into the 
+                    environment store to the task environment of every running task.
+                    Loading something from the environment into the data store
+                    (previous step) only makes it available in the datastore. 
+                    To export it to the task environment of every running task,
+                    use a command similar to the following in your 
+                    <filename>local.conf</filename> or distro configuration file:
+                    <literallayout class='monospaced'>
+     export CCACHE_DIR
+                    </literallayout></para></listitem>
+            </orderedlist>
+        </para>
+
+        <note>
+            A side effect of the previous steps is that BitBake records the variable
+            as a dependency of the build process in things like the shared state
+            checksums. 
+            If doing so results in unnecessary rebuilds of tasks, you can whitelist the 
+            variable so that the shared state code ignores the dependency when it creates
+            checksums.
+            For information on this process, see the <filename>BB_HASHBASE_WHITELIST</filename>
+            example in <xref linkend='checksums'>Checksums (Signatures)</xref>.
+        </note>
+    </section>
 
     <section id='ref-bitbake-commandline'>
         <title>BitBake Command Line</title>

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

@@ -139,7 +139,7 @@
     </para>
 
     <para>
-        During staging, Bitbake installs such scripts into the 
+        During staging, BitBake installs such scripts into the
         <filename>sysroots/</filename> directory. 
         BitBake also changes all paths to point into the <filename>sysroots/</filename>
         directory so all builds that use the script will use the correct 
@@ -152,8 +152,8 @@
 
     <para>
         This class renames packages so that they follow the Debian naming
-        policy (i.e. <filename>glibc</filename> becomes <filename>libc6</filename>
-        and <filename>glibc-devel</filename> becomes <filename>libc6-dev</filename>.
+        policy (i.e. <filename>eglibc</filename> becomes <filename>libc6</filename>
+        and <filename>eglibc-devel</filename> becomes <filename>libc6-dev</filename>.
     </para>
 </section>
 
@@ -166,7 +166,7 @@
     </para>
 
     <para>
-        During staging, Bitbake installs <filename>pkg-config</filename> data into the 
+        During staging, BitBake installs <filename>pkg-config</filename> data into the
         <filename>sysroots/</filename> directory. 
         By making use of sysroot functionality within <filename>pkg-config</filename>,
         this class no longer has to manipulate the files.
@@ -387,10 +387,91 @@
     <para>
         This class adds a step to the package generation process that sanity checks the
         packages generated by the Yocto Project.
-        An ever-increasing range of checks are performed that check for 
-        common problems that break builds.
+        A range of checks are performed that check the build's output
+        for common problems that show up during runtime.
         Distribution policy usually dictates whether to include this class as the Yocto Project does.
     </para>
+
+    <para>
+        You can configure the sanity checks so that specific test failures either raise a warning or 
+        an error message.  
+        Typically, failures for new tests generate a warning.
+        Subsequent failures for the same test would then generate an error message 
+        once the metadata is in a known and good condition.
+        You use the <filename>WARN_QA</filename> variable to specify tests for which you 
+        want to generate a warning message on failure.
+        You use the <filename>ERROR_QA</filename> variable to specify tests for which you 
+        want to generate an error message on failure.
+    </para>
+
+    <para>
+        The following list shows the tests you can list with the <filename>WARN_QA</filename>
+        and <filename>ERROR_QA</filename> variables:
+        <itemizedlist>
+            <listitem><para><emphasis><filename>ldflags:</filename></emphasis>
+                Ensures that the binaries were linked with the 
+                <filename>LDFLAGS</filename> options provided by the build system. 
+                If this test fails, check that the <filename>LDFLAGS</filename> variable
+                is being passed to the linker command.</para></listitem>
+            <listitem><para><emphasis><filename>useless-rpaths:</filename></emphasis>
+                Checks for dynamic library load paths (rpaths) in the binaries that 
+                by default on a standard system are searched by the linker (e.g.
+                <filename>/lib</filename> and <filename>/usr/lib</filename>). 
+                While these paths will not cause any breakage, they do waste space and 
+                are unnecessary.</para></listitem>
+            <listitem><para><emphasis><filename>rpaths:</filename></emphasis>
+                Checks for rpaths in the binaries that contain build system paths such
+                as <filename>TMPDIR</filename>.
+                If this test fails, bad <filename>-rpath</filename> options are being 
+                passed to the linker commands and your binaries have potential security 
+                issues.</para></listitem>
+            <listitem><para><emphasis><filename>dev-so:</filename></emphasis>
+                Checks that the <filename>.so</filename> symbolic links are in the 
+                <filename>-dev</filename> package and not in any of the other packages. 
+                In general, these symlinks are only useful for development purposes.
+                Thus, the <filename>-dev</filename> package is the correct location for
+                them. 
+                Some very rare cases do exist for dynamically loaded modules where 
+                these symlinks are needed instead in the main package.
+                </para></listitem>
+            <listitem><para><emphasis><filename>debug-files:</filename></emphasis>
+                Checks for <filename>.debug</filename> directories in anything but the 
+                <filename>-dbg</filename> package. 
+                The debug files should all be in the <filename>-dbg</filename> package.
+                Thus, anything packaged elsewhere is incorrect packaging.</para></listitem>
+            <listitem><para><emphasis><filename>arch:</filename></emphasis>
+                Checks the Executable and Linkable Format (ELF) type, bit size and endianness 
+                of any binaries to ensure it matches the target architecture. 
+                This test fails if any binaries don't match the type since there would be an 
+                incompatibility. 
+                Sometimes software, like bootloaders, might need to bypass this check.
+                </para></listitem>
+            <listitem><para><emphasis><filename>debug-deps:</filename></emphasis>
+                Checks that <filename>-dbg</filename> packages only depend on other
+                <filename>-dbg</filename> packages and not on any other types of packages,
+                which would cause a packaging bug.</para></listitem>
+            <listitem><para><emphasis><filename>dev-deps:</filename></emphasis>
+                Checks that <filename>-dev</filename> packages only depend on other 
+                <filename>-dev</filename> packages and not on any other types of packages,
+                which would be a packaging bug.</para></listitem>
+            <listitem><para><emphasis><filename>pkgconfig:</filename></emphasis>
+                Checks <filename>.pc</filename> files for any 
+                <filename>TMPDIR/WORKDIR</filename> paths. 
+                Any <filename>.pc</filename> file containing these paths is incorrect 
+                since <filename>pkg-config</filename> itself adds the correct sysroot prefix 
+                when the files are accessed.</para></listitem>
+            <listitem><para><emphasis><filename>la:</filename></emphasis>
+                Checks <filename>.la</filename> files for any <filename>TMPDIR</filename>
+                paths. 
+                Any <filename>.la</filename> file continaing these paths is incorrect since 
+                <filename>libtool</filename> adds the correct sysroot prefix when using the 
+                files automatically itself.</para></listitem>
+            <listitem><para><emphasis><filename>desktop:</filename></emphasis>
+                Runs the <filename>desktop-file-validate</filename> program against any 
+                <filename>.desktop</filename> files to validate their contents against 
+                the specification for <filename>.desktop</filename> files.</para></listitem>
+        </itemizedlist>
+    </para>
 </section>
 
 <section id='ref-classes-siteinfo'>
@@ -403,7 +484,7 @@
         still make the correct values available.
         The <filename><link linkend='structure-meta-site'>meta/site directory</link></filename>
         contains test results sorted into different categories such as architecture, endianness, and
-        the libc used. 
+        the <filename>libc</filename> used. 
         Site information provides a list of files containing data relevant to 
         the current build in the 
         <filename><link linkend='var-CONFIG_SITE'>CONFIG_SITE</link></filename> variable 
@@ -422,6 +503,21 @@
     </para>
 </section>
 
+<section id='ref-classes-useradd'>
+    <title>Adding Users - <filename>useradd.bbclass</filename></title>
+
+    <para>
+        If you have packages that install files that are owned by custom users or groups, 
+        you can use this class to specify those packages and associate the users and groups
+        with those packages.
+        The <filename>meta-skeleton/recipes-skeleton/useradd/useradd-example.bb</filename> 
+        recipe in the Yocto Project Files provides a simple exmample that shows how to add three 
+        users and groups to two packages.
+        See the <filename>useradd-example.bb</filename> for more information on how to 
+        use this class.
+    </para>
+</section>
+
 <section id='ref-classes-others'>
     <title>Other Classes</title>
 
@@ -436,44 +532,71 @@
 </section>
 
 <!-- Undocumented classes are:
-        base_srpm.bbclass
+        allarch.bbclass
+        binconfig.bbclass
         bootimg.bbclass
+        buildstats.bbclass
         ccache.inc
-        ccdv.bbclass
         cmake.bbclass
         cml1.bbclass
         cross.bbclass
-        flow-lossage.bbclass
+        cross-canadian.bbclass
+        deploy.bbclass
+        distrodata.bbclass
         gconf.bbclass
         gettext.bbclass
         gnome.bbclass
+        gtk-doc.bbclass
         gtk-icon-cache.bbclass
         icecc.bbclass
+        image-mklibs.bbclass
+        image-prelink.bbclass
+        image-swab.bbclass
+        imagetest-dummy.bbclass
+        imagetest-qemu.bbclass
+        insserv.bbclass
         lib_package.bbclass
+        license.bbclass
+        logging.bbclass
+        meta.bbclass
+        metadata_scm.bbclass
         mirrors.bbclass
-        mozilla.bbclass
-        multimachine.bbclass
+        multilib*.bbclass
         native.bbclass
+        nativesdk.bbclass
         oelint.bbclass
+        own-mirrors.bbclass
+        packagedata.bbclass
+        packagehistory.bbclass
         patch.bbclass
-        patcher.bbclass
+        perlnative.bbclass
         pkg_distribute.bbclass
         pkg_metainfo.bbclass
-        poky.bbclass
+        populate_sdk*.bbclass
+        prserv.bbclass
+        python-dir.bbclass
+        qemu.bbclass
+        qmake*.bbclass
+        qt4*.bbclass
+        recipe_sanity.bbclass
+        relocatable.bbclass
         rm_work.bbclass
-        rpm_core.bbclass
         scons.bbclass
-        sdk.bbclass
         sdl.bbclass
+        setuptools.bbclass
         sip.bbclass
+        siteconfig.bbclass
         sourcepkg.bbclass
-        srec.bbclass
+        sstate.bbclass
+        staging.bbclass
         syslinux.bbclass
+        task.bbclass
+        terminal.bbclass
         tinderclient.bbclass
-        tmake.bbclass
+        toolchain-scripts.bbclass
+        typecheck.bbclass
+        utility-tasks.bbclass
         utils.bbclass
-        xfce.bbclass
-        xlibs.bbclass
 -->
 
 

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

@@ -14,9 +14,9 @@
 
 <para>
     For information on how to establish the Yocto Project files on your local development system, see the
-    <ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html#getting-started'> 
+    <ulink url='http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#getting-started'> 
     Getting Setup</ulink> section in the 
-    <ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html'>
+    <ulink url='http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html'>
     The Yocto Project Development Manual</ulink>.
 </para>
 

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

@@ -16,7 +16,7 @@
 
     <para>
        <link linkend='var-AUTHOR'>A</link> 
-       <link linkend='var-BB_NUMBER_THREADS'>B</link> 
+       <link linkend='var-BAD_RECOMMENDATIONS'>B</link> 
        <link linkend='var-CFLAGS'>C</link> 
        <link linkend='var-D'>D</link> 
        <link linkend='var-ENABLE_BINARY_LOCALE_GENERATION'>E</link> 
@@ -25,7 +25,7 @@
        <link linkend='var-HOMEPAGE'>H</link> 
        <link linkend='var-IMAGE_FEATURES'>I</link> 
 <!--               <link linkend='var-glossary-j'>J</link> -->
-       <link linkend='var-KERNEL_IMAGETYPE'>K</link>
+       <link linkend='var-KERNEL_FEATURES'>K</link>
        <link linkend='var-LAYERDIR'>L</link> 
        <link linkend='var-MACHINE'>M</link> 
 <!--               <link linkend='var-glossary-n'>N</link> -->
@@ -64,6 +64,14 @@
 
     <glossdiv id='var-glossary-b'><title>B</title>
 
+        <glossentry id='var-BAD_RECOMMENDATIONS'><glossterm>BAD_RECOMMENDATIONS</glossterm>
+            <glossdef>
+                <para>A list of packages not to install despite being recommended by a recipe.
+                    Support for this variable exists only for images that use the 
+                    <filename>ipkg</filename> packaging system.</para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-BB_NUMBER_THREADS'><glossterm>BB_NUMBER_THREADS</glossterm>
             <glossdef>
                 <para>The maximum number of tasks BitBake should run in parallel at any one time.
@@ -320,7 +328,7 @@
 
         <glossentry id='var-ENABLE_BINARY_LOCALE_GENERATION'><glossterm>ENABLE_BINARY_LOCALE_GENERATION</glossterm>
             <glossdef>
-                <para>Variable that controls which locales for <filename>glibc</filename> are
+                <para>Variable that controls which locales for <filename>eglibc</filename> are
                     to be generated during the build (useful if the target device has 64Mbytes
                     of RAM or less).</para>
             </glossdef>
@@ -337,38 +345,59 @@
                     You can use this variable to add more features in addition to those.
                     Here are some examples of features you can add:</para>
                     <literallayout class='monospaced'>
-     "dbg-pkgs" - Adds -dbg packages for all installed packages
-                  including symbol information for debugging and 
-                  profiling.
+"dbg-pkgs" - Adds -dbg packages for all installed packages
+             including symbol information for debugging and 
+             profiling.
 
-     "dev-pkgs" - Adds -dev packages for all installed packages.  
-                  This is useful if you want to develop against 
-                  the libraries in the image.
+"dev-pkgs" - Adds -dev packages for all installed packages.  
+             This is useful if you want to develop against 
+             the libraries in the image.
 
-     "tools-sdk" - Adds development tools such as gcc, make, 
-                   pkgconfig and so forth.
+"tools-sdk" - Adds development tools such as gcc, make, 
+              pkgconfig and so forth.
 
-     "tools-debug" - Adds debugging tools such as gdb and 
-                     strace.
+"tools-debug" - Adds debugging tools such as gdb and 
+                strace.
 
-     "tools-profile" - Adds profiling tools such as oprofile, 
-                       exmap, lttng and valgrind (x86 only).
+"tools-profile" - Adds profiling tools such as oprofile, 
+                  exmap, lttng and valgrind (x86 only).
 
-     "tools-testapps" - Adds useful testing tools such as 
-                        ts_print, aplay, arecord and so 
-                        forth.
+"tools-testapps" - Adds useful testing tools such as 
+                   ts_print, aplay, arecord and so 
+                   forth.
 
-     "debug-tweaks" - Makes an image suitable for development.  
-                      For example, ssh root access has a blank 
-                      password.  There are other application 
-                      targets too, see 
-                      meta/classes/poky-image.bbclass
-                      and meta/packages/tasks/task-poky.bb 
-                      for more details.
+"debug-tweaks" - Makes an image suitable for development.  
+                 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> 
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-EXTRA_IMAGEDEPENDS'><glossterm>EXTRA_IMAGEDEPENDS</glossterm>
+            <glossdef>
+                <para>A list of recipes to be built that do not provide packages to be installed in
+                    the root filesystem.
+                </para>
+                <para>Sometimes a recipe is required to build the final image but is not
+                    needed in the root filesystem.
+                    You can use the <filename>EXTRA_IMAGEDEPENDS</filename> variable to 
+                    list these recipes and thus, specify the dependencies. 
+                    A typical example is a required bootloader in a machine configuration.
+                </para>
+                <note>
+                    To add packages to the root filesystem, see the various 
+                    <filename>*DEPENDS</filename> and <filename>*RECOMMENDS</filename>
+                    variables.
+                </note>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-EXTRA_OECMAKE'><glossterm>EXTRA_OECMAKE</glossterm>
             <glossdef>
                 <para>Additional <filename>cmake</filename> options.</para>
@@ -397,6 +426,37 @@
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-FILESYSTEM_PERMS_TABLES'><glossterm>FILESYSTEM_PERMS_TABLES</glossterm>
+            <glossdef>
+                <para>Allows you to define your own file permissions settings table as part of
+                    your configuration for the packaging process.
+                    For example, suppose you need a consistent set of custom permissions for 
+                    a set of groups and users across an entire work project.
+                    It is best to do this in the packages themselves but this is not always 
+                    possible.
+                </para>
+                <para>
+                    By default, the Yocto Project uses the <filename>fs-perms.txt</filename>, which
+                    is located in the <filename>meta/files</filename> directory of the Yocto Project
+                    files directory.
+                    If you create your own file permissions setting table, you should place it in your
+                    layer or the distros layer. 
+                </para>
+                <para>
+                    You define the <filename>FILESYSTEM_PERMS_TABLES</filename> variable in the 
+                    <filename>conf/local.conf</filename> file, which is found in the Yocto Project's 
+                    build directory, to point to your custom <filename>fs-perms.txt</filename>.
+                    You can specify more than a single file permissions setting table.
+                    The paths you specify to these files must be defined within the 
+                    <filename>BBPATH</filename> variable.  
+                </para>
+                <para>
+                    For guidance on how to create your own file permissions settings table file, 
+                    examine the existing <filename>fs-perms.txt</filename>.
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-FULL_OPTIMIZATION'><glossterm>FULL_OPTIMIZATION</glossterm>
             <glossdef>
                 <para>
@@ -450,6 +510,87 @@
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-IMAGE_OVERHEAD_FACTOR'><glossterm>IMAGE_OVERHEAD_FACTOR</glossterm>
+            <glossdef>
+                <para>
+                    Defines a multiplier that the build system might apply to the initial image
+                    size to create free disk space in the image as overhead.
+                    By default, the build process uses a multiplier of 1.3 for this variable. 
+                    This default value results in 30% free disk space added to the image when this 
+                    method is used to determine the final generated image size. 
+                    See <filename><link linkend='var-IMAGE_ROOTFS_SIZE'>IMAGE_ROOTFS_SIZE</link></filename>
+                    for information on how the build system determines the overall image size.
+                </para>
+
+                <para>
+                    The default 30% free disk space typically gives the image enough room to boot 
+                    and allows for basic post installs while still leaving a small amount of 
+                    free disk space. 
+                    If 30% free space is inadequate, you can increase the default value.
+                    For example, the following setting gives you 50% free space added to the image:
+                    <literallayout class='monospaced'>
+     IMAGE_OVERHEAD_FACTOR = "1.5"
+                    </literallayout>
+                </para>
+
+                <para>
+                    Alternatively, you can ensure a specific amount of free disk space is added
+                    to the image by using     
+                    <filename><link linkend='var-IMAGE_ROOTFS_EXTRA_SPACE'>IMAGE_ROOTFS_EXTRA_SPACE</link></filename>
+                    the variable.
+                </para>
+            </glossdef>
+        </glossentry> 
+
+        <glossentry id='var-IMAGE_ROOTFS_EXTRA_SPACE'><glossterm>IMAGE_ROOTFS_EXTRA_SPACE</glossterm>
+            <glossdef>
+                <para>
+                    Defines additional free disk space created in the image in Kbytes.
+                    By default, this variable is set to "0".
+                    This free disk space is added to the image after the build system determines
+                    the image size as described in 
+                    <filename><link linkend='var-IMAGE_ROOTFS_SIZE'>IMAGE_ROOTFS_SIZE</link></filename>.
+                </para>
+
+                <para>
+                    This variable is particularly useful when you want to ensure that a 
+                    specific amount of free disk space is available on a device after an image 
+                    is installed and running. 
+                    For example, to be sure 5 Gbytes of free disk space is available, set the 
+                    variable as follows:
+                    <literallayout class='monospaced'>
+     IMAGE_ROOTFS_EXTRA_SPACE = "5242880"
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry> 
+
+        <glossentry id='var-IMAGE_ROOTFS_SIZE'><glossterm>IMAGE_ROOTFS_SIZE</glossterm>
+            <glossdef>
+                <para>
+                    Defines the size in Kbytes for the generated image.
+                    The Yocto Project build system determines the final size for the generated 
+                    image using an algorithm that takes into account the initial disk space used
+                    for the generated image, a requested size for the image, and requested 
+                    additional free disk space to be added to the image.
+                    Programatically, the build system determines the final size of the 
+                    generated image as follows:
+                    <literallayout class='monospaced'>
+    if (du * overhead) &lt; IMAGE_ROOTFS_SIZE:
+	IMAGE_ROOTFS_SIZE = IMAGE_ROOTFS_SIZE + xspace
+    else:
+	IMAGE_ROOTFS_SIZE = (du * overhead) + xspace
+                    </literallayout>
+                    In the above example, <filename>overhead</filename> is defined by the 
+                    <filename><link linkend='var-IMAGE_OVERHEAD_FACTOR'>IMAGE_OVERHEAD_FACTOR</link></filename>
+                    variable, <filename>xspace</filename> is defined by the 
+                    <filename><link linkend='var-IMAGE_ROOTFS_EXTRA_SPACE'>IMAGE_ROOTFS_EXTRA_SPACE</link></filename>
+                    variable, and <filename>du</filename> is the results of the disk usage command 
+                    on the initially generated image.                    
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-INC_PR'><glossterm>INC_PR</glossterm>
             <glossdef>
                 <para>Defines the Package revision.  
@@ -539,6 +680,34 @@
 
    <glossdiv id='var-glossary-k'><title>K</title>
 
+        <glossentry id='var-KERNEL_FEATURES'><glossterm>KERNEL_FEATURES</glossterm>
+            <glossdef>
+                <para>Includes additional metadata from the Linux Yocto kernel Git repository.
+                    In the Yocto Project build system, the default Board Support Packages (BSPs)
+                    metadata is provided through 
+                    the <filename>KMACHINE</filename> and <filename>KBRANCH</filename> variables.
+                    You can use the <filename>KERNEL_FEATURES</filename> variable to further 
+                    add metadata for all BSPs.</para>
+                <para>The metadata you add through this variable includes config fragments and 
+                    features descriptions,
+                    which usually includes patches as well as config fragments.
+                    You typically override the <filename>KERNEL_FEATURES</filename> variable
+                    for a specific machine.
+                    In this way, you can provide validated, but optional, sets of kernel
+                    configurations and features.</para>
+                <para>For example, the following adds <filename>netfilter</filename> to all 
+                    the Linux Yocto kernels and adds sound support to the <filename>qemux86</filename>
+                    machine:
+                    <literallayout class='monospaced'>
+     # Add netfilter to all linux-yocto kernels
+     KERNEL_FEATURES="features/netfilter"
+
+     # Add sound support to the qemux86 machine
+     KERNEL_FEATURES_append_qemux86="cfg/sound"
+                    </literallayout></para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-KERNEL_IMAGETYPE'><glossterm>KERNEL_IMAGETYPE</glossterm>
             <glossdef>
                 <para>The type of kernel to build for a device, usually set by the 
@@ -589,12 +758,6 @@
             </glossdef>
         </glossentry>
 
-        <glossentry id='var-LICENSE'><glossterm>LICENSE</glossterm>
-            <glossdef>
-                <para>The list of package source licenses.</para>
-            </glossdef>
-        </glossentry>
-
         <glossentry id='var-LIC_FILES_CHKSUM'><glossterm>LIC_FILES_CHKSUM</glossterm>
             <glossdef>
                 <para>Checksums of the license text in the recipe source code.</para>
@@ -612,6 +775,25 @@
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-LICENSE'><glossterm>LICENSE</glossterm>
+            <glossdef>
+                <para>The list of package source licenses.</para>
+            </glossdef>
+        </glossentry>
+
+        <glossentry id='var-LICENSE_DIR'><glossterm>LICENSE_DIR</glossterm>
+            <glossdef>
+                <para>Path to additional licenses used during the build.
+                    By default, the Yocto Project uses <filename>COMMON_LICENSE_DIR</filename>  
+                    to define the directory that holds common license text used during the build. 
+                    The <filename>LICENSE_DIR</filename> variable allows you to extend that
+                    location to other areas that have additional licenses: 
+                    <literallayout class='monospaced'>
+  LICENSE_DIR += "/path/to/additional/common/licenses"
+                    </literallayout></para>
+            </glossdef>
+        </glossentry>
+
     </glossdiv>
 
     <glossdiv id='var-glossary-m'><title>M</title>
@@ -622,29 +804,152 @@
             </glossdef>
          </glossentry>
 
-         <glossentry id='var-MACHINE_ESSENTIAL_RDEPENDS'><glossterm>MACHINE_ESSENTIAL_RDEPENDS</glossterm>
+         <glossentry id='var-MACHINE_ESSENTIAL_EXTRA_RDEPENDS'><glossterm>MACHINE_ESSENTIAL_EXTRA_RDEPENDS</glossterm>
             <glossdef>
-                <para>Specifies the list of packages required to boot the device.</para>
+                <para>
+                    A list of required packages to install as part of the package being
+                    built.
+                    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>,
+                    including the <filename>core-image-minimal</filename> image.
+                </para>
+                <para>
+                    This variable is similar to the 
+                    <link linkend='var-MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS'>MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS</link>
+                    variable with the exception that the package being built has a build 
+                    dependency on the variable's list of packages.
+                    In other words, the image will not build if a file in this list is not found.
+                </para>
+                <para>
+                    For example, suppose you are building a runtime package that depends
+                    on a certain disk driver.
+                    In this case, you would use the following:
+                    <literallayout class='monospaced'>
+     MACHINE_ESSENTIAL_EXTRA_RDEPENDS += "&lt;disk_driver&gt;"
+                    </literallayout>
+                </para>
             </glossdef>
          </glossentry>
 
-         <glossentry id='var-MACHINE_ESSENTIAL_RRECOMMENDS'><glossterm>MACHINE_ESSENTIAL_RRECOMMENDS</glossterm>
+         <glossentry id='var-MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS'><glossterm>MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS</glossterm>
             <glossdef>
-                <para>Specifies the list of packages required to boot the device (usually
-                    additional kernel modules).</para>
+                <para>
+                    A list of recommended packages to install as part of the package being 
+                    built. 
+                    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>,
+                    including the <filename>core-image-minimal</filename> image.
+                </para>
+                <para>
+                    This variable is similar to the 
+                    <link linkend='var-MACHINE_ESSENTIAL_EXTRA_RDEPENDS'>MACHINE_ESSENTIAL_EXTRA_RDEPENDS</link>
+                    variable with the exception that the package being built does not have a build 
+                    dependency on the variable's list of packages.
+                    In other words, the image will build if a file in this list is not found.
+                    However, because this is one of the "essential" variables, the resulting image
+                    might not boot on the machine. 
+                    Or, if the machine does boot using the image, the machine might not be fully 
+                    functional.
+                </para>
+                <para>
+                    Consider an example where you have a custom kernel with a disk driver
+                    built into the kernel itself, rather than using the driver built as a module.
+                    If you include the package that has the driver module as part of 
+                    the variable's list, the 
+                    build process will not find that package.  
+                    However, because these packages are "recommends" packages, the build will 
+                    not fail due to the missing package.
+                    Not accounting for any other problems, the custom kernel would still boot the machine.
+                </para>
+                <para>
+                    Some example packages of these machine essentials are flash, screen, keyboard, mouse, 
+                    or touchscreen drivers (depending on the machine).
+                </para>
+                <para>
+                    For example, suppose you are building a runtime package that depends
+                    on a mouse driver.
+                    In this case, you would use the following:
+                    <literallayout class='monospaced'>
+     MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "&lt;mouse_driver&gt;"
+                    </literallayout>
+                </para>
             </glossdef>
         </glossentry>
 
          <glossentry id='var-MACHINE_EXTRA_RDEPENDS'><glossterm>MACHINE_EXTRA_RDEPENDS</glossterm>
             <glossdef>
-                <para>Specifies the list of packages required to use the devices</para>
+                <para>
+                    A list of optional but non-machine essential packages to install as 
+                    part of the package being built.
+                    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>core-image-minimal</filename> or <filename>core-image-basic</filename> 
+                    images.
+                </para>
+                <para>
+                    This variable is similar to the 
+                    <link linkend='var-MACHINE_EXTRA_RRECOMMENDS'>MACHINE_EXTRA_RRECOMMENDS</link>
+                    variable with the exception that the package being built has a build 
+                    dependency on the variable's list of packages.
+                    In other words, the image will not build if a file in this list is not found.
+                </para>
+                <para>
+                    An example is a machine that might or might not have a WiFi card.
+                    The package containing the WiFi support is not essential for the 
+                    machine to boot the image.
+                    If it is not there, the machine will boot but not be able to use the 
+                    WiFi functionality.
+                    However, if you include the package with the WiFi support as part of the 
+                    variable's package list, the build 
+                    process depends on finding the package.
+                    In this case, you would use the following:
+                    <literallayout class='monospaced'>
+     MACHINE_EXTRA_RDEPENDS += "&lt;wifi_driver&gt;"
+                    </literallayout>
+                </para>
             </glossdef>
          </glossentry>
 
          <glossentry id='var-MACHINE_EXTRA_RRECOMMENDS'><glossterm>MACHINE_EXTRA_RRECOMMENDS</glossterm>
             <glossdef>
-                <para>Specifies the list of packages useful to use the device (e.g.
-                    additional kernel modules)</para>
+                <para>
+                    A list of optional but non-machine essential packages to install as 
+                    part of the package being built.
+                    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>core-image-minimal</filename> or <filename>core-image-basic</filename> 
+                    images.
+                </para>
+                <para>
+                    This variable is similar to the 
+                    <link linkend='var-MACHINE_EXTRA_RDEPENDS'>MACHINE_EXTRA_RDEPENDS</link>
+                    variable with the exception that the package being built does not have a build 
+                    dependency on the variable's list of packages.
+                    In other words, the image will build if a file in this list is not found.
+                </para>
+                <para>
+                    An example is a machine that might or might not have a WiFi card.
+                    The package containing the WiFi support is not essential for the 
+                    machine to boot the image.
+                    If it is not there, the machine will boot but not be able to use the 
+                    WiFi functionality.
+                    You are free to either include or not include the 
+                    the package with the WiFi support as part of the 
+                    variable's package list, the build 
+                    process does not depend on finding the package.
+                    If you include the package, you would use the following:
+                    <literallayout class='monospaced'>
+     MACHINE_EXTRA_RRECOMMENDS += "&lt;wifi_driver&gt;"
+                    </literallayout>
+                </para>
             </glossdef>
          </glossentry>
 
@@ -735,7 +1040,7 @@
                     This variable is usually in the form <filename>-j 4</filename>, where the number
                     represents the maximum number of parallel threads make can run.
                     If you development host supports multiple cores a good rule of thumb is to set 
-                    this variable to one and a half times the number of cores on the host.</para>
+                    this variable to twice the number of cores on the host.</para>
             </glossdef>
         </glossentry>
 
@@ -781,10 +1086,18 @@
 
         <glossentry id='var-PREFERRED_PROVIDER'><glossterm>PREFERRED_PROVIDER</glossterm>
             <glossdef>
-                <para>If multiple recipes provide an item, this variable
+                <para>
+                    If multiple recipes provide an item, this variable
                     determines which recipe should be given preference. 
-                    The variable should be set to the <filename>$PN</filename> of the recipe 
-                    to which you want to give precedence.</para>
+                    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 
+                    to which you want to give precedence.
+                    Here is an example:
+                    <literallayout class='monospaced'>
+     PREFERRED_PROVIDER_virtual/xserver = "xserver-xf86"
+                    </literallayout>
+                </para>
             </glossdef>
         </glossentry>
 
@@ -793,8 +1106,18 @@
                 <para>
                     If there are multiple versions of recipes available, this
                     variable determines which recipe should be given preference.
-                    The variable should be set to the <filename>$PV</filename> of the recipe 
-                    to whichy you want to give precedence.
+                    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.
+                    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 
+                    potentially change.
+                    Here are two examples:
+                    <literallayout class='monospaced'>
+     PREFERRED_VERSION_python = "2.6.6"
+     PREFERRED_VERSION_linux-yocto = "3.0+git%" 
+                    </literallayout>
                 </para>
             </glossdef>
         </glossentry>
@@ -809,19 +1132,19 @@
 
         <glossentry id='var-POKYLIBC'><glossterm>POKYLIBC</glossterm>
             <glossdef>
-                <para>The <filename>libc</filename> implementation selector. 
-                    You can select <filename>glibc</filename>, <filename>eglibc</filename>, 
-                    or <filename>uclibc</filename>.</para>
+                <para>
+                    This variable is no longer supported and has been replaced by the
+                    <link linkend='var-TCLIBC'><filename>TCLIBC</filename></link> variable.
+                </para>
             </glossdef>
         </glossentry>
 
         <glossentry id='var-POKYMODE'><glossterm>POKYMODE</glossterm>
             <glossdef>
-                <para>The toolchain selector. 
-                    This variable has been replaced by <filename>TCMODE</filename>.
-                    The <filename>POKYMODE</filename> would select the external toolchain
-                    built from the Yocto Project or a few supported combinations of
-                    upstream GCC or CodeSourcery Labs toolchain.</para>
+                <para>
+                    This variable is no longer supported and has been replaced by the
+                    <link linkend='var-TCMODE'><filename>TCMODE</filename></link> variable.
+                </para>
             </glossdef>
         </glossentry>
 
@@ -843,18 +1166,48 @@
         <glossentry id='var-RDEPENDS'><glossterm>RDEPENDS</glossterm>
             <glossdef>
                 <para>
-                    A list of run-time dependencies for a package. 
-                    These packages need to be installed alongside the package to which
-                    they apply. 
-                    This enables the package to run correctly. 
-                    For example, consider a Perl script, which depends on the Perl package. 
-                    Since this variable applies to 
-                    output packages, there would usually be an override attached 
-                    to this variable such as <filename>RDEPENDS_${PN}-dev</filename>. 
-                    Names in this field must appear as they appear in the
+                    A list of packages that must be installed as part of a package being built.
+                    The package being built has a runtime dependency on the packages in the 
+                    variable's list.
+                    In other words, in order for the package being built to run correctly, 
+                    it depends on these listed packages.
+                    If a package in this list cannot be found during the build, the build
+                    will not complete.
+                </para>
+                <para>
+                    Because the <filename>RDEPENDS</filename> variable applies to packages 
+                    being built, you should 
+                    always attach an override to the variable to specify the particular runtime package
+                    that has the dependency.
+                    For example, suppose you are building a development package that depends
+                    on the <filename>perl</filename> package.
+                    In this case, you would use the following <filename>RDEPENDS</filename>
+                    statement:
+                    <literallayout class='monospaced'>
+     RDEPENDS_${PN}-dev += "perl"
+                    </literallayout>
+                    In the example, the package name (<filename>${PN}-dev</filename>) must 
+                    appear as it would in the 
                     <filename><link linkend='var-PACKAGES'>PACKAGES</link></filename> namespace before any 
                     renaming of the output package by classes like <filename>debian.bbclass</filename>.
                 </para>
+                <para>
+                    Some automatic handling occurs around the <filename>RDEPENDS</filename>
+                    variable:
+                    <itemizedlist>
+                        <listitem><para><emphasis><filename>shlibdeps</filename></emphasis>:  If a runtime
+                            package contains a shared library (<filename>.so</filename>), the build
+                            processes the library in order to determine other libraries to which it 
+                            is dynamically linked.  
+                            The build process adds these libraries to <filename>RDEPENDS</filename>
+                            to create the runtime package.</para></listitem>
+                        <listitem><para><emphasis><filename>pcdeps</filename></emphasis>:  If the package
+                            ships a <filename>pkg-config</filename> information file, the build process
+                            uses this file to add items to the <filename>RDEPENDS</filename>
+                            variable to create the runtime packages.
+                            </para></listitem>
+                    </itemizedlist>
+                </para>
             </glossdef>
         </glossentry>
 
@@ -866,8 +1219,37 @@
 
         <glossentry id='var-RRECOMMENDS'><glossterm>RRECOMMENDS</glossterm>
             <glossdef>
-                <para>The list of packages that extend usability of the package. 
-                    The packages are automatically installed but can be removed by user.</para>
+                <para>
+                    A list of packages that extend the usability of a package being 
+                    built.
+                    The package being built does not depend on this list of packages in 
+                    order to successfully build, but needs them for the extended usability.
+                    To specify runtime dependencies for packages, see the 
+                    <link linkend='var-RDEPENDS'>RDEPENDS</link> variable.
+                </para>
+                <para>
+                    The Yocto Project build process automatically installs the list of packages
+                    as part of the built package.
+                    However, you can remove them later if you want.
+                    If, during the build, a package from the list cannot be found, the build
+                    process continues without an error.
+                </para>
+                <para>
+                    Because the <filename>RRECOMMENDS</filename> variable applies to packages 
+                    being built, you should 
+                    always attach an override to the variable to specify the particular package
+                    whose usability is being extended.
+                    For example, suppose you are building a development package that is extended
+                    to support wireless functionality.
+                    In this case, you would use the following:
+                    <literallayout class='monospaced'>
+     RRECOMMENDS_${PN}-dev += "&lt;wireless_package_name&gt;"
+                    </literallayout>
+                    In the example, the package name (<filename>${PN}-dev</filename>) must 
+                    appear as it would in the 
+                    <filename><link linkend='var-PACKAGES'>PACKAGES</link></filename> namespace before any 
+                    renaming of the output package by classes like <filename>debian.bbclass</filename>.
+                </para>
             </glossdef>
         </glossentry>
 
@@ -1057,24 +1439,52 @@
         <glossentry id='var-TARGET_OS'><glossterm>TARGET_OS</glossterm>
             <glossdef>
                 <para>Specifies the target's operating system. 
-                    The variable can be set to "linux" for <filename>glibc</filename>-based systems and
-                    "linux-uclibc" for <filename>uClibc</filename>. 
+                    The variable can be set to "linux" for <filename>eglibc</filename>-based systems and
+                    to "linux-uclibc" for <filename>uclibc</filename>. 
                     For ARM/EABI targets, there are also "linux-gnueabi" and
                     "linux-uclibc-gnueabi" values possible.</para>
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-TCLIBC'><glossterm>TCLIBC</glossterm>
+            <glossdef>
+                <para>
+                    Specifies which variant of the GNU standard C library (<filename>libc</filename>)
+                    to use during the build process.
+                    This variable replaces <filename>POKYLIBC</filename>, which is no longer
+                    supported.
+                </para>
+                <para>
+                    You can select <filename>eglibc</filename> or <filename>uclibc</filename>.
+                    <note>
+                        This release of the Yocto Project does not support the 
+                        <filename>glibc</filename> implementation of <filename>libc</filename>.
+                    </note>
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-TCMODE'><glossterm>TCMODE</glossterm>
             <glossdef>
-                <para>The toolchain selector. 
-                    This variable replaces <filename>POKYMODE</filename>.
+                <para>
+                    The toolchain selector. 
+                    This variable replaces <filename>POKYMODE</filename>, which is no longer
+                    supported.
+                </para>
+                <para>
+                    The <filename>TCMODE</filename> variable selects the external toolchain
+                    built from the Yocto Project or a few supported combinations of
+                    the upstream GCC or CodeSourcery Labs toolchain.
                     The variable determines which of the files in 
                     <filename>meta/conf/distro/include/tcmode-*</filename> is used. 
+                </para>
+                <para>
                     By default, <filename>TCMODE</filename> is set to "default", which 
-                    chooses <filename>tcmode-default.inc</filename>.</para>
-                <para>The variable is similar to <filename>TCLIBC</filename>, which controls the 
-                    <filename>libc</filename> used: <filename>eglibc</filename> or <filename>uclibc</filename>.
-                    </para>
+                    chooses <filename>tcmode-default.inc</filename>.
+                    The variable is similar to <filename>TCLIBC</filename>, which controls 
+                    the variant of the GNU standard C library (<filename>libc</filename>)
+                    used during the build process: <filename>eglibc</filename> or <filename>uclibc</filename>.
+                </para>
             </glossdef>
         </glossentry> 
 

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

@@ -71,10 +71,10 @@
                         </link></filename></para></listitem>
                     <listitem><para><filename><link linkend='var-MACHINE_EXTRA_RRECOMMENDS'>MACHINE_EXTRA_RRECOMMENDS
                         </link></filename></para></listitem>
-                    <listitem><para><filename><link linkend='var-MACHINE_ESSENTIAL_RDEPENDS'>MACHINE_ESSENTIAL_RDEPENDS
+                    <listitem><para><filename><link linkend='var-MACHINE_ESSENTIAL_EXTRA_RDEPENDS'>MACHINE_ESSENTIAL_EXTRA_RDEPENDS
                         </link></filename></para></listitem>
-                    <listitem><para><filename><link linkend='var-MACHINE_ESSENTIAL_RRECOMMENDS'>
-                        MACHINE_ESSENTIAL_RRECOMMENDS</link></filename></para></listitem>
+                    <listitem><para><filename><link linkend='var-MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS'>
+                        MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS</link></filename></para></listitem>
                 </itemizedlist>
             </para>
         </section>

documentation/poky-ref-manual/resources.xml

@@ -10,9 +10,9 @@
         The Yocto Project team is happy for people to experiment with the Yocto Project.
         A number of places exist to find help if you run into difficulties or find bugs. 
         To find out how to download source code,
-        see the <ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html#local-yp-release'>
+        see the <ulink url='http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#local-yp-release'>
         Yocto Project Release</ulink> list item in
-        <ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html'>The Yocto 
+        <ulink url='http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html'>The Yocto 
         Project Development Manual</ulink>.
     </para>
 </section>
@@ -32,13 +32,16 @@
     <para>
         To subscribe to the Yocto Project mailing lists, click on the following URLs and follow the instructions:
         <itemizedlist>
-            <listitem><para><ulink url='http://lists.yoctoproject.org/listinfo/yocto'></ulink> for a 
-                Yocto Discussions mailing list.</para></listitem>
-            <listitem><para><ulink url='http://lists.yoctoproject.org/listinfo/poky'></ulink> for a 
-                Yocto Project Discussions mailing list.</para></listitem>
-            <listitem><para><ulink url='http://lists.yoctoproject.org/listinfo/yocto-announce'></ulink> for a 
-                mailing list to receive offical Yocto Project announcements for developments and 
-                as well as Yocto Project milestones.</para></listitem>
+            <listitem><para><emphasis>
+                <ulink url='http://lists.yoctoproject.org/listinfo/yocto-announce'></ulink></emphasis>:
+                Use this list to receive offical Yocto Project announcements for developments and 
+                to learn about Yocto Project milestones.</para></listitem>
+            <listitem><para><emphasis><ulink url='http://lists.yoctoproject.org/listinfo/yocto'></ulink></emphasis>:
+                Use this list to monitor Yocto Project development discussions, ask questions, and 
+                get help.</para></listitem>
+            <listitem><para><emphasis><ulink url='http://lists.yoctoproject.org/listinfo/poky'></ulink></emphasis>:
+                Use this list to monitor discussions about the Yocto Project build system Poky, 
+                ask questions, and get help.</para></listitem>
         </itemizedlist>
     </para>
 </section>
@@ -47,7 +50,7 @@
     <title>Internet Relay Chat (IRC)</title>
 
     <para>
-        Two IRC channels on freenode are available for Yocto Project and Poky discussions:
+        Two IRC channels on freenode are available for the Yocto Project and Poky discussions:
         <itemizedlist>
             <listitem><para><filename>#yocto</filename></para></listitem>
             <listitem><para><filename>#poky</filename></para></listitem>
@@ -73,7 +76,7 @@
                 The upstream, generic, embedded distribution the Yocto Project build system (Poky) derives
                 from and to which it contributes.</para></listitem>
             <listitem><para><emphasis><ulink url='http://developer.berlios.de/projects/bitbake/'>
-                Bitbake</ulink>:</emphasis> The tool used to process Yocto Project metadata.</para></listitem>
+                BitBake</ulink>:</emphasis> The tool used to process Yocto Project metadata.</para></listitem>
             <listitem><para><emphasis><ulink url='http://bitbake.berlios.de/manual/'>
                 BitBake User Manual</ulink>:</emphasis> A comprehensive guide to the BitBake tool.
                 </para></listitem>
@@ -90,44 +93,14 @@
     <title>Contributions</title>
 
     <para>
-        Contributions to the Yocto Project are very welcome. 
-        You should send patches to the Yocto Project mailing list along with a "signed-off-by:"
-        line in the same style as required by the Linux kernel. 
-        Adding this line signifies the developer has agreed to the Developer's Certificate of Origin 1.1
-        as follows:
-        <literallayout class='monospaced'>
-     Developer's Certificate of Origin 1.1
-
-     By making a contribution to this project, I certify that:
-
-     (a) The contribution was created in whole or in part by me and I
-         have the right to submit it under the open source license
-         indicated in the file; or
-
-     (b) The contribution is based upon previous work that, to the best
-         of my knowledge, is covered under an appropriate open source
-         license and I have the right under that license to submit that
-         work with modifications, whether created in whole or in part
-         by me, under the same open source license (unless I am
-         permitted to submit under a different license), as indicated
-         in the file; or
-
-     (c) The contribution was provided directly to me by some other
-         person who certified (a), (b) or (c) and I have not modified
-         it.
-
-     (d) I understand and agree that this project and the contribution
-         are public and that a record of the contribution (including all
-         personal information I submit with it, including my sign-off) is
-         maintained indefinitely and may be redistributed consistent with
-         this project or the open source license(s) involved.
-        </literallayout>
-        A Poky contributions tree (<filename>poky-contrib</filename>, 
-        <filename>git://git.yoctoproject.org/poky-contrib.git</filename>)
-        exists for contributors to stage contributions.
-        If people desire such access, please ask on the mailing list. 
-        Usually, the Yocto Project team will grant access to anyone with a proven track 
-        record of good patches.
+        The Yocto Project gladly accepts contributions.
+        You can submit changes to the project either by creating and sending pull requests, 
+        or by submitting patches through email.
+        For information on how to do both, see
+        <ulink url='http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#how-to-submit-a-change'>
+        How to Submit a Change</ulink> in
+        <ulink url='http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html'>
+        The Yocto Project Development Manual</ulink>.
     </para>
 </section>
 

documentation/poky-ref-manual/style.css

@@ -966,3 +966,9 @@ table {
    color: #fff;   
    text-decoration: underline;
 }
+
+.footnote {
+   font-size: small;
+   color: #333;
+}
+

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

@@ -0,0 +1,733 @@
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<chapter id='technical-details'>
+<title>Technical Details</title>
+
+    <para>
+        This chapter provides technical details for various parts of the Yocto Project. 
+        Currently, topics include Yocto Project components and shared state (sstate) cache.
+    </para>
+
+<section id='usingpoky-components'>
+    <title>Yocto Project Components</title>
+
+    <para>
+        The BitBake task executor together with various types of configuration files form the 
+        Yocto Project core.
+        This section overviews the BitBake task executor and the
+        configuration files by describing what they are used for and how they interact.
+    </para>
+    
+    <para>  
+        BitBake handles the parsing and execution of the data files. 
+        The data itself is of various types:
+    <itemizedlist>
+        <listitem><para><emphasis>Recipes:</emphasis>  Provides details about particular 
+            pieces of software</para></listitem>
+        <listitem><para><emphasis>Class Data:</emphasis>  An abstraction of common build 
+            information (e.g. how to build a Linux kernel).</para></listitem>
+        <listitem><para><emphasis>Configuration Data:</emphasis>  Defines machine-specific settings, 
+            policy decisions, etc.
+            Configuration data acts as the glue to bind everything together.</para></listitem>
+    </itemizedlist>
+        For more information on data, see the
+        <ulink url='http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#yocto-project-terms'>
+        Yocto Project Terms</ulink> section in 
+        <ulink url='http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html'>
+        The Yocto Project Development Manual</ulink>.
+    </para>
+
+    <para> 
+        BitBake knows how to combine multiple data sources together and refers to each data source
+        as a "<link linkend='usingpoky-changes-layers'>layer</link>".
+    </para>
+
+    <para>
+        Following are some brief details on these core components.
+        For more detailed information on these components see the 
+        <link linkend='ref-structure'>'Reference: Directory Structure'</link>
+        appendix.
+    </para>
+
+    <section id='usingpoky-components-bitbake'>
+        <title>BitBake</title>
+
+        <para>
+            BitBake is the tool at the heart of the Yocto Project and is responsible
+            for parsing the metadata, generating a list of tasks from it,
+            and then executing those tasks. 
+            To see a list of the options BitBake supports, use the following help command:
+            <literallayout class='monospaced'>
+     $ bitbake --help
+            </literallayout>
+        </para>
+
+        <para>
+            The most common usage for BitBake is <filename>bitbake &lt;packagename&gt;</filename>, where
+            <filename>packagename</filename> is the name of the package you want to build 
+            (referred to as the "target" in this manual). 
+            The target often equates to the first part of a <filename>.bb</filename> filename.
+            So, to run the <filename>matchbox-desktop_1.2.3.bb</filename> file, you
+            might type the following:
+            <literallayout class='monospaced'>
+     $ bitbake matchbox-desktop
+            </literallayout>
+            Several different versions of <filename>matchbox-desktop</filename> might exist.
+            BitBake chooses the one selected by the distribution configuration.
+            You can get more details about how BitBake chooses between different 
+            target versions and providers in the 
+            <link linkend='ref-bitbake-providers'>Preferences and Providers</link> section.
+        </para>
+
+        <para>
+            BitBake also tries to execute any dependent tasks first.
+            So for example, before building <filename>matchbox-desktop</filename>, BitBake
+            would build a cross compiler and <filename>eglibc</filename> if they had not already 
+            been built.
+            <note>This release of the Yocto Project does not support the <filename>glibc</filename>
+                GNU version of the Unix standard C library.  By default, the Yocto Project builds with
+                <filename>eglibc</filename>.</note>
+        </para>
+
+        <para>
+            A useful BitBake option to consider is the <filename>-k</filename> or 
+            <filename>--continue</filename> option.  
+            This option instructs BitBake to try and continue processing the job as much 
+            as possible even after encountering an error.  
+            When an error occurs, the target that
+            failed and those that depend on it cannot be remade.  
+            However, when you use this option other dependencies can still be processed.
+        </para>
+    </section>
+
+    <section id='usingpoky-components-metadata'>
+        <title>Metadata (Recipes)</title>
+
+        <para>
+            The <filename>.bb</filename> files are usually referred to as "recipes." 
+            In general, a recipe contains information about a single piece of software.
+            The information includes the location from which to download the source patches 
+            (if any are needed), which special configuration options to apply, 
+            how to compile the source files, and how to package the compiled output. 
+        </para>
+
+        <para>
+            The term "package" can also be used to describe recipes.
+            However, since the same word is used for the packaged output from the Yocto 
+            Project (i.e. <filename>.ipk</filename> or <filename>.deb</filename> files), 
+            this document avoids using the term "package" when refering to recipes.
+        </para>
+    </section>
+
+    <section id='usingpoky-components-classes'>
+        <title>Classes</title>
+
+        <para>
+            Class files (<filename>.bbclass</filename>) contain information that is useful to share
+            between metadata files. 
+            An example is the Autotools class, which contains
+            common settings for any application that Autotools uses.
+            The <link linkend='ref-classes'>Reference: Classes</link> appendix provides details
+            about common classes and how to use them.
+        </para>
+    </section>
+
+    <section id='usingpoky-components-configuration'>
+        <title>Configuration</title>
+
+        <para>
+            The configuration files (<filename>.conf</filename>) define various configuration variables
+            that govern the Yocto Project build process. 
+            These files fall into several areas that define machine configuration options, 
+            distribution configuration options, compiler tuning options, general common configuration
+            options and user configuration options (<filename>local.conf</filename>, which is found
+            in the Yocto Project files build directory).
+        </para>
+    </section>
+</section>
+
+<section id="shared-state-cache">
+    <title>Shared State Cache</title>
+
+    <para>
+        By design, the Yocto Project build system builds everything from scratch unless 
+        BitBake can determine that parts don't need to be rebuilt.
+        Fundamentally, building from scratch is attractive as it means all parts are 
+        built fresh and there is no possibility of stale data causing problems. 
+        When developers hit problems, they typically default back to building from scratch
+        so they know the state of things from the start.
+    </para>
+
+    <para>  
+        Building an image from scratch is both an advantage and a disadvantage to the process. 
+        As mentioned in the previous paragraph, building from scratch ensures that 
+        everything is current and starts from a known state.
+        However, building from scratch also takes much longer as it generally means 
+        rebuiding things that don't necessarily need rebuilt.
+    </para>
+
+    <para>
+        The Yocto Project implements shared state code that supports incremental builds.
+        The implementation of the shared state code answers the following questions that
+        were fundamental roadblocks within the Yocto Project incremental build support system:
+        <itemizedlist>
+            <listitem>What pieces of the system have changed and what pieces have not changed?</listitem>
+            <listitem>How are changed pieces of software removed and replaced?</listitem>
+            <listitem>How are pre-built components that don't need to be rebuilt from scratch
+                used when they are available?</listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        For the first question, the build system detects changes in the "inputs" to a given task by 
+        creating a checksum (or signature) of the task's inputs. 
+        If the checksum changes, the system assumes the inputs have changed and the task needs to be 
+        rerun.
+        For the second question, the shared state (sstate) code tracks which tasks add which output
+        to the build process. 
+        This means the output from a given task can be removed, upgraded or otherwise manipulated.
+        The third question is partly addressed by the solution for the second question
+        assuming the build system can fetch the sstate objects from remote locations and 
+        install them if they are deemed to be valid.
+    </para>
+
+    <para>
+        The rest of this section goes into detail about the overall incremental build
+        architecture, the checksums (signatures), shared state, and some tips and tricks.
+    </para>
+
+    <section id='overall-architecture'>
+        <title>Overall Architecture</title>
+
+        <para>
+            When determining what parts of the system need to be built, BitBake 
+            uses a per-task basis and does not use a per-recipe basis.
+            You might wonder why using a per-task basis is preferred over a per-recipe basis.
+            To help explain, consider having the IPK packaging backend enabled and then switching to DEB. 
+            In this case, <filename>do_install</filename> and <filename>do_package</filename>
+            output are still valid.
+            However, with a per-recipe approach, the build would not include the 
+            <filename>.deb</filename> files.        
+            Consequently, you would have to invalidate the whole build and rerun it. 
+            Rerunning everything is not the best situation.
+            Also in this case, the core must be "taught" much about specific tasks. 
+            This methodology does not scale well and does not allow users to easily add new tasks 
+            in layers or as external recipes without touching the packaged-staging core.
+        </para>
+    </section>
+
+    <section id='checksums'>
+        <title>Checksums (Signatures)</title>
+
+        <para>
+            The shared state code uses a checksum, which is a unique signature of a task's 
+            inputs, to determine if a task needs to be run again. 
+            Because it is a change in a task's inputs that triggers a rerun, the process
+            needs to detect all the inputs to a given task. 
+            For shell tasks, this turns out to be fairly easy because
+            the build process generates a "run" shell script for each task and 
+            it is possible to create a checksum that gives you a good idea of when 
+            the task's data changes.
+        </para>
+
+        <para>
+            To complicate the problem, there are things that should not be included in 
+            the checksum. 
+            First, there is the actual specific build path of a given task - 
+            the <filename>WORKDIR</filename>. 
+            It does not matter if the working directory changes because it should not 
+            affect the output for target packages.
+            Also, the build process has the objective of making native/cross packages relocatable. 
+            The checksum therefore needs to exclude <filename>WORKDIR</filename>.
+            The simplistic approach for excluding the worknig directory is to set 
+            <filename>WORKDIR</filename> to some fixed value and create the checksum
+            for the "run" script. 
+        </para>
+
+        <para>
+            Another problem results from the "run" scripts containing functions that 
+            might or might not get called.  
+            The incremental build solution contains code that figures out dependencies 
+            between shell functions.
+            This code is used to prune the "run" scripts down to the minimum set, 
+            thereby alleviating this problem and making the "run" scripts much more 
+            readable as a bonus.
+        </para>
+
+        <para>
+            So far we have solutions for shell scripts.
+            What about python tasks?
+            The same approach applies even though these tasks are more difficult.
+            The process needs to figure out what variables a python function accesses 
+            and what functions it calls.
+            Again, the incremental build solution contains code that first figures out 
+            the variable and function dependencies, and then creates a checksum for the data 
+            used as the input to the task.
+        </para>
+
+        <para>
+            Like the <filename>WORKDIR</filename> case, situations exist where dependencies 
+            should be ignored.
+            For these cases, you can instruct the build process to ignore a dependency
+            by using a line like the following:
+            <literallayout class='monospaced'>
+     PACKAGE_ARCHS[vardepsexclude] = "MACHINE"
+            </literallayout>
+            This example ensures that the <filename>PACKAGE_ARCHS</filename> variable does not 
+            depend on the value of <filename>MACHINE</filename>, even if it does reference it.
+        </para>
+           
+        <para>
+            Equally, there are cases where we need to add dependencies BitBake is not able to find.
+            You can accomplish this by using a line like the following:
+            <literallayout class='monospaced'>
+      PACKAGE_ARCHS[vardeps] = "MACHINE"
+            </literallayout>
+            This example explicitly adds the <filename>MACHINE</filename> variable as a 
+            dependency for <filename>PACKAGE_ARCHS</filename>.
+        </para>
+
+        <para> 
+            Consider a case with inline python, for example, where BitBake is not
+            able to figure out dependencies. 
+            When running in debug mode (i.e. using <filename>-DDD</filename>), BitBake 
+            produces output when it discovers something for which it cannot figure out
+            dependencies. 
+            The Yocto Project team has currently not managed to cover those dependencies 
+            in detail and is aware of the need to fix this situation.
+        </para>
+
+        <para>
+            Thus far, this section has limited discussion to the direct inputs into a task.
+            Information based on direct inputs is referred to as the "basehash" in the code.
+            However, there is still the question of a task's indirect inputs, the things that 
+            were already built and present in the build directory. 
+            The checksum (or signature) for a particular task needs to add the hashes of all the
+            tasks on which the particular task depends. 
+            Choosing which dependencies to add is a policy decision.
+            However, the effect is to generate a master checksum that combines the 
+            basehash and the hashes of the task's dependencies.
+        </para>
+
+        <para>
+            While figuring out the dependencies and creating these checksums is good,
+            what does the Yocto Project build system do with the checksum information? 
+            The build system uses a signature handler that is responsible for 
+            processing the checksum information.
+            By default, there is a dummy "noop" signature handler enabled in BitBake.
+            This means that behaviour is unchanged from previous versions. 
+            OECore uses the "basic" signature handler through this setting in the
+            <filename>bitbake.conf</filename> file:
+            <literallayout class='monospaced'>
+     BB_SIGNATURE_HANDLER ?= "basic"
+            </literallayout>
+            Also within the BitBake configuration file, we can give BitBake
+            some extra information to help it handle this information.
+            The following statements effectively result in a list of global
+            variable dependency excludes - variables never included in 
+            any checksum:
+            <literallayout class='monospaced'>
+     BB_HASHBASE_WHITELIST ?= "TMPDIR FILE PATH PWD BB_TASKHASH BBPATH"
+     BB_HASHBASE_WHITELIST += "DL_DIR SSTATE_DIR THISDIR FILESEXTRAPATHS"
+     BB_HASHBASE_WHITELIST += "FILE_DIRNAME HOME LOGNAME SHELL TERM USER"
+     BB_HASHBASE_WHITELIST += "FILESPATH USERNAME STAGING_DIR_HOST STAGING_DIR_TARGET"
+     BB_HASHTASK_WHITELIST += "(.*-cross$|.*-native$|.*-cross-initial$| \
+         .*-cross-intermediate$|^virtual:native:.*|^virtual:nativesdk:.*)"
+            </literallayout>
+            This example is actually where <filename>WORKDIR</filename>
+            is excluded since <filename>WORKDIR</filename> is constructed as a
+            path within <filename>TMPDIR</filename>, which is on the whitelist.
+        </para>
+
+        <para>
+            The <filename>BB_HASHTASK_WHITELIST</filename> covers dependent tasks and 
+            excludes certain kinds of tasks from the dependency chains. 
+            The effect of the previous example is to isolate the native, target,
+            and cross-components.
+            So, for example, toolchain changes do not force a rebuild of the whole system.
+        </para>
+
+        <para>
+            The end result of the "basic" handler is to make some dependency and
+            hash information available to the build. 
+            This includes:
+            <literallayout class='monospaced'>
+     BB_BASEHASH_task-&lt;taskname&gt; - the base hashes for each task in the recipe
+     BB_BASEHASH_&lt;filename:taskname&gt; - the base hashes for each dependent task
+     BBHASHDEPS_&lt;filename:taskname&gt; - The task dependencies for each task
+     BB_TASKHASH - the hash of the currently running task
+            </literallayout>
+            There is also a "basichash" <filename>BB_SIGNATURE_HANDLER</filename>,
+            which is the same as the basic version but adds the task hash to the stamp files. 
+            This results in any metadata change that changes the task hash,
+            automatically causing the task to be run again. 
+            This removes the need to bump <filename>PR</filename>
+            values and changes to metadata automatically ripple across the build.
+            Currently, this behavior is not the default behavior.
+            However, it is likely that the Yocto Project team will go forward with this 
+            behavior in the future since all the functionality exists. 
+            The reason for the delay is the potential impact to the distribution feed 
+            creation as they need increasing <filename>PR</filename> fields
+            and the Yocto Project currently lacks a mechanism to automate incrementing 
+            this field.
+        </para>
+    </section>
+
+    <section id='shared-state'>
+        <title>Shared State</title>
+
+        <para>
+            Checksums and dependencies, as discussed in the previous section, solve half the 
+            problem.
+            The other part of the problem is being able to use checksum information during the build
+            and being able to reuse or rebuild specific components.
+        </para>
+
+        <para>
+            The shared state class (<filename>sstate.bbclass</filename>) 
+            is a relatively generic implementation of how to "capture" a snapshot of a given task. 
+            The idea is that the build process does not care about the source of a task's output.
+            Output could be freshly built or it could be downloaded and unpacked from
+            somewhere - the build process doesn't need to worry about its source.
+        </para>
+
+        <para>
+            There are two types of output, one is just about creating a directory
+            in <filename>WORKDIR</filename>.
+            A good example is the output of either <filename>do_install</filename> or 
+            <filename>do_package</filename>. 
+            The other type of output occurs when a set of data is merged into a shared directory 
+            tree such as the sysroot.
+        </para>
+
+        <para>
+            The Yocto Project team has tried to keep the details of the implementation hidden in 
+            <filename>sstate.bbclass</filename>. 
+            From a user's perspective, adding shared state wrapping to a task
+            is as simple as this <filename>do_deploy</filename> example taken from 
+            <filename>do_deploy.bbclass</filename>:
+            <literallayout class='monospaced'>
+     DEPLOYDIR = "${WORKDIR}/deploy-${PN}"
+     SSTATETASKS += "do_deploy"
+     do_deploy[sstate-name] = "deploy"
+     do_deploy[sstate-inputdirs] = "${DEPLOYDIR}"
+     do_deploy[sstate-outputdirs] = "${DEPLOY_DIR_IMAGE}"
+
+     python do_deploy_setscene () {
+         sstate_setscene(d)
+     }
+     addtask do_deploy_setscene
+            </literallayout>
+            In the example, we add some extra flags to the task, a name field ("deploy"), an
+            input directory where the task sends data, and the output
+            directory where the data from the task should eventually be copied. 
+            We also add a <filename>_setscene</filename> variant of the task and add the task
+            name to the <filename>SSTATETASKS</filename> list.
+        </para>
+
+        <para>
+            If you have a directory whose contents you need to preserve, you can do this with 
+            a line like the following:
+            <literallayout class='monospaced'>
+     do_package[sstate-plaindirs] = "${PKGD} ${PKGDEST}"
+            </literallayout>
+            This method, as well as the following example, also works for mutliple directories.
+            <literallayout class='monospaced'>
+     do_package[sstate-inputdirs] = "${PKGDESTWORK} ${SHLIBSWORKDIR}"
+     do_package[sstate-outputdirs] = "${PKGDATA_DIR} ${SHLIBSDIR}"
+     do_package[sstate-lockfile] = "${PACKAGELOCK}"
+            </literallayout>
+            These methods also include the ability to take a lockfile when manipulating
+            shared state directory structures since some cases are sensitive to file
+            additions or removals.
+        </para>
+
+        <para>
+            Behind the scenes, the shared state code works by looking in 
+            <filename>SSTATE_DIR</filename> and  
+            <filename>SSTATE_MIRRORS</filename> for shared state files. 
+            Here is an example:
+            <literallayout class='monospaced'>
+     SSTATE_MIRRORS ?= "\
+     file://.* http://someserver.tld/share/sstate/ \n \
+     file://.* file:///some/local/dir/sstate/"
+            </literallayout>
+        </para>
+
+        <para>
+            The shared state package validity can be detected just by looking at the
+            filename since the filename contains the task checksum (or signature) as
+            described earlier in this section. 
+            If a valid shared state package is found, the build process downloads it 
+            and uses it to accelerate the task.
+        </para>
+
+        <para>
+            The build processes uses the <filename>*_setscene</filename> tasks
+            for the task acceleration phase.
+            BitBake goes through this phase before the main execution code and tries
+            to accelerate any tasks for which it can find shared state packages. 
+            If a shared state package for a task is available, the shared state
+            package is used.
+            This means the task and any tasks on which it is dependent are not 
+            executed.
+        </para>
+
+        <para>
+            As a real world example, the aim is when building an IPK-based image,
+            only the <filename>do_package_write_ipk</filename> tasks would have their 
+            shared state packages fetched and extracted. 
+            Since the sysroot is not used, it would never get extracted. 
+            This is another reason why a task-based approach is preferred over a 
+            recipe-based approach, which would have to install the output from every task.
+        </para>
+    </section>
+
+    <section id='tips-and-tricks'>
+        <title>Tips and Tricks</title>
+
+        <para>
+            The code in the Yocto Project that supports incremental builds is not 
+            simple code.
+            This section presents some tips and tricks that help you work around 
+            issues related to shared state code.
+        </para>
+
+        <section id='debugging'>
+            <title>Debugging</title>
+
+            <para>
+                When things go wrong, debugging needs to be straightforward. 
+                Because of this, the Yocto Project team included strong debugging
+                tools:
+                <itemizedlist>
+                    <listitem><para>Whenever a shared state package is written out, so is a
+                        corresponding <filename>.siginfo</filename> file. 
+                        This practice results in a pickled python database of all
+                        the metadata that went into creating the hash for a given shared state
+                        package.</para></listitem>
+                    <listitem><para>If BitBake is run with the <filename>--dump-signatures</filename>
+                        (or <filename>-S</filename>) option, BitBake dumps out 
+                        <filename>.siginfo</filename> files in
+                        the stamp directory for every task it would have executed instead of
+                        building the specified target package.</para></listitem>
+                    <listitem><para>There is a <filename>bitbake-diffsigs</filename> command that
+                        can process these <filename>.siginfo</filename> files. 
+                        If one file is specified, it will dump out the dependency
+                        information in the file. 
+                        If two files are specified, it will compare the two files and dump out 
+                        the differences between the two.
+                        This allows the question of "What changed between X and Y?" to be
+                        answered easily.</para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id='invalidating-shared-state'>
+            <title>Invalidating Shared State</title>
+
+            <para>
+                The shared state code uses checksums and shared state memory 
+                cache to avoid unnecessarily rebuilding tasks.
+                As with all schemes, this one has some drawbacks.
+                It is possible that you could make implicit changes that are not factored 
+                into the checksum calculation, but do affect a task's output. 
+                A good example is perhaps when a tool changes its output.
+                Let's say that the output of <filename>rpmdeps</filename> needed to change.
+                The result of the change should be that all the "package", "package_write_rpm",
+                and "package_deploy-rpm" shared state cache items would become invalid.
+                But, because this is a change that is external to the code and therefore implicit,
+                the associated shared state cache items do not become invalidated.
+                In this case, the build process would use the cached items rather than running the 
+                task again. 
+                Obviously, these types of implicit changes can cause problems.
+            </para>
+
+            <para>
+                To avoid these problems during the build, you need to understand the effects of any
+                change you make.
+                Note that any changes you make directly to a function automatically are factored into 
+                the checksum calculation and thus, will invalidate the associated area of sstate cache.
+                You need to be aware of any implicit changes that are not obvious changes to the 
+                code and could affect the output of a given task. 
+                Once you are aware of such a change, you can take steps to invalidate the cache 
+                and force the task to run. 
+                The step to take is as simple as changing a function's comments in the source code. 
+                For example, to invalidate package shared state files, change the comment statments
+                of <filename>do_package</filename> or the comments of one of the functions it calls.
+                The change is purely cosmetic, but it causes the checksum to be recalculated and  
+                forces the task to be run again.
+            </para>
+
+            <note>
+                For an example of a commit that makes a cosmetic change to invalidate 
+                a shared state, see this
+                <ulink url='http://git.yoctoproject.org/cgit.cgi/poky/commit/meta/classes/package.bbclass?id=737f8bbb4f27b4837047cb9b4fbfe01dfde36d54'>commit</ulink>.
+            </note>
+        </section>                
+    </section>
+</section>
+
+<section id="licenses">
+    <title>Licenses</title>
+
+    <para>
+        This section describes the mechanism by which the Yocto Project build system 
+        tracks changes to licensing text.
+        The section also describes how to enable commercially licensed receipes, 
+        which by default are disabled.
+    </para>
+
+    <section id="usingpoky-configuring-LIC_FILES_CHKSUM">
+        <title>Tracking License Changes</title>
+
+        <para>
+            The license of an upstream project might change in the future. In order to prevent these changes
+            going unnoticed, the Yocto Project provides a 
+            <filename><link linkend='var-LIC_FILES_CHKSUM'>LIC_FILES_CHKSUM</link></filename>
+            variable to track changes to the license text. The checksums are validated at the end of the
+            configure step, and if the checksums do not match, the build will fail.
+        </para>
+
+        <section id="usingpoky-specifying-LIC_FILES_CHKSUM">
+            <title>Specifying the <filename>LIC_FILES_CHKSUM</filename> Variable</title>
+
+            <para>
+                The <filename>LIC_FILES_CHKSUM</filename>
+                variable contains checksums of the license text in the source code for the recipe.
+                Following is an example of how to specify <filename>LIC_FILES_CHKSUM</filename>:
+                <literallayout class='monospaced'>
+     LIC_FILES_CHKSUM = "file://COPYING;md5=xxxx \
+                         file://licfile1.txt;beginline=5;endline=29;md5=yyyy \
+                         file://licfile2.txt;endline=50;md5=zzzz \
+                         ..."
+                </literallayout>
+            </para>
+
+            <para>
+                The Yocto Project uses the 
+                <filename><link linkend='var-S'>S</link></filename> variable as the 
+                default directory used when searching files listed in 
+                <filename>LIC_FILES_CHKSUM</filename>.
+                The previous example employs the default directory.
+            </para>
+
+            <para>
+                You can also use relative paths as shown in the following example: 
+                <literallayout class='monospaced'>
+     LIC_FILES_CHKSUM = "file://src/ls.c;startline=5;endline=16;\
+                                         md5=bb14ed3c4cda583abc85401304b5cd4e"
+     LIC_FILES_CHKSUM = "file://../license.html;md5=5c94767cedb5d6987c902ac850ded2c6"
+                </literallayout>
+            </para>
+
+            <para>
+                In this example, the first line locates a file in 
+                <filename><link linkend='var-S'>S</link>/src/ls.c</filename>. 
+                The second line refers to a file in 
+                <filename><link linkend='var-WORKDIR'>WORKDIR</link></filename>, which is the parent
+                of <filename>S</filename>.
+            </para>
+            <para>
+                Note that this variable is mandatory for all recipes, unless the 
+                <filename>LICENSE</filename> variable is set to "CLOSED".
+            </para>
+        </section>
+
+        <section id="usingpoky-LIC_FILES_CHKSUM-explanation-of-syntax">
+            <title>Explanation of Syntax</title>
+            <para>
+                As mentioned in the previous section, the 
+                <filename>LIC_FILES_CHKSUM</filename> variable lists all the 
+                important files that contain the license text for the source code. 
+                It is possible to specify a checksum for an entire file, or a specific section of a
+                file (specified by beginning and ending line numbers with the "beginline" and "endline"
+                parameters, respectively). 
+                The latter is useful for source files with a license notice header,
+                README documents, and so forth.
+                If you do not use the "beginline" parameter, then it is assumed that the text begins on the 
+                first line of the file. 
+                Similarly, if you do not use the "endline" parameter, it is assumed that the license text 
+                ends with the last line of the file. 
+            </para>
+
+            <para>
+                The "md5" parameter stores the md5 checksum of the license text. 
+                If the license text changes in any way as compared to this parameter
+                then a mismatch occurs.
+                This mismatch triggers a build failure and notifies the developer.
+                Notification allows the developer to review and address the license text changes.
+                Also note that if a mismatch occurs during the build, the correct md5 
+                checksum is placed in the build log and can be easily copied to the recipe.
+            </para>
+
+            <para>
+                There is no limit to how many files you can specify using the 
+                <filename>LIC_FILES_CHKSUM</filename> variable.
+                Generally, however, every project requires a few specifications for license tracking. 
+                Many projects have a "COPYING" file that stores the license information for all the source 
+                code files.
+                This practice allows you to just track the "COPYING" file as long as it is kept up to date. 
+            </para>
+
+            <tip>
+                If you specify an empty or invalid "md5" parameter, BitBake returns an md5 mis-match 
+                error and displays the correct "md5" parameter value during the build. 
+                The correct parameter is also captured in the build log. 
+            </tip>
+
+            <tip>
+                If the whole file contains only license text, you do not need to use the "beginline" and 
+                "endline" parameters. 
+            </tip>
+        </section>
+    </section>
+
+    <section id="enabling-commercially-licensed-recipes">
+        <title>Enabling Commercially Licensed Recipes</title>
+
+        <para>
+            By default, the Yocto Project build system disables components that 
+            have commercial licensing requirements.
+            The following four statements in the
+            <filename>$HOME/poky/meta/conf/distro/poky.conf</filename> file
+            disable components:
+            <literallayout class='monospaced'>
+     COMMERCIAL_LICENSE ?= "lame gst-fluendo-mp3 libmad mpeg2dec ffmpeg qmmp"
+     COMMERCIAL_AUDIO_PLUGINS ?= ""
+     COMMERCIAL_VIDEO_PLUGINS ?= ""
+     COMMERCIAL_QT ?= "qmmp"
+            </literallayout>
+        </para> 
+
+        <para>
+            If you want to enable these components, you can do so by making sure you have
+            the following statements in the configuration file:
+            <literallayout class='monospaced'>
+     COMMERCIAL_AUDIO_PLUGINS = "gst-plugins-ugly-mad \
+        gst-plugins-ugly-mpegaudioparse"
+     COMMERCIAL_VIDEO_PLUGINS = "gst-plugins-ugly-mpeg2dec \
+        gst-plugins-ugly-mpegstream gst-plugins-bad-mpegvideoparse"
+     COMMERCIAL_LICENSE = ""
+     COMMERCIAL_QT = ""
+            </literallayout>
+        </para>
+
+        <para>
+            Excluding a package name from the 
+            <filename>COMMERCIAL_LICENSE</filename> or 
+            <filename>COMMERCIAL_QT</filename> statement enables that package.  
+        </para>
+
+        <para>
+            Specifying audio and video plug-ins as part of the 
+            <filename>COMMERCIAL_AUDIO_PLUGINS</filename> and 
+            <filename>COMMERCIAL_VIDEO_PLUGINS</filename> statements includes 
+            the plug-ins into built images - thus adding support for media formats.
+        </para>
+    </section>
+</section>
+</chapter>
+<!-- 
+vim: expandtab tw=80 ts=4 
+-->

documentation/poky-ref-manual/usingpoky.xml

@@ -4,210 +4,84 @@
 <title>Using the Yocto Project</title>
 
     <para>
-        This section gives an overview of the components that make up the Yocto Project 
-        followed by information about Yocto Project builds and dealing with any
-        problems that might arise.
+        This chapter describes common usage for the Yocto Project.
+        The information is introductory in nature as other manuals in the Yocto Project
+        provide more details on how to use the Yocto Project.
     </para>
 
-<section id='usingpoky-components'>
-    <title>Yocto Project Components</title>
-
-    <para>
-        The BitBake task executor together with various types of configuration files form the 
-        Yocto Project core.
-        This section overviews the BitBake task executor and the
-        configuration files by describing what they are used for and they they interact.
-    </para>
-    
-    <para>  
-        BitBake handles the parsing and execution of the data files. 
-        The data itself is of various types:
-    <itemizedlist>
-        <listitem><para><emphasis>Recipes:</emphasis>  Provides details about particular 
-            pieces of software</para></listitem>
-        <listitem><para><emphasis>Class Data:</emphasis>  An abstraction of common build 
-            information (e.g. how to build a Linux kernel).</para></listitem>
-        <listitem><para><emphasis>Configuration Data:</emphasis>  Defines machine-specific settings, 
-            policy decisions, etc.
-            Configuration data acts a the glue to bind everything together.</para></listitem>
-    </itemizedlist>
-        For more information on data, see the
-        <ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html#yocto-project-terms'>
-        Yocto Project Terms</ulink> section in 
-        <ulink url='http://www.yoctoproject.org/docs/1.1/dev-manual/dev-manual.html'>
-        The Yocto Project Development Manual</ulink>.
-    </para>
-
-    <para> 
-        BitBake knows how to combine multiple data sources together and refers to each data source
-        as a <link linkend='usingpoky-changes-layers'>'layer'</link>.
-    </para>
-
-    <para>
-        Following are some brief details on these core components.
-        For more detailed information on these components see the 
-        <link linkend='ref-structure'>'Reference: Directory Structure'</link>
-        appendix.
-    </para>
-
-    <section id='usingpoky-components-bitbake'>
-        <title>BitBake</title>
-
-        <para>
-            BitBake is the tool at the heart of the Yocto Project and is responsible
-            for parsing the metadata, generating a list of tasks from it,
-            and then executing those tasks. 
-            To see a list of the options BitBake supports, use the following help command:
-            <literallayout class='monospaced'>
-     $ bitbake --help
-            </literallayout>
-        </para>
-
-        <para>
-            The most common usage for BitBake is <filename>bitbake &lt;packagename&gt;</filename>, where
-            <filename>packagename</filename> is the name of the package you want to build 
-            (referred to as the "target" in this manual). 
-            The target often equates to the first part of a <filename>.bb</filename> filename.
-            So, to run the <filename>matchbox-desktop_1.2.3.bb</filename> file, you
-            might type the following:
-            <literallayout class='monospaced'>
-     $ bitbake matchbox-desktop
-            </literallayout>
-            Several different versions of <filename>matchbox-desktop</filename> might exist.
-            BitBake chooses the one selected by the distribution configuration.
-            You can get more details about how BitBake chooses between different 
-            target versions and providers in the 
-            <link linkend='ref-bitbake-providers'>Preferences and Providers</link> section.
-        </para>
-
-        <para>
-            BitBake also tries to execute any dependent tasks first.
-            So for example, before building <filename>matchbox-desktop</filename>, BitBake
-            would build a cross compiler and <filename>glibc</filename> if they had not already 
-            been built.
-        </para>
-
-        <para>
-            A useful BitBake option to consider is the <filename>-k</filename> or 
-            <filename>--continue</filename> option.  
-            This option instructs BitBake to try and continue processing the job as much 
-            as possible even after encountering an error.  
-            When an error occurs, the target that
-            failed and those that depend on it cannot be remade.  
-            However, when you use this option other dependencies can still be processed.
-        </para>
-    </section>
-
-    <section id='usingpoky-components-metadata'>
-        <title>Metadata (Recipes)</title>
-
-        <para>
-            The <filename>.bb</filename> files are usually referred to as "recipes." 
-            In general, a recipe contains information about a single piece of software.
-            The information includes the location from which to download the source patches 
-            (if any are needed), which special configuration options to apply, 
-            how to compile the source files, and how to package the compiled output. 
-        </para>
-
-        <para>
-            The term "package" can also be used to describe recipes.
-            However, since the same word is used for the packaged output from the Yocto 
-            Project (i.e. <filename>.ipk</filename> or <filename>.deb</filename> files), 
-            this document avoids using the term "package" to refer to recipes.
-        </para>
-    </section>
-
-    <section id='usingpoky-components-classes'>
-        <title>Classes</title>
-
-        <para>
-            Class files (<filename>.bbclass</filename>) contain information that is useful to share
-            between metadata files. 
-            An example is the Autotools class, which contains
-            common settings for any application that Autotools uses.
-            The <link linkend='ref-classes'>Reference: Classes</link> appendix provides details
-            about common classes and how to use them.
-        </para>
-    </section>
-
-    <section id='usingpoky-components-configuration'>
-        <title>Configuration</title>
-
-        <para>
-            The configuration files (<filename>.conf</filename>) define various configuration variables
-            that govern the Yocto Project build process. 
-            These files fall into several areas that define machine configuration options, 
-            distribution configuration options, compiler tuning options, general common configuration
-            options and user configuration options (<filename>local.conf</filename>, which is found
-            in the Yocto Project files build directory).
-        </para>
-    </section>
-</section>
-
-
 <section id='usingpoky-build'>
     <title>Running a Build</title>
 
     <para>
-        You can find information on how to build an image using the Yocto Project in the 
-        <ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html#building-image'>
+        You can find general information on how to build an image using the 
+        Yocto Project in the 
+        <ulink url='http://www.yoctoproject.org/docs/latest/yocto-project-qs/yocto-project-qs.html#building-image'>
         Building an Image</ulink> section of the 
-        <ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html'>
+        <ulink url='http://www.yoctoproject.org/docs/latest/yocto-project-qs/yocto-project-qs.html'>
         Yocto Project Quick Start</ulink>.
-        This section provides a quick overview.
+        This section provides a summary of the build process and provides information
+        for less obvious aspects of the build process.
     </para>
 
-    <para>
-        The first thing you need to do is set up the Yocto Project build environment by sourcing
-        the environment setup script as follows:
-        <literallayout class='monospaced'>
-     $ source oe-init-build-env [build_dir];
-        </literallayout>
-    </para>
+    <section id='build-overview'>
+        <title>Build Overview</title>
 
-    <para>
-        The <filename>build_dir</filename> is optional and specifies the directory Yocto Project
-        uses for the build.
-        If you do not specify a build directory it defaults to <filename>build</filename>
-        in the Yocto Project files directory structure.
-        A common practice is to use a different build directory for different targets. 
-        For example, <filename>~/build/x86</filename> for a <filename>qemux86</filename>
-        target, and <filename>~/build/arm</filename> for a <filename>qemuarm</filename> target.
-        See <link linkend="structure-core-script">oe-init-build-env</link>
-        for more information on this script.
-    </para>
+        <para>
+            The first thing you need to do is set up the Yocto Project build environment by sourcing
+            the environment setup script as follows:
+            <literallayout class='monospaced'>
+     $ source oe-init-build-env [build_dir]
+            </literallayout>
+        </para>
 
-    <para>
-        Once the Yocto Project build environment is set up, you can build a target using:
-        <literallayout class='monospaced'>
+        <para>
+            The <filename>build_dir</filename> is optional and specifies the directory Yocto Project
+            uses for the build.
+            If you do not specify a build directory it defaults to <filename>build</filename>
+            in your current working directory.
+            A common practice is to use a different build directory for different targets. 
+            For example, <filename>~/build/x86</filename> for a <filename>qemux86</filename>
+            target, and <filename>~/build/arm</filename> for a <filename>qemuarm</filename> target.
+            See <link linkend="structure-core-script">oe-init-build-env</link>
+            for more information on this script.
+        </para>
+
+        <para>
+            Once the Yocto Project build environment is set up, you can build a target using:
+            <literallayout class='monospaced'>
      $ bitbake &lt;target&gt;
-        </literallayout>
-    </para>
+            </literallayout>
+        </para>
 
-    <para>
-        The <filename>target</filename> is the name of the recipe you want to build. 
-        Common targets are the images in <filename>meta/recipes-core/images</filename>,
-        <filename>/meta/recipes-sato/images</filename>, etc. all found in the Yocto Project
-        files.
-        Or, the target can be the name of a recipe for a specific piece of software such as 
-        <application>busybox</application>. 
-        For more details about the images Yocto Project supports, see the 
-        <link linkend="ref-images">'Reference: Images'</link> appendix.
-    </para>
+        <para>
+            The <filename>target</filename> is the name of the recipe you want to build. 
+            Common targets are the images in <filename>meta/recipes-core/images</filename>,
+            <filename>/meta/recipes-sato/images</filename>, etc. all found in the Yocto Project
+            files.
+            Or, the target can be the name of a recipe for a specific piece of software such as 
+            <application>busybox</application>. 
+            For more details about the images Yocto Project supports, see the 
+            <link linkend="ref-images">'Reference: Images'</link> appendix.
+        </para>
 
-    <note>
-        Building an image without GNU Public License Version 3 (GPLv3) components is 
-        only supported for minimal and base images.
-        See <link linkend='ref-images'>'Reference: Images'</link> for more information.
-    </note>
+        <note>
+            Building an image without GNU Public License Version 3 (GPLv3) components is 
+            only supported for minimal and base images.
+            See <link linkend='ref-images'>'Reference: Images'</link> for more information.
+        </note>
+    </section>
 
-    <note>
-        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.  
-        If you rebuild using different versions of GPL, dependency errors might occur
-        due to some components not being rebuilt.
-    </note>
+    <section id='building-an-image-using-gpl-components'>
+        <title>Building an Image Using GPL Components</title>
+
+        <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.  
+            If you rebuild using different versions of GPL, dependency errors might occur
+            due to some components not being rebuilt.
+        </para>
+    </section>
 </section>
 
 <section id='usingpoky-install'>
@@ -219,9 +93,9 @@
         <filename class="directory">tmp/deploy/images</filename>. 
         For information on how to run pre-built images such as <filename>qemux86</filename> 
         and <filename>qemuarm</filename>, see the
-        <ulink url='http://www.yoctoproject.org//docs/yocto-quick-start/yocto-project-qs.html#using-pre-built'>
+        <ulink url='http://www.yoctoproject.org/docs/latest/yocto-project-qs/yocto-project-qs.html#using-pre-built'>
         Using Pre-Built Binaries and QEMU</ulink> section in the 
-        <ulink url='http://www.yoctoproject.org//docs/yocto-quick-start/yocto-project-qs.html'>
+        <ulink url='http://www.yoctoproject.org/docs/latest/yocto-project-qs/yocto-project-qs.html'>
         Yocto Project Quick Start</ulink>.
         For information about how to install these images, see the documentation for your
         particular board/machine.
@@ -307,7 +181,7 @@
             You can view a list of tasks in a given package by running the
             <filename>listtasks</filename> task as follows:
             <literallayout class='monospaced'>
-     $ bitbake matchbox-desktop -c
+     $ bitbake matchbox-desktop -c listtasks
             </literallayout>
             The results are in the file <filename>${WORKDIR}/temp/log.do_listtasks</filename>.
         </para>

documentation/yocto-project-qs/style.css

@@ -966,3 +966,9 @@ table {
    color: #fff;   
    text-decoration: underline;
 }
+
+.footnote {
+   font-size: small;
+   color: #333;
+}
+

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

@@ -21,7 +21,7 @@
     <para>
         This short document will give you some basic information about the environment as well 
         as let you experience it in its simplest form.  
-        After reading this document you will have a basic understanding of what the Yocto Project is
+        After reading this document, you will have a basic understanding of what the Yocto Project is
         and how to use some of its core components.  
         This document steps you through a simple example showing you how to build a small image 
         and run it using the QEMU emulator.
@@ -29,20 +29,21 @@
     <para>
         For complete information on the Yocto Project, you should check out the 
         <ulink url='http://www.yoctoproject.org'>Yocto Project Website</ulink>.
-        You can find the latest builds, breaking news, full development documentation, and a 
+        Through the website, you can find the latest builds, breaking news, full development 
+        documentation, and a 
         rich Yocto Project Development Community into which you can tap.
     </para>
     <para>
         Finally, you might find the Frequently Asked Questions (FAQ) for the Yocto Project
         at <ulink url='https://wiki.yoctoproject.org/wiki/FAQ'>Yocto Project FAQ</ulink> and 
-        the FAQ appendix located in the 
-        <ulink url='http://www.yoctoproject.org/docs/poky-ref-manual/poky-ref-manual.html'>
-        Yocto Project Reference Manual</ulink> helpful.
+        the FAQ appendix located in  
+        <ulink url='http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html'>
+        The Yocto Project Reference Manual</ulink> helpful.
     </para>
     <note>
         Due to production processes, there could be differences between the Yocto Project
         documentation bundled in the release tarball and the 
-        <ulink url='http://www.yoctoproject.org/docs/1.1/yocto-project-qs/yocto-project-qs.html'>
+        <ulink url='http://www.yoctoproject.org/docs/latest/yocto-project-qs/yocto-project-qs.html'>
         Yocto Project Quick Start</ulink> on
         the <ulink url='http://www.yoctoproject.org'>Yocto Project</ulink> website.
         For the latest version of this manual, see the manual on the website.
@@ -74,7 +75,7 @@
      </mediaobject>
 
     <para>
-        Yocto Project:
+        Here are some highlights for the Yocto Project:
     </para>
 
     <itemizedlist>
@@ -85,7 +86,7 @@
             <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 
+            For devices that don't have a GUI or display, you simply would not employ these 
             components.</para>
         </listitem>
         <listitem>
@@ -100,9 +101,9 @@
 
     <para>
         The Yocto Project can generate images for many kinds of devices.  
-        However, the standard example machines target QEMU full system emulation for x86, ARM, MIPS,
-        and PPC-based architectures as well as specific hardware such as the Intel Desktop Board
-        DH55TC.  
+        However, the standard example machines target QEMU full-system emulation for x86, x86-64, ARM, MIPS,
+        and PPC-based architectures as well as specific hardware such as the 
+        <trademark class='registered'>Intel</trademark> Desktop Board DH55TC.  
         Because an image developed with the Yocto Project can boot inside a QEMU emulator, the 
         development environment works nicely as a test platform for developing embedded software.
     </para>
@@ -113,7 +114,7 @@
         restricted screen sizes, sits neatly on top of a device using the 
         GNOME Mobile Stack and provides a well-defined user experience. 
         Implemented in its own layer, it makes it clear to developers how they can implement 
-        their own UIs on top of Yocto Linux.
+        their own user interface on top of Yocto Linux.
     </para>
 </section>
 
@@ -128,11 +129,10 @@
         <listitem>
             <para>A host system running a supported Linux distribution (i.e. recent releases of
                 Fedora, openSUSE, Debian, and Ubuntu).
-            <note>
-                For notes about using the Yocto Project on development systems that use 
-                older Linux distributions see 
-                <ulink url='https://wiki.yoctoproject.org/wiki/BuildingOnRHEL4'></ulink>
-            </note></para>
+                If the host system supports multiple cores and threads, you can configure the 
+                Yocto Project build system to decrease the time needed to build images
+                significantly.
+            </para>
         </listitem>
         <listitem>
             <para>The right packages.</para>
@@ -146,15 +146,23 @@
         <title>The Linux Distribution</title>
 
         <para>
-            The Yocto Project has been tested and is known to work on the current releases minus one
-            of the following distributions. 
-            Follow this <ulink url='https://wiki.pokylinux.org/wiki/Distro_Test'>link </ulink> for more 
-            information on distribution testing.
+            The Yocto Project team is continually verifying more and more Linux 
+            distributions with each release.
+            In general, if you have the current release minus one of the following 
+            distributions you should have no problems.
             <itemizedlist>
                 <listitem><para>Ubuntu</para></listitem>
                 <listitem><para>Fedora</para></listitem>
                 <listitem><para>openSUSE</para></listitem>
             </itemizedlist>
+            For a list of the distributions under validation and their status, see the
+            <ulink url='https://wiki.yoctoproject.org/wiki/Distribution_Support'>Distribution
+            Support</ulink> wiki page.
+            <note>
+                For notes about using the Yocto Project on a RHEL 4-based host, see the
+                <ulink url='https://wiki.yoctoproject.org/wiki/BuildingOnRHEL4'>BuildingOnRHEL4</ulink>
+                wiki page.
+            </note>
             </para>
         <para>
             The build system should be able to run on any modern distribution with Python 2.6 or 2.7.
@@ -168,7 +176,7 @@
             Refer to  
             <ulink url='http://openembedded.net/index.php?title=OEandYourDistro&amp;action=historysubmit&amp;diff=4309&amp;okdid=4225'>OE and Your Distro</ulink> and 
             <ulink url='http://openembedded.net/index.php?title=Required_software&amp;action=historysubmit&amp;diff=4311&amp;oldid=4251'>Required Software</ulink> 
-            for information for other distributions used with the Open Embedded project, which might be
+            for information for other distributions used with the OpenEmbedded project, which might be
             a starting point for exploration.
             If you go down this path, you should expect problems.
             When you do, please go to <ulink url='http://bugzilla.yoctoproject.org'>Yocto Project Bugzilla</ulink>
@@ -183,56 +191,76 @@
         <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, and openSUSE.
         </para>
+  
+        <section id='ubuntu'>
+            <title>Ubuntu</title>
 
-        <note><para>
-            If you are using a Fedora version prior to version 15 you will need to take some 
-            extra steps to enable <filename>sudo</filename>.
-            See <ulink url='https://fedoraproject.org/wiki/Configuring_Sudo'></ulink> for details.
-        </para></note>
+            <para>
+                The packages you need for a supported Ubuntu distribution are shown in the following command:
+            </para>
 
-        <para>
-            The packages you need for a Debian-based host are shown in the following command:
-        </para>
-
-            <literallayout class='monospaced'>
+                <literallayout class='monospaced'>
      $ sudo apt-get install sed wget cvs subversion git-core coreutils \
      unzip texi2html texinfo libsdl1.2-dev docbook-utils gawk \
      python-pysqlite2 diffstat help2man make gcc build-essential \
      g++ desktop-file-utils chrpath libgl1-mesa-dev libglu1-mesa-dev \
-     mercurial autoconf automake groff libtool xterm
-            </literallayout>
+     mercurial autoconf automake groff libtool xterm libxml-parser-perl
+                </literallayout>
+        </section>
 
-        <para>
-            The packages you need for an RPM-based host like Fedora and openSUSE, 
-            respectively, are as follows:
-        </para>
+        <section id='fedora'>
+            <title>Fedora</title>
 
-            <literallayout class='monospaced'>
+            <para>
+                The packages you need for a supported Fedora distribution are shown in the following
+                commands:
+            </para>
+
+                <literallayout class='monospaced'>
      $ sudo yum groupinstall "development tools"
      $ sudo yum install python m4 make wget curl ftp hg tar bzip2 gzip \
      unzip python-psyco perl texinfo texi2html diffstat openjade \
      docbook-style-dsssl sed docbook-style-xsl docbook-dtds \
-     docbook-utils sed bc glibc-devel ccache pcre pcre-devel quilt \
+     docbook-utils sed bc eglibc-devel ccache pcre pcre-devel quilt \
      groff linuxdoc-tools patch linuxdoc-tools cmake help2man \
      perl-ExtUtils-MakeMaker tcl-devel gettext chrpath ncurses apr \
      SDL-devel mesa-libGL-devel mesa-libGLU-devel gnome-doc-utils \
      autoconf automake libtool xterm
-            </literallayout>
+                </literallayout>
 
-            <literallayout class='monospaced'>
+            <note><para>
+                If you are using a Fedora version prior to version 15, you will need to take some 
+                extra steps to enable <filename>sudo</filename>, or you will need to run
+                the commands as root user.
+                See the <ulink url='https://fedoraproject.org/wiki/Configuring_Sudo'>Configuring Sudo</ulink> 
+                wiki page for details.
+            </para></note>
+        </section>
+
+        <section id='opensuse'>
+            <title>openSUSE</title>
+
+            <para>
+                The packages you need for a supported openSUSE distribution are shown in the following 
+                command:
+            </para>
+
+                <literallayout class='monospaced'>
      $ sudo zypper install python gcc gcc-c++ libtool \
-     subversion git chrpath automake \
-     help2man diffstat texinfo mercurial wget
-            </literallayout>
- 
+     subversion git chrpath automake make wget help2man \
+     diffstat texinfo mercurial freeglut-devel libSDL-devel
+                </literallayout>
+        </section>
     </section>
 
     <section id='releases'>
         <title>Yocto Project Release</title>
             
         <para>
-            You can download the latest release images for the Yocto Project on the 
+            You can download the latest Yocto Project release by going to the 
             <ulink url="http://yoctoproject.org/download">Yocto Project Download page</ulink>.
             Just go to the page and click the "Yocto Downloads" link found in the "Download"
             navigation pane to the right to view all available Yocto Project releases. 
@@ -242,6 +270,17 @@
             <ulink url="http://autobuilder.yoctoproject.org/nightly/"></ulink>.  
             However, for this document a released version of Yocto Project is used.
         </para>
+
+        <para>
+            You can also get the Yocto Project files by setting up a Git repository on your host
+            development system. 
+            Doing so allows you to contribute back to the project.
+            For information on how to get set up using this method, see the 
+            "<ulink url='http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#local-yp-release'>Yocto 
+            Project Release</ulink>" item in  
+            <ulink url='http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html'>The Yocto Project
+            Development Manual</ulink>.
+        </para>
     </section>
 </section>
 
@@ -249,16 +288,16 @@
     <title>A Quick Test Run</title>
 
     <para>
-        Now that you have your system requirements in order you can give Yocto Project a try.  
+        Now that you have your system requirements in order, you can give Yocto Project a try.  
         This section presents some steps that let you do the following:
     </para>
 
     <itemizedlist>
         <listitem>
-            <para>Build an image and run it in the emulator</para>
+            <para>Build an image and run it in the QEMU emulator</para>
         </listitem>
         <listitem>
-            <para>Or, use a pre-built image and run it in the emulator</para>
+            <para>Use a pre-built image and run it in the QEMU emulator</para>
         </listitem>
     </itemizedlist>
 
@@ -266,7 +305,8 @@
         <title>Building an Image</title>
  
         <para>
-            In the development environment you will need to build an image whenever you change hardware support, add or change system libraries, or add or change services that have dependencies.
+            In the development environment you will need to build an image whenever you change hardware 
+            support, add or change system libraries, or add or change services that have dependencies.
         </para>
 
         <mediaobject>
@@ -295,22 +335,23 @@
              through a set of locations.
              If you encounter problems with the Yocto Project finding and downloading source code, see
              the FAQ entry "How does Poky obtain source code and will it work behind my
-             firewall or proxy server?" in the 
-             <ulink url='http://www.yoctoproject.org/docs/poky-ref-manual/poky-ref-manual.html'>
-             Yocto Project Reference Manual</ulink>.
+             firewall or proxy server?" in  
+             <ulink url='http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html'>
+             The Yocto Project Reference Manual</ulink>.
          </para></note>
 
          <para>
              <literallayout class='monospaced'>
-     $ wget http://www.yoctoproject.org/downloads/poky/poky-bernard-5.0.1.tar.bz2
-     $ tar xjf poky-bernard-5.0.1.tar.bz2
-     $ source poky-bernard-5.0.1/poky-init-build-env poky-5.0.1-build
+     $ wget http://downloads.yoctoproject.org/releases/yocto/yocto-1.1/poky-edison-6.0.tar.bz2
+     $ tar xjf poky-edison-6.0.tar.bz2
+     $ source poky-edison-6.0/oe-init-build-env edison-6.0-build
              </literallayout>
          </para>
 
          <tip><para>
-             To help conserve disk space during builds you can add the following statement
-             to your <filename>local.conf</filename> file.  
+             To help conserve disk space during builds, you can add the following statement
+             to your project's configuration file, which for this example
+             is <filename>edison-6.0-build/conf/local.conf</filename>.
              Adding this statement deletes the work directory used for building a package
              once the package is built.
              <literallayout class='monospaced'>
@@ -319,25 +360,50 @@
          </para></tip>
 
          <itemizedlist>
-             <listitem><para>The first two commands extract the Yocto Project files from the 
-             release tarball and place them into a subdirectory of your current directory.</para></listitem>
-             <listitem><para>The <command>source</command> command creates the 
-             <filename>poky-5.0.1-build</filename> directory and executes the <command>cd</command>
-             command to make <filename>poky-5.0.1-build</filename> the working directory.
-             The resulting build directory contains all the files created during the build.   
-             By default the target architecture is qemux86.
-             To change this default, edit the value of the MACHINE variable in the 
-             <filename>conf/local.conf</filename> file.</para></listitem>
+             <listitem><para>In the previous example, the first command retrieves the Yocto Project
+                 release tarball from the source repositories using the
+                 <filename>wget</filename> command.
+                 Alternatively, you can go to the 
+                 <ulink url='http://www.yoctoproject.org/download'>Yocto Project website</ulink>
+                 Downloads page to retrieve the tarball.</para></listitem>
+             <listitem><para>The second command extracts the files from the tarball and places 
+                 them into a directory named <filename>poky-edison-6.0</filename> in the current 
+                 directory.</para></listitem>
+             <listitem><para>The third command runs the Yocto Project environment setup script.
+                 Running this script defines Yocto Project build environment settings needed to 
+                 complete the build.
+                 The script also creates the Yocto Project
+                 build directory, which is <filename>edison-6.0-build</filename> in this case.
+                 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 
+                 created during the build.
+                 </para></listitem>
          </itemizedlist>
          <para>
-             Take some time to examine your <filename>conf/local.conf</filename> file found in the
-             Yocto Project file's <filename>conf</filename>.  
-             The defaults should work fine.  
-             However, if you have a multi-core CPU you might want to set the variable
-             BB_NUMBER_THREADS equal to twice the number of processor cores your system has.
-             And, set the variable PARALLEL_MAKE equal to the number of processor cores.
+             Take some time to examine your <filename>local.conf</filename> file 
+             in your project's configuration directory.
+             The defaults in that file should work fine.
+             However, there are some variables of interest at which you might look.
+         </para>
+
+         <para>  
+             By default, the target architecture for the build is <filename>qemux86</filename>, 
+             which produces an image that can be used in the QEMU emulator and is targeted at an
+             <trademark class='registered'>Intel</trademark> 32-bit based architecture.
+             To change this default, edit the value of the <filename>MACHINE</filename> variable 
+             in the configuration file before launching the build.
+         </para>
+
+         <para>
+             Another couple of variables of interest are the 
+             <ulink url='http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html#var-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename></ulink> and the 
+             <ulink url='http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html#var-PARALLEL_MAKE'><filename>PARALLEL_MAKE</filename></ulink> variables.
+             By default, these variables are commented out. 
+             However, if you have a multi-core CPU you might want to uncomment
+             the lines and set both variables equal to twice the number of your 
+             host's processor cores.
              Setting these variables can significantly shorten your build time.
-             By default, these variables are commented out.
          </para>
 
         <para>
@@ -345,28 +411,28 @@
             the image. 
             By default, the Yocto Project build system uses the RPM package manager.
             You can control this configuration by using the 
-            <filename><ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html#var-PACKAGE_CLASSES'>PACKAGE_CLASSES</ulink></filename> variable.  
+            <filename><ulink url='http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html#var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></ulink></filename> variable.  
              For additional package manager selection information, see 
-             <ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html#ref-classes-package'>Packaging - <filename>package*.bbclass</filename></ulink> in 
-             <ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html'>
+             "<ulink url='http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html#ref-classes-package'>Packaging - <filename>package*.bbclass</filename></ulink>" in 
+             <ulink url='http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html'>
              The Yocto Project Reference Manual</ulink>.
         </para>
 
          <para>
              Continue with the following command to build an OS image for the target, which is 
              <filename>core-image-sato</filename> in this example.
-             For information on the <filename>&dash;k</filename> option use the 
-             <filename>bitbake --help</filename> command or see
-             <ulink url='http://www.yoctoproject.org/docs/poky-ref-manual/poky-ref-manual.html#usingpoky-components-bitbake'>
-             BitBake</ulink> section in the Yocto Project Reference Manual.
+             For information on the <filename>-k</filename> option use the 
+             <filename>bitbake --help</filename> command or see the
+             "<ulink url='http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html#usingpoky-components-bitbake'>BitBake</ulink>" section in 
+             <ulink url='http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html'>The Yocto Project Reference Manual</ulink>.
              <literallayout class='monospaced'>
      $ bitbake -k core-image-sato
              </literallayout>
              <note><para>
                  BitBake requires Python 2.6 or 2.7.  For more information on this requirement, 
-                 see the FAQ appendix in the 
-                 <ulink url='http://www.yoctoproject.org/docs/poky-ref-manual/poky-ref-manual.html'>
-                 Yocto Project Reference Manual</ulink>.
+                 see the FAQ appendix in  
+                 <ulink url='http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html'>
+                 The Yocto Project Reference Manual</ulink>.
              </para></note>
              The final command runs the image:
              <literallayout class='monospaced'>
@@ -383,16 +449,13 @@
 
     <section id='using-pre-built'>
         <title>Using Pre-Built Binaries and QEMU</title>
+ 
         <para>
-            If hardware, libraries and services are stable you can get started by using a pre-built binary 
-            of the image, kernel and toolchain and run it using the emulator QEMU.  
+            If hardware, libraries and services are stable, you can get started by using a pre-built binary 
+            of the filesystem image, kernel, and toolchain and run it using the QEMU emulator.  
             This scenario is useful for developing application software.
         </para>
 
-        <para></para>
-        <para></para>
-        <para></para>
-
         <mediaobject>
             <imageobject>
             <imagedata fileref="figures/using-a-pre-built-image.png" format="PNG" align='center' scalefit='1'/>
@@ -400,54 +463,39 @@
             <caption>
                 <para>Using a Pre-Built Image</para>
             </caption>
-         </mediaobject>
+        </mediaobject>
 
-         <para>
-             For this scenario you need to do several things:
-         </para>
+        <para>
+            For this scenario, you need to do several things:
+        </para>
 
-         <itemizedlist>
-             <listitem>
-                 <para>
-                     Install the stand-alone Yocto toolchain tarball.
-                 </para>
-             </listitem>
-             <listitem>
-                 <para>
-                     Download the pre-built kernel that will boot with QEMU.  
-                     You need to be sure to get the QEMU image that matches your target machine’s 
-                     architecture (e.g. x86, ARM, etc.).
-                 </para>
-             </listitem>
-             <listitem>
-                 <para>
-                     Download the filesystem image for your target machine's architecture.
-                 </para>
-             </listitem>
-             <listitem>
-                 <para>
-                     Set up the environment to emulate the hardware and then start the QEMU emulator.
-                 </para>
-             </listitem>
-
-         </itemizedlist>
+        <itemizedlist>
+            <listitem><para>Install the stand-alone Yocto toolchain tarball.</para></listitem>
+            <listitem><para>Download the pre-built image that will boot with QEMU.  
+                You need to be sure to get the QEMU image that matches your target machine’s 
+                architecture (e.g. x86, ARM, etc.).</para></listitem>
+            <listitem><para>Download the filesystem image for your target machine's architecture.
+                </para></listitem>
+            <listitem><para>Set up the environment to emulate the hardware and then start the QEMU emulator.
+                </para></listitem>
+        </itemizedlist>
 
         <section id='installing-the-toolchain'>
-        <title>Installing the Toolchain</title>
-         <para>
-             You can download the pre-built toolchain, which includes the <filename>runqemu</filename> 
-             script and support files, from 
-             <ulink url='http://yoctoproject.org/downloads/yocto-1.0/toolchain/'></ulink>.  
-             Toolchains are available for 32-bit and 64-bit development systems from the 
-             <filename>i686</filename> and <filename>x86_64</filename> folders, respectively. 
-             Each type of development system supports five target architectures.
-             The tarball files are named 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>
+            <title>Installing the Toolchain</title>
+            <para>
+                You can download the pre-built toolchain, which includes the <filename>runqemu</filename> 
+                script and support files, from the appropriate directory under
+                <ulink url='http://downloads.yoctoproject.org/releases/yocto/yocto-1.1/toolchain/'></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 tarball files are named 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'>
-     yocto-eglibc&lt;<emphasis>host_system</emphasis>&gt;-&lt;<emphasis>arch</emphasis>&gt;-toolchain-gmae-&lt;<emphasis>release</emphasis>&gt;.tar.bz2
+            <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
 
      Where:
          &lt;<emphasis>host_system</emphasis>&gt; is a string representing your development system: 
@@ -457,100 +505,112 @@
                 i586, x86_64, powerpc, mips, or arm.
        
          &lt;<emphasis>release</emphasis>&gt; is the version of Yocto Project.
-         </literallayout>
+            </literallayout>
 
-         <para>       
-             For example, the following toolchain tarball is for a 64-bit development 
-             host system and a 32-bit target architecture:
-         </para>
+            <para>       
+                For example, the following toolchain tarball is for a 64-bit development 
+                host system and a 32-bit target architecture:
+            </para>
 
-         <literallayout class='monospaced'>
-     yocto-eglibc-x86_64-i586-toolchain-gmae-1.1.tar.bz2
-         </literallayout>
+            <literallayout class='monospaced'>
+     poky-eglibc-x86_64-i586-toolchain-gmae-1.1.tar.bz2
+            </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>:
-         </para>
+            <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>:
+            </para>
 
-         <para>
-             <literallayout class='monospaced'>
+            <para>
+                <literallayout class='monospaced'>
      $ cd /
-     $ sudo tar -xvjf ~/toolchains/yocto-eglibc-x86_64-i586-toolchain-gmae-1.1.tar.bz2
-             </literallayout>
-         </para>
-         </section>
+     $ sudo tar -xvjf ~/toolchains/poky-eglibc-x86_64-i586-toolchain-gmae-1.1.tar.bz2
+                </literallayout>
+            </para>
+
+            <para>
+                For more information on how to install tarballs, see the 
+                "<ulink url='http://www.yoctoproject.org/docs/latest/adt-manual/adt-manual.html#using-an-existing-toolchain-tarball'>Using a Cross-Toolchain Tarball</ulink>" and 
+                "<ulink url='http://www.yoctoproject.org/docs/latest/adt-manual/adt-manual.html#using-the-toolchain-from-within-the-build-tree'>Using BitBake and the Yocto Project Build Tree</ulink>" sections in  
+                <ulink url='http://www.yoctoproject.org/docs/latest/adt-manual/adt-manual.html'>The Yocto Project 
+                Application Development Toolkit (ADT) User's Guide</ulink>.
+            </para>
+        </section>
 
         <section id='downloading-the-pre-built-linux-kernel'>
-        <title>Downloading the Pre-Built Linux Kernel</title>
-         <para>
-             You can download the pre-built Linux kernel and the filesystem image suitable for 
-             running in the emulator QEMU from 
-             <ulink url='http://yoctoproject.org/downloads/yocto-1.0/machines/qemu'></ulink>.
-             Be sure to use the kernel and filesystem image that matches the architecture you want 
-             to simulate.
-             Download areas exist for the five supported machine architectures:
-             <filename>qemuarm</filename>, <filename>qemumips</filename>, <filename>qemuppc</filename>,
-             <filename>qemux86</filename>, and <filename>qemux86_64</filename>.
-         </para>
-       
-         <para>  
-             Most kernel files have one of the following forms:
-         </para>
-
-         <literallayout class='monospaced'>
-     *zImage-&lt;<emphasis>kernel-rev</emphasis>&gt;-qemu&lt;<emphasis>arch</emphasis>&gt;-&lt;<emphasis>release</emphasis>&gt;*.bin
-     vmlinux-&lt;<emphasis>kernel-rev</emphasis>&gt;-qemu&lt;<emphasis>arch</emphasis>&gt;-&lt;<emphasis>release</emphasis>&gt;*.bin
+            <title>Downloading the Pre-Built Linux Kernel</title>
+      
+            <para>
+                You can download the pre-built Linux kernel suitable for running in the QEMU emulator from 
+                <ulink url='http://downloads.yoctoproject.org/releases/yocto/yocto-1.1/machines/qemu'></ulink>.
+                Be sure to use the kernel that matches the architecture you want to simulate.
+                Download areas exist for the five supported machine architectures:
+                <filename>qemuarm</filename>, <filename>qemumips</filename>, <filename>qemuppc</filename>,
+                <filename>qemux86</filename>, and <filename>qemux86_64</filename>.
+            </para>
+         
+            <para>  
+                Most kernel files have one of the following forms:
+                <literallayout class='monospaced'>
+     *zImage-qemu&lt;<emphasis>arch</emphasis>&gt;.bin
+     vmlinux-qemu&lt;<emphasis>arch</emphasis>&gt;.bin
 
      Where:
-         &lt;<emphasis>kernel-rev</emphasis>&gt; is the base Linux kernel revision 
-                (e.g. 2.6.37).
-
          &lt;<emphasis>arch</emphasis>&gt; is a string representing the target architecture: 
                 x86, x86-64, ppc, mips, or arm.
+                </literallayout>
+            </para>
 
-         &lt;<emphasis>release</emphasis>&gt; is the version of Yocto Project. 
-         </literallayout>
-         </section>
+            <para>
+                You can learn more about downloading a Yocto Project kernel in the 
+                "<ulink url='http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#local-kernel-files'>Linux Yocto Kernel</ulink>" section of  
+                <ulink url='http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html'>The 
+                Yocto Project Development Manual</ulink>.
+            </para>
+        </section>
 
         <section id='downloading-the-filesystem'>
-        <title>Downloading the Filesystem</title>
-         <para>
-             The filesystem image has two tarball forms: <filename>ext3</filename> and 
-             <filename>tar</filename>.
-             You must use the <filename>ext3</filename> form when booting an image using the 
-             QEMU emulator.
-             The <filename>tar</filename> form can be flattened out in your host development system
-             and used for Yocto Project build purposes.
-         </para>
+            <title>Downloading the Filesystem</title>
 
-          <literallayout class='monospaced'>
-     yocto-image-&lt;<emphasis>profile</emphasis>&gt;-qemu&lt;<emphasis>arch</emphasis>&gt;-&lt;<emphasis>release</emphasis>&gt;.rootfs.ext3.bz2
-     yocto-image-&lt;<emphasis>profile</emphasis>&gt;-qemu&lt;<emphasis>arch</emphasis>&gt;-&lt;<emphasis>release</emphasis>&gt;.rootfs.tar.bz2
+            <para>
+                You can also download the filesystem image suitable for your target architecture from
+                <ulink url='http://downloads.yoctoproject.org/releases/yocto/yocto-1.1/machines/qemu'></ulink>.
+                Again, be sure to use the filesystem that matches the architecture you want 
+                to simulate.
+            </para>
+
+            <para>
+                The filesystem image has two tarball forms: <filename>ext3</filename> and 
+                <filename>tar</filename>.
+                You must use the <filename>ext3</filename> form when booting an image using the 
+                QEMU emulator.
+                The <filename>tar</filename> form can be flattened out in your host development system
+                and used for Yocto Project build purposes.
+                <literallayout class='monospaced'>
+     core-image-&lt;<emphasis>profile</emphasis>&gt;-qemu&lt;<emphasis>arch</emphasis>&gt;.ext3
+     core-image-&lt;<emphasis>profile</emphasis>&gt;-qemu&lt;<emphasis>arch</emphasis>&gt;.tar.bz2
 
      Where:
          &lt;<emphasis>profile</emphasis>&gt; is the filesystem image's profile:
-                   lsb, lsb-dev, lsb-sdk, minimal, minimal-dev, sato, sato-dev, or sato-sdk.
+                   lsb, lsb-dev, lsb-sdk, lsb-qt3, minimal, minimal-dev, sato, sato-dev, or sato-sdk.
                    For information on these types of image profiles, see
-                   <ulink url='http://www.yoctoproject.org/docs/1.1/poky-ref-manual/poky-ref-manual.html#ref-images'>Reference: Images</ulink> in the Yocto Project Reference Manual.
+                   <ulink url='http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html#ref-images'>Reference: Images</ulink> in the Yocto Project Reference Manual.
 
          &lt;<emphasis>arch</emphasis>&gt; is a string representing the target architecture: 
                 x86, x86-64, ppc, mips, or arm.
-
-         &lt;<emphasis>release</emphasis>&gt; is the version of Yocto Project. 
-          </literallayout>
-         </section>
+                </literallayout>
+            </para>
+        </section>
 
         <section id='setting-up-the-environment-and-starting-the-qemu-emulator'>
-        <title>Setting Up the Environment and Starting the QEMU Emulator</title>
-         <para>
-             Before you start the QEMU emulator you need to set up the emulation environment.
-             The following command form sets up the emulation environment.
-         </para>
-
-         <literallayout class='monospaced'>
+            <title>Setting Up the Environment and Starting the QEMU Emulator</title>
+           
+            <para>
+                Before you start the QEMU emulator, you need to set up the emulation environment.
+                The following command form sets up the emulation environment.
+                <literallayout class='monospaced'>
      $ source /opt/poky/1.1/environment-setup-&lt;<emphasis>arch</emphasis>&gt;-poky-linux-&lt;<emphasis>if</emphasis>&gt; 
 
      Where:
@@ -559,13 +619,12 @@
 
          &lt;<emphasis>if</emphasis>&gt; is a string representing an embedded application binary interface.
               Not all setup scripts include this string.
-         </literallayout>
+                </literallayout>
+            </para>
 
-         <para>
-              Finally, this command form invokes the QEMU emulator 
-         </para>
-
-         <literallayout class='monospaced'>
+            <para>
+                Finally, this command form invokes the QEMU emulator 
+                <literallayout class='monospaced'>
      $ runqemu &lt;<emphasis>qemuarch</emphasis>&gt; &lt;<emphasis>kernel-image</emphasis>&gt; &lt;<emphasis>filesystem-image</emphasis>&gt;
 
      Where:
@@ -576,33 +635,32 @@
 
          &lt;<emphasis>filesystem-image</emphasis>&gt; is the .ext3 filesystem image.
 
-         </literallayout>
+                </literallayout>
+            </para>
 
-         <para>
-             Continuing with the example, the following two commands setup the emulation 
-             environment and launch QEMU.
-             This example assumes the root filesystem tarball has been downloaded and expanded, and 
-             that the kernel and filesystem are for a 32-bit target architecture.
-         </para>
-
-         <literallayout class='monospaced'>
+            <para>
+                Continuing with the example, the following two commands setup the emulation 
+                environment and launch QEMU.
+                This example assumes the root filesystem tarball has been downloaded and expanded, and 
+                that the kernel and filesystem are for a 32-bit target architecture.
+                <literallayout class='monospaced'>
      $ source /opt/poky/1.1/environment-setup-i686-poky-linux 
      $ runqemu qemux86 bzImage-3.0-qemux86-1.1.bin \
-     yocto-image-sato-qemux86-1.1.rootfs.ext3
-         </literallayout>
+     core-image-sato-qemux86.ext3
+                </literallayout>
+            </para>
 
-         <para>
-             The environment in which QEMU launches varies depending on the filesystem image and on the 
-             target architecture.  For example, if you source the environment for the ARM target 
-             architecture and then boot the minimal QEMU image, the emulator comes up in a new 
-             shell in command-line mode.  However, if you boot the SDK image QEMU comes up with 
-             a GUI.
-         </para>
- 
-         <note><para>
-             Booting the PPC image results in QEMU launching in the same shell in command-line mode.
-         </para></note>
-         </section>     
+            <para>
+                The environment in which QEMU launches varies depending on the filesystem image and on the 
+                target architecture.  
+                For example, if you source the environment for the ARM target 
+                architecture and then boot the minimal QEMU image, the emulator comes up in a new 
+                shell in command-line mode.  
+                However, if you boot the SDK image, QEMU comes up with a GUI.
+                <note>Booting the PPC image results in QEMU launching in the same shell in 
+                command-line mode.</note>
+            </para>
+        </section>     
     </section>
 </section>
 

meta-demoapps/recipes-connectivity/farsight/farsight2_0.0.9.bb

@@ -1,12 +1,12 @@
 DESCRIPTION = "FarSight is an audio/video conferencing framework specifically designed for Instant Messengers."
 HOMEPAGE = "http://farsight.sf.net"
 SRC_URI = "http://farsight.freedesktop.org/releases/farsight2/${BPN}-${PV}.tar.gz"
-LICENSE = "GPLv2.1"
+LICENSE = "LGPLv2.1"
 DEPENDS = "libnice glib-2.0 libxml2 zlib dbus gstreamer gst-plugins-base"
 
 inherit autotools
 
-PR = "r1"
+PR = "r2"
 
 EXTRA_OECONF = " \
   --disable-debug \

meta-demoapps/recipes-connectivity/openswan/openswan-2.4.7/installflags.patch

@@ -1,3 +1,5 @@
+Upstream-Status: Inappropriate [configuration]
+
 Index: openswan-2.4.7/Makefile.inc
 ===================================================================
 --- openswan-2.4.7.orig/Makefile.inc	2006-12-25 18:05:40.608503250 +0100

meta-demoapps/recipes-connectivity/openswan/openswan-2.4.7/ld-library-path-breakage.patch

@@ -1,3 +1,5 @@
+Upstream-Status: Inappropriate [configuration]
+
 --- openswan-2.2.0.orig/programs/Makefile.program	2004-06-03 03:06:27.000000000 +0200
 +++ openswan-2.2.0/programs/Makefile.program	2005-03-05 13:50:19.000000000 +0100
 @@ -30,10 +30,6 @@

meta-demoapps/recipes-connectivity/openswan/openswan-2.4.7/openswan-2.4.7-gentoo.patch

@@ -1,3 +1,5 @@
+Upstream-Status: Inappropriate [configuration]
+
 diff -Nru openswan-2.4.7.orig/doc/Makefile openswan-2.4.7/doc/Makefile
 --- openswan-2.4.7.orig/doc/Makefile	2005-11-08 23:32:45.000000000 +0200
 +++ openswan-2.4.7/doc/Makefile	2006-12-06 22:46:54.732830840 +0200

meta-demoapps/recipes-connectivity/opensync/libsync_git.bb

@@ -1,16 +1,17 @@
 SUMMARY = "GObject-based sync library"
 DESCRIPTION = "LibSync is a GObject-based framework for more convenient use of \
 OpenSync in GLib applications."
-LICENSE = "LGPL"
+LICENSE = "LGPLv2"
 SECTION = "x11"
 DEPENDS = "glib-2.0 gtk+ libglade libopensync avahi"
 RRECOMMENDS_${PN} = "\
 	libopensync-plugin-file \
 	"
-PV = "0.0+svnr${SRCPV}"
-PR = "r1"
+SRCREV = "3f375969d56028505db97cd25ef1679a167cfc59"
+PV = "0.0+gitr${SRCPV}"
+PR = "r2"
 
-SRC_URI = "svn://svn.o-hand.com/repos/sync/trunk;module=sync;proto=http"
+SRC_URI = "git://git.yoctoproject.org/sync;protocol=git"
 
 inherit autotools pkgconfig
 

meta-demoapps/recipes-connectivity/wbxml/files/no-doc-install.patch

@@ -1,3 +1,5 @@
+
+Upstream-Status: Inappropriate [configuration]
 --- wbxml2-0.9.2/Makefile.am.old	2007-01-03 19:50:24.000000000 +0000
 +++ wbxml2-0.9.2/Makefile.am	2007-01-03 19:50:39.000000000 +0000
 @@ -24,9 +24,9 @@

meta-demoapps/recipes-gnome/abiword/abiword-2.5.inc

@@ -9,7 +9,7 @@ RDEPENDS_${PN}    = "glibc-gconv-ibm850 glibc-gconv-cp1252 \
 SRC_URI = "http://www.abiword.org/downloads/abiword/${PV}/source/abiword-${PV}.tar.gz"
 
 #want 2.x from 2.x.y for the installation directory
-SHRT_VER = "${@bb.data.getVar('PV',d,1).split('.')[0]}.${@bb.data.getVar('PV',d,1).split('.')[1]}"
+SHRT_VER = "${@d.getVar('PV',1).split('.')[0]}.${@d.getVar('PV',1).split('.')[1]}"
 
 FILES_${PN} += " \
 		${datadir}/icons/* \

meta-demoapps/recipes-gnome/abiword/abiword.inc

@@ -13,11 +13,11 @@ RRECOMMENDS_${PN}    = "glibc-gconv-ibm850 glibc-gconv-cp1252 \
 RELURI = "http://www.abiword.org/downloads/abiword/${PV}/source/abiword-${PV}.tar.gz"
 RELSRC = "${WORKDIR}/abiword-${PV}/abi"
 
-CVSURI = "cvs://anoncvs:anoncvs@anoncvs.abisource.com/cvsroot;module=abi"
-CVSSRC = "${WORKDIR}/abi"
+SVNURI = "svn://svn.abisource.com/abiword/trunk;module=abiword;proto=http"
+SVNSRC = "${WORKDIR}/abi"
 
 #want 2.x from 2.x.y for the installation directory
-SHRT_VER = "${@bb.data.getVar('PV',d,1).split('.')[0]}.${@bb.data.getVar('PV',d,1).split('.')[1]}"
+SHRT_VER = "${@d.getVar('PV',1).split('.')[0]}.${@d.getVar('PV',1).split('.')[1]}"
 
 FILES_${PN} += " \
 		${datadir}/icons/* \

meta-demoapps/recipes-gnome/abiword/abiword_cvs.bb

@@ -1,10 +0,0 @@
-require abiword.inc
-
-SRCDATE = "20070130"
-PV="2.5.0+cvs${SRCDATE}"
-PR = "r4"
-
-SRC_URI = "${CVSURI}"
-
-S = "${CVSSRC}"
-

meta-demoapps/recipes-gnome/abiword/abiword_svn.bb

@@ -0,0 +1,10 @@
+require abiword.inc
+
+SRCREV = "21818"
+PV="2.5.2+svnr${SRCPV}"
+PR = "r0"
+
+SRC_URI = "${SVNURI}"
+
+S = "${SVNSRC}"
+

meta-demoapps/recipes-gnome/gcalctool/gcalctool/fix-includedir.patch

@@ -3,6 +3,8 @@
  gcalctool/Makefile.am |    2 --
  2 files changed, 1 insertion(+), 3 deletions(-)
 
+Upstream-Status: Inappropriate [configuration]
+
 Index: gcalctool-5.8.17/gcalctool/Makefile.am
 ===================================================================
 --- gcalctool-5.8.17.orig/gcalctool/Makefile.am	2005-12-19 15:46:57.000000000 +0000

meta-demoapps/recipes-gnome/libgsf/libgsf_1.14.5.bb

@@ -1,10 +1,14 @@
 DESCRIPTION = "GNOME Structured File Library"
 LICENSE = "GPL"
 SECTION = "libs"
-PR = "r1"
+PR = "r2"
+
+LIC_FILES_CHKSUM = "file://COPYING;md5=dc7371b50816c96e145fa0f8ade8e24d \
+                    file://COPYING.LIB;md5=61464cfe342798eeced82efe9ae55f63 \
+                    file://gsf/gsf.h;endline=25;md5=15cf6d31ad023167779ab5f0bbb76f49"
 
 DEPENDS= "libxml2 bzip2 glib-2.0 zlib"
-RDEPENDS_${PN} = "gconf gnome-vfs"
+RDEPENDS_${PN} = "gconf"
 
 
 PACKAGES =+ "${PN}-gnome ${PN}-gnome-dev "

meta-demoapps/recipes-graphics/clutter/table.inc

@@ -1,13 +0,0 @@
-DESCRIPTION = "Table Clutter Demo"
-HOMEPAGE = "http://www.clutter-project.org/"
-LICENSE = "LGPLv2.1 & GPLv2"
-
-DEPENDS = "clutter-gst-1.4 gnome-vfs"
-
-inherit autotools pkgconfig
-
-do_install() {
-	install -d ${D}${bindir}
-	install -m 0755 ${S}/table ${D}${bindir}/table
-}
-