bitbake: Revert "fetch2: Adapt encode/decode url to use URI class"

This reverts commit 21fe2683aefde10e847e66c11c26d4f4c1e07cfd
since bitbake-selftest doesn't pass when this is applied and
we're seeing multiple build failures from this change.

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

bitbake/bin/bitbake

@@ -40,7 +40,7 @@ from bb import cooker
 from bb import ui
 from bb import server
 
-__version__ = "1.17.0"
+__version__ = "1.17.1"
 logger = logging.getLogger("BitBake")
 
 # Unbuffer stdout to avoid log truncation in the event
@@ -229,10 +229,8 @@ Default BBFILES are the .bb files in the current directory.""")
     # Before we start modifying the environment we should take a pristine
     # copy for possible later use
     initialenv = os.environ.copy()
-    # Clear away any spurious environment variables. But don't wipe the
-    # environment totally. This is necessary to ensure the correct operation
-    # of the UIs (e.g. for DISPLAY, etc.)
-    bb.utils.clean_environment()
+    # Clear away any spurious environment variables while we stoke up the cooker
+    cleanedvars = bb.utils.clean_environment()
 
     server = server.BitBakeServer()
     if configuration.bind:
@@ -258,6 +256,10 @@ Default BBFILES are the .bb files in the current directory.""")
         # Setup a connection to the server (cooker)
         server_connection = server.establishConnection()
 
+        # Restore the environment in case the UI needs it
+        for k in cleanedvars:
+            os.environ[k] = cleanedvars[k]
+
         try:
             return server.launchUI(ui_main, server_connection.connection, server_connection.events)
         finally:

bitbake/bin/bitbake-diffsigs

@@ -85,8 +85,8 @@ options, args = parser.parse_args(sys.argv)
 if len(args) == 1:
     parser.print_help()
 else:
-    tinfoil = bb.tinfoil.Tinfoil()
     if options.taskmode:
+        tinfoil = bb.tinfoil.Tinfoil()
         if len(args) < 3:
             logger.error("Please specify a recipe and task name")
             sys.exit(1)

bitbake/bin/bitbake-layers

@@ -26,6 +26,7 @@ import os
 import sys
 import fnmatch
 from collections import defaultdict
+import re
 
 bindir = os.path.dirname(__file__)
 topdir = os.path.dirname(bindir)
@@ -458,10 +459,25 @@ build results (as the layer priority order has effectively changed).
         for layer, _, regex, _ in self.bbhandler.cooker.status.bbfile_config_priorities:
             if regex.match(filename):
                 for layerdir in self.bblayers:
-                    if regex.match(os.path.join(layerdir, 'test')):
+                    if regex.match(os.path.join(layerdir, 'test')) and re.match(layerdir, filename):
                         return self.get_layer_name(layerdir)
         return "?"
 
+    def get_file_layerdir(self, filename):
+        for layer, _, regex, _ in self.bbhandler.cooker.status.bbfile_config_priorities:
+            if regex.match(filename):
+                for layerdir in self.bblayers:
+                    if regex.match(os.path.join(layerdir, 'test')) and re.match(layerdir, filename):
+                        return layerdir
+        return "?"
+
+    def remove_layer_prefix(self, f):
+        """Remove the layer_dir prefix, e.g., f = /path/to/layer_dir/foo/blah, the
+           return value will be: layer_dir/foo/blah"""
+        f_layerdir = self.get_file_layerdir(f)
+        prefix = os.path.join(os.path.dirname(f_layerdir), '')
+        return f[len(prefix):] if f.startswith(prefix) else f
+
     def get_layer_name(self, layerdir):
         return os.path.basename(layerdir.rstrip(os.sep))
 
@@ -541,6 +557,164 @@ Recipes are listed with the bbappends that apply to them as subitems.
                 notappended.append(basename)
         return appended, notappended
 
+    def do_show_cross_depends(self, args):
+        """figure out the dependency between recipes that crosses a layer boundary.
+
+usage: show-cross-depends [-f]
+
+Figure out the dependency between recipes that crosses a layer boundary.
+
+Options:
+  -f   show full file path
+
+NOTE:
+The .bbappend file can impact the dependency.
+"""
+        self.bbhandler.prepare()
+
+        show_filenames = False
+        for arg in args.split():
+            if arg == '-f':
+                show_filenames = True
+            else:
+                sys.stderr.write("show-cross-depends: invalid option %s\n" % arg)
+                self.do_help('')
+                return
+
+        pkg_fn = self.bbhandler.cooker_data.pkg_fn
+        bbpath = str(self.bbhandler.config_data.getVar('BBPATH', True))
+        self.require_re = re.compile(r"require\s+(.+)")
+        self.include_re = re.compile(r"include\s+(.+)")
+        self.inherit_re = re.compile(r"inherit\s+(.+)")
+
+        # The bb's DEPENDS and RDEPENDS
+        for f in pkg_fn:
+            f = bb.cache.Cache.virtualfn2realfn(f)[0]
+            # Get the layername that the file is in
+            layername = self.get_file_layer(f)
+
+            # The DEPENDS
+            deps = self.bbhandler.cooker_data.deps[f]
+            for pn in deps:
+                if pn in self.bbhandler.cooker_data.pkg_pn:
+                    best = bb.providers.findBestProvider(pn,
+                            self.bbhandler.cooker.configuration.data,
+                            self.bbhandler.cooker_data,
+                            self.bbhandler.cooker_data.pkg_pn)
+                    self.check_cross_depends("DEPENDS", layername, f, best[3], show_filenames)
+
+            # The RDPENDS
+            all_rdeps = self.bbhandler.cooker_data.rundeps[f].values()
+            # Remove the duplicated or null one.
+            sorted_rdeps = {}
+            # The all_rdeps is the list in list, so we need two for loops
+            for k1 in all_rdeps:
+                for k2 in k1:
+                    sorted_rdeps[k2] = 1
+            all_rdeps = sorted_rdeps.keys()
+            for rdep in all_rdeps:
+                all_p = bb.providers.getRuntimeProviders(self.bbhandler.cooker_data, rdep)
+                if all_p:
+                    best = bb.providers.filterProvidersRunTime(all_p, rdep,
+                                    self.bbhandler.cooker.configuration.data,
+                                    self.bbhandler.cooker_data)[0][0]
+                    self.check_cross_depends("RDEPENDS", layername, f, best, show_filenames)
+
+            # The inherit class
+            cls_re = re.compile('classes/')
+            if f in self.bbhandler.cooker_data.inherits:
+                inherits = self.bbhandler.cooker_data.inherits[f]
+                for cls in inherits:
+                    # The inherits' format is [classes/cls, /path/to/classes/cls]
+                    # ignore the classes/cls.
+                    if not cls_re.match(cls):
+                        inherit_layername = self.get_file_layer(cls)
+                        if inherit_layername != layername:
+                            if not show_filenames:
+                                f_short = self.remove_layer_prefix(f)
+                                cls = self.remove_layer_prefix(cls)
+                            else:
+                                f_short = f
+                            logger.plain("%s inherits %s" % (f_short, cls))
+
+            # The 'require/include xxx' in the bb file
+            pv_re = re.compile(r"\${PV}")
+            fnfile = open(f, 'r')
+            line = fnfile.readline()
+            while line:
+                m, keyword = self.match_require_include(line)
+                # Found the 'require/include xxxx'
+                if m:
+                    needed_file = m.group(1)
+                    # Replace the ${PV} with the real PV
+                    if pv_re.search(needed_file) and f in self.bbhandler.cooker_data.pkg_pepvpr:
+                        pv = self.bbhandler.cooker_data.pkg_pepvpr[f][1]
+                        needed_file = re.sub(r"\${PV}", pv, needed_file)
+                    self.print_cross_files(bbpath, keyword, layername, f, needed_file, show_filenames)
+                line = fnfile.readline()
+            fnfile.close()
+
+        # The "require/include xxx" in conf/machine/*.conf, .inc and .bbclass
+        conf_re = re.compile(".*/conf/machine/[^\/]*\.conf$")
+        inc_re = re.compile(".*\.inc$")
+        # The "inherit xxx" in .bbclass
+        bbclass_re = re.compile(".*\.bbclass$")
+        for layerdir in self.bblayers:
+            layername = self.get_layer_name(layerdir)
+            for dirpath, dirnames, filenames in os.walk(layerdir):
+                for name in filenames:
+                    f = os.path.join(dirpath, name)
+                    s = conf_re.match(f) or inc_re.match(f) or bbclass_re.match(f)
+                    if s:
+                        ffile = open(f, 'r')
+                        line = ffile.readline()
+                        while line:
+                            m, keyword = self.match_require_include(line)
+                            # Only bbclass has the "inherit xxx" here.
+                            bbclass=""
+                            if not m and f.endswith(".bbclass"):
+                                m, keyword = self.match_inherit(line)
+                                bbclass=".bbclass"
+                            # Find a 'require/include xxxx'
+                            if m:
+                                self.print_cross_files(bbpath, keyword, layername, f, m.group(1) + bbclass, show_filenames)
+                            line = ffile.readline()
+                        ffile.close()
+
+    def print_cross_files(self, bbpath, keyword, layername, f, needed_filename, show_filenames):
+        """Print the depends that crosses a layer boundary"""
+        needed_file = bb.utils.which(bbpath, needed_filename)
+        if needed_file:
+            # Which layer is this file from
+            needed_layername = self.get_file_layer(needed_file)
+            if needed_layername != layername:
+                if not show_filenames:
+                    f = self.remove_layer_prefix(f)
+                    needed_file = self.remove_layer_prefix(needed_file)
+                logger.plain("%s %s %s" %(f, keyword, needed_file))
+    def match_inherit(self, line):
+        """Match the inherit xxx line"""
+        return (self.inherit_re.match(line), "inherits")
+
+    def match_require_include(self, line):
+        """Match the require/include xxx line"""
+        m = self.require_re.match(line)
+        keyword = "requires"
+        if not m:
+            m = self.include_re.match(line)
+            keyword = "includes"
+        return (m, keyword)
+
+    def check_cross_depends(self, keyword, layername, f, needed_file, show_filenames):
+        """Print the DEPENDS/RDEPENDS file that crosses a layer boundary"""
+        best_realfn = bb.cache.Cache.virtualfn2realfn(needed_file)[0]
+        needed_layername = self.get_file_layer(best_realfn)
+        if needed_layername != layername:
+            if not show_filenames:
+                f = self.remove_layer_prefix(f)
+                best_realfn = self.remove_layer_prefix(best_realfn)
+
+            logger.plain("%s %s %s" % (f, keyword, best_realfn))
 
 if __name__ == '__main__':
     sys.exit(main(sys.argv[1:]) or 0)

bitbake/lib/bb/__init__.py

@@ -21,7 +21,7 @@
 # with this program; if not, write to the Free Software Foundation, Inc.,
 # 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
 
-__version__ = "1.17.0"
+__version__ = "1.17.1"
 
 import sys
 if sys.version_info < (2, 6, 0):

bitbake/lib/bb/build.py

@@ -423,13 +423,27 @@ def _exec_task(fn, task, d, quieterr):
 
     return 0
 
-def exec_task(fn, task, d):
+def exec_task(fn, task, d, profile = False):
     try: 
         quieterr = False
         if d.getVarFlag(task, "quieterrors") is not None:
             quieterr = True
 
-        return _exec_task(fn, task, d, quieterr)
+        if profile: 
+            profname = "profile-%s.log" % (os.path.basename(fn) + "-" + task)
+            try:
+                import cProfile as profile
+            except:
+                import profile
+            prof = profile.Profile()
+            ret = profile.Profile.runcall(prof, _exec_task, fn, task, d, quieterr)
+            prof.dump_stats(profname)
+            bb.utils.process_profilelog(profname)
+
+            return ret
+        else:
+            return _exec_task(fn, task, d, quieterr)
+
     except Exception:
         from traceback import format_exc
         if not quieterr:

bitbake/lib/bb/cache.py

@@ -119,7 +119,6 @@ class CoreRecipeInfo(RecipeInfoCommon):
         self.basetaskhashes = self.taskvar('BB_BASEHASH', self.tasks, metadata)
         self.hashfilename = self.getvar('BB_HASHFILENAME', metadata)
 
-        self.file_depends = metadata.getVar('__depends', False)
         self.task_deps = metadata.getVar('_task_deps', False) or {'tasks': [], 'parents': {}}
 
         self.skipped = False
@@ -127,7 +126,6 @@ class CoreRecipeInfo(RecipeInfoCommon):
         self.pv = self.getvar('PV', metadata)
         self.pr = self.getvar('PR', metadata)
         self.defaultpref = self.intvar('DEFAULT_PREFERENCE', metadata)
-        self.broken = self.getvar('BROKEN', metadata)
         self.not_world = self.getvar('EXCLUDE_FROM_WORLD', metadata)
         self.stamp = self.getvar('STAMP', metadata)
         self.stampclean = self.getvar('STAMPCLEAN', metadata)        
@@ -234,7 +232,7 @@ class CoreRecipeInfo(RecipeInfoCommon):
 
         # Collect files we may need for possible world-dep
         # calculations
-        if not self.broken and not self.not_world:
+        if not self.not_world:
             cachedata.possible_world.append(fn)
 
         # create a collection of all targets for sanity checking

bitbake/lib/bb/codeparser.py

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

bitbake/lib/bb/command.py

@@ -174,6 +174,18 @@ class CommandsSync:
         value = str(params[1])
         command.cooker.configuration.data.setVar(varname, value)
 
+    def enableDataTracking(self, command, params):
+        """
+        Enable history tracking for variables
+        """
+        command.cooker.enableDataTracking()
+
+    def disableDataTracking(self, command, params):
+        """
+        Disable history tracking for variables
+        """
+        command.cooker.disableDataTracking()
+
     def initCooker(self, command, params):
         """
         Init the cooker to initial state with nothing parsed
@@ -210,6 +222,12 @@ class CommandsSync:
         package_queue = params[2]
         return command.cooker.generateNewImage(image, base_image, package_queue)
 
+    def setVarFile(self, command, params):
+        var = params[0]
+        val = params[1]
+        default_file = params[2]
+        command.cooker.saveConfigurationVar(var, val, default_file)
+
 class CommandsAsync:
     """
     A class of asynchronous commands

bitbake/lib/bb/compat.py

@@ -239,3 +239,690 @@ class OrderedDict(dict):
     def viewitems(self):
         "od.viewitems() -> a set-like object providing a view on od's items"
         return ItemsView(self)
+
+# Multiprocessing pool code imported from python 2.7.3. Previous versions of 
+# python have issues in this code which hang pool usage
+
+#
+# Module providing the `Pool` class for managing a process pool
+#
+# multiprocessing/pool.py
+#
+# Copyright (c) 2006-2008, R Oudkerk
+# All rights reserved.
+#
+# Redistribution and use in source and binary forms, with or without
+# modification, are permitted provided that the following conditions
+# are met:
+#
+# 1. Redistributions of source code must retain the above copyright
+#    notice, this list of conditions and the following disclaimer.
+# 2. Redistributions in binary form must reproduce the above copyright
+#    notice, this list of conditions and the following disclaimer in the
+#    documentation and/or other materials provided with the distribution.
+# 3. Neither the name of author nor the names of any contributors may be
+#    used to endorse or promote products derived from this software
+#    without specific prior written permission.
+#
+# THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS "AS IS" AND
+# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+# ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+# SUCH DAMAGE.
+#
+import threading
+import Queue
+import itertools
+import collections
+import time
+
+import multiprocessing
+from multiprocessing import Process, cpu_count, TimeoutError, pool
+from multiprocessing.util import Finalize, debug
+
+#
+# Constants representing the state of a pool
+#
+
+RUN = 0
+CLOSE = 1
+TERMINATE = 2
+
+#
+# Miscellaneous
+#
+
+def mapstar(args):
+    return map(*args)
+
+class MaybeEncodingError(Exception):
+    """Wraps possible unpickleable errors, so they can be
+    safely sent through the socket."""
+
+    def __init__(self, exc, value):
+        self.exc = repr(exc)
+        self.value = repr(value)
+        super(MaybeEncodingError, self).__init__(self.exc, self.value)
+
+    def __str__(self):
+        return "Error sending result: '%s'. Reason: '%s'" % (self.value,
+                                                             self.exc)
+
+    def __repr__(self):
+        return "<MaybeEncodingError: %s>" % str(self)
+
+def worker(inqueue, outqueue, initializer=None, initargs=(), maxtasks=None):
+    assert maxtasks is None or (type(maxtasks) == int and maxtasks > 0)
+    put = outqueue.put
+    get = inqueue.get
+    if hasattr(inqueue, '_writer'):
+        inqueue._writer.close()
+        outqueue._reader.close()
+
+    if initializer is not None:
+        initializer(*initargs)
+
+    completed = 0
+    while maxtasks is None or (maxtasks and completed < maxtasks):
+        try:
+            task = get()
+        except (EOFError, IOError):
+            debug('worker got EOFError or IOError -- exiting')
+            break
+
+        if task is None:
+            debug('worker got sentinel -- exiting')
+            break
+
+        job, i, func, args, kwds = task
+        try:
+            result = (True, func(*args, **kwds))
+        except Exception, e:
+            result = (False, e)
+        try:
+            put((job, i, result))
+        except Exception as e:
+            wrapped = MaybeEncodingError(e, result[1])
+            debug("Possible encoding error while sending result: %s" % (
+                wrapped))
+            put((job, i, (False, wrapped)))
+        completed += 1
+    debug('worker exiting after %d tasks' % completed)
+
+
+class Pool(object):
+    '''
+    Class which supports an async version of the `apply()` builtin
+    '''
+    Process = Process
+
+    def __init__(self, processes=None, initializer=None, initargs=(),
+                 maxtasksperchild=None):
+        self._setup_queues()
+        self._taskqueue = Queue.Queue()
+        self._cache = {}
+        self._state = RUN
+        self._maxtasksperchild = maxtasksperchild
+        self._initializer = initializer
+        self._initargs = initargs
+
+        if processes is None:
+            try:
+                processes = cpu_count()
+            except NotImplementedError:
+                processes = 1
+        if processes < 1:
+            raise ValueError("Number of processes must be at least 1")
+
+        if initializer is not None and not hasattr(initializer, '__call__'):
+            raise TypeError('initializer must be a callable')
+
+        self._processes = processes
+        self._pool = []
+        self._repopulate_pool()
+
+        self._worker_handler = threading.Thread(
+            target=Pool._handle_workers,
+            args=(self, )
+            )
+        self._worker_handler.daemon = True
+        self._worker_handler._state = RUN
+        self._worker_handler.start()
+
+
+        self._task_handler = threading.Thread(
+            target=Pool._handle_tasks,
+            args=(self._taskqueue, self._quick_put, self._outqueue, self._pool)
+            )
+        self._task_handler.daemon = True
+        self._task_handler._state = RUN
+        self._task_handler.start()
+
+        self._result_handler = threading.Thread(
+            target=Pool._handle_results,
+            args=(self._outqueue, self._quick_get, self._cache)
+            )
+        self._result_handler.daemon = True
+        self._result_handler._state = RUN
+        self._result_handler.start()
+
+        self._terminate = Finalize(
+            self, self._terminate_pool,
+            args=(self._taskqueue, self._inqueue, self._outqueue, self._pool,
+                  self._worker_handler, self._task_handler,
+                  self._result_handler, self._cache),
+            exitpriority=15
+            )
+
+    def _join_exited_workers(self):
+        """Cleanup after any worker processes which have exited due to reaching
+        their specified lifetime.  Returns True if any workers were cleaned up.
+        """
+        cleaned = False
+        for i in reversed(range(len(self._pool))):
+            worker = self._pool[i]
+            if worker.exitcode is not None:
+                # worker exited
+                debug('cleaning up worker %d' % i)
+                worker.join()
+                cleaned = True
+                del self._pool[i]
+        return cleaned
+
+    def _repopulate_pool(self):
+        """Bring the number of pool processes up to the specified number,
+        for use after reaping workers which have exited.
+        """
+        for i in range(self._processes - len(self._pool)):
+            w = self.Process(target=worker,
+                             args=(self._inqueue, self._outqueue,
+                                   self._initializer,
+                                   self._initargs, self._maxtasksperchild)
+                            )
+            self._pool.append(w)
+            w.name = w.name.replace('Process', 'PoolWorker')
+            w.daemon = True
+            w.start()
+            debug('added worker')
+
+    def _maintain_pool(self):
+        """Clean up any exited workers and start replacements for them.
+        """
+        if self._join_exited_workers():
+            self._repopulate_pool()
+
+    def _setup_queues(self):
+        from multiprocessing.queues import SimpleQueue
+        self._inqueue = SimpleQueue()
+        self._outqueue = SimpleQueue()
+        self._quick_put = self._inqueue._writer.send
+        self._quick_get = self._outqueue._reader.recv
+
+    def apply(self, func, args=(), kwds={}):
+        '''
+        Equivalent of `apply()` builtin
+        '''
+        assert self._state == RUN
+        return self.apply_async(func, args, kwds).get()
+
+    def map(self, func, iterable, chunksize=None):
+        '''
+        Equivalent of `map()` builtin
+        '''
+        assert self._state == RUN
+        return self.map_async(func, iterable, chunksize).get()
+
+    def imap(self, func, iterable, chunksize=1):
+        '''
+        Equivalent of `itertools.imap()` -- can be MUCH slower than `Pool.map()`
+        '''
+        assert self._state == RUN
+        if chunksize == 1:
+            result = IMapIterator(self._cache)
+            self._taskqueue.put((((result._job, i, func, (x,), {})
+                         for i, x in enumerate(iterable)), result._set_length))
+            return result
+        else:
+            assert chunksize > 1
+            task_batches = Pool._get_tasks(func, iterable, chunksize)
+            result = IMapIterator(self._cache)
+            self._taskqueue.put((((result._job, i, mapstar, (x,), {})
+                     for i, x in enumerate(task_batches)), result._set_length))
+            return (item for chunk in result for item in chunk)
+
+    def imap_unordered(self, func, iterable, chunksize=1):
+        '''
+        Like `imap()` method but ordering of results is arbitrary
+        '''
+        assert self._state == RUN
+        if chunksize == 1:
+            result = IMapUnorderedIterator(self._cache)
+            self._taskqueue.put((((result._job, i, func, (x,), {})
+                         for i, x in enumerate(iterable)), result._set_length))
+            return result
+        else:
+            assert chunksize > 1
+            task_batches = Pool._get_tasks(func, iterable, chunksize)
+            result = IMapUnorderedIterator(self._cache)
+            self._taskqueue.put((((result._job, i, mapstar, (x,), {})
+                     for i, x in enumerate(task_batches)), result._set_length))
+            return (item for chunk in result for item in chunk)
+
+    def apply_async(self, func, args=(), kwds={}, callback=None):
+        '''
+        Asynchronous equivalent of `apply()` builtin
+        '''
+        assert self._state == RUN
+        result = ApplyResult(self._cache, callback)
+        self._taskqueue.put(([(result._job, None, func, args, kwds)], None))
+        return result
+
+    def map_async(self, func, iterable, chunksize=None, callback=None):
+        '''
+        Asynchronous equivalent of `map()` builtin
+        '''
+        assert self._state == RUN
+        if not hasattr(iterable, '__len__'):
+            iterable = list(iterable)
+
+        if chunksize is None:
+            chunksize, extra = divmod(len(iterable), len(self._pool) * 4)
+            if extra:
+                chunksize += 1
+        if len(iterable) == 0:
+            chunksize = 0
+
+        task_batches = Pool._get_tasks(func, iterable, chunksize)
+        result = MapResult(self._cache, chunksize, len(iterable), callback)
+        self._taskqueue.put((((result._job, i, mapstar, (x,), {})
+                              for i, x in enumerate(task_batches)), None))
+        return result
+
+    @staticmethod
+    def _handle_workers(pool):
+        thread = threading.current_thread()
+
+        # Keep maintaining workers until the cache gets drained, unless the pool
+        # is terminated.
+        while thread._state == RUN or (pool._cache and thread._state != TERMINATE):
+            pool._maintain_pool()
+            time.sleep(0.1)
+        # send sentinel to stop workers
+        pool._taskqueue.put(None)
+        debug('worker handler exiting')
+
+    @staticmethod
+    def _handle_tasks(taskqueue, put, outqueue, pool):
+        thread = threading.current_thread()
+
+        for taskseq, set_length in iter(taskqueue.get, None):
+            i = -1
+            for i, task in enumerate(taskseq):
+                if thread._state:
+                    debug('task handler found thread._state != RUN')
+                    break
+                try:
+                    put(task)
+                except IOError:
+                    debug('could not put task on queue')
+                    break
+            else:
+                if set_length:
+                    debug('doing set_length()')
+                    set_length(i+1)
+                continue
+            break
+        else:
+            debug('task handler got sentinel')
+
+
+        try:
+            # tell result handler to finish when cache is empty
+            debug('task handler sending sentinel to result handler')
+            outqueue.put(None)
+
+            # tell workers there is no more work
+            debug('task handler sending sentinel to workers')
+            for p in pool:
+                put(None)
+        except IOError:
+            debug('task handler got IOError when sending sentinels')
+
+        debug('task handler exiting')
+
+    @staticmethod
+    def _handle_results(outqueue, get, cache):
+        thread = threading.current_thread()
+
+        while 1:
+            try:
+                task = get()
+            except (IOError, EOFError):
+                debug('result handler got EOFError/IOError -- exiting')
+                return
+
+            if thread._state:
+                assert thread._state == TERMINATE
+                debug('result handler found thread._state=TERMINATE')
+                break
+
+            if task is None:
+                debug('result handler got sentinel')
+                break
+
+            job, i, obj = task
+            try:
+                cache[job]._set(i, obj)
+            except KeyError:
+                pass
+
+        while cache and thread._state != TERMINATE:
+            try:
+                task = get()
+            except (IOError, EOFError):
+                debug('result handler got EOFError/IOError -- exiting')
+                return
+
+            if task is None:
+                debug('result handler ignoring extra sentinel')
+                continue
+            job, i, obj = task
+            try:
+                cache[job]._set(i, obj)
+            except KeyError:
+                pass
+
+        if hasattr(outqueue, '_reader'):
+            debug('ensuring that outqueue is not full')
+            # If we don't make room available in outqueue then
+            # attempts to add the sentinel (None) to outqueue may
+            # block.  There is guaranteed to be no more than 2 sentinels.
+            try:
+                for i in range(10):
+                    if not outqueue._reader.poll():
+                        break
+                    get()
+            except (IOError, EOFError):
+                pass
+
+        debug('result handler exiting: len(cache)=%s, thread._state=%s',
+              len(cache), thread._state)
+
+    @staticmethod
+    def _get_tasks(func, it, size):
+        it = iter(it)
+        while 1:
+            x = tuple(itertools.islice(it, size))
+            if not x:
+                return
+            yield (func, x)
+
+    def __reduce__(self):
+        raise NotImplementedError(
+              'pool objects cannot be passed between processes or pickled'
+              )
+
+    def close(self):
+        debug('closing pool')
+        if self._state == RUN:
+            self._state = CLOSE
+            self._worker_handler._state = CLOSE
+
+    def terminate(self):
+        debug('terminating pool')
+        self._state = TERMINATE
+        self._worker_handler._state = TERMINATE
+        self._terminate()
+
+    def join(self):
+        debug('joining pool')
+        assert self._state in (CLOSE, TERMINATE)
+        self._worker_handler.join()
+        self._task_handler.join()
+        self._result_handler.join()
+        for p in self._pool:
+            p.join()
+
+    @staticmethod
+    def _help_stuff_finish(inqueue, task_handler, size):
+        # task_handler may be blocked trying to put items on inqueue
+        debug('removing tasks from inqueue until task handler finished')
+        inqueue._rlock.acquire()
+        while task_handler.is_alive() and inqueue._reader.poll():
+            inqueue._reader.recv()
+            time.sleep(0)
+
+    @classmethod
+    def _terminate_pool(cls, taskqueue, inqueue, outqueue, pool,
+                        worker_handler, task_handler, result_handler, cache):
+        # this is guaranteed to only be called once
+        debug('finalizing pool')
+
+        worker_handler._state = TERMINATE
+        task_handler._state = TERMINATE
+
+        debug('helping task handler/workers to finish')
+        cls._help_stuff_finish(inqueue, task_handler, len(pool))
+
+        assert result_handler.is_alive() or len(cache) == 0
+
+        result_handler._state = TERMINATE
+        outqueue.put(None)                  # sentinel
+
+        # We must wait for the worker handler to exit before terminating
+        # workers because we don't want workers to be restarted behind our back.
+        debug('joining worker handler')
+        if threading.current_thread() is not worker_handler:
+            worker_handler.join(1e100)
+
+        # Terminate workers which haven't already finished.
+        if pool and hasattr(pool[0], 'terminate'):
+            debug('terminating workers')
+            for p in pool:
+                if p.exitcode is None:
+                    p.terminate()
+
+        debug('joining task handler')
+        if threading.current_thread() is not task_handler:
+            task_handler.join(1e100)
+
+        debug('joining result handler')
+        if threading.current_thread() is not result_handler:
+            result_handler.join(1e100)
+
+        if pool and hasattr(pool[0], 'terminate'):
+            debug('joining pool workers')
+            for p in pool:
+                if p.is_alive():
+                    # worker has not yet exited
+                    debug('cleaning up worker %d' % p.pid)
+                    p.join()
+
+class ApplyResult(object):
+
+    def __init__(self, cache, callback):
+        self._cond = threading.Condition(threading.Lock())
+        self._job = multiprocessing.pool.job_counter.next()
+        self._cache = cache
+        self._ready = False
+        self._callback = callback
+        cache[self._job] = self
+
+    def ready(self):
+        return self._ready
+
+    def successful(self):
+        assert self._ready
+        return self._success
+
+    def wait(self, timeout=None):
+        self._cond.acquire()
+        try:
+            if not self._ready:
+                self._cond.wait(timeout)
+        finally:
+            self._cond.release()
+
+    def get(self, timeout=None):
+        self.wait(timeout)
+        if not self._ready:
+            raise TimeoutError
+        if self._success:
+            return self._value
+        else:
+            raise self._value
+
+    def _set(self, i, obj):
+        self._success, self._value = obj
+        if self._callback and self._success:
+            self._callback(self._value)
+        self._cond.acquire()
+        try:
+            self._ready = True
+            self._cond.notify()
+        finally:
+            self._cond.release()
+        del self._cache[self._job]
+
+#
+# Class whose instances are returned by `Pool.map_async()`
+#
+
+class MapResult(ApplyResult):
+
+    def __init__(self, cache, chunksize, length, callback):
+        ApplyResult.__init__(self, cache, callback)
+        self._success = True
+        self._value = [None] * length
+        self._chunksize = chunksize
+        if chunksize <= 0:
+            self._number_left = 0
+            self._ready = True
+            del cache[self._job]
+        else:
+            self._number_left = length//chunksize + bool(length % chunksize)
+
+    def _set(self, i, success_result):
+        success, result = success_result
+        if success:
+            self._value[i*self._chunksize:(i+1)*self._chunksize] = result
+            self._number_left -= 1
+            if self._number_left == 0:
+                if self._callback:
+                    self._callback(self._value)
+                del self._cache[self._job]
+                self._cond.acquire()
+                try:
+                    self._ready = True
+                    self._cond.notify()
+                finally:
+                    self._cond.release()
+
+        else:
+            self._success = False
+            self._value = result
+            del self._cache[self._job]
+            self._cond.acquire()
+            try:
+                self._ready = True
+                self._cond.notify()
+            finally:
+                self._cond.release()
+
+#
+# Class whose instances are returned by `Pool.imap()`
+#
+
+class IMapIterator(object):
+
+    def __init__(self, cache):
+        self._cond = threading.Condition(threading.Lock())
+        self._job = multiprocessing.pool.job_counter.next()
+        self._cache = cache
+        self._items = collections.deque()
+        self._index = 0
+        self._length = None
+        self._unsorted = {}
+        cache[self._job] = self
+
+    def __iter__(self):
+        return self
+
+    def next(self, timeout=None):
+        self._cond.acquire()
+        try:
+            try:
+                item = self._items.popleft()
+            except IndexError:
+                if self._index == self._length:
+                    raise StopIteration
+                self._cond.wait(timeout)
+                try:
+                    item = self._items.popleft()
+                except IndexError:
+                    if self._index == self._length:
+                        raise StopIteration
+                    raise TimeoutError
+        finally:
+            self._cond.release()
+
+        success, value = item
+        if success:
+            return value
+        raise value
+
+    __next__ = next                    # XXX
+
+    def _set(self, i, obj):
+        self._cond.acquire()
+        try:
+            if self._index == i:
+                self._items.append(obj)
+                self._index += 1
+                while self._index in self._unsorted:
+                    obj = self._unsorted.pop(self._index)
+                    self._items.append(obj)
+                    self._index += 1
+                self._cond.notify()
+            else:
+                self._unsorted[i] = obj
+
+            if self._index == self._length:
+                del self._cache[self._job]
+        finally:
+            self._cond.release()
+
+    def _set_length(self, length):
+        self._cond.acquire()
+        try:
+            self._length = length
+            if self._index == self._length:
+                self._cond.notify()
+                del self._cache[self._job]
+        finally:
+            self._cond.release()
+
+#
+# Class whose instances are returned by `Pool.imap_unordered()`
+#
+
+class IMapUnorderedIterator(IMapIterator):
+
+    def _set(self, i, obj):
+        self._cond.acquire()
+        try:
+            self._items.append(obj)
+            self._index += 1
+            self._cond.notify()
+            if self._index == self._length:
+                del self._cache[self._job]
+        finally:
+            self._cond.release()
+
+

bitbake/lib/bb/cooker.py

@@ -34,7 +34,7 @@ from cStringIO import StringIO
 from contextlib import closing
 from functools import wraps
 from collections import defaultdict
-import bb, bb.exceptions, bb.command
+import bb, bb.exceptions, bb.command, bb.compat
 from bb import utils, data, parse, event, cache, providers, taskdata, runqueue
 import Queue
 import prserv.serv
@@ -185,6 +185,13 @@ class BBCooker:
 
         filtered_keys = bb.utils.approved_variables()
         bb.data.inheritFromOS(self.configuration.data, self.savedenv, filtered_keys)
+        self.configuration.data.setVar("BB_ORIGENV", self.savedenv)
+
+    def enableDataTracking(self):
+        self.configuration.data.enableTracking()
+
+    def disableDataTracking(self):
+        self.configuration.data.disableTracking()
 
     def loadConfigurationData(self):
         self.initConfigurationData()
@@ -201,6 +208,89 @@ class BBCooker:
         if not self.configuration.cmd:
             self.configuration.cmd = self.configuration.data.getVar("BB_DEFAULT_TASK", True) or "build"
 
+    def saveConfigurationVar(self, var, val, default_file):
+
+        replaced = False
+        #do not save if nothing changed
+        if str(val) == self.configuration.data.getVar(var):
+            return
+
+        conf_files = self.configuration.data.varhistory.get_variable_files(var)
+
+        #format the value when it is a list
+        if isinstance(val, list):
+            listval = ""
+            for value in val:
+                listval += "%s   " % value
+            val = listval
+
+        topdir = self.configuration.data.getVar("TOPDIR")
+
+        #comment or replace operations made on var
+        for conf_file in conf_files:
+            if topdir in conf_file:
+                with open(conf_file, 'r') as f:
+                    contents = f.readlines()
+                f.close()
+
+                lines = self.configuration.data.varhistory.get_variable_lines(var, conf_file)
+                for line in lines:
+                    total = ""
+                    i = 0
+                    for c in contents:
+                        total += c
+                        i = i + 1
+                        if i==int(line):
+                            end_index = len(total)
+                    index = total.rfind(var, 0, end_index)
+
+                    begin_line = total.count("\n",0,index)
+                    end_line = int(line)
+
+                    #check if the variable was saved before in the same way
+                    #if true it replace the place where the variable was declared
+                    #else it comments it
+                    if contents[begin_line-1]== "#added by bitbake\n":
+                        contents[begin_line] = "%s = \"%s\"\n" % (var, val)
+                        replaced = True
+                    else:
+                        for ii in range(begin_line, end_line):
+                            contents[ii] = "#" + contents[ii]
+
+                total = ""
+                for c in contents:
+                    total += c
+                with open(conf_file, 'w') as f:
+                    f.write(total)
+                f.close()
+
+        if replaced == False:
+            #remove var from history
+            self.configuration.data.varhistory.del_var_history(var)
+
+            #add var to the end of default_file
+            default_file = self._findConfigFile(default_file)
+
+            with open(default_file, 'r') as f:
+                contents = f.readlines()
+            f.close()
+
+            total = ""
+            for c in contents:
+                total += c
+
+            #add the variable on a single line, to be easy to replace the second time
+            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":set, "file":default_file, "line":total.count("\n")}
+            self.configuration.data.setVar(var, val, **loginfo)
+
     def parseConfiguration(self):
 
         # Set log file verbosity
@@ -887,10 +977,16 @@ class BBCooker:
             bb.fetch.fetcher_init(data)
         bb.codeparser.parser_cache_init(data)
         bb.event.fire(bb.event.ConfigParsed(), data)
-        bb.parse.init_parser(data)
-        data.setVar('BBINCLUDED',bb.parse.get_file_depends(data))
-        self.configuration.data = data
-        self.configuration.data_hash = data.get_hash()
+
+        if data.getVar("BB_INVALIDCONF") is True:
+            data.setVar("BB_INVALIDCONF", False)
+            self.parseConfigurationFiles(self.configuration.prefile,
+                                         self.configuration.postfile)
+        else:
+            bb.parse.init_parser(data)
+            data.setVar('BBINCLUDED',bb.parse.get_file_depends(data))
+            self.configuration.data = data
+            self.configuration.data_hash = data.get_hash()
 
     def handleCollections( self, collections ):
         """Handle collections"""
@@ -1416,25 +1512,7 @@ def server_main(cooker, func, *args):
         ret = profile.Profile.runcall(prof, func, *args)
 
         prof.dump_stats("profile.log")
-
-        # Redirect stdout to capture profile information
-        pout = open('profile.log.processed', 'w')
-        so = sys.stdout.fileno()
-        orig_so = os.dup(sys.stdout.fileno())
-        os.dup2(pout.fileno(), so)
-   
-        import pstats
-        p = pstats.Stats('profile.log')
-        p.sort_stats('time')
-        p.print_stats()
-        p.print_callers()
-        p.sort_stats('cumulative')
-        p.print_stats()
-
-        os.dup2(orig_so, so)
-        pout.flush()
-        pout.close()  
-
+        bb.utils.process_profilelog("profile.log")
         print("Raw profiling information saved to profile.log and processed statistics to profile.log.processed")
 
     else:
@@ -1478,87 +1556,19 @@ class ParsingFailure(Exception):
         self.recipe = recipe
         Exception.__init__(self, realexception, recipe)
 
-class Feeder(multiprocessing.Process):
-    def __init__(self, jobs, to_parsers, quit):
-        self.quit = quit
-        self.jobs = jobs
-        self.to_parsers = to_parsers
-        multiprocessing.Process.__init__(self)
-
-    def run(self):
-        while True:
-            try:
-                quit = self.quit.get_nowait()
-            except Queue.Empty:
-                pass
-            else:
-                if quit == 'cancel':
-                    self.to_parsers.cancel_join_thread()
-                break
-
-            try:
-                job = self.jobs.pop()
-            except IndexError:
-                break
-
-            try:
-                self.to_parsers.put(job, timeout=0.5)
-            except Queue.Full:
-                self.jobs.insert(0, job)
-                continue
-
-class Parser(multiprocessing.Process):
-    def __init__(self, jobs, results, quit, init):
-        self.jobs = jobs
-        self.results = results
-        self.quit = quit
-        self.init = init
-        multiprocessing.Process.__init__(self)
-
-    def run(self):
-        if self.init:
-            self.init()
-
-        pending = []
-        while True:
-            try:
-                self.quit.get_nowait()
-            except Queue.Empty:
-                pass
-            else:
-                self.results.cancel_join_thread()
-                break
-
-            if pending:
-                result = pending.pop()
-            else:
-                try:
-                    job = self.jobs.get(timeout=0.25)
-                except Queue.Empty:
-                    continue
-
-                if job is None:
-                    break
-                result = self.parse(*job)
-
-            try:
-                self.results.put(result, timeout=0.25)
-            except Queue.Full:
-                pending.append(result)
-
-    def parse(self, filename, appends, caches_array):
-        try:
-            return True, bb.cache.Cache.parse(filename, appends, self.cfg, caches_array)
-        except Exception as exc:
-            tb = sys.exc_info()[2]
-            exc.recipe = filename
-            exc.traceback = list(bb.exceptions.extract_traceback(tb, context=3))
-            return True, exc
-        # Need to turn BaseExceptions into Exceptions here so we gracefully shutdown
-        # and for example a worker thread doesn't just exit on its own in response to
-        # a SystemExit event for example.
-        except BaseException as exc:
-            return True, ParsingFailure(exc, filename)
+def parse_file((filename, appends, caches_array)):
+    try:
+        return True, bb.cache.Cache.parse(filename, appends, parse_file.cfg, caches_array)
+    except Exception as exc:
+        tb = sys.exc_info()[2]
+        exc.recipe = filename
+        exc.traceback = list(bb.exceptions.extract_traceback(tb, context=3))
+        return True, exc
+    # Need to turn BaseExceptions into Exceptions here so we gracefully shutdown
+    # and for example a worker thread doesn't just exit on its own in response to
+    # a SystemExit event for example.
+    except BaseException as exc:
+        return True, ParsingFailure(exc, filename)
 
 class CookerParser(object):
     def __init__(self, cooker, filelist, masked):
@@ -1592,32 +1602,25 @@ class CookerParser(object):
                 self.fromcache.append((filename, appends))
         self.toparse = self.total - len(self.fromcache)
         self.progress_chunk = max(self.toparse / 100, 1)
+        self.chunk = int(self.cfgdata.getVar("BB_PARSE_CHUNK", True) or 1)
 
         self.start()
         self.haveshutdown = False
 
     def start(self):
         self.results = self.load_cached()
-        self.processes = []
         if self.toparse:
+            def process_init():
+                parse_file.cfg = self.cfgdata
+                multiprocessing.util.Finalize(None, bb.codeparser.parser_cache_save, args=(parse_file.cfg,), exitpriority=1)
+                multiprocessing.util.Finalize(None, bb.fetch.fetcher_parse_save, args=(parse_file.cfg,), exitpriority=1)
+
             bb.event.fire(bb.event.ParseStarted(self.toparse), self.cfgdata)
-            def init():
-                Parser.cfg = self.cfgdata
-                multiprocessing.util.Finalize(None, bb.codeparser.parser_cache_save, args=(self.cfgdata,), exitpriority=1)
-                multiprocessing.util.Finalize(None, bb.fetch.fetcher_parse_save, args=(self.cfgdata,), exitpriority=1)
 
-            self.feeder_quit = multiprocessing.Queue(maxsize=1)
-            self.parser_quit = multiprocessing.Queue(maxsize=self.num_processes)
-            self.jobs = multiprocessing.Queue(maxsize=self.num_processes)
-            self.result_queue = multiprocessing.Queue()
-            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.start()
-                self.processes.append(parser)
-
-            self.results = itertools.chain(self.results, self.parse_generator())
+            self.pool = bb.compat.Pool(self.num_processes, process_init)
+            parsed = self.pool.imap_unordered(parse_file, self.willparse, self.chunk)
+            self.pool.close()
+            self.results = itertools.chain(self.results, parsed)
 
     def shutdown(self, clean=True, force=False):
         if not self.toparse:
@@ -1633,25 +1636,9 @@ class CookerParser(object):
                                             self.total)
 
             bb.event.fire(event, self.cfgdata)
-            self.feeder_quit.put(None)
-            for process in self.processes:
-                self.jobs.put(None)
         else:
-            self.feeder_quit.put('cancel')
-
-            self.parser_quit.cancel_join_thread()
-            for process in self.processes:
-                self.parser_quit.put(None)
-
-            self.jobs.cancel_join_thread()
-
-        for process in self.processes:
-            if force:
-                process.join(.1)
-                process.terminate()
-            else:
-                process.join()
-        self.feeder.join()
+            self.pool.terminate()
+        self.pool.join()
 
         sync = threading.Thread(target=self.bb_cache.sync)
         sync.start()
@@ -1664,22 +1651,6 @@ class CookerParser(object):
             cached, infos = self.bb_cache.load(filename, appends, self.cfgdata)
             yield not cached, infos
 
-    def parse_generator(self):
-        while True:
-            if self.parsed >= self.toparse:
-                break
-
-            try:
-                result = self.result_queue.get(timeout=0.25)
-            except Queue.Empty:
-                pass
-            else:
-                value = result[1]
-                if isinstance(value, BaseException):
-                    raise value
-                else:
-                    yield result
-
     def parse_next(self):
         result = []
         parsed = None

bitbake/lib/bb/data_smart.py

@@ -259,6 +259,27 @@ class VariableHistory(object):
             o.write("#\n# $%s\n#   [no history recorded]\n#\n" % var)
             o.write('#   "%s"\n' % (commentVal))
 
+    def get_variable_files(self, var):
+        """Get the files where operations are made on a variable"""
+        var_history = self.variable(var)
+        files = []
+        for event in var_history:
+            files.append(event['file'])
+        return files
+
+    def get_variable_lines(self, var, f):
+        """Get the line where a operation is made on a variable in file f"""
+        var_history = self.variable(var)
+        lines = []
+        for event in var_history:
+            if f== event['file']:
+                line = event['line']
+                lines.append(line)
+        return lines
+
+    def del_var_history(self, var):
+        if var in self.variables:
+            self.variables[var] = []
 
 class DataSmart(MutableMapping):
     def __init__(self, special = COWDictBase.copy(), seen = COWDictBase.copy() ):
@@ -429,6 +450,7 @@ class DataSmart(MutableMapping):
 
 
     def setVar(self, var, value, **loginfo):
+        #print("var=" + str(var) + "  val=" + str(value))
         if 'op' not in loginfo:
             loginfo['op'] = "set"
         self.expand_cache = {}

bitbake/lib/bb/fetch2/__init__.py

@@ -30,6 +30,10 @@ from __future__ import print_function
 import os, re
 import logging
 import urllib
+import urlparse
+if 'git' not in urlparse.uses_netloc:
+    urlparse.uses_netloc.append('git')
+from urlparse import urlparse
 import operator
 import bb.persist_data, bb.utils
 import bb.checksum
@@ -120,6 +124,199 @@ class NonLocalMethod(Exception):
     def __init__(self):
         Exception.__init__(self)
 
+
+class URI(object):
+    """
+    A class representing a generic URI, with methods for
+    accessing the URI components, and stringifies to the
+    URI.
+
+    It is constructed by calling it with a URI, or setting
+    the attributes manually:
+
+     uri = URI("http://example.com/")
+
+     uri = URI()
+     uri.scheme = 'http'
+     uri.hostname = 'example.com'
+     uri.path = '/'
+
+    It has the following attributes:
+
+      * scheme (read/write)
+      * userinfo (authentication information) (read/write)
+        * username (read/write)
+        * password (read/write)
+
+        Note, password is deprecated as of RFC 3986.
+
+      * hostname (read/write)
+      * port (read/write)
+      * hostport (read only)
+        "hostname:port", if both are set, otherwise just "hostname"
+      * path (read/write)
+      * path_quoted (read/write)
+        A URI quoted version of path
+      * params (dict) (read/write)
+      * relative (bool) (read only)
+        True if this is a "relative URI", (e.g. file:foo.diff)
+
+    It stringifies to the URI itself.
+
+    Some notes about relative URIs: while it's specified that
+    a URI beginning with <scheme>:// should either be directly
+    followed by a hostname or a /, the old URI handling of the
+    fetch2 library did not comform to this. Therefore, this URI
+    class has some kludges to make sure that URIs are parsed in
+    a way comforming to bitbake's current usage. This URI class
+    supports the following:
+
+     file:relative/path.diff (IETF compliant)
+     git:relative/path.git (IETF compliant)
+     git:///absolute/path.git (IETF compliant)
+     file:///absolute/path.diff (IETF compliant)
+
+     file://relative/path.diff (not IETF compliant)
+
+    But it does not support the following:
+
+     file://hostname/absolute/path.diff (would be IETF compliant)
+
+    Note that the last case only applies to a list of
+    "whitelisted" schemes (currently only file://), that requires
+    its URIs to not have a network location.
+    """
+
+    _relative_schemes = ['file', 'git']
+    _netloc_forbidden = ['file']
+
+    def __init__(self, uri=None):
+        self.scheme = ''
+        self.userinfo = ''
+        self.hostname = ''
+        self.port = None
+        self._path = ''
+        self.params = {}
+        self.relative = False
+
+        if not uri:
+            return
+
+        urlp = urlparse(uri)
+        self.scheme = urlp.scheme
+
+        # Convert URI to be relative
+        if urlp.scheme in self._netloc_forbidden:
+            uri = re.sub("(?<=:)//(?!/)", "", uri, 1)
+            urlp = urlparse(uri)
+
+        # Identify if the URI is relative or not
+        if urlp.scheme in self._relative_schemes and \
+           re.compile("^\w+:(?!//)").match(uri):
+            self.relative = True
+
+        if not self.relative:
+            self.hostname = urlp.hostname or ''
+            self.port = urlp.port
+
+            self.userinfo += urlp.username or ''
+
+            if urlp.password:
+                self.userinfo += ':%s' % urlp.password
+
+        # Do support params even for URI schemes that Python's
+        # urlparse doesn't support params for.
+        path = ''
+        param_str = ''
+        if not urlp.params:
+            path, param_str = (list(urlp.path.split(";", 1)) + [None])[:2]
+        else:
+            path = urlp.path
+            param_str = urlp.params
+
+        self.path = urllib.unquote(path)
+
+        if param_str:
+            self.params = self._param_dict(param_str)
+
+    def __str__(self):
+        userinfo = self.userinfo
+        if userinfo:
+            userinfo += '@'
+
+        return "%s:%s%s%s%s%s" % (
+            self.scheme,
+            '' if self.relative else '//',
+            userinfo,
+            self.hostport,
+            self.path_quoted,
+            self._param_str)
+
+    @property
+    def _param_str(self):
+        ret = ''
+        for key, val in self.params.items():
+            ret += ";%s=%s" % (key, val)
+        return ret
+
+    def _param_dict(self, param_str):
+        parm = {}
+
+        for keyval in param_str.split(";"):
+            key, val = keyval.split("=", 1)
+            parm[key] = val
+
+        return parm
+
+    @property
+    def hostport(self):
+        if not self.port:
+            return self.hostname
+        return "%s:%d" % (self.hostname, self.port)
+
+    @property
+    def path_quoted(self):
+        return urllib.quote(self.path)
+
+    @path_quoted.setter
+    def path_quoted(self, path):
+        self.path = urllib.unquote(path)
+
+    @property
+    def path(self):
+        return self._path
+
+    @path.setter
+    def path(self, path):
+        self._path = path
+
+        if re.compile("^/").match(path):
+            self.relative = False
+        else:
+            self.relative = True
+
+    @property
+    def username(self):
+        if self.userinfo:
+            return (self.userinfo.split(":", 1))[0]
+        return ''
+
+    @username.setter
+    def username(self, username):
+        self.userinfo = username
+        if self.password:
+            self.userinfo += ":%s" % self.password
+
+    @property
+    def password(self):
+        if self.userinfo and ":" in self.userinfo:
+            return (self.userinfo.split(":", 1))[1]
+        return ''
+
+    @password.setter
+    def password(self, password):
+        self.userinfo = "%s:%s" % (self.username, password)
+
 def decodeurl(url):
     """Decodes an URL into the tokens (scheme, network location, path,
     user, password, parameters).
@@ -214,6 +411,8 @@ def uri_replace(ud, uri_find, uri_replace, replacements, d):
                         return None
             # Overwrite any specified replacement parameters
             for k in uri_replace_decoded[loc]:
+                for l in replacements:
+                    uri_replace_decoded[loc][k] = uri_replace_decoded[loc][k].replace(l, replacements[l])
                 result_decoded[loc][k] = uri_replace_decoded[loc][k]
         elif (re.match(regexp, uri_decoded[loc])):
             if not uri_replace_decoded[loc]:
@@ -458,11 +657,16 @@ def runfetchcmd(cmd, d, quiet = False, cleanup = []):
     # rather than host provided
     # Also include some other variables.
     # FIXME: Should really include all export varaiables?
-    exportvars = ['PATH', 'GIT_PROXY_COMMAND', 'GIT_PROXY_HOST',
-                  'GIT_PROXY_PORT', 'GIT_CONFIG', 'http_proxy', 'ftp_proxy',
-                  'https_proxy', 'no_proxy', 'ALL_PROXY', 'all_proxy',
-                  'SSH_AUTH_SOCK', 'SSH_AGENT_PID', 'HOME',
-                  'GIT_PROXY_IGNORE', 'SOCKS5_USER', 'SOCKS5_PASSWD']
+    exportvars = ['HOME', 'PATH',
+                  'HTTP_PROXY', 'http_proxy',
+                  'HTTPS_PROXY', 'https_proxy',
+                  'FTP_PROXY', 'ftp_proxy',
+                  'FTPS_PROXY', 'ftps_proxy',
+                  'NO_PROXY', 'no_proxy',
+                  'ALL_PROXY', 'all_proxy',
+                  'GIT_PROXY_COMMAND',
+                  'SSH_AUTH_SOCK', 'SSH_AGENT_PID',
+                  'SOCKS5_USER', 'SOCKS5_PASSWD']
 
     for var in exportvars:
         val = d.getVar(var, True)
@@ -577,6 +781,7 @@ def try_mirror_url(newuri, origud, ud, ld, check = False):
         dldir = ld.getVar("DL_DIR", True)
         if origud.mirrortarball and os.path.basename(ud.localpath) == os.path.basename(origud.mirrortarball) \
                 and os.path.basename(ud.localpath) != os.path.basename(origud.localpath):
+            bb.utils.mkdirhier(os.path.dirname(ud.donestamp))
             open(ud.donestamp, 'w').close()
             dest = os.path.join(dldir, os.path.basename(ud.localpath))
             if not os.path.exists(dest):
@@ -650,11 +855,14 @@ def srcrev_internal_helper(ud, d, name):
         if not rev:
             rev = d.getVar("SRCREV_%s" % name, True)
     if not rev:
-       rev = d.getVar("SRCREV_pn-%s" % pn, True)
+        rev = d.getVar("SRCREV_pn-%s" % pn, True)
     if not rev:
         rev = d.getVar("SRCREV", True)
     if rev == "INVALID":
-        raise FetchError("Please set SRCREV to a valid value", ud.url)
+        var = "SRCREV_pn-%s" % pn
+        if name != '':
+            var = "SRCREV_%s_pn-%s" % (name, pn)
+        raise FetchError("Please set %s to a valid value" % var, ud.url)
     if rev == "AUTOINC":
         rev = ud.method.latest_revision(ud.url, ud, d, name)
 
@@ -746,6 +954,7 @@ class FetchData(object):
         self.lockfile = None
         self.mirrortarball = None
         self.basename = None
+        self.basepath = None
         (self.type, self.host, self.path, self.user, self.pswd, self.parm) = decodeurl(data.expand(url, d))
         self.date = self.getSRCDate(d)
         self.url = url
@@ -802,8 +1011,14 @@ class FetchData(object):
         elif self.localfile:
             self.localpath = self.method.localpath(self.url, self, d)
 
-        # Note: These files should always be in DL_DIR whereas localpath may not be.
-        basepath = d.expand("${DL_DIR}/%s" % os.path.basename(self.localpath or self.basename))
+        dldir = d.getVar("DL_DIR", True)
+        # Note: .done and .lock files should always be in DL_DIR whereas localpath may not be.
+        if self.localpath and self.localpath.startswith(dldir):
+            basepath = self.localpath
+        elif self.localpath:
+            basepath = dldir + os.sep + os.path.basename(self.localpath)
+        else:
+            basepath = dldir + os.sep + (self.basepath or self.basename)
         self.donestamp = basepath + '.done'
         self.lockfile = basepath + '.lock'
 
@@ -1287,6 +1502,7 @@ from . import svn
 from . import wget
 from . import svk
 from . import ssh
+from . import sftp
 from . import perforce
 from . import bzr
 from . import hg
@@ -1300,6 +1516,7 @@ methods.append(git.Git())
 methods.append(cvs.Cvs())
 methods.append(svk.Svk())
 methods.append(ssh.SSH())
+methods.append(sftp.SFTP())
 methods.append(perforce.Perforce())
 methods.append(bzr.Bzr())
 methods.append(hg.Hg())

bitbake/lib/bb/fetch2/sftp.py

@@ -0,0 +1,129 @@
+# ex:ts=4:sw=4:sts=4:et
+# -*- tab-width: 4; c-basic-offset: 4; indent-tabs-mode: nil -*-
+"""
+BitBake SFTP Fetch implementation
+
+Class for fetching files via SFTP. It tries to adhere to the (now
+expired) IETF Internet Draft for "Uniform Resource Identifier (URI)
+Scheme for Secure File Transfer Protocol (SFTP) and Secure Shell
+(SSH)" (SECSH URI).
+
+It uses SFTP (as to adhere to the SECSH URI specification). It only
+supports key based authentication, not password. This class, unlike
+the SSH fetcher, does not support fetching a directory tree from the
+remote.
+
+  http://tools.ietf.org/html/draft-ietf-secsh-scp-sftp-ssh-uri-04
+  https://www.iana.org/assignments/uri-schemes/prov/sftp
+  https://tools.ietf.org/html/draft-ietf-secsh-filexfer-13
+
+Please note that '/' is used as host path seperator, and not ":"
+as you may be used to from the scp/sftp commands. You can use a
+~ (tilde) to specify a path relative to your home directory.
+(The /~user/ syntax, for specyfing a path relative to another
+user's home directory is not supported.) Note that the tilde must
+still follow the host path seperator ("/"). See exampels below.
+
+Example SRC_URIs:
+
+SRC_URI = "sftp://host.example.com/dir/path.file.txt"
+
+A path relative to your home directory.
+
+SRC_URI = "sftp://host.example.com/~/dir/path.file.txt"
+
+You can also specify a username (specyfing password in the
+URI is not supported, use SSH keys to authenticate):
+
+SRC_URI = "sftp://user@host.example.com/dir/path.file.txt"
+
+"""
+
+# Copyright (C) 2013, Olof Johansson <olof.johansson@axis.com>
+#
+# Based in part on bb.fetch2.wget:
+#    Copyright (C) 2003, 2004  Chris Larson
+#
+# 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.
+#
+# Based on functions from the base bb module, Copyright 2003 Holger Schurig
+
+import os
+import bb
+import urllib
+import commands
+from bb import data
+from bb.fetch2 import URI
+from bb.fetch2 import FetchMethod
+from bb.fetch2 import runfetchcmd
+
+
+class SFTP(FetchMethod):
+    """Class to fetch urls via 'sftp'"""
+
+    def supports(self, url, ud, d):
+        """
+        Check to see if a given url can be fetched with sftp.
+        """
+        return ud.type in ['sftp']
+
+    def recommends_checksum(self, urldata):
+        return True
+
+    def urldata_init(self, ud, d):
+        if 'protocol' in ud.parm and ud.parm['protocol'] == 'git':
+            raise bb.fetch2.ParameterError(
+                "Invalid protocol - if you wish to fetch from a " +
+                "git repository using ssh, you need to use the " +
+                "git:// prefix with protocol=ssh", ud.url)
+
+        if 'downloadfilename' in ud.parm:
+            ud.basename = ud.parm['downloadfilename']
+        else:
+            ud.basename = os.path.basename(ud.path)
+
+        ud.localfile = data.expand(urllib.unquote(ud.basename), d)
+
+    def download(self, uri, ud, d):
+        """Fetch urls"""
+
+        urlo = URI(uri)
+        basecmd = 'sftp -oPasswordAuthentication=no'
+        port = ''
+        if urlo.port:
+            port = '-P %d' % urlo.port
+            urlo.port = None
+
+        dldir = data.getVar('DL_DIR', d, True)
+        lpath = os.path.join(dldir, ud.localfile)
+
+        user = ''
+        if urlo.userinfo:
+            user = urlo.userinfo + '@'
+
+        path = urlo.path
+
+        # Supoprt URIs relative to the user's home directory, with
+        # the tilde syntax. (E.g. <sftp://example.com/~/foo.diff>).
+        if path[:3] == '/~/':
+            path = path[3:]
+
+        remote = '%s%s:%s' % (user, urlo.hostname, path)
+
+        cmd = '%s %s %s %s' % (basecmd, port, commands.mkarg(remote),
+                               commands.mkarg(lpath))
+
+        bb.fetch2.check_network_access(d, cmd, uri)
+        runfetchcmd(cmd, d)
+        return True

bitbake/lib/bb/fetch2/ssh.py

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

bitbake/lib/bb/fetch2/wget.py

@@ -32,8 +32,6 @@ import urllib
 from   bb import data
 from   bb.fetch2 import FetchMethod
 from   bb.fetch2 import FetchError
-from   bb.fetch2 import encodeurl
-from   bb.fetch2 import decodeurl
 from   bb.fetch2 import logger
 from   bb.fetch2 import runfetchcmd
 
@@ -65,8 +63,10 @@ class Wget(FetchMethod):
 
         basecmd = d.getVar("FETCHCMD_wget", True) or "/usr/bin/env wget -t 2 -T 30 -nv --passive-ftp --no-check-certificate"
 
-        if 'downloadfilename' in ud.parm:
-            basecmd += " -O ${DL_DIR}/" + ud.localfile
+        if not checkonly and 'downloadfilename' in ud.parm:
+            dldir = d.getVar("DL_DIR", True)
+            bb.utils.mkdirhier(os.path.dirname(dldir + os.sep + ud.localfile))
+            basecmd += " -O " + dldir + os.sep + ud.localfile
 
         if checkonly:
             fetchcmd = d.getVar("CHECKCOMMAND_wget", True) or d.expand(basecmd + " --spider '${URI}'")
@@ -77,9 +77,6 @@ class Wget(FetchMethod):
             fetchcmd = d.getVar("FETCHCOMMAND_wget", True) or d.expand(basecmd + " -P ${DL_DIR} '${URI}'")
 
         uri = uri.split(";")[0]
-        uri_decoded = list(decodeurl(uri))
-        uri_type = uri_decoded[0]
-        uri_host = uri_decoded[1]
 
         fetchcmd = fetchcmd.replace("${URI}", uri.split(";")[0])
         fetchcmd = fetchcmd.replace("${FILE}", ud.basename)

bitbake/lib/bb/monitordisk.py

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

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

@@ -29,7 +29,30 @@ import logging
 import bb.utils
 from bb.parse import ParseError, resolve_file, ast, logger
 
-__config_regexp__  = re.compile( r"(?P<exp>export\s*)?(?P<var>[a-zA-Z0-9\-~_+.${}/]+)(\[(?P<flag>[a-zA-Z0-9\-_+.]+)\])?\s*((?P<colon>:=)|(?P<lazyques>\?\?=)|(?P<ques>\?=)|(?P<append>\+=)|(?P<prepend>=\+)|(?P<predot>=\.)|(?P<postdot>\.=)|=)\s*(?!'[^']*'[^']*'$)(?!\"[^\"]*\"[^\"]*\"$)(?P<apo>['\"])(?P<value>.*)(?P=apo)$")
+__config_regexp__  = re.compile( r"""
+    ^
+    (?P<exp>export\s*)?
+    (?P<var>[a-zA-Z0-9\-~_+.${}/]+?)
+    (\[(?P<flag>[a-zA-Z0-9\-_+.]+)\])?
+
+    \s* (
+        (?P<colon>:=) |
+        (?P<lazyques>\?\?=) |
+        (?P<ques>\?=) |
+        (?P<append>\+=) |
+        (?P<prepend>=\+) |
+        (?P<predot>=\.) |
+        (?P<postdot>\.=) |
+        =
+    ) \s*
+
+    (?!'[^']*'[^']*'$)
+    (?!\"[^\"]*\"[^\"]*\"$)
+    (?P<apo>['\"])
+    (?P<value>.*)
+    (?P=apo)
+    $
+    """, re.X)
 __include_regexp__ = re.compile( r"include\s+(.+)" )
 __require_regexp__ = re.compile( r"require\s+(.+)" )
 __export_regexp__ = re.compile( r"export\s+([a-zA-Z0-9\-_+.${}/]+)$" )

bitbake/lib/bb/runqueue.py

@@ -1149,7 +1149,8 @@ class RunQueueExecute:
                 os._exit(1)
             try:
                 if not self.cooker.configuration.dry_run:
-                    ret = bb.build.exec_task(fn, taskname, the_data)
+                    profile = self.cooker.configuration.profile
+                    ret = bb.build.exec_task(fn, taskname, the_data, profile)
                 os._exit(ret)
             except:
                 os._exit(1)

bitbake/lib/bb/server/process.py

@@ -266,5 +266,5 @@ class BitBakeServer(object):
         return self.connection
 
     def launchUI(self, uifunc, *args):
-        return bb.cooker.server_main(self.cooker, uifunc, *args)
+        return uifunc(*args)
 

bitbake/lib/bb/siggen.py

@@ -98,6 +98,7 @@ class SignatureGeneratorBasic(SignatureGenerator):
                 bb.error("Task %s from %s seems to be empty?!" % (task, fn))
                 data = ''
 
+            gendeps[task] -= self.basewhitelist
             newdeps = gendeps[task]
             seen = set()
             while newdeps:
@@ -107,12 +108,12 @@ class SignatureGeneratorBasic(SignatureGenerator):
                 for dep in nextdeps:
                     if dep in self.basewhitelist:
                         continue
+                    gendeps[dep] -= self.basewhitelist
                     newdeps |= gendeps[dep]
                 newdeps -= seen
 
-            alldeps = seen - self.basewhitelist
-
-            for dep in sorted(alldeps):
+            alldeps = sorted(seen)
+            for dep in alldeps:
                 data = data + dep
                 if dep in lookupcache:
                     var = lookupcache[dep]
@@ -126,7 +127,7 @@ class SignatureGeneratorBasic(SignatureGenerator):
                 if var:
                     data = data + str(var)
             self.basehash[fn + "." + task] = hashlib.md5(data).hexdigest()
-            taskdeps[task] = sorted(alldeps)
+            taskdeps[task] = alldeps
 
         self.taskdeps[fn] = taskdeps
         self.gendeps[fn] = gendeps

bitbake/lib/bb/tests/codeparser.py

@@ -1,3 +1,5 @@
+# ex:ts=4:sw=4:sts=4:et
+# -*- tab-width: 4; c-basic-offset: 4; indent-tabs-mode: nil -*-
 #
 # BitBake Test for codeparser.py
 #
@@ -24,6 +26,9 @@ import bb
 
 logger = logging.getLogger('BitBake.TestCodeParser')
 
+# bb.data references bb.parse but can't directly import due to circular dependencies.
+# Hack around it for now :( 
+import bb.parse
 import bb.data
 
 class ReferenceTest(unittest.TestCase):

bitbake/lib/bb/tests/cow.py

@@ -1,3 +1,5 @@
+# ex:ts=4:sw=4:sts=4:et
+# -*- tab-width: 4; c-basic-offset: 4; indent-tabs-mode: nil -*-
 #
 # BitBake Tests for Copy-on-Write (cow.py)
 #

bitbake/lib/bb/tests/data.py

@@ -1,3 +1,5 @@
+# ex:ts=4:sw=4:sts=4:et
+# -*- tab-width: 4; c-basic-offset: 4; indent-tabs-mode: nil -*-
 #
 # BitBake Tests for the Data Store (data.py/data_smart.py)
 #

bitbake/lib/bb/tests/fetch.py

@@ -1,3 +1,5 @@
+# ex:ts=4:sw=4:sts=4:et
+# -*- tab-width: 4; c-basic-offset: 4; indent-tabs-mode: nil -*-
 #
 # BitBake Tests for the Fetcher (fetch2/)
 #
@@ -21,8 +23,234 @@ import unittest
 import tempfile
 import subprocess
 import os
+from bb.fetch2 import URI
 import bb
 
+class URITest(unittest.TestCase):
+    test_uris = {
+        "http://www.google.com/index.html" : {
+            'uri': 'http://www.google.com/index.html',
+            'scheme': 'http',
+            'hostname': 'www.google.com',
+            'port': None,
+            'hostport': 'www.google.com',
+            'path': '/index.html',
+            'userinfo': '',
+            'username': '',
+            'password': '',
+            'params': {},
+            'relative': False
+        },
+        "http://www.google.com/index.html;param1=value1" : {
+            'uri': 'http://www.google.com/index.html;param1=value1',
+            'scheme': 'http',
+            'hostname': 'www.google.com',
+            'port': None,
+            'hostport': 'www.google.com',
+            'path': '/index.html',
+            'userinfo': '',
+            'username': '',
+            'password': '',
+            'params': {
+                'param1': 'value1'
+            },
+            'relative': False
+        },
+        "http://www.example.com:8080/index.html" : {
+            'uri': 'http://www.example.com:8080/index.html',
+            'scheme': 'http',
+            'hostname': 'www.example.com',
+            'port': 8080,
+            'hostport': 'www.example.com:8080',
+            'path': '/index.html',
+            'userinfo': '',
+            'username': '',
+            'password': '',
+            'params': {},
+            'relative': False
+        },
+        "cvs://anoncvs@cvs.handhelds.org/cvs;module=familiar/dist/ipkg" : {
+            'uri': 'cvs://anoncvs@cvs.handhelds.org/cvs;module=familiar/dist/ipkg',
+            'scheme': 'cvs',
+            'hostname': 'cvs.handhelds.org',
+            'port': None,
+            'hostport': 'cvs.handhelds.org',
+            'path': '/cvs',
+            'userinfo': 'anoncvs',
+            'username': 'anoncvs',
+            'password': '',
+            'params': {
+                'module': 'familiar/dist/ipkg'
+            },
+            'relative': False
+        },
+        "cvs://anoncvs:anonymous@cvs.handhelds.org/cvs;tag=V0-99-81;module=familiar/dist/ipkg": {
+            'uri': 'cvs://anoncvs:anonymous@cvs.handhelds.org/cvs;tag=V0-99-81;module=familiar/dist/ipkg',
+            'scheme': 'cvs',
+            'hostname': 'cvs.handhelds.org',
+            'port': None,
+            'hostport': 'cvs.handhelds.org',
+            'path': '/cvs',
+            'userinfo': 'anoncvs:anonymous',
+            'username': 'anoncvs',
+            'password': 'anonymous',
+            'params': {
+                'tag': 'V0-99-81',
+                'module': 'familiar/dist/ipkg'
+            },
+            'relative': False
+        },
+        "file://example.diff": { # NOTE: Not RFC compliant!
+            'uri': 'file:example.diff',
+            'scheme': 'file',
+            'hostname': '',
+            'port': None,
+            'hostport': '',
+            'path': 'example.diff',
+            'userinfo': '',
+            'username': '',
+            'password': '',
+            'params': {},
+            'relative': True
+        },
+        "file:example.diff": { # NOTE: RFC compliant version of the former
+            'uri': 'file:example.diff',
+            'scheme': 'file',
+            'hostname': '',
+            'port': None,
+            'hostport': '',
+            'path': 'example.diff',
+            'userinfo': '',
+            'userinfo': '',
+            'username': '',
+            'password': '',
+            'params': {},
+            'relative': True
+        },
+        "file:///tmp/example.diff": {
+            'uri': 'file:///tmp/example.diff',
+            'scheme': 'file',
+            'hostname': '',
+            'port': None,
+            'hostport': '',
+            'path': '/tmp/example.diff',
+            'userinfo': '',
+            'userinfo': '',
+            'username': '',
+            'password': '',
+            'params': {},
+            'relative': False
+        },
+        "git:///path/example.git": {
+            'uri': 'git:///path/example.git',
+            'scheme': 'git',
+            'hostname': '',
+            'port': None,
+            'hostport': '',
+            'path': '/path/example.git',
+            'userinfo': '',
+            'userinfo': '',
+            'username': '',
+            'password': '',
+            'params': {},
+            'relative': False
+        },
+        "git:path/example.git": {
+            'uri': 'git:path/example.git',
+            'scheme': 'git',
+            'hostname': '',
+            'port': None,
+            'hostport': '',
+            'path': 'path/example.git',
+            'userinfo': '',
+            'userinfo': '',
+            'username': '',
+            'password': '',
+            'params': {},
+            'relative': True
+        },
+        "git://example.net/path/example.git": {
+            'uri': 'git://example.net/path/example.git',
+            'scheme': 'git',
+            'hostname': 'example.net',
+            'port': None,
+            'hostport': 'example.net',
+            'path': '/path/example.git',
+            'userinfo': '',
+            'userinfo': '',
+            'username': '',
+            'password': '',
+            'params': {},
+            'relative': False
+        }
+    }
+
+    def test_uri(self):
+        for test_uri, ref in self.test_uris.items():
+            uri = URI(test_uri)
+
+            self.assertEqual(str(uri), ref['uri'])
+
+            # expected attributes
+            self.assertEqual(uri.scheme, ref['scheme'])
+
+            self.assertEqual(uri.userinfo, ref['userinfo'])
+            self.assertEqual(uri.username, ref['username'])
+            self.assertEqual(uri.password, ref['password'])
+
+            self.assertEqual(uri.hostname, ref['hostname'])
+            self.assertEqual(uri.port, ref['port'])
+            self.assertEqual(uri.hostport, ref['hostport'])
+
+            self.assertEqual(uri.path, ref['path'])
+            self.assertEqual(uri.params, ref['params'])
+
+            self.assertEqual(uri.relative, ref['relative'])
+
+    def test_dict(self):
+        for test in self.test_uris.values():
+            uri = URI()
+
+            self.assertEqual(uri.scheme, '')
+            self.assertEqual(uri.userinfo, '')
+            self.assertEqual(uri.username, '')
+            self.assertEqual(uri.password, '')
+            self.assertEqual(uri.hostname, '')
+            self.assertEqual(uri.port, None)
+            self.assertEqual(uri.path, '')
+            self.assertEqual(uri.params, {})
+
+
+            uri.scheme = test['scheme']
+            self.assertEqual(uri.scheme, test['scheme'])
+
+            uri.userinfo = test['userinfo']
+            self.assertEqual(uri.userinfo, test['userinfo'])
+            self.assertEqual(uri.username, test['username'])
+            self.assertEqual(uri.password, test['password'])
+
+            uri.hostname = test['hostname']
+            self.assertEqual(uri.hostname, test['hostname'])
+            self.assertEqual(uri.hostport, test['hostname'])
+
+            uri.port = test['port']
+            self.assertEqual(uri.port, test['port'])
+            self.assertEqual(uri.hostport, test['hostport'])
+
+            uri.path = test['path']
+            self.assertEqual(uri.path, test['path'])
+
+            uri.params = test['params']
+            self.assertEqual(uri.params, test['params'])
+
+            self.assertEqual(str(uri)+str(uri.relative), str(test['uri'])+str(test['relative']))
+
+            self.assertEqual(str(uri), test['uri'])
+
+            uri.params = {}
+            self.assertEqual(uri.params, {})
+            self.assertEqual(str(uri), (str(uri).split(";"))[0])
+
 
 class FetcherTest(unittest.TestCase):
 

bitbake/lib/bb/tests/utils.py

@@ -1,3 +1,5 @@
+# ex:ts=4:sw=4:sts=4:et
+# -*- tab-width: 4; c-basic-offset: 4; indent-tabs-mode: nil -*-
 #
 # BitBake Tests for utils.py
 #

bitbake/lib/bb/tinfoil.py

@@ -29,15 +29,17 @@ from bb.cooker import state
 import bb.fetch2
 
 class Tinfoil:
-    def __init__(self):
+    def __init__(self, output=sys.stdout):
         # Needed to avoid deprecation warnings with python 2.6
         warnings.filterwarnings("ignore", category=DeprecationWarning)
 
         # Set up logging
         self.logger = logging.getLogger('BitBake')
-        console = logging.StreamHandler(sys.stdout)
-        format = bb.msg.BBLogFormatter("%(levelname)s: %(message)s")
+        console = logging.StreamHandler(output)
         bb.msg.addDefaultlogFilter(console)
+        format = bb.msg.BBLogFormatter("%(levelname)s: %(message)s")
+        if output.isatty():
+            format.enable_color()
         console.setFormatter(format)
         self.logger.addHandler(console)
 

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

@@ -190,20 +190,6 @@ class Configuration:
         self.split_proxy("cvs", params["cvs_proxy_host"] + ":" + params["cvs_proxy_port"])
 
     def load(self, template):
-        self.curr_mach = template.getVar("MACHINE")
-        self.curr_package_format = " ".join(template.getVar("PACKAGE_CLASSES").split("package_")).strip()
-        self.curr_distro = template.getVar("DISTRO")
-        self.dldir = template.getVar("DL_DIR")
-        self.sstatedir = template.getVar("SSTATE_DIR")
-        self.sstatemirror = template.getVar("SSTATE_MIRRORS")
-        try:
-            self.pmake = int(template.getVar("PARALLEL_MAKE").split()[1])
-        except:
-            pass
-        try:
-            self.bbthread = int(template.getVar("BB_NUMBER_THREADS"))
-        except:
-            pass
         try:
             self.image_rootfs_size = int(template.getVar("IMAGE_ROOTFS_SIZE"))
         except:
@@ -215,13 +201,9 @@ class Configuration:
         # image_overhead_factor is read-only.
         self.incompat_license = template.getVar("INCOMPATIBLE_LICENSE")
         self.curr_sdk_machine = template.getVar("SDKMACHINE")
-        self.conf_version = template.getVar("CONF_VERSION")
-        self.lconf_version = template.getVar("LCONF_VERSION")
         self.extra_setting = eval(template.getVar("EXTRA_SETTING"))
         self.toolchain_build = eval(template.getVar("TOOLCHAIN_BUILD"))
         self.image_fstypes = template.getVar("IMAGE_FSTYPES")
-        # bblayers.conf
-        self.layers = template.getVar("BBLAYERS").split()
         # image/recipes/packages
         self.selected_image = template.getVar("__SELECTED_IMAGE__")
         self.selected_recipes = template.getVar("DEPENDS").split()
@@ -235,26 +217,32 @@ class Configuration:
         self.split_proxy("git", template.getVar("GIT_PROXY_HOST") + ":" + template.getVar("GIT_PROXY_PORT"))
         self.split_proxy("cvs", template.getVar("CVS_PROXY_HOST") + ":" + template.getVar("CVS_PROXY_PORT"))
 
-    def save(self, template, defaults=False):
+    def save(self, handler, template, defaults=False):
         template.setVar("VERSION", "%s" % hobVer)
         # bblayers.conf
-        template.setVar("BBLAYERS", " ".join(self.layers))
+        handler.set_var_in_file("BBLAYERS", self.layers, "bblayers.conf")
         # local.conf
         if not defaults:
-            template.setVar("MACHINE", self.curr_mach)
-        template.setVar("DISTRO", self.curr_distro)
-        template.setVar("DL_DIR", self.dldir)
-        template.setVar("SSTATE_DIR", self.sstatedir)
-        template.setVar("SSTATE_MIRRORS", self.sstatemirror)
-        template.setVar("PARALLEL_MAKE", "-j %s" % self.pmake)
-        template.setVar("BB_NUMBER_THREADS", self.bbthread)
-        template.setVar("PACKAGE_CLASSES", " ".join(["package_" + i for i in self.curr_package_format.split()]))
+            handler.set_var_in_file("MACHINE", self.curr_mach, "local.conf")
+        handler.set_var_in_file("DISTRO", self.curr_distro, "local.conf")
+        handler.set_var_in_file("DL_DIR", self.dldir, "local.conf")
+        handler.set_var_in_file("SSTATE_DIR", self.sstatedir, "local.conf")
+        sstate_mirror_list = self.sstatemirror.split("\\n ")
+        sstate_mirror_list_modified = []
+        for mirror in sstate_mirror_list:
+            if mirror != "":
+                mirror = mirror + "\\n"
+                sstate_mirror_list_modified.append(mirror)
+        handler.set_var_in_file("SSTATE_MIRRORS", sstate_mirror_list_modified, "local.conf")
+        handler.set_var_in_file("PARALLEL_MAKE", "-j %s" % self.pmake, "local.conf")
+        handler.set_var_in_file("BB_NUMBER_THREADS", self.bbthread, "local.conf")
+        handler.set_var_in_file("PACKAGE_CLASSES", " ".join(["package_" + i for i in self.curr_package_format.split()]), "local.conf")
         template.setVar("IMAGE_ROOTFS_SIZE", self.image_rootfs_size)
         template.setVar("IMAGE_EXTRA_SPACE", self.image_extra_size)
         template.setVar("INCOMPATIBLE_LICENSE", self.incompat_license)
         template.setVar("SDKMACHINE", self.curr_sdk_machine)
-        template.setVar("CONF_VERSION", self.conf_version)
-        template.setVar("LCONF_VERSION", self.lconf_version)
+        handler.set_var_in_file("CONF_VERSION", self.conf_version, "local.conf")
+        handler.set_var_in_file("LCONF_VERSION", self.lconf_version, "bblayers.conf")
         template.setVar("EXTRA_SETTING", self.extra_setting)
         template.setVar("TOOLCHAIN_BUILD", self.toolchain_build)
         template.setVar("IMAGE_FSTYPES", self.image_fstypes)
@@ -561,11 +549,9 @@ class Builder(gtk.Window):
 
     def initiate_new_build_async(self):
         self.switch_page(self.MACHINE_SELECTION)
-        if self.load_template(TemplateMgr.convert_to_template_pathfilename("default", ".hob/")) == False:
-            self.show_sanity_check_page()
-            self.handler.init_cooker()
-            self.handler.set_extra_inherit("image_types")
-            self.generate_configuration()
+        self.handler.init_cooker()
+        self.handler.set_extra_inherit("image_types")
+        self.generate_configuration()
 
     def update_config_async(self):
         self.switch_page(self.MACHINE_SELECTION)
@@ -689,7 +675,7 @@ class Builder(gtk.Window):
         self.template = TemplateMgr()
         try:
             self.template.open(filename, path)
-            self.configuration.save(self.template, defaults)
+            self.configuration.save(self.handler, self.template, defaults)
 
             self.template.save()
         except Exception as e:
@@ -1244,39 +1230,6 @@ class Builder(gtk.Window):
                 self.update_config_async()
         dialog.destroy()
 
-    def show_load_template_dialog(self):
-        dialog = gtk.FileChooserDialog("Load Template Files", self,
-                                       gtk.FILE_CHOOSER_ACTION_OPEN)
-        button = dialog.add_button("Cancel", gtk.RESPONSE_NO)
-        HobAltButton.style_button(button)
-        button = dialog.add_button("Open", gtk.RESPONSE_YES)
-        HobButton.style_button(button)
-        filter = gtk.FileFilter()
-        filter.set_name("Hob Files")
-        filter.add_pattern("*.hob")
-        dialog.add_filter(filter)
-
-        response = dialog.run()
-        path = None
-        if response == gtk.RESPONSE_YES:
-            path = dialog.get_filename()
-        dialog.destroy()
-        return response == gtk.RESPONSE_YES, path
-
-    def show_save_template_dialog(self):
-        dialog = gtk.FileChooserDialog("Save Template Files", self,
-                                       gtk.FILE_CHOOSER_ACTION_SAVE)
-        button = dialog.add_button("Cancel", gtk.RESPONSE_NO)
-        HobAltButton.style_button(button)
-        button = dialog.add_button("Save", gtk.RESPONSE_YES)
-        HobButton.style_button(button)
-        dialog.set_current_name("hob")
-        response = dialog.run()
-        if response == gtk.RESPONSE_YES:
-            path = dialog.get_filename()
-            self.save_template(path)
-        dialog.destroy()
-
     def get_image_extension(self):
         image_extension = {}
         for type in self.parameters.image_types:

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

@@ -105,8 +105,10 @@ class ParsingWarningsDialog (CrumbsDialog):
     def create_visual_elements(self):
         self.set_size_request(350, 350)
         self.heading_label = gtk.Label()
-        self.heading_label.set_alignment(0.1, 0)
+        self.heading_label.set_alignment(0, 0)
         self.warning_label = gtk.Label()
+        self.warning_label.set_selectable(True)
+        self.warning_label.set_alignment(0, 0)
         self.textWindow = gtk.ScrolledWindow()
 
         table = gtk.Table(1, 10, False)
@@ -155,7 +157,7 @@ class ParsingWarningsDialog (CrumbsDialog):
             self.vbox.pack_start(self.heading_label, expand=False, fill=False)
             self.vbox.pack_start(self.warning_label, expand=False, fill=False)
             self.vbox.pack_start(self.textWindow, expand=False, fill=False)
-            cancel_button = self.add_button("Cancel", gtk.RESPONSE_CANCEL)
+            cancel_button = self.add_button("Close", gtk.RESPONSE_CANCEL)
             HobAltButton.style_button(cancel_button)
 
         self.refresh_components()

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

@@ -120,97 +120,3 @@ class SettingsUIHelper():
 
         hbox.show_all()
         return hbox, entry
-
-    def gen_mirror_entry_widget(self, content, index, match_content=""):
-        hbox = gtk.HBox(False)
-        entry = gtk.Entry()
-        content = content[:-2]
-        entry.set_text(content)
-        entry.set_size_request(350,30)
-
-        entry_match = gtk.Entry()
-        entry_match.set_text(match_content)
-        entry_match.set_size_request(100,30)
-
-        table = gtk.Table(2, 5, False)
-        table.set_row_spacings(12)
-        table.set_col_spacings(6)
-        hbox.pack_start(table, expand=True, fill=True)
-
-        label_configuration = gtk.Label("Configuration")
-        label_configuration.set_alignment(0.0,0.5)
-        label_mirror_url = gtk.Label("Mirror URL")
-        label_mirror_url.set_alignment(0.0,0.5)
-        label_match = gtk.Label("Match")
-        label_match.set_alignment(0.0,0.5)
-        label_replace_with = gtk.Label("Replace with")
-        label_replace_with.set_alignment(0.0,0.5)
-
-        combo = gtk.combo_box_new_text()
-        combo.append_text("Standard")
-        combo.append_text("Custom")
-        if match_content == "":
-            combo.set_active(0)
-        else:
-            combo.set_active(1)
-        combo.connect("changed", self.on_combo_changed, index)
-        combo.set_size_request(100,30)
-
-        delete_button = HobAltButton("Delete")
-        delete_button.connect("clicked", self.delete_cb, index, entry)
-        if content == "" and index == 0  and len(self.sstatemirrors_list) == 1:
-            delete_button.set_sensitive(False)
-        delete_button.set_size_request(100, 30)
-
-        entry_match.connect("changed", self.insert_entry_match_cb, index)
-        entry.connect("changed", self.insert_entry_cb, index, delete_button)
-
-        if match_content == "":
-            table.attach(label_configuration, 1, 2, 0, 1, xoptions=gtk.SHRINK|gtk.FILL)
-            table.attach(label_mirror_url, 2, 3, 0, 1, xoptions=gtk.SHRINK|gtk.FILL)
-            table.attach(combo, 1, 2, 1, 2, xoptions=gtk.SHRINK)
-            table.attach(entry, 2, 3, 1, 2, xoptions=gtk.SHRINK)
-            table.attach(delete_button, 3, 4, 1, 2, xoptions=gtk.SHRINK)
-        else:
-            table.attach(label_configuration, 1, 2, 0, 1, xoptions=gtk.SHRINK|gtk.FILL)
-            table.attach(label_match, 2, 3, 0, 1, xoptions=gtk.SHRINK|gtk.FILL)
-            table.attach(label_replace_with, 3, 4, 0, 1, xoptions=gtk.SHRINK|gtk.FILL)
-            table.attach(combo, 1, 2, 1, 2, xoptions=gtk.SHRINK)
-            table.attach(entry_match, 2, 3, 1, 2, xoptions=gtk.SHRINK)
-            table.attach(entry, 3, 4, 1, 2, xoptions=gtk.SHRINK)
-            table.attach(delete_button, 4, 5, 1, 2, xoptions=gtk.SHRINK)
-
-        hbox.show_all()
-        return hbox
-
-    def insert_entry_match_cb(self, entry_match, index):
-        self.sstatemirrors_list[index][2] = entry_match.get_text()
-
-    def insert_entry_cb(self, entry, index, button):
-        self.sstatemirrors_list[index][1] = entry.get_text()
-        if entry.get_text() == "" and index == 0:
-            button.set_sensitive(False)
-        else:
-            button.set_sensitive(True)
-
-    def on_combo_changed(self, combo, index):
-        if combo.get_active_text() == "Standard":
-            self.sstatemirrors_list[index][0] = 0
-            self.sstatemirrors_list[index][2] = "file://(.*)"
-        else:
-            self.sstatemirrors_list[index][0] = 1
-        self.refresh_shared_state_page()
-
-    def delete_cb(self, button, index, entry):
-        if index == 0 and len(self.sstatemirrors_list)==1:
-            entry.set_text("")
-        else:
-            self.sstatemirrors_list.pop(index)
-            self.refresh_shared_state_page()
-
-    def add_mirror(self, button):
-        tooltip = "Select the pre-built mirror that will speed your build"
-        index = len(self.sstatemirrors_list)
-        sm_list = [0, "", "file://(.*)"]
-        self.sstatemirrors_list.append(sm_list)
-        self.refresh_shared_state_page()

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

@@ -50,6 +50,13 @@ class SimpleSettingsDialog (CrumbsDialog, SettingsUIHelper):
      TEST_NETWORK_FAILED,
      TEST_NETWORK_CANCELED) = range(6)
 
+    TARGETS = [
+        ("MY_TREE_MODEL_ROW", gtk.TARGET_SAME_WIDGET, 0),
+        ("text/plain", 0, 1),
+        ("TEXT", 0, 2),
+        ("STRING", 0, 3),
+        ]
+
     def __init__(self, title, configuration, all_image_types,
             all_package_formats, all_distros, all_sdk_machines,
             max_threads, parent, flags, handler, buttons=None):
@@ -84,6 +91,8 @@ class SimpleSettingsDialog (CrumbsDialog, SettingsUIHelper):
         self.proxy_settings_changed = False
         self.handler = handler
         self.proxy_test_ran = False
+        self.selected_mirror_row = 0
+        self.new_mirror = False
 
         # create visual elements on the dialog
         self.create_visual_elements()
@@ -219,7 +228,7 @@ class SimpleSettingsDialog (CrumbsDialog, SettingsUIHelper):
         self.configuration.sstatedir = self.sstatedir_text.get_text()
         self.configuration.sstatemirror = ""
         for mirror in self.sstatemirrors_list:
-            if mirror[1] != "":
+            if mirror[1] != "" and mirror[2].startswith("file://"):
                 if mirror[1].endswith("\\1"):
                     smirror = mirror[2] + " " + mirror[1] + " \\n "
                 else:
@@ -287,7 +296,7 @@ class SimpleSettingsDialog (CrumbsDialog, SettingsUIHelper):
         label = self.gen_label_info_widget(content, tooltip)
         sstatedir_widget, self.sstatedir_text = self.gen_entry_widget(self.configuration.sstatedir, self)
         sub_vbox.pack_start(label, expand=False, fill=False)
-        sub_vbox.pack_start(sstatedir_widget, expand=False, fill=False, padding=12)
+        sub_vbox.pack_start(sstatedir_widget, expand=False, fill=False, padding=6)
 
         content = "<span weight=\"bold\">Shared state mirrors</span>"
         tooltip = "URLs pointing to pre-built mirrors that will speed your build. "
@@ -297,21 +306,17 @@ class SimpleSettingsDialog (CrumbsDialog, SettingsUIHelper):
         tooltip += "http://www.yoctoproject.org/docs/current/poky-ref-manual/"
         tooltip += "poky-ref-manual.html#shared-state\">Yocto Project Reference Manual</a>."
         table = self.gen_label_info_widget(content, tooltip)
-        advanced_vbox.pack_start(table, expand=False, fill=False)
+        advanced_vbox.pack_start(table, expand=False, fill=False, padding=6)
 
         sub_vbox = gtk.VBox(False)
-        scroll = gtk.ScrolledWindow()
-        scroll.set_policy(gtk.POLICY_NEVER, gtk.POLICY_AUTOMATIC)
-        scroll.add_with_viewport(sub_vbox)
-        scroll.connect('size-allocate', self.scroll_changed)
-        advanced_vbox.pack_start(scroll, gtk.TRUE, gtk.TRUE, 0)
+        advanced_vbox.pack_start(sub_vbox, gtk.TRUE, gtk.TRUE, 0)
         searched_string = "file://"
 
         if self.sstatemirrors_changed == 0:
             self.sstatemirrors_changed = 1
             sstatemirrors = self.configuration.sstatemirror
             if sstatemirrors == "":
-                sm_list = [ 0, "", "file://(.*)"]
+                sm_list = ["Standard", "", "file://(.*)"]
                 self.sstatemirrors_list.append(sm_list)
             else:
                 while sstatemirrors.find(searched_string) != -1:
@@ -323,31 +328,208 @@ class SimpleSettingsDialog (CrumbsDialog, SettingsUIHelper):
                         sstatemirrors = sstatemirrors[1:]
 
                     sstatemirror_fields = [x for x in sstatemirror.split(' ') if x.strip()]
-                    if sstatemirror_fields[0] == "file://(.*)":
-                        sm_list = [ 0, sstatemirror_fields[1], "file://(.*)"]
-                    else:
-                        sm_list = [ 1, sstatemirror_fields[1], sstatemirror_fields[0]]
-                    self.sstatemirrors_list.append(sm_list)
+                    if len(sstatemirror_fields):
+                        if sstatemirror_fields[0] == "file://(.*)":
+                            sm_list = ["Standard", sstatemirror_fields[1], "file://(.*)"]
+                        else:
+                            sm_list = ["Custom", sstatemirror_fields[1], sstatemirror_fields[0]]
+                        self.sstatemirrors_list.append(sm_list)
 
-        index = 0
-        for mirror in self.sstatemirrors_list:
-            if mirror[0] == 0:
-                sstatemirror_widget = self.gen_mirror_entry_widget(mirror[1], index)
-            else:
-                sstatemirror_widget = self.gen_mirror_entry_widget(mirror[1], index, mirror[2])
-            sub_vbox.pack_start(sstatemirror_widget, expand=False, fill=False, padding=9)
-            index += 1
+        sstatemirrors_widget, sstatemirrors_store = self.gen_shared_sstate_widget(self.sstatemirrors_list, self)
+        sub_vbox.pack_start(sstatemirrors_widget, expand=True, fill=True)
 
-        table = gtk.Table(1, 1, False)
+        table = gtk.Table(1, 10, False)
         table.set_col_spacings(6)
-        add_mirror_button = HobAltButton("Add another mirror")
+        add_mirror_button = HobAltButton("Add mirror")
         add_mirror_button.connect("clicked", self.add_mirror)
-        add_mirror_button.set_size_request(150,30)
+        add_mirror_button.set_size_request(120,30)
         table.attach(add_mirror_button, 1, 2, 0, 1, xoptions=gtk.SHRINK)
-        advanced_vbox.pack_start(table, expand=False, fill=False, padding=9)
+
+        self.delete_button = HobAltButton("Delete mirror")
+        self.delete_button.connect("clicked", self.delete_cb)
+        self.delete_button.set_size_request(120, 30)
+        table.attach(self.delete_button, 3, 4, 0, 1, xoptions=gtk.SHRINK)
+
+        advanced_vbox.pack_start(table, expand=False, fill=False, padding=6)
 
         return advanced_vbox
 
+    def gen_shared_sstate_widget(self, sstatemirrors_list, window):
+        hbox = gtk.HBox(False)
+
+        sstatemirrors_store = gtk.ListStore(str, str, str)
+        for sstatemirror in sstatemirrors_list:
+            sstatemirrors_store.append(sstatemirror)
+
+        self.sstatemirrors_tv = gtk.TreeView()
+        self.sstatemirrors_tv.set_rules_hint(True)
+        self.sstatemirrors_tv.set_headers_visible(True)
+        tree_selection = self.sstatemirrors_tv.get_selection()
+        tree_selection.set_mode(gtk.SELECTION_SINGLE)
+
+        # Allow enable drag and drop of rows including row move
+        self.sstatemirrors_tv.enable_model_drag_source( gtk.gdk.BUTTON1_MASK,
+            self.TARGETS,
+            gtk.gdk.ACTION_DEFAULT|
+            gtk.gdk.ACTION_MOVE)
+        self.sstatemirrors_tv.enable_model_drag_dest(self.TARGETS,
+            gtk.gdk.ACTION_DEFAULT)
+        self.sstatemirrors_tv.connect("drag_data_get", self.drag_data_get_cb)
+        self.sstatemirrors_tv.connect("drag_data_received", self.drag_data_received_cb)
+
+
+        self.scroll = gtk.ScrolledWindow()
+        self.scroll.set_policy(gtk.POLICY_NEVER, gtk.POLICY_AUTOMATIC)
+        self.scroll.set_shadow_type(gtk.SHADOW_IN)
+        self.scroll.connect('size-allocate', self.scroll_changed)
+        self.scroll.add(self.sstatemirrors_tv)
+
+        #list store for cell renderer
+        m = gtk.ListStore(gobject.TYPE_STRING)
+        m.append(["Standard"])
+        m.append(["Custom"])
+
+        cell0 = gtk.CellRendererCombo()
+        cell0.set_property("model",m)
+        cell0.set_property("text-column", 0)
+        cell0.set_property("editable", True)
+        cell0.set_property("has-entry", False)
+        col0 = gtk.TreeViewColumn("Configuration")
+        col0.pack_start(cell0, False)
+        col0.add_attribute(cell0, "text", 0)
+        col0.set_cell_data_func(cell0, self.configuration_field)
+        self.sstatemirrors_tv.append_column(col0)
+
+        cell0.connect("edited", self.combo_changed, sstatemirrors_store)
+
+        self.cell1 = gtk.CellRendererText()
+        self.cell1.set_padding(5,2)
+        col1 = gtk.TreeViewColumn('Regex', self.cell1)
+        col1.set_cell_data_func(self.cell1, self.regex_field)
+        self.sstatemirrors_tv.append_column(col1)
+
+        self.cell1.connect("edited", self.regex_changed, sstatemirrors_store)
+
+        cell2 = gtk.CellRendererText()
+        cell2.set_padding(5,2)
+        cell2.set_property("editable", True)
+        col2 = gtk.TreeViewColumn('URL', cell2)
+        col2.set_cell_data_func(cell2, self.url_field)
+        self.sstatemirrors_tv.append_column(col2)
+
+        cell2.connect("edited", self.url_changed, sstatemirrors_store)
+
+        self.sstatemirrors_tv.set_model(sstatemirrors_store)
+        self.sstatemirrors_tv.set_cursor(self.selected_mirror_row)
+        hbox.pack_start(self.scroll, expand=True, fill=True)
+        hbox.show_all()
+
+        return hbox, sstatemirrors_store
+
+    def drag_data_get_cb(self, treeview, context, selection, target_id, etime):
+        treeselection = treeview.get_selection()
+        model, iter = treeselection.get_selected()
+        data = model.get_string_from_iter(iter)
+        selection.set(selection.target, 8, data)
+
+    def drag_data_received_cb(self, treeview, context, x, y, selection, info, etime):
+        model = treeview.get_model()
+        data = []
+        tree_iter = model.get_iter_from_string(selection.data)
+        data.append(model.get_value(tree_iter, 0))
+        data.append(model.get_value(tree_iter, 1))
+        data.append(model.get_value(tree_iter, 2))
+
+        drop_info = treeview.get_dest_row_at_pos(x, y)
+        if drop_info:
+            path, position = drop_info
+            iter = model.get_iter(path)
+            if (position == gtk.TREE_VIEW_DROP_BEFORE or position == gtk.TREE_VIEW_DROP_INTO_OR_BEFORE):
+                model.insert_before(iter, data)
+            else:
+                model.insert_after(iter, data)
+        else:
+            model.append(data)
+        if context.action == gtk.gdk.ACTION_MOVE:
+            context.finish(True, True, etime)
+        return
+
+    def delete_cb(self, button):
+        selection = self.sstatemirrors_tv.get_selection()
+        tree_model, tree_iter = selection.get_selected()
+        index = int(tree_model.get_string_from_iter(tree_iter))
+        if index == 0:
+            self.selected_mirror_row = index
+        else:
+            self.selected_mirror_row = index - 1
+        self.sstatemirrors_list.pop(index)
+        self.refresh_shared_state_page()
+        if not self.sstatemirrors_list:
+            self.delete_button.set_sensitive(False)
+
+    def add_mirror(self, button):
+        self.new_mirror = True
+        tooltip = "Select the pre-built mirror that will speed your build"
+        index = len(self.sstatemirrors_list)
+        self.selected_mirror_row = index
+        sm_list = ["Standard", "", "file://(.*)"]
+        self.sstatemirrors_list.append(sm_list)
+        self.refresh_shared_state_page()
+
+    def scroll_changed(self, widget, event, data=None):
+        if self.new_mirror == True:
+            adj = widget.get_vadjustment()
+            adj.set_value(adj.upper - adj.page_size)
+            self.new_mirror = False
+
+    def combo_changed(self, widget, path, text, model):
+        model[path][0] = text
+        selection = self.sstatemirrors_tv.get_selection()
+        tree_model, tree_iter = selection.get_selected()
+        index = int(tree_model.get_string_from_iter(tree_iter))
+        self.sstatemirrors_list[index][0] = text
+
+    def regex_changed(self, cell, path, new_text, user_data):
+        user_data[path][2] = new_text
+        selection = self.sstatemirrors_tv.get_selection()
+        tree_model, tree_iter = selection.get_selected()
+        index = int(tree_model.get_string_from_iter(tree_iter))
+        self.sstatemirrors_list[index][2] = new_text
+        return
+
+    def url_changed(self, cell, path, new_text, user_data):
+        if new_text!="Enter the mirror URL" and new_text!="Match regex and replace it with this URL":
+            user_data[path][1] = new_text
+            selection = self.sstatemirrors_tv.get_selection()
+            tree_model, tree_iter = selection.get_selected()
+            index = int(tree_model.get_string_from_iter(tree_iter))
+            self.sstatemirrors_list[index][1] = new_text
+        return
+
+    def configuration_field(self, column, cell, model, iter):
+        cell.set_property('text', model.get_value(iter, 0))
+        if model.get_value(iter, 0) == "Standard":
+            self.cell1.set_property("sensitive", False)
+            self.cell1.set_property("editable", False)
+        else:
+            self.cell1.set_property("sensitive", True)
+            self.cell1.set_property("editable", True)
+        return
+
+    def regex_field(self, column, cell, model, iter):
+        cell.set_property('text', model.get_value(iter, 2))
+        return
+
+    def url_field(self, column, cell, model, iter):
+        text = model.get_value(iter, 1)
+        if text == "":
+            if model.get_value(iter, 0) == "Standard":
+                text = "Enter the mirror URL"
+            else:
+                text = "Match regex and replace it with this URL"
+        cell.set_property('text', text)
+        return
+
     def refresh_shared_state_page(self):
         page_num = self.nb.get_current_page()
         self.nb.remove_page(page_num);
@@ -716,7 +898,3 @@ class SimpleSettingsDialog (CrumbsDialog, SettingsUIHelper):
         self.handler.disconnect(self.proxy_test_passed_id)
         self.handler.disconnect(self.proxy_test_failed_id)
         super(SimpleSettingsDialog, self).destroy()
-
-    def scroll_changed(self, widget, event, data=None):
-        adj = widget.get_vadjustment()
-        adj.set_value(adj.upper - adj.page_size)

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

@@ -146,7 +146,9 @@ class HobHandler(gobject.GObject):
         elif next_command == self.SUB_MATCH_CLASS:
             self.runCommand(["findFilesMatchingInDir", "rootfs_", "classes"])
         elif next_command == self.SUB_PARSE_CONFIG:
+            self.runCommand(["enableDataTracking"])
             self.runCommand(["parseConfigurationFiles", "", ""])
+            self.runCommand(["disableDataTracking"])
         elif next_command == self.SUB_GNERATE_TGTS:
             self.runCommand(["generateTargetsTree", "classes/image.bbclass", []])
         elif next_command == self.SUB_GENERATE_PKGINFO:
@@ -200,6 +202,10 @@ class HobHandler(gobject.GObject):
             self.run_next_command()
 
         elif isinstance(event, bb.event.SanityCheckPassed):
+            reparse = self.runCommand(["getVariable", "BB_INVALIDCONF"]) or None
+            if reparse is True:
+                self.runCommand(["setVariable", "BB_INVALIDCONF", False])
+                self.runCommand(["parseConfigurationFiles", "", ""])
             self.run_next_command()
 
         elif isinstance(event, bb.event.SanityCheckFailed):
@@ -451,6 +457,9 @@ class HobHandler(gobject.GObject):
                 ret.append(i)
         return " ".join(ret)
 
+    def set_var_in_file(self, var, val, default_file=None):
+        self.server.runCommand(["setVarFile", var, val, default_file])
+
     def get_parameters(self):
         # retrieve the parameters from bitbake
         params = {}

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

@@ -27,14 +27,15 @@ from bb.ui.crumbs.hobpages import HobPage
 #
 # PackageListModel
 #
-class PackageListModel(gtk.TreeStore):
+class PackageListModel(gtk.ListStore):
     """
-    This class defines an gtk.TreeStore subclass which will convert the output
-    of the bb.event.TargetsTreeGenerated event into a gtk.TreeStore whilst also
+    This class defines an gtk.ListStore subclass which will convert the output
+    of the bb.event.TargetsTreeGenerated event into a gtk.ListStore whilst also
     providing convenience functions to access gtk.TreeModel subclasses which
     provide filtered views of the data.
     """
-    (COL_NAME, COL_VER, COL_REV, COL_RNM, COL_SEC, COL_SUM, COL_RDEP, COL_RPROV, COL_SIZE, COL_BINB, COL_INC, COL_FADE_INC, COL_FONT) = range(13)
+
+    (COL_NAME, COL_VER, COL_REV, COL_RNM, COL_SEC, COL_SUM, COL_RDEP, COL_RPROV, COL_SIZE, COL_RCP, COL_BINB, COL_INC, COL_FADE_INC, COL_FONT) = range(14)
 
     __gsignals__ = {
         "package-selection-changed" : (gobject.SIGNAL_RUN_LAST,
@@ -45,15 +46,9 @@ class PackageListModel(gtk.TreeStore):
     __toolchain_required_packages__ = ["packagegroup-core-standalone-sdk-target", "packagegroup-core-standalone-sdk-target-dbg"]
 
     def __init__(self):
-
-        self.contents = None
-        self.images = None
-        self.pkgs_size = 0
-        self.pn_path = {}
-        self.pkg_path = {}
         self.rprov_pkg = {}
-        
-        gtk.TreeStore.__init__ (self,
+        gtk.ListStore.__init__ (self,
+                                gobject.TYPE_STRING,
                                 gobject.TYPE_STRING,
                                 gobject.TYPE_STRING,
                                 gobject.TYPE_STRING,
@@ -68,21 +63,20 @@ class PackageListModel(gtk.TreeStore):
                                 gobject.TYPE_BOOLEAN,
                                 gobject.TYPE_STRING)
 
-
     """
     Find the model path for the item_name
     Returns the path in the model or None
     """
     def find_path_for_item(self, item_name):
         pkg = item_name
-        if item_name not in self.pkg_path.keys():
+        if item_name not in self.pn_path.keys():
             if item_name not in self.rprov_pkg.keys():
                 return None
             pkg = self.rprov_pkg[item_name]
-            if pkg not in self.pkg_path.keys():
+            if pkg not in self.pn_path.keys():
                 return None
 
-        return self.pkg_path[pkg]
+        return self.pn_path[pkg]
 
     def find_item_for_path(self, item_path):
         return self[item_path][self.COL_NAME]
@@ -106,10 +100,20 @@ class PackageListModel(gtk.TreeStore):
         model.set_visible_func(self.tree_model_filter, filter)
 
         sort = gtk.TreeModelSort(model)
-        sort.set_sort_column_id(PackageListModel.COL_NAME, gtk.SORT_ASCENDING)
+        sort.set_sort_column_id(RecipeListModel.COL_NAME, gtk.SORT_ASCENDING)
         sort.set_default_sort_func(None)
         return sort
 
+    def exclude_item_sort_func(self, model, iter1, iter2):
+        val1 = model.get_value(iter1, RecipeListModel.COL_FADE_INC)
+        val2 = model.get_value(iter2, RecipeListModel.COL_INC)
+        return ((val1 == True) and (val2 == False))
+
+    def include_item_sort_func(self, model, iter1, iter2):
+        val1 = model.get_value(iter1, RecipeListModel.COL_INC)
+        val2 = model.get_value(iter2, RecipeListModel.COL_INC)
+        return ((val1 == False) and (val2 == True))
+
     def convert_vpath_to_path(self, view_model, view_path):
         # view_model is the model sorted
         # get the path of the model filtered
@@ -121,16 +125,13 @@ class PackageListModel(gtk.TreeStore):
         return path
 
     def convert_path_to_vpath(self, view_model, path):
-        name = self.find_item_for_path(path)
         it = view_model.get_iter_first()
         while it:
-            child_it = view_model.iter_children(it)
-            while child_it:
-                view_name = view_model.get_value(child_it, self.COL_NAME)
-                if view_name == name:
-                    view_path = view_model.get_path(child_it)
-                    return view_path
-                child_it = view_model.iter_next(child_it)
+            name = self.find_item_for_path(path)
+            view_name = view_model.get_value(it, RecipeListModel.COL_NAME)
+            if view_name == name:
+                view_path = view_model.get_path(it)
+                return view_path
             it = view_model.iter_next(it)
         return None
 
@@ -139,11 +140,8 @@ class PackageListModel(gtk.TreeStore):
     bb.event.PackageInfo event and populates the package list.
     """
     def populate(self, pkginfolist):
+        # First clear the model, in case repopulating
         self.clear()
-        self.pkgs_size = 0
-        self.pn_path = {}
-        self.pkg_path = {}
-        self.rprov_pkg = {}
 
         def getpkgvalue(pkgdict, key, pkgname, defaultval = None):
             value = pkgdict.get('%s_%s' % (key, pkgname), None)
@@ -155,15 +153,6 @@ class PackageListModel(gtk.TreeStore):
             pn = pkginfo['PN']
             pv = pkginfo['PV']
             pr = pkginfo['PR']
-            if pn in self.pn_path.keys():
-                pniter = self.get_iter(self.pn_path[pn])
-            else:
-                pniter = self.append(None)
-                self.set(pniter, self.COL_NAME, pn + '-' + pv + '-' + pr,
-                                 self.COL_INC, False)
-                self.pn_path[pn] = self.get_path(pniter)
-
-            # PKG is always present
             pkg = pkginfo['PKG']
             pkgv = getpkgvalue(pkginfo, 'PKGV', pkg)
             pkgr = getpkgvalue(pkginfo, 'PKGR', pkg)
@@ -180,6 +169,8 @@ class PackageListModel(gtk.TreeStore):
             for i in rprov.split():
                 self.rprov_pkg[i] = pkg
 
+            recipe = pn + '-' + pv + '-' + pr
+
             allow_empty = getpkgvalue(pkginfo, 'ALLOW_EMPTY', pkg, "")
 
             if pkgsize == "0" and not allow_empty:
@@ -188,20 +179,21 @@ class PackageListModel(gtk.TreeStore):
             # pkgsize is in KB
             size = HobPage._size_to_string(HobPage._string_to_size(pkgsize + ' KB'))
 
-            it = self.append(pniter)
-            self.pkg_path[pkg] = self.get_path(it)
-            self.set(it, self.COL_NAME, pkg, self.COL_VER, pkgv,
+            self.set(self.append(), self.COL_NAME, pkg, self.COL_VER, pkgv,
                      self.COL_REV, pkgr, self.COL_RNM, pkg_rename,
                      self.COL_SEC, section, self.COL_SUM, summary,
                      self.COL_RDEP, rdep + ' ' + rrec,
                      self.COL_RPROV, rprov, self.COL_SIZE, size,
-                     self.COL_BINB, "", self.COL_INC, False, self.COL_FONT, '10')
+                     self.COL_RCP, recipe, self.COL_BINB, "",
+                     self.COL_INC, False, self.COL_FONT, '10')
 
-    """
-    Check whether the item at item_path is included or not
-    """
-    def path_included(self, item_path):
-        return self[item_path][self.COL_INC]
+        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.
@@ -210,48 +202,32 @@ class PackageListModel(gtk.TreeStore):
         self.emit("package-selection-changed")
 
     """
-    Mark a certain package as selected.
-    All its dependencies are marked as selected.
-    The recipe provides the package is marked as selected.
-    If user explicitly selects a recipe, all its providing packages are selected
+    Check whether the item at item_path is included or not
+    """
+    def path_included(self, item_path):
+        return self[item_path][self.COL_INC]
+
+    """
+    Add this item, and any of its dependencies, to the image contents
     """
     def include_item(self, item_path, binb=""):
         if self.path_included(item_path):
             return
 
         item_name = self[item_path][self.COL_NAME]
-        item_rdep = self[item_path][self.COL_RDEP]
+        item_deps = self[item_path][self.COL_RDEP]
 
         self[item_path][self.COL_INC] = True
 
-        it = self.get_iter(item_path)
-
-        # If user explicitly selects a recipe, all its providing packages are selected.
-        if not self[item_path][self.COL_VER] and binb == "User Selected":
-            child_it = self.iter_children(it)
-            while child_it:
-                child_path = self.get_path(child_it)
-                child_included = self.path_included(child_path)
-                if not child_included:
-                    self.include_item(child_path, binb="User Selected")
-                child_it = self.iter_next(child_it)
-            return
-
-        # The recipe provides the package is also marked as selected
-        parent_it = self.iter_parent(it)
-        if parent_it:
-            parent_path = self.get_path(parent_it)
-            self[parent_path][self.COL_INC] = True
-
         item_bin = self[item_path][self.COL_BINB].split(', ')
         if binb and not binb in item_bin:
             item_bin.append(binb)
             self[item_path][self.COL_BINB] = ', '.join(item_bin).lstrip(', ')
 
-        if item_rdep:
+        if item_deps:
             # Ensure all of the items deps are included and, where appropriate,
             # add this item to their COL_BINB
-            for dep in item_rdep.split(" "):
+            for dep in item_deps.split(" "):
                 if dep.startswith('('):
                     continue
                 # If the contents model doesn't already contain dep, add it
@@ -270,12 +246,6 @@ class PackageListModel(gtk.TreeStore):
                 elif not dep_included:
                     self.include_item(dep_path, binb=item_name)
 
-    """
-    Mark a certain package as de-selected.
-    All other packages that depends on this package are marked as de-selected.
-    If none of the packages provided by the recipe, the recipe should be marked as de-selected.
-    If user explicitly de-select a recipe, all its providing packages are de-selected.
-    """
     def exclude_item(self, item_path):
         if not self.path_included(item_path):
             return
@@ -283,37 +253,9 @@ class PackageListModel(gtk.TreeStore):
         self[item_path][self.COL_INC] = False
 
         item_name = self[item_path][self.COL_NAME]
-        item_rdep = self[item_path][self.COL_RDEP]
-        it = self.get_iter(item_path)
-
-        # If user explicitly de-select a recipe, all its providing packages are de-selected.
-        if not self[item_path][self.COL_VER]:
-            child_it = self.iter_children(it)
-            while child_it:
-                child_path = self.get_path(child_it)
-                child_included = self[child_path][self.COL_INC]
-                if child_included:
-                    self.exclude_item(child_path)
-                child_it = self.iter_next(child_it)
-            return
-
-        # If none of the packages provided by the recipe, the recipe should be marked as de-selected.
-        parent_it = self.iter_parent(it)
-        peer_iter = self.iter_children(parent_it)
-        enabled = 0
-        while peer_iter:
-            peer_path = self.get_path(peer_iter)
-            if self[peer_path][self.COL_INC]:
-                enabled = 1
-                break
-            peer_iter = self.iter_next(peer_iter)
-        if not enabled:
-            parent_path = self.get_path(parent_it)
-            self[parent_path][self.COL_INC] = False
-
-        # All packages that depends on this package are de-selected.
-        if item_rdep:
-            for dep in item_rdep.split(" "):
+        item_deps = self[item_path][self.COL_RDEP]
+        if item_deps:
+            for dep in item_deps.split(" "):
                 if dep.startswith('('):
                     continue
                 dep_path = self.find_path_for_item(dep)
@@ -333,51 +275,40 @@ class PackageListModel(gtk.TreeStore):
                 self.exclude_item(binb_path)
 
     """
-    Package model may be incomplete, therefore when calling the
-    set_selected_packages(), some packages will not be set included.
-    Return the un-set packages list.
+    Empty self.contents by setting the include of each entry to None
     """
-    def set_selected_packages(self, packagelist, user_selected=False):
-        left = []
-        binb = 'User Selected' if user_selected else ''
-        for pn in packagelist:
-            if pn in self.pkg_path.keys():
-                path = self.pkg_path[pn]
-                self.include_item(item_path=path, binb=binb)
-            else:
-                left.append(pn)
-
-        self.selection_change_notification()
-        return left
-
-    def get_user_selected_packages(self):
-        packagelist = []
-
+    def reset(self):
         it = self.get_iter_first()
         while it:
-            child_it = self.iter_children(it)
-            while child_it:
-                if self.get_value(child_it, self.COL_INC):
-                    binb = self.get_value(child_it, self.COL_BINB)
-                    if binb == "User Selected":
-                        name = self.get_value(child_it, self.COL_NAME)
-                        packagelist.append(name)
-                child_it = self.iter_next(child_it)
+            self.set(it,
+                     self.COL_INC, False,
+                     self.COL_BINB, "")
             it = self.iter_next(it)
 
-        return packagelist
+        self.selection_change_notification()
 
     def get_selected_packages(self):
         packagelist = []
 
         it = self.get_iter_first()
         while it:
-            child_it = self.iter_children(it)
-            while child_it:
-                if self.get_value(child_it, self.COL_INC):
-                    name = self.get_value(child_it, self.COL_NAME)
+            if self.get_value(it, self.COL_INC):
+                name = self.get_value(it, self.COL_NAME)
+                packagelist.append(name)
+            it = self.iter_next(it)
+
+        return packagelist
+
+    def get_user_selected_packages(self):
+        packagelist = []
+
+        it = self.get_iter_first()
+        while it:
+            if self.get_value(it, self.COL_INC):
+                binb = self.get_value(it, self.COL_BINB)
+                if binb == "User Selected":
+                    name = self.get_value(it, self.COL_NAME)
                     packagelist.append(name)
-                child_it = self.iter_next(child_it)
             it = self.iter_next(it)
 
         return packagelist
@@ -388,16 +319,31 @@ class PackageListModel(gtk.TreeStore):
         it = self.get_iter_first()
         while it:
             if self.get_value(it, self.COL_INC):
-                child_it = self.iter_children(it)
-                while child_it:
-                    name = self.get_value(child_it, self.COL_NAME)
-                    inc = self.get_value(child_it, self.COL_INC)
-                    if inc or name.endswith("-dev") or name.endswith("-dbg"):
-                        packagelist.append(name)
-                    child_it = self.iter_next(child_it)
+                name = self.get_value(it, self.COL_NAME)
+                if name.endswith("-dev") or name.endswith("-dbg"):
+                    packagelist.append(name)
             it = self.iter_next(it)
 
         return list(set(packagelist + self.__toolchain_required_packages__));
+
+    """
+    Package model may be incomplete, therefore when calling the
+    set_selected_packages(), some packages will not be set included.
+    Return the un-set packages list.
+    """
+    def set_selected_packages(self, packagelist, user_selected=False):
+        left = []
+        binb = 'User Selected' if user_selected else ''
+        for pn in packagelist:
+            if pn in self.pn_path.keys():
+                path = self.pn_path[pn]
+                self.include_item(item_path=path, binb=binb)
+            else:
+                left.append(pn)
+
+        self.selection_change_notification()
+        return left
+
     """
     Return the selected package size, unit is B.
     """
@@ -405,37 +351,16 @@ class PackageListModel(gtk.TreeStore):
         packages_size = 0
         it = self.get_iter_first()
         while it:
-            child_it = self.iter_children(it)
-            while child_it:
-                if self.get_value(child_it, self.COL_INC):
-                    str_size = self.get_value(child_it, self.COL_SIZE)
-                    if not str_size:
-                        continue
+            if self.get_value(it, self.COL_INC):
+                str_size = self.get_value(it, self.COL_SIZE)
+                if not str_size:
+                    continue
 
-                    packages_size += HobPage._string_to_size(str_size)
+                packages_size += HobPage._string_to_size(str_size)
 
-                child_it = self.iter_next(child_it)
             it = self.iter_next(it)
         return packages_size
 
-    """
-    Empty self.contents by setting the include of each entry to None
-    """
-    def reset(self):
-        self.pkgs_size = 0
-        it = self.get_iter_first()
-        while it:
-            self.set(it, self.COL_INC, False)
-            child_it = self.iter_children(it)
-            while child_it:
-                self.set(child_it,
-                         self.COL_INC, False,
-                         self.COL_BINB, "")
-                child_it = self.iter_next(child_it)
-            it = self.iter_next(it)
-
-        self.selection_change_notification()
-
     """
     Resync the state of included items to a backup column before performing the fadeout visible effect
     """
@@ -444,9 +369,6 @@ class PackageListModel(gtk.TreeStore):
         while it:
             active = self.get_value(it, self.COL_INC)
             self.set(it, self.COL_FADE_INC, active)
-            if self.iter_has_child(it):
-                self.resync_fadeout_column(self.iter_children(it))
-
             it = self.iter_next(it)
 
 #
@@ -533,7 +455,7 @@ class RecipeListModel(gtk.ListStore):
 
     """
     Create, if required, and return a filtered gtk.TreeModelSort
-    containing only the items which are items specified by filter
+    containing only the items specified by filter
     """
     def tree_model(self, filter, excluded_items_ahead=False, included_items_ahead=True):
         model = self.filter_new()

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

@@ -44,8 +44,6 @@ class hic:
     ICON_PACKAGES_HOVER_FILE      = os.path.join(HOB_ICON_BASE_DIR, ('packages/packages_hover.png'))
     ICON_LAYERS_DISPLAY_FILE      = os.path.join(HOB_ICON_BASE_DIR, ('layers/layers_display.png'))
     ICON_LAYERS_HOVER_FILE        = os.path.join(HOB_ICON_BASE_DIR, ('layers/layers_hover.png'))
-    ICON_TEMPLATES_DISPLAY_FILE   = os.path.join(HOB_ICON_BASE_DIR, ('templates/templates_display.png'))
-    ICON_TEMPLATES_HOVER_FILE     = os.path.join(HOB_ICON_BASE_DIR, ('templates/templates_hover.png'))
     ICON_IMAGES_DISPLAY_FILE      = os.path.join(HOB_ICON_BASE_DIR, ('images/images_display.png'))
     ICON_IMAGES_HOVER_FILE        = os.path.join(HOB_ICON_BASE_DIR, ('images/images_hover.png'))
     ICON_SETTINGS_DISPLAY_FILE    = os.path.join(HOB_ICON_BASE_DIR, ('settings/settings_display.png'))

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

@@ -55,12 +55,6 @@ class ImageConfigurationPage (HobPage):
         self.toolbar.set_orientation(gtk.ORIENTATION_HORIZONTAL)
         self.toolbar.set_style(gtk.TOOLBAR_BOTH)
 
-        template_button = self.append_toolbar_button(self.toolbar,
-            "Templates",
-            hic.ICON_TEMPLATES_DISPLAY_FILE,
-            hic.ICON_TEMPLATES_HOVER_FILE,
-            "Load a previously saved template",
-            self.template_button_clicked_cb)
         my_images_button = self.append_toolbar_button(self.toolbar,
             "Images",
             hic.ICON_IMAGES_DISPLAY_FILE,
@@ -173,6 +167,11 @@ class ImageConfigurationPage (HobPage):
 
         return warnings_bar
 
+    def disable_warnings_bar(self):
+        if self.builder.parsing_warnings:
+            self.warnings_bar.hide_all()
+            self.builder.parsing_warnings = []
+
     def create_config_machine(self):
         self.machine_title = gtk.Label()
         self.machine_title.set_alignment(0.0, 0.5)
@@ -298,6 +297,7 @@ class ImageConfigurationPage (HobPage):
 
     def machine_combo_changed_cb(self, machine_combo):
         self.stopping = False
+        self.builder.parsing_warnings = []
         combo_item = machine_combo.get_active_text()
         if not combo_item or combo_item == self.__dummy_machine__:
             return
@@ -318,6 +318,7 @@ class ImageConfigurationPage (HobPage):
         self.builder.populate_recipe_package_info_async()
 
     def update_machine_combo(self):
+        self.disable_warnings_bar()
         all_machines = [self.__dummy_machine__] + self.builder.parameters.all_machines
 
         model = self.machine_combo.get_model()
@@ -327,6 +328,7 @@ class ImageConfigurationPage (HobPage):
         self.machine_combo.set_active(0)
 
     def switch_machine_combo(self):
+        self.disable_warnings_bar()
         self.machine_combo_changed_by_manual = False
         model = self.machine_combo.get_model()
         active = 0
@@ -486,13 +488,6 @@ class ImageConfigurationPage (HobPage):
         self.builder.configuration.initial_selected_image = self.builder.configuration.selected_image
         self.builder.show_recipes()
 
-    def template_button_clicked_cb(self, button):
-        response, path = self.builder.show_load_template_dialog()
-        if not response:
-            return
-        if path:
-            self.builder.load_template(path)
-
     def my_images_button_clicked_cb(self, button):
         self.builder.show_load_my_images_dialog()
 

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

@@ -197,12 +197,6 @@ class ImageDetailsPage (HobPage):
         self.toolbar.set_orientation(gtk.ORIENTATION_HORIZONTAL)
         self.toolbar.set_style(gtk.TOOLBAR_BOTH)
 
-        template_button = self.append_toolbar_button(self.toolbar,
-            "Templates",
-            hic.ICON_TEMPLATES_DISPLAY_FILE,
-            hic.ICON_TEMPLATES_HOVER_FILE,
-            "Load a previously saved template",
-            self.template_button_clicked_cb)
         my_images_button = self.append_toolbar_button(self.toolbar,
             "Images",
             hic.ICON_IMAGES_DISPLAY_FILE,
@@ -265,11 +259,7 @@ class ImageDetailsPage (HobPage):
             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)
 
-        # create the buttons at the bottom first because the buttons are used in apply_button_per_image()
-        if self.build_succeeded:
-            self.buttonlist = ["Build new image", "Save as template", "Run image", "Deploy image"]
-        else: # get to this page from "My images"
-            self.buttonlist = ["Build new image", "Run image", "Deploy image"]
+        self.buttonlist = ["Build new image", "Run image", "Deploy image"]
 
         # Name
         self.image_store = []
@@ -582,26 +572,6 @@ class ImageDetailsPage (HobPage):
             created = True
             is_runnable = True
 
-        name = "Save as template"
-        if name in buttonlist:
-            if created == True:
-                # separator
-                #label = gtk.Label(" or ")
-                #self.details_bottom_buttons.pack_end(label, expand=False, fill=False)
-
-                # create button "Save as template"
-                save_button = HobAltButton("Save as template")
-            else:
-                save_button = HobButton("Save as template")
-                #save_button.set_size_request(205, 49)
-                save_button.set_flags(gtk.CAN_DEFAULT)
-                packed = True
-            save_button.set_tooltip_text("Save the image configuration for reuse")
-            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)
-            create = True
-
         name = "Build new image"
         if name in buttonlist:
             # create button "Build new image"
@@ -618,9 +588,6 @@ class ImageDetailsPage (HobPage):
 
         return is_runnable
 
-    def save_button_clicked_cb(self, button):
-        self.builder.show_save_template_dialog()
-
     def deploy_button_clicked_cb(self, button):
         if self.toggled_image:
             if self.num_toggled > 1:
@@ -648,13 +615,6 @@ class ImageDetailsPage (HobPage):
     def edit_packages_button_clicked_cb(self, button):
         self.builder.show_packages(ask=False)
 
-    def template_button_clicked_cb(self, button):
-        response, path = self.builder.show_load_template_dialog()
-        if not response:
-            return
-        if path:
-            self.builder.load_template(path)
-
     def my_images_button_clicked_cb(self, button):
         self.builder.show_load_my_images_dialog()
 

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

@@ -51,6 +51,13 @@ class PackageSelectionPage (HobPage):
                        'col_min'  : 100,
                        'col_max'  : 300,
                        'expand'   : 'True'
+                      }, {
+                       'col_name' : 'Recipe',
+                       'col_id'   : PackageListModel.COL_RCP,
+                       'col_style': 'text',
+                       'col_min'  : 100,
+                       'col_max'  : 250,
+                       'expand'   : 'True'
                       }, {
                        'col_name' : 'Brought in by (+others)',
                        'col_id'   : PackageListModel.COL_BINB,
@@ -83,6 +90,13 @@ class PackageSelectionPage (HobPage):
                        'col_min'  : 100,
                        'col_max'  : 500,
                        'expand'   : 'True'
+                      }, {
+                       'col_name' : 'Recipe',
+                       'col_id'   : PackageListModel.COL_RCP,
+                       'col_style': 'text',
+                       'col_min'  : 100,
+                       'col_max'  : 250,
+                       'expand'   : 'True'
                       }, {
                        'col_name' : 'Included',
                        'col_id'   : PackageListModel.COL_INC,
@@ -99,7 +113,7 @@ class PackageSelectionPage (HobPage):
     def __init__(self, builder):
         super(PackageSelectionPage, self).__init__(builder, "Edit packages")
 
-        # set invisiable members
+        # set invisible members
         self.recipe_model = self.builder.recipe_model
         self.package_model = self.builder.package_model
 
@@ -196,13 +210,7 @@ class PackageSelectionPage (HobPage):
         else:
             self.builder.show_configuration()
 
-    def _expand_all(self):
-        for tab in self.tables:
-            tab.table_tree.expand_all()
-
     def refresh_selection(self):
-        self._expand_all()
-
         self.builder.configuration.selected_packages = self.package_model.get_selected_packages()
         self.builder.configuration.user_selected_packages = self.package_model.get_user_selected_packages()
         selected_packages_num = len(self.builder.configuration.selected_packages)

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

@@ -137,8 +137,6 @@ class RecipeFile(ConfigFile):
 
 class TemplateMgr(gobject.GObject):
 
-    __gLocalVars__ = ["MACHINE", "PACKAGE_CLASSES", "DISTRO", "DL_DIR", "SSTATE_DIR", "SSTATE_MIRRORS", "PARALLEL_MAKE", "BB_NUMBER_THREADS", "CONF_VERSION"]
-    __gBBLayersVars__ = ["BBLAYERS", "LCONF_VERSION"]
     __gRecipeVars__ = ["DEPENDS", "IMAGE_INSTALL"]
 
     def __init__(self):
@@ -152,37 +150,21 @@ class TemplateMgr(gobject.GObject):
     def convert_to_template_pathfilename(cls, filename, path):
         return "%s/%s%s%s" % (path, "template-", filename, ".hob")
 
-    @classmethod
-    def convert_to_bblayers_pathfilename(cls, filename, path):
-        return "%s/%s%s%s" % (path, "bblayers-", filename, ".conf")
-
-    @classmethod
-    def convert_to_local_pathfilename(cls, filename, path):
-        return "%s/%s%s%s" % (path, "local-", filename, ".conf")
-
     @classmethod
     def convert_to_image_pathfilename(cls, filename, path):
         return "%s/%s%s%s" % (path, "hob-image-", filename, ".bb")
 
     def open(self, filename, path):
         self.template_hob = HobTemplateFile(TemplateMgr.convert_to_template_pathfilename(filename, path))
-        self.bblayers_conf = ConfigFile(TemplateMgr.convert_to_bblayers_pathfilename(filename, path))
-        self.local_conf = ConfigFile(TemplateMgr.convert_to_local_pathfilename(filename, path))
         self.image_bb = RecipeFile(TemplateMgr.convert_to_image_pathfilename(filename, path))
 
     def setVar(self, var, val):
-        if var in TemplateMgr.__gLocalVars__:
-            self.local_conf.setVar(var, val)
-        if var in TemplateMgr.__gBBLayersVars__:
-            self.bblayers_conf.setVar(var, val)
         if var in TemplateMgr.__gRecipeVars__:
             self.image_bb.setVar(var, val)
 
         self.template_hob.setVar(var, val)
 
     def save(self):
-        self.local_conf.save()
-        self.bblayers_conf.save()
         self.image_bb.save()
         self.template_hob.save()
 
@@ -200,12 +182,6 @@ class TemplateMgr(gobject.GObject):
         if self.template_hob:
             del self.template_hob
             template_hob = None
-        if self.bblayers_conf:
-            del self.bblayers_conf
-            self.bblayers_conf = None
-        if self.local_conf:
-            del self.local_conf
-            self.local_conf = None
         if self.image_bb:
             del self.image_bb
             self.image_bb = None

bitbake/lib/bb/ui/knotty.py

@@ -453,7 +453,8 @@ def main(server, eventHandler, tf = TerminalFilter):
                                   bb.runqueue.runQueueExitWait,
                                   bb.event.OperationStarted,
                                   bb.event.OperationCompleted,
-                                  bb.event.OperationProgress)):
+                                  bb.event.OperationProgress,
+                                  bb.event.DiskFull)):
                 continue
 
             logger.error("Unknown event: %s", event)

bitbake/lib/bb/utils.py

@@ -458,27 +458,6 @@ def preserved_envvars_exported():
         'USER',
     ]
 
-def preserved_envvars_exported_interactive():
-    """Variables which are taken from the environment and placed in and exported
-    from the metadata, for interactive tasks"""
-    return [
-        'COLORTERM',
-        'DBUS_SESSION_BUS_ADDRESS',
-        'DESKTOP_SESSION',
-        'DESKTOP_STARTUP_ID',
-        'DISPLAY',
-        'GNOME_KEYRING_PID',
-        'GNOME_KEYRING_SOCKET',
-        'GPG_AGENT_INFO',
-        'GTK_RC_FILES',
-        'SESSION_MANAGER',
-        'KRB5CCNAME',
-        'SSH_AUTH_SOCK',
-        'XAUTHORITY',
-        'XDG_DATA_DIRS',
-        'XDG_SESSION_COOKIE',
-    ]
-
 def preserved_envvars():
     """Variables which are taken from the environment and placed in the metadata"""
     v = [
@@ -487,7 +466,7 @@ def preserved_envvars():
         'BB_ENV_WHITELIST',
         'BB_ENV_EXTRAWHITE',
     ]
-    return v + preserved_envvars_exported() + preserved_envvars_exported_interactive()
+    return v + preserved_envvars_exported()
 
 def filter_environment(good_vars):
     """
@@ -495,24 +474,20 @@ def filter_environment(good_vars):
     are not known and may influence the build in a negative way.
     """
 
-    removed_vars = []
+    removed_vars = {}
     for key in os.environ.keys():
         if key in good_vars:
             continue
 
-        removed_vars.append(key)
+        removed_vars[key] = os.environ[key]
         os.unsetenv(key)
         del os.environ[key]
 
     if len(removed_vars):
-        logger.debug(1, "Removed the following variables from the environment: %s", ", ".join(removed_vars))
+        logger.debug(1, "Removed the following variables from the environment: %s", ", ".join(removed_vars.keys()))
 
     return removed_vars
 
-def create_interactive_env(d):
-    for k in preserved_envvars_exported_interactive():
-        os.setenv(k, d.getVar(k, True))
-
 def approved_variables():
     """
     Determine and return the list of whitelisted variables which are approved
@@ -534,7 +509,9 @@ def clean_environment():
     """
     if 'BB_PRESERVE_ENV' not in os.environ:
         good_vars = approved_variables()
-        filter_environment(good_vars)
+        return filter_environment(good_vars)
+
+    return {}
 
 def empty_environment():
     """
@@ -558,14 +535,17 @@ def remove(path, recurse=False):
     """Equivalent to rm -f or rm -rf"""
     if not path:
         return
-    import os, errno, shutil, glob
+    if recurse:
+        import subprocess, glob
+        # shutil.rmtree(name) would be ideal but its too slow
+        subprocess.call(['rm', '-rf'] + glob.glob(path))
+        return
+    import os, errno, glob
     for name in glob.glob(path):
         try:
             os.unlink(name)
         except OSError as exc:
-            if recurse and exc.errno == errno.EISDIR:
-                shutil.rmtree(name)
-            elif exc.errno != errno.ENOENT:
+            if exc.errno != errno.ENOENT:
                 raise
 
 def prunedir(topdir):
@@ -820,3 +800,31 @@ def cpu_count():
 def nonblockingfd(fd):
     fcntl.fcntl(fd, fcntl.F_SETFL, fcntl.fcntl(fd, fcntl.F_GETFL) | os.O_NONBLOCK)
 
+def process_profilelog(fn):
+    # Redirect stdout to capture profile information
+    pout = open(fn + '.processed', 'w')
+    so = sys.stdout.fileno()
+    orig_so = os.dup(sys.stdout.fileno())
+    os.dup2(pout.fileno(), so)
+   
+    import pstats
+    p = pstats.Stats(fn)
+    p.sort_stats('time')
+    p.print_stats()
+    p.print_callers()
+    p.sort_stats('cumulative')
+    p.print_stats()
+
+    os.dup2(orig_so, so)
+    pout.flush()
+    pout.close()  
+
+#
+# Work around multiprocessing pool bugs in python < 2.7.3
+#
+def multiprocessingpool(*args, **kwargs):
+    if sys.version_info < (2, 7, 3):
+        return bb.compat.Pool(*args, **kwargs)
+    else:
+        return multiprocessing.pool.Pool(*args, **kwargs)
+

bitbake/lib/prserv/serv.py

@@ -86,7 +86,8 @@ class PRServer(SimpleXMLRPCServer):
     def work_forever(self,):
         self.quit = False
         self.timeout = 0.5
-        logger.info("PRServer: started! DBfile: %s, IP: %s, PORT: %s, PID: %s" %
+
+        logger.info("Started PRServer with DBfile: %s, IP: %s, PORT: %s, PID: %s" %
                      (self.dbfile, self.host, self.port, str(os.getpid())))
 
         while not self.quit:
@@ -97,16 +98,10 @@ class PRServer(SimpleXMLRPCServer):
         return
 
     def start(self):
-        if self.daemon is True:
-            logger.info("PRServer: try to start daemon...")
-            self.daemonize()
-        else:
-            atexit.register(self.delpid)
-            pid = str(os.getpid()) 
-            pf = file(self.pidfile, 'w+')
-            pf.write("%s\n" % pid)
-            pf.close()
-            self.work_forever()
+        pid = self.daemonize()
+        # Ensure both the parent sees this and the child from the work_forever log entry above
+        logger.info("Started PRServer with DBfile: %s, IP: %s, PORT: %s, PID: %s" %
+                     (self.dbfile, self.host, self.port, str(pid)))
 
     def delpid(self):
         os.remove(self.pidfile)
@@ -118,8 +113,9 @@ class PRServer(SimpleXMLRPCServer):
         try:
             pid = os.fork()
             if pid > 0:
+                os.waitpid(pid, 0)
                 #parent return instead of exit to give control 
-                return
+                return pid
         except OSError as e:
             raise Exception("%s [%d]" % (e.strerror, e.errno))
 
@@ -131,7 +127,7 @@ class PRServer(SimpleXMLRPCServer):
         try:
             pid = os.fork()
             if pid > 0: #parent
-                sys.exit(0)
+                os._exit(0)
         except OSError as e:
             raise Exception("%s [%d]" % (e.strerror, e.errno))
 
@@ -147,15 +143,22 @@ class PRServer(SimpleXMLRPCServer):
         os.dup2(so.fileno(),sys.stdout.fileno())
         os.dup2(se.fileno(),sys.stderr.fileno())
 
+        # Ensure logging makes it to the logfile
+        streamhandler = logging.StreamHandler()
+        streamhandler.setLevel(logging.DEBUG)
+        formatter = bb.msg.BBLogFormatter("%(levelname)s: %(message)s")
+        streamhandler.setFormatter(formatter)
+        logger.addHandler(streamhandler)
+
         # write pidfile
-        atexit.register(self.delpid)
         pid = str(os.getpid()) 
         pf = file(self.pidfile, 'w')
         pf.write("%s\n" % pid)
         pf.close()
 
         self.work_forever()
-        sys.exit(0)
+        self.delpid
+        os._exit(0)
 
 class PRServSingleton():
     def __init__(self, dbfile, logfile, interface):
@@ -164,21 +167,14 @@ class PRServSingleton():
         self.interface = interface
         self.host = None
         self.port = None
-        self.event = threading.Event()
-
-    def _work(self):
-        self.prserv = PRServer(self.dbfile, self.logfile, self.interface, False)
-        self.host, self.port = self.prserv.getinfo()
-        self.event.set()
-        self.prserv.work_forever()
-        del self.prserv.db
 
     def start(self):
-        self.working_thread = threading.Thread(target=self._work)
-        self.working_thread.start()
+        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):
-        self.event.wait()
         return (self.host, self.port)
 
 class PRServerConnection():
@@ -194,6 +190,7 @@ class PRServerConnection():
         import socket
         socket.setdefaulttimeout(2)
         try:
+            logger.info("Terminating PRServer...")
             self.connection.quit()
         except Exception as exc:
             sys.stderr.write("%s\n" % str(exc))
@@ -268,10 +265,17 @@ def is_local_special(host, port):
 
 def auto_start(d):
     global singleton
-    if (not d.getVar('PRSERV_HOST', True)) or (not d.getVar('PRSERV_PORT', True)):
+
+    host_params = filter(None, (d.getVar('PRSERV_HOST', True) or '').split(':'))
+    if not host_params:
         return True
 
-    if is_local_special(d.getVar('PRSERV_HOST', True), int(d.getVar('PRSERV_PORT', True))) and not singleton:
+    if len(host_params) != 2:
+        logger.critical('\n'.join(['PRSERV_HOST: incorrect format',
+                'Usage: PRSERV_HOST = "<hostname>:<port>"']))
+        return True
+
+    if is_local_special(host_params[0], int(host_params[1])) and not singleton:
         import bb.utils
         cachedir = (d.getVar("PERSISTENT_DIR", True) or d.getVar("CACHE", True))
         if not cachedir:
@@ -285,8 +289,8 @@ def auto_start(d):
     if singleton:
         host, port = singleton.getinfo()
     else:
-        host = d.getVar('PRSERV_HOST', True)
-        port = int(d.getVar('PRSERV_PORT', True))
+        host = host_params[0]
+        port = int(host_params[1])
 
     try:
         return PRServerConnection(host,port).ping()

documentation/Makefile

@@ -11,6 +11,8 @@
 #              or the mega-manual (single, large HTML file comprised of all
 #              Yocto Project manuals).
 #    html:     generates an HTML version of a manual.
+#    eclipse:  generates an HTML version of a manual that can be used as
+#              eclipse help (including necessary metadata files).
 #    tarball:  creates a tarball for the doc files.
 #    validate: validates
 #    publish:  pushes generated files to the Yocto Project website
@@ -70,26 +72,19 @@
 #
 
 ifeq ($(DOC),bsp-guide)
-XSLTOPTS = --stringparam html.stylesheet bsp-style.css \
-           --stringparam  chapter.autolabel 1 \
-           --stringparam  section.autolabel 1 \
-           --stringparam  section.label.includes.component.label 1 \
-           --xinclude
-ALLPREQ = html pdf tarball
-TARFILES = bsp-style.css bsp-guide.html bsp-guide.pdf figures/bsp-title.png
-MANUALS = $(DOC)/$(DOC).html $(DOC)/$(DOC).pdf
+XSLTOPTS = --xinclude
+ALLPREQ = html pdf eclipse tarball
+TARFILES = bsp-style.css bsp-guide.html bsp-guide.pdf figures/bsp-title.png \
+           eclipse
+MANUALS = $(DOC)/$(DOC).html $(DOC)/$(DOC).pdf $(DOC)/eclipse
 FIGURES = figures
 STYLESHEET = $(DOC)/*.css
 
 endif
 
 ifeq ($(DOC),dev-manual)
-XSLTOPTS = --stringparam html.stylesheet dev-style.css \
-           --stringparam  chapter.autolabel 1 \
-           --stringparam  section.autolabel 1 \
-           --stringparam  section.label.includes.component.label 1 \
-           --xinclude
-ALLPREQ = html pdf tarball
+XSLTOPTS = --xinclude
+ALLPREQ = html pdf eclipse tarball
 #
 # Note that the tarfile might produce the "Cannot stat: No such file or directory" error
 # message for .PNG files that are not present when building a particular branch.  The
@@ -120,21 +115,24 @@ TARFILES = dev-style.css dev-manual.html dev-manual.pdf \
            figures/app-dev-flow.png figures/bsp-dev-flow.png figures/dev-title.png \
            figures/git-workflow.png figures/index-downloads.png figures/kernel-dev-flow.png \
            figures/kernel-overview-1.png figures/kernel-overview-2-generic.png \
-           figures/source-repos.png figures/yp-download.png
+           figures/source-repos.png figures/yp-download.png \
+           eclipse
 	endif
 
-MANUALS = $(DOC)/$(DOC).html $(DOC)/$(DOC).pdf
+MANUALS = $(DOC)/$(DOC).html $(DOC)/$(DOC).pdf $(DOC)/eclipse
 FIGURES = figures
 STYLESHEET = $(DOC)/*.css
 
 endif
 
 ifeq ($(DOC),yocto-project-qs)
-XSLTOPTS = --stringparam html.stylesheet qs-style.css \
-           --xinclude
-ALLPREQ = html tarball
-TARFILES = yocto-project-qs.html qs-style.css figures/yocto-environment.png figures/building-an-image.png figures/using-a-pre-built-image.png figures/yocto-project-transp.png
-MANUALS = $(DOC)/$(DOC).html
+XSLTOPTS = --xinclude
+ALLPREQ = html eclipse tarball
+TARFILES = yocto-project-qs.html qs-style.css figures/yocto-environment.png \
+           figures/building-an-image.png figures/using-a-pre-built-image.png \
+           figures/yocto-project-transp.png \
+           eclipse
+MANUALS = $(DOC)/$(DOC).html $(DOC)/eclipse
 FIGURES = figures
 STYLESHEET = $(DOC)/*.css
 endif
@@ -178,11 +176,27 @@ TARFILES = mega-manual.html mega-style.css figures/yocto-environment.png figures
 	figures/using-a-pre-built-image.png \
 	figures/poky-title.png figures/buildhistory.png figures/buildhistory-web.png \
 	figures/adt-title.png figures/bsp-title.png \
-	figures/kernel-title.png figures/kernel-architecture-overview.png \
+	figures/kernel-dev-title.png figures/kernel-architecture-overview.png \
 	figures/app-dev-flow.png figures/bsp-dev-flow.png figures/dev-title.png \
 	figures/git-workflow.png figures/index-downloads.png figures/kernel-dev-flow.png \
 	figures/kernel-overview-1.png figures/kernel-overview-2-generic.png \
-	figures/source-repos.png figures/yp-download.png figures/kernel-dev-title.png
+	figures/source-repos.png figures/yp-download.png \
+        figures/profile-title.png figures/kernelshark-all.png \
+        figures/kernelshark-choose-events.png figures/kernelshark-i915-display.png \
+        figures/kernelshark-output-display.png figures/lttngmain0.png \
+        figures/oprofileui-busybox.png figures/oprofileui-copy-to-user.png \
+        figures/oprofileui-downloading.png figures/oprofileui-processes.png \
+        figures/perf-probe-do_fork-profile.png figures/perf-report-cycles-u.png \
+        figures/perf-systemwide.png figures/perf-systemwide-libc.png \
+        figures/perf-wget-busybox-annotate-menu.png figures/perf-wget-busybox-annotate-udhcpc.png \
+        figures/perf-wget-busybox-debuginfo.png figures/perf-wget-busybox-dso-zoom.png \
+        figures/perf-wget-busybox-dso-zoom-menu.png figures/perf-wget-busybox-expanded-stripped.png \
+        figures/perf-wget-flat-stripped.png figures/perf-wget-g-copy-from-user-expanded-stripped.png \
+        figures/perf-wget-g-copy-to-user-expanded-debuginfo.png figures/perf-wget-g-copy-to-user-expanded-stripped.png \
+        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
 	endif
 
 MANUALS = $(DOC)/$(DOC).html
@@ -192,59 +206,59 @@ STYLESHEET = $(DOC)/*.css
 endif
 
 ifeq ($(DOC),ref-manual)
-XSLTOPTS = --stringparam html.stylesheet ref-style.css \
-           --stringparam  chapter.autolabel 1 \
-           --stringparam  appendix.autolabel A \
-           --stringparam  section.autolabel 1 \
-           --stringparam  section.label.includes.component.label 1 \
-           --xinclude
-ALLPREQ = html pdf tarball
+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
-MANUALS = $(DOC)/$(DOC).html $(DOC)/$(DOC).pdf
+	figures/buildhistory.png figures/buildhistory-web.png eclipse
+MANUALS = $(DOC)/$(DOC).html $(DOC)/$(DOC).pdf $(DOC)/eclipse
 FIGURES = figures
 STYLESHEET = $(DOC)/*.css
 endif
 
 
 ifeq ($(DOC),adt-manual)
-XSLTOPTS = --stringparam html.stylesheet adt-style.css \
-           --stringparam  chapter.autolabel 1 \
-           --stringparam  appendix.autolabel A \
-           --stringparam  section.autolabel 1 \
-           --stringparam  section.label.includes.component.label 1 \
-           --xinclude
-ALLPREQ = html pdf tarball
-TARFILES = adt-manual.html adt-manual.pdf adt-style.css figures/adt-title.png
-MANUALS = $(DOC)/$(DOC).html $(DOC)/$(DOC).pdf
+XSLTOPTS = --xinclude
+ALLPREQ = html pdf eclipse tarball
+TARFILES = adt-manual.html adt-manual.pdf adt-style.css figures/adt-title.png \
+			eclipse
+MANUALS = $(DOC)/$(DOC).html $(DOC)/$(DOC).pdf $(DOC)/eclipse
 FIGURES = figures
 STYLESHEET = $(DOC)/*.css
 endif
 
-ifeq ($(DOC),kernel-manual)
-XSLTOPTS = --stringparam html.stylesheet kernel-style.css \
-           --stringparam  chapter.autolabel 1 \
-           --stringparam  appendix.autolabel A \
-           --stringparam  section.autolabel 1 \
-           --stringparam  section.label.includes.component.label 1 \
-           --xinclude
-ALLPREQ = html pdf tarball
-TARFILES = kernel-manual.html kernel-manual.pdf kernel-style.css figures/kernel-title.png figures/kernel-architecture-overview.png
-MANUALS = $(DOC)/$(DOC).html $(DOC)/$(DOC).pdf
+ifeq ($(DOC),profile-manual)
+XSLTOPTS = --xinclude
+ALLPREQ = html pdf eclipse tarball
+TARFILES = profile-manual.html profile-manual.pdf profile-manual-style.css \
+           figures/profile-title.png figures/kernelshark-all.png \
+           figures/kernelshark-choose-events.png figures/kernelshark-i915-display.png \
+           figures/kernelshark-output-display.png figures/lttngmain0.png \
+           figures/oprofileui-busybox.png figures/oprofileui-copy-to-user.png \
+           figures/oprofileui-downloading.png figures/oprofileui-processes.png \
+           figures/perf-probe-do_fork-profile.png figures/perf-report-cycles-u.png \
+           figures/perf-systemwide.png figures/perf-systemwide-libc.png \
+           figures/perf-wget-busybox-annotate-menu.png figures/perf-wget-busybox-annotate-udhcpc.png \
+           figures/perf-wget-busybox-debuginfo.png figures/perf-wget-busybox-dso-zoom.png \
+           figures/perf-wget-busybox-dso-zoom-menu.png figures/perf-wget-busybox-expanded-stripped.png \
+           figures/perf-wget-flat-stripped.png figures/perf-wget-g-copy-from-user-expanded-stripped.png \
+           figures/perf-wget-g-copy-to-user-expanded-debuginfo.png figures/perf-wget-g-copy-to-user-expanded-stripped.png \
+           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 \
+           eclipse
+MANUALS = $(DOC)/$(DOC).html $(DOC)/$(DOC).pdf $(DOC)/eclipse
 FIGURES = figures
 STYLESHEET = $(DOC)/*.css
 endif
 
 ifeq ($(DOC),kernel-dev)
-XSLTOPTS = --stringparam html.stylesheet kernel-dev-style.css \
-           --stringparam  chapter.autolabel 1 \
-           --stringparam  appendix.autolabel A \
-           --stringparam  section.autolabel 1 \
-           --stringparam  section.label.includes.component.label 1 \
-           --xinclude
-ALLPREQ = html pdf tarball
-TARFILES = kernel-dev.html kernel-dev.pdf kernel-dev-style.css figures/kernel-dev-title.png
-MANUALS = $(DOC)/$(DOC).html $(DOC)/$(DOC).pdf
+XSLTOPTS = --xinclude
+ALLPREQ = html pdf eclipse tarball
+TARFILES = kernel-dev.html kernel-dev.pdf kernel-dev-style.css figures/kernel-dev-title.png \
+           figures/kernel-architecture-overview.png \
+           eclipse
+MANUALS = $(DOC)/$(DOC).html $(DOC)/$(DOC).pdf $(DOC)/eclipse
 FIGURES = figures
 STYLESHEET = $(DOC)/*.css
 endif
@@ -298,6 +312,49 @@ else
 endif
 
 
+eclipse: BASE_DIR = html/$(DOC)/
+
+eclipse: eclipse-generate eclipse-resolve-links
+
+.PHONY : eclipse-generate eclipse-resolve-links
+
+eclipse-generate:
+ifeq ($(filter $(DOC), adt-manual bsp-guide dev-manual kernel-dev profile-manual ref-manual yocto-project-qs),)
+	@echo " "
+	@echo "ERROR: You can only create eclipse documentation"
+	@echo "       of the following documentation parts:"
+	@echo "       - adt-manual"
+	@echo "       - bsp-guide"
+	@echo "       - dev-manual"
+	@echo "       - kernel-dev"
+	@echo "       - profile-manual"
+	@echo "       - ref-manual"
+	@echo "       - yocto-project-qs"
+	@echo " "
+else
+	@echo " "
+	@echo "******** Building eclipse help of "$(DOC)
+	@echo " "
+	cd $(DOC) && \
+		xsltproc $(XSLTOPTS) \
+				--stringparam base.dir '$(BASE_DIR)' \
+				-o eclipse/$(DOC).html \
+				$(DOC)-eclipse-customization.xsl $(DOC).xml && \
+		mv eclipse/toc.xml eclipse/$(DOC)-toc.xml && \
+		cp -rf $(FIGURES) eclipse/$(BASE_DIR) && \
+		cd ..;
+
+	$(call modify-eclipse)
+endif
+
+eclipse-resolve-links:
+	@echo " "
+	@echo "******** Using eclipse-help.sed to process external links"
+	@echo " "
+	$(foreach FILE, \
+		$(wildcard $(DOC)/eclipse/html/$(DOC)/*.html), \
+		$(shell sed -i -f tools/eclipse-help.sed $(FILE)))
+
 tarball: html
 	@echo " "
 	@echo "******** Creating Tarball of document files"

documentation/adt-manual/adt-intro.xml

@@ -48,17 +48,20 @@
         </itemizedlist>
     </para>
 
-    <section id='the-cross-toolchain'>
-        <title>The Cross-Toolchain</title>
+    <section id='the-cross-development-toolchain'>
+        <title>The Cross-Development Toolchain</title>
 
         <para>
-            The cross-toolchain consists of a cross-compiler, cross-linker, and cross-debugger
-            that are used to develop user-space applications for targeted hardware.
-            This toolchain is created either by running the ADT Installer script, a toolchain installer
-            script, or through a
-            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink> that
-            is based on your metadata
-            configuration or extension for your targeted device.
+            The
+            <ulink url='&YOCTO_DOCS_DEV_URL;#cross-development-toolchain'>Cross-Development Toolchain</ulink>
+            consists of a cross-compiler, cross-linker, and cross-debugger
+            that are used to develop user-space applications for targeted
+            hardware.
+            This toolchain is created either by running the ADT Installer
+            script, a toolchain installer script, or through a
+            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
+            that is based on your metadata configuration or extension for
+            your targeted device.
             The cross-toolchain works with a matching target sysroot.
         </para>
     </section>
@@ -147,18 +150,29 @@
                 <listitem><para><emphasis>OProfile:</emphasis> A system-wide profiler for Linux
                     systems that is capable of profiling all running code at low overhead.
                     You can find out more about OProfile at
-                    <ulink url='http://oprofile.sourceforge.net/about/'></ulink>.</para></listitem>
+                    <ulink url='http://oprofile.sourceforge.net/about/'></ulink>.
+                    For examples on how to setup and use this tool, see the
+                    "<ulink url='&YOCTO_DOCS_PROF_URL;#profile-manual-oprofile'>OProfile</ulink>"
+                    section in the Yocto Project Profiling and Tracing Manual.
+                    </para></listitem>
                 <listitem><para><emphasis>Perf:</emphasis> Performance counters for Linux used
                     to keep track of certain types of hardware and software events.
                     For more information on these types of counters see
                     <ulink url='https://perf.wiki.kernel.org/'></ulink> and click
-                    on “Perf tools.”</para></listitem>
+                    on “Perf tools.”
+                    For examples on how to setup and use this tool, see the
+                    "<ulink url='&YOCTO_DOCS_PROF_URL;#profile-manual-perf'>perf</ulink>"
+                    section in the Yocto Project Profiling and Tracing Manual.
+                    </para></listitem>
                 <listitem><para><emphasis>SystemTap:</emphasis> A free software infrastructure
                     that simplifies information gathering about a running Linux system.
                     This information helps you diagnose performance or functional problems.
                     SystemTap is not available as a user-space tool through the Eclipse IDE Yocto Plug-in.
                     See <ulink url='http://sourceware.org/systemtap'></ulink> for more information
-                    on SystemTap.</para></listitem>
+                    on SystemTap.
+                    For examples on how to setup and use this tool, see the
+                    "<ulink url='&YOCTO_DOCS_PROF_URL;#profile-manual-systemtap'>SystemTap</ulink>"
+                    section in the Yocto Project Profiling and Tracing Manual.</para></listitem>
                 <listitem><para><emphasis>Lttng-ust:</emphasis> A User-space Tracer designed to
                     provide detailed information on user-space activity.
                     See <ulink url='http://lttng.org/ust'></ulink> for more information on Lttng-ust.

documentation/adt-manual/adt-manual-customization.xsl

@@ -3,6 +3,9 @@
   
   <xsl:import href="http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl" />
 
-<!--  <xsl:param name="generate.toc" select="'article nop'"></xsl:param>  -->
-
+  <xsl:param name="html.stylesheet" select="'adt-style.css'" />
+  <xsl:param name="chapter.autolabel" select="1" />
+  <xsl:param name="appendix.autolabel" select="1" />
+  <xsl:param name="section.autolabel" select="1" />
+  <xsl:param name="section.label.includes.component.label" select="1" />
 </xsl:stylesheet>

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

@@ -0,0 +1,27 @@
+<?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/adt-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="1" />
+  <xsl:param name="section.autolabel" select="1" />
+  <xsl:param name="section.label.includes.component.label" select="1" />
+</xsl:stylesheet>

documentation/adt-manual/adt-manual.xml

@@ -16,7 +16,9 @@
             </imageobject>
         </mediaobject>
 
-        <title></title>
+        <title>
+            Yocto Project Application Developer's Guide
+        </title>
 
         <authorgroup>
             <author>

documentation/bsp-guide/bsp-guide-customization.xsl

@@ -3,4 +3,8 @@
   
   <xsl:import href="http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl" />
 
+  <xsl:param name="html.stylesheet" select="'bsp-style.css'" />
+  <xsl:param name="chapter.autolabel" select="1" />
+  <xsl:param name="section.autolabel" select="1" />
+  <xsl:param name="section.label.includes.component.label" select="1" />
 </xsl:stylesheet>

documentation/bsp-guide/bsp-guide-eclipse-customization.xsl

@@ -0,0 +1,27 @@
+<?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/bsp-guide/'"/>
+  <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="1" />
+  <xsl:param name="section.autolabel" select="1" />
+  <xsl:param name="section.label.includes.component.label" select="1" />
+</xsl:stylesheet>

documentation/bsp-guide/bsp-guide.xml

@@ -16,7 +16,9 @@
             </imageobject>
         </mediaobject>
 
-        <title></title>
+        <title>
+            Yocto Project Board Support Package Developer's Guide
+        </title>
 
         <authorgroup>
             <author>

documentation/bsp-guide/bsp.xml

@@ -621,7 +621,8 @@
             </para>
 
             <para>
-                The <filename>FILESEXTRAPATHS</filename> variable is in boilerplate form in the
+                The <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></ulink>
+                variable is in boilerplate form in the
                 previous example in order to make it easy to do that.
                 This variable must be in your layer or BitBake will not find the patches or
                 configurations even if you have them in your <filename>SRC_URI</filename>.

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

@@ -46,9 +46,17 @@
             <title>Layers</title>
 
             <para>
-                The Source Directory contains several layers right out of the box.
-                You can easily identify a layer in the Source Directory by its folder name.
-                Folders that are layers begin with the string <filename>meta</filename>.
+                The Source Directory contains several layers right out of the
+                box.
+                You can easily identify layers that ship with a
+                Yocto Project release in the Source Directory by their
+                folder names.
+                Folders that are layers begin with the string
+                <filename>meta</filename>.
+                <note>
+                    It is not a requirement that a layer begins with the
+                    string <filename>meta</filename>.
+                </note>
                 For example, when you set up the <link linkend='source-directory'>Source Directory</link>
                 structure, you will see several layers: <filename>meta</filename>,
                 <filename>meta-hob</filename>, <filename>meta-skeleton</filename>,
@@ -80,10 +88,10 @@
                         <ulink url='&OE_HOME_URL;/wiki/LayerIndex'><filename>LayerIndex</filename></ulink>
                         for a list of layers from the OpenEmbedded community that can be used in the
                         Yocto Project.</para></listitem>
-                    <listitem><para><emphasis>Create a Directory:</emphasis> Create the directory
-                        for your layer.
-                        Traditionally, prepend the name of the folder with the string
-                        <filename>meta</filename>.
+                    <listitem><para><emphasis>Create a Directory:</emphasis>
+                        Create the directory for your layer.
+                        While not strictly required, prepend the name of the
+                        folder with the string <filename>meta</filename>.
                         For example:
                         <literallayout class='monospaced'>
      meta-mylayer
@@ -94,37 +102,64 @@
                        layer folder, you need to create a <filename>conf/layer.conf</filename> file.
                        It is easiest to take an existing layer configuration file and copy that to your
                        layer's <filename>conf</filename> directory and then modify the file as needed.</para>
-                       <para>The <filename>meta-yocto/conf/layer.conf</filename> file demonstrates the
+                       <para>The <filename>meta-yocto-bsp/conf/layer.conf</filename> file demonstrates the
                        required syntax:
                        <literallayout class='monospaced'>
      # We have a conf and classes directory, add to BBPATH
-     BBPATH := "${LAYERDIR}:${BBPATH}"
+     BBPATH := "${BBPATH}:${LAYERDIR}"
 
-     # We have recipes-* directories, add to BBFILES
+     # We have a packages directory, add to BBFILES
      BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
                  ${LAYERDIR}/recipes-*/*/*.bbappend"
 
-     BBFILE_COLLECTIONS += "yocto"
-     BBFILE_PATTERN_yocto := "^${LAYERDIR}/"
-     BBFILE_PRIORITY_yocto = "5"
+     BBFILE_COLLECTIONS += "yoctobsp"
+     BBFILE_PATTERN_yoctobsp := "^${LAYERDIR}/"
+     BBFILE_PRIORITY_yoctobsp = "5"
                         </literallayout></para>
-                        <para>In the previous example, the recipes for the layers are added to
-                        <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-BBFILES'>BBFILES</ulink></filename>.
-                        The
-                        <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-BBFILE_COLLECTIONS'>BBFILE_COLLECTIONS</ulink></filename>
-                        variable is then appended with the layer name.
-                        The
-                        <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-BBFILE_PATTERN'>BBFILE_PATTERN</ulink></filename>
-                        variable is set to a regular expression and is used to match files
-                        from <filename>BBFILES</filename> into a particular layer.
-                        In this case, immediate expansion of
-                        <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-LAYERDIR'>LAYERDIR</ulink></filename>
-                        sets <filename>BBFILE_PATTERN</filename> to the layer's path.
-                        The
-                        <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-BBFILE_PRIORITY'>BBFILE_PRIORITY</ulink></filename>
-                        variable then assigns a priority to the layer.
-                        Applying priorities is useful in situations where the same package might appear in multiple
-                        layers and allows you to choose what layer should take precedence.</para>
+                        <para>Here is an explanation of the example:
+                        <itemizedlist>
+                            <listitem><para>The configuration and
+                                classes directory is appended to
+                                <ulink url='&YOCTO_DOCS_REF_URL;#var-BBPATH'><filename>BBPATH</filename></ulink>.
+                                <note>
+                                    All non-distro layers, which include all BSP
+                                    layers, are expected to append the layer
+                                    directory to the
+                                    <filename>BBPATH</filename>.
+                                    On the other hand, distro layers, such as
+                                    <filename>meta-yocto</filename>, can choose
+                                    to enforce their own precedence over
+                                    <filename>BBPATH</filename>.
+                                    For an example of that syntax, see the
+                                    <filename>layer.conf</filename> file for
+                                    the <filename>meta-yocto</filename> layer.
+                                </note></para></listitem>
+                            <listitem><para>The recipes for the layers are
+                                appended to
+                                <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-BBFILES'>BBFILES</ulink></filename>.
+                                </para></listitem>
+                            <listitem><para>The
+                                <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-BBFILE_COLLECTIONS'>BBFILE_COLLECTIONS</ulink></filename>
+                                variable is then appended with the layer name.
+                                </para></listitem>
+                            <listitem><para>The
+                                <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-BBFILE_PATTERN'>BBFILE_PATTERN</ulink></filename>
+                                variable is set to a regular expression and is
+                                used to match files from
+                                <filename>BBFILES</filename> into a particular
+                                layer.
+                                In this case, immediate expansion of
+                                <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-LAYERDIR'>LAYERDIR</ulink></filename>
+                                sets <filename>BBFILE_PATTERN</filename> to the
+                                layer's path.</para></listitem>
+                            <listitem><para>The
+                                <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-BBFILE_PRIORITY'>BBFILE_PRIORITY</ulink></filename>
+                                variable then assigns a priority to the layer.
+                                Applying priorities is useful in situations
+                                where the same package might appear in multiple
+                                layers and allows you to choose what layer
+                                should take precedence.</para></listitem>
+                        </itemizedlist></para>
                         <para>Note the use of the
                         <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-LAYERDIR'>LAYERDIR</ulink></filename>
                         variable with the immediate expansion operator.
@@ -260,15 +295,18 @@
             </para>
 
             <para>
-                Append files files must have the same name as the corresponding recipe.
+                Append files must have the same root name as the corresponding recipe.
                 For example, the append file <filename>someapp_&DISTRO;.bbappend</filename> must
                 apply to <filename>someapp_&DISTRO;.bb</filename>.
-                This means the original recipe and append file names are version number specific.
+                This means the original recipe and append file names are version number-specific.
                 If the corresponding recipe is renamed to update to a newer version, the
                 underlying <filename>.bbappend</filename> file must be renamed as well.
                 During the build process, BitBake displays an error on starting if it detects a
                 <filename>.bbappend</filename> file that does not have a corresponding recipe
                 with a matching name.
+                See the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-BB_DANGLINGAPPENDS_WARNONLY'><filename>BB_DANGLINGAPPENDS_WARNONLY</filename></ulink>
+                variable for information on how to handle this error.
             </para>
 
             <para>
@@ -282,7 +320,7 @@
                 append file both from the
                 <link linkend='source-directory'>Source Directory</link>.
                 Here is the main formfactor recipe, which is named <filename>formfactor_0.0.bb</filename> and
-                located in the meta layer at <filename>meta/recipes-bsp/formfactor</filename>:
+                located in the "meta" layer at <filename>meta/recipes-bsp/formfactor</filename>:
                 <literallayout class='monospaced'>
      DESCRIPTION = "Device formfactor information"
      SECTION = "base"
@@ -318,7 +356,8 @@
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
                 within a <filename>.bbappend</filename> by extending the path BitBake uses to search for files.
                 The most reliable way to do this is by prepending the
-                <filename>FILESEXTRAPATHS</filename> variable.
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></ulink>
+                variable.
                 For example, if you have your files in a directory that is named the same as your package
                 (<ulink url='&YOCTO_DOCS_REF_URL;#var-PN'><filename>PN</filename></ulink>),
                 you can add this directory by adding the following to your <filename>.bbappend</filename> file:
@@ -329,10 +368,16 @@
                 of the reference to <filename>THISDIR</filename>.
                 The trailing colon character is important as it ensures that items in the list remain
                 colon-separated.
-                <note>BitBake automatically defines the <filename>THISDIR</filename> variable.
+                <note><para>BitBake automatically defines the
+                    <filename>THISDIR</filename> variable.
                     You should never set this variable yourself.
-                    Using <filename>_prepend</filename> ensures your path will be searched prior to other
-                    paths in the final list.
+                    Using <filename>_prepend</filename> ensures your path will
+                    be searched prior to other paths in the final list.</para>
+                    <para>Also, not all append files add extra files.
+                    Many append files simply exist to add build options
+                    (e.g. <filename>systemd</filename>).
+                    For these cases, it is not necessary to use the
+                    "_prepend" part of the statement.</para>
                 </note>
             </para>
         </section>
@@ -344,7 +389,7 @@
                 Each layer is assigned a priority value.
                 Priority values control which layer takes precedence if there are recipe files with
                 the same name in multiple layers.
-                For these cases, the recipe file from the layer with a higher priority number taking precedence.
+                For these cases, the recipe file from the layer with a higher priority number takes precedence.
                 Priority values also affect the order in which multiple <filename>.bbappend</filename> files
                 for the same recipe are applied.
                 You can either specify the priority manually, or allow the build system to calculate it
@@ -1338,9 +1383,9 @@
         </para>
 
         <para>
-            For concepts on kernel configuration, see the
-            "<ulink url='&YOCTO_DOCS_KERNEL_URL;#kernel-configuration'>Kernel Configuration</ulink>"
-            section in the Yocto Project Kernel Architecture and Use Manual.
+            For more information on kernel configuration, see the
+            "<ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;#changing-the-configuration'>Changing the Configuration</ulink>"
+            section in the Yocto Project Linux Kernel Development Manual.
         </para>
 
         <section id='using-menuconfig'>
@@ -1622,6 +1667,12 @@
             in the Yocto Project Quick Start.
         </para>
 
+        <para>
+            Also, for more information on patching the kernel, see the
+            "<ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;#applying-patches'>Applying Patches</ulink>"
+            section in the Yocto Project Linux Kernel Development Manual.
+        </para>
+
         <section id='create-a-layer-for-your-changes'>
             <title>Create a Layer for your Changes</title>
 
@@ -1755,7 +1806,7 @@
                         the <filename>layer.conf</filename> file as follows:
                         <literallayout class='monospaced'>
      # We have a conf and classes directory, add to BBPATH
-     BBPATH := "${LAYERDIR}:${BBPATH}"
+     BBPATH := "${BBPATH}:${LAYERDIR}"
 
      # We have a packages directory, add to BBFILES
      BBFILES := "${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
@@ -1777,7 +1828,8 @@
 
      PRINC := "${@int(PRINC) + 1}"
                         </literallayout>
-                        The <filename>FILESEXTRAPATHS</filename> and <filename>SRC_URI</filename>
+                        The <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></ulink>
+                        and <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
                         statements enable the OpenEmbedded build system to find the patch file.
                         </para></listitem>
                     <listitem><para><emphasis>Put the patch file in your layer</emphasis>:
@@ -1924,71 +1976,225 @@
             </itemizedlist>
         </para>
 
-        <section id="usingpoky-changes-prbump">
+        <section id='incrementing-a-package-revision-number'>
             <title>Incrementing a Package Revision Number</title>
 
             <para>
                 If a committed change results in changing the package output,
                 then the value of the
-                <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PR'>PR</ulink></filename>
-                variable needs to be increased
-                (or "bumped") as part of that commit.
-                For new recipes you should add the <filename>PR</filename>
-                variable and set its initial value equal to "r0", which is the default.
-                Even though the default value is "r0", the practice of adding it to a new recipe makes
-                it harder to forget to bump the variable when you make changes
-                to the recipe in future.
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-PR'><filename>PR</filename></ulink>
+                variable needs to be increased (or "bumped").
+                Increasing <filename>PR</filename> occurs one of two ways:
+                <itemizedlist>
+                    <listitem><para>Automatically using a Package Revision
+                        Service (PR Service).</para></listitem>
+                    <listitem><para>Manually incrementing the
+                        <filename>PR</filename> variable.</para></listitem>
+                </itemizedlist>
             </para>
 
             <para>
-                If you are sharing a common <filename>.inc</filename> file with multiple recipes,
-                you can also use the
-                <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-INC_PR'>INC_PR</ulink></filename>
-                variable to ensure that
-                the recipes sharing the <filename>.inc</filename> file are rebuilt when the
-                <filename>.inc</filename> file itself is changed.
-                The <filename>.inc</filename> file must set <filename>INC_PR</filename>
-                (initially to "r0"), and all recipes referring to it should set <filename>PR</filename>
-                to "$(INC_PR).0" initially, incrementing the last number when the recipe is changed.
-                If the <filename>.inc</filename> file is changed then its
-                <filename>INC_PR</filename> should be incremented.
+                Given that one of the challenges any build system and its
+                users face is how to maintain a package feed that is compatible
+                with existing package manager applications such as
+                RPM, APT, and OPKG, using an automated system is much
+                preferred over a manual system.
+                In either system, the main requirement is that version
+                numbering increases in a linear fashion and that a number of
+                version components exist that support that linear progression.
             </para>
 
             <para>
-                When upgrading the version of a package, assuming the
-                <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PV'>PV</ulink></filename>
-                changes, the <filename>PR</filename> variable should be reset to "r0"
-                (or "$(INC_PR).0" if you are using <filename>INC_PR</filename>).
+                The following two sections provide information on the PR Service
+                and on manual <filename>PR</filename> bumping.
             </para>
 
-            <para>
-                Usually, version increases occur only to packages.
-                However, if for some reason <filename>PV</filename> changes but does not
-                increase, you can increase the
-                <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PE'>PE</ulink></filename>
-                variable (Package Epoch).
-                The <filename>PE</filename> variable defaults to "0".
-            </para>
+            <section id='working-with-a-pr-service'>
+                <title>Working With a PR Service</title>
 
-            <para>
-                Version numbering strives to follow the
-                <ulink url='http://www.debian.org/doc/debian-policy/ch-controlfields.html'>
-                Debian Version Field Policy Guidelines</ulink>.
-                These guidelines define how versions are compared and what "increasing" a version means.
-            </para>
+                <para>
+                    As mentioned, attempting to maintain revision numbers in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
+                    is error prone, inaccurate and causes problems for people
+                    submitting recipes.
+                    Conversely, the PR Service automatically generates
+                    increasing numbers, particularly the revision field,
+                    which removes the human element.
+                    <note>
+                        For additional information on using a PR Service, you
+                        can see the
+                        <ulink url='&YOCTO_WIKI_URL;/wiki/PR_Service'>PR Service</ulink>
+                        wiki page.
+                    </note>
+                </para>
 
-            <para>
-                There are two reasons for following the previously mentioned guidelines.
-                First, to ensure that when a developer updates and rebuilds, they get all the changes to
-                the repository and do not have to remember to rebuild any sections.
-                Second, to ensure that target users are able to upgrade their
-                devices using package manager commands such as <filename>opkg upgrade</filename>
-                (or similar commands for dpkg/apt or rpm-based systems).
-            </para>
+                <para>
+                    The Yocto Project uses variables in order of
+                    decreasing priority to facilitate revision numbering (i.e.
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-PE'><filename>PE</filename></ulink>,
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-PV'><filename>PV</filename></ulink>, and
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-PR'><filename>PR</filename></ulink>
+                    for epoch, version and revision, respectively).
+                    The values are highly dependent on the policies and
+                    procedures of a given distribution and package feed.
+                </para>
 
-            <para>
-                The goal is to ensure the Yocto Project has packages that can be upgraded in all cases.
-            </para>
+                <para>
+                    Because the OpenEmbedded build system uses
+                    "<ulink url='&YOCTO_DOCS_REF_URL;#checksums'>signatures</ulink>",
+                    which are unique to a given build, the build system
+                    knows when to rebuild packages.
+                    All the inputs into a given task are represented by a
+                    signature, which can trigger a rebuild when different.
+                    Thus, the build system itself does not rely on the
+                    <filename>PR</filename> numbers to trigger a rebuild.
+                    The signatures, however, can be used to generate
+                    <filename>PR</filename> values.
+                </para>
+
+                <para>
+                    The PR Service works with both
+                    <filename>OEBasic</filename> and
+                    <filename>OEBasicHash</filename> generators.
+                    The value of <filename>PR</filename> bumps when the
+                    checksum changes and the different generator mechanisms
+                    change signatures under different circumstances.
+                </para>
+
+                <para>
+                    As implemented, the build system includes values from
+                    the PR Service into the <filename>PR</filename> field as
+                    an addition using the form "<filename>.x</filename>" so
+                    <filename>r0</filename> becomes <filename>r0.1</filename>,
+                    <filename>r0.2</filename> and so forth.
+                    This scheme allows existing <filename>PR</filename> values
+                    to be used for whatever reasons, which include manual
+                    <filename>PR</filename> bumps should it be necessary.
+                </para>
+
+                <para>
+                    By default, the PR Service is not enabled or running.
+                    Thus, the packages generated are just "self consistent".
+                    The build system adds and removes packages and
+                    there are no guarantees about upgrade paths but images
+                    will be consistent and correct with the latest changes.
+                </para>
+
+                <para>
+                    The simplest form for a PR Service is for it to exist
+                    for a single host development system that builds the
+                    package feed (building system).
+                    For this scenario, you can enable the PR Service by adding
+                    the following to your <filename>local.conf</filename>
+                    file in the
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>:
+                    <literallayout class='monospaced'>
+     PRSERV_HOST = "localhost:0"
+                    </literallayout>
+                    Once the service is started, packages will automatically
+                    get increasing <filename>PR</filename> values and
+                    BitBake will take care of starting and stopping the server.
+                </para>
+
+                <para>
+                    If you have a more complex setup where multiple host
+                    development systems work against a common, shared package
+                    feed, you have a single PR Service running and it is
+                    connected to each building system.
+                    For this scenario, you need to start the PR Service using
+                    the <filename>bitbake-prserv</filename> command:
+                    <literallayout class='monospaced'>
+     bitbake-prserve &dash;&dash;host &lt;ip&gt; &dash;&dash;port &lt;port&gt; &dash;&dash;start
+                    </literallayout>
+                    In addition to hand-starting the service, you need to
+                    update the <filename>local.conf</filename> file of each
+                    building system as described earlier so each system
+                    points to the server and port.
+                </para>
+
+                <para>
+                    It is also recommended you use build history, which adds
+                    some sanity checks to package versions, in conjunction with
+                    the server that is running the PR Service.
+                    To enable build history, add the following to each building
+                    system's <filename>local.conf</filename> file:
+                    <literallayout class='monospaced'>
+     # It is recommended to activate "buildhistory" for testing the PR service
+     INHERIT += "buildhistory"
+     BUILDHISTORY_COMMIT = "1"
+                    </literallayout>
+                    For information on build history, see the
+                    "<ulink url='&YOCTO_DOCS_REF_URL;#maintaining-build-output-quality'>Maintaining Build Output Quality</ulink>"
+                    section in the Yocto Project Reference Manual.
+                </para>
+
+                <note>
+                    <para>The OpenEmbedded build system does not maintain
+                    <filename>PR</filename> information as part of the
+                    shared state (sstate) packages.
+                    If you maintain an sstate feed, its expected that either
+                    all your building systems that contribute to the sstate
+                    feed use a shared PR Service, or you do not run a PR
+                    Service on any of your building systems.
+                    Having some systems use a PR Service while others do
+                    not leads to obvious problems.</para>
+                    <para>For more information on shared state, see the
+                    "<ulink url='&YOCTO_DOCS_REF_URL;#shared-state-cache'>Shared State Cache</ulink>"
+                    section in the Yocto Project Reference Manual.</para>
+                </note>
+            </section>
+
+            <section id='manually-bumping-pr'>
+                <title>Manually Bumping PR</title>
+
+                <para>
+                    If a committed change results in changing the package output,
+                    then the value of the PR variable needs to be increased
+                    (or "bumped") as part of that commit.
+                    For new recipes you should add the <filename>PR</filename>
+                    variable and set its initial value equal to "r0", which is the default.
+                    Even though the default value is "r0", the practice of adding it to a new recipe makes
+                    it harder to forget to bump the variable when you make changes
+                    to the recipe in future.
+                </para>
+
+                <para>
+                    If you are sharing a common <filename>.inc</filename> file with multiple recipes,
+                    you can also use the
+                    <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-INC_PR'>INC_PR</ulink></filename>
+                    variable to ensure that
+                    the recipes sharing the <filename>.inc</filename> file are rebuilt when the
+                    <filename>.inc</filename> file itself is changed.
+                    The <filename>.inc</filename> file must set <filename>INC_PR</filename>
+                    (initially to "r0"), and all recipes referring to it should set <filename>PR</filename>
+                    to "$(INC_PR).0" initially, incrementing the last number when the recipe is changed.
+                    If the <filename>.inc</filename> file is changed then its
+                    <filename>INC_PR</filename> should be incremented.
+                </para>
+
+                <para>
+                    When upgrading the version of a package, assuming the
+                    <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PV'>PV</ulink></filename>
+                    changes, the <filename>PR</filename> variable should be reset to "r0"
+                    (or "$(INC_PR).0" if you are using <filename>INC_PR</filename>).
+                </para>
+
+                <para>
+                    Usually, version increases occur only to packages.
+                    However, if for some reason <filename>PV</filename> changes but does not
+                    increase, you can increase the
+                    <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PE'>PE</ulink></filename>
+                    variable (Package Epoch).
+                    The <filename>PE</filename> variable defaults to "0".
+                </para>
+
+                <para>
+                    Version numbering strives to follow the
+                    <ulink url='http://www.debian.org/doc/debian-policy/ch-controlfields.html'>
+                    Debian Version Field Policy Guidelines</ulink>.
+                    These guidelines define how versions are compared and what "increasing" a version means.
+                </para>
+            </section>
         </section>
 
         <section id="usingpoky-configuring-DISTRO_PN_ALIAS">
@@ -2307,27 +2513,38 @@
         <title>Excluding Recipes From the Build</title>
 
         <para>
-            You might find that there are groups of recipes you want to filter
-            out of the build process.
+            You might find that there are groups of recipes or append files
+            that you want to filter out of the build process.
             For example, recipes you know you will never use or want should not
             be part of the build.
-            Removing these recipes from parsing speeds up parts of the build.
+            Removing these files from parsing speeds up parts of the build.
         </para>
 
         <para>
             It is possible to filter or mask out <filename>.bb</filename> and
             <filename>.bbappend</filename> files.
             You can do this by providing an expression with the
-            <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-BBMASK'>BBMASK</ulink></filename>
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-BBMASK'><filename>BBMASK</filename></ulink>
             variable.
             Here is an example:
             <literallayout class='monospaced'>
-     BBMASK = ".*/meta-mymachine/recipes-maybe/"
+     BBMASK = "/meta-mymachine/recipes-maybe/"
             </literallayout>
-            Here, all <filename>.bb</filename> and <filename>.bbappend</filename> files
-            in the directory that match the expression are ignored during the build
-            process.
+            Here, all <filename>.bb</filename> and
+            <filename>.bbappend</filename> files in the directory that matches
+            the expression are ignored during the build process.
+            See the glossary entry for the
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-BBMASK'><filename>BBMASK</filename></ulink>
+            variable for more information.
         </para>
+
+        <note>
+            The value you provide is passed to python's regular expression
+            compiler.
+            The expression is compared against the full paths to the files.
+            For complete syntax information, see python's documentation at
+            <ulink url='http://docs.python.org/release/2.3/lib/re-syntax.html'></ulink>.
+        </note>
     </section>
 
     <section id="platdev-appdev-srcrev">
@@ -2606,6 +2823,11 @@
             the most time in when doing X?"
             Because the OpenEmbedded build system is well integrated with OProfile, it makes profiling
             applications on target hardware straightforward.
+            <note>
+                For more information on how to set up and run OProfile, see the
+                "<ulink url='&YOCTO_DOCS_PROF_URL;#profile-manual-oprofile'>OProfile</ulink>"
+                section in the Yocto Project Profiling and Tracing Manual.
+            </note>
         </para>
 
         <para>
@@ -2936,9 +3158,9 @@
      INHERIT += "${ARCHIVER_CLASS}"
      SOURCE_ARCHIVE_PACKAGE_TYPE = "tar"
                 </literallayout>
-                During the creation of your image, all GPL
-                or other copyleft licensed source
-                is placed within subdirectories of
+                During the creation of your image, the source from all
+                recipes that deploy packages to the image is placed within
+                subdirectories of
                 <filename>DEPLOY_DIR/sources</filename> based on the
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-LICENSE'><filename>LICENSE</filename></ulink>
                 for each recipe.
@@ -2957,7 +3179,7 @@
                 <literallayout class='monospaced'>
      $ cd poky/build/tmp/deploy/sources
      $ mkdir ~/gpl_source_release
-     $ for x in `ls|grep GPL`; do cp -R $x/* ~/gpl_source_release; done
+     $ for dir in */*GPL*; do cp -r $dir ~/gpl_source_release; done
                 </literallayout>
                 At this point, you could create a tarball from the
                 <filename>gpl_source_release</filename> directory and
@@ -3049,15 +3271,15 @@
      BBFILES ?= ""
 
      BBLAYERS ?= " \
-       $HOME/poky/meta \
-       $HOME/poky/meta-yocto \
-       $HOME/poky/meta-yocto-bsp \
-       $HOME/poky/meta-mylayer \
+       ##COREBASE##/meta \
+       ##COREBASE##/meta-yocto \
+       ##COREBASE##/meta-yocto-bsp \
+       ##COREBASE##/meta-mylayer \
        "
 
      BBLAYERS_NON_REMOVABLE ?= " \
-       $HOME/poky/meta \
-       $HOME/poky/meta-yocto \
+       ##COREBASE##/meta \
+       ##COREBASE##/meta-yocto \
        "
                 </literallayout>
                 Creating and providing an archive of the metadata layers

documentation/dev-manual/dev-manual-customization.xsl

@@ -3,6 +3,8 @@
   
   <xsl:import href="http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl" />
 
-<!--  <xsl:param name="generate.toc" select="'article nop'"></xsl:param>  -->
-
+  <xsl:param name="html.stylesheet" select="'dev-style.css'" />
+  <xsl:param name="chapter.autolabel" select="1" />
+  <xsl:param name="section.autolabel" select="1" />
+  <xsl:param name="section.label.includes.component.label" select="1" />
 </xsl:stylesheet>

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

@@ -0,0 +1,27 @@
+<?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/dev-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="1" />
+  <xsl:param name="section.autolabel" select="1" />
+  <xsl:param name="section.label.includes.component.label" select="1" />
+</xsl:stylesheet>

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

@@ -103,9 +103,15 @@
                     This guide defines the structure for BSP components.
                     Having a commonly understood structure encourages standardization.</para></listitem>
                 <listitem><para><emphasis>
-                    <ulink url='&YOCTO_DOCS_KERNEL_URL;'>Yocto Project Kernel Architecture and Use Manual</ulink>:</emphasis>
-                    This manual describes the architecture of the Yocto Project kernel and provides
-                    some work flow examples.</para></listitem>
+                    <ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;'>Yocto Project Linux Kernel Development Manual</ulink>:</emphasis>
+                    This manual describes how to work with Linux Yocto kernels as well as providing a bit
+                    of conceptual information on the construction of the Yocto Linux kernel tree.
+                    </para></listitem>
+                <listitem><para><emphasis>
+                    <ulink url='&YOCTO_DOCS_PROF_URL;'>Yocto Project Profiling and Tracing Manual</ulink>:</emphasis>
+                    This manual presents a set of common and generally useful tracing and
+                    profiling schemes along with their application (as appropriate) to each tool.
+                    </para></listitem>
                 <listitem><para><emphasis>
                     <ulink url='http://www.youtube.com/watch?v=3ZlOu-gLsh0'>
                     Eclipse IDE Yocto Plug-in</ulink>:</emphasis> A step-by-step instructional video that
@@ -115,8 +121,7 @@
                     <ulink url='&YOCTO_WIKI_URL;/wiki/FAQ'>FAQ</ulink>:</emphasis>
                     A list of commonly asked questions and their answers.</para></listitem>
                 <listitem><para><emphasis>
-                    <ulink url='&YOCTO_HOME_URL;/download/yocto/yocto-project-&DISTRO;-release-notes-poky-&POKYVERSION;'>
-                    Release Notes</ulink>:</emphasis> Features, updates and known issues for the current
+                    <ulink url='&YOCTO_HOME_URL;/download/yocto/yocto-project-&DISTRO;-release-notes-poky-&POKYVERSION;'>Release Notes</ulink>:</emphasis> Features, updates and known issues for the current
                     release of the Yocto Project.</para></listitem>
                 <listitem><para><emphasis>
                     <ulink url='&YOCTO_HOME_URL;/tools-resources/projects/hob'>

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

@@ -17,6 +17,9 @@
              For an example on how to create a BSP, see the
              "<ulink url='&YOCTO_DOCS_BSP_URL;#creating-a-new-bsp-layer-using-the-yocto-bsp-script'>Creating a New BSP Layer Using the yocto-bsp Script</ulink>"
              section in the Yocto Project Board Support Package (BSP) Developer's Guide.
+             For more complete information on how to work with the kernel, see the
+             <ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;'>Yocto Project Linux Kernel
+             Development Manual</ulink>.
              </para></listitem>
          <listitem><para><emphasis>User Application Development:</emphasis>
              User Application Development covers development of applications that you intend
@@ -79,9 +82,15 @@
         </note>
 
         <para>
-            The remainder of this section presents the basic steps used to create a BSP
-            using the Yocto Project's
+            The remainder of this section presents the basic
+            steps used to create a BSP using the Yocto Project's
             <ulink url='&YOCTO_DOCS_BSP_URL;#using-the-yocto-projects-bsp-tools'>BSP Tools</ulink>.
+            Although not required for BSP creation, the
+            <filename>meta-intel</filename> repository, which contains
+            many BSPs supported by the Yocto Project, is part of the example.
+        </para>
+
+        <para>
             For an example that shows how to create a new layer using the tools, see the
             "<ulink url='&YOCTO_DOCS_BSP_URL;#creating-a-new-bsp-layer-using-the-yocto-bsp-script'>Creating a New BSP Layer Using the yocto-bsp Script</ulink>"
              section in the Yocto Project Board Support Package (BSP) Developer's Guide.
@@ -99,7 +108,7 @@
             <orderedlist>
                 <listitem><para><emphasis>Set up your host development system to support
                     development using the Yocto Project</emphasis>:  See the
-                    "<ulink url='&YOCTO_DOCS_QS_URL;#the-linux-distro'>The Linux Distributions</ulink>"
+                    "<ulink url='&YOCTO_DOCS_QS_URL;#the-linux-distro'>The Linux Distribution</ulink>"
                     and the
                     "<ulink url='&YOCTO_DOCS_QS_URL;#packages'>The Packages</ulink>" sections both
                     in the Yocto Project Quick Start for requirements.</para></listitem>
@@ -110,11 +119,12 @@
                     process and to the tools you need.
                     For information on how to set up the
                     <link linkend='source-directory'>Source Directory</link>, see the
-                    "<link linkend='getting-setup'>Getting Setup</link>" section.</para></listitem>
+                    "<link linkend='getting-setup'>Getting Set up</link>" section.</para></listitem>
                 <listitem><para><emphasis>Establish the <filename>meta-intel</filename>
-                    repository on your system</emphasis>:  Having local copies of the
-                    supported BSP layers on your system gives you access to the build
-                    process and to the tools you need for creating a BSP.
+                    repository on your system</emphasis>:  Having local copies
+                    of these supported BSP layers on your system gives you
+                    access to layers you might be able to build on or modify
+                    to create your BSP.
                     For information on how to get these files, see the
                     "<link linkend='getting-setup'>Getting Setup</link>" section.</para></listitem>
                 <listitem><para><emphasis>Create your own BSP layer using the
@@ -230,13 +240,13 @@
         <para>
             The remainder of this section presents a high-level overview of the Yocto Project
             kernel architecture and the steps to modify the kernel.
-            For a complete discussion of the kernel, see the
-            <ulink url='&YOCTO_DOCS_KERNEL_URL;'>Yocto Project Kernel Architecture and Use Manual</ulink>.
             You can reference the
             "<link linkend='patching-the-kernel'>Patching the Kernel</link>" section
             for an example that changes the source code of the kernel.
             For information on how to configure the kernel, see the
             "<link linkend='configuring-the-kernel'>Configuring the Kernel</link>" section.
+            For more information on the kernel and on modifying the kernel, see the
+            <ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;'>Yocto Project Linux Kernel Development Manual</ulink>.
         </para>
 
         <section id='kernel-overview'>
@@ -245,7 +255,7 @@
             <para>
                 Traditionally, when one thinks of a patched kernel, they think of a base kernel
                 source tree and a fixed structure that contains kernel patches.
-                The Yocto Project, however, employs mechanisms, that in a sense, result in a kernel source
+                The Yocto Project, however, employs mechanisms that, in a sense, result in a kernel source
                 generator.
                 By the end of this section, this analogy will become clearer.
             </para>
@@ -328,7 +338,7 @@
                 Conceptually, you can think of the kernel source repositories as all the
                 source files necessary for all the supported kernels.
                 As a developer, you are just interested in the source files for the kernel on
-                on which you are working.
+                which you are working.
                 And, furthermore, you need them available on your host system.
             </para>
 
@@ -366,9 +376,9 @@
             </para>
 
             <para>
-                Again, for a complete discussion of the Yocto Project kernel's architecture and its
-                branching strategy, see the
-                <ulink url='&YOCTO_DOCS_KERNEL_URL;'>Yocto Project Kernel Architecture and Use Manual</ulink>.
+                Again, for additional information the Yocto Project kernel's
+                architecture and its branching strategy, see the
+                <ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;'>Yocto Project Linux Kernel Development Manual</ulink>.
                 You can also reference the
                 "<link linkend='patching-the-kernel'>Patching the Kernel</link>"
                 section for a detailed example that modifies the kernel.
@@ -391,7 +401,7 @@
                 <orderedlist>
                     <listitem><para><emphasis>Set up your host development system to support
                         development using the Yocto Project</emphasis>:  See
-                        "<ulink url='&YOCTO_DOCS_QS_URL;#the-linux-distro'>The Linux Distributions</ulink>" and
+                        "<ulink url='&YOCTO_DOCS_QS_URL;#the-linux-distro'>The Linux Distribution</ulink>" and
                         "<ulink url='&YOCTO_DOCS_QS_URL;#packages'>The Packages</ulink>" sections both
                         in the Yocto Project Quick Start for requirements.</para></listitem>
                     <listitem><para><emphasis>Establish a local copy of project files on your
@@ -445,7 +455,7 @@
                         Doing so, can produce unexpected results when the OpenEmbedded build system
                         regenerates the configuration file.</para>
                         <para>Once you are satisfied with the configuration changes made using
-                        <filename>menuconfig</filename>, you can directly examine the
+                        <filename>menuconfig</filename>, you can directly compare the
                         <filename>.config</filename> file against a saved original and gather those
                         changes into a config fragment to be referenced from within the kernel's
                         <filename>.bbappend</filename> file.</para></listitem>
@@ -503,11 +513,11 @@
             <orderedlist>
                 <listitem><para><emphasis>Prepare the Host System for the Yocto Project</emphasis>:
                     See
-                    "<ulink url='&YOCTO_DOCS_QS_URL;#the-linux-distro'>The Linux Distributions</ulink>" and
+                    "<ulink url='&YOCTO_DOCS_QS_URL;#the-linux-distro'>The Linux Distribution</ulink>" and
                     "<ulink url='&YOCTO_DOCS_QS_URL;#packages'>The Packages</ulink>" sections both
                     in the Yocto Project Quick Start for requirements.</para></listitem>
                 <listitem><para><emphasis>Secure the Yocto Project Kernel Target Image</emphasis>:
-                    You must have a target kernel image that has been built using the OpenEmbeded
+                    You must have a target kernel image that has been built using the OpenEmbedded
                     build system.</para>
                     <para>Depending on whether the Yocto Project has a pre-built image that matches your target
                     architecture and where you are going to run the image while you develop your application
@@ -517,7 +527,7 @@
                                 <ulink url='&YOCTO_MACHINES_DL_URL;'><filename>machines</filename></ulink>
                                 if your target architecture is supported and you are going to develop
                                 and test your application on actual hardware.</para></listitem>
-                            <listitem><para>Download the image from the
+                            <listitem><para>Download the image from
                                 <ulink url='&YOCTO_QEMU_DL_URL;'>
                                 <filename>machines/qemu</filename></ulink> if your target architecture is supported
                                 and you are going to develop and test your application using the QEMU
@@ -1272,7 +1282,11 @@ directory.</para></listitem>
                         host can use, you must have <filename>oprofile</filename> version 0.9.4 or
                         greater installed on the host.</para>
                         <para>You can locate both the viewer and server from
-                        <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/oprofileui/'></ulink>.
+                        <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/oprofileui/'></ulink>
+                        You can also find more information on setting up and
+                        using this tool in the
+                        "<ulink url='&YOCTO_DOCS_PROF_URL;#profile-manual-oprofile'>OProfile</ulink>"
+                        section of the Yocto Project Profiling and Tracing Manual.
                         <note>The <filename>oprofile-server</filename> is installed by default on
                         the <filename>core-image-sato-sdk</filename> image.</note></para></listitem>
                     <listitem><para><emphasis><filename>Lttng2.0 ust trace import</filename>:</emphasis>
@@ -1331,7 +1345,12 @@ directory.</para></listitem>
                         performance counter registers.
                         Selecting either of these tools causes an RSE terminal view to appear
                         from which you can run the tools.
-                        Both tools refresh the entire screen to display results while they run.</para></listitem>
+                        Both tools refresh the entire screen to display results while they run.
+                        For more informationi on setting up and using <filename>perf</filename>,
+                        see the
+                        "<ulink url='&YOCTO_DOCS_PROF_URL;#profile-manual-perf'>perf</ulink>"
+                        section in the Yocto Project Profiling and Tracing Manual.
+                        </para></listitem>
                 </itemizedlist>
             </para>
         </section>
@@ -1429,45 +1448,57 @@ directory.</para></listitem>
         <title>Workflow Using Stand-alone Cross-development Toolchains</title>
 
         <para>
-            If you want to develop an application without prior installation of the ADT, you
-            still can employ the cross-development toolchain, the QEMU emulator, and a number of supported
-            target image files.
+            If you want to develop an application without prior installation
+            of the ADT, you still can employ the
+            <link linkend='cross-development-toolchain'>Cross Development Toolchain</link>,
+            the QEMU emulator, and a number of supported  target image files.
             You just need to follow these general steps:
             <orderedlist>
-                <listitem><para><emphasis>Install the cross-development toolchain for your target hardware:</emphasis>
+                <listitem><para><emphasis>Install the cross-development
+                    toolchain for your target hardware:</emphasis>
                     For information on how to install the toolchain, see the
                     "<ulink url='&YOCTO_DOCS_ADT_URL;#using-an-existing-toolchain-tarball'>Using a Cross-Toolchain Tarball</ulink>"
-                    section
-                    in the Yocto Project Application Developer's Guide.</para></listitem>
-                <listitem><para><emphasis>Download the Target Image:</emphasis>  The Yocto Project supports
-                    several target architectures and has many pre-built kernel images and root filesystem
+                    section in the Yocto Project Application Developer's
+                    Guide.</para></listitem>
+                <listitem><para><emphasis>Download the Target Image:</emphasis>
+                    The Yocto Project supports several target architectures
+                    and has many pre-built kernel images and root filesystem
                     images.</para>
-                    <para>If you are going to develop your application on hardware, go to the
+                    <para>If you are going to develop your application on
+                    hardware, go to the
                     <ulink url='&YOCTO_MACHINES_DL_URL;'><filename>machines</filename></ulink>
                     download area and choose a target machine area
                     from which to download the kernel image and root filesystem.
-                    This download area could have several files in it that support development using
-                    actual hardware.
-                    For example, the area might contain <filename>.hddimg</filename> files that combine the
+                    This download area could have several files in it that
+                    support development using actual hardware.
+                    For example, the area might contain
+                    <filename>.hddimg</filename> files that combine the
                     kernel image with the filesystem, boot loaders, etc.
-                    Be sure to get the files you need for your particular development process.</para>
-                    <para>If you are going to develop your application and then run and test it using the QEMU
-                    emulator, go to the
+                    Be sure to get the files you need for your particular
+                    development process.</para>
+                    <para>If you are going to develop your application and
+                    then run and test it using the QEMU emulator, go to the
                     <ulink url='&YOCTO_QEMU_DL_URL;'><filename>machines/qemu</filename></ulink>
                     download area.
-                    From this area, go down into the directory for your target architecture
-                    (e.g. <filename>qemux86_64</filename> for an
-                    <trademark class='registered'>Intel</trademark>-based 64-bit architecture).
-                    Download kernel, root filesystem, and any other files you need for your process.
-                    <note>In order to use the root filesystem in QEMU, you need to extract it.
+                    From this area, go down into the directory for your
+                    target architecture (e.g. <filename>qemux86_64</filename>
+                    for an <trademark class='registered'>Intel</trademark>-based
+                    64-bit architecture).
+                    Download kernel, root filesystem, and any other files you
+                    need for your process.
+                    <note>In order to use the root filesystem in QEMU, you
+                    need to extract it.
                     See the
                     "<ulink url='&YOCTO_DOCS_ADT_URL;#extracting-the-root-filesystem'>Extracting the Root Filesystem</ulink>"
-                    section for information on how to extract the root filesystem.</note></para></listitem>
-                <listitem><para><emphasis>Develop and Test your Application:</emphasis>  At this point,
-                    you have the tools to develop your application.
-                    If you need to separately install and use the QEMU emulator, you can go to
-                    <ulink url='http://www.qemu.org'>QEMU Home Page</ulink> to download and learn about the
-                    emulator.</para></listitem>
+                    section for information on how to extract the root
+                    filesystem.</note></para></listitem>
+                <listitem><para><emphasis>Develop and Test your
+                    Application:</emphasis>  At this point, you have the tools
+                    to develop your application.
+                    If you need to separately install and use the QEMU
+                    emulator, you can go to
+                    <ulink url='http://wiki.qemu.org/Main_Page'>QEMU Home Page</ulink>
+                    to download and learn about the emulator.</para></listitem>
             </orderedlist>
         </para>
     </section>
@@ -1825,7 +1856,7 @@ directory.</para></listitem>
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink>
                 for which you are building the image.</para></listitem>
             <listitem><para>You can modify various policy settings such as the package format used to build with,
-                the parrallelism BitBake uses, whether or not to build an external toolchain, and which host
+                the parallelism BitBake uses, whether or not to build an external toolchain, and which host
                 to build against.</para></listitem>
             <listitem><para>You can manage
                 <link linkend='understanding-and-creating-layers'>layers</link>.</para></listitem>

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

@@ -58,99 +58,321 @@
     <title>Using the Yocto Project in a Team Environment</title>
 
     <para>
-        It might not be immediately clear how you can use the Yocto Project in a team environment,
-        or scale it for a large team of developers.
-        The specifics of any situation determine the best solution.
-        Granted that the Yocto Project offers immense flexibility regarding this, practices do exist
-        that experience has shown work well.
+        It might not be immediately clear how you can use the Yocto
+        Project in a team environment, or scale it for a large team of
+        developers.
+        One of the strengths of the Yocto Project is that it is extremely
+        flexible.
+        Thus, you can adapt it to many different use cases and scenarios.
+        However, these characteristics can cause a struggle if you are trying
+        to create a working setup that scales across a large team.
+        To help with these types of situations, this section presents
+        some of the project's most successful experiences,
+        practices, solutions, and available technologies that work well.
+        Keep in mind, the information here is a starting point.
+        You can build off it and customize it to fit any
+        particular working environment and set of practices.
     </para>
 
-    <para>
-        The core component of any development effort with the Yocto Project is often an
-        automated build and testing framework along with an image generation process.
-        You can use these core components to check that the metadata can be built,
-        highlight when commits break the build, and provide up-to-date images that
-        allow developers to test the end result and use it as a base platform for further
-        development.
-        Experience shows that buildbot is a good fit for this role.
-        What works well is to configure buildbot to make two types of builds:
-        incremental and full (from scratch).
-        See "<ulink url='http://autobuilder.yoctoproject.org:8010/'>Welcome to the buildbot for the Yocto Project</ulink>"
-        for an example implementation that uses buildbot.
-    </para>
+    <section id='best-practices-system-configurations'>
+        <title>System Configurations</title>
 
-    <para>
-        You can tie an incremental build to a commit hook that triggers the build
-        each time a commit is made to the metadata.
-        This practice results in useful acid tests that determine whether a given commit
-        breaks the build in some serious way.
-        Associating a build to a commit can catch a lot of simple errors.
-        Furthermore, the tests are fast so developers can get quick feedback on changes.
-    </para>
+        <para>
+            Systems across a large team should meet the needs of
+            two types of developers: those working on the direction of the
+            software stack itself and those developing applications.
+            Regardless of the type of developer, their workstations must
+            be both reasonably powerful and run Linux.
+        </para>
 
-    <para>
-        Full builds build and test everything from the ground up.
-        These types of builds usually happen at predetermined times like during the
-        night when the machine load is low.
-    </para>
+        <section id='best-practices-application-development'>
+            <title>Application Development</title>
 
-    <para>
-        Most teams have many pieces of software undergoing active development at any given time.
-        You can derive large benefits by putting these pieces under the control of a source
-        control system that is compatible (i.e. Git or Subversion (SVN)) with the OpenEmbedded
-        build system that the Yocto Project uses.
-        You can then set the autobuilder to pull the latest revisions of the packages
-        and test the latest commits by the builds.
-        This practice quickly highlights issues.
-        The build system easily supports testing configurations that use both a
-        stable known good revision and a floating revision.
-        The build system can also take just the changes from specific source control branches.
-        This capability allows you to track and test specific changes.
-    </para>
+            <para>
+                For developers who mainly do application level work
+                on top of an existing software stack,
+                here are some practices that work best:
+                <itemizedlist>
+                    <listitem><para>Use a pre-built toolchain that
+                        contains the software stack itself.
+                        Then, develop the application code on top of the
+                        stack.
+                        This method works well for small numbers of relatively
+                        isolated applications.</para></listitem>
+                    <listitem><para>When possible, use the Yocto Project
+                        plug-in for the <trademark class='trade'>Eclipse</trademark> IDE
+                        and other pieces of Application Development
+                        Technology (ADT).
+                        For more information, see the
+                        "<link linkend='application-development-workflow'>Application
+                        Development Workflow</link>" section as well as the
+                        <ulink url='&YOCTO_DOCS_ADT_URL;'>Yocto Project Application Developer's Guide</ulink>.
+                        </para></listitem>
+                    <listitem><para>Keep your cross-development toolchains
+                        updated.
+                        You can do this by provisioning either as new
+                        toolchain downloads or as updates through a package
+                        update mechanism using <filename>opkg</filename>
+                        to provide updates to an existing toolchain.
+                        The exact mechanics of how and when to do this are a
+                        question for local policy.</para></listitem>
+                    <listitem><para>Use multiple toolchains installed locally
+                        into different locations to allow development across
+                        versions.</para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
 
-    <para>
-        Perhaps the hardest part of setting this up is defining the software project or
-        the metadata policies that surround the different source control systems.
-        Of course circumstances will be different in each case.
-        However, this situation reveals one of the Yocto Project's advantages -
-        the system itself does not
-        force any particular policy on users, unlike a lot of build systems.
-        The system allows the best policies to be chosen for the given circumstances.
-    </para>
+        <section id='best-practices-core-system-development'>
+            <title>Core System Development</title>
 
-    <para>
-        In general, best practices exist that make your work with the Yocto
-        Project easier in a team environment.
-        This list presents some of these practices you might consider following.
-        Of course, you need to understand that you do not have to follow these
-        practices and your setup can be totally controlled and customized by
-        your team:
-        <itemizedlist>
-            <listitem><para>Use <link linkend='git'>Git</link>
-                as the source control system.</para></listitem>
-            <listitem><para>Maintain your metadata in layers that make sense
-                for your situation.
-                See the "<link linkend='understanding-and-creating-layers'>Understanding
-                and Creating Layers</link>" section for more information on
-                layers.</para></listitem>
-            <listitem><para>Separate the project's metadata and code by using
-                separate Git repositories.
-                See the "<link linkend='yocto-project-repositories'>Yocto Project
-                Source Repositories</link>" section for information on these
-                repositories.
-                See the "<link linkend='getting-setup'>Getting Set Up</link>" section
-                for information on how to set up various Yocto Project related
-                Git repositories.</para></listitem>
-            <listitem><para>Set up the directory for the shared state cache
-                (<ulink url='&YOCTO_DOCS_REF_URL;#var-SSTATE_DIR'><filename>SSTATE_DIR</filename></ulink>)
-                where they make sense.
-                For example, set up the sstate cache for developers using the
-                same office and share source directories on the developer's
-                machines.</para></listitem>
-            <listitem><para>Set up an autobuilder and have it populate the
-                sstate cache and source directories.</para></listitem>
-        </itemizedlist>
-    </para>
+            <para>
+                For core system development, it is often best to have the
+                build system itself available on the developer workstations
+                so developers can run their own builds and directly
+                rebuild the software stack.
+                You should keep the core system standard as much as
+                possible and do your work in layers on top of the core system.
+                You can share layers amongst the developers of a particular
+                project and contain the policy configuration that defines
+                the project.
+            </para>
+
+            <para>
+                Aside from the previous best practices, there exists a number
+                of tips and tricks that can help speed up core development
+                projects:
+                <itemizedlist>
+                    <listitem><para>Use a
+                        <ulink url='&YOCTO_DOCS_REF_URL;#shared-state-cache'>Shared State Cache</ulink>
+                        (sstate) among groups of developers who are on a
+                        fast network.
+                        The best way to share sstate is through a
+                        Network File System (NFS) share.
+                        The first user to build a given component for the
+                        first time contributes that object to the sstate,
+                        while subsequent builds from other developers then
+                        reuse the object rather than rebuild it themselves.
+                        </para>
+                        <para>Although it is possible to use other protocols for the
+                        sstate such as HTTP and FTP, you should avoid these.
+                        Using HTTP limits the sstate to read-only and
+                        FTP provides poor performance.
+                        </para></listitem>
+                    <listitem><para>Have autobuilders contribute to the sstate
+                        pool similarly to how the developer workstations
+                        contribute.
+                        For information, see the
+                        <link linkend='best-practices-autobuilders'>Autobuilders</link>
+                        section.</para></listitem>
+                    <listitem><para>Build stand-alone tarballs that contain
+                        "missing" system requirements if for some reason
+                        developer workstations do not meet minimum system
+                        requirements such as latest Python versions,
+                        <filename>chrpath</filename>, or other tools.
+                        You can install and relocate the tarball exactly as you
+                        would the usual cross-development toolchain so that
+                        all developers can meet minimum version requirements
+                        on most distributions.</para></listitem>
+                    <listitem><para>Use a small number of high performance
+                        systems for testing purposes (e.g. dual six core Xeons
+                        with 24GB RAM and plenty of disk space).
+                        Developers can use these systems for wider, more
+                        extensive testing while they continue to develop
+                        locally using their primary development system.
+                        </para></listitem>
+                </itemizedlist>
+            </para>
+        </section>
+    </section>
+
+    <section id='best-practices-source-control-management'>
+        <title>Source Control Manangement (SCM)</title>
+
+        <para>
+            Keeping your
+            <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
+            and any software you are developing under the
+            control of an SCM system that is compatible
+            with the OpenEmbedded build system is adviseable.
+            Of the two SCMs available (Git or Subversion), the
+            Yocto Project team strongly recommends using
+            <link linkend='git'>Git</link>.
+            Git is a distributed system that is easy to backup
+            (each checkout is a backup in itself), allows you to work
+            remotely, and then connect back to the infrastructue.
+        </para>
+
+        <para>
+            It is relatively easy to set up Git services and create
+            infrastructure like
+            <ulink url='&YOCTO_GIT_URL;'>http://git.yoctoproject.org</ulink>,
+            which is based on server software called
+            <filename>gitolite</filename> with <filename>cgit</filename>
+            being used to generate the web interface that lets you view the
+            repositories.
+            The <filename>gitlite</filename> software identifies users
+            using <filename>ssh</filename> keys and allows branch-based
+            access controls to repositories that you can control as little
+            or as much as necessary.
+        </para>
+
+        <note>
+            The setup of these services is beyond the scope of this manual.
+            However, sites such as these exist that describe how to perform
+            setup:
+            <itemizedlist>
+                <listitem><para><ulink url='http://git-scm.com/book/ch4-8.html'>Git documentation</ulink>:
+                    Describes how to install <filename>gitolite</filename>
+                    on the server.</para></listitem>
+                <listitem><para><ulink url='http://sitaramc.github.com/gitolite/master-toc.html'>The <filename>gitolite</filename> master index</ulink>:
+                    All topics for <filename>gitolite</filename>.
+                    </para></listitem>
+                <listitem><para><ulink url='http://hjemli.net/git/cgit/tree/README'><filename>cgit</filename> index</ulink>:
+                    A <filename>README</filename> file on how to create a
+                    fast web interface for Git.</para></listitem>
+            </itemizedlist>
+        </note>
+    </section>
+
+    <section id='best-practices-autobuilders'>
+        <title>Autobuilders</title>
+
+        <para>
+            Autobuilders are often the core of a development project.
+            It is here that changes from individual developers are brought
+            together and centrally tested and subsequent decisions about
+            releases can be made.
+            Autobuilders also allow for "continuous integration" style
+            testing of software components and regression identification
+            and tracking.
+        </para>
+
+        <para>
+            See "<ulink url='http://autobuilder.yoctoproject.org:8010/'>Welcome to the buildbot for the Yocto Project</ulink>"
+            for the Yocto Project's reference implementation that uses
+            buildbot.
+            The Yocto Project team has found this implementation
+            works well in this role.
+            A public example of this is the Yocto Project
+            Autobuilders, which we use to test the overall health of the
+            project.
+        </para>
+
+        <para>
+            The features of this system are:
+            <itemizedlist>
+                <listitem><para>Highlights when commits break the build
+                    </para></listitem>
+                <listitem><para>Populates an sstate cache from which
+                    developers can pull rather than requiring local
+                    builds</para></listitem>
+                <listitem><para>Allows commit hook triggers,
+                    which trigger builds when commits are made
+                    </para></listitem>
+                <listitem><para>Allows triggering of automated image booting
+                    and testing under the QuickEMUlator (QEMU)
+                    </para></listitem>
+                <listitem><para>Supports incremental build testing and from
+                    scratch builds</para></listitem>
+                <listitem><para>Shared output that allows developer
+                    testing and historical regression investigation
+                    </para></listitem>
+                <listitem><para>Creates output that can be use for releases
+                    </para></listitem>
+                <listitem><para>Allows scheduling of builds so that resources
+                    can be used efficiently.</para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='best-practices-policies-and-change-flow'>
+        <title>Policies and Change Flow</title>
+
+        <para>
+            The Yocto Project itself uses a hierarchy structure and a
+            pull model.
+            Scripts exist to create and send pull requests
+            (i.e. <filename>create-pull-request</filename> and
+            <filename>send-pull-request</filename>).
+            This model is in line with other open source projects where
+            maintainers are responsible for specific areas of the project
+            and a single maintainer handles the final top-of-tree merges.
+        </para>
+
+        <note>
+            You can also use a more collective push model.
+            The <filename>gitolite</filename> software supports both the
+            push and pull models quite easily.
+        </note>
+
+        <para>
+            As with any development environment, it is important
+            to document the policy used as well as any main project
+            guidelines so they are understoon by everyone.
+            It is also a good idea to have well structured
+            commit messages, which are usually a part of a project's
+            guidelines.
+            Good commit messages are essential when looking back in time and
+            trying to understand why changes were made.
+        </para>
+
+        <para>
+            If you discover that changes are needed to the core layer of the
+            project, it is worth sharing those with the community as soon
+            as possible.
+            Chances are if you have discovered the need for changes, someone
+            someone else in the community needs them also.
+            sooner than later.
+        </para>
+    </section>
+
+    <section id='best-practices-summary'>
+        <title>Summary</title>
+
+        <para>
+            This section summarizes thee key recommendations described in the
+            previous sections:
+            <itemizedlist>
+                <listitem><para>Use <link linkend='git'>Git</link>
+                    as the source control system.</para></listitem>
+                <listitem><para>Maintain your metadata in layers that make sense
+                    for your situation.
+                    See the "<link linkend='understanding-and-creating-layers'>Understanding
+                    and Creating Layers</link>" section for more information on
+                    layers.</para></listitem>
+                <listitem><para>Separate the project's metadata and code by using
+                    separate Git repositories.
+                    See the "<link linkend='yocto-project-repositories'>Yocto Project
+                    Source Repositories</link>" section for information on these
+                    repositories.
+                    See the "<link linkend='getting-setup'>Getting Set Up</link>" section
+                    for information on how to set up various Yocto Project related
+                    Git repositories.</para></listitem>
+                <listitem><para>Set up the directory for the shared state cache
+                    (<ulink url='&YOCTO_DOCS_REF_URL;#var-SSTATE_DIR'><filename>SSTATE_DIR</filename></ulink>)
+                    where they make sense.
+                    For example, set up the sstate cache for developers using the
+                    same office and share source directories on the developer's
+                    machines.</para></listitem>
+                <listitem><para>Set up an autobuilder and have it populate the
+                    sstate cache and source directories.</para></listitem>
+                <listitem><para>Follow the project commit guidelines for
+                    writing good commit messages.
+                    See the "<link linkend='how-to-submit-a-change'>How to Submit a Change</link>"
+                    section.</para></listitem>
+                <listitem><para>Send changes to the core sooner than later
+                    as others likely run into the same issues.
+                    For some guidance on mailing lists to use, see the list in the
+                    "<link linkend='how-to-submit-a-change'>How to Submit a Change</link>"
+                    section.
+                    For a description of the available mailing lists, see
+                    "<ulink url='&YOCTO_DOCS_REF_URL;#resources-mailinglist'>Mailing Lists</ulink>"
+                    section in the Yocto Project Reference Manual.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
 </section>
 
 <section id='yocto-project-repositories'>
@@ -311,17 +533,61 @@
                 variables for the Texas Instruments ARM Cortex-A8 development board).
                 Configuration files end with a <filename>.conf</filename> filename extension.
                 </para></listitem>
-            <listitem><para><emphasis>Cross-Development Toolchain:</emphasis>
+            <listitem><para id='cross-development-toolchain'>
+                <emphasis>Cross-Development Toolchain:</emphasis>
                 A collection of software development
-                tools and utilities that allow you to develop software for targeted architectures.
-                This toolchain contains cross-compilers, linkers, and debuggers that are specific to
-                an architecture.
-                You can use the OpenEmbedded build system to build a cross-development toolchain
-                installer that when run installs the toolchain that contains the development tools you
+                tools and utilities that allow you to develop software for
+                targeted architectures.
+                This toolchain contains cross-compilers, linkers, and debuggers
+                that are specific to an architecture.
+                You can use the OpenEmbedded build system to build a
+                cross-development toolchain installer that, when run, installs
+                the toolchain that contains the development tools you
                 need to cross-compile and test your software.
                 The Yocto Project ships with images that contain installers for
                 toolchains for supported architectures as well.
-                Sometimes this toolchain is referred to as the meta-toolchain.</para></listitem>
+                Sometimes this toolchain is referred to as the
+                meta-toolchain.</para>
+                <para>Following is a list of toolchain recipes with brief
+                descriptions of each:
+                <itemizedlist>
+                    <listitem><para><filename>gcc-cross-initial</filename>:
+                        The initial compiler needed to bootstrap the toolchain
+                        that runs on the host and is used to build software
+                        for the target.
+                        This tool is a 'native' package.</para></listitem>
+                    <listitem><para><filename>gcc-cross-intermediate</filename>:
+                        The second stage of the bootstrap process that runs
+                        on the host and builds software for the target.
+                        This tool is a 'native' package.</para></listitem>
+                    <listitem><para><filename>gcc-cross</filename>:
+                        The the final stage of the bootstrap process that
+                        results in the cross compiler that runs on the host
+                        and builds software for the target.
+                        If you are replacing the cross compiler toolchain
+                        with a custom version, this is what you must replace.
+                        This tool is a 'native' package.</para></listitem>
+                    <listitem><para><filename>gcc-runtime</filename>:
+                        Runtime libraries from the toolchain bootstrapping
+                        process.
+                        This tool produces a binary for the target.
+                        </para></listitem>
+                    <listitem><para><filename>gcc-crosssdk-initial/intermediate</filename>:
+                        Stage 1 and 2 of the a cross compiler that runs on the
+                        host and builds for the SDK.
+                        Often the SDK is not the same target as the host.
+                        This tool is a 'native' binary.</para></listitem>
+                    <listitem><para><filename>gcc-crosssdk</filename>:
+                        The final stage of the SDK compiler.
+                        This tool is a 'native' binary.
+                        The tool runs on the host and builds for the SDK.
+                        </para></listitem>
+                    <listitem><para><filename>gcc-cross-canadian</filename>:
+                        The compiler that runs on the SDK machine and is
+                        included with the SDK that builds software for the
+                        target.
+                        This tool is a 'nativesdk' package.</para></listitem>
+                </itemizedlist></para></listitem>
             <listitem><para><emphasis>Image:</emphasis> An image is the result produced when
                 BitBake processes a given collection of recipes and related metadata.
                 Images are the binary output that run on specific hardware or QEMU
@@ -334,9 +600,14 @@
                 For a discussion on BSP Layers, see the
                 "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-layers'>BSP Layers</ulink>"
                 section in the Yocto Project Board Support Packages (BSP) Developer's Guide.</para></listitem>
-            <listitem><para id='metadata'><emphasis>Metadata:</emphasis> The files that BitBake parses when
-                building an image.
-                Metadata includes recipes, classes, and configuration files.</para></listitem>
+            <listitem><para id='metadata'><emphasis>Metadata:</emphasis>
+                The files that BitBake parses when building an image.
+                In general, Metadata includes recipes, classes, and
+                configuration files.
+                In the context of the kernel ("kernel Metadata"),
+                it refers to metadata in the <filename>meta</filename>
+                branches of the kernel source Git repositories.
+                </para></listitem>
             <listitem><para id='oe-core'><emphasis>OE-Core:</emphasis> A core set of metadata originating
                 with OpenEmbedded (OE) that is shared between OE and the Yocto Project.
                 This metadata is found in the <filename>meta</filename> directory of the source

documentation/dev-manual/dev-manual.xml

@@ -16,7 +16,9 @@
             </imageobject>
         </mediaobject>
 
-        <title></title>
+        <title>
+            Yocto Project Development Manual
+        </title>
 
         <authorgroup>
             <author>

documentation/kernel-dev/kernel-dev-advanced.xml

@@ -82,10 +82,10 @@
         The linux-yocto style recipes can optionally define the following
         variables:
         <literallayout class='monospaced'>
-     KBRANCH
-     KERNEL_FEATURES
-     KBRANCH_DEFAULT
-     LINUX_KERNEL_TYPE
+     <ulink url='&YOCTO_DOCS_REF_URL;#var-KBRANCH'>KBRANCH</ulink>
+     <ulink url='&YOCTO_DOCS_REF_URL;#var-KERNEL_FEATURES'>KERNEL_FEATURES</ulink>
+     <ulink url='&YOCTO_DOCS_REF_URL;#var-KBRANCH_DEFAULT'>KBRANCH_DEFAULT</ulink>
+     <ulink url='&YOCTO_DOCS_REF_URL;#var-LINUX_KERNEL_TYPE'>LINUX_KERNEL_TYPE</ulink>
         </literallayout>
         <filename>KBRANCH_DEFAULT</filename> defines the Linux kernel source
         repository's default branch to use to build the Linux kernel.
@@ -104,7 +104,8 @@
         used in assembling the configuration.
         If you do not specify a <filename>LINUX_KERNEL_TYPE</filename>,
         it defaults to "standard".
-        Together with <filename>KMACHINE</filename>,
+        Together with
+        <ulink url='&YOCTO_DOCS_REF_URL;#var-KMACHINE'><filename>KMACHINE</filename></ulink>,
         <filename>LINUX_KERNEL_TYPE</filename> defines the search
         arguments used by the kernel tools to find the
         appropriate description within the kernel Metadata with which to
@@ -139,7 +140,8 @@
         then for the <filename>LINUX_KERNEL_TYPE</filename>.
         If the tools cannot find a partial match, they will use the
         sources from the <filename>KBRANCH</filename> and any configuration
-        specified in the <filename>SRC_URI</filename>.
+        specified in the
+        <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>.
     </para>
 
     <para>
@@ -394,19 +396,20 @@
         description files within the structure:
         <itemizedlist>
             <listitem><para>If your file contains
-                only configuration fragments, place the file in
-                <filename>cfg</filename>.</para></listitem>
+                only configuration fragments, place the file in the
+                <filename>cfg</filename> directory.</para></listitem>
             <listitem><para>If your file contains
-                only source-code fixes, place the file in
-                <filename>patches</filename>.</para></listitem>
+                only source-code fixes, place the file in the
+                <filename>patches</filename> directory.</para></listitem>
             <listitem><para>If your file encapsulates
                 a major feature, often combining sources and configurations,
-                place the file in <filename>features</filename>.
+                place the file in <filename>features</filename> directory.
                 </para></listitem>
             <listitem><para>If your file aggregates
                 non-hardware configuration and patches in order to define a
                 base kernel policy or major kernel type to be reused across
-                multiple BSPs, place the file in <filename>ktypes</filename>.
+                multiple BSPs, place the file in <filename>ktypes</filename>
+                directory.
                 </para></listitem>
         </itemizedlist>
     </para>
@@ -466,8 +469,8 @@
         </para>
 
         <para>
-            <filename>KFEATURE_DESCRIPTION</filename> provides a short
-            description of the fragment.
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-KFEATURE_DESCRIPTION'><filename>KFEATURE_DESCRIPTION</filename></ulink>
+            provides a short description of the fragment.
             Higher level kernel tools use this description.
         </para>
 
@@ -653,7 +656,8 @@
             It is not strictly necessary to create a kernel type
             <filename>.scc</filename> file.
             The Board Support Package (BSP) file can implicitly define
-            the kernel type using a <filename>define KTYPE myktype</filename>
+            the kernel type using a <filename>define
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-KTYPE'>KTYPE</ulink> myktype</filename>
             line.
             See the "<link linkend='bsp-descriptions'>BSP Descriptions</link>"
             section for more information.
@@ -680,13 +684,15 @@
         kconf mybsp.cfg
             </literallayout>
             Every BSP description should define the
-            <filename>KMACHINE</filename>, <filename>KTYPE</filename>,
-            and <filename>KARCH</filename> variables.
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-KMACHINE'><filename>KMACHINE</filename></ulink>,
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-KTYPE'><filename>KTYPE</filename></ulink>,
+            and <ulink url='&YOCTO_DOCS_REF_URL;#var-KARCH'><filename>KARCH</filename></ulink>
+            variables.
             These variables allow the OpenEmbedded build system to identify
             the description as meeting the criteria set by the recipe being
             built.
             This simple example supports the "mybsp" machine for the "standard"
-            kernel and the 'i386" architecture.
+            kernel and the "i386" architecture.
         </para>
 
         <para>
@@ -695,9 +701,9 @@
             description file does not exist.
             Thus, if you do not have kernel types defined in your kernel
             Metadata, you only need to ensure that the kernel recipe's
-            <filename>LINUX_KERNEL_TYPE</filename> variable and the
-            <filename>KTYPE</filename> variable in the BSP description
-            file match.
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-LINUX_KERNEL_TYPE'><filename>LINUX_KERNEL_TYPE</filename></ulink>
+            variable and the <filename>KTYPE</filename> variable in the
+            BSP description file match.
             <note>
                 Future versions of the tooling make the specification of
                 <filename>KTYPE</filename> in the BSP optional.

documentation/kernel-dev/kernel-dev-common.xml

@@ -7,11 +7,15 @@
 <title>Common Tasks</title>
 
 <para>
-    This chapter presents several common tasks that are performed when you
+    This chapter presents several common tasks you perform when you
     work with the Yocto Project Linux kernel.
     These tasks include preparing a layer, modifying an existing recipe,
     iterative development, working with your own sources, and incorporating
     out-of-tree modules.
+    <note>
+        The examples presented in this chapter work with the Yocto Project
+        1.2.2 Release and forward.
+    </note>
 </para>
 
     <section id='creating-and-preparing-a-layer'>
@@ -29,7 +33,7 @@
             sections in the Yocto Project Development Manual:
             <itemizedlist>
                 <listitem><para>"<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and Creating Layers</ulink>" for
-                    general information on layers and how to create them.</para></listitem>
+                    general information on layers and how to create layers.</para></listitem>
                 <listitem><para>"<ulink url='&YOCTO_DOCS_DEV_URL;#get-your-layer-setup-for-the-build'>Get Your Layer Setup for the Build</ulink>" for
                     specific instructions on setting up a layer for kernel
                     development.</para></listitem>
@@ -217,6 +221,49 @@
             "linux-yocto".
         </para>
 
+        <section id='tip-dirty-string'>
+            <title>"-dirty" String</title>
+
+            <para>
+                <emphasis>AR - Darrren Hart:</emphasis>  This section
+                originated from the old Yocto Project Kernel Architecture
+                and Use Manual.
+                It was decided we need to put it in this section here.
+                Darren needs to figure out where we want it and what part
+                of it we want (all, revision???)
+            </para>
+
+            <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 force a pickup and commit of 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 id='generating-configuration-files'>
             <title>Generating Configuration Files</title>
 
@@ -238,7 +285,7 @@
                 The resulting <filename>.config</filename> file is
                 located in
                 <filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-WORKDIR'><filename>WORKDIR</filename></ulink><filename>}</filename> under the
-                <filename>linux-${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink><filename>}-${KTYPE}-build</filename> directory.
+                <filename>linux-${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink><filename>}-${<ulink url='&YOCTO_DOCS_REF_URL;#var-KTYPE'><filename>KTYPE</filename></ulink>}-build</filename> directory.
                 You can use the entire <filename>.config</filename> file as the
                 <filename>defconfig</filename> file as described in the
                 "<link linkend='changing-the-configuration'>Changing the Configuration</link>" section.
@@ -612,11 +659,14 @@
 
         <para>
             The important point to note here is the
-            <filename>KERNEL_SRC</filename> variable.
-            The module <filename>bbclass</filename> sets this variable,
-            as well as the <filename>KERNEL_PATH</filename> variable
-            to <filename>${STAGING_KERNEL_DIR}</filename> with the
-            necessary Linux kernel build information to build modules.
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-KERNEL_SRC'><filename>KERNEL_SRC</filename></ulink>
+            variable.
+            The class <filename>module.bbclass</filename> sets this variable,
+            as well as the
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-KERNEL_PATH'><filename>KERNEL_PATH</filename></ulink>
+            variable to
+            <filename>${<ulink url='&YOCTO_DOCS_REF_URL;#var-STAGING_KERNEL_DIR'><filename>STAGING_KERNEL_DIR</filename></ulink>}</filename>
+            with the necessary Linux kernel build information to build modules.
             If your module <filename>Makefile</filename> uses a different
             variable, you might want to override the
             <filename>do_compile()</filename> step, or create a patch to
@@ -656,11 +706,122 @@
         </para>
 
         <para>
-            Because the variable is <filename>RRECOMMENDS</filename> and not
-            a <filename>RDEPENDS</filename> variable, the build will not fail
-            if this module is not available to include in the image.
+            Because the variable is
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-RRECOMMENDS'><filename>RRECOMMENDS</filename></ulink>
+            and not a
+            <ulink url='&YOCTO_DOCS_REF_URL;#var-RDEPENDS'><filename>RDEPENDS</filename></ulink>
+            variable, the build will not fail if this module is not available
+            to include in the image.
         </para>
     </section>
+
+    <section id='inspecting-changes-and-commits'>
+        <title>Inspecting Changes and Commits</title>
+
+        <para>
+            A common question when working with a kernel is:
+            "What changes have been applied to this tree?"
+            Rather than using "grep" across directories to see what has
+            changed, you can use Git to inspect or search the kernel tree.
+            Using Git is an efficent way to see what has changed in the tree.
+        </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.
+                These examples are by no means the only way to see 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>.
+                </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 short, oneline summaries of changes use the
+                <filename>git log</filename> command:
+                <literallayout class='monospaced'>
+     $ git log --oneline origin/standard/base..origin/standard/emenlow
+                </literallayout>
+            </para>
+
+            <para>
+                Use this command to see code differences for the changes:
+                <literallayout class='monospaced'>
+     $ git diff origin/standard/base..origin/standard/emenlow
+                </literallayout>
+            </para>
+
+            <para>
+                Use this command to see the commit log messages and the
+                text differences:
+                <literallayout class='monospaced'>
+     $ git show origin/standard/base..origin/standard/emenlow
+                </literallayout>
+            </para>
+
+            <para>
+                Use this command to create individual patches for
+                each change.
+                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='showing-a-particular-feature-or-branch-change'>
+            <title>Showing a Particular Feature or Branch Change</title>
+
+            <para>
+                Tags in the Yocto Project kernel tree divide changes for
+                significant features or branches.
+                The <filename>git show &lt;tag&gt;</filename> command shows
+                changes based on a tag.
+                Here is an example that shows <filename>systemtap</filename>
+                changes:
+                <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>
+        </section>
+    </section>
 </chapter>
 <!--
 vim: expandtab tw=80 ts=4

documentation/kernel-dev/kernel-dev-concepts-appx.xml

@@ -0,0 +1,253 @@
+<!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; ] >
+
+<appendix id='kernel-dev-concepts-appx'>
+<title>Advanced Kernel Concepts</title>
+
+    <section id='kernel-big-picture'>
+        <title>Yocto Project Kernel Development and Maintenance</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>
+</appendix>
+<!--
+vim: expandtab tw=80 ts=4
+-->

documentation/kernel-dev/kernel-dev-customization.xsl

@@ -1,8 +1,11 @@
 <?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="generate.toc" select="'article nop'"></xsl:param>  -->
-
+  <xsl:param name="html.stylesheet" select="'kernel-dev-style.css'" />
+  <xsl:param name="chapter.autolabel" select="1" />
+  <xsl:param name="appendix.autolabel">A</xsl:param>
+  <xsl:param name="section.autolabel" select="1" />
+  <xsl:param name="section.label.includes.component.label" select="1" />
 </xsl:stylesheet>

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

@@ -0,0 +1,27 @@
+<?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-dev/'"/>
+  <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">A</xsl:param>
+  <xsl:param name="section.autolabel" select="1" />
+  <xsl:param name="section.label.includes.component.label" select="1" />
+</xsl:stylesheet>

documentation/kernel-dev/kernel-dev-faq.xml

@@ -2,7 +2,7 @@
 "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
 [<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
-<chapter id='kernel-dev-faq'>
+<appendix id='kernel-dev-faq'>
 <title>Kernel Development FAQ</title>
 <qandaset>
     <qandaentry>
@@ -125,7 +125,7 @@
     </qandaentry>
 
 </qandaset>
-</chapter>
+</appendix>
 <!--
 vim: expandtab tw=80 ts=4
 -->

documentation/kernel-dev/kernel-dev-intro.xml

@@ -5,6 +5,27 @@
 <chapter id='kernel-dev-intro'>
 <title>Introduction</title>
 
+<para>
+    <emphasis>AR - Darrren Hart:</emphasis>  See if the concepts in these
+    three bullets are adequately covered in somewhere in this manual:
+    <itemizedlist>
+        <listitem><para>Do we convey that our kernel Git repositories
+            have a clear and continuous history, similar to the way the
+            kernel Git repositories for <filename>kernel.org</filename>
+            do.
+            </para></listitem>
+        <listitem><para>Does the manual note that Yocto Project delivers
+            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>Do we convey that the Yocto Project uses a
+            Git branching strategy that, from a
+            developer's point of view, results in a linear path from the
+            baseline kernel.org, through a select group of features and
+            ends with their BSP-specific commits.</para></listitem>
+    </itemizedlist>
+</para>
+
     <section id='kernel-dev-overview'>
         <title>Overview</title>
 
@@ -14,7 +35,7 @@
             This manual provides background information on the Yocto Linux kernel
             <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>,
             describes common tasks you can perform using the kernel tools,
-            and shows you how to use the Metadata needed to work with
+            and shows you how to use the kernel Metadata needed to work with
             the kernel inside the Yocto Project.
        </para>
 
@@ -32,7 +53,7 @@
             Also included is a linux-yocto development recipe
             (<filename>linux-yocto-dev.bb</filename>) should you want to work
             with the very latest in upstream Linux kernel development and
-            Metadata development.
+            kernel Metadata development.
         </para>
 
         <para>

documentation/kernel-dev/kernel-dev-maint-appx.xml

@@ -0,0 +1,218 @@
+<!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; ] >
+
+<appendix id='kernel-dev-maint-appx'>
+<title>Kernel Maintenance</title>
+
+    <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>
+            <emphasis>AR - Darrren Hart:</emphasis>  Some parts of this section
+            need to be in the
+            "<link linkend='using-an-iterative-development-process'>Using an Iterative Development Process</link>"
+            section.
+            Darren needs to figure out which parts and identify them.
+        </para>
+
+        <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.
+        </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>
+</appendix>
+<!--
+vim: expandtab tw=80 ts=4
+-->

documentation/kernel-dev/kernel-dev.xml

@@ -16,7 +16,9 @@
             </imageobject>
         </mediaobject>
 
-        <title></title>
+        <title>
+		  Yocto Project Linux Kernel Development Manual
+		</title>
 
         <authorgroup>
             <author>
@@ -63,6 +65,10 @@
 
     <xi:include href="kernel-dev-advanced.xml"/>
 
+    <xi:include href="kernel-dev-concepts-appx.xml"/>
+
+    <xi:include href="kernel-dev-maint-appx.xml"/>
+
 <!--
     <xi:include href="kernel-dev-examples.xml"/>
 -->

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

@@ -246,10 +246,10 @@
         </para>
 
         <section id='change-inspection-kernel-changes-commits'>
-            <title>Change Inspection: Kernel Changes/Commits</title>
+            <title>Change Inspection: Changes/Commits</title>
 
             <para>
-                A common question when working with a BSP or kernel is:
+                A common question when working with a kernel is:
                 "What changes have been applied to this tree?"
             </para>
 
@@ -257,53 +257,95 @@
                 In projects that have a collection of directories that
                 contain patches to the kernel, it is possible to inspect or "grep" the contents
                 of the directories to get a general feel for the changes.
-                This sort of patch inspection is not an efficient way to determine what has been done to the
-                kernel.
+                This sort of patch inspection is not an efficient way to determine what has been
+                done to the kernel.
                 The reason it is inefficient is because there are many optional patches that are
                 selected based on the kernel type and the feature description.
                 Additionally, patches could exist in directories that are not included in the search.
             </para>
 
             <para>
-                A more efficient way to determine what has changed in the kernel is to use
+                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-bsp'>
-                <title>What Changed in a BSP?</title>
+            <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 to examine changes.
-                    Because the Yocto Project Git repository does not break existing Git
-                    functionality and because there exists many permutations of these types of
-                    commands, there are many more methods to discover changes.
+                    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>
-                        Unless you provide a commit range
-                        (&lt;kernel-type&gt;..&lt;bsp&gt;-&lt;kernel-type&gt;), <filename>kernel.org</filename> history
-                        is blended with Yocto Project changes.
+                        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'>
-     # full description of the changes
-     &gt; git whatchanged &lt;kernel type&gt;..&lt;kernel type&gt;/&lt;bsp&gt;
-        &gt; eg: git whatchanged yocto/standard/base..yocto/standard/common-pc/base
+     $ git whatchanged origin/standard/base..origin/standard/emenlow
+                    </literallayout>
+                </para>
 
-     # summary of the changes
-     &gt; git log --pretty=oneline --abbrev-commit &lt;kernel type&gt;..&lt;kernel type&gt;/&lt;bsp&gt;
+                <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>
 
-     # source code changes (one combined diff)
-     &gt; git diff &lt;kernel type&gt;..&lt;kernel type&gt;/&lt;bsp&gt;
-     &gt; git show &lt;kernel type&gt;..&lt;kernel type&gt;/&lt;bsp&gt;
+                <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>
 
-     # dump individual patches per commit
-     &gt; git format-patch -o &lt;dir&gt; &lt;kernel type&gt;..&lt;kernel type&gt;/&lt;bsp&gt;
+                <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>
 
-     # determine the change history of a particular file
-     &gt; git whatchanged &lt;path to file&gt;
-
-     # determine the commits which touch each line in a file
-     &gt; git blame &lt;path to file&gt;
+                <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>

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

@@ -3,6 +3,9 @@
   
   <xsl:import href="http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl" />
 
-<!--  <xsl:param name="generate.toc" select="'article nop'"></xsl:param>  -->
-
+  <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

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

@@ -16,7 +16,9 @@
             </imageobject>
         </mediaobject>
 
-        <title></title>
+        <title>
+            The Yocto Project Kernel Architecture and Use Manual
+        </title>
 
         <authorgroup>
             <author>