beagleboard: update the dts location

Update the dts path for beagleboard

(From meta-yocto rev: e29387d71a4c532431669f317ea518f99b1dd786)

Signed-off-by: Maxin B. John <maxin.john@enea.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

README.hardware

@@ -59,7 +59,7 @@ Consumer Devices
 
 The following consumer devices are supported by the meta-yocto-bsp layer:
 
-  * Intel Atom based PCs and devices (atom-pc)
+  * Intel x86 based PCs and devices (genericx86)
 
 For more information see the device's section below. The appropriate MACHINE
 variable value corresponding to the device is given in brackets.
@@ -70,10 +70,10 @@ variable value corresponding to the device is given in brackets.
                       ===============================
 
 
-Intel Atom based PCs and devices (atom-pc)
+Intel x86 based PCs and devices (genericx86)
 ==========================================
 
-The atom-pc MACHINE is tested on the following platforms:
+The genericx86 MACHINE is tested on the following platforms:
 
   o Asus EeePC 901
   o Acer Aspire One
@@ -93,7 +93,7 @@ device as the following commands are run as root and are not reversable.
 USB Device:
   1. Build a live image. This image type consists of a simple filesystem
      without a partition table, which is suitable for USB keys, and with the
-     default setup for the atom-pc machine, this image type is built
+     default setup for the genericx86 machine, this image type is built
      automatically for any image you build. For example:
 
      $ bitbake core-image-minimal
@@ -101,7 +101,7 @@ USB Device:
   2. Use the "dd" utility to write the image to the raw block device. For
      example:
 
-     # dd if=core-image-minimal-atom-pc.hddimg of=/dev/sdb
+     # dd if=core-image-minimal-genericx86.hddimg of=/dev/sdb
 
   If the device fails to boot with "Boot error" displayed, or apparently
   stops just after the SYSLINUX version banner, it is likely the BIOS cannot
@@ -142,7 +142,7 @@ USB Device:
 
      # mkdir /tmp/image
      # mkdir /tmp/usbkey
-     # mount -o loop core-image-minimal-atom-pc.hddimg  /tmp/image
+     # mount -o loop core-image-minimal-genericx86.hddimg  /tmp/image
      # mount /dev/sdb4 /tmp/usbkey
      # cp -rf /tmp/image/* /tmp/usbkey
 

bitbake/bin/bitbake

@@ -41,7 +41,7 @@ from bb import ui
 from bb import server
 from bb import cookerdata
 
-__version__ = "1.19.0"
+__version__ = "1.19.1"
 logger = logging.getLogger("BitBake")
 
 # Python multiprocessing requires /dev/shm
@@ -197,14 +197,27 @@ class BitBakeConfigParameters(cookerdata.ConfigParameters):
         parser.add_option("", "--remote-server", help = "Connect to the specified server",
                    action = "store", dest = "remote_server", default = False)
 
+        parser.add_option("-m", "--kill-server", help = "Terminate the remote server",
+                    action = "store_true", dest = "kill_server", default = False)
+
+        parser.add_option("", "--observe-only", help = "Connect to a server as an observing-only client",
+                   action = "store_true", dest = "observe_only", default = False)
+
         options, targets = parser.parse_args(sys.argv)
+
+        # some environmental variables set also configuration options
+        if "BBSERVER" in os.environ:
+            options.servertype = "xmlrpc"
+            options.remote_server = os.environ["BBSERVER"]
+
         return options, targets[1:]
 
 
 def start_server(servermodule, configParams, configuration):
     server = servermodule.BitBakeServer()
     if configParams.bind:
-        server.initServer((configParams.bind, 0))
+        (host, port) = configParams.bind.split(':')
+        server.initServer((host, int(port)))
     else:
         server.initServer()
 
@@ -261,6 +274,9 @@ def main():
             sys.exit("FATAL: If '--server-only' is defined, we must set the servertype as 'xmlrpc'.\n")
         if not configParams.bind:
             sys.exit("FATAL: The '--server-only' option requires a name/address to bind to with the -B option.\n")
+        if configParams.remote_server:
+            sys.exit("FATAL: The '--server-only' option conflicts with the '--remote-server' option. %s\n" % 
+                ("Please check your BBSERVER environment" if "BBSERVER" in os.environ else "" ))
 
     if configParams.bind and configParams.servertype != "xmlrpc":
         sys.exit("FATAL: If '-B' or '--bind' is defined, we must set the servertype as 'xmlrpc'.\n")
@@ -268,6 +284,9 @@ def main():
     if configParams.remote_server and configParams.servertype != "xmlrpc":
         sys.exit("FATAL: If '--remote-server' is defined, we must set the servertype as 'xmlrpc'.\n")
 
+    if configParams.observe_only and (not configParams.remote_server or configParams.bind):
+        sys.exit("FATAL: '--observe-only' can only be used by UI clients connecting to a server.\n")
+
     if "BBDEBUG" in os.environ:
         level = int(os.environ["BBDEBUG"])
         if level > configuration.debug:
@@ -294,7 +313,7 @@ def main():
         server = start_server(servermodule, configParams, configuration)
     else:
         # we start a stub server that is actually a XMLRPClient to
-        server = servermodule.BitBakeXMLRPCClient()
+        server = servermodule.BitBakeXMLRPCClient(configParams.observe_only)
         server.saveConnectionDetails(configParams.remote_server)
 
     logger.removeHandler(handler)
@@ -313,7 +332,7 @@ def main():
             bb.event.ui_queue = []
             server_connection.terminate()
     else:
-        print("server address: %s, server port: %s" % (server.serverinfo.host, server.serverinfo.port))
+        print("server address: %s, server port: %s" % (server.serverImpl.host, server.serverImpl.port))
 
     return 1
 

bitbake/bin/bitbake-layers

@@ -226,7 +226,7 @@ Options:
 
     def list_recipes(self, title, pnspec, show_overlayed_only, show_same_ver_only, show_filenames, show_multi_provider_only):
         pkg_pn = self.bbhandler.cooker.recipecache.pkg_pn
-        (latest_versions, preferred_versions) = bb.providers.findProviders(self.bbhandler.cooker.configuration.data, self.bbhandler.cooker.recipecache, pkg_pn)
+        (latest_versions, preferred_versions) = bb.providers.findProviders(self.bbhandler.config_data, self.bbhandler.cooker.recipecache, pkg_pn)
         allproviders = bb.providers.allProviders(self.bbhandler.cooker.recipecache)
 
         # Ensure we list skipped recipes
@@ -515,7 +515,7 @@ Recipes are listed with the bbappends that apply to them as subitems.
         filenames = self.bbhandler.cooker_data.pkg_pn[pn]
 
         best = bb.providers.findBestProvider(pn,
-                                             self.bbhandler.cooker.configuration.data,
+                                             self.bbhandler.config_data,
                                              self.bbhandler.cooker_data,
                                              self.bbhandler.cooker_data.pkg_pn)
         best_filename = os.path.basename(best[3])
@@ -598,7 +598,7 @@ The .bbappend file can impact the dependency.
             for pn in deps:
                 if pn in self.bbhandler.cooker_data.pkg_pn:
                     best = bb.providers.findBestProvider(pn,
-                            self.bbhandler.cooker.configuration.data,
+                            self.bbhandler.config_data,
                             self.bbhandler.cooker_data,
                             self.bbhandler.cooker_data.pkg_pn)
                     self.check_cross_depends("DEPENDS", layername, f, best[3], show_filenames)
@@ -616,7 +616,7 @@ The .bbappend file can impact the dependency.
                 all_p = bb.providers.getRuntimeProviders(self.bbhandler.cooker_data, rdep)
                 if all_p:
                     best = bb.providers.filterProvidersRunTime(all_p, rdep,
-                                    self.bbhandler.cooker.configuration.data,
+                                    self.bbhandler.config_data,
                                     self.bbhandler.cooker_data)[0][0]
                     self.check_cross_depends("RDEPENDS", layername, f, best, show_filenames)
 

bitbake/bin/bitbake-worker

@@ -0,0 +1,363 @@
+#!/usr/bin/env python
+
+import os
+import sys
+import warnings
+sys.path.insert(0, os.path.join(os.path.dirname(os.path.dirname(sys.argv[0])), 'lib'))
+from bb import fetch2
+import logging
+import bb
+import select
+import errno
+import signal
+
+# Users shouldn't be running this code directly
+if len(sys.argv) != 2 or sys.argv[1] != "decafbad":
+    print("bitbake-worker is meant for internal execution by bitbake itself, please don't use it standalone.")
+    sys.exit(1)
+
+logger = logging.getLogger("BitBake")
+
+try:
+    import cPickle as pickle
+except ImportError:
+    import pickle
+    bb.msg.note(1, bb.msg.domain.Cache, "Importing cPickle failed. Falling back to a very slow implementation.")
+
+
+worker_pipe = sys.stdout.fileno()
+bb.utils.nonblockingfd(worker_pipe)
+
+handler = bb.event.LogHandler()
+logger.addHandler(handler)
+
+if 0:
+    # Code to write out a log file of all events passing through the worker
+    logfilename = "/tmp/workerlogfile"
+    format_str = "%(levelname)s: %(message)s"
+    conlogformat = bb.msg.BBLogFormatter(format_str)
+    consolelog = logging.FileHandler(logfilename)
+    bb.msg.addDefaultlogFilter(consolelog)
+    consolelog.setFormatter(conlogformat)
+    logger.addHandler(consolelog)
+
+worker_queue = ""
+
+def worker_fire(event, d):
+    data = "<event>" + pickle.dumps(event) + "</event>"
+    worker_fire_prepickled(data)
+
+def worker_fire_prepickled(event):
+    global worker_queue
+
+    worker_queue = worker_queue + event
+    worker_flush()
+
+def worker_flush():
+    global worker_queue, worker_pipe
+
+    if not worker_queue:
+        return
+
+    try:
+        written = os.write(worker_pipe, worker_queue)
+        worker_queue = worker_queue[written:]
+    except (IOError, OSError) as e:
+        if e.errno != errno.EAGAIN:
+            raise
+
+def worker_child_fire(event, d):
+    global worker_pipe
+
+    data = "<event>" + pickle.dumps(event) + "</event>"
+    worker_pipe.write(data)
+
+bb.event.worker_fire = worker_fire
+
+lf = None
+#lf = open("/tmp/workercommandlog", "w+")
+def workerlog_write(msg):
+    if lf:
+        lf.write(msg)
+        lf.flush()
+
+def fork_off_task(cfg, data, workerdata, fn, task, taskname, appends, quieterrors=False):
+    # We need to setup the environment BEFORE the fork, since
+    # a fork() or exec*() activates PSEUDO...
+
+    envbackup = {}
+    fakeenv = {}
+    umask = None
+
+    taskdep = workerdata["taskdeps"][fn]
+    if 'umask' in taskdep and taskname in taskdep['umask']:
+        # umask might come in as a number or text string..
+        try:
+             umask = int(taskdep['umask'][taskname],8)
+        except TypeError:
+             umask = taskdep['umask'][taskname]
+
+    if 'fakeroot' in taskdep and taskname in taskdep['fakeroot']:
+        envvars = (workerdata["fakerootenv"][fn] or "").split()
+        for key, value in (var.split('=') for var in envvars):
+            envbackup[key] = os.environ.get(key)
+            os.environ[key] = value
+            fakeenv[key] = value
+
+        fakedirs = (workerdata["fakerootdirs"][fn] or "").split()
+        for p in fakedirs:
+            bb.utils.mkdirhier(p)
+        logger.debug(2, 'Running %s:%s under fakeroot, fakedirs: %s' %
+                        (fn, taskname, ', '.join(fakedirs)))
+    else:
+        envvars = (workerdata["fakerootnoenv"][fn] or "").split()
+        for key, value in (var.split('=') for var in envvars):
+            envbackup[key] = os.environ.get(key)
+            os.environ[key] = value
+            fakeenv[key] = value
+
+    sys.stdout.flush()
+    sys.stderr.flush()
+
+    try:
+        pipein, pipeout = os.pipe()
+        pipein = os.fdopen(pipein, 'rb', 4096)
+        pipeout = os.fdopen(pipeout, 'wb', 0)
+        pid = os.fork()
+    except OSError as e:
+        bb.msg.fatal("RunQueue", "fork failed: %d (%s)" % (e.errno, e.strerror))
+
+    if pid == 0:
+            global worker_pipe
+            pipein.close()
+
+            # Save out the PID so that the event can include it the
+            # events
+            bb.event.worker_pid = os.getpid()
+            bb.event.worker_fire = worker_child_fire
+            worker_pipe = pipeout
+
+            # Make the child the process group leader
+            os.setpgid(0, 0)
+            # No stdin
+            newsi = os.open(os.devnull, os.O_RDWR)
+            os.dup2(newsi, sys.stdin.fileno())
+
+            if umask:
+                os.umask(umask)
+
+            data.setVar("BB_WORKERCONTEXT", "1")
+            data.setVar("BUILDNAME", workerdata["buildname"])
+            data.setVar("DATE", workerdata["date"])
+            data.setVar("TIME", workerdata["time"])
+            bb.parse.siggen.set_taskdata(workerdata["hashes"], workerdata["hash_deps"], workerdata["sigchecksums"])
+            ret = 0
+            try:
+                the_data = bb.cache.Cache.loadDataFull(fn, appends, data)
+                the_data.setVar('BB_TASKHASH', workerdata["runq_hash"][task])
+                for h in workerdata["hashes"]:
+                    the_data.setVar("BBHASH_%s" % h, workerdata["hashes"][h])
+                for h in workerdata["hash_deps"]:
+                    the_data.setVar("BBHASHDEPS_%s" % h, workerdata["hash_deps"][h])
+
+                # exported_vars() returns a generator which *cannot* be passed to os.environ.update() 
+                # successfully. We also need to unset anything from the environment which shouldn't be there 
+                exports = bb.data.exported_vars(the_data)
+                bb.utils.empty_environment()
+                for e, v in exports:
+                    os.environ[e] = v
+                for e in fakeenv:
+                    os.environ[e] = fakeenv[e]
+                    the_data.setVar(e, fakeenv[e])
+                    the_data.setVarFlag(e, 'export', "1")
+
+                if quieterrors:
+                    the_data.setVarFlag(taskname, "quieterrors", "1")
+
+            except Exception as exc:
+                if not quieterrors:
+                    logger.critical(str(exc))
+                os._exit(1)
+            try:
+                if not cfg.dry_run:
+                    ret = bb.build.exec_task(fn, taskname, the_data, cfg.profile)
+                os._exit(ret)
+            except:
+                os._exit(1)
+    else:
+        for key, value in envbackup.iteritems():
+            if value is None:
+                del os.environ[key]
+            else:
+                os.environ[key] = value
+
+    return pid, pipein, pipeout
+
+class runQueueWorkerPipe():
+    """
+    Abstraction for a pipe between a worker thread and the worker server
+    """
+    def __init__(self, pipein, pipeout):
+        self.input = pipein
+        if pipeout:
+            pipeout.close()
+        bb.utils.nonblockingfd(self.input)
+        self.queue = ""
+
+    def read(self):
+        start = len(self.queue)
+        try:
+            self.queue = self.queue + self.input.read(102400)
+        except (OSError, IOError) as e:
+            if e.errno != errno.EAGAIN:
+                raise
+
+        end = len(self.queue)
+        index = self.queue.find("</event>")
+        while index != -1:
+            worker_fire_prepickled(self.queue[:index+8])
+            self.queue = self.queue[index+8:]
+            index = self.queue.find("</event>")
+        return (end > start)
+
+    def close(self):
+        while self.read():
+            continue
+        if len(self.queue) > 0:
+            print("Warning, worker child left partial message: %s" % self.queue)
+        self.input.close()
+
+normalexit = False
+
+class BitbakeWorker(object):
+    def __init__(self, din):
+        self.input = din
+        bb.utils.nonblockingfd(self.input)
+        self.queue = ""
+        self.cookercfg = None
+        self.databuilder = None
+        self.data = None
+        self.build_pids = {}
+        self.build_pipes = {}
+    
+    def serve(self):        
+        while True:
+            (ready, _, _) = select.select([self.input] + [i.input for i in self.build_pipes.values()], [] , [], 1)
+            if self.input in ready or len(self.queue):
+                start = len(self.queue)
+                try:
+                    self.queue = self.queue + self.input.read()
+                except (OSError, IOError):
+                    pass
+                end = len(self.queue)
+                self.handle_item("cookerconfig", self.handle_cookercfg)
+                self.handle_item("workerdata", self.handle_workerdata)
+                self.handle_item("runtask", self.handle_runtask)
+                self.handle_item("finishnow", self.handle_finishnow)
+                self.handle_item("ping", self.handle_ping)
+                self.handle_item("quit", self.handle_quit)
+
+            for pipe in self.build_pipes:
+                self.build_pipes[pipe].read()
+            if len(self.build_pids):
+                self.process_waitpid()
+            worker_flush()
+
+
+    def handle_item(self, item, func):
+        if self.queue.startswith("<" + item + ">"):
+            index = self.queue.find("</" + item + ">")
+            while index != -1:
+                func(self.queue[(len(item) + 2):index])
+                self.queue = self.queue[(index + len(item) + 3):]
+                index = self.queue.find("</" + item + ">")
+
+    def handle_cookercfg(self, data):
+        self.cookercfg = pickle.loads(data)
+        self.databuilder = bb.cookerdata.CookerDataBuilder(self.cookercfg, worker=True)
+        self.databuilder.parseBaseConfiguration()
+        self.data = self.databuilder.data
+
+    def handle_workerdata(self, data):
+        self.workerdata = pickle.loads(data)
+        bb.msg.loggerDefaultDebugLevel = self.workerdata["logdefaultdebug"]
+        bb.msg.loggerDefaultVerbose = self.workerdata["logdefaultverbose"]
+        bb.msg.loggerVerboseLogs = self.workerdata["logdefaultverboselogs"]
+        bb.msg.loggerDefaultDomains = self.workerdata["logdefaultdomain"]
+        self.data.setVar("PRSERV_HOST", self.workerdata["prhost"])
+
+    def handle_ping(self, _):
+        workerlog_write("Handling ping\n")
+
+        logger.warn("Pong from bitbake-worker!")
+
+    def handle_quit(self, data):
+        workerlog_write("Handling quit\n")
+
+        global normalexit
+        normalexit = True
+        sys.exit(0)
+
+    def handle_runtask(self, data):
+        fn, task, taskname, quieterrors, appends = pickle.loads(data)
+        workerlog_write("Handling runtask %s %s %s\n" % (task, fn, taskname))
+
+        pid, pipein, pipeout = fork_off_task(self.cookercfg, self.data, self.workerdata, fn, task, taskname, appends, quieterrors)
+
+        self.build_pids[pid] = task
+        self.build_pipes[pid] = runQueueWorkerPipe(pipein, pipeout)
+
+    def process_waitpid(self):
+        """
+        Return none is there are no processes awaiting result collection, otherwise
+        collect the process exit codes and close the information pipe.
+        """
+        try:
+            pid, status = os.waitpid(-1, os.WNOHANG)
+            if pid == 0 or os.WIFSTOPPED(status):
+                return None
+        except OSError:
+            return None
+
+        workerlog_write("Exit code of %s for pid %s\n" % (status, pid))
+
+        if os.WIFEXITED(status):
+            status = os.WEXITSTATUS(status)
+        elif os.WIFSIGNALED(status):
+            # Per shell conventions for $?, when a process exits due to
+            # a signal, we return an exit code of 128 + SIGNUM
+            status = 128 + os.WTERMSIG(status)
+
+        task = self.build_pids[pid]
+        del self.build_pids[pid]
+
+        self.build_pipes[pid].close()
+        del self.build_pipes[pid]
+
+        worker_fire_prepickled("<exitcode>" + pickle.dumps((task, status)) + "</exitcode>")
+
+    def handle_finishnow(self, _):
+        if self.build_pids:
+            logger.info("Sending SIGTERM to remaining %s tasks", len(self.build_pids))
+            for k, v in self.build_pids.iteritems():
+                try:
+                    os.kill(-k, signal.SIGTERM)
+                    os.waitpid(-1, 0)
+                except:
+                    pass
+        for pipe in self.build_pipes:
+            self.build_pipes[pipe].read()
+
+try:
+    worker = BitbakeWorker(sys.stdin)
+    worker.serve()
+except BaseException as e:
+    if not normalexit:
+        import traceback
+        sys.stderr.write(traceback.format_exc())
+        sys.stderr.write(str(e))
+while len(worker_queue):
+    worker_flush()
+workerlog_write("exitting")
+sys.exit(0)
+

bitbake/contrib/vim/ftdetect/bitbake.vim

@@ -14,7 +14,7 @@ endif
 au BufNewFile,BufRead *.{bb,bbappend,bbclass}	set filetype=bitbake
 
 " .inc
-au BufNewFile,BufRead *.inc 		set filetype=bitbake
+au BufNewFile,BufRead *.inc		set filetype=bitbake
 
 " .conf
 au BufNewFile,BufRead *.conf

bitbake/contrib/vim/ftplugin/bitbake.vim

@@ -1 +1,2 @@
 set sts=4 sw=4 et
+set cms=#%s

bitbake/contrib/vim/plugin/newbb.vim

@@ -15,7 +15,7 @@ if &compatible || v:version < 600
 endif
 
 fun! <SID>GetUserName()
-    let l:user_name = system("git-config --get user.name")
+    let l:user_name = system("git config --get user.name")
     if v:shell_error
         return "Unknow User"
     else
@@ -23,7 +23,7 @@ fun! <SID>GetUserName()
 endfun
 
 fun! <SID>GetUserEmail()
-    let l:user_email = system("git-config --get user.email")
+    let l:user_email = system("git config --get user.email")
     if v:shell_error
         return "unknow@user.org"
     else

bitbake/contrib/vim/syntax/bitbake.vim

@@ -44,8 +44,8 @@ syn match bbArrayBrackets       "[\[\]]" contained
 
 " BitBake strings
 syn match bbContinue            "\\$"
-syn region bbString             matchgroup=bbQuote start=+"+ skip=+\\$+ excludenl end=+"+ contained keepend contains=bbTodo,bbContinue,bbVarDeref,bbVarPyValue,@Spell
-syn region bbString             matchgroup=bbQuote start=+'+ skip=+\\$+ excludenl end=+'+ contained keepend contains=bbTodo,bbContinue,bbVarDeref,bbVarPyValue,@Spell
+syn region bbString             matchgroup=bbQuote start=+"+ skip=+\\$+ end=+"+ contained contains=bbTodo,bbContinue,bbVarDeref,bbVarPyValue,@Spell
+syn region bbString             matchgroup=bbQuote start=+'+ skip=+\\$+ end=+'+ contained contains=bbTodo,bbContinue,bbVarDeref,bbVarPyValue,@Spell
 
 " Vars definition
 syn match bbExport            "^export" nextgroup=bbIdentifier skipwhite
@@ -55,11 +55,11 @@ syn match bbVarDeref            "${[a-zA-Z0-9\-_\.\/\+]\+}" contained
 syn match bbVarEq               "\(:=\|+=\|=+\|\.=\|=\.\|?=\|??=\|=\)" contained nextgroup=bbVarValue
 syn match bbVarDef              "^\(export\s*\)\?\([a-zA-Z0-9\-_\.\/\+]\+\(_[${}a-zA-Z0-9\-_\.\/\+]\+\)\?\)\s*\(:=\|+=\|=+\|\.=\|=\.\|?=\|??=\|=\)\@=" contains=bbExportFlag,bbIdentifier,bbVarDeref nextgroup=bbVarEq
 syn match bbVarValue            ".*$" contained contains=bbString,bbVarDeref,bbVarPyValue
-syn region bbVarPyValue         start=+${@+ skip=+\\$+ excludenl end=+}+ contained contains=@python
+syn region bbVarPyValue         start=+${@+ skip=+\\$+ end=+}+ contained contains=@python
 
 " Vars metadata flags
 syn match bbVarFlagDef          "^\([a-zA-Z0-9\-_\.]\+\)\(\[[a-zA-Z0-9\-_\.]\+\]\)\@=" contains=bbIdentifier nextgroup=bbVarFlagFlag
-syn region bbVarFlagFlag        matchgroup=bbArrayBrackets start="\[" end="\]\s*\(=\)\@=" keepend excludenl contained contains=bbIdentifier nextgroup=bbVarEq
+syn region bbVarFlagFlag        matchgroup=bbArrayBrackets start="\[" end="\]\s*\(=\|+=\|=+\|?=\)\@=" contained contains=bbIdentifier nextgroup=bbVarEq
 
 " Includes and requires
 syn keyword bbInclude           inherit include require contained 
@@ -83,13 +83,16 @@ if exists("b:current_syntax")
   unlet b:current_syntax
 endif
 syn keyword bbShFakeRootFlag    fakeroot contained
-syn match bbShFuncDef           "^\(fakeroot\s*\)\?\([0-9A-Za-z_-]\+\)\(python\)\@<!\(\s*()\s*\)\({\)\@=" contains=bbShFakeRootFlag,bbFunction,bbDelimiter nextgroup=bbShFuncRegion skipwhite
-syn region bbShFuncRegion       matchgroup=bbDelimiter start="{\s*$" end="^}\s*$" keepend contained contains=@shell
+syn match bbShFuncDef           "^\(fakeroot\s*\)\?\([0-9A-Za-z_${}-]\+\)\(python\)\@<!\(\s*()\s*\)\({\)\@=" contains=bbShFakeRootFlag,bbFunction,bbVarDeref,bbDelimiter nextgroup=bbShFuncRegion skipwhite
+syn region bbShFuncRegion       matchgroup=bbDelimiter start="{\s*$" end="^}\s*$" contained contains=@shell
+
+" Python value inside shell functions
+syn region shDeref         start=+${@+ skip=+\\$+ excludenl end=+}+ contained contains=@python
 
 " BitBake python metadata
 syn keyword bbPyFlag            python contained
-syn match bbPyFuncDef           "^\(python\s\+\)\([0-9A-Za-z_-]\+\)\?\(\s*()\s*\)\({\)\@=" contains=bbPyFlag,bbFunction,bbDelimiter nextgroup=bbPyFuncRegion skipwhite 
-syn region bbPyFuncRegion       matchgroup=bbDelimiter start="{\s*$" end="^}\s*$" keepend contained contains=@python
+syn match bbPyFuncDef           "^\(python\s\+\)\([0-9A-Za-z_${}-]\+\)\?\(\s*()\s*\)\({\)\@=" contains=bbPyFlag,bbFunction,bbVarDeref,bbDelimiter nextgroup=bbPyFuncRegion skipwhite
+syn region bbPyFuncRegion       matchgroup=bbDelimiter start="{\s*$" end="^}\s*$" contained contains=@python
 
 " BitBake 'def'd python functions
 syn keyword bbPyDef             def contained

bitbake/lib/bb/__init__.py

@@ -21,11 +21,11 @@
 # with this program; if not, write to the Free Software Foundation, Inc.,
 # 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
 
-__version__ = "1.19.0"
+__version__ = "1.19.1"
 
 import sys
-if sys.version_info < (2, 6, 0):
-    raise RuntimeError("Sorry, python 2.6.0 or later is required for this version of bitbake")
+if sys.version_info < (2, 7, 3):
+    raise RuntimeError("Sorry, python 2.7.3 or later is required for this version of bitbake")
 
 
 class BBHandledException(Exception):

bitbake/lib/bb/build.py

@@ -34,7 +34,7 @@ import bb
 import bb.msg
 import bb.process
 from contextlib import nested
-from bb import data, event, utils
+from bb import event, utils
 
 bblogger = logging.getLogger('BitBake')
 logger = logging.getLogger('BitBake.Build')
@@ -142,54 +142,68 @@ class LogTee(object):
 def exec_func(func, d, dirs = None):
     """Execute an BB 'function'"""
 
-    body = data.getVar(func, d)
+    body = d.getVar(func)
     if not body:
         if body is None:
             logger.warn("Function %s doesn't exist", func)
         return
 
-    flags = data.getVarFlags(func, d)
+    flags = d.getVarFlags(func)
     cleandirs = flags.get('cleandirs')
     if cleandirs:
-        for cdir in data.expand(cleandirs, d).split():
+        for cdir in d.expand(cleandirs).split():
             bb.utils.remove(cdir, True)
 
     if dirs is None:
         dirs = flags.get('dirs')
         if dirs:
-            dirs = data.expand(dirs, d).split()
+            dirs = d.expand(dirs).split()
 
     if dirs:
         for adir in dirs:
             bb.utils.mkdirhier(adir)
         adir = dirs[-1]
     else:
-        adir = data.getVar('B', d, 1)
+        adir = d.getVar('B', True)
         bb.utils.mkdirhier(adir)
 
     ispython = flags.get('python')
 
     lockflag = flags.get('lockfiles')
     if lockflag:
-        lockfiles = [data.expand(f, d) for f in lockflag.split()]
+        lockfiles = [d.expand(f) for f in lockflag.split()]
     else:
         lockfiles = None
 
-    tempdir = data.getVar('T', d, 1)
+    tempdir = d.getVar('T', True)
 
     # or func allows items to be executed outside of the normal
     # task set, such as buildhistory
-    task = data.getVar('BB_RUNTASK', d, 1) or func
+    task = d.getVar('BB_RUNTASK', True) or func
     if task == func:
         taskfunc = task
     else:
         taskfunc = "%s.%s" % (task, func)
 
-    runfmt = data.getVar('BB_RUNFMT', d, 1) or "run.{func}.{pid}"
+    runfmt = d.getVar('BB_RUNFMT', True) or "run.{func}.{pid}"
     runfn = runfmt.format(taskfunc=taskfunc, task=task, func=func, pid=os.getpid())
     runfile = os.path.join(tempdir, runfn)
     bb.utils.mkdirhier(os.path.dirname(runfile))
 
+    # Setup the courtesy link to the runfn, only for tasks
+    # we create the link 'just' before the run script is created
+    # if we create it after, and if the run script fails, then the
+    # link won't be created as an exception would be fired.
+    if task == func:
+        runlink = os.path.join(tempdir, 'run.{0}'.format(task))
+        if runlink:
+            bb.utils.remove(runlink)
+
+            try:
+                os.symlink(runfn, runlink)
+            except OSError:
+                pass
+
     with bb.utils.fileslocked(lockfiles):
         if ispython:
             exec_func_python(func, d, runfile, cwd=adir)
@@ -250,14 +264,37 @@ def exec_func_shell(func, d, runfile, cwd=None):
     d.delVarFlag('PWD', 'export')
 
     with open(runfile, 'w') as script:
-        script.write('#!/bin/sh -e\n')
-        data.emit_func(func, script, d)
+        script.write('''#!/bin/sh\n
+# Emit a useful diagnostic if something fails:
+bb_exit_handler() {
+    ret=$?
+    case $ret in
+    0)  ;;
+    *)  case $BASH_VERSION in
+        "")   echo "WARNING: exit code $ret from a shell command.";;
+        *)    echo "WARNING: ${BASH_SOURCE[0]}:${BASH_LINENO[0]} exit $ret from
+  \"$BASH_COMMAND\"";;
+        esac
+        exit $ret
+    esac
+}
+trap 'bb_exit_handler' 0
+set -e
+''')
+
+        bb.data.emit_func(func, script, d)
 
         if bb.msg.loggerVerboseLogs:
             script.write("set -x\n")
         if cwd:
             script.write("cd %s\n" % cwd)
         script.write("%s\n" % func)
+        script.write('''
+# cleanup
+ret=$?
+trap '' 0
+exit $?
+''')
 
     os.chmod(runfile, 0775)
 
@@ -284,13 +321,13 @@ def exec_func_shell(func, d, runfile, cwd=None):
     bb.debug(2, "Shell function %s finished" % func)
 
 def _task_data(fn, task, d):
-    localdata = data.createCopy(d)
+    localdata = bb.data.createCopy(d)
     localdata.setVar('BB_FILENAME', fn)
     localdata.setVar('BB_CURRENTTASK', task[3:])
     localdata.setVar('OVERRIDES', 'task-%s:%s' %
                      (task[3:], d.getVar('OVERRIDES', False)))
     localdata.finalize()
-    data.expandKeys(localdata)
+    bb.data.expandKeys(localdata)
     return localdata
 
 def _exec_task(fn, task, d, quieterr):
@@ -299,7 +336,7 @@ def _exec_task(fn, task, d, quieterr):
     Execution of a task involves a bit more setup than executing a function,
     running it with its own local metadata, and with some useful variables set.
     """
-    if not data.getVarFlag(task, 'task', d):
+    if not d.getVarFlag(task, 'task'):
         event.fire(TaskInvalid(task, d), d)
         logger.error("No such task: %s" % task)
         return 1
@@ -430,7 +467,7 @@ def exec_task(fn, task, d, profile = False):
             quieterr = True
 
         if profile: 
-            profname = "profile-%s.log" % (os.path.basename(fn) + "-" + task)
+            profname = "profile-%s.log" % (d.getVar("PN", True) + "-" + task)
             try:
                 import cProfile as profile
             except:
@@ -575,7 +612,7 @@ def stampfile(taskname, d, file_name = None):
     return stamp_internal(taskname, d, file_name)
 
 def add_tasks(tasklist, d):
-    task_deps = data.getVar('_task_deps', d)
+    task_deps = d.getVar('_task_deps')
     if not task_deps:
         task_deps = {}
     if not 'tasks' in task_deps:
@@ -584,24 +621,25 @@ def add_tasks(tasklist, d):
         task_deps['parents'] = {}
 
     for task in tasklist:
-        task = data.expand(task, d)
-        data.setVarFlag(task, 'task', 1, d)
+        task = d.expand(task)
+        d.setVarFlag(task, 'task', 1)
 
         if not task in task_deps['tasks']:
             task_deps['tasks'].append(task)
 
-        flags = data.getVarFlags(task, d)
+        flags = d.getVarFlags(task)
         def getTask(name):
             if not name in task_deps:
                 task_deps[name] = {}
             if name in flags:
-                deptask = data.expand(flags[name], d)
+                deptask = d.expand(flags[name])
                 task_deps[name][task] = deptask
         getTask('depends')
         getTask('rdepends')
         getTask('deptask')
         getTask('rdeptask')
         getTask('recrdeptask')
+        getTask('recideptask')
         getTask('nostamp')
         getTask('fakeroot')
         getTask('noexec')
@@ -609,15 +647,15 @@ def add_tasks(tasklist, d):
         task_deps['parents'][task] = []
         if 'deps' in flags:
             for dep in flags['deps']:
-                dep = data.expand(dep, d)
+                dep = d.expand(dep)
                 task_deps['parents'][task].append(dep)
 
     # don't assume holding a reference
-    data.setVar('_task_deps', task_deps, d)
+    d.setVar('_task_deps', task_deps)
 
 def remove_task(task, kill, d):
     """Remove an BB 'task'.
 
        If kill is 1, also remove tasks that depend on this task."""
 
-    data.delVarFlag(task, 'task', d)
+    d.delVarFlag(task, 'task')

bitbake/lib/bb/cache.py

@@ -43,7 +43,7 @@ except ImportError:
     logger.info("Importing cPickle failed. "
                 "Falling back to a very slow implementation.")
 
-__cache_version__ = "145"
+__cache_version__ = "146"
 
 def getCacheFile(path, filename, data_hash):
     return os.path.join(path, filename + "." + data_hash)
@@ -524,6 +524,15 @@ class Cache(object):
                     self.remove(fn)
                     return False
 
+        if hasattr(info_array[0], 'file_checksums'):
+            for _, fl in info_array[0].file_checksums.items():
+                for f in fl.split():
+                    if not os.path.exists(f):
+                        logger.debug(2, "Cache: %s's file checksum list file %s was removed",
+                                        fn, f)
+                        self.remove(fn)
+                        return False
+
         if appends != info_array[0].appends:
             logger.debug(2, "Cache: appends for %s changed", fn)
             logger.debug(2, "%s to %s" % (str(appends), str(info_array[0].appends)))
@@ -715,7 +724,6 @@ class CacheData(object):
         for info in info_array:
             info.add_cacheData(self, fn)
 
-
 class MultiProcessCache(object):
     """
     BitBake multi-process cache implementation
@@ -737,13 +745,18 @@ class MultiProcessCache(object):
         self.cachefile = os.path.join(cachedir, self.__class__.cache_file_name)
         logger.debug(1, "Using cache in '%s'", self.cachefile)
 
+        glf = bb.utils.lockfile(self.cachefile + ".lock")
+
         try:
             with open(self.cachefile, "rb") as f:
                 p = pickle.Unpickler(f)
                 data, version = p.load()
         except:
+            bb.utils.unlockfile(glf)
             return
 
+        bb.utils.unlockfile(glf)
+
         if version != self.__class__.CACHE_VERSION:
             return
 

bitbake/lib/bb/command.py

@@ -59,11 +59,14 @@ class Command:
         # FIXME Add lock for this
         self.currentAsyncCommand = None
 
-    def runCommand(self, commandline):
+    def runCommand(self, commandline, ro_only = False):
         command = commandline.pop(0)
         if hasattr(CommandsSync, command):
             # Can run synchronous commands straight away
             command_method = getattr(self.cmds_sync, command)
+            if ro_only:
+                if not hasattr(command_method, 'readonly') or False == getattr(command_method, 'readonly'):
+                    return None, "Not able to execute not readonly commands in readonly mode"
             try:
                 result = command_method(self, commandline)
             except CommandError as exc:
@@ -87,8 +90,7 @@ class Command:
                 (command, options) = self.currentAsyncCommand
                 commandmethod = getattr(CommandsAsync, command)
                 needcache = getattr( commandmethod, "needcache" )
-                if (needcache and self.cooker.state in
-                    (bb.cooker.state.initial, bb.cooker.state.parsing)):
+                if needcache and self.cooker.state != bb.cooker.state.running:
                     self.cooker.updateCache()
                     return True
                 else:
@@ -116,11 +118,11 @@ class Command:
 
     def finishAsyncCommand(self, msg=None, code=None):
         if msg:
-            bb.event.fire(CommandFailed(msg), self.cooker.configuration.event_data)
+            bb.event.fire(CommandFailed(msg), self.cooker.event_data)
         elif code:
-            bb.event.fire(CommandExit(code), self.cooker.configuration.event_data)
+            bb.event.fire(CommandExit(code), self.cooker.event_data)
         else:
-            bb.event.fire(CommandCompleted(), self.cooker.configuration.event_data)
+            bb.event.fire(CommandCompleted(), self.cooker.event_data)
         self.currentAsyncCommand = None
 
 
@@ -145,22 +147,23 @@ class CommandsSync:
 
     def getVariable(self, command, params):
         """
-        Read the value of a variable from configuration.data
+        Read the value of a variable from data
         """
         varname = params[0]
         expand = True
         if len(params) > 1:
-            expand = params[1]
+            expand = (params[1] == "True")
 
-        return command.cooker.configuration.data.getVar(varname, expand)
+        return command.cooker.data.getVar(varname, expand)
+    getVariable.readonly = True
 
     def setVariable(self, command, params):
         """
-        Set the value of variable in configuration.data
+        Set the value of variable in data
         """
         varname = params[0]
         value = str(params[1])
-        command.cooker.configuration.data.setVar(varname, value)
+        command.cooker.data.setVar(varname, value)
 
     def setConfig(self, command, params):
         """
@@ -200,6 +203,7 @@ class CommandsSync:
         Get the CPU count on the bitbake server
         """
         return bb.utils.cpu_count()
+    getCpuCount.readonly = True
 
     def matchFile(self, command, params):
         fMatch = params[0]
@@ -209,13 +213,38 @@ class CommandsSync:
         image = params[0]
         base_image = params[1]
         package_queue = params[2]
-        return command.cooker.generateNewImage(image, base_image, package_queue)
+        timestamp = params[3]
+        description = params[4]
+        return command.cooker.generateNewImage(image, base_image,
+                        package_queue, timestamp, description)
+
+    def ensureDir(self, command, params):
+        directory = params[0]
+        bb.utils.mkdirhier(directory)
 
     def setVarFile(self, command, params):
+        """
+        Save a variable in a file; used for saving in a configuration file
+        """
         var = params[0]
         val = params[1]
         default_file = params[2]
-        command.cooker.saveConfigurationVar(var, val, default_file)
+        op = params[3]
+        command.cooker.modifyConfigurationVar(var, val, default_file, op)
+
+    def createConfigFile(self, command, params):
+        """
+        Create an extra configuration file
+        """
+        name = params[0]
+        command.cooker.createConfigFile(name)
+
+    def setEventMask(self, command, params):
+        handlerNum = params[0]
+        llevel = params[1]
+        debug_domains = params[2]
+        mask = params[3]
+        return bb.event.set_UIHmask(handlerNum, llevel, debug_domains, mask)
 
 class CommandsAsync:
     """
@@ -363,19 +392,11 @@ class CommandsAsync:
         command.finishAsyncCommand()
     parseFiles.needcache = True
 
-    def reparseFiles(self, command, params):
-        """
-        Reparse .bb files
-        """
-        command.cooker.reparseFiles()
-        command.finishAsyncCommand()
-    reparseFiles.needcache = True
-
     def compareRevisions(self, command, params):
         """
         Parse the .bb files
         """
-        if bb.fetch.fetcher_compare_revisions(command.cooker.configuration.data):
+        if bb.fetch.fetcher_compare_revisions(command.cooker.data):
             command.finishAsyncCommand(code=1)
         else:
             command.finishAsyncCommand()
@@ -385,8 +406,8 @@ class CommandsAsync:
         """
         Parse the configuration files
         """
-        prefiles = params[0]
-        postfiles = params[1]
+        prefiles = params[0].split()
+        postfiles = params[1].split()
         command.cooker.configuration.prefile = prefiles
         command.cooker.configuration.postfile = postfiles
         command.cooker.loadConfigurationData()
@@ -398,7 +419,7 @@ class CommandsAsync:
         Trigger a certain event
         """
         event = params[0]
-        bb.event.fire(eval(event), command.cooker.configuration.data)
+        bb.event.fire(eval(event), command.cooker.data)
         command.currentAsyncCommand = None
     triggerEvent.needcache = False
 

bitbake/lib/bb/compat.py

@@ -1,928 +1,6 @@
 """Code pulled from future python versions, here for compatibility"""
 
-from collections import MutableMapping, KeysView, ValuesView, ItemsView
-try:
-    from thread import get_ident as _get_ident
-except ImportError:
-    from dummy_thread import get_ident as _get_ident
-
-def total_ordering(cls):
-    """Class decorator that fills in missing ordering methods"""
-    convert = {
-        '__lt__': [('__gt__', lambda self, other: other < self),
-                   ('__le__', lambda self, other: not other < self),
-                   ('__ge__', lambda self, other: not self < other)],
-        '__le__': [('__ge__', lambda self, other: other <= self),
-                   ('__lt__', lambda self, other: not other <= self),
-                   ('__gt__', lambda self, other: not self <= other)],
-        '__gt__': [('__lt__', lambda self, other: other > self),
-                   ('__ge__', lambda self, other: not other > self),
-                   ('__le__', lambda self, other: not self > other)],
-        '__ge__': [('__le__', lambda self, other: other >= self),
-                   ('__gt__', lambda self, other: not other >= self),
-                   ('__lt__', lambda self, other: not self >= other)]
-    }
-    roots = set(dir(cls)) & set(convert)
-    if not roots:
-        raise ValueError('must define at least one ordering operation: < > <= >=')
-    root = max(roots)       # prefer __lt__ to __le__ to __gt__ to __ge__
-    for opname, opfunc in convert[root]:
-        if opname not in roots:
-            opfunc.__name__ = opname
-            opfunc.__doc__ = getattr(int, opname).__doc__
-            setattr(cls, opname, opfunc)
-    return cls
-
-class OrderedDict(dict):
-    'Dictionary that remembers insertion order'
-    # An inherited dict maps keys to values.
-    # The inherited dict provides __getitem__, __len__, __contains__, and get.
-    # The remaining methods are order-aware.
-    # Big-O running times for all methods are the same as regular dictionaries.
-
-    # The internal self.__map dict maps keys to links in a doubly linked list.
-    # The circular doubly linked list starts and ends with a sentinel element.
-    # The sentinel element never gets deleted (this simplifies the algorithm).
-    # Each link is stored as a list of length three:  [PREV, NEXT, KEY].
-
-    def __init__(self, *args, **kwds):
-        '''Initialize an ordered dictionary.  The signature is the same as
-        regular dictionaries, but keyword arguments are not recommended because
-        their insertion order is arbitrary.
-
-        '''
-        if len(args) > 1:
-            raise TypeError('expected at most 1 arguments, got %d' % len(args))
-        try:
-            self.__root
-        except AttributeError:
-            self.__root = root = []                     # sentinel node
-            root[:] = [root, root, None]
-            self.__map = {}
-        self.__update(*args, **kwds)
-
-    def __setitem__(self, key, value, PREV=0, NEXT=1, dict_setitem=dict.__setitem__):
-        'od.__setitem__(i, y) <==> od[i]=y'
-        # Setting a new item creates a new link at the end of the linked list,
-        # and the inherited dictionary is updated with the new key/value pair.
-        if key not in self:
-            root = self.__root
-            last = root[PREV]
-            last[NEXT] = root[PREV] = self.__map[key] = [last, root, key]
-        dict_setitem(self, key, value)
-
-    def __delitem__(self, key, PREV=0, NEXT=1, dict_delitem=dict.__delitem__):
-        'od.__delitem__(y) <==> del od[y]'
-        # Deleting an existing item uses self.__map to find the link which gets
-        # removed by updating the links in the predecessor and successor nodes.
-        dict_delitem(self, key)
-        link_prev, link_next, key = self.__map.pop(key)
-        link_prev[NEXT] = link_next
-        link_next[PREV] = link_prev
-
-    def __iter__(self):
-        'od.__iter__() <==> iter(od)'
-        # Traverse the linked list in order.
-        NEXT, KEY = 1, 2
-        root = self.__root
-        curr = root[NEXT]
-        while curr is not root:
-            yield curr[KEY]
-            curr = curr[NEXT]
-
-    def __reversed__(self):
-        'od.__reversed__() <==> reversed(od)'
-        # Traverse the linked list in reverse order.
-        PREV, KEY = 0, 2
-        root = self.__root
-        curr = root[PREV]
-        while curr is not root:
-            yield curr[KEY]
-            curr = curr[PREV]
-
-    def clear(self):
-        'od.clear() -> None.  Remove all items from od.'
-        for node in self.__map.itervalues():
-            del node[:]
-        root = self.__root
-        root[:] = [root, root, None]
-        self.__map.clear()
-        dict.clear(self)
-
-    # -- the following methods do not depend on the internal structure --
-
-    def keys(self):
-        'od.keys() -> list of keys in od'
-        return list(self)
-
-    def values(self):
-        'od.values() -> list of values in od'
-        return [self[key] for key in self]
-
-    def items(self):
-        'od.items() -> list of (key, value) pairs in od'
-        return [(key, self[key]) for key in self]
-
-    def iterkeys(self):
-        'od.iterkeys() -> an iterator over the keys in od'
-        return iter(self)
-
-    def itervalues(self):
-        'od.itervalues -> an iterator over the values in od'
-        for k in self:
-            yield self[k]
-
-    def iteritems(self):
-        'od.iteritems -> an iterator over the (key, value) pairs in od'
-        for k in self:
-            yield (k, self[k])
-
-    update = MutableMapping.update
-
-    __update = update # let subclasses override update without breaking __init__
-
-    __marker = object()
-
-    def pop(self, key, default=__marker):
-        '''od.pop(k[,d]) -> v, remove specified key and return the corresponding
-        value.  If key is not found, d is returned if given, otherwise KeyError
-        is raised.
-
-        '''
-        if key in self:
-            result = self[key]
-            del self[key]
-            return result
-        if default is self.__marker:
-            raise KeyError(key)
-        return default
-
-    def setdefault(self, key, default=None):
-        'od.setdefault(k[,d]) -> od.get(k,d), also set od[k]=d if k not in od'
-        if key in self:
-            return self[key]
-        self[key] = default
-        return default
-
-    def popitem(self, last=True):
-        '''od.popitem() -> (k, v), return and remove a (key, value) pair.
-        Pairs are returned in LIFO order if last is true or FIFO order if false.
-
-        '''
-        if not self:
-            raise KeyError('dictionary is empty')
-        key = next(reversed(self) if last else iter(self))
-        value = self.pop(key)
-        return key, value
-
-    def __repr__(self, _repr_running={}):
-        'od.__repr__() <==> repr(od)'
-        call_key = id(self), _get_ident()
-        if call_key in _repr_running:
-            return '...'
-        _repr_running[call_key] = 1
-        try:
-            if not self:
-                return '%s()' % (self.__class__.__name__,)
-            return '%s(%r)' % (self.__class__.__name__, self.items())
-        finally:
-            del _repr_running[call_key]
-
-    def __reduce__(self):
-        'Return state information for pickling'
-        items = [[k, self[k]] for k in self]
-        inst_dict = vars(self).copy()
-        for k in vars(OrderedDict()):
-            inst_dict.pop(k, None)
-        if inst_dict:
-            return (self.__class__, (items,), inst_dict)
-        return self.__class__, (items,)
-
-    def copy(self):
-        'od.copy() -> a shallow copy of od'
-        return self.__class__(self)
-
-    @classmethod
-    def fromkeys(cls, iterable, value=None):
-        '''OD.fromkeys(S[, v]) -> New ordered dictionary with keys from S.
-        If not specified, the value defaults to None.
-
-        '''
-        self = cls()
-        for key in iterable:
-            self[key] = value
-        return self
-
-    def __eq__(self, other):
-        '''od.__eq__(y) <==> od==y.  Comparison to another OD is order-sensitive
-        while comparison to a regular mapping is order-insensitive.
-
-        '''
-        if isinstance(other, OrderedDict):
-            return len(self)==len(other) and self.items() == other.items()
-        return dict.__eq__(self, other)
-
-    def __ne__(self, other):
-        'od.__ne__(y) <==> od!=y'
-        return not self == other
-
-    # -- the following methods support python 3.x style dictionary views --
-
-    def viewkeys(self):
-        "od.viewkeys() -> a set-like object providing a view on od's keys"
-        return KeysView(self)
-
-    def viewvalues(self):
-        "od.viewvalues() -> an object providing a view on od's values"
-        return ValuesView(self)
-
-    def viewitems(self):
-        "od.viewitems() -> a set-like object providing a view on od's items"
-        return ItemsView(self)
-
-# Multiprocessing pool code imported from python 2.7.3. Previous versions of 
-# python have issues in this code which hang pool usage
-
-#
-# Module providing the `Pool` class for managing a process pool
-#
-# multiprocessing/pool.py
-#
-# Copyright (c) 2006-2008, R Oudkerk
-# 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. Redistributions in binary form must reproduce the above copyright
-#    notice, this list of conditions and the following disclaimer in the
-#    documentation and/or other materials provided with the distribution.
-# 3. Neither the name of author nor the names of any contributors may be
-#    used to endorse or promote products derived from this software
-#    without specific prior written permission.
-#
-# THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS "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 OR CONTRIBUTORS 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.
-#
-import threading
-import Queue
-import itertools
-import collections
-import time
-
-import multiprocessing
-from multiprocessing import Process, cpu_count, TimeoutError, pool
-from multiprocessing.util import Finalize, debug
-
-#
-# Constants representing the state of a pool
-#
-
-RUN = 0
-CLOSE = 1
-TERMINATE = 2
-
-#
-# Miscellaneous
-#
-
-def mapstar(args):
-    return map(*args)
-
-class MaybeEncodingError(Exception):
-    """Wraps possible unpickleable errors, so they can be
-    safely sent through the socket."""
-
-    def __init__(self, exc, value):
-        self.exc = repr(exc)
-        self.value = repr(value)
-        super(MaybeEncodingError, self).__init__(self.exc, self.value)
-
-    def __str__(self):
-        return "Error sending result: '%s'. Reason: '%s'" % (self.value,
-                                                             self.exc)
-
-    def __repr__(self):
-        return "<MaybeEncodingError: %s>" % str(self)
-
-def worker(inqueue, outqueue, initializer=None, initargs=(), maxtasks=None):
-    assert maxtasks is None or (type(maxtasks) == int and maxtasks > 0)
-    put = outqueue.put
-    get = inqueue.get
-    if hasattr(inqueue, '_writer'):
-        inqueue._writer.close()
-        outqueue._reader.close()
-
-    if initializer is not None:
-        initializer(*initargs)
-
-    completed = 0
-    while maxtasks is None or (maxtasks and completed < maxtasks):
-        try:
-            task = get()
-        except (EOFError, IOError):
-            debug('worker got EOFError or IOError -- exiting')
-            break
-
-        if task is None:
-            debug('worker got sentinel -- exiting')
-            break
-
-        job, i, func, args, kwds = task
-        try:
-            result = (True, func(*args, **kwds))
-        except Exception as e:
-            result = (False, e)
-        try:
-            put((job, i, result))
-        except Exception as e:
-            wrapped = MaybeEncodingError(e, result[1])
-            debug("Possible encoding error while sending result: %s" % (
-                wrapped))
-            put((job, i, (False, wrapped)))
-        completed += 1
-    debug('worker exiting after %d tasks' % completed)
-
-
-class Pool(object):
-    '''
-    Class which supports an async version of the `apply()` builtin
-    '''
-    Process = Process
-
-    def __init__(self, processes=None, initializer=None, initargs=(),
-                 maxtasksperchild=None):
-        self._setup_queues()
-        self._taskqueue = Queue.Queue()
-        self._cache = {}
-        self._state = RUN
-        self._maxtasksperchild = maxtasksperchild
-        self._initializer = initializer
-        self._initargs = initargs
-
-        if processes is None:
-            try:
-                processes = cpu_count()
-            except NotImplementedError:
-                processes = 1
-        if processes < 1:
-            raise ValueError("Number of processes must be at least 1")
-
-        if initializer is not None and not hasattr(initializer, '__call__'):
-            raise TypeError('initializer must be a callable')
-
-        self._processes = processes
-        self._pool = []
-        self._repopulate_pool()
-
-        self._worker_handler = threading.Thread(
-            target=Pool._handle_workers,
-            args=(self, )
-            )
-        self._worker_handler.daemon = True
-        self._worker_handler._state = RUN
-        self._worker_handler.start()
-
-
-        self._task_handler = threading.Thread(
-            target=Pool._handle_tasks,
-            args=(self._taskqueue, self._quick_put, self._outqueue, self._pool)
-            )
-        self._task_handler.daemon = True
-        self._task_handler._state = RUN
-        self._task_handler.start()
-
-        self._result_handler = threading.Thread(
-            target=Pool._handle_results,
-            args=(self._outqueue, self._quick_get, self._cache)
-            )
-        self._result_handler.daemon = True
-        self._result_handler._state = RUN
-        self._result_handler.start()
-
-        self._terminate = Finalize(
-            self, self._terminate_pool,
-            args=(self._taskqueue, self._inqueue, self._outqueue, self._pool,
-                  self._worker_handler, self._task_handler,
-                  self._result_handler, self._cache),
-            exitpriority=15
-            )
-
-    def _join_exited_workers(self):
-        """Cleanup after any worker processes which have exited due to reaching
-        their specified lifetime.  Returns True if any workers were cleaned up.
-        """
-        cleaned = False
-        for i in reversed(range(len(self._pool))):
-            worker = self._pool[i]
-            if worker.exitcode is not None:
-                # worker exited
-                debug('cleaning up worker %d' % i)
-                worker.join()
-                cleaned = True
-                del self._pool[i]
-        return cleaned
-
-    def _repopulate_pool(self):
-        """Bring the number of pool processes up to the specified number,
-        for use after reaping workers which have exited.
-        """
-        for i in range(self._processes - len(self._pool)):
-            w = self.Process(target=worker,
-                             args=(self._inqueue, self._outqueue,
-                                   self._initializer,
-                                   self._initargs, self._maxtasksperchild)
-                            )
-            self._pool.append(w)
-            w.name = w.name.replace('Process', 'PoolWorker')
-            w.daemon = True
-            w.start()
-            debug('added worker')
-
-    def _maintain_pool(self):
-        """Clean up any exited workers and start replacements for them.
-        """
-        if self._join_exited_workers():
-            self._repopulate_pool()
-
-    def _setup_queues(self):
-        from multiprocessing.queues import SimpleQueue
-        self._inqueue = SimpleQueue()
-        self._outqueue = SimpleQueue()
-        self._quick_put = self._inqueue._writer.send
-        self._quick_get = self._outqueue._reader.recv
-
-    def apply(self, func, args=(), kwds={}):
-        '''
-        Equivalent of `apply()` builtin
-        '''
-        assert self._state == RUN
-        return self.apply_async(func, args, kwds).get()
-
-    def map(self, func, iterable, chunksize=None):
-        '''
-        Equivalent of `map()` builtin
-        '''
-        assert self._state == RUN
-        return self.map_async(func, iterable, chunksize).get()
-
-    def imap(self, func, iterable, chunksize=1):
-        '''
-        Equivalent of `itertools.imap()` -- can be MUCH slower than `Pool.map()`
-        '''
-        assert self._state == RUN
-        if chunksize == 1:
-            result = IMapIterator(self._cache)
-            self._taskqueue.put((((result._job, i, func, (x,), {})
-                         for i, x in enumerate(iterable)), result._set_length))
-            return result
-        else:
-            assert chunksize > 1
-            task_batches = Pool._get_tasks(func, iterable, chunksize)
-            result = IMapIterator(self._cache)
-            self._taskqueue.put((((result._job, i, mapstar, (x,), {})
-                     for i, x in enumerate(task_batches)), result._set_length))
-            return (item for chunk in result for item in chunk)
-
-    def imap_unordered(self, func, iterable, chunksize=1):
-        '''
-        Like `imap()` method but ordering of results is arbitrary
-        '''
-        assert self._state == RUN
-        if chunksize == 1:
-            result = IMapUnorderedIterator(self._cache)
-            self._taskqueue.put((((result._job, i, func, (x,), {})
-                         for i, x in enumerate(iterable)), result._set_length))
-            return result
-        else:
-            assert chunksize > 1
-            task_batches = Pool._get_tasks(func, iterable, chunksize)
-            result = IMapUnorderedIterator(self._cache)
-            self._taskqueue.put((((result._job, i, mapstar, (x,), {})
-                     for i, x in enumerate(task_batches)), result._set_length))
-            return (item for chunk in result for item in chunk)
-
-    def apply_async(self, func, args=(), kwds={}, callback=None):
-        '''
-        Asynchronous equivalent of `apply()` builtin
-        '''
-        assert self._state == RUN
-        result = ApplyResult(self._cache, callback)
-        self._taskqueue.put(([(result._job, None, func, args, kwds)], None))
-        return result
-
-    def map_async(self, func, iterable, chunksize=None, callback=None):
-        '''
-        Asynchronous equivalent of `map()` builtin
-        '''
-        assert self._state == RUN
-        if not hasattr(iterable, '__len__'):
-            iterable = list(iterable)
-
-        if chunksize is None:
-            chunksize, extra = divmod(len(iterable), len(self._pool) * 4)
-            if extra:
-                chunksize += 1
-        if len(iterable) == 0:
-            chunksize = 0
-
-        task_batches = Pool._get_tasks(func, iterable, chunksize)
-        result = MapResult(self._cache, chunksize, len(iterable), callback)
-        self._taskqueue.put((((result._job, i, mapstar, (x,), {})
-                              for i, x in enumerate(task_batches)), None))
-        return result
-
-    @staticmethod
-    def _handle_workers(pool):
-        thread = threading.current_thread()
-
-        # Keep maintaining workers until the cache gets drained, unless the pool
-        # is terminated.
-        while thread._state == RUN or (pool._cache and thread._state != TERMINATE):
-            pool._maintain_pool()
-            time.sleep(0.1)
-        # send sentinel to stop workers
-        pool._taskqueue.put(None)
-        debug('worker handler exiting')
-
-    @staticmethod
-    def _handle_tasks(taskqueue, put, outqueue, pool):
-        thread = threading.current_thread()
-
-        for taskseq, set_length in iter(taskqueue.get, None):
-            i = -1
-            for i, task in enumerate(taskseq):
-                if thread._state:
-                    debug('task handler found thread._state != RUN')
-                    break
-                try:
-                    put(task)
-                except IOError:
-                    debug('could not put task on queue')
-                    break
-            else:
-                if set_length:
-                    debug('doing set_length()')
-                    set_length(i+1)
-                continue
-            break
-        else:
-            debug('task handler got sentinel')
-
-
-        try:
-            # tell result handler to finish when cache is empty
-            debug('task handler sending sentinel to result handler')
-            outqueue.put(None)
-
-            # tell workers there is no more work
-            debug('task handler sending sentinel to workers')
-            for p in pool:
-                put(None)
-        except IOError:
-            debug('task handler got IOError when sending sentinels')
-
-        debug('task handler exiting')
-
-    @staticmethod
-    def _handle_results(outqueue, get, cache):
-        thread = threading.current_thread()
-
-        while 1:
-            try:
-                task = get()
-            except (IOError, EOFError):
-                debug('result handler got EOFError/IOError -- exiting')
-                return
-
-            if thread._state:
-                assert thread._state == TERMINATE
-                debug('result handler found thread._state=TERMINATE')
-                break
-
-            if task is None:
-                debug('result handler got sentinel')
-                break
-
-            job, i, obj = task
-            try:
-                cache[job]._set(i, obj)
-            except KeyError:
-                pass
-
-        while cache and thread._state != TERMINATE:
-            try:
-                task = get()
-            except (IOError, EOFError):
-                debug('result handler got EOFError/IOError -- exiting')
-                return
-
-            if task is None:
-                debug('result handler ignoring extra sentinel')
-                continue
-            job, i, obj = task
-            try:
-                cache[job]._set(i, obj)
-            except KeyError:
-                pass
-
-        if hasattr(outqueue, '_reader'):
-            debug('ensuring that outqueue is not full')
-            # If we don't make room available in outqueue then
-            # attempts to add the sentinel (None) to outqueue may
-            # block.  There is guaranteed to be no more than 2 sentinels.
-            try:
-                for i in range(10):
-                    if not outqueue._reader.poll():
-                        break
-                    get()
-            except (IOError, EOFError):
-                pass
-
-        debug('result handler exiting: len(cache)=%s, thread._state=%s',
-              len(cache), thread._state)
-
-    @staticmethod
-    def _get_tasks(func, it, size):
-        it = iter(it)
-        while 1:
-            x = tuple(itertools.islice(it, size))
-            if not x:
-                return
-            yield (func, x)
-
-    def __reduce__(self):
-        raise NotImplementedError(
-              'pool objects cannot be passed between processes or pickled'
-              )
-
-    def close(self):
-        debug('closing pool')
-        if self._state == RUN:
-            self._state = CLOSE
-            self._worker_handler._state = CLOSE
-
-    def terminate(self):
-        debug('terminating pool')
-        self._state = TERMINATE
-        self._worker_handler._state = TERMINATE
-        self._terminate()
-
-    def join(self):
-        debug('joining pool')
-        assert self._state in (CLOSE, TERMINATE)
-        self._worker_handler.join()
-        self._task_handler.join()
-        self._result_handler.join()
-        for p in self._pool:
-            p.join()
-
-    @staticmethod
-    def _help_stuff_finish(inqueue, task_handler, size):
-        # task_handler may be blocked trying to put items on inqueue
-        debug('removing tasks from inqueue until task handler finished')
-        inqueue._rlock.acquire()
-        while task_handler.is_alive() and inqueue._reader.poll():
-            inqueue._reader.recv()
-            time.sleep(0)
-
-    @classmethod
-    def _terminate_pool(cls, taskqueue, inqueue, outqueue, pool,
-                        worker_handler, task_handler, result_handler, cache):
-        # this is guaranteed to only be called once
-        debug('finalizing pool')
-
-        worker_handler._state = TERMINATE
-        task_handler._state = TERMINATE
-
-        debug('helping task handler/workers to finish')
-        cls._help_stuff_finish(inqueue, task_handler, len(pool))
-
-        assert result_handler.is_alive() or len(cache) == 0
-
-        result_handler._state = TERMINATE
-        outqueue.put(None)                  # sentinel
-
-        # We must wait for the worker handler to exit before terminating
-        # workers because we don't want workers to be restarted behind our back.
-        debug('joining worker handler')
-        if threading.current_thread() is not worker_handler:
-            worker_handler.join(1e100)
-
-        # Terminate workers which haven't already finished.
-        if pool and hasattr(pool[0], 'terminate'):
-            debug('terminating workers')
-            for p in pool:
-                if p.exitcode is None:
-                    p.terminate()
-
-        debug('joining task handler')
-        if threading.current_thread() is not task_handler:
-            task_handler.join(1e100)
-
-        debug('joining result handler')
-        if threading.current_thread() is not result_handler:
-            result_handler.join(1e100)
-
-        if pool and hasattr(pool[0], 'terminate'):
-            debug('joining pool workers')
-            for p in pool:
-                if p.is_alive():
-                    # worker has not yet exited
-                    debug('cleaning up worker %d' % p.pid)
-                    p.join()
-
-class ApplyResult(object):
-
-    def __init__(self, cache, callback):
-        self._cond = threading.Condition(threading.Lock())
-        self._job = multiprocessing.pool.job_counter.next()
-        self._cache = cache
-        self._ready = False
-        self._callback = callback
-        cache[self._job] = self
-
-    def ready(self):
-        return self._ready
-
-    def successful(self):
-        assert self._ready
-        return self._success
-
-    def wait(self, timeout=None):
-        self._cond.acquire()
-        try:
-            if not self._ready:
-                self._cond.wait(timeout)
-        finally:
-            self._cond.release()
-
-    def get(self, timeout=None):
-        self.wait(timeout)
-        if not self._ready:
-            raise TimeoutError
-        if self._success:
-            return self._value
-        else:
-            raise self._value
-
-    def _set(self, i, obj):
-        self._success, self._value = obj
-        if self._callback and self._success:
-            self._callback(self._value)
-        self._cond.acquire()
-        try:
-            self._ready = True
-            self._cond.notify()
-        finally:
-            self._cond.release()
-        del self._cache[self._job]
-
-#
-# Class whose instances are returned by `Pool.map_async()`
-#
-
-class MapResult(ApplyResult):
-
-    def __init__(self, cache, chunksize, length, callback):
-        ApplyResult.__init__(self, cache, callback)
-        self._success = True
-        self._value = [None] * length
-        self._chunksize = chunksize
-        if chunksize <= 0:
-            self._number_left = 0
-            self._ready = True
-            del cache[self._job]
-        else:
-            self._number_left = length//chunksize + bool(length % chunksize)
-
-    def _set(self, i, success_result):
-        success, result = success_result
-        if success:
-            self._value[i*self._chunksize:(i+1)*self._chunksize] = result
-            self._number_left -= 1
-            if self._number_left == 0:
-                if self._callback:
-                    self._callback(self._value)
-                del self._cache[self._job]
-                self._cond.acquire()
-                try:
-                    self._ready = True
-                    self._cond.notify()
-                finally:
-                    self._cond.release()
-
-        else:
-            self._success = False
-            self._value = result
-            del self._cache[self._job]
-            self._cond.acquire()
-            try:
-                self._ready = True
-                self._cond.notify()
-            finally:
-                self._cond.release()
-
-#
-# Class whose instances are returned by `Pool.imap()`
-#
-
-class IMapIterator(object):
-
-    def __init__(self, cache):
-        self._cond = threading.Condition(threading.Lock())
-        self._job = multiprocessing.pool.job_counter.next()
-        self._cache = cache
-        self._items = collections.deque()
-        self._index = 0
-        self._length = None
-        self._unsorted = {}
-        cache[self._job] = self
-
-    def __iter__(self):
-        return self
-
-    def next(self, timeout=None):
-        self._cond.acquire()
-        try:
-            try:
-                item = self._items.popleft()
-            except IndexError:
-                if self._index == self._length:
-                    raise StopIteration
-                self._cond.wait(timeout)
-                try:
-                    item = self._items.popleft()
-                except IndexError:
-                    if self._index == self._length:
-                        raise StopIteration
-                    raise TimeoutError
-        finally:
-            self._cond.release()
-
-        success, value = item
-        if success:
-            return value
-        raise value
-
-    __next__ = next                    # XXX
-
-    def _set(self, i, obj):
-        self._cond.acquire()
-        try:
-            if self._index == i:
-                self._items.append(obj)
-                self._index += 1
-                while self._index in self._unsorted:
-                    obj = self._unsorted.pop(self._index)
-                    self._items.append(obj)
-                    self._index += 1
-                self._cond.notify()
-            else:
-                self._unsorted[i] = obj
-
-            if self._index == self._length:
-                del self._cache[self._job]
-        finally:
-            self._cond.release()
-
-    def _set_length(self, length):
-        self._cond.acquire()
-        try:
-            self._length = length
-            if self._index == self._length:
-                self._cond.notify()
-                del self._cache[self._job]
-        finally:
-            self._cond.release()
-
-#
-# Class whose instances are returned by `Pool.imap_unordered()`
-#
-
-class IMapUnorderedIterator(IMapIterator):
-
-    def _set(self, i, obj):
-        self._cond.acquire()
-        try:
-            self._items.append(obj)
-            self._index += 1
-            self._cond.notify()
-            if self._index == self._length:
-                del self._cache[self._job]
-        finally:
-            self._cond.release()
+from collections import MutableMapping, KeysView, ValuesView, ItemsView, OrderedDict
+from functools import total_ordering
 
 

bitbake/lib/bb/cooker.py

@@ -108,13 +108,12 @@ class BBCooker:
                 logger.critical("Unable to import extra RecipeInfo '%s' from '%s': %s" % (cache_name, module_name, exc))
                 sys.exit("FATAL: Failed to import extra cache class '%s'." % cache_name)
 
-        self.configuration.data = None
-        self.initConfigurationData()
+        self.data = None
         self.loadConfigurationData()
 
         # Take a lock so only one copy of bitbake can run against a given build
         # directory at a time
-        lockfile = self.configuration.data.expand("${TOPDIR}/bitbake.lock")
+        lockfile = self.data.expand("${TOPDIR}/bitbake.lock")
         self.lock = bb.utils.lockfile(lockfile, False, False)
         if not self.lock:
             bb.fatal("Only one copy of bitbake should be run against a build directory")
@@ -122,9 +121,9 @@ class BBCooker:
         #
         # Special updated configuration we use for firing events
         #
-        self.configuration.event_data = bb.data.createCopy(self.configuration.data)
-        bb.data.update_data(self.configuration.event_data)
-        bb.parse.init_parser(self.configuration.event_data)
+        self.event_data = bb.data.createCopy(self.data)
+        bb.data.update_data(self.event_data)
+        bb.parse.init_parser(self.event_data)
 
         # TOSTOP must not be set or our children will hang when they output
         fd = sys.stdout.fileno()
@@ -147,27 +146,59 @@ class BBCooker:
             worker = True
 
         self.databuilder = bb.cookerdata.CookerDataBuilder(self.configuration, worker)
-        self.configuration.data = self.databuilder.data
+        self.data = self.databuilder.data
 
     def enableDataTracking(self):
-        self.configuration.data.enableTracking()
+        self.configuration.tracking = True
+        self.data.enableTracking()
 
     def disableDataTracking(self):
-        self.configuration.data.disableTracking()
+        self.configuration.tracking = False
+        self.data.disableTracking()
 
     def loadConfigurationData(self):
+        self.initConfigurationData()
         self.databuilder.parseBaseConfiguration()
-        self.configuration.data = self.databuilder.data
-        self.configuration.data_hash = self.databuilder.data_hash
+        self.data = self.databuilder.data
+        self.data_hash = self.databuilder.data_hash
+
+    def modifyConfigurationVar(self, var, val, default_file, op):
+        if op == "append":
+            self.appendConfigurationVar(var, val, default_file)
+        elif op == "set":
+            self.saveConfigurationVar(var, val, default_file)
+
+    def appendConfigurationVar(self, var, val, default_file):
+        #add append var operation to the end of default_file
+        default_file = bb.cookerdata.findConfigFile(default_file, self.data)
+
+        with open(default_file, 'r') as f:
+            contents = f.readlines()
+        f.close()
+
+        total = ""
+        for c in contents:
+            total += c
+
+        total += "#added by bitbake"
+        total += "\n%s += \"%s\"\n" % (var, val)
+
+        with open(default_file, 'w') as f:
+            f.write(total)
+        f.close()
+
+        #add to history
+        loginfo = {"op":append, "file":default_file, "line":total.count("\n")}
+        self.data.appendVar(var, val, **loginfo)
 
     def saveConfigurationVar(self, var, val, default_file):
 
         replaced = False
         #do not save if nothing changed
-        if str(val) == self.configuration.data.getVar(var):
+        if str(val) == self.data.getVar(var):
             return
 
-        conf_files = self.configuration.data.varhistory.get_variable_files(var)
+        conf_files = self.data.varhistory.get_variable_files(var)
 
         #format the value when it is a list
         if isinstance(val, list):
@@ -176,7 +207,7 @@ class BBCooker:
                 listval += "%s   " % value
             val = listval
 
-        topdir = self.configuration.data.getVar("TOPDIR")
+        topdir = self.data.getVar("TOPDIR")
 
         #comment or replace operations made on var
         for conf_file in conf_files:
@@ -185,7 +216,7 @@ class BBCooker:
                     contents = f.readlines()
                 f.close()
 
-                lines = self.configuration.data.varhistory.get_variable_lines(var, conf_file)
+                lines = self.data.varhistory.get_variable_lines(var, conf_file)
                 for line in lines:
                     total = ""
                     i = 0
@@ -218,10 +249,10 @@ class BBCooker:
 
         if replaced == False:
             #remove var from history
-            self.configuration.data.varhistory.del_var_history(var)
+            self.data.varhistory.del_var_history(var)
 
             #add var to the end of default_file
-            default_file = bb.cookerdata.findConfigFile(default_file)
+            default_file = bb.cookerdata.findConfigFile(default_file, self.data)
 
             with open(default_file, 'r') as f:
                 contents = f.readlines()
@@ -232,7 +263,7 @@ class BBCooker:
                 total += c
 
             #add the variable on a single line, to be easy to replace the second time
-            total += "#added by bitbake"
+            total += "\n#added by bitbake"
             total += "\n%s = \"%s\"\n" % (var, val)
 
             with open(default_file, 'w') as f:
@@ -241,17 +272,22 @@ class BBCooker:
 
             #add to history
             loginfo = {"op":set, "file":default_file, "line":total.count("\n")}
-            self.configuration.data.setVar(var, val, **loginfo)
+            self.data.setVar(var, val, **loginfo)
+
+    def createConfigFile(self, name):
+        path = os.getcwd()
+        confpath = os.path.join(path, "conf", name)
+        open(confpath, 'w').close()
 
     def parseConfiguration(self):
 
         # Set log file verbosity
-        verboselogs = bb.utils.to_boolean(self.configuration.data.getVar("BB_VERBOSE_LOGS", "0"))
+        verboselogs = bb.utils.to_boolean(self.data.getVar("BB_VERBOSE_LOGS", "0"))
         if verboselogs:
             bb.msg.loggerVerboseLogs = True
 
         # Change nice level if we're asked to
-        nice = self.configuration.data.getVar("BB_NICE_LEVEL", True)
+        nice = self.data.getVar("BB_NICE_LEVEL", True)
         if nice:
             curnice = os.nice(0)
             nice = int(nice) - curnice
@@ -261,7 +297,7 @@ class BBCooker:
             del self.recipecache
         self.recipecache = bb.cache.CacheData(self.caches_array)
 
-        self.handleCollections( self.configuration.data.getVar("BBFILE_COLLECTIONS", True) )
+        self.handleCollections( self.data.getVar("BBFILE_COLLECTIONS", True) )
 
     def runCommands(self, server, data, abort):
         """
@@ -275,7 +311,7 @@ class BBCooker:
     def showVersions(self):
 
         pkg_pn = self.recipecache.pkg_pn
-        (latest_versions, preferred_versions) = bb.providers.findProviders(self.configuration.data, self.recipecache, pkg_pn)
+        (latest_versions, preferred_versions) = bb.providers.findProviders(self.data, self.recipecache, pkg_pn)
 
         logger.plain("%-35s %25s %25s", "Recipe Name", "Latest Version", "Preferred Version")
         logger.plain("%-35s %25s %25s\n", "===========", "==============", "=================")
@@ -308,11 +344,11 @@ class BBCooker:
             fn = self.matchFile(fn)
             fn = bb.cache.Cache.realfn2virtual(fn, cls)
         elif len(pkgs_to_build) == 1:
-            ignore = self.configuration.data.getVar("ASSUME_PROVIDED", True) or ""
+            ignore = self.data.getVar("ASSUME_PROVIDED", True) or ""
             if pkgs_to_build[0] in set(ignore.split()):
                 bb.fatal("%s is in ASSUME_PROVIDED" % pkgs_to_build[0])
 
-            localdata = data.createCopy(self.configuration.data)
+            localdata = data.createCopy(self.data)
             bb.data.update_data(localdata)
             bb.data.expandKeys(localdata)
 
@@ -324,18 +360,18 @@ class BBCooker:
             fnid = taskdata.build_targets[targetid][0]
             fn = taskdata.fn_index[fnid]
         else:
-            envdata = self.configuration.data
+            envdata = self.data
 
         if fn:
             try:
-                envdata = bb.cache.Cache.loadDataFull(fn, self.collection.get_file_appends(fn), self.configuration.data)
+                envdata = bb.cache.Cache.loadDataFull(fn, self.collection.get_file_appends(fn), self.data)
             except Exception as e:
                 parselog.exception("Unable to read %s", fn)
                 raise
 
         # Display history
         with closing(StringIO()) as env:
-            self.configuration.data.inchistory.emit(env)
+            self.data.inchistory.emit(env)
             logger.plain(env.getvalue())
 
         # emit variables and shell functions
@@ -354,7 +390,7 @@ class BBCooker:
         """
         Prepare a runqueue and taskdata object for iteration over pkgs_to_build
         """
-        bb.event.fire(bb.event.TreeDataPreparationStarted(), self.configuration.data)
+        bb.event.fire(bb.event.TreeDataPreparationStarted(), self.data)
 
         # If we are told to do the None task then query the default task
         if (task == None):
@@ -362,7 +398,7 @@ class BBCooker:
 
         pkgs_to_build = self.checkPackages(pkgs_to_build)
 
-        localdata = data.createCopy(self.configuration.data)
+        localdata = data.createCopy(self.data)
         bb.data.update_data(localdata)
         bb.data.expandKeys(localdata)
         # We set abort to False here to prevent unbuildable targets raising
@@ -375,9 +411,9 @@ class BBCooker:
             taskdata.add_provider(localdata, self.recipecache, k)
             runlist.append([k, "do_%s" % task])
             current += 1
-            bb.event.fire(bb.event.TreeDataPreparationProgress(current, len(pkgs_to_build)), self.configuration.data)
+            bb.event.fire(bb.event.TreeDataPreparationProgress(current, len(pkgs_to_build)), self.data)
         taskdata.add_unresolved(localdata, self.recipecache)
-        bb.event.fire(bb.event.TreeDataPreparationCompleted(len(pkgs_to_build)), self.configuration.data)
+        bb.event.fire(bb.event.TreeDataPreparationCompleted(len(pkgs_to_build)), self.data)
         return runlist, taskdata
     
     ######## WARNING : this function requires cache_extra to be enabled ########
@@ -388,7 +424,7 @@ class BBCooker:
         information.
         """
         runlist, taskdata = self.prepareTreeData(pkgs_to_build, task)
-        rq = bb.runqueue.RunQueue(self, self.configuration.data, self.recipecache, taskdata, runlist)
+        rq = bb.runqueue.RunQueue(self, self.data, self.recipecache, taskdata, runlist)
         rq.rqdata.prepare()
 
         seen_fnids = []
@@ -543,7 +579,7 @@ class BBCooker:
         Generate an event with the result
         """
         depgraph = self.generateTaskDepTreeData(pkgs_to_build, task)
-        bb.event.fire(bb.event.DepTreeGenerated(depgraph), self.configuration.data)
+        bb.event.fire(bb.event.DepTreeGenerated(depgraph), self.data)
 
     def generateDotGraphFiles(self, pkgs_to_build, task):
         """
@@ -621,7 +657,7 @@ class BBCooker:
                            for append in appends)
             msg = 'No recipes available for:\n%s' % '\n'.join(appendlines)
             warn_only = data.getVar("BB_DANGLINGAPPENDS_WARNONLY", \
-                 self.configuration.data, False) or "no"
+                 self.data, False) or "no"
             if warn_only.lower() in ("1", "yes", "true"):
                 bb.warn(msg)
             else:
@@ -629,7 +665,7 @@ class BBCooker:
 
     def handlePrefProviders(self):
 
-        localdata = data.createCopy(self.configuration.data)
+        localdata = data.createCopy(self.data)
         bb.data.update_data(localdata)
         bb.data.expandKeys(localdata)
 
@@ -645,7 +681,7 @@ class BBCooker:
             self.recipecache.preferred[providee] = provider
 
     def findCoreBaseFiles(self, subdir, configfile):
-        corebase = self.configuration.data.getVar('COREBASE', True) or ""
+        corebase = self.data.getVar('COREBASE', True) or ""
         paths = []
         for root, dirs, files in os.walk(corebase + '/' + subdir):
             for d in dirs:
@@ -654,22 +690,22 @@ class BBCooker:
                     paths.append(os.path.join(root, d))
 
         if paths:
-            bb.event.fire(bb.event.CoreBaseFilesFound(paths), self.configuration.data)
+            bb.event.fire(bb.event.CoreBaseFilesFound(paths), self.data)
 
     def findConfigFilePath(self, configfile):
         """
         Find the location on disk of configfile and if it exists and was parsed by BitBake
         emit the ConfigFilePathFound event with the path to the file.
         """
-        path = bb.cookerdata.findConfigFile(configfile)
+        path = bb.cookerdata.findConfigFile(configfile, self.data)
         if not path:
             return
 
         # Generate a list of parsed configuration files by searching the files
         # listed in the __depends and __base_depends variables with a .conf suffix.
         conffiles = []
-        dep_files = self.configuration.data.getVar('__base_depends') or []
-        dep_files = dep_files + (self.configuration.data.getVar('__depends') or [])
+        dep_files = self.data.getVar('__base_depends') or []
+        dep_files = dep_files + (self.data.getVar('__depends') or [])
 
         for f in dep_files:
             if f[0].endswith(".conf"):
@@ -682,7 +718,7 @@ class BBCooker:
         for cfg in conffiles:
             if cfg.endswith(match):
                 bb.event.fire(bb.event.ConfigFilePathFound(path),
-                              self.configuration.data)
+                              self.data)
                 break
 
     def findFilesMatchingInDir(self, filepattern, directory):
@@ -697,7 +733,7 @@ class BBCooker:
 
         matches = []
         p = re.compile(re.escape(filepattern))
-        bbpaths = self.configuration.data.getVar('BBPATH', True).split(':')
+        bbpaths = self.data.getVar('BBPATH', True).split(':')
         for path in bbpaths:
             dirpath = os.path.join(path, directory)
             if os.path.exists(dirpath):
@@ -707,7 +743,7 @@ class BBCooker:
                             matches.append(f)
 
         if matches:
-            bb.event.fire(bb.event.FilesMatchingFound(filepattern, matches), self.configuration.data)
+            bb.event.fire(bb.event.FilesMatchingFound(filepattern, matches), self.data)
 
     def findConfigFiles(self, varname):
         """
@@ -717,7 +753,7 @@ class BBCooker:
         possible = []
         var = varname.lower()
 
-        data = self.configuration.data
+        data = self.data
         # iterate configs
         bbpaths = data.getVar('BBPATH', True).split(':')
         for path in bbpaths:
@@ -731,7 +767,7 @@ class BBCooker:
                             possible.append(val)
 
         if possible:
-            bb.event.fire(bb.event.ConfigFilesFound(var, possible), self.configuration.data)
+            bb.event.fire(bb.event.ConfigFilesFound(var, possible), self.data)
 
     def findInheritsClass(self, klass):
         """
@@ -762,7 +798,7 @@ class BBCooker:
 
         # generate a dependency tree for all our packages
         tree = self.generatePkgDepTreeData(pkgs, 'build')
-        bb.event.fire(bb.event.TargetsTreeGenerated(tree), self.configuration.data)
+        bb.event.fire(bb.event.TargetsTreeGenerated(tree), self.data)
 
     def buildWorldTargetList(self):
         """
@@ -808,7 +844,7 @@ class BBCooker:
             min_prio = 0
             for c in collection_list:
                 # Get collection priority if defined explicitly
-                priority = self.configuration.data.getVar("BBFILE_PRIORITY_%s" % c, True)
+                priority = self.data.getVar("BBFILE_PRIORITY_%s" % c, True)
                 if priority:
                     try:
                         prio = int(priority)
@@ -822,7 +858,7 @@ class BBCooker:
                     collection_priorities[c] = None
 
                 # Check dependencies and store information for priority calculation
-                deps = self.configuration.data.getVar("LAYERDEPENDS_%s" % c, True)
+                deps = self.data.getVar("LAYERDEPENDS_%s" % c, True)
                 if deps:
                     depnamelist = []
                     deplist = deps.split()
@@ -842,7 +878,7 @@ class BBCooker:
 
                         if dep in collection_list:
                             if depver:
-                                layerver = self.configuration.data.getVar("LAYERVERSION_%s" % dep, True)
+                                layerver = self.data.getVar("LAYERVERSION_%s" % dep, True)
                                 if layerver:
                                     try:
                                         lver = int(layerver)
@@ -879,7 +915,7 @@ class BBCooker:
             # Calculate all layer priorities using calc_layer_priority and store in bbfile_config_priorities
             for c in collection_list:
                 calc_layer_priority(c)
-                regex = self.configuration.data.getVar("BBFILE_PATTERN_%s" % c, True)
+                regex = self.data.getVar("BBFILE_PATTERN_%s" % c, True)
                 if regex == None:
                     parselog.error("BBFILE_PATTERN_%s not defined" % c)
                     errors = True
@@ -899,9 +935,9 @@ class BBCooker:
         """
         Setup any variables needed before starting a build
         """
-        if not self.configuration.data.getVar("BUILDNAME"):
-            self.configuration.data.setVar("BUILDNAME", time.strftime('%Y%m%d%H%M'))
-        self.configuration.data.setVar("BUILDSTART", time.strftime('%m/%d/%Y %H:%M:%S', time.gmtime()))
+        if not self.data.getVar("BUILDNAME"):
+            self.data.setVar("BUILDNAME", time.strftime('%Y%m%d%H%M'))
+        self.data.setVar("BUILDSTART", time.strftime('%m/%d/%Y %H:%M:%S', time.gmtime()))
 
     def matchFiles(self, bf):
         """
@@ -911,7 +947,7 @@ class BBCooker:
             bf = os.path.abspath(bf)
 
         self.collection = CookerCollectFiles(self.recipecache.bbfile_config_priorities)
-        filelist, masked = self.collection.collect_bbfiles(self.configuration.data, self.configuration.event_data)
+        filelist, masked = self.collection.collect_bbfiles(self.data, self.event_data)
         try:
             os.stat(bf)
             bf = os.path.abspath(bf)
@@ -966,7 +1002,7 @@ class BBCooker:
 
         self.recipecache = bb.cache.CacheData(self.caches_array)
         infos = bb.cache.Cache.parse(fn, self.collection.get_file_appends(fn), \
-                                     self.configuration.data,
+                                     self.data,
                                      self.caches_array)
         infos = dict(infos)
 
@@ -999,15 +1035,15 @@ class BBCooker:
 
         # Setup taskdata structure
         taskdata = bb.taskdata.TaskData(self.configuration.abort)
-        taskdata.add_provider(self.configuration.data, self.recipecache, item)
+        taskdata.add_provider(self.data, self.recipecache, item)
 
-        buildname = self.configuration.data.getVar("BUILDNAME")
-        bb.event.fire(bb.event.BuildStarted(buildname, [item]), self.configuration.event_data)
+        buildname = self.data.getVar("BUILDNAME")
+        bb.event.fire(bb.event.BuildStarted(buildname, [item]), self.event_data)
 
         # Execute the runqueue
         runlist = [[item, "do_%s" % task]]
 
-        rq = bb.runqueue.RunQueue(self, self.configuration.data, self.recipecache, taskdata, runlist)
+        rq = bb.runqueue.RunQueue(self, self.data, self.recipecache, taskdata, runlist)
 
         def buildFileIdle(server, rq, abort):
 
@@ -1026,7 +1062,7 @@ class BBCooker:
                 return False
 
             if not retval:
-                bb.event.fire(bb.event.BuildCompleted(len(rq.rqdata.runq_fnid), buildname, item, failures), self.configuration.event_data)
+                bb.event.fire(bb.event.BuildCompleted(len(rq.rqdata.runq_fnid), buildname, item, failures), self.event_data)
                 self.command.finishAsyncCommand()
                 return False
             if retval is True:
@@ -1063,7 +1099,7 @@ class BBCooker:
                 return False
 
             if not retval:
-                bb.event.fire(bb.event.BuildCompleted(len(rq.rqdata.runq_fnid), buildname, targets, failures), self.configuration.data)
+                bb.event.fire(bb.event.BuildCompleted(len(rq.rqdata.runq_fnid), buildname, targets, failures), self.data)
                 self.command.finishAsyncCommand()
                 return False
             if retval is True:
@@ -1072,10 +1108,10 @@ class BBCooker:
 
         self.buildSetVars()
 
-        buildname = self.configuration.data.getVar("BUILDNAME")
-        bb.event.fire(bb.event.BuildStarted(buildname, targets), self.configuration.data)
+        buildname = self.data.getVar("BUILDNAME")
+        bb.event.fire(bb.event.BuildStarted(buildname, targets), self.data)
 
-        localdata = data.createCopy(self.configuration.data)
+        localdata = data.createCopy(self.data)
         bb.data.update_data(localdata)
         bb.data.expandKeys(localdata)
 
@@ -1087,31 +1123,52 @@ class BBCooker:
             runlist.append([k, "do_%s" % task])
         taskdata.add_unresolved(localdata, self.recipecache)
 
-        rq = bb.runqueue.RunQueue(self, self.configuration.data, self.recipecache, taskdata, runlist)
+        rq = bb.runqueue.RunQueue(self, self.data, self.recipecache, taskdata, runlist)
         if universe:
             rq.rqdata.warn_multi_bb = True
 
         self.configuration.server_register_idlecallback(buildTargetsIdle, rq)
 
-    def generateNewImage(self, image, base_image, package_queue):
+    def generateNewImage(self, image, base_image, package_queue, timestamp, description):
         '''
-        Create a new image with a "require" base_image statement
+        Create a new image with a "require"/"inherit" base_image statement
         '''
-        image_name = os.path.splitext(image)[0]
-        timestr = time.strftime("-%Y%m%d-%H%M%S")
-        dest = image_name + str(timestr) + ".bb"
+        if timestamp:
+            image_name = os.path.splitext(image)[0]
+            timestr = time.strftime("-%Y%m%d-%H%M%S")
+            dest = image_name + str(timestr) + ".bb"
+        else:
+            if not image.endswith(".bb"):
+                dest = image + ".bb"
+            else:
+                dest = image
+
+        if base_image:
+            with open(base_image, 'r') as f:
+                require_line = f.readline()
 
         with open(dest, "w") as imagefile:
-            imagefile.write("require " + base_image + "\n")
-            package_install = "PACKAGE_INSTALL_forcevariable = \""
+            if base_image is None:
+                imagefile.write("inherit image\n")
+            else:
+                topdir = self.data.getVar("TOPDIR")
+                if topdir in base_image:
+                    base_image = require_line.split()[1]
+                imagefile.write("require " + base_image + "\n")
+            image_install = "IMAGE_INSTALL = \""
             for package in package_queue:
-                package_install += str(package) + " "
-            package_install += "\"\n"
-            imagefile.write(package_install)
+                image_install += str(package) + " "
+            image_install += "\"\n"
+            imagefile.write(image_install)
+
+            description_var = "DESCRIPTION = \"" + description + "\"\n"
+            imagefile.write(description_var)
 
         self.state = state.initial
-        return timestr
+        if timestamp:
+            return timestr
 
+    # This is called for all async commands when self.state != running
     def updateCache(self):
         if self.state == state.running:
             return
@@ -1123,16 +1180,16 @@ class BBCooker:
         if self.state != state.parsing:
             self.parseConfiguration ()
 
-            ignore = self.configuration.data.getVar("ASSUME_PROVIDED", True) or ""
+            ignore = self.data.getVar("ASSUME_PROVIDED", True) or ""
             self.recipecache.ignored_dependencies = set(ignore.split())
 
             for dep in self.configuration.extra_assume_provided:
                 self.recipecache.ignored_dependencies.add(dep)
 
             self.collection = CookerCollectFiles(self.recipecache.bbfile_config_priorities)
-            (filelist, masked) = self.collection.collect_bbfiles(self.configuration.data, self.configuration.event_data)
+            (filelist, masked) = self.collection.collect_bbfiles(self.data, self.event_data)
 
-            self.configuration.data.renameVar("__depends", "__base_depends")
+            self.data.renameVar("__depends", "__base_depends")
 
             self.parser = CookerParser(self, filelist, masked)
             self.state = state.parsing
@@ -1177,14 +1234,14 @@ class BBCooker:
         # necessary from the data store.
         #bb.utils.empty_environment()
         try:
-            prserv.serv.auto_start(self.configuration.data)
+            self.prhost = prserv.serv.auto_start(self.data)
         except prserv.serv.PRServiceConfigError:
-            bb.event.fire(CookerExit(), self.configuration.event_data)
+            bb.event.fire(CookerExit(), self.event_data)
         return
 
     def post_serve(self):
-        prserv.serv.auto_shutdown(self.configuration.data)
-        bb.event.fire(CookerExit(), self.configuration.event_data)
+        prserv.serv.auto_shutdown(self.data)
+        bb.event.fire(CookerExit(), self.event_data)
 
     def shutdown(self):
         self.state = state.shutdown
@@ -1192,16 +1249,12 @@ class BBCooker:
     def stop(self):
         self.state = state.stop
 
-    def reparseFiles(self):
-        return
-
     def initialize(self):
         self.state = state.initial
         self.initConfigurationData()
 
     def reset(self):
         self.state = state.initial
-        self.initConfigurationData()
         self.loadConfigurationData()
 
 def server_main(cooker, func, *args):
@@ -1490,8 +1543,8 @@ class CookerParser(object):
     def __init__(self, cooker, filelist, masked):
         self.filelist = filelist
         self.cooker = cooker
-        self.cfgdata = cooker.configuration.data
-        self.cfghash = cooker.configuration.data_hash
+        self.cfgdata = cooker.data
+        self.cfghash = cooker.data_hash
 
         # Accounting statistics
         self.parsed = 0
@@ -1582,8 +1635,8 @@ class CookerParser(object):
         sync = threading.Thread(target=self.bb_cache.sync)
         sync.start()
         multiprocessing.util.Finalize(None, sync.join, exitpriority=-100)
-        bb.codeparser.parser_cache_savemerge(self.cooker.configuration.data)
-        bb.fetch.fetcher_parse_done(self.cooker.configuration.data)
+        bb.codeparser.parser_cache_savemerge(self.cooker.data)
+        bb.fetch.fetcher_parse_done(self.cooker.data)
 
     def load_cached(self):
         for filename, appends in self.fromcache:

bitbake/lib/bb/cookerdata.py

@@ -25,7 +25,9 @@
 import os, sys
 from functools import wraps
 import logging
+import bb
 from bb import data
+import bb.parse
 
 logger      = logging.getLogger("BitBake")
 parselog    = logging.getLogger("BitBake.Parsing")
@@ -139,6 +141,20 @@ class CookerConfiguration(object):
     def setServerRegIdleCallback(self, srcb):
         self.server_register_idlecallback = srcb
 
+    def __getstate__(self):
+        state = {}
+        for key in self.__dict__.keys():
+            if key == "server_register_idlecallback":
+                state[key] = None
+            else:
+                state[key] = getattr(self, key)
+        return state
+
+    def __setstate__(self,state):
+        for k in state:
+            setattr(self, k, state[k]) 
+
+
 def catch_parse_error(func):
     """Exception handling bits for our parsing"""
     @wraps(func)
@@ -146,6 +162,8 @@ def catch_parse_error(func):
         try:
             return func(fn, *args)
         except (IOError, bb.parse.ParseError, bb.data_smart.ExpansionError) as exc:
+            import traceback
+            parselog.critical( traceback.format_exc())
             parselog.critical("Unable to parse %s: %s" % (fn, exc))
             sys.exit(1)
     return wrapped
@@ -159,14 +177,21 @@ def _inherit(bbclass, data):
     bb.parse.BBHandler.inherit(bbclass, "configuration INHERITs", 0, data)
     return data
 
-def findConfigFile(configfile):
+def findConfigFile(configfile, data):
+    search = []
+    bbpath = data.getVar("BBPATH", True)
+    if bbpath:
+        for i in bbpath.split(":"):
+            search.append(os.path.join(i, "conf", configfile))
     path = os.getcwd()
     while path != "/":
-        confpath = os.path.join(path, "conf", configfile)
-        if os.path.exists(confpath):
-            return confpath
-
+        search.append(os.path.join(path, "conf", configfile))
         path, _ = os.path.split(path)
+
+    for i in search:
+        if os.path.exists(i):
+            return i
+
     return None
 
 class CookerDataBuilder(object):
@@ -207,8 +232,8 @@ class CookerDataBuilder(object):
             logger.exception("Error parsing configuration files")
             sys.exit(1)
 
-    def _findLayerConf(self):
-        return findConfigFile("bblayers.conf")
+    def _findLayerConf(self, data):
+        return findConfigFile("bblayers.conf", data)
 
     def parseConfigurationFiles(self, prefiles, postfiles):
         data = self.data
@@ -218,9 +243,12 @@ class CookerDataBuilder(object):
         for f in prefiles:
             data = parse_config_file(f, data)
 
-        layerconf = self._findLayerConf()
+        layerconf = self._findLayerConf(data)
         if layerconf:
             parselog.debug(2, "Found bblayers.conf (%s)", layerconf)
+            # By definition bblayers.conf is in conf/ of TOPDIR.
+            # We may have been called with cwd somewhere else so reset TOPDIR
+            data.setVar("TOPDIR", os.path.dirname(os.path.dirname(layerconf)))
             data = parse_config_file(layerconf, data)
 
             layers = (data.getVar('BBLAYERS', True) or "").split()
@@ -235,7 +263,12 @@ class CookerDataBuilder(object):
             data.delVar('LAYERDIR')
 
         if not data.getVar("BBPATH", True):
-            raise SystemExit("The BBPATH variable is not set")
+            msg = "The BBPATH variable is not set"
+            if not layerconf:
+                msg += (" and bitbake did not find a conf/bblayers.conf file in"
+                        " the expected location.\nMaybe you accidentally"
+                        " invoked bitbake from the wrong directory?")
+            raise SystemExit(msg)
 
         data = parse_config_file(os.path.join("conf", "bitbake.conf"), data)
 
@@ -251,7 +284,7 @@ class CookerDataBuilder(object):
         # Nomally we only register event handlers at the end of parsing .bb files
         # We register any handlers we've found so far here...
         for var in data.getVar('__BBHANDLERS') or []:
-            bb.event.register(var, data.getVar(var))
+            bb.event.register(var, data.getVar(var),  (data.getVarFlag(var, "eventmask", True) or "").split())
 
         if data.getVar("BB_WORKERCONTEXT", False) is None:
             bb.fetch.fetcher_init(data)

bitbake/lib/bb/data.py

@@ -97,6 +97,10 @@ def delVar(var, d):
     """Removes a variable from the data set"""
     d.delVar(var)
 
+def appendVar(var, value, d):
+    """Append additional value to a variable"""
+    d.appendVar(var, value)
+
 def setVarFlag(var, flag, flagvalue, d):
     """Set a flag for a given variable to a given value"""
     d.setVarFlag(var, flag, flagvalue)

bitbake/lib/bb/data_smart.py

@@ -38,8 +38,8 @@ from bb.COW  import COWDictBase
 
 logger = logging.getLogger("BitBake.Data")
 
-__setvar_keyword__ = ["_append", "_prepend"]
-__setvar_regexp__ = re.compile('(?P<base>.*?)(?P<keyword>_append|_prepend)(_(?P<add>.*))?$')
+__setvar_keyword__ = ["_append", "_prepend", "_remove"]
+__setvar_regexp__ = re.compile('(?P<base>.*?)(?P<keyword>_append|_prepend|_remove)(_(?P<add>.*))?$')
 __expand_var_regexp__ = re.compile(r"\${[^{}]+}")
 __expand_python_regexp__ = re.compile(r"\${@.+?}")
 
@@ -357,7 +357,8 @@ class DataSmart(MutableMapping):
 
         #
         # First we apply all overrides
-        # Then  we will handle _append and _prepend
+        # Then we will handle _append and _prepend and store the _remove
+        # information for later.
         #
 
         # We only want to report finalization once per variable overridden.
@@ -392,7 +393,7 @@ class DataSmart(MutableMapping):
                 except Exception:
                     logger.info("Untracked delVar")
 
-        # now on to the appends and prepends
+        # now on to the appends and prepends, and stashing the removes
         for op in __setvar_keyword__:
             if op in self._special_values:
                 appends = self._special_values[op] or []
@@ -415,6 +416,10 @@ class DataSmart(MutableMapping):
                         elif op == "_prepend":
                             sval = a + (self.getVar(append, False) or "")
                             self.setVar(append, sval)
+                        elif op == "_remove":
+                            removes = self.getVarFlag(append, "_removeactive", False) or []
+                            removes.extend(a.split())
+                            self.setVarFlag(append, "_removeactive", removes, ignore=True)
 
                     # We save overrides that may be applied at some later stage
                     if keep:
@@ -485,23 +490,22 @@ class DataSmart(MutableMapping):
 
         # more cookies for the cookie monster
         if '_' in var:
-            override = var[var.rfind('_')+1:]
-            if len(override) > 0:
-                if override not in self._seen_overrides:
-                    self._seen_overrides[override] = set()
-                self._seen_overrides[override].add( var )
+            self._setvar_update_overrides(var)
 
         # setting var
         self.dict[var]["_content"] = value
         self.varhistory.record(**loginfo)
 
-    def getVar(self, var, expand=False, noweakdefault=False):
-        value = self.getVarFlag(var, "_content", False, noweakdefault)
+    def _setvar_update_overrides(self, var):
+        # aka pay the cookie monster
+        override = var[var.rfind('_')+1:]
+        if len(override) > 0:
+            if override not in self._seen_overrides:
+                self._seen_overrides[override] = set()
+            self._seen_overrides[override].add( var )
 
-        # Call expand() separately to make use of the expand cache
-        if expand and value:
-            return self.expand(value, var)
-        return value
+    def getVar(self, var, expand=False, noweakdefault=False):
+        return self.getVarFlag(var, "_content", expand, noweakdefault)
 
     def renameVar(self, key, newkey, **loginfo):
         """
@@ -515,7 +519,7 @@ class DataSmart(MutableMapping):
             self.varhistory.record(**loginfo)
             self.setVar(newkey, val, ignore=True)
 
-        for i in ('_append', '_prepend'):
+        for i in (__setvar_keyword__):
             src = self.getVarFlag(key, i)
             if src is None:
                 continue
@@ -566,6 +570,9 @@ class DataSmart(MutableMapping):
             self._makeShadowCopy(var)
         self.dict[var][flag] = value
 
+        if flag == "defaultval" and '_' in var:
+            self._setvar_update_overrides(var)
+
     def getVarFlag(self, var, flag, expand=False, noweakdefault=False):
         local_var = self._findVar(var)
         value = None
@@ -575,7 +582,15 @@ class DataSmart(MutableMapping):
             elif flag == "_content" and "defaultval" in local_var and not noweakdefault:
                 value = copy.copy(local_var["defaultval"])
         if expand and value:
-            value = self.expand(value, None)
+            # Only getvar (flag == _content) hits the expand cache
+            cachename = None
+            if flag == "_content":
+                cachename = var
+            value = self.expand(value, cachename)
+        if value and flag == "_content" and local_var and "_removeactive" in local_var:
+            filtered = filter(lambda v: v not in local_var["_removeactive"],
+                              value.split(" "))
+            value = " ".join(filtered)
         return value
 
     def delVarFlag(self, var, flag, **loginfo):
@@ -738,6 +753,12 @@ class DataSmart(MutableMapping):
             value = d.getVar(key, False) or ""
             data.update({key:value})
 
+            varflags = d.getVarFlags(key)
+            if not varflags:
+                continue
+            for f in varflags:
+                data.update({'%s[%s]' % (key, f):varflags[f]})
+
         for key in ["__BBTASKS", "__BBANONFUNCS", "__BBHANDLERS"]:
             bb_list = d.getVar(key, False) or []
             bb_list.sort()

bitbake/lib/bb/event.py

@@ -33,11 +33,12 @@ import atexit
 import traceback
 import bb.utils
 import bb.compat
+import bb.exceptions
 
 # This is the pid for which we should generate the event. This is set when
 # the runqueue forks off.
 worker_pid = 0
-worker_pipe = None
+worker_fire = None
 
 logger = logging.getLogger('BitBake.Event')
 
@@ -62,7 +63,10 @@ def clean_class_handlers():
 # Internal
 _handlers = clean_class_handlers()
 _ui_handlers = {}
+_ui_logfilters = {}
 _ui_handler_seq = 0
+_event_handler_map = {}
+_catchall_handlers = {}
 
 def execute_handler(name, handler, event, d):
     event.data = d
@@ -86,11 +90,14 @@ def fire_class_handlers(event, d):
     if isinstance(event, logging.LogRecord):
         return
 
+    eid = str(event.__class__)[8:-2]
+    evt_hmap = _event_handler_map.get(eid, {})
     for name, handler in _handlers.iteritems():
-        try:
-            execute_handler(name, handler, event, d)
-        except Exception:
-            continue
+        if name in _catchall_handlers or name in evt_hmap:
+            try:
+                execute_handler(name, handler, event, d)
+            except Exception:
+                continue
 
 ui_queue = []
 @atexit.register
@@ -129,6 +136,8 @@ def fire_ui_handlers(event, d):
     for h in _ui_handlers:
         #print "Sending event %s" % event
         try:
+             if not _ui_logfilters[h].filter(event):
+                 continue
              # We use pickle here since it better handles object instances
              # which xmlrpc's marshaller does not. Events *must* be serializable
              # by pickle.
@@ -150,24 +159,16 @@ def fire(event, d):
     # don't have a datastore so the datastore context isn't a problem.
 
     fire_class_handlers(event, d)
-    if worker_pid != 0:
+    if worker_fire:
         worker_fire(event, d)
     else:
         fire_ui_handlers(event, d)
 
-def worker_fire(event, d):
-    data = "<event>" + pickle.dumps(event) + "</event>"
-    worker_pipe.write(data)
-
 def fire_from_worker(event, d):
-    if not event.startswith("<event>") or not event.endswith("</event>"):
-        print("Error, not an event %s" % event)
-        return
-    event = pickle.loads(event[7:-8])
     fire_ui_handlers(event, d)
 
 noop = lambda _: None
-def register(name, handler):
+def register(name, handler, mask=[]):
     """Register an Event handler"""
 
     # already registered
@@ -192,6 +193,14 @@ def register(name, handler):
         else:
             _handlers[name] = handler
 
+        if not mask or '*' in mask:
+            _catchall_handlers[name] = True
+        else:
+            for m in mask:
+                if _event_handler_map.get(m, None) is None:
+                    _event_handler_map[m] = {}
+                _event_handler_map[m][name] = True
+
         return Registered
 
 def remove(name, handler):
@@ -201,6 +210,8 @@ def remove(name, handler):
 def register_UIHhandler(handler):
     bb.event._ui_handler_seq = bb.event._ui_handler_seq + 1
     _ui_handlers[_ui_handler_seq] = handler
+    level, debug_domains = bb.msg.constructLogOptions()
+    _ui_logfilters[_ui_handler_seq] = UIEventFilter(level, debug_domains)
     return _ui_handler_seq
 
 def unregister_UIHhandler(handlerNum):
@@ -208,6 +219,37 @@ def unregister_UIHhandler(handlerNum):
         del _ui_handlers[handlerNum]
     return
 
+# Class to allow filtering of events and specific filtering of LogRecords *before* we put them over the IPC
+class UIEventFilter(object):
+    def __init__(self, level, debug_domains):
+        self.update(None, level, debug_domains)
+
+    def update(self, eventmask, level, debug_domains):
+        self.eventmask = eventmask
+        self.stdlevel = level
+        self.debug_domains = debug_domains
+
+    def filter(self, event):
+        if isinstance(event, logging.LogRecord):
+            if event.levelno >= self.stdlevel:
+                return True
+            if event.name in self.debug_domains and event.levelno >= self.debug_domains[event.name]:
+                return True
+            return False
+        eid = str(event.__class__)[8:-2]
+        if self.eventmask and eid not in self.eventmask:
+            return False
+        return True
+
+def set_UIHmask(handlerNum, level, debug_domains, mask):
+    if not handlerNum in _ui_handlers:
+        return False
+    if '*' in mask:
+        _ui_logfilters[handlerNum].update(None, level, debug_domains)
+    else:
+        _ui_logfilters[handlerNum].update(mask, level, debug_domains)
+    return True
+
 def getName(e):
     """Returns the name of a class or class instance"""
     if getattr(e, "__name__", None) == None:
@@ -335,12 +377,13 @@ class DiskFull(Event):
 class NoProvider(Event):
     """No Provider for an Event"""
 
-    def __init__(self, item, runtime=False, dependees=None, reasons=[]):
+    def __init__(self, item, runtime=False, dependees=None, reasons=[], close_matches=[]):
         Event.__init__(self)
         self._item = item
         self._runtime = runtime
         self._dependees = dependees
         self._reasons = reasons
+        self._close_matches = close_matches
 
     def getItem(self):
         return self._item

bitbake/lib/bb/fetch2/__init__.py

@@ -121,7 +121,7 @@ class ParameterError(BBFetchException):
 class NetworkAccess(BBFetchException):
     """Exception raised when network access is disabled but it is required."""
     def __init__(self, url, cmd):
-         msg = "Network access disabled through BB_NO_NETWORK but access requested with command %s (for url %s)" % (cmd, url)
+         msg = "Network access disabled through BB_NO_NETWORK (or set indirectly due to use of BB_FETCH_PREMIRRORONLY) but access requested with command %s (for url %s)" % (cmd, url)
          self.url = url
          self.cmd = cmd
          BBFetchException.__init__(self, msg)
@@ -638,12 +638,12 @@ def get_srcrev(d):
         ud = urldata[scm]
         for name in ud.names:
             autoinc, rev = ud.method.sortable_revision(scm, ud, d, name)
+            seenautoinc = seenautoinc or autoinc
             if len(rev) > 10:
                 rev = rev[:10]
-            if autoinc and not seenautoinc:
-                rev = "AUTOINC+" + rev
-                seenautoinc = True
             format = format.replace(name, rev)
+    if seenautoinc:
+       format = "AUTOINC+" + format
 
     return format
 
@@ -990,13 +990,13 @@ class FetchData(object):
             self.sha256_name = "sha256sum"
         if self.md5_name in self.parm:
             self.md5_expected = self.parm[self.md5_name]
-        elif self.type not in ["http", "https", "ftp", "ftps"]:
+        elif self.type not in ["http", "https", "ftp", "ftps", "sftp"]:
             self.md5_expected = None
         else:
             self.md5_expected = d.getVarFlag("SRC_URI", self.md5_name)
         if self.sha256_name in self.parm:
             self.sha256_expected = self.parm[self.sha256_name]
-        elif self.type not in ["http", "https", "ftp", "ftps"]:
+        elif self.type not in ["http", "https", "ftp", "ftps", "sftp"]:
             self.sha256_expected = None
         else:
             self.sha256_expected = d.getVarFlag("SRC_URI", self.sha256_name)
@@ -1105,7 +1105,7 @@ class FetchMethod(object):
     def recommends_checksum(self, urldata):
         """
         Is the backend on where checksumming is recommended (should warnings 
-        by displayed if there is no checksum)?
+        be displayed if there is no checksum)?
         """
         return False
 
@@ -1157,7 +1157,7 @@ class FetchMethod(object):
                      (file, urldata.parm.get('unpack')))
 
         dots = file.split(".")
-        if dots[-1] in ['gz', 'bz2', 'Z']:
+        if dots[-1] in ['gz', 'bz2', 'Z', 'xz']:
             efile = os.path.join(rootdir, os.path.basename('.'.join(dots[0:-1])))
         else:
             efile = file

bitbake/lib/bb/msg.py

@@ -146,8 +146,7 @@ def init_msgconfig(verbose, debug, debug_domains = []):
         bb.msg.loggerVerboseLogs = True
     bb.msg.loggerDefaultDomains = debug_domains
 
-def addDefaultlogFilter(handler):
-
+def constructLogOptions():
     debug = loggerDefaultDebugLevel
     verbose = loggerDefaultVerbose
     domains = loggerDefaultDomains
@@ -163,6 +162,10 @@ def addDefaultlogFilter(handler):
     for (domainarg, iterator) in groupby(domains):
         dlevel = len(tuple(iterator))
         debug_domains["BitBake.%s" % domainarg] = logging.DEBUG - dlevel + 1
+    return level, debug_domains
+
+def addDefaultlogFilter(handler):
+    level, debug_domains = constructLogOptions()
 
     BBLogFilter(handler, level, debug_domains)
 

bitbake/lib/bb/parse/__init__.py

@@ -107,6 +107,9 @@ def resolve_file(fn, d):
             raise IOError("file %s not found in %s" % (fn, bbpath))
         fn = newfn
 
+    if not os.path.isfile(fn):
+        raise IOError("file %s not found" % fn)
+
     logger.debug(2, "LOAD %s", fn)
     return fn
 

bitbake/lib/bb/parse/ast.py

@@ -147,7 +147,7 @@ class MethodNode(AstNode):
     def eval(self, data):
         text = '\n'.join(self.body)
         if self.func_name == "__anonymous":
-            funcname = ("__anon_%s_%s" % (self.lineno, self.filename.translate(string.maketrans('/.+-', '____'))))
+            funcname = ("__anon_%s_%s" % (self.lineno, self.filename.translate(string.maketrans('/.+-@', '_____'))))
             text = "def %s(d):\n" % (funcname) + text
             bb.methodpool.insert_method(funcname, text, self.filename)
             anonfuncs = data.getVar('__BBANONFUNCS') or []
@@ -320,8 +320,7 @@ def finalize(fn, d, variant = None):
     all_handlers = {}
     for var in d.getVar('__BBHANDLERS') or []:
         # try to add the handler
-        handler = d.getVar(var)
-        bb.event.register(var, handler)
+        bb.event.register(var, d.getVar(var), (d.getVarFlag(var, "eventmask", True) or "").split())
 
     bb.event.fire(bb.event.RecipePreFinalise(fn), d)
 

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

@@ -89,7 +89,7 @@ def include(oldfn, fn, lineno, data, error_out):
     from bb.parse import handle
     try:
         ret = handle(fn, data, True)
-    except IOError:
+    except (IOError, OSError):
         if error_out:
             raise ParseError("Could not %(error_out)s file %(fn)s" % vars(), oldfn, lineno)
         logger.debug(2, "CONF file '%s' not found", fn)

bitbake/lib/bb/providers.py

@@ -341,7 +341,7 @@ def filterProvidersRunTime(providers, item, cfgData, dataCache):
     if numberPreferred > 1:
         logger.error("Trying to resolve runtime dependency %s resulted in conflicting PREFERRED_PROVIDER entries being found.\nThe providers found were: %s\nThe PREFERRED_PROVIDER entries resulting in this conflict were: %s", item, preferred, preferred_vars)
 
-    logger.debug(1, "sorted providers for %s are: %s", item, eligible)
+    logger.debug(1, "sorted runtime providers for %s are: %s", item, eligible)
 
     return eligible, numberPreferred
 
@@ -376,5 +376,6 @@ def getRuntimeProviders(dataCache, rdepend):
             regexp_cache[pattern] = regexp
         if regexp.match(rdepend):
             rproviders += dataCache.packages_dynamic[pattern]
+            logger.debug(1, "Assuming %s is a dynamic package, but it may not exist" % rdepend)
 
     return rproviders

bitbake/lib/bb/runqueue.py

@@ -28,10 +28,17 @@ import sys
 import signal
 import stat
 import fcntl
+import errno
 import logging
 import bb
 from bb import msg, data, event
 from bb import monitordisk
+import subprocess
+
+try:
+    import cPickle as pickle
+except ImportError:
+    import pickle
 
 bblogger = logging.getLogger("BitBake")
 logger = logging.getLogger("BitBake.RunQueue")
@@ -77,7 +84,6 @@ runQueueRunning = 6
 runQueueFailed = 7
 runQueueCleanUp = 8
 runQueueComplete = 9
-runQueueChildProcess = 10
 
 class RunQueueScheduler(object):
     """
@@ -376,6 +382,7 @@ class RunQueueData:
 
         runq_build = []
         recursivetasks = {}
+        recursiveitasks = {}
         recursivetasksselfref = set()
 
         taskData = self.taskData
@@ -498,6 +505,12 @@ class RunQueueData:
                     if taskData.tasks_name[task] in tasknames:
                         recursivetasksselfref.add(task)
 
+                    if 'recideptask' in task_deps and taskData.tasks_name[task] in task_deps['recideptask']:
+                        recursiveitasks[task] = []
+                        for t in task_deps['recideptask'][taskData.tasks_name[task]].split():
+                            newdep = taskData.gettask_id_fromfnid(fnid, t)
+                            recursiveitasks[task].append(newdep)
+
             self.runq_fnid.append(taskData.tasks_fnid[task])
             self.runq_task.append(taskData.tasks_name[task])
             self.runq_depends.append(depends)
@@ -530,6 +543,10 @@ class RunQueueData:
                             generate_recdeps(n)
             generate_recdeps(task)
 
+            if task in recursiveitasks:
+                for dep in recursiveitasks[task]:
+                    generate_recdeps(dep)
+
         # Remove circular references so that do_a[recrdeptask] = "do_a do_b" can work
         for task in recursivetasks:
             extradeps[task].difference_update(recursivetasksselfref)
@@ -584,7 +601,13 @@ class RunQueueData:
                 continue
 
             if target[1] not in taskData.tasks_lookup[fnid]:
-                bb.msg.fatal("RunQueue", "Task %s does not exist for target %s" % (target[1], target[0]))
+                import difflib
+                close_matches = difflib.get_close_matches(target[1], taskData.tasks_lookup[fnid], cutoff=0.7)
+                if close_matches:
+                    extra = ". Close matches:\n  %s" % "\n  ".join(close_matches)
+                else:
+                    extra = ""
+                bb.msg.fatal("RunQueue", "Task %s does not exist for target %s%s" % (target[1], target[0], extra))
 
             listid = taskData.tasks_lookup[fnid][target[1]]
 
@@ -673,6 +696,14 @@ class RunQueueData:
                     prov_list[prov].append(fn)
         for prov in prov_list:
             if len(prov_list[prov]) > 1 and prov not in self.multi_provider_whitelist:
+                seen_pn = []
+                # If two versions of the same PN are being built its fatal, we don't support it.
+                for fn in prov_list[prov]:
+                    pn = self.dataCache.pkg_fn[fn]
+                    if pn not in seen_pn:
+                        seen_pn.append(pn)
+                    else:
+                        bb.fatal("Multiple versions of %s are due to be built (%s). Only one version of a given PN should be built in any given build. You likely need to set PREFERRED_VERSION_%s to select the correct version or don't depend on multiple versions." % (pn, " ".join(prov_list[prov]), pn))
                 msg = "Multiple .bb files are due to be built which each provide %s (%s)." % (prov, " ".join(prov_list[prov]))
                 if self.warn_multi_bb:
                     logger.warn(msg)
@@ -680,7 +711,6 @@ class RunQueueData:
                     msg += "\n This usually means one provides something the other doesn't and should."
                     logger.error(msg)
 
-
         # Create a whitelist usable by the stamp checks
         stampfnwhitelist = []
         for entry in self.stampwhitelist.split():
@@ -703,6 +733,9 @@ class RunQueueData:
 
         def invalidate_task(fn, taskname, error_nostamp):
             taskdep = self.dataCache.task_deps[fn]
+            fnid = self.taskData.getfn_id(fn)
+            if taskname not in taskData.tasks_lookup[fnid]:
+                logger.warn("Task %s does not exist, invalidating this task will have no effect" % taskname)
             if 'nostamp' in taskdep and taskname in taskdep['nostamp']:
                 if error_nostamp:
                     bb.fatal("Task %s is marked nostamp, cannot invalidate this task" % taskname)
@@ -793,6 +826,92 @@ class RunQueue:
         self.dm = monitordisk.diskMonitor(cfgData)
 
         self.rqexe = None
+        self.worker = None
+        self.workerpipe = None
+        self.fakeworker = None
+        self.fakeworkerpipe = None
+
+    def _start_worker(self, fakeroot = False, rqexec = None):
+        logger.debug(1, "Starting bitbake-worker")
+        if fakeroot:
+            fakerootcmd = self.cfgData.getVar("FAKEROOTCMD", True)
+            fakerootenv = (self.cfgData.getVar("FAKEROOTBASEENV", True) or "").split()
+            env = os.environ.copy()
+            for key, value in (var.split('=') for var in fakerootenv):
+                env[key] = value
+            worker = subprocess.Popen([fakerootcmd, "bitbake-worker", "decafbad"], stdout=subprocess.PIPE, stdin=subprocess.PIPE, env=env)
+        else:
+            worker = subprocess.Popen(["bitbake-worker", "decafbad"], stdout=subprocess.PIPE, stdin=subprocess.PIPE)
+        bb.utils.nonblockingfd(worker.stdout)
+        workerpipe = runQueuePipe(worker.stdout, None, self.cfgData, rqexec)
+
+        workerdata = {
+            "taskdeps" : self.rqdata.dataCache.task_deps,
+            "fakerootenv" : self.rqdata.dataCache.fakerootenv,
+            "fakerootdirs" : self.rqdata.dataCache.fakerootdirs,
+            "fakerootnoenv" : self.rqdata.dataCache.fakerootnoenv,
+            "hashes" : self.rqdata.hashes,
+            "hash_deps" : self.rqdata.hash_deps,
+            "sigchecksums" : bb.parse.siggen.file_checksum_values,
+            "runq_hash" : self.rqdata.runq_hash,
+            "logdefaultdebug" : bb.msg.loggerDefaultDebugLevel,
+            "logdefaultverbose" : bb.msg.loggerDefaultVerbose,
+            "logdefaultverboselogs" : bb.msg.loggerVerboseLogs,
+            "logdefaultdomain" : bb.msg.loggerDefaultDomains,
+            "prhost" : self.cooker.prhost,
+            "buildname" : self.cfgData.getVar("BUILDNAME", True),
+            "date" : self.cfgData.getVar("DATE", True),
+            "time" : self.cfgData.getVar("TIME", True),
+        }
+
+        worker.stdin.write("<cookerconfig>" + pickle.dumps(self.cooker.configuration) + "</cookerconfig>")
+        worker.stdin.write("<workerdata>" + pickle.dumps(workerdata) + "</workerdata>")
+        worker.stdin.flush()
+
+        return worker, workerpipe
+
+    def _teardown_worker(self, worker, workerpipe):
+        if not worker:
+            return
+        logger.debug(1, "Teardown for bitbake-worker")
+        worker.stdin.write("<quit></quit>")
+        worker.stdin.flush()
+        while worker.returncode is None:
+            workerpipe.read()
+            worker.poll()
+        while workerpipe.read():
+            continue
+        workerpipe.close()
+
+    def start_worker(self):
+        if self.worker:
+            self.teardown_workers()
+        self.worker, self.workerpipe = self._start_worker()
+
+    def start_fakeworker(self, rqexec):
+        if not self.fakeworker:
+            self.fakeworker, self.fakeworkerpipe = self._start_worker(True, rqexec)
+
+    def teardown_workers(self):
+        self._teardown_worker(self.worker, self.workerpipe)
+        self.worker = None
+        self.workerpipe = None
+        self._teardown_worker(self.fakeworker, self.fakeworkerpipe)
+        self.fakeworker = None
+        self.fakeworkerpipe = None
+
+    def read_workers(self):
+        self.workerpipe.read()
+        if self.fakeworkerpipe:
+            self.fakeworkerpipe.read()
+
+    def active_fds(self):
+        fds = []
+        if self.workerpipe:
+            fds.append(self.workerpipe.input)
+        if self.fakeworkerpipe:
+            fds.append(self.fakeworkerpipe.input)
+        return fds
 
     def check_stamp_task(self, task, taskname = None, recurse = False, cache = None):
         def get_timestamp(f):
@@ -871,7 +990,7 @@ class RunQueue:
         (if the abort on failure configuration option isn't set)
         """
 
-        retval = 0.5
+        retval = True
 
         if self.state is runQueuePrepare:
             self.rqexe = RunQueueExecuteDummy(self)
@@ -884,6 +1003,7 @@ class RunQueue:
             if self.cooker.configuration.dump_signatures:
                 self.dump_signatures()
             else:
+                self.start_worker()
                 self.rqexe = RunQueueExecuteScenequeue(self)
 
         if self.state in [runQueueSceneRun, runQueueRunning, runQueueCleanUp]:
@@ -904,6 +1024,7 @@ class RunQueue:
            self.rqexe.finish()
 
         if self.state is runQueueComplete or self.state is runQueueFailed:
+            self.teardown_workers()
             if self.rqexe.stats.failed:
                 logger.info("Tasks Summary: Attempted %d tasks of which %d didn't need to be rerun and %d failed.", self.rqexe.stats.completed + self.rqexe.stats.failed, self.rqexe.stats.skipped, self.rqexe.stats.failed)
             else:
@@ -921,10 +1042,6 @@ class RunQueue:
             # All done
             return False
 
-        if self.state is runQueueChildProcess:
-            print("Child process, eeek, shouldn't happen!")
-            return False
-
         # Loop
         return retval
 
@@ -938,6 +1055,10 @@ class RunQueue:
             raise
         except:
             logger.error("An uncaught exception occured in runqueue, please see the failure below:")
+            try:
+                self.teardown_workers()
+            except:
+                pass
             self.state = runQueueComplete
             raise
 
@@ -957,7 +1078,7 @@ class RunQueue:
         for task in range(len(self.rqdata.runq_fnid)):
             if self.rqdata.runq_fnid[task] not in done:
                 fn = self.rqdata.taskData.fn_index[self.rqdata.runq_fnid[task]]
-                the_data = bb.cache.Cache.loadDataFull(fn, self.cooker.collection.get_file_appends(fn), self.cooker.configuration.data)
+                the_data = bb.cache.Cache.loadDataFull(fn, self.cooker.collection.get_file_appends(fn), self.cooker.data)
                 done.add(self.rqdata.runq_fnid[task])
 
         bb.parse.siggen.dump_sigs(self.rqdata.dataCache)
@@ -979,38 +1100,21 @@ class RunQueueExecute:
         self.runq_buildable = []
         self.runq_running = []
         self.runq_complete = []
-        self.build_pids = {}
-        self.build_pipes = {}
+
         self.build_stamps = {}
         self.failed_fnids = []
 
         self.stampcache = {}
 
-    def runqueue_process_waitpid(self):
-        """
-        Return none is there are no processes awaiting result collection, otherwise
-        collect the process exit codes and close the information pipe.
-        """
-        pid, status = os.waitpid(-1, os.WNOHANG)
-        if pid == 0 or os.WIFSTOPPED(status):
-            return None
+        rq.workerpipe.setrunqueueexec(self)
+        if rq.fakeworkerpipe:
+            rq.fakeworkerpipe.setrunqueueexec(self)
 
-        if os.WIFEXITED(status):
-            status = os.WEXITSTATUS(status)
-        elif os.WIFSIGNALED(status):
-            # Per shell conventions for $?, when a process exits due to
-            # a signal, we return an exit code of 128 + SIGNUM
-            status = 128 + os.WTERMSIG(status)
-
-        task = self.build_pids[pid]
-        del self.build_pids[pid]
-
-        self.build_pipes[pid].close()
-        del self.build_pipes[pid]
+    def runqueue_process_waitpid(self, task, status):
 
         # self.build_stamps[pid] may not exist when use shared work directory.
-        if pid in self.build_stamps:
-            del self.build_stamps[pid]
+        if task in self.build_stamps:
+            del self.build_stamps[task]
 
         if status != 0:
             self.task_fail(task, status)
@@ -1019,16 +1123,12 @@ class RunQueueExecute:
         return True
 
     def finish_now(self):
-        if self.stats.active:
-            logger.info("Sending SIGTERM to remaining %s tasks", self.stats.active)
-            for k, v in self.build_pids.iteritems():
-                try:
-                    os.kill(-k, signal.SIGTERM)
-                    os.waitpid(-1, 0)
-                except:
-                    pass
-        for pipe in self.build_pipes:
-            self.build_pipes[pipe].read()
+
+        self.rq.worker.stdin.write("<finishnow></finishnow>")
+        self.rq.worker.stdin.flush()
+        if self.rq.fakeworker:
+            self.rq.fakeworker.stdin.write("<finishnow></finishnow>")
+            self.rq.fakeworker.stdin.flush()
 
         if len(self.failed_fnids) != 0:
             self.rq.state = runQueueFailed
@@ -1040,12 +1140,10 @@ class RunQueueExecute:
     def finish(self):
         self.rq.state = runQueueCleanUp
 
-        for pipe in self.build_pipes:
-            self.build_pipes[pipe].read()
-
         if self.stats.active > 0:
             bb.event.fire(runQueueExitWait(self.stats.active), self.cfgData)
-            self.runqueue_process_waitpid()
+            self.rq.read_workers()
+
             return
 
         if len(self.failed_fnids) != 0:
@@ -1055,115 +1153,6 @@ class RunQueueExecute:
         self.rq.state = runQueueComplete
         return
 
-    def fork_off_task(self, fn, task, taskname, quieterrors=False):
-        # We need to setup the environment BEFORE the fork, since
-        # a fork() or exec*() activates PSEUDO...
-
-        envbackup = {}
-        fakeenv = {}
-        umask = None
-
-        taskdep = self.rqdata.dataCache.task_deps[fn]
-        if 'umask' in taskdep and taskname in taskdep['umask']:
-            # umask might come in as a number or text string..
-            try:
-                 umask = int(taskdep['umask'][taskname],8)
-            except TypeError:
-                 umask = taskdep['umask'][taskname]
-
-        if 'fakeroot' in taskdep and taskname in taskdep['fakeroot']:
-            envvars = (self.rqdata.dataCache.fakerootenv[fn] or "").split()
-            for key, value in (var.split('=') for var in envvars):
-                envbackup[key] = os.environ.get(key)
-                os.environ[key] = value
-                fakeenv[key] = value
-
-            fakedirs = (self.rqdata.dataCache.fakerootdirs[fn] or "").split()
-            for p in fakedirs:
-                bb.utils.mkdirhier(p)
-
-            logger.debug(2, 'Running %s:%s under fakeroot, fakedirs: %s' %
-                            (fn, taskname, ', '.join(fakedirs)))
-        else:
-            envvars = (self.rqdata.dataCache.fakerootnoenv[fn] or "").split()
-            for key, value in (var.split('=') for var in envvars):
-                envbackup[key] = os.environ.get(key)
-                os.environ[key] = value
-                fakeenv[key] = value
-
-        sys.stdout.flush()
-        sys.stderr.flush()
-        try:
-            pipein, pipeout = os.pipe()
-            pipein = os.fdopen(pipein, 'rb', 4096)
-            pipeout = os.fdopen(pipeout, 'wb', 0)
-            pid = os.fork()
-        except OSError as e:
-            bb.msg.fatal("RunQueue", "fork failed: %d (%s)" % (e.errno, e.strerror))
-
-        if pid == 0:
-            pipein.close()
-
-            # Save out the PID so that the event can include it the
-            # events
-            bb.event.worker_pid = os.getpid()
-            bb.event.worker_pipe = pipeout
-
-            self.rq.state = runQueueChildProcess
-            # Make the child the process group leader
-            os.setpgid(0, 0)
-            # No stdin
-            newsi = os.open(os.devnull, os.O_RDWR)
-            os.dup2(newsi, sys.stdin.fileno())
-
-            if umask:
-                os.umask(umask)
-
-            self.cooker.configuration.data.setVar("BB_WORKERCONTEXT", "1")
-            bb.parse.siggen.set_taskdata(self.rqdata.hashes, self.rqdata.hash_deps)
-            ret = 0
-            try:
-                the_data = bb.cache.Cache.loadDataFull(fn, self.cooker.collection.get_file_appends(fn), self.cooker.configuration.data)
-                the_data.setVar('BB_TASKHASH', self.rqdata.runq_hash[task])
-                for h in self.rqdata.hashes:
-                    the_data.setVar("BBHASH_%s" % h, self.rqdata.hashes[h])
-                for h in self.rqdata.hash_deps:
-                    the_data.setVar("BBHASHDEPS_%s" % h, self.rqdata.hash_deps[h])
-
-                # exported_vars() returns a generator which *cannot* be passed to os.environ.update() 
-                # successfully. We also need to unset anything from the environment which shouldn't be there 
-                exports = bb.data.exported_vars(the_data)
-                bb.utils.empty_environment()
-                for e, v in exports:
-                    os.environ[e] = v
-                for e in fakeenv:
-                    os.environ[e] = fakeenv[e]
-                    the_data.setVar(e, fakeenv[e])
-                    the_data.setVarFlag(e, 'export', "1")
-
-                if quieterrors:
-                    the_data.setVarFlag(taskname, "quieterrors", "1")
-
-            except Exception as exc:
-                if not quieterrors:
-                    logger.critical(str(exc))
-                os._exit(1)
-            try:
-                if not self.cooker.configuration.dry_run:
-                    profile = self.cooker.configuration.profile
-                    ret = bb.build.exec_task(fn, taskname, the_data, profile)
-                os._exit(ret)
-            except:
-                os._exit(1)
-        else:
-            for key, value in envbackup.iteritems():
-                if value is None:
-                    del os.environ[key]
-                else:
-                    os.environ[key] = value
-
-        return pid, pipein, pipeout
-
     def check_dependencies(self, task, taskdeps, setscene = False):
         if not self.rq.depvalidate:
             return False
@@ -1180,7 +1169,7 @@ class RunQueueExecute:
             taskname = self.rqdata.runq_task[depid]
             taskdata[dep] = [pn, taskname, fn]
         call = self.rq.depvalidate + "(task, taskdata, notneeded, d)"
-        locs = { "task" : task, "taskdata" : taskdata, "notneeded" : self.scenequeue_notneeded, "d" : self.cooker.configuration.data }
+        locs = { "task" : task, "taskdata" : taskdata, "notneeded" : self.scenequeue_notneeded, "d" : self.cooker.data }
         valid = bb.utils.better_eval(call, locs)
         return valid
 
@@ -1247,7 +1236,7 @@ class RunQueueExecuteTasks(RunQueueExecute):
 
             call = self.rq.setsceneverify + "(covered, tasknames, fnids, fns, d, invalidtasks=invalidtasks)"
             call2 = self.rq.setsceneverify + "(covered, tasknames, fnids, fns, d)"
-            locs = { "covered" : self.rq.scenequeue_covered, "tasknames" : self.rqdata.runq_task, "fnids" : self.rqdata.runq_fnid, "fns" : self.rqdata.taskData.fn_index, "d" : self.cooker.configuration.data, "invalidtasks" : invalidtasks }
+            locs = { "covered" : self.rq.scenequeue_covered, "tasknames" : self.rqdata.runq_task, "fnids" : self.rqdata.runq_fnid, "fns" : self.rqdata.taskData.fn_index, "d" : self.cooker.data, "invalidtasks" : invalidtasks }
             # Backwards compatibility with older versions without invalidtasks
             try:
                 covered_remove = bb.utils.better_eval(call, locs)
@@ -1275,7 +1264,6 @@ class RunQueueExecuteTasks(RunQueueExecute):
             bb.fatal("Invalid scheduler '%s'.  Available schedulers: %s" %
                      (self.scheduler, ", ".join(obj.name for obj in schedulers)))
 
-
     def get_schedulers(self):
         schedulers = set(obj for obj in globals().values()
                              if type(obj) is type and
@@ -1349,6 +1337,9 @@ class RunQueueExecuteTasks(RunQueueExecute):
         Run the tasks in a queue prepared by rqdata.prepare()
         """
 
+        self.rq.read_workers()
+        
+
         if self.stats.total == 0:
             # nothing to do
             self.rq.state = runQueueCleanUp
@@ -1384,23 +1375,25 @@ class RunQueueExecuteTasks(RunQueueExecute):
                 startevent = runQueueTaskStarted(task, self.stats, self.rq)
                 bb.event.fire(startevent, self.cfgData)
 
-            pid, pipein, pipeout = self.fork_off_task(fn, task, taskname)
+            taskdep = self.rqdata.dataCache.task_deps[fn]
+            if 'fakeroot' in taskdep and taskname in taskdep['fakeroot']:
+                if not self.rq.fakeworker:
+                    self.rq.start_fakeworker(self)
+                self.rq.fakeworker.stdin.write("<runtask>" + pickle.dumps((fn, task, taskname, False, self.cooker.collection.get_file_appends(fn))) + "</runtask>")
+                self.rq.fakeworker.stdin.flush()
+            else:
+                self.rq.worker.stdin.write("<runtask>" + pickle.dumps((fn, task, taskname, False, self.cooker.collection.get_file_appends(fn))) + "</runtask>")
+                self.rq.worker.stdin.flush()
 
-            self.build_pids[pid] = task
-            self.build_pipes[pid] = runQueuePipe(pipein, pipeout, self.cfgData)
-            self.build_stamps[pid] = bb.build.stampfile(taskname, self.rqdata.dataCache, fn)
+            self.build_stamps[task] = bb.build.stampfile(taskname, self.rqdata.dataCache, fn)
             self.runq_running[task] = 1
             self.stats.taskActive()
             if self.stats.active < self.number_tasks:
                 return True
 
-        for pipe in self.build_pipes:
-            self.build_pipes[pipe].read()
-
         if self.stats.active > 0:
-            if self.runqueue_process_waitpid() is None:
-                return 0.5
-            return True
+            self.rq.read_workers()
+            return self.rq.active_fds()
 
         if len(self.failed_fnids) != 0:
             self.rq.state = runQueueFailed
@@ -1415,6 +1408,7 @@ class RunQueueExecuteTasks(RunQueueExecute):
             if self.runq_complete[task] == 0:
                 logger.error("Task %s never completed!", task)
         self.rq.state = runQueueComplete
+
         return True
 
 class RunQueueExecuteScenequeue(RunQueueExecute):
@@ -1436,6 +1430,7 @@ class RunQueueExecuteScenequeue(RunQueueExecute):
         sq_revdeps = []
         sq_revdeps_new = []
         sq_revdeps_squash = []
+        self.sq_harddeps = []
 
         # We need to construct a dependency graph for the setscene functions. Intermediate
         # dependencies between the setscene tasks only complicate the code. This code
@@ -1548,6 +1543,7 @@ class RunQueueExecuteScenequeue(RunQueueExecute):
                     if taskid is None:
                         bb.msg.fatal("RunQueue", "Task %s:%s depends upon non-existent task %s:%s" % (self.rqdata.taskData.fn_index[self.rqdata.runq_fnid[realid]], self.rqdata.taskData.tasks_name[realid], dep, idependtask))
 
+                    self.sq_harddeps.append(self.rqdata.runq_setscene.index(taskid))
                     sq_revdeps_squash[self.rqdata.runq_setscene.index(task)].add(self.rqdata.runq_setscene.index(taskid))
                     # Have to zero this to avoid circular dependencies
                     sq_revdeps_squash[self.rqdata.runq_setscene.index(taskid)] = set()
@@ -1607,7 +1603,7 @@ class RunQueueExecuteScenequeue(RunQueueExecute):
                 sq_taskname.append(taskname)
                 sq_task.append(task)
             call = self.rq.hashvalidate + "(sq_fn, sq_task, sq_hash, sq_hashfn, d)"
-            locs = { "sq_fn" : sq_fn, "sq_task" : sq_taskname, "sq_hash" : sq_hash, "sq_hashfn" : sq_hashfn, "d" : self.cooker.configuration.data }
+            locs = { "sq_fn" : sq_fn, "sq_task" : sq_taskname, "sq_hash" : sq_hash, "sq_hashfn" : sq_hashfn, "d" : self.cooker.data }
             valid = bb.utils.better_eval(call, locs)
 
             valid_new = stamppresent
@@ -1625,8 +1621,10 @@ class RunQueueExecuteScenequeue(RunQueueExecute):
 
         self.rq.state = runQueueSceneRun
 
-    def scenequeue_updatecounters(self, task):
+    def scenequeue_updatecounters(self, task, fail = False):
         for dep in self.sq_deps[task]:
+            if fail and task in self.sq_harddeps:
+                continue
             self.sq_revdeps2[dep].remove(task)
             if len(self.sq_revdeps2[dep]) == 0:
                 self.runq_buildable[dep] = 1
@@ -1647,13 +1645,14 @@ class RunQueueExecuteScenequeue(RunQueueExecute):
 
     def task_complete(self, task):
         self.stats.taskCompleted()
+        bb.event.fire(sceneQueueTaskCompleted(task, self.stats, self.rq), self.cfgData)
         self.task_completeoutright(task)
 
     def task_fail(self, task, result):
         self.stats.taskFailed()
         bb.event.fire(sceneQueueTaskFailed(task, self.stats, result, self), self.cfgData)
         self.scenequeue_notcovered.add(task)
-        self.scenequeue_updatecounters(task)
+        self.scenequeue_updatecounters(task, True)
 
     def task_failoutright(self, task):
         self.runq_running[task] = 1
@@ -1662,7 +1661,7 @@ class RunQueueExecuteScenequeue(RunQueueExecute):
         self.stats.taskSkipped()
         index = self.rqdata.runq_setscene[task]
         self.scenequeue_notcovered.add(task)
-        self.scenequeue_updatecounters(task)
+        self.scenequeue_updatecounters(task, True)
 
     def task_skip(self, task):
         self.runq_running[task] = 1
@@ -1676,6 +1675,8 @@ class RunQueueExecuteScenequeue(RunQueueExecute):
         Run the tasks in a queue prepared by prepare_runqueue
         """
 
+        self.rq.read_workers()
+
         task = None
         if self.stats.active < self.number_tasks:
             # Find the next setscene to run
@@ -1716,22 +1717,24 @@ class RunQueueExecuteScenequeue(RunQueueExecute):
             startevent = sceneQueueTaskStarted(task, self.stats, self.rq)
             bb.event.fire(startevent, self.cfgData)
 
-            pid, pipein, pipeout = self.fork_off_task(fn, realtask, taskname)
+            taskdep = self.rqdata.dataCache.task_deps[fn]
+            if 'fakeroot' in taskdep and taskname in taskdep['fakeroot']:
+                if not self.rq.fakeworker:
+                    self.rq.start_fakeworker(self)
+                self.rq.fakeworker.stdin.write("<runtask>" + pickle.dumps((fn, realtask, taskname, True, self.cooker.collection.get_file_appends(fn))) + "</runtask>")
+                self.rq.fakeworker.stdin.flush()
+            else:
+                self.rq.worker.stdin.write("<runtask>" + pickle.dumps((fn, realtask, taskname, True, self.cooker.collection.get_file_appends(fn))) + "</runtask>")
+                self.rq.worker.stdin.flush()
 
-            self.build_pids[pid] = task
-            self.build_pipes[pid] = runQueuePipe(pipein, pipeout, self.cfgData)
             self.runq_running[task] = 1
             self.stats.taskActive()
             if self.stats.active < self.number_tasks:
                 return True
 
-        for pipe in self.build_pipes:
-            self.build_pipes[pipe].read()
-
         if self.stats.active > 0:
-            if self.runqueue_process_waitpid() is None:
-                return 0.5
-            return True
+            self.rq.read_workers()
+            return self.rq.active_fds()
 
         # Convert scenequeue_covered task numbers into full taskgraph ids
         oldcovered = self.scenequeue_covered
@@ -1747,8 +1750,10 @@ class RunQueueExecuteScenequeue(RunQueueExecute):
         self.rq.state = runQueueRunInit
         return True
 
-    def fork_off_task(self, fn, task, taskname):
-        return RunQueueExecute.fork_off_task(self, fn, task, taskname, quieterrors=True)
+    def runqueue_process_waitpid(self, task, status):
+        task = self.rq.rqdata.runq_setscene.index(task)
+
+        RunQueueExecute.runqueue_process_waitpid(self, task, status)
 
 class TaskFailure(Exception):
     """
@@ -1824,29 +1829,52 @@ class runQueueTaskCompleted(runQueueEvent):
     Event notifing a task completed
     """
 
+class sceneQueueTaskCompleted(sceneQueueEvent):
+    """
+    Event notifing a setscene task completed
+    """
+
 class runQueuePipe():
     """
     Abstraction for a pipe between a worker thread and the server
     """
-    def __init__(self, pipein, pipeout, d):
+    def __init__(self, pipein, pipeout, d, rq):
         self.input = pipein
-        pipeout.close()
+        if pipeout:
+            pipeout.close()
         bb.utils.nonblockingfd(self.input)
         self.queue = ""
         self.d = d
+        self.rq = rq
+
+    def setrunqueueexec(self, rq):
+        self.rq = rq
 
     def read(self):
         start = len(self.queue)
         try:
             self.queue = self.queue + self.input.read(102400)
-        except (OSError, IOError):
-            pass
+        except (OSError, IOError) as e:
+            if e.errno != errno.EAGAIN:
+                raise
         end = len(self.queue)
-        index = self.queue.find("</event>")
-        while index != -1:
-            bb.event.fire_from_worker(self.queue[:index+8], self.d)
-            self.queue = self.queue[index+8:]
+        found = True
+        while found and len(self.queue):
+            found = False
             index = self.queue.find("</event>")
+            while index != -1 and self.queue.startswith("<event>"):
+                event = pickle.loads(self.queue[7:index])
+                bb.event.fire_from_worker(event, self.d)
+                found = True
+                self.queue = self.queue[index+8:]
+                index = self.queue.find("</event>")
+            index = self.queue.find("</exitcode>")
+            while index != -1 and self.queue.startswith("<exitcode>"):
+                task, status = pickle.loads(self.queue[10:index])
+                self.rq.runqueue_process_waitpid(task, status)
+                found = True
+                self.queue = self.queue[index+11:]
+                index = self.queue.find("</exitcode>")
         return (end > start)
 
     def close(self):

bitbake/lib/bb/server/__init__.py

@@ -0,0 +1,96 @@
+#
+# BitBake Base Server Code
+#
+# Copyright (C) 2006 - 2007  Michael 'Mickey' Lauer
+# Copyright (C) 2006 - 2008  Richard Purdie
+# Copyright (C) 2013         Alexandru Damian
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License version 2 as
+# published by the Free Software Foundation.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License along
+# with this program; if not, write to the Free Software Foundation, Inc.,
+# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+
+""" Base code for Bitbake server process
+
+Have a common base for that all Bitbake server classes ensures a consistent
+approach to the interface, and minimize risks associated with code duplication.
+
+"""
+
+"""  BaseImplServer() the base class for all XXServer() implementations.
+
+    These classes contain the actual code that runs the server side, i.e.
+    listens for the commands and executes them. Although these implementations
+    contain all the data of the original bitbake command, i.e the cooker instance,
+    they may well run on a different process or even machine.
+
+"""
+
+class BaseImplServer():
+    def __init__(self):
+        self._idlefuns = {}
+
+    def addcooker(self, cooker):
+        self.cooker = cooker
+
+    def register_idle_function(self, function, data):
+        """Register a function to be called while the server is idle"""
+        assert hasattr(function, '__call__')
+        self._idlefuns[function] = data
+
+
+
+""" BitBakeBaseServerConnection class is the common ancestor to all
+    BitBakeServerConnection classes.
+
+    These classes control the remote server. The only command currently
+    implemented is the terminate() command.
+
+"""
+
+class BitBakeBaseServerConnection():
+    def __init__(self, serverImpl):
+        pass
+
+    def terminate(self):
+        pass
+
+
+""" BitBakeBaseServer class is the common ancestor to all Bitbake servers
+
+    Derive this class in order to implement a BitBakeServer which is the
+    controlling stub for the actual server implementation
+
+"""
+class BitBakeBaseServer(object):
+    def initServer(self):
+        self.serverImpl = None  # we ensure a runtime crash if not overloaded
+        self.connection = None
+        return
+
+    def addcooker(self, cooker):
+        self.cooker = cooker
+        self.serverImpl.addcooker(cooker)
+
+    def getServerIdleCB(self):
+        return self.serverImpl.register_idle_function
+
+    def saveConnectionDetails(self):
+        return
+
+    def detach(self):
+        return
+
+    def establishConnection(self):
+        raise   "Must redefine the %s.establishConnection()" % self.__class__.__name__
+
+    def endSession(self):
+        self.connection.terminate()

bitbake/lib/bb/server/process.py

@@ -29,14 +29,18 @@ import os
 import signal
 import sys
 import time
+import select
 from Queue import Empty
 from multiprocessing import Event, Process, util, Queue, Pipe, queues
 
+from . import BitBakeBaseServer, BitBakeBaseServerConnection, BaseImplServer
+
 logger = logging.getLogger('BitBake')
 
 class ServerCommunicator():
-    def __init__(self, connection):
+    def __init__(self, connection, event_handle):
         self.connection = connection
+        self.event_handle = event_handle
 
     def runCommand(self, command):
         # @todo try/except
@@ -52,6 +56,8 @@ class ServerCommunicator():
             except KeyboardInterrupt:
                 pass
 
+    def getEventHandle(self):
+        return self.event_handle.value
 
 class EventAdapter():
     """
@@ -68,30 +74,26 @@ class EventAdapter():
             print("EventAdapter puked: %s" % str(err))
 
 
-class ProcessServer(Process):
+class ProcessServer(Process, BaseImplServer):
     profile_filename = "profile.log"
     profile_processed_filename = "profile.log.processed"
 
     def __init__(self, command_channel, event_queue):
+        BaseImplServer.__init__(self)
         Process.__init__(self)
         self.command_channel = command_channel
         self.event_queue = event_queue
         self.event = EventAdapter(event_queue)
-        self._idlefunctions = {}
         self.quit = False
 
         self.keep_running = Event()
         self.keep_running.set()
-
-    def register_idle_function(self, function, data):
-        """Register a function to be called while the server is idle"""
-        assert hasattr(function, '__call__')
-        self._idlefunctions[function] = data
+        self.event_handle = multiprocessing.Value("i")
 
     def run(self):
         for event in bb.event.ui_queue:
             self.event_queue.put(event)
-        self.event_handle = bb.event.register_UIHhandler(self)
+        self.event_handle.value = bb.event.register_UIHhandler(self)
         bb.cooker.server_main(self.cooker, self.main)
 
     def main(self):
@@ -104,37 +106,37 @@ class ProcessServer(Process):
                     command = self.command_channel.recv()
                     self.runCommand(command)
 
-                self.idle_commands(.1)
+                self.idle_commands(.1, [self.event_queue._reader, self.command_channel])
             except Exception:
                 logger.exception('Running command %s', command)
 
-        self.event_queue.cancel_join_thread()
-        bb.event.unregister_UIHhandler(self.event_handle)
+        self.event_queue.close()
+        bb.event.unregister_UIHhandler(self.event_handle.value)
         self.command_channel.close()
         self.cooker.stop()
         self.idle_commands(.1)
 
-    def idle_commands(self, delay):
+    def idle_commands(self, delay, fds = []):
         nextsleep = delay
 
-        for function, data in self._idlefunctions.items():
+        for function, data in self._idlefuns.items():
             try:
                 retval = function(self, data, False)
                 if retval is False:
-                    del self._idlefunctions[function]
+                    del self._idlefuns[function]
                 elif retval is True:
                     nextsleep = None
                 elif nextsleep is None:
                     continue
-                elif retval < nextsleep:
-                    nextsleep = retval
+                else:
+                    fds = fds + retval
             except SystemExit:
                 raise
             except Exception:
                 logger.exception('Running idle function')
 
         if nextsleep is not None:
-            time.sleep(nextsleep)
+            select.select(fds,[],[],nextsleep)
 
     def runCommand(self, command):
         """
@@ -145,80 +147,33 @@ class ProcessServer(Process):
     def stop(self):
         self.keep_running.clear()
 
-    def bootstrap_2_6_6(self):
-        """Pulled from python 2.6.6. Needed to ensure we have the fix from
-        http://bugs.python.org/issue5313 when running on python version 2.6.2
-        or lower."""
+class BitBakeProcessServerConnection(BitBakeBaseServerConnection):
+    def __init__(self, serverImpl, ui_channel, event_queue):
+        self.procserver = serverImpl
+        self.ui_channel = ui_channel
+        self.event_queue = event_queue
+        self.connection = ServerCommunicator(self.ui_channel, self.procserver.event_handle)
+        self.events = self.event_queue
 
-        try:
-            self._children = set()
-            self._counter = itertools.count(1)
-            try:
-                sys.stdin.close()
-                sys.stdin = open(os.devnull)
-            except (OSError, ValueError):
-                pass
-            multiprocessing._current_process = self
-            util._finalizer_registry.clear()
-            util._run_after_forkers()
-            util.info('child process calling self.run()')
-            try:
-                self.run()
-                exitcode = 0
-            finally:
-                util._exit_function()
-        except SystemExit as e:
-            if not e.args:
-                exitcode = 1
-            elif type(e.args[0]) is int:
-                exitcode = e.args[0]
-            else:
-                sys.stderr.write(e.args[0] + '\n')
-                sys.stderr.flush()
-                exitcode = 1
-        except:
-            exitcode = 1
-            import traceback
-            sys.stderr.write('Process %s:\n' % self.name)
-            sys.stderr.flush()
-            traceback.print_exc()
+    def terminate(self):
+        def flushevents():
+            while True:
+                try:
+                    event = self.event_queue.get(block=False)
+                except (Empty, IOError):
+                    break
+                if isinstance(event, logging.LogRecord):
+                    logger.handle(event)
 
-        util.info('process exiting with exitcode %d' % exitcode)
-        return exitcode
-
-    # Python versions 2.6.0 through 2.6.2 suffer from a multiprocessing bug
-    # which can result in a bitbake server hang during the parsing process
-    if (2, 6, 0) <= sys.version_info < (2, 6, 3):
-        _bootstrap = bootstrap_2_6_6
-
-class BitBakeServerConnection():
-    def __init__(self, server):
-        self.server = server
-        self.procserver = server.server
-        self.connection = ServerCommunicator(server.ui_channel)
-        self.events = server.event_queue
-
-    def terminate(self, force = False):
         signal.signal(signal.SIGINT, signal.SIG_IGN)
         self.procserver.stop()
-        if force:
-            self.procserver.join(0.5)
-            if self.procserver.is_alive():
-                self.procserver.terminate()
-                self.procserver.join()
-        else:
-            self.procserver.join()
-        while True:
-            try:
-                event = self.server.event_queue.get(block=False)
-            except (Empty, IOError):
-                break
-            if isinstance(event, logging.LogRecord):
-                logger.handle(event)
-        self.server.ui_channel.close()
-        self.server.event_queue.close()
-        if force:
-            sys.exit(1)
+
+        while self.procserver.is_alive():
+            flushevents()
+            self.procserver.join(0.1)
+
+        self.ui_channel.close()
+        self.event_queue.close()
 
 # Wrap Queue to provide API which isn't server implementation specific
 class ProcessEventQueue(multiprocessing.queues.Queue):
@@ -235,7 +190,7 @@ class ProcessEventQueue(multiprocessing.queues.Queue):
             return None
 
 
-class BitBakeServer(object):
+class BitBakeServer(BitBakeBaseServer):
     def initServer(self):
         # establish communication channels.  We use bidirectional pipes for
         # ui <--> server command/response pairs
@@ -243,24 +198,13 @@ class BitBakeServer(object):
         #
         self.ui_channel, self.server_channel = Pipe()
         self.event_queue = ProcessEventQueue(0)
-
-        self.server = ProcessServer(self.server_channel, self.event_queue)
-
-    def addcooker(self, cooker):
-        self.cooker = cooker
-        self.server.cooker = cooker
-
-    def getServerIdleCB(self):
-        return self.server.register_idle_function
-
-    def saveConnectionDetails(self):
-        return
+        self.serverImpl = ProcessServer(self.server_channel, self.event_queue)
 
     def detach(self):
-        self.server.start() 
+        self.serverImpl.start()
         return
 
     def establishConnection(self):
-        self.connection = BitBakeServerConnection(self)
-        signal.signal(signal.SIGTERM, lambda i, s: self.connection.terminate(force=True))
+        self.connection = BitBakeProcessServerConnection(self.serverImpl, self.ui_channel, self.event_queue)
+        signal.signal(signal.SIGTERM, lambda i, s: self.connection.terminate())
         return self.connection

bitbake/lib/bb/server/xmlrpc.py

@@ -47,105 +47,39 @@ except ImportError:
 DEBUG = False
 
 from SimpleXMLRPCServer import SimpleXMLRPCServer, SimpleXMLRPCRequestHandler
-import inspect, select
+import inspect, select, httplib
 
-if sys.hexversion < 0x020600F0:
-    print("Sorry, python 2.6 or later is required for bitbake's XMLRPC mode")
-    sys.exit(1)
+from . import BitBakeBaseServer, BitBakeBaseServerConnection, BaseImplServer
 
-##
-# The xmlrpclib.Transport class has undergone various changes in Python 2.7
-# which break BitBake's XMLRPC implementation.
-# To work around this we subclass Transport and have a copy/paste of method
-# implementations from Python 2.6.6's xmlrpclib.
-#
-# Upstream Python bug is #8194 (http://bugs.python.org/issue8194)
-# This bug is relevant for Python 2.7.0 and 2.7.1 but was fixed for
-# Python > 2.7.2
-#
-# To implement a simple form of client control, we use a special transport
-# that adds a HTTP header field ("Bitbake-token") to ensure that a server
-# can communicate with only a client at a given time (the client must use
-# the same token).
-##
-if (2, 7, 0) <= sys.version_info < (2, 7, 2):
-    class BBTransport(xmlrpclib.Transport):
-        def __init__(self):
-            self.connection_token = None
-            xmlrpclib.Transport.__init__(self)
+class BBTransport(xmlrpclib.Transport):
+    def __init__(self, timeout):
+        self.timeout = timeout
+        self.connection_token = None
+        xmlrpclib.Transport.__init__(self)
 
-        def request(self, host, handler, request_body, verbose=0):
-            h = self.make_connection(host)
-            if verbose:
-                h.set_debuglevel(1)
+    # Modified from default to pass timeout to HTTPConnection
+    def make_connection(self, host):
+        #return an existing connection if possible.  This allows
+        #HTTP/1.1 keep-alive.
+        if self._connection and host == self._connection[0]:
+            return self._connection[1]
 
-            self.send_request(h, handler, request_body)
-            self.send_host(h, host)
-            self.send_user_agent(h)
-            if self.connection_token:
-                h.putheader("Bitbake-token", self.connection_token)
-            self.send_content(h, request_body)
+        # create a HTTP connection object from a host descriptor
+        chost, self._extra_headers, x509 = self.get_host_info(host)
+        #store the host argument along with the connection object
+        self._connection = host, httplib.HTTPConnection(chost, timeout=self.timeout)
+        return self._connection[1]
 
-            errcode, errmsg, headers = h.getreply()
+    def set_connection_token(self, token):
+        self.connection_token = token
 
-            if errcode != 200:
-                raise ProtocolError(
-                    host + handler,
-                    errcode, errmsg,
-                    headers
-                    )
+    def send_content(self, h, body):
+        if self.connection_token:
+            h.putheader("Bitbake-token", self.connection_token)
+        xmlrpclib.Transport.send_content(self, h, body)
 
-            self.verbose = verbose
-
-            try:
-                sock = h._conn.sock
-            except AttributeError:
-                sock = None
-
-            return self._parse_response(h.getfile(), sock)
-
-        def make_connection(self, host):
-            import httplib
-            host, extra_headers, x509 = self.get_host_info(host)
-            return httplib.HTTP(host)
-
-        def _parse_response(self, file, sock):
-            p, u = self.getparser()
-
-            while 1:
-                if sock:
-                    response = sock.recv(1024)
-                else:
-                    response = file.read(1024)
-                if not response:
-                    break
-                if self.verbose:
-                    print("body:", repr(response))
-                p.feed(response)
-
-            file.close()
-            p.close()
-
-            return u.close()
-
-        def set_connection_token(self, token):
-            self.connection_token = token
-else:
-    class BBTransport(xmlrpclib.Transport):
-        def __init__(self):
-            self.connection_token = None
-            xmlrpclib.Transport.__init__(self)
-
-        def set_connection_token(self, token):
-            self.connection_token = token
-
-        def send_content(self, h, body):
-            if self.connection_token:
-                h.putheader("Bitbake-token", self.connection_token)
-            xmlrpclib.Transport.send_content(self, h, body)
-
-def _create_server(host, port):
-    t = BBTransport()
+def _create_server(host, port, timeout = 60):
+    t = BBTransport(timeout)
     s = xmlrpclib.Server("http://%s:%d/" % (host, port), transport=t, allow_none=True)
     return s, t
 
@@ -161,7 +95,8 @@ class BitBakeServerCommands():
         """
         s, t = _create_server(host, port)
 
-        return bb.event.register_UIHhandler(s)
+        self.event_handle = bb.event.register_UIHhandler(s)
+        return self.event_handle
 
     def unregisterEventHandler(self, handlerNum):
         """
@@ -173,7 +108,10 @@ class BitBakeServerCommands():
         """
         Run a cooker command on the server
         """
-        return self.cooker.command.runCommand(command)
+        return self.cooker.command.runCommand(command, self.server.readonly)
+
+    def getEventHandle(self):
+        return self.event_handle
 
     def terminateServer(self):
         """
@@ -195,6 +133,8 @@ class BitBakeServerCommands():
         if self.has_client:
             self.server.set_connection_token(None)
             self.has_client = False
+            if self.server.single_use:
+                self.server.quit = True
 
 # This request handler checks if the request has a "Bitbake-token" header
 # field (this comes from the client side) and compares it with its internal
@@ -204,7 +144,7 @@ class BitBakeServerCommands():
 # ("service unavailable") is returned to the client.
 class BitBakeXMLRPCRequestHandler(SimpleXMLRPCRequestHandler):
     def __init__(self, request, client_address, server):
-        self.connection_token = server.connection_token
+        self.server = server
         SimpleXMLRPCRequestHandler.__init__(self, request, client_address, server)
 
     def do_POST(self):
@@ -212,9 +152,13 @@ class BitBakeXMLRPCRequestHandler(SimpleXMLRPCRequestHandler):
             remote_token = self.headers["Bitbake-token"]
         except:
             remote_token = None
-        if remote_token != self.connection_token:
+        if remote_token != self.server.connection_token and remote_token != "observer":
             self.report_503()
         else:
+            if remote_token == "observer":
+                self.server.readonly = True
+            else:
+                self.server.readonly = False
             SimpleXMLRPCRequestHandler.do_POST(self)
 
     def report_503(self):
@@ -225,7 +169,6 @@ class BitBakeXMLRPCRequestHandler(SimpleXMLRPCRequestHandler):
         self.end_headers()
         self.wfile.write(response)
 
-
 class BitBakeUIEventServer(threading.Thread):
     class EventAdapter():
         """
@@ -271,59 +214,16 @@ class BitBakeUIEventServer(threading.Thread):
             if evt:
                 self.connection.event.sendpickle(pickle.dumps(evt))
 
-class BitBakeXMLRPCEventServerController(SimpleXMLRPCServer):
-    def __init__(self, interface):
-        SimpleXMLRPCServer.__init__(self, interface, logRequests=False, allow_none=True)
-        self.register_function(self.registerEventHandler, "registerEventHandler")
-        self.register_function(self.unregisterEventHandler, "unregisterEventHandler")
-        self.register_function(self.terminateServer, "terminateServer")
-        #self.register_function(self.runCommand, "runCommand")
-        self.quit = False
-        self.clients = {}
-        self.client_ui_ids = {}
 
-    def registerEventHandler(self, host, port):
-        """
-        Register a remote UI Event Handler
-        """
-        print "registering handler %s:%s" % (host,port) 
-        connection = xmlrpclib.ServerProxy("http://%s:%d/" % (host, port), allow_none=True)
-        client_hash = "%s:%d" % (host, port)
-        if self.clients.has_key(client_hash):
-            return None
-        client_ui_server = BitBakeUIEventServer(connection)
-        self.client_ui_ids[client_hash] = bb.event.register_UIHhandler(client_ui_server)
-        client_ui_server.start()
-        self.clients[client_hash] = client_ui_server
-        return client_hash
+class XMLRPCProxyServer(BaseImplServer):
+    """ not a real working server, but a stub for a proxy server connection
 
-    def unregisterEventHandler(self, client_hash):
-        """
-        Unregister a remote UI Event Handler
-        """
-        print "unregistering handler %s:%s" % (host,port)
-        client_thread = self.clients[client_hash]
-        if client_thread:
-            bb.event.unregister_UIHhandler(self.clients_ui_ids[client_hash])
-            client_thread.terminateServer()
-            client_thread.join()
-            return True
-        else:
-            return False
+    """
+    def __init__(self, host, port):
+        self.host = host
+        self.port = port
 
-    def terminateServer(self):
-        self.quit = True
-
-    def runCommand(self, cmd):
-        return None
-
-    def serve_forever(self, main_server):
-        self.main_server = main_server
-        while not self.quit:
-            self.handle_request()
-        self.server_close()
-
-class BitBakeXMLRPCServer(SimpleXMLRPCServer):
+class XMLRPCServer(SimpleXMLRPCServer, BaseImplServer):
     # remove this when you're done with debugging
     # allow_reuse_address = True
 
@@ -331,19 +231,22 @@ class BitBakeXMLRPCServer(SimpleXMLRPCServer):
         """
         Constructor
         """
+        BaseImplServer.__init__(self)
         SimpleXMLRPCServer.__init__(self, interface,
                                     requestHandler=BitBakeXMLRPCRequestHandler,
                                     logRequests=False, allow_none=True)
-        self._idlefuns = {}
         self.host, self.port = self.socket.getsockname()
         self.connection_token = None
         #self.register_introspection_functions()
         self.commands = BitBakeServerCommands(self)
         self.autoregister_all_functions(self.commands, "")
         self.interface = interface
+        self.single_use = False
+        if (interface[1] == 0):     # anonymous port, not getting reused
+            self.single_use = True
 
     def addcooker(self, cooker):
-        self.cooker = cooker
+        BaseImplServer.addcooker(self, cooker)
         self.commands.cooker = cooker
 
     def autoregister_all_functions(self, context, prefix):
@@ -356,33 +259,19 @@ class BitBakeXMLRPCServer(SimpleXMLRPCServer):
             if name.startswith(prefix):
                 self.register_function(method, name[len(prefix):])
 
-    def register_idle_function(self, function, data):
-        """Register a function to be called while the server is idle"""
-        assert hasattr(function, '__call__')
-        self._idlefuns[function] = data
 
     def serve_forever(self):
-        # Create and run the event server controller in a separate thread
-        evt_server_ctrl = BitBakeXMLRPCEventServerController((self.host, self.port + 2))
-        self.event_controller_thread = threading.Thread(target = evt_server_ctrl.serve_forever, args = (self,))
-        self.event_controller_thread.start()
         # Start the actual XMLRPC server
         bb.cooker.server_main(self.cooker, self._serve_forever)
 
-    def removeClient(self):
-        self.commands.removeClient()
-
     def _serve_forever(self):
         """
         Serve Requests. Overloaded to honor a quit command
         """
         self.quit = False
-        self.timeout = 0 # Run Idle calls for our first callback
         while not self.quit:
-            #print "Idle queue length %s" % len(self._idlefuns)
-            self.handle_request()
-            #print "Idle timeout, running idle functions"
-            nextsleep = None
+            fds = [self]
+            nextsleep = 0.1
             for function, data in self._idlefuns.items():
                 try:
                     retval = function(self, data, False)
@@ -390,49 +279,46 @@ class BitBakeXMLRPCServer(SimpleXMLRPCServer):
                         del self._idlefuns[function]
                     elif retval is True:
                         nextsleep = 0
-                    elif nextsleep is 0:
-                        continue
-                    elif nextsleep is None:
-                        nextsleep = retval
-                    elif retval < nextsleep:
-                        nextsleep = retval
+                    else:
+                        fds = fds + retval
                 except SystemExit:
                     raise
                 except:
                     import traceback
                     traceback.print_exc()
                     pass
-            if nextsleep is None and len(self._idlefuns) > 0:
-                nextsleep = 0
-            self.timeout = nextsleep
+
+            socktimeout = self.socket.gettimeout() or nextsleep
+            socktimeout = min(socktimeout, nextsleep)
+            # Mirror what BaseServer handle_request would do
+            fd_sets = select.select(fds, [], [], socktimeout)
+            if fd_sets[0] and self in fd_sets[0]:
+                self._handle_request_noblock()
+
         # Tell idle functions we're exiting
         for function, data in self._idlefuns.items():
             try:
                 retval = function(self, data, True)
             except:
                 pass
-        # Terminate the event server
-        self.event_controller_thread.terminateServer()
-        self.event_controller_thread.join()
         self.server_close()
         return
 
     def set_connection_token(self, token):
         self.connection_token = token
 
-class BitbakeServerInfo():
-    def __init__(self, host, port):
-        self.host = host
-        self.port = port
-
-class BitBakeServerConnection():
-    def __init__(self, serverinfo, clientinfo=("localhost", 0)):
-        self.connection, self.transport = _create_server(serverinfo.host, serverinfo.port)
+class BitBakeXMLRPCServerConnection(BitBakeBaseServerConnection):
+    def __init__(self, serverImpl, clientinfo=("localhost", 0), observer_only = False):
+        self.connection, self.transport = _create_server(serverImpl.host, serverImpl.port)
         self.clientinfo = clientinfo
-        self.serverinfo = serverinfo
+        self.serverImpl = serverImpl
+        self.observer_only = observer_only
 
     def connect(self):
-        token = self.connection.addClient()
+        if not self.observer_only:
+            token = self.connection.addClient()
+        else:
+            token = "observer"
         if token is None:
             return None
         self.transport.set_connection_token(token)
@@ -442,7 +328,8 @@ class BitBakeServerConnection():
         return self
 
     def removeClient(self):
-        self.connection.removeClient()
+        if not self.observer_only:
+            self.connection.removeClient()
 
     def terminate(self):
         # Don't wait for server indefinitely
@@ -453,42 +340,29 @@ class BitBakeServerConnection():
         except:
             pass
         try:
-            self.connection.terminateServer()
+            self.connection.removeClient()
         except:
             pass
 
-class BitBakeServer(object):
+class BitBakeServer(BitBakeBaseServer):
     def initServer(self, interface = ("localhost", 0)):
-        self.server = BitBakeXMLRPCServer(interface)
-
-    def addcooker(self, cooker):
-        self.cooker = cooker
-        self.server.addcooker(cooker)
-
-    def getServerIdleCB(self):
-        return self.server.register_idle_function
-
-    def saveConnectionDetails(self):
-        self.serverinfo = BitbakeServerInfo(self.server.host, self.server.port)
+        self.serverImpl = XMLRPCServer(interface)
 
     def detach(self):
-        daemonize.createDaemon(self.server.serve_forever, "bitbake-cookerdaemon.log")
+        daemonize.createDaemon(self.serverImpl.serve_forever, "bitbake-cookerdaemon.log")
         del self.cooker
-        del self.server
 
     def establishConnection(self):
-        self.connection = BitBakeServerConnection(self.serverinfo)
+        self.connection = BitBakeXMLRPCServerConnection(self.serverImpl)
         return self.connection.connect()
 
     def set_connection_token(self, token):
         self.connection.transport.set_connection_token(token)
 
-    def endSession(self):
-        self.connection.terminate()
+class BitBakeXMLRPCClient(BitBakeBaseServer):
 
-class BitBakeXMLRPCClient(object):
-
-    def __init__(self):
+    def __init__(self, observer_only = False):
+        self.observer_only = observer_only
         pass
 
     def saveConnectionDetails(self, remote):
@@ -510,8 +384,8 @@ class BitBakeXMLRPCClient(object):
             s.close()
         except:
             return None
-        self.serverinfo = BitbakeServerInfo(host, port)
-        self.connection = BitBakeServerConnection(self.serverinfo, (ip, 0))
+        self.serverImpl = XMLRPCProxyServer(host, port)
+        self.connection = BitBakeXMLRPCServerConnection(self.serverImpl, (ip, 0), self.observer_only)
         return self.connection.connect()
 
     def endSession(self):

bitbake/lib/bb/siggen.py

@@ -201,9 +201,10 @@ class SignatureGeneratorBasic(SignatureGenerator):
         #d.setVar("BB_TASKHASH_task-%s" % task, taskhash[task])
         return h
 
-    def set_taskdata(self, hashes, deps):
+    def set_taskdata(self, hashes, deps, checksums):
         self.runtaskdeps = deps
         self.taskhash = hashes
+        self.file_checksum_values = checksums
 
     def dump_sigtask(self, fn, task, stampbase, runtime):
         k = fn + "." + task

bitbake/lib/bb/taskdata.py

@@ -390,6 +390,17 @@ class TaskData:
                     reasons.append("%s PROVIDES %s but was skipped: %s" % (skipitem.pn, item, skipitem.skipreason))
         return reasons
 
+    def get_close_matches(self, item, provider_list):
+        import difflib
+        if self.skiplist:
+            skipped = []
+            for fn in self.skiplist:
+                skipped.append(self.skiplist[fn].pn)
+            full_list = provider_list + skipped
+        else:
+            full_list = provider_list
+        return difflib.get_close_matches(item, full_list, cutoff=0.7)
+
     def add_provider(self, cfgData, dataCache, item):
         try:
             self.add_provider_internal(cfgData, dataCache, item)
@@ -411,7 +422,7 @@ class TaskData:
             return
 
         if not item in dataCache.providers:
-            bb.event.fire(bb.event.NoProvider(item, dependees=self.get_dependees_str(item), reasons=self.get_reasons(item)), cfgData)
+            bb.event.fire(bb.event.NoProvider(item, dependees=self.get_dependees_str(item), reasons=self.get_reasons(item), close_matches=self.get_close_matches(item, dataCache.providers.keys())), cfgData)
             raise bb.providers.NoProvider(item)
 
         if self.have_build_target(item):

bitbake/lib/bb/tinfoil.py

@@ -49,7 +49,7 @@ class Tinfoil:
         self.config.setConfigParameters(configparams)
         self.config.setServerRegIdleCallback(self.register_idle_function)
         self.cooker = BBCooker(self.config)
-        self.config_data = self.cooker.configuration.data
+        self.config_data = self.cooker.data
         bb.providers.logger.setLevel(logging.ERROR)
         self.cooker_data = None
 

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

@@ -30,7 +30,7 @@ import shlex
 import re
 import logging
 import sys
-from bb.ui.crumbs.template import TemplateMgr
+import signal
 from bb.ui.crumbs.imageconfigurationpage import ImageConfigurationPage
 from bb.ui.crumbs.recipeselectionpage import RecipeSelectionPage
 from bb.ui.crumbs.packageselectionpage import PackageSelectionPage
@@ -192,36 +192,7 @@ class Configuration:
         self.split_proxy("socks", params["socks_proxy"])
         self.split_proxy("cvs", params["cvs_proxy_host"] + ":" + params["cvs_proxy_port"])
 
-    def load(self, template):
-        try:
-            self.image_rootfs_size = int(template.getVar("IMAGE_ROOTFS_SIZE"))
-        except:
-            pass
-        try:
-            self.image_extra_size = int(template.getVar("IMAGE_EXTRA_SPACE"))
-        except:
-            pass
-        # image_overhead_factor is read-only.
-        self.incompat_license = template.getVar("INCOMPATIBLE_LICENSE")
-        self.curr_sdk_machine = template.getVar("SDKMACHINE")
-        self.extra_setting = eval(template.getVar("EXTRA_SETTING"))
-        self.toolchain_build = eval(template.getVar("TOOLCHAIN_BUILD"))
-        self.image_fstypes = template.getVar("IMAGE_FSTYPES")
-        # image/recipes/packages
-        self.selected_image = template.getVar("__SELECTED_IMAGE__")
-        self.selected_recipes = template.getVar("DEPENDS").split()
-        self.selected_packages = template.getVar("IMAGE_INSTALL").split()
-        # proxy
-        self.enable_proxy = eval(template.getVar("enable_proxy"))
-        self.same_proxy = eval(template.getVar("use_same_proxy"))
-        self.split_proxy("http", template.getVar("http_proxy"))
-        self.split_proxy("https", template.getVar("https_proxy"))
-        self.split_proxy("ftp", template.getVar("ftp_proxy"))
-        self.split_proxy("socks", template.getVar("all_proxy"))
-        self.split_proxy("cvs", template.getVar("CVS_PROXY_HOST") + ":" + template.getVar("CVS_PROXY_PORT"))
-
-    def save(self, handler, template, defaults=False):
-        template.setVar("VERSION", "%s" % hobVer)
+    def save(self, handler, defaults=False):
         # bblayers.conf
         handler.set_var_in_file("BBLAYERS", self.layers, "bblayers.conf")
         # local.conf
@@ -240,29 +211,29 @@ class Configuration:
         handler.set_var_in_file("PARALLEL_MAKE", "-j %s" % self.pmake, "local.conf")
         handler.set_var_in_file("BB_NUMBER_THREADS", self.bbthread, "local.conf")
         handler.set_var_in_file("PACKAGE_CLASSES", " ".join(["package_" + i for i in self.curr_package_format.split()]), "local.conf")
-        template.setVar("IMAGE_ROOTFS_SIZE", self.image_rootfs_size)
-        template.setVar("IMAGE_EXTRA_SPACE", self.image_extra_size)
-        template.setVar("INCOMPATIBLE_LICENSE", self.incompat_license)
-        template.setVar("SDKMACHINE", self.curr_sdk_machine)
+        handler.set_var_in_file("IMAGE_ROOTFS_SIZE", self.image_rootfs_size, "local.conf")
+        handler.set_var_in_file("IMAGE_EXTRA_SPACE", self.image_extra_size, "local.conf")
+        handler.set_var_in_file("INCOMPATIBLE_LICENSE", self.incompat_license, "local.conf")
+        handler.set_var_in_file("SDKMACHINE", self.curr_sdk_machine, "local.conf")
         handler.set_var_in_file("CONF_VERSION", self.conf_version, "local.conf")
         handler.set_var_in_file("LCONF_VERSION", self.lconf_version, "bblayers.conf")
-        template.setVar("EXTRA_SETTING", self.extra_setting)
-        template.setVar("TOOLCHAIN_BUILD", self.toolchain_build)
-        template.setVar("IMAGE_FSTYPES", self.image_fstypes)
+        handler.set_var_in_file("EXTRA_SETTING", self.extra_setting, "local.conf")
+        handler.set_var_in_file("TOOLCHAIN_BUILD", self.toolchain_build, "local.conf")
+        handler.set_var_in_file("IMAGE_FSTYPES", self.image_fstypes, "local.conf")
         if not defaults:
             # image/recipes/packages
-            template.setVar("__SELECTED_IMAGE__", self.selected_image)
-            template.setVar("DEPENDS", self.selected_recipes)
-            template.setVar("IMAGE_INSTALL", self.user_selected_packages)
+            handler.set_var_in_file("__SELECTED_IMAGE__", self.selected_image, "local.conf")
+            handler.set_var_in_file("DEPENDS", self.selected_recipes, "local.conf")
+            handler.set_var_in_file("IMAGE_INSTALL", self.user_selected_packages, "local.conf")
         # proxy
-        template.setVar("enable_proxy", self.enable_proxy)
-        template.setVar("use_same_proxy", self.same_proxy)
-        template.setVar("http_proxy", self.combine_proxy("http"))
-        template.setVar("https_proxy", self.combine_proxy("https"))
-        template.setVar("ftp_proxy", self.combine_proxy("ftp"))
-        template.setVar("all_proxy", self.combine_proxy("socks"))
-        template.setVar("CVS_PROXY_HOST", self.combine_host_only("cvs"))
-        template.setVar("CVS_PROXY_PORT", self.combine_port_only("cvs"))
+        handler.set_var_in_file("enable_proxy", self.enable_proxy, "local.conf")
+        handler.set_var_in_file("use_same_proxy", self.same_proxy, "local.conf")
+        handler.set_var_in_file("http_proxy", self.combine_proxy("http"), "local.conf")
+        handler.set_var_in_file("https_proxy", self.combine_proxy("https"), "local.conf")
+        handler.set_var_in_file("ftp_proxy", self.combine_proxy("ftp"), "local.conf")
+        handler.set_var_in_file("all_proxy", self.combine_proxy("socks"), "local.conf")
+        handler.set_var_in_file("CVS_PROXY_HOST", self.combine_host_only("cvs"), "local.conf")
+        handler.set_var_in_file("CVS_PROXY_PORT", self.combine_port_only("cvs"), "local.conf")
 
     def __str__(self):
         s = "VERSION: '%s', BBLAYERS: '%s', MACHINE: '%s', DISTRO: '%s', DL_DIR: '%s'," % \
@@ -407,8 +378,6 @@ class Builder(gtk.Window):
         # handler
         self.handler = hobHandler
 
-        self.template = None
-
         # logger
         self.logger = logging.getLogger("BitBake")
         self.consolelog = None
@@ -471,8 +440,11 @@ class Builder(gtk.Window):
         self.handler.connect("recipe-populated",         self.handler_recipe_populated_cb)
         self.handler.connect("package-populated",        self.handler_package_populated_cb)
 
+        self.handler.append_to_bbfiles("${TOPDIR}/recipes/images/*.bb")
         self.initiate_new_build_async()
 
+        signal.signal(signal.SIGINT, self.event_handle_SIGINT)
+
     def create_visual_elements(self):
         self.set_title("Hob")
         self.set_icon_name("applications-development")
@@ -548,11 +520,11 @@ class Builder(gtk.Window):
         self.handler.generate_configuration()
 
     def initiate_new_build_async(self):
+        self.configuration.selected_image = None
         self.switch_page(self.MACHINE_SELECTION)
         self.handler.init_cooker()
         self.handler.set_extra_inherit("image_types")
         self.generate_configuration()
-        self.load_template(TemplateMgr.convert_to_template_pathfilename("default", ".hob/"))
 
     def update_config_async(self):
         self.switch_page(self.MACHINE_SELECTION)
@@ -623,6 +595,16 @@ class Builder(gtk.Window):
                                     toolchain_packages,
                                     self.configuration.default_task)
 
+    def generate_new_image(self, image, description):
+        base_image = self.configuration.initial_selected_image
+        if base_image == self.recipe_model.__custom_image__:
+            base_image = None
+        packages = self.package_model.get_selected_packages()
+        self.handler.generate_new_image(image, base_image, packages, description)
+
+    def ensure_dir(self, directory):
+        self.handler.ensure_dir(directory)
+
     def get_parameters_sync(self):
         return self.handler.get_parameters()
 
@@ -635,61 +617,6 @@ class Builder(gtk.Window):
     def cancel_parse_sync(self):
         self.handler.cancel_parse()
 
-    def load_template(self, path):
-        if not os.path.isfile(path):
-            return False
-
-        self.template = TemplateMgr()
-        # check compatibility
-        tempVer = self.template.getVersion(path)
-        if not tempVer or int(tempVer) < hobVer:
-            self.template.destroy()
-            self.template = None
-            return False
-
-        try:
-            self.template.load(path)
-            self.configuration.load(self.template)
-        except Exception as e:
-            self.show_error_dialog("Hob Exception - %s" % (str(e)))
-            self.reset()
-        finally:
-            self.template.destroy()
-            self.template = None
-
-        for layer in self.configuration.layers:
-            if not os.path.exists(layer+'/conf/layer.conf'):
-                return False
-
-        self.set_user_config_extra()
-        return True
-
-    def save_template(self, path, defaults=False):
-        if path.rfind("/") == -1:
-            filename = "default"
-            path = "."
-        else:
-            filename = path[path.rfind("/") + 1:len(path)]
-            path = path[0:path.rfind("/")]
-
-        self.template = TemplateMgr()
-        try:
-            self.template.open(filename, path)
-            self.configuration.save(self.handler, self.template, defaults)
-
-            self.template.save()
-        except Exception as e:
-            self.show_error_dialog("Hob Exception - %s" % (str(e)))
-            self.reset()
-        finally:
-            self.template.destroy()
-            self.template = None
-
-    def save_defaults(self):
-        if not os.path.exists(".hob/"):
-            os.mkdir(".hob/")
-        self.save_template(".hob/default", True)
-
     def switch_page(self, next_step):
         # Main Workflow (Business Logic)
         self.nb.set_current_page(self.__step2page__[next_step])
@@ -772,12 +699,11 @@ class Builder(gtk.Window):
         self.handler.set_sdk_machine(self.configuration.curr_sdk_machine)
         self.handler.set_image_fstypes(self.configuration.image_fstypes)
         self.handler.set_extra_config(self.configuration.extra_setting)
-        self.handler.set_extra_inherit("packageinfo")
-        self.handler.set_extra_inherit("image_types")
+        self.handler.set_extra_inherit("packageinfo image_types")
         self.set_user_config_proxies()
 
     def set_user_config(self):
-        self.handler.init_cooker()
+        self.handler.reset_cooker()
         # set bb layers
         self.handler.set_bblayers(self.configuration.layers)
         # set local configuration
@@ -1164,6 +1090,12 @@ class Builder(gtk.Window):
         else:
             gtk.main_quit()
 
+    def event_handle_SIGINT(self, signal, frame):
+        for w in gtk.window_list_toplevels():
+            if w.get_modal():
+                w.response(gtk.RESPONSE_DELETE_EVENT)
+        sys.exit(0)
+
     def build_packages(self):
         _, all_recipes = self.recipe_model.get_selected_recipes()
         if not all_recipes:
@@ -1255,7 +1187,6 @@ class Builder(gtk.Window):
         response = dialog.run()
         if response == gtk.RESPONSE_YES:
             self.configuration.layers = dialog.layers
-            self.save_defaults() # remember layers
             # DO refresh layers
             if dialog.layers_changed:
                 self.update_config_async()
@@ -1319,7 +1250,7 @@ class Builder(gtk.Window):
         settings_changed = False
         if response == gtk.RESPONSE_YES:
             self.configuration = dialog.configuration
-            self.save_defaults() # remember settings
+            self.configuration.save(self.handler, True) # remember settings
             settings_changed = dialog.settings_changed
         dialog.destroy()
         return response == gtk.RESPONSE_YES, settings_changed
@@ -1347,7 +1278,7 @@ class Builder(gtk.Window):
         settings_changed = False
         if response == gtk.RESPONSE_YES:
             self.configuration = dialog.configuration
-            self.save_defaults() # remember settings
+            self.configuration.save(self.handler, True) # remember settings
             settings_changed = dialog.settings_changed
             if dialog.proxy_settings_changed:
                 self.set_user_config_proxies()
@@ -1532,3 +1463,6 @@ class Builder(gtk.Window):
             self.consolelog.setFormatter(format)
 
             self.logger.addHandler(self.consolelog)
+
+    def get_topdir(self):
+        return self.handler.get_topdir()

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

@@ -131,7 +131,7 @@ class AdvancedSettingsDialog (CrumbsDialog, SettingsUIHelper):
         self.rootfs_size_spinner = None
         self.extra_size_spinner = None
         self.gplv3_checkbox = None
-        self.toolchain_checkbox = None
+        self.sdk_checkbox = None
         self.image_types_checkbuttons = {}
 
         self.md5 = self.config_md5()
@@ -286,16 +286,17 @@ class AdvancedSettingsDialog (CrumbsDialog, SettingsUIHelper):
             self.gplv3_checkbox.set_active(False)
         advanced_vbox.pack_start(self.gplv3_checkbox, expand=False, fill=False)
 
-        advanced_vbox.pack_start(self.gen_label_widget('<span weight="bold">Toolchain</span>'), expand=False, fill=False)
+        advanced_vbox.pack_start(self.gen_label_widget('<span weight="bold">SDK</span>'), expand=False, fill=False)
         sub_hbox = gtk.HBox(False, 6)
         advanced_vbox.pack_start(sub_hbox, expand=False, fill=False)
-        self.toolchain_checkbox = gtk.CheckButton("Build toolchain")
-        self.toolchain_checkbox.set_tooltip_text("Check this box to build the related toolchain with your image")
-        self.toolchain_checkbox.set_active(self.configuration.toolchain_build)
-        sub_hbox.pack_start(self.toolchain_checkbox, expand=False, fill=False)
+        self.sdk_checkbox = gtk.CheckButton("Populate SDK")
+        tooltip = "Check this box to generate an SDK tarball that consists of the cross-toolchain and a sysroot that contains development packages for your image."
+        self.sdk_checkbox.set_tooltip_text(tooltip)
+        self.sdk_checkbox.set_active(self.configuration.toolchain_build)
+        sub_hbox.pack_start(self.sdk_checkbox, expand=False, fill=False)
 
-        tooltip = "Selects the host platform for which you want to run the toolchain"
-        sdk_machine_widget, self.sdk_machine_combo = self.gen_combo_widget(self.configuration.curr_sdk_machine, self.all_sdk_machines,"<b>Build toolchain</b>" + "*" + tooltip)
+        tooltip = "Select the host platform for which you want to run the toolchain contained in the SDK tarball."
+        sdk_machine_widget, self.sdk_machine_combo = self.gen_combo_widget(self.configuration.curr_sdk_machine, self.all_sdk_machines,"<b>Populate SDK</b>" + "*" + tooltip)
         sub_hbox.pack_start(sdk_machine_widget, expand=False, fill=False)
 
         return advanced_vbox
@@ -330,7 +331,7 @@ class AdvancedSettingsDialog (CrumbsDialog, SettingsUIHelper):
                 self.configuration.incompat_license = " ".join(self.configuration.incompat_license or [])
         self.configuration.incompat_license = self.configuration.incompat_license.strip()
 
-        self.configuration.toolchain_build = self.toolchain_checkbox.get_active()
+        self.configuration.toolchain_build = self.sdk_checkbox.get_active()
         self.configuration.curr_sdk_machine = self.sdk_machine_combo.get_active_text()
         md5 = self.config_md5()
         self.settings_changed = (self.md5 != md5)

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

@@ -275,24 +275,23 @@ class PropertyDialog(CrumbsDialog):
                 binb_items_count = len(binb.split(','))
                 binb_items = binb.split(',')
                                		
-		vbox = gtk.VBox(True,spacing = 0)
-                
+		vbox = gtk.VBox(False,spacing = 0)
+
                 ######################################## SUMMARY LABEL #########################################                	                
                 
                 if summary != '':                
                         self.label_short = gtk.Label()
-                        self.label_short.set_size_request(300,-1)
+                        self.label_short.set_width_chars(37)
                         self.label_short.set_selectable(True)                
                         self.label_short.set_line_wrap(True)
                         self.label_short.set_markup("<b>" + summary + "</b>")
                         self.label_short.set_property("xalign", 0)
                         
-                        self.vbox.pack_start(self.label_short, expand=False, fill=False, padding=0)
+                        self.vbox.add(self.label_short)
                 
                 ########################################## NAME ROW + COL #######################################
                                 
                 self.label_short = gtk.Label()
-                self.label_short.set_size_request(300,-1)
                 self.label_short.set_selectable(True)
                 self.label_short.set_line_wrap(True)
                 self.label_short.set_markup("<span weight=\"bold\">Name: </span>" + name)
@@ -303,7 +302,6 @@ class PropertyDialog(CrumbsDialog):
                 ####################################### VERSION ROW + COL ####################################
                 
                 self.label_short = gtk.Label()
-                self.label_short.set_size_request(300,-1)
                 self.label_short.set_selectable(True)
                 self.label_short.set_line_wrap(True)
                 self.label_short.set_markup("<span weight=\"bold\">Version: </span>" + version)
@@ -314,7 +312,6 @@ class PropertyDialog(CrumbsDialog):
                 ##################################### REVISION ROW + COL #####################################
 
                 self.label_short = gtk.Label()
-                self.label_short.set_size_request(300,-1)
                 self.label_short.set_line_wrap(True)
                 self.label_short.set_selectable(True)
                 self.label_short.set_markup("<span weight=\"bold\">Revision: </span>" + revision)
@@ -325,7 +322,6 @@ class PropertyDialog(CrumbsDialog):
                 ################################## GROUP ROW + COL ############################################
                
                 self.label_short = gtk.Label()
-                self.label_short.set_size_request(300,-1)  
                 self.label_short.set_selectable(True)              
                 self.label_short.set_line_wrap(True)                                
                 self.label_short.set_markup("<span weight=\"bold\">Group: </span>" + group)
@@ -347,7 +343,6 @@ class PropertyDialog(CrumbsDialog):
                         self.label_info.set_property("xalign", 0)
                        
                         self.label_short = gtk.Label()
-                        self.label_short.set_size_request(300,-1)   
                         self.label_short.set_selectable(True)                     
                         self.label_short.set_line_wrap(True)                        
                         self.label_short.set_markup("<b>Homepage: </b>")                      
@@ -369,7 +364,6 @@ class PropertyDialog(CrumbsDialog):
                         self.label_info.set_property("xalign", 0)  
 
                         self.label_short = gtk.Label()
-                        self.label_short.set_size_request(300,-1)    
                         self.label_short.set_selectable(True)                    
                         self.label_short.set_line_wrap(True)
                         self.label_short.set_markup("<b>Bugtracker: </b>")                   
@@ -381,7 +375,6 @@ class PropertyDialog(CrumbsDialog):
                 ################################# LICENSE ROW + COL ############################################
                 
                 self.label_info = gtk.Label()
-                self.label_info.set_size_request(300,-1)
                 self.label_info.set_selectable(True)
                 self.label_info.set_line_wrap(True)
                 self.label_info.set_markup(license)
@@ -404,16 +397,25 @@ class PropertyDialog(CrumbsDialog):
                         self.label_short.set_line_wrap(True)
                         self.label_short.set_markup("<span weight=\"bold\">Brought in by: </span>")
                         self.label_short.set_property("xalign", 0)
-
-                        self.label_info = gtk.Label()
-                        self.label_info.set_size_request(300,-1)
-                        self.label_info.set_selectable(True)
-                        self.label_info.set_markup(binb)
-                        self.label_info.set_property("xalign", 0)
-                        self.label_info.set_line_wrap(True)
-                        
                         self.vbox.add(self.label_short)
-                        self.vbox.add(self.label_info)
+                        self.label_info = gtk.Label()
+                        self.label_info.set_selectable(True)
+                        self.label_info.set_width_chars(36)
+                        if len(binb) > 200:
+                            scrolled_window = gtk.ScrolledWindow()
+                            scrolled_window.set_policy(gtk.POLICY_NEVER,gtk.POLICY_ALWAYS)
+                            scrolled_window.set_size_request(100,100)
+                            self.label_info.set_markup(binb)
+                            self.label_info.set_padding(6,6)
+                            self.label_info.set_alignment(0,0)
+                            self.label_info.set_line_wrap(True)
+                            scrolled_window.add_with_viewport(self.label_info)
+                            self.vbox.add(scrolled_window)
+                        else:
+                            self.label_info.set_markup(binb)
+                            self.label_info.set_property("xalign", 0)
+                            self.label_info.set_line_wrap(True) 
+                            self.vbox.add(self.label_info)
 
                 ################################ DESCRIPTION TAG ROW #################################################
                 
@@ -428,11 +430,22 @@ class PropertyDialog(CrumbsDialog):
                 hbox = gtk.HBox(True,spacing = 0)
 
                 self.label_short = gtk.Label()
-                self.label_short.set_size_request(300,-1)
-                self.label_short.set_selectable(True)                
-                self.label_short.set_text(description)
-                self.label_short.set_line_wrap(True)
-                self.label_short.set_property("xalign", 0)
-                self.vbox.add(self.label_short)
+                self.label_short.set_selectable(True)
+                self.label_short.set_width_chars(36)
+                if len(description) > 200:
+                    scrolled_window = gtk.ScrolledWindow()
+                    scrolled_window.set_policy(gtk.POLICY_NEVER,gtk.POLICY_ALWAYS)
+                    scrolled_window.set_size_request(100,100)
+                    self.label_short.set_markup(description)
+                    self.label_short.set_padding(6,6)
+                    self.label_short.set_alignment(0,0)
+                    self.label_short.set_line_wrap(True)
+                    scrolled_window.add_with_viewport(self.label_short)
+                    self.vbox.add(scrolled_window)
+                else:    
+                    self.label_short.set_markup(description)
+                    self.label_short.set_property("xalign", 0)
+                    self.label_short.set_line_wrap(True)
+                    self.vbox.add(self.label_short)
 
                 self.vbox.show_all()

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

@@ -0,0 +1,51 @@
+#
+# BitBake Graphical GTK User Interface
+#
+# Copyright (C) 2013   Intel Corporation
+#
+# Authored by Cristiana Voicu <cristiana.voicu@intel.com>
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License version 2 as
+# published by the Free Software Foundation.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License along
+# with this program; if not, write to the Free Software Foundation, Inc.,
+# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+
+import gtk
+
+class RetrieveImageDialog (gtk.FileChooserDialog):
+    """
+    This class is used to create a dialog that permits to retrieve
+    a custom image saved previously from Hob.
+    """
+    def __init__(self, directory,title, parent, flags, buttons=None):
+        super(RetrieveImageDialog, self).__init__(title, None, gtk.FILE_CHOOSER_ACTION_OPEN,
+            (gtk.STOCK_CANCEL, gtk.RESPONSE_CANCEL,gtk.STOCK_OPEN, gtk.RESPONSE_OK))
+        self.directory = directory
+
+        # create visual elements on the dialog
+        self.create_visual_elements()
+
+    def create_visual_elements(self):
+        self.set_show_hidden(True)
+        self.set_default_response(gtk.RESPONSE_OK)
+        self.set_current_folder(self.directory)
+
+        vbox = self.get_children()[0].get_children()[0].get_children()[0]
+        for child in vbox.get_children()[0].get_children()[0].get_children()[0].get_children():
+            vbox.get_children()[0].get_children()[0].get_children()[0].remove(child)
+
+        label1 = gtk.Label()
+        label1.set_text("File system" + self.directory)
+        label1.show()
+        vbox.get_children()[0].get_children()[0].get_children()[0].pack_start(label1, expand=False, fill=False, padding=0)
+        vbox.get_children()[0].get_children()[1].get_children()[0].hide()
+
+        self.get_children()[0].get_children()[1].get_children()[0].set_label("Select")

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

@@ -0,0 +1,160 @@
+#
+# BitBake Graphical GTK User Interface
+#
+# Copyright (C) 2013   Intel Corporation
+#
+# Authored by Cristiana Voicu <cristiana.voicu@intel.com>
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License version 2 as
+# published by the Free Software Foundation.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License along
+# with this program; if not, write to the Free Software Foundation, Inc.,
+# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+
+import gtk
+import glib
+from bb.ui.crumbs.hig.crumbsdialog import CrumbsDialog
+from bb.ui.crumbs.hig.crumbsmessagedialog import CrumbsMessageDialog
+from bb.ui.crumbs.hobwidget import HobButton
+
+class SaveImageDialog (CrumbsDialog):
+    """
+    This class is used to create a dialog that permits to save
+    a custom image in a predefined directory.
+    """
+    def __init__(self, directory, name, description, title, parent, flags, buttons=None):
+        super(SaveImageDialog, self).__init__(title, parent, flags, buttons)
+        self.directory = directory
+        self.builder = parent
+        self.name_field = name
+        self.description_field = description
+
+        # create visual elements on the dialog
+        self.create_visual_elements()
+
+    def create_visual_elements(self):
+        self.set_default_response(gtk.RESPONSE_OK)
+        self.vbox.set_border_width(6)
+
+        sub_vbox = gtk.VBox(False, 12)
+        self.vbox.pack_start(sub_vbox, expand=False, fill=False)
+        label = gtk.Label()
+        label.set_alignment(0, 0)
+        label.set_markup("<b>Name</b>")
+        sub_label = gtk.Label()
+        sub_label.set_alignment(0, 0)
+        content = "Image recipe names should be all lowercase and include only alphanumeric\n"
+        content += "characters. The only special character you can use is the ASCII hyphen (-)."
+        sub_label.set_markup(content)
+        self.name_entry = gtk.Entry()
+        self.name_entry.set_text(self.name_field)
+        self.name_entry.set_size_request(350,30)
+        self.name_entry.connect("changed", self.name_entry_changed)
+        sub_vbox.pack_start(label, expand=False, fill=False)
+        sub_vbox.pack_start(sub_label, expand=False, fill=False)
+        sub_vbox.pack_start(self.name_entry, expand=False, fill=False)
+
+        sub_vbox = gtk.VBox(False, 12)
+        self.vbox.pack_start(sub_vbox, expand=False, fill=False)
+        label = gtk.Label()
+        label.set_alignment(0, 0)
+        label.set_markup("<b>Description</b> (optional)")
+        sub_label = gtk.Label()
+        sub_label.set_alignment(0, 0)
+        sub_label.set_markup("The description should be less than 150 characters long.")
+        self.description_entry = gtk.TextView()
+        description_buffer = self.description_entry.get_buffer()
+        description_buffer.set_text(self.description_field)
+        description_buffer.connect("insert-text", self.limit_description_length)
+        self.description_entry.set_wrap_mode(gtk.WRAP_WORD)
+        self.description_entry.set_size_request(350,50)
+        sub_vbox.pack_start(label, expand=False, fill=False)
+        sub_vbox.pack_start(sub_label, expand=False, fill=False)
+        sub_vbox.pack_start(self.description_entry, expand=False, fill=False)
+
+        sub_vbox = gtk.VBox(False, 12)
+        self.vbox.pack_start(sub_vbox, expand=False, fill=False)
+        label = gtk.Label()
+        label.set_alignment(0, 0)
+        label.set_markup("Your image recipe will be saved to:")
+        sub_label = gtk.Label()
+        sub_label.set_alignment(0, 0)
+        sub_label.set_markup(self.directory)
+        sub_vbox.pack_start(label, expand=False, fill=False)
+        sub_vbox.pack_start(sub_label, expand=False, fill=False)
+
+        table = gtk.Table(1, 4, True)
+
+        cancel_button = gtk.Button()
+        cancel_button.set_label("Cancel")
+        cancel_button.connect("clicked", self.cancel_button_cb)
+        cancel_button.set_size_request(110, 30)
+
+        self.save_button = gtk.Button()
+        self.save_button.set_label("Save")
+        self.save_button.connect("clicked", self.save_button_cb)
+        self.save_button.set_size_request(110, 30)
+        if self.name_entry.get_text() == '':
+            self.save_button.set_sensitive(False)
+
+        table.attach(cancel_button, 2, 3, 0, 1)
+        table.attach(self.save_button, 3, 4, 0, 1)
+        self.vbox.pack_end(table, expand=False, fill=False)
+
+        self.show_all()
+
+    def limit_description_length(self, textbuffer, iter, text, length):
+        buffer_bounds = textbuffer.get_bounds()
+        entire_text = textbuffer.get_text(*buffer_bounds)
+        entire_text += text
+        if len(entire_text)>150 or text=="\n":
+            textbuffer.emit_stop_by_name("insert-text")
+
+    def name_entry_changed(self, entry):
+        text = entry.get_text()
+        if text == '':
+            self.save_button.set_sensitive(False)
+        else:
+            self.save_button.set_sensitive(True)
+
+    def cancel_button_cb(self, button):
+        self.destroy()
+
+    def save_button_cb(self, button):
+        text = self.name_entry.get_text()
+        new_text = text.replace("-","")
+        description_buffer = self.description_entry.get_buffer()
+        description = description_buffer.get_text(description_buffer.get_start_iter(),description_buffer.get_end_iter())
+        if new_text.islower() and new_text.isalnum():
+            self.builder.image_details_page.image_saved = True
+            self.builder.customized = False
+            self.builder.generate_new_image(self.directory+text, description)
+            self.builder.recipe_model.set_in_list(text, description)
+            self.builder.recipe_model.set_selected_image(text)
+            self.builder.image_details_page.show_page(self.builder.IMAGE_GENERATED)
+            self.builder.image_details_page.name_field_template = text
+            self.builder.image_details_page.description_field_template = description
+            self.destroy()
+        else:
+            self.show_invalid_input_error_dialog()
+
+    def show_invalid_input_error_dialog(self):
+        lbl = "<b>Invalid characters in image recipe name</b>\n"
+        msg = "Image recipe names should be all lowercase and\n"
+        msg += "include only alphanumeric characters. The only\n"
+        msg += "special character you can use is the ASCII hyphen (-)."
+        lbl = lbl + "\n%s\n" % glib.markup_escape_text(msg)
+        dialog = CrumbsMessageDialog(self, lbl, gtk.STOCK_DIALOG_ERROR)
+        button = dialog.add_button("Close", gtk.RESPONSE_OK)
+        HobButton.style_button(button)
+
+        res = dialog.run()
+        self.name_entry.grab_focus()
+        dialog.destroy()

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

@@ -310,7 +310,6 @@ class SimpleSettingsDialog (CrumbsDialog, SettingsUIHelper):
 
         sub_vbox = gtk.VBox(False)
         advanced_vbox.pack_start(sub_vbox, gtk.TRUE, gtk.TRUE, 0)
-        searched_string = "file://"
 
         if self.sstatemirrors_changed == 0:
             self.sstatemirrors_changed = 1
@@ -319,18 +318,12 @@ class SimpleSettingsDialog (CrumbsDialog, SettingsUIHelper):
                 sm_list = ["Standard", "", "file://(.*)"]
                 self.sstatemirrors_list.append(sm_list)
             else:
-                while sstatemirrors.find(searched_string) != -1:
-                    if sstatemirrors.find(searched_string,1) != -1:
-                        sstatemirror = sstatemirrors[:sstatemirrors.find(searched_string,1)]
-                        sstatemirrors = sstatemirrors[sstatemirrors.find(searched_string,1):]
-                    else:
-                        sstatemirror = sstatemirrors
-                        sstatemirrors = sstatemirrors[1:]
-
+                sstatemirrors = [x for x in sstatemirrors.split('\\n')]
+                for sstatemirror in sstatemirrors:
                     sstatemirror_fields = [x for x in sstatemirror.split(' ') if x.strip()]
-                    if len(sstatemirror_fields):
-                        if sstatemirror_fields[0] == "file://(.*)":
-                            sm_list = ["Standard", sstatemirror_fields[1], "file://(.*)"]
+                    if len(sstatemirror_fields) == 2:
+                        if sstatemirror_fields[0] == "file://(.*)" or sstatemirror_fields[0] == "file://.*":
+                            sm_list = ["Standard", sstatemirror_fields[1], sstatemirror_fields[0]]
                         else:
                             sm_list = ["Custom", sstatemirror_fields[1], sstatemirror_fields[0]]
                         self.sstatemirrors_list.append(sm_list)

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

@@ -147,7 +147,7 @@ class HobHandler(gobject.GObject):
             self.runCommand(["findFilesMatchingInDir", "rootfs_", "classes"])
         elif next_command == self.SUB_PARSE_CONFIG:
             self.runCommand(["enableDataTracking"])
-            self.runCommand(["parseConfigurationFiles", "", ""])
+            self.runCommand(["parseConfigurationFiles", "conf/.hob.conf", ""])
             self.runCommand(["disableDataTracking"])
         elif next_command == self.SUB_GNERATE_TGTS:
             self.runCommand(["generateTargetsTree", "classes/image.bbclass", []])
@@ -166,17 +166,15 @@ class HobHandler(gobject.GObject):
             self.clear_busy()
             self.building = True
             targets = [self.image]
-            if self.package_queue:
-                self.runCommand(["setVariable", "LINGUAS_INSTALL", ""])
-                self.runCommand(["setVariable", "PACKAGE_INSTALL", " ".join(self.package_queue)])
             if self.toolchain_packages:
-                self.runCommand(["setVariable", "TOOLCHAIN_TARGET_TASK", " ".join(self.toolchain_packages)])
+                self.set_var_in_file("TOOLCHAIN_TARGET_TASK", " ".join(self.toolchain_packages), "local.conf")
                 targets.append(self.toolchain)
             if targets[0] == "hob-image":
+                self.set_var_in_file("LINGUAS_INSTALL", "", "local.conf")
                 hobImage = self.runCommand(["matchFile", "hob-image.bb"])
-                if self.base_image != "Create your own image":
+                if self.base_image != "Start with an empty image recipe":
                     baseImage = self.runCommand(["matchFile", self.base_image + ".bb"])
-                    version = self.runCommand(["generateNewImage", hobImage, baseImage, self.package_queue])
+                    version = self.runCommand(["generateNewImage", hobImage, baseImage, self.package_queue, True, ""])
                     targets[0] += version
                     self.recipe_model.set_custom_image_version(version)
 
@@ -204,8 +202,8 @@ class HobHandler(gobject.GObject):
         elif isinstance(event, bb.event.SanityCheckPassed):
             reparse = self.runCommand(["getVariable", "BB_INVALIDCONF"]) or None
             if reparse is True:
-                self.runCommand(["setVariable", "BB_INVALIDCONF", False])
-                self.runCommand(["parseConfigurationFiles", "", ""])
+                self.set_var_in_file("BB_INVALIDCONF", False, "local.conf")
+                self.runCommand(["parseConfigurationFiles", "conf/.hob.conf", ""])
             self.run_next_command()
 
         elif isinstance(event, bb.event.SanityCheckFailed):
@@ -300,79 +298,85 @@ class HobHandler(gobject.GObject):
 
     def init_cooker(self):
         self.runCommand(["initCooker"])
+        self.runCommand(["createConfigFile", ".hob.conf"])
+
+    def reset_cooker(self):
+        self.runCommand(["enableDataTracking"])
+        self.runCommand(["resetCooker"])
+        self.runCommand(["disableDataTracking"])
 
     def set_extra_inherit(self, bbclass):
         inherits = self.runCommand(["getVariable", "INHERIT"]) or ""
         inherits = inherits + " " + bbclass
-        self.runCommand(["setVariable", "INHERIT", inherits])
+        self.set_var_in_file("INHERIT", inherits, ".hob.conf")
 
     def set_bblayers(self, bblayers):
-        self.runCommand(["setVariable", "BBLAYERS", " ".join(bblayers)])
+        self.set_var_in_file("BBLAYERS", " ".join(bblayers), "bblayers.conf")
 
     def set_machine(self, machine):
         if machine:
-            self.runCommand(["setVariable", "MACHINE", machine])
+            self.set_var_in_file("MACHINE", machine, "local.conf")
 
     def set_sdk_machine(self, sdk_machine):
-        self.runCommand(["setVariable", "SDKMACHINE", sdk_machine])
+        self.set_var_in_file("SDKMACHINE", sdk_machine, "local.conf")
 
     def set_image_fstypes(self, image_fstypes):
-        self.runCommand(["setVariable", "IMAGE_FSTYPES", image_fstypes])
+        self.set_var_in_file("IMAGE_FSTYPES", image_fstypes, "local.conf")
 
     def set_distro(self, distro):
-        self.runCommand(["setVariable", "DISTRO", distro])
+        self.set_var_in_file("DISTRO", distro, "local.conf")
 
     def set_package_format(self, format):
         package_classes = ""
         for pkgfmt in format.split():
             package_classes += ("package_%s" % pkgfmt + " ")
-        self.runCommand(["setVariable", "PACKAGE_CLASSES", package_classes])
+        self.set_var_in_file("PACKAGE_CLASSES", package_classes, "local.conf")
 
     def set_bbthreads(self, threads):
-        self.runCommand(["setVariable", "BB_NUMBER_THREADS", threads])
+        self.set_var_in_file("BB_NUMBER_THREADS", threads, "local.conf")
 
     def set_pmake(self, threads):
         pmake = "-j %s" % threads
-        self.runCommand(["setVariable", "PARALLEL_MAKE", pmake])
+        self.set_var_in_file("PARALLEL_MAKE", pmake, "local.conf")
 
     def set_dl_dir(self, directory):
-        self.runCommand(["setVariable", "DL_DIR", directory])
+        self.set_var_in_file("DL_DIR", directory, "local.conf")
 
     def set_sstate_dir(self, directory):
-        self.runCommand(["setVariable", "SSTATE_DIR", directory])
+        self.set_var_in_file("SSTATE_DIR", directory, "local.conf")
 
     def set_sstate_mirrors(self, url):
-        self.runCommand(["setVariable", "SSTATE_MIRRORS", url])
+        self.set_var_in_file("SSTATE_MIRRORS", url, "local.conf")
 
     def set_extra_size(self, image_extra_size):
-        self.runCommand(["setVariable", "IMAGE_ROOTFS_EXTRA_SPACE", str(image_extra_size)])
+        self.set_var_in_file("IMAGE_ROOTFS_EXTRA_SPACE", str(image_extra_size), "local.conf")
 
     def set_rootfs_size(self, image_rootfs_size):
-        self.runCommand(["setVariable", "IMAGE_ROOTFS_SIZE", str(image_rootfs_size)])
+        self.set_var_in_file("IMAGE_ROOTFS_SIZE", str(image_rootfs_size), "local.conf")
 
     def set_incompatible_license(self, incompat_license):
-        self.runCommand(["setVariable", "INCOMPATIBLE_LICENSE", incompat_license])
+        self.set_var_in_file("INCOMPATIBLE_LICENSE", incompat_license, "local.conf")
 
     def set_extra_config(self, extra_setting):
         for key in extra_setting.keys():
             value = extra_setting[key]
-            self.runCommand(["setVariable", key, value])
+            self.set_var_in_file(key, value, "local.conf")
 
     def set_http_proxy(self, http_proxy):
-        self.runCommand(["setVariable", "http_proxy", http_proxy])
+        self.set_var_in_file("http_proxy", http_proxy, "local.conf")
 
     def set_https_proxy(self, https_proxy):
-        self.runCommand(["setVariable", "https_proxy", https_proxy])
+        self.set_var_in_file("https_proxy", https_proxy, "local.conf")
 
     def set_ftp_proxy(self, ftp_proxy):
-        self.runCommand(["setVariable", "ftp_proxy", ftp_proxy])
+        self.set_var_in_file("ftp_proxy", ftp_proxy, "local.conf")
 
     def set_socks_proxy(self, socks_proxy):
-        self.runCommand(["setVariable", "all_proxy", socks_proxy])
+        self.set_var_in_file("all_proxy", socks_proxy, "local.conf")
 
     def set_cvs_proxy(self, host, port):
-        self.runCommand(["setVariable", "CVS_PROXY_HOST", host])
-        self.runCommand(["setVariable", "CVS_PROXY_PORT", port])
+        self.set_var_in_file("CVS_PROXY_HOST", host, "local.conf")
+        self.set_var_in_file("CVS_PROXY_PORT", port, "local.conf")
 
     def request_package_info(self):
         self.commands_async.append(self.SUB_GENERATE_PKGINFO)
@@ -420,6 +424,13 @@ class HobHandler(gobject.GObject):
         self.commands_async.append(self.SUB_BUILD_IMAGE)
         self.run_next_command(self.GENERATE_IMAGE)
 
+    def generate_new_image(self, image, base_image, package_queue, description):
+        base_image = self.runCommand(["matchFile", self.base_image + ".bb"])
+        self.runCommand(["generateNewImage", image, base_image, package_queue, False, description])
+
+    def ensure_dir(self, directory):
+        self.runCommand(["ensureDir", directory])
+
     def build_succeeded_async(self):
         self.building = False
 
@@ -446,6 +457,9 @@ class HobHandler(gobject.GObject):
     def get_logfile(self):
         return self.server.runCommand(["getVariable", "BB_CONSOLELOG"])[0]
 
+    def get_topdir(self):
+        return self.runCommand(["getVariable", "TOPDIR"]) or ""
+
     def _remove_redundant(self, string):
         ret = []
         for i in string.split():
@@ -454,7 +468,18 @@ class HobHandler(gobject.GObject):
         return " ".join(ret)
 
     def set_var_in_file(self, var, val, default_file=None):
-        self.server.runCommand(["setVarFile", var, val, default_file])
+        self.runCommand(["enableDataTracking"])
+        self.server.runCommand(["setVarFile", var, val, default_file, "set"])
+        self.runCommand(["disableDataTracking"])
+
+    def append_var_in_file(self, var, val, default_file=None):
+        self.server.runCommand(["setVarFile", var, val, default_file, "append"])
+
+    def append_to_bbfiles(self, val):
+        bbfiles = self.runCommand(["getVariable", "BBFILES", "False"]) or ""
+        bbfiles = bbfiles.split()
+        if val not in bbfiles:
+            self.append_var_in_file("BBFILES", val, "local.conf")
 
     def get_parameters(self):
         # retrieve the parameters from bitbake

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

@@ -474,9 +474,9 @@ class RecipeListModel(gtk.ListStore):
     provide filtered views of the data.
     """
     (COL_NAME, COL_DESC, COL_LIC, COL_GROUP, COL_DEPS, COL_BINB, COL_TYPE, COL_INC, COL_IMG, COL_INSTALL, COL_PN, COL_FADE_INC, COL_SUMMARY, COL_VERSION,
-     COL_REVISION, COL_HOMEPAGE, COL_BUGTRACKER) = range(17)
+     COL_REVISION, COL_HOMEPAGE, COL_BUGTRACKER, COL_FILE) = range(18)
 
-    __custom_image__ = "Create your own image"
+    __custom_image__ = "Start with an empty image recipe"
 
     __gsignals__ = {
         "recipe-selection-changed" : (gobject.SIGNAL_RUN_LAST,
@@ -504,6 +504,7 @@ class RecipeListModel(gtk.ListStore):
                                 gobject.TYPE_STRING,
                                 gobject.TYPE_STRING,
                                 gobject.TYPE_STRING,
+                                gobject.TYPE_STRING,
                                 gobject.TYPE_STRING)
         self.sort_column_id, self.sort_order = RecipeListModel.COL_NAME, gtk.SORT_ASCENDING
 
@@ -678,15 +679,8 @@ class RecipeListModel(gtk.ListStore):
         self.clear()
 
         # dummy image for prompt
-        self.set(self.append(), self.COL_NAME, self.__custom_image__,
-                 self.COL_DESC, "Use 'Edit image' to customize recipes and packages " \
-                                "to be included in your image ",
-                 self.COL_LIC, "", self.COL_GROUP, "",
-                 self.COL_DEPS, "", self.COL_BINB, "",
-                 self.COL_TYPE, "image", self.COL_INC, False,
-                 self.COL_IMG, False, self.COL_INSTALL, "", self.COL_PN, self.__custom_image__,
-                 self.COL_SUMMARY, "", self.COL_VERSION, "", self.COL_REVISION, "",
-                 self.COL_HOMEPAGE, "", self.COL_BUGTRACKER, "")
+        self.set_in_list(self.__custom_image__,  "Use 'Edit image recipe' to customize recipes and packages " \
+                                "to be included in your image ")
 
         for item in event_model["pn"]:
             name = item
@@ -699,6 +693,7 @@ class RecipeListModel(gtk.ListStore):
             revision = event_model["pn"][item]["revision"]
             homepage = event_model["pn"][item]["homepage"]
             bugtracker = event_model["pn"][item]["bugtracker"]
+            filename = event_model["pn"][item]["filename"]
             install = []
 
             depends = event_model["depends"].get(item, []) + event_model["rdepends-pn"].get(item, [])
@@ -722,7 +717,8 @@ class RecipeListModel(gtk.ListStore):
                      self.COL_TYPE, atype, self.COL_INC, False,
                      self.COL_IMG, False, self.COL_INSTALL, " ".join(install), self.COL_PN, item,
                      self.COL_SUMMARY, summary, self.COL_VERSION, version, self.COL_REVISION, revision,
-                     self.COL_HOMEPAGE, homepage, self.COL_BUGTRACKER, bugtracker)
+                     self.COL_HOMEPAGE, homepage, self.COL_BUGTRACKER, bugtracker,
+                     self.COL_FILE, filename)
 
         self.pn_path = {}
         it = self.get_iter_first()
@@ -732,6 +728,23 @@ class RecipeListModel(gtk.ListStore):
             self.pn_path[pn] = path
             it = self.iter_next(it)
 
+    def set_in_list(self, item, desc):
+        self.set(self.append(), self.COL_NAME, item,
+                 self.COL_DESC, desc,
+                 self.COL_LIC, "", self.COL_GROUP, "",
+                 self.COL_DEPS, "", self.COL_BINB, "",
+                 self.COL_TYPE, "image", self.COL_INC, False,
+                 self.COL_IMG, False, self.COL_INSTALL, "", self.COL_PN, item,
+                 self.COL_SUMMARY, "", self.COL_VERSION, "", self.COL_REVISION, "",
+                 self.COL_HOMEPAGE, "", self.COL_BUGTRACKER, "")
+        self.pn_path = {}
+        it = self.get_iter_first()
+        while it:
+            pn = self.get_value(it, self.COL_NAME)
+            path = self.get_path(it)
+            self.pn_path[pn] = path
+            it = self.iter_next(it)
+
     """
     Update the model, send out the notification.
     """
@@ -882,3 +895,6 @@ class RecipeListModel(gtk.ListStore):
 
     def get_custom_image_version(self):
         return self.custom_image_version
+
+    def is_custom_image(self):
+        return self.get_selected_image() == self.__custom_image__

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

@@ -28,6 +28,7 @@ from bb.ui.crumbs.hobcolor import HobColors
 from bb.ui.crumbs.hobwidget import hic, HobImageButton, HobInfoButton, HobAltButton, HobButton
 from bb.ui.crumbs.hoblistmodel import RecipeListModel
 from bb.ui.crumbs.hobpages import HobPage
+from bb.ui.crumbs.hig.retrieveimagedialog import RetrieveImageDialog
 
 #
 # ImageConfigurationPage
@@ -35,7 +36,8 @@ from bb.ui.crumbs.hobpages import HobPage
 class ImageConfigurationPage (HobPage):
 
     __dummy_machine__ = "--select a machine--"
-    __dummy_image__   = "--select a base image--"
+    __dummy_image__   = "--select an image recipe--"
+    __custom_image__  = "Select from my image recipes"
 
     def __init__(self, builder):
         super(ImageConfigurationPage, self).__init__(builder, "Image configuration")
@@ -47,6 +49,7 @@ class ImageConfigurationPage (HobPage):
         self.machine_combo_changed_by_manual = True
         self.stopping = False
         self.warning_shift = 0
+        self.custom_image_selected = None
         self.create_visual_elements()
 
     def create_visual_elements(self):
@@ -169,7 +172,8 @@ class ImageConfigurationPage (HobPage):
 
     def disable_warnings_bar(self):
         if self.builder.parsing_warnings:
-            self.warnings_bar.hide_all()
+            if hasattr(self, 'warnings_bar'):
+                self.warnings_bar.hide_all()
             self.builder.parsing_warnings = []
 
     def create_config_machine(self):
@@ -199,12 +203,9 @@ class ImageConfigurationPage (HobPage):
         markup += "http://www.yoctoproject.org/docs/current/dev-manual/"
         markup += "dev-manual.html#understanding-and-using-layers\">reference manual</a>."
         self.layer_info_icon = HobInfoButton("<b>Layers</b>" + "*" + markup, self.get_parent())
-#        self.progress_box = gtk.HBox(False, 6)
         self.progress_bar = HobProgressBar()
-#        self.progress_box.pack_start(self.progress_bar, expand=True, fill=True)
         self.stop_button = HobAltButton("Stop")
         self.stop_button.connect("clicked", self.stop_button_clicked_cb)
-#        self.progress_box.pack_end(stop_button, expand=False, fill=False)
         self.machine_separator = gtk.HSeparator()
 
     def set_config_machine_layout(self, show_progress_bar = False):
@@ -228,17 +229,19 @@ class ImageConfigurationPage (HobPage):
     def create_config_baseimg(self):
         self.image_title = gtk.Label()
         self.image_title.set_alignment(0, 1.0)
-        mark = "<span %s>Select a base image</span>" % self.span_tag('x-large', 'bold')
+        mark = "<span %s>Select an image recipe</span>" % self.span_tag('x-large', 'bold')
         self.image_title.set_markup(mark)
 
         self.image_title_desc = gtk.Label()
         self.image_title_desc.set_alignment(0, 0.5)
-        mark = ("<span %s>Base images are a starting point for the type of image you want. "
+
+        mark = ("<span %s>Image recipes are a starting point for the type of image you want. "
                 "You can build them as \n"
-                "they are or customize them to your specific needs.\n</span>") % self.span_tag('medium')
+                "they are or edit them to suit your needs.\n</span>") % self.span_tag('medium')
         self.image_title_desc.set_markup(mark)
 
         self.image_combo = gtk.combo_box_new_text()
+        self.image_combo.set_row_separator_func(self.combo_separator_func, None)
         self.image_combo_id = self.image_combo.connect("changed", self.image_combo_changed_cb)
 
         self.image_desc = gtk.Label()
@@ -257,6 +260,11 @@ class ImageConfigurationPage (HobPage):
 
         self.image_separator = gtk.HSeparator()
 
+    def combo_separator_func(self, model, iter, user_data):
+        name = model.get_value(iter, 0)
+        if name == "--Separator--":
+            return True
+
     def set_config_baseimg_layout(self):
         self.gtable.attach(self.image_title, 0, 40, 15+self.warning_shift, 17+self.warning_shift)
         self.gtable.attach(self.image_title_desc, 0, 40, 18+self.warning_shift, 22+self.warning_shift)
@@ -271,15 +279,13 @@ class ImageConfigurationPage (HobPage):
 
         # create button "Build image"
         self.just_bake_button = HobButton("Build image")
-        #self.just_bake_button.set_size_request(205, 49)
-        self.just_bake_button.set_tooltip_text("Build target image")
+        self.just_bake_button.set_tooltip_text("Build the image recipe as it is")
         self.just_bake_button.connect("clicked", self.just_bake_button_clicked_cb)
         button_box.pack_end(self.just_bake_button, expand=False, fill=False)
 
-        # create button "Edit Image"
-        self.edit_image_button = HobAltButton("Edit image")
-        #self.edit_image_button.set_size_request(205, 49)
-        self.edit_image_button.set_tooltip_text("Edit target image")
+        # create button "Edit image recipe"
+        self.edit_image_button = HobAltButton("Edit image recipe")
+        self.edit_image_button.set_tooltip_text("Customize the recipes and packages to be included in your image")
         self.edit_image_button.connect("clicked", self.edit_image_button_clicked_cb)
         button_box.pack_end(self.edit_image_button, expand=False, fill=False)
 
@@ -313,6 +319,8 @@ class ImageConfigurationPage (HobPage):
         # reset machine_combo_changed_by_manual
         self.machine_combo_changed_by_manual = True
 
+        self.builder.configuration.selected_image = None
+
         # Do reparse recipes
         self.builder.populate_recipe_package_info_async()
 
@@ -361,7 +369,33 @@ class ImageConfigurationPage (HobPage):
     def image_combo_changed_cb(self, combo):
         self.builder.window_sensitive(False)
         selected_image = self.image_combo.get_active_text()
+        if selected_image == self.__custom_image__:
+            topdir = self.builder.get_topdir()
+            images_dir = topdir + "/recipes/images/"
+            self.builder.ensure_dir(images_dir)
+
+            dialog = RetrieveImageDialog(images_dir, "Select from my image recipes",
+                            self.builder, gtk.DIALOG_MODAL | gtk.DIALOG_DESTROY_WITH_PARENT)
+            response = dialog.run()
+            if response == gtk.RESPONSE_OK:
+                image_name = dialog.get_filename()
+                head, tail = os.path.split(image_name)
+                selected_image = os.path.splitext(tail)[0]
+                self.custom_image_selected = selected_image
+                self.update_image_combo(self.builder.recipe_model, selected_image)
+            else:
+                selected_image = self.__dummy_image__
+                self.update_image_combo(self.builder.recipe_model, None)
+            dialog.destroy()
+        else:
+            if self.custom_image_selected:
+                self.custom_image_selected = None
+                self.update_image_combo(self.builder.recipe_model, selected_image)
+
         if not selected_image or (selected_image == self.__dummy_image__):
+            self.builder.window_sensitive(True)
+            self.just_bake_button.hide()
+            self.edit_image_button.hide()
             return
 
         # remove __dummy_image__ item from the store list after first user selection
@@ -427,6 +461,11 @@ class ImageConfigurationPage (HobPage):
             self.image_combo.append_text(self.__dummy_image__)
             cnt = cnt + 1
 
+        self.image_combo.append_text(self.__custom_image__)
+        self.image_combo.append_text("--Separator--")
+        cnt = cnt + 2
+
+        topdir = self.builder.get_topdir()
         # append and set active
         while it:
             path = image_model.get_path(it)
@@ -450,16 +489,27 @@ class ImageConfigurationPage (HobPage):
             else:
                 allow = True
 
+            file_name = image_model[path][recipe_model.COL_FILE]
+            if file_name and topdir in file_name:
+                allow = False
+
             if allow:
                 self.image_combo.append_text(image_name)
                 if image_name == selected_image:
                     active = cnt
                 cnt = cnt + 1
-
         self.image_combo.append_text(self.builder.recipe_model.__custom_image__)
+
         if selected_image == self.builder.recipe_model.__custom_image__:
             active = cnt
 
+        if self.custom_image_selected:
+            self.image_combo.append_text("--Separator--")
+            self.image_combo.append_text(self.custom_image_selected)
+            cnt = cnt + 2
+            if self.custom_image_selected == selected_image:
+                active = cnt
+
         self.image_combo.set_active(active)
 
         if active != 0:
@@ -470,14 +520,14 @@ class ImageConfigurationPage (HobPage):
     def layer_button_clicked_cb(self, button):
         # Create a layer selection dialog
         self.builder.show_layer_selection_dialog()
-        
+
     def view_adv_configuration_button_clicked_cb(self, button):
         # Create an advanced settings dialog
         response, settings_changed = self.builder.show_adv_settings_dialog()
         if not response:
             return
         if settings_changed:
-            self.builder.reparse_post_adv_settings()        
+            self.builder.reparse_post_adv_settings()
 
     def just_bake_button_clicked_cb(self, button):
         self.builder.parsing_warnings = []

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

@@ -27,6 +27,7 @@ from bb.ui.crumbs.hobwidget import hic, HobViewTable, HobAltButton, HobButton
 from bb.ui.crumbs.hobpages import HobPage
 import subprocess
 from bb.ui.crumbs.hig.crumbsdialog import CrumbsDialog
+from bb.ui.crumbs.hig.saveimagedialog import SaveImageDialog
 
 #
 # ImageDetailsPage
@@ -188,7 +189,10 @@ class ImageDetailsPage (HobPage):
         self.image_store = []
         self.button_ids = {}
         self.details_bottom_buttons = gtk.HBox(False, 6)
+        self.image_saved = False
         self.create_visual_elements()
+        self.name_field_template = ""
+        self.description_field_template = ""
 
     def create_visual_elements(self):
         # create visual elements
@@ -247,7 +251,7 @@ class ImageDetailsPage (HobPage):
         self.pack_start(self.group_align, expand=True, fill=True)
 
         self.build_result = None
-        if self.build_succeeded and self.builder.current_step == self.builder.IMAGE_GENERATING:
+        if self.image_saved or (self.build_succeeded and self.builder.current_step == self.builder.IMAGE_GENERATING):
             # building is the previous step
             icon = gtk.Image()
             pixmap_path = hic.ICON_INDI_CONFIRM_FILE
@@ -255,11 +259,14 @@ class ImageDetailsPage (HobPage):
             pix_buffer = gtk.gdk.pixbuf_new_from_file(pixmap_path)
             icon.set_from_pixbuf(pix_buffer)
             varlist = [""]
-            vallist = ["Your image is ready"]
+            if self.image_saved:
+                vallist = ["Your image recipe has been saved"]
+            else:
+                vallist = ["Your image is ready"]
             self.build_result = self.BuildDetailBox(varlist=varlist, vallist=vallist, icon=icon, color=color)
             self.box_group_area.pack_start(self.build_result, expand=False, fill=False)
 
-        self.buttonlist = ["Build new image", "Run image", "Deploy image"]
+        self.buttonlist = ["Build new image", "Save image recipe", "Run image", "Deploy image"]
 
         # Name
         self.image_store = []
@@ -333,13 +340,18 @@ class ImageDetailsPage (HobPage):
         #    self.kernel_detail = self.DetailBox(varlist=varlist, vallist=vallist, button=change_kernel_button)
         #    self.box_group_area.pack_start(self.kernel_detail, expand=True, fill=True)
 
-        # Machine, Base image and Layers
+        # Machine, Image recipe and Layers
         layer_num_limit = 15
-        varlist = ["Machine: ", "Base image: ", "Layers: "]
+        varlist = ["Machine: ", "Image recipe: ", "Layers: "]
         vallist = []
         self.setting_detail = None
         if self.build_succeeded:
             vallist.append(machine)
+            if self.builder.recipe_model.is_custom_image():
+                if self.builder.configuration.initial_selected_image == self.builder.recipe_model.__custom_image__:
+                    base_image ="New image recipe"
+                else:
+                    base_image = self.builder.configuration.initial_selected_image + " (edited)"
             vallist.append(base_image)
             i = 0
             for layer in layers:
@@ -359,7 +371,7 @@ class ImageDetailsPage (HobPage):
                 i += 1
 
             edit_config_button = HobAltButton("Edit configuration")
-            edit_config_button.set_tooltip_text("Edit machine, base image and recipes")
+            edit_config_button.set_tooltip_text("Edit machine and image recipe")
             edit_config_button.connect("clicked", self.edit_config_button_clicked_cb)
             self.setting_detail = self.DetailBox(varlist=varlist, vallist=vallist, button=edit_config_button)
             self.box_group_area.pack_start(self.setting_detail, expand=True, fill=True)
@@ -391,6 +403,7 @@ class ImageDetailsPage (HobPage):
         self.show_all()
         if self.kernel_detail and (not is_runnable):
             self.kernel_detail.hide()
+        self.image_saved = False
 
     def view_files_clicked_cb(self, button, image_addr):
         subprocess.call("xdg-open /%s" % image_addr, shell=True)
@@ -574,6 +587,15 @@ class ImageDetailsPage (HobPage):
             created = True
             is_runnable = True
 
+        name = "Save image recipe"
+        if name in buttonlist and self.builder.recipe_model.is_custom_image():
+            save_button = HobAltButton("Save image recipe")
+            save_button.set_tooltip_text("Keep your changes saving them as an image recipe")
+            save_button.set_sensitive(not self.image_saved)
+            button_id = save_button.connect("clicked", self.save_button_clicked_cb)
+            self.button_ids[button_id] = save_button
+            self.details_bottom_buttons.pack_end(save_button, expand=False, fill=False)
+
         name = "Build new image"
         if name in buttonlist:
             # create button "Build new image"
@@ -608,6 +630,16 @@ class ImageDetailsPage (HobPage):
             else:
                 self.builder.runqemu_image(self.toggled_image, self.sel_kernel)
 
+    def save_button_clicked_cb(self, button):
+        topdir = self.builder.get_topdir()
+        images_dir = topdir + "/recipes/images/"
+        self.builder.ensure_dir(images_dir)
+
+        dialog = SaveImageDialog(images_dir, self.name_field_template, self.description_field_template,
+                 "Save image recipe", self.builder, gtk.DIALOG_MODAL | gtk.DIALOG_DESTROY_WITH_PARENT)
+        response = dialog.run()
+        dialog.destroy()
+
     def build_new_button_clicked_cb(self, button):
         self.builder.initiate_new_build_async()
 

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

@@ -278,7 +278,7 @@ class PackageSelectionPage (HobPage):
                 image_total_size += (51200 * 1024)
             image_total_size_str = HobPage._size_to_string(image_total_size)
 
-        self.label.set_label("Packages included: %s\nSelected packages size: %s\nTotal image size: %s" %
+        self.label.set_label("Packages included: %s\nSelected packages size: %s\nEstimated image size: %s" %
                             (selected_packages_num, selected_packages_size_str, image_total_size_str))
         self.ins.show_indicator_icon("Included packages", selected_packages_num)
 

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

@@ -375,10 +375,16 @@ class RunningBuild (gobject.GObject):
                 r = "R"
             else:
                 r = ""
+
+            extra = ''
+            if not event._reasons:
+                if event._close_matches:
+                    extra = ". Close matches:\n  %s" % '\n  '.join(event._close_matches)
+
             if event._dependees:
-                msg = "Nothing %sPROVIDES '%s' (but %s %sDEPENDS on or otherwise requires it)\n" % (r, event._item, ", ".join(event._dependees), r)
+                msg = "Nothing %sPROVIDES '%s' (but %s %sDEPENDS on or otherwise requires it)%s\n" % (r, event._item, ", ".join(event._dependees), r, extra)
             else:
-                msg = "Nothing %sPROVIDES '%s'\n" % (r, event._item)
+                msg = "Nothing %sPROVIDES '%s'%s\n" % (r, event._item, extra)
             if event._reasons:
                 for reason in event._reasons:
                     msg += ("%s\n" % reason)

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

@@ -1,187 +0,0 @@
-#
-# BitBake Graphical GTK User Interface
-#
-# Copyright (C) 2011        Intel Corporation
-#
-# Authored by Shane Wang <shane.wang@intel.com>
-#
-# This program is free software; you can redistribute it and/or modify
-# it under the terms of the GNU General Public License version 2 as
-# published by the Free Software Foundation.
-#
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License along
-# with this program; if not, write to the Free Software Foundation, Inc.,
-# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
-
-import gobject
-import os
-import re
-
-class File(gobject.GObject):
-
-    def __init__(self, pathfilename, suffix):
-        if not pathfilename.endswith(suffix):
-            pathfilename = "%s%s" % (pathfilename, suffix)
-        gobject.GObject.__init__(self)
-        self.pathfilename = pathfilename
-
-    def readFile(self):
-        if not os.path.isfile(self.pathfilename):
-            return None
-        if not os.path.exists(self.pathfilename):
-            return None
-
-        with open(self.pathfilename, 'r') as f:
-            contents = f.readlines()
-        f.close()
-
-        return contents
-
-    def writeFile(self, contents):
-        if os.path.exists(self.pathfilename):
-            orig = "%s.orig" % self.pathfilename
-            if os.path.exists(orig):
-                os.remove(orig)
-            os.rename(self.pathfilename, orig)
-
-        with open(self.pathfilename, 'w') as f:
-            f.write(contents)
-        f.close()
-
-class ConfigFile(File):
-    """
-    This object does save general config file. (say bblayers.conf, or local.conf). Again, it is the base class for other template files and image bb files.
-    """
-    def __init__(self, pathfilename, suffix = None, header = None):
-        if suffix:
-            File.__init__(self, pathfilename, suffix)
-        else:
-            File.__init__(self, pathfilename, ".conf")
-        if header:
-            self.header = header
-        else:
-            self.header = "# Config generated by Hob\n\n"
-        self.dictionary = {}
-
-    def setVar(self, var, val):
-        if isinstance(val, list):
-            liststr = ""
-            if val:
-                i = 0
-                for value in val:
-                    if i < len(val) - 1:
-                        liststr += "%s " % value
-                    else:
-                        liststr += "%s" % value
-                    i += 1
-            self.dictionary[var] = liststr
-        else:
-            self.dictionary[var] = val
-
-    def save(self):
-        contents = self.header
-        for var, val in self.dictionary.items():
-            contents += "%s = \"%s\"\n" % (var, val)
-        File.writeFile(self, contents)
-
-class HobTemplateFile(ConfigFile):
-    """
-    This object does save or load hob specific file.
-    """
-    def __init__(self, pathfilename):
-        ConfigFile.__init__(self, pathfilename, ".hob", "# Hob Template generated by Hob\n\n")
-
-    def getVar(self, var):
-        if var in self.dictionary: 
-            return self.dictionary[var]
-        else:
-            return ""
-
-    def getVersion(self):
-        contents = ConfigFile.readFile(self)
-
-        pattern = "^\s*(\S+)\s*=\s*(\".*?\")"
-
-        for line in contents:
-            match = re.search(pattern, line)
-            if match:
-                if match.group(1) == "VERSION":
-                    return match.group(2).strip('"')
-        return None
-
-    def load(self):
-        contents = ConfigFile.readFile(self)
-        self.dictionary.clear()
-
-        pattern = "^\s*(\S+)\s*=\s*(\".*?\")"
-
-        for line in contents:
-            match = re.search(pattern, line)
-            if match:
-                var = match.group(1)
-                val = match.group(2).strip('"')
-                self.dictionary[var] = val
-        return self.dictionary
-
-class RecipeFile(ConfigFile):
-    """
-    This object is for image bb file.
-    """
-    def __init__(self, pathfilename):
-        ConfigFile.__init__(self, pathfilename, ".bb", "# Recipe generated by Hob\n\ninherit core-image\n")
-
-class TemplateMgr(gobject.GObject):
-
-    __gRecipeVars__ = ["DEPENDS", "IMAGE_INSTALL"]
-
-    def __init__(self):
-        gobject.GObject.__init__(self)
-        self.template_hob = None
-        self.bblayers_conf = None
-        self.local_conf = None
-        self.image_bb = None
-
-    @classmethod
-    def convert_to_template_pathfilename(cls, filename, path):
-        return "%s/%s%s%s" % (path, "template-", filename, ".hob")
-
-    @classmethod
-    def convert_to_image_pathfilename(cls, filename, path):
-        return "%s/%s%s%s" % (path, "hob-image-", filename, ".bb")
-
-    def open(self, filename, path):
-        self.template_hob = HobTemplateFile(TemplateMgr.convert_to_template_pathfilename(filename, path))
-        self.image_bb = RecipeFile(TemplateMgr.convert_to_image_pathfilename(filename, path))
-
-    def setVar(self, var, val):
-        if var in TemplateMgr.__gRecipeVars__:
-            self.image_bb.setVar(var, val)
-
-        self.template_hob.setVar(var, val)
-
-    def save(self):
-        self.image_bb.save()
-        self.template_hob.save()
-
-    def getVersion(self, path):
-        return HobTemplateFile(path).getVersion()
-
-    def load(self, path):
-        self.template_hob = HobTemplateFile(path)
-        self.dictionary = self.template_hob.load()
-
-    def getVar(self, var):
-        return self.template_hob.getVar(var)
-
-    def destroy(self):
-        if self.template_hob:
-            del self.template_hob
-            template_hob = None
-        if self.image_bb:
-            del self.image_bb
-            self.image_bb = None

bitbake/lib/bb/ui/depexp.py

@@ -154,7 +154,7 @@ class DepExplorer(gtk.Window):
 
     def on_cursor_changed(self, selection):
         (model, it) = selection.get_selected()
-        if iter is None:
+        if it is None:
             current_package = None
         else:
             current_package = model.get_value(it, COL_PKG_NAME)
@@ -163,23 +163,17 @@ class DepExplorer(gtk.Window):
         self.revdep_treeview.set_current_package(current_package)
 
 
-def parse(depgraph, pkg_model, depends_model):
-    for package in depgraph["pn"]:
-        pkg_model.set(pkg_model.append(), COL_PKG_NAME, package)
+    def parse(self, depgraph):
+        for package in depgraph["pn"]:
+            self.pkg_model.insert(0, (package,))
 
-    for package in depgraph["depends"]:
-        for depend in depgraph["depends"][package]:
-            depends_model.set (depends_model.append(),
-                              COL_DEP_TYPE, TYPE_DEP,
-                              COL_DEP_PARENT, package,
-                              COL_DEP_PACKAGE, depend)
+        for package in depgraph["depends"]:
+            for depend in depgraph["depends"][package]:
+                self.depends_model.insert (0, (TYPE_DEP, package, depend))
 
-    for package in depgraph["rdepends-pn"]:
-        for rdepend in depgraph["rdepends-pn"][package]:
-            depends_model.set (depends_model.append(),
-                              COL_DEP_TYPE, TYPE_RDEP,
-                              COL_DEP_PARENT, package,
-                              COL_DEP_PACKAGE, rdepend)
+        for package in depgraph["rdepends-pn"]:
+            for rdepend in depgraph["rdepends-pn"][package]:
+                self.depends_model.insert (0, (TYPE_RDEP, package, rdepend))
 
 
 class gtkthread(threading.Thread):
@@ -293,7 +287,7 @@ def main(server, eventHandler, params):
 
             if isinstance(event, bb.event.DepTreeGenerated):
                 gtk.gdk.threads_enter()
-                parse(event._depgraph, dep.pkg_model, dep.depends_model)
+                dep.parse(event._depgraph)
                 gtk.gdk.threads_leave()
 
             if isinstance(event, bb.command.CommandCompleted):

bitbake/lib/bb/ui/hob.py

@@ -58,6 +58,19 @@ def event_handle_idle_func(eventHandler, hobHandler):
         event = eventHandler.getEvent()
     return True
 
+_evt_list = [ "bb.runqueue.runQueueExitWait", "bb.event.LogExecTTY", "logging.LogRecord",
+              "bb.build.TaskFailed", "bb.build.TaskBase", "bb.event.ParseStarted",
+              "bb.event.ParseProgress", "bb.event.ParseCompleted", "bb.event.CacheLoadStarted",
+              "bb.event.CacheLoadProgress", "bb.event.CacheLoadCompleted", "bb.command.CommandFailed",
+              "bb.command.CommandExit", "bb.command.CommandCompleted",  "bb.cooker.CookerExit",
+              "bb.event.MultipleProviders", "bb.event.NoProvider", "bb.runqueue.sceneQueueTaskStarted",
+              "bb.runqueue.runQueueTaskStarted", "bb.runqueue.runQueueTaskFailed", "bb.runqueue.sceneQueueTaskFailed",
+              "bb.event.BuildBase", "bb.build.TaskStarted", "bb.build.TaskSucceeded", "bb.build.TaskFailedSilent",
+              "bb.event.SanityCheckPassed", "bb.event.SanityCheckFailed", "bb.event.PackageInfo",
+              "bb.event.TargetsTreeGenerated", "bb.event.ConfigFilesFound", "bb.event.ConfigFilePathFound",
+              "bb.event.FilesMatchingFound", "bb.event.NetworkTestFailed", "bb.event.NetworkTestPassed",
+              "bb.event.BuildStarted", "bb.event.BuildCompleted", "bb.event.DiskFull"]
+
 def main (server, eventHandler, params):
     params.updateFromServer(server)
     gobject.threads_init()
@@ -68,6 +81,8 @@ def main (server, eventHandler, params):
     recipe_model = RecipeListModel()
     package_model = PackageListModel()
 
+    llevel, debug_domains = bb.msg.constructLogOptions()
+    server.runCommand(["setEventMask", server.getEventHandle(), llevel, debug_domains, _evt_list])
     hobHandler = HobHandler(server, recipe_model, package_model)
     builder = Builder(hobHandler, recipe_model, package_model)
 

bitbake/lib/bb/ui/knotty.py

@@ -216,21 +216,34 @@ class TerminalFilter(object):
             fd = sys.stdin.fileno()
             self.termios.tcsetattr(fd, self.termios.TCSADRAIN, self.stdinbackup)
 
-def main(server, eventHandler, params, tf = TerminalFilter):
-
+def _log_settings_from_server(server):
     # Get values of variables which control our output
     includelogs, error = server.runCommand(["getVariable", "BBINCLUDELOGS"])
     if error:
         logger.error("Unable to get the value of BBINCLUDELOGS variable: %s" % error)
-        return 1
+        raise BaseException(error)
     loglines, error = server.runCommand(["getVariable", "BBINCLUDELOGS_LINES"])
     if error:
         logger.error("Unable to get the value of BBINCLUDELOGS_LINES variable: %s" % error)
-        return 1
+        raise BaseException(error)
     consolelogfile, error = server.runCommand(["getVariable", "BB_CONSOLELOG"])
     if error:
         logger.error("Unable to get the value of BB_CONSOLELOG variable: %s" % error)
-        return 1
+        raise BaseException(error)
+    return includelogs, loglines, consolelogfile
+
+_evt_list = [ "bb.runqueue.runQueueExitWait", "bb.event.LogExecTTY", "logging.LogRecord",
+              "bb.build.TaskFailed", "bb.build.TaskBase", "bb.event.ParseStarted",
+              "bb.event.ParseProgress", "bb.event.ParseCompleted", "bb.event.CacheLoadStarted",
+              "bb.event.CacheLoadProgress", "bb.event.CacheLoadCompleted", "bb.command.CommandFailed",
+              "bb.command.CommandExit", "bb.command.CommandCompleted",  "bb.cooker.CookerExit",
+              "bb.event.MultipleProviders", "bb.event.NoProvider", "bb.runqueue.sceneQueueTaskStarted",
+              "bb.runqueue.runQueueTaskStarted", "bb.runqueue.runQueueTaskFailed", "bb.runqueue.sceneQueueTaskFailed",
+              "bb.event.BuildBase", "bb.build.TaskStarted", "bb.build.TaskSucceeded", "bb.build.TaskFailedSilent"]
+
+def main(server, eventHandler, params, tf = TerminalFilter):
+
+    includelogs, loglines, consolelogfile = _log_settings_from_server(server)
 
     if sys.stdin.isatty() and sys.stdout.isatty():
         log_exec_tty = True
@@ -246,6 +259,10 @@ def main(server, eventHandler, params, tf = TerminalFilter):
     console.setFormatter(format)
     logger.addHandler(console)
 
+    if params.options.remote_server and params.options.kill_server:
+        server.terminateServer()
+        return
+
     if consolelogfile and not params.options.show_environment:
         bb.utils.mkdirhier(os.path.dirname(consolelogfile))
         conlogformat = bb.msg.BBLogFormatter(format_str)
@@ -254,7 +271,10 @@ def main(server, eventHandler, params, tf = TerminalFilter):
         consolelog.setFormatter(conlogformat)
         logger.addHandler(consolelog)
 
-    try:
+    llevel, debug_domains = bb.msg.constructLogOptions()
+    server.runCommand(["setEventMask", server.getEventHandle(), llevel, debug_domains, _evt_list])
+
+    if not params.observe_only:
         params.updateFromServer(server)
         cmdline = params.parseActions()
         if not cmdline:
@@ -271,9 +291,7 @@ def main(server, eventHandler, params, tf = TerminalFilter):
         elif ret != True:
             logger.error("Command '%s' failed: returned %s" % (cmdline, ret))
             return 1
-    except xmlrpclib.Fault as x:
-        logger.error("XMLRPC Fault getting commandline:\n %s" % x)
-        return 1
+
 
     parseprogress = None
     cacheprogress = None
@@ -288,8 +306,10 @@ def main(server, eventHandler, params, tf = TerminalFilter):
 
     while True:
         try:
-            termfilter.updateFooter()
-            event = eventHandler.waitEvent(0.25)
+            event = eventHandler.waitEvent(0)
+            if event is None:
+                termfilter.updateFooter()
+                event = eventHandler.waitEvent(0.25)
             if event is None:
                 if main.shutdown > 1:
                     break
@@ -320,7 +340,7 @@ def main(server, eventHandler, params, tf = TerminalFilter):
                 elif event.levelno == format.WARNING:
                     warnings = warnings + 1
                 # For "normal" logging conditions, don't show note logs from tasks
-                # but do show them if the user has changed the default log level to 
+                # but do show them if the user has changed the default log level to
                 # include verbose/debug messages
                 if event.taskpid != 0 and event.levelno <= format.NOTE:
                     continue
@@ -410,10 +430,15 @@ def main(server, eventHandler, params, tf = TerminalFilter):
                 else:
                     r = ""
 
+                extra = ''
+                if not event._reasons:
+                    if event._close_matches:
+                        extra = ". Close matches:\n  %s" % '\n  '.join(event._close_matches)
+
                 if event._dependees:
-                    logger.error("Nothing %sPROVIDES '%s' (but %s %sDEPENDS on or otherwise requires it)", r, event._item, ", ".join(event._dependees), r)
+                    logger.error("Nothing %sPROVIDES '%s' (but %s %sDEPENDS on or otherwise requires it)%s", r, event._item, ", ".join(event._dependees), r, extra)
                 else:
-                    logger.error("Nothing %sPROVIDES '%s'", r, event._item)
+                    logger.error("Nothing %sPROVIDES '%s'%s", r, event._item, extra)
                 if event._reasons:
                     for reason in event._reasons:
                         logger.error("%s", reason)
@@ -469,12 +494,15 @@ def main(server, eventHandler, params, tf = TerminalFilter):
                 pass
         except KeyboardInterrupt:
             termfilter.clearFooter()
-            if main.shutdown == 1:
+            if params.observe_only:
+                print("\nKeyboard Interrupt, exiting observer...")
+                main.shutdown = 2
+            if not params.observe_only and main.shutdown == 1:
                 print("\nSecond Keyboard Interrupt, stopping...\n")
                 _, error = server.runCommand(["stateStop"])
                 if error:
                     logger.error("Unable to cleanly stop: %s" % error)
-            if main.shutdown == 0:
+            if not params.observe_only and main.shutdown == 0:
                 print("\nKeyboard Interrupt, closing down...\n")
                 interrupted = True
                 _, error = server.runCommand(["stateShutdown"])

bitbake/lib/bb/ui/uievent.py

@@ -84,6 +84,7 @@ class BBUIEventQueue:
 
     def startCallbackHandler(self):
 
+        self.server.timeout = 1
         while not self.server.quit:
             self.server.handle_request()
         self.server.server_close()

bitbake/lib/bb/utils.py

@@ -532,6 +532,8 @@ def approved_variables():
     Determine and return the list of whitelisted variables which are approved
     to remain in the envrionment.
     """
+    if 'BB_PRESERVE_ENV' in os.environ:
+        return os.environ.keys()
     approved = []
     if 'BB_ENV_WHITELIST' in os.environ:
         approved = os.environ['BB_ENV_WHITELIST'].split()
@@ -860,11 +862,8 @@ def process_profilelog(fn):
     pout.close()  
 
 #
-# Work around multiprocessing pool bugs in python < 2.7.3
+# Was present to work around multiprocessing pool bugs in python < 2.7.3
 #
 def multiprocessingpool(*args, **kwargs):
-    if sys.version_info < (2, 7, 3):
-        return bb.compat.Pool(*args, **kwargs)
-    else:
-        return multiprocessing.pool.Pool(*args, **kwargs)
+    return multiprocessing.Pool(*args, **kwargs)
 

bitbake/lib/prserv/db.py

@@ -2,6 +2,7 @@ import logging
 import os.path
 import errno
 import prserv
+import time
 
 try:
     import sqlite3
@@ -14,7 +15,7 @@ sqlversion = sqlite3.sqlite_version_info
 if sqlversion[0] < 3 or (sqlversion[0] == 3 and sqlversion[1] < 3):
     raise Exception("sqlite3 version 3.3.0 or later is required.")
 
-class PRTable():
+class PRTable(object):
     def __init__(self, conn, table, nohist):
         self.conn = conn
         self.nohist = nohist
@@ -32,16 +33,20 @@ class PRTable():
 
     def _execute(self, *query):
         """Execute a query, waiting to acquire a lock if necessary"""
-        count = 0
+        start = time.time()
+        end = start + 20
         while True:
             try:
                 return self.conn.execute(*query)
             except sqlite3.OperationalError as exc:
-                if 'database is locked' in str(exc) and count < 500:
-                    count = count + 1
+                if 'is locked' in str(exc) and end > time.time():
                     continue
                 raise exc
 
+    def sync(self):
+        self.conn.commit()
+        self._execute("BEGIN EXCLUSIVE TRANSACTION")
+
     def _getValueHist(self, version, pkgarch, checksum):
         data=self._execute("SELECT value FROM %s WHERE version=? AND pkgarch=? AND checksum=?;" % self.table,
                            (version, pkgarch, checksum))
@@ -51,11 +56,9 @@ class PRTable():
         else:
             #no value found, try to insert
             try:
-                self._execute("BEGIN")
-                self._execute("INSERT OR ROLLBACK INTO %s VALUES (?, ?, ?, (select ifnull(max(value)+1,0) from %s where version=? AND pkgarch=?));"
+                self._execute("INSERT INTO %s VALUES (?, ?, ?, (select ifnull(max(value)+1,0) from %s where version=? AND pkgarch=?));"
                            % (self.table,self.table),
                            (version,pkgarch, checksum,version, pkgarch))
-                self.conn.commit()
             except sqlite3.IntegrityError as exc:
                 logger.error(str(exc))
 
@@ -79,11 +82,9 @@ class PRTable():
         else:
             #no value found, try to insert
             try:
-                self._execute("BEGIN")
                 self._execute("INSERT OR REPLACE INTO %s VALUES (?, ?, ?, (select ifnull(max(value)+1,0) from %s where version=? AND pkgarch=?));"
                                % (self.table,self.table),
                                (version, pkgarch, checksum, version, pkgarch))
-                self.conn.commit()
             except sqlite3.IntegrityError as exc:
                 logger.error(str(exc))
                 self.conn.rollback()
@@ -112,10 +113,8 @@ class PRTable():
         else:
             #no value found, try to insert
             try:
-                self._execute("BEGIN")
-                self._execute("INSERT OR ROLLBACK INTO %s VALUES (?, ?, ?, ?);"  % (self.table),
+                self._execute("INSERT INTO %s VALUES (?, ?, ?, ?);"  % (self.table),
                            (version, pkgarch, checksum, value))
-                self.conn.commit()
             except sqlite3.IntegrityError as exc:
                 logger.error(str(exc))
 
@@ -129,18 +128,14 @@ class PRTable():
     def _importNohist(self, version, pkgarch, checksum, value):
         try:
             #try to insert
-            self._execute("BEGIN")
-            self._execute("INSERT OR ROLLBACK INTO %s VALUES (?, ?, ?, ?);"  % (self.table),
+            self._execute("INSERT INTO %s VALUES (?, ?, ?, ?);"  % (self.table),
                            (version, pkgarch, checksum,value))
-            self.conn.commit()
         except sqlite3.IntegrityError as exc:
             #already have the record, try to update
             try:
-                self._execute("BEGIN")
                 self._execute("UPDATE %s SET value=? WHERE version=? AND pkgarch=? AND checksum=? AND value<?"  
                               % (self.table),
                                (value,version,pkgarch,checksum,value))
-                self.conn.commit()
             except sqlite3.IntegrityError as exc:
                 logger.error(str(exc))
 
@@ -223,7 +218,7 @@ class PRData(object):
         except OSError as e:
             if e.errno != errno.EEXIST:
                 raise e
-        self.connection=sqlite3.connect(self.filename, isolation_level="DEFERRED")
+        self.connection=sqlite3.connect(self.filename, isolation_level="EXCLUSIVE", check_same_thread = False)
         self.connection.row_factory=sqlite3.Row
         self._tables={}
 

bitbake/lib/prserv/serv.py

@@ -2,6 +2,8 @@ import os,sys,logging
 import signal, time, atexit, threading
 from SimpleXMLRPCServer import SimpleXMLRPCServer, SimpleXMLRPCRequestHandler
 import xmlrpclib
+import threading
+import Queue
 
 try:
     import sqlite3
@@ -31,19 +33,17 @@ class Handler(SimpleXMLRPCRequestHandler):
 PIDPREFIX = "/tmp/PRServer_%s_%s.pid"
 singleton = None
 
+
 class PRServer(SimpleXMLRPCServer):
     def __init__(self, dbfile, logfile, interface, daemon=True):
         ''' constructor '''
         SimpleXMLRPCServer.__init__(self, interface,
-                                    requestHandler=SimpleXMLRPCRequestHandler,
                                     logRequests=False, allow_none=True)
         self.dbfile=dbfile
         self.daemon=daemon
         self.logfile=logfile
         self.working_thread=None
         self.host, self.port = self.socket.getsockname()
-        self.db=prserv.db.PRData(dbfile)
-        self.table=self.db["PRMAIN"]
         self.pidfile=PIDPREFIX % (self.host, self.port)
 
         self.register_function(self.getPR, "getPR")
@@ -53,6 +53,32 @@ class PRServer(SimpleXMLRPCServer):
         self.register_function(self.importone, "importone")
         self.register_introspection_functions()
 
+        self.db = prserv.db.PRData(self.dbfile)
+        self.table = self.db["PRMAIN"]
+
+        self.requestqueue = Queue.Queue()
+        self.handlerthread = threading.Thread(target = self.process_request_thread)
+        self.handlerthread.daemon = False
+
+    def process_request_thread(self):
+        """Same as in BaseServer but as a thread.
+
+        In addition, exception handling is done here.
+
+        """
+        while True:
+            (request, client_address) = self.requestqueue.get()
+            try:
+                self.finish_request(request, client_address)
+                self.shutdown_request(request)
+            except:
+                self.handle_error(request, client_address)
+                self.shutdown_request(request)
+                self.table.sync()
+
+    def process_request(self, request, client_address):
+        self.requestqueue.put((request, client_address))
+
     def export(self, version=None, pkgarch=None, checksum=None, colinfo=True):
         try:
             return self.table.export(version, pkgarch, checksum, colinfo)
@@ -90,9 +116,11 @@ class PRServer(SimpleXMLRPCServer):
         logger.info("Started PRServer with DBfile: %s, IP: %s, PORT: %s, PID: %s" %
                      (self.dbfile, self.host, self.port, str(os.getpid())))
 
+        self.handlerthread.start()
         while not self.quit:
             self.handle_request()
 
+        self.table.sync()
         logger.info("PRServer: stopping...")
         self.server_close()
         return
@@ -143,6 +171,11 @@ class PRServer(SimpleXMLRPCServer):
         os.dup2(so.fileno(),sys.stdout.fileno())
         os.dup2(se.fileno(),sys.stderr.fileno())
 
+        # Clear out all log handlers prior to the fork() to avoid calling
+        # event handlers not part of the PRserver
+        for logger_iter in logging.Logger.manager.loggerDict.keys():
+            logging.getLogger(logger_iter).handlers = []
+
         # Ensure logging makes it to the logfile
         streamhandler = logging.StreamHandler()
         streamhandler.setLevel(logging.DEBUG)
@@ -157,10 +190,10 @@ class PRServer(SimpleXMLRPCServer):
         pf.close()
 
         self.work_forever()
-        self.delpid
+        self.delpid()
         os._exit(0)
 
-class PRServSingleton():
+class PRServSingleton(object):
     def __init__(self, dbfile, logfile, interface):
         self.dbfile = dbfile
         self.logfile = logfile
@@ -172,12 +205,11 @@ class PRServSingleton():
         self.prserv = PRServer(self.dbfile, self.logfile, self.interface)
         self.prserv.start()
         self.host, self.port = self.prserv.getinfo()
-        del self.prserv.db
 
     def getinfo(self):
         return (self.host, self.port)
 
-class PRServerConnection():
+class PRServerConnection(object):
     def __init__(self, host, port):
         if is_local_special(host, port):
             host, port = singleton.getinfo()
@@ -186,9 +218,6 @@ class PRServerConnection():
         self.connection, self.transport = bb.server.xmlrpc._create_server(self.host, self.port)
 
     def terminate(self):
-        # Don't wait for server indefinitely
-        import socket
-        socket.setdefaulttimeout(2)
         try:
             logger.info("Terminating PRServer...")
             self.connection.quit()
@@ -207,6 +236,9 @@ class PRServerConnection():
     def importone(self, version, pkgarch, checksum, value):
         return self.connection.importone(version, pkgarch, checksum, value)
 
+    def getinfo(self):
+        return self.host, self.port
+
 def start_daemon(dbfile, host, port, logfile):
     pidfile = PIDPREFIX % (host, port)
     try:
@@ -271,7 +303,7 @@ def auto_start(d):
 
     host_params = filter(None, (d.getVar('PRSERV_HOST', True) or '').split(':'))
     if not host_params:
-        return True
+        return None
 
     if len(host_params) != 2:
         logger.critical('\n'.join(['PRSERV_HOST: incorrect format',
@@ -296,7 +328,11 @@ def auto_start(d):
         port = int(host_params[1])
 
     try:
-        return PRServerConnection(host,port).ping()
+        connection = PRServerConnection(host,port)
+        connection.ping()
+        realhost, realport = connection.getinfo()
+        return str(realhost) + ":" + str(realport)
+        
     except Exception:
         logger.critical("PRservice %s:%d not available" % (host, port))
         raise PRServiceConfigError

documentation/Makefile

@@ -196,7 +196,11 @@ TARFILES = mega-manual.html mega-style.css figures/yocto-environment.png figures
         figures/perf-wget-g-copy-to-user-expanded-stripped-unresolved-hidden.png figures/pybootchartgui-linux-yocto.png \
         figures/pychart-linux-yocto-rpm.png figures/pychart-linux-yocto-rpm-nostrip.png \
         figures/sched-wakeup-profile.png figures/sysprof-callers.png \
-        figures/sysprof-copy-from-user.png figures/sysprof-copy-to-user.png
+        figures/sysprof-copy-from-user.png figures/sysprof-copy-to-user.png figures/cross-development-toolchains.png \
+	figures/yocto-environment-ref.png figures/user-configuration.png figures/source-input.png \
+	figures/package-feeds.png figures/layer-input.png figures/images.png figures/sdk.png \
+	figures/source-fetching.png figures/patching.png figures/configuration-compile-autoreconf.png \
+	figures/analysis-for-package-splitting.png
 	endif
 
 MANUALS = $(DOC)/$(DOC).html
@@ -209,7 +213,13 @@ ifeq ($(DOC),ref-manual)
 XSLTOPTS = --xinclude
 ALLPREQ = html pdf eclipse tarball
 TARFILES = ref-manual.html ref-style.css figures/poky-title.png \
-	figures/buildhistory.png figures/buildhistory-web.png eclipse
+	figures/buildhistory.png figures/buildhistory-web.png eclipse \
+        figures/cross-development-toolchains.png figures/layer-input.png \
+	figures/package-feeds.png figures/source-input.png \
+	figures/user-configuration.png figures/yocto-environment-ref.png \
+	figures/images.png figures/sdk.png figures/source-fetching.png \
+	figures/patching.png figures/configuration-compile-autoreconf.png \
+	figures/analysis-for-package-splitting.png
 MANUALS = $(DOC)/$(DOC).html $(DOC)/$(DOC).pdf $(DOC)/eclipse
 FIGURES = figures
 STYLESHEET = $(DOC)/*.css

documentation/README

@@ -2,60 +2,60 @@ documentation
 =============
 
 This is the directory that contains the Yocto Project documentation.  The Yocto
-Project source repositories at http://git.yoctoproject.org/cgit.cgi have two 
+Project source repositories at http://git.yoctoproject.org/cgit.cgi have two
 instances of the "documentation" directory.  You should understand each of
 these instances.
 
   poky/documentation - The directory within the poky Git repository containing
-                       the set of Yocto Project manuals.  When you clone the 
-                       poky Git repository, the documentation directory 
-                       contains the manuals.  The state of the manuals in this 
-                       directory is guaranteed to reflect the latest Yocto 
-                       Project release.  The manuals at the tip of this 
-                       directory will also likely contain most manual 
+                       the set of Yocto Project manuals.  When you clone the
+                       poky Git repository, the documentation directory
+                       contains the manuals.  The state of the manuals in this
+                       directory is guaranteed to reflect the latest Yocto
+                       Project release.  The manuals at the tip of this
+                       directory will also likely contain most manual
                        development changes.
 
-  yocto-docs/documentation - The Git repository for the Yocto Project manuals.  
-                             This repository is where manual development 
-                             occurs.  If you plan on contributing back to the 
-                             Yocto Project documentation, you should set up 
-                             a local Git repository based on this upstream 
+  yocto-docs/documentation - The Git repository for the Yocto Project manuals.
+                             This repository is where manual development
+                             occurs.  If you plan on contributing back to the
+                             Yocto Project documentation, you should set up
+                             a local Git repository based on this upstream
                              repository as follows:
 
                                git clone git://git.yoctoproject.org/yocto-docs
 
-                             Changes and patches are first pushed to the 
-                             yocto-docs Git repository.  Later, they make it 
-                             into the poky Git repository found at 
-                             git://git.yoctoproject.org/poky.  
+                             Changes and patches are first pushed to the
+                             yocto-docs Git repository.  Later, they make it
+                             into the poky Git repository found at
+                             git://git.yoctoproject.org/poky.
 
 Manual Organization
 ===================
 
 Folders exist for individual manuals as follows:
 
-* adt-manual       - The Yocto Project Application Development Toolkit (ADT)
-                     User's Guide.
-* bsp-guide        - The Yocto Project Board Support (BSP) Developer's Guide
+* adt-manual       - The Yocto Project Application Developer's Guide.
+* bsp-guide        - The Yocto Project Board Support Package (BSP) Developer's Guide
 * dev-manual       - The Yocto Project Development Manual
-* kernel-manual    - The Yocto Project Kernel Architecture and Use Manual
-* poky-ref-manual  - The Yocto Project Reference Manual
+* kernel-dev       - The Yocto Project Linux Kernel Development Manual
+* ref-manual       - The Yocto Project Reference Manual
 * yocto-project-qs - The Yocto Project Quick Start
-* mega-manual      - The aggregated manual comprised of all YP manuals and guides
+* mega-manual      - An aggregated manual comprised of all YP manuals and guides
+* profile-manual   - The Yocto Project Profile and Tracing Manual
 
 Each folder is self-contained regarding content and figures.  Note that there
 is a sed file needed to process the links of the mega-manual.  The sed file
-is located in the tools directory.  Also note that the figures folder in the 
+is located in the tools directory.  Also note that the figures folder in the
 mega-manual directory contains duplicates of all the figures in the YP folders
 directories for all YP manuals and guides.
 
-If you want to find HTML versions of the Yocto Project manuals on the web, 
-go to http://www.yoctoproject.org and click on the "Documentation" tab.  From 
+If you want to find HTML versions of the Yocto Project manuals on the web,
+go to http://www.yoctoproject.org and click on the "Documentation" tab.  From
 there you have access to archived documentation from previous releases, current
-documentation for the latest release, and "Docs in Progress" for the release 
+documentation for the latest release, and "Docs in Progress" for the release
 currently being developed.
 
-In general, the Yocto Project site (http://www.yoctoproject.org) is a great 
+In general, the Yocto Project site (http://www.yoctoproject.org) is a great
 reference for both information and downloads.
 
 Makefile
@@ -66,8 +66,8 @@ tarballs, etc.  Details on how the Makefile work are documented
 inside the Makefile.  See that file for more information.
 
 To build a manual, you run the make command and pass it the name
-of the folder containing the manual's contents. 
-For example, the following command run from the documentation directory 
+of the folder containing the manual's contents.
+For example, the following command run from the documentation directory
 creates an HTML and a PDF version of the ADT manual.
 The DOC variable specifies the manual you are making:
 
@@ -86,9 +86,6 @@ Contains various templates, fonts, and some old PNG files.
 tools
 =====
 Contains a tool to convert the DocBook files to PDF format.  This folder also
-contains the mega-manual.sed file, which is used by Makefile to process 
-cross-references from within the manual that normally go to an external 
+contains the mega-manual.sed file, which is used by Makefile to process
+cross-references from within the manual that normally go to an external
 manual.
-
-
-

documentation/adt-manual/adt-prepare.xml

@@ -91,8 +91,8 @@
             <para>
                 If you use BitBake to generate the ADT Installer tarball, you must
                 <filename>source</filename> the environment setup script
-                (<ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>) 
-                located in the Source Directory before running the 
+                (<ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>)
+                located in the Source Directory before running the
                 BitBake command that creates the tarball.
             </para>
 
@@ -229,9 +229,11 @@
         <title>Using a Cross-Toolchain Tarball</title>
 
         <para>
-            If you want to simply install the cross-toolchain by hand, you can
+            If you want to simply install a cross-toolchain by hand, you can
             do so by running the toolchain installer.
-            If you use this method to install the cross-toolchain and you
+            The installer includes the pre-built cross-toolchain, the
+            <filename>runqemu</filename> script, and support files.
+            If you use this method to install the cross-toolchain, you
             might still need to install the target sysroot by installing and
             extracting it separately.
             For information on how to install the sysroot, see the
@@ -241,80 +243,61 @@
         <para>
             Follow these steps:
             <orderedlist>
-                <listitem><para>Go to
-                    <ulink url='&YOCTO_TOOLCHAIN_DL_URL;'></ulink>
-                    and find the folder that matches your host development system
-                    (i.e. <filename>i686</filename> for 32-bit machines or
-                    <filename>x86-64</filename> for 64-bit machines).</para></listitem>
-                <listitem><para>Go into that folder and download the toolchain installer whose name
-                    includes the appropriate target architecture.
-                    For example, if your host development system is an Intel-based 64-bit system and
-                    you are going to use your cross-toolchain for an Intel-based 32-bit target, go into the
-                    <filename>x86_64</filename> folder and download the following installer:
-                    <literallayout class='monospaced'>
-     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 need GMAE, you should use the
-                        <filename>bitbake meta-toolchain-gmae</filename>
-                        command.
-                        Running the resulting installation script will support
-                        such development.
-                        If you are not concerned with GMAE, you can generate
-                        the toolchain installer using
-                        <filename>bitbake meta-toolchain</filename>.
-                        Either of these methods requires you to still
-                        install the target sysroot by installing and
-                        extracting it separately.
-                        For information on how to install the sysroot, see the
-                        "<link linkend='extracting-the-root-filesystem'>Extracting the Root Filesystem</link>" section.
-                        </para>
-                        <para>A final method of building the toolchain installer
-                        exists that has significant advantages over the previous
-                        two methods.
-                        This method results in a toolchain installer that
-                        contains the sysroot that matches your target root
-                        filesystem.
-                        To build this installer, use the
-                        <filename>bitbake image -c populate_sdk</filename>
-                        command.</para>
-                        <para>Remember, before using any
-                        <filename>bitbake</filename> command, you must source
-                        the <filename>&OE_INIT_PATH;</filename> script
-                        located in the Source Directory and you must make sure
-                        your <filename>conf/local.conf</filename> variables are
-                        correct.
-                        In particular, you need to be sure the
-                        <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink>
-                        variable matches the architecture for which you are
-                        building and that the <filename>SDKMACHINE</filename>
-                        variable is correctly set if you are building
-                        a toolchain for an architecture that differs from your
-                        current development host machine.</para>
-                        <para>When the BitBake command
-                        completes, the toolchain installer will 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.
+                <listitem><para>Get your toolchain installer using one of the
+                    following methods:
+                    <itemizedlist>
+                        <listitem><para>Go to
+                            <ulink url='&YOCTO_TOOLCHAIN_DL_URL;'></ulink>
+                            and find the folder that matches your host
+                            development system (i.e. <filename>i686</filename>
+                            for 32-bit machines or <filename>x86_64</filename>
+                            for 64-bit machines).</para>
+                            <para>Go into that folder and download the toolchain
+                            installer whose name includes the appropriate target
+                            architecture.
+                            The toolchains provided by the Yocto Project
+                            are based off of the
+                            <filename>core-image-sato</filename> image and
+                            contain libraries appropriate for developing
+                            against that image.
+                            For example, if your host development system is a
+                            64-bit x86 system and you are going to use
+                            your cross-toolchain for a 32-bit x86
+                            target, go into the <filename>x86_64</filename>
+                            folder and download the following installer:
+                            <literallayout class='monospaced'>
+     poky-eglibc-x86_64-core-image-sato-i586.sh
+                            </literallayout></para></listitem>
+                        <listitem><para>Build your own toolchain installer.
+                            For cases where you cannot use an installer
+                            from the download area, you can build your own as
+                            described in the
+                            "<link linkend='optionally-building-a-toolchain-installer'>Optionally Building a Toolchain Installer</link>"
+                            section.</para></listitem>
+                    </itemizedlist></para></listitem>
+                <listitem><para>Once you have the installer, run it to install
+                    the toolchain.
                     You must change the permissions on the toolchain installer
                     script so that it is executable.</para>
-                    <para>The following command shows how to run the installer given a toolchain tarball
-                    for a 64-bit development host system and a 32-bit target architecture.
-                    The example assumes the toolchain installer is located in <filename>~/Downloads/</filename>.
+                    <para>The following command shows how to run the installer
+                    given a toolchain tarball for a 64-bit x86 development host
+                    system and a 32-bit x86 target architecture.
+                    The example assumes the toolchain installer is located
+                    in <filename>~/Downloads/</filename>.
                     <literallayout class='monospaced'>
-     $ ~/Downloads/poky-eglibc-x86_64-i586-toolchain-gmae-&DISTRO;.sh
+     $ ~/Downloads/poky-eglibc-x86_64-core-image-sato-i586.sh
                     </literallayout>
                     <note>
-                        If you do not have write permissions for the directory into which you are installing
-                        the toolchain, the toolchain installer notifies you and exits.
-                        Be sure you have write permissions in the directory and run the installer again.
+                        If you do not have write permissions for the directory
+                        into which you are installing the toolchain, the
+                        toolchain installer notifies you and exits.
+                        Be sure you have write permissions in the directory and
+                        run the installer again.
                     </note>
-                    Once the tarball is expanded, the cross-toolchain is installed.
-                    You will notice environment setup files for the cross-toolchain in the directory.
-                    </para></listitem>
+                    Once the tarball is expanded, the cross-toolchain is
+                    installed.
+                    You will notice environment setup files for the
+                    cross-toolchain in the directory.</para></listitem>
             </orderedlist>
         </para>
     </section>
@@ -537,6 +520,54 @@
     </section>
 </section>
 
+<section id='optionally-building-a-toolchain-installer'>
+    <title>Optionally Building a Toolchain Installer</title>
+
+    <para>
+        As an alternative to locating and downloading a toolchain installer,
+        you can build the toolchain installer if you have a
+        <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+    </para>
+
+    <para>
+        You can build the toolchain
+        installer using <filename>bitbake meta-toolchain</filename>.
+        This method requires you to still install the target
+        sysroot by installing and extracting it separately.
+        For information on how to install the sysroot, see the
+        "<link linkend='extracting-the-root-filesystem'>Extracting the Root Filesystem</link>" section.
+    </para>
+
+    <para>
+        A final method of building the toolchain installer exists that has
+        significant advantages over the previous two methods.
+        This method results in a toolchain installer that contains the sysroot
+        that matches your target root filesystem.
+        To build this installer, use the
+        <filename>bitbake image -c populate_sdk</filename> command.
+    </para>
+
+    <para>
+         Remember, before using any <filename>bitbake</filename> command, you
+         must source the <filename>&OE_INIT_PATH;</filename> script located in
+         the Source Directory and you must make sure your
+         <filename>conf/local.conf</filename> variables are correct.
+         In particular, you need to be sure the
+         <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink>
+         variable matches the architecture for which you are building and that
+         the
+         <ulink url='&YOCTO_DOCS_REF_URL;#var-SDKMACHINE'><filename>SDKMACHINE</filename></ulink>
+         variable is correctly set if you are building a toolchain designed to
+         run on an architecture that differs from your current development host
+         machine (i.e. the build machine).
+     </para>
+
+     <para>
+         When the BitBake command completes, the toolchain installer will be in
+         <filename>tmp/deploy/sdk</filename> in the Build Directory.
+     </para>
+</section>
+
 </chapter>
 <!--
 vim: expandtab tw=80 ts=4

documentation/bsp-guide/bsp.xml

@@ -1243,11 +1243,11 @@
                     <literallayout class='monospaced'>
      $ yocto-bsp list karch
      Architectures available:
-         qemu
-         x86_64
-         i386
          powerpc
+         i386
+         x86_64
          arm
+         qemu
          mips
                     </literallayout>
                 </para>

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

@@ -1355,24 +1355,24 @@
             <para>
                 The most important variables to set in this file are as follows:
                 <itemizedlist>
-                    <listitem><para><filename><ulink url='&YOCTO_DOCS_REF_URL;#var-TARGET_ARCH'>
-                        TARGET_ARCH</ulink></filename> (e.g. "arm")</para></listitem>
-                    <listitem><para><filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PREFERRED_PROVIDER'>
-                        PREFERRED_PROVIDER</ulink></filename>_virtual/kernel (see below)</para></listitem>
-                    <listitem><para><filename><ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE_FEATURES'>
-                        MACHINE_FEATURES</ulink></filename> (e.g. "apm screen wifi")</para></listitem>
+                    <listitem><para><filename><ulink url='&YOCTO_DOCS_REF_URL;#var-TARGET_ARCH'>TARGET_ARCH</ulink></filename>
+                        (e.g. "arm")</para></listitem>
+                    <listitem><para><filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PREFERRED_PROVIDER'>PREFERRED_PROVIDER</ulink>_virtual/kernel</filename>
+                        (see below)</para></listitem>
+                    <listitem><para><filename><ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE_FEATURES'>MACHINE_FEATURES</ulink></filename>
+                        (e.g. "apm screen wifi")</para></listitem>
                 </itemizedlist>
             </para>
 
             <para>
                 You might also need these variables:
                 <itemizedlist>
-                    <listitem><para><filename><ulink url='&YOCTO_DOCS_REF_URL;#var-SERIAL_CONSOLE'>
-                        SERIAL_CONSOLE</ulink></filename> (e.g. "115200 ttyS0")</para></listitem>
-                    <listitem><para><filename><ulink url='&YOCTO_DOCS_REF_URL;#var-KERNEL_IMAGETYPE'>
-                        KERNEL_IMAGETYPE</ulink></filename> (e.g. "zImage")</para></listitem>
-                    <listitem><para><filename><ulink url='&YOCTO_DOCS_REF_URL;#var-IMAGE_FSTYPES'>
-                        IMAGE_FSTYPES</ulink></filename> (e.g. "tar.gz jffs2")</para></listitem>
+                    <listitem><para><filename><ulink url='&YOCTO_DOCS_REF_URL;#var-SERIAL_CONSOLES'>SERIAL_CONSOLES</ulink></filename>
+                        (e.g. "115200 ttyS0")</para></listitem>
+                    <listitem><para><filename><ulink url='&YOCTO_DOCS_REF_URL;#var-KERNEL_IMAGETYPE'>KERNEL_IMAGETYPE</ulink></filename>
+                        (e.g. "zImage")</para></listitem>
+                    <listitem><para><filename><ulink url='&YOCTO_DOCS_REF_URL;#var-IMAGE_FSTYPES'>IMAGE_FSTYPES</ulink></filename>
+                        (e.g. "tar.gz jffs2")</para></listitem>
                 </itemizedlist>
             </para>
 
@@ -3465,7 +3465,7 @@
 
             <para>
                 Following are the steps to set up the optional repository.
-                This examples assumes you are using RPM and the Apache 2
+                This example assumes you are using RPM and the Apache 2
                 server:
                 <orderedlist>
                     <listitem><para>
@@ -3496,7 +3496,7 @@
                         <literallayout class='monospaced'>
      service httpd reload
                         </literallayout>
-                        For Ubuntu, use the following:
+                        For Ubuntu and Debian, use the following:
                         <literallayout class='monospaced'>
      /etc/init.d/apache2 reload
                         </literallayout>
@@ -3619,8 +3619,8 @@
                     which is found in the
                     <link linkend='build-directory'>Build Directory</link>:
                     <literallayout class='monospaced'>
-     EXTRA_IMAGE_FEATURES += "ptest"
-     DISTRO_FEATURES_append = " ptest-pkgs"
+     DISTRO_FEATURES_append = " ptest"
+     EXTRA_IMAGE_FEATURES += "ptest-pkgs"
                     </literallayout>
                     Once your build is complete, the ptest files are installed
                     into the <filename>/usr/lib/&lt;package&gt;/ptest</filename>
@@ -3749,54 +3749,58 @@
         <title>Building Software from an External Source</title>
 
         <para>
-            By default, the OpenEmbedded build system does its work from within the
-            <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.
+            By default, the OpenEmbedded build system uses the
+            <link linkend='build-directory'>Build Directory</link> to
+            build source code.
+            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>.
-            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.
+            Situations exist where you might want to build software from source
+            files that are external to and thus outside of the
+            OpenEmbedded build system.
+            For example, suppose you have a project that includes a new BSP with
+            a heavily customized kernel.
             And, you want to minimize exposing the build system to the
-            development team so that they can focus on their project and maintain everyone's workflow
-            as much as possible.
-            In this case, you want a kernel source directory on the development machine where the
-            development occurs.
+            development team so that they can focus on their project and
+            maintain everyone's workflow as much as possible.
+            In this case, you want a kernel source directory on the development
+            machine where the development occurs.
             You want the recipe's
             <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
-            variable to point to the external directory and use it as is, not copy it.
+            variable to point to the external directory and use it as is, not
+            copy it.
         </para>
 
         <para>
-            To build from software that comes from an external source, all you need to do is
-            change your recipe so that it inherits the
+            To build from software that comes from an external source, all you
+            need to do is inherit
             <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-externalsrc'><filename>externalsrc.bbclass</filename></ulink>
-            class and then sets the
-            <ulink url='&YOCTO_DOCS_REF_URL;#var-S'><filename>S</filename></ulink>
+            and then set the
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-EXTERNALSRC'><filename>EXTERNALSRC</filename></ulink>
             variable to point to your external source code.
-            Here are the statements to put in your recipe:
+            Here are the statements to put in your
+            <filename>local.conf</filename> file:
             <literallayout class='monospaced'>
-     inherit externalsrc
-     S = "/some/path/to/your/package/source"
+     INHERIT += "externalsrc"
+     EXTERNALSRC_pn-myrecipe = "/some/path/to/your/source/tree"
             </literallayout>
         </para>
 
         <para>
-            It is important to know that the <filename>externalsrc.bbclass</filename> assumes that the
-            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 these directories are the same by default.
-            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
-            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.
+            By default, <filename>externalsrc.bbclass</filename> builds
+            the source code in a directory separate from the external source
+            directory as specified by
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-EXTERNALSRC'><filename>EXTERNALSRC</filename></ulink>.
+            If you need to have the source built in the same directory in
+            which it resides, or some other nominated directory, you can set
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-EXTERNALSRC_BUILD'><filename>EXTERNALSRC_BUILD</filename></ulink>
+            to point to that directory:
+            <literallayout class='monospaced'>
+     EXTERNALSRC_BUILD_pn-myrecipe = "/path/to/my/source/tree"
+            </literallayout>
         </para>
     </section>
 
@@ -4319,6 +4323,191 @@
         </section>
     </section>
 
+    <section id="examining-builds-using-toaster">
+        <title>Examining Builds using Toaster</title>
+
+        <para>
+            Toaster is a Web-based interface to the OpenEmbedded build system,
+            which uses BitBake.
+            Toaster offers features to record and analyze BitBake runs applied
+            to a specific target.
+            Using Toaster, you can do the following:
+            <itemizedlist>
+                <listitem><para>See information about the tasks executed
+                    and reused during the build.</para></listitem>
+                <listitem><para>See what is built (recipes and
+                    packages) and what packages were installed into the final
+                    image.</para></listitem>
+                <listitem><para>See performance-related information such
+                    as build time, CPU usage, and disk I/O.</para></listitem>
+                <listitem><para>Examine error, warning and trace messages
+                    to aid in debugging.</para></listitem>
+            </itemizedlist>
+        </para>
+
+        <note>
+            <para>This release of Toaster provides you with information
+            about a BitBake run.
+            The tool does not allow you to configure and launch a build.
+            Future development includes plans to integrate the data examination
+            features of Toaster with the configuration and build launching
+            capabilities of
+            <ulink url='&YOCTO_HOME_URL;/tools-resources/projects/hob'>Hob</ulink>.
+            </para>
+            <para>For more information on using Hob to build an image,
+            see the
+            "<link linkend='image-development-using-hob'>Image Development Using Hob</link>"
+            section.</para>
+        </note>
+
+        <section id='starting-toaster'>
+            <title>Starting Toaster</title>
+
+            <para>
+                Getting set up to use and start Toaster is simple.
+                First, be sure you have met the following requirements:
+                <itemizedlist>
+                    <listitem><para>You have set up your
+                        <link linkend='source-directory'>Source Directory</link>.
+                        See the
+                        <link linkend='local-yp-release'>Yocto Project Release</link>
+                        item for information on how to set up the Source
+                        Directory.</para></listitem>
+                    <listitem><para>Be sure your build machine has
+                        <ulink url='http://en.wikipedia.org/wiki/Django_%28web_framework%29'>Django</ulink>
+                        version 1.4 or greater installed.</para></listitem>
+                </itemizedlist>
+            </para>
+
+            <para>
+                Once you have met the requirements, follow these steps to
+                start Toaster running in the background of your shell:
+                <orderedlist>
+                    <listitem><para>Set up your build environment by sourcing
+                        the <filename>oe-init-build-env</filename> script.
+                        </para></listitem>
+                    <listitem><para>Edit your <filename>local.conf</filename>
+                        configuration file as needed.</para></listitem>
+                    <listitem><para>Start the Toaster service using this
+                        command from within your build directory:
+                        <literallayout class='monospaced'>
+     $ source toaster start
+                        </literallayout></para></listitem>
+                        <note>
+                            The Toaster must be started and running in order
+                            for it to collect data.
+                        </note>
+                </orderedlist>
+            </para>
+
+            <para>
+                When Toaster starts, it creates some additional files in your
+                Build Directory.
+                Deleting these files will cause you to lose data or interrupt
+                Toaster:
+                <itemizedlist>
+                    <listitem><para><emphasis><filename>toaster.sqlite</filename>:</emphasis>
+                        Toaster's database file.</para></listitem>
+                    <listitem><para><emphasis><filename>tstmain.log</filename>:</emphasis>
+                        Toaster's log file.</para></listitem>
+                    <listitem><para><emphasis><filename>tstmain.pid</filename>:</emphasis>
+                        Contains the PID of the web server.</para></listitem>
+                    <listitem><para><emphasis><filename>dsi.pid</filename>:</emphasis>
+                        Contains the PID of th bridge.</para></listitem>
+                    <listitem><para><emphasis><filename>bitbake-cookerdaemon.log</filename>:</emphasis>
+                        The BitBake server's log file.</para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
+        <section id='using-toaster'>
+            <title>Using Toaster</title>
+
+            <para>
+                Once Toaster is running, it logs information for any BitBake
+                run from your Build Directory.
+                This logging is automatic.
+                All you need to do is access and use the information.
+            </para>
+
+            <para>
+                You access the information one of two ways:
+                <itemizedlist>
+                    <listitem><para>Open a Browser and type enter in the
+                        <filename>http://localhost:8000</filename> URL.
+                        </para></listitem>
+                    <listitem><para>Use the <filename>xdg-open</filename>
+                        tool from the shell and pass it the same URL.
+                        </para></listitem>
+                </itemizedlist>
+                Either method opens the home page for the Toaster interface.
+            </para>
+        </section>
+
+        <section id='examining-toaster-data'>
+            <title>Examining Toaster Data</title>
+
+            <para>
+                The Toaster database is persistent regardless of whether you
+                start or stop the service.
+            </para>
+
+            <para>
+                Toaster's interface shows you a list of builds
+                (successful and unsuccessful) for which it has data.
+                You can click on any build to see related information.
+                This information includes configuration details, information
+                about tasks, all recipes and packages built and their
+                dependencies, packages installed in your final image,
+                execution time, CPU usage and disk I/O per task.
+            </para>
+
+<!--
+                The home page of the interface into the database organizes
+                builds into areas:
+                <itemizedlist>
+                    <listitem><para>Recent successful builds, which appear
+                        in row format in a green area.</para></listitem>
+                    <listitem><para>Recent failed builds, which appear
+                        in row format in a red area.</para></listitem>
+                    <listitem><para>Recent builds in progress, which appear
+                        in row format in a yellow area.</para></listitem>
+                    <listitem><para>All builds, which appear in row format at
+                        the end of the page.</para></listitem>
+                </itemizedlist>
+            <para>
+                Each entry is linked to more detail on the particular build
+                or recipe.
+                You can click on the links to learn more information.
+            </para>
+
+            <para>
+                When you click on a failed recipe link, you can find out
+                information such as the work directory, the pathname to the
+                failing recipe, the exact error message, and precursor tasks.
+            </para>
+
+            <para>
+                Clicking on a successful build provides you with configuration,
+                task, and package information along with directory structure,
+                build time, CPU usage, and disk I/O information.
+            </para>
+-->
+        </section>
+
+        <section id='stopping-toaster'>
+            <title>Stopping Toaster</title>
+
+            <para>
+                Stop the Toaster service with the following command:
+                <literallayout class='monospaced'>
+     $ source toaster stop
+                </literallayout>
+                The service stops but the Toaster database remains persistent.
+            </para>
+        </section>
+    </section>
+
     <section id="platdev-oprofile">
         <title>Profiling with OProfile</title>
 

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

@@ -1,553 +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-kernel-appendix'>
-
-<title>Kernel Modification Example</title>
-
-    <para>
-        Kernel modification 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.
-        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'>
-        <title>Modifying the Kernel Source Code</title>
-
-        <para>
-            This example adds some simple QEMU emulator console output at boot time by
-            adding <filename>printk</filename> statements to the kernel's
-            <filename>calibrate.c</filename> source code file.
-            Booting the modified image causes the added messages to appear on the emulator's
-            console.
-        </para>
-
-        <section id='understanding-the-files-you-need'>
-            <title>Understanding the Files You Need</title>
-
-            <para>
-                Before you modify the kernel, you need to know what Git repositories and file
-                structures you need.
-                Briefly, you need the following:
-                <itemizedlist>
-                    <listitem><para>A local
-                        <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>
-                    <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.
-                        </para></listitem>
-                    <listitem><para>A copy of that bare clone in which you make your source
-                        modifications</para></listitem>
-                </itemizedlist>
-            </para>
-
-            <para>
-                The following figure summarizes these four areas.
-                Within each rectangular that represents a data structure, a
-                host development directory pathname appears at the
-                lower left-hand corner of the box.
-                These pathnames are the locations used in this example.
-                The figure also provides key statements and commands used during the kernel
-                modification process:
-            </para>
-
-            <para>
-                <imagedata fileref="figures/kernel-example-repos-generic.png" width="7in" depth="5in"
-                    align="center" scale="100" />
-            </para>
-
-            <para>
-                Here is a brief description of the four areas:
-                <itemizedlist>
-                    <listitem><para><emphasis>Local Source Directory:</emphasis>
-                        This area contains all the metadata that supports building images
-                        using the OpenEmbedded build system.
-                        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
-                        <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&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
-                        local kernel source files and to identify the kernel being built.
-                        This Git repository is a gathering place for extensions to the Yocto Project
-                        (or really any) kernel recipes that faciliate the creation and development
-                        of kernel features, BSPs or configurations.</para>
-                        <para>See the bulleted item
-                        "<link linkend='poky-extras-repo'>The
-                        <filename>poky-extras</filename> Git Repository</link>"
-                        for information on how to get these files.</para></listitem>
-                    <listitem><para><emphasis>Bare Clone of the Yocto Project kernel:</emphasis>
-                        This bare Git repository tracks the upstream Git repository of the Linux
-                        Yocto kernel source code you are changing.
-                        When you modify the kernel you must work through a bare clone.
-                        All source code changes you make to the kernel must be committed and
-                        pushed to the bare clone using Git commands.
-                        As mentioned, the <filename>.bbappend</filename> file in the
-                        <filename>poky-extras</filename> repository points to the bare clone
-                        so that the build process can locate the locally changed source files.</para>
-                        <para>See the bulleted item
-                        "<link linkend='local-kernel-files'>Yocto Project Kernel</link>"
-                        for information on how to set up the bare clone.
-                        </para></listitem>
-                    <listitem><para><emphasis>Copy of the Yocto Project Kernel Bare Clone:</emphasis>
-                        This Git repository contains the actual source files that you modify.
-                        Any changes you make to files in this location need to ultimately be pushed
-                        to the bare clone using the <filename>git push</filename> command.</para>
-                        <para>See the bulleted item
-                        "<link linkend='local-kernel-files'>Yocto Project Kernel</link>"
-                        for information on how to set up the bare clone.
-                        <note>Typically, Git workflows follow a scheme where changes made to a local area
-                        are pulled into a Git repository.
-                        However, because the <filename>git pull</filename> command does not work
-                        with bare clones, this workflow pushes changes to the
-                        repository even though you could use other more complicated methods to
-                        get changes into the bare clone.</note>
-                        </para></listitem>
-                </itemizedlist>
-            </para>
-        </section>
-
-        <section id='setting-up-the-local-yocto-project-files-git-repository'>
-            <title>Setting Up the Local Source Directory</title>
-
-            <para>
-                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.
-                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,
-                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:
-                <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>
-        </section>
-
-        <section id='setting-up-the-poky-extras-git-repository'>
-            <title>Setting Up the Local poky-extras Git Repository</title>
-
-            <para>
-                This example creates a local copy of the <filename>poky-extras</filename> Git
-                repository inside the <filename>poky</filename> Source Directory.
-                See the bulleted item "<link linkend='poky-extras-repo'>The
-                <filename>poky-extras</filename> Git Repository</link>"
-                for information on how to set up a local copy of the
-                <filename>poky-extras</filename> repository.
-            </para>
-
-            <para>
-                Because this example uses the Yocto Project &DISTRO; Release code
-                named "&DISTRO_NAME;", which maps to the <filename>&DISTRO_NAME;</filename>
-                branch in the repository, you need to be sure you are using that
-                branch for <filename>poky-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;'
-                </literallayout>
-            </para>
-        </section>
-
-        <section id='setting-up-the-bare-clone-and-its-copy'>
-            <title>Setting Up the Bare Clone and its Copy</title>
-
-            <para>
-                This example modifies the <filename>linux-yocto-3.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
-                "<link linkend='local-kernel-files'>Yocto Project Kernel</link>"
-                for information on how to do that.
-            </para>
-
-            <para>
-                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.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.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>
-
-        <section id='building-and-booting-the-default-qemu-kernel-image'>
-            <title>Building and Booting the Default QEMU Kernel Image</title>
-
-            <para>
-                Before we make changes to the kernel source files, this example first builds the
-                default image and then boots it inside the QEMU emulator.
-                <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_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
-                    <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 <filename>BB_NUMBER_THREADS</filename> and
-                    <filename>PARALLEL_MAKE</filename> 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_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.
-
-     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/
-
-     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
-         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>
-
-            <para>
-                After the build completes, you can start the QEMU emulator using the resulting image
-                <filename>qemux86</filename> as follows:
-                <literallayout class='monospaced'>
-     $ runqemu qemux86
-                </literallayout>
-            </para>
-
-            <para>
-                As the image boots in the emulator, console message and status output appears
-                across the terminal window.
-                Because the output scrolls by quickly, it is difficult to read.
-                To examine the output, you log into the system using the
-                login <filename>root</filename> with no password.
-                Once you are logged in, issue the following command to scroll through the
-                console output:
-                <literallayout class='monospaced'>
-     # dmesg | less
-                </literallayout>
-            </para>
-
-            <para>
-                Take note of the output as you will want to look for your inserted print command output
-                later in the example.
-            </para>
-        </section>
-
-        <section id='changing-the-source-code-and-pushing-it-to-the-bare-clone'>
-            <title>Changing the Source Code and Pushing it to the Bare Clone</title>
-
-            <para>
-                The file you change in this example is named <filename>calibrate.c</filename>
-                and is located in the <filename>my-linux-yocto-3.4-work</filename> Git repository
-                (the copy of the bare clone) in <filename>init</filename>.
-                This example simply inserts several <filename>printk</filename> statements
-                at the beginning of the <filename>calibrate_delay</filename> function.
-            </para>
-
-            <para>
-                Here is the unaltered code at the start of this function:
-                <literallayout class='monospaced'>
-     void __cpuinit calibrate_delay(void)
-     {
-     	unsigned long lpj;
-     	static bool printed;
-     	int this_cpu = smp_processor_id();
-
-     	if (per_cpu(cpu_loops_per_jiffy, this_cpu)) {
-               .
-               .
-               .
-               </literallayout>
-           </para>
-
-           <para>
-               Here is the altered code showing five new <filename>printk</filename> statements
-               near the top of the function:
-                <literallayout class='monospaced'>
-     void __cpuinit calibrate_delay(void)
-     {
-         unsigned long lpj;
-         static bool printed;
-         int this_cpu = smp_processor_id();
-
-         printk("*************************************\n");
-         printk("*                                   *\n");
-         printk("*        HELLO YOCTO KERNEL         *\n");
-         printk("*                                   *\n");
-         printk("*************************************\n");
-
-     	if (per_cpu(cpu_loops_per_jiffy, this_cpu)) {
-               .
-               .
-               .
-               </literallayout>
-           </para>
-
-           <para>
-               After making and saving your changes, you need to stage them for the push.
-               The following Git commands are one method of staging and committing your changes:
-               <literallayout class='monospaced'>
-     $ git add calibrate.c
-     $ git commit --signoff
-               </literallayout>
-           </para>
-
-           <para>
-               Once the source code has been modified, you need to use Git to push the changes to
-               the bare clone.
-               If you do not push the changes, then the OpenEmbedded build system will not pick
-               up the changed source files.
-           </para>
-
-           <para>
-               The following command pushes the changes to the bare clone:
-               <literallayout class='monospaced'>
-     $ git push origin standard-common-pc-base:standard/default/common-pc/base
-               </literallayout>
-           </para>
-       </section>
-
-       <section id='changing-build-parameters-for-your-build'>
-           <title>Changing Build Parameters for Your Build</title>
-
-           <para>
-               At this point, the source has been changed and pushed.
-               The example now defines some variables used by the OpenEmbedded build system
-               to locate your kernel source.
-               You essentially need to identify where to find the kernel recipe and the changed source code.
-               You also need to be sure some basic configurations are in place that identify the
-               type of machine you are building and to help speed up the build should your host support
-               multiple-core and thread capabilities.
-           </para>
-
-           <para>
-               Do the following to make sure the build parameters are set up for the example.
-               Once you set up these build parameters, they do not have to change unless you
-               change the target architecture of the machine you are building or you move
-               the bare clone, copy of the clone, or the <filename>poky-extras</filename> repository:
-               <itemizedlist>
-                   <listitem><para><emphasis>Build for the Correct Target Architecture:</emphasis> The
-                       <filename>local.conf</filename> file in the build directory defines the build's
-                       target architecture.
-                       By default, <filename>MACHINE</filename> is set to
-                       <filename>qemux86</filename>, which specifies a 32-bit
-                       <trademark class='registered'>Intel</trademark> Architecture
-                       target machine suitable for the QEMU emulator.
-                       In this example, <filename>MACHINE</filename> is correctly configured.
-                       </para></listitem>
-                   <listitem><para><emphasis>Optimize Build Time:</emphasis> Also in the
-                       <filename>local.conf</filename> file are two variables that can speed your
-                       build time if your host supports multi-core and multi-thread capabilities:
-                       <filename>BB_NUMBER_THREADS</filename> and <filename>PARALLEL_MAKE</filename>.
-                       If the host system has multiple cores then you can optimize build time
-                       by setting both these variables to twice the number of
-                       cores.</para></listitem>
-                   <listitem><para><emphasis>Identify Your <filename>meta-kernel-dev</filename>
-                       Layer:</emphasis> The <filename>BBLAYERS</filename> variable in the
-                       <filename>bblayers.conf</filename> file found in the
-                       <filename>poky/build/conf</filename> directory needs to have the path to your local
-                       <filename>meta-kernel-dev</filename> layer.
-                       By default, the <filename>BBLAYERS</filename> variable contains paths to
-                       <filename>meta</filename> and <filename>meta-yocto</filename> in the
-                       <filename>poky</filename> Git repository.
-                       Add the path to your <filename>meta-kernel-dev</filename> location.
-                       Be sure to substitute your user information in the statement.
-                       Here is an example:
-                       <literallayout class='monospaced'>
-     BBLAYERS = " \
-       /home/scottrif/poky/meta \
-       /home/scottrif/poky/meta-yocto \
-       /home/scottrif/poky/meta-yocto-bsp \
-       /home/scottrif/poky/poky-extras/meta-kernel-dev \
-       "
-                       </literallayout></para></listitem>
-                   <listitem><para><emphasis>Identify Your Source Files:</emphasis> In the
-                       <filename>linux-yocto_3.4.bbappend</filename> file located in the
-                       <filename>poky-extras/meta-kernel-dev/recipes-kernel/linux</filename>
-                       directory, you need to identify the location of the
-                       local source code, which in this example is the bare clone named
-                       <filename>linux-yocto-3.4.git</filename>.
-                       To do this, set the <filename>KSRC_linux_yocto</filename> variable to point to your
-                       local <filename>linux-yocto-3.4.git</filename> Git repository by adding the
-                       following statement.
-                       Also, be sure the <filename>SRC_URI</filename> variable is pointing to
-                       your kernel source files by removing the comment.
-                       Finally, be sure to substitute your user information in the statement:
-                       <literallayout class='monospaced'>
-     KSRC_linux_yocto_3_4 ?= "/home/scottrif/linux-yocto-3.4.git"
-     SRC_URI = "git://${KSRC_linux_yocto_3_4};protocol=file;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"
-                       </literallayout></para></listitem>
-               </itemizedlist>
-           </para>
-
-           <note>
-               <para>Before attempting to build the modified kernel, there is one more set of changes you
-               need to make in the <filename>meta-kernel-dev</filename> layer.
-               Because all the kernel <filename>.bbappend</filename> files are parsed during the
-               build process regardless of whether you are using them or not, you should either
-               comment out the <filename>COMPATIBLE_MACHINE</filename> statements in all
-               unused <filename>.bbappend</filename> files, or simply remove (or rename) all the files
-               except the one your are using for the build
-               (i.e. <filename>linux-yocto_3.4.bbappend</filename> in this example).</para>
-               <para>If you do not make one of these two adjustments, your machine will be compatible
-               with all the kernel recipes in the <filename>meta-kernel-dev</filename> layer.
-               When your machine is comapatible with all the kernel recipes, the build attempts
-               to build all kernels in the layer.
-               You could end up with build errors blocking your work.</para>
-           </note>
-       </section>
-
-        <section id='building-and-booting-the-modified-qemu-kernel-image'>
-            <title>Building and Booting the Modified QEMU Kernel Image</title>
-
-            <para>
-                Next, you need to build the modified image.
-                Do the following:
-                <orderedlist>
-                    <listitem><para>Your environment should be set up since you previously sourced
-                        the <filename>&OE_INIT_FILE;</filename> script.
-                        If it isn't, source the script again from <filename>poky</filename>.
-                        <literallayout class='monospaced'>
-     $ cd ~/poky
-     $ source &OE_INIT_FILE;
-                        </literallayout>
-                        </para></listitem>
-                    <listitem><para>Be sure old images are cleaned out by running the
-                        <filename>cleanall</filename> BitBake task as follows from your build directory:
-                        <literallayout class='monospaced'>
-     $ bitbake -c cleanall linux-yocto
-                        </literallayout></para>
-                        <para><note>Never remove any files by hand from the <filename>tmp/deploy</filename>
-                        directory insided the build directory.
-                        Always use the BitBake <filename>cleanall</filename> task to clear
-                        out previous builds.</note></para></listitem>
-                    <listitem><para>Next, build the kernel image using this command:
-                        <literallayout class='monospaced'>
-     $ bitbake -k core-image-minimal
-                        </literallayout></para></listitem>
-                    <listitem><para>Finally, boot the modified image in the QEMU emulator
-                        using this command:
-                        <literallayout class='monospaced'>
-     $ runqemu qemux86
-                        </literallayout></para></listitem>
-                </orderedlist>
-            </para>
-
-            <para>
-                Log into the machine using <filename>root</filename> with no password and then
-                use the following shell command to scroll through the console's boot output.
-                <literallayout class='monospaced'>
-     # dmesg | less
-                </literallayout>
-            </para>
-
-            <para>
-                You should see the results of your <filename>printk</filename> statements
-                as part of the output.
-            </para>
-        </section>
-    </section>
-</appendix>
-
-<!--
-vim: expandtab tw=80 ts=4
--->

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

@@ -444,14 +444,14 @@
     <para>
         In summary, here is where you can get the project files needed for development:
         <itemizedlist>
-            <listitem><para id='source-repositories'>:S<emphasis><ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi'>Source Repositories:</ulink></emphasis>
+            <listitem><para id='source-repositories'><emphasis><ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi'>Source Repositories:</ulink></emphasis>
                 This area contains IDE Plugins, Matchbox, Poky, Poky Support, Tools, Yocto Linux Kernel, and Yocto
                 Metadata Layers.
                 You can create local copies of Git repositories for each of these areas.</para>
                 <para>
                 <imagedata fileref="figures/source-repos.png" align="center" width="6in" depth="4in" />
                 </para></listitem>
-            <listitem><para><anchor id='index-downloads' />:<emphasis><ulink url='&YOCTO_DL_URL;/releases/'>Index of /releases:</ulink></emphasis>
+            <listitem><para><anchor id='index-downloads' /><emphasis><ulink url='&YOCTO_DL_URL;/releases/'>Index of /releases:</ulink></emphasis>
                 This area contains index releases such as
                 the <trademark class='trade'>Eclipse</trademark>
                 Yocto Plug-in, miscellaneous support, poky, pseudo, installers for cross-development toolchains,
@@ -566,59 +566,40 @@
                 </para></listitem>
             <listitem><para id='cross-development-toolchain'>
                 <emphasis>Cross-Development Toolchain:</emphasis>
-                A collection of software development
-                tools and utilities that allow you to develop software for
-                targeted architectures.
-                This toolchain contains cross-compilers, linkers, and debuggers
-                that are specific to an architecture.
-                You can use the OpenEmbedded build system to build a
-                cross-development toolchain installer that, when run, installs
-                the toolchain that contains the development tools you
-                need to cross-compile and test your software.
-                The Yocto Project ships with images that contain installers for
-                toolchains for supported architectures as well.
-                Sometimes this toolchain is referred to as the
-                meta-toolchain.</para>
-                <para>Following is a list of toolchain recipes with brief
-                descriptions of each:
-                <itemizedlist>
-                    <listitem><para><filename>gcc-cross-initial</filename>:
-                        The initial compiler needed to bootstrap the toolchain
-                        that runs on the host and is used to build software
-                        for the target.
-                        This tool is a "native" package.</para></listitem>
-                    <listitem><para><filename>gcc-cross-intermediate</filename>:
-                        The second stage of the bootstrap process that runs
-                        on the host and builds software for the target.
-                        This tool is a "native" package.</para></listitem>
-                    <listitem><para><filename>gcc-cross</filename>:
-                        The the final stage of the bootstrap process that
-                        results in the cross compiler that runs on the host
-                        and builds software for the target.
-                        If you are replacing the cross compiler toolchain
-                        with a custom version, this is what you must replace.
-                        This tool is a "native" package.</para></listitem>
-                    <listitem><para><filename>gcc-runtime</filename>:
-                        Runtime libraries from the toolchain bootstrapping
-                        process.
-                        This tool produces a binary for the target.
-                        </para></listitem>
-                    <listitem><para><filename>gcc-crosssdk-initial/intermediate</filename>:
-                        Stage 1 and 2 of the a cross compiler that runs on the
-                        host and builds for the SDK.
-                        Often the SDK is not the same target as the host.
-                        This tool is a "native" binary.</para></listitem>
-                    <listitem><para><filename>gcc-crosssdk</filename>:
-                        The final stage of the SDK compiler.
-                        This tool is a "native" binary.
-                        The tool runs on the host and builds for the SDK.
-                        </para></listitem>
-                    <listitem><para><filename>gcc-cross-canadian</filename>:
-                        The compiler that runs on the SDK machine and is
-                        included with the SDK that builds software for the
-                        target.
-                        This tool is a "nativesdk" package.</para></listitem>
-                </itemizedlist></para></listitem>
+                    In general, a cross-development toolchain is a collection of
+                    software development tools and utilities that run on one
+                    architecture and allow you to develop software for a
+                    different, or targeted, architecture.
+                    These toolchains contain cross-compilers, linkers, and
+                    debuggers that are specific to the target architecture.
+                </para>
+
+                <para>The Yocto Project supports two different cross-development
+                    toolchains:
+                    <itemizedlist>
+                        <listitem><para>A toolchain only used by and within
+                            BitBake when building an image for a target
+                            architecture.</para></listitem>
+                        <listitem><para>A relocatable toolchain used outside of
+                            BitBake by developers when developing applications
+                            that will run on a targeted device.
+                            Sometimes this relocatable cross-development
+                            toolchain is referred to as the meta-toolchain.
+                            </para></listitem>
+                    </itemizedlist>
+                </para>
+
+                <para>
+                    Creation of these toolchains is simple and automated.
+                    For information on toolchain concepts as they apply to the
+                    Yocto Project, see the
+                    "<ulink url='&YOCTO_DOCS_REF_URL;#cross-development-toolchain-generation'>Cross-Development Toolchain Generation</ulink>"
+                    section in the Yocto Project Reference Manual.
+                    You can also find more information on using the
+                    relocatable toolchain in the
+                    <ulink url='&YOCTO_DOCS_ADT_URL;'>Yocto Project
+                    Application Developer's Guide</ulink>.
+                </para></listitem>
             <listitem><para><emphasis>Image:</emphasis> An image is the result produced when
                 BitBake processes a given collection of recipes and related Metadata.
                 Images are the binary output that run on specific hardware or QEMU
@@ -630,7 +611,12 @@
                 a BSP, or an application stack.
                 For a discussion on BSP Layers, see the
                 "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-layers'>BSP Layers</ulink>"
-                section in the Yocto Project Board Support Packages (BSP) Developer's Guide.</para></listitem>
+                section in the Yocto Project Board Support Packages (BSP)
+                Developer's Guide.</para></listitem>
+            <listitem><para id='meta-toochain'><emphasis>Meta-Toolchain:</emphasis>
+                A term sometimes used for
+                <link linkend='cross-development-toolchain'>Cross-Development Toolchain</link>.
+                </para></listitem>
             <listitem><para id='metadata'><emphasis>Metadata:</emphasis>
                 The files that BitBake parses when building an image.
                 In general, Metadata includes recipes, classes, and
@@ -782,7 +768,7 @@
         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
-        <filename>tmp/deploy/images/licenses</filename>.
+        <filename>tmp/deploy/licenses</filename>.
     </para>
 
     <para>
@@ -1419,7 +1405,7 @@
                 references - any commit that addresses a specific bug should include the
                 bug ID in the description (typically at the beginning) as follows:
                 <literallayout class='monospaced'>
-     Fixes YOCTO #&lt;bug-id&gt;
+     [YOCTO #&lt;bug-id&gt;]
 
      &lt;detailed description of change&gt;
                 </literallayout></para></listitem>
@@ -1551,7 +1537,7 @@
                     <filename>git send-email</filename> command.
                     <note>In order to use <filename>git send-email</filename>, you must have the
                     the proper Git packages installed.
-                    For Ubuntu and Fedora the package is <filename>git-email</filename>.</note></para>
+                    For Ubuntu, Debian, and Fedora the package is <filename>git-email</filename>.</note></para>
                     <para>The <filename>git send-email</filename> command sends email by using a local
                     or remote Mail Transport Agent (MTA) such as
                     <filename>msmtp</filename>, <filename>sendmail</filename>, or through a direct

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

@@ -72,10 +72,10 @@
             <listitem><para><emphasis>Packages:</emphasis>  The OpenEmbedded build system
                 requires certain packages exist on your development system (e.g. Python 2.6 or 2.7).
                 See "<ulink url='&YOCTO_DOCS_QS_URL;#packages'>The Packages</ulink>"
-                section in the Yocto Project Quick Start and the 
+                section in the Yocto Project Quick Start and 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 for the exact 
-                package requirements and the installation commands to install 
+                section in the Yocto Project Reference Manual for the exact
+                package requirements and the installation commands to install
                 them for the supported distributions.
                 </para></listitem>
             <listitem id='local-yp-release'><para><emphasis>Yocto Project Release:</emphasis>
@@ -88,14 +88,14 @@
                     hierarchical set of files as the "Source Directory."
                 </note>
                 <itemizedlist>
-                    <listitem><para><emphasis>Tarball Extraction:</emphasis>  
-                        If you are not going to contribute back into the Yocto 
-                        Project, you can simply go to the 
-                        <ulink url='&YOCTO_HOME_URL;'>Yocto Project Website</ulink>, 
+                    <listitem><para><emphasis>Tarball Extraction:</emphasis>
+                        If you are not going to contribute back into the Yocto
+                        Project, you can simply go to the
+                        <ulink url='&YOCTO_HOME_URL;'>Yocto Project Website</ulink>,
                         select the "Downloads" tab, and choose what you want.
-                        Once you have the tarball, just extract it into a 
+                        Once you have the tarball, just extract it into a
                         directory of your choice.</para>
-                        <para>For example, the following command extracts the 
+                        <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
                         with a top-level folder named <filename>&YOCTO_POKY;</filename>:
@@ -126,7 +126,7 @@
      remote: Compressing objects: 100% (47428/47428), done.
      remote: Total 183981 (delta 132271), reused 183703 (delta 132044)
      Receiving objects: 100% (183981/183981), 89.71 MiB | 2.93 MiB/s, done.
-     Resolving deltas: 100% (132271/132271), done.   
+     Resolving deltas: 100% (132271/132271), done.
                         </literallayout></para>
                         <para>For another example of how to set up your own local Git repositories, see this
                         <ulink url='&YOCTO_WIKI_URL;/wiki/Transcript:_from_git_checkout_to_meta-intel_BSP'>
@@ -168,9 +168,9 @@
      Cloning into 'my-linux-yocto-3.8-work'...
      done.
                 </literallayout></para></listitem>
-            <listitem id='poky-extras-repo'><para><emphasis>
-                The <filename>poky-extras</filename> Git Repository</emphasis>:
-                The <filename>poky-extras</filename> Git repository contains Metadata needed
+            <listitem id='meta-yocto-kernel-extras-repo'><para><emphasis>
+                The <filename>meta-yocto-kernel-extras</filename> Git Repository</emphasis>:
+                The <filename>meta-yocto-kernel-extras</filename> Git repository contains Metadata needed
                 only if you are modifying and building the kernel image.
                 In particular, it contains the kernel BitBake append (<filename>.bbappend</filename>)
                 files that you
@@ -178,17 +178,17 @@
                 image.
                 Pointing to these local files is much more efficient than requiring a download of the
                 kernel's source files from upstream each time you make changes to the kernel.</para>
-                <para>You can find the <filename>poky-extras</filename> Git Repository in the
+                <para>You can find the <filename>meta-yocto-kernel-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>
-                <para>Following is an example that creates the <filename>poky-extras</filename> Git
+                <para>Following is an example that creates the <filename>meta-yocto-kernel-extras</filename> Git
                 repository inside the Source Directory, which is named <filename>poky</filename>
                 in this case:
                 <literallayout class='monospaced'>
      $ cd ~/poky
-     $ git clone git://git.yoctoproject.org/poky-extras poky-extras
-     Cloning into 'poky-extras'...
+     $ git clone git://git.yoctoproject.org/meta-yocto-kernel-extras meta-yocto-kernel-extras
+     Cloning into 'meta-yocto-kernel-extras'...
      remote: Counting objects: 690, done.
      remote: Compressing objects: 100% (431/431), done.
      remote: Total 690 (delta 238), reused 690 (delta 238)
@@ -223,10 +223,10 @@
                 information on BSP Layers.
                 <itemizedlist>
                     <listitem><para><emphasis>Tarball Extraction:</emphasis>  You can download any released
-                        BSP tarball from the same "Downloads" page of the 
+                        BSP tarball from the same "Downloads" page of the
                         <ulink url='&YOCTO_HOME_URL;'>Yocto Project Website</ulink>
                         to get the Yocto Project release.
-                        Once on the "Download" page, look for "BSP" under the 
+                        Once on the "Download" page, look for "BSP" under the
                         "Type" heading.</para>
                         <para>Once you have the tarball, just extract it into a directory of your choice.
                         Again, this method just produces a snapshot of the BSP layer in the form

documentation/kernel-dev/kernel-dev.xml

@@ -56,7 +56,7 @@
       <note>
           Due to production processes, there could be differences between the Yocto Project
           documentation bundled in the release tarball and the
-          <ulink url='&YOCTO_DOCS_KERNEL_URL;'>Yocto Project Linux Kernel Development Manual</ulink> on
+          <ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;'>Yocto Project Linux Kernel Development Manual</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.
       </note>

documentation/kernel-manual/kernel-concepts.xml

@@ -1,392 +0,0 @@
-<!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='kernel-concepts'>
-
-<title>Yocto Project Kernel Concepts</title>
-
-<section id='concepts-org'>
-    <title>Introduction</title>
-    <para>
-        This chapter provides conceptual information about the kernel:
-        <itemizedlist>
-            <listitem><para>Kernel Goals</para></listitem>
-            <listitem><para>Kernel Development and Maintenance Overview</para></listitem>
-            <listitem><para>Kernel Architecture</para></listitem>
-            <listitem><para>Kernel Tools</para></listitem>
-        </itemizedlist>
-    </para>
-</section>
-
-    <section id='kernel-goals'>
-        <title>Kernel Goals</title>
-        <para>
-            The complexity of embedded kernel design has increased dramatically.
-            Whether it is managing multiple implementations of a particular feature or tuning and
-            optimizing board specific features, both flexibility and maintainability are key concerns.
-            The Linux kernels available through the Yocto Project are presented with the embedded
-            developer's needs in mind and have evolved to assist in these key concerns.
-            For example, prior methods such as applying hundreds of patches to an extracted
-            tarball have been replaced with proven techniques that allow easy inspection,
-            bisection and analysis of changes.
-            Application of these techniques also creates a platform for performing integration and
-            collaboration with the thousands of upstream development projects.
-        </para>
-        <para>
-            With all these considerations in mind, the Yocto Project's kernel and development team
-            strives to attain these goals:
-        <itemizedlist>
-            <listitem><para>Allow the end user to leverage community best practices to seamlessly
-            manage the development, build and debug cycles.</para></listitem>
-            <listitem><para>Create a platform for performing integration and collaboration with the
-            thousands of upstream development projects that exist.</para></listitem>
-            <listitem><para>Provide mechanisms that support many different work flows, front-ends and
-            management techniques.</para></listitem>
-            <listitem><para>Deliver the most up-to-date kernel possible while still ensuring that
-            the baseline kernel is the most stable official release.</para></listitem>
-            <listitem><para>Include major technological features as part of the Yocto Project's
-            upward revision strategy.</para></listitem>
-            <listitem><para>Present a kernel Git repository that, similar to the upstream
-            <filename>kernel.org</filename> tree,
-            has a clear and continuous history.</para></listitem>
-            <listitem><para>Deliver a key set of supported kernel types, where each type is tailored
-            to meet a specific use (e.g. networking, consumer, devices, and so forth).</para></listitem>
-            <listitem><para>Employ a Git branching strategy that, from a developer's point of view,
-            results in a linear path from the baseline <filename>kernel.org</filename>,
-            through a select group of features and
-            ends with their BSP-specific commits.</para></listitem>
-        </itemizedlist>
-        </para>
-    </section>
-
-    <section id='kernel-big-picture'>
-        <title>Yocto Project Kernel Development and Maintenance Overview</title>
-        <para>
-            Kernels available through the Yocto Project, like other kernels, are based off the Linux
-            kernel releases from <ulink url='http://www.kernel.org'></ulink>.
-            At the beginning of a major development cycle, the Yocto Project team
-            chooses its kernel based on factors such as release timing, the anticipated release
-            timing of final upstream <filename>kernel.org</filename> versions, and Yocto Project
-            feature requirements.
-            Typically, the kernel chosen is in the
-            final stages of development by the community.
-            In other words, the kernel is in the release
-            candidate or "rc" phase and not yet a final release.
-            But, by being in the final stages of external development, the team knows that the
-            <filename>kernel.org</filename> final release will clearly be within the early stages of
-            the Yocto Project development window.
-        </para>
-        <para>
-            This balance allows the team to deliver the most up-to-date kernel
-            possible, while still ensuring that the team has a stable official release for
-            the baseline Linux kernel version.
-        </para>
-        <para>
-            The ultimate source for kernels available through the Yocto Project are released kernels
-            from <filename>kernel.org</filename>.
-            In addition to a foundational kernel from <filename>kernel.org</filename>, the
-            kernels available contain a mix of important new mainline
-            developments, non-mainline developments (when there is no alternative),
-            Board Support Package (BSP) developments,
-            and custom features.
-            These additions result in a commercially released Yocto Project Linux kernel that caters
-            to specific embedded designer needs for targeted hardware.
-        </para>
-        <para>
-            Once a kernel is officially released, the Yocto Project team goes into
-            their next development cycle, or upward revision (uprev) cycle, while still
-            continuing maintenance on the released kernel.
-            It is important to note that the most sustainable and stable way
-            to include feature development upstream is through a kernel uprev process.
-            Back-porting hundreds of individual fixes and minor features from various
-            kernel versions is not sustainable and can easily compromise quality.
-        </para>
-        <para>
-            During the uprev cycle, the Yocto Project team uses an ongoing analysis of
-            kernel development, BSP support, and release timing to select the best
-            possible <filename>kernel.org</filename> version.
-            The team continually monitors community kernel
-            development to look for significant features of interest.
-            The team does consider back-porting large features if they have a significant advantage.
-            User or community demand can also trigger a back-port or creation of new
-            functionality in the Yocto Project baseline kernel during the uprev cycle.
-        </para>
-        <para>
-            Generally speaking, every new kernel both adds features and introduces new bugs.
-            These consequences are the basic properties of upstream kernel development and are
-            managed by the Yocto Project team's kernel strategy.
-            It is the Yocto Project team's policy to not back-port minor features to the released kernel.
-            They only consider back-porting significant technological jumps - and, that is done
-            after a complete gap analysis.
-            The reason for this policy is that back-porting any small to medium sized change
-            from an evolving kernel can easily create mismatches, incompatibilities and very
-            subtle errors.
-        </para>
-        <para>
-            These policies result in both a stable and a cutting
-            edge kernel that mixes forward ports of existing features and significant and critical
-            new functionality.
-            Forward porting functionality in the kernels available through the Yocto Project kernel
-            can be thought of as a "micro uprev."
-            The many “micro uprevs” produce a kernel version with a mix of
-            important new mainline, non-mainline, BSP developments and feature integrations.
-            This kernel gives insight into new features and allows focused
-            amounts of testing to be done on the kernel, which prevents
-            surprises when selecting the next major uprev.
-            The quality of these cutting edge kernels is evolving and the kernels are used in leading edge
-            feature and BSP development.
-        </para>
-    </section>
-
-    <section id='kernel-architecture'>
-        <title>Kernel Architecture</title>
-        <para>
-            This section describes the architecture of the kernels available through the
-            Yocto Project and provides information
-            on the mechanisms used to achieve that architecture.
-        </para>
-
-        <section id='architecture-overview'>
-            <title>Overview</title>
-            <para>
-                As mentioned earlier, a key goal of the Yocto Project is to present the
-                developer with
-                a kernel that has a clear and continuous history that is visible to the user.
-                The architecture and mechanisms used achieve that goal in a manner similar to the
-                upstream <filename>kernel.org</filename>.
-            </para>
-            <para>
-                You can think of a Yocto Project kernel as consisting of a baseline Linux kernel with
-                added features logically structured on top of the baseline.
-                The features are tagged and organized by way of a branching strategy implemented by the
-                source code manager (SCM) Git.
-                For information on Git as applied to the Yocto Project, see the
-                "<ulink url='&YOCTO_DOCS_DEV_URL;#git'>Git</ulink>" section in the
-                Yocto Project Development Manual.
-            </para>
-            <para>
-                The result is that the user has the ability to see the added features and
-                the commits that make up those features.
-                In addition to being able to see added features, the user can also view the history of what
-                made up the baseline kernel.
-            </para>
-            <para>
-                The following illustration shows the conceptual Yocto Project kernel.
-            </para>
-            <para>
-                <imagedata fileref="figures/kernel-architecture-overview.png" width="6in" depth="7in" align="center" scale="100" />
-            </para>
-            <para>
-                In the illustration, the "Kernel.org Branch Point"
-                marks the specific spot (or release) from
-                which the Yocto Project kernel is created.
-                From this point "up" in the tree, features and differences are organized and tagged.
-            </para>
-            <para>
-                The "Yocto Project Baseline Kernel" contains functionality that is common to every kernel
-                type and BSP that is organized further up the tree.
-                Placing these common features in the
-                tree this way means features don't have to be duplicated along individual branches of the
-                structure.
-            </para>
-            <para>
-                From the Yocto Project Baseline Kernel, branch points represent specific functionality
-                for individual BSPs as well as real-time kernels.
-                The illustration represents this through three BSP-specific branches and a real-time
-                kernel branch.
-                Each branch represents some unique functionality for the BSP or a real-time kernel.
-            </para>
-            <para>
-                In this example structure, the real-time kernel branch has common features for all
-                real-time kernels and contains
-                more branches for individual BSP-specific real-time kernels.
-                The illustration shows three branches as an example.
-                Each branch points the way to specific, unique features for a respective real-time
-                kernel as they apply to a given BSP.
-            </para>
-            <para>
-                The resulting tree structure presents a clear path of markers (or branches) to the
-                developer that, for all practical purposes, is the kernel needed for any given set
-                of requirements.
-            </para>
-        </section>
-
-        <section id='branching-and-workflow'>
-            <title>Branching Strategy and Workflow</title>
-            <para>
-                The Yocto Project team creates kernel branches at points where functionality is
-                no longer shared and thus, needs to be isolated.
-                For example, board-specific incompatibilities would require different functionality
-                and would require a branch to separate the features.
-                Likewise, for specific kernel features, the same branching strategy is used.
-            </para>
-            <para>
-                This branching strategy results in a tree that has features organized to be specific
-                for particular functionality, single kernel types, or a subset of kernel types.
-                This strategy also results in not having to store the same feature twice
-                internally in the tree.
-                Rather, the kernel team stores the unique differences required to apply the
-                feature onto the kernel type in question.
-                <note>
-                    The Yocto Project team strives to place features in the tree such that they can be
-                    shared by all boards and kernel types where possible.
-                    However, during development cycles or when large features are merged,
-                    the team cannot always follow this practice.
-                    In those cases, the team uses isolated branches to merge features.
-                </note>
-            </para>
-            <para>
-                BSP-specific code additions are handled in a similar manner to kernel-specific additions.
-                Some BSPs only make sense given certain kernel types.
-                So, for these types, the team creates branches off the end of that kernel type for all
-                of the BSPs that are supported on that kernel type.
-                From the perspective of the tools that create the BSP branch, the BSP is really no
-                different than a feature.
-                Consequently, the same branching strategy applies to BSPs as it does to features.
-                So again, rather than store the BSP twice, the team only stores the unique
-                differences for the BSP across the supported multiple kernels.
-            </para>
-            <para>
-                While this strategy can result in a tree with a significant number of branches, it is
-                important to realize that from the developer's point of view, there is a linear
-                path that travels from the baseline <filename>kernel.org</filename>, through a select
-                group of features and ends with their BSP-specific commits.
-                In other words, the divisions of the kernel are transparent and are not relevant
-                to the developer on a day-to-day basis.
-                From the developer's perspective, this path is the "master" branch.
-                The developer does not need to be aware of the existence of any other branches at all.
-                Of course, there is value in the existence of these branches
-                in the tree, should a person decide to explore them.
-                For example, a comparison between two BSPs at either the commit level or at the line-by-line
-                code <filename>diff</filename> level is now a trivial operation.
-            </para>
-            <para>
-                Working with the kernel as a structured tree follows recognized community best practices.
-                In particular, the kernel as shipped with the product, should be
-                considered an "upstream source" and viewed as a series of
-                historical and documented modifications (commits).
-                These modifications represent the development and stabilization done
-                by the Yocto Project kernel development team.
-            </para>
-            <para>
-                Because commits only change at significant release points in the product life cycle,
-                developers can work on a branch created
-                from the last relevant commit in the shipped Yocto Project kernel.
-                As mentioned previously, the structure is transparent to the developer
-                because the kernel tree is left in this state after cloning and building the kernel.
-            </para>
-        </section>
-
-        <section id='source-code-manager-git'>
-            <title>Source Code Manager - Git</title>
-            <para>
-                The Source Code Manager (SCM) is Git.
-                This SCM is the obvious mechanism for meeting the previously mentioned goals.
-                Not only is it the SCM for <filename>kernel.org</filename> but,
-                Git continues to grow in popularity and supports many different work flows,
-                front-ends and management techniques.
-            </para>
-            <para>
-                You can find documentation on Git at <ulink url='http://git-scm.com/documentation'></ulink>.
-                You can also get an introduction to Git as it applies to the Yocto Project in the
-                "<ulink url='&YOCTO_DOCS_DEV_URL;#git'>Git</ulink>"
-                section in the Yocto Project Development Manual.
-                These referenced sections overview Git and describe a minimal set of
-                commands that allows you to be functional using Git.
-                <note>
-                    You can use as much, or as little, of what Git has to offer to accomplish what
-                    you need for your project.
-                    You do not have to be a "Git Master" in order to use it with the Yocto Project.
-                </note>
-            </para>
-        </section>
-    </section>
-
-    <section id='kernel-configuration'>
-        <title>Kernel Configuration</title>
-        <para>
-            Kernel configuration, along with kernel features, defines how a kernel
-            image is built for the Yocto Project.
-            Through configuration settings, you can customize a Yocto Project kernel to be
-            specific to particular hardware.
-            For example, you can specify sound support or networking support.
-            This section describes basic concepts behind Kernel configuration within the
-            Yocto Project and references you to other areas for specific configuration
-            applications.
-        </para>
-
-        <para>
-            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 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.
-            You can also define configurations in the file by using configuration fragments.
-            <note>
-                It is not recommended that you edit the <filename>.config</filename> file directly.
-            </note>
-            Here are some brief descriptions of the ways you can affect the
-            <filename>.config</filename> file:
-            <itemizedlist>
-                <listitem><para><emphasis>The <filename>menuconfig</filename> Tool:</emphasis>
-                    One of many front-ends that allows you to define kernel configurations.
-                    Some others are <filename>make config</filename>,
-                    <filename>make nconfig</filename>, and <filename>make gconfig</filename>.
-                    In the Yocto Project environment, you must use BitBake to build the
-                    <filename>menuconfig</filename> tool before you can use it to define
-                    configurations:
-                    <literallayout class='monospaced'>
-     $ bitbake linux-yocto -c menuconfig
-                    </literallayout>
-                    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;#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>.
-                    </para></listitem>
-                <listitem><para><emphasis>Configuration Fragments:</emphasis> A file with a
-                    list of kernel options just as they would appear syntactically in the
-                    <filename>.config</filename> file.
-                    Configuration fragments are typically logical groupings and are assembled
-                    by the OpenEmbedded build system to produce input used by the LKC
-                    that ultimately generates the <filename>.config</filename> file.</para>
-                    <para>The
-                    <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-KERNEL_FEATURES'>KERNEL_FEATURES</ulink></filename>
-                    variable can be used to list configuration fragments.
-                    For further discussion on applying configuration fragments, see the
-                    "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-filelayout-kernel'>Linux Kernel Configuration</ulink>"
-                    section in the Yocto Project Board Support Package (BSP) Guide.
-                    </para></listitem>
-            </itemizedlist>
-        </para>
-    </section>
-
-    <section id='kernel-tools'>
-        <title>Kernel Tools</title>
-        <para>
-            Since most standard workflows involve moving forward with an existing tree by
-            continuing to add and alter the underlying baseline, the tools that manage
-            the Yocto Project's kernel construction are largely hidden from the developer to
-            present a simplified view of the kernel for ease of use.
-        </para>
-        <para>
-            Fundamentally, the kernel tools that manage and construct the
-            Yocto Project kernel accomplish the following:
-            <itemizedlist>
-                <listitem><para>Group patches into named, reusable features.</para></listitem>
-                <listitem><para>Allow top-down control of included features.</para></listitem>
-                <listitem><para>Bind kernel configurations to kernel patches and features.</para></listitem>
-                <listitem><para>Present a seamless Git repository that blends Yocto Project value
-                    with the <filename>kernel.org</filename> history and development.</para></listitem>
-            </itemizedlist>
-        </para>
-    </section>
-</chapter>
-<!--
-vim: expandtab tw=80 ts=4
--->

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

@@ -1,78 +0,0 @@
-<!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='kernel-doc-intro'>
-
-<title>Yocto Project Kernel Architecture and Use Manual</title>
-
-<section id='kernel-intro-section'>
-    <title>Introduction</title>
-    <para>
-        The Yocto Project presents kernels as a fully patched, history-clean Git
-        repositories.
-        Each repository represents selected features, board support,
-        and configurations extensively tested by the Yocto Project.
-        Yocto Project kernels allow the end user to leverage community
-        best practices to seamlessly manage the development, build and debug cycles.
-    </para>
-    <para>
-        This manual describes Yocto Project kernels by providing information
-        on history, organization, benefits, and use.
-        The manual consists of two sections:
-        <itemizedlist>
-            <listitem><para><emphasis>Concepts:</emphasis> Describes concepts behind a kernel.
-                You will understand how a kernel is organized and why it is organized in
-                the way it is.  You will understand the benefits of a kernel's organization
-                and the mechanisms used to work with the kernel and how to apply it in your
-                design process.</para></listitem>
-            <listitem><para><emphasis>Using a Kernel:</emphasis> Describes best practices
-                and "how-to" information
-                that lets you put a kernel to practical use.
-                Some examples are how to examine changes in a branch and how to
-                save kernel modifications.</para></listitem>
-        </itemizedlist>
-    </para>
-
-    <para>
-        For more information on the Linux kernel, see the following links:
-        <itemizedlist>
-            <listitem><para>The Linux Foundation's guide for kernel development
-                process - <ulink url='http://www.linuxfoundation.org/content/1-guide-kernel-development-process'></ulink></para></listitem>
-            <listitem><para>A fairly encompassing guide on Linux kernel development -
-                <ulink url='http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/HOWTO;hb=HEAD'></ulink></para></listitem>
-        </itemizedlist>
-    </para>
-
-    <para>
-        For more discussion on the Yocto Project kernel, you can see these sections
-        in the Yocto Project Development Manual:
-        <itemizedlist>
-            <listitem><para>
-                "<ulink url='&YOCTO_DOCS_DEV_URL;#kernel-overview'>Kernel Overview</ulink>"</para></listitem>
-            <listitem><para>
-                "<ulink url='&YOCTO_DOCS_DEV_URL;#kernel-modification-workflow'>Kernel Modification Workflow</ulink>"
-                </para></listitem>
-            <listitem><para>
-                "<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>
-
-    <para>
-        For general information on the Yocto Project, visit the website at
-        <ulink url='&YOCTO_HOME_URL;'></ulink>.
-    </para>
-</section>
-
-
-
-
-
-
-
-</chapter>
-<!--
-vim: expandtab tw=80 ts=4
--->

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

@@ -1,918 +0,0 @@
-<!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='kernel-how-to'>
-
-<title>Working with the Yocto Project Kernel</title>
-
-
-<section id='actions-org'>
-    <title>Introduction</title>
-    <para>
-        This chapter describes how to accomplish tasks involving a kernel's tree structure.
-        The information is designed to help the developer that wants to modify the Yocto
-        Project kernel and contribute changes upstream to the Yocto Project.
-        The information covers the following:
-        <itemizedlist>
-            <listitem><para>Tree construction</para></listitem>
-            <listitem><para>Build strategies</para></listitem>
-            <listitem><para>Workflow examples</para></listitem>
-        </itemizedlist>
-    </para>
-</section>
-
-    <section id='tree-construction'>
-        <title>Tree Construction</title>
-        <para>
-            This section describes construction of the Yocto Project kernel source repositories
-            as accomplished by the Yocto Project team to create kernel repositories.
-            These kernel repositories are found under the heading "Yocto Linux Kernel" at
-            <ulink url='&YOCTO_GIT_URL;/cgit.cgi'>&YOCTO_GIT_URL;/cgit.cgi</ulink>
-            and can be shipped as part of a Yocto Project release.
-            The team creates these repositories by
-            compiling and executing the set of feature descriptions for every BSP/feature
-            in the product.
-            Those feature descriptions list all necessary patches,
-            configuration, branching, tagging and feature divisions found in a kernel.
-            Thus, the Yocto Project kernel repository (or tree) is built.
-        </para>
-        <para>
-            The existence of this tree allows you to access and clone a particular
-            Yocto Project kernel repository and use it to build images based on their configurations
-            and features.
-        </para>
-        <para>
-            You can find the files used to describe all the valid features and BSPs
-            in the Yocto Project kernel in any clone of the Yocto Project kernel source repository
-            Git tree.
-            For example, the following command clones the Yocto Project baseline kernel that
-            branched off of <filename>linux.org</filename> version 3.4:
-            <literallayout class='monospaced'>
-     $ git clone git://git.yoctoproject.org/linux-yocto-3.4
-            </literallayout>
-            For another example of how to set up a local Git repository of the Yocto Project
-            kernel files, see the
-            "<ulink url='&YOCTO_DOCS_DEV_URL;#local-kernel-files'>Yocto Project Kernel</ulink>" bulleted
-            item in the Yocto Project Development Manual.
-        </para>
-        <para>
-            Once you have cloned the kernel Git repository on your local machine, you can
-            switch to the <filename>meta</filename> branch within the repository.
-            Here is an example that assumes the local Git repository for the kernel is in
-            a top-level directory named <filename>linux-yocto-3.4</filename>:
-            <literallayout class='monospaced'>
-     $ cd ~/linux-yocto-3.4
-     $ git checkout -b meta origin/meta
-            </literallayout>
-            Once you have checked out and switched to the <filename>meta</filename> branch,
-            you can see a snapshot of all the kernel configuration and feature descriptions that are
-            used to build that particular kernel repository.
-            These descriptions are in the form of <filename>.scc</filename> files.
-        </para>
-        <para>
-            You should realize, however, that browsing your local kernel repository
-            for feature descriptions and patches is not an effective way to determine what is in a
-            particular kernel branch.
-            Instead, you should use Git directly to discover the changes in a branch.
-            Using Git is an efficient and flexible way to inspect changes to the kernel.
-            For examples showing how to use Git to inspect kernel commits, see the following sections
-            in this chapter.
-            <note>
-                Ground up reconstruction of the complete kernel tree is an action only taken by the
-                Yocto Project team during an active development cycle.
-                When you create a clone of the kernel Git repository, you are simply making it
-                efficiently available for building and development.
-            </note>
-        </para>
-        <para>
-            The following steps describe what happens when the Yocto Project Team constructs
-            the Yocto Project kernel source Git repository (or tree) found at
-            <ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink> given the
-            introduction of a new top-level kernel feature or BSP.
-            These are the actions that effectively create the tree
-            that includes the new feature, patch or BSP:
-            <orderedlist>
-                <listitem><para>A top-level kernel feature is passed to the kernel build subsystem.
-                    Normally, this feature is a BSP for a particular kernel type.</para></listitem>
-                <listitem><para>The file that describes the top-level feature is located by searching
-                    these system directories:
-                    <itemizedlist>
-                        <listitem><para>The in-tree kernel-cache directories, which are located
-                            in <filename>meta/cfg/kernel-cache</filename></para></listitem>
-                        <listitem><para>Areas pointed to by <filename>SRC_URI</filename> statements
-                            found in recipes</para></listitem>
-                    </itemizedlist>
-                    For a typical build, the target of the search is a
-                    feature description in an <filename>.scc</filename> file
-                    whose name follows this format:
-                    <literallayout class='monospaced'>
-     &lt;bsp_name&gt;-&lt;kernel_type&gt;.scc
-                    </literallayout>
-                </para></listitem>
-                <listitem><para>Once located, the feature description is either compiled into a simple script
-                    of actions, or into an existing equivalent script that is already part of the
-                    shipped kernel.</para></listitem>
-                <listitem><para>Extra features are appended to the top-level feature description.
-                    These features can come from the
-                    <ulink url='&YOCTO_DOCS_REF_URL;#var-KERNEL_FEATURES'><filename>KERNEL_FEATURES</filename></ulink>
-                    variable in recipes.</para></listitem>
-                <listitem><para>Each extra feature is located, compiled and appended to the script
-                    as described in step three.</para></listitem>
-                <listitem><para>The script is executed to produce a series of <filename>meta-*</filename>
-                    directories.
-                    These directories are descriptions of all the branches, tags, patches and configurations that
-                    need to be applied to the base Git repository to completely create the
-                    source (build) branch for the new BSP or feature.</para></listitem>
-                <listitem><para>The base repository is cloned, and the actions
-                    listed in the <filename>meta-*</filename> directories are applied to the
-                    tree.</para></listitem>
-                <listitem><para>The Git repository is left with the desired branch checked out and any
-                    required branching, patching and tagging has been performed.</para></listitem>
-            </orderedlist>
-        </para>
-        <para>
-            The kernel tree is now ready for developer consumption to be locally cloned,
-            configured, and built into a Yocto Project kernel specific to some target hardware.
-            <note><para>The generated <filename>meta-*</filename> directories add to the kernel
-                as shipped with the Yocto Project release.
-                Any add-ons and configuration data are applied to the end of an existing branch.
-                The full repository generation that is found in the
-                official Yocto Project kernel repositories at
-                <ulink url='&YOCTO_GIT_URL;/cgit.cgi'>http://git.yoctoproject.org/cgit.cgi</ulink>
-                is the combination of all supported boards and configurations.</para>
-                <para>The technique the Yocto Project team uses is flexible and allows for seamless
-                blending of an immutable history with additional patches specific to a
-                deployment.
-                Any additions to the kernel become an integrated part of the branches.</para>
-            </note>
-        </para>
-    </section>
-
-    <section id='build-strategy'>
-        <title>Build Strategy</title>
-        <para>
-            Once a local Git repository of the Yocto Project kernel exists on a development system,
-            you can consider the compilation phase of kernel development - building a kernel image.
-            Some prerequisites exist that are validated by the build process before compilation
-            starts:
-        </para>
-
-        <itemizedlist>
-            <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'>
-     &lt;kernel_type&gt;/&lt;bsp_name&gt;
-                </literallayout></para></listitem>
-        </itemizedlist>
-
-        <para>
-            The OpenEmbedded build system makes sure these conditions exist before attempting compilation.
-            Other means, however, do exist, such as as bootstrapping a BSP, see
-            the "<link linkend='workflow-examples'>Workflow Examples</link>".
-        </para>
-
-        <para>
-            Before building a kernel, the build process verifies the tree
-            and configures the kernel by processing all of the
-            configuration "fragments" specified by feature descriptions in the <filename>.scc</filename>
-            files.
-            As the features are compiled, associated kernel configuration fragments are noted
-            and recorded in the <filename>meta-*</filename> series of directories in their compilation order.
-            The fragments are migrated, pre-processed and passed to the Linux Kernel
-            Configuration subsystem (<filename>lkc</filename>) as raw input in the form
-            of a <filename>.config</filename> file.
-            The <filename>lkc</filename> uses its own internal dependency constraints to do the final
-            processing of that information and generates the final <filename>.config</filename> file
-            that is used during compilation.
-        </para>
-
-        <para>
-            Using the board's architecture and other relevant values from the board's template,
-            kernel compilation is started and a kernel image is produced.
-        </para>
-
-        <para>
-            The other thing that you notice once you configure a kernel is that
-            the build process generates a build tree that is separate from your kernel's local Git
-            source repository tree.
-            This build tree has a name that uses the following form, where
-            <filename>${MACHINE}</filename> is the metadata name of the machine (BSP) and "kernel_type" is one
-            of the Yocto Project supported kernel types (e.g. "standard"):
-        <literallayout class='monospaced'>
-     linux-${MACHINE}-&lt;kernel_type&gt;-build
-        </literallayout>
-        </para>
-
-        <para>
-            The existing support in the <filename>kernel.org</filename> tree achieves this
-            default functionality.
-        </para>
-
-        <para>
-            This behavior means that all the generated files for a particular machine or BSP are now in
-            the build tree directory.
-            The files include the final <filename>.config</filename> file, all the <filename>.o</filename>
-            files, the <filename>.a</filename> files, and so forth.
-            Since each machine or BSP has its own separate build directory in its own separate branch
-            of the Git repository, you can easily switch between different builds.
-        </para>
-    </section>
-
-    <section id='workflow-examples'>
-        <title>Workflow Examples</title>
-
-        <para>
-            As previously noted, the Yocto Project kernel has built-in Git integration.
-            However, these utilities are not the only way to work with the kernel repository.
-            The Yocto Project has not made changes to Git or to other tools that
-            would invalidate alternate workflows.
-            Additionally, the way the kernel repository is constructed results in using
-            only core Git functionality, thus allowing any number of tools or front ends to use the
-            resulting tree.
-        </para>
-
-        <para>
-            This section contains several workflow examples.
-            Many of the examples use Git commands.
-            You can find Git documentation at
-            <ulink url='http://git-scm.com/documentation'></ulink>.
-            You can find a simple overview of using Git with the Yocto Project in the
-            "<ulink url='&YOCTO_DOCS_DEV_URL;#git'>Git</ulink>"
-            section of the Yocto Project Development Manual.
-        </para>
-
-        <section id='change-inspection-kernel-changes-commits'>
-            <title>Change Inspection: Changes/Commits</title>
-
-            <para>
-                A common question when working with a kernel is:
-                "What changes have been applied to this tree?"
-            </para>
-
-            <para>
-                In projects that have a collection of directories that
-                contain patches to the kernel, it is possible to inspect or "grep" the contents
-                of the directories to get a general feel for the changes.
-                This sort of patch inspection is not an efficient way to determine what has been
-                done to the kernel.
-                The reason it is inefficient is because there are many optional patches that are
-                selected based on the kernel type and the feature description.
-                Additionally, patches could exist in directories that are not included in the search.
-            </para>
-
-            <para>
-                A more efficient way to determine what has changed in the branch is to use
-                Git and inspect or search the kernel tree.
-                This method gives you a full view of not only the source code modifications,
-                but also provides the reasons for the changes.
-            </para>
-
-            <section id='what-changed-in-a-kernel'>
-                <title>What Changed in a Kernel?</title>
-
-                <para>
-                    Following are a few examples that show how to use Git commands to examine changes.
-                    Because Git repositories in the Yocto Project do not break existing Git
-                    functionality, and because there exists many permutations of these types of
-                    Git commands, many methods exist by which you can discover changes.
-                    <note>
-                        In the following examples, unless you provide a commit range,
-                        <filename>kernel.org</filename> history is blended with Yocto Project
-                        kernel changes.
-                        You can form ranges by using branch names from the kernel tree as the
-                        upper and lower commit markers with the Git commands.
-                        You can see the branch names through the web interface to the
-                        Yocto Project source repositories at
-                        <ulink url='http://git.yoctoproject.org/cgit.cgi'></ulink>.
-                        For example, the branch names for the <filename>linux-yocto-3.4</filename>
-                        kernel repository can be seen at
-                        <ulink url='http://git.yoctoproject.org/cgit.cgi/linux-yocto-3.4/refs/heads'></ulink>.
-                    </note>
-                    To see a full range of the changes, use the
-                    <filename>git whatchanged</filename> command and specify a commit range
-                    for the branch (<filename>&lt;commit&gt;..&lt;commit&gt;</filename>).
-                </para>
-
-                <para>
-                    Here is an example that looks at what has changed in the
-                    <filename>emenlow</filename> branch of the
-                    <filename>linux-yocto-3.4</filename> kernel.
-                    The lower commit range is the commit associated with the
-                    <filename>standard/base</filename> branch, while
-                    the upper commit range is the commit associated with the
-                    <filename>standard/emenlow</filename> branch.
-                    <literallayout class='monospaced'>
-     $ git whatchanged origin/standard/base..origin/standard/emenlow
-                    </literallayout>
-                </para>
-
-                <para>
-                    To see a summary of changes use the <filename>git log</filename> command.
-                    Here is an example using the same branches:
-                    <literallayout class='monospaced'>
-     $ git log --oneline origin/standard/base..origin/standard/emenlow
-                    </literallayout>
-                    The <filename>git log</filename> output might be more useful than
-                    the <filename>git whatchanged</filename> as you get
-                    a short, one-line summary of each change and not the entire commit.
-                </para>
-
-                <para>
-                    If you want to see code differences associated with all the changes, use
-                    the <filename>git diff</filename> command.
-                    Here is an example:
-                    <literallayout class='monospaced'>
-     $ git diff origin/standard/base..origin/standard/emenlow
-                    </literallayout>
-                </para>
-
-                <para>
-                    You can see the commit log messages and the text differences using the
-                    <filename>git show</filename> command:
-                    Here is an example:
-                    <literallayout class='monospaced'>
-     $ git show origin/standard/base..origin/standard/emenlow
-                    </literallayout>
-                </para>
-
-                <para>
-                    You can create individual patches for each change by using the
-                    <filename>git format-patch</filename> command.
-                    Here is an example that that creates patch files for each commit and
-                    places them in your <filename>Documents</filename> directory:
-                    <literallayout class='monospaced'>
-     $ git format-patch -o $HOME/Documents origin/standard/base..origin/standard/emenlow
-                    </literallayout>
-                </para>
-            </section>
-
-            <section id='show-a-particular-feature-or-branch-change'>
-                <title>Show a Particular Feature or Branch Change</title>
-
-                <para>
-                    Developers use tags in the Yocto Project kernel tree to divide changes for significant
-                    features or branches.
-                    Once you know a particular tag, you can use Git commands
-                    to show changes associated with the tag and find the branches that contain
-                    the feature.
-                    <note>
-                        Because BSP branch, <filename>kernel.org</filename>, and feature tags are all
-                        present, there could be many tags.
-                    </note>
-                    The <filename>git show &lt;tag&gt;</filename> command shows changes that are tagged by
-                    a feature.
-                    Here is an example that shows changes tagged by the <filename>systemtap</filename>
-                    feature:
-                    <literallayout class='monospaced'>
-     $ git show systemtap
-                    </literallayout>
-                    You can use the <filename>git branch --contains &lt;tag&gt;</filename> command
-                    to show the branches that contain a particular feature.
-                    This command shows the branches that contain the <filename>systemtap</filename>
-                    feature:
-                    <literallayout class='monospaced'>
-     $ git branch --contains systemtap
-                    </literallayout>
-                </para>
-
-                <para>
-                    You can use many other comparisons to isolate BSP and kernel changes.
-                    For example, you can compare against <filename>kernel.org</filename> tags
-                    such as the <filename>v3.4</filename> tag.
-                </para>
-            </section>
-        </section>
-
-        <section id='development-saving-kernel-modifications'>
-            <title>Development: Saving Kernel Modifications</title>
-
-            <para>
-                Another common operation is to build a BSP supplied by the Yocto Project, make some
-                changes, rebuild, and then test.
-                Those local changes often need to be exported, shared or otherwise maintained.
-            </para>
-
-            <para>
-                Since the Yocto Project kernel source tree is backed by Git, this activity is
-                much easier as compared to with previous releases.
-                Because Git tracks file modifications, additions and deletions, it is easy
-                to modify the code and later realize that you need to save the changes.
-                It is also easy to determine what has changed.
-                This method also provides many tools to commit, undo and export those modifications.
-            </para>
-
-            <para>
-                This section and its sub-sections, describe general application of Git's
-                <filename>push</filename> and <filename>pull</filename> commands, which are used to
-                get your changes upstream or source your code from an upstream repository.
-                The Yocto Project provides scripts that help you work in a collaborative development
-                environment.
-                For information on these scripts, see the
-                "<ulink url='&YOCTO_DOCS_DEV_URL;#pushing-a-change-upstream'>Using Scripts to Push a Change
-                Upstream and Request a Pull</ulink>" and
-                "<ulink url='&YOCTO_DOCS_DEV_URL;#submitting-a-patch'>Using Email to Submit a Patch</ulink>"
-                sections in the Yocto Project Development Manual.
-            </para>
-
-            <para>
-                There are many ways to save kernel modifications.
-                The technique employed
-                depends on the destination for the patches:
-
-                <itemizedlist>
-                    <listitem><para>Bulk storage</para></listitem>
-                    <listitem><para>Internal sharing either through patches or by using Git</para></listitem>
-                    <listitem><para>External submissions</para></listitem>
-                    <listitem><para>Exporting for integration into another Source Code
-                        Manager (SCM)</para></listitem>
-                </itemizedlist>
-            </para>
-
-            <para>
-                Because of the following list of issues, the destination of the patches also influences
-                the method for gathering them:
-
-                <itemizedlist>
-                    <listitem><para>Bisectability</para></listitem>
-                    <listitem><para>Commit headers</para></listitem>
-                    <listitem><para>Division of subsystems for separate submission or review</para></listitem>
-                </itemizedlist>
-            </para>
-
-            <section id='bulk-export'>
-                <title>Bulk Export</title>
-
-                <para>
-                    This section describes how you can "bulk" export changes that have not
-                    been separated or divided.
-                    This situation works well when you are simply storing patches outside of the kernel
-                    source repository, either permanently or temporarily, and you are not committing
-                    incremental changes during development.
-                    <note>
-                        This technique is not appropriate for full integration of upstream submission
-                        because changes are not properly divided and do not provide an avenue for per-change
-                        commit messages.
-                        Therefore, this example assumes that changes have not been committed incrementally
-                        during development and that you simply must gather and export them.
-                    </note>
-                    <literallayout class='monospaced'>
-     # bulk export of ALL modifications without separation or division
-     # of the changes
-
-     $ git add .
-     $ git commit -s -a -m &lt;msg&gt;
-        or
-     $ git commit -s -a # and interact with $EDITOR
-                    </literallayout>
-                </para>
-
-                <para>
-                    The previous operations capture all the local changes in the project source
-                    tree in a single Git commit.
-                    And, that commit is also stored in the project's source tree.
-                </para>
-
-                <para>
-                    Once the changes are exported, you can restore them manually using a template
-                    or through integration with the <filename>default_kernel</filename>.
-                </para>
-
-            </section>
-
-            <section id='incremental-planned-sharing'>
-                <title>Incremental/Planned Sharing</title>
-
-                <para>
-                    This section describes how to save modifications when you are making incremental
-                    commits or practicing planned sharing.
-                    The examples in this section assume that you have incrementally committed
-                    changes to the tree during development and now need to export them.
-                    The sections that follow
-                    describe how you can export your changes internally through either patches or by
-                    using Git commands.
-                </para>
-
-                <para>
-                    During development, the following commands are of interest.
-                    For full Git documentation, refer to the Git documentation at
-                    <ulink url='http://github.com'></ulink>.
-
-                    <literallayout class='monospaced'>
-     # edit a file
-     $ vi &lt;path&gt;/file
-     # stage the change
-     $ git add &lt;path&gt;/file
-     # commit the change
-     $ git commit -s
-     # remove a file
-     $ git rm &lt;path&gt;/file
-     # commit the change
-     $ git commit -s
-
-     ... etc.
-                    </literallayout>
-                </para>
-
-                <para>
-                    Distributed development with Git is possible when you use a universally
-                    agreed-upon unique commit identifier (set by the creator of the commit) that maps to a
-                    specific change set with a specific parent.
-                    This identifier is created for you when
-                    you create a commit, and is re-created when you amend, alter or re-apply
-                    a commit.
-                    As an individual in isolation, this is of no interest.
-                    However, if you
-                    intend to share your tree with normal Git <filename>push</filename> and
-                    <filename>pull</filename> operations for
-                    distributed development, you should consider the ramifications of changing a
-                    commit that you have already shared with others.
-                </para>
-
-                <para>
-                    Assuming that the changes have not been pushed upstream, or pulled into
-                    another repository, you can update both the commit content and commit messages
-                    associated with development by using the following commands:
-
-                    <literallayout class='monospaced'>
-     $ Git add &lt;path&gt;/file
-     $ Git commit --amend
-     $ Git rebase or Git rebase -i
-                    </literallayout>
-                </para>
-
-                <para>
-                    Again, assuming that the changes have not been pushed upstream, and that
-                    no pending works-in-progress exist (use <filename>git status</filename> to check), then
-                    you can revert (undo) commits by using the following commands:
-
-                    <literallayout class='monospaced'>
-     # remove the commit, update working tree and remove all
-     # traces of the change
-     $ git reset --hard HEAD^
-     # remove the commit, but leave the files changed and staged for re-commit
-     $ git reset --soft HEAD^
-     # remove the commit, leave file change, but not staged for commit
-     $ git reset --mixed HEAD^
-                    </literallayout>
-                </para>
-
-                <para>
-                    You can create branches, "cherry-pick" changes, or perform any number of Git
-                    operations until the commits are in good order for pushing upstream
-                    or for pull requests.
-                    After a <filename>push</filename> or <filename>pull</filename> command,
-                    commits are normally considered
-                    "permanent" and you should not modify them.
-                    If the commits need to be changed, you can incrementally do so with new commits.
-                    These practices follow standard Git workflow and the <filename>kernel.org</filename> best
-                    practices, which is recommended.
-                    <note>
-                        It is recommended to tag or branch before adding changes to a Yocto Project
-                        BSP or before creating a new one.
-                        The reason for this recommendation is because the branch or tag provides a
-                        reference point to facilitate locating and exporting local changes.
-                    </note>
-                </para>
-
-                <section id='export-internally-via-patches'>
-                    <title>Exporting Changes Internally by Using Patches</title>
-
-                    <para>
-                        This section describes how you can extract committed changes from a working directory
-                        by exporting them as patches.
-                        Once the changes have been extracted, you can use the patches for upstream submission,
-                        place them in a Yocto Project template for automatic kernel patching,
-                        or apply them in many other common uses.
-                    </para>
-
-                    <para>
-                        This example shows how to create a directory with sequentially numbered patches.
-                        Once the directory is created, you can apply it to a repository using the
-                        <filename>git am</filename> command to reproduce the original commit and all
-                        the related information such as author, date, commit log, and so forth.
-                        <note>
-                            The new commit identifiers (ID) will be generated upon re-application.
-                            This action reflects that the commit is now applied to an underlying commit
-                            with a different ID.
-                        </note>
-                        <literallayout class='monospaced'>
-     # &lt;first-commit&gt; can be a tag if one was created before development
-     # began. It can also be the parent branch if a branch was created
-     # before development began.
-
-     $ git format-patch -o &lt;dir&gt; &lt;first commit&gt;..&lt;last commit&gt;
-                        </literallayout>
-                    </para>
-
-                    <para>
-                        In other words:
-                        <literallayout class='monospaced'>
-     # Identify commits of interest.
-
-     # If the tree was tagged before development
-     $ git format-patch -o &lt;save dir&gt; &lt;tag&gt;
-
-     # If no tags are available
-     $ git format-patch -o &lt;save dir&gt; HEAD^  # last commit
-     $ git format-patch -o &lt;save dir&gt; HEAD^^ # last 2 commits
-     $ git whatchanged # identify last commit
-     $ git format-patch -o &lt;save dir&gt; &lt;commit id&gt;
-     $ git format-patch -o &lt;save dir&gt; &lt;rev-list&gt;
-                        </literallayout>
-                    </para>
-                </section>
-
-                <section id='export-internally-via-git'>
-                    <title>Exporting Changes Internally by Using Git</title>
-
-                    <para>
-                        This section describes how you can export changes from a working directory
-                        by pushing the changes into a master repository or by making a pull request.
-                        Once you have pushed the changes to the master repository, you can then
-                        pull those same changes into a new kernel build at a later time.
-                    </para>
-
-                    <para>
-                        Use this command form to push the changes:
-                        <literallayout class='monospaced'>
-     $ git push ssh://&lt;master_server&gt;/&lt;path_to_repo&gt;
-        &lt;local_branch&gt;:&lt;remote_branch&gt;
-                        </literallayout>
-                    </para>
-
-                    <para>
-                        For example, the following command pushes the changes from your local branch
-                        <filename>yocto/standard/common-pc/base</filename> to the remote branch with the same name
-                        in the master repository <filename>//git.mycompany.com/pub/git/kernel-3.4</filename>.
-                        <literallayout class='monospaced'>
-     $ git push ssh://git.mycompany.com/pub/git/kernel-3.4 \
-        yocto/standard/common-pc/base:yocto/standard/common-pc/base
-                        </literallayout>
-                    </para>
-
-                    <para>
-                        A pull request entails using the <filename>git request-pull</filename> command to compose
-                        an email to the
-                        maintainer requesting that a branch be pulled into the master repository, see
-                        <ulink url='http://github.com/guides/pull-requests'></ulink> for an example.
-                        <note>
-                            Other commands such as <filename>git stash</filename> or branching can also be used to save
-                            changes, but are not covered in this document.
-                        </note>
-                    </para>
-                </section>
-            </section>
-
-            <section id='export-for-external-upstream-submission'>
-                <title>Exporting Changes for External (Upstream) Submission</title>
-
-                <para>
-                    This section describes how to export changes for external upstream submission.
-                    If the patch series is large or the maintainer prefers to pull
-                    changes, you can submit these changes by using a pull request.
-                    However, it is common to send patches as an email series.
-                    This method allows easy review and integration of the changes.
-                    <note>
-                        Before sending patches for review be sure you understand the
-                        community standards for submitting and documenting changes and follow their best practices.
-                        For example, kernel patches should follow standards such as:
-                        <itemizedlist>
-                            <listitem><para>
-                                <ulink url='http://linux.yyz.us/patch-format.html'></ulink></para></listitem>
-                            <listitem><para>Documentation/SubmittingPatches (in any linux
-                                kernel source tree)</para></listitem>
-                        </itemizedlist>
-                    </note>
-                </para>
-
-                <para>
-                    The messages used to commit changes are a large part of these standards.
-                    Consequently, be sure that the headers for each commit have the required information.
-                    For information on how to follow the Yocto Project commit message standards, see the
-                    "<ulink url='&YOCTO_DOCS_DEV_URL;#how-to-submit-a-change'>How to Submit a
-                    Change</ulink>" section in the Yocto Project Development Manual.
-                </para>
-
-                <para>
-                    If the initial commits were not properly documented or do not meet those standards,
-                    you can re-base by using the <filename>git rebase -i</filename> command to
-                    manipulate the commits and
-                    get them into the required format.
-                    Other techniques such as branching and cherry-picking commits are also viable options.
-                </para>
-
-                <para>
-                    Once you complete the commits, you can generate the email that sends the patches
-                    to the maintainer(s) or lists that review and integrate changes.
-                    The command <filename>git send-email</filename> is commonly used to ensure
-                    that patches are properly
-                    formatted for easy application and avoid mailer-induced patch damage.
-                </para>
-
-                <para>
-                    The following is an example of dumping patches for external submission:
-                    <literallayout class='monospaced'>
-     # dump the last 4 commits
-     $ git format-patch --thread -n -o ~/rr/ HEAD^^^^
-     $ git send-email --compose --subject '[RFC 0/N] &lt;patch series summary&gt;' \
-      --to foo@yoctoproject.org --to bar@yoctoproject.org \
-      --cc list@yoctoproject.org  ~/rr
-     # the editor is invoked for the 0/N patch, and when complete the entire
-     # series is sent via email for review
-                    </literallayout>
-                </para>
-            </section>
-
-            <section id='export-for-import-into-other-scm'>
-                <title>Exporting Changes for Import into Another SCM</title>
-
-                <para>
-                    When you want to export changes for import into another
-                    Source Code Manager (SCM), you can use any of the previously discussed
-                    techniques.
-                    However, if the patches are manually applied to a secondary tree and then
-                    that tree is checked into the SCM, you can lose change information such as
-                    commit logs.
-                    This process is not recommended.
-                </para>
-
-                <para>
-                    Many SCMs can directly import Git commits, or can translate Git patches so that
-                    information is not lost.
-                    Those facilities are SCM-dependent and you should use them whenever possible.
-                </para>
-            </section>
-        </section>
-
-        <section id='scm-working-with-the-yocto-project-kernel-in-another-scm'>
-            <title>Working with the Yocto Project Kernel in Another SCM</title>
-
-            <para>
-                This section describes kernel development in an SCM other than Git,
-                which is not the same as exporting changes to another SCM described earlier.
-                For this scenario, you use the OpenEmbedded build system to
-                develop the kernel in a different SCM.
-                The following must be true for you to accomplish this:
-                <itemizedlist>
-                    <listitem><para>The delivered Yocto Project kernel must be exported into the second
-                        SCM.</para></listitem>
-                    <listitem><para>Development must be exported from that secondary SCM into a
-                        format that can be used by the OpenEmbedded build system.</para></listitem>
-                </itemizedlist>
-            </para>
-
-            <section id='exporting-delivered-kernel-to-scm'>
-                <title>Exporting the Delivered Kernel to the SCM</title>
-
-                <para>
-                    Depending on the SCM, it might be possible to export the entire Yocto Project
-                    kernel Git repository, branches and all, into a new environment.
-                    This method is preferred because it has the most flexibility and potential to maintain
-                    the meta data associated with each commit.
-                </para>
-
-                <para>
-                    When a direct import mechanism is not available, it is still possible to
-                    export a branch (or series of branches) and check them into a new repository.
-                </para>
-
-                <para>
-                    The following commands illustrate some of the steps you could use to
-                    import the <filename>yocto/standard/common-pc/base</filename>
-                    kernel into a secondary SCM:
-                    <literallayout class='monospaced'>
-     $ git checkout yocto/standard/common-pc/base
-     $ cd .. ; echo linux/.git &gt; .cvsignore
-     $ cvs import -m "initial import" linux MY_COMPANY start
-                    </literallayout>
-                </para>
-
-                <para>
-                    You could now relocate the CVS repository and use it in a centralized manner.
-                </para>
-
-                <para>
-                    The following commands illustrate how you can condense and merge two BSPs into a
-                    second SCM:
-                    <literallayout class='monospaced'>
-     $ git checkout yocto/standard/common-pc/base
-     $ git merge yocto/standard/common-pc-64/base
-     # resolve any conflicts and commit them
-     $ cd .. ; echo linux/.git &gt; .cvsignore
-     $ cvs import -m "initial import" linux MY_COMPANY start
-                    </literallayout>
-                </para>
-            </section>
-
-            <section id='importing-changes-for-build'>
-                <title>Importing Changes for the Build</title>
-
-                <para>
-                    Once development has reached a suitable point in the second development
-                    environment, you need to export the changes as patches.
-                    To export them, place the changes in a recipe and
-                    automatically apply them to the kernel during patching.
-                </para>
-            </section>
-        </section>
-
-        <section id='bsp-creating'>
-            <title>Creating a BSP Based on an Existing Similar BSP</title>
-
-            <para>
-                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 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>
-
-            <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
-                        extracting a Yocto Project release tarball.</para></listitem>
-                    <listitem><para><emphasis>Choose an existing BSP available with the Yocto Project:</emphasis>
-                        Try to map your board features as closely to the features of a BSP that is
-                        already supported and exists in the Yocto Project.
-                        Starting with something as close as possible to your board makes developing
-                        your BSP easier.
-                        You can find all the BSPs that are supported and ship with the Yocto Project
-                        on the Yocto Project's Download page at
-                        <ulink url='&YOCTO_HOME_URL;/download'></ulink>.</para></listitem>
-                    <listitem><para><emphasis>Be sure you have the Base BSP:</emphasis>
-                        You need to either have a local Git repository of the base BSP set up or
-                        have downloaded and extracted the files from a release BSP tarball.
-                        Either method gives you access to the BSP source files.</para></listitem>
-                    <listitem><para><emphasis>Make a copy of the existing BSP, thus isolating your new
-                        BSP work:</emphasis>
-                        Copying the existing BSP file structure gives you a new area in which to work.</para></listitem>
-                    <listitem><para><emphasis>Make configuration and recipe changes to your new BSP:</emphasis>
-                        Configuration changes involve the files in the BSP's <filename>conf</filename>
-                        directory.
-                        Changes include creating a machine-specific configuration file and editing the
-                        <filename>layer.conf</filename> file.
-                        The configuration changes identify the kernel you will be using.
-                        Recipe changes include removing, modifying, or adding new recipe files that
-                        instruct the build process on what features to include in the image.</para></listitem>
-                    <listitem><para><emphasis>Prepare for the build:</emphasis>
-                        Before you actually initiate the build, you need to set up the build environment
-                        by sourcing the environment initialization script.
-                        After setting up the environment, you need to make some build configuration
-                        changes to the <filename>local.conf</filename> and <filename>bblayers.conf</filename>
-                        files.</para></listitem>
-                    <listitem><para><emphasis>Build the image:</emphasis>
-                        The OpenEmbedded build system uses BitBake to create the image.
-                        You need to decide on the type of image you are going to build (e.g. minimal, base,
-                        core, sato, and so forth) and then start the build using the <filename>bitbake</filename>
-                        command.</para></listitem>
-                </orderedlist>
-            </para>
-        </section>
-
-        <section id='tip-dirty-string'>
-            <title>"-dirty" String</title>
-
-            <para>
-                If kernel images are being built with "-dirty" on the end of the version
-                string, this simply means that modifications in the source
-                directory have not been committed.
-                <literallayout class='monospaced'>
-     $ git status
-                </literallayout>
-            </para>
-
-            <para>
-                You can use the above Git command to report modified, removed, or added files.
-                You should commit those changes to the tree regardless of whether they will be saved,
-                exported, or used.
-                Once you commit the changes you need to rebuild the kernel.
-            </para>
-
-            <para>
-                To brute force pickup and commit all such pending changes, enter the following:
-                <literallayout class='monospaced'>
-     $ git add .
-     $ git commit -s -a -m "getting rid of -dirty"
-                </literallayout>
-            </para>
-
-            <para>
-                Next, rebuild the kernel.
-            </para>
-        </section>
-    </section>
-</chapter>
-<!--
-vim: expandtab tw=80 ts=4
--->

documentation/kernel-manual/kernel-manual-customization.xsl

@@ -1,11 +0,0 @@
-<?xml version='1.0'?>
-<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/1999/xhtml" xmlns:fo="http://www.w3.org/1999/XSL/Format" version="1.0">
-  
-  <xsl:import href="http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl" />
-
-  <xsl:param name="html.stylesheet" select="'kernel-style.css'" />
-  <xsl:param name="chapter.autolabel" select="1" />
-  <xsl:param name="appendix.autolabel" select="A" />
-  <xsl:param name="section.autolabel" select="1" />
-  <xsl:param name="section.label.includes.component.label" select="1" />
-</xsl:stylesheet>

documentation/kernel-manual/kernel-manual-eclipse-customization.xsl

@@ -1,27 +0,0 @@
-<?xml version='1.0'?>
-<xsl:stylesheet
-	xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
-	xmlns="http://www.w3.org/1999/xhtml"
-	xmlns:fo="http://www.w3.org/1999/XSL/Format"
-	version="1.0">
-
-  <xsl:import
-	  href="http://docbook.sourceforge.net/release/xsl/current/eclipse/eclipse3.xsl" />
-
-  <xsl:param name="chunker.output.indent" select="'yes'"/>
-  <xsl:param name="chunk.quietly" select="1"/>
-  <xsl:param name="chunk.first.sections" select="1"/>
-  <xsl:param name="chunk.section.depth" select="10"/>
-  <xsl:param name="use.id.as.filename" select="1"/>
-  <xsl:param name="ulink.target" select="'_self'" />
-  <xsl:param name="base.dir" select="'html/kernel-manual/'"/>
-  <xsl:param name="html.stylesheet" select="'../book.css'"/>
-  <xsl:param name="eclipse.manifest" select="0"/>
-  <xsl:param name="create.plugin.xml" select="0"/>
-  <xsl:param name="suppress.navigation" select="1"/>
-  <xsl:param name="generate.index" select="0"/>
-  <xsl:param name="chapter.autolabel" select="1" />
-  <xsl:param name="appendix.autolabel" select="A" />
-  <xsl:param name="section.autolabel" select="1" />
-  <xsl:param name="section.label.includes.component.label" select="1" />
-</xsl:stylesheet>

documentation/kernel-manual/kernel-manual.xml

@@ -1,106 +0,0 @@
-<!DOCTYPE book 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; ] >
-
-<book id='kernel-manual' lang='en'
-      xmlns:xi="http://www.w3.org/2003/XInclude"
-      xmlns="http://docbook.org/ns/docbook"
-      >
-    <bookinfo>
-
-        <mediaobject>
-            <imageobject>
-                <imagedata fileref='figures/kernel-title.png'
-                    format='SVG'
-                    align='left' scalefit='1' width='100%'/>
-            </imageobject>
-        </mediaobject>
-
-        <title>
-            The Yocto Project Kernel Architecture and Use Manual
-        </title>
-
-        <authorgroup>
-            <author>
-                <firstname>Bruce</firstname> <surname>Ashfield</surname>
-                <affiliation>
-                    <orgname>Wind River Corporation</orgname>
-                </affiliation>
-                <email>bruce.ashfield@windriver.com</email>
-            </author>
-        </authorgroup>
-
-        <revhistory>
-            <revision>
-                <revnumber>0.9</revnumber>
-                <date>24 November 2010</date>
-                <revremark>The initial document draft released with the Yocto Project 0.9 Release.</revremark>
-            </revision>
-            <revision>
-                <revnumber>1.0</revnumber>
-                <date>6 April 2011</date>
-                <revremark>Released with the Yocto Project 1.0 Release.</revremark>
-            </revision>
-            <revision>
-                <revnumber>1.0.1</revnumber>
-                <date>23 May 2011</date>
-                <revremark>Released with the Yocto Project 1.0.1 Release.</revremark>
-            </revision>
-            <revision>
-                <revnumber>1.1</revnumber>
-                <date>6 October 2011</date>
-                <revremark>Released with the Yocto Project 1.1 Release.</revremark>
-            </revision>
-            <revision>
-                <revnumber>1.2</revnumber>
-                <date>April 2012</date>
-                <revremark>Released with the Yocto Project 1.2 Release.</revremark>
-            </revision>
-            <revision>
-                <revnumber>1.3</revnumber>
-                <date>October 2012</date>
-                <revremark>Released with the Yocto Project 1.3 Release.</revremark>
-            </revision>
-            <revision>
-                <revnumber>1.4</revnumber>
-                <date>Sometime in 2013</date>
-                <revremark>Released with the Yocto Project 1.4 Release.</revremark>
-            </revision>
-        </revhistory>
-
-    <copyright>
-      <year>&COPYRIGHT_YEAR;</year>
-      <holder>Linux Foundation</holder>
-    </copyright>
-
-    <legalnotice>
-      <para>
-        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
-          <ulink url='&YOCTO_DOCS_KERNEL_URL;'>Yocto Project Kernel Architecture and Use Manual</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.
-      </note>
-    </legalnotice>
-
-    </bookinfo>
-
-    <xi:include href="kernel-doc-intro.xml"/>
-
-    <xi:include href="kernel-concepts.xml"/>
-
-    <xi:include href="kernel-how-to.xml"/>
-
-<!--    <index id='index'>
-      <title>Index</title>
-    </index>
--->
-
-</book>
-<!--
-vim: expandtab tw=80 ts=4
--->

documentation/kernel-manual/kernel-style.css

@@ -1,979 +0,0 @@
-/* 
-   Generic XHTML / DocBook XHTML CSS Stylesheet.
-   
-   Browser wrangling and typographic design by
-      Oyvind Kolas / pippin@gimp.org
-
-   Customised for Poky by
-      Matthew Allum / mallum@o-hand.com
-
-   Thanks to:
-     Liam R. E. Quin
-     William Skaggs
-     Jakub Steiner
-
-   Structure
-   ---------
-
-   The stylesheet is divided into the following sections:
-
-       Positioning
-          Margins, paddings, width, font-size, clearing.
-       Decorations
-          Borders, style
-       Colors
-          Colors
-       Graphics
-          Graphical backgrounds
-       Nasty IE tweaks
-          Workarounds needed to make it work in internet explorer,
-          currently makes the stylesheet non validating, but up until
-          this point it is validating.
-       Mozilla extensions
-          Transparency for footer
-	  Rounded corners on boxes
-
-*/
-
-
-  /*************** /
- /  Positioning   /
-/ ***************/
-
-body {
-  font-family: Verdana, Sans, sans-serif;
- 
-  min-width: 640px;
-  width: 80%;
-  margin:  0em auto;
-  padding: 2em 5em 5em 5em;
-  color: #333;
-}
-
-h1,h2,h3,h4,h5,h6,h7 {
-  font-family: Arial, Sans;
-  color: #00557D;
-  clear: both;
-}
-
-h1 {
-  font-size: 2em;
-  text-align: left;
-  padding: 0em 0em 0em 0em;
-  margin: 2em 0em 0em 0em;
-}
-
-h2.subtitle {
-  margin: 0.10em 0em 3.0em 0em;
-  padding: 0em 0em 0em 0em;
-  font-size: 1.8em;
-  padding-left: 20%;
-  font-weight: normal;
-  font-style: italic;
-}
-
-h2 {
-  margin: 2em 0em 0.66em 0em;
-  padding: 0.5em 0em 0em 0em;
-  font-size: 1.5em;
-  font-weight: bold;
-}
-
-h3.subtitle {
-  margin: 0em 0em 1em 0em;
-  padding: 0em 0em 0em 0em;
-  font-size: 142.14%;
-  text-align: right;
-}
-
-h3 {
-  margin: 1em 0em 0.5em 0em;
-  padding: 1em 0em 0em 0em;
-  font-size: 140%;
-  font-weight: bold;
-}
-
-h4 {
-  margin: 1em 0em 0.5em 0em;
-  padding: 1em 0em 0em 0em;
-  font-size: 120%;
-  font-weight: bold;
-}
-
-h5 {
-  margin: 1em 0em 0.5em 0em;
-  padding: 1em 0em 0em 0em;
-  font-size: 110%;
-  font-weight: bold;
-}
-
-h6 {
-  margin: 1em 0em 0em 0em;
-  padding: 1em 0em 0em 0em;
-  font-size: 110%;
-  font-weight: bold;
-}
-
-.authorgroup {
-  background-color: transparent;
-  background-repeat: no-repeat;
-  padding-top: 256px;
-  background-image: url("figures/kernel-title.png");
-  background-position: left top;
-  margin-top: -256px;
-  padding-right: 50px;
-  margin-left: 0px;
-  text-align: right;
-  width: 740px;
-}
-
-h3.author {
-  margin: 0em 0me 0em 0em;
-  padding: 0em 0em 0em 0em;
-  font-weight: normal;
-  font-size: 100%;
-  color: #333;
-  clear: both;
-}
-
-.author tt.email {
-  font-size: 66%;
-}
-
-.titlepage hr {
-  width: 0em;
-  clear: both;
-}
-
-.revhistory {
-  padding-top: 2em;
-  clear: both;
-}
-
-.toc,
-.list-of-tables,
-.list-of-examples,
-.list-of-figures {
-  padding: 1.33em 0em 2.5em 0em;
-  color: #00557D;
-}
-
-.toc p,
-.list-of-tables p,
-.list-of-figures p,
-.list-of-examples p {
-  padding: 0em 0em 0em 0em;
-  padding: 0em 0em 0.3em;
-  margin: 1.5em 0em 0em 0em;
-}
-
-.toc p b,
-.list-of-tables p b,
-.list-of-figures p b,
-.list-of-examples p b{
-  font-size: 100.0%;
-  font-weight: bold;
-}
-
-.toc dl,
-.list-of-tables dl,
-.list-of-figures dl,
-.list-of-examples dl {
-  margin: 0em 0em 0.5em 0em;
-  padding: 0em 0em 0em 0em;
-}
-
-.toc dt {
-  margin: 0em 0em 0em 0em;
-  padding: 0em 0em 0em 0em;
-}
-
-.toc dd {
-  margin: 0em 0em 0em 2.6em;
-  padding: 0em 0em 0em 0em;
-}
-
-div.glossary dl,
-div.variablelist dl {
-}
-
-.glossary dl dt,
-.variablelist dl dt,
-.variablelist dl dt span.term {
-  font-weight: normal;
-  width: 20em;
-  text-align: right;
-}
-
-.variablelist dl dt {
-  margin-top: 0.5em;
-}
-
-.glossary dl dd,
-.variablelist dl dd {
-  margin-top: -1em;
-  margin-left: 25.5em;
-}
-
-.glossary dd p,
-.variablelist dd p {
-  margin-top: 0em;
-  margin-bottom: 1em;
-}
-
-
-div.calloutlist table td {
-  padding: 0em 0em 0em 0em;
-  margin: 0em 0em 0em 0em;
-}
-
-div.calloutlist table td p {
-  margin-top: 0em;
-  margin-bottom: 1em;
-}
-
-div p.copyright {
-  text-align: left;
-}
-
-div.legalnotice p.legalnotice-title {
-  margin-bottom: 0em;
-}
-
-p {
-  line-height: 1.5em;
-  margin-top: 0em;
-  
-}
-
-dl {
-  padding-top: 0em;
-}
-
-hr {
-  border: solid 1px;
-}
-
-
-.mediaobject,
-.mediaobjectco {
-  text-align: center;
-}
-
-img {
-  border: none;
-}
-
-ul {
-  padding: 0em 0em 0em 1.5em;
-}
-
-ul li {
-  padding: 0em 0em 0em 0em;
-}
-
-ul li p {
-  text-align: left;
-}
-
-table {
-  width :100%;
-}
-
-th {
-  padding: 0.25em;
-  text-align: left;
-  font-weight: normal;
-  vertical-align: top;
-}
-
-td {
-  padding: 0.25em;
-  vertical-align: top;
-}
-
-p a[id] {
-  margin: 0px;
-  padding: 0px;
-  display: inline;
-  background-image: none;
-} 
-
-a {
-  text-decoration: underline;
-  color: #444;
-}
-
-pre {
-    overflow: auto;
-}
-
-a:hover {
-  text-decoration: underline;
-  /*font-weight: bold;*/
-}
-
-
-div.informalfigure,
-div.informalexample,
-div.informaltable,
-div.figure,
-div.table,
-div.example {
-  margin: 1em 0em;
-  padding: 1em;
-  page-break-inside: avoid;
-}
-
-
-div.informalfigure p.title b,
-div.informalexample p.title b,
-div.informaltable p.title b,
-div.figure p.title b,
-div.example p.title b,
-div.table p.title b{
-    padding-top: 0em;
-    margin-top: 0em;
-    font-size: 100%;
-    font-weight: normal;
-}
-
-.mediaobject .caption, 
-.mediaobject .caption p  {
-  text-align: center;
-  font-size: 80%;  
-  padding-top: 0.5em;
-  padding-bottom: 0.5em;
-}
-
-.epigraph {
-  padding-left: 55%;
-  margin-bottom: 1em;
-}
-
-.epigraph p {
-  text-align: left;
-}
-
-.epigraph .quote {
-  font-style: italic;
-}
-.epigraph .attribution {
-  font-style: normal;
-  text-align: right;
-}
-
-span.application {
-  font-style: italic;
-}
-
-.programlisting {
-  font-family: monospace;
-  font-size: 80%;
-  white-space: pre;
-  margin: 1.33em 0em;
-  padding: 1.33em;
-}
-
-.tip,
-.warning,
-.caution,
-.note {
-  margin-top: 1em;
-  margin-bottom: 1em;
-
-}
-
-/* force full width of table within div */
-.tip table,
-.warning table,
-.caution table,
-.note table {
-  border: none;
-  width: 100%;
-}
-
-
-.tip table th,
-.warning table th,
-.caution table th,
-.note table th {
-  padding: 0.8em 0.0em 0.0em 0.0em;
-  margin : 0em 0em 0em 0em;
-}
-
-.tip p,
-.warning p,
-.caution p,
-.note p {
-  margin-top: 0.5em;
-  margin-bottom: 0.5em;
-  padding-right: 1em;
-  text-align: left;
-}
-
-.acronym {
-  text-transform: uppercase;
-}
-
-b.keycap,
-.keycap {
-  padding: 0.09em 0.3em;
-  margin: 0em;
-}
-
-.itemizedlist li {
-  clear: none;
-}
-
-.filename {
-  font-size: medium;
-  font-family: Courier, monospace;
-}
-
-
-div.navheader, div.heading{
-  position: absolute;
-  left: 0em;
-  top: 0em;
-  width: 100%;
-  background-color: #cdf;
-  width: 100%;
-}
-
-div.navfooter, div.footing{
-  position: fixed;
-  left: 0em;
-  bottom: 0em;
-  background-color: #eee;
-  width: 100%;
-}
-
-
-div.navheader td,
-div.navfooter td {
-  font-size: 66%;
-}
-
-div.navheader table th {
-  /*font-family: Georgia, Times, serif;*/
-  /*font-size: x-large;*/
-  font-size: 80%;
-}
-
-div.navheader table {
-  border-left: 0em;
-  border-right: 0em;
-  border-top: 0em;
-  width: 100%;
-}
-
-div.navfooter table {
-  border-left: 0em;
-  border-right: 0em;
-  border-bottom: 0em;
-  width: 100%;
-}
-
-div.navheader table td a,
-div.navfooter table td a {
-  color: #777;
-  text-decoration: none;
-}
-
-/* normal text in the footer */
-div.navfooter table td {
-  color: black;
-}
-
-div.navheader table td a:visited,
-div.navfooter table td a:visited {
-  color: #444;
-}
-
-
-/* links in header and footer */
-div.navheader table td a:hover,
-div.navfooter table td a:hover {
-  text-decoration: underline;
-  background-color: transparent;
-  color: #33a;
-}
-
-div.navheader hr,
-div.navfooter hr {
-  display: none;
-}
-
-
-.qandaset tr.question td p {
-  margin: 0em 0em 1em 0em;
-  padding: 0em 0em 0em 0em;
-}
-
-.qandaset tr.answer td p {
-  margin: 0em 0em 1em 0em;
-  padding: 0em 0em 0em 0em;
-}
-.answer td {
-  padding-bottom: 1.5em;
-}
-
-.emphasis {
-  font-weight: bold;
-}
-
-
-  /************* /
- / decorations  /
-/ *************/
-
-.titlepage {
-}
-
-.part .title {
-}
-
-.subtitle {
-    border: none;
-}
-
-/*
-h1 {
-  border: none;
-}
-
-h2 {
-  border-top: solid 0.2em;
-  border-bottom: solid 0.06em;
-}
-
-h3 {
-  border-top: 0em;
-  border-bottom: solid 0.06em;
-}
-
-h4 {
-  border: 0em;
-  border-bottom: solid 0.06em;
-}
-
-h5 {
-  border: 0em;
-}
-*/
-
-.programlisting {
-  border: solid 1px;
-}
-
-div.figure,
-div.table,
-div.informalfigure,
-div.informaltable,
-div.informalexample,
-div.example {
-  border: 1px solid;
-}
-
-
-
-.tip,
-.warning,
-.caution,
-.note {
-  border: 1px solid;
-}
-
-.tip table th,
-.warning table th,
-.caution table th,
-.note table th {
-  border-bottom: 1px solid;
-}
-
-.question td {
-  border-top: 1px solid black;
-}
-
-.answer {
-}
-
-
-b.keycap,
-.keycap {
-  border: 1px solid;
-}
-  
-
-div.navheader, div.heading{
-  border-bottom: 1px solid;
-}
-
-
-div.navfooter, div.footing{
-  border-top: 1px solid;
-}
-
-  /********* /
- /  colors  /
-/ *********/
-
-body {
-  color: #333;
-  background: white;
-}
-
-a {
-  background: transparent;
-}
-
-a:hover {
-  background-color: #dedede;
-}
-
-
-h1,
-h2,
-h3,
-h4,
-h5,
-h6,
-h7,
-h8 {
-  background-color: transparent;
-}
-
-hr {
-  border-color: #aaa;
-}
-
-
-.tip, .warning, .caution, .note {
-  border-color: #fff;
-}
-
-
-.tip table th,
-.warning table th,
-.caution table th,
-.note table th {
-  border-bottom-color: #fff;
-}
-
-
-.warning {
-  background-color: #f0f0f2;
-}
-
-.caution {
-  background-color: #f0f0f2;
-}
-
-.tip {
-  background-color: #f0f0f2;
-}
-
-.note {
-  background-color: #f0f0f2; 
-}
-
-.glossary dl dt, 
-.variablelist dl dt,
-.variablelist dl dt span.term {
-  color: #044;
-}
-
-div.figure,
-div.table,
-div.example,
-div.informalfigure,
-div.informaltable,
-div.informalexample {
-  border-color: #aaa;
-}
-
-pre.programlisting {
-  color: black;
-  background-color: #fff;
-  border-color: #aaa;
-  border-width: 2px;
-}
-
-.guimenu,
-.guilabel,
-.guimenuitem {
-  background-color: #eee;
-}
-
-
-b.keycap,
-.keycap {
-  background-color: #eee;
-  border-color: #999;
-}
-
-
-div.navheader {
-  border-color: black;
-}
-
-
-div.navfooter {
-  border-color: black;
-}
-
-
-  /*********** /
- /  graphics  /
-/ ***********/
-
-/*
-body {
-  background-image: url("images/body_bg.jpg");
-  background-attachment: fixed;
-}
-
-.navheader,
-.note,
-.tip {
-  background-image: url("images/note_bg.jpg");
-  background-attachment: fixed;
-}
-
-.warning,
-.caution {
-  background-image: url("images/warning_bg.jpg");
-  background-attachment: fixed;
-}
-
-.figure,
-.informalfigure,
-.example,
-.informalexample,
-.table,
-.informaltable {
-  background-image: url("images/figure_bg.jpg");
-  background-attachment: fixed;
-}
-
-*/
-h1,
-h2,
-h3,
-h4,
-h5,
-h6,
-h7{
-}
-
-/*
-Example of how to stick an image as part of the title.
-
-div.article .titlepage .title
-{
-  background-image: url("figures/white-on-black.png");
-  background-position: center;
-  background-repeat: repeat-x;
-}
-*/
-
-div.preface .titlepage .title, 
-div.colophon .title, 
-div.chapter .titlepage .title,
-div.article .titlepage .title 
-{
-}
-
-div.section div.section .titlepage .title,
-div.sect2 .titlepage .title {
-    background: none;
-}
-
-
-h1.title {
-  background-color: transparent;
-  background-image: url("figures/yocto-project-bw.png");
-  background-repeat: no-repeat;
-  height: 256px;
-  text-indent: -9000px;
-  overflow:hidden;
-}
-
-h2.subtitle {
-  background-color: transparent;
-  text-indent: -9000px;
-  overflow:hidden;
-  width: 0px;
-  display: none;
-}
-
-  /*************************************** /
- /  pippin.gimp.org specific alterations  /
-/ ***************************************/
-
-/*
-div.heading, div.navheader {
-  color: #777;
-  font-size: 80%;
-  padding: 0;
-  margin: 0;
-  text-align: left;
-  position: absolute;
-  top: 0px;
-  left: 0px;
-  width: 100%;
-  height: 50px;
-  background: url('/gfx/heading_bg.png') transparent;
-  background-repeat: repeat-x;
-  background-attachment: fixed;
-  border: none;
-}
-
-div.heading a {
-  color: #444;
-}
-
-div.footing, div.navfooter {
-  border: none;
-  color: #ddd;
-  font-size: 80%;
-  text-align:right;
-
-  width: 100%;
-  padding-top: 10px;
-  position: absolute;
-  bottom: 0px;
-  left: 0px;
-
-  background: url('/gfx/footing_bg.png') transparent;
-}
-*/
-
-
-
-  /****************** /
- /  nasty ie tweaks  /
-/ ******************/
-
-/*
-div.heading, div.navheader {
-  width:expression(document.body.clientWidth + "px");
-}
-
-div.footing, div.navfooter {
-  width:expression(document.body.clientWidth + "px");
-  margin-left:expression("-5em");
-}
-body {
-  padding:expression("4em 5em 0em 5em");
-}
-*/
-
-  /**************************************** /
- / mozilla vendor specific css extensions  /
-/ ****************************************/
-/*
-div.navfooter, div.footing{
-  -moz-opacity: 0.8em;
-}
-
-div.figure,
-div.table,
-div.informalfigure,
-div.informaltable,
-div.informalexample,
-div.example,
-.tip,
-.warning,
-.caution,
-.note {
-  -moz-border-radius: 0.5em;
-}
-
-b.keycap,
-.keycap {
-  -moz-border-radius: 0.3em;
-}
-*/
-
-table tr td table tr td {
-  display: none;
-}
-
-
-hr {
-  display: none;
-}
-
-table {
-  border: 0em;
-}
-
- .photo {
-  float: right;
-  margin-left:   1.5em;
-  margin-bottom: 1.5em;
-  margin-top: 0em;
-  max-width:      17em;
-  border:     1px solid gray;
-  padding:    3px;
-  background: white;
-}
- .seperator {
-   padding-top: 2em;
-   clear: both;
-  }
-
-  #validators {
-      margin-top: 5em;
-      text-align: right;
-      color: #777;
-  }
-  @media print {
-      body {
-          font-size: 8pt;
-      }
-      .noprint {
-          display: none;
-      }
-  }
-
-
-.tip,
-.note {
-   background: #f0f0f2; 
-   color: #333;   
-   padding: 20px;
-   margin: 20px;
-}
-
-.tip h3,
-.note h3 {
-   padding: 0em;
-   margin: 0em;
-   font-size: 2em;
-   font-weight: bold;
-   color: #333;   
-}
-
-.tip a,
-.note a {
-   color: #333;   
-   text-decoration: underline;
-}
-
-.footnote {
-   font-size: small;
-   color: #333;
-}
-
-/* Changes the announcement text */
-.tip h3,
-.warning h3,
-.caution h3,
-.note h3 {
-   font-size:large;
-   color: #00557D;
-}
-

documentation/ref-manual/faq.xml

@@ -78,7 +78,7 @@
                     <listitem><para>The Yocto Project team runs manual and automated tests
                         using a small, fixed set of reference hardware as well as emulated
                         targets.</para></listitem>
-                    <listitem><para>The Yocto Project uses an an autobuilder,
+                    <listitem><para>The Yocto Project uses an autobuilder,
                         which provides continuous build and integration tests.</para></listitem>
                 </itemizedlist>
             </para>
@@ -134,10 +134,10 @@
         </question>
         <answer>
             <para>
-                Because you can use the same set of recipes to create output of 
-                various formats, the output of an OpenEmbedded build depends on 
+                Because you can use the same set of recipes to create output of
+                various formats, the output of an OpenEmbedded build depends on
                 how you start it.
-                Usually, the output is a flashable image ready for the target 
+                Usually, the output is a flashable image ready for the target
                 device.
             </para>
         </answer>
@@ -168,12 +168,12 @@
         </question>
         <answer>
             <para>
-                The OpenEmbedded build system can build packages in various 
-                formats such as IPK for OPKG, Debian package 
+                The OpenEmbedded build system can build packages in various
+                formats such as IPK for OPKG, Debian package
                 (<filename>.deb</filename>), or RPM.
-                You can then upgrade the packages using the package tools on 
-                the device, much like on a desktop distribution such as 
-                Ubuntu or Fedora. 
+                You can then upgrade the packages using the package tools on
+                the device, much like on a desktop distribution such as
+                Ubuntu or Fedora.
                 However, package management on the target is entirely optional.
             </para>
         </answer>
@@ -189,7 +189,7 @@
             <para>
                 GNOME Mobile is a subset of the <ulink url='http://www.gnome.org'>GNOME</ulink>
                 platform targeted at mobile and embedded devices.
-                The the main difference between GNOME Mobile and standard GNOME is that
+                The main difference between GNOME Mobile and standard GNOME is that
                 desktop-orientated libraries have been removed, along with deprecated libraries,
                 creating a much smaller footprint.
             </para>
@@ -249,7 +249,7 @@
 
             <note>
                 <para>For information on distributions that the Yocto Project
-                uses during validation, see the 
+                uses during validation, see the
                 <ulink url='&YOCTO_WIKI_URL;/wiki/Distribution_Support'>Distribution Support</ulink>
                 Wiki page.</para>
                 <para>For notes about using the Yocto Project on a RHEL 4-based
@@ -297,8 +297,8 @@
                 </filename> = "0" in the <filename>.bb</filename> file but make sure the package is
                 manually marked as
                 machine-specific for the case that needs it.
-                The code that handles 
-                <filename>SRC_URI_OVERRIDES_PACKAGE_ARCH</filename> is in 
+                The code that handles
+                <filename>SRC_URI_OVERRIDES_PACKAGE_ARCH</filename> is in
                 the <filename>meta/classes/base.bbclass</filename> file.
             </para>
         </answer>
@@ -320,8 +320,8 @@
      http_proxy = http://proxy.yoyodyne.com:18023/
      ftp_proxy = http://proxy.yoyodyne.com:18023/
                 </literallayout>
-                The Yocto Project also includes a 
-                <filename>site.conf.sample</filename> file that shows how to 
+                The Yocto Project also includes a
+                <filename>site.conf.sample</filename> file that shows how to
                 configure CVS and Git proxy servers if needed.
             </para>
         </answer>
@@ -352,19 +352,19 @@
         </question>
         <answer>
             <para>
-                If the same build is failing in totally different and random 
+                If the same build is failing in totally different and random
                 ways, the most likely explanation is:
                 <itemizedlist>
-                    <listitem><para>The hardware you are running the build on 
+                    <listitem><para>The hardware you are running the build on
                         has some problem.</para></listitem>
-                    <listitem><para>You are running the build under 
-                        virtualization, in which case the virtualization 
-                        probably has bugs.</para></listitem>   
+                    <listitem><para>You are running the build under
+                        virtualization, in which case the virtualization
+                        probably has bugs.</para></listitem>
                 </itemizedlist>
-                The OpenEmbedded build system processes a massive amount of 
-                data that causes lots of network, disk and CPU activity and 
+                The OpenEmbedded build system processes a massive amount of
+                data that causes lots of network, disk and CPU activity and
                 is sensitive to even single-bit failures in any of these areas.
-                True random failures have always been traced back to hardware 
+                True random failures have always been traced back to hardware
                 or virtualization issues.
             </para>
         </answer>
@@ -378,18 +378,18 @@
         </question>
         <answer>
             <para>
-                This is a difficult question and you need to consult your lawyer 
+                This is a difficult question and you need to consult your lawyer
                 for the answer for your specific case.
-                It is worth bearing in mind that for GPL compliance, there needs 
-                to be enough information shipped to allow someone else to 
+                It is worth bearing in mind that for GPL compliance, there needs
+                to be enough information shipped to allow someone else to
                 rebuild and produce the same end result you are shipping.
-                This means sharing the source code, any patches applied to it, 
-                and also any configuration information about how that package 
+                This means sharing the source code, any patches applied to it,
+                and also any configuration information about how that package
                 was configured and built.
             </para>
 
             <para>
-                You can find more information on licensing in the 
+                You can find more information on licensing in the
                 "<ulink url='&YOCTO_DOCS_DEV_URL;#licensing'>Licensing</ulink>"
                 and "<ulink url='&YOCTO_DOCS_DEV_URL;#maintaining-open-source-license-compliance-during-your-products-lifecycle'>Maintaining Open Source License Compliance During Your Product's Lifecycle</ulink>"
                 sections, both of which are in the Yocto Project Development
@@ -410,7 +410,7 @@
                 "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-filelayout-misc-recipes'>Miscellaneous BSP-Specific Recipe Files</ulink>"
                 section in the Yocto Project Board Support Packages (BSP)
                 Developer's Guide.
-                Set the <filename>HAVE_TOUCHSCREEN</filename> variable equal to 
+                Set the <filename>HAVE_TOUCHSCREEN</filename> variable equal to
                 one as follows:
                 <literallayout class='monospaced'>
      HAVE_TOUCHSCREEN=1
@@ -433,7 +433,7 @@
                 file.
                 See the "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-filelayout-misc-recipes'>Miscellaneous BSP-Specific Recipe Files</ulink>"
                 section in the Yocto Project Board Support Packages (BSP)
-                Developer's Guide for information on creating these types of 
+                Developer's Guide for information on creating these types of
                 miscellaneous recipe files.
             </para>
             <para>
@@ -454,32 +454,32 @@
         </question>
         <answer>
             <para>
-                By default, the OpenEmbedded build system creates images 
+                By default, the OpenEmbedded build system creates images
                 that are 1.3 times the size of the populated root filesystem.
-                To affect the image size, you need to set various 
+                To affect the image size, you need to set various
                 configurations:
                 <itemizedlist>
                     <listitem><para><emphasis>Image Size:</emphasis>
-                        The OpenEmbedded build system uses the 
+                        The OpenEmbedded build system uses the
                         <link linkend='var-IMAGE_ROOTFS_SIZE'><filename>IMAGE_ROOTFS_SIZE</filename></link>
-                        variable to define the size of the image in Kbytes. 
-                        The build system determines the size by taking into 
+                        variable to define the size of the image in Kbytes.
+                        The build system determines the size by taking into
                         account the initial root filesystem size before any
-                        modifications such as requested size for the image and 
-                        any requested additional free disk space to be 
+                        modifications such as requested size for the image and
+                        any requested additional free disk space to be
                         added to the image.</para></listitem>
                     <listitem><para><emphasis>Overhead:</emphasis>
-                        Use the 
+                        Use the
                         <link linkend='var-IMAGE_OVERHEAD_FACTOR'><filename>IMAGE_OVERHEAD_FACTOR</filename></link>
-                        variable to define the multiplier that the build system 
-                        applies to the initial image size, which is 1.3 by 
+                        variable to define the multiplier that the build system
+                        applies to the initial image size, which is 1.3 by
                         default.</para></listitem>
                     <listitem><para><emphasis>Additional Free Space:</emphasis>
-                        Use the 
+                        Use the
                         <link linkend='var-IMAGE_ROOTFS_EXTRA_SPACE'><filename>IMAGE_ROOTFS_EXTRA_SPACE</filename></link>
                         variable to add additional free space to the image.
                         The build system adds this space to the image after
-                        it determines its 
+                        it determines its
                         <filename>IMAGE_ROOTFS_SIZE</filename>.
                         </para></listitem>
                 </itemizedlist>
@@ -495,11 +495,11 @@
         </question>
         <answer>
             <para>
-                The Yocto Project team has tried to do this before but too 
-                many of the tools the OpenEmbedded build system depends on, 
-                such as <filename>autoconf</filename>, break when they find 
+                The Yocto Project team has tried to do this before but too
+                many of the tools the OpenEmbedded build system depends on,
+                such as <filename>autoconf</filename>, break when they find
                 spaces in pathnames.
-                Until that situation changes, the team will not support spaces 
+                Until that situation changes, the team will not support spaces
                 in pathnames.
             </para>
         </answer>
@@ -515,11 +515,11 @@
             <para>
                 The toolchain configuration is very flexible and customizable.
                 It is primarily controlled with the
-                <filename><link linkend='var-TCMODE'>TCMODE</link></filename> 
+                <filename><link linkend='var-TCMODE'>TCMODE</link></filename>
                 variable.
-                This variable controls which <filename>tcmode-*.inc</filename> 
-                file to include from the 
-                <filename>meta/conf/distro/include</filename> directory within 
+                This variable controls which <filename>tcmode-*.inc</filename>
+                file to include from the
+                <filename>meta/conf/distro/include</filename> directory within
                 the
                 <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
             </para>
@@ -528,33 +528,37 @@
                 The default value of <filename>TCMODE</filename> is "default"
                 (i.e. <filename>tcmode-default.inc</filename>).
                 However, other patterns are accepted.
-                In particular, "external-*" refers to external toolchains of 
-                which there are some basic examples included in the 
+                In particular, "external-*" refers to external toolchains of
+                which there are some basic examples included in the
                 OpenEmbedded Core (<filename>meta</filename>).
-                You can use your own custom toolchain definition in your own 
-                layer (or as defined in the <filename>local.conf</filename> 
+                You can use your own custom toolchain definition in your own
+                layer (or as defined in the <filename>local.conf</filename>
                 file) at the location
                 <filename>conf/distro/include/tcmode-*.inc</filename>.
             </para>
 
             <para>
-                In addition to the toolchain configuration, you also need a 
+                In addition to the toolchain configuration, you also need a
                 corresponding toolchain recipe file.
-                This recipe file needs to package up any pre-built objects in 
-                the toolchain such as <filename>libgcc</filename>, 
-                <filename>libstdcc++</filename>, any locales, and 
+                This recipe file needs to package up any pre-built objects in
+                the toolchain such as <filename>libgcc</filename>,
+                <filename>libstdcc++</filename>, any locales, and
                 <filename>libc</filename>.
-                An example is the 
-                <filename>external-sourcery-toolchain.bb</filename>, which is 
-                located in <filename>meta/recipes-core/meta/</filename> within 
+                An example is the
+                <filename>external-sourcery-toolchain.bb</filename>, which is
+                located in <filename>meta/recipes-core/meta/</filename> within
                 the Source Directory.
             </para>
 
             <para>
-                For information on installing and using cross-development 
-                toolchains, see the 
+                For information on installing and using cross-development
+                toolchains, see the
                 "<ulink url='&YOCTO_DOCS_ADT_URL;#installing-the-adt'>Installing the ADT and Toolchains</ulink>"
                 section in the Yocto Project Application Developer's Guide.
+                For general information on cross-development toolchains, see
+                the
+                "<link linkend='cross-development-toolchain-generation'>Cross-Development Toolchain Generation</link>"
+                section.
             </para>
         </answer>
     </qandaentry>
@@ -625,7 +629,7 @@
                  <literallayout class='monospaced'>
      BB_FETCH_PREMIRRORONLY = "1"
                  </literallayout>
-                 This statement limits the build system to pulling source 
+                 This statement limits the build system to pulling source
                  from the <filename>PREMIRRORS</filename> only.
                  Again, this technique is useful for reproducing builds.
              </para>
@@ -634,7 +638,7 @@
                  <literallayout class='monospaced'>
      BB_GENERATE_MIRROR_TARBALLS = "1"
                  </literallayout>
-                 This statement tells the build system to generate mirror 
+                 This statement tells the build system to generate mirror
                  tarballs.
                  This technique is useful if you want to create a mirror server.
                  If not, however, the technique can simply waste time during
@@ -677,8 +681,8 @@
         <answer>
             <para>
                 Yes - you can easily do this.
-                When you use BitBake to build an image, all the build output 
-                goes into the directory created when you source the 
+                When you use BitBake to build an image, all the build output
+                goes into the directory created when you source the
                 <link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>
                 setup script.
                 By default, this <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
@@ -687,10 +691,10 @@
             </para>
 
             <para>
-                Within the Build Directory, is the <filename>tmp</filename> 
+                Within the Build Directory, is the <filename>tmp</filename>
                 directory.
-                To remove all the build output yet preserve any source code or 
-                downloaded files from previous builds, simply remove the 
+                To remove all the build output yet preserve any source code or
+                downloaded files from previous builds, simply remove the
                 <filename>tmp</filename> directory.
             </para>
         </answer>

documentation/ref-manual/introduction.xml

@@ -101,7 +101,37 @@
         <title>Supported Linux Distributions</title>
 
         <para>
-            Currently, the Yocto Project is supported on the following distributions:
+            Currently, the Yocto Project is supported on the following
+            distributions:
+            <note>
+                <para>
+                    Yocto Project releases are tested against the stable Linux
+                    distributions in the following list.
+                    The Yocto Project should work on other distributions but
+                    validation is not performed against them.
+                </para>
+
+                <para>
+                    In particular, the Yocto Project does not support
+                    and currently has no plans to support
+                    rolling-releases or development distributions due to their
+                    constantly changing nature.
+                    We welcome patches and bug reports, but keep in mind that
+                    our priority is on the supported platforms listed below.
+                </para>
+
+                <para>
+                    Refer to
+                    <ulink url='&OE_HOME_URL;/index.php?title=OEandYourDistro'>OE and Your Distro</ulink> and
+                    <ulink url='&OE_HOME_URL;/index.php?title=Required_software'>Required Software</ulink>
+                    for information for information about dependencies and
+                    requirements.
+                    If you encounter problems, please go to
+                    <ulink url='&YOCTO_BUGZILLA_URL;'>Yocto Project Bugzilla</ulink>
+                    and submit a bug.
+                    We are interested in hearing about your experience.
+                </para>
+            </note>
             <itemizedlist>
                 <listitem><para>Ubuntu 10.04</para></listitem>
                 <listitem><para>Ubuntu 11.10</para></listitem>
@@ -112,17 +142,23 @@
                 <listitem><para>Fedora release 18 (Spherical Cow)</para></listitem>
                 <listitem><para>CentOS release 6.3 (Final)</para></listitem>
                 <listitem><para>CentOS release 6.4 (Final)</para></listitem>
-                <listitem><para>Debian GNU/Linux 6.0 (squeeze)</para></listitem>
-                <listitem><para>Debian GNU/Linux 7.0</para></listitem>
+                <listitem><para>Debian GNU/Linux 6.0 (Squeeze)</para></listitem>
+                <listitem><para>Debian GNU/Linux 7.0 (Wheezy)</para></listitem>
                 <listitem><para>openSUSE 12.2</para></listitem>
                 <listitem><para>openSUSE 12.3</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.
+            While the Yocto Project Team attempts to ensure all Yocto Project
+            releases are one hundred percent compatible with each officially
+            supported Linux distribution, instances might exist where you
+            encounter a problem while using the Yocto Project on a specific
+            distribution.
+            For example, the CentOS 6.4 distribution does not include the
+            Gtk+ 2.20.0 and PyGtk 2.21.0 (or higher) packages, which are
+            required to run
+            <ulink url='&YOCTO_HOME_URL;/tools-resources/projects/hob'>Hob</ulink>.
         </note>
     </section>
 
@@ -137,11 +173,11 @@
         </para>
 
         <section id='ubuntu-packages'>
-            <title>Ubuntu</title>
+            <title>Ubuntu and Debian</title>
 
             <para>
                 The following list shows the required packages by function
-                given a supported Ubuntu Linux distribution:
+                given a supported Ubuntu or Debian Linux distribution:
                 <itemizedlist>
                     <listitem><para><emphasis>Essentials:</emphasis>
                         Packages needed to build an image on a headless
@@ -245,40 +281,117 @@
             <para>
                 The following list shows the required packages by function
                 given a supported CentOS Linux distribution:
+                <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>
                 <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;
+     $ sudo yum 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
+     $ 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 -y install make docbook-style-dsssl docbook-style-xsl \
+     $ sudo yum install make docbook-style-dsssl docbook-style-xsl \
      docbook-dtds docbook-utils fop libxslt dblatex xmlto
                         </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
+     $ sudo yum 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 id='required-git-tar-and-python-versions'>
+        <title>Required Git, tar, and Python Versions</title>
+
+        <para>
+            In order to use the build system, your host development system
+            must meet the following version requirements for Git, tar, and
+            Python:
+            <itemizedlist>
+                <listitem><para>Git 1.7.5 or greater</para></listitem>
+                <listitem><para>tar 1.24 or greater</para></listitem>
+                <listitem><para>Python 2.7.3 or greater not including
+                    Python 3.x, which is not supported.</para></listitem>
+            </itemizedlist>
+        </para>
+
+        <para>
+            If your host development system does not meet all these requirements,
+            you can resolve this by either downloading a pre-built tarball
+            containing these tools, or building such a tarball on another
+            system.
+            Regardless of the method, once you have the tarball you simply
+            install it somewhere on you system, such as a directory in your
+            home directory, and then source the environment script provided,
+            which adds the tools into <filename>PATH</filename> and sets
+            any other environment variables required to run the tools.
+            Doing so gives you working versions of Git, tar, Python and
+            <filename>chrpath</filename>.
+        </para>
+
+        <para>
+            If downloading a pre-built tarball, locate the
+            <filename>*.sh</filename> at
+            <ulink url='&YOCTO_DL_URL;/releases/yocto/yocto-1.5/buildtools/'></ulink>.
+        </para>
+
+        <para>
+            If building your own tarball, do so using this command:
+            <literallayout class='monospaced'>
+     $ bitbake buildtools-tarball
+            </literallayout>
+            <note>
+                The <link linkend='var-SDKMACHINE'><filename>SDKMACHINE</filename></link>
+                variable determines whether you build tools for a 32-bit
+                or 64-bit system.
+            </note>
+            Once the build completes, you can find the file that installs the
+            the tools in the <filename>tmp/deploy/sdk</filename> subdirectory
+            of the
+            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+            The file used to install the tarball has the string "buildtools"
+            in the name.
+        </para>
+
+        <para>
+            After you have either built the tarball or downloaded it, you need
+            to install it.
+            Install the tools by executing the <filename>*.sh</filename> file.
+            During execution, a prompt appears that allows you to choose the
+            installation directory.
+            For example, you could choose the following:
+            <literallayout class='monospaced'>
+     /home/your-username/sdk
+            </literallayout>
+        </para>
+
+        <para>
+            The final step before you can actually use the tools is to source
+            the tools environment with a command like the following:
+            <literallayout class='monospaced'>
+     $ source /home/your-username/sdk/environment-setup-i586-poky-linux
+            </literallayout>
+            Of course, you need to supply your installation directory and be
+            sure to use the right file (i.e. i585 or x86-64).
+        </para>
+    </section>
 </section>
 
 <section id='intro-getit'>

documentation/ref-manual/migration.xml

@@ -247,30 +247,30 @@
             Differences include the following:
             <itemizedlist>
                 <listitem><para><emphasis>Comment Continuation:</emphasis>
-                    If a comment ends with a line continuation (\) character, 
+                    If a comment ends with a line continuation (\) character,
                     then the next line must also be a comment.
-                    Any instance where this is not the case, now triggers 
-                    a warning. 
-                    You must either remove the continuation character, or be 
+                    Any instance where this is not the case, now triggers
+                    a warning.
+                    You must either remove the continuation character, or be
                     sure the next line is a comment.
                     </para></listitem>
                 <listitem><para><emphasis>Package Name Overrides:</emphasis>
-                    The runtime package specific variables 
+                    The runtime package specific variables
                     <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>,
                     <link linkend='var-RRECOMMENDS'><filename>RRECOMMENDS</filename></link>,
-                    <link linkend='var-RSUGGESTS'><filename>RSUGGESTS</filename></link>, 
+                    <link linkend='var-RSUGGESTS'><filename>RSUGGESTS</filename></link>,
                     <link linkend='var-RPROVIDES'><filename>RPROVIDES</filename></link>,
                     <link linkend='var-RCONFLICTS'><filename>RCONFLICTS</filename></link>,
                     <link linkend='var-RREPLACES'><filename>RREPLACES</filename></link>,
                     <link linkend='var-FILES'><filename>FILES</filename></link>,
                     <link linkend='var-ALLOW_EMPTY'><filename>ALLOW_EMPTY</filename></link>,
-                    and the pre, post, install, and uninstall script functions 
-                    <filename>pkg_preinst</filename>, 
-                    <filename>pkg_postinst</filename>, 
-                    <filename>pkg_prerm</filename>, and 
+                    and the pre, post, install, and uninstall script functions
+                    <filename>pkg_preinst</filename>,
+                    <filename>pkg_postinst</filename>,
+                    <filename>pkg_prerm</filename>, and
                     <filename>pkg_postrm</filename> should always have a
                     package name override.
-                    For example, use <filename>RDEPENDS_${PN}</filename> for 
+                    For example, use <filename>RDEPENDS_${PN}</filename> for
                     the main package instead of <filename>RDEPENDS</filename>.
                     BitBake uses more strict checks when it parses recipes.
                     </para></listitem>
@@ -285,33 +285,34 @@
             Differences include the following:
             <itemizedlist>
                 <listitem><para><emphasis>Shared State Code:</emphasis>
-                    The shared state code has been optimized to avoid running 
+                    The shared state code has been optimized to avoid running
                     unnecessary tasks.
-                    For example, 
-                    <filename>bitbake -c rootfs some-image</filename> from 
-                    shared state no longer populates the target sysroot 
+                    For example,
+                    <filename>bitbake -c rootfs some-image</filename> from
+                    shared state no longer populates the target sysroot
                     since that is not necessary.
-                    Instead, the system just needs to extract the output 
-                    package contents, re-create the packages, and construct 
-                    the root filesystem. 
-                    This change is unlikely to cause any problems unless 
+                    Instead, the system just needs to extract the output
+                    package contents, re-create the packages, and construct
+                    the root filesystem.
+                    This change is unlikely to cause any problems unless
                     you have missing declared dependencies.
                     </para></listitem>
                 <listitem><para><emphasis>Scanning Directory Names:</emphasis>
-                    When scanning for files in 
-                    <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>, 
-                    the build system now uses <filename>FILESOVERRIDES</filename>
-                    instead of <filename>OVERRIDES</filename> for the directory 
-                    names. 
+                    When scanning for files in
+                    <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>,
+                    the build system now uses
+                    <link linkend='var-FILESOVERRIDES'><filename>FILESOVERRIDES</filename></link>
+                    instead of <link linkend='var-OVERRIDES'><filename>OVERRIDES</filename></link>
+                    for the directory names.
                     In general, the values previously in
-                    <filename>OVERRIDES</filename> are now in 
+                    <filename>OVERRIDES</filename> are now in
                     <filename>FILESOVERRIDES</filename> as well.
-                    However, if you relied upon an additional value 
+                    However, if you relied upon an additional value
                     you previously added to <filename>OVERRIDES</filename>,
-                    you might now need to add it to 
-                    <filename>FILESOVERRIDES</filename> unless you are already 
-                    adding it through the 
-                    <link linkend='var-MACHINEOVERRIDES'><filename>MACHINEOVERRIDES</filename></link> 
+                    you might now need to add it to
+                    <filename>FILESOVERRIDES</filename> unless you are already
+                    adding it through the
+                    <link linkend='var-MACHINEOVERRIDES'><filename>MACHINEOVERRIDES</filename></link>
                     or <link linkend='var-DISTROOVERRIDES'><filename>DISTROOVERRIDES</filename></link>
                     variables, as appropriate.
                     For more related changes, see the
@@ -327,9 +328,9 @@
         <title>Proxies and Fetching Source</title>
 
         <para>
-            A new <filename>oe-git-proxy</filename> script has been added to 
-            replace previous methods of handling proxies and fetching source 
-            from Git. 
+            A new <filename>oe-git-proxy</filename> script has been added to
+            replace previous methods of handling proxies and fetching source
+            from Git.
             See the <filename>meta-yocto/conf/site.conf.sample</filename> file
             for information on how to use this script.
         </para>
@@ -339,15 +340,15 @@
         <title>Custom Interfaces File (netbase change)</title>
 
         <para>
-            If you have created your own custom 
-            <filename>etc/network/interfaces</filename> file by creating 
-            an append file for the <filename>netbase</filename> recipe, 
-            you now need to create an append file for the 
-            <filename>init-ifupdown</filename> recipe instead, which you can 
-            find in the 
+            If you have created your own custom
+            <filename>etc/network/interfaces</filename> file by creating
+            an append file for the <filename>netbase</filename> recipe,
+            you now need to create an append file for the
+            <filename>init-ifupdown</filename> recipe instead, which you can
+            find in the
             <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
             at <filename>meta/recipes-core/init-ifupdown</filename>.
-            For information on how to use append files, see the 
+            For information on how to use append files, see the
             "<ulink url='&YOCTO_DOCS_DEV_URL;#using-bbappend-files'>Using .bbappend Files</ulink>"
             in the Yocto Project Development Manual.
         </para>
@@ -357,12 +358,12 @@
         <title>Remote Debugging</title>
 
         <para>
-            Support for remote debugging with the Eclipse IDE is now 
-            separated into an image feature 
-            (<filename>eclipse-debug</filename>) that corresponds to the 
-            <filename>packagegroup-core-eclipse-debug</filename> package group. 
-            Previously, the debugging feature was included through the 
-            <filename>tools-debug</filename> image feature, which corresponds 
+            Support for remote debugging with the Eclipse IDE is now
+            separated into an image feature
+            (<filename>eclipse-debug</filename>) that corresponds to the
+            <filename>packagegroup-core-eclipse-debug</filename> package group.
+            Previously, the debugging feature was included through the
+            <filename>tools-debug</filename> image feature, which corresponds
             to the <filename>packagegroup-core-tools-debug</filename>
             package group.
         </para>
@@ -375,36 +376,36 @@
             The following variables have changed:
             <itemizedlist>
                 <listitem><para><emphasis><filename>SANITY_TESTED_DISTROS</filename>:</emphasis>
-                    This variable now uses a distribution ID, which is composed 
+                    This variable now uses a distribution ID, which is composed
                     of the host distributor ID followed by the release.
-                    Previously, 
+                    Previously,
                     <link linkend='var-SANITY_TESTED_DISTROS'><filename>SANITY_TESTED_DISTROS</filename></link>
                     was composed of the description field.
-                    For example, "Ubuntu 12.10" becomes "Ubuntu-12.10". 
-                    You do not need to worry about this change if you are not 
+                    For example, "Ubuntu 12.10" becomes "Ubuntu-12.10".
+                    You do not need to worry about this change if you are not
                     specifically setting this variable, or if you are
                     specifically setting it to "".
                     </para></listitem>
                 <listitem><para><emphasis><filename>SRC_URI</filename>:</emphasis>
-                    The <filename>${</filename><link linkend='var-PN'><filename>PN</filename></link><filename>}</filename>, 
-                    <filename>${</filename><link linkend='var-PF'><filename>PF</filename></link><filename>}</filename>, 
-                    <filename>${</filename><link linkend='var-P'><filename>P</filename></link><filename>}</filename>, 
-                    and <filename>FILE_DIRNAME</filename> directories have been 
-                    dropped from the default value of the 
+                    The <filename>${</filename><link linkend='var-PN'><filename>PN</filename></link><filename>}</filename>,
+                    <filename>${</filename><link linkend='var-PF'><filename>PF</filename></link><filename>}</filename>,
+                    <filename>${</filename><link linkend='var-P'><filename>P</filename></link><filename>}</filename>,
+                    and <filename>FILE_DIRNAME</filename> directories have been
+                    dropped from the default value of the
                     <link linkend='var-FILESPATH'><filename>FILESPATH</filename></link>
-                    variable, which is used as the search path for finding files 
-                    referred to in 
-                    <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>. 
-                    If you have a recipe that relied upon these directories, 
-                    which would be unusual, then you will need to add the 
+                    variable, which is used as the search path for finding files
+                    referred to in
+                    <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>.
+                    If you have a recipe that relied upon these directories,
+                    which would be unusual, then you will need to add the
                     appropriate paths within the recipe or, alternatively,
-                    rearrange the files. 
-                    The most common locations are still covered by 
+                    rearrange the files.
+                    The most common locations are still covered by
                     <filename>${BP}</filename>, <filename>${BPN}</filename>,
                     and "files", which all remain in the default value of
-                    <link linkend='var-FILESPATH'><filename>FILESPATH</filename></link>. 
+                    <link linkend='var-FILESPATH'><filename>FILESPATH</filename></link>.
                     </para></listitem>
-            </itemizedlist>           
+            </itemizedlist>
         </para>
     </section>
 
@@ -412,10 +413,10 @@
         <title>Target Package Management with RPM</title>
 
         <para>
-            If runtime package management is enabled and the RPM backend 
-            is selected, Smart is now installed for package download, dependency 
+            If runtime package management is enabled and the RPM backend
+            is selected, Smart is now installed for package download, dependency
             resolution, and upgrades instead of Zypper.
-            For more information on how to use Smart, run the following command 
+            For more information on how to use Smart, run the following command
             on the target:
             <literallayout class='monospaced'>
      smart --help
@@ -427,8 +428,8 @@
         <title>Recipes Moved</title>
 
         <para>
-            The following recipes were moved from their previous locations 
-            because they are no longer used by anything in  
+            The following recipes were moved from their previous locations
+            because they are no longer used by anything in
             the OpenEmbedded-Core:
             <itemizedlist>
                 <listitem><para><emphasis><filename>clutter-box2d</filename>:</emphasis>
@@ -478,7 +479,7 @@
             The following list shows what has been removed or renamed:
             <itemizedlist>
                 <listitem><para><emphasis><filename>evieext</filename>:</emphasis>
-                    Removed because it has been removed from 
+                    Removed because it has been removed from
                     <filename>xserver</filename> since 2008.
                     </para></listitem>
                 <listitem><para><emphasis>Gtk+ DirectFB:</emphasis>
@@ -489,7 +490,7 @@
                     Removed because they were removed from the Xorg server in 2008.
                     </para></listitem>
                 <listitem><para><emphasis><filename>libxp / libxprintapputil / libxprintutil / printproto</filename>:</emphasis>
-                    Removed because the XPrint server was removed from 
+                    Removed because the XPrint server was removed from
                     Xorg in 2008.
                     </para></listitem>
                 <listitem><para><emphasis><filename>libxtrap / xtrapproto</filename>:</emphasis>
@@ -501,7 +502,7 @@
                     as part of the release.
                     </para></listitem>
                 <listitem><para><emphasis><filename>lsbsetup</filename>:</emphasis>
-                    Removed with functionality now provided by 
+                    Removed with functionality now provided by
                     <filename>lsbtest</filename>.
                     </para></listitem>
                 <listitem><para><emphasis><filename>matchbox-stroke</filename>:</emphasis>
@@ -509,8 +510,8 @@
                     </para></listitem>
                 <listitem><para><emphasis><filename>matchbox-wm-2 / matchbox-theme-sato-2</filename>:</emphasis>
                     Removed because they are not maintained.
-                    However, <filename>matchbox-wm</filename> and  
-                    <filename>matchbox-theme-sato</filename> are still 
+                    However, <filename>matchbox-wm</filename> and
+                    <filename>matchbox-theme-sato</filename> are still
                     provided.
                     </para></listitem>
                 <listitem><para><emphasis><filename>mesa-dri</filename>:</emphasis>
@@ -520,7 +521,7 @@
                     Removed because it was no longer useful.
                     </para></listitem>
                 <listitem><para><emphasis><filename>mutter</filename>:</emphasis>
-                    Removed because nothing ever uses it and the recipe is 
+                    Removed because nothing ever uses it and the recipe is
                     very old.
                     </para></listitem>
                 <listitem><para><emphasis><filename>orinoco-conf</filename>:</emphasis>
@@ -528,27 +529,27 @@
                     </para></listitem>
                 <listitem><para><emphasis><filename>update-modules</filename>:</emphasis>
                     Removed because it is no longer used.
-                    The kernel module <filename>postinstall</filename> and 
-                    <filename>postrm</filename> scripts can now do the same 
+                    The kernel module <filename>postinstall</filename> and
+                    <filename>postrm</filename> scripts can now do the same
                     task without the use of this script.
                     </para></listitem>
                 <listitem><para><emphasis><filename>web</filename>:</emphasis>
-                    Removed because it is not maintained.  Superseded by 
+                    Removed because it is not maintained.  Superseded by
                     <filename>web-webkit</filename>.
                     </para></listitem>
                 <listitem><para><emphasis><filename>xf86bigfontproto</filename>:</emphasis>
-                    Removed because upstream it has been disabled by default 
+                    Removed because upstream it has been disabled by default
                     since 2007.
                     Nothing uses <filename>xf86bigfontproto</filename>.
                     </para></listitem>
                 <listitem><para><emphasis><filename>xf86rushproto</filename>:</emphasis>
-                    Removed because its dependency in 
+                    Removed because its dependency in
                     <filename>xserver</filename> was spurious and it was
                     removed in 2005.
                     </para></listitem>
                 <listitem><para><emphasis><filename>zypper / libzypp / sat-solver</filename>:</emphasis>
-                    Removed and been functionally replaced with Smart 
-                    (<filename>python-smartpm</filename>) when RPM packaging 
+                    Removed and been functionally replaced with Smart
+                    (<filename>python-smartpm</filename>) when RPM packaging
                     is used and package management is enabled on the target.
                     </para></listitem>
             </itemizedlist>

documentation/ref-manual/ref-classes.xml

@@ -115,7 +115,17 @@
     </para>
 
     <para>
-        To use this class, you need to define a number of variables.
+        To use this class, you need to define a number of variables:
+        <itemizedlist>
+            <listitem><para><link linkend='var-ALTERNATIVE'><filename>ALTERNATIVE</filename></link>
+                </para></listitem>
+            <listitem><para><link linkend='var-ALTERNATIVE_LINK_NAME'><filename>ALTERNATIVE_LINK_NAME</filename></link>
+                </para></listitem>
+            <listitem><para><link linkend='var-ALTERNATIVE_TARGET'><filename>ALTERNATIVE_TARGET</filename></link>
+                </para></listitem>
+            <listitem><para><link linkend='var-ALTERNATIVE_PRIORITY'><filename>ALTERNATIVE_PRIORITY</filename></link>
+                </para></listitem>
+        </itemizedlist>
         These variables list alternative commands needed by a package,
         provide pathnames for links, default links for targets, and
         so forth.
@@ -147,21 +157,30 @@
 </section>
 
 <section id='ref-classes-binconfig'>
-    <title>Binary Configuration Scripts - <filename>binconfig.bbclass</filename></title>
+    <title><filename>binconfig.bbclass</filename></title>
 
     <para>
-        Before <filename>pkg-config</filename> had become widespread, libraries shipped shell
-        scripts to give information about the libraries and include paths needed
-        to build software (usually named <filename>LIBNAME-config</filename>).
+        This class helps to correct paths in shell scripts.
+    </para>
+
+    <para>
+        Before <filename>pkg-config</filename> had become widespread, libraries
+        shipped shell scripts to give information about the libraries and
+        include paths needed to build software (usually named
+        <filename>LIBNAME-config</filename>).
         This class assists any recipe using such scripts.
     </para>
 
     <para>
-        During staging, BitBake installs such scripts into the
-        <filename>sysroots/</filename> directory.
-        BitBake also changes all paths to point into the <filename>sysroots/</filename>
-        directory so all builds that use the script will use the correct
-        directories for the cross compiling layout.
+        During staging, the OpenEmbedded build system installs such scripts
+        into the <filename>sysroots/</filename> directory.
+        Inheriting this class results in all paths in these scripts being
+        changed to point into the <filename>sysroots/</filename> directory so
+        that all builds that use the script use the correct directories
+        for the cross compiling layout.
+        See the
+        <link linkend='var-BINCONFIG_GLOB'><filename>BINCONFIG_GLOB</filename></link>
+        variable for more information.
     </para>
 </section>
 
@@ -179,7 +198,7 @@
     <title>Pkg-config - <filename>pkgconfig.bbclass</filename></title>
 
     <para>
-        <filename>pkg-config</filename> provides a standard way to get 
+        <filename>pkg-config</filename> provides a standard way to get
         header and library information.
         This class aims to smooth integration of
         <filename>pkg-config</filename> into libraries that use it.
@@ -198,7 +217,7 @@
 
     <para>
         Many software licenses require that source code and other materials be
-        released with the binaries. 
+        released with the binaries.
         To help with that task, the following classes are provided:
         <itemizedlist>
             <listitem><filename>archive-original-sources.bbclass</filename></listitem>
@@ -435,31 +454,51 @@
 </section>
 
 <section id='ref-classes-insane'>
-<title>Generated Output Quality Assurance Checks - <filename>insane.bbclass</filename></title>
+<title><filename>insane.bbclass</filename></title>
 
     <para>
-        This class adds a step to the package generation process that sanity checks the
-        packages generated by the OpenEmbedded build system.
+        This class adds a step to the package generation process so that
+        output quality assurance checks are generated by the OpenEmbedded
+        build system.
         A range of checks are performed that check the build's output
         for common problems that show up during runtime.
         Distribution policy usually dictates whether to include this class.
     </para>
 
     <para>
-        You can configure the sanity checks so that specific test failures either raise a warning or
-        an error message.
+        You can configure the sanity checks so that specific test failures
+        either raise a warning or an error message.
         Typically, failures for new tests generate a warning.
-        Subsequent failures for the same test would then generate an error message
-        once the metadata is in a known and good condition.
-        You use the <filename>WARN_QA</filename> variable to specify tests for which you
-        want to generate a warning message on failure.
-        You use the <filename>ERROR_QA</filename> variable to specify tests for which you
-        want to generate an error message on failure.
+        Subsequent failures for the same test would then generate an error
+        message once the metadata is in a known and good condition.
     </para>
 
     <para>
-        The following list shows the tests you can list with the <filename>WARN_QA</filename>
-        and <filename>ERROR_QA</filename> variables:
+        Use the
+        <link linkend='var-WARN_QA'><filename>WARN_QA</filename></link> and
+        <link linkend='var-ERROR_QA'><filename>ERROR_QA</filename></link>
+         variables to control the behavior of
+        these checks at the global level (i.e. in your custom distro
+        configuration).
+        However, to skip one or more checks in recipes, you should use
+        <link linkend='var-INSANE_SKIP'><filename>INSANE_SKIP</filename></link>.
+        For example, to skip the check for symbolic link
+        <filename>.so</filename> files in the main package of a recipe,
+        add the following to the recipe.
+        You need to realize that the package name override, in this example
+        <filename>${PN}</filename>, must be used:
+        <literallayout class='monospaced'>
+     INSANE_SKIP_${PN} += "dev-so"
+        </literallayout>
+        Please keep in mind that the QA checks exist in order to detect real
+        or potential problems in the packaged output.
+        So exercise caution when disabling these checks.
+    </para>
+
+    <para>
+        The following list shows the tests you can list with the
+        <filename>WARN_QA</filename> and <filename>ERROR_QA</filename>
+        variables:
         <itemizedlist>
             <listitem><para><emphasis><filename>ldflags:</filename></emphasis>
                 Ensures that the binaries were linked with the
@@ -515,47 +554,47 @@
                 since <filename>pkg-config</filename> itself adds the correct sysroot prefix
                 when the files are accessed.</para></listitem>
             <listitem><para><emphasis><filename>textrel:</filename></emphasis>
-                Checks for ELF binaries that contain relocations in their 
-                <filename>.text</filename> sections, which can result in a 
+                Checks for ELF binaries that contain relocations in their
+                <filename>.text</filename> sections, which can result in a
                 performance impact at runtime.</para></listitem>
             <listitem><para><emphasis><filename>pkgvarcheck:</filename></emphasis>
-                Checks through the variables 
-                <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>, 
-                <link linkend='var-RRECOMMENDS'><filename>RRECOMMENDS</filename></link>, 
+                Checks through the variables
+                <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>,
+                <link linkend='var-RRECOMMENDS'><filename>RRECOMMENDS</filename></link>,
                 <link linkend='var-RSUGGESTS'><filename>RSUGGESTS</filename></link>,
                 <link linkend='var-RCONFLICTS'><filename>RCONFLICTS</filename></link>,
                 <link linkend='var-RPROVIDES'><filename>RPROVIDES</filename></link>,
-                <link linkend='var-RREPLACES'><filename>RREPLACES</filename></link>, 
+                <link linkend='var-RREPLACES'><filename>RREPLACES</filename></link>,
                 <link linkend='var-FILES'><filename>FILES</filename></link>,
                 <link linkend='var-ALLOW_EMPTY'><filename>ALLOW_EMPTY</filename></link>,
-                <filename>pkg_preinst</filename>, 
-                <filename>pkg_postinst</filename>, 
+                <filename>pkg_preinst</filename>,
+                <filename>pkg_postinst</filename>,
                 <filename>pkg_prerm</filename>
-                and <filename>pkg_postrm</filename>, and reports if there are 
+                and <filename>pkg_postrm</filename>, and reports if there are
                 variable sets that are not package-specific.
                 Using these variables without a package suffix is bad practice,
                 and might unnecessarily complicate dependencies of other packages
                 within the same recipe or have other unintended consequences.
                 </para></listitem>
             <listitem><para><emphasis><filename>xorg-driver-abi:</filename></emphasis>
-                Checks that all packages containing Xorg drivers have ABI 
+                Checks that all packages containing Xorg drivers have ABI
                 dependencies.
-                The <filename>xserver-xorg</filename> recipe provides driver 
+                The <filename>xserver-xorg</filename> recipe provides driver
                 ABI names.
-                All drivers should depend on the ABI versions that they have 
-                been built against. 
-                Driver recipes that include 
+                All drivers should depend on the ABI versions that they have
+                been built against.
+                Driver recipes that include
                 <filename>xorg-driver-input.inc</filename>
-                or <filename>xorg-driver-video.inc</filename> will 
+                or <filename>xorg-driver-video.inc</filename> will
                 automatically get these versions.
-                Consequently, you should only need to explicitly add 
+                Consequently, you should only need to explicitly add
                 dependencies to binary driver recipes.
                 </para></listitem>
             <listitem><para><emphasis><filename>libexec:</filename></emphasis>
-                Checks if a package contains files in 
+                Checks if a package contains files in
                 <filename>/usr/libexec</filename>.
-                This check is not performed if the 
-                <filename>libexecdir</filename> variable has been set 
+                This check is not performed if the
+                <filename>libexecdir</filename> variable has been set
                 explicitly to <filename>/usr/libexec</filename>.
                 </para></listitem>
             <listitem><para><emphasis><filename>staticdev:</filename></emphasis>
@@ -569,58 +608,225 @@
                 <filename>libtool</filename> adds the correct sysroot prefix when using the
                 files automatically itself.</para></listitem>
             <listitem><para><emphasis><filename>desktop:</filename></emphasis>
-                Runs the <filename>desktop-file-validate</filename> program against any
-                <filename>.desktop</filename> files to validate their contents against
-                the specification for <filename>.desktop</filename> files.</para></listitem>
+                Runs the <filename>desktop-file-validate</filename> program
+                against any <filename>.desktop</filename> files to validate
+                their contents against the specification for
+                <filename>.desktop</filename> files.</para></listitem>
+            <listitem><para><emphasis><filename>already-stripped:</filename></emphasis>
+                Checks that produced binaries have not already been
+                stripped prior to the build system extracting debug symbols.
+                It is common for upstream software projects to default to
+                stripping debug symbols for output binaries.
+                In order for debugging to work on the target using
+                <filename>-dbg</filename> packages, this stripping must be
+                disabled.
+                </para></listitem>
+            <listitem><para><emphasis><filename>split-strip:</filename></emphasis>
+                Reports that splitting or stripping debug symbols from binaries
+                has failed.
+                </para></listitem>
+            <listitem><para><emphasis><filename>arch:</filename></emphasis>
+                Checks to ensure the architecture, bit size, and endianness
+                of all output binaries matches that of the target.
+                This test can detect when the wrong compiler or compiler options
+                have been used.
+                </para></listitem>
+            <listitem><para><emphasis><filename>installed-vs-shipped:</filename></emphasis>
+                Reports when files have been installed within
+                <filename>do_install</filename> but have not been included in
+                any package by way of the
+                <link linkend='var-FILES'><filename>FILES</filename></link>
+                variable.
+                Files that do not appear in any package cannot be present in
+                an image later on in the build process.
+                Ideally, all installed files should be packaged or not
+                installed at all.
+                These files can be deleted at the end of
+                <filename>do_install</filename> if the files are not
+                needed in any package.
+                </para></listitem>
+            <listitem><para><emphasis><filename>dep-cmp:</filename></emphasis>
+                Checks for invalid version comparison statements in runtime
+                dependency relationships between packages (i.e. in
+                <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>,
+                <link linkend='var-RRECOMMENDS'><filename>RRECOMMENDS</filename></link>,
+                <link linkend='var-RSUGGESTS'><filename>RSUGGESTS</filename></link>,
+                <link linkend='var-RPROVIDES'><filename>RPROVIDES</filename></link>,
+                <link linkend='var-RREPLACES'><filename>RREPLACES</filename></link>,
+                and
+                <link linkend='var-RCONFLICTS'><filename>RCONFLICTS</filename></link>
+                variable values).
+                Any invalid comparisons might trigger failures or undesirable
+                behavior when passed to the package manager.
+                </para></listitem>
+            <listitem><para><emphasis><filename>files-invalid:</filename></emphasis>
+                Checks for
+                <link linkend='var-FILES'><filename>FILES</filename></link>
+                variable values that contain "//", which is invalid.
+                </para></listitem>
+            <listitem><para><emphasis><filename>incompatible-license:</filename></emphasis>
+                Report when packages are excluded from being created due to
+                being marked with a license that is in
+                <link linkend='var-INCOMPATIBLE_LICENSE'><filename>INCOMPATIBLE_LICENSE</filename></link>.
+                </para></listitem>
+            <listitem><para><emphasis><filename>compile-host-path:</filename></emphasis>
+                Checks the <filename>do_compile</filename> log for indications
+                that paths to locations on the build host were used.
+                Using such paths might result in host contamination of the
+                build output.
+                </para></listitem>
+            <listitem><para><emphasis><filename>install-host-path:</filename></emphasis>
+                Checks the <filename>do_install</filename> log for indications
+                that paths to locations on the build host were used.
+                Using such paths might result in host contamination of the
+                build output.
+                </para></listitem>
+            <listitem><para><emphasis><filename>libdir:</filename></emphasis>
+                Checks for libraries being installed into incorrect
+                (possibly hardcoded) installation paths.
+                For example, this test will catch recipes that install
+                <filename>/lib/bar.so</filename> when
+                <filename>${base_libdir}</filename> is "lib32".
+                Another example is when recipes install
+                <filename>/usr/lib64/foo.so</filename> when
+                <filename>${libdir}</filename> is "/usr/lib".
+                </para></listitem>
+            <listitem><para><emphasis><filename>packages-list:</filename></emphasis>
+                Checks for the same package being listed multiple times through
+                the <link linkend='var-PACKAGES'><filename>PACKAGES</filename></link>
+                variable value.
+                Installing the package in this manner can cause errors during
+                packaging.
+                </para></listitem>
+            <listitem><para><emphasis><filename>perm-config:</filename></emphasis>
+                Reports lines in <filename>fs-perms.txt</filename> that have
+                an invalid format.
+                </para></listitem>
+            <listitem><para><emphasis><filename>perm-line:</filename></emphasis>
+                Reports lines in <filename>fs-perms.txt</filename> that have
+                an invalid format.
+                </para></listitem>
+            <listitem><para><emphasis><filename>perm-link:</filename></emphasis>
+                Reports lines in <filename>fs-perms.txt</filename> that
+                specify 'link' where the specified target already exists.
+                </para></listitem>
+            <listitem><para><emphasis><filename>pkgname:</filename></emphasis>
+                Checks that all packages in
+                <link linkend='var-PACKAGES'><filename>PACKAGES</filename></link>
+                have names that do not contain invalid characters (i.e.
+                characters other than 0-9, a-z, ., +, and -).
+                </para></listitem>
+            <listitem><para><emphasis><filename>pn-overrides:</filename></emphasis>
+                Checks that a recipe does not have a name
+                (<link linkend='var-PN'><filename>PN</filename></link>) value
+                that appears in
+                <link linkend='var-OVERRIDES'><filename>OVERRIDES</filename></link>.
+                If a recipe is named such that its <filename>PN</filename>
+                value matches something already in
+                <filename>OVERRIDES</filename> (e.g. <filename>PN</filename>
+                happens to be the same as
+                <link linkend='var-MACHINE'><filename>MACHINE</filename></link>
+                or
+                <link linkend='var-DISTRO'><filename>DISTRO</filename></link>),
+                it can have unexpected consequences.
+                For example, assignments such as
+                <filename>FILES_${PN} = "xyz"</filename> effectively turn into
+                <filename>FILES = "xyz"</filename>.
+                </para></listitem>
+            <listitem><para><emphasis><filename>unsafe-references-in-binaries:</filename></emphasis>
+                Reports when a binary installed in
+                <filename>${base_libdir}</filename>,
+                <filename>${base_bindir}</filename>, or
+                <filename>${base_sbindir}</filename>, depends on another
+                binary installed under <filename>${exec_prefix}</filename>.
+                This dependency is a concern if you want the system to remain
+                basically operable if <filename>/usr</filename> is mounted
+                separately and is not mounted.
+                <note>
+                    Defaults for binaries installed in
+                    <filename>${base_libdir}</filename>,
+                    <filename>${base_bindir}</filename>, and
+                    <filename>${base_sbindir}</filename> are
+                    <filename>/lib</filename>, <filename>/bin</filename>, and
+                    <filename>/sbin</filename>, respectively.
+                    The default for a binary installed
+                    under <filename>${exec_prefix}</filename> is
+                    <filename>/usr</filename>.
+                </note>
+                </para></listitem>
+            <listitem><para><emphasis><filename>unsafe-references-in-scripts:</filename></emphasis>
+                Reports when a script file installed in
+                <filename>${base_libdir}</filename>,
+                <filename>${base_bindir}</filename>, or
+                <filename>${base_sbindir}</filename>, depends on files
+                installed under <filename>${exec_prefix}</filename>.
+                This dependency is a concern if you want the system to remain
+                basically operable if <filename>/usr</filename> is mounted
+                separately and is not mounted.
+                <note>
+                    Defaults for binaries installed in
+                    <filename>${base_libdir}</filename>,
+                    <filename>${base_bindir}</filename>, and
+                    <filename>${base_sbindir}</filename> are
+                    <filename>/lib</filename>, <filename>/bin</filename>, and
+                    <filename>/sbin</filename>, respectively.
+                    The default for a binary installed
+                    under <filename>${exec_prefix}</filename> is
+                    <filename>/usr</filename>.
+                </note>
+                </para></listitem>
+            <listitem><para><emphasis><filename>var-undefined:</filename></emphasis>
+                Reports when variables fundamental to packaging (i.e.
+                <link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>,
+                <link linkend='var-DEPLOY_DIR'><filename>DEPLOY_DIR</filename></link>,
+                <link linkend='var-D'><filename>D</filename></link>,
+                <link linkend='var-PN'><filename>PN</filename></link>, and
+                <link linkend='var-PKGD'><filename>PKGD</filename></link>) are
+                undefined during <filename>do_package</filename>.
+                </para></listitem>
+            <listitem><para><emphasis><filename>pkgv-undefined:</filename></emphasis>
+                Checks to see if the <filename>PKGV</filename> variable
+                is undefined during <filename>do_package</filename>.
+                </para></listitem>
+            <listitem><para><emphasis><filename>buildpaths:</filename></emphasis>
+                Checks for paths to locations on the build host inside the
+                output files.
+                Currently, this test triggers too many false positives and
+                thus is not normally enabled.
+                </para></listitem>
+            <listitem><para><emphasis><filename>perms:</filename></emphasis>
+                Currently, this check is unused but reserved.
+                </para></listitem>
         </itemizedlist>
     </para>
-    <note>
-        You can use the <filename>WARN_QA</filename> and 
-        <filename>ERROR_QA</filename> variables to control the behavior of 
-        these checks at the global level (i.e. in your custom distro 
-        configuration).
-        However, to skip one or more checks in recipes, you should use 
-        <link linkend='var-INSANE_SKIP'><filename>INSANE_SKIP</filename></link>. 
-        For example, to skip the check for symbolic link 
-        <filename>.so</filename> files in the main package of a recipe, 
-        add the following to the recipe.
-        You need to realize that the package name override, in this example
-        <filename>${PN}</filename>, must be used:
-        <literallayout class='monospaced'>
-     INSANE_SKIP_${PN} += "dev-so"
-        </literallayout>
-        Please keep in mind that the QA checks exist in order to detect real 
-        or potential problems in the packaged output.
-        So exercise caution when disabling these checks.
-    </note>
 </section>
 
 <section id='ref-classes-rm-work'>
     <title>Removing Work Files During the Build - <filename>rm_work.bbclass</filename></title>
 
     <para>
-        The OpenEmbedded build system can use a substantial amount of disk 
+        The OpenEmbedded build system can use a substantial amount of disk
         space during the build process.
-        A portion of this space is the work files under the 
-        <filename>${TMPDIR}/work</filename> directory for each recipe. 
-        Once the build system generates the packages for a recipe, the work 
+        A portion of this space is the work files under the
+        <filename>${TMPDIR}/work</filename> directory for each recipe.
+        Once the build system generates the packages for a recipe, the work
         files for that recipe are no longer needed.
         However, by default, the build system preserves these files
         for inspection and possible debugging purposes.
-        If you would rather have these files deleted to save disk space 
+        If you would rather have these files deleted to save disk space
         as the build progresses, you can enable <filename>rm_work</filename>
         by adding the following to your <filename>local.conf</filename> file,
-        which is found in the 
+        which is found in the
         <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
         <literallayout class='monospaced'>
     INHERIT += "rm_work"
         </literallayout>
-        If you are modifying and building source code out of the work directory 
-        for a recipe, enabling <filename>rm_work</filename> will potentially 
-        result in your changes to the source being lost. 
+        If you are modifying and building source code out of the work directory
+        for a recipe, enabling <filename>rm_work</filename> will potentially
+        result in your changes to the source being lost.
         To exclude some recipes from having their work directories deleted by
-        <filename>rm_work</filename>, you can add the names of the recipe or 
-        recipes you are working on to the <filename>RM_WORK_EXCLUDE</filename> 
+        <filename>rm_work</filename>, you can add the names of the recipe or
+        recipes you are working on to the <filename>RM_WORK_EXCLUDE</filename>
         variable, which can also be set in your <filename>local.conf</filename>
         file.
         Here is an example:
@@ -677,28 +883,37 @@
 </section>
 
 <section id='ref-classes-externalsrc'>
-    <title>Using External Source - <filename>externalsrc.bbclass</filename></title>
+    <title><filename>externalsrc.bbclass</filename></title>
 
     <para>
-        You can use this class to build software from source code that is external to the
-        OpenEmbedded build system.
-        In other words, your source code resides in an external tree outside of the Yocto Project.
-        Building software from an external source tree means that the normal fetch, unpack, and
-        patch process is not used.
+        You can use this class to build software from source code that is
+        external to the OpenEmbedded build system.
+        Building software from an external source tree means that the build
+        system's normal fetch, unpack, and patch process is not used.
     </para>
 
     <para>
-        To use the class, you need to define the
-        <link linkend='var-S'><filename>S</filename></link> variable to point to the directory that contains the source files.
-        You also need to have your recipe inherit the <filename>externalsrc.bbclass</filename> class.
+        By default, the OpenEmbedded build system uses the
+        <link linkend='var-S'><filename>S</filename></link> and
+        <link linkend='var-B'><filename>B</filename></link> variables to
+        locate unpacked recipe source code and to build it, respectively.
+        When your recipe inherits <filename>externalsrc.bbclass</filename>,
+        you use the
+        <link linkend='var-EXTERNALSRC'><filename>EXTERNALSRC</filename></link>
+        and
+        <link linkend='var-EXTERNALSRC_BUILD'><filename>EXTERNALSRC_BUILD</filename></link>
+        variables to ultimately define <filename>S</filename> and
+        <filename>B</filename>.
     </para>
 
     <para>
-        This class expects the source code to support recipe builds that use the
-        <link linkend='var-B'><filename>B</filename></link> variable to point to the directory in
-        which the 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>):
+        By default, this class expects the source code to support recipe builds
+        that use the <link linkend='var-B'><filename>B</filename></link>
+        variable to point to the directory in which the OpenEmbedded build
+        system places the generated objects built from the recipes.
+        By default, the <filename>B</filename> directory is set to the
+        following, which is separate from the source directory
+        (<filename>S</filename>):
         <literallayout class='monospaced'>
      ${WORKDIR}/${BPN}/{PV}/
         </literallayout>
@@ -706,36 +921,17 @@
         <link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>,
         <link linkend='var-BPN'><filename>BPN</filename></link>,
         <link linkend='var-PV'><filename>PV</filename></link>,
-        <link linkend='var-S'><filename>S</filename></link>, and
-        <link linkend='var-B'><filename>B</filename></link> for more information.
     </para>
 
     <para>
-        You can build object files in the external tree by setting the
-        <filename>B</filename> variable equal to <filename>"${S}"</filename>.
-        However, this practice does not work well if you use the source for more than one variant
-        (i.e., "natives" such as <filename>quilt-native</filename>,
-        or "crosses" such as <filename>gcc-cross</filename>).
-        So, be sure there are no "native", "cross", or "multilib" variants of the recipe.
-    </para>
-
-    <para>
-        If you do want to build different variants of a recipe, you can use the
-        <link linkend='var-BBCLASSEXTEND'><filename>BBCLASSEXTEND</filename></link> variable.
-        When you do, the <link linkend='var-B'><filename>B</filename></link> variable must support the
-        recipe's ability to build variants in different working directories.
-        Most Autotools-based recipes support separating these directories.
-        The OpenEmbedded build system defaults to using separate directories for <filename>gcc</filename>
-        and some kernel recipes.
-        Alternatively, you can make sure that separate recipes exist that each
-        use the <filename>BBCLASSEXTEND</filename> variable to build each variant.
-        The separate recipes can inherit a single target recipe.
-    </para>
-
-    <para>
-        For information on how to use this class, see the
-        "<ulink url='&YOCTO_DOCS_DEV_URL;#building-software-from-an-external-source'>Building
-        Software from an External Source</ulink>" section in the Yocto Project Development Manual.
+        For more information on
+        <filename>externalsrc.bbclass</filename>, see the comments in
+        <filename>meta/classes/externalsrc.bbclass</filename> in the
+        <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+        For information on how to use <filename>externalsrc.bbclass</filename>,
+        see the
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#building-software-from-an-external-source'>Building Software from an External Source</ulink>"
+        section in the Yocto Project Development Manual.
     </para>
 </section>
 

documentation/ref-manual/ref-features.xml

@@ -60,33 +60,43 @@
         <para>
             This list only represents features as shipped with the Yocto Project metadata:
             <itemizedlist>
-                <listitem><para><emphasis>alsa:</emphasis> Include ALSA support (OSS compatibility
-                    kernel modules installed if available).</para></listitem>
-                <listitem><para><emphasis>bluetooth:</emphasis> Include bluetooth support (integrated BT only)
+                <listitem><para><emphasis>alsa:</emphasis> Include ALSA support
+                    (OSS compatibility kernel modules installed if available).
                     </para></listitem>
-                <listitem><para><emphasis>cramfs:</emphasis> Include CramFS support
+                <listitem><para><emphasis>bluetooth:</emphasis> Include
+                    bluetooth support (integrated BT only).</para></listitem>
+                <listitem><para><emphasis>cramfs:</emphasis> Include CramFS
+                    support.</para></listitem>
+                <listitem><para><emphasis>ext2:</emphasis> Include tools for
+                    supporting for devices with internal HDD/Microdrive for
+                    storing files (instead of Flash only devices).
                     </para></listitem>
-                <listitem><para><emphasis>ext2:</emphasis> Include tools for supporting for devices with internal
-                    HDD/Microdrive for storing files (instead of Flash only devices)
+                <listitem><para><emphasis>ipsec:</emphasis> Include IPSec
+                    support.</para></listitem>
+                <listitem><para><emphasis>ipv6:</emphasis> Include IPv6 support.
                     </para></listitem>
-                <listitem><para><emphasis>ipsec:</emphasis> Include IPSec support
+                <listitem><para><emphasis>irda:</emphasis> Include Irda support.
                     </para></listitem>
-                <listitem><para><emphasis>ipv6:</emphasis> Include IPv6 support
+                <listitem><para><emphasis>keyboard:</emphasis> Include keyboard
+                    support (e.g. keymaps will be loaded during boot).
                     </para></listitem>
-                <listitem><para><emphasis>irda:</emphasis> Include Irda support
+                <listitem><para><emphasis>nfs:</emphasis> Include NFS client
+                    support (for mounting NFS exports on device).
                     </para></listitem>
-                <listitem><para><emphasis>keyboard:</emphasis> Include keyboard support (e.g. keymaps will be
-                    loaded during boot).
-                    </para></listitem>
-                <listitem><para><emphasis>nfs:</emphasis> Include NFS client support (for mounting NFS exports on
-                    device)</para></listitem>
-                <listitem><para><emphasis>pci:</emphasis> Include PCI bus support
-                    </para></listitem>
-                <listitem><para><emphasis>pcmcia:</emphasis> Include PCMCIA/CompactFlash support
-                    </para></listitem>
-                <listitem><para><emphasis>ppp:</emphasis> Include PPP dialup support</para></listitem>
-                <listitem><para><emphasis>smbfs:</emphasis> Include SMB networks client support (for mounting
-                    Samba/Microsoft Windows shares on device)</para></listitem>
+                <listitem><para><emphasis>opengl:</emphasis>
+                    Include the Open Graphics Library, which is a
+                    cross-language, multi-platform application programming
+                    interface used for rendering two and three-dimensional
+                    graphics.</para></listitem>
+                <listitem><para><emphasis>pci:</emphasis> Include PCI bus
+                    support.</para></listitem>
+                <listitem><para><emphasis>pcmcia:</emphasis> Include
+                    PCMCIA/CompactFlash support.</para></listitem>
+                <listitem><para><emphasis>ppp:</emphasis> Include PPP dialup
+                    support.</para></listitem>
+                <listitem><para><emphasis>smbfs:</emphasis> Include SMB networks
+                    client support (for mounting Samba/Microsoft Windows shares
+                    on device).</para></listitem>
                 <listitem><para><emphasis>systemd:</emphasis> Include support
                     for this <filename>init</filename> manager, which is a full
                     replacement of for <filename>init</filename> with parallel
@@ -94,17 +104,17 @@
                     features.
                     This <filename>init</filename> manager is used by many
                     distributions.</para></listitem>
-                <listitem><para><emphasis>usbgadget:</emphasis> Include USB Gadget Device support (for USB
-                    networking/serial/storage)
-                    </para></listitem>
-                <listitem><para><emphasis>usbhost:</emphasis> Include USB Host support (allows to connect external
-                    keyboard, mouse, storage, network etc)
+                <listitem><para><emphasis>usbgadget:</emphasis> Include USB
+                    Gadget Device support (for USB networking/serial/storage).
                     </para></listitem>
+                <listitem><para><emphasis>usbhost:</emphasis> Include USB Host
+                    support (allows to connect external keyboard, mouse,
+                    storage, network etc).</para></listitem>
                 <listitem><para><emphasis>wayland:</emphasis> Include the
                     Wayland display server protocol and the library that
                     supports it.</para></listitem>
-                <listitem><para><emphasis>wifi:</emphasis> Include WiFi support (integrated only)
-                    </para></listitem>
+                <listitem><para><emphasis>wifi:</emphasis> Include WiFi support
+                    (integrated only).</para></listitem>
             </itemizedlist>
         </para>
     </section>

documentation/ref-manual/ref-images.xml

@@ -6,7 +6,8 @@
     <title>Images</title>
 
     <para>
-        The OpenEmbedded build process supports several types of images to satisfy different needs.
+        The OpenEmbedded build system provides several example
+        images to satisfy different needs.
         When you issue the <filename>bitbake</filename> command you provide a “top-level” recipe
         that essentially begins the build for the type of image you want.
     </para>