bitbake: cooker, toaster: variable definition tracking

In order to track the file where a configuration
variable was defined, this patch bring these changes:

* a new feature is defined in CookerFeatures, named
BASEDATASTORE_TRACKING. When a UI requests BASEDATASTORE_TRACKING,
the base variable definition are tracked when configuration
is parsed.

* getAllKeysWithFlags now includes variable history in the
data dump

* toaster_ui.py will record the operation, file path
and line number where the variable was changes

* toaster Simple UI will display the file path
and line number for Configuration page

There is a change in the models to accomodate the recording
of variable change history.

[YOCTO #5227]

(Bitbake rev: 78e58fed82f2a71f052485de0052d7b9cca53ffd)

Signed-off-by: Alexandru DAMIAN <alexandru.damian@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

bitbake/bin/bitbake

@@ -41,7 +41,7 @@ from bb import ui
 from bb import server
 from bb import cookerdata
 
-__version__ = "1.21.0"
+__version__ = "1.20.0"
 logger = logging.getLogger("BitBake")
 
 # Python multiprocessing requires /dev/shm
@@ -190,9 +190,6 @@ class BitBakeConfigParameters(cookerdata.ConfigParameters):
         parser.add_option("", "--observe-only", help = "Connect to a server as an observing-only client.",
                    action = "store_true", dest = "observe_only", default = False)
 
-        parser.add_option("", "--status-only", help = "Check the status of the remote bitbake server.",
-                   action = "store_true", dest = "status_only", default = False)
-
         options, targets = parser.parse_args(sys.argv)
 
         # some environmental variables set also configuration options
@@ -208,10 +205,8 @@ def start_server(servermodule, configParams, configuration):
     if configParams.bind:
         (host, port) = configParams.bind.split(':')
         server.initServer((host, int(port)))
-        configuration.interface = [ server.serverImpl.host, server.serverImpl.port ]
     else:
         server.initServer()
-        configuration.interface = []
 
     try:
         configuration.setServerRegIdleCallback(server.getServerIdleCB())
@@ -289,9 +284,7 @@ def main():
 
     # Ensure logging messages get sent to the UI as events
     handler = bb.event.LogHandler()
-    if not configParams.status_only:
-        # In status only mode there are no logs and no UI
-        logger.addHandler(handler)
+    logger.addHandler(handler)
 
     # Clear away any spurious environment variables while we stoke up the cooker
     cleanedvars = bb.utils.clean_environment()
@@ -304,31 +297,13 @@ def main():
         # we start a stub server that is actually a XMLRPClient that connects to a real server
         server = servermodule.BitBakeXMLRPCClient(configParams.observe_only)
         server.saveConnectionDetails(configParams.remote_server)
-        server.saveConnectionConfigParams(configParams)
 
     if not configParams.server_only:
         # Collect the feature set for the UI
         featureset = getattr(ui_module, "featureSet", [])
 
-        if configParams.status_only:
-            try:
-                server_connection = server.establishConnection(featureset)
-            except:
-                sys.exit(1)
-            if not server_connection:
-                sys.exit(1)
-            server_connection.terminate()
-            sys.exit(0)
-
         # Setup a connection to the server (cooker)
         server_connection = server.establishConnection(featureset)
-        if not server_connection:
-            if configParams.kill_server:
-                bb.fatal("Server already killed")
-            configParams.bind = configParams.remote_server
-            start_server(servermodule, configParams, configuration)
-            bb.event.ui_queue = []
-            server_connection = server.establishConnection(featureset)
 
         # Restore the environment in case the UI needs it
         for k in cleanedvars:

bitbake/bin/bitbake-layers

@@ -55,16 +55,10 @@ def main(args):
 
 class Commands(cmd.Cmd):
     def __init__(self):
-        self.bbhandler = None
-        self.returncode = 0
-        self.bblayers = []
         cmd.Cmd.__init__(self)
-
-    def init_bbhandler(self, config_only = False):
-        if not self.bbhandler:
-            self.bbhandler = bb.tinfoil.Tinfoil()
-            self.bblayers = (self.bbhandler.config_data.getVar('BBLAYERS', True) or "").split()
-            self.bbhandler.prepare(config_only)
+        self.bbhandler = bb.tinfoil.Tinfoil()
+        self.returncode = 0
+        self.bblayers = (self.bbhandler.config_data.getVar('BBLAYERS', True) or "").split()
 
     def default(self, line):
         """Handle unrecognised commands"""
@@ -89,7 +83,7 @@ class Commands(cmd.Cmd):
 
     def do_show_layers(self, args):
         """show current configured layers"""
-        self.init_bbhandler(config_only = True)
+        self.bbhandler.prepare(config_only = True)
         logger.plain("%s  %s  %s" % ("layer".ljust(20), "path".ljust(40), "priority"))
         logger.plain('=' * 74)
         for layerdir in self.bblayers:
@@ -126,7 +120,7 @@ Options:
        recipes with the ones they overlay indented underneath
   -s   only list overlayed recipes where the version is the same
 """
-        self.init_bbhandler()
+        self.bbhandler.prepare()
 
         show_filenames = False
         show_same_ver_only = False
@@ -209,7 +203,7 @@ Options:
   -m   only list where multiple recipes (in the same layer or different
        layers) exist for the same recipe name
 """
-        self.init_bbhandler()
+        self.bbhandler.prepare()
 
         show_filenames = False
         show_multi_provider_only = False
@@ -347,7 +341,7 @@ build results (as the layer priority order has effectively changed).
             logger.error('Directory %s exists and is non-empty, please clear it out first' % outputdir)
             return
 
-        self.init_bbhandler()
+        self.bbhandler.prepare()
         layers = self.bblayers
         if len(arglist) > 2:
             layernames = arglist[:-1]
@@ -503,7 +497,7 @@ usage: show-appends
 
 Recipes are listed with the bbappends that apply to them as subitems.
 """
-        self.init_bbhandler()
+        self.bbhandler.prepare()
         if not self.bbhandler.cooker.collection.appendlist:
             logger.plain('No append files found')
             return
@@ -576,7 +570,7 @@ Options:
 NOTE:
 The .bbappend file can impact the dependency.
 """
-        self.init_bbhandler()
+        self.bbhandler.prepare()
 
         show_filenames = False
         for arg in args.split():

bitbake/bin/bitbake-worker

@@ -81,7 +81,7 @@ def workerlog_write(msg):
         lf.write(msg)
         lf.flush()
 
-def fork_off_task(cfg, data, workerdata, fn, task, taskname, appends, taskdepdata, quieterrors=False):
+def fork_off_task(cfg, data, workerdata, fn, task, taskname, appends, quieterrors=False):
     # We need to setup the environment BEFORE the fork, since
     # a fork() or exec*() activates PSEUDO...
 
@@ -97,8 +97,7 @@ def fork_off_task(cfg, data, workerdata, fn, task, taskname, appends, taskdepdat
         except TypeError:
              umask = taskdep['umask'][taskname]
 
-    # We can't use the fakeroot environment in a dry run as it possibly hasn't been built
-    if 'fakeroot' in taskdep and taskname in taskdep['fakeroot'] and not cfg.dry_run:
+    if 'fakeroot' in taskdep and taskname in taskdep['fakeroot']:
         envvars = (workerdata["fakerootenv"][fn] or "").split()
         for key, value in (var.split('=') for var in envvars):
             envbackup[key] = os.environ.get(key)
@@ -148,7 +147,6 @@ def fork_off_task(cfg, data, workerdata, fn, task, taskname, appends, taskdepdat
                 os.umask(umask)
 
             data.setVar("BB_WORKERCONTEXT", "1")
-            data.setVar("BB_TASKDEPDATA", taskdepdata)
             data.setVar("BUILDNAME", workerdata["buildname"])
             data.setVar("DATE", workerdata["date"])
             data.setVar("TIME", workerdata["time"])
@@ -301,10 +299,10 @@ class BitbakeWorker(object):
         sys.exit(0)
 
     def handle_runtask(self, data):
-        fn, task, taskname, quieterrors, appends, taskdepdata = pickle.loads(data)
+        fn, task, taskname, quieterrors, appends = pickle.loads(data)
         workerlog_write("Handling runtask %s %s %s\n" % (task, fn, taskname))
 
-        pid, pipein, pipeout = fork_off_task(self.cookercfg, self.data, self.workerdata, fn, task, taskname, appends, taskdepdata, quieterrors)
+        pid, pipein, pipeout = fork_off_task(self.cookercfg, self.data, self.workerdata, fn, task, taskname, appends, quieterrors)
 
         self.build_pids[pid] = task
         self.build_pipes[pid] = runQueueWorkerPipe(pipein, pipeout)

bitbake/contrib/vim/plugin/newbb.vim

@@ -17,7 +17,7 @@ endif
 fun! <SID>GetUserName()
     let l:user_name = system("git config --get user.name")
     if v:shell_error
-        return "Unknown User"
+        return "Unknow User"
     else
         return substitute(l:user_name, "\n", "", "")
 endfun

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.21.0"
+__version__ = "1.20.0"
 
 import sys
 if sys.version_info < (2, 7, 3):
@@ -141,3 +141,6 @@ def deprecate_import(current, modulename, fromlist, renames = None):
 
         setattr(sys.modules[current], newname, newobj)
 
+deprecate_import(__name__, "bb.fetch", ("MalformedUrl", "encodeurl", "decodeurl"))
+deprecate_import(__name__, "bb.utils", ("mkdirhier", "movefile", "copyfile", "which"))
+deprecate_import(__name__, "bb.utils", ["vercmp_string"], ["vercmp"])

bitbake/lib/bb/build.py

@@ -288,7 +288,7 @@ set -e
         if bb.msg.loggerVerboseLogs:
             script.write("set -x\n")
         if cwd:
-            script.write("cd '%s'\n" % cwd)
+            script.write("cd %s\n" % cwd)
         script.write("%s\n" % func)
         script.write('''
 # cleanup

bitbake/lib/bb/codeparser.py

@@ -35,7 +35,7 @@ def check_indent(codestr):
 
 class CodeParserCache(MultiProcessCache):
     cache_file_name = "bb_codeparser.dat"
-    CACHE_VERSION = 4
+    CACHE_VERSION = 3
 
     def __init__(self):
         MultiProcessCache.__init__(self)
@@ -64,8 +64,6 @@ class CodeParserCache(MultiProcessCache):
         for h in data[0]:
             data[0][h]["refs"] = self.internSet(data[0][h]["refs"])
             data[0][h]["execs"] = self.internSet(data[0][h]["execs"])
-            for k in data[0][h]["contains"]:
-                data[0][h]["contains"][k] = self.internSet(data[0][h]["contains"][k])
         for h in data[1]:
             data[1][h]["execs"] = self.internSet(data[1][h]["execs"])
         return
@@ -124,13 +122,7 @@ class PythonParser():
         name = self.called_node_name(node.func)
         if name in self.getvars or name in self.containsfuncs:
             if isinstance(node.args[0], ast.Str):
-                varname = node.args[0].s
-                if name in self.containsfuncs and isinstance(node.args[1], ast.Str):
-                    if varname not in self.contains:
-                        self.contains[varname] = set()
-                    self.contains[varname].add(node.args[1].s)
-                else:                      
-                    self.references.add(node.args[0].s)
+                self.var_references.add(node.args[0].s)
             else:
                 self.warn(node.func, node.args[0])
         elif name in self.execfuncs:
@@ -155,11 +147,11 @@ class PythonParser():
                 break
 
     def __init__(self, name, log):
+        self.var_references = set()
         self.var_execs = set()
-        self.contains = {}
         self.execs = set()
         self.references = set()
-        self.log = BufferedLogger('BitBake.Data.PythonParser', logging.DEBUG, log)
+        self.log = BufferedLogger('BitBake.Data.%s' % name, logging.DEBUG, log)
 
         self.unhandled_message = "in call of %s, argument '%s' is not a string literal"
         self.unhandled_message = "while parsing %s, %s" % (name, self.unhandled_message)
@@ -170,15 +162,14 @@ class PythonParser():
         if h in codeparsercache.pythoncache:
             self.references = codeparsercache.pythoncache[h]["refs"]
             self.execs = codeparsercache.pythoncache[h]["execs"]
-            self.contains = codeparsercache.pythoncache[h]["contains"]
             return
 
         if h in codeparsercache.pythoncacheextras:
             self.references = codeparsercache.pythoncacheextras[h]["refs"]
             self.execs = codeparsercache.pythoncacheextras[h]["execs"]
-            self.contains = codeparsercache.pythoncacheextras[h]["contains"]
             return
 
+
         code = compile(check_indent(str(node)), "<string>", "exec",
                        ast.PyCF_ONLY_AST)
 
@@ -186,12 +177,12 @@ class PythonParser():
             if n.__class__.__name__ == "Call":
                 self.visit_Call(n)
 
+        self.references.update(self.var_references)
         self.references.update(self.var_execs)
 
         codeparsercache.pythoncacheextras[h] = {}
         codeparsercache.pythoncacheextras[h]["refs"] = self.references
         codeparsercache.pythoncacheextras[h]["execs"] = self.execs
-        codeparsercache.pythoncacheextras[h]["contains"] = self.contains
 
 class ShellParser():
     def __init__(self, name, log):

bitbake/lib/bb/command.py

@@ -86,8 +86,6 @@ class Command:
 
     def runAsyncCommand(self):
         try:
-            if self.cooker.state == bb.cooker.state.error:
-                return False
             if self.currentAsyncCommand is not None:
                 (command, options) = self.currentAsyncCommand
                 commandmethod = getattr(CommandsAsync, command)
@@ -196,11 +194,18 @@ class CommandsSync:
         """
         command.cooker.disableDataTracking()
 
-    def setPrePostConfFiles(self, command, params):
-        prefiles = params[0].split()
-        postfiles = params[1].split()
-        command.cooker.configuration.prefile = prefiles
-        command.cooker.configuration.postfile = postfiles
+    def initCooker(self, command, params):
+        """
+        Init the cooker to initial state with nothing parsed
+        """
+        command.cooker.initialize()
+
+    def resetCooker(self, command, params):
+        """
+        Reset the cooker to its initial state, thus forcing a reparse for
+        any async command that has the needcache property set to True
+        """
+        command.cooker.reset()
 
     def getCpuCount(self, command, params):
         """
@@ -413,6 +418,18 @@ class CommandsAsync:
             command.finishAsyncCommand()
     compareRevisions.needcache = True
 
+    def parseConfigurationFiles(self, command, params):
+        """
+        Parse the configuration files
+        """
+        prefiles = params[0].split()
+        postfiles = params[1].split()
+        command.cooker.configuration.prefile = prefiles
+        command.cooker.configuration.postfile = postfiles
+        command.cooker.loadConfigurationData()
+        command.finishAsyncCommand()
+    parseConfigurationFiles.needcache = False
+
     def triggerEvent(self, command, params):
         """
         Trigger a certain event
@@ -422,12 +439,3 @@ class CommandsAsync:
         command.currentAsyncCommand = None
     triggerEvent.needcache = False
 
-    def resetCooker(self, command, params):
-        """
-        Reset the cooker to its initial state, thus forcing a reparse for
-        any async command that has the needcache property set to True
-        """
-        command.cooker.reset()
-        command.finishAsyncCommand()
-    resetCooker.needcache = False
-

bitbake/lib/bb/cooker.py

@@ -61,7 +61,7 @@ class CollectionError(bb.BBHandledException):
     """
 
 class state:
-    initial, parsing, running, shutdown, forceshutdown, stopped, error = range(7)
+    initial, parsing, running, shutdown, forceshutdown, stopped = range(6)
 
 
 class SkippedPackage:
@@ -117,7 +117,7 @@ class BBCooker:
 
         self.configuration = configuration
 
-        self.initConfigurationData()
+        self.loadConfigurationData()
 
         # Take a lock so only one copy of bitbake can run against a given build
         # directory at a time
@@ -125,14 +125,6 @@ class BBCooker:
         self.lock = bb.utils.lockfile(lockfile, False, False)
         if not self.lock:
             bb.fatal("Only one copy of bitbake should be run against a build directory")
-        try:
-            self.lock.seek(0)
-            self.lock.truncate()
-            if len(configuration.interface) >= 2:
-                self.lock.write("%s:%s\n" % (configuration.interface[0], configuration.interface[1]));
-            self.lock.flush()
-        except:
-            pass
 
         # TOSTOP must not be set or our children will hang when they output
         fd = sys.stdout.fileno()
@@ -152,10 +144,8 @@ class BBCooker:
     def initConfigurationData(self):
 
         self.state = state.initial
-        self.caches_array = []
 
-        if CookerFeatures.BASEDATASTORE_TRACKING in self.featureset:
-            self.enableDataTracking()
+        self.caches_array = []
 
         all_extra_cache_names = []
         # We hardcode all known cache types in a single place, here.
@@ -178,6 +168,19 @@ class BBCooker:
         self.databuilder = bb.cookerdata.CookerDataBuilder(self.configuration, False)
         self.data = self.databuilder.data
 
+    def enableDataTracking(self):
+        self.configuration.tracking = True
+        self.data.enableTracking()
+
+    def disableDataTracking(self):
+        self.configuration.tracking = False
+        self.data.disableTracking()
+
+    def loadConfigurationData(self):
+        if CookerFeatures.BASEDATASTORE_TRACKING in self.featureset:
+            self.enableDataTracking()
+
+        self.initConfigurationData()
         self.databuilder.parseBaseConfiguration()
         self.data = self.databuilder.data
         self.data_hash = self.databuilder.data_hash
@@ -192,13 +195,6 @@ class BBCooker:
         if CookerFeatures.BASEDATASTORE_TRACKING in self.featureset:
             self.disableDataTracking()
 
-    def enableDataTracking(self):
-        self.configuration.tracking = True
-        self.data.enableTracking()
-
-    def disableDataTracking(self):
-        self.configuration.tracking = False
-        self.data.disableTracking()
 
     def modifyConfigurationVar(self, var, val, default_file, op):
         if op == "append":
@@ -213,11 +209,20 @@ class BBCooker:
         #add append var operation to the end of default_file
         default_file = bb.cookerdata.findConfigFile(default_file, self.data)
 
-        total = "#added by hob"
+        with open(default_file, 'r') as f:
+            contents = f.readlines()
+        f.close()
+
+        total = ""
+        for c in contents:
+            total += c
+
+        total += "#added by hob"
         total += "\n%s += \"%s\"\n" % (var, val)
 
-        with open(default_file, 'a') as f:
+        with open(default_file, 'w') as f:
             f.write(total)
+        f.close()
 
         #add to history
         loginfo = {"op":append, "file":default_file, "line":total.count("\n")}
@@ -246,6 +251,7 @@ class BBCooker:
             if topdir in conf_file:
                 with open(conf_file, 'r') as f:
                     contents = f.readlines()
+                f.close()
 
                 lines = self.data.varhistory.get_variable_lines(var, conf_file)
                 for line in lines:
@@ -271,8 +277,12 @@ class BBCooker:
                         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.writelines(contents)
+                    f.write(total)
+                f.close()
 
         if replaced == False:
             #remove var from history
@@ -281,12 +291,21 @@ class BBCooker:
             #add var to the end of default_file
             default_file = bb.cookerdata.findConfigFile(default_file, self.data)
 
+            with open(default_file, 'r') as f:
+                contents = f.readlines()
+            f.close()
+
+            total = ""
+            for c in contents:
+                total += c
+
             #add the variable on a single line, to be easy to replace the second time
-            total = "\n#added by hob"
+            total += "\n#added by hob"
             total += "\n%s %s \"%s\"\n" % (var, op, val)
 
-            with open(default_file, 'a') as f:
+            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")}
@@ -300,6 +319,7 @@ class BBCooker:
             if topdir in conf_file:
                 with open(conf_file, 'r') as f:
                     contents = f.readlines()
+                f.close()
 
                 lines = self.data.varhistory.get_variable_lines(var, conf_file)
                 for line in lines:
@@ -322,8 +342,12 @@ class BBCooker:
                     #remove var from history
                     self.data.varhistory.del_var_history(var, conf_file, line)
 
+                total = ""
+                for c in contents:
+                    total += c
                 with open(conf_file, 'w') as f:
-                    f.writelines(contents)
+                    f.write(total)
+                f.close()
 
     def createConfigFile(self, name):
         path = os.getcwd()
@@ -710,9 +734,14 @@ class BBCooker:
         logger.info("Task dependencies saved to 'task-depends.dot'")
 
     def show_appends_with_no_recipes( self ):
+        recipes = set(os.path.basename(f)
+                      for f in self.recipecache.pkg_fn.iterkeys())
+        recipes |= set(os.path.basename(f)
+                      for f in self.skiplist.iterkeys())
+        appended_recipes = self.collection.appendlist.iterkeys()
         appends_without_recipes = [self.collection.appendlist[recipe]
-                                   for recipe in self.collection.appendlist
-                                   if recipe not in self.collection.appliedappendlist]
+                                   for recipe in appended_recipes
+                                   if recipe not in recipes]
         if appends_without_recipes:
             appendlines = ('  %s' % append
                            for appends in appends_without_recipes
@@ -1108,13 +1137,10 @@ class BBCooker:
 
         def buildFileIdle(server, rq, abort):
 
-            msg = None
             if abort or self.state == state.forceshutdown:
                 rq.finish_runqueue(True)
-                msg = "Forced shutdown"
             elif self.state == state.shutdown:
                 rq.finish_runqueue(False)
-                msg = "Stopped build"
             failures = 0
             try:
                 retval = rq.execute_runqueue()
@@ -1127,7 +1153,7 @@ class BBCooker:
 
             if not retval:
                 bb.event.fire(bb.event.BuildCompleted(len(rq.rqdata.runq_fnid), buildname, item, failures), self.event_data)
-                self.command.finishAsyncCommand(msg)
+                self.command.finishAsyncCommand()
                 return False
             if retval is True:
                 return True
@@ -1141,13 +1167,10 @@ class BBCooker:
         """
 
         def buildTargetsIdle(server, rq, abort):
-            msg = None
             if abort or self.state == state.forceshutdown:
                 rq.finish_runqueue(True)
-                msg = "Forced shutdown"
             elif self.state == state.shutdown:
                 rq.finish_runqueue(False)
-                msg = "Stopped build"
             failures = 0
             try:
                 retval = rq.execute_runqueue()
@@ -1160,7 +1183,7 @@ class BBCooker:
 
             if not retval:
                 bb.event.fire(bb.event.BuildCompleted(len(rq.rqdata.runq_fnid), buildname, targets, failures), self.data)
-                self.command.finishAsyncCommand(msg)
+                self.command.finishAsyncCommand()
                 return False
             if retval is True:
                 return True
@@ -1282,11 +1305,6 @@ class BBCooker:
         if len(pkgs_to_build) == 0:
             raise NothingToBuild
 
-        ignore = (self.data.getVar("ASSUME_PROVIDED", True) or "").split()
-        for pkg in pkgs_to_build:
-            if pkg in ignore:
-                parselog.warn("Explicit target \"%s\" is in ASSUME_PROVIDED, ignoring" % pkg)
-
         if 'world' in pkgs_to_build:
             self.buildWorldTargetList()
             pkgs_to_build.remove('world')
@@ -1313,7 +1331,6 @@ class BBCooker:
             self.prhost = prserv.serv.auto_start(self.data)
         except prserv.serv.PRServiceConfigError:
             bb.event.fire(CookerExit(), self.event_data)
-            self.state = state.error
         return
 
     def post_serve(self):
@@ -1329,9 +1346,12 @@ class BBCooker:
     def finishcommand(self):
         self.state = state.initial
 
-    def reset(self):
+    def initialize(self):
         self.initConfigurationData()
 
+    def reset(self):
+        self.loadConfigurationData()
+
 def server_main(cooker, func, *args):
     cooker.pre_serve()
 
@@ -1367,7 +1387,6 @@ class CookerExit(bb.event.Event):
 class CookerCollectFiles(object):
     def __init__(self, priorities):
         self.appendlist = {}
-        self.appliedappendlist = []
         self.bbfile_config_priorities = priorities
 
     def calc_bbfile_priority( self, filename, matched = None ):
@@ -1484,14 +1503,10 @@ class CookerCollectFiles(object):
         """
         Returns a list of .bbappend files to apply to fn
         """
-        filelist = []
         f = os.path.basename(fn)
-        for bbappend in self.appendlist:
-            if (bbappend == f) or ('%' in bbappend and bbappend.startswith(f[:bbappend.index('%')])):
-                self.appliedappendlist.append(bbappend)
-                for filename in self.appendlist[bbappend]:
-                    filelist.append(filename)
-        return filelist
+        if f in self.appendlist:
+            return self.appendlist[f]
+        return []
 
     def collection_priorities(self, pkgfns):
 

bitbake/lib/bb/cookerdata.py

@@ -127,7 +127,6 @@ class CookerConfiguration(object):
         self.dump_signatures = False
         self.dry_run = False
         self.tracking = False
-        self.interface = []
 
         self.env = {}
 

bitbake/lib/bb/data.py

@@ -214,7 +214,7 @@ def emit_var(var, o=sys.__stdout__, d = init(), all=False):
         o.write('unset %s\n' % varExpanded)
         return 0
 
-    if val is None:
+    if not val:
         return 0
 
     val = str(val)
@@ -229,7 +229,7 @@ def emit_var(var, o=sys.__stdout__, d = init(), all=False):
 
     # if we're going to output this within doublequotes,
     # to a shell, we need to escape the quotes in the var
-    alter = re.sub('"', '\\"', val)
+    alter = re.sub('"', '\\"', val.strip())
     alter = re.sub('\n', ' \\\n', alter)
     o.write('%s="%s"\n' % (varExpanded, alter))
     return 0
@@ -299,21 +299,6 @@ def build_dependencies(key, keys, shelldeps, varflagsexcl, d):
         vardeps = varflags.get("vardeps")
         value = d.getVar(key, False)
 
-        def handle_contains(value, contains, d):
-            newvalue = ""
-            for k in contains:
-                l = (d.getVar(k, True) or "").split()
-                for word in contains[k]:
-                    if word in l:
-                        newvalue += "\n%s{%s} = Set" %  (k, word)
-                    else:
-                        newvalue += "\n%s{%s} = Unset" %  (k, word)
-            if not newvalue:
-                return value
-            if not value:
-                return newvalue
-            return value + newvalue
-
         if "vardepvalue" in varflags:
            value = varflags.get("vardepvalue")
         elif varflags.get("func"):
@@ -324,7 +309,6 @@ def build_dependencies(key, keys, shelldeps, varflagsexcl, d):
                     logger.warn("Variable %s contains tabs, please remove these (%s)" % (key, d.getVar("FILE", True)))
                 parser.parse_python(parsedvar.value)
                 deps = deps | parser.references
-                value = handle_contains(value, parser.contains, d)
             else:
                 parsedvar = d.expandWithRefs(value, key)
                 parser = bb.codeparser.ShellParser(key, logger)
@@ -334,12 +318,10 @@ def build_dependencies(key, keys, shelldeps, varflagsexcl, d):
                 parser.log.flush()
             deps = deps | parsedvar.references
             deps = deps | (keys & parser.execs) | (keys & parsedvar.execs)
-            value = handle_contains(value, parsedvar.contains, d)
         else:
             parser = d.expandWithRefs(value, key)
             deps |= parser.references
             deps = deps | (keys & parser.execs)
-            value = handle_contains(value, parser.contains, d)
 
         # Add varflags, assuming an exclusion list is set
         if varflagsexcl:

bitbake/lib/bb/data_smart.py

@@ -88,7 +88,6 @@ class VariableParse:
 
         self.references = set()
         self.execs = set()
-        self.contains = {}
 
     def var_sub(self, match):
             key = match.group()[2:-1]
@@ -99,7 +98,7 @@ class VariableParse:
                 varparse = self.d.expand_cache[key]
                 var = varparse.value
             else:
-                var = self.d.getVarFlag(key, "_content", True)
+                var = self.d.getVar(key, True)
             self.references.add(key)
             if var is not None:
                 return var
@@ -121,11 +120,6 @@ class VariableParse:
             self.references |= parser.references
             self.execs |= parser.execs
 
-            for k in parser.contains:
-                if k not in self.contains:
-                    self.contains[k] = parser.contains[k]
-                else:
-                    self.contains[k].update(parser.contains[k])
             value = utils.better_eval(codeobj, DataContext(self.d))
             return str(value)
 

bitbake/lib/bb/fetch2/__init__.py

@@ -507,7 +507,7 @@ def fetcher_compare_revisions(d):
 def mirror_from_string(data):
     return [ i.split() for i in (data or "").replace('\\n','\n').split('\n') if i ]
 
-def verify_checksum(ud, d):
+def verify_checksum(u, ud, d):
     """
     verify the MD5 and SHA256 checksum for downloaded src
 
@@ -530,7 +530,7 @@ def verify_checksum(ud, d):
             raise NoChecksumError('No checksum specified for %s, please add at least one to the recipe:\n'
                              'SRC_URI[%s] = "%s"\nSRC_URI[%s] = "%s"' %
                              (ud.localpath, ud.md5_name, md5data,
-                              ud.sha256_name, sha256data), ud.url)
+                              ud.sha256_name, sha256data), u)
 
         # Log missing sums so user can more easily add them
         if ud.md5_expected == None:
@@ -568,10 +568,10 @@ def verify_checksum(ud, d):
         msg = msg + '\nIf this change is expected (e.g. you have upgraded to a new version without updating the checksums) then you can use these lines within the recipe:\nSRC_URI[%s] = "%s"\nSRC_URI[%s] = "%s"\nOtherwise you should retry the download and/or check with upstream to determine if the file has become corrupted or otherwise unexpectedly modified.\n' % (ud.md5_name, md5data, ud.sha256_name, sha256data)
 
     if len(msg):
-        raise ChecksumError('Checksum mismatch!%s' % msg, ud.url, md5data)
+        raise ChecksumError('Checksum mismatch!%s' % msg, u, md5data)
 
 
-def update_stamp(ud, d):
+def update_stamp(u, ud, d):
     """
         donestamp is file stamp indicating the whole fetching is done
         this function update the stamp after verifying the checksum
@@ -584,7 +584,7 @@ def update_stamp(ud, d):
             # Errors aren't fatal here
             pass
     else:
-        verify_checksum(ud, d)
+        verify_checksum(u, ud, d)
         open(ud.donestamp, 'w').close()
 
 def subprocess_setup():
@@ -619,7 +619,7 @@ def get_srcrev(d):
         raise FetchError("SRCREV was used yet no valid SCM was found in SRC_URI")
 
     if len(scms) == 1 and len(urldata[scms[0]].names) == 1:
-        autoinc, rev = urldata[scms[0]].method.sortable_revision(urldata[scms[0]], d, urldata[scms[0]].names[0])
+        autoinc, rev = urldata[scms[0]].method.sortable_revision(scms[0], urldata[scms[0]], d, urldata[scms[0]].names[0])
         if len(rev) > 10:
             rev = rev[:10]
         if autoinc:
@@ -637,7 +637,7 @@ def get_srcrev(d):
     for scm in scms:
         ud = urldata[scm]
         for name in ud.names:
-            autoinc, rev = ud.method.sortable_revision(ud, d, name)
+            autoinc, rev = ud.method.sortable_revision(scm, ud, d, name)
             seenautoinc = seenautoinc or autoinc
             if len(rev) > 10:
                 rev = rev[:10]
@@ -730,7 +730,7 @@ def build_mirroruris(origud, mirrors, ld):
     replacements["BASENAME"] = origud.path.split("/")[-1]
     replacements["MIRRORNAME"] = origud.host.replace(':','.') + origud.path.replace('/', '.').replace('*', '.')
 
-    def adduri(ud, uris, uds):
+    def adduri(uri, ud, uris, uds):
         for line in mirrors:
             try:
                 (find, replace) = line
@@ -753,9 +753,9 @@ def build_mirroruris(origud, mirrors, ld):
             uris.append(newuri)
             uds.append(newud)
 
-            adduri(newud, uris, uds)
+            adduri(newuri, newud, uris, uds)
 
-    adduri(origud, uris, uds)
+    adduri(None, origud, uris, uds)
 
     return uris, uds
 
@@ -772,22 +772,22 @@ def rename_bad_checksum(ud, suffix):
     bb.utils.movefile(ud.localpath, new_localpath)
 
 
-def try_mirror_url(origud, ud, ld, check = False):
+def try_mirror_url(newuri, origud, ud, ld, check = False):
     # Return of None or a value means we're finished
     # False means try another url
     try:
         if check:
-            found = ud.method.checkstatus(ud, ld)
+            found = ud.method.checkstatus(newuri, ud, ld)
             if found:
                 return found
             return False
 
         os.chdir(ld.getVar("DL_DIR", True))
 
-        if not os.path.exists(ud.donestamp) or ud.method.need_update(ud, ld):
-            ud.method.download(ud, ld)
+        if not os.path.exists(ud.donestamp) or ud.method.need_update(newuri, ud, ld):
+            ud.method.download(newuri, ud, ld)
             if hasattr(ud.method,"build_mirror_data"):
-                ud.method.build_mirror_data(ud, ld)
+                ud.method.build_mirror_data(newuri, ud, ld)
 
         if not ud.localpath or not os.path.exists(ud.localpath):
             return False
@@ -805,10 +805,6 @@ def try_mirror_url(origud, ud, ld, check = False):
             dest = os.path.join(dldir, os.path.basename(ud.localpath))
             if not os.path.exists(dest):
                 os.symlink(ud.localpath, dest)
-            if not os.path.exists(origud.donestamp) or origud.method.need_update(origud, ld):
-                origud.method.download(origud, ld)
-                if hasattr(ud.method,"build_mirror_data"):
-                    origud.method.build_mirror_data(origud, ld)
             return None
         # Otherwise the result is a local file:// and we symlink to it
         if not os.path.exists(origud.localpath):
@@ -817,7 +813,7 @@ def try_mirror_url(origud, ud, ld, check = False):
                 os.unlink(origud.localpath)
 
             os.symlink(ud.localpath, origud.localpath)
-        update_stamp(origud, ld)
+        update_stamp(newuri, origud, ld)
         return ud.localpath
 
     except bb.fetch2.NetworkAccess:
@@ -825,13 +821,13 @@ def try_mirror_url(origud, ud, ld, check = False):
 
     except bb.fetch2.BBFetchException as e:
         if isinstance(e, ChecksumError):
-            logger.warn("Mirror checksum failure for url %s (original url: %s)\nCleaning and trying again." % (ud.url, origud.url))
+            logger.warn("Mirror checksum failure for url %s (original url: %s)\nCleaning and trying again." % (newuri, origud.url))
             logger.warn(str(e))
             rename_bad_checksum(ud, e.checksum)
         elif isinstance(e, NoChecksumError):
             raise
         else:
-            logger.debug(1, "Mirror fetch failure for url %s (original url: %s)" % (ud.url, origud.url))
+            logger.debug(1, "Mirror fetch failure for url %s (original url: %s)" % (newuri, origud.url))
             logger.debug(1, str(e))
         try:
             ud.method.clean(ud, ld)
@@ -853,7 +849,7 @@ def try_mirrors(d, origud, mirrors, check = False):
     uris, uds = build_mirroruris(origud, mirrors, ld)
 
     for index, uri in enumerate(uris):
-        ret = try_mirror_url(origud, uds[index], ld, check)
+        ret = try_mirror_url(uri, origud, uds[index], ld, check)
         if ret != False:
             return ret
     return None
@@ -888,7 +884,7 @@ def srcrev_internal_helper(ud, d, 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, d, name)
+        rev = ud.method.latest_revision(ud.url, ud, d, name)
 
     return rev
 
@@ -1009,7 +1005,7 @@ class FetchData(object):
 
         self.method = None
         for m in methods:
-            if m.supports(self, d):
+            if m.supports(url, self, d):
                 self.method = m
                 break                
 
@@ -1031,7 +1027,7 @@ class FetchData(object):
             self.localpath = self.parm["localpath"]
             self.basename = os.path.basename(self.localpath)
         elif self.localfile:
-            self.localpath = self.method.localpath(self, d)
+            self.localpath = self.method.localpath(self.url, self, d)
 
         dldir = d.getVar("DL_DIR", True)
         # Note: .done and .lock files should always be in DL_DIR whereas localpath may not be.
@@ -1055,7 +1051,7 @@ class FetchData(object):
 
     def setup_localpath(self, d):
         if not self.localpath:
-            self.localpath = self.method.localpath(self, d)
+            self.localpath = self.method.localpath(self.url, self, d)
 
     def getSRCDate(self, d):
         """
@@ -1079,13 +1075,13 @@ class FetchMethod(object):
     def __init__(self, urls = []):
         self.urls = []
 
-    def supports(self, urldata, d):
+    def supports(self, url, urldata, d):
         """
         Check to see if this fetch class supports a given url.
         """
         return 0
 
-    def localpath(self, urldata, d):
+    def localpath(self, url, urldata, d):
         """
         Return the local filename of a given url assuming a successful fetch.
         Can also setup variables in urldata for use in go (saving code duplication
@@ -1129,7 +1125,7 @@ class FetchMethod(object):
 
     urls = property(getUrls, setUrls, None, "Urls property")
 
-    def need_update(self, ud, d):
+    def need_update(self, url, ud, d):
         """
         Force a fetch, even if localpath exists?
         """
@@ -1143,7 +1139,7 @@ class FetchMethod(object):
         """
         return False
 
-    def download(self, urldata, d):
+    def download(self, url, urldata, d):
         """
         Fetch urls
         Assumes localpath was called first
@@ -1267,13 +1263,13 @@ class FetchMethod(object):
        """
        bb.utils.remove(urldata.localpath)
 
-    def try_premirror(self, urldata, d):
+    def try_premirror(self, url, urldata, d):
         """
         Should premirrors be used?
         """
         return True
 
-    def checkstatus(self, urldata, d):
+    def checkstatus(self, url, urldata, d):
         """
         Check the status of a URL
         Assumes localpath was called first
@@ -1281,7 +1277,7 @@ class FetchMethod(object):
         logger.info("URL %s could not be checked for status since no method exists.", url)
         return True
 
-    def latest_revision(self, ud, d, name):
+    def latest_revision(self, url, ud, d, name):
         """
         Look in the cache for the latest revision, if not present ask the SCM.
         """
@@ -1289,19 +1285,19 @@ class FetchMethod(object):
             raise ParameterError("The fetcher for this URL does not support _latest_revision", url)
 
         revs = bb.persist_data.persist('BB_URI_HEADREVS', d)
-        key = self.generate_revision_key(ud, d, name)
+        key = self.generate_revision_key(url, ud, d, name)
         try:
             return revs[key]
         except KeyError:
-            revs[key] = rev = self._latest_revision(ud, d, name)
+            revs[key] = rev = self._latest_revision(url, ud, d, name)
             return rev
 
-    def sortable_revision(self, ud, d, name):
-        latest_rev = self._build_revision(ud, d, name)
+    def sortable_revision(self, url, ud, d, name):
+        latest_rev = self._build_revision(url, ud, d, name)
         return True, str(latest_rev)
 
-    def generate_revision_key(self, ud, d, name):
-        key = self._revision_key(ud, d, name)
+    def generate_revision_key(self, url, ud, d, name):
+        key = self._revision_key(url, ud, d, name)
         return "%s-%s" % (key, d.getVar("PN", True) or "")
 
 class Fetch(object):
@@ -1372,9 +1368,9 @@ class Fetch(object):
             try:
                 self.d.setVar("BB_NO_NETWORK", network)
  
-                if os.path.exists(ud.donestamp) and not m.need_update(ud, self.d):
+                if os.path.exists(ud.donestamp) and not m.need_update(u, ud, self.d):
                     localpath = ud.localpath
-                elif m.try_premirror(ud, self.d):
+                elif m.try_premirror(u, ud, self.d):
                     logger.debug(1, "Trying PREMIRRORS")
                     mirrors = mirror_from_string(self.d.getVar('PREMIRRORS', True))
                     localpath = try_mirrors(self.d, ud, mirrors, False)
@@ -1385,16 +1381,16 @@ class Fetch(object):
                 os.chdir(self.d.getVar("DL_DIR", True))
 
                 firsterr = None
-                if not localpath and ((not os.path.exists(ud.donestamp)) or m.need_update(ud, self.d)):
+                if not localpath and ((not os.path.exists(ud.donestamp)) or m.need_update(u, ud, self.d)):
                     try:
                         logger.debug(1, "Trying Upstream")
-                        m.download(ud, self.d)
+                        m.download(u, ud, self.d)
                         if hasattr(m, "build_mirror_data"):
-                            m.build_mirror_data(ud, self.d)
+                            m.build_mirror_data(u, ud, self.d)
                         localpath = ud.localpath
                         # early checksum verify, so that if checksum mismatched,
                         # fetcher still have chance to fetch from mirror
-                        update_stamp(ud, self.d)
+                        update_stamp(u, ud, self.d)
 
                     except bb.fetch2.NetworkAccess:
                         raise
@@ -1421,7 +1417,7 @@ class Fetch(object):
                         logger.error(str(firsterr))
                     raise FetchError("Unable to fetch URL from any source.", u)
 
-                update_stamp(ud, self.d)
+                update_stamp(u, ud, self.d)
 
             except BBFetchException as e:
                 if isinstance(e, NoChecksumError):
@@ -1452,7 +1448,7 @@ class Fetch(object):
             if not ret:
                 # Next try checking from the original uri, u
                 try:
-                    ret = m.checkstatus(ud, self.d)
+                    ret = m.checkstatus(u, ud, self.d)
                 except:
                     # Finally, try checking uri, u, from MIRRORS
                     mirrors = mirror_from_string(self.d.getVar('MIRRORS', True))

bitbake/lib/bb/fetch2/bzr.py

@@ -34,7 +34,7 @@ from bb.fetch2 import runfetchcmd
 from bb.fetch2 import logger
 
 class Bzr(FetchMethod):
-    def supports(self, ud, d):
+    def supports(self, url, ud, d):
         return ud.type in ['bzr']
 
     def urldata_init(self, ud, d):
@@ -48,7 +48,7 @@ class Bzr(FetchMethod):
         ud.setup_revisons(d)
 
         if not ud.revision:
-            ud.revision = self.latest_revision(ud, d)
+            ud.revision = self.latest_revision(ud.url, ud, d)
 
         ud.localfile = data.expand('bzr_%s_%s_%s.tar.gz' % (ud.host, ud.path.replace('/', '.'), ud.revision), d)
 
@@ -81,12 +81,12 @@ class Bzr(FetchMethod):
 
         return bzrcmd
 
-    def download(self, ud, d):
+    def download(self, loc, ud, d):
         """Fetch url"""
 
         if os.access(os.path.join(ud.pkgdir, os.path.basename(ud.pkgdir), '.bzr'), os.R_OK):
             bzrcmd = self._buildbzrcommand(ud, d, "update")
-            logger.debug(1, "BZR Update %s", ud.url)
+            logger.debug(1, "BZR Update %s", loc)
             bb.fetch2.check_network_access(d, bzrcmd, ud.url)
             os.chdir(os.path.join (ud.pkgdir, os.path.basename(ud.path)))
             runfetchcmd(bzrcmd, d)
@@ -94,7 +94,7 @@ class Bzr(FetchMethod):
             bb.utils.remove(os.path.join(ud.pkgdir, os.path.basename(ud.pkgdir)), True)
             bzrcmd = self._buildbzrcommand(ud, d, "fetch")
             bb.fetch2.check_network_access(d, bzrcmd, ud.url)
-            logger.debug(1, "BZR Checkout %s", ud.url)
+            logger.debug(1, "BZR Checkout %s", loc)
             bb.utils.mkdirhier(ud.pkgdir)
             os.chdir(ud.pkgdir)
             logger.debug(1, "Running %s", bzrcmd)
@@ -114,17 +114,17 @@ class Bzr(FetchMethod):
     def supports_srcrev(self):
         return True
 
-    def _revision_key(self, ud, d, name):
+    def _revision_key(self, url, ud, d, name):
         """
         Return a unique key for the url
         """
         return "bzr:" + ud.pkgdir
 
-    def _latest_revision(self, ud, d, name):
+    def _latest_revision(self, url, ud, d, name):
         """
         Return the latest upstream revision number
         """
-        logger.debug(2, "BZR fetcher hitting network for %s", ud.url)
+        logger.debug(2, "BZR fetcher hitting network for %s", url)
 
         bb.fetch2.check_network_access(d, self._buildbzrcommand(ud, d, "revno"), ud.url)
 
@@ -132,12 +132,12 @@ class Bzr(FetchMethod):
 
         return output.strip()
 
-    def sortable_revision(self, ud, d, name):
+    def sortable_revision(self, url, ud, d, name):
         """
         Return a sortable revision number which in our case is the revision number
         """
 
-        return False, self._build_revision(ud, d)
+        return False, self._build_revision(url, ud, d)
 
-    def _build_revision(self, ud, d):
+    def _build_revision(self, url, ud, d):
         return ud.revision

bitbake/lib/bb/fetch2/cvs.py

@@ -36,7 +36,7 @@ class Cvs(FetchMethod):
     """
     Class to fetch a module or modules from cvs repositories
     """
-    def supports(self, ud, d):
+    def supports(self, url, ud, d):
         """
         Check to see if a given url can be fetched with cvs.
         """
@@ -65,14 +65,14 @@ class Cvs(FetchMethod):
 
         ud.localfile = bb.data.expand('%s_%s_%s_%s%s%s.tar.gz' % (ud.module.replace('/', '.'), ud.host, ud.tag, ud.date, norecurse, fullpath), d)
 
-    def need_update(self, ud, d):
+    def need_update(self, url, ud, d):
         if (ud.date == "now"):
             return True
         if not os.path.exists(ud.localpath):
             return True
         return False
 
-    def download(self, ud, d):
+    def download(self, loc, ud, d):
 
         method = ud.parm.get('method', 'pserver')
         localdir = ud.parm.get('localdir', ud.module)
@@ -124,13 +124,13 @@ class Cvs(FetchMethod):
         pkgdir = os.path.join(d.getVar('CVSDIR', True), pkg)
         moddir = os.path.join(pkgdir, localdir)
         if os.access(os.path.join(moddir, 'CVS'), os.R_OK):
-            logger.info("Update " + ud.url)
+            logger.info("Update " + loc)
             bb.fetch2.check_network_access(d, cvsupdatecmd, ud.url)
             # update sources there
             os.chdir(moddir)
             cmd = cvsupdatecmd
         else:
-            logger.info("Fetch " + ud.url)
+            logger.info("Fetch " + loc)
             # check out sources there
             bb.utils.mkdirhier(pkgdir)
             os.chdir(pkgdir)

bitbake/lib/bb/fetch2/git.py

@@ -73,7 +73,7 @@ class Git(FetchMethod):
     def init(self, d):
         pass
 
-    def supports(self, ud, d):
+    def supports(self, url, ud, d):
         """
         Check to see if a given url can be fetched with git.
         """
@@ -125,7 +125,7 @@ class Git(FetchMethod):
             if not ud.revisions[name] or len(ud.revisions[name]) != 40  or (False in [c in "abcdef0123456789" for c in ud.revisions[name]]):
                 if ud.revisions[name]:
                     ud.branches[name] = ud.revisions[name]
-                ud.revisions[name] = self.latest_revision(ud, d, name)
+                ud.revisions[name] = self.latest_revision(ud.url, ud, d, name)
 
         gitsrcname = '%s%s' % (ud.host.replace(':','.'), ud.path.replace('/', '.').replace('*', '.'))
         # for rebaseable git repo, it is necessary to keep mirror tar ball
@@ -142,21 +142,21 @@ class Git(FetchMethod):
 
         ud.localfile = ud.clonedir
 
-    def localpath(self, ud, d):
+    def localpath(self, url, ud, d):
         return ud.clonedir
 
-    def need_update(self, ud, d):
+    def need_update(self, u, ud, d):
         if not os.path.exists(ud.clonedir):
             return True
         os.chdir(ud.clonedir)
         for name in ud.names:
-            if not self._contains_ref(ud.revisions[name], ud.branches[name], d):
+            if not self._contains_ref(ud.revisions[name], d):
                 return True
         if ud.write_tarballs and not os.path.exists(ud.fullmirror):
             return True
         return False
 
-    def try_premirror(self, ud, d):
+    def try_premirror(self, u, ud, d):
         # If we don't do this, updating an existing checkout with only premirrors
         # is not possible
         if d.getVar("BB_FETCH_PREMIRRORONLY", True) is not None:
@@ -165,7 +165,7 @@ class Git(FetchMethod):
             return False
         return True
 
-    def download(self, ud, d):
+    def download(self, loc, ud, d):
         """Fetch url"""
 
         if ud.user:
@@ -197,7 +197,7 @@ class Git(FetchMethod):
         # Update the checkout if needed
         needupdate = False
         for name in ud.names:
-            if not self._contains_ref(ud.revisions[name], ud.branches[name], d):
+            if not self._contains_ref(ud.revisions[name], d):
                 needupdate = True
         if needupdate:
             try: 
@@ -214,7 +214,7 @@ class Git(FetchMethod):
             runfetchcmd("%s pack-redundant --all | xargs -r rm" % ud.basecmd, d)
             ud.repochanged = True
 
-    def build_mirror_data(self, ud, d):
+    def build_mirror_data(self, url, ud, d):
         # Generate a mirror tarball if needed
         if ud.write_tarballs and (ud.repochanged or not os.path.exists(ud.fullmirror)):
             # it's possible that this symlink points to read-only filesystem with PREMIRROR
@@ -281,24 +281,21 @@ class Git(FetchMethod):
     def supports_srcrev(self):
         return True
 
-    def _contains_ref(self, tag, branch, d):
+    def _contains_ref(self, tag, d):
         basecmd = data.getVar("FETCHCMD_git", d, True) or "git"
-        cmd =  "%s branch --contains %s --list %s 2> /dev/null | wc -l" % (basecmd, tag, branch)
-        try:
-            output = runfetchcmd(cmd, d, quiet=True)
-        except bb.fetch2.FetchError:
-            return False
+        cmd = "%s log --pretty=oneline -n 1 %s -- 2> /dev/null | wc -l" % (basecmd, tag)
+        output = runfetchcmd(cmd, d, quiet=True)
         if len(output.split()) > 1:
             raise bb.fetch2.FetchError("The command '%s' gave output with more then 1 line unexpectedly, output: '%s'" % (cmd, output))
         return output.split()[0] != "0"
 
-    def _revision_key(self, ud, d, name):
+    def _revision_key(self, url, ud, d, name):
         """
         Return a unique key for the url
         """
         return "git:" + ud.host + ud.path.replace('/', '.') + ud.branches[name]
 
-    def _latest_revision(self, ud, d, name):
+    def _latest_revision(self, url, ud, d, name):
         """
         Compute the HEAD revision for the url
         """
@@ -314,14 +311,14 @@ class Git(FetchMethod):
             bb.fetch2.check_network_access(d, cmd)
         output = runfetchcmd(cmd, d, True)
         if not output:
-            raise bb.fetch2.FetchError("The command %s gave empty output unexpectedly" % cmd, ud.url)
+            raise bb.fetch2.FetchError("The command %s gave empty output unexpectedly" % cmd, url)
         return output.split()[0]
 
-    def _build_revision(self, ud, d, name):
+    def _build_revision(self, url, ud, d, name):
         return ud.revisions[name]
 
-    def checkstatus(self, ud, d):
-        fetchcmd = "%s ls-remote %s" % (ud.basecmd, ud.url)
+    def checkstatus(self, uri, ud, d):
+        fetchcmd = "%s ls-remote %s" % (ud.basecmd, uri)
         try:
             runfetchcmd(fetchcmd, d, quiet=True)
             return True

bitbake/lib/bb/fetch2/gitsm.py

@@ -27,7 +27,7 @@ from   bb.fetch2 import runfetchcmd
 from   bb.fetch2 import logger
 
 class GitSM(Git):
-    def supports(self, ud, d):
+    def supports(self, url, ud, d):
         """
         Check to see if a given url can be fetched with git.
         """
@@ -42,7 +42,7 @@ class GitSM(Git):
                 pass
         return False
 
-    def update_submodules(self, ud, d):
+    def update_submodules(self, u, ud, d):
         # We have to convert bare -> full repo, do the submodule bit, then convert back
         tmpclonedir = ud.clonedir + ".tmp"
         gitdir = tmpclonedir + os.sep + ".git"
@@ -58,13 +58,13 @@ class GitSM(Git):
         os.rename(gitdir, ud.clonedir,)
         bb.utils.remove(tmpclonedir, True)
 
-    def download(self, ud, d):
-        Git.download(self, ud, d)
+    def download(self, loc, ud, d):
+        Git.download(self, loc, ud, d)
 
         os.chdir(ud.clonedir)
         submodules = self.uses_submodules(ud, d)
         if submodules:
-            self.update_submodules(ud, d)
+            self.update_submodules(loc, ud, d)
 
     def unpack(self, ud, destdir, d):
         Git.unpack(self, ud, destdir, d)

bitbake/lib/bb/fetch2/hg.py

@@ -37,7 +37,7 @@ from bb.fetch2 import logger
 
 class Hg(FetchMethod):
     """Class to fetch from mercurial repositories"""
-    def supports(self, ud, d):
+    def supports(self, url, ud, d):
         """
         Check to see if a given url can be fetched with mercurial.
         """
@@ -62,11 +62,11 @@ class Hg(FetchMethod):
         if 'rev' in ud.parm:
             ud.revision = ud.parm['rev']
         elif not ud.revision:
-            ud.revision = self.latest_revision(ud, d)
+            ud.revision = self.latest_revision(ud.url, ud, d)
 
         ud.localfile = data.expand('%s_%s_%s_%s.tar.gz' % (ud.module.replace('/', '.'), ud.host, ud.path.replace('/', '.'), ud.revision), d)
 
-    def need_update(self, ud, d):
+    def need_update(self, url, ud, d):
         revTag = ud.parm.get('rev', 'tip')
         if revTag == "tip":
             return True
@@ -92,10 +92,7 @@ class Hg(FetchMethod):
         if not ud.user:
             hgroot = host + ud.path
         else:
-            if ud.pswd:
-                hgroot = ud.user + ":" + ud.pswd + "@" + host + ud.path
-            else:
-                hgroot = ud.user + "@" + host + ud.path
+            hgroot = ud.user + "@" + host + ud.path
 
         if command == "info":
             return "%s identify -i %s://%s/%s" % (basecmd, proto, hgroot, ud.module)
@@ -115,10 +112,7 @@ class Hg(FetchMethod):
             # do not pass options list; limiting pull to rev causes the local
             # repo not to contain it and immediately following "update" command
             # will crash
-            if ud.user and ud.pswd:
-                cmd = "%s --config auth.default.prefix=* --config auth.default.username=%s --config auth.default.password=%s --config \"auth.default.schemes=%s\" pull" % (basecmd, ud.user, ud.pswd, proto)
-            else:
-                cmd = "%s pull" % (basecmd)
+            cmd = "%s pull" % (basecmd)
         elif command == "update":
             cmd = "%s update -C %s" % (basecmd, " ".join(options))
         else:
@@ -126,14 +120,14 @@ class Hg(FetchMethod):
 
         return cmd
 
-    def download(self, ud, d):
+    def download(self, loc, ud, d):
         """Fetch url"""
 
         logger.debug(2, "Fetch: checking for module directory '" + ud.moddir + "'")
 
         if os.access(os.path.join(ud.moddir, '.hg'), os.R_OK):
             updatecmd = self._buildhgcommand(ud, d, "pull")
-            logger.info("Update " + ud.url)
+            logger.info("Update " + loc)
             # update sources there
             os.chdir(ud.moddir)
             logger.debug(1, "Running %s", updatecmd)
@@ -142,7 +136,7 @@ class Hg(FetchMethod):
 
         else:
             fetchcmd = self._buildhgcommand(ud, d, "fetch")
-            logger.info("Fetch " + ud.url)
+            logger.info("Fetch " + loc)
             # check out sources there
             bb.utils.mkdirhier(ud.pkgdir)
             os.chdir(ud.pkgdir)
@@ -169,7 +163,7 @@ class Hg(FetchMethod):
     def supports_srcrev(self):
         return True
 
-    def _latest_revision(self, ud, d, name):
+    def _latest_revision(self, url, ud, d, name):
         """
         Compute tip revision for the url
         """
@@ -177,10 +171,10 @@ class Hg(FetchMethod):
         output = runfetchcmd(self._buildhgcommand(ud, d, "info"), d)
         return output.strip()
 
-    def _build_revision(self, ud, d, name):
+    def _build_revision(self, url, ud, d, name):
         return ud.revision
 
-    def _revision_key(self, ud, d, name):
+    def _revision_key(self, url, ud, d, name):
         """
         Return a unique key for the url
         """

bitbake/lib/bb/fetch2/local.py

@@ -34,7 +34,7 @@ from   bb.fetch2 import FetchMethod, FetchError
 from   bb.fetch2 import logger
 
 class Local(FetchMethod):
-    def supports(self, urldata, d):
+    def supports(self, url, urldata, d):
         """
         Check to see if a given url represents a local fetch.
         """
@@ -47,7 +47,7 @@ class Local(FetchMethod):
         ud.basepath = ud.decodedurl
         return
 
-    def localpath(self, urldata, d):
+    def localpath(self, url, urldata, d):
         """
         Return the local filename of a given url assuming a successful fetch.
         """
@@ -75,14 +75,14 @@ class Local(FetchMethod):
                 return dldirfile
         return newpath
 
-    def need_update(self, ud, d):
-        if ud.url.find("*") != -1:
+    def need_update(self, url, ud, d):
+        if url.find("*") != -1:
             return False
         if os.path.exists(ud.localpath):
             return False
         return True
 
-    def download(self, urldata, d):
+    def download(self, url, urldata, d):
         """Fetch urls (no-op for Local method)"""
         # no need to fetch local files, we'll deal with them in place.
         if self.supports_checksum(urldata) and not os.path.exists(urldata.localpath):
@@ -95,17 +95,17 @@ class Local(FetchMethod):
                 locations.append(filesdir)
             locations.append(d.getVar("DL_DIR", True))
 
-            msg = "Unable to find file " + urldata.url + " anywhere. The paths that were searched were:\n    " + "\n    ".join(locations)
+            msg = "Unable to find file " + url + " anywhere. The paths that were searched were:\n    " + "\n    ".join(locations)
             raise FetchError(msg)
 
         return True
 
-    def checkstatus(self, urldata, d):
+    def checkstatus(self, url, urldata, d):
         """
         Check the status of the url
         """
         if urldata.localpath.find("*") != -1:
-            logger.info("URL %s looks like a glob and was therefore not checked.", urldata.url)
+            logger.info("URL %s looks like a glob and was therefore not checked.", url)
             return True
         if os.path.exists(urldata.localpath):
             return True

bitbake/lib/bb/fetch2/osc.py

@@ -20,7 +20,7 @@ class Osc(FetchMethod):
     """Class to fetch a module or modules from Opensuse build server
        repositories."""
 
-    def supports(self, ud, d):
+    def supports(self, url, ud, d):
         """
         Check to see if a given url can be fetched with osc.
         """
@@ -77,7 +77,7 @@ class Osc(FetchMethod):
 
         return osccmd
 
-    def download(self, ud, d):
+    def download(self, loc, ud, d):
         """
         Fetch url
         """
@@ -86,7 +86,7 @@ class Osc(FetchMethod):
 
         if os.access(os.path.join(data.expand('${OSCDIR}', d), ud.path, ud.module), os.R_OK):
             oscupdatecmd = self._buildosccommand(ud, d, "update")
-            logger.info("Update "+ ud.url)
+            logger.info("Update "+ loc)
             # update sources there
             os.chdir(ud.moddir)
             logger.debug(1, "Running %s", oscupdatecmd)
@@ -94,7 +94,7 @@ class Osc(FetchMethod):
             runfetchcmd(oscupdatecmd, d)
         else:
             oscfetchcmd = self._buildosccommand(ud, d, "fetch")
-            logger.info("Fetch " + ud.url)
+            logger.info("Fetch " + loc)
             # check out sources there
             bb.utils.mkdirhier(ud.pkgdir)
             os.chdir(ud.pkgdir)

bitbake/lib/bb/fetch2/perforce.py

@@ -37,7 +37,7 @@ from   bb.fetch2 import logger
 from   bb.fetch2 import runfetchcmd
 
 class Perforce(FetchMethod):
-    def supports(self, ud, d):
+    def supports(self, url, ud, d):
         return ud.type in ['p4']
 
     def doparse(url, d):
@@ -112,7 +112,7 @@ class Perforce(FetchMethod):
         base = path
         which = path.find('/...')
         if which != -1:
-            base = path[:which-1]
+            base = path[:which]
 
         base = self._strip_leading_slashes(base)
 
@@ -120,12 +120,12 @@ class Perforce(FetchMethod):
 
         ud.localfile = data.expand('%s+%s+%s.tar.gz' % (host, base.replace('/', '.'), cset), d)
 
-    def download(self, ud, d):
+    def download(self, loc, ud, d):
         """
         Fetch urls
         """
 
-        (host, depot, user, pswd, parm) = Perforce.doparse(ud.url, d)
+        (host, depot, user, pswd, parm) = Perforce.doparse(loc, d)
 
         if depot.find('/...') != -1:
             path = depot[:depot.find('/...')]
@@ -158,7 +158,7 @@ class Perforce(FetchMethod):
         tmpfile, errors = bb.process.run(data.getVar('MKTEMPDIRCMD', localdata, True) or "false")
         tmpfile = tmpfile.strip()
         if not tmpfile:
-            raise FetchError("Fetch: unable to create temporary directory.. make sure 'mktemp' is in the PATH.", ud.url)
+            raise FetchError("Fetch: unable to create temporary directory.. make sure 'mktemp' is in the PATH.", loc)
 
         if "label" in parm:
             depot = "%s@%s" % (depot, parm["label"])
@@ -167,13 +167,13 @@ class Perforce(FetchMethod):
             depot = "%s@%s" % (depot, cset)
 
         os.chdir(tmpfile)
-        logger.info("Fetch " + ud.url)
+        logger.info("Fetch " + loc)
         logger.info("%s%s files %s", p4cmd, p4opt, depot)
         p4file, errors = bb.process.run("%s%s files %s" % (p4cmd, p4opt, depot))
         p4file = [f.rstrip() for f in p4file.splitlines()]
 
         if not p4file:
-            raise FetchError("Fetch: unable to get the P4 files from %s" % depot, ud.url)
+            raise FetchError("Fetch: unable to get the P4 files from %s" % depot, loc)
 
         count = 0
 
@@ -191,7 +191,7 @@ class Perforce(FetchMethod):
 
         if count == 0:
             logger.error()
-            raise FetchError("Fetch: No files gathered from the P4 fetch", ud.url)
+            raise FetchError("Fetch: No files gathered from the P4 fetch", loc)
 
         runfetchcmd("tar -czf %s %s" % (ud.localpath, module), d, cleanup = [ud.localpath])
         # cleanup

bitbake/lib/bb/fetch2/repo.py

@@ -31,7 +31,7 @@ from   bb.fetch2 import runfetchcmd
 
 class Repo(FetchMethod):
     """Class to fetch a module or modules from repo (git) repositories"""
-    def supports(self, ud, d):
+    def supports(self, url, ud, d):
         """
         Check to see if a given url can be fetched with repo.
         """
@@ -53,7 +53,7 @@ class Repo(FetchMethod):
 
         ud.localfile = data.expand("repo_%s%s_%s_%s.tar.gz" % (ud.host, ud.path.replace("/", "."), ud.manifest, ud.branch), d)
 
-    def download(self, ud, d):
+    def download(self, loc, ud, d):
         """Fetch url"""
 
         if os.access(os.path.join(data.getVar("DL_DIR", d, True), ud.localfile), os.R_OK):
@@ -91,8 +91,8 @@ class Repo(FetchMethod):
     def supports_srcrev(self):
         return False
 
-    def _build_revision(self, ud, d):
+    def _build_revision(self, url, ud, d):
         return ud.manifest
 
-    def _want_sortable_revision(self, ud, d):
+    def _want_sortable_revision(self, url, ud, d):
         return False

bitbake/lib/bb/fetch2/sftp.py

@@ -72,7 +72,7 @@ from bb.fetch2 import runfetchcmd
 class SFTP(FetchMethod):
     """Class to fetch urls via 'sftp'"""
 
-    def supports(self, ud, d):
+    def supports(self, url, ud, d):
         """
         Check to see if a given url can be fetched with sftp.
         """
@@ -95,10 +95,10 @@ class SFTP(FetchMethod):
 
         ud.localfile = data.expand(urllib.unquote(ud.basename), d)
 
-    def download(self, ud, d):
+    def download(self, uri, ud, d):
         """Fetch urls"""
 
-        urlo = URI(ud.url)
+        urlo = URI(uri)
         basecmd = 'sftp -oPasswordAuthentication=no'
         port = ''
         if urlo.port:
@@ -124,6 +124,6 @@ class SFTP(FetchMethod):
         cmd = '%s %s %s %s' % (basecmd, port, commands.mkarg(remote),
                                commands.mkarg(lpath))
 
-        bb.fetch2.check_network_access(d, cmd, ud.url)
+        bb.fetch2.check_network_access(d, cmd, uri)
         runfetchcmd(cmd, d)
         return True

bitbake/lib/bb/fetch2/ssh.py

@@ -72,8 +72,8 @@ __pattern__ = re.compile(r'''
 class SSH(FetchMethod):
     '''Class to fetch a module or modules via Secure Shell'''
 
-    def supports(self, urldata, d):
-        return __pattern__.match(urldata.url) != None
+    def supports(self, url, urldata, d):
+        return __pattern__.match(url) != None
 
     def supports_checksum(self, urldata):
         return False
@@ -89,10 +89,10 @@ class SSH(FetchMethod):
         host = m.group('host')
         urldata.localpath = os.path.join(d.getVar('DL_DIR', True), os.path.basename(path))
 
-    def download(self, urldata, d):
+    def download(self, url, urldata, d):
         dldir = d.getVar('DL_DIR', True)
 
-        m = __pattern__.match(urldata.url)
+        m = __pattern__.match(url)
         path = m.group('path')
         host = m.group('host')
         port = m.group('port')

bitbake/lib/bb/fetch2/svk.py

@@ -37,7 +37,7 @@ from   bb.fetch2 import runfetchcmd
 
 class Svk(FetchMethod):
     """Class to fetch a module or modules from svk repositories"""
-    def supports(self, ud, d):
+    def supports(self, url, ud, d):
         """
         Check to see if a given url can be fetched with svk.
         """
@@ -54,14 +54,14 @@ class Svk(FetchMethod):
 
         ud.localfile = data.expand('%s_%s_%s_%s_%s.tar.gz' % (ud.module.replace('/', '.'), ud.host, ud.path.replace('/', '.'), ud.revision, ud.date), d)
 
-    def need_update(self, ud, d):
+    def need_update(self, url, ud, d):
         if ud.date == "now":
             return True
         if not os.path.exists(ud.localpath):
             return True
         return False
 
-    def download(self, ud, d):
+    def download(self, loc, ud, d):
         """Fetch urls"""
 
         svkroot = ud.host + ud.path
@@ -81,11 +81,11 @@ class Svk(FetchMethod):
         tmpfile = tmpfile.strip()
         if not tmpfile:
             logger.error()
-            raise FetchError("Fetch: unable to create temporary directory.. make sure 'mktemp' is in the PATH.", ud.url)
+            raise FetchError("Fetch: unable to create temporary directory.. make sure 'mktemp' is in the PATH.", loc)
 
         # check out sources there
         os.chdir(tmpfile)
-        logger.info("Fetch " + ud.url)
+        logger.info("Fetch " + loc)
         logger.debug(1, "Running %s", svkcmd)
         runfetchcmd(svkcmd, d, cleanup = [tmpfile])
 

bitbake/lib/bb/fetch2/svn.py

@@ -27,7 +27,6 @@ import os
 import sys
 import logging
 import bb
-import re
 from   bb import data
 from   bb.fetch2 import FetchMethod
 from   bb.fetch2 import FetchError
@@ -37,7 +36,7 @@ from   bb.fetch2 import logger
 
 class Svn(FetchMethod):
     """Class to fetch a module or modules from svn repositories"""
-    def supports(self, ud, d):
+    def supports(self, url, ud, d):
         """
         Check to see if a given url can be fetched with svn.
         """
@@ -92,8 +91,6 @@ class Svn(FetchMethod):
 
         if command == "info":
             svncmd = "%s info %s %s://%s/%s/" % (ud.basecmd, " ".join(options), proto, svnroot, ud.module)
-        elif command == "log1":
-            svncmd = "%s log --limit 1 %s %s://%s/%s/" % (ud.basecmd, " ".join(options), proto, svnroot, ud.module)
         else:
             suffix = ""
             if ud.revision:
@@ -112,14 +109,14 @@ class Svn(FetchMethod):
 
         return svncmd
 
-    def download(self, ud, d):
+    def download(self, loc, ud, d):
         """Fetch url"""
 
         logger.debug(2, "Fetch: checking for module directory '" + ud.moddir + "'")
 
         if os.access(os.path.join(ud.moddir, '.svn'), os.R_OK):
             svnupdatecmd = self._buildsvncommand(ud, d, "update")
-            logger.info("Update " + ud.url)
+            logger.info("Update " + loc)
             # update sources there
             os.chdir(ud.moddir)
             # We need to attempt to run svn upgrade first in case its an older working format
@@ -132,7 +129,7 @@ class Svn(FetchMethod):
             runfetchcmd(svnupdatecmd, d)
         else:
             svnfetchcmd = self._buildsvncommand(ud, d, "fetch")
-            logger.info("Fetch " + ud.url)
+            logger.info("Fetch " + loc)
             # check out sources there
             bb.utils.mkdirhier(ud.pkgdir)
             os.chdir(ud.pkgdir)
@@ -160,32 +157,33 @@ class Svn(FetchMethod):
     def supports_srcrev(self):
         return True
 
-    def _revision_key(self, ud, d, name):
+    def _revision_key(self, url, ud, d, name):
         """
         Return a unique key for the url
         """
         return "svn:" + ud.moddir
 
-    def _latest_revision(self, ud, d, name):
+    def _latest_revision(self, url, ud, d, name):
         """
         Return the latest upstream revision number
         """
-        bb.fetch2.check_network_access(d, self._buildsvncommand(ud, d, "log1"))
+        bb.fetch2.check_network_access(d, self._buildsvncommand(ud, d, "info"))
 
-        output = runfetchcmd("LANG=C LC_ALL=C " + self._buildsvncommand(ud, d, "log1"), d, True)
+        output = runfetchcmd("LANG=C LC_ALL=C " + self._buildsvncommand(ud, d, "info"), d, True)
 
-        # skip the first line, as per output of svn log
-        # then we expect the revision on the 2nd line
-        revision = re.search('^r([0-9]*)', output.splitlines()[1]).group(1)
+        revision = None
+        for line in output.splitlines():
+            if "Last Changed Rev" in line:
+                revision = line.split(":")[1].strip()
 
         return revision
 
-    def sortable_revision(self, ud, d, name):
+    def sortable_revision(self, url, ud, d, name):
         """
         Return a sortable revision number which in our case is the revision number
         """
 
-        return False, self._build_revision(ud, d)
+        return False, self._build_revision(url, ud, d)
 
-    def _build_revision(self, ud, d):
+    def _build_revision(self, url, ud, d):
         return ud.revision

bitbake/lib/bb/fetch2/wget.py

@@ -37,7 +37,7 @@ from   bb.fetch2 import runfetchcmd
 
 class Wget(FetchMethod):
     """Class to fetch urls via 'wget'"""
-    def supports(self, ud, d):
+    def supports(self, url, ud, d):
         """
         Check to see if a given url can be fetched with wget.
         """
@@ -58,7 +58,7 @@ class Wget(FetchMethod):
 
         ud.localfile = data.expand(urllib.unquote(ud.basename), d)
 
-    def download(self, ud, d, checkonly = False):
+    def download(self, uri, ud, d, checkonly = False):
         """Fetch urls"""
 
         basecmd = d.getVar("FETCHCMD_wget", True) or "/usr/bin/env wget -t 2 -T 30 -nv --passive-ftp --no-check-certificate"
@@ -76,7 +76,7 @@ class Wget(FetchMethod):
         else:
             fetchcmd = d.getVar("FETCHCOMMAND_wget", True) or d.expand(basecmd + " -P ${DL_DIR} '${URI}'")
 
-        uri = ud.url.split(";")[0]
+        uri = uri.split(";")[0]
 
         fetchcmd = fetchcmd.replace("${URI}", uri.split(";")[0])
         fetchcmd = fetchcmd.replace("${FILE}", ud.basename)
@@ -93,5 +93,5 @@ class Wget(FetchMethod):
 
         return True
 
-    def checkstatus(self, ud, d):
-        return self.download(ud, d, True)
+    def checkstatus(self, uri, ud, d):
+        return self.download(uri, ud, d, True)

bitbake/lib/bb/monitordisk.py

@@ -243,7 +243,7 @@ class diskMonitor:
                     # zero, this is a feature of the fs, we disable the inode
                     # checking for such a fs.
                     if st.f_files == 0:
-                        logger.info("Inode check for %s is unavaliable, will remove it from disk monitor" % path)
+                        logger.warn("Inode check for %s is unavaliable, will remove it from disk monitor" % path)
                         self.devDict[k][2] = None
                         continue
                     # Always show warning, the self.checked would always be False if the action is WARN

bitbake/lib/bb/parse/__init__.py

@@ -73,17 +73,9 @@ def update_mtime(f):
 def mark_dependency(d, f):
     if f.startswith('./'):
         f = "%s/%s" % (os.getcwd(), f[2:])
-    deps = (d.getVar('__depends') or [])
-    s = (f, cached_mtime_noerror(f))
-    if s not in deps:
-        deps.append(s)
-        d.setVar('__depends', deps)
+    deps = (d.getVar('__depends') or []) + [(f, cached_mtime(f))]
+    d.setVar('__depends', deps)
 
-def check_dependency(d, f):
-    s = (f, cached_mtime_noerror(f))
-    deps = (d.getVar('__depends') or [])
-    return s in deps
-   
 def supports(fn, data):
     """Returns true if we have a handler for this file, false otherwise"""
     for h in handlers:
@@ -110,14 +102,11 @@ def init_parser(d):
 def resolve_file(fn, d):
     if not os.path.isabs(fn):
         bbpath = d.getVar("BBPATH", True)
-        newfn, attempts = bb.utils.which(bbpath, fn, history=True)
-        for af in attempts:
-            mark_dependency(d, af)
+        newfn = bb.utils.which(bbpath, fn)
         if not newfn:
             raise IOError("file %s not found in %s" % (fn, bbpath))
         fn = newfn
 
-    mark_dependency(d, fn)
     if not os.path.isfile(fn):
         raise IOError("file %s not found" % fn)
 

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

@@ -77,10 +77,7 @@ def inherit(files, fn, lineno, d):
         if not os.path.isabs(file):
             dname = os.path.dirname(fn)
             bbpath = "%s:%s" % (dname, d.getVar("BBPATH", True))
-            abs_fn, attempts = bb.utils.which(bbpath, file, history=True)
-            for af in attempts:
-                if af != abs_fn:
-                    bb.parse.mark_dependency(d, af)
+            abs_fn = bb.utils.which(bbpath, file)
             if abs_fn:
                 file = abs_fn
 

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

@@ -82,15 +82,9 @@ def include(oldfn, fn, lineno, data, error_out):
     if not os.path.isabs(fn):
         dname = os.path.dirname(oldfn)
         bbpath = "%s:%s" % (dname, data.getVar("BBPATH", True))
-        abs_fn, attempts = bb.utils.which(bbpath, fn, history=True)
-        if abs_fn and bb.parse.check_dependency(data, abs_fn):
-            bb.warn("Duplicate inclusion for %s in %s" % (abs_fn, data.getVar('FILE', True)))
-        for af in attempts:
-            bb.parse.mark_dependency(data, af)
+        abs_fn = bb.utils.which(bbpath, fn)
         if abs_fn:
             fn = abs_fn
-    elif bb.parse.check_dependency(data, fn):
-        bb.warn("Duplicate inclusion for %s in %s" % (fn, data.getVar('FILE', True)))
 
     from bb.parse import handle
     try:
@@ -99,7 +93,6 @@ def include(oldfn, fn, lineno, data, error_out):
         if error_out:
             raise ParseError("Could not %(error_out)s file %(fn)s" % vars(), oldfn, lineno)
         logger.debug(2, "CONF file '%s' not found", fn)
-        bb.parse.mark_dependency(data, fn)
 
 # We have an issue where a UI might want to enforce particular settings such as
 # an empty DISTRO variable. If configuration files do something like assigning

bitbake/lib/bb/runqueue.py

@@ -98,49 +98,26 @@ class RunQueueScheduler(object):
         """
         self.rq = runqueue
         self.rqdata = rqdata
-        self.numTasks = len(self.rqdata.runq_fnid)
+        numTasks = len(self.rqdata.runq_fnid)
 
         self.prio_map = []
-        self.prio_map.extend(range(self.numTasks))
-
-        self.buildable = []
-        self.stamps = {}
-        for taskid in xrange(self.numTasks):
-            fn = self.rqdata.taskData.fn_index[self.rqdata.runq_fnid[taskid]]
-            taskname = self.rqdata.runq_task[taskid]
-            self.stamps[taskid] = bb.build.stampfile(taskname, self.rqdata.dataCache, fn)
-            if self.rq.runq_buildable[taskid] == 1:
-                self.buildable.append(taskid)
-
-        self.rev_prio_map = None
+        self.prio_map.extend(range(numTasks))
 
     def next_buildable_task(self):
         """
         Return the id of the first task we find that is buildable
         """
-        self.buildable = [x for x in self.buildable if not self.rq.runq_running[x] == 1]
-        if not self.buildable:
-            return None
-        if len(self.buildable) == 1:
-            return self.buildable[0]
-
-        if not self.rev_prio_map:
-            self.rev_prio_map = range(self.numTasks)
-            for taskid in xrange(self.numTasks):
-                self.rev_prio_map[self.prio_map[taskid]] = taskid
-
-        best = None
-        bestprio = None
-        for taskid in self.buildable:
-            prio = self.rev_prio_map[taskid]
-            if not bestprio or bestprio > prio:
-                stamp = self.stamps[taskid]
-                if stamp in self.rq.build_stamps.itervalues():
+        for tasknum in xrange(len(self.rqdata.runq_fnid)):
+            taskid = self.prio_map[tasknum]
+            if self.rq.runq_running[taskid] == 1:
+                continue
+            if self.rq.runq_buildable[taskid] == 1:
+                fn = self.rqdata.taskData.fn_index[self.rqdata.runq_fnid[taskid]]
+                taskname = self.rqdata.runq_task[taskid]
+                stamp = bb.build.stampfile(taskname, self.rqdata.dataCache, fn)
+                if stamp in self.rq.build_stamps.values():
                     continue
-                bestprio = prio
-                best = taskid
-
-        return best
+                return taskid
 
     def next(self):
         """
@@ -149,9 +126,6 @@ class RunQueueScheduler(object):
         if self.rq.stats.active < self.rq.number_tasks:
             return self.next_buildable_task()
 
-    def newbuilable(self, task):
-        self.buildable.append(task)
-
 class RunQueueSchedulerSpeed(RunQueueScheduler):
     """
     A scheduler optimised for speed. The priority map is sorted by task weight,
@@ -163,7 +137,9 @@ class RunQueueSchedulerSpeed(RunQueueScheduler):
         """
         The priority map is sorted by task weight.
         """
-        RunQueueScheduler.__init__(self, runqueue, rqdata)
+
+        self.rq = runqueue
+        self.rqdata = rqdata
 
         sortweight = sorted(copy.deepcopy(self.rqdata.runq_weight))
         copyweight = copy.deepcopy(self.rqdata.runq_weight)
@@ -1140,7 +1116,6 @@ class RunQueueExecute:
         self.runq_complete = []
 
         self.build_stamps = {}
-        self.build_stamps2 = []
         self.failed_fnids = []
 
         self.stampcache = {}
@@ -1153,7 +1128,6 @@ class RunQueueExecute:
 
         # self.build_stamps[pid] may not exist when use shared work directory.
         if task in self.build_stamps:
-            self.build_stamps2.remove(self.build_stamps[task])
             del self.build_stamps[task]
 
         if status != 0:
@@ -1230,8 +1204,6 @@ class RunQueueExecuteTasks(RunQueueExecute):
 
         self.stampcache = {}
 
-        initial_covered = self.rq.scenequeue_covered.copy()
-
         # Mark initial buildable tasks
         for task in xrange(self.stats.total):
             self.runq_running.append(0)
@@ -1285,27 +1257,12 @@ class RunQueueExecuteTasks(RunQueueExecute):
             except TypeError:
                 covered_remove = bb.utils.better_eval(call2, locs)
 
-        def removecoveredtask(task):
+        for task in covered_remove:
             fn = self.rqdata.taskData.fn_index[self.rqdata.runq_fnid[task]]
             taskname = self.rqdata.runq_task[task] + '_setscene'
             bb.build.del_stamp(taskname, self.rqdata.dataCache, fn)
-            self.rq.scenequeue_covered.remove(task)
-
-        toremove = covered_remove
-        for task in toremove:
             logger.debug(1, 'Not skipping task %s due to setsceneverify', task)
-        while toremove:
-            covered_remove = []
-            for task in toremove:
-                removecoveredtask(task)
-                for deptask in self.rqdata.runq_depends[task]:
-                    if deptask not in self.rq.scenequeue_covered:
-                        continue
-                    if deptask in toremove or deptask in covered_remove or deptask in initial_covered:
-                        continue
-                    logger.debug(1, 'Task %s depends on task %s so not skipping' % (task, deptask))
-                    covered_remove.append(deptask)
-            toremove = covered_remove
+            self.rq.scenequeue_covered.remove(task)
 
         logger.debug(1, 'Full skip list %s', self.rq.scenequeue_covered)
 
@@ -1343,10 +1300,6 @@ class RunQueueExecuteTasks(RunQueueExecute):
                     schedulers.add(getattr(module, name))
         return schedulers
 
-    def setbuildable(self, task):
-        self.runq_buildable[task] = 1
-        self.sched.newbuilable(task)
-
     def task_completeoutright(self, task):
         """
         Mark a task as completed
@@ -1364,7 +1317,7 @@ class RunQueueExecuteTasks(RunQueueExecute):
                 if self.runq_complete[dep] != 1:
                     alldeps = 0
             if alldeps == 1:
-                self.setbuildable(revdep)
+                self.runq_buildable[revdep] = 1
                 fn = self.rqdata.taskData.fn_index[self.rqdata.runq_fnid[revdep]]
                 taskname = self.rqdata.runq_task[revdep]
                 logger.debug(1, "Marking task %s (%s, %s) as buildable", revdep, fn, taskname)
@@ -1388,7 +1341,7 @@ class RunQueueExecuteTasks(RunQueueExecute):
 
     def task_skip(self, task, reason):
         self.runq_running[task] = 1
-        self.setbuildable(task)
+        self.runq_buildable[task] = 1
         bb.event.fire(runQueueTaskSkipped(task, self.stats, self.rq, reason), self.cfgData)
         self.task_completeoutright(task)
         self.stats.taskCompleted()
@@ -1437,20 +1390,17 @@ class RunQueueExecuteTasks(RunQueueExecute):
                 startevent = runQueueTaskStarted(task, self.stats, self.rq)
                 bb.event.fire(startevent, self.cfgData)
 
-            taskdepdata = self.build_taskdepdata(task)
-
             taskdep = self.rqdata.dataCache.task_deps[fn]
-            if 'fakeroot' in taskdep and taskname in taskdep['fakeroot'] and not self.cooker.configuration.dry_run:
+            if 'fakeroot' in taskdep and taskname in taskdep['fakeroot']:
                 if not self.rq.fakeworker:
                     self.rq.start_fakeworker(self)
-                self.rq.fakeworker.stdin.write("<runtask>" + pickle.dumps((fn, task, taskname, False, self.cooker.collection.get_file_appends(fn), taskdepdata)) + "</runtask>")
+                self.rq.fakeworker.stdin.write("<runtask>" + pickle.dumps((fn, task, taskname, False, self.cooker.collection.get_file_appends(fn))) + "</runtask>")
                 self.rq.fakeworker.stdin.flush()
             else:
-                self.rq.worker.stdin.write("<runtask>" + pickle.dumps((fn, task, taskname, False, self.cooker.collection.get_file_appends(fn), taskdepdata)) + "</runtask>")
+                self.rq.worker.stdin.write("<runtask>" + pickle.dumps((fn, task, taskname, False, self.cooker.collection.get_file_appends(fn))) + "</runtask>")
                 self.rq.worker.stdin.flush()
 
             self.build_stamps[task] = bb.build.stampfile(taskname, self.rqdata.dataCache, fn)
-            self.build_stamps2.append(self.build_stamps[task]) 
             self.runq_running[task] = 1
             self.stats.taskActive()
             if self.stats.active < self.number_tasks:
@@ -1476,26 +1426,6 @@ class RunQueueExecuteTasks(RunQueueExecute):
 
         return True
 
-    def build_taskdepdata(self, task):
-        taskdepdata = {}
-        next = self.rqdata.runq_depends[task]
-        next.add(task)
-        while next:
-            additional = []
-            for revdep in next:
-                fn = self.rqdata.taskData.fn_index[self.rqdata.runq_fnid[revdep]]
-                pn = self.rqdata.dataCache.pkg_fn[fn]
-                taskname = self.rqdata.runq_task[revdep]
-                deps = self.rqdata.runq_depends[revdep]
-                taskdepdata[revdep] = [pn, taskname, fn, deps]
-                for revdep2 in deps:
-                    if revdep2 not in taskdepdata:
-                        additional.append(revdep2)
-            next = additional
-
-        #bb.note("Task %s: " % task + str(taskdepdata).replace("], ", "],\n"))
-        return taskdepdata
-
 class RunQueueExecuteScenequeue(RunQueueExecute):
     def __init__(self, rq):
         RunQueueExecute.__init__(self, rq)
@@ -1806,10 +1736,10 @@ class RunQueueExecuteScenequeue(RunQueueExecute):
             if 'fakeroot' in taskdep and taskname in taskdep['fakeroot']:
                 if not self.rq.fakeworker:
                     self.rq.start_fakeworker(self)
-                self.rq.fakeworker.stdin.write("<runtask>" + pickle.dumps((fn, realtask, taskname, True, self.cooker.collection.get_file_appends(fn), None)) + "</runtask>")
+                self.rq.fakeworker.stdin.write("<runtask>" + pickle.dumps((fn, realtask, taskname, True, self.cooker.collection.get_file_appends(fn))) + "</runtask>")
                 self.rq.fakeworker.stdin.flush()
             else:
-                self.rq.worker.stdin.write("<runtask>" + pickle.dumps((fn, realtask, taskname, True, self.cooker.collection.get_file_appends(fn), None)) + "</runtask>")
+                self.rq.worker.stdin.write("<runtask>" + pickle.dumps((fn, realtask, taskname, True, self.cooker.collection.get_file_appends(fn))) + "</runtask>")
                 self.rq.worker.stdin.flush()
 
             self.runq_running[task] = 1

bitbake/lib/bb/server/xmlrpc.py

@@ -198,11 +198,6 @@ class XMLRPCServer(SimpleXMLRPCServer, BaseImplServer):
         Constructor
         """
         BaseImplServer.__init__(self)
-        if (interface[1] == 0):     # anonymous port, not getting reused
-            self.single_use = True
-        # Use auto port configuration
-        if (interface[1] == -1):
-            interface = (interface[0], 0)
         SimpleXMLRPCServer.__init__(self, interface,
                                     requestHandler=BitBakeXMLRPCRequestHandler,
                                     logRequests=False, allow_none=True)
@@ -213,6 +208,8 @@ class XMLRPCServer(SimpleXMLRPCServer, BaseImplServer):
         self.autoregister_all_functions(self.commands, "")
         self.interface = interface
         self.single_use = False
+        if (interface[1] == 0):     # anonymous port, not getting reused
+            self.single_use = True
 
     def addcooker(self, cooker):
         BaseImplServer.addcooker(self, cooker)
@@ -341,38 +338,13 @@ class BitBakeXMLRPCClient(BitBakeBaseServer):
     def saveConnectionDetails(self, remote):
         self.remote = remote
 
-    def saveConnectionConfigParams(self, configParams):
-        self.configParams = configParams
-
     def establishConnection(self, featureset):
         # The format of "remote" must be "server:port"
         try:
             [host, port] = self.remote.split(":")
             port = int(port)
-        except Exception as e:
-            bb.fatal("Failed to read remote definition (%s)" % str(e))
-
-        # use automatic port if port set to -1, meaning read it from
-        # the bitbake.lock file
-        if port == -1:
-            lock_location = "%s/bitbake.lock" % self.configParams.environment.get('BUILDDIR')
-            lock = bb.utils.lockfile(lock_location, False, False)
-            if lock:
-                # This means there is no server running which we can
-                # connect to on the local system.
-                bb.utils.unlockfile(lock)
-                return None
-
-            try:
-                lf = open(lock_location, 'r')
-                remotedef = lf.readline()
-                [host, port] = remotedef.split(":")
-                port = int(port)
-                lf.close()
-                self.remote = remotedef
-            except Exception as e:
-                bb.fatal("Failed to read bitbake.lock (%s)" % str(e))
-
+        except:
+            return None
         # We need our IP for the server connection. We get the IP
         # by trying to connect with the server
         try:
@@ -380,8 +352,8 @@ class BitBakeXMLRPCClient(BitBakeBaseServer):
             s.connect((host, port))
             ip = s.getsockname()[0]
             s.close()
-        except Exception as e:
-            bb.fatal("Could not create socket for %s:%s (%s)" % (host, port, str(e)))
+        except:
+            return None
         try:
             self.serverImpl = XMLRPCProxyServer(host, port)
             self.connection = BitBakeXMLRPCServerConnection(self.serverImpl, (ip, 0), self.observer_only, featureset)

bitbake/lib/bb/siggen.py

@@ -224,7 +224,7 @@ class SignatureGeneratorBasic(SignatureGenerator):
 
         if runtime and k in self.taskhash:
             data['runtaskdeps'] = self.runtaskdeps[k]
-            data['file_checksum_values'] = [(os.path.basename(f), cs) for f,cs in self.file_checksum_values[k].items()]
+            data['file_checksum_values'] = self.file_checksum_values[k]
             data['runtaskhashes'] = {}
             for dep in data['runtaskdeps']:
                 data['runtaskhashes'][dep] = self.taskhash[dep]
@@ -322,39 +322,6 @@ def compare_sigfiles(a, b, recursecb = None):
         removed = sb - sa
         return changed, added, removed
 
-    def file_checksums_diff(a, b):
-        from collections import Counter
-        # Handle old siginfo format
-        if isinstance(a, dict):
-            a = [(os.path.basename(f), cs) for f, cs in a.items()]
-        if isinstance(b, dict):
-            b = [(os.path.basename(f), cs) for f, cs in b.items()]
-        # Compare lists, ensuring we can handle duplicate filenames if they exist
-        removedcount = Counter(a)
-        removedcount.subtract(b)
-        addedcount = Counter(b)
-        addedcount.subtract(a)
-        added = []
-        for x in b:
-            if addedcount[x] > 0:
-                addedcount[x] -= 1
-                added.append(x)
-        removed = []
-        changed = []
-        for x in a:
-            if removedcount[x] > 0:
-                removedcount[x] -= 1
-                for y in added:
-                    if y[0] == x[0]:
-                        changed.append((x[0], x[1], y[1]))
-                        added.remove(y)
-                        break
-                else:
-                    removed.append(x)
-        added = [x[0] for x in added]
-        removed = [x[0] for x in removed]
-        return changed, added, removed
-
     if 'basewhitelist' in a_data and a_data['basewhitelist'] != b_data['basewhitelist']:
         output.append("basewhitelist changed from '%s' to '%s'" % (a_data['basewhitelist'], b_data['basewhitelist']))
         if a_data['basewhitelist'] and b_data['basewhitelist']:
@@ -390,10 +357,10 @@ def compare_sigfiles(a, b, recursecb = None):
         for dep in changed:
             output.append("Variable %s value changed from '%s' to '%s'" % (dep, a_data['varvals'][dep], b_data['varvals'][dep]))
 
-    changed, added, removed = file_checksums_diff(a_data['file_checksum_values'], b_data['file_checksum_values'])
+    changed, added, removed = dict_diff(a_data['file_checksum_values'], b_data['file_checksum_values'])
     if changed:
-        for f, old, new in changed:
-            output.append("Checksum for file %s changed from %s to %s" % (f, old, new))
+        for f in changed:
+            output.append("Checksum for file %s changed from %s to %s" % (f, a_data['file_checksum_values'][f], b_data['file_checksum_values'][f]))
     if added:
         for f in added:
             output.append("Dependency on checksum of file %s was added" % (f))

bitbake/lib/bb/ui/buildinfohelper.py

@@ -188,7 +188,7 @@ class ORMWrapper(object):
                                        revision = package_info['PKGR'],
                                        summary = package_info['SUMMARY'],
                                        description = package_info['DESCRIPTION'],
-                                       size = int(package_info['PKGSIZE']),
+                                       size = int(package_info['PKGSIZE']) * 1024,
                                        section = package_info['SECTION'],
                                        license = package_info['LICENSE'],
                                        )
@@ -543,7 +543,7 @@ class BuildInfoHelper(object):
             task_information['disk_io'] = task_build_stats['disk_io']
             del self.internal_state[identifier]
 
-        if isinstance(event, (bb.runqueue.runQueueTaskFailed, bb.runqueue.sceneQueueTaskFailed)):
+        if isinstance(event, (bb.runqueue.runQueueTaskFailed, bb.runCommand.sceneQueueTaskFailed)):
             task_information['outcome'] = Task.OUTCOME_FAILED
             del self.internal_state[identifier]
 

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

@@ -185,7 +185,6 @@ class BuildDetailsPage (HobPage):
     def show_issues(self):
         self.num_of_issues += 1
         self.notebook.show_indicator_icon("Issues", self.num_of_issues)
-        self.notebook.queue_draw()
 
     def reset_issues(self):
         self.num_of_issues = 0
@@ -424,7 +423,7 @@ class BuildDetailsPage (HobPage):
         if "recipes" in action:
             self.builder.show_recipes()
         elif "packages" in action:
-            self.builder.show_packages()
+            self.builder.show_packages(ask=False)
         elif "image" in action:
             self.builder.show_configuration()
 

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

@@ -704,6 +704,7 @@ class Builder(gtk.Window):
         self.set_user_config_proxies()
 
     def set_user_config(self):
+        self.handler.reset_cooker()
         # set bb layers
         self.handler.set_bblayers(self.configuration.layers)
         # set local configuration
@@ -793,8 +794,8 @@ class Builder(gtk.Window):
                 self.generate_image_async(True)
 
     def show_error_dialog(self, msg):
-        lbl = "<b>Hob found an error</b>"
-        dialog = CrumbsMessageDialog(self, lbl, gtk.MESSAGE_ERROR, msg)
+        lbl = "<b>Hob found an error</b>\n"
+        dialog = CrumbsMessageDialog(self, lbl, gtk.STOCK_DIALOG_ERROR, msg)
         button = dialog.add_button("Close", gtk.RESPONSE_OK)
         HobButton.style_button(button)
         response = dialog.run()
@@ -810,9 +811,10 @@ class Builder(gtk.Window):
         dialog.destroy()
 
     def show_network_error_dialog(self):
-        lbl = "<b>Hob cannot connect to the network</b>"
-        msg = msg + "Please check your network connection. If you are using a proxy server, please make sure it is configured correctly."
-        dialog = CrumbsMessageDialog(self, lbl, gtk.MESSAGE_ERROR, msg)
+        lbl = "<b>Hob cannot connect to the network</b>\n"
+        msg = "Please check your network connection. If you are using a proxy server, please make sure it is configured correctly."
+        lbl = lbl + "%s\n\n" % glib.markup_escape_text(msg)
+        dialog = CrumbsMessageDialog(self, lbl, gtk.STOCK_DIALOG_ERROR)
         button = dialog.add_button("Close", gtk.RESPONSE_OK)
         HobButton.style_button(button)
         button = dialog.add_button("Proxy settings", gtk.RESPONSE_CANCEL)
@@ -1035,7 +1037,7 @@ class Builder(gtk.Window):
         self.build_failed()
 
     def handler_no_provider_cb(self, running_build, msg):
-        dialog = CrumbsMessageDialog(self, glib.markup_escape_text(msg), gtk.MESSAGE_INFO)
+        dialog = CrumbsMessageDialog(self, glib.markup_escape_text(msg), gtk.STOCK_DIALOG_INFO)
         button = dialog.add_button("Close", gtk.RESPONSE_OK)
         HobButton.style_button(button)
         dialog.run()
@@ -1098,10 +1100,9 @@ class Builder(gtk.Window):
     def build_packages(self):
         _, all_recipes = self.recipe_model.get_selected_recipes()
         if not all_recipes:
-            lbl = "<b>No selections made</b>"
-            msg = "You have not made any selections"
-            msg = msg + " so there isn't anything to bake at this time."
-            dialog = CrumbsMessageDialog(self, lbl, gtk.MESSAGE_INFO, msg)
+            lbl = "<b>No selections made</b>\nYou have not made any selections"
+            lbl = lbl + " so there isn't anything to bake at this time."
+            dialog = CrumbsMessageDialog(self, lbl, gtk.STOCK_DIALOG_INFO)
             button = dialog.add_button("Close", gtk.RESPONSE_OK)
             HobButton.style_button(button)
             dialog.run()
@@ -1112,10 +1113,9 @@ class Builder(gtk.Window):
     def build_image(self):
         selected_packages = self.package_model.get_selected_packages()
         if not selected_packages:      
-            lbl = "<b>No selections made</b>"
-            msg = "You have not made any selections"
-            msg = msg + " so there isn't anything to bake at this time."
-            dialog = CrumbsMessageDialog(self, lbl, gtk.MESSAGE_INFO, msg)
+            lbl = "<b>No selections made</b>\nYou have not made any selections"
+            lbl = lbl + " so there isn't anything to bake at this time."
+            dialog = CrumbsMessageDialog(self, lbl, gtk.STOCK_DIALOG_INFO)
             button = dialog.add_button("Close", gtk.RESPONSE_OK)
             HobButton.style_button(button)
             dialog.run()
@@ -1129,10 +1129,9 @@ class Builder(gtk.Window):
 
         # If no base image and no selected packages don't build anything
         if not (selected_packages or selected_image != self.recipe_model.__custom_image__):
-            lbl = "<b>No selections made</b>"
-            msg = "You have not made any selections"
-            msg = msg + " so there isn't anything to bake at this time."
-            dialog = CrumbsMessageDialog(self, lbl, gtk.MESSAGE_INFO, msg)
+            lbl = "<b>No selections made</b>\nYou have not made any selections"
+            lbl = lbl + " so there isn't anything to bake at this time."
+            dialog = CrumbsMessageDialog(self, lbl, gtk.STOCK_DIALOG_INFO)
             button = dialog.add_button("Close", gtk.RESPONSE_OK)
             HobButton.style_button(button)
             dialog.run()
@@ -1216,9 +1215,8 @@ class Builder(gtk.Window):
         response = dialog.run()
         if response == gtk.RESPONSE_YES:
             if not dialog.image_names:
-                lbl = "<b>No selections made</b>"
-                msg = "You have not made any selections"
-                crumbs_dialog = CrumbsMessageDialog(self, lbl, gtk.MESSAGE_INFO, msg)
+                lbl = "<b>No selections made</b>\nYou have not made any selections"
+                crumbs_dialog = CrumbsMessageDialog(self, lbl, gtk.STOCK_DIALOG_INFO)
                 button = crumbs_dialog.add_button("Close", gtk.RESPONSE_OK)
                 HobButton.style_button(button)
                 crumbs_dialog.run()
@@ -1305,7 +1303,7 @@ class Builder(gtk.Window):
     def deploy_image(self, image_name):
         if not image_name:
             lbl = "<b>Please select an image to deploy.</b>"
-            dialog = CrumbsMessageDialog(self, lbl, gtk.MESSAGE_INFO)
+            dialog = CrumbsMessageDialog(self, lbl, gtk.STOCK_DIALOG_INFO)
             button = dialog.add_button("Close", gtk.RESPONSE_OK)
             HobButton.style_button(button)
             dialog.run()
@@ -1351,8 +1349,8 @@ class Builder(gtk.Window):
 
     def runqemu_image(self, image_name, kernel_name):
         if not image_name or not kernel_name:
-            lbl = "<b>Please select %s to launch in QEMU.</b>" % ("a kernel" if image_name else "an image")
-            dialog = CrumbsMessageDialog(self, lbl, gtk.MESSAGE_INFO)
+            lbl = "<b>Please select an %s to launch in QEMU.</b>" % ("kernel" if image_name else "image")
+            dialog = CrumbsMessageDialog(self, lbl, gtk.STOCK_DIALOG_INFO)
             button = dialog.add_button("Close", gtk.RESPONSE_OK)
             HobButton.style_button(button)
             dialog.run()
@@ -1373,23 +1371,38 @@ class Builder(gtk.Window):
             cmdline += "runqemu " + kernel_path + " " + image_path + "\"\'"
             subprocess.Popen(shlex.split(cmdline))
         else:
-            lbl = "<b>Path error</b>"
-            msg = "One of your paths is wrong,"
-            msg = msg + " please make sure the following paths exist:\n"
-            msg = msg + "image path:" + image_path + "\n"
-            msg = msg + "kernel path:" + kernel_path + "\n"
-            msg = msg + "source environment path:" + source_env_path + "\n"
-            msg = msg + "tmp path: " + tmp_path + "."
-            msg = msg + "You may be missing either xterm or vte for terminal services."
-            dialog = CrumbsMessageDialog(self, lbl, gtk.MESSAGE_ERROR, msg)
+            lbl = "<b>Path error</b>\nOne of your paths is wrong,"
+            lbl = lbl + " please make sure the following paths exist:\n"
+            lbl = lbl + "image path:" + image_path + "\n"
+            lbl = lbl + "kernel path:" + kernel_path + "\n"
+            lbl = lbl + "source environment path:" + source_env_path + "\n"
+            lbl = lbl + "tmp path: " + tmp_path + "."
+            lbl = lbl + "You may be missing either xterm or vte for terminal services."
+            dialog = CrumbsMessageDialog(self, lbl, gtk.STOCK_DIALOG_ERROR)
             button = dialog.add_button("Close", gtk.RESPONSE_OK)
             HobButton.style_button(button)
             dialog.run()
             dialog.destroy()
 
-    def show_packages(self):
-        self.package_details_page.refresh_tables()
-        self.switch_page(self.PACKAGE_SELECTION)
+    def show_packages(self, ask=True):
+        _, selected_recipes = self.recipe_model.get_selected_recipes()
+        if selected_recipes and ask:
+            lbl = "<b>Package list may be incomplete!</b>\nDo you want to build selected recipes"
+            lbl = lbl + " to get a full list or just view the existing packages?"
+            dialog = CrumbsMessageDialog(self, lbl, gtk.STOCK_DIALOG_INFO)
+            button = dialog.add_button("View packages", gtk.RESPONSE_NO)
+            HobAltButton.style_button(button)
+            button = dialog.add_button("Build packages", gtk.RESPONSE_YES)
+            HobButton.style_button(button)
+            dialog.set_default_response(gtk.RESPONSE_YES)
+            response = dialog.run()
+            dialog.destroy()
+            if response == gtk.RESPONSE_YES:
+                self.generate_packages_async(True)
+            else:
+                self.switch_page(self.PACKAGE_SELECTION)
+        else:
+            self.switch_page(self.PACKAGE_SELECTION)
 
     def show_recipes(self):
         self.switch_page(self.RECIPE_SELECTION)
@@ -1402,28 +1415,26 @@ class Builder(gtk.Window):
 
     def stop_build(self):
         if self.stopping:
-            lbl = "<b>Force Stop build?</b>"
-            msg = "You've already selected Stop once,"
-            msg = msg + " would you like to 'Force Stop' the build?\n\n"
-            msg = msg + "This will stop the build as quickly as possible but may"
-            msg = msg + " well leave your build directory in an  unusable state"
-            msg = msg + " that requires manual steps to fix."
-            dialog = CrumbsMessageDialog(self, lbl, gtk.MESSAGE_WARNING, msg)
+            lbl = "<b>Force Stop build?</b>\nYou've already selected Stop once,"
+            lbl = lbl + " would you like to 'Force Stop' the build?\n\n"
+            lbl = lbl + "This will stop the build as quickly as possible but may"
+            lbl = lbl + " well leave your build directory in an  unusable state"
+            lbl = lbl + " that requires manual steps to fix.\n"
+            dialog = CrumbsMessageDialog(self, lbl, gtk.STOCK_DIALOG_WARNING)
             button = dialog.add_button("Cancel", gtk.RESPONSE_CANCEL)
             HobAltButton.style_button(button)
             button = dialog.add_button("Force Stop", gtk.RESPONSE_YES)
             HobButton.style_button(button)
         else:
-            lbl = "<b>Stop build?</b>"
-            msg = "Are you sure you want to stop this"
-            msg = msg + " build?\n\n'Stop' will stop the build as soon as all in"
-            msg = msg + " progress build tasks are finished. However if a"
-            msg = msg + " lengthy compilation phase is in progress this may take"
-            msg = msg + " some time.\n\n"
-            msg = msg + "'Force Stop' will stop the build as quickly as"
-            msg = msg + " possible but may well leave your build directory in an"
-            msg = msg + " unusable state that requires manual steps to fix."
-            dialog = CrumbsMessageDialog(self, lbl, gtk.MESSAGE_WARNING, msg)
+            lbl = "<b>Stop build?</b>\n\nAre you sure you want to stop this"
+            lbl = lbl + " build?\n\n'Stop' will stop the build as soon as all in"
+            lbl = lbl + " progress build tasks are finished. However if a"
+            lbl = lbl + " lengthy compilation phase is in progress this may take"
+            lbl = lbl + " some time.\n\n"
+            lbl = lbl + "'Force Stop' will stop the build as quickly as"
+            lbl = lbl + " possible but may well leave your build directory in an"
+            lbl = lbl + " unusable state that requires manual steps to fix."
+            dialog = CrumbsMessageDialog(self, lbl, gtk.STOCK_DIALOG_WARNING)
             button = dialog.add_button("Cancel", gtk.RESPONSE_CANCEL)
             HobAltButton.style_button(button)
             button = dialog.add_button("Force stop", gtk.RESPONSE_YES)

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

@@ -183,9 +183,8 @@ class AdvancedSettingsDialog (CrumbsDialog, SettingsUIHelper):
         self.set_save_button_state()
         if self.get_num_checked_image_types() == 0:
             # Show an error dialog
-            lbl = "<b>Select an image type</b>"
-            msg = "You need to select at least one image type."
-            dialog = CrumbsMessageDialog(self, lbl, gtk.MESSAGE_WARNING, msg)
+            lbl = "<b>Select an image type</b>\n\nYou need to select at least one image type."
+            dialog = CrumbsMessageDialog(self, lbl, gtk.STOCK_DIALOG_WARNING)
             button = dialog.add_button("OK", gtk.RESPONSE_OK)
             HobButton.style_button(button)
             response = dialog.run()

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

@@ -31,28 +31,51 @@ BitBake GUI's
 In summary: spacing = 12px, border-width = 6px
 """
 
-class CrumbsMessageDialog(gtk.MessageDialog):
+class CrumbsMessageDialog(CrumbsDialog):
     """
     A GNOME HIG compliant dialog widget.
     Add buttons with gtk.Dialog.add_button or gtk.Dialog.add_buttons
     """
-    def __init__(self, parent = None, label="", dialog_type = gtk.MESSAGE_QUESTION, msg=""):
-        super(CrumbsMessageDialog, self).__init__(None,
-                                                  gtk.DIALOG_MODAL | gtk.DIALOG_DESTROY_WITH_PARENT,
-                                                  dialog_type,
-                                                  gtk.BUTTONS_NONE,
-                                                  None)
+    def __init__(self, parent=None, label="", icon=gtk.STOCK_INFO, msg=""):
+        super(CrumbsMessageDialog, self).__init__("", parent, gtk.DIALOG_MODAL)
 
-        self.set_skip_taskbar_hint(False)
+        self.set_border_width(6)
+        self.vbox.set_property("spacing", 12)
+        self.action_area.set_property("spacing", 12)
+        self.action_area.set_property("border-width", 6)
 
-        self.set_markup(label)
+        first_column = gtk.HBox(spacing=12)
+        first_column.set_property("border-width", 6)
+        first_column.show()
+        self.vbox.add(first_column)
 
-        if 0 <= len(msg) < 300:
-            self.format_secondary_markup(msg)
+        self.icon = gtk.Image()
+        # We have our own Info icon which should be used in preference of the stock icon
+        self.icon_chk = HobIconChecker()
+        self.icon.set_from_stock(self.icon_chk.check_stock_icon(icon), gtk.ICON_SIZE_DIALOG)
+        self.icon.set_property("yalign", 0.00)
+        self.icon.show()
+        first_column.pack_start(self.icon, expand=False, fill=True, padding=0)
+        
+        if 0 <= len(msg) < 200:
+            lbl = label + "%s" % glib.markup_escape_text(msg)
+            self.label_short = gtk.Label()
+            self.label_short.set_use_markup(True)
+            self.label_short.set_line_wrap(True)
+            self.label_short.set_markup(lbl)
+            self.label_short.set_property("yalign", 0.00)
+            self.label_short.show()
+            first_column.add(self.label_short)
         else:
-            vbox = self.get_message_area()
-            vbox.set_border_width(1)
-            vbox.set_property("spacing", 12)
+            second_row = gtk.VBox(spacing=12)
+            second_row.set_property("border-width", 6)
+            self.label_long = gtk.Label()
+            self.label_long.set_use_markup(True)
+            self.label_long.set_line_wrap(True)
+            self.label_long.set_markup(label)
+            self.label_long.set_alignment(0.0, 0.0)
+            second_row.pack_start(self.label_long, expand=False, fill=False, padding=0)
+            self.label_long.show()
             self.textWindow = gtk.ScrolledWindow()
             self.textWindow.set_shadow_type(gtk.SHADOW_IN)
             self.textWindow.set_policy(gtk.POLICY_AUTOMATIC, gtk.POLICY_AUTOMATIC)
@@ -66,5 +89,7 @@ class CrumbsMessageDialog(gtk.MessageDialog):
             self.msgView.set_buffer(self.buf)
             self.textWindow.add(self.msgView)
             self.msgView.show()
-            vbox.add(self.textWindow)
+            second_row.add(self.textWindow)
             self.textWindow.show()
+            first_column.add(second_row)
+            second_row.show()

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

@@ -160,7 +160,6 @@ class DeployImageDialog (CrumbsDialog):
     def response_cb(self, dialog, response_id):
         if response_id == gtk.RESPONSE_YES:
             lbl = ''
-            msg = ''
             combo_item = self.usb_combo.get_active_text()
             if combo_item and combo_item != self.__dummy_usb__ and self.image_path:
                 cmdline = bb.ui.crumbs.utils.which_terminal()
@@ -173,18 +172,15 @@ class DeployImageDialog (CrumbsDialog):
                     if int(tmpfile.readline().strip()) == 0:
                         lbl = "<b>Deploy image successfully.</b>"
                     else:
-                        lbl = "<b>Failed to deploy image.</b>"
-                        msg = "Please check image <b>%s</b> exists and USB device <b>%s</b> is writable." % (self.image_path, combo_item)
+                        lbl = "<b>Failed to deploy image.</b>\nPlease check image <b>%s</b> exists and USB device <b>%s</b> is writable." % (self.image_path, combo_item)
                     tmpfile.close()
             else:
                 if not self.image_path:
-                    lbl = "<b>No selection made.</b>"
-                    msg = "You have not selected an image to deploy."
+                    lbl = "<b>No selection made.</b>\nYou have not selected an image to deploy."
                 else:
-                    lbl = "<b>No selection made.</b>"
-                    msg = "You have not selected a USB device."
+                    lbl = "<b>No selection made.</b>\nYou have not selected a USB device."
             if len(lbl):
-                crumbs_dialog = CrumbsMessageDialog(self, lbl, gtk.MESSAGE_INFO, msg)
+                crumbs_dialog = CrumbsMessageDialog(self, lbl, gtk.STOCK_DIALOG_INFO)
                 button = crumbs_dialog.add_button("Close", gtk.RESPONSE_OK)
                 HobButton.style_button(button)
                 crumbs_dialog.run()

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

@@ -92,8 +92,7 @@ class LayerSelectionDialog (CrumbsDialog):
         path = dialog.get_filename()
         dialog.destroy()
 
-        lbl = "<b>Error</b>"
-        msg = "Unable to load layer <i>%s</i> because " % path
+        lbl = "<b>Error</b>\nUnable to load layer <i>%s</i> because " % path
         if response == gtk.RESPONSE_YES:
             import os
             import os.path
@@ -104,15 +103,15 @@ class LayerSelectionDialog (CrumbsDialog):
                 it = layer_store.iter_next(it)
 
             if not path:
-                msg += "it is an invalid path."
+                lbl += "it is an invalid path."
             elif not os.path.exists(path+"/conf/layer.conf"):
-                msg += "there is no layer.conf inside the directory."
+                lbl += "there is no layer.conf inside the directory."
             elif path in layers:
-                msg += "it is already in loaded layers."
+                lbl += "it is already in loaded layers."
             else:
                 layer_store.append([path])
                 return
-            dialog = CrumbsMessageDialog(parent, lbl, gtk.MESSAGE_ERROR, msg)
+            dialog = CrumbsMessageDialog(parent, lbl)
             dialog.add_button(gtk.STOCK_CLOSE, gtk.RESPONSE_OK)
             response = dialog.run()
             dialog.destroy()
@@ -133,13 +132,12 @@ class LayerSelectionDialog (CrumbsDialog):
         tree_selection.set_mode(gtk.SELECTION_SINGLE)
 
         # Allow enable drag and drop of rows including row move
-        dnd_internal_target = ''
-        dnd_targets = [(dnd_internal_target, gtk.TARGET_SAME_WIDGET, 0)]
         layer_tv.enable_model_drag_source( gtk.gdk.BUTTON1_MASK,
-            dnd_targets,
-            gtk.gdk.ACTION_MOVE)
-        layer_tv.enable_model_drag_dest(dnd_targets,
+            self.TARGETS,
+            gtk.gdk.ACTION_DEFAULT|
             gtk.gdk.ACTION_MOVE)
+        layer_tv.enable_model_drag_dest(self.TARGETS,
+            gtk.gdk.ACTION_DEFAULT)
         layer_tv.connect("drag_data_get", self.drag_data_get_cb)
         layer_tv.connect("drag_data_received", self.drag_data_received_cb)
 

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

@@ -105,14 +105,13 @@ class PropertyDialog(CrumbsDialog):
                 
         def create_package_visual_elements(self):
 
-                import json
-
                 name = self.properties['name']
                 binb = self.properties['binb']
                 size = self.properties['size']
                 recipe = self.properties['recipe']
-                file_list = json.loads(self.properties['files_list'])
+                file_list = self.properties['files_list']
 
+                file_list = file_list.strip("{}'")
                 files_temp = ''
                 paths_temp = ''
                 files_binb = []
@@ -181,43 +180,58 @@ class PropertyDialog(CrumbsDialog):
 
                 #################################### FILES BROUGHT BY PACKAGES ###################################
 
-                if file_list:
+                if file_list != '':
                 
                         self.textWindow = gtk.ScrolledWindow()
                         self.textWindow.set_shadow_type(gtk.SHADOW_IN)
                         self.textWindow.set_policy(gtk.POLICY_AUTOMATIC, gtk.POLICY_AUTOMATIC)
                         self.textWindow.set_size_request(100, 170)
 
-                        packagefiles_store = gtk.ListStore(str)
+                        sstatemirrors_store = gtk.ListStore(str)
 
-                        self.packagefiles_tv = gtk.TreeView()
-                        self.packagefiles_tv.set_rules_hint(True)
-                        self.packagefiles_tv.set_headers_visible(True)
-                        self.textWindow.add(self.packagefiles_tv)
+                        self.sstatemirrors_tv = gtk.TreeView()
+                        self.sstatemirrors_tv.set_rules_hint(True)
+                        self.sstatemirrors_tv.set_headers_visible(True)
+                        self.textWindow.add(self.sstatemirrors_tv)
 
                         self.cell1 = gtk.CellRendererText()
                         col1 = gtk.TreeViewColumn('Package files', self.cell1)
                         col1.set_cell_data_func(self.cell1, self.regex_field)
-                        self.packagefiles_tv.append_column(col1)
+                        self.sstatemirrors_tv.append_column(col1)
 
-                        items = file_list.keys()
-                        items.sort()
-                        for item in items:
-                                fullpath = item
-                                while len(item) > 35:
-                                        item = item[:len(item)/2] + "" + item[len(item)/2+1:]
-                                if len(item) == 35:
-                                        item = item[:len(item)/2] + "..." + item[len(item)/2+3:]
-                                        self.tooltip_items[item] = fullpath
+                        for items in file_list.split(']'):
+                            if len(items) > 1:
+                                paths_temp = items.split(":")[0]
+                                paths_binb.append(paths_temp.strip(" ,'"))
+                                files_temp = items.split(":")[1]
+                                files_binb.append(files_temp.strip(" ['"))
 
-                                packagefiles_store.append([str(item)])
+                        unsorted_list = []
+                        
+                        for items in range(len(paths_binb)):
+                              if len(files_binb[items]) > 1:
+                                  for aduse in (files_binb[items].split(",")):
+                                        unsorted_list.append(paths_binb[items].split(name)[len(paths_binb[items].split(name))-1] + '/' + aduse.strip(" '"))
+                       
+                         
+                        unsorted_list.sort()
+                        for items in unsorted_list:
+                                temp = items
+                                while len(items) > 35:
+                                        items = items[:len(items)/2] + "" + items[len(items)/2+1:]
+                                if len(items) == 35:
+                                        items = items[:len(items)/2] + "..." + items[len(items)/2+3:]
+                                        self.tooltip_items[items] = temp
 
-                        self.packagefiles_tv.set_model(packagefiles_store)
+                                sstatemirrors_store.append([str(items)])
+                                
+                                
+                        self.sstatemirrors_tv.set_model(sstatemirrors_store)
 
                         tips = gtk.Tooltips()
-                        tips.set_tip(self.packagefiles_tv, "")
-                        self.packagefiles_tv.connect("motion-notify-event", self.treeViewTooltip, tips, 0)
-                        self.packagefiles_tv.set_events(gtk.gdk.POINTER_MOTION_MASK)
+                        tips.set_tip(self.sstatemirrors_tv, "")
+                        self.sstatemirrors_tv.connect("motion-notify-event", self.treeViewTooltip, tips, 0)
+                        self.sstatemirrors_tv.set_events(gtk.gdk.POINTER_MOTION_MASK)
                         
                         self.vbox.add(self.textWindow)                                      
 

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

@@ -146,11 +146,12 @@ class SaveImageDialog (CrumbsDialog):
             self.show_invalid_input_error_dialog()
 
     def show_invalid_input_error_dialog(self):
-        lbl = "<b>Invalid characters in image recipe name</b>"
+        lbl = "<b>Invalid characters in image recipe name</b>\n"
         msg = "Image recipe names should be all lowercase and\n"
         msg += "include only alphanumeric characters. The only\n"
         msg += "special character you can use is the ASCII hyphen (-)."
-        dialog = CrumbsMessageDialog(self, lbl, gtk.MESSAGE_ERROR, msg)
+        lbl = lbl + "\n%s\n" % glib.markup_escape_text(msg)
+        dialog = CrumbsMessageDialog(self, lbl, gtk.STOCK_DIALOG_ERROR)
         button = dialog.add_button("Close", gtk.RESPONSE_OK)
         HobButton.style_button(button)
 

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

@@ -211,19 +211,18 @@ class SimpleSettingsDialog (CrumbsDialog, SettingsUIHelper):
 
     def response_cb(self, dialog, response_id):
         if response_id == gtk.RESPONSE_YES:
-            if self.proxy_checkbox.get_active():
-                # Check that all proxy entries have a corresponding port
-                for proxy, port in zip(self.all_proxy_addresses, self.all_proxy_ports):
-                    if proxy.get_text() and not port.get_text():
-                        lbl = "<b>Enter all port numbers</b>"
-                        msg = "Proxy servers require a port number. Please make sure you have entered a port number for each proxy server."
-                        dialog = CrumbsMessageDialog(self, lbl, gtk.MESSAGE_WARNING, msg)
-                        button = dialog.add_button("Close", gtk.RESPONSE_OK)
-                        HobButton.style_button(button)
-                        response = dialog.run()
-                        dialog.destroy()
-                        self.emit_stop_by_name("response")
-                        return
+            # Check that all proxy entries have a corresponding port
+            for proxy, port in zip(self.all_proxy_addresses, self.all_proxy_ports):
+                if proxy.get_text() and not port.get_text():
+                    lbl = "<b>Enter all port numbers</b>\n\n"
+                    msg = "Proxy servers require a port number. Please make sure you have entered a port number for each proxy server."
+                    dialog = CrumbsMessageDialog(self, lbl, gtk.STOCK_DIALOG_WARNING, msg)
+                    button = dialog.add_button("Close", gtk.RESPONSE_OK)
+                    HobButton.style_button(button)
+                    response = dialog.run()
+                    dialog.destroy()
+                    self.emit_stop_by_name("response")
+                    return
 
         self.configuration.dldir = self.dldir_text.get_text()
         self.configuration.sstatedir = self.sstatedir_text.get_text()

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

@@ -98,7 +98,6 @@ class HobHandler(gobject.GObject):
 
         self.server = server
         self.error_msg = ""
-        self.lastCommand = ""
         self.initcmd = None
         self.parsing = False
 
@@ -113,7 +112,6 @@ class HobHandler(gobject.GObject):
             self.generating = False
 
     def runCommand(self, commandline):
-        self.lastCommand = commandline[0]
         try:
             result, error = self.server.runCommand(commandline)
             if error:
@@ -149,7 +147,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(["resetCooker"])
+            self.runCommand(["enableDataTracking"])
+            self.runCommand(["parseConfigurationFiles", "conf/.hob.conf", ""])
+            self.runCommand(["disableDataTracking"])
         elif next_command == self.SUB_GNERATE_TGTS:
             self.runCommand(["generateTargetsTree", "classes/image.bbclass", []])
         elif next_command == self.SUB_GENERATE_PKGINFO:
@@ -204,8 +204,7 @@ class HobHandler(gobject.GObject):
             reparse = self.runCommand(["getVariable", "BB_INVALIDCONF"]) or None
             if reparse is True:
                 self.set_var_in_file("BB_INVALIDCONF", False, "local.conf")
-                self.runCommand(["setPrePostConfFiles", "conf/.hob.conf", ""])
-                self.commands_async.prepend(self.SUB_PARSE_CONFIG)
+                self.runCommand(["parseConfigurationFiles", "conf/.hob.conf", ""])
             self.run_next_command()
 
         elif isinstance(event, bb.event.SanityCheckFailed):
@@ -252,10 +251,6 @@ class HobHandler(gobject.GObject):
             self.current_phase = None
             self.run_next_command()
         elif isinstance(event, bb.command.CommandFailed):
-            if self.error_msg == "":
-                self.error_msg = "The command \"" + self.lastCommand
-                self.error_msg += "\" was sent to bitbake server but it failed. Please"
-                self.error_msg += " check the code executed by this command in bitbake."
             self.commands_async = []
             self.display_error()
         elif isinstance(event, (bb.event.ParseStarted,
@@ -303,8 +298,14 @@ class HobHandler(gobject.GObject):
         return
 
     def init_cooker(self):
+        self.runCommand(["initCooker"])
         self.runCommand(["createConfigFile", ".hob.conf"])
 
+    def reset_cooker(self):
+        self.runCommand(["enableDataTracking"])
+        self.runCommand(["resetCooker"])
+        self.runCommand(["disableDataTracking"])
+
     def set_extra_inherit(self, bbclass):
         inherits = self.runCommand(["getVariable", "INHERIT"]) or ""
         inherits = inherits + " " + bbclass
@@ -404,17 +405,15 @@ class HobHandler(gobject.GObject):
         self.run_next_command(self.NETWORK_TEST)
 
     def generate_configuration(self):
-        self.runCommand(["setPrePostConfFiles", "conf/.hob.conf", ""])
+        self.commands_async.append(self.SUB_PARSE_CONFIG)
         self.commands_async.append(self.SUB_PATH_LAYERS)
         self.commands_async.append(self.SUB_FILES_DISTRO)
         self.commands_async.append(self.SUB_FILES_MACH)
         self.commands_async.append(self.SUB_FILES_SDKMACH)
         self.commands_async.append(self.SUB_MATCH_CLASS)
-        self.commands_async.append(self.SUB_PARSE_CONFIG)
         self.run_next_command(self.GENERATE_CONFIGURATION)
 
     def generate_recipes(self):
-        self.runCommand(["setPrePostConfFiles", "conf/.hob.conf", ""])
         self.commands_async.append(self.SUB_PARSE_CONFIG)
         self.commands_async.append(self.SUB_GNERATE_TGTS)
         self.run_next_command(self.GENERATE_RECIPES)
@@ -424,7 +423,6 @@ class HobHandler(gobject.GObject):
         targets.extend(tgts)
         self.recipe_queue = targets
         self.default_task = default_task
-        self.runCommand(["setPrePostConfFiles", "conf/.hob.conf", ""])
         self.commands_async.append(self.SUB_PARSE_CONFIG)
         self.commands_async.append(self.SUB_BUILD_RECIPES)
         self.run_next_command(self.GENERATE_PACKAGES)
@@ -436,7 +434,6 @@ class HobHandler(gobject.GObject):
         self.package_queue = image_packages
         self.toolchain_packages = toolchain_packages
         self.default_task = default_task
-        self.runCommand(["setPrePostConfFiles", "conf/.hob.conf", ""])
         self.commands_async.append(self.SUB_PARSE_CONFIG)
         self.commands_async.append(self.SUB_BUILD_IMAGE)
         self.run_next_command(self.GENERATE_IMAGE)

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

@@ -199,9 +199,7 @@ class PackageListModel(gtk.ListStore):
         return self.cmp_vals(val1, val2, user_data)
 
     def cmp_vals(self, val1, val2, user_data):
-        if val1 is None or val2 is None:
-            return 0
-        elif val1.startswith(user_data) and not val2.startswith(user_data):
+        if val1.startswith(user_data) and not val2.startswith(user_data):
             return -1
         elif not val1.startswith(user_data) and val2.startswith(user_data):
             return 1
@@ -251,7 +249,7 @@ class PackageListModel(gtk.ListStore):
             pkgv = getpkgvalue(pkginfo, 'PKGV', pkg)
             pkgr = getpkgvalue(pkginfo, 'PKGR', pkg)
             # PKGSIZE is artificial, will always be overridden with the package name if present
-            pkgsize = int(pkginfo.get('PKGSIZE_%s' % pkg, "0"))
+            pkgsize = pkginfo.get('PKGSIZE_%s' % pkg, "0")
             # PKG_%s is the renamed version
             pkg_rename = pkginfo.get('PKG_%s' % pkg, "")
             # The rest may be overridden or not
@@ -268,10 +266,11 @@ class PackageListModel(gtk.ListStore):
 
             allow_empty = getpkgvalue(pkginfo, 'ALLOW_EMPTY', pkg, "")
 
-            if pkgsize == 0 and not allow_empty:
+            if pkgsize == "0" and not allow_empty:
                 continue
 
-            size = HobPage._size_to_string(pkgsize)
+            # pkgsize is in KB
+            size = HobPage._size_to_string(HobPage._string_to_size(pkgsize + ' KB'))
             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,
@@ -576,9 +575,7 @@ class RecipeListModel(gtk.ListStore):
         return self.cmp_vals(val1, val2, user_data)
 
     def cmp_vals(self, val1, val2, user_data):
-        if val1 is None or val2 is None:
-            return 0
-        elif val1.startswith(user_data) and not val2.startswith(user_data):
+        if val1.startswith(user_data) and not val2.startswith(user_data):
             return -1
         elif not val1.startswith(user_data) and val2.startswith(user_data):
             return 1

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

@@ -734,7 +734,7 @@ class HobCellRendererController(gobject.GObject):
         self.current_angle_pos += self.step_angle
         if self.running_mode == self.MODE_CYCLE_RUNNING:
             if (self.current_angle_pos >= 1):
-                self.current_angle_pos = 0
+                self.current_angle_pos = self.step_angle
         else:
             if self.current_angle_pos > 1:
                 self.force_stop()

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

@@ -355,9 +355,9 @@ class ImageDetailsPage (HobPage):
             vallist.append(base_image)
             i = 0
             for layer in layers:
+                varlist.append(" - ")
                 if i > layer_num_limit:
                     break
-                varlist.append(" - ")
                 i += 1
             vallist.append("")
             i = 0
@@ -655,7 +655,7 @@ class ImageDetailsPage (HobPage):
         self.builder.show_configuration()
 
     def edit_packages_button_clicked_cb(self, button):
-        self.builder.show_packages()
+        self.builder.show_packages(ask=False)
 
     def my_images_button_clicked_cb(self, button):
         self.builder.show_load_my_images_dialog()

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

@@ -174,15 +174,6 @@ class RunningBuild (gobject.GObject):
                       color,
                       0))
 
-            # if there are warnings while processing a package
-            #  (parent), mark the task with warning color;
-            # in case there are errors, the updates will be
-            #  handled on TaskFailed.
-            if color == HobColors.WARNING and parent:
-                self.model.set(parent, self.model.COL_COLOR, color)
-                if task: #then we have a parent (package), and update it's color
-                    self.model.set(self.tasks_to_iter[(package, None)], self.model.COL_COLOR, color)
-
         elif isinstance(event, bb.build.TaskStarted):
             (package, task) = (event._package, event._task)
 
@@ -210,10 +201,9 @@ class RunningBuild (gobject.GObject):
 
             # Because this parent package now has an active child mark it as
             # such.
-            self.model.set(parent, self.model.COL_ICON, "gtk-execute")
-            parent_color = self.model.get(parent, self.model.COL_COLOR)[0]
-            if parent_color != HobColors.ERROR and parent_color != HobColors.WARNING:
-                self.model.set(parent, self.model.COL_COLOR, HobColors.RUNNING)
+            # @todo if parent is already in error, don't mark it green
+            self.model.set(parent, self.model.COL_ICON, "gtk-execute",
+                           self.model.COL_COLOR, HobColors.RUNNING)
 
             # Add an entry in the model for this task
             i = self.model.append (parent, (None,
@@ -256,28 +246,20 @@ class RunningBuild (gobject.GObject):
                     self.model.set(i, self.model.COL_ICON, icon,
                                    self.model.COL_COLOR, color)
             else:
-                # Mark the parent package and the task as inactive,
-                # but make sure to preserve error, warnings and active
-                # states
-                parent_color = self.model.get(parent, self.model.COL_COLOR)[0]
-                task_color = self.model.get(current, self.model.COL_COLOR)[0]
+                icon = None
+                color = HobColors.OK
 
                 # Mark the task as inactive
-                self.model.set(current, self.model.COL_ICON, None)
-                if task_color != HobColors.ERROR:
-                    if task_color == HobColors.WARNING:
-                        self.model.set(current, self.model.COL_ICON, 'dialog-warning')
-                    else:
-                        self.model.set(current, self.model.COL_COLOR, HobColors.OK)
+                self.model.set(current, self.model.COL_ICON, icon,
+                               self.model.COL_COLOR, color)
 
-                # Mark the parent as inactive
-                if parent_color != HobColors.ERROR:
-                    if parent_color == HobColors.WARNING:
-                        self.model.set(parent, self.model.COL_ICON, "dialog-warning")
-                    else:
-                        self.model.set(parent, self.model.COL_ICON, None)
-                        if num_active == 0:
-                            self.model.set(parent, self.model.COL_COLOR, HobColors.OK)
+                # Mark the parent package as inactive, but make sure to
+                # preserve error and active states
+                i = self.tasks_to_iter[(package, None)]
+                if self.model.get(parent, self.model.COL_ICON) != 'dialog-error':
+                    self.model.set(parent, self.model.COL_ICON, icon)
+                    if num_active == 0:
+                        self.model.set(parent, self.model.COL_COLOR, HobColors.OK)
 
             # Clear the iters and the pids since when the task goes away the
             # pid will no longer be used for messages

bitbake/lib/bb/ui/depexp.py

@@ -202,7 +202,7 @@ def main(server, eventHandler, params):
             return 1
         cmdline = cmdline['action']
         if not cmdline or cmdline[0] != "generateDotGraph":
-            print("This UI requires the -g option")
+            print("This UI is only compatible with the -g option")
             return 1
         ret, error = server.runCommand(["generateDepTreeEvent", cmdline[1], cmdline[2]])
         if error:

bitbake/lib/bb/ui/hob.py

@@ -46,7 +46,7 @@ from bb.ui.crumbs.hoblistmodel import RecipeListModel, PackageListModel
 from bb.ui.crumbs.hobeventhandler import HobHandler
 from bb.ui.crumbs.builder import Builder
 
-featureSet = [bb.cooker.CookerFeatures.HOB_EXTRA_CACHES, bb.cooker.CookerFeatures.BASEDATASTORE_TRACKING]
+featureSet = [bb.cooker.CookerFeatures.HOB_EXTRA_CACHES]
 
 def event_handle_idle_func(eventHandler, hobHandler):
     # Consume as many messages as we can in the time available to us

bitbake/lib/bb/ui/toasterui.py

@@ -217,13 +217,6 @@ def main(server, eventHandler, params ):
             if isinstance(event, (bb.command.CommandCompleted,
                                   bb.command.CommandFailed,
                                   bb.command.CommandExit)):
-                if (isinstance(event, bb.command.CommandFailed)):
-                    event.levelno = format.ERROR
-                    event.msg = event.error
-                    event.pathname = ""
-                    event.lineno = 0
-                    buildinfohelper.store_log_event(event)
-                    errors += 1
 
                 buildinfohelper.update_build_information(event, errors, warnings, taskfailures)
 

bitbake/lib/bb/utils.py

@@ -354,9 +354,6 @@ def better_exec(code, context, text = None, realfile = "<code>"):
         code = better_compile(code, realfile, realfile)
     try:
         exec(code, get_context(), context)
-    except bb.BBHandledException:
-        # Error already shown so passthrough
-        raise
     except Exception as e:
         (t, value, tb) = sys.exc_info()
 
@@ -796,28 +793,22 @@ def copyfile(src, dest, newmtime = None, sstat = None):
         newmtime = sstat[stat.ST_MTIME]
     return newmtime
 
-def which(path, item, direction = 0, history = False):
+def which(path, item, direction = 0):
     """
     Locate a file in a PATH
     """
 
-    hist = []
     paths = (path or "").split(':')
     if direction != 0:
         paths.reverse()
 
     for p in paths:
         next = os.path.join(p, item)
-        hist.append(next)
         if os.path.exists(next):
             if not os.path.isabs(next):
                 next = os.path.abspath(next)
-            if history:
-                return next, hist
             return next
 
-    if history:
-        return "", hist
     return ""
 
 def to_boolean(string, default=None):

bitbake/lib/prserv/serv.py

@@ -13,7 +13,6 @@ except ImportError:
 import bb.server.xmlrpc
 import prserv
 import prserv.db
-import errno
 
 logger = logging.getLogger("BitBake.PRserv")
 
@@ -281,18 +280,8 @@ def stop_daemon(host, port):
         if pid:
             if os.path.exists(pidfile):
                 os.remove(pidfile)
-
-            wait_timeout = 0
-            while is_running(pid) and wait_timeout < 10:
-                print("Waiting for pr-server to exit.")
-                time.sleep(0.5)
-                wait_timeout += 1
-
-            if is_running(pid):
-                print("Sending SIGTERM to pr-server.")
-                os.kill(pid,signal.SIGTERM)
-                time.sleep(0.1)
-
+            os.kill(pid,signal.SIGTERM)
+            time.sleep(0.1)
     except OSError as e:
         err = str(e)
         if err.find("No such process") <= 0:
@@ -300,14 +289,6 @@ def stop_daemon(host, port):
 
     return 0
 
-def is_running(pid):
-    try:
-        os.kill(pid, 0)
-    except OSError as err:
-        if err.errno == errno.ESRCH:
-            return False
-    return True
-
 def is_local_special(host, port):
     if host.strip().upper() == 'localhost'.upper() and (not port):
         return True

documentation/adt-manual/adt-command.xml

@@ -8,32 +8,23 @@
     <para>
         Recall that earlier the manual discussed how to use an existing toolchain
         tarball that had been installed into the default installation
-        directory, <filename>/opt/poky/&DISTRO;</filename>, which is outside of the
+        directory, <filename>/opt/poky</filename>, which is outside of the
         <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
         (see the section "<link linkend='using-an-existing-toolchain-tarball'>Using a Cross-Toolchain Tarball)</link>".
         And, that sourcing your architecture-specific environment setup script
         initializes a suitable cross-toolchain development environment.
-    </para>
-
-    <para>
-        During this setup, locations for the compiler, QEMU scripts, QEMU binary,
+        During the setup, locations for the compiler, QEMU scripts, QEMU binary,
         a special version of <filename>pkgconfig</filename> and other useful
         utilities are added to the <filename>PATH</filename> variable.
-        Also, variables to assist
-        <filename>pkgconfig</filename> and <filename>autotools</filename>
-        are also defined so that, for example, <filename>configure.sh</filename>
-        can find pre-generated test results for tests that need target hardware
-        on which to run.
+        Variables to assist <filename>pkgconfig</filename> and <filename>autotools</filename>
+        are also defined so that,
+        for example, <filename>configure.sh</filename> can find pre-generated
+        test results for tests that need target hardware on which to run.
+        These conditions allow you to easily use the toolchain outside of the
+        OpenEmbedded build environment on both autotools-based projects and
+        Makefile-based projects.
     </para>
 
-    <para>
-        Collectively, these conditions allow you to easily use the toolchain
-        outside of the OpenEmbedded build environment on both autotools-based
-        projects and Makefile-based projects.
-        This chapter provides information for both these types of projects.
-    </para>
-
-
 <section id='autotools-based-projects'>
 <title>Autotools-Based Projects</title>
 
@@ -188,7 +179,7 @@
                 If <filename>configure</filename> script results in problems recognizing the
                 <filename>--with-libtool-sysroot=&lt;sysroot-dir&gt;</filename> option,
                 regenerate the script to enable the support by doing the following and then
-                run the script again:
+                re-running the script:
                 <literallayout class='monospaced'>
      $ libtoolize --automake
      $ aclocal -I ${OECORE_NATIVE_SYSROOT}/usr/share/aclocal \

documentation/adt-manual/adt-intro.xml

@@ -22,8 +22,8 @@
     and an introduction to the <trademark class='trade'>Eclipse</trademark> IDE
     Yocto Plug-in.
     <note>
-        The ADT is distribution-neutral and does not require the Yocto
-        Project reference distribution, which is called Poky.
+        The ADT is distribution-neutral and does not require the Yocto 
+        Project reference distribution, which is called Poky.  
         This manual, however, uses examples that use the Poky distribution.
     </note>
 </para>
@@ -43,7 +43,7 @@
         <itemizedlist>
             <listitem><para>An architecture-specific cross-toolchain and matching
                 sysroot both built by the OpenEmbedded build system.
-                The toolchain and sysroot are based on a
+                The toolchain and sysroot are based on a 
                 <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
                 configuration and extensions,
                 which allows you to cross-develop on the host machine for the target hardware.
@@ -149,7 +149,8 @@
                     that causes skips in audio,
                     stutters in your desktop experience, or situations that overload your server
                     even when you have plenty of CPU power left.
-                    </para></listitem>
+                    You can find out more about LatencyTOP at
+                    <ulink url='https://latencytop.org/'></ulink>.</para></listitem>
                 <listitem><para><emphasis>PowerTOP:</emphasis> Helps you determine what
                     software is using the most power.
                     You can find out more about PowerTOP at

documentation/adt-manual/adt-manual.xml

@@ -66,16 +66,6 @@
                 <date>October 2013</date>
                 <revremark>Released with the Yocto Project 1.5 Release.</revremark>
             </revision>
-            <revision>
-                <revnumber>1.5.1</revnumber>
-                <date>Sometime in 2013</date>
-                <revremark>Released with the Yocto Project 1.5.1 Release.</revremark>
-            </revision>
-            <revision>
-                <revnumber>1.6</revnumber>
-                <date>Sometime 2014</date>
-                <revremark>Released with the Yocto Project 1.6 Release.</revremark>
-            </revision>
        </revhistory>
 
     <copyright>
@@ -89,10 +79,11 @@
         the terms of the <ulink type="http" url="http://creativecommons.org/licenses/by-sa/2.0/uk/">Creative Commons Attribution-Share Alike 2.0 UK: England &amp; Wales</ulink> as published by Creative Commons.
       </para>
       <note>
-          For the latest version of this manual associated with this
-          Yocto Project release, see the
-          <ulink url='&YOCTO_DOCS_ADT_URL;'>Yocto Project Application Developer's Guide</ulink>
-          from the Yocto Project website.
+          Due to production processes, there could be differences between the Yocto Project
+          documentation bundled in the release tarball and the
+          <ulink url='&YOCTO_DOCS_ADT_URL;'>Yocto Project Application Developer's Guide</ulink> on
+          the <ulink url='&YOCTO_HOME_URL;'>Yocto Project</ulink> website.
+          For the latest version of this manual, see the manual on the website.
       </note>
 
     </legalnotice>

documentation/adt-manual/adt-prepare.xml

@@ -80,48 +80,39 @@
 
             <para>
                 The ADT Installer is contained in the ADT Installer tarball.
-                You can get the tarball using either of these methods:
-                <itemizedlist>
-                    <listitem><para><emphasis>Download the Tarball:</emphasis>
-                        You can download the tarball from
-                        <ulink url='&YOCTO_ADTINSTALLER_DL_URL;'></ulink> into
-                        any directory.</para></listitem>
-                    <listitem><para><emphasis>Build the Tarball:</emphasis>
-                        You can use BitBake to generate the tarball inside an
-                        existing
-                        <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
-                        </para>
-                        <para>If you use BitBake to generate the ADT Installer
-                        tarball, you must <filename>source</filename> the
-                        environment setup script
-                        (<ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>
-                        or
-                        <ulink url='&YOCTO_DOCS_REF_URL;#structure-memres-core-script'><filename>oe-init-build-env-memres</filename></ulink>)
-                        located in the Source Directory before running the
-                        BitBake command that creates the tarball.</para>
-                        <para>The following example commands establish
-                        the
-                        <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>,
-                        check out the current release branch, set up the
-                        build environment while also creating the default
-                        Build Directory, and run the BitBake command that
-                        results in the tarball
-                        <filename>poky/build/tmp/deploy/sdk/adt_installer.tar.bz2</filename>:
-                        <note>
-                            Before using BitBake to build the ADT tarball, be
-                            sure to make sure your
-                            <filename>local.conf</filename> file is properly
-                            configured.
-                        </note>
-                        <literallayout class='monospaced'>
+                You can download the tarball into any directory from the
+                <ulink url='&YOCTO_DL_URL;/releases'>Index of Releases</ulink>, specifically
+                at
+                <ulink url='&YOCTO_ADTINSTALLER_DL_URL;'></ulink>.
+                Or, you can use BitBake to generate the tarball inside the existing
+                <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+            </para>
+
+            <para>
+                If you use BitBake to generate the ADT Installer tarball, you must
+                <filename>source</filename> the environment setup script
+                (<ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>
+                or
+                <ulink url='&YOCTO_DOCS_REF_URL;#structure-memres-core-script'><filename>oe-init-build-env-memres</filename></ulink>)
+                located in the Source Directory before running the
+                BitBake command that creates the tarball.
+            </para>
+
+            <para>
+                The following example commands download the Poky tarball, set up the
+                <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>,
+                set up the environment while also creating the default Build Directory,
+                and run the BitBake command that results in the tarball
+                <filename>~/yocto-project/build/tmp/deploy/sdk/adt_installer.tar.bz2</filename>:
+                <literallayout class='monospaced'>
      $ cd ~
-     $ git clone git://git.yoctoproject.org/poky
-     $ cd poky
-     $ git checkout -b &DISTRO_NAME; origin/&DISTRO_NAME;
-     $ source &OE_INIT_FILE;
+     $ mkdir yocto-project
+     $ cd yocto-project
+     $ wget &YOCTO_RELEASE_DL_URL;/&YOCTO_POKY_TARBALL;
+     $ tar xjf &YOCTO_POKY_TARBALL;
+     $ source &OE_INIT_PATH;
      $ bitbake adt-installer
-                        </literallayout></para></listitem>
-                </itemizedlist>
+                </literallayout>
             </para>
         </section>
 
@@ -136,7 +127,7 @@
                 a top-level directory named <filename>adt-installer</filename>:
                 <literallayout class='monospaced'>
      $ cd ~
-     $ cp poky/build/tmp/deploy/sdk/adt_installer.tar.bz2 $HOME
+     $ cp ~/poky/build/tmp/deploy/sdk/adt_installer.tar.bz2 $HOME
      $ tar -xjf adt_installer.tar.bz2
                 </literallayout>
                 Unpacking it creates the directory <filename>adt-installer</filename>,
@@ -206,7 +197,7 @@
                 When you run the installer, the environment must use a
                 host <filename>gcc</filename>:
                 <literallayout class='monospaced'>
-     $ cd adt-installer
+     $ cd ~/adt-installer
      $ ./adt_installer
                 </literallayout>
                 Once the installer begins to run, you are asked to enter the
@@ -277,7 +268,7 @@
                             target, go into the <filename>x86_64</filename>
                             folder and download the following installer:
                             <literallayout class='monospaced'>
-     poky-eglibc-x86_64-core-image-sato-i586-toolchain-&DISTRO;.sh
+     poky-eglibc-x86_64-core-image-sato-i586-&DISTRO;.sh
                             </literallayout></para></listitem>
                         <listitem><para>Build your own toolchain installer.
                             For cases where you cannot use an installer
@@ -288,32 +279,27 @@
                     </itemizedlist></para></listitem>
                 <listitem><para>Once you have the installer, run it to install
                     the toolchain.
-                    <note>
-                        You must change the permissions on the toolchain
-                        installer script so that it is executable.
-                    </note></para>
+                    You must change the permissions on the toolchain installer
+                    script so that it is executable.</para>
                     <para>The following command shows how to run the installer
                     given a toolchain tarball for a 64-bit x86 development host
                     system and a 32-bit x86 target architecture.
                     The example assumes the toolchain installer is located
                     in <filename>~/Downloads/</filename>.
                     <literallayout class='monospaced'>
-     $ ~/Downloads/poky-eglibc-x86_64-core-image-sato-i586-toolchain-&DISTRO;.sh
+     $ ~/Downloads/poky-eglibc-x86_64-core-image-sato-i586-&DISTRO;.sh
                     </literallayout>
-                    The first thing the installer prompts you for is the
-                    directory into which you want to install the toolchain.
-                    The default directory used is
-                    <filename>/opt/poky/&DISTRO;</filename>.
-                    If you do not have write permissions for the directory
-                    into which you are installing the toolchain, the
-                    toolchain installer notifies you and exits.
-                    Be sure you have write permissions in the directory and
-                    run the installer again.</para>
-                    <para>When the script finishes, the cross-toolchain is
+                    <note>
+                        If you do not have write permissions for the directory
+                        into which you are installing the toolchain, the
+                        toolchain installer notifies you and exits.
+                        Be sure you have write permissions in the directory and
+                        run the installer again.
+                    </note>
+                    Once the tarball is expanded, the cross-toolchain is
                     installed.
                     You will notice environment setup files for the
-                    cross-toolchain in the installation directory.
-                    </para></listitem>
+                    cross-toolchain in the directory.</para></listitem>
             </orderedlist>
         </para>
     </section>
@@ -334,43 +320,37 @@
         <para>
             Follow these steps to generate the toolchain into the Build Directory:
             <orderedlist>
-                <listitem><para><emphasis>Set up the Build Environment:</emphasis>
-                    Source the OpenEmbedded build environment setup
-                    script (i.e.
-                    <ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>
-                    or
-                    <ulink url='&YOCTO_DOCS_REF_URL;#structure-memres-core-script'><filename>oe-init-build-env-memres</filename></ulink>)
-                    located in the
+                <listitem><para>Source the environment setup script
+                    <filename>&OE_INIT_FILE;</filename> located in the
                     <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
                     </para></listitem>
-                <listitem><para><emphasis>Check your Local Configuration File:</emphasis>
-                    At this point, you should be sure that the
+                <listitem><para>At this point, you should be sure that the
                     <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink> variable
                     in the <filename>local.conf</filename> file found in the
                     <filename>conf</filename> directory of the Build Directory
                     is set for the target architecture.
-                    Comments within the <filename>local.conf</filename> file
-                    list the values you can use for the
-                    <filename>MACHINE</filename> variable.
-                    <note>
-                        You can populate the Build Directory with the
-                        cross-toolchains for more than a single architecture.
-                        You just need to edit the <filename>MACHINE</filename>
-                        variable in the <filename>local.conf</filename> file and
-                        re-run the BitBake command.
-                    </note></para></listitem>
-                <listitem><para><emphasis>Generate the Cross-Toolchain:</emphasis>
-                    Run <filename>bitbake meta-ide-support</filename> to
-                    complete the cross-toolchain generation.
-                    Once the BitBake command finishes, the cross-toolchain is
-                    generated and populated within the Build Directory.
-                    You will notice environment setup files for the
-                    cross-toolchain that contain the string
-                    "<filename>environment-setup</filename>" in the
-                    Build Directory's <filename>tmp</filename> folder.</para>
-                    <para>Be aware that when you use this method to install the
-                    toolchain, you still need to separately extract and install
-                    the sysroot filesystem.
+                    Comments within the <filename>local.conf</filename> file list the values you
+                    can use for the <filename>MACHINE</filename> variable.
+                    <note>You can populate the Build Directory with the cross-toolchains for more
+                        than a single architecture.
+                        You just need to edit the <filename>MACHINE</filename> variable in the
+                        <filename>local.conf</filename> file and re-run the BitBake
+                        command.</note></para></listitem>
+                <listitem><para>Run <filename>bitbake meta-ide-support</filename> to complete the
+                    cross-toolchain generation.
+                    <note>If you change out of your working directory after you
+                        <filename>source</filename> the environment setup script and before you run
+                        the BitBake command, the command might not work.
+                        Be sure to run the BitBake command immediately
+                        after checking or editing the <filename>local.conf</filename> but without
+                        changing out of your working directory.</note>
+                    Once the BitBake command finishes,
+                    the cross-toolchain is generated and populated within the Build Directory.
+                    You will notice environment setup files for the cross-toolchain in the
+                    Build Directory in the <filename>tmp</filename> directory.
+                    Setup script filenames contain the strings <filename>environment-setup</filename>.</para>
+                    <para>Be aware that when you use this method to install the toolchain you still need
+                    to separately extract and install the sysroot filesystem.
                     For information on how to do this, see the
                     "<link linkend='extracting-the-root-filesystem'>Extracting the Root Filesystem</link>" section.
                     </para></listitem>
@@ -457,8 +437,8 @@
             application from within the
             Eclipse IDE, you must have an image that contains the Yocto Target Communication
             Framework (TCF) agent (<filename>tcf-agent</filename>).
-            By default, the Yocto Project provides only one type of pre-built
-            image that contains the <filename>tcf-agent</filename>.
+            By default, the Yocto Project provides only one type pre-built image that contains the
+            <filename>tcf-agent</filename>.
             And, those images are SDK (e.g.<filename>core-image-sato-sdk</filename>).
         </para>
 
@@ -487,16 +467,13 @@
                             the following commands:
                             <literallayout class='monospaced'>
      $ git clone http://git.eclipse.org/gitroot/tcf/org.eclipse.tcf.agent.git
-     $ cd org.eclipse.tcf.agent/agent
+     $ cd agent
                             </literallayout></para></listitem>
-                        <listitem><para>Locate the
-                            <filename>Makefile.inc</filename> file inside the
-                            <filename>agent</filename> folder and modify it
+                        <listitem><para>Modify the <filename>Makefile.inc</filename> file
                             for the cross-compilation environment by setting the
                             <filename>OPSYS</filename> and
                             <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink>
-                            variables according to your target.
-                            </para></listitem>
+                            variables according to your target.</para></listitem>
                         <listitem><para>Use the cross-development tools to build the
                             <filename>tcf-agent</filename>.
                             Before you "Make" the file, be sure your cross-tools are set up first.
@@ -516,63 +493,32 @@
         <title>Extracting the Root Filesystem</title>
 
         <para>
-            If you install your toolchain by hand or build it using BitBake and
-            you need a root filesystem, you need to extract it separately.
-            If you use the ADT Installer to install the ADT, the root
-            filesystem is automatically extracted and installed.
-        </para>
-
-        <para>
-            Here are some cases where you need to extract the root filesystem:
-            <itemizedlist>
-                <listitem><para>You want to boot the image using NFS.
-                    </para></listitem>
-                <listitem><para>You want to use the root filesystem as the
-                    target sysroot.
-                    For example, the Eclipse IDE environment with the Eclipse
-                    Yocto Plug-in installed allows you to use QEMU to boot
-                    under NFS.</para></listitem>
-                <listitem><para>You want to develop your target application
-                    using the root filesystem as the target sysroot.
-                    </para></listitem>
-            </itemizedlist>
+            You must extract the root filesystem if you want to boot the image using NFS
+            or you want to use the root filesystem as the target sysroot.
+            For example, the Eclipse IDE environment with the Eclipse Yocto Plug-in installed allows you
+            to use QEMU to boot under NFS.
+            Another example is if you want to develop your target application using the
+            root filesystem as the target sysroot.
         </para>
 
         <para>
             To extract the root filesystem, first <filename>source</filename>
-            the cross-development environment setup script.
-            If you built the toolchain in the Build Directory, you will find
-            the toolchain environment script in the
-            <filename>tmp</filename> directory.
-            If you installed the toolchain by hand, the environment setup
-            script is located in <filename>/opt/poky/&DISTRO;</filename>.
-        </para>
-
-        <para>
-            After sourcing the environment script, use the
-            <filename>runqemu-extract-sdk</filename> command and provide the
+            the cross-development environment setup script and then
+            use the <filename>runqemu-extract-sdk</filename> command on the
             filesystem image.
-        </para>
-
-        <para>
-            Following is an example.
-            The second command sets up the environment.
-            In this case, the setup script is located in the
-            <filename>/opt/poky/&DISTRO;</filename> directory.
-            The third command extracts the root filesystem from a previously
-            built filesystem that is located in the
-            <filename>~/Downloads</filename> directory.
-            Furthermore, this command extracts the root filesystem into the
-            <filename>qemux86-sato</filename> directory:
+            For example, the following commands set up the environment and then extract
+            the root filesystem from a previously built filesystem image tarball named
+            <filename>core-image-sato-sdk-qemux86-2011091411831.rootfs.tar.bz2</filename>.
+            The example extracts the root filesystem into the <filename>$HOME/qemux86-sato</filename>
+            directory:
             <literallayout class='monospaced'>
-     $ cd ~
-     $ source /opt/poky/&DISTRO;/environment-setup-i586-poky-linux
+     $ source $HOME/toolchain_dir/environment-setup-i586-poky-linux
      $ runqemu-extract-sdk \
-        ~/Downloads/core-image-sato-sdk-qemux86-2011091411831.rootfs.tar.bz2 \
+        ~Downloads/core-image-sato-sdk-qemux86-2011091411831.rootfs.tar.bz2 \
         $HOME/qemux86-sato
             </literallayout>
-            You could now point to the target sysroot at
-            <filename>qemux86-sato</filename>.
+            In this case, you could now point to the target sysroot at
+            <filename>$HOME/qemux86-sato</filename>.
         </para>
     </section>
 </section>
@@ -582,26 +528,30 @@
 
     <para>
         As an alternative to locating and downloading a toolchain installer,
-        you can build the toolchain installer one of two ways if you have a
-        <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>:
-        <itemizedlist>
-            <listitem><para>Use <filename>bitbake meta-toolchain</filename>.
-                This method requires you to still install the target
-                sysroot by installing and extracting it separately.
-                For information on how to install the sysroot, see the
-                "<link linkend='extracting-the-root-filesystem'>Extracting the Root Filesystem</link>"
-                section.</para></listitem>
-            <listitem><para>Use
-                <filename>bitbake image -c populate_sdk</filename>.
-                This method has significant advantages over the previous method
-                because it results in a toolchain installer that contains the
-                sysroot that matches your target root filesystem.
-                </para></listitem>
-        </itemizedlist>
+        you can build the toolchain installer if you have a
+        <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
     </para>
 
     <para>
-         Remember, before using any BitBake command, you
+        You can build the toolchain
+        installer using <filename>bitbake meta-toolchain</filename>.
+        This method requires you to still install the target
+        sysroot by installing and extracting it separately.
+        For information on how to install the sysroot, see the
+        "<link linkend='extracting-the-root-filesystem'>Extracting the Root Filesystem</link>" section.
+    </para>
+
+    <para>
+        A final method of building the toolchain installer exists that has
+        significant advantages over the previous method.
+        This method results in a toolchain installer that contains the sysroot
+        that matches your target root filesystem.
+        To build this installer, use the
+        <filename>bitbake image -c populate_sdk</filename> command.
+    </para>
+
+    <para>
+         Remember, before using any <filename>bitbake</filename> command, you
          must source the build environment setup script
          (i.e.
          <ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>
@@ -617,27 +567,12 @@
          variable is correctly set if you are building a toolchain designed to
          run on an architecture that differs from your current development host
          machine (i.e. the build machine).
-    </para>
+     </para>
 
-    <para>
-        When the BitBake command completes, the toolchain installer will be in
-        <filename>tmp/deploy/sdk</filename> in the Build Directory.
-        <note>
-            By default, this toolchain does not build static binaries.
-            If you want to use the toolchain to build these types of libraries,
-            you need to be sure your image has the appropriate static
-            development libraries.
-            Use the
-            <ulink url='&YOCTO_DOCS_REF_URL;#var-IMAGE_INSTALL'><filename>IMAGE_INSTALL</filename></ulink>
-            variable inside your <filename>local.conf</filename> file to
-            install the appropriate library packages.
-            Following is an example using <filename>eglibc</filename> static
-            development libraries:
-            <literallayout class='monospaced'>
-     IMAGE_INSTALL_append = " eglibc-staticdev"
-            </literallayout>
-        </note>
-    </para>
+     <para>
+         When the BitBake command completes, the toolchain installer will be in
+         <filename>tmp/deploy/sdk</filename> in the Build Directory.
+     </para>
 </section>
 
 </chapter>

documentation/bsp-guide/bsp-guide.xml

@@ -78,16 +78,6 @@
                 <date>October 2013</date>
                 <revremark>Released with the Yocto Project 1.5 Release.</revremark>
             </revision>
-            <revision>
-                <revnumber>1.5.1</revnumber>
-                <date>Sometime in 2013</date>
-                <revremark>Released with the Yocto Project 1.5.1 Release.</revremark>
-            </revision>
-            <revision>
-                <revnumber>1.6</revnumber>
-                <date>Sometime 2014</date>
-                <revremark>Released with the Yocto Project 1.6 Release.</revremark>
-            </revision>
         </revhistory>
 
     <copyright>
@@ -101,10 +91,11 @@
         the terms of the <ulink type="http" url="http://creativecommons.org/licenses/by-nc-sa/2.0/uk/">Creative Commons Attribution-Non-Commercial-Share Alike 2.0 UK: England &amp; Wales</ulink> as published by Creative Commons.
       </para>
       <note>
-          For the latest version of this manual associated with this
-          Yocto Project release, see the
-          <ulink url='&YOCTO_DOCS_BSP_URL;'>Yocto Project Board Support Package (BSP) Developer's Guide</ulink>
-          from the Yocto Project website.
+          Due to production processes, there could be differences between the Yocto Project
+          documentation bundled in the release tarball and the
+          <ulink url='&YOCTO_DOCS_BSP_URL;'>Yocto Project Board Support Package (BSP) Developer's Guide</ulink> on
+          the <ulink url='&YOCTO_HOME_URL;'>Yocto Project</ulink> website.
+          For the latest version of this manual, see the manual on the website.
       </note>
     </legalnotice>
 

documentation/bsp-guide/bsp.xml

@@ -394,13 +394,12 @@
 
             <para>
                 To use an include file, you simply include them in the machine configuration file.
-                For example, the Crown Bay BSP <filename>crownbay.conf</filename> contains the
+                For example, the Crown Bay BSP <filename>crownbay.conf</filename> has the
                 following statements:
                 <literallayout class='monospaced'>
      require conf/machine/include/tune-atom.inc
      require conf/machine/include/ia32-base.inc
      require conf/machine/include/meta-intel.inc
-     require conf/machine/include/meta-intel-emgd.inc
                 </literallayout>
             </para>
             </section>
@@ -421,7 +420,7 @@
                 <filename>formfactor_0.0.bbappend</filename> file, which is an
                 append file used to augment the recipe that starts the build.
                 Furthermore, there are machine-specific settings used during the
-                build that are defined by the <filename>machconfig</filename> file.
+                build that are defined by the <filename>machconfig</filename>.
                 In the Crown Bay example, two <filename>machconfig</filename> files
                 exist: one that supports the Intel® Embedded Media and Graphics
                 Driver (Intel® EMGD) and one that does not:
@@ -461,7 +460,7 @@
                 (VESA) graphics):
                 <literallayout class='monospaced'>
      meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
-     meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay/xorg.conf
+     meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay-noemgd/xorg.conf
                 </literallayout>
             </para>
             </section>
@@ -562,7 +561,7 @@
             <para>
                 For example, suppose you had some configuration options in a file called
                 <filename>network_configs.cfg</filename>.
-                You can place that file inside a directory named <filename>linux-yocto</filename> and then add
+                You can place that file inside a directory named <filename>/linux-yocto</filename> and then add
                 a <filename>SRC_URI</filename> statement such as the following to the append file.
                 When the OpenEmbedded build system builds the kernel, the configuration options are
                 picked up and applied.
@@ -748,7 +747,7 @@
                                 <listitem><para>Instructions on how to boot the BSP build from
                                     the BSP layer.</para></listitem>
                                 <listitem><para>Instructions on how to boot the binary images
-                                    contained in the <filename>binary</filename> directory,
+                                    contained in the <filename>/binary</filename> directory,
                                     if present.</para></listitem>
                                 <listitem><para>Information on any known bugs or issues that users
                                     should know about when either building or booting the BSP
@@ -759,7 +758,7 @@
                             <filename>meta-&lt;bsp_name&gt;</filename> directory.
                             This file specifies exactly where you can find the sources used to
                             generate the binary images contained in the
-                            <filename>binary</filename> directory, if present.
+                            <filename>/binary</filename> directory, if present.
                             See the
                             <ulink url='&YOCTO_GIT_URL;/cgit.cgi/meta-intel/tree/meta-fri2/README.sources'><filename>README.sources</filename></ulink>
                             file for the Fish River Island 2 BSP in the <filename>meta-fri2</filename> BSP layer

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

@@ -155,11 +155,10 @@
                     For more information on BSP layers, see the
                     "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-layers'>BSP Layers</ulink>" section in the
                     Yocto Project Board Support Package (BSP) Developer's Guide.</para>
-                    <note>Five BSPs exist that are part of the
-                    Yocto Project release: <filename>genericx86</filename>, <filename>genericx86-64</filename>,
-                    <filename>beagleboard</filename>,
+                    <note>Four BSPs exist that are part of the
+                    Yocto Project release: <filename>genericx86</filename>, <filename>beagleboard</filename>,
                     <filename>mpc8315e</filename>, and <filename>routerstationpro</filename>.
-                    The recipes and configurations for these five BSPs are located and dispersed
+                    The recipes and configurations for these four BSPs are located and dispersed
                     within the <link linkend='source-directory'>Source Directory</link>.
                     On the other hand, BSP layers for Chief River, Crown Bay,
                     Crystal Forest, Emenlow, Fish River Island 2, Jasper Forest, N450, NUC DC3217IYE,
@@ -219,10 +218,10 @@
         <para>
             You can view a video presentation on "Building Custom Embedded Images with Yocto"
             at <ulink url='http://free-electrons.com/blog/elc-2011-videos'>Free Electrons</ulink>.
-            You can also find supplemental information in the
+            You can also find supplemental information in
             <ulink url='&YOCTO_DOCS_BSP_URL;'>
-            Yocto Project Board Support Package (BSP) Developer's Guide</ulink>.
-            Finally, there is a wiki page write up of the example also located
+            The Board Support Package (BSP) Development Guide</ulink>.
+            Finally, there is wiki page write up of the example also located
             <ulink url='&YOCTO_WIKI_URL;/wiki/Transcript:_creating_one_generic_Atom_BSP_from_another'>
             here</ulink> that you might find helpful.
        </para>
@@ -419,9 +418,8 @@
                         If you have never built the kernel you are interested in, you need to run
                         an initial build to establish local kernel source files.</para>
                         <para>If you are building an image for the first time, you need to get the build
-                        environment ready by sourcing an environment setup script
-                        (e.g. <filename>oe-init-build-env</filename> or
-                        <filename>oe-init-build-env-memres</filename>).
+                        environment ready by sourcing
+                        the environment setup script.
                         You also need to be sure two key configuration files
                         (<filename>local.conf</filename> and <filename>bblayers.conf</filename>)
                         are configured appropriately.</para>
@@ -1426,6 +1424,9 @@
                         "<ulink url='&YOCTO_DOCS_PROF_URL;#profile-manual-perf'>perf</ulink>"
                         section in the Yocto Project Profiling and Tracing
                         Manual.
+                        For information on LatencyTOP, see the
+                        <ulink url='https://latencytop.org/'>LatencyTOP</ulink>
+                        website.
                         </para></listitem>
                 </itemizedlist>
             </para>
@@ -1469,14 +1470,7 @@
                             the "Clone from Yocto Git Repository" box, which
                             would execute a <filename>git clone</filename>
                             command to get the project's Metadata files.
-                            <note>
-                                Do not specify your BitBake Commander project
-                                location as your Eclipse workspace.
-                                Doing so causes an error indicating that the
-                                current project overlaps the location of
-                                another project.
-                                This error occurs even if no such project exits.
-                            </note></para></listitem>
+                            </para></listitem>
                         <listitem><para>Select <filename>Finish</filename> to
                             create the project.</para></listitem>
                     </orderedlist>
@@ -1645,7 +1639,7 @@
             <filename>meta/conf/bitbake.conf</filename> configuration file in the
             <link linkend='source-directory'>Source Directory</link>:
             <literallayout class='monospaced'>
-     S = "${WORKDIR}/${BP}"
+     S = ${WORKDIR}/${BP}
             </literallayout>
             You should be aware that many recipes override the <filename>S</filename> variable.
             For example, recipes that fetch their source from Git usually set
@@ -1655,7 +1649,7 @@
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-BP'><filename>BP</filename></ulink>
                 represents the base recipe name, which consists of the name and version:
                 <literallayout class='monospaced'>
-     BP = "${BPN}-${PV}"
+     BP = ${BPN}-${PV}
                 </literallayout>
             </note>
         </para>
@@ -1676,7 +1670,7 @@
             the following is the work directory for the <filename>acl</filename> recipe that
             creates the <filename>acl</filename> package:
             <literallayout class='monospaced'>
-     poky/build/tmp/work/i586-poky-linux/acl/2.2.51-r3/
+     ~/poky/build/tmp/work/i586-poky-linux/acl/2.2.51-r3/
             </literallayout>
         </para>
 
@@ -1692,8 +1686,8 @@
             for the <filename>acl</filename> package that is being
             built for a MIPS-based device:
             <literallayout class='monospaced'>
-     poky/build/tmp/work/mips-poky-linux/acl/2.2.51-r2
-     poky/build/tmp/work/mips-poky-linux/acl/2.2.51-r2/acl-2.2.51
+     ~/poky/build/tmp/work/mips-poky-linux/acl/2.2.51-r2
+     ~/poky/build/tmp/work/mips-poky-linux/acl/2.2.51-r2/acl-2.2.51
             </literallayout>
         </para>
 
@@ -1704,7 +1698,6 @@
             <ulink url='&YOCTO_DOCS_REF_URL;#var-TMPDIR'><filename>TMPDIR</filename></ulink>,
             <ulink url='&YOCTO_DOCS_REF_URL;#var-TOPDIR'><filename>TOPDIR</filename></ulink>,
             <ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGE_ARCH'><filename>PACKAGE_ARCH</filename></ulink>,
-            <ulink url='&YOCTO_DOCS_REF_URL;#var-MULTIMACH_TARGET_SYS'><filename>MULTIMACH_TARGET_SYS</filename></ulink>,
             <ulink url='&YOCTO_DOCS_REF_URL;#var-TARGET_OS'><filename>TARGET_OS</filename></ulink>,
             <ulink url='&YOCTO_DOCS_REF_URL;#var-PN'><filename>PN</filename></ulink>,
             <ulink url='&YOCTO_DOCS_REF_URL;#var-PV'><filename>PV</filename></ulink>,

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

@@ -406,34 +406,38 @@
     <title>Yocto Project Source Repositories</title>
 
     <para>
-        The Yocto Project team maintains complete source repositories for all
-        Yocto Project files at
-        <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi'></ulink>.
-        This web-based source code browser is organized into categories by
-        function such as IDE Plugins, Matchbox, Poky, Yocto Linux Kernel, and
-        so forth.
-        From the interface, you can click on any particular item in the "Name"
-        column and see the URL at the bottom of the page that you need to clone
-        a Git repository for that particular item.
-        Having a local Git repository of the Source Directory (poky) allows
-        you to make changes, contribute to the history, and ultimately enhance
-        the Yocto Project's tools, Board Support Packages, and so forth.
+        The Yocto Project team maintains complete source repositories for all Yocto Project files
+        at <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi'></ulink>.
+        This web-based source code browser is organized into categories by function such as
+        IDE Plugins, Matchbox, Poky, Yocto Linux Kernel, and so forth.
+        From the interface, you can click on any particular item in the "Name" column and
+        see the URL at the bottom of the page that you need to clone a Git repository for
+        that particular item.
+        Having a local Git repository of the Source Directory (poky) allows you to
+        make changes, contribute to the history, and ultimately enhance the Yocto Project's
+        tools, Board Support Packages, and so forth.
     </para>
 
     <para>
-        For any supported release of Yocto Project, you can also go to the
+        Conversely, if you are a developer that is not interested in contributing back to the
+        Yocto Project, you have the ability to simply download and extract release tarballs
+        and use them within the Yocto Project environment.
+        All that is required is a particular release of the Yocto Project and
+        your application source code.
+    </para>
+
+    <para>
+        For any supported release of Yocto Project, you can go to the
         <ulink url='&YOCTO_HOME_URL;'>Yocto Project Website</ulink> and
-        select the "Downloads" tab and get a released tarball of the
-        <filename>poky</filename> repository or any supported BSP tarballs.
-        Unpacking these tarballs gives you a snapshot of the released
-        files.
-        <note>
-            The recommended method for setting up the Yocto Project
-            <link linkend='source-directory'>Source Directory</link> and the
-            files for supported BSPs (e.g., <filename>meta-intel</filename>) is to
-            use <link linkend='git'>Git</link> to create a local copy of the
-            upstream repositories.
-        </note>
+        select the "Downloads" tab and get a tarball of the release.
+        You can also go to this site to download any supported BSP tarballs.
+        Unpacking the tarball gives you a hierarchical Source Directory that lets you develop
+        using the Yocto Project.
+    </para>
+
+    <para>
+        Once you are set up through either tarball extraction or a checkout of Git repositories,
+        you are ready to develop.
     </para>
 
     <para>
@@ -510,40 +514,27 @@
                 The <ulink url='&YOCTO_DOCS_REF_URL;#var-TOPDIR'><filename>TOPDIR</filename></ulink>
                 variable points to the Build Directory.</para>
 
-                <para>
-                    You have a lot of flexibility when creating the Build
-                    Directory.
-                    Following are some examples that show how to create the
-                    directory.
-                    The examples assume your
-                    <link linkend='source-directory'>Source Directory</link> is
-                    named <filename>poky</filename>:
+                <para>You have a lot of flexibility when creating the Build Directory.
+                Following are some examples that show how to create the directory:
                    <itemizedlist>
-                        <listitem><para>Create the Build Directory inside your
-                            Source Directory and let the name of the Build
-                            Directory default to <filename>build</filename>:
+                        <listitem><para>Create the Build Directory in your current working directory
+                            and name it <filename>build</filename>.
+                            This is the default behavior.
                             <literallayout class='monospaced'>
-     $ cd $HOME/poky
-     $ source &OE_INIT_FILE;
+     $ source &OE_INIT_PATH;
                             </literallayout></para></listitem>
-                        <listitem><para>Create the Build Directory inside your
-                            home directory and specifically name it
-                            <filename>test-builds</filename>:
+                        <listitem><para>Provide a directory path and specifically name the build
+                            directory.
+                            This next example creates a Build Directory named <filename>YP-&POKYVERSION;</filename>
+                            in your home directory within the directory <filename>mybuilds</filename>.
+                            If <filename>mybuilds</filename> does not exist, the directory is created for you:
                             <literallayout class='monospaced'>
-     $ cd $HOME
-     $ source poky/&OE_INIT_FILE; test-builds
+     $ source &OE_INIT_PATH; $HOME/mybuilds/YP-&POKYVERSION;
                             </literallayout></para></listitem>
-                        <listitem><para>Provide a directory path and
-                            specifically name the build directory.
-                            Any intermediate folders in the pathname must
-                            exist.
-                            This next example creates a Build Directory named
-                            <filename>YP-&POKYVERSION;</filename>
-                            in your home directory within the existing
-                            directory <filename>mybuilds</filename>:
+                        <listitem><para>Provide an existing directory to use as the Build Directory
+                            and use the default <filename>build</filename> name.
                             <literallayout class='monospaced'>
-     $cd $HOME
-     $ source $HOME/poky/&OE_INIT_FILE; $HOME/mybuilds/YP-&POKYVERSION;
+     $ source &OE_INIT_PATH; $HOME/mybuilds/
                             </literallayout></para></listitem>
                     </itemizedlist>
                 </para></listitem>
@@ -656,17 +647,6 @@
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-PV'><filename>PV</filename></ulink>, and
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-PE'><filename>PE</filename></ulink>).
                 </para></listitem>
-            <listitem><para><emphasis>Package Groups:</emphasis>
-                Arbitrary groups of software Recipes.
-                You use package groups to hold recipes that, when built,
-                usually accomplish a single task.
-                For example, a package group could contain the recipes for a
-                company’s proprietary or value-add software.
-                Or, the package group could contain the recipes that enable
-                graphics.
-                A package group is really just another recipe.
-                Because package group files are recipes, they end with the
-                <filename>.bb</filename> filename extension.</para></listitem>
             <listitem><para id='poky'><emphasis>Poky:</emphasis> The term "poky" can mean several things.
                 In its most general sense, it is an open-source project that was initially developed
                 by OpenedHand.  With OpenedHand, poky was developed off of the existing OpenEmbedded
@@ -686,69 +666,63 @@
                 use the <filename>.bb</filename> file extension.</para></listitem>
             <listitem>
                 <para id='source-directory'><emphasis>Source Directory:</emphasis>
-                This term refers to the directory structure created as a result
-                of creating a local copy of the <filename>poky</filename> Git
-                repository <filename>git://git.yoctoproject.org/poky</filename>
-                or expanding a released <filename>poky</filename> tarball.
-                Sometimes you might hear the term "poky directory" used to refer
-                to this directory structure.
-                <note>
-                    The OpenEmbedded build system does not support file or
-                    directory names that contain spaces.
-                    Be sure that the Source Directory you use does not contain
-                    these types of names.
-                </note></para>
-
-                <para>The Source Directory contains BitBake, Documentation,
-                Metadata and other files that all support the Yocto Project.
-                Consequently, you must have the Source Directory in place on
-                your development system in order to do any development using
-                the Yocto Project.</para>
-
-                <para>When you create a local copy of the Git repository, you
-                can name the repository anything you like.
-                Throughout much of the documentation, <filename>poky</filename>
-                is used as the name of the top-level folder of the local copy of
-                the poky Git repository.
-                So, for example, cloning the <filename>poky</filename> Git
-                repository results in a local Git repository whose top-level
-                folder is also named <filename>poky</filename>.</para>
-
-                <para>While it is not recommended that you use tarball expansion
-                to setup the Source Directory, if you do, the top-level
-                directory name of the Source Directory is derived from the
-                Yocto Project release tarball.
-                For example, downloading and unpacking
-                <filename>&YOCTO_POKY_TARBALL;</filename> results in a
-                Source Directory whose root folder is named
-                <filename>&YOCTO_POKY;</filename>.</para>
-
-                <para>It is important to understand the differences between the
-                Source Directory created by unpacking a released tarball as
-                compared to cloning
+                This term refers to the directory structure created as a result of either downloading
+                and unpacking a Yocto Project release tarball or creating a local copy of
+                the <filename>poky</filename> Git repository
                 <filename>git://git.yoctoproject.org/poky</filename>.
-                When you unpack a tarball, you have an exact copy of the files
-                based on the time of release - a fixed release point.
-                Any changes you make to your local files in the Source Directory
-                are on top of the release and will remain local only.
-                On the other hand, when you clone the <filename>poky</filename>
-                Git repository, you have an active development repository with
-                access to the upstream repository's branches and tags.
-                In this case, any local changes you make to the local
-                Source Directory can be later applied to active development
-                branches of the upstream <filename>poky</filename> Git
+                Sometimes you might hear the term "poky directory" used to refer to this
+                directory structure.
+                <note>
+                    The OpenEmbedded build system does not support file or directory names that
+                    contain spaces.
+                    Be sure that the Source Directory you use does not contain these types
+                    of names.
+                </note></para>
+                <para>The Source Directory contains BitBake, Documentation, Metadata and
+                other files that all support the Yocto Project.
+                Consequently, you must have the Source Directory in place on your development
+                system in order to do any development using the Yocto Project.</para>
+
+                <para>For tarball expansion, the name of the top-level directory of the Source Directory
+                is derived from the Yocto Project release tarball.
+                For example, downloading and unpacking <filename>&YOCTO_POKY_TARBALL;</filename>
+                results in a Source Directory whose top-level folder is named
+                <filename>&YOCTO_POKY;</filename>.
+                If you create a local copy of the Git repository, you can name the repository
+                anything you like.
+                Throughout much of the documentation, <filename>poky</filename> is used as the name of
+                the top-level folder of the local copy of the poky Git repository.
+                So, for example, cloning the <filename>poky</filename> Git repository results in a
+                local Git repository whose top-level folder is also named <filename>poky</filename>.</para>
+
+                <para>It is important to understand the differences between the Source Directory created
+                by unpacking a released tarball as compared to cloning
+                <filename>git://git.yoctoproject.org/poky</filename>.
+                When you unpack a tarball, you have an exact copy of the files based on the time of
+                release - a fixed release point.
+                Any changes you make to your local files in the Source Directory are on top of the release.
+                On the other hand, when you clone the <filename>poky</filename> Git repository, you have an
+                active development repository.
+                In this case, any local changes you make to the Source Directory can be later applied
+                to active development branches of the upstream <filename>poky</filename> Git
                 repository.</para>
 
-                <para>For more information on concepts related to Git
-                repositories, branches, and tags, see the
+                <para>Finally, if you want to track a set of local changes while starting from the same point
+                as a release tarball, you can create a local Git branch that
+                reflects the exact copy of the files at the time of their release.
+                You do this by using Git tags that are part of the repository.</para>
+
+                <para>For more information on concepts related to Git repositories, branches, and tags,
+                see the
                 "<link linkend='repositories-tags-and-branches'>Repositories, Tags, and Branches</link>"
                 section.</para></listitem>
-            <listitem><para><emphasis>Task:</emphasis>
-                A unit of execution for BitBake (e.g.
-                <filename>do_compile</filename>,
-                <filename>do_fetch</filename>, <filename>do_patch</filename>,
-                and so forth).
-                </para></listitem>
+            <listitem><para><emphasis>Tasks:</emphasis> Arbitrary groups of software Recipes.
+                You use tasks to hold recipes that, when built, usually accomplish a single task.
+                For example, a task could contain the recipes for a company’s proprietary or value-add software.
+                Or, the task could contain the recipes that enable graphics.
+                A task is really just another recipe.
+                Because task files are recipes, they end with the <filename>.bb</filename> filename
+                extension.</para></listitem>
             <listitem><para><emphasis>Upstream:</emphasis> A reference to source code or repositories
                 that are not local to the development system but located in a master area that is controlled
                 by the maintainer of the source code.
@@ -833,8 +807,7 @@
     <title>Git</title>
 
     <para>
-        The Yocto Project makes extensive use of Git,
-        which is a free, open source distributed version control system.
+        The Yocto Project uses Git, which is a free, open source distributed version control system.
         Git supports distributed development, non-linear development, and can handle large projects.
         It is best that you have some fundamental understanding of how Git tracks projects and
         how to work with Git if you are going to use the Yocto Project for development.
@@ -938,7 +911,7 @@
             local working branch based on a branch name,
             your local environment matches the "tip" of that development branch
             at the time you created your local branch, which could be
-            different from the files at the time of a similarly named release.
+            different than the files at the time of a similarly named release.
             In other words, creating and checking out a local branch based on the
             <filename>&DISTRO_NAME;</filename> branch name is not the same as
             cloning and checking out the <filename>master</filename> branch.
@@ -1031,7 +1004,7 @@
                     will allow the change, and for ultimately pushing the change from your local Git repository
                     into the project’s upstream (or master) repository.</para></listitem>
                 <listitem><para><emphasis><filename>git status</filename>:</emphasis> Reports any modified files that
-                    possibly need to be staged and committed.</para></listitem>
+                    possibly need staged and committed.</para></listitem>
                 <listitem><para><emphasis><filename>git checkout &lt;branch-name&gt;</filename>:</emphasis> Changes
                     your working branch.
                     This command is analogous to "cd".</para></listitem>
@@ -1308,9 +1281,10 @@
             <listitem><para><emphasis>Board Support Package (BSP) README Files:</emphasis>
                 For BSP maintainers of supported BSPs, you can examine
                 individual BSP <filename>README</filename> files.
-                In addition, some layers (such as the <filename>meta-intel</filename> layer),
-                include a <filename>MAINTAINERS</filename> file which contains
-                a list of all supported BSP maintainers for that layer.
+                Alternatively, you can examine the
+                <filename>MAINTAINERS</filename> file, which is found in the
+                <filename>meta-intel</filename>, for a list of all supported
+                BSP maintainers.
                 </para></listitem>
             <listitem><para><emphasis>Search by File:</emphasis>
                 Using <link linkend='git'>Git</link>, you can enter the
@@ -1485,8 +1459,8 @@
                     <para>For help on using these scripts, simply provide the
                     <filename>-h</filename> argument as follows:
                     <literallayout class='monospaced'>
-     $ poky/scripts/create-pull-request -h
-     $ poky/scripts/send-pull-request -h
+     $ ~/poky/scripts/create-pull-request -h
+     $ ~/poky/scripts/send-pull-request -h
                     </literallayout></para></listitem>
             </itemizedlist>
         </para>

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

@@ -55,12 +55,12 @@
     <title>Getting Set Up</title>
 
     <para>
-        Here is what you need to use the Yocto Project:
+        Here is what you need to get set up to use the Yocto Project:
         <itemizedlist>
             <listitem><para><emphasis>Host System:</emphasis>  You should have a reasonably current
                 Linux-based host system.
                 You will have the best results with a recent release of Fedora,
-                openSUSE, Debian, Ubuntu, or CentOS as these releases are frequently tested against the Yocto Project
+                OpenSUSE, Debian, Ubuntu, or CentOS as these releases are frequently tested against the Yocto Project
                 and officially supported.
                 For a list of the distributions under validation and their status, see the
                 "<ulink url='&YOCTO_DOCS_REF_URL;#detailed-supported-distros'>Supported Linux Distributions</ulink>" section
@@ -70,7 +70,7 @@
                 You should also have about 100 gigabytes of free disk space for building images.
                 </para></listitem>
             <listitem><para><emphasis>Packages:</emphasis>  The OpenEmbedded build system
-                requires that certain packages exist on your development system (e.g. Python 2.6 or 2.7).
+                requires certain packages exist on your development system (e.g. Python 2.6 or 2.7).
                 See "<ulink url='&YOCTO_DOCS_QS_URL;#packages'>The Packages</ulink>"
                 section in the Yocto Project Quick Start and the
                 "<ulink url='&YOCTO_DOCS_REF_URL;#required-packages-for-the-host-development-system'>Required Packages for the Host Development System</ulink>"
@@ -79,33 +79,47 @@
                 them for the supported distributions.
                 </para></listitem>
             <listitem id='local-yp-release'><para><emphasis>Yocto Project Release:</emphasis>
-                You need a release of the Yocto Project installed locally on
-                your development system.
-                This local area is referred to as the
-                <link linkend='source-directory'>Source Directory</link>
-                and is created when you use
-                <link linkend='git'>Git</link> to clone a local copy
-                of the upstream <filename>poky</filename> repository,
-                or when you download an official release of the corresponding tarball.</para>
-                <para>Working from a copy of the upstream repository allows you
-                to contribute back into the Yocto Project or simply work with
-                the latest software on a development branch.
-                Because Git maintains and creates an upstream repository with
-                a complete history of changes and you are working with a local
-                clone of that repository, you have access to all the Yocto
-                Project development branches and tag names used in the upstream
-                repository.</para>
-                <note>You can view the Yocto Project Source Repositories at
-                    <ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink>
+                You need a release of the Yocto Project.
+                You set that up with a local <link linkend='source-directory'>Source Directory</link>
+                one of two ways depending on whether you
+                are going to contribute back into the Yocto Project or not.
+                <note>
+                    Regardless of the method you use, this manual refers to the resulting local
+                    hierarchical set of files as the "Source Directory."
                 </note>
-                <para>The following transcript shows how to clone the
-                <filename>poky</filename> Git repository into the current
-                working directory.
-                The command creates the local repository in a directory
-                named <filename>poky</filename>.
-                For information on Git used within the Yocto Project, see
-                the "<link linkend='git'>Git</link>" section.
-                <literallayout class='monospaced'>
+                <itemizedlist>
+                    <listitem><para><emphasis>Tarball Extraction:</emphasis>
+                        If you are not going to contribute back into the Yocto
+                        Project, you can simply go to the
+                        <ulink url='&YOCTO_HOME_URL;'>Yocto Project Website</ulink>,
+                        select the "Downloads" tab, and choose what you want.
+                        Once you have the tarball, just extract it into a
+                        directory of your choice.</para>
+                        <para>For example, the following command extracts the
+                        Yocto Project &DISTRO; release tarball
+                        into the current working directory and sets up the local Source Directory
+                        with a top-level folder named <filename>&YOCTO_POKY;</filename>:
+                        <literallayout class='monospaced'>
+     $ tar xfj &YOCTO_POKY_TARBALL;
+                        </literallayout></para>
+                        <para>This method does not produce a local Git repository.
+                        Instead, you simply end up with a snapshot of the release.</para></listitem>
+                    <listitem><para><emphasis>Git Repository Method:</emphasis>  If you are going to be contributing
+                        back into the Yocto Project or you simply want to keep up
+                        with the latest developments, you should use Git commands to set up a local
+                        Git repository of the upstream <filename>poky</filename> source repository.
+                        Doing so creates a repository with a complete history of changes and allows
+                        you to easily submit your changes upstream to the project.
+                        Because you clone the repository, you have access to all the Yocto Project development
+                        branches and tag names used in the upstream repository.</para>
+                        <note>You can view the Yocto Project Source Repositories at
+                        <ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink></note>
+                        <para>The following transcript shows how to clone the <filename>poky</filename>
+                        Git repository into the current working directory.
+                        The command creates the local repository in a directory named <filename>poky</filename>.
+                        For information on Git used within the Yocto Project, see the
+                        "<link linkend='git'>Git</link>" section.
+                        <literallayout class='monospaced'>
      $ git clone git://git.yoctoproject.org/poky
      Cloning into 'poky'...
      remote: Counting objects: 203728, done.
@@ -113,17 +127,16 @@
      remote: Total 203728 (delta 147444), reused 202891 (delta 146614)
      Receiving objects: 100% (203728/203728), 95.54 MiB | 308 KiB/s, done.
      Resolving deltas: 100% (147444/147444), done.
-                </literallayout></para>
-                <para>For another example of how to set up your own local Git
-                repositories, see this
-                <ulink url='&YOCTO_WIKI_URL;/wiki/Transcript:_from_git_checkout_to_meta-intel_BSP'>
-                wiki page</ulink>, which describes how to create both
-                <filename>poky</filename> and <filename>meta-intel</filename>
-                Git repositories.</para></listitem>
+                        </literallayout></para>
+                        <para>For another example of how to set up your own local Git repositories, see this
+                        <ulink url='&YOCTO_WIKI_URL;/wiki/Transcript:_from_git_checkout_to_meta-intel_BSP'>
+                        wiki page</ulink>, which describes how to create both <filename>poky</filename>
+                        and <filename>meta-intel</filename> Git repositories.</para></listitem>
+                </itemizedlist></para></listitem>
             <listitem id='local-kernel-files'><para><emphasis>Yocto Project Kernel:</emphasis>
                 If you are going to be making modifications to a supported Yocto Project kernel, you
                 need to establish local copies of the source.
-                You can find Git repositories of supported Yocto Project kernels organized under
+                You can find Git repositories of supported Yocto Project Kernels organized under
                 "Yocto Linux Kernel" in the Yocto Project Source Repositories at
                 <ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink>.</para>
                 <para>This setup can involve creating a bare clone of the Yocto Project kernel and then
@@ -185,20 +198,21 @@
                </literallayout></para></listitem>
            <listitem><para id='supported-board-support-packages-(bsps)'><emphasis>Supported Board
                 Support Packages (BSPs):</emphasis>
-                The Yocto Project provides a layer called
-                <filename>meta-intel</filename> and it is maintained in its own
-                separate Git repository.
-                The <filename>meta-intel</filename> layer contains many
-                supported
-                <ulink url='&YOCTO_DOCS_BSP_URL;#bsp-layers'>BSP Layers</ulink>.
-                </para>
-                <para>The Yocto Project uses the following BSP layer naming
-                scheme:
+                The Yocto Project provides a layer called <filename>meta-intel</filename> and
+                it is maintained in its own separate Git repository.
+                The <filename>meta-intel</filename> layer contains many supported
+                <ulink url='&YOCTO_DOCS_BSP_URL;#bsp-layers'>BSP Layers</ulink>.</para>
+                <para>Similar considerations exist for setting up the <filename>meta-intel</filename>
+                layer.
+                You can get set up for BSP development one of two ways: tarball extraction or
+                with a local Git repository.
+                It is a good idea to use the same method that you used to set up the Source Directory.
+                Regardless of the method you use, the Yocto Project uses the following BSP layer
+                naming scheme:
                 <literallayout class='monospaced'>
      meta-&lt;BSP_name&gt;
                 </literallayout>
-                where <filename>&lt;BSP_name&gt;</filename> is the recognized
-                BSP name.
+                where <filename>&lt;BSP_name&gt;</filename> is the recognized BSP name.
                 Here are some examples:
                 <literallayout class='monospaced'>
      meta-crownbay
@@ -207,21 +221,30 @@
                 </literallayout>
                 See the
                 "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-layers'>BSP Layers</ulink>"
-                section in the Yocto Project Board Support Package (BSP)
-                Developer's Guide for more information on BSP Layers.</para>
-                <para>You can locate the <filename>meta-intel</filename> Git
-                repository in the "Yocto Metadata Layers" area of the Yocto
-                Project Source Repositories at
-                <ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink>.</para>
-                <para>Using
-                <link linkend='git'>Git</link> to create a local clone of the
-                upstream repository can be helpful if you are working with
-                BSPs.
-                Typically, you set up the <filename>meta-intel</filename>
-                Git repository inside the Source Directory.
-                For example, the following transcript shows the steps to clone
-                <filename>meta-intel</filename>.
-                <literallayout class='monospaced'>
+                section in the Yocto Project Board Support Package (BSP) Developer's Guide for more
+                information on BSP Layers.
+                <itemizedlist>
+                    <listitem><para><emphasis>Tarball Extraction:</emphasis>  You can download any released
+                        BSP tarball from the same "Downloads" page of the
+                        <ulink url='&YOCTO_HOME_URL;'>Yocto Project Website</ulink>
+                        to get the Yocto Project release.
+                        Once on the "Download" page, look to the right of the
+                        page and scroll down to find the BSP tarballs.</para>
+                        <para>Once you have the tarball, just extract it into a directory of your choice.
+                        Again, this method just produces a snapshot of the BSP layer in the form
+                        of a hierarchical directory structure.</para></listitem>
+                    <listitem><para><emphasis>Git Repository Method:</emphasis>  If you are working
+                        with a local Git repository for your Source Directory, you should also use this method
+                        to set up the <filename>meta-intel</filename> Git repository.
+                        You can locate the <filename>meta-intel</filename> Git repository in the
+                        "Yocto Metadata Layers" area of the Yocto Project Source Repositories at
+                        <ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink>.</para>
+                        <para>Typically, you set up the <filename>meta-intel</filename> Git repository inside
+                        the Source Directory.
+                        For example, the following transcript shows the steps to clone the
+                        <filename>meta-intel</filename>
+                        Git repository inside the local <filename>poky</filename> Git repository.
+                        <literallayout class='monospaced'>
      $ cd ~/poky
      $ git clone git://git.yoctoproject.org/meta-intel.git
      Cloning into 'meta-intel'...
@@ -230,12 +253,13 @@
      remote: Total 7366 (delta 3997), reused 7299 (delta 3930)
      Receiving objects: 100% (7366/7366), 2.31 MiB | 95 KiB/s, done.
      Resolving deltas: 100% (3997/3997), done.
-                </literallayout></para>
-                <para>The same
-                <ulink url='&YOCTO_WIKI_URL;/wiki/Transcript:_from_git_checkout_to_meta-intel_BSP'>wiki page</ulink>
-                referenced earlier covers how to set up the
-                <filename>meta-intel</filename> Git repository.
-                </para></listitem>
+                        </literallayout></para>
+                        <para>The same
+                        <ulink url='&YOCTO_WIKI_URL;/wiki/Transcript:_from_git_checkout_to_meta-intel_BSP'>wiki page</ulink>
+                        referenced earlier covers how to
+                        set up the <filename>meta-intel</filename> Git repository.
+                        </para></listitem>
+                </itemizedlist></para></listitem>
             <listitem><para><emphasis>Eclipse Yocto Plug-in:</emphasis>  If you are developing
                 applications using the Eclipse Integrated Development Environment (IDE),
                 you will need this plug-in.

documentation/dev-manual/dev-manual.xml

@@ -56,16 +56,6 @@
                 <date>October 2013</date>
                 <revremark>Released with the Yocto Project 1.5 Release.</revremark>
             </revision>
-            <revision>
-                <revnumber>1.5.1</revnumber>
-                <date>Sometime in 2013</date>
-                <revremark>Released with the Yocto Project 1.5.1 Release.</revremark>
-            </revision>
-            <revision>
-                <revnumber>1.6</revnumber>
-                <date>Sometime 2014</date>
-                <revremark>Released with the Yocto Project 1.6 Release.</revremark>
-            </revision>
         </revhistory>
 
     <copyright>
@@ -82,10 +72,11 @@
       </para>
 
       <note>
-          For the latest version of this manual associated with this
-          Yocto Project release, see the
-          <ulink url='&YOCTO_DOCS_DEV_URL;'>Yocto Project Development Manual</ulink>
-          from the Yocto Project website.
+          Due to production processes, there could be differences between the Yocto Project
+          documentation bundled in the release tarball and the
+          <ulink url='&YOCTO_DOCS_DEV_URL;'>Yocto Project Development Manual</ulink> on
+          the <ulink url='&YOCTO_HOME_URL;'>Yocto Project</ulink> website.
+          For the latest version of this manual, see the manual on the website.
       </note>
     </legalnotice>
 

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

@@ -95,7 +95,7 @@
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></ulink>
                 variable as follows:
                 <literallayout class='monospaced'>
-     FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+     FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}"
                 </literallayout>
                 The path <filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-THISDIR'><filename>THISDIR</filename></ulink><filename>}/${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PN'><filename>PN</filename></ulink><filename>}</filename>
                 expands to "linux-yocto" in the current directory for this

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

@@ -45,7 +45,7 @@
             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
+     $ 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,
@@ -208,7 +208,7 @@
             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
+            Since each machine or BSP has its own separate 
             <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
             in its own separate branch
             of the Git repository, you can easily switch between different builds.

documentation/kernel-dev/kernel-dev.xml

@@ -41,16 +41,6 @@
                 <date>October 2013</date>
                 <revremark>Released with the Yocto Project 1.5 Release.</revremark>
             </revision>
-            <revision>
-                <revnumber>1.5.1</revnumber>
-                <date>Sometime in 2013</date>
-                <revremark>Released with the Yocto Project 1.5.1 Release.</revremark>
-            </revision>
-            <revision>
-                <revnumber>1.6</revnumber>
-                <date>Sometime 2014</date>
-                <revremark>Released with the Yocto Project 1.6 Release.</revremark>
-            </revision>
         </revhistory>
 
     <copyright>
@@ -64,10 +54,11 @@
         the terms of the <ulink type="http" url="http://creativecommons.org/licenses/by-sa/2.0/uk/">Creative Commons Attribution-Share Alike 2.0 UK: England &amp; Wales</ulink> as published by Creative Commons.
       </para>
       <note>
-          For the latest version of this manual associated with this
-          Yocto Project release, see the
-          <ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;'>Yocto Project Linux Kernel Development Manual</ulink>
-          from the Yocto Project website.
+          Due to production processes, there could be differences between the Yocto Project
+          documentation bundled in the release tarball and the
+          <ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;'>Yocto Project Linux Kernel Development Manual</ulink> on
+          the <ulink url='&YOCTO_HOME_URL;'>Yocto Project</ulink> website.
+          For the latest version of this manual, see the manual on the website.
       </note>
     </legalnotice>
 

documentation/poky.ent

@@ -1,11 +1,11 @@
-<!ENTITY DISTRO "1.6">
-<!ENTITY DISTRO_COMPRESSED "16">
-<!ENTITY DISTRO_NAME "tbd">
-<!ENTITY YOCTO_DOC_VERSION "1.6">
-<!ENTITY POKYVERSION "11.0.0">
-<!ENTITY POKYVERSION_COMPRESSED "1100">
+<!ENTITY DISTRO "1.5">
+<!ENTITY DISTRO_COMPRESSED "15">
+<!ENTITY DISTRO_NAME "dora">
+<!ENTITY YOCTO_DOC_VERSION "1.5">
+<!ENTITY POKYVERSION "10.0.0">
+<!ENTITY POKYVERSION_COMPRESSED "1000">
 <!ENTITY YOCTO_POKY "poky-&DISTRO_NAME;-&POKYVERSION;">
-<!ENTITY COPYRIGHT_YEAR "2010-2014">
+<!ENTITY COPYRIGHT_YEAR "2010-2013">
 <!ENTITY YOCTO_DL_URL "http://downloads.yoctoproject.org">
 <!ENTITY YOCTO_HOME_URL "http://www.yoctoproject.org">
 <!ENTITY YOCTO_LISTS_URL "http://lists.yoctoproject.org">
@@ -54,7 +54,7 @@
 <!ENTITY YOCTO_POKY_TARBALL "&YOCTO_POKY;.tar.bz2">
 <!ENTITY OE_INIT_PATH "&YOCTO_POKY;/oe-init-build-env">
 <!ENTITY OE_INIT_FILE "oe-init-build-env">
-<!ENTITY UBUNTU_HOST_PACKAGES_ESSENTIAL "gawk wget git-core diffstat unzip texinfo gcc-multilib \
+<!ENTITY UBUNTU_HOST_PACKAGES_ESSENTIAL "gawk wget git-core diffstat unzip texinfo \
      build-essential chrpath">
 <!ENTITY FEDORA_HOST_PACKAGES_ESSENTIAL "gawk make wget tar bzip2 gzip python unzip perl patch \
      diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath \

documentation/profile-manual/profile-manual-intro.xml

@@ -78,7 +78,7 @@
         </para>
 
         <para>
-            If you've already built a stripped image, you can generate
+            If you've already build a stripped image, you can generate
             debug packages (xxx-dbg) which you can manually install as
             needed.
         </para>

documentation/profile-manual/profile-manual-usage.xml

@@ -22,7 +22,7 @@
     <para>
         Don't let the fact that it's part of the kernel fool you into thinking
         that it's only for tracing and profiling the kernel - you can indeed
-        use it to trace and profile just the kernel, but you can also use it
+        use it to trace and profile just the kernel , but you can also use it
         to profile specific applications separately (with or without kernel
         context), and you can also use it to trace and profile the kernel
         and all applications on the system simultaneously to gain a system-wide
@@ -30,10 +30,10 @@
     </para>
 
     <para>
-        In many ways, perf aims to be a superset of all the tracing and profiling
+        In many ways, it aims to be a superset of all the tracing and profiling
         tools available in Linux today, including all the other tools covered
         in this HOWTO. The past couple of years have seen perf subsume a lot
-        of the functionality of those other tools and, at the same time, those
+        of the functionality of those other tools, and at the same time those
         other tools have removed large portions of their previous functionality
         and replaced it with calls to the equivalent functionality now
         implemented by the perf subsystem. Extrapolation suggests that at
@@ -126,7 +126,7 @@
      wget <ulink url='http://downloads.yoctoproject.org/mirror/sources/linux-2.6.19.2.tar.bz2'>http://downloads.yoctoproject.org/mirror/sources/linux-2.6.19.2.tar.bz2</ulink>
                 </literallayout>
                 The quickest and easiest way to get some basic overall data about
-                what's going on for a particular workload is to profile it using
+                what's going on for a particular workload it to profile it using
                 'perf stat'. 'perf stat' basically profiles using a few default
                 counters and displays the summed counts at the end of the run:
                 <literallayout class='monospaced'>
@@ -201,7 +201,7 @@
                 As our first attempt at profiling this workload, we'll simply
                 run 'perf record', handing it the workload we want to profile
                 (everything after 'perf record' and any perf options we hand
-                it - here none - will be executed in a new shell). perf collects
+                it - here none - will be executedin a new shell). perf collects
                 samples until the process exits and records them in a file named
                 'perf.data' in the current working directory.
                 <literallayout class='monospaced'>
@@ -241,7 +241,7 @@
                 Notice also that the above report shows an entry for 'busybox',
                 which is the executable that implements 'wget' in Yocto, but that
                 instead of a useful function name in that entry, it displays
-                a not-so-friendly hex value instead. The steps below will show
+                an not-so-friendly hex value instead. The steps below will show
                 how to fix that problem.
             </para>
 
@@ -308,7 +308,7 @@
             </para>
 
             <para>
-                Notice also that here there's also a case where the hex value
+                Notice also that here there's also a case where the a hex value
                 is displayed in the callstack, here in the expanded
                 sys_clock_gettime() function. Later we'll see it resolve to a
                 userspace function call in busybox.
@@ -367,7 +367,7 @@
 
             <para>
                 To generate the debug info for the packages in the image, we can
-                add dbg-pkgs to EXTRA_IMAGE_FEATURES in local.conf. For example:
+                to add dbg-pkgs to EXTRA_IMAGE_FEATURES in local.conf. For example:
                 <literallayout class='monospaced'>
      EXTRA_IMAGE_FEATURES = "debug-tweaks tools-profile dbg-pkgs"
                 </literallayout>
@@ -462,7 +462,7 @@
                 The tracing and profiling infrastructure in Linux has become
                 unified in a way that allows us to use the same tool with a
                 completely different set of counters, not just the standard
-                hardware counters that traditional tools have had to restrict
+                hardware counters that traditionally tools have had to restrict
                 themselves to (of course the traditional tools can also make use
                 of the expanded possibilities now available to them, and in some
                 cases have, as mentioned previously).
@@ -828,7 +828,7 @@
             </para>
 
             <para>
-                Luckily, there is a general-purpose way to handle such needs,
+                Luckily, there is general-purpose way to handle such needs,
                 called 'programming languages'. Making programming languages
                 easily available to apply to such problems given the specific
                 format of data is called a 'programming language binding' for
@@ -925,9 +925,9 @@
                 </literallayout>
                 Each event handler function in the generated code is modified
                 to do this. For convenience, we define a common function called
-                inc_counts() that each handler calls; inc_counts() simply tallies
+                inc_counts() that each handler calls; inc_counts simply tallies
                 a count for each event using the 'counts' hash, which is a
-                specialized hash function that does Perl-like autovivification, a
+                specialized has function that does Perl-like autovivification, a
                 capability that's extremely useful for kinds of multi-level
                 aggregation commonly used in processing traces (see perf's
                 documentation on the Python language binding for details):
@@ -1377,7 +1377,7 @@
             the /tracing directory of the mounted debugfs filesystem
             (Yocto follows the standard convention and mounts it
             at /sys/kernel/debug). Here's a listing of all the files
-            found in /sys/kernel/debug/tracing on a Yocto system:
+            found in /sys/kernel/debug/tracing on a Yocto system.:
             <literallayout class='monospaced'>
      root@sugarbay:/sys/kernel/debug/tracing# ls
      README                      kprobe_events               trace
@@ -1634,7 +1634,7 @@
             Also notice that there are various annotations on the left
             hand side of the display. For example if the total time it
             took for a given function to execute is above a certain
-            threshold, an exclamation point or plus sign appears on the
+            threshold, and exclamation point or plus sign appears on the
             left hand side. Please see the ftrace documentation for
             details on all these fields.
         </para>
@@ -1842,7 +1842,7 @@
             </literallayout>
             You can enable any number of events or complete subsystems
             (by using the 'enable' file in the subsystem directory) and
-            get an arbitrarily fine-grained idea of what's going on in the
+            get am arbitrarily fine-grained idea of what's going on in the
             system by enabling as many of the appropriate tracepoints
             as applicable.
         </para>
@@ -1878,14 +1878,14 @@
             in /sys/kernel/debug/tracing, allowing users to specify
             specific particular events within the
             /sys/kernel/debug/tracing/events/ subdirectory and to collect
-            traces and avoid having to deal with those details directly.
+            traces and avoiding having to deal with those details directly.
         </para>
 
         <para>
             As yet another layer on top of that, kernelshark provides a GUI
             that allows users to start and stop traces and specify sets
             of events using an intuitive interface, and view the
-            output as both trace events and as a per-CPU graphical
+            output as both trace events and as a per-cpu graphical
             display. It directly uses 'trace-cmd' as the plumbing
             that accomplishes all that underneath the covers (and
             actually displays the trace-cmd command it uses, as we'll see).
@@ -1896,13 +1896,13 @@
             <literallayout class='monospaced'>
      root@sugarbay:~# kernelshark
             </literallayout>
-            Then bring up the 'Capture' dialog by choosing from the
+            The bring up the 'Capture' dialog by choosing from the
             kernelshark menu:
             <literallayout class='monospaced'>
      Capture | Record
             </literallayout>
             That will display the following dialog, which allows you to
-            choose one or more events (or even one or more complete
+            choose on or more events (or even one or more complete
             subsystems) to trace:
         </para>
 
@@ -1911,7 +1911,7 @@
         </para>
 
         <para>
-            Note that these are exactly the same sets of events described
+            Note that these are exactly the same set of events described
             in the previous trace events subsystem section, and in fact
             is where trace-cmd gets them for kernelshark.
         </para>
@@ -1980,15 +1980,13 @@
             <literallayout class='monospaced'>
      Documentation/trace/events.txt
             </literallayout>
-            There is a nice series of articles on using
+            There are a nice series of articles on using
             ftrace and trace-cmd at LWN:
             <itemizedlist>
                 <listitem><para><ulink url='http://lwn.net/Articles/365835/'>Debugging the kernel using Ftrace - part 1</ulink>
                     </para></listitem>
                 <listitem><para><ulink url='http://lwn.net/Articles/366796/'>Debugging the kernel using Ftrace - part 2</ulink>
                     </para></listitem>
-                <listitem><para><ulink url='http://lwn.net/Articles/370423/'>Secrets of the Ftrace function tracer</ulink>
-                    </para></listitem>
                 <listitem><para><ulink url='https://lwn.net/Articles/410200/'>trace-cmd: A front-end for Ftrace</ulink>
                     </para></listitem>
             </itemizedlist>
@@ -2024,7 +2022,7 @@
         <ulink url='http://sourceware.org/systemtap/tutorial/'>SystemTap tutorial</ulink>
         simply prints a line every time any process on the system open()s
         a file. For each line, it prints the executable name of the
-        program that opened the file, along with its PID, and the name
+        program that opened the file, along with its pid, and the name
         of the file it opened (or tried to open), which it extracts
         from the open syscall's argstr.
         <literallayout class='monospaced'>
@@ -2098,15 +2096,6 @@
             booted. The 'crosstap' script provides details on how
             to do this if you run the script on the host without having
             done a build:
-            <note>
-                SystemTap, which uses 'crosstap', assumes you can establish an
-                ssh connection to the remote target.
-                Please refer to the crosstap wiki page for details on verifying
-                ssh connections at
-                <ulink url='https://wiki.yoctoproject.org/wiki/Tracing_and_Profiling#systemtap'></ulink>.
-                Also, the ability to ssh into the target system is not enabled
-                by default in *-minimal images.
-            </note>
             <literallayout class='monospaced'>
      $ crosstap root@192.168.1.88 trace_open.stp
 
@@ -2133,6 +2122,9 @@
             the EXTRA_IMAGE_FEATURES variable ]
           $ bitbake core-image-sato
 
+      [ NOTE that 'crosstap' needs to be able to ssh into the target
+        system, which isn't enabled by default in -minimal images. ]
+
      Once you've build the image on the host system, you're ready to
      boot it (or the equivalent pre-built image) and use 'crosstap'
      to probe it (you need to source the environment as usual first):
@@ -2203,7 +2195,7 @@
         <para>
             If everything worked as planned, you should see something
             like this (enter the password when prompted, or press enter
-            if it's set up to use no password):
+            if its set up to use no password):
             <literallayout class='monospaced'>
      $ crosstap root@192.168.7.2 trace_open.stp
      root@192.168.7.2's password:
@@ -2248,7 +2240,7 @@
         </para>
 
         <para>
-            For the section that deals with running oprofile from the command-line,
+            For the the section that deals with oprofile from the command-line,
             we assume you've ssh'ed to the host and will be running
             oprofile on the target.
         </para>
@@ -2268,7 +2260,7 @@
             Oprofile as configured in Yocto is a system-wide profiler
             (i.e. the version in Yocto doesn't yet make use of the
             perf_events interface which would allow it to profile
-            specific processes and workloads). It relies on hardware
+            specific processes and workloads). It's relies on hardware
             counter support in the hardware (but can fall back to a
             timer-based mode), which means that it doesn't take
             advantage of tracepoints or other event sources for example.
@@ -2289,8 +2281,8 @@
         <para>
             The oprofile daemon should already be running, but before
             you start profiling, you may need to change some settings
-            and some of these settings may require the daemon to not
-            be running. One of these settings is the path to the
+            and some of these settings may require the daemon not
+            be running. One of these settings is the path the the
             vmlinux file, which you'll want to set using the --vmlinux
             option if you want the kernel profiled:
             <literallayout class='monospaced'>
@@ -2321,7 +2313,7 @@
      Using log file /var/lib/oprofile/samples/oprofiled.log
      Daemon started.
             </literallayout>
-            If we check the status again we now see our updated settings:
+            If we get the status again we now see our updated settings:
             <literallayout class='monospaced'>
      root@crownbay:~# opcontrol --status
      Daemon paused: pid 1649
@@ -2330,7 +2322,7 @@
      Image filter: none
      Call-graph depth: 6
             </literallayout>
-            We're now in a position to run a profile. For that we use
+            We're now in a position to run a profile. For that we used
             'opcontrol --start':
             <literallayout class='monospaced'>
      root@crownbay:~# opcontrol --start
@@ -2342,10 +2334,10 @@
      Connecting to downloads.yoctoproject.org (140.211.169.59:80)
      linux-2.6.19.2.tar.b 100% |*******************************| 41727k  0:00:00 ETA
             </literallayout>
-            To stop the profile we use 'opcontrol --shutdown', which not
+            To stop the profile we use 'opcontrol --shudown', which not
             only stops the profile but shuts down the daemon as well:
             <literallayout class='monospaced'>
-     root@crownbay:~# opcontrol --shutdown
+     root@crownbay:~# opcontrol --start
      Stopping profiling.
      Killing daemon.
             </literallayout>
@@ -2904,7 +2896,7 @@
 
         <para>
             Once you've applied the above commits and built and booted your
-            image (you need to build the core-image-sato-sdk image or use one of the
+            image (you need to build the core-image-sato-sdk image or the
             other methods described in the General Setup section), you're
             ready to start tracing.
         </para>
@@ -2913,7 +2905,7 @@
             <title>Collecting and viewing a trace on the target (inside a shell)</title>
 
             <para>
-                First, from the host, ssh to the target:
+                First, from the target, ssh to the target:
                 <literallayout class='monospaced'>
      $ ssh -l root 192.168.1.47
      The authenticity of host '192.168.1.47 (192.168.1.47)' can't be established.
@@ -3014,7 +3006,7 @@
             <title>Collecting and viewing a userspace trace on the target (inside a shell)</title>
 
             <para>
-                For LTTng userspace tracing, you need to have a properly
+                For lttng userspace tracing, you need to have a properly
                 instrumented userspace program. For this example, we'll use
                 the 'hello' test program generated by the lttng-ust build.
             </para>
@@ -3036,7 +3028,7 @@
             </para>
 
             <para>
-                First, from the host, ssh to the target:
+                First, from the target, ssh to the target:
                 <literallayout class='monospaced'>
      $ ssh -l root 192.168.1.47
      The authenticity of host '192.168.1.47 (192.168.1.47)' can't be established.
@@ -3602,7 +3594,7 @@
                 It's also possible to trace block I/O using only
                 <link linkend='the-trace-events-subsystem'>trace events subsystem</link>,
                 which can be useful for casual tracing
-                if you don't want to bother dealing with the userspace tools.
+                if you don't want bother dealing with the userspace tools.
             </para>
 
             <para>

documentation/profile-manual/profile-manual.xml

@@ -41,16 +41,6 @@
                 <date>October 2013</date>
                 <revremark>Released with the Yocto Project 1.5 Release.</revremark>
             </revision>
-            <revision>
-                <revnumber>1.5.1</revnumber>
-                <date>Sometime in 2013</date>
-                <revremark>Released with the Yocto Project 1.5.1 Release.</revremark>
-            </revision>
-            <revision>
-                <revnumber>1.6</revnumber>
-                <date>Sometime 2014</date>
-                <revremark>Released with the Yocto Project 1.6 Release.</revremark>
-            </revision>
         </revhistory>
 
     <copyright>
@@ -67,10 +57,11 @@
       </para>
 
       <note>
-          For the latest version of this manual associated with this
-          Yocto Project release, see the
-          <ulink url='&YOCTO_DOCS_PROF_URL;'>Yocto Project Profiling and Tracing Manual</ulink>
-          from the Yocto Project website.
+          Due to production processes, there could be differences between the Yocto Project
+          documentation bundled in the release tarball and the
+          <ulink url='&YOCTO_DOCS_PROF_URL;'>Yocto Project Tracing and Profiling Manual</ulink> on
+          the <ulink url='&YOCTO_HOME_URL;'>Yocto Project</ulink> website.
+          For the latest version of this manual, see the manual on the website.
       </note>
     </legalnotice>
 

documentation/ref-manual/closer-look.xml

@@ -267,7 +267,7 @@
 
         <para>
             The previous section described the user configurations that
-            define BitBake's global behavior.
+            define the BitBake's global behavior.
             This section takes a closer look at the layers the build system
             uses to further control the build.
             These layers provide Metadata for the software, machine, and
@@ -363,7 +363,7 @@
                 for what you typically find in the distribution layer:
                 <itemizedlist>
                     <listitem><para><emphasis>classes:</emphasis>
-                        Class files (<filename>.bbclass</filename>) hold
+                        Class files (<filename>.bbclass</filename>) holds
                         common functionality that can be shared among
                         recipes in the distribution.
                         When your recipes inherit a class, they take on the
@@ -381,7 +381,7 @@
                     <listitem><para><emphasis>recipes-*:</emphasis>
                         Recipes and append files that affect common
                         functionality across the distribution.
-                        This area could include recipes and append files
+                        This area could include recipes and append files to
                         to add distribution-specific configuration,
                         initialization scripts, custom image recipes,
                         and so forth.</para></listitem>
@@ -421,7 +421,7 @@
                 Metadata can exist for multiple formfactors, graphics
                 support systems, and so forth.
                 <note>
-                    While the figure shows several <filename>recipes-*</filename>
+                    While the figure shows several <filename>recipe-*</filename>
                     directories, not all these directories appear in all
                     BSP layers.
                 </note>
@@ -487,7 +487,7 @@
 
         <para>
             Another area that plays a significant role in where source files
-            come from is pointed to by the
+            comes from is pointed to by the
             <link linkend='var-DL_DIR'><filename>DL_DIR</filename></link>
             variable.
             This area is a cache that can hold previously downloaded source.
@@ -546,7 +546,7 @@
                 The canonical method through which to include a local project
                 is to use the
                 <link linkend='ref-classes-externalsrc'><filename>externalsrc.bbclass</filename></link>
-                class to include that local project.
+                class to include local project.
                 You use either the <filename>local.conf</filename> or a
                 recipe's append file to override or set the
                 recipe to point to the local directory on your disk to pull
@@ -693,7 +693,7 @@
             <para>
                 The <filename>do_fetch</filename> and
                 <filename>do_unpack</filename> tasks fetch the source files
-                and unpack them into the work directory.
+                and unpack them into a working directory.
                 By default, everything is accomplished in the
                 <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>,
                 which has a defined structure.
@@ -704,11 +704,11 @@
             </para>
 
             <para>
-                Unpacked source files are pointed to by the
+                Unpacked source source files are pointed to by the
                 <link linkend='var-S'><filename>S</filename></link> variable.
                 Each recipe has an area in the Build Directory where the
                 unpacked source code resides.
-                The name of that directory for any given recipe is defined from
+                The name of directory for any given recipe is defined from
                 several different variables.
                 You can see the variables that define these directories
                 by looking at the figure:
@@ -809,7 +809,7 @@
                         variable.
                         For information on how this variable works within
                         that class, see the
-                        <filename>meta/classes/autotools.bbclass</filename> file.
+                        <filename>meta/classes/autotools.bbclass</filename>.
                         </para></listitem>
                     <listitem><para><emphasis><filename>do_compile</filename>:</emphasis>
                         Once a configuration task has been satisfied, BitBake
@@ -818,8 +818,8 @@
                         Compilation occurs in the directory pointed to by the
                         <link linkend='var-B'><filename>B</filename></link>
                         variable.
-                        Realize that the <filename>B</filename> directory is, by
-                        default, the same as the
+                        Realize that the <filename>B</filename> directory, by
+                        default, is the same as the
                         <link linkend='var-S'><filename>S</filename></link>
                         directory.</para></listitem>
                     <listitem><para><emphasis><filename>do_install</filename>:</emphasis>
@@ -948,7 +948,7 @@
 
             <para>
                 During image generation, the build system attempts to run
-                all post-installation scripts.
+                all post installation scripts.
                 Any that fail to run on the build host are run on the
                 target when the target system is first booted.
                 If you are using a
@@ -1052,7 +1052,7 @@
         <para>
             The images produced by the OpenEmbedded build system
             are compressed forms of the
-            root filesystem that are ready to boot on a target device.
+            root filesystems that are ready to boot on a target device.
             You can see from the
             <link linkend='general-yocto-environment-figure'>general Yocto Project Development Environment figure</link>
             that BitBake output in part consists of images.
@@ -1062,14 +1062,14 @@
 
         <para>
             For a list of example images that the Yocto Project provides,
-            see the
+            the
             "<link linkend='ref-images'>Images</link>" chapter.
         </para>
 
         <para>
             Images are written out to the
             <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
-            inside the <filename>tmp/deploy/images/&lt;machine&gt;/</filename>
+            inside the <filename>deploy/images/&lt;machine&gt;/</filename>
             folder as shown in the figure.
             This folder contains any files expected to be loaded on the
             target device.

documentation/ref-manual/faq.xml

@@ -31,19 +31,31 @@
     <qandaentry>
         <question>
             <para>
-                My development system does not have Python 2.7.3 or greater,
-                which the Yocto Project requires.
+                I only have Python 2.4 or 2.5 but BitBake requires Python 2.6 or 2.7.
                 Can I still use the Yocto Project?
             </para>
         </question>
         <answer>
             <para>
-                You can get the required tools on your host development
-                system a couple different ways (i.e. building a tarball or
-                downloading a tarball).
-                See the
-                "<link linkend='required-git-tar-and-python-versions'>Required Git, tar, and Python Versions</link>"
-                section for steps on how to update your build tools.
+                You can use a stand-alone tarball to provide Python 2.6.
+                You can find pre-built 32 and 64-bit versions of Python 2.6 at the following locations:
+                <itemizedlist>
+                    <listitem><para><ulink url='&YOCTO_PYTHON-i686_DL_URL;'>32-bit tarball</ulink></para></listitem>
+                    <listitem><para><ulink url='&YOCTO_PYTHON-x86_64_DL_URL;'>64-bit tarball</ulink></para></listitem>
+                </itemizedlist>
+            </para>
+            <para>
+                These tarballs are self-contained with all required libraries and should work
+                on most Linux systems.
+                To use the tarballs extract them into the root
+                directory and run the appropriate command:
+                <literallayout class='monospaced'>
+     $ export PATH=/opt/poky/sysroots/i586-pokysdk-linux/usr/bin/:$PATH
+     $ export PATH=/opt/poky/sysroots/x86_64-pokysdk-linux/usr/bin/:$PATH
+                </literallayout>
+            </para>
+            <para>
+                Once you run the command, BitBake uses Python 2.6.
             </para>
         </answer>
     </qandaentry>
@@ -199,7 +211,7 @@
         </answer>
     </qandaentry>
 
-<!--    <qandaentry>
+    <qandaentry>
         <question>
             <para>
                 How do I make the Yocto Project work in RHEL/CentOS?
@@ -246,7 +258,7 @@
                 Wiki page.</para>
             </note>
         </answer>
-    </qandaentry> -->
+    </qandaentry>
 
     <qandaentry>
         <question>
@@ -670,7 +682,7 @@
             <para>
                 Yes - you can easily do this.
                 When you use BitBake to build an image, all the build output
-                goes into the directory created when you run the
+                goes into the directory created when you run the 
                 build environment setup script (i.e.
                 <link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>
                 or

documentation/ref-manual/introduction.xml

@@ -121,6 +121,11 @@
                 </para>
 
                 <para>
+                    Refer to
+                    <ulink url='&OE_HOME_URL;/index.php?title=OEandYourDistro'>OE and Your Distro</ulink> and
+                    <ulink url='&OE_HOME_URL;/index.php?title=Required_software'>Required Software</ulink>
+                    for information for information about dependencies and
+                    requirements.
                     If you encounter problems, please go to
                     <ulink url='&YOCTO_BUGZILLA_URL;'>Yocto Project Bugzilla</ulink>
                     and submit a bug.
@@ -246,11 +251,11 @@
         </section>
 
         <section id='opensuse-packages'>
-            <title>openSUSE Packages</title>
+            <title>OpenSUSE Packages</title>
 
             <para>
                 The following list shows the required packages by function
-                given a supported openSUSE Linux distribution:
+                given a supported OpenSUSE Linux distribution:
                 <itemizedlist>
                     <listitem><para><emphasis>Essentials:</emphasis>
                         Packages needed to build an image for a headless
@@ -341,8 +346,8 @@
             you can resolve this by either downloading a pre-built tarball
             containing these tools, or building such a tarball on another
             system.
-            Regardless of the method, once you have the tarball, you simply
-            install it somewhere on your system, such as a directory in your
+            Regardless of the method, once you have the tarball you simply
+            install it somewhere on you system, such as a directory in your
             home directory, and then source the environment script provided,
             which adds the tools into <filename>PATH</filename> and sets
             any other environment variables required to run the tools.
@@ -353,7 +358,7 @@
         <para>
             If downloading a pre-built tarball, locate the
             <filename>*.sh</filename> at
-            <ulink url='&YOCTO_DL_URL;/releases/yocto/yocto-&DISTRO;/buildtools/'></ulink>.
+            <ulink url='&YOCTO_DL_URL;/releases/yocto/yocto-1.5/buildtools/'></ulink>.
         </para>
 
         <para>
@@ -366,7 +371,7 @@
                 variable determines whether you build tools for a 32-bit
                 or 64-bit system.
             </note>
-            Once the build completes, you can find the file that installs
+            Once the build completes, you can find the file that installs the
             the tools in the <filename>tmp/deploy/sdk</filename> subdirectory
             of the
             <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
@@ -404,32 +409,16 @@
         The Yocto Project development team makes the Yocto Project available through a number
         of methods:
         <itemizedlist>
-            <listitem><para><emphasis>Source Repositories:</emphasis>
-                Working from a copy of the upstream
-                <filename>poky</filename> repository is the
-                preferred method for obtaining and using a Yocto Project
-                release.
-                You can view the Yocto Project Source Repositories at
-                <ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink>.
-                In particular, you can find the
-                <filename>poky</filename> repository at
-                <ulink url='http://git.yoctoproject.org/cgit/cgit.cgi/poky/'></ulink>.
-                </para></listitem>
-            <listitem><para><emphasis>Releases:</emphasis> Stable, tested
-                releases are available as tarballs through
+            <listitem><para><emphasis>Releases:</emphasis> Stable, tested releases are available through
                 <ulink url='&YOCTO_DL_URL;/releases/yocto/'/>.</para></listitem>
-            <listitem><para><emphasis>Nightly Builds:</emphasis> These
-                tarball releases are available at
+            <listitem><para><emphasis>Nightly Builds:</emphasis> These releases are available at
                 <ulink url='http://autobuilder.yoctoproject.org/nightly'/>.
-                These builds include Yocto Project releases, meta-toolchain
-                tarball installation scripts, and experimental builds.
-                </para></listitem>
-            <listitem><para><emphasis>Yocto Project Website:</emphasis> You can
-                find tarball releases of the Yocto Project and supported BSPs
-                at the
+                These builds include Yocto Project releases, meta-toolchain tarball installation scripts, and
+                experimental builds.</para></listitem>
+            <listitem><para><emphasis>Yocto Project Website:</emphasis> You can find releases
+                of the Yocto Project and supported BSPs at the
                 <ulink url='&YOCTO_HOME_URL;'>Yocto Project website</ulink>.
-                Along with these downloads, you can find lots of other
-                information at this site.
+                Along with these downloads, you can find lots of other information at this site.
                 </para></listitem>
         </itemizedlist>
     </para>
@@ -440,9 +429,10 @@
     <para>
         Development using the Yocto Project requires a local
         <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
-        You can set up the Source Directory by cloning a copy of the upstream
-        <ulink url='&YOCTO_DOCS_DEV_URL;#poky'>poky</ulink> Git repository.
-        For information on how to do this, see the
+        You can set up the Source Directory by downloading a Yocto Project release tarball and unpacking it,
+        or by cloning a copy of the upstream
+        <ulink url='&YOCTO_DOCS_DEV_URL;#poky'>Poky</ulink> Git repository.
+        For information on both these methods, see the
         "<ulink url='&YOCTO_DOCS_DEV_URL;#getting-setup'>Getting Set Up</ulink>"
         section in the Yocto Project Development Manual.
     </para>

documentation/ref-manual/migration.xml

@@ -34,7 +34,7 @@
             <para>
                 The shared state cache (sstate-cache), as pointed to by
                 <link linkend='var-SSTATE_DIR'><filename>SSTATE_DIR</filename></link>, by default
-                now has two-character subdirectories to prevent issues arising
+                now has two-character subdirectories to prevent issues rising
                 from too many files in the same directory.
                 Also, native sstate-cache packages will go into a subdirectory named using
                 the distro ID string.
@@ -755,7 +755,7 @@
                     <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
                     rather than
                     <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link>.
-                    Doing so makes it easier to delete
+                    Doing so makes it a easier to delete
                     <filename>TMPDIR</filename> and preserve the build history.
                     Additionally, data for produced SDKs is now split by
                     <link linkend='var-IMAGE_NAME'><filename>IMAGE_NAME</filename></link>.
@@ -829,10 +829,10 @@
     </section>
 
     <section id='migration-1.5-run'>
-        <title><filename>run</filename></title>
+        <title><filename>/run</filename></title>
 
         <para>
-            The <filename>run</filename> directory from the Filesystem
+            The <filename>/run</filename> directory from the Filesystem
             Hierarchy Standard 3.0 has been introduced.
             You can find some of the implications for this change
             <ulink url='http://cgit.openembedded.org/openembedded-core/commit/?id=0e326280a15b0f2c4ef2ef4ec441f63f55b75873'>here</ulink>.
@@ -1033,7 +1033,7 @@
                     </para></listitem>
                 <listitem><para>
                     <filename>base-files</filename>: Remove the unnecessary
-                    <filename>media/xxx</filename> directories.
+                    <filename>/media/xxx</filename> directories.
                     </para></listitem>
                 <listitem><para>
                     <filename>alsa-state</filename>: Provide an empty

documentation/ref-manual/ref-bitbake.xml

@@ -222,7 +222,7 @@
         <para>
             As each task completes, a timestamp is written to the directory specified by the
             <filename><link linkend='var-STAMP'>STAMP</link></filename> variable.
-            On subsequent runs, BitBake looks within the <filename>build/tmp/stamps</filename>
+            On subsequent runs, BitBake looks within the <filename>/build/tmp/stamps</filename>
             directory and does not rerun
             tasks that are already completed unless a timestamp is found to be invalid.
             Currently, invalid timestamps are only considered on a per

documentation/ref-manual/ref-features.xml

@@ -3,7 +3,7 @@
 [<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
 <chapter id='ref-features'>
-    <title>Features</title>
+    <title>Reference: Features</title>
 
     <para>
         This chapter provides a reference of shipped machine and distro features
@@ -38,17 +38,17 @@
         Here is an example that discovers the recipes whose build is potentially
         changed based on a given feature:
         <literallayout class='monospaced'>
-     $ cd poky
+     $ cd $HOME/poky
      $ git grep 'contains.*MACHINE_FEATURES.*&lt;feature&gt;'
         </literallayout>
     </para>
 
-    <section id='ref-features-machine'>
-        <title>Machine Features</title>
+    <section id='ref-features-distro'>
+        <title>Distro</title>
 
         <para>
             The items below are features you can use with
-            <link linkend='var-MACHINE_FEATURES'><filename>MACHINE_FEATURES</filename></link>.
+            <link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link>.
             Features do not have a one-to-one correspondence to packages, and they can
             go beyond simply controlling the installation of a package or packages.
             Sometimes a feature can influence how certain recipes are built.
@@ -57,68 +57,6 @@
             recipe.
         </para>
 
-        <para>
-            This feature list only represents features as shipped with the Yocto Project metadata:
-            <itemizedlist>
-                <listitem><para><emphasis>acpi:</emphasis> Hardware has ACPI (x86/x86_64 only)
-                    </para></listitem>
-                <listitem><para><emphasis>alsa:</emphasis> Hardware has ALSA audio drivers
-                    </para></listitem>
-                <listitem><para><emphasis>apm:</emphasis> Hardware uses APM (or APM emulation)
-                    </para></listitem>
-                <listitem><para><emphasis>bluetooth:</emphasis> Hardware has integrated BT
-                    </para></listitem>
-                <listitem><para><emphasis>ext2:</emphasis> Hardware HDD or Microdrive
-                    </para></listitem>
-                <listitem><para><emphasis>irda:</emphasis> Hardware has IrDA support
-                    </para></listitem>
-                <listitem><para><emphasis>keyboard:</emphasis> Hardware has a keyboard
-                    </para></listitem>
-                <listitem><para><emphasis>pci:</emphasis> Hardware has a PCI bus
-                    </para></listitem>
-                <listitem><para><emphasis>pcmcia:</emphasis> Hardware has PCMCIA or CompactFlash sockets
-                    </para></listitem>
-                <listitem><para><emphasis>screen:</emphasis> Hardware has a screen
-                    </para></listitem>
-                <listitem><para><emphasis>serial:</emphasis> Hardware has serial support (usually RS232)
-                    </para></listitem>
-                <listitem><para><emphasis>touchscreen:</emphasis> Hardware has a touchscreen
-                    </para></listitem>
-                <listitem><para><emphasis>usbgadget:</emphasis> Hardware is USB gadget device capable
-                    </para></listitem>
-                <listitem><para><emphasis>usbhost:</emphasis> Hardware is USB Host capable
-                    </para></listitem>
-                <listitem><para><emphasis>wifi:</emphasis> Hardware has integrated WiFi
-                    </para></listitem>
-            </itemizedlist>
-        </para>
-    </section>
-
-    <section id='ref-features-distro'>
-        <title>Distro Features</title>
-
-        <para>
-            The items below are features you can use with
-            <link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link>
-            to enable features across your distribution.
-            Features do not have a one-to-one correspondence to packages,
-            and they can go beyond simply controlling the installation of a
-            package or packages.
-            In most cases, the presence or absence of a feature translates to
-            the appropriate option supplied to the configure script during
-            <filename>do_configure</filename> for the recipes that optionally
-            support the feature.
-        </para>
-
-        <para>
-            Some distro features are also machine features.
-            These select features make sense to be controlled both at
-            the machine and distribution configuration level.
-            See the
-            <ulink url='&YOCTO_DOCS_REF_URL;#var-COMBINED_FEATURES'><filename>COMBINED_FEATURES</filename></ulink>
-            variable for more information.
-        </para>
-
         <para>
             This list only represents features as shipped with the Yocto Project metadata:
             <itemizedlist>
@@ -137,7 +75,7 @@
                     support.</para></listitem>
                 <listitem><para><emphasis>ipv6:</emphasis> Include IPv6 support.
                     </para></listitem>
-                <listitem><para><emphasis>irda:</emphasis> Include IrDA support.
+                <listitem><para><emphasis>irda:</emphasis> Include Irda support.
                     </para></listitem>
                 <listitem><para><emphasis>keyboard:</emphasis> Include keyboard
                     support (e.g. keymaps will be loaded during boot).
@@ -177,18 +115,63 @@
                     supports it.</para></listitem>
                 <listitem><para><emphasis>wifi:</emphasis> Include WiFi support
                     (integrated only).</para></listitem>
-                <listitem><para><emphasis>sdk-pms:</emphasis> Include Package
-                    Management Tools in the
-                    <filename>nativesdk</filename> toolchain tarball.
-                    Including these tools allows for easy sandbox use when
-                    creating the root filesystem while using the SDK tarball.
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='ref-features-machine'>
+        <title>Machine</title>
+
+        <para>
+            The items below are features you can use with
+            <link linkend='var-MACHINE_FEATURES'><filename>MACHINE_FEATURES</filename></link>.
+            Features do not have a one-to-one correspondence to packages, and they can
+            go beyond simply controlling the installation of a package or packages.
+            Sometimes a feature can influence how certain recipes are built.
+            For example, a feature might determine whether a particular configure option
+            is specified within <filename>do_configure</filename> for a particular
+            recipe.
+        </para>
+
+        <para>
+            This feature list only represents features as shipped with the Yocto Project metadata:
+            <itemizedlist>
+                <listitem><para><emphasis>acpi:</emphasis> Hardware has ACPI (x86/x86_64 only)
+                    </para></listitem>
+                <listitem><para><emphasis>alsa:</emphasis> Hardware has ALSA audio drivers
+                    </para></listitem>
+                <listitem><para><emphasis>apm:</emphasis> Hardware uses APM (or APM emulation)
+                    </para></listitem>
+                <listitem><para><emphasis>bluetooth:</emphasis> Hardware has integrated BT
+                    </para></listitem>
+                <listitem><para><emphasis>ext2:</emphasis> Hardware HDD or Microdrive
+                    </para></listitem>
+                <listitem><para><emphasis>irda:</emphasis> Hardware has Irda support
+                    </para></listitem>
+                <listitem><para><emphasis>keyboard:</emphasis> Hardware has a keyboard
+                    </para></listitem>
+                <listitem><para><emphasis>pci:</emphasis> Hardware has a PCI bus
+                    </para></listitem>
+                <listitem><para><emphasis>pcmcia:</emphasis> Hardware has PCMCIA or CompactFlash sockets
+                    </para></listitem>
+                <listitem><para><emphasis>screen:</emphasis> Hardware has a screen
+                    </para></listitem>
+                <listitem><para><emphasis>serial:</emphasis> Hardware has serial support (usually RS232)
+                    </para></listitem>
+                <listitem><para><emphasis>touchscreen:</emphasis> Hardware has a touchscreen
+                    </para></listitem>
+                <listitem><para><emphasis>usbgadget:</emphasis> Hardware is USB gadget device capable
+                    </para></listitem>
+                <listitem><para><emphasis>usbhost:</emphasis> Hardware is USB Host capable
+                    </para></listitem>
+                <listitem><para><emphasis>wifi:</emphasis> Hardware has integrated WiFi
                     </para></listitem>
             </itemizedlist>
         </para>
     </section>
 
     <section id='ref-features-image'>
-        <title>Image Features</title>
+        <title>Images</title>
 
         <para>
             The contents of images generated by the OpenEmbedded build system can be controlled by the

documentation/ref-manual/ref-images.xml

@@ -90,18 +90,14 @@
         <listitem><para><emphasis><filename>core-image-clutter</filename>:</emphasis>
             An image with support for the Open GL-based toolkit Clutter, which enables development of
             rich and animated graphical user interfaces.</para></listitem>
-        <listitem><para><emphasis><filename>core-image-directfb</filename>:</emphasis>
-            An image that uses <filename>directfb</filename> instead of X11.
-            </para></listitem>
+        <listitem><para><emphasis><filename>core-image-gtk-directfb</filename>:</emphasis>
+            An image that uses <filename>gtk+</filename> over <filename>directfb</filename>
+            instead of X11.
+            In order to build, this image requires specific distro configuration that enables
+            <filename>gtk</filename> over <filename>directfb</filename>.</para></listitem>
         <listitem><para><emphasis><filename>core-image-x11</filename>:</emphasis>
             A very basic X11 image with a terminal.
             </para></listitem>
-        <listitem><para><emphasis><filename>core-image-weston</filename>:</emphasis>
-            An image that provides the Wayland protocol libraries and the
-            reference Weston compositor.
-            For more information, see the
-            "<link linkend='wayland'>Wayland</link>" section.
-            </para></listitem>
         <listitem><para><emphasis><filename>qt4e-demo-image</filename>:</emphasis>
             An image that launches into the demo application for the embedded
             (not based on X11) version of Qt.</para></listitem>

documentation/ref-manual/ref-manual.xml

@@ -72,16 +72,6 @@
                 <date>October 2013</date>
                 <revremark>Released with the Yocto Project 1.5 Release.</revremark>
             </revision>
-            <revision>
-                <revnumber>1.5.1</revnumber>
-                <date>Sometime in 2013</date>
-                <revremark>Released with the Yocto Project 1.5.1 Release.</revremark>
-            </revision>
-            <revision>
-                <revnumber>1.6</revnumber>
-                <date>Sometime 2014</date>
-                <revremark>Released with the Yocto Project 1.6 Release.</revremark>
-            </revision>
         </revhistory>
 
     <copyright>
@@ -95,10 +85,11 @@
         the terms of the <ulink type="http" url="http://creativecommons.org/licenses/by-sa/2.0/uk/">Creative Commons Attribution-Share Alike 2.0 UK: England &amp; Wales</ulink> as published by Creative Commons.
       </para>
       <note>
-          For the latest version of this manual associated with this
-          Yocto Project release, see the
-          <ulink url='&YOCTO_DOCS_REF_URL;'>Yocto Project Reference Manual</ulink>
-          from the Yocto Project website.
+          Due to production processes, there could be differences between the Yocto Project
+          documentation bundled in the release tarball and the
+          <ulink url='&YOCTO_DOCS_REF_URL;'>Yocto Project Reference Manual</ulink> on
+          the <ulink url='&YOCTO_HOME_URL;'>Yocto Project</ulink> website.
+          For the latest version of this manual, see the manual on the website.
       </note>
     </legalnotice>
 

documentation/ref-manual/ref-structure.xml

@@ -39,27 +39,23 @@
 
         <para>
             This directory includes a copy of BitBake for ease of use.
-            The copy usually matches the current stable BitBake release from
-            the BitBake project.
+            The copy usually matches the current stable BitBake release from the BitBake project.
             BitBake, a
             <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
-            interpreter, reads the Yocto Project Metadata and runs the tasks
+            interpreter, reads the Yocto Project metadata and runs the tasks
             defined by that data.
-            Failures are usually from the Metadata and not from BitBake itself.
+            Failures are usually from the metadata and not from BitBake itself.
             Consequently, most users do not need to worry about BitBake.
         </para>
 
         <para>
-            When you run the <filename>bitbake</filename> command, the
-            main BitBake executable, which resides in the
-            <filename>bitbake/bin/</filename> directory, starts.
-            Sourcing an environment setup script (e.g.
-            <link linkend="structure-core-script"><filename>&OE_INIT_FILE;</filename></link>
-            or
-            <link linkend="structure-memres-core-script"><filename>oe-init-build-env-memres</filename></link>)
-            places the <filename>scripts</filename> and
-            <filename>bitbake/bin</filename> directories (in that order) into
-            the shell's <filename>PATH</filename> environment variable.
+            When you run the <filename>bitbake</filename> command, the wrapper script in
+            <filename>scripts/</filename> is executed to run the main BitBake executable,
+            which resides in the <filename>bitbake/bin/</filename> directory.
+            Sourcing the <link linkend="structure-core-script"><filename>&OE_INIT_FILE;</filename></link>
+            script places the <filename>scripts</filename> and <filename>bitbake/bin</filename>
+            directories (in that order) into the shell's <filename>PATH</filename> environment
+            variable.
         </para>
 
         <para>
@@ -78,7 +74,7 @@
             the source tree is combined with the output.
             The <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
             is created initially when you <filename>source</filename>
-            the OpenEmbedded build environment setup script
+            the OpenEmbedded build environment setup script 
             (i.e.
             <link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>
             or
@@ -101,7 +97,7 @@
     </section>
 
     <section id='handbook'>
-        <title><filename>documentation/</filename></title>
+        <title><filename>documentation</filename></title>
 
         <para>
             This directory holds the source for the Yocto Project documentation
@@ -109,7 +105,7 @@
             versions of the manuals.
             Each manual is contained in a sub-folder.
             For example, the files for this manual reside in
-            the <filename>ref-manual/</filename> directory.
+            <filename>ref-manual</filename>.
         </para>
     </section>
 
@@ -179,9 +175,9 @@
         </para>
 
         <para>
-            The <filename>scripts</filename> directory has useful scripts that assist in contributing
-            back to the Yocto Project, such as <filename>create-pull-request</filename> and
-            <filename>send-pull-request</filename>.
+            The <filename>scripts</filename> directory has useful scripts that assist contributing
+            back to the Yocto Project, such as <filename>create_pull_request</filename> and
+            <filename>send_pull_request</filename>.
         </para>
     </section>
 
@@ -189,9 +185,9 @@
         <title><filename>&OE_INIT_FILE;</filename></title>
 
         <para>
-            This script is one of two scripts that set up the OpenEmbedded build
+            This script is one of two scripts that set up the OpenEmbedded build 
             environment.
-            For information on the other script, see the
+            For information on the other script, see the 
             "<link linkend='structure-memres-core-script'><filename>oe-init-build-env-memres</filename></link>"
             section.
         </para>
@@ -200,7 +196,7 @@
             Running this script with the <filename>source</filename> command in
             a shell makes changes to <filename>PATH</filename> and sets other
             core BitBake variables based on the current working directory.
-            You need to run an environment setup script before running BitBake
+            You need to run an environment setup script before running BitBake 
             commands.
             The script uses other scripts within the
             <filename>scripts</filename> directory to do the bulk of the work.
@@ -209,8 +205,7 @@
         <para>
             By default, running this script without a
             <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
-            argument creates the <filename>build</filename> directory
-            in your current working directory.
+            argument creates the <filename>build</filename> directory.
             If you provide a Build Directory argument when you
             <filename>source</filename> the script, you direct the OpenEmbedded
             build system to create a Build Directory of your choice.
@@ -236,11 +231,11 @@
         <title><filename>oe-init-build-env-memres</filename></title>
 
         <para>
-            This script is one of two scripts that set up the OpenEmbedded
-            build environment.
-            Aside from setting up the environment, this script starts a
-            memory-resident BitBake server.
-            For information on the other setup script, see the
+            This script is one of two scripts that set up the OpenEmbedded build 
+            environment.
+            Setting up the environment with this script uses a 
+            memory-resident BitBake.
+            For information on the other setup script, see the 
             "<link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>"
             section.
         </para>
@@ -257,14 +252,14 @@
             Running this script with the <filename>source</filename> command in
             a shell makes changes to <filename>PATH</filename> and sets other
             core BitBake variables based on the current working directory.
-            One of these variables is the
+            One of these variables is the 
             <link linkend='var-BBSERVER'><filename>BBSERVER</filename></link>
-            variable, which allows the OpenEmbedded build system to locate
+            variable, which allows the OpenEmbedded build system to locate 
             the server that is running BitBake.
         </para>
 
         <para>
-            You need to run an environment setup script before using BitBake
+            You need to run an environment setup script before running BitBake 
             commands.
             Following is the script syntax:
             <literallayout class='monospaced'>
@@ -275,34 +270,33 @@
         </para>
 
         <para>
-            If you do not provide a port number with the script, the
-            BitBake server at port "12345" is started.
+            If you do not provide a port number with the script, the default
+            port "12345" is used.
         </para>
 
         <para>
             By default, running this script without a
             <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
-            argument creates a build directory named
-            <filename>build</filename>.
+            argument creates the <filename>build</filename> directory.
             If you provide a Build Directory argument when you
-            <filename>source</filename> the script, the Build Directory is
-            created using that name.
-            For example, the following command starts the BitBake server using
-            the default port "12345" and creates a Build Directory named
+            <filename>source</filename> the script, you direct the OpenEmbedded
+            build system to create a Build Directory of your choice.
+            For example, the following command uses the default port number
+            "12345" and creates a Build Directory named
             <filename>mybuilds</filename> that is outside of the
             <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>:
             <literallayout class='monospaced'>
      $ source oe-init-build-env-memres ~/mybuilds
             </literallayout>
             <note>
-                The OpenEmbedded build system does not support file or
+                The OpenEmbedded build system does not support file or 
                 directory names that contain spaces.
-                If you attempt to run the
+                If you attempt to run the 
                 <filename>oe-init-build-env-memres</filename> script
-                from a Source Directory that contains spaces in either the
-                filenames or directory names, the script returns an error
+                from a Source Directory that contains spaces in either the 
+                filenames or directory names, the script returns an error 
                 indicating no such file or directory.
-                Be sure to use a Source Directory free of names containing
+                Be sure to use a Source Directory free of names containing 
                 spaces.
             </note>
         </para>
@@ -327,72 +321,81 @@
         By default, this directory is named <filename>build</filename>.
     </para>
 
+    <section id='structure-build-pseudodone'>
+        <title><filename>build/pseudodone</filename></title>
+
+        <para>
+            This tag file indicates that the initial pseudo binary was created.
+            The file is built the first time BitBake is invoked.
+        </para>
+    </section>
+
     <section id='structure-build-conf-local.conf'>
         <title><filename>build/conf/local.conf</filename></title>
 
         <para>
-            This configuration file contains all the local user configurations
+            This configuration file contains all the local user configurations 
             for your build environment.
-            The <filename>local.conf</filename> file contains documentation on
+            The <filename>local.conf</filename> file contains documentation on 
             the various configuration options.
-            Any variable set here overrides any variable set elsewhere within
-            the environment unless that variable is hard-coded within a file
+            Any variable set here overrides any variable set elsewhere within 
+            the environment unless that variable is hard-coded within a file 
             (e.g. by using '=' instead of '?=').
-            Some variables are hard-coded for various reasons but these
+            Some variables are hard-coded for various reasons but these 
             variables are relatively rare.
         </para>
 
         <para>
-            Edit this file to set the
+            Edit this file to set the 
             <filename><link linkend='var-MACHINE'>MACHINE</link></filename>
             for which you want to build, which package types you wish to use
             (<link linkend='var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></link>),
-            the location from which you want to access downloaded files
+            the location from which you want to downloaded files
             (<filename><link linkend='var-DL_DIR'>DL_DIR</link></filename>),
             and how you want your host machine to use resources
-            (<link linkend='var-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename></link>
+            (<link linkend='var-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename></link> 
             and
             <link linkend='var-PARALLEL_MAKE'><filename>PARALLEL_MAKE</filename></link>).
         </para>
 
         <para>
-            If <filename>local.conf</filename> is not present when you
-            start the build, the OpenEmbedded build system creates it from
+            If <filename>local.conf</filename> is not present when you 
+            start the build, the OpenEmbedded build system creates it from 
             <filename>local.conf.sample</filename> when
-            you <filename>source</filename> the top-level build environment
+            you <filename>source</filename> the top-level build environment 
             setup script (i.e.
             <link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>
-            or
+            or 
             <link linkend='structure-memres-core-script'><filename>oe-init-build-env-memres</filename></link>).
         </para>
 
         <para>
-            The source <filename>local.conf.sample</filename> file used
+            The source <filename>local.conf.sample</filename> file used 
             depends on the <filename>$TEMPLATECONF</filename> script variable,
-            which defaults to <filename>meta-yocto/conf</filename>
-            when you are building from the Yocto Project development
-            environment and defaults to <filename>meta/conf</filename> when
+            which defaults to <filename>/meta-yocto/conf</filename>
+            when you are building from the Yocto Project development 
+            environment and defaults to <filename>/meta/conf</filename> when 
             you are building from the OpenEmbedded Core environment.
-            Because the script variable points to the source of the
-            <filename>local.conf.sample</filename> file, this implies that
-            you can configure your build environment from any layer by setting
-            the variable in the top-level build environment setup script as
+            Because the script variable points to the source of the 
+            <filename>local.conf.sample</filename> file, this implies that 
+            you can configure your build environment from any layer by setting     
+            the variable in the top-level build environment setup script as 
             follows:
             <literallayout class='monospaced'>
      TEMPLATECONF=&lt;your_layer&gt;/conf
             </literallayout>
-            Once the build process gets the sample file, it uses
-            <filename>sed</filename> to substitute final
-            <filename>${</filename><link linkend='var-OEROOT'><filename>OEROOT</filename></link><filename>}</filename>
+            Once the build process gets the sample file, it uses 
+            <filename>sed</filename> to substitute final 
+            <filename>${</filename><link linkend='var-OEROOT'><filename>OEROOT</filename></link><filename>}</filename> 
             values for all <filename>##OEROOT##</filename> values.
             <note>
                 You can see how the <filename>TEMPLATECONF</filename> variable
-                is used by looking at the
-                <filename>scripts/oe-setup-builddir</filename> script in the
+                is used by looking at the       
+                <filename>/scripts/oe-setup-builddir</filename> script in the 
                 <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
-                You can find the Yocto Project version of the
-                <filename>local.conf.sample</filename> file in the
-                <filename>meta-yocto/conf</filename> directory.
+                You can find the Yocto Project version of the 
+                <filename>local.conf.sample</filename> file in the 
+                <filename>/meta-yocto/conf</filename> directory.                
             </note>
         </para>
     </section>
@@ -405,48 +408,48 @@
             <ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>layers</ulink>,
             which are directory trees, traversed (or walked) by BitBake.
             The <filename>bblayers.conf</filename> file uses the
-            <link linkend='var-BBLAYERS'><filename>BBLAYERS</filename></link>
+            <link linkend='var-BBLAYERS'><filename>BBLAYERS</filename></link> 
             variable to list the layers BitBake tries to find, and uses the
             <link linkend='var-BBLAYERS_NON_REMOVABLE'><filename>BBLAYERS_NON_REMOVABLE</filename></link>
             variable to list layers that must not be removed.
         </para>
 
         <para>
-            If <filename>bblayers.conf</filename> is not present when you
-            start the build, the OpenEmbedded build system creates it from
+            If <filename>bblayers.conf</filename> is not present when you 
+            start the build, the OpenEmbedded build system creates it from 
             <filename>bblayers.conf.sample</filename> when
-            you <filename>source</filename> the top-level build environment
+            you <filename>source</filename> the top-level build environment 
             setup script (i.e.
             <link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>
-            or
+            or 
             <link linkend='structure-memres-core-script'><filename>oe-init-build-env-memres</filename></link>).
         </para>
 
         <para>
-            The source <filename>bblayers.conf.sample</filename> file used
+            The source <filename>bblayers.conf.sample</filename> file used 
             depends on the <filename>$TEMPLATECONF</filename> script variable,
-            which defaults to <filename>meta-yocto/conf</filename>
-            when you are building from the Yocto Project development
-            environment and defaults to <filename>meta/conf</filename> when
+            which defaults to <filename>/meta-yocto/conf</filename>
+            when you are building from the Yocto Project development 
+            environment and defaults to <filename>/meta/conf</filename> when 
             you are building from the OpenEmbedded Core environment.
-            Because the script variable points to the source of the
-            <filename>bblayers.conf.sample</filename> file, this implies that
+            Because the script variable points to the source of the 
+            <filename>bblayers.conf.sample</filename> file, this implies that 
             you can base your build from any layer by setting the variable in
             the top-level build environment setup script as follows:
             <literallayout class='monospaced'>
      TEMPLATECONF=&lt;your_layer&gt;/conf
             </literallayout>
-            Once the build process gets the sample file, it uses
-            <filename>sed</filename> to substitute final
-            <filename>${</filename><link linkend='var-OEROOT'><filename>OEROOT</filename></link><filename>}</filename>
+            Once the build process gets the sample file, it uses 
+            <filename>sed</filename> to substitute final 
+            <filename>${</filename><link linkend='var-OEROOT'><filename>OEROOT</filename></link><filename>}</filename> 
             values for all <filename>##OEROOT##</filename> values.
             <note>
                 You can see how the <filename>TEMPLATECONF</filename> variable
-                <filename>scripts/oe-setup-builddir</filename> script in the
+                <filename>/scripts/oe-setup-builddir</filename> script in the 
                 <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
-                You can find the Yocto Project version of the
-                <filename>bblayers.conf.sample</filename> file in the
-                <filename>meta-yocto/conf</filename> directory.
+                You can find the Yocto Project version of the 
+                <filename>bblayers.conf.sample</filename> file in the 
+                <filename>/meta-yocto/conf</filename> directory.                
             </note>
         </para>
     </section>
@@ -488,7 +491,7 @@
         <title><filename>build/tmp/</filename></title>
 
         <para>
-            This directory receives all of the OpenEmbedded build system's output.
+            This directory receives all the OpenEmbedded build system's output.
             BitBake creates this directory if it does not exist.
             As a last resort, to clean up a build and start it from scratch (other than the downloads),
             you can remove everything in the <filename>tmp</filename> directory or get rid of the
@@ -552,15 +555,6 @@
         </para>
     </section>
 
-    <section id='structure-build-tmp-deploy-ipk'>
-        <title><filename>build/tmp/deploy/ipk/</filename></title>
-
-        <para>
-            This directory receives <filename>.ipk</filename> packages produced by
-            the build process.
-        </para>
-    </section>
-
     <section id='structure-build-tmp-deploy-licenses'>
         <title><filename>build/tmp/deploy/licenses/</filename></title>
 
@@ -607,6 +601,14 @@
         </para>
     </section>
 
+    <section id='structure-build-tmp-deploy-ipk'>
+        <title><filename>build/tmp/deploy/ipk/</filename></title>
+
+        <para>
+            This directory receives <filename>.ipk</filename> packages produced by
+            the build process.</para>
+    </section>
+
     <section id='structure-build-tmp-sysroots'>
         <title><filename>build/tmp/sysroots/</filename></title>
 
@@ -648,6 +650,15 @@
         </para>
     </section>
 
+    <section id='structure-build-tmp-pkgdata'>
+        <title><filename>build/tmp/pkgdata/</filename></title>
+
+        <para>
+            This directory contains intermediate packaging data that is used later in the packaging process.
+            For more information, see the "<link linkend='ref-classes-package'>Packaging - package*.bbclass</link>" section.
+        </para>
+    </section>
+
     <section id='structure-build-tmp-work'>
         <title><filename>build/tmp/work/</filename></title>
 
@@ -779,7 +790,7 @@
             This directory contains common license files and several text files
             used by the build system.
             The text files contain minimal device information and
-            lists of files and directories with known permissions.
+            lists of files and directories with knows permissions.
         </para>
     </section>
 

documentation/ref-manual/technical-details.xml

@@ -60,10 +60,9 @@
             and is responsible for parsing the
             <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>,
             generating a list of tasks from it, and then executing those tasks.
-            To see a list of the options BitBake supports, use either of
-            the following commands:
+            To see a list of the options BitBake supports, use the following
+            help command:
             <literallayout class='monospaced'>
-     $ bitbake -h
      $ bitbake --help
             </literallayout>
         </para>
@@ -73,7 +72,7 @@
             <filename>packagename</filename> is the name of the package you want to build
             (referred to as the "target" in this manual).
             The target often equates to the first part of a <filename>.bb</filename> filename.
-            So, to process the <filename>matchbox-desktop_1.2.3.bb</filename> recipe file, you
+            So, to run the <filename>matchbox-desktop_1.2.3.bb</filename> file, you
             might type the following:
             <literallayout class='monospaced'>
      $ bitbake matchbox-desktop
@@ -112,15 +111,14 @@
         <para>
             The <filename>.bb</filename> files are usually referred to as "recipes."
             In general, a recipe contains information about a single piece of software.
-            This information includes the location from which to download the
-            unaltered source, any source patches to be applied to that source
-            (if needed), which special configuration options to apply,
+            The information includes the location from which to download the source patches
+            (if any are needed), which special configuration options to apply,
             how to compile the source files, and how to package the compiled output.
         </para>
 
         <para>
-            The term "package" is sometimes used to refer to recipes. However,
-            since the word "package" is used for the packaged output from the OpenEmbedded
+            The term "package" can also be used to describe recipes.
+            However, since the same word is used for the packaged output from the OpenEmbedded
             build system (i.e. <filename>.ipk</filename> or <filename>.deb</filename> files),
             this document avoids using the term "package" when referring to recipes.
         </para>
@@ -164,7 +162,7 @@
         <ulink url='&YOCTO_DOCS_DEV_URL;#cross-development-toolchain'>cross-development toolchains</ulink>.
         This section provides some technical background information on how
         cross-development toolchains are created and used.
-        For more information on toolchains, you can also see the
+        For more information on these toolchain, you can also see the
         <ulink url='&YOCTO_DOCS_ADT_URL;'>the Yocto Project Application Developer's Guide</ulink>.
     </para>
 
@@ -349,7 +347,7 @@
         As mentioned in the previous paragraph, building from scratch ensures that
         everything is current and starts from a known state.
         However, building from scratch also takes much longer as it generally means
-        rebuilding things that do not necessarily need to be rebuilt.
+        rebuilding things that do not necessarily need rebuilt.
     </para>
 
     <para>
@@ -357,11 +355,10 @@
         The implementation of the shared state code answers the following questions that
         were fundamental roadblocks within the OpenEmbedded incremental build support system:
         <itemizedlist>
-            <listitem><para>What pieces of the system have changed and what pieces have
-                not changed?</para></listitem>
-            <listitem><para>How are changed pieces of software removed and replaced?</para></listitem>
-            <listitem><para>How are pre-built components that do not need to be rebuilt from scratch
-                used when they are available?</para></listitem>
+            <listitem>What pieces of the system have changed and what pieces have not changed?</listitem>
+            <listitem>How are changed pieces of software removed and replaced?</listitem>
+            <listitem>How are pre-built components that do not need to be rebuilt from scratch
+                used when they are available?</listitem>
         </itemizedlist>
     </para>
 
@@ -400,16 +397,16 @@
 
         <para>
             When determining what parts of the system need to be built, BitBake
-            works on a per-task basis rather than a per-recipe basis.
+            uses a per-task basis and does not use a per-recipe basis.
             You might wonder why using a per-task basis is preferred over a per-recipe basis.
             To help explain, consider having the IPK packaging backend enabled and then switching to DEB.
             In this case, <filename>do_install</filename> and <filename>do_package</filename>
-            outputs are still valid.
+            output are still valid.
             However, with a per-recipe approach, the build would not include the
             <filename>.deb</filename> files.
             Consequently, you would have to invalidate the whole build and rerun it.
-            Rerunning everything is not the best solution.
-            Also, in this case, the core must be "taught" much about specific tasks.
+            Rerunning everything is not the best situation.
+            Also in this case, the core must be "taught" much about specific tasks.
             This methodology does not scale well and does not allow users to easily add new tasks
             in layers or as external recipes without touching the packaged-staging core.
         </para>
@@ -434,11 +431,11 @@
             the checksum.
             First, there is the actual specific build path of a given task -
             the <link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>.
-            It does not matter if the work directory changes because it should not
+            It does not matter if the working directory changes because it should not
             affect the output for target packages.
             Also, the build process has the objective of making native or cross packages relocatable.
             The checksum therefore needs to exclude <filename>WORKDIR</filename>.
-            The simplistic approach for excluding the work directory is to set
+            The simplistic approach for excluding the working directory is to set
             <filename>WORKDIR</filename> to some fixed value and create the checksum
             for the "run" script.
         </para>
@@ -515,18 +512,17 @@
             dependent task hashes can be influenced.
             Within the BitBake configuration file, we can give BitBake some extra information
             to help it construct the basehash.
-            The following statement effectively results in a list of global variable
+            The following statements effectively result in a list of global variable
             dependency excludes - variables never included in any checksum:
             <literallayout class='monospaced'>
-     BB_HASHBASE_WHITELIST ?= "TMPDIR FILE PATH PWD BB_TASKHASH BBPATH DL_DIR \
-         SSTATE_DIR THISDIR FILESEXTRAPATHS FILE_DIRNAME HOME LOGNAME SHELL TERM \
-         USER FILESPATH STAGING_DIR_HOST STAGING_DIR_TARGET COREBASE PRSERV_HOST \
-         PRSERV_DUMPDIR PRSERV_DUMPFILE PRSERV_LOCKDOWN PARALLEL_MAKE \
-         CCACHE_DIR EXTERNAL_TOOLCHAIN CCACHE CCACHE_DISABLE LICENSE_PATH SDKPKGSUFFIX"
+  BB_HASHBASE_WHITELIST ?= "TMPDIR FILE PATH PWD BB_TASKHASH BBPATH"
+  BB_HASHBASE_WHITELIST += "DL_DIR SSTATE_DIR THISDIR FILESEXTRAPATHS"
+  BB_HASHBASE_WHITELIST += "FILE_DIRNAME HOME LOGNAME SHELL TERM USER"
+  BB_HASHBASE_WHITELIST += "FILESPATH USERNAME STAGING_DIR_HOST STAGING_DIR_TARGET"
             </literallayout>
-            The previous example excludes
+            The previous example actually excludes
             <link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>
-            since that variable is actually constructed as a path within
+            since it is actually constructed as a path within
             <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link>, which is on
             the whitelist.
         </para>
@@ -545,7 +541,7 @@
             <filename>OE-Core</filename> uses the "OEBasicHash" signature handler by default
             through this setting in the <filename>bitbake.conf</filename> file:
             <literallayout class='monospaced'>
-     BB_SIGNATURE_HANDLER ?= "OEBasicHash"
+  BB_SIGNATURE_HANDLER ?= "OEBasicHash"
             </literallayout>
             The "OEBasicHash" <filename>BB_SIGNATURE_HANDLER</filename> is the same as the
             "OEBasic" version but adds the task hash to the stamp files.
@@ -554,7 +550,7 @@
             change that changes the task hash, automatically
             causing the task to be run again.
             This removes the need to bump <link linkend='var-PR'><filename>PR</filename></link>
-            values, and changes to Metadata automatically ripple across the build.
+            values and changes to Metadata automatically ripple across the build.
         </para>
 
         <para>
@@ -562,10 +558,10 @@
             make some dependency and hash information available to the build.
             This information includes:
             <literallayout class='monospaced'>
-     BB_BASEHASH_task-&lt;taskname&gt; - the base hashes for each task in the recipe
-     BB_BASEHASH_&lt;filename:taskname&gt; - the base hashes for each dependent task
-     BBHASHDEPS_&lt;filename:taskname&gt; - The task dependencies for each task
-     BB_TASKHASH - the hash of the currently running task
+  BB_BASEHASH_task-&lt;taskname&gt; - the base hashes for each task in the recipe
+  BB_BASEHASH_&lt;filename:taskname&gt; - the base hashes for each dependent task
+  BBHASHDEPS_&lt;filename:taskname&gt; - The task dependencies for each task
+  BB_TASKHASH - the hash of the currently running task
             </literallayout>
         </para>
     </section>
@@ -575,7 +571,7 @@
 
         <para>
             Checksums and dependencies, as discussed in the previous section, solve half the
-            problem of supporting a shared state.
+            problem.
             The other part of the problem is being able to use checksum information during the build
             and being able to reuse or rebuild specific components.
         </para>
@@ -585,7 +581,7 @@
             is a relatively generic implementation of how to "capture" a snapshot of a given task.
             The idea is that the build process does not care about the source of a task's output.
             Output could be freshly built or it could be downloaded and unpacked from
-            somewhere - the build process does not need to worry about its origin.
+            somewhere - the build process does not need to worry about its source.
         </para>
 
         <para>
@@ -602,7 +598,7 @@
             <filename>sstate.bbclass</filename>.
             From a user's perspective, adding shared state wrapping to a task
             is as simple as this <filename>do_deploy</filename> example taken from
-            <filename>deploy.bbclass</filename>:
+            <filename>do_deploy.bbclass</filename>:
             <literallayout class='monospaced'>
      DEPLOYDIR = "${WORKDIR}/deploy-${PN}"
      SSTATETASKS += "do_deploy"
@@ -614,9 +610,8 @@
          sstate_setscene(d)
      }
      addtask do_deploy_setscene
-     do_deploy[dirs] = "${DEPLOYDIR} ${B}"
             </literallayout>
-            In this example, we add some extra flags to the task, a name field ("deploy"), an
+            In the example, we add some extra flags to the task, a name field ("deploy"), an
             input directory where the task sends data, and the output
             directory where the data from the task should eventually be copied.
             We also add a <filename>_setscene</filename> variant of the task and add the task
@@ -735,61 +730,43 @@
             <title>Invalidating Shared State</title>
 
             <para>
-                The OpenEmbedded build system uses checksums and shared state
+                The shared state code uses checksums and shared state
                 cache to avoid unnecessarily rebuilding tasks.
-                Collectively, this scheme is known as "shared state code."
-            </para>
-
-            <para>
                 As with all schemes, this one has some drawbacks.
-                It is possible that you could make implicit changes to your
-                code that the checksum calculations do not take into
-                account (i.e. implicit changes).
-                These implicit changes affect a task's output but do not trigger
-                the shared state code into rebuilding a recipe.
-                Consider an example during which a tool changes its output.
-                Assume that the output of <filename>rpmdeps</filename> changes.
+                It is possible that you could make implicit changes that are not factored
+                into the checksum calculation, but do affect a task's output.
+                A good example is perhaps when a tool changes its output.
+                Assume that the output of <filename>rpmdeps</filename> needed to change.
                 The result of the change should be that all the
-                <filename>package</filename> and
-                <filename>package_write_rpm</filename> shared state cache
-                items become invalid.
-                However, because the change to the output is
-                external to the code and therefore implicit,
-                the associated shared state cache items do not become
-                invalidated.
-                In this case, the build process uses the cached items rather
-                than running the task again.
+                <filename>package</filename>, <filename>package_write_rpm</filename>,
+                and <filename>package_deploy-rpm</filename> shared state cache
+                items would become invalid.
+                But, because this is a change that is external to the code and therefore implicit,
+                the associated shared state cache items do not become invalidated.
+                In this case, the build process uses the cached items rather than running the
+                task again.
                 Obviously, these types of implicit changes can cause problems.
             </para>
 
             <para>
-                To avoid these problems during the build, you need to
-                understand the effects of any changes you make.
-                Realize that changes you make directly to a function
-                are automatically factored into the checksum calculation.
-                Thus, these explicit changes invalidate the associated area of
-                sstate cache.
-                However, you need to be aware of any implicit changes that
-                are not obvious changes to the code and could affect the output
-                of a given task.
-            </para>
-
-            <para>
-                When you identify an implicit change, you can easily take steps
-                to invalidate the cache and force the tasks to run.
-                The steps you can take are as simple as changing a function's
-                comments in the source code.
-                For example, to invalidate package shared state files, change
-                the comment statements of <filename>do_package</filename> or
-                the comments of one of the functions it calls.
-                Even though the change is purely cosmetic, it causes the
-                checksum to be recalculated and forces the OpenEmbedded build
-                system to run the task again.
+                To avoid these problems during the build, you need to understand the effects of any
+                change you make.
+                Note that any changes you make directly to a function automatically are factored into
+                the checksum calculation and thus, will invalidate the associated area of sstate cache.
+                You need to be aware of any implicit changes that are not obvious changes to the
+                code and could affect the output of a given task.
+                Once you are aware of such changes, you can take steps to invalidate the cache
+                and force the tasks to run.
+                The steps to take are as simple as changing function's comments in the source code.
+                For example, to invalidate package shared state files, change the comment statements
+                of <filename>do_package</filename> or the comments of one of the functions it calls.
+                The change is purely cosmetic, but it causes the checksum to be recalculated and
+                forces the task to be run again.
             </para>
 
             <note>
-                For an example of a commit that makes a cosmetic change to
-                invalidate shared state, see this
+                For an example of a commit that makes a cosmetic change to invalidate
+                a shared state, see this
                 <ulink url='&YOCTO_GIT_URL;/cgit.cgi/poky/commit/meta/classes/package.bbclass?id=737f8bbb4f27b4837047cb9b4fbfe01dfde36d54'>commit</ulink>.
             </note>
         </section>
@@ -891,7 +868,7 @@
 
     <para>
         <ulink url='http://en.wikipedia.org/wiki/Wayland_(display_server_protocol)#Weston'>Wayland</ulink>
-        is a computer display server protocol that
+        is a computer display server protocol that when implemented
         provides a method for compositing window managers to communicate
         directly with applications and video hardware and expects them to
         communicate with input hardware using other libraries.
@@ -902,7 +879,7 @@
 
     <para>
         The Yocto Project provides the Wayland protocol libraries and the
-        reference Weston compositor as part of its release.
+        reference Weston compositor as part of it release.
         This section describes what you need to do to implement Wayland and
         use the compositor when building an image for a supporting target.
     </para>
@@ -997,7 +974,7 @@
         <para>
             Alternatively, you can run Weston through the command-line
             interpretor (CLI), which is better suited for development work.
-            To run Weston under the CLI, you need to do the following after
+            To run Weston under the CLI you need to do the following after
             your image is built:
             <orderedlist>
                 <listitem><para>Run these commands to export
@@ -1149,7 +1126,7 @@
             recipe-by-recipe basis through the <filename>LICENSE_FLAGS</filename> variable
             definition in the affected recipe.
             For instance, the
-            <filename>poky/meta/recipes-multimedia/gstreamer/gst-plugins-ugly</filename>
+            <filename>$HOME/poky/meta/recipes-multimedia/gstreamer/gst-plugins-ugly</filename>
             recipe contains the following statement:
             <literallayout class='monospaced'>
      LICENSE_FLAGS = "commercial"
@@ -1165,7 +1142,7 @@
 	        <filename>LICENSE_FLAGS_WHITELIST</filename> variable, which is a variable
 	        typically defined in your <filename>local.conf</filename> file.
             For example, to enable
-	        the <filename>poky/meta/recipes-multimedia/gstreamer/gst-plugins-ugly</filename>
+	        the <filename>$HOME/poky/meta/recipes-multimedia/gstreamer/gst-plugins-ugly</filename>
 	        package, you could add either the string
 	        "commercial_gst-plugins-ugly" or the more general string
 	        "commercial" to <filename>LICENSE_FLAGS_WHITELIST</filename>.
@@ -1186,7 +1163,7 @@
             </literallayout>
 	        As a convenience, you do not need to specify the complete license string
 	        in the whitelist for every package.
-            You can use an abbreviated form, which consists
+            you can use an abbreviated form, which consists
 	        of just the first portion or portions of the license string before
 	        the initial underscore character or characters.
             A partial string will match
@@ -1208,10 +1185,10 @@
 		        License flag matching allows you to control what recipes the
                 OpenEmbedded build system includes in the build.
                 Fundamentally, the build system attempts to match
-                <filename>LICENSE_FLAGS</filename> strings found in
+                <filename>LICENSE_FLAG</filename> strings found in
                 recipes against <filename>LICENSE_FLAGS_WHITELIST</filename>
                 strings found in the whitelist.
-                A match causes the build system to include a recipe in the
+                A match, causes the build system to include a recipe in the
                 build, while failure to find a match causes the build system to
                 exclude a recipe.
             </para>
@@ -1272,7 +1249,7 @@
 
             <para>
                 This scheme works even if the
-                <filename>LICENSE_FLAGS</filename> string already
+                <filename>LICENSE_FLAG</filename> string already
                 has <filename>_${PN}</filename> appended.
                 For example, the build system turns the license flag
                 "commercial_1.2_foo" into "commercial_1.2_foo_foo" and would
@@ -1312,7 +1289,7 @@
             <para>
                 Other helpful variables related to commercial
                 license handling exist and are defined in the
-                <filename>poky/meta/conf/distro/include/default-distrovars.inc</filename> file:
+                <filename>$HOME/poky/meta/conf/distro/include/default-distrovars.inc</filename> file:
                 <literallayout class='monospaced'>
      COMMERCIAL_AUDIO_PLUGINS ?= ""
      COMMERCIAL_VIDEO_PLUGINS ?= ""

documentation/ref-manual/usingpoky.xml

@@ -40,7 +40,7 @@
         </para>
 
         <para>
-            The <filename>build_dir</filename> argument is optional and specifies the directory the
+            The <filename>build_dir</filename> is optional and specifies the directory the
             OpenEmbedded build system uses for the build -
             the <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
             If you do not specify a Build Directory, it defaults to a directory
@@ -62,7 +62,7 @@
         <para>
             The <filename>target</filename> is the name of the recipe you want to build.
             Common targets are the images in <filename>meta/recipes-core/images</filename>,
-            <filename>meta/recipes-sato/images</filename>, etc. all found in the
+            <filename>/meta/recipes-sato/images</filename>, etc. all found in the
             <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
             Or, the target can be the name of a recipe for a specific piece of software such as
             BusyBox.
@@ -72,7 +72,7 @@
 
         <note>
             Building an image without GNU General Public License Version 3 (GPLv3) components
-            is supported for only minimal and base images.
+            is only supported for minimal and base images.
             See the "<link linkend='ref-images'>Images</link>" chapter for more information.
         </note>
     </section>
@@ -158,7 +158,7 @@
             <filename>package_write</filename>, and <filename>build</filename>.
             The default task is <filename>build</filename> and any tasks on which it depends
             build first.
-            Some tasks, such as <filename>devshell</filename>, are not part of the
+            Some tasks exist, such as <filename>devshell</filename>, that are not part of the
             default build chain.
             If you wish to run a task that is not part of the default build chain, you can use the
             <filename>-c</filename> option in BitBake.
@@ -169,15 +169,14 @@
         </para>
 
         <para>
-            If you wish to rerun a task, use the <filename>-f</filename> force
-            option.
-            For example, the following sequence forces recompilation after
-            changing files in the work directory.
+            If you wish to rerun a task, use the <filename>-f</filename> force option.
+            For example, the following sequence forces recompilation after changing files in the
+            working directory.
             <literallayout class='monospaced'>
      $ bitbake matchbox-desktop
                .
                .
-        [make some changes to the source code in the work directory]
+        [make some changes to the source code in the working directory]
                .
                .
      $ bitbake matchbox-desktop -c compile -f
@@ -207,19 +206,14 @@
         <title>Dependency Graphs</title>
 
         <para>
-            Sometimes it can be hard to see why BitBake wants to build
-            other packages before building a given package you have specified.
-            The <filename>bitbake -g &lt;targetname&gt;</filename> command
-            creates the <filename>pn-buildlist</filename>,
-            <filename>pn-depends.dot</filename>,
-            <filename>package-depends.dot</filename>, and
-            <filename>task-depends.dot</filename> files in the current
-            directory.
-            These files show what will be built and the package and task
-            dependencies, which are useful for debugging problems.
-            You can use the
-            <filename>bitbake -g -u depexp &lt;targetname&gt;</filename>
-            command to display the results in a more human-readable form.
+            Sometimes it can be hard to see why BitBake wants to build some other packages before a given
+            package you have specified.
+            The <filename>bitbake -g targetname</filename> command creates the
+            <filename>depends.dot</filename>, <filename>package-depends.dot</filename>,
+            and <filename>task-depends.dot</filename> files in the current directory.
+            These files show the package and task dependencies and are useful for debugging problems.
+            You can use the <filename>bitbake -g -u depexp targetname</filename> command to
+            display the results in a more human-readable form.
         </para>
     </section>
 
@@ -277,18 +271,12 @@
     <section id='usingpoky-debugging-buildfile'>
         <title>Building with No Dependencies</title>
         <para>
-            To build a specific recipe (<filename>.bb</filename> file),
-            you can use the following command form:
-            <literallayout class='monospaced'>
-     $ bitbake -b &lt;somepath/somerecipe.bb&gt;
-            </literallayout>
-            This command form does not check for dependencies.
-            Consequently, you should use it
-            only when you know dependencies already exist.
-            <note>
-                You can also specify fragments of the filename.
-                In this case, BitBake checks for a unique match.
-            </note>
+            If you really want to build a specific <filename>.bb</filename> file, you can use
+            the command form <filename>bitbake -b &lt;somepath/somefile.bb&gt;</filename>.
+            This command form does not check for dependencies so you should use it
+            only when you know its dependencies already exist.
+            You can also specify fragments of the filename.
+            In this case, BitBake checks for a unique match.
         </para>
     </section>
 
@@ -296,16 +284,11 @@
         <title>Variables</title>
         <para>
             You can use the <filename>-e</filename> BitBake option to
-            display the parsing environment for a configuration.
-            The following displays the general parsing environment:
-            <literallayout class='monospaced'>
-     $ bitbake -e
-            </literallayout>
-            This next example shows the parsing environment for a specific
-            recipe:
-            <literallayout class='monospaced'>
-     $ bitbake -e &lt;recipename&gt;
-            </literallayout>
+            display the resulting environment for a configuration
+            when you do not specify a package or for a specific package when
+            you do specify the package.
+            If you want to show the environment resulting from parsing a single
+            recipe, use the <filename>-b recipename</filename> form.
         </para>
     </section>
 
@@ -496,11 +479,11 @@
             from your <filename>conf/local.conf</filename> file.
             However, you should realize that enabling and disabling
             build history in this manner can change the
-            <filename>do_package</filename> task checksums which, if you
+            <filename>do_package</filename> task checksums, which if you
             are using the OEBasicHash signature generator (the default
             for many current distro configurations including
             <filename>DISTRO = "poky"</filename> and
-            <filename>DISTRO = ""</filename>) will result in the packaging
+            <filename>DISTRO = ""</filename>) and will result in the packaging
             tasks being re-run during the subsequent build.
         </para>
 

documentation/tools/mega-manual.sed

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

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

@@ -17,10 +17,11 @@
                 the terms of the <ulink type="http" url="http://creativecommons.org/licenses/by-sa/2.0/uk/">Creative Commons Attribution-Share Alike 2.0 UK: England &amp; Wales</ulink> as published by Creative Commons.
             </para>
             <note>
-                For the latest version of this manual associated with this
-                Yocto Project release, see the
-                <ulink url='&YOCTO_DOCS_QS_URL;'>Yocto Project Quick Start</ulink>
-                from the Yocto Project website.
+                Due to production processes, there could be differences between the Yocto Project
+                documentation bundled in the release tarball and the
+                <ulink url='&YOCTO_DOCS_QS_URL;'>Yocto Project Quick Start</ulink> on
+                the <ulink url='&YOCTO_HOME_URL;'>Yocto Project</ulink> website.
+                For the latest version of this manual, see the manual on the website.
             </note>
         </legalnotice>
 
@@ -231,6 +232,11 @@
                 distributions listed in the
                 "<ulink url='&YOCTO_DOCS_REF_URL;#detailed-supported-distros'>Supported Linux Distributions</ulink>"
                 section of the Yocto Project Reference Manual.
+                Refer to
+                <ulink url='&OE_HOME_URL;/index.php?title=OEandYourDistro'>OE and Your Distro</ulink> and
+                <ulink url='&OE_HOME_URL;/index.php?title=Required_software'>Required Software</ulink>
+                for information for information about dependencies and
+                requirements.
                 If you encounter problems, please go to
                 <ulink url='&YOCTO_BUGZILLA_URL;'>Yocto Project Bugzilla</ulink>
                 and submit a bug.
@@ -409,9 +415,9 @@
 
          <para>
              <literallayout class='monospaced'>
-     $ git clone &YOCTO_GIT_URL;/git/poky
-     $ cd poky
-     $ git checkout -b &DISTRO_NAME; origin/&DISTRO_NAME;
+     $ wget &YOCTO_POKY_DL_URL;
+     $ tar xjf &YOCTO_POKY;.tar.bz2
+     $ cd &YOCTO_POKY;
      $ source &OE_INIT_FILE;
              </literallayout>
          </para>
@@ -428,31 +434,30 @@
          </para></tip>
 
          <itemizedlist>
-             <listitem><para>In the previous example, the first command uses
-                 <ulink url='&YOCTO_DOCS_DEV_URL;#git'>Git</ulink> to create
-                 a local repository named <filename>poky</filename> that is a
-                 clone of the upstream Yocto Project
-                 <filename>poky</filename> repository.</para></listitem>
-             <listitem><para>The third command checks out a local branch and
-                 names it <filename>&DISTRO_NAME;</filename>.
-                 The local branch tracks the upstream branch of the same name.
-                 Creating your own branch based on the released branch ensures
-                 you are using the latest files for that release.
-                 </para></listitem>
-             <listitem><para>The final command runs the Yocto Project
+             <listitem><para>In the previous example, the first command retrieves the Yocto Project
+                 release tarball from the source repositories using the
+                 <filename>wget</filename> command.
+                 Alternatively, you can go to the
+                 <ulink url='&YOCTO_HOME_URL;'>Yocto Project website's</ulink>
+                 "Downloads" page to retrieve the tarball.</para></listitem>
+             <listitem><para>The second command extracts the files from the tarball and places
+                 them into a directory named <filename>&YOCTO_POKY;</filename> in the current
+                 directory.</para></listitem>
+             <listitem><para>The third and fourth commands change the working directory to the
+                 <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+                 and run the Yocto Project
                  <ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>
                  environment setup script.
-                 Running this script defines OpenEmbedded build environment
-                 settings needed to complete the build.
+                 Running this script defines OpenEmbedded build environment settings needed to
+                 complete the build.
                  The script also creates the
                  <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>,
-                 which is <filename>build</filename> in this case and is located
-                 in the
-                 <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+                 which is <filename>build</filename> in this case and is located in the
+                 Source Directory.
                  After the script runs, your current working directory is set
                  to the Build Directory.
-                 Later, when the build completes, the Build Directory contains
-                 all the files created during the build.
+                 Later, when the build completes, the Build Directory contains all the files
+                 created during the build.
                  <note>
                      For information on running a memory-resident BitBake, see
                      the
@@ -586,7 +591,7 @@
             </para>
 
             <literallayout class='monospaced'>
-     poky-eglibc-&lt;<emphasis>host_system</emphasis>&gt;-&lt;<emphasis>image_type</emphasis>&gt;-&lt;<emphasis>arch</emphasis>&gt;-toolchain-&lt;<emphasis>release_version</emphasis>&gt;.sh
+     poky-eglibc-&lt;<emphasis>host_system</emphasis>&gt;-&lt;<emphasis>image_type</emphasis>&gt;-&lt;<emphasis>arch</emphasis>&gt;-&lt;<emphasis>release_version</emphasis>&gt;.sh
 
      Where:
          &lt;<emphasis>host_system</emphasis>&gt; is a string representing your development system:
@@ -615,7 +620,7 @@
                 development host system and a i586-tuned target architecture
                 based off the SDK for <filename>core-image-sato</filename>:
                 <literallayout class='monospaced'>
-     poky-eglibc-x86_64-core-image-sato-i586-toolchain-&DISTRO;.sh
+     poky-eglibc-x86_64-core-image-sato-i586-&DISTRO;.sh
                 </literallayout>
             </para>
 
@@ -644,7 +649,7 @@
 
             <para>
                 <literallayout class='monospaced'>
-     $ ~/Downloads/poky-eglibc-x86_64-core-image-sato-i586-toolchain-&DISTRO;.sh
+     $ ~/Downloads/poky-eglibc-x86_64-core-image-sato-i586-&DISTRO;.sh
                 </literallayout>
             </para>
 
@@ -717,6 +722,11 @@
          &lt;<emphasis>arch</emphasis>&gt; is a string representing the target architecture:
                 x86, x86-64, ppc, mips, or arm.
                 </literallayout>
+                <note>
+                    For the <filename>qemu</filename> architecture,
+                    <filename>ext3</filename> and <filename>tar</filename>
+                    files start with the "lib32" string.
+                </note>
             </para>
         </section>
 
@@ -799,23 +809,29 @@
         </footnote>
         gives you a minimal description of how to use the Yocto Project to build images
         for a BeagleBoard xM starting from scratch.
-        The steps were performed on a 64-bit Ubuntu 12.04 system.
+        The steps were performed on a 64-bit Ubuntu 10.04 system.
     </para>
 
     <section id='getting-yocto'>
         <title>Getting the Yocto Project</title>
 
         <para>
-            Set up your
-            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
-            by using Git to clone the <filename>poky</filename> poky
-            repository and then check out the release branch:
-            <literallayout class='monospaced'>
-     $ cd ~
+            Set up your <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+            one of two ways:
+            <itemizedlist>
+                <listitem><para><emphasis>Tarball:</emphasis>
+                    Use if you want the latest stable release:
+                    <literallayout class='monospaced'>
+     $ wget &YOCTO_RELEASE_DL_URL;/&YOCTO_POKY_TARBALL;
+     $ tar xvjf &YOCTO_POKY_TARBALL;
+                    </literallayout></para></listitem>
+                <listitem><para><emphasis>Git Repository:</emphasis>
+                    Use if you want to work with cutting edge development content:
+                    <literallayout class='monospaced'>
      $ git clone git://git.yoctoproject.org/poky
-     $ cd poky
-     $ git checkout -b &DISTRO_NAME; origin/&DISTRO_NAME;
-            </literallayout>
+                    </literallayout></para></listitem>
+            </itemizedlist>
+            The remainder of the section assumes the Git repository method.
         </para>
     </section>
 
@@ -824,8 +840,7 @@
 
         <para>
             You need some packages for everything to work.
-            Rather than duplicate them here, look at the
-            "<link linkend='packages'>The Packages</link>"
+            Rather than duplicate them here, look at the "<link linkend='packages'>The Packages</link>"
             section earlier in this quick start.
         </para>
     </section>
@@ -834,18 +849,17 @@
         <title>Initializing the Build Environment</title>
 
         <para>
-            From the root directory of your
+            From the parent directory your
             <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>,
             initialize your environment and provide a meaningful
             <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
             name:
             <literallayout class='monospaced'>
-     $ source &OE_INIT_FILE; mybuilds
+     $ source poky/&OE_INIT_FILE; mybuilds
             </literallayout>
-            At this point, the <filename>mybuilds</filename> directory has
-            been created for you and it is now your current working directory.
-            If you don't provide your own directory name,
-            it defaults to <filename>build</filename>,
+            At this point, the <filename>mybuilds</filename> directory has been created for you
+            and it is now your current working directory.
+            If you don't provide your own directory name it defaults to <filename>build</filename>,
             which is inside the Source Directory.
         </para>
     </section>
@@ -854,21 +868,18 @@
         <title>Configuring the local.conf File</title>
 
         <para>
-            Initializing the build environment creates a
-            <filename>conf/local.conf</filename> configuration file
+            Initializing the build environment creates a <filename>conf/local.conf</filename> configuration file
             in the Build Directory.
-            You need to manually edit this file to specify the machine you
-            are building and to optimize your build time.
+            You need to manually edit this file to specify the machine you are building and to optimize
+            your build time.
             Here are the minimal changes to make:
             <literallayout class='monospaced'>
      BB_NUMBER_THREADS = "8"
      PARALLEL_MAKE = "-j 8"
      MACHINE ?= "beagleboard"
             </literallayout>
-            Briefly, set
-            <ulink url='&YOCTO_DOCS_REF_URL;#var-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename></ulink>
-            and
-            <ulink url='&YOCTO_DOCS_REF_URL;#var-PARALLEL_MAKE'><filename>PARALLEL_MAKE</filename></ulink> to
+            Briefly, set <ulink url='&YOCTO_DOCS_REF_URL;#var-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename></ulink>
+            and <ulink url='&YOCTO_DOCS_REF_URL;#var-PARALLEL_MAKE'><filename>PARALLEL_MAKE</filename></ulink> to
             twice your host processor's number of cores.
         </para>
 
@@ -918,10 +929,9 @@
         <title>Building the Image</title>
 
         <para>
-            At this point, you need to select an image to build for the
-            BeagleBoard xM.
-            If this is your first build using the Yocto Project, you should try
-            the smallest and simplest image:
+            At this point, you need to select an image to build for the BeagleBoard xM.
+            If this is your first build using the Yocto Project, you should try the smallest and simplest
+            image:
             <literallayout class='monospaced'>
      $ bitbake core-image-minimal
             </literallayout>
@@ -931,18 +941,15 @@
         <para>
             Here are some variations on the build process that could be helpful:
             <itemizedlist>
-                <listitem><para>Fetch all the necessary sources without starting
-                    the build:
+                <listitem><para>Fetch all the necessary sources without starting the build:
                     <literallayout class='monospaced'>
      $ bitbake -c fetchall core-image-minimal
                     </literallayout>
-                    This variation guarantees that you have all the sources for
-                    that BitBake target should you disconnect from the net and
-                    want to do the build later offline.</para></listitem>
-                <listitem><para>Specify to continue the build even if BitBake
-                    encounters an error.
-                    By default, BitBake aborts the build when it encounters an
-                    error.
+                    This variation guarantees that you have all the sources for that BitBake target
+                    should you disconnect from the net and want to do the build later offline.
+                    </para></listitem>
+                <listitem><para>Specify to continue the build even if BitBake encounters an error.
+                    By default, BitBake aborts the build when it encounters an error.
                     This command keeps a faulty build going:
                     <literallayout class='monospaced'>
      $ bitbake -k core-image-minimal
@@ -951,8 +958,7 @@
         </para>
 
         <para>
-            Once you have your image, you can take steps to load and boot it on
-            the target hardware.
+            Once you have your image, you can take steps to load and boot it on the target hardware.
         </para>
     </section>
 </section>

meta-selftest/COPYING.MIT

@@ -1,17 +0,0 @@
-Permission is hereby granted, free of charge, to any person obtaining a copy
-of this software and associated documentation files (the "Software"), to deal
-in the Software without restriction, including without limitation the rights
-to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-copies of the Software, and to permit persons to whom the Software is
-furnished to do so, subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in
-all copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
-AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
-OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
-THE SOFTWARE.

meta-selftest/README

@@ -1,3 +0,0 @@
-This layer is intended as test layer, used by scripts/oe-selftest
-and it's probably a mistake to include it in your builds (unless you
-want to run the script).

meta-selftest/classes/test_events.bbclass

@@ -1,16 +0,0 @@
-python test1_eventhandler() {
-    bb.note("Test for bb.event.BuildStarted")
-}
-python test2_eventhandler() {
-    bb.note("Test for bb.event.BuildCompleted")
-}
-python test3_eventhandler() {
-    bb.note("Test for bb.event.InvalidEvent")
-}
-
-addhandler test1_eventhandler
-test1_eventhandler[eventmask] = "bb.event.BuildStarted"
-addhandler test2_eventhandler
-test2_eventhandler[eventmask] = "bb.event.BuildCompleted"
-addhandler test3_eventhandler
-test3_eventhandler[eventmask] = "bb.event.InvalidEvent"

meta-selftest/conf/layer.conf

@@ -1,10 +0,0 @@
-# We have a conf and classes directory, add to BBPATH
-BBPATH .= ":${LAYERDIR}"
-
-# We have recipes-* directories, add to BBFILES
-BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
-	${LAYERDIR}/recipes-*/*/*.bbappend"
-
-BBFILE_COLLECTIONS += "selftest"
-BBFILE_PATTERN_selftest = "^${LAYERDIR}/"
-BBFILE_PRIORITY_selftest = "5"

meta-selftest/recipes-test/aspell/aspell_0.0.0.1.bb

@@ -1,28 +0,0 @@
-# This recipe is a copy from the oe-core one.
-# It has a lower and invalid version number in order not to be accidentally used by bitbake.
-# It is used for tests that require overlayed recipe files.
-
-DESCRIPTION = "GNU Aspell spell-checker"
-SECTION = "console/utils"
-LICENSE="LGPLv2 | LGPLv2.1"
-LIC_FILES_CHKSUM = "file://COPYING;md5=7fbc338309ac38fefcd64b04bb903e34"
-PR = "r1"
-
-SRC_URI = "${GNU_MIRROR}/aspell/aspell-${PV}.tar.gz"
-SRC_URI[md5sum] = "e66a9c9af6a60dc46134fdacf6ce97d7"
-SRC_URI[sha256sum] = "f52583a83a63633701c5f71db3dc40aab87b7f76b29723aeb27941eff42df6e1"
-
-PACKAGECONFIG ??= ""
-PACKAGECONFIG[curses] = "--enable-curses,--disable-curses,ncurses"
-
-PACKAGES += "libaspell libpspell libpspell-dev aspell-utils"
-
-FILES_${PN}-dbg += "${libdir}/aspell-0.60/.debu*"
-FILES_libaspell = "${libdir}/libaspell.so.* ${libdir}/aspell*"
-FILES_aspell-utils = "${bindir}/word-list-compress ${bindir}/aspell-import ${bindir}/run-with-aspell ${bindir}/pre*"
-FILES_${PN} = "${bindir}/aspell"
-FILES_libpspell = "${libdir}/libpspell.so.*"
-FILES_libpspell-dev = "${libdir}/libpspell* ${bindir}/pspell-config ${includedir}/pspell"
-
-ARM_INSTRUCTION_SET = "arm"
-inherit autotools gettext

meta-selftest/recipes-test/aspell/aspell_0.60.6.1.bbappend

@@ -1,2 +0,0 @@
-# This bbappend is used to alter the recipe using the test_recipe.inc file created by tests.
-include test_recipe.inc

meta-selftest/recipes-test/m4/m4_1.4.17.bbappend

@@ -1,2 +0,0 @@
-# This bbappend is used to alter the recipe using the test_recipe.inc file created by tests.
-include test_recipe.inc

meta-selftest/recipes-test/man/man/man-1.5h1-make.patch

@@ -1,16 +0,0 @@
-Test patch here!
-This is invalid patch used by tests in scripts/lib/selftests.
-
---- man-1.5g/man/Makefile.in.mike	Fri Apr  9 13:35:54 1999
-+++ man-1.5g/man/Makefile.in	Fri Apr  9 13:36:45 1999
-@@ -1,8 +1,8 @@
- #MAKE THIS PATCH INVALID
- MAN1 = man whatis apropos
--MAN5 = man.conf
-+MAN5 = man.config
- MAN8 = makewhatis
--ALL = man.1 whatis.1 apropos.1 man.conf.5
-+ALL = man.1 whatis.1 apropos.1 man.config.5
- MAYBE8 = makewhatis
- 
- .SUFFIXES: .man .1 .5 .8

meta-selftest/recipes-test/man/man_1.6g.bbappend

@@ -1,2 +0,0 @@
-# This bbappend is used to alter the recipe using the test_recipe.inc file created by tests.
-include test_recipe.inc