documentation: Updated release date to May in the manual rev. tables.

(From yocto-docs rev: 66d2c65daf3a30e244253213e49eeb9092a9b709)

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

.gitignore

@@ -1,4 +1,3 @@
-bitbake
 *.pyc
 *.pyo
 /*.patch
@@ -9,10 +8,10 @@ scripts/oe-git-proxy-socks
 sources/
 meta-*
 !meta-skeleton
-!meta-demoapps
+!meta-hob
 *.swp
 *.orig
 *.rej
 *~
-
-
+!meta-yocto
+!meta-yocto-bsp

bitbake/lib/bb/build.py

@@ -29,6 +29,7 @@ import os
 import sys
 import logging
 import shlex
+import glob
 import bb
 import bb.msg
 import bb.process
@@ -491,9 +492,11 @@ def stamp_cleanmask_internal(taskname, d, file_name):
         extrainfo = d.getVarFlag(taskflagname, 'stamp-extra-info', True) or ""
 
     if not stamp:
-        return
+        return []
 
-    return bb.parse.siggen.stampcleanmask(stamp, file_name, taskname, extrainfo)
+    cleanmask = bb.parse.siggen.stampcleanmask(stamp, file_name, taskname, extrainfo)
+
+    return [cleanmask, cleanmask.replace(taskflagname, taskflagname + "_setscene")]
 
 def make_stamp(task, d, file_name = None):
     """
@@ -501,9 +504,16 @@ def make_stamp(task, d, file_name = None):
     (d can be a data dict or dataCache)
     """
     cleanmask = stamp_cleanmask_internal(task, d, file_name)
-    if cleanmask:
-        bb.utils.remove(cleanmask)
-
+    for mask in cleanmask:
+        for name in glob.glob(mask):
+            # Preserve sigdata files in the stamps directory
+            if "sigdata" in name:
+                continue
+            # Preserve taint files in the stamps directory
+            if name.endswith('.taint'):
+                continue
+            os.unlink(name)
+    
     stamp = stamp_internal(task, d, file_name)
     # Remove the file and recreate to force timestamp
     # change on broken NFS filesystems

bitbake/lib/bb/codeparser.py

@@ -35,7 +35,7 @@ def check_indent(codestr):
 
 class CodeParserCache(MultiProcessCache):
     cache_file_name = "bb_codeparser.dat"
-    CACHE_VERSION = 2
+    CACHE_VERSION = 3
 
     def __init__(self):
         MultiProcessCache.__init__(self)
@@ -100,7 +100,8 @@ class BufferedLogger(Logger):
         self.buffer = []
 
 class PythonParser():
-    getvars = ("d.getVar", "bb.data.getVar", "data.getVar")
+    getvars = ("d.getVar", "bb.data.getVar", "data.getVar", "d.appendVar", "d.prependVar")
+    containsfuncs = ("bb.utils.contains", "base_contains", "oe.utils.contains")
     execfuncs = ("bb.build.exec_func", "bb.build.exec_task")
 
     def warn(self, func, arg):
@@ -119,7 +120,7 @@ class PythonParser():
 
     def visit_Call(self, node):
         name = self.called_node_name(node.func)
-        if name in self.getvars:
+        if name in self.getvars or name in self.containsfuncs:
             if isinstance(node.args[0], ast.Str):
                 self.var_references.add(node.args[0].s)
             else:

bitbake/lib/bb/command.py

@@ -44,6 +44,9 @@ class CommandFailed(CommandExit):
         self.error = message
         CommandExit.__init__(self, 1)
 
+class CommandError(Exception):
+    pass
+
 class Command:
     """
     A queue of asynchronous commands for bitbake
@@ -57,21 +60,25 @@ class Command:
         self.currentAsyncCommand = None
 
     def runCommand(self, commandline):
-        try:
-            command = commandline.pop(0)
-            if command in CommandsSync.__dict__:
-                # Can run synchronous commands straight away
-                return getattr(CommandsSync, command)(self.cmds_sync, self, commandline)
-            if self.currentAsyncCommand is not None:
-                return "Busy (%s in progress)" % self.currentAsyncCommand[0]
-            if command not in CommandsAsync.__dict__:
-                return "No such command"
-            self.currentAsyncCommand = (command, commandline)
-            self.cooker.server_registration_cb(self.cooker.runCommands, self.cooker)
-            return True
-        except:
-            import traceback
-            return traceback.format_exc()
+        command = commandline.pop(0)
+        if hasattr(CommandsSync, command):
+            # Can run synchronous commands straight away
+            command_method = getattr(self.cmds_sync, command)
+            try:
+                result = command_method(self, commandline)
+            except CommandError as exc:
+                return None, exc.args[0]
+            except Exception:
+                return None, traceback.format_exc()
+            else:
+                return result, None
+        if self.currentAsyncCommand is not None:
+            return None, "Busy (%s in progress)" % self.currentAsyncCommand[0]
+        if command not in CommandsAsync.__dict__:
+            return None, "No such command"
+        self.currentAsyncCommand = (command, commandline)
+        self.cooker.server_registration_cb(self.cooker.runCommands, self.cooker)
+        return True, None
 
     def runAsyncCommand(self):
         try:
@@ -139,7 +146,11 @@ class CommandsSync:
         """
         Get any command parsed from the commandline
         """
-        return command.cooker.commandlineAction
+        cmd_action = command.cooker.commandlineAction
+        if cmd_action['msg']:
+            raise CommandError(msg)
+        else:
+            return cmd_action['action']
 
     def getVariable(self, command, params):
         """

bitbake/lib/bb/cooker.py

@@ -1353,7 +1353,10 @@ 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)
+        try:
+            prserv.serv.auto_start(self.configuration.data)
+        except prserv.serv.PRServiceConfigError:
+            bb.event.fire(CookerExit(), self.configuration.event_data)
         return
 
     def post_serve(self):

bitbake/lib/bb/data_smart.py

@@ -474,12 +474,16 @@ class DataSmart(MutableMapping):
 
     def get_hash(self):
         data = {}
-        config_whitelist = set((self.getVar("BB_HASHCONFIG_WHITELIST", True) or "").split())
-        keys = set(key for key in iter(self) if not key.startswith("__"))
+        d = self.createCopy()
+        bb.data.expandKeys(d)
+        bb.data.update_data(d)
+
+        config_whitelist = set((d.getVar("BB_HASHCONFIG_WHITELIST", True) or "").split())
+        keys = set(key for key in iter(d) if not key.startswith("__"))
         for key in keys:
             if key in config_whitelist:
                 continue
-            value = self.getVar(key, False) or ""
+            value = d.getVar(key, False) or ""
             data.update({key:value})
 
         data_str = str([(k, data[k]) for k in sorted(data.keys())])

bitbake/lib/bb/fetch2/ssh.py

@@ -10,6 +10,12 @@ IETF secsh internet draft:
     Currently does not support the sftp parameters, as this uses scp
     Also does not support the 'fingerprint' connection parameter.
 
+    Please note that '/' is used as host, path separator not ':' as you may 
+    be used to, also '~' can be used to specify user HOME, but again after '/'
+    
+    Example SRC_URI:
+    SRC_URI = "ssh://user@host.example.com/dir/path/file.txt"
+    SRC_URI = "ssh://user@host.example.com/~/file.txt"
 '''
 
 # Copyright (C) 2006  OpenedHand Ltd.
@@ -72,15 +78,19 @@ class SSH(FetchMethod):
     def supports_checksum(self, urldata):
         return False
 
-    def localpath(self, url, urldata, d):
+    def urldata_init(self, urldata, d):
+        if 'protocol' in urldata.parm and urldata.parm['protocol'] == 'git':
+            raise bb.fetch2.ParameterError(
+                "Invalid protocol - if you wish to fetch from a git " +
+                "repository using ssh, you need to use " +
+                "git:// prefix with protocol=ssh", urldata.url)
         m = __pattern__.match(urldata.url)
         path = m.group('path')
         host = m.group('host')
-        lpath = os.path.join(data.getVar('DL_DIR', d, True), host, os.path.basename(path))
-        return lpath
+        urldata.localpath = os.path.join(d.getVar('DL_DIR', True), os.path.basename(path))
 
     def download(self, url, urldata, d):
-        dldir = data.getVar('DL_DIR', d, True)
+        dldir = d.getVar('DL_DIR', True)
 
         m = __pattern__.match(url)
         path = m.group('path')
@@ -89,16 +99,10 @@ class SSH(FetchMethod):
         user = m.group('user')
         password = m.group('pass')
 
-        ldir = os.path.join(dldir, host)
-        lpath = os.path.join(ldir, os.path.basename(path))
-
-        if not os.path.exists(ldir):
-            os.makedirs(ldir)
-
         if port:
-            port = '-P %s' % port
+            portarg = '-P %s' % port
         else:
-            port = ''
+            portarg = ''
 
         if user:
             fr = user
@@ -112,9 +116,9 @@ class SSH(FetchMethod):
 
         import commands
         cmd = 'scp -B -r %s %s %s/' % (
-            port,
+            portarg,
             commands.mkarg(fr),
-            commands.mkarg(ldir)
+            commands.mkarg(dldir)
         )
 
         bb.fetch2.check_network_access(d, cmd, urldata.url)

bitbake/lib/bb/fetch2/wget.py

@@ -69,10 +69,10 @@ class Wget(FetchMethod):
             basecmd += " -O ${DL_DIR}/" + ud.localfile
 
         if checkonly:
-            fetchcmd = d.getVar("CHECKCOMMAND_wget", True) or d.expand(basecmd + " -c -P ${DL_DIR} '${URI}'")
+            fetchcmd = d.getVar("CHECKCOMMAND_wget", True) or d.expand(basecmd + " --spider '${URI}'")
         elif os.path.exists(ud.localpath):
             # file exists, but we didnt complete it.. trying again..
-            fetchcmd = d.getVar("RESUMECOMMAND_wget", True) or d.expand(basecmd + " --spider -P ${DL_DIR} '${URI}'")
+            fetchcmd = d.getVar("RESUMECOMMAND_wget", True) or d.expand(basecmd + " -c -P ${DL_DIR} '${URI}'")
         else:
             fetchcmd = d.getVar("FETCHCOMMAND_wget", True) or d.expand(basecmd + " -P ${DL_DIR} '${URI}'")
 

bitbake/lib/bb/monitordisk.py

@@ -128,7 +128,7 @@ def getDiskData(BBDirs, configuration):
         if not os.path.exists(path):
             bb.utils.mkdirhier(path)
         mountedDev = getMountedDev(path)
-        devDict[mountedDev] = action, path, minSpace, minInode
+        devDict[mountedDev] = [action, path, minSpace, minInode]
 
     return devDict
 
@@ -231,6 +231,13 @@ class diskMonitor:
                 freeInode = st.f_favail
 
                 if self.devDict[dev][3] and freeInode < self.devDict[dev][3]:
+                    # Some fs formats' (e.g., btrfs) statvfs.f_files (inodes) is
+                    # zero, this is a feature of the fs, we disable the inode
+                    # checking for such a fs.
+                    if st.f_files == 0:
+                        logger.warn("Inode check for %s is unavaliable, remove it from disk monitor" % dev)
+                        self.devDict[dev][3] = None
+                        continue
                     # Always show warning, the self.checked would always be False if the action is WARN
                     if self.preFreeI[dev] == 0 or self.preFreeI[dev] - freeInode > self.inodeInterval and not self.checked[dev]:
                         logger.warn("The free inode of %s is running low (%.3fK left)" % (dev, freeInode / 1024.0))

bitbake/lib/bb/server/process.py

@@ -48,7 +48,7 @@ class ServerCommunicator():
                 if self.connection.poll(.5):
                     return self.connection.recv()
                 else:
-                    return None
+                    return None, "Timeout while attempting to communicate with bitbake server"
             except KeyboardInterrupt:
                 pass
 

bitbake/lib/bb/siggen.py

@@ -49,7 +49,7 @@ class SignatureGenerator(object):
         return ("%s.%s.%s" % (stampbase, taskname, extrainfo)).rstrip('.')
 
     def stampcleanmask(self, stampbase, file_name, taskname, extrainfo):
-        return ("%s.%s*.%s" % (stampbase, taskname, extrainfo)).rstrip('.')
+        return ("%s.%s.%s" % (stampbase, taskname, extrainfo)).rstrip('.')
 
     def dump_sigtask(self, fn, task, stampbase, runtime):
         return
@@ -276,7 +276,6 @@ class SignatureGeneratorBasicHash(SignatureGeneratorBasic):
             k = fn + "." + taskname
         if clean:
             h = "*"
-            taskname = taskname + "*"
         elif k in self.taskhash:
             h = self.taskhash[k]
         else:

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

@@ -101,7 +101,10 @@ class HobHandler(gobject.GObject):
 
     def runCommand(self, commandline):
         try:
-            return self.server.runCommand(commandline)
+            result, error = self.server.runCommand(commandline)
+            if error:
+                raise Exception("Error running command '%s': %s" % (commandline, error))
+            return result
         except Exception as e:
             self.commands_async = []
             self.clear_busy()
@@ -398,7 +401,7 @@ class HobHandler(gobject.GObject):
         self.build.reset()
 
     def get_logfile(self):
-        return self.server.runCommand(["getVariable", "BB_CONSOLELOG"])
+        return self.server.runCommand(["getVariable", "BB_CONSOLELOG"])[0]
 
     def _remove_redundant(self, string):
         ret = []

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

@@ -42,7 +42,7 @@ class PackageListModel(gtk.TreeStore):
                                 ()),
     }
 
-    __toolchain_required_packages__ = ["task-core-standalone-sdk-target", "task-core-standalone-sdk-target-dbg"]
+    __toolchain_required_packages__ = ["packagegroup-core-standalone-sdk-target", "packagegroup-core-standalone-sdk-target-dbg"]
 
     def __init__(self):
 

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

@@ -368,6 +368,7 @@ class ImageConfigurationPage (HobPage):
         if self.builder.parameters.image_black_pattern:
             for i in self.builder.parameters.image_black_pattern.split():
                 black_pattern.append(re.compile(i))
+        black_pattern.append(re.compile("hob-image"))
 
         it = image_model.get_iter_first()
         self._image_combo_disconnect_signal()

bitbake/lib/bb/ui/depexp.py

@@ -198,17 +198,23 @@ class gtkthread(threading.Thread):
 
 def main(server, eventHandler):
     try:
-        cmdline = server.runCommand(["getCmdLineAction"])
-        if cmdline and not cmdline['action']:
-            print(cmdline['msg'])
-            return
-        elif not cmdline or (cmdline['action'] and cmdline['action'][0] != "generateDotGraph"):
+        cmdline, error = server.runCommand(["getCmdLineAction"])
+        if error:
+            print("Error getting bitbake commandline: %s" % error)
+            return 1
+        elif not cmdline:
+            print("Nothing to do.  Use 'bitbake world' to build everything, or run 'bitbake --help' for usage information.")
+            return 1
+        elif not cmdline or cmdline[0] != "generateDotGraph":
             print("This UI is only compatible with the -g option")
-            return
-        ret = server.runCommand(["generateDepTreeEvent", cmdline['action'][1], cmdline['action'][2]])
-        if ret != True:
-            print("Couldn't run command! %s" % ret)
-            return
+            return 1
+        ret, error = server.runCommand(["generateDepTreeEvent", cmdline[1], cmdline[2]])
+        if error:
+            print("Error running command '%s': %s" % (cmdline, error))
+            return 1
+        elif ret != True:
+            print("Error running command '%s': returned %s" % (cmdline, ret))
+            return 1
     except xmlrpclib.Fault as x:
         print("XMLRPC Fault getting commandline:\n %s" % x)
         return
@@ -234,7 +240,9 @@ def main(server, eventHandler):
         try:
             event = eventHandler.waitEvent(0.25)
             if gtkthread.quit.isSet():
-                server.runCommand(["stateStop"])
+                _, error = server.runCommand(["stateStop"])
+                if error:
+                    print('Unable to cleanly stop: %s' % error)
                 break
 
             if event is None:
@@ -310,9 +318,13 @@ def main(server, eventHandler):
                 break
             if shutdown == 1:
                 print("\nSecond Keyboard Interrupt, stopping...\n")
-                server.runCommand(["stateStop"])
+                _, error = server.runCommand(["stateStop"])
+                if error:
+                    print('Unable to cleanly stop: %s' % error)
             if shutdown == 0:
                 print("\nKeyboard Interrupt, closing down...\n")
-                server.runCommand(["stateShutdown"])
+                _, error = server.runCommand(["stateShutdown"])
+                if error:
+                    print('Unable to cleanly shutdown: %s' % error)
             shutdown = shutdown + 1
             pass

bitbake/lib/bb/ui/goggle.py

@@ -80,16 +80,19 @@ def main (server, eventHandler):
     running_build.connect ("build-failed", running_build_failed_cb)
 
     try:
-        cmdline = server.runCommand(["getCmdLineAction"])
-        if not cmdline:
+        cmdline, error = server.runCommand(["getCmdLineAction"])
+        if err:
+            print("Error getting bitbake commandline: %s" % error)
+            return 1
+        elif not cmdline:
             print("Nothing to do.  Use 'bitbake world' to build everything, or run 'bitbake --help' for usage information.")
             return 1
-        elif not cmdline['action']:
-            print(cmdline['msg'])
+        ret, error = server.runCommand(cmdline)
+        if error:
+            print("Error running command '%s': %s" % (cmdline, error))
             return 1
-        ret = server.runCommand(cmdline['action'])
-        if ret != True:
-            print("Couldn't get default commandline! %s" % ret)
+        elif ret != True:
+            print("Error running command '%s': returned %s" % (cmdline, ret))
             return 1
     except xmlrpclib.Fault as x:
         print("XMLRPC Fault getting commandline:\n %s" % x)

bitbake/lib/bb/ui/knotty.py

@@ -217,9 +217,19 @@ class TerminalFilter(object):
 def main(server, eventHandler, tf = TerminalFilter):
 
     # 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"])
+    includelogs, error = server.runCommand(["getVariable", "BBINCLUDELOGS"])
+    if error:
+        logger.error("Unable to get the value of BBINCLUDELOGS variable: %s" % error)
+        return 1
+    loglines, error = server.runCommand(["getVariable", "BBINCLUDELOGS_LINES"])
+    if error:
+        logger.error("Unable to get the value of BBINCLUDELOGS_LINES variable: %s" % error)
+        return 1
+    consolelogfile, error = server.runCommand(["getVariable", "BB_CONSOLELOG"])
+    if error:
+        logger.error("Unable to get the value of BB_CONSOLELOG variable: %s" % error)
+        return 1
+
     if sys.stdin.isatty() and sys.stdout.isatty():
         log_exec_tty = True
     else:
@@ -240,19 +250,22 @@ def main(server, eventHandler, tf = TerminalFilter):
         logger.addHandler(consolelog)
 
     try:
-        cmdline = server.runCommand(["getCmdLineAction"])
-        if not cmdline:
+        cmdline, error = server.runCommand(["getCmdLineAction"])
+        if error:
+            logger.error("Unable to get bitbake commandline arguments: %s" % error)
+            return 1
+        elif not cmdline:
             print("Nothing to do.  Use 'bitbake world' to build everything, or run 'bitbake --help' for usage information.")
             return 1
-        elif not cmdline['action']:
-            print(cmdline['msg'])
+        ret, error = server.runCommand(cmdline)
+        if error:
+            logger.error("Command '%s' failed: %s" % (cmdline, error))
             return 1
-        ret = server.runCommand(cmdline['action'])
-        if ret != True:
-            print("Couldn't get default commandline! %s" % ret)
+        elif ret != True:
+            logger.error("Command '%s' failed: returned %s" % (cmdline, ret))
             return 1
     except xmlrpclib.Fault as x:
-        print("XMLRPC Fault getting commandline:\n %s" % x)
+        logger.error("XMLRPC Fault getting commandline:\n %s" % x)
         return 1
 
     parseprogress = None
@@ -436,7 +449,8 @@ def main(server, eventHandler, tf = TerminalFilter):
                                   bb.runqueue.runQueueExitWait,
                                   bb.event.OperationStarted,
                                   bb.event.OperationCompleted,
-                                  bb.event.OperationProgress)):
+                                  bb.event.OperationProgress,
+                                  bb.event.DiskFull)):
                 continue
 
             logger.error("Unknown event: %s", event)
@@ -447,14 +461,19 @@ def main(server, eventHandler, tf = TerminalFilter):
             if ioerror.args[0] == 4:
                 pass
         except KeyboardInterrupt:
+            import time
             termfilter.clearFooter()
             if main.shutdown == 1:
                 print("\nSecond Keyboard Interrupt, stopping...\n")
-                server.runCommand(["stateStop"])
+                _, error = server.runCommand(["stateStop"])
+                if error:
+                    logger.error("Unable to cleanly stop: %s" % error)
             if main.shutdown == 0:
-                interrupted = True
                 print("\nKeyboard Interrupt, closing down...\n")
-                server.runCommand(["stateShutdown"])
+                interrupted = True
+                _, error = server.runCommand(["stateShutdown"])
+                if error:
+                    logger.error("Unable to cleanly shutdown: %s" % error)
             main.shutdown = main.shutdown + 1
             pass
 

bitbake/lib/bb/ui/ncurses.py

@@ -236,15 +236,18 @@ class NCursesUI:
         shutdown = 0
 
         try:
-            cmdline = server.runCommand(["getCmdLineAction"])
+            cmdline, error = server.runCommand(["getCmdLineAction"])
             if not cmdline:
                 print("Nothing to do.  Use 'bitbake world' to build everything, or run 'bitbake --help' for usage information.")
                 return
-            elif not cmdline['action']:
-                print(cmdline['msg'])
+            elif error:
+                print("Error getting bitbake commandline: %s" % error)
                 return
-            ret = server.runCommand(cmdline['action'])
-            if ret != True:
+            ret, error = server.runCommand(cmdline)
+            if error:
+                print("Error running command '%s': %s" % (cmdline, error))
+                return
+            elif ret != True:
                 print("Couldn't get default commandlind! %s" % ret)
                 return
         except xmlrpclib.Fault as x:
@@ -345,10 +348,14 @@ class NCursesUI:
                     exitflag = True
                 if shutdown == 1:
                     mw.appendText("Second Keyboard Interrupt, stopping...\n")
-                    server.runCommand(["stateStop"])
+                    _, error = server.runCommand(["stateStop"])
+                    if error:
+                        print("Unable to cleanly stop: %s" % error)
                 if shutdown == 0:
                     mw.appendText("Keyboard Interrupt, closing down...\n")
-                    server.runCommand(["stateShutdown"])
+                    _, error = server.runCommand(["stateShutdown"])
+                    if error:
+                        print("Unable to cleanly shutdown: %s" % error)
                 shutdown = shutdown + 1
                 pass
 

bitbake/lib/prserv/serv.py

@@ -266,17 +266,20 @@ def is_local_special(host, port):
     else:
         return False
 
+class PRServiceConfigError(Exception):
+    pass
+
 def auto_start(d):
     global singleton
     if (not d.getVar('PRSERV_HOST', True)) or (not d.getVar('PRSERV_PORT', True)):
-        return True
+        return
 
     if is_local_special(d.getVar('PRSERV_HOST', True), int(d.getVar('PRSERV_PORT', True))) and not singleton:
         import bb.utils
         cachedir = (d.getVar("PERSISTENT_DIR", True) or d.getVar("CACHE", True))
         if not cachedir:
             logger.critical("Please set the 'PERSISTENT_DIR' or 'CACHE' variable")
-            sys.exit(1)
+            raise PRServiceConfigError
         bb.utils.mkdirhier(cachedir)
         dbfile = os.path.join(cachedir, "prserv.sqlite3")
         logfile = os.path.join(cachedir, "prserv.log")
@@ -292,7 +295,7 @@ def auto_start(d):
         return PRServerConnection(host,port).ping()
     except Exception:
         logger.critical("PRservice %s:%d not available" % (host, port))
-    return False
+        raise PRServiceConfigError
 
 def auto_shutdown(d=None):
     global singleton

documentation/Makefile

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

documentation/adt-manual/adt-command.xml

@@ -8,9 +8,9 @@
     <para>
         Recall that earlier the manual discussed how to use an existing toolchain 
         tarball that had been installed into <filename>/opt/poky</filename>, 
-        which is outside of the build directory 
-        (see the section "<link linkend='using-an-existing-toolchain-tarball'>Using an Existing 
-        Toolchain Tarball)</link>".  
+        which is outside of the 
+        <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
+        (see the section "<link linkend='using-an-existing-toolchain-tarball'>Using a Cross-Toolchain Tarball)</link>".  
         And, that sourcing your architecture-specific environment setup script 
         initializes a suitable cross-toolchain development environment.  
         During the setup, locations for the compiler, QEMU scripts, QEMU binary, 

documentation/adt-manual/adt-intro.xml

@@ -55,7 +55,9 @@
             The cross-toolchain consists of a cross-compiler, cross-linker, and cross-debugger 
             that are used to develop user-space applications for targeted hardware.
             This toolchain is created either by running the ADT Installer script, a toolchain installer
-            script, or through a build directory that is based on your metadata 
+            script, or through a 
+            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink> that 
+            is based on your metadata 
             configuration or extension for your targeted device.  
             The cross-toolchain works with a matching target sysroot.
         </para>
@@ -111,7 +113,9 @@
                 <listitem><para>If you use the ADT Installer script to install ADT, you can 
                     specify whether or not to install QEMU.</para></listitem>
                 <listitem><para>If you have downloaded a Yocto Project release and unpacked 
-                    it to create a source directory and you have sourced  
+                    it to create a 
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink> and 
+                    you have sourced  
                     the environment setup script, QEMU is installed and automatically 
                     available.</para></listitem>
                 <listitem><para>If you have installed the cross-toolchain 
@@ -139,7 +143,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 

documentation/adt-manual/adt-manual.xml

@@ -2,7 +2,7 @@
 "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
 [<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
-<book id='adt-manual' lang='en' 
+<book id='adt-manual' lang='en'
       xmlns:xi="http://www.w3.org/2003/XInclude"
       xmlns="http://docbook.org/ns/docbook"
       >
@@ -10,10 +10,10 @@
 
         <mediaobject>
             <imageobject>
-                <imagedata fileref='figures/adt-title.png' 
-                    format='SVG' 
+                <imagedata fileref='figures/adt-title.png'
+                    format='SVG'
                     align='left' scalefit='1' width='100%'/>
-            </imageobject>    
+            </imageobject>
         </mediaobject>
 
         <title></title>
@@ -51,9 +51,19 @@
             </revision>
             <revision>
                 <revnumber>1.3</revnumber>
-                <date>Sometime in 2012</date>
+                <date>October 2012</date>
                 <revremark>Released with the Yocto Project 1.3 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>1.3.1</revnumber>
+                <date>April 2013</date>
+                <revremark>Released with the Yocto Project 1.3.1 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.3.2</revnumber>
+                <date>May 2013</date>
+                <revremark>Released with the Yocto Project 1.3.2 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>
@@ -63,12 +73,12 @@
 
     <legalnotice>
       <para>
-        Permission is granted to copy, distribute and/or modify this document under 
+        Permission is granted to copy, distribute and/or modify this document under
         the terms of the <ulink type="http" url="http://creativecommons.org/licenses/by-sa/2.0/uk/">Creative Commons Attribution-Share Alike 2.0 UK: England &amp; Wales</ulink> as published by Creative Commons.
       </para>
       <note>
           Due to production processes, there could be differences between the Yocto Project
-          documentation bundled in the release tarball and the 
+          documentation bundled in the release tarball and the
           <ulink url='&YOCTO_DOCS_ADT_URL;'>Yocto Project Application Developer's Guide</ulink> on
           the <ulink url='&YOCTO_HOME_URL;'>Yocto Project</ulink> website.
           For the latest version of this manual, see the manual on the website.
@@ -92,6 +102,6 @@
 -->
 
 </book>
-<!-- 
-vim: expandtab tw=80 ts=4 
+<!--
+vim: expandtab tw=80 ts=4
 -->

documentation/adt-manual/adt-package.xml

@@ -78,7 +78,7 @@
 
     <para>
         Next, source the environment setup script found in the 
-        <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>.  
+        <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.  
         Follow that by setting up the installation destination to point to your 
         sysroot as <filename>&lt;sysroot_dir&gt;</filename>.  
         Finally, have an OPKG configuration file <filename>&lt;conf_file&gt;</filename>

documentation/adt-manual/adt-prepare.xml

@@ -52,7 +52,7 @@
                 get any of the other mentioned benefits had you run the ADT Installer script.</para></listitem>
             <listitem><para><emphasis>Use the Toolchain from within the Build Directory:</emphasis>
                 If you already have a 
-                <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>, 
+                <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>, 
                 you can build the cross-toolchain within the directory.
                 However, like the previous method mentioned, you only get the cross-toolchain and QEMU - you 
                 do not get any of the other benefits without taking separate steps.</para></listitem>
@@ -63,8 +63,16 @@
         <title>Using the ADT Installer</title>
 
         <para>
-            To run the ADT Installer, you need to first get the ADT Installer tarball and then run the ADT
-            Installer Script.
+            To run the ADT Installer, you need to get the ADT Installer tarball, be sure 
+            you have the necessary host development packages that support the ADT Installer, 
+            and then run the ADT Installer Script.
+        </para>
+
+        <para>
+            For a list of the host packages needed to support ADT installation and use, see the
+            "ADT Installer Extras" lists in the 
+            "<ulink url='&YOCTO_DOCS_REF_URL;#required-packages-for-the-host-development-system'>Required Packages for the Host Development System</ulink>" section
+            of the Yocto Project Reference Manual.
         </para>
 
         <section id='getting-the-adt-installer-tarball'>
@@ -77,21 +85,21 @@
                 at  
                 <ulink url='&YOCTO_ADTINSTALLER_DL_URL;'></ulink>.
                 Or, you can use BitBake to generate the tarball inside the existing 
-                <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>.
+                <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
             </para>
 
             <para>
                 If you use BitBake to generate the ADT Installer tarball, you must 
                 <filename>source</filename> the environment setup script 
                 (<filename>&OE_INIT_FILE;</filename>) located 
-                in the source directory before running the <filename>bitbake</filename>
+                in the Source Directory before running the <filename>bitbake</filename>
                 command that creates the tarball.
             </para>
 
             <para>
                 The following example commands download the Poky tarball, set up the 
-                <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>, 
-                set up the environment while also creating the default build directory, 
+                <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>, 
+                set up the environment while also creating the default Build Directory, 
                 and run the <filename>bitbake</filename> command that results in the tarball 
                 <filename>~/yocto-project/build/tmp/deploy/sdk/adt_installer.tar.bz2</filename>:
                 <literallayout class='monospaced'>
@@ -120,13 +128,16 @@
      $ 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>).
+                Unpacking the tarball creates the directory <filename>adt-installer</filename>, 
+                which contains the ADT Installer script (<filename>adt_installer</filename>),
+                its configuration file (<filename>adt_installer.conf</filename>), a
+                <filename>scripts</filename> directory, and an <filename>opkg</filename> 
+                directory.
             </para>
 
             <para>
-                Before you run the script, however, you should examine the ADT Installer configuration 
+                Before you run the ADT Installer script, however, you should examine 
+                the ADT Installer configuration 
                 file and be sure you are going to get what you want.  
                 Your configurations determine which kernel and filesystem image are downloaded.
             </para>
@@ -144,7 +155,22 @@
                         <filename>YOCTOADT_REPO</filename>, you need to be sure that the 
                         directory structure follows the same layout as the reference directory 
                         set up at <ulink url='http://adtrepo.yoctoproject.org'></ulink>.  
-                        Also, your repository needs to be accessible through HTTP.</para></listitem>
+                        Also, your repository needs to be accessible through HTTP.</para>
+                        <para>Additionally, you will need to edit a second configuration file
+                        located in the <filename>adt-installer/opkg</filename> directory.
+                        The configuration file you edit depends on your host development
+                        system.
+                        For 64-bit systems, edit the <filename>opkg-sdk-x86_64.conf</filename>
+                        file.
+                        If your host development system is 32-bit, edit the 
+                        <filename>opkg-sdk-i686.conf</filename> file.
+                        For both cases, you need to make sure you are pointing to 
+                        the IPKG-based packages specified by the 
+                        <filename>YOCTOADT_REPO</filename>.
+                        Here is an example for a 64-bit development system:
+                        <literallayout class='monospaced'>
+     src yp-x86_64-nativesdk http://my_repo/yp-1.3.1/adt-ipk/x86_64-nativesdk
+                        </literallayout></para></listitem>
                     <listitem><para><filename>YOCTOADT_TARGETS</filename>: The machine 
                         target architectures for which you want to set up cross-development 
                         environments.</para></listitem>
@@ -190,16 +216,6 @@
      $ cd ~/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  
-                "<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>
                 Once the installer begins to run, you are asked to enter the location for 
                 cross-toolchain installation.
                 The default location is <filename>/opt/poky/&lt;release&gt;</filename>.
@@ -251,7 +267,7 @@
      poky-eglibc-x86_64-i586-toolchain-gmae-&DISTRO;.sh
                     </literallayout>
                     <note><para>As an alternative to steps one and two, you can build the toolchain installer 
-                        if you have a <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>.
+                        if you have a <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
                         If you need GMAE, you should use the <filename>bitbake meta-toolchain-gmae</filename>
                         command. 
                         The resulting installation script when run will support such development.
@@ -259,10 +275,10 @@
                         you can generate the toolchain installer using
                         <filename>bitbake meta-toolchain</filename>.</para>
                         <para>Use the appropriate <filename>bitbake</filename> command only after you have 
-                        sourced the <filename>oe-build-init-env</filename> script located in the source
-                        directory.  
+                        sourced the <filename>&OE_INIT_PATH;</filename> script located in the Source
+                        Directory.  
                         When the <filename>bitbake</filename> command completes, the toolchain installer will 
-                        be in <filename>tmp/deploy/sdk</filename> in the build directory.
+                        be in <filename>tmp/deploy/sdk</filename> in the Build Directory.
                         </para></note>
                     </para></listitem>
                 <listitem><para>Once you have the installer, run it to install the toolchain.
@@ -292,7 +308,7 @@
         <para>
             A final way of making the cross-toolchain available is to use BitBake 
             to generate the toolchain within an existing 
-            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>.
+            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
             This method does not install the toolchain into the 
             <filename>/opt</filename> directory.
             As with the previous method, if you need to install the target sysroot, you must 
@@ -300,20 +316,20 @@
         </para>
 
         <para>
-            Follow these steps to generate the toolchain into the build directory:
+            Follow these steps to generate the toolchain into the Build Directory:
             <orderedlist>
                 <listitem><para>Source the environment setup script 
                     <filename>&OE_INIT_FILE;</filename> located in the 
-                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>.
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
                     </para></listitem> 
                 <listitem><para>At this point, you should be sure that the 
                     <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink> variable 
                     in the <filename>local.conf</filename> file found in the 
-                    <filename>conf</filename> directory of the build directory
+                    <filename>conf</filename> directory of the Build Directory
                     is set for the target architecture.
                     Comments within the <filename>local.conf</filename> file list the values you 
                     can use for the <filename>MACHINE</filename> variable.  
-                    <note>You can populate the build directory with the cross-toolchains for more 
+                    <note>You can populate the Build Directory with the cross-toolchains for more 
                         than a single architecture.  
                         You just need to edit the <filename>MACHINE</filename> variable in the 
                         <filename>local.conf</filename> file and re-run the BitBake 
@@ -327,9 +343,9 @@
                         after checking or editing the <filename>local.conf</filename> but without 
                         changing out of your working directory.</note>
                     Once the <filename>bitbake</filename> command finishes, 
-                    the cross-toolchain is generated and populated within the build directory.
+                    the cross-toolchain is generated and populated within the Build Directory.
                     You will notice environment setup files for the cross-toolchain in the 
-                    build directory in the <filename>tmp</filename> directory.
+                    Build Directory in the <filename>tmp</filename> directory.
                     Setup script filenames contain the strings <filename>environment-setup</filename>.</para>
                     <para>Be aware that when you use this method to install the toolchain you still need
                     to separately extract and install the sysroot filesystem.
@@ -351,9 +367,9 @@
         then you can find this script in the <filename>&YOCTO_ADTPATH_DIR;</filename>
         directory.  
         If you installed the toolchain in the 
-        <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>, 
+        <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>, 
         you can find the environment setup 
-        script for the toolchain in the build directory's <filename>tmp</filename> directory.
+        script for the toolchain in the Build Directory's <filename>tmp</filename> directory.
     </para>
 
     <para> 
@@ -426,7 +442,7 @@
             you can do so one of two ways:
             <itemizedlist>
                 <listitem><para>Modify the <filename>conf/local.conf</filename> configuration in 
-                    the <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>
+                    the <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
                     and then rebuild the image.
                     With this method, you need to modify the 
                     <ulink url='&YOCTO_DOCS_REF_URL;#var-EXTRA_IMAGE_FEATURES'><filename>EXTRA_IMAGE_FEATURES</filename></ulink>

documentation/bsp-guide/bsp-guide.xml

@@ -2,7 +2,7 @@
 "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
 [<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
-<book id='bsp-guide' lang='en' 
+<book id='bsp-guide' lang='en'
       xmlns:xi="http://www.w3.org/2003/XInclude"
       xmlns="http://docbook.org/ns/docbook"
       >
@@ -10,13 +10,13 @@
 
         <mediaobject>
             <imageobject>
-                <imagedata fileref='figures/bsp-title.png' 
-                    format='SVG' 
+                <imagedata fileref='figures/bsp-title.png'
+                    format='SVG'
                     align='center' scalefit='1' width='100%'/>
-            </imageobject>    
+            </imageobject>
         </mediaobject>
 
-        <title></title> 
+        <title></title>
 
         <authorgroup>
             <author>
@@ -63,9 +63,19 @@
             </revision>
             <revision>
                 <revnumber>1.3</revnumber>
-                <date>Sometime in 2012</date>
+                <date>October 2012</date>
                 <revremark>Released with the Yocto Project 1.3 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>1.3.1</revnumber>
+                <date>April 2013</date>
+                <revremark>Released with the Yocto Project 1.3.1 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.3.2</revnumber>
+                <date>May 2013</date>
+                <revremark>Released with the Yocto Project 1.3.2 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>
@@ -75,12 +85,12 @@
 
     <legalnotice>
       <para>
-        Permission is granted to copy, distribute and/or modify this document under 
+        Permission is granted to copy, distribute and/or modify this document under
         the terms of the <ulink type="http" url="http://creativecommons.org/licenses/by-nc-sa/2.0/uk/">Creative Commons Attribution-Non-Commercial-Share Alike 2.0 UK: England &amp; Wales</ulink> as published by Creative Commons.
       </para>
       <note>
           Due to production processes, there could be differences between the Yocto Project
-          documentation bundled in the release tarball and the 
+          documentation bundled in the release tarball and the
           <ulink url='&YOCTO_DOCS_BSP_URL;'>Yocto Project Board Support Package (BSP) Developer's Guide</ulink> on
           the <ulink url='&YOCTO_HOME_URL;'>Yocto Project</ulink> website.
           For the latest version of this manual, see the manual on the website.
@@ -97,6 +107,6 @@
 -->
 
 </book>
-<!-- 
-vim: expandtab tw=80 ts=4 
+<!--
+vim: expandtab tw=80 ts=4
 -->

documentation/bsp-guide/bsp.xml

@@ -19,8 +19,7 @@
         </para>
 
         <para>
-            This chapter (or document if you are reading the BSP Developer's Guide) 
-            talks about BSP Layers, defines a structure for components
+            This guide presents information about BSP Layers, defines a structure for components
             so that BSPs follow a commonly understood layout, discusses how to customize
             a recipe for a BSP, addresses BSP licensing, and provides information that
             shows you how to create and manage a 
@@ -48,7 +47,7 @@
                 This root is what you add to the 
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-BBLAYERS'><filename>BBLAYERS</filename></ulink>
                 variable in the <filename>conf/bblayers.conf</filename> file found in the 
-                <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>.
+                <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
                 Adding the root allows the OpenEmbedded build system to recognize the BSP 
                 definition and from it build an image.
                 Here is an example:
@@ -56,6 +55,7 @@
      BBLAYERS = " \
         /usr/local/src/yocto/meta \
         /usr/local/src/yocto/meta-yocto \
+        /usr/local/src/yocto/meta-yocto-bsp \
         /usr/local/src/yocto/meta-&lt;bsp_name&gt; \
         "
                 </literallayout>
@@ -83,8 +83,6 @@
                 For more detailed information on layers, see the 
                 "<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and Creating Layers</ulink>" 
                 section of the Yocto Project Development Manual.
-                You can also see the detailed examples in the appendices of the
-                <ulink url='&YOCTO_DOCS_DEV_URL;'>Yocto Project Development Manual</ulink>.
             </para>
         </section>
 
@@ -182,9 +180,10 @@
      meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay-noemgd/xorg.conf
      meta-crownbay/recipes-kernel/
      meta-crownbay/recipes-kernel/linux/
-     meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.0.bbappend
-     meta-crownbay/recipes-kernel/linux/linux-yocto_2.6.37.bbappend
-     meta-crownbay/recipes-kernel/linux/linux-yocto_3.0.bbappend
+     meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend
+     meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.4.bbappend
+     meta-crownbay/recipes-kernel/linux/linux-yocto_3.2.bbappend
+     meta-crownbay/recipes-kernel/linux/linux-yocto_3.4.bbappend
                 </literallayout>
             </para>
 
@@ -388,7 +387,7 @@
             <para>
                 Tuning files are found in the <filename>meta/conf/machine/include</filename>
                 directory within the 
-                <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>.
+                <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
                 Tuning files can also reside in the BSP Layer itself.  
                 For example, the <filename>ia32-base.inc</filename> file resides in the 
                 <filename>meta-intel</filename> BSP Layer in <filename>conf/machine/include</filename>.
@@ -399,8 +398,8 @@
                 For example, the Crown Bay BSP <filename>crownbay.conf</filename> has the 
                 following statements:
                 <literallayout class='monospaced'>
-     include conf/machine/include/tune-atom.inc
-     include conf/machine/include/ia32-base.inc
+     require conf/machine/include/tune-atom.inc
+     require conf/machine/include/ia32-base.inc
                 </literallayout>
             </para>
             </section>
@@ -440,7 +439,7 @@
                 formfactor recipe 
                 <filename>meta/recipes-bsp/formfactor/formfactor_0.0.bb</filename>, 
                 which is found in the 
-                <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>.
+                <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
             </para></note>
             </section>
 
@@ -485,7 +484,7 @@
             </para>
             <para>
                 For your BSP, you typically want to use an existing Yocto Project kernel recipe found in the 
-                <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink> 
+                <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink> 
                 at <filename>meta/recipes-kernel/linux</filename>.
                 You can append your specific changes to the kernel recipe by using a
                 similarly named append file, which is located in the BSP Layer (e.g. 
@@ -495,11 +494,17 @@
                 Suppose you are using the <filename>linux-yocto_3.4.bb</filename> recipe to build
                 the kernel.
                 In other words, you have selected the kernel in your 
-                <filename>&lt;bsp_name&gt;.conf</filename> file by adding the following statements:
+                <filename>&lt;bsp_name&gt;.conf</filename> file by adding these types 
+                of statements:
                 <literallayout class='monospaced'>
      PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
      PREFERRED_VERSION_linux-yocto = "3.4%"
                 </literallayout>
+                <note>
+                    When the preferred provider is assumed by default, the 
+                    <filename>PREFERRED_PROVIDER</filename> statement does not appear in the 
+                    <filename>&lt;bsp_name&gt;.conf</filename> file.
+                </note>
                 You would use the <filename>linux-yocto_3.4.bbappend</filename> file to append 
                 specific BSP settings to the kernel, thus configuring the kernel for your particular BSP.
             </para>
@@ -518,17 +523,22 @@
 
      COMPATIBLE_MACHINE_crownbay = "crownbay"
      KMACHINE_crownbay  = "crownbay"
-     KBRANCH_crownbay  = "standard/default/crownbay"
+     KBRANCH_crownbay  = "standard/crownbay"
 
      COMPATIBLE_MACHINE_crownbay-noemgd = "crownbay-noemgd"
      KMACHINE_crownbay-noemgd  = "crownbay"
-     KBRANCH_crownbay-noemgd  = "standard/default/crownbay"
+     KBRANCH_crownbay-noemgd  = "standard/crownbay"
 
-     SRCREV_machine_pn-linux-yocto_crownbay ?= "48101e609711fcfe8d5e737a37a5a69f4bd57d9a"
-     SRCREV_meta_pn-linux-yocto_crownbay ?= "5b4c9dc78b5ae607173cc3ddab9bce1b5f78129b"
+     SRCREV_machine_pn-linux-yocto_crownbay ?= "449f7f520350700858f21a5554b81cc8ad23267d"
+     SRCREV_meta_pn-linux-yocto_crownbay ?= "9e3bdb7344054264b750e53fbbb6394cc1c942ac"
+     SRCREV_emgd_pn-linux-yocto_crownbay ?= "86643bdd8cbad616a161ab91f51108cf0da827bc"
 
-     SRCREV_machine_pn-linux-yocto_crownbay-noemgd ?= "48101e609711fcfe8d5e737a37a5a69f4bd57d9a"
-     SRCREV_meta_pn-linux-yocto_crownbay-noemgd ?= "5b4c9dc78b5ae607173cc3ddab9bce1b5f78129b"
+     SRCREV_machine_pn-linux-yocto_crownbay-noemgd ?= "449f7f520350700858f21a5554b81cc8ad23267d"
+     SRCREV_meta_pn-linux-yocto_crownbay-noemgd ?= "9e3bdb7344054264b750e53fbbb6394cc1c942ac"
+
+     KSRC_linux_yocto_3_4 ?= "git.yoctoproject.org/linux-yocto-3.4.git"
+     SRC_URI_crownbay = "git://git.yoctoproject.org/linux-yocto-3.4.git;protocol=git;nocheckout=1;branch=${KBRANCH},meta,emgd-1.14;name=machine,meta,emgd"
+     SRC_URI_crownbay-noemgd = "git://git.yoctoproject.org/linux-yocto-3.4.git;protocol=git;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"
                 </literallayout>
                 This append file contains statements used to support the Crown Bay BSP for both 
                 <trademark class='registered'>Intel</trademark> EMGD and the VESA graphics.
@@ -541,10 +551,11 @@
 
      COMPATIBLE_MACHINE_crownbay = "crownbay"
      KMACHINE_crownbay  = "crownbay"
-     KBRANCH_crownbay  = "standard/default/crownbay"
+     KBRANCH_crownbay  = "standard/crownbay"
 
-     SRCREV_machine_pn-linux-yocto_crownbay ?= "48101e609711fcfe8d5e737a37a5a69f4bd57d9a"
-     SRCREV_meta_pn-linux-yocto_crownbay ?= "5b4c9dc78b5ae607173cc3ddab9bce1b5f78129b"
+     SRCREV_machine_pn-linux-yocto_crownbay ?= "449f7f520350700858f21a5554b81cc8ad23267d"
+     SRCREV_meta_pn-linux-yocto_crownbay ?= "9e3bdb7344054264b750e53fbbb6394cc1c942ac"
+     SRCREV_emgd_pn-linux-yocto_crownbay ?= "86643bdd8cbad616a161ab91f51108cf0da827bc"
                 </literallayout>
                 The append file defines <filename>crownbay</filename> as the 
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-COMPATIBLE_MACHINE'><filename>COMPATIBLE_MACHINE</filename></ulink>
@@ -556,10 +567,16 @@
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-KBRANCH'><filename>KBRANCH</filename></ulink> variable
                 to ensure the build process uses the <filename>standard/default/crownbay</filename>
                 kernel branch.
-                Finally, the append file points to the specific top commits in the 
-                <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink> Git 
+                Finally, the append file points to specific commits in the 
+                <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink> Git 
                 repository and the <filename>meta</filename> Git repository branches to identify the 
                 exact kernel needed to build the Crown Bay BSP.
+                <note>
+                    For <filename>crownbay</filename>, a specific commit is also needed to point
+                    to the branch that supports EMGD graphics. 
+                    At a minimum, every BSP points to the 
+                    <filename>machine</filename> and <filename>meta</filename> commits.
+                </note>
             </para>
 
             <para>
@@ -617,13 +634,6 @@
                     <filename>meta</filename> branch for your BSP.
                     The configuration options will likely end up in that location anyway if the BSP gets 
                     added to the Yocto Project. 
-                    For an example showing how to change the BSP configuration, see the
-                    "<ulink url='&YOCTO_DOCS_DEV_URL;#changing-the-bsp-configuration'>Changing the BSP Configuration</ulink>" 
-                    section in the Yocto Project Development Manual.
-                    For a better understanding of working with a local clone of the kernel repository
-                    and a local bare clone of the kernel, see the
-                    "<ulink url='&YOCTO_DOCS_DEV_URL;#modifying-the-kernel-source-code'>Modifying the Kernel
-                    Source Code</ulink>" section also in the Yocto Project Development Manual.
                 </para>
 
                 <para>
@@ -706,7 +716,7 @@
                             <filename>recipe-*</filename> subdirectory.
                             You can find <filename>recipes.txt</filename> in the
                             <filename>meta</filename> directory of the 
-                            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>, 
+                            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>, 
                             or in the OpenEmbedded Core Layer
                             (<filename>openembedded-core</filename>) found at 
                             <ulink url='http://git.openembedded.org/openembedded-core/tree/meta'></ulink>.
@@ -714,7 +724,7 @@
                             <para>Within any particular <filename>recipes-*</filename> category, the layout
                             should match what is found in the OpenEmbedded Core
                             Git repository (<filename>openembedded-core</filename>)
-                            or the source directory (<filename>poky</filename>).
+                            or the Source Directory (<filename>poky</filename>).
                             In other words, make sure you place related files in appropriately
                             related <filename>recipes-*</filename> subdirectories specific to the
                             recipe's function, or within a subdirectory containing a set of closely-related
@@ -730,22 +740,22 @@
                             You must specify which license to use since there is no 
                             default license if one is not specified.
                             See the 
-                            <ulink url='&YOCTO_GIT_URL;/cgit.cgi/meta-intel/tree/meta-fishriver/COPYING.MIT'><filename>COPYING.MIT</filename></ulink>
-                            file for the Fish River BSP in the <filename>meta-fishriver</filename> BSP layer 
+                            <ulink url='&YOCTO_GIT_URL;/cgit.cgi/meta-intel/tree/meta-fri2/COPYING.MIT'><filename>COPYING.MIT</filename></ulink>
+                            file for the Fish River Island 2 BSP in the <filename>meta-fri2</filename> BSP layer 
                             as an example.</para></listitem>
                         <listitem><para><emphasis>README File:</emphasis>
                             You must include a <filename>README</filename> file in the 
                             <filename>meta-&lt;bsp_name&gt;</filename> directory.
                             See the 
-                            <ulink url='&YOCTO_GIT_URL;/cgit.cgi/meta-intel/tree/meta-fishriver/README'><filename>README</filename></ulink>
-                            file for the Fish River BSP in the <filename>meta-fishriver</filename> BSP layer 
+                            <ulink url='&YOCTO_GIT_URL;/cgit.cgi/meta-intel/tree/meta-fri2/README'><filename>README</filename></ulink>
+                            file for the Fish River Island 2 BSP in the <filename>meta-fri2</filename> BSP layer 
                             as an example.</para>
                             <para>At a minimum, the <filename>README</filename> file should 
                             contain the following:
                             <itemizedlist>
                                 <listitem><para>A brief description about the hardware the BSP 
                                     targets.</para></listitem>
-                                <listitem><para>A list of all the dependencies a 
+                                <listitem><para>A list of all the dependencies 
                                     on which a BSP layer depends.
                                     These dependencies are typically a list of required layers needed 
                                     to build the BSP.
@@ -778,8 +788,8 @@
                             generate the binary images contained in the 
                             <filename>/binary</filename> directory, if present.
                             See the 
-                            <ulink url='&YOCTO_GIT_URL;/cgit.cgi/meta-intel/tree/meta-fishriver/README.sources'><filename>README.sources</filename></ulink>
-                            file for the Fish River BSP in the <filename>meta-fishriver</filename> BSP layer 
+                            <ulink url='&YOCTO_GIT_URL;/cgit.cgi/meta-intel/tree/meta-fri2/README.sources'><filename>README.sources</filename></ulink>
+                            file for the Fish River Island 2 BSP in the <filename>meta-fri2</filename> BSP layer 
                             as an example.</para></listitem>
                         <listitem><para><emphasis>Layer Configuration File:</emphasis>
                             You must include a <filename>conf/layer.conf</filename> in the
@@ -793,14 +803,13 @@
                             using the BSP layer.
                             Multiple machine configuration files define variations of machine 
                             configurations that are supported by the BSP.
-                            If a BSP supports more multiple machine variations, you need to 
+                            If a BSP supports multiple machine variations, you need to 
                             adequately describe each variation in the BSP 
                             <filename>README</filename> file.
                             Do not use multiple machine configuration files to describe disparate
                             hardware. 
-                            Multiple machine configuration files should describe very similar targets.
-                            If you do have very different targets, you should create a separate
-                            BSP.
+                            If you do have very different targets, you should create separate
+                            BSP layers for each target.
                             <note>It is completely possible for a developer to structure the 
                             working repository as a conglomeration of unrelated BSP
                             files, and to possibly generate specifically targeted 'release' BSPs 
@@ -846,7 +855,7 @@
                             Basing your recipes on these kernels reduces the costs for maintaining 
                             the BSP and increases its scalability.
                             See the <filename>Yocto Linux Kernel</filename> category in the 
-                            <ulink url='&YOCTO_GIT_URL;/cgit.cgi'><filename>Yocto Source Repositories</filename></ulink>
+                            <ulink url='&YOCTO_GIT_URL;/cgit.cgi'>Source Repositories</ulink>
                             for these kernels.</para></listitem>
                     </itemizedlist>
                 </para>
@@ -1017,8 +1026,8 @@
 
             <para>
                 The following sections describe the common location and help features as well 
-                as details for the <filename>yocto-bsp</filename> and <filename>yocto-kernel</filename> 
-                tools.
+                as provide details for the 
+                <filename>yocto-bsp</filename> and <filename>yocto-kernel</filename> tools.
             </para>
 
             <section id='common-features'>
@@ -1037,7 +1046,7 @@
 
                 <para>
                     Both tools reside in the <filename>scripts/</filename> subdirectory 
-                    of the <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>.
+                    of the <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
                     Consequently, to use the scripts, you must <filename>source</filename> the 
                     environment just as you would when invoking a build:
                     <literallayout class='monospaced'>
@@ -1049,30 +1058,27 @@
                     The most immediately useful function is to get help on both tools.
                     The built-in help system makes it easy to drill down at
                     any time and view the syntax required for any specific command.
-                    Simply enter the name of the command, or the command along with 
-                    <filename>help</filename> to display a list of the available sub-commands. 
-                    Here is an example:
+                    Simply enter the name of the command with the <filename>help</filename>
+                    switch:
                     <literallayout class='monospaced'>
-     $ yocto-bsp
      $ yocto-bsp help
+     Usage: 
 
-     Usage:
+      Create a customized Yocto BSP layer.
 
-     Create a customized Yocto BSP layer.
+      usage: yocto-bsp [--version] [--help] COMMAND [ARGS]
 
-     usage: yocto-bsp [--version] [--help] COMMAND [ARGS]
+      Current 'yocto-bsp' commands are:
+         create            Create a new Yocto BSP
+         list              List available values for options and BSP properties
 
-     The most commonly used 'yocto-bsp' commands are:
-     create            Create a new Yocto BSP
-     list              List available values for options and BSP properties
-
-     See 'yocto-bsp help COMMAND' for more information on a specific command.
+      See 'yocto-bsp help COMMAND' for more information on a specific command.
 
 
      Options:
-     --version    show program's version number and exit
-     -h, --help   show this help message and exit
-     -D, --debug  output debug information
+       --version    show program's version number and exit
+       -h, --help   show this help message and exit
+       -D, --debug  output debug information
                     </literallayout>
                 </para>
 
@@ -1082,19 +1088,20 @@
                     <literallayout class='monospaced'>
      $ yocto-bsp create
 
-     Usage:
+     Usage: 
 
-     Create a new Yocto BSP
-     usage: yocto-bsp create &lt;bsp-name&gt; &lt;karch&gt; [-o &lt;DIRNAME&gt; | --outdir &lt;DIRNAME&gt;]
+      Create a new Yocto BSP
+
+      usage: yocto-bsp create &lt;bsp-name&gt; &lt;karch&gt; [-o &lt;DIRNAME&gt; | --outdir &lt;DIRNAME&gt;]
              [-i &lt;JSON PROPERTY FILE&gt; | --infile &lt;JSON PROPERTY_FILE&gt;]
 
-                 This command creates a Yocto BSP based on the specified parameters.
-                 The new BSP will be a new BSP layer contained by default within
-                 the top-level directory specified as 'meta-bsp-name'.  The -o option
-                 can be used to place the BSP layer in a directory with a different
-                 name and location.
+      This command creates a Yocto BSP based on the specified parameters.
+      The new BSP will be a new Yocto BSP layer contained by default within
+      the top-level directory specified as 'meta-bsp-name'.  The -o option
+      can be used to place the BSP layer in a directory with a different
+      name and location.
 
-                 ...
+      ...
                     </literallayout>
                 </para>
 
@@ -1105,33 +1112,26 @@
      $ yocto-bsp help create
 
      NAME
-     yocto-bsp create - Create a new Yocto BSP
+         yocto-bsp create - Create a new Yocto BSP
 
      SYNOPSIS
-     yocto-bsp create &lt;bsp-name&gt; &lt;karch&gt; [-o &lt;DIRNAME&gt; | --outdir &lt;DIRNAME&gt;]
+         yocto-bsp create &lt;bsp-name&gt; &lt;karch&gt; [-o &lt;DIRNAME&gt; | --outdir &lt;DIRNAME&gt;]
              [-i &lt;JSON PROPERTY FILE&gt; | --infile &lt;JSON PROPERTY_FILE&gt;]
 
      DESCRIPTION
-     This command creates a Yocto BSP based on the specified
-     parameters.  The new BSP will be a new Yocto BSP layer contained
-     by default within the top-level directory specified as
-     'meta-bsp-name'.  The -o option can be used to place the BSP layer
-     in a directory with a different name and location.
-			    
-     The value of the 'karch' parameter determines the set of files
-     that will be generated for the BSP, along with the specific set of
-     'properties' that will be used to fill out the BSP-specific
-     portions of the BSP.
-			    
-     ...
-			    
-     NOTE: Once created, you should add your new layer to your
-     bblayers.conf file in order for it to be subsequently seen and
-     modified by the yocto-kernel tool.
-			    
-     NOTE for x86- and x86_64-based BSPs: The generated BSP assumes the
-     presence of the of the meta-intel layer, so you should also have a
-     meta-intel layer present and added to your bblayers.conf as well.
+         This command creates a Yocto BSP based on the specified
+         parameters.  The new BSP will be a new Yocto BSP layer contained
+         by default within the top-level directory specified as
+         'meta-bsp-name'.  The -o option can be used to place the BSP layer
+         in a directory with a different name and location.
+
+         The value of the 'karch' parameter determines the set of files
+         that will be generated for the BSP, along with the specific set of
+         'properties' that will be used to fill out the BSP-specific
+         portions of the BSP.  The possible values for the 'karch' paramter
+         can be listed via 'yocto-bsp list karch'.
+
+         ...
                     </literallayout>
                 </para>
 
@@ -1158,33 +1158,33 @@
                     For the current set of BSPs, the script prompts you for various important
                     parameters such as:
                     <itemizedlist>
-                        <listitem><para>which kernel to use</para></listitem>
-                        <listitem><para>which branch of that kernel to use (or re-use)</para></listitem>
-                        <listitem><para>whether or not to use X, and if so, which drivers to use</para></listitem>
-                        <listitem><para>whether to turn on SMP</para></listitem>
-                        <listitem><para>whether the BSP has a keyboard</para></listitem>
-                        <listitem><para>whether the BSP has a touchscreen</para></listitem>
-                        <listitem><para>any remaining configurable items associated with the BSP</para></listitem>
+                        <listitem><para>The kernel to use</para></listitem>
+                        <listitem><para>The branch of that kernel to use (or re-use)</para></listitem>
+                        <listitem><para>Whether or not to use X, and if so, which drivers to use</para></listitem>
+                        <listitem><para>Whether to turn on SMP</para></listitem>
+                        <listitem><para>Whether the BSP has a keyboard</para></listitem>
+                        <listitem><para>Whether the BSP has a touchscreen</para></listitem>
+                        <listitem><para>Remaining configurable items associated with the BSP</para></listitem>
                     </itemizedlist>
                 </para>
 
                 <para>
                     You use the <filename>yocto-bsp create</filename> sub-command to create 
                     a new BSP layer. 
-                    This command requires you to specify a particular architecture on which to 
-                    base the BSP.
+                    This command requires you to specify a particular kernel architecture 
+                    (<filename>karch</filename>) on which to base the BSP.
                     Assuming you have sourced the environment, you can use the 
                     <filename>yocto-bsp list karch</filename> sub-command to list the
                     architectures available for BSP creation as follows:
                     <literallayout class='monospaced'>
      $ yocto-bsp list karch
      Architectures available:
-         arm
-         powerpc
-         i386
-         mips
-         x86_64
          qemu
+         x86_64
+         i386
+         powerpc
+         arm
+         mips
                     </literallayout>
                 </para>
 
@@ -1205,53 +1205,46 @@
                     the prompts appear in brackets.
                     Pressing enter without supplying anything on the command line or pressing enter
                     and providing an invalid response causes the script to accept the default value.
+                    Once the script completes, the new <filename>meta-myarm</filename> BSP layer
+                    is created in the current working directory. 
+                    This example assumes you have source the &OE_INIT_FILE; and are currently
+                    in the top-level folder of the 
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
                 </para>
 
                 <para>
                     Following is the complete example:
                     <literallayout class='monospaced'>
      $ yocto-bsp create myarm qemu
-     Which qemu architecture would you like to use? [default: x86]
-             1) common 32-bit x86
-             2) common 64-bit x86
-             3) common 32-bit ARM
-             4) common 32-bit PowerPC
-             5) common 32-bit MIPS
+     Which qemu architecture would you like to use? [default: i386]
+	     1) i386    (32-bit)
+	     2) x86_64  (64-bit)
+	     3) ARM     (32-bit)
+	     4) PowerPC (32-bit)
+	     5) MIPS    (32-bit)
      3
-     Would you like to use the default (3.2) kernel? (Y/n)
-     Do you need a new machine branch for this BSP (the alternative is to re-use an existing branch)? [Y/n]
-     Getting branches from remote repo git://git.yoctoproject.org/linux-yocto-3.2...
-     Please choose a machine branch to base this BSP on => [default: standard/default/common-pc]
-             1) base
+     Would you like to use the default (3.4) kernel? (y/n) [default: y]
+     Do you need a new machine branch for this BSP (the alternative is to re-use an existing branch)? [y/n] [default: y]
+     Getting branches from remote repo git://git.yoctoproject.org/linux-yocto-3.4.git...
+     Please choose a machine branch to base your new BSP branch on: [default: standard/base]
+             1) standard/arm-versatile-926ejs
              2) standard/base
-             3) standard/default/arm-versatile-926ejs
-             4) standard/default/base
-             5) standard/default/beagleboard
-             6) standard/default/cedartrailbsp (copy).xml
-             7) standard/default/common-pc-64/base
-             8) standard/default/common-pc-64/jasperforest
-             9) standard/default/common-pc-64/romley
-             10) standard/default/common-pc-64/sugarbay
-             11) standard/default/common-pc/atom-pc
-             12) standard/default/common-pc/base
-             13) standard/default/crownbay
-             14) standard/default/emenlow
-             15) standard/default/fishriver
-             16) standard/default/fri2
-             17) standard/default/fsl-mpc8315e-rdb
-             18) standard/default/mti-malta32-be
-             19) standard/default/mti-malta32-le
-             20) standard/default/preempt-rt
-             21) standard/default/qemu-ppc32
-             22) standard/default/routerstationpro
-             23) standard/preempt-rt/base
-             24) standard/preempt-rt/qemu-ppc32
-             25) standard/preempt-rt/routerstationpro
-             26) standard/tiny
-     3
-     Do you need SMP support? (Y/n)
-     Does your BSP have a touchscreen? (y/N)
-     Does your BSP have a keyboard? (Y/n)
+             3) standard/beagleboard
+             4) standard/cedartrail
+             5) standard/crownbay
+             6) standard/emenlow
+             7) standard/fishriver
+             8) standard/fri2
+             9) standard/fsl-mpc8315e-rdb
+             10) standard/mti-malta32
+             11) standard/mti-malta64
+             12) standard/qemuppc
+             13) standard/routerstationpro
+             14) standard/sys940x
+     1
+     Would you like SMP support? (y/n) [default: y]
+     Does your BSP have a touchscreen? (y/n) [default: n]
+     Does your BSP have a keyboard? (y/n) [default: y]
      New qemu BSP created in meta-myarm
                     </literallayout>
                     Let's take a closer look at the example now:
@@ -1261,10 +1254,10 @@
                             In the example, we use the <filename>arm</filename> architecture.
                             </para></listitem>
                         <listitem><para>The script then prompts you for the kernel.
-                            The default kernel is 3.2 and is acceptable.  
+                            The default 3.4 kernel is acceptable.  
                             So, the example accepts the default.
                             If you enter 'n', the script prompts you to further enter the kernel
-                            you do want to use (e.g. 3.0, 3.2_preempt-rt, etc.).</para></listitem>
+                            you do want to use (e.g. 3.0, 3.2_preempt-rt, and so forth.).</para></listitem>
                         <listitem><para>Next, the script asks whether you would like to have a new 
                             branch created especially for your BSP in the local 
                             <ulink url='&YOCTO_DOCS_DEV_URL;#local-kernel-files'>Linux Yocto Kernel</ulink> 
@@ -1277,25 +1270,20 @@
                             The reason a new branch is the default is that typically
                             new BSPs do require BSP-specific patches.
                             The tool thus assumes that most of time a new branch is required.
-                            <note>In the current implementation, creation or re-use of a branch does 
-                            not actually matter.
-                            The reason is because the generated BSPs assume that patches and 
-                            configurations live in recipe-space, which is something that can be done 
-                            with or without a dedicated branch.  
-                            Generated BSPs, however, are different.
-                            This difference becomes significant once the tool's 'publish' functionality 
-                            is implemented.</note></para></listitem>
-                        <listitem><para>Regardless of which choice is made in the previous step, 
+                            </para></listitem>
+                        <listitem><para>Regardless of which choice you make in the previous step, 
                             you are now given the opportunity to select a particular machine branch on
-                            which to base your new BSP-specific machine branch on 
+                            which to base your new BSP-specific machine branch 
                             (or to re-use if you had elected to not create a new branch).  
                             Because this example is generating an <filename>arm</filename> BSP, the example 
-                            uses <filename>#3</filename> at the prompt, which selects the arm-versatile branch.
+                            uses <filename>#1</filename> at the prompt, which selects the arm-versatile branch.
                             </para></listitem>
                         <listitem><para>The remainder of the prompts are routine. 
                             Defaults are accepted for each.</para></listitem>
                         <listitem><para>By default, the script creates the new BSP Layer in the 
-                            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>.
+                            current working directory of the 
+                            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>, 
+                            which is <filename>poky</filename> in this case.
                             </para></listitem>
                     </orderedlist> 
                 </para>
@@ -1308,6 +1296,7 @@
      BBLAYERS = " \
         /usr/local/src/yocto/meta \
         /usr/local/src/yocto/meta-yocto \
+        /usr/local/src/yocto/meta-yocto-bsp \
         /usr/local/src/yocto/meta-myarm \
         "
                     </literallayout> 
@@ -1339,21 +1328,28 @@
                     is to use the <filename>yocto-kernel</filename> built-in help as follows:
                     <literallayout class='monospaced'>
      $ yocto-kernel
-     Usage:
+     Usage: 
 
-     Modify and list Yocto BSP kernel config items and patches.
+      Modify and list Yocto BSP kernel config items and patches.
 
-     usage: yocto-kernel [--version] [--help] COMMAND [ARGS]
+      usage: yocto-kernel [--version] [--help] COMMAND [ARGS]
 
-     The most commonly used 'yocto-kernel' commands are:
-     config list       List the modifiable set of bare kernel config options for a BSP
-     config add        Add or modify bare kernel config options for a BSP 
-     config rm         Remove bare kernel config options from a BSP
-     patch list        List the patches associated with a BSP
-     patch add         Patch the Yocto kernel for a BSP
-     patch rm          Remove patches from a BSP
+      Current 'yocto-kernel' commands are:
+        config list       List the modifiable set of bare kernel config options for a BSP
+        config add        Add or modify bare kernel config options for a BSP
+        config rm         Remove bare kernel config options from a BSP
+        patch list        List the patches associated with a BSP
+        patch add         Patch the Yocto kernel for a BSP
+        patch rm          Remove patches from a BSP
 
-     See 'yocto-kernel help COMMAND' for more information on a specific command.
+      See 'yocto-kernel help COMMAND' for more information on a specific command.
+
+
+
+     Options:
+       --version    show program's version number and exit
+       -h, --help   show this help message and exit
+       -D, --debug  output debug information
                     </literallayout>
                 </para>
 

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

@@ -1,713 +0,0 @@
-<!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
-[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
-
-<appendix id='dev-manual-bsp-appendix'>
-
-<title>BSP Development Example</title>
-
-<para>
-    This appendix provides a complete BSP development example.
-    The example assumes the following:
-    <itemizedlist>
-        <listitem><para>No previous preparation or use of the Yocto Project.</para></listitem>
-        <listitem><para>Use of the Fish River Island 2 Board Support Package (BSP) as a "base" BSP from 
-            which to work.  
-            The example begins with the Fish River Island 2 BSP as the starting point
-            but ends by building a new 'atom-pc' BSP, which was based on the Fish River Island 2 BSP.
-            </para></listitem>  
-        <listitem><para>Shell commands assume <filename>bash</filename></para></listitem>
-        <listitem><para>Example was developed on an Intel-based Core i7 platform running 
-            Ubuntu 10.04 LTS released in April of 2010.</para></listitem>        
-    </itemizedlist>             
-</para>
-
-<section id='getting-local-yocto-project-files-and-bsp-files'>
-    <title>Getting Local Source Files and BSP Files</title>
-
-    <para>
-        You need to have the <link linkend='source-directory'>Source Directory</link>
-        available on your host system.  
-        You can set up this directory through tarball extraction or by cloning the 
-        <filename>poky</filename> Git repository.
-        The following paragraphs describe both methods.
-        For additional information, see the bulleted item
-        "<link linkend='local-yp-release'>Yocto Project Release</link>".
-    </para> 
-
-    <para>
-        As mentioned, one way to set up the Source Directory is to use Git to clone the 
-        <filename>poky</filename> repository. 
-        These commands create a local copy of the Git repository.
-        By default, the top-level directory of the repository is named <filename>poky</filename>:
-        <literallayout class='monospaced'>
-     $ git clone git://git.yoctoproject.org/poky
-     $ cd poky
-        </literallayout> 
-        Alternatively, you can start with the downloaded Poky "&DISTRO_NAME;" tarball.
-        These commands unpack the tarball into a Source Directory structure.
-        By default, the top-level directory of the Source Directory is named
-        <filename>&YOCTO_POKY;</filename>:
-        <literallayout class='monospaced'>
-     $ tar xfj &YOCTO_POKY_TARBALL;
-     $ cd &YOCTO_POKY;
-        </literallayout> 
-        <note><para>If you're using the tarball method, you can ignore all the following steps that
-        ask you to carry out Git operations.  
-        You already have the results of those operations
-        in the form of the &DISTRO_NAME; release tarballs.
-        Consequently, there is nothing left to do other than extract those tarballs into the 
-        proper locations.</para>
-
-        <para>Once you expand the released tarball, you have a snapshot of the Git repository
-        that represents a specific release.
-        Fundamentally, this is different than having a local copy of the Poky Git repository.  
-        Given the tarball method, changes you make are building on top of a release.
-        With the Git repository method you have the ability to track development
-        and keep changes in revision control.
-        See the 
-        "<link linkend='repositories-tags-and-branches'>Repositories, Tags, and Branches</link>" section
-        for more discussion around these differences.</para></note>
-    </para>
-
-    <para>
-        With the local <filename>poky</filename> Git repository set up, 
-        you have all the development branches available to you from which you can work. 
-        Next, you need to be sure that your local repository reflects the exact
-        release in which you are interested.
-        From inside the repository you can see the development branches that represent
-        areas of development that have diverged from the main (master) branch
-        at some point, such as a branch to track a maintenance release's development.  
-        You can also see the tag names used to mark snapshots of stable releases or 
-        points in the repository.
-        Use the following commands to list out the branches and the tags in the repository, 
-        respectively.
-        <literallayout class='monospaced'>
-     $ git branch -a
-     $ git tag -l
-        </literallayout> 
-        For this example, we are going to use the Yocto Project &DISTRO; Release, which is code
-        named "&DISTRO_NAME;". 
-        To make sure we have a local area (branch in Git terms) on our machine that 
-        reflects the &DISTRO; release, we can use the following commands:
-        <literallayout class='monospaced'>
-     $ cd ~/poky
-     $ git fetch --tags
-     $ git checkout -b &DISTRO_NAME;-&POKYVERSION; origin/&DISTRO_NAME;
-     Switched to a new branch '&DISTRO_NAME;-&POKYVERSION;'
-        </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;-&POKYVERSION;</filename>.
-        Your local branch begins in the same state as the Yocto Project &DISTRO; released tarball 
-        marked with the <filename>&DISTRO_NAME;-&POKYVERSION;</filename> tag in the source repositories.
-    </para>
-</section> 
-
-<section id='choosing-a-base-bsp-app'>
-    <title>Choosing a Base BSP</title>
-
-    <para>
-        For this example, the base BSP is the <trademark class='registered'>Intel</trademark>
-        <trademark class='trade'>Atom</trademark> Processor E660 with Intel Platform 
-        Controller Hub EG20T Development Kit, which is otherwise referred to as "Fish River Island 2."
-        The BSP layer is <filename>meta-fri2</filename>.  
-        The base BSP is simply the BSP
-        we will be using as a starting point, so don't worry if you don't actually have Fish River Island 2
-        hardware.
-        The remainder of the example transforms the base BSP into a BSP that should be
-        able to boot on generic atom-pc (netbook) hardware.
-    </para>
-
-    <para>
-        For information on how to choose a base BSP, see
-        "<link linkend='developing-a-board-support-package-bsp'>Developing a Board Support Package (BSP)</link>".
-    </para>
-</section>
-
-<section id='getting-your-base-bsp-app'>
-    <title>Getting Your Base BSP</title>
-
-    <para>
-        You need to have the base BSP layer on your development system.  
-        Similar to the local <link linkend='source-directory'>Source Directory</link>, 
-        you can get the BSP 
-        layer in a couple of different ways:  
-        download the BSP tarball and extract it, or set up a local Git repository that 
-        has the BSP layers.  
-        You should use the same method that you used to set up the Source Directory earlier.
-        See "<link linkend='getting-setup'>Getting Setup</link>" for information on how to get 
-        the BSP files.
-    </para>
-
-    <para>
-        This example assumes the BSP layer will be located within a directory named
-        <filename>meta-intel</filename> contained within the <filename>poky</filename>
-        parent directory.  
-        The following steps will automatically create the
-        <filename>meta-intel</filename> directory and the contained 
-        <filename>meta-fri2</filename> starting point in both the Git and the tarball cases.
-    </para>
-
-    <para>
-        If you're using the Git method, you could do the following to create
-        the starting layout after you have made sure you are in the <filename>poky</filename>
-        directory created in the previous steps:
-        <literallayout class='monospaced'>
-     $ git clone git://git.yoctoproject.org/meta-intel.git
-     $ cd meta-intel
-        </literallayout> 
-        Alternatively, you can start with the downloaded Fish River Island 2 tarball.
-        You can download the &DISTRO_NAME; version of the BSP tarball from the
-        <ulink url='&YOCTO_HOME_URL;/download'>Downloads</ulink> page of the 
-        Yocto Project website. 
-        Here is the specific link for the tarball needed for this example:
-        <ulink url='&YOCTO_MACHINES_DL_URL;/fri2-noemgd/fri2-noemgd-&DISTRO_NAME;-&POKYVERSION;.tar.bz2'></ulink>.
-        Again, be sure that you are already in the <filename>poky</filename> directory
-        as described previously before installing the tarball:
-        <literallayout class='monospaced'>
-     $ tar xfj fri2-noemgd-&DISTRO_NAME;-&POKYVERSION;.tar.bz2
-     $ cd meta-intel
-        </literallayout> 
-    </para>
-        
-    <para>
-        The <filename>meta-intel</filename> directory contains all the metadata 
-        that supports BSP creation.  
-        If you're using the Git method, the following
-        step will switch to the &DISTRO_NAME; metadata.
-        If you're using the tarball method, you already have the correct metadata and can 
-        skip to the next step.
-        Because <filename>meta-intel</filename> is its own Git repository, you will want
-        to be sure you are in the appropriate branch for your work.
-        For this example we are going to use the <filename>&DISTRO_NAME;</filename> 
-        branch. 
-        <literallayout class='monospaced'>
-     $ git checkout -b &DISTRO_NAME;-&POKYVERSION; origin/&DISTRO_NAME;
-     Branch &DISTRO_NAME;-&POKYVERSION; set up to track remote branch &DISTRO_NAME; from origin.
-     Switched to a new branch '&DISTRO_NAME;-&POKYVERSION;'
-        </literallayout>
-    </para>
-</section>
-
-<section id='making-a-copy-of-the-base bsp-to-create-your-new-bsp-layer-app'>
-    <title>Making a Copy of the Base BSP to Create Your New BSP Layer</title>
-
-    <para>
-        Now that you have set up the Source Directory and included the base BSP files, you need to 
-        create a new layer for your BSP.
-        To create your BSP layer, you simply copy the <filename>meta-fri2</filename>
-        layer to a new layer.
-    </para>
-
-    <para>  
-        For this example, the new layer will be named <filename>meta-mymachine</filename>.  
-        The name should follow the BSP layer naming convention, which is 
-        <filename>meta-&lt;name&gt;</filename>.  
-        The following assumes your working directory is <filename>meta-intel</filename> 
-        inside your Source Directory.  
-        To start your new layer, just copy the new layer alongside the existing
-        BSP layers in the <filename>meta-intel</filename> directory:
-        <literallayout class='monospaced'>
-     $ cp -a meta-fri2/ meta-mymachine 
-        </literallayout>
-    </para>
-</section>
-
-<section id='making-changes-to-your-bsp-app'>
-    <title>Making Changes to Your BSP</title>
-
-    <para>
-        Right now you have two identical BSP layers with different names:  
-        <filename>meta-fri2</filename> and <filename>meta-mymachine</filename>.  
-        You need to change your configurations so that they work for your new BSP and 
-        your particular hardware.
-        The following sections look at each of these areas of the BSP.
-    </para>
-
-    <section id='changing-the-bsp-configuration'>
-        <title>Changing the BSP Configuration</title>
-   
-        <para>  
-            We will look first at the configurations, which are all done in the layer’s 
-            <filename>conf</filename> directory.
-        </para>
-
-        <para>
-            First, since in this example the new BSP will not support EMGD, we will get rid of the 
-            <filename>fri2.conf</filename> file and then rename the 
-            <filename>fri2-noemgd.conf</filename> file to <filename>mymachine.conf</filename>.  
-            Much of what we do in the configuration directory is designed to help the OpenEmbedded 
-            build system work with the new layer and to be able to find and use the right software.  
-            The following two commands result in a single machine configuration file named 
-            <filename>mymachine.conf</filename>.  
-            <literallayout class='monospaced'>
-     $ rm meta-mymachine/conf/machine/fri2.conf
-     $ mv meta-mymachine/conf/machine/fri2-noemgd.conf \
-     meta-mymachine/conf/machine/mymachine.conf
-            </literallayout>
-        </para>
-
-        <para>
-            Next, we need to make changes to the <filename>mymachine.conf</filename> itself.
-            The only changes we want to make for this example are to the comment lines.  
-            Changing comments, of course, is never strictly necessary, but it's always good form to make
-            them reflect reality as much as possible.
-
-            Here, simply substitute the Fish River Island 2 name with an appropriate name for the BSP 
-            (<filename>mymachine</filename> in this case) and change the description to 
-            something that describes your hardware.
-        </para>
-
-        <para>
-            Note that inside the <filename>mymachine.conf</filename> is the 
-            <filename>PREFERRED_VERSION_linux-yocto</filename> statement. 
-            This statement identifies the kernel that the BSP is going to use.
-            In this case, the BSP is using <filename>linux-yocto</filename>, which is the 
-            current Yocto Project kernel based on the Linux 3.4 release. 
-        </para>
-
-        <para>
-            The next configuration file in the new BSP layer we need to edit is
-            <filename>meta-mymachine/conf/layer.conf</filename>.
-            This file identifies build information needed for the new layer.  
-            You can see the 
-            "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-filelayout-layer'>Layer Configuration File</ulink>" section
-            in The Board Support Packages (BSP) Development Guide for more information on this configuration file.  
-            Basically, we are changing the existing statements to work with our BSP. 
-        </para>
-
-        <para>
-            The file contains these statements that reference the Fish River Island 2 BSP:
-            <literallayout class='monospaced'>
-     BBFILE_COLLECTIONS += "fri2"
-     BBFILE_PATTERN_fri2 := "^${LAYERDIR}/"
-     BBFILE_PRIORITY_fri2 = "6"
-
-     LAYERDEPENDS_fri2 = "intel"
-            </literallayout>
-        </para>
-
-        <para>
-            Simply substitute the machine string name <filename>fri2</filename>
-            with the new machine name <filename>mymachine</filename> to get the following:
-            <literallayout class='monospaced'>
-     BBFILE_COLLECTIONS += "mymachine"
-     BBFILE_PATTERN_mymachine := "^${LAYERDIR}/"
-     BBFILE_PRIORITY_mymachine = "6"
-
-     LAYERDEPENDS_mymachine = "intel"
-            </literallayout>
-        </para>
-    </section>
-
-    <section id='changing-the-recipes-in-your-bsp'>
-        <title>Changing the Recipes in Your BSP</title>
-
-        <para>
-            Now we will take a look at the recipes in your new layer.  
-            The standard BSP structure has areas for BSP, graphics, core, and kernel recipes.  
-            When you create a BSP, you use these areas for appropriate recipes and append files.  
-            Recipes take the form of <filename>.bb</filename> files, while append files take
-            the form of <filename>.bbappend</filename> files.  
-            If you want to leverage the existing recipes the OpenEmbedded build system uses
-            but change those recipes, you can use <filename>.bbappend</filename> files.  
-            All new recipes and append files for your layer must go in the layer’s 
-            <filename>recipes-bsp</filename>, <filename>recipes-kernel</filename>, 
-            <filename>recipes-core</filename>, and 
-            <filename>recipes-graphics</filename> directories.    
-        </para>
-
-        <section id='changing-recipes-bsp'>
-            <title>Changing&nbsp;&nbsp;<filename>recipes-bsp</filename></title>
-
-            <para>
-                First, let's look at <filename>recipes-bsp</filename>.
-                For this example we are not adding any new BSP recipes.  
-                And, we only need to remove the formfactor we do not want and change the name of 
-                the remaining one that doesn't support EMGD.  
-                These commands take care of the <filename>recipes-bsp</filename> recipes:
-                <literallayout class='monospaced'>
-     $ rm -rf meta-mymachine/recipes-bsp/formfactor/formfactor/fri2
-     $ mv meta-mymachine/recipes-bsp/formfactor/formfactor/fri2-noemgd/ \
-     meta-mymachine/recipes-bsp/formfactor/formfactor/mymachine
-                </literallayout>
-            </para>
-        </section>
-
-        <section id='changing-recipes-graphics'>
-            <title>Changing&nbsp;&nbsp;<filename>recipes-graphics</filename></title>
-
-            <para>
-                Now let's look at <filename>recipes-graphics</filename>.
-                For this example we want to remove anything that supports EMGD and 
-                be sure to rename remaining directories appropriately.  
-                The following commands clean up the <filename>recipes-graphics</filename> directory:
-                <literallayout class='monospaced'>
-     $ rm -rf meta-mymachine/recipes-graphics/xorg-xserver/xserver-xf86-config/fri2
-     $ mv meta-mymachine/recipes-graphics/xorg-xserver/xserver-xf86-config/fri2-noemgd \
-        meta-mymachine/recipes-graphics/xorg-xserver/xserver-xf86-config/mymachine   
-                </literallayout>
-            </para>
-
-            <para>
-                At this point the <filename>recipes-graphics</filename> directory just has files that 
-                support Video Electronics Standards Association (VESA) graphics modes and not EMGD.  
-            </para>
-        </section>
-
-        <section id='changing-recipes-kernel'>
-            <title>Changing&nbsp;&nbsp;<filename>recipes-kernel</filename></title>
-
-            <para>
-                Finally, let's look at <filename>recipes-kernel</filename> changes.
-                Recall that the BSP uses the <filename>linux-yocto</filename> kernel as determined
-                earlier in the <filename>mymachine.conf</filename>.
-                The recipe for that kernel is not located in the  
-                BSP layer but rather in the Source Directory at 
-                <filename>meta/recipes-kernel/linux</filename> and is 
-                named <filename>linux-yocto_3.4.bb</filename>.
-                The <filename>SRCREV_machine</filename> and <filename>SRCREV_meta</filename>
-                statements point to the exact commits used by the Yocto Project development team
-                in their source repositories that identify the right kernel for our hardware.
-                In other words, the <filename>SRCREV</filename> values are simply Git commit 
-                IDs that identify which commit on each
-                of the kernel branches (machine and meta) will be checked out and used to build
-                the kernel.
-            </para>
- 
-            <para>
-                However, in the <filename>meta-mymachine</filename> layer in 
-                <filename>recipes-kernel/linux</filename> resides a <filename>.bbappend</filename>
-                file named <filename>linux-yocto_3.4.bbappend</filename> that 
-                appends the information to the recipe of the same name 
-                that is found in <filename>meta/recipes-kernel/linux</filename>.
-                Thus, the <filename>SRCREV</filename> statements in our 
-                <filename>mymachine</filename> append file override
-                the more general statements found in the more general recipe.
-            </para>
-
-            <para>
-                The <filename>SRCREV</filename> statements in the 
-                <filename>mymachine</filename> append file currently identify
-                the kernel that supports the Fish River Island 2 BSP with and without EMGD support.
-                Here are the statements:
-                <note>The commit ID strings used in this manual might not match the actual commit
-                    ID strings found in the <filename>linux-yocto_3.4.bbappend</filename> file.
-                    For the example, this difference does not matter.</note> 
-                <literallayout class='monospaced'>
-     SRCREV_machine_pn-linux-yocto_fri2 ?= \
-        "59c3ff750831338d05ab67d5efd7fc101c451aff"
-     #SRCREV_meta_pn-linux-yocto_fri2 ?= \
-        "c5bddf8ea379406ffec550528e17b777a0eba24b"
-
-     SRCREV_machine_pn-linux-yocto_fri2-noemgd ?= \
-        "59c3ff750831338d05ab67d5efd7fc101c451aff"
-     #SRCREV_meta_pn-linux-yocto_fir2-noemgd ?= \
-        "c5bddf8ea379406ffec550528e17b777a0eba24b"
-                </literallayout>
-                <note>The <filename>SRCREV_meta_pn-linux-yocto_fir2-noemgd</filename>
-                   statements in the <filename>mymachine</filename> append file, 
-                   which originated from the Fish River Island 2 BSP, are 
-                   commented out.
-                   The reason they are not used is because the commit IDs are identical to 
-                   those in the general <filename>linux-yocto_3.4.bbappend</filename> recipe, 
-                   which is found in <filename>meta/recipes-kernel/linux</filename>.
-                   </note>
-            </para>
-
-            <para>
-                You will notice that there are two pairs of <filename>SRCREV</filename> statements.  
-                The top pair identifies the kernel that supports
-                EMGD, which we don’t care about in this example.  
-                The bottom pair identifies the kernel that we will use:  
-                <filename>linux-yocto</filename>.  
-                At this point though, the unique commit strings all are still associated with 
-                Fish River Island 2 and not <filename>meta-mymachine</filename>.
-            </para>
-
-            <para>  
-                To fix this situation in <filename>linux-yocto_3.4.bbappend</filename>
-                for <filename>mymachine</filename>,
-                we delete the two <filename>SRCREV</filename> statements that support 
-                EMGD (the top pair).
-                We also change the remaining pair to specify <filename>mymachine</filename>
-                and insert the commit identifiers to identify the kernel in which we 
-                are interested, which will be based on the <filename>atom-pc-standard</filename>
-                kernel.
-                In this case, because we're working with the &DISTRO_NAME; branch of everything, we
-                need to use the <filename>SRCREV</filename> values for the atom-pc branch
-                that are associated with the &DISTRO_NAME; release. 
-            </para>
-
-            <para> 
-                To find the machine value, we need to find the <filename>SRCREV</filename>
-                value that &DISTRO_NAME; uses for the atom-pc branch, which we find in the
-                <filename>poky/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_3.4.bbappend</filename>
-                file.
-                The machine <filename>SRCREV</filename> we want is in the 
-                <filename>SRCREV_machine_atom-pc</filename> variable.
-            </para>
-
-            <para>  
-                The meta <filename>SRCREV</filename> isn't specified in this file, so if you    
-                needed it, you would find it in the base kernel recipe in the
-                <filename>poky/meta/recipes-kernel/linux/linux-yocto_3.4.bb</filename>.
-                Recall that for this example the commit ID's for the <filename>SRCREV</filename>
-                meta statements are identical and do not have to be used in the 
-                <filename>mymachine</filename> append file.
-            </para>
-
-            <para>  
-                Here are the final <filename>SRCREV</filename> statements for the 
-                <filename>mymachine</filename> append file:
-                <literallayout class='monospaced'>
-     SRCREV_machine_pn-linux-yocto_mymachine ?= \
-        "0985844fa6235422c67ef269952fa4e765f252f9"
-     #SRCREV_meta_pn-linux-yocto_mymachine ?= \
-        "c5bddf8ea379406ffec550528e17b777a0eba24b"
-                </literallayout>
-            </para>
-
-            <para>
-                In this example, we're using the <filename>SRCREV</filename> values we 
-                found already captured in the &DISTRO_NAME; release because we're creating a BSP based on 
-                &DISTRO_NAME;.  
-                If, instead, we had based our BSP on the master branches, we would want to use 
-                the most recent <filename>SRCREV</filename> values taken directly from the kernel's
-                repository.
-                We will not be doing that for this example.
-                However, if you do base a future BSP on master and
-                if you are familiar with Git repositories, you probably won’t have trouble locating the 
-                exact commit strings in the Yocto Project source repositories you need to change 
-                the <filename>SRCREV</filename> statements.  
-                You can find all the <filename>machine</filename> and <filename>meta</filename> 
-                branch points (commits) for the <filename>linux-yocto-3.4</filename> kernel at
-                <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/linux-yocto-3.4'></ulink>.  
-            </para>
-
-            <para>
-                If you need a little more assistance after going to the link then do the following:
-                <orderedlist>
-                    <listitem><para>Expand the list of branches by clicking <filename>[…]</filename></para></listitem>
-                    <listitem><para>Click on the <filename>standard/default/common-pc/atom-pc</filename> 
-                        branch</para></listitem>
-                    <listitem><para>Click on the commit column header to view the top commit</para></listitem>
-                    <listitem><para>Copy the commit string for use in the 
-                        <filename>linux-yocto_3.4.bbappend</filename> file</para></listitem>
-                </orderedlist>
-            </para>
-
-            <para>
-                For the <filename>SRCREV</filename> statement that points to the <filename>meta</filename>
-                branch use the same procedure except expand the <filename>meta</filename>
-                branch in step 2 above.
-            </para>
-
-            <para>
-                Also in the <filename>linux-yocto_3.4.bbappend</filename> file are 
-                <ulink url='&YOCTO_DOCS_REF_URL;#var-COMPATIBLE_MACHINE'><filename>COMPATIBLE_MACHINE</filename></ulink>, 
-                <ulink url='&YOCTO_DOCS_REF_URL;#var-KMACHINE'><filename>KMACHINE</filename></ulink>, 
-                and 
-                <ulink url='&YOCTO_DOCS_REF_URL;#var-KBRANCH'><filename>KBRANCH</filename></ulink> statements.  
-                Two sets of these exist: one set supports EMGD and one set does not.
-                Because we are not interested in supporting EMGD those three can be deleted.
-                The remaining three must be changed so that <filename>mymachine</filename> replaces
-                <filename>fri2-noemgd</filename> and <filename>fri2</filename>.
-            </para>
-
-            <para>
-                Because we are using the <filename>atom-pc</filename> branch for this new BSP, we can also find
-                the exact branch we need for the <filename>KMACHINE</filename>  
-                and <filename>KBRANCH</filename> variables in our new BSP from the value
-                we find in the
-                <filename>poky/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_3.4.bbappend</filename>
-                file we looked at in a previous step.  
-                In this case, the values we want are in the <filename>KMACHINE_atom-pc</filename> variable
-                and the <filename>KBRANCH_atom-pc</filename> variables in that file.
-                Here is the final <filename>linux-yocto_3.4.bbappend</filename> file after all 
-                the edits:
-                <literallayout class='monospaced'>
-     FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
-
-     COMPATIBLE_MACHINE_mymachine = "mymachine"
-     KMACHINE_mymachine  = "atom-pc"
-     KBRANCH_mymachine  = "standard/default/common-pc/atom-pc"
-
-     SRCREV_machine_pn-linux-yocto_mymachine ?= \
-        "f29531a41df15d74be5ad47d958e4117ca9e489e"
-     SRCREV_meta_pn-linux-yocto_mymachine ?= \
-        "b14a08f5c7b469a5077c10942f4e1aec171faa9d"
-                </literallayout>
-            </para>
-        </section>
-    </section>
-
-    <section id='bsp-recipe-change-summary'>
-        <title>BSP Recipe Change Summary</title>
-
-        <para>
-            In summary, the edits to the layer’s recipe files result in removal of any files and 
-            statements that do not support your targeted hardware in addition to the inclusion 
-            of any new recipes you might need.  
-            In this example, it was simply a matter of ridding the new layer 
-            <filename>meta-mymachine</filename> of any code that supported the EMGD features
-            and making sure we were identifying the kernel that supports our example, which
-            is the <filename>atom-pc-standard</filename> kernel.  
-            We did not introduce any new recipes to the layer. 
-        </para>
-
-        <para>
-            Finally, it is also important to update the layer’s <filename>README</filename>
-            file so that the information in it reflects your BSP.
-        </para>
-    </section>
-</section>
-
-<section id='preparing-for-the-build-app'>
-    <title>Preparing for the Build</title>
-
-    <para>
-        To get ready to build your image that uses the new layer you need to do the following:
-        <orderedlist>
-            <listitem><para>Get the environment ready for the build by sourcing the environment 
-                script. 
-                The environment script is in the top-level of the Source Directory.
-                The script has the string 
-                <filename>init-build-env</filename> in the file’s name.  
-                For this example, the following command gets the build environment ready:                       
-                <literallayout class='monospaced'>
-     $ source oe-init-build-env yocto-build
-                </literallayout>
-                When you source the script, a build directory is created in the current 
-                working directory.  
-                In our example we were in the <filename>poky</filename> directory.  
-                Thus, entering the previous command created the <filename>yocto-build</filename> directory.  
-                If you do not provide a name for the build directory it defaults to 
-                <filename>build</filename>.  
-                The <filename>yocto-build</filename> directory contains a
-                <filename>conf</filename> directory that has 
-                two configuration files you will need to check:  <filename>bblayers.conf</filename>
-                and <filename>local.conf</filename>.</para></listitem>
-            <listitem><para>Check and edit the resulting <filename>local.conf</filename> file.
-                This file minimally identifies the machine for which to build the image by 
-                configuring the <filename>MACHINE</filename> variable.  
-                For this example you must set the variable to mymachine as follows:
-                <literallayout class='monospaced'>
-     MACHINE ??= “mymachine”
-                </literallayout>
-                You should also be sure any other variables in which you are interested are set.  
-                Some variables to consider are <filename>BB_NUMBER_THREADS</filename>
-                and <filename>PARALLEL_MAKE</filename>, both of which can greatly reduce your build time 
-                if your development system supports multiple cores.
-                For development systems that support multiple cores, a good rule of thumb is to set 
-                both the <filename>BB_NUMBER_THREADS</filename> and <filename>PARALLEL_MAKE</filename> 
-                variables to twice the number of cores your system supports.</para></listitem>
-            <listitem><para>Update the <filename>bblayers.conf</filename> file so that it includes 
-                both the path to your new BSP layer and the path to the 
-                <filename>meta-intel</filename> layer.  
-                In this example, you need to include both these paths as part of the 
-                <filename>BBLAYERS</filename> variable:
-                <literallayout class='monospaced'>
-     $HOME/poky/meta-intel
-     $HOME/poky/meta-intel/meta-mymachine
-                </literallayout></para></listitem>
-        </orderedlist>
-    </para>
-
-    <para>
-        The  
-        <ulink url='&YOCTO_DOCS_REF_URL;#ref-variables-glos'>Variables Glossary</ulink> chapter in the 
-        Yocto Project Reference Manual has more information on configuration variables.
-    </para>
-</section>
-
-<section id='building-the-image-app'>
-    <title>Building and Booting the Image</title>
-
-    <para>
-        To build the image for our <filename>meta-mymachine</filename> BSP enter the following command 
-        from the same shell from which you ran the setup script.  
-        You should run the <filename>bitbake</filename> command without any intervening shell commands.  
-        For example, moving your working directory around could cause problems.  
-        Here is the command for this example:
-        <literallayout class='monospaced'>
-     $ bitbake -k core-image-sato
-        </literallayout>
-    </para>
-
-    <para>
-        This command specifies an image that has Sato support and that can be run from a USB device or 
-        from a CD without having to first install anything.  
-        The build process takes significant time and includes thousands of tasks, which are reported 
-        at the console.  
-        If the build results in any type of error you should check for misspellings in the 
-        files you changed or problems with your host development environment such as missing packages.
-    </para>
-
-    <para>
-        Finally, once you have an image, you can try booting it from a device
-        (e.g. a USB device).
-        To prepare a bootable USB device, insert a USB flash drive into your build system and
-        copy the <filename>.hddimg</filename> file, located in the 
-        <filename>poky/build/tmp/deploy/images</filename>
-        directory after a successful build to the flash drive.  
-        Assuming the USB flash drive takes device <filename>/dev/sdf</filename>, 
-        use <filename>dd</filename> to copy the live image to it.  
-        For example:
-        <literallayout class='monospaced'>
-     # dd if=core-image-sato-mymachine-20111101223904.hddimg of=/dev/sdf
-     # sync
-     # eject /dev/sdf
-        </literallayout>
-        You should now have a bootable USB flash device.  
-    </para>
-
-    <para>
-        Insert the device
-        into a bootable USB socket on the target, and power it on.  
-        The system should boot to the Sato graphical desktop.
-        <footnote><para>Because 
-            this new image is not in any way tailored to the system you're
-            booting it on, which is assumed to be some sort of atom-pc (netbook) system for this
-            example, it might not be completely functional though it should at least boot to a text
-            prompt.  
-            Specifically, it might fail to boot into graphics without some tweaking.  
-            If this ends up being the case, a possible next step would be to replace the 
-            <filename>mymachine.conf</filename>
-            contents with the contents of <filename>atom-pc.conf</filename> and replace 
-            <filename>xorg.conf</filename> with <filename>atom-pc xorg.conf</filename>
-            in <filename>meta-yocto</filename> and see if it fares any better.  
-            In any case, following the previous steps will give you a buildable image that 
-            will probably boot on most systems.
-            Getting things working like you want
-            them to for your hardware will normally require some amount of experimentation with
-            configuration settings.</para></footnote> 
-    </para>
-
-    <para>
-        For reference, the sato image produced by the previous steps for &DISTRO_NAME; 
-        should look like the following in terms of size.
-        If your sato image is much different from this,
-        you probably made a mistake in one of the above steps:
-        <literallayout class='monospaced'>
-     260538368 2012-04-27 01:44 core-image-sato-mymachine-20120427025051.hddimg
-        </literallayout>
-        <note>The previous instructions are also present in the README that was copied
-        from meta-fri2, which should also be updated to reflect the specifics of your
-        new BSP.  
-        That file and the <filename>README.hardware</filename> file in the top-level 
-        <filename>poky</filename> directory
-        also provides some suggestions for things to try if booting fails and produces
-        strange error messages.</note>
-    </para>
-</section>
-</appendix>
-
-
-<!--
-vim: expandtab tw=80 ts=4
--->

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

@@ -46,10 +46,10 @@
             <title>Layers</title>
 
             <para>
-                The source directory contains several layers right out of the box.
-                You can easily identify a layer in the source directory by its folder name.
+                The Source Directory contains several layers right out of the box.
+                You can easily identify a layer in the Source Directory by its folder name.
                 Folders that are layers begin with the string <filename>meta</filename>.
-                For example, when you set up the <link linkend='source-directory'>source directory</link>
+                For example, when you set up the <link linkend='source-directory'>Source Directory</link>
                 structure, you will see several layers: <filename>meta</filename>, 
                 <filename>meta-hob</filename>, <filename>meta-skeleton</filename>, 
                 <filename>meta-yocto</filename>, and <filename>meta-yocto-bsp</filename>.
@@ -173,15 +173,15 @@
                         deficiency in the include file in the layer to which it originally belongs.
                         If this is the case, you need to address that deficiency instead of overlaying
                         the include file.
-                        For example, consider how Qt 4 database support plugins are configured.
-                        The source directory does not have 
+                        For example, consider how Qt 4 database support plug-ins are configured.
+                        The Source Directory does not have 
                         MySQL or PostgreSQL, however OpenEmbedded's
                         layer <filename>meta-oe</filename> does.
                         Consequently, <filename>meta-oe</filename> uses <filename>.bbappend</filename>
                         files to modify the <filename>QT_SQL_DRIVER_FLAGS</filename> variable to enable 
                         the appropriate plugins. 
                         This variable was added to the <filename>qt4.inc</filename> include file in 
-                        the source directory specifically to allow the <filename>meta-oe</filename> layer
+                        the Source Directory specifically to allow the <filename>meta-oe</filename> layer
                         to be able to control which plugins are built.</para></listitem>
                 </itemizedlist> 
             </para>
@@ -193,9 +193,9 @@
                         <filename>meta-&lt;layer_name&gt;</filename> format.</para></listitem>
                     <listitem><para>Clone the repository alongside other <filename>meta</filename>
                         directories in the 
-                        <link linkend='source-directory'>source directory</link>.</para></listitem>
+                        <link linkend='source-directory'>Source Directory</link>.</para></listitem>
                  </itemizedlist>
-                 Following these recommendations keeps your source directory and 
+                 Following these recommendations keeps your Source Directory and 
                  its configuration entirely inside the Yocto Project's core base.
             </para>
         </section>
@@ -208,17 +208,20 @@
                 To enable your layer, simply add your layer's path to the 
                 <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-BBLAYERS'>BBLAYERS</ulink></filename> 
                 variable in your <filename>conf/bblayers.conf</filename> file, which is found in the 
-                <link linkend='build-directory'>build directory</link>. 
+                <link linkend='build-directory'>Build Directory</link>. 
                 The following example shows how to enable a layer named <filename>meta-mylayer</filename>:
                 <literallayout class='monospaced'>
-     LCONF_VERSION = "1"
+     LCONF_VERSION = "6"
 
+     BBPATH = "${TOPDIR}"
      BBFILES ?= ""
-     BBLAYERS = " \
+
+     BBLAYERS ?= " \
        /path/to/poky/meta \
        /path/to/poky/meta-yocto \
+       /path/to/poky/meta-yocto-bsp \
        /path/to/poky/meta-mylayer \
-       "
+       "                
                 </literallayout>
             </para>
 
@@ -229,6 +232,14 @@
                 During the processing of each <filename>conf/layer.conf</filename> file, BitBake adds the 
                 recipes, classes and configurations contained within the particular layer to the source
                 directory.
+                <note>
+                    Removing the <filename>meta-yocto</filename> layer exposes a bug for the 
+                    current release of the Yocto Project.
+                    If for some reason you do remove this layer from the 
+                    <filename>bblayers.conf</filename>, you must set the 
+                    <filename>LCONF_VERSION</filename> variable to "5".
+                    See <ulink url='https://bugzilla.yoctoproject.org/show_bug.cgi?id=3176'>[YOCTO_#3176]</ulink>
+                    for more information.</note>
             </para>
         </section>
 
@@ -272,7 +283,7 @@
             <para>
                 As an example, consider the main formfactor recipe and a corresponding formfactor 
                 append file both from the 
-                <link linkend='source-directory'>source directory</link>.
+                <link linkend='source-directory'>Source Directory</link>.
                 Here is the main formfactor recipe, which is named <filename>formfactor_0.0.bb</filename> and  
                 located in the meta layer at <filename>meta/recipes-bsp/formfactor</filename>:
                 <literallayout class='monospaced'>
@@ -304,7 +315,7 @@
                 <literallayout class='monospaced'>
      FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
  
-     PRINC = "1"
+     PRINC := "${@int(PRINC) + 2}"
                 </literallayout>
                 This example adds or overrides files in 
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
@@ -327,12 +338,6 @@
                     paths in the final list.
                 </note>
             </para>
-
-            <para>
-                For another example on how to use a <filename>.bbappend</filename> file, see the 
-                "<link linkend='changing-recipes-kernel'>Changing <filename>recipes-kernel</filename></link>"
-                section.
-            </para>
         </section>
 
         <section id='prioritizing-your-layer'>
@@ -575,8 +580,8 @@
                 with specialized image <filename>.bb</filename> files.
                 You can also add more features by configuring the 
                 <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-EXTRA_IMAGE_FEATURES'>EXTRA_IMAGE_FEATURES</ulink></filename>
-                variable in the <filename>local.conf</filename> file found in the source directory
-                located in the build directory.
+                variable in the <filename>local.conf</filename> file found in the Source Directory
+                located in the Build Directory.
             </para>
 
             <para>
@@ -1025,8 +1030,8 @@
         <para>
             For a complete example that shows how to add a new machine, 
             see the 
-            "<ulink url='&YOCTO_DOCS_DEV_URL;#dev-manual-bsp-appendix'>BSP Development Example</ulink>" 
-            in Appendix A.
+            "<ulink url='&YOCTO_DOCS_BSP_URL;#creating-a-new-bsp-layer-using-the-yocto-bsp-script'>Creating a New BSP Layer Using the yocto-bsp Script</ulink>" 
+            in the Yocto Project Board Support Package (BSP) Developer's Guide.
         </para>
 
         <section id="platdev-newmachine-conffile">
@@ -1078,7 +1083,7 @@
                 You need to either create a new kernel recipe for this machine, or extend an 
                 existing recipe. 
                 You can find several kernel examples in the 
-                source directory at <filename>meta/recipes-kernel/linux</filename>
+                Source Directory at <filename>meta/recipes-kernel/linux</filename>
                 that you can use as references.
             </para>
 
@@ -1201,7 +1206,7 @@
                 extended to support multiple libraries. 
                 Many standard recipes are already extended and support multiple libraries.
                 You can check in the <filename>meta/conf/multilib.conf</filename>
-                configuration file in the source directory to see how this is 
+                configuration file in the Source Directory to see how this is 
                 done using the 
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-BBCLASSEXTEND'><filename>BBCLASSEXTEND</filename></ulink>
                 variable.
@@ -1235,7 +1240,7 @@
                 combination of multiple libraries you want to build. 
                 You accomplish this through your <filename>local.conf</filename>
                 configuration file in the 
-                <link linkend='build-directory'>build directory</link>. 
+                <link linkend='build-directory'>Build Directory</link>. 
                 An example configuration would be as follows:
                 <literallayout class='monospaced'>
      MACHINE = "qemux86-64"
@@ -1280,7 +1285,7 @@
                     <listitem><para>A unique architecture is defined for the Multilib packages,
                         along with creating a unique deploy folder under 
                         <filename>tmp/deploy/rpm</filename> in the 
-                        <link linkend='build-directory'>build directory</link>. 
+                        <link linkend='build-directory'>Build Directory</link>. 
                         For example, consider <filename>lib32</filename> in a 
                         <filename>qemux86-64</filename> image. 
                         The possible architectures in the system are "all", "qemux86_64",
@@ -1347,6 +1352,8 @@
             <para>
                 The easiest way to define kernel configurations is to set them through the
                 <filename>menuconfig</filename> tool.
+                This tool provides an interactive method with which
+                to set kernel configurations.
                 For general information on <filename>menuconfig</filename>, see
                 <ulink url='http://en.wikipedia.org/wiki/Menuconfig'></ulink>.
             </para>
@@ -1354,25 +1361,97 @@
             <para>
                 To use the <filename>menuconfig</filename> tool in the Yocto Project development
                 environment, you must build the tool using BitBake.
+                Thus, the environment must be set up using the <filename>&OE_INIT_FILE;</filename>
+                script found in the 
+                <link linkend='build-directory'>Build Directory</link>.
                 The following commands build and invoke <filename>menuconfig</filename> assuming the 
-                source directory top-level folder is <filename>~/poky</filename>:
+                Source Directory top-level folder is <filename>~/poky</filename>:
                 <literallayout class='monospaced'>
      $ cd ~/poky
      $ source oe-init-build-env
      $ bitbake linux-yocto -c menuconfig
                 </literallayout>
                 Once <filename>menuconfig</filename> comes up, its standard interface allows you to 
-                examine and configure all the kernel configuration parameters.
-                Once you have made your changes, simply exit the tool and save your changes to 
+                interactively examine and configure all the kernel configuration parameters.
+                After making your changes, simply exit the tool and save your changes to 
                 create an updated version of the <filename>.config</filename> configuration file.
             </para>
 
             <para>
-                For an example that shows how to change a specific kernel option
-                using <filename>menuconfig</filename>, see the 
-                "<link linkend='changing-the-config-smp-configuration-using-menuconfig'>Changing
-                the <filename>CONFIG_SMP</filename> Configuration Using <filename>menuconfig</filename></link>" 
-                section.
+                Consider an example that configures the <filename>linux-yocto-3.4</filename>
+                kernel.
+                The OpenEmbedded build system recognizes this kernel as 
+                <filename>linux-yocto</filename>.
+                Thus, the following commands from the shell in which you previously sourced the 
+                environment initialization script cleans the shared state cache and the 
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-WORKDIR'><filename>WORKDIR</filename></ulink>
+                directory and then builds and launches <filename>menuconfig</filename>:
+                <literallayout class='monospaced'>
+     $ bitbake linux-yocto -c menuconfig
+                </literallayout>
+            </para>
+
+            <para>
+                Once <filename>menuconfig</filename> launches, you use the interface 
+                to navigate through the selections to find the configuration settings in
+                which you are interested.  
+                For example, consider the <filename>CONFIG_SMP</filename> configuration setting.
+                You can find it at <filename>Processor Type and Features</filename> under 
+                the configuration selection <filename>Symmetric Multi-processing Support</filename>.
+                After highlighting the selection, you can use the arrow keys to select or deselect
+                the setting.
+                When you are finished with all your selections, exit out and save them.
+            </para>
+
+            <para>
+                Saving the selections updates the <filename>.config</filename> configuration file.
+                This is the file that the OpenEmbedded build system uses to configure the 
+                kernel during the build. 
+                You can find and examine this file in the Build Directory in 
+                <filename>tmp/work/</filename>.
+                The actual <filename>.config</filename> is located in the area where the 
+                specific kernel is built.
+                For example, if you were building a Linux Yocto kernel based on the 
+                Linux 3.4 kernel and you were building a QEMU image targeted for 
+                <filename>x86</filename> architecture, the 
+                <filename>.config</filename> file would be located here:
+                <literallayout class='monospaced'>
+     ~/poky/build/tmp/work/qemux86-poky-linux/linux-yocto-3.4.11+git1+84f...
+        ...656ed30-r1/linux-qemux86-standard-build
+                </literallayout>
+                <note>
+                    The previous example directory is artificially split and many of the characters 
+                    in the actual filename are omitted in order to make it more readable.
+                    Also, depending on the kernel you are using, the exact pathname 
+                    for <filename>linux-yocto-3.4...</filename> might differ.
+                </note>
+            </para>
+
+            <para>
+                Within the <filename>.config</filename> file, you can see the kernel settings.
+                For example, the following entry shows that symmetric multi-processor support
+                is not set:
+                <literallayout class='monospaced'>
+     # CONFIG_SMP is not set
+                </literallayout>
+            </para>
+
+            <para>
+                A good method to isolate changed configurations is to use a combination of the 
+                <filename>menuconfig</filename> tool and simple shell commands.
+                Before changing configurations with <filename>menuconfig</filename>, copy the 
+                existing <filename>.config</filename> and rename it to something else,
+                use <filename>menuconfig</filename> to make 
+                as many changes an you want and save them, then compare the renamed configuration 
+                file against the newly created file.
+                You can use the resulting differences as your base to create configuration fragments
+                to permanently save in your kernel layer.
+                <note>
+                    Be sure to make a copy of the <filename>.config</filename> and don't just
+                    rename it. 
+                    The build system needs an existing <filename>.config</filename>
+                    from which to work.
+                </note>
             </para>
         </section>
 
@@ -1384,7 +1463,7 @@
                 placed where the OpenEmbedded build system can find and apply them.
                 Syntactically, the configuration statement is identical to what would appear
                 in the <filename>.config</filename> file, which is in the 
-                <link linkend='build-directory'>build directory</link> in 
+                <link linkend='build-directory'>Build Directory</link> in 
                 <filename>tmp/work/&lt;arch&gt;-poky-linux/linux-yocto-&lt;release-specific-string&gt;/linux-&lt;arch&gt;-&lt;build-type&gt;</filename>.
             </para>
 
@@ -1511,6 +1590,306 @@
         </section>
     </section>
 
+    <section id="patching-the-kernel">
+        <title>Patching the Kernel</title>
+  
+        <para>
+            Patching the kernel involves changing or adding configurations to an existing kernel,  
+            changing or adding recipes to the kernel that are needed to support specific hardware features, 
+            or even altering the source code itself.  
+            <note>
+                You can use the <filename>yocto-kernel</filename> script
+                found in the <link linkend='source-directory'>Source Directory</link>
+                under <filename>scripts</filename> to manage kernel patches and configuration.
+                See the "<ulink url='&YOCTO_DOCS_BSP_URL;#managing-kernel-patches-and-config-items-with-yocto-kernel'>Managing kernel Patches and Config Items with yocto-kernel</ulink>" 
+                section in the Yocto Project Board Support Packages (BSP) Developer's Guide for
+                more information.</note>
+        </para>
+
+        <para>
+            This example creates a simple patch by adding some QEMU emulator console 
+            output at boot time through <filename>printk</filename> statements in the kernel's
+            <filename>calibrate.c</filename> source code file.
+            Applying the patch and booting the modified image causes the added 
+            messages to appear on the emulator's console.
+        </para>
+
+        <para>
+            The example assumes a clean build exists for the <filename>qemux86</filename>
+            machine in a Source Directory named <filename>poky</filename>.
+            Furthermore, the <link linkend='build-directory'>Build Directory</link> is 
+            <filename>build</filename> and is located in <filename>poky</filename> and  
+            the kernel is based on the Linux 3.4 kernel.
+            For general information on how to configure the most efficient build, see the 
+            "<ulink url='&YOCTO_DOCS_QS_URL;#building-image'>Building an Image</ulink>" section
+            in the Yocto Project Quick Start.
+        </para>
+
+        <section id='create-a-layer-for-your-changes'>
+            <title>Create a Layer for your Changes</title>
+
+            <para>
+                The first step is to create a layer so you can isolate your changes:
+                <literallayout class='monospaced'>
+     $cd ~/poky
+     $mkdir meta-mylayer
+                </literallayout>
+                Creating a directory that follows the Yocto Project layer naming 
+                conventions sets up the layer for your changes.  
+                The layer is where you place your configuration files, append
+                files, and patch files. 
+                To learn more about creating a layer and filling it with the 
+                files you need, see the "<link linkend='understanding-and-creating-layers'>Understanding
+                and Creating Layers</link>" section.                
+            </para>
+        </section>
+
+        <section id='finding-the-kernel-source-code'>
+            <title>Finding the Kernel Source Code</title>
+
+            <para>
+                Each time you build a kernel image, the kernel source code is fetched 
+                and unpacked into the following directory:
+                <literallayout class='monospaced'>
+     ${S}/linux
+                </literallayout>
+                See the "<link linkend='finding-the-temporary-source-code'>Finding the Temporary Source Code</link>" 
+                section and the 
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-S'><filename>S</filename></ulink> variable
+                for more information about where source is kept during a build.
+            </para>
+
+            <para>
+                For this example, we are going to patch the 
+                <filename>init/calibrate.c</filename> file
+                by adding some simple console <filename>printk</filename> statements that we can 
+                see when we boot the image using QEMU.
+            </para>
+        </section> 
+
+        <section id='creating-the-patch'>
+            <title>Creating the Patch</title>
+
+            <para>
+                Two methods exist by which you can create the patch: 
+                <link linkend='using-a-git-workflow'>Git workflow</link> and 
+                <link linkend='using-a-quilt-workflow'>Quilt workflow</link>.
+                For kernel patches, the Git workflow is more appropriate. 
+                This section assumes the Git workflow and shows the steps specific to 
+                this example.
+                <orderedlist>
+                    <listitem><para><emphasis>Change the working directory</emphasis>:
+                        Change to where the kernel source code is before making 
+                        your edits to the <filename>calibrate.c</filename> file:
+                        <literallayout class='monospaced'>
+     $ cd ~/poky/build/tmp/work/qemux86-poky-linux/linux-yocto-${PV}-${PR}/linux
+                        </literallayout>
+                        Because you are working in an established Git repository, 
+                        you must be in this directory in order to commit your changes
+                        and create the patch file.
+                        <note>The <ulink url='&YOCTO_DOCS_REF_URL;#var-PV'><filename>PV</filename></ulink> and 
+                            <ulink url='&YOCTO_DOCS_REF_URL;#var-PR'><filename>PR</filename></ulink> variables
+                            represent the version and revision for the 
+                            <filename>linux-yocto</filename> recipe.
+                            The <filename>PV</filename> variable includes the Git meta and machine
+                            hashes, which make the directory name longer than you might
+                            expect.
+                        </note></para></listitem>
+                    <listitem><para><emphasis>Edit the source file</emphasis>:
+                        Edit the <filename>init/calibrate.c</filename> file to have the 
+                        following changes:
+                        <literallayout class='monospaced'>
+     void __cpuinit calibrate_delay(void)
+     {
+         unsigned long lpj;
+         static bool printed;
+         int this_cpu = smp_processor_id();
+
+         printk("*************************************\n");
+         printk("*                                   *\n");
+         printk("*        HELLO YOCTO KERNEL         *\n");
+         printk("*                                   *\n");
+         printk("*************************************\n");
+
+     	if (per_cpu(cpu_loops_per_jiffy, this_cpu)) {
+               .
+               .
+               .
+                        </literallayout></para></listitem>
+                    <listitem><para><emphasis>Stage and commit your changes</emphasis>:
+                        These Git commands list out the changed file, stage it, and then 
+                        commit the file:
+                        <literallayout class='monospaced'>
+     $ git status
+     $ git add init/calibrate.c
+     $ git commit -m "calibrate: Add printk example"
+                        </literallayout></para></listitem>
+                    <listitem><para><emphasis>Generate the patch file</emphasis>:
+                        This Git command creates the a patch file named
+                        <filename>0001-calibrate-Add-printk-example.patch</filename> 
+                        in the current directory.
+                        <literallayout class='monospaced'>
+     $ git format-patch -1
+                        </literallayout>
+                        </para></listitem>
+                </orderedlist>
+            </para>
+        </section>
+
+        <section id='get-your-layer-setup-for-the-build'>
+            <title>Get Your Layer Setup for the Build</title>
+
+            <para>These steps get your layer set up for the build:
+                <orderedlist>
+                    <listitem><para><emphasis>Create additional structure</emphasis>:
+                        Create the additional layer structure:
+                        <literallayout class='monospaced'>
+     $ cd ~/poky/meta-mylayer
+     $ mkdir conf
+     $ mkdir recipes-kernel
+     $ mkdir recipes-kernel/linux
+     $ mkdir recipes-kernel/linux/linux-yocto
+                         </literallayout>
+                         The <filename>conf</filename> directory holds your configuration files, while the 
+                         <filename>recipes-kernel</filename> directory holds your append file and 
+                         your patch file.</para></listitem>
+                    <listitem><para><emphasis>Create the layer configuration file</emphasis>:
+                        Move to the <filename>meta-mylayer/conf</filename> directory and create
+                        the <filename>layer.conf</filename> file as follows:
+                        <literallayout class='monospaced'>
+     # We have a conf and classes directory, add to BBPATH
+     BBPATH := "${LAYERDIR}:${BBPATH}"
+
+     # We have a packages directory, add to BBFILES
+     BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
+                 ${LAYERDIR}/recipes-*/*/*.bbappend"
+
+     BBFILE_COLLECTIONS += "mylayer"
+     BBFILE_PATTERN_mylayer := "^${LAYERDIR}/"
+     BBFILE_PRIORITY_mylayer = "5"
+                         </literallayout>
+                         Notice <filename>mylayer</filename> as part of the last three 
+                         statements.</para></listitem>
+                    <listitem><para><emphasis>Create the kernel recipe append file</emphasis>:
+                        Move to the <filename>meta-mylayer/recipes-kernel/linux</filename> directory and create
+                        the <filename>linux-yocto_3.4.bbappend</filename> file as follows:
+                        <literallayout class='monospaced'>
+     FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+
+     SRC_URI += "file://0001-calibrate-Add-printk-example.patch"
+
+     PRINC := "${@int(PRINC) + 1}"                       
+                        </literallayout>
+                        The <filename>FILESEXTRAPATHS</filename> and <filename>SRC_URI</filename>
+                        statements enable the OpenEmbedded build system to find the patch file.
+                        </para></listitem>
+                    <listitem><para><emphasis>Put the patch file in your layer</emphasis>:
+                        Move the <filename>0001-calibrate-Add-printk-example.patch</filename> file to 
+                        the <filename>meta-mylayer/recipes-kernel/linux/linux-yocto</filename>
+                        directory.</para></listitem>
+                </orderedlist>
+            </para>
+        </section>
+
+        <section id='set-up-for-the-build'>
+            <title>Set Up for the Build</title>
+
+            <para>
+                Do the following to make sure the build parameters are set up for the example.
+                Once you set up these build parameters, they do not have to change unless you 
+                change the target architecture of the machine you are building:
+                <itemizedlist>
+                    <listitem><para><emphasis>Build for the Correct Target Architecture:</emphasis> Your
+                        selected <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink>
+                        definition within the <filename>local.conf</filename> file in the Build Directory 
+                        specifies the target architecture used when building the Linux kernel.
+                        By default, <filename>MACHINE</filename> is set to 
+                        <filename>qemux86</filename>, which specifies a 32-bit 
+                        <trademark class='registered'>Intel</trademark> Architecture 
+                        target machine suitable for the QEMU emulator.</para></listitem>
+                    <listitem><para><emphasis>Identify Your <filename>meta-mylayer</filename>
+                        Layer:</emphasis> The <filename>BBLAYERS</filename> variable in the 
+                        <filename>bblayers.conf</filename> file found in the 
+                        <filename>poky/build/conf</filename> directory needs to have the path to your local
+                        <filename>meta-mylayer</filename> layer.  
+                        By default, the <filename>BBLAYERS</filename> variable contains paths to  
+                        <filename>meta</filename>, <filename>meta-yocto</filename>, and 
+                        <filename>meta-yocto-bsp</filename> in the 
+                        <filename>poky</filename> Git repository.
+                        Add the path to your <filename>meta-mylayer</filename> location.
+                        Be sure to substitute your user information in the statement:
+                        <literallayout class='monospaced'>
+     BBLAYERS = " \
+       /home/&lt;user&gt;/poky/meta \
+       /home/&lt;user&gt;/poky/meta-yocto \
+       /home/&lt;user&gt;/poky/meta-yocto-bsp \
+       /home/&lt;user&gt;/poky/meta-mylayer \
+       "
+                        </literallayout></para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id='build-and-booting-the-modified-qemu-kernel-image'>
+            <title>Build and Booting the Modified QEMU Kernel Image</title>
+
+            <para>
+                The following steps build and boot your modified kernel image:
+                <orderedlist>
+                    <listitem><para><emphasis>Be sure your build environment is initialized</emphasis>:
+                        Your environment should be set up since you previously sourced
+                        the <filename>&OE_INIT_FILE;</filename> script.
+                        If it is not, source the script again from <filename>poky</filename>.
+                        <literallayout class='monospaced'>
+     $ cd ~/poky
+     $ source &OE_INIT_FILE;
+                        </literallayout>
+                        </para></listitem>
+                    <listitem><para><emphasis>Clean up</emphasis>:
+                        Be sure to clean the shared state out by running the 
+                        <filename>cleansstate</filename> BitBake task as follows from your Build Directory:
+                        <literallayout class='monospaced'>
+     $ bitbake -c cleansstate linux-yocto
+                        </literallayout></para>
+                        <para><note>Never remove any files by hand from the <filename>tmp/deploy</filename>
+                        directory inside the Build Directory.
+                        Always use the various BitBake clean tasks to clear out previous 
+                        build artifacts.
+                        </note></para></listitem>
+                    <listitem><para><emphasis>Build the image</emphasis>:
+                        Next, build the kernel image using this command:
+                        <literallayout class='monospaced'>
+     $ bitbake -k linux-yocto
+                        </literallayout></para></listitem>
+                </orderedlist>
+            </para>
+        </section>
+
+        <section id='verify-your-changes'>
+            <title>Verify Your Changes</title>
+
+            <para>
+                These steps boot the image and allow you to see the changes
+                <orderedlist>
+                    <listitem><para><emphasis>Boot the image</emphasis>:
+                        Boot the modified image in the QEMU emulator 
+                        using this command:
+                        <literallayout class='monospaced'>
+     $ runqemu qemux86
+                        </literallayout></para></listitem>
+                    <listitem><para><emphasis>Verify the changes</emphasis>:
+                        Log into the machine using <filename>root</filename> with no password and then 
+                        use the following shell command to scroll through the console's boot output.
+                        <literallayout class='monospaced'>
+     # dmesg | less
+                        </literallayout>
+                        You should see the results of your <filename>printk</filename> statements 
+                        as part of the output.</para></listitem>
+                </orderedlist>
+            </para>
+        </section>
+    </section>
+
     <section id="usingpoky-changes-updatingimages">
         <title>Updating Existing Images</title>
 
@@ -1634,7 +2013,7 @@
      $ bitbake world -f -c distro_check
             </literallayout>
             The results are stored in the <filename>build/tmp/log/distro_check-${DATETIME}.results</filename> 
-            file found in the source directory.
+            file found in the Source Directory.
         </para>
     </section>
 
@@ -1643,14 +2022,14 @@
 
         <para>
             By default, the OpenEmbedded build system does its work from within the 
-            <link linkend='build-directory'>build directory</link>.  
+            <link linkend='build-directory'>Build Directory</link>.  
             The build process involves fetching the source files, unpacking them, and then patching them
             if necessary before the build takes place.
         </para>
 
         <para>
             Situations exist where you might want to build software from source files that are external to 
-            and thus outside of the <link linkend='source-directory'>source directory</link>.
+            and thus outside of the <link linkend='source-directory'>Source Directory</link>.
             For example, suppose you have a project that includes a new BSP with a heavily customized 
             kernel, a very minimal image, and some new user-space recipes.
             And, you want to minimize exposing the build system to the 
@@ -1679,17 +2058,17 @@
 
         <para>
             It is important to know that the <filename>externalsrc.bbclass</filename> assumes that the 
-            source directory <filename>S</filename> and the build directory 
+            source directory <filename>S</filename> and the Build Directory 
             <ulink url='&YOCTO_DOCS_REF_URL;#var-B'><filename>B</filename></ulink>
             are different even though by default these directories are the same.
             This assumption is important because it supports building different variants of the recipe
             by using the 
             <ulink url='&YOCTO_DOCS_REF_URL;#var-BBCLASSEXTEND'><filename>BBCLASSEXTEND</filename></ulink>
             variable.
-            You could allow the build directory to be the same as the source directory but you would 
+            You could allow the Build Directory to be the same as the source directory but you would 
             not be able to build more than one variant of the recipe.
             Consequently, if you are building multiple variants of the recipe, you need to establish a 
-            build directory that is different than the source directory.
+            Build Directory that is different than the source directory.
         </para>
     </section>
 
@@ -1735,7 +2114,7 @@
         <para>
             To enable this behavior, simply add the following to the <filename>local.conf</filename>
             configuration file found in the 
-            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>:
+            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>:
             <literallayout class='monospaced'>
      SRCREV_pn-&lt;PN&gt; = "${AUTOREV}"
             </literallayout>
@@ -2166,7 +2545,7 @@
                 </para>
 
                 <para>
-                    Downloaded archives reside in the build directory in 
+                    Downloaded archives reside in the Build Directory in 
                     <filename>/tmp</filename> and are cleared up when they are no longer in use.
                 </para>
 
@@ -2228,6 +2607,232 @@
             </section>
         </section>
     </section>
+
+    <section id='maintaining-open-source-license-compliance-during-your-products-lifecycle'>
+        <title>Maintaining Open Source License Compliance During Your Product's Lifecycle</title>
+
+        <para>
+            One of the concerns for a development organization using open source
+            software is how to maintain compliance with various open source
+            licensing during the lifecycle of the product.
+            While this section does not provide legal advice or  
+            comprehensively cover all scenarios, it does 
+            present methods that you can use to 
+            assist you in meeting the compliance requirements during a software
+            release.
+        </para>
+
+        <para>
+            With hundreds of different open source licenses that the Yocto 
+            Project tracks, it is difficult to know the requirements of each 
+            and every license.
+            However, we can begin to cover the requirements of the major FLOSS licenses, by
+            assuming that there are three main areas of concern:
+            <itemizedlist>
+                <listitem><para>Source code must be provided.</para></listitem>
+                <listitem><para>License text for the software must be 
+                    provided.</para></listitem>
+                <listitem><para>Compilation scripts and modifications to the 
+                    source code must be provided.
+                    </para></listitem>
+            </itemizedlist>
+            There are other requirements beyond the scope of these
+            three and the methods described in this section 
+            (e.g. the mechanism through which source code is distributed).
+            As different organizations have different methods of complying with 
+            open source licensing, this section is not meant to imply that 
+            there is only one single way to meet your compliance obligations, 
+            but rather to describe one method of achieving compliance.
+        </para>
+
+        <para>
+            The remainder of this section describes methods supported to meet the
+            previously mentioned three requirements.
+            Once you take steps to meet these requirements, 
+            and prior to releasing images, sources, and the build system,
+            you should audit all artifacts to ensure completeness.
+            The Yocto Project generates a license manifest during 
+            image creation that is located 
+            in <filename>${DEPLOY_DIR}/licenses/&lt;image_name-datestamp&gt;</filename>
+            to assist with any audits.
+        </para>
+
+        <section id='providing-the-source-code'>
+            <title>Providing the Source Code</title>
+
+            <para>
+                Compliance activities should begin before you generate the 
+                final image. 
+                The first thing you should look at is the requirement that
+                tops the list for most compliance groups - providing
+                the source.
+                The Yocto Project has a few ways of meeting this
+                requirement. 
+            </para>
+
+            <para>
+                One of the easiest ways to meet this requirement is
+                to provide the entire 
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-DL_DIR'><filename>DL_DIR</filename></ulink>
+                used by the build. 
+                This method, however, has a few issues.
+                The most obvious is the size of the directory since it includes
+                all sources used in the build and not just the source used in 
+                the released image. 
+                It will include toolchain source, and other artifacts which 
+                you would not generally release. 
+                But, the more serious issue for most companies is accidental 
+                release of proprietary software. 
+                The Yocto Project provides an archiver class to help avoid
+                some of these concerns.
+            </para>
+
+            <para>
+                Before you employ <filename>DL_DIR</filename> or the 
+                archiver class, you need to decide how you choose to
+                provide source. 
+                The source archiver class can generate tarballs and SRPMs 
+                and can create them with various levels of compliance in mind. 
+                One way of doing this (but certainly not the only way) is to 
+                release just the original source as a tarball.
+                You can do this by adding the following to the 
+                <filename>local.conf</filename> file found in the 
+                <link linkend='build-directory'>Build Directory</link>:
+                <literallayout class='monospaced'>
+     ARCHIVER_MODE ?= "original"
+     ARCHIVER_CLASS = "${@'archive-${ARCHIVER_MODE}-source' if
+     ARCHIVER_MODE != 'none' else ''}"
+     INHERIT += "${ARCHIVER_CLASS}"
+     SOURCE_ARCHIVE_PACKAGE_TYPE = "tar"
+                </literallayout>
+                During the creation of your image, all GPL
+                or other copyleft licensed source 
+                is placed within subdirectories of 
+                <filename>DEPLOY_DIR/sources</filename> based on the 
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-LICENSE'><filename>LICENSE</filename></ulink>
+                for each recipe. 
+                Releasing the entire directory enables you to comply with 
+                requirements concerning providing the unmodified source.
+                It is important to note that the size of the directory can
+                get large. 
+            </para>
+
+            <para>
+                A way to help mitigate the size issue is to only release
+                tarballs for licenses that require the release of
+                source. 
+                Let's assume you are only concerned with GPL code as 
+                identified with the following:
+                <literallayout class='monospaced'>
+     $ cd poky/build/tmp/deploy/sources
+     $ mkdir ~/gpl_source_release
+     $ for x in `ls|grep GPL`; do cp -R $x/* ~/gpl_source_release; done
+                </literallayout>
+                At this point, you could create a tarball from the 
+                <filename>gpl_source_release</filename> directory and
+                provide that to the end user.
+                This method would be a step toward achieving compliance 
+                with section 3a of GPLv2 and with section 6 of GPLv3.
+            </para>
+        </section>
+
+        <section id='providing-license-text'>
+            <title>Providing License Text</title>
+
+            <para>
+                One requirement that is often overlooked is inclusion 
+                of license text.
+                This requirement also needs to be dealt with prior to 
+                generating the final image.
+                Some licenses require the license text to accompany
+                the binary. 
+                You can achieve this by adding the following to your
+                <filename>local.conf</filename> file:
+                <literallayout class='monospaced'>
+     COPY_LIC_MANIFEST = "1"
+     COPY_LIC_DIRS = "1"
+                </literallayout>
+                Adding these statements to the configuration file ensures
+                that the licenses collected during package generation
+                are included on your image.
+                As the source archiver has already archived the original 
+                unmodified source which would contain the license files, 
+                you would have already met the requirements for inclusion 
+                of the license information with source as defined by the GPL 
+                and other open source licenses.
+            </para>
+        </section>
+
+        <section id='providing-compilation-scripts-and-source-code-modifications'>
+            <title>Providing Compilation Scripts and Source Code Modifications</title>
+
+            <para>
+                At this point, we have addressed all we need to address 
+                prior to generating the image.
+                The next two requirements are addressed during the final
+                packaging of the release.
+            </para>
+
+            <para>
+                By releasing the version of the OpenEmbedded build system
+                and the layers used during the build, you will be providing both
+                compilation scripts and the source code modifications in one 
+                step.
+            </para>
+
+            <para>
+                If the deployment team has a 
+                <ulink url='&YOCTO_DOCS_BSP_URL;#bsp-layers'>BSP layer</ulink>
+                and a distro layer, and those those layers are used to patch, 
+                compile, package, or modify (in any way) any open source 
+                software included in your released images, you
+                may be required to to release those layers under section 3 of 
+                GPLv2 or section 1 of GPLv3. 
+                One way of doing that is with a clean
+                checkout of the version of the Yocto Project and layers used 
+                during your build.
+                Here is an example:
+                <literallayout class='monospaced'>
+     # We built using the &DISTRO_NAME; branch of the poky repo
+     $ git clone -b &DISTRO_NAME; git://git.yoctoproject.org/poky
+     $ cd poky
+     # We built using the release_branch for our layers
+     $ git clone -b release_branch git://git.mycompany.com/meta-my-bsp-layer
+     $ git clone -b release_branch git://git.mycompany.com/meta-my-software-layer
+     # clean up the .git repos
+     $ find . -name ".git" -type d -exec rm -rf {} \;
+                </literallayout>
+                One thing a development organization might want to consider 
+                for end-user convenience is to modify 
+                <filename>meta-yocto/conf/bblayers.conf.sample</filename> to
+                ensure that when the end user utilizes the released build 
+                system to build an image, the development organization's 
+                layers are included in the <filename>bblayers.conf</filename>
+                file automatically:
+                <literallayout class='monospaced'>
+     # LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
+     # changes incompatibly
+     LCONF_VERSION = "6"
+
+     BBPATH = "${TOPDIR}"
+     BBFILES ?= ""
+
+     BBLAYERS ?= " \
+       ##COREBASE##/meta \
+       ##COREBASE##/meta-yocto \
+       ##COREBASE##/meta-yocto-bsp \
+       ##COREBASE##/meta-my-bsp-layer \
+       ##COREBASE##/meta-my-software-layer \
+       "
+                </literallayout>
+                Creating and providing an archive of the metadata layers
+                (recipes, configuration files, and so forth) 
+                enables you to meet your 
+                requirements to include the scripts to control compilation 
+                as well as any modifications to the original source.
+            </para>
+        </section>
+    </section>
 </chapter>
 
 <!-- 

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

@@ -23,9 +23,9 @@
         </para>
 
         <para>  
-            The Yocto Project Development Manual, however, does provide detailed examples on how to create a 
-            Board Support Package (BSP), change the kernel source code, and reconfigure the kernel.
-            You can find this information in the appendices of the manual.
+            The Yocto Project Development Manual, however, does provide detailed examples
+            on how to change the kernel source code, reconfigure the kernel, and develop
+            an application using the popular <trademark class='trade'>Eclipse</trademark> IDE.
         </para>
     </section>
 
@@ -44,7 +44,7 @@
                 <listitem><para>Development case overviews for both system development and user-space 
                     applications.</para></listitem>
                 <listitem><para>An overview and understanding of the emulation environment used with 
-                    the Yocto Project (QEMU).</para></listitem>
+                    the Yocto Project - the Quick EMUlator (QEMU).</para></listitem>
                 <listitem><para>An understanding of basic kernel architecture and concepts.</para></listitem>
                 <listitem><para>Many references to other sources of related information.</para></listitem>
             </itemizedlist>

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

@@ -12,6 +12,13 @@
         or even altering the source code itself.  
         This appendix presents simple examples that modify the kernel source code, 
         change the kernel configuration, and add a kernel source recipe.
+        <note>
+            You can use the <filename>yocto-kernel</filename> script
+            found in the <link linkend='source-directory'>Source Directory</link>
+            under <filename>scripts</filename> to manage kernel patches and configuration.
+            See the "<ulink url='&YOCTO_DOCS_BSP_URL;#managing-kernel-patches-and-config-items-with-yocto-kernel'>Managing kernel Patches and Config Items with yocto-kernel</ulink>" 
+            section in the Yocto Project Board Support Packages (BSP) Developer's Guide for
+            more information.</note>
     </para>
 
     <section id='modifying-the-kernel-source-code'>
@@ -34,11 +41,11 @@
                 Briefly, you need the following: 
                 <itemizedlist>
                     <listitem><para>A local 
-                        <link linkend='source-directory'>source directory</link> for the 
+                        <link linkend='source-directory'>Source Directory</link> for the 
                         poky Git repository</para></listitem>
                     <listitem><para>Local copies of the
                         <link linkend='poky-extras-repo'><filename>poky-extras</filename></link>
-                        Git repository placed within the source directory.</para></listitem>  
+                        Git repository placed within the Source Directory.</para></listitem>  
                     <listitem><para>A bare clone of the 
                         <link linkend='local-kernel-files'>Yocto Project Kernel</link> upstream Git 
                         repository to which you want to push your modifications.
@@ -59,7 +66,7 @@
             </para>
 
             <para>
-                <imagedata fileref="figures/kernel-example-repos-denzil.png" width="7in" depth="5in" 
+                <imagedata fileref="figures/kernel-example-repos-generic.png" width="7in" depth="5in" 
                     align="center" scale="100" />
             </para>
 
@@ -69,16 +76,18 @@
                     <listitem><para><emphasis>Local Source Directory:</emphasis> 
                         This area contains all the metadata that supports building images 
                         using the OpenEmbedded build system.
-                        In this example, the source directory also 
-                        contains the build directory, which contains the configuration directory 
+                        In this example, the 
+                        <link linkend='source-directory'>Source Directory</link> also 
+                        contains the 
+                        <link linkend='build-directory'>Build Directory</link>, 
+                        which contains the configuration directory 
                         that lets you control the build.
-                        Also in this example, the source directory contains local copies of the 
+                        Also in this example, the Source Directory contains local copies of the 
                         <filename>poky-extras</filename> Git repository.</para>
                         <para>See the bulleted item
                         "<link linkend='local-yp-release'>Yocto Project Release</link>"
                         for information on how to get these files on your local system.</para></listitem>
-                    <listitem><para><emphasis>Local copies of the<filename>poky-extras</filename> 
-                        Git Repository:</emphasis> 
+                    <listitem><para><emphasis>Local copies of the&nbsp;<filename>poky-extras</filename>&nbsp;Git Repository:</emphasis> 
                         This area contains the <filename>meta-kernel-dev</filename> layer, 
                         which is where you make changes that append the kernel build recipes.
                         You edit <filename>.bbappend</filename> files to locate your 
@@ -125,17 +134,19 @@
             <title>Setting Up the Local Source Directory</title>
 
             <para>
-                You can set up the source directory through tarball extraction or by 
+                You can set up the 
+                <link linkend='source-directory'>Source Directory</link>
+                through tarball extraction or by 
                 cloning the <filename>poky</filename> Git repository.  
                 This example uses <filename>poky</filename> as the root directory of the 
-                local source directory.
+                local Source Directory.
                 See the bulleted item
                 "<link linkend='local-yp-release'>Yocto Project Release</link>"
                 for information on how to get these files.
             </para>
 
             <para>
-                Once you have source directory set up, 
+                Once you have Source Directory set up, 
                 you have many development branches from which you can work. 
                 From inside the local repository you can see the branch names and the tag names used 
                 in the upstream Git repository by using either of the following commands:
@@ -161,7 +172,7 @@
 
             <para>
                 This example creates a local copy of the <filename>poky-extras</filename> Git 
-                repository inside the <filename>poky</filename> source directory.
+                repository inside the <filename>poky</filename> Source Directory.
                 See the bulleted item "<link linkend='poky-extras-repo'>The 
                 <filename>poky-extras</filename> Git Repository</link>" 
                 for information on how to set up a local copy of the
@@ -172,11 +183,12 @@
                 Because this example uses the Yocto Project &DISTRO; Release code 
                 named "&DISTRO_NAME;", which maps to the <filename>&DISTRO_NAME;</filename> 
                 branch in the repository, you need to be sure you are using that 
-                branch for <filename>poky-extra</filename>.
+                branch for <filename>poky-extras</filename>.
                 The following commands create and checkout the local 
                 branch you are using for the <filename>&DISTRO_NAME;</filename>
                 branch:
                 <literallayout class='monospaced'>
+     $ cd ~/poky/poky-extras
      $ git checkout -b &DISTRO_NAME; origin/&DISTRO_NAME;
      Branch &DISTRO_NAME; set up to track remote branch &DISTRO_NAME; from origin.
      Switched to a new branch '&DISTRO_NAME;'
@@ -188,7 +200,7 @@
             <title>Setting Up the Bare Clone and its Copy</title>
 
             <para>
-                This example modifies the <filename>linux-yocto-3.2</filename> kernel.
+                This example modifies the <filename>linux-yocto-3.4</filename> kernel.
                 Thus, you need to create a bare clone of that kernel and then make a copy of the 
                 bare clone.
                 See the bulleted item
@@ -200,17 +212,16 @@
                 The bare clone exists for the kernel build tools and simply as the receiving end 
                 of <filename>git push</filename>
                 commands after you make edits and commits inside the copy of the clone.
-                The copy (<filename>my-linux-yocto-3.2-work</filename> in this example) has to have 
+                The copy (<filename>my-linux-yocto-3.4-work</filename> in this example) has to have 
                 a local branch created and checked out for your work.
                 This example uses <filename>common-pc-base</filename> as the local branch.
                 The following commands create and checkout the branch:
                 <literallayout class='monospaced'>
-     $ cd ~/my-linux-yocto-3.2-work
-     $ git checkout -b common-pc-base origin/standard/default/common-pc/base
-     Checking out files: 100% (532/532), done.
-     Branch common-pc-base set up to track remote branch 
-        standard/default/common-pc/base from origin.
-     Switched to a new branch 'common-pc-base'
+     $ cd ~/my-linux-yocto-3.4-work
+     $ git checkout -b standard-common-pc-base origin/standard/common-pc/base
+     Branch standard-common-pc-base set up to track remote branch 
+        standard/common-pc/base from origin.
+     Switched to a new branch 'standard-common-pc-base'
                 </literallayout>
             </para>
         </section>
@@ -224,7 +235,7 @@
                 <note>
                     Because a full build can take hours, you should check two variables in the 
                     <filename>build</filename> directory that is created after you source the 
-                    <filename>oe-init-build-env</filename> script.
+                    <filename>&OE_INIT_FILE;</filename> script.
                     You can find these variables
                     <filename>BB_NUMBER_THREADS</filename> and <filename>PARALLEL_MAKE</filename>
                     in the <filename>build/conf</filename> directory in the 
@@ -242,11 +253,36 @@
                 If necessary, the script creates the build directory:
                 <literallayout class='monospaced'>
      $ cd ~/poky
-     $ source oe-init-build-env
+     $ source &OE_INIT_FILE;
+     You had no conf/local.conf file. This configuration file has therefore been
+     created for you with some default values. You may wish to edit it to use a 
+     different MACHINE (target hardware) or enable parallel build options to take 
+     advantage of multiple cores for example. See the file for more information as 
+     common configuration options are commented.
 
-          ### Shell environment set up for builds. ###
+     The Yocto Project has extensive documentation about OE including a reference manual
+     which can be found at:
+         http://yoctoproject.org/documentation
 
-     You can now run 'bitbake &lt;target&gt;'
+     For more information about OpenEmbedded see their website:
+         http://www.openembedded.org/
+
+     You had no conf/bblayers.conf file. The configuration file has been created for
+     you with some default values. To add additional metadata layers into your
+     configuration please add entries to this file.
+
+     The Yocto Project has extensive documentation about OE including a reference manual
+     which can be found at:
+         http://yoctoproject.org/documentation
+
+     For more information about OpenEmbedded see their website:
+         http://www.openembedded.org/
+
+
+
+     ### Shell environment set up for builds. ###
+
+     You can now run 'bitbake &lt;target&gt;>'
 
      Common targets are:
          core-image-minimal
@@ -301,7 +337,7 @@
 
             <para>
                 The file you change in this example is named <filename>calibrate.c</filename>
-                and is located in the <filename>my-linux-yocto-3.2-work</filename> Git repository
+                and is located in the <filename>my-linux-yocto-3.4-work</filename> Git repository
                 (the copy of the bare clone) in <filename>init</filename>.
                 This example simply inserts several <filename>printk</filename> statements
                 at the beginning of the <filename>calibrate_delay</filename> function.
@@ -365,7 +401,7 @@
            <para>
                The following command pushes the changes to the bare clone:
                <literallayout class='monospaced'>
-     $ git push origin common-pc-base:standard/default/common-pc/base
+     $ git push origin standard-common-pc-base:standard/default/common-pc/base
                </literallayout>
            </para>
        </section>
@@ -420,21 +456,25 @@
      BBLAYERS = " \
        /home/scottrif/poky/meta \
        /home/scottrif/poky/meta-yocto \
+       /home/scottrif/poky/meta-yocto-bsp \
        /home/scottrif/poky/poky-extras/meta-kernel-dev \
        "
                        </literallayout></para></listitem>
                    <listitem><para><emphasis>Identify Your Source Files:</emphasis> In the 
-                       <filename>linux-yocto_3.2.bbappend</filename> file located in the 
+                       <filename>linux-yocto_3.4.bbappend</filename> file located in the 
                        <filename>poky-extras/meta-kernel-dev/recipes-kernel/linux</filename>
                        directory, you need to identify the location of the 
                        local source code, which in this example is the bare clone named
-                       <filename>linux-yocto-3.2.git</filename>.
+                       <filename>linux-yocto-3.4.git</filename>.
                        To do this, set the <filename>KSRC_linux_yocto</filename> variable to point to your
-                       local <filename>linux-yocto-3.2.git</filename> Git repository by adding the 
+                       local <filename>linux-yocto-3.4.git</filename> Git repository by adding the 
                        following statement.
-                       Be sure to substitute your user information in the statement:
+                       Also, be sure the <filename>SRC_URI</filename> variable is pointing to
+                       your kernel source files by removing the comment.
+                       Finally, be sure to substitute your user information in the statement:
                        <literallayout class='monospaced'>
-     KSRC_linux_yocto_3_2 ?= "/home/scottrif/linux-yocto-3.2.git"
+     KSRC_linux_yocto_3_4 ?= "/home/scottrif/linux-yocto-3.4.git"
+     SRC_URI = "git://${KSRC_linux_yocto_3_4};protocol=file;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"
                        </literallayout></para></listitem>
                </itemizedlist>
            </para>
@@ -447,7 +487,7 @@
                comment out the <filename>COMPATIBLE_MACHINE</filename> statements in all 
                unused <filename>.bbappend</filename> files, or simply remove (or rename) all the files 
                except the one your are using for the build 
-               (i.e. <filename>linux-yocto_3.2.bbappend</filename> in this example).</para>
+               (i.e. <filename>linux-yocto_3.4.bbappend</filename> in this example).</para>
                <para>If you do not make one of these two adjustments, your machine will be compatible
                with all the kernel recipes in the <filename>meta-kernel-dev</filename> layer. 
                When your machine is comapatible with all the kernel recipes, the build attempts
@@ -464,11 +504,11 @@
                 Do the following:
                 <orderedlist>
                     <listitem><para>Your environment should be set up since you previously sourced
-                        the <filename>oe-init-build-env</filename> script.
+                        the <filename>&OE_INIT_FILE;</filename> script.
                         If it isn't, source the script again from <filename>poky</filename>.
                         <literallayout class='monospaced'>
      $ cd ~/poky
-     $ source oe-init-build-env
+     $ source &OE_INIT_FILE;
                         </literallayout>
                         </para></listitem>
                     <listitem><para>Be sure old images are cleaned out by running the 
@@ -506,299 +546,6 @@
             </para>
         </section>
     </section>
-
-    <section id='changing-the-kernel-configuration'>
-        <title>Changing the Kernel Configuration</title>
-
-        <para>
-            This example changes the default behavior, which is "on", of the Symmetric 
-            Multi-processing Support (<filename>CONFIG_SMP</filename>) to "off".  
-            It is a simple example that demonstrates how to reconfigure the kernel.
-        </para>
-
-        <section id='getting-set-up-to-run-this-example'>
-            <title>Getting Set Up to Run this Example</title>
-
-            <para>
-                If you took the time to work through the example that modifies the kernel source code 
-                in "<link linkend='modifying-the-kernel-source-code'>Modifying the Kernel Source
-                Code</link>" you should already have the source directory set up on your 
-                host machine.
-                If this is the case, go to the next section, which is titled
-                "<link linkend='examining-the-default-config-smp-behavior'>Examining the Default
-                <filename>CONFIG_SMP</filename> Behavior</link>", and continue with the 
-                example.
-            </para>
-
-            <para>
-                If you don't have the source directory established on your system, 
-                you can get them through tarball extraction or by 
-                cloning the <filename>poky</filename> Git repository.  
-                This example uses <filename>poky</filename> as the root directory of the 
-                <link linkend='source-directory'>source directory</link>.
-                See the bulleted item
-                "<link linkend='local-yp-release'>Yocto Project Release</link>"
-                for information on how to get these files.
-            </para>
-
-            <para>
-                Once you have the local copy of the repository set up, 
-                you have many development branches from which you can work. 
-                From inside the repository you can see the branch names and the tag names used 
-                in the upstream Git repository using either of the following commands:
-                <literallayout class='monospaced'>
-     $ cd poky
-     $ git branch -a
-     $ git tag -l
-                </literallayout> 
-                This example uses the Yocto Project &DISTRO; Release code named "&DISTRO_NAME;", 
-                which maps to the <filename>&DISTRO_NAME;</filename> branch in the repository. 
-                The following commands create and checkout the local <filename>&DISTRO_NAME;</filename>
-                branch:
-                <literallayout class='monospaced'>
-     $ git checkout -b &DISTRO_NAME; origin/&DISTRO_NAME;
-     Branch &DISTRO_NAME; set up to track remote branch &DISTRO_NAME; from origin.
-     Switched to a new branch '&DISTRO_NAME;'
-                </literallayout>
-            </para>
-
-            <para>
-                Next, you need to build the default <filename>qemux86</filename> image that you 
-                can boot using QEMU.
-                <note>
-                    Because a full build can take hours, you should check two variables in the 
-                    <filename>build</filename> directory that is created after you source the 
-                    <filename>oe-init-build-env</filename> script.
-                    You can find these variables
-                    <filename>BB_NUMBER_THREADS</filename> and <filename>PARALLEL_MAKE</filename>
-                    in the <filename>build/conf</filename> directory in the 
-                    <filename>local.conf</filename> configuration file.
-                    By default, these variables are commented out.
-                    If your host development system supports multi-core and multi-thread capabilities,
-                    you can uncomment these statements and set the variables to significantly shorten
-                    the full build time.
-                    As a guideline, set both the <filename>BB_NUMBER_THREADS</filename> and the 
-                    <filename>PARALLEL_MAKE</filename> variables to twice the number 
-                    of cores your machine supports.
-                </note>
-                The following two commands <filename>source</filename> the build environment setup script
-                and build the default <filename>qemux86</filename> image.
-                If necessary, the script creates the build directory:
-                <literallayout class='monospaced'>
-     $ cd ~/poky
-     $ source oe-init-build-env
-
-          ### Shell environment set up for builds. ###
-
-     You can now run 'bitbake &lt;target&gt;'
-
-     Common targets are:
-         core-image-minimal
-         core-image-sato
-         meta-toolchain
-         meta-toolchain-sdk
-         adt-installer
-         meta-ide-support
-
-     You can also run generated qemu images with a command like 'runqemu qemux86'
-                </literallayout>
-            </para>
-
-            <para>
-                The following <filename>bitbake</filename> command starts the build:
-                <literallayout class='monospaced'>
-     $ bitbake -k core-image-minimal
-                </literallayout>
-                <note>Be sure to check the settings in the <filename>local.conf</filename>
-                before starting the build.</note>
-            </para>
-        </section>
-
-        <section id='examining-the-default-config-smp-behavior'>
-            <title>Examining the Default&nbsp;&nbsp;<filename>CONFIG_SMP</filename> Behavior</title>
-
-            <para>
-                By default, <filename>CONFIG_SMP</filename> supports multiple processor machines.
-                To see this default setting from within the QEMU emulator, boot your image using 
-                the emulator as follows:
-                <literallayout class='monospaced'>
-     $ runqemu qemux86 qemuparams="-smp 4"
-                </literallayout>
-            </para>
-
-            <para>
-                Login to the machine using <filename>root</filename> with no password.
-                After logging in, enter the following command to see how many processors are 
-                being supported in the emulator.
-                The emulator reports support for the number of processors you specified using 
-                the <filename>-smp</filename> option, four in this case:
-                <literallayout class='monospaced'>
-     # cat /proc/cpuinfo | grep processor 
-     processor       : 0
-     processor       : 1
-     processor       : 2
-     processor       : 3
-     #
-                </literallayout>
-                To check the setting for <filename>CONFIG_SMP</filename>, you can use the 
-                following command:
-                <literallayout class='monospaced'>
-     zcat /proc/config.gz | grep CONFIG_SMP
-                </literallayout>
-                The console returns the following showing that multi-processor machine support
-                is set:
-                <literallayout class='monospaced'>
-     CONFIG_SMP=y
-                </literallayout>
-                Logout of the emulator using the <filename>exit</filename> command and 
-                then close it down.
-            </para>
-        </section>
-
-        <section id='changing-the-config-smp-configuration-using-menuconfig'>
-            <title>Changing the&nbsp;&nbsp;<filename>CONFIG_SMP</filename> Configuration Using&nbsp;&nbsp;<filename>menuconfig</filename></title>
-
-            <para>
-                The <filename>menuconfig</filename> tool provides an interactive method with which
-                to set kernel configurations.
-                You need to run <filename>menuconfig</filename> inside the Yocto BitBake environment.
-                Thus, the environment must be set up using the <filename>oe-init-build-env</filename>
-                script found in the build directory.
-                If you have not sourced this script do so with the following commands:
-                <literallayout class='monospaced'>
-     $ cd ~/poky
-     $ source oe-init-build-env
-                </literallayout>
-            </para>
-
-            <para>
-                After setting up the environment to run <filename>menuconfig</filename>, you are ready 
-                to use the tool to interactively change the kernel configuration.
-                In this example, we are basing our changes on the <filename>linux-yocto-3.2</filename>
-                kernel.
-                The OpenEmbedded build system recognizes this kernel as 
-                <filename>linux-yocto</filename>.
-                Thus, the following commands from the shell in which you previously sourced the 
-                environment initialization script cleans the shared state cache and the 
-                <ulink url='&YOCTO_DOCS_REF_URL;#var-WORKDIR'><filename>WORKDIR</filename></ulink>
-                directory and then builds and launches <filename>menuconfig</filename>:
-                <literallayout class='monospaced'>
-     $ bitbake linux-yocto -c menuconfig
-                </literallayout>
-            </para>
-                  
-            <para>
-                Once <filename>menuconfig</filename> launches, navigate through the user interface
-                to find the <filename>CONFIG_SMP</filename> configuration setting.
-                You can find it at <filename>Processor Type and Features</filename>.
-                The configuration selection is 
-                <filename>Symmetric Multi-processing Support</filename>.
-                After using the arrow keys to highlight this selection, press "n" to turn it off.
-                Then, exit out and save your selections.
-            </para>
-
-            <para>
-                Once you save the selection, the <filename>.config</filename> configuration file
-                is updated. 
-                This is the file that the build system uses to configure the Yocto Project kernel
-                when it is built. 
-                You can find and examine this file in the build directory. 
-                This example uses the following:
-                <literallayout class='monospaced'>
-     ~/poky/build/tmp/work/qemux86-poky-linux/linux-yocto-3.2.11+git1+84f...
-        ...656ed30-r1/linux-qemux86-standard-build
-                </literallayout>
-                <note>
-                    The previous example directory is artificially split and many of the characters 
-                    in the actual filename are omitted in order to make it more readable.
-                    Also, depending on the kernel you are using, the exact pathname might differ 
-                    slightly.
-                </note>
-            </para>
-
-            <para>
-                Within the <filename>.config</filename> file, you can see the following setting:
-                <literallayout class='monospaced'>
-     # CONFIG_SMP is not set
-                </literallayout>
-            </para>
-
-            <para>
-                A good method to isolate changed configurations is to use a combination of the 
-                <filename>menuconfig</filename> tool and simple shell commands.
-                Before changing configurations with <filename>menuconfig</filename>, copy the 
-                existing <filename>.config</filename> and rename it to something else,
-                use <filename>menuconfig</filename> to make 
-                as many changes an you want and save them, then compare the renamed configuration 
-                file against the newly created file.
-                You can use the resulting differences as your base to create configuration fragments
-                to permanently save in your kernel layer.
-                <note>
-                    Be sure to make a copy of the <filename>.config</filename> and don't just
-                    rename it. 
-                    The build system needs an existing <filename>.config</filename>
-                    from which to work.
-                </note>
-            </para>
-        </section>
-
-        <section id='recompiling-the-kernel-and-testing-the-new-configuration'>
-            <title>Recompiling the Kernel and Testing the New Configuration</title>
-
-            <para>
-                At this point, you are ready to recompile your kernel image with 
-                the new setting in effect using the BitBake command below:
-                <literallayout class='monospaced'>
-     $ bitbake linux-yocto
-                </literallayout>
-            </para>
- 
-            <para>
-                Now run the QEMU emulator and pass it the same multi-processor option as before:
-                <literallayout class='monospaced'>
-     $ runqemu qemux86 qemuparams="-smp 4"
-                </literallayout>
-            </para>
-
-            <para>
-                Login to the machine using <filename>root</filename> with no password
-                and test for the number of processors the kernel supports:
-                <literallayout class='monospaced'>
-     # cat /proc/cpuinfo | grep processor 
-     processor       : 0
-     #
-                </literallayout>
-            </para>
-
-            <para>
-                From the output, you can see that the kernel no longer supports multi-processor systems.
-                The output indicates support for a single processor.  You can verify the 
-                <filename>CONFIG_SMP</filename> setting by using this command:
-                <literallayout class='monospaced'>
-     zcat /proc/config.gz | grep CONFIG_SMP
-                </literallayout>
-                The console returns the following output:
-                <literallayout class='monospaced'>
-     # CONFIG_SMP is not set
-                </literallayout>
-                You have successfully reconfigured the kernel.
-            </para>
-        </section>
-    </section>
-
-    <section id='adding-kernel-recipes'>
-        <title>Adding Kernel Recipes</title>
-
-        <para>
-            A future release of this manual will present an example that adds kernel recipes, which provide 
-            new functionality to the kernel.
-        </para>
-
-        <para>
-            <imagedata fileref="figures/wip.png" 
-                width="2in" depth="3in" align="center" scalefit="1" />
-        </para> 
-    </section> 
 </appendix>
 
 <!--

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

@@ -8,15 +8,15 @@
 
 <para>
     Many development models exist for which you can use the Yocto Project. 
-    This chapter overviews the following methods:
+    This chapter overviews simple methods that use tools provided by the 
+    Yocto Project:
     <itemizedlist>
         <listitem><para><emphasis>System Development:</emphasis>
              System Development covers Board Support Package (BSP) development and kernel 
              modification or configuration.
-             If you want to examine specific examples of the system development models, 
-             see the "<link linkend='dev-manual-bsp-appendix'>BSP Development Example</link>" 
-             appendix and the 
-             "<link linkend='dev-manual-kernel-appendix'>Kernel Modification Example</link>" appendix.
+             For an example on how to create a BSP, see the 
+             "<ulink url='&YOCTO_DOCS_BSP_URL;#creating-a-new-bsp-layer-using-the-yocto-bsp-script'>Creating a New BSP Layer Using the yocto-bsp Script</ulink>"
+             section in the Yocto Project Board Support Package (BSP) Developer's Guide.
              </para></listitem>
          <listitem><para><emphasis>User Application Development:</emphasis>
              User Application Development covers development of applications that you intend 
@@ -80,9 +80,11 @@
 
         <para>
             The remainder of this section presents the basic steps used to create a BSP 
-            based on an existing BSP that ships with the Yocto Project.
-            You can reference the "<link linkend='dev-manual-bsp-appendix'>BSP Development Example</link>"
-            appendix for a detailed example that uses the Crown Bay BSP as a base BSP from which to start.
+            using the Yocto Project's 
+            <ulink url='&YOCTO_DOCS_BSP_URL;#using-the-yocto-projects-bsp-tools'>BSP Tools</ulink>.
+            For an example that shows how to create a new layer using the tools, see the
+            "<ulink url='&YOCTO_DOCS_BSP_URL;#creating-a-new-bsp-layer-using-the-yocto-bsp-script'>Creating a New BSP Layer Using the yocto-bsp Script</ulink>"
+             section in the Yocto Project Board Support Package (BSP) Developer's Guide.
         </para>
 
         <para>
@@ -106,39 +108,26 @@
                     Directory</link> available on your host system. 
                     Having these files on your system gives you access to the build
                     process and to the tools you need.
-                    For information on how to set up the Source Directory, see the
+                    For information on how to set up the 
+                    <link linkend='source-directory'>Source Directory</link>, see the
                     "<link linkend='getting-setup'>Getting Setup</link>" section.</para></listitem>
-                <listitem><para><emphasis>Establish a local copy of the base BSP files</emphasis>:  Having    
-                    the BSP files on your system gives you access to the build
+                <listitem><para><emphasis>Establish the <filename>meta-intel</filename>
+                    repository on your system</emphasis>:  Having local copies of the 
+                    supported BSP layers on your system gives you access to the build
                     process and to the tools you need for creating a BSP.
                     For information on how to get these files, see the
                     "<link linkend='getting-setup'>Getting Setup</link>" section.</para></listitem>    
-                <listitem><para><emphasis>Choose a BSP that is supported by the Yocto Project 
-                    as your base BSP</emphasis>:  
-                    The Yocto Project ships with several BSPs that support various hardware.  
-                    It is best to base your new BSP on an existing BSP rather than create all the 
-                    recipes and configuration files from scratch.  
-                    While it is possible to create everything from scratch, basing your new BSP 
-                    on something that is close is much easier.  
-                    Or, at a minimum, leveraging off an existing BSP
-                    gives you some structure with which to start.</para>
-                    <para>At this point you need to understand your target hardware well enough to determine which 
-                    existing BSP it most closely matches.  
-                    Things to consider are your hardware’s on-board features, such as CPU type and graphics support.  
-                    You should look at the README files for supported BSPs to get an idea of which one 
-                    you could use.  
-                    A generic <trademark class='registered'>Intel</trademark> 
-                    <trademark class='trade'>Atom</trademark>-based BSP to consider is the 
-                    Crown Bay that does not support the <trademark class='registered'>Intel</trademark> 
-                    Embedded Media Graphics Driver (EMGD).  
-                    The remainder of this example uses that base BSP.</para>
-                    <para>To see the supported BSPs, go to the 
-                    <ulink url='&YOCTO_HOME_URL;/download'>Downloads</ulink> page on the Yocto Project
-                    website and click on “BSP Downloads.”</para></listitem>
-                <listitem><para><emphasis>Create your own BSP layer</emphasis>:  Layers are ideal for 
+                <listitem><para><emphasis>Create your own BSP layer using the 
+                    <ulink url='&YOCTO_DOCS_BSP_URL;#creating-a-new-bsp-layer-using-the-yocto-bsp-script'><filename>yocto-bsp</filename></ulink> script</emphasis>:  
+                    Layers are ideal for 
                     isolating and storing work for a given piece of hardware.  
                     A layer is really just a location or area in which you place the recipes for your BSP.
-                    In fact, a BSP is, in itself, a special type of layer.   
+                    In fact, a BSP is, in itself, a special type of layer.
+                    The simplest way to create a new BSP layer that is compliant with the 
+                    Yocto Project is to use the <filename>yocto-bsp</filename> script. 
+                    For information about that script, see the 
+                    "<ulink url='&YOCTO_DOCS_BSP_URL;#creating-a-new-bsp-layer-using-the-yocto-bsp-script'>Creating a New BSP Layer Using the yocto-bsp Script</ulink>" 
+                    section in the Yocto Project Board Support (BSP) Developer's Guide.   
                     </para>
                     <para>
                     Another example that illustrates a layer is an application.  
@@ -170,25 +159,34 @@
                     section of the Board Support Package (BSP) Development Guide.  
                     In the standard layout, you will notice a suggested structure for recipes and  
                     configuration information.  
-                    You can see the standard layout for the Crown Bay BSP in this example by examining the 
-                    directory structure of the <filename>meta-crownbay</filename> layer inside the 
-                    Source Directory.</para></listitem>
+                    You can see the standard layout for a BSP by examining 
+                    any supported BSP found in the <filename>meta-intel</filename> layer inside
+                    the Source Directory.</para></listitem>
                 <listitem><para><emphasis>Make configuration changes to your new BSP 
                     layer</emphasis>:  The standard BSP layer structure organizes the files you need 
                     to edit in <filename>conf</filename> and several <filename>recipes-*</filename>
                     directories within the BSP layer.
                     Configuration changes identify where your new layer is on the local system
                     and identify which kernel you are going to use.
+                    When you run the <filename>yocto-bsp</filename> script you are able to interactively
+                    configure many things for the BSP (e.g. keyboard, touchscreen, and so forth).
                     </para></listitem>
                 <listitem><para><emphasis>Make recipe changes to your new BSP layer</emphasis>:  Recipe 
                     changes include altering recipes (<filename>.bb</filename> files), removing 
-                    recipes you don't use, and adding new recipes that you need to support your hardware.
+                    recipes you don't use, and adding new recipes or append files 
+                    (<filename>.bbappend</filename>) that you need to support your hardware.
                     </para></listitem>
                 <listitem><para><emphasis>Prepare for the build</emphasis>:  Once you have made all the 
                     changes to your BSP layer, there remains a few things 
                     you need to do for the OpenEmbedded build system in order for it to create your image.  
                     You need to get the build environment ready by sourcing an environment setup script 
-                    and you need to be sure two key configuration files are configured appropriately.</para>
+                    and you need to be sure two key configuration files are configured appropriately:
+                    the <filename>conf/local.conf</filename> and the 
+                    <filename>conf/bblayers.conf</filename> file.
+                    You must make the OpenEmbedded build system aware of your new layer.
+                    See the 
+                    "<link linkend='enabling-your-layer'>Enabling Your Layer</link>" section
+                    for information on how to let the build system know about your new layer.</para>
                     <para>The entire process for building an image is overviewed in the section
                     "<ulink url='&YOCTO_DOCS_QS_URL;#building-image'>Building an Image</ulink>" section 
                     of the Yocto Project Quick Start.    
@@ -234,9 +232,11 @@
             kernel architecture and the steps to modify the kernel.
             For a complete discussion of the kernel, see the
             <ulink url='&YOCTO_DOCS_KERNEL_URL;'>Yocto Project Kernel Architecture and Use Manual</ulink>.
-            You can reference the appendix 
-            "<link linkend='dev-manual-kernel-appendix'>Kernel Modification Example</link>"
-            for a detailed example that changes the configuration of a kernel.
+            You can reference the  
+            "<link linkend='patching-the-kernel'>Patching the Kernel</link>" section
+            for an example that changes the source code of the kernel.
+            For information on how to configure the kernel, see the 
+            "<link linkend='configuring-the-kernel'>Configuring the Kernel</link>" section.
         </para>
 
         <section id='kernel-overview'>
@@ -323,8 +323,8 @@
             </note>
 
             <para>
-                Storage of all the available kernel source code is one thing, while representing the 
-                code on your host development system is another.  
+                Upstream storage of all the available kernel source code is one thing, while 
+                representing and using the code on your host development system is another.  
                 Conceptually, you can think of the kernel source repositories as all the 
                 source files necessary for all the supported kernels. 
                 As a developer, you are just interested in the source files for the kernel on 
@@ -333,57 +333,35 @@
             </para>
 
             <para>
-                You make kernel source code available on your host development system by using 
-                Git to create a bare clone of the Yocto Project kernel Git repository 
-                in which you are interested.
-                Then, you use Git again to clone a copy of that bare clone.  
-                This copy represents the directory structure on your host system that is particular
-                to the kernel you want.  
-                The files in the copy of the bare clone are the files you actually modify 
-                to change the kernel.
-                See the <link linkend='local-kernel-files'>Yocto Project Kernel</link> item earlier
-                in this manual for an example of how to set up the kernel source directory
-                structure on your host system.
-            </para>
-
-            <para>
-                This next figure illustrates how the kernel source files might be arranged on 
-                your host system.
-            </para>
-
-            <para>
-                <imagedata fileref="figures/kernel-overview-3-denzil.png" 
-                    width="6in" depth="4in" align="center" scale="100" />
-            </para> 
-
-            <para>
-                In the previous figure, the file structure on the left represents the bare clone 
-                set up to track the Yocto Project kernel Git repository. 
-                The structure on the right represents the copy of the bare clone. 
-                When you make modifcations to the kernel source code, this is the area in which 
-                you work.
-                Once you make corrections, you must use Git to push the committed changes to the 
-                bare clone.
-                The example in <xref linkend='modifying-the-kernel-source-code'>
-                Modifying the Kernel Source Code</xref> provides a detailed example.
+                Kernel source code is available on your host system a couple of different
+                ways.
+                If you are working in the kernel all the time, you probably would want
+                to set up your own local Git repository of the kernel tree.
+                If you just need to make some patches to the kernel, you can get at 
+                temporary kernel source files extracted and used during the OpenEmbedded
+                build system. 
+                We will just talk about working with the temporary source code.
             </para>
 
             <para>
                 What happens during the build?  
                 When you build the kernel on your development system, all files needed for the build
                 are taken from the source repositories pointed to by the 
-                <filename>SRC_URI</filename> variable and gathered in a temporary work area
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink> variable 
+                and gathered in a temporary work area
                 where they are subsequently used to create the unique kernel.
                 Thus, in a sense, the process constructs a local source tree specific to your 
                 kernel to generate the new kernel image - a source generator if you will.
             </para>
                 The following figure shows the temporary file structure
                 created on your host system when the build occurs. 
-                This build directory contains all the source files used during the build.
+                This 
+                <link linkend='build-directory'>Build Directory</link> contains all the 
+                source files used during the build.
             </para>
 
             <para>
-                <imagedata fileref="figures/kernel-overview-2.png" 
+                <imagedata fileref="figures/kernel-overview-2-generic.png" 
                     width="6in" depth="5in" align="center" scale="100" />
             </para> 
 
@@ -392,7 +370,7 @@
                 branching strategy, see the
                 <ulink url='&YOCTO_DOCS_KERNEL_URL;'>Yocto Project Kernel Architecture and Use Manual</ulink>.
                 You can also reference the
-                "<link linkend='modifying-the-kernel-source-code'>Modifying the Kernel Source Code</link>"
+                "<link linkend='patching-the-kernel'>Patching the Kernel</link>"
                 section for a detailed example that modifies the kernel.
             </para>
         </section> 
@@ -406,7 +384,7 @@
 
             <para>
                 <imagedata fileref="figures/kernel-dev-flow.png" 
-                    width="6in" depth="7.5in" align="center" scalefit="1" />
+                    width="6in" depth="5in" align="center" scalefit="1" />
             </para> 
 
             <para>
@@ -417,56 +395,52 @@
                         "<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 project files on your 
-                        system</emphasis>:  Having the <link linkend='source-directory'>source
-                        directory</link> on your system gives you access to the build process and tools 
+                        system</emphasis>:  Having the <link linkend='source-directory'>Source
+                        Directory</link> on your system gives you access to the build process and tools 
                         you need.
                         For information on how to get these files, see the bulleted item
                         "<link linkend='local-yp-release'>Yocto Project Release</link>" earlier in this manual.
                         </para></listitem>
-                    <listitem><para><emphasis>Set up a local copy of the <filename>poky-extras</filename> Git 
-                        repository</emphasis>:  This local repository is the area for your configuration 
-                        fragments, new kernel recipes, and the kernel <filename>.bbappend</filename>
-                        file used during the build. 
-                        It is good practice to set this repository up inside your local 
-                        <link linkend='source-directory'>Source Directory</link>.
-                        For information on how to get these files, see the bulleted item
-                        "<link linkend='poky-extras-repo'>The <filename>poky-extras</filename> Git Repository</link>"
-                        earlier in this manual.
-                        <note>While it is certainly possible to modify the kernel without involving
-                            a local Git repository, the suggested workflow for kernel modification
-                            using the Yocto Project does use a Git repository.</note></para></listitem>
-                    <listitem><para><emphasis>Establish a local copy of the Yocto Project kernel files on your 
-                        system</emphasis>:  In order to make modifications to the kernel you need two things:
-                        a bare clone of the Yocto Project kernel you are modifying and  
-                        a copy of that bare clone. 
-                        The bare clone is required by the build process and is the area to which you 
-                        push your kernel source changes (pulling does not work with bare clones). 
-                        The copy of the bare clone is a local Git repository that contains all the kernel's 
-                        source files. 
-                        You make your changes to the files in this copy of the bare clone.
-                        For information on how to set these two items up, see the bulleted item
-                        "<link linkend='local-kernel-files'>Yocto Project Kernel</link>" 
-                        earlier in this manual.</para></listitem>
+                    <listitem><para><emphasis>Establish the temporary kernel source files</emphasis>:  
+                        Temporary kernel source files are kept in the Build Directory created by the 
+                        OpenEmbedded build system when you run BitBake.
+                        If you have never built the kernel you are interested in, you need to run 
+                        an initial build to establish local kernel source files.</para>
+                        <para>If you are building an image for the first time, you need to get the build 
+                        environment ready by sourcing 
+                        the environment setup script.
+                        You also need to be sure two key configuration files 
+                        (<filename>local.conf</filename> and <filename>bblayers.conf</filename>)
+                        are configured appropriately.</para>
+                        <para>The entire process for building an image is overviewed in the 
+                        "<ulink url='&YOCTO_DOCS_QS_URL;#building-image'>Building an Image</ulink>" 
+                        section of the Yocto Project Quick Start.    
+                        You might want to reference this information.
+                        You can find more information on BitBake in the user manual, which is found in the
+                        <filename>bitbake/doc/manual</filename> directory of the 
+                        <link linkend='source-directory'>Source Directory</link>.</para>
+                        <para>The build process supports several types of images to satisfy different needs.  
+                        See the "<ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Images</ulink>" chapter in 
+                        the Yocto Project Reference Manual for information on supported images.
+                        </para></listitem>
                     <listitem><para><emphasis>Make changes to the kernel source code if 
                         applicable</emphasis>:  Modifying the kernel does not always mean directly
                         changing source files. 
-                        However, if you have to do this, you make the changes in the local 
-                        Git repository you set up to hold the source files (i.e. the copy of the 
-                        bare clone).
-                        Once the changes are made, you need to use Git commands to commit the changes
-                        and then push them to the bare clone.</para></listitem>                      
+                        However, if you have to do this, you make the changes to the files in the 
+                        Build directory.</para></listitem>                      
                     <listitem><para><emphasis>Make kernel configuration changes
                         if applicable</emphasis>:  
                         If your situation calls for changing the kernel's configuration, you can 
-                        use <filename>menuconfig</filename>
+                        use the <filename>yocto-kernel</filename> script or <filename>menuconfig</filename>
                         to enable and disable kernel configurations.  
+                        Using the script lets you interactively set up kernel configurations.
                         Using <filename>menuconfig</filename> allows you to interactively develop and test the 
                         configuration changes you are making to the kernel.
                         When saved, changes using <filename>menuconfig</filename> update the kernel's
                         <filename>.config</filename>.
                         Try to resist the temptation of directly editing the <filename>.config</filename> 
                         file found in the 
-                        <link linkend='build-directory'>build directory</link> at 
+                        <link linkend='build-directory'>Build Directory</link> at 
                         <filename>tmp/sysroots/&lt;machine-name&gt;/kernel</filename>.
                         Doing so, can produce unexpected results when the OpenEmbedded build system 
                         regenerates the configuration file.</para>
@@ -475,55 +449,8 @@
                         <filename>.config</filename> file against a saved original and gather those
                         changes into a config fragment to be referenced from within the kernel's   
                         <filename>.bbappend</filename> file.</para></listitem>                      
-                    <listitem><para><emphasis>Add or extend kernel recipes if applicable</emphasis>:  
-                        The standard 
-                        layer structure organizes recipe files inside the 
-                        <filename>meta-kernel-dev</filename> layer that is within the local
-                        <filename>poky-extras</filename> Git repository.
-                        If you need to add new kernel recipes, you add them within this layer. 
-                        Also within this area, you will find the <filename>.bbappend</filename> 
-                        file that appends information to the kernel's recipe file used during the 
-                        build.
-                        </para></listitem>
-                    <listitem><para><emphasis>Prepare for the build</emphasis>:  Once you have made all the 
-                        changes to your kernel (configurations, source code changes, recipe additions, 
-                        or recipe changes), there remains a few things 
-                        you need to do in order for the build system to create your image.  
-                        If you have not done so, you need to get the build environment ready by sourcing 
-                        the environment setup script described earlier.
-                        You also need to be sure two key configuration files 
-                        (<filename>local.conf</filename> and <filename>bblayers.conf</filename>)
-                        are configured appropriately.</para>
-                        <para>The entire process for building an image is overviewed in the 
-                        "<ulink url='&YOCTO_DOCS_QS_URL;#building-image'>Building an Image</ulink>" 
-                        section of the Yocto Project Quick Start.    
-                        You might want to reference this information.
-                        Also, you should look at the detailed examples found in the appendices at 
-                        at the end of this manual.</para></listitem>
-                    <listitem><para><emphasis>Build the image</emphasis>:  The OpenEmbedded 
-                        build system uses the BitBake 
-                        tool to build images based on the type of image you want to create.  
-                        You can find more information on BitBake in the user manual, which is found in the
-                        <filename>bitbake/doc/manual</filename> directory of the 
-                        <link linkend='source-directory'>Source Directory</link>.</para>
-                        <para>The build process supports several types of images to satisfy different needs.  
-                        See the "<ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Images</ulink>" chapter in 
-                        the Yocto Project Reference Manual for information on supported images.</para></listitem>
-                    <listitem><para><emphasis>Make your configuration changes available
-                        in the kernel layer</emphasis>:  Up to this point, all the configuration changes to the 
-                        kernel have been done and tested iteratively.  
-                        Once they are tested and ready to go, you can move them into the kernel layer, 
-                        which allows you to distribute the layer.</para></listitem>
-                    <listitem><para><emphasis>If applicable, share your in-tree changes</emphasis>:  
-                        If the changes you made
-                        are suited for all Yocto Project kernel users, you might want to send them on 
-                        for inclusion into the upstream kernel's Git repository. 
-                        If the changes are accepted, the Yocto Project Maintainer pulls them into 
-                        the master branch of the kernel tree. 
-                        Doing so makes them available to everyone using the kernel.</para>
-                        <para>For information on how to submit a change to the Yocto Project, see the
-                        "<link linkend='how-to-submit-a-change'>How to Submit a Change</link>" section
-                        earlier in this manual.</para></listitem> 
+                    <listitem><para><emphasis>Rebuild the kernel image with your changes</emphasis>:  
+                        Rebuilding the kernel image applies your changes.</para></listitem>
                 </orderedlist>
             </para>
         </section>
@@ -600,8 +527,8 @@
                                 If your target architecture is similar to a supported architecture, you can 
                                 modify the kernel image before you build it.
                                 See the 
-                                "<link linkend='dev-manual-kernel-appendix'>Kernel Modification Example</link>"
-                                appendix later in this manual for an example.</para></listitem>
+                                "<link linkend='patching-the-kernel'>Patching the Kernel</link>"
+                                section for an example.</para></listitem>
                         </itemizedlist></para>
                     <para>For information on pre-built kernel image naming schemes for images 
                     that can run on the QEMU emulator, see the
@@ -654,7 +581,7 @@
                     </para></listitem>                      
                 <listitem><para><emphasis>Test and Debug the Application</emphasis>:  
                     Once your application is deployed, you need to test it.
-                    Within the Eclipse IDE, you can use the debubbing environment along with the 
+                    Within the Eclipse IDE, you can use the debugging environment along with the 
                     set of user-space tools installed along with the ADT to debug your application. 
                     Of course, the same user-space tools are available separately if you choose
                     not to use the Eclipse IDE.</para></listitem>
@@ -1060,10 +987,10 @@
                                        <listitem><para><emphasis>
                                             <filename>Build System Derived Toolchain:</filename></emphasis> 
                                             Select this mode if the cross-toolchain has been installed and built 
-                                            as part of the build directory.  
+                                            as part of the Build Directory.  
                                             When you select <filename>Build system derived toolchain</filename>,
                                             you are using the toolchain bundled 
-                                            inside the build directory.
+                                            inside the Build Directory.
                                             </para></listitem>
                                     </itemizedlist>
                                 </para></listitem>
@@ -1082,9 +1009,9 @@
                                 However, doing so is discouraged.</note></para>
                                 <para>If you are using a system-derived toolchain, the path you provide 
                                 for the <filename>Toolchain Root Location</filename>
-                                field is the build directory.
+                                field is the Build Directory.
                                 See the "<ulink url='&YOCTO_DOCS_ADT_URL;#using-the-toolchain-from-within-the-build-tree'>Using 
-                                BitBake and the build directory</ulink>" section in the Yocto Project Application
+                                BitBake and the Build Directory</ulink>" section in the Yocto Project Application
                                 Developer's Guide for information on how to install the toolchain into the build 
 directory.</para></listitem> 
                             <listitem><para><emphasis>Specify the Sysroot Location:</emphasis>
@@ -1127,7 +1054,7 @@ directory.</para></listitem>
                                 and specify any custom options.</para>
                                 <para>If you selected <filename>Build system derived toolchain</filename>, 
                                 the target kernel you built will be located in the 
-                                build directory in <filename>tmp/deploy/images</filename> directory.   
+                                Build Directory in <filename>tmp/deploy/images</filename> directory.   
                                 If you selected <filename>Standalone pre-built toolchain</filename>, the 
                                 pre-built image you downloaded is located 
                                 in the directory you specified when you downloaded the image.</para>
@@ -1345,44 +1272,48 @@ directory.</para></listitem>
                         <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 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/documentation'></ulink>.</para>
-                        <para>For <filename>Application</filename>, you must supply the absolute path name of the 
-                        application to be traced by user mode <filename>lttng</filename>.  
-                        For example, typing <filename>/path/to/foo</filename> triggers 
-                        <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>
-                        <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.
+                    <listitem><para><emphasis><filename>Lttng2.0 ust trace import</filename>:</emphasis> 
+                        Selecting this tool transfers the remote target's 
+                        <filename>Lttng</filename> tracing 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/documentation'></ulink>.
+                        <note>Do not use <filename>Lttng-user space (legacy)</filename> tool.
+                            This tool no longer has any upstream support.</note>
+                        </para>
+                        <para>Before you use the <filename>Lttng2.0 ust trace import</filename> tool, 
+                        you need to setup the <filename>Lttng</filename> Eclipse plug-in and create a 
+                        <filename>Tracing</filename> project.
                         Do the following:
                         <orderedlist>
-                            <listitem><para>Follow the instructions from the  
-                                <ulink url='http://wiki.eclipse.org/Linux_Tools_Project/LTTng2/User_Guide'>Linux Tools Projec/LTTng2/User Guide</ulink>
-                                to download and install the <filename>lttng</filename> parser library.
-                                </para></listitem>
                             <listitem><para>Select <filename>Window -> Open Perspective -> Other</filename>
-                                and then select <filename>LTTng</filename>.</para></listitem>
+                                and then select <filename>Tracing</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 
+                                into the <filename>Tracing</filename> perspective.</para></listitem>
+                            <listitem><para>Create a new <filename>Tracing</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>Choose <filename>Tracing -> Tracing Project</filename>.
+                                </para></listitem>
+                            <listitem><para>Generate your tracing data on the remote target.
+                                </para></listitem>
+                            <listitem><para>Click 
+                                <filename>Yocto Project Tools -> Lttng2.0 ust trace import</filename>
+                                to start the data import process.</para></listitem>
+                            <listitem><para>Specify your remote connection name.</para></listitem>
+                            <listitem><para>For the Ust directory path, specify the location of 
+                                your remote tracing data.
+                                Make sure the location ends with <filename>ust</filename> (e.g. 
+                                <filename>/usr/mysession/ust</filename>.</para></listitem>
+                            <listitem><para>Click <filename>OK</filename> to complete the import process.
+                                The data is now in the local tracing project you created.</para></listitem>
+                            <listitem><para>Right click on the data and then use the menu to 
+                                <filename>Select Trace Type... -> Common Trace Format -> Generic CTF Trace</filename> 
+                                to map the tracing type.</para></listitem>
+                            <listitem><para>Right click the mouse and select <filename>Open</filename>
+                                to bring up the Eclipse <filename>Lttng</filename> Trace Viewer so you 
+                                view the tracing data.</para></listitem>
+                        </orderedlist></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>
@@ -1457,7 +1388,7 @@ directory.</para></listitem>
                             to open a new recipe wizard.</para></listitem>
                         <listitem><para>Point to your source by filling in the "SRC_URL" field.
                             For example, you can add a recipe to your 
-                            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+                            <link linkend='source-directory'>Source Directory</link>
                             by defining "SRC_URL" as follows:
                             <literallayout class='monospaced'>
      ftp://ftp.gnu.org/gnu/m4/m4-1.4.9.tar.gz
@@ -1479,7 +1410,7 @@ directory.</para></listitem>
                     <orderedlist>
                         <listitem><para>Select your Yocto Bitbake Commander project.</para></listitem>
                         <listitem><para>Select <filename>Project -> Launch HOB</filename>.</para></listitem>
-                        <listitem><para>Enter the build directory where you want to put your final images.</para></listitem>
+                        <listitem><para>Enter the Build Directory where you want to put your final images.</para></listitem>
                         <listitem><para>Click <filename>OK</filename> to launch Hob.</para></listitem>
                         <listitem><para>Use Hob to customize and build your own images. 
                             For information on Hob, see the 
@@ -1550,7 +1481,7 @@ directory.</para></listitem>
         to figure out your solution.
         After you have initially built the package, you can iteratively tweak the 
         source code, which is located in the 
-        <link linkend='build-directory'>build directory</link>, and then 
+        <link linkend='build-directory'>Build Directory</link>, and then 
         you can force a re-compile and quickly test your altered code.
         Once you settle on a solution, you can then preserve your changes in the form of 
         patches.
@@ -1564,7 +1495,7 @@ directory.</para></listitem>
 
         <para>
             During a build, the unpacked temporary source code used by recipes 
-            to build packages is available in the build directory as 
+            to build packages is available in the Build Directory as 
             defined by the 
             <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-S'>S</ulink></filename> variable.
             Below is the default value for the <filename>S</filename> variable as defined in the 
@@ -1598,7 +1529,7 @@ directory.</para></listitem>
             Let's look at an example without variables.
             Assuming a top-level <link linkend='source-directory'>Source Directory</link>
             named <filename>poky</filename>
-            and a default build directory of <filename>poky/build</filename>, 
+            and a default Build Directory of <filename>poky/build</filename>, 
             the following is the work directory for the <filename>acl</filename> recipe that 
             creates the <filename>acl</filename> package:
             <literallayout class='monospaced'>
@@ -1613,11 +1544,13 @@ directory.</para></listitem>
      ${TMPDIR}/work/${MACHINE}-poky-${TARGET_OS}/${PN}-${PV}-${PR}
             </literallayout>
             Again, assuming top-level Source Directory named <filename>poky</filename>
-            and a default build directory of <filename>poky/build</filename>, the 
-            following is the work directory for the <filename>acl</filename> package that is being 
+            and a default Build Directory of <filename>poky/build</filename>, the 
+            following are the work and temporary source directories, respectively,
+            for the <filename>acl</filename> package that is being 
             built for a MIPS-based device:
             <literallayout class='monospaced'>
      ~/poky/build/tmp/work/mips-poky-linux/acl-2.2.51-r2
+     ~/poky/build/tmp/work/mips-poky-linux/acl-2.2.51-r2/acl-2.2.51
             </literallayout>
         </para>
 
@@ -1659,7 +1592,7 @@ directory.</para></listitem>
             <orderedlist>
                 <listitem><para><emphasis>Find the Source Code:</emphasis>
                     The temporary source code used by the OpenEmbedded build system is kept in the 
-                    build directory.  
+                    Build Directory.  
                     See the 
                     "<link linkend='finding-the-temporary-source-code'>Finding the Temporary Source Code</link>"
                     section to learn how to locate the directory that has the temporary source code for a 
@@ -1667,7 +1600,7 @@ directory.</para></listitem>
                 <listitem><para><emphasis>Change Your Working Directory:</emphasis>
                     You need to be in the directory that has the temporary source code.
                     That directory is defined by the 
-                    <ulink url='&YOCTO_DOCS_REF_URL;#var-S'>S</ulink>
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-S'><filename>S</filename></ulink>
                     variable.</para></listitem>
                 <listitem><para><emphasis>Create a New Patch:</emphasis>
                     Before modifying source code, you need to create a new patch.
@@ -1676,14 +1609,16 @@ directory.</para></listitem>
      $ quilt new my_changes.patch
                     </literallayout></para></listitem>
                 <listitem><para><emphasis>Notify Quilt and Add Files:</emphasis>
-                    After creating the patch, you need to notify Quilt about the files you will 
-                    be changing.
-                    Add the files you will be modifying into the patch you just created:
+                    After creating the patch, you need to notify Quilt about the files 
+                    you plan to edit.
+                    You notify Quilt by adding the files to the patch you just created:
                     <literallayout class='monospaced'>
      $ quilt add file1.c file2.c file3.c
-                    </literallayout></para></listitem>
+                    </literallayout>
+                    </para></listitem>
                 <listitem><para><emphasis>Edit the Files:</emphasis>
-                    Make the changes to the temporary source code.</para></listitem>
+                    Make your changes in the temporary source code to the files you added
+                    to the patch.</para></listitem>
                 <listitem><para><emphasis>Test Your Changes:</emphasis>
                     Once you have modified the source code, the easiest way to test your changes 
                     is by calling the <filename>compile</filename> task as shown in the following example:
@@ -1715,7 +1650,9 @@ directory.</para></listitem>
                     subdirectory of the source (<filename>S</filename>) directory.</para></listitem>
                 <listitem><para><emphasis>Copy the Patch File:</emphasis> 
                     For simplicity, copy the patch file into a directory named <filename>files</filename>,
-                    which you can create in the same directory as the recipe.
+                    which you can create in the same directory that holds the recipe 
+                    (<filename>.bb</filename>) file or the 
+                    append (<filename>.bbappend</filename>) file.
                     Placing the patch here guarantees that the OpenEmbedded build system will find
                     the patch.
                     Next, add the patch into the  
@@ -1753,7 +1690,7 @@ directory.</para></listitem>
             <orderedlist>
                 <listitem><para><emphasis>Find the Source Code:</emphasis>
                     The temporary source code used by the OpenEmbedded build system is kept in the 
-                    build directory.  
+                    Build Directory.  
                     See the 
                     "<link linkend='finding-the-temporary-source-code'>Finding the Temporary Source Code</link>"
                     section to learn how to locate the directory that has the temporary source code for a 
@@ -1761,30 +1698,24 @@ directory.</para></listitem>
                 <listitem><para><emphasis>Change Your Working Directory:</emphasis>
                     You need to be in the directory that has the temporary source code.
                     That directory is defined by the 
-                    <ulink url='&YOCTO_DOCS_REF_URL;#var-S'>S</ulink>
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-S'><filename>S</filename></ulink>
                     variable.</para></listitem>
-                <listitem><para><emphasis>Initialize a Git Repository:</emphasis>
-                    Use the <filename>git init</filename> command to initialize a new local repository
-                    that is based on the work directory:
+                <listitem><para><emphasis>If needed, initialize a Git Repository:</emphasis>
+                    If the recipe you are working with does not use a Git fetcher, 
+                    you need to set up a Git repository as follows:
                     <literallayout class='monospaced'>
      $ git init
-                    </literallayout></para></listitem>
-                <listitem><para><emphasis>Stage all the files:</emphasis>
-                    Use the <filename>git add *</filename> command to stage all the files in the source
-                    code directory so that they can be committed:
-                    <literallayout class='monospaced'>
      $ git add *
-                    </literallayout></para></listitem>
-                <listitem><para><emphasis>Commit the Source Files:</emphasis>
-                    Use the <filename>git commit</filename> command to initially commit all the files in 
-                    the work directory:
-                    <literallayout class='monospaced'>
-     $ git commit
+     $ git commit -m "initial revision"
                     </literallayout>
+                    The above Git commands initialize a Git repository that is based on the 
+                    files in your current working directory, stage all the files, and commit
+                    the files. 
                     At this point, your Git repository is aware of all the source code files.
-                    Any edits you now make to files will be tracked by Git.</para></listitem>
+                    Any edits you now make to files can be committed later and will be tracked by 
+                    Git.</para></listitem>
                 <listitem><para><emphasis>Edit the Files:</emphasis>
-                    Make the changes to the temporary source code.</para></listitem>
+                    Make your changes to the temporary source code.</para></listitem>
                 <listitem><para><emphasis>Test Your Changes:</emphasis>
                     Once you have modified the source code, the easiest way to test your changes 
                     is by calling the <filename>compile</filename> task as shown in the following example:
@@ -1796,8 +1727,8 @@ directory.</para></listitem>
                     If you find problems with your code, you can just keep editing and 
                     re-testing iteratively until things work as expected.
                     <note>All the modifications you make to the temporary source code
-                    disappear once you <filename>-c clean</filename> or 
-                    <filename>-c cleanall</filename> with BitBake for the package.
+                    disappear once you <filename>-c clean</filename>, <filename>-c cleansstate</filename>,
+                    or <filename>-c cleanall</filename> with BitBake for the package.
                     Modifications will also disappear if you use the <filename>rm_work</filename>
                     feature as described in the
                     "<ulink url='&YOCTO_DOCS_QS_URL;#building-image'>Building an Image</ulink>" 
@@ -1823,25 +1754,30 @@ directory.</para></listitem>
                     Once you have committed the files, you can use the <filename>git log</filename>
                     command to see your changes:
                     <literallayout class='monospaced'>
-     $ git commit
+     $ git commit -m "&lt;commit-summary-message&gt;"
      $ git log
-                    </literallayout></para></listitem>
+                    </literallayout>
+                    <note>The name of the patch file created in the next step is based on your 
+                        <filename>commit-summary-message</filename>.</note></para></listitem>
                 <listitem><para><emphasis>Generate the Patch:</emphasis>
                     Once the changes are committed, use the <filename>git format-patch</filename>
                     command to generate a patch file:
                     <literallayout class='monospaced'>
-     $ git format-patch HEAD~1
+     $ git format-patch -1
                     </literallayout>
-                    The <filename>HEAD~1</filename> part of the command causes Git to generate the 
+                    Specifying "-1" causes Git to generate the 
                     patch file for the most recent commit.</para>
                     <para>At this point, the patch file has all your edits made 
                     to the <filename>file1.c</filename>, <filename>file2.c</filename>, and 
                     <filename>file3.c</filename> files.
-                    You can find the resulting patch file in the current directory.
+                    You can find the resulting patch file in the current directory and it 
+                    is named according to the <filename>git commit</filename> summary line.
                     The patch file ends with <filename>.patch</filename>.</para></listitem>
                 <listitem><para><emphasis>Copy the Patch File:</emphasis> 
                     For simplicity, copy the patch file into a directory named <filename>files</filename>,
-                    which you can create in the same directory as the recipe.
+                    which you can create in the same directory that holds the recipe 
+                    (<filename>.bb</filename>) file or the 
+                    append (<filename>.bbappend</filename>) file.
                     Placing the patch here guarantees that the OpenEmbedded build system will find
                     the patch.
                     Next, add the patch into the  
@@ -1849,7 +1785,7 @@ directory.</para></listitem>
                     of the recipe.  
                     Here is an example:
                     <literallayout class='monospaced'>
-     SRC_URI += "file://my_changes.patch"
+     SRC_URI += "file://0001-&lt;commit-summary-message&gt;.patch"
                     </literallayout></para></listitem>
                 <listitem><para><emphasis>Increment the Recipe Revision Number:</emphasis>
                     Finally, don't forget to 'bump' the 

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

@@ -130,7 +130,7 @@
         From the interface, you can click on any particular item in the "Name" column and 
         see the URL at the bottom of the page that you need to set up a Git repository for 
         that particular item.
-        Having a local Git repository of the source directory (poky) allows you to 
+        Having a local Git repository of the Source Directory (poky) allows you to 
         make changes, contribute to the history, and ultimately enhance the Yocto Project's 
         tools, Board Support Packages, and so forth.
     </para>
@@ -148,7 +148,7 @@
         <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 source directory that lets you develop 
+        Unpacking the tarball gives you a hierarchical Source Directory that lets you develop 
         using the Yocto Project.
     </para>
 
@@ -207,10 +207,9 @@
                 <filename>formfactor_0.0.bb</filename> and <filename>formfactor_0.0.bbappend</filename>).
                 </para>
                 <para>Information in append files overrides the information in the similarly-named recipe file.
-                For examples of <filename>.bbappend</filename> file in use, see the
-                "<link linkend='using-bbappend-files'>Using .bbappend Files</link>" and 
-                "<link linkend='changing-recipes-kernel'>Changing <filename>recipes-kernel</filename></link>"
-                sections.</para></listitem>
+                For an example of an append file in use, see the
+                "<link linkend='using-bbappend-files'>Using .bbappend Files</link>" section.
+                </para></listitem>
             <listitem><para id='bitbake-term'><emphasis>BitBake:</emphasis>
                 The task executor and scheduler used by 
                 the OpenEmbedded build system to build images. 
@@ -221,31 +220,31 @@
                 <para id='build-directory'><emphasis>Build Directory:</emphasis>
                 This term refers to the area used by the OpenEmbedded build system for builds.  
                 The area is created when you <filename>source</filename> the setup 
-                environment script that is found in the source directory
-                (i.e. <filename>oe-init-build-env</filename>).
+                environment script that is found in the Source Directory
+                (i.e. <filename>&OE_INIT_FILE;</filename>).
                 The <ulink url='&YOCTO_DOCS_REF_URL;#var-TOPDIR'><filename>TOPDIR</filename></ulink>
-                variable points to the build directory.</para>
+                variable points to the Build Directory.</para>
            
-                <para>You have a lot of flexibility when creating the build directory.
+                <para>You have a lot of flexibility when creating the Build Directory.
                 Following are some examples that show how to create the directory:
                    <itemizedlist>
-                        <listitem><para>Create the build directory in your current working directory
+                        <listitem><para>Create the Build Directory in your current working directory
                             and name it <filename>build</filename>.
                             This is the default behavior.
                             <literallayout class='monospaced'>
-     $ source oe-init-build-env
+     $ source &OE_INIT_PATH;
                             </literallayout></para></listitem>
                         <listitem><para>Provide a directory path and specifically name the build 
                             directory. 
-                            This next example creates a build directory named <filename>YP-&POKYVERSION;</filename>
+                            This next example creates a Build Directory named <filename>YP-&POKYVERSION;</filename>
                             in your home directory within the directory <filename>mybuilds</filename>.
                             If <filename>mybuilds</filename> does not exist, the directory is created for you:
                             <literallayout class='monospaced'> 
      $ source &OE_INIT_PATH; $HOME/mybuilds/YP-&POKYVERSION;
                             </literallayout></para></listitem>
-                        <listitem><para>Provide an existing directory to use as the build directory.
+                        <listitem><para>Provide an existing directory to use as the Build Directory.
                             This example uses the existing <filename>mybuilds</filename> directory 
-                            as the build directory.
+                            as the Build Directory.
                             <literallayout class='monospaced'> 
      $ source &OE_INIT_PATH; $HOME/mybuilds/
                             </literallayout></para></listitem>
@@ -255,7 +254,7 @@
                 this term refers to the OpenEmbedded build system used by the project. 
                 This build system is based on the project known as "Poky."
                 For some historical information about Poky, see the 
-                <link linkend='poky'>poky</link> term further along in this section.
+                <link linkend='poky'>Poky</link> term further along in this section.
                 </para></listitem>
             <listitem><para><emphasis>Classes:</emphasis> Files that provide for logic encapsulation
                 and inheritance allowing commonly used patterns to be defined once and easily used 
@@ -265,14 +264,14 @@
             <listitem><para><emphasis>Configuration File:</emphasis>  Configuration information in various
                 <filename>.conf</filename> files provides global definitions of variables.
                 The <filename>conf/local.conf</filename> configuration file in the 
-                <link linkend='build-directory'>build directory</link>
+                <link linkend='build-directory'>Build Directory</link>
                 contains user-defined variables that affect each build.
                 The <filename>meta-yocto/conf/distro/poky.conf</filename> configuration file
                 defines Yocto ‘distro’ configuration
                 variables used only when building with this policy.  
                 Machine configuration files, which 
                 are located throughout the 
-                <link linkend='source-directory'>source directory</link>, define
+                <link linkend='source-directory'>Source Directory</link>, define
                 variables for specific hardware and are only used when building for that target 
                 (e.g. the <filename>machine/beagleboard.conf</filename> configuration file defines 
                 variables for the Texas Instruments ARM Cortex-A8 development board).  
@@ -326,14 +325,14 @@
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-PE'><filename>PE</filename></ulink>).
                 </para></listitem>
             <listitem><para id='poky'><emphasis>Poky:</emphasis> The term "poky" can mean several things.
-                In its most general sence, it is an open-source project that was initially developed
+                In its most general sense, it is an open-source project that was initially developed
                 by OpenedHand.  With OpenedHand, poky was developed off of the existing OpenEmbedded
                 build system becoming a build system for embedded images. 
                 After Intel Corporation aquired OpenedHand, the project poky became the basis for 
                 the Yocto Project's build system.
                 Within the Yocto Project source repositories, poky exists as a separate Git repository
                 that can be cloned to yield a local copy on the host system. 
-                Thus, "poky" can refer to the local copy of the source directory used to develop within
+                Thus, "poky" can refer to the local copy of the Source Directory used to develop within
                 the Yocto Project.</para></listitem>
             <listitem><para><emphasis>Recipe:</emphasis> A set of instructions for building packages.  
                 A recipe describes where you get source code and which patches to apply.
@@ -350,15 +349,15 @@
                 Sometimes you might here the term "poky directory" used to refer to this 
                 directory structure.</para>
 
-                <para>The source directory contains BitBake, Documentation, metadata and 
+                <para>The Source Directory contains BitBake, Documentation, metadata and 
                 other files that all support the Yocto Project. 
-                Consequently, you must have the source directory in place on your development 
+                Consequently, you must have the Source Directory in place on your development 
                 system in order to do any development using the Yocto Project.</para>
 
-                <para>For tarball expansion, the name of the top-level directory of the source directory  
+                <para>For tarball expansion, the name of the top-level directory of the Source Directory  
                 is derived from the Yocto Project release tarball.
                 For example, downloading and unpacking <filename>&YOCTO_POKY_TARBALL;</filename>
-                results in a source directory whose top-level folder is named 
+                results in a Source Directory whose top-level folder is named 
                 <filename>&YOCTO_POKY;</filename>.
                 If you create a local copy of the Git repository, then you can name the repository 
                 anything you like.
@@ -367,15 +366,15 @@
                 So, for example, cloning the <filename>poky</filename> Git repository results in a 
                 local Git repository whose top-level folder is also named <filename>poky</filename>.</para>
 
-                <para>It is important to understand the differences between the source directory created
+                <para>It is important to understand the differences between the Source Directory created
                 by unpacking a released tarball as compared to cloning 
                 <filename>git://git.yoctoproject.org/poky</filename>.
                 When you unpack a tarball, you have an exact copy of the files based on the time of 
                 release - a fixed release point.
-                Any changes you make to your local files in the source directory are on top of the release.
+                Any changes you make to your local files in the Source Directory are on top of the release.
                 On the other hand, when you clone the <filename>poky</filename> Git repository, you have an
                 active development repository.
-                In this case, any local changes you make to the source directory can be later applied 
+                In this case, any local changes you make to the Source Directory can be later applied 
                 to active development branches of the upstream <filename>poky</filename> Git 
                 repository.</para>
 
@@ -439,7 +438,7 @@
         <filename>meta/files/common-licenses</filename>.  
         Once the build completes, the list of all licenses found and used during that build are 
         kept in the 
-        <link linkend='build-directory'>build directory</link> at 
+        <link linkend='build-directory'>Build Directory</link> at 
         <filename>tmp/deploy/images/licenses</filename>.
     </para>
 
@@ -467,6 +466,12 @@
         <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>
+
+    <para>
+        For information that can help you to maintain compliance with various open source licensing 
+        during the lifecycle of a product created using the Yocto Project, see the 
+        "<link linkend='maintaining-open-source-license-compliance-during-your-products-lifecycle'>Maintaining Open Source License Compliance During Your Product's Lifecycle</link>" section.
+    </para>
 </section>
 
 <section id='git'>

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

@@ -56,8 +56,9 @@
                 OpenSUSE, Ubuntu, or CentOS as these releases are frequently tested against the Yocto Project
                 and officially supported. 
                 For a list of the distributions under validation and their status, see the
-                <ulink url='&YOCTO_WIKI_URL;/wiki/Distribution_Support'>Distribution
-                Support</ulink> wiki page.</para>
+                "<ulink url='&YOCTO_DOCS_REF_URL;#detailed-supported-distros'>Supported Linux Distributions</ulink>" section
+                in the Yocto Project Reference Manual and the wiki page at 
+                <ulink url='&YOCTO_WIKI_URL;/wiki/Distribution_Support'>Distribution Support</ulink>.</para>
                 <para>
                 You should also have about 100 gigabytes of free disk space for building images.
                 </para></listitem>
@@ -69,12 +70,12 @@
                 for the supported distributions.</para></listitem>
             <listitem id='local-yp-release'><para><emphasis>Yocto Project Release:</emphasis>  
                 You need a release of the Yocto Project.  
-                You set up a with local <link linkend='source-directory'>source directory</link>
+                You set up a with local <link linkend='source-directory'>Source Directory</link>
                 one of two ways depending on whether you 
                 are going to contribute back into the Yocto Project or not.
                 <note>
                     Regardless of the method you use, this manual refers to the resulting local
-                    hierarchical set of files as the "source directory."
+                    hierarchical set of files as the "Source Directory."
                 </note>
                 <itemizedlist>
                     <listitem><para><emphasis>Tarball Extraction:</emphasis>  If you are not going to contribute 
@@ -83,7 +84,7 @@
                         Once you have the tarball, just extract it into a directory of your choice.</para>
                         <para>For example, the following command extracts the Yocto Project &DISTRO; 
                         release tarball 
-                        into the current working directory and sets up the local source directory
+                        into the current working directory and sets up the local Source Directory
                         with a top-level folder named <filename>&YOCTO_POKY;</filename>:
                         <literallayout class='monospaced'>
      $ tar xfj &YOCTO_POKY_TARBALL;
@@ -125,11 +126,11 @@
                 You can find Git repositories of supported Yocto Project Kernels organized under
                 "Yocto Linux Kernel" in the Yocto Project Source Repositories at
                 <ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink>.</para>
-                <para>This setup involves creating a bare clone of the Yocto Project kernel and then 
+                <para>This setup can involve creating a bare clone of the Yocto Project kernel and then 
                 copying that cloned repository.
                 You can create the bare clone and the copy of the bare clone anywhere you like.
                 For simplicity, it is recommended that you create these structures outside of the 
-                source directory (usually <filename>poky</filename>).</para>
+                Source Directory (usually <filename>poky</filename>).</para>
                 <para>As an example, the following transcript shows how to create the bare clone
                 of the <filename>linux-yocto-3.4</filename> kernel and then create a copy of 
                 that clone.
@@ -152,8 +153,8 @@
                 <para>Now create a clone of the bare clone just created:
                 <literallayout class='monospaced'>
      $ git clone linux-yocto-3.4.git my-linux-yocto-3.4-work
-     Initialized empty Git repository in /home/scottrif/my-linux-yocto-3.4-work/.git/
-     Checking out files: 100% (37619/37619), done.
+     Cloning into 'my-linux-yocto-3.4-work'...
+     done.
                 </literallayout></para></listitem>
             <listitem id='poky-extras-repo'><para><emphasis>
                 The <filename>poky-extras</filename> Git Repository</emphasis>:
@@ -168,9 +169,9 @@
                 <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 source directory.</para>
+                It is good practice to create this Git repository inside the Source Directory.</para>
                 <para>Following is an example that creates the <filename>poky-extras</filename> Git 
-                repository inside the source directory, which is named <filename>poky</filename> 
+                repository inside the Source Directory, which is named <filename>poky</filename> 
                 in this case:
                 <literallayout class='monospaced'>
      $ cd ~/poky
@@ -192,7 +193,7 @@
                 layer.  
                 You can get set up for BSP development one of two ways: tarball extraction or
                 with a local Git repository.
-                It is a good idea to use the same method that you used to set up the source directory.
+                It is a good idea to use the same method that you used to set up the Source Directory.
                 Regardless of the method you use, the Yocto Project uses the following BSP layer 
                 naming scheme:
                 <literallayout class='monospaced'> 
@@ -218,13 +219,13 @@
                         Again, this method just produces a snapshot of the BSP layer in the form
                         of a hierarchical directory structure.</para></listitem>
                     <listitem><para><emphasis>Git Repository Method:</emphasis>  If you are working 
-                        with a local Git repository for your source directory, you should also use this method 
+                        with a local Git repository for your Source Directory, you should also use this method 
                         to set up the <filename>meta-intel</filename> Git repository.
                         You can locate the <filename>meta-intel</filename> Git repository in the 
                         "Yocto Metadata Layers" area of the Yocto Project Source Repositories at
                         <ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink>.</para>
                         <para>Typically, you set up the <filename>meta-intel</filename> Git repository inside
-                        the source directory.
+                        the Source Directory.
                         For example, the following transcript shows the steps to clone the 
                         <filename>meta-intel</filename>
                         Git repository inside the local <filename>poky</filename> Git repository.
@@ -266,13 +267,13 @@
     <para>
         The build process is as follows:
         <orderedlist>
-            <listitem><para>Make sure you have set up the source directory described in the 
+            <listitem><para>Make sure you have set up the Source Directory described in the 
                 previous section.</para></listitem>
             <listitem><para>Initialize the build environment by sourcing a build environment 
                 script.</para></listitem>
             <listitem><para>Optionally ensure the <filename>conf/local.conf</filename> configuration file,
                 which is found in the 
-                <link linkend='build-directory'>build directory</link>, 
+                <link linkend='build-directory'>Build Directory</link>, 
                 is set up how you want it.  
                 This file defines many aspects of the build environment including 
                 the target machine architecture through the 
@@ -298,7 +299,7 @@
     <para>
         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'>Images</ulink>
+        See the "<ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Images</ulink>"
         chapter in the Yocto Project Reference Manual
         for descriptions of the types of binaries that ship with a Yocto Project
         release.

documentation/dev-manual/dev-manual.xml

@@ -2,7 +2,7 @@
 "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
 [<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
-<book id='dev-manual' lang='en' 
+<book id='dev-manual' lang='en'
       xmlns:xi="http://www.w3.org/2003/XInclude"
       xmlns="http://docbook.org/ns/docbook"
       >
@@ -10,13 +10,13 @@
 
         <mediaobject>
             <imageobject>
-                <imagedata fileref='figures/dev-title.png' 
-                    format='SVG' 
+                <imagedata fileref='figures/dev-title.png'
+                    format='SVG'
                     align='left' scalefit='1' width='100%'/>
-            </imageobject> 
+            </imageobject>
         </mediaobject>
 
-        <title></title> 
+        <title></title>
 
         <authorgroup>
             <author>
@@ -41,9 +41,19 @@
             </revision>
             <revision>
                 <revnumber>1.3</revnumber>
-                <date>Sometime in 2012</date>
+                <date>October 2012</date>
                 <revremark>Released with the Yocto Project 1.3 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>1.3.1</revnumber>
+                <date>April 2013</date>
+                <revremark>Released with the Yocto Project 1.3.1 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.3.2</revnumber>
+                <date>May 2013</date>
+                <revremark>Released with the Yocto Project 1.3.2 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>
@@ -53,9 +63,9 @@
 
     <legalnotice>
       <para>
-          Permission is granted to copy, distribute and/or modify this document under 
+          Permission is granted to copy, distribute and/or modify this document under
           the terms of the <ulink type="http" url="http://creativecommons.org/licenses/by-sa/2.0/uk/">
-          Creative Commons Attribution-Share Alike 2.0 UK: England &amp; Wales</ulink> as published by 
+          Creative Commons Attribution-Share Alike 2.0 UK: England &amp; Wales</ulink> as published by
           Creative Commons.
       </para>
 
@@ -76,15 +86,11 @@
 
     <xi:include href="dev-manual-newbie.xml"/>
 
-    <xi:include href="dev-manual-common-tasks.xml"/>
-
     <xi:include href="dev-manual-model.xml"/>
 
-    <xi:include href="dev-manual-bsp-appendix.xml"/>
-
-    <xi:include href="dev-manual-kernel-appendix.xml"/>
+    <xi:include href="dev-manual-common-tasks.xml"/>
 
 </book>
-<!-- 
-vim: expandtab tw=80 ts=4 
+<!--
+vim: expandtab tw=80 ts=4
 -->

documentation/kernel-manual/kernel-concepts.xml

@@ -320,7 +320,7 @@
             Conceptually, configuration of a Yocto Project kernel occurs similarly to that needed for any
             Linux kernel.
             The build process for a Yocto Project kernel uses a <filename>.config</filename> file, which 
-            is created through the Linux Kernel Coinfiguration (LKC) tool.
+            is created through the Linux Kernel Configuration (LKC) tool.
             You can directly set various configurations in the 
             <filename>.config</filename> file by using the <filename>menuconfig</filename> 
             tool as built by BitBake.
@@ -344,7 +344,7 @@
                     After the tool is built, you can interact with it normally.
                     You can see how <filename>menuconfig</filename> is used to change a simple 
                     kernel configuration in the 
-                    "<ulink url='&YOCTO_DOCS_DEV_URL;#changing-the-config-smp-configuration-using-menuconfig'>Changing the&nbsp;&nbsp;<filename>CONFIG_SMP</filename> Configuration Using&nbsp;&nbsp;<filename>menuconfig</filename></ulink>" 
+                    "<ulink url='&YOCTO_DOCS_DEV_URL;#configuring-the-kernel'>Configuring the Kernel</ulink>" 
                     section of the Yocto Project Development Manual.
                     For general information on <filename>menuconfig</filename>, see
                     <ulink url='http://en.wikipedia.org/wiki/Menuconfig'></ulink>.

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

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

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

@@ -159,8 +159,9 @@
         </para>
 
         <itemizedlist>
-            <listitem><para>The <filename>SRC_URI</filename> points to the kernel Git 
-                repository.</para></listitem>
+            <listitem><para>The 
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink> points 
+                to the kernel Git repository.</para></listitem>
             <listitem><para>A BSP build branch exists.
                 This branch has the following form:
                 <literallayout class='monospaced'>
@@ -784,9 +785,9 @@
                 This section overviews the process of creating a BSP based on an 
                 existing similar BSP.
                 The information is introductory in nature and does not provide step-by-step examples. 
-                For detailed information on how to create a BSP given an existing similar BSP, see
-                the "<ulink url='&YOCTO_DOCS_DEV_URL;#dev-manual-bsp-appendix'>BSP Development 
-                Example</ulink>" appendix in the Yocto Project Development Manual, or see the 
+                For detailed information on how to create a new BSP, see
+                the "<ulink url='&YOCTO_DOCS_BSP_URL;#creating-a-new-bsp-layer-using-the-yocto-bsp-script'>Creating a New BSP Layer Using the yocto-bsp Script</ulink>" section in the 
+                Yocto Project Board Support Package (BSP) Developer's Guide, or see the 
                 <ulink url='&YOCTO_WIKI_URL;/wiki/Transcript:_creating_one_generic_Atom_BSP_from_another'>Transcript:_creating_one_generic_Atom_BSP_from_another</ulink>
                 wiki page.
             </para>
@@ -794,9 +795,10 @@
             <para>
                 The basic steps you need to follow are:
                 <orderedlist>
-                    <listitem><para><emphasis>Make sure you have set up a local source directory:</emphasis>
-                        You must create a local <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source
-                        directory</ulink> by either creating a Git repository (recommended) or 
+                    <listitem><para><emphasis>Make sure you have set up a local Source Directory:</emphasis>
+                        You must create a local 
+                        <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink> 
+                        by either creating a Git repository (recommended) or 
                         extracting a Yocto Project release tarball.</para></listitem>
                     <listitem><para><emphasis>Choose an existing BSP available with the Yocto Project:</emphasis>
                         Try to map your board features as closely to the features of a BSP that is  

documentation/kernel-manual/kernel-manual.xml

@@ -2,7 +2,7 @@
 "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
 [<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
-<book id='kernel-manual' lang='en' 
+<book id='kernel-manual' lang='en'
       xmlns:xi="http://www.w3.org/2003/XInclude"
       xmlns="http://docbook.org/ns/docbook"
       >
@@ -10,13 +10,13 @@
 
         <mediaobject>
             <imageobject>
-                <imagedata fileref='figures/kernel-title.png' 
-                    format='SVG' 
+                <imagedata fileref='figures/kernel-title.png'
+                    format='SVG'
                     align='left' scalefit='1' width='100%'/>
-            </imageobject>    
+            </imageobject>
         </mediaobject>
 
-        <title></title> 
+        <title></title>
 
         <authorgroup>
             <author>
@@ -56,9 +56,19 @@
             </revision>
             <revision>
                 <revnumber>1.3</revnumber>
-                <date>Sometime in 2012</date>
+                <date>October 2012</date>
                 <revremark>Released with the Yocto Project 1.3 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>1.3.1</revnumber>
+                <date>April 2013</date>
+                <revremark>Released with the Yocto Project 1.3.1 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.3.2</revnumber>
+                <date>May 2013</date>
+                <revremark>Released with the Yocto Project 1.3.2 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>
@@ -68,7 +78,7 @@
 
     <legalnotice>
       <para>
-        Permission is granted to copy, distribute and/or modify this document under 
+        Permission is granted to copy, distribute and/or modify this document under
         the terms of the <ulink type="http" url="http://creativecommons.org/licenses/by-sa/2.0/uk/">Creative Commons Attribution-Share Alike 2.0 UK: England &amp; Wales</ulink> as published by Creative Commons.
       </para>
       <note>
@@ -94,6 +104,6 @@
 -->
 
 </book>
-<!-- 
-vim: expandtab tw=80 ts=4 
+<!--
+vim: expandtab tw=80 ts=4
 -->

documentation/poky-ref-manual/faq.xml

@@ -166,7 +166,7 @@
         <answer>
             <para>
                 The OpenEmbedded build system can build packages in various formats such as
-                <filename>ipk</filename> for <filename>ipkg</filename>/<filename>opkg</filename>, 
+                <filename>ipk</filename> for <filename>opkg</filename>, 
                 Debian package (<filename>.deb</filename>), or RPM. 
                 The packages can then be upgraded using the package tools on the device, much like 
                 on a desktop distribution such as Ubuntu or Fedora.

documentation/poky-ref-manual/introduction.xml

@@ -87,10 +87,198 @@
 <section id='intro-requirements'>
 <title>System Requirements</title>
     <para>
-        For Yocto Project system requirements, see the
-        <ulink url='&YOCTO_DOCS_QS_URL;#yp-resources'>
-        What You Need and How You Get It</ulink> section in the Yocto Project Quick Start.
+        For general Yocto Project system requirements, see the
+        "<ulink url='&YOCTO_DOCS_QS_URL;#yp-resources'>What You Need and How You Get It</ulink>" section 
+        in the Yocto Project Quick Start.
+        The remainder of this section provides details on system requirements
+        not covered in the Yocto Project Quick Start.
     </para>
+
+    <section id='detailed-supported-distros'>
+        <title>Supported Linux Distributions</title>
+
+        <para>
+            Currently, the Yocto Project is supported on the following distributions:
+            <itemizedlist>
+                <listitem><para>Ubuntu 10.04.4 LTS</para></listitem>
+                <listitem><para>Ubuntu 11.10</para></listitem>
+                <listitem><para>Ubuntu 12.04.1 LTS</para></listitem>
+                <listitem><para>Ubuntu 12.04.1 LTS</para></listitem>
+                <listitem><para>Ubuntu 12.10</para></listitem>
+                <listitem><para>Fedora release 16 (Verne)</para></listitem>
+                <listitem><para>Fedora release 17 (Beefy Miracle)</para></listitem>
+                <listitem><para>Fedora release 18 (Spherical Cow)</para></listitem>
+                <listitem><para>CentOS release 5.6 (Final)</para></listitem>
+                <listitem><para>CentOS release 5.7 (Final)</para></listitem>
+                <listitem><para>CentOS release 5.8 (Final)</para></listitem>
+                <listitem><para>CentOS release 6.3 (Final)</para></listitem>
+                <listitem><para>Debian GNU/Linux 6.0.6 (squeeze)</para></listitem>
+                <listitem><para>openSUSE 11.4</para></listitem>
+                <listitem><para>openSUSE 12.1</para></listitem>
+                <listitem><para>openSUSE 12.2</para></listitem>
+            </itemizedlist>
+        </para>
+
+        <note>
+            For additional information on distributions that support the 
+            Yocto Project, see the 
+            <ulink url='&YOCTO_WIKI_URL;/wiki/Distribution_Support'>Distribution Support</ulink> wiki page.
+        </note>
+    </section>
+
+    <section id='required-packages-for-the-host-development-system'>
+    <title>Required Packages for the Host Development System</title>
+
+        <para>
+            The list of packages you need on the host development system can 
+            be large when covering all build scenarios using the Yocto Project. 
+            This section provides required packages by Linux distribution and 
+            further categorized by function.
+        </para>
+
+        <section id='ubuntu-packages'>
+            <title>Ubuntu</title>
+
+            <para>
+                The following list shows the required packages by function
+                given a supported Ubuntu Linux distribution:
+                <itemizedlist>
+                    <listitem><para><emphasis>Essentials:</emphasis>
+                        Packages needed to build an image on a headless 
+                        system:
+                        <literallayout class='monospaced'>
+     $ sudo apt-get install &UBUNTU_HOST_PACKAGES_ESSENTIAL;
+                        </literallayout></para></listitem>
+                    <listitem><para><emphasis>Graphical Extras:</emphasis>
+                        Packages recommended if the host system has graphics support:
+                        <literallayout class='monospaced'>
+     $ sudo apt-get install libsdl1.2-dev xterm
+                        </literallayout></para></listitem>
+                    <listitem><para><emphasis>Documentation:</emphasis>
+                        Packages needed if you are going to build out the 
+                        Yocto Project documentation manuals:
+                        <literallayout class='monospaced'>
+     $ sudo apt-get install make xsltproc docbook-utils fop
+                        </literallayout></para></listitem>
+                    <listitem><para><emphasis>ADT Installer Extras:</emphasis>
+                        Packages needed if you are going to be using the 
+                        <ulink url='&YOCTO_DOCS_ADT_URL;#using-the-adt-installer'>Application Development Toolkit (ADT) Installer</ulink>:
+                        <literallayout class='monospaced'>
+     $ sudo apt-get install autoconf automake libtool libglib2.0-dev
+                        </literallayout></para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id='fedora-packages'>
+            <title>Fedora Packages</title>
+
+            <para>
+                The following list shows the required packages by function
+                given a supported Fedora Linux distribution:
+                <itemizedlist>
+                    <listitem><para><emphasis>Essentials:</emphasis>
+                        Packages needed to build an image for a headless 
+                        system:
+                        <literallayout class='monospaced'>
+     $ sudo yum install &FEDORA_HOST_PACKAGES_ESSENTIAL;
+                        </literallayout></para></listitem>
+                    <listitem><para><emphasis>Graphical Extras:</emphasis>
+                        Packages recommended if the host system has graphics support:
+                        <literallayout class='monospaced'>
+     $ sudo yum install SDL-devel xterm
+                        </literallayout></para></listitem>
+                    <listitem><para><emphasis>Documentation:</emphasis>
+                        Packages needed if you are going to build out the 
+                        Yocto Project documentation manuals:
+                        <literallayout class='monospaced'>
+     $ sudo yum install make docbook-style-dsssl docbook-style-xsl \
+     docbook-dtds docbook-utils fop libxslt
+                        </literallayout></para></listitem>
+                    <listitem><para><emphasis>ADT Installer Extras:</emphasis>
+                        Packages needed if you are going to be using the 
+                        <ulink url='&YOCTO_DOCS_ADT_URL;#using-the-adt-installer'>Application Development Toolkit (ADT) Installer</ulink>:
+                        <literallayout class='monospaced'>
+     $ sudo yum install autoconf automake libtool glib2-devel
+                        </literallayout></para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id='opensuse-packages'>
+            <title>OpenSUSE Packages</title>
+
+            <para>
+                The following list shows the required packages by function
+                given a supported OpenSUSE Linux distribution:
+                <itemizedlist>
+                    <listitem><para><emphasis>Essentials:</emphasis>
+                        Packages needed to build an image for a headless 
+                        system:
+                        <literallayout class='monospaced'>
+     $ sudo zypper install &OPENSUSE_HOST_PACKAGES_ESSENTIAL;
+                        </literallayout></para></listitem>
+                    <listitem><para><emphasis>Graphical Extras:</emphasis>
+                        Packages recommended if the host system has graphics support:
+                        <literallayout class='monospaced'>
+     $ sudo zypper install libSDL-devel xterm
+                        </literallayout></para></listitem>
+                    <listitem><para><emphasis>Documentation:</emphasis>
+                        Packages needed if you are going to build out the 
+                        Yocto Project documentation manuals:
+                        <literallayout class='monospaced'>
+     $ sudo zypper install make fop xsltproc
+                        </literallayout></para></listitem>
+                    <listitem><para><emphasis>ADT Installer Extras:</emphasis>
+                        Packages needed if you are going to be using the 
+                        <ulink url='&YOCTO_DOCS_ADT_URL;#using-the-adt-installer'>Application Development Toolkit (ADT) Installer</ulink>:
+                        <literallayout class='monospaced'>
+     $ sudo zypper install autoconf automake libtool glib2-devel
+                        </literallayout></para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id='centos-packages'>
+            <title>CentOS Packages</title>
+
+            <para>
+                The following list shows the required packages by function
+                given a supported CentOS Linux distribution:
+                <itemizedlist>
+                    <listitem><para><emphasis>Essentials:</emphasis>
+                        Packages needed to build an image for a headless 
+                        system:
+                        <literallayout class='monospaced'>
+     $ sudo yum -y install &CENTOS_HOST_PACKAGES_ESSENTIAL;
+                        </literallayout></para></listitem>
+                    <listitem><para><emphasis>Graphical Extras:</emphasis>
+                        Packages recommended if the host system has graphics support:
+                        <literallayout class='monospaced'>
+     $ sudo yum -y install SDL-devel xterm
+                        </literallayout></para></listitem>
+                    <listitem><para><emphasis>Documentation:</emphasis>
+                        Packages needed if you are going to build out the 
+                        Yocto Project documentation manuals:
+                        <literallayout class='monospaced'>
+     $ sudo yum -y install make docbook-style-dsssl docbook-style-xsl \
+     docbook-dtds docbook-utils fop libxslt
+                        </literallayout></para></listitem>
+                    <listitem><para><emphasis>ADT Installer Extras:</emphasis>
+                        Packages needed if you are going to be using the 
+                        <ulink url='&YOCTO_DOCS_ADT_URL;#using-the-adt-installer'>Application Development Toolkit (ADT) Installer</ulink>:
+                        <literallayout class='monospaced'>
+     $ sudo yum -y install autoconf automake libtool glib2-devel
+                        </literallayout></para></listitem>
+                </itemizedlist>
+                <note>Depending on the CentOS version you are using, other requirements 
+                    and dependencies might exist. 
+                    For details, you should look at the CentOS sections on the 
+                    <ulink url='https://wiki.yoctoproject.org/wiki/Poky/GettingStarted/Dependencies'>Poky/GettingStarted/Dependencies</ulink>
+                    wiki page.</note>
+            </para>
+        </section>
+    </section>
 </section>
 
 <section id='intro-getit'>
@@ -118,7 +306,7 @@
     <title>Development Checkouts</title>
     <para>
         Development using the Yocto Project requires a local 
-        <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>. 
+        <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>. 
         You can set up the source directory by downloading a Yocto Project release tarball and unpacking it,  
         or by cloning a copy of the upstream
         <ulink url='&YOCTO_DOCS_DEV_URL;#poky'>Poky</ulink> Git repository.

documentation/poky-ref-manual/migration.xml

@@ -0,0 +1,235 @@
+<!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; ] >
+
+<chapter id='migration'>
+<title>Migrating to a Newer Yocto Project Release</title>
+
+    <para>
+        This chapter provides information you can use to migrate work to a 
+        newer Yocto Project release.  You can find the same information in the 
+        release notes for a given release.
+    </para>
+
+<section id='moving-to-the-yocto-project-1.3-release'>
+    <title>Moving to the Yocto Project 1.3 Release</title>
+
+    <para>
+        This section provides migration information for moving to the 
+        Yocto Project 1.3 Release.
+    </para>
+
+    <section id='1.3-local-configuration'>
+        <title>Local Configuration</title>
+
+        <para>
+            Differences include changes for 
+            <link linkend='var-SSTATE_MIRRORS'><filename>SSTATE_MIRRORS</filename></link>
+            and <filename>bblayers.conf</filename>.
+        </para>
+
+        <section id='migration-1.3-sstate-mirrors'>
+            <title>SSTATE_MIRRORS</title>
+
+            <para>
+                The shared state cache (sstate-cache) as pointed to by 
+                <link linkend='var-SSTATE_DIR'><filename>SSTATE_DIR</filename></link> by default 
+                now has two-character subdirectories to prevent there being an issue with too 
+                many files in the same directory.
+                Also, native sstate-cache packages will go into a subdirectory named using 
+                the distro ID string. 
+                If you copy the newly structured sstate-cache to a mirror location 
+                (either local or remote) and then point to it in 
+                <link linkend='var-SSTATE_MIRRORS'><filename>SSTATE_MIRRORS</filename></link>,
+                you need to append "PATH" to the end of the mirror URL so that 
+                the path used by BitBake before the mirror substitution is 
+                appended to the path used to access the mirror. 
+                Here is an example:
+                <literallayout class='monospaced'>
+     SSTATE_MIRRORS = "file://.* http://someserver.tld/share/sstate/PATH"
+                </literallayout>
+            </para>
+        </section>
+
+        <section id='migration-1.3-bblayers-conf'>
+            <title>bblayers.conf</title>
+
+            <para>
+                The <filename>meta-yocto</filename> layer has been split into 
+                two parts: <filename>meta-yocto</filename> and 
+                <filename>meta-yocto-bsp</filename>, corresponding to the 
+                Poky reference distro configuration and the reference
+                hardware Board Support Packages (BSPs), respectively. 
+                When running BitBake or Hob for the first time after upgrading, 
+                your <filename>conf/bblayers.conf</filename> file will be 
+                updated to handle this change and you will be asked to 
+                re-run/restart for the changes to take effect.
+            </para>
+        </section>
+    </section>
+
+    <section id='1.3-recipes'>
+        <title>Recipes</title>
+
+        <para>
+            Differences include changes for the following:
+            <itemizedlist>
+                <listitem><para>Python function whitespace</para></listitem>
+                <listitem><para><filename>proto=</filename> in <filename>SRC_URI</filename></para></listitem>
+                <listitem><para><filename>nativesdk</filename></para></listitem>
+                <listitem><para>Task recipes</para></listitem>
+                <listitem><para><filename>IMAGE_FEATURES</filename></para></listitem>
+                <listitem><para>Removed recipes</para></listitem>
+            </itemizedlist>
+        </para>
+
+        <section id='migration-1.3-python-function-whitespace'>
+            <title>Python Function Whitespace</title>
+
+            <para>
+                All Python functions must now use four spaces for indentation. 
+                Previously, an inconsistent mix of spaces and tabs existed,
+                which made extending these functions using 
+                <filename>_append</filename> or <filename>_prepend</filename>
+                complicated given that Python treats whitespace as 
+                syntactically significant. 
+                If you are defining or extending any Python functions (e.g.
+                <filename>populate_packages</filename>, <filename>do_unpack</filename>,
+                <filename>do_patch</filename> and so forth) in custom recipes
+                or classes, you need to ensure you are using consistent 
+                four-space indentation.
+            </para>
+        </section>
+
+        <section id='migration-1.3-proto=-in-src-uri'>
+            <title>proto= in SRC_URI</title>
+
+            <para>
+                Any use of <filename>proto=</filename> in 
+                <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>
+                needs to be changed to <filename>protocol=</filename>.
+                In particular, this applies to the following URIs:
+                <itemizedlist>
+                    <listitem><para><filename>svn://</filename></para></listitem>
+                    <listitem><para><filename>bzr://</filename></para></listitem>
+                    <listitem><para><filename>hg://</filename></para></listitem>
+                    <listitem><para><filename>osc://</filename></para></listitem>
+                </itemizedlist>
+                Other URIs were already using <filename>protocol=</filename>.
+                This change improves consistency.
+            </para>
+        </section>
+
+        <section id='migration-1.3-nativesdk'>
+            <title>nativesdk</title>
+
+            <para>
+                The suffix <filename>nativesdk</filename> is now implemented
+                as a prefix, which simplifies a lot of the packaging code for 
+                <filename>nativesdk</filename> recipes. 
+                All custom <filename>nativesdk</filename> recipes and any 
+                references need to be updated to use 
+                <filename>nativesdk-*</filename> instead of 
+                <filename>*-nativesdk</filename>.
+            </para>
+        </section>
+
+        <section id='migration-1.3-task-recipes'>
+            <title>Task Recipes</title>
+
+            <para>
+                "Task" recipes are now known as "Package groups" and have 
+                been renamed from <filename>task-*.bb</filename> to 
+                <filename>packagegroup-*.bb</filename>. 
+                Existing references to the previous <filename>task-*</filename>
+                names should work in most cases as there is an automatic 
+                upgrade path for most packages.
+                However, you should update references in your own recipes and 
+                configurations as they could be removed in future releases. 
+                You should also rename any custom <filename>task-*</filename>
+                recipes to <filename>packagegroup-*</filename>, and change 
+                them to inherit <filename>packagegroup</filename> instead of 
+                <filename>task</filename>, as well as taking the opportunity 
+                to remove anything now handled by 
+                <filename>packagegroup.bbclass</filename>, such as providing
+                <filename>-dev</filename> and <filename>-dbg</filename>
+                packages, setting 
+                <link linkend='var-LIC_FILES_CHKSUM'><filename>LIC_FILES_CHKSUM</filename></link>, 
+                and so forth.
+                See the 
+                "<link linkend='ref-classes-packagegroup'>Package Groups - packagegroup.bbclass</link>"
+                section for further details.
+            </para>
+        </section>
+
+        <section id='migration-1.3-image-features'>
+            <title>IMAGE_FEATURES</title>
+
+            <para>
+                Image recipes that previously included "apps-console-core" 
+                in <link linkend='var-IMAGE_FEATURES'><filename>IMAGE_FEATURES</filename></link>
+                should now include "splash" instead to enable the boot-up 
+                splash screen.
+                Retaining "apps-console-core" will still include the splash 
+                screen generates a warning.
+                The "apps-x11-core" and "apps-x11-games" 
+                <filename>IMAGE_FEATURES</filename> features have been removed.
+            </para>
+        </section>
+
+        <section id='migration-1.3-removed-recipes'>
+            <title>Removed Recipes</title>
+
+            <para>
+                The following recipes have been removed. 
+                For most of them, it is unlikely that you would have any 
+                references to them in your own metadata.
+                However, you should check your metadata against this list to be sure:
+                <itemizedlist>
+                    <listitem><para><emphasis><filename>libx11-trim</filename></emphasis>: 
+                        Replaced by <filename>libx11</filename>, which has a negligible 
+                        size difference with modern Xorg.</para></listitem>
+                    <listitem><para><emphasis><filename>xserver-xorg-lite</filename></emphasis>: 
+                        Use <filename>xserver-xorg</filename>, which has a negligible 
+                        size difference when DRI and GLX modules are not installed.</para></listitem>
+                    <listitem><para><emphasis><filename>xserver-kdrive</filename></emphasis>: 
+                        Effectively unmaintained for many years.</para></listitem>
+                    <listitem><para><emphasis><filename>mesa-xlib</filename></emphasis>: 
+                        No longer serves any purpose.</para></listitem>
+                    <listitem><para><emphasis><filename>galago</filename></emphasis>: 
+                        Replaced by telepathy.</para></listitem>
+                    <listitem><para><emphasis><filename>gail</filename></emphasis>: 
+                        Functionality was integrated into GTK+ 2.13.</para></listitem>
+                    <listitem><para><emphasis><filename>eggdbus</filename></emphasis>: 
+                        No longer needed.</para></listitem>
+                    <listitem><para><emphasis><filename>gcc-*-intermediate</filename></emphasis>: 
+                        The build has been restructured to avoid the need for 
+                        this step.</para></listitem>
+                    <listitem><para><emphasis><filename>libgsmd</filename></emphasis>: 
+                        Unmaintained for many years.
+                        Functionality now provided by 
+                        <filename>ofono</filename> instead.</para></listitem>
+                    <listitem><para><emphasis>contacts, dates, tasks, eds-tools</emphasis>: 
+                        Largely unmaintained PIM application suite.
+                        It has been moved to <filename>meta-gnome</filename>
+                        in <filename>meta-openembedded</filename>.</para></listitem>
+                </itemizedlist>
+                In addition to the previously listed changes, the 
+                <filename>meta-demoapps</filename> directory has also been removed
+                because the recipes in it were not being maintained and many 
+                had become obsolete or broken.
+                Additionally, these recipes were not parsed in the default configuration.
+                Many of these recipes are already provided in an updated and 
+                maintained form within OpenEmbedded community layers such as 
+                <filename>meta-oe</filename> and <filename>meta-gnome</filename>.
+                For the remainder, you can now find them in the 
+                <filename>meta-extras</filename> repository, which is in the 
+                Yocto Project source repositories.
+            </para>
+        </section>        
+    </section>
+</section>
+</chapter>
+<!-- 
+vim: expandtab tw=80 ts=4 
+-->

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

@@ -2,18 +2,18 @@
 "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
 [<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
-<book id='poky-ref-manual' lang='en' 
+<book id='poky-ref-manual' lang='en'
       xmlns:xi="http://www.w3.org/2003/XInclude"
       xmlns="http://docbook.org/ns/docbook"
       >
     <bookinfo>
- 
+
         <mediaobject>
             <imageobject>
-                <imagedata fileref='figures/poky-title.png' 
-                    format='SVG' 
+                <imagedata fileref='figures/poky-title.png'
+                    format='SVG'
                     align='left' scalefit='1' width='100%'/>
-            </imageobject>    
+            </imageobject>
         </mediaobject>
 
         <title></title>
@@ -57,9 +57,19 @@
             </revision>
             <revision>
                 <revnumber>1.3</revnumber>
-                <date>Sometime in 2012</date>
+                <date>October 2012</date>
                 <revremark>Released with the Yocto Project 1.3 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>1.3.1</revnumber>
+                <date>April 2013</date>
+                <revremark>Released with the Yocto Project 1.3.1 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.3.2</revnumber>
+                <date>May 2013</date>
+                <revremark>Released with the Yocto Project 1.3.2 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>
@@ -69,7 +79,7 @@
 
     <legalnotice>
       <para>
-        Permission is granted to copy, distribute and/or modify this document under 
+        Permission is granted to copy, distribute and/or modify this document under
         the terms of the <ulink type="http" url="http://creativecommons.org/licenses/by-sa/2.0/uk/">Creative Commons Attribution-Share Alike 2.0 UK: England &amp; Wales</ulink> as published by Creative Commons.
       </para>
       <note>
@@ -89,6 +99,8 @@
 
     <xi:include href="technical-details.xml"/>
 
+    <xi:include href="migration.xml"/>
+
     <xi:include href="ref-structure.xml"/>
 
     <xi:include href="ref-bitbake.xml"/>
@@ -109,10 +121,10 @@
 
 <!--    <index id='index'>
       <title>Index</title>
-    </index> 
+    </index>
 -->
 
 </book>
-<!-- 
-vim: expandtab tw=80 ts=4 
+<!--
+vim: expandtab tw=80 ts=4
 -->

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

@@ -36,7 +36,7 @@
         <para>
             The first thing BitBake does is look for the <filename>bitbake.conf</filename> file.
             This file resides in the 
-            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>
+            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
             within the <filename>meta/conf/</filename> directory.
             BitBake finds it by examining its 
             <link linkend='var-BBPATH'><filename>BBPATH</filename></link> environment 

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

@@ -13,7 +13,7 @@
     Class files are identified by the extension <filename>.bbclass</filename> and are usually placed 
     in a <filename>classes/</filename> directory beneath the 
     <filename>meta*/</filename> directory found in the 
-    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>.
+    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
     Class files can also be pointed to by BUILDDIR (e.g. <filename>build/</filename>)in the same way as
     <filename>.conf</filename> files in the <filename>conf</filename> directory. 
     Class files are searched for in <link linkend='var-BBPATH'><filename>BBPATH</filename></link>
@@ -302,7 +302,7 @@
         <filename><link linkend='var-PACKAGE_CLASSES'>PACKAGE_CLASSES</link></filename> 
         variable defined in the <filename>local.conf</filename> configuration file, 
         which is located in the <filename>conf</filename> folder of the 
-        <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>. 
+        <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>. 
         When defining the variable, you can specify one or more package types.
         Since images are generated from packages, a packaging class is 
         needed to enable image generation.
@@ -538,7 +538,7 @@
         you can use this class to specify those packages and associate the users and groups
         with those packages.
         The <filename>meta-skeleton/recipes-skeleton/useradd/useradd-example.bb</filename> 
-        recipe in the <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>
+        recipe in the <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
         provides a simple exmample that shows how to add three 
         users and groups to two packages.
         See the <filename>useradd-example.bb</filename> for more information on how to 
@@ -568,7 +568,7 @@
         <link linkend='var-B'><filename>B</filename></link> variable to point to the directory in 
         which the OpenEmbedded build system places the generated objects built from the recipes.
         By default, the <filename>B</filename> directory is set to the following, which is separate from the 
-        source directory (<filename>S</filename>):
+        Source Directory (<filename>S</filename>):
         <literallayout class='monospaced'>
      ${WORKDIR}/${BPN}-{PV}/
         </literallayout>
@@ -616,7 +616,7 @@
         Thus far, this chapter has discussed only the most useful and important 
         classes.
         However, other classes exist within the <filename>meta/classes</filename> directory 
-        in the <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>.
+        in the <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
         You can examine the <filename>.bbclass</filename> files directly for more 
         information. 
     </para>

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

@@ -28,8 +28,9 @@
         <title>Distro</title>
 
         <para>
-            The items below are valid options for 
-            <filename><link linkend='var-DISTRO_FEATURES'>DISTRO_FEATURES</link></filename>:
+            The items below are features you can use with  
+            <link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link>.
+            This list only represents features as shipped with the Yocto Project metadata:
             <itemizedlist>
                 <listitem><para><emphasis>alsa:</emphasis> ALSA support will be included (OSS compatibility 
                     kernel modules will be installed if available).</para></listitem>
@@ -74,8 +75,9 @@
         <title>Machine</title>
 
         <para>
-            The items below are valid options for 
-            <filename><link linkend='var-MACHINE_FEATURES'>MACHINE_FEATURES</link></filename>:
+            The items below are features you can use with  
+            <link linkend='var-MACHINE_FEATURES'><filename>MACHINE_FEATURES</filename></link>.
+            This list only represents features as shipped with the Yocto Project metadata:
             <itemizedlist>
                 <listitem><para><emphasis>acpi:</emphasis> Hardware has ACPI (x86/x86_64 only)
                     </para></listitem>
@@ -171,6 +173,83 @@
             </itemizedlist>
         </para>
     </section>
+
+    <section id='ref-features-backfill'>
+        <title>Feature Backfilling</title>
+
+        <para>
+            Sometimes it is necessary in the OpenEmbedded build system to extend
+            <link linkend='var-MACHINE_FEATURES'><filename>MACHINE_FEATURES</filename></link>
+            or <link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link>
+            to control functionality that was previously enabled and not able 
+            to be disabled. 
+            For these cases, we need to add an
+            additional feature item to appear in one of these variables, 
+            but we do not want to force developers who have existing values 
+            of the variables in their configuration to add the new feature 
+            in order to retain the same overall level of functionality. 
+            Thus, the OpenEmbedded build system has a mechanism to
+            automatically "backfill" these added features into existing 
+            distro or machine configurations. 
+            You can see the list of features for which this is done by
+            finding the 
+            <link linkend='var-DISTRO_FEATURES_BACKFILL'><filename>DISTRO_FEATURES_BACKFILL</filename></link>
+            and <link linkend='var-MACHINE_FEATURES_BACKFILL'><filename>MACHINE_FEATURES_BACKFILL</filename></link>
+            variables in the <filename>meta/conf/bitbake.conf</filename> file.
+        </para>
+
+        <para>
+            Because such features are backfilled by default into all 
+            configurations as described in the previous paragraph, developers 
+            who wish to disable the new features need to be able to selectively 
+            prevent the backfilling from occurring.
+            They can do this by adding the undesired feature or features to the
+            <link linkend='var-DISTRO_FEATURES_BACKFILL_CONSIDERED'><filename>DISTRO_FEATURES_BACKFILL_CONSIDERED</filename></link> 
+            or <link linkend='var-MACHINE_FEATURES_BACKFILL_CONSIDERED'><filename>MACHINE_FEATURES_BACKFILL_CONSIDERED</filename></link>
+            variables for distro features and machine features respectively.
+        </para>
+
+        <para>
+            Here are two examples to help illustrate feature backfilling:
+            <itemizedlist>
+                <listitem><para><emphasis>The "pulseaudio" distro feature option</emphasis>: 
+                    Previously, PulseAudio support was enabled within the Qt and 
+                    GStreamer frameworks.
+                    Because of this, the feature is backfilled and thus 
+                    enabled for all distros through the 
+                    <filename>DISTRO_FEATURES_BACKFILL</filename>
+                    variable in the <filename>meta/conf/bitbake.conf</filename> file.
+                    However, your distro needs to disable the feature.
+                    You can disable the feature without affecting 
+                    other existing distro configurations that need PulseAudio support
+                    by adding "pulseaudio" to
+                    <filename>DISTRO_FEATURES_BACKFILL_CONSIDERED</filename>
+                    in your distro's <filename>.conf</filename> file.
+                    Adding the feature to this variable when it also
+                    exists in the <filename>DISTRO_FEATURES_BACKFILL</filename>
+                    variable prevents the build system from adding the feature to 
+                    your configuration's <filename>DISTRO_FEATURES</filename>, effectively disabling
+                    the feature for that particular distro.</para></listitem>
+                <listitem><para><emphasis>The "rtc" machine feature option</emphasis>: 
+                    Previously, real time clock (RTC) support was enabled for all 
+                    target devices.
+                    Because of this, the feature is backfilled and thus enabled
+                    for all machines through the <filename>MACHINE_FEATURES_BACKFILL</filename>
+                    variable in the <filename>meta/conf/bitbake.conf</filename> file.
+                    However, your target device does not have this capability.
+                    You can disable RTC support for your device without 
+                    affecting other machines that need RTC support 
+                    by adding the feature to your machine's 
+                    <filename>MACHINE_FEATURES_BACKFILL_CONSIDERED</filename>
+                    list in the machine's <filename>.conf</filename> file.
+                    Adding the feature to this variable when it also
+                    exists in the <filename>MACHINE_FEATURES_BACKFILL</filename>
+                    variable prevents the build system from adding the feature to 
+                    your configuration's <filename>MACHINE_FEATURES</filename>, effectively 
+                    disabling RTC support for that particular machine.</para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
 </chapter>
 
 <!-- 

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

@@ -7,14 +7,14 @@
 <title>Source Directory Structure</title>
 
 <para>
-    The <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink> consists of several components.
+    The <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink> consists of several components.
     Understanding them and knowing where they are located is key to using the Yocto Project well.
-    This chapter describes the source directory and gives information about the various 
+    This chapter describes the Source Directory and gives information about the various 
     files and directories.
 </para>
 
 <para>
-    For information on how to establish a local source directory on your development system, see the
+    For information on how to establish a local Source Directory on your development system, see the
     "<ulink url='&YOCTO_DOCS_DEV_URL;#getting-setup'>Getting Set Up</ulink>"
     section in the Yocto Project Development Manual.
 </para>
@@ -26,7 +26,7 @@
         <title><filename>bitbake/</filename></title>
 
         <para>
-            The <ulink url='source-directory'>source directory</ulink>
+            The <ulink url='source-directory'>Source Directory</ulink>
             includes a copy of BitBake for ease of use.
             The copy usually matches the current stable BitBake release from the BitBake project. 
             BitBake, a metadata interpreter, reads the Yocto Project metadata and runs the tasks 
@@ -39,7 +39,7 @@
             When you run the <filename>bitbake</filename> command, the wrapper script in 
             <filename>scripts/</filename> is executed to run the main BitBake executable, 
             which resides in the <filename>bitbake/bin/</filename> directory.
-            Sourcing the <link linkend="structure-core-script">oe-init-build-env</link> 
+            Sourcing the <link linkend="structure-core-script">&OE_INIT_FILE;</link> 
             script places the <filename>scripts</filename> and <filename>bitbake/bin</filename>
             directories (in that order) into the shell's <filename>PATH</filename> environment 
             variable.
@@ -59,19 +59,19 @@
             This directory contains user configuration files and the output 
             generated by the OpenEmbedded build system in its standard configuration where 
             the source tree is combined with the output.
-            The <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>
+            The <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
             is created initially when you <filename>source</filename>
-            the OpenEmbedded build environment setup script <filename>oe-init-build-env</filename>.
+            the OpenEmbedded build environment setup script <filename>&OE_INIT_FILE;</filename>.
         </para>
 
         <para> 
             It is also possible to place output and configuration 
             files in a directory separate from the 
-            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>
+            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
             by providing a directory name when you <filename>source</filename>
             the setup script.
-            For information on separating output from your local source directory files, see <link 
-            linkend='structure-core-script'>oe-init-build-env</link>.
+            For information on separating output from your local Source Directory files, see <link 
+            linkend='structure-core-script'>&OE_INIT_FILE;</link>.
         </para>
     </section>
 
@@ -93,25 +93,37 @@
 
         <para>
             This directory contains the OpenEmbedded Core metadata. 
-            The directory holds machine definitions, the Yocto Project distribution, 
-            and the packages that make up a given system.
+            The directory holds recipes, common classes, and machine
+            configuration for emulated targets (qemux86, qemuarm,
+            and so on.)
         </para>
     </section>
 
-    <section id='structure-core-meta-demoapps'>
-        <title><filename>meta-demoapps/</filename></title>
+    <section id='structure-core-meta-yocto'>
+        <title><filename>meta-yocto/</filename></title>
 
         <para>
-            This directory contains recipes for applications and demos that are not part of the 
-            OpenEmbedded core.
+            This directory contains the configuration for the Poky
+            reference distribution.
         </para>
     </section>
 
-    <section id='structure-core-meta-rt'>
-        <title><filename>meta-rt/</filename></title>
+    <section id='structure-core-meta-yocto-bsp'>
+        <title><filename>meta-yocto-bsp/</filename></title>
 
         <para>
-            This directory contains recipes for real-time kernels. 
+            This directory contains the Yocto Project reference
+            hardware BSPs.
+        </para>
+    </section>
+
+    <section id='structure-meta-hob'>
+        <title><filename>meta-hob/</filename></title>
+
+        <para>
+            This directory contains template recipes used by the
+            <ulink url='&YOCTO_HOME_URL;/projects/hob'>Hob</ulink>
+            build UI.
         </para>
     </section>
 
@@ -129,7 +141,7 @@
         <para>
             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
+            The <link linkend="structure-core-script">&OE_INIT_FILE;</link> script appends this
             directory to the shell's <filename>PATH</filename> environment variable.
         </para>
 
@@ -141,7 +153,7 @@
     </section>
 
     <section id='structure-core-script'>
-        <title><filename>oe-init-build-env</filename></title>
+        <title><filename>&OE_INIT_FILE;</filename></title>
 
         <para>
             This script sets up the OpenEmbedded build environment. 
@@ -154,16 +166,16 @@
         </para>
 
         <para>
-            By default, running this script without a build directory argument creates the 
+            By default, running this script without a Build Directory argument creates the 
             <filename>build</filename> directory. 
-            If you provide a build directory argument when you <filename>source</filename>
+            If you provide a Build Directory argument when you <filename>source</filename>
             the script, you direct OpenEmbedded build system to create a 
-            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink> of your choice.
-            For example, the following command creates a build directory named 
+            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink> of your choice.
+            For example, the following command creates a Build Directory named 
             <filename>mybuilds</filename> that is outside of the 
-            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>:
+            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>:
             <literallayout class='monospaced'>
-     $ source oe-init-build-env ~/mybuilds
+     $ source &OE_INIT_FILE; ~/mybuilds
             </literallayout>
         </para>
     </section>
@@ -205,9 +217,13 @@
 
         <para>
             Edit this file to set the <filename><link linkend='var-MACHINE'>MACHINE</link></filename> 
-            for which you want to build, which package types you
-            wish to use (<filename>PACKAGE_CLASSES</filename>), or where you want to downloaded files
-            (<filename><link linkend='var-DL_DIR'>DL_DIR</link></filename>).
+            for which you want to build, which package types you wish to use 
+            (<link linkend='var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></link>), 
+            where you want to downloaded files
+            (<filename><link linkend='var-DL_DIR'>DL_DIR</link></filename>), 
+            and how you want your host machine to use resources 
+            (<link linkend='var-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename></link> and 
+            <link linkend='var-PARALLEL_MAKE'><filename>PARALLEL_MAKE</filename></link>).
         </para>
     </section>
 
@@ -371,7 +387,7 @@
             data.  
             Packages that need to share output with other packages do so within this directory. 
             The directory is subdivided by architecture so multiple builds can run within
-            the one build directory.
+            the one Build Directory.
         </para>
     </section>
 

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

@@ -120,20 +120,13 @@
             <para>
                 This section lists variables that are required for recipes.
                 <itemizedlist>
-                    <listitem><para><filename><link linkend='var-DESCRIPTION'>DESCRIPTION</link>
-                        </filename></para></listitem>
                     <listitem><para><filename><link linkend='var-LICENSE'>LICENSE</link>
                         </filename></para></listitem>
                     <listitem><para><filename><link linkend='var-LIC_FILES_CHKSUM'>LIC_FILES_CHKSUM</link>
                         </filename></para></listitem>
-                    <listitem><para><filename><link linkend='var-SECTION'>SECTION</link>
-                        </filename></para></listitem>
-                    <listitem><para><filename><link linkend='var-HOMEPAGE'>HOMEPAGE</link>
-                        </filename></para></listitem>
-                    <listitem><para><filename><link linkend='var-AUTHOR'>AUTHOR</link>
-                        </filename></para></listitem>
-                    <listitem><para><filename><link linkend='var-SRC_URI'>SRC_URI</link>
-                        </filename></para></listitem>
+                    <listitem><para><filename><link linkend='var-SRC_URI'>SRC_URI</link></filename> - used
+                        in recipes that fetch local or remote files.
+                        </para></listitem>
                 </itemizedlist>
             </para>
         </section>
@@ -180,8 +173,6 @@
             <para>
                 This section lists variables that define extra build information for recipes.
                 <itemizedlist>
-                    <listitem><para><filename><link linkend='var-DISTRO_PN_ALIAS'>DISTRO_PN_ALIAS</link>
-                        </filename></para></listitem>
                     <listitem><para><filename><link linkend='var-EXTRA_OECMAKE'>EXTRA_OECMAKE</link>
                         </filename></para></listitem>
                     <listitem><para><filename><link linkend='var-EXTRA_OECONF'>EXTRA_OECONF</link>

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

@@ -129,7 +129,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>" chapter provides details
+            The "<link linkend='ref-classes'>Classes</link>" chapter provides details
             about common classes and how to use them.
         </para>
     </section>
@@ -143,7 +143,7 @@
             These files fall into several areas that define machine configuration options, 
             distribution configuration options, compiler tuning options, general common configuration
             options and user configuration options (<filename>local.conf</filename>, which is found
-            in the <ulink url='build-directory'>build directory</ulink>).
+            in the <ulink url='build-directory'>Build Directory</ulink>).
         </para>
     </section>
 </section>
@@ -304,7 +304,7 @@
             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. 
+            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. 
@@ -442,14 +442,24 @@
 
         <para>
             Behind the scenes, the shared state code works by looking in 
-            <filename>SSTATE_DIR</filename> and  
-            <filename>SSTATE_MIRRORS</filename> for shared state files. 
+            <link linkend='var-SSTATE_DIR'><filename>SSTATE_DIR</filename></link> and  
+            <link linkend='var-SSTATE_MIRRORS'><filename>SSTATE_MIRRORS</filename></link>
+            for shared state files. 
             Here is an example:
             <literallayout class='monospaced'>
      SSTATE_MIRRORS ?= "\
-     file://.* http://someserver.tld/share/sstate/ \n \
-     file://.* file:///some/local/dir/sstate/"
+     file://.* http://someserver.tld/share/sstate/PATH \n \
+     file://.* file:///some/local/dir/sstate/PATH"
             </literallayout>
+            <note> 
+                The shared state directory (<filename>SSTATE_DIR</filename>) is 
+                organized into two-character subdirectories, where the subdirectory 
+                names are based on the first two characters of the hash.
+                If the shared state directory structure for a mirror has the 
+                same structure as <filename>SSTATE_DIR</filename>, you must
+                specify "PATH" as part of the URI to enable the build system
+                to map to the appropriate subdirectory.
+            </note>
         </para>
 
         <para>
@@ -640,7 +650,7 @@
             Yocto Project, you can follow these steps to use the x32 spABI:
             <itemizedlist>
                 <listitem><para>Add the <filename>experimental/meta-x32</filename> layer to your local
-                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>.  
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.  
                     You can find the <filename>experimental/meta-x32</filename> source repository at
                     <ulink url='&YOCTO_GIT_URL;'></ulink>.</para></listitem>
                 <listitem><para>Edit your <filename>conf/bblayers.conf</filename> file so that it includes
@@ -650,6 +660,7 @@
      BBLAYERS ?= " \
         /home/nitin/prj/poky.git/meta \
         /home/nitin/prj/poky.git/meta-yocto \
+        /home/nitin/prj/poky.git/meta-yocto-bsp \
         /home/nitin/prj/meta-x32.git \
      "
                     </literallayout></para></listitem>
@@ -687,6 +698,13 @@
         which by default are disabled.
     </para>
 
+    <para>
+        For information that can help you maintain compliance with various open 
+        source licensing during the lifecycle of the product, see the 
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#maintaining-open-source-license-compliance-during-your-products-lifecycle'>Maintaining Open Source License Compliance During Your Project's Lifecycle</ulink>" section
+        in the Yocto Project Development Manual.
+    </para>
+
     <section id="usingpoky-configuring-LIC_FILES_CHKSUM">
         <title>Tracking License Changes</title>
 
@@ -724,7 +742,7 @@
             <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;\
+     LIC_FILES_CHKSUM = "file://src/ls.c;beginline=5;endline=16;\
                                          md5=bb14ed3c4cda583abc85401304b5cd4e"
      LIC_FILES_CHKSUM = "file://../license.html;md5=5c94767cedb5d6987c902ac850ded2c6"
                 </literallayout>

documentation/poky-ref-manual/usingpoky.xml

@@ -30,20 +30,20 @@
             The first thing you need to do is set up the OpenEmbedded build environment by sourcing
             the environment setup script as follows:
             <literallayout class='monospaced'>
-     $ source oe-init-build-env [build_dir]
+     $ source &OE_INIT_FILE; [build_dir]
             </literallayout>
         </para>
 
         <para>
             The <filename>build_dir</filename> is optional and specifies the directory the 
             OpenEmbedded build system uses for the build - 
-            the <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>.
-            If you do not specify a build directory it defaults to <filename>build</filename>
+            the <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+            If you do not specify a Build Directory it defaults to <filename>build</filename>
             in your current working directory.
-            A common practice is to use a different build directory for different targets. 
+            A common practice is to use a different Build Directory for different targets. 
             For example, <filename>~/build/x86</filename> for a <filename>qemux86</filename>
             target, and <filename>~/build/arm</filename> for a <filename>qemuarm</filename> target.
-            See <link linkend="structure-core-script">oe-init-build-env</link>
+            See <link linkend="structure-core-script">&OE_INIT_FILE;</link>
             for more information on this script.
         </para>
 
@@ -58,7 +58,7 @@
             The <filename>target</filename> is the name of the recipe you want to build. 
             Common targets are the images in <filename>meta/recipes-core/images</filename>,
             <filename>/meta/recipes-sato/images</filename>, etc. all found in the 
-            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>.
+            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
             Or, the target can be the name of a recipe for a specific piece of software such as 
             <application>busybox</application>. 
             For more details about the images the OpenEmbedded build system supports, see the 
@@ -91,7 +91,7 @@
     <para>
         Once an image has been built, it often needs to be installed. 
         The images and kernels built by the OpenEmbedded build system are placed in the 
-        <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink> in 
+        <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink> in 
         <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
@@ -268,7 +268,7 @@
             For guidance on how logging is handled in both Python and Bash recipes, see the 
             <filename>logging.bbclass</filename> file in the 
             <filename>meta/classes</filename> folder of the 
-            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>.
+            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
         </para>
 
         <section id='logging-with-python'>

documentation/poky.ent

@@ -1,9 +1,9 @@
-<!ENTITY DISTRO "1.3">
+<!ENTITY DISTRO "1.3.2">
 <!ENTITY DISTRO_NAME "danny">
-<!ENTITY YOCTO_DOC_VERSION "1.3">
-<!ENTITY POKYVERSION "8.0">
+<!ENTITY YOCTO_DOC_VERSION "1.3.2">
+<!ENTITY POKYVERSION "8.0.2">
 <!ENTITY YOCTO_POKY "poky-&DISTRO_NAME;-&POKYVERSION;">
-<!ENTITY COPYRIGHT_YEAR "2010-2012">
+<!ENTITY COPYRIGHT_YEAR "2010-2013">
 <!ENTITY YOCTO_DL_URL "http://downloads.yoctoproject.org">
 <!ENTITY YOCTO_HOME_URL "http://www.yoctoproject.org">
 <!ENTITY YOCTO_LISTS_URL "http://lists.yoctoproject.org">
@@ -48,3 +48,9 @@
 <!ENTITY YOCTO_POKY_TARBALL "&YOCTO_POKY;.tar.bz2">
 <!ENTITY OE_INIT_PATH "&YOCTO_POKY;/oe-init-build-env">
 <!ENTITY OE_INIT_FILE "oe-init-build-env">
+<!ENTITY UBUNTU_HOST_PACKAGES_ESSENTIAL "gawk wget git-core diffstat unzip texinfo build-essential chrpath">
+<!ENTITY FEDORA_HOST_PACKAGES_ESSENTIAL "gawk make wget tar bzip2 gzip python unzip perl patch diffutils diffstat git
+cpp gcc gcc-c++ eglibc-devel texinfo chrpath ccache">
+<!ENTITY OPENSUSE_HOST_PACKAGES_ESSENTIAL "python gcc gcc-c++ git chrpath make wget diffstat texinfo python-curses">
+<!ENTITY CENTOS_HOST_PACKAGES_ESSENTIAL "gawk make wget tar bzip2 gzip python unzip perl patch diffutils diffstat git
+cpp gcc gcc-c++ glibc-devel texinfo chrpath">

documentation/tools/mega-manual.sed

@@ -1,14 +1,13 @@
 # Processes poky-ref-manual and yocto-project-qs manual (<word>-<word>-<word> style)
-s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.3\/[a-z]*-[a-z]*-[a-z]*\/[a-z]*-[a-z]*-[a-z]*.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.3.1\/[a-z]*-[a-z]*-[a-z]*\/[a-z]*-[a-z]*-[a-z]*.html#/\"link\" href=\"#/g
 
 # Processes all other manuals (<word>-<word> style)
-s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.3\/[a-z]*-[a-z]*\/[a-z]*-[a-z]*.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.3.1\/[a-z]*-[a-z]*\/[a-z]*-[a-z]*.html#/\"link\" href=\"#/g
 
 # Process cases where just an external manual is referenced without an id anchor
-s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.3\/yocto-project-qs\/yocto-project-qs.html\" target=\"_top\">Yocto Project Quick Start<\/a>/Yocto Project Quick Start/g
-s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.3\/dev-manual\/dev-manual.html\" target=\"_top\">Yocto Project Development Manual<\/a>/Yocto Project Development Manual/g
-s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.3\/adt-manual\/adt-manual.html\" target=\"_top\">Yocto Project Application Developer's Guide<\/a>/Yocto Project Application Developer's Guide/g
-s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.3\/bsp-guide\/bsp-guide.html\" target=\"_top\">Yocto Project Board Support Package (BSP) Developer's Guide<\/a>/Yocto Project Board Support Package (BSP) Developer's Guide/g
-s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.3\/kernel-manual\/kernel-manual.html\" target=\"_top\">Yocto Project Kernel Architecture and Use Manual<\/a>/Yocto Project Kernel Architecture and Use Manual/g
-s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.3\/poky-ref-manual\/poky-ref-manual.html\" target=\"_top\">Yocto Project Reference Manual<\/a>/Yocto Project Reference Manual/g
-
+s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.3.1\/yocto-project-qs\/yocto-project-qs.html\" target=\"_top\">Yocto Project Quick Start<\/a>/Yocto Project Quick Start/g
+s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.3.1\/dev-manual\/dev-manual.html\" target=\"_top\">Yocto Project Development Manual<\/a>/Yocto Project Development Manual/g
+s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.3.1\/adt-manual\/adt-manual.html\" target=\"_top\">Yocto Project Application Developer's Guide<\/a>/Yocto Project Application Developer's Guide/g
+s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.3.1\/bsp-guide\/bsp-guide.html\" target=\"_top\">Yocto Project Board Support Package (BSP) Developer's Guide<\/a>/Yocto Project Board Support Package (BSP) Developer's Guide/g
+s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.3.1\/kernel-manual\/kernel-manual.html\" target=\"_top\">Yocto Project Kernel Architecture and Use Manual<\/a>/Yocto Project Kernel Architecture and Use Manual/g
+s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.3.1\/poky-ref-manual\/poky-ref-manual.html\" target=\"_top\">Yocto Project Reference Manual<\/a>/Yocto Project Reference Manual/g

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

@@ -56,7 +56,7 @@
             <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> chapter in  
+                "<ulink url='&YOCTO_DOCS_REF_URL;#faq'>FAQ</ulink>" chapter in  
                 the Yocto Project Reference Manual.
                 </para></listitem>
             <listitem><para><emphasis>Developer Screencast:</emphasis> The 
@@ -177,9 +177,10 @@
                 <listitem><para>openSUSE</para></listitem>
                 <listitem><para>CentOS</para></listitem>
             </itemizedlist>
-            For a list of the distributions under validation and their status, see the
-            <ulink url='&YOCTO_WIKI_URL;/wiki/Distribution_Support'>Distribution
-            Support</ulink> wiki page.
+            For a more detailed list of distributions that support the Yocto Project, 
+            see the 
+            "<ulink url='&YOCTO_DOCS_REF_URL;#detailed-supported-distros'>Supported Linux Distributions</ulink>" section
+            in the Yocto Project Reference Manual.
             <note>
                 For notes about using the Yocto Project on a RHEL 4-based host, see the
                 <ulink url='&YOCTO_WIKI_URL;/wiki/BuildingOnRHEL4'>BuildingOnRHEL4</ulink>
@@ -211,94 +212,85 @@
         <title>The Packages</title>
 
         <para>
-            Packages and package installation vary depending on your development system.  
-            In general, you need to have root access and then install the required packages.
-            The next few sections show you how to get set up with the right packages for
-            Ubuntu, Fedora, openSUSE, and CentOS.
+            Packages and package installation vary depending on your development system
+            and on your intent. 
+            For example, if you want to build an image that can run
+            on QEMU in graphical mode (a minimal, basic build
+            requirement), then the number of packages is different than if you want to
+            build an image on a headless system or build out the Yocto Project
+            documentation set. 
+            Collectively, the number of required packages is large
+            if you want to be able to cover all cases.
+            <note>In general, you need to have root access and then install the 
+                required packages.
+                Thus, the commands in the following section may or may not work 
+                depending on whether or not your Linux distribution has 
+                <filename>sudo</filename> installed.</note>
         </para>
-  
+
+        <para>
+            The next few sections list, by supported Linux Distributions, the required
+            packages needed to build an image that runs on QEMU in graphical mode
+            (e.g. essential plus graphics support).
+        </para>
+
+        <para> 
+            For lists of required packages for other scenarios, see the 
+            "<ulink url='&YOCTO_DOCS_REF_URL;#required-packages-for-the-host-development-system'>Required Packages for the Host Development System</ulink>" 
+            section in the Yocto Project Reference Manual.
+        </para>
+
         <section id='ubuntu'>
             <title>Ubuntu</title>
 
             <para>
-                The packages you need for a supported Ubuntu distribution are shown in the following command:
-            </para>
-
+                The essential packages you need for a supported Ubuntu distribution 
+                are shown in the following command:
                 <literallayout class='monospaced'>
-     $ sudo apt-get install sed wget subversion git-core coreutils \
-     unzip texi2html texinfo libsdl1.2-dev docbook-utils fop gawk \
-     python-pysqlite2 diffstat make gcc build-essential xsltproc \
-     g++ desktop-file-utils chrpath libgl1-mesa-dev libglu1-mesa-dev \
-     autoconf automake groff libtool xterm libxml-parser-perl dblatex
+     $ sudo apt-get install &UBUNTU_HOST_PACKAGES_ESSENTIAL; libsdl1.2-dev xterm
                 </literallayout>
+            </para>
         </section>
 
         <section id='fedora'>
             <title>Fedora</title>
 
             <para>
-                The packages you need for a supported Fedora distribution are shown in the following
-                commands:
-            </para>
-
+                The essential packages you need for a supported Fedora distribution 
+                are shown in the following command:
                 <literallayout class='monospaced'>
-     $ sudo yum groupinstall "development tools"
-     $ sudo yum install python m4 make wget curl ftp tar bzip2 gzip \
-     unzip perl texinfo texi2html diffstat openjade \
-     docbook-style-dsssl sed docbook-style-xsl docbook-dtds fop libxslt \
-     docbook-utils sed bc eglibc-devel ccache pcre pcre-devel quilt \
-     groff linuxdoc-tools patch cmake \
-     perl-ExtUtils-MakeMaker tcl-devel gettext chrpath ncurses apr \
-     SDL-devel mesa-libGL-devel mesa-libGLU-devel gnome-doc-utils \
-     autoconf automake libtool xterm dblatex glib-gettextize
+     $ sudo yum install &FEDORA_HOST_PACKAGES_ESSENTIAL; SDL-devel xterm
                 </literallayout>
-
+            </para>
         </section>
 
         <section id='opensuse'>
             <title>openSUSE</title>
 
             <para>
-                The packages you need for a supported openSUSE distribution are shown in the following 
-                command:
-            </para>
-
+                The essential packages you need for a supported openSUSE 
+                distribution are shown in the following command:
                 <literallayout class='monospaced'>
-     $ sudo zypper install python gcc gcc-c++ libtool fop \
-     subversion git chrpath automake make wget xsltproc \
-     diffstat texinfo freeglut-devel libSDL-devel dblatex \
-     python-curses
+     $ sudo zypper install &OPENSUSE_HOST_PACKAGES_ESSENTIAL; libSDL-devel xterm
                 </literallayout>
+            </para>
         </section>
 
         <section id='centos'>
             <title>CentOS</title>
 
             <para>
-                The packages you need for a supported CentOS distribution are shown in the following 
-                commands:
-            </para>
-
+                The essential packages you need for a supported CentOS 
+                distribution are shown in the following command:
                 <literallayout class='monospaced'>
-     $ sudo yum -y groupinstall "development tools"
-     $ sudo yum -y install tetex gawk sqlite-devel vim-common redhat-lsb xz \
-       m4 make wget curl ftp tar bzip2 gzip python-devel \
-       unzip perl texinfo texi2html diffstat openjade zlib-devel \
-       docbook-style-dsssl sed docbook-style-xsl docbook-dtds \
-       docbook-utils bc glibc-devel pcre pcre-devel \
-       groff linuxdoc-tools patch cmake \
-       tcl-devel gettext ncurses apr \
-       SDL-devel mesa-libGL-devel mesa-libGLU-devel gnome-doc-utils \
-       autoconf automake libtool xterm dblatex
+     $ sudo yum -y install &CENTOS_HOST_PACKAGES_ESSENTIAL; SDL-devel xterm
                 </literallayout>
-            <note><para>
-                Depending on the CentOS version you are using, other requirements and dependencies
-                might exist. 
-                For details, you should look at the CentOS sections on the 
-                <ulink url='&YOCTO_WIKI_URL;/wiki/Poky/GettingStarted/Dependencies'>Poky/GettingStarted/Dependencies</ulink>
-                wiki page.
-            </para></note>
-
+                <note>Depending on the CentOS version you are using, other requirements 
+                    and dependencies might exist. 
+                    For details, you should look at the CentOS sections on the 
+                    <ulink url='https://wiki.yoctoproject.org/wiki/Poky/GettingStarted/Dependencies'>Poky/GettingStarted/Dependencies</ulink>
+                    wiki page.</note>
+            </para>
         </section>
     </section>
 
@@ -414,23 +406,23 @@
                  them into a directory named <filename>&YOCTO_POKY;</filename> in the current 
                  directory.</para></listitem>
              <listitem><para>The third and fourth commands change the working directory to the
-                 <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>
+                 <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
                  and run the Yocto Project environment setup script.
                  Running this script defines OpenEmbedded build environment settings needed to
                  complete the build.
                  The script also creates the 
-                 <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>,
+                 <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>,
                  which is <filename>build</filename> in this case and is located in the 
-                 source directory.
+                 Source Directory.
                  After the script runs, your current working directory is set 
-                 to the build directory.
-                 Later, when the build completes, the build directory contains all the files 
+                 to the Build Directory.
+                 Later, when the build completes, the Build Directory contains all the files 
                  created during the build.
                  </para></listitem>
          </itemizedlist>
          <para>
              Take some time to examine your <filename>local.conf</filename> file 
-             in your project's configuration directory, which is found in the build directory.
+             in your project's configuration directory, which is found in the Build Directory.
              The defaults in that file should work fine.
              However, there are some variables of interest at which you might look.
          </para>
@@ -749,7 +741,7 @@
         <title>Getting the Yocto Project</title>
 
         <para>
-            Set up your <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>
+            Set up your <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
             one of two ways:
             <itemizedlist>
                 <listitem><para><emphasis>Tarball:</emphasis> 
@@ -783,9 +775,9 @@
 
         <para>
             From the parent directory your
-            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>source directory</ulink>, 
+            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>, 
             initialize your environment and provide a meaningful 
-            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>build directory</ulink>
+            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
             name:
             <literallayout class='monospaced'>
      $ source poky/&OE_INIT_FILE; mybuilds
@@ -793,7 +785,7 @@
             At this point, the <filename>mybuilds</filename> directory has been created for you 
             and it is now your current working directory.
             If you don't provide your own directory name it defaults to <filename>build</filename>,
-            which is inside the source directory.
+            which is inside the Source Directory.
         </para>
     </section>
 
@@ -802,7 +794,7 @@
 
         <para>
             Initializing the build environment creates a <filename>conf/local.conf</filename> configuration file
-            in the build directory.
+            in the Build Directory.
             You need to manually edit this file to specify the machine you are building and to optimize
             your build time.
             Here are the minimal changes to make:

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

@@ -3,11 +3,10 @@ KBRANCH_routerstationpro = "standard/routerstationpro"
 KBRANCH_mpc8315e-rdb = "standard/fsl-mpc8315e-rdb"
 KBRANCH_beagleboard = "standard/beagleboard"
 
-SRCREV_machine_atom-pc ?= "59c3ff750831338d05ab67d5efd7fc101c451aff"
-SRCREV_machine_routerstationpro ?= "009935376be574746446f4bead6f0fb7b40d6d79"
-SRCREV_machine_mpc8315e-rdb ?= "6b18b6f483716b757c7c8642fa3792235118bb63"
-SRCREV_machine_beagleboard ?= "59c3ff750831338d05ab67d5efd7fc101c451aff"
-
+SRCREV_machine_atom-pc ?= "449f7f520350700858f21a5554b81cc8ad23267d"
+SRCREV_machine_routerstationpro ?= "27e8b8dabfed786aaaafd2f7104c141597830089"
+SRCREV_machine_mpc8315e-rdb ?= "524ce8107febcfd88717f54d50d36ca7c6e6e437"
+SRCREV_machine_beagleboard ?= "449f7f520350700858f21a5554b81cc8ad23267d"
 
 COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb"
 COMPATIBLE_MACHINE_routerstationpro = "routerstationpro"

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

@@ -13,8 +13,11 @@ DISTRO_PN_ALIAS_pn-aaina = "Intel"
 DISTRO_PN_ALIAS_pn-abiword-embedded = "Fedora=abiword Ubuntu=abiword"
 DISTRO_PN_ALIAS_pn-adt-installer = "Intel"
 DISTRO_PN_ALIAS_pn-alsa-state = "OE-Core"
+DISTRO_PN_ALIAS_pn-anjuta-remote-run = "OpenedHand"
 DISTRO_PN_ALIAS_pn-augeas = "Ubuntu=libaugeas0 Debian=libaugeas0"
 DISTRO_PN_ALIAS_pn-avahi-ui = "Ubuntu=avahi-discover Debian=avahi-discover"
+DISTRO_PN_ALIAS_pn-babeltrace = "OSPDT"
+DISTRO_PN_ALIAS_pn-bdwgc = "OSPDT"
 DISTRO_PN_ALIAS_pn-bigreqsproto = "Meego=xorg-x11-proto-bigreqsproto"
 DISTRO_PN_ALIAS_pn-blktool = "Debian=blktool Mandriva=blktool"
 DISTRO_PN_ALIAS_pn-bluez4= "Fedora=bluez Ubuntu=bluez Debian=bluez-utils Opensuse=bluez"
@@ -22,6 +25,7 @@ DISTRO_PN_ALIAS_pn-bluez4="Meego=bluz Fedora=bluz Ubuntu=bluz OpenSuSE=bluz Mand
 DISTRO_PN_ALIAS_pn-bluez-dtl1-workaround = "OE-Core"
 DISTRO_PN_ALIAS_pn-btrfs-tools = "Debian=btrfs-tools Fedora=btrfs-progs"
 DISTRO_PN_ALIAS_pn-builder = "OE-Core"
+DISTRO_PN_ALIAS_pn-build-appliance-image = "OSPDT"
 DISTRO_PN_ALIAS_pn-calibrateproto = "OSPDT upstream=http://cgit.freedesktop.org/xorg/lib/libXCalibrate/"
 DISTRO_PN_ALIAS_pn-calibrateproto = "OSPDT upstream=http://cgit.freedesktop.org/xorg/proto/calibrateproto"
 DISTRO_PN_ALIAS_pn-cdrtools = "OpenSUSE=cdrtools OSPDT"
@@ -30,8 +34,9 @@ DISTRO_PN_ALIAS_pn-claws-plugin-maildir = "Fedora=claws-mail-plugins OpenSuSE=cl
 DISTRO_PN_ALIAS_pn-claws-plugin-mailmbox = "Fedora=claws-mail-plugins OpenSuSE=claws-mail-extra-plugins Debian=claws-mail-extra-plugins"
 DISTRO_PN_ALIAS_pn-claws-plugin-rssyl = "Fedora=claws-mail-plugins OpenSuSE=claws-mail-extra-plugins Debian=claws-mail-extra-plugins"
 DISTRO_PN_ALIAS_pn-clipboard-manager = "OpenedHand"
-DISTRO_PN_ALIAS_pn-clutter-1.8 = "Fedora=clutter OpenSuse=clutter Ubuntu=clutter-1.0 Mandriva=clutter Debian=clutter"
 DISTRO_PN_ALIAS_pn-clutter = "Fedora=clutter OpenSuse=clutter Ubuntu=clutter-1.0 Mandriva=clutter Debian=clutter"
+DISTRO_PN_ALIAS_pn-clutter-1.8 = "Fedora=clutter OpenSuse=clutter Ubuntu=clutter-1.0 Mandriva=clutter Debian=clutter"
+DISTRO_PN_ALIAS_pn-clutter-box2d = "Meego=clutter-box2d"
 DISTRO_PN_ALIAS_pn-clutter-gst-1.8 = "Fedora=clutter-gst Debian=libclutter-gst"
 DISTRO_PN_ALIAS_pn-clutter-gtk-1.8 = "Fedora=clutter-gtk OpenSuSE=clutter-gtk Ubuntu=clutter-gtk-0.10 Mandriva=clutter-gtk Debian=clutter-gtk"
 DISTRO_PN_ALIAS_pn-cogl = "Fedora=cogl OpenSuse=cogl Ubuntu=cogl Mandriva=cogl Debian=cogl"
@@ -64,7 +69,7 @@ DISTRO_PN_ALIAS_pn-core-image-sato-sdk-directdisk = "OE-Core"
 DISTRO_PN_ALIAS_pn-core-image-sato-sdk-live = "OE-Core"
 DISTRO_PN_ALIAS_pn-core-image-sato-sdk = "OE-Core"
 DISTRO_PN_ALIAS_pn-core-image-sdk = "OE-Core"
-DISTRO_PN_ALIAS_pn-core-x11 = "OE-Core"
+DISTRO_PN_ALIAS_pn-core-image-x11 = "OE-Core"
 DISTRO_PN_ALIAS_pn-cross-localedef = "OSPDT"
 DISTRO_PN_ALIAS_pn-cwautomacros= "OSPDT upstream=http://cwautomacros.berlios.de/"
 DISTRO_PN_ALIAS_pn-damageproto = "Meego=xorg-x11-proto-damageproto"
@@ -72,9 +77,9 @@ DISTRO_PN_ALIAS_pn-db = "Debian=db5.1 Ubuntu=db5.1"
 DISTRO_PN_ALIAS_pn-dbus-wait = "OpenedHand"
 DISTRO_PN_ALIAS_pn-directfb-examples = "Debian=directfb Fedora=directfb"
 DISTRO_PN_ALIAS_pn-distcc = "Debian=distcc Fedora=distcc"
+DISTRO_PN_ALIAS_pn-distcc-config = "OpenedHand"
 DISTRO_PN_ALIAS_pn-dmxproto = "Meego=xorg-x11-proto-dmxproto Ubuntu=x11proto-dmx Debian=x11proto-dmx"
-DISTRO_PN_ALIAS_pn-docbook-dsssl-stylesheet = "Fedora=docbook-style-dsssl Ubuntu=docbook-dsssl"
-DISTRO_PN_ALIAS_pn-docbook-dsssl-stylesheet-native = "Fedora=docbook-style-dsssl Ubuntu=docbook-dsssl"
+DISTRO_PN_ALIAS_pn-docbook-dsssl-stylesheets = "Fedora=docbook-style-dsssl Ubuntu=docbook-dsssl"
 DISTRO_PN_ALIAS_pn-docbook-sgml-dtd-3.1 = "Fedora=docbook-dtds Mandriva=docbook-dtd31-sgml"
 DISTRO_PN_ALIAS_pn-docbook-sgml-dtd-4.1 = "Fedora=docbook-dtds Mandriva=docbook-dtd41-sgml"
 DISTRO_PN_ALIAS_pn-docbook-sgml-dtd-4.5 = "Fedora=docbook-dtds Mandriva=docbook-dtd42-sgml"
@@ -84,7 +89,8 @@ DISTRO_PN_ALIAS_pn-dtc = "Fedora=dtc Ubuntu=dtc"
 DISTRO_PN_ALIAS_pn-dtc-native = "Fedora=dtc Ubuntu=dtc"
 DISTRO_PN_ALIAS_pn-eds-tools = "OpenedHand"
 DISTRO_PN_ALIAS_pn-eee-acpi-scripts = "Debian=eeepc-acpi-scripts Ubuntu=eeepc-acpi-scripts"
-DISTRO_PN_ALIAS_pn-eglibc-locale-nativesdk = "OE-Core"
+DISTRO_PN_ALIAS_pn-eglibc = "OE-Core"
+DISTRO_PN_ALIAS_pn-eglibc-initial = "OE-Core"
 DISTRO_PN_ALIAS_pn-eglibc-locale = "OE-Core"
 DISTRO_PN_ALIAS_pn-emgd-driver-bin = "Intel"
 DISTRO_PN_ALIAS_pn-encodings = "Ubuntu=xfonts-encodings Mandriva=x11-font-encodings Debian=xfonts-encodings"
@@ -111,9 +117,11 @@ DISTRO_PN_ALIAS_pn-gcc-runtime = "Ubuntu=gcc Fedora=gcc"
 DISTRO_PN_ALIAS_pn-gconf-dbus = "Meego=GConf-dbus"
 DISTRO_PN_ALIAS_pn-gdk-pixbuf-csource-native = "Debian=libgdk-pixbuf2.0-0 Fedora=gdk-pixbuf2"
 DISTRO_PN_ALIAS_pn-gdk-pixbuf = "Debian=libgdk-pixbuf2.0 Fedora=gdk-pixbuf"
+DISTRO_PN_ALIAS_pn-gettext-minimal-native = "Debian=gettext Fedora=gettext"
 DISTRO_PN_ALIAS_pn-glib-2.0 = "Meego=glib2 Fedora=glib2 OpenSuSE=glib2 Ubuntu=glib2.0 Mandriva=glib2.0 Debian=glib2.0"
 DISTRO_PN_ALIAS_pn-glproto = "Meego=xorg-x11-proto-glproto"
 DISTRO_PN_ALIAS_pn-gnu-config = "OpenedHand"
+DISTRO_PN_ALIAS_pn-grub-efi-i586 = "Ubuntu=grub Fedora=grub"
 DISTRO_PN_ALIAS_pn-gst-ffmpeg = "Mandriva=gstreamer0.10-ffmpeg Debian=gstreamer0.10-ffmpeg"
 DISTRO_PN_ALIAS_pn-gst-fluendo-mp3 = "Debian=gstreamer0.10-fluendo-mp3 Ubuntu=gstreamer0.10-fluendo-mp3"
 DISTRO_PN_ALIAS_pn-gst-fluendo-mpegdemux = "Ubuntu=gstreamer0.10-fluendo-mpegdemux Debian=gstreamer0.10-fluendo-mpegdemux"
@@ -124,6 +132,7 @@ DISTRO_PN_ALIAS_pn-gst-plugins-bad = "Fedora=gstreamer-plugins-bad-free OpenSuSE
 DISTRO_PN_ALIAS_pn-gst-plugins-base = "Meego=gst-plugins-base Fedora=gstreamer-plugins-base OpenSuSE=gstreamer-plugins-base Ubuntu=gst-plugins-base0.10 Mandriva=gstreamer0.10-plugins-base Debian=gst-plugins-base0.10"
 DISTRO_PN_ALIAS_pn-gst-plugins-good = "Meego=gst-plugins-good Fedora=gstreamer-plugins-good OpenSuSE=gstreamer-plugins-good Ubuntu=gst-plugins-good0.10 Mandriva=gstreamer0.10-plugins-good Debian=gst-plugins-good0.10"
 DISTRO_PN_ALIAS_pn-gst-plugins-ugly = "OpenSuSE=gstreamer-plugins-ugly Mandriva=gstreamer0.10-plugins-ugly Debian=gst-plugins-ugly0.10"
+DISTRO_PN_ALIAS_pn-gtk-doc-stub = "Fedora=gtk-doc Ubuntu=gtk-doc"
 DISTRO_PN_ALIAS_pn-gtk-engines = "Fedora=gtk2-engines OpenSuSE=gtk2-engines Ubuntu=gtk2-engines Mandriva=gtk-engines2 Debian=gtk2-engines"
 DISTRO_PN_ALIAS_pn-gtkhtml2 = "Debian=libgtkhtml2-0 Fedora=gtkhtml2"
 DISTRO_PN_ALIAS_pn-gtk+ = "Meego=gtk2 Fedora=gtk2 OpenSuSE=gtk2 Ubuntu=gtk+2.0 Mandriva=gtk+2.0 Debian=gtk+2.0"
@@ -131,15 +140,19 @@ DISTRO_PN_ALIAS_pn-gtk-sato-engine = "OpenedHand"
 DISTRO_PN_ALIAS_pn-gtk-theme-torturer = "OSPDT upstream=http://wiki.laptop.org/go/GTK_for_OLPC"
 DISTRO_PN_ALIAS_pn-hello-mod = "OE-Core"
 DISTRO_PN_ALIAS_pn-hostap-conf = "OE-Core"
+DISTRO_PN_ALIAS_pn-hwlatdetect = "OSPDT"
 DISTRO_PN_ALIAS_pn-icecc-create-env = "OE-Core"
 DISTRO_PN_ALIAS_pn-imake = "Mandriva=xutils Ubuntu=xutils"
 DISTRO_PN_ALIAS_pn-initramfs-boot = "OE-Core"
+DISTRO_PN_ALIAS_pn-initramfs-framework = "OE-Core"
 DISTRO_PN_ALIAS_pn-initramfs-live-boot = "OE-Core"
 DISTRO_PN_ALIAS_pn-initramfs-live-install = "OE-Core"
+DISTRO_PN_ALIAS_pn-initramfs-live-install-efi = "OE-Core"
 DISTRO_PN_ALIAS_pn-inputproto = "Meego=xorg-x11-proto-inputproto"
 DISTRO_PN_ALIAS_pn-iproute2 = "OSPDT"
 DISTRO_PN_ALIAS_pn-jpeg="OpenSuSE=libjpeg Ubuntu=libjpeg62"
 DISTRO_PN_ALIAS_pn-kbproto = "Meego=xorg-x11-proto-kbproto Ubuntu=x11proto-kb-dev Debian=x11proto-kb-dev"
+DISTRO_PN_ALIAS_pn-kconfig-frontends = "OSPDT"
 DISTRO_PN_ALIAS_pn-kernelshark = "Mandriva=kernelshark Ubuntu=kernelshark"
 DISTRO_PN_ALIAS_pn-kern-tools-native = "OpenedHand"
 DISTRO_PN_ALIAS_pn-kern-tools-native = "Windriver"
@@ -152,14 +165,19 @@ DISTRO_PN_ALIAS_pn-liba52 = "Mandriva=a52dec Debian=a52dec"
 DISTRO_PN_ALIAS_pn-libacpi="Ubuntu=libacpi Mandriva=libacpi"
 DISTRO_PN_ALIAS_pn-libatomics-ops = "Meego=libatomic-ops Debian=libatomic-ops Ubuntu=libatomic-ops OpenSuSE=libatomic-ops Mandriva=libatomic-ops"
 DISTRO_PN_ALIAS_pn-libcheck = "Ubuntu=check Fedora=check OpenSuSE=check"
+DISTRO_PN_ALIAS_pn-libclass-isa-perl = "OSPDT"
 DISTRO_PN_ALIAS_pn-libdrm-poulsbo = "Debian=libdrm-intel1 Ubuntu=libdrm-intel1"
+DISTRO_PN_ALIAS_pn-libdumpvalue-perl = "OSPDT"
+DISTRO_PN_ALIAS_pn-libenv-perl = "OSPDT"
 DISTRO_PN_ALIAS_pn-libfakekey="Meego1.0=libfakekey Debian=libfakekey"
+DISTRO_PN_ALIAS_pn-libfile-checktree-perl = "OSPDT"
 DISTRO_PN_ALIAS_pn-libfribidi = "OpenSuSE=fribidi Ubuntu=fribidi Mandriva=fribidi Debian=fribidi"
 DISTRO_PN_ALIAS_pn-libgcc = "Debian=libgcc4 Ubuntu=libgcc1 OpenSuSE=libgcc46"
 DISTRO_PN_ALIAS_pn-libgdbus = "Intel"
 DISTRO_PN_ALIAS_pn-libglade = "Meego=libglade2 Fedora=libglade2 OpenSuSE=libglade2 Ubuntu=libglade2 Mandriva=libglade2.0 Debian=libglade2"
 DISTRO_PN_ALIAS_pn-libgsmd = "Fedora=gsm Ubuntu=libgsm Debian=libgsm Opensuse=libgsm"
 DISTRO_PN_ALIAS_pn-libgtkstylus = "Debian=libgtkstylus Ubuntu=libgtkstylus"
+DISTRO_PN_ALIAS_pn-libi18n-collate-perl = "OSPDT"
 DISTRO_PN_ALIAS_pn-libiconv = "Fedora=mingw-libiconv Opensuse=cross-mingw-libiconv"
 DISTRO_PN_ALIAS_pn-libjson = "Ubuntu=libjson0-dev Debian=libjson0-dev"
 DISTRO_PN_ALIAS_pn-libksba = "Fedora=libksba Debian=libksba8"
@@ -172,6 +190,7 @@ DISTRO_PN_ALIAS_pn-libowl-av = "OpenedHand"
 DISTRO_PN_ALIAS_pn-libowl = "Debian=owl OpenedHand"
 DISTRO_PN_ALIAS_pn-libpam = "Meego=pam Fedora=pam OpenSuSE=pam Ubuntu=pam Mandriva=pam Debian=pam"
 DISTRO_PN_ALIAS_pn-libpcre = "Mandriva=libpcre0 Fedora=pcre"
+DISTRO_PN_ALIAS_pn-libpod-plainer-perl = "OSPDT"
 DISTRO_PN_ALIAS_pn-libsamplerate0 = "Meego=libsamplerate Fedora=libsamplerate OpenSuSE=libsamplerate Ubuntu=libsamplerate Mandriva=libsamplerate Debian=libsamplerate"
 DISTRO_PN_ALIAS_pn-libsdl = "Fedora=SDL Opensuse=SDL"
 DISTRO_PN_ALIAS_pn-libsndfile1 = "Meego=libsndfile Fedora=libsndfile OpenSuSE=libsndfile Ubuntu=libsndfile Mandriva=libsndfile Debian=libsndfile"
@@ -197,11 +216,17 @@ DISTRO_PN_ALIAS_pn-linux-libc-headers = "Debian=linux-kernel-headers Ubuntu=linu
 DISTRO_PN_ALIAS_pn-linux-libc-headers-yocto = "Debian=linux-kernel-headers Ubuntu=linux-kernel-headers"
 DISTRO_PN_ALIAS_pn-linux-yocto = "Debian=linux-base Ubuntu=linux"
 DISTRO_PN_ALIAS_pn-linux-yocto-rt = "Debian=linux-base Ubuntu=linux"
+DISTRO_PN_ALIAS_pn-linux-yocto-tiny = "OSPDT"
+DISTRO_PN_ALIAS_pn-lsbinitscripts = "Windriver"
 DISTRO_PN_ALIAS_pn-lsbsetup = "Windriver"
+DISTRO_PN_ALIAS_pn-lsbtest = "Windriver"
 DISTRO_PN_ALIAS_pn-ltp = "Ubuntu=ltp"
 DISTRO_PN_ALIAS_pn-lttng-control = "OSPDT upstream=http://lttng.org/"
+DISTRO_PN_ALIAS_pn-lttng-modules = "OSPDT upstream=http://lttng.org/"
+DISTRO_PN_ALIAS_pn-lttng-tools = "OSPDT upstream=http://lttng.org/"
 DISTRO_PN_ALIAS_pn-lttng-ust = "OSPDT upstream=http://lttng.org/"
 DISTRO_PN_ALIAS_pn-lttng-viewer = "OSPDT upstream=http://lttng.org/"
+DISTRO_PN_ALIAS_pn-lttng2-ust = "OSPDT upstream=http://lttng.org/"
 DISTRO_PN_ALIAS_pn-makedepend = "Mandriva=makedepend Ubuntu=xutils-dev"
 DISTRO_PN_ALIAS_pn-makedevs = "OE-Core"
 DISTRO_PN_ALIAS_pn-matchbox-config-gtk = "OpenedHand"
@@ -223,12 +248,13 @@ DISTRO_PN_ALIAS_pn-menu-cache = "OSPDT"
 DISTRO_PN_ALIAS_pn-mesa-dri = "Fedora=mesa Ubuntu=libgl1-mesa-dri"
 DISTRO_PN_ALIAS_pn-mesa-dri-glsl-native = "Fedora=mesa Ubuntu=libgl1-mesa-dri"
 DISTRO_PN_ALIAS_pn-meta-environment-i586 = "OE-Core"
-DISTRO_PN_ALIAS_pn-meta-ide-support = 'OE-Core'
+DISTRO_PN_ALIAS_pn-meta-ide-support = "OE-Core"
 DISTRO_PN_ALIAS_pn-meta-toolchain-gmae = "OE-Core"
 DISTRO_PN_ALIAS_pn-meta-toolchain = "OE-Core"
 DISTRO_PN_ALIAS_pn-meta-toolchain-qte = "OE-Core"
-DISTRO_PN_ALIAS_pn-meta-toolchain-sdk = "OE-Core"
 DISTRO_PN_ALIAS_pn-mkfontdir = "Mandriva=mkfontdir Ubuntu=xfonts-utils Fedora=xorg-x11-font-utils"
+DISTRO_PN_ALIAS_pn-meta-toolchain-sdk = "OE-Core"
+DISTRO_PN_ALIAS_pn-mini-x-session = "OSPDT"
 DISTRO_PN_ALIAS_pn-mkfontscale = "Mandriva=mkfontscale Ubuntu=xfonts-utils Fedora=xorg-x11-font-utils"
 DISTRO_PN_ALIAS_pn-mktemp = "Mandriva=mktemp Fedora=mktemp"
 DISTRO_PN_ALIAS_pn-moblin-proto = "OE-Core"
@@ -237,20 +263,55 @@ DISTRO_PN_ALIAS_pn-modutils-initscripts = "OE-Core"
 DISTRO_PN_ALIAS_pn-msynctool = "OpenSuse=msynctool Mandriva=msynctool"
 DISTRO_PN_ALIAS_pn-n450-audio = "Intel"
 DISTRO_PN_ALIAS_pn-network-suspend-scripts = "OE-Core"
+DISTRO_PN_ALIAS_pn-nfs-export-root = "OpenedHand"
+DISTRO_PN_ALIAS_pn-npth = "OSPDT"
+DISTRO_PN_ALIAS_pn-ocf-linux = "OSPDT"
 DISTRO_PN_ALIAS_pn-ofono = "Debian=ofono Ubuntu=ofono"
 DISTRO_PN_ALIAS_pn-oh-puzzles = "OpenedHand"
 DISTRO_PN_ALIAS_pn-opkg-collateral = "OE-Core"
 DISTRO_PN_ALIAS_pn-opkg-config-base = "OE-Core"
-DISTRO_PN_ALIAS_pn-opkg-nogpg-native = "OE-Core"
-DISTRO_PN_ALIAS_pn-opkg-nogpg-nativesdk = "OE-Core"
-DISTRO_PN_ALIAS_pn-opkg-nogpg = "OE-Core"
-DISTRO_PN_ALIAS_pn-opkg_nogpg = "OSPDT upstream=http://svn.openmoko.org/trunk/src/tar"
+DISTRO_PN_ALIAS_pn-opkg-nogpg = "OSPDT upstream=http://svn.openmoko.org/trunk/src/tar"
 DISTRO_PN_ALIAS_pn-opkg = "OSPDT upstream=http://svn.openmoko.org/trunk/src/tar"
 DISTRO_PN_ALIAS_pn-opkg-utils = "OSPDT upstream=http://svn.openmoko.org/trunk/src/target/opkg/"
 DISTRO_PN_ALIAS_pn-oprofileui = "Fedora=oprofileui Ubuntu=oprofile-gui Debian=oprofile-gui"
+DISTRO_PN_ALIAS_pn-oprofileui-server = "Fedora=oprofileui Ubuntu=oprofile-gui Debian=oprofile-gui"
 DISTRO_PN_ALIAS_pn-orinoco-conf = "OE-Core"
 DISTRO_PN_ALIAS_pn-owl-video = "OpenedHand"
 DISTRO_PN_ALIAS_pn-package-index = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-base = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core-basic = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core-boot = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core-clutter = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core-console = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core-device-devel = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core-gtk-directfb = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core-lsb = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core-nfs = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core-qt = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core-qt4e = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core-sdk-gmae = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core-sdk = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core-ssh-dropbear = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core-ssh-openssh = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core-standalone-gmae-sdk-target = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core-standalone-sdk-target = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core-tools-debug = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core-tools = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core-tools-profile = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core-tools-testapps = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core-x11-mini = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core-x11 = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core-x11-base = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core-x11-sato = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-core-x11-xserver = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-cross-canadian-i586 = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-qt4e = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-qte-toolchain-host = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-qte-toolchain-target = "Intel"
+DISTRO_PN_ALIAS_pn-packagegroup-sdk-host = "OE-Core"
+DISTRO_PN_ALIAS_pn-packagegroup-self-hosted = "OE-Core"
+DISTRO_PN_ALIAS_pn-perf = "OSPDT"
 DISTRO_PN_ALIAS_pn-pointercal = "OE-Core"
 DISTRO_PN_ALIAS_pn-poky-feed-config-opkg = "OE-Core"
 DISTRO_PN_ALIAS_pn-pong-clock = "OpenedHand"
@@ -271,6 +332,7 @@ DISTRO_PN_ALIAS_pn-python-pygtk = "Debian=python-gtk2 Fedora=pygtk2 OpenSuSE=pyt
 DISTRO_PN_ALIAS_pn-python-pyrex = "Mandriva=python-pyrex Ubuntu=python-pyrex"
 DISTRO_PN_ALIAS_pn-python-scons = "Fedora=scons OpenSuSE=scons Ubuntu=scons Mandriva=scons Debian=scons"
 DISTRO_PN_ALIAS_pn-python-ZSI = "OE-Core"
+DISTRO_PN_ALIAS_pn-qemu-helper = "OpenedHand"
 DISTRO_PN_ALIAS_pn-qemu-config = "OpenedHand"
 DISTRO_PN_ALIAS_pn-qemugl = "OpenedHand"
 DISTRO_PN_ALIAS_pn-qemu-helper-native = "OpenedHand"
@@ -281,7 +343,7 @@ DISTRO_PN_ALIAS_pn-qt4-embedded = "OSPDT"
 DISTRO_PN_ALIAS_pn-qt4-graphics-system = "OE-Core"
 DISTRO_PN_ALIAS_pn-qt4-native = "Fedora=qt4 Debian=qt4-dev-tools"
 DISTRO_PN_ALIAS_pn-qt4-native = "Mandriva=libqt4-devel Ubuntu=libqt4-dev"
-DISTRO_PN_ALIAS_pn-qt4-tools-nativesdk = "Mandriva=libqt4-devel Ubuntu=libqt4-dev"
+DISTRO_PN_ALIAS_pn-qt4-tools = "Mandriva=libqt4-devel Ubuntu=libqt4-dev"
 DISTRO_PN_ALIAS_pn-qt4-x11-free = "Ubuntu=qt-x11-free Debian=qt-x11-free"
 DISTRO_PN_ALIAS_pn-qt-demo-init = "OE-Core"
 DISTRO_PN_ALIAS_pn-qt-mobility-embedded = "Ubuntu=qtmobility-dev Debian=qtmobility-dev"
@@ -289,9 +351,11 @@ DISTRO_PN_ALIAS_pn-qt-mobility-x11 = "Ubuntu=qtmobility-dev Debian=qtmobility-de
 DISTRO_PN_ALIAS_pn-quicky = "OSPDT"
 DISTRO_PN_ALIAS_pn-randrproto = "Meego=xorg-x11-proto-randrproto"
 DISTRO_PN_ALIAS_pn-recordproto = "Meego=xorg-x11-proto-recordproto"
+DISTRO_PN_ALIAS_pn-remake = "Mandriva=remake Debian=remake"
 DISTRO_PN_ALIAS_pn-renderproto = "Meego=xorg-x11-proto-renderproto"
 DISTRO_PN_ALIAS_pn-resourceproto = "Meego=xorg-x11-proto-resourceproto"
 DISTRO_PN_ALIAS_pn-rgb = "Fedora=xorg-X11-server-utils Debian=x11-xserver-utils"
+DISTRO_PN_ALIAS_pn-rpmresolve = "OSPDT"
 DISTRO_PN_ALIAS_pn-rt-tests = "Debian=rt-tests Ubuntu=rt-tests"
 DISTRO_PN_ALIAS_pn-run-postinsts = "OE-Core"
 DISTRO_PN_ALIAS_pn-sato-icon-theme = "OpenedHand"
@@ -304,6 +368,7 @@ DISTRO_PN_ALIAS_pn-sgmlspl = "Debian=sgmlspl Ubuntu=sgmlspl"
 DISTRO_PN_ALIAS_pn-shadow-securetty = "Ubuntu=shadow Fedora=shadow"
 DISTRO_PN_ALIAS_pn-shadow-sysroot = "Ubuntu=shadow Fedora=shadow"
 DISTRO_PN_ALIAS_pn-shasum-native = "OE-Core"
+DISTRO_PN_ALIAS_pn-shutdown-desktop = "OpenedHand"
 DISTRO_PN_ALIAS_pn-signgp-native = "OE-Core"
 DISTRO_PN_ALIAS_pn-stat = "Debian=coreutils Fedora=coreutils"
 DISTRO_PN_ALIAS_pn-swabber-native = "OE-Core"
@@ -311,41 +376,14 @@ DISTRO_PN_ALIAS_pn-systemtap-uprobes = "Ubuntu=systemtap Debian=systemtap"
 DISTRO_PN_ALIAS_pn-sysvinit-inittab = "OE-Core"
 DISTRO_PN_ALIAS_pn-table = "Intel"
 DISTRO_PN_ALIAS_pn-tar-replacement-native = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-base = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-core-basic = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-core-boot = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-core-clutter = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-core-console = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-core-gtk-directfb = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-core-lsb = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-core-nfs = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-core = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-core-qt = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-core-sdk-gmae = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-core-sdk = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-core-ssh-dropbear = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-core-ssh-openssh = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-core-standalone-gmae-sdk-target = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-core-standalone-sdk-target = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-core-tools-debug = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-core-tools = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-core-tools-profile = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-core-tools-testapps = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-core-x11-mini = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-core-x11 = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-core-x11-sato = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-cross-canadian-i586 = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-qt4e = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-qte-toolchain-host-nativesdk = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-qte-toolchain-host-natives = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-qte-toolchain-target = "Intel"
-DISTRO_PN_ALIAS_pn-packagegroup-sdk-host = "OE-Core"
-DISTRO_PN_ALIAS_pn-packagegroup-self-hosted = "OE-Core"
 DISTRO_PN_ALIAS_pn-tcf-agent = "Windriver upstream=http://www.eclipse.org/dsdp/tm/"
+DISTRO_PN_ALIAS_pn-telepathy-python = "Debian=telepathy-python Ubuntu=telepathy-python"
+DISTRO_PN_ALIAS_pn-tiny-init = "OSPDT"
 DISTRO_PN_ALIAS_pn-tinylogin = "Debian=busybox Ubuntu=busybox Mandriva=busybox"
 DISTRO_PN_ALIAS_pn-trace-cmd = "Mandriva=trace-cmd Ubuntu=trace-cmd"
 DISTRO_PN_ALIAS_pn-trapproto = "Meego=xorg-x11-proto-trapproto"
 DISTRO_PN_ALIAS_pn-tremor = "OSPDT upstream=http://www.xiph.org/vorbis/"
+DISTRO_PN_ALIAS_pn-tslib = "Debian=tslib Ubuntu=tslib"
 DISTRO_PN_ALIAS_pn-ttf-bitstream-vera = "Debian=ttf-bitstream-vera Ubuntu=ttf-bitstream-vera"
 DISTRO_PN_ALIAS_pn-tzcode = "OSPDT"
 DISTRO_PN_ALIAS_pn-ubootchart = "OSPDT upstream=http://code.google.com/p/ubootchart"
@@ -361,14 +399,17 @@ DISTRO_PN_ALIAS_pn-util-macros = "Meego=xorg-x11-util-macros Fedora=xorg-x11-uti
 DISTRO_PN_ALIAS_pn-v86d = "Debian=v86d Ubuntu=v86d"
 DISTRO_PN_ALIAS_pn-videoproto = "Meego=xorg-x11-proto-videoproto"
 DISTRO_PN_ALIAS_pn-watchdog = "Debian=watchdog Ubuntu=watchdog Mandriva=watchdog"
-DISTRO_PN_ALIAS_pn-webkit-gtk = "Fedora=webkitgtk"
 DISTRO_PN_ALIAS_pn-webkit-gtk = "Fedora=webkitgtk Ubuntu=libwebkit"
 DISTRO_PN_ALIAS_pn-web = "OpenedHand"
 DISTRO_PN_ALIAS_pn-web-webkit = "OpenedHand"
+DISTRO_PN_ALIAS_pn-which = "Mandriva=which Fedora=which"
 DISTRO_PN_ALIAS_pn-wpa-supplicant = "Meego=wpa_supplicant Fedora=wpa_supplicant OpenSuSE=wpa_supplicant Ubuntu=wpasupplicant Mandriva=wpa_supplicant Debian=wpasupplicant"
 DISTRO_PN_ALIAS_pn-x11-common = "OE-Core"
 DISTRO_PN_ALIAS_pn-x11perf = "Fedora=xorg-x11-apps Ubuntu=x11-apps"
 DISTRO_PN_ALIAS_pn-x11vnc = "Fedora=x11vnc Ubuntu=x11vnc"
+DISTRO_PN_ALIAS_pn-xcb-util-wm = "Debian=xcb-util Fedora=xcb-util"
+DISTRO_PN_ALIAS_pn-xcb-util-image = "Debian=xcb-util Fedora=xcb-util"
+DISTRO_PN_ALIAS_pn-xcb-util-keysyms = "Debian=xcb-util Fedora=xcb-util"
 DISTRO_PN_ALIAS_pn-xcmiscproto = "Meego=xorg-x11-proto-xcmiscproto"
 DISTRO_PN_ALIAS_pn-xcursor-transparent-theme = "OpenedHand"
 DISTRO_PN_ALIAS_pn-xdpyinfo = "Fedora=xorg-x11-utils Ubuntu=x11-utils"

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

@@ -37,7 +37,7 @@ DISTRO = "poky-tiny"
 # Distro config is evaluated after the machine config, so we have to explicitly
 # set the kernel provider to override a machine config.
 PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-tiny"
-PREFERRED_VERSION_linux-yocto-tiny = "3.2%"
+PREFERRED_VERSION_linux-yocto-tiny = "3.4%"
 
 # We can use packagegroup-core-boot, but in the future we may need a new packagegroup-core-tiny
 #POKY_DEFAULT_EXTRA_RDEPENDS += "packagegroup-core-boot"

meta-yocto/conf/distro/poky.conf

@@ -1,8 +1,8 @@
 DISTRO = "poky"
-DISTRO_NAME = "Poky 7.0 (Yocto Project 1.2 Reference Distro)"
-DISTRO_VERSION = "1.2+snapshot-${DATE}"
+DISTRO_NAME = "Poky 8.0.2 (Yocto Project 1.3.2 Reference Distro)"
+DISTRO_VERSION = "1.3.2"
 SDK_VENDOR = "-pokysdk"
-SDK_VERSION := "${@'${DISTRO_VERSION}'.replace('snapshot-${DATE}','snapshot')}"
+SDK_VERSION := "${DISTRO_VERSION}"
 
 MAINTAINER = "Poky <poky@yoctoproject.org>"
 
@@ -70,8 +70,11 @@ CONNECTIVITY_CHECK_URIS ?= " \
 
 SANITY_TESTED_DISTROS ?= " \
             Yocto (Built by Poky 7.0) 1.2 \n \
-            Poky 7.0 (Yocto Project 1.2 Reference Distro) \n \
-            Poky 8.0 (Yocto Project 1.3 Reference Distro) \n \
+            Yocto (Built by Poky 8.0) 1.3 \n \
+            Poky 7.0 (Yocto Project 1.2 Reference Distro) 1.2 \n \
+            Poky 8.0 (Yocto Project 1.3 Reference Distro) 1.3 \n \
+            Poky 8.0.1 (Yocto Project 1.3.1 Reference Distro) 1.3.1 \n \
+            Poky 8.0.2 (Yocto Project 1.3.1 Reference Distro) 1.3.2 \n \
             Ubuntu 10.04.4 LTS \n \
             Ubuntu 11.10 \n \
             Ubuntu 12.04 LTS \n \
@@ -85,6 +88,7 @@ SANITY_TESTED_DISTROS ?= " \
             CentOS release 5.8 (Final) \n \
             CentOS release 6.3 (Final) \n \
             Debian GNU/Linux 6.0.6 (squeeze) \n \
+            Debian GNU/Linux 7.0 (wheezy) \n \
             openSUSE 11.4 \n \
             openSUSE 12.1 \n \
             openSUSE 12.2 \n \

meta-yocto/conf/local.conf.sample

@@ -216,9 +216,12 @@ PATCHRESOLVE = "noop"
 # would contain the sstate-cache results from previous builds (possibly from other 
 # machines). This variable works like fetcher MIRRORS/PREMIRRORS and points to the 
 # cache locations to check for the shared objects.
+# NOTE: if the mirror uses the same structure as SSTATE_DIR, you need to add PATH
+# at the end as shown in the examples below. This will be substituted with the
+# correct path within the directory structure.
 #SSTATE_MIRRORS ?= "\
-#file://.* http://someserver.tld/share/sstate/ \n \
-#file://.* file:///some/local/dir/sstate/"
+#file://.* http://someserver.tld/share/sstate/PATH \n \
+#file://.* file:///some/local/dir/sstate/PATH"
 
 # CONF_VERSION is increased each time build/conf/ changes incompatibly and is used to
 # track the version of this file when it was generated. This can safely be ignored if

meta/classes/bootimg.bbclass

@@ -163,8 +163,15 @@ build_hddimg() {
 		# done in blocks, thus the mod by 16 instead of 32.
 		BLOCKS=$(expr $BLOCKS + $(expr 16 - $(expr $BLOCKS % 16)))
 
+		# mkdosfs will sometimes use FAT16 when it is not appropriate,
+		# resulting in a boot failure from SYSLINUX. Use FAT32 for
+		# images larger than 512MB, otherwise let mkdosfs decide.
+		if [ $(expr $BLOCKS / 1024) -gt 512 ]; then
+			FATSIZE="-F 32"
+		fi
+
 		IMG=${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.hddimg
-		mkdosfs -n ${BOOTIMG_VOLUME_ID} -S 512 -C ${IMG} ${BLOCKS}
+		mkdosfs ${FATSIZE} -n ${BOOTIMG_VOLUME_ID} -S 512 -C ${IMG} ${BLOCKS}
 		# Copy HDDDIR recursively into the image file directly
 		mcopy -i ${IMG} -s ${HDDDIR}/* ::/
 

meta/classes/buildhistory.bbclass

@@ -403,9 +403,9 @@ END
 		fi
 		# Check if there are new/changed files to commit (other than metadata-revs)
 		repostatus=`git status --porcelain | grep -v " metadata-revs$"`
+		HOSTNAME=`hostname 2>/dev/null || echo unknown`
 		if [ "$repostatus" != "" ] ; then
 			git add .
-			HOSTNAME=`hostname 2>/dev/null || echo unknown`
 			# porcelain output looks like "?? packages/foo/bar"
 			# Ensure we commit metadata-revs with the first commit
 			for entry in `echo "$repostatus" | awk '{print $2}' | awk -F/ '{print $1}' | sort | uniq` ; do

meta/classes/cross-canadian.bbclass

@@ -54,6 +54,13 @@ LDFLAGS = "${BUILDSDK_LDFLAGS} \
 
 DEPENDS_GETTEXT = "gettext-native nativesdk-gettext"
 
+#
+# We need chrpath >= 0.14 to ensure we can deal with 32 and 64 bit
+# binaries
+#
+DEPENDS_append = " chrpath-replacement-native"
+EXTRANATIVEPATH += "chrpath-native"
+
 # Path mangling needed by the cross packaging
 # Note that we use := here to ensure that libdir and includedir are
 # target paths.

meta/classes/distutils-common-base.bbclass

@@ -5,10 +5,13 @@ EXTRA_OEMAKE = ""
 export STAGING_INCDIR
 export STAGING_LIBDIR
 
-PACKAGES = "${PN}-dev ${PN}-dbg ${PN}-doc ${PN}"
+PACKAGES = "${PN}-staticdev ${PN}-dev ${PN}-dbg ${PN}-doc ${PN}"
 
 FILES_${PN} = "${bindir}/* ${libdir}/* ${libdir}/${PYTHON_DIR}/*"
 
+FILES_${PN}-staticdev += "\
+  ${PYTHON_SITEPACKAGES_DIR}/*.a \
+"
 FILES_${PN}-dev += "\
   ${datadir}/pkgconfig \
   ${libdir}/pkgconfig \

meta/classes/distutils.bbclass

@@ -47,12 +47,14 @@ distutils_do_install() {
 
         if test -e ${D}${bindir} ; then	
             for i in ${D}${bindir}/* ; do \
+                sed -i -e s:${STAGING_BINDIR_NATIVE}/python-native/python:${bindir}/env\ python:g $i
                 sed -i -e s:${STAGING_BINDIR_NATIVE}:${bindir}:g $i
             done
         fi
 
         if test -e ${D}${sbindir}; then
             for i in ${D}${sbindir}/* ; do \
+                sed -i -e s:${STAGING_BINDIR_NATIVE}/python-native/python:${bindir}/env\ python:g $i
                 sed -i -e s:${STAGING_BINDIR_NATIVE}:${bindir}:g $i
             done
         fi

meta/classes/gnomebase.bbclass

@@ -7,7 +7,7 @@ GNOME_COMPRESS_TYPE ?= "bz2"
 SECTION ?= "x11/gnome"
 SRC_URI = "${GNOME_MIRROR}/${BPN}/${@gnome_verdir("${PV}")}/${BPN}-${PV}.tar.${GNOME_COMPRESS_TYPE};name=archive"
 
-DEPENDS += "gnome-common"
+DEPENDS += "gnome-common-native"
 
 FILES_${PN} += "${datadir}/application-registry  \
 	${datadir}/mime-info \

meta/classes/imagetest-qemu.bbclass

@@ -75,6 +75,7 @@ def qemuimagetest_main(d):
         os.environ["TARGET_IPSAVE"] = d.getVar("TARGET_IPSAVE", True)
         os.environ["TEST_SERIALIZE"] = d.getVar("TEST_SERIALIZE", True)
         os.environ["SDK_NAME"] = d.getVar("SDK_NAME", True)
+        os.environ["RUNQEMU_LOGFILE"] = d.expand("${T}/log.runqemutest.%s" % os.getpid())
 
         """run Test Case"""
         bb.note("Run %s test in scenario %s" % (case, scen))

meta/classes/kernel-yocto.bbclass

@@ -326,6 +326,8 @@ do_validate_branches() {
 	if [ $? -eq 0 ]; then
 		# restore the branch for builds
 		git checkout -q -f ${KBRANCH}
+        else
+	        git checkout -q master
 	fi
 }
 

meta/classes/kernel.bbclass

@@ -85,7 +85,6 @@ KERNEL_IMAGETYPE_FOR_MAKE = "${@(lambda s: s[:-3] if s[-3:] == ".gz" else s)(d.g
 
 kernel_do_compile() {
 	unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
-	oe_runmake include/linux/version.h CC="${KERNEL_CC}" LD="${KERNEL_LD}"
 	oe_runmake ${KERNEL_IMAGETYPE_FOR_MAKE} ${KERNEL_ALT_IMAGETYPE} CC="${KERNEL_CC}" LD="${KERNEL_LD}"
 	if test "${KERNEL_IMAGETYPE_FOR_MAKE}.gz" = "${KERNEL_IMAGETYPE}"; then
 		gzip -9c < "${KERNEL_IMAGETYPE_FOR_MAKE}" > "${KERNEL_OUTPUT}"
@@ -530,6 +529,7 @@ kernel_do_deploy() {
 	ln -sf ${KERNEL_IMAGE_BASE_NAME}.bin ${KERNEL_IMAGETYPE}
 
 	cp ${COREBASE}/meta/files/deploydir_readme.txt ${DEPLOYDIR}/README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt
+	cd -
 }
 do_deploy[dirs] = "${DEPLOYDIR} ${B}"
 

meta/classes/libc-common.bbclass

@@ -4,6 +4,7 @@ do_install() {
 		h=`echo $r|sed -e's,\.x$,.h,'`
 		install -m 0644 ${S}/sunrpc/rpcsvc/$h ${D}/${includedir}/rpcsvc/
 	done
+	install -d ${D}/${sysconfdir}/ 
 	install -m 0644 ${WORKDIR}/etc/ld.so.conf ${D}/${sysconfdir}/
 	install -d ${D}${localedir}
 	make -f ${WORKDIR}/generate-supported.mk IN="${S}/localedata/SUPPORTED" OUT="${WORKDIR}/SUPPORTED"

meta/classes/license.bbclass

@@ -13,7 +13,7 @@ do_populate_lic[cleandirs] = "${LICSSTATEDIR}"
 license_create_manifest() {
 	mkdir -p ${LICENSE_DIRECTORY}/${IMAGE_NAME}
 	# Get list of installed packages
-	list_installed_packages | grep -v "locale" |sort > ${LICENSE_DIRECTORY}/${IMAGE_NAME}/package.manifest
+	list_installed_packages |sort > ${LICENSE_DIRECTORY}/${IMAGE_NAME}/package.manifest
 	INSTALLED_PKGS=`cat ${LICENSE_DIRECTORY}/${IMAGE_NAME}/package.manifest`
 	LICENSE_MANIFEST="${LICENSE_DIRECTORY}/${IMAGE_NAME}/license.manifest"
 	# remove existing license.manifest file
@@ -21,16 +21,12 @@ license_create_manifest() {
 		rm ${LICENSE_MANIFEST}
 	fi
 	# list of installed packages is broken for deb
+	touch ${LICENSE_MANIFEST}
 	for pkg in ${INSTALLED_PKGS}; do
 		# not the best way to do this but licenses are not arch dependant iirc
 		filename=`ls ${TMPDIR}/pkgdata/*/runtime-reverse/${pkg}| head -1`
 		pkged_pn="$(sed -n 's/^PN: //p' ${filename})"
 
-		# exclude locale recipes
-		if [ "${pkged_pn}" = "*locale*" ]; then
-			continue
-		fi
-
 		# check to see if the package name exists in the manifest. if so, bail.
 		if grep -q "^PACKAGE NAME: ${pkg}" ${LICENSE_MANIFEST}; then
 			continue
@@ -97,9 +93,9 @@ python do_populate_lic() {
 
     pn = d.getVar('PN', True)
     for package in d.getVar('PACKAGES', True):
-        if d.getVar('LICENSE_' + pn + '-' + package, True):
+        if d.getVar('LICENSE_' + package, True):
             license_types = license_types + ' & ' + \
-                            d.getVar('LICENSE_' + pn + '-' + package, True)
+                            d.getVar('LICENSE_' + package, True)
 
     #If we get here with no license types, then that means we have a recipe 
     #level license. If so, we grab only those.

meta/classes/multilib.bbclass

@@ -10,7 +10,9 @@ python multilib_virtclass_handler () {
     e.data.setVar('STAGING_KERNEL_DIR', e.data.getVar('STAGING_KERNEL_DIR', True))
 
     # There should only be one kernel in multilib configs
-    if bb.data.inherits_class('kernel', e.data) or bb.data.inherits_class('module-base', e.data):
+    # We also skip multilib setup for module packages.
+    provides = (e.data.getVar("PROVIDES", True) or "").split()
+    if "virtual/kernel" in provides or bb.data.inherits_class('module-base', e.data):
         raise bb.parse.SkipPackage("We shouldn't have multilib variants for the kernel")
 
     if bb.data.inherits_class('image', e.data):
@@ -75,7 +77,7 @@ python __anonymous () {
     clsextend.map_depends_variable("DEPENDS")
     clsextend.map_packagevars()
     clsextend.map_variable("PROVIDES")
-    clsextend.map_variable("PACKAGES_DYNAMIC")
+    clsextend.map_regexp_variable("PACKAGES_DYNAMIC")
     clsextend.map_variable("PACKAGE_INSTALL")
     clsextend.map_variable("INITSCRIPT_PACKAGES")
 }

meta/classes/package_rpm.bbclass

@@ -324,11 +324,15 @@ package_install_internal_rpm () {
 				rm -f $m
 			fi
 		done
+		sort -u ${target_rootfs}/install/original_solution.manifest -o ${target_rootfs}/install/original_solution.manifest.new
+		mv ${target_rootfs}/install/original_solution.manifest.new ${target_rootfs}/install/original_solution.manifest
 	fi
 
 	# Setup manifest of packages to install...
 	mkdir -p ${target_rootfs}/install
 	rm -f ${target_rootfs}/install/install.manifest
+	rm -f ${target_rootfs}/install/install_multilib.manifest
+	rm -f ${target_rootfs}/install/install_attemptonly.manifest
 
 	# Uclibc builds don't provide this stuff...
 	if [ x${TARGET_OS} = "xlinux" ] || [ x${TARGET_OS} = "xlinux-gnueabi" ] ; then
@@ -428,7 +432,7 @@ package_install_internal_rpm () {
 	fi
 
 	# Now that we have a solution, pull out a list of what to install...
-	echo "Manifest: ${target_rootfs}/install/install.manifest"
+	echo "Manifest: ${target_rootfs}/install/install_solution.manifest"
 	${RPM} -D "_dbpath ${target_rootfs}/install" -qa --qf "%{packageorigin}\n" \
 		--root "${target_rootfs}/install" \
 		-D "__dbi_txn create nofsync private" \
@@ -459,8 +463,8 @@ package_install_internal_rpm () {
 
 	fi
 
-	cat ${target_rootfs}/install/install_solution.manifest > ${target_rootfs}/install/total_solution.manifest
-	cat ${target_rootfs}/install/install_multilib_solution.manifest >> ${target_rootfs}/install/total_solution.manifest
+	cat ${target_rootfs}/install/install_solution.manifest \
+	    ${target_rootfs}/install/install_multilib_solution.manifest | sort -u > ${target_rootfs}/install/total_solution.manifest
 
 	# Construct install scriptlet wrapper
 	cat << EOF > ${WORKDIR}/scriptlet_wrapper
@@ -521,8 +525,8 @@ EOF
 	if [ "${INSTALL_COMPLEMENTARY_RPM}" = "1" ] ; then
 		# Only install packages not already installed (dependency calculation will
 		# almost certainly have added some that have been)
-		sort ${target_rootfs}/install/original_solution.manifest > ${target_rootfs}/install/original_solution_sorted.manifest
-		sort ${target_rootfs}/install/total_solution.manifest > ${target_rootfs}/install/total_solution_sorted.manifest
+		sort -u ${target_rootfs}/install/original_solution.manifest > ${target_rootfs}/install/original_solution_sorted.manifest
+		sort -u ${target_rootfs}/install/total_solution.manifest > ${target_rootfs}/install/total_solution_sorted.manifest
 		comm -2 -3 ${target_rootfs}/install/total_solution_sorted.manifest \
 			${target_rootfs}/install/original_solution_sorted.manifest > \
 			${target_rootfs}/install/diff.manifest

meta/classes/populate_sdk_base.bbclass

@@ -132,11 +132,20 @@ else
 	target_sdk_dir=$(readlink -m $target_sdk_dir)
 fi
 
-printf "You are about to install the SDK to \"$target_sdk_dir\". Proceed[Y/n]?"
+if [ -e "$target_sdk_dir/environment-setup-${REAL_MULTIMACH_TARGET_SYS}" ]; then
+	echo "The directory \"$target_sdk_dir\" already contains a SDK for this architecture."
+	printf "If you continue, existing files will be overwritten! Proceed[y/N]?"
+
+	default_answer="n"
+else
+	printf "You are about to install the SDK to \"$target_sdk_dir\". Proceed[Y/n]?"
+
+	default_answer="y"
+fi
 read answer
 
 if [ "$answer" = "" ]; then
-	answer="y"
+	answer="$default_answer"
 fi
 
 if [ "$answer" != "Y" -a "$answer" != "y" ]; then
@@ -174,9 +183,16 @@ fi
 # replace ${SDKPATH} with the new prefix in all text files: configs/scripts/etc
 find $native_sysroot -type f -exec file '{}' \;|grep ":.*ASCII.*text"|cut -d':' -f1|xargs sed -i -e "s:$DEFAULT_INSTALL_DIR:$target_sdk_dir:g"
 
+# find out all perl scripts in $native_sysroot and modify them replacing the
+# host perl with SDK perl.
+for perl_script in $(grep "^#!.*perl" -rls $native_sysroot); do
+	sed -i -e "s:^#! */usr/bin/perl.*:#! /usr/bin/env perl:g" -e \
+		"s: /usr/bin/perl: /usr/bin/env perl:g" $perl_script
+done
+
 # change all symlinks pointing to ${SDKPATH}
 for l in $(find $native_sysroot -type l); do
-	ln -sf $(readlink $l|sed -e "s:$DEFAULT_INSTALL_DIR:$target_sdk_dir:") $l
+	ln -sfn $(readlink $l|sed -e "s:$DEFAULT_INSTALL_DIR:$target_sdk_dir:") $l
 done
 
 echo done
@@ -191,6 +207,9 @@ exit 0
 
 MARKER:
 EOF
+	# add execution permission
+	chmod +x ${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.sh
+
 	# append the SDK tarball
 	cat ${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.tar.bz2 >> ${SDK_DEPLOY}/${TOOLCHAIN_OUTPUTNAME}.sh
 

meta/classes/rootfs_ipk.bbclass

@@ -14,9 +14,9 @@ do_rootfs[recrdeptask] += "do_package_write_ipk"
 
 do_rootfs[lockfiles] += "${WORKDIR}/ipk.lock"
 
-IPKG_ARGS = "-f ${IPKGCONF_TARGET} -o ${IMAGE_ROOTFS} --force-overwrite --prefer-arch-to-version"
+IPKG_ARGS = "-f ${IPKGCONF_TARGET} -o ${IMAGE_ROOTFS} --force-overwrite --force_postinstall --prefer-arch-to-version"
 # The _POST version also works when constructing the matching SDK
-IPKG_ARGS_POST = "-f ${IPKGCONF_TARGET} -o $INSTALL_ROOTFS_IPK --force-overwrite --prefer-arch-to-version"
+IPKG_ARGS_POST = "-f ${IPKGCONF_TARGET} -o $INSTALL_ROOTFS_IPK --force-overwrite --force_postinstall --prefer-arch-to-version"
 
 OPKG_PREPROCESS_COMMANDS = "package_update_index_ipk; package_generate_ipkg_conf"
 

meta/classes/rootfs_rpm.bbclass

@@ -151,7 +151,7 @@ list_installed_packages() {
 
 	# print the info, need to different return counts
 	if [ "$1" = "arch" ] ; then
-		echo "$GET_LIST" | awk '{print $1, $2}'
+		echo "$GET_LIST" | awk '{PN=$1; gsub("_", "-"); print PN, $2}'
         elif [ "$1" = "file" ] ; then
 		echo "$GET_LIST" | awk '{print $1, $3}'
         else

meta/classes/sanity.bbclass

@@ -566,6 +566,7 @@ def check_sanity(sanity_data):
         if (saved_tmpdir != tmpdir):
             messages = messages + "Error, TMPDIR has changed location. You need to either move it back to %s or rebuild\n" % saved_tmpdir
     else:
+        bb.utils.mkdirhier(tmpdir)
         f = file(checkfile, "w")
         f.write(tmpdir)
     f.close()

meta/classes/sstate.bbclass

@@ -19,9 +19,15 @@ SSTATE_PATHSPEC   = "${SSTATE_DIR}/${SSTATE_EXTRAPATHWILDCARD}*/${SSTATE_PKGSPEC
 
 # In theory we should be using:
 # SSTATE_DUPWHITELIST = "${DEPLOY_DIR_IMAGE}/ ${DEPLOY_DIR}/licenses/ ${DEPLOY_DIR_IPK}/all/ ${DEPLOY_DIR_RPM}/all ${DEPLOY_DIR_DEB}/all/ ${TMPDIR}/pkgdata/all${TARGET_VENDOR}-${TARGET_OS}"
-# However until do_package is not machine specific, we'll have to make do with this:
+# However until do_package is not machine specific, we'll have to make do with all of deploy/pkgdata.
 SSTATE_DUPWHITELIST = "${DEPLOY_DIR}/ ${TMPDIR}/pkgdata/"
-
+# Also need to make cross recipes append to ${PN} and install once for any given PACAGE_ARCH so
+# can avoid multiple installs (e.g. routerstationpro+qemumips both using mips32)
+SSTATE_DUPWHITELIST += "${STAGING_LIBDIR_NATIVE}/${MULTIMACH_TARGET_SYS} ${STAGING_DIR_NATIVE}/usr/libexec/${MULTIMACH_TARGET_SYS} ${STAGING_BINDIR_NATIVE}/${MULTIMACH_TARGET_SYS} ${STAGING_DIR_NATIVE}${includedir_native}/gcc-build-internal-${MULTIMACH_TARGET_SYS}"
+# Also avoid python issues until we fix the python recipe
+SSTATE_DUPWHITELIST += "${STAGING_LIBDIR}/python2.7/config/Makefile ${STAGING_LIBDIR}/libpython2.7 ${STAGING_INCDIR}/python2.7/pyconfig.h"
+# Avoid docbook/sgml catalog warnings for now
+SSTATE_DUPWHITELIST += "${STAGING_ETCDIR_NATIVE}/sgml ${STAGING_DATADIR_NATIVE}/sgml"
 
 SSTATE_SCAN_FILES ?= "*.la *-config *_config"
 SSTATE_SCAN_CMD ?= 'find ${SSTATE_BUILDDIR} \( -name "${@"\" -o -name \"".join(d.getVar("SSTATE_SCAN_FILES", True).split())}" \) -type f'
@@ -150,6 +156,7 @@ def sstate_install(ss, d):
     match = []
     for f in sharedfiles:
         if os.path.exists(f):
+            f = os.path.normpath(f)
             realmatch = True
             for w in whitelist:
                 if f.startswith(w):

meta/classes/toolchain-scripts.bbclass

@@ -26,6 +26,7 @@ toolchain_create_sdk_env_script () {
 	echo 'export OBJDUMP=${TARGET_PREFIX}objdump' >> $script
 	echo 'export AR=${TARGET_PREFIX}ar' >> $script
 	echo 'export NM=${TARGET_PREFIX}nm' >> $script
+	echo 'export M4=m4' >> $script
 	echo 'export TARGET_PREFIX=${TARGET_PREFIX}' >> $script
 	echo 'export CONFIGURE_FLAGS="--target=${TARGET_SYS} --host=${TARGET_SYS} --build=${SDK_ARCH}-linux --with-libtool-sysroot=${SDKTARGETSYSROOT}"' >> $script
 	if [ "${TARGET_OS}" = "darwin8" ]; then
@@ -44,6 +45,7 @@ toolchain_create_sdk_env_script () {
 	echo 'export OECORE_ACLOCAL_OPTS="-I ${SDKPATHNATIVE}/usr/share/aclocal"' >> $script
 	echo 'export OECORE_DISTRO_VERSION="${DISTRO_VERSION}"' >> $script
 	echo 'export OECORE_SDK_VERSION="${SDK_VERSION}"' >> $script
+	echo 'export PYTHONHOME=${SDKPATHNATIVE}${prefix_nativesdk}' >> $script
 }
 
 # This function creates an environment-setup-script in the TMPDIR which enables
@@ -131,6 +133,7 @@ toolchain_create_sdk_env_script_for_installer () {
         echo 'export OECORE_ACLOCAL_OPTS="-I ${SDKPATHNATIVE}/usr/share/aclocal"' >> $script
 	echo 'export OECORE_DISTRO_VERSION="${DISTRO_VERSION}"' >> $script
 	echo 'export OECORE_SDK_VERSION="${SDK_VERSION}"' >> $script
+	echo 'export PYTHONHOME=${SDKPATHNATIVE}${prefix_nativesdk}' >> $script
 }
 
 #we get the cached site config in the runtime

meta/conf/machine/include/arm/arch-armv4.inc

@@ -4,7 +4,13 @@ ARMPKGARCH ?= "armv4"
 
 TUNEVALID[armv4] = "Enable instructions for ARMv4"
 TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv4", "-march=armv4${ARMPKGSFX_THUMB}", "", d)}"
-TARGET_LD_KERNEL_ARCH += "${@bb.utils.contains("TUNE_FEATURES", "armv4", "--fix-v4bx", "", d)}"
+# enable --fix-v4bx when we have armv4 in TUNE_FEATURES, but then disable it when we have also armv5 or thumb
+# maybe we should extend bb.utils.contains to support check for any checkvalues in value, now it does 
+# checkvalues.issubset(val) which cannot be used for negative test of foo neither bar in value
+FIX_V4BX_ARMV4 = "${@bb.utils.contains("TUNE_FEATURES", "armv4", "--fix-v4bx", "", d)}"
+FIX_V4BX_ARMV5 = "${@bb.utils.contains("TUNE_FEATURES", "armv5", "", "${FIX_V4BX_ARMV4}", d)}"
+FIX_V4BX = "${@bb.utils.contains("TUNE_FEATURES", "thumb", "", "${FIX_V4BX_ARMV5}", d)}"
+TARGET_LD_KERNEL_ARCH += "${FIX_V4BX}"
 MACHINEOVERRIDES .= "${@bb.utils.contains("TUNE_FEATURES", "armv4", ":armv4", "" ,d)}"
 
 require conf/machine/include/arm/arch-arm.inc

meta/files/common-licenses/bzip2

@@ -0,0 +1,41 @@
+--------------------------------------------------------------------------
+
+This program, "bzip2", the associated library "libbzip2", and all
+documentation, are copyright (C) 1996-2010 Julian R Seward.  All
+rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+
+1. Redistributions of source code must retain the above copyright
+   notice, this list of conditions and the following disclaimer.
+
+2. The origin of this software must not be misrepresented; you must
+   not claim that you wrote the original software.  If you use this
+   software in a product, an acknowledgment in the product
+   documentation would be appreciated but is not required.
+
+3. Altered source versions must be plainly marked as such, and must
+   not be misrepresented as being the original software.
+
+4. The name of the author may not be used to endorse or promote
+   products derived from this software without specific prior written
+   permission.
+
+THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS
+OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
+DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
+GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
+WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
+NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+Julian Seward, jseward@bzip.org
+bzip2/libbzip2 version 1.0.6 of 6 September 2010
+
+--------------------------------------------------------------------------

meta/lib/oe/classextend.py

@@ -5,7 +5,7 @@ class ClassExtender(object):
         self.pkgs_mapping = []
 
     def extend_name(self, name):
-        if name.startswith("kernel-module"):
+        if name.startswith("kernel-") or name == "virtual/kernel":
             return name
         if name.startswith("rtld"):
             return name
@@ -33,6 +33,24 @@ class ClassExtender(object):
             self.d.setVar(varname, newdata)
         return newdata
 
+    def map_regexp_variable(self, varname, setvar = True):
+        var = self.d.getVar(varname, True)
+        if not var:
+            return ""
+        var = var.split()
+        newvar = []
+        for v in var:
+            if v.startswith("^" + self.extname):
+                newvar.append(v)
+            elif v.startswith("^"):
+                newvar.append("^" + self.extname + "-" + v[1:])
+            else:
+                newvar.append(self.extend_name(v))
+        newdata =  " ".join(newvar)
+        if setvar:
+            self.d.setVar(varname, newdata)
+        return newdata
+
     def map_depends(self, dep):
         if dep.endswith(("-native", "-native-runtime")):
             return dep
@@ -45,11 +63,12 @@ class ClassExtender(object):
         deps = self.d.getVar(varname, True)
         if not deps:
             return
-        deps = bb.utils.explode_deps(deps)
-        newdeps = []
+        deps = bb.utils.explode_dep_versions2(deps)
+        newdeps = {}
         for dep in deps:
-            newdeps.append(self.map_depends(dep))
-        self.d.setVar(varname, " ".join(newdeps))
+            newdeps[self.map_depends(dep)] = deps[dep]
+
+        self.d.setVar(varname, bb.utils.join_deps(newdeps, False))
 
     def map_packagevars(self):
         for pkg in (self.d.getVar("PACKAGES", True).split() + [""]):

meta/recipes-connectivity/bluez/bluez4.inc

@@ -7,7 +7,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=12f884d2ae1ff87c09e5b7ccc2c4ca7e \
                     file://COPYING.LIB;md5=fb504b67c50331fc78734fed90fb0e09 \
                     file://src/main.c;beginline=1;endline=24;md5=9bc54b93cd7e17bf03f52513f39f926e \
                     file://sbc/sbc.c;beginline=1;endline=25;md5=1a40781ed30d50d8639323a184aeb191"
-DEPENDS = "udev libusb dbus-glib glib-2.0 libcheck"
+DEPENDS = "udev libusb dbus-glib glib-2.0 libcheck readline"
 RDEPENDS_${PN}-dev = "bluez-hcidump"
 
 PACKAGECONFIG ??= "\

meta/recipes-connectivity/libnss-mdns/libnss-mdns_0.10.bb

@@ -7,7 +7,7 @@ LIC_FILES_CHKSUM = "file://LICENSE;md5=2d5025d4aa3495befef8f17206a5b0a1"
 
 DEPENDS = "avahi"
 RDEPENDS_${PN} = "avahi-daemon"
-PR = "r5"
+PR = "r6"
 
 SRC_URI = "http://0pointer.de/lennart/projects/nss-mdns/nss-mdns-${PV}.tar.gz"
 
@@ -24,13 +24,13 @@ DEBIANNAME_${PN} = "libnss-mdns"
 EXTRA_OECONF = "--libdir=${base_libdir} --disable-lynx --enable-avahi"
 
 pkg_postinst_${PN} () {
-if ! grep -q '^hosts:.*\<mdns4\>' $D/etc/nsswitch.conf; then
-	sed -e 's/^hosts:.*/& mdns4/' -i $D/etc/nsswitch.conf
-fi
+	sed -e '/^hosts:/s/\s*\<mdns4\>//' \
+		-e 's/\(^hosts:.*\)\(\<files\>\)\(.*\)\(\<dns\>\)\(.*\)/\1\2 mdns4_minimal [NOTFOUND=return]\3\4 mdns4\5/' \
+		-i $D/etc/nsswitch.conf
 }
 
 pkg_prerm_${PN} () {
-if grep -q '^hosts:.*\<mdns4\>' /etc/nsswitch.conf; then
-	sed -e '/^hosts:/s/\s\<mdns4\>//' -i /etc/nsswitch.conf
-fi
+	sed -e '/^hosts:/s/\s*\<mdns4\>//' \
+		-e '/^hosts:/s/\s*mdns4_minimal\s\+\[NOTFOUND=return\]//' \
+		-i /etc/nsswitch.conf
 }

meta/recipes-connectivity/openssh/openssh-6.0p1/cve-2010-5107.patch

@@ -0,0 +1,50 @@
+Fix CVE-2010-5107 by backporting the relevant changes from upstream CVS.
+
+http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/servconf.c?r1=1.234#rev1.234
+http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/sshd_config.5?r1=1.156#rev1.156
+http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/sshd_config?r1=1.89#rev1.89
+
+Upstream-Status: Backport
+Signed-off-by: Ross Burton <ross.burton@intel.com>
+
+--- a/src/usr.bin/ssh/sshd_config	2012/10/30 22:29:55	1.88
++++ b/src/usr.bin/ssh/sshd_config	2013/02/06 00:20:42	1.89
+@@ -96,7 +96,7 @@ UsePrivilegeSeparation sandbox		# Default for new inst
+ #ClientAliveCountMax 3
+ #UseDNS yes
+ #PidFile /var/run/sshd.pid
+-#MaxStartups 10
++#MaxStartups 10:30:100
+ #PermitTunnel no
+ #ChrootDirectory none
+ #VersionAddendum none
+
+--- a/src/usr.bin/ssh/sshd_config.5	2013/01/18 08:00:49	1.155
++++ b/src/usr.bin/ssh/sshd_config.5	2013/02/06 00:20:42	1.156
+@@ -821,7 +821,7 @@ SSH daemon.
+ Additional connections will be dropped until authentication succeeds or the
+ .Cm LoginGraceTime
+ expires for a connection.
+-The default is 10.
++The default is 10:30:100.
+ .Pp
+ Alternatively, random early drop can be enabled by specifying
+ the three colon separated values
+
+--- a/src/usr.bin/ssh/servconf.c	2012/12/02 20:46:11	1.233
++++ b/src/usr.bin/ssh/servconf.c	2013/02/06 00:20:42	1.234
+@@ -242,11 +242,11 @@ fill_default_server_options(ServerOptions *options)
+ 	if (options->gateway_ports == -1)
+ 		options->gateway_ports = 0;
+ 	if (options->max_startups == -1)
+-		options->max_startups = 10;
++		options->max_startups = 100;
+ 	if (options->max_startups_rate == -1)
+-		options->max_startups_rate = 100;		/* 100% */
++		options->max_startups_rate = 30;		/* 30% */
+ 	if (options->max_startups_begin == -1)
+-		options->max_startups_begin = options->max_startups;
++		options->max_startups_begin = 10;
+ 	if (options->max_authtries == -1)
+ 		options->max_authtries = DEFAULT_AUTH_FAIL_MAX;
+ 	if (options->max_sessions == -1)

meta/recipes-connectivity/openssh/openssh_6.0p1.bb

@@ -23,7 +23,8 @@ SRC_URI = "ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-${PV}.tar.
            file://sshd_config \
            file://ssh_config \
            file://init \
-           ${@base_contains('DISTRO_FEATURES', 'pam', '${PAM_SRC_URI}', '', d)}"
+           ${@base_contains('DISTRO_FEATURES', 'pam', '${PAM_SRC_URI}', '', d)} \
+           file://cve-2010-5107.patch;pnum=4"
 
 PAM_SRC_URI = "file://sshd"
 SRC_URI[md5sum] = "3c9347aa67862881c5da3f3b1c08da7b"

meta/recipes-core/base-files/base-files_3.0.14.bb

@@ -123,7 +123,7 @@ do_install_basefilesissue () {
 			printf "${DISTRO_VERSION} " >> ${D}${sysconfdir}/issue
 			printf "${DISTRO_VERSION} " >> ${D}${sysconfdir}/issue.net
 		fi
-		echo "\n \l" >> ${D}${sysconfdir}/issue
+		printf "\\\n \\\l\n" >> ${D}${sysconfdir}/issue
 		echo >> ${D}${sysconfdir}/issue
 		echo "%h"    >> ${D}${sysconfdir}/issue.net
 		echo >> ${D}${sysconfdir}/issue.net

meta/recipes-core/base-passwd/base-passwd_3.5.26.bb

@@ -1,7 +1,7 @@
 SUMMARY = "Base system master password/group files."
 DESCRIPTION = "The master copies of the user database files (/etc/passwd and /etc/group).  The update-passwd tool is also provided to keep the system databases synchronized with these master files."
 SECTION = "base"
-PR = "r0"
+PR = "r1"
 LICENSE = "GPLv2+"
 LIC_FILES_CHKSUM = "file://COPYING;md5=eb723b61539feef013de476e68b5c50a"
 
@@ -64,6 +64,7 @@ python populate_packages_prepend() {
     f.close()
 
     preinst = """#!/bin/sh
+mkdir -p $D${sysconfdir}
 if [ ! -e $D${sysconfdir}/passwd ]; then
 \tcat << EOF > $D${sysconfdir}/passwd
 """ + passwd + """EOF