documentation: Updated Manual Revision Tables for 1.1.2

Updated the tables for the adt, bsp, dev, kernel, and ref manuals
so the release date is "July 2012".

(From yocto-docs rev: fc4cb441031bca79f09203f9268f0528078fb652)

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

README

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

bitbake/bin/bitbake

@@ -40,7 +40,7 @@ from bb import cooker
 from bb import ui
 from bb import server
 
-__version__ = "1.15.0"
+__version__ = "1.13.3"
 logger = logging.getLogger("BitBake")
 
 
@@ -165,9 +165,6 @@ 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)
@@ -189,9 +186,6 @@ 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")
@@ -228,17 +222,14 @@ Default BBFILES are the .bb files in the current directory.""")
 
     logger.removeHandler(handler)
 
-    if not configuration.server_only:
-        # Setup a connection to the server (cooker)
-        server_connection = server.establishConnection()
+    # 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()
-    else:
-        print("server address: %s, server port: %s" % (server.serverinfo.host, server.serverinfo.port))
+    try:
+        return server.launchUI(ui_main, server_connection.connection, server_connection.events)
+    finally:
+        bb.event.ui_queue = []
+        server_connection.terminate()
 
     return 1
 

bitbake/bin/bitbake-layers

@@ -8,7 +8,6 @@ import cmd
 import logging
 import os
 import sys
-import fnmatch
 
 bindir = os.path.dirname(__file__)
 topdir = os.path.dirname(bindir)
@@ -19,7 +18,6 @@ import bb.cooker
 import bb.providers
 import bb.utils
 from bb.cooker import state
-import bb.fetch2
 
 
 logger = logging.getLogger('BitBake')
@@ -140,10 +138,9 @@ 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 [layer1 layer2 [layer3]...] <outputdir>
+usage: flatten <outputdir>
 
-Takes the specified layers (or all layers in the current layer
-configuration if none are specified) and builds a "flattened" directory
+Takes the current layer configuration 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:
@@ -151,63 +148,21 @@ 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 number layer's layer.conf is used)
+  layer.conf (only the lowest priority 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 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)
+        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])
             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():
@@ -225,7 +180,7 @@ build results (as the layer priority order has effectively changed).
                         ext = os.path.splitext(f1)[1]
                         if ext != '.bbappend':
                             fdest = f1full[len(layer):]
-                            fdest = os.path.normpath(os.sep.join([outputdir,fdest]))
+                            fdest = os.path.normpath(os.sep.join([arglist[0],fdest]))
                             bb.utils.mkdirhier(os.path.dirname(fdest))
                             if os.path.exists(fdest):
                                 if f1 == 'layer.conf' and root.endswith('/conf'):
@@ -240,60 +195,7 @@ build results (as the layer priority order has effectively changed).
                                     if appends:
                                         logger.plain('  Applying appends to %s' % fdest )
                                         for appendname in appends:
-                                            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)
+                                            self.apply_append(appendname, fdest)
 
     def get_append_layer(self, appendname):
         for layer, _, regex, _ in self.cooker.status.bbfile_config_priorities:
@@ -307,8 +209,6 @@ build results (as the layer priority order has effectively changed).
         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,39 +10,37 @@ import prserv.serv
 
 __version__="1.0.0"
 
-PRHOST_DEFAULT='0.0.0.0'
+PRHOST_DEFAULT=''
 PRPORT_DEFAULT=8585
 
 def main():
     parser = optparse.OptionParser(
         version="Bitbake PR Service Core version %s, %%prog version %s" % (prserv.__version__, __version__),
-        usage = "%prog < --start | --stop > [options]")
+        usage = "%prog [options]")
 
-    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",
+    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",
                       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 = "INFO")
+                      action = "store", type="string", dest="loglevel", default = "WARNING")
     parser.add_option("--start", help="start daemon",
-                      action="store_true", dest="start")
+                      action="store_true", dest="start", default="True")
     parser.add_option("--stop", help="stop daemon",
-                      action="store_true", dest="stop")
+                      action="store_false", dest="start")
     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:
-        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)
+        prserv.serv.start_daemon(options)
     else:
-        ret=parser.print_help()
-    return ret
+        prserv.serv.stop_daemon()
 
 if __name__ == "__main__":
     try:

bitbake/bin/bitbake-runtask

@@ -91,7 +91,7 @@ def register_idle_function(self, function, data):
 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))
+cooker.handleCollections(bb.data.getVar("BBFILE_COLLECTIONS", config_data, 1))
 
 fn, cls = bb.cache.Cache.virtualfn2realfn(buildfile)
 buildfile = cooker.matchFile(fn)
@@ -108,9 +108,9 @@ if taskname.endswith("_setscene"):
 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])
+        bb.data.setVar("BBHASH_%s" % h, hashdata["hashes"][h], the_data)
     for h in hashdata["deps"]:
-        the_data.setVar("BBHASHDEPS_%s" % h, hashdata["deps"][h])
+        bb.data.setVar("BBHASHDEPS_%s" % h, hashdata["deps"][h], the_data)
 
 ret = 0
 if dryrun != "True":

bitbake/bin/bitdoc

@@ -462,7 +462,7 @@ def main():
     state_group = 2
 
     for key in bb.data.keys(documentation):
-        data   = documentation.getVarFlag(key, "doc")
+        data   = bb.data.getVarFlag(key, "doc", documentation)
         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 d.getVar('SOMECONDITION', True):
+    if bb.data.getVar('SOMECONDITION', d, 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 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>
+            <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>
 
         </section>
 

bitbake/lib/bb/__init__.py

@@ -21,24 +21,12 @@
 # with this program; if not, write to the Free Software Foundation, Inc.,
 # 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
 
-__version__ = "1.15.0"
+__version__ = "1.13.3"
 
 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
 
@@ -79,7 +67,7 @@ if "BBDEBUG" in os.environ:
     if level:
         bb.msg.set_debug_level(level)
 
-if os.environ.get("BBFETCH2"):
+if True or 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 = d.getVar("PF", 1)
+        self._package = bb.data.getVar("PF", d, 1)
         event.Event.__init__(self)
-        self._message = "package %s: task %s: %s" % (d.getVar("PF", 1), t, bb.event.getName(self)[4:])
+        self._message = "package %s: task %s: %s" % (bb.data.getVar("PF", d, 1), t, bb.event.getName(self)[4:])
 
     def getTask(self):
         return self._task

bitbake/lib/bb/cache.py

@@ -31,6 +31,7 @@
 import os
 import logging
 from collections import defaultdict
+import bb.data
 import bb.utils
 
 logger = logging.getLogger("BitBake.Cache")
@@ -142,7 +143,6 @@ 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,7 +178,6 @@ class CoreRecipeInfo(RecipeInfoCommon):
         cachedata.license = {}
         cachedata.section = {}
         cachedata.fakerootenv = {}
-        cachedata.fakerootnoenv = {}
         cachedata.fakerootdirs = {}
 
     def add_cacheData(self, cachedata, fn):
@@ -244,7 +243,6 @@ 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
 
 
@@ -259,7 +257,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 = data.getVar("CACHE", True)
+        self.cachedir = bb.data.getVar("CACHE", data, True)
         self.clean = set()
         self.checked = set()
         self.depends_cache = {}
@@ -282,7 +280,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 = data.getVar("__base_depends")
+        deps = bb.data.getVar("__base_depends", data)
 
         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 = (d.getVar("PERSISTENT_DIR", True) or
-                d.getVar("CACHE", True))
+    cachedir = (bb.data.getVar("PERSISTENT_DIR", d, True) or
+                bb.data.getVar("CACHE", d, True))
     if cachedir in [None, '']:
         return None
     bb.utils.mkdirhier(cachedir)

bitbake/lib/bb/command.py

@@ -30,6 +30,11 @@ 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
@@ -56,6 +61,16 @@ 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)
@@ -98,12 +113,9 @@ class Command:
             else:
                 self.finishAsyncCommand("Exited with %s" % arg)
             return False
-        except Exception as exc:
+        except Exception:
             import traceback
-            if isinstance(exc, bb.BBHandledException):
-                self.finishAsyncCommand("")
-            else:
-                self.finishAsyncCommand(traceback.format_exc())
+            self.finishAsyncCommand(traceback.format_exc())
             return False
 
     def finishAsyncCommand(self, msg=None, code=None):
@@ -150,7 +162,7 @@ class CommandsSync:
         if len(params) > 1:
             expand = params[1]
 
-        return command.cooker.configuration.data.getVar(varname, expand)
+        return bb.data.getVar(varname, command.cooker.configuration.data, expand)
 
     def setVariable(self, command, params):
         """
@@ -158,13 +170,7 @@ class CommandsSync:
         """
         varname = params[0]
         value = params[1]
-        command.cooker.configuration.data.setVar(varname, value)
-
-    def initCooker(self, command, params):
-        """
-        Init the cooker to initial state with nothing parsed
-        """
-        command.cooker.initialize()
+        bb.data.setVar(varname, value, command.cooker.configuration.data)
 
     def resetCooker(self, command, params):
         """
@@ -241,17 +247,6 @@ 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
@@ -261,7 +256,7 @@ class CommandsAsync:
 
         command.cooker.findConfigFiles(varname)
         command.finishAsyncCommand()
-    findConfigFiles.needcache = False
+    findConfigFiles.needcache = True
 
     def findFilesMatchingInDir(self, command, params):
         """
@@ -273,7 +268,7 @@ class CommandsAsync:
 
         command.cooker.findFilesMatchingInDir(pattern, directory)
         command.finishAsyncCommand()
-    findFilesMatchingInDir.needcache = False
+    findFilesMatchingInDir.needcache = True
 
     def findConfigFilePath(self, command, params):
         """
@@ -340,13 +335,3 @@ 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,9 +34,8 @@ from cStringIO import StringIO
 from contextlib import closing
 from functools import wraps
 from collections import defaultdict
-import bb, bb.exceptions, bb.command
-from bb import utils, data, parse, event, cache, providers, taskdata, runqueue
-import prserv.serv
+import bb, bb.exceptions
+from bb import utils, data, parse, event, cache, providers, taskdata, command, runqueue
 
 logger      = logging.getLogger("BitBake")
 collectlog  = logging.getLogger("BitBake.Collection")
@@ -136,14 +135,10 @@ class BBCooker:
         self.configuration.data = None
         self.loadConfigurationData()
 
-        # 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")
+        if not self.configuration.cmd:
+            self.configuration.cmd = bb.data.getVar("BB_DEFAULT_TASK", self.configuration.data, True) or "build"
 
-        bbpkgs = self.configuration.data.getVar('BBPKGS', True)
+        bbpkgs = bb.data.getVar('BBPKGS', self.configuration.data, True)
         if bbpkgs and len(self.configuration.pkgs_to_build) == 0:
             self.configuration.pkgs_to_build.extend(bbpkgs.split())
 
@@ -168,20 +163,11 @@ class BBCooker:
 
         self.parser = None
 
-    def initConfigurationData(self):
-        self.configuration.data = bb.data.init()
-
-        if not self.server_registration_cb:
-            bb.data.setVar("BB_WORKERCONTEXT", "1", self.configuration.data)
-
-        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")
+            bb.data.setVar("BB_WORKERCONTEXT", "1", self.configuration.data)
 
         filtered_keys = bb.utils.approved_variables()
         bb.data.inheritFromOS(self.configuration.data, self.savedenv, filtered_keys)
@@ -196,13 +182,13 @@ class BBCooker:
             sys.exit(1)
 
         if not self.configuration.cmd:
-            self.configuration.cmd = self.configuration.data.getVar("BB_DEFAULT_TASK", True) or "build"
+            self.configuration.cmd = bb.data.getVar("BB_DEFAULT_TASK", self.configuration.data, True) or "build"
 
     def parseConfiguration(self):
 
 
         # Change nice level if we're asked to
-        nice = self.configuration.data.getVar("BB_NICE_LEVEL", True)
+        nice = bb.data.getVar("BB_NICE_LEVEL", self.configuration.data, True)
         if nice:
             curnice = os.nice(0)
             nice = int(nice) - curnice
@@ -300,7 +286,7 @@ class BBCooker:
             # this showEnvironment() code path doesn't use the cache
             self.parseConfiguration()
             self.status = bb.cache.CacheData(self.caches_array)
-            self.handleCollections( self.configuration.data.getVar("BBFILE_COLLECTIONS", 1) )
+            self.handleCollections( bb.data.getVar("BBFILE_COLLECTIONS", self.configuration.data, 1) )
 
             fn, cls = bb.cache.Cache.virtualfn2realfn(buildfile)
             fn = self.matchFile(fn)
@@ -606,7 +592,7 @@ class BBCooker:
         bb.data.expandKeys(localdata)
 
         # Handle PREFERRED_PROVIDERS
-        for p in (localdata.getVar('PREFERRED_PROVIDERS', True) or "").split():
+        for p in (bb.data.getVar('PREFERRED_PROVIDERS', localdata, True) or "").split():
             try:
                 (providee, provider) = p.split(':')
             except:
@@ -642,18 +628,6 @@ 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
@@ -666,8 +640,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 = self.configuration.data.getVar('__depends') or set()
-        dep_files.union(self.configuration.data.getVar('__base_depends') or set())
+        dep_files = bb.data.getVar('__depends', self.configuration.data) or set()
+        dep_files.union(bb.data.getVar('__base_depends', self.configuration.data) or set())
 
         for f in dep_files:
             if f[0].endswith(".conf"):
@@ -695,7 +669,7 @@ class BBCooker:
 
         matches = []
         p = re.compile(re.escape(filepattern))
-        bbpaths = self.configuration.data.getVar('BBPATH', True).split(':')
+        bbpaths = bb.data.getVar('BBPATH', self.configuration.data, True).split(':')
         for path in bbpaths:
             dirpath = os.path.join(path, directory)
             if os.path.exists(dirpath):
@@ -717,7 +691,7 @@ class BBCooker:
 
         data = self.configuration.data
         # iterate configs
-        bbpaths = data.getVar('BBPATH', True).split(':')
+        bbpaths = bb.data.getVar('BBPATH', data, True).split(':')
         for path in bbpaths:
             confpath = os.path.join(path, "conf", var)
             if os.path.exists(confpath):
@@ -822,16 +796,16 @@ class BBCooker:
             parselog.debug(2, "Found bblayers.conf (%s)", layerconf)
             data = _parse(layerconf, data)
 
-            layers = (data.getVar('BBLAYERS', True) or "").split()
+            layers = (bb.data.getVar('BBLAYERS', data, True) or "").split()
 
             data = bb.data.createCopy(data)
             for layer in layers:
                 parselog.debug(2, "Adding layer %s", layer)
-                data.setVar('LAYERDIR', layer)
+                bb.data.setVar('LAYERDIR', layer, data)
                 data = _parse(os.path.join(layer, "conf", "layer.conf"), data)
                 data.expandVarref('LAYERDIR')
 
-            data.delVar('LAYERDIR')
+            bb.data.delVar('LAYERDIR', data)
 
         if not data.getVar("BBPATH", True):
             raise SystemExit("The BBPATH variable is not set")
@@ -849,8 +823,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 data.getVar('__BBHANDLERS') or []:
-            bb.event.register(var, data.getVar(var))
+        for var in bb.data.getVar('__BBHANDLERS', data) or []:
+            bb.event.register(var, bb.data.getVar(var, data))
 
         if data.getVar("BB_WORKERCONTEXT", False) is None:
             bb.fetch.fetcher_init(data)
@@ -869,7 +843,7 @@ class BBCooker:
             min_prio = 0
             for c in collection_list:
                 # Get collection priority if defined explicitly
-                priority = self.configuration.data.getVar("BBFILE_PRIORITY_%s" % c, 1)
+                priority = bb.data.getVar("BBFILE_PRIORITY_%s" % c, self.configuration.data, 1)
                 if priority:
                     try:
                         prio = int(priority)
@@ -882,7 +856,7 @@ class BBCooker:
                     collection_priorities[c] = None
 
                 # Check dependencies and store information for priority calculation
-                deps = self.configuration.data.getVar("LAYERDEPENDS_%s" % c, 1)
+                deps = bb.data.getVar("LAYERDEPENDS_%s" % c, self.configuration.data, 1)
                 if deps:
                     depnamelist = []
                     deplist = deps.split()
@@ -901,7 +875,7 @@ class BBCooker:
 
                         if dep in collection_list:
                             if depver:
-                                layerver = self.configuration.data.getVar("LAYERVERSION_%s" % dep, 1)
+                                layerver = bb.data.getVar("LAYERVERSION_%s" % dep, self.configuration.data, 1)
                                 if layerver:
                                     try:
                                         lver = int(layerver)
@@ -934,7 +908,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 = self.configuration.data.getVar("BBFILE_PATTERN_%s" % c, 1)
+                regex = bb.data.getVar("BBFILE_PATTERN_%s" % c, self.configuration.data, 1)
                 if regex == None:
                     parselog.error("BBFILE_PATTERN_%s not defined" % c)
                     continue
@@ -949,9 +923,9 @@ class BBCooker:
         """
         Setup any variables needed before starting a build
         """
-        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()))
+        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)
 
     def matchFiles(self, bf):
         """
@@ -998,7 +972,7 @@ class BBCooker:
         # buildFile() doesn't use the cache
         self.parseConfiguration()
         self.status = bb.cache.CacheData(self.caches_array)
-        self.handleCollections( self.configuration.data.getVar("BBFILE_COLLECTIONS", 1) )
+        self.handleCollections( bb.data.getVar("BBFILE_COLLECTIONS", self.configuration.data, 1) )
 
         # If we are told to do the None task then query the default task
         if (task == None):
@@ -1042,7 +1016,7 @@ class BBCooker:
         taskdata = bb.taskdata.TaskData(self.configuration.abort)
         taskdata.add_provider(self.configuration.data, self.status, item)
 
-        buildname = self.configuration.data.getVar("BUILDNAME")
+        buildname = bb.data.getVar("BUILDNAME", self.configuration.data)
         bb.event.fire(bb.event.BuildStarted(buildname, [item]), self.configuration.event_data)
 
         # Execute the runqueue
@@ -1110,7 +1084,7 @@ class BBCooker:
                 return False
 
             if not retval:
-                bb.event.fire(bb.event.BuildCompleted(buildname, targets, failures), self.configuration.data)
+                bb.event.fire(bb.event.BuildCompleted(buildname, targets, failures), self.configuration.event_data)
                 self.command.finishAsyncCommand()
                 return False
             if retval is True:
@@ -1119,8 +1093,8 @@ class BBCooker:
 
         self.buildSetVars()
 
-        buildname = self.configuration.data.getVar("BUILDNAME")
-        bb.event.fire(bb.event.BuildStarted(buildname, targets), self.configuration.data)
+        buildname = bb.data.getVar("BUILDNAME", self.configuration.data)
+        bb.event.fire(bb.event.BuildStarted(buildname, targets), self.configuration.event_data)
 
         localdata = data.createCopy(self.configuration.data)
         bb.data.update_data(localdata)
@@ -1153,16 +1127,16 @@ class BBCooker:
                 del self.status
             self.status = bb.cache.CacheData(self.caches_array)
 
-            ignore = self.configuration.data.getVar("ASSUME_PROVIDED", 1) or ""
+            ignore = bb.data.getVar("ASSUME_PROVIDED", self.configuration.data, 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( self.configuration.data.getVar("BBFILE_COLLECTIONS", 1) )
+            self.handleCollections( bb.data.getVar("BBFILE_COLLECTIONS", self.configuration.data, 1) )
 
             (filelist, masked) = self.collect_bbfiles()
-            self.configuration.data.renameVar("__depends", "__base_depends")
+            bb.data.renameVar("__depends", "__base_depends", self.configuration.data)
 
             self.parser = CookerParser(self, filelist, masked)
             self.state = state.parsing
@@ -1253,7 +1227,7 @@ class BBCooker:
                     if g not in newfiles:
                         newfiles.append(g)
 
-        bbmask = self.configuration.data.getVar('BBMASK', 1)
+        bbmask = bb.data.getVar('BBMASK', self.configuration.data, 1)
 
         if bbmask:
             try:
@@ -1312,11 +1286,9 @@ 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):
@@ -1328,10 +1300,6 @@ 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

@@ -266,7 +266,7 @@ def emit_func(func, o=sys.__stdout__, d = init()):
         seen |= deps
         newdeps = set()
         for dep in deps:
-            if d.getVarFlag(dep, "func"):
+            if bb.data.getVarFlag(dep, "func", d):
                emit_var(dep, o, d, False) and o.write('\n')
                newdeps |=  bb.codeparser.ShellParser(dep, logger).parse_shell(d.getVar(dep, True))
         newdeps -= seen
@@ -319,7 +319,7 @@ def generate_dependencies(d):
     deps = {}
     values = {}
 
-    tasklist = d.getVar('__BBTASKS') or []
+    tasklist = bb.data.getVar('__BBTASKS', d) or []
     for task in tasklist:
         deps[task], values[task] = build_dependencies(task, keys, shelldeps, vardepvals, d)
         newdeps = deps[task]

bitbake/lib/bb/data_smart.py

@@ -146,7 +146,7 @@ class DataSmart(MutableMapping):
 
         return varparse
 
-    def expand(self, s, varname = None):
+    def expand(self, s, varname):
         return self.expandWithRefs(s, varname).value
 
 
@@ -304,14 +304,6 @@ 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] = {}
@@ -347,14 +339,6 @@ 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,14 +402,6 @@ 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 = d.getVar('BB_SRCREV_POLICY', 1) or "clear"
+    srcrev_policy = bb.data.getVar('BB_SRCREV_POLICY', d, 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 = d.getVar('FILE', 1)
+    fn = bb.data.getVar('FILE', d, 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 d.getVar("BB_STRICT_CHECKSUM", True) == "1":
+        if bb.data.getVar("BB_STRICT_CHECKSUM", d, 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(d.getVar('PREMIRRORS', True))
+            mirrors = mirror_from_string(bb.data.getVar('PREMIRRORS', d, 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(d.getVar('MIRRORS', True))
+                mirrors = mirror_from_string(bb.data.getVar('MIRRORS', d, 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(d.getVar('PREMIRRORS', True))
+        mirrors = mirror_from_string(bb.data.getVar('PREMIRRORS', d, 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(d.getVar('MIRRORS', True))
+                mirrors = mirror_from_string(bb.data.getVar('MIRRORS', d, 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(d.getVar('SRC_URI', 1).split(), d, False)
+    urldata = init(bb.data.getVar('SRC_URI', d, 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 d.getVar('BB_SRCREV_POLICY', True) != "cache":
-        d.setVar('__BB_DONT_CACHE', '1')
+    if bb.data.getVar('BB_SRCREV_POLICY', d, True) != "cache":
+        bb.data.setVar('__BB_DONT_CACHE', '1', d)
 
     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 = d.getVar('SRCREV_FORMAT', 1)
+    format = bb.data.getVar('SRCREV_FORMAT', d, 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 = d.getVarFlag("SRC_URI", self.md5_name)
-        self.sha256_expected = d.getVarFlag("SRC_URI", self.sha256_name)
+        self.md5_expected = bb.data.getVarFlag("SRC_URI", self.md5_name, d)
+        self.sha256_expected = bb.data.getVarFlag("SRC_URI", self.sha256_name, d)
 
         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 = d.getVar('PREMIRRORS', True)
+            premirrors = bb.data.getVar('PREMIRRORS', d, 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 = d.getVar("BB_LOCALCOUNT_OVERRIDE", True) or False
+        uselocalcount = bb.data.getVar("BB_LOCALCOUNT_OVERRIDE", d, 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, d.getVar("PN", True) or "")
+        return "%s-%s" % (key, bb.data.getVar("PN", d, 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 d.getVar("BB_GIT_CLONE_FOR_SRCREV", True):
+        if bb.data.getVar("BB_GIT_CLONE_FOR_SRCREV", d, 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, d.getVar("PN", True) or "")
+        return "%s-%s" % (key, bb.data.getVar("PN", d, 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 = d.getVar("BB_LOCALCOUNT_OVERRIDE", True) or False
+        uselocalcount = bb.data.getVar("BB_LOCALCOUNT_OVERRIDE", d, 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.persist_data, bb.utils
+import bb.data, bb.persist_data, bb.utils
 from bb import data
 
 __version__ = "2"
@@ -93,6 +93,28 @@ 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):
@@ -211,7 +233,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 = d.getVar('BB_SRCREV_POLICY', True) or "clear"
+    srcrev_policy = bb.data.getVar('BB_SRCREV_POLICY', d, 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":
@@ -256,8 +278,8 @@ def verify_checksum(u, ud, d):
     verify the MD5 and SHA256 checksum for downloaded src
 
     return value:
-        - True: a checksum matched
-        - False: neither checksum matched
+        - True: checksum matched
+        - False: checksum unmatched
 
     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
@@ -270,46 +292,20 @@ def verify_checksum(u, ud, d):
     md5data = bb.utils.md5_file(ud.localpath)
     sha256data = bb.utils.sha256_file(ud.localpath)
 
-    # If strict checking enabled and neither sum defined, raise error
-    strict = d.getVar("BB_STRICT_CHECKSUM", True) or None
-    if (strict and ud.md5_expected == None and ud.sha256_expected == None):
-        raise FetchError('No checksum specified for %s, please add at least one to the recipe:\n'
-                         'SRC_URI[%s] = "%s"\nSRC_URI[%s] = "%s"' %
-                         (ud.localpath, ud.md5_name, md5data,
-                         ud.sha256_name, sha256data), u)
-
-    # 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 == 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 ud.md5_expected != md5data:
-        md5mismatch = True
+        raise MD5SumError(ud.localpath, ud.md5_expected, md5data, u)
 
     if ud.sha256_expected != sha256data:
-        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)
-
+        raise SHA256SumError(ud.localpath, ud.sha256_expected, sha256data, u)
 
 def update_stamp(u, ud, d):
     """
@@ -336,8 +332,8 @@ def subprocess_setup():
 
 def get_autorev(d):
     #  only not cache src rev in autorev case
-    if d.getVar('BB_SRCREV_POLICY', True) != "cache":
-        d.setVar('__BB_DONT_CACHE', '1')
+    if bb.data.getVar('BB_SRCREV_POLICY', d, True) != "cache":
+        bb.data.setVar('__BB_DONT_CACHE', '1', d)
     return "AUTOINC"
 
 def get_srcrev(d):
@@ -350,7 +346,7 @@ def get_srcrev(d):
     """
 
     scms = []
-    fetcher = Fetch(d.getVar('SRC_URI', True).split(), d)
+    fetcher = Fetch(bb.data.getVar('SRC_URI', d, True).split(), d)
     urldata = fetcher.ud
     for u in urldata:
         if urldata[u].method.supports_srcrev():
@@ -365,7 +361,7 @@ def get_srcrev(d):
     #
     # Mutiple SCMs are in SRC_URI so we resort to SRCREV_FORMAT
     #
-    format = d.getVar('SRCREV_FORMAT', True)
+    format = bb.data.getVar('SRCREV_FORMAT', d, True)
     if not format:
         raise FetchError("The SRCREV_FORMAT variable must be set when multiple SCMs are used.")
 
@@ -400,7 +396,7 @@ def runfetchcmd(cmd, d, quiet = False, cleanup = []):
                   'GIT_PROXY_IGNORE', 'SOCKS5_USER', 'SOCKS5_PASSWD']
 
     for var in exportvars:
-        val = d.getVar(var, True)
+        val = bb.data.getVar(var, d, True)
         if val:
             cmd = 'export ' + var + '=\"%s\"; %s' % (val, cmd)
 
@@ -440,7 +436,7 @@ def check_network_access(d, info = "", url = None):
     """
     log remote network access, and error if BB_NO_NETWORK is set
     """
-    if d.getVar("BB_NO_NETWORK", True) == "1":
+    if bb.data.getVar("BB_NO_NETWORK", d, True) == "1":
         raise NetworkAccess(url, info)
     else:
         logger.debug(1, "Fetcher accessed the network with the command %s" % info)
@@ -526,15 +522,15 @@ def srcrev_internal_helper(ud, d, name):
         return ud.parm['tag']
 
     rev = None
-    pn = d.getVar("PN", True)
+    pn = bb.data.getVar("PN", d, True)
     if name != '':
-        rev = d.getVar("SRCREV_%s_pn-%s" % (name, pn), True)
+        rev = bb.data.getVar("SRCREV_%s_pn-%s" % (name, pn), d, True)
         if not rev:
-            rev = d.getVar("SRCREV_%s" % name, True)
+            rev = bb.data.getVar("SRCREV_%s" % name, d, True)
     if not rev:
-       rev = d.getVar("SRCREV_pn-%s" % pn, True)
+       rev = bb.data.getVar("SRCREV_pn-%s" % pn, d, True)
     if not rev:
-        rev = d.getVar("SRCREV", True)
+        rev = bb.data.getVar("SRCREV", d, True)
     if rev == "INVALID":
         raise FetchError("Please set SRCREV to a valid value", ud.url)
     if rev == "AUTOINC":
@@ -569,14 +565,8 @@ class FetchData(object):
         else:
             self.md5_name = "md5sum"
             self.sha256_name = "sha256sum"
-        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.md5_expected = bb.data.getVarFlag("SRC_URI", self.md5_name, d)
+        self.sha256_expected = bb.data.getVarFlag("SRC_URI", self.sha256_name, d)
 
         self.names = self.parm.get("name",'default').split(',')
 
@@ -600,7 +590,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 = d.expand("${DL_DIR}/%s" % os.path.basename(self.localpath or self.basename))
+        basepath = bb.data.expand("${DL_DIR}/%s" % os.path.basename(self.localpath or self.basename), d)
         self.donestamp = basepath + '.done'
         self.lockfile = basepath + '.lock'
 
@@ -626,12 +616,12 @@ class FetchData(object):
         if "srcdate" in self.parm:
             return self.parm['srcdate']
 
-        pn = d.getVar("PN", True)
+        pn = bb.data.getVar("PN", d, True)
 
         if pn:
-            return d.getVar("SRCDATE_%s" % pn, True) or d.getVar("SRCDATE", True) or d.getVar("DATE", True)
+            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", True) or d.getVar("DATE", True)
+        return bb.data.getVar("SRCDATE", d, True) or bb.data.getVar("DATE", d, True)
 
 class FetchMethod(object):
     """Base class for 'fetch'ing data"""
@@ -703,7 +693,7 @@ class FetchMethod(object):
 
         dots = file.split(".")
         if dots[-1] in ['gz', 'bz2', 'Z']:
-            efile = os.path.join(data.getVar('WORKDIR', True),os.path.basename('.'.join(dots[0:-1])))
+            efile = os.path.join(bb.data.getVar('WORKDIR', data, True),os.path.basename('.'.join(dots[0:-1])))
         else:
             efile = file
         cmd = None
@@ -747,7 +737,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(data.getVar("FILESDIR", True))
+                    filesdir = os.path.realpath(bb.data.getVar("FILESDIR", data, True))
                     destdir = "."
                     if file[0:len(filesdir)] == filesdir:
                         destdir = file[len(filesdir):file.rfind('/')]
@@ -779,7 +769,7 @@ class FetchMethod(object):
             bb.utils.mkdirhier(newdir)
             os.chdir(newdir)
 
-        cmd = "PATH=\"%s\" %s" % (data.getVar('PATH', True), cmd)
+        cmd = "PATH=\"%s\" %s" % (bb.data.getVar('PATH', data, True), cmd)
         bb.note("Unpacking %s to %s/" % (file, os.getcwd()))
         ret = subprocess.call(cmd, preexec_fn=subprocess_setup, shell=True)
 
@@ -824,10 +814,10 @@ class FetchMethod(object):
 
         localcount = None
         if name != '':
-            pn = d.getVar("PN", True)
-            localcount = d.getVar("LOCALCOUNT_" + name, True)
+            pn = bb.data.getVar("PN", d, True)
+            localcount = bb.data.getVar("LOCALCOUNT_" + name, d, True)
         if not localcount:
-            localcount = d.getVar("LOCALCOUNT", True)
+            localcount = bb.data.getVar("LOCALCOUNT", d, True)
         return localcount
 
     localcount_internal_helper = staticmethod(localcount_internal_helper)
@@ -859,7 +849,7 @@ class FetchMethod(object):
 
         latest_rev = self._build_revision(url, ud, d, name)
         last_rev = localcounts.get(key + '_rev')
-        uselocalcount = d.getVar("BB_LOCALCOUNT_OVERRIDE", True) or False
+        uselocalcount = bb.data.getVar("BB_LOCALCOUNT_OVERRIDE", d, True) or False
         count = None
         if uselocalcount:
             count = FetchMethod.localcount_internal_helper(ud, d, name)
@@ -887,7 +877,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, d.getVar("PN", True) or "")
+        return "%s-%s" % (key, bb.data.getVar("PN", d, True) or "")
 
 class Fetch(object):
     def __init__(self, urls, d, cache = True):
@@ -897,7 +887,7 @@ class Fetch(object):
         self.d = d
         self.ud = {}
 
-        fn = d.getVar('FILE', True)
+        fn = bb.data.getVar('FILE', d, True)
         if cache and fn in urldata_cache:
             self.ud = urldata_cache[fn]
 
@@ -913,7 +903,7 @@ class Fetch(object):
             self.ud[url] = FetchData(url, self.d)
 
         self.ud[url].setup_localpath(self.d)
-        return self.d.expand(self.ud[url].localpath)
+        return bb.data.expand(self.ud[url].localpath, self.d)
 
     def localpaths(self):
         """
@@ -935,8 +925,8 @@ class Fetch(object):
         if len(urls) == 0:
             urls = self.urls
 
-        network = self.d.getVar("BB_NO_NETWORK", True)
-        premirroronly = (self.d.getVar("BB_FETCH_PREMIRRORONLY", True) == "1")
+        network = bb.data.getVar("BB_NO_NETWORK", self.d, True)
+        premirroronly = (bb.data.getVar("BB_FETCH_PREMIRRORONLY", self.d, True) == "1")
 
         for u in urls:
             ud = self.ud[u]
@@ -947,17 +937,17 @@ class Fetch(object):
             lf = bb.utils.lockfile(ud.lockfile)
 
             try:
-                self.d.setVar("BB_NO_NETWORK", network)
+                bb.data.setVar("BB_NO_NETWORK", network, self.d)
  
                 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(self.d.getVar('PREMIRRORS', True))
+                    mirrors = mirror_from_string(bb.data.getVar('PREMIRRORS', self.d, True))
                     localpath = try_mirrors(self.d, ud, mirrors, False)
 
                 if premirroronly:
-                    self.d.setVar("BB_NO_NETWORK", "1")
+                    bb.data.setVar("BB_NO_NETWORK", "1", self.d)
 
                 if not localpath and m.need_update(u, ud, self.d):
                     try:
@@ -979,7 +969,7 @@ class Fetch(object):
                         if os.path.isfile(ud.localpath):
                             bb.utils.remove(ud.localpath)
                         logger.debug(1, "Trying MIRRORS")
-                        mirrors = mirror_from_string(self.d.getVar('MIRRORS', True))
+                        mirrors = mirror_from_string(bb.data.getVar('MIRRORS', self.d, True))
                         localpath = try_mirrors (self.d, ud, mirrors)
 
                 if not localpath or ((not os.path.exists(localpath)) and localpath.find("*") == -1):
@@ -1004,7 +994,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(self.d.getVar('PREMIRRORS', True))
+            mirrors = mirror_from_string(bb.data.getVar('PREMIRRORS', self.d, True))
             ret = try_mirrors(self.d, ud, mirrors, True)
             if not ret:
                 # Next try checking from the original uri, u
@@ -1012,7 +1002,7 @@ class Fetch(object):
                     ret = m.checkstatus(u, ud, self.d)
                 except:
                     # Finally, try checking uri, u, from MIRRORS
-                    mirrors = mirror_from_string(self.d.getVar('MIRRORS', True))
+                    mirrors = mirror_from_string(bb.data.getVar('MIRRORS', self.d, True))
                     ret = try_mirrors (self.d, ud, mirrors, True)
 
             if not ret:
@@ -1030,7 +1020,7 @@ class Fetch(object):
             ud = self.ud[u]
             ud.setup_localpath(self.d)
 
-            if self.d.expand(self.localpath) is None:
+            if bb.data.expand(self.localpath, self.d) 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 d.getVar("BB_GIT_CLONE_FOR_SRCREV", True):
+        if bb.data.getVar("BB_GIT_CLONE_FOR_SRCREV", d, 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.replace(':','.'), ud.path.replace('/', '.'))
+        gitsrcname = '%s%s' % (ud.host, 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 d.getVar("BB_FETCH_PREMIRRORONLY", True) is not None:
+        if bb.data.getVar("BB_FETCH_PREMIRRORONLY", d, True) is not None:
             return True
         if os.path.exists(ud.clonedir):
             return False
@@ -220,7 +220,7 @@ class Git(FetchMethod):
         if os.path.exists(destdir):
             bb.utils.prunedir(destdir)
 
-        runfetchcmd("git clone -s -n %s %s" % (ud.clonedir, destdir), d)
+        runfetchcmd("git clone -s -n %s/ %s" % (ud.clonedir, destdir), d)
         if not ud.nocheckout:
             os.chdir(destdir)
             if subdir != "":

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 = d.getVar('__depends') or set()
+    deps = bb.data.getVar('__depends', d) or set()
     deps.update([(f, cached_mtime(f))])
-    d.setVar('__depends', deps)
+    bb.data.setVar('__depends', deps, d)
 
 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 = d.getVar("BBPATH", True)
+        bbpath = bb.data.getVar("BBPATH", d, 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 = data.expand(self.what_file)
+        s = bb.data.expand(self.what_file, data)
         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):
-        data.setVarFlag(self.var, "export", 1)
+        bb.data.setVarFlag(self.var, "export", 1, data)
 
 class DataNode(AstNode):
     """
@@ -92,7 +92,7 @@ class DataNode(AstNode):
         groupd = self.groupd
         key = groupd["var"]
         if "exp" in groupd and groupd["exp"] != None:
-            data.setVarFlag(key, "export", 1)
+            bb.data.setVarFlag(key, "export", 1, data)
         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 = e.expand(groupd["value"], key + "[:=]")
+            val = bb.data.expand(groupd["value"], e, 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:
-            data.setVarFlag(key, groupd['flag'], val)
+            bb.data.setVarFlag(key, groupd['flag'], val, data)
         elif groupd["lazyques"]:
-            data.setVarFlag(key, "defaultval", val)
+            bb.data.setVarFlag(key, "defaultval", val, data)
         else:
-            data.setVar(key, val)
+            bb.data.setVar(key, val, data)
 
 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 = data.getVar('__BBANONFUNCS') or []
+            anonfuncs = bb.data.getVar('__BBANONFUNCS', data) or []
             anonfuncs.append(funcname)
-            data.setVar('__BBANONFUNCS', anonfuncs)
+            bb.data.setVar('__BBANONFUNCS', anonfuncs, data)
         else:
-            data.setVarFlag(self.func_name, "func", 1)
-            data.setVar(self.func_name, '\n'.join(self.body))
+            bb.data.setVarFlag(self.func_name, "func", 1, data)
+            bb.data.setVar(self.func_name, '\n'.join(self.body), data)
 
 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)
-        data.setVarFlag(self.function, "func", 1)
-        data.setVarFlag(self.function, "python", 1)
-        data.setVar(self.function, text)
+        bb.data.setVarFlag(self.function, "func", 1, data)
+        bb.data.setVarFlag(self.function, "python", 1, data)
+        bb.data.setVar(self.function, text, data)
 
 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 data.getVar(self.key):
+        if bb.data.getVar(self.key, data):
             # clean up old version of this piece of metadata, as its
             # flags could cause problems
-            data.setVarFlag(self.key, 'python', None)
-            data.setVarFlag(self.key, 'fakeroot', None)
+            bb.data.setVarFlag(self.key, 'python', None, data)
+            bb.data.setVarFlag(self.key, 'fakeroot', None, data)
         if self.m.group("py") is not None:
-            data.setVarFlag(self.key, "python", "1")
+            bb.data.setVarFlag(self.key, "python", "1", data)
         else:
-            data.delVarFlag(self.key, "python")
+            bb.data.delVarFlag(self.key, "python", data)
         if self.m.group("fr") is not None:
-            data.setVarFlag(self.key, "fakeroot", "1")
+            bb.data.setVarFlag(self.key, "fakeroot", "1", data)
         else:
-            data.delVarFlag(self.key, "fakeroot")
+            bb.data.delVarFlag(self.key, "fakeroot", data)
 
 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 data.getVar(var) and not data.getVarFlag(var, 'export_func'):
+                if bb.data.getVar(var, data) and not bb.data.getVarFlag(var, 'export_func', data):
                     continue
 
-                if data.getVar(var):
-                    data.setVarFlag(var, 'python', None)
-                    data.setVarFlag(var, 'func', None)
+                if bb.data.getVar(var, data):
+                    bb.data.setVarFlag(var, 'python', None, data)
+                    bb.data.setVarFlag(var, 'func', None, data)
 
                 for flag in [ "func", "python" ]:
-                    if data.getVarFlag(calledvar, flag):
-                        data.setVarFlag(var, flag, data.getVarFlag(calledvar, flag))
+                    if bb.data.getVarFlag(calledvar, flag, data):
+                        bb.data.setVarFlag(var, flag, bb.data.getVarFlag(calledvar, flag, data), data)
                 for flag in [ "dirs" ]:
-                    if data.getVarFlag(var, flag):
-                        data.setVarFlag(calledvar, flag, data.getVarFlag(var, flag))
+                    if bb.data.getVarFlag(var, flag, data):
+                        bb.data.setVarFlag(calledvar, flag, bb.data.getVarFlag(var, flag, data), data)
 
-                if data.getVarFlag(calledvar, "python"):
-                    data.setVar(var, "\tbb.build.exec_func('" + calledvar + "', d)\n")
+                if bb.data.getVarFlag(calledvar, "python", data):
+                    bb.data.setVar(var, "\tbb.build.exec_func('" + calledvar + "', d)\n", data)
                 else:
-                    data.setVar(var, "\t" + calledvar + "\n")
-                data.setVarFlag(var, 'export_func', '1')
+                    bb.data.setVar(var, "\t" + calledvar + "\n", data)
+                bb.data.setVarFlag(var, 'export_func', '1', data)
 
 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
 
-        data.setVarFlag(var, "task", 1)
-        bbtasks = data.getVar('__BBTASKS') or []
+        bb.data.setVarFlag(var, "task", 1, data)
+        bbtasks = bb.data.getVar('__BBTASKS', data) or []
         if not var in bbtasks:
             bbtasks.append(var)
-        data.setVar('__BBTASKS', bbtasks)
+        bb.data.setVar('__BBTASKS', bbtasks, data)
 
-        existing = data.getVarFlag(var, "deps") or []
+        existing = bb.data.getVarFlag(var, "deps", data) 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)
-        data.setVarFlag(var, "deps", existing)
+        bb.data.setVarFlag(var, "deps", existing, data)
         if self.before is not None:
             # set up things that depend on this func
             for entry in self.before.split():
-                existing = data.getVarFlag(entry, "deps") or []
+                existing = bb.data.getVarFlag(entry, "deps", data) or []
                 if var not in existing:
-                    data.setVarFlag(entry, "deps", [var] + existing)
+                    bb.data.setVarFlag(entry, "deps", [var] + existing, data)
 
 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 = data.getVar('__BBHANDLERS') or []
+        bbhands = bb.data.getVar('__BBHANDLERS', data) or []
         for h in self.hs:
             bbhands.append(h)
-            data.setVarFlag(h, "handler", 1)
-        data.setVar('__BBHANDLERS', bbhands)
+            bb.data.setVarFlag(h, "handler", 1, data)
+        bb.data.setVar('__BBHANDLERS', bbhands, data)
 
 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 d.getVar('__BBHANDLERS') or []:
+    for var in bb.data.getVar('__BBHANDLERS', d) or []:
         # try to add the handler
-        handler = d.getVar(var)
+        handler = bb.data.getVar(var, d)
         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 d.getVar("__BBANONFUNCS") or []:
+    for funcname in bb.data.getVar("__BBANONFUNCS", d) or []:
         code.append("%s(d)" % funcname)
     bb.utils.simple_exec("\n".join(code), {"d": d})
     bb.data.update_data(d)
 
-    tasklist = d.getVar('__BBTASKS') or []
+    tasklist = bb.data.getVar('__BBTASKS', d) 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:
-        d.setVar("__SKIPPED", e.args[0])
+        bb.data.setVar("__SKIPPED", e.args[0], d)
     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:
-                d.setVar("__SKIPPED", e.args[0])
+                bb.data.setVar("__SKIPPED", e.args[0], d)
 
         _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:
-                variant_d.setVar("__SKIPPED", e.args[0])
+                bb.data.setVar("__SKIPPED", e.args[0], variant_d)
 
     if len(datastores) > 1:
         variants = filter(None, datastores.iterkeys())

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

@@ -159,7 +159,7 @@ def handle(fn, d, include):
             return ast.multi_finalize(fn, d)
 
     if oldfile:
-        d.setVar("FILE", oldfile)
+        bb.data.setVar("FILE", oldfile, d)
 
     # we have parsed the bb class now
     if ext == ".bbclass" or ext == ".inc":
@@ -193,6 +193,7 @@ 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, os
+import re, bb.data, 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 = data.getVar('TOPDIR')
+    topdir = bb.data.getVar('TOPDIR', data)
     if not topdir:
-        data.setVar('TOPDIR', os.getcwd())
+        bb.data.setVar('TOPDIR', os.getcwd(), data)
 
 
 def supports(fn, d):
@@ -53,12 +53,12 @@ def include(oldfn, fn, data, error_out):
         return None
 
     import bb
-    fn = data.expand(fn)
-    oldfn = data.expand(oldfn)
+    fn = bb.data.expand(fn, data)
+    oldfn = bb.data.expand(oldfn, data)
 
     if not os.path.isabs(fn):
         dname = os.path.dirname(oldfn)
-        bbpath = "%s:%s" % (dname, data.getVar("BBPATH", 1))
+        bbpath = "%s:%s" % (dname, bb.data.getVar("BBPATH", data, 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 = data.getVar('FILE')
+        oldfile = bb.data.getVar('FILE', data)
 
     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
-    data.setVar('FILE', abs_fn)
+    bb.data.setVar('FILE', abs_fn, data)
     statements.eval(data)
     if oldfile:
-        data.setVar('FILE', oldfile)
+        bb.data.setVar('FILE', oldfile, data)
 
     return data
 

bitbake/lib/bb/persist_data.py

@@ -47,9 +47,10 @@ if hasattr(sqlite3, 'enable_shared_cache'):
 @total_ordering
 class SQLTable(collections.MutableMapping):
     """Object representing a table/domain in the database"""
-    def __init__(self, cursor, table):
-        self.cursor = cursor
+    def __init__(self, cachefile, table):
+        self.cachefile = cachefile
         self.table = table
+        self.cursor = connect(self.cachefile)
 
         self._execute("CREATE TABLE IF NOT EXISTS %s(key TEXT, value TEXT);"
                       % table)
@@ -63,6 +64,8 @@ class SQLTable(collections.MutableMapping):
             except sqlite3.OperationalError as exc:
                 if 'database is locked' in str(exc) and count < 500:
                     count = count + 1
+                    self.cursor.close()
+                    self.cursor = connect(self.cachefile)
                     continue
                 raise
 
@@ -188,18 +191,17 @@ class PersistData(object):
         del self.data[domain][key]
 
 def connect(database):
-    return sqlite3.connect(database, timeout=30, isolation_level=None)
+    return sqlite3.connect(database, timeout=5, isolation_level=None)
 
 def persist(domain, d):
     """Convenience factory for SQLTable objects based upon metadata"""
-    import bb.utils
-    cachedir = (d.getVar("PERSISTENT_DIR", True) or
-                d.getVar("CACHE", True))
+    import bb.data, bb.utils
+    cachedir = (bb.data.getVar("PERSISTENT_DIR", d, True) or
+                bb.data.getVar("CACHE", d, True))
     if not cachedir:
         logger.critical("Please set the 'PERSISTENT_DIR' or 'CACHE' variable")
         sys.exit(1)
 
     bb.utils.mkdirhier(cachedir)
     cachefile = os.path.join(cachedir, "bb_persist_data.sqlite3")
-    connection = connect(cachefile)
-    return SQLTable(connection, domain)
+    return SQLTable(cachefile, domain)

bitbake/lib/bb/providers.py

@@ -28,10 +28,10 @@ import bb
 
 logger = logging.getLogger("BitBake.Provider")
 
-class NoProvider(bb.BBHandledException):
+class NoProvider(Exception):
     """Exception raised when no provider of a build dependency can be found"""
 
-class NoRProvider(bb.BBHandledException):
+class NoRProvider(Exception):
     """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)
-    localdata.setVar('OVERRIDES', "%s:pn-%s:%s" % (data.getVar('OVERRIDES', localdata), pn, pn))
+    bb.data.setVar('OVERRIDES', "%s:pn-%s:%s" % (data.getVar('OVERRIDES', localdata), pn, pn), localdata)
     bb.data.update_data(localdata)
 
-    preferred_v = localdata.getVar('PREFERRED_VERSION', True)
+    preferred_v = bb.data.getVar('PREFERRED_VERSION', localdata, 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 = cfgData.getVar('PREFERRED_PROVIDER_%s' % item, 1)
+    prefervar = bb.data.getVar('PREFERRED_PROVIDER_%s' % item, cfgData, 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 = cfgData.getVar('PREFERRED_PROVIDER_%s' % provide, 1)
+            prefervar = bb.data.getVar('PREFERRED_PROVIDER_%s' % provide, cfgData, 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 = cfgData.getVar("BB_STAMP_WHITELIST", 1) or ""
-        self.multi_provider_whitelist = (cfgData.getVar("MULTI_PROVIDER_WHITELIST", 1) or "").split()
+        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.reset()
 
@@ -765,9 +765,8 @@ class RunQueue:
         self.cfgData = cfgData
         self.rqdata = RunQueueData(self, cooker, cfgData, dataCache, taskData, targets)
 
-        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.stamppolicy = bb.data.getVar("BB_STAMP_POLICY", cfgData, True) or "perfile"
+        self.hashvalidate = bb.data.getVar("BB_HASHCHECK_FUNCTION", cfgData, True) or None
 
         self.state = runQueuePrepare
 
@@ -1007,8 +1006,8 @@ class RunQueueExecute:
         self.cfgData = rq.cfgData
         self.rqdata = rq.rqdata
 
-        self.number_tasks = int(self.cfgData.getVar("BB_NUMBER_THREADS", 1) or 1)
-        self.scheduler = self.cfgData.getVar("BB_SCHEDULER", 1) or "speed"
+        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.runq_buildable = []
         self.runq_running = []
@@ -1097,12 +1096,6 @@ 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()
@@ -1132,9 +1125,9 @@ class RunQueueExecute:
             if umask:
                 os.umask(umask)
 
-            self.cooker.configuration.data.setVar("BB_WORKERCONTEXT", "1")
-            self.cooker.configuration.data.setVar("__RUNQUEUE_DO_NOT_USE_EXTERNALLY", self)
-            self.cooker.configuration.data.setVar("__RUNQUEUE_DO_NOT_USE_EXTERNALLY2", fn)
+            bb.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)
             bb.parse.siggen.set_taskdata(self.rqdata.hashes, self.rqdata.hash_deps)
             ret = 0
             try:
@@ -1209,34 +1202,33 @@ class RunQueueExecuteTasks(RunQueueExecute):
             for task in xrange(self.stats.total):
                 if task in self.rq.scenequeue_covered:
                     continue
-                logger.debug(1, 'Considering %s (%s): %s' % (task, self.rqdata.get_user_idstring(task), str(self.rqdata.runq_revdeps[task])))
-
                 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
+        # 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.
         covered_remove = set()
-        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 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
 
         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 due to setsceneverify', task)
+            logger.debug(1, 'Not skipping task %s because it will have to be run anyway', task)
             self.rq.scenequeue_covered.remove(task)
 
         logger.debug(1, 'Full skip list %s', self.rq.scenequeue_covered)
@@ -1259,7 +1251,7 @@ class RunQueueExecuteTasks(RunQueueExecute):
                              if type(obj) is type and
                                 issubclass(obj, RunQueueScheduler))
 
-        user_schedulers = self.cfgData.getVar("BB_SCHEDULERS", True)
+        user_schedulers = bb.data.getVar("BB_SCHEDULERS", self.cfgData, True)
         if user_schedulers:
             for sched in user_schedulers.split():
                 if not "." in sched:
@@ -1429,18 +1421,20 @@ class RunQueueExecuteScenequeue(RunQueueExecute):
             sq_revdeps.append(copy.copy(self.rqdata.runq_revdeps[task]))
             sq_revdeps_new.append(set())
             if (len(self.rqdata.runq_revdeps[task]) == 0) and task not in self.rqdata.runq_setscene:
-                endpoints[task] = None
+                endpoints[task] = set()
 
         for task in self.rqdata.runq_setscene:
             for dep in self.rqdata.runq_depends[task]:
-                    endpoints[dep] = task
+                    if dep not in endpoints:
+                        endpoints[dep] = set()
+                    endpoints[dep].add(task)
 
         def process_endpoints(endpoints):
             newendpoints = {}
             for point, task in endpoints.items():
                 tasks = set()
                 if task:
-                    tasks.add(task)
+                    tasks |= task
                 if sq_revdeps_new[point]:
                     tasks |= sq_revdeps_new[point]
                 sq_revdeps_new[point] = set()
@@ -1465,6 +1459,28 @@ class RunQueueExecuteScenequeue(RunQueueExecute):
             elif len(sq_revdeps_new[task]) != 0:
                 bb.msg.fatal("RunQueue", "Something went badly wrong during scenequeue generation, aborting. Please report this problem.")
 
+        # Resolve setscene inter-task dependencies
+        # e.g. do_sometask_setscene[depends] = "targetname:do_someothertask_setscene"
+        # Note that anything explicitly depended upon will have its reverse dependencies removed to avoid circular dependencies
+        for task in self.rqdata.runq_setscene:
+                realid = self.rqdata.taskData.gettask_id(self.rqdata.taskData.fn_index[self.rqdata.runq_fnid[task]], self.rqdata.runq_task[task] + "_setscene", False)
+                idepends = self.rqdata.taskData.tasks_idepends[realid]
+                for (depid, idependtask) in idepends:
+                    if depid not in self.rqdata.taskData.build_targets:
+                        continue
+
+                    depdata = self.rqdata.taskData.build_targets[depid][0]
+                    if depdata is None:
+                         continue
+                    dep = self.rqdata.taskData.fn_index[depdata]
+                    taskid = self.rqdata.get_task_id(self.rqdata.taskData.getfn_id(dep), idependtask.replace("_setscene", ""))
+                    if taskid is None:
+                        bb.msg.fatal("RunQueue", "Task %s depends upon nonexistant task %s:%s" % (self.rqdata.taskData.tasks_name[realid], dep, idependtask))
+
+                    sq_revdeps_squash[self.rqdata.runq_setscene.index(task)].add(self.rqdata.runq_setscene.index(taskid))
+                    # Have to zero this to avoid circular dependencies
+                    sq_revdeps_squash[self.rqdata.runq_setscene.index(taskid)] = set()
+
         #for task in xrange(len(sq_revdeps_squash)):
         #    print "Task %s: %s.%s is %s " % (task, self.taskData.fn_index[self.runq_fnid[self.runq_setscene[task]]], self.runq_task[self.runq_setscene[task]] + "_setscene", sq_revdeps_squash[task])
 
@@ -1706,8 +1722,8 @@ class runQueueTaskCompleted(runQueueEvent):
     """
 
 def check_stamp_fn(fn, taskname, d):
-    rqexe = d.getVar("__RUNQUEUE_DO_NOT_USE_EXTERNALLY")
-    fn = d.getVar("__RUNQUEUE_DO_NOT_USE_EXTERNALLY2")
+    rqexe = bb.data.getVar("__RUNQUEUE_DO_NOT_USE_EXTERNALLY", d)
+    fn = bb.data.getVar("__RUNQUEUE_DO_NOT_USE_EXTERNALLY2", d)
     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, host, port):
-        self.host = host
-        self.port = port
+    def __init__(self, server):
+        self.host = server.host
+        self.port = server.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.host, self.server.port)
+        self.serverinfo = BitbakeServerInfo(self.server)
 
     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 = d.getVar("BB_SIGNATURE_HANDLER", True) or "noop"
+    desired = bb.data.getVar("BB_SIGNATURE_HANDLER", d, True) or "noop"
     for sg in siggens:
         if desired == sg.name:
             return sg(d)

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

@@ -58,7 +58,7 @@ class Configurator(gobject.GObject):
 
     def _loadConf(self, path):
         def getString(var):
-            return data.getVar(var, True) or ""
+            return bb.data.getVar(var, data, 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 = (data.getVar('BBLAYERS', True) or "").split()
+        layers = (bb.data.getVar('BBLAYERS', data, 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/knotty.py

@@ -69,7 +69,6 @@ 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()
 
@@ -78,11 +77,6 @@ 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"])
@@ -105,8 +99,6 @@ def main(server, eventHandler):
     cacheprogress = None
     shutdown = 0
     return_value = 0
-    errors = 0
-    warnings = 0
     while True:
         try:
             event = eventHandler.waitEvent(0.25)
@@ -125,15 +117,13 @@ 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
 
@@ -212,7 +202,6 @@ def main(server, eventHandler):
                 continue
             if isinstance(event, bb.event.NoProvider):
                 return_value = 1
-                errors = errors + 1
                 if event._runtime:
                     r = "R"
                 else:
@@ -272,8 +261,4 @@ 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

@@ -562,7 +562,7 @@ def filter_environment(good_vars):
 
 def create_interactive_env(d):
     for k in preserved_envvars_exported_interactive():
-        os.setenv(k, d.getVar(k, True))
+        os.setenv(k, bb.data.getVar(k, d, True))
 
 def approved_variables():
     """
@@ -601,9 +601,9 @@ def build_environment(d):
     """
     import bb.data
     for var in bb.data.keys(d):
-        export = d.getVarFlag(var, "export")
+        export = bb.data.getVarFlag(var, "export", d)
         if export:
-            os.environ[var] = d.getVar(var, True) or ""
+            os.environ[var] = bb.data.getVar(var, d, True) or ""
 
 def remove(path, recurse=False):
     """Equivalent to rm -f or rm -rf"""

bitbake/lib/prserv/__init__.py

@@ -7,8 +7,5 @@ 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)
-    FORMAT = '%(asctime)-15s %(message)s'
-    logging.basicConfig(level=numeric_level, filename=logfile, format=FORMAT)
+    logging.basicConfig(level=numeric_level, filename=logfile)
 
-class NotFoundError(StandardError):
-    pass

bitbake/lib/prserv/db.py

@@ -1,233 +1,86 @@
 import logging
 import os.path
 import errno
-import prserv
+import sys
+import warnings
+import sqlite3
 
 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 PRTable():
-    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 
+class NotFoundError(StandardError):
+    pass
 
+class PRTable():
+    def __init__(self,cursor,table):
+        self.cursor = cursor
+        self.table = 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, pkgarch, checksum));" % self.table)
+                    PRIMARY KEY (version,checksum));"
+                      % table)
 
     def _execute(self, *query):
         """Execute a query, waiting to acquire a lock if necessary"""
         count = 0
         while True:
             try:
-                return self.conn.execute(*query)
+                return self.cursor.execute(*query)
             except sqlite3.OperationalError as exc:
                 if 'database is locked' in str(exc) and count < 500:
                     count = count + 1
                     continue
-                raise exc
+                raise
+            except sqlite3.IntegrityError as exc:
+                print "Integrity error %s" % str(exc)
+                break
 
-    def _getValueHist(self, version, pkgarch, checksum):
-        data=self._execute("SELECT value FROM %s WHERE version=? AND pkgarch=? AND checksum=?;" % self.table,
-                           (version, pkgarch, checksum))
+    def getValue(self, version, checksum):
+        data=self._execute("SELECT value FROM %s WHERE version=? AND checksum=?;" % self.table,
+                           (version,checksum))
         row=data.fetchone()
         if row != None:
             return row[0]
         else:
             #no value found, try to insert
-            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._execute("INSERT INTO %s VALUES (?, ?, (select ifnull(max(value)+1,0) from %s where version=?));" 
                            % (self.table,self.table),
-                           (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))
+                           (version,checksum,version))
+            data=self._execute("SELECT value FROM %s WHERE version=? AND checksum=?;" % self.table,
+                               (version,checksum))
             row=data.fetchone()
             if row != None:
                 return row[0]
             else:
-                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)
+                raise NotFoundError
 
 class PRData(object):
     """Object representing the PR database"""
-    def __init__(self, filename, nohist=True):
+    def __init__(self, filename):
         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, isolation_level="DEFERRED")
-        self.connection.row_factory=sqlite3.Row
+        self.connection=sqlite3.connect(self.filename, timeout=5,
+                                          isolation_level=None)
+        self.cursor=self.connection.cursor()
         self._tables={}
 
     def __del__(self):
+        print "PRData: closing DB %s" % self.filename
         self.connection.close()
 
     def __getitem__(self,tblname):
@@ -237,11 +90,11 @@ class PRData(object):
         if tblname in self._tables:
             return self._tables[tblname]
         else:
-            tableobj = self._tables[tblname] = PRTable(self.connection, tblname, self.nohist)
+            tableobj = self._tables[tblname] = PRTable(self.cursor, tblname)
             return tableobj
 
     def __delitem__(self, tblname):
         if tblname in self._tables:
             del self._tables[tblname]
-        logger.info("drop table %s" % (tblname))
-        self.connection.execute("DROP TABLE IF EXISTS %s;" % tblname) 
+        logging.info("drop table %s" % (tblname))
+        self.cursor.execute("DROP TABLE IF EXISTS %s;" % tblname) 

bitbake/lib/prserv/serv.py

@@ -1,5 +1,5 @@
 import os,sys,logging
-import signal, time, atexit, threading
+import signal,time, atexit
 from SimpleXMLRPCServer import SimpleXMLRPCServer, SimpleXMLRPCRequestHandler
 import xmlrpclib,sqlite3
 
@@ -7,8 +7,6 @@ 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)
@@ -23,10 +21,8 @@ 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,
@@ -35,88 +31,66 @@ 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 getinfo(self):
-        return (self.host, self.port)
-
-    def getPR(self, version, pkgarch, checksum):
+ 
+    def getPR(self, version, checksum):
         try:
-            return self.table.getValue(version, pkgarch, checksum)
+            return self.table.getValue(version,checksum)
         except prserv.NotFoundError:
-            logger.error("can not find value for (%s, %s)",version, checksum)
+            logging.error("can not find value for (%s, %s)",version,checksum)
             return None
         except sqlite3.Error as exc:
-            logger.error(str(exc))
+            logging.error(str(exc))
             return None
 
     def quit(self):
         self.quit=True
         return
 
-    def work_forever(self,):
+    def _serve_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()
 
-        logger.info("PRServer: stopping...")
+        logging.info("PRServer: stopping...")
         self.server_close()
         return
 
     def start(self):
         if self.daemon is True:
-            logger.info("PRServer: try to start daemon...")
+            logging.info("PRServer: starting daemon...")
             self.daemonize()
         else:
-            atexit.register(self.delpid)
-            pid = str(os.getpid()) 
-            pf = file(self.pidfile, 'w+')
-            pf.write("%s\n" % pid)
-            pf.close()
-            self.work_forever()
+            logging.info("PRServer: starting...")
+            self._serve_forever()
 
     def delpid(self):
-        os.remove(self.pidfile)
+        os.remove(PRServer.pidfile)
 
     def daemonize(self):
         """
         See Advanced Programming in the UNIX, Sec 13.3
         """
+        os.umask(0)
+
         try:
             pid = os.fork()
-            if pid > 0:
-                #parent return instead of exit to give control 
-                return
+            if pid > 0: 
+                sys.exit(0)
         except OSError as e:
-            raise Exception("%s [%d]" % (e.strerror, e.errno))
+            sys.stderr.write("1st fork failed: %d %s\n" % (e.errno, e.strerror))
+            sys.exit(1)
 
         os.setsid()
         """
@@ -128,9 +102,9 @@ class PRServer(SimpleXMLRPCServer):
             if pid > 0: #parent
                 sys.exit(0)
         except OSError as e:
-            raise Exception("%s [%d]" % (e.strerror, e.errno))
+            sys.stderr.write("2nd fork failed: %d %s\n" % (e.errno, e.strerror))
+            sys.exit(1)
 
-        os.umask(0)
         os.chdir("/")
 
         sys.stdout.flush()
@@ -145,44 +119,19 @@ class PRServer(SimpleXMLRPCServer):
         # write pidfile
         atexit.register(self.delpid)
         pid = str(os.getpid()) 
-        pf = file(self.pidfile, 'w')
+        pf = file(PRServer.pidfile, 'w+')
         pf.write("%s\n" % pid)
+        pf.write("%s\n" % self.host)
+        pf.write("%s\n" % self.port)
         pf.close()
 
-        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)
+        self._serve_forever()
 
 class PRServerConnection():
     def __init__(self, host, port):
-        if is_local_special(host, port):
-            host, port = singleton.getinfo()
+        self.connection = bb.server.xmlrpc._create_server(host, port)
         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
@@ -190,25 +139,18 @@ class PRServerConnection():
         socket.setdefaulttimeout(2)
         try:
             self.connection.quit()
-        except Exception as exc:
-            sys.stderr.write("%s\n" % str(exc))
+        except:
+            pass
 
-    def getPR(self, version, pkgarch, checksum):
-        return self.connection.getPR(version, pkgarch, checksum)
+    def getPR(self, version, checksum):
+        return self.connection.getPR(version, checksum)
 
     def ping(self):
         return self.connection.ping()
 
-    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)
+def start_daemon(options):
     try:
-        pf = file(pidfile,'r')
+        pf = file(PRServer.pidfile,'r')
         pid = int(pf.readline().strip())
         pf.close()
     except IOError:
@@ -216,89 +158,41 @@ def start_daemon(dbfile, host, port, logfile):
 
     if pid:
         sys.stderr.write("pidfile %s already exist. Daemon already running?\n"
-                            % pidfile)
-        return 1
+                            % PRServer.pidfile)
+        sys.exit(1)
 
-    server = PRServer(os.path.abspath(dbfile), os.path.abspath(logfile), (host,port))
+    server = PRServer(options.dbfile, interface=(options.host, options.port),
+                      logfile=os.path.abspath(options.logfile))
     server.start()
-    return 0
 
-def stop_daemon(host, port):
-    pidfile = PIDPREFIX % (host, port)
+def stop_daemon():
     try:
-        pf = file(pidfile,'r')
+        pf = file(PRServer.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"
-                        % pidfile)
+                        % PRServer.pidfile)
+        sys.exit(1)
 
-    try:
-        PRServerConnection(host, port).terminate()
-    except:
-        logger.critical("Stop PRService %s:%d failed" % (host,port))
+    PRServerConnection(host,port).terminate()
     time.sleep(0.5)
 
     try:
-        if pid:
-            if os.path.exists(pidfile):
-                os.remove(pidfile)
+        while 1:
             os.kill(pid,signal.SIGTERM)
             time.sleep(0.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")
+    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)
-        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

@@ -1,48 +1,61 @@
 # This is a single Makefile to handle all generated Yocto Project documents.
 # The Makefile needs to live in the documents directory and all figures used
-# in any manuals must be PNG files and live in the individual book's figures
-# directory.
+# in any manuals must be .PNG files and live in the individual book's figures
+# directory.  Note that the figures for the Yocto Project Development Manual
+# differ between the 'master' and 'edison' branches.
 #
 # The Makefile has these targets:
 #
-#    pdf: generates a PDF version of a manual.  Not valid for the Quick Start
-#    html: generates an HTML version of a manual.
-#    tarball: creates a tarball for the doc files.
+#    pdf:      generates a PDF version of a manual.  Not valid for the Quick Start
+#    html:     generates an HTML version of a manual.
+#    tarball:  creates a tarball for the doc files.
 #    validate: validates 
-#    publish: pushes generated files to the Yocto Project website
-#    clean: removes files
+#    publish:  pushes generated files to the Yocto Project website
+#    clean:    removes files
 #
 # The Makefile generates an HTML and PDF version of every document except the
 # Yocto Project Quick Start.  The Quick Start is in HTML form only.  The variable
-# The command-line argument DOC represents the folder name in which a particular 
-# document is stored.  The command-line argument VER represents the distro 
-# version of the Yocto Release for which the manuals are being generated.
+# DOC is used to indicate the folder name for a given manual. The variable
+# VER represents the distro version of the Yocto Release for which the manuals 
+# are being generated.  The variable BRANCH is used to indicate the 'edison'
+# branch and is used only when DOC=dev-manual (making the YP Development
+# Manual).  
+#
 # To build the HTML and PDF versions of the manual you must invoke the Makefile
 # with the DOC argument.  If you are going to publish the manual then you 
 # you must invoke the Makefile with both the DOC and the VER argument.
+# If you are building the 'edison' version of the YP DEvelopment Manual then
+# you must use the DOC and BRANCH arguments.  
 #
 # Examples:
 #
 #     make DOC=bsp-guide
 #     make DOC=yocto-project-qs
 #     make pdf DOC=poky-ref-manual
+#     make DOC=dev-manual BRANCH=edison
 #
 # The first example generates the HTML and PDF versions of the BSP Guide.
 # The second example generates the HTML version only of the Quick Start.  Note that 
 # the Quick Start only has an HTML version available.  The third example generates 
-# both the PDF and HTML versions of the Yocto Project Reference Manual.
+# both the PDF and HTML versions of the Yocto Project Reference Manual. The 
+# last example generates both the PDF and HTML 'edison' versions of the YP 
+# Development Manual.
 #
 # Use the publish target to push the generated manuals to the Yocto Project 
 # website.  All files needed for the manual's HTML form are pushed as well as the 
 # PDF version (if applicable).  
 # Examples:
 #
-#    make publish DOC=bsp-guide VER=1.1
-#    make publish DOC=adt-manual VER=1.1
+#    make publish DOC=bsp-guide VER=1.2
+#    make publish DOC=adt-manual VER=1.2
+#    make publish DOC=dev-manual VER=1.1.1 BRANCH=edison
+#    make publish DOC=dev-manual VER=1.2 
 #
-# The first example publishes the 1.1 version of both the PDF and HTML versions of 
-# the BSP Guide.  The second example publishes the 1.1 version of both the PDF and 
-# HTML versions of the ADT Manual.
+# The first example publishes the 1.2 version of both the PDF and HTML versions of 
+# the BSP Guide.  The second example publishes the 1.2 version of both the PDF and 
+# HTML versions of the ADT Manual. The third example publishes the PDF and HTML
+# 'edison' versions of the YP Development Manual.  Finally, the last example publishes
+# the PDF and HTML 'master' versions of the YP Development Manual. 
 #
 
 ifeq ($(DOC),bsp-guide)
@@ -66,11 +79,32 @@ XSLTOPTS = --stringparam html.stylesheet style.css \
            --stringparam  section.label.includes.component.label 1 \
            --xinclude
 ALLPREQ = html pdf tarball
-TARFILES = style.css dev-manual.html dev-manual.pdf figures/bsp-dev-flow.png figures/dev-title.png \
+#
+# Note that the tarfile might produce the "Cannot stat: No such file or directory" error
+# message for .PNG files that are not present when building a particular branch.  The 
+# list of files is all-inclusive for all branches.
+#
+
+	ifeq ($(BRANCH),edison)
+TARFILES = style.css dev-manual.html dev-manual.pdf \
+           figures/app-dev-flow.png figures/bsp-dev-flow.png figures/dev-title.png \
            figures/git-workflow.png figures/index-downloads.png figures/kernel-dev-flow.png \
-           figures/kernel-example-repos.png figures/kernel-overview-1.png figures/kernel-overview-2.png \
-           figures/kernel-overview-3.png figures/source-repos.png figures/yp-download.png \
+           figures/kernel-example-repos-edison.png \
+           figures/kernel-overview-1.png figures/kernel-overview-2.png \
+           figures/kernel-overview-3-edison.png \
+           figures/source-repos.png figures/yp-download.png \
            figures/wip.png
+	else
+TARFILES = style.css dev-manual.html dev-manual.pdf \
+           figures/app-dev-flow.png figures/bsp-dev-flow.png figures/dev-title.png \
+           figures/git-workflow.png figures/index-downloads.png figures/kernel-dev-flow.png \
+           figures/kernel-example-repos.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/wip.png
+	endif
+
 MANUALS = $(DOC)/$(DOC).html $(DOC)/$(DOC).pdf
 FIGURES = figures
 STYLESHEET = $(DOC)/*.css

documentation/adt-manual/adt-command.xml

@@ -1,5 +1,6 @@
 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <chapter id='using-the-command-line'>
 <title>Using the Command Line</title>
@@ -12,9 +13,9 @@
         Toolchain Tarball)</link>".  
         And, that sourcing your architecture-specific environment setup script 
         initializes a suitable cross-toolchain development environment.  
-        This setup occurs by adding the compiler, QEMU scripts, QEMU binary, 
+        During the setup, locations for the compiler, QEMU scripts, QEMU binary, 
         a special version of <filename>pkgconfig</filename> and other useful 
-        utilities to the <filename>PATH</filename> variable.
+        utilities are added to the <filename>PATH</filename> variable.
         Variables to assist <filename>pkgconfig</filename> and <filename>autotools</filename> 
         are also defined so that, 
         for example, <filename>configure.sh</filename> can find pre-generated 

documentation/adt-manual/adt-eclipse.xml

@@ -1,5 +1,6 @@
 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <chapter id='adt-eclipse'>
 <title>Working Within Eclipse</title>
@@ -34,6 +35,11 @@
             <listitem><para>Install the Eclipse Yocto Plug-in.</para></listitem>
             <listitem><para>Configure the Eclipse Yocto Plug-in.</para></listitem>
         </orderedlist>
+        <note>
+            Do not install Eclipse from your distribution's package repository.
+            Be sure to install Eclipse from the official Eclipse download site as directed
+            in the next section.
+        </note>
     </para>
 
     <section id='installing-eclipse-ide'>
@@ -43,7 +49,7 @@
             It is recommended that you have the Indigo 3.7 version of the 
             Eclipse IDE installed on your development system.  
             If you don’t have this version, you can find it at 
-            <ulink url='http://www.eclipse.org/downloads'></ulink>.  
+            <ulink url='&ECLIPSE_MAIN_URL;'></ulink>.  
             From that site, choose the Eclipse Classic version particular to your development
             host.  
             This version contains the Eclipse Platform, the Java Development 
@@ -53,10 +59,12 @@
         <para>
             Once you have downloaded the tarball, extract it into a clean 
             directory.
-            For example, the following command unpacks and installs the Eclipse IDE
+            For example, the following commands unpack and install the Eclipse IDE
+            tarball found in the <filename>Downloads</filename> area 
             into a clean directory using the default name <filename>eclipse</filename>:
             <literallayout class='monospaced'>
-     $ tar -xzvf ~/Downloads/Eclipse-SDK-3.7-linux-gtk-x86_64.tar.gz
+     $ cd ~
+     $ tar -xzvf ~/Downloads/eclipse-SDK-3.7.1-linux-gtk-x86_64.tar.gz
             </literallayout>
         </para>
 
@@ -98,20 +106,22 @@
                 <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>indigo - http://download.eclipse.org/releases/indigo</filename>
+                <listitem><para>Select <filename>indigo - &ECLIPSE_INDIGO_URL;</filename>
                     from the "Work with:" pull-down menu.</para></listitem>
                 <listitem><para>Expand the box next to <filename>Programming Languages</filename>
                     and select the <filename>Autotools Support for CDT (incubation)</filename>
                     and <filename>C/C++ Development Tools</filename> boxes.</para></listitem>
+                <listitem><para>Expand the box next to "Linux Tools" and select the 
+                    "LTTng - Linux Tracing Toolkit(incubation)" boxes.</para></listitem>
                 <listitem><para>Complete the installation and restart the Eclipse IDE.</para></listitem>
                 <listitem><para>After the Eclipse IDE restarts and from the Workbench, select 
                     "Install New Software" from the "Help" pull-down menu.</para></listitem>
                 <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>
+                    <filename>&ECLIPSE_UPDATES_URL;</filename>
                     and click "OK".</para></listitem>
-                <listitem><para>Select <filename>http://download.eclipse.org/tm/updates/3.3</filename>
+                <listitem><para>Select <filename>&ECLIPSE_UPDATES_URL;</filename>
                     from the "Work with:" pull-down menu.</para></listitem>
                 <listitem><para>Check the box next to <filename>TM and RSE Main Features</filename>.
                     </para></listitem>
@@ -125,7 +135,7 @@
                 <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/indigo</filename>
+                <listitem><para>Select <filename>&ECLIPSE_INDIGO_CDT_URL;</filename>
                     from the "Work with:" pull-down menu.</para></listitem>
                 <listitem><para>Check the box next to <filename>CDT Main Features</filename>.
                     </para></listitem>
@@ -138,30 +148,36 @@
     </section>
 
     <section id='installing-the-eclipse-yocto-plug-in'>
-    <title>Installing the Eclipse Yocto Plug-in</title>
+    <title>Installing or Accessing the Eclipse Yocto Plug-in</title>
 
         <para>
-            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.
+            You can install the Eclipse Yocto Plug-in into the Eclipse application
+            one of two ways:  using the Eclipse IDE and installing the plug-in as new software, or
+            using a built zip file.
+            If you don't want to permanently install the plug-in but just want to try it out
+            within the Eclipse environment, you can import the plug-in project from the 
+            Yocto Project source repositories.
         </para>
 
         <section id='new-software'>
-        <title>New Software</title>
+        <title>Installing the Plug-in as New Software</title>
 
             <para>
-                To install the Eclipse Yocto Plug-in directly into the Eclipse IDE, 
+                To install the Eclipse Yocto Plug-in as new software 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> 
+                        <filename>&ECLIPSE_DL_PLUGIN_URL;</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>Check the box next to <filename>Development tools and SDKs for Yocto Linux</filename>.
+                        </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>
@@ -169,46 +185,8 @@
             </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>
-                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>
+       <title>Installing the Plug-in from a Zip File</title>
             <para>
                 To install the Eclipse Yocto Plug-in by building and installing a plug-in 
                 zip file, follow these steps:
@@ -234,9 +212,9 @@
                         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:
+                        and the <filename>&DISTRO;</filename> release:
                         <literallayout class='monospaced'>
-     $ scripts/build.sh master 1.1M4 
+     $ scripts/build.sh master &DISTRO; 
                         </literallayout>
                         After running the script, the file
                         <filename>org.yocto.sdk-&lt;release&gt;-&lt;date&gt;-archive.zip</filename>
@@ -247,22 +225,57 @@
                         </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.
+                    <listitem><para>Click "Archive" and browse to the ZIP file you built 
+                        in step four.  
                         This ZIP file should not be "unzipped", and must be the 
                         <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
+                    <listitem><para>Check the box next to the new entry in the installation window and complete
                         the installation.</para></listitem>
                     <listitem><para>Restart the Eclipse IDE if necessary.</para></listitem>
                 </orderedlist>
             </para>
 
             <para>
-                At this point you should be able to configure the Eclipse Yocto Plug-in as described in
-                the next section.
+                At this point you should be able to configure the Eclipse Yocto Plug-in as described in the
+                "<link linkend='configuring-the-eclipse-yocto-plug-in'>Configuring the Eclipse Yocto Plug-in</link>"
+                section.</para>
+        </section>            
+
+        <section id='yocto-project-source'>
+        <title>Importing the Plug-in Project into the Eclipse Environment</title>
+            <para>
+                Importing the Eclipse Yocto Plug-in project from the Yocto Project source repositories
+                is useful when you want to try out the latest plug-in from the tip of plug-in's 
+                development tree.
+                It is important to understand when you import the plug-in you are not installing 
+                it into the Eclipse application.
+                Rather, you are importing the project and just using it.
+                To import the plug-in project, 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 select "existing projects into workspace"
+                        and then click "Next".</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>
+                </orderedlist>
+            </para>
+
+            <para>
+                The left navigation pane in the Eclipse application shows the default projects. 
+                Right-click on one of these projects and run it as an Eclipse application.
+                This brings up a second instance of Eclipse IDE that has the Yocto Plug-in.
            </para>
-       </section>            
+       </section>
     </section>
 
     <section id='configuring-the-eclipse-yocto-plug-in'>
@@ -317,7 +330,7 @@
                         </para></listitem>
                     <listitem><para><emphasis>Point to the Toolchain:</emphasis>
                         If you are using a stand-alone pre-built toolchain, you should be pointing to the
-                        <filename>/opt/poky/1.1</filename> directory.
+                        <filename>&YOCTO_ADTPATH_DIR;</filename> directory.
                         This is the location for toolchains installed by the ADT Installer or by hand.
                         Sections "<link linkend='configuring-and-running-the-adt-installer-script'>Configuring 
                         and Running the ADT Installer Script</link>" and 
@@ -349,9 +362,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/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>
+                        See the "<ulink url='&YOCTO_DOCS_QS_URL;#building-image'>Building an Image</ulink>" section 
+                        of The Yocto Project Quick Start for more information.</para></listitem>
                 </itemizedlist>
             </para>
         </section>
@@ -467,7 +479,9 @@
                 The script also runs <filename>libtoolize</filename>, <filename>aclocal</filename>,
                 <filename>autoconf</filename>, <filename>autoheader</filename>, 
                 <filename>automake --a</filename>, and 
-                <filename>./configure</filename>.</para></listitem>
+                <filename>./configure</filename>.
+                Click on the <filename>Console</filename> tab beneath your source code to 
+                see the results of reconfiguring your project.</para></listitem>
         </orderedlist>
     </para>
 </section>
@@ -490,7 +504,7 @@
             <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 in the navigation pane to launch the 
+            <listitem><para>Select your image from the menu 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 
@@ -509,8 +523,8 @@
 <title>Deploying and Debugging the Application</title>
 
     <para>
-        Once the QEMU emulator is running the image, you can deploy your application and use the emulator 
-        to perform debugging.  
+        Once the QEMU emulator is running the image, using the Eclipse IDE 
+        you can deploy your application and use the emulator to perform debugging.  
         Follow these steps to deploy the application.
         <orderedlist>
             <listitem><para>Select <filename>Run -&gt; Debug Configurations...</filename></para></listitem>
@@ -550,7 +564,7 @@
         your development experience.  
         These tools are aids in developing and debugging applications and images.  
         You can run these user-space tools from within the Eclipse IDE through the 
-        <filename>Window -&gt; YoctoTools</filename> menu.
+        <filename>YoctoTools</filename> menu.
     </para>
 
     <para>
@@ -575,14 +589,14 @@
                 host can use, you must have <filename>oprofile</filename> version 0.9.4 or 
                 greater installed on the host.</para>
                 <para>You can locate both the viewer and server from 
-                <ulink url='http://git.yoctoproject.org/cgit/cgit.cgi/oprofileui/'></ulink>.
+                <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/oprofileui/'></ulink>.
                 <note>The <filename>oprofile-server</filename> is installed by default on 
                 the <filename>core-image-sato-sdk</filename> image.</note></para></listitem>
-            <listitem><para><emphasis><filename>Lttng-ust</filename>:</emphasis> Selecting this tool runs 
-                <filename>usttrace</filename> on the remote target, transfers the output data back to the 
-                local host machine, and uses <filename>lttv-gui</filename> to graphically display the output.  
-                The <filename>lttv-gui</filename> must be installed on the local host machine to use this tool.  
-                For information on how to use <filename>lttng</filename> to trace an application, see 
+            <listitem><para><emphasis><filename>Lttng-ust</filename>:</emphasis> Selecting this tool runs
+                <filename>usttrace</filename> on the remote target, transfers the output data back 
+                to the local host machine, and uses the <filename>lttng</filename> Eclipse plug-in to 
+                graphically display the output. 
+                For information on how to use <filename>lttng</filename> to trace an application, see
                 <ulink url='http://lttng.org/files/ust/manual/ust.html'></ulink>.</para>
                 <para>For <filename>Application</filename>, you must supply the absolute path name of the 
                 application to be traced by user mode <filename>lttng</filename>.  
@@ -590,7 +604,32 @@
                 <filename>usttrace /path/to/foo</filename> on the remote target to trace the 
                 program <filename>/path/to/foo</filename>.</para>
                 <para><filename>Argument</filename> is passed to <filename>usttrace</filename>
-                running on the remote target.</para></listitem>
+                running on the remote target.</para>
+                <para>Before you use the <filename>lttng-ust</filename> tool, you need to setup 
+                the <filename>lttng</filename> Eclipse plug-in and create a <filename>lttng</filename>
+                project.
+                Do the following:
+                <orderedlist>
+                    <listitem><para>Follow these 
+                        <ulink url='http://wiki.eclipse.org/Linux_Tools_Project/LTTng#Downloading_and_installing_the_LTTng_parser_library'>instructions</ulink>
+                        to download and install the <filename>lttng</filename> parser library.
+                        </para></listitem>
+                    <listitem><para>Select <filename>Window -> Open Perspective -> Other</filename>
+                        and then select <filename>LTTng</filename>.</para></listitem>
+                    <listitem><para>Click <filename>OK</filename> to change the Eclipse perspective 
+                        into the <filename>LTTng</filename> perspective.</para></listitem>
+                    <listitem><para>Create a new <filename>LTTng</filename> project by selecting 
+                        <filename>File -> New -> Project</filename>.</para></listitem>
+                    <listitem><para>Choose <filename>LTTng -> LTTng Project</filename>.</para></listitem>
+                    <listitem><para>Click <filename>YoctoTools -> lttng-ust</filename> to start user mode 
+                        <filename>lttng</filename> on the remote target.</para></listitem>
+                </orderedlist></para>
+                <para>After the output data has been transferred from the remote target back to the local
+                host machine, new traces will be imported into the selected <filename>LTTng</filename> project.
+                Then you can go to the <filename>LTTng</filename> project, right click the imported 
+                trace, and set the trace type as the <filename>LTTng</filename> kernel trace.
+                Finally, right click the imported trace and select <filename>Open</filename>
+                to display the data graphically.</para></listitem>
             <listitem><para><emphasis><filename>PowerTOP</filename>:</emphasis> Selecting this tool runs 
                 <filename>powertop</filename> on the remote target machine and displays the results in a 
                 new view called <filename>powertop</filename>.</para>

documentation/adt-manual/adt-intro.xml

@@ -1,5 +1,6 @@
 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <chapter id='adt-intro'>
 
@@ -106,7 +107,7 @@
                 <listitem><para><emphasis>PowerTOP:</emphasis> Helps you determine what   
                     software is using the most power.  
                     You can find out more about PowerTOP at 
-                    <ulink url='http://www.linuxpowertop.org/'></ulink>.</para></listitem>
+                    <ulink url='https://01.org/powertop/'></ulink>.</para></listitem>
                 <listitem><para><emphasis>OProfile:</emphasis> A system-wide profiler for Linux 
                     systems that is capable of profiling all running code at low overhead.  
                     You can find out more about OProfile at 
@@ -114,7 +115,7 @@
                 <listitem><para><emphasis>Perf:</emphasis> Performance counters for Linux used 
                     to keep track of certain types of hardware and software events.  
                     For more information on these types of counters see 
-                    <ulink url='https://perf.wiki.kernel.org/index.php'></ulink> and click 
+                    <ulink url='https://perf.wiki.kernel.org/'></ulink> and click 
                     on “Perf tools.”</para></listitem>
                 <listitem><para><emphasis>SystemTap:</emphasis> A free software infrastructure 
                     that simplifies information gathering about a running Linux system.  

documentation/adt-manual/adt-manual.xml

@@ -1,5 +1,6 @@
 <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <book id='adt-manual' lang='en' 
       xmlns:xi="http://www.w3.org/2003/XInclude"
@@ -43,10 +44,20 @@
                 <date>6 October 2011</date>
                 <revremark>Released with the Yocto Project 1.1 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>1.1.1</revnumber>
+                <date>15 March 2012</date>
+                <revremark>Released with the Yocto Project 1.1.1 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.1.2</revnumber>
+                <date>July 2012</date>
+                <revremark>Released with the Yocto Project 1.1.2 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>
-      <year>2010-2011</year>
+      <year>&COPYRIGHT_YEAR;</year>
       <holder>Linux Foundation</holder>
     </copyright>
 
@@ -58,9 +69,9 @@
       <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/latest/adt-manual/adt-manual.html'>
+          <ulink url='&YOCTO_DOCS_ADT_URL;'>
           Application Developer's Toolkit (ADT) User's Guide</ulink> on
-          the <ulink url='http://www.yoctoproject.org'>Yocto Project</ulink> website.
+          the <ulink url='&YOCTO_HOME_URL;'>Yocto Project</ulink> website.
           For the latest version of this manual, see the manual on the website.
       </note>
 

documentation/adt-manual/adt-package.xml

@@ -1,5 +1,6 @@
 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <chapter id='adt-package'>
 <title>Optionally Customizing the Development Packages Installation</title>
@@ -54,9 +55,7 @@
 
     <note>
         For build performance information related to the PMS, see
-        <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>.
+        <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-package'>Packaging - <filename>package*.bbclass</filename></ulink> in The Yocto Project Reference Manual.
     </note>
 
     <para>

documentation/adt-manual/adt-prepare.xml

@@ -1,5 +1,6 @@
 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <chapter id='adt-prepare'>
 
@@ -55,8 +56,10 @@
 
             <para>
                 The ADT Installer is contained in the ADT Installer tarball.
-                You can download the tarball into any directory from  
-                <ulink url='http://downloads.yoctoproject.org/releases/yocto/yocto-1.1/adt_installer'></ulink>.
+                You can download the tarball into any directory from the 
+                <ulink url='&YOCTO_DL_URL;/releases'>Index of Releases</ulink>, specifically
+                at  
+                <ulink url='&YOCTO_ADTINSTALLER_DL_URL;'></ulink>.
                 Or, you can use BitBake to generate the tarball inside the existing Yocto Project 
                 build tree.
             </para>
@@ -79,9 +82,9 @@
      $ cd ~
      $ mkdir yocto-project
      $ cd yocto-project
-     $ 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
+     $ wget &YOCTO_RELEASE_DL_URL;/&YOCTO_POKY_TARBALL;
+     $ tar xjf &YOCTO_POKY_TARBALL;
+     $ source &OE_INIT_PATH;
      $ bitbake adt-installer
                 </literallayout>
             </para>
@@ -93,6 +96,14 @@
             <para>
                 Before running the ADT Installer script, you need to unpack the tarball.
                 You can unpack the tarball in any directory you wish.
+                For example, this command copies the ADT Installer tarball from where 
+                it was built into the home directory and then unpacks the tarball into 
+                a top-level directory named <filename>adt-installer</filename>:
+                <literallayout class='monospaced'>
+     $ cd ~
+     $ cp ~/poky/build/tmp/deploy/sdk/adt_installer.tar.bz2 $HOME
+     $ tar -xjf adt_installer.tar.bz2
+                </literallayout>
                 Unpacking it creates the directory <filename>adt-installer</filename>, 
                 which contains the ADT Installer script (<filename>adt_installer</filename>)
                 and its configuration file (<filename>adt_installer.conf</filename>).
@@ -155,19 +166,20 @@
 
             <para>
                 After you have configured the <filename>adt_installer.conf</filename> file, 
-                run the installer using the following command:
+                run the installer using the following command.
+                Be sure that you are not trying to use cross-compilation tools. 
+                When you run the installer, the environment must use a 
+                host <filename>gcc</filename>:
                 <literallayout class='monospaced'>
-     $ adt_installer
+     $ ./adt_installer
                 </literallayout>
             </para>
 
             <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/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.
+                If you install the recommended packages as described in  
+                "<ulink url='&YOCTO_DOCS_QS_URL;#packages'>The Packages</ulink>"
+                section of The Yocto Project Quick Start, then you will have libtool installed.
             </note>
 
             <para>
@@ -181,7 +193,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/1.1</filename>,
+                <filename>&YOCTO_ADTPATH_DIR;</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
@@ -204,17 +216,17 @@
             Follow these steps:
             <orderedlist>
                 <listitem><para>Go to  
-                    <ulink url='http://downloads.yoctoproject.org/releases/yocto/yocto-1.1/toolchain'></ulink> 
+                    <ulink url='&YOCTO_TOOLCHAIN_DL_URL;'></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>
+                    <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 Intel-based 32-bit target, go into the 
                     <filename>x86_64</filename> folder and download the following tarball:
                     <literallayout class='monospaced'>
-     poky-eglibc-x86_64-i586-toolchain-gmae-1.1.tar.bz2
+     poky-eglibc-x86_64-i586-toolchain-gmae-&DISTRO;.tar.bz2
                     </literallayout>
                     <note><para>As an alternative to steps one and two, you can build the toolchain tarball 
                         if you have a Yocto Project build tree.
@@ -231,7 +243,7 @@
                         </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/1.1</filename>.
+                    The tarball expands into <filename>&YOCTO_ADTPATH_DIR;</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>
@@ -294,7 +306,7 @@
         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/1.1</filename>
+        then you can find this script in the <filename>&YOCTO_ADTPATH_DIR;</filename>
         directory.  
         If you installed the toolchain in the build tree, you can find the environment setup 
         script for the toolchain in the Yocto Project build tree's <filename>tmp</filename> directory.
@@ -308,7 +320,7 @@
         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
+     &YOCTO_ADTPATH_DIR;/environment-setup-x86_64-poky-linux
         </literallayout>
     </para>
 </section>
@@ -330,10 +342,8 @@
             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>.
+            "<ulink url='&YOCTO_DOCS_QS_URL;#test-run'>A Quick Test Run</ulink>" section of   
+            The Yocto Project Quick Start.
         </para>
 
         <para> 
@@ -342,12 +352,11 @@
             <filename>mips</filename>, <filename>powerpc</filename>, and <filename>arm</filename>) 
             that you can use unaltered in the QEMU emulator.  
             These kernel images reside in the Yocto Project release 
-            area - <ulink url='http://downloads.yoctoproject.org/releases/yocto/yocto-1.1/machines/'></ulink>
+            area - <ulink url='&YOCTO_MACHINES_DL_URL;'></ulink>
             and are ideal for experimentation within Yocto Project.
             For information on the image types you can build using the Yocto Project, see the
-            "<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>.
+            "<ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Reference: Images</ulink>" appendix in  
+            The Yocto Project Reference Manual.
         </para>
 
         <para>
@@ -363,7 +372,7 @@
             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 
+                <listitem><para>Modify the <filename>conf/local.conf</filename> configuration file 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. 
@@ -378,11 +387,11 @@
                         <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:
+                        <listitem><para>Get the <filename>tcf-agent</filename> source code using
+                            the following commands:
                             <literallayout class='monospaced'>
-     $ svn checkout svn://dev.eclipse.org/svnroot/dsdp/org.eclipse.tm.tcf/trunk/agent \
-        &lt;-r #rev_number&gt;
+     $ git clone http://git.eclipse.org/gitroot/tcf/org.eclipse.tcf.agent.git
+     $ cd agent
                             </literallayout></para></listitem>
                         <listitem><para>Modify the <filename>Makefile.inc</filename> file
                             for the cross-compilation environment by setting the 
@@ -422,13 +431,13 @@
             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>.
+            <filename>core-image-sato-sdk-qemux86.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 \
+        tmp/deploy/images/core-image-sato-sdk-qemux86.tar.bz2 \
         $HOME/qemux86-sato
             </literallayout>
             In this case, you could now point to the target sysroot at 

documentation/adt-manual/style.css

@@ -654,7 +654,7 @@ hr {
 
 
 .tip, .warning, .caution, .note {
-  border-color: #aaa;
+  border-color: #fff;
 }
 
 
@@ -662,24 +662,24 @@ hr {
 .warning table th,
 .caution table th,
 .note table th {
-  border-bottom-color: #aaa;
+  border-bottom-color: #fff;
 }
 
 
 .warning {
-  background-color: #fea;
+  background-color: #f0f0f2;
 }
 
 .caution {
-  background-color: #fea;
+  background-color: #f0f0f2;
 }
 
 .tip {
-  background-color: #eff;
+  background-color: #f0f0f2;
 }
 
 .note {
-  background-color: #dfc;
+  background-color: #f0f0f2; 
 }
 
 .glossary dl dt, 
@@ -946,8 +946,8 @@ table {
 
 .tip,
 .note {
-   background: #666666;
-   color: #fff;   
+   background: #f0f0f2; 
+   color: #333;   
    padding: 20px;
    margin: 20px;
 }
@@ -958,12 +958,12 @@ table {
    margin: 0em;
    font-size: 2em;
    font-weight: bold;
-   color: #fff;   
+   color: #333;   
 }
 
 .tip a,
 .note a {
-   color: #fff;   
+   color: #333;   
    text-decoration: underline;
 }
 
@@ -972,3 +972,12 @@ table {
    color: #333;
 }
 
+/* Changes the announcement text */
+.tip h3,
+.warning h3,
+.caution h3,
+.note h3 {
+   font-size:large;
+   color: #00557D;
+}
+

documentation/bsp-guide/bsp-guide.xml

@@ -1,5 +1,6 @@
 <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <book id='bsp-guide' lang='en' 
       xmlns:xi="http://www.w3.org/2003/XInclude"
@@ -55,10 +56,20 @@
                 <date>6 October 2011</date>
                 <revremark>Released with the Yocto Project 1.1 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>1.1.1</revnumber>
+                <date>15 March 2012</date>
+                <revremark>Released with the Yocto Project 1.1.1 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.1.2</revnumber>
+                <date>July 2012</date>
+                <revremark>Released with the Yocto Project 1.1.2 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>
-      <year>2010-2011</year>
+      <year>&COPYRIGHT_YEAR;</year>
       <holder>Linux Foundation</holder>
     </copyright>
 
@@ -70,9 +81,9 @@
       <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/latest/bsp-guide/bsp-guide.html'>
+          <ulink url='&YOCTO_DOCS_BSP_URL;'>
           Board Support Package (BSP) Developer's Guide</ulink> on
-          the <ulink url='http://www.yoctoproject.org'>Yocto Project</ulink> website.
+          the <ulink url='&YOCTO_HOME_URL;'>Yocto Project</ulink> website.
           For the latest version of this manual, see the manual on the website.
       </note>
     </legalnotice>

documentation/bsp-guide/style.css

@@ -654,7 +654,7 @@ hr {
 
 
 .tip, .warning, .caution, .note {
-  border-color: #aaa;
+  border-color: #fff;
 }
 
 
@@ -662,24 +662,24 @@ hr {
 .warning table th,
 .caution table th,
 .note table th {
-  border-bottom-color: #aaa;
+  border-bottom-color: #fff;
 }
 
 
 .warning {
-  background-color: #fea;
+  background-color: #f0f0f2;
 }
 
 .caution {
-  background-color: #fea;
+  background-color: #f0f0f2;
 }
 
 .tip {
-  background-color: #eff;
+  background-color: #f0f0f2;
 }
 
 .note {
-  background-color: #dfc;
+  background-color: #f0f0f2; 
 }
 
 .glossary dl dt, 
@@ -771,6 +771,17 @@ h6,
 h7{
 }
 
+/*
+Example of how to stick an image as part of the title.
+
+div.article .titlepage .title
+{
+  background-image: url("figures/white-on-black.png");
+  background-position: center;
+  background-repeat: repeat-x;
+}
+*/
+
 div.preface .titlepage .title, 
 div.colophon .title, 
 div.chapter .titlepage .title {
@@ -936,8 +947,8 @@ table {
 
 .tip,
 .note {
-   background: #666666;
-   color: #fff;   
+   background: #f0f0f2; 
+   color: #333;   
    padding: 20px;
    margin: 20px;
 }
@@ -948,12 +959,12 @@ table {
    margin: 0em;
    font-size: 2em;
    font-weight: bold;
-   color: #fff;   
+   color: #333;   
 }
 
 .tip a,
 .note a {
-   color: #fff;   
+   color: #333;   
    text-decoration: underline;
 }
 
@@ -962,3 +973,12 @@ table {
    color: #333;
 }
 
+/* Changes the announcement text */
+.tip h3,
+.warning h3,
+.caution h3,
+.note h3 {
+   font-size:large;
+   color: #00557D;
+}
+

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

@@ -1,5 +1,6 @@
 <!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <appendix id='dev-manual-bsp-appendix'>
 
@@ -31,47 +32,77 @@
         The following paragraphs describe both methods.
         For additional information, see the bulleted item
         "<link linkend='local-yp-release'>Yocto Project Release</link>".
-    </para>
+    </para> 
 
     <para>
         As mentioned, one way to get the Yocto Project files is to use Git to clone the 
-        <filename>poky</filename> repository:
+        <filename>poky</filename> repository. 
+        These commands create a local copy of the Git repository.
+        By default, the top-level directory of the repository is named <filename>poky</filename>:
         <literallayout class='monospaced'>
      $ git clone git://git.yoctoproject.org/poky
      $ cd poky
         </literallayout> 
-        Alternatively, you can start with the downloaded Poky "edison" tarball:
+        Alternatively, you can start with the downloaded Poky "&DISTRO_NAME;" tarball.
+        These commands unpack the tarball into a Yocto Project File directory structure.
+        By default, the top-level directory of the file structure is named
+        <filename>&YOCTO_POKY;</filename>:
         <literallayout class='monospaced'>
-     $ tar xfj poky-edison-6.0.tar.bz2
-     $ cd poky
+     $ tar xfj &YOCTO_POKY_TARBALL;
+     $ cd &YOCTO_POKY;
         </literallayout> 
-        <note>If you're using the tarball method, you can ignore all the following steps that
+        <note><para>If you're using the tarball method, you can ignore all the following steps that
         ask you to carry out Git operations.  
         You already have the results of those operations
-        in the form of the edison release tarballs.
+        in the form of the &DISTRO_NAME; release tarballs.
         Consequently, there is nothing left to do other than extract those tarballs into the 
-        proper locations.</note>
+        proper locations.</para>
+
+        <para>Once you expand the released tarball, you have a snapshot of the Git repository
+        that represents a specific release.
+        Fundamentally, this is different than having a local copy of the Yocto Project 
+        Git repository.  
+        Given the tarball method, changes you make are building on top of a release.
+        With the Git repository method you have the ability to track development
+        and keep changes in revision control.</para></note>
     </para>
 
     <para>
-        Once you have the local <filename>poky</filename> Git repository set up, 
-        you have many development branches from which you can work. 
-        From inside the repository you can see the branch names and the tag names used 
-        in the Git repository using either of the following two commands:
+        With the local <filename>poky</filename> Git repository set up, 
+        you have all the development branches available to you from which you can work. 
+        Next, you need to be sure that your local repository reflects the exact
+        release in which you are interested.
+        From inside the repository you can see the development branches that represent
+        areas of development that have diverged from the main (master) branch
+        at some point, such as a branch to track a maintenance release's development.  
+        You can also see the tag names used to mark snapshots of stable releases or 
+        points in the repository.
+        Use the following commands to list out the branches and the tags in the repository, 
+        respectively.
         <literallayout class='monospaced'>
      $ git branch -a
      $ git tag -l
         </literallayout> 
-        For this example we are going to use the Yocto Project 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.
+        For this example, we are going to use the Yocto Project &DISTRO; Release, which is code
+        named "&DISTRO_NAME;". 
+        To make sure we have a local area (branch in Git terms) on our machine that 
+        reflects the &DISTRO; release, we can use the following commands:
         <literallayout class='monospaced'>
-     $ git checkout -b edison origin/edison
-     Switched to a new branch 'edison'
+     $ cd ~/poky
+     $ git fetch --tags
+     $ git checkout &DISTRO_NAME;-&POKYVERSION; -b &DISTRO_NAME;
+     Switched to a new branch '&DISTRO_NAME;'
         </literallayout>
+        The <filename>git fetch --tags</filename> is somewhat redundant since you just set 
+        up the repository and should have all the tags.
+        The <filename>fetch</filename> command makes sure all the tags are available in your
+        local repository.
+        The Git <filename>checkout</filename> command with the <filename>-b</filename> option
+        creates a local branch for you named <filename>&DISTRO_NAME;</filename>.
+        Your local branch begins in the same state as the Yocto Project &DISTRO; released tarball 
+        marked with the <filename>&DISTRO_NAME;-&POKYVERSION;</filename> tag in the source repositories.
     </para>
-</section>
+</section> 
 
 <section id='choosing-a-base-bsp-app'>
     <title>Choosing a Base BSP</title>
@@ -100,7 +131,7 @@
     <para>
         You need to have the base BSP layer on your development system.  
         Similar to the local Yocto Project files, you can get the BSP 
-        layer in a couple of different ways:  
+        layer in 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.
@@ -126,15 +157,15 @@
      $ cd meta-intel
         </literallayout> 
         Alternatively, you can start with the downloaded Crown Bay tarball.
-        You can download the edison version of the BSP tarball from the
-        <ulink url='http://www.yoctoproject.org/download'>Download</ulink> page of the 
+        You can download the &DISTRO_NAME; version of the BSP tarball from the
+        <ulink url='&YOCTO_HOME_URL;/download'>Download</ulink> page of the 
         Yocto Project website. 
         Here is the specific link for the tarball needed for this example:
-        <ulink url='http://downloads.yoctoproject.org/releases/yocto/yocto-1.1/machines/crownbay-noemgd/crownbay-noemgd-edison-6.0.0.tar.bz2'></ulink>.
+        <ulink url='&YOCTO_DL_URL;/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
+     $ tar xfj crownbay-noemgd-&DISTRO_NAME;-6.0.0.tar.bz2
      $ cd meta-intel
         </literallayout> 
     </para>
@@ -143,15 +174,16 @@
         The <filename>meta-intel</filename> directory contains all the metadata 
         that supports BSP creation.  
         If you're using the Git method, the following
-        step will switch to the edison metadata.
+        step will switch to the &DISTRO_NAME; metadata.
         If you're using the tarball method, you already have the correct metadata and can 
         skip to the next step.
         Because <filename>meta-intel</filename> is its own Git repository, you will want
         to be sure you are in the appropriate branch for your work.
-        For this example we are going to use the <filename>edison</filename> branch. 
+        For this example we are going to use the <filename>&DISTRO_NAME;</filename> branch. 
         <literallayout class='monospaced'>
-     $ git checkout -b edison origin/edison
-     Switched to a new branch 'edison'
+     $ git checkout -b &DISTRO_NAME; origin/&DISTRO_NAME;
+     Branch &DISTRO_NAME; set up to track remote branch &DISTRO_NAME; from origin.
+     Switched to a new branch '&DISTRO_NAME;'
         </literallayout>
     </para>
 </section>
@@ -238,10 +270,8 @@
             <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/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.  
+            "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-filelayout-layer'>Layer Configuration File</ulink>" section
+            in The Board Support Packages (BSP) Development Guide for more information on this configuration file.  
             Basically, we are changing the existing statements to work with our BSP. 
         </para>
 
@@ -272,7 +302,8 @@
             Now we will take a look at the recipes in your new layer.  
             The standard BSP structure has areas for BSP, graphics, core, and kernel recipes.  
             When you create a BSP, you use these areas for appropriate recipes and append files.  
-            Recipes take the form of <filename>.bb</filename> files.  
+            Recipes take the form of <filename>.bb</filename> files, while append files take
+            the form of <filename>.bbappend</filename> files.  
             If you want to leverage the existing recipes the Yocto Project build system uses
             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 
@@ -328,7 +359,7 @@
                 <filename>recipes-core/tasks</filename> appends the similarly named recipe
                 located in the local Yocto Project files at 
                 <filename>meta/recipes-core/tasks</filename>.
-                The "append" file in our layer right now is Crown Bay-specific and supports 
+                The append file in our layer right now is Crown Bay-specific and supports 
                 EMGD and non-EMGD.
                 Here are the contents of the file:
                 <literallayout class='monospaced'>
@@ -372,15 +403,18 @@
                 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/linux</filename>.
-                Thus, the <filename>SRCREV</filename> statements in the "append" file override
+                appends information to the recipe of the same name in <filename>meta/recipes-kernel/linux</filename>.
+                Thus, the <filename>SRCREV</filename> statements in the append file override
                 the more general statements found in <filename>meta</filename>.
             </para>
 
             <para>
-                The <filename>SRCREV</filename> statements in the "append" file currently identify
+                The <filename>SRCREV</filename> statements in the append file currently identify
                 the kernel that supports the Crown Bay BSP with and without EMGD support.
-                Here are the statements: 
+                Here are the statements:
+                <note>The commit ID strings used in this manual might not match the actual commit
+                    ID strings found in the <filename>linux-yocto_3.0.bbappend</filename> file.
+                    For the example, this difference does not matter.</note> 
                 <literallayout class='monospaced'>
      SRCREV_machine_pn-linux-yocto_crownbay ?= \
         "2247da9131ea7e46ed4766a69bb1353dba22f873"
@@ -412,11 +446,11 @@
                 and insert the commit identifiers to identify the kernel in which we 
                 are interested, which will be based on the <filename>atom-pc-standard</filename>
                 kernel.
-                In this case, because we're working with the edison branch of everything, we
+                In this case, because we're working with the &DISTRO_NAME; branch of everything, we
                 need to use the <filename>SRCREV</filename> values for the atom-pc branch
-                that are associated with the edison release.  
+                that are associated with the &DISTRO_NAME; release.  
                 To find those values, we need to find the <filename>SRCREV</filename>
-                values that edison uses for the atom-pc branch, which we find in the
+                values that &DISTRO_NAME; uses for the atom-pc branch, which we find in the
                 <filename>poky/meta-yocto/recipes-kernel/linux/linux-yocto_3.0.bbappend</filename>
                 file.
             </para>
@@ -427,9 +461,7 @@
                 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.
+                file, in the <filename>SRCREV_meta</filename>  variable found there.  
                 Here are the final <filename>SRCREV</filename> statements:
                 <literallayout class='monospaced'>
      SRCREV_machine_pn-linux-yocto_mymachine ?= \ 
@@ -441,8 +473,8 @@
 
             <para>
                 In this example, we're using the <filename>SRCREV</filename> values we 
-                found already captured in the edison release because we're creating a BSP based on 
-                edison.  
+                found already captured in the &DISTRO_NAME; release because we're creating a BSP based on 
+                &DISTRO_NAME;.  
                 If, instead, we had based our BSP on the master branches, we would want to use 
                 the most recent <filename>SRCREV</filename> values taken directly from the kernel repo.
                 We will not be doing that for this example.
@@ -451,8 +483,8 @@
                 exact commit strings in the Yocto Project source repositories you need to change 
                 the <filename>SRCREV</filename> statements.  
                 You can find all the <filename>machine</filename> and <filename>meta</filename> 
-                branch points (commits) for the <filename>linux-yocto-3.0</filename> kernel at
-                <ulink url='http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.0'></ulink>.  
+                branch points (commits) for the <filename>linux-yocto-3.0-1.1.x</filename> kernel at
+                <ulink url='&YOCTO_GIT_URL;/cgit.cgi/linux-yocto-3.0-1.1.x/'></ulink>.  
             </para>
 
             <para>
@@ -481,12 +513,12 @@
                 Because we are not interested in supporting EMGD those three can be deleted.
                 The remaining three must be changed so that <filename>mymachine</filename> replaces
                 <filename>crownbay-noemgd</filename> and <filename>crownbay</filename>.
-                Because we are using the atom-pc branch for this new BSP, we can also find
-                the exact branch we need for the KMACHINE variable in our new BSP from the value
+                Because we are using the <filename>atom-pc</filename> branch for this new BSP, we can also find
+                the exact branch we need for the <filename>KMACHINE</filename> 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.
+                In this case, the value we want is in the <filename>KMACHINE_atom-pc</filename> variable in that file.
                 Here is the final <filename>linux-yocto_3.0.bbappend</filename> file after all 
                 the edits:
                 <literallayout class='monospaced'>
@@ -568,9 +600,8 @@
                 variables to twice the number of cores your system supports.</para></listitem>
             <listitem><para>Update the <filename>bblayers.conf</filename> file so that it includes 
                 the path to your new BSP layer.  
-                In this example you need to include the pathname to <filename>meta-mymachine</filename>.
-                For this example the 
-                <filename>BBLAYERS</filename> variable in the file would need to include the following path:
+                In this example, you need to include this path as part of the 
+                <filename>BBLAYERS</filename> variable:
                 <literallayout class='monospaced'>
      $HOME/poky/meta-intel/meta-mymachine
                 </literallayout></para></listitem>
@@ -579,7 +610,7 @@
 
     <para>
         The appendix 
-        <ulink url='http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html#ref-variables-glos'>
+        <ulink url='&YOCTO_DOCS_REF_URL;#ref-variables-glos'>
         Reference: Variables Glossary</ulink> in the Yocto Project Reference Manual has more information 
          on configuration variables.
     </para>
@@ -615,13 +646,13 @@
         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>, 
+        Assuming the USB flash drive takes device <filename>/dev/sdc</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
+     # dd if=core-image-sato-mymachine-20120111232235.hddimg of=/dev/sdc
      # sync
-     # eject /dev/sdf
+     # eject /dev/sdc
         </literallayout>
         You should now have a bootable USB flash device.  
     </para>
@@ -649,12 +680,12 @@
     </para>
 
     <para>
-        For reference, the sato image produced by the previous steps for edison 
+        For reference, the sato image produced by the previous steps for &DISTRO_NAME; 
         should look like the following in terms of size.
         If your sato image is much different from this,
         you probably made a mistake in one of the above steps:
         <literallayout class='monospaced'>
-     358715392 2011-11-01 19:11 core-image-sato-mymachine-20111101223904.hddimg
+     358709248 2012-01-11 20:43 core-image-sato-mymachine-20120111232235.hddimg
         </literallayout>
         <note>The previous instructions are also present in the README that was copied
         from meta-crownbay, which should also be updated to reflect the specifics of your

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

@@ -1,5 +1,6 @@
 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <chapter id='dev-manual-intro'>
 
@@ -17,7 +18,8 @@
             sources where you can find more detail.
             For example, detailed information on Git, repositories and open source in general
             can be found in many places.  
-            Another example is how to get set up to use the Yocto Project, which our Yocto Project Quick Start covers.
+            Another example is how to get set up to use the Yocto Project, which our 
+            <ulink url='&YOCTO_DOCS_QS_URL;'>Yocto Project Quick Start</ulink> covers.
         </para>
 
         <para>  
@@ -38,7 +40,7 @@
                 <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>An understanding of common end-to-end development models and tasks.</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 
@@ -63,13 +65,15 @@
             <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 
+                    For example, the 
+                    <ulink url='&YOCTO_DOCS_ADT_URL;'>Yocto Project Application Development Toolkit (ADT)
+                    User's Guide</ulink> 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'>
+                    <ulink url='&YOCTO_DOCS_REF_URL;'>
                     Yocto Project Reference Manual</ulink>.</para></listitem>
                 <listitem><para>Detailed public information that is not specific to the Yocto Project.  
                     For example, exhaustive information on how to use Git is covered better through the 
@@ -86,31 +90,31 @@
             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>:
+                <listitem><para><emphasis>The <ulink url='&YOCTO_HOME_URL;'>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'>
+                    <ulink url='&YOCTO_DOCS_QS_URL;'>
                     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'>
+                    <ulink url='&YOCTO_DOCS_REF_URL;'>
                     The Yocto Project Reference Manual</ulink>:</emphasis> This manual is a reference 
                     guide to the Yocto Project build component known as "Poky."  
                     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'>
+                    <ulink url='&YOCTO_DOCS_ADT_URL;'>
                     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'>
+                    <ulink url='&YOCTO_DOCS_BSP_URL;'>
                     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'>
+                    <ulink url='&YOCTO_DOCS_KERNEL_URL;'>
                     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>
@@ -120,14 +124,14 @@
                     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>
+                    <ulink url='&YOCTO_WIKI_URL;/wiki/FAQ'>FAQ</ulink>:</emphasis>
                     A list of commonly asked questions and their answers.</para></listitem>
                 <listitem><para><emphasis>
-                    <ulink url='http://www.yoctoproject.org/download/yocto/yocto-project-1.1-release-notes-poky-6.0'>
+                    <ulink url='&YOCTO_HOME_URL;/download/yocto/yocto-project-1.1.2-release-notes-poky-&POKYVERSION;'>
                     Release Notes</ulink>:</emphasis> Features, updates and known issues for the current 
                     release of the Yocto Project.</para></listitem>
                 <listitem><para><emphasis>
-                    <ulink url='http://bugzilla.yoctoproject.org/'>Bugzilla</ulink>:</emphasis>
+                    <ulink url='&YOCTO_BUGZILLA_URL;'>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>
@@ -135,11 +139,11 @@
                     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 
+                        <listitem><para><ulink url='&YOCTO_LISTS_URL;/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 
+                        <listitem><para><ulink url='&YOCTO_LISTS_URL;/listinfo/poky'></ulink> for a 
                             Yocto Project Discussions mailing list about the Poky build system.</para></listitem>
-                        <listitem><para><ulink url='http://lists.yoctoproject.org/listinfo/yocto-announce'></ulink>
+                        <listitem><para><ulink url='&YOCTO_LISTS_URL;/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>
@@ -148,7 +152,7 @@
                     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>
+                    <ulink url='&OH_HOME_URL;'>OpenedHand</ulink>:</emphasis>
                     The company where the Yocto Project build system Poky was first developed.
                     OpenedHand has since been acquired by Intel Corporation.</para></listitem>
                 <listitem><para><emphasis>
@@ -156,7 +160,7 @@
                     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>
+                    <ulink url='&OE_HOME_URL;'>OpenEmbedded</ulink>:</emphasis>
                     The upstream, generic, embedded distribution the Yocto Project build system (Poky) derives
                     from and to which it contributes.</para></listitem>
                 <listitem><para><emphasis>

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

@@ -1,5 +1,6 @@
 <!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <appendix id='dev-manual-kernel-appendix'>
 
@@ -65,7 +66,7 @@
             </para>
 
             <para>
-                <imagedata fileref="figures/kernel-example-repos.png" width="7in" depth="5in" 
+                <imagedata fileref="figures/kernel-example-repos-edison.png" width="7in" depth="5in" 
                     align="center" scale="100" />
             </para>
 
@@ -75,9 +76,10 @@
                     <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
-                        and a configuration directory that let you control the build.
-                        Note also that in this example, the repository also contains the 
+                        In this example, the local Yocto Project files Git repository also 
+                        contains the build directory, which contains the configuration directory 
+                        that lets you control the build.
+                        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>"
@@ -148,14 +150,14 @@
      $ git branch -a
      $ git tag -l
                 </literallayout> 
-                This example uses the Yocto Project 1.1 Release code named "edison", 
-                which maps to the <filename>edison</filename> branch in the repository. 
-                The following commands create and checkout the local <filename>edison</filename>
+                This example uses the Yocto Project &DISTRO; Release code named "&DISTRO_NAME;", 
+                which maps to the <filename>&DISTRO_NAME;</filename> branch in the repository. 
+                The following commands create and checkout the local <filename>&DISTRO_NAME;</filename>
                 branch:
                 <literallayout class='monospaced'>
-     $ git checkout -b edison origin/edison
-     Branch edison set up to track remote branch edison from origin.
-     Switched to a new branch 'edison'
+     $ git checkout -b &DISTRO_NAME; origin/&DISTRO_NAME;
+     Branch &DISTRO_NAME; set up to track remote branch &DISTRO_NAME; from origin.
+     Switched to a new branch '&DISTRO_NAME;'
                 </literallayout>
             </para>
         </section>
@@ -171,13 +173,34 @@
                 <filename>poky-extras</filename> Git Repository</link>" 
                 for information on how to get the <filename>poky-extras</filename> repository.
             </para>
+
+            <para>
+                Once you have the repository set up, 
+                you have many development branches from which you can work. 
+                From inside the repository you can see the branch names and the tag names used 
+                in the Git repository using either of the following two commands:
+                <literallayout class='monospaced'>
+     $ cd poky/poky-extras
+     $ git branch -a
+     $ git tag -l
+                </literallayout> 
+                This example uses the Yocto Project &DISTRO; Release code named "&DISTRO_NAME;", 
+                which maps to the <filename>&DISTRO_NAME;</filename> branch in the repository. 
+                The following commands create and checkout the local <filename>&DISTRO_NAME;</filename>
+                branch:
+                <literallayout class='monospaced'>
+     $ git checkout -b &DISTRO_NAME; origin/&DISTRO_NAME;
+     Branch &DISTRO_NAME; set up to track remote branch &DISTRO_NAME; from origin.
+     Switched to a new branch '&DISTRO_NAME;'
+                </literallayout>
+            </para>
         </section>
 
         <section id='setting-up-the-bare-clone-and-its-copy'>
             <title>Setting Up the Bare Clone and its Copy</title>
 
             <para>
-                This example modifies the <filename>linux-yocto-3.0</filename> kernel.
+                This example modifies the <filename>linux-yocto-3.0-1.1.x</filename> kernel.
                 Thus, you need to create a bare clone of that kernel and then make a copy of the 
                 bare clone.
                 See the bulleted item
@@ -189,13 +212,14 @@
                 The bare clone exists for the kernel build tools and simply as the receiving end 
                 of <filename>git push</filename>
                 commands after you make edits and commits inside the copy of the clone.
-                The copy (<filename>linux-yocto-3.0</filename> in this example) has to have 
+                The copy (<filename>my-linux-yocto-3.0-1.1.x-work</filename> in this example) has to have 
                 a local branch created and checked out for your work.
                 This example uses <filename>common-pc-base</filename> as the local branch.
                 The following commands create and checkout the branch:
                 <literallayout class='monospaced'>
-     $ cd ~/linux-yocto-3.0
+     $ cd ~/my-linux-yocto-3.0-1.1.x-work
      $ git checkout -b common-pc-base origin/yocto/standard/common-pc/base
+     Checking out files: 100% (7289/7289), done.
      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'
@@ -225,10 +249,8 @@
                     <filename>PARALLEL_MAKE</filename> to twice the number 
                     of cores your machine supports.
                 </note>
-                </para>
-                <para>
-                The following two commands build the default <filename>qemux86</filename> image and 
-                <filename>source</filename> build environment setup script.
+                The following two commands <filename>source</filename> the build environment setup script
+                and build the default <filename>qemux86</filename> image.
                 If necessary, the script creates the build directory:
                 <literallayout class='monospaced'>
      $ cd ~/poky
@@ -291,7 +313,7 @@
 
             <para>
                 The file you change in this example is named <filename>calibrate.c</filename>
-                and is located in the <filename>linux-yocto-3.0</filename> Git repository
+                and is located in the <filename>my-linux-yocto-3.0-1.1.x-work</filename> Git repository
                 (the copy of the bare clone) in <filename>init</filename>.
                 This example simply inserts several <filename>printk</filename> statements
                 at the beginning of the <filename>calibrate_delay</filename> function.
@@ -415,13 +437,13 @@
                        <filename>poky-extras/meta-kernel-dev/recipes-kernel/linux</filename>
                        directory, you need to identify the location of the 
                        local source code, which in this example is the bare clone named
-                       <filename>linux-yocto-3.0.git</filename>.
+                       <filename>linux-yocto-3.0-1.1.x.git</filename>.
                        To do this, set the <filename>KSRC_linux_yocto</filename> variable to point to your
-                       local <filename>linux-yocto-3.0.git</filename> Git repository by adding the 
+                       local <filename>linux-yocto-3.0-1.1.x.git</filename> Git repository by adding the 
                        following statement.
                        Be sure to substitute your user information in the statement:
                        <literallayout class='monospaced'>
-     KSRC_linux_yocto ?= /home/scottrif/linux-yocto-3.0.git
+     KSRC_linux_yocto ?= /home/scottrif/linux-yocto-3.0-1.1.x.git
                        </literallayout></para></listitem>
                    <listitem><para><emphasis>Specify the Kernel Machine:</emphasis> Also in the 
                        <filename>linux-yocto_3.0.bbappend</filename> file, you need to specify
@@ -433,14 +455,19 @@
            </para>
 
            <note>
-               Before attempting to build the modified kernel, there is one more set of changes you 
+               <para>Before attempting to build the modified kernel, there is one more set of changes you 
                need to make in the <filename>meta-kernel-dev</filename> layer.
                Because all the kernel <filename>.bbappend</filename> files are parsed during the 
                build process regardless of whether you are using them or not, you should either 
                comment out the <filename>COMPATIBLE_MACHINE</filename> statements in all 
-               <filename>.bbappend</filename> files, or you should simply remove all the files 
+               unused <filename>.bbappend</filename> files, or simply remove (or rename) all the files 
                except the one your are using for the build 
-               (i.e. <filename>linux-yocto_3.0.bbappend</filename> in this example).
+               (i.e. <filename>linux-yocto_3.0.bbappend</filename> in this example).</para>
+               <para>If you do not make one of these two adjustments, your machine will be compatible
+               with all the kernel recipes in the <filename>meta-kernel-dev</filename> layer. 
+               When your machine is comapatible with all the kernel recipes, the build attempts
+               to build all kernels in the layer.
+               You could end up with build errors blocking your work.</para>
            </note>            
        </section>
 
@@ -454,18 +481,21 @@
                     <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>.
-                        </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
+     $ source oe-init-build-env
+                        </literallayout>
+                        </para></listitem>
+                    <listitem><para>Be sure old images are cleaned out by running the 
+                        <filename>cleanall</filename> BitBake task as follows from your build directory:
+                        <literallayout class='monospaced'>
      $ bitbake -c cleanall linux-yocto
                         </literallayout></para>
                         <para><note>Never remove any files by hand from the <filename>tmp/deploy</filename>
                         directory insided the local Yocto Project files build directory.
                         Always use the BitBake <filename>cleanall</filename> task to clear
                         out previous builds.</note></para></listitem>
-                    <listitem><para>Build the kernel image using this command:
+                    <listitem><para>Next, build the kernel image using this command:
                         <literallayout class='monospaced'>
      $ bitbake -k core-image-minimal
                         </literallayout></para></listitem>
@@ -509,46 +539,94 @@
                 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.
+                If this is the case, go to the next section, which is titled
+                "<link linkend='examining-the-default-config-smp-behavior'>Examining the Default
+                <filename>CONFIG_SMP</filename> Behavior</link>", and continue with the 
+                example.
             </para>
 
             <para>
                 If you don't have the 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. 
+                you can get them through tarball extraction or by 
+                cloning the <filename>poky</filename> Git repository.  
+                This example uses <filename>poky</filename> as the root directory of the 
+                local Yocto Project files Git repository.
+                See the bulleted item
+                "<link linkend='local-yp-release'>Yocto Project Release</link>"
+                for information on how to get these files.
             </para>
 
-<!--
+            <para>
+                Once you have the repository set up, 
+                you have many development branches from which you can work. 
+                From inside the repository you can see the branch names and the tag names used 
+                in the Git repository using either of the following two commands:
+                <literallayout class='monospaced'>
+     $ cd poky
+     $ git branch -a
+     $ git tag -l
+                </literallayout> 
+                This example uses the Yocto Project &DISTRO; Release code named "&DISTRO_NAME;", 
+                which maps to the <filename>&DISTRO_NAME;</filename> branch in the repository. 
+                The following commands create and checkout the local <filename>&DISTRO_NAME;</filename>
+                branch:
+                <literallayout class='monospaced'>
+     $ git checkout -b &DISTRO_NAME; origin/&DISTRO_NAME;
+     Branch &DISTRO_NAME; set up to track remote branch &DISTRO_NAME; from origin.
+     Switched to a new branch '&DISTRO_NAME;'
+                </literallayout>
+            </para>
 
             <para>
-                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 "<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 "<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 "<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 "<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 "<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> -->
+                Next, you need to build the default <filename>qemux86</filename> image that you 
+                can boot using QEMU.
+                <note>
+                    Because a full build can take hours, you should check two variables in the 
+                    <filename>build</filename> directory that is created after you source the 
+                    <filename>oe-init-build-env</filename> script.
+                    You can find these variables
+                    <filename>BB_NUMBER_THREADS</filename> and <filename>PARALLEL_MAKE</filename>
+                    in the <filename>build/conf</filename> directory in the 
+                    <filename>local.conf</filename> configuration file.
+                    By default, these variables are commented out.
+                    If your host development system supports multi-core and multi-thread capabilities,
+                    you can uncomment these statements and set the variables to significantly shorten
+                    the full build time.
+                    As a guideline, set <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.
+                </note>
+                The following two commands <filename>source</filename> the build environment setup script
+                and build the default <filename>qemux86</filename> image.
+                If necessary, the script creates the build directory:
+                <literallayout class='monospaced'>
+     $ cd ~/poky
+     $ source oe-init-build-env
+
+          ### Shell environment set up for builds. ###
+
+     You can now run 'bitbake &lt;target&gt;'
+
+     Common targets are:
+         core-image-minimal
+         core-image-sato
+         meta-toolchain
+         meta-toolchain-sdk
+         adt-installer
+         meta-ide-support
+
+     You can also run generated qemu images with a command like 'runqemu qemux86'
+                </literallayout>
+            </para>
+
+            <para>
+                The following <filename>bitbake</filename> command starts the build:
+                <literallayout class='monospaced'>
+     $ bitbake -k core-image-minimal
+                </literallayout>
+                <note>Be sure to check the settings in the <filename>local.conf</filename>
+                before starting the build.</note>
+            </para>
         </section>
 
         <section id='examining-the-default-config-smp-behavior'>
@@ -578,6 +656,8 @@
             </para>
         </section>
 
+
+
         <section id='changing-the-config-smp-configuration-using-menuconfig'>
             <title>Changing the&nbsp;&nbsp;<filename>CONFIG_SMP</filename> Configuration Using&nbsp;&nbsp;<filename>menuconfig</filename></title>
 
@@ -597,15 +677,24 @@
             <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-1.1.x</filename>
                 kernel.
                 The Yocto Project build environment recognizes this kernel as 
                 <filename>linux-yocto</filename>.
-                Thus, the following command from the shell in which you previously sourced the 
-                environment initialization script launches <filename>menuconfig</filename>:
+                Thus, the following commands from the shell in which you previously sourced the 
+                environment initialization script cleans the shared state memory and 
+                the <filename>WORKDIR</filename> direcotry and then builds and 
+                launches <filename>menuconfig</filename>:
                 <literallayout class='monospaced'>
+     $ bitbake linux-yocto -c cleansstate
      $ bitbake linux-yocto -c menuconfig
                 </literallayout>
+                <note>Due to a bug in the release, it is necessary to clean the shared state
+                    memory in order for configurations made using <filename>menuconfig</filename>
+                    to take effect.
+                    For information on the bug, see 
+                    <ulink url='&YOCTO_BUGZILLA_URL;/show_bug.cgi?id=2256'></ulink>.
+                </note>
             </para>
                   
             <para>
@@ -623,16 +712,19 @@
                 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 
+                You can find and examine this file in the Yocto Project Files Git repository in 
                 the build directory. 
-                This example uses the following.
-                Note that this example directory is artificially split and many of the characters 
-                in the actually filename are omitted in order to make it more
-                readable:
+                This example uses the following:
                 <literallayout class='monospaced'>
-     ~/poky/build/tmp/work/qemux86-poky-linux/linux-yocto-2.6.37+git1+84f...
-        ...r20/linux-qemux86-standard-build
+     ~/poky/build/tmp/work/qemux86-poky-linux/linux-yocto-3.0.10+git1+d38...
+        ...3a9ac596f7a-r3/linux-qemux86-standard-build
                 </literallayout>
+                <note>
+                    The previous example directory is artificially split and many of the characters 
+                    in the actual filename are omitted in order to make it more readable.
+                    Also, depending on the kernel you are using, the exact pathname might differ 
+                    slightly.
+                </note>
             </para>
 
             <para>

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

@@ -1,5 +1,6 @@
 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <chapter id='dev-manual-model'>
 
@@ -23,9 +24,8 @@
     "<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>.
+    see <ulink url='&YOCTO_DOCS_ADT_URL;'>The Yocto Project Application Development 
+    Toolkit (ADT) User's Guide</ulink>.
 </para>
 
 <section id='system-development-model'>
@@ -50,7 +50,7 @@
         <title>Developing a Board Support Package (BSP)</title>
 
         <para>
-            A BSP is a package of recipes that, when applied, during a build results in 
+            A BSP is a packageof recipes that, when applied, during a build results in 
             an image that you can run on a particular board.  
             Thus, the package, when compiled into the new image, supports the operation of the board.  
         </para>
@@ -79,8 +79,9 @@
             <orderedlist>
                 <listitem><para><emphasis>Set up your host development system to support 
                     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
+                    "<ulink url='&YOCTO_DOCS_QS_URL;#the-linux-distro'>The Linux Distributions</ulink>" 
+                    and the 
+                    "<ulink url='&YOCTO_DOCS_QS_URL;#packages'>The Packages</ulink>" sections both
                     in the Yocto Project Quick Start for requirements.</para></listitem>
                 <listitem><para><emphasis>Establish a local copy of the Yocto Project files on your 
                     system</emphasis>:  You need to have the Yocto Project files available on your host system. 
@@ -111,13 +112,15 @@
                     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 
-                    on “BSP Downloads.”</para></listitem>
+                    <para>To see the supported BSPs, go to the 
+                    <ulink url='&YOCTO_HOME_URL;/download'>Download</ulink> page on the Yocto Project
+                    website and click on “BSP Downloads.”</para></listitem>
                 <listitem><para><emphasis>Create your own BSP layer</emphasis>:  Layers are ideal for 
                     isolating and storing work for a given piece of hardware.  
-                    A layer is really just a location or area in which you place the recipes for your BSP.  
+                    A layer is really just a location or area in which you place the recipes for your BSP.
                     In fact, a BSP is, in itself, a special type of layer.   
+                    </para>
+                    <para>
                     Another example that illustrates a layer is an application.  
                     Suppose you are creating an application that has library or other dependencies in 
                     order for it to compile and run.  
@@ -137,16 +140,17 @@
                     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 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.  
+                    "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-filelayout'>Example Filesystem Layout</ulink>"
+                    section of the Board Support Package (BSP) Development Guide.  
                     In the standard layout, you will notice a suggested structure for recipes and  
                     configuration information.  
                     You can see the standard layout for the Crown Bay BSP in this example by examining the 
                     directory structure of the <filename>meta-crownbay</filename> layer inside the 
                     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> directories within the 
-                    BSP layer.
+                    layer</emphasis>:  The standard BSP layer structure organizes the files you need 
+                    to edit in <filename>conf</filename> and several <filename>recipes-*</filename>
+                    directories within the BSP layer.
                     Configuration changes identify where your new layer is on the local system
                     and identify which kernel you are going to use.
                     </para></listitem>
@@ -160,7 +164,8 @@
                     You need to get the build environment ready by sourcing an environment setup script 
                     and you need to be sure two key configuration files are configured appropriately.</para>
                     <para>The entire process for building an image is overviewed in the section
-                    "<ulink url='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.    
+                    "<ulink url='&YOCTO_DOCS_QS_URL;#building-image'>Building an Image</ulink>" section 
+                    of the Yocto Project Quick Start.    
                     You might want to reference this information.</para></listitem>
                 <listitem><para><emphasis>Build the image</emphasis>:  The Yocto Project uses the BitBake 
                     tool to build images based on the type of image you want to create.  
@@ -168,9 +173,9 @@
                     <ulink url='http://bitbake.berlios.de/manual/'>here</ulink>.</para>
                     <para>The build process supports several types of images to satisfy different needs.  
                     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>
+                    "<ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Reference: Images</ulink>" appendix 
+                    in The Yocto Project Reference Manual for information on 
+                    supported images.</para></listitem>
             </orderedlist>
         </para>
 
@@ -178,10 +183,10 @@
             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/latest/bsp-guide/bsp-guide.html'>
+            <ulink url='&YOCTO_DOCS_BSP_URL;'>
             The Board Support Package (BSP) Development Guide</ulink>.
             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'>
+            <ulink url='&YOCTO_WIKI_URL;/wiki/Transcript:_creating_one_generic_Atom_BSP_from_another'>
             here</ulink> that you might find helpful.
        </para>
     </section>
@@ -201,7 +206,7 @@
             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/latest/kernel-manual/kernel-manual.html'>
+            <ulink url='&YOCTO_DOCS_KERNEL_URL;'>
             The Yocto Project Kernel Architecture and Use Manual</ulink>.
             You can reference the appendix 
             "<link linkend='dev-manual-kernel-appendix'>Kernel Modification Example</link>"
@@ -221,18 +226,24 @@
 
             <para>
                 You can find a web interface to the Linux Yocto kernel source repositories at
-                <ulink url='http://git.yoctoproject.org/'></ulink>.
+                <ulink url='&YOCTO_GIT_URL;'></ulink>.
                 If you look at the interface, you will see to the left a grouping of 
                 Git repositories titled "Yocto Linux Kernel."  
-                Within this group, you will find the four different kernels supported by 
+                Within this group, you will find several kernels supported by 
                 the Yocto Project:
                 <itemizedlist>
                     <listitem><para><emphasis><filename>linux-yocto-2.6.34</filename></emphasis> - The 
                     stable Linux Yocto kernel that is based on the Linux 2.6.34 release.</para></listitem>
                     <listitem><para><emphasis><filename>linux-yocto-2.6.37</filename></emphasis> - The
                     stable Linux Yocto kernel that is based on the Linux 2.6.37 release.</para></listitem>
-                    <listitem><para><emphasis><filename>linux-yocto-3.0</filename></emphasis> - The current
+                    <listitem><para><emphasis><filename>linux-yocto-3.0</filename></emphasis> - The stable
                     Linux Yocto kernel that is based on the Linux 3.0 release.</para></listitem>
+                    <listitem><para><emphasis><filename>linux-yocto-3.0-1.1.x</filename></emphasis> - The 
+                    stable Linux Yocto kernel to use with the Yocto Project Release 1.1.x. This kernel 
+                    is based on the Linux 3.0 release</para></listitem>
+                    <listitem><para><emphasis><filename>linux-yocto-3.2</filename></emphasis> - The 
+                    stable Linux Yocto kernel to use with the Yocto Project Release 1.2. This kernel 
+                    is based on the Linux 3.2 release</para></listitem>
                     <listitem><para><emphasis><filename>linux-yocto-dev</filename></emphasis> - A development
                     kernel based on the latest upstream release candidate available.</para></listitem>
                 </itemizedlist>
@@ -274,7 +285,7 @@
             </para>
 
             <note>
-                Keep in mind the figure does not take into account all four supported Linux Yocto
+                Keep in mind the figure does not take into account all the supported Linux Yocto
                 kernel types, but rather shows a single generic kernel just for conceptual purposes.
                 Also keep in mind that this structure represents the Yocto Project source repositories 
                 that are either pulled from during the build or established on the host development system
@@ -311,7 +322,7 @@
             </para>
 
             <para>
-                <imagedata fileref="figures/kernel-overview-3.png" 
+                <imagedata fileref="figures/kernel-overview-3-edison.png" 
                     width="6in" depth="4in" align="center" scale="100" />
             </para> 
 
@@ -349,11 +360,11 @@
             <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/latest/kernel-manual/kernel-manual.html'>
+                see <ulink url='&YOCTO_DOCS_KERNEL_URL;'>
                 The Yocto Project Kernel Architecture and Use Manual</ulink>.
-                Also, you can reference 
-                <xref linkend='modifying-the-kernel-source-code'>Modifying the Kernel Source Code</xref>
-                for a detailed example that modifies the kernel.
+                You can also reference the
+                "<link linkend='modifying-the-kernel-source-code'>Modifying the Kernel Source Code</link>"
+                section for a detailed example that modifies the kernel.
             </para>
         </section> 
 
@@ -373,8 +384,8 @@
                 <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/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
+                        "<ulink url='&YOCTO_DOCS_QS_URL;#the-linux-distro'>The Linux Distributions</ulink>" and  
+                        "<ulink url='&YOCTO_DOCS_QS_URL;#packages'>The Packages</ulink>" sections both
                         in the Yocto Project Quick Start for requirements.</para></listitem>
                     <listitem><para><emphasis>Establish a local copy of the Yocto Project files on your 
                         system</emphasis>:  Having the Yocto Project files on your system gives you access to 
@@ -431,8 +442,8 @@
                         <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>                      
+                        changes into a config fragment to be referenced from within the kernel's   
+                        <filename>.bbappend</filename> file.</para></listitem>                      
                     <listitem><para><emphasis>Add or extend kernel recipes if applicable</emphasis>:  
                         The standard 
                         layer structure organizes recipe files inside the 
@@ -446,14 +457,15 @@
                     <listitem><para><emphasis>Prepare for the build</emphasis>:  Once you have made all the 
                         changes to your kernel (configurations, source code changes, recipe additions, 
                         or recipe changes), there remains a few things 
-                        you need to do in order for the Yocto Project build system to create your image.  
+                        you need to do in order for the Yocto Project build system (BitBake) 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/latest/yocto-project-qs/yocto-project-qs.html#building-image'>Building an Image</ulink>" section of the Yocto Project Quick Start.    
+                        "<ulink url='&YOCTO_DOCS_QS_URL;#building-image'>Building an Image</ulink>" 
+                        section of the Yocto Project Quick Start.    
                         You might want to reference this information.
                         Also, you should look at the detailed examples found in the appendices at 
                         at the end of this manual.</para></listitem>
@@ -464,10 +476,8 @@
                         <ulink url='http://bitbake.berlios.de/manual/'>here</ulink>.</para>
                         <para>The build process supports several types of images to satisfy different needs.  
                         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>
+                        "<ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Reference: Images</ulink>" in 
+                        The Yocto Project Reference Manual for information on supported images.</para></listitem>
                     <listitem><para><emphasis>Make your configuration changes available
                         in the kernel layer</emphasis>:  Up to this point, all the configuration changes to the 
                         kernel have been done and tested iteratively.  
@@ -517,7 +527,7 @@
             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'>
+            <ulink url='&YOCTO_DOCS_ADT_URL;'>
             The Application Development Toolkit (ADT) User's Manual</ulink>.
         </para>
 
@@ -534,8 +544,8 @@
             <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
+                    "<ulink url='&YOCTO_DOCS_QS_URL;#the-linux-distro'>The Linux Distributions</ulink>" and  
+                    "<ulink url='&YOCTO_DOCS_QS_URL;#packages'>The Packages</ulink>" sections both
                     in the Yocto Project Quick Start for requirements.</para></listitem>
 
 <!--
@@ -560,15 +570,15 @@ WRITER NOTE:  The areas to get the kernel and root filesystem are located in the
                     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.
+                    (QEMU or real hardware), the area from which you get the image differs.
                         <itemizedlist>
                             <listitem><para>Download the image from  
-                                <ulink url='http://www.yoctoproject.org/downloads/yocto-1.1/machines/'>  
+                                <ulink url='&YOCTO_MACHINES_DL_URL;'>  
                                 <filename>machines</filename></ulink> if your target architecture is supported
                                 and you are going to develop and test your application on actual hardware. 
                                 </para></listitem>
                             <listitem><para>Download the image from the 
-                                <ulink url='http://www.yoctoproject.org/downloads/yocto-1.1/machines/qemu/'>  
+                                <ulink url='&YOCTO_QEMU_DL_URL;'>  
                                 <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>
@@ -583,10 +593,8 @@ WRITER NOTE:  The areas to get the kernel and root filesystem are located in the
                         </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>
+                    "<ulink url='&YOCTO_DOCS_QS_URL;#using-pre-built'>Using Pre-Built Binaries and QEMU</ulink>"
+                    section in the Yocto Project Quick Start.</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.
@@ -594,9 +602,9 @@ WRITER NOTE:  The areas to get the kernel and root filesystem are located in the
                     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>
+                    "<ulink url='&YOCTO_DOCS_ADT_URL;#using-the-adt-installer'>Using the ADT Installer</ulink>"
+                    section 
+                    in the Yocto Project Application Development (ADT) User's Manual.</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 
@@ -640,14 +648,14 @@ WRITER NOTE:  The areas to get the kernel and root filesystem are located in the
             <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>
+                    "<ulink url='&YOCTO_DOCS_ADT_URL;#using-an-existing-toolchain-tarball'>Using a Cross-Toolchain Tarball</ulink>" 
+                    section
+                    in the Yocto Project Application Development (ADT) User's Manual.</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/'>  
+                    <ulink url='&YOCTO_MACHINES_DL_URL;'>  
                     <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   
@@ -657,7 +665,7 @@ WRITER NOTE:  The areas to get the kernel and root filesystem are located in the
                     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/'>  
+                    <ulink url='&YOCTO_QEMU_DL_URL;'>  
                     <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 
@@ -665,7 +673,7 @@ WRITER NOTE:  The areas to get the kernel and root filesystem are located in the
                     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 
+                    "<ulink url='&YOCTO_DOCS_ADT_URL;#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.  

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

@@ -1,5 +1,6 @@
 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <chapter id='dev-manual-newbie'>
 
@@ -58,7 +59,7 @@
 
     <para>
         The Yocto Project team maintains complete source repositories for all Yocto Project files 
-        <ulink url='http://git.yoctoproject.org/cgit/cgit.cgi'>here</ulink>.
+        at <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi'></ulink>.
         This web-based source code browser is organized into categories by function such as
         IDE Plugins, Matchbox, Poky, Yocto Linux Kernel, and so forth.
         From the interface, you can click on any particular item in the "Name" column and 
@@ -79,7 +80,7 @@
 
     <para>
         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 
+        <ulink url='&YOCTO_HOME_URL;/download'>download page</ulink> and get a 
         tarball of the release.  
         You can also go to this site to download any supported BSP tarballs.
         Unpacking the tarball gives you a hierarchical directory structure of Yocto Project 
@@ -94,15 +95,15 @@
     <para>
         In summary, here is where you can get the Yocto Project files needed for development:
         <itemizedlist>
-            <listitem><para><emphasis><ulink url='http://git.yoctoproject.org/cgit/cgit.cgi'>Source Repositories:</ulink></emphasis>
+            <listitem><para><emphasis><ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi'>Source Repositories:</ulink></emphasis>
                 This area contains IDE Plugins, Matchbox, Poky, Poky Support, Tools, Yocto Linux Kernel, and Yocto 
                 Metadata Layers.
                 You can create Git repositories for each of these areas.</para>
                 <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://downloads.yoctoproject.org/releases/'>Index of /releases:</ulink></emphasis>
-                This area contains an index of downloads such as 
+            <listitem><para><anchor id='index-downloads' /><emphasis><ulink url='&YOCTO_DL_URL;/releases/'>Index of /releases:</ulink></emphasis>
+                This area contains index releases such as 
                 the <trademark class='trade'>Eclipse</trademark>
                 Yocto Plug-in, miscellaneous support, Poky, pseudo, cross-development toolchains,
                 and all released versions of Yocto Project in the form of images or tarballs.
@@ -111,11 +112,11 @@
                 <para>
                 <imagedata fileref="figures/index-downloads.png" align="center" width="6in" depth="4in" />
                 </para></listitem>
-            <listitem><para><emphasis><ulink url='http://www.yoctoproject.org/download'>Yocto Project Download Page</ulink></emphasis>
+            <listitem><para><emphasis><ulink url='&YOCTO_HOME_URL;/download'>Yocto Project Download Page</ulink></emphasis>
                 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://downloads.yoctoproject.org/releases/'>Index of /releases:</ulink> area.</para>
+                <ulink url='&YOCTO_DL_URL;/releases/'>Index of /releases:</ulink> area.</para>
                 <para>
                 <imagedata fileref="figures/yp-download.png" align="center" width="6in" depth="4in" />
             </para></listitem>
@@ -133,7 +134,7 @@
     <itemizedlist>
         <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.
+            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>BitBake:</emphasis> The task executor and scheduler used by 
             the Yocto Project to build images. 
@@ -143,12 +144,12 @@
             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
+        <listitem><para><emphasis>Configuration File:</emphasis>  Configuration information in the 
+            <filename>.conf</filename> files provides global definitions of variables.  
+            The <filename>conf/local.conf</filename> configuration file in the Yocto Project 
+            build directory defines user-defined variables that affect each build.  
+            The <filename>distro/poky.conf</filename> configuration file also in the 
+            build directory 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
@@ -159,7 +160,7 @@
         <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.
+            an architecure.
             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
@@ -170,10 +171,8 @@
             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/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>
+            "<ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Reference: Images</ulink>"
+            appendix in the Yocto Project Reference Manual.</para></listitem>
         <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> The files that BitBake parses when building an image. 
@@ -216,14 +215,14 @@
             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>
+            For example, downloading and unpacking <filename>&YOCTO_POKY_TARBALL;</filename>
             results in a Yocto Project file structure whose Yocto Project source directory is named 
-            <filename>poky-edison-6.0</filename>.
+            <filename>&YOCTO_POKY;</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
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#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.  
@@ -233,9 +232,9 @@
             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>:
+            and names the Yocto Project build directory <filename>YP-&POKYVERSION;</filename>:
             <literallayout class='monospaced'> 
-     $ source poky-edison-6.0/oe-init-build-env $HOME/mybuilds/YP-6.0
+     $ source &OE_INIT_PATH; $HOME/mybuilds/YP-&POKYVERSION;
             </literallayout>
             If you don't specifically name the directory, BitBake creates it 
             in the current directory and uses the name <filename>build</filename>.
@@ -305,7 +304,7 @@
 
     <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>.
+        <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta/files/common-licenses'>here</ulink>.
         This wiki page discusses the license infrastructure used by the Yocto Project.
     </para>
 </section>
@@ -316,7 +315,10 @@
     <para>
         The Yocto Project uses Git, which is a free, open source distributed version control system.  
         Git supports distributed development, non-linear development, and can handle large projects.  
-        It is best that you know how to work with Git if you are going to use Yocto Project for development.  
+        It is best that you have some fundamental understanding of how Git tracks projects and 
+        how to work with Git if you are going to use Yocto Project for development. 
+        This section provides a quick overview of how Git works and provides you with a summary
+        of some essential Git commands.
     </para>
 
     <para>
@@ -369,7 +371,7 @@
             will allow the change, and for ultimately pushing the change from your local Git repository 
             into the project’s upstream (or master) repository.</para></listitem>
         <listitem><para><emphasis><filename>git status</filename>:</emphasis> Reports any modified files that 
-            possibly need to be added and committed.</para></listitem>
+            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>
@@ -486,8 +488,8 @@
         While each development environment is unique, there are some best practices or methods 
         that help development run smoothly.  
         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>. 
+        For more information about Git workflows, see the workflow topics in the 
+        <ulink url='http://book.git-scm.com'>Git Community Book</ulink>. 
         <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.  
@@ -551,7 +553,7 @@
         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. 
         The home page for the Yocto Project implementation of Bugzilla is   
-        <ulink url='http://bugzilla.yoctoproject.org'>http://bugzilla.yoctoproject.org</ulink>.
+        <ulink url='&YOCTO_BUGZILLA_URL;'>&YOCTO_BUGZILLA_URL;</ulink>.
     </para>
 
     <para>
@@ -562,7 +564,7 @@
         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>.     
+        <ulink url='&YOCTO_WIKI_URL;/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>
@@ -605,12 +607,13 @@
 
     <para>
         Contributions to the Yocto Project are very welcome. 
+        Because the Yocto Project is extremely configurable and flexible, we recognize that developers 
+        will want to extend, configure or optimize it for their specific uses.
         You should send patches to the appropriate Yocto Project mailing list to get them 
         in front of the Yocto Project Maintainer.
         For a list of the Yocto Project mailing lists, see the
-        "<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>.
+        "<ulink url='&YOCTO_DOCS_REF_URL;#resources-mailinglist'>Mailing lists</ulink>" section in 
+        The Yocto Project Reference Manual.
     </para>
 
     <para>
@@ -618,14 +621,14 @@
         <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. 
+                <ulink url='&YOCTO_LISTS_URL;/listinfo/poky'></ulink> mailing list. 
                 This mailing list corresponds to issues that are not specific to the Yocto Project but
                 are part of the OE-core.
                 For example, a defect against anything in the <filename>meta</filename> layer 
                 or the BitBake Manual could be sent to this mailing list.</para></listitem>
             <listitem><para>For defects against Yocto-specific layers, tools, and Yocto Project 
                 documentation use the 
-                <ulink url='http://lists.yoctoproject.org/listinfo/yocto'></ulink> mailing list.
+                <ulink url='&YOCTO_LISTS_URL;/listinfo/yocto'></ulink> mailing list.
                 This mailing list corresponds to Yocto-specific areas such as 
                 <filename>meta-yocto</filename>, <filename>meta-intel</filename>, 
                 <filename>linux-yocto</filename>, and <filename>documentation</filename>.</para></listitem>
@@ -675,7 +678,10 @@
     <para>
         In a collaborative environment, it is necessary to have some sort of standard 
         or method through which you submit changes.  
-        Otherwise, things could get quite chaotic.  
+        Otherwise, things could get quite chaotic.
+        One general practice to follow is to make small, controlled changes to the 
+        Yocto Project.
+        Keeping changes small and isolated lets you best keep pace with future Yocto Project changes.
     </para>
 
     <para>
@@ -713,7 +719,7 @@
     <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>.
+        <ulink url='&OE_HOME_URL;/wiki/Commit_Patch_Message_Guidelines'></ulink>.
     </para>
 
     <para>
@@ -751,9 +757,8 @@
         </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>.
+            You can find general Git information on how to push a change upstream in the 
+            <ulink url='http://book.git-scm.com/3_distributed_workflows.html'>Git Community Book</ulink>.
         </para>
     </section>
 
@@ -778,7 +783,7 @@
                     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.
+                <listitem><para>Format the commit into an email message.
                     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.

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

@@ -1,5 +1,6 @@
 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <chapter id='dev-manual-start'>
 
@@ -9,7 +10,7 @@
     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 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'>
+    <ulink url='&YOCTO_DOCS_QS_URL;'>
     The Yocto Project Quick Start</ulink>.
 </para>
 
@@ -30,7 +31,8 @@
     </para>
 
     <para>
-        You can use the Yocto Project, which uses the BitBake build tool, to develop complete Linux 
+        You can use the Yocto Project build system, which uses 
+        <ulink url='http://bitbake.berlios.de/manual/'>BitBake</ulink>, to develop complete Linux 
         images and associated user-space applications for architectures based on ARM, MIPS, PowerPC, 
         x86 and x86-64.  
         While the Yocto Project does not provide a strict testing framework,
@@ -57,7 +59,7 @@
                 </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/latest/yocto-project-qs/yocto-project-qs.html#packages'>The Packages</ulink>" 
+                See "<ulink url='&YOCTO_DOCS_QS_URL;#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>
@@ -73,29 +75,37 @@
                 <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 
-                        from the website’s <ulink url='http://yoctoproject.org/download'>download page</ulink>.
+                        from the website’s <ulink url='&YOCTO_HOME_URL;/download'>download page</ulink>.
                         Once you have the tarball, just extract it into a directory of your choice.</para>
-                        <para>For example, the following command extracts the Yocto Project 1.1 release tarball 
+                        <para>For example, the following command extracts the Yocto Project &DISTRO; 
+                        release tarball 
                         into the current working directory and sets up the Yocto Project file structure
-                        with a top-level directory named <filename>poky-edison-6.0</filename>:
+                        with a top-level directory named <filename>&YOCTO_POKY;</filename>:
                         <literallayout class='monospaced'>
-     $ tar xfj poky-edison-6.0.tar.bz2
+     $ tar xfj &YOCTO_POKY_TARBALL;
                         </literallayout></para>
                         <para>This method does not produce a Git repository. 
                         Instead, you simply end up with a local snapshot of the 
                         Yocto Project files that are based on the particular release in the 
                         tarball.</para></listitem>
                     <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 
-                        Git repository of the Yocto Project files.  
+                        back into the Yocto Project or you simply want to keep up
+                        with the latest developments, you should use Git commands to set up a local
+                        Git repository of the Yocto Project files.
                         Doing so creates a Git repository with a complete history of changes and allows 
-                        you to easily submit your changes upstream to the project.</para>
-                       <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 the
-                       "<link linkend='git'>Git</link>" section.
-                       <literallayout class='monospaced'>
+                        you to easily submit your changes upstream to the project.
+                        Because you cloned the repository, you have access to all the Yocto Project development
+                        branches and tag names used in the upstream repository.</para>
+                        <para>The following transcript shows how to clone the Yocto Project Files'  
+                        Git repository into the current working directory.
+                        <note>The name of the Yocto Project Files Git repository in the Yocto Project Files
+                        Source Repositories is <filename>poky</filename>.
+                        You can view the Yocto Project Source Repositories at
+                        <ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink></note>  
+                        The command creates the local repository in a directory named <filename>poky</filename>.
+                        For information on Git used within the Yocto Project, see the
+                        "<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: 116882, done.
@@ -104,68 +114,78 @@
      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'>
+                        <ulink url='&YOCTO_WIKI_URL;/wiki/Transcript:_from_git_checkout_to_meta-intel_BSP'>
                         wiki page</ulink>, which describes how to create both <filename>poky</filename>
                         and <filename>meta-intel</filename> Git repositories.</para></listitem>
                 </itemizedlist></para></listitem>
             <listitem id='local-kernel-files'><para><emphasis>Linux Yocto Kernel:</emphasis>  
                 If you are going to be making modifications to a supported Linux Yocto kernel, you 
                 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 find Git repositories of supported Linux Yocto Kernels organized under
+                "Yocto Linux Kernel" in the Yocto Project Source Repositories at
+                <ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink>.</para>
+                <para>This setup involves creating a bare clone of the Linux Yocto kernel and then 
+                copying that cloned repository.
                 You can create the bare clone and the copy of the bare clone anywhere you like.
                 For simplicity, it is recommended that you create these structures outside of the 
                 Yocto Project files' Git repository.</para>
                 <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 
+                of the <filename>linux-yocto-3.0-1.1.x</filename> kernel and then create a copy of 
                 that clone.
                 <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></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>: 
+                <filename>linux-yocto-3.0-1.1.x.git</filename>, while the 
+                copy is named <filename>my-linux-yocto-3.0-1.1.x-work</filename>: 
                 <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/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>
+     $ git clone --bare git://git.yoctoproject.org/linux-yocto-3.0-1.1.x linux-yocto-3.0-1.1.x.git
+     Initialized empty Git repository in /home/scottrif/linux-yocto-3.0-1.1.x.git/
+     remote: Counting objects: 2259181, done.
+     remote: Compressing objects: 100% (373259/373259), done.
+     remote: Total 2259181 (delta 1892638), reused 2231556 (delta 1865300)
+     Receiving objects: 100% (2259181/2259181), 482.44 MiB | 580 KiB/s, done.
+     Resolving deltas: 100% (1892638/1892638), done.
+                </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/linux-yocto-3.0/.git/
-     Checking out files: 100% (36898/36898), done.                </literallayout></para></listitem>
+     $ git clone linux-yocto-3.0-1.1.x.git my-linux-yocto-3.0-1.1.x-work
+     Initialized empty Git repository in /home/scottrif/my-linux-yocto-3.0-1.1.x/.git/
+     Checking out files: 100% (36898/36898), done.
+                </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 
                 only if you are modifying and building the kernel image.
-                In particular, it contains the kernel <filename>.bbappend</filename> files that you 
+                In particular, it contains the kernel BitBake append (<filename>.bbappend</filename>)
+                files that you 
                 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>
-                <para>It is good practice to create this Git repository inside the Yocto Project
-                files Git repository.
-                Following is an example that creates the <filename>poky-extras</filename> Git 
+                <para>You can find the <filename>poky-extras</filename> Git Repository in the 
+                "Yocto Metadata Layers" area of the Yocto Project Source Repositories at 
+                <ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink>.
+                It is good practice to create this Git repository inside the Yocto Project
+                files Git repository.</para>
+                <para>Following is an example that creates the <filename>poky-extras</filename> Git 
                 repository inside the Yocto Project files Git repository, which is named 
                 <filename>poky</filename> in this case:
                 <literallayout class='monospaced'>
-     $ cd ~/poky
      $ git clone git://git.yoctoproject.org/poky-extras poky-extras
      Initialized empty Git repository in /home/scottrif/poky/poky-extras/.git/
-     remote: Counting objects: 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>
+     remote: Counting objects: 561, done.
+     remote: Compressing objects: 100% (501/501), done.
+     remote: Total 561 (delta 159), reused 306 (delta 39)
+     Receiving objects: 100% (561/561), 519.96 KiB | 479 KiB/s, done.
+     Resolving deltas: 100% (159/159), done.
+                </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.
+                It is a good idea to use the same method used to set up the Yocto Project Files.
                 Regardless of the method you use, the Yocto Project uses the following BSP layer 
                 naming scheme:
                 <literallayout class='monospaced'> 
@@ -181,31 +201,33 @@
                 <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> used 
+                        <ulink url='&YOCTO_HOME_URL;/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 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 Yocto Project files Git repository.</para>
-                        <para>For example, the following transcript shows the steps to clone the 
+                        with a Yocto Project Files Git repository, you should also use this method 
+                        to set up the <filename>meta-intel</filename> Git repository.
+                        You can locate the <filename>meta-intel</filename> Git repository in the 
+                        "Yocto Metadata Layers" area of the Yocto Project Source Repositories at
+                        <ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink>.</para>
+                        <para>Typically, you set up the <filename>meta-intel</filename> Git repository inside
+                        the Yocto Project Files Git repository.
+                        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
      $ git clone git://git.yoctoproject.org/meta-intel.git
      Initialized empty Git repository in /home/scottrif/poky/meta-intel/.git/
-     remote: Counting objects: 1325, done.
-     remote: Compressing objects: 100% (1078/1078), done.
-     remote: Total 1325 (delta 546), reused 85 (delta 27)
-     Receiving objects: 100% (1325/1325), 1.56 MiB | 330 KiB/s, done.
-     Resolving deltas: 100% (546/546), done.
+     remote: Counting objects: 3279, done.
+     remote: Compressing objects: 100% (2708/2708), done.
+     remote: Total 3279 (delta 1761), reused 194 (delta 105)
+     Receiving objects: 100% (3279/3279), 1.75 MiB | 377 KiB/s, done.
+     Resolving deltas: 100% (1761/1761), done.
                         </literallayout></para>
                         <para>The same  
-                        <ulink url='https://wiki.yoctoproject.org/wiki/Transcript:_from_git_checkout_to_meta-intel_BSP'>
+                        <ulink url='&YOCTO_WIKI_URL;/wiki/Transcript:_from_git_checkout_to_meta-intel_BSP'>
                         wiki page</ulink> referenced earlier covers how to 
                         set up the <filename>meta-intel</filename> Git repository.</para></listitem>
                 </itemizedlist></para></listitem>
@@ -213,7 +235,7 @@
                 applications using the Eclipse Integrated Development Environment (IDE),
                 you will need this plug-in.  
                 See the 
-                "<ulink url='http://www.yoctoproject.org/docs/latest/adt-manual/adt-manual.html#setting-up-the-eclipse-ide'>Setting up the Eclipse IDE</ulink>"
+                "<ulink url='&YOCTO_DOCS_ADT_URL;#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>
@@ -226,7 +248,7 @@
     <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/latest/yocto-project-qs/yocto-project-qs.html#building-image'>Building an Image</ulink>"
+        "<ulink url='&YOCTO_DOCS_QS_URL;#building-image'>Building an Image</ulink>"
         section in the Yocto Project Quick Start.
     </para>
 
@@ -237,12 +259,20 @@
                 previous section.</para></listitem>
             <listitem><para>Initialize the build environment by sourcing a build environment 
                 script.</para></listitem>
-            <listitem><para>Optionally ensure the <filename>conf/local.conf</filename> configuration file is set 
-                up how you want it.  
-                This file defines the target machine architecture and other build options.</para></listitem>
-            <listitem><para>Build the image using the <command>bitbake</command> command.
+            <listitem><para>Optionally ensure the <filename>/conf/local.conf</filename> configuration file, 
+                which is found in the Yocto Project build directory, 
+                is set up how you want it.  
+                This file defines many aspects of the build environment including 
+                the target machine architecture through the 
+                <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'>MACHINE</ulink></filename> variable, 
+                the development machine's processor use through the 
+                <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-BB_NUMBER_THREADS'>BB_NUMBER_THREADS</ulink></filename> and 
+                <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PARALLEL_MAKE'>PARALLEL_MAKE</ulink></filename> variables, and
+                a centralized tarball download directory through the  
+                <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-DL_DIR'>DL_DIR</ulink></filename> variable.</para></listitem>
+            <listitem><para>Build the image using the <filename>bitbake</filename> command.
                 If you want information on BitBake, see the user manual at
-                <ulink url='http://docs.openembedded.org/bitbake/html'></ulink>.</para></listitem>
+                <ulink url='&OE_DOCS_URL;/bitbake/html'></ulink>.</para></listitem>
             <listitem><para>Run the image either on the actual hardware or using the QEMU 
                 emulator.</para></listitem>
         </orderedlist>
@@ -253,18 +283,37 @@
     <title>Using Pre-Built Binaries and QEMU</title>
 
     <para>
-        Another option you have to get started is to use pre-built binaries.  
-        This scenario is ideal for developing software applications to run on your target hardware.  
-        To do this, you need to install the stand-alone Yocto Project cross-toolchain tarball and 
-        then download the pre-built kernel that you will boot in the QEMU emulator.  
-        Next, you must download and extract the target root filesystem for your target 
-        machine’s architecture.  
-        Finally, you set up the environment to emulate the hardware and then start the QEMU emulator.
+        Another option you have to get started is to use pre-built binaries. 
+        The Yocto Project provides many types of binaries with each release. 
+        See the <ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Reference: Images</ulink>
+        section for descriptions of the types of binaries that ship with a Yocto Project
+        release.
     </para>
 
     <para>
+        Using a pre-built binary is ideal for developing software applications to run on your 
+        target hardware.  
+        To do this, you need to be able to access the appropriate cross-toolchain tarball for 
+        the architecture on which you are developing.  
+        If you are using an SDK type image, the image ships with the complete toolchain native to 
+        the architecture. 
+        If you are not using an SDK type image, you need to separately download and 
+        install the stand-alone Yocto Project cross-toolchain tarball.
+    </para>
+
+    <para>
+        Regardless of the type of image you are using, you need to download the pre-built kernel 
+        that you will boot in the QEMU emulator and then download and extract the target root 
+        filesystem for your target machine’s architecture.
+        You can get architecture-specific binaries and filesystem from
+        <ulink url='&YOCTO_MACHINES_DL_URL;'>machines</ulink>.
+        You can get stand-alone toolchains from
+        <ulink url='&YOCTO_TOOLCHAIN_DL_URL;'>toolchains</ulink>.
+        Once you have all your files, you set up the environment to emulate the hardware 
+        by sourcing an environment setup script. 
+        Finally, you start the QEMU emulator.
         You can find details on all these steps in the 
-        "<ulink url='http://www.yoctoproject.org/docs/latest/yocto-project-qs/yocto-project-qs.html#using-pre-built'>Using Pre-Built Binaries and QEMU</ulink>"
+        "<ulink url='&YOCTO_DOCS_QS_URL;#using-pre-built'>Using Pre-Built Binaries and QEMU</ulink>"
         section of the Yocto Project Quick Start. 
     </para>
 </section>

documentation/dev-manual/dev-manual.xml

@@ -1,5 +1,6 @@
 <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <book id='dev-manual' lang='en' 
       xmlns:xi="http://www.w3.org/2003/XInclude"
@@ -33,10 +34,20 @@
                 <date>6 October 2011</date>
                 <revremark>The initial document released with the Yocto Project 1.1 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>1.1.1</revnumber>
+                <date>15 March 2012</date>
+                <revremark>Released with the Yocto Project 1.1.1 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.1.2</revnumber>
+                <date>July 2012</date>
+                <revremark>Released with the Yocto Project 1.1.2 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>
-     <year>2010-2011</year>
+     <year>&COPYRIGHT_YEAR;</year>
       <holder>Linux Foundation</holder>
     </copyright>
 
@@ -51,9 +62,9 @@
       <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/latest/dev-manual/dev-manual.html'>
+          <ulink url='&YOCTO_DOCS_DEV_URL;'>
           The Yocto Project Development Manual</ulink> on
-          the <ulink url='http://www.yoctoproject.org'>Yocto Project</ulink> website.
+          the <ulink url='&YOCTO_HOME_URL;'>Yocto Project</ulink> website.
           For the latest version of this manual, see the manual on the website.
       </note>
     </legalnotice>

documentation/dev-manual/style.css

@@ -435,6 +435,7 @@ b.keycap,
   font-family: Courier, monospace;
 }
 
+
 div.navheader, div.heading{
   position: absolute;
   left: 0em;
@@ -653,7 +654,7 @@ hr {
 
 
 .tip, .warning, .caution, .note {
-  border-color: #aaa;
+  border-color: #fff;
 }
 
 
@@ -661,24 +662,24 @@ hr {
 .warning table th,
 .caution table th,
 .note table th {
-  border-bottom-color: #aaa;
+  border-bottom-color: #fff;
 }
 
 
 .warning {
-  background-color: #fea;
+  background-color: #f0f0f2;
 }
 
 .caution {
-  background-color: #fea;
+  background-color: #f0f0f2;
 }
 
 .tip {
-  background-color: #eff;
+  background-color: #f0f0f2;
 }
 
 .note {
-  background-color: #dfc;
+  background-color: #f0f0f2; 
 }
 
 .glossary dl dt, 
@@ -945,8 +946,8 @@ table {
 
 .tip,
 .note {
-   background: #666666;
-   color: #fff;   
+   background: #f0f0f2; 
+   color: #333;   
    padding: 20px;
    margin: 20px;
 }
@@ -957,12 +958,12 @@ table {
    margin: 0em;
    font-size: 2em;
    font-weight: bold;
-   color: #fff;   
+   color: #333;   
 }
 
 .tip a,
 .note a {
-   color: #fff;   
+   color: #333;   
    text-decoration: underline;
 }
 
@@ -971,3 +972,12 @@ table {
    color: #333;
 }
 
+/* Changes the announcement text */
+.tip h3,
+.warning h3,
+.caution h3,
+.note h3 {
+   font-size:large;
+   color: #00557D;
+}
+

documentation/kernel-manual/kernel-concepts.xml

@@ -1,5 +1,6 @@
 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <chapter id='kernel-concepts'>
 
@@ -160,9 +161,8 @@
                 The features are tagged and organized by way of a branching strategy implemented by the 
                 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>.
+                "<ulink url='&YOCTO_DOCS_DEV_URL;#git'>Git</ulink>" section in the 
+                Yocto Project Development Manual.
             </para>
             <para>
                 The result is that the user has the ability to see the added features and 
@@ -289,9 +289,8 @@
             <para>
                 You can find documentation on Git at <ulink url='http://git-scm.com/documentation'></ulink>.
                 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>. 
+                "<ulink url='&YOCTO_DOCS_DEV_URL;#git'>Git</ulink>"
+                section in the Yocto Project Development Manual. 
                 These referenced sections overview Git and describe a minimal set of 
                 commands that allow you to be functional using Git.
                 <note>
@@ -337,11 +336,6 @@ kernel toolkit:
 </itemizedlist>
 </para> -->
     </section> 
-
-
-
-
-
 </chapter>
 <!--
 vim: expandtab tw=80 ts=4

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

@@ -1,5 +1,6 @@
 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <chapter id='kernel-doc-intro'>
 
@@ -46,21 +47,21 @@
 
     <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>:
+        in <ulink url='&YOCTO_DOCS_DEV_URL;'>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>
+                "<ulink url='&YOCTO_DOCS_DEV_URL;#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>"
+                "<ulink url='&YOCTO_DOCS_DEV_URL;#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>
+                "<ulink url='&YOCTO_DOCS_DEV_URL;#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>.
+        <ulink url='&YOCTO_HOME_URL;'></ulink>.
     </para>
 </section>
 

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

@@ -1,5 +1,6 @@
 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <chapter id='kernel-how-to'>
 
@@ -27,7 +28,7 @@
             This section describes construction of the Yocto Project kernel repositories 
             as accomplished by the Yocto Project team to create kernel repositories.
             These kernel repositories are found at
-            <ulink url='http://git.yoctoproject.org/cgit.cgi'>http://git.yoctoproject.org/cgit.cgi</ulink>
+            <ulink url='&YOCTO_GIT_URL;/cgit.cgi'>&YOCTO_GIT_URL;/cgit.cgi</ulink>
             and can be shipped as part of a Yocto Project release. 
             The team creates these repositories by
             compiling and executing the set of feature descriptions for every BSP/feature
@@ -51,19 +52,25 @@
             </literallayout>
             For another example of how to set up a local Git repository of the Linux Yocto 
             kernel files, see the 
-            "<ulink url='http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#local-kernel-files'>Linux Yocto Kernel</ulink>" bulleted item in  
-            <ulink url='http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html'>The Yocto Project Development Manual</ulink>.
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#local-kernel-files'>Linux Yocto Kernel</ulink>" bulleted item in The Yocto Project Development Manual.
         </para>
         <para>  
-            Once the Git repository is set up on your local machine, you can switch to the 
-            <filename>meta</filename> branch within the repository.
-            Here, you can see a snapshot of all the kernel configuration and feature descriptions that are 
-            used to build the kernel repository.
+            Once you have cloned the kernel Git repository on your local machine, you can 
+            switch to the <filename>meta</filename> branch within the repository.
+            Here is an example that assumes the local Git repository for the kernel is in 
+            a top-level directory named <filename>linux-yocto-3.0</filename>:
+            <literallayout class='monospaced'>
+     $ cd ~/linux-yocto-3.0
+     $ git checkout -b meta origin/meta
+            </literallayout>
+            Once you have checked out and switched to the <filename>meta</filename> branch,
+            you can see a snapshot of all the kernel configuration and feature descriptions that are 
+            used to build that particular kernel repository.
             These descriptions are in the form of <filename>.scc</filename> files. 
         </para>
         <para>
-            You should realize, however, that browsing your local snapshot of feature
-            descriptions and patches is not an effective way to determine what is in a
+            You should realize, however, that browsing your local kernel repository
+            for feature descriptions and patches is not an effective way to determine what is in a
             particular kernel branch. 
             Instead, you should use Git directly to discover the changes in a branch.
             Using Git is an efficient and flexible way to inspect changes to the kernel.  
@@ -77,10 +84,12 @@
             </note>
         </para>
         <para>
-            The following steps describe what happens when the Yocto kernel team constructs
-            the kernel tree given the introduction of a new top-level kernel feature or BSP. 
-            These are the actions that effectively create the tree that includes the new feature, patch, 
-            or BSP:
+            The following steps describe what happens when the Yocto Project Team constructs
+            the Yocto Linux kernel source Git repository (or tree) found at 
+            <ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink> given the 
+            introduction of a new top-level kernel feature or BSP. 
+            These are the actions that effectively create the tree 
+            that includes the new feature, patch or BSP:
             <orderedlist>
                 <listitem><para>A top-level kernel feature is passed to the kernel build subsystem.
                     Normally, this feature is a BSP for a particular kernel type.</para></listitem>
@@ -127,7 +136,7 @@
                 Any add-ons and configuration data are applied to the end of an existing branch. 
                 The full repository generation that is found in the 
                 official Yocto Project kernel repositories at
-                <ulink url='http://git.yoctoproject.org/cgit.cgi'>http://git.yoctoproject.org/cgit.cgi</ulink>
+                <ulink url='&YOCTO_GIT_URL;/cgit.cgi'>http://git.yoctoproject.org/cgit.cgi</ulink>
                 is the combination of all supported boards and configurations.</para>
                 <para>The technique the Yocto Project team uses is flexible and allows for seamless 
                 blending of an immutable history with additional patches specific to a 
@@ -228,10 +237,8 @@
             You can find Git documentation at 
             <ulink url='http://git-scm.com/documentation'></ulink>.
             You can find a simple overview of using Git with the Yocto Project in the 
-            "<ulink url='http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#git'>Git</ulink>"
-            section of  
-            <ulink url='http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html'>The Yocto 
-            Project Development Manual</ulink>.
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#git'>Git</ulink>"
+            section of The Yocto Project Development Manual.
         </para>
 
         <section id='change-inspection-kernel-changes-commits'>
@@ -246,8 +253,8 @@
                 In projects that have a collection of directories that
                 contain patches to the kernel, it is possible to inspect or "grep" the contents 
                 of the directories to get a general feel for the changes. 
-                This sort of patch inspection is not an efficient way to determine what has been done to the
-                kernel.
+                This sort of patch inspection is not an efficient way to determine what has been 
+                done to the kernel.
                 The reason it is inefficient is because there are many optional patches that are 
                 selected based on the kernel type and the feature description.
                 Additionally, patches could exist in directories that are not included in the search.
@@ -265,9 +272,9 @@
 
                 <para>
                     Following are a few examples that show how to use Git to examine changes.
-                    Because the Yocto Project Git repository does not break existing Git
+                    Note that because the Yocto Project Git repository does not break existing Git
                     functionality and because there exists many permutations of these types of 
-                    commands, there are many more methods to discover changes.
+                    commands there are many more methods to discover changes.
                     <note>
                         Unless you provide a commit range 
                         (&lt;kernel-type&gt;..&lt;bsp&gt;-&lt;kernel-type&gt;), <filename>kernel.org</filename> history 
@@ -301,9 +308,11 @@
                 <title>Show a Particular Feature or Branch Change</title>
 
                 <para>
-                    Significant features or branches are tagged in the Yocto Project tree to divide
-                    changes. 
-                    Remember to first determine (or add) the tag of interest.  
+                    Developers use tags in the Yocto Project tree to divide changes for significant 
+                    features or branches. 
+                    Once you know a particular tag, you can use Git commands 
+                    to show changes associated with the tag and find the branches that contain
+                    the feature.  
                     <note>
                         Because BSP branch, <filename>kernel.org</filename>, and feature tags are all 
                         present, there could be many tags.
@@ -356,10 +365,10 @@
                 The Yocto Project provides scripts that help you work in a collaborative development 
                 environment.  
                 For information on these scripts, see the
-                "<ulink url='http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#pushing-a-change-upstream'>Pushing a Change Upstream and Requesting a Pull</ulink>" and   
-                "<ulink url='http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#submitting-a-patch'>Submitting a Patch Through Email</ulink>" sections in    
-                <ulink url='http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html'>The 
-                Yocto Project Development Manual</ulink>".
+                "<ulink url='&YOCTO_DOCS_DEV_URL;#pushing-a-change-upstream'>Pushing a Change 
+                Upstream and Requesting a Pull</ulink>" and   
+                "<ulink url='&YOCTO_DOCS_DEV_URL;#submitting-a-patch'>Submitting a Patch Through 
+                Email</ulink>" sections in The Yocto Project Development Manual.
             </para>
 
             <para>
@@ -625,8 +634,6 @@
                         community standards for submitting and documenting changes and follow their best practices.  
                         For example, kernel patches should follow standards such as:
                         <itemizedlist>
-                            <listitem><para>
-                                <ulink url='http://userweb.kernel.org/~akpm/stuff/tpp.txt'></ulink></para></listitem>
                             <listitem><para>
                                 <ulink url='http://linux.yyz.us/patch-format.html'></ulink></para></listitem>
                             <listitem><para>Documentation/SubmittingPatches (in any linux 
@@ -639,9 +646,8 @@
                     The messages used to commit changes are a large part of these standards.
                     Consequently, be sure that the headers for each commit have the required information.
                     For information on how to follow the Yocto Project commit message standards, see the
-                    "<ulink url='http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#how-to-submit-a-change'>How to Submit a Change</ulink>" section in  
-                    <ulink url='http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html'>The 
-                    Yocto Project Development Manual</ulink>".
+                    "<ulink url='&YOCTO_DOCS_DEV_URL;#how-to-submit-a-change'>How to Submit a 
+                    Change</ulink>" section in The Yocto Project Development Manual.
                 </para>
 
                 <para>
@@ -743,7 +749,8 @@
                 </para>
 
                 <para>
-                    The following commands illustrate how you can condense and merge two BSPs into a second SCM:
+                    The following commands illustrate how you can condense and merge two BSPs into a 
+                    second SCM:
                     <literallayout class='monospaced'>
      &gt; git checkout yocto/standard/common-pc/base
      &gt; git merge yocto/standard/common-pc-64/base
@@ -774,10 +781,9 @@
                 existing similar BSP.
                 The information is introductory in nature and does not provide step-by-step examples. 
                 For detailed information on how to create a BSP given an existing similar BSP, see
-                the "<ulink url='http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#dev-manual-bsp-appendix'>BSP Development Example</ulink>" appendix in  
-                <ulink url='http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html'>The 
-                Yocto Project Development Manual</ulink>, or see the 
-                <ulink url='https://wiki.yoctoproject.org/wiki/Transcript:_creating_one_generic_Atom_BSP_from_another'>Transcript:_creating_one_generic_Atom_BSP_from_another</ulink>
+                the "<ulink url='&YOCTO_DOCS_DEV_URL;#dev-manual-bsp-appendix'>BSP Development 
+                Example</ulink>" appendix in the Yocto Project Development Manual, or see the 
+                <ulink url='&YOCTO_WIKI_URL;/wiki/Transcript:_creating_one_generic_Atom_BSP_from_another'>Transcript:_creating_one_generic_Atom_BSP_from_another</ulink>
                 wiki page.
             </para>
 
@@ -794,7 +800,7 @@
                         your BSP easier.  
                         You can find all the BSPs that are supported and ship with the Yocto Project 
                         on the Yocto Project's Download page at 
-                        <ulink url='http://www.yoctoproject.org/download'></ulink>.</para></listitem>
+                        <ulink url='&YOCTO_HOME_URL;/download'></ulink>.</para></listitem>
                     <listitem><para><emphasis>Be sure you have the Base BSP:</emphasis>
                         You need to either have the Yocto Project Git repository set up or download
                         the tarball of the base BSP.

documentation/kernel-manual/kernel-manual.xml

@@ -1,5 +1,6 @@
 <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <book id='kernel-manual' lang='en' 
       xmlns:xi="http://www.w3.org/2003/XInclude"
@@ -48,10 +49,20 @@
                 <date>6 October 2011</date>
                 <revremark>Released with the Yocto Project 1.1 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>1.1.1</revnumber>
+                <date>15 March 2012</date>
+                <revremark>Released with the Yocto Project 1.1.1 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.1.2</revnumber>
+                <date>July 2012</date>
+                <revremark>Released with the Yocto Project 1.1.2 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>
-      <year>2010-2011</year>
+      <year>&COPYRIGHT_YEAR;</year>
       <holder>Linux Foundation</holder>
     </copyright>
 
@@ -63,9 +74,9 @@
       <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/latest/kernel-manual/kernel-manual.html'>
+          <ulink url='&YOCTO_DOCS_KERNEL_URL;'>
           The Yocto Project Kernel Architecture and Use Manual</ulink> on
-          the <ulink url='http://www.yoctoproject.org'>Yocto Project</ulink> website.
+          the <ulink url='&YOCTO_HOME_URL;'>Yocto Project</ulink> website.
           For the latest version of this manual, see the manual on the website.
       </note>
     </legalnotice>

documentation/kernel-manual/style.css

@@ -654,7 +654,7 @@ hr {
 
 
 .tip, .warning, .caution, .note {
-  border-color: #aaa;
+  border-color: #fff;
 }
 
 
@@ -662,24 +662,24 @@ hr {
 .warning table th,
 .caution table th,
 .note table th {
-  border-bottom-color: #aaa;
+  border-bottom-color: #fff;
 }
 
 
 .warning {
-  background-color: #fea;
+  background-color: #f0f0f2;
 }
 
 .caution {
-  background-color: #fea;
+  background-color: #f0f0f2;
 }
 
 .tip {
-  background-color: #eff;
+  background-color: #f0f0f2;
 }
 
 .note {
-  background-color: #dfc;
+  background-color: #f0f0f2; 
 }
 
 .glossary dl dt, 
@@ -946,8 +946,8 @@ table {
 
 .tip,
 .note {
-   background: #666666;
-   color: #fff;   
+   background: #f0f0f2; 
+   color: #333;   
    padding: 20px;
    margin: 20px;
 }
@@ -958,12 +958,12 @@ table {
    margin: 0em;
    font-size: 2em;
    font-weight: bold;
-   color: #fff;   
+   color: #333;   
 }
 
 .tip a,
 .note a {
-   color: #fff;   
+   color: #333;   
    text-decoration: underline;
 }
 
@@ -972,3 +972,12 @@ table {
    color: #333;
 }
 
+/* Changes the announcement text */
+.tip h3,
+.warning h3,
+.caution h3,
+.note h3 {
+   font-size:large;
+   color: #00557D;
+}
+

documentation/poky-ref-manual/development.xml

@@ -1,5 +1,6 @@
 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <chapter id="platdev">
 <title>Platform Development with the Yocto Project</title>
@@ -82,7 +83,7 @@
             The current release of the Yocto Project no longer supports the Anjuta plug-in.
             However, the Poky Anjuta Plug-in is available to download directly from the Poky 
             Git repository located through the web interface at
-            <ulink url="http://git.yoctoproject.org/"></ulink> under IDE Plugins.
+            <ulink url="&YOCTO_GIT_URL;"></ulink> under IDE Plugins.
             The community is free to continue supporting it beyond the Yocto Project 0.9
             Release.            
         </note>
@@ -91,10 +92,8 @@
             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/latest/adt-manual/adt-manual.html#adt-eclipse'>
-            "Working Within Eclipse"</ulink> chapter in the 
-            <ulink url='http://www.yoctoproject.org/docs/latest/adt-manual/adt-manual.html'>
-            "Application Development Toolkit (ADT) User's Guide."</ulink>
+            "<ulink url='&YOCTO_DOCS_ADT_URL;#adt-eclipse'>Working Within Eclipse</ulink>" chapter in the 
+            Yocto Project Application Development Toolkit (ADT) User's Guide.
          </para>
          </section>
 
@@ -102,8 +101,8 @@
         <title>External Development Using the QEMU Emulator</title>
         <para>
             Running Poky QEMU images is covered in the 
-            <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.
+            "<ulink url='&YOCTO_DOCS_ADT_URL;#test-run'>A Quick Test Run</ulink>" section of
+            the Yocto Project Quick Start.
         </para>
         <para>
             The QEMU images shipped with the Yocto Project contain complete toolchains
@@ -162,8 +161,8 @@
         <para>
             Working directly with the Yocto Project is a fast and effective development technique.
             The idea is that you can directly edit files in a working directory
-            (<glossterm><link linkend='var-WORKDIR'>WORKDIR</link></glossterm>) 
-            or the source directory (<glossterm><link linkend='var-S'>S</link></glossterm>) 
+            (<filename><link linkend='var-WORKDIR'>WORKDIR</link></filename>) 
+            or the source directory (<filename><link linkend='var-S'>S</link></filename>) 
             and then force specific tasks to rerun in order to test the changes. 
             An example session working on the matchbox-desktop package might 
             look like this:
@@ -203,16 +202,16 @@
         <para>
             It is useful when making changes directly to the work directory files to do
             so using the Quilt tool as detailed in the 
-            <link linkend='usingpoky-modifying-packages-quilt'> 
-            Modifying Package Source Code with Quilt</link> section. 
+            "<link linkend='usingpoky-modifying-packages-quilt'>Modifying Package Source Code with Quilt</link>"
+             section. 
             Using Quilt, you can copy patches into the recipe directory and use the patches directly 
-            through use of the <glossterm><link linkend='var-SRC_URI'>SRC_URI</link></glossterm> variable.
+            through use of the <filename><link linkend='var-SRC_URI'>SRC_URI</link></filename> variable.
         </para>
 
         <para>
             For a review of the skills used in this section, see the 
-            <link linkend="usingpoky-components-bitbake">BitBake</link> and 
-            <link linkend="usingpoky-debugging-taskrunning">Running Specific Tasks</link> sections
+            "<link linkend="usingpoky-components-bitbake">BitBake</link>" and 
+            "<link linkend="usingpoky-debugging-taskrunning">Running Specific Tasks</link>" sections
             in this manual.
         </para>
         </section>
@@ -231,7 +230,7 @@
             still defined so you can use commands such as <filename>configure</filename> and 
             <filename>make</filename>. 
             The commands execute just as if the Yocto Project build system were executing them. 
-            Consequently, workng this way can be helpful when debugging a build or preparing 
+            Consequently, working this way can be helpful when debugging a build or preparing 
             software to be used with the Yocto Project build system.
         </para>
 
@@ -262,7 +261,7 @@
             or <filename>compile</filename> commands as if they were being run by 
             the Yocto Project build system itself.
             As noted earlier, the working directory also automatically changes to the 
-            source directory (<glossterm><link linkend='var-S'>S</link></glossterm>).
+            source directory (<filename><link linkend='var-S'>S</link></filename>).
         </para>
 
         <para> 
@@ -272,8 +271,8 @@
         <para>
             The default shell used by <filename>devshell</filename> is xterm. 
             You can use other terminal forms by setting the 
-            <glossterm><link linkend='var-TERMCMD'>TERMCMD</link></glossterm> and 
-            <glossterm><link linkend='var-TERMCMDRUN'>TERMCMDRUN</link></glossterm> variables 
+            <filename><link linkend='var-TERMCMD'>TERMCMD</link></filename> and 
+            <filename><link linkend='var-TERMCMDRUN'>TERMCMDRUN</link></filename> variables 
             in the Yocto Project's <filename>local.conf</filename> file found in the build
             directory. 
             For examples of the other options available, see the "UI/Interaction Configuration"
@@ -294,7 +293,7 @@
             instead of just using <filename>gcc</filename>.
             The same applies to other applications such as <filename>binutils</filename>, 
             <filename>libtool</filename> and so forth.
-            The Yocto Project has setup environment variables such as <filename>CC</filename>
+            BitBake sets up environment variables such as <filename>CC</filename>
             to assist applications, such as <filename>make</filename> to find the correct tools.</para>
             <para>It is also worth noting that <filename>devshell</filename> still works over
             X11 forwarding and similar situations</para>
@@ -333,7 +332,7 @@
         It also allows you to perform post-mortem style analysis of program crashes. 
         GDB is available as a package within the Yocto Project and by default is 
         installed in sdk images.
-        See <xref linkend='ref-images'>Reference: Images</xref> for a description of these
+        See the "<link linkend='ref-images'>Reference: Images</link>" appendix for a description of these
         images. 
         You can find information on GDB at <ulink url="http://sourceware.org/gdb/"/>.
     </para>
@@ -671,7 +670,7 @@
         <para>
             A graphical user interface for OProfile is also available. 
             You can download and build this interface from the Yocto Project at
-            <ulink url="http://git.yoctoproject.org/cgit.cgi/oprofileui/"></ulink>. 
+            <ulink url="&YOCTO_GIT_URL;/cgit.cgi/oprofileui/"></ulink>. 
             If the "tools-profile" image feature is selected, all necessary binaries
             are installed onto the target device for OProfileUI interaction.
         </para>
@@ -679,7 +678,7 @@
         <para>
             Even though the Yocto Project usually includes all needed patches on the target device, you 
             might find you need other OProfile patches for recent OProfileUI features.
-            If so, see the <ulink url='http://git.yoctoproject.org/cgit.cgi/oprofileui/tree/README'>
+            If so, see the <ulink url='&YOCTO_GIT_URL;/cgit.cgi/oprofileui/tree/README'>
             OProfileUI README</ulink> for the most recent information.
         </para>
 
@@ -765,8 +764,8 @@
                 is not always necessary to actually have them on the device for OProfile use. 
                 All that is needed is a copy of the filesystem with the debug symbols present 
                 on the viewer system. 
-                The <link linkend='platdev-gdb-remotedebug-launch-gdb'>Launching GDB
-                on the Host Computer</link> section covers how to create such a directory with 
+                The "<link linkend='platdev-gdb-remotedebug-launch-gdb'>Launching GDB on the Host Computer</link>"
+                section covers how to create such a directory with 
                 the Yocto Project and how to use the OProfileUI Settings dialog to specify the location.
                 If you specify the directory, it will be used when the file checksums 
                 match those on the system you are profiling.

documentation/poky-ref-manual/extendpoky.xml

@@ -1,5 +1,6 @@
 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <chapter id='extendpoky'>
 
@@ -9,7 +10,8 @@
         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.
+        versions of library files into a single image, track license changes, 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>
@@ -23,7 +25,7 @@
             variables.
             For information on variables that are useful for recipes and for information about recipe naming
             issues, see the 
-            <link linkend='ref-varlocality-recipe-required'>Required</link> section for recipe variables.
+            "<link linkend='ref-varlocality-recipe-required'>Required</link>" section for recipe variables.
         </para>
 
         <para>
@@ -113,7 +115,7 @@
             <para>
                 The variable <filename><link linkend='var-LIC_FILES_CHKSUM'>LIC_FILES_CHKSUM</link>
                 </filename> is used to track source license changes as described in the
-                <link linkend='usingpoky-configuring-LIC_FILES_CHKSUM'>Track License Change</link>
+                "<link linkend='usingpoky-configuring-LIC_FILES_CHKSUM'>Track License Change</link>"
                 section. 
                 You can quickly create Autotool-based recipes in a manner similar to the previous example.
             </para>
@@ -531,10 +533,9 @@
         <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/latest/dev-manual/dev-manual.html#dev-manual-bsp-appendix'>
+            <ulink url='&YOCTO_DOCS_DEV_URL;#dev-manual-bsp-appendix'>
             BSP Development Example</ulink> in Appendix A of  
-            <ulink url='http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html'>
-            The Yocto Project Development Manual</ulink>.
+            The Yocto Project Development Manual.
         </para>
 
         <section id="platdev-newmachine-conffile">
@@ -785,7 +786,7 @@
         <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 
+            <ulink url='&YOCTO_WIKI_URL;/wiki/Multilib'>Multilib</ulink> wiki 
             page.
         </para>
 
@@ -918,6 +919,111 @@
         </section> 
     </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>
@@ -970,7 +1076,7 @@
         </para>
 
         <para>
-            The Yocto Project supports a <link linkend='usingpoky-changes-layers'>"layers"</link> concept.
+            The Yocto Project supports a "<link linkend='usingpoky-changes-layers'>layers</link>" concept.
             If you use layers properly, you can ease future upgrades and allow segregation
             between the Yocto Project core and a given developer's changes. 
             The following section provides more advice on managing changes to the Yocto Project.
@@ -1215,7 +1321,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://www.yoctoproject.org:8010'>the buildbot for the 
+                See <ulink url='&YOCTO_AB_URL;:8010'>the buildbot for the 
                 Yocto Project</ulink> for an example implementation that uses buildbot.
             </para>
 

documentation/poky-ref-manual/faq.xml

@@ -1,5 +1,6 @@
 <!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <appendix id='faq'>
 <title>FAQ</title>
@@ -7,13 +8,13 @@
     <qandaentry>
         <question>
             <para>
-                How does Poky differ from <ulink url='http://www.openembedded.org/'>OpenEmbedded</ulink>?
+                How does Poky differ from <ulink url='&OE_HOME_URL;'>OpenEmbedded</ulink>?
             </para>
         </question>
         <answer>
             <para>
                 Poky is the Yocto Project build system that was derived from <ulink 
-                url='http://www.openembedded.org/'>OpenEmbedded</ulink>.
+                url='&OE_HOME_URL;'>OpenEmbedded</ulink>.
                 Poky is a stable, smaller subset focused on the mobile environment. 
                 Development in the Yocto Project using Poky is closely tied to OpenEmbedded with 
                 features being merged regularly between the two for mutual benefit.
@@ -33,8 +34,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://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>
+                    <listitem><para><ulink url='&YOCTO_PYTHON-i686_DL_URL;'>32-bit tarball</ulink></para></listitem>
+                    <listitem><para><ulink url='&YOCTO_PYTHON-x86_64_DL_URL;'>64-bit tarball</ulink></para></listitem>
                 </itemizedlist>
             </para>
             <para>
@@ -139,7 +140,7 @@
             <para>
                 To add a package, you need to create a BitBake recipe.
                 For information on how to add a package, see the 
-                <link linkend='usingpoky-extend-addpkg'>Adding a Package</link> section
+                "<link linkend='usingpoky-extend-addpkg'>Adding a Package</link>" section
                 earlier in this manual.
             </para>
         </answer>
@@ -171,7 +172,7 @@
         </question>
         <answer>
             <para>
-                <ulink url='http://www.gnome.org/mobile/'>GNOME Mobile</ulink> is a subset of the GNOME 
+                GNOME Mobile is a subset of the <ulink url='http://www.gnome.org'>GNOME</ulink> 
                 platform targeted at mobile and embedded devices. 
                 The the main difference between GNOME Mobile and standard GNOME is that 
                 desktop-orientated libraries have been removed, along with deprecated libraries, 
@@ -385,9 +386,9 @@
         </question>
         <answer>
             <para>
-                You need to create a form factor file as described in 
-                <xref linkend='bsp-filelayout-misc-recipes'>"Miscellaneous Recipe Files"</xref>
-                and set the <filename>HAVE_TOUCHSCREEN</filename> variable equal to one as follows:
+                You need to create a form factor file as described in the
+                "<link linkend='bsp-filelayout-misc-recipes'>Miscellaneous Recipe Files</link>"
+                section and set the <filename>HAVE_TOUCHSCREEN</filename> variable equal to one as follows:
                 <literallayout class='monospaced'>
      HAVE_TOUCHSCREEN=1
                 </literallayout>
@@ -407,8 +408,8 @@
                 automatically bring up network interfaces. 
                 Therefore, you will need to add a BSP-specific netbase that includes an interfaces 
                 file.
-                See <xref linkend='bsp-filelayout-misc-recipes'>"Miscellaneous Recipe Files"</xref>
-                for information on creating these types of miscellaneous recipe files.
+                See the "<link linkend='bsp-filelayout-misc-recipes'>Miscellaneous Recipe Files</link>"
+                section for information on creating these types of miscellaneous recipe files.
             </para>
             <para>
                 For example, add the following files to your layer:
@@ -493,8 +494,8 @@
 
     <qandaentry>
         <question>
-            <para>
-                How does the Yocto Project obtain source code and will it work behind my 
+            <para id='how-does-the-yocto-project-obtain-source-code-and-will-it-work-behind-my-firewall-or-proxy-server'>
+                How does the Yocto Project build system obtain source code and will it work behind my 
                 firewall or proxy server?
             </para>
         </question>
@@ -573,7 +574,7 @@
                  any network accesses to anything other than the PREMIRROR would fail.
              </para>
              <para>
-                 Poky also honors the standard environment variables 
+                 Poky also honors the standard shell environment variables 
                  <filename>http_proxy</filename>, <filename>ftp_proxy</filename>, 
                  <filename>https_proxy</filename>, and <filename>all_proxy</filename>
                  to redirect requests through proxy servers.

documentation/poky-ref-manual/introduction.xml

@@ -1,5 +1,6 @@
 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <chapter id='intro'>
 <title>Introduction</title>
@@ -15,13 +16,13 @@
         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/latest/yocto-project-qs/yocto-project-qs.html'>   
+        <ulink url='&YOCTO_DOCS_QS_URL;'>   
         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'>
+        <ulink url='&YOCTO_DOCS_DEV_URL;'>
         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>.
+        <ulink url="&YOCTO_HOME_URL;">Yocto Project website</ulink>.
     </para>
 </section>
 
@@ -98,10 +99,8 @@
 <title>System Requirements</title>
     <para>
         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/latest/yocto-project-qs/yocto-project-qs.html'>
-        Yocto Project Quick Start</ulink>.
+        <ulink url='&YOCTO_DOCS_QS_URL;#resources'>
+        What You Need and How You Get It</ulink> section in the Yocto Project Quick Start.
     </para>
 </section>
 
@@ -112,14 +111,14 @@
         of methods:
         <itemizedlist>
             <listitem><para><emphasis>Releases:</emphasis> Stable, tested releases are available through 
-                <ulink url='http://downloads.yoctoproject.org/releases/yocto/'/>.</para></listitem>
+                <ulink url='&YOCTO_DL_URL;/releases/yocto/'/>.</para></listitem>
             <listitem><para><emphasis>Nightly Builds:</emphasis> These releases are available at
                 <ulink url='http://autobuilder.yoctoproject.org/nightly'/>.  
                 These builds include Yocto Project releases, meta-toolchain tarballs, and 
                 experimental builds.</para></listitem>
             <listitem><para><emphasis>Yocto Project Website:</emphasis> You can find releases
                 of the Yocto Project and supported BSPs at the
-                <ulink url='http://www.yoctoproject.org'>Yocto Project website</ulink>.
+                <ulink url='&YOCTO_HOME_URL;'>Yocto Project website</ulink>.
                 Along with these downloads, you can find lots of other information at this site.  
                 </para></listitem>
         </itemizedlist>
@@ -132,11 +131,9 @@
         Development using the Yocto Project requires a local copy of the Yocto Project files. 
         You can get these files by downloading a Yocto Project release tarball and unpacking it,  
         or by establishing a Git repository of the files.
-        For information on both these methods, see
-        <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/latest/dev-manual/dev-manual.html'>
-        The Yocto Project Development Manual</ulink>.
+        For information on both these methods, see the
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#getting-setup'>Getting Setup</ulink>" 
+        section in The Yocto Project Development Manual.
     </para>
 </section>
 

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

@@ -1,5 +1,6 @@
 <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <book id='poky-ref-manual' lang='en' 
       xmlns:xi="http://www.w3.org/2003/XInclude"
@@ -62,10 +63,20 @@
                 <date>6 October 2011</date>
                 <revremark>Released with the Yocto Project 1.1 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>1.1.1</revnumber>
+                <date>15 March 2012</date>
+                <revremark>Released with the Yocto Project 1.1.1 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.1.2</revnumber>
+                <date>July 2012</date>
+                <revremark>Released with the Yocto Project 1.1.2 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>
-      <year>2007-2011</year>
+      <year>&COPYRIGHT_YEAR;</year>
       <holder>Linux Foundation</holder>
     </copyright>
 
@@ -77,9 +88,9 @@
       <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/latest/poky-ref-manual/poky-ref-manual.html'>
+          <ulink url='&YOCTO_DOCS_REF_URL;'>
           The Yocto Project Reference Manual</ulink> on
-          the <ulink url='http://www.yoctoproject.org'>Yocto Project</ulink> website.
+          the <ulink url='&YOCTO_HOME_URL;'>Yocto Project</ulink> website.
           For the latest version of this manual, see the manual on the website.
       </note>
     </legalnotice>

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

@@ -1,5 +1,6 @@
 <!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <appendix id='ref-bitbake'>
 
@@ -35,7 +36,7 @@
             The first thing BitBake does is look for the <filename>bitbake.conf</filename> file.
             The Yocto Project keeps this file in the Yocto Project file's <filename>meta/conf/</filename>
             directory.
-            BitBake finds it by examining the <filename>BBPATH</filename> environment 
+            BitBake finds it by examining its <filename>BBPATH</filename> environment 
             variable and looking for the <filename>meta/conf/</filename> 
             directory.
         </para>
@@ -53,7 +54,7 @@
             and the machine configuration file 
             (set by the 
             <filename><link linkend='var-MACHINE'>MACHINE</link></filename> variable).  
-            The <filename>DISTRO</filename> and <filename>MACHINE</filename> environment 
+            The <filename>DISTRO</filename> and <filename>MACHINE</filename> BitBake environment 
             variables are both usually set in 
             the <filename>local.conf</filename> file. 
             Valid distribution 
@@ -86,7 +87,7 @@
             <filename>meta/recipes-*/</filename> directory within Poky. 
             Adding extra content to <filename>BBFILES</filename> is best achieved through the use of 
             BitBake layers as described in the 
-            <link linkend='usingpoky-changes-layers'>BitBake Layers</link> section.
+            "<link linkend='usingpoky-changes-layers'>BitBake Layers</link>" section.
         </para>
 
         <para>
@@ -207,17 +208,16 @@
             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/latest/yocto-project-qs/yocto-project-qs.html#building-image'>
-            Building an Image</ulink> section in the 
-            <ulink url='http://www.yoctoproject.org/docs/latest/yocto-project-qs/yocto-project-qs.html'>
-            Yocto Project Quick Start</ulink> for more information.
+            "<ulink url='&YOCTO_DOCS_QS_URL;#building-image'>Building an Image</ulink>"
+            section in the Yocto Project Quick Start for more information.
         </para>
 
         <para>
             As each task completes, a timestamp is written to the directory specified by the 
             <filename><link linkend='var-STAMPS'>STAMPS</link></filename> variable (usually 
             <filename>build/tmp/stamps/*/</filename>). 
-            On subsequent runs, BitBake looks at the <filename>STAMPS</filename> directory and does not rerun 
+            On subsequent runs, BitBake looks at the <filename>/build/tmp/stamps</filename>
+            directory and does not rerun
             tasks that are already completed unless a timestamp is found to be invalid. 
             Currently, invalid timestamps are only considered on a per 
             <filename>.bb</filename> file basis.
@@ -301,7 +301,7 @@
             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>.
+            example in the "<link linkend='checksums'>Checksums (Signatures)</link>" section.
         </note>
     </section>
 
@@ -401,8 +401,8 @@ Options:
             This feature works using the <filename><link linkend='var-SRCREV'>SRCREV</link></filename> 
             variable. 
             See the 
-            <link linkend='platdev-appdev-srcrev'>Development Within Yocto Project for a Package that Uses 
-            an External SCM</link> section for more information.
+            "<link linkend='platdev-appdev-srcrev'>Development Within Yocto Project for a Package that Uses 
+            an External SCM</link>" section for more information.
         </para>
 
     </section>

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

@@ -1,5 +1,6 @@
 <!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <appendix id='ref-classes'>
 <title>Reference: Classes</title>
@@ -49,7 +50,7 @@
         This class defines a set of tasks (configure, compile etc.) that 
         work for all Autotooled packages.  
         It should usually be enough to define a few standard variables as documented in the 
-        <link linkend='usingpoky-extend-addpkg-autotools'>Autotooled Package</link> section 
+        "<link linkend='usingpoky-extend-addpkg-autotools'>Autotooled Package</link>" section 
         and then simply <filename>inherit autotools</filename>. 
         This class can also work with software that emulates Autotools.
     </para>
@@ -252,8 +253,8 @@
     <para>
         This class adds the <filename>devshell</filename> task. 
         Distribution policy dictates whether to include this class as the Yocto Project does.
-        See the <link 
-        linkend='platdev-appdev-devshell'>Development Within a Development Shell</link> section 
+        See the 
+        "<link linkend='platdev-appdev-devshell'>Development Within a Development Shell</link>" section 
         for more information about using devshell.
     </para>
 </section>
@@ -313,9 +314,9 @@
         You can find additional information on the effects of the package class at these 
         two Yocto Project mailing list links:
         <itemizedlist>
-            <listitem><para><ulink url='https://lists.yoctoproject.org/pipermail/poky/2011-May/006362.html'>
+            <listitem><para><ulink url='&YOCTO_LISTS_URL;/pipermail/poky/2011-May/006362.html'>
                 https://lists.yoctoproject.org/pipermail/poky/2011-May/006362.html</ulink></para></listitem>
-            <listitem><para><ulink url='https://lists.yoctoproject.org/pipermail/poky/2011-May/006363.html'>
+            <listitem><para><ulink url='&YOCTO_LISTS_URL;/pipermail/poky/2011-May/006363.html'>
                 https://lists.yoctoproject.org/pipermail/poky/2011-May/006363.html</ulink></para></listitem>
         </itemizedlist>
     </para>

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

@@ -1,5 +1,6 @@
 <!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <appendix id='ref-features'>
     <title>Reference: Features</title>

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

@@ -1,5 +1,6 @@
 <!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <appendix id='ref-images'>
     <title>Reference: Images</title>
@@ -45,7 +46,10 @@
         <listitem><para><emphasis><filename>core-image-minimal</filename>:</emphasis>
             A small image just capable of allowing a device to boot.</para></listitem>
         <listitem><para><emphasis><filename>core-image-minimal-dev</filename>:</emphasis>
-            A <filename>core-image-minimal</filename> image suitable for development work.
+            A <filename>core-image-minimal</filename> image suitable for development work
+            using the host.
+            The image includes headers and libraries you can use in a host development 
+            environment.
             </para></listitem>
         <listitem><para><emphasis><filename>core-image-minimal-initramfs</filename>:</emphasis>
             A <filename>core-image-minimal</filename> image that has the Minimal RAM-based 
@@ -64,13 +68,17 @@
             A <filename>core-image-basic</filename> image suitable for implementations 
             that conform to Linux Standard Base (LSB).</para></listitem>
         <listitem><para><emphasis><filename>core-image-lsb-dev</filename>:</emphasis>
-            A <filename>core-image-lsb</filename> image that is suitable for development work.
+            A <filename>core-image-lsb</filename> image that is suitable for development work
+            using the host.
+            The image includes headers and libraries you can use in a host development 
+            environment.
             </para></listitem>
         <listitem><para><emphasis><filename>core-image-lsb-sdk</filename>:</emphasis>
             A <filename>core-image-lsb</filename> that includes everything in meta-toolchain 
-            but also includes development headers and libraries to form a complete standalone SDK. 
-            See the <link linkend='platdev-appdev-external-sdk'> 
-            External Development Using the Poky SDK</link> section for more information.
+            but also includes development headers and libraries to form a complete standalone SDK.
+            This image is suitable for development using the target. 
+            See the "<link linkend='platdev-appdev-external-sdk'> 
+            External Development Using the Poky SDK</link>" section for more information.
             </para></listitem>
         <listitem><para><emphasis><filename>core-image-clutter</filename>:</emphasis>
             An image with support for the Open GL-based toolkit Clutter, which enables development of 
@@ -81,16 +89,17 @@
             The image supports X11 with a Sato theme and Pimlico applications and also  
             contains terminal, editor, and file manager.</para></listitem>
         <listitem><para><emphasis><filename>core-image-sato-dev</filename>:</emphasis>
-            A <filename>core-image-sato</filename> image suitable for development
-            that also includes a native toolchain and libraries needed to build applications on 
-            the device itself. 
-            The image also includes testing and profiling tools as well as debug symbols.  
+            A <filename>core-image-sato</filename> image suitable for development 
+            using the host.
+            The image includes libraries needed to build applications on the device itself, 
+            testing and profiling tools, and debug symbols.  
             This image was formerly <filename>core-image-sdk</filename>.</para></listitem>
         <listitem><para><emphasis><filename>core-image-sato-sdk</filename>:</emphasis>
             A <filename>core-image-sato</filename> image that includes everything in meta-toolchain. 
-            The image also includes development headers and libraries to form a complete standalone SDK. 
-            See the <link linkend='platdev-appdev-external-sdk'> 
-            External Development Using the Poky SDK</link> section for more information.
+            The image also includes development headers and libraries to form a complete standalone SDK
+            and is suitable for development using the target. 
+            See the "<link linkend='platdev-appdev-external-sdk'> 
+            External Development Using the Poky SDK</link>" section for more information.
             </para></listitem>
     </itemizedlist>
 

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

@@ -1,5 +1,6 @@
 <!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <appendix id='ref-structure'>
 
@@ -14,10 +15,8 @@
 
 <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/latest/dev-manual/dev-manual.html#getting-started'> 
-    Getting Setup</ulink> section in the 
-    <ulink url='http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html'>
-    The Yocto Project Development Manual</ulink>.
+    "<ulink url='&YOCTO_DOCS_DEV_URL;#getting-setup'>Getting Set Up</ulink>"
+    section in the Yocto Project Development Manual.
 </para>
 
 <section id='structure-core'>
@@ -35,7 +34,7 @@
             from BitBake itself.
             Consequently, most users do not need to worry about BitBake.
             The <filename>bitbake/bin/</filename> directory is placed 
-            into the <filename>PATH</filename> environment variable by the 
+            into the shell's <filename>PATH</filename> environment variable by the 
             <link linkend="structure-core-script">oe-init-build-env</link> script.
         </para>
 
@@ -121,7 +120,7 @@
             This directory contains various integration scripts that implement 
             extra functionality in the Yocto Project environment (e.g. QEMU scripts).
             The <link linkend="structure-core-script">oe-init-build-env</link> script appends this
-            directory to the <filename>PATH</filename> environment variable.
+            directory to the shell's <filename>PATH</filename> environment variable.
         </para>
 
         <para>
@@ -363,7 +362,7 @@
 
         <para>
             This directory contains intermediate packaging data that is used later in the packaging process. 
-            For more information, see <link linkend='ref-classes-package'>package.bbclass</link>.
+            For more information, see the "<link linkend='ref-classes-package'>Packaging - package*.bbclass</link>" section.
         </para>
     </section>
 
@@ -388,8 +387,8 @@
             referred to as <filename><link linkend='var-WORKDIR'>WORKDIR</link></filename>, is created.  
             Within this directory, the source is unpacked to 
             <filename>linux-qemux86-standard-build</filename> and then patched by Quilt 
-            (see the <link linkend="usingpoky-modifying-packages-quilt">Modifying Package Source Code
-            With Quilt</link> section).   
+            (see the "<link linkend="usingpoky-modifying-packages-quilt">Modifying Package Source Code
+            With Quilt</link>" section).   
             Within the <filename>linux-qemux86-standard-build</filename> directory, 
             standard Quilt directories <filename>linux-3.0/patches</filename>
             and <filename>linux-3.0/.pc</filename> are created,
@@ -480,8 +479,8 @@
         <title><filename>meta/recipes-bsp/</filename></title>
 
         <para>
-            This directory contains anything linking to specific hardware or hardware configuration information
-            such as "u-boot" and "grub".
+            This directory contains anything linking to specific hardware or hardware 
+            configuration information such as "u-boot" and "grub".
         </para>
     </section>
 

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

@@ -1,5 +1,6 @@
 <!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <!-- Dummy chapter -->
 <appendix id='ref-variables-glos'>
@@ -75,7 +76,7 @@
         <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.
-                    If your host development system supports mulitiple cores a good rule of thumb
+                    If your host development system supports multiple cores, a good rule of thumb
                     is to set this variable to twice the number of cores.</para>
             </glossdef>
         </glossentry>
@@ -285,6 +286,7 @@
 
         <glossentry id='var-DISTRO_EXTRA_RRECOMMENDS'><glossterm>DISTRO_EXTRA_RRECOMMENDS</glossterm>
             <glossdef>
+                <para></para>
                 <para>The list of packages which extend usability of the image. 
                     Those packages will automatically be installed but can be removed by user.</para>
             </glossdef>
@@ -305,8 +307,8 @@
         <glossentry id='var-DISTRO_PN_ALIAS'><glossterm>DISTRO_PN_ALIAS</glossterm>
             <glossdef>
                 <para>Alias names used for the recipe in various Linux distributions.</para>
-                <para>See <link linkend='usingpoky-configuring-DISTRO_PN_ALIAS'>
-                    Handling a Package Name Alias</link> section for more information.</para>
+                <para>See "<link linkend='usingpoky-configuring-DISTRO_PN_ALIAS'>
+                    Handling a Package Name Alias</link>" section for more information.</para>
             </glossdef>
         </glossentry>
 
@@ -328,6 +330,7 @@
 
         <glossentry id='var-ENABLE_BINARY_LOCALE_GENERATION'><glossterm>ENABLE_BINARY_LOCALE_GENERATION</glossterm>
             <glossdef>
+                <para></para>
                 <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>
@@ -379,25 +382,6 @@
             </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>
@@ -463,7 +447,7 @@
                     The options to pass in 
                     <filename><link linkend='var-TARGET_CFLAGS'>TARGET_CFLAGS</link></filename>
                     and <filename><link linkend='var-CFLAGS'>CFLAGS</link></filename>
-                    when compiling an optimised system.
+                    when compiling an optimized system.
                     This variable defaults to 
                     "-fexpensive-optimizations -fomit-frame-pointer -frename-registers -O2".
                 </para>
@@ -493,7 +477,7 @@
                 Typically, you configure this variable in image recipes.
                 Note that you can add extra features to the image by using the
                 <filename><link linkend='var-EXTRA_IMAGE_FEATURES'>EXTRA_IMAGE_FEATURES</link></filename> variable.
-                See the <link linkend="ref-features-image">Reference: Images</link> section for the 
+                See the "<link linkend="ref-features-image">Reference: Images</link>" section for the 
                 list of features present in images built by the Yocto Project.</para>
             </glossdef>
         </glossentry>
@@ -510,87 +494,6 @@
             </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.  
@@ -758,6 +661,12 @@
             </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>
@@ -770,27 +679,8 @@
                     This variable must be defined for all recipes (unless <filename>LICENSE</filename>
                     is set to "CLOSED")</para>
                 <para>For more information, see the
-                    <link linkend='usingpoky-configuring-LIC_FILES_CHKSUM'>
-                    Track License Change</link> section</para>
-            </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>
+                    "<link linkend='usingpoky-configuring-LIC_FILES_CHKSUM'>Track License Change</link>" 
+                    section</para>
             </glossdef>
         </glossentry>
 
@@ -806,6 +696,7 @@
 
          <glossentry id='var-MACHINE_ESSENTIAL_EXTRA_RDEPENDS'><glossterm>MACHINE_ESSENTIAL_EXTRA_RDEPENDS</glossterm>
             <glossdef>
+                <para></para>
                 <para>
                     A list of required packages to install as part of the package being
                     built.
@@ -817,7 +708,7 @@
                 </para>
                 <para>
                     This variable is similar to the 
-                    <link linkend='var-MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS'>MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS</link>
+                    <filename><link linkend='var-MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS'>MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS</link></filename>
                     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.
@@ -835,6 +726,7 @@
 
          <glossentry id='var-MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS'><glossterm>MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS</glossterm>
             <glossdef>
+                <para></para>
                 <para>
                     A list of recommended packages to install as part of the package being 
                     built. 
@@ -846,7 +738,7 @@
                 </para>
                 <para>
                     This variable is similar to the 
-                    <link linkend='var-MACHINE_ESSENTIAL_EXTRA_RDEPENDS'>MACHINE_ESSENTIAL_EXTRA_RDEPENDS</link>
+                    <filename><link linkend='var-MACHINE_ESSENTIAL_EXTRA_RDEPENDS'>MACHINE_ESSENTIAL_EXTRA_RDEPENDS</link></filename>
                     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.
@@ -894,7 +786,7 @@
                 </para>
                 <para>
                     This variable is similar to the 
-                    <link linkend='var-MACHINE_EXTRA_RRECOMMENDS'>MACHINE_EXTRA_RRECOMMENDS</link>
+                    <filename><link linkend='var-MACHINE_EXTRA_RRECOMMENDS'>MACHINE_EXTRA_RRECOMMENDS</link></filename>
                     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.
@@ -918,6 +810,7 @@
 
          <glossentry id='var-MACHINE_EXTRA_RRECOMMENDS'><glossterm>MACHINE_EXTRA_RRECOMMENDS</glossterm>
             <glossdef>
+                <para></para>
                 <para>
                     A list of optional but non-machine essential packages to install as 
                     part of the package being built.
@@ -930,7 +823,7 @@
                 </para>
                 <para>
                     This variable is similar to the 
-                    <link linkend='var-MACHINE_EXTRA_RDEPENDS'>MACHINE_EXTRA_RDEPENDS</link>
+                    <filename><link linkend='var-MACHINE_EXTRA_RDEPENDS'>MACHINE_EXTRA_RDEPENDS</link></filename>
                     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.
@@ -956,7 +849,7 @@
          <glossentry id='var-MACHINE_FEATURES'><glossterm>MACHINE_FEATURES</glossterm>
             <glossdef>
                 <para>Specifies the list of device features.
-                    See the <link linkend='ref-features-machine'>Machine</link> section for 
+                    See the "<link linkend='ref-features-machine'>Machine</link>" section for 
                     more information.</para>
             </glossdef>
          </glossentry>
@@ -994,7 +887,7 @@
                     </literallayout>
                     For information on build performance effects as a result of the 
                     package manager use, see
-                    <link linkend='ref-classes-package'>Packaging - <filename>package*.bbclass</filename></link>
+                    "<link linkend='ref-classes-package'>Packaging - <filename>package*.bbclass</filename></link>"
                     in this manual.
                 </para>
             </glossdef>
@@ -1225,7 +1118,7 @@
                     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.
+                    <filename><link linkend='var-RDEPENDS'>RDEPENDS</link></filename> variable.
                 </para>
                 <para>
                     The Yocto Project build process automatically installs the list of packages
@@ -1268,7 +1161,7 @@
                 <para>
                     The path to unpacked sources.
                     By default, this path is 
-                    "${<link linkend='var-WORKDIR'>WORKDIR</link>}/${<link linkend='var-PN'>PN</link>}-${<link linkend='var-PV'>PV</link>}".
+                    "<filename>${<link linkend='var-WORKDIR'>WORKDIR</link>}/${<link linkend='var-PN'>PN</link>}-${<link linkend='var-PV'>PV</link>}</filename>".
                 </para>
             </glossdef>
         </glossentry>
@@ -1343,13 +1236,14 @@
 
         <glossentry id='var-SRC_URI_OVERRIDES_PACKAGE_ARCH'><glossterm>SRC_URI_OVERRIDES_PACKAGE_ARCH</glossterm>
             <glossdef>
+                <para></para>
                 <para>
                     By default, the Yocto Project automatically detects whether 
                     <filename><link linkend='var-SRC_URI'>SRC_URI</link></filename>  
                     contains files that are machine-specific.
                     If so, the Yocto Project automatically changes 
                     <filename><link linkend='var-PACKAGE_ARCH'>PACKAGE_ARCH</link></filename>. 
-                    Setting this variable to "0" disables this behaviour.
+                    Setting this variable to "0" disables this behavior.
                 </para>
             </glossdef>
         </glossentry>

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

@@ -1,5 +1,6 @@
 <!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <appendix id='ref-varlocality'>
     <title>Reference: Variable Context</title>

documentation/poky-ref-manual/resources.xml

@@ -1,5 +1,6 @@
 <!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <appendix id='resources'>
 <title>Contributing to the Yocto Project</title>
@@ -10,10 +11,8 @@
         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/latest/dev-manual/dev-manual.html#local-yp-release'>
-        Yocto Project Release</ulink> list item in
-        <ulink url='http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html'>The Yocto 
-        Project Development Manual</ulink>.
+        see the "<ulink url='&YOCTO_DOCS_DEV_URL;#local-yp-release'>Yocto Project Release</ulink>"
+        list item in the Yocto Project Development Manual.
     </para>
 </section>
 
@@ -22,7 +21,7 @@
 
     <para>
         If you find problems with the Yocto Project, you should report them using the 
-        Bugzilla application at <ulink url='http://bugzilla.yoctoproject.org/'></ulink>.
+        Bugzilla application at <ulink url='&YOCTO_BUGZILLA_URL;'></ulink>.
     </para>
 </section>
 
@@ -33,13 +32,13 @@
         To subscribe to the Yocto Project mailing lists, click on the following URLs and follow the instructions:
         <itemizedlist>
             <listitem><para><emphasis>
-                <ulink url='http://lists.yoctoproject.org/listinfo/yocto-announce'></ulink></emphasis>:
+                <ulink url='&YOCTO_LISTS_URL;/listinfo/yocto-announce'></ulink></emphasis>:
                 Use this list to receive offical Yocto Project announcements for developments and 
                 to learn about Yocto Project milestones.</para></listitem>
-            <listitem><para><emphasis><ulink url='http://lists.yoctoproject.org/listinfo/yocto'></ulink></emphasis>:
+            <listitem><para><emphasis><ulink url='&YOCTO_LISTS_URL;/listinfo/yocto'></ulink></emphasis>:
                 Use this list to monitor Yocto Project development discussions, ask questions, and 
                 get help.</para></listitem>
-            <listitem><para><emphasis><ulink url='http://lists.yoctoproject.org/listinfo/poky'></ulink></emphasis>:
+            <listitem><para><emphasis><ulink url='&YOCTO_LISTS_URL;/listinfo/poky'></ulink></emphasis>:
                 Use this list to monitor discussions about the Yocto Project build system Poky, 
                 ask questions, and get help.</para></listitem>
         </itemizedlist>
@@ -64,15 +63,15 @@
     <para>
         Following is a list of resources you will find helpful:
         <itemizedlist>
-            <listitem><para><emphasis><ulink url='http://yoctoproject.org'>The Yocto Project website</ulink>:
+            <listitem><para><emphasis><ulink url='&YOCTO_HOME_URL;'>The Yocto Project website</ulink>:
                 </emphasis> The home site for the Yocto Project.</para></listitem>
-            <listitem><para><emphasis><ulink url='http://www.openedhand.com/'>OpenedHand</ulink>:</emphasis>
+            <listitem><para><emphasis><ulink url='&OH_HOME_URL;'>OpenedHand</ulink>:</emphasis>
                 The company where the Yocto Project build system Poky was first developed.
                 OpenedHand has since been acquired by Intel Corporation.</para></listitem>
             <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>
+            <listitem><para><emphasis><ulink url='&OE_HOME_URL;'>OpenEmbedded</ulink>:</emphasis>
                 The upstream, generic, embedded distribution the Yocto Project build system (Poky) derives
                 from and to which it contributes.</para></listitem>
             <listitem><para><emphasis><ulink url='http://developer.berlios.de/projects/bitbake/'>
@@ -96,11 +95,9 @@
         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>.
+        For information on how to do both, see the
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#how-to-submit-a-change'>How to Submit a Change</ulink>"
+        section in the Yocto Project Development Manual.
     </para>
 </section>
 

documentation/poky-ref-manual/style.css

@@ -654,7 +654,7 @@ hr {
 
 
 .tip, .warning, .caution, .note {
-  border-color: #aaa;
+  border-color: #fff;
 }
 
 
@@ -662,24 +662,24 @@ hr {
 .warning table th,
 .caution table th,
 .note table th {
-  border-bottom-color: #aaa;
+  border-bottom-color: #fff;
 }
 
 
 .warning {
-  background-color: #fea;
+  background-color: #f0f0f2;
 }
 
 .caution {
-  background-color: #fea;
+  background-color: #f0f0f2;
 }
 
 .tip {
-  background-color: #eff;
+  background-color: #f0f0f2;
 }
 
 .note {
-  background-color: #dfc;
+  background-color: #f0f0f2; 
 }
 
 .glossary dl dt, 
@@ -946,8 +946,8 @@ table {
 
 .tip,
 .note {
-   background: #666666;
-   color: #fff;   
+   background: #f0f0f2; 
+   color: #333;   
    padding: 20px;
    margin: 20px;
 }
@@ -958,12 +958,12 @@ table {
    margin: 0em;
    font-size: 2em;
    font-weight: bold;
-   color: #fff;   
+   color: #333;   
 }
 
 .tip a,
 .note a {
-   color: #fff;   
+   color: #333;   
    text-decoration: underline;
 }
 
@@ -972,3 +972,12 @@ table {
    color: #333;
 }
 
+/* Changes the announcement text */
+.tip h3,
+.warning h3,
+.caution h3,
+.note h3 {
+   font-size:large;
+   color: #00557D;
+}
+

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

@@ -1,5 +1,7 @@
 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
 <chapter id='technical-details'>
 <title>Technical Details</title>
 
@@ -31,10 +33,8 @@
             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>.
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#yocto-project-terms'>Yocto Project Terms</ulink>"
+        section in the Yocto Project Development Manual.
     </para>
 
     <para> 
@@ -45,8 +45,7 @@
     <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.
+        "<link linkend='ref-structure'>Reference: Directory Structure</link>" appendix.
     </para>
 
     <section id='usingpoky-components-bitbake'>
@@ -76,7 +75,7 @@
             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.
+            "<link linkend='ref-bitbake-providers'>Preferences and Providers</link>" section.
         </para>
 
         <para>
@@ -115,7 +114,7 @@
             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.
+            this document avoids using the term "package" when referring to recipes.
         </para>
     </section>
 
@@ -127,7 +126,7 @@
             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
+            The "<link linkend='ref-classes'>Reference: Classes</link>" appendix provides details
             about common classes and how to use them.
         </para>
     </section>
@@ -163,7 +162,7 @@
         As mentioned in the previous paragraph, building from scratch ensures that 
         everything is current and starts from a known state.
         However, building from scratch also takes much longer as it generally means 
-        rebuiding things that don't necessarily need rebuilt.
+        rebuilding things that don't necessarily need rebuilt.
     </para>
 
     <para>
@@ -239,7 +238,7 @@
             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 
+            The simplistic approach for excluding the working directory is to set 
             <filename>WORKDIR</filename> to some fixed value and create the checksum
             for the "run" script. 
         </para>
@@ -299,77 +298,73 @@
 
         <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.
+            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:
+            At the code level, there are a variety of ways both the basehash and the
+            dependent task hashes can be influenced. 
+            Within the BitBake configuration file, we can give BitBake some extra information 
+            to help it construct the basehash.
+            The following statements effectively result in a list of global variable
+            dependency excludes - variables never included in any checksum:
             <literallayout class='monospaced'>
-     BB_SIGNATURE_HANDLER ?= "basic"
+  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"
             </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.
+            The previous example actually excludes 
+            <link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>
+            since it is actually 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.
+            The rules for deciding which hashes of dependent tasks to include through
+            dependency chains are more complex and are generally accomplished with a 
+            python function. 
+            The code in <filename>meta/lib/oe/sstatesig.py</filename> shows two examples
+            of this and also illustrates how you can insert your own policy into the system 
+            if so desired.
+            This file defines the two basic signature generators <filename>OE-Core</filename>
+            uses:  "OEBasic" and "OEBasicHash". 
+            By default, there is a dummy "noop" signature handler enabled in BitBake. 
+            This means that behavior is unchanged from previous versions. 
+            <filename>OE-Core</filename> uses the "OEBasic" signature handler by default
+            through this setting in the <filename>bitbake.conf</filename> file:
+            <literallayout class='monospaced'>
+  BB_SIGNATURE_HANDLER ?= "OEBasic"
+            </literallayout>
+            The "OEBasicHash" <filename>BB_SIGNATURE_HANDLER</filename> is the same as the 
+            "OEBasic" 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 <link linkend='var-PR'><filename>PR</filename></link>
+            values and changes to metadata automatically ripple across the build. 
+            Currently, this behavior is not the default behavior for <filename>OE-Core</filename>
+            but is the default in <filename>poky</filename>.
         </para>
 
         <para>
-            The end result of the "basic" handler is to make some dependency and
-            hash information available to the build. 
-            This includes:
+            It is also worth noting that the end result of these signature generators is to
+            make some dependency and hash information available to the build. 
+            This information includes:
             <literallayout class='monospaced'>
-     BB_BASEHASH_task-&lt;taskname&gt; - the base hashes for each task in the recipe
-     BB_BASEHASH_&lt;filename:taskname&gt; - the base hashes for each dependent task
-     BBHASHDEPS_&lt;filename:taskname&gt; - The task dependencies for each task
-     BB_TASKHASH - the hash of the currently running task
+  BB_BASEHASH_task-&lt;taskname&gt; - the base hashes for each task in the recipe
+  BB_BASEHASH_&lt;filename:taskname&gt; - the base hashes for each dependent task
+  BBHASHDEPS_&lt;filename:taskname&gt; - The task dependencies for each task
+  BB_TASKHASH - the hash of the currently running task
             </literallayout>
-            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>
 
@@ -431,7 +426,7 @@
             <literallayout class='monospaced'>
      do_package[sstate-plaindirs] = "${PKGD} ${PKGDEST}"
             </literallayout>
-            This method, as well as the following example, also works for mutliple directories.
+            This method, as well as the following example, also works for multiple directories.
             <literallayout class='monospaced'>
      do_package[sstate-inputdirs] = "${PKGDESTWORK} ${SHLIBSWORKDIR}"
      do_package[sstate-outputdirs] = "${PKGDATA_DIR} ${SHLIBSDIR}"
@@ -553,7 +548,7 @@
                 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
+                For example, to invalidate package shared state files, change the comment statements
                 of <filename>do_package</filename> or the comments of one of the functions it calls.
                 The change is purely cosmetic, but it causes the checksum to be recalculated and  
                 forces the task to be run again.
@@ -562,171 +557,12 @@
             <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>.
+                <ulink url='&YOCTO_GIT_URL;/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

@@ -1,5 +1,7 @@
 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
+
 <chapter id='usingpoky'>
 <title>Using the Yocto Project</title>
 
@@ -15,10 +17,8 @@
     <para>
         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/latest/yocto-project-qs/yocto-project-qs.html'>
-        Yocto Project Quick Start</ulink>.
+        "<ulink url='&YOCTO_DOCS_QS_URL;#building-image'>Building an Image</ulink>"
+        section of The Yocto Project Quick Start.
         This section provides a summary of the build process and provides information
         for less obvious aspects of the build process.
     </para>
@@ -60,14 +60,14 @@
             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.
+            For more details about the images the 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.
+            See the "<link linkend='ref-images'>Reference: Images</link>" appendix for more information.
         </note>
     </section>
 
@@ -93,10 +93,8 @@
         <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/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/latest/yocto-project-qs/yocto-project-qs.html'>
-        Yocto Project Quick Start</ulink>.
+        "<ulink url='&YOCTO_DOCS_QS_URL;#using-pre-built'>Using Pre-Built Binaries and QEMU</ulink>"
+        section in the Yocto Project Quick Start.
         For information about how to install these images, see the documentation for your
         particular board/machine.
     </para>
@@ -297,7 +295,7 @@
          if fatal_error:
              bb.fatal("fatal_error detected, unable to print the task list")
          bb.plain("The tasks present are abc")
-         bb.debug(2, "Finished figureing out the tasklist")
+         bb.debug(2, "Finished figuring out the tasklist")
      }
                 </literallayout>
             </para>

documentation/poky.ent

@@ -0,0 +1,48 @@
+<!ENTITY DISTRO "1.1.2">
+<!ENTITY DISTRO_NAME "edison">
+<!ENTITY YOCTO_DOC_VERSION "1.1.2">
+<!ENTITY POKYVERSION "6.0.2">
+<!ENTITY YOCTO_POKY "poky-&DISTRO_NAME;-&POKYVERSION;">
+<!ENTITY COPYRIGHT_YEAR "2010-2012">
+<!ENTITY YOCTO_DL_URL "http://downloads.yoctoproject.org">
+<!ENTITY YOCTO_HOME_URL "http://www.yoctoproject.org">
+<!ENTITY YOCTO_LISTS_URL "http://lists.yoctoproject.org">
+<!ENTITY YOCTO_BUGZILLA_URL "http://bugzilla.yoctoproject.org">
+<!ENTITY YOCTO_WIKI_URL "https://wiki.yoctoproject.org">
+<!ENTITY YOCTO_AB_URL "http://autobuilder.yoctoproject.org">
+<!ENTITY YOCTO_GIT_URL "http://git.yoctoproject.org">
+<!ENTITY YOCTO_ADTREPO_URL "http://adtrepo.yoctoproject.org">
+<!ENTITY OE_HOME_URL "http://www.openembedded.org">
+<!ENTITY OE_DOCS_URL "http://docs.openembedded.org">
+<!ENTITY OH_HOME_URL "http://o-hand.com">
+<!ENTITY BITBAKE_HOME_URL "http://developer.berlios.de/projects/bitbake/">
+<!ENTITY BITBAKE_DOCS_URL "http://bitbake.berlios.de/manual/">
+<!ENTITY ECLIPSE_MAIN_URL "http://www.eclipse.org/downloads">
+<!ENTITY ECLIPSE_DL_URL "http://download.eclipse.org">
+<!ENTITY ECLIPSE_DL_PLUGIN_URL "&YOCTO_DL_URL;/releases/eclipse-plugin/&DISTRO;">
+<!ENTITY ECLIPSE_UPDATES_URL "&ECLIPSE_DL_URL;/tm/updates/3.3">
+<!ENTITY ECLIPSE_INDIGO_URL "&ECLIPSE_DL_URL;/releases/indigo">
+<!ENTITY ECLIPSE_INDIGO_CDT_URL "&ECLIPSE_DL_URL;tools/cdt/releases/indigo">
+<!ENTITY YOCTO_DOCS_URL "&YOCTO_HOME_URL;/docs">
+<!ENTITY YOCTO_SOURCES_URL "&YOCTO_HOME_URL;/sources/">
+<!ENTITY YOCTO_AB_PORT_URL "&YOCTO_AB_URL;:8010">
+<!ENTITY YOCTO_AB_NIGHTLY_URL "&YOCTO_AB_URL;/nightly/">
+<!ENTITY YOCTO_POKY_URL "&YOCTO_DL_URL;/releases/poky/">
+<!ENTITY YOCTO_RELEASE_DL_URL "&YOCTO_DL_URL;/releases/yocto/yocto-&DISTRO;">
+<!ENTITY YOCTO_TOOLCHAIN_DL_URL "&YOCTO_RELEASE_DL_URL;/toolchain/">
+<!ENTITY YOCTO_ECLIPSE_DL_URL "&YOCTO_RELEASE_DL_URL;/eclipse-plugin/indigo;">
+<!ENTITY YOCTO_ADTINSTALLER_DL_URL "&YOCTO_RELEASE_DL_URL;/adt_installer">
+<!ENTITY YOCTO_POKY_DL_URL "&YOCTO_RELEASE_DL_URL;/&YOCTO_POKY;.tar.bz2">
+<!ENTITY YOCTO_MACHINES_DL_URL "&YOCTO_RELEASE_DL_URL;/machines">
+<!ENTITY YOCTO_QEMU_DL_URL "&YOCTO_MACHINES_DL_URL;/qemu">
+<!ENTITY YOCTO_PYTHON-i686_DL_URL "&YOCTO_DL_URL;/releases/miscsupport/python-nativesdk-standalone-i686.tar.bz2">
+<!ENTITY YOCTO_PYTHON-x86_64_DL_URL "&YOCTO_DL_URL;/releases/miscsupport/python-nativesdk-standalone-x86_64.tar.bz2">
+<!ENTITY YOCTO_DOCS_QS_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/yocto-project-qs/yocto-project-qs.html">
+<!ENTITY YOCTO_DOCS_ADT_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/adt-manual/adt-manual.html">
+<!ENTITY YOCTO_DOCS_REF_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/poky-ref-manual/poky-ref-manual.html">
+<!ENTITY YOCTO_DOCS_BSP_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/bsp-guide/bsp-guide.html">
+<!ENTITY YOCTO_DOCS_DEV_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/dev-manual/dev-manual.html">
+<!ENTITY YOCTO_DOCS_KERNEL_URL "&YOCTO_DOCS_URL;/&YOCTO_DOC_VERSION;/kernel-manual/kernel-manual.html">
+<!ENTITY YOCTO_ADTPATH_DIR "/opt/poky/&DISTRO;">
+<!ENTITY YOCTO_POKY_TARBALL "&YOCTO_POKY;.tar.bz2">
+<!ENTITY OE_INIT_PATH "&YOCTO_POKY;/oe-init-build-env">

documentation/yocto-project-qs/style.css

@@ -654,7 +654,7 @@ hr {
 
 
 .tip, .warning, .caution, .note {
-  border-color: #aaa;
+  border-color: #fff;
 }
 
 
@@ -662,24 +662,24 @@ hr {
 .warning table th,
 .caution table th,
 .note table th {
-  border-bottom-color: #aaa;
+  border-bottom-color: #fff;
 }
 
 
 .warning {
-  background-color: #fea;
+  background-color: #f0f0f2;
 }
 
 .caution {
-  background-color: #fea;
+  background-color: #f0f0f2;
 }
 
 .tip {
-  background-color: #eff;
+  background-color: #f0f0f2;
 }
 
 .note {
-  background-color: #dfc;
+  background-color: #f0f0f2; 
 }
 
 .glossary dl dt, 
@@ -946,8 +946,8 @@ table {
 
 .tip,
 .note {
-   background: #666666;
-   color: #fff;   
+   background: #f0f0f2; 
+   color: #333;   
    padding: 20px;
    margin: 20px;
 }
@@ -958,12 +958,12 @@ table {
    margin: 0em;
    font-size: 2em;
    font-weight: bold;
-   color: #fff;   
+   color: #333;   
 }
 
 .tip a,
 .note a {
-   color: #fff;   
+   color: #333;   
    text-decoration: underline;
 }
 
@@ -972,3 +972,12 @@ table {
    color: #333;
 }
 
+/* Changes the announcement text */
+.tip h3,
+.warning h3,
+.caution h3,
+.note h3 {
+   font-size:large;
+   color: #00557D;
+}
+

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

@@ -1,12 +1,13 @@
-<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" 
+"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" 
+[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <article id='intro'>
    <imagedata fileref="figures/yocto-project-transp.png" width="6in" depth="1in" align="right" scale="25" />
 
 <section id='fake-title'>
-    <title>Yocto Project Quick Start</title>
-    <para>Copyright &copy; 2010-2011 Linux Foundation</para>
+    <title>The Yocto Project Quick Start</title>
+    <para>Copyright &copy; &COPYRIGHT_YEAR; Linux Foundation</para>
 </section>
 
 <section id='welcome'>
@@ -18,6 +19,7 @@
         Amongst other things, the Yocto Project uses the Poky build system to 
         construct complete Linux images.
     </para>
+
     <para>
         This short document will give you some basic information about the environment as well 
         as let you experience it in its simplest form.  
@@ -26,26 +28,28 @@
         This document steps you through a simple example showing you how to build a small image 
         and run it using the QEMU emulator.
     </para>
+
     <para>
-        For complete information on the Yocto Project, you should check out the 
-        <ulink url='http://www.yoctoproject.org'>Yocto Project Website</ulink>.
-        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  
-        <ulink url='http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html'>
-        The Yocto Project Reference Manual</ulink> helpful.
+        For more detailed information on the Yocto Project, you should check out these resources:
+        <itemizedlist>
+            <listitem><para><emphasis>Website:</emphasis> The <ulink url='&YOCTO_HOME_URL;'>Yocto Project Website</ulink>
+                provides the latest builds, breaking news, full development documentation, and a rich Yocto 
+                Project Development Community into which you can tap.
+                </para></listitem>
+            <listitem><para><emphasis>FAQs:</emphasis> Lists commonly asked Yocto Project questions and answers.
+                You can find two FAQs: <ulink url='&YOCTO_WIKI_URL;/wiki/FAQ'>Yocto Project FAQ</ulink> on 
+                a wiki, and the 
+                <ulink url='&YOCTO_DOCS_REF_URL;#faq'>FAQ</ulink> appendix in the 
+                The Yocto Project Reference Manual.
+                </para></listitem>
+        </itemizedlist>
     </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/latest/yocto-project-qs/yocto-project-qs.html'>
+        <ulink url='&YOCTO_DOCS_QS_URL;'>
         Yocto Project Quick Start</ulink> on
-        the <ulink url='http://www.yoctoproject.org'>Yocto Project</ulink> website.
+        the <ulink url='&YOCTO_HOME_URL;'>Yocto Project</ulink> website.
         For the latest version of this manual, see the manual on the website.
     </note>
 </section>
@@ -156,11 +160,11 @@
                 <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
+            <ulink url='&YOCTO_WIKI_URL;/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>
+                <ulink url='&YOCTO_WIKI_URL;/wiki/BuildingOnRHEL4'>BuildingOnRHEL4</ulink>
                 wiki page.
             </note>
             </para>
@@ -174,12 +178,12 @@
             If you attempt to use a distribution not in the above list, you may or may not have success - you 
             are venturing into untested territory.
             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> 
+            <ulink url='&OE_HOME_URL;/index.php?title=OEandYourDistro&amp;action=historysubmit&amp;diff=4309&amp;okdid=4225'>OE and Your Distro</ulink> and 
+            <ulink url='&OE_HOME_URL;/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 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>
+            When you do, please go to <ulink url='&YOCTO_BUGZILLA_URL;'>Yocto Project Bugzilla</ulink>
             and submit a bug.
             We are interested in hearing about your experience.
         </para></note>
@@ -198,16 +202,25 @@
         <section id='ubuntu'>
             <title>Ubuntu</title>
 
+            <para>
+                If your distribution is Ubuntu, you need to be running the bash shell.  
+                You can be sure you are running this shell by entering the following command and 
+                selecting "No" at the prompt:
+                <literallayout class='monospaced'>
+     $ sudo dpkg-reconfigure dash
+                </literallayout>
+            </para>
+
             <para>
                 The packages you need for a supported Ubuntu distribution are shown in the following command:
             </para>
 
                 <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 \
+     unzip texi2html texinfo libsdl1.2-dev docbook-utils gawk fop \
+     python-pysqlite2 diffstat help2man make gcc build-essential xsltproc \
      g++ desktop-file-utils chrpath libgl1-mesa-dev libglu1-mesa-dev \
-     mercurial autoconf automake groff libtool xterm libxml-parser-perl
+     mercurial autoconf automake groff libtool xterm
                 </literallayout>
         </section>
 
@@ -223,7 +236,7 @@
      $ 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-style-dsssl sed docbook-style-xsl docbook-dtds fop xsltproc \
      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 \
@@ -249,8 +262,8 @@
             </para>
 
                 <literallayout class='monospaced'>
-     $ sudo zypper install python gcc gcc-c++ libtool \
-     subversion git chrpath automake make wget help2man \
+     $ sudo zypper install python gcc gcc-c++ libtool fop \
+     subversion git chrpath automake make wget help2man xsltproc \
      diffstat texinfo mercurial freeglut-devel libSDL-devel
                 </literallayout>
         </section>
@@ -261,13 +274,13 @@
             
         <para>
             You can download the latest Yocto Project release by going to the 
-            <ulink url="http://yoctoproject.org/download">Yocto Project Download page</ulink>.
+            <ulink url="&YOCTO_HOME_URL;/download">Yocto Project Download page</ulink>.
             Just go to the page and click the "Yocto Downloads" link found in the "Download"
             navigation pane to the right to view all available Yocto Project releases. 
             Then, click the "Yocto Release" link for the release you want from the list to 
             begin the download. 
             Nightly and developmental builds are also maintained at
-            <ulink url="http://autobuilder.yoctoproject.org/nightly/"></ulink>.  
+            <ulink url="&YOCTO_AB_NIGHTLY_URL;"></ulink>.  
             However, for this document a released version of Yocto Project is used.
         </para>
 
@@ -276,10 +289,8 @@
             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>.
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#local-yp-release'>Yocto 
+            Project Release</ulink>" item in The Yocto Project Development Manual.
         </para>
     </section>
 </section>
@@ -288,7 +299,7 @@
     <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 the Yocto Project a try.  
         This section presents some steps that let you do the following:
     </para>
 
@@ -334,28 +345,28 @@
              By default, the Yocto Project searches for source code using a pre-determined order
              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
+             the FAQ entry "How does the Yocto Project build system obtain source code and will it work behind my
              firewall or proxy server?" in  
-             <ulink url='http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html'>
+             <ulink url='&YOCTO_DOCS_REF_URL;#faq'>
              The Yocto Project Reference Manual</ulink>.
          </para></note>
 
          <para>
              <literallayout class='monospaced'>
-     $ 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
+     $ wget &YOCTO_POKY_DL_URL;
+     $ tar xjf &YOCTO_POKY;.tar.bz2
+     $ source &OE_INIT_PATH; &YOCTO_POKY;-build
              </literallayout>
          </para>
 
          <tip><para>
              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>.
+             is <filename>&YOCTO_POKY;-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'>
-     INHERIT += rm_work
+     INHERIT += "rm_work"
              </literallayout>
          </para></tip>
 
@@ -364,16 +375,16 @@
                  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>
+                 <ulink url='&YOCTO_HOME_URL;/download'>Yocto Project website's Downloads page</ulink>
+                 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 
+                 them into a directory named <filename>&YOCTO_POKY;</filename> in the current 
                  directory.</para></listitem>
              <listitem><para>The third command runs the Yocto Project environment setup script.
                  Running this script defines 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.
+                 build directory, which is <filename>&YOCTO_POKY;-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 
@@ -397,8 +408,8 @@
 
          <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.
+             <ulink url='&YOCTO_DOCS_REF_URL;#var-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename></ulink> and the 
+             <ulink url='&YOCTO_DOCS_REF_URL;#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 
@@ -411,11 +422,10 @@
             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/latest/poky-ref-manual/poky-ref-manual.html#var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></ulink></filename> variable.  
+            <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></ulink></filename> variable.  
              For additional package manager selection information, see 
-             "<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>.
+             "<ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-package'>Packaging - <filename>package*.bbclass</filename></ulink>" 
+             in The Yocto Project Reference Manual.
         </para>
 
          <para>
@@ -423,16 +433,16 @@
              <filename>core-image-sato</filename> in this example.
              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>.
+             "<ulink url='&YOCTO_DOCS_REF_URL;#usingpoky-components-bitbake'>BitBake</ulink>" section in 
+             The Yocto Project Reference Manual.
              <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  
-                 <ulink url='http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html'>
-                 The Yocto Project Reference Manual</ulink>.
+                 see the 
+                 <ulink url='&YOCTO_DOCS_REF_URL;#faq'>FAQ</ulink> in The Yocto Project Reference 
+                 Manual.
              </para></note>
              The final command runs the image:
              <literallayout class='monospaced'>
@@ -470,7 +480,7 @@
         </para>
 
         <itemizedlist>
-            <listitem><para>Install the stand-alone Yocto toolchain tarball.</para></listitem>
+            <listitem><para>Install the appropriate 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>
@@ -485,9 +495,9 @@
             <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>.  
+                <ulink url='&YOCTO_TOOLCHAIN_DL_URL;'></ulink>.  
                 Toolchains are available for 32-bit and 64-bit development systems from the 
-                <filename>i686</filename> and <filename>x86_64</filename> directories, respectively. 
+                <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
@@ -495,7 +505,7 @@
             </para>
 
             <literallayout class='monospaced'>
-     poky-eglibc&lt;<emphasis>host_system</emphasis>&gt;-&lt;<emphasis>arch</emphasis>&gt;-toolchain-gmae-&lt;<emphasis>release</emphasis>&gt;.tar.bz2
+     poky-eglibc-&lt;<emphasis>host_system</emphasis>&gt;-&lt;<emphasis>arch</emphasis>&gt;-toolchain-gmae-&lt;<emphasis>release</emphasis>&gt;.tar.bz2
 
      Where:
          &lt;<emphasis>host_system</emphasis>&gt; is a string representing your development system: 
@@ -513,7 +523,7 @@
             </para>
 
             <literallayout class='monospaced'>
-     poky-eglibc-x86_64-i586-toolchain-gmae-1.1.tar.bz2
+     poky-eglibc-x86_64-i586-toolchain-gmae-&DISTRO;.tar.bz2
             </literallayout>
 
             <para>
@@ -526,16 +536,15 @@
             <para>
                 <literallayout class='monospaced'>
      $ cd /
-     $ sudo tar -xvjf ~/toolchains/poky-eglibc-x86_64-i586-toolchain-gmae-1.1.tar.bz2
+     $ sudo tar -xvjf ~/toolchains/poky-eglibc-x86_64-i586-toolchain-gmae-&DISTRO;.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>.
+                "<ulink url='&YOCTO_DOCS_ADT_URL;#using-an-existing-toolchain-tarball'>Using a Cross-Toolchain Tarball</ulink>" and 
+                "<ulink url='&YOCTO_DOCS_ADT_URL;#using-the-toolchain-from-within-the-build-tree'>Using BitBake and the Yocto Project Build Tree</ulink>" sections in The Yocto Project Application Development Toolkit (ADT) 
+                User's Guide.
             </para>
         </section>
 
@@ -544,11 +553,11 @@
       
             <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>.
+                <ulink url='&YOCTO_QEMU_DL_URL;'></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>.
+                <filename>qemux86</filename>, and <filename>qemux86-64</filename>.
             </para>
          
             <para>  
@@ -565,9 +574,8 @@
 
             <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>.
+                "<ulink url='&YOCTO_DOCS_DEV_URL;#local-kernel-files'>Linux Yocto Kernel</ulink>" section of  
+                The Yocto Project Development Manual.
             </para>
         </section>
 
@@ -576,7 +584,7 @@
 
             <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>.
+                <ulink url='&YOCTO_QEMU_DL_URL;'></ulink>.
                 Again, be sure to use the filesystem that matches the architecture you want 
                 to simulate.
             </para>
@@ -587,7 +595,7 @@
                 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.
+                and used for build purposes with the Yocto Project.
                 <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
@@ -596,7 +604,7 @@
          &lt;<emphasis>profile</emphasis>&gt; is the filesystem image's profile:
                    lsb, lsb-dev, lsb-sdk, lsb-qt3, minimal, minimal-dev, sato, sato-dev, or sato-sdk.
                    For information on these types of image profiles, see
-                   <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.
+                   <ulink url='&YOCTO_DOCS_REF_URL;#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.
@@ -611,7 +619,7 @@
                 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; 
+     $ source &YOCTO_ADTPATH_DIR;/environment-setup-&lt;<emphasis>arch</emphasis>&gt;-poky-linux-&lt;<emphasis>if</emphasis>&gt; 
 
      Where:
          &lt;<emphasis>arch</emphasis>&gt; is a string representing the target architecture: 
@@ -641,11 +649,13 @@
             <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.
+                This example assumes the root filesystem (<filename>.ext3</filename> file) and 
+                the pre-built kernel image file both reside in your home directory. 
+                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 \
+     $ cd $HOME
+     $ source &YOCTO_ADTPATH_DIR;/environment-setup-i586-poky-linux 
+     $ runqemu qemux86 bzImage-qemux86.bin \
      core-image-sato-qemux86.ext3
                 </literallayout>
             </para>

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 = "LGPLv2.1"
+LICENSE = "GPLv2.1"
 DEPENDS = "libnice glib-2.0 libxml2 zlib dbus gstreamer gst-plugins-base"
 
 inherit autotools
 
-PR = "r2"
+PR = "r1"
 
 EXTRA_OECONF = " \
   --disable-debug \

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

@@ -1,5 +1,3 @@
-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,5 +1,3 @@
-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,5 +1,3 @@
-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_svn.bb

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

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

@@ -1,5 +1,3 @@
-
-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 = "${@d.getVar('PV',1).split('.')[0]}.${@d.getVar('PV',1).split('.')[1]}"
+SHRT_VER = "${@bb.data.getVar('PV',d,1).split('.')[0]}.${@bb.data.getVar('PV',d,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"
 
-SVNURI = "svn://svn.abisource.com/abiword/trunk;module=abiword;proto=http"
-SVNSRC = "${WORKDIR}/abi"
+CVSURI = "cvs://anoncvs:anoncvs@anoncvs.abisource.com/cvsroot;module=abi"
+CVSSRC = "${WORKDIR}/abi"
 
 #want 2.x from 2.x.y for the installation directory
-SHRT_VER = "${@d.getVar('PV',1).split('.')[0]}.${@d.getVar('PV',1).split('.')[1]}"
+SHRT_VER = "${@bb.data.getVar('PV',d,1).split('.')[0]}.${@bb.data.getVar('PV',d,1).split('.')[1]}"
 
 FILES_${PN} += " \
 		${datadir}/icons/* \

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

@@ -0,0 +1,10 @@
+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

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

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

@@ -0,0 +1,13 @@
+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
+}
+

meta-demoapps/recipes-graphics/clutter/table/fixes.patch

@@ -0,0 +1,16 @@
+Upstream-Status: Pending
+
+Index: table/Makefile
+===================================================================
+--- table.orig/Makefile	2007-07-10 13:24:18.000000000 +0100
++++ table/Makefile	2007-07-10 13:28:10.000000000 +0100
+@@ -8,7 +8,7 @@ all: table
+ 
+ 
+ table: table.o clutter-dominatrix.o clutter-video-player.o
+-	$(CC) -g -Wall $(CFLAGS) -o $@ table.o clutter-dominatrix.o clutter-video-player.o $(LIBS)
++	$(CC) -g -Wall $(CFLAGS) $(LDFLAGS) -o $@ table.o clutter-dominatrix.o clutter-video-player.o $(LIBS)
+ 
+ clean:
+ 	rm -fr *.o table
+\ No newline at end of file