bitbake: bitbake-user-manual: Fixed porno hack for hello world example

Someone hacked the http://hambedded site or it was moved and some
links to that site in the BB manual had been hijacked to point to
an entry portal for a pornography site.  Replaced the link with an
archived version that restores the integrity of the links.

(Bitbake rev: daa0aa05a04d8d20473a05b5b5878610e40ef820)

Signed-off-by: Scott Rifenbark <srifenbark@gmail.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.23.2"
+__version__ = "1.24.0"
 logger = logging.getLogger("BitBake")
 
 # Python multiprocessing requires /dev/shm
@@ -263,6 +263,7 @@ def start_server(servermodule, configParams, configuration, features):
                 logger.handle(event)
         raise exc_info[1], None, exc_info[2]
     server.detach()
+    cooker.lock.close()
     return server
 
 

bitbake/bin/bitbake-worker

@@ -147,6 +147,8 @@ def fork_off_task(cfg, data, workerdata, fn, task, taskname, appends, taskdepdat
             pipein.close()
 
             signal.signal(signal.SIGTERM, sigterm_handler)
+            # Let SIGHUP exit as SIGTERM
+            signal.signal(signal.SIGHUP, sigterm_handler)
 
             # Save out the PID so that the event can include it the
             # events
@@ -154,8 +156,11 @@ def fork_off_task(cfg, data, workerdata, fn, task, taskname, appends, taskdepdat
             bb.event.worker_fire = worker_child_fire
             worker_pipe = pipeout
 
-            # Make the child the process group leader
-            os.setpgid(0, 0)
+            # Make the child the process group leader and ensure no
+            # child process will be controlled by the current terminal
+            # This ensures signals sent to the controlling terminal like Ctrl+C
+            # don't stop the child processes.
+            os.setsid()
             # No stdin
             newsi = os.open(os.devnull, os.O_RDWR)
             os.dup2(newsi, sys.stdin.fileno())
@@ -193,8 +198,9 @@ def fork_off_task(cfg, data, workerdata, fn, task, taskname, appends, taskdepdat
                     logger.critical(str(exc))
                 os._exit(1)
             try:
-                if not cfg.dry_run:
-                    return bb.build.exec_task(fn, taskname, the_data, cfg.profile)
+                if cfg.dry_run:
+                    return 0
+                return bb.build.exec_task(fn, taskname, the_data, cfg.profile)
             except:
                 os._exit(1)
         if not profiling:
@@ -265,9 +271,14 @@ class BitbakeWorker(object):
         self.build_pipes = {}
     
         signal.signal(signal.SIGTERM, self.sigterm_exception)
+        # Let SIGHUP exit as SIGTERM
+        signal.signal(signal.SIGHUP, self.sigterm_exception)
 
     def sigterm_exception(self, signum, stackframe):
-        bb.warn("Worker recieved SIGTERM, shutting down...")
+        if signum == signal.SIGTERM:
+            bb.warn("Worker recieved SIGTERM, shutting down...")
+        elif signum == signal.SIGHUP:
+            bb.warn("Worker recieved SIGHUP, shutting down...")
         self.handle_finishnow(None)
         signal.signal(signal.SIGTERM, signal.SIG_DFL)
         os.kill(os.getpid(), signal.SIGTERM)

bitbake/doc/bitbake-user-manual/bitbake-user-manual-hello.xml

@@ -135,7 +135,7 @@
                     <ulink url="http://www.mail-archive.com/yocto@yoctoproject.org/msg09379.html">Mailing List post - The BitBake equivalent of "Hello, World!"</ulink>
                     </para></listitem>
                 <listitem><para>
-                    <ulink url="http://hambedded.org/blog/2012/11/24/from-bitbake-hello-world-to-an-image/">Hambedded Linux blog post - From Bitbake Hello World to an Image</ulink>
+                    <ulink url="https://web.archive.org/web/20150325165911/http://hambedded.org/blog/2012/11/24/from-bitbake-hello-world-to-an-image/">Hambedded Linux blog post - From Bitbake Hello World to an Image</ulink>
                     </para></listitem>
             </itemizedlist>
         </note>
@@ -270,7 +270,7 @@
                 and define some key BitBake variables.
                 For more information on the <filename>bitbake.conf</filename>,
                 see
-                <ulink url='http://hambedded.org/blog/2012/11/24/from-bitbake-hello-world-to-an-image/#an-overview-of-bitbakeconf'></ulink>
+                <ulink url='https://web.archive.org/web/20150325165911/http://hambedded.org/blog/2012/11/24/from-bitbake-hello-world-to-an-image/#an-overview-of-bitbakeconf'></ulink>
                 </para>
                 <para>Use the following commands to create the <filename>conf</filename>
                 directory in the project directory:
@@ -355,7 +355,7 @@ ERROR: Unable to parse base: ParseError in configuration INHERITs: Could not inh
                 supporting.
                 For more information on the <filename>base.bbclass</filename> file,
                 you can look at
-                <ulink url='http://hambedded.org/blog/2012/11/24/from-bitbake-hello-world-to-an-image/#tasks'></ulink>.
+                <ulink url='https://web.archive.org/web/20150325165911/http://hambedded.org/blog/2012/11/24/from-bitbake-hello-world-to-an-image/#tasks'></ulink>.
                 </para></listitem>
             <listitem><para><emphasis>Run Bitbake:</emphasis>
                 After making sure that the <filename>classes/base.bbclass</filename>
@@ -377,7 +377,7 @@ ERROR: Unable to parse base: ParseError in configuration INHERITs: Could not inh
                 Thus, this example creates and uses a layer called "mylayer".
                 <note>
                     You can find additional information on adding a layer at
-                    <ulink url='http://hambedded.org/blog/2012/11/24/from-bitbake-hello-world-to-an-image/#adding-an-example-layer'></ulink>.
+                    <ulink url='https://web.archive.org/web/20150325165911/http://hambedded.org/blog/2012/11/24/from-bitbake-hello-world-to-an-image/#adding-an-example-layer'></ulink>.
                 </note>
                 </para>
                 <para>Minimally, you need a recipe file and a layer configuration

bitbake/doc/bitbake-user-manual/bitbake-user-manual-metadata.xml

@@ -1308,8 +1308,8 @@
             BitBake allows installation of event handlers within
             recipe and class files.
             Events are triggered at certain points during operation,
-            such as the beginning of operation against a given
-            <filename>.bb</filename>, the start of a given task,
+            such as the beginning of an operation against a given recipe
+            (<filename>*.bb</filename> file), the start of a given task,
             task failure, task success, and so forth.
             The intent is to make it easy to do things like email
             notification on build failure.
@@ -1337,6 +1337,27 @@
             the name of the triggered event.
         </para>
 
+        <para>
+            Because you probably are only interested in a subset of events,
+            you would likely use the <filename>[eventmask]</filename> flag
+            for your event handler to be sure that only certain events
+            trigger the handler.
+            Given the previous example, suppose you only wanted the
+            <filename>bb.build.TaskFailed</filename> event to trigger that
+            event handler.
+            Use the flag as follows:
+            <literallayout class='monospaced'>
+     addhandler myclass_eventhandler
+     myclass_eventhandler[eventmask] = "bb.build.TaskFailed"
+     python myclass_eventhandler() {
+         from bb.event import getName
+         from bb import data
+         print("The name of the Event is %s" % getName(e))
+         print("The file we run for is %s" % data.getVar('FILE', e.data, True))
+     }
+            </literallayout>
+        </para>
+
         <para>
             During a standard build, the following common events might occur:
             <itemizedlist>
@@ -1551,11 +1572,11 @@
                 item runtime dependency which must have completed before that
                 task can be executed.
                 <literallayout class='monospaced'>
-     do_package_write[rdeptask] = "do_package"
+     do_package_qa[rdeptask] = "do_packagedata"
                 </literallayout>
-                In the previous example, the <filename>do_package</filename>
+                In the previous example, the <filename>do_packagedata</filename>
                 task of each item in <filename>RDEPENDS</filename> must have
-                completed before <filename>do_package_write</filename> can execute.
+                completed before <filename>do_package_qa</filename> can execute.
             </para>
         </section>
 

bitbake/doc/bitbake-user-manual/bitbake-user-manual.xml

@@ -56,7 +56,7 @@
 -->
 
         <copyright>
-            <year>2004-2014</year>
+            <year>2004-2015</year>
             <holder>Richard Purdie</holder>
             <holder>Chris Larson</holder>
             <holder>and Phil Blundell</holder>

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.23.2"
+__version__ = "1.24.0"
 
 import sys
 if sys.version_info < (2, 7, 3):

bitbake/lib/bb/cache.py

@@ -43,7 +43,7 @@ except ImportError:
     logger.info("Importing cPickle failed. "
                 "Falling back to a very slow implementation.")
 
-__cache_version__ = "147"
+__cache_version__ = "148"
 
 def getCacheFile(path, filename, data_hash):
     return os.path.join(path, filename + "." + data_hash)
@@ -529,8 +529,11 @@ class Cache(object):
         if hasattr(info_array[0], 'file_checksums'):
             for _, fl in info_array[0].file_checksums.items():
                 for f in fl.split():
-                    if not ('*' in f or os.path.exists(f)):
-                        logger.debug(2, "Cache: %s's file checksum list file %s was removed",
+                    if "*" in f:
+                        continue
+                    f, exist = f.split(":")
+                    if (exist == "True" and not os.path.exists(f)) or (exist == "False" and os.path.exists(f)):
+                        logger.debug(2, "Cache: %s's file checksum list file %s changed",
                                         fn, f)
                         self.remove(fn)
                         return False
@@ -620,10 +623,13 @@ class Cache(object):
     def mtime(cachefile):
         return bb.parse.cached_mtime_noerror(cachefile)
 
-    def add_info(self, filename, info_array, cacheData, parsed=None):
+    def add_info(self, filename, info_array, cacheData, parsed=None, watcher=None):
         if isinstance(info_array[0], CoreRecipeInfo) and (not info_array[0].skipped):
             cacheData.add_from_recipeinfo(filename, info_array)
 
+            if watcher:
+                watcher(info_array[0].file_depends)
+
         if not self.has_cache:
             return
 

bitbake/lib/bb/command.py

@@ -271,6 +271,10 @@ class CommandsSync:
     # we always take and leave the cooker in state.initial
     setFeatures.readonly = True
 
+    def updateConfig(self, command, params):
+        options = params[0]
+        command.cooker.updateConfigOpts(options)
+
 class CommandsAsync:
     """
     A class of asynchronous commands

bitbake/lib/bb/cooker.py

@@ -38,7 +38,10 @@ import bb, bb.exceptions, bb.command
 from bb import utils, data, parse, event, cache, providers, taskdata, runqueue
 import Queue
 import signal
+import subprocess
+import errno
 import prserv.serv
+import pyinotify
 
 logger      = logging.getLogger("BitBake")
 collectlog  = logging.getLogger("BitBake.Collection")
@@ -120,8 +123,34 @@ class BBCooker:
 
         self.configuration = configuration
 
+        self.configwatcher = pyinotify.WatchManager()
+        self.configwatcher.bbseen = []
+        self.confignotifier = pyinotify.Notifier(self.configwatcher, self.config_notifications)
+        self.watchmask = pyinotify.IN_CLOSE_WRITE | pyinotify.IN_CREATE | pyinotify.IN_DELETE | \
+                         pyinotify.IN_DELETE_SELF | pyinotify.IN_MODIFY | pyinotify.IN_MOVE_SELF | \
+                         pyinotify.IN_MOVED_FROM | pyinotify.IN_MOVED_TO 
+        self.watcher = pyinotify.WatchManager()
+        self.watcher.bbseen = []
+        self.notifier = pyinotify.Notifier(self.watcher, self.notifications)
+
+
         self.initConfigurationData()
 
+        self.inotify_modified_files = []
+
+        def _process_inotify_updates(server, notifier_list, abort):
+            for n in notifier_list:
+                if n.check_events(timeout=0):
+                    # read notified events and enqeue them
+                    n.read_events()
+                    n.process_events()
+            return 1.0
+
+        self.configuration.server_register_idlecallback(_process_inotify_updates, [self.confignotifier, self.notifier])
+
+        self.baseconfig_valid = True
+        self.parsecache_valid = False
+
         # Take a lock so only one copy of bitbake can run against a given build
         # directory at a time
         lockfile = self.data.expand("${TOPDIR}/bitbake.lock")
@@ -153,9 +182,46 @@ class BBCooker:
         self.parser = None
 
         signal.signal(signal.SIGTERM, self.sigterm_exception)
+        # Let SIGHUP exit as SIGTERM
+        signal.signal(signal.SIGHUP, self.sigterm_exception)
+
+    def config_notifications(self, event):
+        if not event.path in self.inotify_modified_files:
+            self.inotify_modified_files.append(event.path)
+        self.baseconfig_valid = False
+
+    def notifications(self, event):
+        if not event.path in self.inotify_modified_files:
+            self.inotify_modified_files.append(event.path)
+        self.parsecache_valid = False
+
+    def add_filewatch(self, deps, watcher=None):
+        if not watcher:
+            watcher = self.watcher
+        for i in deps:
+            f = i[0]
+            if f in watcher.bbseen:
+                continue
+            watcher.bbseen.append(f)
+            while True:
+                # We try and add watches for files that don't exist but if they did, would influence
+                # the parser. The parent directory of these files may not exist, in which case we need 
+                # to watch any parent that does exist for changes.
+                try:
+                    watcher.add_watch(f, self.watchmask, quiet=False)
+                    break
+                except pyinotify.WatchManagerError as e:
+                    if 'ENOENT' in str(e):
+                        f = os.path.dirname(f)
+                        watcher.bbseen.append(f)
+                        continue
+                    raise
 
     def sigterm_exception(self, signum, stackframe):
-        bb.warn("Cooker recieved SIGTERM, shutting down...")
+        if signum == signal.SIGTERM:
+            bb.warn("Cooker recieved SIGTERM, shutting down...")
+        elif signum == signal.SIGHUP:
+            bb.warn("Cooker recieved SIGHUP, shutting down...")
         self.state = state.forceshutdown
 
     def setFeatures(self, features):
@@ -371,6 +437,10 @@ class BBCooker:
 
         self.handleCollections( self.data.getVar("BBFILE_COLLECTIONS", True) )
 
+    def updateConfigOpts(self,options):
+        for o in options:
+            setattr(self.configuration, o, options[o])
+
     def runCommands(self, server, data, abort):
         """
         Run any queued asynchronous command
@@ -1277,12 +1347,25 @@ class BBCooker:
         if self.state == state.running:
             return
 
-        if self.state in (state.shutdown, state.forceshutdown):
+        if self.state in (state.shutdown, state.forceshutdown, state.error):
             if hasattr(self.parser, 'shutdown'):
                 self.parser.shutdown(clean=False, force = True)
             raise bb.BBHandledException()
 
         if self.state != state.parsing:
+
+            # reload files for which we got notifications
+            for p in self.inotify_modified_files:
+                bb.parse.update_cache(p)
+            self.inotify_modified_files = []
+
+            if not self.baseconfig_valid:
+                logger.debug(1, "Reloading base configuration data")
+                self.initConfigurationData()
+                self.baseconfig_valid = True
+                self.parsecache_valid = False
+
+        if self.state != state.parsing and not self.parsecache_valid:
             self.parseConfiguration ()
             if CookerFeatures.SEND_SANITYEVENTS in self.featureset:
                 bb.event.fire(bb.event.SanityCheck(False), self.data)
@@ -1297,9 +1380,12 @@ class BBCooker:
             (filelist, masked) = self.collection.collect_bbfiles(self.data, self.event_data)
 
             self.data.renameVar("__depends", "__base_depends")
+            self.add_filewatch(self.data.getVar("__base_depends"), self.configwatcher)
 
             self.parser = CookerParser(self, filelist, masked)
-            self.state = state.parsing
+            self.parsecache_valid = True
+
+        self.state = state.parsing
 
         if not self.parser.parse_next():
             collectlog.debug(1, "parsing complete")
@@ -1358,6 +1444,33 @@ class BBCooker:
     def post_serve(self):
         prserv.serv.auto_shutdown(self.data)
         bb.event.fire(CookerExit(), self.event_data)
+        lockfile = self.lock.name
+        self.lock.close()
+        self.lock = None
+
+        while not self.lock:
+            with bb.utils.timeout(3):
+                self.lock = bb.utils.lockfile(lockfile, shared=False, retry=False, block=True)
+                if not self.lock:
+                    # Some systems may not have lsof available
+                    procs = None
+                    try:
+                        procs = subprocess.check_output(["lsof", '-w', lockfile], stderr=subprocess.STDOUT)
+                    except OSError as e:
+                        if e.errno != errno.ENOENT:
+                            raise
+                    if procs is None:
+                        # Fall back to fuser if lsof is unavailable
+                        try:
+                            procs = subprocess.check_output(["fuser", '-v', lockfile], stderr=subprocess.STDOUT)
+                        except OSError as e:
+                            if e.errno != errno.ENOENT:
+                                raise
+
+                    msg = "Delaying shutdown due to active processes which appear to be holding bitbake.lock"
+                    if procs:
+                        msg += ":\n%s" % str(procs)
+                    print(msg)
 
     def shutdown(self, force = False):
         if force:
@@ -1406,6 +1519,7 @@ class CookerExit(bb.event.Event):
 class CookerCollectFiles(object):
     def __init__(self, priorities):
         self.appendlist = {}
+        self.bbappends = []
         self.appliedappendlist = []
         self.bbfile_config_priorities = priorities
 
@@ -1500,6 +1614,7 @@ class CookerCollectFiles(object):
         # Build a list of .bbappend files for each .bb file
         for f in bbappend:
             base = os.path.basename(f).replace('.bbappend', '.bb')
+            self.bbappends.append((base, f))
             if not base in self.appendlist:
                self.appendlist[base] = []
             if f not in self.appendlist[base]:
@@ -1525,11 +1640,11 @@ class CookerCollectFiles(object):
         """
         filelist = []
         f = os.path.basename(fn)
-        for bbappend in self.appendlist:
+        for b in self.bbappends:
+            (bbappend, filename) = b
             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)
+                filelist.append(filename)
         return filelist
 
     def collection_priorities(self, pkgfns):
@@ -1549,10 +1664,10 @@ class CookerCollectFiles(object):
                 unmatched.add(regex)
 
         def findmatch(regex):
-            for bbfile in self.appendlist:
-                for append in self.appendlist[bbfile]:
-                    if regex.match(append):
-                        return True
+            for b in self.bbappends:
+                (bbfile, append) = b
+                if regex.match(append):
+                    return True
             return False
 
         for unmatch in unmatched.copy():
@@ -1861,7 +1976,7 @@ class CookerParser(object):
                 self.skipped += 1
                 self.cooker.skiplist[virtualfn] = SkippedPackage(info_array[0])
             self.bb_cache.add_info(virtualfn, info_array, self.cooker.recipecache,
-                                        parsed=parsed)
+                                        parsed=parsed, watcher = self.cooker.add_filewatch)
         return True
 
     def reparse(self, filename):

bitbake/lib/bb/cookerdata.py

@@ -69,6 +69,17 @@ class ConfigParameters(object):
             if bbpkgs:
                 self.options.pkgs_to_build.extend(bbpkgs.split())
 
+    def updateToServer(self, server):
+        options = {}
+        for o in ["abort", "tryaltconfigs", "force", "invalidate_stamp", 
+                  "verbose", "debug", "dry_run", "dump_signatures", 
+                  "debug_domains", "extra_assume_provided", "profile"]:
+            options[o] = getattr(self.options, o)
+
+        ret, error = server.runCommand(["updateConfig", options])
+        if error:
+                raise Exception("Unable to update the server configuration with local parameters: %s" % error)
+
     def parseActions(self):
         # Parse any commandline into actions
         action = {'action':None, 'msg':None}

bitbake/lib/bb/data.py

@@ -219,6 +219,13 @@ def emit_var(var, o=sys.__stdout__, d = init(), all=False):
 
     val = str(val)
 
+    if varExpanded.startswith("BASH_FUNC_"):
+        varExpanded = varExpanded[10:-2]
+        val = val[3:] # Strip off "() "
+        o.write("%s() %s\n" % (varExpanded, val))
+        o.write("export -f %s\n" % (varExpanded))
+        return 1
+
     if func:
         # NOTE: should probably check for unbalanced {} within the var
         o.write("%s() {\n%s\n}\n" % (varExpanded, val))
@@ -231,6 +238,7 @@ def emit_var(var, o=sys.__stdout__, d = init(), all=False):
     # to a shell, we need to escape the quotes in the var
     alter = re.sub('"', '\\"', val)
     alter = re.sub('\n', ' \\\n', alter)
+    alter = re.sub('\\$', '\\\\$', alter)
     o.write('%s="%s"\n' % (varExpanded, alter))
     return 0
 

bitbake/lib/bb/data_smart.py

@@ -263,7 +263,7 @@ class VariableHistory(object):
                     flag = ''
                 o.write("#   %s %s:%s%s\n#     %s\"%s\"\n" % (event['op'], event['file'], event['line'], display_func, flag, re.sub('\n', '\n#     ', event['detail'])))
             if len(history) > 1:
-                o.write("# computed:\n")
+                o.write("# pre-expansion value:\n")
                 o.write('#   "%s"\n' % (commentVal))
         else:
             o.write("#\n# $%s\n#   [no history recorded]\n#\n" % var)
@@ -616,8 +616,10 @@ class DataSmart(MutableMapping):
                 cachename = var + "[" + flag + "]"
             value = self.expand(value, cachename)
         if value and flag == "_content" and local_var is not None and "_removeactive" in local_var:
-            filtered = filter(lambda v: v not in local_var["_removeactive"],
-                              value.split(" "))
+            removes = [self.expand(r).split()  for r in local_var["_removeactive"]]
+            removes = reduce(lambda a, b: a+b, removes, [])
+            filtered = filter(lambda v: v not in removes,
+                              value.split())
             value = " ".join(filtered)
             if expand:
                  # We need to ensure the expand cache has the correct value

bitbake/lib/bb/event.py

@@ -55,6 +55,7 @@ def get_class_handlers():
     return _handlers
 
 def set_class_handlers(h):
+    global _handlers
     _handlers = h
 
 def clean_class_handlers():

bitbake/lib/bb/fetch2/__init__.py

@@ -543,8 +543,8 @@ def verify_checksum(ud, d):
 
     if ud.method.recommends_checksum(ud):
         # If strict checking enabled and neither sum defined, raise error
-        strict = d.getVar("BB_STRICT_CHECKSUM", True) or None
-        if strict and not (ud.md5_expected or ud.sha256_expected):
+        strict = d.getVar("BB_STRICT_CHECKSUM", True) or "0"
+        if (strict == "1") and not (ud.md5_expected or ud.sha256_expected):
             logger.error('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,
@@ -936,22 +936,21 @@ def get_checksum_file_list(d):
         ud = fetch.ud[u]
 
         if ud and isinstance(ud.method, local.Local):
-            ud.setup_localpath(d)
-            f = ud.localpath
-            pth = ud.decodedurl
-            if '*' in pth:
-                f = os.path.join(os.path.abspath(f), pth)
-            if f.startswith(dl_dir):
-                # The local fetcher's behaviour is to return a path under DL_DIR if it couldn't find the file anywhere else
-                if os.path.exists(f):
-                    bb.warn("Getting checksum for %s SRC_URI entry %s: file not found except in DL_DIR" % (d.getVar('PN', True), os.path.basename(f)))
-                else:
-                    bb.warn("Unable to get checksum for %s SRC_URI entry %s: file could not be found" % (d.getVar('PN', True), os.path.basename(f)))
-            filelist.append(f)
+            paths = ud.method.localpaths(ud, d)
+            for f in paths:
+                pth = ud.decodedurl
+                if '*' in pth:
+                    f = os.path.join(os.path.abspath(f), pth)
+                if f.startswith(dl_dir):
+                    # The local fetcher's behaviour is to return a path under DL_DIR if it couldn't find the file anywhere else
+                    if os.path.exists(f):
+                        bb.warn("Getting checksum for %s SRC_URI entry %s: file not found except in DL_DIR" % (d.getVar('PN', True), os.path.basename(f)))
+                    else:
+                        bb.warn("Unable to get checksum for %s SRC_URI entry %s: file could not be found" % (d.getVar('PN', True), os.path.basename(f)))
+                filelist.append(f + ":" + str(os.path.exists(f)))
 
     return " ".join(filelist)
 
-
 def get_file_checksums(filelist, pn):
     """Get a list of the checksums for a list of local files
 
@@ -981,6 +980,10 @@ def get_file_checksums(filelist, pn):
 
     checksums = []
     for pth in filelist.split():
+        exist = pth.split(":")[1]
+        if exist == "False":
+            continue
+        pth = pth.split(":")[0]
         if '*' in pth:
             # Handle globs
             for f in glob.glob(pth):
@@ -988,14 +991,12 @@ def get_file_checksums(filelist, pn):
                     checksums.extend(checksum_dir(f))
                 else:
                     checksum = checksum_file(f)
-                    if checksum:
-                        checksums.append((f, checksum))
+                    checksums.append((f, checksum))
         elif os.path.isdir(pth):
             checksums.extend(checksum_dir(pth))
         else:
             checksum = checksum_file(pth)
-            if checksum:
-                checksums.append((pth, checksum))
+            checksums.append((pth, checksum))
 
     checksums.sort(key=operator.itemgetter(1))
     return checksums
@@ -1264,8 +1265,13 @@ class FetchMethod(object):
                     # items.  So, only do so for file:// entries.
                     if urldata.type == "file" and urldata.path.find("/") != -1:
                        destdir = urldata.path.rsplit("/", 1)[0]
+                       if urldata.parm.get('subdir') != None:
+                          destdir = urldata.parm.get('subdir') + "/" + destdir
                     else:
-                       destdir = "."
+                       if urldata.parm.get('subdir') != None:
+                          destdir = urldata.parm.get('subdir')
+                       else:
+                          destdir = "."
                     bb.utils.mkdirhier("%s/%s" % (rootdir, destdir))
                     cmd = 'cp -f %s %s/%s/' % (file, rootdir, destdir)
 

bitbake/lib/bb/fetch2/git.py

@@ -245,7 +245,7 @@ class Git(FetchMethod):
         subdir = ud.parm.get("subpath", "")
         if subdir != "":
             readpathspec = ":%s" % (subdir)
-            def_destsuffix = "%s/" % os.path.basename(subdir)
+            def_destsuffix = "%s/" % os.path.basename(subdir.rstrip('/'))
         else:
             readpathspec = ""
             def_destsuffix = "git/"
@@ -339,7 +339,10 @@ class Git(FetchMethod):
         """
         Compute the HEAD revision for the url
         """
-        search = "refs/heads/%s refs/tags/%s^{}" % (ud.unresolvedrev[name], ud.unresolvedrev[name])
+        if ud.unresolvedrev[name][:5] == "refs/":
+            search = "%s %s^{}" % (ud.unresolvedrev[name], ud.unresolvedrev[name])
+        else:
+            search = "refs/heads/%s refs/tags/%s^{}" % (ud.unresolvedrev[name], ud.unresolvedrev[name])
         output = self._lsremote(ud, d, search)
         return output.split()[0]
 

bitbake/lib/bb/fetch2/local.py

@@ -51,29 +51,41 @@ class Local(FetchMethod):
         """
         Return the local filename of a given url assuming a successful fetch.
         """
+        return self.localpaths(urldata, d)[-1]
+
+    def localpaths(self, urldata, d):
+        """
+        Return the local filename of a given url assuming a successful fetch.
+        """
+        searched = []
         path = urldata.decodedurl
         newpath = path
-        if path[0] != "/":
-            filespath = data.getVar('FILESPATH', d, True)
-            if filespath:
-                logger.debug(2, "Searching for %s in paths:\n    %s" % (path, "\n    ".join(filespath.split(":"))))
-                newpath = bb.utils.which(filespath, path)
-            if not newpath:
-                filesdir = data.getVar('FILESDIR', d, True)
-                if filesdir:
-                    logger.debug(2, "Searching for %s in path: %s" % (path, filesdir))
-                    newpath = os.path.join(filesdir, path)
-            if (not newpath or not os.path.exists(newpath)) and path.find("*") != -1:
-                # For expressions using '*', best we can do is take the first directory in FILESPATH that exists
-                newpath = bb.utils.which(filespath, ".")
-                logger.debug(2, "Searching for %s in path: %s" % (path, newpath))
-                return newpath
-            if not os.path.exists(newpath):
-                dldirfile = os.path.join(d.getVar("DL_DIR", True), path)
-                logger.debug(2, "Defaulting to %s for %s" % (dldirfile, path))
-                bb.utils.mkdirhier(os.path.dirname(dldirfile))
-                return dldirfile
-        return newpath
+        if path[0] == "/":
+            return [path]
+        filespath = data.getVar('FILESPATH', d, True)
+        if filespath:
+            logger.debug(2, "Searching for %s in paths:\n    %s" % (path, "\n    ".join(filespath.split(":"))))
+            newpath, hist = bb.utils.which(filespath, path, history=True)
+            searched.extend(hist)
+        if not newpath:
+            filesdir = data.getVar('FILESDIR', d, True)
+            if filesdir:
+                logger.debug(2, "Searching for %s in path: %s" % (path, filesdir))
+                newpath = os.path.join(filesdir, path)
+                searched.append(newpath)
+        if (not newpath or not os.path.exists(newpath)) and path.find("*") != -1:
+            # For expressions using '*', best we can do is take the first directory in FILESPATH that exists
+            newpath, hist = bb.utils.which(filespath, ".", history=True)
+            searched.extend(hist)
+            logger.debug(2, "Searching for %s in path: %s" % (path, newpath))
+            return searched
+        if not os.path.exists(newpath):
+            dldirfile = os.path.join(d.getVar("DL_DIR", True), path)
+            logger.debug(2, "Defaulting to %s for %s" % (dldirfile, path))
+            bb.utils.mkdirhier(os.path.dirname(dldirfile))
+            searched.append(dldirfile)
+            return searched
+        return searched
 
     def need_update(self, ud, d):
         if ud.url.find("*") != -1:

bitbake/lib/bb/fetch2/perforce.py

@@ -103,22 +103,15 @@ class Perforce(FetchMethod):
     def urldata_init(self, ud, d):
         (host, path, user, pswd, parm) = Perforce.doparse(ud.url, d)
 
-        # If a label is specified, we use that as our filename
-
+        base_path = path.replace('/...', '')
+        base_path = self._strip_leading_slashes(base_path)
+        
         if "label" in parm:
-            ud.localfile = "%s.tar.gz" % (parm["label"])
-            return
+            version = parm["label"]
+        else:
+            version = Perforce.getcset(d, path, host, user, pswd, parm)
 
-        base = path
-        which = path.find('/...')
-        if which != -1:
-            base = path[:which-1]
-
-        base = self._strip_leading_slashes(base)
-
-        cset = Perforce.getcset(d, path, host, user, pswd, parm)
-
-        ud.localfile = data.expand('%s+%s+%s.tar.gz' % (host, base.replace('/', '.'), cset), d)
+        ud.localfile = data.expand('%s+%s+%s.tar.gz' % (host, base_path.replace('/', '.'), version), d)
 
     def download(self, ud, d):
         """

bitbake/lib/bb/monitordisk.py

@@ -239,11 +239,9 @@ class diskMonitor:
                 freeInode = st.f_favail
 
                 if minInode and freeInode < minInode:
-                    # Some fs formats' (e.g., btrfs) statvfs.f_files (inodes) is
-                    # zero, this is a feature of the fs, we disable the inode
-                    # checking for such a fs.
+                    # Some filesystems use dynamic inodes so can't run out
+                    # (e.g. btrfs). This is reported by the inode count being 0.
                     if st.f_files == 0:
-                        logger.info("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,6 +73,11 @@ def update_mtime(f):
     __mtime_cache[f] = os.stat(f)[stat.ST_MTIME]
     return __mtime_cache[f]
 
+def update_cache(f):
+    if f in __mtime_cache:
+        logger.debug(1, "Updating mtime cache for %s" % f)
+        update_mtime(f)
+
 def mark_dependency(d, f):
     if f.startswith('./'):
         f = "%s/%s" % (os.getcwd(), f[2:])

bitbake/lib/bb/parse/ast.py

@@ -226,6 +226,8 @@ class ExportFuncsNode(AstNode):
             if data.getVarFlag(calledfunc, "python"):
                 data.setVar(func, "    bb.build.exec_func('" + calledfunc + "', d)\n")
             else:
+                if "-" in self.classname:
+                   bb.fatal("The classname %s contains a dash character and is calling an sh function %s using EXPORT_FUNCTIONS. Since a dash is illegal in sh function names, this cannot work, please rename the class or don't use EXPORT_FUNCTIONS." % (self.classname, calledfunc))
                 data.setVar(func, "    " + calledfunc + "\n")
             data.setVarFlag(func, 'export_func', '1')
 

bitbake/lib/bb/runqueue.py

@@ -1064,7 +1064,7 @@ class RunQueue:
             retval = self.rqexe.execute()
 
         if self.state is runQueueCleanUp:
-           self.rqexe.finish()
+            retval = self.rqexe.finish()
 
         if (self.state is runQueueComplete or self.state is runQueueFailed) and self.rqexe:
             self.teardown_workers()
@@ -1242,6 +1242,8 @@ class RunQueue:
                 prevh = __find_md5__.search(latestmatch).group(0)
                 output = bb.siggen.compare_sigfiles(latestmatch, match, recursecb)
                 bb.plain("\nTask %s:%s couldn't be used from the cache because:\n  We need hash %s, closest matching task was %s\n  " % (pn, taskname, h, prevh) + '\n  '.join(output))
+            else:
+                bb.plain("Error, can't find multiple tasks at divergence point? Was there a previously run task?")
 
 class RunQueueExecute:
 
@@ -1306,15 +1308,14 @@ class RunQueueExecute:
         if self.stats.active > 0:
             bb.event.fire(runQueueExitWait(self.stats.active), self.cfgData)
             self.rq.read_workers()
-
-            return
+            return self.rq.active_fds()
 
         if len(self.failed_fnids) != 0:
             self.rq.state = runQueueFailed
-            return
+            return True
 
         self.rq.state = runQueueComplete
-        return
+        return True
 
     def check_dependencies(self, task, taskdeps, setscene = False):
         if not self.rq.depvalidate:

bitbake/lib/bb/server/process.py

@@ -135,6 +135,9 @@ class ProcessServer(Process, BaseImplServer):
                     nextsleep = None
                 elif retval is True:
                     nextsleep = None
+                elif isinstance(retval, float):
+                    if (retval < nextsleep):
+                        nextsleep = retval
                 elif nextsleep is None:
                     continue
                 else:

bitbake/lib/bb/server/xmlrpc.py

@@ -241,6 +241,9 @@ class XMLRPCServer(SimpleXMLRPCServer, BaseImplServer):
                         del self._idlefuns[function]
                     elif retval is True:
                         nextsleep = 0
+                    elif isinstance(retval, float):
+                        if (retval < nextsleep):
+                            nextsleep = retval
                     else:
                         fds = fds + retval
                 except SystemExit:

bitbake/lib/bb/siggen.py

@@ -62,6 +62,13 @@ class SignatureGenerator(object):
     def dump_sigs(self, dataCache, options):
         return
 
+    def get_taskdata(self):
+       return (self.runtaskdeps, self.taskhash, self.file_checksum_values)
+
+    def set_taskdata(self, data):
+        self.runtaskdeps, self.taskhash, self.file_checksum_values = data
+
+
 class SignatureGeneratorBasic(SignatureGenerator):
     """
     """
@@ -185,7 +192,8 @@ class SignatureGeneratorBasic(SignatureGenerator):
             checksums = bb.fetch2.get_file_checksums(dataCache.file_checksums[fn][task], recipename)
             for (f,cs) in checksums:
                 self.file_checksum_values[k][f] = cs
-                data = data + cs
+                if cs:
+                    data = data + cs
 
         taint = self.read_taint(fn, task, dataCache.stamp[fn])
         if taint:
@@ -197,12 +205,6 @@ class SignatureGeneratorBasic(SignatureGenerator):
         #d.setVar("BB_TASKHASH_task-%s" % task, taskhash[task])
         return h
 
-    def get_taskdata(self):
-       return (self.runtaskdeps, self.taskhash, self.file_checksum_values)
-
-    def set_taskdata(self, data):
-        self.runtaskdeps, self.taskhash, self.file_checksum_values = data
-
     def dump_sigtask(self, fn, task, stampbase, runtime):
         k = fn + "." + task
         if runtime == "customfile":
@@ -295,10 +297,9 @@ def dump_this_task(outfile, d):
     bb.parse.siggen.dump_sigtask(fn, task, outfile, "customfile")
 
 def clean_basepath(a):
+    b = a.rsplit("/", 2)[1] + a.rsplit("/", 2)[2]
     if a.startswith("virtual:"):
-        b = a.rsplit("/", 1)[1] + ":" + a.rsplit(":", 1)[0]
-    else:
-        b = a.rsplit("/", 1)[1]
+        b = b + ":" + a.rsplit(":", 1)[0]
     return b
 
 def clean_basepaths(a):

bitbake/lib/bb/tests/data.py

@@ -259,6 +259,20 @@ class TestConcatOverride(unittest.TestCase):
         bb.data.update_data(self.d)
         self.assertEqual(self.d.getVar("TEST", True), "")
 
+    def test_remove_expansion(self):
+        self.d.setVar("BAR", "Z")
+        self.d.setVar("TEST", "${BAR}/X Y")
+        self.d.setVar("TEST_remove", "${BAR}/X")
+        bb.data.update_data(self.d)
+        self.assertEqual(self.d.getVar("TEST", True), "Y")
+
+    def test_remove_expansion_items(self):
+        self.d.setVar("TEST", "A B C D")
+        self.d.setVar("BAR", "B D")
+        self.d.setVar("TEST_remove", "${BAR}")
+        bb.data.update_data(self.d)
+        self.assertEqual(self.d.getVar("TEST", True), "A C")
+
 class TestOverrides(unittest.TestCase):
     def setUp(self):
         self.d = bb.data.init()

bitbake/lib/bb/tests/fetch.py

@@ -444,6 +444,13 @@ class FetcherLocalTest(FetcherTest):
         tree = self.fetchUnpack(['file://dir/subdir/e'])
         self.assertEqual(tree, ['dir/subdir/e'])
 
+    def test_local_subdirparam(self):
+        tree = self.fetchUnpack(['file://a;subdir=bar'])
+        self.assertEqual(tree, ['bar/a'])
+
+    def test_local_deepsubdirparam(self):
+        tree = self.fetchUnpack(['file://dir/subdir/e;subdir=bar'])
+        self.assertEqual(tree, ['bar/dir/subdir/e'])
 
 class FetcherNetworkTest(FetcherTest):
 

bitbake/lib/bb/tests/utils.py

@@ -21,6 +21,7 @@
 
 import unittest
 import bb
+import os
 
 class VerCmpString(unittest.TestCase):
 
@@ -51,3 +52,52 @@ class VerCmpString(unittest.TestCase):
         result = bb.utils.explode_dep_versions2("foo ( =1.10 )")
         self.assertEqual(result, correctresult)
 
+    def test_vercmp_string_op(self):
+        compareops = [('1', '1', '=', True),
+                      ('1', '1', '==', True),
+                      ('1', '1', '!=', False),
+                      ('1', '1', '>', False),
+                      ('1', '1', '<', False),
+                      ('1', '1', '>=', True),
+                      ('1', '1', '<=', True),
+                      ('1', '0', '=', False),
+                      ('1', '0', '==', False),
+                      ('1', '0', '!=', True),
+                      ('1', '0', '>', True),
+                      ('1', '0', '<', False),
+                      ('1', '0', '>>', True),
+                      ('1', '0', '<<', False),
+                      ('1', '0', '>=', True),
+                      ('1', '0', '<=', False),
+                      ('0', '1', '=', False),
+                      ('0', '1', '==', False),
+                      ('0', '1', '!=', True),
+                      ('0', '1', '>', False),
+                      ('0', '1', '<', True),
+                      ('0', '1', '>>', False),
+                      ('0', '1', '<<', True),
+                      ('0', '1', '>=', False),
+                      ('0', '1', '<=', True)]
+
+        for arg1, arg2, op, correctresult in compareops:
+            result = bb.utils.vercmp_string_op(arg1, arg2, op)
+            self.assertEqual(result, correctresult, 'vercmp_string_op("%s", "%s", "%s") != %s' % (arg1, arg2, op, correctresult))
+
+        # Check that clearly invalid operator raises an exception
+        self.assertRaises(bb.utils.VersionStringException, bb.utils.vercmp_string_op, '0', '0', '$')
+
+
+class Path(unittest.TestCase):
+    def test_unsafe_delete_path(self):
+        checkitems = [('/', True),
+                      ('//', True),
+                      ('///', True),
+                      (os.getcwd().count(os.sep) * ('..' + os.sep), True),
+                      (os.environ.get('HOME', '/home/test'), True),
+                      ('/home/someone', True),
+                      ('/home/other/', True),
+                      ('/home/other/subdir', False),
+                      ('', False)]
+        for arg1, correctresult in checkitems:
+            result = bb.utils._check_unsafe_delete_path(arg1)
+            self.assertEqual(result, correctresult, '_check_unsafe_delete_path("%s") != %s' % (arg1, correctresult))

bitbake/lib/bb/tinfoil.py

@@ -84,6 +84,11 @@ class Tinfoil:
             else:
                 self.parseRecipes()
 
+    def shutdown(self):
+        self.cooker.shutdown(force=True)
+        self.cooker.post_serve()
+        self.cooker.unlockBitbake()
+
 class TinfoilConfigParameters(ConfigParameters):
 
     def __init__(self, **options):

bitbake/lib/bb/ui/buildinfohelper.py

@@ -979,14 +979,12 @@ class BuildInfoHelper(object):
 
         log_information = {}
         log_information['build'] = self.internal_state['build']
-        if event.levelno >= format.ERROR:
-            log_information['level'] = event.levelno
+        if event.levelno == format.ERROR:
+            log_information['level'] = LogMessage.ERROR
         elif event.levelno == format.WARNING:
             log_information['level'] = LogMessage.WARNING
-        elif event.levelno == format.INFO:
-            log_information['level'] = LogMessage.INFO
         else:
-            log_information['level'] = event.levelno
+            log_information['level'] = LogMessage.INFO
 
         log_information['message'] = event.msg
         log_information['pathname'] = event.pathname

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

@@ -230,10 +230,7 @@ class SimpleSettingsDialog (CrumbsDialog, SettingsUIHelper):
         self.configuration.sstatemirror = ""
         for mirror in self.sstatemirrors_list:
             if mirror[1] != "" and mirror[2].startswith("file://"):
-                if mirror[1].endswith("\\1"):
-                    smirror = mirror[2] + " " + mirror[1] + " \\n "
-                else:
-                    smirror = mirror[2] + " " + mirror[1] + "\\1 \\n "
+                smirror = mirror[2] + " " + mirror[1] + " \\n "
                 self.configuration.sstatemirror += smirror
         self.configuration.bbthread = self.bb_spinner.get_value_as_int()
         self.configuration.pmake = self.pmake_spinner.get_value_as_int()

bitbake/lib/bb/ui/knotty.py

@@ -284,6 +284,7 @@ def main(server, eventHandler, params, tf = TerminalFilter):
 
     if not params.observe_only:
         params.updateFromServer(server)
+        params.updateToServer(server)
         cmdline = params.parseActions()
         if not cmdline:
             print("Nothing to do.  Use 'bitbake world' to build everything, or run 'bitbake --help' for usage information.")
@@ -535,24 +536,29 @@ def main(server, eventHandler, params, tf = TerminalFilter):
             if not params.observe_only:
                 _, error = server.runCommand(["stateForceShutdown"])
             main.shutdown = 2
-    summary = ""
-    if taskfailures:
-        summary += pluralise("\nSummary: %s task failed:",
-                             "\nSummary: %s tasks failed:", len(taskfailures))
-        for failure in taskfailures:
-            summary += "\n  %s" % failure
-    if warnings:
-        summary += pluralise("\nSummary: There was %s WARNING message shown.",
-                             "\nSummary: There were %s WARNING messages shown.", warnings)
-    if return_value and errors:
-        summary += pluralise("\nSummary: There was %s ERROR message shown, returning a non-zero exit code.",
-                             "\nSummary: There were %s ERROR messages shown, returning a non-zero exit code.", errors)
-    if summary:
-        print(summary)
+    try:
+        summary = ""
+        if taskfailures:
+            summary += pluralise("\nSummary: %s task failed:",
+                                 "\nSummary: %s tasks failed:", len(taskfailures))
+            for failure in taskfailures:
+                summary += "\n  %s" % failure
+        if warnings:
+            summary += pluralise("\nSummary: There was %s WARNING message shown.",
+                                 "\nSummary: There were %s WARNING messages shown.", warnings)
+        if return_value and errors:
+            summary += pluralise("\nSummary: There was %s ERROR message shown, returning a non-zero exit code.",
+                                 "\nSummary: There were %s ERROR messages shown, returning a non-zero exit code.", errors)
+        if summary:
+            print(summary)
 
-    if interrupted:
-        print("Execution was interrupted, returning a non-zero exit code.")
-        if return_value == 0:
-            return_value = 1
+        if interrupted:
+            print("Execution was interrupted, returning a non-zero exit code.")
+            if return_value == 0:
+                return_value = 1
+    except IOError as e:
+        import errno
+        if e.errno == errno.EPIPE:
+            pass
 
     return return_value

bitbake/lib/bb/utils.py

@@ -31,6 +31,7 @@ import subprocess
 import glob
 import traceback
 import errno
+import signal
 from commands import getstatusoutput
 from contextlib import contextmanager
 
@@ -386,10 +387,30 @@ def fileslocked(files):
     for lock in locks:
         bb.utils.unlockfile(lock)
 
-def lockfile(name, shared=False, retry=True):
+@contextmanager
+def timeout(seconds):
+    def timeout_handler(signum, frame):
+        pass
+
+    original_handler = signal.signal(signal.SIGALRM, timeout_handler)
+
+    try:
+        signal.alarm(seconds)
+        yield
+    finally:
+        signal.alarm(0)
+        signal.signal(signal.SIGALRM, original_handler)
+
+def lockfile(name, shared=False, retry=True, block=False):
     """
-    Use the file fn as a lock file, return when the lock has been acquired.
-    Returns a variable to pass to unlockfile().
+    Use the specified file as a lock file, return when the lock has
+    been acquired. Returns a variable to pass to unlockfile().
+    Parameters:
+        retry: True to re-try locking if it fails, False otherwise
+        block: True to block until the lock succeeds, False otherwise
+    The retry and block parameters are kind of equivalent unless you
+    consider the possibility of sending a signal to the process to break
+    out - at which point you want block=True rather than retry=True.
     """
     dirname = os.path.dirname(name)
     mkdirhier(dirname)
@@ -402,7 +423,7 @@ def lockfile(name, shared=False, retry=True):
     op = fcntl.LOCK_EX
     if shared:
         op = fcntl.LOCK_SH
-    if not retry:
+    if not retry and not block:
         op = op | fcntl.LOCK_NB
 
     while True:
@@ -575,11 +596,30 @@ def build_environment(d):
         if export:
             os.environ[var] = d.getVar(var, True) or ""
 
+def _check_unsafe_delete_path(path):
+    """
+    Basic safeguard against recursively deleting something we shouldn't. If it returns True,
+    the caller should raise an exception with an appropriate message.
+    NOTE: This is NOT meant to be a security mechanism - just a guard against silly mistakes
+    with potentially disastrous results.
+    """
+    extra = ''
+    # HOME might not be /home/something, so in case we can get it, check against it
+    homedir = os.environ.get('HOME', '')
+    if homedir:
+        extra = '|%s' % homedir
+    if re.match('(/|//|/home|/home/[^/]*%s)$' % extra, os.path.abspath(path)):
+        return True
+    return False
+
 def remove(path, recurse=False):
     """Equivalent to rm -f or rm -rf"""
     if not path:
         return
     if recurse:
+        for name in glob.glob(path):
+            if _check_unsafe_delete_path(path):
+                raise Exception('bb.utils.remove: called with dangerous path "%s" and recurse=True, refusing to delete!' % path)
         # shutil.rmtree(name) would be ideal but its too slow
         subprocess.call(['rm', '-rf'] + glob.glob(path))
         return
@@ -593,6 +633,8 @@ def remove(path, recurse=False):
 def prunedir(topdir):
     # Delete everything reachable from the directory named in 'topdir'.
     # CAUTION:  This is dangerous!
+    if _check_unsafe_delete_path(topdir):
+        raise Exception('bb.utils.prunedir: called with dangerous path "%s", refusing to delete!' % topdir)
     for root, dirs, files in os.walk(topdir, topdown = False):
         for name in files:
             os.remove(os.path.join(root, name))

bitbake/lib/progressbar.py

@@ -1,4 +1,4 @@
-#!/usr/bin/python
+#!/usr/bin/env python
 # -*- coding: iso-8859-1 -*-
 #
 # progressbar  - Text progressbar library for python.

bitbake/lib/prserv/db.py

@@ -19,6 +19,7 @@ class PRTable(object):
     def __init__(self, conn, table, nohist):
         self.conn = conn
         self.nohist = nohist
+        self.dirty = False
         if nohist:
             self.table = "%s_nohist" % table 
         else:
@@ -47,6 +48,11 @@ class PRTable(object):
         self.conn.commit()
         self._execute("BEGIN EXCLUSIVE TRANSACTION")
 
+    def sync_if_dirty(self):
+        if self.dirty:
+            self.sync()
+            self.dirty = False
+
     def _getValueHist(self, version, pkgarch, checksum):
         data=self._execute("SELECT value FROM %s WHERE version=? AND pkgarch=? AND checksum=?;" % self.table,
                            (version, pkgarch, checksum))
@@ -62,6 +68,8 @@ class PRTable(object):
             except sqlite3.IntegrityError as exc:
                 logger.error(str(exc))
 
+            self.dirty = True
+
             data=self._execute("SELECT value FROM %s WHERE version=? AND pkgarch=? AND checksum=?;" % self.table,
                                (version, pkgarch, checksum))
             row=data.fetchone()
@@ -89,6 +97,8 @@ class PRTable(object):
                 logger.error(str(exc))
                 self.conn.rollback()
 
+            self.dirty = True
+
             data=self._execute("SELECT value FROM %s WHERE version=? AND pkgarch=? AND checksum=?;" % self.table,
                                (version, pkgarch, checksum))
             row=data.fetchone()
@@ -118,6 +128,8 @@ class PRTable(object):
             except sqlite3.IntegrityError as exc:
                 logger.error(str(exc))
 
+            self.dirty = True
+
             data = self._execute("SELECT value FROM %s WHERE version=? AND pkgarch=? AND checksum=?;" % self.table,
                            (version, pkgarch, checksum))
             row = data.fetchone()
@@ -139,6 +151,8 @@ class PRTable(object):
             except sqlite3.IntegrityError as exc:
                 logger.error(str(exc))
 
+        self.dirty = True
+
         data = self._execute("SELECT value FROM %s WHERE version=? AND pkgarch=? AND checksum=? AND value>=?;" % self.table,
                             (version,pkgarch,checksum,value))
         row=data.fetchone()
@@ -221,6 +235,7 @@ class PRData(object):
         self.connection=sqlite3.connect(self.filename, isolation_level="EXCLUSIVE", check_same_thread = False)
         self.connection.row_factory=sqlite3.Row
         self.connection.execute("pragma synchronous = off;")
+        self.connection.execute("PRAGMA journal_mode = WAL;")
         self._tables={}
 
     def __del__(self):

bitbake/lib/prserv/serv.py

@@ -38,8 +38,17 @@ singleton = None
 class PRServer(SimpleXMLRPCServer):
     def __init__(self, dbfile, logfile, interface, daemon=True):
         ''' constructor '''
-        SimpleXMLRPCServer.__init__(self, interface,
-                                    logRequests=False, allow_none=True)
+        import socket
+        try:
+            SimpleXMLRPCServer.__init__(self, interface,
+                                        logRequests=False, allow_none=True)
+        except socket.error:
+            ip=socket.gethostbyname(interface[0])
+            port=interface[1]
+            msg="PR Server unable to bind to %s:%s\n" % (ip, port)
+            sys.stderr.write(msg)
+            raise PRServiceConfigError
+
         self.dbfile=dbfile
         self.daemon=daemon
         self.logfile=logfile
@@ -67,15 +76,27 @@ class PRServer(SimpleXMLRPCServer):
         In addition, exception handling is done here.
 
         """
-        while True:
-            (request, client_address) = self.requestqueue.get()
+        iter_count = 1
+        # 60 iterations between syncs or sync if dirty every ~30 seconds
+        iterations_between_sync = 60
+
+        while not self.quit:
+            try:
+                (request, client_address) = self.requestqueue.get(True, 30)
+            except Queue.Empty:
+                self.table.sync_if_dirty()
+                continue
             try:
                 self.finish_request(request, client_address)
                 self.shutdown_request(request)
+                iter_count = (iter_count + 1) % iterations_between_sync
+                if iter_count == 0:
+                    self.table.sync_if_dirty()
             except:
                 self.handle_error(request, client_address)
                 self.shutdown_request(request)
                 self.table.sync()
+            self.table.sync_if_dirty()
 
     def process_request(self, request, client_address):
         self.requestqueue.put((request, client_address))
@@ -120,7 +141,7 @@ class PRServer(SimpleXMLRPCServer):
         self.handlerthread.start()
         while not self.quit:
             self.handle_request()
-
+        self.handlerthread.join()
         self.table.sync()
         logger.info("PRServer: stopping...")
         self.server_close()

bitbake/lib/toaster/toastergui/views.py

@@ -742,7 +742,6 @@ class LazyEncoder(json.JSONEncoder):
         return super(LazyEncoder, self).default(obj)
 
 from toastergui.templatetags.projecttags import filtered_filesizeformat
-from django import template
 import os
 def _get_dir_entries(build_id, target_id, start):
     node_str = {
@@ -797,9 +796,7 @@ def _get_dir_entries(build_id, target_id, start):
                 # don't use resolved path from above, show immediate link-to
                 if o.sym_target_id != "" and o.sym_target_id != None:
                     entry['link_to'] = Target_File.objects.get(pk=o.sym_target_id).path
-            t = template.Template('{% load projecttags %} {{ size|filtered_filesizeformat }}')
-            c = template.Context({'size': o.size})
-            entry['size'] = str(t.render(c))
+            entry['size'] = filtered_filesizeformat(o.size)
             if entry['link_to'] != None:
                 entry['permission'] = node_str[o.inodetype] + o.permission
             else:
@@ -808,7 +805,10 @@ def _get_dir_entries(build_id, target_id, start):
             entry['group'] = o.group
             response.append(entry)
 
-        except:
+        except Exception as e:
+            print "Exception ", e
+            import traceback
+            traceback.print_exc(e)
             pass
 
     # sort by directories first, then by name

documentation/adt-manual/adt-command.xml

@@ -177,7 +177,7 @@
             Thus, the following command works:
             <literallayout class='monospaced'>
      $ ./configure --host=armv5te-poky-linux-gnueabi \
-        --with-libtool-sysroot=&lt;sysroot-dir&gt;
+        --with-libtool-sysroot=<replaceable>sysroot-dir</replaceable>
             </literallayout>
         </para>
 
@@ -186,13 +186,13 @@
             cross-toolchain tools.
             <note>
                 If the <filename>configure</filename> script results in problems recognizing the
-                <filename>--with-libtool-sysroot=&lt;sysroot-dir&gt;</filename> option,
+                <filename>--with-libtool-sysroot=</filename><replaceable>sysroot-dir</replaceable> option,
                 regenerate the script to enable the support by doing the following and then
                 run the script again:
                 <literallayout class='monospaced'>
      $ libtoolize --automake
      $ aclocal -I ${OECORE_NATIVE_SYSROOT}/usr/share/aclocal \
-        [-I &lt;dir_containing_your_project-specific_m4_macros&gt;]
+        [-I <replaceable>dir_containing_your_project-specific_m4_macros</replaceable>]
      $ autoconf
      $ autoheader
      $ automake -a

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

@@ -1,7 +1,7 @@
 <?xml version='1.0'?>
 <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/1999/xhtml" xmlns:fo="http://www.w3.org/1999/XSL/Format" version="1.0">
 
-  <xsl:import href="http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl" />
+  <xsl:import href="http://docbook.sourceforge.net/release/xsl/1.76.1/xhtml/docbook.xsl" />
 
   <xsl:include href="../template/permalinks.xsl"/>
   <xsl:include href="../template/section.title.xsl"/>

documentation/adt-manual/adt-manual.xml

@@ -78,9 +78,24 @@
             </revision>
             <revision>
                 <revnumber>1.7</revnumber>
-                <date>Fall of 2014</date>
+                <date>October 2014</date>
                 <revremark>Released with the Yocto Project 1.7 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>1.7.1</revnumber>
+                <date>January 2015</date>
+                <revremark>Released with the Yocto Project 1.7.1 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.7.2</revnumber>
+                <date>June 2015</date>
+                <revremark>Released with the Yocto Project 1.7.2 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.7.3</revnumber>
+                <date>November 2015</date>
+                <revremark>Released with the Yocto Project 1.7.3 Release.</revremark>
+            </revision>
        </revhistory>
 
     <copyright>

documentation/adt-manual/adt-package.xml

@@ -80,17 +80,17 @@
         Next, source the environment setup script found in the
         <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
         Follow that by setting up the installation destination to point to your
-        sysroot as <filename>&lt;sysroot_dir&gt;</filename>.
-        Finally, have an OPKG configuration file <filename>&lt;conf_file&gt;</filename>
+        sysroot as <replaceable>sysroot_dir</replaceable>.
+        Finally, have an OPKG configuration file <replaceable>conf_file</replaceable>
         that corresponds to the <filename>opkg</filename> repository you have just created.
         The following command forms should now work:
         <literallayout class='monospaced'>
-     $ opkg-cl –f &lt;conf_file&gt; -o &lt;sysroot_dir&gt; update
-     $ opkg-cl –f &lt;cconf_file&gt; -o &lt;sysroot_dir&gt; \
+     $ opkg-cl –f <replaceable>conf_file</replaceable> -o <replaceable>sysroot_dir</replaceable> update
+     $ opkg-cl –f <replaceable>cconf_file</replaceable> -o <replaceable>sysroot_dir</replaceable> \
         --force-overwrite install libglade
-     $ opkg-cl –f &lt;cconf_file&gt; -o &lt;sysroot_dir&gt; \
+     $ opkg-cl –f <replaceable>cconf_file</replaceable> -o <replaceable>sysroot_dir</replaceable> \
         --force-overwrite install libglade-dbg
-     $ opkg-cl –f &lt;conf_file&gt; -o &lt;sysroot_dir&gt; \
+     $ opkg-cl –f <replaceable>conf_file&gt; -o </replaceable>sysroot_dir&gt; \
         --force-overwrite install libglade-dev
         </literallayout>
     </para>

documentation/adt-manual/adt-prepare.xml

@@ -183,20 +183,20 @@
                             Please make sure you understand the security implications of doing this.
                             You might also have to modify your firewall settings to allow
                             NFS booting to work.</note></para></listitem>
-                    <listitem><para><filename>YOCTOADT_ROOTFS_&lt;arch&gt;</filename>: The root
+                    <listitem><para><filename>YOCTOADT_ROOTFS_</filename><replaceable>arch</replaceable>: The root
                         filesystem images you want to download from the
                         <filename>YOCTOADT_IPKG_REPO</filename> repository.</para></listitem>
-                    <listitem><para><filename>YOCTOADT_TARGET_SYSROOT_IMAGE_&lt;arch&gt;</filename>: The
+                    <listitem><para><filename>YOCTOADT_TARGET_SYSROOT_IMAGE_</filename><replaceable>arch</replaceable>: The
                         particular root filesystem used to extract and create the target sysroot.
                         The value of this variable must have been specified with
-                        <filename>YOCTOADT_ROOTFS_&lt;arch&gt;</filename>.
+                        <filename>YOCTOADT_ROOTFS_</filename><replaceable>arch</replaceable>.
                         For example, if you downloaded both <filename>minimal</filename> and
                         <filename>sato-sdk</filename> images by setting
-                        <filename>YOCTOADT_ROOTFS_&lt;arch&gt;</filename>
-                        to "minimal sato-sdk", then <filename>YOCTOADT_ROOTFS_&lt;arch&gt;</filename>
+                        <filename>YOCTOADT_ROOTFS_</filename><replaceable>arch</replaceable>
+                        to "minimal sato-sdk", then <filename>YOCTOADT_ROOTFS_</filename><replaceable>arch</replaceable>
                         must be set to either "minimal" or "sato-sdk".
                         </para></listitem>
-                    <listitem><para><filename>YOCTOADT_TARGET_SYSROOT_LOC_&lt;arch&gt;</filename>: The
+                    <listitem><para><filename>YOCTOADT_TARGET_SYSROOT_LOC_</filename><replaceable>arch</replaceable>: The
                         location on the development host where the target sysroot is created.
                         </para></listitem>
                 </itemizedlist>
@@ -212,7 +212,7 @@
                 Once the installer begins to run, you are asked to enter the
                 location for cross-toolchain installation.
                 The default location is
-                <filename>/opt/poky/&lt;release&gt;</filename>.
+                <filename>/opt/poky/</filename><replaceable>release</replaceable>.
                 After either accepting the default location or selecting your
                 own location, you are prompted to run the installation script
                 interactively or in silent mode.
@@ -230,7 +230,7 @@
                 <filename>adt-installer</filename> directory according to your
                 installer configurations, and the target sysroot located
                 according to the
-                <filename>YOCTOADT_TARGET_SYSROOT_LOC_&lt;arch&gt;</filename>
+                <filename>YOCTOADT_TARGET_SYSROOT_LOC_</filename><replaceable>arch</replaceable>
                 variable also in your configuration file.
             </para>
          </section>
@@ -276,7 +276,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-glibc-x86_64-core-image-sato-i586-toolchain-&DISTRO;.sh
                             </literallayout></para></listitem>
                         <listitem><para>Build your own toolchain installer.
                             For cases where you cannot use an installer
@@ -296,7 +296,7 @@
                     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-glibc-x86_64-core-image-sato-i586-toolchain-&DISTRO;.sh
                     </literallayout>
                     The first thing the installer prompts you for is the
                     directory into which you want to install the toolchain.
@@ -593,7 +593,7 @@
                 section.
                 </para></listitem>
             <listitem><para>
-                Use <filename>bitbake &lt;image&gt; -c populate_sdk</filename>.
+                Use <filename>bitbake</filename> <replaceable>image</replaceable> <filename>-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.
@@ -656,10 +656,10 @@
             <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
+            Following is an example using <filename>glibc</filename> static
             development libraries:
             <literallayout class='monospaced'>
-     IMAGE_INSTALL_append = " eglibc-staticdev"
+     IMAGE_INSTALL_append = " glibc-staticdev"
             </literallayout>
         </note>
     </para>

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

@@ -1,7 +1,7 @@
 <?xml version='1.0'?>
 <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/1999/xhtml" xmlns:fo="http://www.w3.org/1999/XSL/Format" version="1.0">
 
-  <xsl:import href="http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl" />
+  <xsl:import href="http://docbook.sourceforge.net/release/xsl/1.76.1/xhtml/docbook.xsl" />
 
   <xsl:include href="../template/permalinks.xsl"/>
   <xsl:include href="../template/section.title.xsl"/>

documentation/bsp-guide/bsp-guide.xml

@@ -90,9 +90,24 @@
             </revision>
             <revision>
                 <revnumber>1.7</revnumber>
-                <date>Fall of 2014</date>
+                <date>October 2014</date>
                 <revremark>Released with the Yocto Project 1.7 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>1.7.1</revnumber>
+                <date>January 2015</date>
+                <revremark>Released with the Yocto Project 1.7.1 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.7.2</revnumber>
+                <date>June 2015</date>
+                <revremark>Released with the Yocto Project 1.7.2 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.7.3</revnumber>
+                <date>November 2015</date>
+                <revremark>Released with the Yocto Project 1.7.3 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>

documentation/bsp-guide/bsp.xml

@@ -1351,7 +1351,7 @@
                         <listitem><para>By default, the script creates the new BSP Layer in the
                             current working directory of the
                             <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>,
-                            which is <filename>poky</filename> in this case.
+                            (i.e. <filename>poky/build</filename>).
                             </para></listitem>
                     </orderedlist>
                 </para>

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

@@ -1,7 +1,7 @@
 <?xml version='1.0'?>
 <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/1999/xhtml" xmlns:fo="http://www.w3.org/1999/XSL/Format" version="1.0">
 
-  <xsl:import href="http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl" />
+  <xsl:import href="http://docbook.sourceforge.net/release/xsl/1.76.1/xhtml/docbook.xsl" />
 
   <xsl:include href="../template/permalinks.xsl"/>
   <xsl:include href="../template/section.title.xsl"/>

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

@@ -5,7 +5,7 @@
 <chapter id='dev-manual-intro'>
 
 <title>The Yocto Project Development Manual</title>
-    <section id='intro'>
+    <section id='dev-intro'>
         <title>Introduction</title>
 
         <para>

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

@@ -279,20 +279,35 @@
                 Within this group, you will find several kernels supported by
                 the Yocto Project:
                 <itemizedlist>
-                    <listitem><para><emphasis><filename>linux-yocto-3.4</filename></emphasis> - The
-                    stable Yocto Project kernel to use with the Yocto Project Release 1.3. This kernel
-                    is based on the Linux 3.4 released kernel.</para></listitem>
-                    <listitem><para><emphasis><filename>linux-yocto-3.8</filename></emphasis> - The
-                    stable Yocto Project kernel to use with the Yocto Project Release 1.4. This kernel
-                    is based on the Linux 3.8 released kernel.</para></listitem>
-                    <listitem><para><emphasis><filename>linux-yocto-3.10</filename></emphasis> - The
-                    stable Yocto Project kernel to use with the Yocto Project Release 1.5. This kernel
-                    is based on the Linux 3.10 released kernel.</para></listitem>
-                    <listitem><para><emphasis><filename>linux-yocto-3.14</filename></emphasis> - The
-                    stable Yocto Project kernel to use with the Yocto Project Release 1.6. This kernel
-                    is based on the Linux 3.14 released kernel.</para></listitem>
-                    <listitem><para><emphasis><filename>linux-yocto-dev</filename></emphasis> - A development
-                    kernel based on the latest upstream release candidate available.</para></listitem>
+                    <listitem><para><emphasis>
+                        <filename>linux-yocto-3.8</filename></emphasis> - The
+                        stable Yocto Project kernel to use with the Yocto
+                        Project Release 1.4. This kernel is based on the
+                        Linux 3.8 released kernel.
+                        </para></listitem>
+                    <listitem><para><emphasis>
+                        <filename>linux-yocto-3.10</filename></emphasis> - The
+                        stable Yocto Project kernel to use with the Yocto
+                        Project Release 1.5.
+                        This kernel is based on the Linux 3.10 released kernel.
+                        </para></listitem>
+                    <listitem><para><emphasis>
+                        <filename>linux-yocto-3.14</filename></emphasis> - The
+                        stable Yocto Project kernel to use with the Yocto
+                        Project Releases 1.6 and 1.7.
+                        This kernel is based on the Linux 3.14 released kernel.
+                        </para></listitem>
+                    <listitem><para><emphasis>
+                        <filename>linux-yocto-3.17</filename></emphasis> - An
+                        additional Yocto Project kernel used with the Yocto
+                        Project Release 1.7.
+                        This kernel is based on the Linux 3.17 released kernel.
+                        </para></listitem>
+                    <listitem><para><emphasis>
+                        <filename>linux-yocto-dev</filename></emphasis> - A
+                        development kernel based on the latest upstream release
+                        candidate available.
+                        </para></listitem>
                 </itemizedlist>
             </para>
 

documentation/dev-manual/dev-manual-qemu.xml

@@ -349,19 +349,19 @@
                 <listitem><para><emphasis><filename>start</filename>:</emphasis>
                     Starts the NFS share:
                     <literallayout class='monospaced'>
-     runqemu-export-rootfs start &lt;<replaceable>file-system-location</replaceable>&gt;
+     runqemu-export-rootfs start <replaceable>file-system-location</replaceable>
                     </literallayout>
                     </para></listitem>
                 <listitem><para><emphasis><filename>stop</filename>:</emphasis>
                     Stops the NFS share:
                     <literallayout class='monospaced'>
-     runqemu-export-rootfs stop &lt;<replaceable>file-system-location</replaceable>&gt;
+     runqemu-export-rootfs stop <replaceable>file-system-location</replaceable>
                     </literallayout>
                     </para></listitem>
                 <listitem><para><emphasis><filename>restart</filename>:</emphasis>
                     Restarts the NFS share:
                     <literallayout class='monospaced'>
-     runqemu-export-rootfs restart &lt;<replaceable>file-system-location</replaceable>&gt;
+     runqemu-export-rootfs restart <replaceable>file-system-location</replaceable>
                     </literallayout>
                     </para></listitem>
             </itemizedlist>
@@ -379,7 +379,7 @@
             <listitem><para><emphasis>Switching Between Consoles:</emphasis>
                 When booting or running QEMU, you can switch between
                 supported consoles by using
-                Ctrl+Alt+&lt;<replaceable>number</replaceable>&gt;.
+                Ctrl+Alt+<replaceable>number</replaceable>.
                 For example, Ctrl+Alt+3 switches you to the serial console as
                 long as that console is enabled.
                 Being able to switch consoles is helpful, for example, if the

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

@@ -190,13 +190,13 @@
      Resolving deltas: 100% (260/260), done.
                </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>
+                The Yocto Project supports many BSPs, which are maintained in
+                their own layers or in layers designed to contain several
+                BSPs.
+                To get an idea of machine support through BSP layers, you can
+                look at the
+                <ulink url='&YOCTO_RELEASE_DL_URL;/machines'>index of machines</ulink>
+                for the release.</para>
 
                 <para>The Yocto Project uses the following BSP layer naming
                 scheme:
@@ -214,18 +214,18 @@
                 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>
+                Developer's Guide for more information on BSP Layers.</para>
 
-                <para>
+                <para>A useful Git repository released with the Yocto
+                Project is <filename>meta-intel</filename>, which is a
+                parent layer that contains many supported
+                <ulink url='&YOCTO_DOCS_BSP_URL;#bsp-layers'>BSP Layers</ulink>.
                 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>
+                <ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink>.</para>
 
-                <para>
-                Using
+                <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.
@@ -252,11 +252,9 @@
      remote: Total 8844 (delta 4931), reused 8780 (delta 4867)
      Receiving objects: 100% (8844/8844), 2.48 MiB | 264 KiB/s, done.
      Resolving deltas: 100% (4931/4931), done.
-                </literallayout>
-                </para>
+                </literallayout></para>
 
-                <para>
-                The same
+                <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.

documentation/dev-manual/dev-manual.xml

@@ -68,9 +68,24 @@
             </revision>
             <revision>
                 <revnumber>1.7</revnumber>
-                <date>Fall of 2014</date>
+                <date>October 2014</date>
                 <revremark>Released with the Yocto Project 1.7 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>1.7.1</revnumber>
+                <date>January 2015</date>
+                <revremark>Released with the Yocto Project 1.7.1 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.7.2</revnumber>
+                <date>June 2015</date>
+                <revremark>Released with the Yocto Project 1.7.2 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.7.3</revnumber>
+                <date>November 2015</date>
+                <revremark>Released with the Yocto Project 1.7.3 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>

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

@@ -214,7 +214,7 @@
             Here is an example that shows a trivial tree of kernel Metadata
             stored in recipe-space within a BSP layer:
             <literallayout class='monospaced'>
-     meta-my_bsp_layer/
+     meta-<replaceable>my_bsp_layer</replaceable>/
      `-- recipes-kernel
          `-- linux
              `-- linux-yocto
@@ -370,7 +370,7 @@
         of Metadata.
         The following Metadata file hierarchy is recommended:
         <literallayout class='monospaced'>
-     &lt;base&gt;/
+     <replaceable>base</replaceable>/
         bsp/
         cfg/
         features/
@@ -513,7 +513,7 @@
         patch mypatch.patch
 
      patches/mypatch.patch:
-        &lt;typical-patch&gt;
+        <replaceable>typical-patch</replaceable>
             </literallayout>
             You can create the typical <filename>.patch</filename>
             file using <filename>diff -Nurp</filename> or
@@ -968,37 +968,38 @@
             hierarchical branching system similar to what the linux-yocto Linux
             kernel repositories use:
             <literallayout class='monospaced'>
-     &lt;common&gt;/&lt;kernel_type&gt;/&lt;machine&gt;
+     <replaceable>common</replaceable>/<replaceable>kernel_type</replaceable>/<replaceable>machine</replaceable>
             </literallayout>
         </para>
 
         <para>
             If you had two kernel types, "standard" and "small" for
-            instance, and three machines, the branches in your
+            instance, three machines, and <replaceable>common</replaceable>
+            as <filename>mydir</filename>, the branches in your
             Git repository might look like this:
             <literallayout class='monospaced'>
-     common/base
-     common/standard/base
-     common/standard/machine_a
-     common/standard/machine_b
-     common/standard/machine_c
-     common/small/base
-     common/small/machine_a
+     mydir/base
+     mydir/standard/base
+     mydir/standard/machine_a
+     mydir/standard/machine_b
+     mydir/standard/machine_c
+     mydir/small/base
+     mydir/small/machine_a
             </literallayout>
         </para>
 
         <para>
             This organization can help clarify the branch relationships.
-            In this case, <filename>common/standard/machine_a</filename>
-            includes everything in <filename>common/base</filename> and
-            <filename>common/standard/base</filename>.
+            In this case, <filename>mydir/standard/machine_a</filename>
+            includes everything in <filename>mydir/base</filename> and
+            <filename>mydir/standard/base</filename>.
             The "standard" and "small" branches add sources specific to those
             kernel types that for whatever reason are not appropriate for the
             other branches.
             <note>The "base" branches are an artifact of the way Git manages
                 its data internally on the filesystem: Git will not allow you
-                to use <filename>common/standard</filename> and
-                <filename>common/standard/machine_a</filename> because it
+                to use <filename>mydir/standard</filename> and
+                <filename>mydir/standard/machine_a</filename> because it
                 would have to create a file and a directory named "standard".
             </note>
         </para>

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

@@ -88,7 +88,7 @@
                 recipe, the append file will typically be located as follows
                 within your custom layer:
                 <literallayout class='monospaced'>
-     &lt;your-layer&gt;/recipes-kernel/linux/linux-yocto_3.4.bbappend
+     <replaceable>your-layer</replaceable>/recipes-kernel/linux/linux-yocto_3.4.bbappend
                 </literallayout>
                 The append file should initially extend the
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESPATH'><filename>FILESPATH</filename></ulink>
@@ -107,7 +107,7 @@
                 described above, you must place the files in your layer in the
                 following area:
                 <literallayout class='monospaced'>
-     &lt;your-layer&gt;/recipes-kernel/linux/linux-yocto/
+     <replaceable>your-layer</replaceable>/recipes-kernel/linux/linux-yocto/
                 </literallayout>
                 <note>If you are working on a new machine Board Support Package
                     (BSP), be sure to refer to the

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

@@ -1,7 +1,7 @@
 <?xml version='1.0'?>
 <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/1999/xhtml" xmlns:fo="http://www.w3.org/1999/XSL/Format" version="1.0">
 
-  <xsl:import href="http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl" />
+  <xsl:import href="http://docbook.sourceforge.net/release/xsl/1.76.1/xhtml/docbook.xsl" />
 
   <xsl:include href="../template/permalinks.xsl"/>
   <xsl:include href="../template/section.title.xsl"/>

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

@@ -88,7 +88,7 @@
                     feature description in an <filename>.scc</filename> file
                     whose name follows this format:
                     <literallayout class='monospaced'>
-     &lt;bsp_name&gt;-&lt;kernel_type&gt;.scc
+     <replaceable>bsp_name</replaceable>-<replaceable>kernel_type</replaceable>.scc
                     </literallayout>
                 </para></listitem>
                 <listitem><para>Once located, the feature description is either compiled into a simple script
@@ -157,7 +157,7 @@
             <listitem><para>A BSP build branch exists.
                 This branch has the following form:
                 <literallayout class='monospaced'>
-     &lt;kernel_type&gt;/&lt;bsp_name&gt;
+     <replaceable>kernel_type</replaceable>/<replaceable>bsp_name</replaceable>
                 </literallayout></para></listitem>
         </itemizedlist>
 
@@ -194,7 +194,7 @@
             <filename>${MACHINE}</filename> is the metadata name of the machine (BSP) and "kernel_type" is one
             of the Yocto Project supported kernel types (e.g. "standard"):
         <literallayout class='monospaced'>
-     linux-${MACHINE}-&lt;kernel_type&gt;-build
+     linux-${MACHINE}-<replaceable>kernel_type</replaceable>-build
         </literallayout>
         </para>
 

documentation/kernel-dev/kernel-dev.xml

@@ -53,9 +53,24 @@
             </revision>
             <revision>
                 <revnumber>1.7</revnumber>
-                <date>Fall of 2014</date>
+                <date>October 2014</date>
                 <revremark>Released with the Yocto Project 1.7 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>1.7.1</revnumber>
+                <date>January 2015</date>
+                <revremark>Released with the Yocto Project 1.7.1 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.7.2</revnumber>
+                <date>June 2015</date>
+                <revremark>Released with the Yocto Project 1.7.2 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.7.3</revnumber>
+                <date>November 2015</date>
+                <revremark>Released with the Yocto Project 1.7.3 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>

documentation/mega-manual/mega-manual-customization.xsl

@@ -1,7 +1,7 @@
 <?xml version='1.0'?>
 <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/1999/xhtml" xmlns:fo="http://www.w3.org/1999/XSL/Format" version="1.0">
 
-  <xsl:import href="http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl" />
+  <xsl:import href="http://docbook.sourceforge.net/release/xsl/1.76.1/xhtml/docbook.xsl" />
 
   <xsl:param name="generate.toc">
    appendix  toc

documentation/poky.ent

@@ -1,11 +1,11 @@
-<!ENTITY DISTRO "1.7">
-<!ENTITY DISTRO_COMPRESSED "17">
-<!ENTITY DISTRO_NAME "tbd">
-<!ENTITY YOCTO_DOC_VERSION "1.7">
-<!ENTITY POKYVERSION "12.0.0">
-<!ENTITY POKYVERSION_COMPRESSED "1100">
+<!ENTITY DISTRO "1.7.3">
+<!ENTITY DISTRO_COMPRESSED "173">
+<!ENTITY DISTRO_NAME "dizzy">
+<!ENTITY YOCTO_DOC_VERSION "1.7.3">
+<!ENTITY POKYVERSION "12.0.3">
+<!ENTITY POKYVERSION_COMPRESSED "1203">
 <!ENTITY YOCTO_POKY "poky-&DISTRO_NAME;-&POKYVERSION;">
-<!ENTITY COPYRIGHT_YEAR "2010-2014">
+<!ENTITY COPYRIGHT_YEAR "2010-2015">
 <!ENTITY YOCTO_DL_URL "http://downloads.yoctoproject.org">
 <!ENTITY YOCTO_HOME_URL "http://www.yoctoproject.org">
 <!ENTITY YOCTO_LISTS_URL "http://lists.yoctoproject.org">
@@ -14,7 +14,7 @@
 <!ENTITY YOCTO_AB_URL "http://autobuilder.yoctoproject.org">
 <!ENTITY YOCTO_GIT_URL "http://git.yoctoproject.org">
 <!ENTITY YOCTO_ADTREPO_URL "http://adtrepo.yoctoproject.org">
-<!ENTITY YOCTO_RELEASE_NOTES "&YOCTO_HOME_URL;/download/yocto-project-&DISTRO_COMPRESSED;-poky-&POKYVERSION_COMPRESSED;">
+<!ENTITY YOCTO_RELEASE_NOTES "&YOCTO_HOME_URL;/downloads/core/&DISTRO_NAME;&DISTRO_COMPRESSED;">
 <!ENTITY OE_HOME_URL "http://www.openembedded.org">
 <!ENTITY OE_LISTS_URL "http://lists.openembedded.org/mailman">
 <!ENTITY OE_DOCS_URL "http://docs.openembedded.org">
@@ -27,7 +27,7 @@
 <!ENTITY ECLIPSE_INDIGO_URL "&ECLIPSE_DL_URL;/releases/indigo">
 <!ENTITY ECLIPSE_JUNO_URL "&ECLIPSE_DL_URL;/releases/juno">
 <!ENTITY ECLIPSE_KEPLER_URL "&ECLIPSE_DL_URL;/releases/kepler">
-<!ENTITY ECLIPSE_INDIGO_CDT_URL "&ECLIPSE_DL_URL;tools/cdt/releases/indigo">
+<!ENTITY ECLIPSE_INDIGO_CDT_URL "&ECLIPSE_DL_URL;/tools/cdt/releases/indigo">
 <!ENTITY YOCTO_DOCS_URL "&YOCTO_HOME_URL;/docs">
 <!ENTITY YOCTO_SOURCES_URL "&YOCTO_HOME_URL;/sources/">
 <!ENTITY YOCTO_AB_PORT_URL "&YOCTO_AB_URL;:8010">
@@ -35,7 +35,7 @@
 <!ENTITY YOCTO_POKY_URL "&YOCTO_DL_URL;/releases/poky/">
 <!ENTITY YOCTO_RELEASE_DL_URL "&YOCTO_DL_URL;/releases/yocto/yocto-&DISTRO;">
 <!ENTITY YOCTO_TOOLCHAIN_DL_URL "&YOCTO_RELEASE_DL_URL;/toolchain/">
-<!ENTITY YOCTO_ECLIPSE_DL_URL "&YOCTO_RELEASE_DL_URL;/eclipse-plugin/indigo;">
+<!ENTITY YOCTO_ECLIPSE_DL_URL "&YOCTO_RELEASE_DL_URL;/eclipse-plugin/">
 <!ENTITY YOCTO_ADTINSTALLER_DL_URL "&YOCTO_RELEASE_DL_URL;/adt-installer">
 <!ENTITY YOCTO_POKY_DL_URL "&YOCTO_RELEASE_DL_URL;/&YOCTO_POKY;.tar.bz2">
 <!ENTITY YOCTO_MACHINES_DL_URL "&YOCTO_RELEASE_DL_URL;/machines">

documentation/profile-manual/profile-manual-customization.xsl

@@ -1,7 +1,7 @@
 <?xml version='1.0'?>
 <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/1999/xhtml" xmlns:fo="http://www.w3.org/1999/XSL/Format" version="1.0">
 
-  <xsl:import href="http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl" />
+  <xsl:import href="http://docbook.sourceforge.net/release/xsl/1.76.1/xhtml/docbook.xsl" />
 
   <xsl:include href="../template/permalinks.xsl"/>
   <xsl:include href="../template/section.title.xsl"/>

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

@@ -5,7 +5,7 @@
 <chapter id='profile-manual-intro'>
 
 <title>Yocto Project Profiling and Tracing Manual</title>
-    <section id='intro'>
+    <section id='prof-intro'>
         <title>Introduction</title>
 
         <para>

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

@@ -842,7 +842,7 @@
                 idea.  One of the first projects to do this was IBM's DProbes
                 dpcc compiler, an ANSI C compiler which targeted a low-level
                 assembly language running on an in-kernel interpreter on the
-                target system.  This is exactly analagous to what Sun's DTrace
+                target system.  This is exactly analogous to what Sun's DTrace
                 did, except that DTrace invented its own language for the purpose.
                 Systemtap, heavily inspired by DTrace, also created its own
                 one-off language, but rather than running the product on an
@@ -1275,7 +1275,7 @@
             </para>
 
             <informalexample>
-                <emphasis>Tying it Together:</emphasis> The trace events subsystem accomodate static
+                <emphasis>Tying it Together:</emphasis> The trace events subsystem accommodate static
                 and dynamic tracepoints in exactly the same way - there's no
                 difference as far as the infrastructure is concerned.  See the
                 ftrace section for more details on the trace event subsystem.
@@ -2169,7 +2169,7 @@
 
      ### Shell environment set up for builds. ###
 
-     You can now run 'bitbake &lt;target&gt;'
+     You can now run 'bitbake <replaceable>target</replaceable>'
 
      Common targets are:
          core-image-minimal
@@ -3257,15 +3257,25 @@
         <title>Documentation</title>
 
         <para>
-            There doesn't seem to be any current documentation covering
-            LTTng 2.0, but maybe that's because the project is in transition.
-            The LTTng 2.0 website, however, is here:
-            <ulink url='http://lttng.org/lttng2.0'>LTTng Project</ulink>
+            You can find the primary LTTng Documentation on the
+            <ulink url='https://lttng.org/docs/'>LTTng Documentation</ulink>
+            site.
+            The documentation on this site is appropriate for intermediate to
+            advanced software developers who are working in a Linux environment
+            and are interested in efficient software tracing.
         </para>
 
         <para>
-            You can access extensive help information on how to use the
-            LTTng plug-in to search and analyze captured traces via the
+            For information on LTTng in general, visit the
+            <ulink url='http://lttng.org/lttng2.0'>LTTng Project</ulink>
+            site.
+            You can find a "Getting Started" link on this site that takes
+            you to an LTTng Quick Start.
+        </para>
+
+        <para>
+            Finally, you can access extensive help information on how to use
+            the LTTng plug-in to search and analyze captured traces via the
             Eclipse help system:
             <literallayout class='monospaced'>
      Help | Help Contents | LTTng Plug-in User Guide

documentation/profile-manual/profile-manual.xml

@@ -53,9 +53,24 @@
             </revision>
             <revision>
                 <revnumber>1.7</revnumber>
-                <date>Fall of 2014</date>
+                <date>October 2014</date>
                 <revremark>Released with the Yocto Project 1.7 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>1.7.1</revnumber>
+                <date>January 2015</date>
+                <revremark>Released with the Yocto Project 1.7.1 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.7.2</revnumber>
+                <date>June 2015</date>
+                <revremark>Released with the Yocto Project 1.7.2 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.7.3</revnumber>
+                <date>November 2015</date>
+                <revremark>Released with the Yocto Project 1.7.3 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>

documentation/ref-manual/closer-look.xml

@@ -255,7 +255,7 @@
 
         <para>
             When you launch your build with the
-            <filename>bitbake &lt;target&gt;</filename> command, BitBake
+            <filename>bitbake <replaceable>target</replaceable></filename> command, BitBake
             sorts out the configurations to ultimately define your build
             environment.
         </para>
@@ -351,7 +351,7 @@
                 Best practices dictate that you isolate these types of
                 configurations into their own layer.
                 Settings you provide in
-                <filename>conf/distro/&lt;distro&gt;.conf</filename> override
+                <filename>conf/distro/<replaceable>distro</replaceable>.conf</filename> override
                 similar
                 settings that BitBake finds in your
                 <filename>conf/local.conf</filename> file in the Build
@@ -375,7 +375,7 @@
                         This area holds configuration files for the
                         layer (<filename>conf/layer.conf</filename>),
                         the distribution
-                        (<filename>conf/distro/&lt;distro&gt;.conf</filename>),
+                        (<filename>conf/distro/<replaceable>distro</replaceable>.conf</filename>),
                         and any distribution-wide include files.
                         </para></listitem>
                     <listitem><para><emphasis>recipes-*:</emphasis>
@@ -408,7 +408,7 @@
             <para>
                 The BSP Layer's configuration directory contains
                 configuration files for the machine
-                (<filename>conf/machine/&lt;machine&gt;.conf</filename>) and,
+                (<filename>conf/machine/<replaceable>machine</replaceable>.conf</filename>) and,
                 of course, the layer (<filename>conf/layer.conf</filename>).
             </para>
 
@@ -1145,7 +1145,7 @@
         <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>tmp/deploy/images/<replaceable>machine</replaceable>/</filename>
             folder as shown in the figure.
             This folder contains any files expected to be loaded on the
             target device.
@@ -1157,43 +1157,43 @@
             variable points to the appropriate directory containing images for
             the current configuration.
             <itemizedlist>
-                <listitem><para><filename>&lt;kernel-image&gt;</filename>:
+                <listitem><para><filename><replaceable>kernel-image</replaceable></filename>:
                     A kernel binary file.
                     The <link linkend='var-KERNEL_IMAGETYPE'><filename>KERNEL_IMAGETYPE</filename></link>
                     variable setting determines the naming scheme for the
                     kernel image file.
                     Depending on that variable, the file could begin with
                     a variety of naming strings.
-                    The <filename>deploy/images/&lt;machine&gt;</filename>
+                    The <filename>deploy/images/<replaceable>machine</replaceable></filename>
                     directory can contain multiple image files for the
                     machine.</para></listitem>
-                <listitem><para><filename>&lt;root-filesystem-image&gt;</filename>:
+                <listitem><para><filename><replaceable>root-filesystem-image</replaceable></filename>:
                     Root filesystems for the target device (e.g.
                     <filename>*.ext3</filename> or <filename>*.bz2</filename>
                     files).
                     The <link linkend='var-IMAGE_FSTYPES'><filename>IMAGE_FSTYPES</filename></link>
                     variable setting determines the root filesystem image
                     type.
-                    The <filename>deploy/images/&lt;machine&gt;</filename>
+                    The <filename>deploy/images/<replaceable>machine</replaceable></filename>
                     directory can contain multiple root filesystems for the
                     machine.</para></listitem>
-                <listitem><para><filename>&lt;kernel-modules&gt;</filename>:
+                <listitem><para><filename><replaceable>kernel-modules</replaceable></filename>:
                     Tarballs that contain all the modules built for the kernel.
                     Kernel module tarballs exist for legacy purposes and
                     can be suppressed by setting the
                     <link linkend='var-MODULE_TARBALL_DEPLOY'><filename>MODULE_TARBALL_DEPLOY</filename></link>
                     variable to "0".
-                    The <filename>deploy/images/&lt;machine&gt;</filename>
+                    The <filename>deploy/images/<replaceable>machine</replaceable></filename>
                     directory can contain multiple kernel module tarballs
                     for the machine.</para></listitem>
-                <listitem><para><filename>&lt;bootloaders&gt;</filename>:
+                <listitem><para><filename><replaceable>bootloaders</replaceable></filename>:
                     Bootloaders supporting the image, if applicable to the
                     target machine.
-                    The <filename>deploy/images/&lt;machine&gt;</filename>
+                    The <filename>deploy/images/<replaceable>machine</replaceable></filename>
                     directory can contain multiple bootloaders for the
                     machine.</para></listitem>
-                <listitem><para><filename>&lt;symlinks&gt;</filename>:
-                    The <filename>deploy/images/&lt;machine&gt;</filename>
+                <listitem><para><filename><replaceable>symlinks</replaceable></filename>:
+                    The <filename>deploy/images/<replaceable>machine</replaceable></filename>
                     folder contains
                     a symbolic link that points to the most recently built file
                     for each machine.
@@ -1280,7 +1280,7 @@
                     part of the SDK (i.e. the part that runs on
                     the <filename>SDKMACHINE</filename>).
                     When you use
-                    <filename>bitbake -c populate_sdk &lt;imagename&gt;</filename>
+                    <filename>bitbake -c populate_sdk <replaceable>imagename</replaceable></filename>
                     to create the SDK, a set of default packages
                     apply.
                     This variable allows you to add more packages.

documentation/ref-manual/faq.xml

@@ -321,7 +321,7 @@
     <qandaentry>
         <question>
             <para>
-                What’s the difference between <filename>foo</filename> and <filename>foo-native</filename>?
+                What’s the difference between <replaceable>target</replaceable> and <replaceable>target</replaceable><filename>-native</filename>?
             </para>
         </question>
         <answer>

documentation/ref-manual/introduction.xml

@@ -2,7 +2,7 @@
 "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
 [<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
 
-<chapter id='intro'>
+<chapter id='ref-intro'>
 <title>Introduction</title>
 
 <section id='intro-welcome'>
@@ -72,6 +72,10 @@
                 <link linkend='ref-tasks'>Tasks</link>:</emphasis>
                 Describes the tasks defined by the OpenEmbedded build system.
                 </para></listitem>
+            <listitem><para><emphasis>
+                <link linkend='ref-qa-checks'>QA Error and Warning Messages</link>:</emphasis>
+                Lists and describes QA warning and error messages.
+                </para></listitem>
             <listitem><para><emphasis>
                 <link linkend='ref-images'>Images</link>:</emphasis>
                 Describes the standard images that the Yocto Project supports.
@@ -164,6 +168,8 @@
                 <listitem><para>Debian GNU/Linux 7.2 (Wheezy)</para></listitem>
                 <listitem><para>Debian GNU/Linux 7.3 (Wheezy)</para></listitem>
                 <listitem><para>Debian GNU/Linux 7.4 (Wheezy)</para></listitem>
+                <listitem><para>Debian GNU/Linux 7.5 (Wheezy)</para></listitem>
+                <listitem><para>Debian GNU/Linux 7.6 (Wheezy)</para></listitem>
 <!--                <listitem><para>openSUSE 11.4</para></listitem>
                 <listitem><para>openSUSE 12.1</para></listitem> -->
                 <listitem><para>openSUSE 12.2</para></listitem>
@@ -392,20 +398,20 @@
                         Execute the installation script.
                         Here is an example:
                         <literallayout class='monospaced'>
-     $ sh poky-eglibc-x86_64-buildtools-tarball-x86_64-buildtools-nativesdk-standalone-&DISTRO;.sh
+     $ sh poky-glibc-x86_64-buildtools-tarball-x86_64-buildtools-nativesdk-standalone-&DISTRO;.sh
                         </literallayout>
                         During execution, a prompt appears that allows you to
                         choose the installation directory.
                         For example, you could choose the following:
                         <literallayout class='monospaced'>
-     /home/your-username/buildtools
+     /home/<replaceable>your-username</replaceable>/buildtools
                         </literallayout>
                         </para></listitem>
                     <listitem><para>
                         Source the tools environment setup script by using a
                         command like the following:
                         <literallayout class='monospaced'>
-     $ source /home/your-username/buildtools/environment-setup-i586-poky-linux
+     $ source /home/<replaceable>your-username</replaceable>/buildtools/environment-setup-i586-poky-linux
                         </literallayout>
                         Of course, you need to supply your installation directory and be
                         sure to use the right file (i.e. i585 or x86-64).
@@ -478,20 +484,20 @@
                        to install the tools.
                        Here is an example:
                        <literallayout class='monospaced'>
-     $ sh poky-eglibc-x86_64-buildtools-tarball-x86_64-buildtools-nativesdk-standalone-&DISTRO;.sh
+     $ sh poky-glibc-x86_64-buildtools-tarball-x86_64-buildtools-nativesdk-standalone-&DISTRO;.sh
                        </literallayout>
                        During execution, a prompt appears that allows you to
                        choose the installation directory.
                        For example, you could choose the following:
                        <literallayout class='monospaced'>
-     /home/your-username/buildtools
+     /home/<replaceable>your-username</replaceable>/buildtools
                        </literallayout>
                        </para></listitem>
                     <listitem><para>
                         Source the tools environment setup script by using a
                         command like the following:
                         <literallayout class='monospaced'>
-     $ source /home/your-username/buildtools/environment-setup-i586-poky-linux
+     $ source /home/<replaceable>your-username</replaceable>/buildtools/environment-setup-i586-poky-linux
                         </literallayout>
                         Of course, you need to supply your installation directory and be
                         sure to use the right file (i.e. i585 or x86-64).

documentation/ref-manual/migration.xml

@@ -110,7 +110,7 @@
                 appended to the path used to access the mirror.
                 Here is an example:
                 <literallayout class='monospaced'>
-     SSTATE_MIRRORS = "file://.* http://someserver.tld/share/sstate/PATH"
+     SSTATE_MIRRORS = "file://.* http://<replaceable>someserver</replaceable>.tld/share/sstate/PATH"
                 </literallayout>
             </para>
         </section>
@@ -375,10 +375,11 @@
                 <listitem><para><emphasis>Shared State Code:</emphasis>
                     The shared state code has been optimized to avoid running
                     unnecessary tasks.
-                    For example,
-                    <filename>bitbake -c rootfs some-image</filename> from
-                    shared state no longer populates the target sysroot
-                    since that is not necessary.
+                    For example, the following no longer populates the target
+                    sysroot since that is not necessary:
+                    <literallayout class='monospaced'>
+     $ bitbake -c rootfs <replaceable>some-image</replaceable>
+                    </literallayout>
                     Instead, the system just needs to extract the output
                     package contents, re-create the packages, and construct
                     the root filesystem.
@@ -832,7 +833,7 @@
                     This directory is located under
                     <filename>sysroots</filename> and uses a machine-specific
                     name (i.e.
-                    <filename>tmp/sysroots/&lt;machine&gt;/pkgdata</filename>).
+                    <filename>tmp/sysroots/<replaceable>machine</replaceable>/pkgdata</filename>).
                     </para></listitem>
             </itemizedlist>
         </para>
@@ -1100,7 +1101,7 @@
                     </para></listitem>
                 <listitem><para>
                     <filename>base-files</filename>: Remove the unnecessary
-                    <filename>media/xxx</filename> directories.
+                    <filename>media/</filename><replaceable>xxx</replaceable> directories.
                     </para></listitem>
                 <listitem><para>
                     <filename>alsa-state</filename>: Provide an empty
@@ -1228,7 +1229,7 @@
                 value against the branch.
                 You can specify the branch using the following form:
                 <literallayout class='monospaced'>
-     SRC_URI = "git://server.name/repository;branch=&lt;branchname&gt;"
+     SRC_URI = "git://server.name/repository;branch=<replaceable>branchname</replaceable>"
                 </literallayout>
                 If you do not specify a branch, BitBake looks
                 in the default "master" branch.
@@ -1305,10 +1306,10 @@
         </section>
 
         <section id='migration-1.6-task-taskname-overrides'>
-            <title><filename>task-&lt;taskname&gt;</filename> Overrides</title>
+            <title><filename>task-</filename><replaceable>taskname</replaceable> Overrides</title>
 
             <para>
-                <filename>task-&lt;taskname&gt;</filename> overrides have been
+                <filename>task-</filename><replaceable>taskname</replaceable> overrides have been
                 adjusted so that tasks whose names contain underscores have the
                 underscores replaced by hyphens for the override so that they
                 now function properly.
@@ -1691,6 +1692,327 @@
         </para>
     </section>
 </section>
+
+<section id='moving-to-the-yocto-project-1.7-release'>
+    <title>Moving to the Yocto Project 1.7 Release</title>
+
+    <para>
+        This section provides migration information for moving to the
+        Yocto Project 1.7 Release from the prior release.
+    </para>
+
+    <section id='migration-1.7-changes-to-setting-qemu-packageconfig-options'>
+        <title>Changes to Setting QEMU <filename>PACKAGECONFIG</filename> Options in <filename>local.conf</filename></title>
+
+        <para>
+            The QEMU recipe now uses a number of
+            <link linkend='var-PACKAGECONFIG'><filename>PACKAGECONFIG</filename></link>
+            options to enable various optional features.
+            The method used to set defaults for these options means that
+            existing
+            <filename>local.conf</filename> files will need to be be
+            modified to append to <filename>PACKAGECONFIG</filename> for
+            <filename>qemu-native</filename> and
+            <filename>nativesdk-qemu</filename> instead of setting it.
+            In other words, to enable graphical output for QEMU, you should
+            now have these lines in <filename>local.conf</filename>:
+            <literallayout class='monospaced'>
+     PACKAGECONFIG_append_pn-qemu-native = " sdl"
+     PACKAGECONFIG_append_pn-nativesdk-qemu = " sdl"
+            </literallayout>
+        </para>
+    </section>
+
+    <section id='migration-1.7-minimum-git-version'>
+        <title>Minimum Git version</title>
+
+        <para>
+            The minimum
+            <ulink url='&YOCTO_DOCS_DEV_URL;#git'>Git</ulink> version required
+            on the build host is now 1.7.8 because the
+            <filename>&dash;&dash;list</filename> option is now required by
+            BitBake's Git fetcher.
+            As always, if your host distribution does not provide a version of
+            Git that meets this requirement, you can use the
+            <filename>buildtools-tarball</filename> that does.
+            See the
+            "<link linkend='required-git-tar-and-python-versions'>Required Git, tar, and Python Versions</link>"
+            section for more information.
+        </para>
+    </section>
+
+    <section id='migration-1.7-autotools-class-changes'>
+        <title>Autotools Class Changes</title>
+
+        <para>
+            The following
+            <link linkend='ref-classes-autotools'><filename>autotools</filename></link>
+            class changes occurred:
+            <itemizedlist>
+                <listitem><para><emphasis>
+                    A separate build directory is now used by default:</emphasis>
+                    The <filename>autotools</filename> class has been changed
+                    to use a directory for building
+                    (<link linkend='var-B'><filename>B</filename></link>),
+                    which is separate from the source directory
+                    (<link linkend='var-S'><filename>S</filename></link>).
+                    This is commonly referred to as
+                    <filename>B != S</filename>, or an out-of-tree build.</para>
+                    <para>If the software being built is already capable of
+                    building in a directory separate from the source, you
+                    do not need to do anything.
+                    However, if the software is not capable of being built
+                    in this manner, you will
+                    need to either patch the software so that it can build
+                    separately, or you will need to change the recipe to
+                    inherit the
+                    <link linkend='ref-classes-autotools-brokensep'><filename>autotools-brokensep</filename></link>
+                    class instead of the <filename>autotools</filename> class.
+                    </para></listitem>
+                <listitem><para><emphasis>
+                    The <filename>&dash;&dash;foreign</filename> option is
+                    no longer passed to <filename>automake</filename> when
+                    running <filename>autoconf</filename>:</emphasis>
+                    This option tells <filename>automake</filename> that a
+                    particular software package does not follow the GNU
+                    standards and therefore should not be expected
+                    to distribute certain files such as
+                    <filename>ChangeLog</filename>,
+                    <filename>AUTHORS</filename>, and so forth.
+                    Because the majority of upstream software packages already
+                    tell <filename>automake</filename> to enable foreign mode
+                    themselves, the option is mostly superfluous.
+                    However, some recipes will need patches for this change.
+                    You can easily make the change by patching
+                    <filename>configure.ac</filename> so that it passes
+                    "foreign" to <filename>AM_INIT_AUTOMAKE()</filename>.
+                    See
+                    <ulink url='http://cgit.openembedded.org/openembedded-core/commit/?id=01943188f85ce6411717fb5bf702d609f55813f2'>this commit</ulink>
+                    for an example showing how to make the patch.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-1.7-binary-configuration-scripts-disabled'>
+        <title>Binary Configuration Scripts Disabled</title>
+
+        <para>
+            Some of the core recipes that package binary configuration scripts
+            now disable the scripts due to the
+            scripts previously requiring error-prone path substitution.
+            Software that links against these libraries using these scripts
+            should use the much more robust <filename>pkg-config</filename>
+            instead.
+            The list of recipes changed in this version (and their
+            configuration scripts) is as follows:
+            <literallayout class='monospaced'>
+     directfb (directfb-config)
+     freetype (freetype-config)
+     gpgme (gpgme-config)
+     libassuan (libassuan-config)
+     libcroco (croco-6.0-config)
+     libgcrypt (libgcrypt-config)
+     libgpg-error (gpg-error-config)
+     libksba (ksba-config)
+     libpcap (pcap-config)
+     libpcre (pcre-config)
+     libpng (libpng-config, libpng16-config)
+     libsdl (sdl-config)
+     libusb-compat (libusb-config)
+     libxml2 (xml2-config)
+     libxslt (xslt-config)
+     ncurses (ncurses-config)
+     neon (neon-config)
+     npth (npth-config)
+     pth (pth-config)
+     taglib (taglib-config)
+            </literallayout>
+            Additionally, support for <filename>pkg-config</filename> has been
+            added to some recipes in the previous list in the rare cases
+            where the upstream software package does not already provide
+            it.
+        </para>
+    </section>
+
+    <section id='migration-1.7-glibc-replaces-eglibc'>
+        <title><filename>eglibc 2.19</filename> Replaced with <filename>glibc 2.20</filename></title>
+
+        <para>
+            Because <filename>eglibc</filename> and
+            <filename>glibc</filename> were already fairly close, this
+            replacement should not require any significant changes to other
+            software that links to <filename>eglibc</filename>.
+            However, there were a number of minor changes in
+            <filename>glibc 2.20</filename> upstream that could require
+            patching some software (e.g. the removal of the
+            <filename>_BSD_SOURCE</filename> feature test macro).
+        </para>
+
+        <para>
+            <filename>glibc 2.20</filename> requires version 2.6.32 or greater
+            of the Linux kernel.
+            Thus, older kernels will no longer be usable in conjunction with it.
+        </para>
+
+        <para>
+            For full details on the changes in <filename>glibc 2.20</filename>,
+            see the upstream release notes
+            <ulink url='https://sourceware.org/ml/libc-alpha/2014-09/msg00088.html'>here</ulink>.
+        </para>
+    </section>
+
+    <section id='migration-1.7-kernel-module-autoloading'>
+        <title>Kernel Module Autoloading</title>
+
+        <para>
+            The
+            <link linkend='var-module_autoload'><filename>module_autoload_*</filename></link>
+            variable is now deprecated and a new
+            <link linkend='var-KERNEL_MODULE_AUTOLOAD'><filename>KERNEL_MODULE_AUTOLOAD</filename></link>
+            variable should be used instead.
+            Also,
+            <link linkend='var-module_conf'><filename>module_conf_*</filename></link>
+            must now be used in conjunction with a new
+            <link linkend='var-KERNEL_MODULE_PROBECONF'><filename>KERNEL_MODULE_PROBECONF</filename></link>
+            variable.
+            The new variables no longer require you to specify the module name
+            as part of the variable name.
+            This change not only simplifies usage but also allows the values
+            of these variables to be appropriately incorporated into task
+            signatures and thus trigger the appropriate tasks to re-execute
+            when changed.
+            You should replace any references to
+            <filename>module_autoload_*</filename> with
+            <filename>KERNEL_MODULE_AUTOLOAD</filename>, and add any modules
+            for which <filename>module_conf_*</filename> is specified to
+            <filename>KERNEL_MODULE_PROBECONF</filename>.
+        </para>
+
+        <para>
+            For more information, see the
+            <link linkend='var-KERNEL_MODULE_AUTOLOAD'><filename>KERNEL_MODULE_AUTOLOAD</filename></link>
+            and
+            <link linkend='var-KERNEL_MODULE_PROBECONF'><filename>KERNEL_MODULE_PROBECONF</filename></link>
+            variables.
+        </para>
+    </section>
+
+    <section id='migration-1.7-qa-check-changes'>
+        <title>QA Check Changes</title>
+
+        <para>
+            The following changes have occurred to the QA check process:
+            <itemizedlist>
+                <listitem><para>
+                    Additional QA checks <filename>file-rdeps</filename>
+                    and <filename>build-deps</filename> have been added in
+                    order to verify that file dependencies are satisfied
+                    (e.g. package contains a script requiring
+                    <filename>/bin/bash</filename>) and build-time dependencies
+                    are declared, respectively.
+                    For more information, please see the
+                    "<link linkend='ref-qa-checks'>QA Error and Warning Messages</link>"
+                    chapter.
+                    </para></listitem>
+                <listitem><para>
+                    Package QA checks are now performed during a new
+                    <link linkend='ref-tasks-package_qa'><filename>do_package_qa</filename></link>
+                    task rather than being part of the
+                    <link linkend='ref-tasks-package'><filename>do_package</filename></link>
+                    task.
+                    This allows more parallel execution.
+                    This change is unlikely to be an issue except for highly
+                    customized recipes that disable packaging tasks themselves
+                    by marking them as <filename>noexec</filename>.
+                    For those packages, you will need to disable the
+                    <filename>do_package_qa</filename> task as well.
+                    </para></listitem>
+                <listitem><para>
+                    Files being overwritten during the
+                    <link linkend='ref-tasks-populate_sysroot'><filename>do_populate_sysroot</filename></link>
+                    task now trigger an error instead of a warning.
+                    Recipes should not be overwriting files written to the
+                    sysroot by other recipes.
+                    If you have these types of recipes, you need to alter them
+                    so that they do not overwrite these files.</para>
+                    <para>You might now receive this error after changes in
+                    configuration or metadata resulting in orphaned files
+                    being left in the sysroot.
+                    If you do receive this error, the way to resolve the issue
+                    is to delete your
+                    <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link>
+                    or to move it out of the way and then re-start the build.
+                    Anything that has been fully built up to that point and
+                    does not need rebuilding will be restored from the shared
+                    state cache and the rest of the build will be able to
+                    proceed as normal.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-1.7-removed-recipes'>
+        <title>Removed Recipes</title>
+
+        <para>
+            The following recipes have been removed:
+            <itemizedlist>
+                <listitem><para>
+                    <filename>x-load</filename>:
+                    This recipe has been superseded by
+                    U-boot SPL for all Cortex-based TI SoCs.
+                    For legacy boards, the <filename>meta-ti</filename>
+                    layer, which contains a maintained recipe, should be used
+                    instead.
+                    </para></listitem>
+                <listitem><para>
+                    <filename>ubootchart</filename>:
+                    This recipe is obsolete.
+                    A <filename>bootchart2</filename> recipe has been added
+                    to functionally replace it.
+                    </para></listitem>
+                <listitem><para>
+                    <filename>linux-yocto 3.4</filename>:
+                    Support for the linux-yocto 3.4 kernel has been dropped.
+                    Support for the 3.10 and 3.14 kernels remains, while
+                    support for version 3.17 has been added.
+                    </para></listitem>
+                <listitem><para>
+                    <filename>eglibc</filename> has been removed in favor of
+                    <filename>glibc</filename>.
+                    See the
+                    "<link linkend='migration-1.7-glibc-replaces-eglibc'><filename>eglibc 2.19</filename> Replaced with <filename>glibc 2.20</filename></link>"
+                    section for more information.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-1.7-miscellaneous-changes'>
+        <title>Miscellaneous Changes</title>
+
+        <para>
+            The following miscellaneous change occurred:
+            <itemizedlist>
+                <listitem><para>
+                    The build history feature now writes
+                    <filename>build-id.txt</filename> instead of
+                    <filename>build-id</filename>.
+                    Additionally, <filename>build-id.txt</filename>
+                    now contains the full build header as printed by
+                    BitBake upon starting the build.
+                    You should manually remove old "build-id" files from your
+                    existing build history repositories to avoid confusion.
+                    For information on the build history feature, see the
+                    "<link linkend='maintaining-build-output-quality'>Maintaining Build Output Quality</link>"
+                    section.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+</section>
+
 </chapter>
 <!--
 vim: expandtab tw=80 ts=4

documentation/ref-manual/ref-bitbake.xml

@@ -169,7 +169,7 @@
             <filename>packagegroup-core-x11-sato</filename>,
             which in turn leads to recipes like <filename>matchbox-terminal</filename>,
             <filename>pcmanfm</filename> and <filename>gthumb</filename>.
-            These recipes in turn depend on <filename>eglibc</filename> and the toolchain.
+            These recipes in turn depend on <filename>glibc</filename> and the toolchain.
         </para>
 
         <para>

documentation/ref-manual/ref-classes.xml

@@ -101,11 +101,23 @@
         section in the Yocto Project Development Manual.
     </para>
 
+    <para>
+        By default, the <filename>autotools</filename> class
+        uses out-of-tree builds
+        (<link linkend='var-B'><filename>B</filename></link> <filename>!=</filename>
+        <link linkend='var-S'><filename>S</filename></link>).
+        If the software being built by a recipe does not support
+        using out-of-tree builds, you should have the recipe inherit the
+        <link linkend='ref-classes-autotools-brokensep'><filename>autotools-brokensep</filename></link>
+        class.
+    </para>
+
     <para>
         It's useful to have some idea of how the tasks defined by this class work
         and what they do behind the scenes.
         <itemizedlist>
-            <listitem><para><link linkend='ref-tasks-configure'><filename>do_configure</filename></link> &dash; Regenerates the
+            <listitem><para><link linkend='ref-tasks-configure'><filename>do_configure</filename></link> &dash;
+                Regenerates the
                 configure script (using <filename>autoreconf</filename>) and then launches it
                 with a standard set of arguments used during cross-compilation.
                 You can pass additional parameters to <filename>configure</filename> through the
@@ -123,17 +135,6 @@
                 </para></listitem>
         </itemizedlist>
     </para>
-
-    <note>
-        It is planned for future Yocto Project releases that by default, the
-        <filename>autotools</filename> class supports out-of-tree builds
-        (<link linkend='var-B'><filename>B</filename></link> !=
-        <link linkend='var-S'><filename>S</filename></link>).
-        If your recipes do not support out-of-tree builds, you should
-        have them inherit the
-        <link linkend='ref-classes-autotools-brokensep'><filename>autotools-brokensep</filename></link>
-        class.
-    </note>
 </section>
 
 <section id='ref-classes-autotools-brokensep'>
@@ -186,6 +187,8 @@
         binary from source.
         The binary package is extracted and new packages in the configured
         output package format are created.
+        Extraction and installation of proprietary binaries is a good example
+        use for this class.
         <note>
             For RPMs and other packages that do not contain a subdirectory,
             you should specify a "subdir" parameter.
@@ -229,6 +232,21 @@
     </para>
 </section>
 
+<section id='ref-classes-binconfig-disabled'>
+    <title><filename>binconfig-disabled.bbclass</filename></title>
+
+    <para>
+        An alternative version of the
+        <link linkend='ref-classes-binconfig'><filename>binconfig</filename></link>
+        class, which disables binary configuration scripts by making them
+        return an error in favor of using <filename>pkg-config</filename>
+        to query the information.
+        The scripts to be disabled should be specified using the
+        <link linkend='var-BINCONFIG'><filename>BINCONFIG</filename></link>
+        variable within the recipe inheriting the class.
+    </para>
+</section>
+
 <section id='ref-classes-blacklist'>
     <title><filename>blacklist.bbclass</filename></title>
 
@@ -364,6 +382,18 @@
     </para>
 </section>
 
+<section id='ref-classes-buildstats-summary'>
+    <title><filename>buildstats-summary.bbclass</filename></title>
+
+    <para>
+        When inherited globally, prints statistics at the end of the build
+        on sstate re-use.
+        In order to function, this class requires the
+        <link linkend='ref-classes-buildstats'><filename>buildstats</filename></link>
+        class be enabled.
+    </para>
+</section>
+
 <section id='ref-classes-ccache'>
     <title><filename>ccache.bbclass</filename></title>
 
@@ -431,6 +461,19 @@
     </para>
 </section>
 
+<section id='ref-classes-compress_doc'>
+    <title><filename>compress_doc.bbclass</filename></title>
+
+    <para>
+        Enables compression for man pages and info pages.
+        This class is intended to be inherited globally.
+        The default compression mechanism is gz (gzip) but you can
+        select an alternative mechanism by setting the
+        <link linkend='var-DOC_COMPRESS'><filename>DOC_COMPRESS</filename></link>
+        variable.
+    </para>
+</section>
+
 <section id='ref-classes-copyleft_compliance'>
     <title><filename>copyleft_compliance.bbclass</filename></title>
 
@@ -445,6 +488,20 @@
     </para>
 </section>
 
+<section id='ref-classes-copyleft_filter'>
+    <title><filename>copyleft_filter.bbclass</filename></title>
+
+    <para>
+        A class used by the
+        <link linkend='ref-classes-archiver'><filename>archiver</filename></link>
+        and
+        <link linkend='ref-classes-copyleft_compliance'><filename>copyleft_compliance</filename></link>
+        classes for filtering licenses.
+        The <filename>copyleft_filter</filename> class is an internal class
+        and is not intended to be used directly.
+    </para>
+</section>
+
 <section id='ref-classes-core-image'>
     <title><filename>core-image.bbclass</filename></title>
 
@@ -523,8 +580,8 @@
 
     <para>
         The <filename>debian</filename> class renames output packages so that
-        they follow the Debian naming policy (i.e. <filename>eglibc</filename>
-        becomes <filename>libc6</filename> and <filename>eglibc-devel</filename>
+        they follow the Debian naming policy (i.e. <filename>glibc</filename>
+        becomes <filename>libc6</filename> and <filename>glibc-devel</filename>
         becomes <filename>libc6-dev</filename>.)
         Renaming includes the library name and version as part of the package
         name.
@@ -980,6 +1037,36 @@
     </para>
 </section>
 
+<section id='ref-classes-gummiboot'>
+    <title><filename>gummiboot.bbclass</filename></title>
+
+    <para>
+        The <filename>gummiboot</filename> class provides functions specific
+        to the gummiboot bootloader for building bootable images.
+        This is an internal class and is not intended to be
+        used directly.
+        Set the
+        <link linkend='var-EFI_PROVIDER'><filename>EFI_PROVIDER</filename></link>
+        variable to "gummiboot" to use this class.
+    </para>
+
+    <para>
+        For information on more variables used and supported in this class,
+        see the
+        <link linkend='var-GUMMIBOOT_CFG'><filename>GUMMIBOOT_CFG</filename></link>,
+        <link linkend='var-GUMMIBOOT_ENTRIES'><filename>GUMMIBOOT_ENTRIES</filename></link>,
+        and
+        <link linkend='var-GUMMIBOOT_TIMEOUT'><filename>GUMMIBOOT_TIMEOUT</filename></link>
+        variables.
+    </para>
+
+    <para>
+        You can also see the
+        <ulink url='http://freedesktop.org/wiki/Software/gummiboot/'>Gummiboot documentation</ulink>
+        for more information.
+    </para>
+</section>
+
 <section id='ref-classes-gzipnative'>
     <title><filename>gzipnative.bbclass</filename></title>
 
@@ -1090,7 +1177,7 @@
         <link linkend='var-ICECC_DISABLED'><filename>ICECC_DISABLED</filename></link>
         variable to "1" as follows:
         <literallayout class='monospaced'>
-     INHERIT_DISTRO += "icecc"
+     INHERIT_DISTRO_append = " icecc"
      ICECC_DISABLED ??= "1"
         </literallayout>
         This practice makes sure everyone is using the same signatures but also
@@ -1333,6 +1420,35 @@
                 Currently, this test triggers too many false positives and
                 thus is not normally enabled.
                 </para></listitem>
+            <listitem><para><emphasis><filename>build-deps:</filename></emphasis>
+                Determines if a build-time dependency that is specified through
+                <link linkend='var-DEPENDS'><filename>DEPENDS</filename></link>,
+                explicit
+                <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>,
+                or task-level dependencies exists to match any runtime
+                dependency.
+                This determination is particularly useful to discover where
+                runtime dependencies are detected and added during packaging.
+                If no explicit dependency has been specified within the
+                metadata, at the packaging stage it is too late to ensure that
+                the dependency is built, and thus you can end up with an
+                error when the package is installed into the image during the
+                <link linkend='ref-tasks-rootfs'><filename>do_rootfs</filename></link>
+                task because the auto-detected dependency was not satisfied.
+                An example of this would be where the
+                <link linkend='ref-classes-update-rc.d'><filename>update-rc.d</filename></link>
+                class automatically adds a dependency on the
+                <filename>initscripts-functions</filename> package to packages
+                that install an initscript that refers to
+                <filename>/etc/init.d/functions</filename>.
+                The recipe should really have an explicit
+                <filename>RDEPENDS</filename> for the package in question on
+                <filename>initscripts-functions</filename> so that the
+                OpenEmbedded build system is able to ensure that the
+                <filename>initscripts</filename> recipe is actually built and
+                thus the <filename>initscripts-functions</filename> package is
+                made available.
+                </para></listitem>
             <listitem><para><emphasis><filename>compile-host-path:</filename></emphasis>
                 Checks the
                 <link linkend='ref-tasks-compile'><filename>do_compile</filename></link>
@@ -1384,6 +1500,25 @@
                 Some very rare cases do exist for dynamically loaded modules where
                 these symlinks are needed instead in the main package.
                 </para></listitem>
+            <listitem><para><emphasis><filename>file-rdeps:</filename></emphasis>
+                Checks that file-level dependencies identified by the
+                OpenEmbedded build system at packaging time are satisfied.
+                For example, a shell script might start with the line
+                <filename>#!/bin/bash</filename>.
+                This line would translate to a file dependency on
+                <filename>/bin/bash</filename>.
+                Of the three package managers that the OpenEmbedded build
+                system supports, only RPM directly handles file-level
+                dependencies, resolving them automatically to packages
+                providing the files.
+                However, the lack of that functionality in the other two
+                package managers does not mean the dependencies do not still
+                need resolving.
+                This QA check attempts to ensure that explicitly declared
+                <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>
+                exist to handle any file-level dependency detected in
+                packaged files.
+                </para></listitem>
             <listitem><para><emphasis><filename>files-invalid:</filename></emphasis>
                 Checks for
                 <link linkend='var-FILES'><filename>FILES</filename></link>
@@ -1896,7 +2031,7 @@
         You can create a recipe that builds tools that run natively on the
         host a couple different ways:
         <itemizedlist>
-            <listitem><para>Create a <filename>myrecipe-native.bb</filename>
+            <listitem><para>Create a <replaceable>myrecipe</replaceable><filename>-native.bb</filename>
                 that inherits the <filename>native</filename> class.
                 If you use this method, you must order the inherit statement
                 in the recipe after all other inherit statements so that the
@@ -1937,7 +2072,7 @@
         You can create a recipe that builds tools that run on the SDK machine
         a couple different ways:
         <itemizedlist>
-            <listitem><para>Create a <filename>myrecipe-nativesdk.bb</filename>
+            <listitem><para>Create a <replaceable>myrecipe</replaceable><filename>-nativesdk.bb</filename>
                 recipe that inherits the <filename>nativesdk</filename> class.
                 If you use this method, you must order the inherit statement
                 in the recipe after all other inherit statements so that the
@@ -2143,7 +2278,7 @@
     <title><filename>package_rpm.bbclass</filename></title>
 
     <para>
-        The <filename>package_deb</filename> class
+        The <filename>package_rpm</filename> class
         provides support for creating packages that use the
         <filename>.rpm</filename> file format.
         The class ensures the packages are written out to the
@@ -2340,7 +2475,7 @@
         <itemizedlist>
             <listitem><para><emphasis><filename>populate_sdk_base</filename>:</emphasis>
                 The base class supporting SDK creation under all package
-                managers (i.e. DEB, RPM, and IPK).</para></listitem>
+                managers (i.e. DEB, RPM, and opkg).</para></listitem>
             <listitem><para><emphasis><filename>populate_sdk_deb</filename>:</emphasis>
                 Supports creation of the SDK given the Debian package manager.
                 </para></listitem>
@@ -2348,13 +2483,14 @@
                 Supports creation of the SDK given the RPM package manager.
                 </para></listitem>
             <listitem><para><emphasis><filename>populate_sdk_ipk</filename>:</emphasis>
-                Supports creation of the SDK given the IPK package manager.
+                Supports creation of the SDK given the opkg (IPK format)
+                package manager.
                 </para></listitem>
         </itemizedlist>
     </para>
 
     <para>
-        The <filename>populate_sdk_base</filename> package inherits the
+        The <filename>populate_sdk_base</filename> class inherits the
         appropriate <filename>populate_sdk_*</filename> (i.e.
         <filename>deb</filename>, <filename>rpm</filename>, and
         <filename>ipk</filename>) based on
@@ -2365,8 +2501,8 @@
         The base class ensures all source and destination directories are
         established and then populates the SDK.
         After populating the SDK, the <filename>populate_sdk_base</filename>
-        class constructs two images:
-        <link linkend='var-SDK_ARCH'><filename>SDK_ARCH</filename></link><filename>-nativesdk</filename>,
+        class constructs two sysroots:
+        <filename>${</filename><link linkend='var-SDK_ARCH'><filename>SDK_ARCH</filename></link><filename>}-nativesdk</filename>,
         which contains the cross-compiler and associated tooling, and the
         target, which contains a target root filesystem that is configured for
         the SDK usage.
@@ -2374,8 +2510,8 @@
         <link linkend='var-SDK_OUTPUT'><filename>SDK_OUTPUT</filename></link>,
         which consists of the following:
         <literallayout class='monospaced'>
-     ${SDK_OUTPUT}/&lt;sdk_arch-nativesdk pkgs&gt;
-     ${SDK_OUTPUT}/${SDKTARGETSYSROOT}/&lt;target pkgs&gt;
+     ${SDK_OUTPUT}/${SDK_ARCH}<replaceable>-nativesdk-pkgs</replaceable>
+     ${SDK_OUTPUT}/${SDKTARGETSYSROOT}/<replaceable>target-pkgs</replaceable>
         </literallayout>
     </para>
 
@@ -2481,6 +2617,22 @@
     </para>
 </section>
 
+<section id='ref-classes-ptest-gnome'>
+    <title><filename>ptest-gnome.bbclass</filename></title>
+
+    <para>
+        Enables package tests (ptests) specifically for GNOME packages,
+        which have tests intended to be executed with
+        <filename>gnome-desktop-testing</filename>.
+    </para>
+
+    <para>
+        For information on setting up and running ptests, see the
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#testing-packages-with-ptest'>Testing Packages With ptest</ulink>"
+        section in the Yocto Project Development Manual.
+    </para>
+</section>
+
 <section id='ref-classes-python-dir'>
     <title><filename>python-dir.bbclass</filename></title>
 
@@ -2645,7 +2797,7 @@
         file.
         Here is an example:
         <literallayout class='monospaced'>
-    RM_WORK_EXCLUDE += "busybox eglibc"
+    RM_WORK_EXCLUDE += "busybox glibc"
         </literallayout>
     </para>
 </section>
@@ -2864,37 +3016,37 @@
     <para>
         The class supports the following variables:
         <itemizedlist>
-            <listitem><para><emphasis><link linkend='var-INITRD'><filename>INITRD</filename></link>:</emphasis>
+            <listitem><para><link linkend='var-INITRD'><filename>INITRD</filename></link>:
                 Indicates list of filesystem images to concatenate and use as
                 an initial RAM disk (initrd).
                 This variable is optional.</para></listitem>
-            <listitem><para><emphasis><link linkend='var-ROOTFS'><filename>ROOTFS</filename></link>:</emphasis>
+            <listitem><para><link linkend='var-ROOTFS'><filename>ROOTFS</filename></link>:
                 Indicates a filesystem image to include as the root filesystem.
                 This variable is optional.</para></listitem>
-            <listitem><para><emphasis><link linkend='var-AUTO_SYSLINUXMENU'><filename>AUTO_SYSLINUXMENU</filename></link>:</emphasis>
+            <listitem><para><link linkend='var-AUTO_SYSLINUXMENU'><filename>AUTO_SYSLINUXMENU</filename></link>:
                 Enables creating an automatic menu when set to "1".
                 </para></listitem>
-            <listitem><para><emphasis><link linkend='var-LABELS'><filename>LABELS</filename></link>:</emphasis>
+            <listitem><para><link linkend='var-LABELS'><filename>LABELS</filename></link>:
                 Lists targets for automatic configuration.
                 </para></listitem>
-            <listitem><para><emphasis><link linkend='var-APPEND'><filename>APPEND</filename></link>:</emphasis>
+            <listitem><para><link linkend='var-APPEND'><filename>APPEND</filename></link>:
                 Lists append string overrides for each label.
                 </para></listitem>
-            <listitem><para><emphasis><link linkend='var-SYSLINUX_OPTS'><filename>SYSLINUX_OPTS</filename></link>:</emphasis>
+            <listitem><para><link linkend='var-SYSLINUX_OPTS'><filename>SYSLINUX_OPTS</filename></link>:
                 Lists additional options to add to the syslinux file.
                 Semicolon characters separate multiple options.
                 </para></listitem>
-            <listitem><para><emphasis><link linkend='var-SYSLINUX_SPLASH'><filename>SYSLINUX_SPLASH</filename></link>:</emphasis>
+            <listitem><para><link linkend='var-SYSLINUX_SPLASH'><filename>SYSLINUX_SPLASH</filename></link>:
                 Lists a background for the VGA boot menu when you are using the
                 boot menu.</para></listitem>
-            <listitem><para><emphasis><link linkend='var-SYSLINUX_DEFAULT_CONSOLE'><filename>SYSLINUX_DEFAULT_CONSOLE</filename></link>:</emphasis>
+            <listitem><para><link linkend='var-SYSLINUX_DEFAULT_CONSOLE'><filename>SYSLINUX_DEFAULT_CONSOLE</filename></link>:
                 Set to "console=ttyX" to change kernel boot default console.
                 </para></listitem>
-            <listitem><para><emphasis><link linkend='var-SYSLINUX_SERIAL'><filename>SYSLINUX_SERIAL</filename></link>:</emphasis>
+            <listitem><para><link linkend='var-SYSLINUX_SERIAL'><filename>SYSLINUX_SERIAL</filename></link>:
                 Sets an alternate serial port.
                 Or, turns off serial when the variable is set with an
                 empty string.</para></listitem>
-            <listitem><para><emphasis><link linkend='var-SYSLINUX_SERIAL_TTY'><filename>SYSLINUX_SERIAL_TTY</filename></link>:</emphasis>
+            <listitem><para><link linkend='var-SYSLINUX_SERIAL_TTY'><filename>SYSLINUX_SERIAL_TTY</filename></link>:
                 Sets an alternate "console=tty..." kernel boot argument.
                 </para></listitem>
         </itemizedlist>
@@ -3004,6 +3156,27 @@
     </para>
 </section>
 
+<section id='ref-classes-texinfo'>
+    <title><filename>texinfo.bbclass</filename></title>
+
+    <para>
+        This class should be inherited by recipes whose upstream packages
+        invoke the <filename>texinfo</filename> utilities at build-time.
+        Native and cross recipes are made to use the dummy scripts provided
+        by <filename>texinfo-dummy-native</filename>, for improved performance.
+        Target architecture recipes use the genuine
+        Texinfo utilities.
+        By default, they use the Texinfo utilities on the host system.
+        <note>
+            If you want to use the Texinfo recipe shipped with the build
+            system, you can remove "texinfo-native" from
+            <link linkend='var-ASSUME_PROVIDED'><filename>ASSUME_PROVIDED</filename></link>
+            and makeinfo from
+            <link linkend='var-SANITY_REQUIRED_UTILITIES'><filename>SANITY_REQUIRED_UTILITIES</filename></link>.
+        </note>
+    </para>
+</section>
+
 <section id='ref-classes-tinderclient'>
     <title><filename>tinderclient.bbclass</filename></title>
 
@@ -3079,6 +3252,21 @@
     </para>
 </section>
 
+<section id='ref-classes-uninative'>
+    <title><filename>uninative.bbclass</filename></title>
+
+    <para>
+        Provides a means of reusing <filename>native/cross</filename> over
+        multiple distros.
+        <note>
+            Currently, the method used by the <filename>uninative</filename>
+            class is experimental.
+        </note>
+        For more information, see the commit message
+        <ulink url='http://cgit.openembedded.org/openembedded-core/commit/?id=e66c96ae9c7ba21ebd04a4807390f0031238a85a'>here</ulink>.
+    </para>
+</section>
+
 <section id='ref-classes-update-alternatives'>
     <title><filename>update-alternatives.bbclass</filename></title>
 

documentation/ref-manual/ref-features.xml

@@ -42,7 +42,7 @@
         changed based on a given feature:
         <literallayout class='monospaced'>
      $ cd poky
-     $ git grep 'contains.*MACHINE_FEATURES.*&lt;feature&gt;'
+     $ git grep 'contains.*MACHINE_FEATURES.*<replaceable>feature</replaceable>'
         </literallayout>
     </para>
 
@@ -72,16 +72,26 @@
                     </para></listitem>
                 <listitem><para><emphasis>bluetooth:</emphasis> Hardware has integrated BT
                     </para></listitem>
+                <listitem><para><emphasis>efi:</emphasis> Support for booting through EFI
+                    </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>pcbios:</emphasis> Support for booting through BIOS
+                    </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>phone:</emphasis> Mobile phone (voice) support
+                    </para></listitem>
+                <listitem><para><emphasis>qvga:</emphasis> Machine has a QVGA (320x240) display
+                    </para></listitem>
+                <listitem><para><emphasis>rtc:</emphasis> Machine has a Real-Time Clock
+                    </para></listitem>
                 <listitem><para><emphasis>screen:</emphasis> Hardware has a screen
                     </para></listitem>
                 <listitem><para><emphasis>serial:</emphasis> Hardware has serial support (usually RS232)
@@ -92,6 +102,8 @@
                     </para></listitem>
                 <listitem><para><emphasis>usbhost:</emphasis> Hardware is USB Host capable
                     </para></listitem>
+                <listitem><para><emphasis>vfat:</emphasis> FAT file system support
+                    </para></listitem>
                 <listitem><para><emphasis>wifi:</emphasis> Hardware has integrated WiFi
                     </para></listitem>
             </itemizedlist>
@@ -195,51 +207,100 @@
         <title>Image Features</title>
 
         <para>
-            The contents of images generated by the OpenEmbedded build system can be controlled by the
-            <filename><link linkend='var-IMAGE_FEATURES'>IMAGE_FEATURES</link></filename>
-            and <filename><link linkend='var-EXTRA_IMAGE_FEATURES'>EXTRA_IMAGE_FEATURES</link></filename>
+            The contents of images generated by the OpenEmbedded build system
+            can be controlled by the
+            <link linkend='var-IMAGE_FEATURES'><filename>IMAGE_FEATURES</filename></link>
+            and
+            <link linkend='var-EXTRA_IMAGE_FEATURES'><filename>EXTRA_IMAGE_FEATURES</filename></link>
             variables that you typically configure in your image recipes.
             Through these variables, you can add several different
-            predefined packages such as development utilities or packages with debug
-            information needed to investigate application problems or profile applications.
+            predefined packages such as development utilities or packages with
+            debug information needed to investigate application problems or
+            profile applications.
         </para>
 
         <para>
-            Current list of
-            <filename>IMAGE_FEATURES</filename> contains the following:
+            The following image features are available for all images:
             <itemizedlist>
-                <listitem><para><emphasis>dbg-pkgs:</emphasis> Installs debug symbol packages for all packages
-                    installed in a given image.</para></listitem>
-                <listitem><para><emphasis>dev-pkgs:</emphasis> Installs development packages (headers and
-                    extra library links) for all packages installed in a given image.</para></listitem>
-                <listitem><para><emphasis>doc-pkgs:</emphasis> Installs documentation packages for all packages
-                    installed in a given image.</para></listitem>
-                <listitem><para><emphasis>nfs-server:</emphasis> Installs an NFS server.</para></listitem>
-                <listitem><para><emphasis>read-only-rootfs:</emphasis> Creates
-                    an image whose root filesystem is read-only.
+                <listitem><para><emphasis>dbg-pkgs:</emphasis>
+                    Installs debug symbol packages for all packages installed
+                    in a given image.
+                    </para></listitem>
+                <listitem><para><emphasis>debug-tweaks:</emphasis>
+                    Makes an image suitable for development (e.g.
+                    allows root logins without passwords).
+                    </para></listitem>
+                <listitem><para><emphasis>dev-pkgs:</emphasis>
+                    Installs development packages (headers and extra library
+                    links) for all packages installed in a given image.
+                    </para></listitem>
+                <listitem><para><emphasis>doc-pkgs:</emphasis> Installs
+                    documentation packages for all packages installed in a
+                    given image.
+                    </para></listitem>
+                <listitem><para><emphasis>package-management:</emphasis>
+                    Installs package management tools and preserves the package
+                    manager database.
+                    </para></listitem>
+                <listitem><para><emphasis>ptest-pkgs:</emphasis>
+                    Installs ptest packages for all ptest-enabled recipes.
+                    </para></listitem>
+                <listitem><para><emphasis>read-only-rootfs:</emphasis>
+                    Creates an image whose root filesystem is read-only.
                     See the
                     "<ulink url='&YOCTO_DOCS_DEV_URL;#creating-a-read-only-root-filesystem'>Creating a Read-Only Root Filesystem</ulink>"
                     section in the Yocto Project Development Manual for more
-                    information.</para></listitem>
-                <listitem><para><emphasis>splash:</emphasis> Enables showing a splash screen during boot.
-                    By default, this screen is provided by <filename>psplash</filename>, which does
-                    allow customization.
-                    If you prefer to use an alternative splash screen package, you can do so by
-                    setting the <filename>SPLASH</filename> variable
-                    to a different package name (or names) within the image recipe or at the distro
-                    configuration level.</para></listitem>
-                <listitem><para><emphasis>ssh-server-dropbear:</emphasis> Installs the Dropbear minimal
-                    SSH server.
+                    information.
                     </para></listitem>
-                <listitem><para><emphasis>ssh-server-openssh:</emphasis> Installs the OpenSSH SSH server,
-                    which is more full-featured than Dropbear.
-                    Note that if both the OpenSSH SSH server and the Dropbear minimal SSH server
-                    are present in <filename>IMAGE_FEATURES</filename>, then OpenSSH will take
-                    precedence and Dropbear will not be installed.</para></listitem>
-                <listitem><para><emphasis>staticdev-pkgs:</emphasis> Installs static development
-                    packages (i.e. static libraries containing <filename>*.a</filename> files) for all
-                    packages installed in a given image.</para></listitem>
-                <listitem><para><emphasis>tools-debug:</emphasis> Installs debugging tools such as
+                <listitem><para><emphasis>splash:</emphasis>
+                    Enables showing a splash screen during boot.
+                    By default, this screen is provided by
+                    <filename>psplash</filename>, which does allow
+                    customization.
+                    If you prefer to use an alternative splash screen package,
+                    you can do so by setting the <filename>SPLASH</filename>
+                    variable to a different package name (or names) within the
+                    image recipe or at the distro configuration level.
+                    </para></listitem>
+                <listitem><para><emphasis>staticdev-pkgs:</emphasis>
+                    Installs static development packages, which are
+                    static libraries (i.e. <filename>*.a</filename> files), for
+                    all packages installed in a given image.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+
+        <para>
+            Some image features are available only when you inherit the
+            <link linkend='ref-classes-core-image'><filename>core-image</filename></link>
+            class.
+            The current list of these valid features is as follows:
+            <itemizedlist>
+                <listitem><para><emphasis>eclipse-debug:</emphasis> Provides
+                    Eclipse remote debugging support.
+                    </para></listitem>
+                <listitem><para><emphasis>hwcodecs:</emphasis> Installs
+                    hardware acceleration codecs.
+                    </para></listitem>
+                <listitem><para><emphasis>nfs-server:</emphasis>
+                    Installs an NFS server.
+                    </para></listitem>
+                <listitem><para><emphasis>qt4-pkgs:</emphasis>
+                    Supports Qt4/X11 and demo applications.
+                    </para></listitem>
+                <listitem><para><emphasis>ssh-server-dropbear:</emphasis>
+                    Installs the Dropbear minimal SSH server.
+                    </para></listitem>
+                <listitem><para><emphasis>ssh-server-openssh:</emphasis>
+                    Installs the OpenSSH SSH server, which is more
+                    full-featured than Dropbear.
+                    Note that if both the OpenSSH SSH server and the Dropbear
+                    minimal SSH server are present in
+                    <filename>IMAGE_FEATURES</filename>, then OpenSSH will take
+                    precedence and Dropbear will not be installed.
+                    </para></listitem>
+                <listitem><para><emphasis>tools-debug:</emphasis>
+                    Installs debugging tools such as
                     <filename>strace</filename> and <filename>gdb</filename>.
                     For information on GDB, see the
                     "<ulink url='&YOCTO_DOCS_DEV_URL;#platdev-gdb-remotedebug'>Debugging With the GNU Project Debugger (GDB) Remotely</ulink>"
@@ -247,23 +308,33 @@
                     For information on tracing and profiling, see the
                     <ulink url='&YOCTO_DOCS_PROF_URL;'>Yocto Project Profiling and Tracing Manual</ulink>.
                     </para></listitem>
-                <listitem><para><emphasis>tools-profile:</emphasis> Installs profiling tools such as
-                    <filename>oprofile</filename>, <filename>exmap</filename>, and
-                    <filename>LTTng</filename>.
+                <listitem><para><emphasis>tools-profile:</emphasis>
+                    Installs profiling tools such as
+                    <filename>oprofile</filename>, <filename>exmap</filename>,
+                    and <filename>LTTng</filename>.
                     For general information on user-space tools, see the
                     "<ulink url='&YOCTO_DOCS_ADT_URL;#user-space-tools'>User-Space Tools</ulink>"
-                    section in the Yocto Project Application Developer's Guide.</para></listitem>
-                <listitem><para><emphasis>tools-sdk:</emphasis> Installs a full SDK that runs on the device.
+                    section in the Yocto Project Application Developer's
+                    Guide.
                     </para></listitem>
-                <listitem><para><emphasis>tools-testapps:</emphasis> Installs device testing tools (e.g.
-                    touchscreen debugging).</para></listitem>
-                <listitem><para><emphasis>x11:</emphasis> Installs the X server</para></listitem>
-                <listitem><para><emphasis>x11-base:</emphasis> Installs the X server with a
-                    minimal environment.</para></listitem>
-                <listitem><para><emphasis>x11-sato:</emphasis> Installs the OpenedHand Sato environment.
+                <listitem><para><emphasis>tools-sdk:</emphasis>
+                    Installs a full SDK that runs on the device.
+                    </para></listitem>
+                <listitem><para><emphasis>tools-testapps:</emphasis>
+                    Installs device testing tools (e.g. touchscreen debugging).
+                    </para></listitem>
+                <listitem><para><emphasis>x11:</emphasis>
+                    Installs the X server.
+                    </para></listitem>
+                <listitem><para><emphasis>x11-base:</emphasis>
+                    Installs the X server with a minimal environment.
+                    </para></listitem>
+                <listitem><para><emphasis>x11-sato:</emphasis>
+                    Installs the OpenedHand Sato environment.
                     </para></listitem>
             </itemizedlist>
         </para>
+
     </section>
 
     <section id='ref-features-backfill'>

documentation/ref-manual/ref-images.xml

@@ -38,9 +38,9 @@
     </para>
 
     <para>
-        Following, is a list of supported recipes:
+        Following is a list of supported recipes:
         <itemizedlist>
-            <listitem><para><emphasis><filename>build-appliance-image</filename>:</emphasis>
+            <listitem><para><filename>build-appliance-image</filename>:
                 An example virtual machine that contains all the pieces required to
                 run builds using the build system as well as the build system itself.
                 You can boot and run the image using either the
@@ -49,18 +49,18 @@
                 For more information on this image, see the
                 <ulink url='&YOCTO_HOME_URL;/documentation/build-appliance'>Build Appliance</ulink> page on
                 the Yocto Project website.</para></listitem>
-            <listitem><para><emphasis><filename>core-image-base</filename>:</emphasis>
+            <listitem><para><filename>core-image-base</filename>:
                 A console-only image that fully supports the target device hardware.</para></listitem>
-            <listitem><para><emphasis><filename>core-image-clutter</filename>:</emphasis>
+            <listitem><para><filename>core-image-clutter</filename>:
                 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>
+            <listitem><para><filename>core-image-directfb</filename>:
                 An image that uses <filename>directfb</filename> instead of X11.
                 </para></listitem>
-            <listitem><para><emphasis><filename>core-image-full-cmdline</filename>:</emphasis>
+            <listitem><para><filename>core-image-full-cmdline</filename>:
                 A console-only image with more full-featured Linux system
                 functionality installed.</para></listitem>
-                <listitem><para><emphasis><filename>core-image-lsb</filename>:</emphasis>
+                <listitem><para><filename>core-image-lsb</filename>:
                 An image that conforms to the Linux Standard Base (LSB)
                 specification.
                 This image requires a distribution configuration that
@@ -68,7 +68,7 @@
                 If you build <filename>core-image-lsb</filename> without that
                 configuration, the image will not be LSB-compliant.
                 </para></listitem>
-            <listitem><para><emphasis><filename>core-image-lsb-dev</filename>:</emphasis>
+            <listitem><para><filename>core-image-lsb-dev</filename>:
                 A <filename>core-image-lsb</filename> image that is suitable for development work
                 using the host.
                 The image includes headers and libraries you can use in a host development
@@ -78,7 +78,7 @@
                 If you build <filename>core-image-lsb-dev</filename> without that
                 configuration, the image will not be LSB-compliant.
                 </para></listitem>
-            <listitem><para><emphasis><filename>core-image-lsb-sdk</filename>:</emphasis>
+            <listitem><para><filename>core-image-lsb-sdk</filename>:
                 A <filename>core-image-lsb</filename> that includes everything in
                 meta-toolchain but also includes development headers and libraries
                 to form a complete standalone SDK.
@@ -87,15 +87,15 @@
                 If you build <filename>core-image-lsb-sdk</filename> without that
                 configuration, the image will not be LSB-compliant.
                 This image is suitable for development using the target.</para></listitem>
-            <listitem><para><emphasis><filename>core-image-minimal</filename>:</emphasis>
+            <listitem><para><filename>core-image-minimal</filename>:
                 A small image just capable of allowing a device to boot.</para></listitem>
-            <listitem><para><emphasis><filename>core-image-minimal-dev</filename>:</emphasis>
+            <listitem><para><filename>core-image-minimal-dev</filename>:
                 A <filename>core-image-minimal</filename> image suitable for development work
                 using the host.
                 The image includes headers and libraries you can use in a host development
                 environment.
                 </para></listitem>
-            <listitem><para id='images-core-image-minimal-initramfs'><emphasis><filename>core-image-minimal-initramfs</filename>:</emphasis>
+            <listitem><para id='images-core-image-minimal-initramfs'><filename>core-image-minimal-initramfs</filename>:
                 A <filename>core-image-minimal</filename> image that has the Minimal RAM-based
                 Initial Root Filesystem (initramfs) as part of the kernel,
                 which allows the system to find the first “init” program more efficiently.
@@ -104,38 +104,38 @@
                 variable for additional information helpful when working with
                 initramfs images.
                 </para></listitem>
-            <listitem><para><emphasis><filename>core-image-minimal-mtdutils</filename>:</emphasis>
+            <listitem><para><filename>core-image-minimal-mtdutils</filename>:
                 A <filename>core-image-minimal</filename> image that has support
                 for the Minimal MTD Utilities, which let the user interact with the
                 MTD subsystem in the kernel to perform operations on flash devices.
                 </para></listitem>
-            <listitem><para><emphasis><filename>core-image-rt</filename>:</emphasis>
+            <listitem><para><filename>core-image-rt</filename>:
                 A <filename>core-image-minimal</filename> image plus a real-time test suite and
                 tools appropriate for real-time use.</para></listitem>
-            <listitem><para><emphasis><filename>core-image-rt-sdk</filename>:</emphasis>
+            <listitem><para><filename>core-image-rt-sdk</filename>:
                 A <filename>core-image-rt</filename> image that includes everything in
                 <filename>meta-toolchain</filename>.
                 The image also includes development headers and libraries to form a complete
                 stand-alone SDK and is suitable for development using the target.
                 </para></listitem>
-            <listitem><para><emphasis><filename>core-image-sato</filename>:</emphasis>
+            <listitem><para><filename>core-image-sato</filename>:
                 An image with Sato support, a mobile environment and visual style that works well
                 with mobile devices.
                 The image supports X11 with a Sato theme and applications such as
                 a terminal, editor, file manager, media player, and so forth.
                 </para></listitem>
-            <listitem><para><emphasis><filename>core-image-sato-dev</filename>:</emphasis>
+            <listitem><para><filename>core-image-sato-dev</filename>:
                 A <filename>core-image-sato</filename> image suitable for development
                 using the host.
                 The image includes libraries needed to build applications on the device itself,
                 testing and profiling tools, and debug symbols.
                 This image was formerly <filename>core-image-sdk</filename>.
                 </para></listitem>
-            <listitem><para><emphasis><filename>core-image-sato-sdk</filename>:</emphasis>
+            <listitem><para><filename>core-image-sato-sdk</filename>:
                 A <filename>core-image-sato</filename> image that includes everything in meta-toolchain.
                 The image also includes development headers and libraries to form a complete standalone SDK
                 and is suitable for development using the target.</para></listitem>
-            <listitem><para><emphasis><filename>core-image-testmaster</filename>:</emphasis>
+            <listitem><para><filename>core-image-testmaster</filename>:
                 A "master" image designed to be used for automated runtime testing.
                 Provides a "known good" image that is deployed to a separate
                 partition so that you can boot into it and use it to deploy a
@@ -144,21 +144,21 @@
                 "<ulink url='&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing'>Performing Automated Runtime Testing</ulink>"
                 section in the Yocto Project Development Manual.
                 </para></listitem>
-            <listitem><para><emphasis><filename>core-image-testmaster-initramfs</filename>:</emphasis>
+            <listitem><para><filename>core-image-testmaster-initramfs</filename>:
                 A RAM-based Initial Root Filesystem (initramfs) image tailored for
                 use with the <filename>core-image-testmaster</filename> image.
                 </para></listitem>
-            <listitem><para><emphasis><filename>core-image-weston</filename>:</emphasis>
+            <listitem><para><filename>core-image-weston</filename>:
                 A very basic Wayland image with a terminal.
                 This image 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>core-image-x11</filename>:</emphasis>
+            <listitem><para><filename>core-image-x11</filename>:
                 A very basic X11 image with a terminal.
                 </para></listitem>
-            <listitem><para><emphasis><filename>qt4e-demo-image</filename>:</emphasis>
+            <listitem><para><filename>qt4e-demo-image</filename>:
                 An image that launches into the demo application for the embedded
                 (not based on X11) version of Qt.</para></listitem>
         </itemizedlist>

documentation/ref-manual/ref-manual-customization.xsl

@@ -1,7 +1,7 @@
 <?xml version='1.0'?>
 <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/1999/xhtml" xmlns:fo="http://www.w3.org/1999/XSL/Format" version="1.0">
 
-  <xsl:import href="http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl" />
+  <xsl:import href="http://docbook.sourceforge.net/release/xsl/1.76.1/xhtml/docbook.xsl" />
 
   <xsl:include href="../template/permalinks.xsl"/>
   <xsl:include href="../template/section.title.xsl"/>
@@ -9,6 +9,7 @@
   <xsl:include href="../template/division.title.xsl"/>
   <xsl:include href="../template/formal.object.heading.xsl"/>
   <xsl:include href="../template/gloss-permalinks.xsl"/>
+  <xsl:include href="../template/qa-code-permalinks.xsl"/>
 
   <xsl:param name="html.stylesheet" select="'ref-style.css'" />
   <xsl:param name="chapter.autolabel" select="1" />

documentation/ref-manual/ref-manual.xml

@@ -84,9 +84,24 @@
             </revision>
             <revision>
                 <revnumber>1.7</revnumber>
-                <date>Fall of 2014</date>
+                <date>October 2014</date>
                 <revremark>Released with the Yocto Project 1.7 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>1.7.1</revnumber>
+                <date>January 2015</date>
+                <revremark>Released with the Yocto Project 1.7.1 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.7.2</revnumber>
+                <date>June 2015</date>
+                <revremark>Released with the Yocto Project 1.7.2 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.7.3</revnumber>
+                <date>November 2015</date>
+                <revremark>Released with the Yocto Project 1.7.3 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>

documentation/ref-manual/ref-qa-checks.xml

@@ -59,10 +59,21 @@
 <section id='qa-errors-and-warnings'>
     <title>Errors and Warnings</title>
 
+<!--
+This section uses the <para><code> construct to enable permalinks for the
+various QA issue and warning messages.  The file templates/qa-code-permalinks.xsl
+is used to locate the construct and generate the permalink.  This solution
+leverages the fact that right now this section in the ref-manual is the only
+place is all the YP docs that uses the <para><code> construct.  If, in the
+future, that construct were to appear in the ref-manual, a generic permalink
+would be generated for the text between <code></code>.  If a better solution
+can be found then it should be implemented.  I can't find one at the moment.
+-->
+
     <para>
         <itemizedlist>
             <listitem>
-                <para>
+                <para id='qa-issue-libexec'>
                     <code>
      &lt;packagename&gt;: &lt;path&gt; is using libexec please relocate to &lt;libexecdir&gt; [libexec]
                     </code>
@@ -87,7 +98,7 @@
     <para>
         <itemizedlist>
             <listitem>
-                <para>
+                <para id='qa-issue-rpaths'>
                     <code>
      package &lt;packagename&gt; contains bad RPATH &lt;rpath&gt; in file &lt;file&gt; [rpaths]
                     </code>
@@ -119,7 +130,7 @@
     <para>
         <itemizedlist>
             <listitem>
-                <para>
+                <para id='qa-issue-useless-rpaths'>
                     <code>
      &lt;packagename&gt;: &lt;file&gt; contains probably-redundant RPATH &lt;rpath&gt; [useless-rpaths]
                     </code>
@@ -147,7 +158,63 @@
     <para>
         <itemizedlist>
             <listitem>
+                <para id='qa-issue-file-rdeps'>
+                    <code>
+     &lt;packagename&gt; requires &lt;files&gt;, but no providers in its RDEPENDS [file-rdeps]
+                    </code>
+                </para>
+
                 <para>
+                    A file-level dependency has been identified from the
+                    specified package on the specified files, but there is
+                    no explicit corresponding entry in
+                    <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>.
+                    If particular files are required at runtime then
+                    <filename>RDEPENDS</filename> should be declared in the
+                    recipe to ensure the packages providing them are built.
+                </para>
+
+                <para>
+                    &nbsp;
+                </para>
+            </listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        <itemizedlist>
+            <listitem>
+                <para id='qa-issue-build-deps'>
+                    <code>
+     &lt;packagename1&gt; rdepends on &lt;packagename2&gt;, but it isn't a build dependency? [build-deps]
+                    </code>
+                </para>
+
+                <para>
+                    A runtime dependency exists between the two specified
+                    packages, but there is nothing explicit within the recipe
+                    to enable the OpenEmbedded build system to ensure that
+                    dependency is satisfied.
+                    This condition is usually triggered by an
+                    <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>
+                    value being added at the packaging stage rather than up
+                    front, which is usually automatic based on the contents of
+                    the package.
+                    In most cases, you should change the recipe to add an
+                    explicit <filename>RDEPENDS</filename> for the dependency.
+                </para>
+
+                <para>
+                    &nbsp;
+                </para>
+            </listitem>
+        </itemizedlist>
+    </para>
+
+    <para>
+        <itemizedlist>
+            <listitem>
+                <para id='qa-issue-dev-so'>
                     <code>
      non -dev/-dbg/-nativesdk package contains symlink .so: &lt;packagename&gt; path '&lt;path&gt;' [dev-so]
                     </code>
@@ -178,7 +245,7 @@
     <para>
         <itemizedlist>
             <listitem>
-                <para>
+                <para id='qa-issue-staticdev'>
                     <code>
      non -staticdev package contains static .a library: &lt;packagename&gt; path '&lt;path&gt;' [staticdev]
                     </code>
@@ -205,7 +272,7 @@
     <para>
         <itemizedlist>
             <listitem>
-                <para>
+                <para id='qa-issue-libdir'>
                     <code>
      &lt;packagename&gt;: found library in wrong location [libdir]
                     </code>
@@ -236,7 +303,7 @@
     <para>
         <itemizedlist>
             <listitem>
-                <para>
+                <para id='qa-issue-debug-files'>
                     <code>
      non debug package contains .debug directory: &lt;packagename&gt; path &lt;path&gt; [debug-files]
                     </code>
@@ -269,7 +336,7 @@
     <para>
         <itemizedlist>
             <listitem>
-                <para>
+                <para id='qa-issue-arch'>
                     <code>
      Architecture did not match (&lt;machine_arch&gt; to &lt;file_arch&gt;) on &lt;file&gt; [arch]
                     </code>
@@ -308,7 +375,7 @@
     <para>
         <itemizedlist>
             <listitem>
-                <para>
+                <para id='qa-issue-arch-bit-size-no-match'>
                     <code>
      Bit size did not match (&lt;machine_bits&gt; to &lt;file_bits&gt;) &lt;recipe&gt; on &lt;file&gt; [arch]
                     </code>
@@ -347,7 +414,7 @@
     <para>
         <itemizedlist>
             <listitem>
-                <para>
+                <para id='qa-issue-arch-endianness-no-match'>
                     <code>
      Endianness did not match (&lt;machine_endianness&gt; to &lt;file_endianness&gt;) on &lt;file&gt; [arch]
                     </code>
@@ -386,7 +453,7 @@
     <para>
         <itemizedlist>
             <listitem>
-                <para>
+                <para id='qa-issue-textrel'>
                     <code>
      ELF binary '&lt;file&gt;' has relocations in .text [textrel]
                     </code>
@@ -397,13 +464,6 @@
                     <filename>.text</filename> sections.
                     This situation can result in a performance impact
                     at runtime.
-                    <note>
-                        A bug currently exists that causes this
-                        warning to appear erroneously.
-                        See
-                        <ulink url='https://bugzilla.yoctoproject.org/show_bug.cgi?id=6104'></ulink>
-                        for more information.
-                    </note>
                 </para>
 
                 <para>
@@ -416,7 +476,7 @@
     <para>
         <itemizedlist>
             <listitem>
-                <para>
+                <para id='qa-issue-ldflags'>
                     <code>
      No GNU_HASH in the elf binary: '&lt;file&gt;' [ldflags]
                     </code>
@@ -448,7 +508,7 @@
     <para>
         <itemizedlist>
             <listitem>
-                <para>
+                <para id='qa-issue-xorg-driver-abi'>
                     <code>
      Package &lt;packagename&gt; contains Xorg driver (&lt;driver&gt;) but no xorg-abi- dependencies [xorg-driver-abi]
                     </code>
@@ -478,7 +538,7 @@
     <para>
         <itemizedlist>
             <listitem>
-                <para>
+                <para id='qa-issue-infodir'>
                     <code>
      The /usr/share/info/dir file is not meant to be shipped in a particular package. [infodir]
                     </code>
@@ -506,7 +566,7 @@
     <para>
         <itemizedlist>
             <listitem>
-                <para>
+                <para id='qa-issue-symlink-to-sysroot'>
                     <code>
      Symlink &lt;path&gt; in &lt;packagename&gt; points to TMPDIR [symlink-to-sysroot]
                     </code>
@@ -533,7 +593,7 @@
     <para>
         <itemizedlist>
             <listitem>
-                <para>
+                <para id='qa-issue-la'>
                     <code>
      &lt;file&gt; failed sanity test (workdir) in path &lt;path&gt; [la]
                     </code>
@@ -559,7 +619,7 @@
     <para>
         <itemizedlist>
             <listitem>
-                <para>
+                <para id='qa-issue-pkgconfig'>
                     <code>
      &lt;file&gt; failed sanity test (tmpdir) in path &lt;path&gt; [pkgconfig]
                     </code>
@@ -584,7 +644,7 @@
     <para>
         <itemizedlist>
             <listitem>
-                <para>
+                <para id='qa-issue-debug-deps'>
                     <code>
      &lt;packagename&gt; rdepends on &lt;debug_packagename&gt; [debug-deps]
                     </code>
@@ -632,7 +692,7 @@
     <para>
         <itemizedlist>
             <listitem>
-                <para>
+                <para id='qa-issue-dev-deps'>
                     <code>
      &lt;packagename&gt; rdepends on &lt;dev_packagename&gt; [dev-deps]
                     </code>
@@ -667,7 +727,7 @@
                     files that it should not have (e.g. a non-symlink
                     <filename>.so</filename> file) or it might have been added
                     manually (e.g. by adding to
-                    <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>.
+                    <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>).
                 </para>
 
                 <para>
@@ -680,7 +740,7 @@
     <para>
         <itemizedlist>
             <listitem>
-                <para>
+                <para id='qa-issue-dep-cmp'>
                     <code>
      &lt;var&gt;_&lt;packagename&gt; is invalid: &lt;comparison&gt; (&lt;value&gt;)   only comparisons &lt;, =, &gt;, &lt;=, and &gt;= are allowed [dep-cmp]
                     </code>
@@ -711,7 +771,7 @@
     <para>
         <itemizedlist>
             <listitem>
-                <para>
+                <para id='qa-issue-compile-host-path'>
                     <code>
      &lt;recipename&gt;: The compile log indicates that host include and/or library paths were used. Please check the log '&lt;logfile&gt;' for more information. [compile-host-path]
                     </code>
@@ -736,7 +796,7 @@
     <para>
         <itemizedlist>
             <listitem>
-                <para>
+                <para id='qa-issue-install-host-path'>
                     <code>
      &lt;recipename&gt;: The install log indicates that host include and/or library paths were used. Please check the log '&lt;logfile&gt;' for more information. [install-host-path]
                     </code>
@@ -761,7 +821,7 @@
     <para>
         <itemizedlist>
             <listitem>
-                <para>
+                <para id='qa-issue-autoconf-log'>
                     <code>
      This autoconf log indicates errors, it looked at host include and/or library paths while determining system capabilities. Rerun configure task after fixing this. The path was '&lt;path&gt;'
                     </code>
@@ -786,7 +846,7 @@
     <para>
         <itemizedlist>
             <listitem>
-                <para>
+                <para id='qa-issue-pkgname'>
                     <code>
      &lt;packagename&gt; doesn't match the [a-z0-9.+-]+ regex [pkgname]
                     </code>
@@ -818,7 +878,7 @@
     <para>
         <itemizedlist>
             <listitem>
-                <para>
+                <para id='qa-issue-unknown-configure-option'>
                     <code>
      &lt;recipe&gt;: configure was passed unrecognized options: &lt;options&gt; [unknown-configure-option]
                     </code>
@@ -854,7 +914,7 @@
     <para>
         <itemizedlist>
             <listitem>
-                <para>
+                <para id='qa-issue-pn-overrides'>
                     <code>
      Recipe &lt;recipefile&gt; has PN of "&lt;recipename&gt;" which is in OVERRIDES, this can result in unexpected behavior. [pn-overrides]
                     </code>
@@ -894,7 +954,7 @@
     <para>
         <itemizedlist>
             <listitem>
-                <para>
+                <para id='qa-issue-pkgvarcheck'>
                     <code>
      &lt;recipefile&gt;: Variable &lt;variable&gt; is set as not being package specific, please fix this. [pkgvarcheck]
                     </code>
@@ -932,7 +992,7 @@
     <para>
         <itemizedlist>
             <listitem>
-                <para>
+                <para id='qa-issue-already-stripped'>
                     <code>
      File '&lt;file&gt;' from &lt;recipename&gt; was already stripped, this will prevent future debugging! [already-stripped]
                     </code>
@@ -977,7 +1037,7 @@
     <para>
         <itemizedlist>
             <listitem>
-                <para>
+                <para id='qa-issue-packages-list'>
                     <code>
      &lt;packagename&gt; is listed in PACKAGES multiple times, this leads to packaging errors. [packages-list]
                     </code>
@@ -1002,7 +1062,7 @@
     <para>
         <itemizedlist>
             <listitem>
-                <para>
+                <para id='qa-issue-files-invalid'>
                     <code>
      FILES variable for package &lt;packagename&gt; contains '//' which is invalid. Attempting to fix this but you should correct the metadata. [files-invalid]
                     </code>
@@ -1025,7 +1085,7 @@
     <para>
         <itemizedlist>
             <listitem>
-                <para>
+                <para id='qa-issue-installed-vs-shipped'>
                     <code>
       &lt;recipename&gt;: Files/directories were installed but not shipped [installed-vs-shipped]
                     </code>
@@ -1065,7 +1125,7 @@
     <para>
         <itemizedlist>
             <listitem>
-                <para>
+                <para id='qa-issue-old-and-new-package-and-version-names'>
                     <code>
      &lt;oldpackage&gt;-&lt;oldpkgversion&gt; was registered as shlib provider for &lt;library&gt;, changing it to &lt;newpackage&gt;-&lt;newpkgversion&gt; because it was built later
                     </code>
@@ -1151,7 +1211,6 @@ enabled by default:
         </note>
     </para>
 </section>
-
 </chapter>
 <!--
 vim: expandtab tw=80 ts=4

documentation/ref-manual/ref-structure.xml

@@ -315,7 +315,7 @@
             commands.
             Following is the script syntax:
             <literallayout class='monospaced'>
-     $ source oe-init-build-env-memres &lt;port_number&gt; &lt;build_dir&gt;
+     $ source oe-init-build-env-memres <replaceable>port_number</replaceable> <replaceable>build_dir</replaceable>
             </literallayout>
             The script uses other scripts within the
             <filename>scripts</filename> directory to do the bulk of the work.
@@ -499,7 +499,7 @@
             the variable in the top-level build environment setup script as
             follows:
             <literallayout class='monospaced'>
-     TEMPLATECONF=&lt;your_layer&gt;/conf
+     TEMPLATECONF=<replaceable>your_layer</replaceable>/conf
             </literallayout>
             Once the build process gets the sample file, it uses
             <filename>sed</filename> to substitute final
@@ -554,7 +554,7 @@
             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
+     TEMPLATECONF=<replaceable>your_layer</replaceable>/conf
             </literallayout>
             Once the build process gets the sample file, it uses
             <filename>sed</filename> to substitute final
@@ -695,7 +695,7 @@
         <para>
             This directory receives package licensing information.
             For example, the directory contains sub-directories for <filename>bash</filename>,
-            <filename>busybox</filename>, and <filename>eglibc</filename> (among others) that in turn
+            <filename>busybox</filename>, and <filename>glibc</filename> (among others) that in turn
             contain appropriate <filename>COPYING</filename> license files with other licensing information.
             For information on licensing, see the
             "<ulink url='&YOCTO_DOCS_DEV_URL;#maintaining-open-source-license-compliance-during-your-products-lifecycle'>Maintaining Open Source License Compliance During Your Product's Lifecycle</ulink>"

documentation/ref-manual/ref-tasks.xml

@@ -129,6 +129,17 @@
         </para>
     </section>
 
+    <section id='ref-tasks-package_qa'>
+        <title><filename>do_package_qa</filename></title>
+
+        <para>
+            Runs QA checks on packaged files.
+            For more information on these checks, see the
+            <link linkend='ref-classes-insane'><filename>insane</filename></link>
+            class.
+        </para>
+    </section>
+
     <section id='ref-tasks-package_write_deb'>
         <title><filename>do_package_write_deb</filename></title>
 
@@ -313,7 +324,7 @@
         <para>
             You can run this task using BitBake as follows:
             <literallayout class='monospaced'>
-     $ bitbake -c clean &lt;recipe&gt;
+     $ bitbake -c clean <replaceable>recipe</replaceable>
             </literallayout>
         </para>
 
@@ -327,7 +338,7 @@
             If you want to remove the sstate cache files for the recipe,
             you need to use the
             <link linkend='ref-tasks-cleansstate'><filename>do_cleansstate</filename></link>
-            task instead (i.e. <filename>bitbake -c cleansstate &lt;recipe&gt;</filename>).
+            task instead (i.e. <filename>bitbake -c cleansstate</filename> <replaceable>recipe</replaceable>).
         </para>
     </section>
 
@@ -348,7 +359,7 @@
         <para>
             You can run this task using BitBake as follows:
             <literallayout class='monospaced'>
-     $ bitbake -c cleanall &lt;recipe&gt;
+     $ bitbake -c cleanall <replaceable>recipe</replaceable>
             </literallayout>
         </para>
 
@@ -378,7 +389,7 @@
         <para>
             You can run this task using BitBake as follows:
             <literallayout class='monospaced'>
-     $ bitbake -c cleansstate &lt;recipe&gt;
+     $ bitbake -c cleansstate <replaceable>recipe</replaceable>
             </literallayout>
         </para>
 
@@ -393,7 +404,7 @@
                 If you need to build a target from scratch using remote
                 mirrors, use the "-f" option as follows:
                 <literallayout class='monospaced'>
-     $ bitbake -f -c do_cleansstate &lt;target&gt;
+     $ bitbake -f -c do_cleansstate <replaceable>target</replaceable>
                 </literallayout>
             </note>
         </para>

documentation/ref-manual/technical-details.xml

@@ -85,7 +85,7 @@
         </para>
 
         <para>
-            The most common usage for BitBake is <filename>bitbake &lt;packagename&gt;</filename>, where
+            The most common usage for BitBake is <filename>bitbake <replaceable>packagename</replaceable></filename>, where
             <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 recipe's filename
@@ -107,11 +107,8 @@
         <para>
             BitBake also tries to execute any dependent tasks first.
             So for example, before building <filename>matchbox-desktop</filename>, BitBake
-            would build a cross compiler and <filename>eglibc</filename> if they had not already
+            would build a cross compiler and <filename>glibc</filename> if they had not already
             been built.
-            <note>This release of the Yocto Project does not support the <filename>glibc</filename>
-                GNU version of the Unix standard C library.  By default, the OpenEmbedded build system
-                builds with <filename>eglibc</filename>.</note>
         </para>
 
         <para>
@@ -228,7 +225,7 @@
         The chain of events that occurs when <filename>gcc-cross</filename> is
         bootstrapped is as follows:
         <literallayout class='monospaced'>
-     gcc -> binutils-cross -> gcc-cross-initial -> linux-libc-headers -> eglibc-initial -> eglibc -> gcc-cross -> gcc-runtime
+     gcc -> binutils-cross -> gcc-cross-initial -> linux-libc-headers -> glibc-initial -> glibc -> gcc-cross -> gcc-runtime
         </literallayout>
         <itemizedlist>
             <listitem><para><filename>gcc</filename>:
@@ -251,9 +248,9 @@
             <listitem><para><filename>linux-libc-headers</filename>:
                 Headers needed for the cross-compiler.
                 </para></listitem>
-            <listitem><para><filename>eglibc-initial</filename>:
+            <listitem><para><filename>glibc-initial</filename>:
                 An initial version of the Embedded GLIBC needed to bootstrap
-                <filename>eglibc</filename>.
+                <filename>glibc</filename>.
                 </para></listitem>
             <listitem><para><filename>gcc-cross</filename>:
                 The final stage of the bootstrap process for the
@@ -304,7 +301,8 @@
     <para>
         Here is the bootstrap process for the relocatable toolchain:
         <literallayout class='monospaced'>
-     gcc -> binutils-crosssdk -> gcc-crosssdk-initial -> linux-libc-headers -> eglibc-initial -> nativesdk-eglibc -> gcc-crosssdk -> gcc-cross-canadian
+     gcc -> binutils-crosssdk -> gcc-crosssdk-initial -> linux-libc-headers ->
+        glibc-initial -> nativesdk-glibc -> gcc-crosssdk -> gcc-cross-canadian
         </literallayout>
         <itemizedlist>
             <listitem><para><filename>gcc</filename>:
@@ -327,11 +325,11 @@
             <listitem><para><filename>linux-libc-headers</filename>:
                 Headers needed for the cross-compiler.
                 </para></listitem>
-            <listitem><para><filename>eglibc-initial</filename>:
+            <listitem><para><filename>glibc-initial</filename>:
                 An initial version of the Embedded GLIBC needed to bootstrap
-                <filename>nativesdk-eglibc</filename>.
+                <filename>nativesdk-glibc</filename>.
                 </para></listitem>
-            <listitem><para><filename>nativesdk-eglibc</filename>:
+            <listitem><para><filename>nativesdk-glibc</filename>:
                 The Embedded GLIBC needed to bootstrap the
                 <filename>gcc-crosssdk</filename>.
                 </para></listitem>
@@ -608,13 +606,13 @@
             make some dependency and hash information available to the build.
             This information includes:
             <itemizedlist>
-                <listitem><para><filename>BB_BASEHASH_task-&lt;taskname&gt;</filename>:
+                <listitem><para><filename>BB_BASEHASH_task-</filename><replaceable>taskname</replaceable>:
                     The base hashes for each task in the recipe.
                     </para></listitem>
-                <listitem><para><filename>BB_BASEHASH_&lt;filename:taskname&gt;</filename>:
+                <listitem><para><filename>BB_BASEHASH_</filename><replaceable>filename</replaceable><filename>:</filename><replaceable>taskname</replaceable>:
                     The base hashes for each dependent task.
                     </para></listitem>
-                <listitem><para><filename>BBHASHDEPS_&lt;filename:taskname&gt;</filename>:
+                <listitem><para><filename>BBHASHDEPS_</filename><replaceable>filename</replaceable><filename>:</filename><replaceable>taskname</replaceable>:
                     The task dependencies for each task.
                     </para></listitem>
                 <listitem><para><filename>BB_TASKHASH</filename>:

documentation/ref-manual/usingpoky.xml

@@ -35,12 +35,12 @@
             <link linkend='structure-memres-core-script'><filename>oe-init-build-env-memres</filename></link>).
             Here is an example:
             <literallayout class='monospaced'>
-     $ source &OE_INIT_FILE; [&lt;build_dir&gt;]
+     $ source &OE_INIT_FILE; [<replaceable>build_dir</replaceable>]
             </literallayout>
         </para>
 
         <para>
-            The <filename>build_dir</filename> argument is optional and specifies the directory the
+            The <replaceable>build_dir</replaceable> argument 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
@@ -53,12 +53,12 @@
         <para>
             Once the build environment is set up, you can build a target using:
             <literallayout class='monospaced'>
-     $ bitbake &lt;target&gt;
+     $ bitbake <replaceable>target</replaceable>
             </literallayout>
         </para>
 
         <para>
-            The <filename>target</filename> is the name of the recipe you want to build.
+            The <replaceable>target</replaceable> is the name of the recipe you want to build.
             Common targets are the images in <filename>meta/recipes-core/images</filename>,
             <filename>meta/recipes-sato/images</filename>, etc. all found in the
             <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
@@ -154,14 +154,14 @@
         <title>Task Failures</title>
 
         <para>The log file for shell tasks is available in
-            <filename>${WORKDIR}/temp/log.do_taskname.pid</filename>.
-            For example, the <filename>compile</filename> task for the QEMU minimal image for the x86
+            <filename>${WORKDIR}/temp/log.do_<replaceable>taskname</replaceable>.pid</filename>.
+            For example, the <filename>do_compile</filename> task for the QEMU minimal image for the x86
             machine (<filename>qemux86</filename>) might be
             <filename>tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/temp/log.do_compile.20830</filename>.
             To see what
             <ulink url='&YOCTO_DOCS_DEV_URL;#bitbake-term'>BitBake</ulink>
             runs to generate that log, look at the corresponding
-            <filename>run.do_taskname.pid</filename> file located in the same directory.
+            <filename>run.do_<replaceable>taskname</replaceable>.pid</filename> file located in the same directory.
         </para>
 
         <para>
@@ -203,7 +203,7 @@
      $ bitbake matchbox-desktop
                .
                .
-        [make some changes to the source code in the work directory]
+        <replaceable>make some changes to the source code in the work directory</replaceable>
                .
                .
      $ bitbake matchbox-desktop -c compile -f
@@ -238,7 +238,7 @@
         <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
+            The <filename>bitbake -g <replaceable>targetname</replaceable></filename> command
             creates the <filename>pn-buildlist</filename>,
             <filename>pn-depends.dot</filename>,
             <filename>package-depends.dot</filename>, and
@@ -247,7 +247,7 @@
             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>
+            <filename>bitbake -g -u depexp <replaceable>targetname</replaceable></filename>
             command to display the results in a more human-readable form.
         </para>
     </section>
@@ -264,7 +264,7 @@
         </para>
 
         <para>
-            The output from <filename>bitbake -DDD -v targetname</filename> can reveal why
+            The output from <filename>bitbake -DDD -v</filename> <replaceable>targetname</replaceable> can reveal why
             BitBake chose a certain version of a package or why BitBake
             picked a certain provider.
             This command could also help you in a situation where you think BitBake did something
@@ -283,12 +283,12 @@
             <ulink url='&YOCTO_RELEASE_NOTES;'>Release Notes</ulink>
             for a look at all release-related issues.
             <itemizedlist>
-                <listitem><para><emphasis><filename>eglibc-initial</filename> fails to build</emphasis>:
+                <listitem><para><emphasis><filename>glibc-initial</filename> fails to build</emphasis>:
                     If your development host system has the unpatched
                     <filename>GNU Make 3.82</filename>,
                     the
                     <link linkend='ref-tasks-install'><filename>do_install</filename></link>
-                    task fails for <filename>eglibc-initial</filename> during
+                    task fails for <filename>glibc-initial</filename> during
                     the build.</para>
                     <para>Typically, every distribution that ships
                     <filename>GNU Make 3.82</filename> as
@@ -310,7 +310,7 @@
             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;
+     $ bitbake -b <replaceable>somepath</replaceable>/<replaceable>somerecipe</replaceable>.bb
             </literallayout>
             This command form does not check for dependencies.
             Consequently, you should use it
@@ -334,7 +334,7 @@
             This next example shows the parsing environment for a specific
             recipe:
             <literallayout class='monospaced'>
-     $ bitbake -e &lt;recipename&gt;
+     $ bitbake -e <replaceable>recipename</replaceable>
             </literallayout>
         </para>
     </section>
@@ -540,7 +540,7 @@
 
         <para>
             Build history information is kept in
-            <filename>$</filename><link linkend='var-TOPDIR'><filename>TOPDIR</filename></link><filename>/buildhistory</filename>
+            <filename>${</filename><link linkend='var-TOPDIR'><filename>TOPDIR</filename></link><filename>}/buildhistory</filename>
             in the Build Directory as defined by the
             <link linkend='var-BUILDHISTORY_DIR'><filename>BUILDHISTORY_DIR</filename></link>
             variable.
@@ -564,19 +564,22 @@
             <para>
                 The history for each package contains a text file that has
                 name-value pairs with information about the package.
-                For example, <filename>buildhistory/packages/core2-poky-linux/busybox/busybox/latest</filename>
+                For example, <filename>buildhistory/packages/i586-poky-linux/busybox/busybox/latest</filename>
                 contains the following:
                 <literallayout class='monospaced'>
-     PV = 1.19.3
-     PR = r3
-     RDEPENDS = update-rc.d eglibc (>= 2.13)
-     RRECOMMENDS = busybox-syslog busybox-udhcpc
-     PKGSIZE = 564701
-     FILES = /usr/bin/* /usr/sbin/* /usr/libexec/* /usr/lib/lib*.so.* \
-        /etc /com /var /bin/* /sbin/* /lib/*.so.* /usr/share/busybox \
-        /usr/lib/busybox/* /usr/share/pixmaps /usr/share/applications \
-        /usr/share/idl /usr/share/omf /usr/share/sounds /usr/lib/bonobo/servers
-     FILELIST = /etc/busybox.links /etc/init.d/hwclock.sh /bin/busybox /bin/sh
+     PV = 1.22.1
+     PR = r32
+     RPROVIDES =
+     RDEPENDS = glibc (>= 2.20) update-alternatives-opkg
+     RRECOMMENDS = busybox-syslog busybox-udhcpc update-rc.d
+     PKGSIZE = 540168
+     FILES = /usr/bin/* /usr/sbin/* /usr/lib/busybox/* /usr/lib/lib*.so.* \
+        /etc /com /var /bin/* /sbin/* /lib/*.so.* /lib/udev/rules.d \
+        /usr/lib/udev/rules.d /usr/share/busybox /usr/lib/busybox/* \
+        /usr/share/pixmaps /usr/share/applications /usr/share/idl \
+        /usr/share/omf /usr/share/sounds /usr/lib/bonobo/servers
+     FILELIST = /bin/busybox /bin/busybox.nosuid /bin/busybox.suid /bin/sh \
+        /etc/busybox.links.nosuid /etc/busybox.links.suid
                 </literallayout>
                 Most of these name-value pairs correspond to variables used
                 to produce the package.
@@ -589,15 +592,16 @@
             <para>
                 There is also a file corresponding to the recipe from which the
                 package came (e.g.
-                <filename>buildhistory/packages/core2-poky-linux/busybox/latest</filename>):
+                <filename>buildhistory/packages/i586-poky-linux/busybox/latest</filename>):
                 <literallayout class='monospaced'>
-     PV = 1.19.3
-     PR = r3
-     DEPENDS = virtual/i586-poky-linux-gcc virtual/i586-poky-linux-compilerlibs \
-        virtual/libc update-rc.d-native
-     PACKAGES = busybox-httpd busybox-udhcpd busybox-udhcpc busybox-syslog \
-        busybox-mdev busybox-dbg busybox busybox-doc busybox-dev \
-        busybox-staticdev busybox-locale
+     PV = 1.22.1
+     PR = r32
+     DEPENDS = initscripts kern-tools-native update-rc.d-native \
+        virtual/i586-poky-linux-compilerlibs virtual/i586-poky-linux-gcc \
+        virtual/libc virtual/update-alternatives
+     PACKAGES = busybox-ptest busybox-httpd busybox-udhcpd busybox-udhcpc \
+        busybox-syslog busybox-mdev busybox-hwclock busybox-dbg \
+        busybox-staticdev busybox-dev busybox-doc busybox-locale busybox
                 </literallayout>
             </para>
 
@@ -611,31 +615,44 @@
                 is set to
                 <filename>${<link linkend='var-AUTOREV'>AUTOREV</link>}</filename>.
                 Here is an example assuming
-                <filename>buildhistory/packages/emenlow-poky-linux/linux-yocto/latest_srcrev</filename>):
+                <filename>buildhistory/packages/qemux86-poky-linux/linux-yocto/latest_srcrev</filename>):
                 <literallayout class='monospaced'>
-     # SRCREV_machine = "b5c37fe6e24eec194bb29d22fdd55d73bcc709bf"
-     SRCREV_machine = "b5c37fe6e24eec194bb29d22fdd55d73bcc709bf"
-     # SRCREV_emgd = "caea08c988e0f41103bbe18eafca20348f95da02"
-     SRCREV_emgd = "caea08c988e0f41103bbe18eafca20348f95da02"
-     # SRCREV_meta = "c2ed0f16fdec628242a682897d5d86df4547cf24"
-     SRCREV_meta = "c2ed0f16fdec628242a682897d5d86df4547cf24"
+     # SRCREV_machine = "38cd560d5022ed2dbd1ab0dca9642e47c98a0aa1"
+     SRCREV_machine = "38cd560d5022ed2dbd1ab0dca9642e47c98a0aa1"
+     # SRCREV_meta = "a227f20eff056e511d504b2e490f3774ab260d6f"
+     SRCREV_meta = "a227f20eff056e511d504b2e490f3774ab260d6f"
                 </literallayout>
                 You can use the <filename>buildhistory-collect-srcrevs</filename>
-                command to collect the stored <filename>SRCREV</filename> values
-                from build history and report them in a format suitable for use in
-                global configuration (e.g., <filename>local.conf</filename>
-                or a distro include file) to override floating
-                <filename>AUTOREV</filename> values to a fixed set of revisions.
+                command with the <filename>-a</filename> option to
+                collect the stored <filename>SRCREV</filename> values
+                from build history and report them in a format suitable for
+                use in global configuration (e.g.,
+                <filename>local.conf</filename> or a distro include file) to
+                override floating <filename>AUTOREV</filename> values to a
+                fixed set of revisions.
                 Here is some example output from this command:
                 <literallayout class='monospaced'>
-     # emenlow-poky-linux
-     SRCREV_machine_pn-linux-yocto = "b5c37fe6e24eec194bb29d22fdd55d73bcc709bf"
-     SRCREV_emgd_pn-linux-yocto = "caea08c988e0f41103bbe18eafca20348f95da02"
-     SRCREV_meta_pn-linux-yocto = "c2ed0f16fdec628242a682897d5d86df4547cf24"
-     # core2-poky-linux
-     SRCREV_pn-kmod = "62081c0f68905b22f375156d4532fd37fa5c8d33"
-     SRCREV_pn-blktrace = "d6918c8832793b4205ed3bfede78c2f915c23385"
-     SRCREV_pn-opkg = "649"
+     $ buildhistory-collect-srcrevs -a
+     # i586-poky-linux
+     SRCREV_pn-glibc = "b8079dd0d360648e4e8de48656c5c38972621072"
+     SRCREV_pn-glibc-initial = "b8079dd0d360648e4e8de48656c5c38972621072"
+     SRCREV_pn-opkg-utils = "53274f087565fd45d8452c5367997ba6a682a37a"
+     SRCREV_pn-kmod = "fd56638aed3fe147015bfa10ed4a5f7491303cb4"
+     # x86_64-linux
+     SRCREV_pn-gtk-doc-stub-native = "1dea266593edb766d6d898c79451ef193eb17cfa"
+     SRCREV_pn-dtc-native = "65cc4d2748a2c2e6f27f1cf39e07a5dbabd80ebf"
+     SRCREV_pn-update-rc.d-native = "eca680ddf28d024954895f59a241a622dd575c11"
+     SRCREV_glibc_pn-cross-localedef-native = "b8079dd0d360648e4e8de48656c5c38972621072"
+     SRCREV_localedef_pn-cross-localedef-native = "c833367348d39dad7ba018990bfdaffaec8e9ed3"
+     SRCREV_pn-prelink-native = "faa069deec99bf61418d0bab831c83d7c1b797ca"
+     SRCREV_pn-opkg-utils-native = "53274f087565fd45d8452c5367997ba6a682a37a"
+     SRCREV_pn-kern-tools-native = "23345b8846fe4bd167efdf1bd8a1224b2ba9a5ff"
+     SRCREV_pn-kmod-native = "fd56638aed3fe147015bfa10ed4a5f7491303cb4"
+     # qemux86-poky-linux
+     SRCREV_machine_pn-linux-yocto = "38cd560d5022ed2dbd1ab0dca9642e47c98a0aa1"
+     SRCREV_meta_pn-linux-yocto = "a227f20eff056e511d504b2e490f3774ab260d6f"
+     # all-poky-linux
+     SRCREV_pn-update-rc.d = "eca680ddf28d024954895f59a241a622dd575c11"
                 </literallayout>
                 <note>
                     Here are some notes on using the
@@ -660,7 +677,7 @@
                             However, the script does place a
                             comment before each set of values that specifies
                             which triplet to which they belong as shown above
-                            (e.g., <filename>emenlow-poky-linux</filename>).
+                            (e.g., <filename>i586-poky-linux</filename>).
                             </para></listitem>
                     </itemizedlist>
                 </note>
@@ -679,9 +696,11 @@
                         The files are defined by
                         <link linkend='var-BUILDHISTORY_IMAGE_FILES'><filename>BUILDHISTORY_IMAGE_FILES</filename></link>.
                         </para></listitem>
-                    <listitem><para><filename>build-id:</filename>
+                    <listitem><para><filename>build-id.txt:</filename>
                         Human-readable information about the build configuration
-                        and metadata source revisions.</para></listitem>
+                        and metadata source revisions.
+                        This file contains the full build header as printed
+                        by BitBake.</para></listitem>
                     <listitem><para><filename>*.dot:</filename>
                         Dependency graphs for the image that are
                         compatible with <filename>graphviz</filename>.
@@ -715,17 +734,21 @@
                 Here is an example of <filename>image-info.txt</filename>:
                 <literallayout class='monospaced'>
      DISTRO = poky
-     DISTRO_VERSION = 1.1+snapshot-20120207
-     USER_CLASSES = image-mklibs image-prelink
+     DISTRO_VERSION = 1.7
+     USER_CLASSES = buildstats image-mklibs image-prelink
      IMAGE_CLASSES = image_types
-     IMAGE_FEATURES = debug-tweaks x11-base apps-x11-core \
-        package-management ssh-server-dropbear package-management
-     IMAGE_LINGUAS = en-us en-gb
-     IMAGE_INSTALL = packagegroup-core-boot packagegroup-base-extended
+     IMAGE_FEATURES = debug-tweaks
+     IMAGE_LINGUAS =
+     IMAGE_INSTALL = packagegroup-core-boot run-postinsts
      BAD_RECOMMENDATIONS =
-     ROOTFS_POSTPROCESS_COMMAND = buildhistory_get_image_installed ;   rootfs_update_timestamp ;
-     IMAGE_POSTPROCESS_COMMAND = buildhistory_get_imageinfo ;
-     IMAGESIZE = 171816
+     NO_RECOMMENDATIONS =
+     PACKAGE_EXCLUDE =
+     ROOTFS_POSTPROCESS_COMMAND = write_package_manifest; license_create_manifest; \
+        write_image_manifest ; buildhistory_list_installed_image ; \
+        buildhistory_get_image_installed ; ssh_allow_empty_password;  \
+        postinst_enable_logging; rootfs_update_timestamp ; ssh_disable_dns_lookup ;
+     IMAGE_POSTPROCESS_COMMAND =   buildhistory_get_imageinfo ;
+     IMAGESIZE = 6900
                 </literallayout>
                 Other than <filename>IMAGESIZE</filename>, which is the
                 total size of the files in the image in Kbytes, the
@@ -809,7 +832,7 @@
                 <literallayout class='monospaced'>
      DISTRO = poky
      DISTRO_VERSION = 1.3+snapshot-20130327
-     SDK_NAME = poky-eglibc-i686-arm
+     SDK_NAME = poky-glibc-i686-arm
      SDK_VERSION = 1.3+snapshot
      SDKMACHINE =
      SDKIMAGE_FEATURES = dev-pkgs dbg-pkgs
@@ -856,12 +879,12 @@
                 Here is an example:
                 <literallayout class='monospaced'>
      $ ~/poky/poky/scripts/buildhistory-diff . HEAD^
-     Changes to images/qemux86_64/eglibc/core-image-minimal (files-in-image.txt):
+     Changes to images/qemux86_64/glibc/core-image-minimal (files-in-image.txt):
         /etc/anotherpkg.conf was added
         /sbin/anotherpkg was added
         * (installed-package-names.txt):
         *   anotherpkg was added
-     Changes to images/qemux86_64/eglibc/core-image-minimal (installed-package-names.txt):
+     Changes to images/qemux86_64/glibc/core-image-minimal (installed-package-names.txt):
         anotherpkg was added
      packages/qemux86_64-poky-linux/v86d: PACKAGES: added "v86d-extras"
         * PR changed from "r0" to "r1"

documentation/template/qa-code-permalinks.xsl

@@ -0,0 +1,23 @@
+<!--
+This XSL sheet enables creation of permalinks for <para><code>
+constructs.  Right now, this construct occurs only in the ref-manual
+book's qa issues and warnings chapter.  However, if the construct
+were to appear anywhere in that ref-manual, a permalink would be
+generated.  I don't foresee any <para><code> constructs being used
+in the future but if they are then a permalink with a generically
+numbered permalink would be generated.
+-->
+<xsl:stylesheet version="1.0"
+  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
+  xmlns:d="http://docbook.org/ns/docbook"
+  xmlns="http://www.w3.org/1999/xhtml">
+
+  <xsl:template match="para/code">
+    <xsl:apply-imports/>
+    <xsl:if test="$generate.permalink != 0">
+      <xsl:call-template name="permalink">
+        <xsl:with-param name="node" select=".."/>
+      </xsl:call-template>
+    </xsl:if>
+  </xsl:template>
+</xsl:stylesheet>

documentation/tools/mega-manual.sed

@@ -2,30 +2,30 @@
 # This style is for manual folders like "yocto-project-qs" and "poky-ref-manual".
 # This is the old way that did it.  Can't do that now that we have "bitbake-user-manual" strings
 # in the mega-manual.
-# s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.7\/[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.7\/yocto-project-qs\/yocto-project-qs.html#/\"link\" href=\"#/g
-s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.7\/poky-ref-manual\/poky-ref-manual.html#/\"link\" href=\"#/g
+# s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.7.3\/[a-z]*-[a-z]*-[a-z]*\/[a-z]*-[a-z]*-[a-z]*.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.7.3\/yocto-project-qs\/yocto-project-qs.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.7.3\/poky-ref-manual\/poky-ref-manual.html#/\"link\" href=\"#/g
 
 # Processes all other manuals (<word>-<word> style) except for the BitBake User Manual because
 # it is not included in the mega-manual.
 # This style is for manual folders that use two word, which is the standard now (e.g. "ref-manual").
 # This was the one-liner that worked before we introduced the BitBake User Manual, which is
 # not in the mega-manual.
-# s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.7\/[a-z]*-[a-z]*\/[a-z]*-[a-z]*.html#/\"link\" href=\"#/g
+# s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.7.3\/[a-z]*-[a-z]*\/[a-z]*-[a-z]*.html#/\"link\" href=\"#/g
 
-s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.7\/adt-manual\/adt-manual.html#/\"link\" href=\"#/g
-s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.7\/bsp-guide\/bsp-guide.html#/\"link\" href=\"#/g
-s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.7\/dev-manual\/dev-manual.html#/\"link\" href=\"#/g
-s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.7\/kernel-dev\/kernel-dev.html#/\"link\" href=\"#/g
-s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.7\/profile-manual\/profile-manual.html#/\"link\" href=\"#/g
-s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.7\/ref-manual\/ref-manual.html#/\"link\" href=\"#/g
-s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.7\/yocto-project-qs\/yocto-project-qs.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.7.3\/adt-manual\/adt-manual.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.7.3\/bsp-guide\/bsp-guide.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.7.3\/dev-manual\/dev-manual.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.7.3\/kernel-dev\/kernel-dev.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.7.3\/profile-manual\/profile-manual.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.7.3\/ref-manual\/ref-manual.html#/\"link\" href=\"#/g
+s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.7.3\/yocto-project-qs\/yocto-project-qs.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.7\/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.7\/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.7\/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.7\/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.7\/profile-manual\/profile-manual.html\" target=\"_top\">Yocto Project Profiling and Tracing Manual<\/a>/Yocto Project Profiling and Tracing Manual/g
-s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.7\/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.7\/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.7.3\/yocto-project-qs\/yocto-project-qs.html\" target=\"_top\">Yocto Project Quick Start<\/a>/Yocto Project Quick Start/g
+s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.7.3\/dev-manual\/dev-manual.html\" target=\"_top\">Yocto Project Development Manual<\/a>/Yocto Project Development Manual/g
+s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.7.3\/adt-manual\/adt-manual.html\" target=\"_top\">Yocto Project Application Developer's Guide<\/a>/Yocto Project Application Developer's Guide/g
+s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.7.3\/bsp-guide\/bsp-guide.html\" target=\"_top\">Yocto Project Board Support Package (BSP) Developer's Guide<\/a>/Yocto Project Board Support Package (BSP) Developer's Guide/g
+s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.7.3\/profile-manual\/profile-manual.html\" target=\"_top\">Yocto Project Profiling and Tracing Manual<\/a>/Yocto Project Profiling and Tracing Manual/g
+s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.7.3\/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.7.3\/ref-manual\/ref-manual.html\" target=\"_top\">Yocto Project Reference Manual<\/a>/Yocto Project Reference Manual/g

documentation/yocto-project-qs/yocto-project-qs-customization.xsl

@@ -1,7 +1,7 @@
 <?xml version='1.0'?>
 <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/1999/xhtml" xmlns:fo="http://www.w3.org/1999/XSL/Format" version="1.0">
 
-  <xsl:import href="http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl" />
+  <xsl:import href="http://docbook.sourceforge.net/release/xsl/1.76.1/xhtml/docbook.xsl" />
   <xsl:import href="yocto-project-qs-titlepage.xsl"/>
 
   <xsl:include href="../template/permalinks.xsl"/>

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

@@ -86,10 +86,12 @@
                 the Yocto Project Reference Manual.
                 </para></listitem>
             <listitem><para><emphasis>Developer Screencast:</emphasis> The
-                <ulink url='http://vimeo.com/36450321'>Getting Started with the Yocto Project - New
-                Developer Screencast Tutorial</ulink> provides a 30-minute video
-                created for users unfamiliar with the Yocto Project but familiar
-                with Linux build systems.</para></listitem>
+                <ulink url='http://vimeo.com/36450321'>Getting Started with the Yocto Project - New Developer Screencast Tutorial</ulink>
+                provides a 30-minute video created for users unfamiliar with
+                the Yocto Project but familiar with Linux build systems.
+                While this screencast is somewhat dated, the introductory
+                and fundamental concepts are useful for the beginner.
+                </para></listitem>
         </itemizedlist>
     </para>
 </section>
@@ -177,7 +179,8 @@
             decrease the time needed to build images.
             </para></listitem>
         <listitem><para>
-            The right packages.
+            Appropriate packages installed on the system you are using for
+            builds.
             </para></listitem>
         <listitem><para>
             A release of the Yocto Project.
@@ -509,7 +512,7 @@
              Another couple of variables of interest are the
              <ulink url='&YOCTO_DOCS_REF_URL;#var-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename></ulink> and the
              <ulink url='&YOCTO_DOCS_REF_URL;#var-PARALLEL_MAKE'><filename>PARALLEL_MAKE</filename></ulink> variables.
-             By default, these variables are set to how ever many processor
+             By default, these variables are set to the number of processor
              cores your build host uses.
              However, if your build host uses multiple processor cores,
              you should increase these settings to twice the number of
@@ -546,7 +549,7 @@
                  "<ulink url='&YOCTO_DOCS_REF_URL;#required-git-tar-and-python-versions'>Required Git, tar, and Python</ulink>"
                  section in the Yocto Project Reference Manual.
              </note>
-             The final command runs the image:
+             The final command runs the image using the QEMU emulator:
              <literallayout class='monospaced'>
      $ runqemu qemux86
              </literallayout>
@@ -622,25 +625,25 @@
             </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-glibc-<replaceable>host_system</replaceable>-<replaceable>image_type</replaceable>-<replaceable>arch</replaceable>-toolchain-<replaceable>release_version</replaceable>.sh
 
      Where:
-         &lt;<emphasis>host_system</emphasis>&gt; is a string representing your development system:
+         <replaceable>host_system</replaceable> is a string representing your development system:
 
                     i686 or x86_64.
 
-         &lt;<emphasis>image_type</emphasis>&gt; is a string representing the image you wish to
+         <replaceable>image_type</replaceable> is a string representing the image you wish to
                 develop a Software Development Toolkit (SDK) for use against.
                 The Yocto Project builds toolchain installers using the
                 following BitBake command:
 
                     bitbake core-image-sato -c populate_sdk
 
-         &lt;<emphasis>arch</emphasis>&gt; is a string representing the tuned target architecture:
+         <replaceable>arch</replaceable> is a string representing the tuned target architecture:
 
                     i586, x86_64, powerpc, mips, armv7a or armv5te
 
-         &lt;<emphasis>release_version</emphasis>&gt; is a string representing the release number of the
+         <replaceable>release_version</replaceable> is a string representing the release number of the
                 Yocto Project:
 
                     &DISTRO;, &DISTRO;+snapshot
@@ -651,7 +654,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-glibc-x86_64-core-image-sato-i586-toolchain-&DISTRO;.sh
                 </literallayout>
             </para>
 
@@ -680,7 +683,7 @@
 
             <para>
                 <literallayout class='monospaced'>
-     $ ~/Downloads/poky-eglibc-x86_64-core-image-sato-i586-toolchain-&DISTRO;.sh
+     $ ~/Downloads/poky-glibc-x86_64-core-image-sato-i586-toolchain-&DISTRO;.sh
                 </literallayout>
             </para>
 
@@ -706,11 +709,11 @@
             <para>
                 Most kernel files have one of the following forms:
                 <literallayout class='monospaced'>
-     *zImage-qemu&lt;<emphasis>arch</emphasis>&gt;.bin
-     vmlinux-qemu&lt;<emphasis>arch</emphasis>&gt;.bin
+     *zImage-qemu<replaceable>arch</replaceable>.bin
+     vmlinux-qemu<replaceable>arch</replaceable>.bin
 
      Where:
-         &lt;<emphasis>arch</emphasis>&gt; is a string representing the target architecture:
+         <replaceable>arch</replaceable> is a string representing the target architecture:
                 x86, x86-64, ppc, mips, or arm.
                 </literallayout>
             </para>
@@ -740,17 +743,17 @@
                 The <filename>tar</filename> form can be flattened out in your host development system
                 and used for build purposes with the Yocto Project.
                 <literallayout class='monospaced'>
-     core-image-&lt;<emphasis>profile</emphasis>&gt;-qemu&lt;<emphasis>arch</emphasis>&gt;.ext3
-     core-image-&lt;<emphasis>profile</emphasis>&gt;-qemu&lt;<emphasis>arch</emphasis>&gt;.tar.bz2
+     core-image-<replaceable>profile</replaceable>-qemu<replaceable>arch</replaceable>.ext3
+     core-image-<replaceable>profile</replaceable>-qemu<replaceable>arch</replaceable>.tar.bz2
 
      Where:
-         &lt;<emphasis>profile</emphasis>&gt; is the filesystem image's profile:
+         <replaceable>profile</replaceable> is the filesystem image's profile:
                    lsb, lsb-dev, lsb-sdk, lsb-qt3, minimal, minimal-dev, sato,
                    sato-dev, or sato-sdk. For information on these types of image
-                   profiles, see the "<ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Images</ulink>" chapter in the Yocto Project
-                   Reference Manual.
+                   profiles, see the "<ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Images</ulink>"
+                   chapter in the Yocto Project Reference Manual.
 
-         &lt;<emphasis>arch</emphasis>&gt; is a string representing the target architecture:
+         <replaceable>arch</replaceable> is a string representing the target architecture:
                 x86, x86-64, ppc, mips, or arm.
                 </literallayout>
             </para>
@@ -763,13 +766,13 @@
                 Before you start the QEMU emulator, you need to set up the emulation environment.
                 The following command form sets up the emulation environment.
                 <literallayout class='monospaced'>
-     $ source &YOCTO_ADTPATH_DIR;/environment-setup-&lt;<emphasis>arch</emphasis>&gt;-poky-linux-&lt;<emphasis>if</emphasis>&gt;
+     $ source &YOCTO_ADTPATH_DIR;/environment-setup-<replaceable>arch</replaceable>-poky-linux-<replaceable>if</replaceable>
 
      Where:
-         &lt;<emphasis>arch</emphasis>&gt; is a string representing the target architecture:
+         <replaceable>arch</replaceable> is a string representing the target architecture:
                 i586, x86_64, ppc603e, mips, or armv5te.
 
-         &lt;<emphasis>if</emphasis>&gt; is a string representing an embedded application binary interface.
+         <replaceable>if</replaceable> is a string representing an embedded application binary interface.
               Not all setup scripts include this string.
                 </literallayout>
             </para>
@@ -777,15 +780,15 @@
             <para>
                 Finally, this command form invokes the QEMU emulator
                 <literallayout class='monospaced'>
-     $ runqemu &lt;<emphasis>qemuarch</emphasis>&gt; &lt;<emphasis>kernel-image</emphasis>&gt; &lt;<emphasis>filesystem-image</emphasis>&gt;
+     $ runqemu <replaceable>qemuarch</replaceable> <replaceable>kernel-image</replaceable> <replaceable>filesystem-image</replaceable>
 
      Where:
-         &lt;<emphasis>qemuarch</emphasis>&gt; is a string representing the target architecture: qemux86, qemux86-64,
+         <replaceable>qemuarch</replaceable> is a string representing the target architecture: qemux86, qemux86-64,
                     qemuppc, qemumips, or qemuarm.
 
-         &lt;<emphasis>kernel-image</emphasis>&gt; is the architecture-specific kernel image.
+         <replaceable>kernel-image</replaceable> is the architecture-specific kernel image.
 
-         &lt;<emphasis>filesystem-image</emphasis>&gt; is the .ext3 filesystem image.
+         <replaceable>filesystem-image</replaceable> is the .ext3 filesystem image.
 
                 </literallayout>
             </para>

meta-yocto-bsp/conf/machine/beaglebone.conf

@@ -35,3 +35,5 @@ UBOOT_ENTRYPOINT = "0x80008000"
 UBOOT_LOADADDRESS = "0x80008000"
 
 MACHINE_FEATURES = "usbgadget usbhost vfat alsa"
+
+IMAGE_BOOT_FILES ?= "u-boot.${UBOOT_SUFFIX} MLO"

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

@@ -7,11 +7,11 @@ KBRANCH_mpc8315e-rdb = "standard/fsl-mpc8315e-rdb"
 KMACHINE_genericx86 ?= "common-pc"
 KMACHINE_genericx86-64 ?= "common-pc-64"
 
-SRCREV_machine_genericx86 ?= "cc12b028076c0a7de042195fb73998aec351f4f2"
-SRCREV_machine_genericx86-64 ?= "47956b735bf67acca4f36af8c3dc18bef3e7c12e"
-SRCREV_machine_edgerouter ?= "47956b735bf67acca4f36af8c3dc18bef3e7c12e"
-SRCREV_machine_beaglebone ?= "47956b735bf67acca4f36af8c3dc18bef3e7c12e"
-SRCREV_machine_mpc8315e-rdb ?= "a6b4507afe330d589193bb50d7d961cd21ee3dd2"
+SRCREV_machine_genericx86 ?= "a39fd81fa54776b2ac8c288251846890c3124dee"
+SRCREV_machine_genericx86-64 ?= "dbe5b52e93ff114b2c0f5da6f6af91f52c18f2b8"
+SRCREV_machine_edgerouter ?= "dbe5b52e93ff114b2c0f5da6f6af91f52c18f2b8"
+SRCREV_machine_beaglebone ?= "dbe5b52e93ff114b2c0f5da6f6af91f52c18f2b8"
+SRCREV_machine_mpc8315e-rdb ?= "4b2929392ec56ca8ef90cc98042609795c44aa3c"
 
 COMPATIBLE_MACHINE_genericx86 = "genericx86"
 COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64"

meta-yocto/conf/distro/poky.conf

@@ -1,7 +1,7 @@
 DISTRO = "poky"
 DISTRO_NAME = "Poky (Yocto Project Reference Distro)"
-DISTRO_VERSION = "1.6+snapshot-${DATE}"
-DISTRO_CODENAME = "next"
+DISTRO_VERSION = "1.7.3"
+DISTRO_CODENAME = "dizzy"
 SDK_VENDOR = "-pokysdk"
 SDK_VERSION := "${@'${DISTRO_VERSION}'.replace('snapshot-${DATE}','snapshot')}"
 
@@ -76,6 +76,7 @@ SANITY_TESTED_DISTROS ?= " \
             Poky-1.4 \n \
             Poky-1.5 \n \
             Poky-1.6 \n \
+            Poky-1.7 \n \
             Ubuntu-12.04 \n \
             Ubuntu-13.10 \n \
             Ubuntu-14.04 \n \
@@ -90,6 +91,7 @@ SANITY_TESTED_DISTROS ?= " \
             Debian-7.4 \n \
             Debian-7.5 \n \
             Debian-7.6 \n \
+            Debian-7.7 \n \
             SUSE-LINUX-12.2 \n \
             openSUSE-project-12.3 \n \
             openSUSE-project-13.1 \n \
@@ -110,7 +112,7 @@ INHERIT += "poky-sanity"
 
 # QA check settings - a little stricter than the OE-Core defaults
 WARN_QA = "textrel files-invalid incompatible-license xorg-driver-abi libdir \
-           unknown-configure-option build-deps"
+           unknown-configure-option build-deps file-rdeps"
 ERROR_QA = "dev-so debug-deps dev-deps debug-files arch pkgconfig la perms \
             useless-rpaths rpaths staticdev ldflags pkgvarcheck already-stripped \
             compile-host-path dep-cmp installed-vs-shipped install-host-path \

meta-yocto/conf/local.conf.sample.extended

@@ -361,3 +361,14 @@
 # feed layout is used where package files are placed in <outdir>/<arch>/.
 #
 #IPK_HIERARCHICAL_FEED = "1"
+#
+
+# Using RPM4
+#
+# Currently the rootfs_rpm code has a hard depends on rpmresolve:do_populate_sysroot,
+# when using rpm4 the rpmresolve code will not compile due to a missing header file.
+# That dependency needs to be removed when using RPM4, also the PREFRRED_VERSION needs
+# to be set. This example shows how to enable rpm4
+# PREFERRED_VERSION_rpm = "4.11.2"
+# PREFERRED_VERSION_rpm-native = "4.11.2"
+# RPMROOTFSDEPENDS_remove = "rpmresolve-native:do_populate_sysroot"

meta/classes/allarch.bbclass

@@ -27,6 +27,10 @@ python () {
         d.setVar("PACKAGE_EXTRA_ARCHS", "")
         d.setVar("SDK_ARCH", "none")
         d.setVar("SDK_CC_ARCH", "none")
+        d.setVar("TARGET_CPPFLAGS", "none")
+        d.setVar("TARGET_CFLAGS", "none")
+        d.setVar("TARGET_CXXFLAGS", "none")
+        d.setVar("TARGET_LDFLAGS", "none")
 
         # Avoid this being unnecessarily different due to nuances of
         # the target machine that aren't important for "all" arch

meta/classes/autotools.bbclass

@@ -86,7 +86,7 @@ oe_runconf () {
 		${CACHED_CONFIGUREVARS} $cfgscript ${CONFIGUREOPTS} ${EXTRA_OECONF} "$@"
 		if [ "$?" != "0" ]; then
 			echo "Configure failed. The contents of all config.log files follows to aid debugging"
-			find ${S} -name config.log -print -exec cat {} \;
+			find ${S} -ignore_readdir_race -name config.log -print -exec cat {} \;
 			bbfatal "oe_runconf failed"
 		fi
 		set -e
@@ -105,7 +105,7 @@ autotools_preconfigure() {
 			if [ "${S}" != "${B}" ]; then
 				echo "Previously configured separate build directory detected, cleaning ${B}"
 				rm -rf ${B}
-				mkdir ${B}
+				mkdir -p ${B}
 			else
 				# At least remove the .la files since automake won't automatically
 				# regenerate them even if CFLAGS/LDFLAGS are different

meta/classes/base.bbclass

@@ -97,6 +97,7 @@ PATH_prepend = "${@extra_path_elements(d)}"
 addtask fetch
 do_fetch[dirs] = "${DL_DIR}"
 do_fetch[file-checksums] = "${@bb.fetch.get_checksum_file_list(d)}"
+do_fetch[vardeps] += "SRCREV"
 python base_do_fetch() {
 
     src_uri = (d.getVar('SRC_URI', True) or "").split()
@@ -433,12 +434,30 @@ python () {
             bad_licenses = map(lambda l: canonical_license(d, l), bad_licenses)
 
             whitelist = []
+            incompatwl = []
+            htincompatwl = []
             for lic in bad_licenses:
+                spdx_license = return_spdx(d, lic)
                 for w in ["HOSTTOOLS_WHITELIST_", "LGPLv2_WHITELIST_", "WHITELIST_"]:
                     whitelist.extend((d.getVar(w + lic, True) or "").split())
-                spdx_license = return_spdx(d, lic)
-                if spdx_license:
-                    whitelist.extend((d.getVar('HOSTTOOLS_WHITELIST_%s' % spdx_license, True) or "").split())
+                    if spdx_license:
+                        whitelist.extend((d.getVar(w + spdx_license, True) or "").split())
+                    '''
+                    We need to track what we are whitelisting and why. If pn is 
+                    incompatible and is not HOSTTOOLS_WHITELIST_ we need to be 
+                    able to note that the image that is created may infact 
+                    contain incompatible licenses despite INCOMPATIBLE_LICENSE 
+                    being set.
+                    '''
+                    if "HOSTTOOLS" in w:
+                        htincompatwl.extend((d.getVar(w + lic, True) or "").split())
+                        if spdx_license:
+                            htincompatwl.extend((d.getVar(w + spdx_license, True) or "").split())
+                    else:
+                        incompatwl.extend((d.getVar(w + lic, True) or "").split())
+                        if spdx_license:
+                            incompatwl.extend((d.getVar(w + spdx_license, True) or "").split())
+
             if not pn in whitelist:
                 recipe_license = d.getVar('LICENSE', True)
                 pkgs = d.getVar('PACKAGES', True).split()
@@ -459,6 +478,11 @@ python () {
                 elif all_skipped or incompatible_license(d, bad_licenses):
                     bb.debug(1, "SKIPPING recipe %s because it's %s" % (pn, recipe_license))
                     raise bb.parse.SkipPackage("incompatible with license %s" % recipe_license)
+            elif pn in whitelist:
+                if pn in incompatwl:
+                    bb.note("INCLUDING " + pn + " as buildable despite INCOMPATIBLE_LICENSE because it has been whitelisted")
+                elif pn in htincompatwl:
+                    bb.note("INCLUDING " + pn + " as buildable despite INCOMPATIBLE_LICENSE because it has been whitelisted for HOSTTOOLS")
 
     srcuri = d.getVar('SRC_URI', True)
     # Svn packages should DEPEND on subversion-native

meta/classes/cmake.bbclass

@@ -34,10 +34,13 @@ set( CMAKE_SYSTEM_NAME `echo ${TARGET_OS} | sed -e 's/^./\u&/' -e 's/^\(Linux\).
 set( CMAKE_SYSTEM_PROCESSOR ${TARGET_ARCH} )
 set( CMAKE_C_COMPILER ${OECMAKE_C_COMPILER} )
 set( CMAKE_CXX_COMPILER ${OECMAKE_CXX_COMPILER} )
+set( CMAKE_ASM_COMPILER ${OECMAKE_C_COMPILER} )
 set( CMAKE_C_FLAGS "${OECMAKE_C_FLAGS}" CACHE STRING "CFLAGS" )
 set( CMAKE_CXX_FLAGS "${OECMAKE_CXX_FLAGS}" CACHE STRING "CXXFLAGS" )
+set( CMAKE_ASM_FLAGS "${OECMAKE_C_FLAGS}" CACHE STRING "ASM FLAGS" )
 set( CMAKE_C_FLAGS_RELEASE "${OECMAKE_C_FLAGS_RELEASE}" CACHE STRING "CFLAGS for release" )
 set( CMAKE_CXX_FLAGS_RELEASE "${OECMAKE_CXX_FLAGS_RELEASE}" CACHE STRING "CXXFLAGS for release" )
+set( CMAKE_ASM_FLAGS_RELEASE "${OECMAKE_C_FLAGS_RELEASE}" CACHE STRING "ASM FLAGS for release" )
 set( CMAKE_C_LINK_FLAGS "${OECMAKE_C_LINK_FLAGS}" CACHE STRING "LDFLAGS" )
 set( CMAKE_CXX_LINK_FLAGS "${OECMAKE_CXX_LINK_FLAGS}" CACHE STRING "LDFLAGS" )
 

meta/classes/cml1.bbclass

@@ -9,10 +9,11 @@ addtask configure after do_unpack do_patch before do_compile
 
 inherit terminal
 
-OE_TERMINAL_EXPORTS += "HOST_EXTRACFLAGS HOSTLDFLAGS HOST_LOADLIBES TERMINFO"
+OE_TERMINAL_EXPORTS += "HOST_EXTRACFLAGS HOSTLDFLAGS TERMINFO CROSS_CURSES_LIB CROSS_CURSES_INC"
 HOST_EXTRACFLAGS = "${BUILD_CFLAGS} ${BUILD_LDFLAGS}"
 HOSTLDFLAGS = "${BUILD_LDFLAGS}"
-HOST_LOADLIBES = "-lncurses"
+CROSS_CURSES_LIB = "-lncurses -ltinfo"
+CROSS_CURSES_INC = '-DCURSES_LOC="<curses.h>"'
 TERMINFO = "${STAGING_DATADIR_NATIVE}/terminfo"
 
 python do_menuconfig() {

meta/classes/compress_doc.bbclass

@@ -29,7 +29,7 @@ DOC_DECOMPRESS_CMD[gz] ?= 'gunzip -v'
 DOC_DECOMPRESS_CMD[bz2] ?= "bunzip2 -v"
 DOC_DECOMPRESS_CMD[xz] ?= "unxz -v"
 
-PACKAGE_PREPROCESS_FUNCS += "package_do_compress_doc"
+PACKAGE_PREPROCESS_FUNCS += "package_do_compress_doc compress_doc_updatealternatives"
 python package_do_compress_doc() {
     compress_mode = d.getVar('DOC_COMPRESS', True)
     compress_list = (d.getVar('DOC_COMPRESS_LIST', True) or '').split()
@@ -211,3 +211,46 @@ def decompress_doc(topdir, compress_mode, decompress_cmds):
 
     _process_hardlink(hardlink_dict, compress_mode, decompress_cmds, decompress)
 
+python compress_doc_updatealternatives () {
+    if not bb.data.inherits_class('update-alternatives', d):
+        return
+
+    mandir = d.getVar("mandir", True)
+    infodir = d.getVar("infodir", True)
+    compress_mode = d.getVar('DOC_COMPRESS', True)
+    for pkg in (d.getVar('PACKAGES', True) or "").split():
+        old_names = (d.getVar('ALTERNATIVE_%s' % pkg, True) or "").split()
+        new_names = []
+        for old_name in old_names:
+            old_link     = d.getVarFlag('ALTERNATIVE_LINK_NAME', old_name, True)
+            old_target   = d.getVarFlag('ALTERNATIVE_TARGET_%s' % pkg, old_name, True) or \
+                d.getVarFlag('ALTERNATIVE_TARGET', old_name, True) or \
+                d.getVar('ALTERNATIVE_TARGET_%s' % pkg, True) or \
+                d.getVar('ALTERNATIVE_TARGET', True) or \
+                old_link
+            # Sometimes old_target is specified as relative to the link name.
+            old_target   = os.path.join(os.path.dirname(old_link), old_target)
+
+            # The updatealternatives used for compress doc
+            if mandir in old_target or infodir in old_target:
+                new_name = old_name + '.' + compress_mode
+                new_link = old_link + '.' + compress_mode
+                new_target = old_target + '.' + compress_mode
+                d.delVarFlag('ALTERNATIVE_LINK_NAME', old_name)
+                d.setVarFlag('ALTERNATIVE_LINK_NAME', new_name, new_link)
+                if d.getVarFlag('ALTERNATIVE_TARGET_%s' % pkg, old_name, True):
+                    d.delVarFlag('ALTERNATIVE_TARGET_%s' % pkg, old_name)
+                    d.setVarFlag('ALTERNATIVE_TARGET_%s' % pkg, new_name, new_target)
+                elif d.getVarFlag('ALTERNATIVE_TARGET', old_name, True):
+                    d.delVarFlag('ALTERNATIVE_TARGET', old_name)
+                    d.setVarFlag('ALTERNATIVE_TARGET', new_name, new_target)
+                elif d.getVar('ALTERNATIVE_TARGET_%s' % pkg, True):
+                    d.setVar('ALTERNATIVE_TARGET_%s' % pkg, new_target)
+                elif d.getVar('ALTERNATIVE_TARGET', old_name, True):
+                    d.setVar('ALTERNATIVE_TARGET', new_target)
+
+                new_names.append(new_name)
+
+        if new_names:
+            d.setVar('ALTERNATIVE_%s' % pkg, ' '.join(new_names))
+}

meta/classes/cross-canadian.bbclass

@@ -16,6 +16,7 @@ STAGING_BINDIR_TOOLCHAIN = "${STAGING_DIR_NATIVE}${bindir_native}/${SDK_ARCH}${S
 #
 PACKAGE_ARCH = "${SDK_ARCH}-${SDKPKGSUFFIX}"
 CANADIANEXTRAOS = ""
+MODIFYTOS ??= "1"
 python () {
     archs = d.getVar('PACKAGE_ARCHS', True).split()
     sdkarchs = []
@@ -23,6 +24,9 @@ python () {
         sdkarchs.append(arch + '-${SDKPKGSUFFIX}')
     d.setVar('PACKAGE_ARCHS', " ".join(sdkarchs))
 
+    # Allow the following code segment to be disabled, e.g. meta-environment
+    if d.getVar("MODIFYTOS", True) != "1":
+        return
     # PowerPC can build "linux" and "linux-gnuspe"
     tarch = d.getVar("TARGET_ARCH", True)
     if tarch == "powerpc":
@@ -111,6 +115,7 @@ export PKG_CONFIG_DIR = "${STAGING_DIR_HOST}${layout_libdir}/pkgconfig"
 export PKG_CONFIG_SYSROOT_DIR = "${STAGING_DIR_HOST}"
 
 do_populate_sysroot[stamp-extra-info] = ""
+do_packagedata[stamp-extra-info] = ""
 
 USE_NLS = "${SDKUSE_NLS}"
 

meta/classes/fontcache.bbclass

@@ -8,13 +8,24 @@ inherit qemu
 
 FONT_PACKAGES ??= "${PN}"
 FONT_EXTRA_RDEPENDS ?= "fontconfig-utils"
-
+FONTCONFIG_CACHE_DIR ?= "${localstatedir}/cache/fontconfig"
+FONTCONFIG_CACHE_PARAMS ?= "-v"
+# You can change this to e.g. FC_DEBUG=16 to debug fc-cache issues,
+# something has to be set, because qemuwrapper is using this variable after -E
+# multiple variables aren't allowed because for qemu they are separated
+# by comma and in -n "$D" case they should be separated by space
+FONTCONFIG_CACHE_ENV ?= "FC_DEBUG=1"
 fontcache_common() {
-if [ "x$D" != "x" ] ; then
-	$INTERCEPT_DIR/postinst_intercept update_font_cache ${PKG} mlprefix=${MLPREFIX} bindir=${bindir} \
-		libdir=${libdir} base_libdir=${base_libdir}
+if [ -n "$D" ] ; then
+	$INTERCEPT_DIR/postinst_intercept update_font_cache ${PKG} mlprefix=${MLPREFIX} \
+		'bindir="${bindir}"' \
+		'libdir="${libdir}"' \
+		'base_libdir="${base_libdir}"' \
+		'fontconfigcachedir="${FONTCONFIG_CACHE_DIR}"' \
+		'fontconfigcacheparams="${FONTCONFIG_CACHE_PARAMS}"' \
+		'fontconfigcacheenv="${FONTCONFIG_CACHE_ENV}"'
 else
-	fc-cache
+	${FONTCONFIG_CACHE_ENV} fc-cache ${FONTCONFIG_CACHE_PARAMS}
 fi
 }
 
@@ -42,4 +53,4 @@ python add_fontcache_postinsts() {
         d.setVar('pkg_postrm_%s' % pkg, postrm)
 }
 
-PACKAGEFUNCS += "add_fontcache_postinsts"
+PACKAGEFUNCS =+ "add_fontcache_postinsts"

meta/classes/gnome.bbclass

@@ -1,5 +1 @@
 inherit gnomebase gtk-icon-cache gconf mime
-
-EXTRA_OECONF += "--disable-introspection"
-
-UNKNOWN_CONFIGURE_WHITELIST += "--disable-introspection"

meta/classes/gnomebase.bbclass

@@ -9,13 +9,13 @@ SRC_URI = "${GNOME_MIRROR}/${GNOMEBN}/${@gnome_verdir("${PV}")}/${GNOMEBN}-${PV}
 DEPENDS += "gnome-common-native"
 
 FILES_${PN} += "${datadir}/application-registry  \
-	${datadir}/mime-info \
-	${datadir}/mime/packages \
-	${datadir}/mime/application \
-	${datadir}/gnome-2.0 \
-	${datadir}/polkit* \
-	${datadir}/GConf \
-	${datadir}/glib-2.0/schemas \
+                ${datadir}/mime-info \
+                ${datadir}/mime/packages \
+                ${datadir}/mime/application \
+                ${datadir}/gnome-2.0 \
+                ${datadir}/polkit* \
+                ${datadir}/GConf \
+                ${datadir}/glib-2.0/schemas \
 "
 
 FILES_${PN}-doc += "${datadir}/devhelp"
@@ -28,3 +28,6 @@ do_install_append() {
 	rm -f ${D}${datadir}/applications/*.cache
 }
 
+EXTRA_OECONF += "--disable-introspection"
+
+UNKNOWN_CONFIGURE_WHITELIST += "--disable-introspection"

meta/classes/icecc.bbclass

@@ -91,6 +91,10 @@ def create_path(compilers, bb, d):
     return staging
 
 def use_icc(bb,d):
+    if d.getVar('ICECC_DISABLED') == "1":
+        # don't even try it, when explicitly disabled
+        return "no"
+
     # allarch recipes don't use compiler
     if icc_is_allarch(bb, d):
         return "no"
@@ -133,8 +137,7 @@ def use_icc(bb,d):
     return "yes"
 
 def icc_is_allarch(bb, d):
-    return \
-        bb.data.inherits_class("allarch", d);
+    return d.getVar("PACKAGE_ARCH") == "all"
 
 def icc_is_kernel(bb, d):
     return \
@@ -148,10 +151,6 @@ def icc_is_native(bb, d):
 # Don't pollute allarch signatures with TARGET_FPU
 icc_version[vardepsexclude] += "TARGET_FPU"
 def icc_version(bb, d):
-    if d.getVar('ICECC_DISABLED') == "1":
-        # don't even try it, when explicitly disabled
-        return ""
-
     if use_icc(bb, d) == "no":
         return ""
 
@@ -179,7 +178,7 @@ def icc_version(bb, d):
     return tar_file
 
 def icc_path(bb,d):
-    if d.getVar('ICECC_DISABLED') == "1":
+    if use_icc(bb, d) == "no":
         # don't create unnecessary directories when icecc is disabled
         return
 
@@ -246,7 +245,7 @@ def set_icecc_env():
     return
 
 set_icecc_env() {
-    if [ "${ICECC_DISABLED}" = "1" ]
+    if [ "${@use_icc(bb, d)}" = "no" ]
     then
         return
     fi