bitbake: server/process: Always place the server logfile in the build directory

Currently the bitbake-cookerdaemon.log is placed into cwd. This seems like a
bad idea, we can place it in the build directory alongside the lockfile that
represents the server instead.

(Bitbake rev: 1620dbc48ffb2a882371cf9174a7b12648befc8a)

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

bitbake/bin/bitbake

@@ -38,7 +38,7 @@ from bb.main import bitbake_main, BitBakeConfigParameters, BBMainException
 if sys.getfilesystemencoding() != "utf-8":
     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.37.0"
+__version__ = "1.39.0"
 
 if __name__ == "__main__":
     if __version__ != bb.__version__:

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

@@ -1929,6 +1929,38 @@
                         not careful.
                     </note>
                     </para></listitem>
+                <listitem><para><emphasis><filename>[number_threads]</filename>:</emphasis>
+                    Limits tasks to a specific number of simultaneous threads
+                    during execution.
+                    This varflag is useful when your build host has a large number
+                    of cores but certain tasks need to be rate-limited due to various
+                    kinds of resource constraints (e.g. to avoid network throttling).
+                    <filename>number_threads</filename> works similarly to the
+                    <link linkend='var-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename></link>
+                    variable but is task-specific.</para>
+
+                    <para>Set the value globally.
+                    For example, the following makes sure the
+                    <filename>do_fetch</filename> task uses no more than two
+                    simultaneous execution threads:
+                    <literallayout class='monospaced'>
+     do_fetch[number_threads] = "2"
+                    </literallayout>
+                    <note><title>Warnings</title>
+                        <itemizedlist>
+                            <listitem><para>
+                                Setting the varflag in individual recipes rather
+                                than globally can result in unpredictable behavior.
+                                </para></listitem>
+                            <listitem><para>
+                                Setting the varflag to a value greater than the
+                                value used in the <filename>BB_NUMBER_THREADS</filename>
+                                variable causes <filename>number_threads</filename>
+                                to have no effect.
+                                </para></listitem>
+                        </itemizedlist>
+                    </note>
+                    </para></listitem>
                 <listitem><para><emphasis><filename>[postfuncs]</filename>:</emphasis>
                     List of functions to call after the completion of the task.
                     </para></listitem>

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

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

bitbake/lib/bb/__init__.py

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

bitbake/lib/bb/fetch2/__init__.py

@@ -383,7 +383,7 @@ def decodeurl(url):
         path = location
     else:
         host = location
-        path = ""
+        path = "/"
     if user:
         m = re.compile('(?P<user>[^:]+)(:?(?P<pswd>.*))').match(user)
         if m:
@@ -452,8 +452,8 @@ def uri_replace(ud, uri_find, uri_replace, replacements, d, mirrortarball=None):
             # Handle URL parameters
             if i:
                 # Any specified URL parameters must match
-                for k in uri_replace_decoded[loc]:
-                    if uri_decoded[loc][k] != uri_replace_decoded[loc][k]:
+                for k in uri_find_decoded[loc]:
+                    if uri_decoded[loc][k] != uri_find_decoded[loc][k]:
                         return None
             # Overwrite any specified replacement parameters
             for k in uri_replace_decoded[loc]:

bitbake/lib/bb/fetch2/bzr.py

@@ -41,8 +41,9 @@ class Bzr(FetchMethod):
         init bzr specific variable within url data
         """
         # Create paths to bzr checkouts
+        bzrdir = d.getVar("BZRDIR") or (d.getVar("DL_DIR") + "/bzr")
         relpath = self._strip_leading_slashes(ud.path)
-        ud.pkgdir = os.path.join(d.expand('${BZRDIR}'), ud.host, relpath)
+        ud.pkgdir = os.path.join(bzrdir, ud.host, relpath)
 
         ud.setup_revisions(d)
 
@@ -57,7 +58,7 @@ class Bzr(FetchMethod):
         command is "fetch", "update", "revno"
         """
 
-        basecmd = d.expand('${FETCHCMD_bzr}')
+        basecmd = d.getVar("FETCHCMD_bzr") or "/usr/bin/env bzr"
 
         proto =  ud.parm.get('protocol', 'http')
 

bitbake/lib/bb/fetch2/clearcase.py

@@ -69,7 +69,6 @@ from   bb.fetch2 import FetchMethod
 from   bb.fetch2 import FetchError
 from   bb.fetch2 import runfetchcmd
 from   bb.fetch2 import logger
-from   distutils import spawn
 
 class ClearCase(FetchMethod):
     """Class to fetch urls via 'clearcase'"""
@@ -107,7 +106,7 @@ class ClearCase(FetchMethod):
         else:
             ud.module = ""
 
-        ud.basecmd = d.getVar("FETCHCMD_ccrc") or spawn.find_executable("cleartool") or spawn.find_executable("rcleartool")
+        ud.basecmd = d.getVar("FETCHCMD_ccrc") or "/usr/bin/env cleartool || rcleartool"
 
         if d.getVar("SRCREV") == "INVALID":
           raise FetchError("Set a valid SRCREV for the clearcase fetcher in your recipe, e.g. SRCREV = \"/main/LATEST\" or any other label of your choice.")

bitbake/lib/bb/fetch2/cvs.py

@@ -110,7 +110,7 @@ class Cvs(FetchMethod):
         if ud.tag:
             options.append("-r %s" % ud.tag)
 
-        cvsbasecmd = d.getVar("FETCHCMD_cvs")
+        cvsbasecmd = d.getVar("FETCHCMD_cvs") or "/usr/bin/env cvs"
         cvscmd = cvsbasecmd + " '-d" + cvsroot + "' co " + " ".join(options) + " " + ud.module
         cvsupdatecmd = cvsbasecmd + " '-d" + cvsroot + "' update -d -P " + " ".join(options)
 
@@ -121,7 +121,8 @@ class Cvs(FetchMethod):
         # create module directory
         logger.debug(2, "Fetch: checking for module directory")
         pkg = d.getVar('PN')
-        pkgdir = os.path.join(d.getVar('CVSDIR'), pkg)
+        cvsdir = d.getVar("CVSDIR") or (d.getVar("DL_DIR") + "/cvs")
+        pkgdir = os.path.join(cvsdir, pkg)
         moddir = os.path.join(pkgdir, localdir)
         workdir = None
         if os.access(os.path.join(moddir, 'CVS'), os.R_OK):

bitbake/lib/bb/fetch2/git.py

@@ -261,7 +261,7 @@ class Git(FetchMethod):
                 gitsrcname = gitsrcname + '_' + ud.revisions[name]
 
         dl_dir = d.getVar("DL_DIR")
-        gitdir = d.getVar("GITDIR") or (dl_dir + "/git2/")
+        gitdir = d.getVar("GITDIR") or (dl_dir + "/git2")
         ud.clonedir = os.path.join(gitdir, gitsrcname)
         ud.localfile = ud.clonedir
 
@@ -322,16 +322,13 @@ class Git(FetchMethod):
     def download(self, ud, d):
         """Fetch url"""
 
-        no_clone = not os.path.exists(ud.clonedir)
-        need_update = no_clone or self.need_update(ud, d)
-
         # A current clone is preferred to either tarball, a shallow tarball is
         # preferred to an out of date clone, and a missing clone will use
         # either tarball.
-        if ud.shallow and os.path.exists(ud.fullshallow) and need_update:
+        if ud.shallow and os.path.exists(ud.fullshallow) and self.need_update(ud, d):
             ud.localpath = ud.fullshallow
             return
-        elif os.path.exists(ud.fullmirror) and no_clone:
+        elif os.path.exists(ud.fullmirror) and not os.path.exists(ud.clonedir):
             bb.utils.mkdirhier(ud.clonedir)
             runfetchcmd("tar -xzf %s" % ud.fullmirror, d, workdir=ud.clonedir)
 
@@ -353,6 +350,8 @@ class Git(FetchMethod):
         for name in ud.names:
             if not self._contains_ref(ud, d, name, ud.clonedir):
                 needupdate = True
+                break
+
         if needupdate:
             try: 
                 runfetchcmd("%s remote rm origin" % ud.basecmd, d, workdir=ud.clonedir)
@@ -373,6 +372,7 @@ class Git(FetchMethod):
             except OSError as exc:
                 if exc.errno != errno.ENOENT:
                     raise
+
         for name in ud.names:
             if not self._contains_ref(ud, d, name, ud.clonedir):
                 raise bb.fetch2.FetchError("Unable to find revision %s in branch %s even from upstream" % (ud.revisions[name], ud.branches[name]))
@@ -472,7 +472,7 @@ class Git(FetchMethod):
         if os.path.exists(destdir):
             bb.utils.prunedir(destdir)
 
-        if ud.shallow and (not os.path.exists(ud.clonedir) or self.need_update(ud, d)):
+        if ud.shallow and self.need_update(ud, d):
             bb.utils.mkdirhier(destdir)
             runfetchcmd("tar -xzf %s" % ud.fullshallow, d, workdir=destdir)
         else:

bitbake/lib/bb/fetch2/gitsm.py

@@ -98,7 +98,7 @@ class GitSM(Git):
                         for line in lines:
                             f.write(line)
 
-    def update_submodules(self, ud, d):
+    def update_submodules(self, ud, d, allow_network):
         # We have to convert bare -> full repo, do the submodule bit, then convert back
         tmpclonedir = ud.clonedir + ".tmp"
         gitdir = tmpclonedir + os.sep + ".git"
@@ -108,11 +108,46 @@ class GitSM(Git):
         runfetchcmd("sed " + gitdir + "/config -i -e 's/bare.*=.*true/bare = false/'", d)
         runfetchcmd(ud.basecmd + " reset --hard", d, workdir=tmpclonedir)
         runfetchcmd(ud.basecmd + " checkout -f " + ud.revisions[ud.names[0]], d, workdir=tmpclonedir)
-        runfetchcmd(ud.basecmd + " submodule update --init --recursive", d, workdir=tmpclonedir)
-        self._set_relative_paths(tmpclonedir)
-        runfetchcmd("sed " + gitdir + "/config -i -e 's/bare.*=.*false/bare = true/'", d, workdir=tmpclonedir)
-        os.rename(gitdir, ud.clonedir,)
-        bb.utils.remove(tmpclonedir, True)
+
+        try:
+            if allow_network:
+                fetch_flags = ""
+            else:
+                fetch_flags = "--no-fetch"
+
+            # The 'git submodule sync' sandwiched between two successive 'git submodule update' commands is
+            # intentional. See the notes on the similar construction in download() for an explanation.
+            runfetchcmd("%(basecmd)s submodule update --init --recursive %(fetch_flags)s || (%(basecmd)s submodule sync --recursive && %(basecmd)s submodule update --init --recursive %(fetch_flags)s)" % {'basecmd': ud.basecmd, 'fetch_flags' : fetch_flags}, d, workdir=tmpclonedir)
+        except bb.fetch.FetchError:
+            if allow_network:
+                raise
+            else:
+                # This method was called as a probe to see whether the submodule history
+                # is complete enough to allow the current working copy to have its
+                # modules filled in. It's not, so swallow up the exception and report
+                # the negative result.
+                return False
+        finally:
+            self._set_relative_paths(tmpclonedir)
+            runfetchcmd("sed " + gitdir + "/config -i -e 's/bare.*=.*false/bare = true/'", d, workdir=tmpclonedir)
+            os.rename(gitdir, ud.clonedir,)
+            bb.utils.remove(tmpclonedir, True)
+
+        return True
+
+    def need_update(self, ud, d):
+        main_repo_needs_update = Git.need_update(self, ud, d)
+
+        # First check that the main repository has enough history fetched. If it doesn't, then we don't
+        # even have the .gitmodules and gitlinks for the submodules to attempt asking whether the
+        # submodules' histories are recent enough.
+        if main_repo_needs_update:
+            return True
+
+        # Now check that the submodule histories are new enough. The git-submodule command doesn't have
+        # any clean interface for doing this aside from just attempting the checkout (with network
+        # fetched disabled).
+        return not self.update_submodules(ud, d, allow_network=False)
 
     def download(self, ud, d):
         Git.download(self, ud, d)
@@ -120,7 +155,7 @@ class GitSM(Git):
         if not ud.shallow or ud.localpath != ud.fullshallow:
             submodules = self.uses_submodules(ud, d, ud.clonedir)
             if submodules:
-                self.update_submodules(ud, d)
+                self.update_submodules(ud, d, allow_network=True)
 
     def clone_shallow_local(self, ud, dest, d):
         super(GitSM, self).clone_shallow_local(ud, dest, d)
@@ -132,4 +167,36 @@ class GitSM(Git):
 
         if self.uses_submodules(ud, d, ud.destdir):
             runfetchcmd(ud.basecmd + " checkout " + ud.revisions[ud.names[0]], d, workdir=ud.destdir)
-            runfetchcmd(ud.basecmd + " submodule update --init --recursive", d, workdir=ud.destdir)
+
+            # Copy over the submodules' fetched histories too.
+            if ud.bareclone:
+                repo_conf = ud.destdir
+            else:
+                repo_conf = os.path.join(ud.destdir, '.git')
+
+            if os.path.exists(ud.clonedir):
+                # This is not a copy unpacked from a shallow mirror clone. So
+                # the manual intervention to populate the .git/modules done
+                # in clone_shallow_local() won't have been done yet.
+                runfetchcmd("cp -fpPRH %s %s" % (os.path.join(ud.clonedir, 'modules'), repo_conf), d)
+                fetch_flags = "--no-fetch"
+            elif os.path.exists(os.path.join(repo_conf, 'modules')):
+                # Unpacked from a shallow mirror clone. Manual population of
+                # .git/modules is already done.
+                fetch_flags = "--no-fetch"
+            else:
+                # This isn't fatal; git-submodule will just fetch it
+                # during do_unpack().
+                fetch_flags = ""
+                bb.error("submodule history not retrieved during do_fetch()")
+
+            # Careful not to hit the network during unpacking; all history should already
+            # be fetched.
+            #
+            # The repeated attempts to do the submodule initialization sandwiched around a sync to
+            # install the correct remote URLs into the submodules' .git/config metadata are deliberate.
+            # Bad remote URLs are leftover in the modules' .git/config files from the unpack of bare
+            # clone tarballs and an initial 'git submodule update' is necessary to prod them back to
+            # enough life so that the 'git submodule sync' realizes the existing module .git/config
+            # files exist to be updated.
+            runfetchcmd("%(basecmd)s submodule update --init --recursive %(fetch_flags)s || (%(basecmd)s submodule sync --recursive && %(basecmd)s submodule update --init --recursive %(fetch_flags)s)" % {'basecmd': ud.basecmd, 'fetch_flags': fetch_flags}, d, workdir=ud.destdir)

bitbake/lib/bb/fetch2/hg.py

@@ -80,7 +80,7 @@ class Hg(FetchMethod):
         ud.fullmirror = os.path.join(d.getVar("DL_DIR"), mirrortarball)
         ud.mirrortarballs = [mirrortarball]
 
-        hgdir = d.getVar("HGDIR") or (d.getVar("DL_DIR") + "/hg/")
+        hgdir = d.getVar("HGDIR") or (d.getVar("DL_DIR") + "/hg")
         ud.pkgdir = os.path.join(hgdir, hgsrcname)
         ud.moddir = os.path.join(ud.pkgdir, ud.module)
         ud.localfile = ud.moddir

bitbake/lib/bb/fetch2/npm.py

@@ -32,7 +32,6 @@ from   bb.fetch2 import runfetchcmd
 from   bb.fetch2 import logger
 from   bb.fetch2 import UnpackError
 from   bb.fetch2 import ParameterError
-from   distutils import spawn
 
 def subprocess_setup():
     # Python installs a SIGPIPE handler by default. This is usually not what

bitbake/lib/bb/fetch2/osc.py

@@ -32,8 +32,9 @@ class Osc(FetchMethod):
         ud.module = ud.parm["module"]
 
         # Create paths to osc checkouts
+        oscdir = d.getVar("OSCDIR") or (d.getVar("DL_DIR") + "/osc")
         relpath = self._strip_leading_slashes(ud.path)
-        ud.pkgdir = os.path.join(d.getVar('OSCDIR'), ud.host)
+        ud.pkgdir = os.path.join(oscdir, ud.host)
         ud.moddir = os.path.join(ud.pkgdir, relpath, ud.module)
 
         if 'rev' in ud.parm:
@@ -54,7 +55,7 @@ class Osc(FetchMethod):
         command is "fetch", "update", "info"
         """
 
-        basecmd = d.expand('${FETCHCMD_osc}')
+        basecmd = d.getVar("FETCHCMD_osc") or "/usr/bin/env osc"
 
         proto = ud.parm.get('protocol', 'ocs')
 

bitbake/lib/bb/fetch2/perforce.py

@@ -43,13 +43,9 @@ class Perforce(FetchMethod):
         provided by the env, use it.  If P4PORT is specified by the recipe, use
         its values, which may override the settings in P4CONFIG.
         """
-        ud.basecmd = d.getVar('FETCHCMD_p4')
-        if not ud.basecmd:
-            ud.basecmd = "/usr/bin/env p4"
+        ud.basecmd = d.getVar("FETCHCMD_p4") or "/usr/bin/env p4"
 
-        ud.dldir = d.getVar('P4DIR')
-        if not ud.dldir:
-            ud.dldir = '%s/%s' % (d.getVar('DL_DIR'), 'p4')
+        ud.dldir = d.getVar("P4DIR") or (d.getVar("DL_DIR") + "/p4")
 
         path = ud.url.split('://')[1]
         path = path.split(';')[0]

bitbake/lib/bb/fetch2/repo.py

@@ -45,6 +45,8 @@ class Repo(FetchMethod):
         "master".
         """
 
+        ud.basecmd = d.getVar("FETCHCMD_repo") or "/usr/bin/env repo"
+
         ud.proto = ud.parm.get('protocol', 'git')
         ud.branch = ud.parm.get('branch', 'master')
         ud.manifest = ud.parm.get('manifest', 'default.xml')
@@ -60,8 +62,8 @@ class Repo(FetchMethod):
             logger.debug(1, "%s already exists (or was stashed). Skipping repo init / sync.", ud.localpath)
             return
 
+        repodir = d.getVar("REPODIR") or (d.getVar("DL_DIR") + "/repo")
         gitsrcname = "%s%s" % (ud.host, ud.path.replace("/", "."))
-        repodir = d.getVar("REPODIR") or os.path.join(d.getVar("DL_DIR"), "repo")
         codir = os.path.join(repodir, gitsrcname, ud.manifest)
 
         if ud.user:
@@ -72,11 +74,11 @@ class Repo(FetchMethod):
         repodir = os.path.join(codir, "repo")
         bb.utils.mkdirhier(repodir)
         if not os.path.exists(os.path.join(repodir, ".repo")):
-            bb.fetch2.check_network_access(d, "repo init -m %s -b %s -u %s://%s%s%s" % (ud.manifest, ud.branch, ud.proto, username, ud.host, ud.path), ud.url)
-            runfetchcmd("repo init -m %s -b %s -u %s://%s%s%s" % (ud.manifest, ud.branch, ud.proto, username, ud.host, ud.path), d, workdir=repodir)
+            bb.fetch2.check_network_access(d, "%s init -m %s -b %s -u %s://%s%s%s" % (ud.basecmd, ud.manifest, ud.branch, ud.proto, username, ud.host, ud.path), ud.url)
+            runfetchcmd("%s init -m %s -b %s -u %s://%s%s%s" % (ud.basecmd, ud.manifest, ud.branch, ud.proto, username, ud.host, ud.path), d, workdir=repodir)
 
-        bb.fetch2.check_network_access(d, "repo sync %s" % ud.url, ud.url)
-        runfetchcmd("repo sync", d, workdir=repodir)
+        bb.fetch2.check_network_access(d, "%s sync %s" % (ud.basecmd, ud.url), ud.url)
+        runfetchcmd("%s sync" % ud.basecmd, d, workdir=repodir)
 
         scmdata = ud.parm.get("scmdata", "")
         if scmdata == "keep":

bitbake/lib/bb/fetch2/svn.py

@@ -49,7 +49,7 @@ class Svn(FetchMethod):
         if not "module" in ud.parm:
             raise MissingParameterError('module', ud.url)
 
-        ud.basecmd = d.getVar('FETCHCMD_svn')
+        ud.basecmd = d.getVar("FETCHCMD_svn") or "/usr/bin/env svn --non-interactive --trust-server-cert"
 
         ud.module = ud.parm["module"]
 
@@ -59,8 +59,9 @@ class Svn(FetchMethod):
             ud.path_spec = ud.parm["path_spec"]
 
         # Create paths to svn checkouts
+        svndir = d.getVar("SVNDIR") or (d.getVar("DL_DIR") + "/svn")
         relpath = self._strip_leading_slashes(ud.path)
-        ud.pkgdir = os.path.join(d.expand('${SVNDIR}'), ud.host, relpath)
+        ud.pkgdir = os.path.join(svndir, ud.host, relpath)
         ud.moddir = os.path.join(ud.pkgdir, ud.module)
 
         ud.setup_revisions(d)

bitbake/lib/bb/runqueue.py

@@ -94,13 +94,13 @@ class RunQueueStats:
         self.active = self.active - 1
         self.failed = self.failed + 1
 
-    def taskCompleted(self, number = 1):
-        self.active = self.active - number
-        self.completed = self.completed + number
+    def taskCompleted(self):
+        self.active = self.active - 1
+        self.completed = self.completed + 1
 
-    def taskSkipped(self, number = 1):
-        self.active = self.active + number
-        self.skipped = self.skipped + number
+    def taskSkipped(self):
+        self.active = self.active + 1
+        self.skipped = self.skipped + 1
 
     def taskActive(self):
         self.active = self.active + 1
@@ -134,6 +134,7 @@ class RunQueueScheduler(object):
         self.prio_map = [self.rqdata.runtaskentries.keys()]
 
         self.buildable = []
+        self.skip_maxthread = {}
         self.stamps = {}
         for tid in self.rqdata.runtaskentries:
             (mc, fn, taskname, taskfn) = split_tid_mcfn(tid)
@@ -150,8 +151,25 @@ class RunQueueScheduler(object):
         self.buildable = [x for x in self.buildable if x not in self.rq.runq_running]
         if not self.buildable:
             return None
+
+        # Filter out tasks that have a max number of threads that have been exceeded
+        skip_buildable = {}
+        for running in self.rq.runq_running.difference(self.rq.runq_complete):
+            rtaskname = taskname_from_tid(running)
+            if rtaskname not in self.skip_maxthread:
+                self.skip_maxthread[rtaskname] = self.rq.cfgData.getVarFlag(rtaskname, "number_threads")
+            if not self.skip_maxthread[rtaskname]:
+                continue
+            if rtaskname in skip_buildable:
+                skip_buildable[rtaskname] += 1
+            else:
+                skip_buildable[rtaskname] = 1
+
         if len(self.buildable) == 1:
             tid = self.buildable[0]
+            taskname = taskname_from_tid(tid)
+            if taskname in skip_buildable and skip_buildable[taskname] >= int(self.skip_maxthread[taskname]):
+                return None
             stamp = self.stamps[tid]
             if stamp not in self.rq.build_stamps.values():
                 return tid
@@ -164,6 +182,9 @@ class RunQueueScheduler(object):
         best = None
         bestprio = None
         for tid in self.buildable:
+            taskname = taskname_from_tid(tid)
+            if taskname in skip_buildable and skip_buildable[taskname] >= int(self.skip_maxthread[taskname]):
+                continue
             prio = self.rev_prio_map[tid]
             if bestprio is None or bestprio > prio:
                 stamp = self.stamps[tid]
@@ -1040,7 +1061,7 @@ class RunQueueData:
 
         # Create a whitelist usable by the stamp checks
         self.stampfnwhitelist = {}
-        for mc in self.taskData: 
+        for mc in self.taskData:
             self.stampfnwhitelist[mc] = []
             for entry in self.stampwhitelist.split():
                 if entry not in self.taskData[mc].build_targets:
@@ -1072,7 +1093,7 @@ class RunQueueData:
                     bb.debug(1, "Task %s is marked nostamp, cannot invalidate this task" % taskname)
             else:
                 logger.verbose("Invalidate task %s, %s", taskname, fn)
-                bb.parse.siggen.invalidate_task(taskname, self.dataCaches[mc], fn)
+                bb.parse.siggen.invalidate_task(taskname, self.dataCaches[mc], taskfn)
 
         self.init_progress_reporter.next_stage()
 
@@ -1865,14 +1886,13 @@ class RunQueueExecuteTasks(RunQueueExecute):
                 continue
             if revdep in self.runq_buildable:
                 continue
-            alldeps = 1
+            alldeps = True
             for dep in self.rqdata.runtaskentries[revdep].depends:
                 if dep not in self.runq_complete:
-                    alldeps = 0
-            if alldeps == 1:
+                    alldeps = False
+                    break
+            if alldeps:
                 self.setbuildable(revdep)
-                fn = fn_from_tid(revdep)
-                taskname = taskname_from_tid(revdep)
                 logger.debug(1, "Marking task %s as buildable", revdep)
 
     def task_complete(self, task):
@@ -1896,8 +1916,8 @@ class RunQueueExecuteTasks(RunQueueExecute):
         self.setbuildable(task)
         bb.event.fire(runQueueTaskSkipped(task, self.stats, self.rq, reason), self.cfgData)
         self.task_completeoutright(task)
-        self.stats.taskCompleted()
         self.stats.taskSkipped()
+        self.stats.taskCompleted()
 
     def execute(self):
         """
@@ -2342,8 +2362,8 @@ class RunQueueExecuteScenequeue(RunQueueExecute):
     def task_failoutright(self, task):
         self.runq_running.add(task)
         self.runq_buildable.add(task)
-        self.stats.taskCompleted()
         self.stats.taskSkipped()
+        self.stats.taskCompleted()
         self.scenequeue_notcovered.add(task)
         self.scenequeue_updatecounters(task, True)
 
@@ -2351,8 +2371,8 @@ class RunQueueExecuteScenequeue(RunQueueExecute):
         self.runq_running.add(task)
         self.runq_buildable.add(task)
         self.task_completeoutright(task)
-        self.stats.taskCompleted()
         self.stats.taskSkipped()
+        self.stats.taskCompleted()
 
     def execute(self):
         """

bitbake/lib/bb/server/process.py

@@ -377,11 +377,12 @@ class BitBakeServer(object):
         if os.path.exists(sockname):
             os.unlink(sockname)
 
+        # Place the log in the builddirectory alongside the lock file
+        logfile = os.path.join(os.path.dirname(self.bitbake_lock.name), "bitbake-cookerdaemon.log")
+
         self.sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
         # AF_UNIX has path length issues so chdir here to workaround
         cwd = os.getcwd()
-        logfile = os.path.join(cwd, "bitbake-cookerdaemon.log")
-
         try:
             os.chdir(os.path.dirname(sockname))
             self.sock.bind(os.path.basename(sockname))

bitbake/lib/bb/siggen.py

@@ -347,7 +347,7 @@ class SignatureGeneratorBasicHash(SignatureGeneratorBasic):
 
     def stampcleanmask(self, stampbase, fn, taskname, extrainfo):
         return self.stampfile(stampbase, fn, taskname, extrainfo, clean=True)
-        
+
     def invalidate_task(self, task, d, fn):
         bb.note("Tainting hash to force rebuild of task %s, %s" % (fn, task))
         bb.build.write_taint(task, d, fn)
@@ -636,7 +636,7 @@ def compare_sigfiles(a, b, recursecb=None, color=False, collapsed=False):
                         if collapsed:
                             output.extend(recout)
                         else:
-                            # If a dependent hash changed, might as well print the line above and then defer to the changes in 
+                            # If a dependent hash changed, might as well print the line above and then defer to the changes in
                             # that hash since in all likelyhood, they're the same changes this task also saw.
                             output = [output[-1]] + recout
 

bitbake/lib/bb/tests/fetch.py

@@ -402,6 +402,12 @@ class MirrorUriTest(FetcherTest):
             : "git://somewhere.org/somedir/mtd-utils.git;tag=1234567890123456789012345678901234567890;protocol=http", 
         ("git://git.invalid.infradead.org/foo/mtd-utils.git;tag=1234567890123456789012345678901234567890", "git://.*/.*", "git://somewhere.org/somedir/MIRRORNAME;protocol=http") 
             : "git://somewhere.org/somedir/git.invalid.infradead.org.foo.mtd-utils.git;tag=1234567890123456789012345678901234567890;protocol=http", 
+        ("http://somewhere.org/somedir1/somedir2/somefile_1.2.3.tar.gz", "http://.*/.*", "http://somewhere2.org")
+            : "http://somewhere2.org/somefile_1.2.3.tar.gz",
+        ("http://somewhere.org/somedir1/somedir2/somefile_1.2.3.tar.gz", "http://.*/.*", "http://somewhere2.org/")
+            : "http://somewhere2.org/somefile_1.2.3.tar.gz",
+        ("git://someserver.org/bitbake;tag=1234567890123456789012345678901234567890;branch=master", "git://someserver.org/bitbake;branch=master", "git://git.openembedded.org/bitbake;protocol=http")
+            : "git://git.openembedded.org/bitbake;tag=1234567890123456789012345678901234567890;branch=master;protocol=http",
 
         #Renaming files doesn't work
         #("http://somewhere.org/somedir1/somefile_1.2.3.tar.gz", "http://somewhere.org/somedir1/somefile_1.2.3.tar.gz", "http://somewhere2.org/somedir3/somefile_2.3.4.tar.gz") : "http://somewhere2.org/somedir3/somefile_2.3.4.tar.gz"
@@ -832,7 +838,7 @@ class URLHandle(unittest.TestCase):
     # decodeurl and we need to handle them
     decodedata = datatable.copy()
     decodedata.update({
-       "http://somesite.net;someparam=1": ('http', 'somesite.net', '', '', '', {'someparam': '1'}),
+       "http://somesite.net;someparam=1": ('http', 'somesite.net', '/', '', '', {'someparam': '1'}),
     })
 
     def test_decodeurl(self):

bitbake/lib/bb/utils.py

@@ -807,8 +807,8 @@ def movefile(src, dest, newmtime = None, sstat = None):
                 return None # failure
         try:
             if didcopy:
-                os.lchown(dest, sstat[stat.ST_UID], sstat[stat.ST_GID])
-                os.chmod(dest, stat.S_IMODE(sstat[stat.ST_MODE])) # Sticky is reset on chown
+                os.lchown(destpath, sstat[stat.ST_UID], sstat[stat.ST_GID])
+                os.chmod(destpath, stat.S_IMODE(sstat[stat.ST_MODE])) # Sticky is reset on chown
                 os.unlink(src)
         except Exception as e:
             print("movefile: Failed to chown/chmod/unlink", dest, e)

bitbake/lib/toaster/orm/fixtures/oe-core.xml

@@ -8,9 +8,9 @@
 
   <!-- Bitbake versions which correspond to the metadata release -->
   <object model="orm.bitbakeversion" pk="1">
-    <field type="CharField" name="name">rocko</field>
+    <field type="CharField" name="name">sumo</field>
     <field type="CharField" name="giturl">git://git.openembedded.org/bitbake</field>
-    <field type="CharField" name="branch">1.36</field>
+    <field type="CharField" name="branch">1.38</field>
   </object>
   <object model="orm.bitbakeversion" pk="2">
     <field type="CharField" name="name">HEAD</field>
@@ -22,14 +22,19 @@
     <field type="CharField" name="giturl">git://git.openembedded.org/bitbake</field>
     <field type="CharField" name="branch">master</field>
   </object>
+  <object model="orm.bitbakeversion" pk="4">
+    <field type="CharField" name="name">rocko</field>
+    <field type="CharField" name="giturl">git://git.openembedded.org/bitbake</field>
+    <field type="CharField" name="branch">1.36</field>
+  </object>
 
   <!-- Releases available -->
   <object model="orm.release" pk="1">
     <field type="CharField" name="name">rocko</field>
-    <field type="CharField" name="description">Openembedded Rocko</field>
+    <field type="CharField" name="description">Openembedded Sumo</field>
     <field rel="ManyToOneRel" to="orm.bitbakeversion" name="bitbake_version">1</field>
-    <field type="CharField" name="branch_name">rocko</field>
-    <field type="TextField" name="helptext">Toaster will run your builds using the tip of the &lt;a href=\"http://cgit.openembedded.org/openembedded-core/log/?h=rocko\"&gt;OpenEmbedded Rocko&lt;/a&gt; branch.</field>
+    <field type="CharField" name="branch_name">sumo</field>
+    <field type="TextField" name="helptext">Toaster will run your builds using the tip of the &lt;a href=\"http://cgit.openembedded.org/openembedded-core/log/?h=sumo\"&gt;OpenEmbedded Sumo&lt;/a&gt; branch.</field>
   </object>
   <object model="orm.release" pk="2">
     <field type="CharField" name="name">local</field>
@@ -45,6 +50,13 @@
     <field type="CharField" name="branch_name">master</field>
     <field type="TextField" name="helptext">Toaster will run your builds using the tip of the &lt;a href=\"http://cgit.openembedded.org/openembedded-core/log/\"&gt;OpenEmbedded master&lt;/a&gt; branch.</field>
   </object>
+  <object model="orm.release" pk="4">
+    <field type="CharField" name="name">rocko</field>
+    <field type="CharField" name="description">Openembedded Rocko</field>
+    <field rel="ManyToOneRel" to="orm.bitbakeversion" name="bitbake_version">1</field>
+    <field type="CharField" name="branch_name">rocko</field>
+    <field type="TextField" name="helptext">Toaster will run your builds using the tip of the &lt;a href=\"http://cgit.openembedded.org/openembedded-core/log/?h=rocko\"&gt;OpenEmbedded Rocko&lt;/a&gt; branch.</field>
+  </object>
 
   <!-- Default layers for each release -->
   <object model="orm.releasedefaultlayer" pk="1">
@@ -59,6 +71,10 @@
     <field rel="ManyToOneRel" to="orm.release" name="release">3</field>
     <field type="CharField" name="layer_name">openembedded-core</field>
   </object>
+  <object model="orm.releasedefaultlayer" pk="4">
+    <field rel="ManyToOneRel" to="orm.release" name="release">4</field>
+    <field type="CharField" name="layer_name">openembedded-core</field>
+  </object>
 
 
   <!-- Layer for the Local release -->

bitbake/lib/toaster/orm/fixtures/poky.xml

@@ -8,9 +8,9 @@
 
   <!-- Bitbake versions which correspond to the metadata release -->
   <object model="orm.bitbakeversion" pk="1">
-    <field type="CharField" name="name">rocko</field>
+    <field type="CharField" name="name">sumo</field>
     <field type="CharField" name="giturl">git://git.yoctoproject.org/poky</field>
-    <field type="CharField" name="branch">rocko</field>
+    <field type="CharField" name="branch">sumo</field>
     <field type="CharField" name="dirpath">bitbake</field>
   </object>
   <object model="orm.bitbakeversion" pk="2">
@@ -25,15 +25,21 @@
     <field type="CharField" name="branch">master</field>
     <field type="CharField" name="dirpath">bitbake</field>
   </object>
+  <object model="orm.bitbakeversion" pk="4">
+    <field type="CharField" name="name">rocko</field>
+    <field type="CharField" name="giturl">git://git.yoctoproject.org/poky</field>
+    <field type="CharField" name="branch">rocko</field>
+    <field type="CharField" name="dirpath">bitbake</field>
+  </object>
 
 
   <!-- Releases available -->
   <object model="orm.release" pk="1">
-    <field type="CharField" name="name">rocko</field>
-    <field type="CharField" name="description">Yocto Project 2.4 "Rocko"</field>
+    <field type="CharField" name="name">sumo</field>
+    <field type="CharField" name="description">Yocto Project 2.5 "Sumo"</field>
     <field rel="ManyToOneRel" to="orm.bitbakeversion" name="bitbake_version">1</field>
-    <field type="CharField" name="branch_name">rocko</field>
-    <field type="TextField" name="helptext">Toaster will run your builds using the tip of the &lt;a href="http://git.yoctoproject.org/cgit/cgit.cgi/poky/log/?h=rocko"&gt;Yocto Project Rocko branch&lt;/a&gt;.</field>
+    <field type="CharField" name="branch_name">sumo</field>
+    <field type="TextField" name="helptext">Toaster will run your builds using the tip of the &lt;a href="http://git.yoctoproject.org/cgit/cgit.cgi/poky/log/?h=sumo"&gt;Yocto Project Sumo branch&lt;/a&gt;.</field>
   </object>
   <object model="orm.release" pk="2">
     <field type="CharField" name="name">local</field>
@@ -49,6 +55,13 @@
     <field type="CharField" name="branch_name">master</field>
     <field type="TextField" name="helptext">Toaster will run your builds using the tip of the &lt;a href="http://git.yoctoproject.org/cgit/cgit.cgi/poky/log/"&gt;Yocto Project Master branch&lt;/a&gt;.</field>
   </object>
+  <object model="orm.release" pk="4">
+    <field type="CharField" name="name">rocko</field>
+    <field type="CharField" name="description">Yocto Project 2.4 "Rocko"</field>
+    <field rel="ManyToOneRel" to="orm.bitbakeversion" name="bitbake_version">1</field>
+    <field type="CharField" name="branch_name">rocko</field>
+    <field type="TextField" name="helptext">Toaster will run your builds using the tip of the &lt;a href="http://git.yoctoproject.org/cgit/cgit.cgi/poky/log/?h=rocko"&gt;Yocto Project Rocko branch&lt;/a&gt;.</field>
+  </object>
 
   <!-- Default project layers for each release -->
   <object model="orm.releasedefaultlayer" pk="1">
@@ -87,6 +100,18 @@
     <field rel="ManyToOneRel" to="orm.release" name="release">3</field>
     <field type="CharField" name="layer_name">meta-yocto-bsp</field>
   </object>
+  <object model="orm.releasedefaultlayer" pk="10">
+    <field rel="ManyToOneRel" to="orm.release" name="release">4</field>
+    <field type="CharField" name="layer_name">openembedded-core</field>
+  </object>
+  <object model="orm.releasedefaultlayer" pk="11">
+    <field rel="ManyToOneRel" to="orm.release" name="release">4</field>
+    <field type="CharField" name="layer_name">meta-poky</field>
+  </object>
+  <object model="orm.releasedefaultlayer" pk="12">
+    <field rel="ManyToOneRel" to="orm.release" name="release">4</field>
+    <field type="CharField" name="layer_name">meta-yocto-bsp</field>
+  </object>
 
   <!-- Default layers provided by poky
        openembedded-core
@@ -105,7 +130,7 @@
     <field rel="ManyToOneRel" to="orm.layer" name="layer">1</field>
     <field type="IntegerField" name="layer_source">0</field>
     <field rel="ManyToOneRel" to="orm.release" name="release">1</field>
-    <field type="CharField" name="branch">rocko</field>
+    <field type="CharField" name="branch">sumo</field>
     <field type="CharField" name="dirpath">meta</field>
   </object>
   <object model="orm.layer_version" pk="2">
@@ -123,6 +148,13 @@
     <field type="CharField" name="branch">master</field>
     <field type="CharField" name="dirpath">meta</field>
   </object>
+  <object model="orm.layer_version" pk="4">
+    <field rel="ManyToOneRel" to="orm.layer" name="layer">1</field>
+    <field type="IntegerField" name="layer_source">0</field>
+    <field rel="ManyToOneRel" to="orm.release" name="release">4</field>
+    <field type="CharField" name="branch">rocko</field>
+    <field type="CharField" name="dirpath">meta</field>
+  </object>
 
   <object model="orm.layer" pk="2">
     <field type="CharField" name="name">meta-poky</field>
@@ -132,14 +164,14 @@
     <field type="CharField" name="vcs_web_tree_base_url">http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/%path%?h=%branch%</field>
     <field type="CharField" name="vcs_web_file_base_url">http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/%path%?h=%branch%</field>
   </object>
-  <object model="orm.layer_version" pk="4">
+  <object model="orm.layer_version" pk="5">
     <field rel="ManyToOneRel" to="orm.layer" name="layer">2</field>
     <field type="IntegerField" name="layer_source">0</field>
     <field rel="ManyToOneRel" to="orm.release" name="release">1</field>
-    <field type="CharField" name="branch">rocko</field>
+    <field type="CharField" name="branch">sumo</field>
     <field type="CharField" name="dirpath">meta-poky</field>
   </object>
-  <object model="orm.layer_version" pk="5">
+  <object model="orm.layer_version" pk="6">
     <field rel="ManyToOneRel" to="orm.layer" name="layer">2</field>
     <field type="IntegerField" name="layer_source">0</field>
     <field rel="ManyToOneRel" to="orm.release" name="release">2</field>
@@ -147,13 +179,20 @@
     <field type="CharField" name="commit">HEAD</field>
     <field type="CharField" name="dirpath">meta-poky</field>
   </object>
-  <object model="orm.layer_version" pk="6">
+  <object model="orm.layer_version" pk="7">
     <field rel="ManyToOneRel" to="orm.layer" name="layer">2</field>
     <field type="IntegerField" name="layer_source">0</field>
     <field rel="ManyToOneRel" to="orm.release" name="release">3</field>
     <field type="CharField" name="branch">master</field>
     <field type="CharField" name="dirpath">meta-poky</field>
   </object>
+  <object model="orm.layer_version" pk="8">
+    <field rel="ManyToOneRel" to="orm.layer" name="layer">2</field>
+    <field type="IntegerField" name="layer_source">0</field>
+    <field rel="ManyToOneRel" to="orm.release" name="release">4</field>
+    <field type="CharField" name="branch">rocko</field>
+    <field type="CharField" name="dirpath">meta-poky</field>
+  </object>
 
   <object model="orm.layer" pk="3">
     <field type="CharField" name="name">meta-yocto-bsp</field>
@@ -163,14 +202,14 @@
     <field type="CharField" name="vcs_web_tree_base_url">http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/%path%?h=%branch%</field>
     <field type="CharField" name="vcs_web_file_base_url">http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/%path%?h=%branch%</field>
   </object>
-  <object model="orm.layer_version" pk="7">
+  <object model="orm.layer_version" pk="9">
     <field rel="ManyToOneRel" to="orm.layer" name="layer">3</field>
     <field type="IntegerField" name="layer_source">0</field>
     <field rel="ManyToOneRel" to="orm.release" name="release">1</field>
-    <field type="CharField" name="branch">rocko</field>
+    <field type="CharField" name="branch">sumo</field>
     <field type="CharField" name="dirpath">meta-yocto-bsp</field>
   </object>
-  <object model="orm.layer_version" pk="8">
+  <object model="orm.layer_version" pk="10">
     <field rel="ManyToOneRel" to="orm.layer" name="layer">3</field>
     <field type="IntegerField" name="layer_source">0</field>
     <field rel="ManyToOneRel" to="orm.release" name="release">2</field>
@@ -178,11 +217,18 @@
     <field type="CharField" name="commit">HEAD</field>
     <field type="CharField" name="dirpath">meta-yocto-bsp</field>
   </object>
-  <object model="orm.layer_version" pk="9">
+  <object model="orm.layer_version" pk="11">
     <field rel="ManyToOneRel" to="orm.layer" name="layer">3</field>
     <field type="IntegerField" name="layer_source">0</field>
     <field rel="ManyToOneRel" to="orm.release" name="release">3</field>
     <field type="CharField" name="branch">master</field>
     <field type="CharField" name="dirpath">meta-yocto-bsp</field>
   </object>
+  <object model="orm.layer_version" pk="12">
+    <field rel="ManyToOneRel" to="orm.layer" name="layer">3</field>
+    <field type="IntegerField" name="layer_source">0</field>
+    <field rel="ManyToOneRel" to="orm.release" name="release">4</field>
+    <field type="CharField" name="branch">rocko</field>
+    <field type="CharField" name="dirpath">meta-yocto-bsp</field>
+  </object>
 </django-objects>

documentation/Makefile

@@ -48,7 +48,7 @@
 # Examples:
 #
 #     make DOC=bsp-guide
-#     make html DOC=yocto-project-qs
+#     make html DOC=brief-yoctoprojectqs
 #     make pdf DOC=ref-manual
 #     make DOC=dev-manual BRANCH=edison
 #     make DOC=mega-manual BRANCH=denzil
@@ -56,7 +56,7 @@
 # The first example generates the HTML and Eclipse help versions of the BSP Guide.
 # The second example generates the HTML version only of the Quick Start.  Note
 # that the Quick Start only has an HTML version available.  So, the
-# 'make DOC=yocto-project-qs' command would be equivalent. The third example
+# 'make DOC=brief-yoctoprojectqs' 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 Tasks Manual.  The last example
@@ -90,8 +90,8 @@ XSLTOPTS = --stringparam html.stylesheet brief-yoctoprojectqs-style.css \
            --stringparam  section.autolabel 0 \
            --stringparam  section.label.includes.component.label 0 \
            --xinclude
-ALLPREQ = html tarball
-TARFILES = brief-yoctoprojectqs-style.css brief-yoctoprojectqs.html figures/ypqs-title.png \
+ALLPREQ = html eclipse tarball
+TARFILES = brief-yoctoprojectqs-style.css brief-yoctoprojectqs.html figures/bypqs-title.png \
            figures/yocto-project-transp.png
 MANUALS = $(DOC)/$(DOC).html $(DOC)/eclipse
 FIGURES = figures
@@ -99,25 +99,13 @@ STYLESHEET = $(DOC)/*.css
 
 endif
 
-ifeq ($(DOC),getting-started)
+ifeq ($(DOC),overview-manual)
 XSLTOPTS = --xinclude
 ALLPREQ = html eclipse tarball
-TARFILES = getting-started-style.css getting-started.html figures/getting-started-title.png \
+TARFILES = overview-manual-style.css overview-manual.html figures/overview-manual-title.png \
            figures/git-workflow.png figures/source-repos.png figures/index-downloads.png \
            figures/yp-download.png figures/YP-flow-diagram.png figures/key-dev-elements.png \
-           figures/poky-reference-distribution.png \
-           eclipse
-MANUALS = $(DOC)/$(DOC).html $(DOC)/eclipse
-FIGURES = figures
-STYLESHEET = $(DOC)/*.css
-
-endif
-
-ifeq ($(DOC),concepts-manual)
-XSLTOPTS = --xinclude
-ALLPREQ = html eclipse tarball
-TARFILES = concepts-manual-style.css concepts-manual.html figures/concepts-manual-title.png \
-           figures/cross-development-toolchains.png figures/yocto-environment-ref.png \
+           figures/poky-reference-distribution.png figures/cross-development-toolchains.png \
            figures/user-configuration.png figures/layer-input.png figures/source-input.png \
            figures/package-feeds.png figures/patching.png figures/source-fetching.png \
            figures/configuration-compile-autoreconf.png figures/analysis-for-package-splitting.png \
@@ -186,22 +174,6 @@ STYLESHEET = $(DOC)/*.css
 
 endif
 
-ifeq ($(DOC),yocto-project-qs)
-XSLTOPTS = --stringparam html.stylesheet qs-style.css \
-           --stringparam  chapter.autolabel 1 \
-           --stringparam  section.autolabel 1 \
-           --stringparam  section.label.includes.component.label 1 \
-           --xinclude
-ALLPREQ = html eclipse tarball
-
-TARFILES = yocto-project-qs.html qs-style.css \
-           figures/yocto-project-transp.png figures/ypqs-title.png \
-           eclipse
-MANUALS = $(DOC)/$(DOC).html $(DOC)/eclipse
-FIGURES = figures
-STYLESHEET = $(DOC)/*.css
-endif
-
 ifeq ($(DOC),mega-manual)
 XSLTOPTS = --stringparam html.stylesheet mega-style.css \
            --stringparam  chapter.autolabel 1 \
@@ -280,7 +252,7 @@ TARFILES = mega-manual.html mega-style.css \
         figures/sched-wakeup-profile.png figures/sysprof-callers.png \
         figures/sysprof-copy-from-user.png figures/sysprof-copy-to-user.png \
         figures/cross-development-toolchains.png \
-	figures/yocto-environment-ref.png figures/user-configuration.png \
+	figures/user-configuration.png \
         figures/source-input.png figures/package-feeds.png \
         figures/layer-input.png figures/images.png figures/sdk.png \
 	figures/source-fetching.png figures/patching.png \
@@ -295,8 +267,8 @@ TARFILES = mega-manual.html mega-style.css \
 	figures/sdk-environment.png figures/sdk-installed-standard-sdk-directory.png \
 	figures/sdk-devtool-add-flow.png figures/sdk-installed-extensible-sdk-directory.png \
 	figures/sdk-devtool-modify-flow.png figures/sdk-eclipse-dev-flow.png \
-	figures/sdk-devtool-upgrade-flow.png figures/bitbake-build-flow.png figures/ypqs-title.png \
-	figures/getting-started-title.png figures/concepts-manual-title.png
+	figures/sdk-devtool-upgrade-flow.png figures/bitbake-build-flow.png figures/bypqs-title.png \
+	figures/overview-manual-title.png figures/sdk-autotools-flow.png figures/sdk-makefile-flow.png
 	endif
 
 MANUALS = $(DOC)/$(DOC).html
@@ -323,7 +295,7 @@ TARFILES = sdk-manual.html sdk-style.css figures/sdk-title.png \
            figures/sdk-environment.png figures/sdk-installed-standard-sdk-directory.png \
 	   figures/sdk-installed-extensible-sdk-directory.png figures/sdk-devtool-add-flow.png \
 	   figures/sdk-devtool-modify-flow.png figures/sdk-eclipse-dev-flow.png \
-	   figures/sdk-devtool-upgrade-flow.png \
+	   figures/sdk-devtool-upgrade-flow.png figures/sdk-autotools-flow.png figures/sdk-makefile-flow.png \
            eclipse
 MANUALS = $(DOC)/$(DOC).html $(DOC)/eclipse
 FIGURES = figures
@@ -399,9 +371,9 @@ XSL_XHTML_URI = $(XSL_BASE_URI)/xhtml/docbook.xsl
 all: $(ALLPREQ)
 
 pdf:
-ifeq ($(DOC),yocto-project-qs brief-yoctoprojectqs)
+ifeq ($(DOC),brief-yoctoprojectqs)
 	@echo " "
-	@echo "ERROR: You cannot generate yocto-project-qs or brief-yoctoprojectqs PDF files."
+	@echo "ERROR: You cannot generate a PDF file for brief-yoctoprojectqs."
 	@echo " "
 
 else ifeq ($(DOC),mega-manual)
@@ -445,19 +417,18 @@ eclipse: eclipse-generate eclipse-resolve-links
 .PHONY : eclipse-generate eclipse-resolve-links
 
 eclipse-generate:
-ifeq ($(filter $(DOC), concepts-manual getting-started sdk-manual bsp-guide dev-manual kernel-dev profile-manual ref-manual yocto-project-qs),)
+ifeq ($(filter $(DOC), overview-manual sdk-manual bsp-guide dev-manual kernel-dev profile-manual ref-manual brief-yoctoprojectqs),)
 	@echo " "
 	@echo "ERROR: You can only create eclipse documentation"
 	@echo "       of the following documentation parts:"
-	@echo "       - concepts-manual"
-	@echo "       - getting-started"
+	@echo "       - overview-manual"
 	@echo "       - sdk-manual"
 	@echo "       - bsp-guide"
 	@echo "       - dev-manual"
 	@echo "       - kernel-dev"
 	@echo "       - profile-manual"
 	@echo "       - ref-manual"
-	@echo "       - yocto-project-qs"
+	@echo "       - brief-yoctoprojectqs"
 	@echo " "
 else
 	@echo " "

documentation/brief-yoctoprojectqs/brief-yoctoprojectqs-eclipse-customization.xsl

@@ -16,13 +16,13 @@
 
 -->
 
-  <xsl:import href="yocto-project-qs-titlepage.xsl"/>
+  <xsl:import href="brief-yoctoprojectqs-titlepage.xsl"/>
 
   <xsl:param name="chunker.output.indent" select="'yes'"/>
   <xsl:param name="chunk.quietly" select="1"/>
   <xsl:param name="use.id.as.filename" select="1"/>
   <xsl:param name="ulink.target" select="'_self'" />
-  <xsl:param name="base.dir" select="'html/yocto-project-qs/'"/>
+  <xsl:param name="base.dir" select="'html/brief-yoctoprojectqs/'"/>
   <xsl:param name="chunk.section.depth" select="0"/>
   <xsl:param name="html.stylesheet" select="'../book.css'"/>
   <xsl:param name="eclipse.manifest" select="0"/>
@@ -32,3 +32,4 @@
   <xsl:param name="generate.toc" select="'article nop'"></xsl:param>
   <xsl:param name="html.stylesheet" select="'style.css'" />
 </xsl:stylesheet>
+

documentation/brief-yoctoprojectqs/brief-yoctoprojectqs-style.css

@@ -118,7 +118,7 @@ h6 {
   background-color: transparent;
   background-repeat: no-repeat;
   padding-top: 256px;
-  background-image: url("figures/ypqs-title.png");
+  background-image: url("figures/bypqs-title.png");
   background-position: left top;
   margin-top: -256px;
   padding-right: 50px;

documentation/brief-yoctoprojectqs/brief-yoctoprojectqs.xml

@@ -4,7 +4,7 @@
 
 <article id='brief-yocto-project-qs-intro'>
     <articleinfo>
-        <title>My First Yocto Project Build</title>
+        <title>Yocto Project Quick Build</title>
 
         <copyright>
             <year>&COPYRIGHT_YEAR;</year>
@@ -16,28 +16,6 @@
                 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 this document associated with
-                        this Yocto Project release
-                        (version &YOCTO_DOC_VERSION;), see the "My First
-                        Yocto Project Build" from the
-                        <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink>.
-                        </para></listitem>
-                    <listitem><para>
-                        This paper is written for the &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>
-                </itemizedlist>
-            </note>
--->
         </legalnotice>
 
 
@@ -55,6 +33,8 @@
             Welcome!
             This short document steps you through the process for a typical
             image build using the Yocto Project.
+            The document also introduces how to configure a build for specific
+            hardware.
             You will use Yocto Project to build a reference embedded OS
             called Poky.
             <note>
@@ -74,7 +54,7 @@
         <para>
             If you want more conceptual or background information on the
             Yocto Project, see the
-            <ulink url='&YOCTO_DOCS_GS_URL;'>Getting Started With Yocto Project Manual</ulink>.
+            <ulink url='&YOCTO_DOCS_OM_URL;'>Yocto Project Overview and Concepts Manual</ulink>.
         </para>
     </section>
 
@@ -82,7 +62,9 @@
         <title>Compatible Linux Distribution</title>
 
         <para>
-            Make sure your build system meets the following requirements:
+            Make sure your
+            <ulink url='&YOCTO_DOCS_REF_URL;#hardware-build-system-term'>build host</ulink>
+            meets the following requirements:
             <itemizedlist>
                 <listitem><para>
                     50 Gbytes of free disk space
@@ -118,11 +100,11 @@
     </section>
 
     <section id='brief-build-system-packages'>
-        <title>Build System Packages</title>
+        <title>Build Host Packages</title>
 
         <para>
             You must install essential host packages on your
-            development host.
+            build host.
             The following command installs the host packages based on an
             Ubuntu distribution:
             <note>
@@ -143,7 +125,7 @@
         <para>
             Once you complete the setup instructions for your machine,
             you need to get a copy of the Poky repository on your build
-            system.
+            host.
             Use the following commands to clone the Poky
             repository and then checkout the &DISTRO_REL_TAG; release:
             <literallayout class='monospaced'>
@@ -167,7 +149,7 @@
         <para>
             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>"
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#locating-yocto-project-source-files'>Locating Yocto Project Source Files</ulink>"
             section in the Yocto Project Development Tasks Manual.
         </para>
     </section>
@@ -177,8 +159,8 @@
 
         <para>
             Use the following steps to build your image.
-            The OpenEmbedded build system creates an entire Linux
-            distribution, including the toolchain, from source.
+            The build process creates an entire Linux distribution, including
+            the toolchain, from source.
             <note>
                 <itemizedlist>
                     <listitem><para>
@@ -207,7 +189,7 @@
                     <emphasis>Initialize the Build Environment:</emphasis>
                     Run the
                     <ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>
-                    environment setup script to define the OpenEmbedded
+                    environment setup script to define Yocto Project's
                     build environment on your build host.
                     <literallayout class='monospaced'>
      $ source &OE_INIT_FILE;
@@ -222,7 +204,7 @@
                     Later, when the build completes, the Build Directory
                     contains all the files created during the build.
                     </para></listitem>
-                <listitem><para>
+                <listitem><para id='conf-file-step'>
                     <emphasis>Examine Your Local Configuration File:</emphasis>
                     When you set up the build environment, a local
                     configuration file named
@@ -243,13 +225,13 @@
                         <literallayout class='monospaced'>
      SSTATE_MIRRORS = "\
      file://.* http://sstate.yoctoproject.org/dev/PATH;downloadfilename=PATH \n \
-     file://.* http://sstate.yoctoproject.org/2.3/PATH;downloadfilename=PATH \n \
-     file://.* http://sstate.yoctoproject.org/2.4/PATH;downloadfilename=PATH \n \
+     file://.* http://sstate.yoctoproject.org/&YOCTO_DOC_VERSION_MINUS_ONE;/PATH;downloadfilename=PATH \n \
+     file://.* http://sstate.yoctoproject.org/&YOCTO_DOC_VERSION;/PATH;downloadfilename=PATH \n \
      "
                         </literallayout>
                         The previous examples showed how to add sstate
-                        paths for Yocto Project 2.3, 2.4, and a development
-                        area.
+                        paths for Yocto Project &YOCTO_DOC_VERSION_MINUS_ONE;,
+                        &YOCTO_DOC_VERSION;, and a development area.
                         For a complete index of sstate locations, see
                         <ulink url='http://sstate.yoctoproject.org/'></ulink>.
                     </tip>
@@ -264,9 +246,9 @@
                     </literallayout>
                     For information on using the
                     <filename>bitbake</filename> command, see the
-                    "<ulink url='&YOCTO_DOCS_OVERVIEW_URL;#usingpoky-components-bitbake'>BitBake</ulink>"
-                    section in the Yocto Project Overview Manual, or
-                    see the
+                    "<ulink url='&YOCTO_DOCS_OM_URL;#usingpoky-components-bitbake'>BitBake</ulink>"
+                    section in the Yocto Project Overview and Concepts Manual,
+                    or see the
                     "<ulink url='&YOCTO_DOCS_BB_URL;#bitbake-user-manual-command'>BitBake Command</ulink>"
                     section in the BitBake User Manual.
                     </para></listitem>
@@ -292,6 +274,147 @@
         </para>
     </section>
 
+    <section id='customizing-your-build-for-specific-hardware'>
+        <title>Customizing Your Build for Specific Hardware</title>
+
+        <para>
+            So far, all you have done is quickly built an image suitable
+            for emulation only.
+            This section shows you how to customize your build for specific
+            hardware by adding a hardware layer into the Yocto Project
+            development environment.
+        </para>
+
+        <para>
+            In general, layers are repositories that contain related sets of
+            instructions and configurations that tell the Yocto Project what
+            to do.
+            Isolating related metadata into functionally specific layers
+            facilitates modular development and makes it easier to reuse the
+            layer metadata.
+            <note>
+                By convention, layer names start with the string "meta-".
+            </note>
+        </para>
+
+        <para>
+            Follow these steps to add a hardware layer:
+            <orderedlist>
+                <listitem><para>
+                    <emphasis>Find a Layer:</emphasis>
+                    Lots of hardware layers exist.
+                    The Yocto Project
+                    <ulink url='&YOCTO_GIT_URL;'>Source Repositories</ulink>
+                    has many hardware layers.
+                    This example adds the
+                    <ulink url='https://github.com/kraj/meta-altera'>meta-altera</ulink>
+                    hardware layer.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis>Clone the Layer</emphasis>
+                    Use Git to make a local copy of the layer on your machine.
+                    You can put the copy in the top level of the copy of the
+                    Poky repository created earlier:
+                    <literallayout class='monospaced'>
+     $ cd ~/poky
+     $ git clone https://github.com/kraj/meta-altera.git
+     Cloning into 'meta-altera'...
+     remote: Counting objects: 25170, done.
+     remote: Compressing objects: 100% (350/350), done.
+     remote: Total 25170 (delta 645), reused 719 (delta 538), pack-reused 24219
+     Receiving objects: 100% (25170/25170), 41.02 MiB | 1.64 MiB/s, done.
+     Resolving deltas: 100% (13385/13385), done.
+     Checking connectivity... done.
+                    </literallayout>
+                    The hardware layer now exists with other layers inside
+                    the Poky reference repository on your build host as
+                    <filename>meta-altera</filename> and contains all the
+                    metadata needed to support hardware from Altera, which
+                    is owned by Intel.
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis>Change the Configuration to Build for a Specific Machine:</emphasis>
+                    The
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink>
+                    variable in the <filename>local.conf</filename> file
+                    specifies the machine for the build.
+                    For this example, set the <filename>MACHINE</filename>
+                    variable to "cyclone5".
+                    These configurations are used:
+                    <ulink url='https://github.com/kraj/meta-altera/blob/master/conf/machine/cyclone5.conf'></ulink>.
+                    <note>
+                        See the
+                        "<link linkend='conf-file-step'>Examine Your Local Configuration File</link>"
+                        step earlier for more information on configuring the
+                        build.
+                    </note>
+                    </para></listitem>
+                <listitem><para>
+                    <emphasis>Add Your Layer to the Layer Configuration File:</emphasis>
+                    Before you can use a layer during a build, you must add it
+                    to your <filename>bblayers.conf</filename> file, which
+                    is found in the
+                    <ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory's</ulink>
+                    <filename>conf</filename> directory.</para>
+
+                    <para>Use the <filename>bitbake-layers add-layer</filename>
+                    command to add the layer to the configuration file:
+                    <literallayout class='monospaced'>
+     $ cd ~/poky/build
+     $ bitbake-layers add-layer ../meta-altera
+     NOTE: Starting bitbake server...
+     Parsing recipes: 100% |##################################################################| Time: 0:00:32
+     Parsing of 918 .bb files complete (0 cached, 918 parsed). 1401 targets, 123 skipped, 0 masked, 0 errors.
+                    </literallayout>
+                    You can find more information on adding layers in the
+                    "<ulink url='&YOCTO_DOCS_DEV_URL;#adding-a-layer-using-the-bitbake-layers-script'>Adding a Layer Using the <filename>bitbake-layers</filename> Script</ulink>"
+                    section.
+                    </para></listitem>
+            </orderedlist>
+            Completing these steps has added the
+            <filename>meta-altera</filename> layer to your Yocto Project
+            development environment and configured it to build for the
+            "cyclone5" machine.
+            <note>
+                The previous steps are for demonstration purposes only.
+                If you were to attempt to build an image for the
+                "cyclone5" build, you should read the Altera
+                <filename>README</filename>.
+            </note>
+        </para>
+    </section>
+
+    <section id='creating-your-own-general-layer'>
+        <title>Creating Your Own General Layer</title>
+
+        <para>
+            Maybe you have an application or specific set of behaviors you
+            need to isolate.
+            You can create your own general layer using the
+            <filename>bitbake-layers create-layer</filename> command.
+            The tool automates layer creation by setting up a
+            subdirectory with a <filename>layer.conf</filename>
+            configuration file, a <filename>recipes-example</filename>
+            subdirectory that contains an <filename>example.bb</filename>
+            recipe, a licensing file, and a <filename>README</filename>.
+        </para>
+
+        <para>
+            The following commands run the tool to create a layer named
+            <filename>meta-mylayer</filename> in the
+            <filename>poky</filename> directory:
+            <literallayout class='monospaced'>
+     $ cd ~/poky
+     $ bitbake-layers create-layer meta-mylayer
+     NOTE: Starting bitbake server...
+     Add your new layer with 'bitbake-layers add-layer meta-mylayer'
+            </literallayout>
+            For more information on layers and how to create them, 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.
+        </para>
+    </section>
+
     <section id='brief-where-to-go-next'>
         <title>Where To Go Next</title>
 
@@ -321,6 +444,17 @@
                     introductory and fundamental concepts are useful for
                     the beginner.
                     </para></listitem>
+                <listitem><para>
+                    <emphasis>Yocto Project Overview and Concepts Manual:</emphasis>
+                    The
+                    <ulink url='&YOCTO_DOCS_OM_URL;'>Yocto Project Overview and Concepts Manual</ulink>
+                    is a great place to start to learn about the
+                    Yocto Project.
+                    This manual introduces you to the Yocto Project and its
+                    development environment.
+                    The manual also provides conceptual information for
+                    various aspects of the Yocto Project.
+                    </para></listitem>
                 <listitem><para>
                     <emphasis>Yocto Project Wiki:</emphasis>
                     The

documentation/bsp-guide/bsp-guide.xml

@@ -118,9 +118,14 @@
             </revision>
             <revision>
                 <revnumber>2.5</revnumber>
-                <date>April 2018</date>
+                <date>May 2018</date>
                 <revremark>Released with the Yocto Project 2.5 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>2.6</revnumber>
+                <date>&REL_MONTH_YEAR;</date>
+                <revremark>Released with the Yocto Project 2.6 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>
@@ -137,28 +142,40 @@
                <itemizedlist>
                    <listitem><para>
                        This version of the
-                       <emphasis>Yocto Project Board Support Package Developer's Guide</emphasis>
+                       <emphasis>Yocto Project Board Support Package (BSP) 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
+                       for this release, 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.
+                       and select the manual from that site.
+                       Manuals from the site are more up-to-date than manuals
+                       derived from the Yocto Project released TAR files.
                        </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>
+                       If you located this manual through a web search, the
+                       version of the manual might not be the one you want
+                       (e.g. the search might have returned a manual much
+                       older than the Yocto Project version with which you
+                       are working).
+                       You can see all Yocto Project major releases by
+                       visiting the
+                       <ulink url='&YOCTO_WIKI_URL;/wiki/Releases'>Releases</ulink>
+                       page.
+                       If you need a version of this manual for a different
+                       Yocto Project release, visit the
+                       <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink>
+                       and select the manual set by using the
+                       "ACTIVE RELEASES DOCUMENTATION" or "DOCUMENTS ARCHIVE"
+                       pull-down menus.
+                       </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>
                </itemizedlist>
            </note>
     </legalnotice>

documentation/bsp-guide/bsp.xml

@@ -56,9 +56,9 @@
         To help understand the BSP layer concept, consider the BSPs that the
         Yocto Project supports and provides with each release.
         You can see the layers in the
-        <ulink url='&YOCTO_DOCS_GS_URL;#yocto-project-repositories'>Yocto Project Source Repositories</ulink>
+        <ulink url='&YOCTO_DOCS_OM_URL;#yocto-project-repositories'>Yocto Project Source Repositories</ulink>
         through a web interface at
-        <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi'></ulink>.
+        <ulink url='&YOCTO_GIT_URL;'></ulink>.
         If you go to that interface, you will find a list of repositories
         under "Yocto Metadata Layers".
         <note>
@@ -93,8 +93,8 @@
         section.
         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 Tasks Manual.
+        "<ulink url='&YOCTO_DOCS_DEV_URL;#locating-yocto-project-source-files'>Locating Yocto Project Source Files</ulink>"
+        section in the Yocto Project Development Tasks Manual.
     </para>
 
     <para>
@@ -187,7 +187,7 @@
                 <emphasis>Set Up the Build Environment:</emphasis>
                 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>"
+                "<ulink url='&YOCTO_DOCS_DEV_URL;#setting-up-the-development-host-to-use-the-yocto-project'>Preparing the Build Host</ulink>"
                 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.
@@ -340,7 +340,7 @@
         It is also intended that it will be be simple to extract
         information and convert it to other formats if required.
         The OpenEmbedded build system, through its standard
-        <ulink url='&YOCTO_DOCS_GS_URL;#the-yocto-project-layer-model'>layers mechanism</ulink>,
+        <ulink url='&YOCTO_DOCS_OM_URL;#the-yocto-project-layer-model'>layers mechanism</ulink>,
         can directly accept the format described as a layer.
         The BSP layer captures all the hardware-specific details
         in one place using a standard format, which is useful
@@ -953,7 +953,7 @@
         <para>
             You can find more information on what your append file
             should contain in the
-            "<ulink url='&YOCTO_DOCS_KERNEL_URL;#creating-the-append-file'>Creating the Append File</ulink>"
+            "<ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;#creating-the-append-file'>Creating the Append File</ulink>"
             section in the Yocto Project Linux Kernel Development
             Manual.
         </para>
@@ -1012,7 +1012,7 @@
                 to Support Development Using the Yocto
                 Project</emphasis>:
                 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>"
+                "<ulink url='&YOCTO_DOCS_DEV_URL;#setting-up-the-development-host-to-use-the-yocto-project'>Preparing the Build Host</ulink>"
                 section in the Yocto Project Development Tasks
                 Manual for options on how to get a system ready
                 to use the Yocto Project.
@@ -1056,8 +1056,8 @@
                 information for the project that the
                 OpenEmbedded build system knows about.
                 For more information on layers, see the
-                "<ulink url='&YOCTO_DOCS_GS_URL;#the-yocto-project-layer-model'>The Yocto Project Layer Model</ulink>"
-                section in the Getting Started With Yocto Project
+                "<ulink url='&YOCTO_DOCS_OM_URL;#the-yocto-project-layer-model'>The Yocto Project Layer Model</ulink>"
+                section in the Yocto Project Overview and Concepts
                 Manual.
                 You can also reference the
                 "<ulink url='&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers'>Understanding and Creating Layers</ulink>"
@@ -1283,7 +1283,7 @@
                     is found in <filename>poky/meta</filename>
                     directory of the
                     <ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink>
-                    or in the OpenEmbedded Core Layer
+                    or in the OpenEmbedded-Core Layer
                     (<filename>openembedded-core</filename>) at
                     <ulink url='http://git.openembedded.org/openembedded-core/tree/meta'></ulink>.
                     </para>
@@ -1303,7 +1303,7 @@
                     <para>Within any particular
                     <filename>recipes-*</filename> category, the
                     layout should match what is found in the
-                    OpenEmbedded Core Git repository
+                    OpenEmbedded-Core Git repository
                     (<filename>openembedded-core</filename>)
                     or the Source Directory (<filename>poky</filename>).
                     In other words, make sure you place related
@@ -1338,7 +1338,7 @@
                     <filename>meta-</filename><replaceable>bsp_root_name</replaceable>
                     directory.
                     See the
-                    <ulink url='&YOCTO_GIT_URL;/cgit.cgi/meta-raspberrypi/tree/README'><filename>README</filename></ulink>
+                    <ulink url='&YOCTO_GIT_URL;/cgit.cgi/meta-raspberrypi/tree/README.md'><filename>README.md</filename></ulink>
                     file for the Raspberry Pi BSP in the
                     <filename>meta-raspberrypi</filename> BSP layer
                     as an example.</para>
@@ -1507,7 +1507,7 @@
                     its scalability.
                     See the <filename>Yocto Linux Kernel</filename>
                     category in the
-                    <ulink url='&YOCTO_GIT_URL;/cgit.cgi'>Source Repositories</ulink>
+                    <ulink url='&YOCTO_GIT_URL;'>Source Repositories</ulink>
                     for these kernels.
                     </para></listitem>
             </itemizedlist>
@@ -1687,9 +1687,10 @@
                 Thus, the build system can build the corresponding
                 recipe and include the component in the image.
                 See the
-                "<ulink url='&YOCTO_DOCS_CM_URL;#enabling-commercially-licensed-recipes'>Enabling Commercially Licensed Recipes</ulink>"
-                section in the Yocto Project Concepts Manual for
-                details on how to use these variables.</para>
+                "<ulink url='&YOCTO_DOCS_DEV_URL;#enabling-commercially-licensed-recipes'>Enabling Commercially Licensed Recipes</ulink>"
+                section in the Yocto Project Development Tasks
+                Manual for details on how to use these variables.
+                </para>
 
                 <para>If you build as you normally would, without
 	        specifying any recipes in the
@@ -1746,25 +1747,20 @@
     <title>Creating a new BSP Layer Using the <filename>bitbake-layers</filename> Script</title>
 
     <para>
-        [INTRODUCE THE PROCEDURE AND LINK BACK TO <link linkend='bsp-layers'>BSP layer</link>.
-        IF THERE IS A LAUNDRY LIST OF ITEMS THAT NEED DEFINITION OR GET SET
-        UP AS A RESULT OF THIS PROCEDURE, LIST THEM HERE.]
-        <itemizedlist>
-            <listitem><para>[PARAMETER 1]</para></listitem>
-            <listitem><para>[PARAMETER 2]</para></listitem>
-            <listitem><para>[PARAMETER 3]</para></listitem>
-            <listitem><para>[PARAMETER 4]</para></listitem>
-            <listitem><para>[PARAMETER 5]</para></listitem>
-            <listitem><para>[PARAMETER 6]</para></listitem>
-            <listitem><para>[PARAMETER 7]</para></listitem>
-        </itemizedlist>
+        The <filename>bitbake-layers create-layer</filename> script
+        automates creating a BSP layer.
+        What makes a layer a "BSP layer", is the presence of a machine
+        configuration file.
+        Additionally, a BSP layer usually has a kernel recipe
+        or an append file that leverages off an existing kernel recipe.
+        The primary requirement, however, is the machine configuration.
     </para>
 
     <para>
-        The following procedure creates a BSP layer:
+        Use these steps to create a BSP layer:
         <itemizedlist>
             <listitem><para>
-                <emphasis>Create General Layer:</emphasis>
+                <emphasis>Create a General Layer:</emphasis>
                 Use the <filename>bitbake-layers</filename> script with the
                 <filename>create-layer</filename> subcommand to create a
                 new general layer.
@@ -1774,25 +1770,41 @@
                 section in the Yocto Project Development Tasks Manual.
                 </para></listitem>
             <listitem><para>
-                <emphasis>Create a Machine Configuration File:</emphasis>
-                Create a <filename>conf/machine/&gt;machine&lt;.conf</filename>
+                <emphasis>Create a Layer Configuration File:</emphasis>
+                Every layer needs a layer configuration file.
+                This configuration file establishes locations for the
+                layer's recipes, priorities for the layer, and so forth.
+                You can find examples of <filename>layer.conf</filename>
+                files in the Yocto Project
+                <ulink url='&YOCTO_GIT_URL;'>Source Repositories</ulink>.
+                To get examples of what you need in your configuration
+                file, locate a layer (e.g. "meta-ti") and examine the
+                <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/meta-ti/tree/conf/layer.conf'></ulink>
                 file.
-                See <filename>meta-yocto-bsp/conf/machine</filename> for sample
-                <filename>&gt;machine.conf&lt;</filename> files.
-                Other samples exist from other vendors such as
-                <filename>meta-intel</filename>, <filename>meta-ti</filename>,
-                and <filename>meta-freescale</filename> that have more specific machine
+                </para></listitem>
+            <listitem><para>
+                <emphasis>Create a Machine Configuration File:</emphasis>
+                Create a <filename>conf/machine/</filename><replaceable>bsp_root_name</replaceable><filename>.conf</filename>
+                file.
+                See
+                <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta-yocto-bsp/conf/machine'><filename>meta-yocto-bsp/conf/machine</filename></ulink>
+                for sample
+                <replaceable>bsp_root_name</replaceable><filename>.conf</filename>
+                files.
+                Other samples such as
+                <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/meta-ti/tree/conf/machine'><filename>meta-ti</filename></ulink>
+                and
+                <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/meta-freescale/tree/conf/machine'><filename>meta-freescale</filename></ulink>
+                exist from other vendors that have more specific machine
                 and tuning examples.
                 </para></listitem>
             <listitem><para>
                 <emphasis>Create a Kernel Recipe:</emphasis>
                 Create a kernel recipe in <filename>recipes-kernel/linux</filename>
-                either using a linux-yocto kernel with a <filename>.bbappend</filename>
-                file or a new custom kernel recipe file (i.e. <filename>.bb</filename>
-                file).
+                by either using a kernel append file or a new custom kernel
+                recipe file (e.g. <filename>yocto-linux_4.12.bb</filename>).
                 The BSP layers mentioned in the previous step also contain different
                 kernel examples.
-                You can start with the linux-yocto or use a custom kernel.
                 See the
                 "<ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;#modifying-an-existing-recipe'>Modifying an Existing Recipe</ulink>"
                 section in the Yocto Project Linux Kernel Development Manual
@@ -1802,43 +1814,456 @@
     </para>
 
     <para>
-        [THERE IS MORE INFORMATION THAT NEEDS TO BE FILLED IN HERE. THIS NEEDS TO
-        BE PROVIDED BY ENGINEERS.]
+        The remainder of this section provides a description of
+        the Yocto Project reference BSP for Beaglebone, which
+        resides in the
+        <ulink url='&YOCTO_DOCS_REF_URL;#term-container-layer'>Container Layer</ulink>
+        (i.e.
+        <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta-yocto-bsp'><filename>meta-yocto-bsp</filename></ulink>).
     </para>
 
-    <para>
-        The remainder of this section presents an example that uses
-        <filename>myarm</filename> as the machine name and <filename>qemu</filename>
-        as the machine architecture.
-        Of the available architectures, <filename>qemu</filename> is the only architecture
-        that causes the script to prompt you further for an actual architecture.
-        In every other way, this architecture is representative of how creating a BSP for
-        an actual machine would work.
-        The reason the example uses this architecture is because it is an emulated architecture
-        and can easily be followed without requiring actual hardware.
-    </para>
+    <section id='bsp-layer-configuration-example'>
+        <title>BSP Layer Configuration Example</title>
 
-    <para>
-        Following is a complete example:
-        <literallayout class='monospaced'>
-     [INSERT EXAMPLE - NEED EXAMPLE]
-        </literallayout>
-    </para>
+        <para>
+            The layer's <filename>conf</filename> directory
+            contains the <filename>layer.conf</filename>
+            configuration file.
+            In this example, the
+            <filename>conf/layer.conf</filename> is the
+            following:
+            <literallayout class='monospaced'>
+     # We have a conf and classes directory, add to BBPATH
+     BBPATH .= ":${LAYERDIR}"
 
-    <para>
-        Once the BSP Layer is created, you must add it to your
-        <filename>bblayers.conf</filename> file.
-        Here is an example:
-        <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-myarm \
-        "
-        </literallayout>
-        Adding the layer to this file allows the build system to build the BSP and
-        find the layer along with other Metadata it needs.
-    </para>
+     # We have recipes-* directories, add to BBFILES
+     BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
+                 ${LAYERDIR}/recipes-*/*/*.bbappend"
+
+     BBFILE_COLLECTIONS += "yoctobsp"
+     BBFILE_PATTERN_yoctobsp = "^${LAYERDIR}/"
+     BBFILE_PRIORITY_yoctobsp = "5"
+     LAYERVERSION_yoctobsp = "4"
+     LAYERSERIES_COMPAT_yoctobsp = "&DISTRO_NAME_NO_CAP;"
+            </literallayout>
+            The variables used in this file configure the
+            layer.
+            A good way to learn about layer configuration
+            files is to examine various files for BSP from
+            the
+            <ulink url='&YOCTO_GIT_URL;'>Source Repositories</ulink>.
+        </para>
+
+        <para>
+            For a detailed description of this particular
+            layer configuration file, see
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#dev-layer-config-file-description'>step 3</ulink>
+            in the discussion that describes how to create
+            layers in the Yocto Project Development Tasks Manual.
+        </para>
+    </section>
+
+    <section id='bsp-machine-configuration-example'>
+        <title>BSP Machine Configuration Example</title>
+
+        <para>
+            As mentioned earlier in this section, the existence
+            of a machine configuration file is what makes a
+            layer a BSP layer as compared to a general or
+            kernel layer.
+        </para>
+
+        <para>
+            Machine configuration files exist in the
+            <replaceable>bsp_layer</replaceable><filename>/conf/machine/</filename>
+            directory of the layer:
+            <literallayout class='monospaced'>
+     <replaceable>bsp_layer</replaceable><filename>/conf/machine/</filename><replaceable>machine</replaceable><filename>.conf</filename>
+            </literallayout>
+            For example, the machine configuration file for the
+            <ulink url='http://beagleboard.org/bone'>BeagleBone and BeagleBone Black development boards</ulink>
+            is located in the container layer
+            <filename>poky/meta-yocto-bsp/conf/machine</filename>
+            and is named <filename>beaglebone-yocto.conf</filename>:
+            <literallayout class='monospaced'>
+     #@TYPE: Machine
+     #@NAME: Beaglebone-yocto machine
+     #@DESCRIPTION: Reference machine configuration for http://beagleboard.org/bone and http://beagleboard.org/black boards
+
+     PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xorg"
+     XSERVER ?= "xserver-xorg \
+                xf86-video-modesetting \
+                "
+
+     MACHINE_EXTRA_RRECOMMENDS = "kernel-modules kernel-devicetree"
+
+     EXTRA_IMAGEDEPENDS += "u-boot"
+
+     DEFAULTTUNE ?= "cortexa8hf-neon"
+     include conf/machine/include/tune-cortexa8.inc
+
+     IMAGE_FSTYPES += "tar.bz2 jffs2 wic wic.bmap"
+     EXTRA_IMAGECMD_jffs2 = "-lnp "
+     WKS_FILE ?= "beaglebone-yocto.wks"
+     IMAGE_INSTALL_append = " kernel-devicetree kernel-image-zimage"
+     do_image_wic[depends] += "mtools-native:do_populate_sysroot dosfstools-native:do_populate_sysroot"
+
+     SERIAL_CONSOLES = "115200;ttyO0"
+
+     PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
+     PREFERRED_VERSION_linux-yocto ?= "4.12%"
+
+     KERNEL_IMAGETYPE = "zImage"
+     KERNEL_DEVICETREE = "am335x-bone.dtb am335x-boneblack.dtb am335x-bonegreen.dtb"
+     KERNEL_EXTRA_ARGS += "LOADADDR=${UBOOT_ENTRYPOINT}"
+
+     SPL_BINARY = "MLO"
+     UBOOT_SUFFIX = "img"
+     UBOOT_MACHINE = "am335x_boneblack_config"
+     UBOOT_ENTRYPOINT = "0x80008000"
+     UBOOT_LOADADDRESS = "0x80008000"
+
+     MACHINE_FEATURES = "usbgadget usbhost vfat alsa"
+
+     IMAGE_BOOT_FILES ?= "u-boot.${UBOOT_SUFFIX} MLO"
+            </literallayout>
+            The variables used to configure the machine define
+            machine-specific properties.
+            For example, machine-dependent packages, machine
+            tunings, the type of kernel to build, and
+            U-Boot configurations.
+        </para>
+
+        <para>
+            The following list provides some explanation
+            for the statements found in the example reference
+            machine configuration file for the BeagleBone
+            development boards.
+            Realize that much more can be defined as part of
+            a machines configuration file.
+            In general, you can learn about related variables
+            that this example does not have by locating the
+            variables in the
+            "<ulink url='&YOCTO_DOCS_REF_URL;#ref-variables-glos'>Yocto Project Variables Glossary</ulink>"
+            in the Yocto Project Reference Manual.
+            <itemizedlist>
+                <listitem><para>
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-PREFERRED_PROVIDER'><filename>PREFERRED_PROVIDER_virtual/xserver</filename></ulink>:
+                    The recipe that provides "virtual/xserver" when
+                    more than one provider is found.
+                    In this case, the recipe that provides
+                    "virtual/xserver" is "xserver-xorg", which
+                    exists in
+                    <filename>poky/meta/recipes-graphics/xserver-xorg</filename>.
+                    </para></listitem>
+                <listitem><para>
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-XSERVER'><filename>XSERVER</filename></ulink>:
+                    The packages that should be installed to provide
+                    an X server and drivers for the machine.
+                    In this example, the "xserver-xorg" and
+                    "xf86-video-modesetting" are installed.
+                    </para></listitem>
+                <listitem><para>
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE_EXTRA_RRECOMMENDS'><filename>MACHINE_EXTRA_RRECOMMENDS</filename></ulink>:
+                    A list of machine-dependent packages
+                    not essential for booting the image.
+                    Thus, the build does not fail if the packages
+                    do not exist.
+                    However, the packages are required for a
+                    fully-featured image.
+                    <note><title>Tip</title>
+                        Many <filename>MACHINE*</filename> variables
+                        exist that help you configure a particular
+                        piece of hardware.
+                    </note>
+                    </para></listitem>
+                <listitem><para>
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-EXTRA_IMAGEDEPENDS'><filename>EXTRA_IMAGEDEPENDS</filename></ulink>:
+                    Recipes to build that do not provide packages
+                    for installing into the root filesystem
+                    but building the image depends on the
+                    recipes.
+                    Sometimes a recipe is required to build
+                    the final image but is not needed in the
+                    root filesystem.
+                    In this case, the U-Boot recipe must be
+                    built for the image.
+                    </para></listitem>
+                <listitem><para>
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-DEFAULTTUNE'><filename>DEFAULTTUNE</filename></ulink>:
+                    Machines use tunings to optimize machine,
+                    CPU, and application performance.
+                    These features, which are collectively known
+                    as "tuning features", exist in the
+                    <ulink url='&YOCTO_DOCS_REF_URL;#oe-core'>OpenEmbedded-Core (OE-Core)</ulink>
+                    layer (e.g.
+                    <filename>poky/meta/conf/machine/include</filename>).
+                    In this example, the default tunning file is
+                    "cortexa8hf-neon".
+                    <note>
+                        The <filename>include</filename> statement
+                        that pulls in the
+                        <filename>conf/machine/include/tune-cortexa8.inc</filename>
+                        file provides many tuning possibilities.
+                    </note>
+                    </para></listitem>
+                <listitem><para>
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-IMAGE_FSTYPES'><filename>IMAGE_FSTYPES</filename></ulink>:
+                    The formats the OpenEmbedded build system
+                    uses during the build when creating the
+                    root filesystem.
+                    In this example, four types of images are
+                    supported.
+                    </para></listitem>
+                <listitem><para>
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-EXTRA_IMAGECMD'><filename>EXTRA_IMAGECMD</filename></ulink>:
+                    Specifies additional options for image
+                    creation commands.
+                    In this example, the "-lnp " option is used
+                    when creating the
+                    <ulink url='https://en.wikipedia.org/wiki/JFFS2'>JFFS2</ulink>
+                    image.
+                    </para></listitem>
+                <listitem><para>
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-WKS_FILE'><filename>WKS_FILE</filename></ulink>:
+                    The location of the
+                    <ulink url='&YOCTO_DOCS_REF_URL;#ref-kickstart'>Wic kickstart</ulink>
+                    file used by the OpenEmbedded build system to
+                    create a partitioned image (image.wic).
+                    </para></listitem>
+                <listitem><para>
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-IMAGE_INSTALL'><filename>IMAGE_INSTALL</filename></ulink>:
+                    Specifies packages to install into an image
+                    through the
+                    <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-image'><filename>image</filename></ulink>
+                    class.
+                    Recipes use the <filename>IMAGE_INSTALL</filename>
+                    variable.
+                    </para></listitem>
+                <listitem><para>
+                    <filename>do_image_wic[depends]</filename>:
+                    A task that is constructed during the build.
+                    In this example, the task depends on specific tools
+                    in order to create the sysroot when buiding a Wic
+                    image.
+                    </para></listitem>
+                <listitem><para>
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-SERIAL_CONSOLES'><filename>SERIAL_CONSOLES</filename></ulink>:
+                    Defines a serial console (TTY) to enable using
+                    getty.
+                    In this case, the baud rate is "115200" and the
+                    device name is "ttyO0".
+                    </para></listitem>
+                <listitem><para>
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-PREFERRED_PROVIDER'><filename>PREFERRED_PROVIDER_virtual/kernel</filename></ulink>:
+                    Specifies the recipe that provides
+                    "virtual/kernel" when more than one provider
+                    is found.
+                    In this case, the recipe that provides
+                    "virtual/kernel" is "linux-yocto", which
+                    exists in the layer's
+                    <filename>recipes-kernel/linux</filename> directory.
+                    </para></listitem>
+                <listitem><para>
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-PREFERRED_VERSION'><filename>PREFERRED_VERSION_linux-yocto</filename></ulink>:
+                    Defines the version of the recipe used
+                    to build the kernel, which is "4.12" in this
+                    case.
+                    </para></listitem>
+                <listitem><para>
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-KERNEL_IMAGETYPE'><filename>KERNEL_IMAGETYPE</filename></ulink>:
+                    The type of kernel to build for the device.
+                    In this case, the OpenEmbedded build system
+                    creates a "zImage" image type.
+                    </para></listitem>
+                <listitem><para>
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-KERNEL_DEVICETREE'><filename>KERNEL_DEVICETREE</filename></ulink>:
+                    The name of the generated Linux kernel device
+                    tree (i.e. the <filename>.dtb</filename>) file.
+                    All the device trees for the various BeagleBone
+                    devices are included.
+<!--
+                    You have to include some *.inc files according to the definition of KERNEL_DEVICETREE.
+                    I don't see where these are being provided.
+-->
+                    </para></listitem>
+                <listitem><para>
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-KERNEL_EXTRA_ARGS'><filename>KERNEL_EXTRA_ARGS</filename></ulink>:
+                    Additional <filename>make</filename>
+                    command-line arguments the OpenEmbedded build
+                    system passes on when compiling the kernel.
+                    In this example, "LOADADDR=${UBOOT_ENTRYPOINT}"
+                    is passed as a command-line argument.
+                    </para></listitem>
+                <listitem><para>
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-SPL_BINARY'><filename>SPL_BINARY</filename></ulink>:
+                    Defines the Secondary Program Loader (SPL) binary
+                    type.
+                    In this case, the SPL binary is set to
+                    "MLO", which stands for Multimedia card LOader.
+                    </para>
+
+                    <para>The BeagleBone development board requires an
+                    SPL to boot and that SPL file type must be MLO.
+                    Consequently, the machine configuration needs to
+                    define <filename>SPL_BINARY</filename> as "MLO".
+                    <note>
+                        For more information on how the SPL variables
+                        are used, see the
+                        <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta/recipes-bsp/u-boot/u-boot.inc'><filename>u-boot.inc</filename></ulink>
+                        include file.
+                    </note>
+                    </para></listitem>
+                <listitem><para>
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-UBOOT_ENTRYPOINT'><filename>UBOOT_*</filename></ulink>:
+                    Defines various U-Boot configurations needed
+                    to build a U-Boot image.
+                    In this example, a U-Boot image is required
+                    to boot the BeagleBone device.
+                    See the following variables for more information:
+                    <itemizedlist>
+                        <listitem><para>
+                            <ulink url='&YOCTO_DOCS_REF_URL;#var-UBOOT_SUFFIX'><filename>UBOOT_SUFFIX</filename></ulink>:
+                            Points to the generated U-Boot extension.
+                            </para></listitem>
+                        <listitem><para>
+                            <ulink url='&YOCTO_DOCS_REF_URL;#var-UBOOT_MACHINE'><filename>UBOOT_MACHINE</filename></ulink>:
+                            Specifies the value passed on the make command line when building a U-Boot image.
+                            </para></listitem>
+                        <listitem><para>
+                            <ulink url='&YOCTO_DOCS_REF_URL;#var-UBOOT_ENTRYPOINT'><filename>UBOOT_ENTRYPOINT</filename></ulink>:
+                            Specifies the entry point for the U-Boot image.
+                            </para></listitem>
+                        <listitem><para>
+                            <ulink url='&YOCTO_DOCS_REF_URL;#var-UBOOT_LOADADDRESS'><filename>UBOOT_LOADADDRESS</filename></ulink>:
+                            Specifies the load address for the U-Boot image.
+                            </para></listitem>
+                    </itemizedlist>
+                    </para></listitem>
+                <listitem><para>
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE_FEATURES'><filename>MACHINE_FEATURES</filename></ulink>:
+                    Specifies the list of hardware features the
+                    BeagleBone device is capable of supporting.
+                    In this case, the device supports
+                    "usbgadget usbhost vfat alsa".
+                    </para></listitem>
+                <listitem><para>
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-IMAGE_BOOT_FILES'><filename>IMAGE_BOOT_FILES</filename></ulink>:
+                    Files installed into the device's boot partition
+                    when preparing the image using the Wic tool
+                    with the <filename>bootimg-partition</filename>
+                    source plugin.
+                    In this case, the "u-boot.${UBOOT_SUFFIX}" and
+                    "MLO" files are installed.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
+
+    <section id='bsp-kernel-recipe-example'>
+        <title>BSP Kernel Recipe Example</title>
+
+        <para>
+            The kernel recipe used to build the kernel image
+            for the BeagleBone device was established in the
+            machine configuration:
+            <literallayout class='monospaced'>
+     PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
+     PREFERRED_VERSION_linux-yocto ?= "4.12%"
+            </literallayout>
+            The <filename>meta-yocto-bsp/recipes-kernel/linux</filename>
+            directory in the layer contains metadata used
+            to build the kernel.
+            In this case, a kernel append file is used to
+            override an established kernel recipe, which is
+            located in
+            <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/poky/tree/meta/recipes-kernel/linux'></ulink>
+            and named
+            <filename>linux-yocto_4.12.bb</filename>.
+        </para>
+
+        <para>
+            Following is the contents of the append file:
+            <literallayout class='monospaced'>
+     KBRANCH_genericx86  = "standard/base"
+     KBRANCH_genericx86-64  = "standard/base"
+
+     KMACHINE_genericx86 ?= "common-pc"
+     KMACHINE_genericx86-64 ?= "common-pc-64"
+     KBRANCH_edgerouter = "standard/edgerouter"
+     KBRANCH_beaglebone-yocto = "standard/beaglebone"
+     KMACHINE_beaglebone-yocto = "beaglebone"
+     KBRANCH_mpc8315e-rdb = "standard/fsl-mpc8315e-rdb"
+
+     SRCREV_machine_genericx86    ?= "1c4ad569af3e23a77994235435040e322908687f"
+     SRCREV_machine_genericx86-64 ?= "1c4ad569af3e23a77994235435040e322908687f"
+     SRCREV_machine_edgerouter ?= "257f843ea367744620f1d92910afd2f454e31483"
+     SRCREV_machine_beaglebone-yocto ?= "257f843ea367744620f1d92910afd2f454e31483"
+     SRCREV_machine_mpc8315e-rdb ?= "014560874f9eb2a86138c9cc35046ff1720485e1"
+
+
+     COMPATIBLE_MACHINE_genericx86 = "genericx86"
+     COMPATIBLE_MACHINE_genericx86-64 = "genericx86-64"
+     COMPATIBLE_MACHINE_edgerouter = "edgerouter"
+     COMPATIBLE_MACHINE_beaglebone-yocto = "beaglebone-yocto"
+     COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb"
+
+     LINUX_VERSION_genericx86 = "4.12.20"
+     LINUX_VERSION_genericx86-64 = "4.12.20"
+     LINUX_VERSION_edgerouter = "4.12.19"
+     LINUX_VERSION_beaglebone-yocto = "4.12.19"
+     LINUX_VERSION_mpc8315e-rdb = "4.12.19"
+            </literallayout>
+            This particular append file works for all the
+            machines that are part of the
+            <filename>meta-yocto-bsp</filename> container
+            layer.
+            The relevant statements are appended with
+            the "beaglebone-yocto" string.
+            The OpenEmbedded build system uses these
+            statements to override similar statements
+            in the kernel recipe:
+            <itemizedlist>
+                <listitem><para>
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-KBRANCH'><filename>KBRANCH</filename></ulink>:
+                    Identifies the kernel branch that is validated,
+                    patched, and configured during the build.
+                    </para></listitem>
+                <listitem><para>
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-KMACHINE'><filename>KMACHINE</filename></ulink>:
+                    Identifies the machine name as known by the
+                    kernel, which is sometimes a different name
+                    than what is known by the OpenEmbedded build
+                    system.
+                    </para></listitem>
+                <listitem><para>
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-SRCREV'><filename>SRCREV</filename></ulink>:
+                    Identifies the revision of the source code used
+                    to build the image.
+<!--
+                    You find out about that point in the kernel source tree by
+                    doing the following command:
+
+                    git log &dash;&dash;decorate 257f843ea367744620f1d92910afd2f454e31483
+
+                    Returns information about the commit, which is usually
+                    that it is a merge point for a stable kernel release.
+-->
+                    </para></listitem>
+                <listitem><para>
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-COMPATIBLE_MACHINE'><filename>COMPATIBLE_MACHINE</filename></ulink>:
+                    A regular expression that resolves to one or
+                    more target machines with which the recipe
+                    is compatible.
+                    </para></listitem>
+                <listitem><para>
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-LINUX_VERSION'><filename>LINUX_VERSION</filename></ulink>:
+                    The Linux version from kernel.org used by
+                    the OpenEmbedded build system to build the
+                    kernel image.
+                    </para></listitem>
+            </itemizedlist>
+        </para>
+    </section>
 </section>
 </chapter>

documentation/concepts-manual/concepts-manual-customization.xsl

@@ -1,27 +0,0 @@
-<?xml version='1.0'?>
-<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns="http://www.w3.org/1999/xhtml" xmlns:fo="http://www.w3.org/1999/XSL/Format" version="1.0">
-
-  <xsl:import href="http://downloads.yoctoproject.org/mirror/docbook-mirror/docbook-xsl-1.76.1/xhtml/docbook.xsl" />
-
-<!--
-
-  <xsl:import href="../template/1.76.1/docbook-xsl-1.76.1/xhtml/docbook.xsl" />
-
-  <xsl:import href="http://docbook.sourceforge.net/release/xsl/1.76.1/xhtml/docbook.xsl" />
-
--->
-
-  <xsl:include href="../template/permalinks.xsl"/>
-  <xsl:include href="../template/section.title.xsl"/>
-  <xsl:include href="../template/component.title.xsl"/>
-  <xsl:include href="../template/division.title.xsl"/>
-  <xsl:include href="../template/formal.object.heading.xsl"/>
-
-  <xsl:param name="html.stylesheet" select="'concepts-manual-style.css'" />
-  <xsl:param name="chapter.autolabel" select="1" />
-  <xsl:param name="appendix.autolabel" select="A" />
-  <xsl:param name="section.autolabel" select="1" />
-  <xsl:param name="section.label.includes.component.label" select="1" />
-  <xsl:param name="generate.id.attributes" select="1" />
-
-</xsl:stylesheet>

documentation/concepts-manual/concepts-manual-eclipse-customization.xsl

@@ -1,35 +0,0 @@
-<?xml version='1.0'?>
-<xsl:stylesheet
-	xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
-	xmlns="http://www.w3.org/1999/xhtml"
-	xmlns:fo="http://www.w3.org/1999/XSL/Format"
-	version="1.0">
-
-  <xsl:import href="http://downloads.yoctoproject.org/mirror/docbook-mirror/docbook-xsl-1.76.1/eclipse/eclipse3.xsl" />
-
-<!--
-
-  <xsl:import href="../template/1.76.1/docbook-xsl-1.76.1/eclipse/eclipse3.xsl" />
-
-  <xsl:import
-	  href="http://docbook.sourceforge.net/release/xsl/1.76.1/eclipse/eclipse3.xsl" />
-
--->
-
-  <xsl:param name="chunker.output.indent" select="'yes'"/>
-  <xsl:param name="chunk.quietly" select="1"/>
-  <xsl:param name="chunk.first.sections" select="1"/>
-  <xsl:param name="chunk.section.depth" select="10"/>
-  <xsl:param name="use.id.as.filename" select="1"/>
-  <xsl:param name="ulink.target" select="'_self'" />
-  <xsl:param name="base.dir" select="'html/concepts-manual/'"/>
-  <xsl:param name="html.stylesheet" select="'../book.css'"/>
-  <xsl:param name="eclipse.manifest" select="0"/>
-  <xsl:param name="create.plugin.xml" select="0"/>
-  <xsl:param name="suppress.navigation" select="1"/>
-  <xsl:param name="generate.index" select="0"/>
-  <xsl:param name="chapter.autolabel" select="1" />
-  <xsl:param name="appendix.autolabel" select="1" />
-  <xsl:param name="section.autolabel" select="1" />
-  <xsl:param name="section.label.includes.component.label" select="1" />
-</xsl:stylesheet>

documentation/concepts-manual/concepts-manual-intro.xml

@@ -1,87 +0,0 @@
-<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
-[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
-
-<chapter id='concepts-manual-intro'>
-
-<title>The Yocto Project Concepts Manual</title>
-    <section id='concepts-overview-welcome'>
-        <title>Welcome</title>
-
-        <para>
-            Welcome to the Yocto Project Concepts Manual!
-            This manual provides conceptual information that helps you
-            better understand the Yocto Project.
-            You can learn about Yocto Project components,
-            cross-development toolchain generation, shared-state cache,
-            and many other concepts.
-        </para>
-
-        <para>
-            This manual does not give you the following:
-            <itemizedlist>
-                <listitem><para>
-                    <emphasis>Complete Step-by-step Instructions for Development Tasks:</emphasis>
-                    Instructional procedures reside in other manuals within
-                    the Yocto Project documentation set.
-                    For example, the
-                    <ulink url='&YOCTO_DOCS_DEV_URL;'>Yocto Project Development Tasks Manual</ulink>
-                    provides examples on how to perform various development
-                    tasks.
-                    As another example, the
-                    <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>
-                <listitem><para>
-                    <emphasis>Reference Material:</emphasis>
-                    This type of material resides in an appropriate reference
-                    manual.
-                    For example, system variables are documented in the
-                    <ulink url='&YOCTO_DOCS_REF_URL;'>Yocto Project Reference Manual</ulink>.
-                    As another example, the
-                    <ulink url='&YOCTO_DOCS_BSP_URL;'>Yocto Project Board Support Package (BSP) Developer's Guide</ulink>
-                    contains reference information on BSPs.
-                    </para></listitem>
-                <listitem><para>
-                    <emphasis>Getting Started Material:</emphasis>
-                    This type of material resides in the
-                    <ulink url='&YOCTO_DOCS_GS_URL;'>Getting Started With Yocto Project Manual</ulink>.
-                    </para></listitem>
-                <listitem><para>
-                    <emphasis>Detailed Public Information Not Specific to the
-                    Yocto Project:</emphasis>
-                    For example, exhaustive information on how to use Git
-                    is better covered with Internet searches and official
-                    Git Documentation than through the Yocto Project
-                    documentation.
-                    </para></listitem>
-            </itemizedlist>
-        </para>
-    </section>
-
-    <section id='concepts-overview-other-information'>
-        <title>Other Information</title>
-
-        <para>
-            Because this manual presents information for many different
-            concepts, supplemental information is recommended for full
-            comprehension.
-            For additional introductory information on the Yocto Project, see
-            the <ulink url='&YOCTO_HOME_URL;'>Yocto Project Website</ulink>.
-            You can find an introductory to using the Yocto Project by working
-            through the
-            <ulink url='&YOCTO_DOCS_QS_URL;'>Yocto Project Quick Start</ulink>.
-        </para>
-
-        <para>
-            For a comprehensive list of links and other documentation, see the
-            "<ulink url='&YOCTO_DOCS_REF_URL;#resources-links-and-related-documentation'>Links and Related Documentation</ulink>"
-            section in the Yocto Project Reference Manual.
-        </para>
-    </section>
-</chapter>
-<!--
-vim: expandtab tw=80 ts=4
--->

documentation/concepts-manual/concepts-manual.xml

@@ -1,92 +0,0 @@
-<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
-[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
-
-<book id='concepts-manual' lang='en'
-      xmlns:xi="http://www.w3.org/2003/XInclude"
-      xmlns="http://docbook.org/ns/docbook"
-      >
-    <bookinfo>
-
-        <mediaobject>
-            <imageobject>
-                <imagedata fileref='figures/concepts-manual-title.png'
-                    format='SVG'
-                    align='left' scalefit='1' width='100%'/>
-            </imageobject>
-        </mediaobject>
-
-        <title>
-            Yocto Project Concepts Manual
-        </title>
-
-        <authorgroup>
-            <author>
-                <firstname>Scott</firstname> <surname>Rifenbark</surname>
-                <affiliation>
-                    <orgname>Scotty's Documentation Services, INC</orgname>
-                </affiliation>
-                <email>srifenbark@gmail.com</email>
-            </author>
-        </authorgroup>
-
-        <revhistory>
-            <revision>
-                <revnumber>2.5</revnumber>
-                <date>April 2018</date>
-                <revremark>The initial document released with the Yocto Project 2.5 Release.</revremark>
-            </revision>
-        </revhistory>
-
-    <copyright>
-     <year>&COPYRIGHT_YEAR;</year>
-      <holder>Linux Foundation</holder>
-    </copyright>
-
-    <legalnotice>
-      <para>
-          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>
-                       This version of the
-                       <emphasis>Yocto Project Concepts 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>
-               </itemizedlist>
-           </note>
-    </legalnotice>
-
-    </bookinfo>
-
-    <xi:include href="concepts-manual-intro.xml"/>
-
-    <xi:include href="concepts-manual-concepts.xml"/>
-
-</book>
-<!--
-vim: expandtab tw=80 ts=4
--->

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

@@ -16,33 +16,29 @@
             The manual groups related procedures into higher-level sections.
             Procedures can consist of high-level steps or low-level steps
             depending on the topic.
-            You can find conceptual information related to a procedure by
-            following appropriate links to the Yocto Project Reference
-            Manual.
         </para>
 
         <para>
             The following list describes what you can get from this manual:
             <itemizedlist>
                 <listitem><para>
-                    <emphasis>Setup Procedures:</emphasis>
-                    Procedures that show you how to set
-                    up a Yocto Project Development environment and how
-                    to accomplish the change workflow through logging
-                    defects and submitting changes.
+                    Procedures that help you get going with the Yocto Project.
+                    For example, procedures that show you how to set up
+                    a build host and work with the Yocto Project
+                    source repositories.
                     </para></listitem>
                 <listitem><para>
-                    <emphasis>Emulation Procedures:</emphasis>
-                    Procedures that show you how to use the
-                    Yocto Project integrated QuickEMUlator (QEMU), which lets
-                    you simulate running on hardware an image you have built
-                    using the OpenEmbedded build system.
+                    Procedures that show you how to submit changes to the
+                    Yocto Project.
+                    Changes can be improvements, new features, or bug
+                    fixes.
                     </para></listitem>
                 <listitem><para>
-                    <emphasis>Common Procedures:</emphasis>
                     Procedures related to "everyday" tasks you perform while
                     developing images and applications using the Yocto
                     Project.
+                    For example, procedures to create a layer, customize an
+                    image, write a new recipe, and so forth.
                     </para></listitem>
             </itemizedlist>
         </para>
@@ -51,7 +47,7 @@
             This manual will not give you the following:
             <itemizedlist>
                 <listitem><para>
-                    <emphasis>Redundant Step-by-step Instructions:</emphasis>
+                    Redundant Step-by-step Instructions:
                     For example, the
                     <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
@@ -59,14 +55,15 @@
                     hardware.
                     </para></listitem>
                 <listitem><para>
-                    <emphasis>Reference or Conceptual Material:</emphasis>
-                    This type of material resides in an appropriate reference manual.
+                    Reference or Conceptual Material:
+                    This type of material resides in an appropriate reference
+                    manual.
                     For example, system variables are documented in the
                     <ulink url='&YOCTO_DOCS_REF_URL;'>Yocto Project Reference Manual</ulink>.
                     </para></listitem>
                 <listitem><para>
-                    <emphasis>Detailed Public Information Not Specific to the
-                    Yocto Project:</emphasis>
+                    Detailed Public Information Not Specific to the
+                    Yocto Project:
                     For example, exhaustive information on how to use the
                     Source Control Manager Git is better covered with Internet
                     searches and official Git Documentation than through the
@@ -85,9 +82,10 @@
             comprehension.
             For introductory information on the Yocto Project, see the
             <ulink url='&YOCTO_HOME_URL;'>Yocto Project Website</ulink>.
-            You can find an introductory to using the Yocto Project by working
-            through the
-            <ulink url='&YOCTO_DOCS_QS_URL;'>Yocto Project Quick Start</ulink>.
+            If you want to build an image with no knowledge of Yocto Project
+            as a way of quickly testing it out, see the
+            <ulink url='&YOCTO_DOCS_BRIEF_URL;'>Yocto Project Quick Build</ulink>
+            document.
         </para>
 
         <para>

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

@@ -1,990 +0,0 @@
-<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
-"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"
-[<!ENTITY % poky SYSTEM "../poky.ent"> %poky; ] >
-
-<chapter id='dev-manual-newbie'>
-
-<title>The Yocto Project Open Source Development Environment</title>
-
-<section id="usingpoky-changes-collaborate">
-    <title>Setting Up a Team Yocto Project Development Environment</title>
-
-    <para>
-        It might not be immediately clear how you can use the Yocto
-        Project in a team development environment, or scale it for a large
-        team of developers.
-        One of the strengths of the Yocto Project is that it is extremely
-        flexible.
-        Thus, you can adapt it to many different use cases and scenarios.
-        However, these characteristics can cause a struggle if you are trying
-        to create a working setup that scales across a large team.
-    </para>
-
-    <para>
-        To help you understand how to set up this type of environment,
-        this section presents a procedure that gives you the information
-        to learn how to get the results you want.
-        The procedure is high-level and presents some of the project's most
-        successful experiences, practices, solutions, and available
-        technologies that work well.
-        Keep in mind, the procedure here is a starting point.
-        You can build off it and customize it to fit any
-        particular working environment and set of practices.
-        <orderedlist>
-            <listitem><para>
-                <emphasis>Determine Who is Going to be Developing:</emphasis>
-                You need to understand who is going to be doing anything
-                related to the Yocto Project and what their roles would be.
-                Making this determination is essential to completing the
-                steps two and three, which are to get your equipment together
-                and set up your development environment's hardware topology.
-                </para>
-
-                <para>The following roles exist:
-                <itemizedlist>
-                    <listitem><para>
-                        <emphasis>Application Development:</emphasis>
-                        These types of developers do application level work
-                        on top of an existing software stack.
-                        </para></listitem>
-                    <listitem><para>
-                        <emphasis>Core System Development:</emphasis>
-                        These types of developers work on the contents of the
-                        operating system image itself.
-                        </para></listitem>
-                    <listitem><para>
-                        <emphasis>Build Engineer:</emphasis>
-                        This type of developer manages Autobuilders and
-                        releases.
-                        Not all environments need a Build Engineer.
-                        </para></listitem>
-                    <listitem><para>
-                        <emphasis>Test Engineer:</emphasis>
-                        This type of developer creates and manages automated
-                        tests needed to ensure all application and core
-                        system development meets desired quality standards.
-                        </para></listitem>
-                </itemizedlist>
-                </para></listitem>
-            <listitem><para>
-                <emphasis>Gather the Hardware:</emphasis>
-                Based on the size and make-up of the team, get the hardware
-                together.
-                Any development, build, or test engineer should be using
-                a system that is running a supported Linux distribution.
-                Systems, in general, should be high performance (e.g. dual,
-                six-core Xeons with 24 Gbytes of RAM and plenty of disk space).
-                You can help ensure efficiency by having any machines used
-                for testing or that run Autobuilders be as high performance
-                as possible.
-                </para></listitem>
-            <listitem><para>
-                <emphasis>Understand the Hardware Topology of the Environment:</emphasis>
-                Now that you know how many developers and support engineers
-                are required, you can understand the topology of the
-                hardware environment.
-                The following figure shows a moderately sized Yocto Project
-                development environment.
-
-                <para role="writernotes">
-                Need figure.</para>
-
-                </para></listitem>
-            <listitem><para>
-                <emphasis>Use Git as Your Source Control Manager (SCM):</emphasis>
-                Keeping your
-                <ulink url='&YOCTO_DOCS_REF_URL;#metadata'>Metadata</ulink>
-                and any software you are developing under the
-                control of an SCM system that is compatible
-                with the OpenEmbedded build system is advisable.
-                Of the SCMs BitBake supports, the
-                Yocto Project team strongly recommends using
-                <ulink url='&YOCTO_DOCS_GS_URL;#git'>Git</ulink>.
-                Git is a distributed system that is easy to backup,
-                allows you to work remotely, and then connects back to the
-                infrastructure.
-                <note>
-                    For information about BitBake, see the
-                    <ulink url='&YOCTO_DOCS_BB_URL;'>BitBake User Manual</ulink>.
-                </note></para>
-
-                <para>It is relatively easy to set up Git services and create
-                infrastructure like
-                <ulink url='&YOCTO_GIT_URL;'>http://git.yoctoproject.org</ulink>,
-                which is based on server software called
-                <filename>gitolite</filename> with <filename>cgit</filename>
-                being used to generate the web interface that lets you view the
-                repositories.
-                The <filename>gitolite</filename> software identifies users
-                using SSH keys and allows branch-based
-                access controls to repositories that you can control as little
-                or as much as necessary.
-
-                <note>
-                   The setup of these services is beyond the scope of this
-                   manual.
-                   However, sites such as these exist that describe how to
-                   perform setup:
-                   <itemizedlist>
-                       <listitem><para>
-                           <ulink url='http://git-scm.com/book/ch4-8.html'>Git documentation</ulink>:
-                           Describes how to install <filename>gitolite</filename>
-                           on the server.
-                           </para></listitem>
-                       <listitem><para>
-                           <ulink url='http://sitaramc.github.com/gitolite/master-toc.html'>The <filename>gitolite</filename> master index</ulink>:
-                            All topics for <filename>gitolite</filename>.
-                            </para></listitem>
-                        <listitem><para>
-                            <ulink url='https://git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools'>Interfaces, frontends, and tools</ulink>:
-                            Documentation on how to create interfaces and frontends
-                            for Git.
-                            </para></listitem>
-                    </itemizedlist>
-                </note>
-                </para></listitem>
-            <listitem><para>
-                <emphasis>Set up the Application Development Machines:</emphasis>
-                As mentioned earlier, application developers are creating
-                applications on top of existing software stacks.
-                Following are some best practices for setting up machines
-                that do application development:
-                <itemizedlist>
-                    <listitem><para>
-                        Use a pre-built toolchain that
-                        contains the software stack itself.
-                        Then, develop the application code on top of the
-                        stack.
-                        This method works well for small numbers of relatively
-                        isolated applications.
-                        </para></listitem>
-                    <listitem><para>
-                        When possible, use the Yocto Project
-                        plug-in for the
-                        <trademark class='trade'>Eclipse</trademark> IDE
-                        and SDK development practices.
-                        For more information, see the
-                        "<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.
-                        You can do this through provisioning either as new
-                        toolchain downloads or as updates through a package
-                        update mechanism using <filename>opkg</filename>
-                        to provide updates to an existing toolchain.
-                        The exact mechanics of how and when to do this are a
-                        question for local policy.
-                        </para></listitem>
-                    <listitem><para>
-                        Use multiple toolchains installed locally
-                        into different locations to allow development across
-                        versions.
-                        </para></listitem>
-                </itemizedlist>
-                </para></listitem>
-            <listitem><para>
-                <emphasis>Set up the Core Development Machines:</emphasis>
-                As mentioned earlier, these types of developers work on the
-                contents of the operating system itself.
-                Following are some best practices for setting up machines
-                used for developing images:
-                <itemizedlist>
-                    <listitem><para>
-                        Have the Yocto Project build system itself available on
-                        the developer workstations so developers can run their own
-                        builds and directly rebuild the software stack.
-                        </para></listitem>
-                    <listitem><para>
-                        Keep the core system unchanged as much as
-                        possible and do your work in layers on top of the
-                        core system.
-                        Doing so gives you a greater level of portability when
-                        upgrading to new versions of the core system or Board
-                        Support Packages (BSPs).
-                        </para></listitem>
-                    <listitem><para>
-                        Share layers amongst the developers of a
-                        particular project and contain the policy configuration
-                        that defines the project.
-                        </para></listitem>
-                </itemizedlist>
-                </para></listitem>
-            <listitem><para>
-                <emphasis>Set up an Autobuilder:</emphasis>
-                Autobuilders are often the core of the development
-                environment.
-                It is here that changes from individual developers are brought
-                together and centrally tested and subsequent decisions about
-                releases can be made.
-                Autobuilders also allow for "continuous integration" style
-                testing of software components and regression identification
-                and tracking.</para>
-
-                <para>See "<ulink url='http://autobuilder.yoctoproject.org'>Yocto Project Autobuilder</ulink>"
-                for more information and links to buildbot.
-                The Yocto Project team has found this implementation
-                works well in this role.
-                A public example of this is the Yocto Project
-                Autobuilders, which we use to test the overall health of the
-                project.</para>
-
-                <para>The features of this system are:
-                <itemizedlist>
-                    <listitem><para>
-                         Highlights when commits break the build.
-                         </para></listitem>
-                    <listitem><para>
-                        Populates an sstate cache from which
-                        developers can pull rather than requiring local
-                        builds.
-                        </para></listitem>
-                    <listitem><para>
-                        Allows commit hook triggers,
-                        which trigger builds when commits are made.
-                        </para></listitem>
-                    <listitem><para>
-                        Allows triggering of automated image booting
-                        and testing under the QuickEMUlator (QEMU).
-                        </para></listitem>
-                    <listitem><para>
-                        Supports incremental build testing and
-                        from-scratch builds.
-                        </para></listitem>
-                    <listitem><para>
-                        Shares output that allows developer
-                        testing and historical regression investigation.
-                        </para></listitem>
-                    <listitem><para>
-                        Creates output that can be used for releases.
-                        </para></listitem>
-                    <listitem><para>
-                        Allows scheduling of builds so that resources
-                        can be used efficiently.
-                        </para></listitem>
-               </itemizedlist>
-               </para></listitem>
-           <listitem><para>
-               <emphasis>Set up Test Machines:</emphasis>
-               Use a small number of shared, high performance systems
-               for testing purposes.
-               Developers can use these systems for wider, more
-               extensive testing while they continue to develop
-               locally using their primary development system.
-               </para></listitem>
-           <listitem><para>
-               <emphasis>Document Policies and Change Flow:</emphasis>
-               The Yocto Project itself uses a hierarchical structure and a
-                pull model.
-                Scripts exist to create and send pull requests
-                (i.e. <filename>create-pull-request</filename> and
-                <filename>send-pull-request</filename>).
-                This model is in line with other open source projects where
-                maintainers are responsible for specific areas of the project
-                and a single maintainer handles the final "top-of-tree" merges.
-                <note>
-                    You can also use a more collective push model.
-                    The <filename>gitolite</filename> software supports both the
-                    push and pull models quite easily.
-                </note></para>
-
-                <para>As with any development environment, it is important
-                to document the policy used as well as any main project
-                guidelines so they are understood by everyone.
-                It is also a good idea to have well structured
-                commit messages, which are usually a part of a project's
-                guidelines.
-                Good commit messages are essential when looking back in time and
-                trying to understand why changes were made.</para>
-
-                <para>If you discover that changes are needed to the core
-                layer of the project, it is worth sharing those with the
-                community as soon as possible.
-                Chances are if you have discovered the need for changes,
-                someone else in the community needs them also.
-                </para></listitem>
-            <listitem><para>
-                <emphasis>Development Environment Summary:</emphasis>
-                Aside from the previous steps, some best practices exist
-                within the Yocto Project development environment.
-                Consider the following:
-                <itemizedlist>
-                    <listitem><para>
-                        Use
-                        <ulink url='&YOCTO_DOCS_GS_URL;#git'>Git</ulink>
-                        as the source control system.
-                        </para></listitem>
-                    <listitem><para>
-                        Maintain your Metadata in layers that make sense
-                        for your situation.
-                        See the "<link linkend='understanding-and-creating-layers'>Understanding
-                        and Creating Layers</link>" section for more information on
-                        layers.
-                        </para></listitem>
-                    <listitem><para>
-                        Separate the project's Metadata and code by using
-                        separate Git repositories.
-                        See the
-                        "<ulink url='&YOCTO_DOCS_GS_URL;#yocto-project-repositories'>Yocto Project Source Repositories</ulink>"
-                        section for information on these repositories.
-                        See the
-                        "<link linkend='working-with-yocto-project-source-files'>Working With Yocto Project Source Files</link>"
-                        section for information on how to set up local Git
-                        repositories for related upstream Yocto Project
-                        Git repositories.
-                        </para></listitem>
-                    <listitem><para>
-                        Set up the directory for the shared state cache
-                        (<ulink url='&YOCTO_DOCS_REF_URL;#var-SSTATE_DIR'><filename>SSTATE_DIR</filename></ulink>)
-                        where it makes sense.
-                        For example, set up the sstate cache on a system used
-                        by developers in the same organization and share the
-                        same source directories on their machines.
-                        </para></listitem>
-                    <listitem><para>
-                        Set up an Autobuilder and have it populate the
-                        sstate cache and source directories.
-                        </para></listitem>
-                    <listitem><para>
-                        The Yocto Project community encourages you
-                        to send patches to the project to fix bugs or add features.
-                        If you do submit patches, follow the project commit
-                        guidelines for writing good commit messages.
-                        See the "<link linkend='how-to-submit-a-change'>Submitting a Change to the Yocto Project</link>"
-                        section.
-                        </para></listitem>
-                    <listitem><para>
-                        Send changes to the core sooner than later
-                        as others are likely to run into the same issues.
-                        For some guidance on mailing lists to use, see the list in the
-                        "<link linkend='how-to-submit-a-change'>Submitting a Change to the Yocto Project</link>"
-                        section.
-                        For a description of the available mailing lists, see the
-                        "<ulink url='&YOCTO_DOCS_REF_URL;#resources-mailinglist'>Mailing Lists</ulink>"
-                        section in the Yocto Project Reference Manual.
-                        </para></listitem>
-                </itemizedlist>
-                </para></listitem>
-        </orderedlist>
-    </para>
-</section>
-
-<section id='submitting-a-defect-against-the-yocto-project'>
-    <title>Submitting a Defect Against the Yocto Project</title>
-
-    <para>
-        Use the Yocto Project implementation of
-        <ulink url='http://www.bugzilla.org/about/'>Bugzilla</ulink>
-        to submit a defect (bug) against the Yocto Project.
-        For additional information on this implementation of Bugzilla see the
-        "<ulink url='&YOCTO_DOCS_REF_URL;#resources-bugtracker'>Yocto Project Bugzilla</ulink>"
-        section in the Yocto Project Reference Manual.
-        For more detail on any of the following steps, see the Yocto Project
-        <ulink url='&YOCTO_WIKI_URL;/wiki/Bugzilla_Configuration_and_Bug_Tracking'>Bugzilla wiki page</ulink>.
-    </para>
-
-    <para>
-        Use the following general steps to submit a bug"
-
-        <orderedlist>
-            <listitem><para>
-                Open the Yocto Project implementation of
-                <ulink url='&YOCTO_BUGZILLA_URL;'>Bugzilla</ulink>.
-                </para></listitem>
-            <listitem><para>
-                Click "File a Bug" to enter a new bug.
-                </para></listitem>
-            <listitem><para>
-                Choose the appropriate "Classification", "Product", and
-                "Component" for which the bug was found.
-                Bugs for the Yocto Project fall into one of several
-                classifications, which in turn break down into several
-                products and components.
-                For example, for a bug against the
-                <filename>meta-intel</filename> layer, you would choose
-                "Build System, Metadata &amp; Runtime", "BSPs", and
-                "bsps-meta-intel", respectively.
-                </para></listitem>
-            <listitem><para>
-                Choose the "Version" of the Yocto Project for which you found
-                the bug (e.g. &DISTRO;).
-                </para></listitem>
-            <listitem><para>
-                Determine and select the "Severity" of the bug.
-                The severity indicates how the bug impacted your work.
-                </para></listitem>
-            <listitem><para>
-                Choose the "Hardware" that the bug impacts.
-                </para></listitem>
-            <listitem><para>
-                Choose the "Architecture" that the bug impacts.
-                </para></listitem>
-            <listitem><para>
-                Choose a "Documentation change" item for the bug.
-                Fixing a bug might or might not affect the Yocto Project
-                documentation.
-                If you are unsure of the impact to the documentation, select
-                "Don't Know".
-                </para></listitem>
-            <listitem><para>
-                Provide a brief "Summary" of the bug.
-                Try to limit your summary to just a line or two and be sure
-                to capture the essence of the bug.
-                </para></listitem>
-            <listitem><para>
-                Provide a detailed "Description" of the bug.
-                You should provide as much detail as you can about the context,
-                behavior, output, and so forth that surrounds the bug.
-                You can even attach supporting files for output from logs by
-                using the "Add an attachment" button.
-                </para></listitem>
-            <listitem><para>
-                Click the "Submit Bug" button submit the bug.
-                A new Bugzilla number is assigned to the bug and the defect
-                is logged in the bug tracking system.
-                </para></listitem>
-        </orderedlist>
-        Once you file a bug, the bug is processed by the Yocto Project Bug
-        Triage Team and further details concerning the bug are assigned
-        (e.g. priority and owner).
-        You are the "Submitter" of the bug and any further categorization,
-        progress, or comments on the bug result in Bugzilla sending you an
-        automated email concerning the particular change or progress to the
-        bug.
-    </para>
-</section>
-
-<section id='how-to-submit-a-change'>
-    <title>Submitting a Change to the Yocto Project</title>
-
-    <para>
-        Contributions to the Yocto Project and OpenEmbedded are very welcome.
-        Because the system is extremely configurable and flexible, we recognize
-        that developers will want to extend, configure or optimize it for
-        their specific uses.
-    </para>
-
-    <para>
-        The Yocto Project uses a mailing list and a patch-based workflow
-        that is similar to the Linux kernel but contains important
-        differences.
-        In general, a mailing list exists through which you can submit
-        patches.
-        You should send patches to the appropriate mailing list so that they
-        can be reviewed and merged by the appropriate maintainer.
-        The specific mailing list you need to use depends on the
-        location of the code you are changing.
-        Each component (e.g. layer) should have a
-        <filename>README</filename> file that indicates where to send
-        the changes and which process to follow.
-    </para>
-
-    <para>
-        You can send the patch to the mailing list using whichever approach
-        you feel comfortable with to generate the patch.
-        Once sent, the patch is usually reviewed by the community at large.
-        If somebody has concerns with the patch, they will usually voice
-        their concern over the mailing list.
-        If a patch does not receive any negative reviews, the maintainer of
-        the affected layer typically takes the patch, tests it, and then
-        based on successful testing, merges the patch.
-    </para>
-
-    <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, Metadata, documentation,
-        and so forth) built using the combo-layer tool.
-        The upstream location used for submitting changes varies by
-        component:
-        <itemizedlist>
-            <listitem><para>
-                <emphasis>Core Metadata:</emphasis>
-                Send your patch to the
-                <ulink url='http://lists.openembedded.org/mailman/listinfo/openembedded-core'>openembedded-core</ulink>
-                mailing list.  For example, a change to anything under
-                the <filename>meta</filename> or
-                <filename>scripts</filename> directories should be sent
-                to this mailing list.
-                </para></listitem>
-            <listitem><para>
-                <emphasis>BitBake:</emphasis>
-                For changes to BitBake (i.e. anything under the
-                <filename>bitbake</filename> directory), send your patch
-                to the
-                <ulink url='http://lists.openembedded.org/mailman/listinfo/bitbake-devel'>bitbake-devel</ulink>
-                mailing list.
-                </para></listitem>
-            <listitem><para>
-                <emphasis>"meta-*" trees:</emphasis>
-                These trees contain Metadata.
-                Use the
-                <ulink url='https://lists.yoctoproject.org/listinfo/poky'>poky</ulink>
-                mailing list.
-                </para></listitem>
-        </itemizedlist>
-    </para>
-
-    <para>
-        For changes to other layers hosted in the Yocto Project source
-        repositories (i.e. <filename>yoctoproject.org</filename>), tools,
-        and the Yocto Project documentation, use the
-        <ulink url='https://lists.yoctoproject.org/listinfo/yocto'>Yocto Project</ulink>
-        general mailing list.
-        <note>
-            Sometimes a layer's documentation specifies to use a
-            particular mailing list.
-            If so, use that list.
-        </note>
-        For additional recipes that do not fit into the core Metadata, you
-        should determine which layer the recipe should go into and submit
-        the change in the manner recommended by the documentation (e.g.
-        the <filename>README</filename> file) supplied with the layer.
-        If in doubt, please ask on the Yocto general mailing list or on
-        the openembedded-devel mailing list.
-    </para>
-
-    <para>
-        You can also push a change upstream and request a maintainer to
-        pull the change into the component's upstream repository.
-        You do this by pushing to a contribution repository that is upstream.
-        See the
-        "<ulink url='&YOCTO_DOCS_GS_URL;#workflows'>Workflows</ulink>"
-        section in the Getting Started With Yocto Project Manual for additional
-        concepts on working in the Yocto Project development environment.
-    </para>
-
-    <para>
-        Two commonly used testing repositories exist for
-        OpenEmbedded-Core:
-        <itemizedlist>
-            <listitem><para>
-                <emphasis>"ross/mut" branch:</emphasis>
-                The "mut" (master-under-test) tree
-                exists in the <filename>poky-contrib</filename> repository
-                in the
-                <ulink url='&YOCTO_GIT_URL;'>Yocto Project source repositories</ulink>.
-                </para></listitem>
-            <listitem><para>
-                <emphasis>"master-next" branch:</emphasis>
-                This branch is part of the main
-                "poky" repository in the Yocto Project source repositories.
-                </para></listitem>
-        </itemizedlist>
-        Maintainers use these branches to test submissions prior to merging
-        patches.
-        Thus, you can get an idea of the status of a patch based on
-        whether the patch has been merged into one of these branches.
-        <note>
-            This system is imperfect and changes can sometimes get lost in the
-            flow.
-            Asking about the status of a patch or change is reasonable if the
-            change has been idle for a while with no feedback.
-            The Yocto Project does have plans to use
-            <ulink url='https://en.wikipedia.org/wiki/Patchwork_(software)'>Patchwork</ulink>
-            to track the status of patches and also to automatically preview
-            patches.
-        </note>
-    </para>
-
-    <para>
-        The following sections provide procedures for submitting a change.
-    </para>
-
-    <section id='pushing-a-change-upstream'>
-        <title>Using Scripts to Push a Change Upstream and Request a Pull</title>
-
-        <para>
-            Follow this procedure to push a change to an upstream "contrib"
-            Git repository:
-            <note>
-                You can find general Git information on how to push a change
-                upstream in the
-                <ulink url='http://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows'>Git Community Book</ulink>.
-            </note>
-            <orderedlist>
-                <listitem><para>
-                    <emphasis>Make Your Changes Locally:</emphasis>
-                    Make your changes in your local Git repository.
-                    You should make small, controlled, isolated changes.
-                    Keeping changes small and isolated aids review,
-                    makes merging/rebasing easier and keeps the change
-                    history clean should anyone need to refer to it in
-                    future.
-                    </para></listitem>
-                <listitem><para>
-                    <emphasis>Stage Your Changes:</emphasis>
-                    Stage your changes by using the <filename>git add</filename>
-                    command on each file you changed.
-                    </para></listitem>
-                <listitem><para id='making-sure-you-have-correct-commit-information'>
-                    <emphasis>Commit Your Changes:</emphasis>
-                    Commit the change by using the
-                    <filename>git commit</filename> command.
-                    Make sure your commit information follows standards by
-                    following these accepted conventions:
-                    <itemizedlist>
-                        <listitem><para>
-                            Be sure to include a "Signed-off-by:" line in the
-                            same style as required by the Linux kernel.
-                            Adding this line signifies that you, the submitter,
-                            have agreed to the Developer's Certificate of
-                            Origin 1.1 as follows:
-                            <literallayout class='monospaced'>
-     Developer's Certificate of Origin 1.1
-
-     By making a contribution to this project, I certify that:
-
-     (a) The contribution was created in whole or in part by me and I
-         have the right to submit it under the open source license
-         indicated in the file; or
-
-     (b) The contribution is based upon previous work that, to the best
-         of my knowledge, is covered under an appropriate open source
-         license and I have the right under that license to submit that
-         work with modifications, whether created in whole or in part
-         by me, under the same open source license (unless I am
-         permitted to submit under a different license), as indicated
-         in the file; or
-
-     (c) The contribution was provided directly to me by some other
-         person who certified (a), (b) or (c) and I have not modified
-         it.
-
-     (d) I understand and agree that this project and the contribution
-         are public and that a record of the contribution (including all
-         personal information I submit with it, including my sign-off) is
-         maintained indefinitely and may be redistributed consistent with
-         this project or the open source license(s) involved.
-                            </literallayout>
-                            </para></listitem>
-                        <listitem><para>
-                            Provide a single-line summary of the change.
-                            and,
-                            if more explanation is needed, provide more
-                            detail in the body of the commit.
-                            This summary is typically viewable in the
-                            "shortlist" of changes.
-                            Thus, providing something short and descriptive
-                            that gives the reader a summary of the change is
-                            useful when viewing a list of many commits.
-                            You should prefix this short description with the
-                            recipe name (if changing a recipe), or else with
-                            the short form path to the file being changed.
-                            </para></listitem>
-                        <listitem><para>
-                            For the body of the commit message, provide
-                            detailed information that describes what you
-                            changed, why you made the change, and the approach
-                            you used.
-                            It might also be helpful if you mention how you
-                            tested the change.
-                            Provide as much detail as you can in the body of
-                            the commit message.
-                            <note>
-                                You do not need to provide a more detailed
-                                explanation of a change if the change is
-                                minor to the point of the single line
-                                summary providing all the information.
-                            </note>
-                            </para></listitem>
-                        <listitem><para>
-                            If the change addresses a specific bug or issue
-                            that is associated with a bug-tracking ID,
-                            include a reference to that ID in your detailed
-                            description.
-                            For example, the Yocto Project uses a specific
-                            convention for bug references - any commit that
-                            addresses a specific bug should use the following
-                            form for the detailed description.
-                            Be sure to use the actual bug-tracking ID from
-                            Bugzilla for
-                            <replaceable>bug-id</replaceable>:
-                            <literallayout class='monospaced'>
-     Fixes [YOCTO #<replaceable>bug-id</replaceable>]
-
-     <replaceable>detailed description of change</replaceable>
-                            </literallayout>
-                            </para></listitem>
-                    </itemizedlist>
-                    </para></listitem>
-                <listitem><para>
-                    <emphasis>Push Your Commits to a "Contrib" Upstream:</emphasis>
-                    If you have arranged for permissions to push to an
-                    upstream contrib repository, push the change to that
-                    repository:
-                    <literallayout class='monospaced'>
-     $ git push <replaceable>upstream_remote_repo</replaceable> <replaceable>local_branch_name</replaceable>
-                    </literallayout>
-                    For example, suppose you have permissions to push into the
-                    upstream <filename>meta-intel-contrib</filename>
-                    repository and you are working in a local branch named
-                    <replaceable>your_name</replaceable><filename>/README</filename>.
-                    The following command pushes your local commits to the
-                    <filename>meta-intel-contrib</filename> upstream
-                    repository and puts the commit in a branch named
-                    <replaceable>your_name</replaceable><filename>/README</filename>:
-                    <literallayout class='monospaced'>
-     $ git push meta-intel-contrib <replaceable>your_name</replaceable>/README
-                    </literallayout>
-                    </para></listitem>
-                <listitem><para id='push-determine-who-to-notify'>
-                    <emphasis>Determine Who to Notify:</emphasis>
-                    Determine the maintainer or the mailing list
-                    that you need to notify for the change.</para>
-
-                    <para>Before submitting any change, you need to be sure
-                    who the maintainer is or what mailing list that you need
-                    to notify.
-                    Use either these methods to find out:
-                    <itemizedlist>
-                        <listitem><para>
-                            <emphasis>Maintenance File:</emphasis>
-                            Examine the <filename>maintainers.inc</filename>
-                            file, which is located in the
-                            <ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink>
-                            at
-                            <filename>meta/conf/distro/include</filename>,
-                            to see who is responsible for code.
-                            </para></listitem>
-                        <listitem><para>
-                            <emphasis>Search by File:</emphasis>
-                            Using <ulink url='&YOCTO_DOCS_GS_URL;#git'>Git</ulink>,
-                            you can enter the following command to bring up a
-                            short list of all commits against a specific file:
-                            <literallayout class='monospaced'>
-     git shortlog -- <replaceable>filename</replaceable>
-                            </literallayout>
-                            Just provide the name of the file for which you
-                            are interested.
-                            The information returned is not ordered by history
-                            but does include a list of everyone who has
-                            committed grouped by name.
-                            From the list, you can see who is responsible for
-                            the bulk of the changes against the file.
-                            </para></listitem>
-                        <listitem><para>
-                            <emphasis>Examine the List of Mailing Lists:</emphasis>
-                            For a list of the Yocto Project and related mailing
-                            lists, see the
-                            "<ulink url='&YOCTO_DOCS_REF_URL;#resources-mailinglist'>Mailing lists</ulink>"
-                            section in the Yocto Project Reference Manual.
-                            </para></listitem>
-                    </itemizedlist>
-                    </para></listitem>
-                <listitem><para>
-                    <emphasis>Make a Pull Request:</emphasis>
-                    Notify the maintainer or the mailing list that you have
-                    pushed a change by making a pull request.</para>
-
-                    <para>The Yocto Project provides two scripts that
-                    conveniently let you generate and send pull requests to the
-                    Yocto Project.
-                    These scripts are <filename>create-pull-request</filename>
-                    and <filename>send-pull-request</filename>.
-                    You can find these scripts in the
-                    <filename>scripts</filename> directory within the
-                    <ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink>
-                    (e.g. <filename>~/poky/scripts</filename>).
-                    </para>
-
-                    <para>Using these scripts correctly formats the requests
-                    without introducing any whitespace or HTML formatting.
-                    The maintainer that receives your patches either directly
-                    or through the mailing list needs to be able to save and
-                    apply them directly from your emails.
-                    Using these scripts is the preferred method for sending
-                    patches.</para>
-
-                    <para>First, create the pull request.
-                    For example, the following command runs the script,
-                    specifies the upstream repository in the contrib directory
-                    into which you pushed the change, and provides a subject
-                    line in the created patch files:
-                    <literallayout class='monospaced'>
-     $ ~/poky/scripts/create-pull-request -u meta-intel-contrib -s "Updated Manual Section Reference in README"
-                    </literallayout>
-                    Running this script forms
-                    <filename>*.patch</filename> files in a folder named
-                    <filename>pull-</filename><replaceable>PID</replaceable>
-                    in the current directory.
-                    One of the patch files is a cover letter.</para>
-
-                    <para>Before running the
-                    <filename>send-pull-request</filename> script, you must
-                    edit the cover letter patch to insert information about
-                    your change.
-                    After editing the cover letter, send the pull request.
-                    For example, the following command runs the script and
-                    specifies the patch directory and email address.
-                    In this example, the email address is a mailing list:
-                    <literallayout class='monospaced'>
-     $ ~/poky/scripts/send-pull-request -p ~/meta-intel/pull-10565 -t meta-intel@yoctoproject.org
-                    </literallayout>
-                    You need to follow the prompts as the script is
-                    interactive.
-                    <note>
-                        For help on using these scripts, simply provide the
-                        <filename>-h</filename> argument as follows:
-                        <literallayout class='monospaced'>
-     $ poky/scripts/create-pull-request -h
-     $ poky/scripts/send-pull-request -h
-                        </literallayout>
-                    </note>
-                    </para></listitem>
-            </orderedlist>
-        </para>
-    </section>
-
-    <section id='submitting-a-patch'>
-        <title>Using Email to Submit a Patch</title>
-
-        <para>
-            You can submit patches without using the
-            <filename>create-pull-request</filename> and
-            <filename>send-pull-request</filename> scripts described in the
-            previous section.
-            However, keep in mind, the preferred method is to use the scripts.
-        </para>
-
-        <para>
-            Depending on the components changed, you need to submit the email
-            to a specific mailing list.
-            For some guidance on which mailing list to use, see the
-            <link linkend='figuring-out-the-mailing-list-to-use'>beginning</link>
-            of this section.
-            For a description of all the available mailing lists, see the
-            "<ulink url='&YOCTO_DOCS_REF_URL;#resources-mailinglist'>Mailing Lists</ulink>"
-            section in the Yocto Project Reference Manual.
-        </para>
-
-        <para>
-            Here is the general procedure on how to submit a patch through
-            email without using the scripts:
-            <orderedlist>
-                <listitem><para>
-                    <emphasis>Make Your Changes Locally:</emphasis>
-                    Make your changes in your local Git repository.
-                    You should make small, controlled, isolated changes.
-                    Keeping changes small and isolated aids review,
-                    makes merging/rebasing easier and keeps the change
-                    history clean should anyone need to refer to it in
-                    future.
-                    </para></listitem>
-                <listitem><para>
-                    <emphasis>Stage Your Changes:</emphasis>
-                    Stage your changes by using the <filename>git add</filename>
-                    command on each file you changed.
-                    </para></listitem>
-                <listitem><para>
-                    <emphasis>Commit Your Changes:</emphasis>
-                    Commit the change by using the
-                    <filename>git commit --signoff</filename> command.
-                    Using the <filename>--signoff</filename> option identifies
-                    you as the person making the change and also satisfies
-                    the Developer's Certificate of Origin (DCO) shown earlier.
-                    </para>
-
-                    <para>When you form a commit, you must follow certain
-                    standards established by the Yocto Project development
-                    team.
-                    See
-                    <link linkend='making-sure-you-have-correct-commit-information'>Step 3</link>
-                    in the previous section for information on how to
-                    provide commit information that meets Yocto Project
-                    commit message standards.
-                    </para></listitem>
-                <listitem><para>
-                    <emphasis>Format the Commit:</emphasis>
-                    Format the commit into an email message.
-                    To format commits, use the
-                    <filename>git format-patch</filename> command.
-                    When you provide the command, you must include a revision
-                    list or a number of patches as part of the command.
-                    For example, either of these two commands takes your most
-                    recent single commit and formats it as an email message in
-                    the current directory:
-                    <literallayout class='monospaced'>
-     $ git format-patch -1
-                    </literallayout>
-                    or
-                    <literallayout class='monospaced'>
-     $ git format-patch HEAD~
-                    </literallayout></para>
-
-                    <para>After the command is run, the current directory
-                    contains a numbered <filename>.patch</filename> file for
-                    the commit.</para>
-
-                    <para>If you provide several commits as part of the
-                    command, the <filename>git format-patch</filename> command
-                    produces a series of numbered files in the current
-                    directory – one for each commit.
-                    If you have more than one patch, you should also use the
-                    <filename>--cover</filename> option with the command,
-                    which generates a cover letter as the first "patch" in
-                    the series.
-                    You can then edit the cover letter to provide a
-                    description for the series of patches.
-                    For information on the
-                    <filename>git format-patch</filename> command,
-                    see <filename>GIT_FORMAT_PATCH(1)</filename> displayed
-                    using the <filename>man git-format-patch</filename>
-                    command.
-                    <note>
-                        If you are or will be a frequent contributor to the
-                        Yocto Project or to OpenEmbedded, you might consider
-                        requesting a contrib area and the necessary associated
-                        rights.
-                    </note>
-                    </para></listitem>
-                <listitem><para>
-                    <emphasis>Import the Files Into Your Mail Client:</emphasis>
-                    Import the files into your mail client by using the
-                    <filename>git send-email</filename> command.
-                    <note>
-                        In order to use <filename>git send-email</filename>,
-                        you must have the proper Git packages installed on
-                        your host.
-                        For Ubuntu, Debian, and Fedora the package is
-                        <filename>git-email</filename>.
-                    </note></para>
-
-                    <para>The <filename>git send-email</filename> command
-                    sends email by using a local or remote Mail Transport Agent
-                    (MTA) such as <filename>msmtp</filename>,
-                    <filename>sendmail</filename>, or through a direct
-                    <filename>smtp</filename> configuration in your Git
-                    <filename>~/.gitconfig</filename> file.
-                    If you are submitting patches through email only, it is
-                    very important that you submit them without any whitespace
-                    or HTML formatting that either you or your mailer
-                    introduces.
-                    The maintainer that receives your patches needs to be able
-                    to save and apply them directly from your emails.
-                    A good way to verify that what you are sending will be
-                    applicable by the maintainer is to do a dry run and send
-                    them to yourself and then save and apply them as the
-                    maintainer would.</para>
-
-                    <para>The <filename>git send-email</filename> command is
-                    the preferred method for sending your patches using
-                    email since there is no risk of compromising whitespace
-                    in the body of the message, which can occur when you use
-                    your own mail client.
-                    The command also has several options that let you
-                    specify recipients and perform further editing of the
-                    email message.
-                    For information on how to use the
-                    <filename>git send-email</filename> command,
-                    see <filename>GIT-SEND-EMAIL(1)</filename> displayed using
-                    the <filename>man git-send-email</filename> command.
-                    </para></listitem>
-            </orderedlist>
-        </para>
-    </section>
-</section>
-</chapter>
-<!--
-vim: expandtab tw=80 ts=4
--->

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

@@ -343,6 +343,40 @@
         </para>
     </section>
 
+    <section id='qemu-kvm-cpu-compatibility'>
+        <title>QEMU CPU Compatibility Under KVM</title>
+
+        <para>
+            By default, the QEMU build compiles for and targets 64-bit and x86
+            <trademark class='registered'>Intel</trademark> <trademark class='trademark'>Core</trademark>2
+            Duo processors and 32-bit x86
+            <trademark class='registered'>Intel</trademark> <trademark class='registered'>Pentium</trademark>
+            II processors.
+            QEMU builds for and targets these CPU types because they display
+            a broad range of CPU feature compatibility with many commonly
+            used CPUs.
+        </para>
+
+        <para>
+            Despite this broad range of compatibility, the CPUs could support
+            a feature that your host CPU does not support.
+            Although this situation is not a problem when QEMU uses software
+            emulation of the feature, it can be a problem when QEMU is
+            running with KVM enabled.
+            Specifically, software compiled with a certain CPU feature crashes
+            when run on a CPU under KVM that does not support that feature.
+            To work around this problem, you can override QEMU's runtime CPU
+            setting by changing the <filename>QB_CPU_KVM</filename>
+            variable in <filename>qemuboot.conf</filename> in the
+            <ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory's</ulink>
+            <filename>deploy/image</filename> directory.
+            This setting specifies a <filename>-cpu</filename> option
+            passed into QEMU in the <filename>runqemu</filename> script.
+            Running <filename>qemu -cpu help</filename> returns a list of
+            available supported CPU types.
+        </para>
+    </section>
+
     <section id='qemu-dev-performance'>
         <title>QEMU Performance</title>
 

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

@@ -4,16 +4,386 @@
 
 <chapter id='dev-manual-start'>
 
-<title>Getting Started with the Yocto Project</title>
+<title>Setting Up to Use the Yocto Project</title>
 
 <para>
     This chapter provides procedures related to getting set up to use the
-    Yocto Project, working with Yocto Project source files, and building
-    an image.
+    Yocto Project.
+    You can learn about creating a team environment that develops using the
+    Yocto Project, how to set up a build host, how to locate Yocto Project
+    source repositories, and how to create local Git repositories.
 </para>
 
+<section id="usingpoky-changes-collaborate">
+    <title>Creating a Team Development Environment</title>
+
+    <para>
+        It might not be immediately clear how you can use the Yocto
+        Project in a team development environment, or scale it for a large
+        team of developers.
+        One of the strengths of the Yocto Project is that it is extremely
+        flexible.
+        Thus, you can adapt it to many different use cases and scenarios.
+        However, these characteristics can cause a struggle if you are trying
+        to create a working setup that scales across a large team.
+    </para>
+
+    <para>
+        To help you understand how to set up this type of environment,
+        this section presents a procedure that gives you the information
+        to learn how to get the results you want.
+        The procedure is high-level and presents some of the project's most
+        successful experiences, practices, solutions, and available
+        technologies that work well.
+        Keep in mind, the procedure here is a starting point.
+        You can build off it and customize it to fit any
+        particular working environment and set of practices.
+        <orderedlist>
+            <listitem><para>
+                <emphasis>Determine Who is Going to be Developing:</emphasis>
+                You need to understand who is going to be doing anything
+                related to the Yocto Project and what their roles would be.
+                Making this determination is essential to completing the
+                steps two and three, which are to get your equipment together
+                and set up your development environment's hardware topology.
+                </para>
+
+                <para>The following roles exist:
+                <itemizedlist>
+                    <listitem><para>
+                        <emphasis>Application Development:</emphasis>
+                        These types of developers do application level work
+                        on top of an existing software stack.
+                        </para></listitem>
+                    <listitem><para>
+                        <emphasis>Core System Development:</emphasis>
+                        These types of developers work on the contents of the
+                        operating system image itself.
+                        </para></listitem>
+                    <listitem><para>
+                        <emphasis>Build Engineer:</emphasis>
+                        This type of developer manages Autobuilders and
+                        releases.
+                        Not all environments need a Build Engineer.
+                        </para></listitem>
+                    <listitem><para>
+                        <emphasis>Test Engineer:</emphasis>
+                        This type of developer creates and manages automated
+                        tests needed to ensure all application and core
+                        system development meets desired quality standards.
+                        </para></listitem>
+                </itemizedlist>
+                </para></listitem>
+            <listitem><para>
+                <emphasis>Gather the Hardware:</emphasis>
+                Based on the size and make-up of the team, get the hardware
+                together.
+                Any development, build, or test engineer should be using
+                a system that is running a supported Linux distribution.
+                Systems, in general, should be high performance (e.g. dual,
+                six-core Xeons with 24 Gbytes of RAM and plenty of disk space).
+                You can help ensure efficiency by having any machines used
+                for testing or that run Autobuilders be as high performance
+                as possible.
+                </para></listitem>
+            <listitem><para>
+                <emphasis>Understand the Hardware Topology of the Environment:</emphasis>
+                Once you understand the hardware involved and the make-up
+                of the team, you can understand the hardware topology of the
+                development environment.
+                You can get a visual idea of the machines and their roles
+                across the development environment.
+
+<!--
+                The following figure shows a moderately sized Yocto Project
+                development environment.
+
+                <para role="writernotes">
+                Need figure.</para>
+-->
+
+                </para></listitem>
+            <listitem><para>
+                <emphasis>Use Git as Your Source Control Manager (SCM):</emphasis>
+                Keeping your
+                <ulink url='&YOCTO_DOCS_REF_URL;#metadata'>Metadata</ulink>
+                and any software you are developing under the
+                control of an SCM system that is compatible
+                with the OpenEmbedded build system is advisable.
+                Of the SCMs BitBake supports, the
+                Yocto Project team strongly recommends using
+                <ulink url='&YOCTO_DOCS_OM_URL;#git'>Git</ulink>.
+                Git is a distributed system that is easy to backup,
+                allows you to work remotely, and then connects back to the
+                infrastructure.
+                <note>
+                    For information about BitBake, see the
+                    <ulink url='&YOCTO_DOCS_BB_URL;'>BitBake User Manual</ulink>.
+                </note></para>
+
+                <para>It is relatively easy to set up Git services and create
+                infrastructure like
+                <ulink url='&YOCTO_GIT_URL;'>http://git.yoctoproject.org</ulink>,
+                which is based on server software called
+                <filename>gitolite</filename> with <filename>cgit</filename>
+                being used to generate the web interface that lets you view the
+                repositories.
+                The <filename>gitolite</filename> software identifies users
+                using SSH keys and allows branch-based
+                access controls to repositories that you can control as little
+                or as much as necessary.
+
+                <note>
+                   The setup of these services is beyond the scope of this
+                   manual.
+                   However, sites such as these exist that describe how to
+                   perform setup:
+                   <itemizedlist>
+                       <listitem><para>
+                           <ulink url='http://git-scm.com/book/ch4-8.html'>Git documentation</ulink>:
+                           Describes how to install <filename>gitolite</filename>
+                           on the server.
+                           </para></listitem>
+                       <listitem><para>
+                           <ulink url='http://gitolite.com'>Gitolite</ulink>:
+                            Information for <filename>gitolite</filename>.
+                            </para></listitem>
+                        <listitem><para>
+                            <ulink url='https://git.wiki.kernel.org/index.php/Interfaces,_frontends,_and_tools'>Interfaces, frontends, and tools</ulink>:
+                            Documentation on how to create interfaces and frontends
+                            for Git.
+                            </para></listitem>
+                    </itemizedlist>
+                </note>
+                </para></listitem>
+            <listitem><para>
+                <emphasis>Set up the Application Development Machines:</emphasis>
+                As mentioned earlier, application developers are creating
+                applications on top of existing software stacks.
+                Following are some best practices for setting up machines
+                that do application development:
+                <itemizedlist>
+                    <listitem><para>
+                        Use a pre-built toolchain that
+                        contains the software stack itself.
+                        Then, develop the application code on top of the
+                        stack.
+                        This method works well for small numbers of relatively
+                        isolated applications.
+                        </para></listitem>
+                    <listitem><para>
+                        When possible, use the Yocto Project
+                        plug-in for the
+                        <trademark class='trade'>Eclipse</trademark> IDE
+                        and SDK development practices.
+                        For more information, see the
+                        "<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.
+                        You can do this through provisioning either as new
+                        toolchain downloads or as updates through a package
+                        update mechanism using <filename>opkg</filename>
+                        to provide updates to an existing toolchain.
+                        The exact mechanics of how and when to do this are a
+                        question for local policy.
+                        </para></listitem>
+                    <listitem><para>
+                        Use multiple toolchains installed locally
+                        into different locations to allow development across
+                        versions.
+                        </para></listitem>
+                </itemizedlist>
+                </para></listitem>
+            <listitem><para>
+                <emphasis>Set up the Core Development Machines:</emphasis>
+                As mentioned earlier, these types of developers work on the
+                contents of the operating system itself.
+                Following are some best practices for setting up machines
+                used for developing images:
+                <itemizedlist>
+                    <listitem><para>
+                        Have the Yocto Project build system itself available on
+                        the developer workstations so developers can run their own
+                        builds and directly rebuild the software stack.
+                        </para></listitem>
+                    <listitem><para>
+                        Keep the core system unchanged as much as
+                        possible and do your work in layers on top of the
+                        core system.
+                        Doing so gives you a greater level of portability when
+                        upgrading to new versions of the core system or Board
+                        Support Packages (BSPs).
+                        </para></listitem>
+                    <listitem><para>
+                        Share layers amongst the developers of a
+                        particular project and contain the policy configuration
+                        that defines the project.
+                        </para></listitem>
+                </itemizedlist>
+                </para></listitem>
+            <listitem><para>
+                <emphasis>Set up an Autobuilder:</emphasis>
+                Autobuilders are often the core of the development
+                environment.
+                It is here that changes from individual developers are brought
+                together and centrally tested and subsequent decisions about
+                releases can be made.
+                Autobuilders also allow for "continuous integration" style
+                testing of software components and regression identification
+                and tracking.</para>
+
+                <para>See "<ulink url='http://autobuilder.yoctoproject.org'>Yocto Project Autobuilder</ulink>"
+                for more information and links to buildbot.
+                The Yocto Project team has found this implementation
+                works well in this role.
+                A public example of this is the Yocto Project
+                Autobuilders, which we use to test the overall health of the
+                project.</para>
+
+                <para>The features of this system are:
+                <itemizedlist>
+                    <listitem><para>
+                         Highlights when commits break the build.
+                         </para></listitem>
+                    <listitem><para>
+                        Populates an sstate cache from which
+                        developers can pull rather than requiring local
+                        builds.
+                        </para></listitem>
+                    <listitem><para>
+                        Allows commit hook triggers,
+                        which trigger builds when commits are made.
+                        </para></listitem>
+                    <listitem><para>
+                        Allows triggering of automated image booting
+                        and testing under the QuickEMUlator (QEMU).
+                        </para></listitem>
+                    <listitem><para>
+                        Supports incremental build testing and
+                        from-scratch builds.
+                        </para></listitem>
+                    <listitem><para>
+                        Shares output that allows developer
+                        testing and historical regression investigation.
+                        </para></listitem>
+                    <listitem><para>
+                        Creates output that can be used for releases.
+                        </para></listitem>
+                    <listitem><para>
+                        Allows scheduling of builds so that resources
+                        can be used efficiently.
+                        </para></listitem>
+               </itemizedlist>
+               </para></listitem>
+           <listitem><para>
+               <emphasis>Set up Test Machines:</emphasis>
+               Use a small number of shared, high performance systems
+               for testing purposes.
+               Developers can use these systems for wider, more
+               extensive testing while they continue to develop
+               locally using their primary development system.
+               </para></listitem>
+           <listitem><para>
+               <emphasis>Document Policies and Change Flow:</emphasis>
+               The Yocto Project itself uses a hierarchical structure and a
+                pull model.
+                Scripts exist to create and send pull requests
+                (i.e. <filename>create-pull-request</filename> and
+                <filename>send-pull-request</filename>).
+                This model is in line with other open source projects where
+                maintainers are responsible for specific areas of the project
+                and a single maintainer handles the final "top-of-tree" merges.
+                <note>
+                    You can also use a more collective push model.
+                    The <filename>gitolite</filename> software supports both the
+                    push and pull models quite easily.
+                </note></para>
+
+                <para>As with any development environment, it is important
+                to document the policy used as well as any main project
+                guidelines so they are understood by everyone.
+                It is also a good idea to have well structured
+                commit messages, which are usually a part of a project's
+                guidelines.
+                Good commit messages are essential when looking back in time and
+                trying to understand why changes were made.</para>
+
+                <para>If you discover that changes are needed to the core
+                layer of the project, it is worth sharing those with the
+                community as soon as possible.
+                Chances are if you have discovered the need for changes,
+                someone else in the community needs them also.
+                </para></listitem>
+            <listitem><para>
+                <emphasis>Development Environment Summary:</emphasis>
+                Aside from the previous steps, some best practices exist
+                within the Yocto Project development environment.
+                Consider the following:
+                <itemizedlist>
+                    <listitem><para>
+                        Use
+                        <ulink url='&YOCTO_DOCS_OM_URL;#git'>Git</ulink>
+                        as the source control system.
+                        </para></listitem>
+                    <listitem><para>
+                        Maintain your Metadata in layers that make sense
+                        for your situation.
+                        See the "<link linkend='understanding-and-creating-layers'>Understanding
+                        and Creating Layers</link>" section for more information on
+                        layers.
+                        </para></listitem>
+                    <listitem><para>
+                        Separate the project's Metadata and code by using
+                        separate Git repositories.
+                        See the
+                        "<ulink url='&YOCTO_DOCS_OM_URL;#yocto-project-repositories'>Yocto Project Source Repositories</ulink>"
+                        section for information on these repositories.
+                        See the
+                        "<link linkend='locating-yocto-project-source-files'>Locating Yocto Project Source Files</link>"
+                        section for information on how to set up local Git
+                        repositories for related upstream Yocto Project
+                        Git repositories.
+                        </para></listitem>
+                    <listitem><para>
+                        Set up the directory for the shared state cache
+                        (<ulink url='&YOCTO_DOCS_REF_URL;#var-SSTATE_DIR'><filename>SSTATE_DIR</filename></ulink>)
+                        where it makes sense.
+                        For example, set up the sstate cache on a system used
+                        by developers in the same organization and share the
+                        same source directories on their machines.
+                        </para></listitem>
+                    <listitem><para>
+                        Set up an Autobuilder and have it populate the
+                        sstate cache and source directories.
+                        </para></listitem>
+                    <listitem><para>
+                        The Yocto Project community encourages you
+                        to send patches to the project to fix bugs or add features.
+                        If you do submit patches, follow the project commit
+                        guidelines for writing good commit messages.
+                        See the "<link linkend='how-to-submit-a-change'>Submitting a Change to the Yocto Project</link>"
+                        section.
+                        </para></listitem>
+                    <listitem><para>
+                        Send changes to the core sooner than later
+                        as others are likely to run into the same issues.
+                        For some guidance on mailing lists to use, see the list in the
+                        "<link linkend='how-to-submit-a-change'>Submitting a Change to the Yocto Project</link>"
+                        section.
+                        For a description of the available mailing lists, see the
+                        "<ulink url='&YOCTO_DOCS_REF_URL;#resources-mailinglist'>Mailing Lists</ulink>"
+                        section in the Yocto Project Reference Manual.
+                        </para></listitem>
+                </itemizedlist>
+                </para></listitem>
+        </orderedlist>
+    </para>
+</section>
+
 <section id='setting-up-the-development-host-to-use-the-yocto-project'>
-    <title>Setting Up the Development Host to Use the Yocto Project</title>
+    <title>Preparing the Build Host</title>
 
     <para>
         This section provides procedures to set up your development host to
@@ -175,7 +545,7 @@
                     site.
                     </para></listitem>
                 <listitem><para>
-                    <emphasis>Go the Install Site for Your Platform:</emphasis>
+                    <emphasis>Go to the Install Site for Your Platform:</emphasis>
                     Click the link for the Docker edition associated with
                     your development host machine's native software.
                     For example, if your machine is running Microsoft
@@ -211,8 +581,8 @@
                     the type of the software you need to install.
                     </para></listitem>
                 <listitem><para>
-                    <emphasis>Optionally Orient Yourself With Dockers:</emphasis>
-                    If you are unfamiliar with Dockers and the container
+                    <emphasis>Optionally Orient Yourself With Docker:</emphasis>
+                    If you are unfamiliar with Docker and the container
                     concept, you can learn more here -
                     <ulink url='https://docs.docker.com/get-started/'></ulink>.
                     You should be able to launch Docker or the Docker Toolbox
@@ -248,25 +618,25 @@
     </section>
 </section>
 
-<section id='working-with-yocto-project-source-files'>
-    <title>Working With Yocto Project Source Files</title>
+<section id='locating-yocto-project-source-files'>
+    <title>Locating Yocto Project Source Files</title>
 
     <para>
-        This section contains procedures related to locating and securing
-        Yocto Project files.
+        This section contains procedures related to locating Yocto Project
+        files.
         You establish and use these local files to work on projects.
         <note><title>Notes</title>
             <itemizedlist>
                 <listitem><para>
                     For concepts and introductory information about Git as it
                     is used in the Yocto Project, see the
-                    "<ulink url='&YOCTO_DOCS_GS_URL;#git'>Git</ulink>"
-                    section in the Getting Started With Yocto Project Manual.
+                    "<ulink url='&YOCTO_DOCS_OM_URL;#git'>Git</ulink>"
+                    section in the Yocto Project Overview and Concepts Manual.
                     </para></listitem>
                 <listitem><para>
                     For concepts on Yocto Project source repositories, see the
-                    "<ulink url='&YOCTO_DOCS_GS_URL;#yocto-project-repositories'>Yocto Project Source Repositories</ulink>"
-                    section in the Getting Started With Yocto Project Manual."
+                    "<ulink url='&YOCTO_DOCS_OM_URL;#yocto-project-repositories'>Yocto Project Source Repositories</ulink>"
+                    section in the Yocto Project Overview and Concepts Manual."
                     </para></listitem>
             </itemizedlist>
         </note>
@@ -277,11 +647,11 @@
 
         <para>
             Working from a copy of the upstream Yocto Project
-            <ulink url='&YOCTO_DOCS_GS_URL;#source-repositories'>Source Repositories</ulink>
+            <ulink url='&YOCTO_DOCS_OM_URL;#source-repositories'>Source Repositories</ulink>
             is the preferred method for obtaining and using a Yocto Project
             release.
             You can view the Yocto Project Source Repositories at
-            <ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink>.
+            <ulink url='&YOCTO_GIT_URL;'></ulink>.
             In particular, you can find the
             <filename>poky</filename> repository at
             <ulink url='http://git.yoctoproject.org/cgit/cgit.cgi/poky/'></ulink>.
@@ -306,7 +676,7 @@
                 <listitem><para>
                     <emphasis>Find the URL Used to Clone the Repository:</emphasis>
                     At the bottom of the page, note the URL used to
-                    <ulink url='&YOCTO_DOCS_GS_URL;#git-commands-clone'>clone</ulink>
+                    <ulink url='&YOCTO_DOCS_OM_URL;#git-commands-clone'>clone</ulink>
                     that repository (e.g.
                     <filename>&YOCTO_GIT_URL;/poky</filename>).
                     <note>
@@ -459,36 +829,40 @@
             </orderedlist>
         </para>
     </section>
+</section>
+
+<section id='cloning-and-checking-out-branchs'>
+    <title>Cloning and Checking Out Branches</title>
+
+    <para>
+        To use the Yocto Project, you need a release of the Yocto Project
+        locally installed on your development system.
+        The locally installed set of files is referred to as the
+        <ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink>
+        in the Yocto Project documentation.
+    </para>
+
+    <para>
+        You create your Source Directory by using
+        <ulink url='&YOCTO_DOCS_OM_URL;#git'>Git</ulink> to clone a local
+        copy of the upstream <filename>poky</filename> repository.
+        <note><title>Tip</title>
+            The preferred method of getting the Yocto Project Source
+            Directory set up is to clone the repository.
+        </note>
+        Working from a copy of the upstream repository allows you
+        to contribute back into the Yocto Project or simply work with
+        the latest software on a development branch.
+        Because Git maintains and creates an upstream repository with
+        a complete history of changes and you are working with a local
+        clone of that repository, you have access to all the Yocto
+        Project development branches and tag names used in the upstream
+        repository.
+    </para>
 
     <section id='cloning-the-poky-repository'>
         <title>Cloning the <filename>poky</filename> Repository</title>
 
-        <para>
-            To use the Yocto Project, you need a release of the Yocto Project
-            locally installed on your development system.
-            The locally installed set of files is referred to as the
-            <ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink>
-            in the Yocto Project documentation.
-        </para>
-
-        <para>
-            You create your Source Directory by using
-            <ulink url='&YOCTO_DOCS_GS_URL;#git'>Git</ulink> to clone a local
-            copy of the upstream <filename>poky</filename> repository.
-            <note><title>Tip</title>
-                The preferred method of getting the Yocto Project Source
-                Directory set up is to clone the repository.
-            </note>
-            Working from a copy of the upstream repository allows you
-            to contribute back into the Yocto Project or simply work with
-            the latest software on a development branch.
-            Because Git maintains and creates an upstream repository with
-            a complete history of changes and you are working with a local
-            clone of that repository, you have access to all the Yocto
-            Project development branches and tag names used in the upstream
-            repository.
-        </para>
-
         <para>
             Follow these steps to create a local version of the
             upstream
@@ -523,8 +897,8 @@
                     branch based on a tag name, see the
                     "<link linkend='checking-out-by-branch-in-poky'>Checking Out By Branch in Poky</link>"
                     and
-                    <link linkend='checkout-out-by-tag-in-poky'>Checking Out By Tag in Poky</link>",
-                    respectively.</para>
+                    <link linkend='checkout-out-by-tag-in-poky'>Checking Out By Tag in Poky</link>"
+                    sections, respectively.</para>
 
                     <para>Once the repository is created, you can change to
                     that directory and check its status.
@@ -706,306 +1080,6 @@
     </section>
 </section>
 
-<section id='dev-building-an-image'>
-    <title>Building an Image</title>
-
-    <para>
-        In the development environment, you need to build an image whenever
-        you change hardware support, add or change system libraries, or add
-        or change services that have dependencies.
-        Several methods exist that allow you to build an image within the
-        Yocto Project.
-        This section shows you how to build an image using BitBake from a
-        Linux host.
-        <note><title>Notes</title>
-            <itemizedlist>
-                <listitem><para>
-                    For information on how to build an image using
-                    <ulink url='&YOCTO_DOCS_REF_URL;#toaster-term'>Toaster</ulink>,
-                    see the
-                    <ulink url='&YOCTO_DOCS_TOAST_URL;'>Toaster Manual</ulink>.
-                    </para></listitem>
-                <listitem><para>
-                    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 Application Development and
-                    the Extensible Software Development Kit (eSDK) manual.
-                    </para></listitem>
-                <listitem><para>
-                    For a practical example on how to build an image using the
-                    OpenEmbedded build system, see the
-                    "<ulink url='&YOCTO_DOCS_QS_URL;#qs-building-images'>Building Images</ulink>"
-                    section of the Yocto Project Quick Start.
-                    </para></listitem>
-            </itemizedlist>
-        </note>
-    </para>
-
-    <para>
-        The build process creates an entire Linux distribution from source
-        and places it in your
-        <ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink>
-        under <filename>tmp/deploy/images</filename>.
-        For detailed information on the build process using BitBake, see the
-        "<ulink url='&YOCTO_DOCS_CM_URL;#images-dev-environment'>Images</ulink>"
-        section in the Yocto Project Concepts Manual.
-    </para>
-
-    <para>
-        The following figure and list overviews the build process:
-        <imagedata fileref="figures/bitbake-build-flow.png" width="7in" depth="4in" align="center" scalefit="1" />
-        <orderedlist>
-            <listitem><para>
-                <emphasis>Set up Your Host Development System to Support
-                Development Using the Yocto Project</emphasis>:
-                See the
-                "<ulink url='&YOCTO_DOCS_QS_URL;#yp-resources'>Setting Up to Use the Yocto Project</ulink>"
-                section in the Yocto Project Quick Start for options on how
-                to get a build host ready to use the Yocto Project.
-                </para></listitem>
-            <listitem><para>
-                <emphasis>Initialize the Build Environment:</emphasis>
-                Initialize the build environment by sourcing the build
-                environment script (i.e.
-                <ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>):
-                <literallayout class='monospaced'>
-     $ source &OE_INIT_FILE; [<replaceable>build_dir</replaceable>]
-                </literallayout></para>
-
-                <para>When you use the initialization script, the
-                OpenEmbedded build system uses <filename>build</filename> as
-                the default Build Directory in your current work directory.
-                You can use a <replaceable>build_dir</replaceable> argument
-                with the script to specify a different build directory.
-                <note><title>Tip</title>
-                    A common practice is to use a different Build Directory for
-                    different targets.
-                    For example, <filename>~/build/x86</filename> for a
-                    <filename>qemux86</filename> target, and
-                    <filename>~/build/arm</filename> for a
-                    <filename>qemuarm</filename> target.
-                </note>
-                </para></listitem>
-            <listitem><para>
-                <emphasis>Make Sure Your <filename>local.conf</filename>
-                File is Correct:</emphasis>
-                Ensure the <filename>conf/local.conf</filename> configuration
-                file, which is found in the Build Directory,
-                is set up how you want it.
-                This file defines many aspects of the build environment
-                including the target machine architecture through the
-                <filename><ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'>MACHINE</ulink></filename> variable,
-                the packaging format used during the build
-                (<ulink url='&YOCTO_DOCS_REF_URL;#var-PACKAGE_CLASSES'><filename>PACKAGE_CLASSES</filename></ulink>),
-                and a centralized tarball download directory through the
-                <ulink url='&YOCTO_DOCS_REF_URL;#var-DL_DIR'><filename>DL_DIR</filename></ulink> variable.
-                </para></listitem>
-            <listitem><para>
-                <emphasis>Build the Image:</emphasis>
-                Build the image using the <filename>bitbake</filename> command:
-                <literallayout class='monospaced'>
-     $ bitbake <replaceable>target</replaceable>
-                </literallayout>
-                <note>
-                    For information on BitBake, see the
-                    <ulink url='&YOCTO_DOCS_BB_URL;'>BitBake User Manual</ulink>.
-                </note>
-                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_REF_URL;#source-directory'>Source Directory</ulink>.
-                Or, the target can be the name of a recipe for a specific
-                piece of software such as BusyBox.
-                For more details about the images the OpenEmbedded build
-                system supports, see the
-                "<ulink url='&YOCTO_DOCS_REF_URL;#ref-images'>Images</ulink>"
-                chapter in the Yocto Project Reference Manual.</para>
-
-                <para>As an example, the following command builds the
-                <filename>core-image-minimal</filename> image:
-                <literallayout class='monospaced'>
-     $ bitbake core-image-minimal
-                </literallayout>
-                Once an image has been built, it often needs to be installed.
-                The images and kernels built by the OpenEmbedded build system
-                are placed in the Build Directory in
-                <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;'>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></listitem>
-        </orderedlist>
-    </para>
-</section>
-
-<section id='speeding-up-the-build'>
-    <title>Speeding Up the Build</title>
-
-    <para>
-        Build time can be an issue.
-        By default, the build system uses simple controls to try and maximize
-        build efficiency.
-        In general, the default settings for all the following variables
-        result in the most efficient build times when dealing with single
-        socket systems (i.e. a single CPU).
-        If you have multiple CPUs, you might try increasing the default
-        values to gain more speed.
-        See the descriptions in the glossary for each variable for more
-        information:
-        <itemizedlist>
-            <listitem><para>
-                <ulink url='&YOCTO_DOCS_REF_URL;#var-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename>:</ulink>
-                The maximum number of threads BitBake simultaneously executes.
-                </para></listitem>
-            <listitem><para>
-                <ulink url='&YOCTO_DOCS_BB_URL;#var-BB_NUMBER_PARSE_THREADS'><filename>BB_NUMBER_PARSE_THREADS</filename>:</ulink>
-                The number of threads BitBake uses during parsing.
-                </para></listitem>
-            <listitem><para>
-                <ulink url='&YOCTO_DOCS_REF_URL;#var-PARALLEL_MAKE'><filename>PARALLEL_MAKE</filename>:</ulink>
-                Extra options passed to the <filename>make</filename> command
-                during the
-                <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-compile'><filename>do_compile</filename></ulink>
-                task in order to specify parallel compilation on the
-                local build host.
-                </para></listitem>
-            <listitem><para>
-                <ulink url='&YOCTO_DOCS_REF_URL;#var-PARALLEL_MAKEINST'><filename>PARALLEL_MAKEINST</filename>:</ulink>
-                Extra options passed to the <filename>make</filename> command
-                during the
-                <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-install'><filename>do_install</filename></ulink>
-                task in order to specify parallel installation on the
-                local build host.
-                </para></listitem>
-        </itemizedlist>
-        As mentioned, these variables all scale to the number of processor
-        cores available on the build system.
-        For single socket systems, this auto-scaling ensures that the build
-        system fundamentally takes advantage of potential parallel operations
-        during the build based on the build machine's capabilities.
-    </para>
-
-    <para>
-        Following are additional factors that can affect build speed:
-        <itemizedlist>
-            <listitem><para>
-                File system type:
-                The file system type that the build is being performed on can
-                also influence performance.
-                Using <filename>ext4</filename> is recommended as compared
-                to <filename>ext2</filename> and <filename>ext3</filename>
-                due to <filename>ext4</filename> improved features
-                such as extents.
-                </para></listitem>
-            <listitem><para>
-                Disabling the updating of access time using
-                <filename>noatime</filename>:
-                The <filename>noatime</filename> mount option prevents the
-                build system from updating file and directory access times.
-                </para></listitem>
-            <listitem><para>
-                Setting a longer commit:
-                Using the "commit=" mount option increases the interval
-                in seconds between disk cache writes.
-                Changing this interval from the five second default to
-                something longer increases the risk of data loss but decreases
-                the need to write to the disk, thus increasing the build
-                performance.
-                </para></listitem>
-            <listitem><para>
-                Choosing the packaging backend:
-                Of the available packaging backends, IPK is the fastest.
-                Additionally, selecting a singular packaging backend also
-                helps.
-                </para></listitem>
-            <listitem><para>
-                Using <filename>tmpfs</filename> for
-                <ulink url='&YOCTO_DOCS_REF_URL;#var-TMPDIR'><filename>TMPDIR</filename></ulink>
-                as a temporary file system:
-                While this can help speed up the build, the benefits are
-                limited due to the compiler using
-                <filename>-pipe</filename>.
-                The build system goes to some lengths to avoid
-                <filename>sync()</filename> calls into the
-                file system on the principle that if there was a significant
-                failure, the
-                <ulink url='&YOCTO_DOCS_REF_URL;#build-directory'>Build Directory</ulink>
-                contents could easily be rebuilt.
-                </para></listitem>
-            <listitem><para>
-                Inheriting the
-                <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-rm-work'><filename>rm_work</filename></ulink>
-                class:
-                Inheriting this class has shown to speed up builds due to
-                significantly lower amounts of data stored in the data
-                cache as well as on disk.
-                Inheriting this class also makes cleanup of
-                <ulink url='&YOCTO_DOCS_REF_URL;#var-TMPDIR'><filename>TMPDIR</filename></ulink>
-                faster, at the expense of being easily able to dive into the
-                source code.
-                File system maintainers have recommended that the fastest way
-                to clean up large numbers of files is to reformat partitions
-                rather than delete files due to the linear nature of
-                partitions.
-                This, of course, assumes you structure the disk partitions and
-                file systems in a way that this is practical.
-                </para></listitem>
-        </itemizedlist>
-        Aside from the previous list, you should keep some trade offs in
-        mind that can help you speed up the build:
-        <itemizedlist>
-            <listitem><para>
-                Remove items from
-                <ulink url='&YOCTO_DOCS_REF_URL;#var-DISTRO_FEATURES'><filename>DISTRO_FEATURES</filename></ulink>
-                that you might not need.
-                </para></listitem>
-            <listitem><para>
-                Exclude debug symbols and other debug information:
-                If you do not need these symbols and other debug information,
-                disabling the <filename>*-dbg</filename> package generation
-                can speed up the build.
-                You can disable this generation by setting the
-                <ulink url='&YOCTO_DOCS_REF_URL;#var-INHIBIT_PACKAGE_DEBUG_SPLIT'><filename>INHIBIT_PACKAGE_DEBUG_SPLIT</filename></ulink>
-                variable to "1".
-                </para></listitem>
-            <listitem><para>
-                Disable static library generation for recipes derived from
-                <filename>autoconf</filename> or <filename>libtool</filename>:
-                Following is an example showing how to disable static
-                libraries and still provide an override to handle exceptions:
-                <literallayout class='monospaced'>
-     STATICLIBCONF = "--disable-static"
-     STATICLIBCONF_sqlite3-native = ""
-     EXTRA_OECONF += "${STATICLIBCONF}"
-                </literallayout>
-                <note><title>Notes</title>
-                    <itemizedlist>
-                        <listitem><para>
-                            Some recipes need static libraries in order to work
-                            correctly (e.g. <filename>pseudo-native</filename>
-                            needs <filename>sqlite3-native</filename>).
-                            Overrides, as in the previous example, account for
-                            these kinds of exceptions.
-                            </para></listitem>
-                        <listitem><para>
-                            Some packages have packaging code that assumes the
-                            presence of the static libraries.
-                            If so, you might need to exclude them as well.
-                            </para></listitem>
-                    </itemizedlist>
-                </note>
-            </para></listitem>
-        </itemizedlist>
-    </para>
-</section>
 </chapter>
 <!--
 vim: expandtab tw=80 ts=4

documentation/dev-manual/dev-manual.xml

@@ -103,9 +103,14 @@
             </revision>
             <revision>
                 <revnumber>2.5</revnumber>
-                <date>April 2018</date>
+                <date>May 2018</date>
                 <revremark>Released with the Yocto Project 2.5 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>2.6</revnumber>
+                <date>&REL_MONTH_YEAR;</date>
+                <revremark>Released with the Yocto Project 2.6 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>
@@ -128,24 +133,36 @@
                        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
+                       for this release, 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.
+                       and select the manual from that site.
+                       Manuals from the site are more up-to-date than manuals
+                       derived from the Yocto Project released TAR files.
                        </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>
+                       If you located this manual through a web search, the
+                       version of the manual might not be the one you want
+                       (e.g. the search might have returned a manual much
+                       older than the Yocto Project version with which you
+                       are working).
+                       You can see all Yocto Project major releases by
+                       visiting the
+                       <ulink url='&YOCTO_WIKI_URL;/wiki/Releases'>Releases</ulink>
+                       page.
+                       If you need a version of this manual for a different
+                       Yocto Project release, visit the
+                       <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink>
+                       and select the manual set by using the
+                       "ACTIVE RELEASES DOCUMENTATION" or "DOCUMENTS ARCHIVE"
+                       pull-down menus.
+                       </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>
                </itemizedlist>
            </note>
     </legalnotice>
@@ -156,8 +173,6 @@
 
     <xi:include href="dev-manual-start.xml"/>
 
-    <xi:include href="dev-manual-newbie.xml"/>
-
     <xi:include href="dev-manual-common-tasks.xml"/>
 
     <xi:include href="dev-manual-qemu.xml"/>

documentation/getting-started/getting-started-style.css

@@ -1,988 +0,0 @@
-/*
-   Generic XHTML / DocBook XHTML CSS Stylesheet.
-
-   Browser wrangling and typographic design by
-      Oyvind Kolas / pippin@gimp.org
-
-   Customised for Poky by
-      Matthew Allum / mallum@o-hand.com
-
-   Thanks to:
-     Liam R. E. Quin
-     William Skaggs
-     Jakub Steiner
-
-   Structure
-   ---------
-
-   The stylesheet is divided into the following sections:
-
-       Positioning
-          Margins, paddings, width, font-size, clearing.
-       Decorations
-          Borders, style
-       Colors
-          Colors
-       Graphics
-          Graphical backgrounds
-       Nasty IE tweaks
-          Workarounds needed to make it work in internet explorer,
-          currently makes the stylesheet non validating, but up until
-          this point it is validating.
-       Mozilla extensions
-          Transparency for footer
-	  Rounded corners on boxes
-
-*/
-
-
-  /*************** /
- /  Positioning   /
-/ ***************/
-
-body {
-  font-family: Verdana, Sans, sans-serif;
-
-  min-width: 640px;
-  width: 80%;
-  margin:  0em auto;
-  padding: 2em 5em 5em 5em;
-  color: #333;
-}
-
-h1,h2,h3,h4,h5,h6,h7 {
-  font-family: Arial, Sans;
-  color: #00557D;
-  clear: both;
-}
-
-h1 {
-  font-size: 2em;
-  text-align: left;
-  padding: 0em 0em 0em 0em;
-  margin: 2em 0em 0em 0em;
-}
-
-h2.subtitle {
-  margin: 0.10em 0em 3.0em 0em;
-  padding: 0em 0em 0em 0em;
-  font-size: 1.8em;
-  padding-left: 20%;
-  font-weight: normal;
-  font-style: italic;
-}
-
-h2 {
-  margin: 2em 0em 0.66em 0em;
-  padding: 0.5em 0em 0em 0em;
-  font-size: 1.5em;
-  font-weight: bold;
-}
-
-h3.subtitle {
-  margin: 0em 0em 1em 0em;
-  padding: 0em 0em 0em 0em;
-  font-size: 142.14%;
-  text-align: right;
-}
-
-h3 {
-  margin: 1em 0em 0.5em 0em;
-  padding: 1em 0em 0em 0em;
-  font-size: 140%;
-  font-weight: bold;
-}
-
-h4 {
-  margin: 1em 0em 0.5em 0em;
-  padding: 1em 0em 0em 0em;
-  font-size: 120%;
-  font-weight: bold;
-}
-
-h5 {
-  margin: 1em 0em 0.5em 0em;
-  padding: 1em 0em 0em 0em;
-  font-size: 110%;
-  font-weight: bold;
-}
-
-h6 {
-  margin: 1em 0em 0em 0em;
-  padding: 1em 0em 0em 0em;
-  font-size: 110%;
-  font-weight: bold;
-}
-
-.authorgroup {
-  background-color: transparent;
-  background-repeat: no-repeat;
-  padding-top: 256px;
-  background-image: url("figures/getting-started-title.png");
-  background-position: left top;
-  margin-top: -256px;
-  padding-right: 50px;
-  margin-left: 0px;
-  text-align: right;
-  width: 740px;
-}
-
-h3.author {
-  margin: 0em 0me 0em 0em;
-  padding: 0em 0em 0em 0em;
-  font-weight: normal;
-  font-size: 100%;
-  color: #333;
-  clear: both;
-}
-
-.author tt.email {
-  font-size: 66%;
-}
-
-.titlepage hr {
-  width: 0em;
-  clear: both;
-}
-
-.revhistory {
-  padding-top: 2em;
-  clear: both;
-}
-
-.toc,
-.list-of-tables,
-.list-of-examples,
-.list-of-figures {
-  padding: 1.33em 0em 2.5em 0em;
-  color: #00557D;
-}
-
-.toc p,
-.list-of-tables p,
-.list-of-figures p,
-.list-of-examples p {
-  padding: 0em 0em 0em 0em;
-  padding: 0em 0em 0.3em;
-  margin: 1.5em 0em 0em 0em;
-}
-
-.toc p b,
-.list-of-tables p b,
-.list-of-figures p b,
-.list-of-examples p b{
-  font-size: 100.0%;
-  font-weight: bold;
-}
-
-.toc dl,
-.list-of-tables dl,
-.list-of-figures dl,
-.list-of-examples dl {
-  margin: 0em 0em 0.5em 0em;
-  padding: 0em 0em 0em 0em;
-}
-
-.toc dt {
-  margin: 0em 0em 0em 0em;
-  padding: 0em 0em 0em 0em;
-}
-
-.toc dd {
-  margin: 0em 0em 0em 2.6em;
-  padding: 0em 0em 0em 0em;
-}
-
-div.glossary dl,
-div.variablelist dl {
-}
-
-.glossary dl dt,
-.variablelist dl dt,
-.variablelist dl dt span.term {
-  font-weight: normal;
-  width: 20em;
-  text-align: right;
-}
-
-.variablelist dl dt {
-  margin-top: 0.5em;
-}
-
-.glossary dl dd,
-.variablelist dl dd {
-  margin-top: -1em;
-  margin-left: 25.5em;
-}
-
-.glossary dd p,
-.variablelist dd p {
-  margin-top: 0em;
-  margin-bottom: 1em;
-}
-
-
-div.calloutlist table td {
-  padding: 0em 0em 0em 0em;
-  margin: 0em 0em 0em 0em;
-}
-
-div.calloutlist table td p {
-  margin-top: 0em;
-  margin-bottom: 1em;
-}
-
-div p.copyright {
-  text-align: left;
-}
-
-div.legalnotice p.legalnotice-title {
-  margin-bottom: 0em;
-}
-
-p {
-  line-height: 1.5em;
-  margin-top: 0em;
-
-}
-
-dl {
-  padding-top: 0em;
-}
-
-hr {
-  border: solid 1px;
-}
-
-
-.mediaobject,
-.mediaobjectco {
-  text-align: center;
-}
-
-img {
-  border: none;
-}
-
-ul {
-  padding: 0em 0em 0em 1.5em;
-}
-
-ul li {
-  padding: 0em 0em 0em 0em;
-}
-
-ul li p {
-  text-align: left;
-}
-
-table {
-  width :100%;
-}
-
-th {
-  padding: 0.25em;
-  text-align: left;
-  font-weight: normal;
-  vertical-align: top;
-}
-
-td {
-  padding: 0.25em;
-  vertical-align: top;
-}
-
-p a[id] {
-  margin: 0px;
-  padding: 0px;
-  display: inline;
-  background-image: none;
-}
-
-a {
-  text-decoration: underline;
-  color: #444;
-}
-
-pre {
-    overflow: auto;
-}
-
-a:hover {
-  text-decoration: underline;
-  /*font-weight: bold;*/
-}
-
-/* This style defines how the permalink character
-   appears by itself and when hovered over with
-   the mouse. */
-
-[alt='Permalink'] { color: #eee; }
-[alt='Permalink']:hover { color: black; }
-
-
-div.informalfigure,
-div.informalexample,
-div.informaltable,
-div.figure,
-div.table,
-div.example {
-  margin: 1em 0em;
-  padding: 1em;
-  page-break-inside: avoid;
-}
-
-
-div.informalfigure p.title b,
-div.informalexample p.title b,
-div.informaltable p.title b,
-div.figure p.title b,
-div.example p.title b,
-div.table p.title b{
-    padding-top: 0em;
-    margin-top: 0em;
-    font-size: 100%;
-    font-weight: normal;
-}
-
-.mediaobject .caption,
-.mediaobject .caption p  {
-  text-align: center;
-  font-size: 80%;
-  padding-top: 0.5em;
-  padding-bottom: 0.5em;
-}
-
-.epigraph {
-  padding-left: 55%;
-  margin-bottom: 1em;
-}
-
-.epigraph p {
-  text-align: left;
-}
-
-.epigraph .quote {
-  font-style: italic;
-}
-.epigraph .attribution {
-  font-style: normal;
-  text-align: right;
-}
-
-span.application {
-  font-style: italic;
-}
-
-.programlisting {
-  font-family: monospace;
-  font-size: 80%;
-  white-space: pre;
-  margin: 1.33em 0em;
-  padding: 1.33em;
-}
-
-.tip,
-.warning,
-.caution,
-.note {
-  margin-top: 1em;
-  margin-bottom: 1em;
-
-}
-
-/* force full width of table within div */
-.tip table,
-.warning table,
-.caution table,
-.note table {
-  border: none;
-  width: 100%;
-}
-
-
-.tip table th,
-.warning table th,
-.caution table th,
-.note table th {
-  padding: 0.8em 0.0em 0.0em 0.0em;
-  margin : 0em 0em 0em 0em;
-}
-
-.tip p,
-.warning p,
-.caution p,
-.note p {
-  margin-top: 0.5em;
-  margin-bottom: 0.5em;
-  padding-right: 1em;
-  text-align: left;
-}
-
-.acronym {
-  text-transform: uppercase;
-}
-
-b.keycap,
-.keycap {
-  padding: 0.09em 0.3em;
-  margin: 0em;
-}
-
-.itemizedlist li {
-  clear: none;
-}
-
-.filename {
-  font-size: medium;
-  font-family: Courier, monospace;
-}
-
-
-div.navheader, div.heading{
-  position: absolute;
-  left: 0em;
-  top: 0em;
-  width: 100%;
-  background-color: #cdf;
-  width: 100%;
-}
-
-div.navfooter, div.footing{
-  position: fixed;
-  left: 0em;
-  bottom: 0em;
-  background-color: #eee;
-  width: 100%;
-}
-
-
-div.navheader td,
-div.navfooter td {
-  font-size: 66%;
-}
-
-div.navheader table th {
-  /*font-family: Georgia, Times, serif;*/
-  /*font-size: x-large;*/
-  font-size: 80%;
-}
-
-div.navheader table {
-  border-left: 0em;
-  border-right: 0em;
-  border-top: 0em;
-  width: 100%;
-}
-
-div.navfooter table {
-  border-left: 0em;
-  border-right: 0em;
-  border-bottom: 0em;
-  width: 100%;
-}
-
-div.navheader table td a,
-div.navfooter table td a {
-  color: #777;
-  text-decoration: none;
-}
-
-/* normal text in the footer */
-div.navfooter table td {
-  color: black;
-}
-
-div.navheader table td a:visited,
-div.navfooter table td a:visited {
-  color: #444;
-}
-
-
-/* links in header and footer */
-div.navheader table td a:hover,
-div.navfooter table td a:hover {
-  text-decoration: underline;
-  background-color: transparent;
-  color: #33a;
-}
-
-div.navheader hr,
-div.navfooter hr {
-  display: none;
-}
-
-
-.qandaset tr.question td p {
-  margin: 0em 0em 1em 0em;
-  padding: 0em 0em 0em 0em;
-}
-
-.qandaset tr.answer td p {
-  margin: 0em 0em 1em 0em;
-  padding: 0em 0em 0em 0em;
-}
-.answer td {
-  padding-bottom: 1.5em;
-}
-
-.emphasis {
-  font-weight: bold;
-}
-
-
-  /************* /
- / decorations  /
-/ *************/
-
-.titlepage {
-}
-
-.part .title {
-}
-
-.subtitle {
-    border: none;
-}
-
-/*
-h1 {
-  border: none;
-}
-
-h2 {
-  border-top: solid 0.2em;
-  border-bottom: solid 0.06em;
-}
-
-h3 {
-  border-top: 0em;
-  border-bottom: solid 0.06em;
-}
-
-h4 {
-  border: 0em;
-  border-bottom: solid 0.06em;
-}
-
-h5 {
-  border: 0em;
-}
-*/
-
-.programlisting {
-  border: solid 1px;
-}
-
-div.figure,
-div.table,
-div.informalfigure,
-div.informaltable,
-div.informalexample,
-div.example {
-  border: 1px solid;
-}
-
-
-
-.tip,
-.warning,
-.caution,
-.note {
-  border: 1px solid;
-}
-
-.tip table th,
-.warning table th,
-.caution table th,
-.note table th {
-  border-bottom: 1px solid;
-}
-
-.question td {
-  border-top: 1px solid black;
-}
-
-.answer {
-}
-
-
-b.keycap,
-.keycap {
-  border: 1px solid;
-}
-
-
-div.navheader, div.heading{
-  border-bottom: 1px solid;
-}
-
-
-div.navfooter, div.footing{
-  border-top: 1px solid;
-}
-
-  /********* /
- /  colors  /
-/ *********/
-
-body {
-  color: #333;
-  background: white;
-}
-
-a {
-  background: transparent;
-}
-
-a:hover {
-  background-color: #dedede;
-}
-
-
-h1,
-h2,
-h3,
-h4,
-h5,
-h6,
-h7,
-h8 {
-  background-color: transparent;
-}
-
-hr {
-  border-color: #aaa;
-}
-
-
-.tip, .warning, .caution, .note {
-  border-color: #fff;
-}
-
-
-.tip table th,
-.warning table th,
-.caution table th,
-.note table th {
-  border-bottom-color: #fff;
-}
-
-
-.warning {
-  background-color: #f0f0f2;
-}
-
-.caution {
-  background-color: #f0f0f2;
-}
-
-.tip {
-  background-color: #f0f0f2;
-}
-
-.note {
-  background-color: #f0f0f2;
-}
-
-.glossary dl dt,
-.variablelist dl dt,
-.variablelist dl dt span.term {
-  color: #044;
-}
-
-div.figure,
-div.table,
-div.example,
-div.informalfigure,
-div.informaltable,
-div.informalexample {
-  border-color: #aaa;
-}
-
-pre.programlisting {
-  color: black;
-  background-color: #fff;
-  border-color: #aaa;
-  border-width: 2px;
-}
-
-.guimenu,
-.guilabel,
-.guimenuitem {
-  background-color: #eee;
-}
-
-
-b.keycap,
-.keycap {
-  background-color: #eee;
-  border-color: #999;
-}
-
-
-div.navheader {
-  border-color: black;
-}
-
-
-div.navfooter {
-  border-color: black;
-}
-
-.writernotes {
-  color: red;
-}
-
-
-  /*********** /
- /  graphics  /
-/ ***********/
-
-/*
-body {
-  background-image: url("images/body_bg.jpg");
-  background-attachment: fixed;
-}
-
-.navheader,
-.note,
-.tip {
-  background-image: url("images/note_bg.jpg");
-  background-attachment: fixed;
-}
-
-.warning,
-.caution {
-  background-image: url("images/warning_bg.jpg");
-  background-attachment: fixed;
-}
-
-.figure,
-.informalfigure,
-.example,
-.informalexample,
-.table,
-.informaltable {
-  background-image: url("images/figure_bg.jpg");
-  background-attachment: fixed;
-}
-
-*/
-h1,
-h2,
-h3,
-h4,
-h5,
-h6,
-h7{
-}
-
-/*
-Example of how to stick an image as part of the title.
-
-div.article .titlepage .title
-{
-  background-image: url("figures/white-on-black.png");
-  background-position: center;
-  background-repeat: repeat-x;
-}
-*/
-
-div.preface .titlepage .title,
-div.colophon .title,
-div.chapter .titlepage .title,
-div.article .titlepage .title
-{
-}
-
-div.section div.section .titlepage .title,
-div.sect2 .titlepage .title {
-    background: none;
-}
-
-
-h1.title {
-  background-color: transparent;
-  background-repeat: no-repeat;
-  height: 256px;
-  text-indent: -9000px;
-  overflow:hidden;
-}
-
-h2.subtitle {
-  background-color: transparent;
-  text-indent: -9000px;
-  overflow:hidden;
-  width: 0px;
-  display: none;
-}
-
-  /*************************************** /
- /  pippin.gimp.org specific alterations  /
-/ ***************************************/
-
-/*
-div.heading, div.navheader {
-  color: #777;
-  font-size: 80%;
-  padding: 0;
-  margin: 0;
-  text-align: left;
-  position: absolute;
-  top: 0px;
-  left: 0px;
-  width: 100%;
-  height: 50px;
-  background: url('/gfx/heading_bg.png') transparent;
-  background-repeat: repeat-x;
-  background-attachment: fixed;
-  border: none;
-}
-
-div.heading a {
-  color: #444;
-}
-
-div.footing, div.navfooter {
-  border: none;
-  color: #ddd;
-  font-size: 80%;
-  text-align:right;
-
-  width: 100%;
-  padding-top: 10px;
-  position: absolute;
-  bottom: 0px;
-  left: 0px;
-
-  background: url('/gfx/footing_bg.png') transparent;
-}
-*/
-
-
-
-  /****************** /
- /  nasty ie tweaks  /
-/ ******************/
-
-/*
-div.heading, div.navheader {
-  width:expression(document.body.clientWidth + "px");
-}
-
-div.footing, div.navfooter {
-  width:expression(document.body.clientWidth + "px");
-  margin-left:expression("-5em");
-}
-body {
-  padding:expression("4em 5em 0em 5em");
-}
-*/
-
-  /**************************************** /
- / mozilla vendor specific css extensions  /
-/ ****************************************/
-/*
-div.navfooter, div.footing{
-  -moz-opacity: 0.8em;
-}
-
-div.figure,
-div.table,
-div.informalfigure,
-div.informaltable,
-div.informalexample,
-div.example,
-.tip,
-.warning,
-.caution,
-.note {
-  -moz-border-radius: 0.5em;
-}
-
-b.keycap,
-.keycap {
-  -moz-border-radius: 0.3em;
-}
-*/
-
-table tr td table tr td {
-  display: none;
-}
-
-
-hr {
-  display: none;
-}
-
-table {
-  border: 0em;
-}
-
- .photo {
-  float: right;
-  margin-left:   1.5em;
-  margin-bottom: 1.5em;
-  margin-top: 0em;
-  max-width:      17em;
-  border:     1px solid gray;
-  padding:    3px;
-  background: white;
-}
- .seperator {
-   padding-top: 2em;
-   clear: both;
-  }
-
-  #validators {
-      margin-top: 5em;
-      text-align: right;
-      color: #777;
-  }
-  @media print {
-      body {
-          font-size: 8pt;
-      }
-      .noprint {
-          display: none;
-      }
-  }
-
-
-.tip,
-.note {
-   background: #f0f0f2;
-   color: #333;
-   padding: 20px;
-   margin: 20px;
-}
-
-.tip h3,
-.note h3 {
-   padding: 0em;
-   margin: 0em;
-   font-size: 2em;
-   font-weight: bold;
-   color: #333;
-}
-
-.tip a,
-.note a {
-   color: #333;
-   text-decoration: underline;
-}
-
-.footnote {
-   font-size: small;
-   color: #333;
-}
-
-/* Changes the announcement text */
-.tip h3,
-.warning h3,
-.caution h3,
-.note h3 {
-   font-size:large;
-   color: #00557D;
-}

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

@@ -21,7 +21,7 @@
     <para>
         Kernel Metadata exists in many places.
         One area in the Yocto Project
-        <ulink url='&YOCTO_DOCS_GS_URL;#source-repositories'>Source Repositories</ulink>
+        <ulink url='&YOCTO_DOCS_OM_URL;#source-repositories'>Source Repositories</ulink>
         is the <filename>yocto-kernel-cache</filename> Git repository.
         You can find this repository grouped under the "Yocto Linux Kernel"
         heading in the
@@ -64,8 +64,7 @@
         <ulink url='&YOCTO_DOCS_REF_URL;#var-KMACHINE'><filename>KMACHINE</filename></ulink>
         variable.
         This variable is typically set to the same value as the
-        <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink>
-        variable, which is used by
+        <filename>MACHINE</filename> variable, which is used by
         <ulink url='&YOCTO_DOCS_REF_URL;#bitbake-term'>BitBake</ulink>.
         However, in some cases, the variable might instead refer to the
         underlying platform of the <filename>MACHINE</filename>.
@@ -77,8 +76,7 @@
         Multiple Corei7-based BSPs could share the same "intel-corei7-64"
         value for <filename>KMACHINE</filename>.
         It is important to realize that <filename>KMACHINE</filename> is
-        just for kernel mapping, while
-        <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink>
+        just for kernel mapping, while <filename>MACHINE</filename>
         is the machine type within a BSP Layer.
         Even with this distinction, however, these two variables can hold
         the same value.
@@ -116,8 +114,7 @@
         used in assembling the configuration.
         If you do not specify a <filename>LINUX_KERNEL_TYPE</filename>,
         it defaults to "standard".
-        Together with
-        <ulink url='&YOCTO_DOCS_REF_URL;#var-KMACHINE'><filename>KMACHINE</filename></ulink>,
+        Together with <filename>KMACHINE</filename>,
         <filename>LINUX_KERNEL_TYPE</filename> defines the search
         arguments used by the kernel tools to find the
         appropriate description within the kernel Metadata with which to
@@ -644,8 +641,7 @@
             aggregation concepts, and presents a detailed example using
             a BSP supported by the Yocto Project (i.e. BeagleBone Board).
             For complete information on BSP layer file hierarchy, see the
-            <ulink url='&YOCTO_DOCS_BSP_URL;'>Yocto Project Board Support
-            Package (BSP) Developer's Guide</ulink>.
+            <ulink url='&YOCTO_DOCS_BSP_URL;'>Yocto Project Board Support Package (BSP) Developer's Guide</ulink>.
         </para>
 
         <section id='bsp-description-file-overview'>
@@ -856,7 +852,7 @@
 
             <para>
                 Now consider the "minnow" description for the "tiny" kernel
-                type (i.e. <filename>minnow-tiny.scc</filename>:
+                type (i.e. <filename>minnow-tiny.scc</filename>):
                 <literallayout class='monospaced'>
         define KMACHINE minnow
         define KTYPE tiny
@@ -1018,8 +1014,7 @@
 
         <para>
             If you modify the Metadata, you must not forget to update the
-            <ulink url='&YOCTO_DOCS_REF_URL;#var-SRCREV'><filename>SRCREV</filename></ulink>
-            statements in the kernel's recipe.
+            <filename>SRCREV</filename> statements in the kernel's recipe.
             In particular, you need to update the
             <filename>SRCREV_meta</filename> variable to match the commit in
             the <filename>KMETA</filename> branch you wish to use.
@@ -1227,9 +1222,13 @@
                 </para></listitem>
             <listitem><para>
                 <filename>define</filename>:
-                Defines variables, such as <filename>KMACHINE</filename>,
-                <filename>KTYPE</filename>, <filename>KARCH</filename>,
-                and <filename>KFEATURE_DESCRIPTION</filename>.</para></listitem>
+                Defines variables, such as
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-KMACHINE'><filename>KMACHINE</filename></ulink>,
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-KTYPE'><filename>KTYPE</filename></ulink>,
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-KARCH'><filename>KARCH</filename></ulink>,
+                and
+                <ulink url='&YOCTO_DOCS_REF_URL;#var-KFEATURE_DESCRIPTION'><filename>KFEATURE_DESCRIPTION</filename></ulink>.
+                </para></listitem>
             <listitem><para>
                 <filename>include SCC_FILE</filename>:
                 Includes an SCC file in the current file.

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

@@ -25,7 +25,7 @@
             Before you can do any kernel development, you need to be
             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>"
+            "<ulink url='&YOCTO_DOCS_DEV_URL;#setting-up-the-development-host-to-use-the-yocto-project'>Preparing the Build Host</ulink>"
             section in the Yocto Project Development Tasks Manual.
             Part of preparing the system is creating a local Git
             repository of the
@@ -79,7 +79,7 @@
                         </literallayout>
                         <note>
                             The previous commands assume the
-                            <ulink url='&YOCTO_DOCS_GS_URL;#source-repositories'>Source Repositories</ulink>
+                            <ulink url='&YOCTO_DOCS_OM_URL;#source-repositories'>Source Repositories</ulink>
                             (i.e. <filename>poky</filename>) have been cloned
                             using Git and the local repository is named
                             "poky".
@@ -303,7 +303,7 @@
                         </literallayout>
                         <note>
                             The previous commands assume the
-                            <ulink url='&YOCTO_DOCS_GS_URL;#source-repositories'>Source Repositories</ulink>
+                            <ulink url='&YOCTO_DOCS_OM_URL;#source-repositories'>Source Repositories</ulink>
                             (i.e. <filename>poky</filename>) have been cloned
                             using Git and the local repository is named
                             "poky".
@@ -387,7 +387,7 @@
                         You can find Git repositories of supported Yocto Project
                         kernels organized under "Yocto Linux Kernel" in the
                         Yocto Project Source Repositories at
-                        <ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink>.
+                        <ulink url='&YOCTO_GIT_URL;'></ulink>.
                         </para>
 
                         <para>
@@ -1402,9 +1402,9 @@
      SRC_URI_append = " file://0001-calibrate.c-Added-some-printk-statements.patch"
                     </literallayout>
                     The
-                    <ulink url='&YOCTO_DOCS_REF_URL;var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></ulink>
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-FILESEXTRAPATHS'><filename>FILESEXTRAPATHS</filename></ulink>
                     and
-                    <ulink url='&YOCTO_DOCS_REF_URL;var-SRC_URI'><filename>SRC_URI</filename></ulink>
+                    <ulink url='&YOCTO_DOCS_REF_URL;#var-SRC_URI'><filename>SRC_URI</filename></ulink>
                     statements enable the OpenEmbedded build system to find
                     the patch file.</para>
 
@@ -1656,7 +1656,7 @@
                     after applying the existing defconfig file configurations.
                 </note>
                 For more information on configuring the kernel, see the
-                "<link link='changing-the-configuration'>Changing the Configuration</link>"
+                "<link linkend='changing-the-configuration'>Changing the Configuration</link>"
                 section.
             </para>
         </section>
@@ -2418,7 +2418,7 @@
                 modules.
                 If your module <filename>Makefile</filename> uses a different
                 variable, you might want to override the
-                <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-compile'><filename>do_compile()</filename></ulink>
+                <ulink url='&YOCTO_DOCS_REF_URL;#ref-tasks-compile'><filename>do_compile</filename></ulink>
                 step, or create a patch to
                 the <filename>Makefile</filename> to work with the more typical
                 <filename>KERNEL_SRC</filename> or
@@ -2494,7 +2494,7 @@
                     the Git commands.
                     You can see the branch names through the web interface
                     to the Yocto Project source repositories at
-                    <ulink url='http://git.yoctoproject.org/cgit.cgi'></ulink>.
+                    <ulink url='&YOCTO_GIT_URL;'></ulink>.
                 </note>
                 To see a full range of the changes, use the
                 <filename>git whatchanged</filename> command and specify a

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

@@ -49,7 +49,7 @@
 
         <para>
             You can find a web interface to the Yocto Linux kernels in the
-            <ulink url='&YOCTO_DOCS_GS_URL;#source-repositories'>Source Repositories</ulink>
+            <ulink url='&YOCTO_DOCS_OM_URL;#source-repositories'>Source Repositories</ulink>
             at
             <ulink url='&YOCTO_GIT_URL;'></ulink>.
             If you look at the interface, you will see to the left a
@@ -239,8 +239,8 @@
                         <ulink url='http://git-scm.com/documentation'></ulink>.
                         You can also get an introduction to Git as it
                         applies to the Yocto Project in the
-                        "<ulink url='&YOCTO_DOCS_GS_URL;#git'>Git</ulink>"
-                        section in the Getting Started With Yocto Project
+                        "<ulink url='&YOCTO_DOCS_OM_URL;#git'>Git</ulink>"
+                        section in the Yocto Project Overview and Concepts
                         Manual.
                         The latter reference provides an overview of
                         Git and presents a minimal set of Git commands
@@ -382,7 +382,7 @@
                 generic kernel just for conceptual purposes.
                 Also keep in mind that this structure represents the Yocto
                 Project
-                <ulink url='&YOCTO_DOCS_GS_URL;#source-repositories'>Source Repositories</ulink>
+                <ulink url='&YOCTO_DOCS_OM_URL;#source-repositories'>Source Repositories</ulink>
                 that are either pulled from during the build or established
                 on the host development system prior to the build by either
                 cloning a particular kernel's Git repository or by

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

@@ -108,7 +108,11 @@
         review and understand the following documentation:
         <itemizedlist>
             <listitem><para>
-                <ulink url='&YOCTO_DOCS_QS_URL;'>Yocto Project Quick Start</ulink>
+                <ulink url='&YOCTO_DOCS_BRIEF_URL;'>Yocto Project Quick Build</ulink>
+                document.
+                </para></listitem>
+            <listitem><para>
+                <ulink url='&YOCTO_DOCS_OM_URL;'>Yocto Project Overview and Concepts Manual</ulink>.
                 </para></listitem>
             <listitem><para>
                 <ulink url='&YOCTO_DOCS_SDK_URL;#using-devtool-in-your-sdk-workflow'><filename>devtool</filename> workflow</ulink>
@@ -153,12 +157,15 @@
     <para>
         <orderedlist>
             <listitem><para>
-                <emphasis>Set Up Your Host Development System to Support
-                Development Using the Yocto Project:</emphasis>
+
+
+                <emphasis>Set up Your Host Development System to Support
+                Development Using the Yocto Project</emphasis>:
                 See the
-                "<ulink url='&YOCTO_DOCS_QS_URL;#yp-resources'>Setting Up to Use the Yocto Project</ulink>"
-                section in the Yocto Project Quick Start for options on how
-                to get a build host ready to use the Yocto Project.
+                "<ulink url='&YOCTO_DOCS_DEV_URL;#dev-manual-start'>Setting Up the Development Host to Use the Yocto Project</ulink>"
+                section in the Yocto Project Development Tasks Manual for
+                options on how to get a build host ready to use the Yocto
+                Project.
                 </para></listitem>
             <listitem><para>
                 <emphasis>Set Up Your Host Development System for Kernel Development:</emphasis>

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

@@ -14,7 +14,7 @@
             create Yocto Linux kernel repositories.
             These kernel repositories are found under the heading "Yocto Linux
             Kernel" at
-            <ulink url='&YOCTO_GIT_URL;/cgit.cgi'>&YOCTO_GIT_URL;/cgit.cgi</ulink>
+            <ulink url='&YOCTO_GIT_URL;'>&YOCTO_GIT_URL;</ulink>
             and are shipped as part of a Yocto Project release.
             The team creates these repositories by compiling and executing the
             set of feature descriptions for every BSP and feature in the
@@ -118,7 +118,7 @@
             The following steps describe what happens when the Yocto Project
             Team constructs the Yocto Project kernel source Git repository
             (or tree) found at
-            <ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink> given the
+            <ulink url='&YOCTO_GIT_URL;'></ulink> given the
             introduction of a new top-level kernel feature or BSP.
             The following actions effectively provide the Metadata
             and create the tree that includes the new feature, patch, or BSP:
@@ -217,7 +217,7 @@
                         end of an existing branch.
                         The full repository generation that is found in the
                         official Yocto Project kernel repositories at
-                        <ulink url='&YOCTO_GIT_URL;/cgit.cgi'>http://git.yoctoproject.org/cgit.cgi</ulink>
+                        <ulink url='&YOCTO_GIT_URL;'>http://git.yoctoproject.org</ulink>
                         is the combination of all supported boards and
                         configurations.
                         </para></listitem>
@@ -231,7 +231,7 @@
                         </para></listitem>
                     <listitem><para>
                         The full kernel tree that you see on
-                        <ulink url='&YOCTO_GIT_URL;/cgit.cgi'></ulink> is
+                        <ulink url='&YOCTO_GIT_URL;'></ulink> is
                         generated through repeating the above steps for all
                         valid BSPs.
                         The end result is a branched, clean history tree that

documentation/kernel-dev/kernel-dev.xml

@@ -88,9 +88,14 @@
             </revision>
             <revision>
                 <revnumber>2.5</revnumber>
-                <date>April 2018</date>
+                <date>May 2018</date>
                 <revremark>Released with the Yocto Project 2.5 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>2.6</revnumber>
+                <date>&REL_MONTH_YEAR;</date>
+                <revremark>Released with the Yocto Project 2.6 Release.</revremark>
+            </revision>
         </revhistory>
 
     <copyright>
@@ -111,24 +116,36 @@
                        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
+                       for this release, 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.
+                       and select the manual from that site.
+                       Manuals from the site are more up-to-date than manuals
+                       derived from the Yocto Project released TAR files.
                        </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>
+                       If you located this manual through a web search, the
+                       version of the manual might not be the one you want
+                       (e.g. the search might have returned a manual much
+                       older than the Yocto Project version with which you
+                       are working).
+                       You can see all Yocto Project major releases by
+                       visiting the
+                       <ulink url='&YOCTO_WIKI_URL;/wiki/Releases'>Releases</ulink>
+                       page.
+                       If you need a version of this manual for a different
+                       Yocto Project release, visit the
+                       <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink>
+                       and select the manual set by using the
+                       "ACTIVE RELEASES DOCUMENTATION" or "DOCUMENTS ARCHIVE"
+                       pull-down menus.
+                       </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>
                </itemizedlist>
            </note>
     </legalnotice>

documentation/mega-manual/mega-manual.xml

@@ -72,9 +72,14 @@
             </revision>
             <revision>
                 <revnumber>2.5</revnumber>
-                <date>April 2018</date>
+                <date>May 2018</date>
                 <revremark>Released with the Yocto Project 2.5 Release.</revremark>
             </revision>
+            <revision>
+                <revnumber>2.6</revnumber>
+                <date>&REL_MONTH_YEAR;</date>
+                <revremark>Released with the Yocto Project 2.6 Release.</revremark>
+            </revision>
        </revhistory>
 
     <copyright>
@@ -95,24 +100,36 @@
                        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
+                       for this release, 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.
+                       and select the manual from that site.
+                       Manuals from the site are more up-to-date than manuals
+                       derived from the Yocto Project released TAR files.
                        </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>
+                       If you located this manual through a web search, the
+                       version of the manual might not be the one you want
+                       (e.g. the search might have returned a manual much
+                       older than the Yocto Project version with which you
+                       are working).
+                       You can see all Yocto Project major releases by
+                       visiting the
+                       <ulink url='&YOCTO_WIKI_URL;/wiki/Releases'>Releases</ulink>
+                       page.
+                       If you need a version of this manual for a different
+                       Yocto Project release, visit the
+                       <ulink url='&YOCTO_HOME_URL;/documentation'>Yocto Project documentation page</ulink>
+                       and select the manual set by using the
+                       "ACTIVE RELEASES DOCUMENTATION" or "DOCUMENTS ARCHIVE"
+                       pull-down menus.
+                       </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>
                </itemizedlist>
            </note>
 
@@ -120,41 +137,32 @@
 
     </bookinfo>
 
-<!-- Includes yocto-project-qs -->
+<!-- Includes brief-yoctoprojectqs -->
 
     <para>
-        <imagedata fileref="figures/ypqs-title.png" width="100%" align="left" scalefit="1" />
+        <imagedata fileref="figures/bypqs-title.png" width="100%" align="left" scalefit="1" />
     </para>
 
     <xi:include
-        xmlns:xi="http://www.w3.org/2003/XInclude" href="../yocto-project-qs/qs.xml"/>
+        xmlns:xi="http://www.w3.org/2003/XInclude" href="../brief-yoctoprojectqs/brief-yoctoprojectqs.xml"/>
 
-<!-- Includes getting-started title image and then getting-started chapters -->
+<!-- Includes overview-manual title image and then overview-manual chapters -->
 
     <para>
-        <imagedata fileref="figures/getting-started-title.png" width="100%" align="left" scalefit="1" />
+        <imagedata fileref="figures/overview-manual-title.png" width="100%" align="left" scalefit="1" />
     </para>
 
     <xi:include
-        xmlns:xi="http://www.w3.org/2003/XInclude" href="../getting-started/getting-started-intro.xml"/>
+        xmlns:xi="http://www.w3.org/2003/XInclude" href="../overview-manual/overview-manual-intro.xml"/>
 
     <xi:include
-        xmlns:xi="http://www.w3.org/2003/XInclude" href="../getting-started/getting-started-yp-intro.xml"/>
+        xmlns:xi="http://www.w3.org/2003/XInclude" href="../overview-manual/overview-manual-yp-intro.xml"/>
 
     <xi:include
-        xmlns:xi="http://www.w3.org/2003/XInclude" href="../getting-started/getting-started-development-environment.xml"/>
-
-<!-- Includes concepts-manual title image and then concepts-manual chapters -->
-
-    <para>
-        <imagedata fileref="figures/concepts-manual-title.png" width="100%" align="left" scalefit="1" />
-    </para>
+        xmlns:xi="http://www.w3.org/2003/XInclude" href="../overview-manual/overview-manual-development-environment.xml"/>
 
     <xi:include
-        xmlns:xi="http://www.w3.org/2003/XInclude" href="../concepts-manual/concepts-manual-intro.xml"/>
-
-    <xi:include
-        xmlns:xi="http://www.w3.org/2003/XInclude" href="../concepts-manual/concepts-manual-concepts.xml"/>
+        xmlns:xi="http://www.w3.org/2003/XInclude" href="../overview-manual/overview-manual-concepts.xml"/>
 
 <!-- Includes dev-manual title image and then dev-manual chapters -->
 
@@ -166,8 +174,6 @@
         xmlns:xi="http://www.w3.org/2003/XInclude" href="../dev-manual/dev-manual-intro.xml"/>
     <xi:include
         xmlns:xi="http://www.w3.org/2003/XInclude" href="../dev-manual/dev-manual-start.xml"/>
-    <xi:include
-        xmlns:xi="http://www.w3.org/2003/XInclude" href="../dev-manual/dev-manual-newbie.xml"/>
     <xi:include
         xmlns:xi="http://www.w3.org/2003/XInclude" href="../dev-manual/dev-manual-common-tasks.xml"/>
     <xi:include
@@ -196,7 +202,7 @@
     <xi:include
         xmlns:xi="http://www.w3.org/2003/XInclude" href="../sdk-manual/sdk-appendix-customizing-standard.xml"/>
     <xi:include
-        xmlns:xi="http://www.w3.org/2003/XInclude" href="../sdk-manual/sdk-appendix-mars.xml"/>
+        xmlns:xi="http://www.w3.org/2003/XInclude" href="../sdk-manual/sdk-appendix-neon.xml"/>
 
 <!-- Includes bsp-guide title image and then bsp-guide chapters -->