build-appliance-image: Update to rocko head revision

(From OE-Core rev: 9d1129076658b4c5827c95ad8b195a7a100d7a9e)

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

bitbake/bin/bitbake

@@ -36,9 +36,9 @@ from bb import cookerdata
 from bb.main import bitbake_main, BitBakeConfigParameters, BBMainException
 
 if sys.getfilesystemencoding() != "utf-8":
-    sys.exit("Please use a locale setting which supports utf-8.\nPython can't change the filesystem locale after loading so we need a utf-8 when python starts or things won't work.")
+    sys.exit("Please use a locale setting which supports UTF-8 (such as LANG=en_US.UTF-8).\nPython can't change the filesystem locale after loading so we need a UTF-8 when Python starts or things won't work.")
 
-__version__ = "1.35.0"
+__version__ = "1.36.0"
 
 if __name__ == "__main__":
     if __version__ != bb.__version__:

bitbake/bin/bitbake-worker

@@ -17,7 +17,7 @@ from multiprocessing import Lock
 from threading import Thread
 
 if sys.getfilesystemencoding() != "utf-8":
-    sys.exit("Please use a locale setting which supports utf-8.\nPython can't change the filesystem locale after loading so we need a utf-8 when python starts or things won't work.")
+    sys.exit("Please use a locale setting which supports UTF-8 (such as LANG=en_US.UTF-8).\nPython can't change the filesystem locale after loading so we need a UTF-8 when Python starts or things won't work.")
 
 # Users shouldn't be running this code directly
 if len(sys.argv) != 2 or not sys.argv[1].startswith("decafbad"):
@@ -499,4 +499,3 @@ worker_thread.join()
 
 workerlog_write("exitting")
 sys.exit(0)
-

bitbake/lib/bb/__init__.py

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

bitbake/lib/bb/cooker.py

@@ -1686,15 +1686,23 @@ class CookerCollectFiles(object):
 
         # We need to track where we look so that we can add inotify watches. There
         # is no nice way to do this, this is horrid. We intercept the os.listdir()
-        # calls while we run glob().
+        # (or os.scandir() for python 3.6+) calls while we run glob().
         origlistdir = os.listdir
+        if hasattr(os, 'scandir'):
+            origscandir = os.scandir
         searchdirs = []
 
         def ourlistdir(d):
             searchdirs.append(d)
             return origlistdir(d)
 
+        def ourscandir(d):
+            searchdirs.append(d)
+            return origscandir(d)
+
         os.listdir = ourlistdir
+        if hasattr(os, 'scandir'):
+            os.scandir = ourscandir
         try:
             # Can't use set here as order is important
             newfiles = []
@@ -1714,6 +1722,8 @@ class CookerCollectFiles(object):
                             newfiles.append(g)
         finally:
             os.listdir = origlistdir
+            if hasattr(os, 'scandir'):
+                os.scandir = origscandir
 
         bbmask = config.getVar('BBMASK')
 

bitbake/lib/bb/event.py

@@ -173,6 +173,10 @@ def print_ui_queue():
             for event in ui_queue[:]:
                 if isinstance(event, logging.LogRecord):
                     logger.handle(event)
+        if msgerrs:
+            logger.removeHandler(stderr)
+        else:
+            logger.removeHandler(stdout)
 
 def fire_ui_handlers(event, d):
     global _thread_lock

bitbake/lib/bb/fetch2/repo.py

@@ -27,6 +27,7 @@ import os
 import bb
 from   bb.fetch2 import FetchMethod
 from   bb.fetch2 import runfetchcmd
+from   bb.fetch2 import logger
 
 class Repo(FetchMethod):
     """Class to fetch a module or modules from repo (git) repositories"""

bitbake/lib/bb/main.py

@@ -47,6 +47,9 @@ logger = logging.getLogger("BitBake")
 class BBMainException(Exception):
     pass
 
+class BBMainFatal(bb.BBHandledException):
+    pass
+
 def present_options(optionlist):
     if len(optionlist) > 1:
         return ' or '.join([', '.join(optionlist[:-1]), optionlist[-1]])
@@ -461,6 +464,8 @@ def setup_bitbake(configParams, configuration, extrafeatures=None):
 
                 if server_connection or configParams.server_only:
                     break
+            except BBMainFatal:
+                raise
             except (Exception, bb.server.process.ProcessTimeout) as e:
                 if not retries:
                     raise
@@ -491,6 +496,9 @@ def setup_bitbake(configParams, configuration, extrafeatures=None):
 
 def lockBitbake():
     topdir = bb.cookerdata.findTopdir()
+    if not topdir:
+        bb.error("Unable to find conf/bblayers.conf or conf/bitbake.conf. BBAPTH is unset and/or not in a build directory?")
+        raise BBMainFatal
     lockfile = topdir + "/bitbake.lock"
     return topdir, bb.utils.lockfile(lockfile, False, False)
 

bitbake/lib/bb/tests/fetch.py

@@ -28,6 +28,11 @@ from bb.fetch2 import URI
 from bb.fetch2 import FetchMethod
 import bb
 
+def skipIfNoNetwork():
+    if os.environ.get("BB_SKIP_NETTESTS") == "yes":
+        return unittest.skip("Network tests being skipped")
+    return lambda f: f
+
 class URITest(unittest.TestCase):
     test_uris = {
         "http://www.google.com/index.html" : {
@@ -518,141 +523,153 @@ class FetcherLocalTest(FetcherTest):
             self.fetchUnpack(['file://a;subdir=/bin/sh'])
 
 class FetcherNetworkTest(FetcherTest):
+    @skipIfNoNetwork()
+    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)
 
-    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()
+    @skipIfNoNetwork()
+    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)
+
+    @skipIfNoNetwork()
+    def test_fetch_mirror_of_mirror(self):
+        self.d.setVar("MIRRORS", "http://.*/.* http://invalid2.yoctoproject.org/ \n http://invalid2.yoctoproject.org/.* 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)
+
+    @skipIfNoNetwork()
+    def test_fetch_file_mirror_of_mirror(self):
+        self.d.setVar("MIRRORS", "http://.*/.* file:///some1where/ \n file:///some1where/.* file://some2where/ \n file://some2where/.* http://downloads.yoctoproject.org/releases/bitbake")
+        fetcher = bb.fetch.Fetch(["http://invalid.yoctoproject.org/releases/bitbake/bitbake-1.0.tar.gz"], self.d)
+        os.mkdir(self.dldir + "/some2where")
+        fetcher.download()
+        self.assertEqual(os.path.getsize(self.dldir + "/bitbake-1.0.tar.gz"), 57749)
+
+    @skipIfNoNetwork()
+    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)
+
+    @skipIfNoNetwork()
+    def gitfetcher(self, url1, url2):
+        def checkrevision(self, fetcher):
             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)
+            revision = bb.process.run("git rev-parse HEAD", shell=True, cwd=self.unpackdir + "/git")[0].strip()
+            self.assertEqual(revision, "270a05b0b4ba0959fe0624d2a4885d7b70426da5")
 
-        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)
+        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_fetch_mirror_of_mirror(self):
-            self.d.setVar("MIRRORS", "http://.*/.* http://invalid2.yoctoproject.org/ \n http://invalid2.yoctoproject.org/.* 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)
+    @skipIfNoNetwork()
+    def test_gitfetch(self):
+        url1 = url2 = "git://git.openembedded.org/bitbake"
+        self.gitfetcher(url1, url2)
 
-        def test_fetch_file_mirror_of_mirror(self):
-            self.d.setVar("MIRRORS", "http://.*/.* file:///some1where/ \n file:///some1where/.* file://some2where/ \n file://some2where/.* http://downloads.yoctoproject.org/releases/bitbake")
-            fetcher = bb.fetch.Fetch(["http://invalid.yoctoproject.org/releases/bitbake/bitbake-1.0.tar.gz"], self.d)
-            os.mkdir(self.dldir + "/some2where")
-            fetcher.download()
-            self.assertEqual(os.path.getsize(self.dldir + "/bitbake-1.0.tar.gz"), 57749)
+    @skipIfNoNetwork()
+    def test_gitfetch_goodsrcrev(self):
+        # SRCREV is set but matches rev= parameter
+        url1 = url2 = "git://git.openembedded.org/bitbake;rev=270a05b0b4ba0959fe0624d2a4885d7b70426da5"
+        self.gitfetcher(url1, url2)
 
-        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)
+    @skipIfNoNetwork()
+    def test_gitfetch_badsrcrev(self):
+        # SRCREV is set but does not match rev= parameter
+        url1 = url2 = "git://git.openembedded.org/bitbake;rev=dead05b0b4ba0959fe0624d2a4885d7b70426da5"
+        self.assertRaises(bb.fetch.FetchError, self.gitfetcher, url1, url2)
 
-        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")
+    @skipIfNoNetwork()
+    def test_gitfetch_tagandrev(self):
+        # SRCREV is set but does not match rev= parameter
+        url1 = url2 = "git://git.openembedded.org/bitbake;rev=270a05b0b4ba0959fe0624d2a4885d7b70426da5;tag=270a05b0b4ba0959fe0624d2a4885d7b70426da5"
+        self.assertRaises(bb.fetch.FetchError, self.gitfetcher, url1, url2)
 
-            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)
+    @skipIfNoNetwork()
+    def test_gitfetch_localusehead(self):
+        # Create dummy local Git repo
+        src_dir = tempfile.mkdtemp(dir=self.tempdir,
+                                   prefix='gitfetch_localusehead_')
+        src_dir = os.path.abspath(src_dir)
+        bb.process.run("git init", cwd=src_dir)
+        bb.process.run("git commit --allow-empty -m'Dummy commit'",
+                       cwd=src_dir)
+        # Use other branch than master
+        bb.process.run("git checkout -b my-devel", cwd=src_dir)
+        bb.process.run("git commit --allow-empty -m'Dummy commit 2'",
+                       cwd=src_dir)
+        stdout = bb.process.run("git rev-parse HEAD", cwd=src_dir)
+        orig_rev = stdout[0].strip()
 
-        def test_gitfetch(self):
-            url1 = url2 = "git://git.openembedded.org/bitbake"
-            self.gitfetcher(url1, url2)
+        # Fetch and check revision
+        self.d.setVar("SRCREV", "AUTOINC")
+        url = "git://" + src_dir + ";protocol=file;usehead=1"
+        fetcher = bb.fetch.Fetch([url], self.d)
+        fetcher.download()
+        fetcher.unpack(self.unpackdir)
+        stdout = bb.process.run("git rev-parse HEAD",
+                                cwd=os.path.join(self.unpackdir, 'git'))
+        unpack_rev = stdout[0].strip()
+        self.assertEqual(orig_rev, unpack_rev)
 
-        def test_gitfetch_goodsrcrev(self):
-            # SRCREV is set but matches rev= parameter
-            url1 = url2 = "git://git.openembedded.org/bitbake;rev=270a05b0b4ba0959fe0624d2a4885d7b70426da5"
-            self.gitfetcher(url1, url2)
+    @skipIfNoNetwork()
+    def test_gitfetch_remoteusehead(self):
+        url = "git://git.openembedded.org/bitbake;usehead=1"
+        self.assertRaises(bb.fetch.ParameterError, self.gitfetcher, url, url)
 
-        def test_gitfetch_badsrcrev(self):
-            # SRCREV is set but does not match rev= parameter
-            url1 = url2 = "git://git.openembedded.org/bitbake;rev=dead05b0b4ba0959fe0624d2a4885d7b70426da5"
-            self.assertRaises(bb.fetch.FetchError, self.gitfetcher, url1, url2)
+    @skipIfNoNetwork()
+    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_tagandrev(self):
-            # SRCREV is set but does not match rev= parameter
-            url1 = url2 = "git://git.openembedded.org/bitbake;rev=270a05b0b4ba0959fe0624d2a4885d7b70426da5;tag=270a05b0b4ba0959fe0624d2a4885d7b70426da5"
-            self.assertRaises(bb.fetch.FetchError, self.gitfetcher, url1, url2)
+    @skipIfNoNetwork()
+    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_localusehead(self):
-            # Create dummy local Git repo
-            src_dir = tempfile.mkdtemp(dir=self.tempdir,
-                                       prefix='gitfetch_localusehead_')
-            src_dir = os.path.abspath(src_dir)
-            bb.process.run("git init", cwd=src_dir)
-            bb.process.run("git commit --allow-empty -m'Dummy commit'",
-                           cwd=src_dir)
-            # Use other branch than master
-            bb.process.run("git checkout -b my-devel", cwd=src_dir)
-            bb.process.run("git commit --allow-empty -m'Dummy commit 2'",
-                           cwd=src_dir)
-            stdout = bb.process.run("git rev-parse HEAD", cwd=src_dir)
-            orig_rev = stdout[0].strip()
+    @skipIfNoNetwork()
+    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)
 
-            # Fetch and check revision
-            self.d.setVar("SRCREV", "AUTOINC")
-            url = "git://" + src_dir + ";protocol=file;usehead=1"
-            fetcher = bb.fetch.Fetch([url], self.d)
-            fetcher.download()
-            fetcher.unpack(self.unpackdir)
-            stdout = bb.process.run("git rev-parse HEAD",
-                                    cwd=os.path.join(self.unpackdir, 'git'))
-            unpack_rev = stdout[0].strip()
-            self.assertEqual(orig_rev, unpack_rev)
-
-        def test_gitfetch_remoteusehead(self):
-            url = "git://git.openembedded.org/bitbake;usehead=1"
-            self.assertRaises(bb.fetch.ParameterError, self.gitfetcher, url, url)
-
-        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)
-
-        def test_git_submodule(self):
-            fetcher = bb.fetch.Fetch(["gitsm://git.yoctoproject.org/git-submodule-test;rev=f12e57f2edf0aa534cf1616fa983d165a92b0842"], self.d)
-            fetcher.download()
-            # Previous cwd has been deleted
-            os.chdir(os.path.dirname(self.unpackdir))
-            fetcher.unpack(self.unpackdir)
+    @skipIfNoNetwork()
+    def test_git_submodule(self):
+        fetcher = bb.fetch.Fetch(["gitsm://git.yoctoproject.org/git-submodule-test;rev=f12e57f2edf0aa534cf1616fa983d165a92b0842"], self.d)
+        fetcher.download()
+        # Previous cwd has been deleted
+        os.chdir(os.path.dirname(self.unpackdir))
+        fetcher.unpack(self.unpackdir)
 
 
 class TrustedNetworksTest(FetcherTest):
@@ -782,32 +799,32 @@ class FetchLatestVersionTest(FetcherTest):
         ("db", "http://download.oracle.com/berkeley-db/db-5.3.21.tar.gz", "http://www.oracle.com/technetwork/products/berkeleydb/downloads/index-082944.html", "http://download.oracle.com/otn/berkeley-db/(?P<name>db-)(?P<pver>((\d+[\.\-_]*)+))\.tar\.gz")
             : "6.1.19",
     }
-    if os.environ.get("BB_SKIP_NETTESTS") == "yes":
-        print("Unset BB_SKIP_NETTESTS to run network tests")
-    else:
-        def test_git_latest_versionstring(self):
-            for k, v in self.test_git_uris.items():
-                self.d.setVar("PN", k[0])
-                self.d.setVar("SRCREV", k[2])
-                self.d.setVar("UPSTREAM_CHECK_GITTAGREGEX", k[3])
-                ud = bb.fetch2.FetchData(k[1], self.d)
-                pupver= ud.method.latest_versionstring(ud, self.d)
-                verstring = pupver[0]
-                self.assertTrue(verstring, msg="Could not find upstream version")
-                r = bb.utils.vercmp_string(v, verstring)
-                self.assertTrue(r == -1 or r == 0, msg="Package %s, version: %s <= %s" % (k[0], v, verstring))
 
-        def test_wget_latest_versionstring(self):
-            for k, v in self.test_wget_uris.items():
-                self.d.setVar("PN", k[0])
-                self.d.setVar("UPSTREAM_CHECK_URI", k[2])
-                self.d.setVar("UPSTREAM_CHECK_REGEX", k[3])
-                ud = bb.fetch2.FetchData(k[1], self.d)
-                pupver = ud.method.latest_versionstring(ud, self.d)
-                verstring = pupver[0]
-                self.assertTrue(verstring, msg="Could not find upstream version")
-                r = bb.utils.vercmp_string(v, verstring)
-                self.assertTrue(r == -1 or r == 0, msg="Package %s, version: %s <= %s" % (k[0], v, verstring))
+    @skipIfNoNetwork()
+    def test_git_latest_versionstring(self):
+        for k, v in self.test_git_uris.items():
+            self.d.setVar("PN", k[0])
+            self.d.setVar("SRCREV", k[2])
+            self.d.setVar("UPSTREAM_CHECK_GITTAGREGEX", k[3])
+            ud = bb.fetch2.FetchData(k[1], self.d)
+            pupver= ud.method.latest_versionstring(ud, self.d)
+            verstring = pupver[0]
+            self.assertTrue(verstring, msg="Could not find upstream version")
+            r = bb.utils.vercmp_string(v, verstring)
+            self.assertTrue(r == -1 or r == 0, msg="Package %s, version: %s <= %s" % (k[0], v, verstring))
+
+    @skipIfNoNetwork()
+    def test_wget_latest_versionstring(self):
+        for k, v in self.test_wget_uris.items():
+            self.d.setVar("PN", k[0])
+            self.d.setVar("UPSTREAM_CHECK_URI", k[2])
+            self.d.setVar("UPSTREAM_CHECK_REGEX", k[3])
+            ud = bb.fetch2.FetchData(k[1], self.d)
+            pupver = ud.method.latest_versionstring(ud, self.d)
+            verstring = pupver[0]
+            self.assertTrue(verstring, msg="Could not find upstream version")
+            r = bb.utils.vercmp_string(v, verstring)
+            self.assertTrue(r == -1 or r == 0, msg="Package %s, version: %s <= %s" % (k[0], v, verstring))
 
 
 class FetchCheckStatusTest(FetcherTest):
@@ -820,40 +837,40 @@ class FetchCheckStatusTest(FetcherTest):
                       "https://yoctoproject.org/documentation",
                       "http://downloads.yoctoproject.org/releases/opkg/opkg-0.1.7.tar.gz",
                       "http://downloads.yoctoproject.org/releases/opkg/opkg-0.3.0.tar.gz",
-                      "ftp://ftp.gnu.org/gnu/autoconf/autoconf-2.60.tar.gz",
-                      "ftp://ftp.gnu.org/gnu/chess/gnuchess-5.08.tar.gz",
-                      "ftp://ftp.gnu.org/gnu/gmp/gmp-4.0.tar.gz",
+                      "ftp://sourceware.org/pub/libffi/libffi-1.20.tar.gz",
+                      "http://ftp.gnu.org/gnu/autoconf/autoconf-2.60.tar.gz",
+                      "https://ftp.gnu.org/gnu/chess/gnuchess-5.08.tar.gz",
+                      "https://ftp.gnu.org/gnu/gmp/gmp-4.0.tar.gz",
                       # GitHub releases are hosted on Amazon S3, which doesn't support HEAD
                       "https://github.com/kergoth/tslib/releases/download/1.1/tslib-1.1.tar.xz"
                       ]
 
-    if os.environ.get("BB_SKIP_NETTESTS") == "yes":
-        print("Unset BB_SKIP_NETTESTS to run network tests")
-    else:
-
-        def test_wget_checkstatus(self):
-            fetch = bb.fetch2.Fetch(self.test_wget_uris, self.d)
-            for u in self.test_wget_uris:
+    @skipIfNoNetwork()
+    def test_wget_checkstatus(self):
+        fetch = bb.fetch2.Fetch(self.test_wget_uris, self.d)
+        for u in self.test_wget_uris:
+            with self.subTest(url=u):
                 ud = fetch.ud[u]
                 m = ud.method
                 ret = m.checkstatus(fetch, ud, self.d)
                 self.assertTrue(ret, msg="URI %s, can't check status" % (u))
 
+    @skipIfNoNetwork()
+    def test_wget_checkstatus_connection_cache(self):
+        from bb.fetch2 import FetchConnectionCache
 
-        def test_wget_checkstatus_connection_cache(self):
-            from bb.fetch2 import FetchConnectionCache
+        connection_cache = FetchConnectionCache()
+        fetch = bb.fetch2.Fetch(self.test_wget_uris, self.d,
+                    connection_cache = connection_cache)
 
-            connection_cache = FetchConnectionCache()
-            fetch = bb.fetch2.Fetch(self.test_wget_uris, self.d,
-                        connection_cache = connection_cache)
-
-            for u in self.test_wget_uris:
+        for u in self.test_wget_uris:
+            with self.subTest(url=u):
                 ud = fetch.ud[u]
                 m = ud.method
                 ret = m.checkstatus(fetch, ud, self.d)
                 self.assertTrue(ret, msg="URI %s, can't check status" % (u))
 
-            connection_cache.close_connections()
+        connection_cache.close_connections()
 
 
 class GitMakeShallowTest(FetcherTest):
@@ -972,15 +989,13 @@ class GitMakeShallowTest(FetcherTest):
         self.make_shallow()
         self.assertRevCount(1)
 
-    if os.environ.get("BB_SKIP_NETTESTS") == "yes":
-        print("Unset BB_SKIP_NETTESTS to run network tests")
-    else:
-        def test_make_shallow_bitbake(self):
-            self.git('remote add origin https://github.com/openembedded/bitbake')
-            self.git('fetch --tags origin')
-            orig_revs = len(self.git('rev-list --all').splitlines())
-            self.make_shallow(['refs/tags/1.10.0'])
-            self.assertRevCount(orig_revs - 1746, ['--all'])
+    @skipIfNoNetwork()
+    def test_make_shallow_bitbake(self):
+        self.git('remote add origin https://github.com/openembedded/bitbake')
+        self.git('fetch --tags origin')
+        orig_revs = len(self.git('rev-list --all').splitlines())
+        self.make_shallow(['refs/tags/1.10.0'])
+        self.assertRevCount(orig_revs - 1746, ['--all'])
 
 class GitShallowTest(FetcherTest):
     def setUp(self):
@@ -1436,24 +1451,22 @@ class GitShallowTest(FetcherTest):
         with self.assertRaises(bb.fetch2.FetchError):
             self.fetch()
 
-    if os.environ.get("BB_SKIP_NETTESTS") == "yes":
-        print("Unset BB_SKIP_NETTESTS to run network tests")
-    else:
-        def test_bitbake(self):
-            self.git('remote add --mirror=fetch origin git://github.com/openembedded/bitbake', cwd=self.srcdir)
-            self.git('config core.bare true', cwd=self.srcdir)
-            self.git('fetch', cwd=self.srcdir)
+    @skipIfNoNetwork()
+    def test_bitbake(self):
+        self.git('remote add --mirror=fetch origin git://github.com/openembedded/bitbake', cwd=self.srcdir)
+        self.git('config core.bare true', cwd=self.srcdir)
+        self.git('fetch', cwd=self.srcdir)
 
-            self.d.setVar('BB_GIT_SHALLOW_DEPTH', '0')
-            # Note that the 1.10.0 tag is annotated, so this also tests
-            # reference of an annotated vs unannotated tag
-            self.d.setVar('BB_GIT_SHALLOW_REVS', '1.10.0')
+        self.d.setVar('BB_GIT_SHALLOW_DEPTH', '0')
+        # Note that the 1.10.0 tag is annotated, so this also tests
+        # reference of an annotated vs unannotated tag
+        self.d.setVar('BB_GIT_SHALLOW_REVS', '1.10.0')
 
-            self.fetch_shallow()
+        self.fetch_shallow()
 
-            # Confirm that the history of 1.10.0 was removed
-            orig_revs = len(self.git('rev-list master', cwd=self.srcdir).splitlines())
-            revs = len(self.git('rev-list master').splitlines())
-            self.assertNotEqual(orig_revs, revs)
-            self.assertRefs(['master', 'origin/master'])
-            self.assertRevCount(orig_revs - 1758)
+        # Confirm that the history of 1.10.0 was removed
+        orig_revs = len(self.git('rev-list master', cwd=self.srcdir).splitlines())
+        revs = len(self.git('rev-list master').splitlines())
+        self.assertNotEqual(orig_revs, revs)
+        self.assertRefs(['master', 'origin/master'])
+        self.assertRevCount(orig_revs - 1758)

bitbake/lib/bb/tinfoil.py

@@ -322,14 +322,14 @@ class Tinfoil:
         self.server_connection = None
         self.recipes_parsed = False
         self.quiet = 0
+        self.oldhandlers = self.logger.handlers[:]
         if setup_logging:
             # This is the *client-side* logger, nothing to do with
             # logging messages from the server
-            oldhandlers = self.logger.handlers[:]
             bb.msg.logger_create('BitBake', output)
             self.localhandlers = []
             for handler in self.logger.handlers:
-                if handler not in oldhandlers:
+                if handler not in self.oldhandlers:
                     self.localhandlers.append(handler)
 
     def __enter__(self):
@@ -835,6 +835,12 @@ class Tinfoil:
             self.server_connection.terminate()
             self.server_connection = None
 
+        # Restore logging handlers to how it looked when we started
+        if self.oldhandlers:
+            for handler in self.logger.handlers:
+                if handler not in self.oldhandlers:
+                    self.logger.handlers.remove(handler)
+
     def _reconvert_type(self, obj, origtypename):
         """
         Convert an object back to the right type, in the case

documentation/Makefile

@@ -8,7 +8,7 @@
 # system.  These manuals also include an "eclipse" sub-directory as part of
 # the make process.
 #
-# Note that the figures for the Yocto Project Development Manual
+# Note that the figures for the Yocto Project Development Tasks Manual
 # differ depending on the BRANCH being built.
 #
 # The Makefile has these targets:
@@ -42,7 +42,7 @@
 # To build a manual, you must invoke Makefile with the DOC argument.  If you
 # are going to publish the manual, then you must invoke Makefile with both the
 # DOC and the VER argument.  Furthermore, if you are building or publishing
-# the edison or denzil versions of the Yocto Project Development Manual or
+# the edison or denzil versions of the Yocto Project Development Tasks Manual or
 # the mega-manual, you must also use the BRANCH argument.
 #
 # Examples:
@@ -59,7 +59,7 @@
 # 'make DOC=yocto-project-qs' command would be equivalent. The third example
 # generates just the PDF version of the Yocto Project Reference Manual.
 # The fourth example generates the HTML 'edison' version and (if available)
-# the Eclipse help version of the YP Development Manual.  The last example
+# the Eclipse help version of the YP Development Tasks Manual.  The last example
 # generates the HTML version of the mega-manual and uses the 'denzil'
 # branch when choosing figures for the tarball of figures.  Any example that does
 # not use the BRANCH argument builds the current version of the manual set.
@@ -79,9 +79,9 @@
 # The first example publishes the 1.7 version of both the PDF and HTML versions of
 # the BSP Guide.  The second example publishes the 1.6 version of both the PDF and
 # HTML versions of the ADT Manual. The third example publishes the 1.1.1 version of
-# the PDF and HTML YP Development Manual for the 'edison' branch.  The fourth example
-# publishes the 1.2 version of the PDF and HTML YP Development Manual for the
-# 'denzil' branch.
+# the PDF and HTML YP Development Tasks Manual for the 'edison' branch.  The fourth
+# example publishes the 1.2 version of the PDF and HTML YP Development Tasks Manual
+# for the 'denzil' branch.
 #
 
 ifeq ($(DOC),bsp-guide)

documentation/README

@@ -36,8 +36,8 @@ Folders exist for individual manuals as follows:
 
 * sdk-manual       - The Yocto Project Software Development Kit (SDK) Developer's Guide.
 * bsp-guide        - The Yocto Project Board Support Package (BSP) Developer's Guide
-* dev-manual       - The Yocto Project Development Manual
-* kernel-dev       - The Yocto Project Linux Kernel Development Manual
+* dev-manual       - The Yocto Project Development Tasks Manual
+* kernel-dev       - The Yocto Project Linux Kernel Development Tasks Manual
 * ref-manual       - The Yocto Project Reference Manual
 * yocto-project-qs - The Yocto Project Quick Start
 * mega-manual      - The Yocto Project Mega-Manual, which is an aggregated manual comprised

documentation/bsp-guide/bsp-guide.xml

@@ -22,18 +22,11 @@
 
         <authorgroup>
             <author>
-                <firstname>Saul</firstname> <surname>Wold</surname>
+                <firstname>Scott</firstname> <surname>Rifenbark</surname>
                 <affiliation>
-                    <orgname>Intel Corporation</orgname>
+                    <orgname>Scotty's Documentation Services, INC</orgname>
                 </affiliation>
-                <email>saul.wold@intel.com</email>
-            </author>
-            <author>
-                <firstname>Richard</firstname> <surname>Purdie</surname>
-                <affiliation>
-                    <orgname>Linux Foundation</orgname>
-                </affiliation>
-                <email>richard.purdie@linuxfoundation.org</email>
+                <email>srifenbark@gmail.com</email>
             </author>
         </authorgroup>
 
@@ -135,34 +128,34 @@
         Permission is granted to copy, distribute and/or modify this document under
         the terms of the <ulink type="http" url="http://creativecommons.org/licenses/by-nc-sa/2.0/uk/">Creative Commons Attribution-Share Alike 2.0 UK: England &amp; Wales</ulink> as published by Creative Commons.
       </para>
-            <note><title>Manual Notes</title>
-                <itemizedlist>
-                    <listitem><para>
-                        For the latest version of the Yocto Project Board
-                        Support Package (BSP) Developer's Guide associated with
-                        this Yocto Project release (version
-                        &YOCTO_DOC_VERSION;),
-                        see the Yocto Project Board Support Package (BSP)
-                        Developer's Guide from the
-                        <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink>.
+           <note><title>Manual Notes</title>
+               <itemizedlist>
+                   <listitem><para>
+                       This version of the
+                       <emphasis>Yocto Project Board Support Package Developer's Guide</emphasis>
+                       is for the &YOCTO_DOC_VERSION; release of the
+                       Yocto Project.
+                       To be sure you have the latest version of the manual
+                       for this release, use the manual from the
+                       <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink>.
+                       </para></listitem>
+                   <listitem><para>
+                       For manuals associated with other releases of the Yocto
+                       Project, go to the
+                       <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink>
+                       and use the drop-down "Active Releases" button
+                       and choose the manual associated with the desired
+                       Yocto Project.
+                       </para></listitem>
+                   <listitem><para>
+                        To report any inaccuracies or problems with this
+                        manual, send an email to the Yocto Project
+                        discussion group at
+                        <filename>yocto@yoctoproject.com</filename> or log into
+                        the freenode <filename>#yocto</filename> channel.
                         </para></listitem>
-                    <listitem><para>
-                        This version of the manual is version
-                        &YOCTO_DOC_VERSION;.
-                        For later releases of the Yocto Project (if they exist),
-                        go to the
-                        <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink>
-                        and use the drop-down "Active Releases" button
-                        and choose the Yocto Project version for which you want
-                        the manual.
-                        </para></listitem>
-                    <listitem><para>
-                        For an in-development version of the Yocto Project
-                        Board Support Package (BSP) Developer's Guide, see
-                        <ulink url='&YOCTO_DOCS_URL;/latest/bsp-guide/bsp-guide.html'></ulink>.
-                        </para></listitem>
-                </itemizedlist>
-            </note>
+               </itemizedlist>
+           </note>
     </legalnotice>
 
     </bookinfo>

documentation/bsp-guide/bsp.xml

@@ -88,7 +88,7 @@
                 For more information on how to set up a local copy of source files
                 from a Git repository, see the
                 "<ulink url='&YOCTO_DOCS_DEV_URL;#working-with-yocto-project-source-files'>Working With Yocto Project Source Files</ulink>"
-                section also in the Yocto Project Development Manual.
+                section also in the Yocto Project Development Tasks Manual.
             </para>
 
             <para>
@@ -139,7 +139,7 @@
             <para>
                 For more detailed information on layers, see the
                 "<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and Creating Layers</ulink>"
-                section of the Yocto Project Development Manual.
+                section of the Yocto Project Development Tasks Manual.
             </para>
         </section>
 
@@ -164,7 +164,7 @@
                         Be sure you are set up to use BitBake in a shell.
                         See the
                         "<ulink url='&YOCTO_DOCS_DEV_URL;#setting-up-the-development-host-to-use-the-yocto-project'>Setting Up the Development Host to Use the Yocto Project</ulink>"
-                        section in the Yocto Project Development Manual for information
+                        section in the Yocto Project Development Tasks Manual for information
                         on how to get a build host ready that is either a native
                         Linux machine or a machine that uses CROPS.
                         </para></listitem>
@@ -179,7 +179,7 @@
                         "<ulink url='&YOCTO_DOCS_DEV_URL;#checking-out-by-branch-in-poky'>Checking Out by Branch in Poky</ulink>"
                         and
                         "<ulink url='&YOCTO_DOCS_DEV_URL;#checkout-out-by-tag-in-poky'>Checking Out by Tag in Poky</ulink>"
-                        sections all in the Yocto Project Development Manual for
+                        sections all in the Yocto Project Development Tasks Manual for
                         information on how to clone the <filename>poky</filename>
                         repository and check out the appropriate branch for your work.
                         </para></listitem>
@@ -236,7 +236,7 @@
                                 For an example on how to discover branch names and
                                 checkout on a branch, see the
                                 "<ulink url='&YOCTO_DOCS_DEV_URL;#checking-out-by-branch-in-poky'>Checking Out By Branch in Poky</ulink>"
-                                section.
+                                section in the Yocto Project Development Tasks Manual.
                                 </para></listitem>
                         </orderedlist>
                         </para></listitem>
@@ -711,7 +711,7 @@
                 <para>
                     Tuning files are found in the <filename>meta/conf/machine/include</filename>
                     directory within the
-                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+                    <ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink>.
                     For example, the <filename>ia32-base.inc</filename> file resides in the
                     <filename>meta/conf/machine/include</filename> directory.
                 </para>
@@ -767,7 +767,7 @@
                     formfactor recipe
                     <filename>meta/recipes-bsp/formfactor/formfactor_0.0.bb</filename>,
                     which is found in the
-                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+                    <ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink>.
                 </para></note>
             </section>
 
@@ -807,7 +807,7 @@
                 <para>
                     For your BSP, you typically want to use an existing Yocto
                     Project kernel recipe found in the
-                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+                    <ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink>
                     at <filename>meta/recipes-kernel/linux</filename>.
                     You can append machine-specific changes to the kernel recipe
                     by using a similarly named append file, which is located in
@@ -928,7 +928,7 @@
                         about.
                         For more information on layers, see the
                         "<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and Creating Layers</ulink>"
-                        section in the Yocto Project Development Manual.
+                        section in the Yocto Project Development Tasks Manual.
                         For more information on BSP layers, see the
                         "<link linkend='bsp-layers'>BSP Layers</link>"
                         section.
@@ -1018,7 +1018,7 @@
                         of your new layer.
                         See the
                         "<ulink url='&YOCTO_DOCS_DEV_URL;#enabling-your-layer'>Enabling Your Layer</ulink>"
-                        section in the Yocto Project Development Manual
+                        section in the Yocto Project Development Tasks Manual
                         for information on how to let the build system
                         know about your new layer.</para>
 
@@ -1070,24 +1070,28 @@
                             For guidelines on creating a layer that meets these base requirements, see the
                             "<link linkend='bsp-layers'>BSP Layers</link>" and the
                             "<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding
-                            and Creating Layers"</ulink> in the Yocto Project Development Manual.</para></listitem>
+                            and Creating Layers"</ulink> in the Yocto Project Development Tasks Manual.
+                            </para></listitem>
                         <listitem><para>The requirements in this section apply regardless of how you
                             package a BSP.
                             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>
+                            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
                             and could have a directory structure completely different from what appears
-                            in the officially released BSP layer.</para></listitem>
+                            in the officially released BSP layer.
+                            </para></listitem>
                         <listitem><para>It is not required that specific packages or package
                             modifications exist in the BSP layer, beyond the requirements for general
                             compliance with the Yocto Project.
                             For example, no requirement exists dictating that a specific kernel or
-                            kernel version be used in a given BSP.</para></listitem>
+                            kernel version be used in a given BSP.
+                            </para></listitem>
                     </itemizedlist>
                 </para>
 
@@ -1114,7 +1118,7 @@
                             <filename>recipes-*</filename> subdirectory.
                             You can find <filename>recipes.txt</filename> in the
                             <filename>meta</filename> directory of the
-                            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>,
+                            <ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink>,
                             or in the OpenEmbedded Core Layer
                             (<filename>openembedded-core</filename>) found at
                             <ulink url='http://git.openembedded.org/openembedded-core/tree/meta'></ulink>.
@@ -1171,7 +1175,7 @@
                                     be sent.
                                     For information on how to find the right person, see the
                                     "<ulink url='&YOCTO_DOCS_DEV_URL;#how-to-submit-a-change'>Submitting a Change to the Yocto Project</ulink>"
-                                    section in the Yocto Project Development Manual.
+                                    section in the Yocto Project Development Tasks Manual.
                                     </para></listitem>
                                 <listitem><para>Instructions on how to build the BSP using the BSP
                                     layer.</para></listitem>
@@ -1275,7 +1279,7 @@
                        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 in Your Layer</ulink>"
-                       section in the Yocto Project Development Manual.
+                       section in the Yocto Project Development Tasks Manual.
                        </para></listitem>
                    <listitem><para>
                        Ensure your directory structure in the BSP layer
@@ -1493,7 +1497,7 @@
 
                 <para>
                     Both tools reside in the <filename>scripts/</filename> subdirectory
-                    of the <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+                    of the <ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink>.
                     Consequently, to use the scripts, you must <filename>source</filename> the
                     environment just as you would when invoking a build:
                     <literallayout class='monospaced'>
@@ -1589,11 +1593,11 @@
                     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
+                        You can also use the <filename>bitbake-layers</filename> script 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.
+                        For information on using this script to create a layer, see the
+                        "<ulink url='&YOCTO_DOCS_DEV_URL;#creating-a-general-layer-using-the-bitbake-layers-script'>Creating a General Layer Using the <filename>bitbake-layers</filename> Script</ulink>"
+                        section in the Yocto Project Development Tasks Manual.
                     </note>
                 </para>
 
@@ -1743,7 +1747,7 @@
                             Defaults are accepted for each.</para></listitem>
                         <listitem><para>By default, the script creates the new BSP Layer in the
                             current working directory of the
-                            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>,
+                            <ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink>,
                             (i.e. <filename>poky/build</filename>).
                             </para></listitem>
                     </orderedlist>

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

@@ -108,7 +108,7 @@
                 "<ulink url='&YOCTO_DOCS_BSP_URL;#creating-a-new-bsp-layer-using-the-yocto-bsp-script'>Creating a New BSP Layer Using the yocto-bsp Script</ulink>"
                 section in the Yocto Project Board Support Package (BSP)
                 Developer's Guide and the
-                "<link linkend='creating-a-general-layer-using-the-yocto-layer-script'>Creating a General Layer Using the yocto-layer Script</link>"
+                "<link linkend='creating-a-general-layer-using-the-bitbake-layers-script'>Creating a General Layer Using the <filename>bitbake-layers</filename> Script</link>"
                 section further down in this manual.
             </para>
 
@@ -968,122 +968,141 @@
             </para>
         </section>
 
-        <section id='creating-a-general-layer-using-the-yocto-layer-script'>
-            <title>Creating a General Layer Using the yocto-layer Script</title>
+        <section id='creating-a-general-layer-using-the-bitbake-layers-script'>
+            <title>Creating a General Layer Using the <filename>bitbake-layers</filename> Script</title>
 
             <para>
-                The <filename>yocto-layer</filename> script simplifies
+                The <filename>bitbake-layers</filename> script with the
+                <filename>create-layer</filename> subcommand simplifies
                 creating a new general layer.
-                <note>
-                    For information on BSP layers, see the
-                    "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-layers'>BSP Layers</ulink>"
-                    section in the Yocto Project Board Specific (BSP)
-                    Developer's Guide.
+                <note><title>Notes</title>
+                    <itemizedlist>
+                        <listitem><para>
+                            For information on BSP layers, see the
+                            "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-layers'>BSP Layers</ulink>"
+                            section in the Yocto Project Board Specific (BSP)
+                            Developer's Guide.
+                            </para></listitem>
+                        <listitem><para>
+                            The <filename>bitbake-layers</filename> script
+                            replaces the <filename>yocto-layer</filename>
+                            script, which is deprecated in the Yocto Project
+                            2.4 release.
+                            The <filename>yocto-layer</filename> script
+                            continues to function as part of the 2.4 release
+                            but will be removed post 2.4.
+                            </para></listitem>
+                    </itemizedlist>
                 </note>
-                The default mode of the script's operation is to prompt you for
-                information needed to generate the layer:
+                The default mode of the script's operation with this
+                subcommand is to create a layer with the following:
                 <itemizedlist>
-                    <listitem><para>The layer priority.
+                    <listitem><para>A layer priority of 6.
                         </para></listitem>
-                    <listitem><para>Whether or not to create a sample recipe.
+                    <listitem><para>A <filename>conf</filename>
+                        subdirectory that contains a
+                        <filename>layer.conf</filename> file.
                         </para></listitem>
-                    <listitem><para>Whether or not to create a sample
-                        append file.
+                    <listitem><para>
+                        A <filename>recipes-example</filename> subdirectory
+                        that contains a further subdirectory named
+                        <filename>example</filename>, which contains
+                        an <filename>example.bb</filename> recipe file.
+                        </para></listitem>
+                    <listitem><para>A <filename >COPYING.MIT</filename>,
+                        which is the license statement for the layer.
+                        The script assumes you want to use the MIT license,
+                        which is typical for most layers, for the contents of
+                        the layer itself.
+                        </para></listitem>
+                    <listitem><para>
+                        A <filename>README</filename> file, which is a file
+                        describing the contents of your new layer.
                         </para></listitem>
                 </itemizedlist>
             </para>
 
             <para>
-                Use the <filename>yocto-layer create</filename> sub-command
-                to create a new general layer.
-                In its simplest form, you can create a layer as follows:
+                In its simplest form, you can use the following command form
+                to create a layer.
+                The command creates a layer whose name corresponds to
+                <replaceable>your_layer_name</replaceable> in the current
+                directory:
                 <literallayout class='monospaced'>
-     $ yocto-layer create mylayer
+     $ bitbake-layers create-layer <replaceable>your_layer_name</replaceable>
                 </literallayout>
-                The previous example creates a layer named
-                <filename>meta-mylayer</filename> in the current directory.
             </para>
 
             <para>
-                As the <filename>yocto-layer create</filename> command runs,
-                default values for the prompts appear in brackets.
-                Pressing enter without supplying anything for the prompts
-                or pressing enter and providing an invalid response causes the
-                script to accept the default value.
-                Once the script completes, the new layer
-                is created in the current working directory.
-                The script names the layer by prepending
-                <filename>meta-</filename> to the name you provide.
+                If you want to set the priority of the layer to other than the
+                default value of "6", you can either use the
+                <filename>&dash;&dash;priority</filename> option or you can
+                edit the
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-BBFILE_PRIORITY'><filename>BBFILE_PRIORITY</filename></ulink>
+                value in the <filename>conf/layer.conf</filename> after the
+                script creates it.
+                Furthermore, if you want to give the example recipe file
+                some name other than the default, you can
+                use the
+                <filename>&dash;&dash;example-recipe-name</filename> option.
             </para>
 
             <para>
-                Minimally, the script creates the following within the layer:
-                <itemizedlist>
-                    <listitem><para><emphasis>The <filename>conf</filename>
-                        directory:</emphasis>
-                        This directory contains the layer's configuration file.
-                        The root name for the file is the same as the root name
-                        your provided for the layer (e.g.
-                        <filename><replaceable>layer</replaceable>.conf</filename>).
-                        </para></listitem>
-                    <listitem><para><emphasis>The
-                        <filename>COPYING.MIT</filename> file:</emphasis>
-                        The copyright and use notice for the software.
-                        </para></listitem>
-                    <listitem><para><emphasis>The <filename>README</filename>
-                        file:</emphasis>
-                        A file describing the contents of your new layer.
-                        </para></listitem>
-                </itemizedlist>
-            </para>
-
-            <para>
-                If you choose to generate a sample recipe file, the script
-                prompts you for the name for the recipe and then creates it
-                in <filename><replaceable>layer</replaceable>/recipes-example/example/</filename>.
-                The script creates a <filename>.bb</filename> file and a
-                directory, which contains a sample
-                <filename>helloworld.c</filename> source file, along with
-                a sample patch file.
-                If you do not provide a recipe name, the script uses
-                "example".
-            </para>
-
-            <para>
-                If you choose to generate a sample append file, the script
-                prompts you for the name for the file and then creates it
-                in <filename><replaceable>layer</replaceable>/recipes-example-bbappend/example-bbappend/</filename>.
-                The script creates a <filename>.bbappend</filename> file and a
-                directory, which contains a sample patch file.
-                If you do not provide a recipe name, the script uses
-                "example".
-                The script also prompts you for the version of the append file.
-                The version should match the recipe to which the append file
-                is associated.
-            </para>
-
-            <para>
-                The easiest way to see how the <filename>yocto-layer</filename>
-                script works is to experiment with the script.
+                The easiest way to see how the
+                <filename>bitbake-layers create-layer</filename> command
+                works is to experiment with the script.
                 You can also read the usage information by entering the
                 following:
                 <literallayout class='monospaced'>
-     $ yocto-layer help
+     $ bitbake-layers create-layer --help
+     NOTE: Starting bitbake server...
+     usage: bitbake-layers create-layer [-h] [--priority PRIORITY]
+                                        [--example-recipe-name EXAMPLERECIPE]
+                                        layerdir
+
+     Create a basic layer
+
+     positional arguments:
+       layerdir              Layer directory to create
+
+     optional arguments:
+       -h, --help            show this help message and exit
+       --priority PRIORITY, -p PRIORITY
+                             Layer directory to create
+       --example-recipe-name EXAMPLERECIPE, -e EXAMPLERECIPE
+                             Filename of the example recipe
                 </literallayout>
             </para>
 
             <para>
                 Once you create your general layer, you must add it to your
                 <filename>bblayers.conf</filename> file.
-                Here is an example where a layer named
-                <filename>meta-mylayer</filename> is added:
+                You can add your layer by using the
+                <filename>bitbake-layers add-layer</filename> command:
                 <literallayout class='monospaced'>
-     BBLAYERS = ?" \
-        /usr/local/src/yocto/meta \
-        /usr/local/src/yocto/meta-poky \
-        /usr/local/src/yocto/meta-yocto-bsp \
-        /usr/local/src/yocto/meta-mylayer \
-        "
+     $ bitbake-layers add-layer <replaceable>your_layer_name</replaceable>
+                </literallayout>
+                Here is an example where a layer named
+                <filename>meta-scottrif</filename> is added and then the
+                layers are shown using the
+                <filename>bitbake-layers show-layers</filename> command:
+                <literallayout class='monospaced'>
+     $ bitbake-layers add-layer meta-scottrif
+     NOTE: Starting bitbake server...
+     Loading cache: 100% |############################################| Time: 0:00:00
+     Loaded 1275 entries from dependency cache.
+     Parsing recipes: 100% |##########################################| Time: 0:00:00
+     Parsing of 819 .bb files complete (817 cached, 2 parsed). 1276 targets, 44 skipped, 0 masked, 0 errors.
+     $ bitbake-layers show-layers
+     NOTE: Starting bitbake server...
+     layer                 path                                      priority
+     ==========================================================================
+     meta                  /home/scottrif/poky/meta                  5
+     meta-poky             /home/scottrif/poky/meta-poky             5
+     meta-yocto-bsp        /home/scottrif/poky/meta-yocto-bsp        5
+     meta-mylayer          /home/scottrif/meta-mylayer               6
+     workspace             /home/scottrif/poky/build/workspace       99
+     meta-scottrif         /home/scottrif/poky/build/meta-scottrif   6
                 </literallayout>
                 Adding the layer to this file enables the build system to
                 locate the layer during the build.
@@ -1509,8 +1528,8 @@
                     You can find a complete description of the
                     <filename>devtool add</filename> command in the
                     "<ulink url='&YOCTO_DOCS_SDK_URL;#sdk-a-closer-look-at-devtool-add'>A Closer Look at <filename>devtool</filename> add</ulink>"
-                    section in the Yocto Project Software Development Kit
-                    (SDK) Developer's Guide.
+                    section in the Yocto Project Application Development
+                    and the Extensible Software Development Kit (eSDK) manual.
                 </para>
             </section>
 
@@ -3775,9 +3794,9 @@
                 clean a recipe or have <filename>rm_work</filename> enabled,
                 the
                 <ulink url='&YOCTO_DOCS_SDK_URL;#using-devtool-in-your-sdk-workflow'><filename>devtool</filename> workflow</ulink>
-                as described in the Yocto Project Software Development Kit
-                (SDK) Developer's Guide is a safer development flow than the
-                flow that uses Quilt.
+                as described in the Yocto Project Application Development
+                and the Extensible Software Development Kit (eSDK) manual
+                is a safer development flow than the flow that uses Quilt.
             </note>
         </para>
 
@@ -6060,7 +6079,7 @@ Some notes from Cal:
                     configuration file makes it easier to reproduce the same
                     build configuration when using multiple build machines.
                     See the
-                    "<link linkend='creating-a-general-layer-using-the-yocto-layer-script'>Creating a General Layer Using the yocto-layer Script</link>"
+                    "<link linkend='creating-a-general-layer-using-the-bitbake-layers-script'>Creating a General Layer Using the <filename>bitbake-layers</filename> Script</link>"
                     section for information on how to quickly set up a layer.
                     </para></listitem>
                 <listitem><para><emphasis>Create the distribution configuration file:</emphasis>
@@ -9993,182 +10012,6 @@ Some notes from Cal:
         </para>
     </section>
 
-<!--
-        <section id='platdev-gdb-remotedebug-setup'>
-            <title>Set Up the Cross-Development Debugging Environment</title>
-
-            <para>
-                Before you can initiate a remote debugging session, you need
-                to be sure you have set up the cross-development environment,
-                toolchain, and sysroot.
-                The <ulink url='&YOCTO_DOCS_SDK_URL;#sdk-intro'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>
-                describes this process.
-            </para>
-        </section>
-
-        <section id="platdev-gdb-remotedebug-launch-gdbserver">
-            <title>Launch gdbserver on the Target</title>
-
-            <para>
-                Make sure gdbserver is installed on the target.
-                If it is not, install the package
-                <filename>gdbserver</filename>, which needs the
-                <filename>libthread-db1</filename> package.
-            </para>
-
-            <para>
-                Here is an example, that when entered from the host,
-                connects to the target and launches gdbserver in order to
-                "debug" a binary named <filename>helloworld</filename>:
-                <literallayout class='monospaced'>
-     $ gdbserver localhost:2345 /usr/bin/helloworld
-                </literallayout>
-                gdbserver should now be listening on port 2345 for debugging
-                commands coming from a remote GDB process that is running on
-                the host computer.
-                Communication between gdbserver and the host GDB are done
-                using TCP.
-                To use other communication protocols, please refer to the
-                <ulink url='http://www.gnu.org/software/gdb/'>Gdbserver documentation</ulink>.
-            </para>
-        </section>
-
-        <section id="platdev-gdb-remotedebug-launch-gdb">
-            <title>Launch GDB on the Host Computer</title>
-
-            <para>
-                Running GDB on the host computer takes a number of stages, which
-                this section describes.
-            </para>
-
-            <section id="platdev-gdb-remotedebug-launch-gdb-buildcross">
-                <title>Build the Cross-GDB Package</title>
-                <para>
-                    A suitable GDB cross-binary is required that runs on your
-                    host computer but also knows about the the ABI of the
-                    remote target.
-                    You can get this binary from the
-                    <link linkend='cross-development-toolchain'>Cross-Development Toolchain</link>.
-                    Here is an example where the toolchain has been installed
-                    in the default directory
-                    <filename>/opt/poky/&DISTRO;</filename>:
-                    <literallayout class='monospaced'>
-     /opt/poky/&DISTRO;/sysroots/i686-pokysdk-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi/arm-poky-linux-gnueabi-gdb
-                    </literallayout>
-                    where <filename>arm</filename> is the target architecture
-                    and <filename>linux-gnueabi</filename> is the target ABI.
-                </para>
-
-                <para>
-                    Alternatively, you can use BitBake to build the
-                    <filename>gdb-cross</filename> binary.
-                    Here is an example:
-                    <literallayout class='monospaced'>
-     $ bitbake gdb-cross
-                    </literallayout>
-                    Once the binary is built, you can find it here:
-                    <literallayout class='monospaced'>
-     tmp/sysroots/<replaceable>host-arch</replaceable>/usr/bin/<replaceable>target-platform</replaceable>/<replaceable>target-abi</replaceable>-gdb
-                    </literallayout>
-                </para>
-            </section>
-
-            <section id='create-the-gdb-initialization-file'>
-                <title>Create the GDB Initialization File and Point to Your Root Filesystem</title>
-
-                <para>
-                    Aside from the GDB cross-binary, you also need a GDB
-                    initialization file in the same top directory in which
-                    your binary resides.
-                    When you start GDB on your host development system, GDB
-                    finds this initialization file and executes all the
-                    commands within.
-                    For information on the <filename>.gdbinit</filename>, see
-                    "<ulink url='http://sourceware.org/gdb/onlinedocs/gdb/'>Debugging with GDB</ulink>",
-                    which is maintained by
-                    <ulink url='http://www.sourceware.org'>sourceware.org</ulink>.
-                </para>
-
-                <para>
-                    You need to add a statement in the
-                    <filename>~/.gdbinit</filename> file that points to your
-                    root filesystem.
-                    Here is an example that points to the root filesystem for
-                    an ARM-based target device:
-                    <literallayout class='monospaced'>
-     set sysroot ~/sysroot_arm
-                    </literallayout>
-                </para>
-            </section>
-
-            <section id="platdev-gdb-remotedebug-launch-gdb-launchhost">
-                <title>Launch the Host GDB</title>
-
-                <para>
-                    Before launching the host GDB, you need to be sure
-                    you have sourced the cross-debugging environment script,
-                    which if you installed the root filesystem in the default
-                    location is at <filename>/opt/poky/&DISTRO;</filename>
-                    and begins with the string "environment-setup".
-                    For more information, see the
-                    <ulink url='&YOCTO_DOCS_SDK_URL;#sdk-manual'>Yocto Project Software Development Kit (SDK) Developer's
-                    Guide</ulink>.
-                </para>
-
-                <para>
-                    Finally, switch to the directory where the binary resides
-                    and run the <filename>cross-gdb</filename> binary.
-                    Provide the binary file you are going to debug.
-                    For example, the following command continues with the
-                    example used in the previous section by loading
-                    the <filename>helloworld</filename> binary as well as the
-                    debugging information:
-                    <literallayout class='monospaced'>
-     $ arm-poky-linux-gnuabi-gdb helloworld
-                    </literallayout>
-                    The commands in your <filename>.gdbinit</filename> execute
-                    and the GDB prompt appears.
-                </para>
-            </section>
-        </section>
-
-        <section id='platdev-gdb-connect-to-the-remote-gdb-server'>
-            <title>Connect to the Remote GDB Server</title>
-
-            <para>
-                From the target, you need to connect to the remote GDB
-                server that is running on the host.
-                You need to specify the remote host and port.
-                Here is the command continuing with the example:
-                <literallayout class='monospaced'>
-     target remote 192.168.7.2:2345
-                </literallayout>
-            </para>
-        </section>
-
-        <section id="platdev-gdb-remotedebug-launch-gdb-using">
-            <title>Use the Debugger</title>
-
-            <para>
-                You can now proceed with debugging as normal - as if you were debugging
-                on the local machine.
-                For example, to instruct GDB to break in the "main" function and then
-                continue with execution of the inferior binary use the following commands
-                from within GDB:
-                <literallayout class='monospaced'>
-     (gdb) break main
-     (gdb) continue
-                </literallayout>
-            </para>
-
-            <para>
-                For more information about using GDB, see the project's online documentation at
-                <ulink url="http://sourceware.org/gdb/download/onlinedocs/"/>.
-            </para>
-        </section>
-    </section>
--->
-
     <section id='debugging-with-the-gnu-project-debugger-gdb-on-the-target'>
         <title>Debugging with the GNU Project Debugger (GDB) on the Target</title>
 

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

@@ -4,12 +4,12 @@
 
 <chapter id='dev-manual-intro'>
 
-<title>The Yocto Project Development Manual</title>
+<title>The Yocto Project Development Tasks Manual</title>
     <section id='dev-welcome'>
         <title>Welcome</title>
 
         <para>
-            Welcome to the Yocto Project Development Manual!
+            Welcome to the Yocto Project Development Tasks Manual!
             This manual provides relevant procedures necessary for developing
             in the Yocto Project environment (i.e. developing embedded Linux
             images and user-space applications that run on targeted devices).
@@ -53,8 +53,8 @@
                 <listitem><para>
                     <emphasis>Redundant Step-by-step Instructions:</emphasis>
                     For example, the
-                    <ulink url='&YOCTO_DOCS_SDK_URL;'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>
-                    contains detailed instructions on how to install an
+                    <ulink url='&YOCTO_DOCS_SDK_URL;'>Yocto Project Application Development and the Extensible Software Development Kit (eSDK)</ulink>
+                    manual contains detailed instructions on how to install an
                     SDK, which is used to develop applications for target
                     hardware.
                     </para></listitem>

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

@@ -164,7 +164,8 @@
                         <trademark class='trade'>Eclipse</trademark> IDE
                         and SDK development practices.
                         For more information, see the
-                        "<ulink url='&YOCTO_DOCS_SDK_URL;'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>".
+                        "<ulink url='&YOCTO_DOCS_SDK_URL;'>Yocto Project Application Development and the Extensible Software Development Kit (eSDK)</ulink>"
+                        manual.
                         </para></listitem>
                     <listitem><para>
                         Keep your cross-development toolchains updated.
@@ -491,8 +492,8 @@
     <para id='figuring-out-the-mailing-list-to-use'>
         The "poky" repository, which is the Yocto Project's reference build
         environment, is a hybrid repository that contains several
-        individual pieces (e.g. BitBake, OpenEmbedded-Core, meta-yocto,
-        documentation, and so forth) built using the combo-layer tool.
+        individual pieces (e.g. BitBake, Metadata, documentation,
+        and so forth) built using the combo-layer tool.
         The upstream location used for submitting changes varies by
         component:
         <itemizedlist>
@@ -514,10 +515,8 @@
                 mailing list.
                 </para></listitem>
             <listitem><para>
-                <emphasis>"meta-yocto-bsp" and "meta-poky" trees:</emphasis>
-                These trees are
-                part of the "meta-yocto" repository in the Yocto Project
-                source repositories.
+                <emphasis>"meta-*" trees:</emphasis>
+                These trees contain Metadata.
                 Use the
                 <ulink url='https://lists.yoctoproject.org/listinfo/poky'>poky</ulink>
                 mailing list.
@@ -744,7 +743,7 @@
                             file, which is located in the
                             <ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink>
                             at
-                            <filename>meta-poky/conf/distro/include</filename>,
+                            <filename>meta/conf/distro/include</filename>,
                             to see who is responsible for code.
                             </para></listitem>
                         <listitem><para>

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

@@ -29,9 +29,9 @@
                     <emphasis>Install QEMU:</emphasis>
                     See
                     "<ulink url='&YOCTO_DOCS_SDK_URL;#the-qemu-emulator'>The QEMU Emulator</ulink>"
-                    section in the Yocto Project Software Development Kit (SDK)
-                    Developer's Guide for information on how to install
-                    QEMU.
+                    section in the Yocto Project Application Development and
+                    the Extensible Software Development Kit (eSDK) manual
+                    for information on how to install QEMU.
                     </para></listitem>
                 <listitem><para>
                     <emphasis>Setting Up the Environment:</emphasis>
@@ -85,9 +85,9 @@
 
                     <para>See the
                     "<ulink url='&YOCTO_DOCS_SDK_URL;#sdk-extracting-the-root-filesystem'>Extracting the Root Filesystem</ulink>"
-                    section in the Yocto Project Software Development Kit (SDK)
-                    Developer's Guide for information on how to extract a
-                    root filesystem.
+                    section in the Yocto Project Application Development and
+                    the Extensible Software Development Kit (eSDK) manual
+                    for information on how to extract a root filesystem.
                     </para></listitem>
                 <listitem><para>
                     <emphasis>Run QEMU:</emphasis>
@@ -104,7 +104,7 @@
                     look for an image.
                     Minimally, through the use of options, you must provide
                     either a machine name, a virtual machine image
-                    (<filename>*.vmdk</filename>), or a kernel image
+                    (<filename>*wic.vmdk</filename>), or a kernel image
                     (<filename>*.bin</filename>).</para>
 
                     <para>Here are some additional examples to help illustrate

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

@@ -52,9 +52,9 @@
             <listitem><para>
                 <emphasis>Eclipse Development:</emphasis>
                 See the
-                "<ulink url='&YOCTO_DOCS_SDK_URL;#sdk-developing-applications-using-eclipse'>Developing Applications Using Eclipse</ulink>"
-                section in the Yocto Project Software Development Kit (SDK)
-                Developer's Guide.
+                "<ulink url='&YOCTO_DOCS_SDK_URL;#sdk-eclipse-project'>Developing Applications Using <trademark class='trade'>Eclipse</trademark></ulink>"
+                Chapter in the Yocto Project Application Development and the
+                Extensible Software Development Kit (eSDK) manual.
                 </para></listitem>
         </itemizedlist>
     </para>
@@ -131,8 +131,8 @@
             section.
             If you are going to use the Extensible SDK, see the
             "<ulink url='&YOCTO_DOCS_SDK_URL;#sdk-extensible'>Using the Extensible SDK</ulink>"
-            Chapter in the Yocto Project Software Development Kit (SDK)
-            Developer's Guide.
+            Chapter in the Yocto Project Application Development and the
+            Extensible Software Development Kit (eSDK) manual.
             If you want to work on the kernel, see the
             <ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;'>Yocto Project Linux Kernel Development Manual</ulink>.
             If you are going to use Toaster, see the
@@ -241,8 +241,8 @@
             section.
             If you are going to use the Extensible SDK container, see the
             "<ulink url='&YOCTO_DOCS_SDK_URL;#sdk-extensible'>Using the Extensible SDK</ulink>"
-            Chapter in the Yocto Project Software Development Kit (SDK)
-            Developer's Guide.
+            Chapter in the Yocto Project Application Development and the
+            Extensible Software Development Kit (eSDK) manual.
             If you are going to use the Toaster container, see the
             "<ulink url='&YOCTO_DOCS_TOAST_URL;#toaster-manual-setup-and-use'>Setting Up and Using Toaster</ulink>"
             section in the Toaster User Manual.
@@ -676,8 +676,8 @@
                     For information on how to use
                     <filename>devtool</filename> to build images, see the
                     "<ulink url='&YOCTO_DOCS_SDK_URL;#using-devtool-in-your-sdk-workflow'>Using <filename>devtool</filename> in Your SDK Workflow</ulink>"
-                    section in the Yocto Project Software Development Kit
-                    (SDK) Developer's Guide.
+                    section in the Yocto Project Application Development and
+                    the Extensible Software Development Kit (eSDK) manual.
                     </para></listitem>
             </itemizedlist>
         </note>
@@ -744,56 +744,6 @@
     </para>
 </section>
 
-<!--
-<section id='using-pre-built-binaries-and-qemu'>
-    <title>Using Pre-Built Binaries and QEMU</title>
-
-    <para>
-        Another option you have to get started is to use pre-built binaries.
-        The Yocto Project provides many types of binaries with each release.
-        See the "<ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Images</ulink>"
-        chapter in the Yocto Project Reference Manual
-        for descriptions of the types of binaries that ship with a Yocto Project
-        release.
-    </para>
-
-    <para>
-        Using a pre-built binary is ideal for developing software
-        applications to run on your target hardware.
-        To do this, you need to be able to access the appropriate
-        cross-toolchain tarball for the architecture on which you are
-        developing.
-        If you are using an SDK type image, the image ships with the complete
-        toolchain native to the architecture (i.e. a toolchain designed to
-        run on the
-        <ulink url='&YOCTO_DOCS_REF_URL;#var-SDKMACHINE'><filename>SDKMACHINE</filename></ulink>).
-        If you are not using an SDK type image, you need to separately download
-        and install the stand-alone Yocto Project cross-toolchain tarball.
-        See the
-        "<ulink url='&YOCTO_DOCS_SDK_URL;#sdk-appendix-obtain'>Obtaining the SDK</ulink>"
-        appendix in the Yocto Project Software Development Kit (SDK)
-        Developer's Guide for more information on locating and installing
-        cross-toolchains.
-    </para>
-
-    <para>
-        Regardless of the type of image you are using, you need to download the pre-built kernel
-        that you will boot in the QEMU emulator and then download and extract the target root
-        filesystem for your target machine’s architecture.
-        You can get architecture-specific binaries and file systems from
-        <ulink url='&YOCTO_MACHINES_DL_URL;'>machines</ulink>.
-        You can get installation scripts for stand-alone toolchains from
-        <ulink url='&YOCTO_TOOLCHAIN_DL_URL;'>toolchains</ulink>.
-        Once you have all your files, you set up the environment to emulate the hardware
-        by sourcing an environment setup script.
-        Finally, you start the QEMU emulator.
-        You can find details on all these steps in the
-        <ulink url='&YOCTO_DOCS_SDK_URL;#sdk-manual'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>.
-        You can learn more about using QEMU with the Yocto Project in the
-        "<link linkend='dev-manual-qemu'>Using the Quick EMUlator (QEMU)</link>"
-        section.
-    </para>
-</section>
 -->
 </chapter>
 <!--

documentation/dev-manual/dev-manual.xml

@@ -17,14 +17,14 @@
         </mediaobject>
 
         <title>
-            Yocto Project Development Manual
+            Yocto Project Development Tasks Manual
         </title>
 
         <authorgroup>
             <author>
                 <firstname>Scott</firstname> <surname>Rifenbark</surname>
                 <affiliation>
-                    <orgname>Scotty's Documentation Services, Inc.</orgname>
+                    <orgname>Scotty's Documentation Services, INC</orgname>
                 </affiliation>
                 <email>srifenbark@gmail.com</email>
             </author>
@@ -115,33 +115,34 @@
           Creative Commons Attribution-Share Alike 2.0 UK: England &amp; Wales</ulink> as published by
           Creative Commons.
       </para>
-
-            <note><title>Manual Notes</title>
-                <itemizedlist>
-                    <listitem><para>
-                        For the latest version of the Yocto Project Development
-                        Manual associated with this Yocto Project release
-                        (version &YOCTO_DOC_VERSION;),
-                        see the Yocto Project Development Manual from the
-                        <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink>.
+           <note><title>Manual Notes</title>
+               <itemizedlist>
+                   <listitem><para>
+                       This version of the
+                       <emphasis>Yocto Project Development Tasks Manual</emphasis>
+                       is for the &YOCTO_DOC_VERSION; release of the
+                       Yocto Project.
+                       To be sure you have the latest version of the manual
+                       for this release, use the manual from the
+                       <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink>.
+                       </para></listitem>
+                   <listitem><para>
+                       For manuals associated with other releases of the Yocto
+                       Project, go to the
+                       <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink>
+                       and use the drop-down "Active Releases" button
+                       and choose the manual associated with the desired
+                       Yocto Project.
+                       </para></listitem>
+                   <listitem><para>
+                        To report any inaccuracies or problems with this
+                        manual, send an email to the Yocto Project
+                        discussion group at
+                        <filename>yocto@yoctoproject.com</filename> or log into
+                        the freenode <filename>#yocto</filename> channel.
                         </para></listitem>
-                    <listitem><para>
-                        This version of the manual is version
-                        &YOCTO_DOC_VERSION;.
-                        For later releases of the Yocto Project (if they exist),
-                        go to the
-                        <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink>
-                        and use the drop-down "Active Releases" button
-                        and choose the Yocto Project version for which you want
-                        the manual.
-                        </para></listitem>
-                    <listitem><para>
-                        For an in-development version of the Yocto Project
-                        Development Manual, see
-                        <ulink url='&YOCTO_DOCS_URL;/latest/dev-manual/dev-manual.html'></ulink>.
-                        </para></listitem>
-                </itemizedlist>
-            </note>
+               </itemizedlist>
+           </note>
     </legalnotice>
 
     </bookinfo>

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

@@ -26,14 +26,14 @@
             sure your build host is set up to use the Yocto Project.
             For information on how to get set up, see the
             "<ulink url='&YOCTO_DOCS_DEV_URL;#setting-up-the-development-host-to-use-the-yocto-project'>Setting Up to Use the Yocto Project</ulink>"
-            section in the Yocto Project Development Manual.
+            section in the Yocto Project Development Tasks Manual.
             Part of preparing the system is creating a local Git
             repository of the
             <ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink>
             (<filename>poky</filename>) on your system.
             Follow the steps in the
             "<ulink url='&YOCTO_DOCS_DEV_URL;#cloning-the-poky-repository'>Cloning the <filename>poky</filename> Repository</ulink>"
-            section in the Yocto Project Development Manual to set up your
+            section in the Yocto Project Development Tasks Manual to set up your
             Source Directory.
             <note>
                 Be sure you check out the appropriate development branch or
@@ -43,7 +43,7 @@
                 "<ulink url='&YOCTO_DOCS_DEV_URL;#checking-out-by-branch-in-poky'>Checking Out by Branch in Poky</ulink>"
                 and
                 "<ulink url='&YOCTO_DOCS_DEV_URL;#checkout-out-by-tag-in-poky'>Checking Out by Tag in Poky</ulink>"
-                sections in the Yocto Project Development Manual for more
+                sections in the Yocto Project Development Tasks Manual for more
                 information.
             </note>
         </para>
@@ -115,32 +115,31 @@
                         <emphasis>Create a Layer for Patches:</emphasis>
                         You need to create a layer to hold patches created
                         for the kernel image.
-                        You can use the <filename>yocto-layer</filename> command
-                        as follows:
+                        You can use the
+                        <filename>bitbake-layers create-layer</filename>
+                        command as follows:
                         <literallayout class='monospaced'>
-     $ cd ~/poky
-     $ yocto-layer create mylayer -o ../meta-mylayer
-      Please enter the layer priority you'd like to use for the layer: [default: 6]
-      Would you like to have an example recipe created? (y/n) [default: n]
-      Would you like to have an example bbappend file created? (y/n) [default: n]
-
-      New layer created in ../meta-mylayer.
-
-      Don't forget to add it to your BBLAYERS (for details see ../meta-mylayer/README).
+     $ cd ~/poky/build
+     $ bitbake-layers create-layer ../../meta-mylayer
+     NOTE: Starting bitbake server...
+     Add your new layer with 'bitbake-layers add-layer ../../meta-mylayer'
+     $
                         </literallayout>
                         <note>
                             For background information on working with
                             common and BSP layers, see the
                             "<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and Creating Layers</ulink>"
-                            section in the Yocto Project Development Manual
-                            and the
+                            section in the Yocto Project Development Tasks
+                            Manual and the
                             "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-layers'>BSP Layers</ulink>"
                             section in the Yocto Project Board Support (BSP)
                             Developer's Guide, respectively.
                             For information on how to use the
-                            <filename>yocto-layer</filename> script, 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 Manual.
+                            <filename>bitbake-layers create-layer</filename>
+                            command, see the
+                            "<ulink url='&YOCTO_DOCS_DEV_URL;#creating-a-general-layer-using-the-bitbake-layers-script'>Creating a General Layer Using the <filename>bitbake-layers</filename> Script</ulink>"
+                            section in the Yocto Project Development Tasks
+                            Manual.
                         </note>
                         </para></listitem>
                     <listitem><para>
@@ -154,6 +153,8 @@
                         <literallayout class='monospaced'>
      $ cd ~/poky/build
      $ bitbake-layers add-layer ../../meta-mylayer
+     NOTE: Starting bitbake server...
+     $
                         </literallayout>
                         </para></listitem>
                     <listitem><para>
@@ -292,7 +293,7 @@
                         If you need to checkout out the &DISTRO_NAME; branch,
                         see the
                         "<ulink url='&YOCTO_DOCS_DEV_URL;#checking-out-by-branch-in-poky'>Checking out by Branch in Poky</ulink>"
-                        section in the Yocto Project Development Manual.
+                        section in the Yocto Project Development Tasks Manual.
                         <literallayout class='monospaced'>
      $ cd ~/poky
      $ git branch
@@ -339,32 +340,30 @@
                         <emphasis>Create a Layer for Patches:</emphasis>
                         You need to create a layer to hold patches created
                         for the kernel image.
-                        You can use the <filename>yocto-layer</filename> command
-                        as follows:
+                        You can use the
+                        <filename>bitbake-layers create-layer</filename>
+                        command as follows:
                         <literallayout class='monospaced'>
-     $ cd ~/poky
-     $ yocto-layer create mylayer -o ../meta-mylayer
-      Please enter the layer priority you'd like to use for the layer: [default: 6]
-      Would you like to have an example recipe created? (y/n) [default: n]
-      Would you like to have an example bbappend file created? (y/n) [default: n]
-
-      New layer created in ../meta-mylayer.
-
-      Don't forget to add it to your BBLAYERS (for details see ../meta-mylayer/README).
+     $ cd ~/poky/build
+     $ bitbake-layers create-layer ../../meta-mylayer
+     NOTE: Starting bitbake server...
+     Add your new layer with 'bitbake-layers add-layer ../../meta-mylayer'
                         </literallayout>
                         <note>
                             For background information on working with
                             common and BSP layers, see the
                             "<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and Creating Layers</ulink>"
-                            section in the Yocto Project Development Manual
-                            and the
+                            section in the Yocto Project Development Tasks
+                            Manual and the
                             "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-layers'>BSP Layers</ulink>"
                             section in the Yocto Project Board Support (BSP)
                             Developer's Guide, respectively.
                             For information on how to use the
-                            <filename>yocto-layer</filename> script, 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 Manual.
+                            <filename>bitbake-layers create-layer</filename>
+                            command, see the
+                            "<ulink url='&YOCTO_DOCS_DEV_URL;#creating-a-general-layer-using-the-bitbake-layers-script'>Creating a General Layer Using the <filename>bitbake-layers</filename> Script</ulink>"
+                            section in the Yocto Project Development Tasks
+                            Manual.
                         </note>
                         </para></listitem>
                     <listitem><para>
@@ -378,6 +377,8 @@
                         <literallayout class='monospaced'>
      $ cd ~/poky/build
      $ bitbake-layers add-layer ../../meta-mylayer
+     NOTE: Starting bitbake server ...
+     $
                         </literallayout>
                         </para></listitem>
                     <listitem><para>
@@ -392,7 +393,7 @@
                         <para>
                         For simplicity, it is recommended that you create your
                         copy of the kernel Git repository outside of the
-                        <ulink url='&YOCTO_DOCS_REF_URL;source-directory'>Source Directory</ulink>,
+                        <ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink>,
                         which is usually named <filename>poky</filename>.
                         Also, be sure you are in the
                         <filename>standard/base</filename> branch.
@@ -428,7 +429,7 @@
                         Repository:</emphasis>
                         For simplicity, it is recommended that you create your
                         copy of the kernel cache Git repository outside of the
-                        <ulink url='&YOCTO_DOCS_REF_URL;source-directory'>Source Directory</ulink>,
+                        <ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink>,
                         which is usually named <filename>poky</filename>.
                         Also, for this example, be sure you are in the
                         <filename>yocto-4.12</filename> branch.
@@ -478,16 +479,17 @@
             patch files.
             For background information on working with layers, see the
             "<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and Creating Layers</ulink>"
-            section in the Yocto Project Development Manual.
+            section in the Yocto Project Development Tasks Manual.
             <note><title>Tip</title>
                 The Yocto Project comes with many tools that simplify
                 tasks you need to perform.
-                One such tool is the <filename>yocto-layer create</filename>
-                script, which simplifies creating a new layer.
+                One such tool is the
+                <filename>bitbake-layers create-layer</filename>
+                command, which simplifies creating a new layer.
                 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 Manual for information
-                on how to use this script.
+                "<ulink url='&YOCTO_DOCS_DEV_URL;#creating-a-general-layer-using-the-bitbake-layers-script'>Creating a General Layer Using the <filename>bitbake-layers</filename> Script</ulink>"
+                section in the Yocto Project Development Tasks Manual for
+                information on how to use this script.
             </note>
         </para>
 
@@ -558,7 +560,7 @@
                     patch files.
                     For more information on using append files, see the
                     "<ulink url='&YOCTO_DOCS_DEV_URL;#using-bbappend-files'>Using .bbappend Files in Your Layer</ulink>"
-                    section in the Yocto Project Development Manual.
+                    section in the Yocto Project Development Tasks Manual.
                     </para></listitem>
             </orderedlist>
         </para>
@@ -573,7 +575,7 @@
             Each release of the Yocto Project provides a few Linux
             kernel recipes from which you can choose.
             These are located in the
-            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+            <ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink>
             in <filename>meta/recipes-kernel/linux</filename>.
         </para>
 
@@ -694,7 +696,7 @@
                 variable could be used to enable features specific to
                 the kernel.
                 The append file points to specific commits in the
-                <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+                <ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink>
                 Git repository and the <filename>meta</filename> Git repository
                 branches to identify the exact kernel needed to build the
                 BSP.
@@ -1425,7 +1427,7 @@
                     sections.
                     You can also see the
                     "<ulink url='&YOCTO_DOCS_DEV_URL;#using-bbappend-files'>Using .bbappend Files in Your Layer"</ulink>"
-                    section in the Yocto Project Development Manual.
+                    section in the Yocto Project Development Tasks Manual.
                     <note>
                         To build <filename>core-image-minimal</filename>
                         again and see the effects of your patch, you can

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

@@ -74,8 +74,9 @@
                         include "kernel-image".</para>
                         <para>See the
                         "<ulink url='&YOCTO_DOCS_DEV_URL;#using-bbappend-files'>Using .bbappend Files in Your Layer</ulink>"
-                        section in the Yocto Project Development Manual for information on
-                        how to use an append file to override metadata.
+                        section in the Yocto Project Development Tasks Manual
+                        for information on how to use an append file to
+                        override metadata.
                     </para>
                 </answer>
             </qandaentry>

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

@@ -112,13 +112,13 @@
                 </para></listitem>
             <listitem><para>
                 <ulink url='&YOCTO_DOCS_SDK_URL;#using-devtool-in-your-sdk-workflow'><filename>devtool</filename> workflow</ulink>
-                as described in the Yocto Project Software Development Kit
-                (SDK) Developer's Guide.
+                as described in the Yocto Project Application Development and
+                the Extensible Software Development Kit (eSDK) manual.
                 </para></listitem>
             <listitem><para>
                 The
-                "<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and Creating Layers</ulink>" section
-                in the Yocto Project Development Manual
+                "<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and Creating Layers</ulink>"
+                section in the Yocto Project Development Tasks Manual.
                 </para></listitem>
             <listitem><para>
                 The

documentation/kernel-dev/kernel-dev.xml

@@ -24,7 +24,7 @@
             <author>
                 <firstname>Scott</firstname> <surname>Rifenbark</surname>
                 <affiliation>
-                    <orgname>Scotty's Documentation Services, INC.</orgname>
+                    <orgname>Scotty's Documentation Services, INC</orgname>
                 </affiliation>
                 <email>srifenbark@gmail.com</email>
             </author>
@@ -101,28 +101,22 @@
            <note><title>Manual Notes</title>
                <itemizedlist>
                    <listitem><para>
-                       For the latest version of the Yocto Project Linux
-                       Kernel Development Manual associated with this Yocto
-                       Project release (version &YOCTO_DOC_VERSION;),
-                       see the Yocto Project Linux Kernel Development
-                       Manual from the
+                       This version of the
+                       <emphasis>Yocto Project Linux Kernel Development Manual</emphasis>
+                       is for the &YOCTO_DOC_VERSION; release of the
+                       Yocto Project.
+                       To be sure you have the latest version of the manual
+                       for this release, use the manual from the
                        <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink>.
                        </para></listitem>
                    <listitem><para>
-                       This version of the manual is version
-                       &YOCTO_DOC_VERSION;.
-                       For later releases of the Yocto Project (if they exist),
-                       go to the
+                       For manuals associated with other releases of the Yocto
+                       Project, go to the
                        <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink>
                        and use the drop-down "Active Releases" button
-                       and choose the Yocto Project version for which you want
-                       the manual.
+                       and choose the manual associated with the desired
+                       Yocto Project.
                        </para></listitem>
-                   <listitem><para>
-                        For an in-development version of the Yocto Project
-                        Linux Kernel Development Manual, see
-                        <ulink url='&YOCTO_DOCS_URL;/latest/kernel-dev/kernel-dev.html'></ulink>.
-                        </para></listitem>
                    <listitem><para>
                         To report any inaccuracies or problems with this
                         manual, send an email to the Yocto Project
@@ -130,8 +124,8 @@
                         <filename>yocto@yoctoproject.com</filename> or log into
                         the freenode <filename>#yocto</filename> channel.
                         </para></listitem>
-                </itemizedlist>
-            </note>
+               </itemizedlist>
+           </note>
     </legalnotice>
 
     </bookinfo>

documentation/mega-manual/mega-manual.xml

@@ -33,7 +33,7 @@
             <author>
                 <firstname>Scott</firstname> <surname>Rifenbark</surname>
                 <affiliation>
-                    <orgname>Intel Corporation</orgname>
+                    <orgname>Scotty's Documentation Services, INC</orgname>
                 </affiliation>
                 <email>srifenbark@gmail.com</email>
             </author>
@@ -85,27 +85,29 @@
            <note><title>Manual Notes</title>
                <itemizedlist>
                    <listitem><para>
-                       For the latest version of the Yocto Project
-                       Mega-Manual associated with this Yocto Project release
-                       (version &YOCTO_DOC_VERSION;),
-                       see the Yocto Project Mega-Manual from the
+                       This version of the
+                       <emphasis>Yocto Project Mega-Manual</emphasis>
+                       is for the &YOCTO_DOC_VERSION; release of the
+                       Yocto Project.
+                       To be sure you have the latest version of the manual
+                       for this release, use the manual from the
                        <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink>.
                        </para></listitem>
                    <listitem><para>
-                       This version of the manual is version
-                       &YOCTO_DOC_VERSION;.
-                       For later releases of the Yocto Project (if they exist),
-                       go to the
+                       For manuals associated with other releases of the Yocto
+                       Project, go to the
                        <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink>
                        and use the drop-down "Active Releases" button
-                       and choose the Yocto Project version for which you want
-                       the manual.
+                       and choose the manual associated with the desired
+                       Yocto Project.
                        </para></listitem>
                    <listitem><para>
-                       For an in-development version of the Yocto Project
-                       Mega-Manual, see
-                       <ulink url='&YOCTO_DOCS_URL;/latest/mega-manual/mega-manual.html'></ulink>.
-                       </para></listitem>
+                        To report any inaccuracies or problems with this
+                        manual, send an email to the Yocto Project
+                        discussion group at
+                        <filename>yocto@yoctoproject.com</filename> or log into
+                        the freenode <filename>#yocto</filename> channel.
+                        </para></listitem>
                </itemizedlist>
            </note>
 
@@ -149,6 +151,8 @@
         xmlns:xi="http://www.w3.org/2003/XInclude" href="../sdk-manual/sdk-using.xml"/>
     <xi:include
         xmlns:xi="http://www.w3.org/2003/XInclude" href="../sdk-manual/sdk-working-projects.xml"/>
+    <xi:include
+        xmlns:xi="http://www.w3.org/2003/XInclude" href="../sdk-manual/sdk-eclipse-project.xml"/>
     <xi:include
         xmlns:xi="http://www.w3.org/2003/XInclude" href="../sdk-manual/sdk-appendix-obtain.xml"/>
     <xi:include

documentation/profile-manual/profile-manual.xml

@@ -22,11 +22,11 @@
 
         <authorgroup>
             <author>
-                <firstname>Tom</firstname> <surname>Zanussi</surname>
+                <firstname>Scott</firstname> <surname>Rifenbark</surname>
                 <affiliation>
-                    <orgname>Intel Corporation</orgname>
+                    <orgname>Scotty's Documentation Services, INC</orgname>
                 </affiliation>
-                <email>tom.zanussi@intel.com</email>
+                <email>srifenbark@gmail.com</email>
             </author>
         </authorgroup>
 
@@ -100,34 +100,34 @@
           Creative Commons Attribution-Share Alike 2.0 UK: England &amp; Wales</ulink> as published by
           Creative Commons.
       </para>
-
-            <note><title>Manual Notes</title>
-                <itemizedlist>
-                    <listitem><para>
-                        For the latest version of the Yocto Project Profiling
-                        and Tracing Manual associated with this Yocto Project
-                        release (version &YOCTO_DOC_VERSION;),
-                        see the Yocto Project Profiling and Tracing Manual
-                        from the
-                        <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink>.
+           <note><title>Manual Notes</title>
+               <itemizedlist>
+                   <listitem><para>
+                       This version of the
+                       <emphasis>Yocto Project Profiling and Tracing Manual</emphasis>
+                       is for the &YOCTO_DOC_VERSION; release of the
+                       Yocto Project.
+                       To be sure you have the latest version of the manual
+                       for this release, use the manual from the
+                       <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink>.
+                       </para></listitem>
+                   <listitem><para>
+                       For manuals associated with other releases of the Yocto
+                       Project, go to the
+                       <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink>
+                       and use the drop-down "Active Releases" button
+                       and choose the manual associated with the desired
+                       Yocto Project.
+                       </para></listitem>
+                   <listitem><para>
+                        To report any inaccuracies or problems with this
+                        manual, send an email to the Yocto Project
+                        discussion group at
+                        <filename>yocto@yoctoproject.com</filename> or log into
+                        the freenode <filename>#yocto</filename> channel.
                         </para></listitem>
-                    <listitem><para>
-                        This version of the manual is version
-                        &YOCTO_DOC_VERSION;.
-                        For later releases of the Yocto Project (if they exist),
-                        go to the
-                        <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink>
-                        and use the drop-down "Active Releases" button
-                        and choose the Yocto Project version for which you want
-                        the manual.
-                        </para></listitem>
-                    <listitem><para>
-                        For an in-development version of the Yocto Project
-                        Profiling and Tracing Manual, see
-                        <ulink url='&YOCTO_DOCS_URL;/latest/profile-manual/profile-manual.html'></ulink>.
-                        </para></listitem>
-                </itemizedlist>
-            </note>
+               </itemizedlist>
+           </note>
     </legalnotice>
 
     </bookinfo>

documentation/ref-manual/faq.xml

@@ -13,10 +13,10 @@
         </question>
         <answer>
             <para>
-                The term "<ulink url='&YOCTO_DOCS_DEV_URL;#poky'>Poky</ulink>"
+                The term "<link link='poky'>Poky</link>"
                 refers to the specific reference build system that
                 the Yocto Project provides.
-                Poky is based on <ulink url='&YOCTO_DOCS_DEV_URL;#oe-core'>OE-Core</ulink>
+                Poky is based on <link linkend='oe-core'>OE-Core</link>
                 and <link linkend='bitbake-term'>BitBake</link>.
                 Thus, the generic term used here for the build system is
                 the "OpenEmbedded build system."
@@ -60,7 +60,7 @@
                 There are three areas that help with stability;
                 <itemizedlist>
                     <listitem><para>The Yocto Project team keeps
-                        <ulink url='&YOCTO_DOCS_DEV_URL;#oe-core'>OE-Core</ulink> small
+                        <link linkend='oe-core'>OE-Core</link> small
                         and focused, containing around 830 recipes as opposed to the thousands
                         available in other OpenEmbedded community layers.
                         Keeping it small makes it easy to test and maintain.</para></listitem>
@@ -86,7 +86,7 @@
                 Board Support Package (BSP) layer for it.
                 For more information on how to create a BSP layer, see the
                 "<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and Creating Layers</ulink>"
-                section in the Yocto Project Development Manual and the
+                section in the Yocto Project Development Tasks Manual and the
                 <ulink url='&YOCTO_DOCS_BSP_URL;'>Yocto Project Board Support Package (BSP) Developer's Guide</ulink>.
             </para>
             <para>
@@ -143,7 +143,7 @@
                 To add a package, you need to create a BitBake recipe.
                 For information on how to create a BitBake recipe, see the
                 "<ulink url='&YOCTO_DOCS_DEV_URL;#new-recipe-writing-a-new-recipe'>Writing a New Recipe</ulink>"
-                in the Yocto Project Development Manual.
+                in the Yocto Project Development Tasks Manual.
             </para>
         </answer>
     </qandaentry>
@@ -417,9 +417,9 @@
 
             <para>
                 You can find more information on licensing in the
-                "<ulink url='&YOCTO_DOCS_REF_URL;#licensing'>Licensing</ulink>"
-                and "<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>"
-                sections, both of which are in the Yocto Project Development
+                "<link linkend='licensing'>Licensing</link>" section and in 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, which is in the Yocto Project Development Tasks
                 Manual.
             </para>
         </answer>
@@ -548,7 +548,7 @@
                 file to include from the
                 <filename>meta/conf/distro/include</filename> directory within
                 the
-                <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+                <link linkend='source-directory'>Source Directory</link>.
             </para>
 
             <para>

documentation/ref-manual/introduction.xml

@@ -33,7 +33,7 @@
         without having to understand concepts, work through the
         <ulink url='&YOCTO_DOCS_QS_URL;'>Yocto Project Quick Start</ulink>.
         You can find "how-to" information in the
-        <ulink url='&YOCTO_DOCS_DEV_URL;'>Yocto Project Development Manual</ulink>.
+        <ulink url='&YOCTO_DOCS_DEV_URL;'>Yocto Project Development Tasks Manual</ulink>.
         <note><title>Tip</title>
             For more information about the Yocto Project Documentation set,
             see the
@@ -154,7 +154,8 @@
         <ulink url='https://www.yoctoproject.org/organization/enea-ab'>ENEA Linux</ulink>
         and <ulink url='https://www.yoctoproject.org/ecosystem/member-organizations'>others</ulink>.
         See the "<ulink url='&YOCTO_DOCS_DEV_URL;#creating-your-own-distribution'>Creating Your Own Distribution</ulink>"
-        section in the Yocto Project Development Manual for more information.
+        section in the Yocto Project Development Tasks Manual for more
+        information.
     </para>
 </section>
 
@@ -651,12 +652,12 @@
     <title>Development Checkouts</title>
     <para>
         Development using the Yocto Project requires a local
-        <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+        <link linkend='source-directory'>Source Directory</link>.
         You can set up the Source Directory by cloning a copy of the upstream
-        <ulink url='&YOCTO_DOCS_DEV_URL;#poky'>poky</ulink> Git repository.
+        <link linkend='poky'>poky</link> Git repository.
         For information on how to do this, see the
         "<ulink url='&YOCTO_DOCS_DEV_URL;#working-with-yocto-project-source-files'>Working With Yocto Project Source Files</ulink>"
-        section in the Yocto Project Development Manual.
+        section in the Yocto Project Development Tasks Manual.
     </para>
 </section>
 
@@ -687,7 +688,7 @@
                 information in the similarly-named recipe file.
                 For an example of an append file in use, see the
                 "<ulink url='&YOCTO_DOCS_DEV_URL;#using-bbappend-files'>Using .bbappend Files in Your Layer</ulink>"
-                section in the Yocto Project Development Manual.
+                section in the Yocto Project Development Tasks Manual.
                 <note>
                     Append files can also use wildcard patterns in their
                     version numbers so they can be applied to more than one
@@ -829,7 +830,8 @@
                 section.
                 You can also find more information on using the
                 relocatable toolchain in the
-                <ulink url='&YOCTO_DOCS_SDK_URL;'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>.
+                <ulink url='&YOCTO_DOCS_SDK_URL;'>Yocto Project Application Development and the Extensible Software Development Kit (eSDK)</ulink>
+                manual.
                 </para></listitem>
             <listitem><para>
                 <emphasis>Image:</emphasis>

documentation/ref-manual/migration.xml

@@ -251,7 +251,7 @@
                 The following recipes have been removed.
                 For most of them, it is unlikely that you would have any
                 references to them in your own
-                <ulink url='&YOCTO_DOCS_REF_URL;#metadata'>Metadata</ulink>.
+                <link linkend='metadata'>Metadata</link>.
                 However, you should check your metadata against this list to be sure:
                 <itemizedlist>
                     <listitem><para><emphasis><filename>libx11-trim</filename></emphasis>:
@@ -293,7 +293,7 @@
                 For the remainder, you can now find them in the
                 <filename>meta-extras</filename> repository, which is in the
                 Yocto Project
-                <ulink url='&YOCTO_DOCS_REF_URL;#source-repositories'>Source Repositories</ulink>.
+                <link linkend='source-repositories'>Source Repositories</link>.
             </para>
         </section>
     </section>
@@ -438,11 +438,11 @@
             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>
+            <link linkend='source-directory'>Source Directory</link>
             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.
+            in the Yocto Project Development Tasks Manual.
         </para>
     </section>
 
@@ -992,7 +992,7 @@
         <para>
             You can learn more about performing automated image tests in the
             "<ulink url='&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing'>Performing Automated Runtime Testing</ulink>"
-            section.
+            section in the Yocto Project Development Tasks Manual.
         </para>
     </section>
 
@@ -1173,7 +1173,7 @@
             class has been rewritten and its configuration has been simplified.
             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.
+            section in the Yocto Project Development Tasks Manual.
         </para>
     </section>
 
@@ -1362,7 +1362,7 @@
                 increments on changes, use the PR service instead.
                 You can find out more about this service in the
                 "<ulink url='&YOCTO_DOCS_DEV_URL;#working-with-a-pr-service'>Working With a PR Service</ulink>"
-                section in the Yocto Project Development Manual.
+                section in the Yocto Project Development Tasks Manual.
             </para>
         </section>
 
@@ -1453,7 +1453,7 @@
             Package Tests (ptest) are built but not installed by default.
             For information on using Package Tests, see the
             "<ulink url='&YOCTO_DOCS_DEV_URL;#testing-packages-with-ptest'>Setting up and running package test (ptest)</ulink>"
-            section in the Yocto Project Development Manual.
+            section in the Yocto Project Development Tasks Manual.
             For information on the <filename>ptest</filename> class, see the
             "<link linkend='ref-classes-ptest'><filename>ptest.bbclass</filename></link>"
             section.
@@ -1525,7 +1525,7 @@
         <para>
             The top-level <filename>LICENSE</filename> file has been changed
             to better describe the license of the various components of
-            OE-Core.
+            <link linkend='oe-core'>OE-Core</link>.
             However, the licensing itself remains unchanged.
         </para>
 
@@ -2572,7 +2572,8 @@
 
         <para>
             Maintenance tracking data for recipes that was previously part
-            of <filename>meta-yocto</filename> has been moved to OE-Core.
+            of <filename>meta-yocto</filename> has been moved to
+            <link linkend='oe-core'>OE-Core</link>.
             The change includes <filename>package_regex.inc</filename> and
             <filename>distro_alias.inc</filename>, which are typically enabled
             when using the
@@ -3209,7 +3210,8 @@
             You can enable, disable, and test the generation of this data.
             See the
             "<ulink url='&YOCTO_DOCS_DEV_URL;#enabling-gobject-introspection-support'>Enabling GObject Introspection Support</ulink>"
-            section for more information.
+            section in the Yocto Project Development Tasks Manual
+            for more information.
         </para>
     </section>
 
@@ -3418,7 +3420,8 @@
                 For help preparing metadata, see any of the many Python 3 porting
                 guides available.
                 Alternatively, you can reference the conversion commits for Bitbake
-                and you can use OE-Core as a guide for changes.
+                and you can use
+                <link linkend='oe-core'>OE-Core</link> as a guide for changes.
                 Following are particular areas of interest:
                 <literallayout class='monospaced'>
      * subprocess command-line pipes needing locale decoding
@@ -3507,7 +3510,8 @@
             hard-coding any knowledge about different machines.
             Using a configuration file is particularly convenient when trying
             to use QEMU with machines other than the
-            <filename>qemu*</filename> machines in OE-Core.
+            <filename>qemu*</filename> machines in
+            <link linkend='oe-core'>OE-Core</link>.
             The <filename>qemuboot.conf</filename> file is generated by the
             <filename>qemuboot</filename>
             class when the root filesystem is being build (i.e.
@@ -4034,7 +4038,7 @@ $ runqemu qemux86-64 tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.
                     <para>For an example, see the
                     <filename>pixbufcache</filename> class in
                     <filename>meta/classes/</filename> in the Yocto Project
-                    <ulink url='&YOCTO_DOCS_REF_URL;#source-repositories'>Source Repositories</ulink>.
+                    <link linkend='source-repositories'>Source Repositories</link>.
                     <note>
                         The <filename>SSTATEPOSTINSTFUNCS</filename> variable
                         itself is now deprecated in favor of the
@@ -4477,7 +4481,8 @@ id=f4d4f99cfbc2396e49c1613a7d237b9e57f06f81'>commit message</ulink>.
                     needed by current hardware.
                     Thus, GStreamer's ivorbis plugin has been disabled
                     by default eliminating the need for the
-                    <filename>tremor</filename> recipe in OE-Core.
+                    <filename>tremor</filename> recipe in
+                    <link linkend='oe-core'>OE-Core</link>.
                     </para></listitem>
                  <listitem><para>
                     <emphasis><filename>gummiboot:</filename></emphasis>
@@ -4495,7 +4500,7 @@ id=f4d4f99cfbc2396e49c1613a7d237b9e57f06f81'>commit message</ulink>.
             <note>
                 For more information on Wic, see the
                 "<ulink url='&YOCTO_DOCS_DEV_URL;#creating-partitioned-images-using-wic'>Creating Partitioned Images Using Wic</ulink>"
-                section in the Yocto Project Development Manual.
+                section in the Yocto Project Development Tasks Manual.
             </note>
             <itemizedlist>
                 <listitem><para>
@@ -4716,6 +4721,530 @@ id=f4d4f99cfbc2396e49c1613a7d237b9e57f06f81'>commit message</ulink>.
         </para>
     </section>
 </section>
+
+<section id='moving-to-the-yocto-project-2.4-release'>
+    <title>Moving to the Yocto Project 2.4 Release</title>
+
+    <para>
+        This section provides migration information for moving to the
+        Yocto Project 2.4 Release from the prior release.
+    </para>
+
+    <section id='migration-2.4-memory-resident-mode'>
+        <title>Memory Resident Mode</title>
+
+        <para>
+            A persistent mode is now available in BitBake's default operation,
+            replacing its previous "memory resident mode" (i.e.
+            <filename>oe-init-build-env-memres</filename>).
+            Now you only need to set
+            <filename>BB_SERVER_TIMEOUT</filename> to a timeout
+            (in seconds) and BitBake's server stays resident for that
+            amount of time between invocations.
+            The <filename>oe-init-build-env-memres</filename> script has been
+            removed which means a separate environment setup script is no longer
+            needed.
+        </para>
+    </section>
+
+    <section id='migration-2.4-packaging-changes'>
+        <title>Packaging Changes</title>
+
+        <para>
+            This section provides information about packaging changes that have
+            ocurred:
+            <itemizedlist>
+                <listitem><para>
+                    <emphasis><filename>python3</filename> Changes:</emphasis>
+                    <itemizedlist>
+                        <listitem><para>
+                            The main "python3" package now brings in all of the
+                            standard Python 3 distributions rather than a subset.
+                            This behavior matches what is expected based on
+                            traditional Linux distributions.
+                            If you wish to install a subset of Python 3, specify
+                            <filename>python-core</filename> plus one or more of
+                            the individual packages that are still produced.
+                            </para></listitem>
+                        <listitem><para>
+                            <emphasis><filename>python3</filename>:</emphasis>
+                            The <filename>bz2.py</filename>,
+                            <filename>lzma.py</filename>, and
+                            <filename>_compression.py</filename> scripts have
+                            been moved from the
+                            <filename>python3-misc</filename> package to
+                            the <filename>python3-compression</filename> package.
+                            </para></listitem>
+                    </itemizedlist>
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis><filename>binutils</filename>:</emphasis>
+                    The <filename>libbfd</filename> package is now packaged in
+                    a separate "libbfd" package.
+                    This packaging saves space when certain tools
+                    (e.g. <filename>perf</filename>) are installed.
+                    In such cases, the tools only need
+                    <filename>libbfd</filename> rather than all the packages in
+                    <filename>binutils</filename>.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis><filename>util-linux</filename> Changes:</emphasis>
+                    <itemizedlist>
+                        <listitem><para>
+                            The <filename>su</filename> package is now packaged
+                            in a separate "util-linux-su" package, which is only
+                            built when "pam" is listed in the
+                            <link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link>
+                            variable.
+                            <filename>util-linux</filename> should not be
+                            installed unless it is needed because
+                            <filename>su</filename> is normally provided through
+                            the shadow file format.
+                            The main <filename>util-linux</filename> package has
+                            runtime dependencies (i.e.
+                            <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>)
+                            on the <filename>util-linux</filename> package when
+                            "pam" is in
+                            <link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link>.
+                            </para></listitem>
+                        <listitem><para>
+                            The <filename>switch_root</filename> package is now
+                            packaged in a separate "util-linux-switch-root"
+                            package for small initramfs images that do not need
+                            the whole <filename>util-linux</filename> package or
+                            the busybox binary, which are both much larger than
+                            <filename>switch_root</filename>.
+                            The main <filename>util-linux</filename> package has
+                            a recommended runtime dependency (i.e.
+                            <link linkend='var-RRECOMMENDS'><filename>RRECOMMENDS</filename></link>)
+                            on the <filename>switch_root</filename> package.
+                            </para></listitem>
+                        <listitem><para>
+                            The <filename>ionice</filename> package is now
+                            packaged in a separate "util-linux-ionice" package.
+                            The main <filename>util-linux</filename> package has
+                            a recommended runtime dependency (i.e.
+                            <link linkend='var-RRECOMMENDS'><filename>RRECOMMENDS</filename></link>)
+                            on the <filename>ionice</filename> package.
+                            </para></listitem>
+                    </itemizedlist>
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis><filename>initscripts</filename>:</emphasis>
+                    The <filename>sushell</filename> package is now packaged in
+                    a separate "initscripts-sushell" package.
+                    This packaging change allows systems to pull
+                    <filename>sushell</filename> in when
+                    <filename>selinux</filename> is enabled.
+                    The change also eliminates needing to pull in the entire
+                    <filename>initscripts</filename> package.
+                    The main <filename>initscripts</filename> package has a
+                    runtime dependency (i.e.
+                    <link linkend='var-RDEPENDS'><filename>RDEPENDS</filename></link>)
+                    on the <filename>sushell</filename> package when
+                    "selinux" is in
+                    <link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link>.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis><filename>glib-2.0</filename>:</emphasis>
+                    The <filename>glib-2.0</filename> package now has a
+                    recommended runtime dependency (i.e.
+                    <link linkend='var-RRECOMMENDS'><filename>RRECOMMENDS</filename></link>)
+                    on the
+                    <filename>shared-mime-info</filename> package, since large
+                    portions of GIO are not useful without the MIME database.
+                    You can remove the dependency by using the
+                    <link linkend='var-BAD_RECOMMENDATIONS'><filename>BAD_RECOMMENDATIONS</filename></link>
+                    variable if <filename>shared-mime-info</filename> is too
+                    large and is not required.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis><filename>Go Standard Runtime</filename>:</emphasis>
+                    The Go standard runtime has been split out from the main
+                    <filename>go</filename> recipe into a separate
+                    <filename>go-runtime</filename> recipe.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-2.4-removed-recipes'>
+        <title>Removed Recipes</title>
+
+        <para>
+            The following recipes have been removed:
+            <itemizedlist>
+                <listitem><para>
+                    <emphasis><filename>acpitests</filename>:</emphasis>
+                    This recipe is not maintained.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis><filename>autogen-native</filename>:</emphasis>
+                    No longer required by Grub, <filename>oe-core</filename>, or
+                    <filename>meta-oe</filename>.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis><filename>bdwgc</filename>:</emphasis>
+                    Nothing in OpenEmbedded-Core requires this recipe.
+                    It has moved to <filename>meta-oe</filename>
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis><filename>byacc</filename>:</emphasis>
+                    This recipe was only needed by rpm 5.x and has moved to
+                    <filename>meta-oe</filename>.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis><filename>gcc (5.4)</filename>:</emphasis>
+                    The 5.4 series dropped the recipe in favor of 6.3 / 7.2.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis><filename>gnome-common</filename>:</emphasis>
+                    Deprecated upstream and no longer needed.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis><filename>go-bootstrap-native</filename>:</emphasis>
+                    Go 1.9 does its own bootstrapping so this recipe has been
+                    removed.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis><filename>guile</filename>:</emphasis>
+                    This recipe was only needed by
+                    <filename>autogen-native</filename> and
+                    <filename>remake</filename>.
+                    It is no longer needed by either of these programs.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis><filename>libclass-isa-perl</filename>:</emphasis>
+                    This recipe was previously needed for LSB 4, which no longer
+                    requires the recipe.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis><filename>libdumpvalue-perl</filename>:</emphasis>
+                    This recipe was previously needed for LSB 4, which no longer
+                    requires the recipe.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis><filename>libenv-perl</filename>:</emphasis>
+                    This recipe was previously needed for LSB 4, which no longer
+                    requires the recipe.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis><filename>libfile-checktree-perl</filename>:</emphasis>
+                    This recipe was previously needed for LSB 4, which no longer
+                    requires the recipe.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis><filename>libi18n-collate-perl</filename>:</emphasis>
+                    This recipe was previously needed for LSB 4, which no longer
+                    requires the recipe.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis><filename>libiconv</filename>:</emphasis>
+                    This recipe was only needed for <filename>uclibc</filename>,
+                    which was removed in the previous release.
+                    <filename>glibc</filename> and <filename>musl</filename>
+                    have their own implementations.
+                    <filename>meta-mingw</filename> still needs
+                    <filename>libiconv</filename>, so it has
+                    been moved to <filename>meta-mingw</filename>.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis><filename>libpng12</filename>:</emphasis>
+                    This recipe was previously needed for LSB. The current
+                    <filename>libpng</filename> is 1.6.x.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis><filename>libpod-plainer-perl</filename>:</emphasis>
+                    This recipe was previously needed for LSB 4, which no longer
+                    requires the recipe.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis><filename>linux-yocto (4.1)</filename>:</emphasis>
+                    This recipe was removed in favor of 4.4, 4.9, 4.10 and 4.12.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis><filename>mailx</filename>:</emphasis>
+                    This recipe was previously only needed for LSB
+                    compatibility, and upstream is defunct.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis><filename>mesa (git version only)</filename>:</emphasis>
+                    This recipe is stale with respect to the release version.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis><filename>ofono (git version only)</filename>:</emphasis>
+                    This recipe is stale with respect to the release version.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis><filename>portmap</filename>:</emphasis>
+                    This recipe is obsolete and is superseded by
+                    <filename>rpcbind</filename>.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis><filename>python3-pygpgme</filename>:</emphasis>
+                    This recipe is old and unmaintained. It was previously
+                    required by <filename>dnf</filename>, which has switched
+                    to official <filename>gpgme</filename> Python bindings.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis><filename>python-async</filename>:</emphasis>
+                    This recipe has been removed in favor of the Python 3
+                    version.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis><filename>python-gitdb</filename>:</emphasis>
+                    This recipe has been removed in favor of the Python 3
+                    version.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis><filename>python-git</filename>:</emphasis>
+                    This recipe was removed in favor of the Python 3
+                    version.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis><filename>python-mako</filename>:</emphasis>
+                    This recipe was removed in favor of the Python 3
+                    version.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis><filename>python-pexpect</filename>:</emphasis>
+                    This recipe was removed in favor of the Python 3 version.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis><filename>python-ptyprocess</filename>:</emphasis>
+                    This recipe was removed in favor of Python the 3 version.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis><filename>python-pycurl</filename>:</emphasis>
+                    Nothing is using this recipe in OpenEmbedded-Core
+                    (i.e. <filename>meta-oe</filename>).
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis><filename>python-six</filename>:</emphasis>
+                    This recipe was removed in favor of the Python 3 version.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis><filename>python-smmap</filename>:</emphasis>
+                    This recipe was removed in favor of the Python 3 version.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis><filename>remake</filename>:</emphasis>
+                    Using <filename>remake</filename> as the provider of
+                    <filename>virtual/make</filename> is broken.
+                    Consequently, this recipe is not needed in OpenEmbedded-Core.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-2.4-kernel-device-tree-move'>
+        <title>Kernel Device Tree Move</title>
+
+        <para>
+            Kernel Device Tree support is easy to enable in a kernel
+            recipe.
+            The Device Tree code has moved to a
+            <filename>kernel-devicetree</filename> class.
+            Functionality is automatically enabled for any recipe that inherits
+            the
+            <link linkend='ref-classes-kernel'><filename>kernel</filename></link>
+            class and sets the
+            <link linkend='var-KERNEL_DEVICETREE'><filename>KERNEL_DEVICETREE</filename></link>
+            variable.
+            The previous mechanism for doing this,
+            <filename>meta/recipes-kernel/linux/linux-dtb.inc</filename>,
+            is still available to avoid breakage, but triggers a
+            deprecation warning.
+            Future releases of the Yocto Project will remove
+            <filename>meta/recipes-kernel/linux/linux-dtb.inc</filename>.
+            It is advisable to remove any <filename>require</filename>
+            statements that request
+            <filename>meta/recipes-kernel/linux/linux-dtb.inc</filename>
+            from any custom kernel recipes you might have.
+            This will avoid breakage in post 2.4 releases.
+        </para>
+    </section>
+
+    <section id='migration-2.4-package-qa-changes'>
+        <title>Package QA Changes</title>
+
+        <para>
+            The following package QA changes took place:
+            <itemizedlist>
+                <listitem><para>
+                    The "unsafe-references-in-scripts" QA check has been
+                    removed.
+                    Previously, this check ensured
+                    that the backslash character (i.e.
+                    <filename>/</filename>) and <filename>/usr</filename>
+                    could be on different filesystems and that
+                    <filename>/usr</filename> is no longer actively supported.
+                    </para></listitem>
+                <listitem><para>
+                    If you refer to <filename>${COREBASE}/LICENSE</filename>
+                    within
+                    <link linkend='var-LIC_FILES_CHKSUM'><filename>LIC_FILES_CHKSUM</filename></link>
+                    you receive a warning because this file is a description of
+                    the license for OE-Core.
+                    Use <filename>${COMMON_LICENSE_DIR}/MIT</filename>
+                    if your recipe is MIT-licensed and you cannot use the
+                    preferred method of referring to a file within the source
+                    tree.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-2.4-readme-changes'>
+        <title><filename>README</filename> File Changes</title>
+
+        <para>
+            The following are changes to <filename>README</filename> files:
+            <itemizedlist>
+                <listitem><para>
+                    The main Poky <filename>README</filename> file has been
+                    moved to the <filename>meta-poky</filename> layer and
+                    has been renamed <filename>README.poky</filename>.
+                    A symlink has been created so that references to the old
+                    location work.
+                    </para></listitem>
+                <listitem><para>
+                    The <filename>README.hardware</filename> file has been moved
+                    to <filename>meta-yocto-bsp</filename>.
+                    A symlink has been created so that references to the old
+                    location work.
+                    </para></listitem>
+                <listitem><para>
+                    A <filename>README.qemu</filename> file has been created
+                    with coverage of the <filename>qemu*</filename> machines.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='migration-2.4-miscellaneous-changes'>
+        <title>Miscellaneous Changes</title>
+
+        <para>
+            The following are additional changes:
+            <itemizedlist>
+                <listitem><para>
+                    The <filename>ROOTFS_PKGMANAGE_BOOTSTRAP</filename>
+                    variable and any references to it have been removed.
+                    You should remove this variable from any custom recipes.
+                    </para></listitem>
+                <listitem><para>
+                    The <filename>meta-yocto</filename> directory has been
+                    removed.
+                    <note>
+                        In the Yocto Project 2.1 release
+                        <filename>meta-yocto</filename> was renamed to
+                        <filename>meta-poky</filename> and the
+                        <filename>meta-yocto</filename> subdirectory remained
+                        to avoid breaking existing configurations.
+                    </note>
+                    </para></listitem>
+                <listitem><para>
+                    The <filename>maintainers.inc</filename> file, which tracks
+                    maintainers by listing a primary person responsible for each
+                    recipe in OE-Core, has been moved from
+                    <filename>meta-poky</filename> to OE-Core (i.e. from
+                    <filename>meta-poky/conf/distro/include</filename> to
+                    <filename>meta/conf/distro/include</filename>).
+                    </para></listitem>
+                <listitem><para>
+                    The
+                    <link linkend='ref-classes-buildhistory'><filename>buildhistory</filename></link>
+                    class now makes a single commit per build rather than one
+                    commit per subdirectory in the repository.
+                    This behavior assumes the commits are enabled with
+                    <link linkend='var-BUILDHISTORY_COMMIT'><filename>BUILDHISTORY_COMMIT</filename></link>
+                    = "1", which is typical.
+                    Previously, the <filename>buildhistory</filename> class made
+                    one commit per subdirectory in the repository in order to
+                    make it easier to see the changes for a particular
+                    subdirectory.
+                    Now Git can filter these changes itself when viewed.
+                    To view a particular change, specify that subdirectory as
+                    the last parameter on the <filename>git show</filename>
+                    or <filename>git diff</filename> commands.
+                    </para></listitem>
+                <listitem><para>
+                    The <filename>x86-base.inc</filename> file, which is
+                    included by all x86-based machine configurations, now sets
+                    <link linkend='var-IMAGE_FSTYPES'><filename>IMAGE_FSTYPES</filename></link>
+                    using <filename>?=</filename> to "live" rather than
+                    appending with <filename>+=</filename>.
+                    This change makes the default easier to override.
+                    </para></listitem>
+                <listitem><para>
+                    BitBake fires multiple "BuildStarted" events when
+                    <filename>multiconfig</filename> is enabled.
+                    This is limited to one per configuration.
+                    For more information, see the
+                    "<ulink url='&YOCTO_DOCS_BB_URL;#events'>Events</ulink>"
+                    in the BitBake User Manual.
+                    </para></listitem>
+                <listitem><para>
+                    By default, the <filename>security_flags.inc</filename> file
+                    sets a <filename>GCCPIE</filename> variable with an option
+                    to enable Position Independent Executables (PIE) within
+                    <filename>gcc</filename>.
+                    Enabling PIE in the GNU C Compiler (GCC), makes Return
+                    Oriented Programming (ROP) attacks much more difficult to
+                    execute.
+                    </para></listitem>
+                <listitem><para>
+                    OE-Core now provides a
+                    <filename>bitbake-layers</filename> plugin that implements
+                    a "create-layer" subcommand.
+                    The implementation of this subcommand has resulted in the
+                    <filename>yocto-layer</filename> script being deprecated and
+                    will likely be removed in the next Yocto Project release.
+                    </para></listitem>
+                <listitem><para>
+                      The <filename>vmdk</filename>, <filename>vdi</filename>,
+                      and <filename>qcow2</filename> image file types are now
+                      used in conjunction with the "wic" image type through
+                      <filename>CONVERSION_CMD</filename>.
+                      Consequently, the equivalent image types are now
+                      <filename>wic.vmdk</filename>, <filename>wic.vdi</filename>,
+                      and <filename>wic.qcow2</filename>, respectively.
+                    </para></listitem>
+                <listitem><para>
+                    <filename>do_image_&lt;type&gt;[depends]</filename> has
+                    replaced <filename>IMAGE_DEPENDS_&lt;type&gt;</filename>.
+                    If you have your own classes that implement custom image
+                    types, then you need to update them.
+                    </para></listitem>
+                <listitem><para>
+                    OpenSSL 1.1 has been introduced.
+                    However, the default is still 1.0.x through the
+                    <link linkend='var-PREFERRED_VERSION'><filename>PREFERRED_VERSION</filename></link>
+                    variable.
+                    This change is due to the remaining compatibility issues
+                    with other software.
+                    The
+                    <link linkend='var-PROVIDES'><filename>PROVIDES</filename></link>
+                    variable includes "openssl10" as a marker for recipes that
+                    still depend on OpenSSL 1.0.
+                    </para></listitem>
+                <listitem><para>
+                    To ensure consistent behavior, BitBake's "-r" and "-R"
+                    options (i.e. prefile and postfile), which are used to
+                    <filename>read</filename> or <filename>post-read</filename>
+                    additional configuration files from the command line, now
+                    only affect the current BitBake command.
+                    Before this change these options would "stick" for
+                    future executions.
+                    <note>
+                        BitBake server changes necessitated this change.
+                    </note>
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+</section>
 </chapter>
 <!--
 vim: expandtab tw=80 ts=4

documentation/ref-manual/ref-bitbake.xml

@@ -8,7 +8,7 @@
 
     <para>
         BitBake is a program written in Python that interprets the
-        <ulink url='&YOCTO_DOCS_REF_URL;#metadata'>Metadata</ulink> used by
+        <link linkend='metadata'>Metadata</link> used by
         the OpenEmbedded build system.
         At some point, developers wonder what actually happens when you enter:
         <literallayout class='monospaced'>
@@ -24,7 +24,7 @@
         BitBake strives to be a generic "task" executor that is capable of handling complex dependency relationships.
         As such, it has no real knowledge of what the tasks being executed actually do.
         BitBake just considers a list of tasks with dependencies and handles
-        <ulink url='&YOCTO_DOCS_REF_URL;#metadata'>Metadata</ulink>
+        <link linkend='metadata'>Metadata</link>
         consisting of variables in a certain format that get passed to the tasks.
     </note>
 
@@ -36,9 +36,10 @@
         </para>
 
         <para>
-            The first thing BitBake does is look for the <filename>bitbake.conf</filename> file.
+            The first thing BitBake does is look for the
+            <filename>bitbake.conf</filename> file.
             This file resides in the
-            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+            <link linkend='source-directory'>Source Directory</link>
             within the <filename>meta/conf/</filename> directory.
             BitBake finds it by examining its
             <link linkend='var-BBPATH'><filename>BBPATH</filename></link> environment
@@ -92,8 +93,8 @@
             <filename>meta/recipes-*/</filename> directory within Poky.
             Adding extra content to <filename>BBFILES</filename> is best achieved through the use of
             BitBake layers as described in the
-            "<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and
-            Creating Layers</ulink>" section of the Yocto Project Development Manual.
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and Creating Layers</ulink>"
+            section of the Yocto Project Development Tasks Manual.
         </para>
 
         <para>
@@ -227,13 +228,14 @@
 
         <para>
             Dependencies are defined through several variables.
-            You can find information about variables BitBake uses in the BitBake documentation,
-            which is found in the <filename>bitbake/doc/manual</filename> directory within the
-            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+            You can find information about variables BitBake uses in the
+            BitBake documentation, which is found in the
+            <filename>bitbake/doc/manual</filename> directory within the
+            <link linkend='source-directory'>Source Directory</link>.
             At a basic level, it is sufficient to know that BitBake uses the
             <filename><link linkend='var-DEPENDS'>DEPENDS</link></filename> and
-            <filename><link linkend='var-RDEPENDS'>RDEPENDS</link></filename> variables when
-            calculating dependencies.
+            <filename><link linkend='var-RDEPENDS'>RDEPENDS</link></filename>
+            variables when calculating dependencies.
         </para>
     </section>
 
@@ -448,20 +450,23 @@ Options:
             You can find information about the options and formats of entries for specific
             fetchers in the BitBake manual located in the
             <filename>bitbake/doc/manual</filename> directory of the
-            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+            <link linkend='source-directory'>Source Directory</link>.
         </para>
 
         <para>
-            One useful feature for certain Source Code Manager (SCM) fetchers is the ability to
-            "auto-update" when the upstream SCM changes version.
-            Since this ability requires certain functionality from the SCM, not all
-            systems support it.
-            Currently Subversion, Bazaar and to a limited extent, Git support the ability to "auto-update".
+            One useful feature for certain Source Code Manager (SCM) fetchers
+            is the ability to "auto-update" when the upstream SCM changes
+            version.
+            Since this ability requires certain functionality from the SCM,
+            not all systems support it.
+            Currently Subversion, Bazaar and to a limited extent, Git support
+            the ability to "auto-update".
             This feature works using the <filename><link linkend='var-SRCREV'>SRCREV</link></filename>
             variable.
             See the
-            "<ulink url='&YOCTO_DOCS_DEV_URL;#platdev-appdev-srcrev'>Using an External SCM</ulink>" section
-            in the Yocto Project Development Manual for more information.
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#platdev-appdev-srcrev'>Using an External SCM</ulink>"
+            section in the Yocto Project Development Tasks Manual for more
+            information.
         </para>
 
     </section>

documentation/ref-manual/ref-classes.xml

@@ -16,12 +16,12 @@
 </para>
 
 <para>
-    Any <ulink url='&YOCTO_DOCS_REF_URL;#metadata'>Metadata</ulink> usually
+    Any <link linkend='metadata'>Metadata</link> usually
     found in a recipe can also be placed in a class file.
     Class files are identified by the extension <filename>.bbclass</filename>
     and are usually placed in a <filename>classes/</filename> directory beneath
     the <filename>meta*/</filename> directory found in the
-    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+    <link linkend='source-directory'>Source Directory</link>.
     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
@@ -36,7 +36,7 @@
     This chapter discusses only the most useful and important classes.
     Other classes do exist within the <filename>meta/classes</filename>
     directory in the
-    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+    <link linkend='source-directory'>Source Directory</link>.
     You can reference the <filename>.bbclass</filename> files directly
     for more information.
 </para>
@@ -94,7 +94,7 @@
     <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.
+        section in the Yocto Project Development Tasks Manual.
         You can also see the
         <link linkend='var-ARCHIVER_MODE'><filename>ARCHIVER_MODE</filename></link>
         variable for information about the variable flags (varflags)
@@ -122,7 +122,7 @@
         These classes can also work with software that emulates Autotools.
         For more information, see the
         "<ulink url='&YOCTO_DOCS_DEV_URL;#new-recipe-autotooled-package'>Autotooled Package</ulink>"
-        section in the Yocto Project Development Manual.
+        section in the Yocto Project Development Tasks Manual.
     </para>
 
     <para>
@@ -333,7 +333,7 @@
         For details on how the class works, see the
         <filename>meta/classes/bluetooth.bbclass</filename> file in the Yocto
         Project
-        <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+        <link linkend='source-directory'>Source Directory</link>.
     </para>
 </section>
 
@@ -641,7 +641,7 @@
         Distribution policy dictates whether to include this class.
         See the
         "<ulink url='&YOCTO_DOCS_DEV_URL;#platdev-appdev-devshell'>Using a Development Shell</ulink>" section
-        in the Yocto Project Development Manual for more information about
+        in the Yocto Project Development Tasks Manual for more information about
         using <filename>devshell</filename>.
     </para>
 </section>
@@ -816,11 +816,11 @@
         For more information on the
         <filename>externalsrc</filename> class, see the comments in
         <filename>meta/classes/externalsrc.bbclass</filename> in the
-        <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+        <link linkend='source-directory'>Source Directory</link>.
         For information on how to use the <filename>externalsrc</filename>
         class, see the
         "<ulink url='&YOCTO_DOCS_DEV_URL;#building-software-from-an-external-source'>Building Software from an External Source</ulink>"
-        section in the Yocto Project Development Manual.
+        section in the Yocto Project Development Tasks Manual.
     </para>
 </section>
 
@@ -1247,7 +1247,7 @@
         </itemizedlist>
         For information on customizing images, see the
         "<ulink url='&YOCTO_DOCS_DEV_URL;#usingpoky-extend-customimage'>Customizing Images</ulink>"
-        section in the Yocto Project Development Manual.
+        section in the Yocto Project Development Tasks Manual.
         For information on how images are created, see the
         "<link linkend='images-dev-environment'>Images</link>" section elsewhere
         in this manual.
@@ -1768,27 +1768,6 @@ This check was removed for YP 2.3 release
                 </note>
                 </para></listitem>
 -->
-            <listitem><para><emphasis><filename>unsafe-references-in-scripts:</filename></emphasis>
-                Reports when a script file installed in
-                <filename>${base_libdir}</filename>,
-                <filename>${base_bindir}</filename>, or
-                <filename>${base_sbindir}</filename>, depends on files
-                installed under <filename>${exec_prefix}</filename>.
-                This dependency is a concern if you want the system to remain
-                basically operable if <filename>/usr</filename> is mounted
-                separately and is not mounted.
-                <note>
-                    Defaults for binaries installed in
-                    <filename>${base_libdir}</filename>,
-                    <filename>${base_bindir}</filename>, and
-                    <filename>${base_sbindir}</filename> are
-                    <filename>/lib</filename>, <filename>/bin</filename>, and
-                    <filename>/sbin</filename>, respectively.
-                    The default for a binary installed
-                    under <filename>${exec_prefix}</filename> is
-                    <filename>/usr</filename>.
-                </note>
-                </para></listitem>
             <listitem><para><emphasis><filename>useless-rpaths:</filename></emphasis>
                 Checks for dynamic library load paths (rpaths) in the binaries that
                 by default on a standard system are searched by the linker (e.g.
@@ -1880,7 +1859,7 @@ This check was removed for YP 2.3 release
         you build the kernel image.
         For information on how to build an initramfs, see the
         "<ulink url='&YOCTO_DOCS_DEV_URL;#building-an-initramfs-image'>Building an Initial RAM Filesystem (initramfs) Image</ulink>"
-        section in the Yocto Project Development Manual.
+        section in the Yocto Project Development Tasks Manual.
     </para>
 
     <para>
@@ -2174,7 +2153,7 @@ This check was removed for YP 2.3 release
     <para>
         For more information on using the Multilib feature, see the
         "<ulink url='&YOCTO_DOCS_DEV_URL;#combining-multiple-versions-library-files-into-one-image'>Combining Multiple Versions of Library Files into One Image</ulink>"
-        section in the Yocto Project Development Manual.
+        section in the Yocto Project Development Tasks Manual.
     </para>
 </section>
 
@@ -2308,7 +2287,7 @@ This check was removed for YP 2.3 release
         The <filename>oelint</filename> class is an
         obsolete lint checking tool that exists in
         <filename>meta/classes</filename> in the
-        <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+        <link linkend='source-directory'>Source Directory</link>.
     </para>
 
     <para>
@@ -2387,7 +2366,7 @@ This check was removed for YP 2.3 release
         on the target (i.e. runtime installation of packages).
         For more information, see the
         "<ulink url='&YOCTO_DOCS_DEV_URL;#using-runtime-package-management'>Using Runtime Package Management</ulink>"
-         section in the Yocto Project Development Manual.
+         section in the Yocto Project Development Tasks Manual.
     </para>
 
     <para>
@@ -2399,7 +2378,7 @@ This check was removed for YP 2.3 release
         all dependencies previously built.
         The reason for this discrepancy is because the RPM package manager
         creates and processes more
-        <ulink url='&YOCTO_DOCS_REF_URL;#metadata'>Metadata</ulink> than the
+        <link linkend='metadata'>Metadata</link> than the
         IPK package manager.
         Consequently, you might consider setting
         <filename>PACKAGE_CLASSES</filename> to "package_ipk" if you are
@@ -2567,7 +2546,7 @@ This check was removed for YP 2.3 release
     <para>
         For information on how to use this class, see the
         "<ulink url='&YOCTO_DOCS_DEV_URL;#usingpoky-extend-customimage-customtasks'>Customizing Images Using Custom Package Groups</ulink>"
-        section in the Yocto Project Development Manual.
+        section in the Yocto Project Development Tasks Manual.
     </para>
 
     <para>
@@ -2656,7 +2635,8 @@ This check was removed for YP 2.3 release
         <link linkend='ref-tasks-populate_sdk'><filename>do_populate_sdk</filename></link>
         task, see the
         "<ulink url='&YOCTO_DOCS_SDK_URL;#sdk-building-an-sdk-installer'>Building an SDK Installer</ulink>"
-        section in the Yocto Project Software Development Kit (SDK) Developer's Guide.
+        section in the Yocto Project Application Development and the
+        Extensible Software Development Kit (eSDK) manual.
     </para>
 </section>
 
@@ -2736,8 +2716,8 @@ This check was removed for YP 2.3 release
         <link linkend='ref-tasks-populate_sdk'><filename>do_populate_sdk</filename></link>
         task, see the
         "<ulink url='&YOCTO_DOCS_SDK_URL;#sdk-building-an-sdk-installer'>Building an SDK Installer</ulink>"
-        section in the Yocto Project Software Development Kit (SDK) Developer's
-        Guide.
+        section in the Yocto Project Application Development and the
+        Extensible Software Development Kit (eSDK) manual.
     </para>
 </section>
 
@@ -2810,8 +2790,8 @@ This check was removed for YP 2.3 release
         <link linkend='var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></link>.
         See the
         "<ulink url='&YOCTO_DOCS_DEV_URL;#testing-packages-with-ptest'>Testing Packages With ptest</ulink>"
-        section in the Yocto Project Development Manual for more information
-        on ptest.
+        section in the Yocto Project Development Tasks Manual for more
+        information on ptest.
     </para>
 </section>
 
@@ -2827,7 +2807,7 @@ This check was removed for YP 2.3 release
     <para>
         For information on setting up and running ptests, see the
         "<ulink url='&YOCTO_DOCS_DEV_URL;#testing-packages-with-ptest'>Testing Packages With ptest</ulink>"
-        section in the Yocto Project Development Manual.
+        section in the Yocto Project Development Tasks Manual.
     </para>
 </section>
 
@@ -3435,7 +3415,7 @@ This check was removed for YP 2.3 release
     <para>
         For more information on <filename>systemd</filename>, see the
         "<ulink url='&YOCTO_DOCS_DEV_URL;#selecting-an-initialization-manager'>Selecting an Initialization Manager</ulink>"
-        section in the Yocto Project Development Manual.
+        section in the Yocto Project Development Tasks Manual.
     </para>
 </section>
 
@@ -3535,7 +3515,7 @@ This check was removed for YP 2.3 release
     <para>
         For information on how to enable, run, and create new tests, see the
         "<ulink url='&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing'>Performing Automated Runtime Testing</ulink>"
-        section in the Yocto Project Development Manual.
+        section in the Yocto Project Development Tasks Manual.
     </para>
 </section>
 
@@ -3717,7 +3697,8 @@ This check was removed for YP 2.3 release
         provide pathnames for links, default links for targets, and
         so forth.
         For details on how to use this class, see the comments in the
-        <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta/classes/update-alternatives.bbclass'><filename>update-alternatives.bbclass</filename></ulink>.
+        <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta/classes/update-alternatives.bbclass'><filename>update-alternatives.bbclass</filename></ulink>
+        file.
     </para>
 
     <note>
@@ -3757,8 +3738,9 @@ This check was removed for YP 2.3 release
         For example, if you have packages that contain system services that
         should be run under their own user or group, you can use these classes
         to enable creation of the user or group.
-        The <filename>meta-skeleton/recipes-skeleton/useradd/useradd-example.bb</filename>
-        recipe in the <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+        The
+        <filename>meta-skeleton/recipes-skeleton/useradd/useradd-example.bb</filename>
+        recipe in the <link linkend='source-directory'>Source Directory</link>
         provides a simple example that shows how to add three
         users and groups to two packages.
         See the <filename>useradd-example.bb</filename> recipe for more

documentation/ref-manual/ref-development-environment.xml

@@ -99,7 +99,7 @@
         <note>For information on finding out who is responsible for (maintains)
             a particular area of code, see the
             "<ulink url='&YOCTO_DOCS_DEV_URL;#how-to-submit-a-change'>Submitting a Change to the Yocto Project</ulink>"
-            section of the Yocto Project Development Manual.
+            section of the Yocto Project Development Tasks Manual.
         </note>
     </para>
 
@@ -146,7 +146,7 @@
         This process is called “submitting a patch” or "submitting a change."
         For information on submitting patches and changes, see the
         "<ulink url='&YOCTO_DOCS_DEV_URL;#how-to-submit-a-change'>Submitting a Change to the Yocto Project</ulink>"
-        section in the Yocto Project Development Manual.
+        section in the Yocto Project Development Tasks Manual.
     </para>
 
     <para>
@@ -239,7 +239,7 @@
                 <link linkend='source-directory'>Source Directory</link>.
                 For information on how to use these scripts, see the
                 "<ulink url='&YOCTO_DOCS_DEV_URL;#pushing-a-change-upstream'>Using Scripts to Push a Change Upstream and Request a Pull</ulink>"
-                section in the Yocto Project Development Manual.
+                section in the Yocto Project Development Tasks Manual.
                 </para></listitem>
             <listitem><para>
                 <emphasis>Patch Workflow:</emphasis>
@@ -252,7 +252,7 @@
                 <filename>git send-email</filename>.
                 For information on how to use these scripts, see the
                 "<ulink url='&YOCTO_DOCS_DEV_URL;#how-to-submit-a-change'>Submitting a Change to the Yocto Project</ulink>"
-                section in the Yocto Project Development Manual.
+                section in the Yocto Project Development Tasks Manual.
                 </para></listitem>
         </itemizedlist>
     </para>
@@ -288,7 +288,7 @@
                     For examples beyond the limited few in this section on how
                     to use Git with the Yocto Project, see the
                     "<ulink url='&YOCTO_DOCS_DEV_URL;#working-with-yocto-project-source-files'>Working With Yocto Project Source Files</ulink>"
-                    section in the Yocto Project Development Manual.
+                    section in the Yocto Project Development Tasks Manual.
                     </para></listitem>
             </itemizedlist>
         </note>
@@ -336,7 +336,7 @@
             develop locally.
             For examples on how to clone Git repositories, see the
             "<ulink url='&YOCTO_DOCS_DEV_URL;#working-with-yocto-project-source-files'>Working With Yocto Project Source Files</ulink>"
-            section in the Yocto Project Development Manual.
+            section in the Yocto Project Development Tasks Manual.
         </para>
 
         <para>
@@ -692,7 +692,7 @@
                 For steps on how to view and access these upstream Git
                 repositories, see the
                 "<ulink url='&YOCTO_DOCS_DEV_URL;#accessing-source-repositories'>Accessing Source Repositories</ulink>"
-                Section in the Yocto Project Development Manual.
+                Section in the Yocto Project Development Tasks Manual.
                 </para></listitem>
             <listitem><para><anchor id='index-downloads' />
                 <emphasis>
@@ -711,7 +711,7 @@
                 <imagedata fileref="figures/index-downloads.png" align="center" width="6in" depth="3.5in" />
                 For steps on how to view and access these files, see the
                 "<ulink url='&YOCTO_DOCS_DEV_URL;#accessing-index-of-releases'>Accessing Index of Releases</ulink>"
-                section in the Yocto Project Development Manual.
+                section in the Yocto Project Development Tasks Manual.
                 </para></listitem>
             <listitem><para id='downloads-page'>
                 <emphasis>"Downloads" page for the
@@ -731,7 +731,7 @@
                 <imagedata fileref="figures/yp-download.png" align="center" width="6in" depth="4in" />
                 For steps on how to use the "Downloads" page, see the
                 "<ulink url='&YOCTO_DOCS_DEV_URL;#using-the-downloads-page'>Using the Downloads Page</ulink>"
-                section in the Yocto Project Development Manual.
+                section in the Yocto Project Development Tasks Manual.
                 </para></listitem>
         </itemizedlist>
     </para>
@@ -817,7 +817,7 @@
         open source licensing during the lifecycle of a product created using
         the Yocto Project, 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.
+        section in the Yocto Project Development Tasks Manual.
     </para>
 </section>
 
@@ -1127,7 +1127,7 @@
         The following diagram represents development at a high level.
         The remainder of this chapter expands on the fundamental input, output,
         process, and
-        <ulink url='&YOCTO_DOCS_REF_URL;#metadata'>Metadata</ulink>) blocks
+        <link linkend='metadata'>Metadata</link>) blocks
         that make up development in the Yocto Project environment.
     </para>
 
@@ -1195,7 +1195,7 @@
             a build.
             These files are <filename>*.conf</filename> files.
             The minimally necessary ones reside as example files in the
-            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+            <link linkend='source-directory'>Source Directory</link>.
             For simplicity, this section refers to the Source Directory as
             the "Poky Directory."
         </para>
@@ -1312,7 +1312,7 @@
             You can find more information on working with the
             <filename>bblayers.conf</filename> file in the
             "<ulink url='&YOCTO_DOCS_DEV_URL;#enabling-your-layer'>Enabling Your Layer</ulink>"
-            section in the Yocto Project Development Manual.
+            section in the Yocto Project Development Tasks Manual.
         </para>
 
         <para>
@@ -1465,7 +1465,7 @@
         <para>
             For more information on layers, see the
             "<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and Creating Layers</ulink>"
-            section in the Yocto Project Development Manual.
+            section in the Yocto Project Development Tasks Manual.
         </para>
 
         <section id="distro-layer">
@@ -2230,7 +2230,9 @@
 
             <para>
                 After the root filesystem is built, processing begins on
-                the image through the <filename>do_image</filename> task.
+                the image through the
+                <link linkend='ref-tasks-image'><filename>do_image</filename></link>
+                task.
                 The build system runs any pre-processing commands as defined
                 by the
                 <link linkend='var-IMAGE_PREPROCESS_COMMAND'><filename>IMAGE_PREPROCESS_COMMAND</filename></link>
@@ -2241,20 +2243,38 @@
             </para>
 
             <para>
-                The <filename>do_image</filename> task dynamically creates
-                other <filename>do_image_*</filename> tasks as needed, which
-                include compressing the root filesystem image to reduce the
-                overall size of the image.
-                The process turns everything into an image file or a set of
-                image files.
-                The formats used for the root filesystem depend on the
+                The OpenEmbedded build system dynamically creates
+                <filename>do_image_*</filename> tasks as needed, based
+                on the image types specified in the
                 <link linkend='var-IMAGE_FSTYPES'><filename>IMAGE_FSTYPES</filename></link>
                 variable.
+                The process turns everything into an image file or a set of
+                image files and compresses the root filesystem image to reduce
+                the overall size of the image.
+                The formats used for the root filesystem depend on the
+                <filename>IMAGE_FSTYPES</filename> variable.
+            </para>
+
+            <para>
+                As an example, a dynamically created task when creating a
+                particular image <replaceable>type</replaceable> would take the
+                following form:
+                <literallayout class='monospaced'>
+     do_image_<replaceable>type</replaceable>[depends]
+                </literallayout>
+                So, if the <replaceable>type</replaceable> as specified by the
+                <filename>IMAGE_FSTYPES</filename> were
+                <filename>ext4</filename>, the dynamically generated task
+                would be as follows:
+                <literallayout class='monospaced'>
+     do_image_ext4[depends]
+                </literallayout>
             </para>
 
             <para>
                 The final task involved in image creation is the
-                <filename>do_image_complete</filename> task.
+                <link linkend='ref-tasks-image-complete'><filename>do_image_complete</filename></link>
+                task.
                 This task completes the image by applying any image
                 post processing as defined through the
                 <link linkend='var-IMAGE_POSTPROCESS_COMMAND'><filename>IMAGE_POSTPROCESS_COMMAND</filename></link>
@@ -2291,8 +2311,8 @@
                 <link linkend='ref-tasks-populate_sdk'><filename>do_populate_sdk</filename></link>
                 task, see the
                 "<ulink url='&YOCTO_DOCS_SDK_URL;#sdk-building-an-sdk-installer'>Building an SDK Installer</ulink>"
-                section in the Yocto Project Software Development Kit (SDK)
-                Developer's Guide.
+                section in the Yocto Project Application Development and the
+                Extensible Software Development Kit (SDK) manual.
             </note>
 
             <para>
@@ -2649,7 +2669,8 @@
                 section.
                 For information on setting up a cross-development
                 environment, see the
-                <ulink url='&YOCTO_DOCS_SDK_URL;#sdk-manual'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>.
+                <ulink url='&YOCTO_DOCS_SDK_URL;#sdk-manual'>Yocto Project Application Development and the Extensible Software Development Kit (eSDK)</ulink>
+                manual.
             </para>
         </note>
 

documentation/ref-manual/ref-devtool-reference.xml

@@ -20,8 +20,8 @@
         For more information on how to apply the command when using the
         extensible SDK, see the
         "<ulink url='&YOCTO_DOCS_SDK_URL;#sdk-extensible'>Using the Extensible SDK</ulink>"
-        section in the Yocto Project Software Development Kit (SDK) Developer's
-        Guide.
+        section in the Yocto Project Application Development and the
+        Extensible Software Development Kit (eSDK) manual.
     </para>
 
     <section id='devtool-getting-help'>
@@ -324,7 +324,7 @@
             Use the <filename>devtool modify</filename> command to begin
             modifying the source of an existing recipe.
             This command is very similar to the
-            <ulink url='&YOCTO_DOCS_DEV_URL;#devtool-adding-a-new-recipe-to-the-workspace'><filename>add</filename></ulink>
+            <link linkend='devtool-adding-a-new-recipe-to-the-workspace'><filename>add</filename></link>
             command except that it does not physically create the
             recipe in the workspace layer because the recipe already
             exists in an another layer.
@@ -382,7 +382,7 @@
             to the source files.
             For example, if you know you are going to work on some
             code, you could first use the
-            <ulink url='&YOCTO_DOCS_DEV_URL;#devtool-modifying-a-recipe'><filename>devtool modify</filename></ulink>
+            <link linkend='devtool-modifying-a-recipe'><filename>devtool modify</filename></link>
             command to extract the code and set up the workspace.
             After which, you could modify, compile, and test the code.
         </para>
@@ -604,7 +604,7 @@
             remove deployed build output from the target machine.
             For the <filename>devtool undeploy-target</filename> command to
             work, you must have previously used the
-            <ulink url='&YOCTO_DOCS_DEV_URL;#devtool-deploying-your-software-on-the-target-machine'><filename>devtool deploy-target</filename></ulink>
+            <link linkend='devtool-deploying-your-software-on-the-target-machine'><filename>devtool deploy-target</filename></link>
             command.
             <literallayout class='monospaced'>
      $ devtool undeploy-target <replaceable>recipe</replaceable>&nbsp;<replaceable>target</replaceable>
@@ -664,7 +664,7 @@
      $ devtool status
             </literallayout>
             Following is sample output after using
-            <ulink url='&YOCTO_DOCS_DEV_URL;#devtool-adding-a-new-recipe-to-the-workspace'><filename>devtool add</filename></ulink>
+            <link linkend='devtool-adding-a-new-recipe-to-the-workspace'><filename>devtool add</filename></link>
             to create and add the <filename>mtr_0.86.bb</filename> recipe
             to the <filename>workspace</filename> directory:
             <literallayout class='monospaced'>

documentation/ref-manual/ref-features.xml

@@ -36,7 +36,7 @@
     <para>
         One method you can use to determine which recipes are checking to see if a
         particular feature is contained or not is to <filename>grep</filename> through
-        the <ulink url='&YOCTO_DOCS_REF_URL;#metadata'>Metadata</ulink>
+        the <link linkend='metadata'>Metadata</link>
         for the feature.
         Here is an example that discovers the recipes whose build is potentially
         changed based on a given feature:
@@ -132,7 +132,7 @@
             These select features make sense to be controlled both at
             the machine and distribution configuration level.
             See the
-            <ulink url='&YOCTO_DOCS_REF_URL;#var-COMBINED_FEATURES'><filename>COMBINED_FEATURES</filename></ulink>
+            <link linkend='var-COMBINED_FEATURES'><filename>COMBINED_FEATURES</filename></link>
             variable for more information.
         </para>
 
@@ -151,8 +151,8 @@
                     is used.
                     See the
                     "<ulink url='&YOCTO_DOCS_SDK_URL;#adding-api-documentation-to-the-standard-sdk'>Adding API Documentation to the Standard SDK</ulink>"
-                    section in the Yocto Project Software Development Kit (SDK)
-                    Developer's Guide for more information.
+                    section in the Yocto Project Application Development and
+                    the Extensible Software Development Kit (eSDK) manual.
                     </para></listitem>
                 <listitem><para><emphasis>bluetooth:</emphasis> Include
                     bluetooth support (integrated BT only).</para></listitem>
@@ -217,7 +217,7 @@
                     the package tests where supported by individual recipes.
                     For more information on package tests, see the
                     "<ulink url='&YOCTO_DOCS_DEV_URL;#testing-packages-with-ptest'>Testing Packages With ptest</ulink>"
-                    section in the Yocto Project Development Manual.
+                    section in the Yocto Project Development Tasks Manual.
                     </para></listitem>
                 <listitem><para><emphasis>smbfs:</emphasis> Include SMB networks
                     client support (for mounting Samba/Microsoft Windows shares
@@ -304,7 +304,7 @@
                     <note>
                         To make the <filename>/var/log</filename> directory
                         on the target persistent, use the
-                        <ulink url='&YOCTO_DOCS_REF_URL;#var-VOLATILE_LOG_DIR'><filename>VOLATILE_LOG_DIR</filename></ulink>
+                        <link linkend='var-VOLATILE_LOG_DIR'><filename>VOLATILE_LOG_DIR</filename></link>
                         variable by setting it to "no".
                     </note>
                     </para></listitem>
@@ -315,8 +315,8 @@
                     Creates an image whose root filesystem is read-only.
                     See the
                     "<ulink url='&YOCTO_DOCS_DEV_URL;#creating-a-read-only-root-filesystem'>Creating a Read-Only Root Filesystem</ulink>"
-                    section in the Yocto Project Development Manual for more
-                    information.
+                    section in the Yocto Project Development Tasks Manual for
+                    more information.
                     </para></listitem>
                 <listitem><para><emphasis>splash:</emphasis>
                     Enables showing a splash screen during boot.
@@ -356,7 +356,8 @@
                     <filename>perf</filename>, <filename>systemtap</filename>,
                     and <filename>LTTng</filename>.
                     For general information on user-space tools, see the
-                    <ulink url='&YOCTO_DOCS_SDK_URL;#sdk-manual'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>.
+                    <ulink url='&YOCTO_DOCS_SDK_URL;#sdk-manual'>Yocto Project Application Development and the Extensible Software Development Kit (eSDK)</ulink>
+                    manual.
                     </para></listitem>
                 <listitem><para><emphasis>ssh-server-dropbear:</emphasis>
                     Installs the Dropbear minimal SSH server.
@@ -374,7 +375,7 @@
                     <filename>strace</filename> and <filename>gdb</filename>.
                     For information on GDB, see the
                     "<ulink url='&YOCTO_DOCS_DEV_URL;#platdev-gdb-remotedebug'>Debugging With the GNU Project Debugger (GDB) Remotely</ulink>"
-                    section in the Yocto Project Development Manual.
+                    section in the Yocto Project Development Tasks Manual.
                     For information on tracing and profiling, see the
                     <ulink url='&YOCTO_DOCS_PROF_URL;'>Yocto Project Profiling and Tracing Manual</ulink>.
                     </para></listitem>

documentation/ref-manual/ref-images.xml

@@ -30,7 +30,7 @@
     <para>
         From within the <filename>poky</filename> Git repository, you can use
         the following command to display the list of directories within the
-        <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+        <link linkend='source-directory'>Source Directory</link>
         that contain image recipe files:
         <literallayout class='monospaced'>
      $ ls meta*/recipes*/images/*.bb
@@ -140,7 +140,7 @@
                 second image to be tested.
                 You can find more information about runtime testing in the
                 "<ulink url='&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing'>Performing Automated Runtime Testing</ulink>"
-                section in the Yocto Project Development Manual.
+                section in the Yocto Project Development Tasks Manual.
                 </para></listitem>
             <listitem><para><filename>core-image-testmaster-initramfs</filename>:
                 A RAM-based Initial Root Filesystem (initramfs) image tailored for

documentation/ref-manual/ref-manual.xml

@@ -22,11 +22,11 @@
 
         <authorgroup>
             <author>
-                <firstname>Richard</firstname> <surname>Purdie</surname>
+                <firstname>Scott</firstname> <surname>Rifenbark</surname>
                 <affiliation>
-                    <orgname>Linux Foundation</orgname>
+                    <orgname>Scotty's Documentation Services, INC</orgname>
                 </affiliation>
-                <email>richard.purdie@linuxfoundation.org</email>
+                <email>srifenbark@gmail.com</email>
             </author>
 
         </authorgroup>
@@ -132,29 +132,31 @@
            <note><title>Manual Notes</title>
                <itemizedlist>
                    <listitem><para>
-                       For the latest version of the Yocto Project Reference
-                       Manual associated with this Yocto Project release
-                       (version &YOCTO_DOC_VERSION;),
-                       see the Yocto Project Reference Manual from the
+                       This version of the
+                       <emphasis>Yocto Project Reference Manual</emphasis>
+                       is for the &YOCTO_DOC_VERSION; release of the
+                       Yocto Project.
+                       To be sure you have the latest version of the manual
+                       for this release, use the manual from the
                        <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink>.
                        </para></listitem>
                    <listitem><para>
-                       This version of the manual is version
-                       &YOCTO_DOC_VERSION;.
-                       For later releases of the Yocto Project (if they exist),
-                       go to the
+                       For manuals associated with other releases of the Yocto
+                       Project, go to the
                        <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink>
                        and use the drop-down "Active Releases" button
-                       and choose the Yocto Project version for which you want
-                       the manual.
+                       and choose the manual associated with the desired
+                       Yocto Project.
                        </para></listitem>
                    <listitem><para>
-                       For an in-development version of the Yocto Project
-                       Reference Manual, see
-                        <ulink url='&YOCTO_DOCS_URL;/latest/ref-manual/ref-manual.html'></ulink>.
+                        To report any inaccuracies or problems with this
+                        manual, send an email to the Yocto Project
+                        discussion group at
+                        <filename>yocto@yoctoproject.com</filename> or log into
+                        the freenode <filename>#yocto</filename> channel.
                         </para></listitem>
-                </itemizedlist>
-            </note>
+               </itemizedlist>
+           </note>
     </legalnotice>
 
     </bookinfo>

documentation/ref-manual/ref-release-process.xml

@@ -61,9 +61,9 @@
     <para>
         Each major release receives a codename that identifies the release in
         the
-        <ulink url='&YOCTO_DOCS_REF_URL;#yocto-project-repositories'>Yocto Project Source Repositories</ulink>.
+        <link linkend='yocto-project-repositories'>Yocto Project Source Repositories</link>.
         The concept is that branches of
-        <ulink url='&YOCTO_DOCS_REF_URL;#metadata'>Metadata</ulink>
+        <link linkend='metadata'>Metadata</link>
         with the same codename are likely to be compatible and thus
         work together.
         <note>
@@ -131,7 +131,7 @@
         Yocto Project.
         For information on how to run available tests on your projects, see the
         "<ulink url='&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing'>Performing Automated Runtime Testing</ulink>"
-        section in the Yocto Project Development Manual.
+        section in the Yocto Project Development Tasks Manual.
     </para>
 
     <para>
@@ -206,7 +206,8 @@
     <para>
         The Yocto Project's main Autobuilder
         (<filename>autobuilder.yoctoproject.org</filename>) publicly tests
-        each Yocto Project release's code in the OE-Core, Poky, and BitBake
+        each Yocto Project release's code in the
+        <link linkend='oe-core'>OE-Core</link>, Poky, and BitBake
         repositories.
         The testing occurs for both the current state of the
         "master" branch and also for submitted patches.
@@ -216,7 +217,7 @@
         in the <filename>poky</filename> repository.
         <note>
             You can find all these branches in the Yocto Project
-            <ulink url='&YOCTO_DOCS_REF_URL;#source-repositories'>Source Repositories</ulink>.
+            <link linkend='source-repositories'>Source Repositories</link>.
         </note>
         Testing within these public branches ensures in a publicly visible way
         that all of the main supposed architectures and recipes in OE-Core

documentation/ref-manual/ref-structure.xml

@@ -7,17 +7,19 @@
 <title>Source Directory Structure</title>
 
 <para>
-    The <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink> consists of several components.
-    Understanding them and knowing where they are located is key to using the Yocto Project well.
-    This chapter describes the Source Directory and gives information about the various
-    files and directories.
+    The <link linkend='source-directory'>Source Directory</link>
+    consists of several components.
+    Understanding them and knowing where they are located is key to using the
+    Yocto Project well.
+    This chapter describes the Source Directory and gives information about
+    the various files and directories.
 </para>
 
 <para>
     For information on how to establish a local Source Directory on your
     development system, see the
     "<ulink url='&YOCTO_DOCS_DEV_URL;#working-with-yocto-project-source-files'>Working With Yocto Project Source Files</ulink>"
-    section in the Yocto Project Development Manual.
+    section in the Yocto Project Development Tasks Manual.
 </para>
 
 <note>
@@ -32,7 +34,7 @@
 
     <para>
         This section describes the top-level components of the
-        <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+        <link linkend='source-directory'>Source Directory</link>.
     </para>
 
     <section id='structure-core-bitbake'>
@@ -43,7 +45,7 @@
             The copy usually matches the current stable BitBake release from
             the BitBake project.
             BitBake, a
-            <ulink url='&YOCTO_DOCS_REF_URL;#metadata'>Metadata</ulink>
+            <link linkend='metadata'>Metadata</link>
             interpreter, reads the Yocto Project Metadata and runs the tasks
             defined by that data.
             Failures are usually from the Metadata and not from BitBake itself.
@@ -85,7 +87,7 @@
         <para>
             It is also possible to place output and configuration
             files in a directory separate from the
-            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+            <link linkend='source-directory'>Source Directory</link>
             by providing a directory name when you <filename>source</filename>
             the setup script.
             For information on separating output from your local
@@ -221,13 +223,13 @@
             The script gets its default list of common targets from the
             <filename>conf-notes.txt</filename> file, which is found in the
             <filename>meta-poky</filename> directory within the
-            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+            <link linkend='source-directory'>Source Directory</link>.
             Should you have custom distributions, it is very easy to modify
             this configuration file to include your targets for your
             distribution.
             See the
             "<ulink url='&YOCTO_DOCS_DEV_URL;#creating-a-custom-template-configuration-directory'>Creating a Custom Template Configuration Directory</ulink>"
-            section in the Yocto Project Development Manual for more
+            section in the Yocto Project Development Tasks Manual for more
             information.
         </para>
 
@@ -241,17 +243,17 @@
             build system to create a Build Directory of your choice.
             For example, the following command creates a Build Directory named
             <filename>mybuilds</filename> that is outside of the
-            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>:
+            <link linkend='source-directory'>Source Directory</link>:
             <literallayout class='monospaced'>
      $ source &OE_INIT_FILE; ~/mybuilds
             </literallayout>
             The OpenEmbedded build system uses the template configuration
             files, which are found by default in the
             <filename>meta-poky/conf</filename> directory in the
-            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+            Source Directory.
             See the
             "<ulink url='&YOCTO_DOCS_DEV_URL;#creating-a-custom-template-configuration-directory'>Creating a Custom Template Configuration Directory</ulink>"
-            section in the Yocto Project Development Manual for more
+            section in the Yocto Project Development Tasks Manual for more
             information.
             <note>
                 The OpenEmbedded build system does not support file or directory names that
@@ -365,7 +367,7 @@
                 You can see how the <filename>TEMPLATECONF</filename> variable
                 is used by looking at the
                 <filename>scripts/oe-setup-builddir</filename> script in the
-                <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+                <link linkend='source-directory'>Source Directory</link>.
                 You can find the Yocto Project version of the
                 <filename>local.conf.sample</filename> file in the
                 <filename>meta-poky/conf</filename> directory.
@@ -415,7 +417,7 @@
             <note>
                 You can see how the <filename>TEMPLATECONF</filename> variable
                 <filename>scripts/oe-setup-builddir</filename> script in the
-                <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+                <link linkend='source-directory'>Source Directory</link>.
                 You can find the Yocto Project version of the
                 <filename>bblayers.conf.sample</filename> file in the
                 <filename>meta-poky/conf</filename> directory.
@@ -563,7 +565,7 @@
             contain appropriate <filename>COPYING</filename> license files with other licensing information.
             For information on licensing, see the
             "<ulink url='&YOCTO_DOCS_DEV_URL;#maintaining-open-source-license-compliance-during-your-products-lifecycle'>Maintaining Open Source License Compliance During Your Product's Lifecycle</ulink>"
-            section.
+            section in the Yocto Project Development Tasks Manual.
         </para>
     </section>
 
@@ -607,7 +609,8 @@
             sysroot that matches your target hardware.
             You can find out more about these installers in the
             "<ulink url='&YOCTO_DOCS_SDK_URL;#sdk-building-an-sdk-installer'>Building an SDK Installer</ulink>"
-            section in the Yocto Project Software Development Kit (SDK) Developer's Guide.
+            section in the Yocto Project Application Development and the
+            Extensible Software Development Kit (eSDK) manual.
         </para>
     </section>
 
@@ -738,7 +741,8 @@
             <filename>linux-qemux86-standard-build</filename> and then patched by Quilt.
             (See the
             "<ulink url='&YOCTO_DOCS_DEV_URL;#using-a-quilt-workflow'>Using Quilt in Your Workflow</ulink>"
-            section in the Yocto Project Development Manual for more information.)
+            section in the Yocto Project Development Tasks Manual for more
+            information.)
             Within the <filename>linux-qemux86-standard-build</filename> directory,
             standard Quilt directories <filename>linux-3.0/patches</filename>
             and <filename>linux-3.0/.pc</filename> are created,
@@ -872,7 +876,7 @@
 
     <para>
         As mentioned previously,
-        <ulink url='&YOCTO_DOCS_REF_URL;#metadata'>Metadata</ulink> is the core
+        <link linkend='metadata'>Metadata</link> is the core
         of the Yocto Project.
         Metadata has several important subdivisions:
     </para>

documentation/ref-manual/ref-tasks.xml

@@ -302,7 +302,7 @@
                             See the <filename>bin_package.bbclass</filename>
                             file in the <filename>meta/classes</filename>
                             directory of the
-                            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+                            <link linkend='source-directory'>Source Directory</link>
                             for an example.
                             </para></listitem>
                     </itemizedlist>
@@ -718,7 +718,7 @@
             the BitBake environment.
             See the
             "<ulink url='&YOCTO_DOCS_DEV_URL;#platdev-appdev-devpyshell'>Using a Development Python Shell</ulink>"
-            section in the Yocto Project Development Manual for more
+            section in the Yocto Project Development Tasks Manual for more
             information about using <filename>devpyshell</filename>.
         </para>
     </section>
@@ -731,7 +731,7 @@
             development, debugging, or both.
             See the
             "<ulink url='&YOCTO_DOCS_DEV_URL;#platdev-appdev-devshell'>Using a Development Shell</ulink>"
-            section in the Yocto Project Development Manual for more
+            section in the Yocto Project Development Tasks Manual for more
             information about using <filename>devshell</filename>.
         </para>
     </section>
@@ -821,7 +821,7 @@
             Boots an image and performs runtime tests within the image.
             For information on automatically testing images, see the
             "<ulink url='&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing'>Performing Automated Runtime Testing</ulink>"
-            section in the Yocto Project Development Manual.
+            section in the Yocto Project Development Tasks Manual.
         </para>
     </section>
 
@@ -839,7 +839,7 @@
         <para>
             For information on automatically testing images, see the
             "<ulink url='&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing'>Performing Automated Runtime Testing</ulink>"
-            section in the Yocto Project Development Manual.
+            section in the Yocto Project Development Tasks Manual.
         </para>
     </section>
 </section>

documentation/ref-manual/ref-variables.xml

@@ -321,7 +321,7 @@
                     For information on how the variable works, see the
                     <filename>meta/classes/archiver.bbclass</filename> file
                     in the
-                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+                    <link linkend='source-directory'>Source Directory</link>.
                 </para>
             </glossdef>
         </glossentry>
@@ -488,7 +488,7 @@
                 <para>
                     For more information see the
                     "<ulink url='&YOCTO_DOCS_DEV_URL;#automatically-incrementing-a-binary-package-revision-number'>Automatically Incrementing a Binary Package Revision Number</ulink>"
-                    section in the Yocto Project Development Manual.
+                    section in the Yocto Project Development Tasks Manual.
                     </para>
             </glossdef>
         </glossentry>
@@ -626,14 +626,14 @@
                     Multilib context.
                     See the
                     "<ulink url='&YOCTO_DOCS_DEV_URL;#combining-multiple-versions-library-files-into-one-image'>Combining Multiple Versions of Library Files into One Image</ulink>"
-                    section in the Yocto Project Development Manual for
+                    section in the Yocto Project Development Tasks Manual for
                     information on Multilib.
                 </para>
 
                 <para>
                     The <filename>BASE_LIB</filename> variable is defined in
                     the machine include files in the
-                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+                    <link linkend='source-directory'>Source Directory</link>.
                     If Multilib is not being used, the value defaults to "lib".
                 </para>
             </glossdef>
@@ -1263,7 +1263,7 @@
                     supports building targets with multiple configurations,
                     see the
                     "<ulink url='&YOCTO_DOCS_DEV_URL;#platdev-building-targets-with-multiple-configurations'>Building Targets with Multiple Configurations</ulink>"
-                    section in the Yocto Project Development Manual.
+                    section in the Yocto Project Development Tasks Manual.
                 </para>
             </glossdef>
         </glossentry>
@@ -1374,7 +1374,7 @@
                 <para>
                     For more information on how this variable works, see
                     <filename>meta/classes/binconfig.bbclass</filename> in the
-                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+                    <link linkend='source-directory'>Source Directory</link>.
                     You can also find general information on the class in the
                     "<link linkend='ref-classes-binconfig'><filename>binconfig.bbclass</filename></link>"
                     section.
@@ -2073,7 +2073,7 @@
 <!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
                     Specifies the directory BitBake uses to store a cache
                     of the
-                    <ulink url='&YOCTO_DOCS_REF_URL;#metadata'>Metadata</ulink>
+                    <link linkend='metadata'>Metadata</link>
                     so it does not need to be parsed every time BitBake is
                     started.
                 </para>
@@ -2231,7 +2231,7 @@
 <!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
                     Points to <filename>meta/files/common-licenses</filename>
                     in the
-                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>,
+                    <link linkend='source-directory'>Source Directory</link>,
                     which is where generic license files reside.
                 </para>
             </glossdef>
@@ -2398,7 +2398,7 @@
                     than <filename>/usr/bin</filename>.
                     You can find a list of these variables at the top of the
                     <filename>meta/conf/bitbake.conf</filename> file in the
-                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+                    <link linkend='source-directory'>Source Directory</link>.
                 </note>
             </glossdef>
         </glossentry>
@@ -2441,7 +2441,7 @@
                 <para>
                     For information on creating an initramfs, see the
                     "<ulink url='&YOCTO_DOCS_DEV_URL;#building-an-initramfs-image'>Building an Initial RAM Filesystem (initramfs) Image</ulink>"
-                    section in the Yocto Project Development Manual.
+                    section in the Yocto Project Development Tasks Manual.
                 </para>
             </glossdef>
         </glossentry>
@@ -2675,8 +2675,8 @@
                         variable for additional information.
                         You can also reference the
                         "<ulink url='&YOCTO_DOCS_DEV_URL;#providing-license-text'>Providing License Text</ulink>"
-                        section in the Yocto Project Development Manual for
-                        information on providing license text.
+                        section in the Yocto Project Development Tasks Manual
+                        for information on providing license text.
                     </note>
                 </para>
             </glossdef>
@@ -2703,8 +2703,8 @@
                         variable for additional information.
                         You can also reference the
                         "<ulink url='&YOCTO_DOCS_DEV_URL;#providing-license-text'>Providing License Text</ulink>"
-                        section in the Yocto Project Development Manual for
-                        information on providing license text.
+                        section in the Yocto Project Development Tasks Manual
+                        for information on providing license text.
                     </note>
                 </para>
             </glossdef>
@@ -3566,7 +3566,7 @@
                     and resides in the
                     <filename>meta-poky/conf/distro</filename> directory of
                     the
-                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+                    <link linkend='source-directory'>Source Directory</link>.
                 </para>
 
                 <para>
@@ -3580,7 +3580,7 @@
                 <para>
                     Distribution configuration files are located in a
                     <filename>conf/distro</filename> directory within the
-                    <ulink url='&YOCTO_DOCS_REF_URL;#metadata'>Metadata</ulink>
+                    <link linkend='metadata'>Metadata</link>
                     that contains the distribution configuration.
                     The value for <filename>DISTRO</filename> must not contain
                     spaces, and is typically all lower-case.
@@ -3989,14 +3989,14 @@
 
         <glossentry id='var-EFI_PROVIDER'><glossterm>EFI_PROVIDER</glossterm>
             <info>
-                EFI_PROVIDER[doc] = "When building bootable images (i.e. where hddimg, iso, or live is in IMAGE_FSTYPES), the EFI_PROVIDER variable specifies the EFI bootloader to use."
+                EFI_PROVIDER[doc] = "When building bootable images (i.e. where hddimg, iso, or wic.vmdk is in IMAGE_FSTYPES), the EFI_PROVIDER variable specifies the EFI bootloader to use."
             </info>
             <glossdef>
                 <para role="glossdeffirst">
 <!--                <para role="glossdeffirst"><imagedata fileref="figures/define-generic.png" /> -->
                     When building bootable images (i.e. where
                     <filename>hddimg</filename>, <filename>iso</filename>,
-                    or <filename>vmdk</filename> is in
+                    or <filename>wic.vmdk</filename> is in
                     <link linkend='var-IMAGE_FSTYPES'><filename>IMAGE_FSTYPES</filename></link>),
                     the <filename>EFI_PROVIDER</filename> variable specifies
                     the EFI bootloader to use.
@@ -4244,7 +4244,7 @@
                     You can also find information on how to use this variable
                     in the
                     "<ulink url='&YOCTO_DOCS_DEV_URL;#building-software-from-an-external-source'>Building Software from an External Source</ulink>"
-                    section in the Yocto Project Development Manual.
+                    section in the Yocto Project Development Tasks Manual.
                 </para>
             </glossdef>
         </glossentry>
@@ -4275,7 +4275,7 @@
                     You can also find information on how to use this variable
                     in the
                     "<ulink url='&YOCTO_DOCS_DEV_URL;#building-software-from-an-external-source'>Building Software from an External Source</ulink>"
-                    section in the Yocto Project Development Manual.
+                    section in the Yocto Project Development Tasks Manual.
                 </para>
             </glossdef>
         </glossentry>
@@ -4352,8 +4352,8 @@
                      filesystem is read-only. See the
                      "<ulink url='&YOCTO_DOCS_DEV_URL;#creating-a-read-only-root-filesystem'>Creating a Read-Only Root Filesystem</ulink>"
                      section in the Yocto Project
-                     Development Manual for more
-                     information
+                     Development Tasks Manual for
+                     more information
 
 "tools-debug" - Adds debugging tools such as gdb and
                 strace.
@@ -4379,7 +4379,7 @@
                     For an example that shows how to customize your image by
                     using this variable, see the
                     "<ulink url='&YOCTO_DOCS_DEV_URL;#usingpoky-extend-customimage-imagefeatures'>Customizing Images Using Custom <filename>IMAGE_FEATURES</filename> and <filename>EXTRA_IMAGE_FEATURES</filename></ulink>"
-                    section in the Yocto Project Development Manual.
+                    section in the Yocto Project Development Tasks Manual.
                 </para>
             </glossdef>
         </glossentry>
@@ -4668,7 +4668,7 @@
                     <filename>/usr/bin</filename>.
                     You can find a list of these variables at the top of the
                     <filename>meta/conf/bitbake.conf</filename> file in the
-                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+                    <link linkend='source-directory'>Source Directory</link>.
                     You will also find the default values of the various
                     <filename>FILES_*</filename> variables in this file.
                 </note>
@@ -4860,7 +4860,7 @@
                     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>:
+                    <link linkend='source-directory'>Source Directory</link>:
                     <literallayout class='monospaced'>
      FILESPATH = "${@base_set_filespath(["${FILE_DIRNAME}/${BP}", \
         "${FILE_DIRNAME}/${BPN}", "${FILE_DIRNAME}/files"], d)}"
@@ -4906,7 +4906,7 @@
                 <para>
                     By default, the OpenEmbedded build system uses the <filename>fs-perms.txt</filename>, which
                     is located in the <filename>meta/files</filename> folder in the
-                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+                    <link linkend='source-directory'>Source Directory</link>.
                     If you create your own file permissions setting table, you should place it in your
                     layer or the distro's layer.
                 </para>
@@ -5692,7 +5692,7 @@
                 <para>
                     For more information, see
                     <filename>meta/classes/image_types.bbclass</filename> in the
-                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+                    <link linkend='source-directory'>Source Directory</link>.
                 </para>
             </glossdef>
         </glossentry>
@@ -5786,7 +5786,7 @@
                     For an example that shows how to customize your image by
                     using this variable, see the
                     "<ulink url='&YOCTO_DOCS_DEV_URL;#usingpoky-extend-customimage-imagefeatures'>Customizing Images Using Custom <filename>IMAGE_FEATURES</filename> and <filename>EXTRA_IMAGE_FEATURES</filename></ulink>"
-                    section in the Yocto Project Development Manual.
+                    section in the Yocto Project Development Tasks Manual.
                 </para>
             </glossdef>
         </glossentry>
@@ -5815,20 +5815,25 @@
                     <link linkend='var-IMAGE_TYPES'><filename>IMAGE_TYPES</filename></link>.
                 </para>
 
-                <note>
-                    If you add "live" to <filename>IMAGE_FSTYPES</filename>
-                    inside an image recipe, be sure that you do so prior to the
-                    "inherit image" line of the recipe or the live image will
-                    not build.
-                </note>
-
-                <note>
-                    Due to the way this variable is processed, it is not
-                    possible to update its contents using
-                    <filename>_append</filename> or
-                    <filename>_prepend</filename>. To add one or more
-                    additional options to this variable the
-                    <filename>+=</filename> operator must be used.
+                <note><title>Notes</title>
+                    <itemizedlist>
+                        <listitem><para>
+                            If you add "live" to
+                            <filename>IMAGE_FSTYPES</filename> inside an image
+                            recipe, be sure that you do so prior to the
+                            "inherit image" line of the recipe or the live
+                            image will not build.
+                            </para></listitem>
+                        <listitem><para>
+                            Due to the way the OpenEmbedded build system
+                            processes this variable, you cannot update its
+                            contents by using <filename>_append</filename> or
+                            <filename>_prepend</filename>.
+                            You must use the <filename>+=</filename>
+                            operator to add one or more options to the
+                            <filename>IMAGE_FSTYPES</filename> variable.
+                            </para></listitem>
+                    </itemizedlist>
                 </note>
             </glossdef>
         </glossentry>
@@ -5856,7 +5861,7 @@
                         not be affected by <filename>IMAGE_INSTALL</filename>.
                         For information on creating an initramfs, see the
                         "<ulink url='&YOCTO_DOCS_DEV_URL;#building-an-initramfs-image'>Building an Initial RAM Filesystem (initramfs) Image</ulink>"
-                        section in the Yocto Project Development Manual.
+                        section in the Yocto Project Development Tasks Manual.
                     </note>
                 </para>
 
@@ -6362,7 +6367,7 @@
                     For more information about these types of images, see
                     <filename>meta/classes/image_types*.bbclass</filename>
                     in the
-                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+                    <link linkend='source-directory'>Source Directory</link>.
                 </para>
             </glossdef>
         </glossentry>
@@ -6605,7 +6610,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     The default value of this variable, which is set in the
                     <filename>meta/conf/bitbake.conf</filename> configuration
                     file in the
-                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>,
+                    <link linkend='source-directory'>Source Directory</link>,
                     is "cpio.gz".
                     The Linux kernel's initramfs mechanism, as opposed to the
                     initial RAM filesystem
@@ -6645,7 +6650,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     <note>
                         See the <filename>meta/recipes-core/images/core-image-minimal-initramfs.bb</filename>
                         recipe in the
-                        <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+                        <link linkend='source-directory'>Source Directory</link>
                         for an example initramfs recipe.
                         To select this sample recipe as the one built
                         to provide the initramfs image,
@@ -6658,7 +6663,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     You can also find more information by referencing the
                     <filename>meta-poky/conf/local.conf.sample.extended</filename>
                     configuration file in the
-                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>,
+                    <link linkend='source-directory'>Source Directory</link>,
                     the
                     <link linkend='ref-classes-image'><filename>image</filename></link>
                     class, and the
@@ -6680,7 +6685,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     Additionally, for information on creating an initramfs
                     image, see the
                     "<ulink url='&YOCTO_DOCS_DEV_URL;#building-an-initramfs-image'>Building an Initial RAM Filesystem (initramfs) Image</ulink>"
-                    section in the Yocto Project Development Manual.
+                    section in the Yocto Project Development Tasks Manual.
                 </para>
             </glossdef>
         </glossentry>
@@ -6747,7 +6752,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     file for additional information.
                     Also, for information on creating an initramfs, see the
                     "<ulink url='&YOCTO_DOCS_DEV_URL;#building-an-initramfs-image'>Building an Initial RAM Filesystem (initramfs) Image</ulink>"
-                    section in the Yocto Project Development Manual.
+                    section in the Yocto Project Development Tasks Manual.
                 </para>
             </glossdef>
         </glossentry>
@@ -7200,7 +7205,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     Includes additional kernel metadata.
                     In the OpenEmbedded build system, the default Board Support
                     Packages (BSPs)
-                    <ulink url='&YOCTO_DOCS_REF_URL;#metadata'>Metadata</ulink>
+                    <link linkend='metadata'>Metadata</link>
                     is provided through
                     the <link linkend='var-KMACHINE'><filename>KMACHINE</filename></link>
                     and
@@ -7912,7 +7917,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     <link linkend='var-COPY_LIC_MANIFEST'><filename>COPY_LIC_MANIFEST</filename></link>
                     variable, and the
                     "<ulink url='&YOCTO_DOCS_DEV_URL;#providing-license-text'>Providing License Text</ulink>"
-                    section in the Yocto Project Development Manual.
+                    section in the Yocto Project Development Tasks Manual.
                 </para>
             </glossdef>
         </glossentry>
@@ -8011,7 +8016,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     defines the search
                     arguments used by the kernel tools to find the appropriate
                     description within the kernel
-                    <ulink url='&YOCTO_DOCS_REF_URL;#metadata'>Metadata</ulink>
+                    <link linkend='metadata'>Metadata</link>
                     with which to build out the sources and configuration.
                     </para>
             </glossdef>
@@ -8130,7 +8135,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     Thus, when <filename>MACHINE</filename> is set to "qemux86" there
                     exists the corresponding <filename>qemux86.conf</filename> machine
                     configuration file, which can be found in the
-                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+                    <link linkend='source-directory'>Source Directory</link>
                     in <filename>meta/conf/machine</filename>.
                 </para>
 
@@ -8994,7 +8999,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                 <para>
                     See the <filename>meta/classes/binconfig.bbclass</filename>
                     in the
-                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+                    <link linkend='source-directory'>Source Directory</link>
                     for details on how this class applies these additional
                     sed command arguments.
                     For general information on the
@@ -9059,7 +9064,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     <filename>-c devshell</filename> command-line option).
                     For more information, see the
                     "<ulink url='&YOCTO_DOCS_DEV_URL;#platdev-appdev-devshell'>Using a Development Shell</ulink>" section
-                    in the Yocto Project Development Manual.
+                    in the Yocto Project Development Tasks Manual.
                  </para>
 
                  <para>
@@ -9373,7 +9378,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     You can find out more about debugging using GDB by reading
                     the
                     "<ulink url='&YOCTO_DOCS_DEV_URL;#platdev-gdb-remotedebug'>Debugging With the GNU Project Debugger (GDB) Remotely</ulink>"
-                    section in the Yocto Project Development Manual.
+                    section in the Yocto Project Development Tasks Manual.
                 </para>
             </glossdef>
         </glossentry>
@@ -9660,7 +9665,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     variable.
                     For information on creating an initramfs, see the
                     "<ulink url='&YOCTO_DOCS_DEV_URL;#building-an-initramfs-image'>Building an Initial RAM Filesystem (initramfs) Image</ulink>"
-                    section in the Yocto Project Development Manual.
+                    section in the Yocto Project Development Tasks Manual.
                 </para>
             </glossdef>
         </glossentry>
@@ -9716,7 +9721,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     For information on running post-installation scripts, see
                     the
                     "<ulink url='&YOCTO_DOCS_DEV_URL;#new-recipe-post-installation-scripts'>Post-Installation Scripts</ulink>"
-                    section in the Yocto Project Development Manual.
+                    section in the Yocto Project Development Tasks Manual.
                 </para>
             </glossdef>
         </glossentry>
@@ -9983,7 +9988,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     For an example of how to use the <filename>PACKAGES_DYNAMIC</filename>
                     variable when you are splitting packages, see the
                     "<ulink url='&YOCTO_DOCS_DEV_URL;#handling-optional-module-packaging'>Handling Optional Module Packaging</ulink>" section
-                    in the Yocto Project Development Manual.
+                    in the Yocto Project Development Tasks Manual.
                 </para>
             </glossdef>
         </glossentry>
@@ -10048,7 +10053,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                         the recipe as a workaround.
                         For information on addressing race conditions, see the
                         "<ulink url='&YOCTO_DOCS_DEV_URL;#debugging-parallel-make-races'>Debugging Parallel Make Races</ulink>"
-                        section in the Yocto Project Development Manual.
+                        section in the Yocto Project Development Tasks Manual.
                     </note>
                     For single socket systems (i.e. one CPU), you should not
                     have to override this variable to gain optimal parallelism
@@ -10097,7 +10102,8 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                         the recipe as a workaround.
                         For information on addressing race conditions, see the
                         "<ulink url='&YOCTO_DOCS_DEV_URL;#debugging-parallel-make-races'>Debugging Parallel Make Races</ulink>"
-                        section in the Yocto Project Development Manual.</para>
+                        section in the Yocto Project Development Tasks Manual.
+                        </para>
                     </note>
                 </para>
             </glossdef>
@@ -10579,7 +10585,8 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     cumbersome and error-prone, an automated solution exists.
                     See the
                     "<ulink url='&YOCTO_DOCS_DEV_URL;#working-with-a-pr-service'>Working With a PR Service</ulink>"
-                    section for more information.
+                    section in the Yocto Project Development Tasks Manual
+                    for more information.
                 </para>
             </glossdef>
         </glossentry>
@@ -10906,7 +10913,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                 <para>
                     The <filename>conf/local.conf.sample.extended</filename>
                     configuration file in the
-                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+                    <link linkend='source-directory'>Source Directory</link>
                     shows how the <filename>PRSERV_HOST</filename> variable is
                     set:
                     <literallayout class='monospaced'>
@@ -11706,7 +11713,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
 
                 <para>
                     As an example, assume a
-                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+                    <link linkend='source-directory'>Source Directory</link>
                     top-level folder named <filename>poky</filename> and a
                     default Build Directory at <filename>poky/build</filename>.
                     In this case, the work directory the build system uses
@@ -12815,7 +12822,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                         <listitem><para><emphasis><filename>file://</filename> -</emphasis>
                             Fetches files, which are usually files shipped with
                             the
-                            <ulink url='&YOCTO_DOCS_REF_URL;#metadata'>Metadata</ulink>,
+                            <link linkend='metadata'>Metadata</link>,
                             from the local machine.
                             The path is relative to the
                             <link linkend='var-FILESPATH'><filename>FILESPATH</filename></link>
@@ -13015,7 +13022,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     The <filename>SRCPV</filename> variable is defined in the
                     <filename>meta/conf/bitbake.conf</filename> configuration
                     file in the
-                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+                    <link linkend='source-directory'>Source Directory</link>
                     as follows:
                     <literallayout class='monospaced'>
      SRCPV = "${@bb.fetch2.get_srcrev(d)}"
@@ -13059,7 +13066,8 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                         <link linkend='var-AUTOREV'><filename>AUTOREV</filename></link>
                         variable description and the
                         "<ulink url='&YOCTO_DOCS_DEV_URL;#automatically-incrementing-a-binary-package-revision-number'>Automatically Incrementing a Binary Package Revision Number</ulink>"
-                        section, which is in the Yocto Project Development Manual.
+                        section, which is in the Yocto Project Development
+                        Tasks Manual.
                     </note>
                 </para>
 
@@ -13312,7 +13320,8 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     <link linkend='var-SYSROOT_DIRS'><filename>SYSROOT_DIRS</filename></link>
                     variable and the
                     "<ulink url='&YOCTO_DOCS_DEV_URL;#new-sharing-files-between-recipes'>Sharing Files Between Recipes</ulink>"
-                    section for more information.
+                    section in the Yocto Project Development Tasks Manual
+                    for more information.
                     <note>
                         Recipes should never write files directly under
                         the <filename>STAGING_DIR</filename> directory because
@@ -14219,7 +14228,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     See the
                     <filename>meta/conf/machine/include/arm/feature-arm-thumb.inc</filename>
                     file in the
-                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+                    <link linkend='source-directory'>Source Directory</link>
                     for an example.
                 </para>
             </glossdef>
@@ -14652,7 +14661,8 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     For more information on enabling, running, and writing
                     these tests, see the
                     "<ulink url='&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing'>Performing Automated Runtime Testing</ulink>"
-                    section in the Yocto Project Development Manual and the
+                    section in the Yocto Project Development Tasks Manual and
+                    the
                     "<link linkend='ref-classes-testimage*'><filename>testimage*.bbclass</filename></link>"
                     section.
                 </para>
@@ -14736,7 +14746,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                 <para>
                     For more information on testing images, see the
                     "<ulink url='&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing'>Performing Automated Runtime Testing</ulink>"
-                    section in the Yocto Project Development Manual.
+                    section in the Yocto Project Development Tasks Manual.
                 </para>
             </glossdef>
         </glossentry>
@@ -14843,8 +14853,8 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                             Boots a QEMU image and runs the tests.
                             See the
                             "<ulink url='&YOCTO_DOCS_DEV_URL;#qemu-image-enabling-tests'>Enabling Runtime Tests on QEMU</ulink>"
-                            section in the Yocto Project Development Manual for
-                            more information.
+                            section in the Yocto Project Development Tasks
+                            Manual for more information.
                             </para></listitem>
                         <listitem><para><emphasis>"simpleremote" and "SimpleRemoteTarget":</emphasis>
                             Runs the tests on target hardware that is already
@@ -14876,7 +14886,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                 <para>
                     For information on running tests on hardware, see the
                     "<ulink url='&YOCTO_DOCS_DEV_URL;#hardware-image-enabling-tests'>Enabling Runtime Tests on Hardware</ulink>"
-                    section in the Yocto Project Development Manual.
+                    section in the Yocto Project Development Tasks Manual.
                 </para>
             </glossdef>
         </glossentry>
@@ -14965,7 +14975,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                 <para>
                     For more information on testing images, see the
                     "<ulink url='&YOCTO_DOCS_DEV_URL;#performing-automated-runtime-testing'>Performing Automated Runtime Testing</ulink>"
-                    section in the Yocto Project Development Manual.
+                    section in the Yocto Project Development Tasks Manual.
                 </para>
             </glossdef>
         </glossentry>
@@ -15019,7 +15029,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     than the default, you can uncomment and edit the following
                     statement in the
                     <filename>conf/local.conf</filename> file in the
-                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>:
+                    <link linkend='source-directory'>Source Directory</link>:
                     <literallayout class='monospaced'>
      #TMPDIR = "${TOPDIR}/tmp"
                     </literallayout>
@@ -15065,8 +15075,9 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     variable, but you can add additional packages to the list.
                     See the
                     "<ulink url='&YOCTO_DOCS_SDK_URL;#sdk-adding-individual-packages'>Adding Individual Packages to the Standard SDK</ulink>"
-                    section in the Yocto Project Software Development Kit (SDK)
-                    Developer's Guide for more information.
+                    section in the Yocto Project Application Development and
+                    the Extensible Software Development Kit (eSDK) manual
+                    for more information.
                 </para>
 
                 <para>
@@ -15076,7 +15087,8 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     section.
                     For information on setting up a cross-development
                     environment, see the
-                    <ulink url='&YOCTO_DOCS_SDK_URL;#sdk-manual'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>.
+                    <ulink url='&YOCTO_DOCS_SDK_URL;#sdk-manual'>Yocto Project Application Development and the Extensible Software Development Kit (eSDK)</ulink>
+                    manual.
                 </para>
             </glossdef>
         </glossentry>
@@ -15122,8 +15134,9 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     part of the SDK that runs on the target.
                     See the
                     "<ulink url='&YOCTO_DOCS_SDK_URL;#sdk-adding-individual-packages'>Adding Individual Packages to the Standard SDK</ulink>"
-                    section in the Yocto Project Software Development Kit (SDK)
-                    Developer's Guide for more information.
+                    section in the Yocto Project Application Development and
+                    the Extensible Software Development Kit (eSDK) manual for
+                    more information.
                 </para>
 
                 <para>
@@ -15133,7 +15146,8 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     section.
                     For information on setting up a cross-development
                     environment, see the
-                    <ulink url='&YOCTO_DOCS_SDK_URL;#sdk-manual'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>.
+                    <ulink url='&YOCTO_DOCS_SDK_URL;#sdk-manual'>Yocto Project Application Development and the Extensible Software Development Kit (eSDK)</ulink>
+                    manual.
                 </para>
             </glossdef>
         </glossentry>
@@ -15201,7 +15215,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     For example, the
                     <filename>meta/conf/machine/include/mips/README</filename>
                     file in the
-                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+                    <link linkend='source-directory'>Source Directory</link>
                     provides information for <filename>TUNE_ARCH</filename>
                     specific to the <filename>mips</filename> architecture.
                 </para>
@@ -15484,7 +15498,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                 <para>
                     Known tuning conflicts are specified in the machine include
                     files in the
-                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+                    <link linkend='source-directory'>Source Directory</link>.
                     Here is an example from the
                     <filename>meta/conf/machine/include/mips/arch-mips.inc</filename>
                     include file that lists the "o32" and "n64" features as
@@ -15516,7 +15530,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
 
                 <para>
                     See the machine include files in the
-                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+                    <link linkend='source-directory'>Source Directory</link>
                     for these features.
                 </para>
             </glossdef>
@@ -15853,7 +15867,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                 <para>
                     See the
                     "<ulink url='&YOCTO_DOCS_DEV_URL;#selecting-dev-manager'>Selecting a Device Manager</ulink>"
-                    section in the Yocto Project Development Manual for
+                    section in the Yocto Project Development Tasks Manual for
                     information on how to use this variable.
                 </para>
             </glossdef>
@@ -15908,7 +15922,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     For more information, see
                     <filename>meta-poky/conf/local.conf.sample</filename> in
                     the
-                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+                    <link linkend='source-directory'>Source Directory</link>.
                 </para>
             </glossdef>
         </glossentry>
@@ -16250,7 +16264,7 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
                     For information on how to create a partitioned image, see
                     the
                     "<ulink url='&YOCTO_DOCS_DEV_URL;#creating-partitioned-images-using-wic'>Creating Partitioned Images Using Wic</ulink>"
-                    section in the Yocto Project Development Manual.
+                    section in the Yocto Project Development Tasks Manual.
                     For details on the kickstart file format, see the
                     "<link linkend='openembedded-kickstart-wks-reference'>OpenEmbedded Kickstart (<filename>.wks</filename>) Reference</link>
                     Chapter.

documentation/ref-manual/resources.xml

@@ -28,7 +28,7 @@
         For information on how to do both as well as information on how
         to identify the maintainer for each area of code, see the
         "<ulink url='&YOCTO_DOCS_DEV_URL;#how-to-submit-a-change'>Submitting a Change to the Yocto Project</ulink>"
-        section in the Yocto Project Development Manual.
+        section in the Yocto Project Development Tasks Manual.
     </para>
 </section>
 
@@ -61,7 +61,7 @@
             <listitem><para>
                 The
                 "<ulink url='&YOCTO_DOCS_DEV_URL;#submitting-a-defect-against-the-yocto-project'>Submitting a Defect Against the Yocto Project</ulink>"
-                section in the Yocto Project Development Manual.
+                section in the Yocto Project Development Tasks Manual.
                 </para></listitem>
             <listitem><para>
                 The Yocto Project
@@ -93,7 +93,7 @@
                 build tool.</para></listitem>
             <listitem><para><ulink url='&YOCTO_LISTS_URL;/listinfo/poky'></ulink> -
                 Discussion mailing list about
-                <ulink url='&YOCTO_DOCS_DEV_URL;#poky'>Poky</ulink>.
+                <link linkend='poky'>Poky</link>.
                 </para></listitem>
             <listitem><para><ulink url='&YOCTO_LISTS_URL;/listinfo/yocto-announce'></ulink> -
                 Mailing list to receive official Yocto Project release and milestone
@@ -167,7 +167,7 @@
                 </para></listitem>
             <listitem><para>
                 <emphasis>
-                <ulink url='&YOCTO_DOCS_DEV_URL;'>Yocto Project Development Manual</ulink>:
+                <ulink url='&YOCTO_DOCS_DEV_URL;'>Yocto Project Development Tasks Manual</ulink>:
                 </emphasis>
                 This manual is a "how-to" guide that presents procedures
                 useful to both application and system developers who use the
@@ -175,8 +175,8 @@
                 </para></listitem>
             <listitem><para>
                 <emphasis>
-                <ulink url='&YOCTO_DOCS_SDK_URL;'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>:
-                </emphasis>
+                <ulink url='&YOCTO_DOCS_SDK_URL;'>Yocto Project Application Development and the Extensible Software Development Kit (eSDK)</ulink>
+                manual:</emphasis>
                 This guide provides information that lets you get going
                 with the standard or extensible SDK.
                 An SDK, with its cross-development toolchains, allows you
@@ -236,7 +236,7 @@
                 Toaster.
                 Toaster is an Application Programming Interface (API) and
                 web-based interface to the
-                <ulink url='&YOCTO_DOCS_DEV_URL;#build-system-term'>OpenEmbedded Build System</ulink>,
+                <link linkend='build-system-term'>OpenEmbedded Build System</link>,
                 which uses BitBake, that reports build information.
                 </para></listitem>
             <listitem><para>

documentation/ref-manual/technical-details.xml

@@ -48,7 +48,8 @@
         to each data source as a layer.
         For information on layers, see the
         "<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and
-        Creating Layers</ulink>" section of the Yocto Project Development Manual.
+        Creating Layers</ulink>" section of the Yocto Project Development
+        Tasks Manual.
     </para>
 
     <para>
@@ -65,7 +66,7 @@
         <para>
             BitBake is the tool at the heart of the OpenEmbedded build system
             and is responsible for parsing the
-            <ulink url='&YOCTO_DOCS_REF_URL;#metadata'>Metadata</ulink>,
+            <link linkend='metadata'>Metadata</link>,
             generating a list of tasks from it, and then executing those tasks.
         </para>
 
@@ -209,7 +210,7 @@
         <para>
             Class files (<filename>.bbclass</filename>) contain information that
             is useful to share between
-            <ulink url='&YOCTO_DOCS_REF_URL;#metadata'>Metadata</ulink> files.
+            <link linkend='metadata'>Metadata</link> files.
             An example is the
             <link linkend='ref-classes-autotools'><filename>autotools</filename></link>
             class, which contains common settings for any application that
@@ -244,7 +245,8 @@
         This section provides some technical background on how
         cross-development toolchains are created and used.
         For more information on toolchains, you can also see the
-        <ulink url='&YOCTO_DOCS_SDK_URL;'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>.
+        <ulink url='&YOCTO_DOCS_SDK_URL;'>Yocto Project Application Development and the Extensible Software Development Kit (eSDK)</ulink>
+        manual.
     </para>
 
     <para>
@@ -429,8 +431,8 @@
         For information on advantages gained when building a
         cross-development toolchain installer, see the
         "<ulink url='&YOCTO_DOCS_SDK_URL;#sdk-building-an-sdk-installer'>Building an SDK Installer</ulink>"
-        section in the Yocto Project Software Development Kit (SDK) Developer's
-        Guide.
+        section in the Yocto Project Application Development and the
+        Extensible Software Development Kit (eSDK) manual.
     </note>
 </section>
 
@@ -490,7 +492,7 @@
         works with packages and can
         track incrementing <filename>PR</filename> information, see the
         "<ulink url='&YOCTO_DOCS_DEV_URL;#automatically-incrementing-a-binary-package-revision-number'>Automatically Incrementing a Binary Package Revision Number</ulink>"
-        section.
+        section in the Yocto Project Development Tasks Manual.
     </note>
 
     <para>
@@ -655,11 +657,12 @@
             The code in <filename>meta/lib/oe/sstatesig.py</filename> shows two examples
             of this and also illustrates how you can insert your own policy into the system
             if so desired.
-            This file defines the two basic signature generators <filename>OE-Core</filename>
-            uses:  "OEBasic" and "OEBasicHash".
+            This file defines the two basic signature generators
+            <link linkend='oe-core'>OE-Core</link> uses:  "OEBasic" and
+            "OEBasicHash".
             By default, there is a dummy "noop" signature handler enabled in BitBake.
             This means that behavior is unchanged from previous versions.
-            <filename>OE-Core</filename> uses the "OEBasicHash" signature handler by default
+            OE-Core uses the "OEBasicHash" signature handler by default
             through this setting in the <filename>bitbake.conf</filename> file:
             <literallayout class='monospaced'>
      BB_SIGNATURE_HANDLER ?= "OEBasicHash"
@@ -667,7 +670,7 @@
             The "OEBasicHash" <filename>BB_SIGNATURE_HANDLER</filename> is the same as the
             "OEBasic" version but adds the task hash to the stamp files.
             This results in any
-            <ulink url='&YOCTO_DOCS_REF_URL;#metadata'>Metadata</ulink>
+            <link linkend='metadata'>Metadata</link>
             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>
@@ -1261,7 +1264,7 @@
         This section explains the Wic plug-in interface.
         For information on using Wic in general, see the
         "<ulink url='&YOCTO_DOCS_DEV_URL;#creating-partitioned-images-using-wic'>Creating Partitioned Images Using Wic</ulink>"
-        section in the Yocto Project Development Manual.
+        section in the Yocto Project Development Tasks Manual.
         <note>
             Wic plug-ins consist of "source" and "imager" plug-ins.
             Imager plug-ins are beyond the scope of this section.
@@ -1574,7 +1577,7 @@
             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>.
+            <link linkend='source-directory'>Source Directory</link>.
             Specifically, you can find the recipes that build both Wayland
             and Weston at <filename>meta/recipes-graphics/wayland</filename>.
         </para>
@@ -1689,8 +1692,8 @@
     <para>
         For information that can help you maintain compliance with various open
         source licensing during the lifecycle of the product, see the
-        "<ulink url='&YOCTO_DOCS_DEV_URL;#maintaining-open-source-license-compliance-during-your-products-lifecycle'>Maintaining Open Source License Compliance During Your Project's Lifecycle</ulink>" section
-        in the Yocto Project Development Manual.
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#maintaining-open-source-license-compliance-during-your-products-lifecycle'>Maintaining Open Source License Compliance During Your Project's Lifecycle</ulink>"
+        section in the Yocto Project Development Tasks Manual.
     </para>
 
     <section id="usingpoky-configuring-LIC_FILES_CHKSUM">

documentation/ref-manual/usingpoky.xml

@@ -107,7 +107,7 @@
             The <replaceable>target</replaceable> is the name of the recipe you want to build.
             Common targets are the images in <filename>meta/recipes-core/images</filename>,
             <filename>meta/recipes-sato/images</filename>, etc. all found in the
-            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
+            <link linkend='source-directory'>Source Directory</link>.
             Or, the target can be the name of a recipe for a specific piece of software such as
             BusyBox.
             For more details about the images the OpenEmbedded build system supports, see the
@@ -145,7 +145,8 @@
         <filename class="directory">tmp/deploy/images</filename>.
         For information on how to run pre-built images such as <filename>qemux86</filename>
         and <filename>qemuarm</filename>, see the
-        <ulink url='&YOCTO_DOCS_SDK_URL;#sdk-manual'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>.
+        <ulink url='&YOCTO_DOCS_SDK_URL;#sdk-manual'>Yocto Project Application Development and the Extensible Software Development Kit (eSDK)</ulink>
+        manual.
         For information about how to install these images, see the documentation for your
         particular board or machine.
     </para>
@@ -176,16 +177,17 @@
         going wrong.
         For information on how to enable and use this feature, see the
         "<ulink url='&YOCTO_DOCS_DEV_URL;#using-the-error-reporting-tool'>Using the Error Reporting Tool</ulink>"
-        section in the Yocto Project Development Manual.
+        section in the Yocto Project Development Tasks Manual.
     </para>
 
     <para>
         For discussions on debugging, see the
         "<ulink url='&YOCTO_DOCS_DEV_URL;#platdev-gdb-remotedebug'>Debugging With the GNU Project Debugger (GDB) Remotely</ulink>" section
-        in the Yocto Project Developer's Manual
+        in the Yocto Project Development Tasks Manual
         and the
         "<ulink url='&YOCTO_DOCS_SDK_URL;#adt-eclipse'>Working within Eclipse</ulink>"
-        section in the Yocto Project Software Development Kit (SDK) Developer's Guide.
+        section in the Yocto Project Application Development and the
+        Extensible Software Development Kit (eSDK) manual.
     </para>
 
     <note>
@@ -873,7 +875,7 @@
             class implements these functions.
             See that class in the
             <filename>meta/classes</filename> folder of the
-            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+            <link linkend='source-directory'>Source Directory</link>
             for information.
         </para>
 
@@ -1034,7 +1036,8 @@
                     <ulink url='&YOCTO_WIKI_URL;/wiki/Bugzilla_Configuration_and_Bug_Tracking'>wiki page</ulink>"
                     or the
                     <ulink url='&YOCTO_DOCS_DEV_URL;#submitting-a-defect-against-the-yocto-project'>Submitting a Defect Against the Yocto Project</ulink>"
-                    section, which is in the Yocto Project Development Manual.
+                    section, which is in the Yocto Project Development Tasks
+                    Manual.
                     <note>
                         The manuals might not be the right place to document
                         variables that are purely internal and have a limited
@@ -1092,7 +1095,7 @@
         For information on how to use the Yocto Project implementation of
         QEMU, see the
         "<ulink url='&YOCTO_DOCS_DEV_URL;#dev-manual-qemu'>Using the Quick EMUlator (QEMU)</ulink>"
-        chapter in the Yocto Project Development Manual.
+        chapter in the Yocto Project Development Tasks Manual.
     </para>
 
     <section id='qemu-availability'>
@@ -1104,8 +1107,8 @@
             For more information on how to make sure you have
             QEMU available, see
             "<ulink url='&YOCTO_DOCS_SDK_URL;#the-qemu-emulator'>The QEMU Emulator</ulink>"
-            section in the Yocto Project Software Development Kit (SDK)
-            Developer's Guide.
+            section in the Yocto Project Application Development and the
+            Extensible Software Development Kit (eSDK) manual.
         </para>
     </section>
 
@@ -1180,8 +1183,8 @@
                     filesystem image file.
                     See the
                     "<ulink url='&YOCTO_DOCS_DEV_URL;#qemu-running-under-a-network-file-system-nfs-server'>Running Under a Network File System (NFS) Server</ulink>"
-                    section in the Yocto Project Development Manual for more
-                    information.
+                    section in the Yocto Project Development Tasks Manual for
+                    more information.
                     </para></listitem>
             </itemizedlist>
         </note>
@@ -1204,7 +1207,7 @@
             image.
             Minimally, through the use of options, you must provide either
             a machine name, a virtual machine image
-            (<filename>*.vmdk</filename>), or a kernel image
+            (<filename>*wic.vmdk</filename>), or a kernel image
             (<filename>*.bin</filename>).
         </para>
 
@@ -1475,9 +1478,9 @@ qemux86" or "qemux86-64".
      INHERIT += "buildhistory"
      BUILDHISTORY_COMMIT = "1"
             </literallayout>
-            Enabling build history as previously described
-            causes the build process to collect build
-            output information and commit it to a local
+            Enabling build history as previously described causes the
+            OpenEmbedded build system to collect build output information and
+            commit it as a single commit to a local
             <link linkend='git'>Git</link> repository.
             <note>
                 Enabling build history increases your build times slightly,

documentation/sdk-manual/sdk-appendix-mars.xml

@@ -14,8 +14,8 @@
         from start to finish.
         For general information on using the Eclipse IDE and the Yocto
         Project Eclipse Plug-In, see the
-        "<link linkend='sdk-developing-applications-using-eclipse'>Developing Applications Using <trademark class='trade'>Eclipse</trademark></link>"
-        section.
+        "<link linkend='sdk-eclipse-project'>Developing Applications Using <trademark class='trade'>Eclipse</trademark></link>"
+        Chapter.
     </para>
 
     <section id='mars-setting-up-the-eclipse-ide'>
@@ -700,7 +700,7 @@
             <note>
                 See the
                 "<ulink url='&YOCTO_DOCS_DEV_URL;#dev-manual-qemu'>Using the Quick EMUlator (QEMU)</ulink>"
-                chapter in the Yocto Project Development Manual
+                chapter in the Yocto Project Development Tasks Manual
                 for more information on using QEMU.
             </note>
             <orderedlist>

documentation/sdk-manual/sdk-appendix-obtain.xml

@@ -106,9 +106,9 @@
                 Be sure you are set up to use BitBake in a shell.
                 See the
                 "<ulink url='&YOCTO_DOCS_DEV_URL;#setting-up-the-development-host-to-use-the-yocto-project'>Setting Up the Development Host to Use the Yocto Project</ulink>"
-                section in the Yocto Project Development Manual for information
-                on how to get a build host ready that is either a native
-                Linux machine or a machine that uses CROPS.
+                section in the Yocto Project Development Tasks Manual for
+                information on how to get a build host ready that is either a
+                native Linux machine or a machine that uses CROPS.
                 </para></listitem>
             <listitem><para>
                 <emphasis>Clone the <filename>poky</filename> Repository:</emphasis>
@@ -121,7 +121,7 @@
                 "<ulink url='&YOCTO_DOCS_DEV_URL;#checking-out-by-branch-in-poky'>Checking Out by Branch in Poky</ulink>"
                 and
                 "<ulink url='&YOCTO_DOCS_DEV_URL;#checkout-out-by-tag-in-poky'>Checking Out by Tag in Poky</ulink>"
-                sections all in the Yocto Project Development Manual for
+                sections all in the Yocto Project Development Tasks Manual for
                 information on how to clone the <filename>poky</filename>
                 repository and check out the appropriate branch for your work.
                 </para></listitem>

documentation/sdk-manual/sdk-extensible.xml

@@ -15,7 +15,7 @@
         to an image, modify the source for an existing component, test
         changes on the target hardware, and ease integration into the rest of
         the
-        <ulink url='&YOCTO_DOCS_DEV_URL;#build-system-term'>OpenEmbedded build system</ulink>.
+        <ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>OpenEmbedded build system</ulink>.
         <note>
             For a side-by-side comparison of main features supported for an
             extensible SDK as compared to a standard SDK, see the
@@ -306,7 +306,7 @@
                 The <filename>devtool add</filename> command generates
                 a new recipe based on existing source code.
                 This command takes advantage of the
-                <ulink url='&YOCTO_DOCS_DEV_URL;#devtool-the-workspace-layer-structure'>workspace</ulink>
+                <ulink url='&YOCTO_DOCS_REF_URL;#devtool-the-workspace-layer-structure'>workspace</ulink>
                 layer that many <filename>devtool</filename> commands
                 use.
                 The command is flexible enough to allow you to extract source

documentation/sdk-manual/sdk-intro.xml

@@ -9,8 +9,8 @@
     <title>Introduction</title>
 
     <para>
-        Welcome to the Yocto Project Software Development Kit (SDK)
-        Developer's Guide.
+        Welcome to the Yocto Project Application Development and the
+        Extensible Software Development Kit (eSDK) manual.
         This manual provides information that explains how to use both the
         Yocto Project extensible and standard SDKs to develop
         applications and images.
@@ -52,7 +52,7 @@
         new applications and libraries to an image, modify the source of an
         existing component, test changes on the target hardware, and easily
         integrate an application into the
-        <ulink url='&YOCTO_DOCS_DEV_URL;#build-system-term'>OpenEmbedded build system</ulink>.
+        <ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>OpenEmbedded build system</ulink>.
     </para>
 
     <para>
@@ -245,16 +245,15 @@
                 <listitem><para>
                     If you have cloned the <filename>poky</filename> Git
                     repository to create a
-                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+                    <ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink>
                     and you have sourced the environment setup script, QEMU is
                     installed and automatically available.
                     </para></listitem>
                 <listitem><para>
                     If you have downloaded a Yocto Project release and unpacked
-                    it to create a
-                    <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
-                    and you have sourced the environment setup script, QEMU is
-                    installed and automatically available.
+                    it to create a Source Directory and you have sourced the
+                    environment setup script, QEMU is installed and
+                    automatically available.
                     </para></listitem>
                 <listitem><para>
                     If you have installed the cross-toolchain tarball and you
@@ -295,8 +294,8 @@
             For information about the application development workflow that
             uses the Eclipse IDE and for a detailed example of how to install
             and configure the Eclipse Yocto Project Plug-in, see the
-            "<link linkend='sdk-developing-applications-using-eclipse'>Developing Applications Using <trademark class='trade'>Eclipse</trademark></link>"
-            section.
+            "<link linkend='sdk-eclipse-project'>Developing Applications Using <trademark class='trade'>Eclipse</trademark></link>"
+            Chapter.
         </para>
     </section>
 
@@ -385,7 +384,7 @@
                 to download and learn about the emulator.
                 See the
                 "<ulink url='&YOCTO_DOCS_DEV_URL;#dev-manual-qemu'>Using the Quick EMUlator (QEMU)</ulink>"
-                chapter in the Yocto Project Development Manual
+                chapter in the Yocto Project Development Tasks Manual
                 for information on using QEMU within the Yocto
                 Project.</para></listitem>
         </orderedlist>

documentation/sdk-manual/sdk-manual.xml

@@ -17,14 +17,14 @@
         </mediaobject>
 
         <title>
-            Yocto Project Software Development Kit (SDK) Developer's Guide
+            Yocto Project Application Development and the Extensible Software Development Kit (eSDK)
         </title>
 
         <authorgroup>
             <author>
                 <firstname>Scott</firstname> <surname>Rifenbark</surname>
                 <affiliation>
-                    <orgname>Scotty's Documentation Services, LLC</orgname>
+                    <orgname>Scotty's Documentation Services, INC</orgname>
                 </affiliation>
                 <email>srifenbark@gmail.com</email>
             </author>
@@ -66,28 +66,29 @@
            <note><title>Manual Notes</title>
                <itemizedlist>
                    <listitem><para>
-                       For the latest version of the Yocto Project Software
-                       Development Kit (SDK) Developer's Guide associated with
-                       this Yocto Project release (version &YOCTO_DOC_VERSION;),
-                       see the Yocto Project Software Development Kit (SDK)
-                       Developer's Guide from the
+                       This version of the
+                       <emphasis>Yocto Project Application Development and the Extensible Software Development Kit (eSDK)</emphasis>
+                       manual is for the &YOCTO_DOC_VERSION; release of the
+                       Yocto Project.
+                       To be sure you have the latest version of the manual
+                       for this release, use the manual from the
                        <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink>.
                        </para></listitem>
                    <listitem><para>
-                       This version of the manual is version
-                       &YOCTO_DOC_VERSION;.
-                       For later releases of the Yocto Project (if they exist),
-                       go to the
+                       For manuals associated with other releases of the Yocto
+                       Project, go to the
                        <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink>
                        and use the drop-down "Active Releases" button
-                       and choose the Yocto Project version for which you want
-                       the manual.
+                       and choose the manual associated with the desired
+                       Yocto Project.
                        </para></listitem>
                    <listitem><para>
-                       For an in-development version of the Yocto Project
-                       Software Development Kit (SDK) Developer's Guide, see
-                       <ulink url='&YOCTO_DOCS_URL;/latest/sdk-manual/sdk-manual.html'></ulink>.
-                       </para></listitem>
+                        To report any inaccuracies or problems with this
+                        manual, send an email to the Yocto Project
+                        discussion group at
+                        <filename>yocto@yoctoproject.com</filename> or log into
+                        the freenode <filename>#yocto</filename> channel.
+                        </para></listitem>
                </itemizedlist>
            </note>
 
@@ -103,6 +104,8 @@
 
     <xi:include href="sdk-working-projects.xml"/>
 
+    <xi:include href="sdk-eclipse-project.xml"/>
+
     <xi:include href="sdk-appendix-obtain.xml"/>
 
     <xi:include href="sdk-appendix-customizing.xml"/>

documentation/toaster-manual/toaster-manual-intro.xml

@@ -7,7 +7,7 @@
 
     <para>
         Toaster is a web interface to the Yocto Project's
-        <ulink url='&YOCTO_DOCS_DEV_URL;#build-system-term'>OpenEmbedded build system</ulink>.
+        <ulink url='&YOCTO_DOCS_REF_URL;#build-system-term'>OpenEmbedded build system</ulink>.
         The interface enables you to configure and run your builds.
         Information about builds is collected and stored in a database.
         You can use Toaster to configure and start builds on multiple

documentation/toaster-manual/toaster-manual-reference.xml

@@ -356,8 +356,8 @@
                 <filename>custom.xml</filename> file.
             </para>
 
-            <section id='defining-the-default-distro'>
-                <title>Defining the Default Distro</title>
+            <section id='defining-the-default-distro-and-other-values'>
+                <title>Defining the Default Distro and Other Values</title>
 
                 <para>
                     This section defines the default distro value for new projects.
@@ -372,16 +372,15 @@
        &lt;field type="CharField" name="value"&gt;poky&lt;/field&gt;
      &lt;/object&gt;
                     </literallayout>
-                    <note>
-                       You can override the default value by adding additional
-                       Toaster Setting sections such as any of the settings coming
-                       from the <filename>settings.xml</filename> file.
+                       You can override other default project values by adding
+                       additional Toaster Setting sections such as any of the
+                       settings coming from the <filename>settings.xml</filename>
+                       file.
                        Also, you can add custom values that are included in the
                        BitBake environment.
                        The "pk" values must be unique.
                        By convention, values that set default project values have a
                        "DEFCONF" prefix.
-                    </note>
                 </para>
             </section>
 
@@ -678,7 +677,7 @@
             created that are specific to Toaster and are used to control
             configuration and back-end tasks.
             You can locate these commands in the
-            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+            <ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink>
             (e.g. <filename>poky</filename>) at
             <filename>bitbake/lib/manage.py</filename>.
             This section documents those commands.

documentation/toaster-manual/toaster-manual-setup-and-use.xml

@@ -18,7 +18,7 @@
 
         <para>
             Navigate to the root of your
-            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+            <ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink>
             (e.g. <filename>poky</filename>):
             <literallayout class='monospaced'>
      $ cd poky

documentation/toaster-manual/toaster-manual-start.xml

@@ -41,7 +41,7 @@
             The requirements file is located in the
             <filename>bitbake</filename> directory, which is located in the
             root directory of the
-            <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>
+            <ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink>
             (e.g. <filename>poky/bitbake/toaster-requirements.txt</filename>).
             The dependencies appear in a <filename>pip</filename>,
             install-compatible format.

documentation/toaster-manual/toaster-manual.xml

@@ -22,11 +22,11 @@
 
         <authorgroup>
             <author>
-                <firstname>Scott</firstname> <surname>Rifenbark</surname>
+                <firstname>Kristi</firstname> <surname>Rifenbark</surname>
                 <affiliation>
-                    <orgname>Intel Corporation</orgname>
+                    <orgname>Scotty's Documentation Services, INC</orgname>
                 </affiliation>
-                <email>srifenbark@gmail.com</email>
+                <email>kristi@buzzcollectivemarketing.com</email>
             </author>
         </authorgroup>
 
@@ -76,27 +76,29 @@
            <note><title>Manual Notes</title>
                <itemizedlist>
                    <listitem><para>
-                       For the latest version of the Yocto Project Toaster
-                       User Manual associated with this Yocto Project release
-                       (version &YOCTO_DOC_VERSION;),
-                       see the Yocto Project Toaster User Manual from the
+                       This version of the
+                       <emphasis>Toaster User Manual</emphasis>
+                       is for the &YOCTO_DOC_VERSION; release of the
+                       Yocto Project.
+                       To be sure you have the latest version of the manual
+                       for this release, use the manual from the
                        <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink>.
                        </para></listitem>
                    <listitem><para>
-                       This version of the manual is version
-                       &YOCTO_DOC_VERSION;.
-                       For later releases of the Yocto Project (if they exist),
-                       go to the
+                       For manuals associated with other releases of the Yocto
+                       Project, go to the
                        <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink>
                        and use the drop-down "Active Releases" button
-                       and choose the Yocto Project version for which you want
-                       the manual.
+                       and choose the manual associated with the desired
+                       Yocto Project.
                        </para></listitem>
                    <listitem><para>
-                       For an in-development version of the Yocto Project
-                       Toaster User Manual, see
-                       <ulink url='&YOCTO_DOCS_URL;/latest/toaster-manual/toaster-manual.html'></ulink>.
-                       </para></listitem>
+                        To report any inaccuracies or problems with this
+                        manual, send an email to the Yocto Project
+                        discussion group at
+                        <filename>yocto@yoctoproject.com</filename> or log into
+                        the freenode <filename>#yocto</filename> channel.
+                        </para></listitem>
                </itemizedlist>
            </note>
 

documentation/tools/mega-manual.sed

@@ -24,7 +24,7 @@ s/\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.4\/yocto-project-qs\/y
 
 # Process cases where just an external manual is referenced without an id anchor
 s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.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\/2.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\/2.4\/dev-manual\/dev-manual.html\" target=\"_top\">Yocto Project Development Tasks Manual<\/a>/Yocto Project Development Tasks Manual/g
 s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.4\/sdk-manual\/sdk-manual.html\" target=\"_top\">Yocto Project Software Development Kit (SDK) Developer's Guide<\/a>/Yocto Project Software Development Kit (SDK) Developer's Guide/g
 s/<a class=\"ulink\" href=\"http:\/\/www.yoctoproject.org\/docs\/2.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\/2.4\/profile-manual\/profile-manual.html\" target=\"_top\">Yocto Project Profiling and Tracing Manual<\/a>/Yocto Project Profiling and Tracing Manual/g

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

@@ -16,32 +16,34 @@
                 Permission is granted to copy, distribute and/or modify this document under
                 the terms of the <ulink type="http" url="http://creativecommons.org/licenses/by-sa/2.0/uk/">Creative Commons Attribution-Share Alike 2.0 UK: England &amp; Wales</ulink> as published by Creative Commons.
             </para>
-            <note><title>Manual Notes</title>
-                <itemizedlist>
-                    <listitem><para>
-                        For the latest version of the Yocto Project Quick
-                        Start associated with this Yocto Project release
-                        (version &YOCTO_DOC_VERSION;),
-                        see the Yocto Project Quick Start from the
-                        <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink>.
+           <note><title>Manual Notes</title>
+               <itemizedlist>
+                   <listitem><para>
+                       This version of the
+                       <emphasis>Yocto Project Quick Start</emphasis>
+                       is for the &YOCTO_DOC_VERSION; release of the
+                       Yocto Project.
+                       To be sure you have the latest version of the manual
+                       for this release, use the manual from the
+                       <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink>.
+                       </para></listitem>
+                   <listitem><para>
+                       For manuals associated with other releases of the Yocto
+                       Project, go to the
+                       <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink>
+                       and use the drop-down "Active Releases" button
+                       and choose the manual associated with the desired
+                       Yocto Project.
+                       </para></listitem>
+                   <listitem><para>
+                        To report any inaccuracies or problems with this
+                        manual, send an email to the Yocto Project
+                        discussion group at
+                        <filename>yocto@yoctoproject.com</filename> or log into
+                        the freenode <filename>#yocto</filename> channel.
                         </para></listitem>
-                    <listitem><para>
-                        This version of the manual is version
-                        &YOCTO_DOC_VERSION;.
-                        For later releases of the Yocto Project (if they exist),
-                        go to the
-                        <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink>
-                        and use the drop-down "Active Releases" button
-                        and choose the Yocto Project version for which you want
-                        the manual.
-                        </para></listitem>
-                    <listitem><para>
-                        For an in-development version of the Yocto Project
-                        Quick Start, see
-                        <ulink url='&YOCTO_DOCS_URL;/latest/yocto-project-qs/yocto-project-qs.html'></ulink>.
-                        </para></listitem>
-                </itemizedlist>
-            </note>
+               </itemizedlist>
+           </note>
         </legalnotice>
 
         <abstract>
@@ -211,7 +213,7 @@
                         Work through the first six steps of the procedure
                         in the
                         "<ulink url='&YOCTO_DOCS_DEV_URL;#setting-up-to-use-crops'>Setting Up to Use CROss PlatformS (CROPS)</ulink>"
-                        section of the Yocto Project Development Manual.
+                        section of the Yocto Project Development Tasks Manual.
                         </para></listitem>
                     <listitem><para>
                         <emphasis>Set Up the Poky Container to Use the Yocto Project:</emphasis>
@@ -427,9 +429,9 @@
                     If your build host is using a Poky container, you can
                     use the same Git commands.
                 </note>
-                The example clones the <filename>poky</filename> repository
-                and then checks out the latest Yocto Project Release by tag
-                (i.e. <filename>&DISTRO_REL_TAG;</filename>):
+                The following example clones the <filename>poky</filename>
+                repository and then checks out the latest Yocto Project Release
+                by tag (i.e. <filename>&DISTRO_REL_TAG;</filename>):
                 <literallayout class='monospaced'>
      $ git clone git://git.yoctoproject.org/poky
      Cloning into 'poky'...
@@ -456,8 +458,10 @@
                     Rather than checking out the entire development branch
                     of a release (i.e. the tip), which could be continuously
                     changing while you are doing your development, you would
-                    check out a branch based on a release tag.  Doing so
-                    provides you with an unchanging, stable set of files.
+                    check out a branch based on a release tag as shown in
+                    the previous example.
+                    Doing so provides you with an unchanging, stable set of
+                    files.
                 </note>
             </para>
 
@@ -465,7 +469,7 @@
                 For more options and information about accessing Yocto
                 Project related repositories, see the
                 "<ulink url='&YOCTO_DOCS_DEV_URL;#working-with-yocto-project-source-files'>Working With Yocto Project Source Files</ulink>"
-                section in the Yocto Project Development Manual.
+                section in the Yocto Project Development Tasks Manual.
             </para>
         </section>
     </section>
@@ -479,7 +483,8 @@
             your images.
             <note>
                 A graphical user interface to the Yocto Project is available
-                through Toaster.
+                through
+                <ulink url='&YOCTO_DOCS_REF_URL;#toaster-term'>Toaster</ulink>.
                 See the
                 <ulink url='&YOCTO_DOCS_TOAST_URL;'>Toaster User Manual</ulink>
                 for more information.
@@ -518,31 +523,32 @@
                 Use the following commands to build your image.
                 The OpenEmbedded build system creates an entire Linux
                 distribution, including the toolchain, from source.
-                <note><title>Note about Network Proxies</title>
-                    <para>
-                        By default, the build process searches for source code
-                        using a pre-determined order through a set of
-                        locations.
-                        If you are working behind a firewall and your build
-                        host is not set up for proxies, you could encounter
-                        problems with the build process when fetching source
-                        code (e.g. fetcher failures or Git failures).
-                    </para>
-
-                    <para>
-                        If you do not know your proxy settings, consult your
-                        local network infrastructure resources and get that
-                        information.
-                        A good starting point could also be to check your web
-                        browser settings.
-                        Finally, you can find more information on using the
-                        Yocto Project behind a firewall in the Yocto Project
-                        Reference Manual
-                        <ulink url='&YOCTO_DOCS_REF_URL;#how-does-the-yocto-project-obtain-source-code-and-will-it-work-behind-my-firewall-or-proxy-server'>FAQ</ulink>
-                        and on the
-                        "<ulink url='https://wiki.yoctoproject.org/wiki/Working_Behind_a_Network_Proxy'>Working Behind a Network Proxy</ulink>"
-                        wiki page.
-                    </para>
+                <note><title>Notes about Network Proxies</title>
+                    <itemizedlist>
+                        <listitem><para>
+                            By default, the build process searches for source
+                            code using a pre-determined order through a set of
+                            locations.
+                            If you are working behind a firewall and your build
+                            host is not set up for proxies, you could encounter
+                            problems with the build process when fetching source
+                            code (e.g. fetcher failures or Git failures).
+                            </para></listitem>
+                        <listitem><para>
+                            If you do not know your proxy settings, consult your
+                            local network infrastructure resources and get that
+                            information.
+                            A good starting point could also be to check your
+                            web browser settings.
+                            Finally, you can find more information on using the
+                            Yocto Project behind a firewall in the Yocto Project
+                            Reference Manual
+                            <ulink url='&YOCTO_DOCS_REF_URL;#how-does-the-yocto-project-obtain-source-code-and-will-it-work-behind-my-firewall-or-proxy-server'>FAQ</ulink>
+                            and on the
+                            "<ulink url='https://wiki.yoctoproject.org/wiki/Working_Behind_a_Network_Proxy'>Working Behind a Network Proxy</ulink>"
+                            wiki page.
+                            </para></listitem>
+                    </itemizedlist>
                 </note>
             </para>
 
@@ -720,7 +726,7 @@
                         </literallayout>
                         If you want to learn more about running QEMU, see the
                         "<ulink url="&YOCTO_DOCS_DEV_URL;#dev-manual-qemu">Using the Quick EMUlator (QEMU)</ulink>"
-                        chapter in the Yocto Project Development Manual.
+                        chapter in the Yocto Project Development Tasks Manual.
                         </para></listitem>
                     <listitem><para>
                         <emphasis>Exit QEMU:</emphasis>
@@ -975,7 +981,7 @@
                     </para></listitem>
                 <listitem><para>
                     <emphasis>Look Through the
-                    <ulink url='&YOCTO_DOCS_DEV_URL;#dev-manual-intro'>Yocto Project Development Manual</ulink>:</emphasis>
+                    <ulink url='&YOCTO_DOCS_DEV_URL;#dev-manual-intro'>Yocto Project Development Tasks Manual</ulink>:</emphasis>
                     This manual contains procedural information grouped to
                     help you get set up, work with layers, customize images,
                     write new recipes, work with libraries, and use QEMU.
@@ -984,7 +990,8 @@
                     </para></listitem>
                 <listitem><para>
                     <emphasis>Look Through the
-                    <ulink url='&YOCTO_DOCS_SDK_URL;#sdk-intro'>Yocto Project Software Development Kit (SDK) Developer's Guide</ulink>:</emphasis>
+                    <ulink url='&YOCTO_DOCS_SDK_URL;#sdk-intro'>Yocto Project Application Development and the Extensible Software Development Kit (eSDK)</ulink>
+                    manual:</emphasis>
                     This manual describes how to use both the
                     <ulink url='&YOCTO_DOCS_SDK_URL;#sdk-using-the-standard-sdk'>standard SDK</ulink>
                     and the

meta-poky/conf/distro/poky.conf

@@ -1,6 +1,6 @@
 DISTRO = "poky"
 DISTRO_NAME = "Poky (Yocto Project Reference Distro)"
-DISTRO_VERSION = "2.4"
+DISTRO_VERSION = "2.4.1"
 DISTRO_CODENAME = "rocko"
 SDK_VENDOR = "-pokysdk"
 SDK_VERSION := "${@'${DISTRO_VERSION}'.replace('snapshot-${DATE}','snapshot')}"

meta-selftest/files/static-group

@@ -0,0 +1,14 @@
+messagebus:x:500:
+systemd-bus-proxy:x:501:
+systemd-network:x:502:
+systemd-resolve:x:503:
+systemd-timesync:x:504:
+polkitd:x:505:
+lock:x:506:
+systemd-journal:x:507:
+netdev:x:508:
+avahi:x:509:
+avahi-autoipd:x:510:
+rpc:x:511:
+rpcuser:x:513:
+

meta-selftest/files/static-passwd

@@ -0,0 +1,11 @@
+messagebus:x:500:500::/var/lib/dbus:/bin/false
+systemd-bus-proxy:x:501:501::/:/bin/nologin
+systemd-network:x:502:502::/:/bin/nologin
+systemd-resolve:x:503:503::/:/bin/nologin
+systemd-timesync:x:504:504::/:/bin/nologin
+polkitd:x:505:505::/:/bin/nologin
+avahi:x:509:509::/:/bin/nologin
+avahi-autoipd:x:510:510::/:/bin/nologin
+rpc:x:511:511::/:/bin/nologin
+distcc:x:512:nogroup::/:/bin/nologin
+rpcuser:x:513:513::/var/lib/nfs:/bin/nologin

meta/classes/base.bbclass

@@ -178,7 +178,7 @@ def pkgarch_mapping(d):
 
 def get_layers_branch_rev(d):
     layers = (d.getVar("BBLAYERS") or "").split()
-    layers_branch_rev = ["%-17s = \"%s:%s\"" % (os.path.basename(i), \
+    layers_branch_rev = ["%-20s = \"%s:%s\"" % (os.path.basename(i), \
         base_get_metadata_git_branch(i, None).strip(), \
         base_get_metadata_git_revision(i, None)) \
             for i in layers]
@@ -206,7 +206,7 @@ def buildcfg_vars(d):
     for var in statusvars:
         value = d.getVar(var)
         if value is not None:
-            yield '%-17s = "%s"' % (var, value)
+            yield '%-20s = "%s"' % (var, value)
 
 def buildcfg_neededvars(d):
     needed_vars = oe.data.typed_value("BUILDCFG_NEEDEDVARS", d)
@@ -624,7 +624,7 @@ python () {
             d.appendVarFlag('do_unpack', 'depends', ' lzip-native:do_populate_sysroot')
 
         # *.xz should DEPEND on xz-native for unpacking
-        elif path.endswith('.xz'):
+        elif path.endswith('.xz') or path.endswith('.txz'):
             d.appendVarFlag('do_unpack', 'depends', ' xz-native:do_populate_sysroot')
 
         # .zip should DEPEND on unzip-native for unpacking

meta/classes/externalsrc.bbclass

@@ -188,10 +188,8 @@ def srctree_hash_files(d, srcdir=None):
     git_dir = None
 
     try:
-        # git rev-parse returns the path relative to the current working
-        # directory
         git_dir = os.path.join(s_dir,
-            subprocess.check_output(['git', 'rev-parse', '--git-dir'], cwd=s_dir).decode("utf-8").rstrip())
+            subprocess.check_output(['git', '-C', s_dir, 'rev-parse', '--git-dir']).decode("utf-8").rstrip())
     except subprocess.CalledProcessError:
         pass
 

meta/classes/goarch.bbclass

@@ -29,6 +29,7 @@ COMPATIBLE_HOST_linux-gnux32 = "null"
 COMPATIBLE_HOST_linux-muslx32 = "null"
 COMPATIBLE_HOST_powerpc = "null"
 COMPATIBLE_HOST_powerpc64 = "null"
+COMPATIBLE_HOST_mipsarchn32 = "null"
 ARM_INSTRUCTION_SET = "arm"
 TUNE_CCARGS_remove = "-march=mips32r2"
 

meta/classes/gtk-doc.bbclass

@@ -48,7 +48,7 @@ do_compile_prepend_class-target () {
 # which may then get deleted (or their dependencies) and potentially segfault
 export GIO_MODULE_DIR=${STAGING_LIBDIR}/gio/modules-dummy
 
-GIR_EXTRA_LIBS_PATH=\`find ${B} -name *.so -printf %h| tr '\n' ':'\`\$GIR_EXTRA_LIBS_PATH
+GIR_EXTRA_LIBS_PATH=\`find ${B} -name *.so -printf "%h\n"|sort|uniq| tr '\n' ':'\`\$GIR_EXTRA_LIBS_PATH
 GIR_EXTRA_LIBS_PATH=\`find ${B} -name .libs| tr '\n' ':'\`\$GIR_EXTRA_LIBS_PATH
 
 if [ -d ".libs" ]; then

meta/classes/image.bbclass

@@ -145,14 +145,18 @@ IMAGE_TYPE_wic = "image_types_wic"
 inherit ${IMAGE_TYPE_wic}
 
 python () {
+    def extraimage_getdepends(task):
+        deps = ""
+        for dep in (d.getVar('EXTRA_IMAGEDEPENDS') or "").split():
+            deps += " %s:%s" % (dep, task)
+        return deps
+
+    d.appendVarFlag('do_image', 'depends', extraimage_getdepends('do_populate_lic'))
+    d.appendVarFlag('do_image_complete', 'depends', extraimage_getdepends('do_populate_sysroot'))
+
     deps = " " + imagetypes_getdepends(d)
     d.appendVarFlag('do_rootfs', 'depends', deps)
 
-    deps = ""
-    for dep in (d.getVar('EXTRA_IMAGEDEPENDS') or "").split():
-        deps += " %s:do_populate_sysroot" % dep
-    d.appendVarFlag('do_image_complete', 'depends', deps)
-
     #process IMAGE_FEATURES, we must do this before runtime_mapping_rename
     #Check for replaces image features
     features = set(oe.data.typed_value('IMAGE_FEATURES', d))
@@ -440,6 +444,9 @@ python () {
         localdata.delVar('DATETIME')
         localdata.delVar('DATE')
         localdata.delVar('TMPDIR')
+        vardepsexclude = (d.getVarFlag('IMAGE_CMD_' + realt, 'vardepsexclude', True) or '').split()
+        for dep in vardepsexclude:
+            localdata.delVar(dep)
 
         image_cmd = localdata.getVar("IMAGE_CMD")
         vardeps.add('IMAGE_CMD_' + realt)
@@ -503,7 +510,7 @@ python () {
         d.prependVarFlag(task, 'postfuncs', ' create_symlinks')
         d.appendVarFlag(task, 'subimages', ' ' + ' '.join(subimages))
         d.appendVarFlag(task, 'vardeps', ' ' + ' '.join(vardeps))
-        d.appendVarFlag(task, 'vardepsexclude', 'DATETIME DATE')
+        d.appendVarFlag(task, 'vardepsexclude', 'DATETIME DATE ' + ' '.join(vardepsexclude))
 
         bb.debug(2, "Adding task %s before %s, after %s" % (task, 'do_image_complete', after))
         bb.build.addtask(task, 'do_image_complete', after, d)

meta/classes/image_types.bbclass

@@ -83,7 +83,11 @@ oe_mkext234fs () {
 		eval COUNT=\"$MIN_COUNT\"
 	fi
 	# Create a sparse image block
+	bbdebug 1 Executing "dd if=/dev/zero of=${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.$fstype seek=$ROOTFS_SIZE count=$COUNT bs=1024"
 	dd if=/dev/zero of=${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.$fstype seek=$ROOTFS_SIZE count=$COUNT bs=1024
+	bbdebug 1 "Actual Rootfs size:  `du -s ${IMAGE_ROOTFS}`"
+	bbdebug 1 "Actual Partion size: `ls -s ${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.$fstype`"
+	bbdebug 1 Executing "mkfs.$fstype -F $extra_imagecmd ${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.$fstype -d ${IMAGE_ROOTFS}"
 	mkfs.$fstype -F $extra_imagecmd ${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.$fstype -d ${IMAGE_ROOTFS}
 	# Error codes 0-3 indicate successfull operation of fsck (no errors or errors corrected)
 	fsck.$fstype -pvfD ${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.$fstype || [ $? -le 3 ]

meta/classes/package_ipk.bbclass

@@ -12,7 +12,7 @@ OPKGBUILDCMD ??= "opkg-build"
 
 OPKG_ARGS += "--force_postinstall --prefer-arch-to-version"
 OPKG_ARGS += "${@['', '--no-install-recommends'][d.getVar("NO_RECOMMENDATIONS") == "1"]}"
-OPKG_ARGS += "${@['', '--add-exclude ' + ' --add-exclude '.join((d.getVar('PACKAGE_EXCLUDE') or "").split())][(d.getVar("PACKAGE_EXCLUDE") or "") != ""]}"
+OPKG_ARGS += "${@['', '--add-exclude ' + ' --add-exclude '.join((d.getVar('PACKAGE_EXCLUDE') or "").split())][(d.getVar("PACKAGE_EXCLUDE") or "").strip() != ""]}"
 
 OPKGLIBDIR = "${localstatedir}/lib"
 

meta/classes/qemuboot.bbclass

@@ -85,7 +85,8 @@ python do_write_qemuboot_conf() {
 
     qemuboot = "%s/%s.qemuboot.conf" % (d.getVar('IMGDEPLOYDIR'), d.getVar('IMAGE_NAME'))
     qemuboot_link = "%s/%s.qemuboot.conf" % (d.getVar('IMGDEPLOYDIR'), d.getVar('IMAGE_LINK_NAME'))
-    topdir="%s/"%(d.getVar('TOPDIR')).replace("//","/")
+    finalpath = d.getVar("DEPLOY_DIR_IMAGE")
+    topdir = d.getVar('TOPDIR')
     cf = configparser.ConfigParser()
     cf.add_section('config_bsp')
     for k in sorted(qemuboot_vars(d)):
@@ -98,7 +99,8 @@ python do_write_qemuboot_conf() {
             val = d.getVar(k)
         # we only want to write out relative paths so that we can relocate images
         # and still run them
-        val=val.replace(topdir,"")
+        if val.startswith(topdir):
+            val = os.path.relpath(val, finalpath)
         cf.set('config_bsp', k, '%s' % val)
 
     # QB_DEFAULT_KERNEL's value of KERNEL_IMAGETYPE is the name of a symlink
@@ -108,7 +110,7 @@ python do_write_qemuboot_conf() {
     kernel = os.path.realpath(kernel_link)
     # we only want to write out relative paths so that we can relocate images
     # and still run them
-    kernel=kernel.replace(topdir,"")
+    kernel = os.path.relpath(kernel, finalpath)
     cf.set('config_bsp', 'QB_DEFAULT_KERNEL', kernel)
 
     bb.utils.mkdirhier(os.path.dirname(qemuboot))

meta/classes/testimage.bbclass

@@ -248,7 +248,7 @@ def testimage_main(d):
 
     # the robot dance
     target = OERuntimeTestContextExecutor.getTarget(
-        d.getVar("TEST_TARGET"), None, d.getVar("TEST_TARGET_IP"),
+        d.getVar("TEST_TARGET"), logger, d.getVar("TEST_TARGET_IP"),
         d.getVar("TEST_SERVER_IP"), **target_kwargs)
 
     # test context
@@ -291,11 +291,11 @@ def testimage_main(d):
 
     # Show results (if we have them)
     if not results:
-        bb.fatal('%s - FAILED - tests were interrupted during execution' % pn)
+        bb.fatal('%s - FAILED - tests were interrupted during execution' % pn, forcelog=True)
     results.logDetails()
     results.logSummary(pn)
     if not results.wasSuccessful():
-        bb.fatal('%s - FAILED - check the task log and the ssh log' % pn)
+        bb.fatal('%s - FAILED - check the task log and the ssh log' % pn, forcelog=True)
 
 def get_runtime_paths(d):
     """

meta/classes/useradd-staticids.bbclass

@@ -38,30 +38,39 @@ def update_useradd_static_config(d):
 
         return id_table
 
-    def handle_missing_id(id, type, pkg):
+    def handle_missing_id(id, type, pkg, files, var, value):
         # For backwards compatibility we accept "1" in addition to "error"
-        if d.getVar('USERADD_ERROR_DYNAMIC') == 'error' or d.getVar('USERADD_ERROR_DYNAMIC') == '1':
-            raise NotImplementedError("%s - %s: %sname %s does not have a static ID defined. Skipping it." % (d.getVar('PN'), pkg, type, id))
-        elif d.getVar('USERADD_ERROR_DYNAMIC') == 'warn':
-            bb.warn("%s - %s: %sname %s does not have a static ID defined." % (d.getVar('PN'), pkg, type, id))
+        error_dynamic = d.getVar('USERADD_ERROR_DYNAMIC')
+        msg = "%s - %s: %sname %s does not have a static ID defined." % (d.getVar('PN'), pkg, type, id)
+        if files:
+            msg += " Add %s to one of these files: %s" % (id, files)
+        else:
+            msg += " %s file(s) not found in BBPATH: %s" % (var, value)
+        if error_dynamic == 'error' or error_dynamic == '1':
+            raise NotImplementedError(msg)
+        elif error_dynamic == 'warn':
+            bb.warn(msg)
+        elif error_dynamic == 'skip':
+            raise bb.parse.SkipRecipe(msg)
+
+    # Return a list of configuration files based on either the default
+    # files/group or the contents of USERADD_GID_TABLES, resp.
+    # files/passwd for USERADD_UID_TABLES.
+    # Paths are resolved via BBPATH.
+    def get_table_list(d, var, default):
+        files = []
+        bbpath = d.getVar('BBPATH', True)
+        tables = d.getVar(var, True)
+        if not tables:
+            tables = default
+        for conf_file in tables.split():
+            files.append(bb.utils.which(bbpath, conf_file))
+        return (' '.join(files), var, default)
 
     # We parse and rewrite the useradd components
     def rewrite_useradd(params, is_pkg):
         parser = oe.useradd.build_useradd_parser()
 
-        # Return a list of configuration files based on either the default
-        # files/passwd or the contents of USERADD_UID_TABLES
-        # paths are resolved via BBPATH
-        def get_passwd_list(d):
-            str = ""
-            bbpath = d.getVar('BBPATH')
-            passwd_tables = d.getVar('USERADD_UID_TABLES')
-            if not passwd_tables:
-                passwd_tables = 'files/passwd'
-            for conf_file in passwd_tables.split():
-                str += " %s" % bb.utils.which(bbpath, conf_file)
-            return str
-
         newparams = []
         users = None
         for param in oe.useradd.split_commands(params):
@@ -82,10 +91,12 @@ def update_useradd_static_config(d):
             # all new users get the default ('*' which prevents login) until the user is
             # specifically configured by the system admin.
             if not users:
-                users = merge_files(get_passwd_list(d), 7)
+                files, table_var, table_value = get_table_list(d, 'USERADD_UID_TABLES', 'files/passwd')
+                users = merge_files(files, 7)
 
+            type = 'system user' if uaargs.system else 'normal user'
             if uaargs.LOGIN not in users:
-                handle_missing_id(uaargs.LOGIN, 'user', pkg)
+                handle_missing_id(uaargs.LOGIN, type, pkg, files, table_var, table_value)
                 newparams.append(param)
                 continue
 
@@ -143,7 +154,7 @@ def update_useradd_static_config(d):
 
             # Should be an error if a specific option is set...
             if not uaargs.uid or not uaargs.uid.isdigit() or not uaargs.gid:
-                 handle_missing_id(uaargs.LOGIN, 'user', pkg)
+                 handle_missing_id(uaargs.LOGIN, type, pkg, files, table_var, table_value)
 
             # Reconstruct the args...
             newparam  = ['', ' --defaults'][uaargs.defaults]
@@ -180,19 +191,6 @@ def update_useradd_static_config(d):
     def rewrite_groupadd(params, is_pkg):
         parser = oe.useradd.build_groupadd_parser()
 
-        # Return a list of configuration files based on either the default
-        # files/group or the contents of USERADD_GID_TABLES
-        # paths are resolved via BBPATH
-        def get_group_list(d):
-            str = ""
-            bbpath = d.getVar('BBPATH')
-            group_tables = d.getVar('USERADD_GID_TABLES')
-            if not group_tables:
-                group_tables = 'files/group'
-            for conf_file in group_tables.split():
-                str += " %s" % bb.utils.which(bbpath, conf_file)
-            return str
-
         newparams = []
         groups = None
         for param in oe.useradd.split_commands(params):
@@ -212,10 +210,12 @@ def update_useradd_static_config(d):
             # Note: similar to the passwd file, the 'password' filed is ignored
             # Note: group_members is ignored, group members must be configured with the GROUPMEMS_PARAM
             if not groups:
-                groups = merge_files(get_group_list(d), 4)
+                files, table_var, table_value = get_table_list(d, 'USERADD_GID_TABLES', 'files/group')
+                groups = merge_files(files, 4)
 
+            type = 'system group' if gaargs.system else 'normal group'
             if gaargs.GROUP not in groups:
-                handle_missing_id(gaargs.GROUP, 'group', pkg)
+                handle_missing_id(gaargs.GROUP, type, pkg, files, table_var, table_value)
                 newparams.append(param)
                 continue
 
@@ -227,7 +227,7 @@ def update_useradd_static_config(d):
                 gaargs.gid = field[2]
 
             if not gaargs.gid or not gaargs.gid.isdigit():
-                handle_missing_id(gaargs.GROUP, 'group', pkg)
+                handle_missing_id(gaargs.GROUP, type, pkg, files, table_var, table_value)
 
             # Reconstruct the args...
             newparam  = ['', ' --force'][gaargs.force]

meta/classes/useradd.bbclass

@@ -118,6 +118,7 @@ useradd_sysroot () {
 	# useradd/groupadd tools are unavailable. If there is no dependency, we assume we don't want to
 	# create users in the sysroot
 	if ! command -v useradd; then
+		bbwarn "command useradd not found!"
 		exit 0
 	fi
 

meta/conf/distro/include/maintainers.inc

@@ -44,7 +44,7 @@ RECIPE_MAINTAINER_pn-apr-util = "Hongxu Jia <hongxu.jia@windriver.com>"
 RECIPE_MAINTAINER_pn-apt = "Aníbal Limón <limon.anibal@gmail.com>"
 RECIPE_MAINTAINER_pn-apt-native = "Aníbal Limón <limon.anibal@gmail.com>"
 RECIPE_MAINTAINER_pn-argp-standalone = "Khem Raj <raj.khem@gmail.com>"
-RECIPE_MAINTAINER_pn-asciidoc = "Dengke Du <dengke.du@windriver.com>"
+RECIPE_MAINTAINER_pn-asciidoc = "Yi Zhao <yi.zhao@windriver.com>"
 RECIPE_MAINTAINER_pn-aspell = "Jose Lamego <jose.a.lamego@linux.intel.com>"
 RECIPE_MAINTAINER_pn-assimp = "Jussi Kukkonen <jussi.kukkonen@intel.com>"
 RECIPE_MAINTAINER_pn-at = "Chen Qi <Qi.Chen@windriver.com>"
@@ -56,8 +56,8 @@ RECIPE_MAINTAINER_pn-autoconf = "Robert Yang <liezhi.yang@windriver.com>"
 RECIPE_MAINTAINER_pn-autoconf-archive = "Robert Yang <liezhi.yang@windriver.com>"
 RECIPE_MAINTAINER_pn-autogen-native = "Robert Yang <liezhi.yang@windriver.com>"
 RECIPE_MAINTAINER_pn-automake = "Robert Yang <liezhi.yang@windriver.com>"
-RECIPE_MAINTAINER_pn-avahi = "Dengke Du <dengke.du@windriver.com>"
-RECIPE_MAINTAINER_pn-avahi-ui = "Dengke Du <dengke.du@windriver.com>"
+RECIPE_MAINTAINER_pn-avahi = "Yi Zhao <yi.zhao@windriver.com>"
+RECIPE_MAINTAINER_pn-avahi-ui = "Yi Zhao <yi.zhao@windriver.com>"
 RECIPE_MAINTAINER_pn-babeltrace = "Alexander Kanavin <alexander.kanavin@intel.com>"
 RECIPE_MAINTAINER_pn-base-files = "Ross Burton <ross.burton@intel.com>"
 RECIPE_MAINTAINER_pn-base-passwd = "Ross Burton <ross.burton@intel.com>"
@@ -74,7 +74,7 @@ RECIPE_MAINTAINER_pn-binutils-cross-canadian = "Khem Raj <raj.khem@gmail.com>"
 RECIPE_MAINTAINER_pn-binutils-crosssdk = "Khem Raj <raj.khem@gmail.com>"
 RECIPE_MAINTAINER_pn-bison = "Chen Qi <Qi.Chen@windriver.com>"
 RECIPE_MAINTAINER_pn-bjam-native = "Alexander Kanavin <alexander.kanavin@intel.com>"
-RECIPE_MAINTAINER_pn-blktool = "Dengke Du <dengke.du@windriver.com>"
+RECIPE_MAINTAINER_pn-blktool = "Yi Zhao <yi.zhao@windriver.com>"
 RECIPE_MAINTAINER_pn-blktrace = "Alexander Kanavin <alexander.kanavin@intel.com>"
 RECIPE_MAINTAINER_pn-bluez5 = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-bmap-tools = "Ed Bartosh <ed.bartosh@linux.intel.com>"
@@ -95,10 +95,10 @@ RECIPE_MAINTAINER_pn-cairo = "Jussi Kukkonen <jussi.kukkonen@intel.com>"
 RECIPE_MAINTAINER_pn-calibrateproto = "Armin Kuster <akuster@mvista.com>"
 RECIPE_MAINTAINER_pn-cantarell-fonts = "Alexander Kanavin <alexander.kanavin@intel.com>"
 RECIPE_MAINTAINER_pn-ccache = "Robert Yang <liezhi.yang@windriver.com>"
-RECIPE_MAINTAINER_pn-cdrtools-native = "Dengke Du <dengke.du@windriver.com>"
-RECIPE_MAINTAINER_pn-chkconfig = "Dengke Du <dengke.du@windriver.com>"
-RECIPE_MAINTAINER_pn-chkconfig-alternatives-native = "Dengke Du <dengke.du@windriver.com>"
-RECIPE_MAINTAINER_pn-chrpath = "Dengke Du <dengke.du@windriver.com>"
+RECIPE_MAINTAINER_pn-cdrtools-native = "Yi Zhao <yi.zhao@windriver.com>"
+RECIPE_MAINTAINER_pn-chkconfig = "Yi Zhao <yi.zhao@windriver.com>"
+RECIPE_MAINTAINER_pn-chkconfig-alternatives-native = "Yi Zhao <yi.zhao@windriver.com>"
+RECIPE_MAINTAINER_pn-chrpath = "Yi Zhao <yi.zhao@windriver.com>"
 RECIPE_MAINTAINER_pn-clutter-1.0 = "Jussi Kukkonen <jussi.kukkonen@intel.com>"
 RECIPE_MAINTAINER_pn-clutter-gst-3.0 = "Jussi Kukkonen <jussi.kukkonen@intel.com>"
 RECIPE_MAINTAINER_pn-clutter-gtk-1.0 = "Jussi Kukkonen <jussi.kukkonen@intel.com>"
@@ -139,17 +139,17 @@ RECIPE_MAINTAINER_pn-diffutils = "Chen Qi <Qi.Chen@windriver.com>"
 RECIPE_MAINTAINER_pn-directfb = "Hongxu Jia <hongxu.jia@windriver.com>"
 RECIPE_MAINTAINER_pn-directfb-examples = "Hongxu Jia <hongxu.jia@windriver.com>"
 RECIPE_MAINTAINER_pn-distcc = "Hongxu Jia <hongxu.jia@windriver.com>"
-RECIPE_MAINTAINER_pn-distcc-config = "Dengke Du <dengke.du@windriver.com>"
+RECIPE_MAINTAINER_pn-distcc-config = "Yi Zhao <yi.zhao@windriver.com>"
 RECIPE_MAINTAINER_pn-dmidecode = "Alexander Kanavin <alexander.kanavin@intel.com>"
 RECIPE_MAINTAINER_pn-dmxproto = "Armin Kuster <akuster@mvista.com>"
 RECIPE_MAINTAINER_pn-dnf = "Alexander Kanavin <alexander.kanavin@intel.com>"
-RECIPE_MAINTAINER_pn-docbook-xml-dtd4 = "Dengke Du <dengke.du@windriver.com>"
-RECIPE_MAINTAINER_pn-docbook-xsl-stylesheets = "Dengke Du <dengke.du@windriver.com>"
-RECIPE_MAINTAINER_pn-dosfstools = "Dengke Du <dengke.du@windriver.com>"
+RECIPE_MAINTAINER_pn-docbook-xml-dtd4 = "Yi Zhao <yi.zhao@windriver.com>"
+RECIPE_MAINTAINER_pn-docbook-xsl-stylesheets = "Yi Zhao <yi.zhao@windriver.com>"
+RECIPE_MAINTAINER_pn-dosfstools = "Yi Zhao <yi.zhao@windriver.com>"
 RECIPE_MAINTAINER_pn-dpkg = "Aníbal Limón <limon.anibal@gmail.com>"
 RECIPE_MAINTAINER_pn-dri2proto = "Armin Kuster <akuster@mvista.com>"
 RECIPE_MAINTAINER_pn-dri3proto = "Armin Kuster <akuster@mvista.com>"
-RECIPE_MAINTAINER_pn-dropbear = "Dengke Du <dengke.du@windriver.com>"
+RECIPE_MAINTAINER_pn-dropbear = "Yi Zhao <yi.zhao@windriver.com>"
 RECIPE_MAINTAINER_pn-dtc = "Alexander Kanavin <alexander.kanavin@intel.com>"
 RECIPE_MAINTAINER_pn-e2fsprogs = "Robert Yang <liezhi.yang@windriver.com>"
 RECIPE_MAINTAINER_pn-ed = "Alexander Kanavin <alexander.kanavin@intel.com>"
@@ -164,7 +164,7 @@ RECIPE_MAINTAINER_pn-encodings = "Armin Kuster <akuster@mvista.com>"
 RECIPE_MAINTAINER_pn-epiphany = "Alexander Kanavin <alexander.kanavin@intel.com>"
 RECIPE_MAINTAINER_pn-ethtool = "Changhyeok Bae <changhyeok.bae@lge.com>"
 RECIPE_MAINTAINER_pn-eudev = "Alejandro Hernandez <alejandro.hernandez@linux.intel.com>"
-RECIPE_MAINTAINER_pn-expat = "Dengke Du <dengke.du@windriver.com>"
+RECIPE_MAINTAINER_pn-expat = "Yi Zhao <yi.zhao@windriver.com>"
 RECIPE_MAINTAINER_pn-expect = "Alexander Kanavin <alexander.kanavin@intel.com>"
 RECIPE_MAINTAINER_pn-ffmpeg = "Alexander Kanavin <alexander.kanavin@intel.com>"
 RECIPE_MAINTAINER_pn-file = "Robert Yang <liezhi.yang@windriver.com>"
@@ -224,6 +224,7 @@ RECIPE_MAINTAINER_pn-gnupg = "Hongxu Jia <hongxu.jia@windriver.com>"
 RECIPE_MAINTAINER_pn-gnutls = "Armin Kuster <akuster@mvista.com>"
 RECIPE_MAINTAINER_pn-go = "Khem Raj <raj.khem@gmail.com>"
 RECIPE_MAINTAINER_pn-go-cross = "Khem Raj <raj.khem@gmail.com>"
+RECIPE_MAINTAINER_pn-go-dep = "Otavio Salvador <otavio.salvador@ossystems.com.br>"
 RECIPE_MAINTAINER_pn-go-helloworld = "Khem Raj <raj.khem@gmail.com>"
 RECIPE_MAINTAINER_pn-go-native = "Khem Raj <raj.khem@gmail.com>"
 RECIPE_MAINTAINER_pn-gobject-introspection = "Alexander Kanavin <alexander.kanavin@intel.com>"
@@ -287,8 +288,8 @@ RECIPE_MAINTAINER_pn-irda-utils = "Changhyeok Bae <changhyeok.bae@lge.com>"
 RECIPE_MAINTAINER_pn-iso-codes = "Alexander Kanavin <alexander.kanavin@intel.com>"
 RECIPE_MAINTAINER_pn-iw = "Changhyeok Bae <changhyeok.bae@lge.com>"
 RECIPE_MAINTAINER_pn-libjpeg-turbo = "Maxin B. John <maxin.john@intel.com>"
-RECIPE_MAINTAINER_pn-json-c = "Dengke Du <dengke.du@windriver.com>"
-RECIPE_MAINTAINER_pn-json-glib = "Dengke Du <dengke.du@windriver.com>"
+RECIPE_MAINTAINER_pn-json-c = "Yi Zhao <yi.zhao@windriver.com>"
+RECIPE_MAINTAINER_pn-json-glib = "Yi Zhao <yi.zhao@windriver.com>"
 RECIPE_MAINTAINER_pn-kbd = "Alexander Kanavin <alexander.kanavin@intel.com>"
 RECIPE_MAINTAINER_pn-kbproto = "Armin Kuster <akuster@mvista.com>"
 RECIPE_MAINTAINER_pn-kconfig-frontends = "Alexander Kanavin <alexander.kanavin@intel.com>"
@@ -358,6 +359,7 @@ RECIPE_MAINTAINER_pn-libinput = "Jussi Kukkonen <jussi.kukkonen@intel.com>"
 RECIPE_MAINTAINER_pn-libjson = "Alexander Kanavin <alexander.kanavin@intel.com>"
 RECIPE_MAINTAINER_pn-libksba = "Alexander Kanavin <alexander.kanavin@intel.com>"
 RECIPE_MAINTAINER_pn-libmatchbox = "Jussi Kukkonen <jussi.kukkonen@intel.com>"
+RECIPE_MAINTAINER_pn-libmnl = "Khem Raj <raj.khem@gmail.com>"
 RECIPE_MAINTAINER_pn-libmpc = "Khem Raj <raj.khem@gmail.com>"
 RECIPE_MAINTAINER_pn-libnewt = "Hongxu Jia <hongxu.jia@windriver.com>"
 RECIPE_MAINTAINER_pn-libnewt-python = "Hongxu Jia <hongxu.jia@windriver.com>"
@@ -463,9 +465,9 @@ RECIPE_MAINTAINER_pn-logrotate = "Robert Yang <liezhi.yang@windriver.com>"
 RECIPE_MAINTAINER_pn-lrzsz = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-lsb = "Hongxu Jia <hongxu.jia@windriver.com>"
 RECIPE_MAINTAINER_pn-lsbinitscripts = "Ross Burton <ross.burton@intel.com>"
-RECIPE_MAINTAINER_pn-lsbtest = "Dengke Du <dengke.du@windriver.com>"
+RECIPE_MAINTAINER_pn-lsbtest = "Yi Zhao <yi.zhao@windriver.com>"
 RECIPE_MAINTAINER_pn-lsof = "Maxin B. John <maxin.john@intel.com>"
-RECIPE_MAINTAINER_pn-ltp = "Dengke Du <dengke.du@windriver.com>"
+RECIPE_MAINTAINER_pn-ltp = "Yi Zhao <yi.zhao@windriver.com>"
 RECIPE_MAINTAINER_pn-lttng-modules = "Richard Purdie <richard.purdie@linuxfoundation.org>"
 RECIPE_MAINTAINER_pn-lttng-tools = "Richard Purdie <richard.purdie@linuxfoundation.org>"
 RECIPE_MAINTAINER_pn-lttng-ust = "Richard Purdie <richard.purdie@linuxfoundation.org>"
@@ -581,7 +583,7 @@ RECIPE_MAINTAINER_pn-pm-utils = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-pointercal = "Alexander Kanavin <alexander.kanavin@intel.com>"
 RECIPE_MAINTAINER_pn-pointercal-xinput = "Alexander Kanavin <alexander.kanavin@intel.com>"
 RECIPE_MAINTAINER_pn-pong-clock = "Jussi Kukkonen <jussi.kukkonen@intel.com>"
-RECIPE_MAINTAINER_pn-popt = "Dengke Du <dengke.du@windriver.com>"
+RECIPE_MAINTAINER_pn-popt = "Yi Zhao <yi.zhao@windriver.com>"
 RECIPE_MAINTAINER_pn-portmap = "Robert Yang <liezhi.yang@windriver.com>"
 RECIPE_MAINTAINER_pn-powertop = "Alexander Kanavin <alexander.kanavin@intel.com>"
 RECIPE_MAINTAINER_pn-ppp = "Hongxu Jia <hongxu.jia@windriver.com>"
@@ -591,7 +593,7 @@ RECIPE_MAINTAINER_pn-presentproto = "Armin Kuster <akuster@mvista.com>"
 RECIPE_MAINTAINER_pn-procps = "Alexander Kanavin <alexander.kanavin@intel.com>"
 RECIPE_MAINTAINER_pn-pseudo = "Mark Hatle <mark.hatle@windriver.com>"
 RECIPE_MAINTAINER_pn-psmisc = "Alexander Kanavin <alexander.kanavin@intel.com>"
-RECIPE_MAINTAINER_pn-psplash = "Dengke Du <dengke.du@windriver.com>"
+RECIPE_MAINTAINER_pn-psplash = "Yi Zhao <yi.zhao@windriver.com>"
 RECIPE_MAINTAINER_pn-ptest-runner = "Leonardo Sandoval <leonardo.sandoval.gonzalez@linux.intel.com>"
 RECIPE_MAINTAINER_pn-pulseaudio = "Tanu Kaskinen <tanuk@iki.fi>"
 RECIPE_MAINTAINER_pn-pulseaudio-client-conf-sato = "Tanu Kaskinen <tanuk@iki.fi>"
@@ -819,7 +821,7 @@ RECIPE_MAINTAINER_pn-xvideo-tests = "Maxin B. John <maxin.john@intel.com>"
 RECIPE_MAINTAINER_pn-xvinfo = "Armin Kuster <akuster@mvista.com>"
 RECIPE_MAINTAINER_pn-xwininfo = "Armin Kuster <akuster@mvista.com>"
 RECIPE_MAINTAINER_pn-xz = "Denys Dmytriyenko <denys@ti.com>"
-RECIPE_MAINTAINER_pn-yasm = "Dengke Du <dengke.du@windriver.com>"
+RECIPE_MAINTAINER_pn-yasm = "Yi Zhao <yi.zhao@windriver.com>"
 RECIPE_MAINTAINER_pn-zip = "Denys Dmytriyenko <denys@ti.com>"
 RECIPE_MAINTAINER_pn-zisofs-tools-native = "Alexander Kanavin <alexander.kanavin@intel.com>"
 RECIPE_MAINTAINER_pn-zlib = "Denys Dmytriyenko <denys@ti.com>"

meta/conf/distro/include/tclibc-musl.inc

@@ -14,6 +14,8 @@ PREFERRED_PROVIDER_virtual/libintl ?= "musl"
 PREFERRED_PROVIDER_virtual/nativesdk-libintl ?= "nativesdk-glibc"
 PREFERRED_PROVIDER_virtual/nativesdk-libiconv ?= "nativesdk-glibc"
 
+DISTRO_FEATURES_BACKFILL_CONSIDERED += "ldconfig"
+
 #USE_NLS ?= "no"
 
 CXXFLAGS += "-fvisibility-inlines-hidden"

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

@@ -5,8 +5,8 @@
 TUNEVALID[vfp] = "Enable Vector Floating Point (vfp) unit."
 TUNE_CCARGS_MFPU .= "${@bb.utils.contains('TUNE_FEATURES', 'vfp', ' vfp', '', d)}"
 
-TUNE_CCARGS  .= "${@ (' -mfpu=%s ' % d.getVar('TUNE_CCARGS_MFPU').split()[-1]) if (d.getVar('TUNE_CCARGS_MFPU') != '') else ''}"
-ARMPKGSFX_FPU = "${@ ('-%s'        % d.getVar('TUNE_CCARGS_MFPU').split()[-1].replace('vfpv3-d16', 'vfpv3d16')) if (d.getVar('TUNE_CCARGS_MFPU') != '') else ''}"
+TUNE_CCARGS  .= "${@ (' -mfpu=%s' % d.getVar('TUNE_CCARGS_MFPU').split()[-1]) if (d.getVar('TUNE_CCARGS_MFPU') != '') else ''}"
+ARMPKGSFX_FPU = "${@ ('-%s'       % d.getVar('TUNE_CCARGS_MFPU').split()[-1].replace('vfpv3-d16', 'vfpv3d16')) if (d.getVar('TUNE_CCARGS_MFPU') != '') else ''}"
 
 TUNEVALID[callconvention-hard] = "Enable EABI hard float call convention, requires VFP."
 TUNE_CCARGS_MFLOAT = "${@ bb.utils.contains('TUNE_FEATURES', 'callconvention-hard', 'hard', 'softfp', d) if (d.getVar('TUNE_CCARGS_MFPU') != '') else '' }"

meta/conf/machine/include/qemu.inc

@@ -25,6 +25,7 @@ EXTRA_IMAGEDEPENDS += "qemu-native qemu-helper-native"
 
 # Provide the nfs server kernel module for all qemu images
 KERNEL_FEATURES_append_pn-linux-yocto = " features/nfsd/nfsd-enable.scc"
+KERNEL_FEATURES_append_pn-linux-yocto-rt = " features/nfsd/nfsd-enable.scc"
 
 MACHINE_EXTRA_RRECOMMENDS += "rng-tools"
 

meta/lib/oe/recipeutils.py

@@ -188,6 +188,11 @@ def patch_recipe_lines(fromlines, values, trailing_newline=True):
             for wrapline in wrapped[:-1]:
                 addlines.append('%s \\%s' % (wrapline, newline))
             addlines.append('%s%s' % (wrapped[-1], newline))
+
+        # Split on newlines - this isn't strictly necessary if you are only
+        # going to write the output to disk, but if you want to compare it
+        # (as patch_recipe_file() will do if patch=True) then it's important.
+        addlines = [line for l in addlines for line in l.splitlines(True)]
         if rewindcomments:
             # Ensure we insert the lines before any leading comments
             # (that we'd want to ensure remain leading the next value)
@@ -801,7 +806,7 @@ def bbappend_recipe(rd, destlayerdir, srcfiles, install=None, wildcardver=False,
 
 def find_layerdir(fn):
     """ Figure out the path to the base of the layer containing a file (e.g. a recipe)"""
-    pth = fn
+    pth = os.path.abspath(fn)
     layerdir = ''
     while pth:
         if os.path.exists(os.path.join(pth, 'conf', 'layer.conf')):

meta/lib/oe/sstatesig.py

@@ -320,7 +320,7 @@ def find_siginfo(pn, taskname, taskhashlist, d):
 
     if not taskhashlist or (len(filedates) < 2 and not foundall):
         # That didn't work, look in sstate-cache
-        hashes = taskhashlist or ['*']
+        hashes = taskhashlist or ['?' * 32]
         localdata = bb.data.createCopy(d)
         for hashval in hashes:
             localdata.setVar('PACKAGE_ARCH', '*')

meta/lib/oe/terminal.py

@@ -224,7 +224,7 @@ def spawn(name, sh_cmd, title=None, env=None, d=None):
     import time
     pidfile = tempfile.NamedTemporaryFile(delete = False).name
     try:
-        sh_cmd = "oe-gnome-terminal-phonehome " + pidfile + " " + sh_cmd
+        sh_cmd = bb.utils.which(os.getenv('PATH'), "oe-gnome-terminal-phonehome") + " " + pidfile + " " + sh_cmd
         pipe = terminal(sh_cmd, title, env, d)
         output = pipe.communicate()[0]
         if output:

meta/lib/oeqa/controllers/masterimage.py

@@ -108,7 +108,7 @@ class MasterImageHardwareTarget(oeqa.targetcontrol.BaseTarget, metaclass=ABCMeta
             time.sleep(10)
             self.power_ctl("cycle")
         else:
-            status, output = conn.run("reboot")
+            status, output = conn.run("sync; { sleep 1; reboot; } > /dev/null &")
             if status != 0:
                 bb.error("Failed rebooting target and no power control command defined. You need to manually reset the device.\n%s" % output)
 
@@ -143,7 +143,7 @@ class MasterImageHardwareTarget(oeqa.targetcontrol.BaseTarget, metaclass=ABCMeta
     def _deploy(self):
         pass
 
-    def start(self, params=None):
+    def start(self, extra_bootparams=None):
         bb.plain("%s - boot test image on target" % self.pn)
         self._start()
         # set the ssh object for the target/test image
@@ -156,7 +156,7 @@ class MasterImageHardwareTarget(oeqa.targetcontrol.BaseTarget, metaclass=ABCMeta
 
     def stop(self):
         bb.plain("%s - reboot/powercycle target" % self.pn)
-        self.power_cycle(self.connection)
+        self.power_cycle(self.master)
 
 
 class SystemdbootTarget(MasterImageHardwareTarget):

meta/lib/oeqa/core/loader.py

@@ -2,6 +2,7 @@
 # Released under the MIT license (see COPYING.MIT)
 
 import os
+import re
 import sys
 import unittest
 import inspect
@@ -39,42 +40,19 @@ def _built_modules_dict(modules):
     if modules == None:
         return modules_dict
 
-    for m in modules:
-        ms = m.split('.')
+    for module in modules:
+        # Assumption: package and module names do not contain upper case
+        # characters, whereas class names do
+        m = re.match(r'^([^A-Z]+)(?:\.([A-Z][^.]*)(?:\.([^.]+))?)?$', module)
 
-        if len(ms) == 1:
-            module_name = ms[0]
-            if not module_name in modules_dict:
-                modules_dict[module_name] = {}
-        elif len(ms) == 2:
-            module_name = ms[0]
-            class_name = ms[1]
-            if not module_name in modules_dict:
-                modules_dict[module_name] = {}
-            if not class_name in modules_dict[module_name]:
-                modules_dict[module_name][class_name] = []
-        elif len(ms) == 3:
-            module_name = ms[0]
-            class_name = ms[1]
-            test_name = ms[2]
+        module_name, class_name, test_name = m.groups()
 
-            if not module_name in modules_dict:
-                modules_dict[module_name] = {}
-            if not class_name in modules_dict[module_name]:
-                modules_dict[module_name][class_name] = []
-            if not test_name in modules_dict[module_name][class_name]:
-                modules_dict[module_name][class_name].append(test_name)
-        elif len(ms) >= 4:
-            module_name = '.'.join(ms[0:-2])
-            class_name = ms[-2]
-            test_name = ms[-1]
-
-            if not module_name in modules_dict:
-                modules_dict[module_name] = {}
-            if not class_name in modules_dict[module_name]:
-                modules_dict[module_name][class_name] = []
-            if not test_name in modules_dict[module_name][class_name]:
-                modules_dict[module_name][class_name].append(test_name)
+        if module_name and module_name not in modules_dict:
+            modules_dict[module_name] = {}
+        if class_name and class_name not in modules_dict[module_name]:
+            modules_dict[module_name][class_name] = []
+        if test_name and test_name not in modules_dict[module_name][class_name]:
+            modules_dict[module_name][class_name].append(test_name)
 
     return modules_dict
 

meta/lib/oeqa/core/runner.py

@@ -45,6 +45,14 @@ class OETestResult(_TestResult):
         self.tc = tc
         self._tc_map_results()
 
+    def startTest(self, test):
+        # Allow us to trigger the testcase buffer mode on a per test basis
+        # so stdout/stderr are only printed upon failure. Enables debugging
+        # but clean output
+        if hasattr(test, "buffer"):
+            self.buffer = test.buffer
+        super(OETestResult, self).startTest(test)
+
     def _tc_map_results(self):
         self.tc._results['failures'] = self.failures
         self.tc._results['errors'] = self.errors

meta/lib/oeqa/core/target/qemu.py

@@ -31,7 +31,7 @@ class OEQemuTarget(OESSHTarget):
                                  deploy_dir_image=dir_image, display=display,
                                  logfile=bootlog, boottime=boottime,
                                  use_kvm=kvm, dump_dir=dump_dir,
-                                 dump_host_cmds=dump_host_cmds)
+                                 dump_host_cmds=dump_host_cmds, logger=logger)
 
     def start(self, params=None, extra_bootparams=None):
         if self.runner.start(params, extra_bootparams=extra_bootparams):

meta/lib/oeqa/core/target/ssh.py

@@ -83,7 +83,7 @@ class OESSHTarget(OETarget):
             processTimeout = self.timeout
 
         status, output = self._run(sshCmd, processTimeout, True)
-        self.logger.info('\nCommand: %s\nOutput:  %s\n' % (command, output))
+        self.logger.debug('Command: %s\nOutput:  %s\n' % (command, output))
         return (status, output)
 
     def copyTo(self, localSrc, remoteDst):

meta/lib/oeqa/selftest/cases/devtool.py

@@ -13,6 +13,8 @@ from oeqa.core.decorator.oeid import OETestID
 
 class DevtoolBase(OESelftestTestCase):
 
+    buffer = True
+
     def _test_recipe_contents(self, recipefile, checkvars, checkinherits):
         with open(recipefile, 'r') as f:
             invar = None

meta/lib/oeqa/selftest/cases/imagefeatures.py

@@ -10,6 +10,8 @@ class ImageFeatures(OESelftestTestCase):
     test_user = 'tester'
     root_user = 'root'
 
+    buffer = True
+
     @OETestID(1107)
     def test_non_root_user_can_connect_via_ssh_without_password(self):
         """
@@ -226,3 +228,13 @@ class ImageFeatures(OESelftestTestCase):
             # check if result image is in deploy directory
             self.assertTrue(os.path.exists(image_path),
                             "%s image %s doesn't exist" % (itype, image_path))
+
+    def test_useradd_static(self):
+        config = """
+USERADDEXTENSION = "useradd-staticids"
+USERADD_ERROR_DYNAMIC = "skip"
+USERADD_UID_TABLES += "files/static-passwd"
+USERADD_GID_TABLES += "files/static-group"
+"""
+        self.write_config(config)
+        bitbake("core-image-base")

meta/lib/oeqa/selftest/cases/runqemu.py

@@ -3,7 +3,6 @@
 #
 
 import re
-import logging
 
 from oeqa.selftest.case import OESelftestTestCase
 from oeqa.utils.commands import bitbake, runqemu, get_bb_var
@@ -14,6 +13,8 @@ class RunqemuTests(OESelftestTestCase):
 
     image_is_ready = False
     deploy_dir_image = ''
+    # We only want to print runqemu stdout/stderr if there is a test case failure
+    buffer = True
 
     def setUpLocal(self):
         super(RunqemuTests, self).setUpLocal()
@@ -22,10 +23,6 @@ class RunqemuTests(OESelftestTestCase):
         self.fstypes = "ext4 iso hddimg wic.vmdk wic.qcow2 wic.vdi"
         self.cmd_common = "runqemu nographic"
 
-        # Avoid emit the same record multiple times.
-        mainlogger = logging.getLogger("BitBake.Main")
-        mainlogger.propagate = False
-
         self.write_config(
 """
 MACHINE = "%s"

meta/lib/oeqa/selftest/cases/runtime_test.py

@@ -1,5 +1,6 @@
 from oeqa.selftest.case import OESelftestTestCase
 from oeqa.utils.commands import runCmd, bitbake, get_bb_var, get_bb_vars, runqemu
+from oeqa.utils.sshcontrol import SSHControl
 from oeqa.core.decorator.oeid import OETestID
 import os
 import re
@@ -243,7 +244,7 @@ postinst-delayed-t \
                 with self.subTest(init_manager=init_manager, package_class=classes):
                     features = 'MACHINE = "qemux86"\n'
                     features += 'CORE_IMAGE_EXTRA_INSTALL += "%s %s "\n'% (rootfs_pkg, boot_pkg)
-                    features += 'IMAGE_FEATURES += "ssh-server-openssh"\n'
+                    features += 'IMAGE_FEATURES += "package-management empty-root-password"\n'
                     features += 'PACKAGE_CLASSES = "%s"\n' % classes
                     if init_manager == "systemd":
                         features += 'DISTRO_FEATURES_append = " systemd"\n'
@@ -262,6 +263,5 @@ postinst-delayed-t \
 
                     testcommand = 'ls /etc/' + fileboot_name
                     with runqemu('core-image-minimal') as qemu:
-                        sshargs = '-o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no'
-                        result = runCmd('ssh %s root@%s %s' % (sshargs, qemu.ip, testcommand))
-                        self.assertEqual(result.status, 0, 'File %s was not created at firts boot'% fileboot_name)
+                        status, output = qemu.run_serial("-f /etc/" + fileboot_name)
+                        self.assertEqual(status, 0, 'File %s was not created at first boot (%s)' % (fileboot_name, output))

meta/lib/oeqa/targetcontrol.py

@@ -18,44 +18,18 @@ from oeqa.utils.dump import TargetDumper
 from oeqa.controllers.testtargetloader import TestTargetLoader
 from abc import ABCMeta, abstractmethod
 
-logger = logging.getLogger('BitBake.QemuRunner')
-
-def get_target_controller(d):
-    testtarget = d.getVar("TEST_TARGET")
-    # old, simple names
-    if testtarget == "qemu":
-        return QemuTarget(d)
-    elif testtarget == "simpleremote":
-        return SimpleRemoteTarget(d)
-    else:
-        # use the class name
-        try:
-            # is it a core class defined here?
-            controller = getattr(sys.modules[__name__], testtarget)
-        except AttributeError:
-            # nope, perhaps a layer defined one
-            try:
-                bbpath = d.getVar("BBPATH").split(':')
-                testtargetloader = TestTargetLoader()
-                controller = testtargetloader.get_controller_module(testtarget, bbpath)
-            except ImportError as e:
-                bb.fatal("Failed to import {0} from available controller modules:\n{1}".format(testtarget,traceback.format_exc()))
-            except AttributeError as e:
-                bb.fatal("Invalid TEST_TARGET - " + str(e))
-        return controller(d)
-
-
 class BaseTarget(object, metaclass=ABCMeta):
 
     supported_image_fstypes = []
 
-    def __init__(self, d):
+    def __init__(self, d, logger):
         self.connection = None
         self.ip = None
         self.server_ip = None
         self.datetime = d.getVar('DATETIME')
         self.testdir = d.getVar("TEST_LOG_DIR")
         self.pn = d.getVar("PN")
+        self.logger = logger
 
     @abstractmethod
     def deploy(self):
@@ -65,7 +39,7 @@ class BaseTarget(object, metaclass=ABCMeta):
         if os.path.islink(sshloglink):
             os.unlink(sshloglink)
         os.symlink(self.sshlog, sshloglink)
-        logger.info("SSH log file: %s" %  self.sshlog)
+        self.logger.info("SSH log file: %s" %  self.sshlog)
 
     @abstractmethod
     def start(self, params=None, ssh=True, extra_bootparams=None):
@@ -115,9 +89,9 @@ class QemuTarget(BaseTarget):
 
     supported_image_fstypes = ['ext3', 'ext4', 'cpio.gz', 'wic']
 
-    def __init__(self, d, image_fstype=None):
+    def __init__(self, d, logger, image_fstype=None):
 
-        super(QemuTarget, self).__init__(d)
+        super(QemuTarget, self).__init__(d, logger)
 
         self.rootfs = ''
         self.kernel = ''
@@ -145,7 +119,7 @@ class QemuTarget(BaseTarget):
         self.qemurunnerlog = os.path.join(self.testdir, 'qemurunner_log.%s' % self.datetime)
         loggerhandler = logging.FileHandler(self.qemurunnerlog)
         loggerhandler.setFormatter(logging.Formatter("%(levelname)s: %(message)s"))
-        logger.addHandler(loggerhandler)
+        self.logger.addHandler(loggerhandler)
         oe.path.symlink(os.path.basename(self.qemurunnerlog), os.path.join(self.testdir, 'qemurunner_log'), force=True)
 
         if d.getVar("DISTRO") == "poky-tiny":
@@ -156,7 +130,8 @@ class QemuTarget(BaseTarget):
                             display = d.getVar("BB_ORIGENV", False).getVar("DISPLAY"),
                             logfile = self.qemulog,
                             kernel = self.kernel,
-                            boottime = int(d.getVar("TEST_QEMUBOOT_TIMEOUT")))
+                            boottime = int(d.getVar("TEST_QEMUBOOT_TIMEOUT")),
+                            logger = logger)
         else:
             self.runner = QemuRunner(machine=d.getVar("MACHINE"),
                             rootfs=self.rootfs,
@@ -167,7 +142,8 @@ class QemuTarget(BaseTarget):
                             boottime = int(d.getVar("TEST_QEMUBOOT_TIMEOUT")),
                             use_kvm = use_kvm,
                             dump_dir = dump_dir,
-                            dump_host_cmds = d.getVar("testimage_dump_host"))
+                            dump_host_cmds = d.getVar("testimage_dump_host"),
+                            logger = logger)
 
         self.target_dumper = TargetDumper(dump_target_cmds, dump_dir, self.runner)
 
@@ -179,8 +155,8 @@ class QemuTarget(BaseTarget):
             os.unlink(qemuloglink)
         os.symlink(self.qemulog, qemuloglink)
 
-        logger.info("rootfs file: %s" %  self.rootfs)
-        logger.info("Qemu log file: %s" % self.qemulog)
+        self.logger.info("rootfs file: %s" %  self.rootfs)
+        self.logger.info("Qemu log file: %s" % self.qemulog)
         super(QemuTarget, self).deploy()
 
     def start(self, params=None, ssh=True, extra_bootparams='', runqemuparams='', launch_cmd='', discard_writes=True):
@@ -232,14 +208,14 @@ class SimpleRemoteTarget(BaseTarget):
             self.port = addr.split(":")[1]
         except IndexError:
             self.port = None
-        logger.info("Target IP: %s" % self.ip)
+        self.logger.info("Target IP: %s" % self.ip)
         self.server_ip = d.getVar("TEST_SERVER_IP")
         if not self.server_ip:
             try:
                 self.server_ip = subprocess.check_output(['ip', 'route', 'get', self.ip ]).split("\n")[0].split()[-1]
             except Exception as e:
                 bb.fatal("Failed to determine the host IP address (alternatively you can set TEST_SERVER_IP with the IP address of this machine): %s" % e)
-        logger.info("Server IP: %s" % self.server_ip)
+        self.logger.info("Server IP: %s" % self.server_ip)
 
     def deploy(self):
         super(SimpleRemoteTarget, self).deploy()

meta/lib/oeqa/utils/commands.py

@@ -296,6 +296,12 @@ def runqemu(pn, ssh=True, runqemuparams='', image_fstype=None, launch_cmd=None,
     import bb.tinfoil
     import bb.build
 
+    # Need a non-'BitBake' logger to capture the runner output
+    targetlogger = logging.getLogger('TargetRunner')
+    targetlogger.setLevel(logging.DEBUG)
+    handler = logging.StreamHandler(sys.stdout)
+    targetlogger.addHandler(handler)
+
     tinfoil = bb.tinfoil.Tinfoil()
     tinfoil.prepare(config_only=False, quiet=True)
     try:
@@ -313,31 +319,15 @@ def runqemu(pn, ssh=True, runqemuparams='', image_fstype=None, launch_cmd=None,
         for key, value in overrides.items():
             recipedata.setVar(key, value)
 
-        # The QemuRunner log is saved out, but we need to ensure it is at the right
-        # log level (and then ensure that since it's a child of the BitBake logger,
-        # we disable propagation so we don't then see the log events on the console)
-        logger = logging.getLogger('BitBake.QemuRunner')
-        logger.setLevel(logging.DEBUG)
-        logger.propagate = False
         logdir = recipedata.getVar("TEST_LOG_DIR")
 
-        qemu = oeqa.targetcontrol.QemuTarget(recipedata, image_fstype)
+        qemu = oeqa.targetcontrol.QemuTarget(recipedata, targetlogger, image_fstype)
     finally:
         # We need to shut down tinfoil early here in case we actually want
         # to run tinfoil-using utilities with the running QEMU instance.
         # Luckily QemuTarget doesn't need it after the constructor.
         tinfoil.shutdown()
 
-    # Setup bitbake logger as console handler is removed by tinfoil.shutdown
-    bblogger = logging.getLogger('BitBake')
-    bblogger.setLevel(logging.INFO)
-    console = logging.StreamHandler(sys.stdout)
-    bbformat = bb.msg.BBLogFormatter("%(levelname)s: %(message)s")
-    if sys.stdout.isatty():
-        bbformat.enable_color()
-    console.setFormatter(bbformat)
-    bblogger.addHandler(console)
-
     try:
         qemu.deploy()
         try:
@@ -352,6 +342,7 @@ def runqemu(pn, ssh=True, runqemuparams='', image_fstype=None, launch_cmd=None,
             qemu.stop()
         except:
             pass
+    targetlogger.removeHandler(handler)
 
 def updateEnv(env_file):
     """

meta/lib/oeqa/utils/qemurunner.py

@@ -28,7 +28,7 @@ re_control_char = re.compile('[%s]' % re.escape("".join(control_chars)))
 
 class QemuRunner:
 
-    def __init__(self, machine, rootfs, display, tmpdir, deploy_dir_image, logfile, boottime, dump_dir, dump_host_cmds, use_kvm):
+    def __init__(self, machine, rootfs, display, tmpdir, deploy_dir_image, logfile, boottime, dump_dir, dump_host_cmds, use_kvm, logger):
 
         # Popen object for runqemu
         self.runqemu = None
@@ -57,8 +57,7 @@ class QemuRunner:
         self.qemu_pidfile = 'pidfile_'+str(os.getpid())
         self.host_dumper = HostDumper(dump_host_cmds, dump_dir)
 
-        self.logger = logging.getLogger("BitBake.QemuRunner")
-        self.logger.addHandler(logging.StreamHandler(sys.stdout))
+        self.logger = logger
 
     def create_socket(self):
         try:
@@ -67,7 +66,7 @@ class QemuRunner:
             sock.bind(("127.0.0.1",0))
             sock.listen(2)
             port = sock.getsockname()[1]
-            self.logger.info("Created listening socket for qemu serial console on: 127.0.0.1:%s" % port)
+            self.logger.debug("Created listening socket for qemu serial console on: 127.0.0.1:%s" % port)
             return (sock, port)
 
         except socket.error:
@@ -94,8 +93,8 @@ class QemuRunner:
     def handleSIGCHLD(self, signum, frame):
         if self.runqemu and self.runqemu.poll():
             if self.runqemu.returncode:
-                self.logger.info('runqemu exited with code %d' % self.runqemu.returncode)
-                self.logger.info("Output from runqemu:\n%s" % self.getOutput(self.runqemu.stdout))
+                self.logger.debug('runqemu exited with code %d' % self.runqemu.returncode)
+                self.logger.debug("Output from runqemu:\n%s" % self.getOutput(self.runqemu.stdout))
                 self.stop()
                 self._dump_host()
                 raise SystemExit
@@ -124,10 +123,10 @@ class QemuRunner:
         if not launch_cmd:
             launch_cmd = 'runqemu %s %s ' % ('snapshot' if discard_writes else '', runqemuparams)
             if self.use_kvm:
-                self.logger.info('Using kvm for runqemu')
+                self.logger.debug('Using kvm for runqemu')
                 launch_cmd += ' kvm'
             else:
-                self.logger.info('Not using kvm for runqemu')
+                self.logger.debug('Not using kvm for runqemu')
             if not self.display:
                 launch_cmd += ' nographic'
             launch_cmd += ' %s %s' % (self.machine, self.rootfs)
@@ -159,7 +158,7 @@ class QemuRunner:
         self.origchldhandler = signal.getsignal(signal.SIGCHLD)
         signal.signal(signal.SIGCHLD, self.handleSIGCHLD)
 
-        self.logger.info('launchcmd=%s'%(launch_cmd))
+        self.logger.debug('launchcmd=%s'%(launch_cmd))
 
         # FIXME: We pass in stdin=subprocess.PIPE here to work around stty
         # blocking at the end of the runqemu script when using this within
@@ -194,17 +193,17 @@ class QemuRunner:
             os.killpg(os.getpgid(self.runqemu.pid), signal.SIGTERM)
             sys.exit(0)
 
-        self.logger.info("runqemu started, pid is %s" % self.runqemu.pid)
-        self.logger.info("waiting at most %s seconds for qemu pid" % self.runqemutime)
+        self.logger.debug("runqemu started, pid is %s" % self.runqemu.pid)
+        self.logger.debug("waiting at most %s seconds for qemu pid" % self.runqemutime)
         endtime = time.time() + self.runqemutime
         while not self.is_alive() and time.time() < endtime:
             if self.runqemu.poll():
                 if self.runqemu.returncode:
                     # No point waiting any longer
-                    self.logger.info('runqemu exited with code %d' % self.runqemu.returncode)
+                    self.logger.debug('runqemu exited with code %d' % self.runqemu.returncode)
                     self._dump_host()
                     self.stop()
-                    self.logger.info("Output from runqemu:\n%s" % self.getOutput(output))
+                    self.logger.debug("Output from runqemu:\n%s" % self.getOutput(output))
                     return False
             time.sleep(0.5)
 
@@ -213,7 +212,7 @@ class QemuRunner:
             # Dump all processes to help us to figure out what is going on...
             ps = subprocess.Popen(['ps', 'axww', '-o', 'pid,ppid,command '], stdout=subprocess.PIPE).communicate()[0]
             processes = ps.decode("utf-8")
-            self.logger.info("Running processes:\n%s" % processes)
+            self.logger.debug("Running processes:\n%s" % processes)
             self._dump_host()
             self.stop()
             op = self.getOutput(output)
@@ -226,7 +225,7 @@ class QemuRunner:
         # We are alive: qemu is running
         out = self.getOutput(output)
         netconf = False # network configuration is not required by default
-        self.logger.info("qemu started in %s seconds - qemu procces pid is %s" % (time.time() - (endtime - self.runqemutime), self.qemupid))
+        self.logger.debug("qemu started in %s seconds - qemu procces pid is %s" % (time.time() - (endtime - self.runqemutime), self.qemupid))
         if get_ip:
             cmdline = ''
             with open('/proc/%s/cmdline' % self.qemupid) as p:
@@ -238,7 +237,7 @@ class QemuRunner:
                 ips = re.findall("((?:[0-9]{1,3}\.){3}[0-9]{1,3})", cmdline.split("ip=")[1])
                 self.ip = ips[0]
                 self.server_ip = ips[1]
-                self.logger.info("qemu cmdline used:\n{}".format(cmdline))
+                self.logger.debug("qemu cmdline used:\n{}".format(cmdline))
             except (IndexError, ValueError):
                 # Try to get network configuration from runqemu output
                 match = re.match('.*Network configuration: ([0-9.]+)::([0-9.]+):([0-9.]+)$.*',
@@ -257,8 +256,8 @@ class QemuRunner:
                     self.stop()
                     return False
 
-        self.logger.info("Target IP: %s" % self.ip)
-        self.logger.info("Server IP: %s" % self.server_ip)
+        self.logger.debug("Target IP: %s" % self.ip)
+        self.logger.debug("Server IP: %s" % self.server_ip)
 
         self.thread = LoggingThread(self.log, threadsock, self.logger)
         self.thread.start()
@@ -269,14 +268,14 @@ class QemuRunner:
             self.stop_thread()
             return False
 
-        self.logger.info("Output from runqemu:\n%s", out)
-        self.logger.info("Waiting at most %d seconds for login banner" % self.boottime)
+        self.logger.debug("Output from runqemu:\n%s", out)
+        self.logger.debug("Waiting at most %d seconds for login banner" % self.boottime)
         endtime = time.time() + self.boottime
         socklist = [self.server_socket]
         reachedlogin = False
         stopread = False
         qemusock = None
-        bootlog = ''
+        bootlog = b''
         data = b''
         while time.time() < endtime and not stopread:
             try:
@@ -289,21 +288,17 @@ class QemuRunner:
                     qemusock.setblocking(0)
                     socklist.append(qemusock)
                     socklist.remove(self.server_socket)
-                    self.logger.info("Connection from %s:%s" % addr)
+                    self.logger.debug("Connection from %s:%s" % addr)
                 else:
                     data = data + sock.recv(1024)
                     if data:
-                        try:
-                            data = data.decode("utf-8", errors="surrogateescape")
-                            bootlog += data
-                            data = b''
-                            if re.search(".* login:", bootlog):
-                                self.server_socket = qemusock
-                                stopread = True
-                                reachedlogin = True
-                                self.logger.info("Reached login banner")
-                        except UnicodeDecodeError:
-                            continue
+                        bootlog += data
+                        data = b''
+                        if b' login:' in bootlog:
+                            self.server_socket = qemusock
+                            stopread = True
+                            reachedlogin = True
+                            self.logger.debug("Reached login banner")
                     else:
                         socklist.remove(sock)
                         sock.close()
@@ -311,12 +306,12 @@ class QemuRunner:
 
 
         if not reachedlogin:
-            self.logger.info("Target didn't reached login boot in %d seconds" % self.boottime)
+            self.logger.debug("Target didn't reached login boot in %d seconds" % self.boottime)
             tail = lambda l: "\n".join(l.splitlines()[-25:])
             # in case bootlog is empty, use tail qemu log store at self.msg
             lines = tail(bootlog if bootlog else self.msg)
-            self.logger.info("Last 25 lines of text:\n%s" % lines)
-            self.logger.info("Check full boot log: %s" % self.logfile)
+            self.logger.debug("Last 25 lines of text:\n%s" % lines)
+            self.logger.debug("Check full boot log: %s" % self.logfile)
             self._dump_host()
             self.stop()
             return False
@@ -326,20 +321,20 @@ class QemuRunner:
             (status, output) = self.run_serial("root\n", raw=True)
             if re.search("root@[a-zA-Z0-9\-]+:~#", output):
                 self.logged = True
-                self.logger.info("Logged as root in serial console")
+                self.logger.debug("Logged as root in serial console")
                 if netconf:
                     # configure guest networking
                     cmd = "ifconfig eth0 %s netmask %s up\n" % (self.ip, self.netmask)
                     output = self.run_serial(cmd, raw=True)[1]
                     if re.search("root@[a-zA-Z0-9\-]+:~#", output):
-                        self.logger.info("configured ip address %s", self.ip)
+                        self.logger.debug("configured ip address %s", self.ip)
                     else:
-                        self.logger.info("Couldn't configure guest networking")
-                else:
-                    self.logger.info("Couldn't login into serial console"
-                                " as root using blank password")
+                        self.logger.debug("Couldn't configure guest networking")
+            else:
+                self.logger.debug("Couldn't login into serial console"
+                            " as root using blank password")
         except:
-            self.logger.info("Serial console failed while trying to login")
+            self.logger.debug("Serial console failed while trying to login")
         return True
 
     def stop(self):
@@ -350,7 +345,7 @@ class QemuRunner:
         if self.runqemu:
             if hasattr(self, "monitorpid"):
                 os.kill(self.monitorpid, signal.SIGKILL)
-                self.logger.info("Sending SIGTERM to runqemu")
+                self.logger.debug("Sending SIGTERM to runqemu")
                 try:
                     os.killpg(os.getpgid(self.runqemu.pid), signal.SIGTERM)
                 except OSError as e:
@@ -360,7 +355,7 @@ class QemuRunner:
             while self.runqemu.poll() is None and time.time() < endtime:
                 time.sleep(1)
             if self.runqemu.poll() is None:
-                self.logger.info("Sending SIGKILL to runqemu")
+                self.logger.debug("Sending SIGKILL to runqemu")
                 os.killpg(os.getpgid(self.runqemu.pid), signal.SIGKILL)
             self.runqemu = None
         if hasattr(self, 'server_socket') and self.server_socket:
@@ -385,7 +380,7 @@ class QemuRunner:
             self.thread.join()
 
     def restart(self, qemuparams = None):
-        self.logger.info("Restarting qemu process")
+        self.logger.debug("Restarting qemu process")
         if self.runqemu.poll() is None:
             self.stop()
         if self.start(qemuparams):
@@ -483,17 +478,17 @@ class LoggingThread(threading.Thread):
             self.teardown()
 
     def run(self):
-        self.logger.info("Starting logging thread")
+        self.logger.debug("Starting logging thread")
         self.readpipe, self.writepipe = os.pipe()
         threading.Thread.run(self)
 
     def stop(self):
-        self.logger.info("Stopping logging thread")
+        self.logger.debug("Stopping logging thread")
         if self.running:
             os.write(self.writepipe, bytes("stop", "utf-8"))
 
     def teardown(self):
-        self.logger.info("Tearing down logging thread")
+        self.logger.debug("Tearing down logging thread")
         self.close_socket(self.serversock)
 
         if self.readsock is not None:
@@ -511,7 +506,7 @@ class LoggingThread(threading.Thread):
 
         breakout = False
         self.running = True
-        self.logger.info("Starting thread event loop")
+        self.logger.debug("Starting thread event loop")
         while not breakout:
             events = poll.poll()
             for event in events:
@@ -521,19 +516,19 @@ class LoggingThread(threading.Thread):
 
                 # Event to stop the thread
                 if self.readpipe == event[0]:
-                    self.logger.info("Stop event received")
+                    self.logger.debug("Stop event received")
                     breakout = True
                     break
 
                 # A connection request was received
                 elif self.serversock.fileno() == event[0]:
-                    self.logger.info("Connection request received")
+                    self.logger.debug("Connection request received")
                     self.readsock, _ = self.serversock.accept()
                     self.readsock.setblocking(0)
                     poll.unregister(self.serversock.fileno())
                     poll.register(self.readsock.fileno(), event_read_mask)
 
-                    self.logger.info("Setting connection established event")
+                    self.logger.debug("Setting connection established event")
                     self.connection_established.set()
 
                 # Actual data to be logged

meta/lib/oeqa/utils/qemutinyrunner.py

@@ -17,7 +17,7 @@ from .qemurunner import QemuRunner
 
 class QemuTinyRunner(QemuRunner):
 
-    def __init__(self, machine, rootfs, display, tmpdir, deploy_dir_image, logfile, kernel, boottime):
+    def __init__(self, machine, rootfs, display, tmpdir, deploy_dir_image, logfile, kernel, boottime, logger):
 
         # Popen object for runqemu
         self.runqemu = None
@@ -40,6 +40,7 @@ class QemuTinyRunner(QemuRunner):
         self.socketfile = "console.sock"
         self.server_socket = None
         self.kernel = kernel
+        self.logger = logger
 
 
     def create_socket(self):

meta/lib/oeqa/utils/sshcontrol.py

@@ -150,12 +150,9 @@ class SSHControl(object):
 
     def copy_to(self, localpath, remotepath):
         if os.path.islink(localpath):
-            link = os.readlink(localpath)
-            dst_dir, dst_base = os.path.split(remotepath)
-            return self.run("cd %s; ln -s %s %s" % (dst_dir, link, dst_base))
-        else:
-            command = self.scp + [localpath, '%s@%s:%s' % (self.user, self.ip, remotepath)]
-            return self._internal_run(command, ignore_status=False)
+            localpath = os.path.dirname(localpath) + "/" + os.readlink(localpath)
+        command = self.scp + [localpath, '%s@%s:%s' % (self.user, self.ip, remotepath)]
+        return self._internal_run(command, ignore_status=False)
 
     def copy_from(self, remotepath, localpath):
         command = self.scp + ['%s@%s:%s' % (self.user, self.ip, remotepath), localpath]

meta/recipes-bsp/grub/grub-efi_2.02.bb

@@ -41,6 +41,16 @@ do_install_class-native() {
 	install -m 755 grub-mkimage ${D}${bindir}
 }
 
+do_install_append_class-target() {
+    # Remove build host references...
+    find "${D}" -name modinfo.sh -type f -exec \
+        sed -i \
+        -e 's,--sysroot=${STAGING_DIR_TARGET},,g' \
+        -e 's|${DEBUG_PREFIX_MAP}||g' \
+        -e 's:${RECIPE_SYSROOT_NATIVE}::g' \
+        {} +
+}
+
 GRUB_BUILDIN ?= "boot linux ext2 fat serial part_msdos part_gpt normal efi_gop iso9660 search"
 
 do_deploy() {

meta/recipes-bsp/grub/grub_2.02.bb

@@ -8,6 +8,13 @@ FILES_grub-editenv = "${bindir}/grub-editenv"
 
 do_install_append () {
     install -d ${D}${sysconfdir}/grub.d
+    # Remove build host references...
+    find "${D}" -name modinfo.sh -type f -exec \
+        sed -i \
+        -e 's,--sysroot=${STAGING_DIR_TARGET},,g' \
+        -e 's|${DEBUG_PREFIX_MAP}||g' \
+        -e 's:${RECIPE_SYSROOT_NATIVE}::g' \
+        {} +
 }
 
 INSANE_SKIP_${PN} = "arch"