kernel.bbclass: Complete fix for modules symlink

The fix backported in commit aa9fc551 of oe-core does not completely fix the
issue (Yocto #4595) as intended. The modules symlink is still created in the
working directory instead of in the deploy directory. To fix this, we just need
to use an absolute path to ${DEPLOYDIR} when creating the symlink.

(From OE-Core rev: f07a4e0d80f5e0dd94514f6aae11a7bd56034f30)

Signed-off-by: Paul Barker <paul.barker@commagility.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

bitbake/lib/bb/cache.py

@@ -526,7 +526,7 @@ class Cache(object):
 
         if appends != info_array[0].appends:
             logger.debug(2, "Cache: appends for %s changed", fn)
-            bb.note("%s to %s" % (str(appends), str(info_array[0].appends)))
+            logger.debug(2, "%s to %s" % (str(appends), str(info_array[0].appends)))
             self.remove(fn)
             return False
 

bitbake/lib/bb/cooker.py

@@ -1486,7 +1486,10 @@ class BBCooker:
         # Empty the environment. The environment will be populated as
         # necessary from the data store.
         #bb.utils.empty_environment()
-        prserv.serv.auto_start(self.configuration.data)
+        try:
+            prserv.serv.auto_start(self.configuration.data)
+        except prserv.serv.PRServiceConfigError:
+            bb.event.fire(CookerExit(), self.configuration.event_data)
         return
 
     def post_serve(self):
@@ -1603,6 +1606,7 @@ class Parser(multiprocessing.Process):
         self.quit = quit
         self.init = init
         multiprocessing.Process.__init__(self)
+        self.context = bb.utils._context.copy()
 
     def run(self):
         if self.init:
@@ -1637,6 +1641,7 @@ class Parser(multiprocessing.Process):
 
     def parse(self, filename, appends, caches_array):
         try:
+            bb.utils._context = self.context.copy()
             return True, bb.cache.Cache.parse(filename, appends, self.cfg, caches_array)
         except Exception as exc:
             tb = sys.exc_info()[2]

bitbake/lib/bb/data_smart.py

@@ -738,5 +738,21 @@ class DataSmart(MutableMapping):
             value = d.getVar(key, False) or ""
             data.update({key:value})
 
+            varflags = d.getVarFlags(key)
+            if not varflags:
+                continue
+            for f in varflags:
+                data.update({'%s[%s]' % (key, f):varflags[f]})
+
+        for key in ["__BBTASKS", "__BBANONFUNCS", "__BBHANDLERS"]:
+            bb_list = d.getVar(key, False) or []
+            bb_list.sort()
+            data.update({key:str(bb_list)})
+
+            if key == "__BBANONFUNCS":
+                for i in bb_list:
+                    value = d.getVar(i, True) or ""
+                    data.update({i:value})
+
         data_str = str([(k, data[k]) for k in sorted(data.keys())])
         return hashlib.md5(data_str).hexdigest()

bitbake/lib/bb/fetch2/__init__.py

@@ -325,7 +325,7 @@ def decodeurl(url):
     user, password, parameters).
     """
 
-    m = re.compile('(?P<type>[^:]*)://((?P<user>.+)@)?(?P<location>[^;]+)(;(?P<parm>.*))?').match(url)
+    m = re.compile('(?P<type>[^:]*)://((?P<user>[^/]+)@)?(?P<location>[^;]+)(;(?P<parm>.*))?').match(url)
     if not m:
         raise MalformedUrl(url)
 
@@ -756,6 +756,19 @@ def build_mirroruris(origud, mirrors, ld):
 
     return uris, uds
 
+def rename_bad_checksum(ud, suffix):
+    """
+    Renames files to have suffix from parameter
+    """
+
+    if ud.localpath is None:
+        return
+
+    new_localpath = "%s_bad-checksum_%s" % (ud.localpath, suffix)
+    bb.warn("Renaming %s to %s" % (ud.localpath, new_localpath))
+    bb.utils.movefile(ud.localpath, new_localpath)
+
+
 def try_mirror_url(newuri, origud, ud, ld, check = False):
     # Return of None or a value means we're finished
     # False means try another url
@@ -807,7 +820,7 @@ def try_mirror_url(newuri, origud, ud, ld, check = False):
         if isinstance(e, ChecksumError):
             logger.warn("Mirror checksum failure for url %s (original url: %s)\nCleaning and trying again." % (newuri, origud.url))
             logger.warn(str(e))
-            self.rename_bad_checksum(ud, e.checksum)
+            rename_bad_checksum(ud, e.checksum)
         elif isinstance(e, NoChecksumError):
             raise
         else:
@@ -976,13 +989,13 @@ class FetchData(object):
             self.sha256_name = "sha256sum"
         if self.md5_name in self.parm:
             self.md5_expected = self.parm[self.md5_name]
-        elif self.type not in ["http", "https", "ftp", "ftps"]:
+        elif self.type not in ["http", "https", "ftp", "ftps", "sftp"]:
             self.md5_expected = None
         else:
             self.md5_expected = d.getVarFlag("SRC_URI", self.md5_name)
         if self.sha256_name in self.parm:
             self.sha256_expected = self.parm[self.sha256_name]
-        elif self.type not in ["http", "https", "ftp", "ftps"]:
+        elif self.type not in ["http", "https", "ftp", "ftps", "sftp"]:
             self.sha256_expected = None
         else:
             self.sha256_expected = d.getVarFlag("SRC_URI", self.sha256_name)
@@ -1392,7 +1405,7 @@ class Fetch(object):
                         if isinstance(e, ChecksumError):
                             logger.warn("Checksum failure encountered with download of %s - will attempt other sources if available" % u)
                             logger.debug(1, str(e))
-                            self.rename_bad_checksum(ud, e.checksum)
+                            rename_bad_checksum(ud, e.checksum)
                         elif isinstance(e, NoChecksumError):
                             raise
                         else:
@@ -1500,18 +1513,6 @@ class Fetch(object):
             if ud.lockfile:
                 bb.utils.unlockfile(lf)
 
-    def rename_bad_checksum(self, ud, suffix):
-        """
-        Renames files to have suffix from parameter
-        """
-
-        if ud.localpath is None:
-            return
-
-        new_localpath = "%s_bad-checksum_%s" % (ud.localpath, suffix)
-        bb.warn("Renaming %s to %s" % (ud.localpath, new_localpath))
-        bb.utils.movefile(ud.localpath, new_localpath)
-
 from . import cvs
 from . import git
 from . import gitsm

bitbake/lib/bb/fetch2/git.py

@@ -217,6 +217,10 @@ class Git(FetchMethod):
     def build_mirror_data(self, url, ud, d):
         # Generate a mirror tarball if needed
         if ud.write_tarballs and (ud.repochanged or not os.path.exists(ud.fullmirror)):
+            # it's possible that this symlink points to read-only filesystem with PREMIRROR
+            if os.path.islink(ud.fullmirror):
+                os.unlink(ud.fullmirror)
+
             os.chdir(ud.clonedir)
             logger.info("Creating tarball of git repository")
             runfetchcmd("tar -czf %s %s" % (ud.fullmirror, os.path.join(".") ), d)

bitbake/lib/bb/fetch2/hg.py

@@ -92,7 +92,10 @@ class Hg(FetchMethod):
         if not ud.user:
             hgroot = host + ud.path
         else:
-            hgroot = ud.user + "@" + host + ud.path
+            if ud.pswd:
+                hgroot = ud.user + ":" + ud.pswd + "@" + host + ud.path
+            else:
+                hgroot = ud.user + "@" + host + ud.path
 
         if command == "info":
             return "%s identify -i %s://%s/%s" % (basecmd, proto, hgroot, ud.module)
@@ -112,7 +115,10 @@ class Hg(FetchMethod):
             # do not pass options list; limiting pull to rev causes the local
             # repo not to contain it and immediately following "update" command
             # will crash
-            cmd = "%s pull" % (basecmd)
+            if ud.user and ud.pswd:
+                cmd = "%s --config auth.default.prefix=* --config auth.default.username=%s --config auth.default.password=%s --config \"auth.default.schemes=%s\" pull" % (basecmd, ud.user, ud.pswd, proto)
+            else:
+                cmd = "%s pull" % (basecmd)
         elif command == "update":
             cmd = "%s update -C %s" % (basecmd, " ".join(options))
         else:

bitbake/lib/bb/fetch2/perforce.py

@@ -112,7 +112,7 @@ class Perforce(FetchMethod):
         base = path
         which = path.find('/...')
         if which != -1:
-            base = path[:which]
+            base = path[:which-1]
 
         base = self._strip_leading_slashes(base)
 

bitbake/lib/bb/fetch2/svn.py

@@ -27,6 +27,7 @@ import os
 import sys
 import logging
 import bb
+import re
 from   bb import data
 from   bb.fetch2 import FetchMethod
 from   bb.fetch2 import FetchError
@@ -89,6 +90,8 @@ class Svn(FetchMethod):
 
         if command == "info":
             svncmd = "%s info %s %s://%s/%s/" % (ud.basecmd, " ".join(options), proto, svnroot, ud.module)
+        elif command == "log1":
+            svncmd = "%s log --limit 1 %s %s://%s/%s/" % (ud.basecmd, " ".join(options), proto, svnroot, ud.module)
         else:
             suffix = ""
             if ud.revision:
@@ -165,14 +168,13 @@ class Svn(FetchMethod):
         """
         Return the latest upstream revision number
         """
-        bb.fetch2.check_network_access(d, self._buildsvncommand(ud, d, "info"))
+        bb.fetch2.check_network_access(d, self._buildsvncommand(ud, d, "log1"))
 
-        output = runfetchcmd("LANG=C LC_ALL=C " + self._buildsvncommand(ud, d, "info"), d, True)
+        output = runfetchcmd("LANG=C LC_ALL=C " + self._buildsvncommand(ud, d, "log1"), d, True)
 
-        revision = None
-        for line in output.splitlines():
-            if "Last Changed Rev" in line:
-                revision = line.split(":")[1].strip()
+        # skip the first line, as per output of svn log
+        # then we expect the revision on the 2nd line
+        revision = re.search('^r([0-9]*)', output.splitlines()[1]).group(1)
 
         return revision
 

bitbake/lib/bb/methodpool.py

@@ -17,24 +17,7 @@
 # with this program; if not, write to the Free Software Foundation, Inc.,
 # 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
 
-
-"""
-    What is a method pool?
-
-    BitBake has a global method scope where .bb, .inc and .bbclass
-    files can install methods. These methods are parsed from strings.
-    To avoid recompiling and executing these string we introduce
-    a method pool to do this task.
-
-    This pool will be used to compile and execute the functions. It
-    will be smart enough to
-"""
-
 from bb.utils import better_compile, better_exec
-from bb       import error
-
-# A dict of function names we have seen
-_parsed_fns     = { }
 
 def insert_method(modulename, code, fn):
     """
@@ -43,29 +26,3 @@ def insert_method(modulename, code, fn):
     """
     comp = better_compile(code, modulename, fn )
     better_exec(comp, None, code, fn)
-
-    # now some instrumentation
-    code = comp.co_names
-    for name in code:
-        if name in ['None', 'False']:
-            continue
-        elif name in _parsed_fns and not _parsed_fns[name] == modulename:
-            error("The function %s defined in %s was already declared in %s. BitBake has a global python function namespace so shared functions should be declared in a common include file rather than being duplicated, or if the functions are different, please use different function names." % (name, modulename, _parsed_fns[name]))
-        else:
-            _parsed_fns[name] = modulename
-
-# A dict of modules the parser has finished with
-_parsed_methods = {}
-
-def parsed_module(modulename):
-    """
-    Has module been parsed?
-    """
-    return modulename in _parsed_methods
-
-def set_parsed_module(modulename):
-    """
-    Set module as parsed
-    """
-    _parsed_methods[modulename] = True
-

bitbake/lib/bb/parse/ast.py

@@ -148,9 +148,8 @@ class MethodNode(AstNode):
         text = '\n'.join(self.body)
         if self.func_name == "__anonymous":
             funcname = ("__anon_%s_%s" % (self.lineno, self.filename.translate(string.maketrans('/.+-', '____'))))
-            if not funcname in bb.methodpool._parsed_fns:
-                text = "def %s(d):\n" % (funcname) + text
-                bb.methodpool.insert_method(funcname, text, self.filename)
+            text = "def %s(d):\n" % (funcname) + text
+            bb.methodpool.insert_method(funcname, text, self.filename)
             anonfuncs = data.getVar('__BBANONFUNCS') or []
             anonfuncs.append(funcname)
             data.setVar('__BBANONFUNCS', anonfuncs)
@@ -171,8 +170,7 @@ class PythonMethodNode(AstNode):
         # 'this' file. This means we will not parse methods from
         # bb classes twice
         text = '\n'.join(self.body)
-        if not bb.methodpool.parsed_module(self.modulename):
-            bb.methodpool.insert_method(self.modulename, text, self.filename)
+        bb.methodpool.insert_method(self.modulename, text, self.filename)
         data.setVarFlag(self.function, "func", 1)
         data.setVarFlag(self.function, "python", 1)
         data.setVar(self.function, text)

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

@@ -166,10 +166,6 @@ def handle(fn, d, include):
     if oldfile:
         d.setVar("FILE", oldfile)
 
-    # we have parsed the bb class now
-    if ext == ".bbclass" or ext == ".inc":
-        bb.methodpool.set_parsed_module(base_name)
-
     return d
 
 def feeder(lineno, s, fn, root, statements):

bitbake/lib/bb/tests/fetch.py

@@ -251,9 +251,24 @@ class URITest(unittest.TestCase):
             self.assertEqual(uri.params, {})
             self.assertEqual(str(uri), (str(uri).split(";"))[0])
 
-
 class FetcherTest(unittest.TestCase):
 
+    def setUp(self):
+        self.d = bb.data.init()
+        self.tempdir = tempfile.mkdtemp()
+        self.dldir = os.path.join(self.tempdir, "download")
+        os.mkdir(self.dldir)
+        self.d.setVar("DL_DIR", self.dldir)
+        self.unpackdir = os.path.join(self.tempdir, "unpacked")
+        os.mkdir(self.unpackdir)
+        persistdir = os.path.join(self.tempdir, "persistdata")
+        self.d.setVar("PERSISTENT_DIR", persistdir)
+
+    def tearDown(self):
+        bb.utils.prunedir(self.tempdir)
+
+class MirrorUriTest(FetcherTest):
+
     replaceuris = {
         ("git://git.invalid.infradead.org/mtd-utils.git;tag=1234567890123456789012345678901234567890", "git://.*/.*", "http://somewhere.org/somedir/") 
             : "http://somewhere.org/somedir/git2_git.invalid.infradead.org.mtd-utils.git.tar.gz",
@@ -294,101 +309,6 @@ class FetcherTest(unittest.TestCase):
                 "https://.*/.* file:///someotherpath/downloads/ \n" \
                 "http://.*/.* file:///someotherpath/downloads/ \n"
 
-    def setUp(self):
-        self.d = bb.data.init()
-        self.tempdir = tempfile.mkdtemp()
-        self.dldir = os.path.join(self.tempdir, "download")
-        os.mkdir(self.dldir)
-        self.d.setVar("DL_DIR", self.dldir)
-        self.unpackdir = os.path.join(self.tempdir, "unpacked")
-        os.mkdir(self.unpackdir)
-        persistdir = os.path.join(self.tempdir, "persistdata")
-        self.d.setVar("PERSISTENT_DIR", persistdir)
-
-    def tearDown(self):
-        bb.utils.prunedir(self.tempdir)
-
-    @unittest.skipIf(os.environ.get("BB_SKIP_NETTESTS") == "yes",
-                     "Unset BB_SKIP_NETTESTS to run network tests")
-    def test_fetch(self):
-        fetcher = bb.fetch.Fetch(["http://downloads.yoctoproject.org/releases/bitbake/bitbake-1.0.tar.gz", "http://downloads.yoctoproject.org/releases/bitbake/bitbake-1.1.tar.gz"], self.d)
-        fetcher.download()
-        self.assertEqual(os.path.getsize(self.dldir + "/bitbake-1.0.tar.gz"), 57749)
-        self.assertEqual(os.path.getsize(self.dldir + "/bitbake-1.1.tar.gz"), 57892)
-        self.d.setVar("BB_NO_NETWORK", "1")
-        fetcher = bb.fetch.Fetch(["http://downloads.yoctoproject.org/releases/bitbake/bitbake-1.0.tar.gz", "http://downloads.yoctoproject.org/releases/bitbake/bitbake-1.1.tar.gz"], self.d)
-        fetcher.download()
-        fetcher.unpack(self.unpackdir)
-        self.assertEqual(len(os.listdir(self.unpackdir + "/bitbake-1.0/")), 9)
-        self.assertEqual(len(os.listdir(self.unpackdir + "/bitbake-1.1/")), 9)
-
-    @unittest.skipIf(os.environ.get("BB_SKIP_NETTESTS") == "yes",
-                     "Unset BB_SKIP_NETTESTS to run network tests")
-    def test_fetch_mirror(self):
-        self.d.setVar("MIRRORS", "http://.*/.* http://downloads.yoctoproject.org/releases/bitbake")
-        fetcher = bb.fetch.Fetch(["http://invalid.yoctoproject.org/releases/bitbake/bitbake-1.0.tar.gz"], self.d)
-        fetcher.download()
-        self.assertEqual(os.path.getsize(self.dldir + "/bitbake-1.0.tar.gz"), 57749)
-
-    @unittest.skipIf(os.environ.get("BB_SKIP_NETTESTS") == "yes",
-                     "Unset BB_SKIP_NETTESTS to run network tests")
-    def test_fetch_premirror(self):
-        self.d.setVar("PREMIRRORS", "http://.*/.* http://downloads.yoctoproject.org/releases/bitbake")
-        fetcher = bb.fetch.Fetch(["http://invalid.yoctoproject.org/releases/bitbake/bitbake-1.0.tar.gz"], self.d)
-        fetcher.download()
-        self.assertEqual(os.path.getsize(self.dldir + "/bitbake-1.0.tar.gz"), 57749)
-
-    def gitfetcher(self, url1, url2):
-        def checkrevision(self, fetcher):
-            fetcher.unpack(self.unpackdir)
-            revision = subprocess.check_output("git rev-parse HEAD", shell=True, cwd=self.unpackdir + "/git").strip()
-            self.assertEqual(revision, "270a05b0b4ba0959fe0624d2a4885d7b70426da5")
-
-        self.d.setVar("BB_GENERATE_MIRROR_TARBALLS", "1")
-        self.d.setVar("SRCREV", "270a05b0b4ba0959fe0624d2a4885d7b70426da5")
-        fetcher = bb.fetch.Fetch([url1], self.d)
-        fetcher.download()
-        checkrevision(self, fetcher)
-        # Wipe out the dldir clone and the unpacked source, turn off the network and check mirror tarball works
-        bb.utils.prunedir(self.dldir + "/git2/")
-        bb.utils.prunedir(self.unpackdir)
-        self.d.setVar("BB_NO_NETWORK", "1")
-        fetcher = bb.fetch.Fetch([url2], self.d)
-        fetcher.download()
-        checkrevision(self, fetcher)
-
-    @unittest.skipIf(os.environ.get("BB_SKIP_NETTESTS") == "yes",
-                     "Unset BB_SKIP_NETTESTS to run network tests")
-    def test_gitfetch(self):
-        url1 = url2 = "git://git.openembedded.org/bitbake"
-        self.gitfetcher(url1, url2)
-
-    @unittest.skipIf(os.environ.get("BB_SKIP_NETTESTS") == "yes",
-                     "Unset BB_SKIP_NETTESTS to run network tests")
-    def test_gitfetch_premirror(self):
-        url1 = "git://git.openembedded.org/bitbake"
-        url2 = "git://someserver.org/bitbake"
-        self.d.setVar("PREMIRRORS", "git://someserver.org/bitbake git://git.openembedded.org/bitbake \n")
-        self.gitfetcher(url1, url2)
-
-    @unittest.skipIf(os.environ.get("BB_SKIP_NETTESTS") == "yes",
-                     "Unset BB_SKIP_NETTESTS to run network tests")
-    def test_gitfetch_premirror2(self):
-        url1 = url2 = "git://someserver.org/bitbake"
-        self.d.setVar("PREMIRRORS", "git://someserver.org/bitbake git://git.openembedded.org/bitbake \n")
-        self.gitfetcher(url1, url2)
-
-    @unittest.skipIf(os.environ.get("BB_SKIP_NETTESTS") == "yes",
-                     "Unset BB_SKIP_NETTESTS to run network tests")
-    def test_gitfetch_premirror3(self):
-        realurl = "git://git.openembedded.org/bitbake"
-        dummyurl = "git://someserver.org/bitbake"
-        self.sourcedir = self.unpackdir.replace("unpacked", "sourcemirror.git")
-        os.chdir(self.tempdir)
-        subprocess.check_output("git clone %s %s 2> /dev/null" % (realurl, self.sourcedir), shell=True)
-        self.d.setVar("PREMIRRORS", "%s git://%s;protocol=file \n" % (dummyurl, self.sourcedir))
-        self.gitfetcher(dummyurl, dummyurl)
-
     def test_urireplace(self):
         for k, v in self.replaceuris.items():
             ud = bb.fetch.FetchData(k[0], self.d)
@@ -410,13 +330,85 @@ class FetcherTest(unittest.TestCase):
         uris, uds = bb.fetch2.build_mirroruris(fetcher, mirrors, self.d)
         self.assertEqual(uris, ['file:///someotherpath/downloads/bitbake-1.0.tar.gz'])
 
+class FetcherNetworkTest(FetcherTest):
+
+    if os.environ.get("BB_SKIP_NETTESTS") == "yes":
+        print("Unset BB_SKIP_NETTESTS to run network tests")
+    else:
+        def test_fetch(self):
+            fetcher = bb.fetch.Fetch(["http://downloads.yoctoproject.org/releases/bitbake/bitbake-1.0.tar.gz", "http://downloads.yoctoproject.org/releases/bitbake/bitbake-1.1.tar.gz"], self.d)
+            fetcher.download()
+            self.assertEqual(os.path.getsize(self.dldir + "/bitbake-1.0.tar.gz"), 57749)
+            self.assertEqual(os.path.getsize(self.dldir + "/bitbake-1.1.tar.gz"), 57892)
+            self.d.setVar("BB_NO_NETWORK", "1")
+            fetcher = bb.fetch.Fetch(["http://downloads.yoctoproject.org/releases/bitbake/bitbake-1.0.tar.gz", "http://downloads.yoctoproject.org/releases/bitbake/bitbake-1.1.tar.gz"], self.d)
+            fetcher.download()
+            fetcher.unpack(self.unpackdir)
+            self.assertEqual(len(os.listdir(self.unpackdir + "/bitbake-1.0/")), 9)
+            self.assertEqual(len(os.listdir(self.unpackdir + "/bitbake-1.1/")), 9)
+
+        def test_fetch_mirror(self):
+            self.d.setVar("MIRRORS", "http://.*/.* http://downloads.yoctoproject.org/releases/bitbake")
+            fetcher = bb.fetch.Fetch(["http://invalid.yoctoproject.org/releases/bitbake/bitbake-1.0.tar.gz"], self.d)
+            fetcher.download()
+            self.assertEqual(os.path.getsize(self.dldir + "/bitbake-1.0.tar.gz"), 57749)
+
+        def test_fetch_premirror(self):
+            self.d.setVar("PREMIRRORS", "http://.*/.* http://downloads.yoctoproject.org/releases/bitbake")
+            fetcher = bb.fetch.Fetch(["http://invalid.yoctoproject.org/releases/bitbake/bitbake-1.0.tar.gz"], self.d)
+            fetcher.download()
+            self.assertEqual(os.path.getsize(self.dldir + "/bitbake-1.0.tar.gz"), 57749)
+
+        def gitfetcher(self, url1, url2):
+            def checkrevision(self, fetcher):
+                fetcher.unpack(self.unpackdir)
+                revision = bb.process.run("git rev-parse HEAD", shell=True, cwd=self.unpackdir + "/git")[0].strip()
+                self.assertEqual(revision, "270a05b0b4ba0959fe0624d2a4885d7b70426da5")
+
+            self.d.setVar("BB_GENERATE_MIRROR_TARBALLS", "1")
+            self.d.setVar("SRCREV", "270a05b0b4ba0959fe0624d2a4885d7b70426da5")
+            fetcher = bb.fetch.Fetch([url1], self.d)
+            fetcher.download()
+            checkrevision(self, fetcher)
+            # Wipe out the dldir clone and the unpacked source, turn off the network and check mirror tarball works
+            bb.utils.prunedir(self.dldir + "/git2/")
+            bb.utils.prunedir(self.unpackdir)
+            self.d.setVar("BB_NO_NETWORK", "1")
+            fetcher = bb.fetch.Fetch([url2], self.d)
+            fetcher.download()
+            checkrevision(self, fetcher)
+
+        def test_gitfetch(self):
+            url1 = url2 = "git://git.openembedded.org/bitbake"
+            self.gitfetcher(url1, url2)
+
+        def test_gitfetch_premirror(self):
+            url1 = "git://git.openembedded.org/bitbake"
+            url2 = "git://someserver.org/bitbake"
+            self.d.setVar("PREMIRRORS", "git://someserver.org/bitbake git://git.openembedded.org/bitbake \n")
+            self.gitfetcher(url1, url2)
+
+        def test_gitfetch_premirror2(self):
+            url1 = url2 = "git://someserver.org/bitbake"
+            self.d.setVar("PREMIRRORS", "git://someserver.org/bitbake git://git.openembedded.org/bitbake \n")
+            self.gitfetcher(url1, url2)
+
+        def test_gitfetch_premirror3(self):
+            realurl = "git://git.openembedded.org/bitbake"
+            dummyurl = "git://someserver.org/bitbake"
+            self.sourcedir = self.unpackdir.replace("unpacked", "sourcemirror.git")
+            os.chdir(self.tempdir)
+            bb.process.run("git clone %s %s 2> /dev/null" % (realurl, self.sourcedir), shell=True)
+            self.d.setVar("PREMIRRORS", "%s git://%s;protocol=file \n" % (dummyurl, self.sourcedir))
+            self.gitfetcher(dummyurl, dummyurl)
 
 class URLHandle(unittest.TestCase):
 
     datatable = {
        "http://www.google.com/index.html" : ('http', 'www.google.com', '/index.html', '', '', {}),
        "cvs://anoncvs@cvs.handhelds.org/cvs;module=familiar/dist/ipkg" : ('cvs', 'cvs.handhelds.org', '/cvs', 'anoncvs', '', {'module': 'familiar/dist/ipkg'}),
-       "cvs://anoncvs:anonymous@cvs.handhelds.org/cvs;tag=V0-99-81;module=familiar/dist/ipkg" : ('cvs', 'cvs.handhelds.org', '/cvs', 'anoncvs', 'anonymous', {'tag': 'V0-99-81', 'module': 'familiar/dist/ipkg'})
+       "cvs://anoncvs:anonymous@cvs.handhelds.org/cvs;tag=V0-99-81;module=familiar/dist/ipkg" : ('cvs', 'cvs.handhelds.org', '/cvs', 'anoncvs', 'anonymous', {'tag': 'V0-99-81', 'module': 'familiar/dist/ipkg'}),
+       "git://git.openembedded.org/bitbake;branch=@foo" : ('git', 'git.openembedded.org', '/bitbake', '', '', {'branch': '@foo'})
     }
 
     def test_decodeurl(self):

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

@@ -132,12 +132,13 @@ class LayerSelectionDialog (CrumbsDialog):
         tree_selection.set_mode(gtk.SELECTION_SINGLE)
 
         # Allow enable drag and drop of rows including row move
+        dnd_internal_target = ''
+        dnd_targets = [(dnd_internal_target, gtk.TARGET_SAME_WIDGET, 0)]
         layer_tv.enable_model_drag_source( gtk.gdk.BUTTON1_MASK,
-            self.TARGETS,
-            gtk.gdk.ACTION_DEFAULT|
+            dnd_targets,
+            gtk.gdk.ACTION_MOVE)
+        layer_tv.enable_model_drag_dest(dnd_targets,
             gtk.gdk.ACTION_MOVE)
-        layer_tv.enable_model_drag_dest(self.TARGETS,
-            gtk.gdk.ACTION_DEFAULT)
         layer_tv.connect("drag_data_get", self.drag_data_get_cb)
         layer_tv.connect("drag_data_received", self.drag_data_received_cb)
 

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

@@ -181,7 +181,9 @@ class PackageListModel(gtk.ListStore):
     def sort_func(self, model, iter1, iter2, user_data):
         val1 = model.get_value(iter1, PackageListModel.COL_NAME)
         val2 = model.get_value(iter2, PackageListModel.COL_NAME)
-        if val1.startswith(user_data) and not val2.startswith(user_data):
+        if val1 is None or val2 is None:
+            return 0
+        elif val1.startswith(user_data) and not val2.startswith(user_data):
             return -1
         elif not val1.startswith(user_data) and val2.startswith(user_data):
             return 1
@@ -562,7 +564,9 @@ class RecipeListModel(gtk.ListStore):
     def sort_func(self, model, iter1, iter2, user_data):
         val1 = model.get_value(iter1, RecipeListModel.COL_NAME)
         val2 = model.get_value(iter2, RecipeListModel.COL_NAME)
-        if val1.startswith(user_data) and not val2.startswith(user_data):
+        if val1 is None or val2 is None:
+            return 0
+        elif val1.startswith(user_data) and not val2.startswith(user_data):
             return -1
         elif not val1.startswith(user_data) and val2.startswith(user_data):
             return 1

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

@@ -288,6 +288,7 @@ class PackageSelectionPage (HobPage):
         self.refresh_selection()
         if not self.builder.customized:
             self.builder.customized = True
+            self.builder.configuration.initial_selected_image = self.builder.configuration.selected_image
             self.builder.configuration.selected_image = self.recipe_model.__custom_image__
             self.builder.rcppkglist_populated()
 

bitbake/lib/bb/ui/goggle.py

@@ -81,7 +81,7 @@ def main (server, eventHandler):
 
     try:
         cmdline, error = server.runCommand(["getCmdLineAction"])
-        if err:
+        if error:
             print("Error getting bitbake commandline: %s" % error)
             return 1
         elif not cmdline:

bitbake/lib/prserv/serv.py

@@ -263,6 +263,9 @@ def is_local_special(host, port):
     else:
         return False
 
+class PRServiceConfigError(Exception):
+    pass
+
 def auto_start(d):
     global singleton
 
@@ -273,14 +276,14 @@ def auto_start(d):
     if len(host_params) != 2:
         logger.critical('\n'.join(['PRSERV_HOST: incorrect format',
                 'Usage: PRSERV_HOST = "<hostname>:<port>"']))
-        return True
+        raise PRServiceConfigError
 
     if is_local_special(host_params[0], int(host_params[1])) and not singleton:
         import bb.utils
         cachedir = (d.getVar("PERSISTENT_DIR", True) or d.getVar("CACHE", True))
         if not cachedir:
             logger.critical("Please set the 'PERSISTENT_DIR' or 'CACHE' variable")
-            sys.exit(1)
+            raise PRServiceConfigError
         bb.utils.mkdirhier(cachedir)
         dbfile = os.path.join(cachedir, "prserv.sqlite3")
         logfile = os.path.join(cachedir, "prserv.log")
@@ -296,7 +299,7 @@ def auto_start(d):
         return PRServerConnection(host,port).ping()
     except Exception:
         logger.critical("PRservice %s:%d not available" % (host, port))
-    return False
+        raise PRServiceConfigError
 
 def auto_shutdown(d=None):
     global singleton

documentation/adt-manual/adt-manual.xml

@@ -61,7 +61,32 @@
                 <date>April 2013</date>
                 <revremark>Released with the Yocto Project 1.4 Release.</revremark>
             </revision>
-        </revhistory>
+            <revision>
+                <revnumber>1.4.1</revnumber>
+                <date>June 2013</date>
+                <revremark>Released with the Yocto Project 1.4.1 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.4.2</revnumber>
+                <date>August 2013</date>
+                <revremark>Released with the Yocto Project 1.4.2 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.4.3</revnumber>
+                <date>March 2014</date>
+                <revremark>Released with the Yocto Project 1.4.3 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.4.4</revnumber>
+                <date>May 2014</date>
+                <revremark>Released with the Yocto Project 1.4.4 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.4.5</revnumber>
+                <date>July 2014</date>
+                <revremark>Released with the Yocto Project 1.4.5 Release.</revremark>
+            </revision>
+      </revhistory>
 
     <copyright>
       <year>&COPYRIGHT_YEAR;</year>

documentation/bsp-guide/bsp-guide.xml

@@ -73,6 +73,31 @@
                 <date>April 2013</date>
                 <revremark>Released with the Yocto Project 1.4 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>1.4.1</revnumber>
+                <date>June 2013</date>
+                <revremark>Released with the Yocto Project 1.4.1 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.4.2</revnumber>
+                <date>August 2013</date>
+                <revremark>Released with the Yocto Project 1.4.2 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.4.3</revnumber>
+                <date>March 2014</date>
+                <revremark>Released with the Yocto Project 1.4.3 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.4.4</revnumber>
+                <date>May 2014</date>
+                <revremark>Released with the Yocto Project 1.4.4 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.4.5</revnumber>
+                <date>July 2014</date>
+                <revremark>Released with the Yocto Project 1.4.5 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>

documentation/bsp-guide/bsp.xml

@@ -883,31 +883,59 @@
                If you plan on customizing a recipe for a particular BSP, you need to do the
                following:
                <itemizedlist>
-                   <listitem><para>Include within the BSP layer a <filename>.bbappend</filename>
-                       file for the modified recipe.</para></listitem>
-                   <listitem><para>Place the BSP-specific file in the BSP's recipe
-                       <filename>.bbappend</filename> file path under a directory named
-                       after the machine.</para></listitem>
+                   <listitem><para>Create a <filename>.bbappend</filename>
+                       file for the modified recipe.
+                       For information on using append files, see the 
+                       "<ulink url='&YOCTO_DOCS_DEV_URL;#using-bbappend-files'>Using .bbappend Files</ulink>"
+                       section in the Yocto Project Development Manual.
+                       </para></listitem>
+                   <listitem><para>
+                       Ensure your directory structure in the BSP layer
+                       that supports your machine is such that it can be found
+                       by the build system.
+                       See the example later in this section for more information.
+                       </para></listitem> 
+                   <listitem><para>
+                       Put the append file in a directory whose name matches
+                       the machine's name and is located in an appropriate
+                       sub-directory inside the BSP layer (i.e. 
+                       <filename>recipes-bsp</filename>, <filename>recipes-graphics</filename>,
+                       <filename>recipes-core</filename>, and so forth). 
+                       </para></listitem>
+                   <listitem><para>Place the BSP-specific files in the directory named for 
+                       your machine inside the BSP layer.
+                       </para></listitem>
                </itemizedlist>
            </para>
 
            <para>
-               To better understand this, consider an example that customizes a recipe by adding
+               Following is a specific example to help you better understand the process.
+               Consider an example that customizes a recipe by adding
                a BSP-specific configuration file named <filename>interfaces</filename> to the
-               <filename>netbase_5.0.bb</filename> recipe for machine "xyz".
+               <filename>init-ifupdown_1.0.bb</filename> recipe for machine "xyz".
                Do the following:
                <orderedlist>
-                   <listitem><para>Edit the <filename>netbase_5.0.bbappend</filename> file so that it
+                   <listitem><para>Edit the <filename>init-ifupdown_1.0.bbappend</filename> file so that it
                        contains the following:
                        <literallayout class='monospaced'>
      FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
      PRINC := "${@int(PRINC) + 2}"
-                       </literallayout></para></listitem>
+                       </literallayout>
+                       The append file needs to be in the 
+                       <filename>meta-xyz/recipes-core/init-ifupdown</filename> directory.
+                       </para></listitem>
                    <listitem><para>Create and place the new <filename>interfaces</filename>
                        configuration file in the BSP's layer here:
                        <literallayout class='monospaced'>
-     meta-xyz/recipes-core/netbase/files/xyz/interfaces
-                       </literallayout></para></listitem>
+     meta-xyz/recipes-core/init-ifupdown/files/xyz/interfaces
+                       </literallayout>
+                       The 
+                       <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></ulink>
+                       variable in the append files extends the search path 
+                       the build system uses to find files during the build.
+                       Consequently, for this example you need to have the  
+                       <filename>files</filename> directory in the same location
+                       as your append file.</para></listitem>
                </orderedlist>
             </para>
         </section>

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

@@ -411,7 +411,7 @@
      	        install -m 0644 ${S}/machconfig ${D}${sysconfdir}/formfactor/
      	fi
      }          </literallayout>
-                In the main recipe, note the 
+                In the main recipe, note the
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
                 variable, which tells the OpenEmbedded build system where to
                 find files during the build.
@@ -431,27 +431,27 @@
             </para>
 
             <para>
-                By default, the build system uses the 
+                By default, the build system uses the
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESPATH'><filename>FILESPATH</filename></ulink>
                 variable to locate files.
-                This append file extends the locations by setting the 
+                This append file extends the locations by setting the
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></ulink>
                 variable.
                 Setting this variable in the <filename>.bbappend</filename>
-                file is the most reliable and recommended method for adding 
-                directories to the search path used by the build system 
+                file is the most reliable and recommended method for adding
+                directories to the search path used by the build system
                 to find files.
             </para>
 
             <para>
-                The statement in this example extends the directories to include 
-                <filename>${THISDIR}/${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PN'><filename>PN</filename></ulink><filename>}</filename>, 
-                which resolves to a directory named 
-                <filename>formfactor</filename> in the same directory 
+                The statement in this example extends the directories to include
+                <filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-THISDIR'><filename>THISDIR</filename></ulink><filename>}/${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PN'><filename>PN</filename></ulink><filename>}</filename>,
+                which resolves to a directory named
+                <filename>formfactor</filename> in the same directory
                 in which the append file resides (i.e.
                 <filename>meta-intel/meta-crownbay/recipes-bsp/formfactor/formfactor</filename>.
-                This implies that you must have the supporting directory 
-                structure set up that will contain any files or patches you 
+                This implies that you must have the supporting directory
+                structure set up that will contain any files or patches you
                 will be including from the layer.
             </para>
 
@@ -660,7 +660,7 @@
                 script to accept the default value.
                 Once the script completes, the new layer
                 is created in the current working directory.
-                The script names the layer by prepending 
+                The script names the layer by prepending
                 <filename>meta-</filename> to the name you provide.
             </para>
 
@@ -1270,7 +1270,7 @@
 
             <para>
                 To add a post-installation script to a package, add a
-                <filename>pkg_postinst_PACKAGENAME()</filename> function to the 
+                <filename>pkg_postinst_PACKAGENAME()</filename> function to the
                 <filename>.bb</filename> file and use
                 <filename>PACKAGENAME</filename> as the name of the package you want to attach to the
                 <filename>postinst</filename> script.
@@ -1504,8 +1504,8 @@
                 By default, the <filename>PACKAGES</filename> variable contains
                 <filename>${PN}-staticdev</filename>, which includes all static library files.
                 <note>
-                    Some previously released versions of the Yocto Project 
-                    defined the static library files through 
+                    Some previously released versions of the Yocto Project
+                    defined the static library files through
                     <filename>${PN}-dev</filename>.
                 </note>
                 Following, is part of the BitBake configuration file.
@@ -1810,7 +1810,7 @@
             <para>
                 To use the <filename>menuconfig</filename> tool in the Yocto Project development
                 environment, you must build the tool using BitBake.
-                Thus, the environment must be set up using the 
+                Thus, the environment must be set up using the
                 <ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>
                 script found in the
                 <link linkend='build-directory'>Build Directory</link>.
@@ -2240,7 +2240,7 @@
                         The <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></ulink>
                         and <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
                         statements enable the OpenEmbedded build system to find the patch file.
-                        For more information on using append files, see the 
+                        For more information on using append files, see the
                         "<link linkend='using-bbappend-files'>Using .bbappend Files</link>"
                         section.
                         </para></listitem>
@@ -2262,7 +2262,7 @@
                 <itemizedlist>
                     <listitem><para><emphasis>Build for the correct target architecture:</emphasis> Your
                         selected <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink>
-                        definition within the <filename>local.conf</filename> file in the 
+                        definition within the <filename>local.conf</filename> file in the
                         <link linkend='build-directory'>Build Directory</link>
                         specifies the target architecture used when building the Linux kernel.
                         By default, <filename>MACHINE</filename> is set to
@@ -2270,7 +2270,7 @@
                         <trademark class='registered'>Intel</trademark> Architecture
                         target machine suitable for the QEMU emulator.</para></listitem>
                     <listitem><para><emphasis>Identify your <filename>meta-mylayer</filename>
-                        layer:</emphasis> The 
+                        layer:</emphasis> The
                         <ulink url='&YOCTO_DOCS_REF_URL;#var-BBLAYERS'><filename>BBLAYERS</filename></ulink>
                         variable in the
                         <filename>bblayers.conf</filename> file found in the
@@ -2306,7 +2306,7 @@
                 <orderedlist>
                     <listitem><para><emphasis>Be sure your build environment is initialized</emphasis>:
                         Your environment should be set up since you previously sourced
-                        the 
+                        the
                         <ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>
                         script.
                         If it is not, source the script again from <filename>poky</filename>.
@@ -2322,7 +2322,7 @@
      $ bitbake -c cleansstate linux-yocto
                         </literallayout></para>
                         <para><note>Never remove any files by hand from the <filename>tmp/deploy</filename>
-                        directory inside the 
+                        directory inside the
                         <link linkend='build-directory'>Build Directory</link>.
                         Always use the various BitBake clean tasks to clear out previous
                         build artifacts.
@@ -2390,7 +2390,7 @@
                     configurations in a <filename>local.conf</filename>
                     configuration file makes it easier to reproduce the same
                     build configuration when using multiple build machines.
-                    See the 
+                    See the
                     "<link linkend='creating-a-general-layer-using-the-yocto-layer-script'>Creating a General Layer Using the yocto-layer Script</link>"
                     section for information on how to quickly set up a layer.
                     </para></listitem>
@@ -2416,7 +2416,7 @@
      <ulink url='&YOCTO_DOCS_REF_URL;#var-DISTRO_NAME'><filename>DISTRO_NAME</filename></ulink> [required]
      <ulink url='&YOCTO_DOCS_REF_URL;#var-DISTRO_VERSION'><filename>DISTRO_VERSION</filename></ulink> [required]
                     </literallayout>
-                    These following variables are optional and you typically 
+                    These following variables are optional and you typically
                     set them from the distribution configuration file:
                     <literallayout class='monospaced'>
      <ulink url='&YOCTO_DOCS_REF_URL;#var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></ulink> [optional]
@@ -2427,7 +2427,7 @@
                     <tip>
                         If you want to base your distribution configuration file
                         on the very basic configuration from OE-Core, you
-                        can use 
+                        can use
                         <filename>conf/distro/defaultsetup.conf</filename> as
                         a reference and just include variables that differ
                         as compared to <filename>defaultsetup.conf</filename>.
@@ -2573,7 +2573,7 @@
                 <filename>poky-tiny</filename>.
                 <note>
                     To use <filename>poky-tiny</filename> in your build,
-                    set the 
+                    set the
                     <ulink url='&YOCTO_DOCS_REF_URL;#var-DISTRO'><filename>DISTRO</filename></ulink>
                     variable in your
                     <filename>local.conf</filename> file to "poky-tiny"
@@ -3069,7 +3069,7 @@
 
                 <para>
                     The alternative to setting up a PR Service is to manually
-                    bump the 
+                    bump the
                     <ulink url='&YOCTO_DOCS_REF_URL;#var-PR'><filename>PR</filename></ulink>
                     variable.
                 </para>
@@ -3102,8 +3102,8 @@
                 <para>
                     When upgrading the version of a package, assuming the
                     <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PV'>PV</ulink></filename>
-                    changes, the <filename>PR</filename> variable should be 
-                    reset to "r0" (or "$(INC_PR).0" if you are using 
+                    changes, the <filename>PR</filename> variable should be
+                    reset to "r0" (or "$(INC_PR).0" if you are using
                     <filename>INC_PR</filename>).
                 </para>
 
@@ -3163,7 +3163,7 @@
      $ bitbake world -f -c distro_check
                 </literallayout>
                 The results are stored in the <filename>build/tmp/log/distro_check-${DATETIME}.results</filename>
-                file found in the 
+                file found in the
                 <link linkend='source-directory'>Source Directory</link>.
             </para>
         </section>
@@ -3203,7 +3203,7 @@
                     The <filename>do_split_packages</filename> function
                     searches for a pattern of files or directories under a
                     specified path and creates a package for each one it finds
-                    by appending to the 
+                    by appending to the
                     <ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGES'><filename>PACKAGES</filename></ulink>
                     variable and setting the appropriate values for
                     <filename>FILES_packagename</filename>,
@@ -3241,7 +3241,7 @@
                             Thus, if a file in <filename>${libdir}</filename>
                             called <filename>mod_alias.so</filename> is found,
                             a package called <filename>lighttpd-module-alias</filename>
-                            is created for it and the 
+                            is created for it and the
                             <ulink url='&YOCTO_DOCS_REF_URL;#var-DESCRIPTION'><filename>DESCRIPTION</filename></ulink>
                             is set to "Lighttpd module for alias".</para></listitem>
                     </itemizedlist>
@@ -3265,7 +3265,7 @@
                     <filename>do_split_packages</filename>, see the
                     <filename>connman.inc</filename> file in the
                     <filename>meta/recipes-connectivity/connman/</filename>
-                    directory of the <filename>poky</filename> 
+                    directory of the <filename>poky</filename>
                     <link linkend='yocto-project-repositories'>source repository</link>.
                     You can also find examples in
                     <filename>meta/classes/kernel.bbclass</filename>.
@@ -3535,33 +3535,33 @@
             <title>Testing Packages With ptest</title>
 
             <para>
-                A Package Test (ptest) runs tests against packages built 
+                A Package Test (ptest) runs tests against packages built
                 by the OpenEmbedded build system on the target machine.
-                A ptest contains at least two items: the actual test, and 
+                A ptest contains at least two items: the actual test, and
                 a shell script (<filename>run-ptest</filename>) that starts
                 the test.
-                The shell script that starts the test must not contain 
+                The shell script that starts the test must not contain
                 the actual test, the script only starts it.
                 On the other hand, the test can be anything from a simple
-                shell script that runs a binary and checks the output to 
+                shell script that runs a binary and checks the output to
                 an elaborate system of test binaries and data files.
             </para>
 
             <para>
-                The test generates output in the format used by 
+                The test generates output in the format used by
                 Automake:
                 <literallayout class='monospaced'>
      &lt;result&gt;: &lt;testname&gt;
                 </literallayout>
-                where the result can be <filename>PASS</filename>, 
+                where the result can be <filename>PASS</filename>,
                 <filename>FAIL</filename>, or <filename>SKIP</filename>,
                 and the testname can be any identifying string.
             </para>
 
             <note>
                 With this release of the Yocto Project, three recipes exist
-                that are "ptest-enabled": <filename>bash</filename>, 
-                <filename>glib-2.0</filename>, and 
+                that are "ptest-enabled": <filename>bash</filename>,
+                <filename>glib-2.0</filename>, and
                 <filename>dbus</filename>.
                 These three recipes are Autotool-enabled.
             </note>
@@ -3570,20 +3570,20 @@
                 <title>Adding ptest to Your Build</title>
 
                 <para>
-                    To add package testing to your build, add the 
+                    To add package testing to your build, add the
                     <ulink url='&YOCTO_DOCS_REF_URL;#var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></ulink>
                     and <ulink url='&YOCTO_DOCS_REF_URL;#var-EXTRA_IMAGE_FEATURES'><filename>EXTRA_IMAGE_FEATURES</filename></ulink>
-                    variables to your <filename>local.conf</filename> file, 
-                    which is found in the 
+                    variables to your <filename>local.conf</filename> file,
+                    which is found in the
                     <link linkend='build-directory'>Build Directory</link>:
                     <literallayout class='monospaced'>
-     EXTRA_IMAGE_FEATURES += "ptest" 
-     DISTRO_FEATURES_append = " ptest-pkgs"
+     DISTRO_FEATURES_append = " ptest"
+     EXTRA_IMAGE_FEATURES += "ptest-pkgs"
                     </literallayout>
                     Once your build is complete, the ptest files are installed
                     into the <filename>/usr/lib/&lt;package&gt;/ptest</filename>
-                    directory within the image, where 
-                    <filename>&lt;package&gt;</filename> is the name of the 
+                    directory within the image, where
+                    <filename>&lt;package&gt;</filename> is the name of the
                     package.
                 </para>
             </section>
@@ -3592,21 +3592,21 @@
                 <title>Running ptest</title>
 
                 <para>
-                    The <filename>ptest-runner</filename> package installs a 
-                    shell script that loops through all installed ptest test 
-                    suites and runs them in sequence. 
+                    The <filename>ptest-runner</filename> package installs a
+                    shell script that loops through all installed ptest test
+                    suites and runs them in sequence.
                     Consequently, you might want to add this package to
-                    your image. 
+                    your image.
                 </para>
-            </section> 
+            </section>
 
             <section id='getting-your-package-ready'>
                 <title>Getting Your Package Ready</title>
- 
+
                 <para>
-                    In order to enable a recipe to run installed ptests 
-                    on target hardware, 
-                    you need to prepare the recipes that build the packages     
+                    In order to enable a recipe to run installed ptests
+                    on target hardware,
+                    you need to prepare the recipes that build the packages
                     you want to test.
                     Here is what you have to do for each recipe:
                     <itemizedlist>
@@ -3619,10 +3619,10 @@
                             </para></listitem>
                         <listitem><para><emphasis>Create <filename>run-ptest</filename>:</emphasis>
                             This script starts your test.
-                            Locate the script where you will refer to it 
-                            using 
+                            Locate the script where you will refer to it
+                            using
                             <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>.
-                            Here is an example that starts a test for 
+                            Here is an example that starts a test for
                             <filename>dbus</filename>:
                             <literallayout class='monospaced'>
      #!/bin/sh
@@ -3632,45 +3632,45 @@
                             </para></listitem>
                         <listitem><para><emphasis>Ensure dependencies are
                             met:</emphasis>
-                            If the test adds build or runtime dependencies 
-                            that normally do not exist for the package 
-                            (such as requiring "make" to run the test suite), 
-                            use the 
+                            If the test adds build or runtime dependencies
+                            that normally do not exist for the package
+                            (such as requiring "make" to run the test suite),
+                            use the
                             <ulink url='&YOCTO_DOCS_REF_URL;#var-DEPENDS'><filename>DEPENDS</filename></ulink>
-                            and 
+                            and
                             <ulink url='&YOCTO_DOCS_REF_URL;#var-RDEPENDS'><filename>RDEPENDS</filename></ulink>
                             variables in your recipe in order for the package
-                            to meet the dependencies. 
-                            Here is an example where the package has a runtime 
+                            to meet the dependencies.
+                            Here is an example where the package has a runtime
                             dependency on "make":
                             <literallayout class='monospaced'>
      RDEPENDS_${PN}-ptest += "make"
                             </literallayout>
                             </para></listitem>
-                        <listitem><para><emphasis>Add a function to build the 
+                        <listitem><para><emphasis>Add a function to build the
                             test suite:</emphasis>
-                            Not many packages support cross-compilation of 
-                            their test suites. 
-                            Consequently, you usually need to add a 
+                            Not many packages support cross-compilation of
+                            their test suites.
+                            Consequently, you usually need to add a
                             cross-compilation function to the package.
                             </para>
-                            <para>Many packages based on Automake compile and 
+                            <para>Many packages based on Automake compile and
                             run the test suite by using a single command
                             such as <filename>make check</filename>.
                             However, the native <filename>make check</filename>
-                            builds and runs on the same computer, while 
-                            cross-compiling requires that the package is built 
+                            builds and runs on the same computer, while
+                            cross-compiling requires that the package is built
                             on the host but executed on the target.
-                            The built version of Automake that ships with the 
-                            Yocto Project includes a patch that separates 
+                            The built version of Automake that ships with the
+                            Yocto Project includes a patch that separates
                             building and execution.
-                            Consequently, packages that use the unaltered, 
+                            Consequently, packages that use the unaltered,
                             patched version of <filename>make check</filename>
                             automatically cross-compiles.</para>
-                            <para>However, you still must add a 
-                            <filename>do_compile_ptest</filename> function to 
+                            <para>However, you still must add a
+                            <filename>do_compile_ptest</filename> function to
                             build the test suite.
-                            Add a function similar to the following to your 
+                            Add a function similar to the following to your
                             recipe:
                             <literallayout class='monospaced'>
      do_compile_ptest() {
@@ -3680,26 +3680,26 @@
                             </para></listitem>
                        <listitem><para><emphasis>Ensure special configurations
                             are set:</emphasis>
-                            If the package requires special configurations 
+                            If the package requires special configurations
                             prior to compiling the test code, you must
                             insert a <filename>do_configure_ptest</filename>
                             function into the recipe.
                             </para></listitem>
-                       <listitem><para><emphasis>Install the test 
+                       <listitem><para><emphasis>Install the test
                             suite:</emphasis>
-                            The <filename>ptest.bbclass</filename> class 
-                            automatically copies the file 
-                            <filename>run-ptest</filename> to the target and 
+                            The <filename>ptest.bbclass</filename> class
+                            automatically copies the file
+                            <filename>run-ptest</filename> to the target and
                             then runs make <filename>install-ptest</filename>
-                            to run the tests. 
-                            If this is not enough, you need to create a 
-                            <filename>do_install_ptest</filename> function and 
-                            make sure it gets called after the 
+                            to run the tests.
+                            If this is not enough, you need to create a
+                            <filename>do_install_ptest</filename> function and
+                            make sure it gets called after the
                             "make install-ptest" completes.
                             </para></listitem>
                     </itemizedlist>
                 </para>
-            </section>         
+            </section>
         </section>
     </section>
 
@@ -3779,9 +3779,9 @@
 
         <note>
             It is recommended that you create your own distribution configuration
-            file to hold these settings instead of using your 
+            file to hold these settings instead of using your
             <filename>local.conf</filename> file.
-            For information on creating your own distribution, see the 
+            For information on creating your own distribution, see the
             "<link linkend='creating-your-own-distribution'>Creating Your Own Distribution</link>"
             section.
         </note>
@@ -3797,7 +3797,7 @@
      VIRTUAL-RUNTIME_init_manager = "systemd"
                 </literallayout>
                 You can also prevent the <filename>sysvinit</filename>
-                distribution feature from 
+                distribution feature from
                 being automatically enabled as follows:
                 <literallayout class='monospaced'>
      DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
@@ -3838,7 +3838,7 @@
             However, on rare occasions where you might want to use a
             layer but exclude parts that are causing problems, such
             as introducing a different version of a recipe, you can
-            use 
+            use
             <ulink url='&YOCTO_DOCS_REF_URL;#var-BBMASK'><filename>BBMASK</filename></ulink>
             to exclude the recipe.
         </para>
@@ -3978,7 +3978,7 @@
                 creation:
                 <itemizedlist>
                     <listitem><para><emphasis>Not using $D in front of absolute paths:</emphasis>
-                        The build system defines 
+                        The build system defines
                         <filename>$</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-D'><filename>D</filename></ulink>
                         at root filesystem creation time, and
                         it is blank when run on the target device.
@@ -4034,9 +4034,9 @@
         </para>
 
         <tip>
-            For best results, install <filename>-dbg</filename> packages for 
+            For best results, install <filename>-dbg</filename> packages for
             the applications you are going to debug.
-            Doing so makes extra debug symbols available that give you more 
+            Doing so makes extra debug symbols available that give you more
             meaningful output.
         </tip>
 
@@ -4097,11 +4097,11 @@
             <para>
                 Before you can initiate a remote debugging session, you need
                 to be sure you have set up the cross-development environment,
-                toolchain, and sysroot. 
+                toolchain, and sysroot.
                 The "<ulink url='&YOCTO_DOCS_ADT_URL;#adt-prepare'>Preparing for Application Development</ulink>"
                 chapter of the Yocto Project Application Developer's Guide
                 describes this process.
-                Be sure you have read that chapter and have set up 
+                Be sure you have read that chapter and have set up
                 your environment.
             </para>
         </section>
@@ -4111,22 +4111,22 @@
 
             <para>
                 Make sure Gdbserver is installed on the target.
-                If it is not, install the package 
+                If it is not, install the package
                 <filename>gdbserver</filename>, which needs the
                 <filename>libthread-db1</filename> package.
             </para>
 
             <para>
-                Here is an example that when entered from the host 
-                connects to the target and launches Gdbserver in order to 
+                Here is an example that when entered from the host
+                connects to the target and launches Gdbserver in order to
                 "debug" a binary named <filename>helloworld</filename>:
                 <literallayout class='monospaced'>
      $ gdbserver localhost:2345 /usr/bin/helloworld
                 </literallayout>
                 Gdbserver should now be listening on port 2345 for debugging
-                commands coming from a remote GDB process that is running on 
+                commands coming from a remote GDB process that is running on
                 the host computer.
-                Communication between Gdbserver and the host GDB are done 
+                Communication between Gdbserver and the host GDB are done
                 using TCP.
                 To use other communication protocols, please refer to the
                 <ulink url='http://www.gnu.org/software/gdb/'>Gdbserver documentation</ulink>.
@@ -4144,23 +4144,23 @@
             <section id="platdev-gdb-remotedebug-launch-gdb-buildcross">
                 <title>Build the Cross-GDB Package</title>
                 <para>
-                    A suitable GDB cross-binary is required that runs on your 
-                    host computer but also knows about the the ABI of the 
+                    A suitable GDB cross-binary is required that runs on your
+                    host computer but also knows about the the ABI of the
                     remote target.
-                    You can get this binary from the 
+                    You can get this binary from the
                     <link linkend='cross-development-toolchain'>Cross-Development Toolchain</link>.
                     Here is an example where the toolchain has been installed
-                    in the default directory 
+                    in the default directory
                     <filename>/opt/poky/&DISTRO;</filename>:
                     <literallayout class='monospaced'>
      /opt/poky/1.4/sysroots/i686-pokysdk-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi/arm-poky-linux-gnueabi-gdb
                     </literallayout>
-                    where <filename>arm</filename> is the target architecture 
+                    where <filename>arm</filename> is the target architecture
                     and <filename>linux-gnueabi</filename> is the target ABI.
                 </para>
 
                 <para>
-                    Alternatively, you can use BitBake to build the 
+                    Alternatively, you can use BitBake to build the
                     <filename>gdb-cross</filename> binary.
                     Here is an example:
                     <literallayout class='monospaced'>
@@ -4190,10 +4190,10 @@
                 </para>
 
                 <para>
-                    You need to add a statement in the 
+                    You need to add a statement in the
                     <filename>.gdbinit</filename> file that points to your
                     root filesystem.
-                    Here is an example that points to the root filesystem for 
+                    Here is an example that points to the root filesystem for
                     an ARM-based target device:
                     <literallayout class='monospaced'>
      set sysroot /home/jzhang/sysroot_arm
@@ -4205,14 +4205,14 @@
                 <title>Launch the Host GDB</title>
 
                 <para>
-                    Before launching the host GDB, you need to be sure 
-                    you have sourced the cross-debugging environment script, 
-                    which if you installed the root filesystem in the default 
-                    location is at <filename>/opt/poky/&DISTRO;</filename> 
+                    Before launching the host GDB, you need to be sure
+                    you have sourced the cross-debugging environment script,
+                    which if you installed the root filesystem in the default
+                    location is at <filename>/opt/poky/&DISTRO;</filename>
                     and begins with the string "environment-setup".
-                    For more information, see the 
+                    For more information, see the
                     "<ulink url='&YOCTO_DOCS_ADT_URL;#setting-up-the-cross-development-environment'>Setting Up the Cross-Development Environment</ulink>"
-                    section in the Yocto Project Application Developer's 
+                    section in the Yocto Project Application Developer's
                     Guide.
                 </para>
 
@@ -4222,7 +4222,7 @@
                     Provide the binary file you are going to debug.
                     For example, the following command continues with the
                     example used in the previous section by loading
-                    the <filename>helloworld</filename> binary as well as the 
+                    the <filename>helloworld</filename> binary as well as the
                     debugging information:
                     <literallayout class='monospaced'>
      $ arm-poky-linux-gnuabi-gdb helloworld
@@ -4238,7 +4238,7 @@
 
             <para>
                 From the target, you need to connect to the remote GDB
-                server that is running on the host. 
+                server that is running on the host.
                 You need to specify the remote host and port.
                 Here is the command continuing with the example:
                 <literallayout class='monospaced'>
@@ -4315,7 +4315,7 @@
             <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-DEBUG_BUILD'>DEBUG_BUILD</ulink></filename>
             variable to "1" in the <filename>local.conf</filename> configuration file.
             If you use the <filename>DEBUG_BUILD</filename> variable,
-            you also add extra debugging information that can make the debug 
+            you also add extra debugging information that can make the debug
             packages large.
         </para>
 
@@ -4390,8 +4390,8 @@
                 <ulink url="&YOCTO_GIT_URL;/cgit.cgi/oprofileui/"></ulink>.
                 If the "tools-profile" image feature is selected, all necessary binaries
                 are installed onto the target device for OProfileUI interaction.
-                For a list of image features that ship with the Yocto Project, 
-                see the 
+                For a list of image features that ship with the Yocto Project,
+                see the
                 "<ulink url='&YOCTO_DOCS_REF_URL;#ref-features-image'>Images</ulink>"
                 section in the Yocto Project Reference Manual.
             </para>
@@ -4460,7 +4460,7 @@
                 </para>
 
                 <para>
-                    Downloaded archives reside in the 
+                    Downloaded archives reside in the
                     <link linkend='build-directory'>Build Directory</link> in
                     <filename>/tmp</filename> and are cleared up when they are no longer in use.
                 </para>
@@ -4604,7 +4604,7 @@
                 release of proprietary software.
                 The Yocto Project provides an archiver class to help avoid
                 some of these concerns.
-                See the 
+                See the
                 "<ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-archiver'>Archiving Sources - <filename>archive*.bbclass</filename></ulink>"
                 section in the Yocto Project Reference Manual for information
                 on this class.
@@ -4752,7 +4752,7 @@
        ##COREBASE##/meta-yocto \
        "
                 </literallayout>
-                Creating and providing an archive of the 
+                Creating and providing an archive of the
                 <link linkend='metadata'>Metadata</link> layers
                 (recipes, configuration files, and so forth)
                 enables you to meet your

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

@@ -18,11 +18,11 @@
             Because much of the information in this manual is general, it
             contains many references to other sources where you can find more
             detail.
-            For example, you can find detailed information on Git, repositories, 
+            For example, you can find detailed information on Git, repositories,
             and open source in general in many places on the Internet.
-            Another example specific to the Yocto Project is how to quickly 
-            set up your host development system and build an image, which you 
-            find in the 
+            Another example specific to the Yocto Project is how to quickly
+            set up your host development system and build an image, which you
+            find in the
             <ulink url='&YOCTO_DOCS_QS_URL;'>Yocto Project Quick Start</ulink>.
             <note>
                 By default, using the Yocto Project creates a Poky distribution.
@@ -40,7 +40,7 @@
         <para>
             The Yocto Project Development Manual does, however, provide
             guidance and examples on how to change the kernel source code,
-            reconfigure the kernel, and develop an application using the 
+            reconfigure the kernel, and develop an application using the
             popular <trademark class='trade'>Eclipse</trademark> IDE.
         </para>
     </section>
@@ -53,17 +53,17 @@
             <itemizedlist>
                 <listitem><para>Information that lets you get set
                     up to develop using the Yocto Project.</para></listitem>
-                <listitem><para>Information to help developers who are new to 
-                    the open source environment and to the distributed revision 
+                <listitem><para>Information to help developers who are new to
+                    the open source environment and to the distributed revision
                     control system Git, which the Yocto Project uses.
                     </para></listitem>
-                <listitem><para>An understanding of common end-to-end 
+                <listitem><para>An understanding of common end-to-end
                     development models and tasks.</para></listitem>
                 <listitem><para>Information about common development tasks
-                    generally used during image development for 
+                    generally used during image development for
                     embedded devices.
                     </para></listitem>
-                <listitem><para>Many references to other sources of related 
+                <listitem><para>Many references to other sources of related
                     information.</para></listitem>
             </itemizedlist>
         </para>
@@ -138,7 +138,8 @@
                     <ulink url='&YOCTO_WIKI_URL;/wiki/FAQ'>FAQ</ulink>:</emphasis>
                     A list of commonly asked questions and their answers.</para></listitem>
                 <listitem><para><emphasis>
-                    <ulink url='&YOCTO_HOME_URL;/download/yocto/yocto-project-&DISTRO;-release-notes-poky-&POKYVERSION;'>Release Notes</ulink>:</emphasis> Features, updates and known issues for the current
+                    <ulink url='&YOCTO_RELEASE_NOTES;'>Release Notes</ulink>:</emphasis>
+                    Features, updates and known issues for the current
                     release of the Yocto Project.</para></listitem>
                 <listitem><para><emphasis>
                     <ulink url='&YOCTO_HOME_URL;/tools-resources/projects/hob'>
@@ -147,8 +148,8 @@
                 <listitem><para><emphasis>
                     <ulink url='&YOCTO_HOME_URL;/download/build-appliance-0'>
                     Build Appliance</ulink>:</emphasis> A virtual machine that
-                    enables you to build and boot a custom embedded Linux image 
-                    with the Yocto Project using a non-Linux development system. 
+                    enables you to build and boot a custom embedded Linux image
+                    with the Yocto Project using a non-Linux development system.
                     For more information, see the
                     <ulink url='&YOCTO_HOME_URL;/documentation/build-appliance-manual'>Build Appliance</ulink>
                     page.
@@ -165,7 +166,7 @@
                         <listitem><para><ulink url='&YOCTO_LISTS_URL;/listinfo/yocto'></ulink> for a
                             Yocto Project Discussions mailing list.</para></listitem>
                         <listitem><para><ulink url='&YOCTO_LISTS_URL;/listinfo/poky'></ulink> for a
-                            Yocto Project Discussions mailing list about the 
+                            Yocto Project Discussions mailing list about the
                             OpenEmbedded build system (Poky).
                             </para></listitem>
                         <listitem><para><ulink url='&YOCTO_LISTS_URL;/listinfo/yocto-announce'></ulink>

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

@@ -18,8 +18,7 @@
              "<ulink url='&YOCTO_DOCS_BSP_URL;#creating-a-new-bsp-layer-using-the-yocto-bsp-script'>Creating a New BSP Layer Using the yocto-bsp Script</ulink>"
              section in the Yocto Project Board Support Package (BSP) Developer's Guide.
              For more complete information on how to work with the kernel, see the
-             <ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;'>Yocto Project Linux Kernel
-             Development Manual</ulink>.
+             <ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;'>Yocto Project Linux Kernel Development Manual</ulink>.
              </para></listitem>
          <listitem><para><emphasis>User Application Development:</emphasis>
              User Application Development covers development of applications that you intend
@@ -131,7 +130,7 @@
                     <ulink url='&YOCTO_DOCS_BSP_URL;#creating-a-new-bsp-layer-using-the-yocto-bsp-script'><filename>yocto-bsp</filename></ulink> script</emphasis>:
                     Layers are ideal for
                     isolating and storing work for a given piece of hardware.
-                    A layer is really just a location or area in which you place 
+                    A layer is really just a location or area in which you place
                     the recipes and configurations for your BSP.
                     In fact, a BSP is, in itself, a special type of layer.
                     The simplest way to create a new BSP layer that is compliant with the
@@ -165,7 +164,7 @@
                     Romley, sys940x, Sugar Bay, and tlk exist in their own separate layers
                     within the larger <filename>meta-intel</filename> layer.</note>
                     <para>When you set up a layer for a new BSP, you should follow a standard layout.
-                    This layout is described in the 
+                    This layout is described in the
                     "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-filelayout'>Example Filesystem Layout</ulink>"
                     section of the Board Support Package (BSP) Development Guide.
                     In the standard layout, you will notice a suggested structure for recipes and
@@ -343,10 +342,10 @@
                 If you are working in the kernel all the time, you probably would want
                 to set up your own local Git repository of the kernel tree.
                 If you just need to make some patches to the kernel, you can access
-                temporary kernel source files that were extracted and used 
+                temporary kernel source files that were extracted and used
                 during a build.
                 We will just talk about working with the temporary source code.
-                For more information on how to get kernel source code onto your 
+                For more information on how to get kernel source code onto your
                 host system, see the
                 "<link linkend='local-kernel-files'>Yocto Project Kernel</link>"
                 bulleted item earlier in the manual.
@@ -411,7 +410,7 @@
                         "<link linkend='local-yp-release'>Yocto Project Release</link>" earlier in this manual.
                         </para></listitem>
                     <listitem><para><emphasis>Establish the temporary kernel source files</emphasis>:
-                        Temporary kernel source files are kept in the 
+                        Temporary kernel source files are kept in the
                         <link linkend='build-directory'>Build Directory</link>
                         created by the
                         OpenEmbedded build system when you run BitBake.
@@ -474,7 +473,7 @@
         Application development involves creating an application that you want
         to run on your target hardware, which is running a kernel image created using the
         OpenEmbedded build system.
-        The Yocto Project provides an 
+        The Yocto Project provides an
         <ulink url='&YOCTO_DOCS_ADT_URL;#adt-intro-section'>Application Development Toolkit (ADT)</ulink>
         and stand-alone
         <ulink url='&YOCTO_DOCS_ADT_URL;#the-cross-development-toolchain'>cross-development toolchains</ulink>
@@ -950,7 +949,7 @@
                                 and then click "Next".</para></listitem>
                             <listitem><para>Select the root directory and browse to
                                 <filename>~/yocto-eclipse/plugins</filename>.</para></listitem>
-                            <listitem><para>Three plug-ins exist: 
+                            <listitem><para>Three plug-ins exist:
                                 <filename>org.yocto.bc.ui</filename>,
                                 <filename>org.yocto.sdk.ide</filename>, and
                                 <filename>org.yocto.sdk.remotetools</filename>.
@@ -980,7 +979,7 @@
                 <para>
                     To start, you need to do the following from within the Eclipse IDE:
                     <itemizedlist>
-                        <listitem><para>Choose "Preferences" from the 
+                        <listitem><para>Choose "Preferences" from the
                             "Windows" menu to display
                             the Preferences Dialog</para></listitem>
                         <listitem><para>Click "Yocto Project ADT"</para></listitem>
@@ -1010,7 +1009,7 @@
                                        <listitem><para><emphasis>
                                             <filename>Build System Derived Toolchain:</filename></emphasis>
                                             Select this mode if the cross-toolchain has been installed and built
-                                            as part of the 
+                                            as part of the
                                             <link linkend='build-directory'>Build Directory</link>.
                                             When you select <filename>Build system derived toolchain</filename>,
                                             you are using the toolchain bundled
@@ -1022,7 +1021,7 @@
                                 If you are using a stand-alone pre-built toolchain, you should be pointing to the
                                 where it is installed.
                                 If you used the ADT Installer script and accepted the default
-                                installation directory, the toolchain will be installed in 
+                                installation directory, the toolchain will be installed in
                                 the <filename>&YOCTO_ADTPATH_DIR;</filename> directory.
                                 Sections "<ulink url='&YOCTO_DOCS_ADT_URL;#configuring-and-running-the-adt-installer-script'>Configuring
                                 and Running the ADT Installer Script</ulink>" and
@@ -1034,17 +1033,17 @@
                                 field is the <link linkend='build-directory'>Build Directory</link>.
                                 See the "<ulink url='&YOCTO_DOCS_ADT_URL;#using-the-toolchain-from-within-the-build-tree'>Using
                                 BitBake and the Build Directory</ulink>" section in the Yocto Project Application
-                                Developer's Guide for information on how to install 
+                                Developer's Guide for information on how to install
                                 the toolchain into the Build Directory.</para></listitem>
                             <listitem><para><emphasis>Specify the Sysroot Location:</emphasis>
                                 This location is where the root filesystem for the target hardware resides.
-                                If you used the ADT Installer script and accepted the 
+                                If you used the ADT Installer script and accepted the
                                 default installation directory, then the location is
                                 <filename>/opt/poky/&lt;release&gt;</filename>.
                                 Additionally, when you use the ADT Installer script,
                                 the same location is used for
                                 the QEMU user-space tools and the NFS boot process.</para>
-                                <para>If you used either of the other two methods to 
+                                <para>If you used either of the other two methods to
                                 install the toolchain or did not accept the ADT Installer
                                 script's default installation directory, then the
                                 location of the sysroot filesystem depends on where you separately
@@ -1160,7 +1159,7 @@
                 configurations.
                 You can override these settings for a given project by following these steps:
                 <orderedlist>
-                    <listitem><para>Select "Change Yocto Project Settings" from the 
+                    <listitem><para>Select "Change Yocto Project Settings" from the
                         "Project" menu.
                         This selection brings up the Yocto Project Settings Dialog
                         and allows you to make changes specific to an individual project.
@@ -1170,14 +1169,14 @@
                         Dialog as described earlier
                         in the "<link linkend='configuring-the-eclipse-yocto-plug-in'>Configuring the Eclipse
                         Yocto Plug-in</link>" section.
-                        The Yocto Project Settings Dialog allows you to override 
+                        The Yocto Project Settings Dialog allows you to override
                         those default settings for a given project.</para></listitem>
                     <listitem><para>Make your configurations for the project and click "OK".
                         If you are running the Juno version of Eclipse, you can skip down to the next
                         section where you build the project.
                         If you are not working with Juno, you need to reconfigure the project as
                         described in the next step.</para></listitem>
-                    <listitem><para>Select "Reconfigure Project" from the 
+                    <listitem><para>Select "Reconfigure Project" from the
                         "Project" menu.
                         This selection reconfigures the project by running
                        <filename>autogen.sh</filename> in the workspace for your project.
@@ -1197,7 +1196,7 @@
             <para>
                 To build the project in Juno, right click on the project in the navigator pane and select
                 "Build Project".
-                If you are not running Juno, select "Build Project" from the 
+                If you are not running Juno, select "Build Project" from the
                 "Project" menu.
                 The console should update and you can note the cross-compiler you are using.
             </para>
@@ -1209,7 +1208,7 @@
             <para>
                 To start the QEMU emulator from within Eclipse, follow these steps:
                 <orderedlist>
-                    <listitem><para>Expose and select "External Tools" from 
+                    <listitem><para>Expose and select "External Tools" from
                         the "Run" menu.
                         Your image should appear as a selectable menu item.
                         </para></listitem>
@@ -1232,12 +1231,12 @@
             <title>Deploying and Debugging the Application</title>
 
             <para>
-                Once the QEMU emulator is running the image, you can deploy 
-                your application using the Eclipse IDE and use then use 
+                Once the QEMU emulator is running the image, you can deploy
+                your application using the Eclipse IDE and use then use
                 the emulator to perform debugging.
                 Follow these steps to deploy the application.
                 <orderedlist>
-                    <listitem><para>Select "Debug Configurations..." from the 
+                    <listitem><para>Select "Debug Configurations..." from the
                     "Run" menu.</para></listitem>
                     <listitem><para>In the left area, expand <filename>C/C++Remote Application</filename>.</para></listitem>
                     <listitem><para>Locate your project and select it to bring up a new
@@ -1258,7 +1257,7 @@
                         determined earlier.</para></listitem>
                     <listitem><para>Click "Finish" to close the
                         New Connections Dialog.</para></listitem>
-                    <listitem><para>Use the drop-down menu now in the 
+                    <listitem><para>Use the drop-down menu now in the
                         "Connection" field and pick the IP Address you entered.
                          </para></listitem>
                     <listitem><para>Click "Run" to bring up a login screen
@@ -1315,8 +1314,8 @@
                         display the output.
                         For information on how to use Lttng to trace an application,
                         see <ulink url='http://lttng.org/documentation'></ulink>
-                        and the 
-                        "<ulink url='&YOCTO_DOCS_PROF_URL;#lttng-linux-trace-toolkit-next-generation'>LTTng (Linux Trace Toolkit, next generation)</ulink>" 
+                        and the
+                        "<ulink url='&YOCTO_DOCS_PROF_URL;#lttng-linux-trace-toolkit-next-generation'>LTTng (Linux Trace Toolkit, next generation)</ulink>"
                         section, which is in the Yocto Project Profiling and Tracing Manual.
                         <note>Do not use <filename>Lttng-user space (legacy)</filename> tool.
                             This tool no longer has any upstream support.</note>
@@ -1326,18 +1325,18 @@
                         Tracing project.
                         Do the following:
                         <orderedlist>
-                            <listitem><para>Select "Open Perspective" from the 
+                            <listitem><para>Select "Open Perspective" from the
                                 "Window" menu and then select "Tracing".</para></listitem>
                             <listitem><para>Click "OK" to change the Eclipse perspective
                                 into the Tracing perspective.</para></listitem>
                             <listitem><para>Create a new Tracing project by selecting
                                 "Project" from the "File -> New" menu.</para></listitem>
-                            <listitem><para>Choose "Tracing Project" from the 
+                            <listitem><para>Choose "Tracing Project" from the
                                 "Tracing" menu.
                                 </para></listitem>
                             <listitem><para>Generate your tracing data on the remote target.
                                 </para></listitem>
-                            <listitem><para>Select "Lttng2.0 ust trace import" from 
+                            <listitem><para>Select "Lttng2.0 ust trace import" from
                                 the "Yocto Project Tools" menu to
                                 start the data import process.</para></listitem>
                             <listitem><para>Specify your remote connection name.</para></listitem>
@@ -1348,8 +1347,8 @@
                             <listitem><para>Click "OK" to complete the import process.
                                 The data is now in the local tracing project you created.</para></listitem>
                             <listitem><para>Right click on the data and then use the menu to
-                                Select "Generic CTF Trace" from the 
-                                "Trace Type... -> Common Trace Format" menu to map 
+                                Select "Generic CTF Trace" from the
+                                "Trace Type... -> Common Trace Format" menu to map
                                 the tracing type.</para></listitem>
                             <listitem><para>Right click the mouse and select "Open"
                                 to bring up the Eclipse Lttng Trace Viewer so you
@@ -1386,7 +1385,7 @@
 
             <para>
                 Within the Eclipse IDE, you can create a Yocto BitBake Commander project,
-                edit the <link linkend='metadata'>Metadata</link>, and then use 
+                edit the <link linkend='metadata'>Metadata</link>, and then use
                 <ulink url='&YOCTO_HOME_URL;/tools-resources/projects/hob'>Hob</ulink> to build a customized
                 image all within one IDE.
             </para>
@@ -1397,16 +1396,16 @@
                 <para>
                     To create a Yocto BitBake Commander project, follow these steps:
                     <orderedlist>
-                        <listitem><para>Select "Other" from the 
-                            "Window -> Open Perspective" menu 
+                        <listitem><para>Select "Other" from the
+                            "Window -> Open Perspective" menu
                             and then choose "Bitbake Commander".</para></listitem>
                         <listitem><para>Click "OK" to change the perspective to
                             Bitbake Commander.</para></listitem>
                         <listitem><para>Select "Project" from the "File -> New"
                             menu to create a new Yocto
                             Bitbake Commander project.</para></listitem>
-                        <listitem><para>Choose "New Yocto Project" from the 
-                            "Yocto Project Bitbake Commander" menu and click 
+                        <listitem><para>Choose "New Yocto Project" from the
+                            "Yocto Project Bitbake Commander" menu and click
                             "Next".</para></listitem>
                         <listitem><para>Enter the Project Name and choose the Project Location.
                             The Yocto project's Metadata files will be put under the directory
@@ -1424,7 +1423,7 @@
                 <title>Editing the Metadata</title>
 
                 <para>
-                    After you create the Yocto Bitbake Commander project, you can modify the 
+                    After you create the Yocto Bitbake Commander project, you can modify the
                     <link linkend='metadata'>Metadata</link> files
                     by opening them in the project.
                     When editing recipe files (<filename>.bb</filename> files), you can view BitBake
@@ -1436,8 +1435,8 @@
                     To edit the Metadata, follow these steps:
                     <orderedlist>
                         <listitem><para>Select your Yocto Bitbake Commander project.</para></listitem>
-                        <listitem><para>Select "BitBake Recipe" from the 
-                        "File -> New -> Yocto BitBake Commander" menu 
+                        <listitem><para>Select "BitBake Recipe" from the
+                        "File -> New -> Yocto BitBake Commander" menu
                             to open a new recipe wizard.</para></listitem>
                         <listitem><para>Point to your source by filling in the "SRC_URL" field.
                             For example, you can add a recipe to your
@@ -1459,13 +1458,13 @@
                 <title>Building and Customizing the Image Using Hob</title>
 
                 <para>
-                    To build and customize the image using Hob from within the 
+                    To build and customize the image using Hob from within the
                     Eclipse IDE, follow these steps:
                     <orderedlist>
                         <listitem><para>Select your Yocto Bitbake Commander project.</para></listitem>
                         <listitem><para>Select "Launch Hob" from the "Project"
                             menu.</para></listitem>
-                        <listitem><para>Enter the 
+                        <listitem><para>Enter the
                             <link linkend='build-directory'>Build Directory</link>
                             where you want to put your final images.</para></listitem>
                         <listitem><para>Click "OK" to launch Hob.</para></listitem>
@@ -1508,7 +1507,7 @@
                     support development using actual hardware.
                     For example, the area might contain
                     <filename>.hddimg</filename> files that combine the
-                    kernel image with the filesystem, boot loaders, and 
+                    kernel image with the filesystem, boot loaders, and
                     so forth.
                     Be sure to get the files you need for your particular
                     development process.</para>
@@ -1879,9 +1878,9 @@
 
     <para>
         For a better understanding of Hob, see the project page at
-        <ulink url='&YOCTO_HOME_URL;/tools-resources/projects/hob'></ulink> 
+        <ulink url='&YOCTO_HOME_URL;/tools-resources/projects/hob'></ulink>
         on the Yocto Project website.
-        If you follow the "Documentation" link from the Hob page, you will 
+        If you follow the "Documentation" link from the Hob page, you will
         find a short introductory training video on Hob.
         The following lists some features of Hob:
         <itemizedlist>
@@ -1893,9 +1892,9 @@
             <listitem><para>You can set the
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink>
                 for which you are building the image.</para></listitem>
-            <listitem><para>You can modify various policy settings such as the 
+            <listitem><para>You can modify various policy settings such as the
                 package format with which to build,
-                the parallelism BitBake uses, whether or not to build an 
+                the parallelism BitBake uses, whether or not to build an
                 external toolchain, and which host to build against.
                 </para></listitem>
             <listitem><para>You can manage

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

@@ -782,7 +782,7 @@
         Once the build completes, the list of all licenses found and used during that build are
         kept in the
         <link linkend='build-directory'>Build Directory</link> at
-        <filename>tmp/deploy/images/licenses</filename>.
+        <filename>tmp/deploy/licenses</filename>.
     </para>
 
     <para>

documentation/dev-manual/dev-manual.xml

@@ -51,6 +51,31 @@
                 <date>April 2013</date>
                 <revremark>Released with the Yocto Project 1.4 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>1.4.1</revnumber>
+                <date>June 2013</date>
+                <revremark>Released with the Yocto Project 1.4.1 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.4.2</revnumber>
+                <date>August 2013</date>
+                <revremark>Released with the Yocto Project 1.4.2 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.4.3</revnumber>
+                <date>March 2014</date>
+                <revremark>Released with the Yocto Project 1.4.3 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.4.4</revnumber>
+                <date>May 2014</date>
+                <revremark>Released with the Yocto Project 1.4.4 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.4.5</revnumber>
+                <date>July 2014</date>
+                <revremark>Released with the Yocto Project 1.4.5 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>

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

@@ -203,7 +203,7 @@
             <filename>oe-core/meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb</filename>
             to a recipe in your layer, <filename>FILESEXTRAPATHS</filename>
             is typically set to
-            <filename>${THISDIR}/${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PN'><filename>PN</filename></ulink><filename>}</filename>.
+            <filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-THISDIR'><filename>THISDIR</filename></ulink><filename>}/${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PN'><filename>PN</filename></ulink><filename>}</filename>.
             See the "<link linkend='modifying-an-existing-recipe'>Modifying an Existing Recipe</link>"
             section for more information.
         </para>

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

@@ -92,10 +92,13 @@
                 <literallayout class='monospaced'>
      <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS'>FILESEXTRAPATHS</ulink> := "${THISDIR}/${PN}"
                 </literallayout>
-                The path <filename>${THISDIR}/${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PN'><filename>PN</filename></ulink><filename>}</filename> expands
-                to "linux-yocto" in the current directory for this example.
-                If you add any new files that modify the kernel recipe,
-                you need to place them in your layer in the following area:
+                The path <filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-THISDIR'><filename>THISDIR</filename></ulink><filename>}/${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PN'><filename>PN</filename></ulink><filename>}</filename>
+                expands to "linux-yocto" in the current directory for this
+                example.
+                If you add any new files that modify the kernel recipe and you
+                have extended <filename>FILESPATH</filename> as
+                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/
                 </literallayout>
@@ -149,15 +152,15 @@
                 You can make wholesale or incremental changes to the Linux
                 kernel <filename>.config</filename> file by including a
                 <filename>defconfig</filename> or by specifying
-                configuration fragments in the 
+                configuration fragments in the
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>.
             </para>
 
             <para>
                 If you have a complete Linux kernel <filename>.config</filename>
-                file you want to use, copy it to a directory named 
-                <filename>files</filename>, which must be in 
-                your layer's <filename>recipes-kernel/linux</filename> 
+                file you want to use, copy it to a directory named
+                <filename>files</filename>, which must be in
+                your layer's <filename>recipes-kernel/linux</filename>
                 directory, and name the file "defconfig".
                 Then, add the following lines to your linux-yocto
                 <filename>.bbappend</filename> file in your layer:
@@ -165,13 +168,13 @@
      FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
      SRC_URI += "file://defconfig"
                 </literallayout>
-                The 
-                <filename>SRC_URI</filename> tells the build system how to 
-                search for the file, while the 
+                The
+                <filename>SRC_URI</filename> tells the build system how to
+                search for the file, while the
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></ulink>
-                extends the 
+                extends the
                 <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESPATH'><filename>FILESPATH</filename></ulink>
-                variable (search directories) to include the 
+                variable (search directories) to include the
                 <filename>files</filename> directory you created for the
                 configuration changes.
             </para>
@@ -193,8 +196,8 @@
      CONFIG_SERIAL_CORE=y
      CONFIG_SERIAL_CORE_CONSOLE=y
                 </literallayout>
-                Next, include this configuration fragment and extend the 
-                <filename>FILESPATH</filename> variable in your 
+                Next, include this configuration fragment and extend the
+                <filename>FILESPATH</filename> variable in your
                 <filename>.bbappend</filename> file:
                 <literallayout class='monospaced'>
      FILESEXTRAPATHS_prepend := "${THISDIR}/files:"

documentation/kernel-dev/kernel-dev.xml

@@ -36,6 +36,31 @@
                 <date>April 2013</date>
                 <revremark>Released with the Yocto Project 1.4 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>1.4.1</revnumber>
+                <date>June 2013</date>
+                <revremark>Released with the Yocto Project 1.4.1 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.4.2</revnumber>
+                <date>August 2013</date>
+                <revremark>Released with the Yocto Project 1.4.2 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.4.3</revnumber>
+                <date>March 2014</date>
+                <revremark>Released with the Yocto Project 1.4.3 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.4.4</revnumber>
+                <date>May 2014</date>
+                <revremark>Released with the Yocto Project 1.4.4 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.4.5</revnumber>
+                <date>July 2014</date>
+                <revremark>Released with the Yocto Project 1.4.5 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>
@@ -51,7 +76,7 @@
       <note>
           Due to production processes, there could be differences between the Yocto Project
           documentation bundled in the release tarball and the
-          <ulink url='&YOCTO_DOCS_KERNEL_URL;'>Yocto Project Linux Kernel Development Manual</ulink> on
+          <ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;'>Yocto Project Linux Kernel Development Manual</ulink> on
           the <ulink url='&YOCTO_HOME_URL;'>Yocto Project</ulink> website.
           For the latest version of this manual, see the manual on the website.
       </note>

documentation/poky.ent

@@ -1,9 +1,11 @@
-<!ENTITY DISTRO "1.4">
+<!ENTITY DISTRO "1.4.5">
+<!ENTITY DISTRO_COMPRESSED "145">
 <!ENTITY DISTRO_NAME "dylan">
-<!ENTITY YOCTO_DOC_VERSION "1.4">
-<!ENTITY POKYVERSION "9.0">
+<!ENTITY YOCTO_DOC_VERSION "1.4.5">
+<!ENTITY POKYVERSION "9.0.5">
+<!ENTITY POKYVERSION_COMPRESSED "905">
 <!ENTITY YOCTO_POKY "poky-&DISTRO_NAME;-&POKYVERSION;">
-<!ENTITY COPYRIGHT_YEAR "2010-2013">
+<!ENTITY COPYRIGHT_YEAR "2010-2014">
 <!ENTITY YOCTO_DL_URL "http://downloads.yoctoproject.org">
 <!ENTITY YOCTO_HOME_URL "http://www.yoctoproject.org">
 <!ENTITY YOCTO_LISTS_URL "http://lists.yoctoproject.org">
@@ -12,8 +14,9 @@
 <!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 OE_HOME_URL "http://www.openembedded.org">
-<!ENTITY OE_LISTS_URL "http://lists.linuxtogo.org/cgi-bin/mailman">
+<!ENTITY OE_LISTS_URL "http://lists.openembedded.org/mailman">
 <!ENTITY OE_DOCS_URL "http://docs.openembedded.org">
 <!ENTITY OH_HOME_URL "http://o-hand.com">
 <!ENTITY BITBAKE_HOME_URL "http://developer.berlios.de/projects/bitbake/">
@@ -32,7 +35,7 @@
 <!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_ADTINSTALLER_DL_URL "&YOCTO_RELEASE_DL_URL;/adt_installer">
+<!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">
 <!ENTITY YOCTO_QEMU_DL_URL "&YOCTO_MACHINES_DL_URL;/qemu">
@@ -56,6 +59,6 @@
      diffutils diffstat git cpp gcc gcc-c++ eglibc-devel texinfo chrpath \
      ccache">
 <!ENTITY OPENSUSE_HOST_PACKAGES_ESSENTIAL "python gcc gcc-c++ git chrpath make wget python-xml \
-     diffstat texinfo python-curses">
+     diffstat texinfo python-curses patch">
 <!ENTITY CENTOS_HOST_PACKAGES_ESSENTIAL "gawk make wget tar bzip2 gzip python unzip perl patch \
      diffutils diffstat git cpp gcc gcc-c++ glibc-devel texinfo chrpath">

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

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

documentation/profile-manual/profile-manual.xml

@@ -36,6 +36,31 @@
                 <date>April 2013</date>
                 <revremark>Released with the Yocto Project 1.4 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>1.4.1</revnumber>
+                <date>June 2013</date>
+                <revremark>Released with the Yocto Project 1.4.1 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.4.2</revnumber>
+                <date>August 2013</date>
+                <revremark>Released with the Yocto Project 1.4.2 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.4.3</revnumber>
+                <date>March 2014</date>
+                <revremark>Released with the Yocto Project 1.4.3 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.4.4</revnumber>
+                <date>May 2014</date>
+                <revremark>Released with the Yocto Project 1.4.4 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.4.5</revnumber>
+                <date>July 2014</date>
+                <revremark>Released with the Yocto Project 1.4.5 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>
@@ -54,7 +79,7 @@
       <note>
           Due to production processes, there could be differences between the Yocto Project
           documentation bundled in the release tarball and the
-          <ulink url='&YOCTO_DOCS_PROF_URL;'>Yocto Project Tracing and Profiling Manual</ulink> on
+          <ulink url='&YOCTO_DOCS_PROF_URL;'>Yocto Project Profiling and Tracing Manual</ulink> on
           the <ulink url='&YOCTO_HOME_URL;'>Yocto Project</ulink> website.
           For the latest version of this manual, see the manual on the website.
       </note>

documentation/ref-manual/introduction.xml

@@ -20,9 +20,9 @@
         For task-based information using the Yocto Project, see the
         <ulink url='&YOCTO_DOCS_DEV_URL;'>Yocto Project Development Manual</ulink>
         and the <ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;'>Yocto Project Linux Kernel Development Manual</ulink>.
-        For Board Support Package (BSP) structure information, see the 
+        For Board Support Package (BSP) structure information, see the
         <ulink url='&YOCTO_DOCS_BSP_URL;'>Yocto Project Board Support Package (BSP) Developer's Guide</ulink>.
-        You can also find lots of Yocto Project information on the 
+        You can also find lots of Yocto Project information on the
         <ulink url="&YOCTO_HOME_URL;">Yocto Project website</ulink>.
     </para>
 </section>
@@ -33,7 +33,7 @@
         This reference manual consists of the following:
         <itemizedlist>
             <listitem><para><emphasis>
-                <link linkend='usingpoky'>Using the Yocto Project</link>:</emphasis> 
+                <link linkend='usingpoky'>Using the Yocto Project</link>:</emphasis>
                 Provides an overview of the components that make up the Yocto Project
                 followed by information about debugging images created in the Yocto Project.
                 </para></listitem>
@@ -105,6 +105,7 @@
             <itemizedlist>
                 <listitem><para>Ubuntu 10.04</para></listitem>
                 <listitem><para>Ubuntu 11.10</para></listitem>
+                <listitem><para>Ubuntu 12.04 (LTS)</para></listitem>
                 <listitem><para>Ubuntu 12.10</para></listitem>
                 <listitem><para>Fedora release 16 (Verne)</para></listitem>
                 <listitem><para>Fedora release 17 (Beefy Miracle)</para></listitem>

documentation/ref-manual/migration.xml

@@ -335,6 +335,24 @@
         </para>
     </section>
 
+    <section id='migration-1.4-custom-interfaces-file-netbase-change'>
+        <title>Custom Interfaces File (netbase change)</title>
+
+        <para>
+            If you have created your own custom 
+            <filename>etc/network/interfaces</filename> file by creating 
+            an append file for the <filename>netbase</filename> recipe, 
+            you now need to create an append file for the 
+            <filename>init-ifupdown</filename> recipe instead, which you can 
+            find in the 
+            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+            at <filename>meta/recipes-core/init-ifupdown</filename>.
+            For information on how to use append files, see the 
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#using-bbappend-files'>Using .bbappend Files</ulink>"
+            in the Yocto Project Development Manual.
+        </para>
+    </section>
+
     <section id='migration-1.4-remote-debugging'>
         <title>Remote Debugging</title>
 

documentation/ref-manual/ref-manual.xml

@@ -67,6 +67,31 @@
                 <date>April 2013</date>
                 <revremark>Released with the Yocto Project 1.4 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>1.4.1</revnumber>
+                <date>June 2013</date>
+                <revremark>Released with the Yocto Project 1.4.1 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.4.2</revnumber>
+                <date>August 2013</date>
+                <revremark>Released with the Yocto Project 1.4.2 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.4.3</revnumber>
+                <date>March 2014</date>
+                <revremark>Released with the Yocto Project 1.4.3 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.4.4</revnumber>
+                <date>May 2014</date>
+                <revremark>Released with the Yocto Project 1.4.4 Release.</revremark>
+            </revision>
+            <revision>
+                <revnumber>1.4.5</revnumber>
+                <date>July 2014</date>
+                <revremark>Released with the Yocto Project 1.4.5 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>

documentation/ref-manual/ref-variables.xml

@@ -600,31 +600,31 @@ Core layer for images cannot be removed
 
         <glossentry id='var-COMPATIBLE_HOST'><glossterm>COMPATIBLE_HOST</glossterm>
             <glossdef>
-                <para>A regular expression that resolves to one or more hosts 
-                    (when the recipe is native) or one or more targets (when 
+                <para>A regular expression that resolves to one or more hosts
+                    (when the recipe is native) or one or more targets (when
                     the recipe is non-native) with which a recipe is compatible.
                     The regular expression is matched against
                     <link linkend="var-HOST_SYS"><filename>HOST_SYS</filename></link>.
                     You can use the variable to stop recipes from being built
-                    for classes of systems with which the recipes are not 
+                    for classes of systems with which the recipes are not
                     compatible.
                     Stopping these builds is particularly useful with kernels.
-                    The variable also helps to increase parsing speed 
-                    since the build system skips parsing recipes not 
+                    The variable also helps to increase parsing speed
+                    since the build system skips parsing recipes not
                     compatible with the current system.</para>
             </glossdef>
         </glossentry>
 
         <glossentry id='var-COMPATIBLE_MACHINE'><glossterm>COMPATIBLE_MACHINE</glossterm>
             <glossdef>
-                <para>A regular expression that resolves to one or more 
+                <para>A regular expression that resolves to one or more
                     target machines with which a recipe is compatible.
                     The regular expression is matched against
                     <link linkend="var-MACHINEOVERRIDES"><filename>MACHINEOVERRIDES</filename></link>.
                     You can use the variable to stop recipes from being built
                     for machines with which the recipes are not compatible.
                     Stopping these builds is particularly useful with kernels.
-                    The variable also helps to increase parsing speed 
+                    The variable also helps to increase parsing speed
                     since the build system skips parsing recipes not
                     compatible with the current machine.</para>
             </glossdef>
@@ -746,8 +746,8 @@ Core layer for images cannot be removed
                     Specifies a weak bias for recipe selection priority.
                 </para>
                 <para>
-                    The most common usage of this is variable is to set 
-                    it to "-1" within a recipe for a development version of a 
+                    The most common usage of this is variable is to set
+                    it to "-1" within a recipe for a development version of a
                     piece of software.
                     Using the variable in this way causes the stable version
                     of the recipe to build by default in the absence of
@@ -755,10 +755,10 @@ Core layer for images cannot be removed
                     being used to build the development version.
                 </para>
                 <note>
-                    The bias provided by <filename>DEFAULT_PREFERENCE</filename> 
-                    is weak and is overridden by 
+                    The bias provided by <filename>DEFAULT_PREFERENCE</filename>
+                    is weak and is overridden by
                     <filename><link linkend='var-BBFILE_PRIORITY'>BBFILE_PRIORITY</link></filename>
-                    if the that variable is different between two layers 
+                    if the that variable is different between two layers
                     that contain different versions of the same recipe.
                 </note>
             </glossdef>
@@ -909,12 +909,12 @@ Core layer for images cannot be removed
         <glossentry id='var-DISTROOVERRIDES'><glossterm>DISTROOVERRIDES</glossterm>
             <glossdef>
                 <para>
-                    This variable lists overrides specific to the current 
-                    distribution. 
-                    By default, the variable list includes the value of the 
+                    This variable lists overrides specific to the current
+                    distribution.
+                    By default, the variable list includes the value of the
                     <filename><link linkend='var-DISTRO'>DISTRO</link></filename>
                     variable.
-                    You can extend the variable to apply any variable overrides 
+                    You can extend the variable to apply any variable overrides
                     you want as part of the distribution and are not
                     already in <filename>OVERRIDES</filename> through
                     some other means.
@@ -1158,16 +1158,16 @@ Core layer for images cannot be removed
                     Extends the search path the OpenEmbedded build system uses
                     when looking for files and patches as it processes recipes
                     and append files.
-                    The directories BitBake uses when it processes recipes 
-                    are defined by the 
+                    The directories BitBake uses when it processes recipes
+                    are defined by the
                     <link linkend='var-FILESPATH'><filename>FILESPATH</filename></link>
-                    variable, and can be extended using 
+                    variable, and can be extended using
                     <filename>FILESEXTRAPATHS</filename>.
                 </para>
 
                 <para>
-                    Best practices dictate that you accomplish this by using the 
-                    variable from within a <filename>.bbappend</filename> file 
+                    Best practices dictate that you accomplish this by using the
+                    variable from within a <filename>.bbappend</filename> file
                     and that you prepend paths as follows:
                     <literallayout class='monospaced'>
      FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
@@ -1175,13 +1175,29 @@ Core layer for images cannot be removed
                     In the above example, the build system looks for files in
                     a directory that has the same name as the corresponding
                     append file.
+                    <note>
+                        <para>When extending <filename>FILESEXTRAPATHS</filename>,
+                        be sure to use the immediate expansion
+                        (<filename>:=</filename>) operator.
+                        Immediate expansion makes sure that BitBake evaluates
+                        <link linkend='var-THISDIR'><filename>THISDIR</filename></link>
+                        at the time the directive
+                        is encountered rather than at some later time when
+                        expansion might result in a directory that does not
+                        contain the files you need.</para>
+                        <para>Also, include the trailing separating colon
+                        character if you are prepending.
+                        The trailing colon character is necessary because you
+                        are directing BitBake to extend the path by prepending
+                        directories to the search path.</para>
+                    </note>
                     Here is another common use:
                     <literallayout class='monospaced'>
      FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
                     </literallayout>
-                    In this example, the build system extends the 
+                    In this example, the build system extends the
                     <filename>FILESPATH</filename> variable to include a
-                    directory named <filename>files</filename> that is in the 
+                    directory named <filename>files</filename> that is in the
                     same directory as the corresponding append file.
                 </para>
 
@@ -1195,11 +1211,11 @@ Core layer for images cannot be removed
                 <para>
                     By prepending paths in <filename>.bbappend</filename>
                     files, you allow multiple append files that reside in
-                    different layers but are used for the same recipe to 
+                    different layers but are used for the same recipe to
                     correctly extend the path.
                     <note>
                         Be sure to use the immediate expansion
-                        (<filename>:=</filename>) operator and include 
+                        (<filename>:=</filename>) operator and include
                         the trailing separating colon character.
                     </note>
                 </para>
@@ -1209,17 +1225,17 @@ Core layer for images cannot be removed
         <glossentry id='var-FILESPATH'><glossterm>FILESPATH</glossterm>
             <glossdef>
                 <para>
-                    The default set of directories the OpenEmbedded build system 
+                    The default set of directories the OpenEmbedded build system
                     uses when searching for patches and files.
                     During the build process, BitBake searches each directory in
-                    <filename>FILESPATH</filename> in the specified order when 
-                    looking for files and patches specified by each 
+                    <filename>FILESPATH</filename> in the specified order when
+                    looking for files and patches specified by each
                     <filename>file://</filename> URI in a recipe.
                 </para>
 
                 <para>
-                    The default value for the <filename>FILESPATH</filename> 
-                    variable is defined in the <filename>base.bbclass</filename> 
+                    The default value for the <filename>FILESPATH</filename>
+                    variable is defined in the <filename>base.bbclass</filename>
                     class found in <filename>meta/classes</filename> in the
                     <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>:
                     <literallayout class='monospaced'>
@@ -1227,18 +1243,18 @@ Core layer for images cannot be removed
         "${FILE_DIRNAME}/${BPN}", "${FILE_DIRNAME}/files"], d)}"
                     </literallayout>
                     <note>
-                        Do not hand-edit the <filename>FILESPATH</filename> 
+                        Do not hand-edit the <filename>FILESPATH</filename>
                         variable.
                     </note>
                     Be aware that the default <filename>FILESPATH</filename>
                     directories do not map to directories in custom layers
-                    where append files (<filename>.bbappend</filename>) 
+                    where append files (<filename>.bbappend</filename>)
                     are used.
                     If you want the build system to find patches or files
                     that reside with your append files, you need to extend
-                    the <filename>FILESPATH</filename> variable by using 
-                    the 
-                    <link linkend='var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></link> 
+                    the <filename>FILESPATH</filename> variable by using
+                    the
+                    <link linkend='var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></link>
                     variable.
                 </para>
             </glossdef>
@@ -1306,10 +1322,10 @@ Core layer for images cannot be removed
         <glossentry id='var-HOST_SYS'><glossterm>HOST_SYS</glossterm>
             <glossdef>
                 <para>
-                    Specifies the system, including the architecture and the 
+                    Specifies the system, including the architecture and the
                     operating system, for with the build is occurring
                     in the context of the current
-                    recipe. 
+                    recipe.
                     The OpenEmbedded build system automatically sets this
                     variable.
                     You do not need to set the variable yourself.
@@ -1319,12 +1335,12 @@ Core layer for images cannot be removed
                     Here are two examples:
                     <itemizedlist>
                         <listitem><para>Given a native recipe on a 32-bit
-                            x86 machine running Linux, the value is 
+                            x86 machine running Linux, the value is
                             "i686-linux".
                             </para></listitem>
-                        <listitem><para>Given a recipe being built for a 
+                        <listitem><para>Given a recipe being built for a
                             little-endian MIPS target running Linux,
-                            the value might be "mipsel-linux". 
+                            the value might be "mipsel-linux".
                             </para></listitem>
                     </itemizedlist>
                 </para>
@@ -1419,24 +1435,24 @@ Core layer for images cannot be removed
                 <para>
                     Specifies the list of locales to install into the image
                     during the root filesystem construction process.
-                    The OpenEmbedded build system automatically splits locale 
-                    files, which are used for localization, into separate 
-                    packages. 
+                    The OpenEmbedded build system automatically splits locale
+                    files, which are used for localization, into separate
+                    packages.
                     Setting the <filename>IMAGE_LINGUAS</filename> variable
-                    ensures that any locale packages that correspond to packages 
-                    already selected for installation into the image are also 
-                    installed. 
+                    ensures that any locale packages that correspond to packages
+                    already selected for installation into the image are also
+                    installed.
                     Here is an example:
                     <literallayout class='monospaced'>
      IMAGE_LINGUAS = "pt-br de-de"
                     </literallayout>
-                    In this example, the build system ensures any Brazilian 
-                    Portuguese and German locale files that correspond to 
-                    packages in the image are installed (i.e. 
+                    In this example, the build system ensures any Brazilian
+                    Portuguese and German locale files that correspond to
+                    packages in the image are installed (i.e.
                     <filename>*-locale-pt-br</filename>
-                    and <filename>*-locale-de-de</filename> as well as 
+                    and <filename>*-locale-de-de</filename> as well as
                     <filename>*-locale-pt</filename>
-                    and <filename>*-locale-de</filename>, since some software 
+                    and <filename>*-locale-de</filename>, since some software
                     packages only provide locale files by language and not by
                     country-specific language).
                 </para>
@@ -1672,12 +1688,12 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
         <glossentry id='var-INSANE_SKIP'><glossterm>INSANE_SKIP</glossterm>
             <glossdef>
                 <para>
-                    Specifies the QA checks to skip for a specific package 
+                    Specifies the QA checks to skip for a specific package
                     within a recipe.
-                    For example, to skip the check for symbolic link 
-                    <filename>.so</filename> files in the main package of a 
+                    For example, to skip the check for symbolic link
+                    <filename>.so</filename> files in the main package of a
                     recipe, add the following to the recipe.
-                    The package name override must be used, which in this 
+                    The package name override must be used, which in this
                     example is <filename>${PN}</filename>:
                     <literallayout class='monospaced'>
      INSANE_SKIP_${PN} += "dev-so"
@@ -1685,7 +1701,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                 </para>
                 <para>
                     See the "<link linkend='ref-classes-insane'>Generated Output Quality Assurance Checks - <filename>insane.bbclass</filename></link>"
-                    section for a list of the valid QA checks you can 
+                    section for a list of the valid QA checks you can
                     specify using this variable.
                 </para>
             </glossdef>
@@ -2199,7 +2215,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
         <glossentry id='var-LOG_DIR'><glossterm>LOG_DIR</glossterm>
             <glossdef>
                 <para>
-                    Specifies the directory to which the OpenEmbedded build 
+                    Specifies the directory to which the OpenEmbedded build
                     system writes overall log files.
                     The default directory is <filename>${TMPDIR}/log</filename>.
                 </para>
@@ -2474,22 +2490,22 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
         <glossentry id='var-MACHINEOVERRIDES'><glossterm>MACHINEOVERRIDES</glossterm>
             <glossdef>
                 <para>
-                    Lists overrides specific to the current machine. 
+                    Lists overrides specific to the current machine.
                     By default, this list includes the value
-                    of <filename><link linkend='var-MACHINE'>MACHINE</link></filename>. 
-                    You can extend the list to apply variable overrides for 
+                    of <filename><link linkend='var-MACHINE'>MACHINE</link></filename>.
+                    You can extend the list to apply variable overrides for
                     classes of machines.
-                    For example, all QEMU emulated machines (e.g. qemuarm, 
+                    For example, all QEMU emulated machines (e.g. qemuarm,
                     qemux86, and so forth) include a common file named
                     <filename>meta/conf/machine/include/qemu.inc</filename>
-                    that prepends <filename>MACHINEOVERRIDES</filename> with 
+                    that prepends <filename>MACHINEOVERRIDES</filename> with
                     the following variable override:
                     <literallayout class='monospaced'>
     MACHINEOVERRIDES =. "qemuall:"
                     </literallayout>
                     Applying an override like <filename>qemuall</filename>
                     affects all QEMU emulated machines elsewhere.
-                    Here is an example from the 
+                    Here is an example from the
                     <filename>connman-conf</filename> recipe:
                     <literallayout class='monospaced'>
     SRC_URI_append_qemuall = "file://wired.config \
@@ -2578,18 +2594,18 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                 <para>
                     A string identifying the host distribution.
                     Strings consist of the host distributor ID
-                    followed by the release, as reported by the 
+                    followed by the release, as reported by the
                     <filename>lsb_release</filename> tool
-                    or as read from <filename>/etc/lsb-release</filename>. 
-                    For example, when running a build on Ubuntu 12.10, the value 
-                    is "Ubuntu-12.10". 
-                    If this information is unable to be determined, the value 
+                    or as read from <filename>/etc/lsb-release</filename>.
+                    For example, when running a build on Ubuntu 12.10, the value
+                    is "Ubuntu-12.10".
+                    If this information is unable to be determined, the value
                     resolves to "Unknown".
                 </para>
                 <para>
-                    This variable is used by default to isolate native shared 
-                    state packages for different distributions (e.g. to avoid 
-                    problems with <filename>glibc</filename> version 
+                    This variable is used by default to isolate native shared
+                    state packages for different distributions (e.g. to avoid
+                    problems with <filename>glibc</filename> version
                     incompatibilities).
                     Additionally, the variable is checked against
                     <link linkend='var-SANITY_TESTED_DISTROS'><filename>SANITY_TESTED_DISTROS</filename></link>
@@ -2920,15 +2936,15 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
         <glossentry id='var-PROVIDES'><glossterm>PROVIDES</glossterm>
             <glossdef>
                 <para>
-                    A list of aliases that a recipe also provides. 
-                    These aliases are useful for satisfying dependencies of 
-                    other recipes during the build (as specified by 
+                    A list of aliases that a recipe also provides.
+                    These aliases are useful for satisfying dependencies of
+                    other recipes during the build (as specified by
                     <filename><link linkend='var-DEPENDS'>DEPENDS</link></filename>).
                     <note>
-                        A recipe's own 
+                        A recipe's own
                         <filename><link linkend='var-PN'>PN</link></filename>
-                        is implicitly already in its 
-                        <filename>PROVIDES</filename> list. 
+                        is implicitly already in its
+                        <filename>PROVIDES</filename> list.
                     </note>
                 </para>
             </glossdef>
@@ -3026,28 +3042,30 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
             <glossdef>
                 <para>
                     Lists a package's run-time dependencies (i.e. other packages)
-                    that must be installed for the package to be built.
-                    In other words, in order for the package to be built and
-                    run correctly, it depends on the listed packages.
-                    If a package in this list cannot be found, it is probable
-                    that a dependency error would occur before the build.
+                    that must be installed in order for the built package to run
+                    correctly.
+                    If a package in this list cannot be found during the build,
+                    you will get a build error.
                 </para>
 
                 <para>
-                    The names of the variables you list with
+                    The names of the packages you list within
                     <filename>RDEPENDS</filename> must be the names of other
-                    packages as listed in the
+                    packages - they cannot be recipe names.
+                    Although package names and recipe names usually match,
+                    the important point here is that you are
+                    providing package names within the
+                    <filename>RDEPENDS</filename> variable.
+                    For an example of the default list of packages created from
+                    a recipe, see the
                     <link linkend='var-PACKAGES'><filename>PACKAGES</filename></link>
                     variable.
-                    You should not list recipe names
-                    (<link linkend='var-PN'><filename>PN</filename></link>).
                 </para>
 
                 <para>
                     Because the <filename>RDEPENDS</filename> variable applies
-                    to packages being built, you should
-                    always attach a package name to the variable to specify the
-                    particular run-time package that has the dependency.
+                    to packages being built, you should always use the variable
+                    in a form with an attached package name.
                     For example, suppose you are building a development package
                     that depends on the <filename>perl</filename> package.
                     In this case, you would use the following
@@ -3055,17 +3073,25 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     <literallayout class='monospaced'>
      RDEPENDS_${PN}-dev += "perl"
                     </literallayout>
-                    In the example, the package name
-                    (<filename>${PN}-dev</filename>) must appear as it would
-                    in the
-                    <filename><link linkend='var-PACKAGES'>PACKAGES</link></filename>
+                    In the example, the development package depends on
+                    the <filename>perl</filename> package.
+                    Thus, the <filename>RDEPENDS</filename> variable has the
+                    <filename>${PN}-dev</filename> package name as part of the
+                    variable.
+                </para>
+
+                <para>
+                    The package name you attach to the
+                    <filename>RDEPENDS</filename> variable must appear
+                    as it would in the <filename>PACKAGES</filename>
                     namespace before any renaming of the output package by
                     classes like <filename>debian.bbclass</filename>.
                 </para>
 
                 <para>
-                    In many cases you do not need to explicitly add dependencies
-                    to <filename>RDEPENDS</filename> since some automatic
+                    In many cases you do not need to explicitly add
+                    run-time dependencies using
+                    <filename>RDEPENDS</filename> since some automatic
                     handling occurs:
                     <itemizedlist>
                         <listitem><para><emphasis><filename>shlibdeps</filename></emphasis>:  If
@@ -3090,8 +3116,8 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
         <glossentry id='var-RM_WORK_EXCLUDE'><glossterm>RM_WORK_EXCLUDE</glossterm>
             <glossdef>
                 <para>
-                    With <filename>rm_work</filename> enabled, this 
-                    variable specifies a list of packages whose work directories 
+                    With <filename>rm_work</filename> enabled, this
+                    variable specifies a list of recipes whose work directories
                     should not be removed.
                     See the "<link linkend='ref-classes-rm-work'>Removing Work Files During the Build - <filename>rm_work.bbclass</filename></link>"
                     section for more details.
@@ -3102,9 +3128,9 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
         <glossentry id='var-RPROVIDES'><glossterm>RPROVIDES</glossterm>
             <glossdef>
                 <para>
-                    A list of package name aliases that a package also provides. 
-                    These aliases are useful for satisfying runtime dependencies 
-                    of other packages both during the build and on the target 
+                    A list of package name aliases that a package also provides.
+                    These aliases are useful for satisfying runtime dependencies
+                    of other packages both during the build and on the target
                     (as specified by
                     <filename><link linkend='var-RDEPENDS'>RDEPENDS</link></filename>).
                     <note>
@@ -3113,7 +3139,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     </note>
                 </para>
                 <para>
-                   As with all package-controlling variables, you must always 
+                   As with all package-controlling variables, you must always
                    use the variable in conjunction with a package name override.
                    Here is an example:
                    <literallayout class='monospaced'>
@@ -3163,18 +3189,18 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
         <glossentry id='var-RREPLACES'><glossterm>RREPLACES</glossterm>
             <glossdef>
                 <para>
-                    A list of packages replaced by a package. 
-                    The package manager uses this variable to determine which 
-                    package should be installed to replace other package(s) 
+                    A list of packages replaced by a package.
+                    The package manager uses this variable to determine which
+                    package should be installed to replace other package(s)
                     during an upgrade.
-                    In order to also have the other package(s) removed at the 
-                    same time, you must add the name of the other 
+                    In order to also have the other package(s) removed at the
+                    same time, you must add the name of the other
                     package to the
                     <filename><link linkend='var-RCONFLICTS'>RCONFLICTS</link></filename> variable.
                 </para>
                 <para>
                    As with all package-controlling variables, you must use
-                   this variable in conjunction with a package name 
+                   this variable in conjunction with a package name
                    override.
                    Here is an example:
                    <literallayout class='monospaced'>
@@ -3187,14 +3213,14 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
         <glossentry id='var-RSUGGESTS'><glossterm>RSUGGESTS</glossterm>
             <glossdef>
                 <para>
-                    A list of additional packages that you can suggest for 
-                    installation by the package manager at the time a package 
+                    A list of additional packages that you can suggest for
+                    installation by the package manager at the time a package
                     is installed.
                     Not all package managers support this functionality.
                 </para>
                 <para>
                    As with all package-controlling variables, you must always
-                   use this variable in conjunction with a package name 
+                   use this variable in conjunction with a package name
                    override.
                    Here is an example:
                    <literallayout class='monospaced'>
@@ -3239,19 +3265,19 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
         <glossentry id='var-SANITY_TESTED_DISTROS'><glossterm>SANITY_TESTED_DISTROS</glossterm>
             <glossdef>
                 <para>
-                    A list of the host distribution identifiers that the 
+                    A list of the host distribution identifiers that the
                     build system has been tested against.
                     Identifiers consist of the host distributor ID
-                    followed by the release, 
+                    followed by the release,
                     as reported by the <filename>lsb_release</filename> tool
-                    or as read from <filename>/etc/lsb-release</filename>. 
-                    Separate the list items with explicit newline 
+                    or as read from <filename>/etc/lsb-release</filename>.
+                    Separate the list items with explicit newline
                     characters (<filename>\n</filename>).
-                    If <filename>SANITY_TESTED_DISTROS</filename> is not empty 
-                    and the current value of 
+                    If <filename>SANITY_TESTED_DISTROS</filename> is not empty
+                    and the current value of
                     <link linkend='var-NATIVELSBSTRING'><filename>NATIVELSBSTRING</filename></link>
-                    does not appear in the list, then the build system reports        
-                    a warning that indicates the current host distribution has 
+                    does not appear in the list, then the build system reports
+                    a warning that indicates the current host distribution has
                     not been tested as a build host.
                 </para>
             </glossdef>
@@ -3302,17 +3328,17 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
         <glossentry id='var-SIGGEN_EXCLUDERECIPES_ABISAFE'><glossterm>SIGGEN_EXCLUDERECIPES_ABISAFE</glossterm>
             <glossdef>
                 <para>
-                    A list of recipes that are completely stable and will 
+                    A list of recipes that are completely stable and will
                     never change.
                     The ABI for the recipes in the list are presented by
                     output from the tasks run to build the recipe.
-                    Use of this variable is one way to remove dependencies from 
+                    Use of this variable is one way to remove dependencies from
                     one recipe on another that affect task signatures and
-                    thus force rebuilds when the recipe changes. 
+                    thus force rebuilds when the recipe changes.
                     <caution>
                         If you add an inappropriate variable to this list,
-                        the software might break at runtime if the 
-                        interface of the recipe was changed after the other 
+                        the software might break at runtime if the
+                        interface of the recipe was changed after the other
                         had been built.
                     </caution>
                 </para>
@@ -3322,25 +3348,25 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
         <glossentry id='var-SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS'><glossterm>SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS</glossterm>
             <glossdef>
                 <para>
-                    A list of recipe dependencies that should not be used to 
+                    A list of recipe dependencies that should not be used to
                     determine signatures of tasks from one recipe when they
-                    depend on tasks from another recipe. 
+                    depend on tasks from another recipe.
                     For example:
                     <literallayout class='monospaced'>
     SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS += "intone->mplayer2"
                     </literallayout>
-                    In this example, <filename>intone</filename> depends on 
+                    In this example, <filename>intone</filename> depends on
                     <filename>mplayer2</filename>.
                 </para>
 
                 <para>
-                    Use of this variable is one mechanism to remove dependencies 
-                    that affect task signatures and thus force rebuilds when a 
-                    recipe changes. 
+                    Use of this variable is one mechanism to remove dependencies
+                    that affect task signatures and thus force rebuilds when a
+                    recipe changes.
                     <caution>
                         If you add an inappropriate dependency for a recipe
-                        relationship, the software might break during 
-                        runtime if the interface of the second recipe was 
+                        relationship, the software might break during
+                        runtime if the interface of the second recipe was
                         changed after the first recipe had been built.
                     </caution>
                 </para>
@@ -3369,12 +3395,12 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
             <glossdef>
                 <para>
                     Groups together machines based upon the same family
-                    of SOC (System On Chip). 
+                    of SOC (System On Chip).
                     You typically set this variable in a common
-                    <filename>.inc</filename> file that you include in the 
-                    configuration files of all the machines. 
+                    <filename>.inc</filename> file that you include in the
+                    configuration files of all the machines.
                     <note>
-                        You must include 
+                        You must include
                         <filename>conf/machine/include/soc-family.inc</filename>
                         for this variable to appear in
                     <link linkend='var-MACHINEOVERRIDES'><filename>MACHINEOVERRIDES</filename></link>.
@@ -3397,56 +3423,56 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
         <glossentry id='var-SRC_URI'><glossterm>SRC_URI</glossterm>
             <glossdef>
                 <para>The list of source files - local or remote.
-                    This variable tells the OpenEmbedded build system which bits 
+                    This variable tells the OpenEmbedded build system which bits
                     to pull in for the build and how to pull them in.
-                    For example, if the recipe or append file only needs to 
-                    fetch a tarball from the Internet, the recipe or 
-                    append file uses a single <filename>SRC_URI</filename> 
+                    For example, if the recipe or append file only needs to
+                    fetch a tarball from the Internet, the recipe or
+                    append file uses a single <filename>SRC_URI</filename>
                     entry.
-                    On the other hand, if the recipe or append file needs to 
-                    fetch a tarball, apply two patches, and include a custom 
+                    On the other hand, if the recipe or append file needs to
+                    fetch a tarball, apply two patches, and include a custom
                     file, the recipe or append file would include four
                     instances of the variable.</para>
                 <para>The following list explains the available URI protocols:
                     <itemizedlist>
                         <listitem><para><emphasis><filename>file://</filename> -</emphasis>
-                            Fetches files, which are usually files shipped with 
+                            Fetches files, which are usually files shipped with
                             the
                             <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>,
                             from the local machine.
                             The path is relative to the
                             <link linkend='var-FILESPATH'><filename>FILESPATH</filename></link>
                             variable.
-                            Thus, the build system searches, in order, from the 
-                            following directories, which are assumed to be a 
+                            Thus, the build system searches, in order, from the
+                            following directories, which are assumed to be a
                             subdirectories of the directory in which the
-                            recipe file (<filename>.bb</filename>) or 
-                            append file (<filename>.bbappend</filename>) 
+                            recipe file (<filename>.bb</filename>) or
+                            append file (<filename>.bbappend</filename>)
                             resides:
                             <itemizedlist>
                                 <listitem><para><emphasis><filename>${BPN}</filename> -</emphasis>
-                                    The base recipe name without any special 
+                                    The base recipe name without any special
                                     suffix or version numbers.
                                     </para></listitem>
                                 <listitem><para><emphasis><filename>${BP}</filename> -</emphasis>
                                     <filename>${<link linkend='var-BPN'>BPN</link>}-${PV}</filename>.
-                                    The base recipe name and version but without 
+                                    The base recipe name and version but without
                                     any special package name suffix.
                                     </para></listitem>
-                                <listitem><para><emphasis>files -</emphasis> 
-                                    Files within a directory, which is named 
-                                    <filename>files</filename> and is also 
+                                <listitem><para><emphasis>files -</emphasis>
+                                    Files within a directory, which is named
+                                    <filename>files</filename> and is also
                                     alongside the recipe or append file.
                                     </para></listitem>
                             </itemizedlist>
                             <note>
-                                If you want the build system to pick up files 
-                                specified through a 
+                                If you want the build system to pick up files
+                                specified through a
                                 <filename>SRC_URI</filename>
                                 statement from your append file, you need to be
-                                sure to extend the 
+                                sure to extend the
                                 <filename>FILESPATH</filename>
-                                variable by also using the 
+                                variable by also using the
                                 <link linkend='var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></link>
                                 variable from within your append file.
                             </note>
@@ -3691,9 +3717,9 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
         <glossentry id='var-STAMPS_DIR'><glossterm>STAMPS_DIR</glossterm>
             <glossdef>
                 <para>
-                    Specifies the base directory in which the OpenEmbedded 
+                    Specifies the base directory in which the OpenEmbedded
                     build system places stamps.
-                    The default directory is 
+                    The default directory is
                     <filename>${TMPDIR}/stamps</filename>.
                 </para>
             </glossdef>
@@ -3715,10 +3741,10 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
         <glossentry id='var-SYSROOT_PREPROCESS_FUNCS'><glossterm>SYSROOT_PREPROCESS_FUNCS</glossterm>
             <glossdef>
                 <para>
-                    A list of functions to execute after files are staged into 
+                    A list of functions to execute after files are staged into
                     the sysroot.
-                    These functions are usually used to apply additional 
-                    processing on the staged files, or to stage additional 
+                    These functions are usually used to apply additional
+                    processing on the staged files, or to stage additional
                     files.
                 </para>
             </glossdef>
@@ -3730,15 +3756,15 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
 
         <glossentry id='var-T'><glossterm>T</glossterm>
             <glossdef>
-                <para>This variable points to a directory were BitBake places 
-                    temporary files, which consist mostly of task logs and 
-                    scripts, when building a particular recipe. 
+                <para>This variable points to a directory were BitBake places
+                    temporary files, which consist mostly of task logs and
+                    scripts, when building a particular recipe.
                     The variable is typically set as follows:
                     <literallayout class='monospaced'>
      T = "${WORKDIR}/temp"
                     </literallayout>
                     The <link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>
-                    is the directory into which BitBake unpacks and builds the 
+                    is the directory into which BitBake unpacks and builds the
                     recipe.
                     The default <filename>bitbake.conf</filename> file sets this variable.</para>
                     <para>The <filename>T</filename> variable is not to be confused with
@@ -3839,6 +3865,16 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-THISDIR'><glossterm>THISDIR</glossterm>
+            <glossdef>
+                <para>
+                    The directory in which the file BitBake is currently
+                    parsing is located.
+                    Do not manually set this variable.
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-TMPDIR'><glossterm>TMPDIR</glossterm>
             <glossdef>
                 <para>

documentation/ref-manual/technical-details.xml

@@ -641,7 +641,7 @@
         <title>Stabilizing and Completing x32</title>
 
         <para>
-            As of this Yocto Project release, the x32 psABI kernel and library 
+            As of this Yocto Project release, the x32 psABI kernel and library
             interfaces specifications are not finalized.
         </para>
 
@@ -686,6 +686,136 @@
     </section>
 </section>
 
+<section id="wayland">
+    <title>Wayland</title>
+
+    <para>
+        <ulink url='http://en.wikipedia.org/wiki/Wayland_(display_server_protocol)#Weston'>Wayland</ulink>
+        is a computer display server protocol that when implemented
+        provides a method for compositing window managers to communicate
+        directly with applications and video hardware and expects them to
+        communicate with input hardware using other libraries.
+        Using Wayland with supporting targets can result in better control
+        over graphics frame rendering than an application might otherwise
+        achieve.
+    </para>
+
+    <para>
+        The Yocto Project provides the Wayland protocol libraries and the
+        reference Weston compositor as part of it release.
+        This section describes what you need to do to implement Wayland and
+        use the compositor when building an image for a supporting target.
+    </para>
+
+    <section id="wayland-support">
+        <title>Support</title>
+
+        <para>
+            The Wayland protocol libraries and the reference Weston compositor
+            ship as integrated packages in the <filename>meta</filename> layer
+            of the
+            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+            Specifically, you can find the recipes that build both Wayland
+            and Weston at <filename>meta/recipes-graphics/wayland</filename>.
+        </para>
+
+        <para>
+            You can build both the Wayland and Weston packages for use only
+            with targets that accept the
+            <ulink url='http://dri.freedesktop.org/wiki/'>Mesa 3D and Direct Rendering Infrastructure</ulink>,
+            which is also known as Mesa DRI.
+            This implies that you cannot build and use the packages if your
+            target uses, for example, the
+            <trademark class='registered'>Intel</trademark> Embedded Media and
+            Graphics Driver (<trademark class='registered'>Intel</trademark>
+            EMGD) that overrides Mesa DRI.
+        </para>
+
+        <note>
+            Due to lack of EGL support, Weston 1.0.3 will not run directly on
+            the emulated QEMU hardware.
+            However, this version of Weston will run under X emulation without
+            issues.
+        </note>
+    </section>
+
+    <section id="enabling-wayland-in-an-image">
+        <title>Enabling Wayland in an Image</title>
+
+        <para>
+            To enable Wayland, you need to enable it to be built and enable
+            it to be included in the image.
+        </para>
+
+        <section id="enable-building">
+            <title>Building</title>
+
+            <para>
+                To cause Mesa to build the <filename>wayland-egl</filename>
+                platform and Weston to build Wayland with Kernel Mode
+                Setting
+                (<ulink url='https://wiki.archlinux.org/index.php/Kernel_Mode_Setting'>KMS</ulink>)
+                support, include the "wayland" flag in the
+                <link linkend="var-DISTRO_FEATURES"><filename>DISTRO_FEATURES</filename></link>
+                statement in your <filename>local.conf</filename> file:
+                <literallayout class='monospaced'>
+     DISTRO_FEATURES_append = " wayland"
+                </literallayout>
+            </para>
+
+            <note>
+                If X11 has been enabled elsewhere, Weston will build Wayland
+                with X11 support
+            </note>
+        </section>
+
+        <section id="enable-installation-in-an-image">
+            <title>Installing</title>
+
+            <para>
+                To install the Wayland feature into an image, you must
+                include the following
+                <link linkend='var-CORE_IMAGE_EXTRA_INSTALL'><filename>CORE_IMAGE_EXTRA_INSTALL</filename></link>
+                statement in your <filename>local.conf</filename> file:
+                <literallayout class='monospaced'>
+     CORE_IMAGE_EXTRA_INSTALL += "wayland weston"
+                </literallayout>
+            </para>
+        </section>
+    </section>
+
+    <section id="running-weston">
+        <title>Running Weston</title>
+
+        <para>
+            To run Weston inside X11, enabling it as described earlier and
+            building a Sato image is sufficient.
+            If you are running your image under Sato, a Weston Launcher appears
+            in the "Utility" category.
+        </para>
+
+        <para>
+            Alternatively, you can run Weston through the command-line
+            interpretor (CLI), which is better suited for development work.
+            To run Weston under the CLI you need to do the following after
+            your image is built:
+            <orderedlist>
+                <listitem><para>Run these commands to export
+                    <filename>XDG_RUNTIME_DIR</filename>:
+                    <literallayout class='monospaced'>
+     mkdir -p /tmp/$USER-weston
+     chmod 0700 /tmp/$USER-weston
+     export XDG_RUNTIME_DIR=/tmp/$USER=weston
+                    </literallayout></para></listitem>
+                <listitem><para>Launch Weston in the shell:
+                    <literallayout class='monospaced'>
+     weston
+                    </literallayout></para></listitem>
+            </orderedlist>
+        </para>
+    </section>
+</section>
+
 <section id="licenses">
     <title>Licenses</title>
 

documentation/ref-manual/usingpoky.xml

@@ -117,11 +117,11 @@
     </para>
 
     <para>
-        For discussions on debugging, see the 
+        For discussions on debugging, see the
         "<ulink url='&YOCTO_DOCS_DEV_URL;#platdev-gdb-remotedebug'>Debugging With the GNU Project Debugger (GDB) Remotely</ulink>"
-        and 
+        and
         "<ulink url='&YOCTO_DOCS_DEV_URL;#adt-eclipse'>Working within Eclipse</ulink>"
-        sections in the Yocto Project Development Manual. 
+        sections in the Yocto Project Development Manual.
     </para>
 
     <section id='usingpoky-debugging-taskfailures'>
@@ -156,7 +156,7 @@
             Some tasks exist, such as <filename>devshell</filename>, that are not part of the
             default build chain.
             If you wish to run a task that is not part of the default build chain, you can use the
-            <filename>-c</filename> option in BitBake. 
+            <filename>-c</filename> option in BitBake.
             Here is an example:
             <literallayout class='monospaced'>
      $ bitbake matchbox-desktop -c devshell
@@ -180,7 +180,7 @@
         </para>
 
         <para>
-            This sequence first builds and then recompiles 
+            This sequence first builds and then recompiles
             <filename>matchbox-desktop</filename>.
             The last command reruns all tasks (basically the packaging tasks) after the compile.
             BitBake recognizes that the <filename>compile</filename> task was rerun and therefore
@@ -240,7 +240,7 @@
             build to fail.
             Following are known, host-specific problems.
             Be sure to always consult the
-            <ulink url='&YOCTO_HOME_URL;/download/yocto/yocto-project-&DISTRO;-release-notes-poky-&POKYVERSION;'>Release Notes</ulink>
+            <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>:
@@ -278,9 +278,9 @@
     <section id='usingpoky-debugging-variables'>
         <title>Variables</title>
         <para>
-            You can use the <filename>-e</filename> BitBake option to 
-            display the resulting environment for a configuration 
-            when you do not specify a package or for a specific package when 
+            You can use the <filename>-e</filename> BitBake option to
+            display the resulting environment for a configuration
+            when you do not specify a package or for a specific package when
             you do specify the package.
             If you want to show the environment resulting from parsing a single
             recipe, use the <filename>-b recipename</filename> form.
@@ -395,7 +395,7 @@
                 <listitem><para>If you want to remove the <filename>psplash</filename>
                     boot splashscreen,
                     add <filename>psplash=false</filename> to  the kernel command line.
-                    Doing so prevents <filename>psplash</filename> from loading 
+                    Doing so prevents <filename>psplash</filename> from loading
                     and thus allows you to see the console.
                     It is also possible to switch out of the splashscreen by
                     switching the virtual console (e.g. Fn+Left or Fn+Right on a Zaurus).
@@ -505,7 +505,7 @@
 
         <para>At the top level, there is a <filename>metadata-revs</filename> file
             that lists the revisions of the repositories for the layers enabled
-            when the build was produced. 
+            when the build was produced.
             The rest of the data splits into separate
             <filename>packages</filename>, <filename>images</filename> and
             <filename>sdk</filename> directories, the contents of which are
@@ -560,11 +560,11 @@
                 system (e.g., Git), a file exists that lists source revisions
                 that are specified in the recipe and lists the actual revisions
                 used during the build.
-                Listed and actual revisions might differ when 
+                Listed and actual revisions might differ when
                 <link linkend='var-SRCREV'><filename>SRCREV</filename></link>
-                is set to 
-                <filename>${<link linkend='var-AUTOREV'>AUTOREV</link>}</filename>. 
-                Here is an example assuming 
+                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>):
                 <literallayout class='monospaced'>
      # SRCREV_machine = "b5c37fe6e24eec194bb29d22fdd55d73bcc709bf"
@@ -578,7 +578,7 @@
                 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 
+                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'>
@@ -592,14 +592,14 @@
      SRCREV_pn-opkg = "649"
                 </literallayout>
                 <note>
-                    Here are some notes on using the 
+                    Here are some notes on using the
                     <filename>buildhistory-collect-srcrevs</filename> command:
                     <itemizedlist>
-                        <listitem><para>By default, only values where the 
+                        <listitem><para>By default, only values where the
                             <filename>SRCREV</filename> was
                             not hardcoded (usually when <filename>AUTOREV</filename>
                             was used) are reported.
-                            Use the <filename>-a</filename> option to see all 
+                            Use the <filename>-a</filename> option to see all
                             <filename>SRCREV</filename> values.
                             </para></listitem>
                         <listitem><para>The output statements might not have any effect
@@ -726,13 +726,13 @@
                         See the following listing example for more information.
                         </para></listitem>
                     <listitem><para>The following information appears under
-                        each of the <filename>host</filename> 
-                        and <filename>target</filename> directories 
-                        for the portions of the SDK that run on the host and 
+                        each of the <filename>host</filename>
+                        and <filename>target</filename> directories
+                        for the portions of the SDK that run on the host and
                         on the target, respectively:
                         <itemizedlist>
                             <listitem><para><filename>depends.dot:</filename>
-                                Dependency graph for the SDK that is 
+                                Dependency graph for the SDK that is
                                 compatible with <filename>graphviz</filename>.
                                 </para></listitem>
                             <listitem><para><filename>installed-package-names.txt:</filename>
@@ -756,17 +756,17 @@
      DISTRO_VERSION = 1.3+snapshot-20130327
      SDK_NAME = poky-eglibc-i686-arm
      SDK_VERSION = 1.3+snapshot
-     SDKMACHINE = 
+     SDKMACHINE =
      SDKIMAGE_FEATURES = dev-pkgs dbg-pkgs
-     BAD_RECOMMENDATIONS = 
+     BAD_RECOMMENDATIONS =
      SDKSIZE = 352712
                 </literallayout>
                 Other than <filename>SDKSIZE</filename>, which is the
                 total size of the files in the SDK in Kbytes, the
                 name-value pairs are variables that might have influenced the
                 content of the SDK.
-                This information is often useful when you are trying to 
-                determine why a change in the package or file listings 
+                This information is often useful when you are trying to
+                determine why a change in the package or file listings
                 has occurred.
             </para>
         </section>

documentation/tools/mega-manual.sed

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

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

@@ -308,9 +308,9 @@
         <para>
             You can download the latest Yocto Project release by going to the
             <ulink url="&YOCTO_HOME_URL;">Yocto Project website</ulink>
-            clicking "Downloads" in the navigation pane to the left to view all 
+            clicking "Downloads" in the navigation pane to the left to view all
             available Yocto Project releases.
-            Be sure to scroll down and look for "Yocto Project" under the 
+            Be sure to scroll down and look for "Yocto Project" under the
             "Type" heading in the list.
             Nightly and developmental builds are also maintained at
             <ulink url="&YOCTO_AB_NIGHTLY_URL;"></ulink>.
@@ -395,7 +395,7 @@
          <tip><para>
              To help conserve disk space during builds, you can add the following statement
              to your project's configuration file, which for this example
-             is <filename>&YOCTO_POKY;-build/conf/local.conf</filename>.
+             is <filename>&YOCTO_POKY;/build/conf/local.conf</filename>.
              Adding this statement deletes the work directory used for building a package
              once the package is built.
              <literallayout class='monospaced'>
@@ -663,7 +663,7 @@
                 x86, x86-64, ppc, mips, or arm.
                 </literallayout>
                 <note>
-                    For the <filename>qemu</filename> architecture, 
+                    For the <filename>qemu</filename> architecture,
                     <filename>ext3</filename> and <filename>tar</filename>
                     files start with the "lib32" string.
                 </note>

meta-yocto-bsp/recipes-graphics/xorg-xserver/xserver-xf86-config/beagleboard/xorg.conf

@@ -30,5 +30,4 @@ EndSection
 
 Section "ServerFlags"
 	Option		"DontZap"  "0"
-        Option		"AutoAddDevices" "False"
 EndSection

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

@@ -3,10 +3,10 @@ KBRANCH_routerstationpro = "standard/default/routerstationpro"
 KBRANCH_mpc8315e-rdb = "standard/default/fsl-mpc8315e-rdb"
 KBRANCH_beagleboard = "standard/default/beagleboard"
 
-SRCREV_machine_atom-pc ?= "41074a778d251a77e036fd8a99915cd4da6cd8f7"
-SRCREV_machine_routerstationpro ?= "94abc0d75d0a99c40c53402570cd9c569539fee9"
-SRCREV_machine_mpc8315e-rdb ?= "a04e94f4dae9cf6d32d059cf9e0308abe7341a3a"
-SRCREV_machine_beagleboard ?= "40bde7a43ef3cd85729ab02464a7ecdf71e522a6"
+SRCREV_machine_atom-pc ?= "4e22c5593a355ab6f21f29895b68ee432df49f22"
+SRCREV_machine_routerstationpro ?= "06264be5913f2984aad07fe31a27fd8ef8e15782"
+SRCREV_machine_mpc8315e-rdb ?= "f906a896696d98c1e651bcef17631f1096cd6c31"
+SRCREV_machine_beagleboard ?= "cdc1e64b1cec2f93a1ea656e358b8bb8d2926954"
 
 COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb"
 COMPATIBLE_MACHINE_routerstationpro = "routerstationpro"

meta-yocto/conf/distro/poky-lsb.conf

@@ -6,4 +6,7 @@ DISTROOVERRIDES = "poky:linuxstdbase"
 DISTRO_FEATURES_append = " pam largefile opengl"
 PREFERRED_PROVIDER_virtual/libx11 = "libx11"
 
+# Ensure the kernel nfs server is enabled
+KERNEL_FEATURES_append_pn-linux-yocto = " features/nfsd/nfsd-enable.scc"
+
 

meta-yocto/conf/distro/poky.conf

@@ -1,6 +1,6 @@
 DISTRO = "poky"
-DISTRO_NAME = "Poky 9.0 (Yocto Project 1.4 Reference Distro)"
-DISTRO_VERSION = "1.4"
+DISTRO_NAME = "Poky 9.0.4 (Yocto Project 1.4.4 Reference Distro)"
+DISTRO_VERSION = "1.4.4"
 DISTRO_CODENAME = "dylan"
 SDK_VENDOR = "-pokysdk"
 SDK_VERSION := "${@'${DISTRO_VERSION}'}"
@@ -75,6 +75,10 @@ SANITY_TESTED_DISTROS ?= " \
             Poky-1.2 \n \
             Poky-1.3 \n \
             Poky-1.4 \n \
+            Poky-1.4.1 \n \
+            Poky-1.4.2 \n \
+            Poky-1.4.3 \n \
+            Poky-1.4.4 \n \
             Ubuntu-10.04 \n \
             Ubuntu-11.10 \n \
             Ubuntu-12.04 \n \

meta/classes/archive-configured-source.bbclass

@@ -34,7 +34,10 @@ python () {
         d.appendVarFlag('do_compile', 'depends', ' %s:do_archive_configured_sources' %pn)
         build_deps += ' %s:do_archive_configured_sources' %pn
 
-    d.appendVarFlag('do_build', 'depends', build_deps)
+    if bb.data.inherits_class('image', d):
+        d.appendVarFlag('do_rootfs', 'depends', build_deps)
+    else:
+        d.appendVarFlag('do_build', 'depends', build_deps)
 }
 
 ARCHIVE_SSTATE_OUTDIR = "${DEPLOY_DIR}/sources/"

meta/classes/archive-original-source.bbclass

@@ -34,7 +34,10 @@ python () {
         d.appendVarFlag('do_patch', 'depends', ' %s:do_archive_original_sources_patches' %pn)
         build_deps += ' %s:do_archive_original_sources_patches' %pn
 
-    d.appendVarFlag('do_build', 'depends', build_deps)
+    if bb.data.inherits_class('image', d):
+        d.appendVarFlag('do_rootfs', 'depends', build_deps)
+    else:
+        d.appendVarFlag('do_build', 'depends', build_deps)
 }
 
 ARCHIVE_SSTATE_OUTDIR = "${DEPLOY_DIR}/sources/"

meta/classes/archive-patched-source.bbclass

@@ -34,7 +34,10 @@ python () {
         d.appendVarFlag('do_configure', 'depends', ' %s:do_archive_patched_sources' %pn)
         build_deps += ' %s:do_archive_patched_sources' %pn
 
-    d.appendVarFlag('do_build', 'depends', build_deps)
+    if bb.data.inherits_class('image', d):
+        d.appendVarFlag('do_rootfs', 'depends', build_deps)
+    else:
+        d.appendVarFlag('do_build', 'depends', build_deps)
 }
 
 ARCHIVE_SSTATE_OUTDIR = "${DEPLOY_DIR}/sources/"

meta/classes/archiver.bbclass

@@ -63,7 +63,10 @@ def copyleft_should_include(d):
         bb.fatal('%s: %s' % (d.getVar('PF', True), exc))
     else:
         if is_included:
-            return True, 'recipe has included licenses: %s' % ', '.join(reason)
+            if reason:
+                return True, 'recipe has included licenses: %s' % ', '.join(reason)
+            else:
+                return False, 'recipe does not include a copyleft license'
         else:
             return False, 'recipe has excluded licenses: %s' % ', '.join(reason)
 

meta/classes/autotools.bbclass

@@ -127,6 +127,26 @@ EXTRACONFFUNCS ??= ""
 do_configure[prefuncs] += "autotools_preconfigure ${EXTRACONFFUNCS}"
 do_configure[postfuncs] += "autotools_postconfigure"
 
+ACLOCALDIR = "${B}/aclocal-copy"
+
+autotools_copy_aclocal () {
+	# Remove any previous copy of the m4 macros
+	rm -rf ${ACLOCALDIR}/
+
+	# The aclocal directory could get modified by other processes
+	# uninstalling data from the sysroot. See Yocto #861 for details.
+	# We avoid this by taking a copy here and then files cannot disappear.
+	# We copy native first, then target. This avoids certain races since cp-noerror
+	# won't overwrite existing files.
+	mkdir -p ${ACLOCALDIR}/
+	if [ -d ${STAGING_DATADIR_NATIVE}/aclocal ]; then
+		cp-noerror ${STAGING_DATADIR_NATIVE}/aclocal/ ${ACLOCALDIR}/
+	fi
+	if [ -d ${STAGING_DATADIR}/aclocal -a "${STAGING_DATADIR_NATIVE}/aclocal" != "${STAGING_DATADIR}/aclocal" ]; then
+		cp-noerror ${STAGING_DATADIR}/aclocal/ ${ACLOCALDIR}/
+	fi
+}
+
 autotools_do_configure() {
 	# WARNING: gross hack follows:
 	# An autotools built package generally needs these scripts, however only
@@ -142,9 +162,8 @@ autotools_do_configure() {
 	if [ -e ${S}/configure.in -o -e ${S}/configure.ac ]; then
 		olddir=`pwd`
 		cd ${S}
-		# Remove any previous copy of the m4 macros
-		rm -rf ${B}/aclocal-copy/
-		ACLOCAL="aclocal --system-acdir=${B}/aclocal-copy/"
+		autotools_copy_aclocal
+		ACLOCAL="aclocal --system-acdir=${ACLOCALDIR}/"
 		if [ x"${acpaths}" = xdefault ]; then
 			acpaths=
 			for i in `find ${S} -maxdepth 2 -name \*.m4|grep -v 'aclocal.m4'| \
@@ -160,18 +179,6 @@ autotools_do_configure() {
 		if [ -d ${STAGING_DATADIR_NATIVE}/aclocal-$AUTOV ]; then
 			ACLOCAL="$ACLOCAL --automake-acdir=${STAGING_DATADIR_NATIVE}/aclocal-$AUTOV"
 		fi
-		# The aclocal directory could get modified by other processes 
-		# uninstalling data from the sysroot. See Yocto #861 for details.
-		# We avoid this by taking a copy here and then files cannot disappear.
-		# We copy native first, then target. This avoids certain races since cp-noerror
-		# won't overwrite existing files.
-		mkdir -p ${B}/aclocal-copy/
-		if [ -d ${STAGING_DATADIR_NATIVE}/aclocal ]; then
-			cp-noerror ${STAGING_DATADIR_NATIVE}/aclocal/ ${B}/aclocal-copy/
-		fi
-		if [ -d ${STAGING_DATADIR}/aclocal -a "${STAGING_DATADIR_NATIVE}/aclocal" != "${STAGING_DATADIR}/aclocal" ]; then
-			cp-noerror ${STAGING_DATADIR}/aclocal/ ${B}/aclocal-copy/
-		fi
 		# autoreconf is too shy to overwrite aclocal.m4 if it doesn't look
 		# like it was auto-generated.  Work around this by blowing it away
 		# by hand, unless the package specifically asked not to run aclocal.

meta/classes/base.bbclass

@@ -308,13 +308,15 @@ python base_eventhandler() {
         oe.utils.features_backfill("MACHINE_FEATURES", e.data)
 
     if isinstance(e, bb.event.BuildStarted):
+        localdata = bb.data.createCopy(e.data)
+        bb.data.update_data(localdata)
         statuslines = []
-        for func in oe.data.typed_value('BUILDCFG_FUNCS', e.data):
+        for func in oe.data.typed_value('BUILDCFG_FUNCS', localdata):
             g = globals()
             if func not in g:
                 bb.warn("Build configuration function '%s' does not exist" % func)
             else:
-                flines = g[func](e.data)
+                flines = g[func](localdata)
                 if flines:
                     statuslines.extend(flines)
 

meta/classes/bootimg.bbclass

@@ -20,6 +20,7 @@
 # External variables (also used by syslinux.bbclass)
 # ${INITRD} - indicates a filesystem image to use as an initrd (optional)
 # ${NOISO}  - skip building the ISO image if set to 1
+# ${NOHDD}  - skip building the HDD image if set to 1
 # ${ROOTFS} - indicates a filesystem image to include as the root filesystem (optional)
 
 do_bootimg[depends] += "dosfstools-native:do_populate_sysroot \

meta/classes/buildhistory.bbclass

@@ -500,7 +500,7 @@ END
 		repostatus=`git status --porcelain | grep -v " metadata-revs$"`
 		HOSTNAME=`hostname 2>/dev/null || echo unknown`
 		if [ "$repostatus" != "" ] ; then
-			git add .
+			git add -A .
 			# porcelain output looks like "?? packages/foo/bar"
 			# Ensure we commit metadata-revs with the first commit
 			for entry in `echo "$repostatus" | awk '{print $2}' | awk -F/ '{print $1}' | sort | uniq` ; do

meta/classes/cmake.bbclass

@@ -35,7 +35,7 @@ cmake_do_generate_toolchain_file() {
 	cat > ${WORKDIR}/toolchain.cmake <<EOF
 # CMake system name must be something like "Linux".
 # This is important for cross-compiling.
-set( CMAKE_SYSTEM_NAME `echo ${SDK_OS} | sed 's/^./\u&/'` )
+set( CMAKE_SYSTEM_NAME `echo ${TARGET_OS} | sed -e 's/^./\u&/' -e 's/^\(Linux\).*/\1/'` )
 set( CMAKE_SYSTEM_PROCESSOR ${TARGET_ARCH} )
 set( CMAKE_C_COMPILER ${OECMAKE_C_COMPILER} )
 set( CMAKE_CXX_COMPILER ${OECMAKE_CXX_COMPILER} )

meta/classes/cpan.bbclass

@@ -26,7 +26,7 @@ cpan_do_configure () {
 			test -f $f2 || continue
 			sed -i -e "s:\(PERL_ARCHLIB = \).*:\1${PERL_ARCHLIB}:" \
 				-e 's/perl.real/perl/' \
-				-e "s/^\(CCFLAGS =.*\)/\1 ${CFLAGS}/" \
+				-e "s|^\(CCFLAGS =.*\)|\1 ${CFLAGS}|" \
 				$f2
 		done
 	fi

meta/classes/fontcache.bbclass

@@ -8,19 +8,13 @@ inherit qemu
 
 FONT_PACKAGES ??= "${PN}"
 
-#
-# On host, the postinstall MUST return 1 because we do not know if the intercept
-# hook will succeed. If it does succeed, than the packages will be marked as
-# installed.
-#
 fontcache_common() {
 if [ "x$D" != "x" ] ; then
-	$INTERCEPT_DIR/postinst_intercept update_font_cache ${PKG} bindir=${bindir} \
+	$INTERCEPT_DIR/postinst_intercept update_font_cache ${PKG} mlprefix=${MLPREFIX} bindir=${bindir} \
 		libdir=${libdir} base_libdir=${base_libdir}
-	exit 1
+else
+	fc-cache
 fi
-
-fc-cache
 }
 
 python populate_packages_append() {

meta/classes/gettext.bbclass

@@ -10,8 +10,8 @@ def gettext_dependencies(d):
 def gettext_oeconf(d):
     if oe.utils.inherits(d, 'native', 'cross'):
         return '--disable-nls'
-    # Remove the NLS bits if USE_NLS is no.
-    if d.getVar('USE_NLS', True) == 'no' and not oe.utils.inherits(d, 'nativesdk', 'cross-canadian'):
+    # Remove the NLS bits if USE_NLS is no or INHIBIT_DEFAULT_DEPS is set
+    if (d.getVar('USE_NLS', True) == 'no' or d.getVar('INHIBIT_DEFAULT_DEPS', True)) and not oe.utils.inherits(d, 'nativesdk', 'cross-canadian'):
         return '--disable-nls'
     return "--enable-nls"
 

meta/classes/gtk-icon-cache.bbclass

@@ -2,41 +2,34 @@ FILES_${PN} += "${datadir}/icons/hicolor"
 
 DEPENDS += "${@['hicolor-icon-theme', '']['${BPN}' == 'hicolor-icon-theme']} gtk-update-icon-cache-native"
 
-#
-# On host, the postinstall MUST return 1 because we do not know if the intercept
-# hook will succeed. If it does succeed, than the packages will be marked as
-# installed.
-#
 gtk_icon_cache_postinst() {
 if [ "x$D" != "x" ]; then
-    $INTERCEPT_DIR/postinst_intercept update_icon_cache ${PKG} libdir=${libdir} \
-        base_libdir=${base_libdir}
-    exit 1
+	$INTERCEPT_DIR/postinst_intercept update_icon_cache ${PKG} mlprefix=${MLPREFIX} libdir=${libdir} \
+		base_libdir=${base_libdir}
+else
+
+	# Update the pixbuf loaders in case they haven't been registered yet
+	GDK_PIXBUF_MODULEDIR=${libdir}/gdk-pixbuf-2.0/2.10.0/loaders gdk-pixbuf-query-loaders --update-cache
+
+	for icondir in /usr/share/icons/* ; do
+		if [ -d $icondir ] ; then
+			gtk-update-icon-cache -fqt  $icondir
+		fi
+	done
 fi
-
-# Update the pixbuf loaders in case they haven't been registered yet
-GDK_PIXBUF_MODULEDIR=${libdir}/gdk-pixbuf-2.0/2.10.0/loaders gdk-pixbuf-query-loaders --update-cache
-
-for icondir in /usr/share/icons/* ; do
-    if [ -d $icondir ] ; then
-        gtk-update-icon-cache -fqt  $icondir
-    fi
-done
 }
 
 gtk_icon_cache_postrm() {
 if [ "x$D" != "x" ]; then
-    $INTERCEPT_DIR/postinst_intercept update_icon_cache ${PKG} libdir=${libdir} \
-        base_libdir=${base_libdir}
-
-    exit 1
+	$INTERCEPT_DIR/postinst_intercept update_icon_cache ${PKG} mlprefix=${MLPREFIX} libdir=${libdir} \
+		base_libdir=${base_libdir}
+else
+	for icondir in /usr/share/icons/* ; do
+		if [ -d $icondir ] ; then
+			gtk-update-icon-cache -qt  $icondir
+		fi
+	done
 fi
-
-for icondir in /usr/share/icons/* ; do
-    if [ -d $icondir ] ; then
-        gtk-update-icon-cache -qt  $icondir
-    fi
-done
 }
 
 python populate_packages_append () {

meta/classes/image-mklibs.bbclass

@@ -40,6 +40,7 @@ mklibs_optimize_image_doit() {
 		--ldlib ${dynamic_loader} \
 		--libdir ${baselib} \
 		--sysroot ${PKG_CONFIG_SYSROOT_DIR} \
+		--gcc-options "--sysroot=${PKG_CONFIG_SYSROOT_DIR}" \
 		--root ${IMAGE_ROOTFS} \
 		--target `echo ${TARGET_PREFIX} | sed 's/-$//' ` \
 		-d ${WORKDIR}/mklibs/dest \

meta/classes/image.bbclass

@@ -187,21 +187,32 @@ run_intercept_scriptlets () {
 			[ "$script" = "*" ] && break
 			[ "$script" = "postinst_intercept" ] || [ ! -x "$script" ] && continue
 			echo "> Executing $script"
-			./$script || { echo "WARNING: intercept script \"$script\" failed, falling back to running postinstalls at first boot" && continue; };
+			./$script && continue
+			echo "WARNING: intercept script \"$script\" failed, falling back to running postinstalls at first boot"
 			#
-			# If we got here, than the intercept was successful. Next, we must
-			# mark the postinstalls as "installed". For rpm is a little bit
-			# different, we just have to delete the saved postinstalls from
+			# If we got here, than the intercept has failed. Next, we must
+			# mark the postinstalls as "unpacked". For rpm is a little bit
+			# different, we just have to save the package postinstalls in
 			# /etc/rpm-postinsts
 			#
 			pkgs="$(cat ./$script|grep "^##PKGS"|cut -d':' -f2)" || continue
 			case ${IMAGE_PKGTYPE} in
 				"rpm")
-					for pi in ${IMAGE_ROOTFS}${sysconfdir}/rpm-postinsts/*; do
-						pkg_name="$(cat $pi|sed -n -e "s/^.*postinst_intercept $script \([^ ]*\).*/\1/p")"
-						if [ -n "$pkg_name" -a -n "$(echo "$pkgs"|grep " $pkg_name ")" ]; then
-							rm $pi
-						fi
+					[ -d ${IMAGE_ROOTFS}${sysconfdir}/rpm-postinsts/ ] || mkdir ${IMAGE_ROOTFS}${sysconfdir}/rpm-postinsts/
+					v_expr=$(echo ${MULTILIB_GLOBAL_VARIANTS}|tr ' ' '|')
+					for p in $pkgs; do
+						# remove any multilib prefix from the package name (RPM 
+						# does not use it like this)
+						new_p=$(echo $p | sed -r "s/^($v_expr)-//")
+
+						# extract the postinstall scriptlet from rpm package and
+						# save it in /etc/rpm-postinsts
+						echo "  * postponing $new_p"
+						rpm -q --scripts --root=${IMAGE_ROOTFS} --dbpath=/var/lib/rpm $new_p |\
+						sed -n -e '/^postinstall scriptlet (using .*):$/,/^.* scriptlet (using .*):$/ {/.*/p}' |\
+						sed -e 's/postinstall scriptlet (using \(.*\)):$/#!\1/' -e '/^.* scriptlet (using .*):$/d'\
+							> ${IMAGE_ROOTFS}${sysconfdir}/rpm-postinsts/$new_p
+						chmod +x ${IMAGE_ROOTFS}${sysconfdir}/rpm-postinsts/$new_p
 					done
 					# move to the next intercept script
 					continue
@@ -216,7 +227,8 @@ run_intercept_scriptlets () {
 			# the next piece of code is run only for ipk/dpkg
 			sed_expr=""
 			for p in $pkgs; do
-				sed_expr="$sed_expr -e \"/^Package: ${p}$/,/^Status: install.* unpacked$/ {s/unpacked/installed/}\""
+				echo "  * postponing $p"
+				sed_expr="$sed_expr -e \"/^Package: ${p}$/,/^Status: install.* installed$/ {s/installed/unpacked/}\""
 			done
 			eval sed -i $sed_expr $status_file
 		done

meta/classes/image_types.bbclass

@@ -185,7 +185,7 @@ IMAGE_CMD_cpio () {
 	cd ${IMAGE_ROOTFS} && (find . | cpio -o -H newc >${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.cpio)
 }
 
-ELF_KERNEL ?= "${STAGING_DIR_HOST}/kernel/${KERNEL_IMAGETYPE}"
+ELF_KERNEL ?= "${STAGING_DIR_HOST}/usr/src/kernel/${KERNEL_IMAGETYPE}"
 ELF_APPEND ?= "ramdisk_size=32768 root=/dev/ram0 rw console="
 
 IMAGE_CMD_elf () {

meta/classes/kernel.bbclass

@@ -237,14 +237,6 @@ do_savedefconfig() {
 do_savedefconfig[nostamp] = "1"
 addtask savedefconfig after do_configure
 
-pkg_postinst_kernel-base () {
-	update-alternatives --install /${KERNEL_IMAGEDEST}/${KERNEL_IMAGETYPE} ${KERNEL_IMAGETYPE} ${KERNEL_IMAGETYPE}-${KERNEL_VERSION} ${KERNEL_PRIORITY} || true
-}
-
-pkg_postrm_kernel-base () {
-	update-alternatives --remove ${KERNEL_IMAGETYPE} ${KERNEL_IMAGETYPE}-${KERNEL_VERSION} || true
-}
-
 inherit cml1
 
 EXPORT_FUNCTIONS do_compile do_install do_configure
@@ -252,7 +244,7 @@ EXPORT_FUNCTIONS do_compile do_install do_configure
 # kernel-base becomes kernel-${KERNEL_VERSION}
 # kernel-image becomes kernel-image-${KERNEL_VERISON}
 PACKAGES = "kernel kernel-base kernel-vmlinux kernel-image kernel-dev kernel-modules"
-FILES = ""
+FILES_${PN} = ""
 FILES_kernel-base = "/lib/modules/${KERNEL_VERSION}/modules.order /lib/modules/${KERNEL_VERSION}/modules.builtin"
 FILES_kernel-image = "/boot/${KERNEL_IMAGETYPE}*"
 FILES_kernel-dev = "/boot/System.map* /boot/Module.symvers* /boot/config* ${KERNEL_SRC_PATH}"
@@ -272,14 +264,19 @@ ALLOW_EMPTY_kernel-modules = "1"
 DESCRIPTION_kernel-modules = "Kernel modules meta package"
 
 pkg_postinst_kernel-image () {
-if [ ! -e "$D/lib/modules/${KERNEL_VERSION}" ]; then
-	mkdir -p $D/lib/modules/${KERNEL_VERSION}
-fi
-if [ -n "$D" ]; then
-	depmodwrapper -a -b $D ${KERNEL_VERSION}
-else
-	depmod -a ${KERNEL_VERSION}
-fi
+	update-alternatives --install /${KERNEL_IMAGEDEST}/${KERNEL_IMAGETYPE} ${KERNEL_IMAGETYPE} ${KERNEL_IMAGETYPE}-${KERNEL_VERSION} ${KERNEL_PRIORITY} || true
+	if [ ! -e "$D/lib/modules/${KERNEL_VERSION}" ]; then
+		mkdir -p $D/lib/modules/${KERNEL_VERSION}
+	fi
+	if [ -n "$D" ]; then
+		depmodwrapper -a -b $D ${KERNEL_VERSION}
+	else
+		depmod -a ${KERNEL_VERSION}
+	fi
+}
+
+pkg_postrm_kernel-image () {
+	update-alternatives --remove ${KERNEL_IMAGETYPE} ${KERNEL_IMAGETYPE}-${KERNEL_VERSION} || true
 }
 
 PACKAGESPLITFUNCS_prepend = "split_kernel_packages "
@@ -375,7 +372,7 @@ kernel_do_deploy() {
 	if [ ${MODULE_TARBALL_DEPLOY} = "1" ] && (grep -q -i -e '^CONFIG_MODULES=y$' .config); then
 		mkdir -p ${D}/lib
 		tar -cvzf ${DEPLOYDIR}/${MODULE_TARBALL_BASE_NAME} -C ${D} lib
-		ln -sf ${MODULE_TARBALL_BASE_NAME}.bin ${MODULE_TARBALL_SYMLINK_NAME}
+		ln -sf ${MODULE_TARBALL_BASE_NAME} ${DEPLOYDIR}/${MODULE_TARBALL_SYMLINK_NAME}
 	fi
 
 	cd ${DEPLOYDIR}

meta/classes/libc-package.bbclass

@@ -96,14 +96,14 @@ do_prep_locale_tree() {
 	treedir=${WORKDIR}/locale-tree
 	rm -rf $treedir
 	mkdir -p $treedir/${base_bindir} $treedir/${base_libdir} $treedir/${datadir} $treedir/${localedir}
-	tar -cf - -C ${LOCALETREESRC}${datadir} -ps i18n | tar -xf - -C $treedir/${datadir}
+	tar -cf - -C ${LOCALETREESRC}${datadir} -p i18n | tar -xf - -C $treedir/${datadir}
 	# unzip to avoid parsing errors
 	for i in $treedir/${datadir}/i18n/charmaps/*gz; do 
 		gunzip $i
 	done
-	tar -cf - -C ${LOCALETREESRC}${base_libdir} -ps . | tar -xf - -C $treedir/${base_libdir}
+	tar -cf - -C ${LOCALETREESRC}${base_libdir} -p . | tar -xf - -C $treedir/${base_libdir}
 	if [ -f ${STAGING_DIR_NATIVE}${prefix_native}/lib/libgcc_s.* ]; then
-		tar -cf - -C ${STAGING_DIR_NATIVE}/${prefix_native}/${base_libdir} -ps libgcc_s.* | tar -xf - -C $treedir/${base_libdir}
+		tar -cf - -C ${STAGING_DIR_NATIVE}/${prefix_native}/${base_libdir} -p libgcc_s.* | tar -xf - -C $treedir/${base_libdir}
 	fi
 	install -m 0755 ${LOCALETREESRC}${bindir}/localedef $treedir/${base_bindir}
 }
@@ -113,7 +113,7 @@ do_collect_bins_from_locale_tree() {
 
 	parent=$(dirname ${localedir})
 	mkdir -p ${PKGD}/$parent
-	tar -cf - -C $treedir/$parent -ps $(basename ${localedir}) | tar -xf - -C ${PKGD}$parent
+	tar -cf - -C $treedir/$parent -p $(basename ${localedir}) | tar -xf - -C ${PKGD}$parent
 }
 
 inherit qemu

meta/classes/license.bbclass

@@ -51,11 +51,10 @@ license_create_manifest() {
 		printf "LICENSE:" >> ${LICENSE_MANIFEST}
 		for lic in ${pkged_lic}; do
 			# to reference a license file trim trailing + symbol
-			if [ -e "${LICENSE_DIRECTORY}/${pkged_pn}/generic_${lic%+}" ]; then
-				printf " ${lic}" >> ${LICENSE_MANIFEST}
-			else
-				echo "WARNING: The license listed ${lic} was not in the licenses collected for ${pkged_pn}"
+			if ! [ -e "${LICENSE_DIRECTORY}/${pkged_pn}/generic_${lic%+}" ]; then
+				bbwarn "The license listed ${lic} was not in the licenses collected for ${pkged_pn}"
 			fi
+                        printf " ${lic}" >> ${LICENSE_MANIFEST}
 		done
 		printf "\n\n" >> ${LICENSE_MANIFEST}
 	done
@@ -74,9 +73,9 @@ license_create_manifest() {
 					# Really don't need to copy the generics as they're 
 					# represented in the manifest and in the actual pkg licenses
 					# Doing so would make your image quite a bit larger
-					if [[ "${lic}" != "generic_"* ]]; then
+					if [ "${lic#generic_}" = "${lic}" ]; then
 						cp ${LICENSE_DIRECTORY}/${pkg}/${lic} ${IMAGE_ROOTFS}/usr/share/common-licenses/${pkg}/${lic}
-					elif [[ "${lic}" == "generic_"* ]]; then
+					else
 						if [ ! -f ${IMAGE_ROOTFS}/usr/share/common-licenses/${lic} ]; then
 							cp ${LICENSE_DIRECTORY}/${pkg}/${lic} ${IMAGE_ROOTFS}/usr/share/common-licenses/
 						fi

meta/classes/metadata_scm.bbclass

@@ -52,10 +52,13 @@ def base_get_metadata_monotone_revision(path, d):
     return monotone_revision
 
 def base_get_metadata_svn_revision(path, d):
+    # This only works with older subversion. For newer versions
+    # this function will need to be fixed by someone interested
     revision = "<unknown>"
     try:
-        revision = file( "%s/.svn/entries" % path ).readlines()[3].strip()
-    except IOError:
+        with open("%s/.svn/entries" % path) as f:
+            revision = f.readlines()[3].strip()
+    except IOError, IndexError:
         pass
     return revision
 

meta/classes/package.bbclass

@@ -226,7 +226,7 @@ python () {
         d.setVar("PACKAGERDEPTASK", "")
 }
 
-def splitdebuginfo(file, debugfile, debugsrcdir, d):
+def splitdebuginfo(file, debugfile, debugsrcdir, sourcefile, d):
     # Function to split a single file into two components, one is the stripped
     # target system binary, the other contains any debugging information. The
     # two files are linked to reference each other.
@@ -240,9 +240,6 @@ def splitdebuginfo(file, debugfile, debugsrcdir, d):
     debugedit = d.expand("${STAGING_LIBDIR_NATIVE}/rpm/bin/debugedit")
     workdir = d.getVar("WORKDIR", True)
     workparentdir = d.getVar("DEBUGSRC_OVERRIDE_PATH", True) or os.path.dirname(os.path.dirname(workdir))
-    sourcefile = d.expand("${WORKDIR}/debugsources.list")
-
-    bb.utils.remove(sourcefile)
 
     # We ignore kernel modules, we don't generate debug info files.
     if file.find("/lib/modules/") != -1 and file.endswith(".ko"):
@@ -454,7 +451,7 @@ python perform_packagecopy () {
     # Start by package population by taking a copy of the installed
     # files to operate on
     # Preserve sparse files and hard links
-    cmd = 'tar -cf - -C %s -ps . | tar -xf - -C %s' % (dest, dvar)
+    cmd = 'tar -cf - -C %s -p . | tar -xf - -C %s' % (dest, dvar)
     retval = subprocess.call(cmd, shell=True)
     if retval:
         bb.fatal("file copy failed with exit code %s (cmd was %s)" % (retval, cmd))
@@ -721,6 +718,9 @@ python split_and_strip_files () {
         debuglibdir = ""
         debugsrcdir = "/usr/src/debug"
 
+    sourcefile = d.expand("${WORKDIR}/debugsources.list")
+    bb.utils.remove(sourcefile)
+
     os.chdir(dvar)
 
     # Return type (bits):
@@ -832,7 +832,7 @@ python split_and_strip_files () {
             bb.utils.mkdirhier(os.path.dirname(fpath))
             #bb.note("Split %s -> %s" % (file, fpath))
             # Only store off the hard link reference if we successfully split!
-            splitdebuginfo(file, fpath, debugsrcdir, d)
+            splitdebuginfo(file, fpath, debugsrcdir, sourcefile, d)
 
         # Hardlink our debug symbols to the other hardlink copies
         for file in hardlinks:
@@ -897,7 +897,7 @@ python split_and_strip_files () {
         import multiprocessing
         nproc = multiprocessing.cpu_count()
         pool = bb.utils.multiprocessingpool(nproc)
-        processed = pool.imap(oe.package.runstrip, sfiles)
+        processed = list(pool.imap(oe.package.runstrip, sfiles))
         pool.close()
         pool.join()
 
@@ -925,7 +925,7 @@ python populate_packages () {
     for pkg in packages.split():
         if d.getVar('LICENSE_EXCLUSION-' + pkg, True):
             bb.warn("%s has an incompatible license. Excluding from packaging." % pkg)
-        elif pkg in package_list:
+        if pkg in package_list:
             bb.error("%s is listed in PACKAGES multiple times, this leads to packaging errors." % pkg)
         else:
             package_list.append(pkg)
@@ -965,6 +965,9 @@ python populate_packages () {
                 continue
             seen.append(file)
 
+            if d.getVar('LICENSE_EXCLUSION-' + pkg, True):
+                continue
+
             def mkdir(src, dest, p):
                 src = os.path.join(src, p)
                 dest = os.path.join(dest, p)
@@ -1249,7 +1252,7 @@ python package_do_filedeps() {
     import multiprocessing
     nproc = multiprocessing.cpu_count()
     pool =  bb.utils.multiprocessingpool(nproc)
-    processed = pool.imap(oe.package.filedeprunner, pkglist)
+    processed = list(pool.imap(oe.package.filedeprunner, pkglist))
     pool.close()
     pool.join()
 

meta/classes/package_rpm.bbclass

@@ -35,6 +35,11 @@ package_update_index_rpm () {
 		done
 	done
 
+	# FIXME stopgap for broken "bitbake package-index" since MULTILIB_PREFIX_LIST isn't set for that
+	if [ "$target_archs" = "" ] ; then
+		target_archs="${ALL_MULTILIB_PACKAGE_ARCHS}"
+	fi
+
 	target_archs=`echo "$target_archs" | tr - _`
 
 	archs=`for arch in $target_archs $sdk_archs ; do

meta/classes/pixbufcache.bbclass

@@ -8,27 +8,22 @@ inherit qemu
 
 PIXBUF_PACKAGES ??= "${PN}"
 
-#
-# On host, the postinstall MUST return 1 because we do not know if the intercept
-# hook will succeed. If it does succeed, than the packages will be marked as
-# installed.
-#
 pixbufcache_common() {
 if [ "x$D" != "x" ]; then
-	$INTERCEPT_DIR/postinst_intercept update_pixbuf_cache ${PKG} libdir=${libdir} \
+	$INTERCEPT_DIR/postinst_intercept update_pixbuf_cache ${PKG} mlprefix=${MLPREFIX} libdir=${libdir} \
 		bindir=${bindir} base_libdir=${base_libdir}
-	exit 1
-fi
+else
 
-# Update the pixbuf loaders in case they haven't been registered yet
-GDK_PIXBUF_MODULEDIR=${libdir}/gdk-pixbuf-2.0/2.10.0/loaders gdk-pixbuf-query-loaders --update-cache
+	# Update the pixbuf loaders in case they haven't been registered yet
+	GDK_PIXBUF_MODULEDIR=${libdir}/gdk-pixbuf-2.0/2.10.0/loaders gdk-pixbuf-query-loaders --update-cache
 
-if [ -x ${bindir}/gtk-update-icon-cache ] && [ -d ${datadir}/icons ]; then
-    for icondir in /usr/share/icons/*; do
-        if [ -d ${icondir} ]; then
-            gtk-update-icon-cache -t -q ${icondir}
-        fi
-    done
+	if [ -x ${bindir}/gtk-update-icon-cache ] && [ -d ${datadir}/icons ]; then
+		for icondir in /usr/share/icons/*; do
+			if [ -d ${icondir} ]; then
+				gtk-update-icon-cache -t -q ${icondir}
+			fi
+		done
+	fi
 fi
 }
 

meta/classes/populate_sdk_base.bbclass

@@ -14,7 +14,7 @@ TOOLCHAIN_HOST_TASK ?= "nativesdk-packagegroup-sdk-host packagegroup-cross-canad
 TOOLCHAIN_HOST_TASK_ATTEMPTONLY ?= ""
 TOOLCHAIN_TARGET_TASK ?= "packagegroup-core-standalone-sdk-target packagegroup-core-standalone-sdk-target-dbg"
 TOOLCHAIN_TARGET_TASK_ATTEMPTONLY ?= ""
-TOOLCHAIN_OUTPUTNAME ?= "${SDK_NAME}-toolchain-${DISTRO_VERSION}"
+TOOLCHAIN_OUTPUTNAME ?= "${SDK_NAME}-toolchain-${SDK_VERSION}"
 
 SDK_RDEPENDS = "${TOOLCHAIN_TARGET_TASK} ${TOOLCHAIN_HOST_TASK}"
 SDK_DEPENDS = "virtual/fakeroot-native sed-native"
@@ -181,11 +181,16 @@ else
 	echo "$target_sdk_dir"
 fi
 
-eval target_sdk_dir=$target_sdk_dir
-if [ -d $target_sdk_dir ]; then
-	target_sdk_dir=$(cd $target_sdk_dir; pwd)
+eval target_sdk_dir=$(echo "$target_sdk_dir"|sed 's/ /\\ /g')
+if [ -d "$target_sdk_dir" ]; then
+	target_sdk_dir=$(cd "$target_sdk_dir"; pwd)
 else
-	target_sdk_dir=$(readlink -m $target_sdk_dir)
+	target_sdk_dir=$(readlink -m "$target_sdk_dir")
+fi
+
+if [ -n "$(echo $target_sdk_dir|grep ' ')" ]; then
+	echo "The target directory path ($target_sdk_dir) contains spaces. Abort!"
+	exit 1
 fi
 
 if [ -e "$target_sdk_dir/environment-setup-${REAL_MULTIMACH_TARGET_SYS}" ]; then
@@ -249,7 +254,7 @@ if [ "$dl_path" = "" ] ; then
 	echo "SDK could not be set up. Relocate script unable to find ld-linux.so. Abort!"
 	exit 1
 fi
-executable_files=$($SUDO_EXEC find $native_sysroot -type f -perm +111)
+executable_files=$($SUDO_EXEC find $native_sysroot -type f -perm /111)
 
 tdir=`mktemp -d`
 if [ x$tdir = x ] ; then

meta/classes/populate_sdk_deb.bbclass

@@ -13,7 +13,7 @@ populate_sdk_post_deb () {
 	local target_rootfs=$1
 
 	mkdir -p ${target_rootfs}/etc
-	tar -cf - -C ${STAGING_ETCDIR_NATIVE} -ps apt | tar -xf - -C ${target_rootfs}/etc
+	tar -cf - -C ${STAGING_ETCDIR_NATIVE} -p apt | tar -xf - -C ${target_rootfs}/etc
 }
 
 populate_sdk_deb () {

meta/classes/qemu.bbclass

@@ -4,9 +4,7 @@
 #
 
 def qemu_target_binary(data):
-    target_arch = data.getVar("TARGET_ARCH_MULTILIB_ORIGINAL", True)
-    if not target_arch:
-        target_arch = data.getVar("TARGET_ARCH", True)
+    target_arch = data.getVar("TARGET_ARCH", True)
     if target_arch in ("i486", "i586", "i686"):
         target_arch = "i386"
     elif target_arch == "powerpc":

meta/classes/qmake_base.bbclass

@@ -48,7 +48,7 @@ addtask generate_qt_config_file after do_patch before do_configure
 
 qmake_base_do_configure() {
 	case ${QMAKESPEC} in
-	*linux-oe-g++|*linux-uclibc-oe-g++|*linux-gnueabi-oe-g++|*linux-uclibceabi-oe-g++|*linux-gnuspe-oe-g++|*linux-uclibcspe-oe-g++)
+	*linux-oe-g++|*linux-uclibc-oe-g++|*linux-gnueabi-oe-g++|*linux-uclibceabi-oe-g++|*linux-gnuspe-oe-g++|*linux-uclibcspe-oe-g++|*linux-gnun32-oe-g++)
 		;;
 	*-oe-g++)
 		die Unsupported target ${TARGET_OS} for oe-g++ qmake spec

meta/classes/sanity.bbclass

@@ -124,7 +124,7 @@ def check_toolchain_tune(data, tune, multilib):
             tune_errors.append("Tuning '%s' (%s) cannot be used with any supported tuning/ABI." %
                 (tune, tuneabi))
     if tune_errors:
-        return "Tuning '%s' has the following errors:\n" + '\n'.join(tune_errors)
+        return "Tuning '%s' has the following errors:\n" % tune + '\n'.join(tune_errors)
 
 def check_toolchain(data):
     tune_error_set = []
@@ -195,6 +195,17 @@ def check_sanity_tmpdir_change(tmpdir, data):
 
     # Check that TMPDIR isn't on a filesystem with limited filename length (eg. eCryptFS)
     testmsg = check_create_long_filename(tmpdir, "TMPDIR")
+
+    # Some third-party software apparently relies on chmod etc. being suid root (!!)
+    import stat
+    suid_check_bins = "chown chmod mknod".split()
+    for bin_cmd in suid_check_bins:
+        bin_path = bb.utils.which(os.environ["PATH"], bin_cmd)
+        if bin_path:
+            bin_stat = os.stat(bin_path)
+            if bin_stat.st_uid == 0 and bin_stat.st_mode & stat.S_ISUID:
+                testmsg = testmsg + '%s has the setuid bit set. This interferes with pseudo and may cause other issues that break the build process.\n' % bin_path
+
     # Check that we can fetch from various network transports
     errmsg = check_connectivity(data)
     testmsg = testmsg + check_connectivity(data)

meta/classes/sstate.bbclass

@@ -198,7 +198,7 @@ def sstate_install(ss, d):
     # Run the actual file install
     for state in ss['dirs']:
         if os.path.exists(state[1]):
-            oe.path.copytree(state[1], state[2])
+            oe.path.copyhardlinktree(state[1], state[2])
 
     for postinst in (d.getVar('SSTATEPOSTINSTFUNCS', True) or '').split():
         bb.build.exec_func(postinst, d)
@@ -431,13 +431,14 @@ def sstate_package(ss, d):
         if not link.startswith(tmpdir):
             return
 
-        depth = link.rpartition(tmpdir)[2].count('/')
+        depth = outputpath.rpartition(tmpdir)[2].count('/')
         base = link.partition(tmpdir)[2].strip()
         while depth > 1:
-            base = "../" + base
+            base = "/.." + base
             depth -= 1
+        base = "." + base
 
-        bb.debug(2, "Replacing absolute path %s with relative path %s" % (link, base))
+        bb.debug(2, "Replacing absolute path %s with relative path %s for %s" % (link, base, outputpath))
         os.remove(path)
         os.symlink(base, path)
 
@@ -455,11 +456,11 @@ def sstate_package(ss, d):
         for walkroot, dirs, files in os.walk(state[1]):
             for file in files:
                 srcpath = os.path.join(walkroot, file)
-                dstpath = srcpath.replace(state[1], sstatebuild + state[0])
+                dstpath = srcpath.replace(state[1], state[2])
                 make_relative_symlink(srcpath, dstpath, d)
             for dir in dirs:
                 srcpath = os.path.join(walkroot, dir)
-                dstpath = srcpath.replace(state[1], sstatebuild + state[0])
+                dstpath = srcpath.replace(state[1], state[2])
                 make_relative_symlink(srcpath, dstpath, d)
         bb.debug(2, "Preparing tree %s for packaging at %s" % (state[1], sstatebuild + state[0]))
         oe.path.copyhardlinktree(state[1], sstatebuild + state[0])
@@ -639,19 +640,12 @@ def setscene_depvalid(task, taskdependees, notneeded, d):
         return x.endswith("-native")
     def isNativeCross(x):
         return x.endswith("-native") or x.endswith("-cross") or x.endswith("-cross-initial")
-    def isSafeDep(x):
-        if x in ["quilt-native", "autoconf-native", "automake-native", "gnu-config-native", "libtool-native", "pkgconfig-native", "gcc-cross", "binutils-cross", "gcc-cross-initial"]:
-            return True
-        return False
+
     def isPostInstDep(x):
         if x in ["qemu-native", "gdk-pixbuf-native", "qemuwrapper-cross", "depmodwrapper-cross", "systemd-systemctl-native", "gtk-update-icon-cache-native"]:
             return True
         return False
 
-    # We can skip these "safe" dependencies since the aren't runtime dependencies, just build time
-    if isSafeDep(taskdependees[task][0]) and taskdependees[task][1] == "do_populate_sysroot":
-        return True
-
     # We only need to trigger populate_lic through direct dependencies
     if taskdependees[task][1] == "do_populate_lic":
         return True

meta/classes/staging.bbclass

@@ -13,7 +13,7 @@ sysroot_stage_dir() {
 	# However we always want to stage a $src itself, even if it's empty
 	mkdir -p "$dest"
 	if [ -d "$src" ]; then
-		tar -cf - -C "$src" -ps . | tar -xf - -C "$dest"
+		tar -cf - -C "$src" -p . | tar -xf - -C "$dest"
 	fi
 }
 

meta/classes/terminal.bbclass

@@ -11,43 +11,70 @@ XAUTHORITY ?= "${HOME}/.Xauthority"
 SHELL ?= "bash"
 
 
+def emit_terminal_func(command, envdata, d):
+    cmd_func = 'do_terminal'
+
+    envdata.setVar(cmd_func, 'exec ' + command)
+    envdata.setVarFlag(cmd_func, 'func', 1)
+
+    runfmt = d.getVar('BB_RUNFMT', True) or "run.{func}.{pid}"
+    runfile = runfmt.format(func=cmd_func, pid=os.getpid())
+    runfile = os.path.join(d.getVar('T', True), runfile)
+    with open(runfile, 'w') as script:
+        script.write('#!/bin/sh -e\n')
+        bb.data.emit_func(cmd_func, script, envdata)
+        script.write(cmd_func)
+        script.write("\n")
+    os.chmod(runfile, 0755)
+
+    return runfile
+
 def oe_terminal(command, title, d):
     import oe.data
     import oe.terminal
 
-    env = dict()
+    envdata = bb.data.init()
 
     for v in os.environ:
-        env[v] = os.environ[v]
+        envdata.setVar(v, os.environ[v])
+        envdata.setVarFlag(v, 'export', 1)
 
     for export in oe.data.typed_value('OE_TERMINAL_EXPORTS', d):
         value = d.getVar(export, True)
         if value is not None:
             os.environ[export] = str(value)
-            env[export] = str(value)
+            envdata.setVar(export, str(value))
+            envdata.setVarFlag(export, 'export', 1)
         if export == "PSEUDO_DISABLED":
             if "PSEUDO_UNLOAD" in os.environ:
                 del os.environ["PSEUDO_UNLOAD"]
-            if "PSEUDO_UNLOAD" in env:
-                del env["PSEUDO_UNLOAD"]
+            envdata.delVar("PSEUDO_UNLOAD")
 
     # Add in all variables from the user's original environment which
     # haven't subsequntly been set/changed
     origbbenv = d.getVar("BB_ORIGENV", False) or {}
     for key in origbbenv:
-        if key in env:
+        if key in envdata:
             continue
         value = origbbenv.getVar(key, True)
         if value is not None:
             os.environ[key] = str(value)
-            env[key] = str(value)
+            envdata.setVar(key, str(value))
+            envdata.setVarFlag(key, 'export', 1)
+
+    # LD_PRELOAD of pseudo will cause problems if this is a fakeroot task
+    # and we shouldn't be exporting it anyway
+    envdata.delVar('LD_PRELOAD')
+
+    # Replace command with an executable wrapper script
+    command = emit_terminal_func(command, envdata, d)
 
     terminal = oe.data.typed_value('OE_TERMINAL', d).lower()
     if terminal == 'none':
         bb.fatal('Devshell usage disabled with OE_TERMINAL')
     elif terminal != 'auto':
         try:
-            oe.terminal.spawn(terminal, command, title, env, d)
+            oe.terminal.spawn(terminal, command, title, None, d)
             return
         except oe.terminal.UnsupportedTerminal:
             bb.warn('Unsupported terminal "%s", defaulting to "auto"' %
@@ -56,7 +83,7 @@ def oe_terminal(command, title, d):
             bb.fatal('Unable to spawn terminal %s: %s' % (terminal, exc))
 
     try:
-        oe.terminal.spawn_preferred(command, title, env, d)
+        oe.terminal.spawn_preferred(command, title, None, d)
     except oe.terminal.NoSupportedTerminals:
         bb.fatal('No valid terminal found, unable to open devshell')
     except oe.terminal.ExecutionError as exc:

meta/conf/distro/include/csl-versions.inc

@@ -18,6 +18,7 @@ def csl_get_version(d):
 		stdout, stderr = csl_run(d, 'gcc', '-v')
 	except bb.process.CmdError as exc:
 		bb.error('Failed to obtain CodeSourcery toolchain version: %s' % exc)
+		bb.error('Make sure that MACHINE is set correctly in your local.conf and the toolchain supports %s.' % d.getVar("TARGET_ARCH", True))
 		return 'UNKNOWN'
 	else:
 		last_line = stderr.splitlines()[-1]

meta/conf/distro/include/tcmode-external-sourcery.inc

@@ -27,13 +27,16 @@ PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}gcc-intermediate = "external-sourcery
 PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}g++ = "external-sourcery-toolchain"
 PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}binutils = "external-sourcery-toolchain"
 PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}libc-for-gcc = "external-sourcery-toolchain"
+PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}libc-initial = "external-sourcery-toolchain"
 PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}compilerlibs = "external-sourcery-toolchain"
 PREFERRED_PROVIDER_libgcc = "external-sourcery-toolchain"
+PREFERRED_PROVIDER_eglibc = "external-sourcery-toolchain"
 PREFERRED_PROVIDER_virtual/libc = "external-sourcery-toolchain"
 PREFERRED_PROVIDER_virtual/libintl = "external-sourcery-toolchain"
 PREFERRED_PROVIDER_virtual/libiconv = "external-sourcery-toolchain"
 PREFERRED_PROVIDER_glibc-thread-db = "external-sourcery-toolchain"
 PREFERRED_PROVIDER_virtual/linux-libc-headers = "external-sourcery-toolchain"
+PREFERRED_PROVIDER_virtual/linux-libc-headers-dev = "external-sourcery-toolchain"
 PREFERRED_PROVIDER_gdbserver ??= "external-sourcery-toolchain"
 
 # No need to re-compile the locale files

meta/conf/machine/include/arm/arch-armv4.inc

@@ -1,7 +1,7 @@
 DEFAULTTUNE ?= "armv4"
 
 TUNEVALID[armv4] = "Enable instructions for ARMv4"
-TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv4", "-march=armv4${ARMPKGSFX_THUMB}", "", d)}"
+TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "armv4", " -march=armv4${ARMPKGSFX_THUMB}", "", d)}"
 # enable --fix-v4bx when we have armv4 in TUNE_FEATURES, but then disable it when we have also armv5 or thumb
 # maybe we should extend bb.utils.contains to support check for any checkvalues in value, now it does 
 # checkvalues.issubset(val) which cannot be used for negative test of foo neither bar in value

meta/conf/machine/include/arm/arch-armv5.inc

@@ -2,7 +2,7 @@ DEFAULTTUNE ?= "armv5"
 
 TUNEVALID[armv5] = "Enable instructions for ARMv5"
 TUNECONFLICTS[armv5] = "armv4"
-TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv5", "-march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}", "", d)}"
+TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "armv5", " -march=armv5${ARMPKGSFX_THUMB}${ARMPKGSFX_DSP}", "", d)}"
 MACHINEOVERRIDES =. "${@bb.utils.contains("TUNE_FEATURES", "armv5", "armv5:", "" ,d)}"
 
 ARMPKGSFX_DSP = "${@bb.utils.contains("TUNE_FEATURES", [ "armv5", "dsp" ], "e", "", d)}"

meta/conf/machine/include/arm/arch-armv6.inc

@@ -2,7 +2,7 @@ DEFAULTTUNE ?= "armv6"
 
 TUNEVALID[armv6] = "Enable instructions for ARMv6"
 TUNECONFLICTS[armv6] = "armv4 armv5"
-TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv6", "-march=armv6", "", d)}"
+TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "armv6", " -march=armv6", "", d)}"
 MACHINEOVERRIDES =. "${@bb.utils.contains("TUNE_FEATURES", "armv6", "armv6:", "" ,d)}"
 
 require conf/machine/include/arm/arch-armv5-dsp.inc

meta/conf/machine/include/arm/arch-armv7a.inc

@@ -2,7 +2,7 @@ DEFAULTTUNE ?= "armv7a"
 
 TUNEVALID[armv7a] = "Enable instructions for ARMv7-a"
 TUNECONFLICTS[armv7a] = "armv4 armv5 armv6 armv7"
-TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "armv7a", "-march=armv7-a", "", d)}"
+TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "armv7a", " -march=armv7-a", "", d)}"
 MACHINEOVERRIDES =. "${@bb.utils.contains("TUNE_FEATURES", "armv7a", "armv7a:", "" ,d)}"
 
 require conf/machine/include/arm/arch-armv6.inc

meta/conf/machine/include/arm/feature-arm-neon.inc

@@ -1,3 +1,3 @@
 TUNEVALID[neon] = "Enable Neon SIMD accelerator unit."
-TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "neon", "-mfpu=neon", "" ,d)}"
+TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "neon", " -mfpu=neon", "" ,d)}"
 ARMPKGSFX_FPU .= "${@bb.utils.contains("TUNE_FEATURES", "neon", "-neon", "" ,d)}"

meta/conf/machine/include/arm/feature-arm-thumb.inc

@@ -6,7 +6,7 @@
 # slower.
 TUNEVALID[thumb] = "Use thumb instructions instead of ARM"
 ARM_THUMB_M_OPT = "${@['-marm', '-mthumb'][d.getVar('ARM_INSTRUCTION_SET', True) == 'thumb']}"
-TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "thumb", "${ARM_THUMB_M_OPT}", "", d)}"
+TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "thumb", " ${ARM_THUMB_M_OPT}", "", d)}"
 OVERRIDES .= "${@bb.utils.contains("TUNE_FEATURES", "thumb", ":thumb", "", d)}"
 
 # Note armv7 will hit on armv7a as well
@@ -20,7 +20,7 @@ ARMPKGSFX_THUMB .= "${@bb.utils.contains("TUNE_FEATURES", [ "armv7", "thumb" ],
 # arm system and vice versa. It is strongly recommended that DISTROs not
 # turn this off - the actual cost is very small.
 TUNEVALID[no-thumb-interwork] = "Disable mixing of thumb and ARM functions"
-TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", "-mno-thumb-interwork", "-mthumb-interwork", d)}"
+TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", " -mno-thumb-interwork", " -mthumb-interwork", d)}"
 OVERRIDES .= "${@bb.utils.contains("TUNE_FEATURES", "no-thumb-interwork", ":thumb-interwork", "", d)}"
 
 TARGET_CC_KERNEL_ARCH += "-mno-thumb-interwork -marm"

meta/conf/machine/include/arm/feature-arm-vfp.inc

@@ -2,5 +2,5 @@ TUNEVALID[vfp] = "Enable Vector Floating Point (vfp) unit."
 ARMPKGSFX_FPU .= "${@bb.utils.contains("TUNE_FEATURES", "vfp", "-vfp", "" ,d)}"
 
 TUNEVALID[callconvention-hard] = "Enable EABI hard float call convention, requires VFP."
-TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "vfp", bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "-mfloat-abi=hard", "-mfloat-abi=softfp", d), "" ,d)}"
+TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "vfp", bb.utils.contains("TUNE_FEATURES", "callconvention-hard", " -mfloat-abi=hard", " -mfloat-abi=softfp", d), "" ,d)}"
 ARMPKGSFX_EABI .= "${@bb.utils.contains("TUNE_FEATURES", [ "callconvention-hard", "vfp" ], "hf", "", d)}"

meta/conf/machine/include/ia32/arch-ia32.inc

@@ -13,7 +13,7 @@ TUNE_PKGARCH = "${TUNE_PKGARCH_tune-${DEFAULTTUNE}}"
 TUNEVALID[m32] = "IA32 ELF32 standard ABI"
 TUNECONFLICTS[m32] = "m64 mx32"
 TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "m32", "${X86ARCH32}", "" ,d)}"
-TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m32", "-m32", "", d)}"
+TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "m32", " -m32", "", d)}"
 MACHINEOVERRIDES =. "${@bb.utils.contains("TUNE_FEATURES", "m32", "x86:", "" ,d)}"
 
 # x32 ABI
@@ -21,7 +21,7 @@ TUNEVALID[mx32] = "IA32e (x86_64) ELF32 standard ABI"
 TUNECONFLICTS[mx32] = "m64 m32"
 TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "mx32", "${X86ARCH64}", "" ,d)}"
 ABIEXTENSION .= "${@bb.utils.contains("TUNE_FEATURES", "mx32", "x32", "" ,d)}"
-TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-mx32", "", d)}"
+TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "mx32", " -mx32", "", d)}"
 TUNE_LDARGS += "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-m elf32_x86_64", "", d)}"
 TUNE_ASARGS += "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-x32", "", d)}"
 
@@ -29,7 +29,7 @@ TUNE_ASARGS += "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-x32", "", d)}"
 TUNEVALID[m64] = "IA32e (x86_64) ELF64 standard ABI"
 TUNECONFLICTS[m64] = "m32 mx32"
 TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "m64", "${X86ARCH64}", "" ,d)}"
-TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m64", "-m64", "", d)}"
+TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "m64", " -m64", "", d)}"
 
 # Default Tune configurations
 AVAILTUNES += "x86"

meta/conf/machine/include/mips/arch-mips.inc

@@ -8,25 +8,25 @@ DEFAULTTUNE ?= "mips"
 
 # Endianess
 TUNEVALID[bigendian] = "Enable big-endian mode"
-TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "bigendian", "-meb", "-mel", d)}"
+TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "bigendian", " -meb", " -mel", d)}"
 
 # ABI flags
 TUNEVALID[o32] = "MIPS o32 ABI"
 TUNECONFLICTS[o32] = "n32 n64"
-TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "o32", "-mabi=32", "", d)}"
+TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "o32", " -mabi=32", "", d)}"
 
 TUNEVALID[n32] = "MIPS64 n32 ABI"
 TUNECONFLICTS[n32] = "o32 n64"
 ABIEXTENSION .= "${@bb.utils.contains("TUNE_FEATURES", "n32", "n32", "" ,d)}"
-TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "n32", "-mabi=n32", "", d)}"
+TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "n32", " -mabi=n32", "", d)}"
 
 TUNEVALID[n64] = "MIPS64 n64 ABI"
 TUNECONFLICTS[n64] = "o32 n32"
-TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "n64", "-mabi=64", "", d)}"
+TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "n64", " -mabi=64", "", d)}"
 
 # Floating point
 TUNEVALID[fpu-hard] = "Use hardware FPU"
-TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "fpu-hard", "-mhard-float", "-msoft-float", d)}"
+TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "fpu-hard", " -mhard-float", " -msoft-float", d)}"
 TARGET_FPU = "${@bb.utils.contains("TUNE_FEATURES", "fpu-hard", "", "soft", d)}"
 
 # Package naming

meta/conf/machine/include/powerpc/arch-powerpc.inc

@@ -9,14 +9,14 @@ TUNE_PKGARCH = "${TUNE_PKGARCH_tune-${DEFAULTTUNE}}"
 ABIEXTENSION ?= ""
 
 TUNEVALID[m32] = "Power ELF32 standard ABI"
-TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m32", "-m32", "", d)}"
+TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "m32", " -m32", "", d)}"
 TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "m32", "powerpc", "", d)}"
 
 TUNEVALID[fpu-hard] = "Use hardware FPU."
-TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "fpu-hard", "-mhard-float", "", d)}"
+TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "fpu-hard", " -mhard-float", "", d)}"
 
 TUNEVALID[fpu-soft] = "Use software FPU."
-TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "fpu-soft", "-msoft-float", "", d)}"
+TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "fpu-soft", " -msoft-float", "", d)}"
 TARGET_FPU .= "${@bb.utils.contains("TUNE_FEATURES", "fpu-soft", "soft", "", d)}"
 
 TUNEVALID[altivec] = "Altivec"

meta/conf/machine/include/powerpc/arch-powerpc64.inc

@@ -4,7 +4,7 @@ require conf/machine/include/powerpc/arch-powerpc.inc
 
 TUNEVALID[m64] = "Power ELF64 standard ABI"
 TUNECONFLICTS[m64] = "m32 nf"
-TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m64", "-m64", "", d)}"
+TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "m64", " -m64", "", d)}"
 TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", [ "m64" ], "powerpc64", "", d)}"
 
 AVAILTUNES += "powerpc64"

meta/conf/machine/include/qemu.inc

@@ -23,3 +23,6 @@ RDEPENDS_kernel-base = ""
 PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
 
 EXTRA_IMAGEDEPENDS += "qemu-native qemu-helper-native"
+
+# Provide the nfs server kernel module for all qemu images
+KERNEL_FEATURES_append_pn-linux-yocto = " features/nfsd/nfsd-enable.scc"

meta/conf/machine/include/sh/arch-sh.inc

@@ -6,4 +6,4 @@ TUNE_ARCH = "${TUNE_ARCH_tune-${DEFAULTTUNE}}"
 TUNE_PKGARCH = "${TUNE_PKGARCH_tune-${DEFAULTTUNE}}"
 
 TUNEVALID[bigendian] = "Enabled big-endian mode."
-TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "bigendian", "-mb", "-ml", d)}"
+TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "bigendian", " -mb", " -ml", d)}"

meta/conf/machine/include/tune-arm1136jf-s.inc

@@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv6"
 require conf/machine/include/arm/arch-armv6.inc
 
 TUNEVALID[arm1136jfs] = "Enable arm1136jfs specific processor optimizations"
-TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "arm1136jfs", "-mtune=arm1136jf-s", "", d)}"
+TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "arm1136jfs", " -mtune=arm1136jf-s", "", d)}"
 
 AVAILTUNES += "arm1136jfs"
 ARMPKGARCH_tune-arm1136jfs = "arm1136jfs"

meta/conf/machine/include/tune-arm920t.inc

@@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv4t"
 require conf/machine/include/arm/arch-armv4.inc
 
 TUNEVALID[arm920t] = "Enable arm920t specific processor optimizations"
-TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "arm920t", "-mtune=arm920t", "", d)}"
+TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "arm920t", " -mtune=arm920t", "", d)}"
 
 AVAILTUNES += "arm920t"
 ARMPKGARCH_tune-arm920t = "arm920t"

meta/conf/machine/include/tune-arm926ejs.inc

@@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv5te"
 require conf/machine/include/arm/arch-armv5-dsp.inc
 
 TUNEVALID[arm926ejs] = "Enable arm926ejs specific processor optimizations"
-TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", "-mtune=arm926ej-s", "", d)}"
+TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "arm926ejs", " -mtune=arm926ej-s", "", d)}"
 
 AVAILTUNES += "arm926ejs"
 ARMPKGARCH_tune-arm926ejs = "arm926ejs"

meta/conf/machine/include/tune-arm9tdmi.inc

@@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv4t"
 require conf/machine/include/arm/arch-armv4.inc
 
 TUNEVALID[arm9tdmi] = "Enable arm9tdmi specific processor optimizations"
-TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "arm9tdmi", "-mtune=arm9tdmi", "", d)}"
+TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "arm9tdmi", " -mtune=arm9tdmi", "", d)}"
 
 AVAILTUNES += "arm9tdmi"
 ARMPKGARCH_tune-arm9tdmi = "arm9tdmi"

meta/conf/machine/include/tune-c3.inc

@@ -2,7 +2,7 @@ require conf/machine/include/ia32/arch-ia32.inc
 
 TUNEVALID[c3] = "VIA Cyrix III or VIA C3 specific optimizations"
 TUNECONFLICTS[c3] = "m64 mx32"
-TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "c3", "-march=c3 -mtune=c3", "", d)}"
+TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "c3", " -march=c3 -mtune=c3", "", d)}"
 
 AVAILTUNES += "c3"
 TUNE_FEATURES_tune-c3 = "${TUNE_FEATURES_tune-x86} c3"

meta/conf/machine/include/tune-core2.inc

@@ -4,7 +4,7 @@ require conf/machine/include/tune-i586.inc
 
 # Extra tune features
 TUNEVALID[core2] = "Enable core2 specific processor optimizations"
-TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "core2", "-march=core2 -msse3 -mtune=generic -mfpmath=sse", "", d)}"
+TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "core2", " -march=core2 -msse3 -mtune=generic -mfpmath=sse", "", d)}"
 
 # Extra tune selections
 AVAILTUNES += "core2"

meta/conf/machine/include/tune-cortexa15.inc

@@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv7a-neon"
 require conf/machine/include/arm/arch-armv7a.inc
 
 TUNEVALID[cortexa15] = "Enable Cortex-A15 specific processor optimizations"
-TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "cortexa15", "-mtune=cortex-a15", "", d)}"
+TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "cortexa15", " -mtune=cortex-a15", "", d)}"
 
 # Little Endian base configs
 AVAILTUNES += "cortexa15 cortexa15t cortexa15-neon cortexa15t-neon"

meta/conf/machine/include/tune-cortexa7.inc

@@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv7a-neon"
 require conf/machine/include/arm/arch-armv7a.inc
 
 TUNEVALID[cortexa7] = "Enable Cortex-A7 specific processor optimizations"
-TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "cortexa7", "-mtune=cortex-a7", "", d)}"
+TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "cortexa7", " -mtune=cortex-a7", "", d)}"
 
 # Little Endian base configs
 AVAILTUNES += "cortexa7 cortexa7t cortexa7-neon cortexa7t-neon"

meta/conf/machine/include/tune-cortexa8.inc

@@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv7a-neon"
 require conf/machine/include/arm/arch-armv7a.inc
 
 TUNEVALID[cortexa8] = "Enable Cortex-A8 specific processor optimizations"
-TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "cortexa8", "-mtune=cortex-a8", "", d)}"
+TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "cortexa8", " -mtune=cortex-a8", "", d)}"
 
 # Little Endian base configs
 AVAILTUNES += "cortexa8 cortexa8t cortexa8-neon cortexa8t-neon"

meta/conf/machine/include/tune-cortexa9.inc

@@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv7a-neon"
 require conf/machine/include/arm/arch-armv7a.inc
 
 TUNEVALID[cortexa9] = "Enable Cortex-A9 specific processor optimizations"
-TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "cortexa9", "-mtune=cortex-a9", "", d)}"
+TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "cortexa9", " -mtune=cortex-a9", "", d)}"
 
 # Little Endian base configs
 AVAILTUNES += "cortexa9 cortexa9t cortexa9-neon cortexa9t-neon"

meta/conf/machine/include/tune-cortexm1.inc

@@ -3,7 +3,7 @@ DEFAULTTUNE ?= "armv7a"
 require conf/machine/include/arm/arch-armv7a.inc
 
 TUNEVALID[cortexm1] = "Enable Cortex-M1 specific processor optimizations"
-TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "cortexm1", "-mtune=cortex-m1", "", d)}"
+TUNE_CCARGS .= "${@bb.utils.contains("TUNE_FEATURES", "cortexm1", " -mtune=cortex-m1", "", d)}"
 
 AVAILTUNES += "cortexm1"
 ARMPKGARCH_tune-cortexm1 = "cortexm1"