poky.conf: update version for 1.4.2 release

Update DISTRO_VERSION to 1.4.2 prior to the release and add this version
to the list of tested distributions. DISTRO_NAME also needed to be
updated to refer to Poky 9.0.2 specifically.

(From meta-yocto rev: e640e62c50b9dd0fc6a1771dfc95a2585aed8a47)

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

README.hardware

@@ -308,9 +308,9 @@ Load the kernel and dtb (device tree blob), and boot the system as follows:
 
  5. Download the kernel and dtb, and boot:
 
- => tftp 800000 uImage-mpc8315e-rdb.bin
- => tftp 780000 uImage-mpc8315e-rdb.dtb
- => bootm 800000 - 780000
+ => tftp 1000000 uImage-mpc8315e-rdb.bin
+ => tftp 2000000 uImage-mpc8315e-rdb.dtb
+ => bootm 1000000 - 2000000
 
 
 Ubiquiti Networks RouterStation Pro (routerstationpro)

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

bitbake/lib/bb/data.py

@@ -158,9 +158,9 @@ def expandKeys(alterdata, readdata = None):
 
     for key in todolist:
         ekey = todolist[key]
-        if ekey in keys(alterdata):
+        newval = alterdata.getVar(ekey, 0)
+        if newval:
             val = alterdata.getVar(key, 0)
-            newval = alterdata.getVar(ekey, 0)
             if val is not None and newval is not None:
                 bb.warn("Variable key %s (%s) replaces original key %s (%s)." % (key, val, ekey, newval))
         alterdata.renameVar(key, ekey)

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

@@ -74,6 +74,9 @@ class FetchError(BBFetchException):
 
 class ChecksumError(FetchError):
     """Exception when mismatched checksum encountered"""
+    def __init__(self, message, url = None, checksum = None):
+        self.checksum = checksum
+        FetchError.__init__(self, message, url)
 
 class NoChecksumError(FetchError):
     """Exception when no checksum is specified, but BB_STRICT_CHECKSUM is set"""
@@ -561,7 +564,7 @@ def verify_checksum(u, ud, d):
         msg = msg + '\nIf this change is expected (e.g. you have upgraded to a new version without updating the checksums) then you can use these lines within the recipe:\nSRC_URI[%s] = "%s"\nSRC_URI[%s] = "%s"\nOtherwise you should retry the download and/or check with upstream to determine if the file has become corrupted or otherwise unexpectedly modified.\n' % (ud.md5_name, md5data, ud.sha256_name, sha256data)
 
     if len(msg):
-        raise ChecksumError('Checksum mismatch!%s' % msg, u)
+        raise ChecksumError('Checksum mismatch!%s' % msg, u, md5data)
 
 
 def update_stamp(u, ud, d):
@@ -753,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
@@ -804,6 +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))
+            rename_bad_checksum(ud, e.checksum)
         elif isinstance(e, NoChecksumError):
             raise
         else:
@@ -972,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)
@@ -1388,6 +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))
+                            rename_bad_checksum(ud, e.checksum)
                         elif isinstance(e, NoChecksumError):
                             raise
                         else:

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

@@ -244,7 +244,7 @@ class diskMonitor:
                     # checking for such a fs.
                     if st.f_files == 0:
                         logger.warn("Inode check for %s is unavaliable, will remove it from disk monitor" % path)
-                        minInode = None
+                        self.devDict[k][2] = None
                         continue
                     # Always show warning, the self.checked would always be False if the action is WARN
                     if self.preFreeI[k] == 0 or self.preFreeI[k] - freeInode > self.inodeInterval and not self.checked[k]:

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,6 +330,77 @@ 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):
 

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

@@ -84,7 +84,7 @@ class ImageSelectionDialog (CrumbsDialog):
         open_button.connect("clicked", self.select_path_cb, self, entry)
         table.attach(open_button, 9, 10, 0, 1)
 
-        self.image_table = HobViewTable(self.__columns__)
+        self.image_table = HobViewTable(self.__columns__, "Images")
         self.image_table.set_size_request(-1, 300)
         self.image_table.connect("toggled", self.toggled_cb)
         self.image_table.connect_group_selection(self.table_selected_cb)

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

@@ -103,25 +103,55 @@ class PackageListModel(gtk.ListStore):
     Create, if required, and return a filtered gtk.TreeModelSort
     containing only the items specified by filter
     """
-    def tree_model(self, filter, excluded_items_ahead=False, included_items_ahead=True, search_data=None):
+    def tree_model(self, filter, excluded_items_ahead=False, included_items_ahead=False, search_data=None, initial=False):
         model = self.filter_new()
         self.filtered_nb = 0
         model.set_visible_func(self.tree_model_filter, filter)
 
         sort = gtk.TreeModelSort(model)
+        if initial:
+            sort.set_sort_column_id(PackageListModel.COL_NAME, gtk.SORT_ASCENDING)
+            sort.set_default_sort_func(None)
+
         if excluded_items_ahead:
             sort.set_default_sort_func(self.exclude_item_sort_func, search_data)
         elif included_items_ahead:
             sort.set_default_sort_func(self.include_item_sort_func, search_data)
         else:
-            sort.set_sort_column_id(RecipeListModel.COL_NAME, gtk.SORT_ASCENDING)
-            sort.set_default_sort_func(None)
+            if search_data and search_data!='Search recipes by name' and search_data!='Search package groups by name':
+                sort.set_default_sort_func(self.sort_func, search_data)
+            else:
+                sort.set_sort_column_id(PackageListModel.COL_NAME, gtk.SORT_ASCENDING)
+                sort.set_default_sort_func(None)
+
+        sort.set_sort_func(PackageListModel.COL_INC, self.sort_column, PackageListModel.COL_INC)
+        sort.set_sort_func(PackageListModel.COL_SIZE, self.sort_column, PackageListModel.COL_SIZE)
+        sort.set_sort_func(PackageListModel.COL_BINB, self.sort_column, PackageListModel.COL_BINB)
+        sort.set_sort_func(PackageListModel.COL_RCP, self.sort_column, PackageListModel.COL_RCP)
         return sort
 
+    def sort_column(self, model, row1, row2, col):
+        value1 = model.get_value(row1, col)
+        value2 = model.get_value(row2, col)
+        if col==PackageListModel.COL_SIZE:
+            value1 = HobPage._string_to_size(value1)
+            value2 = HobPage._string_to_size(value2)
+
+        cmp_res = cmp(value1, value2)
+        if cmp_res!=0:
+            if col==PackageListModel.COL_INC:
+                return -cmp_res
+            else:
+                return cmp_res
+        else:
+            name1 = model.get_value(row1, PackageListModel.COL_NAME)
+            name2 = model.get_value(row2, PackageListModel.COL_NAME)
+            return cmp(name1,name2)
+
     def exclude_item_sort_func(self, model, iter1, iter2, user_data=None):
         if user_data:
-            val1 = model.get_value(iter1, RecipeListModel.COL_NAME)
-            val2 = model.get_value(iter2, RecipeListModel.COL_NAME)
+            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):
                 return -1
             elif not val1.startswith(user_data) and val2.startswith(user_data):
@@ -129,14 +159,14 @@ class PackageListModel(gtk.ListStore):
             else:
                 return 0
         else:
-            val1 = model.get_value(iter1, RecipeListModel.COL_FADE_INC)
-            val2 = model.get_value(iter2, RecipeListModel.COL_INC)
+            val1 = model.get_value(iter1, PackageListModel.COL_FADE_INC)
+            val2 = model.get_value(iter2, PackageListModel.COL_INC)
             return ((val1 == True) and (val2 == False))
 
     def include_item_sort_func(self, model, iter1, iter2, user_data=None):
         if user_data:
-            val1 = model.get_value(iter1, RecipeListModel.COL_NAME)
-            val2 = model.get_value(iter2, RecipeListModel.COL_NAME)
+            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):
                 return -1
             elif not val1.startswith(user_data) and val2.startswith(user_data):
@@ -144,10 +174,20 @@ class PackageListModel(gtk.ListStore):
             else:
                 return 0
         else:
-            val1 = model.get_value(iter1, RecipeListModel.COL_INC)
-            val2 = model.get_value(iter2, RecipeListModel.COL_INC)
+            val1 = model.get_value(iter1, PackageListModel.COL_INC)
+            val2 = model.get_value(iter2, PackageListModel.COL_INC)
             return ((val1 == False) and (val2 == True))
 
+    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):
+            return -1
+        elif not val1.startswith(user_data) and val2.startswith(user_data):
+            return 1
+        else:
+            return 0
+
     def convert_vpath_to_path(self, view_model, view_path):
         # view_model is the model sorted
         # get the path of the model filtered
@@ -162,7 +202,7 @@ class PackageListModel(gtk.ListStore):
         it = view_model.get_iter_first()
         while it:
             name = self.find_item_for_path(path)
-            view_name = view_model.get_value(it, RecipeListModel.COL_NAME)
+            view_name = view_model.get_value(it, PackageListModel.COL_NAME)
             if view_name == name:
                 view_path = view_model.get_path(it)
                 return view_path
@@ -213,7 +253,6 @@ class PackageListModel(gtk.ListStore):
 
             # pkgsize is in KB
             size = HobPage._size_to_string(HobPage._string_to_size(pkgsize + ' KB'))
-
             self.set(self.append(), self.COL_NAME, pkg, self.COL_VER, pkgv,
                      self.COL_REV, pkgr, self.COL_RNM, pkg_rename,
                      self.COL_SEC, section, self.COL_SUM, summary,
@@ -520,25 +559,61 @@ class RecipeListModel(gtk.ListStore):
             val2 = model.get_value(iter2, RecipeListModel.COL_INC)
             return ((val1 == False) and (val2 == True))
 
+    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):
+            return -1
+        elif not val1.startswith(user_data) and val2.startswith(user_data):
+            return 1
+        else:
+            return 0
+
     """
     Create, if required, and return a filtered gtk.TreeModelSort
     containing only the items specified by filter
     """
-    def tree_model(self, filter, excluded_items_ahead=False, included_items_ahead=True, search_data=None):
+    def tree_model(self, filter, excluded_items_ahead=False, included_items_ahead=False, search_data=None, initial=False):
         model = self.filter_new()
         self.filtered_nb = 0
         model.set_visible_func(self.tree_model_filter, filter)
 
         sort = gtk.TreeModelSort(model)
+        if initial:
+            sort.set_sort_column_id(RecipeListModel.COL_NAME, gtk.SORT_ASCENDING)
+            sort.set_default_sort_func(None)
+
         if excluded_items_ahead:
             sort.set_default_sort_func(self.exclude_item_sort_func, search_data)
         elif included_items_ahead:
             sort.set_default_sort_func(self.include_item_sort_func, search_data)
         else:
-            sort.set_sort_column_id(RecipeListModel.COL_NAME, gtk.SORT_ASCENDING)
-            sort.set_default_sort_func(None)
+            if search_data and search_data!='Search recipes by name' and search_data!='Search package groups by name':
+                sort.set_default_sort_func(self.sort_func, search_data)
+            else:
+                sort.set_sort_column_id(RecipeListModel.COL_NAME, gtk.SORT_ASCENDING)
+                sort.set_default_sort_func(None)
+
+        sort.set_sort_func(RecipeListModel.COL_INC, self.sort_column, RecipeListModel.COL_INC)
+        sort.set_sort_func(RecipeListModel.COL_GROUP, self.sort_column, RecipeListModel.COL_GROUP)
+        sort.set_sort_func(RecipeListModel.COL_BINB, self.sort_column, RecipeListModel.COL_BINB)
+        sort.set_sort_func(RecipeListModel.COL_LIC, self.sort_column, RecipeListModel.COL_LIC)
         return sort
 
+    def sort_column(self, model, row1, row2, col):
+        value1 = model.get_value(row1, col)
+        value2 = model.get_value(row2, col)
+        cmp_res = cmp(value1, value2)
+        if cmp_res!=0:
+            if col==RecipeListModel.COL_INC:
+                return -cmp_res
+            else:
+                return cmp_res
+        else:
+            name1 = model.get_value(row1, RecipeListModel.COL_NAME)
+            name2 = model.get_value(row2, RecipeListModel.COL_NAME)
+            return cmp(name1,name2)
+
     def convert_vpath_to_path(self, view_model, view_path):
         filtered_model_path = view_model.convert_path_to_child_path(view_path)
         filtered_model = view_model.get_model()

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

@@ -83,7 +83,7 @@ class HobViewTable (gtk.VBox):
                             gobject.TYPE_PYOBJECT,)),
     }
 
-    def __init__(self, columns):
+    def __init__(self, columns, name):
         gtk.VBox.__init__(self, False, 6)
         self.table_tree = gtk.TreeView()
         self.table_tree.set_headers_visible(True)
@@ -94,12 +94,18 @@ class HobViewTable (gtk.VBox):
         self.toggle_columns = []
         self.table_tree.connect("row-activated", self.row_activated_cb)
         self.top_bar = None
+        self.tab_name = name
 
         for i, column in enumerate(columns):
-            col = gtk.TreeViewColumn(column['col_name'])
+            col_name = column['col_name']
+            col = gtk.TreeViewColumn(col_name)
             col.set_clickable(True)
             col.set_resizable(True)
-            col.set_sort_column_id(column['col_id'])
+            if self.tab_name.startswith('Included'):
+                if col_name!='Included':
+                    col.set_sort_column_id(column['col_id'])
+            else:
+                col.set_sort_column_id(column['col_id'])
             if 'col_min' in column.keys():
                 col.set_min_width(column['col_min'])
             if 'col_max' in column.keys():
@@ -122,7 +128,7 @@ class HobViewTable (gtk.VBox):
                 self.toggle_id = i
                 col.pack_end(cell, True)
                 col.set_attributes(cell, active=column['col_id'])
-                self.toggle_columns.append(column['col_name'])
+                self.toggle_columns.append(col_name)
                 if 'col_group' in column.keys():
                     col.set_cell_data_func(cell, self.set_group_number_cb)
             elif column['col_style'] == 'radio toggle':
@@ -133,7 +139,7 @@ class HobViewTable (gtk.VBox):
                 self.toggle_id = i
                 col.pack_end(cell, True)
                 col.set_attributes(cell, active=column['col_id'])
-                self.toggle_columns.append(column['col_name'])
+                self.toggle_columns.append(col_name)
             elif column['col_style'] == 'binb':
                 cell = gtk.CellRendererText()
                 col.pack_start(cell, True)

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

@@ -142,17 +142,18 @@ class PackageSelectionPage (HobPage):
         # append the tab
         for page in self.pages:
             columns = page['columns']
-            tab = HobViewTable(columns)
+            name = page['name']
+            tab = HobViewTable(columns, name)
             search_names.append(page['search'])
             search_tips.append(page['searchtip'])
             filter = page['filter']
-            sort_model = self.package_model.tree_model(filter)
+            sort_model = self.package_model.tree_model(filter, initial=True)
             tab.set_model(sort_model)
-            tab.connect("toggled", self.table_toggled_cb, page['name'])
-            if page['name'] == "Included packages":
+            tab.connect("toggled", self.table_toggled_cb, name)
+            if name == "Included packages":
                 tab.connect("button-release-event", self.button_click_cb)
                 tab.connect("cell-fadeinout-stopped", self.after_fadeout_checkin_include)
-            if page['name'] == "All packages":
+            if name == "All packages":
                 tab.connect("button-release-event", self.button_click_cb)
                 tab.connect("cell-fadeinout-stopped", self.after_fadeout_checkin_include)
             self.ins.append_page(tab, page['name'], page['tooltip'])
@@ -287,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/crumbs/recipeselectionpage.py

@@ -154,20 +154,21 @@ class RecipeSelectionPage (HobPage):
         # append the tabs in order
         for page in self.pages:
             columns = page['columns']
-            tab = HobViewTable(columns)
+            name = page['name']
+            tab = HobViewTable(columns, name)
             search_names.append(page['search'])
             search_tips.append(page['searchtip'])
             filter = page['filter']
-            sort_model = self.recipe_model.tree_model(filter)
+            sort_model = self.recipe_model.tree_model(filter, initial=True)
             tab.set_model(sort_model)
-            tab.connect("toggled", self.table_toggled_cb, page['name'])
-            if page['name'] == "Included recipes":
+            tab.connect("toggled", self.table_toggled_cb, name)
+            if name == "Included recipes":
                 tab.connect("button-release-event", self.button_click_cb)
                 tab.connect("cell-fadeinout-stopped", self.after_fadeout_checkin_include)
-            if page['name'] == "Package Groups":
+            if name == "Package Groups":
                 tab.connect("button-release-event", self.button_click_cb)
                 tab.connect("cell-fadeinout-stopped", self.after_fadeout_checkin_include)
-            if page['name'] == "All recipes":
+            if name == "All recipes":
                 tab.connect("button-release-event", self.button_click_cb)
                 tab.connect("cell-fadeinout-stopped", self.button_click_cb)
             self.ins.append_page(tab, page['name'], page['tooltip'])
@@ -241,7 +242,6 @@ class RecipeSelectionPage (HobPage):
             properties['description'] = tree_model.get_value(tree_model.get_iter(path), RecipeListModel.COL_DESC)
             self.builder.show_recipe_property_dialog(properties)
 
-
     def build_packages_clicked_cb(self, button):
         self.builder.build_packages()
 

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

@@ -95,7 +95,7 @@
                     <literallayout class='monospaced'>
      $ source /opt/poky/&DISTRO;/environment-setup-i586-poky-linux
                     </literallayout></para></listitem>
-                <listitem><para><emphasis>Generate the local <filename>aclocal.m4</filename>
+                <listitem><para><emphasis>Generate the local aclocal.m4
                     files and create the configure script:</emphasis>
                     The following GNU Autotools generate the local
                     <filename>aclocal.m4</filename> files and create the
@@ -112,7 +112,7 @@
                     <literallayout class='monospaced'>
      $ touch NEWS README AUTHORS ChangeLog
                     </literallayout></para></listitem>
-                <listitem><para><emphasis>Generate the <filename>configure</filename>
+                <listitem><para><emphasis>Generate the configure
                     file:</emphasis>
                     This command generates the <filename>configure</filename>:
                     <literallayout class='monospaced'>

documentation/adt-manual/adt-intro.xml

@@ -19,7 +19,8 @@
     how to access and use the cross-development toolchains, how to
     customize the development packages installation,
     how to use command line development for both Autotools-based and Makefile-based projects,
-    and an introduction to the Eclipse Yocto Plug-in.
+    and an introduction to the <trademark class='trade'>Eclipse</trademark> IDE
+    Yocto Plug-in.
     <note>
         The ADT is distribution-neutral and does not require the Yocto 
         Project reference distribution, which is called Poky.  
@@ -42,7 +43,9 @@
         <itemizedlist>
             <listitem><para>An architecture-specific cross-toolchain and matching
                 sysroot both built by the OpenEmbedded build system.
-                The toolchain and sysroot are based on a metadata configuration and extensions,
+                The toolchain and sysroot are based on a 
+                <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
+                configuration and extensions,
                 which allows you to cross-develop on the host machine for the target hardware.
                 </para></listitem>
             <listitem><para>The Eclipse IDE Yocto Plug-in.</para></listitem>
@@ -65,7 +68,7 @@
             This toolchain is created either by running the ADT Installer
             script, a toolchain installer script, or through a
             <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
-            that is based on your metadata configuration or extension for
+            that is based on your Metadata configuration or extension for
             your targeted device.
             The cross-toolchain works with a matching target sysroot.
         </para>
@@ -78,7 +81,7 @@
             The matching target sysroot contains needed headers and libraries for generating
             binaries that run on the target architecture.
             The sysroot is based on the target root filesystem image that is built by
-            the OpenEmbedded build system and uses the same metadata configuration
+            the OpenEmbedded build system and uses the same Metadata configuration
             used to build the cross-toolchain.
         </para>
     </section>
@@ -127,7 +130,7 @@
                     the environment setup script, QEMU is installed and automatically
                     available.</para></listitem>
                 <listitem><para>If you have installed the cross-toolchain
-                    tarball and you have sourcing the toolchain's setup environment script, QEMU
+                    tarball and you have sourced the toolchain's setup environment script, QEMU
                     is also installed and automatically available.</para></listitem>
             </itemizedlist>
         </para>
@@ -147,7 +150,7 @@
                     stutters in your desktop experience, or situations that overload your server
                     even when you have plenty of CPU power left.
                     You can find out more about LatencyTOP at
-                    <ulink url='http://www.latencytop.org/'></ulink>.</para></listitem>
+                    <ulink url='https://latencytop.org/'></ulink>.</para></listitem>
                 <listitem><para><emphasis>PowerTOP:</emphasis> Helps you determine what
                     software is using the most power.
                     You can find out more about PowerTOP at

documentation/adt-manual/adt-manual.xml

@@ -61,7 +61,17 @@
                 <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>
+      </revhistory>
 
     <copyright>
       <year>&COPYRIGHT_YEAR;</year>

documentation/adt-manual/adt-package.xml

@@ -55,9 +55,9 @@
     </para>
 
     <note>
-        For build performance information related to the PMS, see
-        <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-package'>Packaging - <filename>package*.bbclass</filename></ulink>
-        in the Yocto Project Reference Manual.
+        For build performance information related to the PMS, see the
+        "<ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-package'>Packaging - <filename>package*.bbclass</filename></ulink>" 
+        section in the Yocto Project Reference Manual.
     </note>
 
     <para>

documentation/adt-manual/adt-prepare.xml

@@ -39,18 +39,18 @@
 
     <para>
         <itemizedlist>
-            <listitem><para><emphasis>Use the ADT Installer Script:</emphasis>
+            <listitem><para><emphasis>Use the ADT installer script:</emphasis>
                 This method is the recommended way to install the ADT because it
                 automates much of the process for you.
                 For example, you can configure the installation to install the QEMU emulator
                 and the user-space NFS, specify which root filesystem profiles to download,
                 and define the target sysroot location.</para></listitem>
-            <listitem><para><emphasis>Use an Existing Toolchain:</emphasis>
+            <listitem><para><emphasis>Use an existing toolchain:</emphasis>
                 Using this method, you select and download an architecture-specific
                 toolchain installer and then run the script to hand-install the toolchain.
                 If you use this method, you just get the cross-toolchain and QEMU - you do not
                 get any of the other mentioned benefits had you run the ADT Installer script.</para></listitem>
-            <listitem><para><emphasis>Use the Toolchain from within the Build Directory:</emphasis>
+            <listitem><para><emphasis>Use the toolchain from within the Build Directory:</emphasis>
                 If you already have a
                 <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>,
                 you can build the cross-toolchain within the directory.
@@ -91,16 +91,16 @@
             <para>
                 If you use BitBake to generate the ADT Installer tarball, you must
                 <filename>source</filename> the environment setup script
-                (<filename>&OE_INIT_FILE;</filename>) located
-                in the Source Directory before running the <filename>bitbake</filename>
-                command that creates the tarball.
+                (<ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>) 
+                located in the Source Directory before running the 
+                BitBake command that creates the tarball.
             </para>
 
             <para>
                 The following example commands download the Poky tarball, set up the
                 <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>,
                 set up the environment while also creating the default Build Directory,
-                and run the <filename>bitbake</filename> command that results in the tarball
+                and run the BitBake command that results in the tarball
                 <filename>~/yocto-project/build/tmp/deploy/sdk/adt_installer.tar.bz2</filename>:
                 <literallayout class='monospaced'>
      $ cd ~
@@ -293,7 +293,7 @@
                         variable is correctly set if you are building
                         a toolchain for an architecture that differs from your
                         current development host machine.</para>
-                        <para>When the <filename>bitbake</filename> command
+                        <para>When the BitBake command
                         completes, the toolchain installer will be in
                         <filename>tmp/deploy/sdk</filename> in the Build
                         Directory.</para>
@@ -326,7 +326,7 @@
             A final way of making the cross-toolchain available is to use BitBake
             to generate the toolchain within an existing
             <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
-            This method does not install the toolchain into the
+            This method does not install the toolchain into the default
             <filename>/opt</filename> directory.
             As with the previous method, if you need to install the target sysroot, you must
             do that separately as well.
@@ -355,11 +355,11 @@
                     cross-toolchain generation.
                     <note>If you change out of your working directory after you
                         <filename>source</filename> the environment setup script and before you run
-                        the <filename>bitbake</filename> command, the command might not work.
-                        Be sure to run the <filename>bitbake</filename> command immediately
+                        the BitBake command, the command might not work.
+                        Be sure to run the BitBake command immediately
                         after checking or editing the <filename>local.conf</filename> but without
                         changing out of your working directory.</note>
-                    Once the <filename>bitbake</filename> command finishes,
+                    Once the BitBake command finishes,
                     the cross-toolchain is generated and populated within the Build Directory.
                     You will notice environment setup files for the cross-toolchain in the
                     Build Directory in the <filename>tmp</filename> directory.
@@ -393,7 +393,7 @@
     <para>
         Be sure to run the environment setup script that matches the architecture for
         which you are developing.
-        Environment setup scripts begin with the string “<filename>environment-setup</filename>”
+        Environment setup scripts begin with the string "<filename>environment-setup</filename>"
         and include as part of their name the architecture.
         For example, the toolchain environment setup script for a 64-bit
         IA-based architecture installed in the default installation directory
@@ -442,8 +442,8 @@
         <para>
             If you are planning on developing against your image and you are not
             building or using one of the Yocto Project development images
-            (e.g. core-image-*-dev), you must be sure to include the development
-            packages as part of your image recipe.
+            (e.g. <filename>core-image-*-dev</filename>), you must be sure to
+            include the development packages as part of your image recipe.
         </para>
 
         <para>

documentation/bsp-guide/bsp-guide.xml

@@ -73,6 +73,16 @@
                 <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>
         </revhistory>
 
     <copyright>

documentation/bsp-guide/bsp.xml

@@ -185,10 +185,13 @@
      meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay-noemgd/xorg.conf
      meta-crownbay/recipes-kernel/
      meta-crownbay/recipes-kernel/linux/
-     meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend
-     meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.4.bbappend
      meta-crownbay/recipes-kernel/linux/linux-yocto_3.2.bbappend
      meta-crownbay/recipes-kernel/linux/linux-yocto_3.4.bbappend
+     meta-crownbay/recipes-kernel/linux/linux-yocto_3.8.bbappend
+     meta-crownbay/recipes-kernel/linux/linux-yocto-dev.bbappend
+     meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.2.bbappend
+     meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.4.bbappend
+     meta-crownbay/recipes-kernel/linux/linux-yocto-rt_3.8.bbappend
                 </literallayout>
             </para>
 
@@ -256,8 +259,9 @@
                 This file provides information on where to locate the BSP source files.
                 For example, information provides where to find the sources that comprise
                 the images shipped with the BSP.
-                Information is also included to help you find the metadata used to generate the images
-                that ship with the BSP.
+                Information is also included to help you find the 
+                <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
+                used to generate the images that ship with the BSP.
             </para>
             </section>
 
@@ -273,7 +277,7 @@
             <para>
                 This optional area contains useful pre-built kernels and user-space filesystem
                 images appropriate to the target system.
-                This directory typically contains graphical (e.g. sato) and minimal live images
+                This directory typically contains graphical (e.g. Sato) and minimal live images
                 when the BSP tarball has been created and made available in the
                 <ulink url='&YOCTO_HOME_URL;'>Yocto Project</ulink> website.
                 You can use these kernels and images to get a system running and quickly get started
@@ -376,9 +380,9 @@
                 The <filename>crownbay.conf</filename> file is used for the Crown Bay BSP
                 that supports the <trademark class='registered'>Intel</trademark> Embedded
                 Media and Graphics Driver (<trademark class='registered'>Intel</trademark>
-                EMGD), while the <filename>crownbay-noemgd.conf</filename> file is used for the
-                Crown Bay BSP that does not support the <trademark class='registered'>Intel</trademark>
-                EMGD.
+                EMGD), while the <filename>crownbay-noemgd</filename> file is used for the 
+                Crown Bay BSP that supports Video Electronics Standards Association (VESA) 
+                graphics only.
             </para>
 
             <para>
@@ -662,8 +666,8 @@
             <para>
                 Certain requirements exist for a released BSP to be considered
                 compliant with the Yocto Project.
-                Additionally, a single recommendation also exists.
-                This section describes the requirements and recommendation for
+                Additionally, recommendations also exist.
+                This section describes the requirements and recommendations for
                 released BSPs.
             </para>
 
@@ -684,11 +688,11 @@
                             You should consult the packaging and distribution guidelines for your
                             specific release process.
                             For an example of packaging and distribution requirements, see the
-                            <ulink url='https://wiki.yoctoproject.org/wiki/Third_Party_BSP_Release_Process'>Third
-                            Party BSP Release Process</ulink> wiki page.</para></listitem>
+                            "<ulink url='https://wiki.yoctoproject.org/wiki/Third_Party_BSP_Release_Process'>Third Party BSP Release Process</ulink>"
+                            wiki page.</para></listitem>
                         <listitem><para>The requirements for the BSP as it is made available to a developer
                             are completely independent of the released form of the BSP.
-                            For example, the BSP metadata can be contained within a Git repository
+                            For example, the BSP Metadata can be contained within a Git repository
                             and could have a directory structure completely different from what appears
                             in the officially released BSP layer.</para></listitem>
                         <listitem><para>It is not required that specific packages or package
@@ -737,12 +741,12 @@
                             recipes.
                             The recipes themselves should follow the general guidelines
                             for recipes used in the Yocto Project found in the
-                            <ulink url='https://wiki.yoctoproject.org/wiki/Recipe_%26_Patch_Style_Guide'>Yocto
-                            Recipe and Patch Style Guide</ulink>.</para></listitem>
+                            "<ulink url='https://wiki.yoctoproject.org/wiki/Recipe_%26_Patch_Style_Guide'>Yocto Recipe and Patch Style Guide</ulink>".
+                            </para></listitem>
                         <listitem><para><emphasis>License File:</emphasis>
                             You must include a license file in the
                             <filename>meta-&lt;bsp_name&gt;</filename> directory.
-                            This license covers the BSP metadata as a whole.
+                            This license covers the BSP Metadata as a whole.
                             You must specify which license to use since there is no
                             default license if one is not specified.
                             See the
@@ -771,11 +775,15 @@
                                     For example, this information includes information on
                                     special variables needed to satisfy a EULA,
                                     or instructions on information needed to build or distribute
-                                    binaries built from the BSP metadata.</para></listitem>
+                                    binaries built from the BSP Metadata.</para></listitem>
                                 <listitem><para>The name and contact information for the
                                     BSP layer maintainer.
                                     This is the person to whom patches and questions should
-                                    be sent.</para></listitem>
+                                    be sent.
+                                    For information on how to find the right person, see the 
+                                    "<ulink url='&YOCTO_DOCS_DEV_URL;#how-to-submit-a-change'>How to Submit a Change</ulink>"
+                                    section in the Yocto Project Development Manual.
+                                    </para></listitem>
                                 <listitem><para>Instructions on how to build the BSP using the BSP
                                     layer.</para></listitem>
                                 <listitem><para>Instructions on how to boot the BSP build from
@@ -818,7 +826,7 @@
                             BSP layers for each target.
                             <note>It is completely possible for a developer to structure the
                             working repository as a conglomeration of unrelated BSP
-                            files, and to possibly generate specifically targeted 'release' BSPs
+                            files, and to possibly generate BSPs targeted for release
                             from that directory using scripts or some other mechanism.
                             Such considerations are outside the scope of this document.</note>
                             </para></listitem>
@@ -875,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_4.47.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>
@@ -933,9 +969,9 @@
 
             <para>
                 For cases where you can substitute a free component and still
-                maintain the system's functionality, the Yocto Project website's
-                <ulink url='&YOCTO_HOME_URL;/download/all?keys=&amp;download_type=1&amp;download_version='>BSP
-                Download Page</ulink> makes available de-featured BSPs
+                maintain the system's functionality, the "Downloads" page from the 
+                <ulink url='&YOCTO_HOME_URL;'>Yocto Project website's</ulink>
+                makes available de-featured BSPs
                 that are completely free of any IP encumbrances.
                 For these cases, you can use the substitution directly and
                 without any further licensing requirements.
@@ -988,9 +1024,9 @@
 		        can build the encumbered image with no change at all
 		        to the normal build process.</para></listitem>
                     <listitem><para><emphasis>Get a pre-built version of the BSP:</emphasis>
-                        You can get this type of BSP by visiting the Yocto Project website's
-                        <ulink url='&YOCTO_HOME_URL;/download'>Download</ulink>
-                        page and clicking on "BSP Downloads".
+                        You can get this type of BSP by visiting the 
+                        "Downloads" page of the 
+                        <ulink url='&YOCTO_HOME_URL;'>Yocto Project website</ulink>.
                         You can download BSP tarballs that contain proprietary components
                         after agreeing to the licensing
                         requirements of each of the individually encumbered
@@ -1025,7 +1061,7 @@
                 The Yocto Project includes a couple of tools that enable
                 you to create a <link linkend='bsp-layers'>BSP layer</link>
                 from scratch and do basic configuration and maintenance
-                of the kernel without ever looking at a metadata file.
+                of the kernel without ever looking at a Metadata file.
                 These tools are <filename>yocto-bsp</filename> and <filename>yocto-kernel</filename>,
                 respectively.
 	    </para>
@@ -1112,7 +1148,7 @@
                 </para>
 
                 <para>
-                    For any sub-command, you can also use the word 'help' just before the
+                    For any sub-command, you can use the word "help" option just before the
                     sub-command to get more extensive documentation:
                     <literallayout class='monospaced'>
      $ yocto-bsp help create
@@ -1134,7 +1170,7 @@
          The value of the 'karch' parameter determines the set of files
          that will be generated for the BSP, along with the specific set of
          'properties' that will be used to fill out the BSP-specific
-         portions of the BSP.  The possible values for the 'karch' paramter
+         portions of the BSP.  The possible values for the 'karch' parameter
          can be listed via 'yocto-bsp list karch'.
 
          ...
@@ -1146,6 +1182,16 @@
                     on them, you should find it relatively straightforward to discover the commands
                     necessary to create a BSP and perform basic kernel maintenance on that BSP using
                     the tools.
+                    <note>
+                        You can also use the <filename>yocto-layer</filename> tool to create
+                        a "generic" layer. 
+                        For information on this tool, see the 
+                        "<ulink url='&YOCTO_DOCS_DEV_URL;#creating-a-general-layer-using-the-yocto-layer-script'>Creating a General Layer Using the yocto-layer Script</ulink>"
+                        section in the Yocto Project Development Guide.
+                    </note>
+                </para>
+
+                <para>
                     The next sections provide a concrete starting point to expand on a few points that
                     might not be immediately obvious or that could use further explanation.
                 </para>
@@ -1161,6 +1207,9 @@
                     by the Yocto Project, as well as QEMU versions of the same.
                     The default mode of the script's operation is to prompt you for information needed
                     to generate the BSP layer.
+                </para>                    
+
+                <para>
                     For the current set of BSPs, the script prompts you for various important
                     parameters such as:
                     <itemizedlist>
@@ -1201,7 +1250,7 @@
                     Of the available architectures, <filename>qemu</filename> is the only architecture
                     that causes the script to prompt you further for an actual architecture.
                     In every other way, this architecture is representative of how creating a BSP for
-                    a 'real' machine would work.
+                    an actual machine would work.
                     The reason the example uses this architecture is because it is an emulated architecture
                     and can easily be followed without requiring actual hardware.
                 </para>
@@ -1213,8 +1262,9 @@
                     and providing an invalid response causes the script to accept the default value.
                     Once the script completes, the new <filename>meta-myarm</filename> BSP layer
                     is created in the current working directory.
-                    This example assumes you have source the &OE_INIT_FILE; and are currently
-                    in the top-level folder of the
+                    This example assumes you have sourced the 
+                    <ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>
+                    and are currently in the top-level folder of the
                     <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
                 </para>
 
@@ -1229,17 +1279,17 @@
 	     4) PowerPC (32-bit)
 	     5) MIPS    (32-bit)
      3
-     Would you like to use the default (3.4) kernel? (y/n) [default: y]
+     Would you like to use the default (3.8) kernel? (y/n) [default: y]
      Do you need a new machine branch for this BSP (the alternative is to re-use an existing branch)? [y/n] [default: y]
-     Getting branches from remote repo git://git.yoctoproject.org/linux-yocto-3.4.git...
+     Getting branches from remote repo git://git.yoctoproject.org/linux-yocto-3.8.git...
      Please choose a machine branch to base your new BSP branch on: [default: standard/base]
              1) standard/arm-versatile-926ejs
              2) standard/base
              3) standard/beagleboard
-             4) standard/cedartrail
+             4) standard/ck
              5) standard/crownbay
-             6) standard/emenlow
-             7) standard/fishriver
+             6) standard/edf
+             7) standard/emenlow
              8) standard/fri2
              9) standard/fsl-mpc8315e-rdb
              10) standard/mti-malta32
@@ -1251,25 +1301,26 @@
      Would you like SMP support? (y/n) [default: y]
      Does your BSP have a touchscreen? (y/n) [default: n]
      Does your BSP have a keyboard? (y/n) [default: y]
+
      New qemu BSP created in meta-myarm
                     </literallayout>
                     Let's take a closer look at the example now:
                     <orderedlist>
-                        <listitem><para>For the <filename>qemu</filename> architecture,
+                        <listitem><para>For the QEMU architecture,
                             the script first prompts you for which emulated architecture to use.
-                            In the example, we use the <filename>arm</filename> architecture.
+                            In the example, we use the ARM architecture.
                             </para></listitem>
                         <listitem><para>The script then prompts you for the kernel.
-                            The default 3.4 kernel is acceptable.
+                            The default 3.8 kernel is acceptable.
                             So, the example accepts the default.
                             If you enter 'n', the script prompts you to further enter the kernel
-                            you do want to use (e.g. 3.0, 3.2_preempt-rt, and so forth.).</para></listitem>
+                            you do want to use (e.g. 3.2, 3.2_preempt-rt, and so forth.).</para></listitem>
                         <listitem><para>Next, the script asks whether you would like to have a new
                             branch created especially for your BSP in the local
                             <ulink url='&YOCTO_DOCS_DEV_URL;#local-kernel-files'>Linux Yocto Kernel</ulink>
                             Git repository .
                             If not, then the script re-uses an existing branch.</para>
-                            <para>In this example, the default (or 'yes') is accepted.
+                            <para>In this example, the default (or "yes") is accepted.
                             Thus, a new branch is created for the BSP rather than using a common, shared
                             branch.
                             The new branch is the branch committed to for any patches you might later add.
@@ -1281,8 +1332,8 @@
                             you are now given the opportunity to select a particular machine branch on
                             which to base your new BSP-specific machine branch
                             (or to re-use if you had elected to not create a new branch).
-                            Because this example is generating an <filename>arm</filename> BSP, the example
-                            uses <filename>#1</filename> at the prompt, which selects the arm-versatile branch.
+                            Because this example is generating an ARM-based BSP, the example
+                            uses <filename>#1</filename> at the prompt, which selects the ARM-versatile branch.
                             </para></listitem>
                         <listitem><para>The remainder of the prompts are routine.
                             Defaults are accepted for each.</para></listitem>
@@ -1313,7 +1364,7 @@
                     </literallayout>
                     Adding the layer to this file allows the build system to build the BSP and
                     the <filename>yocto-kernel</filename> tool to be able to find the layer and
-                    other metadata it needs on which to operate.
+                    other Metadata it needs on which to operate.
                 </para>
             </section>
 
@@ -1352,6 +1403,13 @@
         patch list        List the patches associated with a BSP
         patch add         Patch the Yocto kernel for a BSP
         patch rm          Remove patches from a BSP
+        feature list      List the features used by a BSP
+        feature add       Have a BSP use a feature
+        feature rm        Have a BSP stop using a feature
+        features list     List the features available to BSPs
+        feature describe  Describe a particular feature
+        feature create    Create a new BSP-local feature
+        feature destroy   Remove a BSP-local feature
 
       See 'yocto-kernel help COMMAND' for more information on a specific command.
 
@@ -1428,7 +1486,7 @@
      Added items:
              CONFIG_MISC_DEVICES=y
 
-     $ yocto-kernel config add myarm KCONFIG_YOCTO_TESTMOD=y
+     $ yocto-kernel config add myarm CONFIG_YOCTO_TESTMOD=y
      Added items:
              CONFIG_YOCTO_TESTMOD=y
                     </literallayout>

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

@@ -23,7 +23,7 @@
              </para></listitem>
          <listitem><para><emphasis>User Application Development:</emphasis>
              User Application Development covers development of applications that you intend
-             to run on some target hardware.
+             to run on target hardware.
              For information on how to set up your host development system for user-space
              application development, see the
              <ulink url='&YOCTO_DOCS_ADT_URL;'>Yocto Project Application Developer's Guide</ulink>.
@@ -35,10 +35,10 @@
          <listitem><para><emphasis>Temporary Source Code Modification:</emphasis>
              Direct modification of temporary source code is a convenient development model
              to quickly iterate and develop towards a solution.
-             Once the solution has been implemented, you should of course take steps to
+             Once you implement the solution, you should of course take steps to
              get the changes upstream and applied in the affected recipes.</para></listitem>
          <listitem><para><emphasis>Image Development using Hob:</emphasis>
-             You can use the <ulink url='&YOCTO_HOME_URL;/projects/hob'>Hob</ulink> to build
+             You can use the <ulink url='&YOCTO_HOME_URL;/tools-resources/projects/hob'>Hob</ulink> to build
              custom operating system images within the build environment.
              Hob provides an efficient interface to the OpenEmbedded build system.</para></listitem>
          <listitem><para><emphasis>Using a Development Shell:</emphasis>
@@ -117,21 +117,22 @@
                     Directory</link> available on your host system.
                     Having these files on your system gives you access to the build
                     process and to the tools you need.
-                    For information on how to set up the
-                    <link linkend='source-directory'>Source Directory</link>, see the
-                    "<link linkend='getting-setup'>Getting Set up</link>" section.</para></listitem>
+                    For information on how to set up the Source Directory,
+                    see the
+                    "<link linkend='getting-setup'>Getting Set Up</link>" section.</para></listitem>
                 <listitem><para><emphasis>Establish the <filename>meta-intel</filename>
                     repository on your system</emphasis>:  Having local copies
                     of these supported BSP layers on your system gives you
                     access to layers you might be able to build on or modify
                     to create your BSP.
                     For information on how to get these files, see the
-                    "<link linkend='getting-setup'>Getting Setup</link>" section.</para></listitem>
+                    "<link linkend='getting-setup'>Getting Set Up</link>" section.</para></listitem>
                 <listitem><para><emphasis>Create your own BSP layer using the
                     <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 the recipes for your BSP.
+                    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
                     Yocto Project is to use the <filename>yocto-bsp</filename> script.
@@ -159,12 +160,12 @@
                     <filename>mpc8315e</filename>, and <filename>routerstationpro</filename>.
                     The recipes and configurations for these four BSPs are located and dispersed
                     within the <link linkend='source-directory'>Source Directory</link>.
-                    On the other hand, BSP layers for Cedar Trail, Chief River, Crown Bay,
-                    Crystal Forest, Emenlow, Fish River, Fish River 2, Jasper Forest, N450,
+                    On the other hand, BSP layers for Chief River, Crown Bay,
+                    Crystal Forest, Emenlow, Fish River Island 2, Jasper Forest, N450, NUC DC3217IYE,
                     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 section
+                    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
@@ -178,7 +179,7 @@
                     directories within the BSP layer.
                     Configuration changes identify where your new layer is on the local system
                     and identify which kernel you are going to use.
-                    When you run the <filename>yocto-bsp</filename> script you are able to interactively
+                    When you run the <filename>yocto-bsp</filename> script, you are able to interactively
                     configure many things for the BSP (e.g. keyboard, touchscreen, and so forth).
                     </para></listitem>
                 <listitem><para><emphasis>Make recipe changes to your new BSP layer</emphasis>:  Recipe
@@ -268,21 +269,15 @@
                 Within this group, you will find several kernels supported by
                 the Yocto Project:
                 <itemizedlist>
-                    <listitem><para><emphasis><filename>linux-yocto-2.6.34</filename></emphasis> - The
-                    stable Yocto Project kernel that is based on the Linux 2.6.34 released kernel.</para></listitem>
-                    <listitem><para><emphasis><filename>linux-yocto-2.6.37</filename></emphasis> - The
-                    stable Yocto Project kernel that is based on the Linux 2.6.37 released kernel.</para></listitem>
-                    <listitem><para><emphasis><filename>linux-yocto-3.0</filename></emphasis> - The stable
-                    Yocto Project kernel that is based on the Linux 3.0 released kernel.</para></listitem>
-                    <listitem><para><emphasis><filename>linux-yocto-3.0-1.1.x</filename></emphasis> - The
-                    stable Yocto Project kernel to use with the Yocto Project Release 1.1.x. This kernel
-                    is based on the Linux 3.0 released kernel.</para></listitem>
                     <listitem><para><emphasis><filename>linux-yocto-3.2</filename></emphasis> - The
                     stable Yocto Project kernel to use with the Yocto Project Release 1.2. This kernel
                     is based on the Linux 3.2 released kernel.</para></listitem>
                     <listitem><para><emphasis><filename>linux-yocto-3.4</filename></emphasis> - The
                     stable Yocto Project kernel to use with the Yocto Project Release 1.3. This kernel
                     is based on the Linux 3.4 released kernel.</para></listitem>
+                    <listitem><para><emphasis><filename>linux-yocto-3.8</filename></emphasis> - The
+                    stable Yocto Project kernel to use with the Yocto Project Release 1.4. This kernel
+                    is based on the Linux 3.8 released kernel.</para></listitem>
                     <listitem><para><emphasis><filename>linux-yocto-dev</filename></emphasis> - A development
                     kernel based on the latest upstream release candidate available.</para></listitem>
                 </itemizedlist>
@@ -292,8 +287,8 @@
                 The kernels are maintained using the Git revision control system
                 that structures them using the familiar "tree", "branch", and "leaf" scheme.
                 Branches represent diversions from general code to more specific code, while leaves
-                represent the end-points for a complete and unique kernel whose source files
-                when gathered from the root of the tree to the leaf accumulate to create the files
+                represent the end-points for a complete and unique kernel whose source files,
+                when gathered from the root of the tree to the leaf, accumulate to create the files
                 necessary for a specific piece of hardware and its features.
                 The following figure displays this concept:
             <para>
@@ -304,12 +299,12 @@
             <para>
                 Within the figure, the "Kernel.org Branch Point" represents the point in the tree
                 where a supported base kernel is modified from the Linux kernel.
-                For example, this could be the branch point for the <filename>linux-yocto-3.0</filename>
+                For example, this could be the branch point for the <filename>linux-yocto-3.4</filename>
                 kernel.
                 Thus, everything further to the right in the structure is based on the
-                <filename>linux-yocto-3.0</filename> kernel.
+                <filename>linux-yocto-3.4</filename> kernel.
                 Branch points to right in the figure represent where the
-                <filename>linux-yocto-3.0</filename> kernel is modified for specific hardware
+                <filename>linux-yocto-3.4</filename> kernel is modified for specific hardware
                 or types of kernels, such as real-time kernels.
                 Each leaf thus represents the end-point for a kernel designed to run on a specific
                 targeted device.
@@ -347,10 +342,14 @@
                 ways.
                 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 get at
-                temporary kernel source files extracted and used during the OpenEmbedded
-                build system.
+                If you just need to make some patches to the kernel, you can access
+                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 
+                host system, see the
+                "<link linkend='local-kernel-files'>Yocto Project Kernel</link>"
+                bulleted item earlier in the manual.
             </para>
 
             <para>
@@ -412,7 +411,9 @@
                         "<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 Build Directory created by 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.
                         If you have never built the kernel you are interested in, you need to run
                         an initial build to establish local kernel source files.</para>
@@ -428,7 +429,7 @@
                         You might want to reference this information.
                         You can find more information on BitBake in the user manual, which is found in the
                         <filename>bitbake/doc/manual</filename> directory of the
-                        <link linkend='source-directory'>Source Directory</link>.</para>
+                        Source Directory.</para>
                         <para>The build process supports several types of images to satisfy different needs.
                         See the "<ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Images</ulink>" chapter in
                         the Yocto Project Reference Manual for information on supported images.
@@ -447,10 +448,9 @@
                         Using <filename>menuconfig</filename> allows you to interactively develop and test the
                         configuration changes you are making to the kernel.
                         When saved, changes using <filename>menuconfig</filename> update the kernel's
-                        <filename>.config</filename>.
+                        <filename>.config</filename> file.
                         Try to resist the temptation of directly editing the <filename>.config</filename>
-                        file found in the
-                        <link linkend='build-directory'>Build Directory</link> at
+                        file found in the Build Directory at
                         <filename>tmp/sysroots/&lt;machine-name&gt;/kernel</filename>.
                         Doing so, can produce unexpected results when the OpenEmbedded build system
                         regenerates the configuration file.</para>
@@ -474,9 +474,11 @@
         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 Application Development Toolkit (ADT) and
-        stand-alone cross-development toolchains that
-        facilitate quick development and integration of your application into its run-time environment.
+        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>
+        that facilitate quick development and integration of your application into its runtime environment.
         Using the ADT and toolchains, you can compile and link your application.
         You can then deploy your application to the actual hardware or to the QEMU emulator for testing.
         If you are familiar with the popular <trademark class='trade'>Eclipse</trademark> IDE,
@@ -511,12 +513,12 @@
 
         <para>
             <orderedlist>
-                <listitem><para><emphasis>Prepare the Host System for the Yocto Project</emphasis>:
+                <listitem><para><emphasis>Prepare the host system for the Yocto Project</emphasis>:
                     See
                     "<ulink url='&YOCTO_DOCS_QS_URL;#the-linux-distro'>The Linux Distribution</ulink>" and
                     "<ulink url='&YOCTO_DOCS_QS_URL;#packages'>The Packages</ulink>" sections both
                     in the Yocto Project Quick Start for requirements.</para></listitem>
-                <listitem><para><emphasis>Secure the Yocto Project Kernel Target Image</emphasis>:
+                <listitem><para><emphasis>Secure the Yocto Project kernel target image</emphasis>:
                     You must have a target kernel image that has been built using the OpenEmbedded
                     build system.</para>
                     <para>Depending on whether the Yocto Project has a pre-built image that matches your target
@@ -548,14 +550,14 @@
                     The ADT provides a target-specific cross-development toolchain, the root filesystem,
                     the QEMU emulator, and other tools that can help you develop your application.
                     While it is possible to get these pieces separately, the ADT Installer provides an
-                    easy method.
+                    easy, inclusive method.
                     You can get these pieces by running an ADT installer script, which is configurable.
                     For information on how to install the ADT, see the
                     "<ulink url='&YOCTO_DOCS_ADT_URL;#using-the-adt-installer'>Using the ADT Installer</ulink>"
                     section
                     in the Yocto Project Application Developer's Guide.</para></listitem>
-                <listitem><para><emphasis>If Applicable, Secure the Target Root Filesystem
-                    and the Cross-development Toolchain</emphasis>:
+                <listitem><para><emphasis>If applicable, secure the target root filesystem
+                    and the Cross-development toolchain</emphasis>:
                     If you choose not to install the ADT using the ADT Installer,
                     you need to find and download the appropriate root filesystem and
                     the cross-development toolchain.</para>
@@ -563,7 +565,7 @@
                     for the kernel image.
                     Depending on the type of image you are running, the root filesystem you need differs.
                     For example, if you are developing an application that runs on an image that
-                    supports Sato, you need to get root filesystem that supports Sato.</para>
+                    supports Sato, you need to get a root filesystem that supports Sato.</para>
                     <para>You can find the cross-development toolchains at
                     <ulink url='&YOCTO_TOOLCHAIN_DL_URL;'><filename>toolchains</filename></ulink>.
                     Be sure to get the correct toolchain for your development host and your
@@ -576,20 +578,20 @@
                     the correct toolchain based on your host development system and your target
                     architecture.
                     </para></listitem>
-                <listitem><para><emphasis>Create and Build your Application</emphasis>:
+                <listitem><para><emphasis>Create and build your application</emphasis>:
                     At this point, you need to have source files for your application.
                     Once you have the files, you can use the Eclipse IDE to import them and build the
                     project.
                     If you are not using Eclipse, you need to use the cross-development tools you have
                     installed to create the image.</para></listitem>
-                <listitem><para><emphasis>Deploy the Image with the Application</emphasis>:
+                <listitem><para><emphasis>Deploy the image with the application</emphasis>:
                     If you are using the Eclipse IDE, you can deploy your image to the hardware or to
                     QEMU through the project's preferences.
                     If you are not using the Eclipse IDE, then you need to deploy the application
                     to the hardware using other methods.
                     Or, if you are using QEMU, you need to use that tool and load your image in for testing.
                     </para></listitem>
-                <listitem><para><emphasis>Test and Debug the Application</emphasis>:
+                <listitem><para><emphasis>Test and debug the application</emphasis>:
                     Once your application is deployed, you need to test it.
                     Within the Eclipse IDE, you can use the debugging environment along with the
                     set of user-space tools installed along with the ADT to debug your application.
@@ -617,7 +619,8 @@
             Installing and configuring the Plug-in results in an environment that
             has extensions specifically designed to let you more easily develop software.
             These extensions allow for cross-compilation, deployment, and execution of
-            your output into a QEMU emulation session.
+            your output into a QEMU emulation session as well as actual target
+            hardware.
             You can also perform cross-debugging and profiling.
             The environment also supports a suite of tools that allows you to perform
             remote profiling, tracing, collection of power data, collection of
@@ -662,7 +665,7 @@
                 </para>
 
                 <para>
-                    If you don’t have the Juno 4.2 Eclipse IDE installed, you can find the tarball at
+                    If you do not have the Juno 4.2 Eclipse IDE installed, you can find the tarball at
                     <ulink url='&ECLIPSE_MAIN_URL;'></ulink>.
                     From that site, choose the Eclipse Classic version particular to your development
                     host.
@@ -731,7 +734,7 @@
                         <listitem><para>Select <filename>Juno - &ECLIPSE_JUNO_URL;</filename>
                             from the "Work with:" pull-down menu.</para></listitem>
                         <listitem><para>Expand the box next to "Linux Tools" and select the
-                            "LTTng - Linux Tracing Toolkit" boxes.</para></listitem>
+                            <filename>LTTng - Linux Tracing Toolkit</filename> boxes.</para></listitem>
                         <listitem><para>Expand the box next to "Mobile and Device Development" and select the
                             following boxes:
                             <itemizedlist>
@@ -742,7 +745,7 @@
                                 <listitem><para><filename>TCF Remote System Explorer add-in</filename></para></listitem>
                                 <listitem><para><filename>TCF Target Explorer</filename></para></listitem>
                             </itemizedlist></para></listitem>
-                        <listitem><para>Expand the box next to <filename>Programming Languages</filename>
+                        <listitem><para>Expand the box next to "Programming Languages"
                             and select the <filename>Autotools Support for CDT</filename>
                             and <filename>C/C++ Development Tools</filename> boxes.</para></listitem>
                         <listitem><para>Complete the installation and restart the Eclipse IDE.</para></listitem>
@@ -770,11 +773,12 @@
                             </para></listitem>
                         <listitem><para>Select <filename>indigo - &ECLIPSE_INDIGO_URL;</filename>
                             from the "Work with:" pull-down menu.</para></listitem>
-                        <listitem><para>Expand the box next to <filename>Programming Languages</filename>
+                        <listitem><para>Expand the box next to "Programming Languages"
                             and select the <filename>Autotools Support for CDT (incubation)</filename>
                             and <filename>C/C++ Development Tools</filename> boxes.</para></listitem>
                         <listitem><para>Expand the box next to "Linux Tools" and select the
-                            "LTTng - Linux Tracing Toolkit(incubation)" boxes.</para></listitem>
+                            <filename>LTTng - Linux Tracing Toolkit(incubation)</filename>
+                            boxes.</para></listitem>
                         <listitem><para>Complete the installation and restart the Eclipse IDE.</para></listitem>
                         <listitem><para>After the Eclipse IDE restarts and from the Workbench, select
                             "Install New Software" from the "Help" pull-down menu.</para></listitem>
@@ -801,7 +805,7 @@
                             from the "Work with:" pull-down menu.</para></listitem>
                         <listitem><para>Check the box next to <filename>CDT Main Features</filename>.
                             </para></listitem>
-                        <listitem><para>Expand the box next to <filename>CDT Optional Features</filename>
+                        <listitem><para>Expand the box next to "CDT Optional Features"
                             and select <filename>C/C++ Remote Launch</filename> and
                             <filename>Target Communication Framework (incubation)</filename>.</para></listitem>
                         <listitem><para>Complete the installation and restart the Eclipse IDE.</para></listitem>
@@ -816,7 +820,7 @@
                     You can install the Eclipse Yocto Plug-in into the Eclipse IDE
                     one of two ways:  use the Yocto Project's Eclipse Update site to install the pre-built plug-in,
                     or build and install the plug-in from the latest source code.
-                    If you don't want to permanently install the plug-in but just want to try it out
+                    If you do not want to permanently install the plug-in but just want to try it out
                     within the Eclipse environment, you can import the plug-in project from the
                     Yocto Project's Source Repositories.
                 </para>
@@ -889,7 +893,7 @@
                                 as directed.
                                 Be sure to provide the name of the Git branch along with the
                                 Yocto Project release you are using.
-                                Here is an example that uses the <filename>&DISTRO_NAME;</filename> branches:
+                                Here is an example that uses the <filename>&DISTRO_NAME;</filename> branch:
                                 <literallayout class='monospaced'>
      $ ECLIPSE_HOME=/home/scottrif/yocto-eclipse/scripts/eclipse ./build.sh &DISTRO_NAME; &DISTRO_NAME;
                                 </literallayout>
@@ -930,6 +934,9 @@
                         It is important to understand when you import the plug-in you are not installing
                         it into the Eclipse application.
                         Rather, you are importing the project and just using it.
+                    </para>
+
+                    <para>
                         To import the plug-in project, follow these steps:
                         <orderedlist>
                             <listitem><para>Open a shell and create a Git repository with:
@@ -943,16 +950,18 @@
                                 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: "org.yocto.bc.ui", "org.yocto.sdk.ide", and
-                                "org.yocto.sdk.remotetools".
+                            <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>.
                                 Select and import all of them.</para></listitem>
                         </orderedlist>
                     </para>
 
                     <para>
                         The left navigation pane in the Eclipse application shows the default projects.
-                        Right-click on one of these projects and run it as an Eclipse application.
-                        This brings up a second instance of Eclipse IDE that has the Yocto Plug-in.
+                        Right-click on one of these projects and run it as an Eclipse application
+                        to bring up a second instance of Eclipse IDE that has the Yocto Plug-in.
                     </para>
                 </section>
             </section>
@@ -971,9 +980,10 @@
                 <para>
                     To start, you need to do the following from within the Eclipse IDE:
                     <itemizedlist>
-                        <listitem><para>Choose <filename>Windows -&gt; Preferences</filename> to display
-                            the <filename>Preferences</filename> Dialog</para></listitem>
-                        <listitem><para>Click <filename>Yocto Project ADT</filename></para></listitem>
+                        <listitem><para>Choose "Preferences" from the 
+                            "Windows" menu to display
+                            the Preferences Dialog</para></listitem>
+                        <listitem><para>Click "Yocto Project ADT"</para></listitem>
                     </itemizedlist>
                 </para>
 
@@ -1000,7 +1010,8 @@
                                        <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 Build Directory.
+                                            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
                                             inside the Build Directory.
@@ -1009,33 +1020,35 @@
                                 </para></listitem>
                             <listitem><para><emphasis>Point to the Toolchain:</emphasis>
                                 If you are using a stand-alone pre-built toolchain, you should be pointing to the
-                                <filename>&YOCTO_ADTPATH_DIR;</filename> directory.
-                                This is the location for toolchains installed by the ADT Installer or by hand.
+                                where it is installed.
+                                If you used the ADT Installer script and accepted the default
+                                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
                                 "<ulink url='&YOCTO_DOCS_ADT_URL;#using-an-existing-toolchain-tarball'>Using a Cross-Toolchain Tarball</ulink>"
                                 in the Yocto Project Application Developer's Guide
-                                describe two ways to install a stand-alone cross-toolchain in the
-                                <filename>/opt/poky</filename> directory.
-                                <note>It is possible to install a stand-alone cross-toolchain in a directory
-                                other than <filename>/opt/poky</filename>.
-                                However, doing so is discouraged.</note></para>
+                                describe how to install a stand-alone cross-toolchain.</para>
                                 <para>If you are using a system-derived toolchain, the path you provide
                                 for the <filename>Toolchain Root Location</filename>
-                                field is the Build Directory.
+                                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 the toolchain into the build
-directory.</para></listitem>
+                                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, then the location is
+                                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, the same location is used for
+                                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 install the toolchain, then the
+                                <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
-                                extracted and intalled the filesystem.</para>
+                                extracted and installed the filesystem.</para>
                                 <para>For information on how to install the toolchain and on how to extract
                                 and install the sysroot filesystem, see the
                                 "<ulink url='&YOCTO_DOCS_ADT_URL;#installing-the-adt'>Installing the ADT and Toolchains</ulink>" section.
@@ -1086,7 +1099,7 @@ directory.</para></listitem>
                                 </literallayout></para>
                                 <para>
                                 Regardless of the mode, Sysroot is already defined as part of the
-                                Cross Compiler Options configuration in the
+                                Cross-Compiler Options configuration in the
                                 <filename>Sysroot Location:</filename> field.</para></listitem>
                             <listitem><para><emphasis><filename>External HW:</filename></emphasis> Select this option
                                 if you will be using actual hardware.</para></listitem>
@@ -1094,7 +1107,7 @@ directory.</para></listitem>
                     </para>
 
                     <para>
-                        Click the <filename>OK</filename> button to save your plug-in configurations.
+                        Click the "OK" to save your plug-in configurations.
                     </para>
                 </section>
             </section>
@@ -1116,7 +1129,7 @@ directory.</para></listitem>
                 To create a project based on a Yocto template and then display the source code,
                 follow these steps:
                 <orderedlist>
-                    <listitem><para>Select <filename>File -&gt; New -&gt; Project</filename>.</para></listitem>
+                    <listitem><para>Select "Project" from the "File -> New" menu.</para></listitem>
                     <listitem><para>Double click <filename>CC++</filename>.</para></listitem>
                     <listitem><para>Double click <filename>C Project</filename> to create the project.</para></listitem>
                     <listitem><para>Expand <filename>Yocto Project ADT Project</filename>.</para></listitem>
@@ -1124,11 +1137,11 @@ directory.</para></listitem>
                         This is an Autotools-based project based on a Yocto template.</para></listitem>
                     <listitem><para>Put a name in the <filename>Project name:</filename> field.
                         Do not use hyphens as part of the name.</para></listitem>
-                    <listitem><para>Click <filename>Next</filename>.</para></listitem>
+                    <listitem><para>Click "Next".</para></listitem>
                     <listitem><para>Add information in the <filename>Author</filename> and
                         <filename>Copyright notice</filename> fields.</para></listitem>
                     <listitem><para>Be sure the <filename>License</filename> field is correct.</para></listitem>
-                    <listitem><para>Click <filename>Finish</filename>.</para></listitem>
+                    <listitem><para>Click "Finish".</para></listitem>
                     <listitem><para>If the "open perspective" prompt appears, click "Yes" so that you
                         in the C/C++ perspective.</para></listitem>
                     <listitem><para>The left-hand navigation pane shows your project.
@@ -1147,31 +1160,32 @@ directory.</para></listitem>
                 configurations.
                 You can override these settings for a given project by following these steps:
                 <orderedlist>
-                    <listitem><para>Select <filename>Project -&gt; Change Yocto Project Settings</filename>:
-                        This selection brings up the <filename>Yocot Project Settings</filename> Dialog
+                    <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.
                         </para>
                         <para>By default, the Cross Compiler Options and Target Options for a project
-                        are inherited from settings you provide using the <filename>Preferences</filename>
+                        are inherited from settings you provide using the Preferences
                         Dialog as described earlier
                         in the "<link linkend='configuring-the-eclipse-yocto-plug-in'>Configuring the Eclipse
                         Yocto Plug-in</link>" section.
-                        The <filename>Yocto Project Settings</filename>
-                        Dialog allows you to override those default settings
-                        for a given project.</para></listitem>
+                        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 <filename>Project -&gt; Reconfigure Project</filename>:
+                    <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.
                         The script also runs <filename>libtoolize</filename>, <filename>aclocal</filename>,
                         <filename>autoconf</filename>, <filename>autoheader</filename>,
                         <filename>automake --a</filename>, and
                         <filename>./configure</filename>.
-                        Click on the <filename>Console</filename> tab beneath your source code to
+                        Click on the "Console" tab beneath your source code to
                         see the results of reconfiguring your project.</para></listitem>
                 </orderedlist>
             </para>
@@ -1182,19 +1196,21 @@ directory.</para></listitem>
 
             <para>
                 To build the project in Juno, right click on the project in the navigator pane and select
-                <filename>Build Project</filename>.
-                If you are not running Juno, select <filename>Project -&gt; Build Project</filename>.
+                "Build Project".
+                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>
         </section>
 
         <section id='starting-qemu-in-user-space-nfs-mode'>
-            <title>Starting QEMU in User Space NFS Mode</title>
+            <title>Starting QEMU in User-Space NFS Mode</title>
 
             <para>
                 To start the QEMU emulator from within Eclipse, follow these steps:
                 <orderedlist>
-                    <listitem><para>Expose the <filename>Run -&gt; External Tools</filename> menu.
+                    <listitem><para>Expose and select "External Tools" from 
+                        the "Run" menu.
                         Your image should appear as a selectable menu item.
                         </para></listitem>
                     <listitem><para>Select your image from the menu to launch the
@@ -1216,33 +1232,36 @@ directory.</para></listitem>
             <title>Deploying and Debugging the Application</title>
 
             <para>
-                Once the QEMU emulator is running the image, using the Eclipse IDE
-                you can deploy your application and use the emulator to perform debugging.
+                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 <filename>Run -&gt; Debug Configurations...</filename></para></listitem>
+                    <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
-                        tabbed view in the <filename>Debug Configurations</filename> Dialog.</para></listitem>
+                        tabbed view in the Debug Configurations Dialog.</para></listitem>
                     <listitem><para>Enter the absolute path into which you want to deploy
                         the application.
-                        Use the <filename>Remote Absolute File Path for C/C++Application:</filename> field.
+                        Use the "Remote Absolute File Path for C/C++Application:" field.
                         For example, enter <filename>/usr/bin/&lt;programname&gt;</filename>.</para></listitem>
-                    <listitem><para>Click on the <filename>Debugger</filename> tab to see the cross-tool debugger
+                    <listitem><para>Click on the "Debugger" tab to see the cross-tool debugger
                         you are using.</para></listitem>
-                    <listitem><para>Click on the <filename>Main</filename> tab.</para></listitem>
+                    <listitem><para>Click on the "Main" tab.</para></listitem>
                     <listitem><para>Create a new connection to the QEMU instance
-                        by clicking on <filename>new</filename>.</para></listitem>
+                        by clicking on "new".</para></listitem>
                     <listitem><para>Select <filename>TCF</filename>, which means Target Communication
                         Framework.</para></listitem>
-                    <listitem><para>Click <filename>Next</filename>.</para></listitem>
-                    <listitem><para>Clear out the <filename>host name</filename> field and enter the IP Address
+                    <listitem><para>Click "Next".</para></listitem>
+                    <listitem><para>Clear out the "host name" field and enter the IP Address
                         determined earlier.</para></listitem>
-                    <listitem><para>Click <filename>Finish</filename> to close the
-                        <filename>New Connections</filename> Dialog.</para></listitem>
-                    <listitem><para>Use the drop-down menu now in the <filename>Connection</filename> field and pick
-                        the IP Address you entered.</para></listitem>
-                    <listitem><para>Click <filename>Run</filename> to bring up a login screen
+                    <listitem><para>Click "Finish" to close the
+                        New Connections Dialog.</para></listitem>
+                    <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
                         and login.</para></listitem>
                     <listitem><para>Accept the debug perspective.</para></listitem>
                 </orderedlist>
@@ -1257,14 +1276,14 @@ directory.</para></listitem>
                 your development experience.
                 These tools are aids in developing and debugging applications and images.
                 You can run these user-space tools from within the Eclipse IDE through the
-                <filename>YoctoTools</filename> menu.
+                "YoctoTools" menu.
             </para>
 
             <para>
                 Once you pick a tool, you need to configure it for the remote target.
                 Every tool needs to have the connection configured.
                 You must select an existing TCF-based RSE connection to the remote target.
-                If one does not exist, click <filename>New</filename> to create one.
+                If one does not exist, click "New" to create one.
             </para>
 
             <para>
@@ -1279,10 +1298,10 @@ directory.</para></listitem>
                         You must compile and install the <filename>oprofile-viewer</filename> from the source code
                         on your local host machine.
                         Furthermore, in order to convert the target's sample format data into a form that the
-                        host can use, you must have <filename>oprofile</filename> version 0.9.4 or
+                        host can use, you must have OProfile version 0.9.4 or
                         greater installed on the host.</para>
                         <para>You can locate both the viewer and server from
-                        <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/oprofileui/'></ulink>
+                        <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/oprofileui/'></ulink>.
                         You can also find more information on setting up and
                         using this tool in the
                         "<ulink url='&YOCTO_DOCS_PROF_URL;#profile-manual-oprofile'>OProfile</ulink>"
@@ -1292,64 +1311,71 @@ directory.</para></listitem>
                     <listitem><para><emphasis><filename>Lttng2.0 ust trace import</filename>:</emphasis>
                         Selecting this tool transfers the remote target's
                         <filename>Lttng</filename> tracing data back to the local host machine
-                        and uses the <filename>Lttng</filename> Eclipse plug-in to graphically
+                        and uses the Lttng Eclipse plug-in to graphically
                         display the output.
-                        For information on how to use <filename>Lttng</filename> to trace an application,
-                        see <ulink url='http://lttng.org/documentation'></ulink>.
+                        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>" 
+                        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>
                         </para>
                         <para>Before you use the <filename>Lttng2.0 ust trace import</filename> tool,
-                        you need to setup the <filename>Lttng</filename> Eclipse plug-in and create a
-                        <filename>Tracing</filename> project.
+                        you need to setup the Lttng Eclipse plug-in and create a
+                        Tracing project.
                         Do the following:
                         <orderedlist>
-                            <listitem><para>Select <filename>Window -> Open Perspective -> Other</filename>
-                                and then select <filename>Tracing</filename>.</para></listitem>
-                            <listitem><para>Click <filename>OK</filename> to change the Eclipse perspective
-                                into the <filename>Tracing</filename> perspective.</para></listitem>
-                            <listitem><para>Create a new <filename>Tracing</filename> project by selecting
-                                <filename>File -> New -> Project</filename>.</para></listitem>
-                            <listitem><para>Choose <filename>Tracing -> Tracing Project</filename>.
+                            <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 
+                                "Tracing" menu.
                                 </para></listitem>
                             <listitem><para>Generate your tracing data on the remote target.
                                 </para></listitem>
-                            <listitem><para>Click
-                                <filename>Yocto Project Tools -> Lttng2.0 ust trace import</filename>
-                                to start the data import process.</para></listitem>
+                            <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>
                             <listitem><para>For the Ust directory path, specify the location of
                                 your remote tracing data.
                                 Make sure the location ends with <filename>ust</filename> (e.g.
-                                <filename>/usr/mysession/ust</filename>.</para></listitem>
-                            <listitem><para>Click <filename>OK</filename> to complete the import process.
+                                <filename>/usr/mysession/ust</filename>).</para></listitem>
+                            <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
-                                <filename>Select Trace Type... -> Common Trace Format -> Generic CTF Trace</filename>
-                                to map the tracing type.</para></listitem>
-                            <listitem><para>Right click the mouse and select <filename>Open</filename>
-                                to bring up the Eclipse <filename>Lttng</filename> Trace Viewer so you
+                                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
                                 view the tracing data.</para></listitem>
                         </orderedlist></para></listitem>
                     <listitem><para><emphasis><filename>PowerTOP</filename>:</emphasis> Selecting this tool runs
-                        <filename>powertop</filename> on the remote target machine and displays the results in a
-                        new view called <filename>powertop</filename>.</para>
-                        <para><filename>Time to gather data(sec):</filename> is the time passed in seconds before data
+                        PowerTOP on the remote target machine and displays the results in a
+                        new view called PowerTOP.</para>
+                        <para>The "Time to gather data(sec):" field is the time passed in seconds before data
                         is gathered from the remote target for analysis.</para>
-                        <para><filename>show pids in wakeups list:</filename> corresponds to the
+                        <para>The "show pids in wakeups list:" field corresponds to the
                         <filename>-p</filename> argument
-                        passed to <filename>powertop</filename>.</para></listitem>
-                        <listitem><para><emphasis><filename>LatencyTOP and Perf</filename>:</emphasis>
-                        <filename>latencytop</filename> identifies system latency, while
-                        <filename>perf</filename> monitors the system's
-                        performance counter registers.
+                        passed to <filename>PowerTOP</filename>.</para></listitem>
+                    <listitem><para><emphasis><filename>LatencyTOP and Perf</filename>:</emphasis>
+                        LatencyTOP identifies system latency, while
+                        Perf monitors the system's performance counter registers.
                         Selecting either of these tools causes an RSE terminal view to appear
                         from which you can run the tools.
                         Both tools refresh the entire screen to display results while they run.
-                        For more informationi on setting up and using <filename>perf</filename>,
+                        For more information on setting up and using <filename>perf</filename>,
                         see the
                         "<ulink url='&YOCTO_DOCS_PROF_URL;#profile-manual-perf'>perf</ulink>"
                         section in the Yocto Project Profiling and Tracing Manual.
+                        For information on LatencyTOP, see the
+                        <ulink url='https://latencytop.org/'>LatencyTOP</ulink>
+                        website.
                         </para></listitem>
                 </itemizedlist>
             </para>
@@ -1359,9 +1385,9 @@ directory.</para></listitem>
             <title>Customizing an Image Using a BitBake Commander Project and Hob</title>
 
             <para>
-                Within Eclipse, you can create a Yocto BitBake Commander project,
-                edit the metadata, and then use the
-                <ulink url='&YOCTO_HOME_URL;/projects/hob'>Hob</ulink> to build a customized
+                Within the Eclipse IDE, you can create a Yocto BitBake Commander project,
+                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>
 
@@ -1371,31 +1397,35 @@ directory.</para></listitem>
                 <para>
                     To create a Yocto BitBake Commander project, follow these steps:
                     <orderedlist>
-                        <listitem><para>Select <filename>Window -> Open Perspective -> Other</filename>
-                            and then choose <filename>Bitbake Commander</filename>.</para></listitem>
-                        <listitem><para>Click <filename>OK</filename> to change the Eclipse perspective into the
-                            Bitbake Commander perspective.</para></listitem>
-                        <listitem><para>Select <filename>File -> New -> Project</filename> to create a new Yocto
+                        <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 <filename>Yocto Project Bitbake Commander -> New Yocto Project</filename>
-                            and click <filename>Next</filename>.</para></listitem>
+                        <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
+                            The Yocto project's Metadata files will be put under the directory
                             <filename>&lt;project_location&gt;/&lt;project_name&gt;</filename>.
                             If that directory does not exist, you need to check
                             the "Clone from Yocto Git Repository" box, which would execute a
-                            <filename>git clone</filename> command to get the project's metadata files.
+                            <filename>git clone</filename> command to get the project's Metadata files.
                             </para></listitem>
                         <listitem><para>Select <filename>Finish</filename> to create the project.</para></listitem>
                     </orderedlist>
                 </para>
             </section>
 
-            <section id='editing-the-metadata-files'>
-                <title>Editing the Metadata Files</title>
+            <section id='editing-the-metadata'>
+                <title>Editing the Metadata</title>
 
                 <para>
-                    After you create the Yocto Bitbake Commander project, you can modify the metadata files
+                    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
                     variable values and information by hovering the mouse pointer over the variable name and
@@ -1403,10 +1433,11 @@ directory.</para></listitem>
                 </para>
 
                 <para>
-                    To edit the metadata, follow these steps:
+                    To edit the Metadata, follow these steps:
                     <orderedlist>
                         <listitem><para>Select your Yocto Bitbake Commander project.</para></listitem>
-                        <listitem><para>Select <filename>File -> New -> Yocto BitBake Commander -> BitBake Recipe</filename>
+                        <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
@@ -1419,24 +1450,28 @@ directory.</para></listitem>
                             license checksum values and to auto-generate the recipe filename.</para></listitem>
                         <listitem><para>Fill in the "Description" field.</para></listitem>
                         <listitem><para>Be sure values for all required fields exist.</para></listitem>
-                        <listitem><para>Click <filename>Finish</filename>.</para></listitem>
+                        <listitem><para>Click "Finish".</para></listitem>
                     </orderedlist>
                 </para>
             </section>
 
-            <section id='buiding-and-customizing-the-image'>
-                <title>Building and Customizing the Image</title>
+            <section id='biding-and-customizing-the-image-using-hob'>
+                <title>Building and Customizing the Image Using Hob</title>
 
                 <para>
-                    To build and customize the image in Eclipse, follow these steps:
+                    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 <filename>Project -> Launch HOB</filename>.</para></listitem>
-                        <listitem><para>Enter the Build Directory where you want to put your final images.</para></listitem>
-                        <listitem><para>Click <filename>OK</filename> to launch Hob.</para></listitem>
+                        <listitem><para>Select "Launch Hob" from the "Project"
+                            menu.</para></listitem>
+                        <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>
                         <listitem><para>Use Hob to customize and build your own images.
                             For information on Hob, see the
-                            <ulink url='&YOCTO_HOME_URL;/projects/hob'>Hob Project Page</ulink> on the
+                            <ulink url='&YOCTO_HOME_URL;/tools-resources/projects/hob'>Hob Project Page</ulink> on the
                             Yocto Project website.</para></listitem>
                     </orderedlist>
                 </para>
@@ -1445,7 +1480,7 @@ directory.</para></listitem>
     </section>
 
     <section id='workflow-using-stand-alone-cross-development-toolchains'>
-        <title>Workflow Using Stand-alone Cross-development Toolchains</title>
+        <title>Workflow Using Stand-Alone Cross-Development Toolchains</title>
 
         <para>
             If you want to develop an application without prior installation
@@ -1473,7 +1508,8 @@ directory.</para></listitem>
                     support development using actual hardware.
                     For example, the area might contain
                     <filename>.hddimg</filename> files that combine the
-                    kernel image with the filesystem, boot loaders, etc.
+                    kernel image with the filesystem, boot loaders, and 
+                    so forth.
                     Be sure to get the files you need for your particular
                     development process.</para>
                     <para>If you are going to develop your application and
@@ -1660,7 +1696,7 @@ directory.</para></listitem>
      $ bitbake -c compile -f &lt;name_of_package&gt;
                     </literallayout>
                     The <filename>-f</filename> or <filename>--force</filename>
-                    option forces re-execution of the specified task.
+                    option forces the specified task to execute.
                     If you find problems with your code, you can just keep editing and
                     re-testing iteratively until things work as expected.
                     <note>All the modifications you make to the temporary source code
@@ -1677,7 +1713,7 @@ directory.</para></listitem>
                     <literallayout class='monospaced'>
      $ quilt refresh
                     </literallayout>
-                    At this point the <filename>my_changes.patch</filename> file has all your edits made
+                    At this point, the <filename>my_changes.patch</filename> file has all your edits made
                     to the <filename>file1.c</filename>, <filename>file2.c</filename>, and
                     <filename>file3.c</filename> files.</para>
                     <para>You can find the resulting patch file in the <filename>patches/</filename>
@@ -1757,7 +1793,7 @@ directory.</para></listitem>
      $ bitbake -c compile -f &lt;name_of_package&gt;
                     </literallayout>
                     The <filename>-f</filename> or <filename>--force</filename>
-                    option forces re-execution of the specified task.
+                    option forces the specified task to execute.
                     If you find problems with your code, you can just keep editing and
                     re-testing iteratively until things work as expected.
                     <note>All the modifications you make to the temporary source code
@@ -1834,17 +1870,19 @@ directory.</para></listitem>
     <title>Image Development Using Hob</title>
 
     <para>
-        The <ulink url='&YOCTO_HOME_URL;/projects/hob'>Hob</ulink> is a graphical user interface for the
+        The <ulink url='&YOCTO_HOME_URL;/tools-resources/projects/hob'>Hob</ulink> is a graphical user interface for the
         OpenEmbedded build system, which is based on BitBake.
         You can use the Hob to build custom operating system images within the Yocto Project build environment.
-        Hob simply provides a friendly interface over the build system used during system development.
+        Hob simply provides a friendly interface over the build system used during development.
         In other words, building images with the Hob lets you take care of common build tasks more easily.
     </para>
 
     <para>
         For a better understanding of Hob, see the project page at
-        <ulink url='&YOCTO_HOME_URL;/projects/hob'></ulink> on the Yocto Project website.
-        The page has a short introductory training video on Hob.
+        <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 
+        find a short introductory training video on Hob.
         The following lists some features of Hob:
         <itemizedlist>
             <listitem><para>You can setup and run Hob using these commands:
@@ -1855,9 +1893,11 @@ directory.</para></listitem>
             <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 package format used to build with,
-                the parallelism BitBake uses, whether or not to build an external toolchain, and which host
-                to build against.</para></listitem>
+            <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 
+                external toolchain, and which host to build against.
+                </para></listitem>
             <listitem><para>You can manage
                 <link linkend='understanding-and-creating-layers'>layers</link>.</para></listitem>
             <listitem><para>You can select a base image and then add extra packages for your custom build.
@@ -1895,7 +1935,7 @@ directory.</para></listitem>
     <para>
         This command spawns a terminal with a shell prompt within the OpenEmbedded build environment.
         The <ulink url='&YOCTO_DOCS_REF_URL;#var-OE_TERMINAL'><filename>OE_TERMINAL</filename></ulink>
-        controls what type of shell is opened.
+        variable controls what type of shell is opened.
     </para>
 
     <para>
@@ -1935,7 +1975,7 @@ directory.</para></listitem>
 
         <para>
             It is also worth noting that <filename>devshell</filename> still works over
-            X11 forwarding and similar situations
+            X11 forwarding and similar situations.
         </para>
     </note>
 </section>

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>
@@ -1088,9 +1088,11 @@
         The "master" branch is the “upstream” repository where the final builds of the project occur.
         The maintainer is responsible for allowing changes in from other developers and for
         organizing the underlying branch structure to reflect release strategies and so forth.
-        <note>You can see who is the maintainer for Yocto Project files by examining the
-        <filename>maintainers.inc</filename> file in the Yocto Project
-        <filename>meta-yocto/conf/distro/include</filename> directory.</note>
+        <note>For information on finding out who is responsible (maintains) 
+            for a particular area of code, see the 
+            "<link linkend='how-to-submit-a-change'>How to Submit a Change</link>"
+            section.
+        </note>
     </para>
 
     <para>
@@ -1251,6 +1253,11 @@
                 and so forth that surrounds the issue.
                 You can even attach supporting files for output from logs by 
                 using the "Add an attachment" button.</para></listitem>
+            <listitem><para>Be sure to copy the appropriate people in the 
+                "CC List" for the bug.  
+                See the "<link linkend='how-to-submit-a-change'>How to Submit a Change</link>"
+                section for information about finding out who is responsible
+                for code.</para></listitem>
             <listitem><para>Submit the bug by clicking the "Submit Bug" button.</para></listitem>
         </orderedlist>
     </para>
@@ -1265,6 +1272,46 @@
         will want to extend, configure or optimize it for their specific uses.
         You should send patches to the appropriate mailing list so that they
         can be reviewed and merged by the appropriate maintainer.
+    </para>
+
+    <para>
+        Before submitting any change, be sure to find out who you should be
+        notifying.
+        Several methods exist through which you find out who you should be copying
+        or notifying:
+        <itemizedlist>
+            <listitem><para><emphasis>Maintenance File:</emphasis>
+                Examine the <filename>maintainers.inc</filename> file, which is 
+                located in the 
+                <link linkend='source-directory'>Source Directory</link>
+                at <filename>meta-yocto/conf/distro/include</filename>, to 
+                see who is responsible for code.
+                </para></listitem>
+            <listitem><para><emphasis>Board Support Package (BSP) README Files:</emphasis>
+                For BSP maintainers of supported BSPs, you can examine 
+                individual BSP <filename>README</filename> files.
+                Alternatively, you can examine the 
+                <filename>MAINTAINERS</filename> file, which is found in the 
+                <filename>meta-intel</filename>, for a list of all supported
+                BSP maintainers.
+                </para></listitem>
+            <listitem><para><emphasis>Search by File:</emphasis>
+                Using <link linkend='git'>Git</link>, you can enter the 
+                following command to bring up a short list of all commits 
+                against a specific file:
+                <literallayout class='monospaced'>
+     git shortlog -- &lt;filename&gt;
+                </literallayout>
+                Just provide the name of the file for which you are interested.
+                The information returned is not ordered by history but does 
+                include a list of all committers grouped by name. 
+                From the list, you can see who is responsible for the bulk of
+                the changes against the file.
+                </para></listitem>
+        </itemizedlist>
+    </para>
+
+    <para>                
         For a list of the Yocto Project and related mailing lists, see the
         "<ulink url='&YOCTO_DOCS_REF_URL;#resources-mailinglist'>Mailing lists</ulink>" section in
         the Yocto Project Reference Manual.

documentation/dev-manual/dev-manual.xml

@@ -51,6 +51,16 @@
                 <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>
         </revhistory>
 
     <copyright>

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

@@ -18,26 +18,6 @@
         to help you manage the complexity of the configuration and sources
         used to support multiple BSPs and Linux kernel types.
     </para>
-
-    <para>
-        In particular, the kernel tools allow you to specify only what you
-        must, and nothing more.
-        Where a complete Linux kernel <filename>.config</filename> includes
-        all the automatically selected <filename>CONFIG</filename> options,
-        the configuration fragments only need to contain the highest level
-        visible <filename>CONFIG</filename> options as presented by the Linux
-        kernel <filename>menuconfig</filename> system.
-        This reduces your maintenance effort and allows you
-        to further separate your configuration in ways that make sense for
-        your project.
-        A common split is policy and hardware.
-        For example, all your kernels might support
-        the <filename>proc</filename> and <filename>sys</filename> filesystems,
-        but only specific boards will require sound, USB, or specific drivers.
-        Specifying these individually allows you to aggregate them
-        together as needed, but maintain them in only one place.
-        Similar logic applies to source changes.
-    </para>
 </section>
 
 <section id='using-kernel-metadata-in-a-recipe'>
@@ -50,7 +30,7 @@
         This Metadata defines Board Support Packages (BSPs) that
         correspond to definitions in linux-yocto recipes for the same BSPs.
         A BSP consists of an aggregation of kernel policy and hardware-specific
-        feature enablement.
+        feature enablements.
         The BSP can be influenced from within the linux-yocto recipe.
         <note>
             Linux kernel source that contains kernel Metadata is said to be
@@ -223,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>
@@ -807,7 +787,7 @@
             </literallayout>
             The <filename>include</filename> command midway through the file
             includes the <filename>fri2.scc</filename> description that
-            defines all hardware enablement for the BSP that is common to all
+            defines all hardware enablements for the BSP that is common to all
             kernel types.
             Using this command significantly reduces duplication.
         </para>
@@ -909,7 +889,7 @@
             if you are reusing patches from an external tree and are not
             working on the patches, you might find the encapsulated feature
             to be appropriate.
-            Given this scenario, you don't need to create any branches in the
+            Given this scenario, you do not need to create any branches in the
             source repository.
             Rather, you just take the static patches you need and encapsulate
             them within a feature description.
@@ -1049,9 +1029,8 @@
             <listitem><para><filename>branch [ref]</filename>:
                 Creates a new branch relative to the current branch
                 (typically <filename>${KTYPE}</filename>) using
-                the currently checked-out branch, or "ref" if specified.</para>
-                <para><emphasis>TODO:</emphasis> Bruce, we need to clarify
-                the "relative to the current branch" bit.</para></listitem>
+                the currently checked-out branch, or "ref" if specified.
+                </para></listitem>
             <listitem><para><filename>define</filename>:
                 Defines variables, such as <filename>KMACHINE</filename>,
                 <filename>KTYPE</filename>, <filename>KARCH</filename>,

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

@@ -34,7 +34,7 @@
             <itemizedlist>
                 <listitem><para>"<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and Creating Layers</ulink>" for
                     general information on layers and how to create layers.</para></listitem>
-                <listitem><para>"<ulink url='&YOCTO_DOCS_DEV_URL;#get-your-layer-setup-for-the-build'>Get Your Layer Setup for the Build</ulink>" for
+                <listitem><para>"<ulink url='&YOCTO_DOCS_DEV_URL;#set-up-your-layer-for-the-build'>Set Up Your Layer for the Build</ulink>" for
                     specific instructions on setting up a layer for kernel
                     development.</para></listitem>
             </itemizedlist>
@@ -69,7 +69,7 @@
             See the "<link linkend='creating-and-preparing-a-layer'>Creating and Preparing a Layer</link>"
             section for some general resources.
             You can also see the
-            "<ulink url='&YOCTO_DOCS_DEV_URL;#get-your-layer-setup-for-the-build'>Get Your Layer Setup for the Build</ulink>" section
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#set-up-your-layer-for-the-build'>Set Up Your Layer for the Build</ulink>" section
             of the Yocto Project Development Manual for a detailed
             example.
         </para>
@@ -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,19 +152,31 @@
                 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 <filename>SRC_URI</filename>.
+                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 the
-                <filename>${</filename><ulink url='&YOCTO_DOCS_REF_URL;#var-FILES'><filename>FILES</filename></ulink><filename>}</filename>
-                directory within your layer and name it "defconfig".
-                Then, add the following line to your linux-yocto
+                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:
                 <literallayout class='monospaced'>
+     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
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></ulink>
+                extends the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESPATH'><filename>FILESPATH</filename></ulink>
+                variable (search directories) to include the
+                <filename>files</filename> directory you created for the
+                configuration changes.
             </para>
 
             <para>
@@ -170,7 +185,7 @@
                 configuration fragment.
                 For example, if you want to add support for a basic serial
                 console, create a file named <filename>8250.cfg</filename> in the
-                <filename>${FILES}</filename> directory with the following
+                <filename>files</filename> directory with the following
                 content (without indentation):
                 <literallayout class='monospaced'>
      CONFIG_SERIAL_8250=y
@@ -181,10 +196,11 @@
      CONFIG_SERIAL_CORE=y
      CONFIG_SERIAL_CORE_CONSOLE=y
                 </literallayout>
-                Next, include this configuration fragment in a
-                <filename>SRC_URI</filename> statement 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:"
      SRC_URI += "file://8250.cfg"
                 </literallayout>
                 The next time you run BitBake to build the Linux kernel, BitBake
@@ -371,7 +387,7 @@
 
      WARNING: There were 2 hardware options requested that do not
               have a corresponding value present in the final ".config" file.
-              This probably means you aren't getting the config you wanted.
+              This probably means you are not't getting the config you wanted.
               The full list can be found in your kernel src dir at:
               meta/cfg/standard/mybsp/mismatch.cfg
                 </literallayout>
@@ -725,7 +741,7 @@
             "What changes have been applied to this tree?"
             Rather than using "grep" across directories to see what has
             changed, you can use Git to inspect or search the kernel tree.
-            Using Git is an efficent way to see what has changed in the tree.
+            Using Git is an efficient way to see what has changed in the tree.
         </para>
 
         <section id='what-changed-in-a-kernel'>
@@ -766,7 +782,7 @@
             </para>
 
             <para>
-                To see short, oneline summaries of changes use the
+                To see short, one line summaries of changes use the
                 <filename>git log</filename> command:
                 <literallayout class='monospaced'>
      $ git log --oneline origin/standard/base..origin/standard/emenlow

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

@@ -132,7 +132,7 @@
                 The "Yocto Project Baseline Kernel" contains functionality that is common to every kernel
                 type and BSP that is organized further up the tree.
                 Placing these common features in the
-                tree this way means features don't have to be duplicated along individual branches of the
+                tree this way means features do not have to be duplicated along individual branches of the
                 structure.
             </para>
             <para>

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

@@ -14,8 +14,8 @@
             <ulink url='&YOCTO_GIT_URL;/cgit.cgi'>&YOCTO_GIT_URL;/cgit.cgi</ulink>
             and can be shipped as part of a Yocto Project release.
             The team creates these repositories by
-            compiling and executing the set of feature descriptions for every BSP/feature
-            in the product.
+            compiling and executing the set of feature descriptions for every BSP
+            and feature in the product.
             Those feature descriptions list all necessary patches,
             configuration, branching, tagging and feature divisions found in a kernel.
             Thus, the Yocto Project kernel repository (or tree) is built.
@@ -59,8 +59,6 @@
             particular kernel branch.
             Instead, you should use Git directly to discover the changes in a branch.
             Using Git is an efficient and flexible way to inspect changes to the kernel.
-            For examples showing how to use Git to inspect kernel commits, see the following sections
-            in this chapter.
             <note>
                 Ground up reconstruction of the complete kernel tree is an action only taken by the
                 Yocto Project team during an active development cycle.
@@ -210,7 +208,9 @@
             the build tree directory.
             The files include the final <filename>.config</filename> file, all the <filename>.o</filename>
             files, the <filename>.a</filename> files, and so forth.
-            Since each machine or BSP has its own separate build directory in its own separate branch
+            Since each machine or BSP has its own separate 
+            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
+            in its own separate branch
             of the Git repository, you can easily switch between different builds.
         </para>
     </section>

documentation/kernel-dev/kernel-dev.xml

@@ -36,6 +36,16 @@
                 <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>
         </revhistory>
 
     <copyright>

documentation/poky.ent

@@ -1,7 +1,9 @@
-<!ENTITY DISTRO "1.4">
+<!ENTITY DISTRO "1.4.2">
+<!ENTITY DISTRO_COMPRESSED "142">
 <!ENTITY DISTRO_NAME "dylan">
-<!ENTITY YOCTO_DOC_VERSION "1.4">
-<!ENTITY POKYVERSION "9.0">
+<!ENTITY YOCTO_DOC_VERSION "1.4.2">
+<!ENTITY POKYVERSION "9.0.2">
+<!ENTITY POKYVERSION_COMPRESSED "902">
 <!ENTITY YOCTO_POKY "poky-&DISTRO_NAME;-&POKYVERSION;">
 <!ENTITY COPYRIGHT_YEAR "2010-2013">
 <!ENTITY YOCTO_DL_URL "http://downloads.yoctoproject.org">
@@ -12,6 +14,7 @@
 <!ENTITY YOCTO_AB_URL "http://autobuilder.yoctoproject.org">
 <!ENTITY YOCTO_GIT_URL "http://git.yoctoproject.org">
 <!ENTITY YOCTO_ADTREPO_URL "http://adtrepo.yoctoproject.org">
+<!ENTITY YOCTO_RELEASE_NOTES "&YOCTO_HOME_URL;/download/yocto-project-&DISTRO_COMPRESSED;-poky-&POKYVERSION_COMPRESSED;">
 <!ENTITY OE_HOME_URL "http://www.openembedded.org">
 <!ENTITY OE_LISTS_URL "http://lists.linuxtogo.org/cgi-bin/mailman">
 <!ENTITY OE_DOCS_URL "http://docs.openembedded.org">
@@ -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.xml

@@ -36,6 +36,16 @@
                 <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>
         </revhistory>
 
     <copyright>

documentation/ref-manual/faq.xml

@@ -173,7 +173,8 @@
                 (<filename>.deb</filename>), or RPM.
                 You can then upgrade the packages using the package tools on 
                 the device, much like on a desktop distribution such as 
-                Ubuntu or Fedora.
+                Ubuntu or Fedora. 
+                However, package management on the target is entirely optional.
             </para>
         </answer>
     </qandaentry>
@@ -364,7 +365,7 @@
                 data that causes lots of network, disk and CPU activity and 
                 is sensitive to even single-bit failures in any of these areas.
                 True random failures have always been traced back to hardware 
-                or visualization issues.
+                or virtualization issues.
             </para>
         </answer>
     </qandaentry>

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>
@@ -103,10 +103,9 @@
         <para>
             Currently, the Yocto Project is supported on the following distributions:
             <itemizedlist>
-                <listitem><para>Ubuntu 10.04.4 LTS</para></listitem>
+                <listitem><para>Ubuntu 10.04</para></listitem>
                 <listitem><para>Ubuntu 11.10</para></listitem>
-                <listitem><para>Ubuntu 12.04.1 LTS</para></listitem>
-                <listitem><para>Ubuntu 12.04.1 LTS</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>
@@ -115,10 +114,13 @@
                 <listitem><para>CentOS release 5.7 (Final)</para></listitem>
                 <listitem><para>CentOS release 5.8 (Final)</para></listitem>
                 <listitem><para>CentOS release 6.3 (Final)</para></listitem>
-                <listitem><para>Debian GNU/Linux 6.0.6 (squeeze)</para></listitem>
+                <listitem><para>CentOS release 6.4 (Final)</para></listitem>
+                <listitem><para>Debian GNU/Linux 6.0 (squeeze)</para></listitem>
+                <listitem><para>Debian GNU/Linux 7.0</para></listitem>
                 <listitem><para>openSUSE 11.4</para></listitem>
                 <listitem><para>openSUSE 12.1</para></listitem>
                 <listitem><para>openSUSE 12.2</para></listitem>
+                <listitem><para>openSUSE 12.3</para></listitem>
             </itemizedlist>
         </para>
 

documentation/ref-manual/migration.xml

@@ -258,8 +258,8 @@
                     The runtime package specific variables 
                     <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>,
                     <link linkend='var-RRECOMMENDS'><filename>RRECOMMENDS</filename></link>,
-                    <filename>RSUGGESTS</filename>, 
-                    <filename>RPROVIDES</filename>,
+                    <link linkend='var-RSUGGESTS'><filename>RSUGGESTS</filename></link>, 
+                    <link linkend='var-RPROVIDES'><filename>RPROVIDES</filename></link>,
                     <link linkend='var-RCONFLICTS'><filename>RCONFLICTS</filename></link>,
                     <link linkend='var-RREPLACES'><filename>RREPLACES</filename></link>,
                     <link linkend='var-FILES'><filename>FILES</filename></link>,
@@ -310,9 +310,13 @@
                     you previously added to <filename>OVERRIDES</filename>,
                     you might now need to add it to 
                     <filename>FILESOVERRIDES</filename> unless you are already 
-                    adding it through the <filename>MACHINEOVERRIDES</filename> 
-                    or <filename>DISTROOVERRIDES</filename> variables, 
-                    as appropriate.
+                    adding it through the 
+                    <link linkend='var-MACHINEOVERRIDES'><filename>MACHINEOVERRIDES</filename></link> 
+                    or <link linkend='var-DISTROOVERRIDES'><filename>DISTROOVERRIDES</filename></link>
+                    variables, as appropriate.
+                    For more related changes, see the
+                    "<link linkend='migration-1.4-variables'>Variables</link>"
+                    section.
                     </para></listitem>
             </itemizedlist>
         </para>
@@ -331,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>
 
@@ -350,14 +372,54 @@
         <title>Variables</title>
 
         <para>
-            The <filename>SANITY_TESTED_DISTROS</filename> variable now uses a
-            distribution ID, which is composed of the host distributor ID 
-            followed by the release.
-            Previously, it was composed of the description field.
-            For example, "Ubuntu 12.10" becomes "Ubuntu-12.10". 
-            You do not need to worry about this change if you are not 
-            specifically setting this variable, or if you are
-            specifically setting it to "".
+            The following variables have changed:
+            <itemizedlist>
+                <listitem><para><emphasis><filename>SANITY_TESTED_DISTROS</filename>:</emphasis>
+                    This variable now uses a distribution ID, which is composed 
+                    of the host distributor ID followed by the release.
+                    Previously, 
+                    <link linkend='var-SANITY_TESTED_DISTROS'><filename>SANITY_TESTED_DISTROS</filename></link>
+                    was composed of the description field.
+                    For example, "Ubuntu 12.10" becomes "Ubuntu-12.10". 
+                    You do not need to worry about this change if you are not 
+                    specifically setting this variable, or if you are
+                    specifically setting it to "".
+                    </para></listitem>
+                <listitem><para><emphasis><filename>SRC_URI</filename>:</emphasis>
+                    The <filename>${</filename><link linkend='var-PN'><filename>PN</filename></link><filename>}</filename>, 
+                    <filename>${</filename><link linkend='var-PF'><filename>PF</filename></link><filename>}</filename>, 
+                    <filename>${</filename><link linkend='var-P'><filename>P</filename></link><filename>}</filename>, 
+                    and <filename>FILE_DIRNAME</filename> directories have been 
+                    dropped from the default value of the 
+                    <link linkend='var-FILESPATH'><filename>FILESPATH</filename></link>
+                    variable, which is used as the search path for finding files 
+                    referred to in 
+                    <link linkend='var-SRC_URI'><filename>SRC_URI</filename></link>. 
+                    If you have a recipe that relied upon these directories, 
+                    which would be unusual, then you will need to add the 
+                    appropriate paths within the recipe or, alternatively,
+                    rearrange the files. 
+                    The most common locations are still covered by 
+                    <filename>${BP}</filename>, <filename>${BPN}</filename>,
+                    and "files", which all remain in the default value of
+                    <link linkend='var-FILESPATH'><filename>FILESPATH</filename></link>. 
+                    </para></listitem>
+            </itemizedlist>           
+        </para>
+    </section>
+
+    <section id='migration-target-package-management-with-rpm'>
+        <title>Target Package Management with RPM</title>
+
+        <para>
+            If runtime package management is enabled and the RPM backend 
+            is selected, Smart is now installed for package download, dependency 
+            resolution, and upgrades instead of Zypper.
+            For more information on how to use Smart, run the following command 
+            on the target:
+            <literallayout class='monospaced'>
+     smart --help
+            </literallayout>
         </para>
     </section>
 

documentation/ref-manual/ref-classes.xml

@@ -17,7 +17,7 @@
     <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
     Class files can also be pointed to by
     <link linkend='var-BUILDDIR'><filename>BUILDDIR</filename></link>
-    (e.g. <filename>build/</filename>)in the same way as
+    (e.g. <filename>build/</filename>) in the same way as
     <filename>.conf</filename> files in the <filename>conf</filename> directory.
     Class files are searched for in <link linkend='var-BBPATH'><filename>BBPATH</filename></link>
     using the same method by which <filename>.conf</filename> files are searched.
@@ -171,7 +171,7 @@
     <para>
         This class renames packages so that they follow the Debian naming
         policy (i.e. <filename>eglibc</filename> becomes <filename>libc6</filename>
-        and <filename>eglibc-devel</filename> becomes <filename>libc6-dev</filename>.
+        and <filename>eglibc-devel</filename> becomes <filename>libc6-dev</filename>.)
     </para>
 </section>
 
@@ -179,9 +179,10 @@
     <title>Pkg-config - <filename>pkgconfig.bbclass</filename></title>
 
     <para>
-        <filename>pkg-config</filename> brought standardization and this class
-        aims to smooth integration of <filename>pkg-config</filename>
-        into libraries that use it.
+        <filename>pkg-config</filename> provides a standard way to get 
+        header and library information.
+        This class aims to smooth integration of
+        <filename>pkg-config</filename> into libraries that use it.
     </para>
 
     <para>
@@ -192,37 +193,26 @@
     </para>
 </section>
 
-<section id='ref-classes-src-distribute'>
-    <title>Distribution of Sources - <filename>src_distribute_local.bbclass</filename></title>
+<section id='ref-classes-archiver'>
+    <title>Archiving Sources - <filename>archive*.bbclass</filename></title>
 
     <para>
-        Many software licenses require that source files be provided along with the binaries.
-        To simplify this process, two classes were created:
-        <filename>src_distribute.bbclass</filename> and
-        <filename>src_distribute_local.bbclass</filename>.
-    </para>
-
-    <para>
-        The results of these classes are <filename>tmp/deploy/source/</filename>
-        subdirectories with sources sorted by
-        <filename><link linkend='var-LICENSE'>LICENSE</link></filename> field.
-        If recipes list few licenses (or have entries like "Bitstream Vera"),
-        the source archive is placed in each license directory.
-    </para>
-
-    <para>
-        This class operates using three modes:
+        Many software licenses require that source code and other materials be
+        released with the binaries. 
+        To help with that task, the following classes are provided:
         <itemizedlist>
-            <listitem><para><emphasis>copy:</emphasis> Copies the files to the
-                distribution directory.</para></listitem>
-            <listitem><para><emphasis>symlink:</emphasis> Creates symbolic
-                links for the files to the distribution directory.
-                </para></listitem>
-            <listitem><para><emphasis>move+symlink:</emphasis> Moves the files
-                into the distribution directory and then creates symbolic
-                links back to where they originated.</para></listitem>
+            <listitem><filename>archive-original-sources.bbclass</filename></listitem>
+            <listitem><filename>archive-patched-sources.bbclass</filename></listitem>
+            <listitem><filename>archive-configured-sources.bbclass</filename></listitem>
+            <listitem><filename>archiver.bbclass</filename></listitem>
         </itemizedlist>
     </para>
+
+    <para>
+        For more details on the source archiver, see the
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#maintaining-open-source-license-compliance-during-your-products-lifecycle'>Maintaining Open Source License Compliance During Your Product's Lifecycle</ulink>"
+        section in the Yocto Project Development Manual.
+    </para>
 </section>
 
 <section id='ref-classes-perl'>
@@ -435,8 +425,8 @@
     <title>Host System Sanity Checks - <filename>sanity.bbclass</filename></title>
 
     <para>
-        This class checks to see if prerequisite software is present so that
-        users can be notified of potential problems that might affect their build.
+        This class checks to see if prerequisite software is present on the host system
+        so that users can be notified of potential problems that might affect their build.
         The class also performs basic user configuration checks from
         the <filename>local.conf</filename> configuration file to
         prevent common mistakes that cause build failures.
@@ -524,6 +514,54 @@
                 Any <filename>.pc</filename> file containing these paths is incorrect
                 since <filename>pkg-config</filename> itself adds the correct sysroot prefix
                 when the files are accessed.</para></listitem>
+            <listitem><para><emphasis><filename>textrel:</filename></emphasis>
+                Checks for ELF binaries that contain relocations in their 
+                <filename>.text</filename> sections, which can result in a 
+                performance impact at runtime.</para></listitem>
+            <listitem><para><emphasis><filename>pkgvarcheck:</filename></emphasis>
+                Checks through the variables 
+                <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>, 
+                <link linkend='var-RRECOMMENDS'><filename>RRECOMMENDS</filename></link>, 
+                <link linkend='var-RSUGGESTS'><filename>RSUGGESTS</filename></link>,
+                <link linkend='var-RCONFLICTS'><filename>RCONFLICTS</filename></link>,
+                <link linkend='var-RPROVIDES'><filename>RPROVIDES</filename></link>,
+                <link linkend='var-RREPLACES'><filename>RREPLACES</filename></link>, 
+                <link linkend='var-FILES'><filename>FILES</filename></link>,
+                <link linkend='var-ALLOW_EMPTY'><filename>ALLOW_EMPTY</filename></link>,
+                <filename>pkg_preinst</filename>, 
+                <filename>pkg_postinst</filename>, 
+                <filename>pkg_prerm</filename>
+                and <filename>pkg_postrm</filename>, and reports if there are 
+                variable sets that are not package-specific.
+                Using these variables without a package suffix is bad practice,
+                and might unnecessarily complicate dependencies of other packages
+                within the same recipe or have other unintended consequences.
+                </para></listitem>
+            <listitem><para><emphasis><filename>xorg-driver-abi:</filename></emphasis>
+                Checks that all packages containing Xorg drivers have ABI 
+                dependencies.
+                The <filename>xserver-xorg</filename> recipe provides driver 
+                ABI names.
+                All drivers should depend on the ABI versions that they have 
+                been built against. 
+                Driver recipes that include 
+                <filename>xorg-driver-input.inc</filename>
+                or <filename>xorg-driver-video.inc</filename> will 
+                automatically get these versions.
+                Consequently, you should only need to explicitly add 
+                dependencies to binary driver recipes.
+                </para></listitem>
+            <listitem><para><emphasis><filename>libexec:</filename></emphasis>
+                Checks if a package contains files in 
+                <filename>/usr/libexec</filename>.
+                This check is not performed if the 
+                <filename>libexecdir</filename> variable has been set 
+                explicitly to <filename>/usr/libexec</filename>.
+                </para></listitem>
+            <listitem><para><emphasis><filename>staticdev:</filename></emphasis>
+                Checks for static library files (<filename>*.a</filename>) in
+                non-<filename>staticdev</filename> packages.
+                </para></listitem>
             <listitem><para><emphasis><filename>la:</filename></emphasis>
                 Checks <filename>.la</filename> files for any <filename>TMPDIR</filename>
                 paths.
@@ -536,8 +574,63 @@
                 the specification for <filename>.desktop</filename> files.</para></listitem>
         </itemizedlist>
     </para>
+    <note>
+        You can use the <filename>WARN_QA</filename> and 
+        <filename>ERROR_QA</filename> variables to control the behavior of 
+        these checks at the global level (i.e. in your custom distro 
+        configuration).
+        However, to skip one or more checks in recipes, you should use 
+        <link linkend='var-INSANE_SKIP'><filename>INSANE_SKIP</filename></link>. 
+        For example, to skip the check for symbolic link 
+        <filename>.so</filename> files in the main package of a recipe, 
+        add the following to the recipe.
+        You need to realize that the package name override, in this example
+        <filename>${PN}</filename>, must be used:
+        <literallayout class='monospaced'>
+     INSANE_SKIP_${PN} += "dev-so"
+        </literallayout>
+        Please keep in mind that the QA checks exist in order to detect real 
+        or potential problems in the packaged output.
+        So exercise caution when disabling these checks.
+    </note>
 </section>
 
+<section id='ref-classes-rm-work'>
+    <title>Removing Work Files During the Build - <filename>rm_work.bbclass</filename></title>
+
+    <para>
+        The OpenEmbedded build system can use a substantial amount of disk 
+        space during the build process.
+        A portion of this space is the work files under the 
+        <filename>${TMPDIR}/work</filename> directory for each recipe. 
+        Once the build system generates the packages for a recipe, the work 
+        files for that recipe are no longer needed.
+        However, by default, the build system preserves these files
+        for inspection and possible debugging purposes.
+        If you would rather have these files deleted to save disk space 
+        as the build progresses, you can enable <filename>rm_work</filename>
+        by adding the following to your <filename>local.conf</filename> file,
+        which is found in the 
+        <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
+        <literallayout class='monospaced'>
+    INHERIT += "rm_work"
+        </literallayout>
+        If you are modifying and building source code out of the work directory 
+        for a recipe, enabling <filename>rm_work</filename> will potentially 
+        result in your changes to the source being lost. 
+        To exclude some recipes from having their work directories deleted by
+        <filename>rm_work</filename>, you can add the names of the recipe or 
+        recipes you are working on to the <filename>RM_WORK_EXCLUDE</filename> 
+        variable, which can also be set in your <filename>local.conf</filename>
+        file.
+        Here is an example:
+        <literallayout class='monospaced'>
+    RM_WORK_EXCLUDE += "busybox eglibc"
+        </literallayout>
+    </para>
+</section>
+
+
 <section id='ref-classes-siteinfo'>
     <title>Autotools Configuration Data Cache - <filename>siteinfo.bbclass</filename></title>
 
@@ -681,12 +774,16 @@
         deploy.bbclass
         distrodata.bbclass
         dummy.bbclass
+        fontcache.bbclass
         gconf.bbclass
         gettext.bbclass
         gnomebase.bbclass
         gnome.bbclass
+        grub-efi.bbclass
+        gsettings.bbclass
         gtk-doc.bbclass
         gtk-icon-cache.bbclass
+        gtk-immodules-cache.bbclass
         gzipnative.bbclass
         icecc.bbclass
         image-empty.bbclass
@@ -708,6 +805,7 @@
         logging.bbclass
         meta.bbclass
         metadata_scm.bbclass
+        migrate_localcount.bbclass
         mime.bbclass
         mirrors.bbclass
         multilib*.bbclass
@@ -719,12 +817,14 @@
         packageinfo.bbclass
         patch.bbclass
         perlnative.bbclass
+        pixbufcache.bbclass
         pkg_distribute.bbclass
         pkg_metainfo.bbclass
         populate_sdk*.bbclass
         prexport.bbclass
         primport.bbclass
         prserv.bbclass
+        ptest.bbclass
         python-dir.bbclass
         pythonnative.bbclass
         qemu.bbclass
@@ -732,7 +832,6 @@
         qt4*.bbclass
         recipe_sanity.bbclass
         relocatable.bbclass
-        rm_work.bbclass
         scons.bbclass
         sdl.bbclass
         setuptools.bbclass
@@ -742,6 +841,7 @@
         sstate.bbclass
         staging.bbclass
         syslinux.bbclass
+        systemd.bbclass
         terminal.bbclass
         tinderclient.bbclass
         toolchain-scripts.bbclass

documentation/ref-manual/ref-manual.xml

@@ -67,6 +67,16 @@
                 <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>
         </revhistory>
 
     <copyright>

documentation/ref-manual/ref-variables.xml

@@ -100,7 +100,7 @@
                     By default, this directory is the same as the <link linkend='var-S'><filename>S</filename></link>
                     directory:
                     <literallayout class='monospaced'>
-     B = ${WORKDIR}/${BPN}/{PV}/
+     B = "${WORKDIR}/${BPN}/{PV}/"
                     </literallayout>
                     You can separate the (<filename>S</filename>) directory and the directory pointed to
                     by the <filename>B</filename> variable.
@@ -598,16 +598,35 @@ Core layer for images cannot be removed
             </glossdef>
         </glossentry>
 
+        <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
+                    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
+                    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
+                    compatible with the current system.</para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-COMPATIBLE_MACHINE'><glossterm>COMPATIBLE_MACHINE</glossterm>
             <glossdef>
-                <para>A regular expression that evaluates to match the machines
-                    with which the recipe works.
-                    You can use the variable to stop recipes from being run
-                    on machines for which they are not compatible.
-                    This is particularly useful with kernels.
-                    The variable also helps to increase parsing speed as
-                    further parsing of the recipe is skipped if it is found
-                    the current machine is not compatible.</para>
+                <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
+                    since the build system skips parsing recipes not
+                    compatible with the current machine.</para>
             </glossdef>
         </glossentry>
 
@@ -723,7 +742,25 @@ Core layer for images cannot be removed
 
         <glossentry id='var-DEFAULT_PREFERENCE'><glossterm>DEFAULT_PREFERENCE</glossterm>
             <glossdef>
-                <para>Specifies the priority of recipes.</para>
+                <para>
+                    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
+                    piece of software.
+                    Using the variable in this way causes the stable version
+                    of the recipe to build by default in the absence of
+                    <filename><link linkend='var-PREFERRED_VERSION'>PREFERRED_VERSION</link></filename>
+                    being used to build the development version.
+                </para>
+                <note>
+                    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
+                    that contain different versions of the same recipe.
+                </note>
             </glossdef>
         </glossentry>
 
@@ -869,6 +906,22 @@ Core layer for images cannot be removed
             </glossdef>
         </glossentry>
 
+        <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
+                    <filename><link linkend='var-DISTRO'>DISTRO</link></filename>
+                    variable.
+                    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.
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-DL_DIR'><glossterm>DL_DIR</glossterm>
             <glossdef>
                 <para>
@@ -1103,42 +1156,68 @@ Core layer for images cannot be removed
             <glossdef>
                 <para>
                     Extends the search path the OpenEmbedded build system uses
-                    when looking for files and patches as it processes recipes.
-                    The directories BitBake uses when it processes recipes are
-                    defined by the
-                    <link linkend='var-FILESPATH'><filename>FILESPATH</filename></link> variable.
-                    You can add directories to the search path by defining the
-                    <filename>FILESEXTRAPATHS</filename> variable.
+                    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
+                    <link linkend='var-FILESPATH'><filename>FILESPATH</filename></link>
+                    variable, and can be extended using
+                    <filename>FILESEXTRAPATHS</filename>.
                 </para>
 
                 <para>
-                    To add paths to the front of the search order, prepend
-                    them and use the immediate expansion
-                    (<filename>:=</filename>) operator.
-                    Provide a list of directories and separate
-                    each path using a colon character as follows:
-                    <literallayout class='monospaced'>
-     FILESEXTRAPATHS_prepend := "path_1:path_2:path_3:"
-                    </literallayout>
-                    You can add paths to the end of the search order by simply
-                    adding them as follows:
-                    <literallayout class='monospaced'>
-     FILESEXTRAPATHS := "path_1:path_2:path_3:"
-                    </literallayout>
-                    To maintain the integrity of the
-                    <filename>FILESPATH</filename> variable, you must include
-                    the appropriate beginning or ending (as needed) colon
-                    character.
-                </para>
-
-                <para>
-                    The <filename>FILESEXTRAPATHS</filename> variable is
-                    intended for use in <filename>.bbappend</filename> files
-                    to include any additional files provided in that layer.
-                    You typically accomplish this with the following:
+                    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}:"
                     </literallayout>
+                    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
+                    <filename>FILESPATH</filename> variable to include a
+                    directory named <filename>files</filename> that is in the
+                    same directory as the corresponding append file.
+                </para>
+
+                <para>
+                    Here is a final example that specifically adds three paths:
+                    <literallayout class='monospaced'>
+     FILESEXTRAPATHS_prepend := "path_1:path_2:path_3:"
+                    </literallayout>
+                </para>
+
+                <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
+                    correctly extend the path.
+                    <note>
+                        Be sure to use the immediate expansion
+                        (<filename>:=</filename>) operator and include
+                        the trailing separating colon character.
+                    </note>
                 </para>
             </glossdef>
         </glossentry>
@@ -1146,26 +1225,37 @@ 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 uses
-                    when searching for patches and files.
+                    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>file://</filename> URI in a recipe.
+                    <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> class found in
-                    <filename>meta/classes</filename> in the
+                    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'>
      FILESPATH = "${@base_set_filespath(["${FILE_DIRNAME}/${BP}", \
         "${FILE_DIRNAME}/${BPN}", "${FILE_DIRNAME}/files"], d)}"
                     </literallayout>
-                    Do not hand-edit the <filename>FILESPATH</filename> variable.
-                    If you want to extend the set of pathnames that BitBake uses when searching for
-                    files and patches, use the
-                    <link linkend='var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></link> variable.
+                    <note>
+                        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>)
+                    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>
+                    variable.
                 </para>
             </glossdef>
         </glossentry>
@@ -1229,6 +1319,34 @@ Core layer for images cannot be removed
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-HOST_SYS'><glossterm>HOST_SYS</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the system, including the architecture and the
+                    operating system, for with the build is occurring
+                    in the context of the current
+                    recipe.
+                    The OpenEmbedded build system automatically sets this
+                    variable.
+                    You do not need to set the variable yourself.
+                </para>
+
+                <para>
+                    Here are two examples:
+                    <itemizedlist>
+                        <listitem><para>Given a native recipe on a 32-bit
+                            x86 machine running Linux, the value is
+                            "i686-linux".
+                            </para></listitem>
+                        <listitem><para>Given a recipe being built for a
+                            little-endian MIPS target running Linux,
+                            the value might be "mipsel-linux".
+                            </para></listitem>
+                    </itemizedlist>
+                </para>
+            </glossdef>
+        </glossentry>
+
     </glossdiv>
 
     <glossdiv id='var-glossary-i'><title>I</title>
@@ -1312,6 +1430,35 @@ Core layer for images cannot be removed
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-IMAGE_LINGUAS'><glossterm>IMAGE_LINGUAS</glossterm>
+            <glossdef>
+                <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.
+                    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.
+                    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.
+                    <filename>*-locale-pt-br</filename>
+                    and <filename>*-locale-de-de</filename> as well as
+                    <filename>*-locale-pt</filename>
+                    and <filename>*-locale-de</filename>, since some software
+                    packages only provide locale files by language and not by
+                    country-specific language).
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-IMAGE_OVERHEAD_FACTOR'><glossterm>IMAGE_OVERHEAD_FACTOR</glossterm>
             <glossdef>
                 <para>
@@ -1476,7 +1623,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
         <glossentry id='var-INHIBIT_PACKAGE_STRIP'><glossterm>INHIBIT_PACKAGE_STRIP</glossterm>
             <glossdef>
                 <para>
-                    Causes the build to not strip binaries in resulting packages.
+                    If set to "1", causes the build to not strip binaries in resulting packages.
                 </para>
             </glossdef>
         </glossentry>
@@ -1538,6 +1685,28 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-INSANE_SKIP'><glossterm>INSANE_SKIP</glossterm>
+            <glossdef>
+                <para>
+                    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
+                    recipe, add the following to the recipe.
+                    The package name override must be used, which in this
+                    example is <filename>${PN}</filename>:
+                    <literallayout class='monospaced'>
+     INSANE_SKIP_${PN} += "dev-so"
+                    </literallayout>
+                </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
+                    specify using this variable.
+                </para>
+            </glossdef>
+        </glossentry>
+
 
     </glossdiv>
 
@@ -1635,6 +1804,16 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-KERNEL_EXTRA_ARGS'><glossterm>KERNEL_EXTRA_ARGS</glossterm>
+            <glossdef>
+                <para>
+                    Specifies additional <filename>make</filename>
+                    command-line arguments the OpenEmbedded build system
+                    passes on when compiling the kernel.
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-KERNEL_FEATURES'><glossterm>KERNEL_FEATURES</glossterm>
             <glossdef>
                 <para>Includes additional metadata from the Yocto Project kernel Git repository.
@@ -2033,6 +2212,21 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-LOG_DIR'><glossterm>LOG_DIR</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the directory to which the OpenEmbedded build
+                    system writes overall log files.
+                    The default directory is <filename>${TMPDIR}/log</filename>.
+                </para>
+                <para>
+                    For the directory containing logs specific to each task,
+                    see the <link linkend='var-T'><filename>T</filename></link>
+                    variable.
+                </para>
+            </glossdef>
+        </glossentry>
+
     </glossdiv>
 
     <glossdiv id='var-glossary-m'><title>M</title>
@@ -2293,6 +2487,35 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-MACHINEOVERRIDES'><glossterm>MACHINEOVERRIDES</glossterm>
+            <glossdef>
+                <para>
+                    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
+                    classes of machines.
+                    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
+                    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
+                    <filename>connman-conf</filename> recipe:
+                    <literallayout class='monospaced'>
+    SRC_URI_append_qemuall = "file://wired.config \
+                              file://wired-setup \
+                             "
+                    </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-MAINTAINER'><glossterm>MAINTAINER</glossterm>
             <glossdef>
                 <para>The email address of the distribution maintainer.</para>
@@ -2339,6 +2562,18 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-MODULE_TARBALL_DEPLOY'><glossterm>MODULE_TARBALL_DEPLOY</glossterm>
+            <glossdef>
+                <para>
+                    Controls creation of the <filename>modules-*.tgz</filename>
+                    file.
+                    Set this variable to "0" to disable creation of this
+                    file, which contains all of the kernel modules resulting
+                    from a kernel build.
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-MULTIMACH_TARGET_SYS'><glossterm>MULTIMACH_TARGET_SYS</glossterm>
             <glossdef>
                 <para>
@@ -2352,8 +2587,34 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
 
     </glossdiv>
 
-<!--            <glossdiv id='var-glossary-n'><title>N</title>-->
-<!--            </glossdiv>-->
+    <glossdiv id='var-glossary-n'><title>N</title>
+
+        <glossentry id='var-NATIVELSBSTRING'><glossterm>NATIVELSBSTRING</glossterm>
+            <glossdef>
+                <para>
+                    A string identifying the host distribution.
+                    Strings consist of the host distributor ID
+                    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
+                    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
+                    incompatibilities).
+                    Additionally, the variable is checked against
+                    <link linkend='var-SANITY_TESTED_DISTROS'><filename>SANITY_TESTED_DISTROS</filename></link>
+                    if that variable is set.
+                </para>
+            </glossdef>
+        </glossentry>
+
+    </glossdiv>
 
     <glossdiv id='var-glossary-o'><title>O</title>
 
@@ -2672,6 +2933,23 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
             </glossdef>
         </glossentry>
 
+        <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
+                    <filename><link linkend='var-DEPENDS'>DEPENDS</link></filename>).
+                    <note>
+                        A recipe's own
+                        <filename><link linkend='var-PN'>PN</link></filename>
+                        is implicitly already in its
+                        <filename>PROVIDES</filename> list.
+                    </note>
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-PV'><glossterm>PV</glossterm>
             <glossdef>
                 <para>The version of the recipe.
@@ -2764,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
@@ -2793,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
@@ -2825,6 +3113,42 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
             </glossdef>
         </glossentry>
 
+        <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 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.
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <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
+                    (as specified by
+                    <filename><link linkend='var-RDEPENDS'>RDEPENDS</link></filename>).
+                    <note>
+                        A package's own name is implicitly already in its
+                        <filename>RPROVIDES</filename> list.
+                    </note>
+                </para>
+                <para>
+                   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'>
+     RPROVIDES_${PN} = "widget-abi-2"
+                   </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-RRECOMMENDS'><glossterm>RRECOMMENDS</glossterm>
             <glossdef>
                 <para>
@@ -2864,8 +3188,45 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
 
         <glossentry id='var-RREPLACES'><glossterm>RREPLACES</glossterm>
             <glossdef>
-                <para>The list of packages replaced by the package in which
-                    <filename>RREPLACES</filename> appears.</para>
+                <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)
+                    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
+                    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
+                   override.
+                   Here is an example:
+                   <literallayout class='monospaced'>
+     RREPLACES_${PN} = "other-package-being-replaced"
+                   </literallayout>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <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
+                    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
+                   override.
+                   Here is an example:
+                   <literallayout class='monospaced'>
+     RSUGGESTS_${PN} = "useful-package another-package"
+                   </literallayout>
+                </para>
             </glossdef>
         </glossentry>
 
@@ -2901,6 +3262,27 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-SANITY_TESTED_DISTROS'><glossterm>SANITY_TESTED_DISTROS</glossterm>
+            <glossdef>
+                <para>
+                    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,
+                    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
+                    characters (<filename>\n</filename>).
+                    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
+                    not been tested as a build host.
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-SDKIMAGE_FEATURES'><glossterm>SDKIMAGE_FEATURES</glossterm>
             <glossdef>
                 <para>Equivalent to
@@ -2943,6 +3325,54 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-SIGGEN_EXCLUDERECIPES_ABISAFE'><glossterm>SIGGEN_EXCLUDERECIPES_ABISAFE</glossterm>
+            <glossdef>
+                <para>
+                    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
+                    one recipe on another that affect task signatures and
+                    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
+                        had been built.
+                    </caution>
+                </para>
+            </glossdef>
+        </glossentry>
+
+        <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
+                    determine signatures of tasks from one recipe when they
+                    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
+                    <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.
+                    <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
+                        changed after the first recipe had been built.
+                    </caution>
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-SITEINFO_ENDIANNESS'><glossterm>SITEINFO_ENDIANNESS</glossterm>
             <glossdef>
                 <para>
@@ -2961,6 +3391,24 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-SOC_FAMILY'><glossterm>SOC_FAMILY</glossterm>
+            <glossdef>
+                <para>
+                    Groups together machines based upon the same family
+                    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.
+                    <note>
+                        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>.
+                    </note>
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-SPECIAL_PKGSUFFIX'><glossterm>SPECIAL_PKGSUFFIX</glossterm>
             <glossdef>
                 <para>
@@ -2975,56 +3423,60 @@ 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 to pull
-                    in for the build and how to pull them in.
-                    For example, if the recipe only needs to fetch a tarball from the
-                    Internet, the recipe uses a single <filename>SRC_URI</filename> entry.
-                    On the other hand, if the recipe needs to fetch a tarball, apply
-                    two patches, and include a custom file, the recipe would include four
+                    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>
+                    entry.
+                    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 is usually
-                            a file shipped with the
+                        <listitem><para><emphasis><filename>file://</filename> -</emphasis>
+                            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 subdirectories of the directory in which the
-                            recipe file resides:
+                            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>)
+                            resides:
                             <itemizedlist>
-                                <listitem><para><emphasis><filename>${PN}</filename> -</emphasis> The recipe name
-                                    with any special suffix or prefix, if applicable.
-                                    For example, using <filename>bash</filename> to build for the native
-                                    machine, <filename>PN</filename> is <filename>bash-native</filename>.
-                                    Using <filename>bash</filename> to build for the target and for Multilib,
-                                    <link linkend='var-PN'><filename>PN</filename></link>
-                                    would be <filename>bash</filename> and
-                                    <filename>lib64-bash</filename>, respectively.
-                                    </para></listitem>
-                                <listitem><para><emphasis><filename>${PF}</filename> - </emphasis>
-                                    <filename>${PN}-${EXTENDPE}${<link linkend='var-PV'>PV</link>}-${<link linkend='var-PR'>PR</link>}</filename>.
-                                    The recipe name including all version and revision numbers
-                                    (i.e. <filename>eglibc-2.13-r20+svnr15508/</filename> and
-                                    <filename>bash-4.2-r1/</filename>).</para></listitem>
-                                <listitem><para><emphasis><filename>${P}</filename> -</emphasis>
-                                    <filename>${PN}-${PV}</filename>.
-                                    The recipe name and version (i.e. <filename>bash-4.2</filename>).
-                                    </para></listitem>
-                                <listitem><para><emphasis><filename>${BPN}</filename> -</emphasis> The
-                                    base recipe name without any special suffix or version numbers.
+                                <listitem><para><emphasis><filename>${BPN}</filename> -</emphasis>
+                                    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 any special
-                                    package name suffix.</para></listitem>
-                                <listitem><para><emphasis>Files -</emphasis> Files beneath the directory in which the recipe
-                                    resides.</para></listitem>
-                                <listitem><para><emphasis>Directory -</emphasis> The directory itself in which the recipe
-                                    resides.</para></listitem>
-                            </itemizedlist></para></listitem>
+                                    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
+                                    alongside the recipe or append file.
+                                    </para></listitem>
+                            </itemizedlist>
+                            <note>
+                                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
+                                <filename>FILESPATH</filename>
+                                variable by also using the
+                                <link linkend='var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></link>
+                                variable from within your append file.
+                            </note>
+                            </para></listitem>
                         <listitem><para><emphasis><filename>bzr://</filename> -</emphasis> Fetches files from a
                             Bazaar revision control repository.</para></listitem>
                         <listitem><para><emphasis><filename>git://</filename> -</emphasis> Fetches files from a
@@ -3249,9 +3701,9 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     as set in the <filename>meta/conf/bitbake.conf</filename> file
                     is:
                     <literallayout class='monospaced'>
-     STAMP = "${TMPDIR}/stamps/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}"
+     STAMP = "${STAMPS_DIR}/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}"
                     </literallayout>
-                    See <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link>,
+                    See <link linkend='var-STAMPS_DIR'><filename>STAMPS_DIR</filename></link>,
                     <link linkend='var-MULTIMACH_TARGET_SYS'><filename>MULTIMACH_TARGET_SYS</filename></link>,
                     <link linkend='var-PN'><filename>PN</filename></link>,
                     <link linkend='var-EXTENDPE'><filename>EXTENDPE</filename></link>,
@@ -3262,6 +3714,17 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-STAMPS_DIR'><glossterm>STAMPS_DIR</glossterm>
+            <glossdef>
+                <para>
+                    Specifies the base directory in which the OpenEmbedded
+                    build system places stamps.
+                    The default directory is
+                    <filename>${TMPDIR}/stamps</filename>.
+                </para>
+            </glossdef>
+        </glossentry>
+
         <glossentry id='var-SUMMARY'><glossterm>SUMMARY</glossterm>
             <glossdef>
                 <para>The short (72 characters or less) summary of the binary package for packaging
@@ -3275,20 +3738,34 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
             </glossdef>
         </glossentry>
 
+        <glossentry id='var-SYSROOT_PREPROCESS_FUNCS'><glossterm>SYSROOT_PREPROCESS_FUNCS</glossterm>
+            <glossdef>
+                <para>
+                    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
+                    files.
+                </para>
+            </glossdef>
+        </glossentry>
+
     </glossdiv>
 
     <glossdiv id='var-glossary-t'><title>T</title>
 
         <glossentry id='var-T'><glossterm>T</glossterm>
             <glossdef>
-                <para>This variable points to a directory were BitBake places temporary
-                    files when building a particular package.
-                    It is typically set as follows:
+                <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
+     T = "${WORKDIR}/temp"
                     </literallayout>
                     The <link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>
-                    is the directory into which BitBake unpacks and builds the package.
+                    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
                     the <link linkend='var-TMPDIR'><filename>TMPDIR</filename></link> variable,
@@ -3388,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/resources.xml

@@ -112,9 +112,11 @@
 
     <para>
         The Yocto Project gladly accepts contributions.
-        You can submit changes to the project either by creating and sending pull requests,
+        You can submit changes to the project either by creating and sending 
+        pull requests,
         or by submitting patches through email.
-        For information on how to do both, see the
+        For information on how to do both as well as information on how
+        to find out who is the maintainer for areas of code, see the
         "<ulink url='&YOCTO_DOCS_DEV_URL;#how-to-submit-a-change'>How to Submit a Change</ulink>"
         section in the Yocto Project Development Manual.
     </para>

documentation/ref-manual/technical-details.xml

@@ -373,9 +373,7 @@
             change that changes the task hash, automatically
             causing the task to be run again.
             This removes the need to bump <link linkend='var-PR'><filename>PR</filename></link>
-            values and changes to metadata automatically ripple across the build.
-            Currently, this behavior is not the default behavior for <filename>OE-Core</filename>
-            but is the default in <filename>poky</filename>.
+            values and changes to Metadata automatically ripple across the build.
         </para>
 
         <para>
@@ -643,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>
 
@@ -688,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.2\/[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.2\/[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.2\/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.2\/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.2\/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.2\/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.2\/profile-manual\/profile-manual.html\" target=\"_top\">Yocto Project Profile and Tracing Manual<\/a>/Yocto Project Profile and Tracing Manual/g
+s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/1.4.2\/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.2\/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

@@ -307,11 +307,11 @@
 
         <para>
             You can download the latest Yocto Project release by going to the
-            <ulink url="&YOCTO_HOME_URL;/download">Yocto Project Download page</ulink>.
-            Just go to the page and click the "Yocto Downloads" link found in the "Download"
-            navigation pane to the right to view all available Yocto Project releases.
-            Then, click the "Yocto Release" link for the release you want from the list to
-            begin the download.
+            <ulink url="&YOCTO_HOME_URL;">Yocto Project website</ulink>
+            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
+            "Type" heading in the list.
             Nightly and developmental builds are also maintained at
             <ulink url="&YOCTO_AB_NIGHTLY_URL;"></ulink>.
             However, for this document a released version of Yocto Project is used.
@@ -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'>
@@ -408,15 +408,16 @@
                  release tarball from the source repositories using the
                  <filename>wget</filename> command.
                  Alternatively, you can go to the
-                 <ulink url='&YOCTO_HOME_URL;/download'>Yocto Project website's Downloads page</ulink>
-                 to retrieve the tarball.</para></listitem>
+                 <ulink url='&YOCTO_HOME_URL;'>Yocto Project website's</ulink>
+                 "Downloads" page to retrieve the tarball.</para></listitem>
              <listitem><para>The second command extracts the files from the tarball and places
                  them into a directory named <filename>&YOCTO_POKY;</filename> in the current
                  directory.</para></listitem>
              <listitem><para>The third and fourth commands change the working directory to the
                  <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
                  and run the Yocto Project
-                 <ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'>environment setup script</ulink>.
+                 <ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>
+                 environment setup script.
                  Running this script defines OpenEmbedded build environment settings needed to
                  complete the build.
                  The script also creates the
@@ -461,9 +462,9 @@
             By default, the OpenEmbedded build system uses the RPM package manager.
             You can control this configuration by using the
             <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></ulink></filename> variable.
-             For additional package manager selection information, see
+             For additional package manager selection information, see the
              "<ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-package'>Packaging - <filename>package*.bbclass</filename></ulink>"
-             in the Yocto Project Reference Manual.
+             section in the Yocto Project Reference Manual.
         </para>
 
          <para>
@@ -661,6 +662,11 @@
          &lt;<emphasis>arch</emphasis>&gt; is a string representing the target architecture:
                 x86, x86-64, ppc, mips, or arm.
                 </literallayout>
+                <note>
+                    For the <filename>qemu</filename> architecture,
+                    <filename>ext3</filename> and <filename>tar</filename>
+                    files start with the "lib32" string.
+                </note>
             </para>
         </section>
 

meta-skeleton/recipes-kernel/hello-mod/hello-mod_0.1.bb

@@ -13,3 +13,11 @@ SRC_URI = "file://Makefile \
           "
 
 S = "${WORKDIR}"
+
+# Kernel module packages MUST begin with 'kernel-module-', otherwise
+# multilib image generation can fail.
+#
+# The following line is only necessary if the recipe name does not begin
+# with kernel-module-.
+#
+PKG_${PN} = "kernel-module-${PN}"

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

@@ -6,8 +6,9 @@ require conf/machine/include/tune-mips32.inc
 
 MACHINE_FEATURES = "screen keyboard pci usbhost ext2 ext3 serial"
 
-KERNEL_ALT_IMAGETYPE = "vmlinux"
-KERNEL_IMAGETYPE = "vmlinux.bin"
+KERNEL_IMAGETYPE = "vmlinux"
+KERNEL_ALT_IMAGETYPE = "vmlinux.bin"
+KERNEL_IMAGE_STRIP_EXTRA_SECTIONS  = ".comment"
 
 PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
 PREFERRED_VERSION_linux-yocto ?= "3.4%"

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/classes/poky-sanity.bbclass

@@ -1,16 +1,24 @@
-python check_bblayers_conf_append() {
-    if current_lconf != lconf_version:
-        if current_lconf == 5:
-            index, meta_yocto_line = find_line('meta-yocto\s*\\\\\\n', lines)
+python poky_update_bblayersconf() {
+    current_version = int(d.getVar('LCONF_VERSION', True) or -1)
+    latest_version = int(d.getVar('LAYER_CONF_VERSION', True) or -1)
+
+    bblayers_fn = bblayers_conf_file(d)
+    lines = sanity_conf_read(bblayers_fn)
+
+    if current_version == 5 and latest_version == 6:
+        if '/meta-yocto-bsp' not in d.getVar('BBLAYERS', True):
+            index, meta_yocto_line = sanity_conf_find_line('meta-yocto\s*\\\\\\n', lines)
             if meta_yocto_line:
                 lines.insert(index + 1, meta_yocto_line.replace('meta-yocto',
                                                                 'meta-yocto-bsp'))
             else:
                 sys.exit()
 
-            index, line = find_line('LCONF_VERSION', lines)
-            current_lconf += 1
-            lines[index] = 'LCONF_VERSION = "%d"\n' % current_lconf
-            with open(bblayers_fn, "w") as f:
-                f.write(''.join(lines))
+        current_version += 1
+        sanity_conf_update(bblayers_fn, lines, 'LCONF_VERSION', current_version)
+        return
+
+    sys.exit()
 }
+
+BBLAYERS_CONF_UPDATE_FUNCS += "poky_update_bblayersconf"

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,9 +1,9 @@
 DISTRO = "poky"
-DISTRO_NAME = "Poky 8.0 (Yocto Project 1.3 Reference Distro)"
-DISTRO_VERSION = "1.3+snapshot-${DATE}"
+DISTRO_NAME = "Poky 9.0.2 (Yocto Project 1.4 Reference Distro)"
+DISTRO_VERSION = "1.4.2"
 DISTRO_CODENAME = "dylan"
 SDK_VENDOR = "-pokysdk"
-SDK_VERSION := "${@'${DISTRO_VERSION}'.replace('snapshot-${DATE}','snapshot')}"
+SDK_VERSION := "${@'${DISTRO_VERSION}'}"
 
 MAINTAINER = "Poky <poky@yoctoproject.org>"
 
@@ -70,9 +70,13 @@ CONNECTIVITY_CHECK_URIS ?= " \
              http://bugzilla.yoctoproject.org/report.cgi"
 
 SANITY_TESTED_DISTROS ?= " \
+            Yocto-1.3 \n \
             Yocto-1.2 \n \
             Poky-1.2 \n \
             Poky-1.3 \n \
+            Poky-1.4 \n \
+            Poky-1.4.1 \n \
+            Poky-1.4.2 \n \
             Ubuntu-10.04 \n \
             Ubuntu-11.10 \n \
             Ubuntu-12.04 \n \
@@ -84,11 +88,13 @@ SANITY_TESTED_DISTROS ?= " \
             CentOS-5.7 \n \
             CentOS-5.8 \n \
             CentOS-6.3 \n \
+            CentOS-6.4 \n \
             Debian-6.0 \n \
             Debian-7.0 \n \
             SUSE-LINUX-11.4 \n \
             SUSE-LINUX-12.1 \n \
             SUSE-LINUX-12.2 \n \
+            openSUSE-project-12.3 \n \
 	    "
 
 # Default hash policy for distro

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/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/icecc.bbclass

@@ -47,6 +47,9 @@ def get_cross_kernel_cc(bb,d):
     kernel_cc = kernel_cc.strip()
     return kernel_cc
 
+def get_icecc(d):
+    return d.getVar('ICECC_PATH') or os.popen("which icecc").read()[:-1]
+
 def create_path(compilers, bb, d):
     """
     Create Symlinks for the icecc in the staging directory
@@ -56,7 +59,7 @@ def create_path(compilers, bb, d):
         staging += "-kernel"
 
     #check if the icecc path is set by the user
-    icecc   = d.getVar('ICECC_PATH') or os.popen("which icecc").read()[:-1]
+    icecc = get_icecc(d)
 
     # Create the dir if necessary
     try:
@@ -151,6 +154,11 @@ def icc_path(bb,d):
         prefix = d.expand('${HOST_PREFIX}')
         return create_path( [prefix+"gcc", prefix+"g++"], bb, d)      
 
+def icc_get_external_tool(bb, d, tool):
+    external_toolchain_bindir = d.expand('${EXTERNAL_TOOLCHAIN}${bindir_cross}')
+    target_prefix = d.expand('${TARGET_PREFIX}')
+    return os.path.join(external_toolchain_bindir, '%s%s' % (target_prefix, tool))
+
 def icc_get_tool(bb, d, tool):
     if icc_is_native(bb, d):
         return os.popen("which %s" % tool).read()[:-1]
@@ -159,7 +167,26 @@ def icc_get_tool(bb, d, tool):
     else:
         ice_dir = d.expand('${STAGING_BINDIR_TOOLCHAIN}')
         target_sys = d.expand('${TARGET_SYS}')
-        return os.path.join(ice_dir, "%s-%s" % (target_sys, tool))
+        tool_bin = os.path.join(ice_dir, "%s-%s" % (target_sys, tool))
+        if os.path.isfile(tool_bin):
+            return tool_bin
+        else:
+            external_tool_bin = icc_get_external_tool(bb, d, tool)
+            if os.path.isfile(external_tool_bin):
+                return external_tool_bin
+            else:
+                return ""
+
+def icc_get_and_check_tool(bb, d, tool):
+    # Check that g++ or gcc is not a symbolic link to icecc binary in
+    # PATH or icecc-create-env script will silently create an invalid
+    # compiler environment package.
+    t = icc_get_tool(bb, d, tool)
+    if t and os.popen("readlink -f %s" % t).read()[:-1] == get_icecc(d):
+        bb.error("%s is a symlink to %s in PATH and this prevents icecc from working" % (t, get_icecc(d)))
+        return ""
+    else:
+        return t
 
 set_icecc_env() {
     if [ "x${ICECC_DISABLED}" != "x" ]
@@ -178,8 +205,8 @@ set_icecc_env() {
         return
     fi
 
-    ICECC_CC="${@icc_get_tool(bb,d, "gcc")}"
-    ICECC_CXX="${@icc_get_tool(bb,d, "g++")}"
+    ICECC_CC="${@icc_get_and_check_tool(bb, d, "gcc")}"
+    ICECC_CXX="${@icc_get_and_check_tool(bb, d, "g++")}"
     if [ ! -x "${ICECC_CC}" -o ! -x "${ICECC_CXX}" ]
     then
         return
@@ -207,6 +234,8 @@ set_icecc_env() {
     export ICECC_VERSION ICECC_CC ICECC_CXX
     export PATH="$ICE_PATH:$PATH"
     export CCACHE_PATH="$PATH"
+
+    bbnote "Using icecc"
 }
 
 do_configure_prepend() {

meta/classes/image.bbclass

@@ -116,8 +116,9 @@ python () {
     d.setVar('IMAGE_FEATURES', ' '.join(list(remain_features)))
 
     if d.getVar('BB_WORKERCONTEXT', True) is not None:
-        runtime_mapping_rename("PACKAGE_INSTALL", d)
-        runtime_mapping_rename("PACKAGE_INSTALL_ATTEMPTONLY", d)
+        pn = d.getVar('PN', True)
+        runtime_mapping_rename("PACKAGE_INSTALL", pn, d)
+        runtime_mapping_rename("PACKAGE_INSTALL_ATTEMPTONLY", pn, d)
 
     # Ensure we have the vendor list for complementary package handling
     ml_vendor_list = ""
@@ -186,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
@@ -215,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/insane.bbclass

@@ -216,7 +216,7 @@ def package_qa_check_dev(path, name, d, elf, messages):
     Check for ".so" library symlinks in non-dev packages
     """
 
-    if not name.endswith("-dev") and not name.endswith("-dbg") and not name.startswith("nativesdk-") and path.endswith(".so") and os.path.islink(path):
+    if not name.endswith("-dev") and not name.endswith("-dbg") and not name.endswith("-ptest") and not name.startswith("nativesdk-") and path.endswith(".so") and os.path.islink(path):
         messages.append("non -dev/-dbg/-nativesdk package contains symlink .so: %s path '%s'" % \
                  (name, package_qa_clean_path(path,d)))
 
@@ -229,7 +229,7 @@ def package_qa_check_staticdev(path, name, d, elf, messages):
     libgcc.a, libgcov.a will be skipped in their packages
     """
 
-    if not name.endswith("-pic") and not name.endswith("-staticdev") and path.endswith(".a") and not path.endswith("_nonshared.a"):
+    if not name.endswith("-pic") and not name.endswith("-staticdev") and not name.endswith("-ptest") and path.endswith(".a") and not path.endswith("_nonshared.a"):
         messages.append("non -staticdev package contains static .a library: %s path '%s'" % \
                  (name, package_qa_clean_path(path,d)))
 
@@ -273,7 +273,7 @@ def package_qa_check_dbg(path, name, d, elf, messages):
     Check for ".debug" files or directories outside of the dbg package
     """
 
-    if not "-dbg" in name:
+    if not "-dbg" in name and not "-ptest" in name:
         if '.debug' in path.split(os.path.sep):
             messages.append("non debug package contains .debug directory: %s path %s" % \
                      (name, package_qa_clean_path(path,d)))

meta/classes/kernel.bbclass

@@ -88,7 +88,7 @@ do_compile_kernelmodules() {
 		bbnote "no modules to compile"
 	fi
 }
-addtask compile_kernelmodules after do_compile before do_install
+addtask compile_kernelmodules after do_compile before do_strip
 
 kernel_do_install() {
 	#
@@ -200,6 +200,7 @@ kernel_do_install() {
 		sed -i 's#-I/usr/include/slang#-I=/usr/include/slang#g' $kerneldir/tools/perf/Makefile
 	fi
 }
+do_install[prefuncs] += "package_get_auto_pr"
 
 sysroot_stage_all_append() {
 	sysroot_stage_dir ${D}${KERNEL_SRC_PATH} ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH}
@@ -251,7 +252,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}"
@@ -289,6 +290,35 @@ python split_kernel_packages () {
     do_split_packages(d, root='/lib/firmware', file_regex='^(.*)\.cis$', output_pattern='kernel-firmware-%s', description='Firmware for %s', recursive=True, extra_depends='')
 }
 
+do_strip() {
+	if [ -n "${KERNEL_IMAGE_STRIP_EXTRA_SECTIONS}" ]; then
+		if [[ "${KERNEL_IMAGETYPE}" != "vmlinux" ]]; then
+			bbwarn "image type will not be stripped (not supported): ${KERNEL_IMAGETYPE}"
+			return
+		fi
+
+		cd ${B}
+		headers=`"$CROSS_COMPILE"readelf -S ${KERNEL_OUTPUT} | \
+			  grep "^ \{1,\}\[[0-9 ]\{1,\}\] [^ ]" | \
+			  sed "s/^ \{1,\}\[[0-9 ]\{1,\}\] //" | \
+			  gawk '{print $1}'`
+
+		for str in ${KERNEL_IMAGE_STRIP_EXTRA_SECTIONS}; do {
+			if [[ "$headers" != *"$str"* ]]; then
+				bbwarn "Section not found: $str";
+			fi
+
+			"$CROSS_COMPILE"strip -s -R $str ${KERNEL_OUTPUT}
+		}; done
+
+		bbnote "KERNEL_IMAGE_STRIP_EXTRA_SECTIONS is set, stripping sections:" \
+			"${KERNEL_IMAGE_STRIP_EXTRA_SECTIONS}"
+	fi;
+}
+do_strip[dirs] = "${B}"
+
+addtask do_strip before do_sizecheck after do_kernel_link_vmlinux
+
 # Support checking the kernel size since some kernels need to reside in partitions
 # with a fixed length or there is a limit in transferring the kernel to memory
 do_sizecheck() {
@@ -302,13 +332,13 @@ do_sizecheck() {
 }
 do_sizecheck[dirs] = "${B}"
 
-addtask sizecheck before do_install after do_kernel_link_vmlinux
+addtask sizecheck before do_install after do_strip
 
-KERNEL_IMAGE_BASE_NAME ?= "${KERNEL_IMAGETYPE}-${PE}-${PV}-${PR}-${MACHINE}-${DATETIME}"
+KERNEL_IMAGE_BASE_NAME ?= "${KERNEL_IMAGETYPE}-${PKGE}-${PKGV}-${PKGR}-${MACHINE}-${DATETIME}"
 # Don't include the DATETIME variable in the sstate package signatures
 KERNEL_IMAGE_BASE_NAME[vardepsexclude] = "DATETIME"
 KERNEL_IMAGE_SYMLINK_NAME ?= "${KERNEL_IMAGETYPE}-${MACHINE}"
-MODULE_IMAGE_BASE_NAME ?= "modules-${PE}-${PV}-${PR}-${MACHINE}-${DATETIME}"
+MODULE_IMAGE_BASE_NAME ?= "modules-${PKGE}-${PKGV}-${PKGR}-${MACHINE}-${DATETIME}"
 MODULE_IMAGE_BASE_NAME[vardepsexclude] = "DATETIME"
 MODULE_TARBALL_BASE_NAME ?= "${MODULE_IMAGE_BASE_NAME}.tgz"
 # Don't include the DATETIME variable in the sstate package signatures
@@ -343,6 +373,7 @@ addtask uboot_mkimage before do_install after do_compile
 kernel_do_deploy() {
 	install -m 0644 ${KERNEL_OUTPUT} ${DEPLOYDIR}/${KERNEL_IMAGE_BASE_NAME}.bin
 	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}
 	fi
@@ -356,6 +387,7 @@ kernel_do_deploy() {
 	cd -
 }
 do_deploy[dirs] = "${DEPLOYDIR} ${B}"
+do_deploy[prefuncs] += "package_get_auto_pr"
 
 addtask deploy before do_build after do_install
 

meta/classes/multilib.bbclass

@@ -100,6 +100,7 @@ python __anonymous () {
     clsextend.map_regexp_variable("PACKAGES_DYNAMIC")
     clsextend.map_variable("PACKAGE_INSTALL")
     clsextend.map_variable("INITSCRIPT_PACKAGES")
+    clsextend.map_variable("USERADD_PACKAGES")
 }
 
 PACKAGEFUNCS_append = "do_package_qa_multilib"

meta/classes/native.bbclass

@@ -50,6 +50,9 @@ TOOLCHAIN_OPTIONS = ""
 
 DEPENDS_GETTEXT = "gettext-native"
 
+# Don't build ptest natively
+PTEST_ENABLED = "0"
+
 # Don't use site files for native builds
 export CONFIG_SITE = ""
 

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"):
@@ -332,24 +329,27 @@ def copydebugsources(debugsrcdir, d):
 # Package data handling routines
 #
 
-def get_package_mapping (pkg, d):
+def get_package_mapping (pkg, basepkg, d):
     import oe.packagedata
 
     data = oe.packagedata.read_subpkgdata(pkg, d)
     key = "PKG_%s" % pkg
 
     if key in data:
+        # Have to avoid undoing the write_extra_pkgs(global_variants...)
+        if bb.data.inherits_class('allarch', d) and data[key] == basepkg:
+            return pkg
         return data[key]
 
     return pkg
 
-def runtime_mapping_rename (varname, d):
+def runtime_mapping_rename (varname, pkg, d):
     #bb.note("%s before: %s" % (varname, d.getVar(varname, True)))
 
     new_depends = {}
     deps = bb.utils.explode_dep_versions2(d.getVar(varname, True) or "")
     for depend in deps:
-        new_depend = get_package_mapping(depend, d)
+        new_depend = get_package_mapping(depend, pkg, d)
         new_depends[new_depend] = deps[depend]
 
     d.setVar(varname, bb.utils.join_deps(new_depends, commasep=False))
@@ -718,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):
@@ -829,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:
@@ -894,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()
 
@@ -943,6 +946,8 @@ python populate_packages () {
         for file in files:
             if os.path.isabs(file):
                 file = '.' + file
+            if not file.startswith("./"):
+                file = './' + file
             if not cpath.islink(file):
                 if cpath.isdir(file):
                     newfiles =  [ os.path.join(file,x) for x in os.listdir(file) ]
@@ -1244,7 +1249,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()
 
@@ -1775,7 +1780,7 @@ python package_depchains() {
 
 # Since bitbake can't determine which variables are accessed during package
 # iteration, we need to list them here:
-PACKAGEVARS = "FILES RDEPENDS RRECOMMENDS SUMMARY DESCRIPTION RSUGGESTS RPROVIDES RCONFLICTS PKG ALLOW_EMPTY pkg_postinst pkg_postrm INITSCRIPT_NAME INITSCRIPT_PARAMS DEBIAN_NOAUTONAME ALTERNATIVE PKGE PKGV PKGR"
+PACKAGEVARS = "FILES RDEPENDS RRECOMMENDS SUMMARY DESCRIPTION RSUGGESTS RPROVIDES RCONFLICTS PKG ALLOW_EMPTY pkg_postinst pkg_postrm INITSCRIPT_NAME INITSCRIPT_PARAMS DEBIAN_NOAUTONAME ALTERNATIVE PKGE PKGV PKGR USERADD_PARAM GROUPADD_PARAM"
 
 def gen_packagevar(d):
     ret = []
@@ -1942,10 +1947,11 @@ def mapping_rename_hook(d):
     Rewrite variables to account for package renaming in things
     like debian.bbclass or manual PKG variable name changes
     """
-    runtime_mapping_rename("RDEPENDS", d)
-    runtime_mapping_rename("RRECOMMENDS", d)
-    runtime_mapping_rename("RSUGGESTS", d)
-    runtime_mapping_rename("RPROVIDES", d)
-    runtime_mapping_rename("RREPLACES", d)
-    runtime_mapping_rename("RCONFLICTS", d)
+    pkg = d.getVar("PKG", True)
+    runtime_mapping_rename("RDEPENDS", pkg, d)
+    runtime_mapping_rename("RRECOMMENDS", pkg, d)
+    runtime_mapping_rename("RSUGGESTS", pkg, d)
+    runtime_mapping_rename("RPROVIDES", pkg, d)
+    runtime_mapping_rename("RREPLACES", pkg, d)
+    runtime_mapping_rename("RCONFLICTS", pkg, d)
 

meta/classes/package_ipk.bbclass

@@ -85,6 +85,7 @@ package_install_internal_ipk() {
 	local package_multilib="${INSTALL_PACKAGES_MULTILIB_IPK}"
 
 	mkdir -p ${target_rootfs}${OPKGLIBDIR}/opkg
+	touch ${target_rootfs}${OPKGLIBDIR}/opkg/status
 
 	local ipkg_args="${OPKG_ARGS}"
 

meta/classes/package_rpm.bbclass

@@ -605,7 +605,14 @@ python write_specfile () {
                             pv = subd['PV']
                             pkgv = subd['PKGV']
                             reppv = pkgv.replace('-', '+')
-                            verlist.append(ver.replace(pv, reppv).replace(pkgv, reppv))
+                            ver = ver.replace(pv, reppv).replace(pkgv, reppv)
+                        if 'PKGR' in subd:
+                            # Make sure PKGR rather than PR in ver
+                            pr = '-' + subd['PR']
+                            pkgr = '-' + subd['PKGR']
+                            if pkgr not in ver:
+                                ver = ver.replace(pr, pkgr)
+                        verlist.append(ver)
                     else:
                         verlist.append(ver)
                 newdeps_dict[dep] = verlist

meta/classes/packagegroup.bbclass

@@ -38,3 +38,10 @@ do_configure[noexec] = "1"
 do_compile[noexec] = "1"
 do_install[noexec] = "1"
 do_populate_sysroot[noexec] = "1"
+
+python () {
+    initman = d.getVar("VIRTUAL-RUNTIME_init_manager", True)
+    if initman and initman in ['sysvinit', 'systemd'] and not base_contains('DISTRO_FEATURES', initman, True, False, d):
+        bb.fatal("Please ensure that your setting of VIRTUAL-RUNTIME_init_manager (%s) matches the entries enabled in DISTRO_FEATURES" % initman)
+}
+

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"
@@ -30,7 +30,8 @@ EXCLUDE_FROM_WORLD = "1"
 SDK_PACKAGING_FUNC ?= "create_shar"
 
 fakeroot python do_populate_sdk() {
-    runtime_mapping_rename("TOOLCHAIN_TARGET_TASK", d)
+    pn = d.getVar('PN', True)
+    runtime_mapping_rename("TOOLCHAIN_TARGET_TASK", pn, d)
 
     bb.build.exec_func("populate_sdk_image", d)
 
@@ -180,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
@@ -248,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/ptest.bbclass

@@ -7,25 +7,18 @@ DESCRIPTION_${PN}-ptest ?= "${DESCRIPTION}  \
 This package contains a test directory ${PTEST_PATH} for package test purposes."
 
 PTEST_PATH ?= "${libdir}/${PN}/ptest"
-FILES_${PN}-ptest = "${PTEST_PATH}/*"
+FILES_${PN}-ptest = "${PTEST_PATH}"
 SECTION_${PN}-ptest = "devel"
 ALLOW_EMPTY_${PN}-ptest = "1"
 PTEST_ENABLED = "${@base_contains("DISTRO_FEATURES", "ptest", "1", "0", d)}"
 RDEPENDS_${PN}-ptest_virtclass-native = ""
 RDEPENDS_${PN}-ptest_virtclass-nativesdk = ""
 
-PACKAGES += "${@base_contains('DISTRO_FEATURES', 'ptest', '${PN}-ptest', '', d)}"
-
-FILES_${PN}-dbg += "${PTEST_PATH}/.debug \
-                    ${PTEST_PATH}/*/.debug \
-                    ${PTEST_PATH}/*/*/.debug \
-                    ${PTEST_PATH}/*/*/*/.debug \
-                    ${PTEST_PATH}/*/*/*/*/.debug \
-                   "
+PACKAGES =+ "${@base_contains('DISTRO_FEATURES', 'ptest', '${PN}-ptest', '', d)}"
 
 do_configure_ptest_base() {
     if [ ${PTEST_ENABLED} = 1 ]; then
-        if [ type -t do_configure_ptest = function ]; then
+        if [ a$(type -t do_configure_ptest) = afunction ]; then
             do_configure_ptest
         fi
     fi
@@ -33,7 +26,7 @@ do_configure_ptest_base() {
 
 do_compile_ptest_base() {
     if [ ${PTEST_ENABLED} = 1 ]; then
-        if [ type -t do_compile_ptest = function ]; then
+        if [ a$(type -t do_compile_ptest) = afunction ]; then
             do_compile_ptest
         fi
     fi
@@ -46,7 +39,7 @@ do_install_ptest_base() {
             if grep -q install-ptest: Makefile; then
                 oe_runmake DESTDIR=${D}${PTEST_PATH} install-ptest
             fi
-            if [ type -t do_install_ptest = function ]; then
+            if [ a$(type -t do_install_ptest) = afunction ]; then
                 do_install_ptest
             fi
         fi

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

@@ -4,8 +4,34 @@
 
 SANITY_REQUIRED_UTILITIES ?= "patch diffstat makeinfo git bzip2 tar gzip gawk chrpath wget cpio"
 
-python check_bblayers_conf() {
-    bblayers_fn = os.path.join(d.getVar('TOPDIR', True), 'conf/bblayers.conf')
+def bblayers_conf_file(d):
+    return os.path.join(d.getVar('TOPDIR', True), 'conf/bblayers.conf')
+
+def sanity_conf_read(fn):
+    with open(fn, 'r') as f:
+        lines = f.readlines()
+    return lines
+
+def sanity_conf_find_line(pattern, lines):
+    import re
+    return next(((index, line)
+        for index, line in enumerate(lines)
+        if re.search(pattern, line)), (None, None))
+
+def sanity_conf_update(fn, lines, version_var_name, new_version):
+    index, line = sanity_conf_find_line(version_var_name, lines)
+    lines[index] = '%s = "%d"\n' % (version_var_name, new_version)
+    with open(fn, "w") as f:
+        f.write(''.join(lines))
+
+EXPORT_FUNCTIONS bblayers_conf_file sanity_conf_read sanity_conf_find_line sanity_conf_update
+
+# Functions added to this variable MUST throw an exception (or sys.exit()) unless they
+# successfully changed LCONF_VERSION in bblayers.conf
+BBLAYERS_CONF_UPDATE_FUNCS += "oecore_update_bblayers"
+
+python oecore_update_bblayers() {
+    # bblayers.conf is out of date, so see if we can resolve that
 
     current_lconf = int(d.getVar('LCONF_VERSION', True))
     if not current_lconf:
@@ -13,21 +39,15 @@ python check_bblayers_conf() {
     lconf_version = int(d.getVar('LAYER_CONF_VERSION', True))
     lines = []
 
-    import re
-    def find_line(pattern, lines):
-        return next(((index, line)
-            for index, line in enumerate(lines)
-            if re.search(pattern, line)), (None, None))
-
     if current_lconf < 4:
         sys.exit()
 
-    with open(bblayers_fn, 'r') as f:
-        lines = f.readlines()
+    bblayers_fn = bblayers_conf_file(d)
+    lines = sanity_conf_read(bblayers_fn)
 
-    if current_lconf == 4:
+    if current_lconf == 4 and lconf_version > 4:
         topdir_var = '$' + '{TOPDIR}'
-        index, bbpath_line = find_line('BBPATH', lines)
+        index, bbpath_line = sanity_conf_find_line('BBPATH', lines)
         if bbpath_line:
             start = bbpath_line.find('"')
             if start != -1 and (len(bbpath_line) != (start + 1)):
@@ -41,17 +61,17 @@ python check_bblayers_conf() {
             else:
                 sys.exit()
         else:
-            index, bbfiles_line = find_line('BBFILES', lines)
+            index, bbfiles_line = sanity_conf_find_line('BBFILES', lines)
             if bbfiles_line:
                 lines.insert(index, 'BBPATH = "' + topdir_var + '"\n')
             else:
                 sys.exit()
 
-        index, line = find_line('LCONF_VERSION', lines)
         current_lconf += 1
-        lines[index] = 'LCONF_VERSION = "%d"\n' % current_lconf
-        with open(bblayers_fn, "w") as f:
-            f.write(''.join(lines))
+        sanity_conf_update(bblayers_fn, lines, 'LCONF_VERSION', current_lconf)
+        return
+
+    sys.exit()
 }
 
 def raise_sanity_error(msg, d, network_error=False):
@@ -104,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 = []
@@ -175,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)
@@ -387,18 +418,25 @@ def check_sanity(sanity_data):
     conf_version =  sanity_data.getVar('LOCALCONF_VERSION', True)
 
     if current_conf != conf_version:
-        messages = messages + "Your version of local.conf was generated from an older version of local.conf.sample and there have been updates made to this file. Please compare the two files and merge any changes before continuing.\nMatching the version numbers will remove this message.\n\"meld conf/local.conf ${COREBASE}/meta*/conf/local.conf.sample\" is a good way to visualise the changes.\n"
+        messages = messages + "Your version of local.conf was generated from an older/newer version of local.conf.sample and there have been updates made to this file. Please compare the two files and merge any changes before continuing.\nMatching the version numbers will remove this message.\n\"meld conf/local.conf ${COREBASE}/meta*/conf/local.conf.sample\" is a good way to visualise the changes.\n"
 
     # Check bblayers.conf is valid
     current_lconf = sanity_data.getVar('LCONF_VERSION', True)
     lconf_version = sanity_data.getVar('LAYER_CONF_VERSION', True)
     if current_lconf != lconf_version:
-        try:
-            bb.build.exec_func("check_bblayers_conf", sanity_data)
-            bb.note("Your conf/bblayers.conf has been automatically updated.")
-            reparse = True
-        except Exception:
-            messages = messages + "Your version of bblayers.conf was generated from an older version of bblayers.conf.sample and there have been updates made to this file. Please compare the two files and merge any changes before continuing.\nMatching the version numbers will remove this message.\n\"meld conf/bblayers.conf ${COREBASE}/meta*/conf/bblayers.conf.sample\" is a good way to visualise the changes.\n"
+        funcs = sanity_data.getVar('BBLAYERS_CONF_UPDATE_FUNCS', True).split()
+        for func in funcs:
+            success = True
+            try:
+                bb.build.exec_func(func, sanity_data)
+            except Exception:
+                success = False
+            if success:
+                bb.note("Your conf/bblayers.conf has been automatically updated.")
+                reparse = True
+                break
+        if not reparse:
+            messages = messages + "Your version of bblayers.conf was generated from an older/newer version of bblayers.conf.sample and there have been updates made to this file. Please compare the two files and merge any changes before continuing.\nMatching the version numbers will remove this message.\n\"meld conf/bblayers.conf ${COREBASE}/meta*/conf/bblayers.conf.sample\" is a good way to visualise the changes.\n"
 
     # If we have a site.conf, check it's valid
     if check_conf_exists("conf/site.conf", sanity_data):
@@ -454,7 +492,7 @@ def check_sanity(sanity_data):
         messages = messages + "Parsed PATH is " + str(paths) + "\n"
 
     bbpaths = sanity_data.getVar('BBPATH', True).split(":")
-    if "." in bbpaths or "" in bbpaths:
+    if ("." in bbpaths or "" in bbpaths) and not reparse:
         # TODO: change the following message to fatal when all BBPATH issues
         # are fixed
         bb.warn("BBPATH references the current directory, either through "    \

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)

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/classes/update-alternatives.bbclass

@@ -169,7 +169,7 @@ def gen_updatealternativesvardeps(d):
 
 def ua_extend_depends(d):
     if not 'virtual/update-alternatives' in d.getVar('PROVIDES', True):
-        d.appendVar('DEPENDS', ' virtual/update-alternatives')
+        d.appendVar('DEPENDS', ' virtual/${MLPREFIX}update-alternatives')
 
 python __anonymous() {
     # Update Alternatives only works on target packages...

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/seperatebuilddir.inc

@@ -305,7 +305,8 @@ B_pn-libmad = "${SEPB}"
 B_pn-libmatchbox = "${SEPB}"
 B_pn-libmpc = "${SEPB}"
 B_pn-libmpc-native = "${SEPB}"
-B_pn-libmusicbrainz = "${SEPB}"
+# CMake Error: The source directory "[...]libmusicbrainz-5.0.1[...]/build" does not appear to contain CMakeLists.txt.
+#B_pn-libmusicbrainz = "${SEPB}"
 # Not automake and no support for out of tree
 #B_pn-libnewt = "${SEPB}"
 B_pn-libnfsidmap = "${SEPB}"
@@ -659,6 +660,7 @@ B_pn-sysfsutils = "${SEPB}"
 B_pn-sysprof = "${SEPB}"
 # No automake, no separate build support
 #B_pn-sysstat = "${SEPB}"
+B_pn-systemd = "${SEPB}"
 B_pn-systemtap = "${SEPB}"
 B_pn-systemtap-native = "${SEPB}"
 B_pn-tar = "${SEPB}"
@@ -773,4 +775,3 @@ B_pn-xz-native = "${SEPB}"
 B_pn-yasm = "${SEPB}"
 B_pn-yasm-native = "${SEPB}"
 B_pn-zaurusd = "${SEPB}"
-

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"