meta-yocto-bsp: bump to the latest linux stable kernel for edgerouter/beaglebone

Bump to the latest stable kernel for 4.14 and 4.15 for edgerouter/beaglebone
to fix gcc8 build issues.

(From meta-yocto rev: c5e07b460cf9477181d2dcde8ea93daeeacc9a2e)

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

.gitignore

@@ -22,6 +22,9 @@ hob-image-*.bb
 /documentation/*/*.html
 /documentation/*/*.pdf
 /documentation/*/*.tgz
+/bitbake/doc/bitbake-user-manual/bitbake-user-manual.html
+/bitbake/doc/bitbake-user-manual/bitbake-user-manual.pdf
+/bitbake/doc/bitbake-user-manual/bitbake-user-manual.tgz
 pull-*/
 bitbake/lib/toaster/contrib/tts/backlog.txt
 bitbake/lib/toaster/contrib/tts/log/*

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/bin/toaster

@@ -68,7 +68,7 @@ webserverKillAll()
         if [ -f ${pidfile} ]; then
             pid=`cat ${pidfile}`
             while kill -0 $pid 2>/dev/null; do
-                kill -SIGTERM -$pid 2>/dev/null
+                kill -SIGTERM $pid 2>/dev/null
                 sleep 1
             done
             rm  ${pidfile}
@@ -91,7 +91,7 @@ webserverStartAll()
 
     echo "Starting webserver..."
 
-    $MANAGE runserver "$ADDR_PORT" \
+    $MANAGE runserver --noreload "$ADDR_PORT" \
            </dev/null >>${BUILDDIR}/toaster_web.log 2>&1 \
            & echo $! >${BUILDDIR}/.toastermain.pid
 

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

@@ -781,7 +781,7 @@
             The code in <filename>meta/lib/oe/sstatesig.py</filename> shows two examples
             of this and also illustrates how you can insert your own policy into the system
             if so desired.
-            This file defines the two basic signature generators OpenEmbedded Core
+            This file defines the two basic signature generators OpenEmbedded-Core
             uses:  "OEBasic" and "OEBasicHash".
             By default, there is a dummy "noop" signature handler enabled in BitBake.
             This means that behavior is unchanged from previous versions.

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

@@ -2651,53 +2651,71 @@
             OpenEmbedded metadata-based example.
         </para>
 
-<!--
         <para>
-            Bug 12030: This list is a place holder of content existed from previous work
-            on the manual.
-            Some or all of it probably needs integrated into the subsections
-            that make up this section.
-            For now, I have just provided a short glossary-like description
-            for each variable.
+            These checksums are stored in
+            <link linkend='var-STAMP'><filename>STAMP</filename></link>.
+            You can examine the checksums using the following BitBake command:
+            <literallayout class='monospaced'>
+     $ bitbake-dumpsigs
+            </literallayout>
+            This command returns the signature data in a readable format
+            that allows you to examine the inputs used when the
+            OpenEmbedded build system generates signatures.
+            For example, using <filename>bitbake-dumpsigs</filename>
+            allows you to examine the <filename>do_compile</filename>
+            task's “sigdata” for a C application (e.g.
+            <filename>bash</filename>).
+            Running the command also reveals that the “CC” variable is part of
+            the inputs that are hashed.
+            Any changes to this variable would invalidate the stamp and
+            cause the <filename>do_compile</filename> task to run.
         </para>
--->
 
         <para>
             The following list describes related variables:
             <itemizedlist>
-                <listitem><para><filename>STAMP</filename>:
-                    The base path to create stamp files.</para></listitem>
-                <listitem><para><filename>STAMPCLEAN</filename>
-                    Again, the base path to create stamp files but can use wildcards
-                    for matching a range of files for clean operations.
-                    </para></listitem>
-                <listitem><para><filename>BB_STAMP_WHITELIST</filename>
-                    Lists stamp files that are looked at when the stamp policy
-                    is "whitelist".
-                    </para></listitem>
-                <listitem><para><filename>BB_STAMP_POLICY</filename>
-                    Defines the mode for comparing timestamps of stamp files.
-                    </para></listitem>
-                <listitem><para><filename>BB_HASHCHECK_FUNCTION</filename>
+                <listitem><para>
+                    <link linkend='var-BB_HASHCHECK_FUNCTION'><filename>BB_HASHCHECK_FUNCTION</filename></link>:
                     Specifies the name of the function to call during
                     the "setscene" part of the task's execution in order
                     to validate the list of task hashes.
                     </para></listitem>
-                <listitem><para><filename>BB_SETSCENE_VERIFY_FUNCTION2</filename>
-                    Specifies a function to call that verifies the list of
-                    planned task execution before the main task execution
-                    happens.
-                    </para></listitem>
-                <listitem><para><filename>BB_SETSCENE_DEPVALID</filename>
+                <listitem><para>
+                    <link linkend='var-BB_SETSCENE_DEPVALID'><filename>BB_SETSCENE_DEPVALID</filename></link>:
                     Specifies a function BitBake calls that determines
                     whether BitBake requires a setscene dependency to
                     be met.
                     </para></listitem>
-                <listitem><para><filename>BB_TASKHASH</filename>
+                <listitem><para>
+                    <link linkend='var-BB_SETSCENE_VERIFY_FUNCTION2'><filename>BB_SETSCENE_VERIFY_FUNCTION2</filename></link>:
+                    Specifies a function to call that verifies the list of
+                    planned task execution before the main task execution
+                    happens.
+                    </para></listitem>
+                <listitem><para>
+                    <link linkend='var-BB_STAMP_POLICY'><filename>BB_STAMP_POLICY</filename></link>:
+                    Defines the mode for comparing timestamps of stamp files.
+                    </para></listitem>
+                <listitem><para>
+                    <link linkend='var-BB_STAMP_WHITELIST'><filename>BB_STAMP_WHITELIST</filename></link>:
+                    Lists stamp files that are looked at when the stamp policy
+                    is "whitelist".
+                    </para></listitem>
+                <listitem><para>
+                    <link linkend='var-BB_TASKHASH'><filename>BB_TASKHASH</filename></link>:
                     Within an executing task, this variable holds the hash
                     of the task as returned by the currently enabled
                     signature generator.
                     </para></listitem>
+                <listitem><para>
+                    <link linkend='var-STAMP'><filename>STAMP</filename></link>:
+                    The base path to create stamp files.
+                    </para></listitem>
+                <listitem><para>
+                    <link linkend='var-STAMPCLEAN'><filename>STAMPCLEAN</filename></link>:
+                    Again, the base path to create stamp files but can use wildcards
+                    for matching a range of files for clean operations.
+                    </para></listitem>
             </itemizedlist>
         </para>
     </section>

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

@@ -78,7 +78,7 @@
                 </para>
 
                 <para>
-                    In OpenEmbedded Core, <filename>ASSUME_PROVIDED</filename>
+                    In OpenEmbedded-Core, <filename>ASSUME_PROVIDED</filename>
                     mostly specifies native tools that should not be built.
                     An example is <filename>git-native</filename>, which
                     when specified allows for the Git binary from the host to
@@ -964,7 +964,7 @@
                     Allows you to extend a recipe so that it builds variants
                     of the software.
                     Some examples of these variants for recipes from the
-                    OpenEmbedded Core metadata are "natives" such as
+                    OpenEmbedded-Core metadata are "natives" such as
                     <filename>quilt-native</filename>, which is a copy of
                     Quilt built to run on the build system; "crosses" such
                     as <filename>gcc-cross</filename>, which is a compiler
@@ -980,7 +980,7 @@
                     amount of code, it usually is as simple as adding the
                     variable to your recipe.
                     Here are two examples.
-                    The "native" variants are from the OpenEmbedded Core
+                    The "native" variants are from the OpenEmbedded-Core
                     metadata:
                     <literallayout class='monospaced'>
      BBCLASSEXTEND =+ "native nativesdk"

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

@@ -396,6 +396,8 @@ class CookerDataBuilder(object):
                 if compat and not (compat & layerseries):
                     bb.fatal("Layer %s is not compatible with the core layer which only supports these series: %s (layer is compatible with %s)"
                               % (c, " ".join(layerseries), " ".join(compat)))
+                elif not compat and not data.getVar("BB_WORKERCONTEXT"):
+                    bb.warn("Layer %s should set LAYERSERIES_COMPAT_%s in its conf/layer.conf file to list the core layer names it is compatible with." % (c, c))
 
         if not data.getVar("BBPATH"):
             msg = "The BBPATH variable is not set"

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:

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

@@ -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:
@@ -595,7 +595,8 @@ class Git(FetchMethod):
         tagregex = re.compile(d.getVar('UPSTREAM_CHECK_GITTAGREGEX') or "(?P<pver>([0-9][\.|_]?)+)")
         try:
             output = self._lsremote(ud, d, "refs/tags/*")
-        except bb.fetch2.FetchError or bb.fetch2.NetworkAccess:
+        except (bb.fetch2.FetchError, bb.fetch2.NetworkAccess) as e:
+            bb.note("Could not list remote: %s" % str(e))
             return pupver
 
         verstring = ""

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

@@ -1,820 +0,0 @@
-# ex:ts=4:sw=4:sts=4:et
-# -*- tab-width: 4; c-basic-offset: 4; indent-tabs-mode: nil -*-
-##########################################################################
-#
-# Copyright (C) 2005-2006 Michael 'Mickey' Lauer <mickey@Vanille.de>
-# Copyright (C) 2005-2006 Vanille Media
-#
-# This program is free software; you can redistribute it and/or modify
-# it under the terms of the GNU General Public License version 2 as
-# published by the Free Software Foundation.
-#
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License along
-# with this program; if not, write to the Free Software Foundation, Inc.,
-# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
-#
-##########################################################################
-#
-# Thanks to:
-# * Holger Freyther <zecke@handhelds.org>
-# * Justin Patrin <papercrane@reversefold.com>
-#
-##########################################################################
-
-"""
-BitBake Shell
-
-IDEAS:
-    * list defined tasks per package
-    * list classes
-    * toggle force
-    * command to reparse just one (or more) bbfile(s)
-    * automatic check if reparsing is necessary (inotify?)
-    * frontend for bb file manipulation
-    * more shell-like features:
-        - output control, i.e. pipe output into grep, sort, etc.
-        - job control, i.e. bring running commands into background and foreground
-    * start parsing in background right after startup
-    * ncurses interface
-
-PROBLEMS:
-    * force doesn't always work
-    * readline completion for commands with more than one parameters
-
-"""
-
-##########################################################################
-# Import and setup global variables
-##########################################################################
-
-from __future__ import print_function
-from functools import reduce
-try:
-    set
-except NameError:
-    from sets import Set as set
-import sys, os, readline, socket, httplib, urllib, commands, popen2, shlex, Queue, fnmatch
-from bb import data, parse, build, cache, taskdata, runqueue, providers as Providers
-
-__version__ = "0.5.3.1"
-__credits__ = """BitBake Shell Version %s (C) 2005 Michael 'Mickey' Lauer <mickey@Vanille.de>
-Type 'help' for more information, press CTRL-D to exit.""" % __version__
-
-cmds = {}
-leave_mainloop = False
-last_exception = None
-cooker = None
-parsed = False
-debug = os.environ.get( "BBSHELL_DEBUG", "" )
-
-##########################################################################
-# Class BitBakeShellCommands
-##########################################################################
-
-class BitBakeShellCommands:
-    """This class contains the valid commands for the shell"""
-
-    def __init__( self, shell ):
-        """Register all the commands"""
-        self._shell = shell
-        for attr in BitBakeShellCommands.__dict__:
-            if not attr.startswith( "_" ):
-                if attr.endswith( "_" ):
-                    command = attr[:-1].lower()
-                else:
-                    command = attr[:].lower()
-                method = getattr( BitBakeShellCommands, attr )
-                debugOut( "registering command '%s'" % command )
-                # scan number of arguments
-                usage = getattr( method, "usage", "" )
-                if usage != "<...>":
-                    numArgs = len( usage.split() )
-                else:
-                    numArgs = -1
-                shell.registerCommand( command, method, numArgs, "%s %s" % ( command, usage ), method.__doc__ )
-
-    def _checkParsed( self ):
-        if not parsed:
-            print("SHELL: This command needs to parse bbfiles...")
-            self.parse( None )
-
-    def _findProvider( self, item ):
-        self._checkParsed()
-        # Need to use taskData for this information
-        preferred = data.getVar( "PREFERRED_PROVIDER_%s" % item, cooker.configuration.data, 1 )
-        if not preferred: preferred = item
-        try:
-            lv, lf, pv, pf = Providers.findBestProvider(preferred, cooker.configuration.data, cooker.status)
-        except KeyError:
-            if item in cooker.status.providers:
-                pf = cooker.status.providers[item][0]
-            else:
-                pf = None
-        return pf
-
-    def alias( self, params ):
-        """Register a new name for a command"""
-        new, old = params
-        if not old in cmds:
-            print("ERROR: Command '%s' not known" % old)
-        else:
-            cmds[new] = cmds[old]
-            print("OK")
-    alias.usage = "<alias> <command>"
-
-    def buffer( self, params ):
-        """Dump specified output buffer"""
-        index = params[0]
-        print(self._shell.myout.buffer( int( index ) ))
-    buffer.usage = "<index>"
-
-    def buffers( self, params ):
-        """Show the available output buffers"""
-        commands = self._shell.myout.bufferedCommands()
-        if not commands:
-            print("SHELL: No buffered commands available yet. Start doing something.")
-        else:
-            print("="*35, "Available Output Buffers", "="*27)
-            for index, cmd in enumerate( commands ):
-                print("| %s %s" % ( str( index ).ljust( 3 ), cmd ))
-            print("="*88)
-
-    def build( self, params, cmd = "build" ):
-        """Build a providee"""
-        global last_exception
-        globexpr = params[0]
-        self._checkParsed()
-        names = globfilter( cooker.status.pkg_pn, globexpr )
-        if len( names ) == 0: names = [ globexpr ]
-        print("SHELL: Building %s" % ' '.join( names ))
-
-        td = taskdata.TaskData(cooker.configuration.abort)
-        localdata = data.createCopy(cooker.configuration.data)
-        data.update_data(localdata)
-        data.expandKeys(localdata)
-
-        try:
-            tasks = []
-            for name in names:
-                td.add_provider(localdata, cooker.status, name)
-                providers = td.get_provider(name)
-
-                if len(providers) == 0:
-                    raise Providers.NoProvider
-
-                tasks.append([name, "do_%s" % cmd])
-
-            td.add_unresolved(localdata, cooker.status)
-
-            rq = runqueue.RunQueue(cooker, localdata, cooker.status, td, tasks)
-            rq.prepare_runqueue()
-            rq.execute_runqueue()
-
-        except Providers.NoProvider:
-            print("ERROR: No Provider")
-            last_exception = Providers.NoProvider
-
-        except runqueue.TaskFailure as fnids:
-            last_exception = runqueue.TaskFailure
-
-        except build.FuncFailed as e:
-            print("ERROR: Couldn't build '%s'" % names)
-            last_exception = e
-
-
-    build.usage = "<providee>"
-
-    def clean( self, params ):
-        """Clean a providee"""
-        self.build( params, "clean" )
-    clean.usage = "<providee>"
-
-    def compile( self, params ):
-        """Execute 'compile' on a providee"""
-        self.build( params, "compile" )
-    compile.usage = "<providee>"
-
-    def configure( self, params ):
-        """Execute 'configure' on a providee"""
-        self.build( params, "configure" )
-    configure.usage = "<providee>"
-
-    def install( self, params ):
-        """Execute 'install' on a providee"""
-        self.build( params, "install" )
-    install.usage = "<providee>"
-
-    def edit( self, params ):
-        """Call $EDITOR on a providee"""
-        name = params[0]
-        bbfile = self._findProvider( name )
-        if bbfile is not None:
-            os.system( "%s %s" % ( os.environ.get( "EDITOR", "vi" ), bbfile ) )
-        else:
-            print("ERROR: Nothing provides '%s'" % name)
-    edit.usage = "<providee>"
-
-    def environment( self, params ):
-        """Dump out the outer BitBake environment"""
-        cooker.showEnvironment()
-
-    def exit_( self, params ):
-        """Leave the BitBake Shell"""
-        debugOut( "setting leave_mainloop to true" )
-        global leave_mainloop
-        leave_mainloop = True
-
-    def fetch( self, params ):
-        """Fetch a providee"""
-        self.build( params, "fetch" )
-    fetch.usage = "<providee>"
-
-    def fileBuild( self, params, cmd = "build" ):
-        """Parse and build a .bb file"""
-        global last_exception
-        name = params[0]
-        bf = completeFilePath( name )
-        print("SHELL: Calling '%s' on '%s'" % ( cmd, bf ))
-
-        try:
-            cooker.buildFile(bf, cmd)
-        except parse.ParseError:
-            print("ERROR: Unable to open or parse '%s'" % bf)
-        except build.FuncFailed as e:
-            print("ERROR: Couldn't build '%s'" % name)
-            last_exception = e
-
-    fileBuild.usage = "<bbfile>"
-
-    def fileClean( self, params ):
-        """Clean a .bb file"""
-        self.fileBuild( params, "clean" )
-    fileClean.usage = "<bbfile>"
-
-    def fileEdit( self, params ):
-        """Call $EDITOR on a .bb file"""
-        name = params[0]
-        os.system( "%s %s" % ( os.environ.get( "EDITOR", "vi" ), completeFilePath( name ) ) )
-    fileEdit.usage = "<bbfile>"
-
-    def fileRebuild( self, params ):
-        """Rebuild (clean & build) a .bb file"""
-        self.fileBuild( params, "rebuild" )
-    fileRebuild.usage = "<bbfile>"
-
-    def fileReparse( self, params ):
-        """(re)Parse a bb file"""
-        bbfile = params[0]
-        print("SHELL: Parsing '%s'" % bbfile)
-        parse.update_mtime( bbfile )
-        cooker.parser.reparse(bbfile)
-        if False: #fromCache:
-            print("SHELL: File has not been updated, not reparsing")
-        else:
-            print("SHELL: Parsed")
-    fileReparse.usage = "<bbfile>"
-
-    def abort( self, params ):
-        """Toggle abort task execution flag (see bitbake -k)"""
-        cooker.configuration.abort = not cooker.configuration.abort
-        print("SHELL: Abort Flag is now '%s'" % repr( cooker.configuration.abort ))
-
-    def force( self, params ):
-        """Toggle force task execution flag (see bitbake -f)"""
-        cooker.configuration.force = not cooker.configuration.force
-        print("SHELL: Force Flag is now '%s'" % repr( cooker.configuration.force ))
-
-    def help( self, params ):
-        """Show a comprehensive list of commands and their purpose"""
-        print("="*30, "Available Commands", "="*30)
-        for cmd in sorted(cmds):
-            function, numparams, usage, helptext = cmds[cmd]
-            print("| %s | %s" % (usage.ljust(30), helptext))
-        print("="*78)
-
-    def lastError( self, params ):
-        """Show the reason or log that was produced by the last BitBake event exception"""
-        if last_exception is None:
-            print("SHELL: No Errors yet (Phew)...")
-        else:
-            reason, event = last_exception.args
-            print("SHELL: Reason for the last error: '%s'" % reason)
-            if ':' in reason:
-                msg, filename = reason.split( ':' )
-                filename = filename.strip()
-                print("SHELL: Dumping log file for last error:")
-                try:
-                    print(open( filename ).read())
-                except IOError:
-                    print("ERROR: Couldn't open '%s'" % filename)
-
-    def match( self, params ):
-        """Dump all files or providers matching a glob expression"""
-        what, globexpr = params
-        if what == "files":
-            self._checkParsed()
-            for key in globfilter( cooker.status.pkg_fn, globexpr ): print(key)
-        elif what == "providers":
-            self._checkParsed()
-            for key in globfilter( cooker.status.pkg_pn, globexpr ): print(key)
-        else:
-            print("Usage: match %s" % self.print_.usage)
-    match.usage = "<files|providers> <glob>"
-
-    def new( self, params ):
-        """Create a new .bb file and open the editor"""
-        dirname, filename = params
-        packages = '/'.join( data.getVar( "BBFILES", cooker.configuration.data, 1 ).split('/')[:-2] )
-        fulldirname = "%s/%s" % ( packages, dirname )
-
-        if not os.path.exists( fulldirname ):
-            print("SHELL: Creating '%s'" % fulldirname)
-            os.mkdir( fulldirname )
-        if os.path.exists( fulldirname ) and os.path.isdir( fulldirname ):
-            if os.path.exists( "%s/%s" % ( fulldirname, filename ) ):
-                print("SHELL: ERROR: %s/%s already exists" % ( fulldirname, filename ))
-                return False
-            print("SHELL: Creating '%s/%s'" % ( fulldirname, filename ))
-            newpackage = open( "%s/%s" % ( fulldirname, filename ), "w" )
-            print("""DESCRIPTION = ""
-SECTION = ""
-AUTHOR = ""
-HOMEPAGE = ""
-MAINTAINER = ""
-LICENSE = "GPL"
-PR = "r0"
-
-SRC_URI = ""
-
-#inherit base
-
-#do_configure() {
-#
-#}
-
-#do_compile() {
-#
-#}
-
-#do_stage() {
-#
-#}
-
-#do_install() {
-#
-#}
-""", file=newpackage)
-            newpackage.close()
-            os.system( "%s %s/%s" % ( os.environ.get( "EDITOR" ), fulldirname, filename ) )
-    new.usage = "<directory> <filename>"
-
-    def package( self, params ):
-        """Execute 'package' on a providee"""
-        self.build( params, "package" )
-    package.usage = "<providee>"
-
-    def pasteBin( self, params ):
-        """Send a command + output buffer to the pastebin at http://rafb.net/paste"""
-        index = params[0]
-        contents = self._shell.myout.buffer( int( index ) )
-        sendToPastebin( "output of " + params[0], contents )
-    pasteBin.usage = "<index>"
-
-    def pasteLog( self, params ):
-        """Send the last event exception error log (if there is one) to http://rafb.net/paste"""
-        if last_exception is None:
-            print("SHELL: No Errors yet (Phew)...")
-        else:
-            reason, event = last_exception.args
-            print("SHELL: Reason for the last error: '%s'" % reason)
-            if ':' in reason:
-                msg, filename = reason.split( ':' )
-                filename = filename.strip()
-                print("SHELL: Pasting log file to pastebin...")
-
-                file = open( filename ).read()
-                sendToPastebin( "contents of " + filename, file )
-
-    def patch( self, params ):
-        """Execute 'patch' command on a providee"""
-        self.build( params, "patch" )
-    patch.usage = "<providee>"
-
-    def parse( self, params ):
-        """(Re-)parse .bb files and calculate the dependency graph"""
-        cooker.status = cache.CacheData(cooker.caches_array)
-        ignore = data.getVar("ASSUME_PROVIDED", cooker.configuration.data, 1) or ""
-        cooker.status.ignored_dependencies = set( ignore.split() )
-        cooker.handleCollections( data.getVar("BBFILE_COLLECTIONS", cooker.configuration.data, 1) )
-
-        (filelist, masked) = cooker.collect_bbfiles()
-        cooker.parse_bbfiles(filelist, masked, cooker.myProgressCallback)
-        cooker.buildDepgraph()
-        global parsed
-        parsed = True
-        print()
-
-    def reparse( self, params ):
-        """(re)Parse a providee's bb file"""
-        bbfile = self._findProvider( params[0] )
-        if bbfile is not None:
-            print("SHELL: Found bbfile '%s' for '%s'" % ( bbfile, params[0] ))
-            self.fileReparse( [ bbfile ] )
-        else:
-            print("ERROR: Nothing provides '%s'" % params[0])
-    reparse.usage = "<providee>"
-
-    def getvar( self, params ):
-        """Dump the contents of an outer BitBake environment variable"""
-        var = params[0]
-        value = data.getVar( var, cooker.configuration.data, 1 )
-        print(value)
-    getvar.usage = "<variable>"
-
-    def peek( self, params ):
-        """Dump contents of variable defined in providee's metadata"""
-        name, var = params
-        bbfile = self._findProvider( name )
-        if bbfile is not None:
-            the_data = cache.Cache.loadDataFull(bbfile, cooker.configuration.data)
-            value = the_data.getVar( var, 1 )
-            print(value)
-        else:
-            print("ERROR: Nothing provides '%s'" % name)
-    peek.usage = "<providee> <variable>"
-
-    def poke( self, params ):
-        """Set contents of variable defined in providee's metadata"""
-        name, var, value = params
-        bbfile = self._findProvider( name )
-        if bbfile is not None:
-            print("ERROR: Sorry, this functionality is currently broken")
-            #d = cooker.pkgdata[bbfile]
-            #data.setVar( var, value, d )
-
-            # mark the change semi persistant
-            #cooker.pkgdata.setDirty(bbfile, d)
-            #print "OK"
-        else:
-            print("ERROR: Nothing provides '%s'" % name)
-    poke.usage = "<providee> <variable> <value>"
-
-    def print_( self, params ):
-        """Dump all files or providers"""
-        what = params[0]
-        if what == "files":
-            self._checkParsed()
-            for key in cooker.status.pkg_fn: print(key)
-        elif what == "providers":
-            self._checkParsed()
-            for key in cooker.status.providers: print(key)
-        else:
-            print("Usage: print %s" % self.print_.usage)
-    print_.usage = "<files|providers>"
-
-    def python( self, params ):
-        """Enter the expert mode - an interactive BitBake Python Interpreter"""
-        sys.ps1 = "EXPERT BB>>> "
-        sys.ps2 = "EXPERT BB... "
-        import code
-        interpreter = code.InteractiveConsole( dict( globals() ) )
-        interpreter.interact( "SHELL: Expert Mode - BitBake Python %s\nType 'help' for more information, press CTRL-D to switch back to BBSHELL." % sys.version )
-
-    def showdata( self, params ):
-        """Execute 'showdata' on a providee"""
-        cooker.showEnvironment(None, params)
-    showdata.usage = "<providee>"
-
-    def setVar( self, params ):
-        """Set an outer BitBake environment variable"""
-        var, value = params
-        data.setVar( var, value, cooker.configuration.data )
-        print("OK")
-    setVar.usage = "<variable> <value>"
-
-    def rebuild( self, params ):
-        """Clean and rebuild a .bb file or a providee"""
-        self.build( params, "clean" )
-        self.build( params, "build" )
-    rebuild.usage = "<providee>"
-
-    def shell( self, params ):
-        """Execute a shell command and dump the output"""
-        if params != "":
-            print(commands.getoutput( " ".join( params ) ))
-    shell.usage = "<...>"
-
-    def stage( self, params ):
-        """Execute 'stage' on a providee"""
-        self.build( params, "populate_staging" )
-    stage.usage = "<providee>"
-
-    def status( self, params ):
-        """<just for testing>"""
-        print("-" * 78)
-        print("building list = '%s'" % cooker.building_list)
-        print("build path = '%s'" % cooker.build_path)
-        print("consider_msgs_cache = '%s'" % cooker.consider_msgs_cache)
-        print("build stats = '%s'" % cooker.stats)
-        if last_exception is not None: print("last_exception = '%s'" % repr( last_exception.args ))
-        print("memory output contents = '%s'" % self._shell.myout._buffer)
-
-    def test( self, params ):
-        """<just for testing>"""
-        print("testCommand called with '%s'" % params)
-
-    def unpack( self, params ):
-        """Execute 'unpack' on a providee"""
-        self.build( params, "unpack" )
-    unpack.usage = "<providee>"
-
-    def which( self, params ):
-        """Computes the providers for a given providee"""
-        # Need to use taskData for this information
-        item = params[0]
-
-        self._checkParsed()
-
-        preferred = data.getVar( "PREFERRED_PROVIDER_%s" % item, cooker.configuration.data, 1 )
-        if not preferred: preferred = item
-
-        try:
-            lv, lf, pv, pf = Providers.findBestProvider(preferred, cooker.configuration.data, cooker.status)
-        except KeyError:
-            lv, lf, pv, pf = (None,)*4
-
-        try:
-            providers = cooker.status.providers[item]
-        except KeyError:
-            print("SHELL: ERROR: Nothing provides", preferred)
-        else:
-            for provider in providers:
-                if provider == pf: provider = " (***) %s" % provider
-                else:              provider = "       %s" % provider
-                print(provider)
-    which.usage = "<providee>"
-
-##########################################################################
-# Common helper functions
-##########################################################################
-
-def completeFilePath( bbfile ):
-    """Get the complete bbfile path"""
-    if not cooker.status: return bbfile
-    if not cooker.status.pkg_fn: return bbfile
-    for key in cooker.status.pkg_fn:
-        if key.endswith( bbfile ):
-            return key
-    return bbfile
-
-def sendToPastebin( desc, content ):
-    """Send content to http://oe.pastebin.com"""
-    mydata = {}
-    mydata["lang"] = "Plain Text"
-    mydata["desc"] = desc
-    mydata["cvt_tabs"] = "No"
-    mydata["nick"] = "%s@%s" % ( os.environ.get( "USER", "unknown" ), socket.gethostname() or "unknown" )
-    mydata["text"] = content
-    params = urllib.urlencode( mydata )
-    headers = {"Content-type": "application/x-www-form-urlencoded", "Accept": "text/plain"}
-
-    host = "rafb.net"
-    conn = httplib.HTTPConnection( "%s:80" % host )
-    conn.request("POST", "/paste/paste.php", params, headers )
-
-    response = conn.getresponse()
-    conn.close()
-
-    if response.status == 302:
-        location = response.getheader( "location" ) or "unknown"
-        print("SHELL: Pasted to http://%s%s" % ( host, location ))
-    else:
-        print("ERROR: %s %s" % ( response.status, response.reason ))
-
-def completer( text, state ):
-    """Return a possible readline completion"""
-    debugOut( "completer called with text='%s', state='%d'" % ( text, state ) )
-
-    if state == 0:
-        line = readline.get_line_buffer()
-        if " " in line:
-            line = line.split()
-            # we are in second (or more) argument
-            if line[0] in cmds and hasattr( cmds[line[0]][0], "usage" ): # known command and usage
-                u = getattr( cmds[line[0]][0], "usage" ).split()[0]
-                if u == "<variable>":
-                    allmatches = cooker.configuration.data.keys()
-                elif u == "<bbfile>":
-                    if cooker.status.pkg_fn is None: allmatches = [ "(No Matches Available. Parsed yet?)" ]
-                    else: allmatches = [ x.split("/")[-1] for x in cooker.status.pkg_fn ]
-                elif u == "<providee>":
-                    if cooker.status.pkg_fn is None: allmatches = [ "(No Matches Available. Parsed yet?)" ]
-                    else: allmatches = cooker.status.providers.iterkeys()
-                else: allmatches = [ "(No tab completion available for this command)" ]
-            else: allmatches = [ "(No tab completion available for this command)" ]
-        else:
-            # we are in first argument
-            allmatches = cmds.iterkeys()
-
-        completer.matches = [ x for x in allmatches if x[:len(text)] == text ]
-        #print "completer.matches = '%s'" % completer.matches
-    if len( completer.matches ) > state:
-        return completer.matches[state]
-    else:
-        return None
-
-def debugOut( text ):
-    if debug:
-        sys.stderr.write( "( %s )\n" % text )
-
-def columnize( alist, width = 80 ):
-    """
-    A word-wrap function that preserves existing line breaks
-    and most spaces in the text. Expects that existing line
-    breaks are posix newlines (\n).
-    """
-    return reduce(lambda line, word, width=width: '%s%s%s' %
-                  (line,
-                   ' \n'[(len(line[line.rfind('\n')+1:])
-                         + len(word.split('\n', 1)[0]
-                              ) >= width)],
-                   word),
-                  alist
-                 )
-
-def globfilter( names, pattern ):
-    return fnmatch.filter( names, pattern )
-
-##########################################################################
-# Class MemoryOutput
-##########################################################################
-
-class MemoryOutput:
-    """File-like output class buffering the output of the last 10 commands"""
-    def __init__( self, delegate ):
-        self.delegate = delegate
-        self._buffer = []
-        self.text = []
-        self._command = None
-
-    def startCommand( self, command ):
-        self._command = command
-        self.text = []
-    def endCommand( self ):
-        if self._command is not None:
-            if len( self._buffer ) == 10: del self._buffer[0]
-            self._buffer.append( ( self._command, self.text ) )
-    def removeLast( self ):
-        if self._buffer:
-            del self._buffer[ len( self._buffer ) - 1 ]
-        self.text = []
-        self._command = None
-    def lastBuffer( self ):
-        if self._buffer:
-            return self._buffer[ len( self._buffer ) -1 ][1]
-    def bufferedCommands( self ):
-        return [ cmd for cmd, output in self._buffer ]
-    def buffer( self, i ):
-        if i < len( self._buffer ):
-            return "BB>> %s\n%s" % ( self._buffer[i][0], "".join( self._buffer[i][1] ) )
-        else: return "ERROR: Invalid buffer number. Buffer needs to be in (0, %d)" % ( len( self._buffer ) - 1 )
-    def write( self, text ):
-        if self._command is not None and text != "BB>> ": self.text.append( text )
-        if self.delegate is not None: self.delegate.write( text )
-    def flush( self ):
-        return self.delegate.flush()
-    def fileno( self ):
-        return self.delegate.fileno()
-    def isatty( self ):
-        return self.delegate.isatty()
-
-##########################################################################
-# Class BitBakeShell
-##########################################################################
-
-class BitBakeShell:
-
-    def __init__( self ):
-        """Register commands and set up readline"""
-        self.commandQ = Queue.Queue()
-        self.commands = BitBakeShellCommands( self )
-        self.myout = MemoryOutput( sys.stdout )
-        self.historyfilename = os.path.expanduser( "~/.bbsh_history" )
-        self.startupfilename = os.path.expanduser( "~/.bbsh_startup" )
-
-        readline.set_completer( completer )
-        readline.set_completer_delims( " " )
-        readline.parse_and_bind("tab: complete")
-
-        try:
-            readline.read_history_file( self.historyfilename )
-        except IOError:
-            pass  # It doesn't exist yet.
-
-        print(__credits__)
-
-    def cleanup( self ):
-        """Write readline history and clean up resources"""
-        debugOut( "writing command history" )
-        try:
-            readline.write_history_file( self.historyfilename )
-        except:
-            print("SHELL: Unable to save command history")
-
-    def registerCommand( self, command, function, numparams = 0, usage = "", helptext = "" ):
-        """Register a command"""
-        if usage == "": usage = command
-        if helptext == "": helptext = function.__doc__ or "<not yet documented>"
-        cmds[command] = ( function, numparams, usage, helptext )
-
-    def processCommand( self, command, params ):
-        """Process a command. Check number of params and print a usage string, if appropriate"""
-        debugOut( "processing command '%s'..." % command )
-        try:
-            function, numparams, usage, helptext = cmds[command]
-        except KeyError:
-            print("SHELL: ERROR: '%s' command is not a valid command." % command)
-            self.myout.removeLast()
-        else:
-            if (numparams != -1) and (not len( params ) == numparams):
-                print("Usage: '%s'" % usage)
-                return
-
-            result = function( self.commands, params )
-            debugOut( "result was '%s'" % result )
-
-    def processStartupFile( self ):
-        """Read and execute all commands found in $HOME/.bbsh_startup"""
-        if os.path.exists( self.startupfilename ):
-            startupfile = open( self.startupfilename, "r" )
-            for cmdline in startupfile:
-                debugOut( "processing startup line '%s'" % cmdline )
-                if not cmdline:
-                    continue
-                if "|" in cmdline:
-                    print("ERROR: '|' in startup file is not allowed. Ignoring line")
-                    continue
-                self.commandQ.put( cmdline.strip() )
-
-    def main( self ):
-        """The main command loop"""
-        while not leave_mainloop:
-            try:
-                if self.commandQ.empty():
-                    sys.stdout = self.myout.delegate
-                    cmdline = raw_input( "BB>> " )
-                    sys.stdout = self.myout
-                else:
-                    cmdline = self.commandQ.get()
-                if cmdline:
-                    allCommands = cmdline.split( ';' )
-                    for command in allCommands:
-                        pipecmd = None
-                        #
-                        # special case for expert mode
-                        if command == 'python':
-                            sys.stdout = self.myout.delegate
-                            self.processCommand( command, "" )
-                            sys.stdout = self.myout
-                        else:
-                            self.myout.startCommand( command )
-                            if '|' in command: # disable output
-                                command, pipecmd = command.split( '|' )
-                                delegate = self.myout.delegate
-                                self.myout.delegate = None
-                            tokens = shlex.split( command, True )
-                            self.processCommand( tokens[0], tokens[1:] or "" )
-                            self.myout.endCommand()
-                            if pipecmd is not None: # restore output
-                                self.myout.delegate = delegate
-
-                                pipe = popen2.Popen4( pipecmd )
-                                pipe.tochild.write( "\n".join( self.myout.lastBuffer() ) )
-                                pipe.tochild.close()
-                                sys.stdout.write( pipe.fromchild.read() )
-                        #
-            except EOFError:
-                print()
-                return
-            except KeyboardInterrupt:
-                print()
-
-##########################################################################
-# Start function - called from the BitBake command line utility
-##########################################################################
-
-def start( aCooker ):
-    global cooker
-    cooker = aCooker
-    bbshell = BitBakeShell()
-    bbshell.processStartupFile()
-    bbshell.main()
-    bbshell.cleanup()
-
-if __name__ == "__main__":
-    print("SHELL: Sorry, this program should only be called by BitBake.")

bitbake/lib/bb/tests/fetch.py

@@ -402,6 +402,10 @@ 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",
 
         #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 +836,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):
@@ -913,7 +917,7 @@ class FetchLatestVersionTest(FetcherTest):
             ud = bb.fetch2.FetchData(k[1], self.d)
             pupver= ud.method.latest_versionstring(ud, self.d)
             verstring = pupver[0]
-            self.assertTrue(verstring, msg="Could not find upstream version")
+            self.assertTrue(verstring, msg="Could not find upstream version for %s" % k[0])
             r = bb.utils.vercmp_string(v, verstring)
             self.assertTrue(r == -1 or r == 0, msg="Package %s, version: %s <= %s" % (k[0], v, verstring))
 
@@ -926,7 +930,7 @@ class FetchLatestVersionTest(FetcherTest):
             ud = bb.fetch2.FetchData(k[1], self.d)
             pupver = ud.method.latest_versionstring(ud, self.d)
             verstring = pupver[0]
-            self.assertTrue(verstring, msg="Could not find upstream version")
+            self.assertTrue(verstring, msg="Could not find upstream version for %s" % k[0])
             r = bb.utils.vercmp_string(v, verstring)
             self.assertTrue(r == -1 or r == 0, msg="Package %s, version: %s <= %s" % (k[0], v, verstring))
 

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/bldcontrol/management/commands/checksettings.py

@@ -107,7 +107,10 @@ class Command(BaseCommand):
                                 action="ignore",
                                 message="^.*No fixture named.*$")
                             print("Importing custom settings if present")
-                            call_command("loaddata", "custom")
+                            try:
+                                call_command("loaddata", "custom")
+                            except:
+                                print("NOTE: optional fixture 'custom' not found")
 
                         # we run lsupdates after config update
                         print("\nFetching information from the layer index, "

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
 	endif
 
 MANUALS = $(DOC)/$(DOC).html
@@ -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/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-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>
@@ -380,7 +750,7 @@
         <para>
             The
             <ulink url='&YOCTO_HOME_URL;'>Yocto Project Website</ulink>
-            uses a "Downloads" area from which you can locate and download
+            uses a "DOWNLOADS" page from which you can locate and download
             tarballs of any Yocto Project release.
             Rather than Git repositories, these files represent snapshot
             tarballs.
@@ -400,17 +770,24 @@
                     </para></listitem>
                 <listitem><para>
                     <emphasis>Get to the Downloads Area:</emphasis>
-                    Click the "Downloads" tab.
+                    Select the "DOWNLOADS" item from the pull-down
+                    "SOFTWARE" tab menu.
                     </para></listitem>
                 <listitem><para>
-                    <emphasis>Select the Type of Files:</emphasis>
-                    Click the type of files you want such as "Build System",
-                    "Tools", or "Board Support Packages (BSPs)".
+                    <emphasis>Select a Yocto Project Release:</emphasis>
+                    Use the menu next to "RELEASE" to display and choose
+                    a Yocto Project release (e.g. sumo, rocko, pyro, and
+                    so forth.
+                    For a "map" of Yocto Project releases to version numbers,
+                    see the
+                    <ulink url='https://wiki.yoctoproject.org/wiki/Releases'>Releases</ulink>
+                    wiki page.
                     </para></listitem>
                 <listitem><para>
-                    <emphasis>Locate and Download the Tarball:</emphasis>
-                    From the list of releases, locate the appropriate
-                    download link and download the files.
+                    <emphasis>Download Tools or Board Support Packages (BSPs):</emphasis>
+                    From the "DOWNLOADS" page, you can download tools or
+                    BSPs as well.
+                    Just scroll down the page and look for what you need.
                     </para></listitem>
             </orderedlist>
         </para>
@@ -452,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
@@ -516,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.
@@ -699,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-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/getting-started/'"/>
-  <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/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
@@ -631,8 +628,10 @@
             <note>
                 For BSPs supported by the Yocto Project, the BSP description
                 files are located in the <filename>bsp</filename> directory
-                of the <filename>yocto-kernel-cache</filename> repository
-                organized under the "Yocto Linux Kernel" heading in the
+                of the
+                <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/yocto-kernel-cache/tree/bsp'><filename>yocto-kernel-cache</filename></ulink>
+                repository organized under the "Yocto Linux Kernel" heading
+                in the
                 <ulink url='http://git.yoctoproject.org/cgit/cgit.cgi'>Yocto Project Source Repositories</ulink>.
             </note>
         </para>
@@ -641,27 +640,30 @@
             This section overviews the BSP description structure, the
             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>.
         </para>
 
         <section id='bsp-description-file-overview'>
             <title>Overview</title>
 
             <para>
-                For simplicity, consider the following top-level BSP
+                For simplicity, consider the following root BSP layer
                 description files for the BeagleBone board.
-                Top-level BSP descriptions files employ both a structure
-                and naming convention for consistency.
+                These files employ both a structure and naming convention
+                for consistency.
                 The naming convention for the file is as follows:
                 <literallayout class='monospaced'>
-     <replaceable>bsp_name</replaceable>-<replaceable>kernel_type</replaceable>.scc
+     <replaceable>bsp_root_name</replaceable>-<replaceable>kernel_type</replaceable>.scc
                 </literallayout>
-                Here are some example top-level BSP filenames for the
+                Here are some example root layer BSP filenames for the
                 BeagleBone Board BSP, which is supported by the Yocto Project:
                 <literallayout class='monospaced'>
      beaglebone-standard.scc
      beaglebone-preempt-rt.scc
                 </literallayout>
-                Each file uses the BSP name followed by the kernel type.
+                Each file uses the root name (i.e "beaglebone") BSP name
+                followed by the kernel type.
             </para>
 
             <para>
@@ -850,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
@@ -1012,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.
@@ -1221,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".
@@ -136,7 +136,7 @@
                             Developer's Guide, respectively.
                             For information on how to use the
                             <filename>bitbake-layers create-layer</filename>
-                            command, see the
+                            command to quickly set up a layer, see the
                             "<ulink url='&YOCTO_DOCS_DEV_URL;#creating-a-general-layer-using-the-bitbake-layers-script'>Creating a General Layer Using the <filename>bitbake-layers</filename> Script</ulink>"
                             section in the Yocto Project Development Tasks
                             Manual.
@@ -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".
@@ -360,7 +360,7 @@
                             Developer's Guide, respectively.
                             For information on how to use the
                             <filename>bitbake-layers create-layer</filename>
-                            command, see the
+                            command to quickly set up a layer, see the
                             "<ulink url='&YOCTO_DOCS_DEV_URL;#creating-a-general-layer-using-the-bitbake-layers-script'>Creating a General Layer Using the <filename>bitbake-layers</filename> Script</ulink>"
                             section in the Yocto Project Development Tasks
                             Manual.
@@ -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>
@@ -489,7 +489,8 @@
                 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 for
-                information on how to use this script.
+                information on how to use this script to quick set up a
+                new layer.
             </note>
         </para>
 
@@ -1224,18 +1225,6 @@
             the
             "<link linkend='getting-ready-for-traditional-kernel-development'>Getting Ready for Traditional Kernel Development</link>"
             Section.
-        </para>
-
-        <para>
-            Although this example uses Git and shell commands to generate the
-            patch, you could use the <filename>yocto-kernel</filename> script
-            found in the <ulink url='&YOCTO_DOCS_REF_URL;#source-directory'>Source Directory</ulink>
-            under <filename>scripts</filename> to add and manage kernel
-            patches and configuration.
-            See the "<ulink url='&YOCTO_DOCS_BSP_URL;#managing-kernel-patches-and-config-items-with-yocto-kernel'>Managing kernel Patches and Config Items with yocto-kernel</ulink>"
-            section in the Yocto Project Board Support Packages (BSP)
-            Developer's Guide for more information on the
-            <filename>yocto-kernel</filename> script.
             <orderedlist>
                 <listitem><para>
                     <emphasis>Edit the Source Files</emphasis>
@@ -1413,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>
 
@@ -1667,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>
@@ -2429,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
@@ -2505,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>
@@ -127,18 +131,6 @@
                 </para></listitem>
         </itemizedlist>
     </para>
-
-    <para>
-        Finally, while this document focuses on the manual creation of
-        recipes, patches, and configuration files, the Yocto Project
-        Board Support Package (BSP) tools are available to automate
-        this process with existing content and work well to create the
-        initial framework and boilerplate code.
-        For details on these tools, see the
-        "<ulink url='&YOCTO_DOCS_BSP_URL;#using-the-yocto-projects-bsp-tools'>Using the Yocto Project's BSP Tools</ulink>"
-        section in the Yocto Project Board Support Package (BSP) Developer's
-        Guide.
-    </para>
 </section>
 
 <section id='kernel-modification-workflow'>
@@ -165,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>
@@ -243,11 +238,7 @@
 
                 <para>Additionally, if you are working in a BSP layer
                 and need to modify the BSP's kernel's configuration,
-                you can use the
-                <ulink url='&YOCTO_DOCS_BSP_URL;#managing-kernel-patches-and-config-items-with-yocto-kernel'><filename>yocto-kernel</filename></ulink>
-                script as well as <filename>menuconfig</filename>.
-                The <filename>yocto-kernel</filename> script lets
-                you interactively set up kernel configurations.
+                you can use <filename>menuconfig</filename>.
                 </para></listitem>
             <listitem><para>
                 <emphasis>Rebuild the Kernel Image With Your Changes:</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,13 +118,13 @@
             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.
-            These are the actions that effectively provide the Metadata
-            and create the tree that includes the new feature, patch or BSP:
+            The following actions effectively provide the Metadata
+            and create the tree that includes the new feature, patch, or BSP:
             <orderedlist>
                 <listitem><para>
-                    <emphasis>Pass Feature to Build Subsystem:</emphasis>
+                    <emphasis>Pass Feature to the OpenEmbedded Build System:</emphasis>
                     A top-level kernel feature is passed to the kernel build
                     subsystem.
                     Normally, this feature is a BSP for a particular kernel
@@ -138,8 +138,10 @@
                         <listitem><para>
                             The in-tree kernel-cache directories, which are
                             located in the
-                            <filename>yocto-kernel-cache</filename>
-                            repository
+                            <ulink url='&YOCTO_GIT_URL;/cgit/cgit.cgi/yocto-kernel-cache/tree/bsp'><filename>yocto-kernel-cache</filename></ulink>
+                            repository organized under the "Yocto Linux Kernel"
+                            heading in the
+                            <ulink url='http://git.yoctoproject.org/cgit/cgit.cgi'>Yocto Project Source Repositories</ulink>.
                             </para></listitem>
                         <listitem><para>
                             Areas pointed to by <filename>SRC_URI</filename>
@@ -148,9 +150,11 @@
                     </itemizedlist>
                     For a typical build, the target of the search is a
                     feature description in an <filename>.scc</filename> file
-                    whose name follows this format:
+                    whose name follows this format (e.g.
+                    <filename>beaglebone-standard.scc</filename> and
+                    <filename>beaglebone-preempt-rt.scc</filename>):
                     <literallayout class='monospaced'>
-     <replaceable>bsp_name</replaceable>-<replaceable>kernel_type</replaceable>.scc
+     <replaceable>bsp_root_name</replaceable>-<replaceable>kernel_type</replaceable>.scc
                     </literallayout>
                 </para></listitem>
                 <listitem><para>
@@ -213,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>
@@ -227,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 -->