perf: Ensure we use CFLAGS and LDFLAGS settings from kernel build system

The kernel build system does the right thing here and we should stop
overriding it. This code has been added based on a change from
'meta-metro' layer, revision 9d698004137c1a888d40d6a4808d94afa22387e7,
without any information about what problem it fixes so I am reverting
it.

Using the CFLAGS and LDFLAGS makes it impossible for kernel build
system to append to it, thus making the build fail in various ways as:

|     CC /.../perf/1.0-r8/perf-1.0/perf.o
| In file included from builtin.h:4:0,
|                  from perf.c:9:
| util/util.h:74:24: fatal error: lk/debugfs.h: No such file or directory
|  #include <lk/debugfs.h>
|                         ^
| compilation terminated.

The unset is done in do_compile and do_install otherwise it /rebuild/
perf as it detects the compiler options has change.

(From OE-Core rev: 2e90f8846db0f3ed99a175befff9ec67fe12bc4e)

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
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-worker

@@ -147,6 +147,9 @@ def fork_off_task(cfg, data, workerdata, fn, task, taskname, appends, quieterror
                 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:

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/build.py

@@ -69,9 +69,10 @@ class FuncFailed(Exception):
 class TaskBase(event.Event):
     """Base class for task events"""
 
-    def __init__(self, t, d ):
+    def __init__(self, t, logfile, d):
         self._task = t
         self._package = d.getVar("PF", True)
+        self.logfile = logfile
         event.Event.__init__(self)
         self._message = "recipe %s: task %s: %s" % (d.getVar("PF", True), t, self.getDisplayName())
 
@@ -96,16 +97,11 @@ class TaskFailed(TaskBase):
     """Task execution failed"""
 
     def __init__(self, task, logfile, metadata, errprinted = False):
-        self.logfile = logfile
         self.errprinted = errprinted
-        super(TaskFailed, self).__init__(task, metadata)
+        super(TaskFailed, self).__init__(task, logfile, metadata)
 
 class TaskFailedSilent(TaskBase):
     """Task execution failed (silently)"""
-    def __init__(self, task, logfile, metadata):
-        self.logfile = logfile
-        super(TaskFailedSilent, self).__init__(task, metadata)
-
     def getDisplayName(self):
         # Don't need to tell the user it was silent
         return "Failed"
@@ -113,7 +109,7 @@ class TaskFailedSilent(TaskBase):
 class TaskInvalid(TaskBase):
 
     def __init__(self, task, metadata):
-        super(TaskInvalid, self).__init__(task, metadata)
+        super(TaskInvalid, self).__init__(task, None, metadata)
         self._message = "No such task '%s'" % task
 
 
@@ -190,6 +186,20 @@ def exec_func(func, d, dirs = None):
     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,7 +260,24 @@ 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')
+        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:
@@ -258,6 +285,12 @@ def exec_func_shell(func, d, runfile, cwd=None):
         if cwd:
             script.write("cd %s\n" % cwd)
         script.write("%s\n" % func)
+        script.write('''
+# cleanup
+ret=$?
+trap '' 0
+exit $?
+''')
 
     os.chmod(runfile, 0775)
 
@@ -379,7 +412,7 @@ def _exec_task(fn, task, d, quieterr):
     localdata.setVar('BB_LOGFILE', logfn)
     localdata.setVar('BB_RUNTASK', task)
 
-    event.fire(TaskStarted(task, localdata), localdata)
+    event.fire(TaskStarted(task, logfn, localdata), localdata)
     try:
         for func in (prefuncs or '').split():
             exec_func(func, localdata)
@@ -416,7 +449,7 @@ def _exec_task(fn, task, d, quieterr):
             logger.debug(2, "Zero size logfn %s, removing", logfn)
             bb.utils.remove(logfn)
             bb.utils.remove(loglink)
-    event.fire(TaskSucceeded(task, localdata), localdata)
+    event.fire(TaskSucceeded(task, logfn, localdata), localdata)
 
     if not localdata.getVarFlag(task, 'nostamp') and not localdata.getVarFlag(task, 'selfstamp'):
         make_stamp(task, localdata)
@@ -430,7 +463,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:

bitbake/lib/bb/command.py

@@ -90,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:
@@ -118,14 +117,14 @@ class Command:
             return False
 
     def finishAsyncCommand(self, msg=None, code=None):
-        if msg:
+        if msg or msg == "":
             bb.event.fire(CommandFailed(msg), self.cooker.event_data)
         elif code:
             bb.event.fire(CommandExit(code), self.cooker.event_data)
         else:
             bb.event.fire(CommandCompleted(), self.cooker.event_data)
         self.currentAsyncCommand = None
-
+        self.cooker.finishcommand()
 
 class CommandsSync:
     """
@@ -138,13 +137,13 @@ class CommandsSync:
         """
         Trigger cooker 'shutdown' mode
         """
-        command.cooker.shutdown()
+        command.cooker.shutdown(False)
 
-    def stateStop(self, command, params):
+    def stateForceShutdown(self, command, params):
         """
         Stop the cooker
         """
-        command.cooker.stop()
+        command.cooker.shutdown(True)
 
     def getVariable(self, command, params):
         """
@@ -153,7 +152,7 @@ class CommandsSync:
         varname = params[0]
         expand = True
         if len(params) > 1:
-            expand = params[1]
+            expand = (params[1] == "True")
 
         return command.cooker.data.getVar(varname, expand)
     getVariable.readonly = True
@@ -214,7 +213,14 @@ 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):
         """
@@ -223,7 +229,8 @@ class CommandsSync:
         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):
         """
@@ -232,6 +239,13 @@ class CommandsSync:
         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:
     """
     A class of asynchronous commands

bitbake/lib/bb/cooker.py

@@ -61,7 +61,7 @@ class CollectionError(bb.BBHandledException):
     """
 
 class state:
-    initial, parsing, running, shutdown, stop = range(5)
+    initial, parsing, running, shutdown, forceshutdown, stopped = range(6)
 
 
 class SkippedPackage:
@@ -93,22 +93,6 @@ class BBCooker:
 
         self.configuration = configuration
 
-        self.caches_array = []
-
-        caches_name_array = ['bb.cache:CoreRecipeInfo'] + configuration.extra_caches
-
-        # At least CoreRecipeInfo will be loaded, so caches_array will never be empty!
-        # This is the entry point, no further check needed!
-        for var in caches_name_array:
-            try:
-                module_name, cache_name = var.split(':')
-                module = __import__(module_name, fromlist=(cache_name,))
-                self.caches_array.append(getattr(module, cache_name)) 
-            except ImportError as exc:
-                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.data = None
         self.loadConfigurationData()
 
         # Take a lock so only one copy of bitbake can run against a given build
@@ -118,13 +102,6 @@ class BBCooker:
         if not self.lock:
             bb.fatal("Only one copy of bitbake should be run against a build directory")
 
-        #
-        # Special updated configuration we use for firing events
-        #
-        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()
         if os.isatty(fd):
@@ -141,11 +118,24 @@ class BBCooker:
         self.parser = None
 
     def initConfigurationData(self):
-        worker = False
-        if not self.configuration.server_register_idlecallback:
-            worker = True
 
-        self.databuilder = bb.cookerdata.CookerDataBuilder(self.configuration, worker)
+        self.state = state.initial
+
+        self.caches_array = []
+        caches_name_array = ['bb.cache:CoreRecipeInfo'] + self.configuration.extra_caches
+
+        # At least CoreRecipeInfo will be loaded, so caches_array will never be empty!
+        # This is the entry point, no further check needed!
+        for var in caches_name_array:
+            try:
+                module_name, cache_name = var.split(':')
+                module = __import__(module_name, fromlist=(cache_name,))
+                self.caches_array.append(getattr(module, cache_name)) 
+            except ImportError as exc:
+                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.databuilder = bb.cookerdata.CookerDataBuilder(self.configuration, False)
         self.data = self.databuilder.data
 
     def enableDataTracking(self):
@@ -162,6 +152,42 @@ class BBCooker:
         self.data = self.databuilder.data
         self.data_hash = self.databuilder.data_hash
 
+        #
+        # Special updated configuration we use for firing events
+        #
+        self.event_data = bb.data.createCopy(self.data)
+        bb.data.update_data(self.event_data)
+        bb.parse.init_parser(self.event_data)
+
+    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
@@ -223,7 +249,7 @@ class BBCooker:
             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()
@@ -319,13 +345,7 @@ class BBCooker:
             if pkgs_to_build[0] in set(ignore.split()):
                 bb.fatal("%s is in ASSUME_PROVIDED" % pkgs_to_build[0])
 
-            localdata = data.createCopy(self.data)
-            bb.data.update_data(localdata)
-            bb.data.expandKeys(localdata)
-
-            taskdata = bb.taskdata.TaskData(self.configuration.abort)
-            taskdata.add_provider(localdata, self.recipecache, pkgs_to_build[0])
-            taskdata.add_unresolved(localdata, self.recipecache)
+            taskdata, runlist, pkgs_to_build = self.buildTaskData(pkgs_to_build, None, self.configuration.abort)
 
             targetid = taskdata.getbuild_id(pkgs_to_build[0])
             fnid = taskdata.build_targets[targetid][0]
@@ -357,34 +377,44 @@ class BBCooker:
             if data.getVarFlag( e, 'python', envdata ):
                 logger.plain("\npython %s () {\n%s}\n", e, data.getVar(e, envdata, 1))
 
-    def prepareTreeData(self, pkgs_to_build, task):
+
+    def buildTaskData(self, pkgs_to_build, task, abort):
         """
         Prepare a runqueue and taskdata object for iteration over pkgs_to_build
         """
         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):
+        # A task of None means use the default task
+        if task is None:
             task = self.configuration.cmd
 
-        pkgs_to_build = self.checkPackages(pkgs_to_build)
+        fulltargetlist = self.checkPackages(pkgs_to_build)
 
         localdata = data.createCopy(self.data)
         bb.data.update_data(localdata)
         bb.data.expandKeys(localdata)
+        taskdata = bb.taskdata.TaskData(abort, skiplist=self.skiplist)
+
+        current = 0
+        runlist = []
+        for k in fulltargetlist:
+            taskdata.add_provider(localdata, self.recipecache, k)
+            current += 1
+            runlist.append([k, "do_%s" % task])
+            bb.event.fire(bb.event.TreeDataPreparationProgress(current, len(fulltargetlist)), self.data)
+        taskdata.add_unresolved(localdata, self.recipecache)
+        bb.event.fire(bb.event.TreeDataPreparationCompleted(len(fulltargetlist)), self.data)
+        return taskdata, runlist, fulltargetlist
+
+    def prepareTreeData(self, pkgs_to_build, task):
+        """
+        Prepare a runqueue and taskdata object for iteration over pkgs_to_build
+        """
+
         # We set abort to False here to prevent unbuildable targets raising
         # an exception when we're just generating data
-        taskdata = bb.taskdata.TaskData(False, skiplist=self.skiplist)
+        taskdata, runlist, pkgs_to_build = self.buildTaskData(pkgs_to_build, task, False)
 
-        runlist = []
-        current = 0
-        for k in pkgs_to_build:
-            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.data)
-        taskdata.add_unresolved(localdata, self.recipecache)
-        bb.event.fire(bb.event.TreeDataPreparationCompleted(len(pkgs_to_build)), self.data)
         return runlist, taskdata
     
     ######## WARNING : this function requires cache_extra to be enabled ########
@@ -668,7 +698,7 @@ class BBCooker:
         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
 
@@ -1018,7 +1048,7 @@ class BBCooker:
 
         def buildFileIdle(server, rq, abort):
 
-            if abort or self.state == state.stop:
+            if abort or self.state == state.forceshutdown:
                 rq.finish_runqueue(True)
             elif self.state == state.shutdown:
                 rq.finish_runqueue(False)
@@ -1047,15 +1077,8 @@ class BBCooker:
         Attempt to build the targets specified
         """
 
-        # If we are told to do the NULL task then query the default task
-        if (task == None):
-            task = self.configuration.cmd
-
-        universe = ('universe' in targets)
-        targets = self.checkPackages(targets)
-
         def buildTargetsIdle(server, rq, abort):
-            if abort or self.state == state.stop:
+            if abort or self.state == state.forceshutdown:
                 rq.finish_runqueue(True)
             elif self.state == state.shutdown:
                 rq.finish_runqueue(False)
@@ -1079,53 +1102,64 @@ class BBCooker:
 
         self.buildSetVars()
 
+        taskdata, runlist, fulltargetlist = self.buildTaskData(targets, task, self.configuration.abort)
+
         buildname = self.data.getVar("BUILDNAME")
-        bb.event.fire(bb.event.BuildStarted(buildname, targets), self.data)
-
-        localdata = data.createCopy(self.data)
-        bb.data.update_data(localdata)
-        bb.data.expandKeys(localdata)
-
-        taskdata = bb.taskdata.TaskData(self.configuration.abort, skiplist=self.skiplist)
-
-        runlist = []
-        for k in targets:
-            taskdata.add_provider(localdata, self.recipecache, k)
-            runlist.append([k, "do_%s" % task])
-        taskdata.add_unresolved(localdata, self.recipecache)
+        bb.event.fire(bb.event.BuildStarted(buildname, fulltargetlist), self.data)
 
         rq = bb.runqueue.RunQueue(self, self.data, self.recipecache, taskdata, runlist)
-        if universe:
+        if 'universe' in targets:
             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
 
-        if self.state in (state.shutdown, state.stop):
+        if self.state in (state.shutdown, state.forceshutdown):
             self.parser.shutdown(clean=False, force = True)
-            sys.exit(1)
+            raise bb.BBHandledException()
 
         if self.state != state.parsing:
             self.parseConfiguration ()
@@ -1147,7 +1181,7 @@ class BBCooker:
         if not self.parser.parse_next():
             collectlog.debug(1, "parsing complete")
             if self.parser.error:
-                sys.exit(1)
+                raise bb.BBHandledException()
             self.show_appends_with_no_recipes()
             self.handlePrefProviders()
             self.recipecache.bbfile_priority = self.collection.collection_priorities(self.recipecache.pkg_fn)
@@ -1193,18 +1227,19 @@ class BBCooker:
         prserv.serv.auto_shutdown(self.data)
         bb.event.fire(CookerExit(), self.event_data)
 
-    def shutdown(self):
-        self.state = state.shutdown
+    def shutdown(self, force = False):
+        if force:
+            self.state = state.forceshutdown
+        else:
+            self.state = state.shutdown
 
-    def stop(self):
-        self.state = state.stop
+    def finishcommand(self):
+        self.state = state.initial
 
     def initialize(self):
-        self.state = state.initial
         self.initConfigurationData()
 
     def reset(self):
-        self.state = state.initial
         self.loadConfigurationData()
 
 def server_main(cooker, func, *args):
@@ -1432,7 +1467,7 @@ class Feeder(multiprocessing.Process):
                 continue
 
 class Parser(multiprocessing.Process):
-    def __init__(self, jobs, results, quit, init):
+    def __init__(self, jobs, results, quit, init, profile):
         self.jobs = jobs
         self.results = results
         self.quit = quit
@@ -1440,8 +1475,28 @@ class Parser(multiprocessing.Process):
         multiprocessing.Process.__init__(self)
         self.context = bb.utils.get_context().copy()
         self.handlers = bb.event.get_class_handlers().copy()
+        self.profile = profile
 
     def run(self):
+
+        if not self.profile:
+            self.realrun()
+            return
+
+        try:
+            import cProfile as profile
+        except:
+            import profile
+        prof = profile.Profile()
+        try:
+            profile.Profile.runcall(prof, self.realrun)
+        finally:
+            logfile = "profile-parse-%s.log" % multiprocessing.current_process().name
+            prof.dump_stats(logfile)
+            bb.utils.process_profilelog(logfile)
+            print("Raw profiling information saved to %s and processed statistics to %s.processed" % (logfile, logfile))
+
+    def realrun(self):
         if self.init:
             self.init()
 
@@ -1542,7 +1597,7 @@ class CookerParser(object):
             self.feeder = Feeder(self.willparse, self.jobs, self.feeder_quit)
             self.feeder.start()
             for i in range(0, self.num_processes):
-                parser = Parser(self.jobs, self.result_queue, self.parser_quit, init)
+                parser = Parser(self.jobs, self.result_queue, self.parser_quit, init, self.cooker.configuration.profile)
                 parser.start()
                 self.processes.append(parser)
 

bitbake/lib/bb/cookerdata.py

@@ -177,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):
@@ -225,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
@@ -236,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()

bitbake/lib/bb/data.py

@@ -59,7 +59,7 @@ def init():
 def init_db(parent = None):
     """Return a new object representing the Bitbake data,
     optionally based on an existing object"""
-    if parent:
+    if parent is not None:
         return parent.createCopy()
     else:
         return _dict_type()
@@ -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)
@@ -144,7 +148,7 @@ def expandKeys(alterdata, readdata = None):
         readdata = alterdata
 
     todolist = {}
-    for key in keys(alterdata):
+    for key in alterdata:
         if not '${' in key:
             continue
 
@@ -281,20 +285,24 @@ def update_data(d):
     """Performs final steps upon the datastore, including application of overrides"""
     d.finalize(parent = True)
 
-def build_dependencies(key, keys, shelldeps, vardepvals, d):
+def build_dependencies(key, keys, shelldeps, varflagsexcl, d):
     deps = set()
-    vardeps = d.getVarFlag(key, "vardeps", True)
     try:
         if key[-1] == ']':
             vf = key[:-1].split('[')
             value = d.getVarFlag(vf[0], vf[1], False)
-        else:
-            value = d.getVar(key, False)
+            parser = d.expandWithRefs(value, key)
+            deps |= parser.references
+            deps = deps | (keys & parser.execs)
+            return deps, value
+        varflags = d.getVarFlags(key, ["vardeps", "vardepvalue", "vardepsexclude"]) or {}
+        vardeps = varflags.get("vardeps")
+        value = d.getVar(key, False)
 
-        if key in vardepvals:
-           value =  d.getVarFlag(key, "vardepvalue", True)
-        elif d.getVarFlag(key, "func"):
-            if d.getVarFlag(key, "python"):
+        if "vardepvalue" in varflags:
+           value = varflags.get("vardepvalue")
+        elif varflags.get("func"):
+            if varflags.get("python"):
                 parsedvar = d.expandWithRefs(value, key)
                 parser = bb.codeparser.PythonParser(key, logger)
                 if parsedvar.value and "\t" in parsedvar.value:
@@ -316,19 +324,16 @@ def build_dependencies(key, keys, shelldeps, vardepvals, d):
             deps = deps | (keys & parser.execs)
 
         # Add varflags, assuming an exclusion list is set
-        varflagsexcl = d.getVar('BB_SIGNATURE_EXCLUDE_FLAGS', True)
         if varflagsexcl:
             varfdeps = []
-            varflags = d.getVarFlags(key)
-            if varflags:
-                for f in varflags:
-                    if f not in varflagsexcl:
-                        varfdeps.append('%s[%s]' % (key, f))
+            for f in varflags:
+                if f not in varflagsexcl:
+                    varfdeps.append('%s[%s]' % (key, f))
             if varfdeps:
                 deps |= set(varfdeps)
 
         deps |= set((vardeps or "").split())
-        deps -= set((d.getVarFlag(key, "vardepsexclude", True) or "").split())
+        deps -= set(varflags.get("vardepsexclude", "").split())
     except Exception as e:
         raise bb.data_smart.ExpansionError(key, None, e)
     return deps, value
@@ -337,16 +342,16 @@ def build_dependencies(key, keys, shelldeps, vardepvals, d):
 
 def generate_dependencies(d):
 
-    keys = set(key for key in d.keys() if not key.startswith("__"))
-    shelldeps = set(key for key in keys if d.getVarFlag(key, "export") and not d.getVarFlag(key, "unexport"))
-    vardepvals = set(key for key in keys if d.getVarFlag(key, "vardepvalue"))
+    keys = set(key for key in d if not key.startswith("__"))
+    shelldeps = set(key for key in d.getVar("__exportlist", False) if d.getVarFlag(key, "export") and not d.getVarFlag(key, "unexport"))
+    varflagsexcl = d.getVar('BB_SIGNATURE_EXCLUDE_FLAGS', True)
 
     deps = {}
     values = {}
 
     tasklist = d.getVar('__BBTASKS') or []
     for task in tasklist:
-        deps[task], values[task] = build_dependencies(task, keys, shelldeps, vardepvals, d)
+        deps[task], values[task] = build_dependencies(task, keys, shelldeps, varflagsexcl, d)
         newdeps = deps[task]
         seen = set()
         while newdeps:
@@ -355,7 +360,7 @@ def generate_dependencies(d):
             newdeps = set()
             for dep in nextdeps:
                 if dep not in deps:
-                    deps[dep], values[dep] = build_dependencies(dep, keys, shelldeps, vardepvals, d)
+                    deps[dep], values[dep] = build_dependencies(dep, keys, shelldeps, varflagsexcl, d)
                 newdeps |=  deps[dep]
             newdeps -= seen
         #print "For %s: %s" % (task, str(deps[task]))

bitbake/lib/bb/data_smart.py

@@ -38,9 +38,9 @@ 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>.*))?$')
-__expand_var_regexp__ = re.compile(r"\${[^{}]+}")
+__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"\${@.+?}")
 
 def infer_caller_details(loginfo, parent = False, varval = True):
@@ -94,9 +94,14 @@ class VariableParse:
             if self.varname and key:
                 if self.varname == key:
                     raise Exception("variable %s references itself!" % self.varname)
+            if key in self.d.expand_cache:
+                varparse = self.d.expand_cache[key]
+                self.references |= varparse.references
+                self.execs |= varparse.execs
+                return varparse.value
             var = self.d.getVar(key, True)
+            self.references.add(key)
             if var is not None:
-                self.references.add(key)
                 return var
             else:
                 return match.group()
@@ -357,7 +362,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 +398,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 +421,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:
@@ -500,12 +510,7 @@ class DataSmart(MutableMapping):
             self._seen_overrides[override].add( var )
 
     def getVar(self, var, expand=False, noweakdefault=False):
-        value = self.getVarFlag(var, "_content", False, noweakdefault)
-
-        # Call expand() separately to make use of the expand cache
-        if expand and value:
-            return self.expand(value, var)
-        return value
+        return self.getVarFlag(var, "_content", expand, noweakdefault)
 
     def renameVar(self, key, newkey, **loginfo):
         """
@@ -519,7 +524,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
@@ -573,16 +578,33 @@ class DataSmart(MutableMapping):
         if flag == "defaultval" and '_' in var:
             self._setvar_update_overrides(var)
 
+        if flag == "unexport" or flag == "export":
+            if not "__exportlist" in self.dict:
+                self._makeShadowCopy("__exportlist")
+            if not "_content" in self.dict["__exportlist"]:
+                self.dict["__exportlist"]["_content"] = set()
+            self.dict["__exportlist"]["_content"].add(var)
+
     def getVarFlag(self, var, flag, expand=False, noweakdefault=False):
         local_var = self._findVar(var)
         value = None
-        if local_var:
+        if local_var is not None:
             if flag in local_var:
                 value = copy.copy(local_var[flag])
             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
+            else:
+                cachename = var + "[" + flag + "]"
+            value = self.expand(value, cachename)
+        if value is not None and flag == "_content" and local_var is not None 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):
@@ -627,16 +649,17 @@ class DataSmart(MutableMapping):
             self.varhistory.record(**loginfo)
             self.dict[var][i] = flags[i]
 
-    def getVarFlags(self, var):
+    def getVarFlags(self, var, expand = False, internalflags=False):
         local_var = self._findVar(var)
         flags = {}
 
         if local_var:
             for i in local_var:
-                if i.startswith("_"):
+                if i.startswith("_") and not internalflags:
                     continue
                 flags[i] = local_var[i]
-
+                if expand and i in expand:
+                    flags[i] = self.expand(flags[i], var + "[" + i + "]")
         if len(flags) == 0:
             return None
         return flags
@@ -742,13 +765,16 @@ class DataSmart(MutableMapping):
         for key in keys:
             if key in config_whitelist:
                 continue
+
             value = d.getVar(key, False) or ""
             data.update({key:value})
 
-            varflags = d.getVarFlags(key)
+            varflags = d.getVarFlags(key, internalflags = True)
             if not varflags:
                 continue
             for f in varflags:
+                if f == "_content":
+                    continue
                 data.update({'%s[%s]' % (key, f):varflags[f]})
 
         for key in ["__BBTASKS", "__BBANONFUNCS", "__BBHANDLERS"]:

bitbake/lib/bb/event.py

@@ -63,6 +63,7 @@ def clean_class_handlers():
 # Internal
 _handlers = clean_class_handlers()
 _ui_handlers = {}
+_ui_logfilters = {}
 _ui_handler_seq = 0
 _event_handler_map = {}
 _catchall_handlers = {}
@@ -135,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.
@@ -190,7 +193,7 @@ def register(name, handler, mask=[]):
         else:
             _handlers[name] = handler
 
-        if not mask:
+        if not mask or '*' in mask:
             _catchall_handlers[name] = True
         else:
             for m in mask:
@@ -207,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):
@@ -214,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:
@@ -341,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/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/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
 

bitbake/lib/bb/runqueue.py

@@ -601,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]]
 
@@ -690,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)
@@ -697,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():
@@ -846,6 +859,9 @@ class RunQueue:
             "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>")
@@ -889,6 +905,14 @@ class RunQueue:
         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):
             try:
@@ -966,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)
@@ -1301,9 +1325,10 @@ class RunQueueExecuteTasks(RunQueueExecute):
         if self.rqdata.taskData.abort:
             self.rq.state = runQueueCleanUp
 
-    def task_skip(self, task):
+    def task_skip(self, task, reason):
         self.runq_running[task] = 1
         self.runq_buildable[task] = 1
+        bb.event.fire(runQueueTaskSkipped(task, self.stats, self.rq, reason), self.cfgData)
         self.task_completeoutright(task)
         self.stats.taskCompleted()
         self.stats.taskSkipped()
@@ -1328,13 +1353,13 @@ class RunQueueExecuteTasks(RunQueueExecute):
             if task in self.rq.scenequeue_covered:
                 logger.debug(2, "Setscene covered task %s (%s)", task,
                                 self.rqdata.get_user_idstring(task))
-                self.task_skip(task)
+                self.task_skip(task, "covered")
                 return True
 
             if self.rq.check_stamp_task(task, taskname, cache=self.stampcache):
                 logger.debug(2, "Stamp current task %s (%s)", task,
                                 self.rqdata.get_user_idstring(task))
-                self.task_skip(task)
+                self.task_skip(task, "existing")
                 return True
 
             taskdep = self.rqdata.dataCache.task_deps[fn]
@@ -1369,7 +1394,7 @@ class RunQueueExecuteTasks(RunQueueExecute):
 
         if self.stats.active > 0:
             self.rq.read_workers()
-            return 0.5
+            return self.rq.active_fds()
 
         if len(self.failed_fnids) != 0:
             self.rq.state = runQueueFailed
@@ -1621,6 +1646,7 @@ 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):
@@ -1709,7 +1735,7 @@ class RunQueueExecuteScenequeue(RunQueueExecute):
 
         if self.stats.active > 0:
             self.rq.read_workers()
-            return 0.5
+            return self.rq.active_fds()
 
         # Convert scenequeue_covered task numbers into full taskgraph ids
         oldcovered = self.scenequeue_covered
@@ -1804,6 +1830,19 @@ class runQueueTaskCompleted(runQueueEvent):
     Event notifing a task completed
     """
 
+class sceneQueueTaskCompleted(sceneQueueEvent):
+    """
+    Event notifing a setscene task completed
+    """
+
+class runQueueTaskSkipped(runQueueEvent):
+    """
+    Event notifing a task was skipped
+    """
+    def __init__(self, task, stats, rq, reason):
+        runQueueEvent.__init__(self, task, stats, rq)
+        self.reason = reason
+
 class runQueuePipe():
     """
     Abstraction for a pipe between a worker thread and the server

bitbake/lib/bb/server/process.py

@@ -29,6 +29,7 @@ import os
 import signal
 import sys
 import time
+import select
 from Queue import Empty
 from multiprocessing import Event, Process, util, Queue, Pipe, queues
 
@@ -37,8 +38,9 @@ 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
@@ -54,6 +56,8 @@ class ServerCommunicator():
             except KeyboardInterrupt:
                 pass
 
+    def getEventHandle(self):
+        return self.event_handle.value
 
 class EventAdapter():
     """
@@ -84,11 +88,12 @@ class ProcessServer(Process, BaseImplServer):
 
         self.keep_running = Event()
         self.keep_running.set()
+        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):
@@ -101,17 +106,17 @@ class ProcessServer(Process, BaseImplServer):
                     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.cooker.shutdown(True)
         self.idle_commands(.1)
 
-    def idle_commands(self, delay):
+    def idle_commands(self, delay, fds = []):
         nextsleep = delay
 
         for function, data in self._idlefuns.items():
@@ -123,15 +128,15 @@ class ProcessServer(Process, BaseImplServer):
                     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):
         """
@@ -147,30 +152,28 @@ class BitBakeProcessServerConnection(BitBakeBaseServerConnection):
         self.procserver = serverImpl
         self.ui_channel = ui_channel
         self.event_queue = event_queue
-        self.connection = ServerCommunicator(self.ui_channel)
+        self.connection = ServerCommunicator(self.ui_channel, self.procserver.event_handle)
         self.events = self.event_queue
 
-    def terminate(self, force = False):
+    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)
+
         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.event_queue.get(block=False)
-            except (Empty, IOError):
-                break
-            if isinstance(event, logging.LogRecord):
-                logger.handle(event)
+
+        while self.procserver.is_alive():
+            flushevents()
+            self.procserver.join(0.1)
+
         self.ui_channel.close()
         self.event_queue.close()
-        if force:
-            sys.exit(1)
 
 # Wrap Queue to provide API which isn't server implementation specific
 class ProcessEventQueue(multiprocessing.queues.Queue):
@@ -203,5 +206,5 @@ class BitBakeServer(BitBakeBaseServer):
 
     def establishConnection(self):
         self.connection = BitBakeProcessServerConnection(self.serverImpl, self.ui_channel, self.event_queue)
-        signal.signal(signal.SIGTERM, lambda i, s: self.connection.terminate(force=True))
+        signal.signal(signal.SIGTERM, lambda i, s: self.connection.terminate())
         return self.connection

bitbake/lib/bb/server/xmlrpc.py

@@ -47,15 +47,29 @@ except ImportError:
 DEBUG = False
 
 from SimpleXMLRPCServer import SimpleXMLRPCServer, SimpleXMLRPCRequestHandler
-import inspect, select
+import inspect, select, httplib
 
 from . import BitBakeBaseServer, BitBakeBaseServerConnection, BaseImplServer
 
 class BBTransport(xmlrpclib.Transport):
-    def __init__(self):
+    def __init__(self, timeout):
+        self.timeout = timeout
         self.connection_token = None
         xmlrpclib.Transport.__init__(self)
 
+    # 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]
+
+        # 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]
+
     def set_connection_token(self, token):
         self.connection_token = token
 
@@ -64,8 +78,8 @@ class BBTransport(xmlrpclib.Transport):
             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
 
@@ -81,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):
         """
@@ -95,6 +110,9 @@ class BitBakeServerCommands():
         """
         return self.cooker.command.runCommand(command, self.server.readonly)
 
+    def getEventHandle(self):
+        return self.event_handle
+
     def terminateServer(self):
         """
         Trigger the server to quit
@@ -115,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
@@ -149,51 +169,6 @@ class BitBakeXMLRPCRequestHandler(SimpleXMLRPCRequestHandler):
         self.end_headers()
         self.wfile.write(response)
 
-class BitBakeUIEventServer(threading.Thread):
-    class EventAdapter():
-        """
-        Adapter to wrap our event queue since the caller (bb.event) expects to
-        call a send() method, but our actual queue only has put()
-        """
-        def __init__(self, notify):
-            self.queue = []
-            self.notify = notify
-            self.qlock = threading.Lock()
-
-        def send(self, event):
-            self.qlock.acquire()
-            self.queue.append(event)
-            self.qlock.release()
-            self.notify.set()
-
-        def get(self):
-            self.qlock.acquire()
-            if len(self.queue) == 0:
-                self.qlock.release()
-                return None
-            e = self.queue.pop(0)
-            if len(self.queue) == 0:
-                self.notify.clear()
-            self.qlock.release()
-            return e
-
-    def __init__(self, connection):
-        self.connection = connection
-        self.notify = threading.Event()
-        self.event = BitBakeUIEventServer.EventAdapter(self.notify)
-        self.quit = False
-        threading.Thread.__init__(self)
-
-    def terminateServer(self):
-        self.quit = True
-
-    def run(self):
-        while not self.quit:
-            self.notify.wait(0.1)
-            evt = self.event.get()
-            if evt:
-                self.connection.event.sendpickle(pickle.dumps(evt))
-
 
 class XMLRPCProxyServer(BaseImplServer):
     """ not a real working server, but a stub for a proxy server connection
@@ -221,6 +196,9 @@ class XMLRPCServer(SimpleXMLRPCServer, BaseImplServer):
         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):
         BaseImplServer.addcooker(self, cooker)
@@ -246,12 +224,9 @@ class XMLRPCServer(SimpleXMLRPCServer, BaseImplServer):
         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)
@@ -259,21 +234,22 @@ class XMLRPCServer(SimpleXMLRPCServer, BaseImplServer):
                         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:

bitbake/lib/bb/siggen.py

@@ -91,8 +91,7 @@ class SignatureGeneratorBasic(SignatureGenerator):
         basehash = {}
 
         for task in tasklist:
-            data = d.getVar(task, False)
-            lookupcache[task] = data
+            data = lookupcache[task]
 
             if data is None:
                 bb.error("Task %s from %s seems to be empty?!" % (task, fn))
@@ -115,16 +114,8 @@ class SignatureGeneratorBasic(SignatureGenerator):
             alldeps = sorted(seen)
             for dep in alldeps:
                 data = data + dep
-                if dep in lookupcache:
-                    var = lookupcache[dep]
-                elif dep[-1] == ']':
-                    vf = dep[:-1].split('[')
-                    var = d.getVarFlag(vf[0], vf[1], False)
-                    lookupcache[dep] = var
-                else:
-                    var = d.getVar(dep, False)
-                    lookupcache[dep] = var
-                if var:
+                var = lookupcache[dep]
+                if var is not None:
                     data = data + str(var)
             self.basehash[fn + "." + task] = hashlib.md5(data).hexdigest()
             taskdeps[task] = alldeps

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/ui/crumbs/builder.py

@@ -440,6 +440,7 @@ 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)
@@ -519,6 +520,7 @@ 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")
@@ -593,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()
 
@@ -1451,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/hobeventhandler.py

@@ -166,17 +166,15 @@ class HobHandler(gobject.GObject):
             self.clear_busy()
             self.building = True
             targets = [self.image]
-            if self.package_queue:
-                self.set_var_in_file("LINGUAS_INSTALL", "", "local.conf")
-                self.set_var_in_file("PACKAGE_INSTALL", " ".join(self.package_queue), "local.conf")
             if 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)
 
@@ -426,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
 
@@ -435,12 +440,12 @@ class HobHandler(gobject.GObject):
         self.building = False
 
     def cancel_parse(self):
-        self.runCommand(["stateStop"])
+        self.runCommand(["stateForceShutdown"])
 
     def cancel_build(self, force=False):
         if force:
             # Force the cooker to stop as quickly as possible
-            self.runCommand(["stateStop"])
+            self.runCommand(["stateForceShutdown"])
         else:
             # Wait for tasks to complete before shutting down, this helps
             # leave the workdir in a usable state
@@ -452,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():
@@ -461,9 +469,18 @@ class HobHandler(gobject.GObject):
 
     def set_var_in_file(self, var, val, default_file=None):
         self.runCommand(["enableDataTracking"])
-        self.server.runCommand(["setVarFile", var, val, default_file])
+        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
         params = {}

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):
@@ -200,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):
@@ -229,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()
@@ -258,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)
@@ -272,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)
 
@@ -314,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()
 
@@ -362,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
@@ -428,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)
@@ -451,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:
@@ -471,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/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):
@@ -320,7 +314,7 @@ def main(server, eventHandler, params):
                 break
             if shutdown == 1:
                 print("\nSecond Keyboard Interrupt, stopping...\n")
-                _, error = server.runCommand(["stateStop"])
+                _, error = server.runCommand(["stateForceShutdown"])
                 if error:
                     print('Unable to cleanly stop: %s' % error)
             if shutdown == 0:

bitbake/lib/bb/ui/goggle.py

@@ -117,5 +117,5 @@ def main (server, eventHandler, params):
     except KeyboardInterrupt:
         pass
     finally:
-        server.runCommand(["stateStop"])
+        server.runCommand(["stateForceShutdown"])
 

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

@@ -232,6 +232,15 @@ def _log_settings_from_server(server):
         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)
@@ -262,6 +271,9 @@ def main(server, eventHandler, params, tf = TerminalFilter):
         consolelog.setFormatter(conlogformat)
         logger.addHandler(consolelog)
 
+    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()
@@ -294,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
@@ -391,8 +405,9 @@ def main(server, eventHandler, params, tf = TerminalFilter):
 
             if isinstance(event, bb.command.CommandFailed):
                 return_value = event.exitcode
-                errors = errors + 1
-                logger.error("Command execution failed: %s", event.error)
+                if event.error:
+                    errors = errors + 1
+                    logger.error("Command execution failed: %s", event.error)
                 main.shutdown = 2
                 continue
             if isinstance(event, bb.command.CommandExit):
@@ -416,10 +431,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)
@@ -480,7 +500,7 @@ def main(server, eventHandler, params, tf = TerminalFilter):
                 main.shutdown = 2
             if not params.observe_only and main.shutdown == 1:
                 print("\nSecond Keyboard Interrupt, stopping...\n")
-                _, error = server.runCommand(["stateStop"])
+                _, error = server.runCommand(["stateForceShutdown"])
                 if error:
                     logger.error("Unable to cleanly stop: %s" % error)
             if not params.observe_only and main.shutdown == 0:
@@ -501,7 +521,7 @@ def main(server, eventHandler, params, tf = TerminalFilter):
     if warnings:
         summary += pluralise("\nSummary: There was %s WARNING message shown.",
                              "\nSummary: There were %s WARNING messages shown.", warnings)
-    if return_value:
+    if return_value and errors:
         summary += pluralise("\nSummary: There was %s ERROR message shown, returning a non-zero exit code.",
                              "\nSummary: There were %s ERROR messages shown, returning a non-zero exit code.", errors)
     if summary:

bitbake/lib/bb/ui/ncurses.py

@@ -350,7 +350,7 @@ class NCursesUI:
                     exitflag = True
                 if shutdown == 1:
                     mw.appendText("Second Keyboard Interrupt, stopping...\n")
-                    _, error = server.runCommand(["stateStop"])
+                    _, error = server.runCommand(["stateForceShutdown"])
                     if error:
                         print("Unable to cleanly stop: %s" % error)
                 if shutdown == 0:

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()

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()

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/cross-development-toolchains.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
@@ -210,7 +214,12 @@ 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/cross-development-toolchains.png
+        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,10 @@
             <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>
+                or 
+                <ulink url='&YOCTO_DOCS_REF_URL;#structure-memres-core-script'><filename>oe-init-build-env-memres</filename></ulink>)
+                located in the Source Directory before running the
                 BitBake command that creates the tarball.
             </para>
 
@@ -229,9 +231,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 +245,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 +522,58 @@
     </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 build environment setup script 
+         (i.e.
+         <ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>
+         or
+         <ulink url='&YOCTO_DOCS_REF_URL;#structure-memres-core-script'><filename>oe-init-build-env-memres</filename></ulink>)
+         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

@@ -1367,7 +1367,7 @@
             <para>
                 You might also need these variables:
                 <itemizedlist>
-                    <listitem><para><filename><ulink url='&YOCTO_DOCS_REF_URL;#var-SERIAL_CONSOLE'>SERIAL_CONSOLE</ulink></filename>
+                    <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>
@@ -1812,6 +1812,8 @@
                 environment, you must build the tool using BitBake.
                 Thus, the environment must be set up using the
                 <ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>
+                or
+                <ulink url='&YOCTO_DOCS_REF_URL;#structure-memres-core-script'><filename>oe-init-build-env-memres</filename></ulink>
                 script found in the
                 <link linkend='build-directory'>Build Directory</link>.
                 The following commands build and invoke <filename>menuconfig</filename> assuming the
@@ -2924,6 +2926,8 @@
         <para>
             This section describes a few tasks that involve packages:
             <itemizedlist>
+                <listitem><para>Excluding packages from an image
+                    </para></listitem>
                 <listitem><para>Incrementing a package revision number
                     </para></listitem>
                 <listitem><para>Handling a package name alias
@@ -2938,6 +2942,50 @@
             </itemizedlist>
         </para>
 
+        <section id='excluding-packages-from-an-image'>
+            <title>Excluding Packages from an Image</title>
+
+            <para>
+                You might find it necessary to prevent specific packages 
+                from being installed into an image.
+                If so, you can use several variables to direct the build
+                system to essentially ignore installing recommended packages
+                or to not install a package at all.
+            </para>
+
+            <para>
+                The following list introduces variables you can use to 
+                prevent packages from being installed into your image.
+                Each of these variables only works with IPK and RPM
+                package types.
+                Support for Debian packages does not exist.
+                Also, you can use these variables from your  
+                <filename>local.conf</filename> file or attach them to a 
+                specific image recipe by using a recipe name override.
+                For more detail on the variables, see the descriptions in the 
+                Yocto Project Reference Manual's glossary chapter.
+                <itemizedlist>
+                    <listitem><para><ulink url='&YOCTO_DOCS_REF_URL;#var-BAD_RECOMMENDATIONS'><filename>BAD_RECOMMENDATIONS</filename></ulink>:
+                        Use this variable to specify "recommended-only"  
+                        packages that you do not want installed.
+                        </para></listitem>
+                    <listitem><para><ulink url='&YOCTO_DOCS_REF_URL;#var-NO_RECOMMENDATIONS'><filename>NO_RECOMMENDATIONS</filename></ulink>:
+                        Use this variable to prevent all "recommended-only"  
+                        packages from being installed.
+                        </para></listitem>
+                    <listitem><para><ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGE_EXCLUDE'><filename>PACKAGE_EXCLUDE</filename></ulink>:
+                        Use this variable to prevent specific packages from 
+                        being installed regardless of whether they are
+                        "recommended-only" or not.
+                        You need to realize that the build process could 
+                        fail with an error when you 
+                        prevent the installation of a package whose presence
+                        is required by an installed package.
+                        </para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+
         <section id='incrementing-a-package-revision-number'>
             <title>Incrementing a Package Revision Number</title>
 
@@ -3465,7 +3513,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 +3544,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>
@@ -3749,54 +3797,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 +4371,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>
 
@@ -4791,15 +5028,15 @@
      BBFILES ?= ""
 
      BBLAYERS ?= " \
-       ##COREBASE##/meta \
-       ##COREBASE##/meta-yocto \
-       ##COREBASE##/meta-yocto-bsp \
-       ##COREBASE##/meta-mylayer \
+       ##OEROOT##/meta \
+       ##OEROOT##/meta-yocto \
+       ##OEROOT##/meta-yocto-bsp \
+       ##OEROOT##/meta-mylayer \
        "
 
      BBLAYERS_NON_REMOVABLE ?= " \
-       ##COREBASE##/meta \
-       ##COREBASE##/meta-yocto \
+       ##OEROOT##/meta \
+       ##OEROOT##/meta-yocto \
        "
                 </literallayout>
                 Creating and providing an archive of the

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-model.xml

@@ -156,7 +156,7 @@
                     "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-layers'>BSP Layers</ulink>" section in the
                     Yocto Project Board Support Package (BSP) Developer's Guide.</para>
                     <note>Four BSPs exist that are part of the
-                    Yocto Project release: <filename>atom-pc</filename>, <filename>beagleboard</filename>,
+                    Yocto Project release: <filename>genericx86</filename>, <filename>beagleboard</filename>,
                     <filename>mpc8315e</filename>, and <filename>routerstationpro</filename>.
                     The recipes and configurations for these four BSPs are located and dispersed
                     within the <link linkend='source-directory'>Source Directory</link>.

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,
@@ -509,7 +509,9 @@
                 This term refers to the area used by the OpenEmbedded build system for builds.
                 The area is created when you <filename>source</filename> the setup
                 environment script that is found in the Source Directory
-                (i.e. <ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>).
+                (i.e. <ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>
+                or
+                <ulink url='&YOCTO_DOCS_REF_URL;#structure-memres-core-script'><filename>oe-init-build-env-memres</filename></ulink>).
                 The <ulink url='&YOCTO_DOCS_REF_URL;#var-TOPDIR'><filename>TOPDIR</filename></ulink>
                 variable points to the Build Directory.</para>
 
@@ -1405,7 +1407,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>
@@ -1537,7 +1539,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,20 +681,22 @@
         <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 run the 
+                build environment setup script (i.e.
                 <link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>
-                setup script.
+                or
+                <link linkend='structure-memres-core-script'><filename>oe-init-build-env-memres</filename></link>).
                 By default, this <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
                 is named <filename>build</filename> but can be named
                 anything you want.
             </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

@@ -102,10 +102,36 @@
 
         <para>
             Currently, the Yocto Project is supported on the following
-            distributions.
-            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.
+            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>
@@ -116,8 +142,8 @@
                 <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>
@@ -147,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
@@ -266,30 +292,106 @@
                         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>
             </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

@@ -230,6 +230,30 @@
             </para>
         </section>
     </section>
+
+    <section id='1.3-linux-kernel-naming'>
+        <title>Linux Kernel Naming</title>
+
+        <para>
+            The naming scheme for kernel output binaries has been changed to
+            now include
+            <link linkend='var-PE'><filename>PE</filename></link> as part of the
+            filename:
+            <literallayout class='monospaced'>
+     KERNEL_IMAGE_BASE_NAME ?= "${KERNEL_IMAGETYPE}-${PE}-${PV}-${PR}-${MACHINE}-${DATETIME}"
+            </literallayout>
+        </para>
+
+        <para>
+            Because the <filename>PE</filename> variable is not set by default,
+            these binary files could result with names that include two dash
+            characters.
+            Here is an example:
+            <literallayout class='monospaced'>
+     bzImage--3.10.9+git0+cd502a8814_7144bcc4b8-r0-qemux86-64-20130830085431.bin
+            </literallayout>
+        </para>
+    </section>
 </section>
 
 <section id='moving-to-the-yocto-project-1.4-release'>
@@ -247,30 +271,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 +309,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 +352,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 +364,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 +382,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 +400,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 +437,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 +452,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 +503,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 +514,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 +526,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 +534,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 +545,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 +553,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-bitbake.xml

@@ -322,10 +322,10 @@
 $ bitbake --help
 Usage: bitbake [options] [package ...]
 
-Executes the specified task (default is 'build') for a given set of BitBake files.
-It expects that BBFILES is defined, which is a space separated list of files to
-be executed.  BBFILES does support wildcards.
-Default BBFILES are the .bb files in the current directory.
+    Executes the specified task (default is 'build') for a given set of BitBake files.
+    It expects that BBFILES is defined, which is a space separated list of files to
+    be executed.  BBFILES does support wildcards.
+    Default BBFILES are the .bb files in the current directory.
 
 Options:
   --version             show program's version number and exit
@@ -348,6 +348,10 @@ Options:
                         what you are doing). Depending on the base.bbclass a
                         listtasks tasks is defined and will show available
                         tasks
+  -C INVALIDATE_STAMP, --clear-stamp=INVALIDATE_STAMP
+                        Invalidate the stamp for the specified cmd such as
+                        'compile' and run the default task for the specified
+                        target(s)
   -r PREFILE, --read=PREFILE
                         read the specified file before bitbake.conf
   -R POSTFILE, --postread=POSTFILE
@@ -360,11 +364,12 @@ Options:
                         don't execute, just dump out the signature
                         construction information
   -p, --parse-only      quit after parsing the BB files (developers only)
-  -s, --show-versions   show current and preferred versions of all packages
+  -s, --show-versions   show current and preferred versions of all recipes
   -e, --environment     show the global or per-package environment (this is
                         what used to be bbread)
   -g, --graphviz        emit the dependency trees of the specified packages in
-                        the dot syntax
+                        the dot syntax, and the pn-buildlist to show the build
+                        list
   -I EXTRA_ASSUME_PROVIDED, --ignore-deps=EXTRA_ASSUME_PROVIDED
                         Assume these dependencies don't exist and are already
                         provided (equivalent to ASSUME_PROVIDED). Useful to
@@ -374,9 +379,17 @@ Options:
   -P, --profile         profile the command and print a report
   -u UI, --ui=UI        userinterface to use
   -t SERVERTYPE, --servertype=SERVERTYPE
-                        Choose which server to use, none, process or xmlrpc
+                        Choose which server to use, process or xmlrpc
   --revisions-changed   Set the exit code depending on whether upstream
                         floating revisions have changed or not
+  --server-only         Run bitbake without UI,  the frontend can connect with
+                        bitbake server itself
+  -B BIND, --bind=BIND  The name/address for the bitbake server to bind to
+  --no-setscene         Do not run any setscene tasks, forces builds
+  --remote-server=REMOTE_SERVER
+                        Connect to the specified server
+  -m, --kill-server     Terminate the remote server
+  --observe-only        Connect to a server as an observing-only client
         </screen>
     </section>
 

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>

documentation/ref-manual/ref-manual.xml

@@ -99,6 +99,8 @@
 
     <xi:include href="usingpoky.xml"/>
 
+    <xi:include href="closer-look.xml"/>
+
     <xi:include href="technical-details.xml"/>
 
     <xi:include href="migration.xml"/>

documentation/ref-manual/ref-structure.xml

@@ -74,7 +74,11 @@
             the source tree is combined with the output.
             The <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
             is created initially when you <filename>source</filename>
-            the OpenEmbedded build environment setup script <filename>&OE_INIT_FILE;</filename>.
+            the OpenEmbedded build environment setup script 
+            (i.e.
+            <link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>
+            or
+            <link linkend='structure-memres-core-script'><filename>oe-init-build-env-memres</filename></link>).
         </para>
 
         <para>
@@ -85,8 +89,10 @@
             the setup script.
             For information on separating output from your local
             Source Directory files, see the
-            "<link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>"
-            section.
+            "<link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>
+            and
+            "<link linkend='structure-memres-core-script'><filename>oe-init-build-env-memres</filename></link>"
+            sections.
         </para>
     </section>
 
@@ -143,7 +149,7 @@
             which is a Yocto Project build user interface.
             For more information on the Hob, see the
             <ulink url='&YOCTO_HOME_URL;/tools-resources/projects/hob'>Hob Project</ulink>
-            webpage.
+            web page.
         </para>
     </section>
 
@@ -162,7 +168,9 @@
             This directory contains various integration scripts that implement
             extra functionality in the Yocto Project environment (e.g. QEMU scripts).
             The <link linkend="structure-core-script"><filename>&OE_INIT_FILE;</filename></link>
-            script appends this directory to the shell's
+            and
+            <link linkend='structure-memres-core-script'><filename>oe-init-build-env-memres</filename></link>
+            scripts append this directory to the shell's
             <filename>PATH</filename> environment variable.
         </para>
 
@@ -177,11 +185,19 @@
         <title><filename>&OE_INIT_FILE;</filename></title>
 
         <para>
-            This script sets up the OpenEmbedded build environment.
+            This script is one of two scripts that set up the OpenEmbedded build 
+            environment.
+            For information on the other script, see the 
+            "<link linkend='structure-memres-core-script'><filename>oe-init-build-env-memres</filename></link>"
+            section.
+        </para>
+
+        <para>
             Running this script with the <filename>source</filename> command in
             a shell makes changes to <filename>PATH</filename> and sets other
             core BitBake variables based on the current working directory.
-            You need to run this script before running BitBake commands.
+            You need to run an environment setup script before running BitBake 
+            commands.
             The script uses other scripts within the
             <filename>scripts</filename> directory to do the bulk of the work.
         </para>
@@ -191,7 +207,7 @@
             <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
             argument creates the <filename>build</filename> directory.
             If you provide a Build Directory argument when you
-            <filename>source</filename> the script, you direct OpenEmbedded
+            <filename>source</filename> the script, you direct the OpenEmbedded
             build system to create a Build Directory of your choice.
             For example, the following command creates a Build Directory named
             <filename>mybuilds</filename> that is outside of the
@@ -211,6 +227,81 @@
         </para>
     </section>
 
+    <section id='structure-memres-core-script'>
+        <title><filename>oe-init-build-env-memres</filename></title>
+
+        <para>
+            This script is one of two scripts that set up the OpenEmbedded build 
+            environment.
+            Setting up the environment with this script uses a 
+            memory-resident BitBake.
+            For information on the other setup script, see the 
+            "<link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>"
+            section.
+        </para>
+
+        <para>
+            Memory-resident BitBake resides in memory until you specifically
+            remove it using the following BitBake command:
+            <literallayout class='monospaced'>
+     $ bitbake -m
+            </literallayout>
+        </para>
+
+        <para>
+            Running this script with the <filename>source</filename> command in
+            a shell makes changes to <filename>PATH</filename> and sets other
+            core BitBake variables based on the current working directory.
+            One of these variables is the 
+            <link linkend='var-BBSERVER'><filename>BBSERVER</filename></link>
+            variable, which allows the OpenEmbedded build system to locate 
+            the server that is running BitBake.
+        </para>
+
+        <para>
+            You need to run an environment setup script before running BitBake 
+            commands.
+            Following is the script syntax:
+            <literallayout class='monospaced'>
+     $ source oe-init-build-env-memres &lt;port_number&gt; &lt;build_dir&gt;
+            </literallayout>
+            The script uses other scripts within the
+            <filename>scripts</filename> directory to do the bulk of the work.
+        </para>
+
+        <para>
+            If you do not provide a port number with the script, the default
+            port "12345" is used.
+        </para>
+
+        <para>
+            By default, running this script without a
+            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
+            argument creates the <filename>build</filename> directory.
+            If you provide a Build Directory argument when you
+            <filename>source</filename> the script, you direct the OpenEmbedded
+            build system to create a Build Directory of your choice.
+            For example, the following command uses the default port number
+            "12345" and creates a Build Directory named
+            <filename>mybuilds</filename> that is outside of the
+            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>:
+            <literallayout class='monospaced'>
+     $ source oe-init-build-env-memres ~/mybuilds
+            </literallayout>
+            <note>
+                The OpenEmbedded build system does not support file or 
+                directory names that contain spaces.
+                If you attempt to run the 
+                <filename>oe-init-build-env-memres</filename> script
+                from a Source Directory that contains spaces in either the 
+                filenames or directory names, the script returns an error 
+                indicating no such file or directory.
+                Be sure to use a Source Directory free of names containing 
+                spaces.
+            </note>
+        </para>
+    </section>
+
     <section id='structure-basic-top-level'>
         <title><filename>LICENSE, README, and README.hardware</filename></title>
 
@@ -243,47 +334,123 @@
         <title><filename>build/conf/local.conf</filename></title>
 
         <para>
-            This file contains all the local user configuration for your build environment.
-            If there is no <filename>local.conf</filename> present, it is created from
-            <filename>local.conf.sample</filename>.
-            The <filename>local.conf</filename> file contains documentation on the various configuration options.
-            Any variable set here overrides any variable set elsewhere within the environment unless
-            that variable is hard-coded within a file (e.g. by using '=' instead of '?=').
-            Some variables are hard-coded for various reasons but these variables are
-            relatively rare.
+            This configuration file contains all the local user configurations 
+            for your build environment.
+            The <filename>local.conf</filename> file contains documentation on 
+            the various configuration options.
+            Any variable set here overrides any variable set elsewhere within 
+            the environment unless that variable is hard-coded within a file 
+            (e.g. by using '=' instead of '?=').
+            Some variables are hard-coded for various reasons but these 
+            variables are relatively rare.
         </para>
 
         <para>
-            Edit this file to set the <filename><link linkend='var-MACHINE'>MACHINE</link></filename>
+            Edit this file to set the 
+            <filename><link linkend='var-MACHINE'>MACHINE</link></filename>
             for which you want to build, which package types you wish to use
             (<link linkend='var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></link>),
             the location from which you want to downloaded files
             (<filename><link linkend='var-DL_DIR'>DL_DIR</link></filename>),
             and how you want your host machine to use resources
-            (<link linkend='var-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename></link> and
+            (<link linkend='var-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename></link> 
+            and
             <link linkend='var-PARALLEL_MAKE'><filename>PARALLEL_MAKE</filename></link>).
         </para>
+
+        <para>
+            If <filename>local.conf</filename> is not present when you 
+            start the build, the OpenEmbedded build system creates it from 
+            <filename>local.conf.sample</filename> when
+            you <filename>source</filename> the top-level build environment 
+            setup script (i.e.
+            <link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>
+            or 
+            <link linkend='structure-memres-core-script'><filename>oe-init-build-env-memres</filename></link>).
+        </para>
+
+        <para>
+            The source <filename>local.conf.sample</filename> file used 
+            depends on the <filename>$TEMPLATECONF</filename> script variable,
+            which defaults to <filename>/meta-yocto/conf</filename>
+            when you are building from the Yocto Project development 
+            environment and defaults to <filename>/meta/conf</filename> when 
+            you are building from the OpenEmbedded Core environment.
+            Because the script variable points to the source of the 
+            <filename>local.conf.sample</filename> file, this implies that 
+            you can configure your build environment from any layer by setting     
+            the variable in the top-level build environment setup script as 
+            follows:
+            <literallayout class='monospaced'>
+     TEMPLATECONF=&lt;your_layer&gt;/conf
+            </literallayout>
+            Once the build process gets the sample file, it uses 
+            <filename>sed</filename> to substitute final 
+            <filename>${</filename><link linkend='var-OEROOT'><filename>OEROOT</filename></link><filename>}</filename> 
+            values for all <filename>##OEROOT##</filename> values.
+            <note>
+                You can see how the <filename>TEMPLATECONF</filename> variable
+                is used by looking at the       
+                <filename>/scripts/oe-setup-builddir</filename> script in the 
+                <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+                You can find the Yocto Project version of the 
+                <filename>local.conf.sample</filename> file in the 
+                <filename>/meta-yocto/conf</filename> directory.                
+            </note>
+        </para>
     </section>
 
     <section id='structure-build-conf-bblayers.conf'>
         <title><filename>build/conf/bblayers.conf</filename></title>
 
         <para>
-            This file defines
+            This configuration file defines
             <ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>layers</ulink>,
             which are directory trees, traversed (or walked) by BitBake.
-            If <filename>bblayers.conf</filename>
-            is not present, it is created from <filename>bblayers.conf.sample</filename> when
-            you <filename>source</filename> the environment setup script.
+            The <filename>bblayers.conf</filename> file uses the
+            <link linkend='var-BBLAYERS'><filename>BBLAYERS</filename></link> 
+            variable to list the layers BitBake tries to find, and uses the
+            <link linkend='var-BBLAYERS_NON_REMOVABLE'><filename>BBLAYERS_NON_REMOVABLE</filename></link>
+            variable to list layers that must not be removed.
         </para>
 
         <para>
-            The <filename>bblayers.conf</filename> file uses the
-            <link linkend='var-BBLAYERS'><filename>BBLAYERS</filename></link> variable to
-            list the layers BitBake tries to find.
-            The file uses the
-            <link linkend='var-BBLAYERS_NON_REMOVABLE'><filename>BBLAYERS_NON_REMOVABLE</filename></link>
-            variable to list layers that must not be removed.
+            If <filename>bblayers.conf</filename> is not present when you 
+            start the build, the OpenEmbedded build system creates it from 
+            <filename>bblayers.conf.sample</filename> when
+            you <filename>source</filename> the top-level build environment 
+            setup script (i.e.
+            <link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>
+            or 
+            <link linkend='structure-memres-core-script'><filename>oe-init-build-env-memres</filename></link>).
+        </para>
+
+        <para>
+            The source <filename>bblayers.conf.sample</filename> file used 
+            depends on the <filename>$TEMPLATECONF</filename> script variable,
+            which defaults to <filename>/meta-yocto/conf</filename>
+            when you are building from the Yocto Project development 
+            environment and defaults to <filename>/meta/conf</filename> when 
+            you are building from the OpenEmbedded Core environment.
+            Because the script variable points to the source of the 
+            <filename>bblayers.conf.sample</filename> file, this implies that 
+            you can base your build from any layer by setting the variable in
+            the top-level build environment setup script as follows:
+            <literallayout class='monospaced'>
+     TEMPLATECONF=&lt;your_layer&gt;/conf
+            </literallayout>
+            Once the build process gets the sample file, it uses 
+            <filename>sed</filename> to substitute final 
+            <filename>${</filename><link linkend='var-OEROOT'><filename>OEROOT</filename></link><filename>}</filename> 
+            values for all <filename>##OEROOT##</filename> values.
+            <note>
+                You can see how the <filename>TEMPLATECONF</filename> variable
+                <filename>/scripts/oe-setup-builddir</filename> script in the 
+                <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+                You can find the Yocto Project version of the 
+                <filename>bblayers.conf.sample</filename> file in the 
+                <filename>/meta-yocto/conf</filename> directory.                
+            </note>
         </para>
     </section>
 
@@ -356,7 +523,15 @@
         <title><filename>build/tmp/deploy/</filename></title>
 
         <para>
-            This directory contains any "end result" output from the OpenEmbedded build process.
+            This directory contains any "end result" output from the
+            OpenEmbedded build process.
+            The <link linkend='var-DEPLOY_DIR'><filename>DEPLOY_DIR</filename></link>
+            variable points to this directory.
+            For more detail on the contents of the <filename>deploy</filename>
+            directory, see the
+            "<link linkend='images-dev-environment'>Images</link>" and
+            "<link linkend='sdk-dev-environment'>Application Development SDK</link>"
+            sections.
         </para>
     </section>
 

documentation/ref-manual/ref-varlocality.xml

@@ -58,7 +58,7 @@
                 <itemizedlist>
                     <listitem><para><filename><link linkend='var-TARGET_ARCH'>TARGET_ARCH</link></filename>
                         </para></listitem>
-                    <listitem><para><filename><link linkend='var-SERIAL_CONSOLE'>SERIAL_CONSOLE</link>
+                    <listitem><para><filename><link linkend='var-SERIAL_CONSOLES'>SERIAL_CONSOLES</link>
                         </filename></para></listitem>
                     <listitem><para><filename><link linkend='var-PACKAGE_EXTRA_ARCHS'>PACKAGE_EXTRA_ARCHS</link>
                         </filename></para></listitem>

documentation/ref-manual/technical-details.xml

@@ -201,7 +201,7 @@
         The chain of events that occurs when <filename>gcc-cross</filename> is
         bootstrapped is as follows:
         <literallayout class='monospaced'>
-     gcc -> binutils-cross -> gcc-cross-initial -> linux_libc-headers -> eglibc-initial -> eglibc -> gcc-cross -> gcc-runtime
+     gcc -> binutils-cross -> gcc-cross-initial -> linux-libc-headers -> eglibc-initial -> eglibc -> gcc-cross -> gcc-runtime
         </literallayout>
         <itemizedlist>
             <listitem><para><filename>gcc</filename>:
@@ -221,7 +221,7 @@
                 This tool is a "native" package (i.e. it is designed to run on
                 the build host).
                 </para></listitem>
-            <listitem><para><filename>linux_libc-headers</filename>:
+            <listitem><para><filename>linux-libc-headers</filename>:
                 Headers needed for the cross-compiler.
                 </para></listitem>
             <listitem><para><filename>eglibc-initial</filename>:
@@ -263,7 +263,8 @@
         The figure shows the commands you use to easily build out this
         toolchain.
         This cross-development toolchain is built to execute on the
-        <filename>SDKMACHINE</filename>, which might or might not be the same
+        <link linkend='var-SDKMACHINE'><filename>SDKMACHINE</filename></link>,
+        which might or might not be the same
         machine as the Build Host.
         <note>
             If your target architecture is supported by the Yocto Project,
@@ -276,7 +277,7 @@
     <para>
         Here is the bootstrap process for the relocatable toolchain:
         <literallayout class='monospaced'>
-     gcc -> binutils-crosssdk -> gcc-crosssdk-initial -> linux_libc-headers -> eglibc-initial -> nativesdk-eglibc -> gcc-crosssdk -> gcc-cross-canadian
+     gcc -> binutils-crosssdk -> gcc-crosssdk-initial -> linux-libc-headers -> eglibc-initial -> nativesdk-eglibc -> gcc-crosssdk -> gcc-cross-canadian
         </literallayout>
         <itemizedlist>
             <listitem><para><filename>gcc</filename>:
@@ -296,7 +297,7 @@
                 finished cross-compiler.
                 This tool is a "native" binary that runs on the build host.
                 </para></listitem>
-            <listitem><para><filename>linux_libc-headers</filename>:
+            <listitem><para><filename>linux-libc-headers</filename>:
                 Headers needed for the cross-compiler.
                 </para></listitem>
             <listitem><para><filename>eglibc-initial</filename>:
@@ -320,7 +321,9 @@
                 </para></listitem>
             <listitem><para><filename>gcc-cross-canadian</filename>:
                 The final relocatable cross-compiler.
-                When run on the <filename>SDKMACHINE</filename>, this tool
+                When run on the
+                <link linkend='var-SDKMACHINE'><filename>SDKMACHINE</filename></link>,
+                this tool
                 produces executable code that runs on the target device.
                 </para></listitem>
         </itemizedlist>
@@ -843,7 +846,7 @@
       DEFAULTTUNE = "x86-64-x32"
       baselib = "${@d.getVar('BASE_LIB_tune-' + (d.getVar('DEFAULTTUNE', True) \
          or 'INVALID'), True) or 'lib'}"
-      #MACHINE = "atom-pc"
+      #MACHINE = "genericx86"
       #DEFAULTTUNE = "core2-64-x32"
                     </literallayout></para></listitem>
                 <listitem><para>As usual, use BitBake to build an image that supports the x32 psABI.
@@ -1035,27 +1038,26 @@
 
             <para>
                 The build system uses the
-                <filename><link linkend='var-S'>S</link></filename> variable as the
-                default directory used when searching files listed in
+                <filename><link linkend='var-S'>S</link></filename> variable as
+                the default directory used when searching files listed in
                 <filename>LIC_FILES_CHKSUM</filename>.
                 The previous example employs the default directory.
             </para>
 
             <para>
-                You can also use relative paths as shown in the following example:
+                Consider this next example:
                 <literallayout class='monospaced'>
      LIC_FILES_CHKSUM = "file://src/ls.c;beginline=5;endline=16;\
                                          md5=bb14ed3c4cda583abc85401304b5cd4e"
-     LIC_FILES_CHKSUM = "file://../license.html;md5=5c94767cedb5d6987c902ac850ded2c6"
+     LIC_FILES_CHKSUM = "file://${WORKDIR}/license.html;md5=5c94767cedb5d6987c902ac850ded2c6"
                 </literallayout>
             </para>
 
             <para>
-                In this example, the first line locates a file in
+                The first line locates a file in
                 <filename>${S}/src/ls.c</filename>.
                 The second line refers to a file in
-                <filename><link linkend='var-WORKDIR'>WORKDIR</link></filename>, which is the parent
-                of <filename><link linkend='var-S'>S</link></filename>.
+                <filename><link linkend='var-WORKDIR'>WORKDIR</link></filename>.
             </para>
             <para>
                 Note that <filename>LIC_FILES_CHKSUM</filename> variable is

documentation/ref-manual/usingpoky.xml

@@ -27,8 +27,13 @@
         <title>Build Overview</title>
 
         <para>
-            The first thing you need to do is set up the OpenEmbedded build environment by sourcing
-            the <link linkend='structure-core-script'>environment setup script</link> as follows:
+            The first thing you need to do is set up the OpenEmbedded build 
+            environment by sourcing an environment setup script
+            (i.e.
+            <link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>
+            or
+            <link linkend='structure-memres-core-script'><filename>oe-init-build-env-memres</filename></link>).
+            Here is an example:
             <literallayout class='monospaced'>
      $ source &OE_INIT_FILE; [&lt;build_dir&gt;]
             </literallayout>

documentation/tools/mega-manual.sed

@@ -9,6 +9,5 @@ s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.5\/yocto-proj
 s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.5\/dev-manual\/dev-manual.html\" target=\"_top\">Yocto Project Development Manual<\/a>/Yocto Project Development Manual/g
 s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.5\/adt-manual\/adt-manual.html\" target=\"_top\">Yocto Project Application Developer's Guide<\/a>/Yocto Project Application Developer's Guide/g
 s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.5\/bsp-guide\/bsp-guide.html\" target=\"_top\">Yocto Project Board Support Package (BSP) Developer's Guide<\/a>/Yocto Project Board Support Package (BSP) Developer's Guide/g
-s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.5\/kernel-manual\/kernel-manual.html\" target=\"_top\">Yocto Project Kernel Architecture and Use Manual<\/a>/Yocto Project Kernel Architecture and Use Manual/g
-s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.5\/kernel-ref\/kernel-ref.html\" target=\"_top\">Yocto Project Kernel Development Manual<\/a>/Yocto Project Kernel Development Manual/g
+s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.5\/kernel-dev\/kernel-dev.html\" target=\"_top\">Yocto Project Linux Kernel Development Manual<\/a>/Yocto Project Linux Kernel Development Manual/g
 s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.5\/ref-manual\/ref-manual.html\" target=\"_top\">Yocto Project Reference Manual<\/a>/Yocto Project Reference Manual/g

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

@@ -11,6 +11,21 @@
             <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_QS_URL;'>Yocto Project Quick Start</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>
+
+
         <abstract>
             <imagedata fileref="figures/yocto-project-transp.png"
                         width="6in" depth="1in"
@@ -156,8 +171,9 @@
 
     <itemizedlist>
         <listitem>
-            <para>A host system running a supported Linux distribution (i.e. recent releases of
-                Fedora, openSUSE, CentOS, and Ubuntu).
+            <para>A host system running a supported Linux distribution
+                (i.e. recent releases of Fedora, openSUSE, CentOS, Debian,
+                and Ubuntu).
                 If the host system supports multiple cores and threads, you can configure the
                 Yocto Project build system to decrease the time needed to build images
                 significantly.
@@ -184,36 +200,56 @@
                 <listitem><para>Fedora</para></listitem>
                 <listitem><para>openSUSE</para></listitem>
                 <listitem><para>CentOS</para></listitem>
+                <listitem><para>Debian</para></listitem>
             </itemizedlist>
             For a more detailed list of distributions that support the Yocto Project,
             see the
             "<ulink url='&YOCTO_DOCS_REF_URL;#detailed-supported-distros'>Supported Linux Distributions</ulink>" section
             in the Yocto Project Reference Manual.
-            <note>
-                For notes about using the Yocto Project on a RHEL 4-based host, see the
-                <ulink url='&YOCTO_WIKI_URL;/wiki/BuildingOnRHEL4'>BuildingOnRHEL4</ulink>
-                wiki page.
-            </note>
             </para>
         <para>
-            The OpenEmbedded build system should be able to run on any modern distribution with Python 2.6 or 2.7.
-            Earlier releases of Python are known to not work and the system does not support Python 3 at this time.
-            This document assumes you are running one of the previously noted distributions on your Linux-based
-            host systems.
+            The OpenEmbedded build system should be able to run on any modern
+            distribution that has the following versions 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 excluding Python
+                   3.x, which is not supported.</para></listitem>
+            </itemizedlist>
+            Earlier releases of Python are known to not work and the system
+            does not support Python 3 at this time.
+            If your system does not meet any of these three listed
+            version requirements, you can
+            take steps to prepare the system so that you can still use the build
+            system.
+            See the
+            "<ulink url='&YOCTO_DOCS_REF_URL;#required-git-tar-and-python-versions'>Required Git, tar, and Python Versions</ulink>"
+            section in the Yocto Project Reference Manual for information.
         </para>
-        <note><para>
-            If you attempt to use a distribution not in the above list, you may or may not have success - you
-            are venturing into untested territory.
-            Refer to
-            <ulink url='&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 other distributions used with the OpenEmbedded project, which might be
-            a starting point for exploration.
-            If you go down this path, you should expect problems.
-            When you do, please go to <ulink url='&YOCTO_BUGZILLA_URL;'>Yocto Project Bugzilla</ulink>
-            and submit a bug.
-            We are interested in hearing about your experience.
-        </para></note>
+        <para>
+            This document assumes you are running one of the previously noted
+            distributions on your Linux-based host systems.
+        </para>
+        <note>
+            <para>
+                If you attempt to use a distribution not in the above list,
+                you may or may not have success.
+                Yocto Project releases are tested against the stable Linux
+                distributions listed in the
+                "<ulink url='&YOCTO_DOCS_REF_URL;#detailed-supported-distros'>Supported Linux Distributions</ulink>"
+                section of the Yocto Project Reference Manual.
+                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>
     </section>
 
     <section id='packages'>
@@ -249,11 +285,11 @@
         </para>
 
         <section id='ubuntu'>
-            <title>Ubuntu</title>
+            <title>Ubuntu and Debian</title>
 
             <para>
-                The essential packages you need for a supported Ubuntu distribution
-                are shown in the following command:
+                The essential packages you need for a supported Ubuntu
+                or Debian distribution are shown in the following command:
                 <literallayout class='monospaced'>
      $ sudo apt-get install &UBUNTU_HOST_PACKAGES_ESSENTIAL; libsdl1.2-dev xterm
                 </literallayout>
@@ -291,7 +327,7 @@
                 The essential packages you need for a supported CentOS
                 distribution are shown in the following command:
                 <literallayout class='monospaced'>
-     $ sudo yum -y install &CENTOS_HOST_PACKAGES_ESSENTIAL; SDL-devel xterm
+     $ sudo yum install &CENTOS_HOST_PACKAGES_ESSENTIAL; SDL-devel xterm
                 </literallayout>
                 <note>Depending on the CentOS version you are using, other requirements
                     and dependencies might exist.
@@ -308,9 +344,9 @@
         <para>
             You can download the latest Yocto Project release by going to the
             <ulink url="&YOCTO_HOME_URL;">Yocto Project website</ulink>
-            clicking "Downloads" in the navigation pane to the left to view all 
+            clicking "Downloads" in the navigation pane to the left to view all
             available Yocto Project releases.
-            Be sure to scroll down and look for "Yocto Project" under the 
+            Be sure to scroll down and look for "Yocto Project" under the
             "Type" heading in the list.
             Nightly and developmental builds are also maintained at
             <ulink url="&YOCTO_AB_NIGHTLY_URL;"></ulink>.
@@ -395,7 +431,7 @@
          <tip><para>
              To help conserve disk space during builds, you can add the following statement
              to your project's configuration file, which for this example
-             is <filename>&YOCTO_POKY;-build/conf/local.conf</filename>.
+             is <filename>&YOCTO_POKY;/build/conf/local.conf</filename>.
              Adding this statement deletes the work directory used for building a package
              once the package is built.
              <literallayout class='monospaced'>
@@ -428,7 +464,12 @@
                  to the Build Directory.
                  Later, when the build completes, the Build Directory contains all the files
                  created during the build.
-                 </para></listitem>
+                 <note>
+                     For information on running a memory-resident BitBake, see
+                     the
+                     <ulink url='&YOCTO_DOCS_REF_URL;#structure-memres-core-script'><filename>oe-init-build-env-memres</filename></ulink>
+                     setup script.
+                 </note></para></listitem>
          </itemizedlist>
          <para>
              Take some time to examine your <filename>local.conf</filename> file
@@ -531,49 +572,67 @@
 
         <section id='installing-the-toolchain'>
             <title>Installing the Toolchain</title>
+
             <para>
-                You can download a tarball installer, which includes the pre-built toolchain, the
-                <filename>runqemu</filename>
+                You can download a tarball installer, which includes the
+                pre-built toolchain, the <filename>runqemu</filename>
                 script, and support files from the appropriate directory under
                 <ulink url='&YOCTO_TOOLCHAIN_DL_URL;'></ulink>.
-                Toolchains are available for 32-bit and 64-bit development systems from the
-                <filename>i686</filename> and <filename>x86-64</filename> directories, respectively.
-                Each type of development system supports five target architectures.
-                The names of the tarball installer scripts are such that a string representing the
-                host system appears first in the filename and then is immediately followed by a
-                string representing the target architecture.
+                Toolchains are available for 32-bit and 64-bit x86 development
+                systems from the <filename>i686</filename> and
+                <filename>x86_64</filename> directories, respectively.
+                The toolchains the Yocto Project provides are based off the
+                <filename>core-image-sato</filename> image and contain
+                libraries appropriate for developing against that image.
+                Each type of development system supports five or more target
+                architectures.
+            </para>
+
+            <para>
+                The names of the tarball installer scripts are such that a
+                string representing the host system appears first in the
+                filename and then is immediately followed by a string
+                that represents the target architecture.
             </para>
 
             <literallayout class='monospaced'>
-     poky-eglibc-&lt;<emphasis>host_system</emphasis>&gt;-&lt;<emphasis>arch</emphasis>&gt;-toolchain-gmae-&lt;<emphasis>release</emphasis>&gt;.sh
+     poky-eglibc-&lt;<emphasis>host_system</emphasis>&gt;-&lt;<emphasis>image_type</emphasis>&gt;-&lt;<emphasis>arch</emphasis>&gt;.sh
 
      Where:
          &lt;<emphasis>host_system</emphasis>&gt; is a string representing your development system:
                 i686 or x86_64.
 
-         &lt;<emphasis>arch</emphasis>&gt; is a string representing the target architecture:
-                i586, x86_64, powerpc, mips, or arm.
+         &lt;<emphasis>image_type</emphasis>&gt; is a string representing the image you wish to
+                develop a Software Development Toolkit (SDK) for use against.
+                The Yocto Project builds toolchain installers using the
+                following BitBake command:
 
-         &lt;<emphasis>release</emphasis>&gt; is the version of Yocto Project.
+                    bitbake core-image-sato -c do_populatesdk core-image-sato
+
+         &lt;<emphasis>arch</emphasis>&gt; is a string representing the tuned target architecture:
+
+                i586, x86_64, powerpc, mips, armv7a or armv5te
             </literallayout>
 
             <para>
-                For example, the following toolchain installer is for a 64-bit development
-                host system and a 32-bit target architecture:
+                For example, the following toolchain installer is for a 64-bit
+                development host system and a i586-tuned target architecture
+                based off the SDK for <filename>core-image-sato</filename>:
+                <literallayout class='monospaced'>
+     poky-eglibc-x86_64-core-image-sato-i586.sh
+                </literallayout>
             </para>
 
-            <literallayout class='monospaced'>
-     poky-eglibc-x86_64-i586-toolchain-gmae-&DISTRO;.sh
-            </literallayout>
-
             <para>
-                Toolchains are self-contained and by default are installed into <filename>/opt/poky</filename>.
-                However, when you run the toolchain installer, you can choose an installation directory.
+                Toolchains are self-contained and by default are installed into
+                <filename>/opt/poky</filename>.
+                However, when you run the toolchain installer, you can choose an
+                installation directory.
             </para>
 
             <para>
                 The following command shows how to run the installer given a toolchain tarball
-                for a 64-bit development host system and a 32-bit target architecture.
+                for a 64-bit x86 development host system and a 32-bit x86 target architecture.
                 You must change the permissions on the toolchain
                 installer script so that it is executable.
             </para>
@@ -589,7 +648,7 @@
 
             <para>
                 <literallayout class='monospaced'>
-     $ ~/Downloads/poky-eglibc-x86_64-i586-toolchain-gmae-&DISTRO;.sh
+     $ ~/Downloads/poky-eglibc-x86_64-core-image-sato-i586.sh
                 </literallayout>
             </para>
 
@@ -663,7 +722,7 @@
                 x86, x86-64, ppc, mips, or arm.
                 </literallayout>
                 <note>
-                    For the <filename>qemu</filename> architecture, 
+                    For the <filename>qemu</filename> architecture,
                     <filename>ext3</filename> and <filename>tar</filename>
                     files start with the "lib32" string.
                 </note>

meta-skeleton/conf/layer.conf

@@ -2,7 +2,7 @@
 BBPATH .= ":${LAYERDIR}"
 
 # We have recipes-* directories, add to BBFILES
-BBFILES += "${LAYERDIR}/recipes-*/*/*.bb"
+BBFILES += "${LAYERDIR}/recipes-*/*/*.bb ${LAYERDIR}/recipes-*/*/*.bbappend"
 
 BBFILE_COLLECTIONS += "skeleton"
 BBFILE_PATTERN_skeleton = "^${LAYERDIR}/"

meta-skeleton/recipes-core/busybox/busybox/no_rfkill.cfg

@@ -0,0 +1 @@
+# CONFIG_RFKILL is not set